From xen-devel-bounces@lists.xen.org Sun Apr 01 01:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 01:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SE9EB-0008Kz-6m; Sun, 01 Apr 2012 01:05:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SE9E8-0008Ku-SX
	for xen-devel@lists.xen.org; Sun, 01 Apr 2012 01:05:05 +0000
Received: from [85.158.139.83:16676] by server-10.bemta-5.messagelabs.com id
	14/AE-08260-0C9A77F4; Sun, 01 Apr 2012 01:05:04 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333242300!17948971!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32279 invoked from network); 1 Apr 2012 01:05:02 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 01:05:02 -0000
Received: by obbwd20 with SMTP id wd20so3204635obb.32
	for <xen-devel@lists.xen.org>; Sat, 31 Mar 2012 18:05:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=5ihVeXQLeSKRQ2qb2aR0iYO1XgctKKyYnBienm8YJZ8=;
	b=fcBNTDS9ceUkFgvBOHp3U2KQqHA6RJEqGLV0yQNYwz7ScePX1vpDfg8qiAVFspsgH7
	B166BiBV0arsnjMnCWv7UPPXcsdcOeQIzZNargzj6Ho9BVa6n8IGgEgDpmsF5yJDQ3Ff
	ZNpE+86Bcvw2SoYLd526PVeuZDsPo2p+wMw1SrRxVrBy6b5tUp5bEhdFrGoDZvXc0t6A
	byBX4XluUE2reJTA+kRy+QOlrHhXo7c3F3KxWuGaltuQGF8s1zNCzyNhMKKLs3KyQ/Bb
	XdLtq8P3O8lg/HQdoN4TkVFiXq0imQGvEZX9Ai5euDectJVC8YgNhVfnvOTSpZ+6yiQh
	UljA==
MIME-Version: 1.0
Received: by 10.60.4.199 with SMTP id m7mr4651025oem.65.1333242300163; Sat, 31
	Mar 2012 18:05:00 -0700 (PDT)
Received: by 10.182.97.72 with HTTP; Sat, 31 Mar 2012 18:05:00 -0700 (PDT)
X-Originating-IP: [121.44.4.35]
In-Reply-To: <CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
Date: Sun, 1 Apr 2012 11:05:00 +1000
Message-ID: <CAOzFzEjAgtAH6oup=bH9+TfQrCYB5s47RkQoMfdXK1pw-KJwHQ@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQmBKAVvF58TYVDlTSgMTbYB1ors24ydhLhLGwvE5VkOvVtn6USmtZYVVAfe2Esd9JjEo4Zg
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 1 April 2012 09:13, Joseph Glanville <joseph.glanville@orionvm.com.au> w=
rote:
> On 31 March 2012 05:08, Joseph Glanville
> <joseph.glanville@orionvm.com.au> wrote:
>> On 31 March 2012 01:03, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>>> Joseph Glanville writes ("[RFC] Shutdown event script for xl toolstack"=
):
>>>> Previously I had a series of out of tree patches to xend that added a
>>>> shutdown event callback on domain death that would call a script with
>>>> the reason why the domain shutdown.
>>>> Basically analagous to this:
>>>> /etc/xen/scripts/shutdown-event $event $domname $domid
>>>
>>> I think this is a good idea, although it shouldn't be enabled by
>>> default and I don't see the need to provide an example script.
>>
>> Yep fair enough, agree on both points.
>>
>>>
>>>> My general idea is to add a config option for a path to an event
>>>> handler script:
>>>> on_shutdown_event =3D "/etc/xen/scripts/shutdown-event"
>>>
>>> Yes, this is good. =A0Shouldn't the argument be a string list so that
>>> you can specify all the arguments to exec() ? =A0Will the script inherit
>>> the domid or name in an environment variable ?
>>>
>>> You need to document this fully I think, in docs/man/xl.cfg.pod.5.
>>
>> I didn't think of this but you make a very valid point, especially
>> considering we can use environment vars to provide the domain data as
>> you suggested.
>>
>>>
>>> It would also be good for the script to be able to give instructions
>>> to the daemonic xl, for example to cause the daemonic xl to neither
>>> reboot nor preserve the domain. =A0So if you wanted your domain to get a
>>> different config when it reboots, you write a hook script which
>>> destroys the previous domain and starts the new one by hand.
>>
>> Hmm this is interesting and something I hadn't really thought of impleme=
nting.
>> Something that uses the return code of the script I think would be appro=
priate.
>>
>>>
>>>> Create the event during handle_domain_death in xl_cmdimpl.c and fire
>>>> the script once shutdown reason and action has been parsed.
>>>
>>> When you say "create the event" what do you mean ?
>>
>> I think "create" was most definitely incorrect terminology. :)
>> "catch" probably would have been a much better way of terming it now I
>> look at it.
>>
>>>
>>>> I implemented a hacky version to illustrate my point but I would like
>>>> some advice on how to do this properly and what tools/framework within
>>>> libxl I could leverage to make it cleaner.
>>>
>>> This is going in the right direction. =A0I'll comment in more detail
>>> below.
>>>
>>>> A quick overview of the following would help immensely:
>>>> Where to add in a new config option and what steps it goes through to
>>>> get to libxl_domain_config.
>>>
>>> This hook script functionality should be part of xl, not part of
>>> libxl, so arguably you shouldn't add it to libxl_domain_config.
>>>
>>> Indeed I think it's arguably a mistake that the on_{poweroff,...}
>>> items are in libxl_domain_config rather than in something provided in
>>> xl.
>>>
>>> The config parsing is done in parse_config_data.
>>
>> Cheers will take a look.
>>
>>>
>>>> How to exec an external script safely, can I use usual fork/exec or
>>>> should I be using libxl__exec or libxl_spawn*?
>>>
>>> In xl I think you should use fork/exec. =A0You may not use any functions
>>> libxl__* as they are private for libxl.
>>
>> Thanks for clarifying, I also read the naming convention docs this
>> morning which cleared this up too.
>>
>>>
>>>> Best place/way to get the event data, atm handle_domain_death looks
>>>> like an easy target but there might be more elegant ways..
>>>
>>> handle_domain_death is called in only one place, the event loop in the
>>> daemonic xl. =A0And yes, it seems like the right place to do this.
>>>
>>>> diff --git a/tools/hotplug/Linux/shutdown-event
>>>> b/tools/hotplug/Linux/shutdown-event
>>>
>>> As I say I don't think we need an example like this.
>>>
>>> Also do we think asking the user to handle this with a switch in their
>>> event script is really better than providing four separate config
>>> options for separate commands ? =A0Doing the latter will make the
>>> scripts simpler, which is good because they'll be very annoying to
>>> debug.
>>
>> Agreed, that is a much better approach.
>>
>>>
>>>> + =A0 =A0char event_name[10];
>>>> + =A0 =A0char event_cmd[100];
>>>>
>>>> =A0 =A0 switch (info->shutdown_reason) {
>>>> =A0 =A0 case SHUTDOWN_poweroff:
>>>> =A0 =A0 =A0 =A0 action =3D d_config->on_poweroff;
>>>> + =A0 =A0 =A0 =A0strcpy(event_name,"poweroff");
>>>
>>> Surely event_name should be
>>> =A0const char *event_name;
>>> and then you can do
>>> =A0event_name =3D "poweroff";
>>>
>>> But this goes away if you have four separate hook script config
>>> options.
>>>
>>>> + =A0 =A0snprintf(event_cmd, 100, SHUTDOWN_EVENT_SCRIPT, event_name,
>>>> d_config->c_info.name, domid);
>>>> + =A0 =A0ret =3D system(event_cmd);
>>>
>>> This part needs serious work. =A0We need firstly to define an
>>> interface. =A0And, I don't really like system(). =A0You should be using
>>> fork/exec.
>>
>> Yep, now that has been clarified I will work on something cleaner.
>> I think taking the array of string approach in the config file and
>> then parsing that array verbatim as the args to exec is a great idea.
>>
>>>
>>> Thanks,
>>> Ian.
>>
>> I will refactor this into a v1 patch after I work out the config file
>> stuff, sensible script interface and return values etc.
>>
>> Thanks for all of your help!
>>
>> Joseph.
>>
>> --
>> Founder | Director | VP Research
>> Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 =
56
>> 99 52 | Mobile: 0428 754 846
>
> Hi Ian,
>
> I have a few more questions.
>
> As I have become more acquainted with the codebase I can see the line
> between libxl and xl quite clearly.
> However the config file territory seems somewhat ambiguous.
> Domain configuration is stored in libxl_domain_config which is a part
> of libxl but there isn't currently a structure for data that is
> private to xl, that is xl daemon or utility specific configuration.
> Is it considered bad form to add a configuration variable to
> libxl_domain_config that only xl will benefit from? if so what is the
> best course of action here?
> I could create another structure for private data but I feel seeking
> guidance on this as prudent.
>
> In the meantime I had added it to libxl_domain_config but I intend to
> have found/made a cleaner solution before submitting the patch for
> inclusion.
>
> In terms of interface I have come up with what I think is inherently
> simple and reliable.
> The shutdown_event_handler is executed with DOM_ID, DOM_NAME, ACTION
> and REASON in it's environment.
> The return code stipulates what action xl will then take, in
> correspondence with the LIBXL_ACTION_ON_SHUTDOWN* counterparts.
>
> I am yet to document this in the xl.cfg.pod file, I will do so in the
> next revision along with adding support for arguments - once we have
> where we are going to store them sorted out at least.
> Patch is only compile tested at this time, I am away from my testing
> environment atm.
>
> Thanks in advance and kind regards,
> Joseph.
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6b69030..b3e5fb1 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -370,6 +370,8 @@ typedef struct {
> =A0 =A0 libxl_action_on_shutdown on_reboot;
> =A0 =A0 libxl_action_on_shutdown on_watchdog;
> =A0 =A0 libxl_action_on_shutdown on_crash;
> +
> + =A0 =A0char *shutdown_event_handler;
> =A0} libxl_domain_config;
> =A0char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config =
*p);
>
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 1d59b89..1096f23 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -664,6 +664,10 @@ static void parse_config_data(const char
> *configfile_filename_report,
> =A0 =A0 =A0 =A0 exit(1);
> =A0 =A0 }
>
> + =A0 =A0if (xlu_cfg_replace_string (config, "shutdown_event_handler",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&d_config->shutd=
own_event_handler, 0))
> + =A0 =A0 =A0 =A0d_config->shutdown_event_handler =3D NULL;
> +
> =A0 =A0 /* libxl_get_required_shadow_memory() must be called after final =
values
> =A0 =A0 =A0* (default or specified) for vcpus and memory are set, because=
 the
> =A0 =A0 =A0* calculation depends on those values. */
> @@ -1206,6 +1210,63 @@ skip_vfb:
> =A0 =A0 xlu_cfg_destroy(config);
> =A0}
>
> +static int xl_exec(const char *arg0, char **args, char **envp,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 useconds_t timeout)
> +{
> + =A0 =A0int status;
> + =A0 =A0useconds_t sleep_time =3D 10, wait_time =3D 0;
> + =A0 =A0pid_t child_pid, wpid;
> +
> + =A0 =A0child_pid =3D fork();
> + =A0 =A0if (child_pid < 0) {
> + =A0 =A0 =A0 =A0LOG("Failed to fork in xl_exec");
> + =A0 =A0 =A0 =A0exit(-1);
> + =A0 =A0} else if (child_pid =3D=3D 0) {
> + =A0 =A0 =A0 =A0execvpe(arg0,args,envp);
> + =A0 =A0} else {
> + =A0 =A0 =A0 =A0do {
> + =A0 =A0 =A0 =A0 =A0 =A0wpid =3D waitpid(child_pid, &status, WNOHANG);
> + =A0 =A0 =A0 =A0 =A0 =A0if (wpid =3D=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (wait_time < timeout) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usleep(sleep_time);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wait_time +=3D sleep_time;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kill(child_pid, SIGKILL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 =A0} while (wpid =3D=3D 0 && wait_time <=3D timeout);
> +
> + =A0 =A0 =A0 =A0if (WIFSIGNALED(status)) {
> + =A0 =A0 =A0 =A0 =A0 =A0return WEXITSTATUS(status);
> + =A0 =A0 =A0 =A0}
> + =A0 =A0}
> + =A0 =A0return WTERMSIG(status);
> +}

Ahh I fumbled it. Obviously WTERMSIG and WEXITSTATUS should be
reversed here. No idea how I missed this on my last glance over.

> +
> +static int user_shutdown_action(libxl_domain_config *d_config, uint32_t =
domid,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int action, unsigned sh=
utdown_reason)
> +{
> + =A0 =A0int ret;
> + =A0 =A0const char* arg0 =3D d_config->shutdown_event_handler;
> + =A0 =A0char* argv[] =3D {NULL};
> + =A0 =A0char* envp[4];
> + =A0 =A0useconds_t timeout =3D 1000;
> +
> + =A0 =A0asprintf(&envp[0],"DOM_ID=3D%d", domid);
> + =A0 =A0asprintf(&envp[1],"DOM_NAME=3D%s", d_config->c_info.name);
> + =A0 =A0asprintf(&envp[2],"ACTION=3D%d", action);
> + =A0 =A0asprintf(&envp[3],"REASON=3D%u", shutdown_reason);
> + =A0 =A0envp[4] =3D NULL;
> +
> + =A0 =A0ret =3D xl_exec(arg0,argv,envp,timeout);
> +
> + =A0 =A0if ((ret < 0) || ( ret > 6)) {
> + =A0 =A0 =A0 =A0LOG("Invalid shutdown action requested: %d, ignoring",re=
t);
> + =A0 =A0 =A0 =A0return action;
> + =A0 =A0}
> + =A0 =A0return ret;
> +}
> +
> =A0/* Returns 1 if domain should be restarted,
> =A0* 2 if domain should be renamed then restarted, or 0 */
> =A0static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
> @@ -1237,6 +1298,10 @@ static int handle_domain_death(libxl_ctx *ctx,
> uint32_t domid,
> =A0 =A0 =A0 =A0 action =3D LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
> =A0 =A0 }
>
> + =A0 =A0 =A0 if (d_config->shutdown_event_handler)
> + =A0 =A0 =A0 =A0action =3D user_shutdown_action(d_config, domid, action,
> +
> event->u.domain_shutdown.shutdown_reason);
> +
> =A0 =A0 LOG("Action for shutdown reason code %d is %s",
> =A0 =A0 =A0 =A0 event->u.domain_shutdown.shutdown_reason,
> =A0 =A0 =A0 =A0 action_on_shutdown_names[action])
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
> 99 52 | Mobile: 0428 754 846



-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 01:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 01:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SE9EB-0008Kz-6m; Sun, 01 Apr 2012 01:05:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SE9E8-0008Ku-SX
	for xen-devel@lists.xen.org; Sun, 01 Apr 2012 01:05:05 +0000
Received: from [85.158.139.83:16676] by server-10.bemta-5.messagelabs.com id
	14/AE-08260-0C9A77F4; Sun, 01 Apr 2012 01:05:04 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333242300!17948971!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32279 invoked from network); 1 Apr 2012 01:05:02 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 01:05:02 -0000
Received: by obbwd20 with SMTP id wd20so3204635obb.32
	for <xen-devel@lists.xen.org>; Sat, 31 Mar 2012 18:05:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=5ihVeXQLeSKRQ2qb2aR0iYO1XgctKKyYnBienm8YJZ8=;
	b=fcBNTDS9ceUkFgvBOHp3U2KQqHA6RJEqGLV0yQNYwz7ScePX1vpDfg8qiAVFspsgH7
	B166BiBV0arsnjMnCWv7UPPXcsdcOeQIzZNargzj6Ho9BVa6n8IGgEgDpmsF5yJDQ3Ff
	ZNpE+86Bcvw2SoYLd526PVeuZDsPo2p+wMw1SrRxVrBy6b5tUp5bEhdFrGoDZvXc0t6A
	byBX4XluUE2reJTA+kRy+QOlrHhXo7c3F3KxWuGaltuQGF8s1zNCzyNhMKKLs3KyQ/Bb
	XdLtq8P3O8lg/HQdoN4TkVFiXq0imQGvEZX9Ai5euDectJVC8YgNhVfnvOTSpZ+6yiQh
	UljA==
MIME-Version: 1.0
Received: by 10.60.4.199 with SMTP id m7mr4651025oem.65.1333242300163; Sat, 31
	Mar 2012 18:05:00 -0700 (PDT)
Received: by 10.182.97.72 with HTTP; Sat, 31 Mar 2012 18:05:00 -0700 (PDT)
X-Originating-IP: [121.44.4.35]
In-Reply-To: <CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
Date: Sun, 1 Apr 2012 11:05:00 +1000
Message-ID: <CAOzFzEjAgtAH6oup=bH9+TfQrCYB5s47RkQoMfdXK1pw-KJwHQ@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQmBKAVvF58TYVDlTSgMTbYB1ors24ydhLhLGwvE5VkOvVtn6USmtZYVVAfe2Esd9JjEo4Zg
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 1 April 2012 09:13, Joseph Glanville <joseph.glanville@orionvm.com.au> w=
rote:
> On 31 March 2012 05:08, Joseph Glanville
> <joseph.glanville@orionvm.com.au> wrote:
>> On 31 March 2012 01:03, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>>> Joseph Glanville writes ("[RFC] Shutdown event script for xl toolstack"=
):
>>>> Previously I had a series of out of tree patches to xend that added a
>>>> shutdown event callback on domain death that would call a script with
>>>> the reason why the domain shutdown.
>>>> Basically analagous to this:
>>>> /etc/xen/scripts/shutdown-event $event $domname $domid
>>>
>>> I think this is a good idea, although it shouldn't be enabled by
>>> default and I don't see the need to provide an example script.
>>
>> Yep fair enough, agree on both points.
>>
>>>
>>>> My general idea is to add a config option for a path to an event
>>>> handler script:
>>>> on_shutdown_event =3D "/etc/xen/scripts/shutdown-event"
>>>
>>> Yes, this is good. =A0Shouldn't the argument be a string list so that
>>> you can specify all the arguments to exec() ? =A0Will the script inherit
>>> the domid or name in an environment variable ?
>>>
>>> You need to document this fully I think, in docs/man/xl.cfg.pod.5.
>>
>> I didn't think of this but you make a very valid point, especially
>> considering we can use environment vars to provide the domain data as
>> you suggested.
>>
>>>
>>> It would also be good for the script to be able to give instructions
>>> to the daemonic xl, for example to cause the daemonic xl to neither
>>> reboot nor preserve the domain. =A0So if you wanted your domain to get a
>>> different config when it reboots, you write a hook script which
>>> destroys the previous domain and starts the new one by hand.
>>
>> Hmm this is interesting and something I hadn't really thought of impleme=
nting.
>> Something that uses the return code of the script I think would be appro=
priate.
>>
>>>
>>>> Create the event during handle_domain_death in xl_cmdimpl.c and fire
>>>> the script once shutdown reason and action has been parsed.
>>>
>>> When you say "create the event" what do you mean ?
>>
>> I think "create" was most definitely incorrect terminology. :)
>> "catch" probably would have been a much better way of terming it now I
>> look at it.
>>
>>>
>>>> I implemented a hacky version to illustrate my point but I would like
>>>> some advice on how to do this properly and what tools/framework within
>>>> libxl I could leverage to make it cleaner.
>>>
>>> This is going in the right direction. =A0I'll comment in more detail
>>> below.
>>>
>>>> A quick overview of the following would help immensely:
>>>> Where to add in a new config option and what steps it goes through to
>>>> get to libxl_domain_config.
>>>
>>> This hook script functionality should be part of xl, not part of
>>> libxl, so arguably you shouldn't add it to libxl_domain_config.
>>>
>>> Indeed I think it's arguably a mistake that the on_{poweroff,...}
>>> items are in libxl_domain_config rather than in something provided in
>>> xl.
>>>
>>> The config parsing is done in parse_config_data.
>>
>> Cheers will take a look.
>>
>>>
>>>> How to exec an external script safely, can I use usual fork/exec or
>>>> should I be using libxl__exec or libxl_spawn*?
>>>
>>> In xl I think you should use fork/exec. =A0You may not use any functions
>>> libxl__* as they are private for libxl.
>>
>> Thanks for clarifying, I also read the naming convention docs this
>> morning which cleared this up too.
>>
>>>
>>>> Best place/way to get the event data, atm handle_domain_death looks
>>>> like an easy target but there might be more elegant ways..
>>>
>>> handle_domain_death is called in only one place, the event loop in the
>>> daemonic xl. =A0And yes, it seems like the right place to do this.
>>>
>>>> diff --git a/tools/hotplug/Linux/shutdown-event
>>>> b/tools/hotplug/Linux/shutdown-event
>>>
>>> As I say I don't think we need an example like this.
>>>
>>> Also do we think asking the user to handle this with a switch in their
>>> event script is really better than providing four separate config
>>> options for separate commands ? =A0Doing the latter will make the
>>> scripts simpler, which is good because they'll be very annoying to
>>> debug.
>>
>> Agreed, that is a much better approach.
>>
>>>
>>>> + =A0 =A0char event_name[10];
>>>> + =A0 =A0char event_cmd[100];
>>>>
>>>> =A0 =A0 switch (info->shutdown_reason) {
>>>> =A0 =A0 case SHUTDOWN_poweroff:
>>>> =A0 =A0 =A0 =A0 action =3D d_config->on_poweroff;
>>>> + =A0 =A0 =A0 =A0strcpy(event_name,"poweroff");
>>>
>>> Surely event_name should be
>>> =A0const char *event_name;
>>> and then you can do
>>> =A0event_name =3D "poweroff";
>>>
>>> But this goes away if you have four separate hook script config
>>> options.
>>>
>>>> + =A0 =A0snprintf(event_cmd, 100, SHUTDOWN_EVENT_SCRIPT, event_name,
>>>> d_config->c_info.name, domid);
>>>> + =A0 =A0ret =3D system(event_cmd);
>>>
>>> This part needs serious work. =A0We need firstly to define an
>>> interface. =A0And, I don't really like system(). =A0You should be using
>>> fork/exec.
>>
>> Yep, now that has been clarified I will work on something cleaner.
>> I think taking the array of string approach in the config file and
>> then parsing that array verbatim as the args to exec is a great idea.
>>
>>>
>>> Thanks,
>>> Ian.
>>
>> I will refactor this into a v1 patch after I work out the config file
>> stuff, sensible script interface and return values etc.
>>
>> Thanks for all of your help!
>>
>> Joseph.
>>
>> --
>> Founder | Director | VP Research
>> Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 =
56
>> 99 52 | Mobile: 0428 754 846
>
> Hi Ian,
>
> I have a few more questions.
>
> As I have become more acquainted with the codebase I can see the line
> between libxl and xl quite clearly.
> However the config file territory seems somewhat ambiguous.
> Domain configuration is stored in libxl_domain_config which is a part
> of libxl but there isn't currently a structure for data that is
> private to xl, that is xl daemon or utility specific configuration.
> Is it considered bad form to add a configuration variable to
> libxl_domain_config that only xl will benefit from? if so what is the
> best course of action here?
> I could create another structure for private data but I feel seeking
> guidance on this as prudent.
>
> In the meantime I had added it to libxl_domain_config but I intend to
> have found/made a cleaner solution before submitting the patch for
> inclusion.
>
> In terms of interface I have come up with what I think is inherently
> simple and reliable.
> The shutdown_event_handler is executed with DOM_ID, DOM_NAME, ACTION
> and REASON in it's environment.
> The return code stipulates what action xl will then take, in
> correspondence with the LIBXL_ACTION_ON_SHUTDOWN* counterparts.
>
> I am yet to document this in the xl.cfg.pod file, I will do so in the
> next revision along with adding support for arguments - once we have
> where we are going to store them sorted out at least.
> Patch is only compile tested at this time, I am away from my testing
> environment atm.
>
> Thanks in advance and kind regards,
> Joseph.
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6b69030..b3e5fb1 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -370,6 +370,8 @@ typedef struct {
> =A0 =A0 libxl_action_on_shutdown on_reboot;
> =A0 =A0 libxl_action_on_shutdown on_watchdog;
> =A0 =A0 libxl_action_on_shutdown on_crash;
> +
> + =A0 =A0char *shutdown_event_handler;
> =A0} libxl_domain_config;
> =A0char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config =
*p);
>
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 1d59b89..1096f23 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -664,6 +664,10 @@ static void parse_config_data(const char
> *configfile_filename_report,
> =A0 =A0 =A0 =A0 exit(1);
> =A0 =A0 }
>
> + =A0 =A0if (xlu_cfg_replace_string (config, "shutdown_event_handler",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&d_config->shutd=
own_event_handler, 0))
> + =A0 =A0 =A0 =A0d_config->shutdown_event_handler =3D NULL;
> +
> =A0 =A0 /* libxl_get_required_shadow_memory() must be called after final =
values
> =A0 =A0 =A0* (default or specified) for vcpus and memory are set, because=
 the
> =A0 =A0 =A0* calculation depends on those values. */
> @@ -1206,6 +1210,63 @@ skip_vfb:
> =A0 =A0 xlu_cfg_destroy(config);
> =A0}
>
> +static int xl_exec(const char *arg0, char **args, char **envp,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 useconds_t timeout)
> +{
> + =A0 =A0int status;
> + =A0 =A0useconds_t sleep_time =3D 10, wait_time =3D 0;
> + =A0 =A0pid_t child_pid, wpid;
> +
> + =A0 =A0child_pid =3D fork();
> + =A0 =A0if (child_pid < 0) {
> + =A0 =A0 =A0 =A0LOG("Failed to fork in xl_exec");
> + =A0 =A0 =A0 =A0exit(-1);
> + =A0 =A0} else if (child_pid =3D=3D 0) {
> + =A0 =A0 =A0 =A0execvpe(arg0,args,envp);
> + =A0 =A0} else {
> + =A0 =A0 =A0 =A0do {
> + =A0 =A0 =A0 =A0 =A0 =A0wpid =3D waitpid(child_pid, &status, WNOHANG);
> + =A0 =A0 =A0 =A0 =A0 =A0if (wpid =3D=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (wait_time < timeout) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usleep(sleep_time);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wait_time +=3D sleep_time;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kill(child_pid, SIGKILL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 =A0} while (wpid =3D=3D 0 && wait_time <=3D timeout);
> +
> + =A0 =A0 =A0 =A0if (WIFSIGNALED(status)) {
> + =A0 =A0 =A0 =A0 =A0 =A0return WEXITSTATUS(status);
> + =A0 =A0 =A0 =A0}
> + =A0 =A0}
> + =A0 =A0return WTERMSIG(status);
> +}

Ahh I fumbled it. Obviously WTERMSIG and WEXITSTATUS should be
reversed here. No idea how I missed this on my last glance over.

> +
> +static int user_shutdown_action(libxl_domain_config *d_config, uint32_t =
domid,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int action, unsigned sh=
utdown_reason)
> +{
> + =A0 =A0int ret;
> + =A0 =A0const char* arg0 =3D d_config->shutdown_event_handler;
> + =A0 =A0char* argv[] =3D {NULL};
> + =A0 =A0char* envp[4];
> + =A0 =A0useconds_t timeout =3D 1000;
> +
> + =A0 =A0asprintf(&envp[0],"DOM_ID=3D%d", domid);
> + =A0 =A0asprintf(&envp[1],"DOM_NAME=3D%s", d_config->c_info.name);
> + =A0 =A0asprintf(&envp[2],"ACTION=3D%d", action);
> + =A0 =A0asprintf(&envp[3],"REASON=3D%u", shutdown_reason);
> + =A0 =A0envp[4] =3D NULL;
> +
> + =A0 =A0ret =3D xl_exec(arg0,argv,envp,timeout);
> +
> + =A0 =A0if ((ret < 0) || ( ret > 6)) {
> + =A0 =A0 =A0 =A0LOG("Invalid shutdown action requested: %d, ignoring",re=
t);
> + =A0 =A0 =A0 =A0return action;
> + =A0 =A0}
> + =A0 =A0return ret;
> +}
> +
> =A0/* Returns 1 if domain should be restarted,
> =A0* 2 if domain should be renamed then restarted, or 0 */
> =A0static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
> @@ -1237,6 +1298,10 @@ static int handle_domain_death(libxl_ctx *ctx,
> uint32_t domid,
> =A0 =A0 =A0 =A0 action =3D LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
> =A0 =A0 }
>
> + =A0 =A0 =A0 if (d_config->shutdown_event_handler)
> + =A0 =A0 =A0 =A0action =3D user_shutdown_action(d_config, domid, action,
> +
> event->u.domain_shutdown.shutdown_reason);
> +
> =A0 =A0 LOG("Action for shutdown reason code %d is %s",
> =A0 =A0 =A0 =A0 event->u.domain_shutdown.shutdown_reason,
> =A0 =A0 =A0 =A0 action_on_shutdown_names[action])
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
> 99 52 | Mobile: 0428 754 846



-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 01:36:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 01:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SE9hi-00007U-1G; Sun, 01 Apr 2012 01:35:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreww591@gmail.com>) id 1SE9hg-00007F-Hq
	for xen-devel@lists.xen.org; Sun, 01 Apr 2012 01:35:36 +0000
Received: from [85.158.143.35:62166] by server-1.bemta-4.messagelabs.com id
	D1/60-20925-7E0B77F4; Sun, 01 Apr 2012 01:35:35 +0000
X-Env-Sender: andreww591@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333244133!6823554!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20290 invoked from network); 1 Apr 2012 01:35:34 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 01:35:34 -0000
Received: by iafj26 with SMTP id j26so3369651iaf.32
	for <multiple recipients>; Sat, 31 Mar 2012 18:35:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=phqSeFxB1o5fSJkyy1zV5iE9LteJ3XqdT/9yvVGtg/M=;
	b=aRTdq4phMOA1XuWiT5luVkYXoIPKQabr1rb9WmTt1RvZkZIepDTZPWfrIJYdD97dxB
	7v06JGvFYfMPA6jQ7eh7jWogJT1fkNzd72sQsFYlvsNjbdDTNDQttSSvQ4y8HjQrS0d6
	Ezp1pMo5G5pk6Lh3GL0r+E8qR3HrxqnVlx+pb7GA742rYcKXBDyI6sVycfyAfq9wDpju
	ae12NrdstK6rdC1xzf/VAxUTzqMIBjwIHbKLzegCnyf3R3koBu6DycrzAhZiCU+mYXRo
	iu2YvFd2n3ZTte5CQ091Cesqlwk8u/kFLKwyOg9SZOSxcSjKXUvVwCXSES0PS7wC6krw
	AR3w==
MIME-Version: 1.0
Received: by 10.50.193.234 with SMTP id hr10mr2258385igc.14.1333244132682;
	Sat, 31 Mar 2012 18:35:32 -0700 (PDT)
Received: by 10.231.133.201 with HTTP; Sat, 31 Mar 2012 18:35:32 -0700 (PDT)
In-Reply-To: <4F7596CE.6000103@xen.org>
References: <4F74593B.9000003@xen.org>
	<CAD-qYGr6xqRoH+evek2iRz0G5gThWbrztZf=EuLU01DAkBdMfQ@mail.gmail.com>
	<4F7596CE.6000103@xen.org>
Date: Sat, 31 Mar 2012 19:35:32 -0600
Message-ID: <CAD-qYGoPHihKG5ry04Dyhkmd7984mEP0T9VUQp-oeLYHwU9-nA@mail.gmail.com>
From: Andrew Warkentin <andreww591@gmail.com>
To: xen-devel@lists.xen.org
Cc: xci-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xci-devel] Archiving XCI : Request for an
 Archivation Review for the XCI project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3/30/12, Lars Kurth <lars.kurth@xen.org> wrote:
> Andrew,
>
> that is good news. I see a number of options going forward, which really
> depends on your preference and also what committers and maintainers in
> the community think:
> 1) OpenXCI as a new project hosted on Xen.org - starting as an
> incubation project as per http://www.xen.org/projects/governance.html
> and archive the old one. What you describe sounds sufficiently different.
>
> 2) OpenXCI as a separate project: Xen.org can help you promoting the
> project in various ways
>
> If you want and have a bit more clarity on what you want to do and how
> you want to achieve things, I could arrange a call with you and walk you
> through the details.
>

I'm not quite sure which would be a better idea. I don't really have
much on the OpenXCI SourceForge project (just the Mercurial repository
for the graphics and input servers, as well as a tarball with the
corresponding qemu patches), so it might be easier to move it to
xen.org now rather than later. I do have a pretty good idea of what I
want OpenXCI to be - a configurable, high-performance multi-boot
alternative with good support for graphics passthrough, using a
similar architecture to XenClient (but using direct GPU passthrough
for one domain and either a "reverse graphics adapter" or a VNC
connection to display other domains, possibly with some kind of
support for 3D on non-passthrough domains using virtual GPUs being
added later).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 01:36:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 01:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SE9hi-00007U-1G; Sun, 01 Apr 2012 01:35:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreww591@gmail.com>) id 1SE9hg-00007F-Hq
	for xen-devel@lists.xen.org; Sun, 01 Apr 2012 01:35:36 +0000
Received: from [85.158.143.35:62166] by server-1.bemta-4.messagelabs.com id
	D1/60-20925-7E0B77F4; Sun, 01 Apr 2012 01:35:35 +0000
X-Env-Sender: andreww591@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333244133!6823554!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20290 invoked from network); 1 Apr 2012 01:35:34 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 01:35:34 -0000
Received: by iafj26 with SMTP id j26so3369651iaf.32
	for <multiple recipients>; Sat, 31 Mar 2012 18:35:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=phqSeFxB1o5fSJkyy1zV5iE9LteJ3XqdT/9yvVGtg/M=;
	b=aRTdq4phMOA1XuWiT5luVkYXoIPKQabr1rb9WmTt1RvZkZIepDTZPWfrIJYdD97dxB
	7v06JGvFYfMPA6jQ7eh7jWogJT1fkNzd72sQsFYlvsNjbdDTNDQttSSvQ4y8HjQrS0d6
	Ezp1pMo5G5pk6Lh3GL0r+E8qR3HrxqnVlx+pb7GA742rYcKXBDyI6sVycfyAfq9wDpju
	ae12NrdstK6rdC1xzf/VAxUTzqMIBjwIHbKLzegCnyf3R3koBu6DycrzAhZiCU+mYXRo
	iu2YvFd2n3ZTte5CQ091Cesqlwk8u/kFLKwyOg9SZOSxcSjKXUvVwCXSES0PS7wC6krw
	AR3w==
MIME-Version: 1.0
Received: by 10.50.193.234 with SMTP id hr10mr2258385igc.14.1333244132682;
	Sat, 31 Mar 2012 18:35:32 -0700 (PDT)
Received: by 10.231.133.201 with HTTP; Sat, 31 Mar 2012 18:35:32 -0700 (PDT)
In-Reply-To: <4F7596CE.6000103@xen.org>
References: <4F74593B.9000003@xen.org>
	<CAD-qYGr6xqRoH+evek2iRz0G5gThWbrztZf=EuLU01DAkBdMfQ@mail.gmail.com>
	<4F7596CE.6000103@xen.org>
Date: Sat, 31 Mar 2012 19:35:32 -0600
Message-ID: <CAD-qYGoPHihKG5ry04Dyhkmd7984mEP0T9VUQp-oeLYHwU9-nA@mail.gmail.com>
From: Andrew Warkentin <andreww591@gmail.com>
To: xen-devel@lists.xen.org
Cc: xci-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xci-devel] Archiving XCI : Request for an
 Archivation Review for the XCI project
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3/30/12, Lars Kurth <lars.kurth@xen.org> wrote:
> Andrew,
>
> that is good news. I see a number of options going forward, which really
> depends on your preference and also what committers and maintainers in
> the community think:
> 1) OpenXCI as a new project hosted on Xen.org - starting as an
> incubation project as per http://www.xen.org/projects/governance.html
> and archive the old one. What you describe sounds sufficiently different.
>
> 2) OpenXCI as a separate project: Xen.org can help you promoting the
> project in various ways
>
> If you want and have a bit more clarity on what you want to do and how
> you want to achieve things, I could arrange a call with you and walk you
> through the details.
>

I'm not quite sure which would be a better idea. I don't really have
much on the OpenXCI SourceForge project (just the Mercurial repository
for the graphics and input servers, as well as a tarball with the
corresponding qemu patches), so it might be easier to move it to
xen.org now rather than later. I do have a pretty good idea of what I
want OpenXCI to be - a configurable, high-performance multi-boot
alternative with good support for graphics passthrough, using a
similar architecture to XenClient (but using direct GPU passthrough
for one domain and either a "reverse graphics adapter" or a VNC
connection to display other domains, possibly with some kind of
support for 3D on non-passthrough domains using virtual GPUs being
added later).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 01:59:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 01:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEA49-0000KR-0q; Sun, 01 Apr 2012 01:58:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEA47-0000KL-BB
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 01:58:47 +0000
Received: from [85.158.143.35:64027] by server-3.bemta-4.messagelabs.com id
	52/E0-05853-656B77F4; Sun, 01 Apr 2012 01:58:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333245525!14590520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17058 invoked from network); 1 Apr 2012 01:58:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 01:58:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,350,1330905600"; d="scan'208";a="11705517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 01:58:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 02:58:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEA44-0002l1-Gg;
	Sun, 01 Apr 2012 01:58:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEA44-0002or-9e;
	Sun, 01 Apr 2012 02:58:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12532-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 02:58:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12532: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12532 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12532/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 01:59:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 01:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEA49-0000KR-0q; Sun, 01 Apr 2012 01:58:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEA47-0000KL-BB
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 01:58:47 +0000
Received: from [85.158.143.35:64027] by server-3.bemta-4.messagelabs.com id
	52/E0-05853-656B77F4; Sun, 01 Apr 2012 01:58:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333245525!14590520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17058 invoked from network); 1 Apr 2012 01:58:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 01:58:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,350,1330905600"; d="scan'208";a="11705517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 01:58:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 02:58:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEA44-0002l1-Gg;
	Sun, 01 Apr 2012 01:58:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEA44-0002or-9e;
	Sun, 01 Apr 2012 02:58:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12532-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 02:58:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12532: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12532 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12532/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 04:45:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 04:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SECec-00012S-Ex; Sun, 01 Apr 2012 04:44:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SECea-00012N-Mp
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 04:44:36 +0000
Received: from [85.158.138.51:54915] by server-10.bemta-3.messagelabs.com id
	B0/86-15637-33DD77F4; Sun, 01 Apr 2012 04:44:35 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-174.messagelabs.com!1333255472!20234012!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21153 invoked from network); 1 Apr 2012 04:44:35 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Apr 2012 04:44:35 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SECeS-0005xT-Lz
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 14:44:28 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 1 Apr 2012 14:44:28 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Sun, 1 Apr 2012 14:44:28 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: qemu reverse vnc connection
Thread-Index: Ac0PwTdj9AHUgRtUT5qsKTdevMW/oA==
Date: Sun, 1 Apr 2012 04:44:24 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Apr 2012 04:44:28.0433 (UTC)
	FILETIME=[1F26F010:01CD0FC2]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] qemu reverse vnc connection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I was looking at vnc.c to see what would be involved in making a reverse VNC connection (vnc server connects to the client), and it looks possible but I also wondered if there was any reason why libvncserver couldn't be used instead? Both qemu-dm and libvncserver appear to be licensed under GPL although I haven't checked what version.

I've never figured out whether it's qemu's vnc implementation or VNCViewer but one of them seems pretty buggy - freezing and requiring frequent refreshes under some circumstances, and occasionally not liking resolution changes.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 04:45:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 04:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SECec-00012S-Ex; Sun, 01 Apr 2012 04:44:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SECea-00012N-Mp
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 04:44:36 +0000
Received: from [85.158.138.51:54915] by server-10.bemta-3.messagelabs.com id
	B0/86-15637-33DD77F4; Sun, 01 Apr 2012 04:44:35 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-174.messagelabs.com!1333255472!20234012!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21153 invoked from network); 1 Apr 2012 04:44:35 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Apr 2012 04:44:35 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SECeS-0005xT-Lz
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 14:44:28 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 1 Apr 2012 14:44:28 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Sun, 1 Apr 2012 14:44:28 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: qemu reverse vnc connection
Thread-Index: Ac0PwTdj9AHUgRtUT5qsKTdevMW/oA==
Date: Sun, 1 Apr 2012 04:44:24 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Apr 2012 04:44:28.0433 (UTC)
	FILETIME=[1F26F010:01CD0FC2]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] qemu reverse vnc connection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I was looking at vnc.c to see what would be involved in making a reverse VNC connection (vnc server connects to the client), and it looks possible but I also wondered if there was any reason why libvncserver couldn't be used instead? Both qemu-dm and libvncserver appear to be licensed under GPL although I haven't checked what version.

I've never figured out whether it's qemu's vnc implementation or VNCViewer but one of them seems pretty buggy - freezing and requiring frequent refreshes under some circumstances, and occasionally not liking resolution changes.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 05:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 05:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEDRF-0001St-GR; Sun, 01 Apr 2012 05:34:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mohitdhingras@gmail.com>) id 1SEDRE-0001So-0e
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 05:34:52 +0000
Received: from [193.109.254.147:17438] by server-8.bemta-14.messagelabs.com id
	A9/8B-23244-BF8E77F4; Sun, 01 Apr 2012 05:34:51 +0000
X-Env-Sender: mohitdhingras@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333258490!2885391!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23390 invoked from network); 1 Apr 2012 05:34:50 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 05:34:50 -0000
Received: by wgbdr12 with SMTP id dr12so1484170wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 31 Mar 2012 22:34:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=5GQumKi3qx80mtMvzYzTkDr+bycH9erLriAlv4WdWxQ=;
	b=rC7naitmhgZ09qkGI/WAGBHoD+x9BlXqLIbI/HCj/tnVY3vaStdbVQT3GxNnyowFVH
	nAn6QvUPoDpMgyXZZyN5LyraOMt3XMHYIDlPtXjeAxKlbGuNv7o5R3w2+mB6klWnbcyk
	v++LiwrmsopdulLj1HjlTjWhrxoOUYSjNmm+Qm4H4kXisTjdSmJAB2kWRDXk+YY7B4cy
	I317e/LjVHLeq52aLv/NTNcMQfMYT4k4D1+5pTxiXoM2naMD/itzNp6cxq2KnYSKKxgC
	3om/9/7/a7NnnmxlmgyoP0pFSzzgDu2mltvoD/cJ9SqlJ5L4SupDiI6US2ZEyId//IQM
	zq7w==
Received: by 10.180.8.231 with SMTP id u7mr12171506wia.9.1333258489673; Sat,
	31 Mar 2012 22:34:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.105.170 with HTTP; Sat, 31 Mar 2012 22:34:29 -0700 (PDT)
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sun, 1 Apr 2012 11:04:29 +0530
Message-ID: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7656275722579576774=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7656275722579576774==
Content-Type: multipart/alternative; boundary=f46d044304d0abb6e404bc976e9a

--f46d044304d0abb6e404bc976e9a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

*Hello All,*

I am a newbie to Linux and Xen. I tried compiling Xen Source code (I want
to make some changes and see how it works), but it failed on my system as
it couldn't find gnu-stubs32.h. Later, on looking at Makefile, I figured
out that for x86_64, it is not yet supported !!

Then I installed "32-bit" emulation utility for x86-64.
and I tried compiling by "linux32" terminal.

Here, I get following error :
make[5]: Entering directory `/srv/xen-4.1.2/tools/blktap/drivers'
gcc  -O2 -fomit-frame-pointer -m32 -march=3Di686 -fno-strict-aliasing
-std=3Dgnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement  -D__XEN_TOOLS__ -MMD -MF .block-qcow2.o.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror
-Wno-unused -I../lib
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/libxc
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/include
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/xenstore
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/include -I
../../libaio/src -I ../../memshr -D_GNU_SOURCE -DUSE_GCRYPT -DMEMSHR -c -o
block-qcow2.o block-qcow2.c
cc1: warnings being treated as errors
block-qcow2.c: In function =91bdrv_pread=92:
block-qcow2.c:238:4: error: format =91%#llx=92 expects type =91long long un=
signed
int=92, but argument 5 has type =91__off_t=92
make[5]: *** [block-qcow2.o] Error 1


block-qcow2.c
---------------------------------------------------------------------------=
---------------------------------------

static int bdrv_pread(int fd, int64_t offset, void *buf, int count)
{
        int ret;

        if (lseek(fd, offset, SEEK_SET) =3D=3D -1) {
                DPRINTF("bdrv_pread failed seek (%#"PRIx64").\n", offset);
                return -1;
        }

        ret =3D  read(fd, buf, count);
        if (ret < 0) {
                if (lseek(fd, 0, SEEK_END) >=3D offset) {
                        DPRINTF("bdrv_pread read failed (%#"PRIx64", END =
=3D
%#"PRIx64").\n",
                                        offset, lseek(fd, 0, SEEK_END));
                        return -1;
                }

                /* Read beyond end of file. Reading zeros. */
                memset(buf, 0, count);
                ret =3D count;
        } else if (ret < count) {
                /* Read beyond end of file. Filling up with zeros. */
                memset(buf + ret, 0, count - ret);
                ret =3D count;
        }
        return ret;
}
---------------------------------------------------------------------------=
---------------------------------------------


Currently, I have following configuration
cadlab:~/Downloads/xen-4.1.2 # uname -a
Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 +0100 x86_64
x86_64 x86_64 GNU/Linux

And, can I contribute towards 64-bit compatibility on Xen source code build=
.
*
----------------------------
Thanks & Regards
Mohit Dhingra
*

--f46d044304d0abb6e404bc976e9a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<b>Hello All,</b><br><br>I am a newbie to Linux and Xen. I tried=20
compiling Xen Source code (I want to make some changes and see how it=20
works), but it failed on my system as it couldn&#39;t find gnu-stubs32.h.=
=20
Later, on looking at Makefile, I figured out that for x86_64, it is not=20
yet supported !! <br>
<br>Then I installed &quot;32-bit&quot; emulation utility for x86-64.<br>an=
d I tried compiling by &quot;linux32&quot; terminal. <br><br>Here, I get fo=
llowing error :<br>make[5]: Entering directory `/srv/xen-4.1.2/tools/blktap=
/drivers&#39;<br>

gcc=A0 -O2 -fomit-frame-pointer -m32 -march=3Di686 -fno-strict-aliasing -st=
d=3Dgnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-s=
tatement=A0 -D__XEN_TOOLS__ -MMD -MF .block-qcow2.o.d=A0 -D_LARGEFILE_SOURC=
E -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -Wno-unused -I../l=
ib -I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/libxc -I/srv/xen-4.=
1.2/tools/blktap/drivers/../../../tools/include -I/srv/xen-4.1.2/tools/blkt=
ap/drivers/../../../tools/xenstore -I/srv/xen-4.1.2/tools/blktap/drivers/..=
/../../tools/include -I ../../libaio/src -I ../../memshr -D_GNU_SOURCE -DUS=
E_GCRYPT -DMEMSHR -c -o block-qcow2.o block-qcow2.c<br>

cc1: warnings being treated as errors<br>block-qcow2.c: In function =91bdrv=
_pread=92:<br>block-qcow2.c:238:4: error: format =91%#llx=92 expects type =
=91long long unsigned int=92, but argument 5 has type =91__off_t=92<br>make=
[5]: *** [block-qcow2.o] Error 1<br>

<br><br>block-qcow2.c<br>--------------------------------------------------=
----------------------------------------------------------------<br><br>sta=
tic int bdrv_pread(int fd, int64_t offset, void *buf, int count)<br>{<br>

=A0=A0=A0=A0=A0=A0=A0 int ret;<br><br>=A0=A0=A0=A0=A0=A0=A0 if (lseek(fd, o=
ffset, SEEK_SET) =3D=3D -1) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 DPRINTF(&quot;bdrv_pread failed seek (%#&quot;PRIx64&quot;).\n&quot;, o=
ffset);<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return -1;<br>=A0=
=A0=A0=A0=A0=A0=A0 }<br><br>

=A0=A0=A0=A0=A0=A0=A0 ret =3D=A0 read(fd, buf, count);<br>=A0=A0=A0=A0=A0=
=A0=A0 if (ret &lt; 0) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i=
f (lseek(fd, 0, SEEK_END) &gt;=3D offset) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DPRINTF(&quot;bdrv_pread read fa=
iled (%#&quot;PRIx64&quot;, END =3D %#&quot;PRIx64&quot;).\n&quot;,<br>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 offset, lseek(fd, 0, SEEK_END));=
<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 r=
eturn -1;<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }<br><br>=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Read beyond end of file. Reading=
 zeros. */<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 memset(buf, 0, =
count);<br>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ret =3D count;<br>=A0=A0=A0=
=A0=A0=A0=A0 } else if (ret &lt; count) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 /* Read beyond end of file. Filling up with zeros. */<br>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 memset(buf + ret, 0, count - =
ret);<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ret =3D count;<br>

=A0=A0=A0=A0=A0=A0=A0 }<br>=A0=A0=A0=A0=A0=A0=A0 return ret;<br>}<br>------=
---------------------------------------------------------------------------=
---------------------------------------<br><br>

<br>Currently, I have following configuration<br>cadlab:~/Downloads/xen-4.1=
.2 # uname -a<br>Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 =
+0100 x86_64 x86_64 x86_64 GNU/Linux<br><br>And, can I contribute towards 6=
4-bit compatibility on Xen source code build.<br>


<b><div><b>---------------------------- <br></b></div>Thanks &amp; Regards<=
br><font color=3D"#888888">Mohit Dhingra=A0<br></font></b><br>

--f46d044304d0abb6e404bc976e9a--


--===============7656275722579576774==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7656275722579576774==--


From xen-devel-bounces@lists.xen.org Sun Apr 01 05:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 05:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEDRF-0001St-GR; Sun, 01 Apr 2012 05:34:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mohitdhingras@gmail.com>) id 1SEDRE-0001So-0e
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 05:34:52 +0000
Received: from [193.109.254.147:17438] by server-8.bemta-14.messagelabs.com id
	A9/8B-23244-BF8E77F4; Sun, 01 Apr 2012 05:34:51 +0000
X-Env-Sender: mohitdhingras@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333258490!2885391!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23390 invoked from network); 1 Apr 2012 05:34:50 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 05:34:50 -0000
Received: by wgbdr12 with SMTP id dr12so1484170wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 31 Mar 2012 22:34:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=5GQumKi3qx80mtMvzYzTkDr+bycH9erLriAlv4WdWxQ=;
	b=rC7naitmhgZ09qkGI/WAGBHoD+x9BlXqLIbI/HCj/tnVY3vaStdbVQT3GxNnyowFVH
	nAn6QvUPoDpMgyXZZyN5LyraOMt3XMHYIDlPtXjeAxKlbGuNv7o5R3w2+mB6klWnbcyk
	v++LiwrmsopdulLj1HjlTjWhrxoOUYSjNmm+Qm4H4kXisTjdSmJAB2kWRDXk+YY7B4cy
	I317e/LjVHLeq52aLv/NTNcMQfMYT4k4D1+5pTxiXoM2naMD/itzNp6cxq2KnYSKKxgC
	3om/9/7/a7NnnmxlmgyoP0pFSzzgDu2mltvoD/cJ9SqlJ5L4SupDiI6US2ZEyId//IQM
	zq7w==
Received: by 10.180.8.231 with SMTP id u7mr12171506wia.9.1333258489673; Sat,
	31 Mar 2012 22:34:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.105.170 with HTTP; Sat, 31 Mar 2012 22:34:29 -0700 (PDT)
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sun, 1 Apr 2012 11:04:29 +0530
Message-ID: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7656275722579576774=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7656275722579576774==
Content-Type: multipart/alternative; boundary=f46d044304d0abb6e404bc976e9a

--f46d044304d0abb6e404bc976e9a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

*Hello All,*

I am a newbie to Linux and Xen. I tried compiling Xen Source code (I want
to make some changes and see how it works), but it failed on my system as
it couldn't find gnu-stubs32.h. Later, on looking at Makefile, I figured
out that for x86_64, it is not yet supported !!

Then I installed "32-bit" emulation utility for x86-64.
and I tried compiling by "linux32" terminal.

Here, I get following error :
make[5]: Entering directory `/srv/xen-4.1.2/tools/blktap/drivers'
gcc  -O2 -fomit-frame-pointer -m32 -march=3Di686 -fno-strict-aliasing
-std=3Dgnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement  -D__XEN_TOOLS__ -MMD -MF .block-qcow2.o.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror
-Wno-unused -I../lib
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/libxc
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/include
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/xenstore
-I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/include -I
../../libaio/src -I ../../memshr -D_GNU_SOURCE -DUSE_GCRYPT -DMEMSHR -c -o
block-qcow2.o block-qcow2.c
cc1: warnings being treated as errors
block-qcow2.c: In function =91bdrv_pread=92:
block-qcow2.c:238:4: error: format =91%#llx=92 expects type =91long long un=
signed
int=92, but argument 5 has type =91__off_t=92
make[5]: *** [block-qcow2.o] Error 1


block-qcow2.c
---------------------------------------------------------------------------=
---------------------------------------

static int bdrv_pread(int fd, int64_t offset, void *buf, int count)
{
        int ret;

        if (lseek(fd, offset, SEEK_SET) =3D=3D -1) {
                DPRINTF("bdrv_pread failed seek (%#"PRIx64").\n", offset);
                return -1;
        }

        ret =3D  read(fd, buf, count);
        if (ret < 0) {
                if (lseek(fd, 0, SEEK_END) >=3D offset) {
                        DPRINTF("bdrv_pread read failed (%#"PRIx64", END =
=3D
%#"PRIx64").\n",
                                        offset, lseek(fd, 0, SEEK_END));
                        return -1;
                }

                /* Read beyond end of file. Reading zeros. */
                memset(buf, 0, count);
                ret =3D count;
        } else if (ret < count) {
                /* Read beyond end of file. Filling up with zeros. */
                memset(buf + ret, 0, count - ret);
                ret =3D count;
        }
        return ret;
}
---------------------------------------------------------------------------=
---------------------------------------------


Currently, I have following configuration
cadlab:~/Downloads/xen-4.1.2 # uname -a
Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 +0100 x86_64
x86_64 x86_64 GNU/Linux

And, can I contribute towards 64-bit compatibility on Xen source code build=
.
*
----------------------------
Thanks & Regards
Mohit Dhingra
*

--f46d044304d0abb6e404bc976e9a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<b>Hello All,</b><br><br>I am a newbie to Linux and Xen. I tried=20
compiling Xen Source code (I want to make some changes and see how it=20
works), but it failed on my system as it couldn&#39;t find gnu-stubs32.h.=
=20
Later, on looking at Makefile, I figured out that for x86_64, it is not=20
yet supported !! <br>
<br>Then I installed &quot;32-bit&quot; emulation utility for x86-64.<br>an=
d I tried compiling by &quot;linux32&quot; terminal. <br><br>Here, I get fo=
llowing error :<br>make[5]: Entering directory `/srv/xen-4.1.2/tools/blktap=
/drivers&#39;<br>

gcc=A0 -O2 -fomit-frame-pointer -m32 -march=3Di686 -fno-strict-aliasing -st=
d=3Dgnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-s=
tatement=A0 -D__XEN_TOOLS__ -MMD -MF .block-qcow2.o.d=A0 -D_LARGEFILE_SOURC=
E -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -Wno-unused -I../l=
ib -I/srv/xen-4.1.2/tools/blktap/drivers/../../../tools/libxc -I/srv/xen-4.=
1.2/tools/blktap/drivers/../../../tools/include -I/srv/xen-4.1.2/tools/blkt=
ap/drivers/../../../tools/xenstore -I/srv/xen-4.1.2/tools/blktap/drivers/..=
/../../tools/include -I ../../libaio/src -I ../../memshr -D_GNU_SOURCE -DUS=
E_GCRYPT -DMEMSHR -c -o block-qcow2.o block-qcow2.c<br>

cc1: warnings being treated as errors<br>block-qcow2.c: In function =91bdrv=
_pread=92:<br>block-qcow2.c:238:4: error: format =91%#llx=92 expects type =
=91long long unsigned int=92, but argument 5 has type =91__off_t=92<br>make=
[5]: *** [block-qcow2.o] Error 1<br>

<br><br>block-qcow2.c<br>--------------------------------------------------=
----------------------------------------------------------------<br><br>sta=
tic int bdrv_pread(int fd, int64_t offset, void *buf, int count)<br>{<br>

=A0=A0=A0=A0=A0=A0=A0 int ret;<br><br>=A0=A0=A0=A0=A0=A0=A0 if (lseek(fd, o=
ffset, SEEK_SET) =3D=3D -1) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 DPRINTF(&quot;bdrv_pread failed seek (%#&quot;PRIx64&quot;).\n&quot;, o=
ffset);<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return -1;<br>=A0=
=A0=A0=A0=A0=A0=A0 }<br><br>

=A0=A0=A0=A0=A0=A0=A0 ret =3D=A0 read(fd, buf, count);<br>=A0=A0=A0=A0=A0=
=A0=A0 if (ret &lt; 0) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i=
f (lseek(fd, 0, SEEK_END) &gt;=3D offset) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DPRINTF(&quot;bdrv_pread read fa=
iled (%#&quot;PRIx64&quot;, END =3D %#&quot;PRIx64&quot;).\n&quot;,<br>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 offset, lseek(fd, 0, SEEK_END));=
<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 r=
eturn -1;<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }<br><br>=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Read beyond end of file. Reading=
 zeros. */<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 memset(buf, 0, =
count);<br>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ret =3D count;<br>=A0=A0=A0=
=A0=A0=A0=A0 } else if (ret &lt; count) {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 /* Read beyond end of file. Filling up with zeros. */<br>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 memset(buf + ret, 0, count - =
ret);<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ret =3D count;<br>

=A0=A0=A0=A0=A0=A0=A0 }<br>=A0=A0=A0=A0=A0=A0=A0 return ret;<br>}<br>------=
---------------------------------------------------------------------------=
---------------------------------------<br><br>

<br>Currently, I have following configuration<br>cadlab:~/Downloads/xen-4.1=
.2 # uname -a<br>Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 =
+0100 x86_64 x86_64 x86_64 GNU/Linux<br><br>And, can I contribute towards 6=
4-bit compatibility on Xen source code build.<br>


<b><div><b>---------------------------- <br></b></div>Thanks &amp; Regards<=
br><font color=3D"#888888">Mohit Dhingra=A0<br></font></b><br>

--f46d044304d0abb6e404bc976e9a--


--===============7656275722579576774==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7656275722579576774==--


From xen-devel-bounces@lists.xen.org Sun Apr 01 08:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 08:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEGaP-000361-SQ; Sun, 01 Apr 2012 08:56:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEGaO-00035w-Rw
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 08:56:33 +0000
Received: from [193.109.254.147:16010] by server-1.bemta-14.messagelabs.com id
	B5/29-29372-048187F4; Sun, 01 Apr 2012 08:56:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333270591!2843997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25895 invoked from network); 1 Apr 2012 08:56:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 08:56:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,352,1330905600"; d="scan'208";a="11706972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 08:56:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 09:56:30 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEGaL-00053f-R9;
	Sun, 01 Apr 2012 08:56:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEGaL-0008Mh-KP;
	Sun, 01 Apr 2012 09:56:29 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12534-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 09:56:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12534: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12534 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12534/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12529
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12529

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12529 blocked in 12534

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  1088c8557a46
baseline version:
 xen                  1088c8557a46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 08:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 08:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEGaP-000361-SQ; Sun, 01 Apr 2012 08:56:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEGaO-00035w-Rw
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 08:56:33 +0000
Received: from [193.109.254.147:16010] by server-1.bemta-14.messagelabs.com id
	B5/29-29372-048187F4; Sun, 01 Apr 2012 08:56:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333270591!2843997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25895 invoked from network); 1 Apr 2012 08:56:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 08:56:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,352,1330905600"; d="scan'208";a="11706972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 08:56:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 09:56:30 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEGaL-00053f-R9;
	Sun, 01 Apr 2012 08:56:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEGaL-0008Mh-KP;
	Sun, 01 Apr 2012 09:56:29 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12534-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 09:56:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12534: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12534 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12534/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12529
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12529

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12529 blocked in 12534

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  1088c8557a46
baseline version:
 xen                  1088c8557a46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 10:15:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 10:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEHoL-0003WC-3i; Sun, 01 Apr 2012 10:15:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SEHoI-0003W3-UO
	for xen-devel@lists.xen.org; Sun, 01 Apr 2012 10:14:59 +0000
Received: from [85.158.138.51:10656] by server-8.bemta-3.messagelabs.com id
	39/E5-29305-2AA287F4; Sun, 01 Apr 2012 10:14:58 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333275297!20274246!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTA3Njk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8385 invoked from network); 1 Apr 2012 10:14:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Apr 2012 10:14:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 0B983286B;
	Sun,  1 Apr 2012 13:14:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 9F2C9200F0; Sun,  1 Apr 2012 13:14:55 +0300 (EEST)
Date: Sun, 1 Apr 2012 13:14:55 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Casey DeLorme <cdelorme@gmail.com>
Message-ID: <20120401101455.GB12984@reaktio.net>
References: <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com>
	<CAA7N5RZVYcpzHdkdZ2_EY1R8OMGNEbmvrXnFaMFxOM7wrUvLjQ@mail.gmail.com>
	<4F74EA35.4030305@amd.com> <20120331104907.GV12984@reaktio.net>
	<CACC+8CQJxm_s1ZKVOU6PpgzPYiDKC75_sTTYQXBg9w4W81t2Mg@mail.gmail.com>
	<20120331111926.GY12984@reaktio.net>
	<CACC+8CReA_5P8RD3+NNRf0g7VvcrSFxQ=cuYoHq5c0p1p1jvmQ@mail.gmail.com>
	<20120331151104.GZ12984@reaktio.net>
	<CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Teo En Ming \(Zhang Enming\)" <singapore.mr.teo.en.ming@gmail.com>,
	Wei Huang <wei.huang2@amd.com>, Kristijan Le??nik <janez3k@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Tobias Geiger <tobias.geiger@vido.info>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users
	to	Attempt Jean David Techer's Xen 4.2-unstable VGA
	Passthrough	Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 04:08:09PM -0400, Casey DeLorme wrote:
>    Hi Pasi,
>    I can confirm that their GPU Passthrough works with consumer models, t=
hey
>    visited my college and presented a 30 minute demonstration video where
>    they acknowledged this.

Yes, XenClient works with consumer models, like I wrote earlier.
XenServer GPU passthru doesn't.

>    Wei stated that XenClient ahs a "customized ATI component", and I am q=
uite
>    certain he is aware our discussion is about consumer models.
>

Note that some/most of those "customized tweaks" to make XenClient work
are not in upstream Xen repositories and also not in XenServer. =

XenClient is a customized product for some specific chipsets/laptops.

XenClient and XenServer have totally different way of working related to gr=
aphics passthru stuff.

>    XenClient comes with XenDesktop, they market to the on-the-go business=
man
>    so it was designed with laptops in mind, but I am quite sure it would =
run
>    on a tower.
>

I wouldn't count on that.. afaik XenClient has pretty limited hardware supp=
ort/certification.

-- Pasi

>    ~Casey
>    On Sat, Mar 31, 2012 at 11:11 AM, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi=
> wrote:
> =

>      On Sat, Mar 31, 2012 at 04:35:32PM +0200, Kristijan Le??nik wrote:
>      >    Hi,
>      >    does such patch exists?=C2
>      >    i am working on this for quite some time now, and didn't came
>      across any
>      >    ATI patch, only for nvidia
>      >
> =

>      Yes it's available on the xen-devel mailinglist archives,
>      and iirc also on the xen vga passthru wiki page.
> =

>      I think the link/url was already posted to this thread once.
> =

>      >    as i understand that ATI should work out of the box or am i
>      mistaking?=C2
>      >
> =

>      Some ATI cards work as *secondary* without extra patches,
>      but passing them as *primary* requires a patch to make the
>      ATI specific VBIOS stuff work properly.
> =

>      -- Pasi
> =

>      >    Best Regards,
>      >    Kristijan Le=C4*nik
>      >
>      >    On Sat, Mar 31, 2012 at 1:19 PM, Pasi K=C3*rkk=C3*inen
>      <[1][2]pasik@iki.fi>
>      >    wrote:
>      >
>      >      On Sat, Mar 31, 2012 at 01:06:37PM +0200, Kristijan Le??nik
>      wrote:
>      >      > =C2  =C2 Hi,
>      >      > =C2  =C2 i was looking hard to get this thing working, and i
>      somehow
>      >      manage to get
>      >      > =C2  =C2 two ATI graphic card working under Windows 7 and D=
ebian 6
>      DomU,
>      >      > =C2  =C2 what i learn from all this trying, that the most i=
mportant
>      thing
>      >      is the
>      >      > =C2  =C2 motherboard!
>      >      > =C2  =C2 i had i7 860 with VT-D, but it was hard to find wo=
rking
>      VT-D
>      >      motherboard,
>      >      > =C2  =C2 i try gigabyte P55-USB3 with beta bios from gigaby=
te and i
>      got
>      >      working 3D
>      >      > =C2  =C2 drivers for a few minutes and then the DomU would =
crash,
>      >      > =C2  =C2 then i wanted to try asus, but they said that P55 =
chipset
>      doesnt
>      >      support
>      >      > =C2  =C2 VT-D functions, then i look what David uses and ge=
t a MSI
>      >      motherboard and
>      >      > =C2  =C2 its default bios has got VT-D to enable/disable
>      >      > =C2  =C2 currenty i have:
>      >      > =C2  =C2 i7 860
>      >      > =C2  =C2 MSI P55 GD85
>      >      > =C2  =C2 ATI H6670 - working 3D
>      >      > =C2  =C2 ATI H5830 - working 3D
>      >      > =C2  =C2 Debian 6.0, custom kernel 3.1
>      >      > =C2  =C2 Xen 4.2 unstable ( from repo 2. march? )
>      >      > =C2  =C2 Windows 7 64bit - virtual
>      >      > =C2  =C2 no extra patches
>      >      > =C2  =C2 but how i get it to work is strange, if i enable
>      #gfx_passthru=3D1
>      >      then
>      >      > =C2  =C2 virtual machine wont start
>      >      >
>      >
>      >      gfx_passthru=3D1 makes the passthru gfx card primary in the V=
M,
>      >      so you need the additional ATI gfx passthru patch so that the
>      VBIOS
>      >      passthru works.
>      >
>      >      without gfx_passthru=3D1 the virtual emulated gfx is primary.
>      >      -- Pasi
>      >
>      > References
>      >
>      >    Visible links
>      >    1. mailto:[3]pasik@iki.fi
> =

> References
> =

>    Visible links
>    1. mailto:pasik@iki.fi
>    2. mailto:pasik@iki.fi
>    3. mailto:pasik@iki.fi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 10:15:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 10:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEHoL-0003WC-3i; Sun, 01 Apr 2012 10:15:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SEHoI-0003W3-UO
	for xen-devel@lists.xen.org; Sun, 01 Apr 2012 10:14:59 +0000
Received: from [85.158.138.51:10656] by server-8.bemta-3.messagelabs.com id
	39/E5-29305-2AA287F4; Sun, 01 Apr 2012 10:14:58 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333275297!20274246!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTA3Njk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8385 invoked from network); 1 Apr 2012 10:14:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Apr 2012 10:14:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 0B983286B;
	Sun,  1 Apr 2012 13:14:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 9F2C9200F0; Sun,  1 Apr 2012 13:14:55 +0300 (EEST)
Date: Sun, 1 Apr 2012 13:14:55 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Casey DeLorme <cdelorme@gmail.com>
Message-ID: <20120401101455.GB12984@reaktio.net>
References: <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com>
	<CAA7N5RZVYcpzHdkdZ2_EY1R8OMGNEbmvrXnFaMFxOM7wrUvLjQ@mail.gmail.com>
	<4F74EA35.4030305@amd.com> <20120331104907.GV12984@reaktio.net>
	<CACC+8CQJxm_s1ZKVOU6PpgzPYiDKC75_sTTYQXBg9w4W81t2Mg@mail.gmail.com>
	<20120331111926.GY12984@reaktio.net>
	<CACC+8CReA_5P8RD3+NNRf0g7VvcrSFxQ=cuYoHq5c0p1p1jvmQ@mail.gmail.com>
	<20120331151104.GZ12984@reaktio.net>
	<CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Teo En Ming \(Zhang Enming\)" <singapore.mr.teo.en.ming@gmail.com>,
	Wei Huang <wei.huang2@amd.com>, Kristijan Le??nik <janez3k@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Tobias Geiger <tobias.geiger@vido.info>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users
	to	Attempt Jean David Techer's Xen 4.2-unstable VGA
	Passthrough	Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 04:08:09PM -0400, Casey DeLorme wrote:
>    Hi Pasi,
>    I can confirm that their GPU Passthrough works with consumer models, t=
hey
>    visited my college and presented a 30 minute demonstration video where
>    they acknowledged this.

Yes, XenClient works with consumer models, like I wrote earlier.
XenServer GPU passthru doesn't.

>    Wei stated that XenClient ahs a "customized ATI component", and I am q=
uite
>    certain he is aware our discussion is about consumer models.
>

Note that some/most of those "customized tweaks" to make XenClient work
are not in upstream Xen repositories and also not in XenServer. =

XenClient is a customized product for some specific chipsets/laptops.

XenClient and XenServer have totally different way of working related to gr=
aphics passthru stuff.

>    XenClient comes with XenDesktop, they market to the on-the-go business=
man
>    so it was designed with laptops in mind, but I am quite sure it would =
run
>    on a tower.
>

I wouldn't count on that.. afaik XenClient has pretty limited hardware supp=
ort/certification.

-- Pasi

>    ~Casey
>    On Sat, Mar 31, 2012 at 11:11 AM, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi=
> wrote:
> =

>      On Sat, Mar 31, 2012 at 04:35:32PM +0200, Kristijan Le??nik wrote:
>      >    Hi,
>      >    does such patch exists?=C2
>      >    i am working on this for quite some time now, and didn't came
>      across any
>      >    ATI patch, only for nvidia
>      >
> =

>      Yes it's available on the xen-devel mailinglist archives,
>      and iirc also on the xen vga passthru wiki page.
> =

>      I think the link/url was already posted to this thread once.
> =

>      >    as i understand that ATI should work out of the box or am i
>      mistaking?=C2
>      >
> =

>      Some ATI cards work as *secondary* without extra patches,
>      but passing them as *primary* requires a patch to make the
>      ATI specific VBIOS stuff work properly.
> =

>      -- Pasi
> =

>      >    Best Regards,
>      >    Kristijan Le=C4*nik
>      >
>      >    On Sat, Mar 31, 2012 at 1:19 PM, Pasi K=C3*rkk=C3*inen
>      <[1][2]pasik@iki.fi>
>      >    wrote:
>      >
>      >      On Sat, Mar 31, 2012 at 01:06:37PM +0200, Kristijan Le??nik
>      wrote:
>      >      > =C2  =C2 Hi,
>      >      > =C2  =C2 i was looking hard to get this thing working, and i
>      somehow
>      >      manage to get
>      >      > =C2  =C2 two ATI graphic card working under Windows 7 and D=
ebian 6
>      DomU,
>      >      > =C2  =C2 what i learn from all this trying, that the most i=
mportant
>      thing
>      >      is the
>      >      > =C2  =C2 motherboard!
>      >      > =C2  =C2 i had i7 860 with VT-D, but it was hard to find wo=
rking
>      VT-D
>      >      motherboard,
>      >      > =C2  =C2 i try gigabyte P55-USB3 with beta bios from gigaby=
te and i
>      got
>      >      working 3D
>      >      > =C2  =C2 drivers for a few minutes and then the DomU would =
crash,
>      >      > =C2  =C2 then i wanted to try asus, but they said that P55 =
chipset
>      doesnt
>      >      support
>      >      > =C2  =C2 VT-D functions, then i look what David uses and ge=
t a MSI
>      >      motherboard and
>      >      > =C2  =C2 its default bios has got VT-D to enable/disable
>      >      > =C2  =C2 currenty i have:
>      >      > =C2  =C2 i7 860
>      >      > =C2  =C2 MSI P55 GD85
>      >      > =C2  =C2 ATI H6670 - working 3D
>      >      > =C2  =C2 ATI H5830 - working 3D
>      >      > =C2  =C2 Debian 6.0, custom kernel 3.1
>      >      > =C2  =C2 Xen 4.2 unstable ( from repo 2. march? )
>      >      > =C2  =C2 Windows 7 64bit - virtual
>      >      > =C2  =C2 no extra patches
>      >      > =C2  =C2 but how i get it to work is strange, if i enable
>      #gfx_passthru=3D1
>      >      then
>      >      > =C2  =C2 virtual machine wont start
>      >      >
>      >
>      >      gfx_passthru=3D1 makes the passthru gfx card primary in the V=
M,
>      >      so you need the additional ATI gfx passthru patch so that the
>      VBIOS
>      >      passthru works.
>      >
>      >      without gfx_passthru=3D1 the virtual emulated gfx is primary.
>      >      -- Pasi
>      >
>      > References
>      >
>      >    Visible links
>      >    1. mailto:[3]pasik@iki.fi
> =

> References
> =

>    Visible links
>    1. mailto:pasik@iki.fi
>    2. mailto:pasik@iki.fi
>    3. mailto:pasik@iki.fi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 11:47:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 11:47:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEJEe-0004Av-PD; Sun, 01 Apr 2012 11:46:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEJEd-0004Aq-Be
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 11:46:15 +0000
Received: from [85.158.139.83:63686] by server-11.bemta-5.messagelabs.com id
	34/14-12959-600487F4; Sun, 01 Apr 2012 11:46:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333280773!21927614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17577 invoked from network); 1 Apr 2012 11:46:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 11:46:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="11707739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 11:46:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 12:46:13 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEJEa-00062s-Ki;
	Sun, 01 Apr 2012 11:46:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEJEa-0003zr-Ef;
	Sun, 01 Apr 2012 12:46:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12535-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 12:46:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12535: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12535 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12535/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-pv            9 guest-start                  fail   like 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 11:47:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 11:47:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEJEe-0004Av-PD; Sun, 01 Apr 2012 11:46:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEJEd-0004Aq-Be
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 11:46:15 +0000
Received: from [85.158.139.83:63686] by server-11.bemta-5.messagelabs.com id
	34/14-12959-600487F4; Sun, 01 Apr 2012 11:46:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333280773!21927614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17577 invoked from network); 1 Apr 2012 11:46:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 11:46:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="11707739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 11:46:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 12:46:13 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEJEa-00062s-Ki;
	Sun, 01 Apr 2012 11:46:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEJEa-0003zr-Ef;
	Sun, 01 Apr 2012 12:46:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12535-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 12:46:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12535: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12535 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12535/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-pv            9 guest-start                  fail   like 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:19:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEKgR-0004iJ-N5; Sun, 01 Apr 2012 13:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SEKgQ-0004iE-Ad
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:19:02 +0000
Received: from [85.158.143.99:57971] by server-2.bemta-4.messagelabs.com id
	1C/EE-17550-5C5587F4; Sun, 01 Apr 2012 13:19:01 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333286340!21814741!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0ODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5185 invoked from network); 1 Apr 2012 13:19:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	1 Apr 2012 13:19:00 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q31DIXUZ012441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 1 Apr 2012 09:18:33 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q31DIPXL015606; Sun, 1 Apr 2012 09:18:26 -0400
Message-ID: <4F7855A1.80107@redhat.com>
Date: Sun, 01 Apr 2012 16:18:25 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com>
In-Reply-To: <4F7585EE.7060203@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/30/2012 01:07 PM, Raghavendra K T wrote:
> On 03/29/2012 11:33 PM, Raghavendra K T wrote:
>> On 03/29/2012 03:28 PM, Avi Kivity wrote:
>>> On 03/28/2012 08:21 PM, Raghavendra K T wrote:
>
>> I really like below ideas. Thanks for that!.
>>
>>> - from the PLE handler, don't wake up a vcpu that is sleeping
>>> because it
>>> is waiting for a kick
>>
>> How about, adding another pass in the beginning of kvm_vcpu_on_spin()
>> to check if any vcpu is already kicked. This would almost result in
>> yield_to(kicked_vcpu). IMO this is also worth trying.
>>
>> will try above ideas soon.
>>
>
> I have patch something like below in mind to try:
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d3b98b1..5127668 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>       * else and called schedule in __vcpu_run.  Hopefully that
>       * VCPU is holding the lock that we need and will release it.
>       * We approximate round-robin by starting at the last boosted VCPU.
> +     * Priority is given to vcpu that are unhalted.
>       */
> -    for (pass = 0; pass < 2 && !yielded; pass++) {
> +    for (pass = 0; pass < 3 && !yielded; pass++) {
>          kvm_for_each_vcpu(i, vcpu, kvm) {
>              struct task_struct *task = NULL;
>              struct pid *pid;
> -            if (!pass && i < last_boosted_vcpu) {
> +            if (!pass && !vcpu->pv_unhalted)
> +                continue;
> +            else if (pass == 1 && i < last_boosted_vcpu) {
>                  i = last_boosted_vcpu;
>                  continue;
> -            } else if (pass && i > last_boosted_vcpu)
> +            } else if (pass == 2 && i > last_boosted_vcpu)
>                  break;
>              if (vcpu == me)
>                  continue;
>

Actually I think this is unneeded.  The loops tries to find vcpus that
are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
don't match this condition.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:19:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEKgR-0004iJ-N5; Sun, 01 Apr 2012 13:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SEKgQ-0004iE-Ad
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:19:02 +0000
Received: from [85.158.143.99:57971] by server-2.bemta-4.messagelabs.com id
	1C/EE-17550-5C5587F4; Sun, 01 Apr 2012 13:19:01 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333286340!21814741!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0ODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5185 invoked from network); 1 Apr 2012 13:19:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	1 Apr 2012 13:19:00 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q31DIXUZ012441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 1 Apr 2012 09:18:33 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q31DIPXL015606; Sun, 1 Apr 2012 09:18:26 -0400
Message-ID: <4F7855A1.80107@redhat.com>
Date: Sun, 01 Apr 2012 16:18:25 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com>
In-Reply-To: <4F7585EE.7060203@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/30/2012 01:07 PM, Raghavendra K T wrote:
> On 03/29/2012 11:33 PM, Raghavendra K T wrote:
>> On 03/29/2012 03:28 PM, Avi Kivity wrote:
>>> On 03/28/2012 08:21 PM, Raghavendra K T wrote:
>
>> I really like below ideas. Thanks for that!.
>>
>>> - from the PLE handler, don't wake up a vcpu that is sleeping
>>> because it
>>> is waiting for a kick
>>
>> How about, adding another pass in the beginning of kvm_vcpu_on_spin()
>> to check if any vcpu is already kicked. This would almost result in
>> yield_to(kicked_vcpu). IMO this is also worth trying.
>>
>> will try above ideas soon.
>>
>
> I have patch something like below in mind to try:
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d3b98b1..5127668 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>       * else and called schedule in __vcpu_run.  Hopefully that
>       * VCPU is holding the lock that we need and will release it.
>       * We approximate round-robin by starting at the last boosted VCPU.
> +     * Priority is given to vcpu that are unhalted.
>       */
> -    for (pass = 0; pass < 2 && !yielded; pass++) {
> +    for (pass = 0; pass < 3 && !yielded; pass++) {
>          kvm_for_each_vcpu(i, vcpu, kvm) {
>              struct task_struct *task = NULL;
>              struct pid *pid;
> -            if (!pass && i < last_boosted_vcpu) {
> +            if (!pass && !vcpu->pv_unhalted)
> +                continue;
> +            else if (pass == 1 && i < last_boosted_vcpu) {
>                  i = last_boosted_vcpu;
>                  continue;
> -            } else if (pass && i > last_boosted_vcpu)
> +            } else if (pass == 2 && i > last_boosted_vcpu)
>                  break;
>              if (vcpu == me)
>                  continue;
>

Actually I think this is unneeded.  The loops tries to find vcpus that
are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
don't match this condition.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:33:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEKtU-0004rv-0p; Sun, 01 Apr 2012 13:32:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SEKtS-0004rq-Kt
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:32:30 +0000
Received: from [193.109.254.147:2701] by server-7.bemta-14.messagelabs.com id
	FD/E7-01627-DE8587F4; Sun, 01 Apr 2012 13:32:29 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333287148!2922287!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0ODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11762 invoked from network); 1 Apr 2012 13:32:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	1 Apr 2012 13:32:29 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q31DVojm013546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 1 Apr 2012 09:31:50 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q31DViRW025431; Sun, 1 Apr 2012 09:31:44 -0400
Message-ID: <4F7858C0.90405@redhat.com>
Date: Sun, 01 Apr 2012 16:31:44 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
> On Fri, 30 Mar 2012, H. Peter Anvin wrote:
>
> > What is the current status of this patchset?  I haven't looked at it too
> > closely because I have been focused on 3.4 up until now...
>
> The real question is whether these heuristics are the correct approach
> or not.
>
> If I look at it from the non virtualized kernel side then this is ass
> backwards. We know already that we are holding a spinlock which might
> cause other (v)cpus going into eternal spin. The non virtualized
> kernel solves this by disabling preemption and therefor getting out of
> the critical section as fast as possible,
>
> The virtualization problem reminds me a lot of the problem which RT
> kernels are observing where non raw spinlocks are turned into
> "sleeping spinlocks" and therefor can cause throughput issues for non
> RT workloads.
>
> Though the virtualized situation is even worse. Any preempted guest
> section which holds a spinlock is prone to cause unbound delays.
>
> The paravirt ticketlock solution can only mitigate the problem, but
> not solve it. With massive overcommit there is always a way to trigger
> worst case scenarious unless you are educating the scheduler to cope
> with that.
>
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.
>
> I know that Peter is going to go berserk on me, but if we are running
> a paravirt guest then it's simple to provide a mechanism which allows
> the host (aka hypervisor) to check that in the guest just by looking
> at some global state.
>
> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be
> modified to indicate the guest to invoke an exit when the last nested
> lock has been released.

Interesting idea (I think it has been raised before btw, don't recall by
who).

One thing about it is that it can give many false positives.  Consider a
fine-grained spinlock that is being accessed by many threads.  That is,
the lock is taken and released with high frequency, but there is no
contention, because each vcpu is accessing a different instance.  So the
host scheduler will needlessly delay preemption of vcpus that happen to
be holding a lock, even though this gains nothing.

A second issue may happen with a lock that is taken and released with
high frequency, with a high hold percentage.  The host scheduler may
always sample the guest in a held state, leading it to conclude that
it's exceeding its timeout when in fact the lock is held for a short
time only.

> Of course this needs to be time bound, so a rogue guest cannot
> monopolize the cpu forever, but that's the least to worry about
> problem simply because a guest which does not get out of a spinlocked
> region within a certain amount of time is borked and elegible to
> killing anyway.

Hopefully not killing!  Just because a guest doesn't scale well, or even
if it's deadlocked, doesn't mean it should be killed.  Just preempt it.

> Thoughts ?

It's certainly interesting.  Maybe a combination is worthwhile - prevent
lockholder preemption for a short period of time AND put waiters to
sleep in case that period is insufficient to release the lock.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:33:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEKtU-0004rv-0p; Sun, 01 Apr 2012 13:32:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SEKtS-0004rq-Kt
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:32:30 +0000
Received: from [193.109.254.147:2701] by server-7.bemta-14.messagelabs.com id
	FD/E7-01627-DE8587F4; Sun, 01 Apr 2012 13:32:29 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333287148!2922287!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0ODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11762 invoked from network); 1 Apr 2012 13:32:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	1 Apr 2012 13:32:29 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q31DVojm013546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 1 Apr 2012 09:31:50 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q31DViRW025431; Sun, 1 Apr 2012 09:31:44 -0400
Message-ID: <4F7858C0.90405@redhat.com>
Date: Sun, 01 Apr 2012 16:31:44 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
> On Fri, 30 Mar 2012, H. Peter Anvin wrote:
>
> > What is the current status of this patchset?  I haven't looked at it too
> > closely because I have been focused on 3.4 up until now...
>
> The real question is whether these heuristics are the correct approach
> or not.
>
> If I look at it from the non virtualized kernel side then this is ass
> backwards. We know already that we are holding a spinlock which might
> cause other (v)cpus going into eternal spin. The non virtualized
> kernel solves this by disabling preemption and therefor getting out of
> the critical section as fast as possible,
>
> The virtualization problem reminds me a lot of the problem which RT
> kernels are observing where non raw spinlocks are turned into
> "sleeping spinlocks" and therefor can cause throughput issues for non
> RT workloads.
>
> Though the virtualized situation is even worse. Any preempted guest
> section which holds a spinlock is prone to cause unbound delays.
>
> The paravirt ticketlock solution can only mitigate the problem, but
> not solve it. With massive overcommit there is always a way to trigger
> worst case scenarious unless you are educating the scheduler to cope
> with that.
>
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.
>
> I know that Peter is going to go berserk on me, but if we are running
> a paravirt guest then it's simple to provide a mechanism which allows
> the host (aka hypervisor) to check that in the guest just by looking
> at some global state.
>
> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be
> modified to indicate the guest to invoke an exit when the last nested
> lock has been released.

Interesting idea (I think it has been raised before btw, don't recall by
who).

One thing about it is that it can give many false positives.  Consider a
fine-grained spinlock that is being accessed by many threads.  That is,
the lock is taken and released with high frequency, but there is no
contention, because each vcpu is accessing a different instance.  So the
host scheduler will needlessly delay preemption of vcpus that happen to
be holding a lock, even though this gains nothing.

A second issue may happen with a lock that is taken and released with
high frequency, with a high hold percentage.  The host scheduler may
always sample the guest in a held state, leading it to conclude that
it's exceeding its timeout when in fact the lock is held for a short
time only.

> Of course this needs to be time bound, so a rogue guest cannot
> monopolize the cpu forever, but that's the least to worry about
> problem simply because a guest which does not get out of a spinlocked
> region within a certain amount of time is borked and elegible to
> killing anyway.

Hopefully not killing!  Just because a guest doesn't scale well, or even
if it's deadlocked, doesn't mean it should be killed.  Just preempt it.

> Thoughts ?

It's certainly interesting.  Maybe a combination is worthwhile - prevent
lockholder preemption for a short period of time AND put waiters to
sleep in case that period is insufficient to release the lock.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SELAN-00052W-Ib; Sun, 01 Apr 2012 13:49:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SELAL-00052R-Bb
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:49:57 +0000
Received: from [85.158.143.35:58400] by server-2.bemta-4.messagelabs.com id
	A4/0D-17550-40D587F4; Sun, 01 Apr 2012 13:49:56 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333288193!7085951!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiAxMTA4NDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23204 invoked from network); 1 Apr 2012 13:49:55 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Apr 2012 13:49:55 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sun, 1 Apr 2012 19:19:50 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 1 Apr 2012 19:19:47 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q31Dnjos3416286
	for <xen-devel@lists.xensource.com>; Sun, 1 Apr 2012 19:19:46 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q31JKDSx024887
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 05:20:14 +1000
Received: from [9.79.209.200] ([9.79.209.200])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q31JK513024773; Mon, 2 Apr 2012 05:20:06 +1000
Message-ID: <4F785CC9.7070204@linux.vnet.ibm.com>
Date: Sun, 01 Apr 2012 19:18:57 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
In-Reply-To: <4F7855A1.80107@redhat.com>
x-cbid: 12040113-8878-0000-0000-000001E85156
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 06:48 PM, Avi Kivity wrote:
> On 03/30/2012 01:07 PM, Raghavendra K T wrote:
>> On 03/29/2012 11:33 PM, Raghavendra K T wrote:
>>> On 03/29/2012 03:28 PM, Avi Kivity wrote:
>>>> On 03/28/2012 08:21 PM, Raghavendra K T wrote:
>>
>>> I really like below ideas. Thanks for that!.
>>>
>>>> - from the PLE handler, don't wake up a vcpu that is sleeping
>>>> because it
>>>> is waiting for a kick
>>>
>>> How about, adding another pass in the beginning of kvm_vcpu_on_spin()
>>> to check if any vcpu is already kicked. This would almost result in
>>> yield_to(kicked_vcpu). IMO this is also worth trying.
>>>
>>> will try above ideas soon.
>>>
>>
>> I have patch something like below in mind to try:
>>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index d3b98b1..5127668 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>        * else and called schedule in __vcpu_run.  Hopefully that
>>        * VCPU is holding the lock that we need and will release it.
>>        * We approximate round-robin by starting at the last boosted VCPU.
>> +     * Priority is given to vcpu that are unhalted.
>>        */
>> -    for (pass = 0; pass<  2&&  !yielded; pass++) {
>> +    for (pass = 0; pass<  3&&  !yielded; pass++) {
>>           kvm_for_each_vcpu(i, vcpu, kvm) {
>>               struct task_struct *task = NULL;
>>               struct pid *pid;
>> -            if (!pass&&  i<  last_boosted_vcpu) {
>> +            if (!pass&&  !vcpu->pv_unhalted)
>> +                continue;
>> +            else if (pass == 1&&  i<  last_boosted_vcpu) {
>>                   i = last_boosted_vcpu;
>>                   continue;
>> -            } else if (pass&&  i>  last_boosted_vcpu)
>> +            } else if (pass == 2&&  i>  last_boosted_vcpu)
>>                   break;
>>               if (vcpu == me)
>>                   continue;
>>
>
> Actually I think this is unneeded.  The loops tries to find vcpus that
> are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
> don't match this condition.
>

I almost agree. But at corner of my thought,

Suppose there are 8 vcpus runnable out of which 4 of them are kicked
but not running, making yield_to those 4 vcpus would result in better
lock progress. no?

  I still have little problem getting PLE setup, here (instead rebasing 
patches).
Once I get PLE to get that running, and numbers prove no improvement, I 
will drop this idea.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SELAN-00052W-Ib; Sun, 01 Apr 2012 13:49:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SELAL-00052R-Bb
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:49:57 +0000
Received: from [85.158.143.35:58400] by server-2.bemta-4.messagelabs.com id
	A4/0D-17550-40D587F4; Sun, 01 Apr 2012 13:49:56 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333288193!7085951!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiAxMTA4NDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23204 invoked from network); 1 Apr 2012 13:49:55 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Apr 2012 13:49:55 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sun, 1 Apr 2012 19:19:50 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 1 Apr 2012 19:19:47 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q31Dnjos3416286
	for <xen-devel@lists.xensource.com>; Sun, 1 Apr 2012 19:19:46 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q31JKDSx024887
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 05:20:14 +1000
Received: from [9.79.209.200] ([9.79.209.200])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q31JK513024773; Mon, 2 Apr 2012 05:20:06 +1000
Message-ID: <4F785CC9.7070204@linux.vnet.ibm.com>
Date: Sun, 01 Apr 2012 19:18:57 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
In-Reply-To: <4F7855A1.80107@redhat.com>
x-cbid: 12040113-8878-0000-0000-000001E85156
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 06:48 PM, Avi Kivity wrote:
> On 03/30/2012 01:07 PM, Raghavendra K T wrote:
>> On 03/29/2012 11:33 PM, Raghavendra K T wrote:
>>> On 03/29/2012 03:28 PM, Avi Kivity wrote:
>>>> On 03/28/2012 08:21 PM, Raghavendra K T wrote:
>>
>>> I really like below ideas. Thanks for that!.
>>>
>>>> - from the PLE handler, don't wake up a vcpu that is sleeping
>>>> because it
>>>> is waiting for a kick
>>>
>>> How about, adding another pass in the beginning of kvm_vcpu_on_spin()
>>> to check if any vcpu is already kicked. This would almost result in
>>> yield_to(kicked_vcpu). IMO this is also worth trying.
>>>
>>> will try above ideas soon.
>>>
>>
>> I have patch something like below in mind to try:
>>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index d3b98b1..5127668 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>        * else and called schedule in __vcpu_run.  Hopefully that
>>        * VCPU is holding the lock that we need and will release it.
>>        * We approximate round-robin by starting at the last boosted VCPU.
>> +     * Priority is given to vcpu that are unhalted.
>>        */
>> -    for (pass = 0; pass<  2&&  !yielded; pass++) {
>> +    for (pass = 0; pass<  3&&  !yielded; pass++) {
>>           kvm_for_each_vcpu(i, vcpu, kvm) {
>>               struct task_struct *task = NULL;
>>               struct pid *pid;
>> -            if (!pass&&  i<  last_boosted_vcpu) {
>> +            if (!pass&&  !vcpu->pv_unhalted)
>> +                continue;
>> +            else if (pass == 1&&  i<  last_boosted_vcpu) {
>>                   i = last_boosted_vcpu;
>>                   continue;
>> -            } else if (pass&&  i>  last_boosted_vcpu)
>> +            } else if (pass == 2&&  i>  last_boosted_vcpu)
>>                   break;
>>               if (vcpu == me)
>>                   continue;
>>
>
> Actually I think this is unneeded.  The loops tries to find vcpus that
> are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
> don't match this condition.
>

I almost agree. But at corner of my thought,

Suppose there are 8 vcpus runnable out of which 4 of them are kicked
but not running, making yield_to those 4 vcpus would result in better
lock progress. no?

  I still have little problem getting PLE setup, here (instead rebasing 
patches).
Once I get PLE to get that running, and numbers prove no improvement, I 
will drop this idea.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:54:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SELE5-00058s-7L; Sun, 01 Apr 2012 13:53:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SELE4-00058k-9i
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:53:48 +0000
Received: from [85.158.138.51:30499] by server-12.bemta-3.messagelabs.com id
	8F/FD-30663-BED587F4; Sun, 01 Apr 2012 13:53:47 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333288426!20067322!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0ODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25758 invoked from network); 1 Apr 2012 13:53:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	1 Apr 2012 13:53:46 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q31DrOIs021357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 1 Apr 2012 09:53:24 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q31DrJqM026085; Sun, 1 Apr 2012 09:53:20 -0400
Message-ID: <4F785DCF.7020809@redhat.com>
Date: Sun, 01 Apr 2012 16:53:19 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com>
In-Reply-To: <4F785CC9.7070204@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>> I have patch something like below in mind to try:
>>>
>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>> index d3b98b1..5127668 100644
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>        * else and called schedule in __vcpu_run.  Hopefully that
>>>        * VCPU is holding the lock that we need and will release it.
>>>        * We approximate round-robin by starting at the last boosted
>>> VCPU.
>>> +     * Priority is given to vcpu that are unhalted.
>>>        */
>>> -    for (pass = 0; pass<  2&&  !yielded; pass++) {
>>> +    for (pass = 0; pass<  3&&  !yielded; pass++) {
>>>           kvm_for_each_vcpu(i, vcpu, kvm) {
>>>               struct task_struct *task = NULL;
>>>               struct pid *pid;
>>> -            if (!pass&&  i<  last_boosted_vcpu) {
>>> +            if (!pass&&  !vcpu->pv_unhalted)
>>> +                continue;
>>> +            else if (pass == 1&&  i<  last_boosted_vcpu) {
>>>                   i = last_boosted_vcpu;
>>>                   continue;
>>> -            } else if (pass&&  i>  last_boosted_vcpu)
>>> +            } else if (pass == 2&&  i>  last_boosted_vcpu)
>>>                   break;
>>>               if (vcpu == me)
>>>                   continue;
>>>
>>
>> Actually I think this is unneeded.  The loops tries to find vcpus that
>> are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
>> don't match this condition.
>>
>
>
> I almost agree. But at corner of my thought,
>
> Suppose there are 8 vcpus runnable out of which 4 of them are kicked
> but not running, making yield_to those 4 vcpus would result in better
> lock progress. no?

That's what the code does.

>   I still have little problem getting PLE setup, here (instead
> rebasing patches).
> Once I get PLE to get that running, and numbers prove no improvement,
> I will drop this idea.
>

I'm interested in how PLE does vs. your patches, both with PLE enabled
and disabled.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:54:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SELE5-00058s-7L; Sun, 01 Apr 2012 13:53:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SELE4-00058k-9i
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:53:48 +0000
Received: from [85.158.138.51:30499] by server-12.bemta-3.messagelabs.com id
	8F/FD-30663-BED587F4; Sun, 01 Apr 2012 13:53:47 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333288426!20067322!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0ODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25758 invoked from network); 1 Apr 2012 13:53:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	1 Apr 2012 13:53:46 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q31DrOIs021357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 1 Apr 2012 09:53:24 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q31DrJqM026085; Sun, 1 Apr 2012 09:53:20 -0400
Message-ID: <4F785DCF.7020809@redhat.com>
Date: Sun, 01 Apr 2012 16:53:19 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com>
In-Reply-To: <4F785CC9.7070204@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>> I have patch something like below in mind to try:
>>>
>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>> index d3b98b1..5127668 100644
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>        * else and called schedule in __vcpu_run.  Hopefully that
>>>        * VCPU is holding the lock that we need and will release it.
>>>        * We approximate round-robin by starting at the last boosted
>>> VCPU.
>>> +     * Priority is given to vcpu that are unhalted.
>>>        */
>>> -    for (pass = 0; pass<  2&&  !yielded; pass++) {
>>> +    for (pass = 0; pass<  3&&  !yielded; pass++) {
>>>           kvm_for_each_vcpu(i, vcpu, kvm) {
>>>               struct task_struct *task = NULL;
>>>               struct pid *pid;
>>> -            if (!pass&&  i<  last_boosted_vcpu) {
>>> +            if (!pass&&  !vcpu->pv_unhalted)
>>> +                continue;
>>> +            else if (pass == 1&&  i<  last_boosted_vcpu) {
>>>                   i = last_boosted_vcpu;
>>>                   continue;
>>> -            } else if (pass&&  i>  last_boosted_vcpu)
>>> +            } else if (pass == 2&&  i>  last_boosted_vcpu)
>>>                   break;
>>>               if (vcpu == me)
>>>                   continue;
>>>
>>
>> Actually I think this is unneeded.  The loops tries to find vcpus that
>> are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
>> don't match this condition.
>>
>
>
> I almost agree. But at corner of my thought,
>
> Suppose there are 8 vcpus runnable out of which 4 of them are kicked
> but not running, making yield_to those 4 vcpus would result in better
> lock progress. no?

That's what the code does.

>   I still have little problem getting PLE setup, here (instead
> rebasing patches).
> Once I get PLE to get that running, and numbers prove no improvement,
> I will drop this idea.
>

I'm interested in how PLE does vs. your patches, both with PLE enabled
and disabled.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:57:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SELHW-0005HY-R5; Sun, 01 Apr 2012 13:57:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SELHV-0005HQ-11
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:57:21 +0000
Received: from [85.158.143.35:16397] by server-3.bemta-4.messagelabs.com id
	48/75-05853-0CE587F4; Sun, 01 Apr 2012 13:57:20 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333288637!6869895!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAyMzg5Mjg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32647 invoked from network); 1 Apr 2012 13:57:19 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Apr 2012 13:57:19 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sun, 1 Apr 2012 19:27:15 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 1 Apr 2012 19:27:11 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q31Dv9s34120780
	for <xen-devel@lists.xensource.com>; Sun, 1 Apr 2012 19:27:10 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q31JRiCR002694
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 05:27:46 +1000
Received: from [9.79.209.200] ([9.79.209.200])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q31JRbZ9002634; Mon, 2 Apr 2012 05:27:38 +1000
Message-ID: <4F785E89.8080609@linux.vnet.ibm.com>
Date: Sun, 01 Apr 2012 19:26:25 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
In-Reply-To: <4F785DCF.7020809@redhat.com>
x-cbid: 12040113-3864-0000-0000-0000021A820A
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 07:23 PM, Avi Kivity wrote:
> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>>> I have patch something like below in mind to try:
>
> I'm interested in how PLE does vs. your patches, both with PLE enabled
> and disabled.
>

Sure. will update with the experimental results.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 13:57:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 13:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SELHW-0005HY-R5; Sun, 01 Apr 2012 13:57:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SELHV-0005HQ-11
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 13:57:21 +0000
Received: from [85.158.143.35:16397] by server-3.bemta-4.messagelabs.com id
	48/75-05853-0CE587F4; Sun, 01 Apr 2012 13:57:20 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333288637!6869895!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAyMzg5Mjg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32647 invoked from network); 1 Apr 2012 13:57:19 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Apr 2012 13:57:19 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sun, 1 Apr 2012 19:27:15 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 1 Apr 2012 19:27:11 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q31Dv9s34120780
	for <xen-devel@lists.xensource.com>; Sun, 1 Apr 2012 19:27:10 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q31JRiCR002694
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 05:27:46 +1000
Received: from [9.79.209.200] ([9.79.209.200])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q31JRbZ9002634; Mon, 2 Apr 2012 05:27:38 +1000
Message-ID: <4F785E89.8080609@linux.vnet.ibm.com>
Date: Sun, 01 Apr 2012 19:26:25 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
In-Reply-To: <4F785DCF.7020809@redhat.com>
x-cbid: 12040113-3864-0000-0000-0000021A820A
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 07:23 PM, Avi Kivity wrote:
> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>>> I have patch something like below in mind to try:
>
> I'm interested in how PLE does vs. your patches, both with PLE enabled
> and disabled.
>

Sure. will update with the experimental results.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 18:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 18:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEPBj-0006r5-96; Sun, 01 Apr 2012 18:07:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEPBh-0006r0-Kd
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 18:07:37 +0000
Received: from [193.109.254.147:31810] by server-2.bemta-14.messagelabs.com id
	9B/7F-19409-869987F4; Sun, 01 Apr 2012 18:07:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333303656!2936757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19582 invoked from network); 1 Apr 2012 18:07:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 18:07:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="11709831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 18:07:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 19:07:35 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEPBf-00082N-57;
	Sun, 01 Apr 2012 18:07:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEPBe-0005GD-Sn;
	Sun, 01 Apr 2012 19:07:34 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12537-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 19:07:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12537: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12537 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12537/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 18:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 18:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEPBj-0006r5-96; Sun, 01 Apr 2012 18:07:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEPBh-0006r0-Kd
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 18:07:37 +0000
Received: from [193.109.254.147:31810] by server-2.bemta-14.messagelabs.com id
	9B/7F-19409-869987F4; Sun, 01 Apr 2012 18:07:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333303656!2936757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19582 invoked from network); 1 Apr 2012 18:07:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 18:07:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="11709831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Apr 2012 18:07:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 1 Apr 2012 19:07:35 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEPBf-00082N-57;
	Sun, 01 Apr 2012 18:07:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEPBe-0005GD-Sn;
	Sun, 01 Apr 2012 19:07:34 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12537-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Apr 2012 19:07:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12537: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12537 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12537/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 18:17:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 18:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEPKF-00072o-DU; Sun, 01 Apr 2012 18:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SEPKD-00072e-KD
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 18:16:25 +0000
Received: from [85.158.138.51:30979] by server-11.bemta-3.messagelabs.com id
	DD/10-12049-87B987F4; Sun, 01 Apr 2012 18:16:24 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333304182!16070273!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1337 invoked from network); 1 Apr 2012 18:16:23 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 18:16:23 -0000
Received: by obbwd18 with SMTP id wd18so293092obb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 01 Apr 2012 11:16:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc
	:content-type:content-transfer-encoding:x-gm-message-state;
	bh=94jNWkZYsHxQ+IN7llFpU58POratXdD9PmlpbtaagAg=;
	b=Muj1+tZW4nK8xlah/xQwajozu0z1gap55UR6ztRVbYA+3KWIoXoFLZ0pFh28eGE3mv
	3AjMvSYlV15r5IRMq7VqLvrHUnhmmbZtvl8eRSycPVmgD8ZYJnEBAUJb4l9opVktp9Gq
	2NPwQTf6mQJ038yQPMpvi9p9AdH6nU4h8E2NqWh2Tju7sCuZn2/NM7CI777kQbZxhvRb
	WPCbKD+8l5JT5mayULqhnAZhEZJUejfEPceAeWQ/PfQz1B/3S3oR4z8OhvYxFcg3cvvW
	28ItBfdqk1ykqsGC1YJhbbEuDJHGPtk7bko7pN1DYGppepoYYtX64a+lV+89BIl3OX3n
	IwUg==
MIME-Version: 1.0
Received: by 10.60.172.231 with SMTP id bf7mr8632917oec.45.1333304181807; Sun,
	01 Apr 2012 11:16:21 -0700 (PDT)
Received: by 10.182.97.72 with HTTP; Sun, 1 Apr 2012 11:16:21 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
Date: Mon, 2 Apr 2012 04:16:21 +1000
Message-ID: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: xen-devel <xen-devel@lists.xensource.com>, xen-users@lists.xensource.com
X-Gm-Message-State: ALoCoQmZ4RqadlTQH2GsLsO8tMwsg66jMrIin6SEHb049XcGt4P7cOeXEOyLE99tMXw8rCak1Dtz
Cc: staff@orionvm.com.au, Lars Kurth <lars.kurth@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys,

I have started preparing a library of PV-HVM templates for use on Xen
4.X+ and PVOPS dom0.
This was brought up late last year as something that would make Xen
alot easier for beginners to try.
They are also great for testing - I will be setting up some stuff to
do automatic testing of distro kernel compatibility against
xen-unstable.

Mirror page is here:

    http://mirror.orionvm.com.au

You can browse what stuff I will be mirroring here:

    http://mirror.orionvm.com.au/pub/

Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
(the final beta, will be updated to final shortly).
Included is an OS image, a config file, a README and the associated
licences etc.
The images are bz2 compressed blockdevice images suitable for use on
LVM or a file backed tapdisk if you have the appropriate backend.
(alternatively you can use the loop device but this is discouraged)
All images have serial console enabled, PV network and block devices,
fixed udev rules etc.

I will add more info about them, an FAQ about how they are setup and
what you should do to customize them, expand the disk image etc soon.

I am looking for someone to mirror these in the US for me, please
email me if you have spare bandwith.

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 01 18:17:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Apr 2012 18:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEPKF-00072o-DU; Sun, 01 Apr 2012 18:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SEPKD-00072e-KD
	for xen-devel@lists.xensource.com; Sun, 01 Apr 2012 18:16:25 +0000
Received: from [85.158.138.51:30979] by server-11.bemta-3.messagelabs.com id
	DD/10-12049-87B987F4; Sun, 01 Apr 2012 18:16:24 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333304182!16070273!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1337 invoked from network); 1 Apr 2012 18:16:23 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Apr 2012 18:16:23 -0000
Received: by obbwd18 with SMTP id wd18so293092obb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 01 Apr 2012 11:16:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc
	:content-type:content-transfer-encoding:x-gm-message-state;
	bh=94jNWkZYsHxQ+IN7llFpU58POratXdD9PmlpbtaagAg=;
	b=Muj1+tZW4nK8xlah/xQwajozu0z1gap55UR6ztRVbYA+3KWIoXoFLZ0pFh28eGE3mv
	3AjMvSYlV15r5IRMq7VqLvrHUnhmmbZtvl8eRSycPVmgD8ZYJnEBAUJb4l9opVktp9Gq
	2NPwQTf6mQJ038yQPMpvi9p9AdH6nU4h8E2NqWh2Tju7sCuZn2/NM7CI777kQbZxhvRb
	WPCbKD+8l5JT5mayULqhnAZhEZJUejfEPceAeWQ/PfQz1B/3S3oR4z8OhvYxFcg3cvvW
	28ItBfdqk1ykqsGC1YJhbbEuDJHGPtk7bko7pN1DYGppepoYYtX64a+lV+89BIl3OX3n
	IwUg==
MIME-Version: 1.0
Received: by 10.60.172.231 with SMTP id bf7mr8632917oec.45.1333304181807; Sun,
	01 Apr 2012 11:16:21 -0700 (PDT)
Received: by 10.182.97.72 with HTTP; Sun, 1 Apr 2012 11:16:21 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
Date: Mon, 2 Apr 2012 04:16:21 +1000
Message-ID: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: xen-devel <xen-devel@lists.xensource.com>, xen-users@lists.xensource.com
X-Gm-Message-State: ALoCoQmZ4RqadlTQH2GsLsO8tMwsg66jMrIin6SEHb049XcGt4P7cOeXEOyLE99tMXw8rCak1Dtz
Cc: staff@orionvm.com.au, Lars Kurth <lars.kurth@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys,

I have started preparing a library of PV-HVM templates for use on Xen
4.X+ and PVOPS dom0.
This was brought up late last year as something that would make Xen
alot easier for beginners to try.
They are also great for testing - I will be setting up some stuff to
do automatic testing of distro kernel compatibility against
xen-unstable.

Mirror page is here:

    http://mirror.orionvm.com.au

You can browse what stuff I will be mirroring here:

    http://mirror.orionvm.com.au/pub/

Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
(the final beta, will be updated to final shortly).
Included is an OS image, a config file, a README and the associated
licences etc.
The images are bz2 compressed blockdevice images suitable for use on
LVM or a file backed tapdisk if you have the appropriate backend.
(alternatively you can use the loop device but this is discouraged)
All images have serial console enabled, PV network and block devices,
fixed udev rules etc.

I will add more info about them, an FAQ about how they are setup and
what you should do to customize them, expand the disk image etc soon.

I am looking for someone to mirror these in the US for me, please
email me if you have spare bandwith.

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 00:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 00:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEVBw-0000Rl-QB; Mon, 02 Apr 2012 00:32:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEVBu-0000Rg-QL
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 00:32:15 +0000
Received: from [193.109.254.147:4236] by server-3.bemta-14.messagelabs.com id
	49/F4-23274-E83F87F4; Mon, 02 Apr 2012 00:32:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1333326733!2964733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3577 invoked from network); 2 Apr 2012 00:32:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 00:32:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,354,1330905600"; d="scan'208";a="11711252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 00:32:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 01:32:12 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEVBs-0001dI-Ht;
	Mon, 02 Apr 2012 00:32:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEVBs-0000a9-5S;
	Mon, 02 Apr 2012 01:32:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12539-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 01:32:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12539: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12539 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12539/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12509 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 00:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 00:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEVBw-0000Rl-QB; Mon, 02 Apr 2012 00:32:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEVBu-0000Rg-QL
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 00:32:15 +0000
Received: from [193.109.254.147:4236] by server-3.bemta-14.messagelabs.com id
	49/F4-23274-E83F87F4; Mon, 02 Apr 2012 00:32:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1333326733!2964733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3577 invoked from network); 2 Apr 2012 00:32:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 00:32:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,354,1330905600"; d="scan'208";a="11711252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 00:32:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 01:32:12 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEVBs-0001dI-Ht;
	Mon, 02 Apr 2012 00:32:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEVBs-0000a9-5S;
	Mon, 02 Apr 2012 01:32:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12539-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 01:32:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12539: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12539 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12539/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12509

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12509 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12509 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 01:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 01:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEVfv-0006Zd-B5; Mon, 02 Apr 2012 01:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SEVfu-0006ZY-2a
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 01:03:14 +0000
Received: from [85.158.138.51:44929] by server-2.bemta-3.messagelabs.com id
	1B/2C-15460-1DAF87F4; Mon, 02 Apr 2012 01:03:13 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333328591!20106859!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12774 invoked from network); 2 Apr 2012 01:03:12 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 01:03:12 -0000
Received: by bkcjg9 with SMTP id jg9so2079020bkc.32
	for <xen-devel@lists.xen.org>; Sun, 01 Apr 2012 18:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=hhCujXGkEPQ2sbWHKnlQCc3zZgAErxyVmlROJKM/XZs=;
	b=I2N+oDsE+dc76zqxSITxVJBbJMGzWucZ2q64/wJDKXnWV9lQSZgEB7BVy6qw4fwPX1
	hpHx7cRZvJKYpSnRRf/8uS5z3kNNhThMpXx7OQ9HZ+zrfyEyp2L7ale9nePi4C3jOguo
	+gw78ZUokTcBsuIcocDyUr2KX70Flgs9hbNVXyf+QAJuIKUDiit3ahoD/vIFq1bBe+8L
	L8g9E/Pc67eqcjx69EM0zedkdY/lqEQRYccH9UcRc03OYls28MIr/QMZYCTGLkhrfpnT
	ifKuIBheR59/uYXpL9tjRas5jpSmaIsPzFZgkLFDxXGqGZymDy1p6HaTCvErtH5uLU8N
	7zxg==
MIME-Version: 1.0
Received: by 10.204.157.134 with SMTP id b6mr2868984bkx.88.1333328591747; Sun,
	01 Apr 2012 18:03:11 -0700 (PDT)
Received: by 10.204.155.145 with HTTP; Sun, 1 Apr 2012 18:03:11 -0700 (PDT)
Date: Mon, 2 Apr 2012 03:03:11 +0200
Message-ID: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7109500362730068448=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7109500362730068448==
Content-Type: multipart/alternative; boundary=0015175cd05e147c0404bca7c13b

--0015175cd05e147c0404bca7c13b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

i am trying to apply AMD/ATI patch on xen4-2 unstable
http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN3j=
loS.txt

and there was some changes in code and the patch is unusable, is there a
new patch. or can somebody help me to update the patch?

make[4]: Entering directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm'
  CC    i386-dm/pt-graphics.o
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:
In function =E2=80=98igd_register_vga_regions=E2=80=99:
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:373:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:374:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:
In function =E2=80=98igd_unregister_vga_regions=E2=80=99:
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:396:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:397:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
make[4]: *** [pt-graphics.o] Error 1
make[4]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm'
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
'
make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
make: *** [install-tools] Error 2

http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-pt=
-pci-host-read-write-td5016713.html

example:

old syle:
vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);

new syle:
vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);

Best Regards,
Kristijan Le=C4=8Dnik

--0015175cd05e147c0404bca7c13b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>i am trying to apply AMD/ATI patch on xen4-2 unstabl=
e</div><div><a href=3D"http://old-list-archives.xen.org/archives/html/xen-d=
evel/2010-12/txtNwRlN3jloS.txt">http://old-list-archives.xen.org/archives/h=
tml/xen-devel/2010-12/txtNwRlN3jloS.txt</a></div>
<div><br></div><div>and there was some changes in code and the patch is unu=
sable, is there a new patch. or can somebody help me to update the patch?</=
div><div><br></div><div><div>make[4]: Entering directory `/root/xen-unstabl=
e.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;</div=
>
<div>=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o</div><div>/root/xen-unsta=
ble.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-graphics.c: In f=
unction =E2=80=98igd_register_vga_regions=E2=80=99:</div><div>/root/xen-uns=
table.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-graphics.c:373=
: error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99<=
/div>
<div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw=
/pt-graphics.c:374: error: too many arguments to function =E2=80=98pt_pci_h=
ost_read=E2=80=99</div><div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu=
-xen-traditional-dir/hw/pt-graphics.c: In function =E2=80=98igd_unregister_=
vga_regions=E2=80=99:</div>
<div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw=
/pt-graphics.c:396: error: too many arguments to function =E2=80=98pt_pci_h=
ost_read=E2=80=99</div><div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu=
-xen-traditional-dir/hw/pt-graphics.c:397: error: too many arguments to fun=
ction =E2=80=98pt_pci_host_read=E2=80=99</div>
<div>make[4]: *** [pt-graphics.o] Error 1</div><div>make[4]: Leaving direct=
ory `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote/i386-dm&#39;</div><div>make[3]: *** [subdir-i386-dm] Error 2</div>
<div>make[3]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools=
/qemu-xen-traditional-dir-remote&#39;</div><div>make[2]: *** [subdir-instal=
l-qemu-xen-traditional-dir] Error 2</div><div>make[2]: Leaving directory `/=
root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div>
<div>make[1]: *** [subdirs-install] Error 2</div><div>make[1]: Leaving dire=
ctory `/root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div><div>make: *** =
[install-tools] Error 2</div></div><div><br></div><div><a href=3D"http://xe=
n.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-pt-pci-host=
-read-write-td5016713.html">http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu=
-xen-Change-prototype-for-pt-pci-host-read-write-td5016713.html</a></div>
<div><br></div><div>example:</div><div><br></div><div>old syle:</div><div>v=
endor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);</div><div><br></div><div>new =
syle:</div><div>vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);</di=
v>
<div><br></div><div>Best Regards,</div><div>Kristijan Le=C4=8Dnik</div>

--0015175cd05e147c0404bca7c13b--


--===============7109500362730068448==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7109500362730068448==--


From xen-devel-bounces@lists.xen.org Mon Apr 02 01:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 01:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEVfv-0006Zd-B5; Mon, 02 Apr 2012 01:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SEVfu-0006ZY-2a
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 01:03:14 +0000
Received: from [85.158.138.51:44929] by server-2.bemta-3.messagelabs.com id
	1B/2C-15460-1DAF87F4; Mon, 02 Apr 2012 01:03:13 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333328591!20106859!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12774 invoked from network); 2 Apr 2012 01:03:12 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 01:03:12 -0000
Received: by bkcjg9 with SMTP id jg9so2079020bkc.32
	for <xen-devel@lists.xen.org>; Sun, 01 Apr 2012 18:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=hhCujXGkEPQ2sbWHKnlQCc3zZgAErxyVmlROJKM/XZs=;
	b=I2N+oDsE+dc76zqxSITxVJBbJMGzWucZ2q64/wJDKXnWV9lQSZgEB7BVy6qw4fwPX1
	hpHx7cRZvJKYpSnRRf/8uS5z3kNNhThMpXx7OQ9HZ+zrfyEyp2L7ale9nePi4C3jOguo
	+gw78ZUokTcBsuIcocDyUr2KX70Flgs9hbNVXyf+QAJuIKUDiit3ahoD/vIFq1bBe+8L
	L8g9E/Pc67eqcjx69EM0zedkdY/lqEQRYccH9UcRc03OYls28MIr/QMZYCTGLkhrfpnT
	ifKuIBheR59/uYXpL9tjRas5jpSmaIsPzFZgkLFDxXGqGZymDy1p6HaTCvErtH5uLU8N
	7zxg==
MIME-Version: 1.0
Received: by 10.204.157.134 with SMTP id b6mr2868984bkx.88.1333328591747; Sun,
	01 Apr 2012 18:03:11 -0700 (PDT)
Received: by 10.204.155.145 with HTTP; Sun, 1 Apr 2012 18:03:11 -0700 (PDT)
Date: Mon, 2 Apr 2012 03:03:11 +0200
Message-ID: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7109500362730068448=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7109500362730068448==
Content-Type: multipart/alternative; boundary=0015175cd05e147c0404bca7c13b

--0015175cd05e147c0404bca7c13b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

i am trying to apply AMD/ATI patch on xen4-2 unstable
http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN3j=
loS.txt

and there was some changes in code and the patch is unusable, is there a
new patch. or can somebody help me to update the patch?

make[4]: Entering directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm'
  CC    i386-dm/pt-graphics.o
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:
In function =E2=80=98igd_register_vga_regions=E2=80=99:
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:373:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:374:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:
In function =E2=80=98igd_unregister_vga_regions=E2=80=99:
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:396:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-g=
raphics.c:397:
error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
make[4]: *** [pt-graphics.o] Error 1
make[4]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm'
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
'
make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
make: *** [install-tools] Error 2

http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-pt=
-pci-host-read-write-td5016713.html

example:

old syle:
vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);

new syle:
vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);

Best Regards,
Kristijan Le=C4=8Dnik

--0015175cd05e147c0404bca7c13b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>i am trying to apply AMD/ATI patch on xen4-2 unstabl=
e</div><div><a href=3D"http://old-list-archives.xen.org/archives/html/xen-d=
evel/2010-12/txtNwRlN3jloS.txt">http://old-list-archives.xen.org/archives/h=
tml/xen-devel/2010-12/txtNwRlN3jloS.txt</a></div>
<div><br></div><div>and there was some changes in code and the patch is unu=
sable, is there a new patch. or can somebody help me to update the patch?</=
div><div><br></div><div><div>make[4]: Entering directory `/root/xen-unstabl=
e.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;</div=
>
<div>=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o</div><div>/root/xen-unsta=
ble.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-graphics.c: In f=
unction =E2=80=98igd_register_vga_regions=E2=80=99:</div><div>/root/xen-uns=
table.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt-graphics.c:373=
: error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99<=
/div>
<div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw=
/pt-graphics.c:374: error: too many arguments to function =E2=80=98pt_pci_h=
ost_read=E2=80=99</div><div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu=
-xen-traditional-dir/hw/pt-graphics.c: In function =E2=80=98igd_unregister_=
vga_regions=E2=80=99:</div>
<div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw=
/pt-graphics.c:396: error: too many arguments to function =E2=80=98pt_pci_h=
ost_read=E2=80=99</div><div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu=
-xen-traditional-dir/hw/pt-graphics.c:397: error: too many arguments to fun=
ction =E2=80=98pt_pci_host_read=E2=80=99</div>
<div>make[4]: *** [pt-graphics.o] Error 1</div><div>make[4]: Leaving direct=
ory `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote/i386-dm&#39;</div><div>make[3]: *** [subdir-i386-dm] Error 2</div>
<div>make[3]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools=
/qemu-xen-traditional-dir-remote&#39;</div><div>make[2]: *** [subdir-instal=
l-qemu-xen-traditional-dir] Error 2</div><div>make[2]: Leaving directory `/=
root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div>
<div>make[1]: *** [subdirs-install] Error 2</div><div>make[1]: Leaving dire=
ctory `/root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div><div>make: *** =
[install-tools] Error 2</div></div><div><br></div><div><a href=3D"http://xe=
n.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-pt-pci-host=
-read-write-td5016713.html">http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu=
-xen-Change-prototype-for-pt-pci-host-read-write-td5016713.html</a></div>
<div><br></div><div>example:</div><div><br></div><div>old syle:</div><div>v=
endor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);</div><div><br></div><div>new =
syle:</div><div>vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);</di=
v>
<div><br></div><div>Best Regards,</div><div>Kristijan Le=C4=8Dnik</div>

--0015175cd05e147c0404bca7c13b--


--===============7109500362730068448==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7109500362730068448==--


From xen-devel-bounces@lists.xen.org Mon Apr 02 05:03:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 05:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEZPe-0008E8-L2; Mon, 02 Apr 2012 05:02:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kuwa@jp.fujitsu.com>) id 1SEZPc-0008E3-GC
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 05:02:40 +0000
Received: from [85.158.143.35:50872] by server-3.bemta-4.messagelabs.com id
	C6/E6-05853-FE2397F4; Mon, 02 Apr 2012 05:02:39 +0000
X-Env-Sender: kuwa@jp.fujitsu.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333342956!16665869!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDE2NTg4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14330 invoked from network); 2 Apr 2012 05:02:38 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 05:02:38 -0000
Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id EDA483EE0BC;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from smail (m3 [127.0.0.1])
	by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id D605845DE9E;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93])
	by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id C02F145DE7E;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id B456F1DB803E;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp
	[10.25.192.37])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 72F8B1DB803B;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp
	[10.25.192.39])
	by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs.
	Domain Mail Master) with ESMTP id q32518Qf023586; 
	Mon, 2 Apr 2012 14:02:33 +0900 (JST)
X-AuditID: 0a19c027-b7b67ae000002cc0-b3-4f7932e93d83
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp
	[10.25.192.105])
	by vskawa.flab.fujitsu.co.jp (Symantec Brightmail Gateway) with SMTP id
	44.0D.11456.9E2397F4; Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from eve.cad.flab.fujitsu.co.jp (eve.cad.flab.fujitsu.co.jp
	[10.25.228.68])
	by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs.
	Kawasaki Domain Mail Master) with ESMTP id q3252XWl016718; 
	Mon, 2 Apr 2012 14:02:33 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by eve.cad.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id
	q3252WNt011376; Mon, 2 Apr 2012 14:02:32 +0900 (JST)
	(envelope-from kuwa@jp.fujitsu.com)
Date: Mon, 02 Apr 2012 14:02:11 +0900 (JST)
Message-Id: <20120402.140211.488075444.kuwa@jp.fujitsu.com>
To: roger.pau@entel.upc.edu
From: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
In-Reply-To: <1333092930-10850-1-git-send-email-roger.pau@entel.upc.edu>
References: <1333092930-10850-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: xcite1.60> Mew version 6.5rc1 on Emacs 23.4 / Mule 6.0
	(HANACHIRUSATO)
Mime-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: yang.z.zhang@intel.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] autoconf: fix python-dev detection on
 old python versions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

>>>>> On Fri, 30 Mar 2012 09:35:30 +0200
>>>>> roger.pau@entel.upc.edu(Roger Pau Monne)  said:
> 
> +LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
> +    print distutils.sysconfig.get_config_var("LIBS")'`"

"SYSLIBS" is also needed.

e.g.:
$ python -c 'import distutils.sysconfig; print distutils.sysconfig.get_config_var("SYSLIBS")'
-lm

Best regards,
-- 
  KUWAMURA Shin'ya

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 05:03:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 05:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEZPe-0008E8-L2; Mon, 02 Apr 2012 05:02:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kuwa@jp.fujitsu.com>) id 1SEZPc-0008E3-GC
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 05:02:40 +0000
Received: from [85.158.143.35:50872] by server-3.bemta-4.messagelabs.com id
	C6/E6-05853-FE2397F4; Mon, 02 Apr 2012 05:02:39 +0000
X-Env-Sender: kuwa@jp.fujitsu.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333342956!16665869!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDE2NTg4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14330 invoked from network); 2 Apr 2012 05:02:38 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 05:02:38 -0000
Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id EDA483EE0BC;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from smail (m3 [127.0.0.1])
	by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id D605845DE9E;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93])
	by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id C02F145DE7E;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id B456F1DB803E;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp
	[10.25.192.37])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 72F8B1DB803B;
	Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp
	[10.25.192.39])
	by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs.
	Domain Mail Master) with ESMTP id q32518Qf023586; 
	Mon, 2 Apr 2012 14:02:33 +0900 (JST)
X-AuditID: 0a19c027-b7b67ae000002cc0-b3-4f7932e93d83
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp
	[10.25.192.105])
	by vskawa.flab.fujitsu.co.jp (Symantec Brightmail Gateway) with SMTP id
	44.0D.11456.9E2397F4; Mon,  2 Apr 2012 14:02:33 +0900 (JST)
Received: from eve.cad.flab.fujitsu.co.jp (eve.cad.flab.fujitsu.co.jp
	[10.25.228.68])
	by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs.
	Kawasaki Domain Mail Master) with ESMTP id q3252XWl016718; 
	Mon, 2 Apr 2012 14:02:33 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by eve.cad.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id
	q3252WNt011376; Mon, 2 Apr 2012 14:02:32 +0900 (JST)
	(envelope-from kuwa@jp.fujitsu.com)
Date: Mon, 02 Apr 2012 14:02:11 +0900 (JST)
Message-Id: <20120402.140211.488075444.kuwa@jp.fujitsu.com>
To: roger.pau@entel.upc.edu
From: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
In-Reply-To: <1333092930-10850-1-git-send-email-roger.pau@entel.upc.edu>
References: <1333092930-10850-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: xcite1.60> Mew version 6.5rc1 on Emacs 23.4 / Mule 6.0
	(HANACHIRUSATO)
Mime-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: yang.z.zhang@intel.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] autoconf: fix python-dev detection on
 old python versions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

>>>>> On Fri, 30 Mar 2012 09:35:30 +0200
>>>>> roger.pau@entel.upc.edu(Roger Pau Monne)  said:
> 
> +LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
> +    print distutils.sysconfig.get_config_var("LIBS")'`"

"SYSLIBS" is also needed.

e.g.:
$ python -c 'import distutils.sysconfig; print distutils.sysconfig.get_config_var("SYSLIBS")'
-lm

Best regards,
-- 
  KUWAMURA Shin'ya

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 07:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 07:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEbMC-0000Uw-SF; Mon, 02 Apr 2012 07:07:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEbMA-0000Ur-O8
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 07:07:15 +0000
Received: from [193.109.254.147:56386] by server-6.bemta-14.messagelabs.com id
	4B/B4-02047-120597F4; Mon, 02 Apr 2012 07:07:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333350433!2973178!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16050 invoked from network); 2 Apr 2012 07:07:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 07:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="11713508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 07:07:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 08:07:12 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEbM8-0003qB-2n;
	Mon, 02 Apr 2012 07:07:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEbM7-0005XH-Py;
	Mon, 02 Apr 2012 08:07:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12541-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 08:07:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12541: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12541 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12541/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 11874
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 07:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 07:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEbMC-0000Uw-SF; Mon, 02 Apr 2012 07:07:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEbMA-0000Ur-O8
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 07:07:15 +0000
Received: from [193.109.254.147:56386] by server-6.bemta-14.messagelabs.com id
	4B/B4-02047-120597F4; Mon, 02 Apr 2012 07:07:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333350433!2973178!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16050 invoked from network); 2 Apr 2012 07:07:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 07:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="11713508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 07:07:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 08:07:12 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEbM8-0003qB-2n;
	Mon, 02 Apr 2012 07:07:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEbM7-0005XH-Py;
	Mon, 02 Apr 2012 08:07:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12541-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 08:07:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12541: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12541 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12541/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 11874
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 07:55:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 07:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEc6P-0000ln-TG; Mon, 02 Apr 2012 07:55:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1SEc6O-0000li-Hw
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 07:55:00 +0000
Received: from [85.158.138.51:47164] by server-2.bemta-3.messagelabs.com id
	FB/7E-15460-35B597F4; Mon, 02 Apr 2012 07:54:59 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333353298!20365955!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20956 invoked from network); 2 Apr 2012 07:54:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 07:54:59 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id A31198891E;
	Mon,  2 Apr 2012 09:54:58 +0200 (CEST)
Message-ID: <4F795B52.9060803@suse.de>
Date: Mon, 02 Apr 2012 09:54:58 +0200
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
X-Priority: 4 (Low)
References: <20120330152436.GA31016@aepfle.de> <4F772590.2000603@suse.de>
	<20120331164627.GA23873@aepfle.de>
In-Reply-To: <20120331164627.GA23873@aepfle.de>
X-Enigmail-Version: 1.4
Cc: xen-devel@lists.xensource.com, Erik Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QW0gMzEuMDMuMjAxMiAxODo0Niwgc2NocmllYiBPbGFmIEhlcmluZzoKPiBPbiBTYXQsIE1hciAz
MSwgQW5kcmVhcyBGw6RyYmVyIHdyb3RlOgo+IAo+PiBUaGlzIGlzIHRoZSBvbmx5IHVzYWdlIG9m
ICs9IG91dHNpZGUgTWFrZWZpbGUgZnJhZ21lbnRzLCBzbyBJIHdvbmRlciBpZgo+PiBpdHMgdXNl
IG1heSBoYXZlIGJlZW4gYnkgYWNjaWRlbnQuIElzIGl0IHNhZmUgaW4gYSBQT1NJWCBjb250ZXh0
Pwo+PiBPciBzaG91bGQgd2UgYmV0dGVyIHVzZSBDRkxBR1M9IiRDRkxBR1MgLW1hcmNoPTQ4NiI/
Cj4gCj4gTm93IHRoYXQgSSBsb29rIGF0IHRoZSBzaGViYW5nLCBjb25maWd1cmUgaXMgYSBzaCBz
Y3JpcHQgYW5kICs9IGlzIG1vc3QKPiBsaWtlbHkgYSBiYXNoIGZlYXR1cmUuIFNvIHlvdXIgc3Vn
Z2VzdGlvbiBmb3IgdGhlIGFzc2lnbm1lbnQgaXMgY29ycmVjdC4KCi4uLmFwYXJ0IGZyb20gdGhl
IG1pc3NpbmcgaSBpbiBpNDg2LCBvYnZpb3VzbHkuIDspCgpBbmRyZWFzCgotLSAKU1VTRSBMSU5V
WCBQcm9kdWN0cyBHbWJILCBNYXhmZWxkc3RyLiA1LCA5MDQwOSBOw7xybmJlcmcsIEdlcm1hbnkK
R0Y6IEplZmYgSGF3biwgSmVubmlmZXIgR3VpbGQsIEZlbGl4IEltZW5kw7ZyZmZlcjsgSFJCIDE2
NzQ2IEFHIE7DvHJuYmVyZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 02 07:55:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 07:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEc6P-0000ln-TG; Mon, 02 Apr 2012 07:55:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1SEc6O-0000li-Hw
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 07:55:00 +0000
Received: from [85.158.138.51:47164] by server-2.bemta-3.messagelabs.com id
	FB/7E-15460-35B597F4; Mon, 02 Apr 2012 07:54:59 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333353298!20365955!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20956 invoked from network); 2 Apr 2012 07:54:59 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 07:54:59 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id A31198891E;
	Mon,  2 Apr 2012 09:54:58 +0200 (CEST)
Message-ID: <4F795B52.9060803@suse.de>
Date: Mon, 02 Apr 2012 09:54:58 +0200
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
X-Priority: 4 (Low)
References: <20120330152436.GA31016@aepfle.de> <4F772590.2000603@suse.de>
	<20120331164627.GA23873@aepfle.de>
In-Reply-To: <20120331164627.GA23873@aepfle.de>
X-Enigmail-Version: 1.4
Cc: xen-devel@lists.xensource.com, Erik Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QW0gMzEuMDMuMjAxMiAxODo0Niwgc2NocmllYiBPbGFmIEhlcmluZzoKPiBPbiBTYXQsIE1hciAz
MSwgQW5kcmVhcyBGw6RyYmVyIHdyb3RlOgo+IAo+PiBUaGlzIGlzIHRoZSBvbmx5IHVzYWdlIG9m
ICs9IG91dHNpZGUgTWFrZWZpbGUgZnJhZ21lbnRzLCBzbyBJIHdvbmRlciBpZgo+PiBpdHMgdXNl
IG1heSBoYXZlIGJlZW4gYnkgYWNjaWRlbnQuIElzIGl0IHNhZmUgaW4gYSBQT1NJWCBjb250ZXh0
Pwo+PiBPciBzaG91bGQgd2UgYmV0dGVyIHVzZSBDRkxBR1M9IiRDRkxBR1MgLW1hcmNoPTQ4NiI/
Cj4gCj4gTm93IHRoYXQgSSBsb29rIGF0IHRoZSBzaGViYW5nLCBjb25maWd1cmUgaXMgYSBzaCBz
Y3JpcHQgYW5kICs9IGlzIG1vc3QKPiBsaWtlbHkgYSBiYXNoIGZlYXR1cmUuIFNvIHlvdXIgc3Vn
Z2VzdGlvbiBmb3IgdGhlIGFzc2lnbm1lbnQgaXMgY29ycmVjdC4KCi4uLmFwYXJ0IGZyb20gdGhl
IG1pc3NpbmcgaSBpbiBpNDg2LCBvYnZpb3VzbHkuIDspCgpBbmRyZWFzCgotLSAKU1VTRSBMSU5V
WCBQcm9kdWN0cyBHbWJILCBNYXhmZWxkc3RyLiA1LCA5MDQwOSBOw7xybmJlcmcsIEdlcm1hbnkK
R0Y6IEplZmYgSGF3biwgSmVubmlmZXIgR3VpbGQsIEZlbGl4IEltZW5kw7ZyZmZlcjsgSFJCIDE2
NzQ2IEFHIE7DvHJuYmVyZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 02 08:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 08:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEcbU-0001Ts-FK; Mon, 02 Apr 2012 08:27:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1SEcbU-0001Tn-3K
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 08:27:08 +0000
Received: from [85.158.139.83:47675] by server-1.bemta-5.messagelabs.com id
	5F/65-28458-BD2697F4; Mon, 02 Apr 2012 08:27:07 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333355226!22016932!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17242 invoked from network); 2 Apr 2012 08:27:06 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-10.tower-182.messagelabs.com with SMTP;
	2 Apr 2012 08:27:06 -0000
Received: (qmail 26107 invoked from network); 2 Apr 2012 10:27:05 +0200
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	2 Apr 2012 10:27:05 +0200
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xen.org
Date: Mon, 2 Apr 2012 10:27:04 +0200
User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; )
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
In-Reply-To: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <201204021027.04846.pavel@netsafe.cz>
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi,
> 
> i am trying to apply AMD/ATI patch on xen4-2 unstable
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN3j
> loS.txt
> 
> and there was some changes in code and the patch is unusable, is there a
> new patch. or can somebody help me to update the patch?

Hi,
that patch is not enough today. It will crash on:
ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);    
You have to patch the kernel. There was some patch in Konrad's git.
Google 'xen "ioperm problem"'.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 08:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 08:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEcbU-0001Ts-FK; Mon, 02 Apr 2012 08:27:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1SEcbU-0001Tn-3K
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 08:27:08 +0000
Received: from [85.158.139.83:47675] by server-1.bemta-5.messagelabs.com id
	5F/65-28458-BD2697F4; Mon, 02 Apr 2012 08:27:07 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333355226!22016932!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17242 invoked from network); 2 Apr 2012 08:27:06 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-10.tower-182.messagelabs.com with SMTP;
	2 Apr 2012 08:27:06 -0000
Received: (qmail 26107 invoked from network); 2 Apr 2012 10:27:05 +0200
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	2 Apr 2012 10:27:05 +0200
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xen.org
Date: Mon, 2 Apr 2012 10:27:04 +0200
User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; )
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
In-Reply-To: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <201204021027.04846.pavel@netsafe.cz>
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi,
> 
> i am trying to apply AMD/ATI patch on xen4-2 unstable
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN3j
> loS.txt
> 
> and there was some changes in code and the patch is unusable, is there a
> new patch. or can somebody help me to update the patch?

Hi,
that patch is not enough today. It will crash on:
ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);    
You have to patch the kernel. There was some patch in Konrad's git.
Google 'xen "ioperm problem"'.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 08:47:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 08:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEcuA-0001fY-BW; Mon, 02 Apr 2012 08:46:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEcu8-0001fT-SO
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 08:46:24 +0000
Received: from [193.109.254.147:57809] by server-9.bemta-14.messagelabs.com id
	64/C5-05787-067697F4; Mon, 02 Apr 2012 08:46:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333356383!2998142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16545 invoked from network); 2 Apr 2012 08:46:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 08:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="11715403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 08:46:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	09:46:23 +0100
Message-ID: <1333356381.25602.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Date: Mon, 2 Apr 2012 09:46:21 +0100
In-Reply-To: <CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-01 at 00:13 +0100, Joseph Glanville wrote:
> Domain configuration is stored in libxl_domain_config which is a part
> of libxl but there isn't currently a structure for data that is
> private to xl, that is xl daemon or utility specific configuration.
> Is it considered bad form to add a configuration variable to
> libxl_domain_config that only xl will benefit from? if so what is the
> best course of action here?
> I could create another structure for private data but I feel seeking
> guidance on this as prudent.

xl_cmdimpl.c defines struct domain_create to contain a bunch of this
sort of thing, is that a convenient location?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 08:47:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 08:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEcuA-0001fY-BW; Mon, 02 Apr 2012 08:46:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEcu8-0001fT-SO
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 08:46:24 +0000
Received: from [193.109.254.147:57809] by server-9.bemta-14.messagelabs.com id
	64/C5-05787-067697F4; Mon, 02 Apr 2012 08:46:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333356383!2998142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16545 invoked from network); 2 Apr 2012 08:46:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 08:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="11715403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 08:46:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	09:46:23 +0100
Message-ID: <1333356381.25602.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Date: Mon, 2 Apr 2012 09:46:21 +0100
In-Reply-To: <CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-01 at 00:13 +0100, Joseph Glanville wrote:
> Domain configuration is stored in libxl_domain_config which is a part
> of libxl but there isn't currently a structure for data that is
> private to xl, that is xl daemon or utility specific configuration.
> Is it considered bad form to add a configuration variable to
> libxl_domain_config that only xl will benefit from? if so what is the
> best course of action here?
> I could create another structure for private data but I feel seeking
> guidance on this as prudent.

xl_cmdimpl.c defines struct domain_create to contain a bunch of this
sort of thing, is that a convenient location?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 08:56:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 08:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEd3g-00023F-2M; Mon, 02 Apr 2012 08:56:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEd3e-000239-U6
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 08:56:15 +0000
Received: from [85.158.138.51:19916] by server-9.bemta-3.messagelabs.com id
	2E/E2-10923-EA9697F4; Mon, 02 Apr 2012 08:56:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333356973!20377962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12292 invoked from network); 2 Apr 2012 08:56:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 08:56:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="11715642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 08:56:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	09:56:13 +0100
Message-ID: <1333356972.25602.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Mon, 2 Apr 2012 09:56:12 +0100
In-Reply-To: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
> Hello All,
> 
> I am a newbie to Linux and Xen. I tried compiling Xen Source code (I
> want to make some changes and see how it works), but it failed on my
> system as it couldn't find gnu-stubs32.h. Later, on looking at
> Makefile, I figured out that for x86_64, it is not yet supported !! 

x86_64 is very much supported, in fact a 64 bit hypervisor is the
preferred configuration (with 32 or 64 tools depending on your chosen
dom0 configuration). What did you see in the Makefile which made you
think otherwise?

WRT gnu-stubs32.h I suspect you are missing some -devel package or
other. I don't know about how SuSE lays things out but you should locate
the package containing this file and install it. Googling suggests that
perhaps you meant gnu/stubs32.h? In which case you probably want to
install glibc-devel.

If you need to post again then please include a build log, including the
exact make command and the last page or so of the output (i.e. including
all of the error message).

> Then I installed "32-bit" emulation utility for x86-64.
> and I tried compiling by "linux32" terminal. 

Cross compiling requires much more effort than that. I suggest you don't
go down that path.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 08:56:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 08:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEd3g-00023F-2M; Mon, 02 Apr 2012 08:56:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEd3e-000239-U6
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 08:56:15 +0000
Received: from [85.158.138.51:19916] by server-9.bemta-3.messagelabs.com id
	2E/E2-10923-EA9697F4; Mon, 02 Apr 2012 08:56:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333356973!20377962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12292 invoked from network); 2 Apr 2012 08:56:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 08:56:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="11715642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 08:56:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	09:56:13 +0100
Message-ID: <1333356972.25602.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Mon, 2 Apr 2012 09:56:12 +0100
In-Reply-To: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
> Hello All,
> 
> I am a newbie to Linux and Xen. I tried compiling Xen Source code (I
> want to make some changes and see how it works), but it failed on my
> system as it couldn't find gnu-stubs32.h. Later, on looking at
> Makefile, I figured out that for x86_64, it is not yet supported !! 

x86_64 is very much supported, in fact a 64 bit hypervisor is the
preferred configuration (with 32 or 64 tools depending on your chosen
dom0 configuration). What did you see in the Makefile which made you
think otherwise?

WRT gnu-stubs32.h I suspect you are missing some -devel package or
other. I don't know about how SuSE lays things out but you should locate
the package containing this file and install it. Googling suggests that
perhaps you meant gnu/stubs32.h? In which case you probably want to
install glibc-devel.

If you need to post again then please include a build log, including the
exact make command and the last page or so of the output (i.e. including
all of the error message).

> Then I installed "32-bit" emulation utility for x86-64.
> and I tried compiling by "linux32" terminal. 

Cross compiling requires much more effort than that. I suggest you don't
go down that path.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:01:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEd8B-0002Ei-RJ; Mon, 02 Apr 2012 09:00:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SEd8A-0002Eb-BM
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:00:54 +0000
Received: from [193.109.254.147:26241] by server-7.bemta-14.messagelabs.com id
	41/A0-01627-5CA697F4; Mon, 02 Apr 2012 09:00:53 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333357250!2974553!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2433 invoked from network); 2 Apr 2012 09:00:52 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:00:52 -0000
Received: by qcsp15 with SMTP id p15so1794057qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Apr 2012 02:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Arv5pGbdDpP7JhlpC0NrWZuFbaM+hzIx4AR2vaGmNtI=;
	b=zExtJiaqswfi2renJqQs6c50QalwfBQ3/+sdag15mG5LIKstIdgCcYwCMf9o0hF6d/
	kBbGIekqhryvBlfGGUV0bDkB+18ONYtBGoZ0xwWANUu/U2Qy4Euob4BTqnKGGvuqkYnL
	0GLZIftWo530qYseSFvQh5f+7Ihu4/oV6lzOad+adkc6dTK2cIzXjMUv2bMxpUtOdWFu
	my9ENzsUJLkWybU+ufuJ3PLH/xEl3hgPRNKO5GNci7mOSt8vjYlXXMiF+lvINaaZealc
	d3u9NF3ku3gaCrfvn4yMUhios1RM/pDrzznRNJ8zUfwKJ3EFAOAfc0re/nYC2R9scTgq
	5hIw==
MIME-Version: 1.0
Received: by 10.224.96.66 with SMTP id g2mr10134884qan.47.1333357250145; Mon,
	02 Apr 2012 02:00:50 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Mon, 2 Apr 2012 02:00:50 -0700 (PDT)
In-Reply-To: <1333199711583-5608788.post@n5.nabble.com>
References: <1333199711583-5608788.post@n5.nabble.com>
Date: Mon, 2 Apr 2012 10:00:50 +0100
X-Google-Sender-Auth: oM2rOLkmEIZCZ336DZG-3XD1o7M
Message-ID: <CAFLBxZa7fha+Hh2v7gY0Cgn8eGmnKhWQ2TCdBtp8wSb8v4kOCg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: SuperWong <wang_nets@163.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] I have used printk in some hypercall.But Dom0 can't
 be booted.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 2:15 PM, SuperWong <wang_nets@163.com> wrote:
> Hi all:
> =A0 =A0I wanted to record some information about some hypercalls and trac=
e the
> hypercalls.So I have tried to add printk in the hypercall.But the Dom0 ca=
n't
> be *booted*.For example, I add printk at the beginning of do_set_trap_tab=
le.
> printk("<1>""HYPERCALL:do_set_trap_table");
> Why I can't add printk in hypercall?
> Does anyone know the reason and the solution?Thanks.

There's no way we can answer this question without the output of the
dom0 saying why it failed.

The best way to do this is to set up a serial console:
 http://wiki.xen.org/wiki/Xen_Serial_Console

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:01:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEd8B-0002Ei-RJ; Mon, 02 Apr 2012 09:00:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SEd8A-0002Eb-BM
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:00:54 +0000
Received: from [193.109.254.147:26241] by server-7.bemta-14.messagelabs.com id
	41/A0-01627-5CA697F4; Mon, 02 Apr 2012 09:00:53 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333357250!2974553!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2433 invoked from network); 2 Apr 2012 09:00:52 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:00:52 -0000
Received: by qcsp15 with SMTP id p15so1794057qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Apr 2012 02:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Arv5pGbdDpP7JhlpC0NrWZuFbaM+hzIx4AR2vaGmNtI=;
	b=zExtJiaqswfi2renJqQs6c50QalwfBQ3/+sdag15mG5LIKstIdgCcYwCMf9o0hF6d/
	kBbGIekqhryvBlfGGUV0bDkB+18ONYtBGoZ0xwWANUu/U2Qy4Euob4BTqnKGGvuqkYnL
	0GLZIftWo530qYseSFvQh5f+7Ihu4/oV6lzOad+adkc6dTK2cIzXjMUv2bMxpUtOdWFu
	my9ENzsUJLkWybU+ufuJ3PLH/xEl3hgPRNKO5GNci7mOSt8vjYlXXMiF+lvINaaZealc
	d3u9NF3ku3gaCrfvn4yMUhios1RM/pDrzznRNJ8zUfwKJ3EFAOAfc0re/nYC2R9scTgq
	5hIw==
MIME-Version: 1.0
Received: by 10.224.96.66 with SMTP id g2mr10134884qan.47.1333357250145; Mon,
	02 Apr 2012 02:00:50 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Mon, 2 Apr 2012 02:00:50 -0700 (PDT)
In-Reply-To: <1333199711583-5608788.post@n5.nabble.com>
References: <1333199711583-5608788.post@n5.nabble.com>
Date: Mon, 2 Apr 2012 10:00:50 +0100
X-Google-Sender-Auth: oM2rOLkmEIZCZ336DZG-3XD1o7M
Message-ID: <CAFLBxZa7fha+Hh2v7gY0Cgn8eGmnKhWQ2TCdBtp8wSb8v4kOCg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: SuperWong <wang_nets@163.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] I have used printk in some hypercall.But Dom0 can't
 be booted.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 2:15 PM, SuperWong <wang_nets@163.com> wrote:
> Hi all:
> =A0 =A0I wanted to record some information about some hypercalls and trac=
e the
> hypercalls.So I have tried to add printk in the hypercall.But the Dom0 ca=
n't
> be *booted*.For example, I add printk at the beginning of do_set_trap_tab=
le.
> printk("<1>""HYPERCALL:do_set_trap_table");
> Why I can't add printk in hypercall?
> Does anyone know the reason and the solution?Thanks.

There's no way we can answer this question without the output of the
dom0 saying why it failed.

The best way to do this is to set up a serial console:
 http://wiki.xen.org/wiki/Xen_Serial_Console

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdRm-0002W2-NS; Mon, 02 Apr 2012 09:21:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEdRl-0002Vx-Cy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:21:09 +0000
Received: from [85.158.143.99:42350] by server-3.bemta-4.messagelabs.com id
	60/39-05853-48F697F4; Mon, 02 Apr 2012 09:21:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333358467!16159125!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI2MjU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI2MjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24598 invoked from network); 2 Apr 2012 09:21:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 09:21:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333358467; l=920;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=iwtzpEliyWz8hv8sYL6SONrTLKc=;
	b=kBsKiYaZ41uny3PqPbNS6hPfxKljMbR2m2fxM9znr0rjGsFfCS0c3PIOIDEOo9O4Oxs
	F0jWuXtPieNv3n2tRgpLBLt3qg5J1CxVqYSyzu8YgJkD5AlDBfgVb49GH8KqWgDsttCnN
	dpaReJZdzKBsGSoZa5hJDdW4kL6rN1C6S9I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjS0PFQXU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-083-162.pools.arcor-ip.net [88.65.83.162])
	by smtp.strato.de (jimi mo50) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02bfdo328pVSU ;
	Mon, 2 Apr 2012 11:21:06 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0C42418637; Mon,  2 Apr 2012 11:21:05 +0200 (CEST)
Date: Mon, 2 Apr 2012 11:21:05 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120402092105.GA25886@aepfle.de>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
	<1333356972.25602.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333356972.25602.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Mohit Dhingra <mohitdhingras@gmail.com>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Campbell wrote:

> On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
> > Hello All,
> > 
> > I am a newbie to Linux and Xen. I tried compiling Xen Source code (I
> > want to make some changes and see how it works), but it failed on my
> > system as it couldn't find gnu-stubs32.h. Later, on looking at
> > Makefile, I figured out that for x86_64, it is not yet supported !! 

> WRT gnu-stubs32.h I suspect you are missing some -devel package or
> other. I don't know about how SuSE lays things out but you should locate
> the package containing this file and install it. Googling suggests that
> perhaps you meant gnu/stubs32.h? In which case you probably want to
> install glibc-devel.

Running configure and/or make in a 32bit shell is not needed.
"zypper in gcc-32bit glibc-devel-32bit" will install the required
packages to compile the 32bit parts in the firmware.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdRm-0002W2-NS; Mon, 02 Apr 2012 09:21:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEdRl-0002Vx-Cy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:21:09 +0000
Received: from [85.158.143.99:42350] by server-3.bemta-4.messagelabs.com id
	60/39-05853-48F697F4; Mon, 02 Apr 2012 09:21:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333358467!16159125!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI2MjU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI2MjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24598 invoked from network); 2 Apr 2012 09:21:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 09:21:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333358467; l=920;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=iwtzpEliyWz8hv8sYL6SONrTLKc=;
	b=kBsKiYaZ41uny3PqPbNS6hPfxKljMbR2m2fxM9znr0rjGsFfCS0c3PIOIDEOo9O4Oxs
	F0jWuXtPieNv3n2tRgpLBLt3qg5J1CxVqYSyzu8YgJkD5AlDBfgVb49GH8KqWgDsttCnN
	dpaReJZdzKBsGSoZa5hJDdW4kL6rN1C6S9I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjS0PFQXU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-083-162.pools.arcor-ip.net [88.65.83.162])
	by smtp.strato.de (jimi mo50) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02bfdo328pVSU ;
	Mon, 2 Apr 2012 11:21:06 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0C42418637; Mon,  2 Apr 2012 11:21:05 +0200 (CEST)
Date: Mon, 2 Apr 2012 11:21:05 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120402092105.GA25886@aepfle.de>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
	<1333356972.25602.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333356972.25602.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Mohit Dhingra <mohitdhingras@gmail.com>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Campbell wrote:

> On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
> > Hello All,
> > 
> > I am a newbie to Linux and Xen. I tried compiling Xen Source code (I
> > want to make some changes and see how it works), but it failed on my
> > system as it couldn't find gnu-stubs32.h. Later, on looking at
> > Makefile, I figured out that for x86_64, it is not yet supported !! 

> WRT gnu-stubs32.h I suspect you are missing some -devel package or
> other. I don't know about how SuSE lays things out but you should locate
> the package containing this file and install it. Googling suggests that
> perhaps you meant gnu/stubs32.h? In which case you probably want to
> install glibc-devel.

Running configure and/or make in a 32bit shell is not needed.
"zypper in gcc-32bit glibc-devel-32bit" will install the required
packages to compile the 32bit parts in the firmware.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:21:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdRy-0002Wc-3U; Mon, 02 Apr 2012 09:21:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEdRw-0002WV-Lh
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:21:20 +0000
Received: from [85.158.138.51:26776] by server-9.bemta-3.messagelabs.com id
	42/BA-10923-F8F697F4; Mon, 02 Apr 2012 09:21:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333358477!20344160!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12961 invoked from network); 2 Apr 2012 09:21:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23773291"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 05:21:16 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	05:21:16 -0400
Message-ID: <4F796F7C.4070400@citrix.com>
Date: Mon, 2 Apr 2012 10:21:00 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>	
	<1332443876-28506-3-git-send-email-david.vrabel@citrix.com>
	<1333123166.15932.113.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333123166.15932.113.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/03/12 16:59, Ian Campbell wrote:
> On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Build a flat device tree for dom0 based on the one supplied to Xen.
>> The following changes are made:
>>
>>   * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
>>     bootargs.
>>
>>   * In all memory nodes, the reg parameters are adjusted to reflect
>>     the amount of memory dom0 can use.  The p2m is updated using this
>>     info.
>>
>> Support for passing ATAGS to dom0 is removed.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  xen/arch/arm/domain_build.c         |  257 +++++++++++++++++++++++++++++------
>>  xen/arch/arm/kernel.c               |    2 +-
>>  xen/arch/arm/kernel.h               |    8 +-
>>  xen/common/device_tree.c            |   47 ++++--
>>  xen/include/xen/device_tree.h       |    8 +
>>  xen/include/xen/libfdt/libfdt_env.h |    3 +
>>  6 files changed, 265 insertions(+), 60 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 15632f7..b4c0452 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -6,6 +6,10 @@
>>  #include <xen/sched.h>
>>  #include <asm/irq.h>
>>  #include <asm/regs.h>
>> +#include <xen/errno.h>
>> +#include <xen/device_tree.h>
>> +#include <xen/libfdt/libfdt.h>
>> +#include <xen/guest_access.h>
>>
>>  #include "gic.h"
>>  #include "kernel.h"
>> @@ -13,6 +17,13 @@
>>  static unsigned int __initdata opt_dom0_max_vcpus;
>>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>>
>> +/*
>> + * Amount of extra space required to dom0's device tree.  No new nodes
>> + * are added (yet) but one terminating reserve map entry (16 bytes) is
>> + * added.
>> + */
>> +#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
>> +
>>  struct vcpu *__init alloc_dom0_vcpu0(void)
>>  {
>>      if ( opt_dom0_max_vcpus == 0 )
>> @@ -28,43 +39,210 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
>>      return alloc_vcpu(dom0, 0, 0);
>>  }
>>
>> -extern void guest_mode_entry(void);
>> +static void set_memory_reg(struct domain *d, struct kernel_info *kinfo,
>> +                           const void *fdt,
>> +                           const u32 *cell, int address_cells, int size_cells,
>> +                           u32 *new_cell, int *len)
>> +{
>> +    int reg_size = (address_cells + size_cells) * sizeof(*cell);
>> +    int l;
>> +    u64 start;
>> +    u64 size;
>> +
>> +    l = *len;
> 
>> +
>> +    while ( kinfo->unassigned_mem > 0 && l >= reg_size
>> +            && kinfo->mem.nr_banks < NR_MEM_BANKS )
>> +    {
>> +        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
>> +        if ( size > kinfo->unassigned_mem )
>> +            size = kinfo->unassigned_mem;
>> +
>> +        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
> 
> This assumes/requires that address_cells and size_cells a 1, right? If
> they end up being 2 or more then device_tree_get_reg will trample on the
> stack via &start and &size.

No.  address_cells and size_cells can be 1 or 2.  This is enough for 64
addresses.

>> +
>> +        printk("Populate P2M %#llx->%#llx\n", start, start + size);
>> +        p2m_populate_ram(d, start, start + size);
>> +        kinfo->mem.bank[kinfo->mem.nr_banks].start = start;
>> +        kinfo->mem.bank[kinfo->mem.nr_banks].size = size;
>> +        kinfo->mem.nr_banks++;
>> +        kinfo->unassigned_mem -= size;
>> +
>> +        l -= reg_size;
>> +    }
>> +
>> +    *len -= l;
> 
> I had a bit of trouble following the logic wrt l and the updating of
> *len in this function.

I've updated this as per your suggestion.

>> --- a/xen/include/xen/libfdt/libfdt_env.h
>> +++ b/xen/include/xen/libfdt/libfdt_env.h
>> @@ -13,4 +13,7 @@
>>  #define fdt64_to_cpu(x) be64_to_cpu(x)
>>  #define cpu_to_fdt64(x) cpu_to_be64(x)
>>
>> +/* Xen-specific libfdt error code. */
>> +#define FDT_ERR_XEN(err) (FDT_ERR_MAX + (err))
> 
> Looks like the only user is FDT_ERR_XEN(ENOMEM) which could as well be
> FDT_ERR_NOSPACE?

No.  FDT_ERR_NOSPACE means the buffer isn't large enough to add new
nodes etc.  This needs to be a different error code from a memory
allocation failure.

> FWIW I think adding a new error code would be a fair reason to diverge
> in a controlled way from the pristine upstream source.

I don't know what you're asking for here.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:21:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdRy-0002Wc-3U; Mon, 02 Apr 2012 09:21:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEdRw-0002WV-Lh
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:21:20 +0000
Received: from [85.158.138.51:26776] by server-9.bemta-3.messagelabs.com id
	42/BA-10923-F8F697F4; Mon, 02 Apr 2012 09:21:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333358477!20344160!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12961 invoked from network); 2 Apr 2012 09:21:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23773291"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 05:21:16 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	05:21:16 -0400
Message-ID: <4F796F7C.4070400@citrix.com>
Date: Mon, 2 Apr 2012 10:21:00 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>	
	<1332443876-28506-3-git-send-email-david.vrabel@citrix.com>
	<1333123166.15932.113.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333123166.15932.113.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/03/12 16:59, Ian Campbell wrote:
> On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Build a flat device tree for dom0 based on the one supplied to Xen.
>> The following changes are made:
>>
>>   * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
>>     bootargs.
>>
>>   * In all memory nodes, the reg parameters are adjusted to reflect
>>     the amount of memory dom0 can use.  The p2m is updated using this
>>     info.
>>
>> Support for passing ATAGS to dom0 is removed.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  xen/arch/arm/domain_build.c         |  257 +++++++++++++++++++++++++++++------
>>  xen/arch/arm/kernel.c               |    2 +-
>>  xen/arch/arm/kernel.h               |    8 +-
>>  xen/common/device_tree.c            |   47 ++++--
>>  xen/include/xen/device_tree.h       |    8 +
>>  xen/include/xen/libfdt/libfdt_env.h |    3 +
>>  6 files changed, 265 insertions(+), 60 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 15632f7..b4c0452 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -6,6 +6,10 @@
>>  #include <xen/sched.h>
>>  #include <asm/irq.h>
>>  #include <asm/regs.h>
>> +#include <xen/errno.h>
>> +#include <xen/device_tree.h>
>> +#include <xen/libfdt/libfdt.h>
>> +#include <xen/guest_access.h>
>>
>>  #include "gic.h"
>>  #include "kernel.h"
>> @@ -13,6 +17,13 @@
>>  static unsigned int __initdata opt_dom0_max_vcpus;
>>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>>
>> +/*
>> + * Amount of extra space required to dom0's device tree.  No new nodes
>> + * are added (yet) but one terminating reserve map entry (16 bytes) is
>> + * added.
>> + */
>> +#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
>> +
>>  struct vcpu *__init alloc_dom0_vcpu0(void)
>>  {
>>      if ( opt_dom0_max_vcpus == 0 )
>> @@ -28,43 +39,210 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
>>      return alloc_vcpu(dom0, 0, 0);
>>  }
>>
>> -extern void guest_mode_entry(void);
>> +static void set_memory_reg(struct domain *d, struct kernel_info *kinfo,
>> +                           const void *fdt,
>> +                           const u32 *cell, int address_cells, int size_cells,
>> +                           u32 *new_cell, int *len)
>> +{
>> +    int reg_size = (address_cells + size_cells) * sizeof(*cell);
>> +    int l;
>> +    u64 start;
>> +    u64 size;
>> +
>> +    l = *len;
> 
>> +
>> +    while ( kinfo->unassigned_mem > 0 && l >= reg_size
>> +            && kinfo->mem.nr_banks < NR_MEM_BANKS )
>> +    {
>> +        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
>> +        if ( size > kinfo->unassigned_mem )
>> +            size = kinfo->unassigned_mem;
>> +
>> +        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
> 
> This assumes/requires that address_cells and size_cells a 1, right? If
> they end up being 2 or more then device_tree_get_reg will trample on the
> stack via &start and &size.

No.  address_cells and size_cells can be 1 or 2.  This is enough for 64
addresses.

>> +
>> +        printk("Populate P2M %#llx->%#llx\n", start, start + size);
>> +        p2m_populate_ram(d, start, start + size);
>> +        kinfo->mem.bank[kinfo->mem.nr_banks].start = start;
>> +        kinfo->mem.bank[kinfo->mem.nr_banks].size = size;
>> +        kinfo->mem.nr_banks++;
>> +        kinfo->unassigned_mem -= size;
>> +
>> +        l -= reg_size;
>> +    }
>> +
>> +    *len -= l;
> 
> I had a bit of trouble following the logic wrt l and the updating of
> *len in this function.

I've updated this as per your suggestion.

>> --- a/xen/include/xen/libfdt/libfdt_env.h
>> +++ b/xen/include/xen/libfdt/libfdt_env.h
>> @@ -13,4 +13,7 @@
>>  #define fdt64_to_cpu(x) be64_to_cpu(x)
>>  #define cpu_to_fdt64(x) cpu_to_be64(x)
>>
>> +/* Xen-specific libfdt error code. */
>> +#define FDT_ERR_XEN(err) (FDT_ERR_MAX + (err))
> 
> Looks like the only user is FDT_ERR_XEN(ENOMEM) which could as well be
> FDT_ERR_NOSPACE?

No.  FDT_ERR_NOSPACE means the buffer isn't large enough to add new
nodes etc.  This needs to be a different error code from a memory
allocation failure.

> FWIW I think adding a new error code would be a fair reason to diverge
> in a controlled way from the pristine upstream source.

I don't know what you're asking for here.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:27:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdXF-0002m8-Re; Mon, 02 Apr 2012 09:26:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1SEdXE-0002lz-8p
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:26:48 +0000
Received: from [85.158.143.35:4496] by server-2.bemta-4.messagelabs.com id
	B8/63-17550-7D0797F4; Mon, 02 Apr 2012 09:26:47 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333358806!7179562!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14122 invoked from network); 2 Apr 2012 09:26:46 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Apr 2012 09:26:46 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <tglx@linutronix.de>)
	id 1SEdWr-0008VJ-4J; Mon, 02 Apr 2012 11:26:25 +0200
Date: Mon, 2 Apr 2012 11:26:23 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F7858C0.90405@redhat.com>
Message-ID: <alpine.LFD.2.02.1204021117560.2542@ionos>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<4F7858C0.90405@redhat.com>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 1 Apr 2012, Avi Kivity wrote:
> On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
> > On Fri, 30 Mar 2012, H. Peter Anvin wrote:
> >
> > > What is the current status of this patchset?  I haven't looked at it too
> > > closely because I have been focused on 3.4 up until now...
> >
> > The real question is whether these heuristics are the correct approach
> > or not.
> >
> > If I look at it from the non virtualized kernel side then this is ass
> > backwards. We know already that we are holding a spinlock which might
> > cause other (v)cpus going into eternal spin. The non virtualized
> > kernel solves this by disabling preemption and therefor getting out of
> > the critical section as fast as possible,
> >
> > The virtualization problem reminds me a lot of the problem which RT
> > kernels are observing where non raw spinlocks are turned into
> > "sleeping spinlocks" and therefor can cause throughput issues for non
> > RT workloads.
> >
> > Though the virtualized situation is even worse. Any preempted guest
> > section which holds a spinlock is prone to cause unbound delays.
> >
> > The paravirt ticketlock solution can only mitigate the problem, but
> > not solve it. With massive overcommit there is always a way to trigger
> > worst case scenarious unless you are educating the scheduler to cope
> > with that.
> >
> > So if we need to fiddle with the scheduler and frankly that's the only
> > way to get a real gain (the numbers, which are achieved by this
> > patches, are not that impressive) then the question arises whether we
> > should turn the whole thing around.
> >
> > I know that Peter is going to go berserk on me, but if we are running
> > a paravirt guest then it's simple to provide a mechanism which allows
> > the host (aka hypervisor) to check that in the guest just by looking
> > at some global state.
> >
> > So if a guest exits due to an external event it's easy to inspect the
> > state of that guest and avoid to schedule away when it was interrupted
> > in a spinlock held section. That guest/host shared state needs to be
> > modified to indicate the guest to invoke an exit when the last nested
> > lock has been released.
> 
> Interesting idea (I think it has been raised before btw, don't recall by
> who).

Someoen posted a pointer to that old thread.

> One thing about it is that it can give many false positives.  Consider a
> fine-grained spinlock that is being accessed by many threads.  That is,
> the lock is taken and released with high frequency, but there is no
> contention, because each vcpu is accessing a different instance.  So the
> host scheduler will needlessly delay preemption of vcpus that happen to
> be holding a lock, even though this gains nothing.

You're talking about per cpu locks, right? I can see the point there,
but per cpu stuff might be worth annotating to avoid this.
 
> A second issue may happen with a lock that is taken and released with
> high frequency, with a high hold percentage.  The host scheduler may
> always sample the guest in a held state, leading it to conclude that
> it's exceeding its timeout when in fact the lock is held for a short
> time only.

Well, no. You can avoid that.

host		VCPU
		spin_lock()
		 modify_global_state()
   	exit
check_global_state()
mark_global_state()
reschedule vcpu

		spin_unlock()
		 check_global_state()
		  trigger_exit()

So when an exit occures in the locked section, then the host can mark
the global state to tell the guest to issue a trap on unlock.
 
> > Of course this needs to be time bound, so a rogue guest cannot
> > monopolize the cpu forever, but that's the least to worry about
> > problem simply because a guest which does not get out of a spinlocked
> > region within a certain amount of time is borked and elegible to
> > killing anyway.
> 
> Hopefully not killing!  Just because a guest doesn't scale well, or even
> if it's deadlocked, doesn't mean it should be killed.  Just preempt it.

:)
 
> > Thoughts ?
> 
> It's certainly interesting.  Maybe a combination is worthwhile - prevent
> lockholder preemption for a short period of time AND put waiters to
> sleep in case that period is insufficient to release the lock.

Right, but as Srivatsa pointed out this still needs the ticket lock
ordering support to avoid that guests are completely starved.

Thanks,

	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:27:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdXF-0002m8-Re; Mon, 02 Apr 2012 09:26:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1SEdXE-0002lz-8p
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:26:48 +0000
Received: from [85.158.143.35:4496] by server-2.bemta-4.messagelabs.com id
	B8/63-17550-7D0797F4; Mon, 02 Apr 2012 09:26:47 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333358806!7179562!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14122 invoked from network); 2 Apr 2012 09:26:46 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Apr 2012 09:26:46 -0000
Received: from localhost ([127.0.0.1]) by Galois.linutronix.de with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <tglx@linutronix.de>)
	id 1SEdWr-0008VJ-4J; Mon, 02 Apr 2012 11:26:25 +0200
Date: Mon, 2 Apr 2012 11:26:23 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F7858C0.90405@redhat.com>
Message-ID: <alpine.LFD.2.02.1204021117560.2542@ionos>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<4F7858C0.90405@redhat.com>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 1 Apr 2012, Avi Kivity wrote:
> On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
> > On Fri, 30 Mar 2012, H. Peter Anvin wrote:
> >
> > > What is the current status of this patchset?  I haven't looked at it too
> > > closely because I have been focused on 3.4 up until now...
> >
> > The real question is whether these heuristics are the correct approach
> > or not.
> >
> > If I look at it from the non virtualized kernel side then this is ass
> > backwards. We know already that we are holding a spinlock which might
> > cause other (v)cpus going into eternal spin. The non virtualized
> > kernel solves this by disabling preemption and therefor getting out of
> > the critical section as fast as possible,
> >
> > The virtualization problem reminds me a lot of the problem which RT
> > kernels are observing where non raw spinlocks are turned into
> > "sleeping spinlocks" and therefor can cause throughput issues for non
> > RT workloads.
> >
> > Though the virtualized situation is even worse. Any preempted guest
> > section which holds a spinlock is prone to cause unbound delays.
> >
> > The paravirt ticketlock solution can only mitigate the problem, but
> > not solve it. With massive overcommit there is always a way to trigger
> > worst case scenarious unless you are educating the scheduler to cope
> > with that.
> >
> > So if we need to fiddle with the scheduler and frankly that's the only
> > way to get a real gain (the numbers, which are achieved by this
> > patches, are not that impressive) then the question arises whether we
> > should turn the whole thing around.
> >
> > I know that Peter is going to go berserk on me, but if we are running
> > a paravirt guest then it's simple to provide a mechanism which allows
> > the host (aka hypervisor) to check that in the guest just by looking
> > at some global state.
> >
> > So if a guest exits due to an external event it's easy to inspect the
> > state of that guest and avoid to schedule away when it was interrupted
> > in a spinlock held section. That guest/host shared state needs to be
> > modified to indicate the guest to invoke an exit when the last nested
> > lock has been released.
> 
> Interesting idea (I think it has been raised before btw, don't recall by
> who).

Someoen posted a pointer to that old thread.

> One thing about it is that it can give many false positives.  Consider a
> fine-grained spinlock that is being accessed by many threads.  That is,
> the lock is taken and released with high frequency, but there is no
> contention, because each vcpu is accessing a different instance.  So the
> host scheduler will needlessly delay preemption of vcpus that happen to
> be holding a lock, even though this gains nothing.

You're talking about per cpu locks, right? I can see the point there,
but per cpu stuff might be worth annotating to avoid this.
 
> A second issue may happen with a lock that is taken and released with
> high frequency, with a high hold percentage.  The host scheduler may
> always sample the guest in a held state, leading it to conclude that
> it's exceeding its timeout when in fact the lock is held for a short
> time only.

Well, no. You can avoid that.

host		VCPU
		spin_lock()
		 modify_global_state()
   	exit
check_global_state()
mark_global_state()
reschedule vcpu

		spin_unlock()
		 check_global_state()
		  trigger_exit()

So when an exit occures in the locked section, then the host can mark
the global state to tell the guest to issue a trap on unlock.
 
> > Of course this needs to be time bound, so a rogue guest cannot
> > monopolize the cpu forever, but that's the least to worry about
> > problem simply because a guest which does not get out of a spinlocked
> > region within a certain amount of time is borked and elegible to
> > killing anyway.
> 
> Hopefully not killing!  Just because a guest doesn't scale well, or even
> if it's deadlocked, doesn't mean it should be killed.  Just preempt it.

:)
 
> > Thoughts ?
> 
> It's certainly interesting.  Maybe a combination is worthwhile - prevent
> lockholder preemption for a short period of time AND put waiters to
> sleep in case that period is insufficient to release the lock.

Right, but as Srivatsa pointed out this still needs the ticket lock
ordering support to avoid that guests are completely starved.

Thanks,

	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:30:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdaW-0002vH-KX; Mon, 02 Apr 2012 09:30:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi@firstfloor.org>) id 1SDk9Z-0002Z8-7E
	for xen-devel@lists.xensource.com; Fri, 30 Mar 2012 22:18:41 +0000
Received: from [85.158.143.35:52540] by server-3.bemta-4.messagelabs.com id
	A6/D3-05853-041367F4; Fri, 30 Mar 2012 22:18:40 +0000
X-Env-Sender: andi@firstfloor.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333145919!11550018!1
X-Originating-IP: [213.235.205.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30908 invoked from network); 30 Mar 2012 22:18:39 -0000
Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Mar 2012 22:18:39 -0000
Received: by one.firstfloor.org (Postfix, from userid 503)
	id 32171200080; Sat, 31 Mar 2012 00:18:36 +0200 (CEST)
Date: Sat, 31 Mar 2012 00:18:36 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120330221836.GN17822@one.firstfloor.org>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
User-Agent: Mutt/1.4.2.2i
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:30:11 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be

On a large system under high contention sleeping can perform surprisingly
well. pthread mutexes have a tendency to beat kernel spinlocks there.
So avoiding sleeping locks completely (that is what pv locks are
essentially) is not necessarily that good.

Your proposal is probably only a good idea on low contention
and relatively small systems.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:30:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdaW-0002vH-KX; Mon, 02 Apr 2012 09:30:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi@firstfloor.org>) id 1SDk9Z-0002Z8-7E
	for xen-devel@lists.xensource.com; Fri, 30 Mar 2012 22:18:41 +0000
Received: from [85.158.143.35:52540] by server-3.bemta-4.messagelabs.com id
	A6/D3-05853-041367F4; Fri, 30 Mar 2012 22:18:40 +0000
X-Env-Sender: andi@firstfloor.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333145919!11550018!1
X-Originating-IP: [213.235.205.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30908 invoked from network); 30 Mar 2012 22:18:39 -0000
Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Mar 2012 22:18:39 -0000
Received: by one.firstfloor.org (Postfix, from userid 503)
	id 32171200080; Sat, 31 Mar 2012 00:18:36 +0200 (CEST)
Date: Sat, 31 Mar 2012 00:18:36 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120330221836.GN17822@one.firstfloor.org>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
User-Agent: Mutt/1.4.2.2i
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:30:11 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be

On a large system under high contention sleeping can perform surprisingly
well. pthread mutexes have a tendency to beat kernel spinlocks there.
So avoiding sleeping locks completely (that is what pv locks are
essentially) is not necessarily that good.

Your proposal is probably only a good idea on low contention
and relatively small systems.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:30:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdaW-0002vT-Vt; Mon, 02 Apr 2012 09:30:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi@firstfloor.org>) id 1SDls5-0003fQ-Nt
	for xen-devel@lists.xensource.com; Sat, 31 Mar 2012 00:08:45 +0000
Received: from [193.109.254.147:4332] by server-7.bemta-14.messagelabs.com id
	DC/37-01627-D0B467F4; Sat, 31 Mar 2012 00:08:45 +0000
X-Env-Sender: andi@firstfloor.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333152524!2805393!1
X-Originating-IP: [213.235.205.2]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6779 invoked from network); 31 Mar 2012 00:08:44 -0000
Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Mar 2012 00:08:44 -0000
Received: by one.firstfloor.org (Postfix, from userid 503)
	id 7FB63200080; Sat, 31 Mar 2012 02:08:43 +0200 (CEST)
Date: Sat, 31 Mar 2012 02:08:43 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120331000843.GO17822@one.firstfloor.org>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120330221836.GN17822@one.firstfloor.org>
	<alpine.LFD.2.02.1203310044580.2542@ionos>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1203310044580.2542@ionos>
User-Agent: Mutt/1.4.2.2i
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:30:11 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 01:04:41AM +0200, Thomas "Kubys" Gleixner wrote:
> On Sat, 31 Mar 2012, Andi Kleen wrote:
> 
> > > So if a guest exits due to an external event it's easy to inspect the
> > > state of that guest and avoid to schedule away when it was interrupted
> > > in a spinlock held section. That guest/host shared state needs to be
> > 
> > On a large system under high contention sleeping can perform surprisingly
> > well. pthread mutexes have a tendency to beat kernel spinlocks there.
> > So avoiding sleeping locks completely (that is what pv locks are
> > essentially) is not necessarily that good.
> 
> Care to back that up with numbers and proper trace evidence instead of
> handwaving?

E.g. my plumbers presentations on lock and mm scalability from last year has some 
graphs that show this very clearly, plus some additional data on the mutexes. 
This compares to the glibc futex locks, which perform much better than the kernel 
mutex locks on larger systems under higher contention

Given your tone I will not supply an URL. I'm sure you can find it if you
need it.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:30:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdaW-0002vT-Vt; Mon, 02 Apr 2012 09:30:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi@firstfloor.org>) id 1SDls5-0003fQ-Nt
	for xen-devel@lists.xensource.com; Sat, 31 Mar 2012 00:08:45 +0000
Received: from [193.109.254.147:4332] by server-7.bemta-14.messagelabs.com id
	DC/37-01627-D0B467F4; Sat, 31 Mar 2012 00:08:45 +0000
X-Env-Sender: andi@firstfloor.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333152524!2805393!1
X-Originating-IP: [213.235.205.2]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6779 invoked from network); 31 Mar 2012 00:08:44 -0000
Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Mar 2012 00:08:44 -0000
Received: by one.firstfloor.org (Postfix, from userid 503)
	id 7FB63200080; Sat, 31 Mar 2012 02:08:43 +0200 (CEST)
Date: Sat, 31 Mar 2012 02:08:43 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120331000843.GO17822@one.firstfloor.org>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120330221836.GN17822@one.firstfloor.org>
	<alpine.LFD.2.02.1203310044580.2542@ionos>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1203310044580.2542@ionos>
User-Agent: Mutt/1.4.2.2i
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:30:11 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 01:04:41AM +0200, Thomas "Kubys" Gleixner wrote:
> On Sat, 31 Mar 2012, Andi Kleen wrote:
> 
> > > So if a guest exits due to an external event it's easy to inspect the
> > > state of that guest and avoid to schedule away when it was interrupted
> > > in a spinlock held section. That guest/host shared state needs to be
> > 
> > On a large system under high contention sleeping can perform surprisingly
> > well. pthread mutexes have a tendency to beat kernel spinlocks there.
> > So avoiding sleeping locks completely (that is what pv locks are
> > essentially) is not necessarily that good.
> 
> Care to back that up with numbers and proper trace evidence instead of
> handwaving?

E.g. my plumbers presentations on lock and mm scalability from last year has some 
graphs that show this very clearly, plus some additional data on the mutexes. 
This compares to the glibc futex locks, which perform much better than the kernel 
mutex locks on larger systems under higher contention

Given your tone I will not supply an URL. I'm sure you can find it if you
need it.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdb8-00030c-Dn; Mon, 02 Apr 2012 09:30:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdb7-00030P-Ne
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:30:49 +0000
Received: from [85.158.143.99:49458] by server-1.bemta-4.messagelabs.com id
	71/4D-20925-9C1797F4; Mon, 02 Apr 2012 09:30:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333359048!16647188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13609 invoked from network); 2 Apr 2012 09:30:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:30:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11716585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:30:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:30:47 +0100
Message-ID: <1333359046.25602.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 10:30:46 +0100
In-Reply-To: <4F796F7C.4070400@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>
	<1332443876-28506-3-git-send-email-david.vrabel@citrix.com>
	<1333123166.15932.113.camel@zakaz.uk.xensource.com>
	<4F796F7C.4070400@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 10:21 +0100, David Vrabel wrote:
> On 30/03/12 16:59, Ian Campbell wrote:
> > On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> Build a flat device tree for dom0 based on the one supplied to Xen.
> >> The following changes are made:
> >>
> >>   * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
> >>     bootargs.
> >>
> >>   * In all memory nodes, the reg parameters are adjusted to reflect
> >>     the amount of memory dom0 can use.  The p2m is updated using this
> >>     info.
> >>
> >> Support for passing ATAGS to dom0 is removed.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  xen/arch/arm/domain_build.c         |  257 +++++++++++++++++++++++++++++------
> >>  xen/arch/arm/kernel.c               |    2 +-
> >>  xen/arch/arm/kernel.h               |    8 +-
> >>  xen/common/device_tree.c            |   47 ++++--
> >>  xen/include/xen/device_tree.h       |    8 +
> >>  xen/include/xen/libfdt/libfdt_env.h |    3 +
> >>  6 files changed, 265 insertions(+), 60 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index 15632f7..b4c0452 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -6,6 +6,10 @@
> >>  #include <xen/sched.h>
> >>  #include <asm/irq.h>
> >>  #include <asm/regs.h>
> >> +#include <xen/errno.h>
> >> +#include <xen/device_tree.h>
> >> +#include <xen/libfdt/libfdt.h>
> >> +#include <xen/guest_access.h>
> >>
> >>  #include "gic.h"
> >>  #include "kernel.h"
> >> @@ -13,6 +17,13 @@
> >>  static unsigned int __initdata opt_dom0_max_vcpus;
> >>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> >>
> >> +/*
> >> + * Amount of extra space required to dom0's device tree.  No new nodes
> >> + * are added (yet) but one terminating reserve map entry (16 bytes) is
> >> + * added.
> >> + */
> >> +#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
> >> +
> >>  struct vcpu *__init alloc_dom0_vcpu0(void)
> >>  {
> >>      if ( opt_dom0_max_vcpus == 0 )
> >> @@ -28,43 +39,210 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
> >>      return alloc_vcpu(dom0, 0, 0);
> >>  }
> >>
> >> -extern void guest_mode_entry(void);
> >> +static void set_memory_reg(struct domain *d, struct kernel_info *kinfo,
> >> +                           const void *fdt,
> >> +                           const u32 *cell, int address_cells, int size_cells,
> >> +                           u32 *new_cell, int *len)
> >> +{
> >> +    int reg_size = (address_cells + size_cells) * sizeof(*cell);
> >> +    int l;
> >> +    u64 start;
> >> +    u64 size;
> >> +
> >> +    l = *len;
> > 
> >> +
> >> +    while ( kinfo->unassigned_mem > 0 && l >= reg_size
> >> +            && kinfo->mem.nr_banks < NR_MEM_BANKS )
> >> +    {
> >> +        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
> >> +        if ( size > kinfo->unassigned_mem )
> >> +            size = kinfo->unassigned_mem;
> >> +
> >> +        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
> > 
> > This assumes/requires that address_cells and size_cells a 1, right? If
> > they end up being 2 or more then device_tree_get_reg will trample on the
> > stack via &start and &size.
> 
> No.  address_cells and size_cells can be 1 or 2.

Where is that checked or enforced? What happens if someone feeds us a
DTB with 3? Or are you saying that this isn't possible (perhaps due to
some constraint in DTB itself)?

> >> --- a/xen/include/xen/libfdt/libfdt_env.h
> >> +++ b/xen/include/xen/libfdt/libfdt_env.h
> >> @@ -13,4 +13,7 @@
> >>  #define fdt64_to_cpu(x) be64_to_cpu(x)
> >>  #define cpu_to_fdt64(x) cpu_to_be64(x)
> >>
> >> +/* Xen-specific libfdt error code. */
> >> +#define FDT_ERR_XEN(err) (FDT_ERR_MAX + (err))
> > 
> > Looks like the only user is FDT_ERR_XEN(ENOMEM) which could as well be
> > FDT_ERR_NOSPACE?
> 
> No.  FDT_ERR_NOSPACE means the buffer isn't large enough to add new
> nodes etc.  This needs to be a different error code from a memory
> allocation failure.

OK.

> > FWIW I think adding a new error code would be a fair reason to diverge
> > in a controlled way from the pristine upstream source.
> 
> I don't know what you're asking for here.

I was suggesting that it would be fine to just add a new error code,
IMHO it's a reasonable reason to diverge from upstream. Could perhaps
even send them the patch?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdb8-00030c-Dn; Mon, 02 Apr 2012 09:30:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdb7-00030P-Ne
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:30:49 +0000
Received: from [85.158.143.99:49458] by server-1.bemta-4.messagelabs.com id
	71/4D-20925-9C1797F4; Mon, 02 Apr 2012 09:30:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333359048!16647188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13609 invoked from network); 2 Apr 2012 09:30:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:30:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11716585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:30:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:30:47 +0100
Message-ID: <1333359046.25602.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 10:30:46 +0100
In-Reply-To: <4F796F7C.4070400@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>
	<1332443876-28506-3-git-send-email-david.vrabel@citrix.com>
	<1333123166.15932.113.camel@zakaz.uk.xensource.com>
	<4F796F7C.4070400@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 10:21 +0100, David Vrabel wrote:
> On 30/03/12 16:59, Ian Campbell wrote:
> > On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> Build a flat device tree for dom0 based on the one supplied to Xen.
> >> The following changes are made:
> >>
> >>   * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
> >>     bootargs.
> >>
> >>   * In all memory nodes, the reg parameters are adjusted to reflect
> >>     the amount of memory dom0 can use.  The p2m is updated using this
> >>     info.
> >>
> >> Support for passing ATAGS to dom0 is removed.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  xen/arch/arm/domain_build.c         |  257 +++++++++++++++++++++++++++++------
> >>  xen/arch/arm/kernel.c               |    2 +-
> >>  xen/arch/arm/kernel.h               |    8 +-
> >>  xen/common/device_tree.c            |   47 ++++--
> >>  xen/include/xen/device_tree.h       |    8 +
> >>  xen/include/xen/libfdt/libfdt_env.h |    3 +
> >>  6 files changed, 265 insertions(+), 60 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index 15632f7..b4c0452 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -6,6 +6,10 @@
> >>  #include <xen/sched.h>
> >>  #include <asm/irq.h>
> >>  #include <asm/regs.h>
> >> +#include <xen/errno.h>
> >> +#include <xen/device_tree.h>
> >> +#include <xen/libfdt/libfdt.h>
> >> +#include <xen/guest_access.h>
> >>
> >>  #include "gic.h"
> >>  #include "kernel.h"
> >> @@ -13,6 +17,13 @@
> >>  static unsigned int __initdata opt_dom0_max_vcpus;
> >>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> >>
> >> +/*
> >> + * Amount of extra space required to dom0's device tree.  No new nodes
> >> + * are added (yet) but one terminating reserve map entry (16 bytes) is
> >> + * added.
> >> + */
> >> +#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
> >> +
> >>  struct vcpu *__init alloc_dom0_vcpu0(void)
> >>  {
> >>      if ( opt_dom0_max_vcpus == 0 )
> >> @@ -28,43 +39,210 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
> >>      return alloc_vcpu(dom0, 0, 0);
> >>  }
> >>
> >> -extern void guest_mode_entry(void);
> >> +static void set_memory_reg(struct domain *d, struct kernel_info *kinfo,
> >> +                           const void *fdt,
> >> +                           const u32 *cell, int address_cells, int size_cells,
> >> +                           u32 *new_cell, int *len)
> >> +{
> >> +    int reg_size = (address_cells + size_cells) * sizeof(*cell);
> >> +    int l;
> >> +    u64 start;
> >> +    u64 size;
> >> +
> >> +    l = *len;
> > 
> >> +
> >> +    while ( kinfo->unassigned_mem > 0 && l >= reg_size
> >> +            && kinfo->mem.nr_banks < NR_MEM_BANKS )
> >> +    {
> >> +        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
> >> +        if ( size > kinfo->unassigned_mem )
> >> +            size = kinfo->unassigned_mem;
> >> +
> >> +        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
> > 
> > This assumes/requires that address_cells and size_cells a 1, right? If
> > they end up being 2 or more then device_tree_get_reg will trample on the
> > stack via &start and &size.
> 
> No.  address_cells and size_cells can be 1 or 2.

Where is that checked or enforced? What happens if someone feeds us a
DTB with 3? Or are you saying that this isn't possible (perhaps due to
some constraint in DTB itself)?

> >> --- a/xen/include/xen/libfdt/libfdt_env.h
> >> +++ b/xen/include/xen/libfdt/libfdt_env.h
> >> @@ -13,4 +13,7 @@
> >>  #define fdt64_to_cpu(x) be64_to_cpu(x)
> >>  #define cpu_to_fdt64(x) cpu_to_be64(x)
> >>
> >> +/* Xen-specific libfdt error code. */
> >> +#define FDT_ERR_XEN(err) (FDT_ERR_MAX + (err))
> > 
> > Looks like the only user is FDT_ERR_XEN(ENOMEM) which could as well be
> > FDT_ERR_NOSPACE?
> 
> No.  FDT_ERR_NOSPACE means the buffer isn't large enough to add new
> nodes etc.  This needs to be a different error code from a memory
> allocation failure.

OK.

> > FWIW I think adding a new error code would be a fair reason to diverge
> > in a controlled way from the pristine upstream source.
> 
> I don't know what you're asking for here.

I was suggesting that it would be fine to just add a new error code,
IMHO it's a reasonable reason to diverge from upstream. Could perhaps
even send them the patch?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdbF-000322-Q8; Mon, 02 Apr 2012 09:30:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1SDjRI-000266-Ad
	for xen-devel@lists.xensource.com; Fri, 30 Mar 2012 21:32:56 +0000
Received: from [85.158.143.99:3815] by server-2.bemta-4.messagelabs.com id
	EB/5A-17550-786267F4; Fri, 30 Mar 2012 21:32:55 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333143173!21604443!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gNDExODQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21261 invoked from network); 30 Mar 2012 21:32:54 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Mar 2012 21:32:54 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5FA9921581
	for <xen-devel@lists.xensource.com>;
	Fri, 30 Mar 2012 17:32:53 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute6.internal (MEProxy); Fri, 30 Mar 2012 17:32:53 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=CXCiSUYOupUrW69voaJMYxAVNJs=; b=ejDE8vWauUbK4pNuf8r764qONnaz
	RwAmn+O/TjR1UcouGvx7jmfmf4shVANacjhyKSqpWpLF8bH4kSGJ+9qjFhtMVmg2
	jYWUfipFFZ7WVtdcSzWropjk9R7hubtMR8TXj9VF6M7mkgudi9wyAaHPp/wDYKLT
	DkK2hi6V3OY+hBI=
X-Sasl-enc: ACU/c2ODV6Xtmd56Zvu6g2zk8QIsJxHP2CEs8dL+/lHD 1333143172
Received: from localhost (c-67-168-183-230.hsd1.wa.comcast.net
	[67.168.183.230])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 924D58E00C3;
	Fri, 30 Mar 2012 17:32:52 -0400 (EDT)
Date: Fri, 30 Mar 2012 14:11:20 -0700
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120330211120.GA15000@kroah.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080606.14568.31335.sendpatchset@codeblue>
	<20120330204912.GA29329@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120330204912.GA29329@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:30:57 +0000
Cc: Xen <xen-devel@lists.xensource.com>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, X86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Alexander Graf <agraf@suse.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 1/6] debugfs: Add support to print
 u32 array in debugfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 30, 2012 at 04:49:12PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 23, 2012 at 01:36:28PM +0530, Raghavendra K T wrote:
> > From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > 
> > Move the code from Xen to debugfs to make the code common
> > for other users as well.
> > 
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Greg,
> 
> I was thinking to stick this patch in my queue, but I need your
> OK since it touches fs/debugfs/file.c.

That's fine with me:

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdbF-000322-Q8; Mon, 02 Apr 2012 09:30:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1SDjRI-000266-Ad
	for xen-devel@lists.xensource.com; Fri, 30 Mar 2012 21:32:56 +0000
Received: from [85.158.143.99:3815] by server-2.bemta-4.messagelabs.com id
	EB/5A-17550-786267F4; Fri, 30 Mar 2012 21:32:55 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333143173!21604443!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gNDExODQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21261 invoked from network); 30 Mar 2012 21:32:54 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Mar 2012 21:32:54 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5FA9921581
	for <xen-devel@lists.xensource.com>;
	Fri, 30 Mar 2012 17:32:53 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute6.internal (MEProxy); Fri, 30 Mar 2012 17:32:53 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=CXCiSUYOupUrW69voaJMYxAVNJs=; b=ejDE8vWauUbK4pNuf8r764qONnaz
	RwAmn+O/TjR1UcouGvx7jmfmf4shVANacjhyKSqpWpLF8bH4kSGJ+9qjFhtMVmg2
	jYWUfipFFZ7WVtdcSzWropjk9R7hubtMR8TXj9VF6M7mkgudi9wyAaHPp/wDYKLT
	DkK2hi6V3OY+hBI=
X-Sasl-enc: ACU/c2ODV6Xtmd56Zvu6g2zk8QIsJxHP2CEs8dL+/lHD 1333143172
Received: from localhost (c-67-168-183-230.hsd1.wa.comcast.net
	[67.168.183.230])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 924D58E00C3;
	Fri, 30 Mar 2012 17:32:52 -0400 (EDT)
Date: Fri, 30 Mar 2012 14:11:20 -0700
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120330211120.GA15000@kroah.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080606.14568.31335.sendpatchset@codeblue>
	<20120330204912.GA29329@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120330204912.GA29329@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:30:57 +0000
Cc: Xen <xen-devel@lists.xensource.com>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, X86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Alexander Graf <agraf@suse.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 1/6] debugfs: Add support to print
 u32 array in debugfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 30, 2012 at 04:49:12PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 23, 2012 at 01:36:28PM +0530, Raghavendra K T wrote:
> > From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > 
> > Move the code from Xen to debugfs to make the code common
> > for other users as well.
> > 
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Greg,
> 
> I was thinking to stick this patch in my queue, but I need your
> OK since it touches fs/debugfs/file.c.

That's fine with me:

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdbd-00037D-6r; Mon, 02 Apr 2012 09:31:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1SEZ01-0007yK-Hr
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 04:36:13 +0000
Received: from [85.158.138.51:64891] by server-10.bemta-3.messagelabs.com id
	BC/DC-15637-CBC297F4; Mon, 02 Apr 2012 04:36:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333341371!20268148!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMjc2MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8159 invoked from network); 2 Apr 2012 04:36:11 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 04:36:11 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=rtRA1xVzH/MqSuYAo9ap6quBIJwW6aM5z0NiApCbI95DaTcoOR+1QLMZ
	0iNnn1yBkeZywTb+uO+ply/ae/jXPgwUqMphob1+z1kTr1qDd/gsbUPaG
	fMfrSFSVUhhN+7gTxK8+qaXIXCApi9lP68ceppo3TNrUoR5G6cb7qbOMI
	tBG2jE8lXc4z8GUsgTXAcTxBKNlomg7KxNRqqTBcrPYcWyQvFyg5pzi+v
	lF/JS7xMANDpdapshLgxUcL0hgUUz;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1333341371; x=1364877371;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=uwgJWrqxvwWhhwx0geYIc231cm66QgiNypVtZ75HhS0=;
	b=H0XVh3Y3cm9YEcQ3oMpb+qm3Uue3nOq3qreVqmDGKAdwu+cj4h9GcYpb
	TjRFx3Kczi8ciaFofjyMC39E/1sYbpOnS++VLp1DUq4Bg/J5SZ/JEhvui
	Yz1b8nWXULVw/gS01FcNWnfxNL1SKVm8HrTQBRnmPCugpCak2hWQdJ5RR
	8qLJ3TSd2PJS0uDMVSQx90EZ/FEXsNK0NduW53dAuLaLqCY/+MifBlYW8
	N3EjHNXUS7sJ49V0a+M5e4KitYpKR;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,355,1330902000"; d="scan'208";a="106495612"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 02 Apr 2012 06:36:10 +0200
X-IronPort-AV: E=Sophos;i="4.75,355,1330902000"; d="scan'208";a="131759793"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 02 Apr 2012 06:36:10 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 923C7961151;
	Mon,  2 Apr 2012 06:36:10 +0200 (CEST)
Message-ID: <4F792CBA.1010402@ts.fujitsu.com>
Date: Mon, 02 Apr 2012 06:36:10 +0200
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:31:19 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/31/2012 12:07 AM, Thomas Gleixner wrote:
> On Fri, 30 Mar 2012, H. Peter Anvin wrote:
>
>> What is the current status of this patchset?  I haven't looked at it too
>> closely because I have been focused on 3.4 up until now...
> The real question is whether these heuristics are the correct approach
> or not.
>
> If I look at it from the non virtualized kernel side then this is ass
> backwards. We know already that we are holding a spinlock which might
> cause other (v)cpus going into eternal spin. The non virtualized
> kernel solves this by disabling preemption and therefor getting out of
> the critical section as fast as possible,
>
> The virtualization problem reminds me a lot of the problem which RT
> kernels are observing where non raw spinlocks are turned into
> "sleeping spinlocks" and therefor can cause throughput issues for non
> RT workloads.
>
> Though the virtualized situation is even worse. Any preempted guest
> section which holds a spinlock is prone to cause unbound delays.
>
> The paravirt ticketlock solution can only mitigate the problem, but
> not solve it. With massive overcommit there is always a way to trigger
> worst case scenarious unless you are educating the scheduler to cope
> with that.
>
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.
>
> I know that Peter is going to go berserk on me, but if we are running
> a paravirt guest then it's simple to provide a mechanism which allows
> the host (aka hypervisor) to check that in the guest just by looking
> at some global state.
>
> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be
> modified to indicate the guest to invoke an exit when the last nested
> lock has been released.
>
> Of course this needs to be time bound, so a rogue guest cannot
> monopolize the cpu forever, but that's the least to worry about
> problem simply because a guest which does not get out of a spinlocked
> region within a certain amount of time is borked and elegible to
> killing anyway.
>
> Thoughts ?

I used this approach in 2008:

http://lists.xen.org/archives/html/xen-devel/2008-12/msg00740.html

It worked very well, but it was rejected at that time. I wouldn't mind trying
it again if there is some support from your side. :-)


Juergen

-- 

Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdbd-00037D-6r; Mon, 02 Apr 2012 09:31:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1SEZ01-0007yK-Hr
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 04:36:13 +0000
Received: from [85.158.138.51:64891] by server-10.bemta-3.messagelabs.com id
	BC/DC-15637-CBC297F4; Mon, 02 Apr 2012 04:36:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333341371!20268148!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMjc2MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8159 invoked from network); 2 Apr 2012 04:36:11 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 04:36:11 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=rtRA1xVzH/MqSuYAo9ap6quBIJwW6aM5z0NiApCbI95DaTcoOR+1QLMZ
	0iNnn1yBkeZywTb+uO+ply/ae/jXPgwUqMphob1+z1kTr1qDd/gsbUPaG
	fMfrSFSVUhhN+7gTxK8+qaXIXCApi9lP68ceppo3TNrUoR5G6cb7qbOMI
	tBG2jE8lXc4z8GUsgTXAcTxBKNlomg7KxNRqqTBcrPYcWyQvFyg5pzi+v
	lF/JS7xMANDpdapshLgxUcL0hgUUz;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1333341371; x=1364877371;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=uwgJWrqxvwWhhwx0geYIc231cm66QgiNypVtZ75HhS0=;
	b=H0XVh3Y3cm9YEcQ3oMpb+qm3Uue3nOq3qreVqmDGKAdwu+cj4h9GcYpb
	TjRFx3Kczi8ciaFofjyMC39E/1sYbpOnS++VLp1DUq4Bg/J5SZ/JEhvui
	Yz1b8nWXULVw/gS01FcNWnfxNL1SKVm8HrTQBRnmPCugpCak2hWQdJ5RR
	8qLJ3TSd2PJS0uDMVSQx90EZ/FEXsNK0NduW53dAuLaLqCY/+MifBlYW8
	N3EjHNXUS7sJ49V0a+M5e4KitYpKR;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,355,1330902000"; d="scan'208";a="106495612"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 02 Apr 2012 06:36:10 +0200
X-IronPort-AV: E=Sophos;i="4.75,355,1330902000"; d="scan'208";a="131759793"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 02 Apr 2012 06:36:10 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 923C7961151;
	Mon,  2 Apr 2012 06:36:10 +0200 (CEST)
Message-ID: <4F792CBA.1010402@ts.fujitsu.com>
Date: Mon, 02 Apr 2012 06:36:10 +0200
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:31:19 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/31/2012 12:07 AM, Thomas Gleixner wrote:
> On Fri, 30 Mar 2012, H. Peter Anvin wrote:
>
>> What is the current status of this patchset?  I haven't looked at it too
>> closely because I have been focused on 3.4 up until now...
> The real question is whether these heuristics are the correct approach
> or not.
>
> If I look at it from the non virtualized kernel side then this is ass
> backwards. We know already that we are holding a spinlock which might
> cause other (v)cpus going into eternal spin. The non virtualized
> kernel solves this by disabling preemption and therefor getting out of
> the critical section as fast as possible,
>
> The virtualization problem reminds me a lot of the problem which RT
> kernels are observing where non raw spinlocks are turned into
> "sleeping spinlocks" and therefor can cause throughput issues for non
> RT workloads.
>
> Though the virtualized situation is even worse. Any preempted guest
> section which holds a spinlock is prone to cause unbound delays.
>
> The paravirt ticketlock solution can only mitigate the problem, but
> not solve it. With massive overcommit there is always a way to trigger
> worst case scenarious unless you are educating the scheduler to cope
> with that.
>
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.
>
> I know that Peter is going to go berserk on me, but if we are running
> a paravirt guest then it's simple to provide a mechanism which allows
> the host (aka hypervisor) to check that in the guest just by looking
> at some global state.
>
> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be
> modified to indicate the guest to invoke an exit when the last nested
> lock has been released.
>
> Of course this needs to be time bound, so a rogue guest cannot
> monopolize the cpu forever, but that's the least to worry about
> problem simply because a guest which does not get out of a spinlocked
> region within a certain amount of time is borked and elegible to
> killing anyway.
>
> Thoughts ?

I used this approach in 2008:

http://lists.xen.org/archives/html/xen-devel/2008-12/msg00740.html

It worked very well, but it was rejected at that time. I wouldn't mind trying
it again if there is some support from your side. :-)


Juergen

-- 

Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdbw-0003CE-JS; Mon, 02 Apr 2012 09:31:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SDipm-0001Yc-1M
	for xen-devel@lists.xensource.com; Fri, 30 Mar 2012 20:54:10 +0000
Received: from [85.158.143.99:61027] by server-2.bemta-4.messagelabs.com id
	30/5C-17550-17D167F4; Fri, 30 Mar 2012 20:54:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333140847!20741966!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MjI3Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11030 invoked from network); 30 Mar 2012 20:54:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Mar 2012 20:54:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q2UKrnhd003764
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 30 Mar 2012 20:53:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q2UKrkFp013324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 30 Mar 2012 20:53:47 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q2UKri3w013942; Fri, 30 Mar 2012 15:53:44 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 30 Mar 2012 13:53:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C34E14032D; Fri, 30 Mar 2012 16:49:12 -0400 (EDT)
Date: Fri, 30 Mar 2012 16:49:12 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	gregkh@linuxfoundation.org
Message-ID: <20120330204912.GA29329@phenom.dumpdata.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080606.14568.31335.sendpatchset@codeblue>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120323080606.14568.31335.sendpatchset@codeblue>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F761D61.009F,ss=1,re=-2.300,fgs=0
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:31:38 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, X86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Alexander Graf <agraf@suse.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 1/6] debugfs: Add support to print
 u32 array in debugfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 01:36:28PM +0530, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> 
> Move the code from Xen to debugfs to make the code common
> for other users as well.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Greg,

I was thinking to stick this patch in my queue, but I need your
OK since it touches fs/debugfs/file.c.

> ---
> diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
> index ef1db19..c8377fb 100644
> --- a/arch/x86/xen/debugfs.c
> +++ b/arch/x86/xen/debugfs.c
> @@ -19,107 +19,3 @@ struct dentry * __init xen_init_debugfs(void)
>  	return d_xen_debug;
>  }
>  
> -struct array_data
> -{
> -	void *array;
> -	unsigned elements;
> -};
> -
> -static int u32_array_open(struct inode *inode, struct file *file)
> -{
> -	file->private_data = NULL;
> -	return nonseekable_open(inode, file);
> -}
> -
> -static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> -			   u32 *array, unsigned array_size)
> -{
> -	size_t ret = 0;
> -	unsigned i;
> -
> -	for(i = 0; i < array_size; i++) {
> -		size_t len;
> -
> -		len = snprintf(buf, bufsize, fmt, array[i]);
> -		len++;	/* ' ' or '\n' */
> -		ret += len;
> -
> -		if (buf) {
> -			buf += len;
> -			bufsize -= len;
> -			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> -		}
> -	}
> -
> -	ret++;		/* \0 */
> -	if (buf)
> -		*buf = '\0';
> -
> -	return ret;
> -}
> -
> -static char *format_array_alloc(const char *fmt, u32 *array, unsigned array_size)
> -{
> -	size_t len = format_array(NULL, 0, fmt, array, array_size);
> -	char *ret;
> -
> -	ret = kmalloc(len, GFP_KERNEL);
> -	if (ret == NULL)
> -		return NULL;
> -
> -	format_array(ret, len, fmt, array, array_size);
> -	return ret;
> -}
> -
> -static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> -			      loff_t *ppos)
> -{
> -	struct inode *inode = file->f_path.dentry->d_inode;
> -	struct array_data *data = inode->i_private;
> -	size_t size;
> -
> -	if (*ppos == 0) {
> -		if (file->private_data) {
> -			kfree(file->private_data);
> -			file->private_data = NULL;
> -		}
> -
> -		file->private_data = format_array_alloc("%u", data->array, data->elements);
> -	}
> -
> -	size = 0;
> -	if (file->private_data)
> -		size = strlen(file->private_data);
> -
> -	return simple_read_from_buffer(buf, len, ppos, file->private_data, size);
> -}
> -
> -static int xen_array_release(struct inode *inode, struct file *file)
> -{
> -	kfree(file->private_data);
> -
> -	return 0;
> -}
> -
> -static const struct file_operations u32_array_fops = {
> -	.owner	= THIS_MODULE,
> -	.open	= u32_array_open,
> -	.release= xen_array_release,
> -	.read	= u32_array_read,
> -	.llseek = no_llseek,
> -};
> -
> -struct dentry *xen_debugfs_create_u32_array(const char *name, umode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements)
> -{
> -	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> -
> -	if (data == NULL)
> -		return NULL;
> -
> -	data->array = array;
> -	data->elements = elements;
> -
> -	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> -}
> diff --git a/arch/x86/xen/debugfs.h b/arch/x86/xen/debugfs.h
> index 78d2549..12ebf33 100644
> --- a/arch/x86/xen/debugfs.h
> +++ b/arch/x86/xen/debugfs.h
> @@ -3,8 +3,4 @@
>  
>  struct dentry * __init xen_init_debugfs(void);
>  
> -struct dentry *xen_debugfs_create_u32_array(const char *name, umode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements);
> -
>  #endif /* _XEN_DEBUGFS_H */
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 4926974..b74cebb 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -314,7 +314,7 @@ static int __init xen_spinlock_debugfs(void)
>  	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
>  			   &spinlock_stats.time_blocked);
>  
> -	xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
> +	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
>  				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
>  
>  	return 0;
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index ef023ee..cb6cff3 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -20,6 +20,7 @@
>  #include <linux/namei.h>
>  #include <linux/debugfs.h>
>  #include <linux/io.h>
> +#include <linux/slab.h>
>  
>  static ssize_t default_read_file(struct file *file, char __user *buf,
>  				 size_t count, loff_t *ppos)
> @@ -528,6 +529,133 @@ struct dentry *debugfs_create_blob(const char *name, umode_t mode,
>  }
>  EXPORT_SYMBOL_GPL(debugfs_create_blob);
>  
> +struct array_data {
> +	void *array;
> +	u32 elements;
> +};
> +
> +static int u32_array_open(struct inode *inode, struct file *file)
> +{
> +	file->private_data = NULL;
> +	return nonseekable_open(inode, file);
> +}
> +
> +static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> +			   u32 *array, u32 array_size)
> +{
> +	size_t ret = 0;
> +	u32 i;
> +
> +	for (i = 0; i < array_size; i++) {
> +		size_t len;
> +
> +		len = snprintf(buf, bufsize, fmt, array[i]);
> +		len++;	/* ' ' or '\n' */
> +		ret += len;
> +
> +		if (buf) {
> +			buf += len;
> +			bufsize -= len;
> +			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> +		}
> +	}
> +
> +	ret++;		/* \0 */
> +	if (buf)
> +		*buf = '\0';
> +
> +	return ret;
> +}
> +
> +static char *format_array_alloc(const char *fmt, u32 *array,
> +						u32 array_size)
> +{
> +	size_t len = format_array(NULL, 0, fmt, array, array_size);
> +	char *ret;
> +
> +	ret = kmalloc(len, GFP_KERNEL);
> +	if (ret == NULL)
> +		return NULL;
> +
> +	format_array(ret, len, fmt, array, array_size);
> +	return ret;
> +}
> +
> +static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> +			      loff_t *ppos)
> +{
> +	struct inode *inode = file->f_path.dentry->d_inode;
> +	struct array_data *data = inode->i_private;
> +	size_t size;
> +
> +	if (*ppos == 0) {
> +		if (file->private_data) {
> +			kfree(file->private_data);
> +			file->private_data = NULL;
> +		}
> +
> +		file->private_data = format_array_alloc("%u", data->array,
> +							      data->elements);
> +	}
> +
> +	size = 0;
> +	if (file->private_data)
> +		size = strlen(file->private_data);
> +
> +	return simple_read_from_buffer(buf, len, ppos,
> +					file->private_data, size);
> +}
> +
> +static int u32_array_release(struct inode *inode, struct file *file)
> +{
> +	kfree(file->private_data);
> +
> +	return 0;
> +}
> +
> +static const struct file_operations u32_array_fops = {
> +	.owner	 = THIS_MODULE,
> +	.open	 = u32_array_open,
> +	.release = u32_array_release,
> +	.read	 = u32_array_read,
> +	.llseek  = no_llseek,
> +};
> +
> +/**
> + * debugfs_create_u32_array - create a debugfs file that is used to read u32
> + * array.
> + * @name: a pointer to a string containing the name of the file to create.
> + * @mode: the permission that the file should have.
> + * @parent: a pointer to the parent dentry for this file.  This should be a
> + *          directory dentry if set.  If this parameter is %NULL, then the
> + *          file will be created in the root of the debugfs filesystem.
> + * @array: u32 array that provides data.
> + * @elements: total number of elements in the array.
> + *
> + * This function creates a file in debugfs with the given name that exports
> + * @array as data. If the @mode variable is so set it can be read from.
> + * Writing is not supported. Seek within the file is also not supported.
> + * Once array is created its size can not be changed.
> + *
> + * The function returns a pointer to dentry on success. If debugfs is not
> + * enabled in the kernel, the value -%ENODEV will be returned.
> + */
> +struct dentry *debugfs_create_u32_array(const char *name, umode_t mode,
> +					    struct dentry *parent,
> +					    u32 *array, u32 elements)
> +{
> +	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> +
> +	if (data == NULL)
> +		return NULL;
> +
> +	data->array = array;
> +	data->elements = elements;
> +
> +	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> +}
> +EXPORT_SYMBOL_GPL(debugfs_create_u32_array);
> +
>  #ifdef CONFIG_HAS_IOMEM
>  
>  /*
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index 6169c26..5cb4435 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -93,6 +93,10 @@ struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
>  int debugfs_print_regs32(struct seq_file *s, const struct debugfs_reg32 *regs,
>  			 int nregs, void __iomem *base, char *prefix);
>  
> +struct dentry *debugfs_create_u32_array(const char *name, umode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements);
> +
>  bool debugfs_initialized(void);
>  
>  #else
> @@ -219,6 +223,13 @@ static inline bool debugfs_initialized(void)
>  	return false;
>  }
>  
> +struct dentry *debugfs_create_u32_array(const char *name, umode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +
>  #endif
>  
>  #endif
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:31:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdbw-0003CE-JS; Mon, 02 Apr 2012 09:31:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SDipm-0001Yc-1M
	for xen-devel@lists.xensource.com; Fri, 30 Mar 2012 20:54:10 +0000
Received: from [85.158.143.99:61027] by server-2.bemta-4.messagelabs.com id
	30/5C-17550-17D167F4; Fri, 30 Mar 2012 20:54:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333140847!20741966!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MjI3Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11030 invoked from network); 30 Mar 2012 20:54:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Mar 2012 20:54:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q2UKrnhd003764
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 30 Mar 2012 20:53:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q2UKrkFp013324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 30 Mar 2012 20:53:47 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q2UKri3w013942; Fri, 30 Mar 2012 15:53:44 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 30 Mar 2012 13:53:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C34E14032D; Fri, 30 Mar 2012 16:49:12 -0400 (EDT)
Date: Fri, 30 Mar 2012 16:49:12 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	gregkh@linuxfoundation.org
Message-ID: <20120330204912.GA29329@phenom.dumpdata.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080606.14568.31335.sendpatchset@codeblue>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120323080606.14568.31335.sendpatchset@codeblue>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F761D61.009F,ss=1,re=-2.300,fgs=0
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:31:38 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, X86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Alexander Graf <agraf@suse.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 1/6] debugfs: Add support to print
 u32 array in debugfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 01:36:28PM +0530, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> 
> Move the code from Xen to debugfs to make the code common
> for other users as well.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Greg,

I was thinking to stick this patch in my queue, but I need your
OK since it touches fs/debugfs/file.c.

> ---
> diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
> index ef1db19..c8377fb 100644
> --- a/arch/x86/xen/debugfs.c
> +++ b/arch/x86/xen/debugfs.c
> @@ -19,107 +19,3 @@ struct dentry * __init xen_init_debugfs(void)
>  	return d_xen_debug;
>  }
>  
> -struct array_data
> -{
> -	void *array;
> -	unsigned elements;
> -};
> -
> -static int u32_array_open(struct inode *inode, struct file *file)
> -{
> -	file->private_data = NULL;
> -	return nonseekable_open(inode, file);
> -}
> -
> -static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> -			   u32 *array, unsigned array_size)
> -{
> -	size_t ret = 0;
> -	unsigned i;
> -
> -	for(i = 0; i < array_size; i++) {
> -		size_t len;
> -
> -		len = snprintf(buf, bufsize, fmt, array[i]);
> -		len++;	/* ' ' or '\n' */
> -		ret += len;
> -
> -		if (buf) {
> -			buf += len;
> -			bufsize -= len;
> -			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> -		}
> -	}
> -
> -	ret++;		/* \0 */
> -	if (buf)
> -		*buf = '\0';
> -
> -	return ret;
> -}
> -
> -static char *format_array_alloc(const char *fmt, u32 *array, unsigned array_size)
> -{
> -	size_t len = format_array(NULL, 0, fmt, array, array_size);
> -	char *ret;
> -
> -	ret = kmalloc(len, GFP_KERNEL);
> -	if (ret == NULL)
> -		return NULL;
> -
> -	format_array(ret, len, fmt, array, array_size);
> -	return ret;
> -}
> -
> -static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> -			      loff_t *ppos)
> -{
> -	struct inode *inode = file->f_path.dentry->d_inode;
> -	struct array_data *data = inode->i_private;
> -	size_t size;
> -
> -	if (*ppos == 0) {
> -		if (file->private_data) {
> -			kfree(file->private_data);
> -			file->private_data = NULL;
> -		}
> -
> -		file->private_data = format_array_alloc("%u", data->array, data->elements);
> -	}
> -
> -	size = 0;
> -	if (file->private_data)
> -		size = strlen(file->private_data);
> -
> -	return simple_read_from_buffer(buf, len, ppos, file->private_data, size);
> -}
> -
> -static int xen_array_release(struct inode *inode, struct file *file)
> -{
> -	kfree(file->private_data);
> -
> -	return 0;
> -}
> -
> -static const struct file_operations u32_array_fops = {
> -	.owner	= THIS_MODULE,
> -	.open	= u32_array_open,
> -	.release= xen_array_release,
> -	.read	= u32_array_read,
> -	.llseek = no_llseek,
> -};
> -
> -struct dentry *xen_debugfs_create_u32_array(const char *name, umode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements)
> -{
> -	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> -
> -	if (data == NULL)
> -		return NULL;
> -
> -	data->array = array;
> -	data->elements = elements;
> -
> -	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> -}
> diff --git a/arch/x86/xen/debugfs.h b/arch/x86/xen/debugfs.h
> index 78d2549..12ebf33 100644
> --- a/arch/x86/xen/debugfs.h
> +++ b/arch/x86/xen/debugfs.h
> @@ -3,8 +3,4 @@
>  
>  struct dentry * __init xen_init_debugfs(void);
>  
> -struct dentry *xen_debugfs_create_u32_array(const char *name, umode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements);
> -
>  #endif /* _XEN_DEBUGFS_H */
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 4926974..b74cebb 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -314,7 +314,7 @@ static int __init xen_spinlock_debugfs(void)
>  	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
>  			   &spinlock_stats.time_blocked);
>  
> -	xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
> +	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
>  				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
>  
>  	return 0;
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index ef023ee..cb6cff3 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -20,6 +20,7 @@
>  #include <linux/namei.h>
>  #include <linux/debugfs.h>
>  #include <linux/io.h>
> +#include <linux/slab.h>
>  
>  static ssize_t default_read_file(struct file *file, char __user *buf,
>  				 size_t count, loff_t *ppos)
> @@ -528,6 +529,133 @@ struct dentry *debugfs_create_blob(const char *name, umode_t mode,
>  }
>  EXPORT_SYMBOL_GPL(debugfs_create_blob);
>  
> +struct array_data {
> +	void *array;
> +	u32 elements;
> +};
> +
> +static int u32_array_open(struct inode *inode, struct file *file)
> +{
> +	file->private_data = NULL;
> +	return nonseekable_open(inode, file);
> +}
> +
> +static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> +			   u32 *array, u32 array_size)
> +{
> +	size_t ret = 0;
> +	u32 i;
> +
> +	for (i = 0; i < array_size; i++) {
> +		size_t len;
> +
> +		len = snprintf(buf, bufsize, fmt, array[i]);
> +		len++;	/* ' ' or '\n' */
> +		ret += len;
> +
> +		if (buf) {
> +			buf += len;
> +			bufsize -= len;
> +			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> +		}
> +	}
> +
> +	ret++;		/* \0 */
> +	if (buf)
> +		*buf = '\0';
> +
> +	return ret;
> +}
> +
> +static char *format_array_alloc(const char *fmt, u32 *array,
> +						u32 array_size)
> +{
> +	size_t len = format_array(NULL, 0, fmt, array, array_size);
> +	char *ret;
> +
> +	ret = kmalloc(len, GFP_KERNEL);
> +	if (ret == NULL)
> +		return NULL;
> +
> +	format_array(ret, len, fmt, array, array_size);
> +	return ret;
> +}
> +
> +static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> +			      loff_t *ppos)
> +{
> +	struct inode *inode = file->f_path.dentry->d_inode;
> +	struct array_data *data = inode->i_private;
> +	size_t size;
> +
> +	if (*ppos == 0) {
> +		if (file->private_data) {
> +			kfree(file->private_data);
> +			file->private_data = NULL;
> +		}
> +
> +		file->private_data = format_array_alloc("%u", data->array,
> +							      data->elements);
> +	}
> +
> +	size = 0;
> +	if (file->private_data)
> +		size = strlen(file->private_data);
> +
> +	return simple_read_from_buffer(buf, len, ppos,
> +					file->private_data, size);
> +}
> +
> +static int u32_array_release(struct inode *inode, struct file *file)
> +{
> +	kfree(file->private_data);
> +
> +	return 0;
> +}
> +
> +static const struct file_operations u32_array_fops = {
> +	.owner	 = THIS_MODULE,
> +	.open	 = u32_array_open,
> +	.release = u32_array_release,
> +	.read	 = u32_array_read,
> +	.llseek  = no_llseek,
> +};
> +
> +/**
> + * debugfs_create_u32_array - create a debugfs file that is used to read u32
> + * array.
> + * @name: a pointer to a string containing the name of the file to create.
> + * @mode: the permission that the file should have.
> + * @parent: a pointer to the parent dentry for this file.  This should be a
> + *          directory dentry if set.  If this parameter is %NULL, then the
> + *          file will be created in the root of the debugfs filesystem.
> + * @array: u32 array that provides data.
> + * @elements: total number of elements in the array.
> + *
> + * This function creates a file in debugfs with the given name that exports
> + * @array as data. If the @mode variable is so set it can be read from.
> + * Writing is not supported. Seek within the file is also not supported.
> + * Once array is created its size can not be changed.
> + *
> + * The function returns a pointer to dentry on success. If debugfs is not
> + * enabled in the kernel, the value -%ENODEV will be returned.
> + */
> +struct dentry *debugfs_create_u32_array(const char *name, umode_t mode,
> +					    struct dentry *parent,
> +					    u32 *array, u32 elements)
> +{
> +	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> +
> +	if (data == NULL)
> +		return NULL;
> +
> +	data->array = array;
> +	data->elements = elements;
> +
> +	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> +}
> +EXPORT_SYMBOL_GPL(debugfs_create_u32_array);
> +
>  #ifdef CONFIG_HAS_IOMEM
>  
>  /*
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index 6169c26..5cb4435 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -93,6 +93,10 @@ struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
>  int debugfs_print_regs32(struct seq_file *s, const struct debugfs_reg32 *regs,
>  			 int nregs, void __iomem *base, char *prefix);
>  
> +struct dentry *debugfs_create_u32_array(const char *name, umode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements);
> +
>  bool debugfs_initialized(void);
>  
>  #else
> @@ -219,6 +223,13 @@ static inline bool debugfs_initialized(void)
>  	return false;
>  }
>  
> +struct dentry *debugfs_create_u32_array(const char *name, umode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +
>  #endif
>  
>  #endif
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:32:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdcS-0003Lf-9r; Mon, 02 Apr 2012 09:32:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1SDtPi-0003PS-Hy
	for xen-devel@lists.xensource.com; Sat, 31 Mar 2012 08:11:58 +0000
Received: from [85.158.138.51:42244] by server-8.bemta-3.messagelabs.com id
	3A/FE-29305-D4CB67F4; Sat, 31 Mar 2012 08:11:57 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333181516!20174211!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15871 invoked from network); 31 Mar 2012 08:11:57 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Mar 2012 08:11:57 -0000
Received: by wibhj13 with SMTP id hj13so1150241wib.6
	for <xen-devel@lists.xensource.com>;
	Sat, 31 Mar 2012 01:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=VpIrwC/jqIL5IlPtsjxvTjA0tWHgpGydXN7NFbS8cjw=;
	b=I60ecba9pytZIUqb68AKL9Ay8zMVty0Oz35uJrN6jkCnGDUNd2L5Rva0DHqv5uWyHX
	VwEuXblYYyOPJTaRICuESIYULmNbG1QhgJGvVQxI5lYuQgburwQWtVRz+cb2n1qlTWdy
	ZqK/8QXNxuZzoJ4L/hTp+qGiX+dBA+TzsymXD/IMKE3GZs2E9/hsPhnZ6nEFQE/hW0+O
	Zqy+iBpDXEYvpT5E2tRmIzm4KFM5Stv+xZemL+sd1zvecsQWf1Yiyv/2VBodPqMadrwy
	0FkNwliB3ng78uhLvjXdPTeSDeLRdNSsDjct4exghqIscfafosMOmOez0GT6KaHRD5CR
	bBig==
Received: by 10.180.102.129 with SMTP id fo1mr4386595wib.6.1333181516648;
	Sat, 31 Mar 2012 01:11:56 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id fn2sm22227864wib.0.2012.03.31.01.11.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 31 Mar 2012 01:11:55 -0700 (PDT)
Date: Sat, 31 Mar 2012 10:11:52 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Message-ID: <20120331081152.GB15958@gmail.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120330221836.GN17822@one.firstfloor.org>
	<alpine.LFD.2.02.1203310044580.2542@ionos>
	<20120331000843.GO17822@one.firstfloor.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120331000843.GO17822@one.firstfloor.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:32:11 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* Andi Kleen <andi@firstfloor.org> wrote:

> > Care to back that up with numbers and proper trace evidence 
> > instead of handwaving?
> 
> E.g. my plumbers presentations on lock and mm scalability from 
> last year has some graphs that show this very clearly, plus 
> some additional data on the mutexes. This compares to the 
> glibc futex locks, which perform much better than the kernel 
> mutex locks on larger systems under higher contention

If you mean these draft slides:

  http://www.halobates.de/plumbers-fork-locks_v2.pdf

it has very little verifiable information in it. It just 
cryptically says lock hold time "microbenchmark", which might or 
might not be a valid measurement.

You could have been honest and straightforward in your first 
mail:

 "I ran workload X on machine Y, and got results Z."

Instead you are *hindering* the discussion:

> Given your tone I will not supply an URL. [...]

If you meant the above URL then it's not the proper numbers 
Thomas asked for, just some vague slides. If you meant something 
else then put up or shut up.

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:32:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdcS-0003Lf-9r; Mon, 02 Apr 2012 09:32:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1SDtPi-0003PS-Hy
	for xen-devel@lists.xensource.com; Sat, 31 Mar 2012 08:11:58 +0000
Received: from [85.158.138.51:42244] by server-8.bemta-3.messagelabs.com id
	3A/FE-29305-D4CB67F4; Sat, 31 Mar 2012 08:11:57 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333181516!20174211!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15871 invoked from network); 31 Mar 2012 08:11:57 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Mar 2012 08:11:57 -0000
Received: by wibhj13 with SMTP id hj13so1150241wib.6
	for <xen-devel@lists.xensource.com>;
	Sat, 31 Mar 2012 01:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=VpIrwC/jqIL5IlPtsjxvTjA0tWHgpGydXN7NFbS8cjw=;
	b=I60ecba9pytZIUqb68AKL9Ay8zMVty0Oz35uJrN6jkCnGDUNd2L5Rva0DHqv5uWyHX
	VwEuXblYYyOPJTaRICuESIYULmNbG1QhgJGvVQxI5lYuQgburwQWtVRz+cb2n1qlTWdy
	ZqK/8QXNxuZzoJ4L/hTp+qGiX+dBA+TzsymXD/IMKE3GZs2E9/hsPhnZ6nEFQE/hW0+O
	Zqy+iBpDXEYvpT5E2tRmIzm4KFM5Stv+xZemL+sd1zvecsQWf1Yiyv/2VBodPqMadrwy
	0FkNwliB3ng78uhLvjXdPTeSDeLRdNSsDjct4exghqIscfafosMOmOez0GT6KaHRD5CR
	bBig==
Received: by 10.180.102.129 with SMTP id fo1mr4386595wib.6.1333181516648;
	Sat, 31 Mar 2012 01:11:56 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id fn2sm22227864wib.0.2012.03.31.01.11.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 31 Mar 2012 01:11:55 -0700 (PDT)
Date: Sat, 31 Mar 2012 10:11:52 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Message-ID: <20120331081152.GB15958@gmail.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120330221836.GN17822@one.firstfloor.org>
	<alpine.LFD.2.02.1203310044580.2542@ionos>
	<20120331000843.GO17822@one.firstfloor.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120331000843.GO17822@one.firstfloor.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:32:11 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* Andi Kleen <andi@firstfloor.org> wrote:

> > Care to back that up with numbers and proper trace evidence 
> > instead of handwaving?
> 
> E.g. my plumbers presentations on lock and mm scalability from 
> last year has some graphs that show this very clearly, plus 
> some additional data on the mutexes. This compares to the 
> glibc futex locks, which perform much better than the kernel 
> mutex locks on larger systems under higher contention

If you mean these draft slides:

  http://www.halobates.de/plumbers-fork-locks_v2.pdf

it has very little verifiable information in it. It just 
cryptically says lock hold time "microbenchmark", which might or 
might not be a valid measurement.

You could have been honest and straightforward in your first 
mail:

 "I ran workload X on machine Y, and got results Z."

Instead you are *hindering* the discussion:

> Given your tone I will not supply an URL. [...]

If you meant the above URL then it's not the proper numbers 
Thomas asked for, just some vague slides. If you meant something 
else then put up or shut up.

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:37:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdhH-0003wj-8F; Mon, 02 Apr 2012 09:37:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEdhF-0003we-K3
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 09:37:09 +0000
Received: from [85.158.138.51:4248] by server-10.bemta-3.messagelabs.com id
	49/79-15637-443797F4; Mon, 02 Apr 2012 09:37:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333359426!20347401!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28945 invoked from network); 2 Apr 2012 09:37:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 09:37:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 10:37:04 +0100
Message-Id: <4F798F5B020000780007BE2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 10:36:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4F703E27020000780007AD24@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Ping: [PATCH] qemu-traditional/passthrough: adjust
 MSI-X device cleanup (bug 1809)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.03.12 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Mon, 26 Mar 2012, Jan Beulich wrote:
>> To address http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809,
>> pt_unregister_regions() also needs to use the newly introduced
>> _pt_iomem_helper() instead of calling xc_domain_memory_mapping()
>> directly, to take into consideration the hole created for the MSI-X
>> table.
>> 
>> For this to work, two calls in unregister_real_device() need to be
>> swapped, since otherwise we'd have
>> 
>> unregister_real_device()
>>   -> pt_config_delete()
>>     -> pt_msix_delete() (frees [and fails to clear] ->msix)
>>   -> pt_unregister_regions()
>>     -> _pt_iomem_helper() (with the patch below)
>>       -> has_msix_mapping() (uses ->msix)
>> 
>> And to be certain to prevent (catch) further/future use-after-free
>> instances, let's also clear dev->msix in pt_msix_delete().
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Ping (http://lists.xen.org/archives/html/xen-devel/2012-03/msg02163.html)?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:37:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdhH-0003wj-8F; Mon, 02 Apr 2012 09:37:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEdhF-0003we-K3
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 09:37:09 +0000
Received: from [85.158.138.51:4248] by server-10.bemta-3.messagelabs.com id
	49/79-15637-443797F4; Mon, 02 Apr 2012 09:37:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333359426!20347401!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28945 invoked from network); 2 Apr 2012 09:37:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 09:37:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 10:37:04 +0100
Message-Id: <4F798F5B020000780007BE2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 10:36:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4F703E27020000780007AD24@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Ping: [PATCH] qemu-traditional/passthrough: adjust
 MSI-X device cleanup (bug 1809)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.03.12 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Mon, 26 Mar 2012, Jan Beulich wrote:
>> To address http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809,
>> pt_unregister_regions() also needs to use the newly introduced
>> _pt_iomem_helper() instead of calling xc_domain_memory_mapping()
>> directly, to take into consideration the hole created for the MSI-X
>> table.
>> 
>> For this to work, two calls in unregister_real_device() need to be
>> swapped, since otherwise we'd have
>> 
>> unregister_real_device()
>>   -> pt_config_delete()
>>     -> pt_msix_delete() (frees [and fails to clear] ->msix)
>>   -> pt_unregister_regions()
>>     -> _pt_iomem_helper() (with the patch below)
>>       -> has_msix_mapping() (uses ->msix)
>> 
>> And to be certain to prevent (catch) further/future use-after-free
>> instances, let's also clear dev->msix in pt_msix_delete().
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Ping (http://lists.xen.org/archives/html/xen-devel/2012-03/msg02163.html)?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdkT-00048W-Gg; Mon, 02 Apr 2012 09:40:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdkR-00048A-RW
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:40:28 +0000
Received: from [85.158.138.51:31452] by server-10.bemta-3.messagelabs.com id
	C0/FF-15637-A04797F4; Mon, 02 Apr 2012 09:40:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333359625!20311918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13903 invoked from network); 2 Apr 2012 09:40:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:40:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11716870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:40:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:40:25 +0100
Message-ID: <1333359624.25602.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 10:40:24 +0100
In-Reply-To: <1332443876-28506-6-git-send-email-david.vrabel@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>
	<1332443876-28506-6-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5/5] device tree: print a warning if a node
 is nested too deep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Since device_tree_for_each_node() is called before printk() works, a
> variable is used to switch between using early_printk() and printk().
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(although I separately wonder if generic printk ought not to redirect to
early_printk early on)

>  xen/common/device_tree.c |   19 ++++++++++++++++++-
>  1 files changed, 18 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 8fb6d46..04619f4 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -23,6 +23,10 @@
>  struct dt_early_info __initdata early_info;
>  void *device_tree_flattened;
>  
> +/* Some device tree functions may be called both before and after the
> +   console is initialized. */
> +static void (*dt_printk)(const char *fmt, ...) = early_printk;
> +
>  bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
>  {
>      const char *name;
> @@ -90,6 +94,11 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
>   * @fdt: flat device tree.
>   * @func: function to call for each node.
>   * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a negative value, that value is returned immediately.
>   */
>  int device_tree_for_each_node(const void *fdt,
>                                device_tree_node_func func, void *data)
> @@ -104,13 +113,19 @@ int device_tree_for_each_node(const void *fdt,
>            node >=0 && depth >= 0;
>            node = fdt_next_node(fdt, node, &depth) )
>      {
> +        const char *name = fdt_get_name(fdt, node, NULL);
> +
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +        {
> +            dt_printk("Warning: device tree node `%s' is nested too deep\n",
> +                      name);
>              continue;
> +        }
>  
>          address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
>          size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
>  
> -        ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
> +        ret = func(fdt, node, name, depth,
>                     address_cells[depth-1], size_cells[depth-1], data);
>          if ( ret < 0 )
>              return ret;
> @@ -253,6 +268,8 @@ size_t __init device_tree_early_init(const void *fdt)
>      device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
>      early_print_info();
>  
> +    dt_printk = printk;
> +
>      return fdt_totalsize(fdt);
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdkT-00048W-Gg; Mon, 02 Apr 2012 09:40:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdkR-00048A-RW
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:40:28 +0000
Received: from [85.158.138.51:31452] by server-10.bemta-3.messagelabs.com id
	C0/FF-15637-A04797F4; Mon, 02 Apr 2012 09:40:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333359625!20311918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13903 invoked from network); 2 Apr 2012 09:40:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:40:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11716870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:40:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:40:25 +0100
Message-ID: <1333359624.25602.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 10:40:24 +0100
In-Reply-To: <1332443876-28506-6-git-send-email-david.vrabel@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>
	<1332443876-28506-6-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5/5] device tree: print a warning if a node
 is nested too deep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Since device_tree_for_each_node() is called before printk() works, a
> variable is used to switch between using early_printk() and printk().
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(although I separately wonder if generic printk ought not to redirect to
early_printk early on)

>  xen/common/device_tree.c |   19 ++++++++++++++++++-
>  1 files changed, 18 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 8fb6d46..04619f4 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -23,6 +23,10 @@
>  struct dt_early_info __initdata early_info;
>  void *device_tree_flattened;
>  
> +/* Some device tree functions may be called both before and after the
> +   console is initialized. */
> +static void (*dt_printk)(const char *fmt, ...) = early_printk;
> +
>  bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
>  {
>      const char *name;
> @@ -90,6 +94,11 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
>   * @fdt: flat device tree.
>   * @func: function to call for each node.
>   * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a negative value, that value is returned immediately.
>   */
>  int device_tree_for_each_node(const void *fdt,
>                                device_tree_node_func func, void *data)
> @@ -104,13 +113,19 @@ int device_tree_for_each_node(const void *fdt,
>            node >=0 && depth >= 0;
>            node = fdt_next_node(fdt, node, &depth) )
>      {
> +        const char *name = fdt_get_name(fdt, node, NULL);
> +
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +        {
> +            dt_printk("Warning: device tree node `%s' is nested too deep\n",
> +                      name);
>              continue;
> +        }
>  
>          address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
>          size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
>  
> -        ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
> +        ret = func(fdt, node, name, depth,
>                     address_cells[depth-1], size_cells[depth-1], data);
>          if ( ret < 0 )
>              return ret;
> @@ -253,6 +268,8 @@ size_t __init device_tree_early_init(const void *fdt)
>      device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
>      early_print_info();
>  
> +    dt_printk = printk;
> +
>      return fdt_totalsize(fdt);
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:55:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdzC-0004it-Pa; Mon, 02 Apr 2012 09:55:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdzB-0004ik-6d
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 09:55:41 +0000
Received: from [193.109.254.147:33046] by server-2.bemta-14.messagelabs.com id
	47/9C-19409-C97797F4; Mon, 02 Apr 2012 09:55:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333360539!3004934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8515 invoked from network); 2 Apr 2012 09:55:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:55:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11717253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:55:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:55:39 +0100
Message-ID: <1333360537.25602.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 2 Apr 2012 10:55:37 +0100
In-Reply-To: <1333136105.12209.3.camel@dagon.hellion.org.uk>
References: <dad4fc193c4b160ac55d.1333030832@whitby.uk.xensource.com>
	<1333124012.15932.118.camel@zakaz.uk.xensource.com>
	<20120330163730.GC90203@ocelot.phlegethon.org>
	<1333136105.12209.3.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: Use HTPIDR to point to per-CPU state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-03-30 at 20:35 +0100, Ian Campbell wrote:
> If it's a simple as that I'll fix it as I apply.

Applied:

arm: remove code that sets current to itself
arm: missing unlock in GIC error path
arm: Use HTPIDR to point to per-CPU state (modified as discussed)

Thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:55:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdzC-0004it-Pa; Mon, 02 Apr 2012 09:55:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdzB-0004ik-6d
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 09:55:41 +0000
Received: from [193.109.254.147:33046] by server-2.bemta-14.messagelabs.com id
	47/9C-19409-C97797F4; Mon, 02 Apr 2012 09:55:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333360539!3004934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8515 invoked from network); 2 Apr 2012 09:55:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:55:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11717253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:55:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:55:39 +0100
Message-ID: <1333360537.25602.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 2 Apr 2012 10:55:37 +0100
In-Reply-To: <1333136105.12209.3.camel@dagon.hellion.org.uk>
References: <dad4fc193c4b160ac55d.1333030832@whitby.uk.xensource.com>
	<1333124012.15932.118.camel@zakaz.uk.xensource.com>
	<20120330163730.GC90203@ocelot.phlegethon.org>
	<1333136105.12209.3.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: Use HTPIDR to point to per-CPU state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-03-30 at 20:35 +0100, Ian Campbell wrote:
> If it's a simple as that I'll fix it as I apply.

Applied:

arm: remove code that sets current to itself
arm: missing unlock in GIC error path
arm: Use HTPIDR to point to per-CPU state (modified as discussed)

Thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:56:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdzy-0004om-7F; Mon, 02 Apr 2012 09:56:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdms-0004Oe-2y
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:42:58 +0000
Received: from [85.158.139.83:39239] by server-3.bemta-5.messagelabs.com id
	9D/EB-25237-1A4797F4; Mon, 02 Apr 2012 09:42:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333359774!22038925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15821 invoked from network); 2 Apr 2012 09:42:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:42:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11716944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:42:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:42:54 +0100
Message-ID: <1333359773.25602.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thomas Gleixner <tglx@linutronix.de>
Date: Mon, 2 Apr 2012 10:42:53 +0100
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com> <alpine.LFD.2.02.1203302333560.2542@ionos>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:56:29 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Attilio Rao <attilio.rao@citrix.com>, Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-03-30 at 23:07 +0100, Thomas Gleixner wrote:
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.

It probably doesn't materially effect your core point (which seems valid
to me) but it's worth pointing out that the numbers presented in this
thread are AFAICT mostly focused on ensuring that that the impact of
this infrastructure is acceptable on native rather than showing the
benefits for virtualized workloads.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 09:56:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 09:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEdzy-0004om-7F; Mon, 02 Apr 2012 09:56:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEdms-0004Oe-2y
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:42:58 +0000
Received: from [85.158.139.83:39239] by server-3.bemta-5.messagelabs.com id
	9D/EB-25237-1A4797F4; Mon, 02 Apr 2012 09:42:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333359774!22038925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15821 invoked from network); 2 Apr 2012 09:42:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:42:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11716944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:42:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	10:42:54 +0100
Message-ID: <1333359773.25602.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thomas Gleixner <tglx@linutronix.de>
Date: Mon, 2 Apr 2012 10:42:53 +0100
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com> <alpine.LFD.2.02.1203302333560.2542@ionos>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 02 Apr 2012 09:56:29 +0000
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Attilio Rao <attilio.rao@citrix.com>, Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-03-30 at 23:07 +0100, Thomas Gleixner wrote:
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.

It probably doesn't materially effect your core point (which seems valid
to me) but it's worth pointing out that the numbers presented in this
thread are AFAICT mostly focused on ensuring that that the impact of
this infrastructure is acceptable on native rather than showing the
benefits for virtualized workloads.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:00:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEe3N-00058r-W5; Mon, 02 Apr 2012 10:00:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SEe3L-00057H-M4
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:59:59 +0000
Received: from [193.109.254.147:28148] by server-10.bemta-14.messagelabs.com
	id 33/C2-05847-F98797F4; Mon, 02 Apr 2012 09:59:59 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333360716!2986304!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxODM1NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13571 invoked from network); 2 Apr 2012 09:59:47 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 09:59:47 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 2 Apr 2012 15:22:37 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 2 Apr 2012 15:22:33 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q329qU333879042
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 15:22:30 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q32FMuXD008376
	for <xen-devel@lists.xensource.com>; Tue, 3 Apr 2012 01:22:59 +1000
Received: from [9.124.158.108] ([9.124.158.108])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q32FMuRk008350; Tue, 3 Apr 2012 01:22:56 +1000
Message-ID: <4F7976B6.5050000@linux.vnet.ibm.com>
Date: Mon, 02 Apr 2012 15:21:50 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
In-Reply-To: <4F785DCF.7020809@redhat.com>
x-cbid: 12040209-5564-0000-0000-0000020E4FA2
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Attilio Rao <attilio.rao@citrix.com>, Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 07:23 PM, Avi Kivity wrote:
 > On 04/01/2012 04:48 PM, Raghavendra K T wrote:
 >>>> I have patch something like below in mind to try:
 >>>>
 >>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
 >>>> index d3b98b1..5127668 100644
 >>>> --- a/virt/kvm/kvm_main.c
 >>>> +++ b/virt/kvm/kvm_main.c
 >>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
 >>>>         * else and called schedule in __vcpu_run.  Hopefully that
 >>>>         * VCPU is holding the lock that we need and will release it.
 >>>>         * We approximate round-robin by starting at the last boosted
 >>>> VCPU.
 >>>> +     * Priority is given to vcpu that are unhalted.
 >>>>         */
 >>>> -    for (pass = 0; pass<   2&&   !yielded; pass++) {
 >>>> +    for (pass = 0; pass<   3&&   !yielded; pass++) {
 >>>>            kvm_for_each_vcpu(i, vcpu, kvm) {
 >>>>                struct task_struct *task = NULL;
 >>>>                struct pid *pid;
 >>>> -            if (!pass&&   i<   last_boosted_vcpu) {
 >>>> +            if (!pass&&   !vcpu->pv_unhalted)
 >>>> +                continue;
 >>>> +            else if (pass == 1&&   i<   last_boosted_vcpu) {
 >>>>                    i = last_boosted_vcpu;
 >>>>                    continue;
 >>>> -            } else if (pass&&   i>   last_boosted_vcpu)
 >>>> +            } else if (pass == 2&&   i>   last_boosted_vcpu)
 >>>>                    break;
 >>>>                if (vcpu == me)
 >>>>                    continue;
 >>>>
 >>>
 >>> Actually I think this is unneeded.  The loops tries to find vcpus that
 >>> are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
 >>> don't match this condition.
 >>>

Oh! I think I misinterpreted your statement. hmm I got it. you told to
remove if (vcpu == me) condition.

I got some more interesting idea ( not sure there is some flaw in idea too).
Basically tried  similar idea (to PLE exit handler) in vcpu_block.

Instead of blind scheduling we try to do yield to vcpu that is kicked.
IMO it may solve some scalability problem and make LHP problem further
shrink.

I think Thomas would be happy to see the result.

results:
test setup.
===========
Host: i5-2540M CPU @ 2.60GHz laptop with 4cpu w/ hyperthreading. 8GB RAM
guest: 16 vcpu 2GB RAM  single guest.

Did kernbench run under guest:
x rc6-with ticketlock (current patchset)+ kvmpatches 
(CONFIG_PARAVIRT_SPINLOCK=y)
+ rc6-with ticketlock + kvmpatches + try_yield_patch (below one) 
(YIELD_THRESHOLD=256) (CONFIG_PARAVIRT_SPINLOCK=y)
* rc6-withticketlock + kvmpatches + try_yield_patch 
(YIELD_THRESHOLD=2048) (CONFIG_PARAVIRT_SPINLOCK=y)

N           Min           Max        Median           Avg        Stddev
x   3        162.45        165.94       165.433     164.60767     1.8857111
+   3        114.02       117.243       115.953     115.73867     1.6221548
Difference at 95.0% confidence
         -29.6882% +/- 2.42192%
*   3       115.823       120.423       117.103       117.783     2.3741946
Difference at 95.0% confidence
         -28.4462% +/- 2.9521%


improvement ~29% w.r.t to current patches.

Note: vanilla rc6 (host and guest) with (CONFIG_PARAVIRT_SPINLOCK=n)
did not finish kernbench run even after *1hr 45* minutes (above
kernbench runs took 9 minute and  6.5 min respectively). I did not try
to test it again.


Yes, I understand that  have to do some more test. and immediate TODO's
for patch are.

1) code belongs to arch/x86 directory and fill in static inline for
other archs
2) tweek YIELD_THRESHOLD value.

Ideas/suggestions welcome

Here is the try_yield_to patch.
---
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 5127668..3fa912a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1557,12 +1557,17 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
  	mark_page_dirty_in_slot(kvm, memslot, gfn);
  }

+#define YIELD_THRESHOLD 2048
+static void kvm_vcpu_try_yield_to(struct kvm_vcpu *me);
  /*
   * The vCPU has executed a HLT instruction with in-kernel mode enabled.
   */
  void kvm_vcpu_block(struct kvm_vcpu *vcpu)
  {
  	DEFINE_WAIT(wait);
+	unsigned int loop_count;
+
+	loop_count = 0;

  	for (;;) {
  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
@@ -1579,7 +1584,10 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
  		if (signal_pending(current))
  			break;

-		schedule();
+		if (loop_count++ % YIELD_THRESHOLD)
+			schedule();
+		else
+			kvm_vcpu_try_yield_to(vcpu);
  	}

  	finish_wait(&vcpu->wq, &wait);
@@ -1593,6 +1601,39 @@ void kvm_resched(struct kvm_vcpu *vcpu)
  }
  EXPORT_SYMBOL_GPL(kvm_resched);

+static void kvm_vcpu_try_yield(struct kvm_vcpu *me)
+{
+
+	struct kvm *kvm = me->kvm;
+	struct kvm_vcpu *vcpu;
+	int i;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		struct task_struct *task = NULL;
+		struct pid *pid;
+		if (!vcpu->pv_unhalted)
+			continue;
+		if (waitqueue_active(&vcpu->wq))
+			continue;
+		rcu_read_lock();
+		pid = rcu_dereference(vcpu->pid);
+		if (pid)
+			task = get_pid_task(vcpu->pid, PIDTYPE_PID);
+		rcu_read_unlock();
+		if (!task)
+			continue;
+		if (task->flags & PF_VCPU) {
+			put_task_struct(task);
+			continue;
+		}
+		if (yield_to(task, 1)) {
+			put_task_struct(task);
+			break;
+		}
+		put_task_struct(task);
+	}
+}
+
  void kvm_vcpu_on_spin(struct kvm_vcpu *me)
  {
  	struct kvm *kvm = me->kvm;
---


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:00:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEe3N-00058r-W5; Mon, 02 Apr 2012 10:00:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SEe3L-00057H-M4
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 09:59:59 +0000
Received: from [193.109.254.147:28148] by server-10.bemta-14.messagelabs.com
	id 33/C2-05847-F98797F4; Mon, 02 Apr 2012 09:59:59 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333360716!2986304!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxODM1NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13571 invoked from network); 2 Apr 2012 09:59:47 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 09:59:47 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 2 Apr 2012 15:22:37 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 2 Apr 2012 15:22:33 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q329qU333879042
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 15:22:30 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q32FMuXD008376
	for <xen-devel@lists.xensource.com>; Tue, 3 Apr 2012 01:22:59 +1000
Received: from [9.124.158.108] ([9.124.158.108])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q32FMuRk008350; Tue, 3 Apr 2012 01:22:56 +1000
Message-ID: <4F7976B6.5050000@linux.vnet.ibm.com>
Date: Mon, 02 Apr 2012 15:21:50 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
In-Reply-To: <4F785DCF.7020809@redhat.com>
x-cbid: 12040209-5564-0000-0000-0000020E4FA2
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Attilio Rao <attilio.rao@citrix.com>, Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 07:23 PM, Avi Kivity wrote:
 > On 04/01/2012 04:48 PM, Raghavendra K T wrote:
 >>>> I have patch something like below in mind to try:
 >>>>
 >>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
 >>>> index d3b98b1..5127668 100644
 >>>> --- a/virt/kvm/kvm_main.c
 >>>> +++ b/virt/kvm/kvm_main.c
 >>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
 >>>>         * else and called schedule in __vcpu_run.  Hopefully that
 >>>>         * VCPU is holding the lock that we need and will release it.
 >>>>         * We approximate round-robin by starting at the last boosted
 >>>> VCPU.
 >>>> +     * Priority is given to vcpu that are unhalted.
 >>>>         */
 >>>> -    for (pass = 0; pass<   2&&   !yielded; pass++) {
 >>>> +    for (pass = 0; pass<   3&&   !yielded; pass++) {
 >>>>            kvm_for_each_vcpu(i, vcpu, kvm) {
 >>>>                struct task_struct *task = NULL;
 >>>>                struct pid *pid;
 >>>> -            if (!pass&&   i<   last_boosted_vcpu) {
 >>>> +            if (!pass&&   !vcpu->pv_unhalted)
 >>>> +                continue;
 >>>> +            else if (pass == 1&&   i<   last_boosted_vcpu) {
 >>>>                    i = last_boosted_vcpu;
 >>>>                    continue;
 >>>> -            } else if (pass&&   i>   last_boosted_vcpu)
 >>>> +            } else if (pass == 2&&   i>   last_boosted_vcpu)
 >>>>                    break;
 >>>>                if (vcpu == me)
 >>>>                    continue;
 >>>>
 >>>
 >>> Actually I think this is unneeded.  The loops tries to find vcpus that
 >>> are runnable but not running (vcpu_active(vcpu->wq)), and halted vcpus
 >>> don't match this condition.
 >>>

Oh! I think I misinterpreted your statement. hmm I got it. you told to
remove if (vcpu == me) condition.

I got some more interesting idea ( not sure there is some flaw in idea too).
Basically tried  similar idea (to PLE exit handler) in vcpu_block.

Instead of blind scheduling we try to do yield to vcpu that is kicked.
IMO it may solve some scalability problem and make LHP problem further
shrink.

I think Thomas would be happy to see the result.

results:
test setup.
===========
Host: i5-2540M CPU @ 2.60GHz laptop with 4cpu w/ hyperthreading. 8GB RAM
guest: 16 vcpu 2GB RAM  single guest.

Did kernbench run under guest:
x rc6-with ticketlock (current patchset)+ kvmpatches 
(CONFIG_PARAVIRT_SPINLOCK=y)
+ rc6-with ticketlock + kvmpatches + try_yield_patch (below one) 
(YIELD_THRESHOLD=256) (CONFIG_PARAVIRT_SPINLOCK=y)
* rc6-withticketlock + kvmpatches + try_yield_patch 
(YIELD_THRESHOLD=2048) (CONFIG_PARAVIRT_SPINLOCK=y)

N           Min           Max        Median           Avg        Stddev
x   3        162.45        165.94       165.433     164.60767     1.8857111
+   3        114.02       117.243       115.953     115.73867     1.6221548
Difference at 95.0% confidence
         -29.6882% +/- 2.42192%
*   3       115.823       120.423       117.103       117.783     2.3741946
Difference at 95.0% confidence
         -28.4462% +/- 2.9521%


improvement ~29% w.r.t to current patches.

Note: vanilla rc6 (host and guest) with (CONFIG_PARAVIRT_SPINLOCK=n)
did not finish kernbench run even after *1hr 45* minutes (above
kernbench runs took 9 minute and  6.5 min respectively). I did not try
to test it again.


Yes, I understand that  have to do some more test. and immediate TODO's
for patch are.

1) code belongs to arch/x86 directory and fill in static inline for
other archs
2) tweek YIELD_THRESHOLD value.

Ideas/suggestions welcome

Here is the try_yield_to patch.
---
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 5127668..3fa912a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1557,12 +1557,17 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
  	mark_page_dirty_in_slot(kvm, memslot, gfn);
  }

+#define YIELD_THRESHOLD 2048
+static void kvm_vcpu_try_yield_to(struct kvm_vcpu *me);
  /*
   * The vCPU has executed a HLT instruction with in-kernel mode enabled.
   */
  void kvm_vcpu_block(struct kvm_vcpu *vcpu)
  {
  	DEFINE_WAIT(wait);
+	unsigned int loop_count;
+
+	loop_count = 0;

  	for (;;) {
  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
@@ -1579,7 +1584,10 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
  		if (signal_pending(current))
  			break;

-		schedule();
+		if (loop_count++ % YIELD_THRESHOLD)
+			schedule();
+		else
+			kvm_vcpu_try_yield_to(vcpu);
  	}

  	finish_wait(&vcpu->wq, &wait);
@@ -1593,6 +1601,39 @@ void kvm_resched(struct kvm_vcpu *vcpu)
  }
  EXPORT_SYMBOL_GPL(kvm_resched);

+static void kvm_vcpu_try_yield(struct kvm_vcpu *me)
+{
+
+	struct kvm *kvm = me->kvm;
+	struct kvm_vcpu *vcpu;
+	int i;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		struct task_struct *task = NULL;
+		struct pid *pid;
+		if (!vcpu->pv_unhalted)
+			continue;
+		if (waitqueue_active(&vcpu->wq))
+			continue;
+		rcu_read_lock();
+		pid = rcu_dereference(vcpu->pid);
+		if (pid)
+			task = get_pid_task(vcpu->pid, PIDTYPE_PID);
+		rcu_read_unlock();
+		if (!task)
+			continue;
+		if (task->flags & PF_VCPU) {
+			put_task_struct(task);
+			continue;
+		}
+		if (yield_to(task, 1)) {
+			put_task_struct(task);
+			break;
+		}
+		put_task_struct(task);
+	}
+}
+
  void kvm_vcpu_on_spin(struct kvm_vcpu *me)
  {
  	struct kvm *kvm = me->kvm;
---


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeTP-00065t-2t; Mon, 02 Apr 2012 10:26:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrei.Lifchits@citrix.com>) id 1SEe03-0004pU-GT
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 09:56:35 +0000
Received: from [85.158.143.35:57787] by server-1.bemta-4.messagelabs.com id
	5F/5C-20925-2D7797F4; Mon, 02 Apr 2012 09:56:34 +0000
X-Env-Sender: Andrei.Lifchits@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333360592!16710477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23061 invoked from network); 2 Apr 2012 09:56:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:56:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11717273"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:56:32 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 2 Apr 2012
	10:56:32 +0100
From: Andrei Lifchits <Andrei.Lifchits@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 2 Apr 2012 10:56:31 +0100
Thread-Topic: [Xen-devel] blkback global resources
Thread-Index: Ac0L6ubp2H7tkcZiRwK0SROZub+Q7gEySnhg
Message-ID: <B45B24330584FB4AAE78E08B8F5E5B5ECBF5C5F365@LONPMAILBOX01.citrite.net>
References: <CB965278.2F50F%keir.xen@gmail.com>
	<1332780797.30244.159.camel@espiritosanto>
	<4F7187E9020000780007B09A@nat28.tlf.novell.com>
In-Reply-To: <4F7187E9020000780007B09A@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 02 Apr 2012 10:26:53 +0000
Cc: Felipe Franciosi <felipe.franciosi@citrix.com>,
	Daniel Stodden <daniel.stodden@googlemail.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback global resources
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, March 27, 2012 8:27 AM
> To: Daniel Stodden
> Cc: Andrei Lifchits; xen-devel
> Subject: Re: [Xen-devel] blkback global resources
> 
> >>> On 26.03.12 at 18:53, Daniel Stodden <daniel.stodden@googlemail.com>
> wrote:
> > On Mon, 2012-03-26 at 17:06 +0100, Keir Fraser wrote:
> >> Cc'ing Daniel for you on this one, Jan.
> >>
> >>  K.
> >>
> >> On 26/03/2012 16:56, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>
> >> > All the resources allocated based on xen_blkif_reqs are global in
> >> > blkback. While (without having measured anything) I think that this
> >> > is bad from a QoS perspective (not the least implied from a warning
> >> > issued by Citrix'es multi-page-ring patches:
> >> >
> >> > if (blkif_reqs < BLK_RING_SIZE(order)) printk(KERN_WARNING
> >> > "WARNING: "
> >> >       "I/O request space (%d reqs) < ring order %ld, "
> >> >       "consider increasing %s.reqs to >= %ld.",
> >> >       blkif_reqs, order, KBUILD_MODNAME,
> >> >       roundup_pow_of_two(BLK_RING_SIZE(order)));
> >> >
> >> > indicating that this _is_ a bottleneck), I'm otoh hesitant to
> >> > convert this to per-instance allocations, as the amount of memory
> >> > taken away from Dom0 for this may be not insignificant when there
> >> > are many devices.
> >> >
> >> > Does anyone have an opinion here, in particular regarding the
> >> > original authors' decision to make this global vs. the apparently
> >> > made observation (by Daniel Stodden, the author of said patch, who
> >> > I don't have any current email of to ask directly), but also in the
> >> > context of multi-page rings, the purpose of which is to allow for
> >> > larger amounts of in-flight I/O?
> >> >
> >> > Thanks, Jan
> >
> > Re-CC'ing Andrei Lifchits, I think there's been some work going on at
> > Citrix regarding that matter.
> >
> > Yes, just allocating a pfn pool per backend instance is way too much
> > memory balooned out. Otherwise this stuff would have never looked the
> > way it does now.
> 
> This of course could be accounted for by having an initially non-empty (large
> enough) balloon (not sure how easy it is these days to do this for pv-ops, but
> it has always been trivial with the legacy code). That wouldn't help a 32-bit
> kernel much (where generally the initial balloon is all in highmem, yet the
> vacated pages need to be in lowmem), but for 64-bit kernels it should be
> fine.
> 
> > Regarding the right balance, note that on the other extreme end, if
> > PFN space were infinite, there's not much expected performance gain
> > from rendering virtual backends fully independent. Beyond controller
> > queue depth, these requests are all just going to pile up, waiting.
> 
> Is there a way to look through the queue stack to find out how many distinct
> ones there are that the backend is running on top of as well as - for a
> particular I/O path - the one with the smallest depth? Or can one assume
> that the top most one (generally loop's or blktap2's) won't advertise a queue
> deeper than what is going to be accepted downstream (probably not, I'd
> guess)?

Hm, I don't remember seeing anything relating to that off the top of my head in the blkback code, so I don't think so. (I'm not sure the benefit would be that great, anyways).

> And - what you say would similarly apply to the usefulness of multi-page
> rings afaict.
> 
> > XenServer has some support for decoupling in blktap.ko [1] which
> > worked relatively well: Use frame 'pool' kobjects. A bunch of pages,
> > mapped to sysfs object. Name was arbitrary. Size configurable, even at
> runtime.

I have added a similar functionality to blkback (pools configurable through xenstore, with userland tools creating one pool per SR), which is now out in the form of a limited-availability hotfix and will be there in the next XenServer release. Felipe (CC'd) measured the effects on performance and found that it helps.

> > Sysfs meant stuff was easily set up by shell or python code, or
> > manually. To become operational, every backend must be bound to a pool
> > (initially, the global 'default' one, for tool compat). Backends can
> > be relinked arbitrarily before entering Connected state.
> >
> > Then let the userland toolstack set things up according to physical
> > I/O topology and properties probed. Basically every physical backend
> > (say, a volume group, or a HBA) would start out by allocating and
> > dimensioning a dedicated pool (named after the backend), and every
> > backend instance fired up gets bound to the pool it belongs to.
> 
> Having userland do all that seems like a fallback solution only to me - I would
> hope that sufficient information is available directly to the drivers.

You're probably right.

> Thanks in any case for responding so quickly, Jan
> 
> > There's a lot of additional optimizations one could consider, e.g.
> > autogrowing the pool (log(nbackends) or so?) and the like. To improve
> > locality, having backends which look ahead in their request queue and
> > allocate whole batches is probably a good idea too, etc, etc.
> >
> > HTH,
> > Daniel
> >
> > [1]
> > http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git
> >  mostly in drivers/block/blktap/sysfs.c (show/store_pool) and request.c.
> >  Note that these are based on mempools, not the frame pools blkback
> > would take.
> 

Cheers,
Andrei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeTP-00065t-2t; Mon, 02 Apr 2012 10:26:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrei.Lifchits@citrix.com>) id 1SEe03-0004pU-GT
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 09:56:35 +0000
Received: from [85.158.143.35:57787] by server-1.bemta-4.messagelabs.com id
	5F/5C-20925-2D7797F4; Mon, 02 Apr 2012 09:56:34 +0000
X-Env-Sender: Andrei.Lifchits@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333360592!16710477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23061 invoked from network); 2 Apr 2012 09:56:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 09:56:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11717273"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 09:56:32 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 2 Apr 2012
	10:56:32 +0100
From: Andrei Lifchits <Andrei.Lifchits@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 2 Apr 2012 10:56:31 +0100
Thread-Topic: [Xen-devel] blkback global resources
Thread-Index: Ac0L6ubp2H7tkcZiRwK0SROZub+Q7gEySnhg
Message-ID: <B45B24330584FB4AAE78E08B8F5E5B5ECBF5C5F365@LONPMAILBOX01.citrite.net>
References: <CB965278.2F50F%keir.xen@gmail.com>
	<1332780797.30244.159.camel@espiritosanto>
	<4F7187E9020000780007B09A@nat28.tlf.novell.com>
In-Reply-To: <4F7187E9020000780007B09A@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 02 Apr 2012 10:26:53 +0000
Cc: Felipe Franciosi <felipe.franciosi@citrix.com>,
	Daniel Stodden <daniel.stodden@googlemail.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback global resources
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, March 27, 2012 8:27 AM
> To: Daniel Stodden
> Cc: Andrei Lifchits; xen-devel
> Subject: Re: [Xen-devel] blkback global resources
> 
> >>> On 26.03.12 at 18:53, Daniel Stodden <daniel.stodden@googlemail.com>
> wrote:
> > On Mon, 2012-03-26 at 17:06 +0100, Keir Fraser wrote:
> >> Cc'ing Daniel for you on this one, Jan.
> >>
> >>  K.
> >>
> >> On 26/03/2012 16:56, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>
> >> > All the resources allocated based on xen_blkif_reqs are global in
> >> > blkback. While (without having measured anything) I think that this
> >> > is bad from a QoS perspective (not the least implied from a warning
> >> > issued by Citrix'es multi-page-ring patches:
> >> >
> >> > if (blkif_reqs < BLK_RING_SIZE(order)) printk(KERN_WARNING
> >> > "WARNING: "
> >> >       "I/O request space (%d reqs) < ring order %ld, "
> >> >       "consider increasing %s.reqs to >= %ld.",
> >> >       blkif_reqs, order, KBUILD_MODNAME,
> >> >       roundup_pow_of_two(BLK_RING_SIZE(order)));
> >> >
> >> > indicating that this _is_ a bottleneck), I'm otoh hesitant to
> >> > convert this to per-instance allocations, as the amount of memory
> >> > taken away from Dom0 for this may be not insignificant when there
> >> > are many devices.
> >> >
> >> > Does anyone have an opinion here, in particular regarding the
> >> > original authors' decision to make this global vs. the apparently
> >> > made observation (by Daniel Stodden, the author of said patch, who
> >> > I don't have any current email of to ask directly), but also in the
> >> > context of multi-page rings, the purpose of which is to allow for
> >> > larger amounts of in-flight I/O?
> >> >
> >> > Thanks, Jan
> >
> > Re-CC'ing Andrei Lifchits, I think there's been some work going on at
> > Citrix regarding that matter.
> >
> > Yes, just allocating a pfn pool per backend instance is way too much
> > memory balooned out. Otherwise this stuff would have never looked the
> > way it does now.
> 
> This of course could be accounted for by having an initially non-empty (large
> enough) balloon (not sure how easy it is these days to do this for pv-ops, but
> it has always been trivial with the legacy code). That wouldn't help a 32-bit
> kernel much (where generally the initial balloon is all in highmem, yet the
> vacated pages need to be in lowmem), but for 64-bit kernels it should be
> fine.
> 
> > Regarding the right balance, note that on the other extreme end, if
> > PFN space were infinite, there's not much expected performance gain
> > from rendering virtual backends fully independent. Beyond controller
> > queue depth, these requests are all just going to pile up, waiting.
> 
> Is there a way to look through the queue stack to find out how many distinct
> ones there are that the backend is running on top of as well as - for a
> particular I/O path - the one with the smallest depth? Or can one assume
> that the top most one (generally loop's or blktap2's) won't advertise a queue
> deeper than what is going to be accepted downstream (probably not, I'd
> guess)?

Hm, I don't remember seeing anything relating to that off the top of my head in the blkback code, so I don't think so. (I'm not sure the benefit would be that great, anyways).

> And - what you say would similarly apply to the usefulness of multi-page
> rings afaict.
> 
> > XenServer has some support for decoupling in blktap.ko [1] which
> > worked relatively well: Use frame 'pool' kobjects. A bunch of pages,
> > mapped to sysfs object. Name was arbitrary. Size configurable, even at
> runtime.

I have added a similar functionality to blkback (pools configurable through xenstore, with userland tools creating one pool per SR), which is now out in the form of a limited-availability hotfix and will be there in the next XenServer release. Felipe (CC'd) measured the effects on performance and found that it helps.

> > Sysfs meant stuff was easily set up by shell or python code, or
> > manually. To become operational, every backend must be bound to a pool
> > (initially, the global 'default' one, for tool compat). Backends can
> > be relinked arbitrarily before entering Connected state.
> >
> > Then let the userland toolstack set things up according to physical
> > I/O topology and properties probed. Basically every physical backend
> > (say, a volume group, or a HBA) would start out by allocating and
> > dimensioning a dedicated pool (named after the backend), and every
> > backend instance fired up gets bound to the pool it belongs to.
> 
> Having userland do all that seems like a fallback solution only to me - I would
> hope that sufficient information is available directly to the drivers.

You're probably right.

> Thanks in any case for responding so quickly, Jan
> 
> > There's a lot of additional optimizations one could consider, e.g.
> > autogrowing the pool (log(nbackends) or so?) and the like. To improve
> > locality, having backends which look ahead in their request queue and
> > allocate whole batches is probably a good idea too, etc, etc.
> >
> > HTH,
> > Daniel
> >
> > [1]
> > http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git
> >  mostly in drivers/block/blktap/sysfs.c (show/store_pool) and request.c.
> >  Note that these are based on mempools, not the frame pools blkback
> > would take.
> 

Cheers,
Andrei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeTI-00065O-MW; Mon, 02 Apr 2012 10:26:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEeTH-00065A-1M
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:26:47 +0000
Received: from [85.158.143.35:16082] by server-2.bemta-4.messagelabs.com id
	3C/BF-17550-5EE797F4; Mon, 02 Apr 2012 10:26:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333362404!13481923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4147 invoked from network); 2 Apr 2012 10:26:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:26:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11718137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:26:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	11:26:43 +0100
Message-ID: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 2 Apr 2012 11:26:42 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt
bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv
bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg
ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZSAgICAgICAgICAgICAgIDw8IFdFIEFSRSBIRVJFCk1p
ZC9MYXRlIEFwcmlsICAtLSBGaXJzdCByZWxlYXNlIGNhbmRpZGF0ZQpXZWVrbHkgICAgICAgICAg
LS0gUkNOKzEgdW50aWwgaXQgaXMgcmVhZHkKClRoZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dz
LiBQZXIgdGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwKbm93IGhhdmUgdG8gYmUg
bWFkZSBhcyB0byB3aHkgbmV3IGl0ZW1zIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgbGlzdCwKZXNw
ZWNpYWxseSBhcyBhIGJsb2NrZXIsIHJhdGhlciB0aGFuIGRlZmVycmVkIHRvIDQuMy4KCldlIGhh
dmUgbm93IGVudGVyZWQgRmVhdHVyZSBGcmVlemUuIFBhdGNoZXMgd2hpY2ggaGF2ZSBiZWVuIHBv
c3RlZApiZWZvcmUgb3Igd2hpY2ggYWRkcmVzcyBzb21ldGhpbmcgb24gdGhlIGxpc3QgYmVsb3cg
YXJlIHN0aWxsIGFjY2VwdGFibGUKKGZvciBub3csIHdlIHdpbGwgZ3JhZHVhbGx5IGJlIGdldHRp
bmcgc3RyaWN0ZXIgYWJvdXQgdGhpcyksIGV2ZXJ5dGhpbmcKZWxzZSB3aWxsIGJlIGRlZmVycmVk
IHVudGlsIDQuMyBieSBkZWZhdWx0LgoKaHlwZXJ2aXNvciwgYmxvY2tlcnM6CiAgICAgICogTk9O
RT8KIAp0b29scywgYmxvY2tlcnM6CiAgICAgICogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3Vs
ZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAgICAgd2hpY2ggZG93bnN0cmVh
bSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgogICAgICAg
IHRoaXMgYXJlOgogICAgICAgICAgICAgICogU2FmZSBmb3JrIHZzLiBmZCBoYW5kbGluZyBob29r
cy4gSW52b2x2ZXMgQVBJIGNoYW5nZXMKICAgICAgICAgICAgICAgIChJYW4gSiwgcGF0Y2hlcyBw
b3N0ZWQpCiAgICAgICAgICAgICAgKiBsb2NraW5nL3NlcmlhbGl6YXRpb24sIGUuZy4sIGZvciBk
b21haW4gY3JlYXRpb24uIEFzIG9mCiAgICAgICAgICAgICAgICBub3csICBub3RoaW5nIGlzIHBy
b3ZpZGVkIGZvciB0aGlzIHB1cnBvc2UsIGFuZAogICAgICAgICAgICAgICAgZG93bnN0cmVhbSB0
b29sc3RhY2tzIGhhdmUgdG8gcHV0IHRoZWlyIG93biBtZWNoYW5pc21zCiAgICAgICAgICAgICAg
ICBpbiBwbGFjZS4gRS5nLiwgeGwgdXNlcyBhIGZjbnRsKCkgbG9jayBhcm91bmQgdGhlIHdob2xl
CiAgICAgICAgICAgICAgICBwcm9jZXNzIG9mIGRvbWFpbiBjcmVhdGlvbi4gSXQgc2hvdWxkIE9U
T0ggYmUgbGlieGwgam9iCiAgICAgICAgICAgICAgICB0byBvZmZlciBhIHByb3BlciBzZXQgb2Yg
aG9va3MgLS1wbGFjZWQgYXQgdGhlIHByb3BlcgogICAgICAgICAgICAgICAgc3BvdHMgZHVyaW5n
IHRoZSBkb21haW4gY3JlYXRpb24gcHJvY2Vzcy0tIGZvciB0aGUKICAgICAgICAgICAgICAgIGRv
d25zdHJlYW1zIHRvICBmaWxsIHdpdGggdGhlIHByb3BlciBjYWxsYmFja3MuIChEYXJpbwogICAg
ICAgICAgICAgICAgRmFnZ2lvbGkpCiAgICAgICAgICAgICAgKiBhZ3JlZSAmIGRvY3VtZW50IGNv
bXBhdGliaWxpdHkgZ3VhcmFudGVlcyArIGFzc29jaWF0ZWQKICAgICAgICAgICAgICAgIHRlY2hu
aWNhbCBtZWFzdXJlcyAoSWFuIEMsIHBhdGNoZXMgcG9zdGVkKQogICAgICAqIHhsIGNvbXBhdGli
aWxpdHkgd2l0aCB4bToKICAgICAgICAgICAgICAqIGZlYXR1cmUgcGFyaXR5IHdydCBkcml2ZXIg
ZG9tYWluIHN1cHBvcnQgKEdlb3JnZSBEdW5sYXApCiAgICAgICAgICAgICAgKiB4bCBzdXBwb3J0
IGZvciAicnRjX3RpbWVvZmZzZXQiIGFuZCAibG9jYWx0aW1lIiAoTGluCiAgICAgICAgICAgICAg
ICBNaW5nLCBQYXRjaGVzIHBvc3RlZCkKICAgICAgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4
bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgogICAgICAgIHRyZWUuIE5lZWRzIHJl
bGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCiAgICAgICAgcmVt
aW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAqIERvbWFpbiAwIGJsb2NrIGF0dGFjaCAmIGdl
bmVyYWwgaG90cGx1ZyB3aGVuIHVzaW5nIHFkaXNrIGJhY2tlbmQKICAgICAgICAobmVlZCB0byBz
dGFydCBxZW11IGFzIG5lY2Vzc2FyeSBldGMpIChTdGVmYW5vIFMpCiAgICAgICogZmlsZTovLyBi
YWNrZW5kIHBlcmZvcm1hbmNlLiBxZW11LXhlbi10cmFkaXRpb24ncyBxZGlzayBpcyBxdWl0ZQog
ICAgICAgIHNsb3cgJiBibGt0YXAyIG5vdCBhdmFpbGFibGUgaW4gdXBzdHJlYW0ga2VybmVscy4g
TmVlZCB0bwogICAgICAgIGNvbnNpZGVyIG91ciBvcHRpb25zOgogICAgICAgICAgICAgICogcWVt
dS14ZW4ncyBxZGlzayBpcyB0aG91Z2h0IHRvIGJlIHdlbGwgcGVyZm9ybWluZyBidXQKICAgICAg
ICAgICAgICAgIHFlbXUteGVuIGlzIG5vdCB5ZXQgdGhlIGRlZmF1bHQuIENvbXBsZXhpdHkgYXJp
c2luZyBmcm9tCiAgICAgICAgICAgICAgICBzcGxpdHRpbmcgcWVtdS1mb3ItcWRpc2sgb3V0IGZy
b20gcWVtdS1mb3ItZG0gYW5kCiAgICAgICAgICAgICAgICBydW5uaW5nIE4gcWVtdSdzLgogICAg
ICAgICAgICAgICogcG90ZW50aWFsbHkgZnVsbHkgdXNlcnNwYWNlIGJsa3RhcCBjb3VsZCBiZSBy
ZWFkeSBmb3IKICAgICAgICAgICAgICAgIDQuMgogICAgICAgICAgICAgICogdXNlIC9kZXYvbG9v
cCtibGtiYWNrLiBUaGlzIHJlcXVpcmVzIGxvb3AgZHJpdmVyIEFJTyBhbmQKICAgICAgICAgICAg
ICAgIE9fRElSRUNUIHBhdGNoZXMgd2hpY2ggYXJlIG5vdCAoQUZBSUspIHlldCB1cHN0cmVhbS4K
ICAgICAgICAgICAgICAqIExldmVyYWdlIFhDUCdzIGJsa3RhcDIgREtNUyB3b3JrLgogICAgICAg
ICAgICAgICogT3RoZXIgaWRlYXM/CiAgICAgICAgICAgICAgICAgICAgICAqIEluIGdlbmVyYWwg
d2Ugc2hvdWxkIHJlY29tbWVuZCBibGtiYWNrIChlLmcuCiAgICAgICAgICAgICAgICAgICAgICAg
IHdpdGggTFZNKSBzaW5jZSBpdCBhbHdheXMgb3V0IHBlcmZvcm1zIG90aGVyCiAgICAgICAgICAg
ICAgICAgICAgICAgIHNvbHV0aW9ucywgYWx0aG91Z2ggYXQgdGhlIGV4cGVuc2Ugb2YKICAgICAg
ICAgICAgICAgICAgICAgICAgZmxleGliaWxpdHkgcmVnYXJkaW5nIGltYWdlIGZvcm1hdHMuCiAg
ICAgICAgU3RlZmFubyBoYXMgZG9uZSBhIGxvdCBvZiB3b3JrIGhlcmUgYW5kIGhhcyBwcm9wb3Nl
ZCBzb21lCiAgICAgICAgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIGZvciBxZGlzayBpbiBib3Ro
IHFlbXUteGVuIGFuZAogICAgICAgIHFlbXUteGVuLXRyYWRpdGlvbmFsIHdoaWNoIG1ha2UgdGhl
bSBhIHBsYXVzaWJsZSBhbHRlcm5hdGl2ZSBmb3IKICAgICAgICBYZW4gNC4yLgogICAgICAqIElt
cHJvdmVkIEhvdHBsdWcgc2NyaXB0IHN1cHBvcnQgKFJvZ2VyIFBhdSBNb25uw6ksIHBhdGNoZXMK
ICAgICAgICBwb3N0ZWQpCiAgICAgICogQmxvY2sgc2NyaXB0IHN1cHBvcnQgLS0gZm9sbG93cyBv
biBmcm9tIGhvdHBsdWcgc2NyaXB0IChSb2dlcgogICAgICAgIFBhdSBNb25uw6kpCgpoeXBlcnZp
c29yLCBuaWNlIHRvIGhhdmU6CiAgICAgICogc29saWQgaW1wbGVtZW50YXRpb24gb2Ygc2hhcmlu
Zy9wYWdpbmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawogICAgICAgIHF1ZXVlcykgKFRpbSBEZWVn
YW4sIE9sYWYgSGVycmluZyBldCBhbCAtLSBwYXRjaGVzIHBvc3RlZCkKICAgICAgICAgICAgICAq
ICJUaGUgbGFzdCBwYXRjaCB0byB1c2UgYSB3YWl0cXVldWUgaW4KICAgICAgICAgICAgICAgIF9f
Z2V0X2dmbl90eXBlX2FjY2VzcygpIGZyb20gVGltIHdvcmtzLiAgSG93ZXZlciwgdGhlcmUKICAg
ICAgICAgICAgICAgIGFyZSBhIGZldyB1c2VycyB3aG8gY2FsbCBfX2dldF9nZm5fdHlwZV9hY2Nl
c3Mgd2l0aCB0aGUKICAgICAgICAgICAgICAgIGRvbWFpbl9sb2NrIGhlbGQuIFRoaXMgcGFydCBu
ZWVkcyB0byBiZSBhZGRyZXNzZWQgaW4KICAgICAgICAgICAgICAgIHNvbWUgd2F5LiIKICAgICAg
KiBTaGFyaW5nIHN1cHBvcnQgZm9yIEFNRCAoVGltLCBBbmRyZXMpLgogICAgICAqIFBvRCBwZXJm
b3JtYW5jZSBpbXByb3ZlbWVudHMgKEdlb3JnZSBEdW5sYXApCgp0b29scywgbmljZSB0byBoYXZl
OgogICAgICAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVy
cmluZywgbG90cyBvZgogICAgICAgIGRpc2N1c3Npb24gYXJvdW5kIGludGVyZmFjZSwgZ2VuZXJh
bCBjb25zZW5zdXMgcmVhY2hlZCBvbiB3aGF0CiAgICAgICAgaXQgc2hvdWxkIGxvb2sgbGlrZS4g
T2xhZiBoYXMgbGV0IG1lIGtub3cgdGhhdCBoZSBpcyBwcm9iYWJseQogICAgICAgIG5vdCBnb2lu
ZyB0byBoYXZlIHRpbWUgdG8gZG8gdGhpcyBmb3IgNC4yLCB3aWxsIGxpa2VseSBzbGlwIHRvCiAg
ICAgICAgNC4zIHVubGVzcyBzb21lb25lIGVsc2Ugd2FudCB0byBwaWNrIHVwIHRoYXQgd29yaykK
ICAgICAgKiBVcHN0cmVhbSBxZW11IGZlYXR1cmUgcGF0Y2hlczoKICAgICAgICAgICAgICAqIFVw
c3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVyYXJkLAogICAg
ICAgICAgICAgICAgcGF0Y2hlcyBzZW50KQogICAgICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBz
YXZlIHJlc3RvcmUgKEFudGhvbnkgUGVyYXJkLCBTdGVmYW5vCiAgICAgICAgICAgICAgICBTdGFi
ZWxsaW5pLCBxZW11IHBhdGNoZXMgYXBwbGllZCwgd2FpdGluZyBmb3IgbGlieGwgZXRjCiAgICAg
ICAgICAgICAgICBzaWRlIHdoaWNoIGhhcyBiZWVuIHJlY2VudGx5IHJlcG9zdGVkKQogICAgICAq
IE5lc3RlZC12aXJ0dWFsaXNhdGlvbi4gQ3VycmVudGx5ICJleHBlcmltZW50YWwiLiBMaWtlbHkg
dG8KICAgICAgICByZWxlYXNlIHRoYXQgd2F5LgogICAgICAgICAgICAgICogTmVzdGVkIFNWTS4g
VGVzdGVkIGluIGEgdmFyaWV0eSBvZiBjb25maWd1cmF0aW9ucyBidXQKICAgICAgICAgICAgICAg
IHN0aWxsIHNvbWUgaXNzdWVzIHdpdGggdGhlIG1vc3QgaW1wb3J0YW50IHVzZSBjYXNlICh3Nwog
ICAgICAgICAgICAgICAgWFAgbW9kZSkgWzBdICAoQ2hyaXN0b3BoIEVnZ2VyKQogICAgICAgICAg
ICAgICogTmVzdGVkIFZNWC4gTmVlZHMgbmVzdGVkIEVQVCB0byBiZSBnZW51aW5lbHkgdXNlZnVs
LgogICAgICAgICAgICAgICAgTmVlZCBtb3JlIGRhdGEgb24gdGVzdGVkbmVzcyBldGMgKEludGVs
KQogICAgICAqIEluaXRpYWwgeGwgc3VwcG9ydCBmb3IgUmVtdXMgKG1lbW9yeSBjaGVja3BvaW50
LCBibGFja2hvbGluZykKICAgICAgICAoU2hyaXJhbSwgcGF0Y2hlcyByZXBvc3RlZCByZWNlbnRs
eSwgd2FzIGJsb2NrZWQgYmVoaW5kIHFlbXUKICAgICAgICBzYXZlIHJlc3RvcmUgcGF0Y2hlcyB3
aGljaCBhcmUgbm93IGluKQogICAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKICAgICAg
ICAgICAgICAqIHhsIHN1cHBvcnQgZm9yIGF1dG9zcGF3bmluZyB2bmN2aWV3ZXIgKHZuY3ZpZXdl
cj0xIG9yCiAgICAgICAgICAgICAgICBvdGhlcndpc2UpIChHb25jYWxvIEdvbWVzLCBwYXRjaGVz
IHBvc3RlZCkKICAgICAgICAgICAgICAqIHN1cHBvcnQgZm9yIHZpZiAicmF0ZSIgcGFyYW1ldGVy
IChNYXRoaWV1IEdhZ27DqSwgcGF0Y2hlcwogICAgICAgICAgICAgICAgcG9zdGVkKQogICAgICAg
ICAgICAgICogZXhwb3NlIFBDSSBiYWNrICJwZXJtaXNzaXZlIiBwYXJhbWV0ZXIgKEdlb3JnZSBE
dW5sYXApCgpbMF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwv
MjAxMi0wMy9tc2cwMDg4My5odG1sCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeTI-00065O-MW; Mon, 02 Apr 2012 10:26:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEeTH-00065A-1M
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:26:47 +0000
Received: from [85.158.143.35:16082] by server-2.bemta-4.messagelabs.com id
	3C/BF-17550-5EE797F4; Mon, 02 Apr 2012 10:26:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333362404!13481923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4147 invoked from network); 2 Apr 2012 10:26:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:26:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11718137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:26:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	11:26:43 +0100
Message-ID: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 2 Apr 2012 11:26:42 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt
bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv
bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg
ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZSAgICAgICAgICAgICAgIDw8IFdFIEFSRSBIRVJFCk1p
ZC9MYXRlIEFwcmlsICAtLSBGaXJzdCByZWxlYXNlIGNhbmRpZGF0ZQpXZWVrbHkgICAgICAgICAg
LS0gUkNOKzEgdW50aWwgaXQgaXMgcmVhZHkKClRoZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dz
LiBQZXIgdGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwKbm93IGhhdmUgdG8gYmUg
bWFkZSBhcyB0byB3aHkgbmV3IGl0ZW1zIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgbGlzdCwKZXNw
ZWNpYWxseSBhcyBhIGJsb2NrZXIsIHJhdGhlciB0aGFuIGRlZmVycmVkIHRvIDQuMy4KCldlIGhh
dmUgbm93IGVudGVyZWQgRmVhdHVyZSBGcmVlemUuIFBhdGNoZXMgd2hpY2ggaGF2ZSBiZWVuIHBv
c3RlZApiZWZvcmUgb3Igd2hpY2ggYWRkcmVzcyBzb21ldGhpbmcgb24gdGhlIGxpc3QgYmVsb3cg
YXJlIHN0aWxsIGFjY2VwdGFibGUKKGZvciBub3csIHdlIHdpbGwgZ3JhZHVhbGx5IGJlIGdldHRp
bmcgc3RyaWN0ZXIgYWJvdXQgdGhpcyksIGV2ZXJ5dGhpbmcKZWxzZSB3aWxsIGJlIGRlZmVycmVk
IHVudGlsIDQuMyBieSBkZWZhdWx0LgoKaHlwZXJ2aXNvciwgYmxvY2tlcnM6CiAgICAgICogTk9O
RT8KIAp0b29scywgYmxvY2tlcnM6CiAgICAgICogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3Vs
ZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAgICAgd2hpY2ggZG93bnN0cmVh
bSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgogICAgICAg
IHRoaXMgYXJlOgogICAgICAgICAgICAgICogU2FmZSBmb3JrIHZzLiBmZCBoYW5kbGluZyBob29r
cy4gSW52b2x2ZXMgQVBJIGNoYW5nZXMKICAgICAgICAgICAgICAgIChJYW4gSiwgcGF0Y2hlcyBw
b3N0ZWQpCiAgICAgICAgICAgICAgKiBsb2NraW5nL3NlcmlhbGl6YXRpb24sIGUuZy4sIGZvciBk
b21haW4gY3JlYXRpb24uIEFzIG9mCiAgICAgICAgICAgICAgICBub3csICBub3RoaW5nIGlzIHBy
b3ZpZGVkIGZvciB0aGlzIHB1cnBvc2UsIGFuZAogICAgICAgICAgICAgICAgZG93bnN0cmVhbSB0
b29sc3RhY2tzIGhhdmUgdG8gcHV0IHRoZWlyIG93biBtZWNoYW5pc21zCiAgICAgICAgICAgICAg
ICBpbiBwbGFjZS4gRS5nLiwgeGwgdXNlcyBhIGZjbnRsKCkgbG9jayBhcm91bmQgdGhlIHdob2xl
CiAgICAgICAgICAgICAgICBwcm9jZXNzIG9mIGRvbWFpbiBjcmVhdGlvbi4gSXQgc2hvdWxkIE9U
T0ggYmUgbGlieGwgam9iCiAgICAgICAgICAgICAgICB0byBvZmZlciBhIHByb3BlciBzZXQgb2Yg
aG9va3MgLS1wbGFjZWQgYXQgdGhlIHByb3BlcgogICAgICAgICAgICAgICAgc3BvdHMgZHVyaW5n
IHRoZSBkb21haW4gY3JlYXRpb24gcHJvY2Vzcy0tIGZvciB0aGUKICAgICAgICAgICAgICAgIGRv
d25zdHJlYW1zIHRvICBmaWxsIHdpdGggdGhlIHByb3BlciBjYWxsYmFja3MuIChEYXJpbwogICAg
ICAgICAgICAgICAgRmFnZ2lvbGkpCiAgICAgICAgICAgICAgKiBhZ3JlZSAmIGRvY3VtZW50IGNv
bXBhdGliaWxpdHkgZ3VhcmFudGVlcyArIGFzc29jaWF0ZWQKICAgICAgICAgICAgICAgIHRlY2hu
aWNhbCBtZWFzdXJlcyAoSWFuIEMsIHBhdGNoZXMgcG9zdGVkKQogICAgICAqIHhsIGNvbXBhdGli
aWxpdHkgd2l0aCB4bToKICAgICAgICAgICAgICAqIGZlYXR1cmUgcGFyaXR5IHdydCBkcml2ZXIg
ZG9tYWluIHN1cHBvcnQgKEdlb3JnZSBEdW5sYXApCiAgICAgICAgICAgICAgKiB4bCBzdXBwb3J0
IGZvciAicnRjX3RpbWVvZmZzZXQiIGFuZCAibG9jYWx0aW1lIiAoTGluCiAgICAgICAgICAgICAg
ICBNaW5nLCBQYXRjaGVzIHBvc3RlZCkKICAgICAgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4
bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgogICAgICAgIHRyZWUuIE5lZWRzIHJl
bGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCiAgICAgICAgcmVt
aW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAqIERvbWFpbiAwIGJsb2NrIGF0dGFjaCAmIGdl
bmVyYWwgaG90cGx1ZyB3aGVuIHVzaW5nIHFkaXNrIGJhY2tlbmQKICAgICAgICAobmVlZCB0byBz
dGFydCBxZW11IGFzIG5lY2Vzc2FyeSBldGMpIChTdGVmYW5vIFMpCiAgICAgICogZmlsZTovLyBi
YWNrZW5kIHBlcmZvcm1hbmNlLiBxZW11LXhlbi10cmFkaXRpb24ncyBxZGlzayBpcyBxdWl0ZQog
ICAgICAgIHNsb3cgJiBibGt0YXAyIG5vdCBhdmFpbGFibGUgaW4gdXBzdHJlYW0ga2VybmVscy4g
TmVlZCB0bwogICAgICAgIGNvbnNpZGVyIG91ciBvcHRpb25zOgogICAgICAgICAgICAgICogcWVt
dS14ZW4ncyBxZGlzayBpcyB0aG91Z2h0IHRvIGJlIHdlbGwgcGVyZm9ybWluZyBidXQKICAgICAg
ICAgICAgICAgIHFlbXUteGVuIGlzIG5vdCB5ZXQgdGhlIGRlZmF1bHQuIENvbXBsZXhpdHkgYXJp
c2luZyBmcm9tCiAgICAgICAgICAgICAgICBzcGxpdHRpbmcgcWVtdS1mb3ItcWRpc2sgb3V0IGZy
b20gcWVtdS1mb3ItZG0gYW5kCiAgICAgICAgICAgICAgICBydW5uaW5nIE4gcWVtdSdzLgogICAg
ICAgICAgICAgICogcG90ZW50aWFsbHkgZnVsbHkgdXNlcnNwYWNlIGJsa3RhcCBjb3VsZCBiZSBy
ZWFkeSBmb3IKICAgICAgICAgICAgICAgIDQuMgogICAgICAgICAgICAgICogdXNlIC9kZXYvbG9v
cCtibGtiYWNrLiBUaGlzIHJlcXVpcmVzIGxvb3AgZHJpdmVyIEFJTyBhbmQKICAgICAgICAgICAg
ICAgIE9fRElSRUNUIHBhdGNoZXMgd2hpY2ggYXJlIG5vdCAoQUZBSUspIHlldCB1cHN0cmVhbS4K
ICAgICAgICAgICAgICAqIExldmVyYWdlIFhDUCdzIGJsa3RhcDIgREtNUyB3b3JrLgogICAgICAg
ICAgICAgICogT3RoZXIgaWRlYXM/CiAgICAgICAgICAgICAgICAgICAgICAqIEluIGdlbmVyYWwg
d2Ugc2hvdWxkIHJlY29tbWVuZCBibGtiYWNrIChlLmcuCiAgICAgICAgICAgICAgICAgICAgICAg
IHdpdGggTFZNKSBzaW5jZSBpdCBhbHdheXMgb3V0IHBlcmZvcm1zIG90aGVyCiAgICAgICAgICAg
ICAgICAgICAgICAgIHNvbHV0aW9ucywgYWx0aG91Z2ggYXQgdGhlIGV4cGVuc2Ugb2YKICAgICAg
ICAgICAgICAgICAgICAgICAgZmxleGliaWxpdHkgcmVnYXJkaW5nIGltYWdlIGZvcm1hdHMuCiAg
ICAgICAgU3RlZmFubyBoYXMgZG9uZSBhIGxvdCBvZiB3b3JrIGhlcmUgYW5kIGhhcyBwcm9wb3Nl
ZCBzb21lCiAgICAgICAgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIGZvciBxZGlzayBpbiBib3Ro
IHFlbXUteGVuIGFuZAogICAgICAgIHFlbXUteGVuLXRyYWRpdGlvbmFsIHdoaWNoIG1ha2UgdGhl
bSBhIHBsYXVzaWJsZSBhbHRlcm5hdGl2ZSBmb3IKICAgICAgICBYZW4gNC4yLgogICAgICAqIElt
cHJvdmVkIEhvdHBsdWcgc2NyaXB0IHN1cHBvcnQgKFJvZ2VyIFBhdSBNb25uw6ksIHBhdGNoZXMK
ICAgICAgICBwb3N0ZWQpCiAgICAgICogQmxvY2sgc2NyaXB0IHN1cHBvcnQgLS0gZm9sbG93cyBv
biBmcm9tIGhvdHBsdWcgc2NyaXB0IChSb2dlcgogICAgICAgIFBhdSBNb25uw6kpCgpoeXBlcnZp
c29yLCBuaWNlIHRvIGhhdmU6CiAgICAgICogc29saWQgaW1wbGVtZW50YXRpb24gb2Ygc2hhcmlu
Zy9wYWdpbmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawogICAgICAgIHF1ZXVlcykgKFRpbSBEZWVn
YW4sIE9sYWYgSGVycmluZyBldCBhbCAtLSBwYXRjaGVzIHBvc3RlZCkKICAgICAgICAgICAgICAq
ICJUaGUgbGFzdCBwYXRjaCB0byB1c2UgYSB3YWl0cXVldWUgaW4KICAgICAgICAgICAgICAgIF9f
Z2V0X2dmbl90eXBlX2FjY2VzcygpIGZyb20gVGltIHdvcmtzLiAgSG93ZXZlciwgdGhlcmUKICAg
ICAgICAgICAgICAgIGFyZSBhIGZldyB1c2VycyB3aG8gY2FsbCBfX2dldF9nZm5fdHlwZV9hY2Nl
c3Mgd2l0aCB0aGUKICAgICAgICAgICAgICAgIGRvbWFpbl9sb2NrIGhlbGQuIFRoaXMgcGFydCBu
ZWVkcyB0byBiZSBhZGRyZXNzZWQgaW4KICAgICAgICAgICAgICAgIHNvbWUgd2F5LiIKICAgICAg
KiBTaGFyaW5nIHN1cHBvcnQgZm9yIEFNRCAoVGltLCBBbmRyZXMpLgogICAgICAqIFBvRCBwZXJm
b3JtYW5jZSBpbXByb3ZlbWVudHMgKEdlb3JnZSBEdW5sYXApCgp0b29scywgbmljZSB0byBoYXZl
OgogICAgICAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVy
cmluZywgbG90cyBvZgogICAgICAgIGRpc2N1c3Npb24gYXJvdW5kIGludGVyZmFjZSwgZ2VuZXJh
bCBjb25zZW5zdXMgcmVhY2hlZCBvbiB3aGF0CiAgICAgICAgaXQgc2hvdWxkIGxvb2sgbGlrZS4g
T2xhZiBoYXMgbGV0IG1lIGtub3cgdGhhdCBoZSBpcyBwcm9iYWJseQogICAgICAgIG5vdCBnb2lu
ZyB0byBoYXZlIHRpbWUgdG8gZG8gdGhpcyBmb3IgNC4yLCB3aWxsIGxpa2VseSBzbGlwIHRvCiAg
ICAgICAgNC4zIHVubGVzcyBzb21lb25lIGVsc2Ugd2FudCB0byBwaWNrIHVwIHRoYXQgd29yaykK
ICAgICAgKiBVcHN0cmVhbSBxZW11IGZlYXR1cmUgcGF0Y2hlczoKICAgICAgICAgICAgICAqIFVw
c3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVyYXJkLAogICAg
ICAgICAgICAgICAgcGF0Y2hlcyBzZW50KQogICAgICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBz
YXZlIHJlc3RvcmUgKEFudGhvbnkgUGVyYXJkLCBTdGVmYW5vCiAgICAgICAgICAgICAgICBTdGFi
ZWxsaW5pLCBxZW11IHBhdGNoZXMgYXBwbGllZCwgd2FpdGluZyBmb3IgbGlieGwgZXRjCiAgICAg
ICAgICAgICAgICBzaWRlIHdoaWNoIGhhcyBiZWVuIHJlY2VudGx5IHJlcG9zdGVkKQogICAgICAq
IE5lc3RlZC12aXJ0dWFsaXNhdGlvbi4gQ3VycmVudGx5ICJleHBlcmltZW50YWwiLiBMaWtlbHkg
dG8KICAgICAgICByZWxlYXNlIHRoYXQgd2F5LgogICAgICAgICAgICAgICogTmVzdGVkIFNWTS4g
VGVzdGVkIGluIGEgdmFyaWV0eSBvZiBjb25maWd1cmF0aW9ucyBidXQKICAgICAgICAgICAgICAg
IHN0aWxsIHNvbWUgaXNzdWVzIHdpdGggdGhlIG1vc3QgaW1wb3J0YW50IHVzZSBjYXNlICh3Nwog
ICAgICAgICAgICAgICAgWFAgbW9kZSkgWzBdICAoQ2hyaXN0b3BoIEVnZ2VyKQogICAgICAgICAg
ICAgICogTmVzdGVkIFZNWC4gTmVlZHMgbmVzdGVkIEVQVCB0byBiZSBnZW51aW5lbHkgdXNlZnVs
LgogICAgICAgICAgICAgICAgTmVlZCBtb3JlIGRhdGEgb24gdGVzdGVkbmVzcyBldGMgKEludGVs
KQogICAgICAqIEluaXRpYWwgeGwgc3VwcG9ydCBmb3IgUmVtdXMgKG1lbW9yeSBjaGVja3BvaW50
LCBibGFja2hvbGluZykKICAgICAgICAoU2hyaXJhbSwgcGF0Y2hlcyByZXBvc3RlZCByZWNlbnRs
eSwgd2FzIGJsb2NrZWQgYmVoaW5kIHFlbXUKICAgICAgICBzYXZlIHJlc3RvcmUgcGF0Y2hlcyB3
aGljaCBhcmUgbm93IGluKQogICAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKICAgICAg
ICAgICAgICAqIHhsIHN1cHBvcnQgZm9yIGF1dG9zcGF3bmluZyB2bmN2aWV3ZXIgKHZuY3ZpZXdl
cj0xIG9yCiAgICAgICAgICAgICAgICBvdGhlcndpc2UpIChHb25jYWxvIEdvbWVzLCBwYXRjaGVz
IHBvc3RlZCkKICAgICAgICAgICAgICAqIHN1cHBvcnQgZm9yIHZpZiAicmF0ZSIgcGFyYW1ldGVy
IChNYXRoaWV1IEdhZ27DqSwgcGF0Y2hlcwogICAgICAgICAgICAgICAgcG9zdGVkKQogICAgICAg
ICAgICAgICogZXhwb3NlIFBDSSBiYWNrICJwZXJtaXNzaXZlIiBwYXJhbWV0ZXIgKEdlb3JnZSBE
dW5sYXApCgpbMF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwv
MjAxMi0wMy9tc2cwMDg4My5odG1sCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:28:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeUT-0006Du-HY; Mon, 02 Apr 2012 10:28:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1SEeUR-0006Dd-EI
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:27:59 +0000
Received: from [193.109.254.147:42941] by server-7.bemta-14.messagelabs.com id
	00/1C-01627-E2F797F4; Mon, 02 Apr 2012 10:27:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333362476!3011382!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3933 invoked from network); 2 Apr 2012 10:27:57 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:27:57 -0000
Received: by ggnp2 with SMTP id p2so1197924ggn.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 03:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=ARLM5nBXflsRVfMBiDXxByS70L5ejb002op8DQeW54s=;
	b=m6ttmt2/dtdwHXHdZ38CnsaPLzLd0SiGGkxsu8jGJTcbRCGcYvxfLWseMIFvodiOxh
	eN2zRpmibXU3GZKX4L9pqfuWMX9WjiArCRH10afMHNBdEtLJdGDNQNGmIKUN6Nt03pJg
	X3euqholHEZBLvXvUs6qY3c+vt4cx14aWpl0jnKQoJcB+I4gt3aKltszGsq+ozsJLl+p
	xKQejLpVzFPzhubWCy3roJn/Xx3PdrE4j+I/ydq/eCJr2w8aarexVVYOUR/OTvjWxNQH
	ti9UbMmp5zu+4PF6NiW5IkOFIVV4hIjYwWr2KjkJC0uVUbEBcGfoFwJNmL9XlxsNvRc5
	fuNQ==
Received: by 10.236.136.4 with SMTP id v4mr6293278yhi.44.1333362476336;
	Mon, 02 Apr 2012 03:27:56 -0700 (PDT)
Received: from Roger.local.com (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id u15sm19505946anb.9.2012.04.02.03.27.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 02 Apr 2012 03:27:55 -0700 (PDT)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Date: Mon,  2 Apr 2012 11:27:46 +0100
Message-Id: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on old
	python versions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Replaced the use of python-config (that is only present in Python >= 2.5.x)
with the distutils python module.

Please run ./autogen.sh after applying the patch.

Again, this has only been tested on OS X Python 2.7.

Changes since v2:

 * Added SYSLIBS to library test.

Changes since v1:

 * Added Python LDFLAGS to library test.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: Zhang, Yang Z <yang.z.zhang@intel.com>
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/m4/python_devel.m4 |   38 +++++++++++++++++++-------------------
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4
index 3bcca7b..8bfcd0c 100644
--- a/tools/m4/python_devel.m4
+++ b/tools/m4/python_devel.m4
@@ -1,27 +1,27 @@
 AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
+ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("VERSION")'`
 ac_previous_cppflags=$CPPFLAGS
-CPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
+CPPFLAGS="$CFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
+CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("CFLAGS")'`"
 ac_previous_ldflags=$LDFLAGS
-for flag in `$PYTHON-config --ldflags`
-do
-    case $flag in
-    -L*)
-        LDFLAGS="$LDLFAGS $flag"
-        ;;
-    -lpython*)
-        python_lib=`echo $flag | sed 's/^-l//'`
-        ;;
-    -l*)
-        # Ignore other libraries, we are only interested in testing python-dev
-        ;;
-    *)
-        AC_MSG_WARN([Strange ldflag found in $PYTHON-config output: $flag])
-        ;;
-    esac
-done
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("LIBS")'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("SYSLIBS")'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
+    standard_lib=1) + "/config"'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("LINKFORSHARED")'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("LDFLAGS")'`"
+
 AC_CHECK_HEADER([Python.h], [],
     [AC_MSG_ERROR([Unable to find Python development headers])],)
-AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
+AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
     [AC_MSG_ERROR([Unable to find a suitable python development library])])
 CPPFLAGS=$ac_previous_cppflags
 LDLFAGS=$ac_previous_ldflags
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:28:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeUT-0006Du-HY; Mon, 02 Apr 2012 10:28:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1SEeUR-0006Dd-EI
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:27:59 +0000
Received: from [193.109.254.147:42941] by server-7.bemta-14.messagelabs.com id
	00/1C-01627-E2F797F4; Mon, 02 Apr 2012 10:27:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333362476!3011382!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3933 invoked from network); 2 Apr 2012 10:27:57 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:27:57 -0000
Received: by ggnp2 with SMTP id p2so1197924ggn.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 03:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=ARLM5nBXflsRVfMBiDXxByS70L5ejb002op8DQeW54s=;
	b=m6ttmt2/dtdwHXHdZ38CnsaPLzLd0SiGGkxsu8jGJTcbRCGcYvxfLWseMIFvodiOxh
	eN2zRpmibXU3GZKX4L9pqfuWMX9WjiArCRH10afMHNBdEtLJdGDNQNGmIKUN6Nt03pJg
	X3euqholHEZBLvXvUs6qY3c+vt4cx14aWpl0jnKQoJcB+I4gt3aKltszGsq+ozsJLl+p
	xKQejLpVzFPzhubWCy3roJn/Xx3PdrE4j+I/ydq/eCJr2w8aarexVVYOUR/OTvjWxNQH
	ti9UbMmp5zu+4PF6NiW5IkOFIVV4hIjYwWr2KjkJC0uVUbEBcGfoFwJNmL9XlxsNvRc5
	fuNQ==
Received: by 10.236.136.4 with SMTP id v4mr6293278yhi.44.1333362476336;
	Mon, 02 Apr 2012 03:27:56 -0700 (PDT)
Received: from Roger.local.com (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id u15sm19505946anb.9.2012.04.02.03.27.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 02 Apr 2012 03:27:55 -0700 (PDT)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Date: Mon,  2 Apr 2012 11:27:46 +0100
Message-Id: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on old
	python versions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Replaced the use of python-config (that is only present in Python >= 2.5.x)
with the distutils python module.

Please run ./autogen.sh after applying the patch.

Again, this has only been tested on OS X Python 2.7.

Changes since v2:

 * Added SYSLIBS to library test.

Changes since v1:

 * Added Python LDFLAGS to library test.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: Zhang, Yang Z <yang.z.zhang@intel.com>
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/m4/python_devel.m4 |   38 +++++++++++++++++++-------------------
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4
index 3bcca7b..8bfcd0c 100644
--- a/tools/m4/python_devel.m4
+++ b/tools/m4/python_devel.m4
@@ -1,27 +1,27 @@
 AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
+ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("VERSION")'`
 ac_previous_cppflags=$CPPFLAGS
-CPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
+CPPFLAGS="$CFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
+CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("CFLAGS")'`"
 ac_previous_ldflags=$LDFLAGS
-for flag in `$PYTHON-config --ldflags`
-do
-    case $flag in
-    -L*)
-        LDFLAGS="$LDLFAGS $flag"
-        ;;
-    -lpython*)
-        python_lib=`echo $flag | sed 's/^-l//'`
-        ;;
-    -l*)
-        # Ignore other libraries, we are only interested in testing python-dev
-        ;;
-    *)
-        AC_MSG_WARN([Strange ldflag found in $PYTHON-config output: $flag])
-        ;;
-    esac
-done
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("LIBS")'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("SYSLIBS")'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
+    standard_lib=1) + "/config"'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("LINKFORSHARED")'`"
+LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("LDFLAGS")'`"
+
 AC_CHECK_HEADER([Python.h], [],
     [AC_MSG_ERROR([Unable to find Python development headers])],)
-AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
+AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
     [AC_MSG_ERROR([Unable to find a suitable python development library])])
 CPPFLAGS=$ac_previous_cppflags
 LDLFAGS=$ac_previous_ldflags
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:33:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeZ0-0006Zv-7e; Mon, 02 Apr 2012 10:32:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeYz-0006Zp-6R
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:32:41 +0000
Received: from [85.158.138.51:10423] by server-1.bemta-3.messagelabs.com id
	D0/44-04539-840897F4; Mon, 02 Apr 2012 10:32:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333362758!20341216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16155 invoked from network); 2 Apr 2012 10:32:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:32:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188619026"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:32:38 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	06:32:37 -0400
Message-ID: <4F798044.6050704@citrix.com>
Date: Mon, 2 Apr 2012 11:32:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>	
	<1332443876-28506-3-git-send-email-david.vrabel@citrix.com>	
	<1333123166.15932.113.camel@zakaz.uk.xensource.com>	
	<4F796F7C.4070400@citrix.com>
	<1333359046.25602.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333359046.25602.21.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 10:30, Ian Campbell wrote:
> On Mon, 2012-04-02 at 10:21 +0100, David Vrabel wrote:
>> On 30/03/12 16:59, Ian Campbell wrote:
>>> On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>
>>>> Build a flat device tree for dom0 based on the one supplied to Xen.
>>>> The following changes are made:
>>>>
>>>>   * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
>>>>     bootargs.
>>>>
>>>>   * In all memory nodes, the reg parameters are adjusted to reflect
>>>>     the amount of memory dom0 can use.  The p2m is updated using this
>>>>     info.
>>>>
>>>> Support for passing ATAGS to dom0 is removed.
>>>>
>>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>>> ---
>>>>  xen/arch/arm/domain_build.c         |  257 +++++++++++++++++++++++++++++------
>>>>  xen/arch/arm/kernel.c               |    2 +-
>>>>  xen/arch/arm/kernel.h               |    8 +-
>>>>  xen/common/device_tree.c            |   47 ++++--
>>>>  xen/include/xen/device_tree.h       |    8 +
>>>>  xen/include/xen/libfdt/libfdt_env.h |    3 +
>>>>  6 files changed, 265 insertions(+), 60 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>> index 15632f7..b4c0452 100644
>>>> --- a/xen/arch/arm/domain_build.c
>>>> +++ b/xen/arch/arm/domain_build.c
>>>> @@ -6,6 +6,10 @@
>>>>  #include <xen/sched.h>
>>>>  #include <asm/irq.h>
>>>>  #include <asm/regs.h>
>>>> +#include <xen/errno.h>
>>>> +#include <xen/device_tree.h>
>>>> +#include <xen/libfdt/libfdt.h>
>>>> +#include <xen/guest_access.h>
>>>>
>>>>  #include "gic.h"
>>>>  #include "kernel.h"
>>>> @@ -13,6 +17,13 @@
>>>>  static unsigned int __initdata opt_dom0_max_vcpus;
>>>>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>>>>
>>>> +/*
>>>> + * Amount of extra space required to dom0's device tree.  No new nodes
>>>> + * are added (yet) but one terminating reserve map entry (16 bytes) is
>>>> + * added.
>>>> + */
>>>> +#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
>>>> +
>>>>  struct vcpu *__init alloc_dom0_vcpu0(void)
>>>>  {
>>>>      if ( opt_dom0_max_vcpus == 0 )
>>>> @@ -28,43 +39,210 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
>>>>      return alloc_vcpu(dom0, 0, 0);
>>>>  }
>>>>
>>>> -extern void guest_mode_entry(void);
>>>> +static void set_memory_reg(struct domain *d, struct kernel_info *kinfo,
>>>> +                           const void *fdt,
>>>> +                           const u32 *cell, int address_cells, int size_cells,
>>>> +                           u32 *new_cell, int *len)
>>>> +{
>>>> +    int reg_size = (address_cells + size_cells) * sizeof(*cell);
>>>> +    int l;
>>>> +    u64 start;
>>>> +    u64 size;
>>>> +
>>>> +    l = *len;
>>>
>>>> +
>>>> +    while ( kinfo->unassigned_mem > 0 && l >= reg_size
>>>> +            && kinfo->mem.nr_banks < NR_MEM_BANKS )
>>>> +    {
>>>> +        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
>>>> +        if ( size > kinfo->unassigned_mem )
>>>> +            size = kinfo->unassigned_mem;
>>>> +
>>>> +        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
>>>
>>> This assumes/requires that address_cells and size_cells a 1, right? If
>>> they end up being 2 or more then device_tree_get_reg will trample on the
>>> stack via &start and &size.
>>
>> No.  address_cells and size_cells can be 1 or 2.
> 
> Where is that checked or enforced? What happens if someone feeds us a
> DTB with 3? Or are you saying that this isn't possible (perhaps due to
> some constraint in DTB itself)?

I just tested with #address-cells == 3 and it works fine.

We trust the DTB is a valid description of the hardware so assume that
all addresses are below 2^64.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:33:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeZ0-0006Zv-7e; Mon, 02 Apr 2012 10:32:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeYz-0006Zp-6R
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:32:41 +0000
Received: from [85.158.138.51:10423] by server-1.bemta-3.messagelabs.com id
	D0/44-04539-840897F4; Mon, 02 Apr 2012 10:32:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333362758!20341216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16155 invoked from network); 2 Apr 2012 10:32:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:32:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188619026"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:32:38 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	06:32:37 -0400
Message-ID: <4F798044.6050704@citrix.com>
Date: Mon, 2 Apr 2012 11:32:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1332443876-28506-1-git-send-email-david.vrabel@citrix.com>	
	<1332443876-28506-3-git-send-email-david.vrabel@citrix.com>	
	<1333123166.15932.113.camel@zakaz.uk.xensource.com>	
	<4F796F7C.4070400@citrix.com>
	<1333359046.25602.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333359046.25602.21.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 10:30, Ian Campbell wrote:
> On Mon, 2012-04-02 at 10:21 +0100, David Vrabel wrote:
>> On 30/03/12 16:59, Ian Campbell wrote:
>>> On Thu, 2012-03-22 at 19:17 +0000, David Vrabel wrote:
>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>
>>>> Build a flat device tree for dom0 based on the one supplied to Xen.
>>>> The following changes are made:
>>>>
>>>>   * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
>>>>     bootargs.
>>>>
>>>>   * In all memory nodes, the reg parameters are adjusted to reflect
>>>>     the amount of memory dom0 can use.  The p2m is updated using this
>>>>     info.
>>>>
>>>> Support for passing ATAGS to dom0 is removed.
>>>>
>>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>>> ---
>>>>  xen/arch/arm/domain_build.c         |  257 +++++++++++++++++++++++++++++------
>>>>  xen/arch/arm/kernel.c               |    2 +-
>>>>  xen/arch/arm/kernel.h               |    8 +-
>>>>  xen/common/device_tree.c            |   47 ++++--
>>>>  xen/include/xen/device_tree.h       |    8 +
>>>>  xen/include/xen/libfdt/libfdt_env.h |    3 +
>>>>  6 files changed, 265 insertions(+), 60 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>> index 15632f7..b4c0452 100644
>>>> --- a/xen/arch/arm/domain_build.c
>>>> +++ b/xen/arch/arm/domain_build.c
>>>> @@ -6,6 +6,10 @@
>>>>  #include <xen/sched.h>
>>>>  #include <asm/irq.h>
>>>>  #include <asm/regs.h>
>>>> +#include <xen/errno.h>
>>>> +#include <xen/device_tree.h>
>>>> +#include <xen/libfdt/libfdt.h>
>>>> +#include <xen/guest_access.h>
>>>>
>>>>  #include "gic.h"
>>>>  #include "kernel.h"
>>>> @@ -13,6 +17,13 @@
>>>>  static unsigned int __initdata opt_dom0_max_vcpus;
>>>>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>>>>
>>>> +/*
>>>> + * Amount of extra space required to dom0's device tree.  No new nodes
>>>> + * are added (yet) but one terminating reserve map entry (16 bytes) is
>>>> + * added.
>>>> + */
>>>> +#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
>>>> +
>>>>  struct vcpu *__init alloc_dom0_vcpu0(void)
>>>>  {
>>>>      if ( opt_dom0_max_vcpus == 0 )
>>>> @@ -28,43 +39,210 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
>>>>      return alloc_vcpu(dom0, 0, 0);
>>>>  }
>>>>
>>>> -extern void guest_mode_entry(void);
>>>> +static void set_memory_reg(struct domain *d, struct kernel_info *kinfo,
>>>> +                           const void *fdt,
>>>> +                           const u32 *cell, int address_cells, int size_cells,
>>>> +                           u32 *new_cell, int *len)
>>>> +{
>>>> +    int reg_size = (address_cells + size_cells) * sizeof(*cell);
>>>> +    int l;
>>>> +    u64 start;
>>>> +    u64 size;
>>>> +
>>>> +    l = *len;
>>>
>>>> +
>>>> +    while ( kinfo->unassigned_mem > 0 && l >= reg_size
>>>> +            && kinfo->mem.nr_banks < NR_MEM_BANKS )
>>>> +    {
>>>> +        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
>>>> +        if ( size > kinfo->unassigned_mem )
>>>> +            size = kinfo->unassigned_mem;
>>>> +
>>>> +        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
>>>
>>> This assumes/requires that address_cells and size_cells a 1, right? If
>>> they end up being 2 or more then device_tree_get_reg will trample on the
>>> stack via &start and &size.
>>
>> No.  address_cells and size_cells can be 1 or 2.
> 
> Where is that checked or enforced? What happens if someone feeds us a
> DTB with 3? Or are you saying that this isn't possible (perhaps due to
> some constraint in DTB itself)?

I just tested with #address-cells == 3 and it works fine.

We trust the DTB is a valid description of the hardware so assume that
all addresses are below 2^64.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:39:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEefd-0006lY-36; Mon, 02 Apr 2012 10:39:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEefb-0006lT-T8
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:39:32 +0000
Received: from [193.109.254.147:46114] by server-4.bemta-14.messagelabs.com id
	3B/67-11570-3E1897F4; Mon, 02 Apr 2012 10:39:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333363169!3022113!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18203 invoked from network); 2 Apr 2012 10:39:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188619529"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:39:28 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	06:39:28 -0400
Message-ID: <4F7981DE.1030004@citrix.com>
Date: Mon, 2 Apr 2012 11:39:26 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 11:26, Ian Campbell wrote:
> 
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.

How does this affect ARM patches?  Are they similarly restricted?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:39:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEefd-0006lY-36; Mon, 02 Apr 2012 10:39:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEefb-0006lT-T8
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:39:32 +0000
Received: from [193.109.254.147:46114] by server-4.bemta-14.messagelabs.com id
	3B/67-11570-3E1897F4; Mon, 02 Apr 2012 10:39:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333363169!3022113!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18203 invoked from network); 2 Apr 2012 10:39:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188619529"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:39:28 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	06:39:28 -0400
Message-ID: <4F7981DE.1030004@citrix.com>
Date: Mon, 2 Apr 2012 11:39:26 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 11:26, Ian Campbell wrote:
> 
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.

How does this affect ARM patches?  Are they similarly restricted?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:44:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEejd-0006w2-U3; Mon, 02 Apr 2012 10:43:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEejc-0006vw-La
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:43:40 +0000
Received: from [85.158.143.35:6309] by server-2.bemta-4.messagelabs.com id
	CC/7C-17550-BD2897F4; Mon, 02 Apr 2012 10:43:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333363418!7196076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24761 invoked from network); 2 Apr 2012 10:43:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:43:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11718571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:43:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	11:43:38 +0100
Message-ID: <1333363416.25602.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 11:43:36 +0100
In-Reply-To: <4F7981DE.1030004@citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<4F7981DE.1030004@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:39 +0100, David Vrabel wrote:
> On 02/04/12 11:26, Ian Campbell wrote:
> > 
> > We have now entered Feature Freeze. Patches which have been posted
> > before or which address something on the list below are still acceptable
> > (for now, we will gradually be getting stricter about this), everything
> > else will be deferred until 4.3 by default.
> 
> How does this affect ARM patches?  Are they similarly restricted?

Given that ARM support in 4.2 is going to be experimental in nature I
suggest that, at least for the time being, ARM patches which do not have
an impact on generic or non-ARM code continue to be accepted.

Any objections?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:44:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEejd-0006w2-U3; Mon, 02 Apr 2012 10:43:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEejc-0006vw-La
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 10:43:40 +0000
Received: from [85.158.143.35:6309] by server-2.bemta-4.messagelabs.com id
	CC/7C-17550-BD2897F4; Mon, 02 Apr 2012 10:43:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333363418!7196076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24761 invoked from network); 2 Apr 2012 10:43:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:43:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11718571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:43:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	11:43:38 +0100
Message-ID: <1333363416.25602.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 11:43:36 +0100
In-Reply-To: <4F7981DE.1030004@citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<4F7981DE.1030004@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:39 +0100, David Vrabel wrote:
> On 02/04/12 11:26, Ian Campbell wrote:
> > 
> > We have now entered Feature Freeze. Patches which have been posted
> > before or which address something on the list below are still acceptable
> > (for now, we will gradually be getting stricter about this), everything
> > else will be deferred until 4.3 by default.
> 
> How does this affect ARM patches?  Are they similarly restricted?

Given that ARM support in 4.2 is going to be experimental in nature I
suggest that, at least for the time being, ARM patches which do not have
an impact on generic or non-ARM code continue to be accepted.

Any objections?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqf-00076d-Hw; Mon, 02 Apr 2012 10:50:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeqd-000768-Li
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:55 +0000
Received: from [85.158.139.83:32927] by server-8.bemta-5.messagelabs.com id
	CA/57-26964-E84897F4; Mon, 02 Apr 2012 10:50:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333363853!22065585!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22872 invoked from network); 2 Apr 2012 10:50:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775127"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-89;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:32 +0100
Message-ID: <1333363834-2520-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] arm: use bootargs for the command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Use the /chosen node's bootargs parameter for the Xen command line.
Parse it early on before the serial console is setup.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c          |    2 ++
 xen/common/device_tree.c      |   20 ++++++++++++++++++++
 xen/include/xen/device_tree.h |    1 +
 3 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 551c149..7dad2c0 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -152,6 +152,8 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+    cmdline_parse(device_tree_bootargs(fdt));
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 715fbf6..8fb6d46 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -118,6 +118,26 @@ int device_tree_for_each_node(const void *fdt,
     return 0;
 }
 
+/**
+ * device_tree_bootargs - return the bootargs (the Xen command line)
+ * @fdt flat device tree.
+ */
+const char *device_tree_bootargs(const void *fdt)
+{
+    int node; 
+    const struct fdt_property *prop;
+
+    node = fdt_path_offset(fdt, "/chosen");
+    if ( node < 0 )
+        return NULL;
+
+    prop = fdt_get_property(fdt, node, "bootargs", NULL);
+    if ( prop == NULL )
+        return NULL;
+
+    return prop->data;
+}
+
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 510b5b4..8e1626c 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -49,6 +49,7 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
+const char *device_tree_bootargs(const void *fdt);
 void device_tree_dump(const void *fdt);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqf-00076d-Hw; Mon, 02 Apr 2012 10:50:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeqd-000768-Li
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:55 +0000
Received: from [85.158.139.83:32927] by server-8.bemta-5.messagelabs.com id
	CA/57-26964-E84897F4; Mon, 02 Apr 2012 10:50:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333363853!22065585!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22872 invoked from network); 2 Apr 2012 10:50:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775127"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-89;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:32 +0100
Message-ID: <1333363834-2520-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] arm: use bootargs for the command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Use the /chosen node's bootargs parameter for the Xen command line.
Parse it early on before the serial console is setup.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c          |    2 ++
 xen/common/device_tree.c      |   20 ++++++++++++++++++++
 xen/include/xen/device_tree.h |    1 +
 3 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 551c149..7dad2c0 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -152,6 +152,8 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+    cmdline_parse(device_tree_bootargs(fdt));
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 715fbf6..8fb6d46 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -118,6 +118,26 @@ int device_tree_for_each_node(const void *fdt,
     return 0;
 }
 
+/**
+ * device_tree_bootargs - return the bootargs (the Xen command line)
+ * @fdt flat device tree.
+ */
+const char *device_tree_bootargs(const void *fdt)
+{
+    int node; 
+    const struct fdt_property *prop;
+
+    node = fdt_path_offset(fdt, "/chosen");
+    if ( node < 0 )
+        return NULL;
+
+    prop = fdt_get_property(fdt, node, "bootargs", NULL);
+    if ( prop == NULL )
+        return NULL;
+
+    return prop->data;
+}
+
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 510b5b4..8e1626c 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -49,6 +49,7 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
+const char *device_tree_bootargs(const void *fdt);
 void device_tree_dump(const void *fdt);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqd-00076H-Qg; Mon, 02 Apr 2012 10:50:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEeqd-000766-24
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:55 +0000
Received: from [85.158.143.35:53120] by server-3.bemta-4.messagelabs.com id
	F5/30-05853-E84897F4; Mon, 02 Apr 2012 10:50:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333363851!11386292!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 2 Apr 2012 10:50:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775124"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:50 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SEeqY-0000P6-3T;
	Mon, 02 Apr 2012 11:50:50 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333363655@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 2 Apr 2012 11:47:35 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series adds the "permissive" option for passed-through devices
which access config space out of the "known good" PCI config space.

v2:
- Added patch to move bdf parsing to libxlu
- Addressed some formatting comments

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqd-00076H-Qg; Mon, 02 Apr 2012 10:50:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEeqd-000766-24
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:55 +0000
Received: from [85.158.143.35:53120] by server-3.bemta-4.messagelabs.com id
	F5/30-05853-E84897F4; Mon, 02 Apr 2012 10:50:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333363851!11386292!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 2 Apr 2012 10:50:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775124"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:50 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SEeqY-0000P6-3T;
	Mon, 02 Apr 2012 11:50:50 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333363655@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 2 Apr 2012 11:47:35 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series adds the "permissive" option for passed-through devices
which access config space out of the "known good" PCI config space.

v2:
- Added patch to move bdf parsing to libxlu
- Addressed some formatting comments

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqg-00076x-Ta; Mon, 02 Apr 2012 10:50:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeqf-00076U-Bm
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:57 +0000
Received: from [85.158.143.35:53354] by server-2.bemta-4.messagelabs.com id
	7E/18-17550-094897F4; Mon, 02 Apr 2012 10:50:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333363851!11386292!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6437 invoked from network); 2 Apr 2012 10:50:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775128"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-7V;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:31 +0100
Message-ID: <1333363834-2520-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Build a flat device tree for dom0 based on the one supplied to Xen.
The following changes are made:

  * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
    bootargs.

  * In all memory nodes, the reg parameters are adjusted to reflect
    the amount of memory dom0 can use.  The p2m is updated using this
    info.

Support for passing ATAGS to dom0 is removed.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c         |  254 +++++++++++++++++++++++++++++------
 xen/arch/arm/kernel.c               |    2 +-
 xen/arch/arm/kernel.h               |    8 +-
 xen/common/device_tree.c            |   47 +++++---
 xen/include/xen/device_tree.h       |    8 +
 xen/include/xen/libfdt/libfdt_env.h |    3 +
 6 files changed, 262 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 15632f7..5e15476 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -6,6 +6,10 @@
 #include <xen/sched.h>
 #include <asm/irq.h>
 #include <asm/regs.h>
+#include <xen/errno.h>
+#include <xen/device_tree.h>
+#include <xen/libfdt/libfdt.h>
+#include <xen/guest_access.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -13,6 +17,13 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+/*
+ * Amount of extra space required to dom0's device tree.  No new nodes
+ * are added (yet) but one terminating reserve map entry (16 bytes) is
+ * added.
+ */
+#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
+
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
     if ( opt_dom0_max_vcpus == 0 )
@@ -28,43 +39,207 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
     return alloc_vcpu(dom0, 0, 0);
 }
 
-extern void guest_mode_entry(void);
+static int set_memory_reg(struct domain *d, struct kernel_info *kinfo,
+                          const void *fdt, const u32 *cell, int len,
+                          int address_cells, int size_cells, u32 *new_cell)
+{
+    int reg_size = (address_cells + size_cells) * sizeof(*cell);
+    int l = 0;
+    u64 start;
+    u64 size;
+
+    while ( kinfo->unassigned_mem > 0 && l + reg_size <= len
+            && kinfo->mem.nr_banks < NR_MEM_BANKS )
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+        if ( size > kinfo->unassigned_mem )
+            size = kinfo->unassigned_mem;
+        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
+
+        printk("Populate P2M %#llx->%#llx\n", start, start + size);
+        p2m_populate_ram(d, start, start + size);
+        kinfo->mem.bank[kinfo->mem.nr_banks].start = start;
+        kinfo->mem.bank[kinfo->mem.nr_banks].size = size;
+        kinfo->mem.nr_banks++;
+        kinfo->unassigned_mem -= size;
+
+        l += reg_size;
+    }
+
+    return l;
+}
+
+static int write_properties(struct domain *d, struct kernel_info *kinfo,
+                            const void *fdt,
+                            int node, const char *name, int depth,
+                            u32 address_cells, u32 size_cells)
+{
+    int prop;
+
+    for ( prop = fdt_first_property_offset(fdt, node);
+          prop >= 0;
+          prop = fdt_next_property_offset(fdt, prop) )
+    {
+        const struct fdt_property *p;
+        const char *prop_name;
+        const char *prop_data;
+        int prop_len;
+        char *new_data = NULL;
+
+        p = fdt_get_property_by_offset(fdt, prop, NULL);
+        prop_name = fdt_string(fdt, fdt32_to_cpu(p->nameoff));
+        prop_data = p->data;
+        prop_len  = fdt32_to_cpu(p->len);
+
+        /*
+         * In chosen node: replace bootargs with value from
+         * xen,dom0-bootargs.
+         */
+        if ( device_tree_node_matches(fdt, node, "chosen") )
+        {
+            if ( strcmp(prop_name, "bootargs") == 0 )
+                continue;
+            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
+                prop_name = "bootargs";
+        }
+        /*
+         * In a memory node: adjust reg property.
+         */
+        else if ( device_tree_node_matches(fdt, node, "memory") )
+        {
+            if ( strcmp(prop_name, "reg") == 0 )
+            {
+                new_data = xzalloc_bytes(prop_len);
+                if ( new_data  == NULL )
+                    return -FDT_ERR_XEN(ENOMEM);
+
+                prop_len = set_memory_reg(d, kinfo, fdt,
+                                          (u32 *)prop_data, prop_len,
+                                          address_cells, size_cells,
+                                          (u32 *)new_data);
+                prop_data = new_data;
+            }
+        }
+
+        /*
+         * TODO: Should call map_mmio_regions() for all devices in the
+         * tree that have a "reg" parameter (except cpus).  This
+         * requires looking into the parent node's "ranges" property
+         * to translate the bus address in the "reg" value into
+         * physical addresses.  Regions also need to be rounded up to
+         * whole pages.
+         */
+
+        fdt_property(kinfo->fdt, prop_name, prop_data, prop_len);
+
+        xfree(new_data);
+    }
+
+    if ( prop == -FDT_ERR_NOTFOUND )
+        return 0;
+    return prop;
+}
 
-static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+static int write_nodes(struct domain *d, struct kernel_info *kinfo,
+                       const void *fdt)
 {
-    paddr_t ma = gvirt_to_maddr(tags);
-    void *map = map_domain_page(ma>>PAGE_SHIFT);
-    void *p = map + (tags & (PAGE_SIZE - 1));
-    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+    int node;
+    int depth = 0, last_depth = -1;
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
+    int ret;
+
+    for ( node = 0, depth = 0;
+          node >= 0 && depth >= 0;
+          node = fdt_next_node(fdt, node, &depth) )
+    {
+        const char *name;
+
+        name = fdt_get_name(fdt, node, NULL);
 
-    /* not enough room on this page for all the tags */
-    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
+        {
+            printk("warning: node `%s' is nested too deep\n", name);
+            continue;
+        }
 
-#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+        while ( last_depth-- >= depth )
+            fdt_end_node(kinfo->fdt);
 
-    /* ATAG_CORE */
-    TAG(uint32_t, 2);
-    TAG(uint32_t, 0x54410001);
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
-    /* ATAG_MEM */
-    TAG(uint32_t, 4);
-    TAG(uint32_t, 0x54410002);
-    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
-    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+        fdt_begin_node(kinfo->fdt, name);
 
-    /* ATAG_CMDLINE */
-    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
-    TAG(uint32_t, 0x54410009);
-    memcpy(p, cmdline, strlen(cmdline) + 1);
-    p += ((strlen(cmdline) + 4) >> 2) << 2;
+        ret = write_properties(d, kinfo, fdt, node, name, depth,
+                               address_cells[depth-1], size_cells[depth-1]);
+        if ( ret < 0 )
+            return ret;
 
-    /* ATAG_NONE */
-    TAG(uint32_t, 0);
-    TAG(uint32_t, 0);
+        last_depth = depth;
+    }
 
-#undef TAG
+    while ( last_depth-- >= 0 )
+        fdt_end_node(kinfo->fdt);
 
-    unmap_domain_page(map);
+    return 0;
+}
+
+static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
+{
+    void *fdt;
+    int new_size;
+    int ret;
+
+    fdt = device_tree_flattened;
+
+    new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
+    kinfo->fdt = xmalloc_bytes(new_size);
+    if ( kinfo->fdt == NULL )
+        return -ENOMEM;
+
+    ret = fdt_create(kinfo->fdt, new_size);
+    if ( ret < 0 )
+        goto err;
+
+    fdt_finish_reservemap(kinfo->fdt);
+
+    ret = write_nodes(d, kinfo, fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    device_tree_dump(kinfo->fdt);
+
+    /*
+     * Put the device tree at the beginning of the first bank.  It
+     * must be below 4 GiB.
+     */
+    kinfo->dtb_paddr = kinfo->mem.bank[0].start + 0x100;
+    if ( kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt) > (1ull << 32) )
+    {
+        printk("Not enough memory below 4 GiB for the device tree.");
+        ret = -FDT_ERR_XEN(EINVAL);
+        goto err;
+    }
+
+    return 0;
+
+  err:
+    printk("Device tree generation failed (%d).\n", ret);
+    xfree(kinfo->fdt);
+    return -EINVAL;
+}
+
+static void dtb_load(struct kernel_info *kinfo)
+{
+    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
+
+    raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
+    xfree(kinfo->fdt);
 }
 
 int construct_dom0(struct domain *d)
@@ -82,22 +257,20 @@ int construct_dom0(struct domain *d)
 
     printk("*** LOADING DOMAIN 0 ***\n");
 
-    /* 128M at 2G physical */
-    /* TODO size and location from DT. */
-    kinfo.ram_start = 0x80000000;
-    kinfo.ram_end   = 0x88000000;
+    d->max_pages = ~0U;
 
-    rc = kernel_prepare(&kinfo);
-    if (rc < 0)
+    if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    d->max_pages = ~0U;
+    kinfo.unassigned_mem = 0x08000000; /* XXX */
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
+    rc = prepare_dtb(d, &kinfo);
+    if ( rc < 0 )
         return rc;
 
-    printk("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
-    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
+    rc = kernel_prepare(&kinfo);
+    if ( rc < 0 )
+        return rc;
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -125,13 +298,12 @@ int construct_dom0(struct domain *d)
     /* Enable second stage translation */
     WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
 
-    /* The following load uses domain's p2m */
+    /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
 
+    dtb_load(&kinfo);
     kernel_load(&kinfo);
 
-    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
-
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
@@ -153,7 +325,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
+    regs->r2 = kinfo.dtb_paddr;
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index dd757e5..130d488 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -121,7 +121,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
      * at 32k from start of RAM.
      */
     if (start == 0)
-        info->zimage.load_addr = info->ram_start + 0x8000;
+        info->zimage.load_addr = info->mem.bank[0].start + 0x8000;
     else
         info->zimage.load_addr = start;
     info->zimage.len = end - start;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 5caebe5..4533568 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -7,11 +7,15 @@
 #define __ARCH_ARM_KERNEL_H__
 
 #include <xen/libelf.h>
+#include <xen/device_tree.h>
 
 struct kernel_info {
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct dt_mem_info mem;
+
+    paddr_t dtb_paddr;
     paddr_t entry;
-    paddr_t ram_start;
-    paddr_t ram_end;
 
     void *kernel_img;
     unsigned kernel_order;
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index d4b1556..715fbf6 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -23,7 +23,7 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
-static bool_t __init node_matches(const void *fdt, int node, const char *match)
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
 {
     const char *name;
     size_t match_len;
@@ -48,16 +48,33 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
     }
 }
 
-static void __init get_register(const u32 **cell,
-                                u32 address_cells, u32 size_cells,
-                                u64 *start, u64 *size)
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size)
 {
     get_val(cell, address_cells, start);
     get_val(cell, size_cells, size);
 }
 
-static u32 __init prop_by_name_u32(const void *fdt, int node,
-                                   const char *prop_name)
+static void set_val(u32 **cell, u32 cells, u64 val)
+{
+    u32 c = cells;
+
+    while ( c-- )
+    {
+        (*cell)[c] = cpu_to_fdt32(val);
+        val >>= 32;
+    }
+    (*cell) += cells;
+}
+
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size)
+{
+    set_val(cell, address_cells, start);
+    set_val(cell, size_cells, size);
+}
+
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
 {
     const struct fdt_property *prop;
 
@@ -68,8 +85,6 @@ static u32 __init prop_by_name_u32(const void *fdt, int node,
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-#define MAX_DEPTH 16
-
 /**
  * device_tree_for_each_node - iterate over all device tree nodes
  * @fdt: flat device tree.
@@ -81,19 +96,19 @@ int device_tree_for_each_node(const void *fdt,
 {
     int node;
     int depth;
-    u32 address_cells[MAX_DEPTH];
-    u32 size_cells[MAX_DEPTH];
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
     int ret;
 
     for ( node = 0, depth = 0;
           node >=0 && depth >= 0;
           node = fdt_next_node(fdt, node, &depth) )
     {
-        if ( depth >= MAX_DEPTH )
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
             continue;
 
-        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
-        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
         ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
                    address_cells[depth-1], size_cells[depth-1], data);
@@ -106,7 +121,7 @@ int device_tree_for_each_node(const void *fdt,
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
-    char prefix[2*MAX_DEPTH + 1] = "";
+    char prefix[2*DEVICE_TREE_MAX_DEPTH + 1] = "";
     int i;
     int prop;
 
@@ -172,7 +187,7 @@ static void __init process_memory_node(const void *fdt, int node,
 
     for ( i = 0; i < banks && early_info.mem.nr_banks < NR_MEM_BANKS; i++ )
     {
-        get_register(&cell, address_cells, size_cells, &start, &size);
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
         early_info.mem.bank[early_info.mem.nr_banks].start = start;
         early_info.mem.bank[early_info.mem.nr_banks].size = size;
         early_info.mem.nr_banks++;
@@ -184,7 +199,7 @@ static int __init early_scan_node(const void *fdt,
                                   u32 address_cells, u32 size_cells,
                                   void *data)
 {
-    if ( node_matches(fdt, node, "memory") )
+    if ( device_tree_node_matches(fdt, node, "memory") )
         process_memory_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index b91b39f..510b5b4 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -12,6 +12,8 @@
 
 #include <xen/types.h>
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
 #define NR_MEM_BANKS 8
 
 struct membank {
@@ -39,6 +41,12 @@ extern void *device_tree_flattened;
 size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size);
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size);
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 void device_tree_dump(const void *fdt);
diff --git a/xen/include/xen/libfdt/libfdt_env.h b/xen/include/xen/libfdt/libfdt_env.h
index 8c0c030..2f1b03c 100644
--- a/xen/include/xen/libfdt/libfdt_env.h
+++ b/xen/include/xen/libfdt/libfdt_env.h
@@ -13,4 +13,7 @@
 #define fdt64_to_cpu(x) be64_to_cpu(x)
 #define cpu_to_fdt64(x) cpu_to_be64(x)
 
+/* Xen-specific libfdt error code. */
+#define FDT_ERR_XEN(err) (FDT_ERR_MAX + (err))
+
 #endif /* _LIBFDT_ENV_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqg-00076x-Ta; Mon, 02 Apr 2012 10:50:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeqf-00076U-Bm
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:57 +0000
Received: from [85.158.143.35:53354] by server-2.bemta-4.messagelabs.com id
	7E/18-17550-094897F4; Mon, 02 Apr 2012 10:50:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333363851!11386292!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6437 invoked from network); 2 Apr 2012 10:50:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775128"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-7V;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:31 +0100
Message-ID: <1333363834-2520-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Build a flat device tree for dom0 based on the one supplied to Xen.
The following changes are made:

  * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
    bootargs.

  * In all memory nodes, the reg parameters are adjusted to reflect
    the amount of memory dom0 can use.  The p2m is updated using this
    info.

Support for passing ATAGS to dom0 is removed.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c         |  254 +++++++++++++++++++++++++++++------
 xen/arch/arm/kernel.c               |    2 +-
 xen/arch/arm/kernel.h               |    8 +-
 xen/common/device_tree.c            |   47 +++++---
 xen/include/xen/device_tree.h       |    8 +
 xen/include/xen/libfdt/libfdt_env.h |    3 +
 6 files changed, 262 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 15632f7..5e15476 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -6,6 +6,10 @@
 #include <xen/sched.h>
 #include <asm/irq.h>
 #include <asm/regs.h>
+#include <xen/errno.h>
+#include <xen/device_tree.h>
+#include <xen/libfdt/libfdt.h>
+#include <xen/guest_access.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -13,6 +17,13 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+/*
+ * Amount of extra space required to dom0's device tree.  No new nodes
+ * are added (yet) but one terminating reserve map entry (16 bytes) is
+ * added.
+ */
+#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
+
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
     if ( opt_dom0_max_vcpus == 0 )
@@ -28,43 +39,207 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
     return alloc_vcpu(dom0, 0, 0);
 }
 
-extern void guest_mode_entry(void);
+static int set_memory_reg(struct domain *d, struct kernel_info *kinfo,
+                          const void *fdt, const u32 *cell, int len,
+                          int address_cells, int size_cells, u32 *new_cell)
+{
+    int reg_size = (address_cells + size_cells) * sizeof(*cell);
+    int l = 0;
+    u64 start;
+    u64 size;
+
+    while ( kinfo->unassigned_mem > 0 && l + reg_size <= len
+            && kinfo->mem.nr_banks < NR_MEM_BANKS )
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+        if ( size > kinfo->unassigned_mem )
+            size = kinfo->unassigned_mem;
+        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
+
+        printk("Populate P2M %#llx->%#llx\n", start, start + size);
+        p2m_populate_ram(d, start, start + size);
+        kinfo->mem.bank[kinfo->mem.nr_banks].start = start;
+        kinfo->mem.bank[kinfo->mem.nr_banks].size = size;
+        kinfo->mem.nr_banks++;
+        kinfo->unassigned_mem -= size;
+
+        l += reg_size;
+    }
+
+    return l;
+}
+
+static int write_properties(struct domain *d, struct kernel_info *kinfo,
+                            const void *fdt,
+                            int node, const char *name, int depth,
+                            u32 address_cells, u32 size_cells)
+{
+    int prop;
+
+    for ( prop = fdt_first_property_offset(fdt, node);
+          prop >= 0;
+          prop = fdt_next_property_offset(fdt, prop) )
+    {
+        const struct fdt_property *p;
+        const char *prop_name;
+        const char *prop_data;
+        int prop_len;
+        char *new_data = NULL;
+
+        p = fdt_get_property_by_offset(fdt, prop, NULL);
+        prop_name = fdt_string(fdt, fdt32_to_cpu(p->nameoff));
+        prop_data = p->data;
+        prop_len  = fdt32_to_cpu(p->len);
+
+        /*
+         * In chosen node: replace bootargs with value from
+         * xen,dom0-bootargs.
+         */
+        if ( device_tree_node_matches(fdt, node, "chosen") )
+        {
+            if ( strcmp(prop_name, "bootargs") == 0 )
+                continue;
+            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
+                prop_name = "bootargs";
+        }
+        /*
+         * In a memory node: adjust reg property.
+         */
+        else if ( device_tree_node_matches(fdt, node, "memory") )
+        {
+            if ( strcmp(prop_name, "reg") == 0 )
+            {
+                new_data = xzalloc_bytes(prop_len);
+                if ( new_data  == NULL )
+                    return -FDT_ERR_XEN(ENOMEM);
+
+                prop_len = set_memory_reg(d, kinfo, fdt,
+                                          (u32 *)prop_data, prop_len,
+                                          address_cells, size_cells,
+                                          (u32 *)new_data);
+                prop_data = new_data;
+            }
+        }
+
+        /*
+         * TODO: Should call map_mmio_regions() for all devices in the
+         * tree that have a "reg" parameter (except cpus).  This
+         * requires looking into the parent node's "ranges" property
+         * to translate the bus address in the "reg" value into
+         * physical addresses.  Regions also need to be rounded up to
+         * whole pages.
+         */
+
+        fdt_property(kinfo->fdt, prop_name, prop_data, prop_len);
+
+        xfree(new_data);
+    }
+
+    if ( prop == -FDT_ERR_NOTFOUND )
+        return 0;
+    return prop;
+}
 
-static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+static int write_nodes(struct domain *d, struct kernel_info *kinfo,
+                       const void *fdt)
 {
-    paddr_t ma = gvirt_to_maddr(tags);
-    void *map = map_domain_page(ma>>PAGE_SHIFT);
-    void *p = map + (tags & (PAGE_SIZE - 1));
-    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+    int node;
+    int depth = 0, last_depth = -1;
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
+    int ret;
+
+    for ( node = 0, depth = 0;
+          node >= 0 && depth >= 0;
+          node = fdt_next_node(fdt, node, &depth) )
+    {
+        const char *name;
+
+        name = fdt_get_name(fdt, node, NULL);
 
-    /* not enough room on this page for all the tags */
-    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
+        {
+            printk("warning: node `%s' is nested too deep\n", name);
+            continue;
+        }
 
-#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+        while ( last_depth-- >= depth )
+            fdt_end_node(kinfo->fdt);
 
-    /* ATAG_CORE */
-    TAG(uint32_t, 2);
-    TAG(uint32_t, 0x54410001);
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
-    /* ATAG_MEM */
-    TAG(uint32_t, 4);
-    TAG(uint32_t, 0x54410002);
-    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
-    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+        fdt_begin_node(kinfo->fdt, name);
 
-    /* ATAG_CMDLINE */
-    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
-    TAG(uint32_t, 0x54410009);
-    memcpy(p, cmdline, strlen(cmdline) + 1);
-    p += ((strlen(cmdline) + 4) >> 2) << 2;
+        ret = write_properties(d, kinfo, fdt, node, name, depth,
+                               address_cells[depth-1], size_cells[depth-1]);
+        if ( ret < 0 )
+            return ret;
 
-    /* ATAG_NONE */
-    TAG(uint32_t, 0);
-    TAG(uint32_t, 0);
+        last_depth = depth;
+    }
 
-#undef TAG
+    while ( last_depth-- >= 0 )
+        fdt_end_node(kinfo->fdt);
 
-    unmap_domain_page(map);
+    return 0;
+}
+
+static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
+{
+    void *fdt;
+    int new_size;
+    int ret;
+
+    fdt = device_tree_flattened;
+
+    new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
+    kinfo->fdt = xmalloc_bytes(new_size);
+    if ( kinfo->fdt == NULL )
+        return -ENOMEM;
+
+    ret = fdt_create(kinfo->fdt, new_size);
+    if ( ret < 0 )
+        goto err;
+
+    fdt_finish_reservemap(kinfo->fdt);
+
+    ret = write_nodes(d, kinfo, fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    device_tree_dump(kinfo->fdt);
+
+    /*
+     * Put the device tree at the beginning of the first bank.  It
+     * must be below 4 GiB.
+     */
+    kinfo->dtb_paddr = kinfo->mem.bank[0].start + 0x100;
+    if ( kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt) > (1ull << 32) )
+    {
+        printk("Not enough memory below 4 GiB for the device tree.");
+        ret = -FDT_ERR_XEN(EINVAL);
+        goto err;
+    }
+
+    return 0;
+
+  err:
+    printk("Device tree generation failed (%d).\n", ret);
+    xfree(kinfo->fdt);
+    return -EINVAL;
+}
+
+static void dtb_load(struct kernel_info *kinfo)
+{
+    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
+
+    raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
+    xfree(kinfo->fdt);
 }
 
 int construct_dom0(struct domain *d)
@@ -82,22 +257,20 @@ int construct_dom0(struct domain *d)
 
     printk("*** LOADING DOMAIN 0 ***\n");
 
-    /* 128M at 2G physical */
-    /* TODO size and location from DT. */
-    kinfo.ram_start = 0x80000000;
-    kinfo.ram_end   = 0x88000000;
+    d->max_pages = ~0U;
 
-    rc = kernel_prepare(&kinfo);
-    if (rc < 0)
+    if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    d->max_pages = ~0U;
+    kinfo.unassigned_mem = 0x08000000; /* XXX */
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
+    rc = prepare_dtb(d, &kinfo);
+    if ( rc < 0 )
         return rc;
 
-    printk("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
-    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
+    rc = kernel_prepare(&kinfo);
+    if ( rc < 0 )
+        return rc;
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -125,13 +298,12 @@ int construct_dom0(struct domain *d)
     /* Enable second stage translation */
     WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
 
-    /* The following load uses domain's p2m */
+    /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
 
+    dtb_load(&kinfo);
     kernel_load(&kinfo);
 
-    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
-
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
@@ -153,7 +325,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
+    regs->r2 = kinfo.dtb_paddr;
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index dd757e5..130d488 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -121,7 +121,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
      * at 32k from start of RAM.
      */
     if (start == 0)
-        info->zimage.load_addr = info->ram_start + 0x8000;
+        info->zimage.load_addr = info->mem.bank[0].start + 0x8000;
     else
         info->zimage.load_addr = start;
     info->zimage.len = end - start;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 5caebe5..4533568 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -7,11 +7,15 @@
 #define __ARCH_ARM_KERNEL_H__
 
 #include <xen/libelf.h>
+#include <xen/device_tree.h>
 
 struct kernel_info {
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct dt_mem_info mem;
+
+    paddr_t dtb_paddr;
     paddr_t entry;
-    paddr_t ram_start;
-    paddr_t ram_end;
 
     void *kernel_img;
     unsigned kernel_order;
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index d4b1556..715fbf6 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -23,7 +23,7 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
-static bool_t __init node_matches(const void *fdt, int node, const char *match)
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
 {
     const char *name;
     size_t match_len;
@@ -48,16 +48,33 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
     }
 }
 
-static void __init get_register(const u32 **cell,
-                                u32 address_cells, u32 size_cells,
-                                u64 *start, u64 *size)
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size)
 {
     get_val(cell, address_cells, start);
     get_val(cell, size_cells, size);
 }
 
-static u32 __init prop_by_name_u32(const void *fdt, int node,
-                                   const char *prop_name)
+static void set_val(u32 **cell, u32 cells, u64 val)
+{
+    u32 c = cells;
+
+    while ( c-- )
+    {
+        (*cell)[c] = cpu_to_fdt32(val);
+        val >>= 32;
+    }
+    (*cell) += cells;
+}
+
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size)
+{
+    set_val(cell, address_cells, start);
+    set_val(cell, size_cells, size);
+}
+
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
 {
     const struct fdt_property *prop;
 
@@ -68,8 +85,6 @@ static u32 __init prop_by_name_u32(const void *fdt, int node,
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-#define MAX_DEPTH 16
-
 /**
  * device_tree_for_each_node - iterate over all device tree nodes
  * @fdt: flat device tree.
@@ -81,19 +96,19 @@ int device_tree_for_each_node(const void *fdt,
 {
     int node;
     int depth;
-    u32 address_cells[MAX_DEPTH];
-    u32 size_cells[MAX_DEPTH];
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
     int ret;
 
     for ( node = 0, depth = 0;
           node >=0 && depth >= 0;
           node = fdt_next_node(fdt, node, &depth) )
     {
-        if ( depth >= MAX_DEPTH )
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
             continue;
 
-        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
-        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
         ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
                    address_cells[depth-1], size_cells[depth-1], data);
@@ -106,7 +121,7 @@ int device_tree_for_each_node(const void *fdt,
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
-    char prefix[2*MAX_DEPTH + 1] = "";
+    char prefix[2*DEVICE_TREE_MAX_DEPTH + 1] = "";
     int i;
     int prop;
 
@@ -172,7 +187,7 @@ static void __init process_memory_node(const void *fdt, int node,
 
     for ( i = 0; i < banks && early_info.mem.nr_banks < NR_MEM_BANKS; i++ )
     {
-        get_register(&cell, address_cells, size_cells, &start, &size);
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
         early_info.mem.bank[early_info.mem.nr_banks].start = start;
         early_info.mem.bank[early_info.mem.nr_banks].size = size;
         early_info.mem.nr_banks++;
@@ -184,7 +199,7 @@ static int __init early_scan_node(const void *fdt,
                                   u32 address_cells, u32 size_cells,
                                   void *data)
 {
-    if ( node_matches(fdt, node, "memory") )
+    if ( device_tree_node_matches(fdt, node, "memory") )
         process_memory_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index b91b39f..510b5b4 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -12,6 +12,8 @@
 
 #include <xen/types.h>
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
 #define NR_MEM_BANKS 8
 
 struct membank {
@@ -39,6 +41,12 @@ extern void *device_tree_flattened;
 size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size);
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size);
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 void device_tree_dump(const void *fdt);
diff --git a/xen/include/xen/libfdt/libfdt_env.h b/xen/include/xen/libfdt/libfdt_env.h
index 8c0c030..2f1b03c 100644
--- a/xen/include/xen/libfdt/libfdt_env.h
+++ b/xen/include/xen/libfdt/libfdt_env.h
@@ -13,4 +13,7 @@
 #define fdt64_to_cpu(x) be64_to_cpu(x)
 #define cpu_to_fdt64(x) cpu_to_be64(x)
 
+/* Xen-specific libfdt error code. */
+#define FDT_ERR_XEN(err) (FDT_ERR_MAX + (err))
+
 #endif /* _LIBFDT_ENV_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqf-00076V-6a; Mon, 02 Apr 2012 10:50:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeqd-000767-G5
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:55 +0000
Received: from [85.158.143.35:53169] by server-1.bemta-4.messagelabs.com id
	D8/2B-20925-E84897F4; Mon, 02 Apr 2012 10:50:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333363851!11386292!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6299 invoked from network); 2 Apr 2012 10:50:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775126"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-6e;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:30 +0100
Message-ID: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv4 00/04] arm: pass a device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We don't yet make use of the device tree to map MMIO regions or setup
interrupts for the guest and we still include the UART used for Xen's
console.

Note the kernel must support device tree (ATAGS are no longer provided
by Xen).

It is also possible to provide the Xen and dom0 command line via the
device tree.  This isn't as useful as it seems as Xen still needs to
be rebuilt to included the updated device tree.

The instructions on the wiki[1] have been updated to reflect these
changes.

Changes since v3:
  - dropped already applied patches
  - tweaked set_memory_reg() to be a bit more readable.

Changes since v2:
  - dropped already applied patches
  - fix crash on boot if bootargs is missing
  - allow space in dom0's dtb for the mem reserve entry
  - bail if dom0's dtb couldn't be created
  - new patch to print warning if a node is nested too deep

Changes since v1:
  - coding style
  - move libfdt headers
  - added myself as device tree maintainer
  - fix potential infinite loop when assigning mem
  - check dtb destination more carefully
  - minor updates for clarity

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEeqf-00076V-6a; Mon, 02 Apr 2012 10:50:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEeqd-000767-G5
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:50:55 +0000
Received: from [85.158.143.35:53169] by server-1.bemta-4.messagelabs.com id
	D8/2B-20925-E84897F4; Mon, 02 Apr 2012 10:50:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333363851!11386292!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6299 invoked from network); 2 Apr 2012 10:50:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="23775126"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-6e;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:30 +0100
Message-ID: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv4 00/04] arm: pass a device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We don't yet make use of the device tree to map MMIO regions or setup
interrupts for the guest and we still include the UART used for Xen's
console.

Note the kernel must support device tree (ATAGS are no longer provided
by Xen).

It is also possible to provide the Xen and dom0 command line via the
device tree.  This isn't as useful as it seems as Xen still needs to
be rebuilt to included the updated device tree.

The instructions on the wiki[1] have been updated to reflect these
changes.

Changes since v3:
  - dropped already applied patches
  - tweaked set_memory_reg() to be a bit more readable.

Changes since v2:
  - dropped already applied patches
  - fix crash on boot if bootargs is missing
  - allow space in dom0's dtb for the mem reserve entry
  - bail if dom0's dtb couldn't be created
  - new patch to print warning if a node is nested too deep

Changes since v1:
  - coding style
  - move libfdt headers
  - added myself as device tree maintainer
  - fix potential infinite loop when assigning mem
  - check dtb destination more carefully
  - minor updates for clarity

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer7-0007E4-BZ; Mon, 02 Apr 2012 10:51:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEer5-0007Cp-Ek
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:23 +0000
Received: from [193.109.254.147:4148] by server-9.bemta-14.messagelabs.com id
	02/30-05787-AA4897F4; Mon, 02 Apr 2012 10:51:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333363877!2959994!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3908 invoked from network); 2 Apr 2012 10:51:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621062"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-B0;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:34 +0100
Message-ID: <1333363834-2520-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] device tree: print a warning if a node is
	nested too deep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Since device_tree_for_each_node() is called before printk() works, a
variable is used to switch between using early_printk() and printk().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/device_tree.c |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 8fb6d46..04619f4 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -23,6 +23,10 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
+/* Some device tree functions may be called both before and after the
+   console is initialized. */
+static void (*dt_printk)(const char *fmt, ...) = early_printk;
+
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
 {
     const char *name;
@@ -90,6 +94,11 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
  * @fdt: flat device tree.
  * @func: function to call for each node.
  * @data: data to pass to @func.
+ *
+ * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
+ *
+ * Returns 0 if all nodes were iterated over successfully.  If @func
+ * returns a negative value, that value is returned immediately.
  */
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data)
@@ -104,13 +113,19 @@ int device_tree_for_each_node(const void *fdt,
           node >=0 && depth >= 0;
           node = fdt_next_node(fdt, node, &depth) )
     {
+        const char *name = fdt_get_name(fdt, node, NULL);
+
         if ( depth >= DEVICE_TREE_MAX_DEPTH )
+        {
+            dt_printk("Warning: device tree node `%s' is nested too deep\n",
+                      name);
             continue;
+        }
 
         address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
         size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
-        ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
+        ret = func(fdt, node, name, depth,
                    address_cells[depth-1], size_cells[depth-1], data);
         if ( ret < 0 )
             return ret;
@@ -253,6 +268,8 @@ size_t __init device_tree_early_init(const void *fdt)
     device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
     early_print_info();
 
+    dt_printk = printk;
+
     return fdt_totalsize(fdt);
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer7-0007E4-BZ; Mon, 02 Apr 2012 10:51:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEer5-0007Cp-Ek
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:23 +0000
Received: from [193.109.254.147:4148] by server-9.bemta-14.messagelabs.com id
	02/30-05787-AA4897F4; Mon, 02 Apr 2012 10:51:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333363877!2959994!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3908 invoked from network); 2 Apr 2012 10:51:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621062"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-B0;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:34 +0100
Message-ID: <1333363834-2520-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] device tree: print a warning if a node is
	nested too deep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Since device_tree_for_each_node() is called before printk() works, a
variable is used to switch between using early_printk() and printk().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/device_tree.c |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 8fb6d46..04619f4 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -23,6 +23,10 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
+/* Some device tree functions may be called both before and after the
+   console is initialized. */
+static void (*dt_printk)(const char *fmt, ...) = early_printk;
+
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
 {
     const char *name;
@@ -90,6 +94,11 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
  * @fdt: flat device tree.
  * @func: function to call for each node.
  * @data: data to pass to @func.
+ *
+ * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
+ *
+ * Returns 0 if all nodes were iterated over successfully.  If @func
+ * returns a negative value, that value is returned immediately.
  */
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data)
@@ -104,13 +113,19 @@ int device_tree_for_each_node(const void *fdt,
           node >=0 && depth >= 0;
           node = fdt_next_node(fdt, node, &depth) )
     {
+        const char *name = fdt_get_name(fdt, node, NULL);
+
         if ( depth >= DEVICE_TREE_MAX_DEPTH )
+        {
+            dt_printk("Warning: device tree node `%s' is nested too deep\n",
+                      name);
             continue;
+        }
 
         address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
         size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
-        ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
+        ret = func(fdt, node, name, depth,
                    address_cells[depth-1], size_cells[depth-1], data);
         if ( ret < 0 )
             return ret;
@@ -253,6 +268,8 @@ size_t __init device_tree_early_init(const void *fdt)
     device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
     early_print_info();
 
+    dt_printk = printk;
+
     return fdt_totalsize(fdt);
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer5-0007D4-HC; Mon, 02 Apr 2012 10:51:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEer3-0007CZ-G8
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:21 +0000
Received: from [193.109.254.147:38706] by server-2.bemta-14.messagelabs.com id
	9B/8F-19409-8A4897F4; Mon, 02 Apr 2012 10:51:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333363877!2959994!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3734 invoked from network); 2 Apr 2012 10:51:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621059"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:50 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SEeqY-0000P6-3z;
	Mon, 02 Apr 2012 11:50:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
Message-ID: <5386937e6c5c9afaa8a3.1333363656@kodo2>
In-Reply-To: <patchbomb.1333363655@kodo2>
References: <patchbomb.1333363655@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 2 Apr 2012 11:47:36 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1333362574 -3600
# Node ID 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
# Parent  f744e82ea74075983de6d5b0ad0cf7ccacf999a2
libxl: Move bdf parsing into libxlu

Config parsing functions do not properly belong in libxl.  Move them into
libxlu so that others can use them or not as they see fit.

No functional changes.  One side-effect was making public a private libxl
utility function which just set the elements of a structure from the  function
arguments passed in.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/Makefile	Mon Apr 02 11:29:34 2012 +0100
@@ -57,7 +57,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-	libxlu_disk_l.o libxlu_disk.o
+	libxlu_disk_l.o libxlu_disk.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 CLIENTS = xl testidl
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Apr 02 11:29:34 2012 +0100
@@ -573,13 +573,10 @@ int libxl_device_pci_add(libxl_ctx *ctx,
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
-
-/*
- * Parse a PCI BDF into a PCI device structure.
- */
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
-                               libxl_device_pci *pcidev,
-                               const char *str);
+/* Just initialize the structure elements with the arguments provided. */
+int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
+                       unsigned int bus, unsigned int dev,
+                       unsigned int func, unsigned int vdevfn);
 
 /*
  * Similar to libxl_device_pci_list but returns all devices which
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
@@ -34,7 +34,7 @@ static unsigned int pcidev_encode_bdf(li
     return value;
 }
 
-static int pcidev_init(libxl_device_pci *pcidev, unsigned int domain,
+int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
                           unsigned int bus, unsigned int dev,
                           unsigned int func, unsigned int vdevfn)
 {
@@ -46,149 +46,6 @@ static int pcidev_init(libxl_device_pci 
     return 0;
 }
 
-static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
-{
-    unsigned long ret;
-    char *end;
-
-    ret = strtoul(str, &end, 16);
-    if ( end == str || *end != '\0' )
-        return -1;
-    if ( ret & ~mask )
-        return -1;
-    *val = (unsigned int)ret & mask;
-    return 0;
-}
-
-#define STATE_DOMAIN    0
-#define STATE_BUS       1
-#define STATE_DEV       2
-#define STATE_FUNC      3
-#define STATE_VSLOT     4
-#define STATE_OPTIONS_K 6
-#define STATE_OPTIONS_V 7
-#define STATE_TERMINAL  8
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx, libxl_device_pci *pcidev, const char *str)
-{
-    unsigned state = STATE_DOMAIN;
-    unsigned dom, bus, dev, func, vslot = 0;
-    char *buf2, *tok, *ptr, *end, *optkey = NULL;
-
-    if ( NULL == (buf2 = ptr = strdup(str)) )
-        return ERROR_NOMEM;
-
-    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
-        switch(state) {
-        case STATE_DOMAIN:
-            if ( *ptr == ':' ) {
-                state = STATE_BUS;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dom, 0xffff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_BUS:
-            if ( *ptr == ':' ) {
-                state = STATE_DEV;
-                *ptr = '\0';
-                if ( hex_convert(tok, &bus, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }else if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( dom & ~0xff )
-                    goto parse_error;
-                bus = dom;
-                dom = 0;
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_DEV:
-            if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_FUNC:
-            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
-                switch( *ptr ) {
-                case '\0':
-                    state = STATE_TERMINAL;
-                    break;
-                case '@':
-                    state = STATE_VSLOT;
-                    break;
-                case ',':
-                    state = STATE_OPTIONS_K;
-                    break;
-                }
-                *ptr = '\0';
-                if ( !strcmp(tok, "*") ) {
-                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
-                }else{
-                    if ( hex_convert(tok, &func, 0x7) )
-                        goto parse_error;
-                    pcidev->vfunc_mask = (1 << 0);
-                }
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_VSLOT:
-            if ( *ptr == '\0' || *ptr == ',' ) {
-                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( hex_convert(tok, &vslot, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_K:
-            if ( *ptr == '=' ) {
-                state = STATE_OPTIONS_V;
-                *ptr = '\0';
-                optkey = tok;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_V:
-            if ( *ptr == ',' || *ptr == '\0' ) {
-                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( !strcmp(optkey, "msitranslate") ) {
-                    pcidev->msitranslate = atoi(tok);
-                }else if ( !strcmp(optkey, "power_mgmt") ) {
-                    pcidev->power_mgmt = atoi(tok);
-                }else{
-                    LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
-                           "Unknown PCI BDF option: %s", optkey);
-                }
-                tok = ptr + 1;
-            }
-        default:
-            break;
-        }
-    }
-
-    free(buf2);
-
-    if ( tok != ptr || state != STATE_TERMINAL )
-        goto parse_error;
-
-    pcidev_init(pcidev, dom, bus, dev, func, vslot << 3);
-
-    return 0;
-
-parse_error:
-    return ERROR_INVAL;
-}
-
 static void libxl_create_pci_backend_device(libxl__gc *gc, flexarray_t *back, int num, libxl_device_pci *pcidev)
 {
     flexarray_append(back, libxl__sprintf(gc, "key-%d", num));
@@ -436,7 +293,7 @@ static int get_all_assigned_devices(libx
                     *list = realloc(*list, sizeof(libxl_device_pci) * ((*num) + 1));
                     if (*list == NULL)
                         return ERROR_NOMEM;
-                    pcidev_init(*list + *num, dom, bus, dev, func, 0);
+                    libxl_pci_dev_init(*list + *num, dom, bus, dev, func, 0);
                     (*num)++;
                 }
             }
@@ -507,7 +364,7 @@ libxl_device_pci *libxl_device_pci_list_
         new = pcidevs + *num;
 
         memset(new, 0, sizeof(*new));
-        pcidev_init(new, dom, bus, dev, func, 0);
+        libxl_pci_dev_init(new, dom, bus, dev, func, 0);
         (*num)++;
     }
 
@@ -1086,7 +943,7 @@ static void libxl__device_pci_from_xs_be
     if (s)
         vdevfn = strtol(s, (char **) NULL, 16);
 
-    pcidev_init(pci, domain, bus, dev, func, vdevfn);
+    libxl_pci_dev_init(pci, domain, bus, dev, func, vdevfn);
 
     s = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/opts-%d", be_path, nr));
     if (s) {
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxlu_pci.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxlu_pci.c	Mon Apr 02 11:29:34 2012 +0100
@@ -0,0 +1,160 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "libxlu_disk_l.h"
+#include "libxlu_disk_i.h"
+#include "libxlu_cfg_i.h"
+
+
+#define XLU__PCI_ERR(_c, _x, _a...) \
+    if((_c) && (_c)->report) fprintf((_c)->report, _x, ##_a)
+
+static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
+{
+    unsigned long ret;
+    char *end;
+
+    ret = strtoul(str, &end, 16);
+    if ( end == str || *end != '\0' )
+        return -1;
+    if ( ret & ~mask )
+        return -1;
+    *val = (unsigned int)ret & mask;
+    return 0;
+}
+
+#define STATE_DOMAIN    0
+#define STATE_BUS       1
+#define STATE_DEV       2
+#define STATE_FUNC      3
+#define STATE_VSLOT     4
+#define STATE_OPTIONS_K 6
+#define STATE_OPTIONS_V 7
+#define STATE_TERMINAL  8
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str)
+{
+    unsigned state = STATE_DOMAIN;
+    unsigned dom, bus, dev, func, vslot = 0;
+    char *buf2, *tok, *ptr, *end, *optkey = NULL;
+
+    if ( NULL == (buf2 = ptr = strdup(str)) )
+        return ERROR_NOMEM;
+
+    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
+        switch(state) {
+        case STATE_DOMAIN:
+            if ( *ptr == ':' ) {
+                state = STATE_BUS;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dom, 0xffff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_BUS:
+            if ( *ptr == ':' ) {
+                state = STATE_DEV;
+                *ptr = '\0';
+                if ( hex_convert(tok, &bus, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }else if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( dom & ~0xff )
+                    goto parse_error;
+                bus = dom;
+                dom = 0;
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_DEV:
+            if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_FUNC:
+            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
+                switch( *ptr ) {
+                case '\0':
+                    state = STATE_TERMINAL;
+                    break;
+                case '@':
+                    state = STATE_VSLOT;
+                    break;
+                case ',':
+                    state = STATE_OPTIONS_K;
+                    break;
+                }
+                *ptr = '\0';
+                if ( !strcmp(tok, "*") ) {
+                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
+                }else{
+                    if ( hex_convert(tok, &func, 0x7) )
+                        goto parse_error;
+                    pcidev->vfunc_mask = (1 << 0);
+                }
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_VSLOT:
+            if ( *ptr == '\0' || *ptr == ',' ) {
+                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( hex_convert(tok, &vslot, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_K:
+            if ( *ptr == '=' ) {
+                state = STATE_OPTIONS_V;
+                *ptr = '\0';
+                optkey = tok;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_V:
+            if ( *ptr == ',' || *ptr == '\0' ) {
+                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( !strcmp(optkey, "msitranslate") ) {
+                    pcidev->msitranslate = atoi(tok);
+                }else if ( !strcmp(optkey, "power_mgmt") ) {
+                    pcidev->power_mgmt = atoi(tok);
+                }else{
+                    XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
+                }
+                tok = ptr + 1;
+            }
+        default:
+            break;
+        }
+    }
+
+    free(buf2);
+
+    if ( tok != ptr || state != STATE_TERMINAL )
+        goto parse_error;
+
+    /* Just a pretty way to fill in the values */
+    libxl_pci_dev_init(pcidev, dom, bus, dev, func, vslot << 3);
+
+    return 0;
+
+parse_error:
+    return ERROR_INVAL;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxlutil.h	Mon Apr 02 11:29:34 2012 +0100
@@ -88,6 +88,16 @@ int xlu_disk_parse(XLU_Config *cfg, int 
    * resulting disk struct is used with libxl.
    */
 
+/*
+ * PCI specification parsing
+ */
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str);
+/* */ 
+
+int xlu_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
+                     unsigned int bus, unsigned int dev,
+                     unsigned int func, unsigned int vdevfn);
+
 
 #endif /* LIBXLUTIL_H */
 
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 02 11:29:34 2012 +0100
@@ -1005,7 +1005,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
-            if (!libxl_device_pci_parse_bdf(ctx, pcidev, buf))
+            if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -2217,11 +2217,16 @@ int main_pcilist(int argc, char **argv)
 static void pcidetach(const char *dom, const char *bdf, int force)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+    
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-detach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
@@ -2257,11 +2262,16 @@ int main_pcidetach(int argc, char **argv
 static void pciattach(const char *dom, const char *bdf, const char *vs)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-attach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
diff -r f744e82ea740 -r 5386937e6c5c tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Apr 02 11:29:34 2012 +0100
@@ -40,6 +40,7 @@
 
 #include <libxl.h>
 #include <libxl_utils.h>
+#include <libxlutil.h>
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
@@ -556,7 +557,7 @@ static PyObject *pyxl_pci_parse(XlObject
         return NULL;
     }
 
-    if ( libxl_device_pci_parse_bdf(self->ctx, &pci->obj, str) ) {
+    if ( xlu_pci_parse_bdf(NULL, &pci->obj, str) ) {
         PyErr_SetString(xl_error_obj, "cannot parse pci device spec (BDF)");
         Py_DECREF(pci);
         return NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer6-0007Do-Tw; Mon, 02 Apr 2012 10:51:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEer4-0007Cp-Ry
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:23 +0000
Received: from [193.109.254.147:33821] by server-9.bemta-14.messagelabs.com id
	EE/20-05787-AA4897F4; Mon, 02 Apr 2012 10:51:22 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333363877!2959994!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3824 invoked from network); 2 Apr 2012 10:51:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621058"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:50 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SEeqY-0000P6-4T;
	Mon, 02 Apr 2012 11:50:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 62b1030a2485536caf995b825bee9e8255f914b3
Message-ID: <62b1030a2485536caf99.1333363657@kodo2>
In-Reply-To: <patchbomb.1333363655@kodo2>
References: <patchbomb.1333363655@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 2 Apr 2012 11:47:37 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1333363500 -3600
# Node ID 62b1030a2485536caf995b825bee9e8255f914b3
# Parent  5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
xl,libxl: Add per-device and global permissive config options for pci passthrough

By default pciback only allows PV guests to write "known safe" values into
PCI config space.  But many devices require writes to other areas of config
space in order to operate properly.  One way to do that is with the "quirks"
interface, which specifies areas known safe to a particular device; the
other way is to mark a device as "permissive", which tells pciback to allow
all config space writes for that domain and device.

This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
to write the appropriate value into sysfs to enable the permissive feature for
devices being passed through.  It also adds the permissive config options either
on a per-device basis, or as a global option in the xl command-line.

Because of the potential stability and security implications of enabling
permissive, the flag is left off by default.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5386937e6c5c -r 62b1030a2485 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Apr 02 11:29:34 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Mon Apr 02 11:45:00 2012 +0100
@@ -294,10 +294,25 @@ XXX
 
 XXX
 
+=item B<permissive=BOOLEAN>
+
+By default pciback only allows PV guests to write "known safe" values into
+PCI config space.  But many devices require writes to other areas of config
+space in order to operate properly.  This tells the pciback driver to
+allow all writes to PCI config space for this domain and this device.  This
+option should be enabled with caution, as there may be stability or security 
+implications of doing so.
+
 =back
 
 =back
 
+=item B<pci_permissive=BOOLEAN>
+
+Changes the default value of 'permissive' for all PCI devices for this
+VM.  This can still be overriden on a per-device basis. See the
+"pci=" section for more information on the "permissive" flag.
+
 =back
 
 =head2 Paravirtualised (PV) Guest Specific Options
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
@@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
     if (pcidev->vdevfn)
         flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
     flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
-    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
+    flexarray_append(back,
+              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
+                             pcidev->msitranslate, pcidev->power_mgmt,
+                             pcidev->permissive));
     flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
 }
 
@@ -565,6 +568,29 @@ static int do_pci_add(libxl__gc *gc, uin
             }
         }
         fclose(f);
+
+        /* Don't restrict writes to the PCI config space from this VM */
+        if (pcidev->permissive) {
+            int fd;
+            char *buf;
+
+            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
+            fd = open(sysfs_path, O_WRONLY);
+            if (fd < 0) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
+                                 sysfs_path);
+                goto out;
+            }
+ 
+            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
+                                 pcidev->dev, pcidev->func);
+            rc = write(fd, buf, strlen(buf));
+            if (rc < 0)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
+                                 sysfs_path, rc);
+            close(fd);
+            goto out;
+        }
         break;
     }
     default:
@@ -958,6 +984,9 @@ static void libxl__device_pci_from_xs_be
             } else if (!strcmp(p, "power_mgmt")) {
                 p = strtok_r(NULL, ",=", &saveptr);
                 pci->power_mgmt = atoi(p);
+            } else if (!strcmp(p, "permissive")) {
+                p = strtok_r(NULL, ",=", &saveptr);
+                pci->permissive = atoi(p);
             }
         } while ((p = strtok_r(NULL, ",=", &saveptr)) != NULL);
     }
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Apr 02 11:45:00 2012 +0100
@@ -352,6 +352,7 @@ libxl_device_pci = Struct("device_pci", 
     ("vfunc_mask", uint32),
     ("msitranslate", bool),
     ("power_mgmt", bool),
+    ("permissive", bool),
     ])
 
 libxl_diskinfo = Struct("diskinfo", [
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxlu_pci.c
--- a/tools/libxl/libxlu_pci.c	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/libxlu_pci.c	Mon Apr 02 11:45:00 2012 +0100
@@ -127,6 +127,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, l
                     pcidev->msitranslate = atoi(tok);
                 }else if ( !strcmp(optkey, "power_mgmt") ) {
                     pcidev->power_mgmt = atoi(tok);
+                }else if ( !strcmp(optkey, "permissive") ) {
+                    pcidev->permissive = atoi(tok);
                 }else{
                     XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
                 }
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 02 11:45:00 2012 +0100
@@ -518,6 +518,7 @@ static void parse_config_data(const char
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
+    int pci_permissive = 0;
     int e;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -986,6 +987,9 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
+    if (!xlu_cfg_get_long (config, "pci_permissive", &l, 0))
+        pci_permissive = l;
+
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1005,6 +1009,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
+            pcidev->permissive = pci_permissive;
             if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer5-0007D4-HC; Mon, 02 Apr 2012 10:51:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEer3-0007CZ-G8
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:21 +0000
Received: from [193.109.254.147:38706] by server-2.bemta-14.messagelabs.com id
	9B/8F-19409-8A4897F4; Mon, 02 Apr 2012 10:51:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333363877!2959994!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3734 invoked from network); 2 Apr 2012 10:51:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621059"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:50 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SEeqY-0000P6-3z;
	Mon, 02 Apr 2012 11:50:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
Message-ID: <5386937e6c5c9afaa8a3.1333363656@kodo2>
In-Reply-To: <patchbomb.1333363655@kodo2>
References: <patchbomb.1333363655@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 2 Apr 2012 11:47:36 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1333362574 -3600
# Node ID 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
# Parent  f744e82ea74075983de6d5b0ad0cf7ccacf999a2
libxl: Move bdf parsing into libxlu

Config parsing functions do not properly belong in libxl.  Move them into
libxlu so that others can use them or not as they see fit.

No functional changes.  One side-effect was making public a private libxl
utility function which just set the elements of a structure from the  function
arguments passed in.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/Makefile	Mon Apr 02 11:29:34 2012 +0100
@@ -57,7 +57,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-	libxlu_disk_l.o libxlu_disk.o
+	libxlu_disk_l.o libxlu_disk.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 CLIENTS = xl testidl
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Apr 02 11:29:34 2012 +0100
@@ -573,13 +573,10 @@ int libxl_device_pci_add(libxl_ctx *ctx,
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
-
-/*
- * Parse a PCI BDF into a PCI device structure.
- */
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
-                               libxl_device_pci *pcidev,
-                               const char *str);
+/* Just initialize the structure elements with the arguments provided. */
+int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
+                       unsigned int bus, unsigned int dev,
+                       unsigned int func, unsigned int vdevfn);
 
 /*
  * Similar to libxl_device_pci_list but returns all devices which
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
@@ -34,7 +34,7 @@ static unsigned int pcidev_encode_bdf(li
     return value;
 }
 
-static int pcidev_init(libxl_device_pci *pcidev, unsigned int domain,
+int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
                           unsigned int bus, unsigned int dev,
                           unsigned int func, unsigned int vdevfn)
 {
@@ -46,149 +46,6 @@ static int pcidev_init(libxl_device_pci 
     return 0;
 }
 
-static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
-{
-    unsigned long ret;
-    char *end;
-
-    ret = strtoul(str, &end, 16);
-    if ( end == str || *end != '\0' )
-        return -1;
-    if ( ret & ~mask )
-        return -1;
-    *val = (unsigned int)ret & mask;
-    return 0;
-}
-
-#define STATE_DOMAIN    0
-#define STATE_BUS       1
-#define STATE_DEV       2
-#define STATE_FUNC      3
-#define STATE_VSLOT     4
-#define STATE_OPTIONS_K 6
-#define STATE_OPTIONS_V 7
-#define STATE_TERMINAL  8
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx, libxl_device_pci *pcidev, const char *str)
-{
-    unsigned state = STATE_DOMAIN;
-    unsigned dom, bus, dev, func, vslot = 0;
-    char *buf2, *tok, *ptr, *end, *optkey = NULL;
-
-    if ( NULL == (buf2 = ptr = strdup(str)) )
-        return ERROR_NOMEM;
-
-    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
-        switch(state) {
-        case STATE_DOMAIN:
-            if ( *ptr == ':' ) {
-                state = STATE_BUS;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dom, 0xffff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_BUS:
-            if ( *ptr == ':' ) {
-                state = STATE_DEV;
-                *ptr = '\0';
-                if ( hex_convert(tok, &bus, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }else if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( dom & ~0xff )
-                    goto parse_error;
-                bus = dom;
-                dom = 0;
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_DEV:
-            if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_FUNC:
-            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
-                switch( *ptr ) {
-                case '\0':
-                    state = STATE_TERMINAL;
-                    break;
-                case '@':
-                    state = STATE_VSLOT;
-                    break;
-                case ',':
-                    state = STATE_OPTIONS_K;
-                    break;
-                }
-                *ptr = '\0';
-                if ( !strcmp(tok, "*") ) {
-                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
-                }else{
-                    if ( hex_convert(tok, &func, 0x7) )
-                        goto parse_error;
-                    pcidev->vfunc_mask = (1 << 0);
-                }
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_VSLOT:
-            if ( *ptr == '\0' || *ptr == ',' ) {
-                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( hex_convert(tok, &vslot, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_K:
-            if ( *ptr == '=' ) {
-                state = STATE_OPTIONS_V;
-                *ptr = '\0';
-                optkey = tok;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_V:
-            if ( *ptr == ',' || *ptr == '\0' ) {
-                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( !strcmp(optkey, "msitranslate") ) {
-                    pcidev->msitranslate = atoi(tok);
-                }else if ( !strcmp(optkey, "power_mgmt") ) {
-                    pcidev->power_mgmt = atoi(tok);
-                }else{
-                    LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
-                           "Unknown PCI BDF option: %s", optkey);
-                }
-                tok = ptr + 1;
-            }
-        default:
-            break;
-        }
-    }
-
-    free(buf2);
-
-    if ( tok != ptr || state != STATE_TERMINAL )
-        goto parse_error;
-
-    pcidev_init(pcidev, dom, bus, dev, func, vslot << 3);
-
-    return 0;
-
-parse_error:
-    return ERROR_INVAL;
-}
-
 static void libxl_create_pci_backend_device(libxl__gc *gc, flexarray_t *back, int num, libxl_device_pci *pcidev)
 {
     flexarray_append(back, libxl__sprintf(gc, "key-%d", num));
@@ -436,7 +293,7 @@ static int get_all_assigned_devices(libx
                     *list = realloc(*list, sizeof(libxl_device_pci) * ((*num) + 1));
                     if (*list == NULL)
                         return ERROR_NOMEM;
-                    pcidev_init(*list + *num, dom, bus, dev, func, 0);
+                    libxl_pci_dev_init(*list + *num, dom, bus, dev, func, 0);
                     (*num)++;
                 }
             }
@@ -507,7 +364,7 @@ libxl_device_pci *libxl_device_pci_list_
         new = pcidevs + *num;
 
         memset(new, 0, sizeof(*new));
-        pcidev_init(new, dom, bus, dev, func, 0);
+        libxl_pci_dev_init(new, dom, bus, dev, func, 0);
         (*num)++;
     }
 
@@ -1086,7 +943,7 @@ static void libxl__device_pci_from_xs_be
     if (s)
         vdevfn = strtol(s, (char **) NULL, 16);
 
-    pcidev_init(pci, domain, bus, dev, func, vdevfn);
+    libxl_pci_dev_init(pci, domain, bus, dev, func, vdevfn);
 
     s = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/opts-%d", be_path, nr));
     if (s) {
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxlu_pci.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxlu_pci.c	Mon Apr 02 11:29:34 2012 +0100
@@ -0,0 +1,160 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "libxlu_disk_l.h"
+#include "libxlu_disk_i.h"
+#include "libxlu_cfg_i.h"
+
+
+#define XLU__PCI_ERR(_c, _x, _a...) \
+    if((_c) && (_c)->report) fprintf((_c)->report, _x, ##_a)
+
+static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
+{
+    unsigned long ret;
+    char *end;
+
+    ret = strtoul(str, &end, 16);
+    if ( end == str || *end != '\0' )
+        return -1;
+    if ( ret & ~mask )
+        return -1;
+    *val = (unsigned int)ret & mask;
+    return 0;
+}
+
+#define STATE_DOMAIN    0
+#define STATE_BUS       1
+#define STATE_DEV       2
+#define STATE_FUNC      3
+#define STATE_VSLOT     4
+#define STATE_OPTIONS_K 6
+#define STATE_OPTIONS_V 7
+#define STATE_TERMINAL  8
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str)
+{
+    unsigned state = STATE_DOMAIN;
+    unsigned dom, bus, dev, func, vslot = 0;
+    char *buf2, *tok, *ptr, *end, *optkey = NULL;
+
+    if ( NULL == (buf2 = ptr = strdup(str)) )
+        return ERROR_NOMEM;
+
+    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
+        switch(state) {
+        case STATE_DOMAIN:
+            if ( *ptr == ':' ) {
+                state = STATE_BUS;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dom, 0xffff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_BUS:
+            if ( *ptr == ':' ) {
+                state = STATE_DEV;
+                *ptr = '\0';
+                if ( hex_convert(tok, &bus, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }else if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( dom & ~0xff )
+                    goto parse_error;
+                bus = dom;
+                dom = 0;
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_DEV:
+            if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_FUNC:
+            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
+                switch( *ptr ) {
+                case '\0':
+                    state = STATE_TERMINAL;
+                    break;
+                case '@':
+                    state = STATE_VSLOT;
+                    break;
+                case ',':
+                    state = STATE_OPTIONS_K;
+                    break;
+                }
+                *ptr = '\0';
+                if ( !strcmp(tok, "*") ) {
+                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
+                }else{
+                    if ( hex_convert(tok, &func, 0x7) )
+                        goto parse_error;
+                    pcidev->vfunc_mask = (1 << 0);
+                }
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_VSLOT:
+            if ( *ptr == '\0' || *ptr == ',' ) {
+                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( hex_convert(tok, &vslot, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_K:
+            if ( *ptr == '=' ) {
+                state = STATE_OPTIONS_V;
+                *ptr = '\0';
+                optkey = tok;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_V:
+            if ( *ptr == ',' || *ptr == '\0' ) {
+                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( !strcmp(optkey, "msitranslate") ) {
+                    pcidev->msitranslate = atoi(tok);
+                }else if ( !strcmp(optkey, "power_mgmt") ) {
+                    pcidev->power_mgmt = atoi(tok);
+                }else{
+                    XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
+                }
+                tok = ptr + 1;
+            }
+        default:
+            break;
+        }
+    }
+
+    free(buf2);
+
+    if ( tok != ptr || state != STATE_TERMINAL )
+        goto parse_error;
+
+    /* Just a pretty way to fill in the values */
+    libxl_pci_dev_init(pcidev, dom, bus, dev, func, vslot << 3);
+
+    return 0;
+
+parse_error:
+    return ERROR_INVAL;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxlutil.h	Mon Apr 02 11:29:34 2012 +0100
@@ -88,6 +88,16 @@ int xlu_disk_parse(XLU_Config *cfg, int 
    * resulting disk struct is used with libxl.
    */
 
+/*
+ * PCI specification parsing
+ */
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str);
+/* */ 
+
+int xlu_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
+                     unsigned int bus, unsigned int dev,
+                     unsigned int func, unsigned int vdevfn);
+
 
 #endif /* LIBXLUTIL_H */
 
diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 02 11:29:34 2012 +0100
@@ -1005,7 +1005,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
-            if (!libxl_device_pci_parse_bdf(ctx, pcidev, buf))
+            if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -2217,11 +2217,16 @@ int main_pcilist(int argc, char **argv)
 static void pcidetach(const char *dom, const char *bdf, int force)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+    
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-detach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
@@ -2257,11 +2262,16 @@ int main_pcidetach(int argc, char **argv
 static void pciattach(const char *dom, const char *bdf, const char *vs)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-attach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
diff -r f744e82ea740 -r 5386937e6c5c tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Apr 02 11:29:34 2012 +0100
@@ -40,6 +40,7 @@
 
 #include <libxl.h>
 #include <libxl_utils.h>
+#include <libxlutil.h>
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
@@ -556,7 +557,7 @@ static PyObject *pyxl_pci_parse(XlObject
         return NULL;
     }
 
-    if ( libxl_device_pci_parse_bdf(self->ctx, &pci->obj, str) ) {
+    if ( xlu_pci_parse_bdf(NULL, &pci->obj, str) ) {
         PyErr_SetString(xl_error_obj, "cannot parse pci device spec (BDF)");
         Py_DECREF(pci);
         return NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer6-0007Do-Tw; Mon, 02 Apr 2012 10:51:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEer4-0007Cp-Ry
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:23 +0000
Received: from [193.109.254.147:33821] by server-9.bemta-14.messagelabs.com id
	EE/20-05787-AA4897F4; Mon, 02 Apr 2012 10:51:22 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333363877!2959994!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3824 invoked from network); 2 Apr 2012 10:51:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621058"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:50 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SEeqY-0000P6-4T;
	Mon, 02 Apr 2012 11:50:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 62b1030a2485536caf995b825bee9e8255f914b3
Message-ID: <62b1030a2485536caf99.1333363657@kodo2>
In-Reply-To: <patchbomb.1333363655@kodo2>
References: <patchbomb.1333363655@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 2 Apr 2012 11:47:37 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1333363500 -3600
# Node ID 62b1030a2485536caf995b825bee9e8255f914b3
# Parent  5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
xl,libxl: Add per-device and global permissive config options for pci passthrough

By default pciback only allows PV guests to write "known safe" values into
PCI config space.  But many devices require writes to other areas of config
space in order to operate properly.  One way to do that is with the "quirks"
interface, which specifies areas known safe to a particular device; the
other way is to mark a device as "permissive", which tells pciback to allow
all config space writes for that domain and device.

This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
to write the appropriate value into sysfs to enable the permissive feature for
devices being passed through.  It also adds the permissive config options either
on a per-device basis, or as a global option in the xl command-line.

Because of the potential stability and security implications of enabling
permissive, the flag is left off by default.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5386937e6c5c -r 62b1030a2485 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Apr 02 11:29:34 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Mon Apr 02 11:45:00 2012 +0100
@@ -294,10 +294,25 @@ XXX
 
 XXX
 
+=item B<permissive=BOOLEAN>
+
+By default pciback only allows PV guests to write "known safe" values into
+PCI config space.  But many devices require writes to other areas of config
+space in order to operate properly.  This tells the pciback driver to
+allow all writes to PCI config space for this domain and this device.  This
+option should be enabled with caution, as there may be stability or security 
+implications of doing so.
+
 =back
 
 =back
 
+=item B<pci_permissive=BOOLEAN>
+
+Changes the default value of 'permissive' for all PCI devices for this
+VM.  This can still be overriden on a per-device basis. See the
+"pci=" section for more information on the "permissive" flag.
+
 =back
 
 =head2 Paravirtualised (PV) Guest Specific Options
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
@@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
     if (pcidev->vdevfn)
         flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
     flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
-    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
+    flexarray_append(back,
+              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
+                             pcidev->msitranslate, pcidev->power_mgmt,
+                             pcidev->permissive));
     flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
 }
 
@@ -565,6 +568,29 @@ static int do_pci_add(libxl__gc *gc, uin
             }
         }
         fclose(f);
+
+        /* Don't restrict writes to the PCI config space from this VM */
+        if (pcidev->permissive) {
+            int fd;
+            char *buf;
+
+            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
+            fd = open(sysfs_path, O_WRONLY);
+            if (fd < 0) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
+                                 sysfs_path);
+                goto out;
+            }
+ 
+            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
+                                 pcidev->dev, pcidev->func);
+            rc = write(fd, buf, strlen(buf));
+            if (rc < 0)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
+                                 sysfs_path, rc);
+            close(fd);
+            goto out;
+        }
         break;
     }
     default:
@@ -958,6 +984,9 @@ static void libxl__device_pci_from_xs_be
             } else if (!strcmp(p, "power_mgmt")) {
                 p = strtok_r(NULL, ",=", &saveptr);
                 pci->power_mgmt = atoi(p);
+            } else if (!strcmp(p, "permissive")) {
+                p = strtok_r(NULL, ",=", &saveptr);
+                pci->permissive = atoi(p);
             }
         } while ((p = strtok_r(NULL, ",=", &saveptr)) != NULL);
     }
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Apr 02 11:45:00 2012 +0100
@@ -352,6 +352,7 @@ libxl_device_pci = Struct("device_pci", 
     ("vfunc_mask", uint32),
     ("msitranslate", bool),
     ("power_mgmt", bool),
+    ("permissive", bool),
     ])
 
 libxl_diskinfo = Struct("diskinfo", [
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxlu_pci.c
--- a/tools/libxl/libxlu_pci.c	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/libxlu_pci.c	Mon Apr 02 11:45:00 2012 +0100
@@ -127,6 +127,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, l
                     pcidev->msitranslate = atoi(tok);
                 }else if ( !strcmp(optkey, "power_mgmt") ) {
                     pcidev->power_mgmt = atoi(tok);
+                }else if ( !strcmp(optkey, "permissive") ) {
+                    pcidev->permissive = atoi(tok);
                 }else{
                     XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
                 }
diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Apr 02 11:29:34 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 02 11:45:00 2012 +0100
@@ -518,6 +518,7 @@ static void parse_config_data(const char
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
+    int pci_permissive = 0;
     int e;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -986,6 +987,9 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
+    if (!xlu_cfg_get_long (config, "pci_permissive", &l, 0))
+        pci_permissive = l;
+
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1005,6 +1009,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
+            pcidev->permissive = pci_permissive;
             if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer7-0007EK-NP; Mon, 02 Apr 2012 10:51:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEer5-0007Cu-7s
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:23 +0000
Received: from [193.109.254.147:33849] by server-11.bemta-14.messagelabs.com
	id 70/21-05858-AA4897F4; Mon, 02 Apr 2012 10:51:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333363880!3021527!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29470 invoked from network); 2 Apr 2012 10:51:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621063"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-AR;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:33 +0100
Message-ID: <1333363834-2520-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] arm: add dom0_mem command line argument
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add a simple dom0_mem command line argument.  It's not as flexible as
the x86 equivalent (the 'max' and 'min' prefixes are not supported).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 5e15476..2b5406d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -17,6 +17,17 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+#define DOM0_MEM_DEFAULT 0x8000000 /* 128 MiB */
+static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+
+static void __init parse_dom0_mem(const char *s)
+{
+    dom0_mem = parse_size_and_unit(s, &s);
+    if ( dom0_mem == 0 )
+        dom0_mem = DOM0_MEM_DEFAULT;
+}
+custom_param("dom0_mem", parse_dom0_mem);
+
 /*
  * Amount of extra space required to dom0's device tree.  No new nodes
  * are added (yet) but one terminating reserve map entry (16 bytes) is
@@ -191,6 +202,8 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
     int new_size;
     int ret;
 
+    kinfo->unassigned_mem = dom0_mem;
+
     fdt = device_tree_flattened;
 
     new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
@@ -262,8 +275,6 @@ int construct_dom0(struct domain *d)
     if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    kinfo.unassigned_mem = 0x08000000; /* XXX */
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:51:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEer7-0007EK-NP; Mon, 02 Apr 2012 10:51:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEer5-0007Cu-7s
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:51:23 +0000
Received: from [193.109.254.147:33849] by server-11.bemta-14.messagelabs.com
	id 70/21-05858-AA4897F4; Mon, 02 Apr 2012 10:51:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333363880!3021527!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29470 invoked from network); 2 Apr 2012 10:51:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330923600"; d="scan'208";a="188621063"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 06:50:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 06:50:52 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SEeqa-0000PD-AR;
	Mon, 02 Apr 2012 11:50:52 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 2 Apr 2012 11:50:33 +0100
Message-ID: <1333363834-2520-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] arm: add dom0_mem command line argument
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add a simple dom0_mem command line argument.  It's not as flexible as
the x86 equivalent (the 'max' and 'min' prefixes are not supported).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 5e15476..2b5406d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -17,6 +17,17 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+#define DOM0_MEM_DEFAULT 0x8000000 /* 128 MiB */
+static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+
+static void __init parse_dom0_mem(const char *s)
+{
+    dom0_mem = parse_size_and_unit(s, &s);
+    if ( dom0_mem == 0 )
+        dom0_mem = DOM0_MEM_DEFAULT;
+}
+custom_param("dom0_mem", parse_dom0_mem);
+
 /*
  * Amount of extra space required to dom0's device tree.  No new nodes
  * are added (yet) but one terminating reserve map entry (16 bytes) is
@@ -191,6 +202,8 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
     int new_size;
     int ret;
 
+    kinfo->unassigned_mem = dom0_mem;
+
     fdt = device_tree_flattened;
 
     new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
@@ -262,8 +275,6 @@ int construct_dom0(struct domain *d)
     if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    kinfo.unassigned_mem = 0x08000000; /* XXX */
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:55:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEevA-00089J-L4; Mon, 02 Apr 2012 10:55:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEev8-00088z-IV
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:55:34 +0000
Received: from [85.158.139.83:39367] by server-5.bemta-5.messagelabs.com id
	32/E0-13566-5A5897F4; Mon, 02 Apr 2012 10:55:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333364133!21963013!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22309 invoked from network); 2 Apr 2012 10:55:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:55:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11718850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:55:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 11:55:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEev6-0005cR-L5;
	Mon, 02 Apr 2012 10:55:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEev6-00007c-B8;
	Mon, 02 Apr 2012 11:55:32 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12542-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 11:55:32 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12542: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12542 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12542/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 12534
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12529

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  1088c8557a46
baseline version:
 xen                  1088c8557a46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 10:55:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 10:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEevA-00089J-L4; Mon, 02 Apr 2012 10:55:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEev8-00088z-IV
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 10:55:34 +0000
Received: from [85.158.139.83:39367] by server-5.bemta-5.messagelabs.com id
	32/E0-13566-5A5897F4; Mon, 02 Apr 2012 10:55:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333364133!21963013!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22309 invoked from network); 2 Apr 2012 10:55:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 10:55:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11718850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:55:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 11:55:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEev6-0005cR-L5;
	Mon, 02 Apr 2012 10:55:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEev6-00007c-B8;
	Mon, 02 Apr 2012 11:55:32 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12542-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 11:55:32 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12542: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12542 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12542/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 12534
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12529

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  1088c8557a46
baseline version:
 xen                  1088c8557a46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:05:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEf4x-00005i-TZ; Mon, 02 Apr 2012 11:05:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEf4w-00005d-5X
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 11:05:42 +0000
Received: from [85.158.143.99:24849] by server-3.bemta-4.messagelabs.com id
	1A/4A-05853-508897F4; Mon, 02 Apr 2012 11:05:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333364739!16632029!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22575 invoked from network); 2 Apr 2012 11:05:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 11:05:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11719085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:05:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	12:05:38 +0100
Message-ID: <1333364737.25602.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Mon, 2 Apr 2012 12:05:37 +0100
In-Reply-To: <5386937e6c5c9afaa8a3.1333363656@kodo2>
References: <patchbomb.1333363655@kodo2>
	<5386937e6c5c9afaa8a3.1333363656@kodo2>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1333362574 -3600
> # Node ID 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
> # Parent  f744e82ea74075983de6d5b0ad0cf7ccacf999a2
> libxl: Move bdf parsing into libxlu
> 
> Config parsing functions do not properly belong in libxl.  Move them into
> libxlu so that others can use them or not as they see fit.
> 
> No functional changes.  One side-effect was making public a private libxl
> utility function which just set the elements of a structure from the  function
> arguments passed in.
> [...]
> diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h       Wed Feb 29 16:30:34 2012 +0000
> +++ b/tools/libxl/libxl.h       Mon Apr 02 11:29:34 2012 +0100
> @@ -573,13 +573,10 @@ int libxl_device_pci_add(libxl_ctx *ctx,
>  int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>  int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>  libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
> -
> -/*
> - * Parse a PCI BDF into a PCI device structure.
> - */
> -int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
> -                               libxl_device_pci *pcidev,
> -                               const char *str);
> +/* Just initialize the structure elements with the arguments provided. */
> +int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
> +                       unsigned int bus, unsigned int dev,
> +                       unsigned int func, unsigned int vdevfn);

libxl_<type>_init has a particular meaning described further up in this
header. Although you haven't actually used <type> here so it doesn't
conflict the general convention is to use the type name as a prefix.

Does this function actually add all that much value? The users of it
could either open code it or have a local version.

Otherwise I think this patch looks good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:05:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEf4x-00005i-TZ; Mon, 02 Apr 2012 11:05:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEf4w-00005d-5X
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 11:05:42 +0000
Received: from [85.158.143.99:24849] by server-3.bemta-4.messagelabs.com id
	1A/4A-05853-508897F4; Mon, 02 Apr 2012 11:05:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333364739!16632029!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22575 invoked from network); 2 Apr 2012 11:05:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 11:05:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,356,1330905600"; d="scan'208";a="11719085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:05:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	12:05:38 +0100
Message-ID: <1333364737.25602.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Mon, 2 Apr 2012 12:05:37 +0100
In-Reply-To: <5386937e6c5c9afaa8a3.1333363656@kodo2>
References: <patchbomb.1333363655@kodo2>
	<5386937e6c5c9afaa8a3.1333363656@kodo2>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1333362574 -3600
> # Node ID 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
> # Parent  f744e82ea74075983de6d5b0ad0cf7ccacf999a2
> libxl: Move bdf parsing into libxlu
> 
> Config parsing functions do not properly belong in libxl.  Move them into
> libxlu so that others can use them or not as they see fit.
> 
> No functional changes.  One side-effect was making public a private libxl
> utility function which just set the elements of a structure from the  function
> arguments passed in.
> [...]
> diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h       Wed Feb 29 16:30:34 2012 +0000
> +++ b/tools/libxl/libxl.h       Mon Apr 02 11:29:34 2012 +0100
> @@ -573,13 +573,10 @@ int libxl_device_pci_add(libxl_ctx *ctx,
>  int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>  int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>  libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
> -
> -/*
> - * Parse a PCI BDF into a PCI device structure.
> - */
> -int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
> -                               libxl_device_pci *pcidev,
> -                               const char *str);
> +/* Just initialize the structure elements with the arguments provided. */
> +int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
> +                       unsigned int bus, unsigned int dev,
> +                       unsigned int func, unsigned int vdevfn);

libxl_<type>_init has a particular meaning described further up in this
header. Although you haven't actually used <type> here so it doesn't
conflict the general convention is to use the type name as a prefix.

Does this function actually add all that much value? The users of it
could either open code it or have a local version.

Otherwise I think this patch looks good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:18:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEfGE-0000XN-3m; Mon, 02 Apr 2012 11:17:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SEfGB-0000XF-Vb
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 11:17:20 +0000
Received: from [85.158.143.35:41862] by server-3.bemta-4.messagelabs.com id
	8A/9D-05853-FBA897F4; Mon, 02 Apr 2012 11:17:19 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333365437!10574666!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9963 invoked from network); 2 Apr 2012 11:17:18 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 11:17:18 -0000
Received: by qcsc20 with SMTP id c20so1804916qcs.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 04:17:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=QfdzcuYKexa/aIfGbQ0EBgwHG2jBj+YL75Ge1zG9V0c=;
	b=j/7SwscjR/sQNv2S6p/+sgADu2QERZAeFLbKuGnlG3rekf7SwNMabgw7CrLY8xcoN9
	jmsJs5mY1LeRoRYpjnRE6vMnLzkqQ3OH8vEa5LYimz6mpigdD6bsnxZ/dbFh0eEuy4m3
	JvkAKWsYtMb1DyWPlOkp7CIqvOdzrv99PHx7FPrdVLguag/6766vi8t6nW/bK/NEp6io
	Lx/D7d5WNdUkLxDfA6aSz0SpJ1I18Bp+ZeY6UoceftHh3Po8pbT9vlxQEnxG/fTxbN7J
	iUp8cfzel5Lbz3HvaPREPVsC9BKuDSVffgWq2PQNwah4eCgiQyo5+2909HpX6oj8iFcQ
	3s6g==
MIME-Version: 1.0
Received: by 10.224.96.66 with SMTP id g2mr10626075qan.47.1333365436966; Mon,
	02 Apr 2012 04:17:16 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Mon, 2 Apr 2012 04:17:16 -0700 (PDT)
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
Date: Mon, 2 Apr 2012 12:17:16 +0100
X-Google-Sender-Auth: 2pHD7QncvOQ5BcA0oZgSm2hYF1M
Message-ID: <CAFLBxZbohQjDJdddTOd6S+k4JqqOGo_ZMynALR8CdhYsk-rbgw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 2, 2012 at 11:26 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March =A0 =A0 =A0 =A0-- TODO list locked down
> 2 April =A0 =A0 =A0 =A0 -- Feature Freeze =A0 =A0 =A0 =A0 =A0 =A0 =A0 << =
WE ARE HERE
> Mid/Late April =A0-- First release candidate
> Weekly =A0 =A0 =A0 =A0 =A0-- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> hypervisor, blockers:
> =A0 =A0 =A0* NONE?
>
> tools, blockers:
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. Involves AP=
I changes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* locking/serialization, e.g., for domain crea=
tion. As of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0now, =A0nothing is provided for this purpo=
se, and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstream toolstacks have to put their ow=
n mechanisms
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in place. E.g., xl uses a fcntl() lock aro=
und the whole
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0process of domain creation. It should OTOH=
 be libxl job
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to offer a proper set of hooks --placed at=
 the proper
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spots during the domain creation process--=
 for the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstreams to =A0fill with the proper cal=
lbacks. (Dario
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Faggioli)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* agree & document compatibility guarantees + =
associated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0technical measures (Ian C, patches posted)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* feature parity wrt driver domain support (Ge=
orge Dunlap)

The only thing missing is the pci "permissive" flag.  Patches posted.

> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for "rtc_timeoffset" and "localti=
me" (Lin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ming, Patches posted)
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
> =A0 =A0 =A0* Domain 0 block attach & general hotplug when using qdisk bac=
kend
> =A0 =A0 =A0 =A0(need to start qemu as necessary etc) (Stefano S)
> =A0 =A0 =A0* file:// backend performance. qemu-xen-tradition's qdisk is q=
uite
> =A0 =A0 =A0 =A0slow & blktap2 not available in upstream kernels. Need to
> =A0 =A0 =A0 =A0consider our options:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen's qdisk is thought to be well perfo=
rming but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0qemu-xen is not yet the default. Complexit=
y arising from
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0splitting qemu-for-qdisk out from qemu-for=
-dm and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0running N qemu's.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* potentially fully userspace blktap could be =
ready for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04.2
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* use /dev/loop+blkback. This requires loop dr=
iver AIO and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O_DIRECT patches which are not (AFAIK) yet=
 upstream.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Leverage XCP's blktap2 DKMS work.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Other ideas?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* In general we should recomme=
nd blkback (e.g.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with LVM) since it always =
out performs other
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0solutions, although at the=
 expense of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flexibility regarding imag=
e formats.
> =A0 =A0 =A0 =A0Stefano has done a lot of work here and has proposed some
> =A0 =A0 =A0 =A0performance improvements for qdisk in both qemu-xen and
> =A0 =A0 =A0 =A0qemu-xen-traditional which make them a plausible alternati=
ve for
> =A0 =A0 =A0 =A0Xen 4.2.
> =A0 =A0 =A0* Improved Hotplug script support (Roger Pau Monn=E9, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
>
> hypervisor, nice to have:
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "The last patch to use a waitqueue in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__get_gfn_type_access() from Tim works. =
=A0However, there
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are a few users who call __get_gfn_type_ac=
cess with the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_lock held. This part needs to be ad=
dressed in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some way."
> =A0 =A0 =A0* Sharing support for AMD (Tim, Andres).
> =A0 =A0 =A0* PoD performance improvements (George Dunlap)
>
> tools, nice to have:
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring, lots of
> =A0 =A0 =A0 =A0discussion around interface, general consensus reached on =
what
> =A0 =A0 =A0 =A0it should look like. Olaf has let me know that he is proba=
bly
> =A0 =A0 =A0 =A0not going to have time to do this for 4.2, will likely sli=
p to
> =A0 =A0 =A0 =A04.3 unless someone else want to pick up that work)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, qemu patches applied, waiting =
for libxl etc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0side which has been recently reposted)
> =A0 =A0 =A0* Nested-virtualisation. Currently "experimental". Likely to
> =A0 =A0 =A0 =A0release that way.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested SVM. Tested in a variety of configura=
tions but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still some issues with the most important =
use case (w7
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XP mode) [0] =A0(Christoph Egger)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested VMX. Needs nested EPT to be genuinely=
 useful.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Need more data on testedness etc (Intel)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, patches reposted recently, was blocked behind qe=
mu
> =A0 =A0 =A0 =A0save restore patches which are now in)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for autospawning vncviewer (vncvi=
ewer=3D1 or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise) (Goncalo Gomes, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga=
gn=E9, patches
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor=
ge Dunlap)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:18:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEfGE-0000XN-3m; Mon, 02 Apr 2012 11:17:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SEfGB-0000XF-Vb
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 11:17:20 +0000
Received: from [85.158.143.35:41862] by server-3.bemta-4.messagelabs.com id
	8A/9D-05853-FBA897F4; Mon, 02 Apr 2012 11:17:19 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333365437!10574666!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9963 invoked from network); 2 Apr 2012 11:17:18 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 11:17:18 -0000
Received: by qcsc20 with SMTP id c20so1804916qcs.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 04:17:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=QfdzcuYKexa/aIfGbQ0EBgwHG2jBj+YL75Ge1zG9V0c=;
	b=j/7SwscjR/sQNv2S6p/+sgADu2QERZAeFLbKuGnlG3rekf7SwNMabgw7CrLY8xcoN9
	jmsJs5mY1LeRoRYpjnRE6vMnLzkqQ3OH8vEa5LYimz6mpigdD6bsnxZ/dbFh0eEuy4m3
	JvkAKWsYtMb1DyWPlOkp7CIqvOdzrv99PHx7FPrdVLguag/6766vi8t6nW/bK/NEp6io
	Lx/D7d5WNdUkLxDfA6aSz0SpJ1I18Bp+ZeY6UoceftHh3Po8pbT9vlxQEnxG/fTxbN7J
	iUp8cfzel5Lbz3HvaPREPVsC9BKuDSVffgWq2PQNwah4eCgiQyo5+2909HpX6oj8iFcQ
	3s6g==
MIME-Version: 1.0
Received: by 10.224.96.66 with SMTP id g2mr10626075qan.47.1333365436966; Mon,
	02 Apr 2012 04:17:16 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Mon, 2 Apr 2012 04:17:16 -0700 (PDT)
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
Date: Mon, 2 Apr 2012 12:17:16 +0100
X-Google-Sender-Auth: 2pHD7QncvOQ5BcA0oZgSm2hYF1M
Message-ID: <CAFLBxZbohQjDJdddTOd6S+k4JqqOGo_ZMynALR8CdhYsk-rbgw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 2, 2012 at 11:26 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March =A0 =A0 =A0 =A0-- TODO list locked down
> 2 April =A0 =A0 =A0 =A0 -- Feature Freeze =A0 =A0 =A0 =A0 =A0 =A0 =A0 << =
WE ARE HERE
> Mid/Late April =A0-- First release candidate
> Weekly =A0 =A0 =A0 =A0 =A0-- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> hypervisor, blockers:
> =A0 =A0 =A0* NONE?
>
> tools, blockers:
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. Involves AP=
I changes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* locking/serialization, e.g., for domain crea=
tion. As of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0now, =A0nothing is provided for this purpo=
se, and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstream toolstacks have to put their ow=
n mechanisms
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in place. E.g., xl uses a fcntl() lock aro=
und the whole
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0process of domain creation. It should OTOH=
 be libxl job
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to offer a proper set of hooks --placed at=
 the proper
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spots during the domain creation process--=
 for the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstreams to =A0fill with the proper cal=
lbacks. (Dario
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Faggioli)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* agree & document compatibility guarantees + =
associated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0technical measures (Ian C, patches posted)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* feature parity wrt driver domain support (Ge=
orge Dunlap)

The only thing missing is the pci "permissive" flag.  Patches posted.

> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for "rtc_timeoffset" and "localti=
me" (Lin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ming, Patches posted)
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
> =A0 =A0 =A0* Domain 0 block attach & general hotplug when using qdisk bac=
kend
> =A0 =A0 =A0 =A0(need to start qemu as necessary etc) (Stefano S)
> =A0 =A0 =A0* file:// backend performance. qemu-xen-tradition's qdisk is q=
uite
> =A0 =A0 =A0 =A0slow & blktap2 not available in upstream kernels. Need to
> =A0 =A0 =A0 =A0consider our options:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen's qdisk is thought to be well perfo=
rming but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0qemu-xen is not yet the default. Complexit=
y arising from
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0splitting qemu-for-qdisk out from qemu-for=
-dm and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0running N qemu's.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* potentially fully userspace blktap could be =
ready for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04.2
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* use /dev/loop+blkback. This requires loop dr=
iver AIO and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O_DIRECT patches which are not (AFAIK) yet=
 upstream.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Leverage XCP's blktap2 DKMS work.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Other ideas?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* In general we should recomme=
nd blkback (e.g.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with LVM) since it always =
out performs other
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0solutions, although at the=
 expense of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flexibility regarding imag=
e formats.
> =A0 =A0 =A0 =A0Stefano has done a lot of work here and has proposed some
> =A0 =A0 =A0 =A0performance improvements for qdisk in both qemu-xen and
> =A0 =A0 =A0 =A0qemu-xen-traditional which make them a plausible alternati=
ve for
> =A0 =A0 =A0 =A0Xen 4.2.
> =A0 =A0 =A0* Improved Hotplug script support (Roger Pau Monn=E9, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
>
> hypervisor, nice to have:
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "The last patch to use a waitqueue in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__get_gfn_type_access() from Tim works. =
=A0However, there
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are a few users who call __get_gfn_type_ac=
cess with the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_lock held. This part needs to be ad=
dressed in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some way."
> =A0 =A0 =A0* Sharing support for AMD (Tim, Andres).
> =A0 =A0 =A0* PoD performance improvements (George Dunlap)
>
> tools, nice to have:
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring, lots of
> =A0 =A0 =A0 =A0discussion around interface, general consensus reached on =
what
> =A0 =A0 =A0 =A0it should look like. Olaf has let me know that he is proba=
bly
> =A0 =A0 =A0 =A0not going to have time to do this for 4.2, will likely sli=
p to
> =A0 =A0 =A0 =A04.3 unless someone else want to pick up that work)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, qemu patches applied, waiting =
for libxl etc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0side which has been recently reposted)
> =A0 =A0 =A0* Nested-virtualisation. Currently "experimental". Likely to
> =A0 =A0 =A0 =A0release that way.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested SVM. Tested in a variety of configura=
tions but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still some issues with the most important =
use case (w7
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XP mode) [0] =A0(Christoph Egger)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested VMX. Needs nested EPT to be genuinely=
 useful.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Need more data on testedness etc (Intel)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, patches reposted recently, was blocked behind qe=
mu
> =A0 =A0 =A0 =A0save restore patches which are now in)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for autospawning vncviewer (vncvi=
ewer=3D1 or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise) (Goncalo Gomes, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga=
gn=E9, patches
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor=
ge Dunlap)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:30:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEfT1-0000k2-DT; Mon, 02 Apr 2012 11:30:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEfSz-0000jx-TQ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 11:30:34 +0000
Received: from [193.109.254.147:63598] by server-7.bemta-14.messagelabs.com id
	55/4F-01627-9DD897F4; Mon, 02 Apr 2012 11:30:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333366221!2966627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21050 invoked from network); 2 Apr 2012 11:30:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 11:30:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11719618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:30:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	12:30:21 +0100
Message-ID: <1333366219.25602.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Mon, 2 Apr 2012 12:30:19 +0100
In-Reply-To: <62b1030a2485536caf99.1333363657@kodo2>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1333363500 -3600
> # Node ID 62b1030a2485536caf995b825bee9e8255f914b3
> # Parent  5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
> xl,libxl: Add per-device and global permissive config options for pci passthrough
> 
> By default pciback only allows PV guests to write "known safe" values into
> PCI config space.  But many devices require writes to other areas of config
> space in order to operate properly.  One way to do that is with the "quirks"
> interface, which specifies areas known safe to a particular device; the
> other way is to mark a device as "permissive", which tells pciback to allow
> all config space writes for that domain and device.
> 
> This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
> to write the appropriate value into sysfs to enable the permissive feature for
> devices being passed through.  It also adds the permissive config options either
> on a per-device basis, or as a global option in the xl command-line.
> 
> Because of the potential stability and security implications of enabling
> permissive, the flag is left off by default.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 5386937e6c5c -r 62b1030a2485 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Mon Apr 02 11:29:34 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Mon Apr 02 11:45:00 2012 +0100
> @@ -294,10 +294,25 @@ XXX
>  
>  XXX
>  
> +=item B<permissive=BOOLEAN>
> +
> +By default pciback only allows PV guests to write "known safe" values into
> +PCI config space.  But many devices require writes to other areas of config
> +space in order to operate properly.  This tells the pciback driver to
> +allow all writes to PCI config space for this domain and this device.  This
> +option should be enabled with caution, as there may be stability or security 
> +implications of doing so.
> +
>  =back
>  
>  =back
>  
> +=item B<pci_permissive=BOOLEAN>
> +
> +Changes the default value of 'permissive' for all PCI devices for this
> +VM.  This can still be overriden on a per-device basis. See the
> +"pci=" section for more information on the "permissive" flag.
> +
>  =back
>  
>  =head2 Paravirtualised (PV) Guest Specific Options
> diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
> @@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
>      if (pcidev->vdevfn)
>          flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
>      flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
> -    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
> +    flexarray_append(back,
> +              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
> +                             pcidev->msitranslate, pcidev->power_mgmt,
> +                             pcidev->permissive));

Since we are already writing this key, and AFAICT this matches xend's
behaviour, I think it is correct to add the new parameter here. But...

Does anything actually read this key? I can't find anything in pciback
or qemu. 

>      flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
>  }
>  
> @@ -565,6 +568,29 @@ static int do_pci_add(libxl__gc *gc, uin
>              }
>          }
>          fclose(f);
> +
> +        /* Don't restrict writes to the PCI config space from this VM */
> +        if (pcidev->permissive) {
> +            int fd;
> +            char *buf;
> +
> +            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
> +            fd = open(sysfs_path, O_WRONLY);
> +            if (fd < 0) {
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
> +                                 sysfs_path);
> +                goto out;

Why not either fall through (i.e. accept this as a soft failure) or
return an actual error here?

FWIW I think the case where we cannot open the sysfs "irq" node and
"goto out" is also similarly wrong.

> +            }
> + 
> +            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
> +                                 pcidev->dev, pcidev->func);
> +            rc = write(fd, buf, strlen(buf));
> +            if (rc < 0)
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
> +                                 sysfs_path, rc);
> +            close(fd);
> +            goto out;

I don't think this makes sense, out is the next thing we actually get to
anyway and there is a "break" out of the switch right below.

> +        }
>          break;
>      }
>      default:

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:30:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEfT1-0000k2-DT; Mon, 02 Apr 2012 11:30:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEfSz-0000jx-TQ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 11:30:34 +0000
Received: from [193.109.254.147:63598] by server-7.bemta-14.messagelabs.com id
	55/4F-01627-9DD897F4; Mon, 02 Apr 2012 11:30:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333366221!2966627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21050 invoked from network); 2 Apr 2012 11:30:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 11:30:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11719618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:30:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	12:30:21 +0100
Message-ID: <1333366219.25602.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Mon, 2 Apr 2012 12:30:19 +0100
In-Reply-To: <62b1030a2485536caf99.1333363657@kodo2>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1333363500 -3600
> # Node ID 62b1030a2485536caf995b825bee9e8255f914b3
> # Parent  5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
> xl,libxl: Add per-device and global permissive config options for pci passthrough
> 
> By default pciback only allows PV guests to write "known safe" values into
> PCI config space.  But many devices require writes to other areas of config
> space in order to operate properly.  One way to do that is with the "quirks"
> interface, which specifies areas known safe to a particular device; the
> other way is to mark a device as "permissive", which tells pciback to allow
> all config space writes for that domain and device.
> 
> This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
> to write the appropriate value into sysfs to enable the permissive feature for
> devices being passed through.  It also adds the permissive config options either
> on a per-device basis, or as a global option in the xl command-line.
> 
> Because of the potential stability and security implications of enabling
> permissive, the flag is left off by default.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 5386937e6c5c -r 62b1030a2485 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Mon Apr 02 11:29:34 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Mon Apr 02 11:45:00 2012 +0100
> @@ -294,10 +294,25 @@ XXX
>  
>  XXX
>  
> +=item B<permissive=BOOLEAN>
> +
> +By default pciback only allows PV guests to write "known safe" values into
> +PCI config space.  But many devices require writes to other areas of config
> +space in order to operate properly.  This tells the pciback driver to
> +allow all writes to PCI config space for this domain and this device.  This
> +option should be enabled with caution, as there may be stability or security 
> +implications of doing so.
> +
>  =back
>  
>  =back
>  
> +=item B<pci_permissive=BOOLEAN>
> +
> +Changes the default value of 'permissive' for all PCI devices for this
> +VM.  This can still be overriden on a per-device basis. See the
> +"pci=" section for more information on the "permissive" flag.
> +
>  =back
>  
>  =head2 Paravirtualised (PV) Guest Specific Options
> diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
> @@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
>      if (pcidev->vdevfn)
>          flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
>      flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
> -    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
> +    flexarray_append(back,
> +              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
> +                             pcidev->msitranslate, pcidev->power_mgmt,
> +                             pcidev->permissive));

Since we are already writing this key, and AFAICT this matches xend's
behaviour, I think it is correct to add the new parameter here. But...

Does anything actually read this key? I can't find anything in pciback
or qemu. 

>      flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
>  }
>  
> @@ -565,6 +568,29 @@ static int do_pci_add(libxl__gc *gc, uin
>              }
>          }
>          fclose(f);
> +
> +        /* Don't restrict writes to the PCI config space from this VM */
> +        if (pcidev->permissive) {
> +            int fd;
> +            char *buf;
> +
> +            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
> +            fd = open(sysfs_path, O_WRONLY);
> +            if (fd < 0) {
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
> +                                 sysfs_path);
> +                goto out;

Why not either fall through (i.e. accept this as a soft failure) or
return an actual error here?

FWIW I think the case where we cannot open the sysfs "irq" node and
"goto out" is also similarly wrong.

> +            }
> + 
> +            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
> +                                 pcidev->dev, pcidev->func);
> +            rc = write(fd, buf, strlen(buf));
> +            if (rc < 0)
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
> +                                 sysfs_path, rc);
> +            close(fd);
> +            goto out;

I don't think this makes sense, out is the next thing we actually get to
anyway and there is a "break" out of the switch right below.

> +        }
>          break;
>      }
>      default:

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEfXP-0000yd-Se; Mon, 02 Apr 2012 11:35:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEfXP-0000yT-3N
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 11:35:07 +0000
Received: from [85.158.138.51:60636] by server-8.bemta-3.messagelabs.com id
	25/85-29305-AEE897F4; Mon, 02 Apr 2012 11:35:06 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333366503!16173978!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22268 invoked from network); 2 Apr 2012 11:35:05 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Apr 2012 11:35:05 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEfXL-00024f-2f
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 04:35:03 -0700
Date: Mon, 2 Apr 2012 04:35:03 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333366503074-5612226.post@n5.nabble.com>
In-Reply-To: <1333120091665-5606945.post@n5.nabble.com>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Fantu wrote
>> 
>> For many years we used virtualization systems based on xen.
>> Up to now we did quite well despite same issue we are trying to solve
>> with the new version.
>> The main issue that we found are about Windows domU performance and the
>> thin client interface with rdp is sometimes problematic.
>> We think a possible solution to solve current shortcomings could be qemu
>> upstream with spice, qxl and USB redirection.
>> We have started preparing a new test system based on Wheezy, the upstream
>> kernel and xen 4.2.
>> The current test system is:
>> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
>> 3.2.12-1, package blktap-dkms and all dependency packages for xen spice
>> and usb redirection.
>> -------------------------
>> /etc/modules
>> ------------
>> loop max_loop=64
>> xenfs
>> xen-evtchn
>> blktap
>> -------------------------
>> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
>> 25070)
>> vi Makefile # removed dist-kernel to not compile kernel
>> -------------------------
>> vi Config.mk # qemu upstream unstable and seabios unstable
>> ------------
>> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
>> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
>> SEABIOS_UPSTREAM_TAG ?= master
>> QEMU_TAG ?= master
>> -------------------------
>> Added some patches:
>> - autoconf: add variable for pass arbitrary options to qemu upstream - my
>> patch to build spice and usbredirection on qemu upstream
>> - QEMU upstream need to kown the amount of RAM given to a guest. This
>> patch give
>> the correct value. - Anthony PERARD patch for try to solve ram/videoram
>> issue
>> - tools: specify datadir for qemu-xen build to fix firmware loading -
>> Olaf Hering patch for try to solve qxl issue
>> -------------------------
>> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
>> -------------------------
>> vi config/Tools.mk # workaround for libxl compilation problem
>> BISON               := bison
>> FLEX                := flex
>> -------------------------
>> make dist
>> ./install.sh
>> insserv xencommons &&
>> insserv xendomains
>> 
>> 
>> Result:
>> Full PV domU work, just minimal tests done.
>> HVM domU with qemu traditional works but with qemu upstream some problem
>> encountered.
>> For now I didn't find a way to make Windows run on qemu upstream and
>> nothing on logs.
>> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
>> Spice and usbrediction seem to be working in basic test done now, qxl
>> not.
>> 
>> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on start,
>> with qemu unstable it starts but with an allocation problem, on xorg log:
>> Out of video memory: Could not allocate 4198400 bytes
>> I tried to update also seabios to unstable but same problem.
>> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
>> 
>> Current xl domU configuration file:
>> -----------------------------------
>> name='PRECISEHVM'
>> builder="hvm"
>> memory=1024
>> #maxmem=1536
>> vcpus=2
>> #hap=1
>> #pae=1
>> #acpi=1
>> #apic=1
>> #nx=1
>> vif=['bridge=xenbr0']
>> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
>> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
>> '/dev/sr0,raw,hdb,ro,cdrom']
>> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
>> boot='c'
>> xen_platform_pci=1
>> device_model_version='qemu-xen'
>> vnc=0
>> #vncunused=1
>> #vnclisten="0.0.0.0"
>> #keymap="it"
>> #stdvga=1
>> #sdl=0
>> spice=1
>> spicehost='0.0.0.0'
>> spiceport=6000
>> spicedisable_ticketing=1
>> #spicepasswd='test'
>> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
>> device_model_args=["-vga qxl"]
>> #device_model_args=["-usb -device usb-ehci"]
>> #on_crash='preserve'
>> videoram=128
>> #bios="ovmf"
>> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
>>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
>> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
>>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
>> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
>>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
>> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
>> -----------------------------------
>> 
>> Can someone help to solve these issues?
>> Thanks for any reply.
>> 
> Today I have done other tests: windows xp sp3 installs and runs
> successfully on qemu upstream unstable.
> Vnc working but too slow, with stdvga improved but not optimal.
> Spice with qxl is working but with slow graphic performance. It seems to
> have only 4 mb videoram usable (seem to be same with Precise, see quote).
> 
> This is the current xl configuration:
> -------------------------------------
> name='XP'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> boot='d'
> xen_platform_pci=1
> viridian=1
> device_model_version="qemu-xen"
> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> vnc=0
> #vncunused=1
> #vnclisten="0.0.0.0"
> #keymap="it"
> spice=1
> spicehost="0.0.0.0"
> spiceport=6000
> spicedisable_ticketing=1
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> stdvga=0
> device_model_args=["-vga qxl"]
> videoram=128
> -------------------------------------
> 
Also Windows 7 is working with qemu upstream, with patches and workaround
applied probably, for details see the first post.

--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5612226.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 11:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 11:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEfXP-0000yd-Se; Mon, 02 Apr 2012 11:35:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEfXP-0000yT-3N
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 11:35:07 +0000
Received: from [85.158.138.51:60636] by server-8.bemta-3.messagelabs.com id
	25/85-29305-AEE897F4; Mon, 02 Apr 2012 11:35:06 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333366503!16173978!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22268 invoked from network); 2 Apr 2012 11:35:05 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Apr 2012 11:35:05 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEfXL-00024f-2f
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 04:35:03 -0700
Date: Mon, 2 Apr 2012 04:35:03 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333366503074-5612226.post@n5.nabble.com>
In-Reply-To: <1333120091665-5606945.post@n5.nabble.com>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Fantu wrote
>> 
>> For many years we used virtualization systems based on xen.
>> Up to now we did quite well despite same issue we are trying to solve
>> with the new version.
>> The main issue that we found are about Windows domU performance and the
>> thin client interface with rdp is sometimes problematic.
>> We think a possible solution to solve current shortcomings could be qemu
>> upstream with spice, qxl and USB redirection.
>> We have started preparing a new test system based on Wheezy, the upstream
>> kernel and xen 4.2.
>> The current test system is:
>> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
>> 3.2.12-1, package blktap-dkms and all dependency packages for xen spice
>> and usb redirection.
>> -------------------------
>> /etc/modules
>> ------------
>> loop max_loop=64
>> xenfs
>> xen-evtchn
>> blktap
>> -------------------------
>> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
>> 25070)
>> vi Makefile # removed dist-kernel to not compile kernel
>> -------------------------
>> vi Config.mk # qemu upstream unstable and seabios unstable
>> ------------
>> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
>> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
>> SEABIOS_UPSTREAM_TAG ?= master
>> QEMU_TAG ?= master
>> -------------------------
>> Added some patches:
>> - autoconf: add variable for pass arbitrary options to qemu upstream - my
>> patch to build spice and usbredirection on qemu upstream
>> - QEMU upstream need to kown the amount of RAM given to a guest. This
>> patch give
>> the correct value. - Anthony PERARD patch for try to solve ram/videoram
>> issue
>> - tools: specify datadir for qemu-xen build to fix firmware loading -
>> Olaf Hering patch for try to solve qxl issue
>> -------------------------
>> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
>> -------------------------
>> vi config/Tools.mk # workaround for libxl compilation problem
>> BISON               := bison
>> FLEX                := flex
>> -------------------------
>> make dist
>> ./install.sh
>> insserv xencommons &&
>> insserv xendomains
>> 
>> 
>> Result:
>> Full PV domU work, just minimal tests done.
>> HVM domU with qemu traditional works but with qemu upstream some problem
>> encountered.
>> For now I didn't find a way to make Windows run on qemu upstream and
>> nothing on logs.
>> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
>> Spice and usbrediction seem to be working in basic test done now, qxl
>> not.
>> 
>> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on start,
>> with qemu unstable it starts but with an allocation problem, on xorg log:
>> Out of video memory: Could not allocate 4198400 bytes
>> I tried to update also seabios to unstable but same problem.
>> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
>> 
>> Current xl domU configuration file:
>> -----------------------------------
>> name='PRECISEHVM'
>> builder="hvm"
>> memory=1024
>> #maxmem=1536
>> vcpus=2
>> #hap=1
>> #pae=1
>> #acpi=1
>> #apic=1
>> #nx=1
>> vif=['bridge=xenbr0']
>> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
>> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
>> '/dev/sr0,raw,hdb,ro,cdrom']
>> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
>> boot='c'
>> xen_platform_pci=1
>> device_model_version='qemu-xen'
>> vnc=0
>> #vncunused=1
>> #vnclisten="0.0.0.0"
>> #keymap="it"
>> #stdvga=1
>> #sdl=0
>> spice=1
>> spicehost='0.0.0.0'
>> spiceport=6000
>> spicedisable_ticketing=1
>> #spicepasswd='test'
>> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
>> device_model_args=["-vga qxl"]
>> #device_model_args=["-usb -device usb-ehci"]
>> #on_crash='preserve'
>> videoram=128
>> #bios="ovmf"
>> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
>>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
>> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
>>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
>> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
>>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
>> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
>> -----------------------------------
>> 
>> Can someone help to solve these issues?
>> Thanks for any reply.
>> 
> Today I have done other tests: windows xp sp3 installs and runs
> successfully on qemu upstream unstable.
> Vnc working but too slow, with stdvga improved but not optimal.
> Spice with qxl is working but with slow graphic performance. It seems to
> have only 4 mb videoram usable (seem to be same with Precise, see quote).
> 
> This is the current xl configuration:
> -------------------------------------
> name='XP'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> boot='d'
> xen_platform_pci=1
> viridian=1
> device_model_version="qemu-xen"
> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> vnc=0
> #vncunused=1
> #vnclisten="0.0.0.0"
> #keymap="it"
> spice=1
> spicehost="0.0.0.0"
> spiceport=6000
> spicedisable_ticketing=1
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> stdvga=0
> device_model_args=["-vga qxl"]
> videoram=128
> -------------------------------------
> 
Also Windows 7 is working with qemu upstream, with patches and workaround
applied probably, for details see the first post.

--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5612226.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 12:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 12:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEgCd-00020S-LW; Mon, 02 Apr 2012 12:17:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SEgCc-00020N-Fj
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 12:17:42 +0000
Received: from [193.109.254.147:46379] by server-2.bemta-14.messagelabs.com id
	FB/73-19409-5E8997F4; Mon, 02 Apr 2012 12:17:41 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333368975!3031377!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxODM1NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9953 invoked from network); 2 Apr 2012 12:17:21 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 12:17:21 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 2 Apr 2012 17:46:15 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 2 Apr 2012 17:46:11 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q32CG7ph3633316
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 17:46:11 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q32HkgcG005230
	for <xen-devel@lists.xensource.com>; Tue, 3 Apr 2012 03:46:44 +1000
Received: from [9.124.158.108] ([9.124.158.108])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q32HkfNq005174; Tue, 3 Apr 2012 03:46:41 +1000
Message-ID: <4F79985F.5030600@linux.vnet.ibm.com>
Date: Mon, 02 Apr 2012 17:45:27 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
	<4F7976B6.5050000@linux.vnet.ibm.com>
In-Reply-To: <4F7976B6.5050000@linux.vnet.ibm.com>
x-cbid: 12040212-5564-0000-0000-0000020F372E
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Attilio Rao <attilio.rao@citrix.com>, Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/02/2012 03:21 PM, Raghavendra K T wrote:
> On 04/01/2012 07:23 PM, Avi Kivity wrote:
>  > On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>  >>>> I have patch something like below in mind to try:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 5127668..3fa912a 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1557,12 +1557,17 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
> mark_page_dirty_in_slot(kvm, memslot, gfn);
> }
>
> +#define YIELD_THRESHOLD 2048
> +static void kvm_vcpu_try_yield_to(struct kvm_vcpu *me);
> /*
> * The vCPU has executed a HLT instruction with in-kernel mode enabled.
> */
> void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> {
[...]
> + if (loop_count++ % YIELD_THRESHOLD)
> + schedule();
> + else
> + kvm_vcpu_try_yield_to(vcpu);
> }
>
> +static void kvm_vcpu_try_yield(struct kvm_vcpu *me)

yes, it is kvm_vcpu_try_yield_to. had changed the name just before
sending. sorry.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 12:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 12:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEgCd-00020S-LW; Mon, 02 Apr 2012 12:17:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SEgCc-00020N-Fj
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 12:17:42 +0000
Received: from [193.109.254.147:46379] by server-2.bemta-14.messagelabs.com id
	FB/73-19409-5E8997F4; Mon, 02 Apr 2012 12:17:41 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333368975!3031377!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxODM1NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9953 invoked from network); 2 Apr 2012 12:17:21 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 12:17:21 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 2 Apr 2012 17:46:15 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 2 Apr 2012 17:46:11 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q32CG7ph3633316
	for <xen-devel@lists.xensource.com>; Mon, 2 Apr 2012 17:46:11 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q32HkgcG005230
	for <xen-devel@lists.xensource.com>; Tue, 3 Apr 2012 03:46:44 +1000
Received: from [9.124.158.108] ([9.124.158.108])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q32HkfNq005174; Tue, 3 Apr 2012 03:46:41 +1000
Message-ID: <4F79985F.5030600@linux.vnet.ibm.com>
Date: Mon, 02 Apr 2012 17:45:27 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
	<4F7976B6.5050000@linux.vnet.ibm.com>
In-Reply-To: <4F7976B6.5050000@linux.vnet.ibm.com>
x-cbid: 12040212-5564-0000-0000-0000020F372E
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Attilio Rao <attilio.rao@citrix.com>, Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/02/2012 03:21 PM, Raghavendra K T wrote:
> On 04/01/2012 07:23 PM, Avi Kivity wrote:
>  > On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>  >>>> I have patch something like below in mind to try:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 5127668..3fa912a 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1557,12 +1557,17 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
> mark_page_dirty_in_slot(kvm, memslot, gfn);
> }
>
> +#define YIELD_THRESHOLD 2048
> +static void kvm_vcpu_try_yield_to(struct kvm_vcpu *me);
> /*
> * The vCPU has executed a HLT instruction with in-kernel mode enabled.
> */
> void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> {
[...]
> + if (loop_count++ % YIELD_THRESHOLD)
> + schedule();
> + else
> + kvm_vcpu_try_yield_to(vcpu);
> }
>
> +static void kvm_vcpu_try_yield(struct kvm_vcpu *me)

yes, it is kvm_vcpu_try_yield_to. had changed the name just before
sending. sorry.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:15:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEh5c-0003Cb-TG; Mon, 02 Apr 2012 13:14:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SEh5a-0003CU-PM
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 13:14:30 +0000
Received: from [85.158.143.99:34441] by server-3.bemta-4.messagelabs.com id
	BC/57-05853-636A97F4; Mon, 02 Apr 2012 13:14:30 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333372467!16204108!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27976 invoked from network); 2 Apr 2012 13:14:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:14:28 -0000
Received: by obbwd20 with SMTP id wd20so5098850obb.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 06:14:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=9TQJUMn1ZnOdJQ1IWorYutl2nXQ6P4Stv9PU5mUNjM8=;
	b=Cj+tOLYV+1bzbvBhMxFjt7isZNNGdsFjqqdO8I06DnSr1s8ZwtLujMBmGGcGXEnquN
	WYYapmfHZ1XxyWs5zF9B5nq9ZtzPpcKIU9Jcx+dRS3vxLNzsEDqRpTpIPXbjZxPI+43t
	GHlf9wHm1QnUYzd03uZ1PqiRrbwbTAtRaebqfcod9L9r9z3pF5V+Rd+VX0Q7Fn+OnMVz
	oNFwsGKOCcqDk9A9MgOsCVqi7clYXOdMBXRJO8yhwG/6tCHFygaLjPADWrnFGulcd2D6
	b7KZyu/LrrTvb3Ie+v1S95vo0yTK5VdrEG0KJCk8H2RaI8K/USE/azRWyiNJ+agoqmkX
	HmlQ==
MIME-Version: 1.0
Received: by 10.182.50.100 with SMTP id b4mr12389873obo.45.1333372465448; Mon,
	02 Apr 2012 06:14:25 -0700 (PDT)
Received: by 10.182.97.72 with HTTP; Mon, 2 Apr 2012 06:14:25 -0700 (PDT)
X-Originating-IP: [121.44.4.35]
In-Reply-To: <1333356381.25602.4.camel@zakaz.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
	<1333356381.25602.4.camel@zakaz.uk.xensource.com>
Date: Mon, 2 Apr 2012 23:14:25 +1000
Message-ID: <CAOzFzEhnMQLfmwv0=jh9TTqEm+o0J5GhRb94AY2xU99jk0mzwQ@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQlSy8GGanWDX5a3HSsAgxPOogTot9AUmJJXpNhOVfp80flBwxahbOujlEBkK7DHgpxOTZar
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2 April 2012 18:46, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Sun, 2012-04-01 at 00:13 +0100, Joseph Glanville wrote:
>> Domain configuration is stored in libxl_domain_config which is a part
>> of libxl but there isn't currently a structure for data that is
>> private to xl, that is xl daemon or utility specific configuration.
>> Is it considered bad form to add a configuration variable to
>> libxl_domain_config that only xl will benefit from? if so what is the
>> best course of action here?
>> I could create another structure for private data but I feel seeking
>> guidance on this as prudent.
>
> xl_cmdimpl.c defines struct domain_create to contain a bunch of this
> sort of thing, is that a convenient location?

That could work. domain_create isn't currently passed to parse_config_data =
or
handle_domain_death yet but it seems like a reasonable place to put this st=
uff

>
> Ian.
>

I will rehash this tonight once I work out how the xlu_cfg_get_list
stuff works and post a proper v1.

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:15:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEh5c-0003Cb-TG; Mon, 02 Apr 2012 13:14:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SEh5a-0003CU-PM
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 13:14:30 +0000
Received: from [85.158.143.99:34441] by server-3.bemta-4.messagelabs.com id
	BC/57-05853-636A97F4; Mon, 02 Apr 2012 13:14:30 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333372467!16204108!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27976 invoked from network); 2 Apr 2012 13:14:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:14:28 -0000
Received: by obbwd20 with SMTP id wd20so5098850obb.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 06:14:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=9TQJUMn1ZnOdJQ1IWorYutl2nXQ6P4Stv9PU5mUNjM8=;
	b=Cj+tOLYV+1bzbvBhMxFjt7isZNNGdsFjqqdO8I06DnSr1s8ZwtLujMBmGGcGXEnquN
	WYYapmfHZ1XxyWs5zF9B5nq9ZtzPpcKIU9Jcx+dRS3vxLNzsEDqRpTpIPXbjZxPI+43t
	GHlf9wHm1QnUYzd03uZ1PqiRrbwbTAtRaebqfcod9L9r9z3pF5V+Rd+VX0Q7Fn+OnMVz
	oNFwsGKOCcqDk9A9MgOsCVqi7clYXOdMBXRJO8yhwG/6tCHFygaLjPADWrnFGulcd2D6
	b7KZyu/LrrTvb3Ie+v1S95vo0yTK5VdrEG0KJCk8H2RaI8K/USE/azRWyiNJ+agoqmkX
	HmlQ==
MIME-Version: 1.0
Received: by 10.182.50.100 with SMTP id b4mr12389873obo.45.1333372465448; Mon,
	02 Apr 2012 06:14:25 -0700 (PDT)
Received: by 10.182.97.72 with HTTP; Mon, 2 Apr 2012 06:14:25 -0700 (PDT)
X-Originating-IP: [121.44.4.35]
In-Reply-To: <1333356381.25602.4.camel@zakaz.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
	<1333356381.25602.4.camel@zakaz.uk.xensource.com>
Date: Mon, 2 Apr 2012 23:14:25 +1000
Message-ID: <CAOzFzEhnMQLfmwv0=jh9TTqEm+o0J5GhRb94AY2xU99jk0mzwQ@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQlSy8GGanWDX5a3HSsAgxPOogTot9AUmJJXpNhOVfp80flBwxahbOujlEBkK7DHgpxOTZar
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2 April 2012 18:46, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Sun, 2012-04-01 at 00:13 +0100, Joseph Glanville wrote:
>> Domain configuration is stored in libxl_domain_config which is a part
>> of libxl but there isn't currently a structure for data that is
>> private to xl, that is xl daemon or utility specific configuration.
>> Is it considered bad form to add a configuration variable to
>> libxl_domain_config that only xl will benefit from? if so what is the
>> best course of action here?
>> I could create another structure for private data but I feel seeking
>> guidance on this as prudent.
>
> xl_cmdimpl.c defines struct domain_create to contain a bunch of this
> sort of thing, is that a convenient location?

That could work. domain_create isn't currently passed to parse_config_data =
or
handle_domain_death yet but it seems like a reasonable place to put this st=
uff

>
> Ian.
>

I will rehash this tonight once I work out how the xlu_cfg_get_list
stuff works and post a proper v1.

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhbp-0003dl-L6; Mon, 02 Apr 2012 13:47:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhbo-0003dg-Fz
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:47:48 +0000
Received: from [85.158.139.83:24062] by server-2.bemta-5.messagelabs.com id
	F2/4D-17016-30EA97F4; Mon, 02 Apr 2012 13:47:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333374466!21998047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 2 Apr 2012 13:47:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:47:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:47:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhbl-0001px-Iw; Mon, 02 Apr 2012 13:47:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhb4-0000gw-GD;
	Mon, 02 Apr 2012 14:47:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.44502.306179.202932@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:47:02 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1c86e2e5268d14587c73.1333095918@probook.site>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> xs_api.c: In function 'convert_dev_name_to_num':
...
> ptr should be increased in each iteration, not the char it points to.

These changes from `*p++;' to `p++' are correct.  But the description
is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
uselessly dereferences it.

> -	char *p_sd = "/dev/sd";
> -	char *p_hd = "/dev/hd";
> -	char *p_xvd = "/dev/xvd";
> -	char *p_plx = "plx";
> -	char *alpha = "abcdefghijklmnop";
> +	static const char p_sd[] = "/dev/sd";
> +	static const char p_hd[] = "/dev/hd";
> +	static const char p_xvd[] = "/dev/xvd";
> +	static const char p_plx[] = "plx";
> +	static const char alpha[] = "abcdefghijklmnop";

And this hunk seems entirely unexplained.  Is it supposed to be a
const-correctness fix ?  Stylistic improvement ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhbp-0003dl-L6; Mon, 02 Apr 2012 13:47:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhbo-0003dg-Fz
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:47:48 +0000
Received: from [85.158.139.83:24062] by server-2.bemta-5.messagelabs.com id
	F2/4D-17016-30EA97F4; Mon, 02 Apr 2012 13:47:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333374466!21998047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 2 Apr 2012 13:47:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:47:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:47:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhbl-0001px-Iw; Mon, 02 Apr 2012 13:47:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhb4-0000gw-GD;
	Mon, 02 Apr 2012 14:47:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.44502.306179.202932@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:47:02 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1c86e2e5268d14587c73.1333095918@probook.site>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> xs_api.c: In function 'convert_dev_name_to_num':
...
> ptr should be increased in each iteration, not the char it points to.

These changes from `*p++;' to `p++' are correct.  But the description
is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
uselessly dereferences it.

> -	char *p_sd = "/dev/sd";
> -	char *p_hd = "/dev/hd";
> -	char *p_xvd = "/dev/xvd";
> -	char *p_plx = "plx";
> -	char *alpha = "abcdefghijklmnop";
> +	static const char p_sd[] = "/dev/sd";
> +	static const char p_hd[] = "/dev/hd";
> +	static const char p_xvd[] = "/dev/xvd";
> +	static const char p_plx[] = "plx";
> +	static const char alpha[] = "abcdefghijklmnop";

And this hunk seems entirely unexplained.  Is it supposed to be a
const-correctness fix ?  Stylistic improvement ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:52:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhgF-0003jt-B8; Mon, 02 Apr 2012 13:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhgE-0003jo-2O
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:52:22 +0000
Received: from [85.158.143.99:57571] by server-1.bemta-4.messagelabs.com id
	2B/3B-20925-51FA97F4; Mon, 02 Apr 2012 13:52:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333374740!21376175!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6638 invoked from network); 2 Apr 2012 13:52:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:52:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhgC-0001rZ-A6; Mon, 02 Apr 2012 13:52:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhgC-0000hq-8o;
	Mon, 02 Apr 2012 14:52:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.44820.253651.355239@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:52:20 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <16f6fc42abaa781e52aa.1333095924@probook.site>
References: <patchbomb.1333095917@probook.site>
	<16f6fc42abaa781e52aa.1333095924@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 18] tools/blktap2: fix build errors
 caused by Werror in tdqcow_get_parent_id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 07 of 18] tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id"):
> tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> block-qcow.c: In function 'tdqcow_get_parent_id':
> block-qcow.c:1457:17: warning: 'type' may be used uninitialized in this function [-Wuninitialized]
> 
> The compiler can not know that open() writes to errno so it has to
> assume that errno can be zero.

Yes.

> Since tdqcow_get_image_type() has just
> one caller which expects a bool as return type, adjust return codes so
> that the compiler knows when 'type' is initialised.

I don't think this is a step in the right direction.  In a better
world the caller would report the errno value.  Throwing the errno
value away is not an improvement.

> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 51c773447549 -r 16f6fc42abaa tools/blktap2/drivers/block-qcow.c
> --- a/tools/blktap2/drivers/block-qcow.c
> +++ b/tools/blktap2/drivers/block-qcow.c
> @@ -1408,12 +1408,12 @@ tdqcow_get_image_type(const char *file, 
>  
>  	fd = open(file, O_RDONLY);
>  	if (fd == -1)
> -		return -errno;
> +		return -1;

This can be fixed here by adding
   assert(errno);

>  	size = read(fd, &header, sizeof(header));
>  	close(fd);
>  	if (size != sizeof(header))
> -		return (errno ? -errno : -EIO);
> +		return -1;

And this seems not to have a problem; surely just leaving it unchanged
is sufficient ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:52:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhgF-0003jt-B8; Mon, 02 Apr 2012 13:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhgE-0003jo-2O
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:52:22 +0000
Received: from [85.158.143.99:57571] by server-1.bemta-4.messagelabs.com id
	2B/3B-20925-51FA97F4; Mon, 02 Apr 2012 13:52:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333374740!21376175!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6638 invoked from network); 2 Apr 2012 13:52:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:52:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhgC-0001rZ-A6; Mon, 02 Apr 2012 13:52:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhgC-0000hq-8o;
	Mon, 02 Apr 2012 14:52:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.44820.253651.355239@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:52:20 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <16f6fc42abaa781e52aa.1333095924@probook.site>
References: <patchbomb.1333095917@probook.site>
	<16f6fc42abaa781e52aa.1333095924@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 18] tools/blktap2: fix build errors
 caused by Werror in tdqcow_get_parent_id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 07 of 18] tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id"):
> tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> block-qcow.c: In function 'tdqcow_get_parent_id':
> block-qcow.c:1457:17: warning: 'type' may be used uninitialized in this function [-Wuninitialized]
> 
> The compiler can not know that open() writes to errno so it has to
> assume that errno can be zero.

Yes.

> Since tdqcow_get_image_type() has just
> one caller which expects a bool as return type, adjust return codes so
> that the compiler knows when 'type' is initialised.

I don't think this is a step in the right direction.  In a better
world the caller would report the errno value.  Throwing the errno
value away is not an improvement.

> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 51c773447549 -r 16f6fc42abaa tools/blktap2/drivers/block-qcow.c
> --- a/tools/blktap2/drivers/block-qcow.c
> +++ b/tools/blktap2/drivers/block-qcow.c
> @@ -1408,12 +1408,12 @@ tdqcow_get_image_type(const char *file, 
>  
>  	fd = open(file, O_RDONLY);
>  	if (fd == -1)
> -		return -errno;
> +		return -1;

This can be fixed here by adding
   assert(errno);

>  	size = read(fd, &header, sizeof(header));
>  	close(fd);
>  	if (size != sizeof(header))
> -		return (errno ? -errno : -EIO);
> +		return -1;

And this seems not to have a problem; surely just leaving it unchanged
is sufficient ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhhi-0003q0-RV; Mon, 02 Apr 2012 13:53:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhhh-0003pp-14
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:53:53 +0000
Received: from [85.158.143.35:45980] by server-1.bemta-4.messagelabs.com id
	E2/3E-20925-07FA97F4; Mon, 02 Apr 2012 13:53:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333374781!10818855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11752 invoked from network); 2 Apr 2012 13:53:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:53:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:53:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:53:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhgr-0001tT-Dg; Mon, 02 Apr 2012 13:53:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhgr-0000i7-CN;
	Mon, 02 Apr 2012 14:53:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.44861.163125.224414@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:53:01 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <46ec38b96a225eadcadd.1333095928@probook.site>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> libxl.c: In function 'disk_eject_xswatch_callback':
> libxl.c:928: warning: zero-length printf format string

There is nothing wrong with zero-length format strings.  This warning
should be disabled.  Please do send a patch to do so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhhi-0003q0-RV; Mon, 02 Apr 2012 13:53:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhhh-0003pp-14
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:53:53 +0000
Received: from [85.158.143.35:45980] by server-1.bemta-4.messagelabs.com id
	E2/3E-20925-07FA97F4; Mon, 02 Apr 2012 13:53:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333374781!10818855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11752 invoked from network); 2 Apr 2012 13:53:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:53:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:53:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:53:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhgr-0001tT-Dg; Mon, 02 Apr 2012 13:53:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhgr-0000i7-CN;
	Mon, 02 Apr 2012 14:53:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.44861.163125.224414@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:53:01 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <46ec38b96a225eadcadd.1333095928@probook.site>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> libxl.c: In function 'disk_eject_xswatch_callback':
> libxl.c:928: warning: zero-length printf format string

There is nothing wrong with zero-length format strings.  This warning
should be disabled.  Please do send a patch to do so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhjr-0003z3-CD; Mon, 02 Apr 2012 13:56:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhjp-0003yo-36
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:56:05 +0000
Received: from [85.158.138.51:42985] by server-11.bemta-3.messagelabs.com id
	2A/3D-12049-4FFA97F4; Mon, 02 Apr 2012 13:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333374959!20428173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8187 invoked from network); 2 Apr 2012 13:56:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723693"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhji-0001uX-EG; Mon, 02 Apr 2012 13:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhji-0000iQ-DO;
	Mon, 02 Apr 2012 14:55:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45038.398849.264369@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:55:58 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <91286869cde3e05f3eff.1333095922@probook.site>
References: <patchbomb.1333095917@probook.site>
	<91286869cde3e05f3eff.1333095922@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 18] tools/blktap2: fix build errors
 caused by Werror in vhd_journal_write_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 05 of 18] tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry"):
> tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry
...
> -	err = vhd_journal_write(j, &e, sizeof(vhd_journal_entry_t));
> -	if (err)
> -		err;

Surely this should have read `return err;'.

> -
> -	return 0;
> +	return vhd_journal_write(j, &e, sizeof(vhd_journal_entry_t));

I think that would be a better fix than this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 13:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 13:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhjr-0003z3-CD; Mon, 02 Apr 2012 13:56:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhjp-0003yo-36
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 13:56:05 +0000
Received: from [85.158.138.51:42985] by server-11.bemta-3.messagelabs.com id
	2A/3D-12049-4FFA97F4; Mon, 02 Apr 2012 13:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333374959!20428173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8187 invoked from network); 2 Apr 2012 13:56:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 13:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723693"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhji-0001uX-EG; Mon, 02 Apr 2012 13:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhji-0000iQ-DO;
	Mon, 02 Apr 2012 14:55:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45038.398849.264369@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:55:58 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <91286869cde3e05f3eff.1333095922@probook.site>
References: <patchbomb.1333095917@probook.site>
	<91286869cde3e05f3eff.1333095922@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 18] tools/blktap2: fix build errors
 caused by Werror in vhd_journal_write_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 05 of 18] tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry"):
> tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry
...
> -	err = vhd_journal_write(j, &e, sizeof(vhd_journal_entry_t));
> -	if (err)
> -		err;

Surely this should have read `return err;'.

> -
> -	return 0;
> +	return vhd_journal_write(j, &e, sizeof(vhd_journal_entry_t));

I think that would be a better fix than this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhne-0004Fm-0s; Mon, 02 Apr 2012 14:00:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhnd-0004Bn-7I
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:00:01 +0000
Received: from [85.158.143.35:23881] by server-1.bemta-4.messagelabs.com id
	78/08-20925-0E0B97F4; Mon, 02 Apr 2012 14:00:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333375199!16760414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19187 invoked from network); 2 Apr 2012 14:00:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:00:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:59:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:59:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhnA-0001vX-Pq; Mon, 02 Apr 2012 13:59:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhnA-0000ix-Od;
	Mon, 02 Apr 2012 14:59:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45252.747454.411523@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:59:32 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1092e073b88e0aed775e.1333095927@probook.site>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> tools/libvchan: fix build errors caused by -Werror in node-select.c
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> node-select.c:57:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]

These changes are correct.

> node-select.c: In function 'vchan_wr':
> node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

This one is a question of coding style.  Apparently libvchan uses
mixed statements/declarations, so this should be fixed by changing the
warning flags.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhne-0004Fm-0s; Mon, 02 Apr 2012 14:00:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhnd-0004Bn-7I
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:00:01 +0000
Received: from [85.158.143.35:23881] by server-1.bemta-4.messagelabs.com id
	78/08-20925-0E0B97F4; Mon, 02 Apr 2012 14:00:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333375199!16760414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19187 invoked from network); 2 Apr 2012 14:00:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:00:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 13:59:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 14:59:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhnA-0001vX-Pq; Mon, 02 Apr 2012 13:59:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhnA-0000ix-Od;
	Mon, 02 Apr 2012 14:59:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45252.747454.411523@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 14:59:32 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1092e073b88e0aed775e.1333095927@probook.site>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> tools/libvchan: fix build errors caused by -Werror in node-select.c
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> node-select.c:57:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]

These changes are correct.

> node-select.c: In function 'vchan_wr':
> node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

This one is a question of coding style.  Apparently libvchan uses
mixed statements/declarations, so this should be fixed by changing the
warning flags.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:01:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhon-0004Jw-Fg; Mon, 02 Apr 2012 14:01:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhom-0004Jm-9t
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:01:12 +0000
Received: from [85.158.138.51:29248] by server-11.bemta-3.messagelabs.com id
	6B/98-12049-721B97F4; Mon, 02 Apr 2012 14:01:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333375261!9396080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16784 invoked from network); 2 Apr 2012 14:01:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:01:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723922"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:01:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:01:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhoa-0001w7-GJ; Mon, 02 Apr 2012 14:01:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhoa-0000j6-FO;
	Mon, 02 Apr 2012 15:01:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45340.459003.798657@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:01:00 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bd4bb152538c54457026.1333095930@probook.site>
References: <patchbomb.1333095917@probook.site>
	<bd4bb152538c54457026.1333095930@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 18] tools/xenpaging: fix build
	errors	caused by -Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 13 of 18] tools/xenpaging: fix build errors caused by -Werror"):
> tools/xenpaging: fix build errors caused by -Werror

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:01:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhon-0004Jw-Fg; Mon, 02 Apr 2012 14:01:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhom-0004Jm-9t
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:01:12 +0000
Received: from [85.158.138.51:29248] by server-11.bemta-3.messagelabs.com id
	6B/98-12049-721B97F4; Mon, 02 Apr 2012 14:01:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333375261!9396080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16784 invoked from network); 2 Apr 2012 14:01:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:01:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11723922"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:01:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:01:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhoa-0001w7-GJ; Mon, 02 Apr 2012 14:01:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhoa-0000j6-FO;
	Mon, 02 Apr 2012 15:01:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45340.459003.798657@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:01:00 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bd4bb152538c54457026.1333095930@probook.site>
References: <patchbomb.1333095917@probook.site>
	<bd4bb152538c54457026.1333095930@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 18] tools/xenpaging: fix build
	errors	caused by -Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 13 of 18] tools/xenpaging: fix build errors caused by -Werror"):
> tools/xenpaging: fix build errors caused by -Werror

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:05:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhsb-0004YY-9q; Mon, 02 Apr 2012 14:05:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhsZ-0004YO-Bh
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:05:07 +0000
Received: from [85.158.139.83:27724] by server-8.bemta-5.messagelabs.com id
	B8/F3-26964-212B97F4; Mon, 02 Apr 2012 14:05:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333375504!22085782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3665 invoked from network); 2 Apr 2012 14:05:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:05:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724096"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:04:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:04:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhrv-0001xL-9h; Mon, 02 Apr 2012 14:04:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhrv-0000jX-8w;
	Mon, 02 Apr 2012 15:04:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45547.261495.199611@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:04:27 +0100
To: Olaf Hering <olaf@aepfle.de>,
    xen-devel@lists.xensource.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20345.44502.306179.202932@mariner.uk.xensource.com>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > xs_api.c: In function 'convert_dev_name_to_num':
> ...
> > ptr should be increased in each iteration, not the char it points to.
> 
> These changes from `*p++;' to `p++' are correct.  But the description
> is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> uselessly dereferences it.

It's been pointed out to me that this rather loose language is
unclear.  `*p++' increments p and but dereferences _the old value_ of
p.

The point I was making is that it does not increment (*p).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:05:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhsb-0004YY-9q; Mon, 02 Apr 2012 14:05:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhsZ-0004YO-Bh
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:05:07 +0000
Received: from [85.158.139.83:27724] by server-8.bemta-5.messagelabs.com id
	B8/F3-26964-212B97F4; Mon, 02 Apr 2012 14:05:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333375504!22085782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3665 invoked from network); 2 Apr 2012 14:05:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:05:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724096"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:04:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:04:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhrv-0001xL-9h; Mon, 02 Apr 2012 14:04:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhrv-0000jX-8w;
	Mon, 02 Apr 2012 15:04:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45547.261495.199611@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:04:27 +0100
To: Olaf Hering <olaf@aepfle.de>,
    xen-devel@lists.xensource.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20345.44502.306179.202932@mariner.uk.xensource.com>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > xs_api.c: In function 'convert_dev_name_to_num':
> ...
> > ptr should be increased in each iteration, not the char it points to.
> 
> These changes from `*p++;' to `p++' are correct.  But the description
> is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> uselessly dereferences it.

It's been pointed out to me that this rather loose language is
unclear.  `*p++' increments p and but dereferences _the old value_ of
p.

The point I was making is that it does not increment (*p).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhyT-0004le-4A; Mon, 02 Apr 2012 14:11:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhyR-0004lZ-OT
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:11:11 +0000
Received: from [85.158.139.83:11955] by server-6.bemta-5.messagelabs.com id
	46/ED-13222-E73B97F4; Mon, 02 Apr 2012 14:11:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333375870!21414620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31500 invoked from network); 2 Apr 2012 14:11:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:11:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:06:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:06:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhtT-0001xu-Os; Mon, 02 Apr 2012 14:06:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhtT-0000jo-O0;
	Mon, 02 Apr 2012 15:06:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45643.725400.367929@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:06:03 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9dbadf67b1b76d5864d1.1333095933@probook.site>
References: <patchbomb.1333095917@probook.site>
	<9dbadf67b1b76d5864d1.1333095933@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 16 of 18] tools/blktap2: fix build errors
 caused by Werror, remove blkif_op_name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 16 of 18] tools/blktap2: fix build errors caused by Werror, remove blkif_op_name"):
> tools/blktap2: fix build errors caused by Werror, remove blkif_op_name
...
> -static char *blkif_op_name[] = {
> -	[BLKIF_OP_READ]       = "READ",
> -	[BLKIF_OP_WRITE]      = "WRITE",
> -};

Looks plausible to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEhyT-0004le-4A; Mon, 02 Apr 2012 14:11:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEhyR-0004lZ-OT
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:11:11 +0000
Received: from [85.158.139.83:11955] by server-6.bemta-5.messagelabs.com id
	46/ED-13222-E73B97F4; Mon, 02 Apr 2012 14:11:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333375870!21414620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31500 invoked from network); 2 Apr 2012 14:11:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:11:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:06:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:06:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEhtT-0001xu-Os; Mon, 02 Apr 2012 14:06:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEhtT-0000jo-O0;
	Mon, 02 Apr 2012 15:06:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.45643.725400.367929@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:06:03 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9dbadf67b1b76d5864d1.1333095933@probook.site>
References: <patchbomb.1333095917@probook.site>
	<9dbadf67b1b76d5864d1.1333095933@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 16 of 18] tools/blktap2: fix build errors
 caused by Werror, remove blkif_op_name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 16 of 18] tools/blktap2: fix build errors caused by Werror, remove blkif_op_name"):
> tools/blktap2: fix build errors caused by Werror, remove blkif_op_name
...
> -static char *blkif_op_name[] = {
> -	[BLKIF_OP_READ]       = "READ",
> -	[BLKIF_OP_WRITE]      = "WRITE",
> -};

Looks plausible to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:23:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEi9f-0004wd-Bo; Mon, 02 Apr 2012 14:22:47 +0000
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 1SEi9d-0004wW-Hv
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 14:22:45 +0000
Received: from [193.109.254.147:29668] by server-5.bemta-14.messagelabs.com id
	3E/AC-30733-436B97F4; Mon, 02 Apr 2012 14:22:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333376561!579852!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17118 invoked from network); 2 Apr 2012 14:22:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 14:22:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 15:22:39 +0100
Message-Id: <4F79D24F020000780007C040@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 15:22:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/pcifront: avoid pci_frontend_enable_msix()
 falsely returning success
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The original XenoLinux code has always had things this way, and for
compatibility reasons (in particular with a subsequent pciback
adjustment) upstream Linux should behave the same way (allowing for two
distinct error indications to be returned by the backend).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/pci/xen-pcifront.c |    1 +
 1 file changed, 1 insertion(+)

--- 3.4-rc1/drivers/pci/xen-pcifront.c
+++ 3.4-rc1-xen-pcifront-enable-msix-retval/drivers/pci/xen-pcifront.c
@@ -290,6 +290,7 @@ static int pci_frontend_enable_msix(stru
 		} else {
 			printk(KERN_DEBUG "enable msix get value %x\n",
 				op.value);
+			err = op.value;
 		}
 	} else {
 		dev_err(&dev->dev, "enable msix get err %x\n", err);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:23:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEi9f-0004wd-Bo; Mon, 02 Apr 2012 14:22:47 +0000
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 1SEi9d-0004wW-Hv
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 14:22:45 +0000
Received: from [193.109.254.147:29668] by server-5.bemta-14.messagelabs.com id
	3E/AC-30733-436B97F4; Mon, 02 Apr 2012 14:22:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333376561!579852!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17118 invoked from network); 2 Apr 2012 14:22:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 14:22:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 15:22:39 +0100
Message-Id: <4F79D24F020000780007C040@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 15:22:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/pcifront: avoid pci_frontend_enable_msix()
 falsely returning success
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The original XenoLinux code has always had things this way, and for
compatibility reasons (in particular with a subsequent pciback
adjustment) upstream Linux should behave the same way (allowing for two
distinct error indications to be returned by the backend).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/pci/xen-pcifront.c |    1 +
 1 file changed, 1 insertion(+)

--- 3.4-rc1/drivers/pci/xen-pcifront.c
+++ 3.4-rc1-xen-pcifront-enable-msix-retval/drivers/pci/xen-pcifront.c
@@ -290,6 +290,7 @@ static int pci_frontend_enable_msix(stru
 		} else {
 			printk(KERN_DEBUG "enable msix get value %x\n",
 				op.value);
+			err = op.value;
 		}
 	} else {
 		dev_err(&dev->dev, "enable msix get err %x\n", err);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:25:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiC3-00051z-T4; Mon, 02 Apr 2012 14:25:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEiC2-00051q-2H
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:25:14 +0000
Received: from [85.158.143.35:10365] by server-2.bemta-4.messagelabs.com id
	E5/32-17550-9C6B97F4; Mon, 02 Apr 2012 14:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333376711!14127037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12878 invoked from network); 2 Apr 2012 14:25:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:25:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:25:08 +0100
Date: Mon, 2 Apr 2012 15:27:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1333366503074-5612226.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Fantu wrote:
> Fantu wrote
> > 
> > 
> > Fantu wrote
> >> 
> >> For many years we used virtualization systems based on xen.
> >> Up to now we did quite well despite same issue we are trying to solve
> >> with the new version.
> >> The main issue that we found are about Windows domU performance and the
> >> thin client interface with rdp is sometimes problematic.
> >> We think a possible solution to solve current shortcomings could be qemu
> >> upstream with spice, qxl and USB redirection.
> >> We have started preparing a new test system based on Wheezy, the upstream
> >> kernel and xen 4.2.
> >> The current test system is:
> >> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> >> 3.2.12-1, package blktap-dkms and all dependency packages for xen spice
> >> and usb redirection.
> >> -------------------------
> >> /etc/modules
> >> ------------
> >> loop max_loop=64
> >> xenfs
> >> xen-evtchn
> >> blktap
> >> -------------------------
> >> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
> >> 25070)
> >> vi Makefile # removed dist-kernel to not compile kernel
> >> -------------------------
> >> vi Config.mk # qemu upstream unstable and seabios unstable
> >> ------------
> >> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
> >> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
> >> SEABIOS_UPSTREAM_TAG ?= master
> >> QEMU_TAG ?= master
> >> -------------------------
> >> Added some patches:
> >> - autoconf: add variable for pass arbitrary options to qemu upstream - my
> >> patch to build spice and usbredirection on qemu upstream
> >> - QEMU upstream need to kown the amount of RAM given to a guest. This
> >> patch give
> >> the correct value. - Anthony PERARD patch for try to solve ram/videoram
> >> issue
> >> - tools: specify datadir for qemu-xen build to fix firmware loading -
> >> Olaf Hering patch for try to solve qxl issue
> >> -------------------------
> >> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
> >> -------------------------
> >> vi config/Tools.mk # workaround for libxl compilation problem
> >> BISON               := bison
> >> FLEX                := flex
> >> -------------------------
> >> make dist
> >> ./install.sh
> >> insserv xencommons &&
> >> insserv xendomains
> >> 
> >> 
> >> Result:
> >> Full PV domU work, just minimal tests done.
> >> HVM domU with qemu traditional works but with qemu upstream some problem
> >> encountered.
> >> For now I didn't find a way to make Windows run on qemu upstream and
> >> nothing on logs.
> >> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
> >> Spice and usbrediction seem to be working in basic test done now, qxl
> >> not.
> >> 
> >> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on start,
> >> with qemu unstable it starts but with an allocation problem, on xorg log:
> >> Out of video memory: Could not allocate 4198400 bytes
> >> I tried to update also seabios to unstable but same problem.
> >> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
> >> 
> >> Current xl domU configuration file:
> >> -----------------------------------
> >> name='PRECISEHVM'
> >> builder="hvm"
> >> memory=1024
> >> #maxmem=1536
> >> vcpus=2
> >> #hap=1
> >> #pae=1
> >> #acpi=1
> >> #apic=1
> >> #nx=1
> >> vif=['bridge=xenbr0']
> >> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> >> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> >> '/dev/sr0,raw,hdb,ro,cdrom']
> >> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
> >> boot='c'
> >> xen_platform_pci=1
> >> device_model_version='qemu-xen'
> >> vnc=0
> >> #vncunused=1
> >> #vnclisten="0.0.0.0"
> >> #keymap="it"
> >> #stdvga=1
> >> #sdl=0
> >> spice=1
> >> spicehost='0.0.0.0'
> >> spiceport=6000
> >> spicedisable_ticketing=1
> >> #spicepasswd='test'
> >> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> >> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
> >> device_model_args=["-vga qxl"]
> >> #device_model_args=["-usb -device usb-ehci"]
> >> #on_crash='preserve'
> >> videoram=128
> >> #bios="ovmf"
> >> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
> >> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
> >> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
> >> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
> >> -----------------------------------
> >> 
> >> Can someone help to solve these issues?
> >> Thanks for any reply.
> >> 
> > Today I have done other tests: windows xp sp3 installs and runs
> > successfully on qemu upstream unstable.
> > Vnc working but too slow, with stdvga improved but not optimal.
> > Spice with qxl is working but with slow graphic performance. It seems to
> > have only 4 mb videoram usable (seem to be same with Precise, see quote).
> > 
> > This is the current xl configuration:
> > -------------------------------------
> > name='XP'
> > builder="hvm"
> > memory=1024
> > vcpus=2
> > hap=1
> > pae=1
> > acpi=1
> > apic=1
> > nx=1
> > vif=['bridge=xenbr0']
> > #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> > disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> > boot='d'
> > xen_platform_pci=1
> > viridian=1
> > device_model_version="qemu-xen"
> > device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> > vnc=0
> > #vncunused=1
> > #vnclisten="0.0.0.0"
> > #keymap="it"
> > spice=1
> > spicehost="0.0.0.0"
> > spiceport=6000
> > spicedisable_ticketing=1
> > on_poweroff="destroy"
> > on_reboot="restart"
> > on_crash="destroy"
> > stdvga=0
> > device_model_args=["-vga qxl"]
> > videoram=128
> > -------------------------------------
> > 
> Also Windows 7 is working with qemu upstream, with patches and workaround
> applied probably, for details see the first post.

Thank you very much for testing!
Would you be up for writing a wiki.xen.org page about how to use SPICE
with Xen?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:25:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiC3-00051z-T4; Mon, 02 Apr 2012 14:25:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEiC2-00051q-2H
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:25:14 +0000
Received: from [85.158.143.35:10365] by server-2.bemta-4.messagelabs.com id
	E5/32-17550-9C6B97F4; Mon, 02 Apr 2012 14:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333376711!14127037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12878 invoked from network); 2 Apr 2012 14:25:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:25:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:25:08 +0100
Date: Mon, 2 Apr 2012 15:27:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1333366503074-5612226.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Fantu wrote:
> Fantu wrote
> > 
> > 
> > Fantu wrote
> >> 
> >> For many years we used virtualization systems based on xen.
> >> Up to now we did quite well despite same issue we are trying to solve
> >> with the new version.
> >> The main issue that we found are about Windows domU performance and the
> >> thin client interface with rdp is sometimes problematic.
> >> We think a possible solution to solve current shortcomings could be qemu
> >> upstream with spice, qxl and USB redirection.
> >> We have started preparing a new test system based on Wheezy, the upstream
> >> kernel and xen 4.2.
> >> The current test system is:
> >> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> >> 3.2.12-1, package blktap-dkms and all dependency packages for xen spice
> >> and usb redirection.
> >> -------------------------
> >> /etc/modules
> >> ------------
> >> loop max_loop=64
> >> xenfs
> >> xen-evtchn
> >> blktap
> >> -------------------------
> >> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
> >> 25070)
> >> vi Makefile # removed dist-kernel to not compile kernel
> >> -------------------------
> >> vi Config.mk # qemu upstream unstable and seabios unstable
> >> ------------
> >> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
> >> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
> >> SEABIOS_UPSTREAM_TAG ?= master
> >> QEMU_TAG ?= master
> >> -------------------------
> >> Added some patches:
> >> - autoconf: add variable for pass arbitrary options to qemu upstream - my
> >> patch to build spice and usbredirection on qemu upstream
> >> - QEMU upstream need to kown the amount of RAM given to a guest. This
> >> patch give
> >> the correct value. - Anthony PERARD patch for try to solve ram/videoram
> >> issue
> >> - tools: specify datadir for qemu-xen build to fix firmware loading -
> >> Olaf Hering patch for try to solve qxl issue
> >> -------------------------
> >> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
> >> -------------------------
> >> vi config/Tools.mk # workaround for libxl compilation problem
> >> BISON               := bison
> >> FLEX                := flex
> >> -------------------------
> >> make dist
> >> ./install.sh
> >> insserv xencommons &&
> >> insserv xendomains
> >> 
> >> 
> >> Result:
> >> Full PV domU work, just minimal tests done.
> >> HVM domU with qemu traditional works but with qemu upstream some problem
> >> encountered.
> >> For now I didn't find a way to make Windows run on qemu upstream and
> >> nothing on logs.
> >> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
> >> Spice and usbrediction seem to be working in basic test done now, qxl
> >> not.
> >> 
> >> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on start,
> >> with qemu unstable it starts but with an allocation problem, on xorg log:
> >> Out of video memory: Could not allocate 4198400 bytes
> >> I tried to update also seabios to unstable but same problem.
> >> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
> >> 
> >> Current xl domU configuration file:
> >> -----------------------------------
> >> name='PRECISEHVM'
> >> builder="hvm"
> >> memory=1024
> >> #maxmem=1536
> >> vcpus=2
> >> #hap=1
> >> #pae=1
> >> #acpi=1
> >> #apic=1
> >> #nx=1
> >> vif=['bridge=xenbr0']
> >> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> >> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> >> '/dev/sr0,raw,hdb,ro,cdrom']
> >> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
> >> boot='c'
> >> xen_platform_pci=1
> >> device_model_version='qemu-xen'
> >> vnc=0
> >> #vncunused=1
> >> #vnclisten="0.0.0.0"
> >> #keymap="it"
> >> #stdvga=1
> >> #sdl=0
> >> spice=1
> >> spicehost='0.0.0.0'
> >> spiceport=6000
> >> spicedisable_ticketing=1
> >> #spicepasswd='test'
> >> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> >> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
> >> device_model_args=["-vga qxl"]
> >> #device_model_args=["-usb -device usb-ehci"]
> >> #on_crash='preserve'
> >> videoram=128
> >> #bios="ovmf"
> >> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
> >> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
> >> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
> >> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
> >> -----------------------------------
> >> 
> >> Can someone help to solve these issues?
> >> Thanks for any reply.
> >> 
> > Today I have done other tests: windows xp sp3 installs and runs
> > successfully on qemu upstream unstable.
> > Vnc working but too slow, with stdvga improved but not optimal.
> > Spice with qxl is working but with slow graphic performance. It seems to
> > have only 4 mb videoram usable (seem to be same with Precise, see quote).
> > 
> > This is the current xl configuration:
> > -------------------------------------
> > name='XP'
> > builder="hvm"
> > memory=1024
> > vcpus=2
> > hap=1
> > pae=1
> > acpi=1
> > apic=1
> > nx=1
> > vif=['bridge=xenbr0']
> > #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> > disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> > boot='d'
> > xen_platform_pci=1
> > viridian=1
> > device_model_version="qemu-xen"
> > device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> > vnc=0
> > #vncunused=1
> > #vnclisten="0.0.0.0"
> > #keymap="it"
> > spice=1
> > spicehost="0.0.0.0"
> > spiceport=6000
> > spicedisable_ticketing=1
> > on_poweroff="destroy"
> > on_reboot="restart"
> > on_crash="destroy"
> > stdvga=0
> > device_model_args=["-vga qxl"]
> > videoram=128
> > -------------------------------------
> > 
> Also Windows 7 is working with qemu upstream, with patches and workaround
> applied probably, for details see the first post.

Thank you very much for testing!
Would you be up for writing a wiki.xen.org page about how to use SPICE
with Xen?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:31:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiHm-0005E1-MV; Mon, 02 Apr 2012 14:31:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiHl-0005Dt-FZ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:31:09 +0000
Received: from [85.158.143.99:16382] by server-2.bemta-4.messagelabs.com id
	3C/BB-17550-C28B97F4; Mon, 02 Apr 2012 14:31:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333377067!21969060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18131 invoked from network); 2 Apr 2012 14:31:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:31:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:31:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:31:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiHi-0002N6-Qs; Mon, 02 Apr 2012 14:31:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiHi-0000m6-Py;
	Mon, 02 Apr 2012 15:31:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47146.789315.21674@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:31:06 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <51c773447549ec98a5bd.1333095923@probook.site>
References: <patchbomb.1333095917@probook.site>
	<51c773447549ec98a5bd.1333095923@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 18] tools/blktap2: fix out of bounds
 access in block-log.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 06 of 18] tools/blktap2: fix out of bounds access in block-log.c"):
> tools/blktap2: fix out of bounds access in block-log.c
> 
> block-log.c: In function 'ctl_close_sock':
> block-log.c:363:23: warning: array subscript is above array bounds [-Warray-bounds]
> 
> Adjust loop condition in ctl_close_sock() to fix warning.
> Adjust array acccess in ctl_close() to actually access the array member.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Good fix for unpleasant code, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:31:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiHm-0005E1-MV; Mon, 02 Apr 2012 14:31:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiHl-0005Dt-FZ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:31:09 +0000
Received: from [85.158.143.99:16382] by server-2.bemta-4.messagelabs.com id
	3C/BB-17550-C28B97F4; Mon, 02 Apr 2012 14:31:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333377067!21969060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18131 invoked from network); 2 Apr 2012 14:31:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:31:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:31:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:31:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiHi-0002N6-Qs; Mon, 02 Apr 2012 14:31:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiHi-0000m6-Py;
	Mon, 02 Apr 2012 15:31:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47146.789315.21674@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:31:06 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <51c773447549ec98a5bd.1333095923@probook.site>
References: <patchbomb.1333095917@probook.site>
	<51c773447549ec98a5bd.1333095923@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 18] tools/blktap2: fix out of bounds
 access in block-log.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 06 of 18] tools/blktap2: fix out of bounds access in block-log.c"):
> tools/blktap2: fix out of bounds access in block-log.c
> 
> block-log.c: In function 'ctl_close_sock':
> block-log.c:363:23: warning: array subscript is above array bounds [-Warray-bounds]
> 
> Adjust loop condition in ctl_close_sock() to fix warning.
> Adjust array acccess in ctl_close() to actually access the array member.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Good fix for unpleasant code, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiIy-0005HU-4l; Mon, 02 Apr 2012 14:32:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiIw-0005HK-Tm
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:32:23 +0000
Received: from [85.158.138.51:26038] by server-3.bemta-3.messagelabs.com id
	01/D6-10665-678B97F4; Mon, 02 Apr 2012 14:32:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333377141!20222737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3491 invoked from network); 2 Apr 2012 14:32:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:32:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:32:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:32:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiIu-0002Nb-SQ; Mon, 02 Apr 2012 14:32:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiIu-0000mR-RP;
	Mon, 02 Apr 2012 15:32:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47220.829841.789325@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:32:20 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <af687dd9e9e0ebf3e68f.1333095932@probook.site>
References: <patchbomb.1333095917@probook.site>
	<af687dd9e9e0ebf3e68f.1333095932@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 18] tools/blktap2: remove static
 string table from header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 15 of 18] tools/blktap2: remove static string table from header file"):
> tools/blktap2: remove static string table from header file
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> ../../include/vhd.h:109: warning: 'HD_TYPE_STR' defined but not used
> 
> Since its used only in one place, move it to the .c file.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiIy-0005HU-4l; Mon, 02 Apr 2012 14:32:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiIw-0005HK-Tm
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:32:23 +0000
Received: from [85.158.138.51:26038] by server-3.bemta-3.messagelabs.com id
	01/D6-10665-678B97F4; Mon, 02 Apr 2012 14:32:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333377141!20222737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3491 invoked from network); 2 Apr 2012 14:32:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:32:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:32:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:32:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiIu-0002Nb-SQ; Mon, 02 Apr 2012 14:32:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiIu-0000mR-RP;
	Mon, 02 Apr 2012 15:32:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47220.829841.789325@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:32:20 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <af687dd9e9e0ebf3e68f.1333095932@probook.site>
References: <patchbomb.1333095917@probook.site>
	<af687dd9e9e0ebf3e68f.1333095932@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 18] tools/blktap2: remove static
 string table from header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 15 of 18] tools/blktap2: remove static string table from header file"):
> tools/blktap2: remove static string table from header file
> 
> -O2 -Wall -Werror triggers these warnings:
> 
> ../../include/vhd.h:109: warning: 'HD_TYPE_STR' defined but not used
> 
> Since its used only in one place, move it to the .c file.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:32:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:32:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiJ5-0005IB-HB; Mon, 02 Apr 2012 14:32:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEiJ3-0005Hx-Er
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 14:32:29 +0000
Received: from [85.158.139.83:31045] by server-10.bemta-5.messagelabs.com id
	12/95-08260-C78B97F4; Mon, 02 Apr 2012 14:32:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333377145!21552371!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 2 Apr 2012 14:32:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 14:32:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 15:32:23 +0100
Message-Id: <4F79D496020000780007C05B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 15:32:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/pciback: fix XEN_PCI_OP_enable_msix result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prior to 2.6.19 and as of 2.6.31, pci_enable_msix() can return a
positive value to indicate the number of vectors (less than the amount
requested) that can be set up for a given device. Returning this as an
operation value (secondary result) is fine, but (primary) operation
results are expected to be negative (error) or zero (success) according
to the protocol. With the frontend fixed to match the XenoLinux
behavior, the backend can now validly return zero (success) here,
passing the upper limit on the number of vectors in op->value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xen-pciback/pciback_ops.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 3.4-rc1/drivers/xen/xen-pciback/pciback_ops.c
+++ 3.4-rc1-xen-pciback-msix-retval/drivers/xen/xen-pciback/pciback_ops.c
@@ -234,7 +234,7 @@ int xen_pcibk_enable_msix(struct xen_pci
 	if (dev_data)
 		dev_data->ack_intr = 0;
 
-	return result;
+	return result > 0 ? 0 : result;
 }
 
 static




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:32:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:32:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiJ5-0005IB-HB; Mon, 02 Apr 2012 14:32:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEiJ3-0005Hx-Er
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 14:32:29 +0000
Received: from [85.158.139.83:31045] by server-10.bemta-5.messagelabs.com id
	12/95-08260-C78B97F4; Mon, 02 Apr 2012 14:32:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333377145!21552371!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 2 Apr 2012 14:32:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 14:32:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 15:32:23 +0100
Message-Id: <4F79D496020000780007C05B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 15:32:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/pciback: fix XEN_PCI_OP_enable_msix result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prior to 2.6.19 and as of 2.6.31, pci_enable_msix() can return a
positive value to indicate the number of vectors (less than the amount
requested) that can be set up for a given device. Returning this as an
operation value (secondary result) is fine, but (primary) operation
results are expected to be negative (error) or zero (success) according
to the protocol. With the frontend fixed to match the XenoLinux
behavior, the backend can now validly return zero (success) here,
passing the upper limit on the number of vectors in op->value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xen-pciback/pciback_ops.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 3.4-rc1/drivers/xen/xen-pciback/pciback_ops.c
+++ 3.4-rc1-xen-pciback-msix-retval/drivers/xen/xen-pciback/pciback_ops.c
@@ -234,7 +234,7 @@ int xen_pcibk_enable_msix(struct xen_pci
 	if (dev_data)
 		dev_data->ack_intr = 0;
 
-	return result;
+	return result > 0 ? 0 : result;
 }
 
 static




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:33:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiJN-0005LL-TO; Mon, 02 Apr 2012 14:32:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiJN-0005L9-8b
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:32:49 +0000
Received: from [85.158.143.99:25681] by server-3.bemta-4.messagelabs.com id
	37/55-05853-098B97F4; Mon, 02 Apr 2012 14:32:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333377166!18573185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15616 invoked from network); 2 Apr 2012 14:32:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:32:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:32:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:32:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiJJ-0002Ni-DC; Mon, 02 Apr 2012 14:32:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiJJ-0000ml-Cb;
	Mon, 02 Apr 2012 15:32:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47245.373293.625269@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:32:45 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8f3eaf8d99f50288eaef.1333095934@probook.site>
References: <patchbomb.1333095917@probook.site>
	<8f3eaf8d99f50288eaef.1333095934@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 18] tools/blktap2: remove unused labels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 17 of 18] tools/blktap2: remove unused labels"):
> tools/blktap2: remove unused labels
> 
> vhd-util-read.c:478:2: warning: label 'print' defined but not used [-Wunused-label]
> vhd-util-set-field.c:99:2: warning: label 'done' defined but not used [-Wunused-label]

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:33:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiJN-0005LL-TO; Mon, 02 Apr 2012 14:32:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiJN-0005L9-8b
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:32:49 +0000
Received: from [85.158.143.99:25681] by server-3.bemta-4.messagelabs.com id
	37/55-05853-098B97F4; Mon, 02 Apr 2012 14:32:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333377166!18573185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15616 invoked from network); 2 Apr 2012 14:32:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:32:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:32:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:32:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiJJ-0002Ni-DC; Mon, 02 Apr 2012 14:32:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiJJ-0000ml-Cb;
	Mon, 02 Apr 2012 15:32:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47245.373293.625269@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:32:45 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8f3eaf8d99f50288eaef.1333095934@probook.site>
References: <patchbomb.1333095917@probook.site>
	<8f3eaf8d99f50288eaef.1333095934@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 18] tools/blktap2: remove unused labels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 17 of 18] tools/blktap2: remove unused labels"):
> tools/blktap2: remove unused labels
> 
> vhd-util-read.c:478:2: warning: label 'print' defined but not used [-Wunused-label]
> vhd-util-set-field.c:99:2: warning: label 'done' defined but not used [-Wunused-label]

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiKH-0005Vs-Gv; Mon, 02 Apr 2012 14:33:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiKG-0005Vc-8p
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:33:44 +0000
Received: from [85.158.139.83:43008] by server-6.bemta-5.messagelabs.com id
	0D/11-13222-7C8B97F4; Mon, 02 Apr 2012 14:33:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333377221!19385446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12040 invoked from network); 2 Apr 2012 14:33:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:33:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:33:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiK9-0002O5-ER; Mon, 02 Apr 2012 14:33:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiK9-0000n8-Cv;
	Mon, 02 Apr 2012 15:33:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47297.154409.698856@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:33:37 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0966600a98f1b3a4707f.1333095931@probook.site>
References: <patchbomb.1333095917@probook.site>
	<0966600a98f1b3a4707f.1333095931@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> tools/libvchan: fix build errors caused by Werror in io.c
...
> -		writev(-1, iov, 2);
> +		if (writev(-1, iov, 2));

You need to actually fix these lost error bugs, not just suppress the
warning.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiKH-0005Vs-Gv; Mon, 02 Apr 2012 14:33:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiKG-0005Vc-8p
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:33:44 +0000
Received: from [85.158.139.83:43008] by server-6.bemta-5.messagelabs.com id
	0D/11-13222-7C8B97F4; Mon, 02 Apr 2012 14:33:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333377221!19385446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12040 invoked from network); 2 Apr 2012 14:33:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11724910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:33:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:33:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiK9-0002O5-ER; Mon, 02 Apr 2012 14:33:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiK9-0000n8-Cv;
	Mon, 02 Apr 2012 15:33:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47297.154409.698856@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:33:37 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0966600a98f1b3a4707f.1333095931@probook.site>
References: <patchbomb.1333095917@probook.site>
	<0966600a98f1b3a4707f.1333095931@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> tools/libvchan: fix build errors caused by Werror in io.c
...
> -		writev(-1, iov, 2);
> +		if (writev(-1, iov, 2));

You need to actually fix these lost error bugs, not just suppress the
warning.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:38:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiOM-0005vT-5z; Mon, 02 Apr 2012 14:37:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiOK-0005vM-LA
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:37:56 +0000
Received: from [193.109.254.147:4603] by server-5.bemta-14.messagelabs.com id
	7C/B8-30733-3C9B97F4; Mon, 02 Apr 2012 14:37:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333377474!3053937!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26726 invoked from network); 2 Apr 2012 14:37:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:37:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377474; l=471;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=3HBOxRtX6lDvCZzrckAML1SvbNQ=;
	b=nDkKQ+0BAwaBw2n2Jh6oVDNC1kwbD1c++E9jnzHoXO1g2wa9P4Uv1c+x1P9d35vpt+W
	WR27aoQKL9Yc0/TZkMuwAkN4vJmeC4VpWrNovZHhsxzDo8WntpVtgTLHfi+lf5VajoDmh
	QfArIVbAPv5XQozQXxGOWbigzTtpc4RjQQ0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo38) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j06b71o32DWmVl ;
	Mon, 2 Apr 2012 16:37:54 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id CE19F18637; Mon,  2 Apr 2012 16:37:52 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:37:52 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402143752.GA4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<0966600a98f1b3a4707f.1333095931@probook.site>
	<20345.47297.154409.698856@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.47297.154409.698856@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > tools/libvchan: fix build errors caused by Werror in io.c
> ...
> > -		writev(-1, iov, 2);
> > +		if (writev(-1, iov, 2));
> 
> You need to actually fix these lost error bugs, not just suppress the
> warning.

The others I havent looked at yet, yes.
But this write to fd '-1' one is just for strace.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:38:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiOM-0005vT-5z; Mon, 02 Apr 2012 14:37:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiOK-0005vM-LA
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:37:56 +0000
Received: from [193.109.254.147:4603] by server-5.bemta-14.messagelabs.com id
	7C/B8-30733-3C9B97F4; Mon, 02 Apr 2012 14:37:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333377474!3053937!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26726 invoked from network); 2 Apr 2012 14:37:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:37:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377474; l=471;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=3HBOxRtX6lDvCZzrckAML1SvbNQ=;
	b=nDkKQ+0BAwaBw2n2Jh6oVDNC1kwbD1c++E9jnzHoXO1g2wa9P4Uv1c+x1P9d35vpt+W
	WR27aoQKL9Yc0/TZkMuwAkN4vJmeC4VpWrNovZHhsxzDo8WntpVtgTLHfi+lf5VajoDmh
	QfArIVbAPv5XQozQXxGOWbigzTtpc4RjQQ0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo38) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j06b71o32DWmVl ;
	Mon, 2 Apr 2012 16:37:54 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id CE19F18637; Mon,  2 Apr 2012 16:37:52 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:37:52 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402143752.GA4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<0966600a98f1b3a4707f.1333095931@probook.site>
	<20345.47297.154409.698856@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.47297.154409.698856@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > tools/libvchan: fix build errors caused by Werror in io.c
> ...
> > -		writev(-1, iov, 2);
> > +		if (writev(-1, iov, 2));
> 
> You need to actually fix these lost error bugs, not just suppress the
> warning.

The others I havent looked at yet, yes.
But this write to fd '-1' one is just for strace.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:38:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiOV-0005wK-Hz; Mon, 02 Apr 2012 14:38:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiOU-0005w9-Vb
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:38:07 +0000
Received: from [85.158.139.83:21656] by server-4.bemta-5.messagelabs.com id
	CE/25-10788-EC9B97F4; Mon, 02 Apr 2012 14:38:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333377484!21553520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27909 invoked from network); 2 Apr 2012 14:38:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:38:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:38:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:38:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiOQ-0002PV-6h; Mon, 02 Apr 2012 14:38:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiOQ-0000ne-63;
	Mon, 02 Apr 2012 15:38:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47562.172976.821185@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:38:02 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5c77f79cc3064b575c1d.1333095919@probook.site>
References: <patchbomb.1333095917@probook.site>
	<5c77f79cc3064b575c1d.1333095919@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 02 of 18] tools/blktap: fix params
	and	physical-device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 02 of 18] tools/blktap: fix params and physical-device parsing"):
> tools/blktap: fix params and physical-device parsing
> 
> If parsing the "physical-device" property fails the physical device node
> should come from the "params" property. But since the deverr value was
> overwritten during read of the "mode" property, the "params" property
> was never parsed.

I think this should be fixed by having the read-only check not
improperly reuse `deverr'.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:38:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiOV-0005wK-Hz; Mon, 02 Apr 2012 14:38:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiOU-0005w9-Vb
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:38:07 +0000
Received: from [85.158.139.83:21656] by server-4.bemta-5.messagelabs.com id
	CE/25-10788-EC9B97F4; Mon, 02 Apr 2012 14:38:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333377484!21553520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27909 invoked from network); 2 Apr 2012 14:38:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:38:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:38:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:38:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiOQ-0002PV-6h; Mon, 02 Apr 2012 14:38:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiOQ-0000ne-63;
	Mon, 02 Apr 2012 15:38:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47562.172976.821185@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:38:02 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5c77f79cc3064b575c1d.1333095919@probook.site>
References: <patchbomb.1333095917@probook.site>
	<5c77f79cc3064b575c1d.1333095919@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 02 of 18] tools/blktap: fix params
	and	physical-device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 02 of 18] tools/blktap: fix params and physical-device parsing"):
> tools/blktap: fix params and physical-device parsing
> 
> If parsing the "physical-device" property fails the physical device node
> should come from the "params" property. But since the deverr value was
> overwritten during read of the "mode" property, the "params" property
> was never parsed.

I think this should be fixed by having the read-only check not
improperly reuse `deverr'.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiPW-00063M-0a; Mon, 02 Apr 2012 14:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEiPU-000634-SE
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 14:39:09 +0000
Received: from [85.158.138.51:56844] by server-5.bemta-3.messagelabs.com id
	A4/A5-31925-C0AB97F4; Mon, 02 Apr 2012 14:39:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333377547!20390309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19762 invoked from network); 2 Apr 2012 14:39:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:39:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:39:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:39:07 +0100
Date: Mon, 2 Apr 2012 15:41:07 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204021528240.15151@kaball-desktop>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Campbell wrote:
>       * file:// backend performance. qemu-xen-tradition's qdisk is quite
>         slow & blktap2 not available in upstream kernels. Need to
>         consider our options:
>               * qemu-xen's qdisk is thought to be well performing but
>                 qemu-xen is not yet the default. Complexity arising from
>                 splitting qemu-for-qdisk out from qemu-for-dm and
>                 running N qemu's.
>               * potentially fully userspace blktap could be ready for
>                 4.2
>               * use /dev/loop+blkback. This requires loop driver AIO and
>                 O_DIRECT patches which are not (AFAIK) yet upstream.
>               * Leverage XCP's blktap2 DKMS work.
>               * Other ideas?
>                       * In general we should recommend blkback (e.g.
>                         with LVM) since it always out performs other
>                         solutions, although at the expense of
>                         flexibility regarding image formats.
>         Stefano has done a lot of work here and has proposed some
>         performance improvements for qdisk in both qemu-xen and
>         qemu-xen-traditional which make them a plausible alternative for
>         Xen 4.2.

Using O_DIRECT rather than the default write-through cache policy solves
the performance problem in QEMU.
I sent patches to xen-devel to enable O_DIRECT for QDISK on
qemu-xen-traditional. I also sent patches to qemu-devel to enable
O_DIRECT and native AIO for QDISK on upstream QEMU.

Upstream QEMU PV backends are as good as the ones in
qemu-xen-traditional, but upstream QDISK performs better because it can
use native AIO. Thus I sent a patch to xen-devel to enable upstream QEMU
as default to provide userspace backends to PV guests.

I wrote and sent a patch series to fix the m2p override in Linux in case
the frontend and backend are both in the same domain.
Then I sent a patch series to xen-devel to make
libxl__device_disk_local_attach work with QDISK: the implementation uses
a frontend/backend pair in dom0.

As a result, with all these patches applied, the disk performances with
file based disk images are good and one can use a qcow2 file to store
a PV guest disk image and boot from it using pygrub.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiPW-00063M-0a; Mon, 02 Apr 2012 14:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEiPU-000634-SE
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 14:39:09 +0000
Received: from [85.158.138.51:56844] by server-5.bemta-3.messagelabs.com id
	A4/A5-31925-C0AB97F4; Mon, 02 Apr 2012 14:39:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333377547!20390309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19762 invoked from network); 2 Apr 2012 14:39:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:39:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:39:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:39:07 +0100
Date: Mon, 2 Apr 2012 15:41:07 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204021528240.15151@kaball-desktop>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Campbell wrote:
>       * file:// backend performance. qemu-xen-tradition's qdisk is quite
>         slow & blktap2 not available in upstream kernels. Need to
>         consider our options:
>               * qemu-xen's qdisk is thought to be well performing but
>                 qemu-xen is not yet the default. Complexity arising from
>                 splitting qemu-for-qdisk out from qemu-for-dm and
>                 running N qemu's.
>               * potentially fully userspace blktap could be ready for
>                 4.2
>               * use /dev/loop+blkback. This requires loop driver AIO and
>                 O_DIRECT patches which are not (AFAIK) yet upstream.
>               * Leverage XCP's blktap2 DKMS work.
>               * Other ideas?
>                       * In general we should recommend blkback (e.g.
>                         with LVM) since it always out performs other
>                         solutions, although at the expense of
>                         flexibility regarding image formats.
>         Stefano has done a lot of work here and has proposed some
>         performance improvements for qdisk in both qemu-xen and
>         qemu-xen-traditional which make them a plausible alternative for
>         Xen 4.2.

Using O_DIRECT rather than the default write-through cache policy solves
the performance problem in QEMU.
I sent patches to xen-devel to enable O_DIRECT for QDISK on
qemu-xen-traditional. I also sent patches to qemu-devel to enable
O_DIRECT and native AIO for QDISK on upstream QEMU.

Upstream QEMU PV backends are as good as the ones in
qemu-xen-traditional, but upstream QDISK performs better because it can
use native AIO. Thus I sent a patch to xen-devel to enable upstream QEMU
as default to provide userspace backends to PV guests.

I wrote and sent a patch series to fix the m2p override in Linux in case
the frontend and backend are both in the same domain.
Then I sent a patch series to xen-devel to make
libxl__device_disk_local_attach work with QDISK: the implementation uses
a frontend/backend pair in dom0.

As a result, with all these patches applied, the disk performances with
file based disk images are good and one can use a qcow2 file to store
a PV guest disk image and boot from it using pygrub.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:40:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiQP-0006A2-GV; Mon, 02 Apr 2012 14:40:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiQN-00069j-Jc
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:40:03 +0000
Received: from [85.158.139.83:55926] by server-7.bemta-5.messagelabs.com id
	51/36-16195-24AB97F4; Mon, 02 Apr 2012 14:40:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333377600!22094944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23138 invoked from network); 2 Apr 2012 14:40:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:39:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:39:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiPu-0002Q0-2Q; Mon, 02 Apr 2012 14:39:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiPu-0000nx-1b;
	Mon, 02 Apr 2012 15:39:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47654.35205.948080@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:39:34 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120402143752.GA4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<0966600a98f1b3a4707f.1333095931@probook.site>
	<20345.47297.154409.698856@mariner.uk.xensource.com>
	<20120402143752.GA4000@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> On Mon, Apr 02, Ian Jackson wrote:
> > You need to actually fix these lost error bugs, not just suppress the
> > warning.
> 
> The others I havent looked at yet, yes.
> But this write to fd '-1' one is just for strace.

Oh wait I didn't spot that.  That's insane.  I guess you should assert
that it always fails, but really why oh why oh why ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:40:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiQP-0006A2-GV; Mon, 02 Apr 2012 14:40:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiQN-00069j-Jc
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:40:03 +0000
Received: from [85.158.139.83:55926] by server-7.bemta-5.messagelabs.com id
	51/36-16195-24AB97F4; Mon, 02 Apr 2012 14:40:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333377600!22094944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23138 invoked from network); 2 Apr 2012 14:40:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:39:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:39:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiPu-0002Q0-2Q; Mon, 02 Apr 2012 14:39:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiPu-0000nx-1b;
	Mon, 02 Apr 2012 15:39:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47654.35205.948080@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:39:34 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120402143752.GA4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<0966600a98f1b3a4707f.1333095931@probook.site>
	<20345.47297.154409.698856@mariner.uk.xensource.com>
	<20120402143752.GA4000@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> On Mon, Apr 02, Ian Jackson wrote:
> > You need to actually fix these lost error bugs, not just suppress the
> > warning.
> 
> The others I havent looked at yet, yes.
> But this write to fd '-1' one is just for strace.

Oh wait I didn't spot that.  That's insane.  I guess you should assert
that it always fails, but really why oh why oh why ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiQS-0006As-AS; Mon, 02 Apr 2012 14:40:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiQR-0006AN-GE
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:40:07 +0000
Received: from [85.158.139.83:42052] by server-1.bemta-5.messagelabs.com id
	3A/8A-28458-24AB97F4; Mon, 02 Apr 2012 14:40:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333377600!22094944!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23173 invoked from network); 2 Apr 2012 14:40:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:39:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:39:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiQ7-0002Q8-3h; Mon, 02 Apr 2012 14:39:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiQ7-0000o1-36;
	Mon, 02 Apr 2012 15:39:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47667.82965.697908@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:39:47 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <95ab84b43c99e4c9a82c.1333095929@probook.site>
References: <patchbomb.1333095917@probook.site>
	<95ab84b43c99e4c9a82c.1333095929@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 12 of 18] tools/memshr: fix build errors
	caused	by Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 12 of 18] tools/memshr: fix build errors caused by Werror"):
> tools/memshr: fix build errors caused by Werror
...
> Mark fingerprint functions as inline, remove unused variables.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiQS-0006As-AS; Mon, 02 Apr 2012 14:40:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEiQR-0006AN-GE
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:40:07 +0000
Received: from [85.158.139.83:42052] by server-1.bemta-5.messagelabs.com id
	3A/8A-28458-24AB97F4; Mon, 02 Apr 2012 14:40:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333377600!22094944!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23173 invoked from network); 2 Apr 2012 14:40:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:39:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:39:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEiQ7-0002Q8-3h; Mon, 02 Apr 2012 14:39:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEiQ7-0000o1-36;
	Mon, 02 Apr 2012 15:39:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.47667.82965.697908@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 15:39:47 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <95ab84b43c99e4c9a82c.1333095929@probook.site>
References: <patchbomb.1333095917@probook.site>
	<95ab84b43c99e4c9a82c.1333095929@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 12 of 18] tools/memshr: fix build errors
	caused	by Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 12 of 18] tools/memshr: fix build errors caused by Werror"):
> tools/memshr: fix build errors caused by Werror
...
> Mark fingerprint functions as inline, remove unused variables.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiQR-0006Ac-TX; Mon, 02 Apr 2012 14:40:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiQQ-0006A5-02
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:40:06 +0000
Received: from [193.109.254.147:63174] by server-7.bemta-14.messagelabs.com id
	A4/01-01627-54AB97F4; Mon, 02 Apr 2012 14:40:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333377604!583601!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8884 invoked from network); 2 Apr 2012 14:40:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:40:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377603; l=859;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=xOn5mwx3hsgeDnydzPiiYkkgoa4=;
	b=g6YNPaCctrqesk9MEhF1EOQWRQNuEd7CXZtymc2Njn+Tc1IKHe//iYesWCfCjBElmdc
	tO2yretmB0i4f8WKTWBJLKjruqSCBIWIktA2JjoHSBNj/Wmj2PczOYWH/clASmtTrU6e5
	dNQb32KMdgK/Ne9Je8t+Bzst6hAAi/zKUlA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32EOxeF ;
	Mon, 2 Apr 2012 16:40:03 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 3644D18637; Mon,  2 Apr 2012 16:40:03 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:40:03 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402144003.GB4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.45252.747454.411523@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > tools/libvchan: fix build errors caused by -Werror in node-select.c
> > 
> > -O2 -Wall -Werror triggers these warnings:
> > 
> > node-select.c:57:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]
> 
> These changes are correct.
> 
> > node-select.c: In function 'vchan_wr':
> > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> 
> This one is a question of coding style.  Apparently libvchan uses
> mixed statements/declarations, so this should be fixed by changing the
> warning flags.

The warning is odd anyway since -std=gnu99 is requested.
I will split the patch to address both warnings.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiQR-0006Ac-TX; Mon, 02 Apr 2012 14:40:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiQQ-0006A5-02
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:40:06 +0000
Received: from [193.109.254.147:63174] by server-7.bemta-14.messagelabs.com id
	A4/01-01627-54AB97F4; Mon, 02 Apr 2012 14:40:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333377604!583601!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8884 invoked from network); 2 Apr 2012 14:40:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:40:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377603; l=859;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=xOn5mwx3hsgeDnydzPiiYkkgoa4=;
	b=g6YNPaCctrqesk9MEhF1EOQWRQNuEd7CXZtymc2Njn+Tc1IKHe//iYesWCfCjBElmdc
	tO2yretmB0i4f8WKTWBJLKjruqSCBIWIktA2JjoHSBNj/Wmj2PczOYWH/clASmtTrU6e5
	dNQb32KMdgK/Ne9Je8t+Bzst6hAAi/zKUlA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32EOxeF ;
	Mon, 2 Apr 2012 16:40:03 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 3644D18637; Mon,  2 Apr 2012 16:40:03 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:40:03 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402144003.GB4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.45252.747454.411523@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > tools/libvchan: fix build errors caused by -Werror in node-select.c
> > 
> > -O2 -Wall -Werror triggers these warnings:
> > 
> > node-select.c:57:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]
> 
> These changes are correct.
> 
> > node-select.c: In function 'vchan_wr':
> > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> 
> This one is a question of coding style.  Apparently libvchan uses
> mixed statements/declarations, so this should be fixed by changing the
> warning flags.

The warning is odd anyway since -std=gnu99 is requested.
I will split the patch to address both warnings.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:42:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiSG-0006Yt-St; Mon, 02 Apr 2012 14:42:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEiSF-0006YY-24
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:41:59 +0000
Received: from [193.109.254.147:60064] by server-2.bemta-14.messagelabs.com id
	1F/13-19409-6BAB97F4; Mon, 02 Apr 2012 14:41:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333377715!3032931!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11826 invoked from network); 2 Apr 2012 14:41:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Apr 2012 14:41:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEiSB-0002qT-9a
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 07:41:55 -0700
Date: Mon, 2 Apr 2012 07:41:55 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333377715290-5612666.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
	<alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Stefano Stabellini-3 wrote
> 
> On Mon, 2 Apr 2012, Fantu wrote:
>> Fantu wrote
>> > 
>> > 
>> > Fantu wrote
>> >> 
>> >> For many years we used virtualization systems based on xen.
>> >> Up to now we did quite well despite same issue we are trying to solve
>> >> with the new version.
>> >> The main issue that we found are about Windows domU performance and
>> the
>> >> thin client interface with rdp is sometimes problematic.
>> >> We think a possible solution to solve current shortcomings could be
>> qemu
>> >> upstream with spice, qxl and USB redirection.
>> >> We have started preparing a new test system based on Wheezy, the
>> upstream
>> >> kernel and xen 4.2.
>> >> The current test system is:
>> >> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64
>> version
>> >> 3.2.12-1, package blktap-dkms and all dependency packages for xen
>> spice
>> >> and usb redirection.
>> >> -------------------------
>> >> /etc/modules
>> >> ------------
>> >> loop max_loop=64
>> >> xenfs
>> >> xen-evtchn
>> >> blktap
>> >> -------------------------
>> >> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
>> >> 25070)
>> >> vi Makefile # removed dist-kernel to not compile kernel
>> >> -------------------------
>> >> vi Config.mk # qemu upstream unstable and seabios unstable
>> >> ------------
>> >> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
>> >> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
>> >> SEABIOS_UPSTREAM_TAG ?= master
>> >> QEMU_TAG ?= master
>> >> -------------------------
>> >> Added some patches:
>> >> - autoconf: add variable for pass arbitrary options to qemu upstream -
>> my
>> >> patch to build spice and usbredirection on qemu upstream
>> >> - QEMU upstream need to kown the amount of RAM given to a guest. This
>> >> patch give
>> >> the correct value. - Anthony PERARD patch for try to solve
>> ram/videoram
>> >> issue
>> >> - tools: specify datadir for qemu-xen build to fix firmware loading -
>> >> Olaf Hering patch for try to solve qxl issue
>> >> -------------------------
>> >> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
>> >> -------------------------
>> >> vi config/Tools.mk # workaround for libxl compilation problem
>> >> BISON               := bison
>> >> FLEX                := flex
>> >> -------------------------
>> >> make dist
>> >> ./install.sh
>> >> insserv xencommons &&
>> >> insserv xendomains
>> >> 
>> >> 
>> >> Result:
>> >> Full PV domU work, just minimal tests done.
>> >> HVM domU with qemu traditional works but with qemu upstream some
>> problem
>> >> encountered.
>> >> For now I didn't find a way to make Windows run on qemu upstream and
>> >> nothing on logs.
>> >> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
>> >> Spice and usbrediction seem to be working in basic test done now, qxl
>> >> not.
>> >> 
>> >> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on
>> start,
>> >> with qemu unstable it starts but with an allocation problem, on xorg
>> log:
>> >> Out of video memory: Could not allocate 4198400 bytes
>> >> I tried to update also seabios to unstable but same problem.
>> >> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
>> >> 
>> >> Current xl domU configuration file:
>> >> -----------------------------------
>> >> name='PRECISEHVM'
>> >> builder="hvm"
>> >> memory=1024
>> >> #maxmem=1536
>> >> vcpus=2
>> >> #hap=1
>> >> #pae=1
>> >> #acpi=1
>> >> #apic=1
>> >> #nx=1
>> >> vif=['bridge=xenbr0']
>> >> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
>> >> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
>> >> '/dev/sr0,raw,hdb,ro,cdrom']
>> >> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
>> >> boot='c'
>> >> xen_platform_pci=1
>> >> device_model_version='qemu-xen'
>> >> vnc=0
>> >> #vncunused=1
>> >> #vnclisten="0.0.0.0"
>> >> #keymap="it"
>> >> #stdvga=1
>> >> #sdl=0
>> >> spice=1
>> >> spicehost='0.0.0.0'
>> >> spiceport=6000
>> >> spicedisable_ticketing=1
>> >> #spicepasswd='test'
>> >> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> >> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
>> >> device_model_args=["-vga qxl"]
>> >> #device_model_args=["-usb -device usb-ehci"]
>> >> #on_crash='preserve'
>> >> videoram=128
>> >> #bios="ovmf"
>> >> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
>> >>
>> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
>> >>
>> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
>> >>
>> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
>> >> -----------------------------------
>> >> 
>> >> Can someone help to solve these issues?
>> >> Thanks for any reply.
>> >> 
>> > Today I have done other tests: windows xp sp3 installs and runs
>> > successfully on qemu upstream unstable.
>> > Vnc working but too slow, with stdvga improved but not optimal.
>> > Spice with qxl is working but with slow graphic performance. It seems
>> to
>> > have only 4 mb videoram usable (seem to be same with Precise, see
>> quote).
>> > 
>> > This is the current xl configuration:
>> > -------------------------------------
>> > name='XP'
>> > builder="hvm"
>> > memory=1024
>> > vcpus=2
>> > hap=1
>> > pae=1
>> > acpi=1
>> > apic=1
>> > nx=1
>> > vif=['bridge=xenbr0']
>> > #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>> > disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>> > boot='d'
>> > xen_platform_pci=1
>> > viridian=1
>> > device_model_version="qemu-xen"
>> > device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> > vnc=0
>> > #vncunused=1
>> > #vnclisten="0.0.0.0"
>> > #keymap="it"
>> > spice=1
>> > spicehost="0.0.0.0"
>> > spiceport=6000
>> > spicedisable_ticketing=1
>> > on_poweroff="destroy"
>> > on_reboot="restart"
>> > on_crash="destroy"
>> > stdvga=0
>> > device_model_args=["-vga qxl"]
>> > videoram=128
>> > -------------------------------------
>> > 
>> Also Windows 7 is working with qemu upstream, with patches and workaround
>> applied probably, for details see the first post.
> 
> Thank you very much for testing!
> Would you be up for writing a wiki.xen.org page about how to use SPICE
> with Xen?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
Thanks for reply.
About Spice I can't do advanced use and test without before solve videoram
limit to 4 MB problem :(
Can you help about please?
QXL vga can be used also without Spice and could be very useful in solving
the problem of current graphic performances.

--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5612666.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:42:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiSG-0006Yt-St; Mon, 02 Apr 2012 14:42:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEiSF-0006YY-24
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:41:59 +0000
Received: from [193.109.254.147:60064] by server-2.bemta-14.messagelabs.com id
	1F/13-19409-6BAB97F4; Mon, 02 Apr 2012 14:41:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333377715!3032931!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11826 invoked from network); 2 Apr 2012 14:41:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Apr 2012 14:41:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SEiSB-0002qT-9a
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 07:41:55 -0700
Date: Mon, 2 Apr 2012 07:41:55 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333377715290-5612666.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
	<alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Stefano Stabellini-3 wrote
> 
> On Mon, 2 Apr 2012, Fantu wrote:
>> Fantu wrote
>> > 
>> > 
>> > Fantu wrote
>> >> 
>> >> For many years we used virtualization systems based on xen.
>> >> Up to now we did quite well despite same issue we are trying to solve
>> >> with the new version.
>> >> The main issue that we found are about Windows domU performance and
>> the
>> >> thin client interface with rdp is sometimes problematic.
>> >> We think a possible solution to solve current shortcomings could be
>> qemu
>> >> upstream with spice, qxl and USB redirection.
>> >> We have started preparing a new test system based on Wheezy, the
>> upstream
>> >> kernel and xen 4.2.
>> >> The current test system is:
>> >> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64
>> version
>> >> 3.2.12-1, package blktap-dkms and all dependency packages for xen
>> spice
>> >> and usb redirection.
>> >> -------------------------
>> >> /etc/modules
>> >> ------------
>> >> loop max_loop=64
>> >> xenfs
>> >> xen-evtchn
>> >> blktap
>> >> -------------------------
>> >> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
>> >> 25070)
>> >> vi Makefile # removed dist-kernel to not compile kernel
>> >> -------------------------
>> >> vi Config.mk # qemu upstream unstable and seabios unstable
>> >> ------------
>> >> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
>> >> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
>> >> SEABIOS_UPSTREAM_TAG ?= master
>> >> QEMU_TAG ?= master
>> >> -------------------------
>> >> Added some patches:
>> >> - autoconf: add variable for pass arbitrary options to qemu upstream -
>> my
>> >> patch to build spice and usbredirection on qemu upstream
>> >> - QEMU upstream need to kown the amount of RAM given to a guest. This
>> >> patch give
>> >> the correct value. - Anthony PERARD patch for try to solve
>> ram/videoram
>> >> issue
>> >> - tools: specify datadir for qemu-xen build to fix firmware loading -
>> >> Olaf Hering patch for try to solve qxl issue
>> >> -------------------------
>> >> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
>> >> -------------------------
>> >> vi config/Tools.mk # workaround for libxl compilation problem
>> >> BISON               := bison
>> >> FLEX                := flex
>> >> -------------------------
>> >> make dist
>> >> ./install.sh
>> >> insserv xencommons &&
>> >> insserv xendomains
>> >> 
>> >> 
>> >> Result:
>> >> Full PV domU work, just minimal tests done.
>> >> HVM domU with qemu traditional works but with qemu upstream some
>> problem
>> >> encountered.
>> >> For now I didn't find a way to make Windows run on qemu upstream and
>> >> nothing on logs.
>> >> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
>> >> Spice and usbrediction seem to be working in basic test done now, qxl
>> >> not.
>> >> 
>> >> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on
>> start,
>> >> with qemu unstable it starts but with an allocation problem, on xorg
>> log:
>> >> Out of video memory: Could not allocate 4198400 bytes
>> >> I tried to update also seabios to unstable but same problem.
>> >> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
>> >> 
>> >> Current xl domU configuration file:
>> >> -----------------------------------
>> >> name='PRECISEHVM'
>> >> builder="hvm"
>> >> memory=1024
>> >> #maxmem=1536
>> >> vcpus=2
>> >> #hap=1
>> >> #pae=1
>> >> #acpi=1
>> >> #apic=1
>> >> #nx=1
>> >> vif=['bridge=xenbr0']
>> >> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
>> >> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
>> >> '/dev/sr0,raw,hdb,ro,cdrom']
>> >> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
>> >> boot='c'
>> >> xen_platform_pci=1
>> >> device_model_version='qemu-xen'
>> >> vnc=0
>> >> #vncunused=1
>> >> #vnclisten="0.0.0.0"
>> >> #keymap="it"
>> >> #stdvga=1
>> >> #sdl=0
>> >> spice=1
>> >> spicehost='0.0.0.0'
>> >> spiceport=6000
>> >> spicedisable_ticketing=1
>> >> #spicepasswd='test'
>> >> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> >> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
>> >> device_model_args=["-vga qxl"]
>> >> #device_model_args=["-usb -device usb-ehci"]
>> >> #on_crash='preserve'
>> >> videoram=128
>> >> #bios="ovmf"
>> >> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
>> >>
>> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
>> >>
>> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
>> >>
>> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
>> >> -----------------------------------
>> >> 
>> >> Can someone help to solve these issues?
>> >> Thanks for any reply.
>> >> 
>> > Today I have done other tests: windows xp sp3 installs and runs
>> > successfully on qemu upstream unstable.
>> > Vnc working but too slow, with stdvga improved but not optimal.
>> > Spice with qxl is working but with slow graphic performance. It seems
>> to
>> > have only 4 mb videoram usable (seem to be same with Precise, see
>> quote).
>> > 
>> > This is the current xl configuration:
>> > -------------------------------------
>> > name='XP'
>> > builder="hvm"
>> > memory=1024
>> > vcpus=2
>> > hap=1
>> > pae=1
>> > acpi=1
>> > apic=1
>> > nx=1
>> > vif=['bridge=xenbr0']
>> > #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>> > disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>> > boot='d'
>> > xen_platform_pci=1
>> > viridian=1
>> > device_model_version="qemu-xen"
>> > device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> > vnc=0
>> > #vncunused=1
>> > #vnclisten="0.0.0.0"
>> > #keymap="it"
>> > spice=1
>> > spicehost="0.0.0.0"
>> > spiceport=6000
>> > spicedisable_ticketing=1
>> > on_poweroff="destroy"
>> > on_reboot="restart"
>> > on_crash="destroy"
>> > stdvga=0
>> > device_model_args=["-vga qxl"]
>> > videoram=128
>> > -------------------------------------
>> > 
>> Also Windows 7 is working with qemu upstream, with patches and workaround
>> applied probably, for details see the first post.
> 
> Thank you very much for testing!
> Would you be up for writing a wiki.xen.org page about how to use SPICE
> with Xen?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
Thanks for reply.
About Spice I can't do advanced use and test without before solve videoram
limit to 4 MB problem :(
Can you help about please?
QXL vga can be used also without Spice and could be very useful in solving
the problem of current graphic performances.

--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5612666.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiT4-0006iT-Ge; Mon, 02 Apr 2012 14:42:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiT3-0006hu-9D
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:42:49 +0000
Received: from [85.158.143.99:3253] by server-3.bemta-4.messagelabs.com id
	B5/4B-05853-8EAB97F4; Mon, 02 Apr 2012 14:42:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333377767!21640433!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3123 invoked from network); 2 Apr 2012 14:42:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:42:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377767; l=131;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=w/ATRZQH0r3omKw2kl5fntXiB3g=;
	b=OOqCz0OADNBoxN1mRKo6t490YBXHxCxGRJBb4xh6fhMkphu29QX5SR4hFDkueuldcHH
	KD+amMd9FM5IUb4E2ohtYw/Fz+f3lduPus5bLSPjqytoA0coIC9zfSEaplt19ZNP5LiVi
	QuyAR6/WwAQ87sXn6JtgyDB4daLS1ztjkFQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo25) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2063c6o32EIQdU ;
	Mon, 2 Apr 2012 16:42:47 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 957A318637; Mon,  2 Apr 2012 16:42:46 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:42:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402144246.GC4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20345.45547.261495.199611@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.45547.261495.199611@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> The point I was making is that it does not increment (*p).

Yes, you are right.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiT4-0006iT-Ge; Mon, 02 Apr 2012 14:42:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiT3-0006hu-9D
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:42:49 +0000
Received: from [85.158.143.99:3253] by server-3.bemta-4.messagelabs.com id
	B5/4B-05853-8EAB97F4; Mon, 02 Apr 2012 14:42:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333377767!21640433!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3123 invoked from network); 2 Apr 2012 14:42:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:42:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377767; l=131;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=w/ATRZQH0r3omKw2kl5fntXiB3g=;
	b=OOqCz0OADNBoxN1mRKo6t490YBXHxCxGRJBb4xh6fhMkphu29QX5SR4hFDkueuldcHH
	KD+amMd9FM5IUb4E2ohtYw/Fz+f3lduPus5bLSPjqytoA0coIC9zfSEaplt19ZNP5LiVi
	QuyAR6/WwAQ87sXn6JtgyDB4daLS1ztjkFQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo25) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2063c6o32EIQdU ;
	Mon, 2 Apr 2012 16:42:47 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 957A318637; Mon,  2 Apr 2012 16:42:46 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:42:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402144246.GC4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20345.45547.261495.199611@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.45547.261495.199611@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> The point I was making is that it does not increment (*p).

Yes, you are right.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:44:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiUq-0006z5-1D; Mon, 02 Apr 2012 14:44:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiUo-0006yl-Ex
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:44:38 +0000
Received: from [85.158.139.83:22921] by server-3.bemta-5.messagelabs.com id
	24/A9-25237-55BB97F4; Mon, 02 Apr 2012 14:44:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333377876!22113744!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24203 invoked from network); 2 Apr 2012 14:44:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:44:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377876; l=1042;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=wG+NqQwuxMz7iBbjhm/D29oyFNg=;
	b=G2xg+6Toq1+g3+tHT89O6b+Kr2L9DDbyO5SL3om85taHCBrN71U8xT4YcOOYryVXGXf
	MBBtYZqfl0iCWD/nZJK7SSmELfaeT/OKJFjS93s1wDyG0KfwjB5k24Aa7Uz/uwKayh58c
	pI4AaWSLka7dp8zlGqLH6X+YJn0roriBwBo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo42) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id J06e29o32ChZ2x ;
	Mon, 2 Apr 2012 16:44:36 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id A14B118637; Mon,  2 Apr 2012 16:44:35 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:44:35 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402144435.GD4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.44502.306179.202932@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > xs_api.c: In function 'convert_dev_name_to_num':
> ...
> > ptr should be increased in each iteration, not the char it points to.
> 
> These changes from `*p++;' to `p++' are correct.  But the description
> is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> uselessly dereferences it.
> 
> > -	char *p_sd = "/dev/sd";
> > -	char *p_hd = "/dev/hd";
> > -	char *p_xvd = "/dev/xvd";
> > -	char *p_plx = "plx";
> > -	char *alpha = "abcdefghijklmnop";
> > +	static const char p_sd[] = "/dev/sd";
> > +	static const char p_hd[] = "/dev/hd";
> > +	static const char p_xvd[] = "/dev/xvd";
> > +	static const char p_plx[] = "plx";
> > +	static const char alpha[] = "abcdefghijklmnop";
> 
> And this hunk seems entirely unexplained.  Is it supposed to be a
> const-correctness fix ?  Stylistic improvement ?

I think that part is not strictly needed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:44:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiUq-0006z5-1D; Mon, 02 Apr 2012 14:44:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEiUo-0006yl-Ex
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:44:38 +0000
Received: from [85.158.139.83:22921] by server-3.bemta-5.messagelabs.com id
	24/A9-25237-55BB97F4; Mon, 02 Apr 2012 14:44:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333377876!22113744!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24203 invoked from network); 2 Apr 2012 14:44:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 14:44:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333377876; l=1042;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=wG+NqQwuxMz7iBbjhm/D29oyFNg=;
	b=G2xg+6Toq1+g3+tHT89O6b+Kr2L9DDbyO5SL3om85taHCBrN71U8xT4YcOOYryVXGXf
	MBBtYZqfl0iCWD/nZJK7SSmELfaeT/OKJFjS93s1wDyG0KfwjB5k24Aa7Uz/uwKayh58c
	pI4AaWSLka7dp8zlGqLH6X+YJn0roriBwBo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo42) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id J06e29o32ChZ2x ;
	Mon, 2 Apr 2012 16:44:36 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id A14B118637; Mon,  2 Apr 2012 16:44:35 +0200 (CEST)
Date: Mon, 2 Apr 2012 16:44:35 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402144435.GD4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.44502.306179.202932@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > xs_api.c: In function 'convert_dev_name_to_num':
> ...
> > ptr should be increased in each iteration, not the char it points to.
> 
> These changes from `*p++;' to `p++' are correct.  But the description
> is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> uselessly dereferences it.
> 
> > -	char *p_sd = "/dev/sd";
> > -	char *p_hd = "/dev/hd";
> > -	char *p_xvd = "/dev/xvd";
> > -	char *p_plx = "plx";
> > -	char *alpha = "abcdefghijklmnop";
> > +	static const char p_sd[] = "/dev/sd";
> > +	static const char p_hd[] = "/dev/hd";
> > +	static const char p_xvd[] = "/dev/xvd";
> > +	static const char p_plx[] = "plx";
> > +	static const char alpha[] = "abcdefghijklmnop";
> 
> And this hunk seems entirely unexplained.  Is it supposed to be a
> const-correctness fix ?  Stylistic improvement ?

I think that part is not strictly needed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:46:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiWK-00079H-KJ; Mon, 02 Apr 2012 14:46:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEiWI-000796-Lf
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:46:10 +0000
Received: from [85.158.139.83:35963] by server-1.bemta-5.messagelabs.com id
	D5/67-28458-1BBB97F4; Mon, 02 Apr 2012 14:46:09 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333377967!22097481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31918 invoked from network); 2 Apr 2012 14:46:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="23783153"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:46:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 10:46:06 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEiWE-0003le-KW;
	Mon, 02 Apr 2012 15:46:06 +0100
Message-ID: <4F79BB94.50003@eu.citrix.com>
Date: Mon, 2 Apr 2012 15:45:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1333363655@kodo2>
	<5386937e6c5c9afaa8a3.1333363656@kodo2>
	<1333364737.25602.47.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333364737.25602.47.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 12:05, Ian Campbell wrote:
> On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
>> # HG changeset patch
>> # User George Dunlap<george.dunlap@eu.citrix.com>
>> # Date 1333362574 -3600
>> # Node ID 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
>> # Parent  f744e82ea74075983de6d5b0ad0cf7ccacf999a2
>> libxl: Move bdf parsing into libxlu
>>
>> Config parsing functions do not properly belong in libxl.  Move them into
>> libxlu so that others can use them or not as they see fit.
>>
>> No functional changes.  One side-effect was making public a private libxl
>> utility function which just set the elements of a structure from the  function
>> arguments passed in.
>> [...]
>> diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl.h
>> --- a/tools/libxl/libxl.h       Wed Feb 29 16:30:34 2012 +0000
>> +++ b/tools/libxl/libxl.h       Mon Apr 02 11:29:34 2012 +0100
>> @@ -573,13 +573,10 @@ int libxl_device_pci_add(libxl_ctx *ctx,
>>   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>>   int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>>   libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
>> -
>> -/*
>> - * Parse a PCI BDF into a PCI device structure.
>> - */
>> -int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
>> -                               libxl_device_pci *pcidev,
>> -                               const char *str);
>> +/* Just initialize the structure elements with the arguments provided. */
>> +int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
>> +                       unsigned int bus, unsigned int dev,
>> +                       unsigned int func, unsigned int vdevfn);
> libxl_<type>_init has a particular meaning described further up in this
> header. Although you haven't actually used<type>  here so it doesn't
> conflict the general convention is to use the type name as a prefix.
>
> Does this function actually add all that much value? The users of it
> could either open code it or have a local version.
You know, I think I'll just make two local copies of the function.  I'll 
also give it a less misleading name.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:46:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiWK-00079H-KJ; Mon, 02 Apr 2012 14:46:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEiWI-000796-Lf
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:46:10 +0000
Received: from [85.158.139.83:35963] by server-1.bemta-5.messagelabs.com id
	D5/67-28458-1BBB97F4; Mon, 02 Apr 2012 14:46:09 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333377967!22097481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31918 invoked from network); 2 Apr 2012 14:46:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="23783153"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 10:46:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 10:46:06 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEiWE-0003le-KW;
	Mon, 02 Apr 2012 15:46:06 +0100
Message-ID: <4F79BB94.50003@eu.citrix.com>
Date: Mon, 2 Apr 2012 15:45:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1333363655@kodo2>
	<5386937e6c5c9afaa8a3.1333363656@kodo2>
	<1333364737.25602.47.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333364737.25602.47.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 12:05, Ian Campbell wrote:
> On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
>> # HG changeset patch
>> # User George Dunlap<george.dunlap@eu.citrix.com>
>> # Date 1333362574 -3600
>> # Node ID 5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
>> # Parent  f744e82ea74075983de6d5b0ad0cf7ccacf999a2
>> libxl: Move bdf parsing into libxlu
>>
>> Config parsing functions do not properly belong in libxl.  Move them into
>> libxlu so that others can use them or not as they see fit.
>>
>> No functional changes.  One side-effect was making public a private libxl
>> utility function which just set the elements of a structure from the  function
>> arguments passed in.
>> [...]
>> diff -r f744e82ea740 -r 5386937e6c5c tools/libxl/libxl.h
>> --- a/tools/libxl/libxl.h       Wed Feb 29 16:30:34 2012 +0000
>> +++ b/tools/libxl/libxl.h       Mon Apr 02 11:29:34 2012 +0100
>> @@ -573,13 +573,10 @@ int libxl_device_pci_add(libxl_ctx *ctx,
>>   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>>   int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
>>   libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
>> -
>> -/*
>> - * Parse a PCI BDF into a PCI device structure.
>> - */
>> -int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
>> -                               libxl_device_pci *pcidev,
>> -                               const char *str);
>> +/* Just initialize the structure elements with the arguments provided. */
>> +int libxl_pci_dev_init(libxl_device_pci *pcidev, unsigned int domain,
>> +                       unsigned int bus, unsigned int dev,
>> +                       unsigned int func, unsigned int vdevfn);
> libxl_<type>_init has a particular meaning described further up in this
> header. Although you haven't actually used<type>  here so it doesn't
> conflict the general convention is to use the type name as a prefix.
>
> Does this function actually add all that much value? The users of it
> could either open code it or have a local version.
You know, I think I'll just make two local copies of the function.  I'll 
also give it a less misleading name.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiWd-0007Bf-0S; Mon, 02 Apr 2012 14:46:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEiWb-0007BN-IB
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:46:29 +0000
Received: from [85.158.143.99:53317] by server-1.bemta-4.messagelabs.com id
	75/5B-20925-4CBB97F4; Mon, 02 Apr 2012 14:46:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333377986!21641176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24763 invoked from network); 2 Apr 2012 14:46:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:46:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:46:25 +0100
Date: Mon, 2 Apr 2012 15:48:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
In-Reply-To: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 1 Apr 2012, Joseph Glanville wrote:
> Hi guys,
> 
> I have started preparing a library of PV-HVM templates for use on Xen
> 4.X+ and PVOPS dom0.
> This was brought up late last year as something that would make Xen
> alot easier for beginners to try.
> They are also great for testing - I will be setting up some stuff to
> do automatic testing of distro kernel compatibility against
> xen-unstable.
>
> Mirror page is here:
> 
>     http://mirror.orionvm.com.au
> 
> You can browse what stuff I will be mirroring here:
> 
>     http://mirror.orionvm.com.au/pub/
> 
> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> (the final beta, will be updated to final shortly).
> Included is an OS image, a config file, a README and the associated
> licences etc.

Great idea! I am downloading the debian6 bz2 image right now, I'll let
you know if I find any issues.


> The images are bz2 compressed blockdevice images suitable for use on
> LVM or a file backed tapdisk if you have the appropriate backend.
> (alternatively you can use the loop device but this is discouraged)
> All images have serial console enabled, PV network and block devices,
> fixed udev rules etc.

I have just fixed the QDISK performance issues so as soon as the patches
are applied to xen-unstable one should be able to use QEMU as disk
backend just a easily.


Maybe we should write a wiki page about this and link
http://mirror.orionvm.com.au/pub/ from there.
Lars, what do you think about it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiWd-0007Bf-0S; Mon, 02 Apr 2012 14:46:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEiWb-0007BN-IB
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:46:29 +0000
Received: from [85.158.143.99:53317] by server-1.bemta-4.messagelabs.com id
	75/5B-20925-4CBB97F4; Mon, 02 Apr 2012 14:46:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333377986!21641176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24763 invoked from network); 2 Apr 2012 14:46:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:46:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:46:25 +0100
Date: Mon, 2 Apr 2012 15:48:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
In-Reply-To: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 1 Apr 2012, Joseph Glanville wrote:
> Hi guys,
> 
> I have started preparing a library of PV-HVM templates for use on Xen
> 4.X+ and PVOPS dom0.
> This was brought up late last year as something that would make Xen
> alot easier for beginners to try.
> They are also great for testing - I will be setting up some stuff to
> do automatic testing of distro kernel compatibility against
> xen-unstable.
>
> Mirror page is here:
> 
>     http://mirror.orionvm.com.au
> 
> You can browse what stuff I will be mirroring here:
> 
>     http://mirror.orionvm.com.au/pub/
> 
> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> (the final beta, will be updated to final shortly).
> Included is an OS image, a config file, a README and the associated
> licences etc.

Great idea! I am downloading the debian6 bz2 image right now, I'll let
you know if I find any issues.


> The images are bz2 compressed blockdevice images suitable for use on
> LVM or a file backed tapdisk if you have the appropriate backend.
> (alternatively you can use the loop device but this is discouraged)
> All images have serial console enabled, PV network and block devices,
> fixed udev rules etc.

I have just fixed the QDISK performance issues so as soon as the patches
are applied to xen-unstable one should be able to use QEMU as disk
backend just a easily.


Maybe we should write a wiki page about this and link
http://mirror.orionvm.com.au/pub/ from there.
Lars, what do you think about it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:51:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEibe-0007ia-Dd; Mon, 02 Apr 2012 14:51:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEibd-0007iR-Ex
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:51:41 +0000
Received: from [85.158.139.83:26650] by server-10.bemta-5.messagelabs.com id
	88/F8-08260-CFCB97F4; Mon, 02 Apr 2012 14:51:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333378300!22012123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17534 invoked from network); 2 Apr 2012 14:51:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:51:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:51:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:51:39 +0100
Date: Mon, 2 Apr 2012 15:53:41 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: James Harper <james.harper@bendigoit.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
Message-ID: <alpine.DEB.2.00.1204021549280.15151@kaball-desktop>
References: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu reverse vnc connection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 1 Apr 2012, James Harper wrote:
> I was looking at vnc.c to see what would be involved in making a reverse VNC connection (vnc server connects to the client), and it looks possible but I also wondered if there was any reason why libvncserver couldn't be used instead? Both qemu-dm and libvncserver appear to be licensed under GPL although I haven't checked what version.

A (very) long time ago a decision was made whether to use libvncserver
or not in QEMU and now we are too far down the road to change it.
Besides we are switching to upstream QEMU so we try to keep our changes
to QEMU's tree as small as possible.


> I've never figured out whether it's qemu's vnc implementation or VNCViewer but one of them seems pretty buggy - freezing and requiring frequent refreshes under some circumstances, and occasionally not liking resolution changes.

Few years ago I have done some investigations and I seem to recall that
the problem lies with vncviewer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 14:51:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 14:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEibe-0007ia-Dd; Mon, 02 Apr 2012 14:51:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEibd-0007iR-Ex
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 14:51:41 +0000
Received: from [85.158.139.83:26650] by server-10.bemta-5.messagelabs.com id
	88/F8-08260-CFCB97F4; Mon, 02 Apr 2012 14:51:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333378300!22012123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17534 invoked from network); 2 Apr 2012 14:51:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 14:51:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 14:51:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 15:51:39 +0100
Date: Mon, 2 Apr 2012 15:53:41 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: James Harper <james.harper@bendigoit.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
Message-ID: <alpine.DEB.2.00.1204021549280.15151@kaball-desktop>
References: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu reverse vnc connection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 1 Apr 2012, James Harper wrote:
> I was looking at vnc.c to see what would be involved in making a reverse VNC connection (vnc server connects to the client), and it looks possible but I also wondered if there was any reason why libvncserver couldn't be used instead? Both qemu-dm and libvncserver appear to be licensed under GPL although I haven't checked what version.

A (very) long time ago a decision was made whether to use libvncserver
or not in QEMU and now we are too far down the road to change it.
Besides we are switching to upstream QEMU so we try to keep our changes
to QEMU's tree as small as possible.


> I've never figured out whether it's qemu's vnc implementation or VNCViewer but one of them seems pretty buggy - freezing and requiring frequent refreshes under some circumstances, and occasionally not liking resolution changes.

Few years ago I have done some investigations and I seem to recall that
the problem lies with vncviewer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:00:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEik4-00080f-EQ; Mon, 02 Apr 2012 15:00:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEik2-00080Z-BQ
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:00:22 +0000
Received: from [193.109.254.147:61618] by server-6.bemta-14.messagelabs.com id
	E9/5F-02047-50FB97F4; Mon, 02 Apr 2012 15:00:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333378811!3062386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11714 invoked from network); 2 Apr 2012 15:00:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:00:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:00:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEijr-0002bO-7H; Mon, 02 Apr 2012 15:00:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEijr-0000pU-5m;
	Mon, 02 Apr 2012 16:00:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.48891.162276.828728@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:00:11 +0100
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your submission; this is coming along but still needs some
work.

Joseph Glanville writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> On 31 March 2012 05:08, Joseph Glanville
> <joseph.glanville@orionvm.com.au> wrote:
> +        execvpe(arg0,args,envp);

I'm afraid that execvpe doesn't do what you want: it entirely replaces
the environment with the one you specify.  You need to use putenv or
setenv.

> +    if (xlu_cfg_replace_string (config, "shutdown_event_handler",
> +                            &d_config->shutdown_event_handler, 0))
> +        d_config->shutdown_event_handler = NULL;

Weren't we going to have one event handler per type of event ?

> +{
> +    int status;
> +    useconds_t sleep_time = 10, wait_time = 0;
> +    pid_t child_pid, wpid;

I'm afraid this timeout approach is not correct; you would need
something to interrupt the wait, rather than polling like this.  I
think this is impractical.  You should, rather, just not implement a
timeout.

I would advise against reusing exit statuses 0..6.  You should start
your new exit statuses at 50 or something.  This is because many
programs use status 1 to mean "I failed" and you would want to avoid
that being misinterpreted.

Other exit statuses, and deaths due to signals, should be reported
properly as errors using libxl_report_child_exitstatus.

> +    ret = xl_exec(arg0,argv,envp,timeout);

I think calling this function xl_exec is a bit unfortunate.  It
doesn't just exec; it also forks.

> +	if (d_config->shutdown_event_handler)
> +        action = user_shutdown_action(d_config, domid, action,
> +
> event->u.domain_shutdown.shutdown_reason);

Something has linewrapped this.  You should keep to within 75-80
lines.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:00:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEik4-00080f-EQ; Mon, 02 Apr 2012 15:00:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEik2-00080Z-BQ
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:00:22 +0000
Received: from [193.109.254.147:61618] by server-6.bemta-14.messagelabs.com id
	E9/5F-02047-50FB97F4; Mon, 02 Apr 2012 15:00:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333378811!3062386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11714 invoked from network); 2 Apr 2012 15:00:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:00:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:00:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEijr-0002bO-7H; Mon, 02 Apr 2012 15:00:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEijr-0000pU-5m;
	Mon, 02 Apr 2012 16:00:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.48891.162276.828728@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:00:11 +0100
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your submission; this is coming along but still needs some
work.

Joseph Glanville writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> On 31 March 2012 05:08, Joseph Glanville
> <joseph.glanville@orionvm.com.au> wrote:
> +        execvpe(arg0,args,envp);

I'm afraid that execvpe doesn't do what you want: it entirely replaces
the environment with the one you specify.  You need to use putenv or
setenv.

> +    if (xlu_cfg_replace_string (config, "shutdown_event_handler",
> +                            &d_config->shutdown_event_handler, 0))
> +        d_config->shutdown_event_handler = NULL;

Weren't we going to have one event handler per type of event ?

> +{
> +    int status;
> +    useconds_t sleep_time = 10, wait_time = 0;
> +    pid_t child_pid, wpid;

I'm afraid this timeout approach is not correct; you would need
something to interrupt the wait, rather than polling like this.  I
think this is impractical.  You should, rather, just not implement a
timeout.

I would advise against reusing exit statuses 0..6.  You should start
your new exit statuses at 50 or something.  This is because many
programs use status 1 to mean "I failed" and you would want to avoid
that being misinterpreted.

Other exit statuses, and deaths due to signals, should be reported
properly as errors using libxl_report_child_exitstatus.

> +    ret = xl_exec(arg0,argv,envp,timeout);

I think calling this function xl_exec is a bit unfortunate.  It
doesn't just exec; it also forks.

> +	if (d_config->shutdown_event_handler)
> +        action = user_shutdown_action(d_config, domid, action,
> +
> event->u.domain_shutdown.shutdown_reason);

Something has linewrapped this.  You should keep to within 75-80
lines.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiku-00083j-SJ; Mon, 02 Apr 2012 15:01:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEikt-00083a-Lj
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:01:15 +0000
Received: from [85.158.143.35:46243] by server-1.bemta-4.messagelabs.com id
	BC/65-20925-B3FB97F4; Mon, 02 Apr 2012 15:01:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1333378874!5033688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25059 invoked from network); 2 Apr 2012 15:01:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:01:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:01:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:01:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEikr-0002bl-W2; Mon, 02 Apr 2012 15:01:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEikr-0000ps-VD;
	Mon, 02 Apr 2012 16:01:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.48953.952902.407000@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:01:13 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120330140640.GA90203@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> tools: Fix FPU save area definition in xen-hvmctx
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Tim Deegan <tim@xen.org>

Urgh.  This seems plausible.  (The repetition of the constant "16" is
unfortunate but we don't have ARRAY_SIZE Here...)

I intend to apply Tim's patch unless anyone objects.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEiku-00083j-SJ; Mon, 02 Apr 2012 15:01:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEikt-00083a-Lj
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:01:15 +0000
Received: from [85.158.143.35:46243] by server-1.bemta-4.messagelabs.com id
	BC/65-20925-B3FB97F4; Mon, 02 Apr 2012 15:01:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1333378874!5033688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25059 invoked from network); 2 Apr 2012 15:01:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:01:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:01:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:01:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEikr-0002bl-W2; Mon, 02 Apr 2012 15:01:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEikr-0000ps-VD;
	Mon, 02 Apr 2012 16:01:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.48953.952902.407000@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:01:13 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120330140640.GA90203@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> tools: Fix FPU save area definition in xen-hvmctx
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Tim Deegan <tim@xen.org>

Urgh.  This seems plausible.  (The repetition of the constant "16" is
unfortunate but we don't have ARRAY_SIZE Here...)

I intend to apply Tim's patch unless anyone objects.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:02:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEilx-00089U-B4; Mon, 02 Apr 2012 15:02:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEilw-00089K-DP
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:02:20 +0000
Received: from [85.158.139.83:57004] by server-12.bemta-5.messagelabs.com id
	54/4C-05587-B7FB97F4; Mon, 02 Apr 2012 15:02:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333378938!19391462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19548 invoked from network); 2 Apr 2012 15:02:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:02:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:02:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:02:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEilu-0002cD-5H; Mon, 02 Apr 2012 15:02:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEilu-0000q8-4X;
	Mon, 02 Apr 2012 16:02:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.49018.121478.756719@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:02:18 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <34d9828185501f6e7ea2.1333120245@probook.site>
References: <34d9828185501f6e7ea2.1333120245@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: add error code to indicate
	iommem	passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: add error code to indicate iommem passthrough"):
> xenpaging: add error code to indicate iommem passthrough
> 
> Similar to the existing ENODEV and EXDEV error codes, add EMDEV to
> indicate that iommu passthrough is not compatible with paging.
> All error codes are just made-up return codes to give proper error
> messages in the pager.
> 
> Also update the HAP related error message now that paging is enabled
> also on AMD hosts.

The tools parts of this are fine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:02:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEilx-00089U-B4; Mon, 02 Apr 2012 15:02:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEilw-00089K-DP
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:02:20 +0000
Received: from [85.158.139.83:57004] by server-12.bemta-5.messagelabs.com id
	54/4C-05587-B7FB97F4; Mon, 02 Apr 2012 15:02:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333378938!19391462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19548 invoked from network); 2 Apr 2012 15:02:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:02:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:02:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:02:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEilu-0002cD-5H; Mon, 02 Apr 2012 15:02:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEilu-0000q8-4X;
	Mon, 02 Apr 2012 16:02:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.49018.121478.756719@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:02:18 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <34d9828185501f6e7ea2.1333120245@probook.site>
References: <34d9828185501f6e7ea2.1333120245@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: add error code to indicate
	iommem	passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: add error code to indicate iommem passthrough"):
> xenpaging: add error code to indicate iommem passthrough
> 
> Similar to the existing ENODEV and EXDEV error codes, add EMDEV to
> indicate that iommu passthrough is not compatible with paging.
> All error codes are just made-up return codes to give proper error
> messages in the pager.
> 
> Also update the HAP related error message now that paging is enabled
> also on AMD hosts.

The tools parts of this are fine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:02:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEim2-0008Ag-Re; Mon, 02 Apr 2012 15:02:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEim1-0008AG-Gi
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:02:25 +0000
Received: from [85.158.139.83:57429] by server-2.bemta-5.messagelabs.com id
	76/5E-17016-08FB97F4; Mon, 02 Apr 2012 15:02:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333378938!19391462!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19813 invoked from network); 2 Apr 2012 15:02:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:02:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	16:02:24 +0100
Message-ID: <1333378942.25602.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:02:22 +0100
In-Reply-To: <alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>,
	"staff@orionvm.com.au" <staff@orionvm.com.au>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 15:48 +0100, Stefano Stabellini wrote:

> Maybe we should write a wiki page about this and link
> http://mirror.orionvm.com.au/pub/ from there.

Joseph already wrote http://wiki.xen.org/wiki/Guest_VM_Images if that's
what you meant.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:02:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEim2-0008Ag-Re; Mon, 02 Apr 2012 15:02:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEim1-0008AG-Gi
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:02:25 +0000
Received: from [85.158.139.83:57429] by server-2.bemta-5.messagelabs.com id
	76/5E-17016-08FB97F4; Mon, 02 Apr 2012 15:02:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333378938!19391462!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19813 invoked from network); 2 Apr 2012 15:02:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:02:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	16:02:24 +0100
Message-ID: <1333378942.25602.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:02:22 +0100
In-Reply-To: <alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>,
	"staff@orionvm.com.au" <staff@orionvm.com.au>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 15:48 +0100, Stefano Stabellini wrote:

> Maybe we should write a wiki page about this and link
> http://mirror.orionvm.com.au/pub/ from there.

Joseph already wrote http://wiki.xen.org/wiki/Guest_VM_Images if that's
what you meant.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:04:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:04:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEine-0008Uq-Va; Mon, 02 Apr 2012 15:04:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEind-0008UI-D4
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:04:05 +0000
Received: from [85.158.143.99:32501] by server-3.bemta-4.messagelabs.com id
	BE/63-05853-4EFB97F4; Mon, 02 Apr 2012 15:04:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333379043!21911417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22352 invoked from network); 2 Apr 2012 15:04:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:04:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725861"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:04:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:04:03 +0100
Date: Mon, 2 Apr 2012 16:06:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333378942.25602.83.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204021605490.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
	<1333378942.25602.83.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Lars Kurth <lars.kurth@xen.org>,
	Joseph Glanville <joseph.glanville@orionvm.com.au>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Campbell wrote:
> On Mon, 2012-04-02 at 15:48 +0100, Stefano Stabellini wrote:
> 
> > Maybe we should write a wiki page about this and link
> > http://mirror.orionvm.com.au/pub/ from there.
> 
> Joseph already wrote http://wiki.xen.org/wiki/Guest_VM_Images if that's
> what you meant.

that is exactly what I meant

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:04:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:04:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEine-0008Uq-Va; Mon, 02 Apr 2012 15:04:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SEind-0008UI-D4
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:04:05 +0000
Received: from [85.158.143.99:32501] by server-3.bemta-4.messagelabs.com id
	BE/63-05853-4EFB97F4; Mon, 02 Apr 2012 15:04:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333379043!21911417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22352 invoked from network); 2 Apr 2012 15:04:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:04:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725861"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:04:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:04:03 +0100
Date: Mon, 2 Apr 2012 16:06:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333378942.25602.83.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204021605490.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<alpine.DEB.2.00.1204021543100.15151@kaball-desktop>
	<1333378942.25602.83.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Lars Kurth <lars.kurth@xen.org>,
	Joseph Glanville <joseph.glanville@orionvm.com.au>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Campbell wrote:
> On Mon, 2012-04-02 at 15:48 +0100, Stefano Stabellini wrote:
> 
> > Maybe we should write a wiki page about this and link
> > http://mirror.orionvm.com.au/pub/ from there.
> 
> Joseph already wrote http://wiki.xen.org/wiki/Guest_VM_Images if that's
> what you meant.

that is exactly what I meant

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:04:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEing-0008VE-16; Mon, 02 Apr 2012 15:04:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEine-0008UZ-F0
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:04:06 +0000
Received: from [85.158.143.99:42478] by server-2.bemta-4.messagelabs.com id
	00/89-17550-5EFB97F4; Mon, 02 Apr 2012 15:04:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333379043!21911417!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22458 invoked from network); 2 Apr 2012 15:04:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:04:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	16:04:04 +0100
Message-ID: <1333379043.25602.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 2 Apr 2012 16:04:03 +0100
In-Reply-To: <20120402144435.GD4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20120402144435.GD4000@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 15:44 +0100, Olaf Hering wrote:
> On Mon, Apr 02, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > > xs_api.c: In function 'convert_dev_name_to_num':
> > ...
> > > ptr should be increased in each iteration, not the char it points to.
> > 
> > These changes from `*p++;' to `p++' are correct.  But the description
> > is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> > uselessly dereferences it.
> > 
> > > -	char *p_sd = "/dev/sd";
> > > -	char *p_hd = "/dev/hd";
> > > -	char *p_xvd = "/dev/xvd";
> > > -	char *p_plx = "plx";
> > > -	char *alpha = "abcdefghijklmnop";
> > > +	static const char p_sd[] = "/dev/sd";
> > > +	static const char p_hd[] = "/dev/hd";
> > > +	static const char p_xvd[] = "/dev/xvd";
> > > +	static const char p_plx[] = "plx";
> > > +	static const char alpha[] = "abcdefghijklmnop";
> > 
> > And this hunk seems entirely unexplained.  Is it supposed to be a
> > const-correctness fix ?  Stylistic improvement ?
> 
> I think that part is not strictly needed.

Adding the const seems reasonable enough. Not sure what the static buys
you on top of that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:04:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEing-0008VE-16; Mon, 02 Apr 2012 15:04:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEine-0008UZ-F0
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:04:06 +0000
Received: from [85.158.143.99:42478] by server-2.bemta-4.messagelabs.com id
	00/89-17550-5EFB97F4; Mon, 02 Apr 2012 15:04:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333379043!21911417!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22458 invoked from network); 2 Apr 2012 15:04:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11725864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:04:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	16:04:04 +0100
Message-ID: <1333379043.25602.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 2 Apr 2012 16:04:03 +0100
In-Reply-To: <20120402144435.GD4000@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20120402144435.GD4000@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 15:44 +0100, Olaf Hering wrote:
> On Mon, Apr 02, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > > xs_api.c: In function 'convert_dev_name_to_num':
> > ...
> > > ptr should be increased in each iteration, not the char it points to.
> > 
> > These changes from `*p++;' to `p++' are correct.  But the description
> > is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> > uselessly dereferences it.
> > 
> > > -	char *p_sd = "/dev/sd";
> > > -	char *p_hd = "/dev/hd";
> > > -	char *p_xvd = "/dev/xvd";
> > > -	char *p_plx = "plx";
> > > -	char *alpha = "abcdefghijklmnop";
> > > +	static const char p_sd[] = "/dev/sd";
> > > +	static const char p_hd[] = "/dev/hd";
> > > +	static const char p_xvd[] = "/dev/xvd";
> > > +	static const char p_plx[] = "plx";
> > > +	static const char alpha[] = "abcdefghijklmnop";
> > 
> > And this hunk seems entirely unexplained.  Is it supposed to be a
> > const-correctness fix ?  Stylistic improvement ?
> 
> I think that part is not strictly needed.

Adding the const seems reasonable enough. Not sure what the static buys
you on top of that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:08:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEirx-0000rQ-NJ; Mon, 02 Apr 2012 15:08:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEirw-0000r8-CW
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:08:32 +0000
Received: from [85.158.138.51:59629] by server-2.bemta-3.messagelabs.com id
	9D/1E-15460-FE0C97F4; Mon, 02 Apr 2012 15:08:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333379310!20442435!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23203 invoked from network); 2 Apr 2012 15:08:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 15:08:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333379310; l=1406;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=xk/lMwpUSZD1JyHRhN8D83STWsY=;
	b=xU814UO1Mfy5d1dOQ2zWgJzhfHj/kcnzFEMap6uRZlUbPiwI1puoK7cUrWDJvJol1DB
	TiRin7v0J9o98U39dqZ4b9sqBIx/+1dGcMvWrhh14REcBTGYaVqS3xs/ZIc9kTow3bKxX
	sOJEWf5wNRcdU/ysqK5qdh1rm0SzdR9/qys=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo21) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602919o32E4TFY ;
	Mon, 2 Apr 2012 17:08:30 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id BEDEF18637; Mon,  2 Apr 2012 17:08:29 +0200 (CEST)
Date: Mon, 2 Apr 2012 17:08:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120402150829.GA5043@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20120402144435.GD4000@aepfle.de>
	<1333379043.25602.85.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333379043.25602.85.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Campbell wrote:

> On Mon, 2012-04-02 at 15:44 +0100, Olaf Hering wrote:
> > On Mon, Apr 02, Ian Jackson wrote:
> > 
> > > Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > > > xs_api.c: In function 'convert_dev_name_to_num':
> > > ...
> > > > ptr should be increased in each iteration, not the char it points to.
> > > 
> > > These changes from `*p++;' to `p++' are correct.  But the description
> > > is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> > > uselessly dereferences it.
> > > 
> > > > -	char *p_sd = "/dev/sd";
> > > > -	char *p_hd = "/dev/hd";
> > > > -	char *p_xvd = "/dev/xvd";
> > > > -	char *p_plx = "plx";
> > > > -	char *alpha = "abcdefghijklmnop";
> > > > +	static const char p_sd[] = "/dev/sd";
> > > > +	static const char p_hd[] = "/dev/hd";
> > > > +	static const char p_xvd[] = "/dev/xvd";
> > > > +	static const char p_plx[] = "plx";
> > > > +	static const char alpha[] = "abcdefghijklmnop";
> > > 
> > > And this hunk seems entirely unexplained.  Is it supposed to be a
> > > const-correctness fix ?  Stylistic improvement ?
> > 
> > I think that part is not strictly needed.
> 
> Adding the const seems reasonable enough. Not sure what the static buys
> you on top of that.

static is not needed, you are right. I will split that patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:08:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEirx-0000rQ-NJ; Mon, 02 Apr 2012 15:08:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEirw-0000r8-CW
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:08:32 +0000
Received: from [85.158.138.51:59629] by server-2.bemta-3.messagelabs.com id
	9D/1E-15460-FE0C97F4; Mon, 02 Apr 2012 15:08:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333379310!20442435!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23203 invoked from network); 2 Apr 2012 15:08:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 15:08:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333379310; l=1406;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=xk/lMwpUSZD1JyHRhN8D83STWsY=;
	b=xU814UO1Mfy5d1dOQ2zWgJzhfHj/kcnzFEMap6uRZlUbPiwI1puoK7cUrWDJvJol1DB
	TiRin7v0J9o98U39dqZ4b9sqBIx/+1dGcMvWrhh14REcBTGYaVqS3xs/ZIc9kTow3bKxX
	sOJEWf5wNRcdU/ysqK5qdh1rm0SzdR9/qys=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo21) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602919o32E4TFY ;
	Mon, 2 Apr 2012 17:08:30 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id BEDEF18637; Mon,  2 Apr 2012 17:08:29 +0200 (CEST)
Date: Mon, 2 Apr 2012 17:08:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120402150829.GA5043@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20120402144435.GD4000@aepfle.de>
	<1333379043.25602.85.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333379043.25602.85.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Campbell wrote:

> On Mon, 2012-04-02 at 15:44 +0100, Olaf Hering wrote:
> > On Mon, Apr 02, Ian Jackson wrote:
> > 
> > > Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> > > > xs_api.c: In function 'convert_dev_name_to_num':
> > > ...
> > > > ptr should be increased in each iteration, not the char it points to.
> > > 
> > > These changes from `*p++;' to `p++' are correct.  But the description
> > > is wrong.  `*p++' is the same as `*(p++)' ie it increments p and then
> > > uselessly dereferences it.
> > > 
> > > > -	char *p_sd = "/dev/sd";
> > > > -	char *p_hd = "/dev/hd";
> > > > -	char *p_xvd = "/dev/xvd";
> > > > -	char *p_plx = "plx";
> > > > -	char *alpha = "abcdefghijklmnop";
> > > > +	static const char p_sd[] = "/dev/sd";
> > > > +	static const char p_hd[] = "/dev/hd";
> > > > +	static const char p_xvd[] = "/dev/xvd";
> > > > +	static const char p_plx[] = "plx";
> > > > +	static const char alpha[] = "abcdefghijklmnop";
> > > 
> > > And this hunk seems entirely unexplained.  Is it supposed to be a
> > > const-correctness fix ?  Stylistic improvement ?
> > 
> > I think that part is not strictly needed.
> 
> Adding the const seems reasonable enough. Not sure what the static buys
> you on top of that.

static is not needed, you are right. I will split that patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:16:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:16:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEizd-0001Hv-ME; Mon, 02 Apr 2012 15:16:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEizc-0001Hn-9v
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:16:28 +0000
Received: from [85.158.139.83:59739] by server-7.bemta-5.messagelabs.com id
	08/F5-16195-BC2C97F4; Mon, 02 Apr 2012 15:16:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333379786!18158910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6864 invoked from network); 2 Apr 2012 15:16:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11726191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:16:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:16:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEizZ-0002iN-MI; Mon, 02 Apr 2012 15:16:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEizZ-0000rH-Lc;
	Mon, 02 Apr 2012 16:16:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.49865.654263.821383@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:16:25 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333379043.25602.85.camel@zakaz.uk.xensource.com>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20120402144435.GD4000@aepfle.de>
	<1333379043.25602.85.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> On Mon, 2012-04-02 at 15:44 +0100, Olaf Hering wrote:
> > On Mon, Apr 02, Ian Jackson wrote:
> > > Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
...
> > > > -	char *p_sd = "/dev/sd";
> > > > -	char *p_hd = "/dev/hd";
> > > > -	char *p_xvd = "/dev/xvd";
> > > > -	char *p_plx = "plx";
> > > > -	char *alpha = "abcdefghijklmnop";
> > > > +	static const char p_sd[] = "/dev/sd";
> > > > +	static const char p_hd[] = "/dev/hd";
> > > > +	static const char p_xvd[] = "/dev/xvd";
> > > > +	static const char p_plx[] = "plx";
> > > > +	static const char alpha[] = "abcdefghijklmnop";
> > > 
> > > And this hunk seems entirely unexplained.  Is it supposed to be a
> > > const-correctness fix ?  Stylistic improvement ?
> > ...
> > I think that part is not strictly needed.

Right.  But I don't object to it, if it is properly described in the
commit message.

> Adding the const seems reasonable enough. Not sure what the static buys
> you on top of that.

Changing from
  const char *str = "foo";
to
  const char str[] = "foo";
prevents erroneous code from modifying str.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:16:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:16:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEizd-0001Hv-ME; Mon, 02 Apr 2012 15:16:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEizc-0001Hn-9v
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:16:28 +0000
Received: from [85.158.139.83:59739] by server-7.bemta-5.messagelabs.com id
	08/F5-16195-BC2C97F4; Mon, 02 Apr 2012 15:16:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333379786!18158910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6864 invoked from network); 2 Apr 2012 15:16:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11726191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:16:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:16:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEizZ-0002iN-MI; Mon, 02 Apr 2012 15:16:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEizZ-0000rH-Lc;
	Mon, 02 Apr 2012 16:16:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.49865.654263.821383@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:16:25 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333379043.25602.85.camel@zakaz.uk.xensource.com>
References: <patchbomb.1333095917@probook.site>
	<1c86e2e5268d14587c73.1333095918@probook.site>
	<20345.44502.306179.202932@mariner.uk.xensource.com>
	<20120402144435.GD4000@aepfle.de>
	<1333379043.25602.85.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in
 convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
> On Mon, 2012-04-02 at 15:44 +0100, Olaf Hering wrote:
> > On Mon, Apr 02, Ian Jackson wrote:
> > > Olaf Hering writes ("[Xen-devel] [PATCH 01 of 18] tools/blktap: fix access errors in convert_dev_name_to_num"):
...
> > > > -	char *p_sd = "/dev/sd";
> > > > -	char *p_hd = "/dev/hd";
> > > > -	char *p_xvd = "/dev/xvd";
> > > > -	char *p_plx = "plx";
> > > > -	char *alpha = "abcdefghijklmnop";
> > > > +	static const char p_sd[] = "/dev/sd";
> > > > +	static const char p_hd[] = "/dev/hd";
> > > > +	static const char p_xvd[] = "/dev/xvd";
> > > > +	static const char p_plx[] = "plx";
> > > > +	static const char alpha[] = "abcdefghijklmnop";
> > > 
> > > And this hunk seems entirely unexplained.  Is it supposed to be a
> > > const-correctness fix ?  Stylistic improvement ?
> > ...
> > I think that part is not strictly needed.

Right.  But I don't object to it, if it is properly described in the
commit message.

> Adding the const seems reasonable enough. Not sure what the static buys
> you on top of that.

Changing from
  const char *str = "foo";
to
  const char str[] = "foo";
prevents erroneous code from modifying str.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEizi-0001IV-2P; Mon, 02 Apr 2012 15:16:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEizh-0001IE-Ct
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:16:33 +0000
Received: from [85.158.143.35:24518] by server-3.bemta-4.messagelabs.com id
	82/68-05853-0D2C97F4; Mon, 02 Apr 2012 15:16:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333379791!14137654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 2 Apr 2012 15:16:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 15:16:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 16:16:30 +0100
Message-Id: <4F79DEEB020000780007C0F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 16:16:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <20120323.155249.425911897.kuwa@jp.fujitsu.com>
	<4F6C49F7020000780007A763@nat28.tlf.novell.com>
	<1333012384.18810.45.camel@zakaz.uk.xensource.com>
	<20120330.175445.321377065.kuwa@jp.fujitsu.com>
In-Reply-To: <20120330.175445.321377065.kuwa@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, xen-ia64-devel@lists.xen.org,
	Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.03.12 at 10:54, "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com> wrote:
>>>>>> On Thu, 29 Mar 2012 10:13:04 +0100
>>>>>> Ian.Campbell@citrix.com(Ian Campbell)  said:
>> 
>> Kuwamura, what is your motivation for wanting to keeping the ia64 port
>> in 4.2 and beyond?
> 
> As the result of my consideration,
> I agree that ia64 port will be dropped on xen-unstable, since it seems
> to be hardly needed:
> - There was little discussion on xen-ia64-devel ML recently.
> - There are few Xen ia64 developers.
> - No new feature will be added.

Keir,

now that we apparently having reached consensus here, are you
going to purge the ia64 bits from the tree, or do you want me to?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEizi-0001IV-2P; Mon, 02 Apr 2012 15:16:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEizh-0001IE-Ct
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:16:33 +0000
Received: from [85.158.143.35:24518] by server-3.bemta-4.messagelabs.com id
	82/68-05853-0D2C97F4; Mon, 02 Apr 2012 15:16:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333379791!14137654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 2 Apr 2012 15:16:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 15:16:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Apr 2012 16:16:30 +0100
Message-Id: <4F79DEEB020000780007C0F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Apr 2012 16:16:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <20120323.155249.425911897.kuwa@jp.fujitsu.com>
	<4F6C49F7020000780007A763@nat28.tlf.novell.com>
	<1333012384.18810.45.camel@zakaz.uk.xensource.com>
	<20120330.175445.321377065.kuwa@jp.fujitsu.com>
In-Reply-To: <20120330.175445.321377065.kuwa@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, xen-ia64-devel@lists.xen.org,
	Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.03.12 at 10:54, "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com> wrote:
>>>>>> On Thu, 29 Mar 2012 10:13:04 +0100
>>>>>> Ian.Campbell@citrix.com(Ian Campbell)  said:
>> 
>> Kuwamura, what is your motivation for wanting to keeping the ia64 port
>> in 4.2 and beyond?
> 
> As the result of my consideration,
> I agree that ia64 port will be dropped on xen-unstable, since it seems
> to be hardly needed:
> - There was little discussion on xen-ia64-devel ML recently.
> - There are few Xen ia64 developers.
> - No new feature will be added.

Keir,

now that we apparently having reached consensus here, are you
going to purge the ia64 bits from the tree, or do you want me to?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:21:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:21:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEj3s-0001ae-Om; Mon, 02 Apr 2012 15:20:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEj3r-0001aX-KA
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:20:51 +0000
Received: from [85.158.143.99:23662] by server-3.bemta-4.messagelabs.com id
	19/BE-05853-3D3C97F4; Mon, 02 Apr 2012 15:20:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333380050!16716202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31129 invoked from network); 2 Apr 2012 15:20:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11726592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:20:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:20:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEj3p-0002k6-FY; Mon, 02 Apr 2012 15:20:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEj3p-0000rh-Dx;
	Mon, 02 Apr 2012 16:20:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.50129.248371.995505@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:20:49 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <62b1030a2485536caf99.1333363657@kodo2>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> +By default pciback only allows PV guests to write "known safe" values into
> +PCI config space.  But many devices require writes to other areas of config
> +space in order to operate properly.  This tells the pciback driver to
> +allow all writes to PCI config space for this domain and this device.  This
> +option should be enabled with caution, as there may be stability or security 
> +implications of doing so.

Is this security warning not overly mealy-mouthed ?  Surely it should
be more definite.

> +Changes the default value of 'permissive' for all PCI devices for this
> +VM.  This can still be overriden on a per-device basis. See the
> +"pci=" section for more information on the "permissive" flag.

And this should mention it as well I think.

> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",

Please keep the lines to 75-80 characters at most.

I think you should consider breakibg out the sysfs writing function
and refactoring with the very similar code in libxl__device_pci_reset,
rather than introducing yet another clone.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:21:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:21:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEj3s-0001ae-Om; Mon, 02 Apr 2012 15:20:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEj3r-0001aX-KA
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:20:51 +0000
Received: from [85.158.143.99:23662] by server-3.bemta-4.messagelabs.com id
	19/BE-05853-3D3C97F4; Mon, 02 Apr 2012 15:20:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333380050!16716202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31129 invoked from network); 2 Apr 2012 15:20:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11726592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:20:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:20:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEj3p-0002k6-FY; Mon, 02 Apr 2012 15:20:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEj3p-0000rh-Dx;
	Mon, 02 Apr 2012 16:20:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.50129.248371.995505@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:20:49 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <62b1030a2485536caf99.1333363657@kodo2>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> +By default pciback only allows PV guests to write "known safe" values into
> +PCI config space.  But many devices require writes to other areas of config
> +space in order to operate properly.  This tells the pciback driver to
> +allow all writes to PCI config space for this domain and this device.  This
> +option should be enabled with caution, as there may be stability or security 
> +implications of doing so.

Is this security warning not overly mealy-mouthed ?  Surely it should
be more definite.

> +Changes the default value of 'permissive' for all PCI devices for this
> +VM.  This can still be overriden on a per-device basis. See the
> +"pci=" section for more information on the "permissive" flag.

And this should mention it as well I think.

> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",

Please keep the lines to 75-80 characters at most.

I think you should consider breakibg out the sysfs writing function
and refactoring with the very similar code in libxl__device_pci_reset,
rather than introducing yet another clone.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:23:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEj6R-0001il-AA; Mon, 02 Apr 2012 15:23:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEj6P-0001id-Nl
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:23:30 +0000
Received: from [85.158.143.35:26146] by server-2.bemta-4.messagelabs.com id
	04/57-17550-074C97F4; Mon, 02 Apr 2012 15:23:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333380206!10623746!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19246 invoked from network); 2 Apr 2012 15:23:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:23:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="188663383"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:23:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 11:23:25 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEj6L-0004Hl-6p;
	Mon, 02 Apr 2012 16:23:25 +0100
Message-ID: <4F79C452.50401@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:22:58 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<1333366219.25602.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333366219.25602.58.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 12:30, Ian Campbell wrote:
> On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
>> # HG changeset patch
>> # User George Dunlap<george.dunlap@eu.citrix.com>
>> # Date 1333363500 -3600
>> # Node ID 62b1030a2485536caf995b825bee9e8255f914b3
>> # Parent  5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
>> xl,libxl: Add per-device and global permissive config options for pci passthrough
>>
>> By default pciback only allows PV guests to write "known safe" values into
>> PCI config space.  But many devices require writes to other areas of config
>> space in order to operate properly.  One way to do that is with the "quirks"
>> interface, which specifies areas known safe to a particular device; the
>> other way is to mark a device as "permissive", which tells pciback to allow
>> all config space writes for that domain and device.
>>
>> This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
>> to write the appropriate value into sysfs to enable the permissive feature for
>> devices being passed through.  It also adds the permissive config options either
>> on a per-device basis, or as a global option in the xl command-line.
>>
>> Because of the potential stability and security implications of enabling
>> permissive, the flag is left off by default.
>>
>> Signed-off-by: George Dunlap<george.dunlap@eu.citrix.com>
>>
>> diff -r 5386937e6c5c -r 62b1030a2485 docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5	Mon Apr 02 11:29:34 2012 +0100
>> +++ b/docs/man/xl.cfg.pod.5	Mon Apr 02 11:45:00 2012 +0100
>> @@ -294,10 +294,25 @@ XXX
>>
>>   XXX
>>
>> +=item B<permissive=BOOLEAN>
>> +
>> +By default pciback only allows PV guests to write "known safe" values into
>> +PCI config space.  But many devices require writes to other areas of config
>> +space in order to operate properly.  This tells the pciback driver to
>> +allow all writes to PCI config space for this domain and this device.  This
>> +option should be enabled with caution, as there may be stability or security
>> +implications of doing so.
>> +
>>   =back
>>
>>   =back
>>
>> +=item B<pci_permissive=BOOLEAN>
>> +
>> +Changes the default value of 'permissive' for all PCI devices for this
>> +VM.  This can still be overriden on a per-device basis. See the
>> +"pci=" section for more information on the "permissive" flag.
>> +
>>   =back
>>
>>   =head2 Paravirtualised (PV) Guest Specific Options
>> diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
>> --- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
>> +++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
>> @@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
>>       if (pcidev->vdevfn)
>>           flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
>>       flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
>> -    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
>> +    flexarray_append(back,
>> +              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
>> +                             pcidev->msitranslate, pcidev->power_mgmt,
>> +                             pcidev->permissive));
> Since we are already writing this key, and AFAICT this matches xend's
> behaviour, I think it is correct to add the new parameter here. But...
>
> Does anything actually read this key? I can't find anything in pciback
> or qemu.
No idea -- I was just following suit.  In any case, it's probably not a 
bad idea to have this kind of thing in there to help debug stuff.

Let me know if you want to do something else, otherwise I'll keep it in 
for my next patch series.
>>       flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
>>   }
>>
>> @@ -565,6 +568,29 @@ static int do_pci_add(libxl__gc *gc, uin
>>               }
>>           }
>>           fclose(f);
>> +
>> +        /* Don't restrict writes to the PCI config space from this VM */
>> +        if (pcidev->permissive) {
>> +            int fd;
>> +            char *buf;
>> +
>> +            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
>> +            fd = open(sysfs_path, O_WRONLY);
>> +            if (fd<  0) {
>> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
>> +                                 sysfs_path);
>> +                goto out;
> Why not either fall through (i.e. accept this as a soft failure) or
> return an actual error here?
>
> FWIW I think the case where we cannot open the sysfs "irq" node and
> "goto out" is also similarly wrong.

>
>> +            }
>> +
>> +            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
>> +                                 pcidev->dev, pcidev->func);
>> +            rc = write(fd, buf, strlen(buf));
>> +            if (rc<  0)
>> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
>> +                                 sysfs_path, rc);
>> +            close(fd);
>> +            goto out;
> I don't think this makes sense, out is the next thing we actually get to
> anyway and there is a "break" out of the switch right below.
Sorry -- yeah, I'm not seeing how that code got generated. :-/

I think what I'm going to do is have it return ERROR_FAIL if either the 
open or the write fails.  In general, if the user has asked specifically 
for something to happen and it can't happen, there should be an error, 
so the user can decide if he doesn't care so much, or fix things so it 
can happen.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:23:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEj6R-0001il-AA; Mon, 02 Apr 2012 15:23:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEj6P-0001id-Nl
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:23:30 +0000
Received: from [85.158.143.35:26146] by server-2.bemta-4.messagelabs.com id
	04/57-17550-074C97F4; Mon, 02 Apr 2012 15:23:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333380206!10623746!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19246 invoked from network); 2 Apr 2012 15:23:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:23:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="188663383"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:23:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 11:23:25 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEj6L-0004Hl-6p;
	Mon, 02 Apr 2012 16:23:25 +0100
Message-ID: <4F79C452.50401@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:22:58 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<1333366219.25602.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333366219.25602.58.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 12:30, Ian Campbell wrote:
> On Mon, 2012-04-02 at 11:47 +0100, George Dunlap wrote:
>> # HG changeset patch
>> # User George Dunlap<george.dunlap@eu.citrix.com>
>> # Date 1333363500 -3600
>> # Node ID 62b1030a2485536caf995b825bee9e8255f914b3
>> # Parent  5386937e6c5c9afaa8a3cd56d391dcc9e40d0596
>> xl,libxl: Add per-device and global permissive config options for pci passthrough
>>
>> By default pciback only allows PV guests to write "known safe" values into
>> PCI config space.  But many devices require writes to other areas of config
>> space in order to operate properly.  One way to do that is with the "quirks"
>> interface, which specifies areas known safe to a particular device; the
>> other way is to mark a device as "permissive", which tells pciback to allow
>> all config space writes for that domain and device.
>>
>> This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
>> to write the appropriate value into sysfs to enable the permissive feature for
>> devices being passed through.  It also adds the permissive config options either
>> on a per-device basis, or as a global option in the xl command-line.
>>
>> Because of the potential stability and security implications of enabling
>> permissive, the flag is left off by default.
>>
>> Signed-off-by: George Dunlap<george.dunlap@eu.citrix.com>
>>
>> diff -r 5386937e6c5c -r 62b1030a2485 docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5	Mon Apr 02 11:29:34 2012 +0100
>> +++ b/docs/man/xl.cfg.pod.5	Mon Apr 02 11:45:00 2012 +0100
>> @@ -294,10 +294,25 @@ XXX
>>
>>   XXX
>>
>> +=item B<permissive=BOOLEAN>
>> +
>> +By default pciback only allows PV guests to write "known safe" values into
>> +PCI config space.  But many devices require writes to other areas of config
>> +space in order to operate properly.  This tells the pciback driver to
>> +allow all writes to PCI config space for this domain and this device.  This
>> +option should be enabled with caution, as there may be stability or security
>> +implications of doing so.
>> +
>>   =back
>>
>>   =back
>>
>> +=item B<pci_permissive=BOOLEAN>
>> +
>> +Changes the default value of 'permissive' for all PCI devices for this
>> +VM.  This can still be overriden on a per-device basis. See the
>> +"pci=" section for more information on the "permissive" flag.
>> +
>>   =back
>>
>>   =head2 Paravirtualised (PV) Guest Specific Options
>> diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
>> --- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
>> +++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
>> @@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
>>       if (pcidev->vdevfn)
>>           flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
>>       flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
>> -    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
>> +    flexarray_append(back,
>> +              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
>> +                             pcidev->msitranslate, pcidev->power_mgmt,
>> +                             pcidev->permissive));
> Since we are already writing this key, and AFAICT this matches xend's
> behaviour, I think it is correct to add the new parameter here. But...
>
> Does anything actually read this key? I can't find anything in pciback
> or qemu.
No idea -- I was just following suit.  In any case, it's probably not a 
bad idea to have this kind of thing in there to help debug stuff.

Let me know if you want to do something else, otherwise I'll keep it in 
for my next patch series.
>>       flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
>>   }
>>
>> @@ -565,6 +568,29 @@ static int do_pci_add(libxl__gc *gc, uin
>>               }
>>           }
>>           fclose(f);
>> +
>> +        /* Don't restrict writes to the PCI config space from this VM */
>> +        if (pcidev->permissive) {
>> +            int fd;
>> +            char *buf;
>> +
>> +            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
>> +            fd = open(sysfs_path, O_WRONLY);
>> +            if (fd<  0) {
>> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
>> +                                 sysfs_path);
>> +                goto out;
> Why not either fall through (i.e. accept this as a soft failure) or
> return an actual error here?
>
> FWIW I think the case where we cannot open the sysfs "irq" node and
> "goto out" is also similarly wrong.

>
>> +            }
>> +
>> +            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
>> +                                 pcidev->dev, pcidev->func);
>> +            rc = write(fd, buf, strlen(buf));
>> +            if (rc<  0)
>> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
>> +                                 sysfs_path, rc);
>> +            close(fd);
>> +            goto out;
> I don't think this makes sense, out is the next thing we actually get to
> anyway and there is a "break" out of the switch right below.
Sorry -- yeah, I'm not seeing how that code got generated. :-/

I think what I'm going to do is have it return ERROR_FAIL if either the 
open or the write fails.  In general, if the user has asked specifically 
for something to happen and it can't happen, there should be an error, 
so the user can decide if he doesn't care so much, or fix things so it 
can happen.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:30:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjCl-00020u-9a; Mon, 02 Apr 2012 15:30:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjCk-00020p-KF
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:30:02 +0000
Received: from [85.158.138.51:40992] by server-6.bemta-3.messagelabs.com id
	64/82-08206-9F5C97F4; Mon, 02 Apr 2012 15:30:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333380600!20275236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22927 invoked from network); 2 Apr 2012 15:30:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:30:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11726817"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:29:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	16:29:58 +0100
Message-ID: <1333380597.25602.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:29:57 +0100
In-Reply-To: <4F79C452.50401@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<1333366219.25602.58.camel@zakaz.uk.xensource.com>
	<4F79C452.50401@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> >> diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
> >> --- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
> >> +++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
> >> @@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
> >>       if (pcidev->vdevfn)
> >>           flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
> >>       flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
> >> -    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
> >> +    flexarray_append(back,
> >> +              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
> >> +                             pcidev->msitranslate, pcidev->power_mgmt,
> >> +                             pcidev->permissive));
> > Since we are already writing this key, and AFAICT this matches xend's
> > behaviour, I think it is correct to add the new parameter here. But...
> >
> > Does anything actually read this key? I can't find anything in pciback
> > or qemu.
> No idea -- I was just following suit.  In any case, it's probably not a 
> bad idea to have this kind of thing in there to help debug stuff.
> 
> Let me know if you want to do something else, otherwise I'll keep it in 
> for my next patch series.

It's fine, I was just wondering if anyone knew what it was for.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:30:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjCl-00020u-9a; Mon, 02 Apr 2012 15:30:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjCk-00020p-KF
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:30:02 +0000
Received: from [85.158.138.51:40992] by server-6.bemta-3.messagelabs.com id
	64/82-08206-9F5C97F4; Mon, 02 Apr 2012 15:30:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333380600!20275236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22927 invoked from network); 2 Apr 2012 15:30:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:30:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11726817"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:29:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	16:29:58 +0100
Message-ID: <1333380597.25602.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:29:57 +0100
In-Reply-To: <4F79C452.50401@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<1333366219.25602.58.camel@zakaz.uk.xensource.com>
	<4F79C452.50401@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> >> diff -r 5386937e6c5c -r 62b1030a2485 tools/libxl/libxl_pci.c
> >> --- a/tools/libxl/libxl_pci.c	Mon Apr 02 11:29:34 2012 +0100
> >> +++ b/tools/libxl/libxl_pci.c	Mon Apr 02 11:45:00 2012 +0100
> >> @@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
> >>       if (pcidev->vdevfn)
> >>           flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
> >>       flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
> >> -    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
> >> +    flexarray_append(back,
> >> +              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
> >> +                             pcidev->msitranslate, pcidev->power_mgmt,
> >> +                             pcidev->permissive));
> > Since we are already writing this key, and AFAICT this matches xend's
> > behaviour, I think it is correct to add the new parameter here. But...
> >
> > Does anything actually read this key? I can't find anything in pciback
> > or qemu.
> No idea -- I was just following suit.  In any case, it's probably not a 
> bad idea to have this kind of thing in there to help debug stuff.
> 
> Let me know if you want to do something else, otherwise I'll keep it in 
> for my next patch series.

It's fine, I was just wondering if anyone knew what it was for.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjFv-00027N-T9; Mon, 02 Apr 2012 15:33:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEjFu-00027G-Jw
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:33:18 +0000
Received: from [85.158.139.83:12355] by server-11.bemta-5.messagelabs.com id
	5E/02-12959-DB6C97F4; Mon, 02 Apr 2012 15:33:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333380795!17833364!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzY2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29529 invoked from network); 2 Apr 2012 15:33:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 15:33:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32FX737004655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 15:33:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32FX6OX015026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 15:33:06 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32FX5IU015005; Mon, 2 Apr 2012 10:33:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 08:33:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 557D04031C; Mon,  2 Apr 2012 11:28:30 -0400 (EDT)
Date: Mon, 2 Apr 2012 11:28:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, tcgoetz@gmail.com
Message-ID: <20120402152830.GA30162@phenom.dumpdata.com>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<75798a472b1a9121adda.1332610904@phenom.dumpdata.com>
	<4F7049E3020000780007AD63@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7049E3020000780007AD63@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F79C6B4.0009,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, keir.fraser@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 6] xen/pat: After suspend re-write PAT
 if BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Mar 26, 2012 at 09:50:11AM +0100, Jan Beulich wrote:
> >>> On 24.03.12 at 18:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > # HG changeset patch
> > # User Simon Graham <simon.graham@virtualcomputer.com>
> > # Date 1332610898 14400
> > # Node ID 75798a472b1a9121adda166b6fd05ba8473a44f0
> > # Parent  d097c3ba42f601af65b53a0c84973855aab64aa9
> > xen/pat: After suspend re-write PAT if BIOS changed it.
> > 
> > Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
> > would reset the PAT MSR causing rather weird issues - where
> > the pages would (say they would be set to WC) would end up with the
> > wrong type (as they would use the BIOS PAT instead of the one set by
> > the hypervisor).
> 
> There's a write of the PAT MSR already at the end of
> restore_rest_processor_state() - are you saying this doesn't do
> what is needed? Also note that this is properly gated by a check
> of cpu_has_pat (other than the patch here does).

Let me double-check with folks at VirtualComputer - but they had
experienced this with Xen 4.0 (I think) and the c/s 19167 certainly
was in there.

> 
> > Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > diff -r d097c3ba42f6 -r 75798a472b1a xen/arch/x86/acpi/power.c
> > --- a/xen/arch/x86/acpi/power.c	Sat Mar 24 12:54:12 2012 -0400
> > +++ b/xen/arch/x86/acpi/power.c	Sat Mar 24 13:41:38 2012 -0400
> > @@ -41,8 +41,25 @@ static DEFINE_SPINLOCK(pm_lock);
> >  
> >  struct acpi_sleep_info acpi_sinfo;
> >  
> > +static void pat_resume(void);
> >  void do_suspend_lowlevel(void);
> >  
> > +static void
> > +pat_resume()
> > +{
> > +    u64 pat;
> > +
> > +    rdmsrl(MSR_IA32_CR_PAT, pat);
> > +    if (pat != host_pat) {
> > +	printk(KERN_INFO PREFIX "Found PAT MSR: 0x%lx\n", pat);
> > +	printk(KERN_INFO PREFIX "reseting to 0x%lx\n", host_pat);
> > +	wrmsrl(MSR_IA32_CR_PAT, host_pat);
> > +	rdmsrl(MSR_IA32_CR_PAT, pat);
> > +	if (pat != host_pat)
> > +	    printk(KERN_WARNING PREFIX "PAT MSR stuck on: 0x%lx\n", pat);
> 
> All the %lx format specifiers here would break the 32-bit build afaict.
> Further (if this code really is needed at all), please use %# instead
> of 0x%.

Right.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjFv-00027N-T9; Mon, 02 Apr 2012 15:33:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEjFu-00027G-Jw
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:33:18 +0000
Received: from [85.158.139.83:12355] by server-11.bemta-5.messagelabs.com id
	5E/02-12959-DB6C97F4; Mon, 02 Apr 2012 15:33:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333380795!17833364!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzY2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29529 invoked from network); 2 Apr 2012 15:33:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 15:33:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32FX737004655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 15:33:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32FX6OX015026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 15:33:06 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32FX5IU015005; Mon, 2 Apr 2012 10:33:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 08:33:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 557D04031C; Mon,  2 Apr 2012 11:28:30 -0400 (EDT)
Date: Mon, 2 Apr 2012 11:28:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, tcgoetz@gmail.com
Message-ID: <20120402152830.GA30162@phenom.dumpdata.com>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<75798a472b1a9121adda.1332610904@phenom.dumpdata.com>
	<4F7049E3020000780007AD63@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7049E3020000780007AD63@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F79C6B4.0009,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, keir.fraser@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 6] xen/pat: After suspend re-write PAT
 if BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Mar 26, 2012 at 09:50:11AM +0100, Jan Beulich wrote:
> >>> On 24.03.12 at 18:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > # HG changeset patch
> > # User Simon Graham <simon.graham@virtualcomputer.com>
> > # Date 1332610898 14400
> > # Node ID 75798a472b1a9121adda166b6fd05ba8473a44f0
> > # Parent  d097c3ba42f601af65b53a0c84973855aab64aa9
> > xen/pat: After suspend re-write PAT if BIOS changed it.
> > 
> > Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
> > would reset the PAT MSR causing rather weird issues - where
> > the pages would (say they would be set to WC) would end up with the
> > wrong type (as they would use the BIOS PAT instead of the one set by
> > the hypervisor).
> 
> There's a write of the PAT MSR already at the end of
> restore_rest_processor_state() - are you saying this doesn't do
> what is needed? Also note that this is properly gated by a check
> of cpu_has_pat (other than the patch here does).

Let me double-check with folks at VirtualComputer - but they had
experienced this with Xen 4.0 (I think) and the c/s 19167 certainly
was in there.

> 
> > Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > diff -r d097c3ba42f6 -r 75798a472b1a xen/arch/x86/acpi/power.c
> > --- a/xen/arch/x86/acpi/power.c	Sat Mar 24 12:54:12 2012 -0400
> > +++ b/xen/arch/x86/acpi/power.c	Sat Mar 24 13:41:38 2012 -0400
> > @@ -41,8 +41,25 @@ static DEFINE_SPINLOCK(pm_lock);
> >  
> >  struct acpi_sleep_info acpi_sinfo;
> >  
> > +static void pat_resume(void);
> >  void do_suspend_lowlevel(void);
> >  
> > +static void
> > +pat_resume()
> > +{
> > +    u64 pat;
> > +
> > +    rdmsrl(MSR_IA32_CR_PAT, pat);
> > +    if (pat != host_pat) {
> > +	printk(KERN_INFO PREFIX "Found PAT MSR: 0x%lx\n", pat);
> > +	printk(KERN_INFO PREFIX "reseting to 0x%lx\n", host_pat);
> > +	wrmsrl(MSR_IA32_CR_PAT, host_pat);
> > +	rdmsrl(MSR_IA32_CR_PAT, pat);
> > +	if (pat != host_pat)
> > +	    printk(KERN_WARNING PREFIX "PAT MSR stuck on: 0x%lx\n", pat);
> 
> All the %lx format specifiers here would break the 32-bit build afaict.
> Further (if this code really is needed at all), please use %# instead
> of 0x%.

Right.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjGG-00029K-9x; Mon, 02 Apr 2012 15:33:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SEjGF-00028z-4O
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:33:39 +0000
Received: from [193.109.254.147:35713] by server-5.bemta-14.messagelabs.com id
	0D/93-30733-2D6C97F4; Mon, 02 Apr 2012 15:33:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333380817!3078528!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18389 invoked from network); 2 Apr 2012 15:33:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:33:37 -0000
Received: by eeit10 with SMTP id t10so847936eei.32
	for <multiple recipients>; Mon, 02 Apr 2012 08:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HIrYGe0/LdgasYmt/XN+ecUwbM1Wp+GouOfP6pjZXWQ=;
	b=gOoaRFylNbTLPl2ftRjTbYOiL592kYzuFlTb0+UXXauj5oFWx6A0VaacPN9lznu6EP
	7fzHQsFuY/zWpFVVZSM+RCm+gVh3KXIvANXqcm5l7gli/fDiQRtRX6Sri7IUPeIHeq8O
	Kfty01jYhjR8QeUpIZnj5uqgXNAQIcsZXP/oKmpVQt3S5tj45Fjpi9dP+2NX3wStj3M7
	vPW2pBXIW4oJ3ueUGaCdBW79jaKlOQX4MrchAU86FqX6kS0hcgD+9fMsyTI4+IKpoFf+
	7mEXulsBt+phvsVg2Wps7admEjPSryq1hE60LTgHll91TDfO8tk/VN8c8n+o9sI4Ewcz
	R08A==
Received: by 10.213.8.71 with SMTP id g7mr9246ebg.139.1333380817296;
	Mon, 02 Apr 2012 08:33:37 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id r44sm64017921eef.2.2012.04.02.08.33.35
	(version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 08:33:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 02 Apr 2012 16:33:34 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB9F855E.2FDCE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] removal of ia64 port
Thread-Index: Ac0Q5fbuPepJOWG48EiPdKS0JotDCA==
In-Reply-To: <4F79DEEB020000780007C0F3@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, xen-ia64-devel@lists.xen.org,
	Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/2012 16:16, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 30.03.12 at 10:54, "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com> wrote:
>>>>>>> On Thu, 29 Mar 2012 10:13:04 +0100
>>>>>>> Ian.Campbell@citrix.com(Ian Campbell)  said:
>>> 
>>> Kuwamura, what is your motivation for wanting to keeping the ia64 port
>>> in 4.2 and beyond?
>> 
>> As the result of my consideration,
>> I agree that ia64 port will be dropped on xen-unstable, since it seems
>> to be hardly needed:
>> - There was little discussion on xen-ia64-devel ML recently.
>> - There are few Xen ia64 developers.
>> - No new feature will be added.
> 
> Keir,
> 
> now that we apparently having reached consensus here, are you
> going to purge the ia64 bits from the tree, or do you want me to?

Please go ahead.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjGG-00029K-9x; Mon, 02 Apr 2012 15:33:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SEjGF-00028z-4O
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:33:39 +0000
Received: from [193.109.254.147:35713] by server-5.bemta-14.messagelabs.com id
	0D/93-30733-2D6C97F4; Mon, 02 Apr 2012 15:33:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333380817!3078528!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18389 invoked from network); 2 Apr 2012 15:33:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:33:37 -0000
Received: by eeit10 with SMTP id t10so847936eei.32
	for <multiple recipients>; Mon, 02 Apr 2012 08:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HIrYGe0/LdgasYmt/XN+ecUwbM1Wp+GouOfP6pjZXWQ=;
	b=gOoaRFylNbTLPl2ftRjTbYOiL592kYzuFlTb0+UXXauj5oFWx6A0VaacPN9lznu6EP
	7fzHQsFuY/zWpFVVZSM+RCm+gVh3KXIvANXqcm5l7gli/fDiQRtRX6Sri7IUPeIHeq8O
	Kfty01jYhjR8QeUpIZnj5uqgXNAQIcsZXP/oKmpVQt3S5tj45Fjpi9dP+2NX3wStj3M7
	vPW2pBXIW4oJ3ueUGaCdBW79jaKlOQX4MrchAU86FqX6kS0hcgD+9fMsyTI4+IKpoFf+
	7mEXulsBt+phvsVg2Wps7admEjPSryq1hE60LTgHll91TDfO8tk/VN8c8n+o9sI4Ewcz
	R08A==
Received: by 10.213.8.71 with SMTP id g7mr9246ebg.139.1333380817296;
	Mon, 02 Apr 2012 08:33:37 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id r44sm64017921eef.2.2012.04.02.08.33.35
	(version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 08:33:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 02 Apr 2012 16:33:34 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB9F855E.2FDCE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] removal of ia64 port
Thread-Index: Ac0Q5fbuPepJOWG48EiPdKS0JotDCA==
In-Reply-To: <4F79DEEB020000780007C0F3@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, xen-ia64-devel@lists.xen.org,
	Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/2012 16:16, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 30.03.12 at 10:54, "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com> wrote:
>>>>>>> On Thu, 29 Mar 2012 10:13:04 +0100
>>>>>>> Ian.Campbell@citrix.com(Ian Campbell)  said:
>>> 
>>> Kuwamura, what is your motivation for wanting to keeping the ia64 port
>>> in 4.2 and beyond?
>> 
>> As the result of my consideration,
>> I agree that ia64 port will be dropped on xen-unstable, since it seems
>> to be hardly needed:
>> - There was little discussion on xen-ia64-devel ML recently.
>> - There are few Xen ia64 developers.
>> - No new feature will be added.
> 
> Keir,
> 
> now that we apparently having reached consensus here, are you
> going to purge the ia64 bits from the tree, or do you want me to?

Please go ahead.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjQ2-0002Uu-Dd; Mon, 02 Apr 2012 15:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEjQ0-0002Up-Pz
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:43:45 +0000
Received: from [85.158.139.83:21237] by server-4.bemta-5.messagelabs.com id
	A7/23-10788-039C97F4; Mon, 02 Apr 2012 15:43:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333381421!22107356!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28387 invoked from network); 2 Apr 2012 15:43:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="23786040"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:43:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 11:43:40 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEjPw-0004bc-G5;
	Mon, 02 Apr 2012 16:43:40 +0100
Message-ID: <4F79C912.9010504@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:43:14 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
In-Reply-To: <20345.50129.248371.995505@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 16:20, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
>> +By default pciback only allows PV guests to write "known safe" values into
>> +PCI config space.  But many devices require writes to other areas of config
>> +space in order to operate properly.  This tells the pciback driver to
>> +allow all writes to PCI config space for this domain and this device.  This
>> +option should be enabled with caution, as there may be stability or security
>> +implications of doing so.
> Is this security warning not overly mealy-mouthed ?  Surely it should
> be more definite.
I'm not sure how we can make it more definite.  What's possible (i.e., 
the security implications) entirely depends on the card; and what's 
likely (i.e., the stability implications) entirely depends on the card 
and the driver.  Short of giving a short discourse on the vices of 
various cards PCI config space (which is entirely inappropriate for a 
man page, IMHO), I'm not sure what more we can say.
>> +Changes the default value of 'permissive' for all PCI devices for this
>> +VM.  This can still be overriden on a per-device basis. See the
>> +"pci=" section for more information on the "permissive" flag.
> And this should mention it as well I think.
I thought it was unnecessary to duplicate, but I can do so if you prefer.
>
>> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
> Please keep the lines to 75-80 characters at most.
Ack.
>
> I think you should consider breakibg out the sysfs writing function
> and refactoring with the very similar code in libxl__device_pci_reset,
> rather than introducing yet another clone.
I shall consider it. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjQ2-0002Uu-Dd; Mon, 02 Apr 2012 15:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEjQ0-0002Up-Pz
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:43:45 +0000
Received: from [85.158.139.83:21237] by server-4.bemta-5.messagelabs.com id
	A7/23-10788-039C97F4; Mon, 02 Apr 2012 15:43:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333381421!22107356!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28387 invoked from network); 2 Apr 2012 15:43:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="23786040"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 11:43:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 11:43:40 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEjPw-0004bc-G5;
	Mon, 02 Apr 2012 16:43:40 +0100
Message-ID: <4F79C912.9010504@eu.citrix.com>
Date: Mon, 2 Apr 2012 16:43:14 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
In-Reply-To: <20345.50129.248371.995505@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 16:20, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
>> +By default pciback only allows PV guests to write "known safe" values into
>> +PCI config space.  But many devices require writes to other areas of config
>> +space in order to operate properly.  This tells the pciback driver to
>> +allow all writes to PCI config space for this domain and this device.  This
>> +option should be enabled with caution, as there may be stability or security
>> +implications of doing so.
> Is this security warning not overly mealy-mouthed ?  Surely it should
> be more definite.
I'm not sure how we can make it more definite.  What's possible (i.e., 
the security implications) entirely depends on the card; and what's 
likely (i.e., the stability implications) entirely depends on the card 
and the driver.  Short of giving a short discourse on the vices of 
various cards PCI config space (which is entirely inappropriate for a 
man page, IMHO), I'm not sure what more we can say.
>> +Changes the default value of 'permissive' for all PCI devices for this
>> +VM.  This can still be overriden on a per-device basis. See the
>> +"pci=" section for more information on the "permissive" flag.
> And this should mention it as well I think.
I thought it was unnecessary to duplicate, but I can do so if you prefer.
>
>> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "write to %s returned %d",
> Please keep the lines to 75-80 characters at most.
Ack.
>
> I think you should consider breakibg out the sysfs writing function
> and refactoring with the very similar code in libxl__device_pci_reset,
> rather than introducing yet another clone.
I shall consider it. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:51:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjXU-0002h8-AP; Mon, 02 Apr 2012 15:51:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjXT-0002h3-Fj
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:51:27 +0000
Received: from [193.109.254.147:59257] by server-5.bemta-14.messagelabs.com id
	2D/90-30733-EFAC97F4; Mon, 02 Apr 2012 15:51:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333381885!3064509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31308 invoked from network); 2 Apr 2012 15:51:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:51:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:51:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:51:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjXQ-00039Q-Ug; Mon, 02 Apr 2012 15:51:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjXQ-0000u2-SU;
	Mon, 02 Apr 2012 16:51:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.51964.865778.569742@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:51:24 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4F79C912.9010504@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> I'm not sure how we can make it more definite.  What's possible (i.e., 
> the security implications) entirely depends on the card; and what's 
> likely (i.e., the stability implications) entirely depends on the card 
> and the driver.  Short of giving a short discourse on the vices of 
> various cards PCI config space (which is entirely inappropriate for a 
> man page, IMHO), I'm not sure what more we can say.

Is it generally or usually the case that this option will more
completely expose the host ?

> I thought it was unnecessary to duplicate, but I can do so if you prefer.

I guess that depends on how strong a statement it is.

> > I think you should consider breakibg out the sysfs writing function
> > and refactoring with the very similar code in libxl__device_pci_reset,
> > rather than introducing yet another clone.
>
> I shall consider it. :-)

Thanks :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:51:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjXU-0002h8-AP; Mon, 02 Apr 2012 15:51:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjXT-0002h3-Fj
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:51:27 +0000
Received: from [193.109.254.147:59257] by server-5.bemta-14.messagelabs.com id
	2D/90-30733-EFAC97F4; Mon, 02 Apr 2012 15:51:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333381885!3064509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31308 invoked from network); 2 Apr 2012 15:51:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:51:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:51:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:51:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjXQ-00039Q-Ug; Mon, 02 Apr 2012 15:51:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjXQ-0000u2-SU;
	Mon, 02 Apr 2012 16:51:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.51964.865778.569742@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:51:24 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4F79C912.9010504@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> I'm not sure how we can make it more definite.  What's possible (i.e., 
> the security implications) entirely depends on the card; and what's 
> likely (i.e., the stability implications) entirely depends on the card 
> and the driver.  Short of giving a short discourse on the vices of 
> various cards PCI config space (which is entirely inappropriate for a 
> man page, IMHO), I'm not sure what more we can say.

Is it generally or usually the case that this option will more
completely expose the host ?

> I thought it was unnecessary to duplicate, but I can do so if you prefer.

I guess that depends on how strong a statement it is.

> > I think you should consider breakibg out the sysfs writing function
> > and refactoring with the very similar code in libxl__device_pci_reset,
> > rather than introducing yet another clone.
>
> I shall consider it. :-)

Thanks :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjXs-0002iT-N9; Mon, 02 Apr 2012 15:51:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjXr-0002iM-CU
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:51:51 +0000
Received: from [193.109.254.147:3197] by server-7.bemta-14.messagelabs.com id
	67/27-01627-61BC97F4; Mon, 02 Apr 2012 15:51:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333381908!3067716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2162 invoked from network); 2 Apr 2012 15:51:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:51:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:51:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:51:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjXn-00039Y-PU; Mon, 02 Apr 2012 15:51:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjXn-0000uE-Ol;
	Mon, 02 Apr 2012 16:51:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.51987.737417.316381@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:51:47 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1333106583.15932.94.camel@zakaz.uk.xensource.com>
References: <201203291439.q2TEdJKL006923@wind.enjellic.com>
	<1333095477.15932.26.camel@zakaz.uk.xensource.com>
	<1333106583.15932.94.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Basic blktap2 functionality issues."):
> On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > I think an approach worth trying would be to have
> > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > doing the actual detach. i.e. it would respond with "Yes, I will do
> > that" rather than "Yes, I have done that". My speculation is that this
> > will allow libxl to continue and hopefully avoid the deadlock.
> 
> This seems to be the case as the following fixes things for me. Thanks
> very much for your analysis which lead me to this solution...

Greg, can you confirm whether this works for you ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 15:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 15:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjXs-0002iT-N9; Mon, 02 Apr 2012 15:51:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjXr-0002iM-CU
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 15:51:51 +0000
Received: from [193.109.254.147:3197] by server-7.bemta-14.messagelabs.com id
	67/27-01627-61BC97F4; Mon, 02 Apr 2012 15:51:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333381908!3067716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2162 invoked from network); 2 Apr 2012 15:51:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 15:51:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 15:51:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 16:51:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjXn-00039Y-PU; Mon, 02 Apr 2012 15:51:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjXn-0000uE-Ol;
	Mon, 02 Apr 2012 16:51:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.51987.737417.316381@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 16:51:47 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1333106583.15932.94.camel@zakaz.uk.xensource.com>
References: <201203291439.q2TEdJKL006923@wind.enjellic.com>
	<1333095477.15932.26.camel@zakaz.uk.xensource.com>
	<1333106583.15932.94.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Basic blktap2 functionality issues."):
> On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > I think an approach worth trying would be to have
> > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > doing the actual detach. i.e. it would respond with "Yes, I will do
> > that" rather than "Yes, I have done that". My speculation is that this
> > will allow libxl to continue and hopefully avoid the deadlock.
> 
> This seems to be the case as the following fixes things for me. Thanks
> very much for your analysis which lead me to this solution...

Greg, can you confirm whether this works for you ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:00:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjfg-000300-PL; Mon, 02 Apr 2012 15:59:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SEjfe-0002zv-GK
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:59:54 +0000
Received: from [85.158.139.83:21168] by server-12.bemta-5.messagelabs.com id
	08/BC-05587-6FCC97F4; Mon, 02 Apr 2012 15:59:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333382388!22109646!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24659 invoked from network); 2 Apr 2012 15:59:49 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 15:59:49 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q32Fxem6014974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 2 Apr 2012 11:59:40 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q32FxdX7014972;
	Mon, 2 Apr 2012 11:59:39 -0400
Date: Mon, 2 Apr 2012 11:59:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120402155939.GA13833@andromeda.dapyr.net>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<95eda76084314aa8a5cf.1332610906@phenom.dumpdata.com>
	<1332754979.26550.7.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1332754979.26550.7.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.fraser@eu.citrix.com" <keir.fraser@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6] xend/xc: Implement a
	domain_set_e820_hole function to be used by python code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Mar 26, 2012 at 10:42:59AM +0100, Ian Campbell wrote:
> On Sat, 2012-03-24 at 17:41 +0000, Konrad Rzeszutek Wilk wrote:
> > # HG changeset patch
> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > # Date 1332610898 14400
> > # Node ID 95eda76084314aa8a5cfd4b5e83969823492deda
> > # Parent  d42921da3931026ecf5da7c0e5bb86074e77cf71
> > xend/xc: Implement a domain_set_e820_hole function to be used by python code
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > diff -r d42921da3931 -r 95eda7608431 tools/python/xen/lowlevel/xc/xc.c
> > --- a/tools/python/xen/lowlevel/xc/xc.c	Sat Mar 24 13:41:38 2012 -0400
> > +++ b/tools/python/xen/lowlevel/xc/xc.c	Sat Mar 24 13:41:38 2012 -0400
> > @@ -16,6 +16,7 @@
> >  #include <sys/mman.h>
> >  #include <netdb.h>
> >  #include <arpa/inet.h>
> > +#include <stdio.h>
> >  
> >  #include "xenctrl.h"
> >  #include <xen/elfnote.h>
> > @@ -1697,6 +1698,243 @@ static PyObject *pyxc_domain_set_memmap_
> >      return zero;
> >  }
> >  
> > +#ifdef PRIu64
> 
> This is a really weird condition -- when / where does this end up not
> defined?

32-bit, but not sure now if the problem still exists.
> 
> Perhaps you see this depending on platform? In which case is this just a
> case of including the right header (stdint.h?) directly instead of
> implicitly via some arch dependent chain of includes?

<nods> That is probably what I hit and never tried to resolve.

> 
> > +static const char *e820_names(int type)
> > +{
> > +    switch (type) {
> > +        case E820_RAM: return "RAM";
> > +        case E820_RESERVED: return "Reserved";
> > +        case E820_ACPI: return "ACPI";
> > +        case E820_NVS: return "ACPI NVS";
> > +        case E820_UNUSABLE: return "Unusable";
> > +        default: break;
> > +    }
> > +    return "Unknown";
> > +}
> > +#endif
> > +static int e820_sanitize(struct e820entry src[],
> > +                         uint32_t *nr_entries,
> > +                         unsigned long map_limitkb,
> > +                         unsigned long balloon_kb)
> > +{
> 
> Seems odd to do this in the C bindings, can this be done either in the
> python layer or in the libxc layer (in which case libxl can use it too?)

So this is copied from the libxl layer (With the removal of the
libxl_ctx). I was hoping you could shed some ideas of how to "export" that
function (e820_sanitize) from the libxl_pci.c so that the
tools/python/xen/lowlevel/xc/xc.c can also use it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:00:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjfg-000300-PL; Mon, 02 Apr 2012 15:59:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SEjfe-0002zv-GK
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 15:59:54 +0000
Received: from [85.158.139.83:21168] by server-12.bemta-5.messagelabs.com id
	08/BC-05587-6FCC97F4; Mon, 02 Apr 2012 15:59:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333382388!22109646!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24659 invoked from network); 2 Apr 2012 15:59:49 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 15:59:49 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q32Fxem6014974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 2 Apr 2012 11:59:40 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q32FxdX7014972;
	Mon, 2 Apr 2012 11:59:39 -0400
Date: Mon, 2 Apr 2012 11:59:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120402155939.GA13833@andromeda.dapyr.net>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<95eda76084314aa8a5cf.1332610906@phenom.dumpdata.com>
	<1332754979.26550.7.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1332754979.26550.7.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.fraser@eu.citrix.com" <keir.fraser@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6] xend/xc: Implement a
	domain_set_e820_hole function to be used by python code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Mar 26, 2012 at 10:42:59AM +0100, Ian Campbell wrote:
> On Sat, 2012-03-24 at 17:41 +0000, Konrad Rzeszutek Wilk wrote:
> > # HG changeset patch
> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > # Date 1332610898 14400
> > # Node ID 95eda76084314aa8a5cfd4b5e83969823492deda
> > # Parent  d42921da3931026ecf5da7c0e5bb86074e77cf71
> > xend/xc: Implement a domain_set_e820_hole function to be used by python code
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > diff -r d42921da3931 -r 95eda7608431 tools/python/xen/lowlevel/xc/xc.c
> > --- a/tools/python/xen/lowlevel/xc/xc.c	Sat Mar 24 13:41:38 2012 -0400
> > +++ b/tools/python/xen/lowlevel/xc/xc.c	Sat Mar 24 13:41:38 2012 -0400
> > @@ -16,6 +16,7 @@
> >  #include <sys/mman.h>
> >  #include <netdb.h>
> >  #include <arpa/inet.h>
> > +#include <stdio.h>
> >  
> >  #include "xenctrl.h"
> >  #include <xen/elfnote.h>
> > @@ -1697,6 +1698,243 @@ static PyObject *pyxc_domain_set_memmap_
> >      return zero;
> >  }
> >  
> > +#ifdef PRIu64
> 
> This is a really weird condition -- when / where does this end up not
> defined?

32-bit, but not sure now if the problem still exists.
> 
> Perhaps you see this depending on platform? In which case is this just a
> case of including the right header (stdint.h?) directly instead of
> implicitly via some arch dependent chain of includes?

<nods> That is probably what I hit and never tried to resolve.

> 
> > +static const char *e820_names(int type)
> > +{
> > +    switch (type) {
> > +        case E820_RAM: return "RAM";
> > +        case E820_RESERVED: return "Reserved";
> > +        case E820_ACPI: return "ACPI";
> > +        case E820_NVS: return "ACPI NVS";
> > +        case E820_UNUSABLE: return "Unusable";
> > +        default: break;
> > +    }
> > +    return "Unknown";
> > +}
> > +#endif
> > +static int e820_sanitize(struct e820entry src[],
> > +                         uint32_t *nr_entries,
> > +                         unsigned long map_limitkb,
> > +                         unsigned long balloon_kb)
> > +{
> 
> Seems odd to do this in the C bindings, can this be done either in the
> python layer or in the libxc layer (in which case libxl can use it too?)

So this is copied from the libxl layer (With the removal of the
libxl_ctx). I was hoping you could shed some ideas of how to "export" that
function (e820_sanitize) from the libxl_pci.c so that the
tools/python/xen/lowlevel/xc/xc.c can also use it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjgc-0003T7-C9; Mon, 02 Apr 2012 16:00:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SEjgZ-0003Sq-Du
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:00:53 +0000
Received: from [85.158.143.99:60781] by server-3.bemta-4.messagelabs.com id
	52/E6-05853-23DC97F4; Mon, 02 Apr 2012 16:00:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333382449!21984089!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1246 invoked from network); 2 Apr 2012 16:00:50 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 16:00:50 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q32G0jJd015257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 2 Apr 2012 12:00:45 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q32G0j9j015255;
	Mon, 2 Apr 2012 12:00:45 -0400
Date: Mon, 2 Apr 2012 12:00:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402160045.GB13833@andromeda.dapyr.net>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<67f01753ae43f66a1a4b.1332610907@phenom.dumpdata.com>
	<20337.50204.619331.417545@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20337.50204.619331.417545@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.fraser@eu.citrix.com" <keir.fraser@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6] xend: Add support for passing in the
	host's E820 for PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Mar 27, 2012 at 02:43:56PM +0100, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH 6 of 6] xend: Add support for passing in the host's E820 for PCI passthrough"):
> > xend: Add support for passing in the host's E820 for PCI passthrough
> ...>
> > The code that populates E820 is unconditionally triggered by the guest
> > configuration having 'e820_hole=1'.
> 
> Isn't this similar to some xl/libxl features ?  "e820_host" maybe.

Yes. It is called 'e820_host'. Sorry about that - I had used an earlier
version of the patches to make this work on the python stack.
> 
> We certainly don't want to add any new features to xend with
> incompatible config settings to xl.

Of course not.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjgc-0003T7-C9; Mon, 02 Apr 2012 16:00:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SEjgZ-0003Sq-Du
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:00:53 +0000
Received: from [85.158.143.99:60781] by server-3.bemta-4.messagelabs.com id
	52/E6-05853-23DC97F4; Mon, 02 Apr 2012 16:00:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333382449!21984089!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1246 invoked from network); 2 Apr 2012 16:00:50 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Apr 2012 16:00:50 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q32G0jJd015257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 2 Apr 2012 12:00:45 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q32G0j9j015255;
	Mon, 2 Apr 2012 12:00:45 -0400
Date: Mon, 2 Apr 2012 12:00:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402160045.GB13833@andromeda.dapyr.net>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<67f01753ae43f66a1a4b.1332610907@phenom.dumpdata.com>
	<20337.50204.619331.417545@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20337.50204.619331.417545@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.fraser@eu.citrix.com" <keir.fraser@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6] xend: Add support for passing in the
	host's E820 for PCI passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Mar 27, 2012 at 02:43:56PM +0100, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH 6 of 6] xend: Add support for passing in the host's E820 for PCI passthrough"):
> > xend: Add support for passing in the host's E820 for PCI passthrough
> ...>
> > The code that populates E820 is unconditionally triggered by the guest
> > configuration having 'e820_hole=1'.
> 
> Isn't this similar to some xl/libxl features ?  "e820_host" maybe.

Yes. It is called 'e820_host'. Sorry about that - I had used an earlier
version of the patches to make this work on the python stack.
> 
> We certainly don't want to add any new features to xend with
> incompatible config settings to xl.

Of course not.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:03:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjhw-0003Zm-RM; Mon, 02 Apr 2012 16:02:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjhv-0003Zg-I7
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:02:15 +0000
Received: from [85.158.138.51:34834] by server-6.bemta-3.messagelabs.com id
	89/CB-08206-68DC97F4; Mon, 02 Apr 2012 16:02:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333382534!20405135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19908 invoked from network); 2 Apr 2012 16:02:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:02:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:02:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:02:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjht-0003JS-NQ; Mon, 02 Apr 2012 16:02:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjht-0000ye-MW;
	Mon, 02 Apr 2012 17:02:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52613.678587.769581@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:02:13 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1332778334@cosworth.uk.xensource.com>
References: <patchbomb.1332778334@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew.Cooper3@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3 DOCDAY] updates to Xen command line
 argument documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 0 of 3 DOCDAY] updates to Xen command line argument documentation"):
> The following patches update misc/xen-command-line.markdown. Resend
> with Andrew Coopers comments addressed.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:03:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjhw-0003Zm-RM; Mon, 02 Apr 2012 16:02:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjhv-0003Zg-I7
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:02:15 +0000
Received: from [85.158.138.51:34834] by server-6.bemta-3.messagelabs.com id
	89/CB-08206-68DC97F4; Mon, 02 Apr 2012 16:02:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333382534!20405135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19908 invoked from network); 2 Apr 2012 16:02:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:02:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:02:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:02:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjht-0003JS-NQ; Mon, 02 Apr 2012 16:02:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjht-0000ye-MW;
	Mon, 02 Apr 2012 17:02:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52613.678587.769581@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:02:13 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1332778334@cosworth.uk.xensource.com>
References: <patchbomb.1332778334@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew.Cooper3@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3 DOCDAY] updates to Xen command line
 argument documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 0 of 3 DOCDAY] updates to Xen command line argument documentation"):
> The following patches update misc/xen-command-line.markdown. Resend
> with Andrew Coopers comments addressed.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:04:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:04:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjjM-0003jc-N3; Mon, 02 Apr 2012 16:03:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjjL-0003jN-Uy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:03:44 +0000
Received: from [193.109.254.147:46243] by server-3.bemta-14.messagelabs.com id
	E0/82-23274-FDDC97F4; Mon, 02 Apr 2012 16:03:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333382622!3083499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21116 invoked from network); 2 Apr 2012 16:03:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:03:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:03:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:03:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjjK-0003Jx-DL	for xen-devel@lists.xensource.com;
	Mon, 02 Apr 2012 16:03:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjjK-00010l-Cd	for
	xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:03:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52702.226386.92630@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:03:42 +0100
To: xen-devel@lists.xensource.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20336.41504.222477.918612@mariner.uk.xensource.com>
References: <20336.41504.222477.918612@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] docs: Document some more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("[Xen-devel] [PATCH] docs: Document some more hypercalls"):
> Some of these could probably do with some review from people who know
> what these hypercalls actually do.

I have applied this patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:04:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:04:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjjM-0003jc-N3; Mon, 02 Apr 2012 16:03:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjjL-0003jN-Uy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:03:44 +0000
Received: from [193.109.254.147:46243] by server-3.bemta-14.messagelabs.com id
	E0/82-23274-FDDC97F4; Mon, 02 Apr 2012 16:03:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333382622!3083499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21116 invoked from network); 2 Apr 2012 16:03:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:03:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:03:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:03:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjjK-0003Jx-DL	for xen-devel@lists.xensource.com;
	Mon, 02 Apr 2012 16:03:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjjK-00010l-Cd	for
	xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:03:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52702.226386.92630@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:03:42 +0100
To: xen-devel@lists.xensource.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20336.41504.222477.918612@mariner.uk.xensource.com>
References: <20336.41504.222477.918612@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] docs: Document some more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("[Xen-devel] [PATCH] docs: Document some more hypercalls"):
> Some of these could probably do with some review from people who know
> what these hypercalls actually do.

I have applied this patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjiZ-0003dA-9J; Mon, 02 Apr 2012 16:02:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjiX-0003cn-5I
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:02:53 +0000
Received: from [85.158.139.83:2348] by server-11.bemta-5.messagelabs.com id
	9B/96-12959-CADC97F4; Mon, 02 Apr 2012 16:02:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333382571!22107303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 484 invoked from network); 2 Apr 2012 16:02:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:02:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	17:02:51 +0100
Message-ID: <1333382570.25602.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Mon, 2 Apr 2012 17:02:50 +0100
In-Reply-To: <20120402155939.GA13833@andromeda.dapyr.net>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<95eda76084314aa8a5cf.1332610906@phenom.dumpdata.com>
	<1332754979.26550.7.camel@zakaz.uk.xensource.com>
	<20120402155939.GA13833@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.fraser@eu.citrix.com" <keir.fraser@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6] xend/xc: Implement a
 domain_set_e820_hole function to be used by python code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 16:59 +0100, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 26, 2012 at 10:42:59AM +0100, Ian Campbell wrote:
> > 
> > > +static const char *e820_names(int type)
> > > +{
> > > +    switch (type) {
> > > +        case E820_RAM: return "RAM";
> > > +        case E820_RESERVED: return "Reserved";
> > > +        case E820_ACPI: return "ACPI";
> > > +        case E820_NVS: return "ACPI NVS";
> > > +        case E820_UNUSABLE: return "Unusable";
> > > +        default: break;
> > > +    }
> > > +    return "Unknown";
> > > +}
> > > +#endif
> > > +static int e820_sanitize(struct e820entry src[],
> > > +                         uint32_t *nr_entries,
> > > +                         unsigned long map_limitkb,
> > > +                         unsigned long balloon_kb)
> > > +{
> > 
> > Seems odd to do this in the C bindings, can this be done either in the
> > python layer or in the libxc layer (in which case libxl can use it too?)
> 
> So this is copied from the libxl layer (With the removal of the
> libxl_ctx). I was hoping you could shed some ideas of how to "export" that
> function (e820_sanitize) from the libxl_pci.c so that the
> tools/python/xen/lowlevel/xc/xc.c can also use it?

The only way would be to move this functionality into libxc instead of
libxl.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjiZ-0003dA-9J; Mon, 02 Apr 2012 16:02:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjiX-0003cn-5I
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:02:53 +0000
Received: from [85.158.139.83:2348] by server-11.bemta-5.messagelabs.com id
	9B/96-12959-CADC97F4; Mon, 02 Apr 2012 16:02:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333382571!22107303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 484 invoked from network); 2 Apr 2012 16:02:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:02:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	17:02:51 +0100
Message-ID: <1333382570.25602.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Mon, 2 Apr 2012 17:02:50 +0100
In-Reply-To: <20120402155939.GA13833@andromeda.dapyr.net>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<95eda76084314aa8a5cf.1332610906@phenom.dumpdata.com>
	<1332754979.26550.7.camel@zakaz.uk.xensource.com>
	<20120402155939.GA13833@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.fraser@eu.citrix.com" <keir.fraser@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6] xend/xc: Implement a
 domain_set_e820_hole function to be used by python code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 16:59 +0100, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 26, 2012 at 10:42:59AM +0100, Ian Campbell wrote:
> > 
> > > +static const char *e820_names(int type)
> > > +{
> > > +    switch (type) {
> > > +        case E820_RAM: return "RAM";
> > > +        case E820_RESERVED: return "Reserved";
> > > +        case E820_ACPI: return "ACPI";
> > > +        case E820_NVS: return "ACPI NVS";
> > > +        case E820_UNUSABLE: return "Unusable";
> > > +        default: break;
> > > +    }
> > > +    return "Unknown";
> > > +}
> > > +#endif
> > > +static int e820_sanitize(struct e820entry src[],
> > > +                         uint32_t *nr_entries,
> > > +                         unsigned long map_limitkb,
> > > +                         unsigned long balloon_kb)
> > > +{
> > 
> > Seems odd to do this in the C bindings, can this be done either in the
> > python layer or in the libxc layer (in which case libxl can use it too?)
> 
> So this is copied from the libxl layer (With the removal of the
> libxl_ctx). I was hoping you could shed some ideas of how to "export" that
> function (e820_sanitize) from the libxl_pci.c so that the
> tools/python/xen/lowlevel/xc/xc.c can also use it?

The only way would be to move this functionality into libxc instead of
libxl.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:05:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjkw-0003wH-7G; Mon, 02 Apr 2012 16:05:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjku-0003w2-Mr
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:05:20 +0000
Received: from [85.158.138.51:37823] by server-8.bemta-3.messagelabs.com id
	9C/79-29305-F3EC97F4; Mon, 02 Apr 2012 16:05:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333382719!18600735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4569 invoked from network); 2 Apr 2012 16:05:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:05:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:05:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:05:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjks-0003Mi-M0; Mon, 02 Apr 2012 16:05:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjks-000115-LC;
	Mon, 02 Apr 2012 17:05:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52798.635608.20418@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:05:18 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4c94b3af302d4825b1e2.1332844639@cosworth.uk.xensource.com>
References: <4c94b3af302d4825b1e2.1332844639@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] README: Document optional ocaml dependencies
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] README: Document optional ocaml dependencies"):
> README: Document optional ocaml dependencies

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:05:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjkw-0003wH-7G; Mon, 02 Apr 2012 16:05:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjku-0003w2-Mr
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:05:20 +0000
Received: from [85.158.138.51:37823] by server-8.bemta-3.messagelabs.com id
	9C/79-29305-F3EC97F4; Mon, 02 Apr 2012 16:05:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333382719!18600735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4569 invoked from network); 2 Apr 2012 16:05:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:05:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:05:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:05:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjks-0003Mi-M0; Mon, 02 Apr 2012 16:05:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjks-000115-LC;
	Mon, 02 Apr 2012 17:05:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52798.635608.20418@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:05:18 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4c94b3af302d4825b1e2.1332844639@cosworth.uk.xensource.com>
References: <4c94b3af302d4825b1e2.1332844639@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] README: Document optional ocaml dependencies
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] README: Document optional ocaml dependencies"):
> README: Document optional ocaml dependencies

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:07:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjnC-0004B1-Oc; Mon, 02 Apr 2012 16:07:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjnA-0004Aq-PB
	for Xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:07:40 +0000
Received: from [193.109.254.147:33430] by server-12.bemta-14.messagelabs.com
	id FC/85-05847-CCEC97F4; Mon, 02 Apr 2012 16:07:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333382859!3018790!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3717 invoked from network); 2 Apr 2012 16:07:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:07:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:07:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjn9-0003UH-88; Mon, 02 Apr 2012 16:07:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjn9-00018J-6A;
	Mon, 02 Apr 2012 17:07:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52939.135980.825969@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:07:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330010204.8557.93.camel@zakaz.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
	<1329995862.8557.83.camel@zakaz.uk.xensource.com>
	<1330010204.8557.93.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Re-reading domain configs on domain restart"):
> I've only lightly tested the following, but it seemed to do what I
> expected (I used it to change memory from 512 to 1024 for a Windows VM
> on reboot).
...
> xl: provide a command to set the saved configuration for a running domain

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:07:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjnC-0004B1-Oc; Mon, 02 Apr 2012 16:07:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjnA-0004Aq-PB
	for Xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:07:40 +0000
Received: from [193.109.254.147:33430] by server-12.bemta-14.messagelabs.com
	id FC/85-05847-CCEC97F4; Mon, 02 Apr 2012 16:07:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333382859!3018790!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3717 invoked from network); 2 Apr 2012 16:07:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11727986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:07:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:07:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjn9-0003UH-88; Mon, 02 Apr 2012 16:07:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjn9-00018J-6A;
	Mon, 02 Apr 2012 17:07:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.52939.135980.825969@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:07:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330010204.8557.93.camel@zakaz.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
	<1329995862.8557.83.camel@zakaz.uk.xensource.com>
	<1330010204.8557.93.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Re-reading domain configs on domain restart"):
> I've only lightly tested the following, but it seemed to do what I
> expected (I used it to change memory from 512 to 1024 for a Windows VM
> on reboot).
...
> xl: provide a command to set the saved configuration for a running domain

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:10:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjpx-0004O1-B7; Mon, 02 Apr 2012 16:10:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjpw-0004Ns-9w
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:10:32 +0000
Received: from [85.158.143.35:62891] by server-2.bemta-4.messagelabs.com id
	09/A7-17550-77FC97F4; Mon, 02 Apr 2012 16:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333383030!10622751!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4991 invoked from network); 2 Apr 2012 16:10:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:10:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:10:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjpu-0003Wp-7X; Mon, 02 Apr 2012 16:10:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjpu-0001GP-6e;
	Mon, 02 Apr 2012 17:10:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53110.188156.671221@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:10:30 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2c4b17937bd19855e59a.1332853053@cosworth.uk.xensource.com>
References: <2c4b17937bd19855e59a.1332853053@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: do not include xenctrl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] xl: do not include xenctrl.h"):
> xl: do not include xenctrl.h
> 
> Toolstacks which use libxl should not need to use libxc.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:10:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjpx-0004O1-B7; Mon, 02 Apr 2012 16:10:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjpw-0004Ns-9w
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:10:32 +0000
Received: from [85.158.143.35:62891] by server-2.bemta-4.messagelabs.com id
	09/A7-17550-77FC97F4; Mon, 02 Apr 2012 16:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333383030!10622751!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4991 invoked from network); 2 Apr 2012 16:10:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:10:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:10:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjpu-0003Wp-7X; Mon, 02 Apr 2012 16:10:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjpu-0001GP-6e;
	Mon, 02 Apr 2012 17:10:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53110.188156.671221@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:10:30 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2c4b17937bd19855e59a.1332853053@cosworth.uk.xensource.com>
References: <2c4b17937bd19855e59a.1332853053@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: do not include xenctrl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] xl: do not include xenctrl.h"):
> xl: do not include xenctrl.h
> 
> Toolstacks which use libxl should not need to use libxc.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:11:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjr1-0004Vn-W7; Mon, 02 Apr 2012 16:11:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjr0-0004Va-Dy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:11:38 +0000
Received: from [193.109.254.147:16067] by server-8.bemta-14.messagelabs.com id
	E2/94-23244-9BFC97F4; Mon, 02 Apr 2012 16:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333383097!3080546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4347 invoked from network); 2 Apr 2012 16:11:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:11:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:11:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	17:11:36 +0100
Message-ID: <1333383095.25602.94.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Date: Mon, 2 Apr 2012 17:11:35 +0100
In-Reply-To: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> Hi guys,
> 
> I have started preparing a library of PV-HVM templates for use on Xen
> 4.X+ and PVOPS dom0.
[...]
> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> (the final beta, will be updated to final shortly).
> Included is an OS image, a config file, a README and the associated
> licences etc.

This is very cool, and you are correct that these will be very useful
for people trying to get something going quickly! Thanks Joseph.

> The images are bz2 compressed blockdevice images suitable for use on
> LVM or a file backed tapdisk if you have the appropriate backend.
> (alternatively you can use the loop device but this is discouraged)
> All images have serial console enabled, PV network and block devices,
> fixed udev rules etc.
> 
> I will add more info about them, an FAQ about how they are setup and
> what you should do to customize them, expand the disk image etc soon.
> 
> I am looking for someone to mirror these in the US for me, please
> email me if you have spare bandwith.
> 
> Joseph.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:11:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjr1-0004Vn-W7; Mon, 02 Apr 2012 16:11:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjr0-0004Va-Dy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:11:38 +0000
Received: from [193.109.254.147:16067] by server-8.bemta-14.messagelabs.com id
	E2/94-23244-9BFC97F4; Mon, 02 Apr 2012 16:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333383097!3080546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4347 invoked from network); 2 Apr 2012 16:11:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:11:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:11:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	17:11:36 +0100
Message-ID: <1333383095.25602.94.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Date: Mon, 2 Apr 2012 17:11:35 +0100
In-Reply-To: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> Hi guys,
> 
> I have started preparing a library of PV-HVM templates for use on Xen
> 4.X+ and PVOPS dom0.
[...]
> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> (the final beta, will be updated to final shortly).
> Included is an OS image, a config file, a README and the associated
> licences etc.

This is very cool, and you are correct that these will be very useful
for people trying to get something going quickly! Thanks Joseph.

> The images are bz2 compressed blockdevice images suitable for use on
> LVM or a file backed tapdisk if you have the appropriate backend.
> (alternatively you can use the loop device but this is discouraged)
> All images have serial console enabled, PV network and block devices,
> fixed udev rules etc.
> 
> I will add more info about them, an FAQ about how they are setup and
> what you should do to customize them, expand the disk image etc soon.
> 
> I am looking for someone to mirror these in the US for me, please
> email me if you have spare bandwith.
> 
> Joseph.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:12:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjrJ-0004Yd-2w; Mon, 02 Apr 2012 16:11:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjrI-0004YP-5V
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:11:56 +0000
Received: from [85.158.143.99:64520] by server-3.bemta-4.messagelabs.com id
	BE/67-05853-BCFC97F4; Mon, 02 Apr 2012 16:11:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333383114!16725113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17297 invoked from network); 2 Apr 2012 16:11:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:11:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:11:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	17:11:53 +0100
Message-ID: <1333383112.25602.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 17:11:52 +0100
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv4 00/04] arm: pass a device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:50 +0100, David Vrabel wrote:
> We don't yet make use of the device tree to map MMIO regions or setup
> interrupts for the guest and we still include the UART used for Xen's
> console.
> 
> Note the kernel must support device tree (ATAGS are no longer provided
> by Xen).
> 
> It is also possible to provide the Xen and dom0 command line via the
> device tree.  This isn't as useful as it seems as Xen still needs to
> be rebuilt to included the updated device tree.

Applied, thanks.

BTW, I dropped the dump of the DT tree, it's ok for debugging DT
specifically but a bit much for normal use.

> The instructions on the wiki[1] have been updated to reflect these
> changes.

There's a reference to "make dtbs" in there, should that be changed to
reflect the need to use a DTB from your device-tree.git (which has a
differently named target)?

Ian.

> 
> Changes since v3:
>   - dropped already applied patches
>   - tweaked set_memory_reg() to be a bit more readable.
> 
> Changes since v2:
>   - dropped already applied patches
>   - fix crash on boot if bootargs is missing
>   - allow space in dom0's dtb for the mem reserve entry
>   - bail if dom0's dtb couldn't be created
>   - new patch to print warning if a node is nested too deep
> 
> Changes since v1:
>   - coding style
>   - move libfdt headers
>   - added myself as device tree maintainer
>   - fix potential infinite loop when assigning mem
>   - check dtb destination more carefully
>   - minor updates for clarity
> 
> David
> 
> [1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:12:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjrJ-0004Yd-2w; Mon, 02 Apr 2012 16:11:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEjrI-0004YP-5V
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:11:56 +0000
Received: from [85.158.143.99:64520] by server-3.bemta-4.messagelabs.com id
	BE/67-05853-BCFC97F4; Mon, 02 Apr 2012 16:11:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333383114!16725113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17297 invoked from network); 2 Apr 2012 16:11:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:11:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:11:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012
	17:11:53 +0100
Message-ID: <1333383112.25602.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Apr 2012 17:11:52 +0100
In-Reply-To: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
References: <1333363834-2520-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv4 00/04] arm: pass a device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 11:50 +0100, David Vrabel wrote:
> We don't yet make use of the device tree to map MMIO regions or setup
> interrupts for the guest and we still include the UART used for Xen's
> console.
> 
> Note the kernel must support device tree (ATAGS are no longer provided
> by Xen).
> 
> It is also possible to provide the Xen and dom0 command line via the
> device tree.  This isn't as useful as it seems as Xen still needs to
> be rebuilt to included the updated device tree.

Applied, thanks.

BTW, I dropped the dump of the DT tree, it's ok for debugging DT
specifically but a bit much for normal use.

> The instructions on the wiki[1] have been updated to reflect these
> changes.

There's a reference to "make dtbs" in there, should that be changed to
reflect the need to use a DTB from your device-tree.git (which has a
differently named target)?

Ian.

> 
> Changes since v3:
>   - dropped already applied patches
>   - tweaked set_memory_reg() to be a bit more readable.
> 
> Changes since v2:
>   - dropped already applied patches
>   - fix crash on boot if bootargs is missing
>   - allow space in dom0's dtb for the mem reserve entry
>   - bail if dom0's dtb couldn't be created
>   - new patch to print warning if a node is nested too deep
> 
> Changes since v1:
>   - coding style
>   - move libfdt headers
>   - added myself as device tree maintainer
>   - fix potential infinite loop when assigning mem
>   - check dtb destination more carefully
>   - minor updates for clarity
> 
> David
> 
> [1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:16:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjv8-00055E-VB; Mon, 02 Apr 2012 16:15:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjv7-00054y-Bw
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:15:53 +0000
Received: from [85.158.139.83:20972] by server-9.bemta-5.messagelabs.com id
	A0/24-09826-8B0D97F4; Mon, 02 Apr 2012 16:15:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333383350!18226212!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2575 invoked from network); 2 Apr 2012 16:15:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:15:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:15:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:15:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjv3-0003aA-AL; Mon, 02 Apr 2012 16:15:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjv3-0001Gx-9N;
	Mon, 02 Apr 2012 17:15:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53429.51575.373166@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:15:49 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> On Fri, 30 Mar 2012, Ian Jackson wrote:
> > Since we need to be able to allocate some vbds dynamically, the right
> > approach is to decree that some portion of the dom0 vbd space is
> > reserved for static allocations by the administrator, and that the
> > remainder is for dynamic allocations by software which picks a free
> > vbd.  Naturally the static space should come first.
> 
> When you hotplug a new disk on your system, for example a new USB disk
> to your native Linux box, usually Linux chooses the device name for
> you. I don't see why this should be any different.

It is different because Xen vbds do in practice appear in dom0 with a
stable name.  So this is something that people have reasonably come to
rely on.

> The admin is going to call instead:
>   xl block-attach 0
> and then checkout dmesg.

This is hardly automatable.  Doing the same thing with udev rules is
quite hard work.

> > I don't think that is true.  On each individual guest platform, the
> > relationship between vbd numbers (the actual interface between
> > frontend and backend), and whatever that guest has for device names,
> > needs to be statically defined.
> 
> I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never
> specified what names the guest kernel is allowed to choose for a
> particular vbd encoding. See the following quote:
> 
> "The Xen interface does not specify what name a device should have in the
> guest (nor what major/minor device number it should have in the guest,
> if the guest has such a concept)."

This refers to the promises made by each side of the Xen VBD interface
to the corresponding other side.  The host's environment is not
allowed to assume things about the guest's device naming conventions.

However, that does not mean that the guest should not document its
naming conventions.  Perhaps this needs to be clarified in the
document.

> What I find confusing is that before you say that "the relationship
> between vbd numbers and whatever that guest has for device names needs
> to be statically defined", but then you say that "the device name in the
> guest is not written to xenstore anywhere.  It is private to the guest."

It is private to the guest and the guest administrator and the guest
documentation.  The guest is not required to notify the host of what
name it has chosen.  (And if it does choose a name that name might be
some crazy thing; imagine if the guest is MVS/370 or something.)

> Maybe we can slightly improve the situation moving libxl__alloc_vdev to
> an OS specific file so that we can have a Linux and a BSD implementation.

We only need a specific implementation of the final mapping from vbd
number to guest-specific device name.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:16:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjv8-00055E-VB; Mon, 02 Apr 2012 16:15:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjv7-00054y-Bw
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:15:53 +0000
Received: from [85.158.139.83:20972] by server-9.bemta-5.messagelabs.com id
	A0/24-09826-8B0D97F4; Mon, 02 Apr 2012 16:15:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333383350!18226212!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2575 invoked from network); 2 Apr 2012 16:15:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:15:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:15:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:15:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjv3-0003aA-AL; Mon, 02 Apr 2012 16:15:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjv3-0001Gx-9N;
	Mon, 02 Apr 2012 17:15:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53429.51575.373166@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:15:49 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> On Fri, 30 Mar 2012, Ian Jackson wrote:
> > Since we need to be able to allocate some vbds dynamically, the right
> > approach is to decree that some portion of the dom0 vbd space is
> > reserved for static allocations by the administrator, and that the
> > remainder is for dynamic allocations by software which picks a free
> > vbd.  Naturally the static space should come first.
> 
> When you hotplug a new disk on your system, for example a new USB disk
> to your native Linux box, usually Linux chooses the device name for
> you. I don't see why this should be any different.

It is different because Xen vbds do in practice appear in dom0 with a
stable name.  So this is something that people have reasonably come to
rely on.

> The admin is going to call instead:
>   xl block-attach 0
> and then checkout dmesg.

This is hardly automatable.  Doing the same thing with udev rules is
quite hard work.

> > I don't think that is true.  On each individual guest platform, the
> > relationship between vbd numbers (the actual interface between
> > frontend and backend), and whatever that guest has for device names,
> > needs to be statically defined.
> 
> I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never
> specified what names the guest kernel is allowed to choose for a
> particular vbd encoding. See the following quote:
> 
> "The Xen interface does not specify what name a device should have in the
> guest (nor what major/minor device number it should have in the guest,
> if the guest has such a concept)."

This refers to the promises made by each side of the Xen VBD interface
to the corresponding other side.  The host's environment is not
allowed to assume things about the guest's device naming conventions.

However, that does not mean that the guest should not document its
naming conventions.  Perhaps this needs to be clarified in the
document.

> What I find confusing is that before you say that "the relationship
> between vbd numbers and whatever that guest has for device names needs
> to be statically defined", but then you say that "the device name in the
> guest is not written to xenstore anywhere.  It is private to the guest."

It is private to the guest and the guest administrator and the guest
documentation.  The guest is not required to notify the host of what
name it has chosen.  (And if it does choose a name that name might be
some crazy thing; imagine if the guest is MVS/370 or something.)

> Maybe we can slightly improve the situation moving libxl__alloc_vdev to
> an OS specific file so that we can have a Linux and a BSD implementation.

We only need a specific implementation of the final mapping from vbd
number to guest-specific device name.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:16:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjv9-00055M-AW; Mon, 02 Apr 2012 16:15:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjv7-00054x-FV
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:15:53 +0000
Received: from [85.158.139.83:23974] by server-1.bemta-5.messagelabs.com id
	71/30-28458-8B0D97F4; Mon, 02 Apr 2012 16:15:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333383350!18226212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2551 invoked from network); 2 Apr 2012 16:15:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:15:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:15:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:15:49 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEjv3-0003a6-2d;
	Mon, 02 Apr 2012 16:15:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEjv2-0006Go-TY;
	Mon, 02 Apr 2012 17:15:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12544-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 17:15:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12544: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12544 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12544/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12541
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12541

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12541 like 11874

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12541 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12541 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12541 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:16:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjv9-00055M-AW; Mon, 02 Apr 2012 16:15:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjv7-00054x-FV
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:15:53 +0000
Received: from [85.158.139.83:23974] by server-1.bemta-5.messagelabs.com id
	71/30-28458-8B0D97F4; Mon, 02 Apr 2012 16:15:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333383350!18226212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2551 invoked from network); 2 Apr 2012 16:15:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:15:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:15:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:15:49 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEjv3-0003a6-2d;
	Mon, 02 Apr 2012 16:15:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEjv2-0006Go-TY;
	Mon, 02 Apr 2012 17:15:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12544-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 17:15:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12544: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12544 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12544/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12541
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12541

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12541 like 11874

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12541 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12541 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12541 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjxX-0005Mg-SZ; Mon, 02 Apr 2012 16:18:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjxX-0005MU-5l
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:18:23 +0000
Received: from [193.109.254.147:30332] by server-8.bemta-14.messagelabs.com id
	A1/C8-23244-E41D97F4; Mon, 02 Apr 2012 16:18:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333383501!3057457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25049 invoked from network); 2 Apr 2012 16:18:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:18:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:18:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjxU-0003bM-GT; Mon, 02 Apr 2012 16:18:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjxU-0001Hc-FT;
	Mon, 02 Apr 2012 17:18:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53580.464371.690500@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:18:20 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203301144510.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.61376.319377.655549@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301144510.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/6] libxl:
	introduce	libxl__device_generic_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/6] libxl: introduce libxl__device_generic_add_t"):
> On Tue, 27 Mar 2012, Ian Jackson wrote:
> > Can we avoid introducing more of these transaction loops using goto ?
> 
> I am afraid I actually prefer the simple goto scheme than the convoluted
> code below.

I really can't stomach any more of these gotos.  If you don't want to
abstract it away, can't you at least write the loop as a loop with
for() or while() ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEjxX-0005Mg-SZ; Mon, 02 Apr 2012 16:18:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEjxX-0005MU-5l
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:18:23 +0000
Received: from [193.109.254.147:30332] by server-8.bemta-14.messagelabs.com id
	A1/C8-23244-E41D97F4; Mon, 02 Apr 2012 16:18:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333383501!3057457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25049 invoked from network); 2 Apr 2012 16:18:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:18:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:18:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEjxU-0003bM-GT; Mon, 02 Apr 2012 16:18:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEjxU-0001Hc-FT;
	Mon, 02 Apr 2012 17:18:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53580.464371.690500@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:18:20 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203301144510.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.61376.319377.655549@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301144510.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/6] libxl:
	introduce	libxl__device_generic_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/6] libxl: introduce libxl__device_generic_add_t"):
> On Tue, 27 Mar 2012, Ian Jackson wrote:
> > Can we avoid introducing more of these transaction loops using goto ?
> 
> I am afraid I actually prefer the simple goto scheme than the convoluted
> code below.

I really can't stomach any more of these gotos.  If you don't want to
abstract it away, can't you at least write the loop as a loop with
for() or while() ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:21:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEk0C-0005ZO-EZ; Mon, 02 Apr 2012 16:21:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEk0B-0005Z9-9O
	for Xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:21:07 +0000
Received: from [85.158.139.83:59396] by server-6.bemta-5.messagelabs.com id
	43/9D-13222-3F1D97F4; Mon, 02 Apr 2012 16:21:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333383666!21571321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2047 invoked from network); 2 Apr 2012 16:21:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:21:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:21:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:21:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEk09-0003dz-LH; Mon, 02 Apr 2012 16:21:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEk09-0001Ht-KH;
	Mon, 02 Apr 2012 17:21:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53745.404872.917708@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:21:05 +0100
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC2AEAC715344@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC2AEAC715344@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] libxc: Report a better error on state file EOF.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Frediano Ziglio writes ("[Xen-devel] libxc: Report a better error on state file EOF."):
> If a EOF is detected in state file 4 error are reported
>  - 0-length
>  - read_exact_timed failed
>  - Error when reading batch size (0 = Success)
>  - Error when reading batch (0 = Success)
> 
> With this patch just one error is reported
>  - Error when reading batch size (32 = Broken pipe)

I approve of the idea of improving the error messages.  But I'm afraid
I must quibble with the reuse of EPIPE this way.  In general it is not
a good idea to synthesise errno values; people expect them to mean
specific things.  In this case EPIPE is an error that only the writer
on a pipe sees, so an admin who sees "Broken pipe" will expect that
the problem was that the writer detected that the reader went away.

I think a better approach would be to state explicitly (in
documentation comments) which situations cause an error report and
which don't, and simply reduce duplication.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:21:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEk0C-0005ZO-EZ; Mon, 02 Apr 2012 16:21:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEk0B-0005Z9-9O
	for Xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:21:07 +0000
Received: from [85.158.139.83:59396] by server-6.bemta-5.messagelabs.com id
	43/9D-13222-3F1D97F4; Mon, 02 Apr 2012 16:21:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333383666!21571321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2047 invoked from network); 2 Apr 2012 16:21:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:21:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:21:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:21:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEk09-0003dz-LH; Mon, 02 Apr 2012 16:21:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEk09-0001Ht-KH;
	Mon, 02 Apr 2012 17:21:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53745.404872.917708@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:21:05 +0100
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC2AEAC715344@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC2AEAC715344@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] libxc: Report a better error on state file EOF.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Frediano Ziglio writes ("[Xen-devel] libxc: Report a better error on state file EOF."):
> If a EOF is detected in state file 4 error are reported
>  - 0-length
>  - read_exact_timed failed
>  - Error when reading batch size (0 = Success)
>  - Error when reading batch (0 = Success)
> 
> With this patch just one error is reported
>  - Error when reading batch size (32 = Broken pipe)

I approve of the idea of improving the error messages.  But I'm afraid
I must quibble with the reuse of EPIPE this way.  In general it is not
a good idea to synthesise errno values; people expect them to mean
specific things.  In this case EPIPE is an error that only the writer
on a pipe sees, so an admin who sees "Broken pipe" will expect that
the problem was that the writer detected that the reader went away.

I think a better approach would be to state explicitly (in
documentation comments) which situations cause an error report and
which don't, and simply reduce duplication.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:22:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEk1o-0005hh-VC; Mon, 02 Apr 2012 16:22:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEk1n-0005hU-IR
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:22:47 +0000
Received: from [193.109.254.147:23975] by server-8.bemta-14.messagelabs.com id
	A2/7B-23244-652D97F4; Mon, 02 Apr 2012 16:22:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1333383766!3065115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12733 invoked from network); 2 Apr 2012 16:22:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:22:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:22:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEk1m-0003eW-5E; Mon, 02 Apr 2012 16:22:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEk1m-0001JS-4R;
	Mon, 02 Apr 2012 17:22:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53846.122834.218561@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:22:46 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f9ce45c9f9842ce5d829.1332860503@kodo2>
References: <f9ce45c9f9842ce5d829.1332860503@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl: Handle non-ballooned,
 zero slackmem properly for pci passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] libxl: Handle non-ballooned, zero slackmem properly for pci passthru"):
> The e820_sanitize() function in libxl_pci.c expects one of its arguments to
> be non-zero; but since a recent changeset, it can typically expect *to be*
> zero.  Since the zero case is handled properly, just remove the check.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:22:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEk1o-0005hh-VC; Mon, 02 Apr 2012 16:22:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEk1n-0005hU-IR
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:22:47 +0000
Received: from [193.109.254.147:23975] by server-8.bemta-14.messagelabs.com id
	A2/7B-23244-652D97F4; Mon, 02 Apr 2012 16:22:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1333383766!3065115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12733 invoked from network); 2 Apr 2012 16:22:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:22:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:22:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEk1m-0003eW-5E; Mon, 02 Apr 2012 16:22:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEk1m-0001JS-4R;
	Mon, 02 Apr 2012 17:22:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.53846.122834.218561@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:22:46 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f9ce45c9f9842ce5d829.1332860503@kodo2>
References: <f9ce45c9f9842ce5d829.1332860503@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl: Handle non-ballooned,
 zero slackmem properly for pci passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] libxl: Handle non-ballooned, zero slackmem properly for pci passthru"):
> The e820_sanitize() function in libxl_pci.c expects one of its arguments to
> be non-zero; but since a recent changeset, it can typically expect *to be*
> zero.  Since the zero case is handled properly, just remove the check.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:33:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:33:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkBu-00061C-49; Mon, 02 Apr 2012 16:33:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkBt-000616-Fq
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:33:13 +0000
Received: from [85.158.143.99:48648] by server-2.bemta-4.messagelabs.com id
	69/D0-17550-8C4D97F4; Mon, 02 Apr 2012 16:33:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333384390!21659456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8534 invoked from network); 2 Apr 2012 16:33:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:33:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:33:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:33:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkBp-0003zx-LW; Mon, 02 Apr 2012 16:33:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkBp-0001TQ-Kb;
	Mon, 02 Apr 2012 17:33:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54469.617588.601756@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:33:09 +0100
To: Lin Ming <mlin@ss.pku.edu.cn>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332681791.22280.3.camel@hp6530s>
References: <1332681791.22280.3.camel@hp6530s>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] libxl: support for "rtc_timeoffset"
	and	"localtime"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lin Ming writes ("[Xen-devel] [PATCH v3] libxl: support for "rtc_timeoffset" and "localtime""):
> Implement "rtc_timeoffset" and "localtime" options compatible as xm.

Thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:33:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:33:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkBu-00061C-49; Mon, 02 Apr 2012 16:33:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkBt-000616-Fq
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:33:13 +0000
Received: from [85.158.143.99:48648] by server-2.bemta-4.messagelabs.com id
	69/D0-17550-8C4D97F4; Mon, 02 Apr 2012 16:33:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333384390!21659456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8534 invoked from network); 2 Apr 2012 16:33:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:33:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:33:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:33:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkBp-0003zx-LW; Mon, 02 Apr 2012 16:33:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkBp-0001TQ-Kb;
	Mon, 02 Apr 2012 17:33:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54469.617588.601756@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:33:09 +0100
To: Lin Ming <mlin@ss.pku.edu.cn>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332681791.22280.3.camel@hp6530s>
References: <1332681791.22280.3.camel@hp6530s>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] libxl: support for "rtc_timeoffset"
	and	"localtime"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lin Ming writes ("[Xen-devel] [PATCH v3] libxl: support for "rtc_timeoffset" and "localtime""):
> Implement "rtc_timeoffset" and "localtime" options compatible as xm.

Thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:36:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkFI-00068l-Qn; Mon, 02 Apr 2012 16:36:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkFH-00068b-K4
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:36:43 +0000
Received: from [193.109.254.147:23788] by server-1.bemta-14.messagelabs.com id
	13/78-29372-A95D97F4; Mon, 02 Apr 2012 16:36:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333384602!3060015!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24120 invoked from network); 2 Apr 2012 16:36:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:36:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:36:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:36:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkFF-00042t-T2; Mon, 02 Apr 2012 16:36:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkFF-00028z-Nw;
	Mon, 02 Apr 2012 17:36:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54680.633964.114159@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:36:40 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
References: <4F703E27020000780007AD24@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Yongjie Ren <yongjie.ren@intel.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional/passthrough: adjust MSI-X
 device cleanup (bug 1809)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu-traditional/passthrough: adjust MSI-X device cleanup (bug 1809)"):
> On Mon, 26 Mar 2012, Jan Beulich wrote:
> > To address http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809,
> > pt_unregister_regions() also needs to use the newly introduced
> > _pt_iomem_helper() instead of calling xc_domain_memory_mapping()
> > directly, to take into consideration the hole created for the MSI-X
> > table.
...
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > Tested-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I will update the QEMU_TAG in xen-unstable soon.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:36:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkFI-00068l-Qn; Mon, 02 Apr 2012 16:36:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkFH-00068b-K4
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:36:43 +0000
Received: from [193.109.254.147:23788] by server-1.bemta-14.messagelabs.com id
	13/78-29372-A95D97F4; Mon, 02 Apr 2012 16:36:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333384602!3060015!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24120 invoked from network); 2 Apr 2012 16:36:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:36:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:36:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:36:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkFF-00042t-T2; Mon, 02 Apr 2012 16:36:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkFF-00028z-Nw;
	Mon, 02 Apr 2012 17:36:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54680.633964.114159@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:36:40 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
References: <4F703E27020000780007AD24@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1203261124360.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Yongjie Ren <yongjie.ren@intel.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional/passthrough: adjust MSI-X
 device cleanup (bug 1809)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu-traditional/passthrough: adjust MSI-X device cleanup (bug 1809)"):
> On Mon, 26 Mar 2012, Jan Beulich wrote:
> > To address http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809,
> > pt_unregister_regions() also needs to use the newly introduced
> > _pt_iomem_helper() instead of calling xc_domain_memory_mapping()
> > directly, to take into consideration the hole created for the MSI-X
> > table.
...
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > Tested-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I will update the QEMU_TAG in xen-unstable soon.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:38:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkGO-0006Em-F3; Mon, 02 Apr 2012 16:37:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkGN-0006Eb-4w
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:37:51 +0000
Received: from [85.158.139.83:2614] by server-9.bemta-5.messagelabs.com id
	CF/F5-09826-ED5D97F4; Mon, 02 Apr 2012 16:37:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333384668!10846124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 2 Apr 2012 16:37:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:37:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:37:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:37:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkGJ-00043C-AM; Mon, 02 Apr 2012 16:37:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkGJ-0002CO-9W;
	Mon, 02 Apr 2012 17:37:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54747.274913.649349@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:37:47 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d8e15dc99bf307bd0ae0.1332752899@cosworth.uk.xensource.com>
References: <d8e15dc99bf307bd0ae0.1332752899@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH DOCDAY] docs: expand docs/INDEX,
 sort html index by title rather than filename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH DOCDAY] docs: expand docs/INDEX, sort html index by title rather than filename"):
> docs: expand docs/INDEX, sort html index by title rather than filename

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:38:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkGO-0006Em-F3; Mon, 02 Apr 2012 16:37:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkGN-0006Eb-4w
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:37:51 +0000
Received: from [85.158.139.83:2614] by server-9.bemta-5.messagelabs.com id
	CF/F5-09826-ED5D97F4; Mon, 02 Apr 2012 16:37:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333384668!10846124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 2 Apr 2012 16:37:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:37:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="11728502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:37:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:37:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkGJ-00043C-AM; Mon, 02 Apr 2012 16:37:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkGJ-0002CO-9W;
	Mon, 02 Apr 2012 17:37:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54747.274913.649349@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:37:47 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d8e15dc99bf307bd0ae0.1332752899@cosworth.uk.xensource.com>
References: <d8e15dc99bf307bd0ae0.1332752899@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH DOCDAY] docs: expand docs/INDEX,
 sort html index by title rather than filename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH DOCDAY] docs: expand docs/INDEX, sort html index by title rather than filename"):
> docs: expand docs/INDEX, sort html index by title rather than filename

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkJG-0006RQ-35; Mon, 02 Apr 2012 16:40:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEkJF-0006RH-1g
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:40:49 +0000
Received: from [85.158.143.99:28067] by server-1.bemta-4.messagelabs.com id
	97/88-20925-096D97F4; Mon, 02 Apr 2012 16:40:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333384846!12341676!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10361 invoked from network); 2 Apr 2012 16:40:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:40:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330923600"; d="scan'208";a="23788371"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 12:40:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 12:40:46 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEkJB-0005Ur-BU;
	Mon, 02 Apr 2012 17:40:45 +0100
Message-ID: <4F79D673.9000104@eu.citrix.com>
Date: Mon, 2 Apr 2012 17:40:19 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
	<20345.51964.865778.569742@mariner.uk.xensource.com>
In-Reply-To: <20345.51964.865778.569742@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 16:51, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
>> I'm not sure how we can make it more definite.  What's possible (i.e.,
>> the security implications) entirely depends on the card; and what's
>> likely (i.e., the stability implications) entirely depends on the card
>> and the driver.  Short of giving a short discourse on the vices of
>> various cards PCI config space (which is entirely inappropriate for a
>> man page, IMHO), I'm not sure what more we can say.
> Is it generally or usually the case that this option will more
> completely expose the host ?
So, worst-case, the guest driver can make the card do anything a card 
can actually do.  Most of the things a card can do can be mitigated by 
the IOMMU.  But there may be some things which are not; and there are 
some people still running older hardware that either doesn't have an 
IOMMU, or whose IOMMU cannot handle important cases (e.g., Intel boxes 
with VTD but no interrupt remapping, if you recall the security issue 
related to this last year).

One of the examples Stefano gave of config stuff that can cause problems 
is the power management features: if the guest driver powers down the 
card, then when libxl tries to reset the card, it generates a PCI error 
interrupt.  This used to crash Xen. (It's now been fixed.)

But on the other hand, how many cards even have these kinds of dangerous 
capabilities in their PCI registers?  Most of them are probably just 
fine.  And in the case of driver domains, most people will be running 
trusted software anyway; the driver will be the same in the domU as the 
dom0.

Still, can't very well just turn things on by default and hope for the 
best; people need to know that they're doing something potentially 
dangerous.  But we can't really tell people how dangerous this thing 
might be, because we don't actually know how many cards might actually 
be dangerous, and we don't know what kind of software they're allowing 
access to the card.  And again, we can't just not give the option, 
because many cards need it to run, and most of the time it's just fine.

This is probably worth doing some more investigation and writing up in a 
doc and/or a wiki page somewhere; but I'm not sure we can do more in a 
man page than give a necessarily unspecific warning.

  -George
>> I thought it was unnecessary to duplicate, but I can do so if you prefer.
> I guess that depends on how strong a statement it is.
>
>>> I think you should consider breakibg out the sysfs writing function
>>> and refactoring with the very similar code in libxl__device_pci_reset,
>>> rather than introducing yet another clone.
>> I shall consider it. :-)
> Thanks :-).
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkJG-0006RQ-35; Mon, 02 Apr 2012 16:40:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEkJF-0006RH-1g
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:40:49 +0000
Received: from [85.158.143.99:28067] by server-1.bemta-4.messagelabs.com id
	97/88-20925-096D97F4; Mon, 02 Apr 2012 16:40:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333384846!12341676!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10361 invoked from network); 2 Apr 2012 16:40:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:40:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330923600"; d="scan'208";a="23788371"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 12:40:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 12:40:46 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEkJB-0005Ur-BU;
	Mon, 02 Apr 2012 17:40:45 +0100
Message-ID: <4F79D673.9000104@eu.citrix.com>
Date: Mon, 2 Apr 2012 17:40:19 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
	<20345.51964.865778.569742@mariner.uk.xensource.com>
In-Reply-To: <20345.51964.865778.569742@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 16:51, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
>> I'm not sure how we can make it more definite.  What's possible (i.e.,
>> the security implications) entirely depends on the card; and what's
>> likely (i.e., the stability implications) entirely depends on the card
>> and the driver.  Short of giving a short discourse on the vices of
>> various cards PCI config space (which is entirely inappropriate for a
>> man page, IMHO), I'm not sure what more we can say.
> Is it generally or usually the case that this option will more
> completely expose the host ?
So, worst-case, the guest driver can make the card do anything a card 
can actually do.  Most of the things a card can do can be mitigated by 
the IOMMU.  But there may be some things which are not; and there are 
some people still running older hardware that either doesn't have an 
IOMMU, or whose IOMMU cannot handle important cases (e.g., Intel boxes 
with VTD but no interrupt remapping, if you recall the security issue 
related to this last year).

One of the examples Stefano gave of config stuff that can cause problems 
is the power management features: if the guest driver powers down the 
card, then when libxl tries to reset the card, it generates a PCI error 
interrupt.  This used to crash Xen. (It's now been fixed.)

But on the other hand, how many cards even have these kinds of dangerous 
capabilities in their PCI registers?  Most of them are probably just 
fine.  And in the case of driver domains, most people will be running 
trusted software anyway; the driver will be the same in the domU as the 
dom0.

Still, can't very well just turn things on by default and hope for the 
best; people need to know that they're doing something potentially 
dangerous.  But we can't really tell people how dangerous this thing 
might be, because we don't actually know how many cards might actually 
be dangerous, and we don't know what kind of software they're allowing 
access to the card.  And again, we can't just not give the option, 
because many cards need it to run, and most of the time it's just fine.

This is probably worth doing some more investigation and writing up in a 
doc and/or a wiki page somewhere; but I'm not sure we can do more in a 
man page than give a necessarily unspecific warning.

  -George
>> I thought it was unnecessary to duplicate, but I can do so if you prefer.
> I guess that depends on how strong a statement it is.
>
>>> I think you should consider breakibg out the sysfs writing function
>>> and refactoring with the very similar code in libxl__device_pci_reset,
>>> rather than introducing yet another clone.
>> I shall consider it. :-)
> Thanks :-).
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkJZ-0006U3-Fh; Mon, 02 Apr 2012 16:41:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkJY-0006Tq-Ap
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:41:08 +0000
Received: from [85.158.139.83:6884] by server-1.bemta-5.messagelabs.com id
	FE/F8-28458-3A6D97F4; Mon, 02 Apr 2012 16:41:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333384866!10846547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25380 invoked from network); 2 Apr 2012 16:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:41:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:41:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkJV-00044I-NJ; Mon, 02 Apr 2012 16:41:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkJV-0002ZO-MQ;
	Mon, 02 Apr 2012 17:41:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54945.676934.660530@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:41:05 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b66a4a57cee2de421fb5.1332768156@probook.site>
References: <b66a4a57cee2de421fb5.1332768156@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libxc: send page-in requests in batches in linux_privcmd_map_foreign_bulk"):
> tools/libxc: send page-in requests in batches in linux_privcmd_map_foreign_bulk

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkJZ-0006U3-Fh; Mon, 02 Apr 2012 16:41:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkJY-0006Tq-Ap
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:41:08 +0000
Received: from [85.158.139.83:6884] by server-1.bemta-5.messagelabs.com id
	FE/F8-28458-3A6D97F4; Mon, 02 Apr 2012 16:41:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333384866!10846547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25380 invoked from network); 2 Apr 2012 16:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:41:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:41:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkJV-00044I-NJ; Mon, 02 Apr 2012 16:41:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkJV-0002ZO-MQ;
	Mon, 02 Apr 2012 17:41:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.54945.676934.660530@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:41:05 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b66a4a57cee2de421fb5.1332768156@probook.site>
References: <b66a4a57cee2de421fb5.1332768156@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libxc: send page-in requests in batches in linux_privcmd_map_foreign_bulk"):
> tools/libxc: send page-in requests in batches in linux_privcmd_map_foreign_bulk

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkKu-0006ei-Ut; Mon, 02 Apr 2012 16:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkKt-0006eU-9q
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:42:31 +0000
Received: from [85.158.143.99:9845] by server-3.bemta-4.messagelabs.com id
	B1/3A-05853-6F6D97F4; Mon, 02 Apr 2012 16:42:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333384949!16243095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20945 invoked from network); 2 Apr 2012 16:42:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:42:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:42:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:42:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkKq-00044k-Qx; Mon, 02 Apr 2012 16:42:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkKq-0002ZZ-QA;
	Mon, 02 Apr 2012 17:42:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55028.794810.345590@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:42:28 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4F79D673.9000104@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
	<20345.51964.865778.569742@mariner.uk.xensource.com>
	<4F79D673.9000104@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> This is probably worth doing some more investigation and writing up in a 
> doc and/or a wiki page somewhere; but I'm not sure we can do more in a 
> man page than give a necessarily unspecific warning.

OK.  I guess that's fine as it is then.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkKu-0006ei-Ut; Mon, 02 Apr 2012 16:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkKt-0006eU-9q
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:42:31 +0000
Received: from [85.158.143.99:9845] by server-3.bemta-4.messagelabs.com id
	B1/3A-05853-6F6D97F4; Mon, 02 Apr 2012 16:42:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333384949!16243095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20945 invoked from network); 2 Apr 2012 16:42:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:42:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:42:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:42:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkKq-00044k-Qx; Mon, 02 Apr 2012 16:42:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkKq-0002ZZ-QA;
	Mon, 02 Apr 2012 17:42:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55028.794810.345590@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:42:28 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4F79D673.9000104@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
	<20345.51964.865778.569742@mariner.uk.xensource.com>
	<4F79D673.9000104@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> This is probably worth doing some more investigation and writing up in a 
> doc and/or a wiki page somewhere; but I'm not sure we can do more in a 
> man page than give a necessarily unspecific warning.

OK.  I guess that's fine as it is then.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:44:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkMc-0006qP-Hx; Mon, 02 Apr 2012 16:44:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkMb-0006q9-3Q
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:44:17 +0000
Received: from [85.158.143.35:49425] by server-2.bemta-4.messagelabs.com id
	20/6C-17550-067D97F4; Mon, 02 Apr 2012 16:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333385055!16790543!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22687 invoked from network); 2 Apr 2012 16:44:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728608"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:44:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:44:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkMY-00045H-GD; Mon, 02 Apr 2012 16:44:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkMY-0002bs-FG;
	Mon, 02 Apr 2012 17:44:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55134.456659.983163@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:44:14 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5e375e46b51d0a5e2932.1332769651@Solace>
References: <5e375e46b51d0a5e2932.1332769651@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [DOC DAY] Document vcpu-pinning in guest
	config	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[Xen-devel] [PATCH] [DOC DAY] Document vcpu-pinning in guest config file"):
> 

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:44:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkMc-0006qP-Hx; Mon, 02 Apr 2012 16:44:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkMb-0006q9-3Q
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 16:44:17 +0000
Received: from [85.158.143.35:49425] by server-2.bemta-4.messagelabs.com id
	20/6C-17550-067D97F4; Mon, 02 Apr 2012 16:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333385055!16790543!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22687 invoked from network); 2 Apr 2012 16:44:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728608"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:44:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:44:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkMY-00045H-GD; Mon, 02 Apr 2012 16:44:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkMY-0002bs-FG;
	Mon, 02 Apr 2012 17:44:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55134.456659.983163@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:44:14 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5e375e46b51d0a5e2932.1332769651@Solace>
References: <5e375e46b51d0a5e2932.1332769651@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [DOC DAY] Document vcpu-pinning in guest
	config	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[Xen-devel] [PATCH] [DOC DAY] Document vcpu-pinning in guest config file"):
> 

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:46:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkOD-00073E-1K; Mon, 02 Apr 2012 16:45:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkOB-000735-UM
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:45:56 +0000
Received: from [85.158.139.83:35981] by server-1.bemta-5.messagelabs.com id
	80/7F-28458-3C7D97F4; Mon, 02 Apr 2012 16:45:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333385153!22029813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31501 invoked from network); 2 Apr 2012 16:45:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:45:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:45:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:45:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkO8-00049U-Uo; Mon, 02 Apr 2012 16:45:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkO8-0002dz-Tw;
	Mon, 02 Apr 2012 17:45:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55232.911200.3326@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:45:52 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332770876-5169-1-git-send-email-anthony.perard@citrix.com>
References: <1332770876-5169-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] doc, Remove qemu-upstream HowTo,
	and link to the wiki page.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] doc, Remove qemu-upstream HowTo, and link to the wiki page."):
> Instead of having twice the same HowTo in tree and in the wiki, the
> one in tree will become a link to the wiki.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I fixed up the summary line to start with "docs: " as docs patches
should.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:46:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkOD-00073E-1K; Mon, 02 Apr 2012 16:45:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkOB-000735-UM
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:45:56 +0000
Received: from [85.158.139.83:35981] by server-1.bemta-5.messagelabs.com id
	80/7F-28458-3C7D97F4; Mon, 02 Apr 2012 16:45:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333385153!22029813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31501 invoked from network); 2 Apr 2012 16:45:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:45:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:45:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:45:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkO8-00049U-Uo; Mon, 02 Apr 2012 16:45:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkO8-0002dz-Tw;
	Mon, 02 Apr 2012 17:45:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55232.911200.3326@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:45:52 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332770876-5169-1-git-send-email-anthony.perard@citrix.com>
References: <1332770876-5169-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] doc, Remove qemu-upstream HowTo,
	and link to the wiki page.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] doc, Remove qemu-upstream HowTo, and link to the wiki page."):
> Instead of having twice the same HowTo in tree and in the wiki, the
> one in tree will become a link to the wiki.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I fixed up the summary line to start with "docs: " as docs patches
should.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:53:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkUv-0007HZ-Tk; Mon, 02 Apr 2012 16:52:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkUu-0007HU-O1
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:52:52 +0000
Received: from [85.158.143.35:25286] by server-3.bemta-4.messagelabs.com id
	2A/C3-05853-369D97F4; Mon, 02 Apr 2012 16:52:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333385571!14599092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 854 invoked from network); 2 Apr 2012 16:52:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:52:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:52:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:52:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkUr-0004Bz-Tu; Mon, 02 Apr 2012 16:52:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkUr-0002jY-Ss;
	Mon, 02 Apr 2012 17:52:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55649.878167.515986@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:52:49 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bb3ac8aac229dc1f0fc5.1332510431@phenom.dumpdata.com>
References: <bb3ac8aac229dc1f0fc5.1332510431@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir.fraser@eu.citrix.com, jbeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] linux-xencommons: Load xen-acpi-processor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH] linux-xencommons: Load xen-acpi-processor"):
> linux-xencommons: Load xen-acpi-processor

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:53:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkUv-0007HZ-Tk; Mon, 02 Apr 2012 16:52:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkUu-0007HU-O1
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:52:52 +0000
Received: from [85.158.143.35:25286] by server-3.bemta-4.messagelabs.com id
	2A/C3-05853-369D97F4; Mon, 02 Apr 2012 16:52:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333385571!14599092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 854 invoked from network); 2 Apr 2012 16:52:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:52:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:52:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:52:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkUr-0004Bz-Tu; Mon, 02 Apr 2012 16:52:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkUr-0002jY-Ss;
	Mon, 02 Apr 2012 17:52:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55649.878167.515986@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:52:49 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bb3ac8aac229dc1f0fc5.1332510431@phenom.dumpdata.com>
References: <bb3ac8aac229dc1f0fc5.1332510431@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir.fraser@eu.citrix.com, jbeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] linux-xencommons: Load xen-acpi-processor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH] linux-xencommons: Load xen-acpi-processor"):
> linux-xencommons: Load xen-acpi-processor

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkYZ-0007RJ-MO; Mon, 02 Apr 2012 16:56:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkYZ-0007RE-1R
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:56:39 +0000
Received: from [193.109.254.147:13132] by server-3.bemta-14.messagelabs.com id
	0D/82-23274-64AD97F4; Mon, 02 Apr 2012 16:56:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1333385797!3096062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25144 invoked from network); 2 Apr 2012 16:56:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:56:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:56:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:56:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkYX-0004DB-0h; Mon, 02 Apr 2012 16:56:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkYW-0002ss-WA;
	Mon, 02 Apr 2012 17:56:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55876.979344.17338@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:56:36 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk
	performance	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> Hi all,
> this small patch series enables the O_DIRECT flag to open disk images
> for both the IDE and xen_disk interface.
> Also it includes few fixes for xen_disk.
> 
> Stefano Stabellini (3):
>       qemu-xen-traditional: use O_DIRECT to open disk images for IDE
>       qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
>       qemu-xen-traditional: QDISK fixes

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkYZ-0007RJ-MO; Mon, 02 Apr 2012 16:56:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkYZ-0007RE-1R
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:56:39 +0000
Received: from [193.109.254.147:13132] by server-3.bemta-14.messagelabs.com id
	0D/82-23274-64AD97F4; Mon, 02 Apr 2012 16:56:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1333385797!3096062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25144 invoked from network); 2 Apr 2012 16:56:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:56:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 16:56:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 17:56:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkYX-0004DB-0h; Mon, 02 Apr 2012 16:56:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkYW-0002ss-WA;
	Mon, 02 Apr 2012 17:56:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.55876.979344.17338@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 17:56:36 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk
	performance	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> Hi all,
> this small patch series enables the O_DIRECT flag to open disk images
> for both the IDE and xen_disk interface.
> Also it includes few fixes for xen_disk.
> 
> Stefano Stabellini (3):
>       qemu-xen-traditional: use O_DIRECT to open disk images for IDE
>       qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
>       qemu-xen-traditional: QDISK fixes

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:57:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:57:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkZK-0007V0-3U; Mon, 02 Apr 2012 16:57:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEkZI-0007Up-9t
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:57:24 +0000
Received: from [85.158.138.51:12877] by server-8.bemta-3.messagelabs.com id
	45/8E-29305-37AD97F4; Mon, 02 Apr 2012 16:57:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333385841!9426090!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30954 invoked from network); 2 Apr 2012 16:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330923600"; d="scan'208";a="23788924"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 12:57:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 12:57:20 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEkZD-0005kR-M4;
	Mon, 02 Apr 2012 17:57:19 +0100
Message-ID: <4F79DA55.7090706@eu.citrix.com>
Date: Mon, 2 Apr 2012 17:56:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
	<20345.51964.865778.569742@mariner.uk.xensource.com>
In-Reply-To: <20345.51964.865778.569742@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 16:51, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
>> I'm not sure how we can make it more definite.  What's possible (i.e.,
>> the security implications) entirely depends on the card; and what's
>> likely (i.e., the stability implications) entirely depends on the card
>> and the driver.  Short of giving a short discourse on the vices of
>> various cards PCI config space (which is entirely inappropriate for a
>> man page, IMHO), I'm not sure what more we can say.
> Is it generally or usually the case that this option will more
> completely expose the host ?
>
>> I thought it was unnecessary to duplicate, but I can do so if you prefer.
> I guess that depends on how strong a statement it is.
>
>>> I think you should consider breakibg out the sysfs writing function
>>> and refactoring with the very similar code in libxl__device_pci_reset,
>>> rather than introducing yet another clone.
>> I shall consider it. :-)
I think for this patch series I'm probably going to leave it; I'll work 
on it when I add the PCI rebinding stuff.  (Otherwise there's the 
possibility I may end up having to refactor it again.)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 16:57:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 16:57:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkZK-0007V0-3U; Mon, 02 Apr 2012 16:57:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SEkZI-0007Up-9t
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 16:57:24 +0000
Received: from [85.158.138.51:12877] by server-8.bemta-3.messagelabs.com id
	45/8E-29305-37AD97F4; Mon, 02 Apr 2012 16:57:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333385841!9426090!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM5MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30954 invoked from network); 2 Apr 2012 16:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 16:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330923600"; d="scan'208";a="23788924"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 12:57:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 2 Apr 2012 12:57:20 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SEkZD-0005kR-M4;
	Mon, 02 Apr 2012 17:57:19 +0100
Message-ID: <4F79DA55.7090706@eu.citrix.com>
Date: Mon, 2 Apr 2012 17:56:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1333363655@kodo2>
	<62b1030a2485536caf99.1333363657@kodo2>
	<20345.50129.248371.995505@mariner.uk.xensource.com>
	<4F79C912.9010504@eu.citrix.com>
	<20345.51964.865778.569742@mariner.uk.xensource.com>
In-Reply-To: <20345.51964.865778.569742@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/12 16:51, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
>> I'm not sure how we can make it more definite.  What's possible (i.e.,
>> the security implications) entirely depends on the card; and what's
>> likely (i.e., the stability implications) entirely depends on the card
>> and the driver.  Short of giving a short discourse on the vices of
>> various cards PCI config space (which is entirely inappropriate for a
>> man page, IMHO), I'm not sure what more we can say.
> Is it generally or usually the case that this option will more
> completely expose the host ?
>
>> I thought it was unnecessary to duplicate, but I can do so if you prefer.
> I guess that depends on how strong a statement it is.
>
>>> I think you should consider breakibg out the sysfs writing function
>>> and refactoring with the very similar code in libxl__device_pci_reset,
>>> rather than introducing yet another clone.
>> I shall consider it. :-)
I think for this patch series I'm probably going to leave it; I'll work 
on it when I add the PCI rebinding stuff.  (Otherwise there's the 
possibility I may end up having to refactor it again.)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:00:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkcO-0007l8-S8; Mon, 02 Apr 2012 17:00:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkcM-0007kw-Ny
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:00:34 +0000
Received: from [85.158.143.99:51767] by server-3.bemta-4.messagelabs.com id
	D9/F9-05853-23BD97F4; Mon, 02 Apr 2012 17:00:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333386033!21066579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27853 invoked from network); 2 Apr 2012 17:00:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:00:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:00:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:00:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkcK-0004Fz-NX; Mon, 02 Apr 2012 17:00:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkcK-0002tI-MZ;
	Mon, 02 Apr 2012 18:00:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56112.630128.747571@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:00:32 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> <Porting from Xen 4.1 tree.>
> 
> libxl: passthrough: avoid passing through devices not owned by pciback

I'm afraid this no longer applies to xen-unstable.hg tip.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:00:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkcO-0007l8-S8; Mon, 02 Apr 2012 17:00:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkcM-0007kw-Ny
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:00:34 +0000
Received: from [85.158.143.99:51767] by server-3.bemta-4.messagelabs.com id
	D9/F9-05853-23BD97F4; Mon, 02 Apr 2012 17:00:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333386033!21066579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27853 invoked from network); 2 Apr 2012 17:00:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:00:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:00:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:00:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkcK-0004Fz-NX; Mon, 02 Apr 2012 17:00:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkcK-0002tI-MZ;
	Mon, 02 Apr 2012 18:00:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56112.630128.747571@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:00:32 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> <Porting from Xen 4.1 tree.>
> 
> libxl: passthrough: avoid passing through devices not owned by pciback

I'm afraid this no longer applies to xen-unstable.hg tip.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:05:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkh7-0007w0-Ic; Mon, 02 Apr 2012 17:05:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkh6-0007vt-Ac
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 17:05:28 +0000
Received: from [85.158.139.83:23584] by server-7.bemta-5.messagelabs.com id
	1A/15-16195-75CD97F4; Mon, 02 Apr 2012 17:05:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333386325!18232104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 2 Apr 2012 17:05:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:05:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:05:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkh1-0004SJ-KW; Mon, 02 Apr 2012 17:05:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkh1-0002vH-Jb;
	Mon, 02 Apr 2012 18:05:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56403.439274.302212@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:05:23 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <691063aaf0dee77576fb.1332407581@cosworth.uk.xensource.com>
References: <691063aaf0dee77576fb.1332407581@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Attilio Rao <attilio.rao@citrix.com>, Bei Guan <gbtju85@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Use enum values for qemu version not
	raw	numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: Use enum values for qemu version not raw numbers"):
> libxl: Use enum values for qemu version not raw numbers

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:05:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkh7-0007w0-Ic; Mon, 02 Apr 2012 17:05:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkh6-0007vt-Ac
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 17:05:28 +0000
Received: from [85.158.139.83:23584] by server-7.bemta-5.messagelabs.com id
	1A/15-16195-75CD97F4; Mon, 02 Apr 2012 17:05:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333386325!18232104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 2 Apr 2012 17:05:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:05:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:05:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkh1-0004SJ-KW; Mon, 02 Apr 2012 17:05:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkh1-0002vH-Jb;
	Mon, 02 Apr 2012 18:05:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56403.439274.302212@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:05:23 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <691063aaf0dee77576fb.1332407581@cosworth.uk.xensource.com>
References: <691063aaf0dee77576fb.1332407581@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Attilio Rao <attilio.rao@citrix.com>, Bei Guan <gbtju85@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Use enum values for qemu version not
	raw	numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: Use enum values for qemu version not raw numbers"):
> libxl: Use enum values for qemu version not raw numbers

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:11:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkn2-00089k-Ku; Mon, 02 Apr 2012 17:11:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkn1-00089R-8c
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:11:35 +0000
Received: from [193.109.254.147:12428] by server-10.bemta-14.messagelabs.com
	id 57/EA-05847-6CDD97F4; Mon, 02 Apr 2012 17:11:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1333386693!3056301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3510 invoked from network); 2 Apr 2012 17:11:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:11:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:11:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:11:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkmz-0004fq-8X; Mon, 02 Apr 2012 17:11:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkmz-0002vs-7R;
	Mon, 02 Apr 2012 18:11:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56773.8058.87028@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:11:33 +0100
To: Julien Grall <julien.grall@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: julian.pidancet@citrix.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
	option	device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> For the support of multiple ioreq server, we add a new option "device_models".
> It's an array of device model, for each device model, we need to specify
> which pci, IO range (MMIO, PIO) will be allow.

I don't think this is really a suitable interface.  The PCI space in
the guest is controlled by the device models(s) and the user should
surely specify which devices should be provided by which dms, in terms
of devices not in terms of PCI space.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:11:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkn2-00089k-Ku; Mon, 02 Apr 2012 17:11:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkn1-00089R-8c
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:11:35 +0000
Received: from [193.109.254.147:12428] by server-10.bemta-14.messagelabs.com
	id 57/EA-05847-6CDD97F4; Mon, 02 Apr 2012 17:11:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1333386693!3056301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3510 invoked from network); 2 Apr 2012 17:11:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:11:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11728979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:11:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:11:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkmz-0004fq-8X; Mon, 02 Apr 2012 17:11:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkmz-0002vs-7R;
	Mon, 02 Apr 2012 18:11:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56773.8058.87028@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:11:33 +0100
To: Julien Grall <julien.grall@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: julian.pidancet@citrix.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
	option	device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> For the support of multiple ioreq server, we add a new option "device_models".
> It's an array of device model, for each device model, we need to specify
> which pci, IO range (MMIO, PIO) will be allow.

I don't think this is really a suitable interface.  The PCI space in
the guest is controlled by the device models(s) and the user should
surely specify which devices should be provided by which dms, in terms
of devices not in terms of PCI space.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:13:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:13:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkoN-0008HS-8J; Mon, 02 Apr 2012 17:12:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkoL-0008HF-7Q
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:12:57 +0000
Received: from [85.158.138.51:36563] by server-5.bemta-3.messagelabs.com id
	A3/5C-31925-61ED97F4; Mon, 02 Apr 2012 17:12:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333386772!18609694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14355 invoked from network); 2 Apr 2012 17:12:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:12:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11729003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:12:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:12:52 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkoF-0004gV-Vp; Mon, 02 Apr 2012 17:12:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkoF-0002wf-Uu;
	Mon, 02 Apr 2012 18:12:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56851.937052.637505@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:12:51 +0100
To: Julien Grall <julien.grall@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2187e535bf91f5f650401a4e08e0e795003ad2aa.1332430810.git.julien.grall@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<2187e535bf91f5f650401a4e08e0e795003ad2aa.1332430810.git.julien.grall@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: julian.pidancet@citrix.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface to
	support	multiple ioreq server
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface to support multiple ioreq server"):
> Add structure to handle ioreq server. It's server which can
> handle a range of IO (MMIO and/or PIO) and emulate a PCI.
> Each server as its own shared page to receive ioreq. So
> we have introduced to HVM PARAM to set/get the first and
> the last shared used for ioreq. With it's id, the server
> knows which page it must use.

This explanation, and full documentation of the new HVMOPs, should be
included in the hvm_op.h header.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 17:13:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 17:13:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEkoN-0008HS-8J; Mon, 02 Apr 2012 17:12:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEkoL-0008HF-7Q
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:12:57 +0000
Received: from [85.158.138.51:36563] by server-5.bemta-3.messagelabs.com id
	A3/5C-31925-61ED97F4; Mon, 02 Apr 2012 17:12:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333386772!18609694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14355 invoked from network); 2 Apr 2012 17:12:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:12:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="11729003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 17:12:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 18:12:52 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SEkoF-0004gV-Vp; Mon, 02 Apr 2012 17:12:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SEkoF-0002wf-Uu;
	Mon, 02 Apr 2012 18:12:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20345.56851.937052.637505@mariner.uk.xensource.com>
Date: Mon, 2 Apr 2012 18:12:51 +0100
To: Julien Grall <julien.grall@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2187e535bf91f5f650401a4e08e0e795003ad2aa.1332430810.git.julien.grall@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<2187e535bf91f5f650401a4e08e0e795003ad2aa.1332430810.git.julien.grall@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: julian.pidancet@citrix.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface to
	support	multiple ioreq server
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface to support multiple ioreq server"):
> Add structure to handle ioreq server. It's server which can
> handle a range of IO (MMIO and/or PIO) and emulate a PCI.
> Each server as its own shared page to receive ioreq. So
> we have introduced to HVM PARAM to set/get the first and
> the last shared used for ioreq. With it's id, the server
> knows which page it must use.

This explanation, and full documentation of the new HVMOPs, should be
included in the hvm_op.h header.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 18:00:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 18:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SElXd-0000Lc-HI; Mon, 02 Apr 2012 17:59:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SElXb-0000LJ-IR
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:59:43 +0000
Received: from [85.158.138.51:9420] by server-4.bemta-3.messagelabs.com id
	DA/13-16467-E09E97F4; Mon, 02 Apr 2012 17:59:42 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333389580!20435404!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21029 invoked from network); 2 Apr 2012 17:59:41 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:59:41 -0000
Received: by obbwd18 with SMTP id wd18so1880232obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Apr 2012 10:59:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=mvppOzc5khUh6TXRbFoi2n6pVaMwHE82Ti5pwT5Y+8w=;
	b=kTxY6aOz+D4HBAXPRMWQ3DIfaKB8ygepiuZUgXLK3oShZxKdxhvVAYeRkuJqy+61qd
	y377BJzbWSYH8gruyTNAclb8yC12cnUiRjjvirut6slq/Ih7re+lLBwT+xyhWGLFM5oo
	m+uPHQy6SFo6eVtYGKblKujVZE0lpDLYiMzGpedW5fCB1SYaY8EFe2dv91Iwd6qy5h8b
	5lca2IsVPwTg5TzzbL5pwIxpIFhp9ujf3ZZ4JpmpEvXihYxn28uHDweQ8+ey/ZGcjfCO
	PHnU4cejGtFikHnSoN1rXmOx1zXoLhsxLJQwYHjXhCPPQqbp9iQ036vE5SWfDEsfOZ2f
	LpPA==
MIME-Version: 1.0
Received: by 10.182.89.39 with SMTP id bl7mr13778564obb.65.1333389579928; Mon,
	02 Apr 2012 10:59:39 -0700 (PDT)
Received: by 10.182.98.137 with HTTP; Mon, 2 Apr 2012 10:59:39 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
In-Reply-To: <1333383095.25602.94.camel@zakaz.uk.xensource.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Apr 2012 03:59:39 +1000
Message-ID: <CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQlJqFSOY0g7dtZyzUTWh6etP2zXwjTqc5yoFRccF8ydKptkfdSzEWytRTrjJrcx/2bCYGDa
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
>> Hi guys,
>>
>> I have started preparing a library of PV-HVM templates for use on Xen
>> 4.X+ and PVOPS dom0.
> [...]
>> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
>> (the final beta, will be updated to final shortly).
>> Included is an OS image, a config file, a README and the associated
>> licences etc.
>
> This is very cool, and you are correct that these will be very useful
> for people trying to get something going quickly! Thanks Joseph.

No problem, I am working on a new dom0 livecd too.

I need some recommendations on what distro to base it on though...
Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
to be more enduring and a more beginner approachable alternative.

Does anyone have any thoughts on this?

>
>> The images are bz2 compressed blockdevice images suitable for use on
>> LVM or a file backed tapdisk if you have the appropriate backend.
>> (alternatively you can use the loop device but this is discouraged)
>> All images have serial console enabled, PV network and block devices,
>> fixed udev rules etc.
>>
>> I will add more info about them, an FAQ about how they are setup and
>> what you should do to customize them, expand the disk image etc soon.
>>
>> I am looking for someone to mirror these in the US for me, please
>> email me if you have spare bandwith.
>>
>> Joseph.
>>
>
>



-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 18:00:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 18:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SElXd-0000Lc-HI; Mon, 02 Apr 2012 17:59:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SElXb-0000LJ-IR
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 17:59:43 +0000
Received: from [85.158.138.51:9420] by server-4.bemta-3.messagelabs.com id
	DA/13-16467-E09E97F4; Mon, 02 Apr 2012 17:59:42 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333389580!20435404!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21029 invoked from network); 2 Apr 2012 17:59:41 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 17:59:41 -0000
Received: by obbwd18 with SMTP id wd18so1880232obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Apr 2012 10:59:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=mvppOzc5khUh6TXRbFoi2n6pVaMwHE82Ti5pwT5Y+8w=;
	b=kTxY6aOz+D4HBAXPRMWQ3DIfaKB8ygepiuZUgXLK3oShZxKdxhvVAYeRkuJqy+61qd
	y377BJzbWSYH8gruyTNAclb8yC12cnUiRjjvirut6slq/Ih7re+lLBwT+xyhWGLFM5oo
	m+uPHQy6SFo6eVtYGKblKujVZE0lpDLYiMzGpedW5fCB1SYaY8EFe2dv91Iwd6qy5h8b
	5lca2IsVPwTg5TzzbL5pwIxpIFhp9ujf3ZZ4JpmpEvXihYxn28uHDweQ8+ey/ZGcjfCO
	PHnU4cejGtFikHnSoN1rXmOx1zXoLhsxLJQwYHjXhCPPQqbp9iQ036vE5SWfDEsfOZ2f
	LpPA==
MIME-Version: 1.0
Received: by 10.182.89.39 with SMTP id bl7mr13778564obb.65.1333389579928; Mon,
	02 Apr 2012 10:59:39 -0700 (PDT)
Received: by 10.182.98.137 with HTTP; Mon, 2 Apr 2012 10:59:39 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
In-Reply-To: <1333383095.25602.94.camel@zakaz.uk.xensource.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Apr 2012 03:59:39 +1000
Message-ID: <CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQlJqFSOY0g7dtZyzUTWh6etP2zXwjTqc5yoFRccF8ydKptkfdSzEWytRTrjJrcx/2bCYGDa
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
>> Hi guys,
>>
>> I have started preparing a library of PV-HVM templates for use on Xen
>> 4.X+ and PVOPS dom0.
> [...]
>> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
>> (the final beta, will be updated to final shortly).
>> Included is an OS image, a config file, a README and the associated
>> licences etc.
>
> This is very cool, and you are correct that these will be very useful
> for people trying to get something going quickly! Thanks Joseph.

No problem, I am working on a new dom0 livecd too.

I need some recommendations on what distro to base it on though...
Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
to be more enduring and a more beginner approachable alternative.

Does anyone have any thoughts on this?

>
>> The images are bz2 compressed blockdevice images suitable for use on
>> LVM or a file backed tapdisk if you have the appropriate backend.
>> (alternatively you can use the loop device but this is discouraged)
>> All images have serial console enabled, PV network and block devices,
>> fixed udev rules etc.
>>
>> I will add more info about them, an FAQ about how they are setup and
>> what you should do to customize them, expand the disk image etc soon.
>>
>> I am looking for someone to mirror these in the US for me, please
>> email me if you have spare bandwith.
>>
>> Joseph.
>>
>
>



-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 18:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 18:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEllI-0000tL-So; Mon, 02 Apr 2012 18:13:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SEllG-0000tE-Pu
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 18:13:51 +0000
Received: from [85.158.138.51:59919] by server-10.bemta-3.messagelabs.com id
	A3/1A-15637-D5CE97F4; Mon, 02 Apr 2012 18:13:49 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333390427!20296885!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22149 invoked from network); 2 Apr 2012 18:13:49 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 18:13:49 -0000
Received: by obbwd20 with SMTP id wd20so5507813obb.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 11:13:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=OOGTGg2PfZLlYnNIRjtNiiHIflFUBuhD/7NIRMDch2E=;
	b=orzy4dyf41BBZmOBq/FVHZ8rjx9pyzCtqmzbYjsow3fqgmP3eiTmsK7NAMuy9XgwNa
	GfajAOgXSAYH8/cFOiRY3Em3mGiV6sM7ntE5iPuAdsiDas5pKusb2mLmGFIvuSAoLcEI
	5K8ibci7YrvGswyT0ovU4HnQyl+jgIAJO4/tsN2471ZSoI1cdz3YajQCX8QjGL1ofQIj
	brxfMtNmF4XJkgGM3CWh/aHpmfCHflo4A7IrESL4xsdZCzGK2oVTBR0wXHwZ/bNZreRO
	xXKhOGQw7OmJOc/beFd8XxiTmOOVM9BMD2M+AZelz3odSuGZQBfUA2GcHEX38ErzQT6K
	0LEg==
MIME-Version: 1.0
Received: by 10.182.89.39 with SMTP id bl7mr13845960obb.65.1333390427171; Mon,
	02 Apr 2012 11:13:47 -0700 (PDT)
Received: by 10.182.98.137 with HTTP; Mon, 2 Apr 2012 11:13:47 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
In-Reply-To: <20345.48891.162276.828728@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
	<20345.48891.162276.828728@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 04:13:47 +1000
Message-ID: <CAOzFzEir5jDuUVoVN8TRGbQy344CDM30q9L6CzpwyDgnu8M_Yw@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQlVZNkSn4e/7kJcQ/s7UtifPZW8m40xMskyGffCnysWA867Mc/Msu7F2QMYMRT4rlf+WdFs
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3 April 2012 01:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Thanks for your submission; this is coming along but still needs some
> work.
>
> Joseph Glanville writes ("Re: [Xen-devel] [RFC] Shutdown event script for=
 xl toolstack"):
>> On 31 March 2012 05:08, Joseph Glanville
>> <joseph.glanville@orionvm.com.au> wrote:
>> + =A0 =A0 =A0 =A0execvpe(arg0,args,envp);
>
> I'm afraid that execvpe doesn't do what you want: it entirely replaces
> the environment with the one you specify. =A0You need to use putenv or
> setenv.

Ahh I see, my mistake.

>
>> + =A0 =A0if (xlu_cfg_replace_string (config, "shutdown_event_handler",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&d_config->shut=
down_event_handler, 0))
>> + =A0 =A0 =A0 =A0d_config->shutdown_event_handler =3D NULL;
>
> Weren't we going to have one event handler per type of event ?

I have implemented the list stuff now so we can have arguments to to
the handler and I also implemented it split into 4 handlers in the
next revision.

>
>> +{
>> + =A0 =A0int status;
>> + =A0 =A0useconds_t sleep_time =3D 10, wait_time =3D 0;
>> + =A0 =A0pid_t child_pid, wpid;
>
> I'm afraid this timeout approach is not correct; you would need
> something to interrupt the wait, rather than polling like this. =A0I
> think this is impractical. =A0You should, rather, just not implement a
> timeout.

Fair enough. I will drop the timeout.

>
> I would advise against reusing exit statuses 0..6. =A0You should start
> your new exit statuses at 50 or something. =A0This is because many
> programs use status 1 to mean "I failed" and you would want to avoid
> that being misinterpreted.
>
> Other exit statuses, and deaths due to signals, should be reported
> properly as errors using libxl_report_child_exitstatus.

Ok, I will take a look at that and make use of it.

>
>> + =A0 =A0ret =3D xl_exec(arg0,argv,envp,timeout);
>
> I think calling this function xl_exec is a bit unfortunate. =A0It
> doesn't just exec; it also forks.

Hmm that is true.. naming is not my strong point.
xl_fork_exec? :)

>
>> + =A0 =A0 if (d_config->shutdown_event_handler)
>> + =A0 =A0 =A0 =A0action =3D user_shutdown_action(d_config, domid, action,
>> +
>> event->u.domain_shutdown.shutdown_reason);
>
> Something has linewrapped this. =A0You should keep to within 75-80
> lines.

Yep no problem.

>
> Thanks,
> Ian.

What is your call about moving this stuff into domain_create rather
than libxl_domain_config?

Thankyou for all of your comments/help, most appreciated.

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 18:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 18:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEllI-0000tL-So; Mon, 02 Apr 2012 18:13:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SEllG-0000tE-Pu
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 18:13:51 +0000
Received: from [85.158.138.51:59919] by server-10.bemta-3.messagelabs.com id
	A3/1A-15637-D5CE97F4; Mon, 02 Apr 2012 18:13:49 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333390427!20296885!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22149 invoked from network); 2 Apr 2012 18:13:49 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 18:13:49 -0000
Received: by obbwd20 with SMTP id wd20so5507813obb.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 11:13:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=OOGTGg2PfZLlYnNIRjtNiiHIflFUBuhD/7NIRMDch2E=;
	b=orzy4dyf41BBZmOBq/FVHZ8rjx9pyzCtqmzbYjsow3fqgmP3eiTmsK7NAMuy9XgwNa
	GfajAOgXSAYH8/cFOiRY3Em3mGiV6sM7ntE5iPuAdsiDas5pKusb2mLmGFIvuSAoLcEI
	5K8ibci7YrvGswyT0ovU4HnQyl+jgIAJO4/tsN2471ZSoI1cdz3YajQCX8QjGL1ofQIj
	brxfMtNmF4XJkgGM3CWh/aHpmfCHflo4A7IrESL4xsdZCzGK2oVTBR0wXHwZ/bNZreRO
	xXKhOGQw7OmJOc/beFd8XxiTmOOVM9BMD2M+AZelz3odSuGZQBfUA2GcHEX38ErzQT6K
	0LEg==
MIME-Version: 1.0
Received: by 10.182.89.39 with SMTP id bl7mr13845960obb.65.1333390427171; Mon,
	02 Apr 2012 11:13:47 -0700 (PDT)
Received: by 10.182.98.137 with HTTP; Mon, 2 Apr 2012 11:13:47 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
In-Reply-To: <20345.48891.162276.828728@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
	<20345.48891.162276.828728@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 04:13:47 +1000
Message-ID: <CAOzFzEir5jDuUVoVN8TRGbQy344CDM30q9L6CzpwyDgnu8M_Yw@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQlVZNkSn4e/7kJcQ/s7UtifPZW8m40xMskyGffCnysWA867Mc/Msu7F2QMYMRT4rlf+WdFs
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3 April 2012 01:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Thanks for your submission; this is coming along but still needs some
> work.
>
> Joseph Glanville writes ("Re: [Xen-devel] [RFC] Shutdown event script for=
 xl toolstack"):
>> On 31 March 2012 05:08, Joseph Glanville
>> <joseph.glanville@orionvm.com.au> wrote:
>> + =A0 =A0 =A0 =A0execvpe(arg0,args,envp);
>
> I'm afraid that execvpe doesn't do what you want: it entirely replaces
> the environment with the one you specify. =A0You need to use putenv or
> setenv.

Ahh I see, my mistake.

>
>> + =A0 =A0if (xlu_cfg_replace_string (config, "shutdown_event_handler",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&d_config->shut=
down_event_handler, 0))
>> + =A0 =A0 =A0 =A0d_config->shutdown_event_handler =3D NULL;
>
> Weren't we going to have one event handler per type of event ?

I have implemented the list stuff now so we can have arguments to to
the handler and I also implemented it split into 4 handlers in the
next revision.

>
>> +{
>> + =A0 =A0int status;
>> + =A0 =A0useconds_t sleep_time =3D 10, wait_time =3D 0;
>> + =A0 =A0pid_t child_pid, wpid;
>
> I'm afraid this timeout approach is not correct; you would need
> something to interrupt the wait, rather than polling like this. =A0I
> think this is impractical. =A0You should, rather, just not implement a
> timeout.

Fair enough. I will drop the timeout.

>
> I would advise against reusing exit statuses 0..6. =A0You should start
> your new exit statuses at 50 or something. =A0This is because many
> programs use status 1 to mean "I failed" and you would want to avoid
> that being misinterpreted.
>
> Other exit statuses, and deaths due to signals, should be reported
> properly as errors using libxl_report_child_exitstatus.

Ok, I will take a look at that and make use of it.

>
>> + =A0 =A0ret =3D xl_exec(arg0,argv,envp,timeout);
>
> I think calling this function xl_exec is a bit unfortunate. =A0It
> doesn't just exec; it also forks.

Hmm that is true.. naming is not my strong point.
xl_fork_exec? :)

>
>> + =A0 =A0 if (d_config->shutdown_event_handler)
>> + =A0 =A0 =A0 =A0action =3D user_shutdown_action(d_config, domid, action,
>> +
>> event->u.domain_shutdown.shutdown_reason);
>
> Something has linewrapped this. =A0You should keep to within 75-80
> lines.

Yep no problem.

>
> Thanks,
> Ian.

What is your call about moving this stuff into domain_create rather
than libxl_domain_config?

Thankyou for all of your comments/help, most appreciated.

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmb0-0002LE-Ft; Mon, 02 Apr 2012 19:07:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jljusten@gmail.com>) id 1SEmaz-0002KE-3G
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:17 +0000
Received: from [85.158.143.99:29723] by server-3.bemta-4.messagelabs.com id
	E9/9D-05853-4E8F97F4; Mon, 02 Apr 2012 19:07:16 +0000
X-Env-Sender: jljusten@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333393633!16746542!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25896 invoked from network); 2 Apr 2012 19:07:15 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 19:07:15 -0000
Received: by ggnp2 with SMTP id p2so1615703ggn.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 12:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=ZRbpn9wqZ6/c1ecicy4b1lRi3r7NVXzWGAkW+0kAANo=;
	b=ZpP5yAhtywuD2Qfu5qRzJ8tJaQpEi+yHUAuQGHaWWSIccRAFRo+wWroq79Vmr3haIw
	yfyPsNvSrKGBcyrE241lxuMlhd/22SOW6J65uZRJ1dMItNFjWtxuO9izzL+9UZPCWFQS
	Zxpf1Ld07pz/M1/9SB6FbZAq4allv8qwq1iJ+14PfCzHE4dEzJ3GBpvxhKxUKgbn0KQA
	U1fdvhVbMZsTw9RIuWHzyFy76YeD0huvlNqpZ7xxySSa55yFfMaoZ3i/nBkbSblWK975
	jn2jDqUoPBf0wE1r0sxK02K69+wTe6mo1NKPSp5JwQTJEqDzRSEpVRwnZogfuCXKPI9Y
	raHw==
MIME-Version: 1.0
Received: by 10.236.136.33 with SMTP id v21mr8280022yhi.17.1333393632875; Mon,
	02 Apr 2012 12:07:12 -0700 (PDT)
Received: by 10.146.120.10 with HTTP; Mon, 2 Apr 2012 12:07:12 -0700 (PDT)
In-Reply-To: <20120322125957.GH37468@ocelot.phlegethon.org>
References: <20120322125957.GH37468@ocelot.phlegethon.org>
Date: Mon, 2 Apr 2012 12:07:12 -0700
Message-ID: <CAFe8ug8-zvDKUkc5aFkEakh=obcf_ZM1aVRyf0v4+uiHNo1Dqg@mail.gmail.com>
From: Jordan Justen <jljusten@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Build failure in OVMF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Mar 22, 2012 at 05:59, Tim Deegan <tim@xen.org> wrote:
> Hi,
>
> On my x64 debian build box, after
> =A0make distclean
> =A0hg purge --all
> =A0./configure
> =A0make -j8 deb
>
> the build eventually fails with this:
>
>> FV Space Information
>> MAINFV [74%Full] 5242880 total, 3888168 used, 1354712 free
>> SECFV [86%Full] 81920 total, 70792 used, 11128 free
>> FVMAIN_COMPACT [74%Full] 966656 total, 719808 used, 246848 free
>> DXEFV [99%Full] 3670016 total, 3669544 used, 472 free
>> make[7]: Leaving directory
>> `/local/scratch/tdeegan/xen-unstable.hg/tools/firmware/ovmf-remote/Build=
/OvmfX64/DEBUG_GCC46'
>>
>> - Done -
>> Build end time: 12:46:06, Mar.22 2012
>> Build total time: 00:00:47
>>
>> cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
>> cp: cannot stat `Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd': No such file or =
directory

Looks like GCC46 was used during the build here, so DEBUG_GCC46 is the
output path, not DEBUG_GCC44.

-Jordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmb0-0002LE-Ft; Mon, 02 Apr 2012 19:07:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jljusten@gmail.com>) id 1SEmaz-0002KE-3G
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:17 +0000
Received: from [85.158.143.99:29723] by server-3.bemta-4.messagelabs.com id
	E9/9D-05853-4E8F97F4; Mon, 02 Apr 2012 19:07:16 +0000
X-Env-Sender: jljusten@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333393633!16746542!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25896 invoked from network); 2 Apr 2012 19:07:15 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 19:07:15 -0000
Received: by ggnp2 with SMTP id p2so1615703ggn.32
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 12:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=ZRbpn9wqZ6/c1ecicy4b1lRi3r7NVXzWGAkW+0kAANo=;
	b=ZpP5yAhtywuD2Qfu5qRzJ8tJaQpEi+yHUAuQGHaWWSIccRAFRo+wWroq79Vmr3haIw
	yfyPsNvSrKGBcyrE241lxuMlhd/22SOW6J65uZRJ1dMItNFjWtxuO9izzL+9UZPCWFQS
	Zxpf1Ld07pz/M1/9SB6FbZAq4allv8qwq1iJ+14PfCzHE4dEzJ3GBpvxhKxUKgbn0KQA
	U1fdvhVbMZsTw9RIuWHzyFy76YeD0huvlNqpZ7xxySSa55yFfMaoZ3i/nBkbSblWK975
	jn2jDqUoPBf0wE1r0sxK02K69+wTe6mo1NKPSp5JwQTJEqDzRSEpVRwnZogfuCXKPI9Y
	raHw==
MIME-Version: 1.0
Received: by 10.236.136.33 with SMTP id v21mr8280022yhi.17.1333393632875; Mon,
	02 Apr 2012 12:07:12 -0700 (PDT)
Received: by 10.146.120.10 with HTTP; Mon, 2 Apr 2012 12:07:12 -0700 (PDT)
In-Reply-To: <20120322125957.GH37468@ocelot.phlegethon.org>
References: <20120322125957.GH37468@ocelot.phlegethon.org>
Date: Mon, 2 Apr 2012 12:07:12 -0700
Message-ID: <CAFe8ug8-zvDKUkc5aFkEakh=obcf_ZM1aVRyf0v4+uiHNo1Dqg@mail.gmail.com>
From: Jordan Justen <jljusten@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Build failure in OVMF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Mar 22, 2012 at 05:59, Tim Deegan <tim@xen.org> wrote:
> Hi,
>
> On my x64 debian build box, after
> =A0make distclean
> =A0hg purge --all
> =A0./configure
> =A0make -j8 deb
>
> the build eventually fails with this:
>
>> FV Space Information
>> MAINFV [74%Full] 5242880 total, 3888168 used, 1354712 free
>> SECFV [86%Full] 81920 total, 70792 used, 11128 free
>> FVMAIN_COMPACT [74%Full] 966656 total, 719808 used, 246848 free
>> DXEFV [99%Full] 3670016 total, 3669544 used, 472 free
>> make[7]: Leaving directory
>> `/local/scratch/tdeegan/xen-unstable.hg/tools/firmware/ovmf-remote/Build=
/OvmfX64/DEBUG_GCC46'
>>
>> - Done -
>> Build end time: 12:46:06, Mar.22 2012
>> Build total time: 00:00:47
>>
>> cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
>> cp: cannot stat `Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd': No such file or =
directory

Looks like GCC46 was used during the build here, so DEBUG_GCC46 is the
output path, not DEBUG_GCC44.

-Jordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:08:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmbc-0002OR-TB; Mon, 02 Apr 2012 19:07:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SEmbb-0002OA-Bq
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:55 +0000
Received: from [85.158.139.83:63020] by server-4.bemta-5.messagelabs.com id
	3D/51-10788-A09F97F4; Mon, 02 Apr 2012 19:07:54 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333393672!19421670!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0OTkw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30629 invoked from network); 2 Apr 2012 19:07:53 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-182.messagelabs.com with SMTP;
	2 Apr 2012 19:07:53 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id B5BA17EC063;
	Mon,  2 Apr 2012 12:07:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=Tb23ClguWW7lANCAsfuDyK
	iJWqz+/dD6om6OTQE31nny/lQ8+SronF2S+AU3N42qGdP9jwlFqEAC7ae5j/cu8q
	HtExgHq7l9KMnvBtMle+9tEER+DT0HPSKJH7UV9VMOZSVZdmp4gJe8UqwcftaSlo
	pTdyXC2kcgdCGViGFK/UA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=qYmnts6hA+X4
	tWIQQZ9SLW/BACU=; b=gTT2t0GzjErWhx2M5owkE9dIWPY8Wk/gTRshaE/ei1PN
	fyakDDX6k/A/9yWbXAmMtjzFqZ0lv1MSPOZYUDL8cPekHobWrmY3O1yU6Du6EP2G
	qDIr2NinGPKz5/g136GPizbMjMj7AXLh01xDtiKxQYdZUCHmbWiMHcON9b9ZSXc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 591617EC07B; 
	Mon,  2 Apr 2012 12:07:46 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 02 Apr 2012 15:11:02 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document the sharing libxc interface, including failure conditions, meaning of
stats, and internal semantics/behavior.

Also remove a stale debug call.

Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits. Both
patches touch the tools. Patch #2 is entirely documentation comments.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 tools/libxc/xc_memshr.c       |   14 --
 tools/libxc/xenctrl.h         |    3 -
 xen/arch/x86/mm/mem_sharing.c |   11 +-
 tools/libxc/xenctrl.h         |  201 +++++++++++++++++++++++++++++++++++++----
 4 files changed, 181 insertions(+), 48 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:08:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmbc-0002OR-TB; Mon, 02 Apr 2012 19:07:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SEmbb-0002OA-Bq
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:55 +0000
Received: from [85.158.139.83:63020] by server-4.bemta-5.messagelabs.com id
	3D/51-10788-A09F97F4; Mon, 02 Apr 2012 19:07:54 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333393672!19421670!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0OTkw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30629 invoked from network); 2 Apr 2012 19:07:53 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-182.messagelabs.com with SMTP;
	2 Apr 2012 19:07:53 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id B5BA17EC063;
	Mon,  2 Apr 2012 12:07:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=Tb23ClguWW7lANCAsfuDyK
	iJWqz+/dD6om6OTQE31nny/lQ8+SronF2S+AU3N42qGdP9jwlFqEAC7ae5j/cu8q
	HtExgHq7l9KMnvBtMle+9tEER+DT0HPSKJH7UV9VMOZSVZdmp4gJe8UqwcftaSlo
	pTdyXC2kcgdCGViGFK/UA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=qYmnts6hA+X4
	tWIQQZ9SLW/BACU=; b=gTT2t0GzjErWhx2M5owkE9dIWPY8Wk/gTRshaE/ei1PN
	fyakDDX6k/A/9yWbXAmMtjzFqZ0lv1MSPOZYUDL8cPekHobWrmY3O1yU6Du6EP2G
	qDIr2NinGPKz5/g136GPizbMjMj7AXLh01xDtiKxQYdZUCHmbWiMHcON9b9ZSXc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 591617EC07B; 
	Mon,  2 Apr 2012 12:07:46 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 02 Apr 2012 15:11:02 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document the sharing libxc interface, including failure conditions, meaning of
stats, and internal semantics/behavior.

Also remove a stale debug call.

Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits. Both
patches touch the tools. Patch #2 is entirely documentation comments.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 tools/libxc/xc_memshr.c       |   14 --
 tools/libxc/xenctrl.h         |    3 -
 xen/arch/x86/mm/mem_sharing.c |   11 +-
 tools/libxc/xenctrl.h         |  201 +++++++++++++++++++++++++++++++++++++----
 4 files changed, 181 insertions(+), 48 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmbf-0002PB-Py; Mon, 02 Apr 2012 19:07:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SEmbe-0002O7-C8
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:58 +0000
Received: from [85.158.143.99:31594] by server-1.bemta-4.messagelabs.com id
	55/5A-20925-E09F97F4; Mon, 02 Apr 2012 19:07:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333393675!16712415!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU3NzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10010 invoked from network); 2 Apr 2012 19:07:56 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-216.messagelabs.com with SMTP;
	2 Apr 2012 19:07:56 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id A0EDE7EC07A;
	Mon,  2 Apr 2012 12:07:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=F2q4zN5LjDmibU6Ut8wicDVp4OHD+M8/h0riOkpTcRti
	HLdZs46HLOQlyy1UzjS/goyaOPGd0Thls21LoMaEH82ra8i93MxW/aV9AOC3gqPo
	v2q+5AozgzbQN+7f9jP1LnEu7tQ23cenwpUqDek0KZdjLDKOmjIvKu11UAvc8IM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=K1q4u0VjH1YP1VOyF6dB9l+0UAo=; b=dleDz+qJYyx
	TOoBADXMxW+b5WvVyuMuvxIt5Yj4V10ZzizMOM41oKmbA/0N1xnrm9pJnugCsgFe
	BJwMqfzWC7T+vr3DLSPtvHGyehBh2RkeZyfzf83EMrHJ8Nurhph/OBmHrvEAJ02P
	YcKUKUa1KJ+bBAuEpC6ADPujrQ+i7fV4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1770B7EC065; 
	Mon,  2 Apr 2012 12:07:47 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f110cf1372a8948512311088222cb5f3e64a33f8
Message-Id: <f110cf1372a894851231.1333393863@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1333393862@xdev.gridcentric.ca>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 02 Apr 2012 15:11:03 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mem_sharing: Clean up debugging calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_memshr.c       |  14 --------------
 tools/libxc/xenctrl.h         |   3 ---
 xen/arch/x86/mm/mem_sharing.c |  11 ++---------
 3 files changed, 2 insertions(+), 26 deletions(-)


- Remove debug_mfn from the user-space interface
- Clean up errno codes

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9f585ddcbe0c -r f110cf1372a8 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -208,20 +208,6 @@ int xc_memshr_debug_gfn(xc_interface *xc
     return xc_memshr_memop(xch, domid, &mso);
 }
 
-int xc_memshr_debug_mfn(xc_interface *xch,
-                        domid_t domid,
-                        unsigned long mfn)
-{
-    xen_mem_sharing_op_t mso;
-
-    memset(&mso, 0, sizeof(mso));
-
-    mso.op = XENMEM_sharing_op_debug_mfn;
-    mso.u.debug.u.mfn = mfn; 
-
-    return xc_memshr_memop(xch, domid, &mso);
-}
-
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
diff -r 9f585ddcbe0c -r f110cf1372a8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1960,9 +1960,6 @@ int xc_memshr_domain_resume(xc_interface
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn);
-int xc_memshr_debug_mfn(xc_interface *xch,
-                        domid_t domid,
-                        unsigned long mfn);
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
diff -r 9f585ddcbe0c -r f110cf1372a8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -512,7 +512,7 @@ int mem_sharing_debug_mfn(mfn_t mfn)
     if ( (page = __grab_shared_page(mfn)) == NULL)
     {
         gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn_x(mfn));
-        return -1;
+        return -EINVAL;
     }
 
     MEM_SHARING_DEBUG( 
@@ -599,7 +599,7 @@ int mem_sharing_debug_gref(struct domain
         MEM_SHARING_DEBUG( 
                 "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
                 d->domain_id, ref);
-        return -1;
+        return -EINVAL;
     }
     (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
     shah = shared_entry_header(d->grant_table, ref);
@@ -1216,13 +1216,6 @@ int mem_sharing_memop(struct domain *d, 
         }
         break;
 
-        case XENMEM_sharing_op_debug_mfn:
-        {
-            unsigned long mfn = mec->u.debug.u.mfn;
-            rc = mem_sharing_debug_mfn(_mfn(mfn));
-        }
-        break;
-
         case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmbf-0002PB-Py; Mon, 02 Apr 2012 19:07:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SEmbe-0002O7-C8
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:58 +0000
Received: from [85.158.143.99:31594] by server-1.bemta-4.messagelabs.com id
	55/5A-20925-E09F97F4; Mon, 02 Apr 2012 19:07:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333393675!16712415!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU3NzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10010 invoked from network); 2 Apr 2012 19:07:56 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-216.messagelabs.com with SMTP;
	2 Apr 2012 19:07:56 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id A0EDE7EC07A;
	Mon,  2 Apr 2012 12:07:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=F2q4zN5LjDmibU6Ut8wicDVp4OHD+M8/h0riOkpTcRti
	HLdZs46HLOQlyy1UzjS/goyaOPGd0Thls21LoMaEH82ra8i93MxW/aV9AOC3gqPo
	v2q+5AozgzbQN+7f9jP1LnEu7tQ23cenwpUqDek0KZdjLDKOmjIvKu11UAvc8IM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=K1q4u0VjH1YP1VOyF6dB9l+0UAo=; b=dleDz+qJYyx
	TOoBADXMxW+b5WvVyuMuvxIt5Yj4V10ZzizMOM41oKmbA/0N1xnrm9pJnugCsgFe
	BJwMqfzWC7T+vr3DLSPtvHGyehBh2RkeZyfzf83EMrHJ8Nurhph/OBmHrvEAJ02P
	YcKUKUa1KJ+bBAuEpC6ADPujrQ+i7fV4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1770B7EC065; 
	Mon,  2 Apr 2012 12:07:47 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f110cf1372a8948512311088222cb5f3e64a33f8
Message-Id: <f110cf1372a894851231.1333393863@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1333393862@xdev.gridcentric.ca>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 02 Apr 2012 15:11:03 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mem_sharing: Clean up debugging calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_memshr.c       |  14 --------------
 tools/libxc/xenctrl.h         |   3 ---
 xen/arch/x86/mm/mem_sharing.c |  11 ++---------
 3 files changed, 2 insertions(+), 26 deletions(-)


- Remove debug_mfn from the user-space interface
- Clean up errno codes

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9f585ddcbe0c -r f110cf1372a8 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -208,20 +208,6 @@ int xc_memshr_debug_gfn(xc_interface *xc
     return xc_memshr_memop(xch, domid, &mso);
 }
 
-int xc_memshr_debug_mfn(xc_interface *xch,
-                        domid_t domid,
-                        unsigned long mfn)
-{
-    xen_mem_sharing_op_t mso;
-
-    memset(&mso, 0, sizeof(mso));
-
-    mso.op = XENMEM_sharing_op_debug_mfn;
-    mso.u.debug.u.mfn = mfn; 
-
-    return xc_memshr_memop(xch, domid, &mso);
-}
-
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
diff -r 9f585ddcbe0c -r f110cf1372a8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1960,9 +1960,6 @@ int xc_memshr_domain_resume(xc_interface
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn);
-int xc_memshr_debug_mfn(xc_interface *xch,
-                        domid_t domid,
-                        unsigned long mfn);
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
diff -r 9f585ddcbe0c -r f110cf1372a8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -512,7 +512,7 @@ int mem_sharing_debug_mfn(mfn_t mfn)
     if ( (page = __grab_shared_page(mfn)) == NULL)
     {
         gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn_x(mfn));
-        return -1;
+        return -EINVAL;
     }
 
     MEM_SHARING_DEBUG( 
@@ -599,7 +599,7 @@ int mem_sharing_debug_gref(struct domain
         MEM_SHARING_DEBUG( 
                 "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
                 d->domain_id, ref);
-        return -1;
+        return -EINVAL;
     }
     (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
     shah = shared_entry_header(d->grant_table, ref);
@@ -1216,13 +1216,6 @@ int mem_sharing_memop(struct domain *d, 
         }
         break;
 
-        case XENMEM_sharing_op_debug_mfn:
-        {
-            unsigned long mfn = mec->u.debug.u.mfn;
-            rc = mem_sharing_debug_mfn(_mfn(mfn));
-        }
-        break;
-
         case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmbd-0002OZ-8a; Mon, 02 Apr 2012 19:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SEmbb-0002O7-5T
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:56 +0000
Received: from [85.158.143.35:56442] by server-1.bemta-4.messagelabs.com id
	87/4A-20925-A09F97F4; Mon, 02 Apr 2012 19:07:54 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333393672!10654588!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjE4MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17933 invoked from network); 2 Apr 2012 19:07:53 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-10.tower-21.messagelabs.com with SMTP;
	2 Apr 2012 19:07:53 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 981B77EC07B;
	Mon,  2 Apr 2012 12:07:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CV3T+D2jgSbYBYiViq/nO767iJRDYxGR6DKr/2HQEz1Z
	G6+p5B9Tu30Dx1B+CaUojHKXdPSfMrPIoIev7BCPpny5Z5B2kQYWQbAZNOSDVtEW
	nhNjyHm+jT8Czb/MaJTRvfaDGEEwLrC0+3WhoAqvJVeilwPHflbZWrSxRvIH4XY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=St/JNho3Z0ridADqWVX8iuiancg=; b=tqVuICIAdCZ
	UNah524K7p9Xos62BVgM5ReiY7xpzPwda0kUPZUi++4GADxyVaScRueO+ZQIRUnf
	TX1aAWYzb7lGJ7zS9Xxi17HBNrCJnv9fW3w0ybtYK26IRo5/NLrkvet4kL0Jdfux
	crk2PdcgXatbOyhsyu0N0Gn+6wzDbQrs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 0589D7EC065; 
	Mon,  2 Apr 2012 12:07:49 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 3f6b49097dced570f2ded4651828c76e0524a28d
Message-Id: <3f6b49097dced570f2de.1333393864@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1333393862@xdev.gridcentric.ca>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 02 Apr 2012 15:11:04 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Document the sharing interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xenctrl.h |  201 ++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 179 insertions(+), 22 deletions(-)


(also make note about AMD support's experimental status)

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r f110cf1372a8 -r 3f6b49097dce tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1251,23 +1251,6 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
-/**
- * This function returns the total number of pages freed by using sharing
- * on the system.  For example, if two domains contain a single entry in
- * their p2m map that points to the same shared page (and no other pages
- * in the system are shared), then this function should return 1.
- */
-long xc_sharing_freed_pages(xc_interface *xch);
-
-/**
- * This function returns the total number of frames occupied by shared
- * pages on the system.  This is independent of the number of domains
- * pointing at these frames.  For example, in the above scenario this
- * should return 1. The following should hold:
- *  memory usage without sharing = freed_pages + used_frames
- */
-long xc_sharing_used_frames(xc_interface *xch);
-
 /* Get current total pages allocated to a domain. */
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
 
@@ -1894,7 +1877,7 @@ int xc_tmem_restore(xc_interface *xch, i
 int xc_tmem_restore_extra(xc_interface *xch, int dom, int fd);
 
 /**
- * mem_event operations
+ * mem_event operations. Internal use only.
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
                          unsigned int mode, uint32_t *port);
@@ -1902,6 +1885,12 @@ int xc_mem_event_memop(xc_interface *xch
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
+/** 
+ * Mem paging operations.
+ * Paging is supported only on the x86 architecture in 64 bit mode, with
+ * Hardware-Assisted Paging (i.e. Intel EPT, AMD NPT). Moreover, AMD NPT
+ * support is considered experimental.
+ */
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
@@ -1911,30 +1900,133 @@ int xc_mem_paging_prep(xc_interface *xch
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                         unsigned long gfn, void *buffer);
 
+/** 
+ * Access tracking operations.
+ * Supported only on Intel EPT 64 bit processors.
+ */
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 
-/**
- * memshr operations
+/***
+ * Memory sharing operations.
+ *
+ * Unles otherwise noted, these calls return 0 on succes, -1 and errno on
+ * failure.
+ *
+ * Sharing is supported only on the x86 architecture in 64 bit mode, with
+ * Hardware-Assisted Paging (i.e. Intel EPT, AMD NPT). Moreover, AMD NPT
+ * support is considered experimental. 
+
+ * Calls below return ENOSYS if not in the x86_64 architecture.
+ * Calls below return ENODEV if the domain does not support HAP.
+ * Calls below return ESRCH if the specified domain does not exist.
+ * Calls below return EPERM if the caller is unprivileged for this domain.
  */
+
+/* Turn on/off sharing for the domid, depending on the enable flag.
+ *
+ * Returns EXDEV if trying to enable and the domain has had a PCI device
+ * assigned for passthrough (these two features are mutually exclusive).
+ *
+ * When sharing for a domain is turned off, the domain may still reference
+ * shared pages. Unsharing happens lazily. */
 int xc_memshr_control(xc_interface *xch,
                       domid_t domid,
                       int enable);
+
+/* Create a communication ring in which the hypervisor will place ENOMEM
+ * notifications.
+ *
+ * ENOMEM happens when unsharing pages: a Copy-on-Write duplicate needs to be
+ * allocated, and thus the out-of-memory error occurr.
+ *
+ * For complete examples on how to plumb a notification ring, look into
+ * xenpaging or xen-access.
+ *
+ * On receipt of a notification, the helper should ensure there is memory
+ * available to the domain before retrying.
+ *
+ * If a domain encounters an ENOMEM condition when sharing and this ring
+ * has not been set up, the hypervisor will crash the domain.
+ *
+ * Fails with:
+ *  EINVAL if port is NULL
+ *  EINVAL if the sharing ring has already been enabled
+ *  ENOSYS if no guest gfn has been specified to host the ring via an hvm param
+ *  EINVAL if the gfn for the ring has not been populated
+ *  ENOENT if the gfn for the ring is paged out, or cannot be unshared
+ *  EINVAL if the gfn for the ring cannot be written to
+ *  EINVAL if the domain is dying
+ *  ENOSPC if an event channel cannot be allocated for the ring
+ *  ENOMEM if memory cannot be allocated for internal data structures
+ *  EINVAL or EACCESS if the request is denied by the security policy
+ */
+
 int xc_memshr_ring_enable(xc_interface *xch, 
                           domid_t domid, 
                           uint32_t *port);
+/* Disable the ring for ENOMEM communication.
+ * May fail with EINVAL if the ring was not enabled in the first place.
+ */
 int xc_memshr_ring_disable(xc_interface *xch, 
                            domid_t domid);
+
+/*
+ * Calls below return EINVAL if sharing has not been enabled for the domain
+ * Calls below return EINVAL if the domain is dying
+ */
+/* Once a reponse to an ENOMEM notification is prepared, the tool can
+ * notify the hypervisor to re-schedule the faulting vcpu of the domain with an
+ * event channel kick and/or this call. */
+int xc_memshr_domain_resume(xc_interface *xch,
+                            domid_t domid);
+
+/* Select a page for sharing. 
+ *
+ * A 64 bit opaque handle will be stored in handle.  The hypervisor ensures
+ * that if the page is modified, the handle will be invalidated, and future
+ * users of it will fail. If the page has already been selected and is still
+ * associated to a valid handle, the existing handle will be returned.
+ *
+ * May fail with:
+ *  EINVAL if the gfn is not populated or not sharable (mmio, etc)
+ *  ENOMEM if internal data structures cannot be allocated
+ *  E2BIG if the page is being referenced by other subsytems (e.g. qemu)
+ *  ENOENT or EEXIST if there are internal hypervisor errors.
+ */
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle);
+/* Same as above, but instead of a guest frame number, the input is a grant
+ * reference provided by the guest.
+ *
+ * May fail with EINVAL if the grant reference is invalid.
+ */
 int xc_memshr_nominate_gref(xc_interface *xch,
                             domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
+
+/* The three calls below may fail with
+ * 10 (or -XENMEM_SHARING_OP_S_HANDLE_INVALID) if the handle passed as source
+ * is invalid.  
+ * 9 (or -XENMEM_SHARING_OP_C_HANDLE_INVALID) if the handle passed as client is
+ * invalid.
+ */
+/* Share two nominated guest pages.
+ *
+ * If the call succeeds, both pages will point to the same backing frame (or
+ * mfn). The hypervisor will verify the handles are still valid, but it will
+ * not perform any sanity checking on the contens of the pages (the selection
+ * mechanism for sharing candidates is entirely up to the user-space tool).
+ *
+ * After successful sharing, the client handle becomes invalid. Both <domain,
+ * gfn> tuples point to the same mfn with the same handle, the one specified as
+ * source. Either 3-tuple can be specified later for further re-sharing. 
+ */
 int xc_memshr_share_gfns(xc_interface *xch,
                     domid_t source_domain,
                     unsigned long source_gfn,
@@ -1942,6 +2034,11 @@ int xc_memshr_share_gfns(xc_interface *x
                     domid_t client_domain,
                     unsigned long client_gfn,
                     uint64_t client_handle);
+
+/* Same as above, but share two grant references instead.
+ *
+ * May fail with EINVAL if either grant reference is invalid.
+ */
 int xc_memshr_share_grefs(xc_interface *xch,
                     domid_t source_domain,
                     grant_ref_t source_gref,
@@ -1949,22 +2046,82 @@ int xc_memshr_share_grefs(xc_interface *
                     domid_t client_domain,
                     grant_ref_t client_gref,
                     uint64_t client_handle);
+
+/* Allows to add to the guest physmap of the client domain a shared frame
+ * directly.
+ *
+ * May additionally fail with 
+ *  9 (-XENMEM_SHARING_OP_C_HANDLE_INVALID) if the physmap entry for the gfn is
+ *  not suitable.
+ *  ENOMEM if internal data structures cannot be allocated.
+ *  ENOENT if there is an internal hypervisor error.
+ */
 int xc_memshr_add_to_physmap(xc_interface *xch,
                     domid_t source_domain,
                     unsigned long source_gfn,
                     uint64_t source_handle,
                     domid_t client_domain,
                     unsigned long client_gfn);
-int xc_memshr_domain_resume(xc_interface *xch,
-                            domid_t domid);
+
+/* Debug calls: return the number of pages referencing the shared frame backing
+ * the input argument. Should be one or greater. 
+ *
+ * May fail with EINVAL if there is no backing shared frame for the input
+ * argument.
+ */
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn);
+/* May additionally fail with EINVAL if the grant reference is invalid. */
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+
+/* Audits the share subsystem. 
+ * 
+ * Returns ENOSYS if not supported (may not be compiled into the hypervisor). 
+ *
+ * Returns the number of errors found during auditing otherwise. May be (should
+ * be!) zero.
+ *
+ * If debugtrace support has been compiled into the hypervisor and is enabled,
+ * verbose descriptions for the errors are available in the hypervisor console.
+ */
 int xc_memshr_audit(xc_interface *xch);
 
+/* Stats reporting.
+ *
+ * At any point in time, the following equality should hold for a host:
+ *
+ *  Let dominfo(d) be the xc_dominfo_t struct filled by a call to
+ *  xc_domain_getinfo(d)
+ *
+ *  The summation of dominfo(d)->shr_pages for all domains in the system
+ *      should be equal to
+ *  xc_sharing_freed_pages + xc_sharing_used_frames
+ */
+/*
+ * This function returns the total number of pages freed by using sharing
+ * on the system.  For example, if two domains contain a single entry in
+ * their p2m table that points to the same shared page (and no other pages
+ * in the system are shared), then this function should return 1.
+ */
+long xc_sharing_freed_pages(xc_interface *xch);
+
+/*
+ * This function returns the total number of frames occupied by shared
+ * pages on the system.  This is independent of the number of domains
+ * pointing at these frames.  For example, in the above scenario this
+ * should return 1. (And dominfo(d) for each of the two domains should return 1
+ * as well).
+ *
+ * Note that some of these sharing_used_frames may be referenced by 
+ * a single domain page, and thus not realize any savings. The same
+ * applies to some of the pages counted in dominfo(d)->shr_pages.
+ */
+long xc_sharing_used_frames(xc_interface *xch);
+/*** End sharing interface ***/
+
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
 int xc_flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEmbd-0002OZ-8a; Mon, 02 Apr 2012 19:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SEmbb-0002O7-5T
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 19:07:56 +0000
Received: from [85.158.143.35:56442] by server-1.bemta-4.messagelabs.com id
	87/4A-20925-A09F97F4; Mon, 02 Apr 2012 19:07:54 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333393672!10654588!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjE4MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17933 invoked from network); 2 Apr 2012 19:07:53 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-10.tower-21.messagelabs.com with SMTP;
	2 Apr 2012 19:07:53 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 981B77EC07B;
	Mon,  2 Apr 2012 12:07:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CV3T+D2jgSbYBYiViq/nO767iJRDYxGR6DKr/2HQEz1Z
	G6+p5B9Tu30Dx1B+CaUojHKXdPSfMrPIoIev7BCPpny5Z5B2kQYWQbAZNOSDVtEW
	nhNjyHm+jT8Czb/MaJTRvfaDGEEwLrC0+3WhoAqvJVeilwPHflbZWrSxRvIH4XY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=St/JNho3Z0ridADqWVX8iuiancg=; b=tqVuICIAdCZ
	UNah524K7p9Xos62BVgM5ReiY7xpzPwda0kUPZUi++4GADxyVaScRueO+ZQIRUnf
	TX1aAWYzb7lGJ7zS9Xxi17HBNrCJnv9fW3w0ybtYK26IRo5/NLrkvet4kL0Jdfux
	crk2PdcgXatbOyhsyu0N0Gn+6wzDbQrs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 0589D7EC065; 
	Mon,  2 Apr 2012 12:07:49 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 3f6b49097dced570f2ded4651828c76e0524a28d
Message-Id: <3f6b49097dced570f2de.1333393864@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1333393862@xdev.gridcentric.ca>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 02 Apr 2012 15:11:04 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Document the sharing interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xenctrl.h |  201 ++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 179 insertions(+), 22 deletions(-)


(also make note about AMD support's experimental status)

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r f110cf1372a8 -r 3f6b49097dce tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1251,23 +1251,6 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
-/**
- * This function returns the total number of pages freed by using sharing
- * on the system.  For example, if two domains contain a single entry in
- * their p2m map that points to the same shared page (and no other pages
- * in the system are shared), then this function should return 1.
- */
-long xc_sharing_freed_pages(xc_interface *xch);
-
-/**
- * This function returns the total number of frames occupied by shared
- * pages on the system.  This is independent of the number of domains
- * pointing at these frames.  For example, in the above scenario this
- * should return 1. The following should hold:
- *  memory usage without sharing = freed_pages + used_frames
- */
-long xc_sharing_used_frames(xc_interface *xch);
-
 /* Get current total pages allocated to a domain. */
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
 
@@ -1894,7 +1877,7 @@ int xc_tmem_restore(xc_interface *xch, i
 int xc_tmem_restore_extra(xc_interface *xch, int dom, int fd);
 
 /**
- * mem_event operations
+ * mem_event operations. Internal use only.
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
                          unsigned int mode, uint32_t *port);
@@ -1902,6 +1885,12 @@ int xc_mem_event_memop(xc_interface *xch
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
+/** 
+ * Mem paging operations.
+ * Paging is supported only on the x86 architecture in 64 bit mode, with
+ * Hardware-Assisted Paging (i.e. Intel EPT, AMD NPT). Moreover, AMD NPT
+ * support is considered experimental.
+ */
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
@@ -1911,30 +1900,133 @@ int xc_mem_paging_prep(xc_interface *xch
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                         unsigned long gfn, void *buffer);
 
+/** 
+ * Access tracking operations.
+ * Supported only on Intel EPT 64 bit processors.
+ */
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 
-/**
- * memshr operations
+/***
+ * Memory sharing operations.
+ *
+ * Unles otherwise noted, these calls return 0 on succes, -1 and errno on
+ * failure.
+ *
+ * Sharing is supported only on the x86 architecture in 64 bit mode, with
+ * Hardware-Assisted Paging (i.e. Intel EPT, AMD NPT). Moreover, AMD NPT
+ * support is considered experimental. 
+
+ * Calls below return ENOSYS if not in the x86_64 architecture.
+ * Calls below return ENODEV if the domain does not support HAP.
+ * Calls below return ESRCH if the specified domain does not exist.
+ * Calls below return EPERM if the caller is unprivileged for this domain.
  */
+
+/* Turn on/off sharing for the domid, depending on the enable flag.
+ *
+ * Returns EXDEV if trying to enable and the domain has had a PCI device
+ * assigned for passthrough (these two features are mutually exclusive).
+ *
+ * When sharing for a domain is turned off, the domain may still reference
+ * shared pages. Unsharing happens lazily. */
 int xc_memshr_control(xc_interface *xch,
                       domid_t domid,
                       int enable);
+
+/* Create a communication ring in which the hypervisor will place ENOMEM
+ * notifications.
+ *
+ * ENOMEM happens when unsharing pages: a Copy-on-Write duplicate needs to be
+ * allocated, and thus the out-of-memory error occurr.
+ *
+ * For complete examples on how to plumb a notification ring, look into
+ * xenpaging or xen-access.
+ *
+ * On receipt of a notification, the helper should ensure there is memory
+ * available to the domain before retrying.
+ *
+ * If a domain encounters an ENOMEM condition when sharing and this ring
+ * has not been set up, the hypervisor will crash the domain.
+ *
+ * Fails with:
+ *  EINVAL if port is NULL
+ *  EINVAL if the sharing ring has already been enabled
+ *  ENOSYS if no guest gfn has been specified to host the ring via an hvm param
+ *  EINVAL if the gfn for the ring has not been populated
+ *  ENOENT if the gfn for the ring is paged out, or cannot be unshared
+ *  EINVAL if the gfn for the ring cannot be written to
+ *  EINVAL if the domain is dying
+ *  ENOSPC if an event channel cannot be allocated for the ring
+ *  ENOMEM if memory cannot be allocated for internal data structures
+ *  EINVAL or EACCESS if the request is denied by the security policy
+ */
+
 int xc_memshr_ring_enable(xc_interface *xch, 
                           domid_t domid, 
                           uint32_t *port);
+/* Disable the ring for ENOMEM communication.
+ * May fail with EINVAL if the ring was not enabled in the first place.
+ */
 int xc_memshr_ring_disable(xc_interface *xch, 
                            domid_t domid);
+
+/*
+ * Calls below return EINVAL if sharing has not been enabled for the domain
+ * Calls below return EINVAL if the domain is dying
+ */
+/* Once a reponse to an ENOMEM notification is prepared, the tool can
+ * notify the hypervisor to re-schedule the faulting vcpu of the domain with an
+ * event channel kick and/or this call. */
+int xc_memshr_domain_resume(xc_interface *xch,
+                            domid_t domid);
+
+/* Select a page for sharing. 
+ *
+ * A 64 bit opaque handle will be stored in handle.  The hypervisor ensures
+ * that if the page is modified, the handle will be invalidated, and future
+ * users of it will fail. If the page has already been selected and is still
+ * associated to a valid handle, the existing handle will be returned.
+ *
+ * May fail with:
+ *  EINVAL if the gfn is not populated or not sharable (mmio, etc)
+ *  ENOMEM if internal data structures cannot be allocated
+ *  E2BIG if the page is being referenced by other subsytems (e.g. qemu)
+ *  ENOENT or EEXIST if there are internal hypervisor errors.
+ */
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle);
+/* Same as above, but instead of a guest frame number, the input is a grant
+ * reference provided by the guest.
+ *
+ * May fail with EINVAL if the grant reference is invalid.
+ */
 int xc_memshr_nominate_gref(xc_interface *xch,
                             domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
+
+/* The three calls below may fail with
+ * 10 (or -XENMEM_SHARING_OP_S_HANDLE_INVALID) if the handle passed as source
+ * is invalid.  
+ * 9 (or -XENMEM_SHARING_OP_C_HANDLE_INVALID) if the handle passed as client is
+ * invalid.
+ */
+/* Share two nominated guest pages.
+ *
+ * If the call succeeds, both pages will point to the same backing frame (or
+ * mfn). The hypervisor will verify the handles are still valid, but it will
+ * not perform any sanity checking on the contens of the pages (the selection
+ * mechanism for sharing candidates is entirely up to the user-space tool).
+ *
+ * After successful sharing, the client handle becomes invalid. Both <domain,
+ * gfn> tuples point to the same mfn with the same handle, the one specified as
+ * source. Either 3-tuple can be specified later for further re-sharing. 
+ */
 int xc_memshr_share_gfns(xc_interface *xch,
                     domid_t source_domain,
                     unsigned long source_gfn,
@@ -1942,6 +2034,11 @@ int xc_memshr_share_gfns(xc_interface *x
                     domid_t client_domain,
                     unsigned long client_gfn,
                     uint64_t client_handle);
+
+/* Same as above, but share two grant references instead.
+ *
+ * May fail with EINVAL if either grant reference is invalid.
+ */
 int xc_memshr_share_grefs(xc_interface *xch,
                     domid_t source_domain,
                     grant_ref_t source_gref,
@@ -1949,22 +2046,82 @@ int xc_memshr_share_grefs(xc_interface *
                     domid_t client_domain,
                     grant_ref_t client_gref,
                     uint64_t client_handle);
+
+/* Allows to add to the guest physmap of the client domain a shared frame
+ * directly.
+ *
+ * May additionally fail with 
+ *  9 (-XENMEM_SHARING_OP_C_HANDLE_INVALID) if the physmap entry for the gfn is
+ *  not suitable.
+ *  ENOMEM if internal data structures cannot be allocated.
+ *  ENOENT if there is an internal hypervisor error.
+ */
 int xc_memshr_add_to_physmap(xc_interface *xch,
                     domid_t source_domain,
                     unsigned long source_gfn,
                     uint64_t source_handle,
                     domid_t client_domain,
                     unsigned long client_gfn);
-int xc_memshr_domain_resume(xc_interface *xch,
-                            domid_t domid);
+
+/* Debug calls: return the number of pages referencing the shared frame backing
+ * the input argument. Should be one or greater. 
+ *
+ * May fail with EINVAL if there is no backing shared frame for the input
+ * argument.
+ */
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn);
+/* May additionally fail with EINVAL if the grant reference is invalid. */
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+
+/* Audits the share subsystem. 
+ * 
+ * Returns ENOSYS if not supported (may not be compiled into the hypervisor). 
+ *
+ * Returns the number of errors found during auditing otherwise. May be (should
+ * be!) zero.
+ *
+ * If debugtrace support has been compiled into the hypervisor and is enabled,
+ * verbose descriptions for the errors are available in the hypervisor console.
+ */
 int xc_memshr_audit(xc_interface *xch);
 
+/* Stats reporting.
+ *
+ * At any point in time, the following equality should hold for a host:
+ *
+ *  Let dominfo(d) be the xc_dominfo_t struct filled by a call to
+ *  xc_domain_getinfo(d)
+ *
+ *  The summation of dominfo(d)->shr_pages for all domains in the system
+ *      should be equal to
+ *  xc_sharing_freed_pages + xc_sharing_used_frames
+ */
+/*
+ * This function returns the total number of pages freed by using sharing
+ * on the system.  For example, if two domains contain a single entry in
+ * their p2m table that points to the same shared page (and no other pages
+ * in the system are shared), then this function should return 1.
+ */
+long xc_sharing_freed_pages(xc_interface *xch);
+
+/*
+ * This function returns the total number of frames occupied by shared
+ * pages on the system.  This is independent of the number of domains
+ * pointing at these frames.  For example, in the above scenario this
+ * should return 1. (And dominfo(d) for each of the two domains should return 1
+ * as well).
+ *
+ * Note that some of these sharing_used_frames may be referenced by 
+ * a single domain page, and thus not realize any savings. The same
+ * applies to some of the pages counted in dominfo(d)->shr_pages.
+ */
+long xc_sharing_used_frames(xc_interface *xch);
+/*** End sharing interface ***/
+
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
 int xc_flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:54:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnKg-0004Qk-2u; Mon, 02 Apr 2012 19:54:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnKe-0004Qc-Kg
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 19:54:28 +0000
Received: from [85.158.143.99:39803] by server-3.bemta-4.messagelabs.com id
	AE/5C-05853-3F30A7F4; Mon, 02 Apr 2012 19:54:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333396466!22012761!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20881 invoked from network); 2 Apr 2012 19:54:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 19:54:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333396466; l=1153;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=0mHtXGgxWiny2iVBI5kFr3ggg2o=;
	b=JNpOVq4wobesNDQ626a2ROm1+/jMS/n0/vfzPJ5GdyVWWaP361OkGrLnT468xb9MUbB
	uwXWRy6snGN2QYfBb7pnyCum07TmnF3F6Kt6hJvSXDrqCYW6E/CoBlWL02aon7RMIX4XN
	ndzeFdMrJW2rQss+pj8aOhfV3PnIrb7UNpA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo8) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f006b8o32IEa6s ;
	Mon, 2 Apr 2012 21:54:26 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 9BE5218637; Mon,  2 Apr 2012 21:54:25 +0200 (CEST)
Date: Mon, 2 Apr 2012 21:54:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402195425.GA21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.45252.747454.411523@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > node-select.c: In function 'vchan_wr':
> > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> 
> This one is a question of coding style.  Apparently libvchan uses
> mixed statements/declarations, so this should be fixed by changing the
> warning flags.

This is from xen itself:

.. -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement ..

Are you saying -Wdeclaration-after-statement should be removed?

diff -r 7c29b8723556 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -161,7 +161,7 @@ CFLAGS += -Wall -Wstrict-prototypes
 # and is over-zealous with the printf format lint
 CFLAGS-$(clang) += -Wno-parentheses -Wno-format
 
-$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
+$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wno-declaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:54:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnKg-0004Qk-2u; Mon, 02 Apr 2012 19:54:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnKe-0004Qc-Kg
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 19:54:28 +0000
Received: from [85.158.143.99:39803] by server-3.bemta-4.messagelabs.com id
	AE/5C-05853-3F30A7F4; Mon, 02 Apr 2012 19:54:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333396466!22012761!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20881 invoked from network); 2 Apr 2012 19:54:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 19:54:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333396466; l=1153;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=0mHtXGgxWiny2iVBI5kFr3ggg2o=;
	b=JNpOVq4wobesNDQ626a2ROm1+/jMS/n0/vfzPJ5GdyVWWaP361OkGrLnT468xb9MUbB
	uwXWRy6snGN2QYfBb7pnyCum07TmnF3F6Kt6hJvSXDrqCYW6E/CoBlWL02aon7RMIX4XN
	ndzeFdMrJW2rQss+pj8aOhfV3PnIrb7UNpA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo8) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f006b8o32IEa6s ;
	Mon, 2 Apr 2012 21:54:26 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 9BE5218637; Mon,  2 Apr 2012 21:54:25 +0200 (CEST)
Date: Mon, 2 Apr 2012 21:54:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402195425.GA21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.45252.747454.411523@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > node-select.c: In function 'vchan_wr':
> > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> 
> This one is a question of coding style.  Apparently libvchan uses
> mixed statements/declarations, so this should be fixed by changing the
> warning flags.

This is from xen itself:

.. -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement ..

Are you saying -Wdeclaration-after-statement should be removed?

diff -r 7c29b8723556 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -161,7 +161,7 @@ CFLAGS += -Wall -Wstrict-prototypes
 # and is over-zealous with the printf format lint
 CFLAGS-$(clang) += -Wno-parentheses -Wno-format
 
-$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
+$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wno-declaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:58:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnOO-0004ke-Bm; Mon, 02 Apr 2012 19:58:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnOM-0004kM-N9
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 19:58:19 +0000
Received: from [85.158.138.51:13335] by server-8.bemta-3.messagelabs.com id
	D5/F7-29305-9D40A7F4; Mon, 02 Apr 2012 19:58:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333396697!20461637!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 404 invoked from network); 2 Apr 2012 19:58:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 19:58:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333396697; l=710;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fcKfBB3N46ZzGhb5hTblrMod0I8=;
	b=MWksWZXz5mzUOMVn1lWa71RlYfrbP9ng/YNFXRFAB80rdpDZa6BwUOx7CAvEFiKDCTp
	vek5Spfza+9lzdZyFBIJdjs+ZatOS4UH8S9m+/jyoRthfZI4Im04gtEi/JJSGoKZPHA0X
	dSeLiW01fASrUJQFtKvzRvLI1eV3bkZMnV0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo20) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z06140o32IQi3A ;
	Mon, 2 Apr 2012 21:58:16 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 59C6D18637; Mon,  2 Apr 2012 21:58:16 +0200 (CEST)
Date: Mon, 2 Apr 2012 21:58:16 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402195816.GB21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.44861.163125.224414@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> > tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback
> > 
> > -O2 -Wall -Werror triggers these warnings:
> > 
> > libxl.c: In function 'disk_eject_xswatch_callback':
> > libxl.c:928: warning: zero-length printf format string
> 
> There is nothing wrong with zero-length format strings.  This warning
> should be disabled.  Please do send a patch to do so.

-Wno-format-zero-length -Wall has no effect, and -Wall comes from
RPM_OPT_FLAGS which will come last with my current EXTRA_CFLAGS patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 19:58:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 19:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnOO-0004ke-Bm; Mon, 02 Apr 2012 19:58:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnOM-0004kM-N9
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 19:58:19 +0000
Received: from [85.158.138.51:13335] by server-8.bemta-3.messagelabs.com id
	D5/F7-29305-9D40A7F4; Mon, 02 Apr 2012 19:58:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333396697!20461637!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 404 invoked from network); 2 Apr 2012 19:58:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 19:58:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333396697; l=710;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fcKfBB3N46ZzGhb5hTblrMod0I8=;
	b=MWksWZXz5mzUOMVn1lWa71RlYfrbP9ng/YNFXRFAB80rdpDZa6BwUOx7CAvEFiKDCTp
	vek5Spfza+9lzdZyFBIJdjs+ZatOS4UH8S9m+/jyoRthfZI4Im04gtEi/JJSGoKZPHA0X
	dSeLiW01fASrUJQFtKvzRvLI1eV3bkZMnV0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo20) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z06140o32IQi3A ;
	Mon, 2 Apr 2012 21:58:16 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 59C6D18637; Mon,  2 Apr 2012 21:58:16 +0200 (CEST)
Date: Mon, 2 Apr 2012 21:58:16 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120402195816.GB21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.44861.163125.224414@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 02, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> > tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback
> > 
> > -O2 -Wall -Werror triggers these warnings:
> > 
> > libxl.c: In function 'disk_eject_xswatch_callback':
> > libxl.c:928: warning: zero-length printf format string
> 
> There is nothing wrong with zero-length format strings.  This warning
> should be disabled.  Please do send a patch to do so.

-Wno-format-zero-length -Wall has no effect, and -Wall comes from
RPM_OPT_FLAGS which will come last with my current EXTRA_CFLAGS patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfc-0005gq-F5; Mon, 02 Apr 2012 20:16:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfY-0005dm-SB
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:05 +0000
Received: from [85.158.138.51:45590] by server-11.bemta-3.messagelabs.com id
	41/E7-12049-4090A7F4; Mon, 02 Apr 2012 20:16:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333397763!20414950!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25160 invoked from network); 2 Apr 2012 20:16:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1210;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=XTnXYGOpwmZMn7vZNwLO8KitSxc=;
	b=I8MIw3F2gfJnxl7Eyww95K/tRDl+WwtDrAKre6W+cOK3U49QQQU3IvzzCqGsiSFvgp5
	RYA1wQ2l98OmsKyohguWbLOfQw6LjvYSBr+kpqbMgEaM9AgobJpHjLSWBuksVcYplhugM
	qg69L4AXaL0Mx9L3JTG1m8AgOmFFL6LH/7A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (fruni mo45) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6070f6o32J4DhG ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3600F18638;
	Mon,  2 Apr 2012 22:16:02 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: a85817bc44e57a805afffc3e91d5bf7051a361e0
Message-Id: <a85817bc44e57a805aff.1333397740@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:40 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17 of 18] tools/blktap2: remove unused labels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397583 -7200
# Node ID a85817bc44e57a805afffc3e91d5bf7051a361e0
# Parent  71055bfdb14c72072d9b3fdf6b3c4973ae5b8a20
tools/blktap2: remove unused labels

vhd-util-read.c:478:2: warning: label 'print' defined but not used [-Wunused-label]
vhd-util-set-field.c:99:2: warning: label 'done' defined but not used [-Wunused-label]

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 71055bfdb14c -r a85817bc44e5 tools/blktap2/vhd/lib/vhd-util-read.c
--- a/tools/blktap2/vhd/lib/vhd-util-read.c
+++ b/tools/blktap2/vhd/lib/vhd-util-read.c
@@ -475,7 +475,6 @@ vhd_test_bitmap(vhd_context_t *vhd, uint
 		else
 			bit = vhd_bitmap_test(vhd, buf, blk);
 
-	print:
 		printf("block %s: ", conv(hex, blk));
 		printf("sec: %s: %d\n", conv(hex, sec), bit);
 	}
diff -r 71055bfdb14c -r a85817bc44e5 tools/blktap2/vhd/lib/vhd-util-set-field.c
--- a/tools/blktap2/vhd/lib/vhd-util-set-field.c
+++ b/tools/blktap2/vhd/lib/vhd-util-set-field.c
@@ -96,7 +96,6 @@ vhd_util_set_field(int argc, char **argv
 
 	err = vhd_write_footer(&vhd, &vhd.footer);
 		
- done:
 	vhd_close(&vhd);
 	return err;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfc-0005gq-F5; Mon, 02 Apr 2012 20:16:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfY-0005dm-SB
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:05 +0000
Received: from [85.158.138.51:45590] by server-11.bemta-3.messagelabs.com id
	41/E7-12049-4090A7F4; Mon, 02 Apr 2012 20:16:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333397763!20414950!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25160 invoked from network); 2 Apr 2012 20:16:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1210;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=XTnXYGOpwmZMn7vZNwLO8KitSxc=;
	b=I8MIw3F2gfJnxl7Eyww95K/tRDl+WwtDrAKre6W+cOK3U49QQQU3IvzzCqGsiSFvgp5
	RYA1wQ2l98OmsKyohguWbLOfQw6LjvYSBr+kpqbMgEaM9AgobJpHjLSWBuksVcYplhugM
	qg69L4AXaL0Mx9L3JTG1m8AgOmFFL6LH/7A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (fruni mo45) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6070f6o32J4DhG ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3600F18638;
	Mon,  2 Apr 2012 22:16:02 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: a85817bc44e57a805afffc3e91d5bf7051a361e0
Message-Id: <a85817bc44e57a805aff.1333397740@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:40 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17 of 18] tools/blktap2: remove unused labels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397583 -7200
# Node ID a85817bc44e57a805afffc3e91d5bf7051a361e0
# Parent  71055bfdb14c72072d9b3fdf6b3c4973ae5b8a20
tools/blktap2: remove unused labels

vhd-util-read.c:478:2: warning: label 'print' defined but not used [-Wunused-label]
vhd-util-set-field.c:99:2: warning: label 'done' defined but not used [-Wunused-label]

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 71055bfdb14c -r a85817bc44e5 tools/blktap2/vhd/lib/vhd-util-read.c
--- a/tools/blktap2/vhd/lib/vhd-util-read.c
+++ b/tools/blktap2/vhd/lib/vhd-util-read.c
@@ -475,7 +475,6 @@ vhd_test_bitmap(vhd_context_t *vhd, uint
 		else
 			bit = vhd_bitmap_test(vhd, buf, blk);
 
-	print:
 		printf("block %s: ", conv(hex, blk));
 		printf("sec: %s: %d\n", conv(hex, sec), bit);
 	}
diff -r 71055bfdb14c -r a85817bc44e5 tools/blktap2/vhd/lib/vhd-util-set-field.c
--- a/tools/blktap2/vhd/lib/vhd-util-set-field.c
+++ b/tools/blktap2/vhd/lib/vhd-util-set-field.c
@@ -96,7 +96,6 @@ vhd_util_set_field(int argc, char **argv
 
 	err = vhd_write_footer(&vhd, &vhd.footer);
 		
- done:
 	vhd_close(&vhd);
 	return err;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfa-0005el-6X; Mon, 02 Apr 2012 20:16:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cP-Hq
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.143.99:38113] by server-1.bemta-4.messagelabs.com id
	01/76-20925-3090A7F4; Mon, 02 Apr 2012 20:16:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333397762!21088886!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31876 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=1076;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=iqPUaqsWs6dihbg9A+WTcUtuHmk=;
	b=bUVSXN0q6PdOzjLgSmaMT8bJs43ntDrNVF1ft/gBBKmStSxSNJoz3/tJPI1/mu7yhJ2
	Bn8XRDvyWQJKs+DNKhwbU0q7vc/PU5oGkrv8fNNbIMFjcUVXmvplsKa8ZLFv5aoyrTsae
	lxPxGhpO2HMDDUu0oiIVLh1jb6BnbQtBPr8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (fruni mo61) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id o00817o32IuXAK ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 08B8618637;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: c582ef14a24cb2186c1748047a62a85fae0dbeb3
Message-Id: <c582ef14a24cb2186c17.1333397734@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:34 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11 of 18] tools/libvchan: fix function
 prototypes in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397559 -7200
# Node ID c582ef14a24cb2186c1748047a62a85fae0dbeb3
# Parent  b0863d6ce260ffdfb9dd6c76d84c083fcf372a7f
tools/libvchan: fix function prototypes in node-select.c

-O2 -Wall -Werror triggers these warnings:

node-select.c:57:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]
node-select.c:71:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]

v2:
 - fix just the -Wstrict-prototypes warning

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b0863d6ce260 -r c582ef14a24c tools/libvchan/node-select.c
--- a/tools/libvchan/node-select.c
+++ b/tools/libvchan/node-select.c
@@ -54,7 +54,7 @@ int insiz = 0;
 int outsiz = 0;
 struct libxenvchan *ctrl = 0;
 
-void vchan_wr() {
+void vchan_wr(void) {
 	if (!insiz)
 		return;
 	int ret = libxenvchan_write(ctrl, inbuf, insiz);
@@ -68,7 +68,7 @@ void vchan_wr() {
 	}
 }
 
-void stdout_wr() {
+void stdout_wr(void) {
 	if (!outsiz)
 		return;
 	int ret = write(1, outbuf, outsiz);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfa-0005el-6X; Mon, 02 Apr 2012 20:16:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cP-Hq
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.143.99:38113] by server-1.bemta-4.messagelabs.com id
	01/76-20925-3090A7F4; Mon, 02 Apr 2012 20:16:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333397762!21088886!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31876 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=1076;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=iqPUaqsWs6dihbg9A+WTcUtuHmk=;
	b=bUVSXN0q6PdOzjLgSmaMT8bJs43ntDrNVF1ft/gBBKmStSxSNJoz3/tJPI1/mu7yhJ2
	Bn8XRDvyWQJKs+DNKhwbU0q7vc/PU5oGkrv8fNNbIMFjcUVXmvplsKa8ZLFv5aoyrTsae
	lxPxGhpO2HMDDUu0oiIVLh1jb6BnbQtBPr8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (fruni mo61) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id o00817o32IuXAK ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 08B8618637;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: c582ef14a24cb2186c1748047a62a85fae0dbeb3
Message-Id: <c582ef14a24cb2186c17.1333397734@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:34 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11 of 18] tools/libvchan: fix function
 prototypes in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397559 -7200
# Node ID c582ef14a24cb2186c1748047a62a85fae0dbeb3
# Parent  b0863d6ce260ffdfb9dd6c76d84c083fcf372a7f
tools/libvchan: fix function prototypes in node-select.c

-O2 -Wall -Werror triggers these warnings:

node-select.c:57:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]
node-select.c:71:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]

v2:
 - fix just the -Wstrict-prototypes warning

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b0863d6ce260 -r c582ef14a24c tools/libvchan/node-select.c
--- a/tools/libvchan/node-select.c
+++ b/tools/libvchan/node-select.c
@@ -54,7 +54,7 @@ int insiz = 0;
 int outsiz = 0;
 struct libxenvchan *ctrl = 0;
 
-void vchan_wr() {
+void vchan_wr(void) {
 	if (!insiz)
 		return;
 	int ret = libxenvchan_write(ctrl, inbuf, insiz);
@@ -68,7 +68,7 @@ void vchan_wr() {
 	}
 }
 
-void stdout_wr() {
+void stdout_wr(void) {
 	if (!outsiz)
 		return;
 	int ret = write(1, outbuf, outsiz);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfX-0005cs-8n; Mon, 02 Apr 2012 20:16:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfV-0005cP-VM
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.143.99:61280] by server-1.bemta-4.messagelabs.com id
	AB/66-20925-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1333397760!15638143!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27450 invoked from network); 2 Apr 2012 20:16:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397759; l=1816;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=tow/XECKuwCInnFk+fFEmthVmoQ=;
	b=l+pNVZ2gWiLFDG71ZXwqW1YNsROVwPLKNdPMPKTnDimpGqQisSP9vEOkWoXEK5lgswE
	e0qnq0Ehrb5kGrGhiBrTwJlyJoRqPub8TPwW6cmWG/X+h/tNLQXeyZRYHv5e+5i5E4KCp
	a7CYmdFlZzXj7fIKuYlzgw+DREIDgHAUGGQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo5) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y04017o32JmwAx ;
	Mon, 2 Apr 2012 22:15:59 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CC45C18637;
	Mon,  2 Apr 2012 22:15:58 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 21640ef72ce861892d71f3916ba6ed0f9a411cca
Message-Id: <21640ef72ce861892d71.1333397724@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:24 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01 of 18] tools/blktap: remove unneeded pointer
 dereferencing in convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397497 -7200
# Node ID 21640ef72ce861892d71f3916ba6ed0f9a411cca
# Parent  14609be41f369c26e759c5d63cc0d2be2fc5b9b6
tools/blktap: remove unneeded pointer dereferencing in convert_dev_name_to_num

xs_api.c: In function 'convert_dev_name_to_num':
xs_api.c:227:4: warning: value computed is not used [-Wunused-value]
xs_api.c:229:3: warning: value computed is not used [-Wunused-value]
xs_api.c:235:4: warning: value computed is not used [-Wunused-value]
xs_api.c:237:3: warning: value computed is not used [-Wunused-value]
xs_api.c:244:4: warning: value computed is not used [-Wunused-value]
xs_api.c:246:3: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

v2:
 - update description, fix only the actual compiler warning
   other unrelated changes will go into a separate patch

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 14609be41f36 -r 21640ef72ce8 tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -224,26 +224,26 @@ int convert_dev_name_to_num(char *name) 
 		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
 			if(*ptr == *p)
 				break;
-			*ptr++;
+			ptr++;
 		}
-		*p++;
+		p++;
 		ret = BASE_DEV_VAL + (16*i) + atoi(p);
 	} else if (strstr(name, p_hd) != NULL) {
 		p = name + strlen(p_hd);
 		for (i = 0, ptr = alpha; i < strlen(alpha); i++) {
 			if(*ptr == *p) break;
-			*ptr++;
+			ptr++;
 		}
-		*p++;
+		p++;
 		ret = (majors[i/2]*256) + atoi(p);
 
 	} else if (strstr(name, p_xvd) != NULL) {
 		p = name + strlen(p_xvd);
 		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
 			if(*ptr == *p) break;
-			*ptr++;
+			ptr++;
 		}
-		*p++;
+		p++;
 		ret = (202*256) + (16*i) + atoi(p);
 
 	} else if (strstr(name, p_plx) != NULL) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfX-0005cs-8n; Mon, 02 Apr 2012 20:16:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfV-0005cP-VM
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.143.99:61280] by server-1.bemta-4.messagelabs.com id
	AB/66-20925-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1333397760!15638143!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27450 invoked from network); 2 Apr 2012 20:16:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397759; l=1816;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=tow/XECKuwCInnFk+fFEmthVmoQ=;
	b=l+pNVZ2gWiLFDG71ZXwqW1YNsROVwPLKNdPMPKTnDimpGqQisSP9vEOkWoXEK5lgswE
	e0qnq0Ehrb5kGrGhiBrTwJlyJoRqPub8TPwW6cmWG/X+h/tNLQXeyZRYHv5e+5i5E4KCp
	a7CYmdFlZzXj7fIKuYlzgw+DREIDgHAUGGQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo5) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y04017o32JmwAx ;
	Mon, 2 Apr 2012 22:15:59 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CC45C18637;
	Mon,  2 Apr 2012 22:15:58 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 21640ef72ce861892d71f3916ba6ed0f9a411cca
Message-Id: <21640ef72ce861892d71.1333397724@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:24 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01 of 18] tools/blktap: remove unneeded pointer
 dereferencing in convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397497 -7200
# Node ID 21640ef72ce861892d71f3916ba6ed0f9a411cca
# Parent  14609be41f369c26e759c5d63cc0d2be2fc5b9b6
tools/blktap: remove unneeded pointer dereferencing in convert_dev_name_to_num

xs_api.c: In function 'convert_dev_name_to_num':
xs_api.c:227:4: warning: value computed is not used [-Wunused-value]
xs_api.c:229:3: warning: value computed is not used [-Wunused-value]
xs_api.c:235:4: warning: value computed is not used [-Wunused-value]
xs_api.c:237:3: warning: value computed is not used [-Wunused-value]
xs_api.c:244:4: warning: value computed is not used [-Wunused-value]
xs_api.c:246:3: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

v2:
 - update description, fix only the actual compiler warning
   other unrelated changes will go into a separate patch

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 14609be41f36 -r 21640ef72ce8 tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -224,26 +224,26 @@ int convert_dev_name_to_num(char *name) 
 		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
 			if(*ptr == *p)
 				break;
-			*ptr++;
+			ptr++;
 		}
-		*p++;
+		p++;
 		ret = BASE_DEV_VAL + (16*i) + atoi(p);
 	} else if (strstr(name, p_hd) != NULL) {
 		p = name + strlen(p_hd);
 		for (i = 0, ptr = alpha; i < strlen(alpha); i++) {
 			if(*ptr == *p) break;
-			*ptr++;
+			ptr++;
 		}
-		*p++;
+		p++;
 		ret = (majors[i/2]*256) + atoi(p);
 
 	} else if (strstr(name, p_xvd) != NULL) {
 		p = name + strlen(p_xvd);
 		for(i = 0, ptr = alpha; i < strlen(alpha); i++) {
 			if(*ptr == *p) break;
-			*ptr++;
+			ptr++;
 		}
-		*p++;
+		p++;
 		ret = (202*256) + (16*i) + atoi(p);
 
 	} else if (strstr(name, p_plx) != NULL) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfY-0005dl-C6; Mon, 02 Apr 2012 20:16:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cS-Gy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.138.51:33998] by server-4.bemta-3.messagelabs.com id
	09/36-16467-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333397760!20449924!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=867;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=C17S3gC4Lot+DAu+bSngJeopwws=;
	b=YxfIReasdfJT2zCYJMJfiI3fThOZ8SGmx8ww395Rw8CYtRA62fh5+E4F+s0fHjML5KN
	Nm4H+qKVu9qpaQ44IY9cNtU641h/da8IimIJ8tdjTQNoB2s6YNFEa6qRQMsh1aIHB7akU
	fYoNALPF+9cDk76WveotYn1RBT/NTMxbHLE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo18) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 50268do32JZJO1 ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C085118630;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: cbdba2284f36dba539b7f5a0cded571c96f2bc4c
Message-Id: <cbdba2284f36dba539b7.1333397728@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05 of 18] tools/blktap: remove unneeded pointer
 dereferencing from qcow2raw.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397528 -7200
# Node ID cbdba2284f36dba539b7f5a0cded571c96f2bc4c
# Parent  ae6bf2207a4e36ca6a60b42e82f79b8de09acec3
tools/blktap: remove unneeded pointer dereferencing from qcow2raw.c

qcow2raw.c: In function 'print_bytes':
qcow2raw.c:76:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ae6bf2207a4e -r cbdba2284f36 tools/blktap/drivers/qcow2raw.c
--- a/tools/blktap/drivers/qcow2raw.c
+++ b/tools/blktap/drivers/qcow2raw.c
@@ -73,7 +73,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if (k % 16 == 0) DFPRINTF("\n");
         else if (k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfd-0005hm-7a; Mon, 02 Apr 2012 20:16:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfa-0005cR-EZ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:06 +0000
Received: from [85.158.143.35:20935] by server-2.bemta-4.messagelabs.com id
	18/27-17550-6090A7F4; Mon, 02 Apr 2012 20:16:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333397761!14622097!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32746 invoked from network); 2 Apr 2012 20:16:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=871;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=a3sZ7japayTX0AICRNkt/q2vZjU=;
	b=Fq7uh8A0XGA6aL5CoqSDz3X9JoYdxqBeR/wgV3MjxtewMjiNJvSIyDe3UR9Oux019Ra
	h+qrlp8sP03HfyyF1BJK/rgYAjOxZLh3Q76arfOTPvnfwI9bkNa7GodnnmbQ+ypWPODlU
	pGgAVqRI7C02RO4RpZSzKuhKlSpMU24I2rU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo43) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q06eceo32IISPp ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D0E531863A;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: b0863d6ce260ffdfb9dd6c76d84c083fcf372a7f
Message-Id: <b0863d6ce260ffdfb9dd.1333397733@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:33 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10 of 18] tools/blktap2: remove unneeded pointer
 dereferencing from qcow2raw.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397554 -7200
# Node ID b0863d6ce260ffdfb9dd6c76d84c083fcf372a7f
# Parent  9b7de2b8d7d6c8312e10dabb68ebebeb5bfd1787
tools/blktap2: remove unneeded pointer dereferencing from qcow2raw.c

qcow2raw.c: In function 'print_bytes':
qcow2raw.c:96:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9b7de2b8d7d6 -r b0863d6ce260 tools/blktap2/drivers/qcow2raw.c
--- a/tools/blktap2/drivers/qcow2raw.c
+++ b/tools/blktap2/drivers/qcow2raw.c
@@ -93,7 +93,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if (k % 16 == 0) DFPRINTF("\n");
         else if (k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfc-0005gY-2V; Mon, 02 Apr 2012 20:16:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfY-0005d8-6G
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:04 +0000
Received: from [85.158.138.51:45515] by server-2.bemta-3.messagelabs.com id
	91/AC-15460-3090A7F4; Mon, 02 Apr 2012 20:16:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333397760!20414942!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24968 invoked from network); 2 Apr 2012 20:16:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=1020;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=H1RSP6j66X0YkfKrvM87VyMi73c=;
	b=U5Rj+yzWohejQRfRa5QDuajsPWjrXXHbOLaCtpdc+JAq4+xzjnazazRotngh3jLF/ur
	btYuX4hCIOLUeASnsiTPztm/spY7+PSMuf2vcfNTaqUEP5OuS6+27T2XNvlk0nVkPd18p
	JBrJV2hLtvymftkqDKZdAZZov5U9fzG2Ivg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32IqrnZ ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 03EFE18638;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 569fc8260490b64ae837c6ed67f1a5b2e582744c
Message-Id: <569fc8260490b64ae837.1333397725@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02 of 18] tools/blktap: constify string arrays
 in convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397505 -7200
# Node ID 569fc8260490b64ae837c6ed67f1a5b2e582744c
# Parent  21640ef72ce861892d71f3916ba6ed0f9a411cca
tools/blktap: constify string arrays in convert_dev_name_to_num

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 21640ef72ce8 -r 569fc8260490 tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -210,14 +210,15 @@ done:
 }
 
 int convert_dev_name_to_num(char *name) {
-	char *p, *ptr;
+	char *p;
+	const char *ptr;
 	int majors[10] = {3,22,33,34,56,57,88,89,90,91};
 	int maj,i,ret = 0;
-	char *p_sd = "/dev/sd";
-	char *p_hd = "/dev/hd";
-	char *p_xvd = "/dev/xvd";
-	char *p_plx = "plx";
-	char *alpha = "abcdefghijklmnop";
+	const char p_sd[] = "/dev/sd";
+	const char p_hd[] = "/dev/hd";
+	const char p_xvd[] = "/dev/xvd";
+	const char p_plx[] = "plx";
+	const char alpha[] = "abcdefghijklmnop";
 
 	if (strstr(name, p_sd) != NULL) {
 		p = name + strlen(p_sd);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfa-0005f8-Jt; Mon, 02 Apr 2012 20:16:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005co-JA
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.139.83:15903] by server-12.bemta-5.messagelabs.com id
	1B/94-05587-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333397761!22133500!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17604 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=1260;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=TTeQ/wu7mn0/zTU0On+FtqYPJVM=;
	b=oc67AuL4scPnMYUToi4hbeX+7/vm4RpHAl+vi5bE6YeIuhClvk/Z/L5c5KfTDuTth4h
	/1v2kvzITNKB/DBAj2ZJFf0vOnTUamK/Zc0tdXLath5bn+U+7BRBhyG8G1+0rW13fvViT
	b5pk51YowFGY8stWAxd7TNCula8NBqOWuh8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (fruni mo12) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N0586do32K7Ydr ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6EF0418639;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: e9b9e8254311fb61930ab5a954e777928466c607
Message-Id: <e9b9e8254311fb61930a.1333397731@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:31 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08 of 18] tools/blktap2: fix build errors caused
 by Werror in tdqcow_get_parent_id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397540 -7200
# Node ID e9b9e8254311fb61930ab5a954e777928466c607
# Parent  acb561c6d4d8ebee95ad0e7007f99a2d22dbaa34
tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id

-O2 -Wall -Werror triggers these warnings:

block-qcow.c: In function 'tdqcow_get_parent_id':
block-qcow.c:1457:17: warning: 'type' may be used uninitialized in this function [-Wuninitialized]

The compiler can not know that open() writes to errno so it has to
assume that errno can be zero. Use assert as hint for gcc.

v2:
 - add assert() as suggested by IanJ

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r acb561c6d4d8 -r e9b9e8254311 tools/blktap2/drivers/block-qcow.c
--- a/tools/blktap2/drivers/block-qcow.c
+++ b/tools/blktap2/drivers/block-qcow.c
@@ -34,6 +34,7 @@
 #include <inttypes.h>
 #include <libaio.h>
 #include <limits.h>
+#include <assert.h>
 #include "bswap.h"
 #include "aes.h"
 #include "md5.h"
@@ -1407,8 +1408,10 @@ tdqcow_get_image_type(const char *file, 
 	QCowHeader header;
 
 	fd = open(file, O_RDONLY);
-	if (fd == -1)
+	if (fd == -1) {
+		assert(errno);
 		return -errno;
+	}
 
 	size = read(fd, &header, sizeof(header));
 	close(fd);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfZ-0005eN-AP; Mon, 02 Apr 2012 20:16:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cf-0M
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.138.51:45535] by server-12.bemta-3.messagelabs.com id
	22/08-30663-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333397761!20449926!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24423 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=1440;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=21QmhWTgLhy+ycXtoPDWJSOcnjw=;
	b=kH5QyIYPyp49P9IYQg/QE8VbhtmxFFdN9VKePH+HD4b7fUlOtHw7UxYUO/wcjBuG+Yi
	oglrum3F4UcYheVKHXhtPC89c4F+jVlHOBkuFp5n+wkazOkW23i5Io5LXg+gqKxfzdFEa
	SNxEBvUdGNZKlBnrx/Z3YMHVbsn8z6igRpM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (jimi mo2) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Z0151bo32K0uhe ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 337E718638;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: acb561c6d4d8ebee95ad0e7007f99a2d22dbaa34
Message-Id: <acb561c6d4d8ebee95ad.1333397730@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:30 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07 of 18] tools/blktap2: fix out of bounds
 access in block-log.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397537 -7200
# Node ID acb561c6d4d8ebee95ad0e7007f99a2d22dbaa34
# Parent  8d134408ddf233c6fe3a452b9b9f0780f91170e6
tools/blktap2: fix out of bounds access in block-log.c

block-log.c: In function 'ctl_close_sock':
block-log.c:363:23: warning: array subscript is above array bounds [-Warray-bounds]

Adjust loop condition in ctl_close_sock() to fix warning.
Adjust array acccess in ctl_close() to actually access the array member.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 8d134408ddf2 -r acb561c6d4d8 tools/blktap2/drivers/block-log.c
--- a/tools/blktap2/drivers/block-log.c
+++ b/tools/blktap2/drivers/block-log.c
@@ -324,11 +324,11 @@ static int ctl_open(struct tdlog_state* 
 static int ctl_close(struct tdlog_state* s)
 {
   while (s->connected) {
+    s->connected--;
     tapdisk_server_unregister_event(s->connections[s->connected].id);
     close(s->connections[s->connected].fd);
     s->connections[s->connected].fd = -1;
     s->connections[s->connected].id = 0;
-    s->connected--;
   }
 
   if (s->ctl.fd >= 0) {
@@ -359,7 +359,7 @@ static int ctl_close_sock(struct tdlog_s
 {
   int i;
 
-  for (i = 0; i <= s->connected; i++) {
+  for (i = 0; i < s->connected; i++) {
     if (s->connections[i].fd == fd) {
       tapdisk_server_unregister_event(s->connections[i].id);
       close(s->connections[i].fd);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfY-0005dV-0B; Mon, 02 Apr 2012 20:16:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cR-Eb
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.143.35:29182] by server-2.bemta-4.messagelabs.com id
	47/17-17550-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333397760!10662643!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20076 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=1216;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Y43zaoGvjUIz588iBibHiKHJXUc=;
	b=HbU41G7OL0nIJWJXvDn/MhgsYaccH+o/Ga0zQGqUZDCcAUzVwrneGhXqM66xTFpcnKH
	aEyrq/+CspEPd0yc/TlGbGAVilzZzXdnb8IMD4CWix5kAIDhkftUfKHDcsz3Za7XL4DQI
	lbV/hTqGdpJsPFeulDK12AdAMI7Ub8PUfU4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32Iqrnb ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2CAFD18639;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 90e2257cace2c3b7b8e7c4611614ad4da07ec895
Message-Id: <90e2257cace2c3b7b8e7.1333397726@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:26 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03 of 18] tools/blktap: fix params and
	physical-device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397506 -7200
# Node ID 90e2257cace2c3b7b8e7c4611614ad4da07ec895
# Parent  569fc8260490b64ae837c6ed67f1a5b2e582744c
tools/blktap: fix params and physical-device parsing

If parsing the "physical-device" property fails the physical device node
should come from the "params" property. But since the deverr value was
overwritten during read of the "mode" property, the "params" property
was never parsed.

Fix this by using different local variable for reading "mode" so that
deverr can be reused to check the "params" property.

v2:
 - use different local variable as suggested by IanJ

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 569fc8260490 -r 90e2257cace2 tools/blktap/lib/xenbus.c
--- a/tools/blktap/lib/xenbus.c
+++ b/tools/blktap/lib/xenbus.c
@@ -346,8 +346,8 @@ static void ueblktap_setup(struct xs_han
 	}
 
 	/* Check to see if device is to be opened read-only. */
-	deverr = xs_gather(h, bepath, "mode", NULL, &path, NULL);
-	if (deverr) {
+	er = xs_gather(h, bepath, "mode", NULL, &path, NULL);
+	if (er) {
 		DPRINTF("ERROR: could not find read/write mode\n");
 		goto fail;
 	} else if (path[0] == 'r')

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfc-0005hH-RD; Mon, 02 Apr 2012 20:16:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfa-0005do-7m
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:06 +0000
Received: from [85.158.143.35:29275] by server-3.bemta-4.messagelabs.com id
	D5/7A-05853-4090A7F4; Mon, 02 Apr 2012 20:16:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333397762!11480155!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21432 invoked from network); 2 Apr 2012 20:16:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1758;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=JcKsexQfWl6hQv3tiiKpf1cZeG8=;
	b=KmtFVD0ofd55mSPSVAecuUqIAOgLzYm4/ygcZS8ECJVhNYWp1bIGNqdunzTLu5CCG9b
	aoaEgYtgZf8tyeIVCwdZ8TBXcwUXGw1RZp5NpOZY4e+vElSG6FqGU+LGwL3tc2v+DxV/X
	LF2UwEu88XaJ20O3WnNXw6a8EK5uazs9MP0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo8) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f04a8eo32JVD9O ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B48F018630;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 55f205a0d2d6831f0e0280bd19d0ade22ebd9fe3
Message-Id: <55f205a0d2d6831f0e02.1333397738@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:38 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15 of 18] tools/blktap2: remove static string
 table from header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397578 -7200
# Node ID 55f205a0d2d6831f0e0280bd19d0ade22ebd9fe3
# Parent  3d15aa971865cf18dac45cb70b53b5380604cc8d
tools/blktap2: remove static string table from header file

-O2 -Wall -Werror triggers these warnings:

../../include/vhd.h:109: warning: 'HD_TYPE_STR' defined but not used

Since its used only in one place, move it to the .c file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3d15aa971865 -r 55f205a0d2d6 tools/blktap2/include/vhd.h
--- a/tools/blktap2/include/vhd.h
+++ b/tools/blktap2/include/vhd.h
@@ -105,17 +105,6 @@ static const char HD_COOKIE[9]  =  "cone
 #define HD_TYPE_DYNAMIC    3  /* dynamic disk */
 #define HD_TYPE_DIFF       4  /* differencing disk */
 
-/* String table for hd.type */
-static const char *HD_TYPE_STR[7] = {
-        "None",                    /* 0 */
-        "Reserved (deprecated)",   /* 1 */
-        "Fixed hard disk",         /* 2 */
-        "Dynamic hard disk",       /* 3 */
-        "Differencing hard disk",  /* 4 */
-        "Reserved (deprecated)",   /* 5 */
-        "Reserved (deprecated)"    /* 6 */
-};
-
 #define HD_TYPE_MAX 6
 
 struct prt_loc {
diff -r 3d15aa971865 -r 55f205a0d2d6 tools/blktap2/vhd/lib/vhd-util-read.c
--- a/tools/blktap2/vhd/lib/vhd-util-read.c
+++ b/tools/blktap2/vhd/lib/vhd-util-read.c
@@ -34,6 +34,17 @@
 #include "libvhd.h"
 #include "vhd-util.h"
 
+/* String table for hd.type */
+static const char *HD_TYPE_STR[7] = {
+        "None",                    /* 0 */
+        "Reserved (deprecated)",   /* 1 */
+        "Fixed hard disk",         /* 2 */
+        "Dynamic hard disk",       /* 3 */
+        "Differencing hard disk",  /* 4 */
+        "Reserved (deprecated)",   /* 5 */
+        "Reserved (deprecated)"    /* 6 */
+};
+
 #define nsize     15
 static char nbuf[nsize];
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfa-0005f8-Jt; Mon, 02 Apr 2012 20:16:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005co-JA
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.139.83:15903] by server-12.bemta-5.messagelabs.com id
	1B/94-05587-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333397761!22133500!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17604 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=1260;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=TTeQ/wu7mn0/zTU0On+FtqYPJVM=;
	b=oc67AuL4scPnMYUToi4hbeX+7/vm4RpHAl+vi5bE6YeIuhClvk/Z/L5c5KfTDuTth4h
	/1v2kvzITNKB/DBAj2ZJFf0vOnTUamK/Zc0tdXLath5bn+U+7BRBhyG8G1+0rW13fvViT
	b5pk51YowFGY8stWAxd7TNCula8NBqOWuh8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (fruni mo12) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N0586do32K7Ydr ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6EF0418639;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: e9b9e8254311fb61930ab5a954e777928466c607
Message-Id: <e9b9e8254311fb61930a.1333397731@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:31 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08 of 18] tools/blktap2: fix build errors caused
 by Werror in tdqcow_get_parent_id
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397540 -7200
# Node ID e9b9e8254311fb61930ab5a954e777928466c607
# Parent  acb561c6d4d8ebee95ad0e7007f99a2d22dbaa34
tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id

-O2 -Wall -Werror triggers these warnings:

block-qcow.c: In function 'tdqcow_get_parent_id':
block-qcow.c:1457:17: warning: 'type' may be used uninitialized in this function [-Wuninitialized]

The compiler can not know that open() writes to errno so it has to
assume that errno can be zero. Use assert as hint for gcc.

v2:
 - add assert() as suggested by IanJ

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r acb561c6d4d8 -r e9b9e8254311 tools/blktap2/drivers/block-qcow.c
--- a/tools/blktap2/drivers/block-qcow.c
+++ b/tools/blktap2/drivers/block-qcow.c
@@ -34,6 +34,7 @@
 #include <inttypes.h>
 #include <libaio.h>
 #include <limits.h>
+#include <assert.h>
 #include "bswap.h"
 #include "aes.h"
 #include "md5.h"
@@ -1407,8 +1408,10 @@ tdqcow_get_image_type(const char *file, 
 	QCowHeader header;
 
 	fd = open(file, O_RDONLY);
-	if (fd == -1)
+	if (fd == -1) {
+		assert(errno);
 		return -errno;
+	}
 
 	size = read(fd, &header, sizeof(header));
 	close(fd);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfY-0005dl-C6; Mon, 02 Apr 2012 20:16:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cS-Gy
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.138.51:33998] by server-4.bemta-3.messagelabs.com id
	09/36-16467-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333397760!20449924!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=867;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=C17S3gC4Lot+DAu+bSngJeopwws=;
	b=YxfIReasdfJT2zCYJMJfiI3fThOZ8SGmx8ww395Rw8CYtRA62fh5+E4F+s0fHjML5KN
	Nm4H+qKVu9qpaQ44IY9cNtU641h/da8IimIJ8tdjTQNoB2s6YNFEa6qRQMsh1aIHB7akU
	fYoNALPF+9cDk76WveotYn1RBT/NTMxbHLE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo18) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 50268do32JZJO1 ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C085118630;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: cbdba2284f36dba539b7f5a0cded571c96f2bc4c
Message-Id: <cbdba2284f36dba539b7.1333397728@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05 of 18] tools/blktap: remove unneeded pointer
 dereferencing from qcow2raw.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397528 -7200
# Node ID cbdba2284f36dba539b7f5a0cded571c96f2bc4c
# Parent  ae6bf2207a4e36ca6a60b42e82f79b8de09acec3
tools/blktap: remove unneeded pointer dereferencing from qcow2raw.c

qcow2raw.c: In function 'print_bytes':
qcow2raw.c:76:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ae6bf2207a4e -r cbdba2284f36 tools/blktap/drivers/qcow2raw.c
--- a/tools/blktap/drivers/qcow2raw.c
+++ b/tools/blktap/drivers/qcow2raw.c
@@ -73,7 +73,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if (k % 16 == 0) DFPRINTF("\n");
         else if (k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfc-0005gY-2V; Mon, 02 Apr 2012 20:16:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfY-0005d8-6G
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:04 +0000
Received: from [85.158.138.51:45515] by server-2.bemta-3.messagelabs.com id
	91/AC-15460-3090A7F4; Mon, 02 Apr 2012 20:16:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333397760!20414942!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24968 invoked from network); 2 Apr 2012 20:16:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=1020;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=H1RSP6j66X0YkfKrvM87VyMi73c=;
	b=U5Rj+yzWohejQRfRa5QDuajsPWjrXXHbOLaCtpdc+JAq4+xzjnazazRotngh3jLF/ur
	btYuX4hCIOLUeASnsiTPztm/spY7+PSMuf2vcfNTaqUEP5OuS6+27T2XNvlk0nVkPd18p
	JBrJV2hLtvymftkqDKZdAZZov5U9fzG2Ivg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32IqrnZ ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 03EFE18638;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 569fc8260490b64ae837c6ed67f1a5b2e582744c
Message-Id: <569fc8260490b64ae837.1333397725@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02 of 18] tools/blktap: constify string arrays
 in convert_dev_name_to_num
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397505 -7200
# Node ID 569fc8260490b64ae837c6ed67f1a5b2e582744c
# Parent  21640ef72ce861892d71f3916ba6ed0f9a411cca
tools/blktap: constify string arrays in convert_dev_name_to_num

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 21640ef72ce8 -r 569fc8260490 tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -210,14 +210,15 @@ done:
 }
 
 int convert_dev_name_to_num(char *name) {
-	char *p, *ptr;
+	char *p;
+	const char *ptr;
 	int majors[10] = {3,22,33,34,56,57,88,89,90,91};
 	int maj,i,ret = 0;
-	char *p_sd = "/dev/sd";
-	char *p_hd = "/dev/hd";
-	char *p_xvd = "/dev/xvd";
-	char *p_plx = "plx";
-	char *alpha = "abcdefghijklmnop";
+	const char p_sd[] = "/dev/sd";
+	const char p_hd[] = "/dev/hd";
+	const char p_xvd[] = "/dev/xvd";
+	const char p_plx[] = "plx";
+	const char alpha[] = "abcdefghijklmnop";
 
 	if (strstr(name, p_sd) != NULL) {
 		p = name + strlen(p_sd);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfd-0005iC-Ju; Mon, 02 Apr 2012 20:16:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfa-0005do-Nt
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:06 +0000
Received: from [85.158.143.99:61396] by server-3.bemta-4.messagelabs.com id
	36/7A-05853-4090A7F4; Mon, 02 Apr 2012 20:16:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333397763!23445695!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9766 invoked from network); 2 Apr 2012 20:16:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1206;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=HkTX67O77Ep5/MuSzffnrAL9JQQ=;
	b=EXve/tiAtED0MDj6PxfQeu7oGFISY6+4Kqngdz0iH+3ddumbVxG01hWGYCx6exMVXTm
	uyIeTMrcHgCxw4+9uZJeO2ISl9nZy8WfVo3ATBj1clPgDwfkgYiPYVOQbACMFdxpPpzYA
	7I/7lCT152R+LwU2zCSy2Qh4J2YCrdR4HoQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo21) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6061b1o32Hwnnh ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id F107E18637;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 71055bfdb14c72072d9b3fdf6b3c4973ae5b8a20
Message-Id: <71055bfdb14c72072d9b.1333397739@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:39 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16 of 18] tools/blktap2: fix build errors caused
 by Werror, remove blkif_op_name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397580 -7200
# Node ID 71055bfdb14c72072d9b3fdf6b3c4973ae5b8a20
# Parent  55f205a0d2d6831f0e0280bd19d0ade22ebd9fe3
tools/blktap2: fix build errors caused by Werror, remove blkif_op_name

-O2 -Wall -Werror triggers these warnings:

../include/blktaplib.h:235: warning: 'blkif_op_name' defined but not used

blkif_op_name[] is odd and appearently not used according to google, except in
an 7 years old blkdump.c which would not compile anyway with current blktap.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 55f205a0d2d6 -r 71055bfdb14c tools/blktap2/include/blktaplib.h
--- a/tools/blktap2/include/blktaplib.h
+++ b/tools/blktap2/include/blktaplib.h
@@ -228,15 +228,4 @@ typedef struct msg_lock {
      ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
      ((_seg) * getpagesize()))
 
-/* Defines that are only used by library clients */
-
-#ifndef __COMPILING_BLKTAP_LIB
-
-static char *blkif_op_name[] = {
-	[BLKIF_OP_READ]       = "READ",
-	[BLKIF_OP_WRITE]      = "WRITE",
-};
-
-#endif /* __COMPILING_BLKTAP_LIB */
-
 #endif /* __BLKTAPLIB_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfe-0005jI-I4; Mon, 02 Apr 2012 20:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfb-0005cR-3f
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:07 +0000
Received: from [85.158.143.99:61499] by server-2.bemta-4.messagelabs.com id
	5A/27-17550-6090A7F4; Mon, 02 Apr 2012 20:16:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333397762!21429398!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30678 invoked from network); 2 Apr 2012 20:16:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1929;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=ng4NTB7NqaM8oMZAqVnpC4wYOHA=;
	b=CCT0ACHRlzgrTkmm6qUz3TBFFCIfcm/1/hPhiKHga2iyVzAPwP9DnssueCxntassEsX
	CrPclBm6AGD2cgpytyv0zvhD1dIzaMZWgXu3/+AKfh1ERFWJIyd7HlEK91kMmT/HOG+gU
	CNa42SX3VREaTPTcHNFdXCnhoBKJ1LWZjKA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo26) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t031edo32I5Y9m ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D6A418639;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 1a0b5c53a3da2a47a98ec093b296616c4b22d810
Message-Id: <1a0b5c53a3da2a47a98e.1333397736@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:36 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13 of 18] tools/xenpaging: fix build errors
	caused by -Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397571 -7200
# Node ID 1a0b5c53a3da2a47a98ec093b296616c4b22d810
# Parent  5d89ebdf878b8b0647a688d0ef938bb933772d86
tools/xenpaging: fix build errors caused by -Werror

-O2 -Wall -Werror triggers these warnings:

xenpaging.c: In function 'xenpaging_init':
xenpaging.c:284: warning: unused variable 'p'
xenpaging.c: In function 'xenpaging_evict_page':
xenpaging.c:606: warning: unused variable 'domctl'
xenpaging.c: In function 'resume_pages':
xenpaging.c:742: warning: unused variable 'xch'
xenpaging.c: In function 'evict_pages':
xenpaging.c:820: warning: unused variable 'xch'

Remove the offending local variables.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 5d89ebdf878b -r 1a0b5c53a3da tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -279,7 +279,6 @@ static struct xenpaging *xenpaging_init(
     xc_domaininfo_t domain_info;
     xc_interface *xch = NULL;
     xentoollog_logger *dbg = NULL;
-    char *p;
     int rc;
     unsigned long ring_pfn, mmap_pfn;
 
@@ -601,8 +600,6 @@ static int xenpaging_evict_page(struct x
     xen_pfn_t victim = gfn;
     int ret;
 
-    DECLARE_DOMCTL;
-
     /* Nominate page */
     ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
     if ( ret < 0 )
@@ -737,7 +734,6 @@ static int xenpaging_populate_page(struc
 /* Trigger a page-in for a batch of pages */
 static void resume_pages(struct xenpaging *paging, int num_pages)
 {
-    xc_interface *xch = paging->xc_handle;
     int i, num = 0;
 
     for ( i = 0; i < paging->max_pages && num < num_pages; i++ )
@@ -815,7 +811,6 @@ static int evict_victim(struct xenpaging
  */
 static int evict_pages(struct xenpaging *paging, int num_pages)
 {
-    xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
 
     /* Reuse known free slots */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfd-0005hm-7a; Mon, 02 Apr 2012 20:16:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfa-0005cR-EZ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:06 +0000
Received: from [85.158.143.35:20935] by server-2.bemta-4.messagelabs.com id
	18/27-17550-6090A7F4; Mon, 02 Apr 2012 20:16:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333397761!14622097!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32746 invoked from network); 2 Apr 2012 20:16:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=871;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=a3sZ7japayTX0AICRNkt/q2vZjU=;
	b=Fq7uh8A0XGA6aL5CoqSDz3X9JoYdxqBeR/wgV3MjxtewMjiNJvSIyDe3UR9Oux019Ra
	h+qrlp8sP03HfyyF1BJK/rgYAjOxZLh3Q76arfOTPvnfwI9bkNa7GodnnmbQ+ypWPODlU
	pGgAVqRI7C02RO4RpZSzKuhKlSpMU24I2rU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo43) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q06eceo32IISPp ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D0E531863A;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: b0863d6ce260ffdfb9dd6c76d84c083fcf372a7f
Message-Id: <b0863d6ce260ffdfb9dd.1333397733@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:33 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10 of 18] tools/blktap2: remove unneeded pointer
 dereferencing from qcow2raw.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397554 -7200
# Node ID b0863d6ce260ffdfb9dd6c76d84c083fcf372a7f
# Parent  9b7de2b8d7d6c8312e10dabb68ebebeb5bfd1787
tools/blktap2: remove unneeded pointer dereferencing from qcow2raw.c

qcow2raw.c: In function 'print_bytes':
qcow2raw.c:96:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9b7de2b8d7d6 -r b0863d6ce260 tools/blktap2/drivers/qcow2raw.c
--- a/tools/blktap2/drivers/qcow2raw.c
+++ b/tools/blktap2/drivers/qcow2raw.c
@@ -93,7 +93,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if (k % 16 == 0) DFPRINTF("\n");
         else if (k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfX-0005dF-Kp; Mon, 02 Apr 2012 20:16:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cO-1U
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.138.51:33975] by server-8.bemta-3.messagelabs.com id
	95/A2-29305-0090A7F4; Mon, 02 Apr 2012 20:16:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333397759!20414633!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26940 invoked from network); 2 Apr 2012 20:16:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397759; l=3613;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TWXYjtekXeRjc+MFwWlsvI3txF0=;
	b=SpMJV8rLBEBxNXitouH4pgZQJxl0V1m+L/7dQv6xcIPLaFOKIQmLx0zZia4U3iLti4X
	k7vKbHJ+ty3Z9ezP+HHs+j2A8LJKARgWTn/WVBwai+WzaU/PiGOteZXVsB5KHCaUgXKgF
	Jo+jNNC00QyuOUktiw7ZIuX1mURDCnelkBs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo36) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x037f5o32J8p97 ;
	Mon, 2 Apr 2012 22:15:59 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9BFE818630;
	Mon,  2 Apr 2012 22:15:58 +0200 (CEST)
MIME-Version: 1.0
Message-Id: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 00 of 18] [v2] tools: fix bugs and build errors
 triggered by -O2 -Wall -Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Changes:
tools/blktap: remove unneeded pointer dereferencing in convert_dev_name_to_num
tools/blktap: constify string arrays in convert_dev_name_to_num
tools/blktap: fix params and physical-device parsing
tools/blktap: remove unneeded pointer dereferencing from img2qcow.c
tools/blktap: remove unneeded pointer dereferencing from qcow2raw.c
tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry
tools/blktap2: fix out of bounds access in block-log.c
tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id
tools/blktap2: remove unneeded pointer dereferencing from img2qcow.c
tools/blktap2: remove unneeded pointer dereferencing from qcow2raw.c
tools/libvchan: fix function prototypes in node-select.c
tools/memshr: fix build errors caused by Werror
tools/xenpaging: fix build errors caused by -Werror
tools/libvchan: fix build errors caused by Werror in io.c
tools/blktap2: remove static string table from header file
tools/blktap2: fix build errors caused by Werror, remove blkif_op_name
tools/blktap2: remove unused labels
tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables

 tools/blktap/drivers/blktapctrl.c          |   19 ++++++-----------
 tools/blktap/drivers/block-aio.c           |    5 ----
 tools/blktap/drivers/block-qcow.c          |    8 +++----
 tools/blktap/drivers/block-qcow2.c         |    9 ++++----
 tools/blktap/drivers/block-ram.c           |    7 ------
 tools/blktap/drivers/block-sync.c          |    5 ----
 tools/blktap/drivers/img2qcow.c            |    7 +-----
 tools/blktap/drivers/qcow2raw.c            |    6 ++---
 tools/blktap/drivers/tapaio.c              |    1 
 tools/blktap/drivers/tapdisk.c             |   18 ++++++++--------
 tools/blktap/lib/xenbus.c                  |   11 ++++-----
 tools/blktap/lib/xs_api.c                  |   32 ++++++++++++++---------------
 tools/blktap2/control/tap-ctl-check.c      |    1 
 tools/blktap2/control/tap-ctl-list.c       |    3 --
 tools/blktap2/control/tap-ctl-spawn.c      |    2 -
 tools/blktap2/drivers/block-aio.c          |    3 --
 tools/blktap2/drivers/block-log.c          |   10 +++------
 tools/blktap2/drivers/block-qcow.c         |   21 ++++++++-----------
 tools/blktap2/drivers/block-ram.c          |    7 ------
 tools/blktap2/drivers/block-remus.c        |   16 +-------------
 tools/blktap2/drivers/block-vhd.c          |   24 ---------------------
 tools/blktap2/drivers/img2qcow.c           |   11 ++-------
 tools/blktap2/drivers/io-optimize.c        |    1 
 tools/blktap2/drivers/lock.c               |    1 
 tools/blktap2/drivers/qcow2raw.c           |    8 ++-----
 tools/blktap2/drivers/tapdisk-client.c     |    1 
 tools/blktap2/drivers/tapdisk-control.c    |    9 +-------
 tools/blktap2/drivers/tapdisk-diff.c       |    2 -
 tools/blktap2/drivers/tapdisk-filter.c     |    2 -
 tools/blktap2/drivers/tapdisk-interface.c  |    1 
 tools/blktap2/drivers/tapdisk-queue.c      |    4 ---
 tools/blktap2/drivers/tapdisk-server.c     |    1 
 tools/blktap2/drivers/tapdisk-stream.c     |    1 
 tools/blktap2/drivers/tapdisk-utils.c      |    1 
 tools/blktap2/drivers/tapdisk-vbd.c        |    5 ----
 tools/blktap2/drivers/td.c                 |    4 +--
 tools/blktap2/include/blktaplib.h          |   11 ---------
 tools/blktap2/include/vhd.h                |   11 ---------
 tools/blktap2/lvm/lvm-util.c               |    2 -
 tools/blktap2/vhd/lib/libvhd-journal.c     |   10 +--------
 tools/blktap2/vhd/lib/libvhd.c             |    6 +----
 tools/blktap2/vhd/lib/vhd-util-check.c     |    2 -
 tools/blktap2/vhd/lib/vhd-util-read.c      |   16 +++++++++++---
 tools/blktap2/vhd/lib/vhd-util-resize.c    |    2 -
 tools/blktap2/vhd/lib/vhd-util-scan.c      |    5 ----
 tools/blktap2/vhd/lib/vhd-util-set-field.c |    2 -
 tools/libvchan/io.c                        |    6 +++--
 tools/libvchan/node-select.c               |    4 +--
 tools/memshr/bidir-hash.h                  |    8 +++----
 tools/memshr/interface.c                   |    3 --
 tools/xenpaging/xenpaging.c                |    5 ----
 51 files changed, 113 insertions(+), 247 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfe-0005ir-60; Mon, 02 Apr 2012 20:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfb-0005do-5i
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:07 +0000
Received: from [85.158.143.99:61495] by server-3.bemta-4.messagelabs.com id
	6B/7A-05853-6090A7F4; Mon, 02 Apr 2012 20:16:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333397762!23445692!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10137 invoked from network); 2 Apr 2012 20:16:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1523;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=ZZlsMKAmV1Z4ulRR154RdI2IXHc=;
	b=Enl55IO7ncJDHNq6JZOilax9Kl3V5zYilHn3TH2Y/Yy5HhA+ztpUjQkKz/2yCcubXI8
	gFX25Qsf9XVMQB6al0JXoaAOzidwk2I0Eu7mTAWbEygYYDbc3Zif5KSyaqNYsxyO6z01y
	c78Df9Uldpm4Ue5gkYShs5Bz5Wjqym6pmGo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo18) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 505f95o32Ikmcd ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 847501863B;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 3d15aa971865cf18dac45cb70b53b5380604cc8d
Message-Id: <3d15aa971865cf18dac4.1333397737@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:37 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397572 -7200
# Node ID 3d15aa971865cf18dac45cb70b53b5380604cc8d
# Parent  1a0b5c53a3da2a47a98ec093b296616c4b22d810
tools/libvchan: fix build errors caused by Werror in io.c

-O2 -Wall -Werror triggers these warnings:

io.c: In function 'do_send':
io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
io.c: In function 'do_recv':
io.c:287: warning: ignoring return value of 'writev', declared with attribute warn_unused_result

writev to -1 will always fail, silence the warning.

v2:
 - add comment about writev use case (see comment about strace in the code)

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1a0b5c53a3da -r 3d15aa971865 tools/libvchan/io.c
--- a/tools/libvchan/io.c
+++ b/tools/libvchan/io.c
@@ -193,7 +193,8 @@ static int do_send(struct libxenvchan *c
 		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p wr", ctrl);
 		iov[1].iov_base = (void *)data;
 		iov[1].iov_len = size;
-		writev(-1, iov, 2);
+		/* Silence gcc warning, will always fail */
+		if (writev(-1, iov, 2));
 	}
 	if (avail_contig > size)
 		avail_contig = size;
@@ -284,7 +285,8 @@ static int do_recv(struct libxenvchan *c
 		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p rd", ctrl);
 		iov[1].iov_base = data;
 		iov[1].iov_len = size;
-		writev(-1, iov, 2);
+		/* Silence gcc warning, will always fail */
+		if (writev(-1, iov, 2));
 	}
 	if (send_notify(ctrl, VCHAN_NOTIFY_READ))
 		return -1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfZ-0005eN-AP; Mon, 02 Apr 2012 20:16:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cf-0M
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.138.51:45535] by server-12.bemta-3.messagelabs.com id
	22/08-30663-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333397761!20449926!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24423 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=1440;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=21QmhWTgLhy+ycXtoPDWJSOcnjw=;
	b=kH5QyIYPyp49P9IYQg/QE8VbhtmxFFdN9VKePH+HD4b7fUlOtHw7UxYUO/wcjBuG+Yi
	oglrum3F4UcYheVKHXhtPC89c4F+jVlHOBkuFp5n+wkazOkW23i5Io5LXg+gqKxfzdFEa
	SNxEBvUdGNZKlBnrx/Z3YMHVbsn8z6igRpM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (jimi mo2) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Z0151bo32K0uhe ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 337E718638;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: acb561c6d4d8ebee95ad0e7007f99a2d22dbaa34
Message-Id: <acb561c6d4d8ebee95ad.1333397730@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:30 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07 of 18] tools/blktap2: fix out of bounds
 access in block-log.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397537 -7200
# Node ID acb561c6d4d8ebee95ad0e7007f99a2d22dbaa34
# Parent  8d134408ddf233c6fe3a452b9b9f0780f91170e6
tools/blktap2: fix out of bounds access in block-log.c

block-log.c: In function 'ctl_close_sock':
block-log.c:363:23: warning: array subscript is above array bounds [-Warray-bounds]

Adjust loop condition in ctl_close_sock() to fix warning.
Adjust array acccess in ctl_close() to actually access the array member.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 8d134408ddf2 -r acb561c6d4d8 tools/blktap2/drivers/block-log.c
--- a/tools/blktap2/drivers/block-log.c
+++ b/tools/blktap2/drivers/block-log.c
@@ -324,11 +324,11 @@ static int ctl_open(struct tdlog_state* 
 static int ctl_close(struct tdlog_state* s)
 {
   while (s->connected) {
+    s->connected--;
     tapdisk_server_unregister_event(s->connections[s->connected].id);
     close(s->connections[s->connected].fd);
     s->connections[s->connected].fd = -1;
     s->connections[s->connected].id = 0;
-    s->connected--;
   }
 
   if (s->ctl.fd >= 0) {
@@ -359,7 +359,7 @@ static int ctl_close_sock(struct tdlog_s
 {
   int i;
 
-  for (i = 0; i <= s->connected; i++) {
+  for (i = 0; i < s->connected; i++) {
     if (s->connections[i].fd == fd) {
       tapdisk_server_unregister_event(s->connections[i].id);
       close(s->connections[i].fd);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfY-0005dV-0B; Mon, 02 Apr 2012 20:16:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cR-Eb
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.143.35:29182] by server-2.bemta-4.messagelabs.com id
	47/17-17550-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333397760!10662643!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20076 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=1216;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Y43zaoGvjUIz588iBibHiKHJXUc=;
	b=HbU41G7OL0nIJWJXvDn/MhgsYaccH+o/Ga0zQGqUZDCcAUzVwrneGhXqM66xTFpcnKH
	aEyrq/+CspEPd0yc/TlGbGAVilzZzXdnb8IMD4CWix5kAIDhkftUfKHDcsz3Za7XL4DQI
	lbV/hTqGdpJsPFeulDK12AdAMI7Ub8PUfU4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32Iqrnb ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2CAFD18639;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 90e2257cace2c3b7b8e7c4611614ad4da07ec895
Message-Id: <90e2257cace2c3b7b8e7.1333397726@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:26 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03 of 18] tools/blktap: fix params and
	physical-device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397506 -7200
# Node ID 90e2257cace2c3b7b8e7c4611614ad4da07ec895
# Parent  569fc8260490b64ae837c6ed67f1a5b2e582744c
tools/blktap: fix params and physical-device parsing

If parsing the "physical-device" property fails the physical device node
should come from the "params" property. But since the deverr value was
overwritten during read of the "mode" property, the "params" property
was never parsed.

Fix this by using different local variable for reading "mode" so that
deverr can be reused to check the "params" property.

v2:
 - use different local variable as suggested by IanJ

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 569fc8260490 -r 90e2257cace2 tools/blktap/lib/xenbus.c
--- a/tools/blktap/lib/xenbus.c
+++ b/tools/blktap/lib/xenbus.c
@@ -346,8 +346,8 @@ static void ueblktap_setup(struct xs_han
 	}
 
 	/* Check to see if device is to be opened read-only. */
-	deverr = xs_gather(h, bepath, "mode", NULL, &path, NULL);
-	if (deverr) {
+	er = xs_gather(h, bepath, "mode", NULL, &path, NULL);
+	if (er) {
 		DPRINTF("ERROR: could not find read/write mode\n");
 		goto fail;
 	} else if (path[0] == 'r')

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfc-0005hH-RD; Mon, 02 Apr 2012 20:16:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfa-0005do-7m
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:06 +0000
Received: from [85.158.143.35:29275] by server-3.bemta-4.messagelabs.com id
	D5/7A-05853-4090A7F4; Mon, 02 Apr 2012 20:16:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333397762!11480155!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21432 invoked from network); 2 Apr 2012 20:16:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1758;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=JcKsexQfWl6hQv3tiiKpf1cZeG8=;
	b=KmtFVD0ofd55mSPSVAecuUqIAOgLzYm4/ygcZS8ECJVhNYWp1bIGNqdunzTLu5CCG9b
	aoaEgYtgZf8tyeIVCwdZ8TBXcwUXGw1RZp5NpOZY4e+vElSG6FqGU+LGwL3tc2v+DxV/X
	LF2UwEu88XaJ20O3WnNXw6a8EK5uazs9MP0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo8) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f04a8eo32JVD9O ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B48F018630;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 55f205a0d2d6831f0e0280bd19d0ade22ebd9fe3
Message-Id: <55f205a0d2d6831f0e02.1333397738@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:38 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15 of 18] tools/blktap2: remove static string
 table from header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397578 -7200
# Node ID 55f205a0d2d6831f0e0280bd19d0ade22ebd9fe3
# Parent  3d15aa971865cf18dac45cb70b53b5380604cc8d
tools/blktap2: remove static string table from header file

-O2 -Wall -Werror triggers these warnings:

../../include/vhd.h:109: warning: 'HD_TYPE_STR' defined but not used

Since its used only in one place, move it to the .c file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3d15aa971865 -r 55f205a0d2d6 tools/blktap2/include/vhd.h
--- a/tools/blktap2/include/vhd.h
+++ b/tools/blktap2/include/vhd.h
@@ -105,17 +105,6 @@ static const char HD_COOKIE[9]  =  "cone
 #define HD_TYPE_DYNAMIC    3  /* dynamic disk */
 #define HD_TYPE_DIFF       4  /* differencing disk */
 
-/* String table for hd.type */
-static const char *HD_TYPE_STR[7] = {
-        "None",                    /* 0 */
-        "Reserved (deprecated)",   /* 1 */
-        "Fixed hard disk",         /* 2 */
-        "Dynamic hard disk",       /* 3 */
-        "Differencing hard disk",  /* 4 */
-        "Reserved (deprecated)",   /* 5 */
-        "Reserved (deprecated)"    /* 6 */
-};
-
 #define HD_TYPE_MAX 6
 
 struct prt_loc {
diff -r 3d15aa971865 -r 55f205a0d2d6 tools/blktap2/vhd/lib/vhd-util-read.c
--- a/tools/blktap2/vhd/lib/vhd-util-read.c
+++ b/tools/blktap2/vhd/lib/vhd-util-read.c
@@ -34,6 +34,17 @@
 #include "libvhd.h"
 #include "vhd-util.h"
 
+/* String table for hd.type */
+static const char *HD_TYPE_STR[7] = {
+        "None",                    /* 0 */
+        "Reserved (deprecated)",   /* 1 */
+        "Fixed hard disk",         /* 2 */
+        "Dynamic hard disk",       /* 3 */
+        "Differencing hard disk",  /* 4 */
+        "Reserved (deprecated)",   /* 5 */
+        "Reserved (deprecated)"    /* 6 */
+};
+
 #define nsize     15
 static char nbuf[nsize];
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfe-0005jI-I4; Mon, 02 Apr 2012 20:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfb-0005cR-3f
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:07 +0000
Received: from [85.158.143.99:61499] by server-2.bemta-4.messagelabs.com id
	5A/27-17550-6090A7F4; Mon, 02 Apr 2012 20:16:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333397762!21429398!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30678 invoked from network); 2 Apr 2012 20:16:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1929;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=ng4NTB7NqaM8oMZAqVnpC4wYOHA=;
	b=CCT0ACHRlzgrTkmm6qUz3TBFFCIfcm/1/hPhiKHga2iyVzAPwP9DnssueCxntassEsX
	CrPclBm6AGD2cgpytyv0zvhD1dIzaMZWgXu3/+AKfh1ERFWJIyd7HlEK91kMmT/HOG+gU
	CNa42SX3VREaTPTcHNFdXCnhoBKJ1LWZjKA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo26) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t031edo32I5Y9m ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D6A418639;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 1a0b5c53a3da2a47a98ec093b296616c4b22d810
Message-Id: <1a0b5c53a3da2a47a98e.1333397736@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:36 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13 of 18] tools/xenpaging: fix build errors
	caused by -Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397571 -7200
# Node ID 1a0b5c53a3da2a47a98ec093b296616c4b22d810
# Parent  5d89ebdf878b8b0647a688d0ef938bb933772d86
tools/xenpaging: fix build errors caused by -Werror

-O2 -Wall -Werror triggers these warnings:

xenpaging.c: In function 'xenpaging_init':
xenpaging.c:284: warning: unused variable 'p'
xenpaging.c: In function 'xenpaging_evict_page':
xenpaging.c:606: warning: unused variable 'domctl'
xenpaging.c: In function 'resume_pages':
xenpaging.c:742: warning: unused variable 'xch'
xenpaging.c: In function 'evict_pages':
xenpaging.c:820: warning: unused variable 'xch'

Remove the offending local variables.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 5d89ebdf878b -r 1a0b5c53a3da tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -279,7 +279,6 @@ static struct xenpaging *xenpaging_init(
     xc_domaininfo_t domain_info;
     xc_interface *xch = NULL;
     xentoollog_logger *dbg = NULL;
-    char *p;
     int rc;
     unsigned long ring_pfn, mmap_pfn;
 
@@ -601,8 +600,6 @@ static int xenpaging_evict_page(struct x
     xen_pfn_t victim = gfn;
     int ret;
 
-    DECLARE_DOMCTL;
-
     /* Nominate page */
     ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
     if ( ret < 0 )
@@ -737,7 +734,6 @@ static int xenpaging_populate_page(struc
 /* Trigger a page-in for a batch of pages */
 static void resume_pages(struct xenpaging *paging, int num_pages)
 {
-    xc_interface *xch = paging->xc_handle;
     int i, num = 0;
 
     for ( i = 0; i < paging->max_pages && num < num_pages; i++ )
@@ -815,7 +811,6 @@ static int evict_victim(struct xenpaging
  */
 static int evict_pages(struct xenpaging *paging, int num_pages)
 {
-    xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
 
     /* Reuse known free slots */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfX-0005dF-Kp; Mon, 02 Apr 2012 20:16:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cO-1U
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:02 +0000
Received: from [85.158.138.51:33975] by server-8.bemta-3.messagelabs.com id
	95/A2-29305-0090A7F4; Mon, 02 Apr 2012 20:16:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333397759!20414633!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26940 invoked from network); 2 Apr 2012 20:16:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397759; l=3613;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TWXYjtekXeRjc+MFwWlsvI3txF0=;
	b=SpMJV8rLBEBxNXitouH4pgZQJxl0V1m+L/7dQv6xcIPLaFOKIQmLx0zZia4U3iLti4X
	k7vKbHJ+ty3Z9ezP+HHs+j2A8LJKARgWTn/WVBwai+WzaU/PiGOteZXVsB5KHCaUgXKgF
	Jo+jNNC00QyuOUktiw7ZIuX1mURDCnelkBs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo36) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x037f5o32J8p97 ;
	Mon, 2 Apr 2012 22:15:59 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9BFE818630;
	Mon,  2 Apr 2012 22:15:58 +0200 (CEST)
MIME-Version: 1.0
Message-Id: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 00 of 18] [v2] tools: fix bugs and build errors
 triggered by -O2 -Wall -Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Changes:
tools/blktap: remove unneeded pointer dereferencing in convert_dev_name_to_num
tools/blktap: constify string arrays in convert_dev_name_to_num
tools/blktap: fix params and physical-device parsing
tools/blktap: remove unneeded pointer dereferencing from img2qcow.c
tools/blktap: remove unneeded pointer dereferencing from qcow2raw.c
tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry
tools/blktap2: fix out of bounds access in block-log.c
tools/blktap2: fix build errors caused by Werror in tdqcow_get_parent_id
tools/blktap2: remove unneeded pointer dereferencing from img2qcow.c
tools/blktap2: remove unneeded pointer dereferencing from qcow2raw.c
tools/libvchan: fix function prototypes in node-select.c
tools/memshr: fix build errors caused by Werror
tools/xenpaging: fix build errors caused by -Werror
tools/libvchan: fix build errors caused by Werror in io.c
tools/blktap2: remove static string table from header file
tools/blktap2: fix build errors caused by Werror, remove blkif_op_name
tools/blktap2: remove unused labels
tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables

 tools/blktap/drivers/blktapctrl.c          |   19 ++++++-----------
 tools/blktap/drivers/block-aio.c           |    5 ----
 tools/blktap/drivers/block-qcow.c          |    8 +++----
 tools/blktap/drivers/block-qcow2.c         |    9 ++++----
 tools/blktap/drivers/block-ram.c           |    7 ------
 tools/blktap/drivers/block-sync.c          |    5 ----
 tools/blktap/drivers/img2qcow.c            |    7 +-----
 tools/blktap/drivers/qcow2raw.c            |    6 ++---
 tools/blktap/drivers/tapaio.c              |    1 
 tools/blktap/drivers/tapdisk.c             |   18 ++++++++--------
 tools/blktap/lib/xenbus.c                  |   11 ++++-----
 tools/blktap/lib/xs_api.c                  |   32 ++++++++++++++---------------
 tools/blktap2/control/tap-ctl-check.c      |    1 
 tools/blktap2/control/tap-ctl-list.c       |    3 --
 tools/blktap2/control/tap-ctl-spawn.c      |    2 -
 tools/blktap2/drivers/block-aio.c          |    3 --
 tools/blktap2/drivers/block-log.c          |   10 +++------
 tools/blktap2/drivers/block-qcow.c         |   21 ++++++++-----------
 tools/blktap2/drivers/block-ram.c          |    7 ------
 tools/blktap2/drivers/block-remus.c        |   16 +-------------
 tools/blktap2/drivers/block-vhd.c          |   24 ---------------------
 tools/blktap2/drivers/img2qcow.c           |   11 ++-------
 tools/blktap2/drivers/io-optimize.c        |    1 
 tools/blktap2/drivers/lock.c               |    1 
 tools/blktap2/drivers/qcow2raw.c           |    8 ++-----
 tools/blktap2/drivers/tapdisk-client.c     |    1 
 tools/blktap2/drivers/tapdisk-control.c    |    9 +-------
 tools/blktap2/drivers/tapdisk-diff.c       |    2 -
 tools/blktap2/drivers/tapdisk-filter.c     |    2 -
 tools/blktap2/drivers/tapdisk-interface.c  |    1 
 tools/blktap2/drivers/tapdisk-queue.c      |    4 ---
 tools/blktap2/drivers/tapdisk-server.c     |    1 
 tools/blktap2/drivers/tapdisk-stream.c     |    1 
 tools/blktap2/drivers/tapdisk-utils.c      |    1 
 tools/blktap2/drivers/tapdisk-vbd.c        |    5 ----
 tools/blktap2/drivers/td.c                 |    4 +--
 tools/blktap2/include/blktaplib.h          |   11 ---------
 tools/blktap2/include/vhd.h                |   11 ---------
 tools/blktap2/lvm/lvm-util.c               |    2 -
 tools/blktap2/vhd/lib/libvhd-journal.c     |   10 +--------
 tools/blktap2/vhd/lib/libvhd.c             |    6 +----
 tools/blktap2/vhd/lib/vhd-util-check.c     |    2 -
 tools/blktap2/vhd/lib/vhd-util-read.c      |   16 +++++++++++---
 tools/blktap2/vhd/lib/vhd-util-resize.c    |    2 -
 tools/blktap2/vhd/lib/vhd-util-scan.c      |    5 ----
 tools/blktap2/vhd/lib/vhd-util-set-field.c |    2 -
 tools/libvchan/io.c                        |    6 +++--
 tools/libvchan/node-select.c               |    4 +--
 tools/memshr/bidir-hash.h                  |    8 +++----
 tools/memshr/interface.c                   |    3 --
 tools/xenpaging/xenpaging.c                |    5 ----
 51 files changed, 113 insertions(+), 247 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfd-0005iC-Ju; Mon, 02 Apr 2012 20:16:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfa-0005do-Nt
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:06 +0000
Received: from [85.158.143.99:61396] by server-3.bemta-4.messagelabs.com id
	36/7A-05853-4090A7F4; Mon, 02 Apr 2012 20:16:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333397763!23445695!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzI3MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9766 invoked from network); 2 Apr 2012 20:16:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1206;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=HkTX67O77Ep5/MuSzffnrAL9JQQ=;
	b=EXve/tiAtED0MDj6PxfQeu7oGFISY6+4Kqngdz0iH+3ddumbVxG01hWGYCx6exMVXTm
	uyIeTMrcHgCxw4+9uZJeO2ISl9nZy8WfVo3ATBj1clPgDwfkgYiPYVOQbACMFdxpPpzYA
	7I/7lCT152R+LwU2zCSy2Qh4J2YCrdR4HoQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo21) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6061b1o32Hwnnh ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id F107E18637;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 71055bfdb14c72072d9b3fdf6b3c4973ae5b8a20
Message-Id: <71055bfdb14c72072d9b.1333397739@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:39 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16 of 18] tools/blktap2: fix build errors caused
 by Werror, remove blkif_op_name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397580 -7200
# Node ID 71055bfdb14c72072d9b3fdf6b3c4973ae5b8a20
# Parent  55f205a0d2d6831f0e0280bd19d0ade22ebd9fe3
tools/blktap2: fix build errors caused by Werror, remove blkif_op_name

-O2 -Wall -Werror triggers these warnings:

../include/blktaplib.h:235: warning: 'blkif_op_name' defined but not used

blkif_op_name[] is odd and appearently not used according to google, except in
an 7 years old blkdump.c which would not compile anyway with current blktap.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 55f205a0d2d6 -r 71055bfdb14c tools/blktap2/include/blktaplib.h
--- a/tools/blktap2/include/blktaplib.h
+++ b/tools/blktap2/include/blktaplib.h
@@ -228,15 +228,4 @@ typedef struct msg_lock {
      ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
      ((_seg) * getpagesize()))
 
-/* Defines that are only used by library clients */
-
-#ifndef __COMPILING_BLKTAP_LIB
-
-static char *blkif_op_name[] = {
-	[BLKIF_OP_READ]       = "READ",
-	[BLKIF_OP_WRITE]      = "WRITE",
-};
-
-#endif /* __COMPILING_BLKTAP_LIB */
-
 #endif /* __BLKTAPLIB_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfe-0005ir-60; Mon, 02 Apr 2012 20:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfb-0005do-5i
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:07 +0000
Received: from [85.158.143.99:61495] by server-3.bemta-4.messagelabs.com id
	6B/7A-05853-6090A7F4; Mon, 02 Apr 2012 20:16:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333397762!23445692!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10137 invoked from network); 2 Apr 2012 20:16:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397762; l=1523;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=ZZlsMKAmV1Z4ulRR154RdI2IXHc=;
	b=Enl55IO7ncJDHNq6JZOilax9Kl3V5zYilHn3TH2Y/Yy5HhA+ztpUjQkKz/2yCcubXI8
	gFX25Qsf9XVMQB6al0JXoaAOzidwk2I0Eu7mTAWbEygYYDbc3Zif5KSyaqNYsxyO6z01y
	c78Df9Uldpm4Ue5gkYShs5Bz5Wjqym6pmGo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo18) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 505f95o32Ikmcd ;
	Mon, 2 Apr 2012 22:16:02 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 847501863B;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 3d15aa971865cf18dac45cb70b53b5380604cc8d
Message-Id: <3d15aa971865cf18dac4.1333397737@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:37 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397572 -7200
# Node ID 3d15aa971865cf18dac45cb70b53b5380604cc8d
# Parent  1a0b5c53a3da2a47a98ec093b296616c4b22d810
tools/libvchan: fix build errors caused by Werror in io.c

-O2 -Wall -Werror triggers these warnings:

io.c: In function 'do_send':
io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
io.c: In function 'do_recv':
io.c:287: warning: ignoring return value of 'writev', declared with attribute warn_unused_result

writev to -1 will always fail, silence the warning.

v2:
 - add comment about writev use case (see comment about strace in the code)

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1a0b5c53a3da -r 3d15aa971865 tools/libvchan/io.c
--- a/tools/libvchan/io.c
+++ b/tools/libvchan/io.c
@@ -193,7 +193,8 @@ static int do_send(struct libxenvchan *c
 		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p wr", ctrl);
 		iov[1].iov_base = (void *)data;
 		iov[1].iov_len = size;
-		writev(-1, iov, 2);
+		/* Silence gcc warning, will always fail */
+		if (writev(-1, iov, 2));
 	}
 	if (avail_contig > size)
 		avail_contig = size;
@@ -284,7 +285,8 @@ static int do_recv(struct libxenvchan *c
 		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p rd", ctrl);
 		iov[1].iov_base = data;
 		iov[1].iov_len = size;
-		writev(-1, iov, 2);
+		/* Silence gcc warning, will always fail */
+		if (writev(-1, iov, 2));
 	}
 	if (send_notify(ctrl, VCHAN_NOTIFY_READ))
 		return -1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfe-0005jg-TK; Mon, 02 Apr 2012 20:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfc-0005do-FR
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:08 +0000
Received: from [85.158.143.35:29435] by server-3.bemta-4.messagelabs.com id
	10/8A-05853-8090A7F4; Mon, 02 Apr 2012 20:16:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1333397764!5076325!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzQwNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzQwNzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27550 invoked from network); 2 Apr 2012 20:16:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397764; l=59478;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=WOseuTVcdO8kxrVDupHTWoMR/OU=;
	b=RA9OwHOHqcwWHnGCgfDY5piJsHz0oYpjTRDhDSSH3lKpg48EsTPhOO0It5ZcM9ZhveE
	eiucj4Ythvg9H72UqM4KSdeWk/qiVdDGHHIjSJCYe/EwsO0+t+CwjMywnI2Z/NYkg2KqD
	Qsn7pml5pkG7sTpt7qH3IqfisjW+CiN0a+4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo5) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y07264o32JZ4cX ;
	Mon, 2 Apr 2012 22:16:03 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5F6FC18639;
	Mon,  2 Apr 2012 22:16:02 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 33af0a492bf7d2d682fe87f6a0a1501efc187508
Message-Id: <33af0a492bf7d2d682fe.1333397741@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:41 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18 of 18] tools/blktap+blktap2: fix build errors
 caused by Werror, remove unused variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397703 -7200
# Node ID 33af0a492bf7d2d682fe87f6a0a1501efc187508
# Parent  a85817bc44e57a805afffc3e91d5bf7051a361e0
tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables

-O2 -Wall -Werror triggers these warnings below.
The patch removes all listed local variables, a few static arrays in
header files will be changed in another patch.

xenbus.c: In function 'ueblktap_setup':
xenbus.c:325:6: warning: unused variable 'len' [-Wunused-variable]
xenbus.c:324:25: warning: unused variable 'dev' [-Wunused-variable]
xenbus.c: In function 'ueblktap_probe':
xenbus.c:453:11: warning: unused variable 'blkif' [-Wunused-variable]
xenbus.c:451:42: warning: unused variable 'p' [-Wunused-variable]
--
xs_api.c: In function 'xs_gather':
xs_api.c:64:19: warning: unused variable 'i' [-Wunused-variable]
xs_api.c:64:15: warning: unused variable 'num' [-Wunused-variable]
xs_api.c:63:16: warning: unused variable 'e' [-Wunused-variable]
xs_api.c: In function 'convert_dev_name_to_num':
xs_api.c:216:6: warning: unused variable 'maj' [-Wunused-variable]
xs_api.c: In function 'xs_fire_next_watch':
xs_api.c:344:6: warning: unused variable 'er' [-Wunused-variable]
--
blktapctrl.c: In function 'del_disktype':
blktapctrl.c:257:43: warning: unused variable 'close' [-Wunused-variable]
blktapctrl.c:257:32: warning: unused variable 'count' [-Wunused-variable]
blktapctrl.c: In function 'write_msg':
blktapctrl.c:301:11: warning: unused variable 'seed' [-Wunused-variable]
blktapctrl.c:300:19: warning: unused variable 'img' [-Wunused-variable]
blktapctrl.c: In function 'read_msg':
blktapctrl.c:411:25: warning: unused variable 'len' [-Wunused-variable]
blktapctrl.c:410:8: warning: unused variable 'p' [-Wunused-variable]
blktapctrl.c: In function 'blktapctrl_new_blkif':
blktapctrl.c:656:19: warning: unused variable 'wrctldev' [-Wunused-variable]
blktapctrl.c:656:8: warning: unused variable 'rdctldev' [-Wunused-variable]
blktapctrl.c:655:45: warning: unused variable 'new' [-Wunused-variable]
blktapctrl.c:655:29: warning: unused variable 'fd_write' [-Wunused-variable]
blktapctrl.c:655:20: warning: unused variable 'fd_read' [-Wunused-variable]
blktapctrl.c: In function 'open_ctrl_socket':
blktapctrl.c:765:17: warning: unused variable 'timeout' [-Wunused-variable]
blktapctrl.c:764:9: warning: unused variable 'socks' [-Wunused-variable]
blktapctrl.c: In function 'main':
blktapctrl.c:835:26: warning: unused variable 'xs_fd' [-Wunused-variable]
blktapctrl.c:834:17: warning: unused variable 'ctlinfo' [-Wunused-variable]
blktapctrl.c:833:8: warning: unused variable 'devname' [-Wunused-variable]
--
tapdisk.c: In function 'daemonize':
tapdisk.c:65:6: warning: unused variable 'i' [-Wunused-variable]
tapdisk.c: In function 'add_fd_entry':
tapdisk.c:157:6: warning: unused variable 'i' [-Wunused-variable]
tapdisk.c: In function 'read_msg':
tapdisk.c:372:36: warning: unused variable 'io_fd' [-Wunused-variable]
tapdisk.c:372:27: warning: unused variable 'tap_fd' [-Wunused-variable]
tapdisk.c: In function 'do_cow_read':
tapdisk.c:596:11: warning: unused variable 'early' [-Wunused-variable]
tapdisk.c: In function 'get_io_request':
tapdisk.c:647:7: warning: unused variable 'done' [-Wunused-variable]
tapdisk.c:634:6: warning: unused variable 'early' [-Wunused-variable]
tapdisk.c:629:24: warning: unused variable 'rc' [-Wunused-variable]
tapdisk.c: In function 'main':
tapdisk.c:769:18: warning: unused variable 'writefds' [-Wunused-variable]
tapdisk.c:768:8: warning: unused variable 'p' [-Wunused-variable]
tapdisk.c:767:11: warning: unused variable 'msglen' [-Wunused-variable]
tapdisk.c:767:6: warning: unused variable 'len' [-Wunused-variable]
--
block-aio.c: In function 'get_image_info':
block-aio.c:67:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-aio.c:66:16: warning: unused variable 'total_size' [-Wunused-variable]
block-aio.c:65:7: warning: unused variable 'size' [-Wunused-variable]
block-aio.c: In function 'tdaio_open':
block-aio.c:123:6: warning: unused variable 'i' [-Wunused-variable]
--
block-sync.c: In function 'get_image_info':
block-sync.c:59:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-sync.c:58:16: warning: unused variable 'total_size' [-Wunused-variable]
block-sync.c:57:7: warning: unused variable 'size' [-Wunused-variable]
block-sync.c: In function 'tdsync_open':
block-sync.c:114:6: warning: unused variable 'i' [-Wunused-variable]
--
block-ram.c: In function 'get_image_info':
block-ram.c:69:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-ram.c:68:16: warning: unused variable 'total_size' [-Wunused-variable]
block-ram.c:67:7: warning: unused variable 'size' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_read':
block-ram.c:228:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_write':
block-ram.c:242:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_close':
block-ram.c:260:22: warning: unused variable 'prv' [-Wunused-variable]
--
block-qcow.c: In function 'tdqcow_open':
block-qcow.c:725:10: warning: unused variable 'len' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_queue_write':
block-qcow.c:1012:6: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_do_callbacks':
block-qcow.c:1102:41: warning: unused variable 'ptr' [-Wunused-variable]
block-qcow.c:1102:13: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'qcow_create':
block-qcow.c:1146:21: warning: unused variable 'adjust' [-Wunused-variable]
--
block-qcow2.c: In function 'qcow_read':
block-qcow2.c:955:32: warning: unused variable 'n1' [-Wunused-variable]
block-qcow2.c: In function 'qcow_queue_write':
block-qcow2.c:1148:17: warning: unused variable 'src_buf' [-Wunused-variable]
block-qcow2.c: In function 'qcow_do_callbacks':
block-qcow2.c:1864:34: warning: unused variable 'ptr' [-Wunused-variable]
block-qcow2.c:1864:6: warning: unused variable 'ret' [-Wunused-variable]
--
tapaio.c: In function 'tap_aio_init':
tapaio.c:186:7: warning: unused variable 'ioidx' [-Wunused-variable]
--
img2qcow.c: In function 'print_bytes':
img2qcow.c:66:7: warning: unused variable 'i' [-Wunused-variable]
img2qcow.c: In function 'get_image_info':
img2qcow.c:107:17: warning: unused variable 'statBuf' [-Wunused-variable]
img2qcow.c:106:16: warning: unused variable 'total_size' [-Wunused-variable]
img2qcow.c:105:7: warning: unused variable 'size' [-Wunused-variable]
--
qcow2raw.c: In function 'print_bytes':
qcow2raw.c:70:7: warning: unused variable 'i' [-Wunused-variable]
qcow2raw.c: In function 'main':
qcow2raw.c:151:24: warning: unused variable 'input' [-Wunused-variable]
qcow2raw.c:151:20: warning: unused variable 'len' [-Wunused-variable]
--
lvm-util.c: In function 'lvm_scan_lvs':
lvm-util.c:221:29: warning: unused variable 'dev' [-Wunused-variable]
--
libvhd.c: In function 'vhd_read_header':
libvhd.c:1031:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_header':
libvhd.c:2011:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_bitmap':
libvhd.c:2146:9: warning: unused variable 'secs' [-Wunused-variable]
libvhd.c: In function '__vhd_io_allocate_block':
libvhd.c:3206:6: warning: unused variable 'i' [-Wunused-variable]
--
libvhd-journal.c: In function 'vhd_journal_update':
libvhd-journal.c:356:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_add_metadata':
libvhd-journal.c:610:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_create':
libvhd-journal.c:1259:14: warning: unused variable 'stats' [-Wunused-variable]
libvhd-journal.c:1258:8: warning: unused variable 'off' [-Wunused-variable]
libvhd-journal.c:1257:9: warning: unused variable 'size' [-Wunused-variable]
libvhd-journal.c:1256:6: warning: unused variable 'i' [-Wunused-variable]
libvhd-journal.c:1255:8: warning: unused variable 'buf' [-Wunused-variable]
--
vhd-util-read.c: In function 'vhd_print_header':
vhd-util-read.c:73:47: warning: unused variable 'out' [-Wunused-variable]
vhd-util-read.c: In function 'vhd_print_footer':
vhd-util-read.c:108:50: warning: unused variable 'cksm_save' [-Wunused-variable]
--
vhd-util-resize.c: In function 'vhd_dynamic_grow':
vhd-util-resize.c:880:6: warning: unused variable 'i' [-Wunused-variable]
--
vhd-util-set-field.c: In function 'vhd_util_set_field':
vhd-util-set-field.c:40:8: warning: unused variable 'eof' [-Wunused-variable]
--
vhd-util-scan.c: In function 'vhd_util_scan_pretty_allocate_list':
vhd-util-scan.c:118:20: warning: unused variable 'list' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_extract_volume_name':
vhd-util-scan.c:446:6: warning: unused variable 'err' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_get_parent':
vhd-util-scan.c:513:6: warning: unused variable 'i' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_open_volume':
vhd-util-scan.c:681:6: warning: unused variable 'err' [-Wunused-variable]
--
vhd-util-check.c: In function 'vhd_util_check_validate_parent':
vhd-util-check.c:312:11: warning: unused variable 'status' [-Wunused-variable]
vhd-util-check.c: In function 'vhd_util_check':
vhd-util-check.c:928:16: warning: unused variable 'vhd' [-Wunused-variable]
--
libvhd.c: In function 'vhd_read_header':
libvhd.c:1031:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_header':
libvhd.c:2011:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_bitmap':
libvhd.c:2146:9: warning: unused variable 'secs' [-Wunused-variable]
libvhd.c: In function '__vhd_io_allocate_block':
libvhd.c:3206:6: warning: unused variable 'i' [-Wunused-variable]
--
libvhd-journal.c: In function 'vhd_journal_update':
libvhd-journal.c:356:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_add_metadata':
libvhd-journal.c:610:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_create':
libvhd-journal.c:1259:14: warning: unused variable 'stats' [-Wunused-variable]
libvhd-journal.c:1258:8: warning: unused variable 'off' [-Wunused-variable]
libvhd-journal.c:1257:9: warning: unused variable 'size' [-Wunused-variable]
libvhd-journal.c:1256:6: warning: unused variable 'i' [-Wunused-variable]
libvhd-journal.c:1255:8: warning: unused variable 'buf' [-Wunused-variable]
--
vhd-util-read.c: In function 'vhd_print_header':
vhd-util-read.c:73:47: warning: unused variable 'out' [-Wunused-variable]
vhd-util-read.c: In function 'vhd_print_footer':
vhd-util-read.c:108:50: warning: unused variable 'cksm_save' [-Wunused-variable]
--
vhd-util-resize.c: In function 'vhd_dynamic_grow':
vhd-util-resize.c:880:6: warning: unused variable 'i' [-Wunused-variable]
--
vhd-util-set-field.c: In function 'vhd_util_set_field':
vhd-util-set-field.c:40:8: warning: unused variable 'eof' [-Wunused-variable]
--
vhd-util-scan.c: In function 'vhd_util_scan_pretty_allocate_list':
vhd-util-scan.c:118:20: warning: unused variable 'list' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_extract_volume_name':
vhd-util-scan.c:446:6: warning: unused variable 'err' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_get_parent':
vhd-util-scan.c:513:6: warning: unused variable 'i' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_open_volume':
vhd-util-scan.c:681:6: warning: unused variable 'err' [-Wunused-variable]
--
vhd-util-check.c: In function 'vhd_util_check_validate_parent':
vhd-util-check.c:312:11: warning: unused variable 'status' [-Wunused-variable]
vhd-util-check.c: In function 'vhd_util_check':
vhd-util-check.c:928:16: warning: unused variable 'vhd' [-Wunused-variable]
--
../../lvm/lvm-util.c: In function 'lvm_scan_lvs':
../../lvm/lvm-util.c:221:29: warning: unused variable 'dev' [-Wunused-variable]
--
tapdisk-vbd.c: In function 'tapdisk_vbd_add_block_cache':
tapdisk-vbd.c:202:15: warning: unused variable 'driver' [-Wunused-variable]
tapdisk-vbd.c: In function 'tapdisk_vbd_open_level':
tapdisk-vbd.c:316:15: warning: unused variable 'driver' [-Wunused-variable]
tapdisk-vbd.c: In function '__tapdisk_vbd_open_vdi':
tapdisk-vbd.c:389:20: warning: unused variable 'images' [-Wunused-variable]
tapdisk-vbd.c: In function '__tapdisk_vbd_complete_td_request':
tapdisk-vbd.c:1199:17: warning: unused variable 'image' [-Wunused-variable]
--
tapdisk-control.c: In function 'tapdisk_control_allocate_connection':
tapdisk-control.c:92:9: warning: unused variable 'sz' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_list':
tapdisk-control.c:255:13: warning: unused variable 'i' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_attach_vbd':
tapdisk-control.c:317:10: warning: unused variable 'image' [-Wunused-variable]
tapdisk-control.c:316:24: warning: unused variable 'params' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_create_socket':
tapdisk-control.c:761:11: warning: unused variable 'flags' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_open':
tapdisk-control.c:832:6: warning: unused variable 'err' [-Wunused-variable]
--
tapdisk-interface.c: In function 'td_load':
tapdisk-interface.c:40:6: warning: unused variable 'err' [-Wunused-variable]
--
tapdisk-server.c: In function 'tapdisk_server_kick_responses':
tapdisk-server.c:183:6: warning: unused variable 'n' [-Wunused-variable]
--
tapdisk-queue.c: In function 'tapdisk_rwio_setup':
tapdisk-queue.c:197:6: warning: unused variable 'err' [-Wunused-variable]
tapdisk-queue.c: In function 'tapdisk_lio_setup':
tapdisk-queue.c:477:9: warning: unused variable 'sz' [-Wunused-variable]
tapdisk-queue.c: In function 'tapdisk_init_queue':
tapdisk-queue.c:611:6: warning: unused variable 'i' [-Wunused-variable]
--
tapdisk-filter.c: In function 'check_data':
tapdisk-filter.c:159:14: warning: unused variable 'sec' [-Wunused-variable]
--
tapdisk-utils.c: In function 'tapdisk_get_image_size':
tapdisk-utils.c:114:6: warning: unused variable 'ret' [-Wunused-variable]
--
io-optimize.c: In function 'io_merge':
io-optimize.c:222:15: warning: unused variable 'ophead' [-Wunused-variable]
--
block-aio.c: In function 'tdaio_get_image_info':
block-aio.c:69:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-aio.c:68:16: warning: unused variable 'total_size' [-Wunused-variable]
block-aio.c:67:7: warning: unused variable 'size' [-Wunused-variable]
--
block-ram.c: In function 'get_image_info':
block-ram.c:60:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-ram.c:59:16: warning: unused variable 'total_size' [-Wunused-variable]
block-ram.c:58:7: warning: unused variable 'size' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_read':
block-ram.c:203:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_write':
block-ram.c:214:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_close':
block-ram.c:227:22: warning: unused variable 'prv' [-Wunused-variable]
--
block-vhd.c: In function '_vhd_close':
block-vhd.c:729:21: warning: unused variable 'bm' [-Wunused-variable]
block-vhd.c: In function 'vhd_validate_parent':
block-vhd.c:776:14: warning: unused variable 'stats' [-Wunused-variable]
block-vhd.c:775:11: warning: unused variable 'status' [-Wunused-variable]
block-vhd.c: In function 'allocate_block':
block-vhd.c:1383:8: warning: unused variable 'zeros' [-Wunused-variable]
block-vhd.c: In function 'start_new_bitmap_transaction':
block-vhd.c:1863:9: warning: unused variable 'error' [-Wunused-variable]
--
block-log.c: In function 'shmem_open':
block-log.c:220:10: warning: unused variable 'l' [-Wunused-variable]
block-log.c:220:7: warning: unused variable 'i' [-Wunused-variable]
block-log.c: In function 'ctl_kick':
block-log.c:489:22: warning: unused variable 'rspend' [-Wunused-variable]
block-log.c:489:12: warning: unused variable 'rspstart' [-Wunused-variable]
block-log.c: In function 'ctl_request':
block-log.c:560:11: warning: unused variable 'i' [-Wunused-variable]
block-log.c: In function 'tdlog_queue_write':
block-log.c:638:7: warning: unused variable 'rc' [-Wunused-variable]
--
block-qcow.c: In function 'gen_cksum':
block-qcow.c:86:7: warning: unused variable 'i' [-Wunused-variable]
block-qcow.c: In function 'init_aio_state':
block-qcow.c:104:18: warning: unused variable 'bs' [-Wunused-variable]
block-qcow.c:103:9: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_open':
block-qcow.c:868:10: warning: unused variable 'len' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_queue_read':
block-qcow.c:987:19: warning: unused variable 'prv' [-Wunused-variable]
block-qcow.c:985:36: warning: unused variable 'i' [-Wunused-variable]
block-qcow.c:985:6: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_queue_write':
block-qcow.c:1057:19: warning: unused variable 'prv' [-Wunused-variable]
block-qcow.c:1056:16: warning: unused variable 'cb' [-Wunused-variable]
block-qcow.c:1054:36: warning: unused variable 'i' [-Wunused-variable]
block-qcow.c:1054:6: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'qcow_create':
block-qcow.c:1181:21: warning: unused variable 'adjust' [-Wunused-variable]
--
block-remus.c: In function 'ramdisk_start_flush':
block-remus.c:581:19: warning: unused variable 'batchlen' [-Wunused-variable]
block-remus.c:581:9: warning: unused variable 'j' [-Wunused-variable]
block-remus.c:580:6: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c:578:12: warning: unused variable 'key' [-Wunused-variable]
block-remus.c: In function 'primary_do_connect':
block-remus.c:749:6: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c: In function 'remus_client_event':
block-remus.c:1031:6: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c: In function 'backup_queue_read':
block-remus.c:1154:6: warning: unused variable 'i' [-Wunused-variable]
block-remus.c: In function 'backup_queue_write':
block-remus.c:1171:24: warning: unused variable 's' [-Wunused-variable]
block-remus.c: In function 'backup_start':
block-remus.c:1186:6: warning: unused variable 'fd' [-Wunused-variable]
block-remus.c: In function 'server_do_wreq':
block-remus.c:1203:11: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c:1201:24: warning: unused variable 'twreq' [-Wunused-variable]
block-remus.c: In function 'get_args':
block-remus.c:1433:9: warning: unused variable 'ipver' [-Wunused-variable]
block-remus.c:1432:9: warning: unused variable 'addr' [-Wunused-variable]
--
td.c: In function 'td_coalesce':
td.c:360:15: warning: unused variable 'pname' [-Wunused-variable]
td.c: In function 'td_set_field':
td.c:548:11: warning: unused variable 'i' [-Wunused-variable]
td.c:548:6: warning: unused variable 'ret' [-Wunused-variable]
--
tapdisk-client.c: In function 'writelog_map':
tapdisk-client.c:244:9: warning: unused variable 'shm' [-Wunused-variable]
--
tapdisk-stream.c: In function 'main':
tapdisk-stream.c:550:21: warning: unused variable 'info' [-Wunused-variable]
--
tapdisk-diff.c: In function 'tapdisk_stream_enqueue2':
tapdisk-diff.c:469:9: warning: unused variable 'blk' [-Wunused-variable]
tapdisk-diff.c:469:6: warning: unused variable 'i' [-Wunused-variable]
tapdisk-diff.c: In function 'main':
tapdisk-diff.c:720:21: warning: unused variable 'info' [-Wunused-variable]
--
lock.c: In function 'main':
lock.c:962:13: warning: unused variable 'dlock' [-Wunused-variable]
--
img2qcow.c: In function 'print_bytes':
img2qcow.c:84:7: warning: unused variable 'i' [-Wunused-variable]
img2qcow.c: In function 'get_image_info':
img2qcow.c:117:17: warning: unused variable 'statBuf' [-Wunused-variable]
img2qcow.c:116:16: warning: unused variable 'total_size' [-Wunused-variable]
img2qcow.c:115:7: warning: unused variable 'size' [-Wunused-variable]
img2qcow.c: In function 'main':
img2qcow.c:167:17: warning: unused variable 'timeout' [-Wunused-variable]
img2qcow.c: At top level:
img2qcow.c:73:17: warning: 'read_idx' defined but not used [-Wunused-variable]
img2qcow.c:76:27: warning: 'written' defined but not used [-Wunused-variable]
--
qcow2raw.c: In function 'print_bytes':
qcow2raw.c:90:7: warning: unused variable 'i' [-Wunused-variable]
qcow2raw.c: In function 'send_read_responses':
qcow2raw.c:147:6: warning: unused variable 'ret' [-Wunused-variable]
qcow2raw.c: In function 'main':
qcow2raw.c:201:24: warning: unused variable 'input' [-Wunused-variable]
qcow2raw.c:201:20: warning: unused variable 'len' [-Wunused-variable]
qcow2raw.c: At top level:
qcow2raw.c:74:17: warning: 'read_idx' defined but not used [-Wunused-variable]
--
tap-ctl-list.c: In function 'tap_ctl_alloc_list':
tap-ctl-list.c:116:22: warning: unused variable 'entry' [-Wunused-variable]
tap-ctl-list.c: In function '_tap_ctl_find_tapdisks':
tap-ctl-list.c:274:7: warning: unused variable 'n' [-Wunused-variable]
--
tap-ctl-spawn.c: In function '__tap_ctl_spawn':
tap-ctl-spawn.c:42:6: warning: unused variable 'err' [-Wunused-variable]
--
tap-ctl-check.c: In function 'tap_ctl_check':
tap-ctl-check.c:68:8: warning: unused variable 'uid' [-Wunused-variable]
--
tap-ctl-list.c: In function 'tap_ctl_alloc_list':
tap-ctl-list.c:116:22: warning: unused variable 'entry' [-Wunused-variable]
tap-ctl-list.c: In function '_tap_ctl_find_tapdisks':
tap-ctl-list.c:274:7: warning: unused variable 'n' [-Wunused-variable]
--
tap-ctl-spawn.c: In function '__tap_ctl_spawn':
tap-ctl-spawn.c:42:6: warning: unused variable 'err' [-Wunused-variable]
--
tap-ctl-check.c: In function 'tap_ctl_check':
tap-ctl-check.c:68:8: warning: unused variable 'uid' [-Wunused-variable]

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c
+++ b/tools/blktap/drivers/blktapctrl.c
@@ -254,7 +254,7 @@ static int qemu_instance_has_disks(pid_t
 static int del_disktype(blkif_t *blkif)
 {
 	driver_list_entry_t *entry, **pprev;
-	int type = blkif->drivertype, count = 0, close = 0;
+	int type = blkif->drivertype;
 
 	if (type > MAX_DISK_TYPES)
 		return 1;
@@ -297,8 +297,7 @@ static int write_msg(int fd, int msgtype
 	int msglen, len, ret;
 	fd_set writefds;
 	struct timeval timeout;
-	image_t *image, *img;
-	uint32_t seed;
+	image_t *image;
 
 	blkif = (blkif_t *)ptr;
 	blk = blkif->info;
@@ -407,8 +406,8 @@ static int read_msg(int fd, int msgtype,
 	blkif_info_t *blk;
 	msg_hdr_t *msg;
 	msg_pid_t *msg_pid;
-	char *p, *buf;
-	int msglen = MSG_SIZE, len, ret;
+	char *buf;
+	int msglen = MSG_SIZE, ret;
 	fd_set readfds;
 	struct timeval timeout;
 	image_t *image, *img;
@@ -652,8 +651,8 @@ fail:
 static int blktapctrl_new_blkif(blkif_t *blkif)
 {
 	blkif_info_t *blk;
-	int major, minor, fd_read, fd_write, type, new;
-	char *rdctldev, *wrctldev, *ptr;
+	int major, minor, type;
+	char *ptr;
 	image_t *image;
 	blkif_t *exist = NULL;
 	static uint16_t next_cookie = 0;
@@ -761,8 +760,6 @@ int open_ctrl_socket(char *devname)
 {
 	int ret;
 	int ipc_fd;
-	fd_set socks;
-	struct timeval timeout;
 
 	if (mkdir(BLKTAP_CTRL_DIR, 0755) == 0)
 		DPRINTF("Created %s directory\n", BLKTAP_CTRL_DIR);
@@ -830,9 +827,7 @@ static void write_pidfile(long pid)
 
 int main(int argc, char *argv[])
 {
-	char *devname;
-	tapdev_info_t *ctlinfo;
-	int tap_pfd, store_pfd, xs_fd, ret, timeout, pfd_count, count=0;
+	int tap_pfd, store_pfd, ret, timeout, pfd_count, count=0;
 	struct xs_handle *h;
 	struct pollfd  pfd[NUM_POLL_FDS];
 	pid_t process;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-aio.c
--- a/tools/blktap/drivers/block-aio.c
+++ b/tools/blktap/drivers/block-aio.c
@@ -62,9 +62,6 @@ struct tdaio_state {
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -120,7 +117,7 @@ static inline void init_fds(struct disk_
 /* Open the disk file and initialize aio state. */
 static int tdaio_open (struct disk_driver *dd, const char *name, td_flag_t flags)
 {
-	int i, fd, ret = 0, o_flags;
+	int fd, ret = 0, o_flags;
 	struct td_state    *s   = dd->td_state;
 	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-qcow.c
--- a/tools/blktap/drivers/block-qcow.c
+++ b/tools/blktap/drivers/block-qcow.c
@@ -722,7 +722,7 @@ static inline void init_fds(struct disk_
 /* Open the disk file and initialize qcow state. */
 static int tdqcow_open (struct disk_driver *dd, const char *name, td_flag_t flags)
 {
-	int fd, len, i, shift, ret, size, l1_table_size, o_flags, l1_table_block;
+	int fd, i, shift, ret, size, l1_table_size, o_flags, l1_table_block;
 	int max_aio_reqs;
 	struct td_state     *bs = dd->td_state;
 	struct tdqcow_state *s  = (struct tdqcow_state *)dd->private;
@@ -1009,7 +1009,7 @@ static int tdqcow_queue_write(struct dis
 		       int id, void *private)
 {
 	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	int ret = 0, index_in_cluster, n, i;
+	int index_in_cluster, n, i;
 	uint64_t cluster_offset, sec, nr_secs;
 
 	sec     = sector;
@@ -1099,7 +1099,7 @@ static int tdqcow_close(struct disk_driv
 
 static int tdqcow_do_callbacks(struct disk_driver *dd, int sid)
 {
-        int ret, i, nr_events, rsp = 0,*ptr;
+        int i, nr_events, rsp = 0;
         struct io_event *ep;
         struct tdqcow_state *prv = (struct tdqcow_state *)dd->private;
 
@@ -1143,7 +1143,7 @@ int qcow_create(const char *filename, ui
 		const char *backing_file, int sparse)
 {
 	int fd, header_size, backing_filename_len, l1_size, i;
-	int shift, length, adjust, flags = 0, ret = 0;
+	int shift, length, flags = 0, ret = 0;
 	QCowHeader header;
 	QCowHeader_ext exthdr;
 	char backing_filename[PATH_MAX], *ptr;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-qcow2.c
--- a/tools/blktap/drivers/block-qcow2.c
+++ b/tools/blktap/drivers/block-qcow2.c
@@ -952,7 +952,10 @@ static int qcow_read(struct disk_driver 
 		uint8_t *buf, int nb_sectors)
 {
 	BDRVQcowState *s = bs->private;
-	int ret, index_in_cluster, n, n1;
+	int ret, index_in_cluster, n;
+#if 0
+	int n1;
+#endif
 	uint64_t cluster_offset;
 
 	while (nb_sectors > 0) {
@@ -1145,8 +1148,6 @@ static int qcow_queue_write(struct disk_
 	BDRVQcowState *s = bs->private;
 	int i, n, index_in_cluster;
 	uint64_t cluster_offset;
-	const uint8_t *src_buf;
-		
 	
 	/*Check we can get a lock*/
 	for (i = 0; i < nb_sectors; i++) 
@@ -1861,7 +1862,7 @@ static int qcow_do_callbacks(struct disk
 
 static int qcow_do_callbacks(struct disk_driver *dd, int sid)
 {
-	int ret, i, nr_events, rsp = 0,*ptr;
+	int i, nr_events, rsp = 0;
 	struct io_event *ep;
 	struct BDRVQcowState *prv = (struct BDRVQcowState*)dd->private;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-ram.c
--- a/tools/blktap/drivers/block-ram.c
+++ b/tools/blktap/drivers/block-ram.c
@@ -64,9 +64,6 @@ struct tdram_state {
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -225,7 +222,6 @@ static int tdram_queue_read(struct disk_
 		      int id, void *private)
 {
 	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
 	int      size    = nb_sectors * s->sector_size;
 	uint64_t offset  = sector * (uint64_t)s->sector_size;
 
@@ -239,7 +235,6 @@ static int tdram_queue_write(struct disk
 		      int id, void *private)
 {
 	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
 	int      size    = nb_sectors * s->sector_size;
 	uint64_t offset  = sector * (uint64_t)s->sector_size;
 	
@@ -257,8 +252,6 @@ static int tdram_submit(struct disk_driv
 
 static int tdram_close(struct disk_driver *dd)
 {
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	
 	connections--;
 	
 	return 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-sync.c
--- a/tools/blktap/drivers/block-sync.c
+++ b/tools/blktap/drivers/block-sync.c
@@ -54,9 +54,6 @@ struct tdsync_state {
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -111,7 +108,7 @@ static inline void init_fds(struct disk_
 /* Open the disk file and initialize aio state. */
 static int tdsync_open (struct disk_driver *dd, const char *name, td_flag_t flags)
 {
-	int i, fd, ret = 0, o_flags;
+	int fd, ret = 0, o_flags;
 	struct td_state     *s   = dd->td_state;
 	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
 	
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/img2qcow.c
--- a/tools/blktap/drivers/img2qcow.c
+++ b/tools/blktap/drivers/img2qcow.c
@@ -63,7 +63,7 @@ static char output[25];
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -102,9 +102,6 @@ static inline void LOCAL_FD_SET(fd_set *
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/qcow2raw.c
--- a/tools/blktap/drivers/qcow2raw.c
+++ b/tools/blktap/drivers/qcow2raw.c
@@ -67,7 +67,7 @@ static char output[25];
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -148,7 +148,7 @@ static int send_read_responses(struct di
 
 int main(int argc, char *argv[])
 {
-	int ret = -1, fd, len,input;
+	int ret = -1, fd;
 	uint64_t size;
 	fd_set readfds;
 	struct timeval timeout;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/tapaio.c
--- a/tools/blktap/drivers/tapaio.c
+++ b/tools/blktap/drivers/tapaio.c
@@ -183,7 +183,6 @@ int tap_aio_init(tap_aio_context_t *ctx,
 		int max_aio_reqs)
 {
 	int i, ret;
-	long ioidx;
 
 	ctx->iocb_list = NULL;
 	ctx->pending_aio = NULL;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/tapdisk.c
--- a/tools/blktap/drivers/tapdisk.c
+++ b/tools/blktap/drivers/tapdisk.c
@@ -62,7 +62,9 @@ static void usage(void)
 
 static void daemonize(void)
 {
+#if 0
 	int i;
+#endif
 
 	if (getppid()==1) return; /* already a daemon */
 	if (fork() != 0) exit(0);
@@ -154,7 +156,6 @@ static inline int LOCAL_FD_SET(fd_set *r
 static inline fd_list_entry_t *add_fd_entry(int tap_fd, struct td_state *s)
 {
 	fd_list_entry_t **pprev, *entry;
-	int i;
 
 	DPRINTF("Adding fd_list_entry\n");
 
@@ -369,7 +370,7 @@ static int open_disk(struct td_state *s,
 
 static int read_msg(char *buf)
 {
-	int length, len, msglen, tap_fd, *io_fd;
+	int length, len, msglen;
 	char *ptr, *path;
 	image_t *img;
 	msg_hdr_t *msg;
@@ -593,7 +594,7 @@ int do_cow_read(struct disk_driver *dd, 
 		int sidx, uint64_t sector, int nr_secs)
 {
 	char *page;
-	int ret, early;
+	int ret;
 	uint64_t seg_start, seg_end;
 	struct td_state  *s = dd->td_state;
 	tapdev_info_t *info = s->ring_info;
@@ -626,12 +627,11 @@ int do_cow_read(struct disk_driver *dd, 
 
 static void get_io_request(struct td_state *s)
 {
-	RING_IDX          rp, rc, j, i;
+	RING_IDX          rp, j, i;
 	blkif_request_t  *req;
 	int idx, nsects, ret;
 	uint64_t sector_nr;
 	char *page;
-	int early = 0; /* count early completions */
 	struct disk_driver *dd = s->disks;
 	struct tap_disk *drv   = dd->drv;
 	blkif_t *blkif = s->blkif;
@@ -644,7 +644,7 @@ static void get_io_request(struct td_sta
 	xen_rmb();
 	for (j = info->fe_ring.req_cons; j != rp; j++)
 	{
-		int done = 0, start_seg = 0; 
+		int start_seg = 0; 
 
 		req = NULL;
 		req = RING_GET_REQUEST(&info->fe_ring, j);
@@ -764,9 +764,9 @@ static void get_io_request(struct td_sta
 
 int main(int argc, char *argv[])
 {
-	int len, msglen, ret;
-	char *p, *buf;
-	fd_set readfds, writefds;	
+	int ret;
+	char *buf;
+	fd_set readfds;	
 	fd_list_entry_t *ptr;
 	struct td_state *s;
 	char openlogbuf[128];
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/lib/xenbus.c
--- a/tools/blktap/lib/xenbus.c
+++ b/tools/blktap/lib/xenbus.c
@@ -321,8 +321,8 @@ static int check_image(struct xs_handle 
 static void ueblktap_setup(struct xs_handle *h, char *bepath)
 {
 	struct backend_info *be;
-	char *path = NULL, *p,*dev;
-	int len, er, deverr;
+	char *path = NULL, *p;
+	int er, deverr;
 	long int pdev = 0, handle;
 	blkif_info_t *blk;
 	const char* errmsg = NULL;
@@ -449,9 +449,8 @@ static void ueblktap_probe(struct xs_han
 			   const char *bepath_im)
 {
 	struct backend_info *be = NULL;
-	char *frontend = NULL, *bepath = NULL, *p;
+	char *frontend = NULL, *bepath = NULL;
 	int er, len;
-	blkif_t *blkif;
 	
 	
 	bepath = strdup(bepath_im);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -60,8 +60,8 @@ int xs_gather(struct xs_handle *xs, cons
 {
 	va_list ap;
 	const char *name;
-	char *path, **e;
-	int ret = 0, num,i;
+	char *path;
+	int ret = 0;
 	unsigned int len;
 	xs_transaction_t xth;
 
@@ -213,7 +213,7 @@ int convert_dev_name_to_num(char *name) 
 	char *p;
 	const char *ptr;
 	int majors[10] = {3,22,33,34,56,57,88,89,90,91};
-	int maj,i,ret = 0;
+	int i,ret = 0;
 	const char p_sd[] = "/dev/sd";
 	const char p_hd[] = "/dev/hd";
 	const char p_xvd[] = "/dev/xvd";
@@ -341,7 +341,6 @@ int xs_fire_next_watch(struct xs_handle 
 	char *token;
 	char *node = NULL;
 	struct xenbus_watch *w;
-	int er;
 	unsigned int num;
 	
 	res = xs_read_watch(h, &num);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/control/tap-ctl-check.c
--- a/tools/blktap2/control/tap-ctl-check.c
+++ b/tools/blktap2/control/tap-ctl-check.c
@@ -65,7 +65,6 @@ int
 tap_ctl_check(const char **msg)
 {
 	int err;
-	uid_t uid;
 
 	err = tap_ctl_check_blktap(msg);
 	if (err)
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/control/tap-ctl-list.c
--- a/tools/blktap2/control/tap-ctl-list.c
+++ b/tools/blktap2/control/tap-ctl-list.c
@@ -125,8 +125,6 @@ tap_ctl_alloc_list(int n)
 	memset(list, 0, size);
 
 	for (i = 0; i < n; ++i) {
-		tap_list_t *entry;
-
 		entry = malloc(sizeof(tap_list_t));
 		if (!entry)
 			goto fail;
@@ -271,7 +269,6 @@ _tap_ctl_find_tapdisks(struct tapdisk **
 
 	for (i = 0; i < glbuf.gl_pathc; ++i) {
 		struct tapdisk *tap;
-		int n;
 
 		tap = &tapv[n_taps];
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/control/tap-ctl-spawn.c
--- a/tools/blktap2/control/tap-ctl-spawn.c
+++ b/tools/blktap2/control/tap-ctl-spawn.c
@@ -39,7 +39,7 @@
 static pid_t
 __tap_ctl_spawn(int *readfd)
 {
-	int err, child, channel[2];
+	int child, channel[2];
 	char *tapdisk;
 
 	if (pipe(channel)) {
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-aio.c
--- a/tools/blktap2/drivers/block-aio.c
+++ b/tools/blktap2/drivers/block-aio.c
@@ -64,9 +64,6 @@ struct tdaio_state {
 static int tdaio_get_image_info(int fd, td_disk_info_t *info)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-log.c
--- a/tools/blktap2/drivers/block-log.c
+++ b/tools/blktap2/drivers/block-log.c
@@ -217,7 +217,7 @@ static char* ctl_makepath(const char* na
 
 static int shmem_open(struct tdlog_state* s, const char* name)
 {
-  int i, l, fd;
+  int fd;
 
   /* device name -> path */
   if (asprintf(&s->shmpath, "/log_%s.wlog", name) < 0) {
@@ -486,7 +486,6 @@ static int ctl_kick(struct tdlog_state* 
   log_request_t req;
 
   /* XXX testing */
-  RING_IDX rspstart, rspend;
   log_response_t rsp;
   struct log_ctlmsg msg;
   int rc;
@@ -557,7 +556,7 @@ static void ctl_request(event_id_t id, c
 {
   struct tdlog_state* s = (struct tdlog_state*)private;
   struct log_ctlmsg msg;
-  int rc, i, fd = -1;
+  int rc, fd = -1;
 
   fd = ctl_find_connection(s, id);
   if (fd == -1)
@@ -635,7 +634,6 @@ static void tdlog_queue_read(td_driver_t
 static void tdlog_queue_write(td_driver_t* driver, td_request_t treq)
 {
   struct tdlog_state* s = (struct tdlog_state*)driver->data;
-  int rc;
 
   writelog_set(s, treq.sec, treq.secs);
   td_forward_request(treq);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-qcow.c
--- a/tools/blktap2/drivers/block-qcow.c
+++ b/tools/blktap2/drivers/block-qcow.c
@@ -84,7 +84,6 @@ static int decompress_cluster(struct tdq
 
 uint32_t gen_cksum(char *ptr, int len)
 {
-  int i;
   uint32_t md[4];
 
   /* Generate checksum */
@@ -101,8 +100,7 @@ static void free_aio_state(struct tdqcow
 
 static int init_aio_state(td_driver_t *driver)
 {
-	int i, ret;
-	td_disk_info_t *bs = &(driver->info);
+	int i;
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
 	
         // A segment (i.e. a page) can span multiple clusters
@@ -866,7 +864,7 @@ out:
 /* Open the disk file and initialize qcow state. */
 int tdqcow_open (td_driver_t *driver, const char *name, td_flag_t flags)
 {
-	int fd, len, i, ret, size, o_flags;
+	int fd, i, ret, size, o_flags;
 	td_disk_info_t *bs = &(driver->info);
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
 	QCowHeader header;
@@ -983,9 +981,8 @@ fail:
 void tdqcow_queue_read(td_driver_t *driver, td_request_t treq)
 {
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
-	int ret = 0, index_in_cluster, n, i;
+	int index_in_cluster, n, i;
 	uint64_t cluster_offset, sector, nb_sectors;
-	struct qcow_prv* prv;
 	td_request_t clone = treq;
 	char* buf = treq.buf;
 
@@ -1007,7 +1004,6 @@ void tdqcow_queue_read(td_driver_t *driv
 		}
 		
 		if(!cluster_offset) {
-            int i;
             /* Forward entire request if possible. */
             for(i=0; i<nb_sectors; i++)
                 if(get_cluster_offset(s, (sector+i) << 9, 0, 0, 0, 0))
@@ -1052,10 +1048,8 @@ done:
 void tdqcow_queue_write(td_driver_t *driver, td_request_t treq)
 {
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
-	int ret = 0, index_in_cluster, n, i;
+	int index_in_cluster, n;
 	uint64_t cluster_offset, sector, nb_sectors;
-	td_callback_t cb;
-	struct qcow_prv* prv;
 	char* buf = treq.buf;
 	td_request_t clone=treq;
 
@@ -1179,7 +1173,7 @@ int qcow_create(const char *filename, ui
 		const char *backing_file, int sparse)
 {
 	int fd, header_size, backing_filename_len, l1_size, i;
-	int shift, length, adjust, flags = 0, ret = 0;
+	int shift, length, flags = 0, ret = 0;
 	QCowHeader header;
 	QCowHeader_ext exthdr;
 	char backing_filename[PATH_MAX], *ptr;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-ram.c
--- a/tools/blktap2/drivers/block-ram.c
+++ b/tools/blktap2/drivers/block-ram.c
@@ -55,9 +55,6 @@ struct tdram_state {
 static int get_image_info(int fd, td_disk_info_t *info)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -200,7 +197,6 @@ done:
 
 void tdram_queue_read(td_driver_t *driver, td_request_t treq)
 {
-	struct tdram_state *prv = (struct tdram_state *)driver->data;
 	int      size    = treq.secs * driver->info.sector_size;
 	uint64_t offset  = treq.sec * (uint64_t)driver->info.sector_size;
 
@@ -211,7 +207,6 @@ void tdram_queue_read(td_driver_t *drive
 
 void tdram_queue_write(td_driver_t *driver, td_request_t treq)
 {
-	struct tdram_state *prv = (struct tdram_state *)driver->data;
 	int      size    = treq.secs * driver->info.sector_size;
 	uint64_t offset  = treq.sec * (uint64_t)driver->info.sector_size;
 	
@@ -224,8 +219,6 @@ void tdram_queue_write(td_driver_t *driv
 
 int tdram_close(td_driver_t *driver)
 {
-	struct tdram_state *prv = (struct tdram_state *)driver->data;
-	
 	connections--;
 	
 	return 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-remus.c
--- a/tools/blktap2/drivers/block-remus.c
+++ b/tools/blktap2/drivers/block-remus.c
@@ -575,10 +575,8 @@ static int ramdisk_flush(td_driver_t *dr
 static int ramdisk_start_flush(td_driver_t *driver)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	uint64_t* key;
 	char* buf;
-	int rc = 0;
-	int i, j, count, batchlen;
+	int i, count;
 	uint64_t* sectors;
 
 	if (!hashtable_count(s->ramdisk.h)) {
@@ -746,7 +744,6 @@ static int primary_do_connect(struct tdr
 {
 	event_id_t id;
 	int fd;
-	int rc;
 	int flags;
 
 	RPRINTF("client connecting to %s:%d...\n", inet_ntoa(state->sa.sin_addr), ntohs(state->sa.sin_port));
@@ -1028,7 +1025,6 @@ static void remus_client_event(event_id_
 {
 	struct tdremus_state *s = (struct tdremus_state *)private;
 	char req[5];
-	int rc;
 
 	if (mread(s->stream_fd.fd, req, sizeof(req) - 1) < 0) {
 		/* replication stream closed or otherwise broken (timeout, reset, &c) */
@@ -1151,7 +1147,6 @@ static inline int server_writes_inflight
 void backup_queue_read(td_driver_t *driver, td_request_t treq)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	int i;
 	if(!remus_image)
 		remus_image = treq.image;
 	
@@ -1168,8 +1163,6 @@ void backup_queue_read(td_driver_t *driv
 /* see above */
 void backup_queue_write(td_driver_t *driver, td_request_t treq)
 {
-	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-
 	/* on a server write, we know the domain has failed over. we must change our
 	 * state to unprotected and then have the unprotected queue_write function
 	 * handle the write
@@ -1183,7 +1176,6 @@ void backup_queue_write(td_driver_t *dri
 static int backup_start(td_driver_t *driver)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	int fd;
 
 	if (ramdisk_start(driver) < 0)
 		return -1;
@@ -1198,9 +1190,8 @@ static int backup_start(td_driver_t *dri
 static int server_do_wreq(td_driver_t *driver)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	static tdremus_wire_t twreq;
 	char buf[4096];
-	int len, rc;
+	int len;
 
 	char header[sizeof(uint32_t) + sizeof(uint64_t)];
 	uint32_t *sectors = (uint32_t *) header;
@@ -1429,9 +1420,6 @@ static int get_args(td_driver_t *driver,
 	/* TODO: do something smarter here */
 	valid_addr = 0;
 	for(servinfo_itr = servinfo; servinfo_itr != NULL; servinfo_itr = servinfo_itr->ai_next) {
-		void *addr;
-		char *ipver;
-
 		if (servinfo_itr->ai_family == AF_INET) {
 			valid_addr = 1;
 			memset(&state->sa, 0, sizeof(state->sa));
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-vhd.c
--- a/tools/blktap2/drivers/block-vhd.c
+++ b/tools/blktap2/drivers/block-vhd.c
@@ -726,7 +726,6 @@ _vhd_close(td_driver_t *driver)
 {
 	int err;
 	struct vhd_state *s;
-	struct vhd_bitmap *bm;
 	
 	DBG(TLOG_WARN, "vhd_close\n");
 	s = (struct vhd_state *)driver->data;
@@ -772,8 +771,6 @@ int
 vhd_validate_parent(td_driver_t *child_driver,
 		    td_driver_t *parent_driver, td_flag_t flags)
 {
-	uint32_t status;
-	struct stat stats;
 	struct vhd_state *child  = (struct vhd_state *)child_driver->data;
 	struct vhd_state *parent;
 
@@ -789,24 +786,6 @@ vhd_validate_parent(td_driver_t *child_d
 
 	parent = (struct vhd_state *)parent_driver->data;
 
-	/* 
-	 * This check removed because of cases like:
-	 *   - parent VHD marked as 'hidden'
-	 *   - parent VHD modified during coalesce
-	 */
-	/*
-	if (stat(parent->vhd.file, &stats)) {
-		DPRINTF("ERROR stating parent file %s\n", parent->vhd.file);
-		return -errno;
-	}
-
-	if (child->hdr.prt_ts != vhd_time(stats.st_mtime)) {
-		DPRINTF("ERROR: parent file has been modified since "
-			"snapshot.  Child image no longer valid.\n");
-		return -EINVAL;
-	}
-	*/
-
 	if (vhd_uuid_compare(&child->vhd.header.prt_uuid, &parent->vhd.footer.uuid)) {
 		DPRINTF("ERROR: %s: %s, %s: parent uuid has changed since "
 			"snapshot.  Child image no longer valid.\n",
@@ -1380,7 +1359,6 @@ update_bat(struct vhd_state *s, uint32_t
 static int
 allocate_block(struct vhd_state *s, uint32_t blk)
 {
-	char *zeros;
 	int err, gap;
 	uint64_t offset, size;
 	struct vhd_bitmap *bm;
@@ -1860,7 +1838,7 @@ signal_completion(struct vhd_request *li
 static void
 start_new_bitmap_transaction(struct vhd_state *s, struct vhd_bitmap *bm)
 {
-	int i, error = 0;
+	int i;
 	struct vhd_transaction *tx;
 	struct vhd_request *r, *next;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/img2qcow.c
--- a/tools/blktap2/drivers/img2qcow.c
+++ b/tools/blktap2/drivers/img2qcow.c
@@ -70,10 +70,9 @@
 
 static int running = 1, complete = 0;
 static int returned_events = 0, submit_events = 0;
-static uint32_t read_idx = 0;
 td_driver_t *ddqcow;
 td_vbd_t* qcow_vbd;
-static uint64_t prev = 0, written = 0;
+static uint64_t prev = 0;
 static char output[(100/PROGRESS_QUANT) + 5];
 
 extern tapdisk_server_t server;
@@ -81,7 +80,7 @@ extern tapdisk_server_t server;
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -112,9 +111,6 @@ static void debug_output(uint64_t progre
 static int get_image_info(td_disk_info_t *driver, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 	uint64_t sector_size=DEFAULT_SECTOR_SIZE;
 
@@ -164,7 +160,6 @@ void send_responses(td_request_t treq, i
 int main(int argc, const char *argv[])
 {
         int ret = -1, fd, len, err;
-	struct timeval timeout;
 	uint64_t i;
 	char *buf;
 	td_request_t treq;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/io-optimize.c
--- a/tools/blktap2/drivers/io-optimize.c
+++ b/tools/blktap2/drivers/io-optimize.c
@@ -219,7 +219,6 @@ io_merge(struct opioctx *ctx, struct ioc
 {
 	int i, on_queue;
 	struct iocb *io, **q;
-	struct opio *ophead;
 	
 	if (!num)
 		return 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/lock.c
--- a/tools/blktap2/drivers/lock.c
+++ b/tools/blktap2/drivers/lock.c
@@ -959,7 +959,6 @@ static void usage(char *prg)
 int main(int argc, char *argv[])
 {
         int status = 0;
-        int dlock;
         char *ptr;
         int force;
         int readonly;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/qcow2raw.c
--- a/tools/blktap2/drivers/qcow2raw.c
+++ b/tools/blktap2/drivers/qcow2raw.c
@@ -71,7 +71,6 @@
 static int running = 1, complete = 0; 
 static int returned_read_events = 0, returned_write_events = 0;
 static int submit_events = 0;
-static uint32_t read_idx = 0;
 td_driver_t *ddqcow, *ddaio;
 td_vbd_t* qcow_vbd, *aio_vbd;
 static uint64_t prev = 0, written = 0;
@@ -87,7 +86,7 @@ struct request_info {
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -144,7 +143,6 @@ static void send_write_responses(td_requ
 
 static void send_read_responses(td_request_t treq, int err)
 {
-	int ret;
         struct request_info* req;
         td_vbd_request_t* vreq;
 
@@ -198,7 +196,7 @@ static void send_read_responses(td_reque
 
 int main(int argc, const char *argv[])
 {
-	int ret = -1, fd, len,input;
+	int ret = -1, fd;
 	uint64_t size;
 	struct timeval timeout;
 	uint64_t i;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-client.c
--- a/tools/blktap2/drivers/tapdisk-client.c
+++ b/tools/blktap2/drivers/tapdisk-client.c
@@ -241,7 +241,6 @@ static int ctl_clear_writes(int fd)
 static int writelog_map(struct writelog* wl)
 {
   int fd;
-  void* shm;
 
   if ((fd = shm_open(wl->shmpath, O_RDWR, 0750)) < 0) {
     BWPRINTF("could not open shared memory at %s: %s", wl->shmpath,
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-control.c
--- a/tools/blktap2/drivers/tapdisk-control.c
+++ b/tools/blktap2/drivers/tapdisk-control.c
@@ -89,7 +89,6 @@ static struct tapdisk_control_connection
 tapdisk_control_allocate_connection(int fd)
 {
 	struct tapdisk_control_connection *connection;
-	size_t sz;
 
 	connection = calloc(1, sizeof(*connection));
 	if (!connection) {
@@ -252,7 +251,7 @@ tapdisk_control_list(struct tapdisk_cont
 	td_vbd_t *vbd;
 	struct list_head *head;
 	tapdisk_message_t response;
-	int count, i;
+	int count;
 
 	memset(&response, 0, sizeof(response));
 	response.type = TAPDISK_MESSAGE_LIST_RSP;
@@ -313,8 +312,6 @@ tapdisk_control_attach_vbd(struct tapdis
 	tapdisk_message_t response;
 	char *devname;
 	td_vbd_t *vbd;
-	struct blktap2_params params;
-	image_t image;
 	int minor, err;
 
 	/*
@@ -758,7 +755,7 @@ tapdisk_control_mkdir(const char *dir)
 static int
 tapdisk_control_create_socket(char **socket_path)
 {
-	int err, flags;
+	int err;
 	struct sockaddr_un saddr;
 
 	err = tapdisk_control_mkdir(BLKTAP2_CONTROL_DIR);
@@ -829,8 +826,6 @@ fail:
 int
 tapdisk_control_open(char **path)
 {
-	int err;
-
 	tapdisk_control_initialize();
 
 	return tapdisk_control_create_socket(path);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-diff.c
--- a/tools/blktap2/drivers/tapdisk-diff.c
+++ b/tools/blktap2/drivers/tapdisk-diff.c
@@ -466,7 +466,6 @@ static void
 tapdisk_stream_enqueue2(void)
 {
 	td_vbd_t *vbd;
-	int i, blk;
 	struct tapdisk_stream_request *itr;
 	struct tapdisk_stream *s = &stream2;
 
@@ -717,7 +716,6 @@ main(int argc, char *argv[])
 {
 	int c, err, type1;
 	const char *arg1 = NULL, *arg2 = NULL;
-	const disk_info_t *info;
 	const char *path1;
 
 	err    = 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-filter.c
--- a/tools/blktap2/drivers/tapdisk-filter.c
+++ b/tools/blktap2/drivers/tapdisk-filter.c
@@ -156,7 +156,7 @@ static void
 check_data(struct tfilter *filter, int type, struct iocb *io)
 {
 	int rw;
-	uint64_t i, sec;
+	uint64_t i;
 
 	rw = (io->aio_lio_opcode == IO_CMD_PWRITE);
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-interface.c
--- a/tools/blktap2/drivers/tapdisk-interface.c
+++ b/tools/blktap2/drivers/tapdisk-interface.c
@@ -37,7 +37,6 @@
 int
 td_load(td_image_t *image)
 {
-	int err;
 	td_image_t *shared;
 	td_driver_t *driver;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-queue.c
--- a/tools/blktap2/drivers/tapdisk-queue.c
+++ b/tools/blktap2/drivers/tapdisk-queue.c
@@ -194,7 +194,6 @@ static int
 tapdisk_rwio_setup(struct tqueue *queue, int size)
 {
 	struct rwio *rwio = queue->tio_data;
-	int err;
 
 	rwio->aio_events = calloc(size, sizeof(struct io_event));
 	if (!rwio->aio_events)
@@ -474,7 +473,6 @@ static int
 tapdisk_lio_setup(struct tqueue *queue, int qlen)
 {
 	struct lio *lio = queue->tio_data;
-	size_t sz;
 	int err;
 
 	lio->event_id = -1;
@@ -608,7 +606,7 @@ int
 tapdisk_init_queue(struct tqueue *queue, int size,
 		   int drv, struct tfilter *filter)
 {
-	int i, err;
+	int err;
 
 	memset(queue, 0, sizeof(struct tqueue));
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-server.c
--- a/tools/blktap2/drivers/tapdisk-server.c
+++ b/tools/blktap2/drivers/tapdisk-server.c
@@ -180,7 +180,6 @@ tapdisk_server_submit_tiocbs(void)
 static void
 tapdisk_server_kick_responses(void)
 {
-	int n;
 	td_vbd_t *vbd, *tmp;
 
 	tapdisk_server_for_each_vbd(vbd, tmp)
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-stream.c
--- a/tools/blktap2/drivers/tapdisk-stream.c
+++ b/tools/blktap2/drivers/tapdisk-stream.c
@@ -547,7 +547,6 @@ main(int argc, char *argv[])
 {
 	int c, err, type;
 	const char *params;
-	const disk_info_t *info;
 	const char *path;
 	uint64_t count, skip;
 	struct tapdisk_stream stream;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-utils.c
--- a/tools/blktap2/drivers/tapdisk-utils.c
+++ b/tools/blktap2/drivers/tapdisk-utils.c
@@ -111,7 +111,6 @@ tapdisk_namedup(char **dup, const char *
 int
 tapdisk_get_image_size(int fd, uint64_t *_sectors, uint32_t *_sector_size)
 {
-	int ret;
 	struct stat stat;
 	uint64_t sectors;
 	uint64_t sector_size;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-vbd.c
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -199,7 +199,6 @@ static int
 tapdisk_vbd_add_block_cache(td_vbd_t *vbd)
 {
 	int err;
-	td_driver_t *driver;
 	td_image_t *cache, *image, *target, *tmp;
 
 	target = NULL;
@@ -313,7 +312,6 @@ tapdisk_vbd_open_level(td_vbd_t *vbd, st
 	int type, err;
 	td_image_t *image;
 	td_disk_id_t id;
-	td_driver_t *driver;
 
 	name    = params;
 	id.name = NULL;
@@ -386,7 +384,6 @@ __tapdisk_vbd_open_vdi(td_vbd_t *vbd, td
 	td_flag_t flags;
 	td_image_t *tmp;
 	td_vbd_driver_info_t *driver_info;
-	struct list_head *images;
 	td_disk_info_t *parent_info = NULL;
 
 	if (list_empty(&vbd->driver_stack))
@@ -1196,7 +1193,6 @@ __tapdisk_vbd_complete_td_request(td_vbd
 				  td_request_t treq, int res)
 {
 	int err;
-    td_image_t *image = treq.image;
 
 	err = (res <= 0 ? res : -res);
 	vbd->secs_pending  -= treq.secs;
@@ -1216,6 +1212,7 @@ __tapdisk_vbd_complete_td_request(td_vbd
 		}
 	} else {
 #ifdef MEMSHR
+		td_image_t *image = treq.image;
 		if (treq.op == TD_OP_READ
 		   && td_flag_test(image->flags, TD_OPEN_RDONLY)) {
 			share_tuple_t hnd = treq.memshr_hnd;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/td.c
--- a/tools/blktap2/drivers/td.c
+++ b/tools/blktap2/drivers/td.c
@@ -357,7 +357,7 @@ int
 td_coalesce(int type, int argc, char *argv[])
 {
 	int c, ret, cargc;
-	char *name, *pname, *cargv[3];
+	char *name, *cargv[3];
 
 	if (type != TD_TYPE_VHD) {
 		fprintf(stderr, "Cannot create snapshot of %s image type\n",
@@ -545,7 +545,7 @@ td_query(int type, int argc, char *argv[
 int
 td_set_field(int type, int argc, char *argv[])
 {
-	int ret, i, c, cargc;
+	int c, cargc;
 	struct vdi_field *field;
 	char *name, *value, *cargv[7];
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/lvm/lvm-util.c
--- a/tools/blktap2/lvm/lvm-util.c
+++ b/tools/blktap2/lvm/lvm-util.c
@@ -218,7 +218,7 @@ lvm_scan_lvs(struct vg *vg)
 		struct lv *lv;
 		struct lv_segment seg;
 		uint64_t size, seg_start;
-		char type[32], name[256], dev[256], devices[1024];
+		char type[32], name[256], devices[1024];
 
 		if (i >= vg->lv_cnt)
 			break;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/libvhd-journal.c
--- a/tools/blktap2/vhd/lib/libvhd-journal.c
+++ b/tools/blktap2/vhd/lib/libvhd-journal.c
@@ -357,7 +357,6 @@ vhd_journal_update(vhd_journal_t *j, off
 		   char *buf, size_t size, uint32_t type)
 {
 	int err;
-	off_t eof;
 	uint64_t *off, off_bak;
 	uint32_t *entries;
 	vhd_journal_entry_t entry;
@@ -611,7 +610,6 @@ static int
 vhd_journal_add_metadata(vhd_journal_t *j)
 {
 	int err;
-	off_t eof;
 	vhd_context_t *vhd;
 
 	vhd = &j->vhd;
@@ -1256,11 +1254,7 @@ fail:
 int
 vhd_journal_create(vhd_journal_t *j, const char *file, const char *jfile)
 {
-	char *buf;
-	int i, err;
-	size_t size;
-	off_t off;
-	struct stat stats;
+	int err;
 
 	memset(j, 0, sizeof(vhd_journal_t));
 	j->jfd = -1;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/libvhd.c
--- a/tools/blktap2/vhd/lib/libvhd.c
+++ b/tools/blktap2/vhd/lib/libvhd.c
@@ -1028,7 +1028,6 @@ out:
 int
 vhd_read_header(vhd_context_t *ctx, vhd_header_t *header)
 {
-	int err;
 	off_t off;
 
 	if (!vhd_type_dynamic(ctx)) {
@@ -2008,7 +2007,6 @@ out:
 int
 vhd_write_header(vhd_context_t *ctx, vhd_header_t *header)
 {
-	int err;
 	off_t off;
 
 	if (!vhd_type_dynamic(ctx))
@@ -2143,7 +2141,7 @@ vhd_write_bitmap(vhd_context_t *ctx, uin
 	int err;
 	off_t off;
 	uint64_t blk;
-	size_t secs, size;
+	size_t size;
 
 	if (!vhd_type_dynamic(ctx))
 		return -EINVAL;
@@ -3203,7 +3201,7 @@ __vhd_io_allocate_block(vhd_context_t *c
 	char *buf;
 	size_t size;
 	off_t off, max;
-	int i, err, gap, spp;
+	int err, gap, spp;
 
 	spp = getpagesize() >> VHD_SECTOR_SHIFT;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-check.c
--- a/tools/blktap2/vhd/lib/vhd-util-check.c
+++ b/tools/blktap2/vhd/lib/vhd-util-check.c
@@ -309,7 +309,6 @@ vhd_util_check_validate_parent(vhd_conte
 {
 	const char *msg;
 	vhd_context_t parent;
-	uint32_t status;
 
 	msg = NULL;
 
@@ -925,7 +924,6 @@ int
 vhd_util_check(int argc, char **argv)
 {
 	char *name;
-	vhd_context_t vhd;
 	int c, err, ignore, parents;
 
 	if (!argc || !argv) {
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-read.c
--- a/tools/blktap2/vhd/lib/vhd-util-read.c
+++ b/tools/blktap2/vhd/lib/vhd-util-read.c
@@ -70,7 +70,7 @@ vhd_print_header(vhd_context_t *vhd, vhd
 {
 	int err;
 	uint32_t  cksm;
-	char      uuid[39], time_str[26], cookie[9], out[512], *name;
+	char      uuid[39], time_str[26], cookie[9], *name;
 
 	printf("VHD Header Summary:\n-------------------\n");
 
@@ -105,7 +105,7 @@ static void
 vhd_print_footer(vhd_footer_t *f, int hex)
 {
 	uint64_t  c, h, s;
-	uint32_t  ff_maj, ff_min, cr_maj, cr_min, cksm, cksm_save;
+	uint32_t  ff_maj, ff_min, cr_maj, cr_min, cksm;
 	char      time_str[26], creator[5], uuid[39], cookie[9];
 
 	printf("VHD Footer Summary:\n-------------------\n");
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-resize.c
--- a/tools/blktap2/vhd/lib/vhd-util-resize.c
+++ b/tools/blktap2/vhd/lib/vhd-util-resize.c
@@ -877,7 +877,7 @@ vhd_add_bat_entries(vhd_journal_t *journ
 static int
 vhd_dynamic_grow(vhd_journal_t *journal, uint64_t secs)
 {
-	int i, err;
+	int err;
 	off_t eob, eom;
 	vhd_context_t *vhd;
 	vhd_block_t first_block;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-scan.c
--- a/tools/blktap2/vhd/lib/vhd-util-scan.c
+++ b/tools/blktap2/vhd/lib/vhd-util-scan.c
@@ -115,7 +115,6 @@ static int
 vhd_util_scan_pretty_allocate_list(int cnt)
 {
 	int i;
-	struct vhd_image *list;
 
 	memset(&scan, 0, sizeof(scan));
 
@@ -443,7 +442,6 @@ copy_name(char *dst, const char *src)
 static int
 vhd_util_scan_extract_volume_name(char *dst, const char *src)
 {
-	int err;
 	char copy[VHD_MAX_NAME_LEN], *name, *s, *c;
 
 	name = strrchr(src, '/');
@@ -510,7 +508,7 @@ found:
 static int
 vhd_util_scan_get_parent(vhd_context_t *vhd, struct vhd_image *image)
 {
-	int i, err;
+	int err;
 	vhd_parent_locator_t *loc;
 
 	if (!target_vhd(image->target->type)) {
@@ -678,7 +676,6 @@ out:
 static int
 vhd_util_scan_open_volume(vhd_context_t *vhd, struct vhd_image *image)
 {
-	int err;
 	struct target *target;
 
 	target = image->target;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-set-field.c
--- a/tools/blktap2/vhd/lib/vhd-util-set-field.c
+++ b/tools/blktap2/vhd/lib/vhd-util-set-field.c
@@ -37,7 +37,6 @@ vhd_util_set_field(int argc, char **argv
 {
 	long value;
 	int err, c;
-	off_t eof;
 	vhd_context_t vhd;
 	char *name, *field;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfe-0005jg-TK; Mon, 02 Apr 2012 20:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfc-0005do-FR
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:08 +0000
Received: from [85.158.143.35:29435] by server-3.bemta-4.messagelabs.com id
	10/8A-05853-8090A7F4; Mon, 02 Apr 2012 20:16:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1333397764!5076325!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzQwNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzQwNzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27550 invoked from network); 2 Apr 2012 20:16:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397764; l=59478;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=WOseuTVcdO8kxrVDupHTWoMR/OU=;
	b=RA9OwHOHqcwWHnGCgfDY5piJsHz0oYpjTRDhDSSH3lKpg48EsTPhOO0It5ZcM9ZhveE
	eiucj4Ythvg9H72UqM4KSdeWk/qiVdDGHHIjSJCYe/EwsO0+t+CwjMywnI2Z/NYkg2KqD
	Qsn7pml5pkG7sTpt7qH3IqfisjW+CiN0a+4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo5) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y07264o32JZ4cX ;
	Mon, 2 Apr 2012 22:16:03 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5F6FC18639;
	Mon,  2 Apr 2012 22:16:02 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 33af0a492bf7d2d682fe87f6a0a1501efc187508
Message-Id: <33af0a492bf7d2d682fe.1333397741@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:41 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18 of 18] tools/blktap+blktap2: fix build errors
 caused by Werror, remove unused variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397703 -7200
# Node ID 33af0a492bf7d2d682fe87f6a0a1501efc187508
# Parent  a85817bc44e57a805afffc3e91d5bf7051a361e0
tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables

-O2 -Wall -Werror triggers these warnings below.
The patch removes all listed local variables, a few static arrays in
header files will be changed in another patch.

xenbus.c: In function 'ueblktap_setup':
xenbus.c:325:6: warning: unused variable 'len' [-Wunused-variable]
xenbus.c:324:25: warning: unused variable 'dev' [-Wunused-variable]
xenbus.c: In function 'ueblktap_probe':
xenbus.c:453:11: warning: unused variable 'blkif' [-Wunused-variable]
xenbus.c:451:42: warning: unused variable 'p' [-Wunused-variable]
--
xs_api.c: In function 'xs_gather':
xs_api.c:64:19: warning: unused variable 'i' [-Wunused-variable]
xs_api.c:64:15: warning: unused variable 'num' [-Wunused-variable]
xs_api.c:63:16: warning: unused variable 'e' [-Wunused-variable]
xs_api.c: In function 'convert_dev_name_to_num':
xs_api.c:216:6: warning: unused variable 'maj' [-Wunused-variable]
xs_api.c: In function 'xs_fire_next_watch':
xs_api.c:344:6: warning: unused variable 'er' [-Wunused-variable]
--
blktapctrl.c: In function 'del_disktype':
blktapctrl.c:257:43: warning: unused variable 'close' [-Wunused-variable]
blktapctrl.c:257:32: warning: unused variable 'count' [-Wunused-variable]
blktapctrl.c: In function 'write_msg':
blktapctrl.c:301:11: warning: unused variable 'seed' [-Wunused-variable]
blktapctrl.c:300:19: warning: unused variable 'img' [-Wunused-variable]
blktapctrl.c: In function 'read_msg':
blktapctrl.c:411:25: warning: unused variable 'len' [-Wunused-variable]
blktapctrl.c:410:8: warning: unused variable 'p' [-Wunused-variable]
blktapctrl.c: In function 'blktapctrl_new_blkif':
blktapctrl.c:656:19: warning: unused variable 'wrctldev' [-Wunused-variable]
blktapctrl.c:656:8: warning: unused variable 'rdctldev' [-Wunused-variable]
blktapctrl.c:655:45: warning: unused variable 'new' [-Wunused-variable]
blktapctrl.c:655:29: warning: unused variable 'fd_write' [-Wunused-variable]
blktapctrl.c:655:20: warning: unused variable 'fd_read' [-Wunused-variable]
blktapctrl.c: In function 'open_ctrl_socket':
blktapctrl.c:765:17: warning: unused variable 'timeout' [-Wunused-variable]
blktapctrl.c:764:9: warning: unused variable 'socks' [-Wunused-variable]
blktapctrl.c: In function 'main':
blktapctrl.c:835:26: warning: unused variable 'xs_fd' [-Wunused-variable]
blktapctrl.c:834:17: warning: unused variable 'ctlinfo' [-Wunused-variable]
blktapctrl.c:833:8: warning: unused variable 'devname' [-Wunused-variable]
--
tapdisk.c: In function 'daemonize':
tapdisk.c:65:6: warning: unused variable 'i' [-Wunused-variable]
tapdisk.c: In function 'add_fd_entry':
tapdisk.c:157:6: warning: unused variable 'i' [-Wunused-variable]
tapdisk.c: In function 'read_msg':
tapdisk.c:372:36: warning: unused variable 'io_fd' [-Wunused-variable]
tapdisk.c:372:27: warning: unused variable 'tap_fd' [-Wunused-variable]
tapdisk.c: In function 'do_cow_read':
tapdisk.c:596:11: warning: unused variable 'early' [-Wunused-variable]
tapdisk.c: In function 'get_io_request':
tapdisk.c:647:7: warning: unused variable 'done' [-Wunused-variable]
tapdisk.c:634:6: warning: unused variable 'early' [-Wunused-variable]
tapdisk.c:629:24: warning: unused variable 'rc' [-Wunused-variable]
tapdisk.c: In function 'main':
tapdisk.c:769:18: warning: unused variable 'writefds' [-Wunused-variable]
tapdisk.c:768:8: warning: unused variable 'p' [-Wunused-variable]
tapdisk.c:767:11: warning: unused variable 'msglen' [-Wunused-variable]
tapdisk.c:767:6: warning: unused variable 'len' [-Wunused-variable]
--
block-aio.c: In function 'get_image_info':
block-aio.c:67:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-aio.c:66:16: warning: unused variable 'total_size' [-Wunused-variable]
block-aio.c:65:7: warning: unused variable 'size' [-Wunused-variable]
block-aio.c: In function 'tdaio_open':
block-aio.c:123:6: warning: unused variable 'i' [-Wunused-variable]
--
block-sync.c: In function 'get_image_info':
block-sync.c:59:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-sync.c:58:16: warning: unused variable 'total_size' [-Wunused-variable]
block-sync.c:57:7: warning: unused variable 'size' [-Wunused-variable]
block-sync.c: In function 'tdsync_open':
block-sync.c:114:6: warning: unused variable 'i' [-Wunused-variable]
--
block-ram.c: In function 'get_image_info':
block-ram.c:69:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-ram.c:68:16: warning: unused variable 'total_size' [-Wunused-variable]
block-ram.c:67:7: warning: unused variable 'size' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_read':
block-ram.c:228:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_write':
block-ram.c:242:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_close':
block-ram.c:260:22: warning: unused variable 'prv' [-Wunused-variable]
--
block-qcow.c: In function 'tdqcow_open':
block-qcow.c:725:10: warning: unused variable 'len' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_queue_write':
block-qcow.c:1012:6: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_do_callbacks':
block-qcow.c:1102:41: warning: unused variable 'ptr' [-Wunused-variable]
block-qcow.c:1102:13: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'qcow_create':
block-qcow.c:1146:21: warning: unused variable 'adjust' [-Wunused-variable]
--
block-qcow2.c: In function 'qcow_read':
block-qcow2.c:955:32: warning: unused variable 'n1' [-Wunused-variable]
block-qcow2.c: In function 'qcow_queue_write':
block-qcow2.c:1148:17: warning: unused variable 'src_buf' [-Wunused-variable]
block-qcow2.c: In function 'qcow_do_callbacks':
block-qcow2.c:1864:34: warning: unused variable 'ptr' [-Wunused-variable]
block-qcow2.c:1864:6: warning: unused variable 'ret' [-Wunused-variable]
--
tapaio.c: In function 'tap_aio_init':
tapaio.c:186:7: warning: unused variable 'ioidx' [-Wunused-variable]
--
img2qcow.c: In function 'print_bytes':
img2qcow.c:66:7: warning: unused variable 'i' [-Wunused-variable]
img2qcow.c: In function 'get_image_info':
img2qcow.c:107:17: warning: unused variable 'statBuf' [-Wunused-variable]
img2qcow.c:106:16: warning: unused variable 'total_size' [-Wunused-variable]
img2qcow.c:105:7: warning: unused variable 'size' [-Wunused-variable]
--
qcow2raw.c: In function 'print_bytes':
qcow2raw.c:70:7: warning: unused variable 'i' [-Wunused-variable]
qcow2raw.c: In function 'main':
qcow2raw.c:151:24: warning: unused variable 'input' [-Wunused-variable]
qcow2raw.c:151:20: warning: unused variable 'len' [-Wunused-variable]
--
lvm-util.c: In function 'lvm_scan_lvs':
lvm-util.c:221:29: warning: unused variable 'dev' [-Wunused-variable]
--
libvhd.c: In function 'vhd_read_header':
libvhd.c:1031:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_header':
libvhd.c:2011:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_bitmap':
libvhd.c:2146:9: warning: unused variable 'secs' [-Wunused-variable]
libvhd.c: In function '__vhd_io_allocate_block':
libvhd.c:3206:6: warning: unused variable 'i' [-Wunused-variable]
--
libvhd-journal.c: In function 'vhd_journal_update':
libvhd-journal.c:356:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_add_metadata':
libvhd-journal.c:610:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_create':
libvhd-journal.c:1259:14: warning: unused variable 'stats' [-Wunused-variable]
libvhd-journal.c:1258:8: warning: unused variable 'off' [-Wunused-variable]
libvhd-journal.c:1257:9: warning: unused variable 'size' [-Wunused-variable]
libvhd-journal.c:1256:6: warning: unused variable 'i' [-Wunused-variable]
libvhd-journal.c:1255:8: warning: unused variable 'buf' [-Wunused-variable]
--
vhd-util-read.c: In function 'vhd_print_header':
vhd-util-read.c:73:47: warning: unused variable 'out' [-Wunused-variable]
vhd-util-read.c: In function 'vhd_print_footer':
vhd-util-read.c:108:50: warning: unused variable 'cksm_save' [-Wunused-variable]
--
vhd-util-resize.c: In function 'vhd_dynamic_grow':
vhd-util-resize.c:880:6: warning: unused variable 'i' [-Wunused-variable]
--
vhd-util-set-field.c: In function 'vhd_util_set_field':
vhd-util-set-field.c:40:8: warning: unused variable 'eof' [-Wunused-variable]
--
vhd-util-scan.c: In function 'vhd_util_scan_pretty_allocate_list':
vhd-util-scan.c:118:20: warning: unused variable 'list' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_extract_volume_name':
vhd-util-scan.c:446:6: warning: unused variable 'err' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_get_parent':
vhd-util-scan.c:513:6: warning: unused variable 'i' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_open_volume':
vhd-util-scan.c:681:6: warning: unused variable 'err' [-Wunused-variable]
--
vhd-util-check.c: In function 'vhd_util_check_validate_parent':
vhd-util-check.c:312:11: warning: unused variable 'status' [-Wunused-variable]
vhd-util-check.c: In function 'vhd_util_check':
vhd-util-check.c:928:16: warning: unused variable 'vhd' [-Wunused-variable]
--
libvhd.c: In function 'vhd_read_header':
libvhd.c:1031:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_header':
libvhd.c:2011:6: warning: unused variable 'err' [-Wunused-variable]
libvhd.c: In function 'vhd_write_bitmap':
libvhd.c:2146:9: warning: unused variable 'secs' [-Wunused-variable]
libvhd.c: In function '__vhd_io_allocate_block':
libvhd.c:3206:6: warning: unused variable 'i' [-Wunused-variable]
--
libvhd-journal.c: In function 'vhd_journal_update':
libvhd-journal.c:356:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_add_metadata':
libvhd-journal.c:610:8: warning: unused variable 'eof' [-Wunused-variable]
libvhd-journal.c: In function 'vhd_journal_create':
libvhd-journal.c:1259:14: warning: unused variable 'stats' [-Wunused-variable]
libvhd-journal.c:1258:8: warning: unused variable 'off' [-Wunused-variable]
libvhd-journal.c:1257:9: warning: unused variable 'size' [-Wunused-variable]
libvhd-journal.c:1256:6: warning: unused variable 'i' [-Wunused-variable]
libvhd-journal.c:1255:8: warning: unused variable 'buf' [-Wunused-variable]
--
vhd-util-read.c: In function 'vhd_print_header':
vhd-util-read.c:73:47: warning: unused variable 'out' [-Wunused-variable]
vhd-util-read.c: In function 'vhd_print_footer':
vhd-util-read.c:108:50: warning: unused variable 'cksm_save' [-Wunused-variable]
--
vhd-util-resize.c: In function 'vhd_dynamic_grow':
vhd-util-resize.c:880:6: warning: unused variable 'i' [-Wunused-variable]
--
vhd-util-set-field.c: In function 'vhd_util_set_field':
vhd-util-set-field.c:40:8: warning: unused variable 'eof' [-Wunused-variable]
--
vhd-util-scan.c: In function 'vhd_util_scan_pretty_allocate_list':
vhd-util-scan.c:118:20: warning: unused variable 'list' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_extract_volume_name':
vhd-util-scan.c:446:6: warning: unused variable 'err' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_get_parent':
vhd-util-scan.c:513:6: warning: unused variable 'i' [-Wunused-variable]
vhd-util-scan.c: In function 'vhd_util_scan_open_volume':
vhd-util-scan.c:681:6: warning: unused variable 'err' [-Wunused-variable]
--
vhd-util-check.c: In function 'vhd_util_check_validate_parent':
vhd-util-check.c:312:11: warning: unused variable 'status' [-Wunused-variable]
vhd-util-check.c: In function 'vhd_util_check':
vhd-util-check.c:928:16: warning: unused variable 'vhd' [-Wunused-variable]
--
../../lvm/lvm-util.c: In function 'lvm_scan_lvs':
../../lvm/lvm-util.c:221:29: warning: unused variable 'dev' [-Wunused-variable]
--
tapdisk-vbd.c: In function 'tapdisk_vbd_add_block_cache':
tapdisk-vbd.c:202:15: warning: unused variable 'driver' [-Wunused-variable]
tapdisk-vbd.c: In function 'tapdisk_vbd_open_level':
tapdisk-vbd.c:316:15: warning: unused variable 'driver' [-Wunused-variable]
tapdisk-vbd.c: In function '__tapdisk_vbd_open_vdi':
tapdisk-vbd.c:389:20: warning: unused variable 'images' [-Wunused-variable]
tapdisk-vbd.c: In function '__tapdisk_vbd_complete_td_request':
tapdisk-vbd.c:1199:17: warning: unused variable 'image' [-Wunused-variable]
--
tapdisk-control.c: In function 'tapdisk_control_allocate_connection':
tapdisk-control.c:92:9: warning: unused variable 'sz' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_list':
tapdisk-control.c:255:13: warning: unused variable 'i' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_attach_vbd':
tapdisk-control.c:317:10: warning: unused variable 'image' [-Wunused-variable]
tapdisk-control.c:316:24: warning: unused variable 'params' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_create_socket':
tapdisk-control.c:761:11: warning: unused variable 'flags' [-Wunused-variable]
tapdisk-control.c: In function 'tapdisk_control_open':
tapdisk-control.c:832:6: warning: unused variable 'err' [-Wunused-variable]
--
tapdisk-interface.c: In function 'td_load':
tapdisk-interface.c:40:6: warning: unused variable 'err' [-Wunused-variable]
--
tapdisk-server.c: In function 'tapdisk_server_kick_responses':
tapdisk-server.c:183:6: warning: unused variable 'n' [-Wunused-variable]
--
tapdisk-queue.c: In function 'tapdisk_rwio_setup':
tapdisk-queue.c:197:6: warning: unused variable 'err' [-Wunused-variable]
tapdisk-queue.c: In function 'tapdisk_lio_setup':
tapdisk-queue.c:477:9: warning: unused variable 'sz' [-Wunused-variable]
tapdisk-queue.c: In function 'tapdisk_init_queue':
tapdisk-queue.c:611:6: warning: unused variable 'i' [-Wunused-variable]
--
tapdisk-filter.c: In function 'check_data':
tapdisk-filter.c:159:14: warning: unused variable 'sec' [-Wunused-variable]
--
tapdisk-utils.c: In function 'tapdisk_get_image_size':
tapdisk-utils.c:114:6: warning: unused variable 'ret' [-Wunused-variable]
--
io-optimize.c: In function 'io_merge':
io-optimize.c:222:15: warning: unused variable 'ophead' [-Wunused-variable]
--
block-aio.c: In function 'tdaio_get_image_info':
block-aio.c:69:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-aio.c:68:16: warning: unused variable 'total_size' [-Wunused-variable]
block-aio.c:67:7: warning: unused variable 'size' [-Wunused-variable]
--
block-ram.c: In function 'get_image_info':
block-ram.c:60:17: warning: unused variable 'statBuf' [-Wunused-variable]
block-ram.c:59:16: warning: unused variable 'total_size' [-Wunused-variable]
block-ram.c:58:7: warning: unused variable 'size' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_read':
block-ram.c:203:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_queue_write':
block-ram.c:214:22: warning: unused variable 'prv' [-Wunused-variable]
block-ram.c: In function 'tdram_close':
block-ram.c:227:22: warning: unused variable 'prv' [-Wunused-variable]
--
block-vhd.c: In function '_vhd_close':
block-vhd.c:729:21: warning: unused variable 'bm' [-Wunused-variable]
block-vhd.c: In function 'vhd_validate_parent':
block-vhd.c:776:14: warning: unused variable 'stats' [-Wunused-variable]
block-vhd.c:775:11: warning: unused variable 'status' [-Wunused-variable]
block-vhd.c: In function 'allocate_block':
block-vhd.c:1383:8: warning: unused variable 'zeros' [-Wunused-variable]
block-vhd.c: In function 'start_new_bitmap_transaction':
block-vhd.c:1863:9: warning: unused variable 'error' [-Wunused-variable]
--
block-log.c: In function 'shmem_open':
block-log.c:220:10: warning: unused variable 'l' [-Wunused-variable]
block-log.c:220:7: warning: unused variable 'i' [-Wunused-variable]
block-log.c: In function 'ctl_kick':
block-log.c:489:22: warning: unused variable 'rspend' [-Wunused-variable]
block-log.c:489:12: warning: unused variable 'rspstart' [-Wunused-variable]
block-log.c: In function 'ctl_request':
block-log.c:560:11: warning: unused variable 'i' [-Wunused-variable]
block-log.c: In function 'tdlog_queue_write':
block-log.c:638:7: warning: unused variable 'rc' [-Wunused-variable]
--
block-qcow.c: In function 'gen_cksum':
block-qcow.c:86:7: warning: unused variable 'i' [-Wunused-variable]
block-qcow.c: In function 'init_aio_state':
block-qcow.c:104:18: warning: unused variable 'bs' [-Wunused-variable]
block-qcow.c:103:9: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_open':
block-qcow.c:868:10: warning: unused variable 'len' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_queue_read':
block-qcow.c:987:19: warning: unused variable 'prv' [-Wunused-variable]
block-qcow.c:985:36: warning: unused variable 'i' [-Wunused-variable]
block-qcow.c:985:6: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'tdqcow_queue_write':
block-qcow.c:1057:19: warning: unused variable 'prv' [-Wunused-variable]
block-qcow.c:1056:16: warning: unused variable 'cb' [-Wunused-variable]
block-qcow.c:1054:36: warning: unused variable 'i' [-Wunused-variable]
block-qcow.c:1054:6: warning: unused variable 'ret' [-Wunused-variable]
block-qcow.c: In function 'qcow_create':
block-qcow.c:1181:21: warning: unused variable 'adjust' [-Wunused-variable]
--
block-remus.c: In function 'ramdisk_start_flush':
block-remus.c:581:19: warning: unused variable 'batchlen' [-Wunused-variable]
block-remus.c:581:9: warning: unused variable 'j' [-Wunused-variable]
block-remus.c:580:6: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c:578:12: warning: unused variable 'key' [-Wunused-variable]
block-remus.c: In function 'primary_do_connect':
block-remus.c:749:6: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c: In function 'remus_client_event':
block-remus.c:1031:6: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c: In function 'backup_queue_read':
block-remus.c:1154:6: warning: unused variable 'i' [-Wunused-variable]
block-remus.c: In function 'backup_queue_write':
block-remus.c:1171:24: warning: unused variable 's' [-Wunused-variable]
block-remus.c: In function 'backup_start':
block-remus.c:1186:6: warning: unused variable 'fd' [-Wunused-variable]
block-remus.c: In function 'server_do_wreq':
block-remus.c:1203:11: warning: unused variable 'rc' [-Wunused-variable]
block-remus.c:1201:24: warning: unused variable 'twreq' [-Wunused-variable]
block-remus.c: In function 'get_args':
block-remus.c:1433:9: warning: unused variable 'ipver' [-Wunused-variable]
block-remus.c:1432:9: warning: unused variable 'addr' [-Wunused-variable]
--
td.c: In function 'td_coalesce':
td.c:360:15: warning: unused variable 'pname' [-Wunused-variable]
td.c: In function 'td_set_field':
td.c:548:11: warning: unused variable 'i' [-Wunused-variable]
td.c:548:6: warning: unused variable 'ret' [-Wunused-variable]
--
tapdisk-client.c: In function 'writelog_map':
tapdisk-client.c:244:9: warning: unused variable 'shm' [-Wunused-variable]
--
tapdisk-stream.c: In function 'main':
tapdisk-stream.c:550:21: warning: unused variable 'info' [-Wunused-variable]
--
tapdisk-diff.c: In function 'tapdisk_stream_enqueue2':
tapdisk-diff.c:469:9: warning: unused variable 'blk' [-Wunused-variable]
tapdisk-diff.c:469:6: warning: unused variable 'i' [-Wunused-variable]
tapdisk-diff.c: In function 'main':
tapdisk-diff.c:720:21: warning: unused variable 'info' [-Wunused-variable]
--
lock.c: In function 'main':
lock.c:962:13: warning: unused variable 'dlock' [-Wunused-variable]
--
img2qcow.c: In function 'print_bytes':
img2qcow.c:84:7: warning: unused variable 'i' [-Wunused-variable]
img2qcow.c: In function 'get_image_info':
img2qcow.c:117:17: warning: unused variable 'statBuf' [-Wunused-variable]
img2qcow.c:116:16: warning: unused variable 'total_size' [-Wunused-variable]
img2qcow.c:115:7: warning: unused variable 'size' [-Wunused-variable]
img2qcow.c: In function 'main':
img2qcow.c:167:17: warning: unused variable 'timeout' [-Wunused-variable]
img2qcow.c: At top level:
img2qcow.c:73:17: warning: 'read_idx' defined but not used [-Wunused-variable]
img2qcow.c:76:27: warning: 'written' defined but not used [-Wunused-variable]
--
qcow2raw.c: In function 'print_bytes':
qcow2raw.c:90:7: warning: unused variable 'i' [-Wunused-variable]
qcow2raw.c: In function 'send_read_responses':
qcow2raw.c:147:6: warning: unused variable 'ret' [-Wunused-variable]
qcow2raw.c: In function 'main':
qcow2raw.c:201:24: warning: unused variable 'input' [-Wunused-variable]
qcow2raw.c:201:20: warning: unused variable 'len' [-Wunused-variable]
qcow2raw.c: At top level:
qcow2raw.c:74:17: warning: 'read_idx' defined but not used [-Wunused-variable]
--
tap-ctl-list.c: In function 'tap_ctl_alloc_list':
tap-ctl-list.c:116:22: warning: unused variable 'entry' [-Wunused-variable]
tap-ctl-list.c: In function '_tap_ctl_find_tapdisks':
tap-ctl-list.c:274:7: warning: unused variable 'n' [-Wunused-variable]
--
tap-ctl-spawn.c: In function '__tap_ctl_spawn':
tap-ctl-spawn.c:42:6: warning: unused variable 'err' [-Wunused-variable]
--
tap-ctl-check.c: In function 'tap_ctl_check':
tap-ctl-check.c:68:8: warning: unused variable 'uid' [-Wunused-variable]
--
tap-ctl-list.c: In function 'tap_ctl_alloc_list':
tap-ctl-list.c:116:22: warning: unused variable 'entry' [-Wunused-variable]
tap-ctl-list.c: In function '_tap_ctl_find_tapdisks':
tap-ctl-list.c:274:7: warning: unused variable 'n' [-Wunused-variable]
--
tap-ctl-spawn.c: In function '__tap_ctl_spawn':
tap-ctl-spawn.c:42:6: warning: unused variable 'err' [-Wunused-variable]
--
tap-ctl-check.c: In function 'tap_ctl_check':
tap-ctl-check.c:68:8: warning: unused variable 'uid' [-Wunused-variable]

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c
+++ b/tools/blktap/drivers/blktapctrl.c
@@ -254,7 +254,7 @@ static int qemu_instance_has_disks(pid_t
 static int del_disktype(blkif_t *blkif)
 {
 	driver_list_entry_t *entry, **pprev;
-	int type = blkif->drivertype, count = 0, close = 0;
+	int type = blkif->drivertype;
 
 	if (type > MAX_DISK_TYPES)
 		return 1;
@@ -297,8 +297,7 @@ static int write_msg(int fd, int msgtype
 	int msglen, len, ret;
 	fd_set writefds;
 	struct timeval timeout;
-	image_t *image, *img;
-	uint32_t seed;
+	image_t *image;
 
 	blkif = (blkif_t *)ptr;
 	blk = blkif->info;
@@ -407,8 +406,8 @@ static int read_msg(int fd, int msgtype,
 	blkif_info_t *blk;
 	msg_hdr_t *msg;
 	msg_pid_t *msg_pid;
-	char *p, *buf;
-	int msglen = MSG_SIZE, len, ret;
+	char *buf;
+	int msglen = MSG_SIZE, ret;
 	fd_set readfds;
 	struct timeval timeout;
 	image_t *image, *img;
@@ -652,8 +651,8 @@ fail:
 static int blktapctrl_new_blkif(blkif_t *blkif)
 {
 	blkif_info_t *blk;
-	int major, minor, fd_read, fd_write, type, new;
-	char *rdctldev, *wrctldev, *ptr;
+	int major, minor, type;
+	char *ptr;
 	image_t *image;
 	blkif_t *exist = NULL;
 	static uint16_t next_cookie = 0;
@@ -761,8 +760,6 @@ int open_ctrl_socket(char *devname)
 {
 	int ret;
 	int ipc_fd;
-	fd_set socks;
-	struct timeval timeout;
 
 	if (mkdir(BLKTAP_CTRL_DIR, 0755) == 0)
 		DPRINTF("Created %s directory\n", BLKTAP_CTRL_DIR);
@@ -830,9 +827,7 @@ static void write_pidfile(long pid)
 
 int main(int argc, char *argv[])
 {
-	char *devname;
-	tapdev_info_t *ctlinfo;
-	int tap_pfd, store_pfd, xs_fd, ret, timeout, pfd_count, count=0;
+	int tap_pfd, store_pfd, ret, timeout, pfd_count, count=0;
 	struct xs_handle *h;
 	struct pollfd  pfd[NUM_POLL_FDS];
 	pid_t process;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-aio.c
--- a/tools/blktap/drivers/block-aio.c
+++ b/tools/blktap/drivers/block-aio.c
@@ -62,9 +62,6 @@ struct tdaio_state {
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -120,7 +117,7 @@ static inline void init_fds(struct disk_
 /* Open the disk file and initialize aio state. */
 static int tdaio_open (struct disk_driver *dd, const char *name, td_flag_t flags)
 {
-	int i, fd, ret = 0, o_flags;
+	int fd, ret = 0, o_flags;
 	struct td_state    *s   = dd->td_state;
 	struct tdaio_state *prv = (struct tdaio_state *)dd->private;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-qcow.c
--- a/tools/blktap/drivers/block-qcow.c
+++ b/tools/blktap/drivers/block-qcow.c
@@ -722,7 +722,7 @@ static inline void init_fds(struct disk_
 /* Open the disk file and initialize qcow state. */
 static int tdqcow_open (struct disk_driver *dd, const char *name, td_flag_t flags)
 {
-	int fd, len, i, shift, ret, size, l1_table_size, o_flags, l1_table_block;
+	int fd, i, shift, ret, size, l1_table_size, o_flags, l1_table_block;
 	int max_aio_reqs;
 	struct td_state     *bs = dd->td_state;
 	struct tdqcow_state *s  = (struct tdqcow_state *)dd->private;
@@ -1009,7 +1009,7 @@ static int tdqcow_queue_write(struct dis
 		       int id, void *private)
 {
 	struct tdqcow_state *s = (struct tdqcow_state *)dd->private;
-	int ret = 0, index_in_cluster, n, i;
+	int index_in_cluster, n, i;
 	uint64_t cluster_offset, sec, nr_secs;
 
 	sec     = sector;
@@ -1099,7 +1099,7 @@ static int tdqcow_close(struct disk_driv
 
 static int tdqcow_do_callbacks(struct disk_driver *dd, int sid)
 {
-        int ret, i, nr_events, rsp = 0,*ptr;
+        int i, nr_events, rsp = 0;
         struct io_event *ep;
         struct tdqcow_state *prv = (struct tdqcow_state *)dd->private;
 
@@ -1143,7 +1143,7 @@ int qcow_create(const char *filename, ui
 		const char *backing_file, int sparse)
 {
 	int fd, header_size, backing_filename_len, l1_size, i;
-	int shift, length, adjust, flags = 0, ret = 0;
+	int shift, length, flags = 0, ret = 0;
 	QCowHeader header;
 	QCowHeader_ext exthdr;
 	char backing_filename[PATH_MAX], *ptr;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-qcow2.c
--- a/tools/blktap/drivers/block-qcow2.c
+++ b/tools/blktap/drivers/block-qcow2.c
@@ -952,7 +952,10 @@ static int qcow_read(struct disk_driver 
 		uint8_t *buf, int nb_sectors)
 {
 	BDRVQcowState *s = bs->private;
-	int ret, index_in_cluster, n, n1;
+	int ret, index_in_cluster, n;
+#if 0
+	int n1;
+#endif
 	uint64_t cluster_offset;
 
 	while (nb_sectors > 0) {
@@ -1145,8 +1148,6 @@ static int qcow_queue_write(struct disk_
 	BDRVQcowState *s = bs->private;
 	int i, n, index_in_cluster;
 	uint64_t cluster_offset;
-	const uint8_t *src_buf;
-		
 	
 	/*Check we can get a lock*/
 	for (i = 0; i < nb_sectors; i++) 
@@ -1861,7 +1862,7 @@ static int qcow_do_callbacks(struct disk
 
 static int qcow_do_callbacks(struct disk_driver *dd, int sid)
 {
-	int ret, i, nr_events, rsp = 0,*ptr;
+	int i, nr_events, rsp = 0;
 	struct io_event *ep;
 	struct BDRVQcowState *prv = (struct BDRVQcowState*)dd->private;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-ram.c
--- a/tools/blktap/drivers/block-ram.c
+++ b/tools/blktap/drivers/block-ram.c
@@ -64,9 +64,6 @@ struct tdram_state {
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -225,7 +222,6 @@ static int tdram_queue_read(struct disk_
 		      int id, void *private)
 {
 	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
 	int      size    = nb_sectors * s->sector_size;
 	uint64_t offset  = sector * (uint64_t)s->sector_size;
 
@@ -239,7 +235,6 @@ static int tdram_queue_write(struct disk
 		      int id, void *private)
 {
 	struct td_state    *s   = dd->td_state;
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
 	int      size    = nb_sectors * s->sector_size;
 	uint64_t offset  = sector * (uint64_t)s->sector_size;
 	
@@ -257,8 +252,6 @@ static int tdram_submit(struct disk_driv
 
 static int tdram_close(struct disk_driver *dd)
 {
-	struct tdram_state *prv = (struct tdram_state *)dd->private;
-	
 	connections--;
 	
 	return 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/block-sync.c
--- a/tools/blktap/drivers/block-sync.c
+++ b/tools/blktap/drivers/block-sync.c
@@ -54,9 +54,6 @@ struct tdsync_state {
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -111,7 +108,7 @@ static inline void init_fds(struct disk_
 /* Open the disk file and initialize aio state. */
 static int tdsync_open (struct disk_driver *dd, const char *name, td_flag_t flags)
 {
-	int i, fd, ret = 0, o_flags;
+	int fd, ret = 0, o_flags;
 	struct td_state     *s   = dd->td_state;
 	struct tdsync_state *prv = (struct tdsync_state *)dd->private;
 	
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/img2qcow.c
--- a/tools/blktap/drivers/img2qcow.c
+++ b/tools/blktap/drivers/img2qcow.c
@@ -63,7 +63,7 @@ static char output[25];
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -102,9 +102,6 @@ static inline void LOCAL_FD_SET(fd_set *
 static int get_image_info(struct td_state *s, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/qcow2raw.c
--- a/tools/blktap/drivers/qcow2raw.c
+++ b/tools/blktap/drivers/qcow2raw.c
@@ -67,7 +67,7 @@ static char output[25];
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -148,7 +148,7 @@ static int send_read_responses(struct di
 
 int main(int argc, char *argv[])
 {
-	int ret = -1, fd, len,input;
+	int ret = -1, fd;
 	uint64_t size;
 	fd_set readfds;
 	struct timeval timeout;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/tapaio.c
--- a/tools/blktap/drivers/tapaio.c
+++ b/tools/blktap/drivers/tapaio.c
@@ -183,7 +183,6 @@ int tap_aio_init(tap_aio_context_t *ctx,
 		int max_aio_reqs)
 {
 	int i, ret;
-	long ioidx;
 
 	ctx->iocb_list = NULL;
 	ctx->pending_aio = NULL;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/drivers/tapdisk.c
--- a/tools/blktap/drivers/tapdisk.c
+++ b/tools/blktap/drivers/tapdisk.c
@@ -62,7 +62,9 @@ static void usage(void)
 
 static void daemonize(void)
 {
+#if 0
 	int i;
+#endif
 
 	if (getppid()==1) return; /* already a daemon */
 	if (fork() != 0) exit(0);
@@ -154,7 +156,6 @@ static inline int LOCAL_FD_SET(fd_set *r
 static inline fd_list_entry_t *add_fd_entry(int tap_fd, struct td_state *s)
 {
 	fd_list_entry_t **pprev, *entry;
-	int i;
 
 	DPRINTF("Adding fd_list_entry\n");
 
@@ -369,7 +370,7 @@ static int open_disk(struct td_state *s,
 
 static int read_msg(char *buf)
 {
-	int length, len, msglen, tap_fd, *io_fd;
+	int length, len, msglen;
 	char *ptr, *path;
 	image_t *img;
 	msg_hdr_t *msg;
@@ -593,7 +594,7 @@ int do_cow_read(struct disk_driver *dd, 
 		int sidx, uint64_t sector, int nr_secs)
 {
 	char *page;
-	int ret, early;
+	int ret;
 	uint64_t seg_start, seg_end;
 	struct td_state  *s = dd->td_state;
 	tapdev_info_t *info = s->ring_info;
@@ -626,12 +627,11 @@ int do_cow_read(struct disk_driver *dd, 
 
 static void get_io_request(struct td_state *s)
 {
-	RING_IDX          rp, rc, j, i;
+	RING_IDX          rp, j, i;
 	blkif_request_t  *req;
 	int idx, nsects, ret;
 	uint64_t sector_nr;
 	char *page;
-	int early = 0; /* count early completions */
 	struct disk_driver *dd = s->disks;
 	struct tap_disk *drv   = dd->drv;
 	blkif_t *blkif = s->blkif;
@@ -644,7 +644,7 @@ static void get_io_request(struct td_sta
 	xen_rmb();
 	for (j = info->fe_ring.req_cons; j != rp; j++)
 	{
-		int done = 0, start_seg = 0; 
+		int start_seg = 0; 
 
 		req = NULL;
 		req = RING_GET_REQUEST(&info->fe_ring, j);
@@ -764,9 +764,9 @@ static void get_io_request(struct td_sta
 
 int main(int argc, char *argv[])
 {
-	int len, msglen, ret;
-	char *p, *buf;
-	fd_set readfds, writefds;	
+	int ret;
+	char *buf;
+	fd_set readfds;	
 	fd_list_entry_t *ptr;
 	struct td_state *s;
 	char openlogbuf[128];
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/lib/xenbus.c
--- a/tools/blktap/lib/xenbus.c
+++ b/tools/blktap/lib/xenbus.c
@@ -321,8 +321,8 @@ static int check_image(struct xs_handle 
 static void ueblktap_setup(struct xs_handle *h, char *bepath)
 {
 	struct backend_info *be;
-	char *path = NULL, *p,*dev;
-	int len, er, deverr;
+	char *path = NULL, *p;
+	int er, deverr;
 	long int pdev = 0, handle;
 	blkif_info_t *blk;
 	const char* errmsg = NULL;
@@ -449,9 +449,8 @@ static void ueblktap_probe(struct xs_han
 			   const char *bepath_im)
 {
 	struct backend_info *be = NULL;
-	char *frontend = NULL, *bepath = NULL, *p;
+	char *frontend = NULL, *bepath = NULL;
 	int er, len;
-	blkif_t *blkif;
 	
 	
 	bepath = strdup(bepath_im);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -60,8 +60,8 @@ int xs_gather(struct xs_handle *xs, cons
 {
 	va_list ap;
 	const char *name;
-	char *path, **e;
-	int ret = 0, num,i;
+	char *path;
+	int ret = 0;
 	unsigned int len;
 	xs_transaction_t xth;
 
@@ -213,7 +213,7 @@ int convert_dev_name_to_num(char *name) 
 	char *p;
 	const char *ptr;
 	int majors[10] = {3,22,33,34,56,57,88,89,90,91};
-	int maj,i,ret = 0;
+	int i,ret = 0;
 	const char p_sd[] = "/dev/sd";
 	const char p_hd[] = "/dev/hd";
 	const char p_xvd[] = "/dev/xvd";
@@ -341,7 +341,6 @@ int xs_fire_next_watch(struct xs_handle 
 	char *token;
 	char *node = NULL;
 	struct xenbus_watch *w;
-	int er;
 	unsigned int num;
 	
 	res = xs_read_watch(h, &num);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/control/tap-ctl-check.c
--- a/tools/blktap2/control/tap-ctl-check.c
+++ b/tools/blktap2/control/tap-ctl-check.c
@@ -65,7 +65,6 @@ int
 tap_ctl_check(const char **msg)
 {
 	int err;
-	uid_t uid;
 
 	err = tap_ctl_check_blktap(msg);
 	if (err)
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/control/tap-ctl-list.c
--- a/tools/blktap2/control/tap-ctl-list.c
+++ b/tools/blktap2/control/tap-ctl-list.c
@@ -125,8 +125,6 @@ tap_ctl_alloc_list(int n)
 	memset(list, 0, size);
 
 	for (i = 0; i < n; ++i) {
-		tap_list_t *entry;
-
 		entry = malloc(sizeof(tap_list_t));
 		if (!entry)
 			goto fail;
@@ -271,7 +269,6 @@ _tap_ctl_find_tapdisks(struct tapdisk **
 
 	for (i = 0; i < glbuf.gl_pathc; ++i) {
 		struct tapdisk *tap;
-		int n;
 
 		tap = &tapv[n_taps];
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/control/tap-ctl-spawn.c
--- a/tools/blktap2/control/tap-ctl-spawn.c
+++ b/tools/blktap2/control/tap-ctl-spawn.c
@@ -39,7 +39,7 @@
 static pid_t
 __tap_ctl_spawn(int *readfd)
 {
-	int err, child, channel[2];
+	int child, channel[2];
 	char *tapdisk;
 
 	if (pipe(channel)) {
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-aio.c
--- a/tools/blktap2/drivers/block-aio.c
+++ b/tools/blktap2/drivers/block-aio.c
@@ -64,9 +64,6 @@ struct tdaio_state {
 static int tdaio_get_image_info(int fd, td_disk_info_t *info)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-log.c
--- a/tools/blktap2/drivers/block-log.c
+++ b/tools/blktap2/drivers/block-log.c
@@ -217,7 +217,7 @@ static char* ctl_makepath(const char* na
 
 static int shmem_open(struct tdlog_state* s, const char* name)
 {
-  int i, l, fd;
+  int fd;
 
   /* device name -> path */
   if (asprintf(&s->shmpath, "/log_%s.wlog", name) < 0) {
@@ -486,7 +486,6 @@ static int ctl_kick(struct tdlog_state* 
   log_request_t req;
 
   /* XXX testing */
-  RING_IDX rspstart, rspend;
   log_response_t rsp;
   struct log_ctlmsg msg;
   int rc;
@@ -557,7 +556,7 @@ static void ctl_request(event_id_t id, c
 {
   struct tdlog_state* s = (struct tdlog_state*)private;
   struct log_ctlmsg msg;
-  int rc, i, fd = -1;
+  int rc, fd = -1;
 
   fd = ctl_find_connection(s, id);
   if (fd == -1)
@@ -635,7 +634,6 @@ static void tdlog_queue_read(td_driver_t
 static void tdlog_queue_write(td_driver_t* driver, td_request_t treq)
 {
   struct tdlog_state* s = (struct tdlog_state*)driver->data;
-  int rc;
 
   writelog_set(s, treq.sec, treq.secs);
   td_forward_request(treq);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-qcow.c
--- a/tools/blktap2/drivers/block-qcow.c
+++ b/tools/blktap2/drivers/block-qcow.c
@@ -84,7 +84,6 @@ static int decompress_cluster(struct tdq
 
 uint32_t gen_cksum(char *ptr, int len)
 {
-  int i;
   uint32_t md[4];
 
   /* Generate checksum */
@@ -101,8 +100,7 @@ static void free_aio_state(struct tdqcow
 
 static int init_aio_state(td_driver_t *driver)
 {
-	int i, ret;
-	td_disk_info_t *bs = &(driver->info);
+	int i;
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
 	
         // A segment (i.e. a page) can span multiple clusters
@@ -866,7 +864,7 @@ out:
 /* Open the disk file and initialize qcow state. */
 int tdqcow_open (td_driver_t *driver, const char *name, td_flag_t flags)
 {
-	int fd, len, i, ret, size, o_flags;
+	int fd, i, ret, size, o_flags;
 	td_disk_info_t *bs = &(driver->info);
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
 	QCowHeader header;
@@ -983,9 +981,8 @@ fail:
 void tdqcow_queue_read(td_driver_t *driver, td_request_t treq)
 {
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
-	int ret = 0, index_in_cluster, n, i;
+	int index_in_cluster, n, i;
 	uint64_t cluster_offset, sector, nb_sectors;
-	struct qcow_prv* prv;
 	td_request_t clone = treq;
 	char* buf = treq.buf;
 
@@ -1007,7 +1004,6 @@ void tdqcow_queue_read(td_driver_t *driv
 		}
 		
 		if(!cluster_offset) {
-            int i;
             /* Forward entire request if possible. */
             for(i=0; i<nb_sectors; i++)
                 if(get_cluster_offset(s, (sector+i) << 9, 0, 0, 0, 0))
@@ -1052,10 +1048,8 @@ done:
 void tdqcow_queue_write(td_driver_t *driver, td_request_t treq)
 {
 	struct tdqcow_state   *s  = (struct tdqcow_state *)driver->data;
-	int ret = 0, index_in_cluster, n, i;
+	int index_in_cluster, n;
 	uint64_t cluster_offset, sector, nb_sectors;
-	td_callback_t cb;
-	struct qcow_prv* prv;
 	char* buf = treq.buf;
 	td_request_t clone=treq;
 
@@ -1179,7 +1173,7 @@ int qcow_create(const char *filename, ui
 		const char *backing_file, int sparse)
 {
 	int fd, header_size, backing_filename_len, l1_size, i;
-	int shift, length, adjust, flags = 0, ret = 0;
+	int shift, length, flags = 0, ret = 0;
 	QCowHeader header;
 	QCowHeader_ext exthdr;
 	char backing_filename[PATH_MAX], *ptr;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-ram.c
--- a/tools/blktap2/drivers/block-ram.c
+++ b/tools/blktap2/drivers/block-ram.c
@@ -55,9 +55,6 @@ struct tdram_state {
 static int get_image_info(int fd, td_disk_info_t *info)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 
 	ret = fstat(fd, &stat);
@@ -200,7 +197,6 @@ done:
 
 void tdram_queue_read(td_driver_t *driver, td_request_t treq)
 {
-	struct tdram_state *prv = (struct tdram_state *)driver->data;
 	int      size    = treq.secs * driver->info.sector_size;
 	uint64_t offset  = treq.sec * (uint64_t)driver->info.sector_size;
 
@@ -211,7 +207,6 @@ void tdram_queue_read(td_driver_t *drive
 
 void tdram_queue_write(td_driver_t *driver, td_request_t treq)
 {
-	struct tdram_state *prv = (struct tdram_state *)driver->data;
 	int      size    = treq.secs * driver->info.sector_size;
 	uint64_t offset  = treq.sec * (uint64_t)driver->info.sector_size;
 	
@@ -224,8 +219,6 @@ void tdram_queue_write(td_driver_t *driv
 
 int tdram_close(td_driver_t *driver)
 {
-	struct tdram_state *prv = (struct tdram_state *)driver->data;
-	
 	connections--;
 	
 	return 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-remus.c
--- a/tools/blktap2/drivers/block-remus.c
+++ b/tools/blktap2/drivers/block-remus.c
@@ -575,10 +575,8 @@ static int ramdisk_flush(td_driver_t *dr
 static int ramdisk_start_flush(td_driver_t *driver)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	uint64_t* key;
 	char* buf;
-	int rc = 0;
-	int i, j, count, batchlen;
+	int i, count;
 	uint64_t* sectors;
 
 	if (!hashtable_count(s->ramdisk.h)) {
@@ -746,7 +744,6 @@ static int primary_do_connect(struct tdr
 {
 	event_id_t id;
 	int fd;
-	int rc;
 	int flags;
 
 	RPRINTF("client connecting to %s:%d...\n", inet_ntoa(state->sa.sin_addr), ntohs(state->sa.sin_port));
@@ -1028,7 +1025,6 @@ static void remus_client_event(event_id_
 {
 	struct tdremus_state *s = (struct tdremus_state *)private;
 	char req[5];
-	int rc;
 
 	if (mread(s->stream_fd.fd, req, sizeof(req) - 1) < 0) {
 		/* replication stream closed or otherwise broken (timeout, reset, &c) */
@@ -1151,7 +1147,6 @@ static inline int server_writes_inflight
 void backup_queue_read(td_driver_t *driver, td_request_t treq)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	int i;
 	if(!remus_image)
 		remus_image = treq.image;
 	
@@ -1168,8 +1163,6 @@ void backup_queue_read(td_driver_t *driv
 /* see above */
 void backup_queue_write(td_driver_t *driver, td_request_t treq)
 {
-	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-
 	/* on a server write, we know the domain has failed over. we must change our
 	 * state to unprotected and then have the unprotected queue_write function
 	 * handle the write
@@ -1183,7 +1176,6 @@ void backup_queue_write(td_driver_t *dri
 static int backup_start(td_driver_t *driver)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	int fd;
 
 	if (ramdisk_start(driver) < 0)
 		return -1;
@@ -1198,9 +1190,8 @@ static int backup_start(td_driver_t *dri
 static int server_do_wreq(td_driver_t *driver)
 {
 	struct tdremus_state *s = (struct tdremus_state *)driver->data;
-	static tdremus_wire_t twreq;
 	char buf[4096];
-	int len, rc;
+	int len;
 
 	char header[sizeof(uint32_t) + sizeof(uint64_t)];
 	uint32_t *sectors = (uint32_t *) header;
@@ -1429,9 +1420,6 @@ static int get_args(td_driver_t *driver,
 	/* TODO: do something smarter here */
 	valid_addr = 0;
 	for(servinfo_itr = servinfo; servinfo_itr != NULL; servinfo_itr = servinfo_itr->ai_next) {
-		void *addr;
-		char *ipver;
-
 		if (servinfo_itr->ai_family == AF_INET) {
 			valid_addr = 1;
 			memset(&state->sa, 0, sizeof(state->sa));
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/block-vhd.c
--- a/tools/blktap2/drivers/block-vhd.c
+++ b/tools/blktap2/drivers/block-vhd.c
@@ -726,7 +726,6 @@ _vhd_close(td_driver_t *driver)
 {
 	int err;
 	struct vhd_state *s;
-	struct vhd_bitmap *bm;
 	
 	DBG(TLOG_WARN, "vhd_close\n");
 	s = (struct vhd_state *)driver->data;
@@ -772,8 +771,6 @@ int
 vhd_validate_parent(td_driver_t *child_driver,
 		    td_driver_t *parent_driver, td_flag_t flags)
 {
-	uint32_t status;
-	struct stat stats;
 	struct vhd_state *child  = (struct vhd_state *)child_driver->data;
 	struct vhd_state *parent;
 
@@ -789,24 +786,6 @@ vhd_validate_parent(td_driver_t *child_d
 
 	parent = (struct vhd_state *)parent_driver->data;
 
-	/* 
-	 * This check removed because of cases like:
-	 *   - parent VHD marked as 'hidden'
-	 *   - parent VHD modified during coalesce
-	 */
-	/*
-	if (stat(parent->vhd.file, &stats)) {
-		DPRINTF("ERROR stating parent file %s\n", parent->vhd.file);
-		return -errno;
-	}
-
-	if (child->hdr.prt_ts != vhd_time(stats.st_mtime)) {
-		DPRINTF("ERROR: parent file has been modified since "
-			"snapshot.  Child image no longer valid.\n");
-		return -EINVAL;
-	}
-	*/
-
 	if (vhd_uuid_compare(&child->vhd.header.prt_uuid, &parent->vhd.footer.uuid)) {
 		DPRINTF("ERROR: %s: %s, %s: parent uuid has changed since "
 			"snapshot.  Child image no longer valid.\n",
@@ -1380,7 +1359,6 @@ update_bat(struct vhd_state *s, uint32_t
 static int
 allocate_block(struct vhd_state *s, uint32_t blk)
 {
-	char *zeros;
 	int err, gap;
 	uint64_t offset, size;
 	struct vhd_bitmap *bm;
@@ -1860,7 +1838,7 @@ signal_completion(struct vhd_request *li
 static void
 start_new_bitmap_transaction(struct vhd_state *s, struct vhd_bitmap *bm)
 {
-	int i, error = 0;
+	int i;
 	struct vhd_transaction *tx;
 	struct vhd_request *r, *next;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/img2qcow.c
--- a/tools/blktap2/drivers/img2qcow.c
+++ b/tools/blktap2/drivers/img2qcow.c
@@ -70,10 +70,9 @@
 
 static int running = 1, complete = 0;
 static int returned_events = 0, submit_events = 0;
-static uint32_t read_idx = 0;
 td_driver_t *ddqcow;
 td_vbd_t* qcow_vbd;
-static uint64_t prev = 0, written = 0;
+static uint64_t prev = 0;
 static char output[(100/PROGRESS_QUANT) + 5];
 
 extern tapdisk_server_t server;
@@ -81,7 +80,7 @@ extern tapdisk_server_t server;
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -112,9 +111,6 @@ static void debug_output(uint64_t progre
 static int get_image_info(td_disk_info_t *driver, int fd)
 {
 	int ret;
-	long size;
-	unsigned long total_size;
-	struct statvfs statBuf;
 	struct stat stat;
 	uint64_t sector_size=DEFAULT_SECTOR_SIZE;
 
@@ -164,7 +160,6 @@ void send_responses(td_request_t treq, i
 int main(int argc, const char *argv[])
 {
         int ret = -1, fd, len, err;
-	struct timeval timeout;
 	uint64_t i;
 	char *buf;
 	td_request_t treq;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/io-optimize.c
--- a/tools/blktap2/drivers/io-optimize.c
+++ b/tools/blktap2/drivers/io-optimize.c
@@ -219,7 +219,6 @@ io_merge(struct opioctx *ctx, struct ioc
 {
 	int i, on_queue;
 	struct iocb *io, **q;
-	struct opio *ophead;
 	
 	if (!num)
 		return 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/lock.c
--- a/tools/blktap2/drivers/lock.c
+++ b/tools/blktap2/drivers/lock.c
@@ -959,7 +959,6 @@ static void usage(char *prg)
 int main(int argc, char *argv[])
 {
         int status = 0;
-        int dlock;
         char *ptr;
         int force;
         int readonly;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/qcow2raw.c
--- a/tools/blktap2/drivers/qcow2raw.c
+++ b/tools/blktap2/drivers/qcow2raw.c
@@ -71,7 +71,6 @@
 static int running = 1, complete = 0; 
 static int returned_read_events = 0, returned_write_events = 0;
 static int submit_events = 0;
-static uint32_t read_idx = 0;
 td_driver_t *ddqcow, *ddaio;
 td_vbd_t* qcow_vbd, *aio_vbd;
 static uint64_t prev = 0, written = 0;
@@ -87,7 +86,7 @@ struct request_info {
 
 static void print_bytes(void *ptr, int length)
 {
-  int i,k;
+  int k;
   unsigned char *p = ptr;
 
     DFPRINTF("Buf dump, length %d:\n",length);
@@ -144,7 +143,6 @@ static void send_write_responses(td_requ
 
 static void send_read_responses(td_request_t treq, int err)
 {
-	int ret;
         struct request_info* req;
         td_vbd_request_t* vreq;
 
@@ -198,7 +196,7 @@ static void send_read_responses(td_reque
 
 int main(int argc, const char *argv[])
 {
-	int ret = -1, fd, len,input;
+	int ret = -1, fd;
 	uint64_t size;
 	struct timeval timeout;
 	uint64_t i;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-client.c
--- a/tools/blktap2/drivers/tapdisk-client.c
+++ b/tools/blktap2/drivers/tapdisk-client.c
@@ -241,7 +241,6 @@ static int ctl_clear_writes(int fd)
 static int writelog_map(struct writelog* wl)
 {
   int fd;
-  void* shm;
 
   if ((fd = shm_open(wl->shmpath, O_RDWR, 0750)) < 0) {
     BWPRINTF("could not open shared memory at %s: %s", wl->shmpath,
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-control.c
--- a/tools/blktap2/drivers/tapdisk-control.c
+++ b/tools/blktap2/drivers/tapdisk-control.c
@@ -89,7 +89,6 @@ static struct tapdisk_control_connection
 tapdisk_control_allocate_connection(int fd)
 {
 	struct tapdisk_control_connection *connection;
-	size_t sz;
 
 	connection = calloc(1, sizeof(*connection));
 	if (!connection) {
@@ -252,7 +251,7 @@ tapdisk_control_list(struct tapdisk_cont
 	td_vbd_t *vbd;
 	struct list_head *head;
 	tapdisk_message_t response;
-	int count, i;
+	int count;
 
 	memset(&response, 0, sizeof(response));
 	response.type = TAPDISK_MESSAGE_LIST_RSP;
@@ -313,8 +312,6 @@ tapdisk_control_attach_vbd(struct tapdis
 	tapdisk_message_t response;
 	char *devname;
 	td_vbd_t *vbd;
-	struct blktap2_params params;
-	image_t image;
 	int minor, err;
 
 	/*
@@ -758,7 +755,7 @@ tapdisk_control_mkdir(const char *dir)
 static int
 tapdisk_control_create_socket(char **socket_path)
 {
-	int err, flags;
+	int err;
 	struct sockaddr_un saddr;
 
 	err = tapdisk_control_mkdir(BLKTAP2_CONTROL_DIR);
@@ -829,8 +826,6 @@ fail:
 int
 tapdisk_control_open(char **path)
 {
-	int err;
-
 	tapdisk_control_initialize();
 
 	return tapdisk_control_create_socket(path);
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-diff.c
--- a/tools/blktap2/drivers/tapdisk-diff.c
+++ b/tools/blktap2/drivers/tapdisk-diff.c
@@ -466,7 +466,6 @@ static void
 tapdisk_stream_enqueue2(void)
 {
 	td_vbd_t *vbd;
-	int i, blk;
 	struct tapdisk_stream_request *itr;
 	struct tapdisk_stream *s = &stream2;
 
@@ -717,7 +716,6 @@ main(int argc, char *argv[])
 {
 	int c, err, type1;
 	const char *arg1 = NULL, *arg2 = NULL;
-	const disk_info_t *info;
 	const char *path1;
 
 	err    = 0;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-filter.c
--- a/tools/blktap2/drivers/tapdisk-filter.c
+++ b/tools/blktap2/drivers/tapdisk-filter.c
@@ -156,7 +156,7 @@ static void
 check_data(struct tfilter *filter, int type, struct iocb *io)
 {
 	int rw;
-	uint64_t i, sec;
+	uint64_t i;
 
 	rw = (io->aio_lio_opcode == IO_CMD_PWRITE);
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-interface.c
--- a/tools/blktap2/drivers/tapdisk-interface.c
+++ b/tools/blktap2/drivers/tapdisk-interface.c
@@ -37,7 +37,6 @@
 int
 td_load(td_image_t *image)
 {
-	int err;
 	td_image_t *shared;
 	td_driver_t *driver;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-queue.c
--- a/tools/blktap2/drivers/tapdisk-queue.c
+++ b/tools/blktap2/drivers/tapdisk-queue.c
@@ -194,7 +194,6 @@ static int
 tapdisk_rwio_setup(struct tqueue *queue, int size)
 {
 	struct rwio *rwio = queue->tio_data;
-	int err;
 
 	rwio->aio_events = calloc(size, sizeof(struct io_event));
 	if (!rwio->aio_events)
@@ -474,7 +473,6 @@ static int
 tapdisk_lio_setup(struct tqueue *queue, int qlen)
 {
 	struct lio *lio = queue->tio_data;
-	size_t sz;
 	int err;
 
 	lio->event_id = -1;
@@ -608,7 +606,7 @@ int
 tapdisk_init_queue(struct tqueue *queue, int size,
 		   int drv, struct tfilter *filter)
 {
-	int i, err;
+	int err;
 
 	memset(queue, 0, sizeof(struct tqueue));
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-server.c
--- a/tools/blktap2/drivers/tapdisk-server.c
+++ b/tools/blktap2/drivers/tapdisk-server.c
@@ -180,7 +180,6 @@ tapdisk_server_submit_tiocbs(void)
 static void
 tapdisk_server_kick_responses(void)
 {
-	int n;
 	td_vbd_t *vbd, *tmp;
 
 	tapdisk_server_for_each_vbd(vbd, tmp)
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-stream.c
--- a/tools/blktap2/drivers/tapdisk-stream.c
+++ b/tools/blktap2/drivers/tapdisk-stream.c
@@ -547,7 +547,6 @@ main(int argc, char *argv[])
 {
 	int c, err, type;
 	const char *params;
-	const disk_info_t *info;
 	const char *path;
 	uint64_t count, skip;
 	struct tapdisk_stream stream;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-utils.c
--- a/tools/blktap2/drivers/tapdisk-utils.c
+++ b/tools/blktap2/drivers/tapdisk-utils.c
@@ -111,7 +111,6 @@ tapdisk_namedup(char **dup, const char *
 int
 tapdisk_get_image_size(int fd, uint64_t *_sectors, uint32_t *_sector_size)
 {
-	int ret;
 	struct stat stat;
 	uint64_t sectors;
 	uint64_t sector_size;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/tapdisk-vbd.c
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -199,7 +199,6 @@ static int
 tapdisk_vbd_add_block_cache(td_vbd_t *vbd)
 {
 	int err;
-	td_driver_t *driver;
 	td_image_t *cache, *image, *target, *tmp;
 
 	target = NULL;
@@ -313,7 +312,6 @@ tapdisk_vbd_open_level(td_vbd_t *vbd, st
 	int type, err;
 	td_image_t *image;
 	td_disk_id_t id;
-	td_driver_t *driver;
 
 	name    = params;
 	id.name = NULL;
@@ -386,7 +384,6 @@ __tapdisk_vbd_open_vdi(td_vbd_t *vbd, td
 	td_flag_t flags;
 	td_image_t *tmp;
 	td_vbd_driver_info_t *driver_info;
-	struct list_head *images;
 	td_disk_info_t *parent_info = NULL;
 
 	if (list_empty(&vbd->driver_stack))
@@ -1196,7 +1193,6 @@ __tapdisk_vbd_complete_td_request(td_vbd
 				  td_request_t treq, int res)
 {
 	int err;
-    td_image_t *image = treq.image;
 
 	err = (res <= 0 ? res : -res);
 	vbd->secs_pending  -= treq.secs;
@@ -1216,6 +1212,7 @@ __tapdisk_vbd_complete_td_request(td_vbd
 		}
 	} else {
 #ifdef MEMSHR
+		td_image_t *image = treq.image;
 		if (treq.op == TD_OP_READ
 		   && td_flag_test(image->flags, TD_OPEN_RDONLY)) {
 			share_tuple_t hnd = treq.memshr_hnd;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/drivers/td.c
--- a/tools/blktap2/drivers/td.c
+++ b/tools/blktap2/drivers/td.c
@@ -357,7 +357,7 @@ int
 td_coalesce(int type, int argc, char *argv[])
 {
 	int c, ret, cargc;
-	char *name, *pname, *cargv[3];
+	char *name, *cargv[3];
 
 	if (type != TD_TYPE_VHD) {
 		fprintf(stderr, "Cannot create snapshot of %s image type\n",
@@ -545,7 +545,7 @@ td_query(int type, int argc, char *argv[
 int
 td_set_field(int type, int argc, char *argv[])
 {
-	int ret, i, c, cargc;
+	int c, cargc;
 	struct vdi_field *field;
 	char *name, *value, *cargv[7];
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/lvm/lvm-util.c
--- a/tools/blktap2/lvm/lvm-util.c
+++ b/tools/blktap2/lvm/lvm-util.c
@@ -218,7 +218,7 @@ lvm_scan_lvs(struct vg *vg)
 		struct lv *lv;
 		struct lv_segment seg;
 		uint64_t size, seg_start;
-		char type[32], name[256], dev[256], devices[1024];
+		char type[32], name[256], devices[1024];
 
 		if (i >= vg->lv_cnt)
 			break;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/libvhd-journal.c
--- a/tools/blktap2/vhd/lib/libvhd-journal.c
+++ b/tools/blktap2/vhd/lib/libvhd-journal.c
@@ -357,7 +357,6 @@ vhd_journal_update(vhd_journal_t *j, off
 		   char *buf, size_t size, uint32_t type)
 {
 	int err;
-	off_t eof;
 	uint64_t *off, off_bak;
 	uint32_t *entries;
 	vhd_journal_entry_t entry;
@@ -611,7 +610,6 @@ static int
 vhd_journal_add_metadata(vhd_journal_t *j)
 {
 	int err;
-	off_t eof;
 	vhd_context_t *vhd;
 
 	vhd = &j->vhd;
@@ -1256,11 +1254,7 @@ fail:
 int
 vhd_journal_create(vhd_journal_t *j, const char *file, const char *jfile)
 {
-	char *buf;
-	int i, err;
-	size_t size;
-	off_t off;
-	struct stat stats;
+	int err;
 
 	memset(j, 0, sizeof(vhd_journal_t));
 	j->jfd = -1;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/libvhd.c
--- a/tools/blktap2/vhd/lib/libvhd.c
+++ b/tools/blktap2/vhd/lib/libvhd.c
@@ -1028,7 +1028,6 @@ out:
 int
 vhd_read_header(vhd_context_t *ctx, vhd_header_t *header)
 {
-	int err;
 	off_t off;
 
 	if (!vhd_type_dynamic(ctx)) {
@@ -2008,7 +2007,6 @@ out:
 int
 vhd_write_header(vhd_context_t *ctx, vhd_header_t *header)
 {
-	int err;
 	off_t off;
 
 	if (!vhd_type_dynamic(ctx))
@@ -2143,7 +2141,7 @@ vhd_write_bitmap(vhd_context_t *ctx, uin
 	int err;
 	off_t off;
 	uint64_t blk;
-	size_t secs, size;
+	size_t size;
 
 	if (!vhd_type_dynamic(ctx))
 		return -EINVAL;
@@ -3203,7 +3201,7 @@ __vhd_io_allocate_block(vhd_context_t *c
 	char *buf;
 	size_t size;
 	off_t off, max;
-	int i, err, gap, spp;
+	int err, gap, spp;
 
 	spp = getpagesize() >> VHD_SECTOR_SHIFT;
 
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-check.c
--- a/tools/blktap2/vhd/lib/vhd-util-check.c
+++ b/tools/blktap2/vhd/lib/vhd-util-check.c
@@ -309,7 +309,6 @@ vhd_util_check_validate_parent(vhd_conte
 {
 	const char *msg;
 	vhd_context_t parent;
-	uint32_t status;
 
 	msg = NULL;
 
@@ -925,7 +924,6 @@ int
 vhd_util_check(int argc, char **argv)
 {
 	char *name;
-	vhd_context_t vhd;
 	int c, err, ignore, parents;
 
 	if (!argc || !argv) {
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-read.c
--- a/tools/blktap2/vhd/lib/vhd-util-read.c
+++ b/tools/blktap2/vhd/lib/vhd-util-read.c
@@ -70,7 +70,7 @@ vhd_print_header(vhd_context_t *vhd, vhd
 {
 	int err;
 	uint32_t  cksm;
-	char      uuid[39], time_str[26], cookie[9], out[512], *name;
+	char      uuid[39], time_str[26], cookie[9], *name;
 
 	printf("VHD Header Summary:\n-------------------\n");
 
@@ -105,7 +105,7 @@ static void
 vhd_print_footer(vhd_footer_t *f, int hex)
 {
 	uint64_t  c, h, s;
-	uint32_t  ff_maj, ff_min, cr_maj, cr_min, cksm, cksm_save;
+	uint32_t  ff_maj, ff_min, cr_maj, cr_min, cksm;
 	char      time_str[26], creator[5], uuid[39], cookie[9];
 
 	printf("VHD Footer Summary:\n-------------------\n");
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-resize.c
--- a/tools/blktap2/vhd/lib/vhd-util-resize.c
+++ b/tools/blktap2/vhd/lib/vhd-util-resize.c
@@ -877,7 +877,7 @@ vhd_add_bat_entries(vhd_journal_t *journ
 static int
 vhd_dynamic_grow(vhd_journal_t *journal, uint64_t secs)
 {
-	int i, err;
+	int err;
 	off_t eob, eom;
 	vhd_context_t *vhd;
 	vhd_block_t first_block;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-scan.c
--- a/tools/blktap2/vhd/lib/vhd-util-scan.c
+++ b/tools/blktap2/vhd/lib/vhd-util-scan.c
@@ -115,7 +115,6 @@ static int
 vhd_util_scan_pretty_allocate_list(int cnt)
 {
 	int i;
-	struct vhd_image *list;
 
 	memset(&scan, 0, sizeof(scan));
 
@@ -443,7 +442,6 @@ copy_name(char *dst, const char *src)
 static int
 vhd_util_scan_extract_volume_name(char *dst, const char *src)
 {
-	int err;
 	char copy[VHD_MAX_NAME_LEN], *name, *s, *c;
 
 	name = strrchr(src, '/');
@@ -510,7 +508,7 @@ found:
 static int
 vhd_util_scan_get_parent(vhd_context_t *vhd, struct vhd_image *image)
 {
-	int i, err;
+	int err;
 	vhd_parent_locator_t *loc;
 
 	if (!target_vhd(image->target->type)) {
@@ -678,7 +676,6 @@ out:
 static int
 vhd_util_scan_open_volume(vhd_context_t *vhd, struct vhd_image *image)
 {
-	int err;
 	struct target *target;
 
 	target = image->target;
diff -r a85817bc44e5 -r 33af0a492bf7 tools/blktap2/vhd/lib/vhd-util-set-field.c
--- a/tools/blktap2/vhd/lib/vhd-util-set-field.c
+++ b/tools/blktap2/vhd/lib/vhd-util-set-field.c
@@ -37,7 +37,6 @@ vhd_util_set_field(int argc, char **argv
 {
 	long value;
 	int err, c;
-	off_t eof;
 	vhd_context_t vhd;
 	char *name, *field;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfb-0005fX-2N; Mon, 02 Apr 2012 20:16:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cq-Jb
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.139.83:17316] by server-11.bemta-5.messagelabs.com id
	52/60-12959-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333397761!22135308!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5156 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=869;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=xtW4n5XuZUX4PQloEH6hWK/fCQ4=;
	b=ms2ePb70T7NKUq6PjLdH0lqjuCLra98ENL38xCjsZg4XPVFDn6c+NJcc2on1Zl4s04+
	wXoYqqtJFcVLSbTA3IwIsPfk6hHyzpNUeloi++VkbCfOoO4HQCu8BJncIsrYCnfjixPih
	ARVkKCQaigAQpsFzaCmvJLeG0c9T6DB0b6Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo28) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 303351o32ICT5i ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A023918630;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 9b7de2b8d7d6c8312e10dabb68ebebeb5bfd1787
Message-Id: <9b7de2b8d7d6c8312e10.1333397732@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:32 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09 of 18] tools/blktap2: remove unneeded pointer
 dereferencing from img2qcow.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397548 -7200
# Node ID 9b7de2b8d7d6c8312e10dabb68ebebeb5bfd1787
# Parent  e9b9e8254311fb61930ab5a954e777928466c607
tools/blktap2: remove unneeded pointer dereferencing from img2qcow.c

img2qcow.c: In function 'print_bytes':
img2qcow.c:90:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e9b9e8254311 -r 9b7de2b8d7d6 tools/blktap2/drivers/img2qcow.c
--- a/tools/blktap2/drivers/img2qcow.c
+++ b/tools/blktap2/drivers/img2qcow.c
@@ -87,7 +87,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if(k % 16 == 0) DFPRINTF("\n");
         else if(k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfb-0005fX-2N; Mon, 02 Apr 2012 20:16:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cq-Jb
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.139.83:17316] by server-11.bemta-5.messagelabs.com id
	52/60-12959-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333397761!22135308!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5156 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=869;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=xtW4n5XuZUX4PQloEH6hWK/fCQ4=;
	b=ms2ePb70T7NKUq6PjLdH0lqjuCLra98ENL38xCjsZg4XPVFDn6c+NJcc2on1Zl4s04+
	wXoYqqtJFcVLSbTA3IwIsPfk6hHyzpNUeloi++VkbCfOoO4HQCu8BJncIsrYCnfjixPih
	ARVkKCQaigAQpsFzaCmvJLeG0c9T6DB0b6Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo28) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 303351o32ICT5i ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A023918630;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 9b7de2b8d7d6c8312e10dabb68ebebeb5bfd1787
Message-Id: <9b7de2b8d7d6c8312e10.1333397732@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:32 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09 of 18] tools/blktap2: remove unneeded pointer
 dereferencing from img2qcow.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397548 -7200
# Node ID 9b7de2b8d7d6c8312e10dabb68ebebeb5bfd1787
# Parent  e9b9e8254311fb61930ab5a954e777928466c607
tools/blktap2: remove unneeded pointer dereferencing from img2qcow.c

img2qcow.c: In function 'print_bytes':
img2qcow.c:90:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e9b9e8254311 -r 9b7de2b8d7d6 tools/blktap2/drivers/img2qcow.c
--- a/tools/blktap2/drivers/img2qcow.c
+++ b/tools/blktap2/drivers/img2qcow.c
@@ -87,7 +87,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if(k % 16 == 0) DFPRINTF("\n");
         else if(k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfY-0005eB-Tm; Mon, 02 Apr 2012 20:16:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cS-6Y
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.138.51:34001] by server-4.bemta-3.messagelabs.com id
	59/36-16467-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333397760!20489273!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13395 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=865;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=KBtr/89exjo20vAVHBLX/gBuAZQ=;
	b=JQz4Ei5aVHFDq76p6cJXEc3Tty0E4hFyVzkBPc9PP/IRl3HV6Vql9lM/iF49lu3z6oI
	3X/kjsp+nBM87bkXtQta5Dpbpm+9p5HVS3/WW+0KVbgevM98LdgA+p1HQWM7XhiNmXhEi
	zPpSJ5KF+kE1XJNPN/INguACWo09pNhRdpw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32Iqrna ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 8CC121863A;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ae6bf2207a4e36ca6a60b42e82f79b8de09acec3
Message-Id: <ae6bf2207a4e36ca6a60.1333397727@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04 of 18] tools/blktap: remove unneeded pointer
 dereferencing from img2qcow.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397521 -7200
# Node ID ae6bf2207a4e36ca6a60b42e82f79b8de09acec3
# Parent  90e2257cace2c3b7b8e7c4611614ad4da07ec895
tools/blktap: remove unneeded pointer dereferencing from img2qcow.c

img2qcow.c: In function 'print_bytes':
img2qcow.c:72:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 90e2257cace2 -r ae6bf2207a4e tools/blktap/drivers/img2qcow.c
--- a/tools/blktap/drivers/img2qcow.c
+++ b/tools/blktap/drivers/img2qcow.c
@@ -69,7 +69,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if(k % 16 == 0) DFPRINTF("\n");
         else if(k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfb-0005g2-H8; Mon, 02 Apr 2012 20:16:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cP-Uq
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:04 +0000
Received: from [85.158.143.99:38128] by server-1.bemta-4.messagelabs.com id
	91/76-20925-3090A7F4; Mon, 02 Apr 2012 20:16:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333397762!21429397!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30512 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=2521;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=qgcsVhP0MmTUYWeemVGHt2e8GP4=;
	b=dowJKN1MY3nbeYQAK8ZXsaIIZkuO2h7GNLuYauS4eSxW3LR5ACqD0L3C4iky+EOvFQ7
	8CxqFOCduR/rQmxXLqBTQLpLEXCrET838acl1iEZKd63fNL4xHsFv+rqB/Tn1tFvKHXlE
	IHbOfKkPQzDXZMp21qOhU6EZRCYAtySZ3ss=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo16) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L05eb6o32K7GC5 ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 327A618638;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 5d89ebdf878b8b0647a688d0ef938bb933772d86
Message-Id: <5d89ebdf878b8b0647a6.1333397735@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:35 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12 of 18] tools/memshr: fix build errors caused
	by Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397566 -7200
# Node ID 5d89ebdf878b8b0647a688d0ef938bb933772d86
# Parent  c582ef14a24cb2186c1748047a62a85fae0dbeb3
tools/memshr: fix build errors caused by Werror

-O2 -Wall -Werror triggers these warnings:

cc1: warnings being treated as errors
interface.c: In function 'memshr_daemon_initialize':
interface.c:55: error: unused variable 'h'
interface.c:54: error: unused variable 'shm_base_addr'
cc1: warnings being treated as errors
bidir-hash.h:47: error: 'fgprtshr_fgprt_hash' defined but not used
bidir-hash.h:52: error: 'fgprtshr_mfn_hash' defined but not used
bidir-hash.h:57: error: 'fgprtshr_fgprt_cmp' defined but not used
bidir-hash.h:62: error: 'fgprtshr_mfn_cmp' defined but not used
make[3]: *** [interface.o] Error 1
make[3]: *** [bidir-daemon.o] Error 1
cc1: warnings being treated as errors
bidir-hash.h:47: error: 'fgprtshr_fgprt_hash' defined but not used
bidir-hash.h:52: error: 'fgprtshr_mfn_hash' defined but not used
bidir-hash.h:57: error: 'fgprtshr_fgprt_cmp' defined but not used
bidir-hash.h:62: error: 'fgprtshr_mfn_cmp' defined but not used

Mark fingerprint functions as inline, remove unused variables.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r c582ef14a24c -r 5d89ebdf878b tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -43,22 +43,22 @@ typedef struct vbdblk {
 #undef BIDIR_VALUE
 #undef BIDIR_KEY_T
 #undef BIDIR_VALUE_T
-static uint32_t fgprtshr_fgprt_hash(uint32_t h)
+static inline uint32_t fgprtshr_fgprt_hash(uint32_t h)
 {
     return h;
 }
 
-static uint32_t fgprtshr_mfn_hash(uint64_t m)
+static inline uint32_t fgprtshr_mfn_hash(uint64_t m)
 {
     return (uint32_t)m;
 }
 
-static int fgprtshr_fgprt_cmp(uint32_t h1, uint32_t h2)
+static inline int fgprtshr_fgprt_cmp(uint32_t h1, uint32_t h2)
 {
     return (h1 == h2);
 }
 
-static int fgprtshr_mfn_cmp(uint32_t m1, uint32_t m2)
+static inline int fgprtshr_mfn_cmp(uint32_t m1, uint32_t m2)
 {
     return (m1 == m2);
 }
diff -r c582ef14a24c -r 5d89ebdf878b tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -51,9 +51,6 @@ void memshr_set_domid(int domid)
 
 void memshr_daemon_initialize(void)
 {
-    void *shm_base_addr;
-    struct fgprtshr_hash *h;
-
     memset(&memshr, 0, sizeof(private_memshr_info_t));
 
     if((SHARED_INFO = shm_shared_info_open(1)) == NULL)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfY-0005eB-Tm; Mon, 02 Apr 2012 20:16:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cS-6Y
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.138.51:34001] by server-4.bemta-3.messagelabs.com id
	59/36-16467-1090A7F4; Mon, 02 Apr 2012 20:16:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333397760!20489273!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ3MjI=\n,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13395 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=865;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=KBtr/89exjo20vAVHBLX/gBuAZQ=;
	b=JQz4Ei5aVHFDq76p6cJXEc3Tty0E4hFyVzkBPc9PP/IRl3HV6Vql9lM/iF49lu3z6oI
	3X/kjsp+nBM87bkXtQta5Dpbpm+9p5HVS3/WW+0KVbgevM98LdgA+p1HQWM7XhiNmXhEi
	zPpSJ5KF+kE1XJNPN/INguACWo09pNhRdpw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by post.strato.de (mrclete mo56) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5043e6o32Iqrna ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 8CC121863A;
	Mon,  2 Apr 2012 22:15:59 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ae6bf2207a4e36ca6a60b42e82f79b8de09acec3
Message-Id: <ae6bf2207a4e36ca6a60.1333397727@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04 of 18] tools/blktap: remove unneeded pointer
 dereferencing from img2qcow.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397521 -7200
# Node ID ae6bf2207a4e36ca6a60b42e82f79b8de09acec3
# Parent  90e2257cace2c3b7b8e7c4611614ad4da07ec895
tools/blktap: remove unneeded pointer dereferencing from img2qcow.c

img2qcow.c: In function 'print_bytes':
img2qcow.c:72:9: warning: value computed is not used [-Wunused-value]

Do not dereference pointer before increment.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 90e2257cace2 -r ae6bf2207a4e tools/blktap/drivers/img2qcow.c
--- a/tools/blktap/drivers/img2qcow.c
+++ b/tools/blktap/drivers/img2qcow.c
@@ -69,7 +69,7 @@ static void print_bytes(void *ptr, int l
     DFPRINTF("Buf dump, length %d:\n",length);
     for (k = 0; k < length; k++) {
         DFPRINTF("%x",*p);
-        *p++;
+        p++;
 	if(k % 16 == 0) DFPRINTF("\n");
         else if(k % 2 == 0) DFPRINTF(" ");	
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfb-0005g2-H8; Mon, 02 Apr 2012 20:16:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfX-0005cP-Uq
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:04 +0000
Received: from [85.158.143.99:38128] by server-1.bemta-4.messagelabs.com id
	91/76-20925-3090A7F4; Mon, 02 Apr 2012 20:16:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333397762!21429397!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30512 invoked from network); 2 Apr 2012 20:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Apr 2012 20:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397761; l=2521;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=qgcsVhP0MmTUYWeemVGHt2e8GP4=;
	b=dowJKN1MY3nbeYQAK8ZXsaIIZkuO2h7GNLuYauS4eSxW3LR5ACqD0L3C4iky+EOvFQ7
	8CxqFOCduR/rQmxXLqBTQLpLEXCrET838acl1iEZKd63fNL4xHsFv+rqB/Tn1tFvKHXlE
	IHbOfKkPQzDXZMp21qOhU6EZRCYAtySZ3ss=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (klopstock mo16) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L05eb6o32K7GC5 ;
	Mon, 2 Apr 2012 22:16:01 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 327A618638;
	Mon,  2 Apr 2012 22:16:01 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 5d89ebdf878b8b0647a688d0ef938bb933772d86
Message-Id: <5d89ebdf878b8b0647a6.1333397735@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:35 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12 of 18] tools/memshr: fix build errors caused
	by Werror
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397566 -7200
# Node ID 5d89ebdf878b8b0647a688d0ef938bb933772d86
# Parent  c582ef14a24cb2186c1748047a62a85fae0dbeb3
tools/memshr: fix build errors caused by Werror

-O2 -Wall -Werror triggers these warnings:

cc1: warnings being treated as errors
interface.c: In function 'memshr_daemon_initialize':
interface.c:55: error: unused variable 'h'
interface.c:54: error: unused variable 'shm_base_addr'
cc1: warnings being treated as errors
bidir-hash.h:47: error: 'fgprtshr_fgprt_hash' defined but not used
bidir-hash.h:52: error: 'fgprtshr_mfn_hash' defined but not used
bidir-hash.h:57: error: 'fgprtshr_fgprt_cmp' defined but not used
bidir-hash.h:62: error: 'fgprtshr_mfn_cmp' defined but not used
make[3]: *** [interface.o] Error 1
make[3]: *** [bidir-daemon.o] Error 1
cc1: warnings being treated as errors
bidir-hash.h:47: error: 'fgprtshr_fgprt_hash' defined but not used
bidir-hash.h:52: error: 'fgprtshr_mfn_hash' defined but not used
bidir-hash.h:57: error: 'fgprtshr_fgprt_cmp' defined but not used
bidir-hash.h:62: error: 'fgprtshr_mfn_cmp' defined but not used

Mark fingerprint functions as inline, remove unused variables.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r c582ef14a24c -r 5d89ebdf878b tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -43,22 +43,22 @@ typedef struct vbdblk {
 #undef BIDIR_VALUE
 #undef BIDIR_KEY_T
 #undef BIDIR_VALUE_T
-static uint32_t fgprtshr_fgprt_hash(uint32_t h)
+static inline uint32_t fgprtshr_fgprt_hash(uint32_t h)
 {
     return h;
 }
 
-static uint32_t fgprtshr_mfn_hash(uint64_t m)
+static inline uint32_t fgprtshr_mfn_hash(uint64_t m)
 {
     return (uint32_t)m;
 }
 
-static int fgprtshr_fgprt_cmp(uint32_t h1, uint32_t h2)
+static inline int fgprtshr_fgprt_cmp(uint32_t h1, uint32_t h2)
 {
     return (h1 == h2);
 }
 
-static int fgprtshr_mfn_cmp(uint32_t m1, uint32_t m2)
+static inline int fgprtshr_mfn_cmp(uint32_t m1, uint32_t m2)
 {
     return (m1 == m2);
 }
diff -r c582ef14a24c -r 5d89ebdf878b tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -51,9 +51,6 @@ void memshr_set_domid(int domid)
 
 void memshr_daemon_initialize(void)
 {
-    void *shm_base_addr;
-    struct fgprtshr_hash *h;
-
     memset(&memshr, 0, sizeof(private_memshr_info_t));
 
     if((SHARED_INFO = shm_shared_info_open(1)) == NULL)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfZ-0005eb-Ob; Mon, 02 Apr 2012 20:16:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cY-U0
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.138.51:34019] by server-5.bemta-3.messagelabs.com id
	FF/D2-31925-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333397761!20414944!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24991 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=961;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=ld8QOoFtSnXUNQfNJsj254PEt18=;
	b=buJCOXRatmuhQMYQwHfaBYr8cp2N3QR4If7N6T7RbLRzEFLbbvtmI/MBoKA4Fe8Rhm+
	y+zNn8RHnlLpy6EUksgFZrTjZ1k7sDer7dvu8uySE/bEEWZQ+IgNW+3X5QUUstIC9yhvr
	+xfPV7T7Hu6gcyj68gDHy4gZJMCGlkOh56k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo19) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C02789o32IlHPs ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 075BC18637;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 8d134408ddf233c6fe3a452b9b9f0780f91170e6
Message-Id: <8d134408ddf233c6fe3a.1333397729@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06 of 18] tools/blktap2: fix build errors caused
 by Werror in vhd_journal_write_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397533 -7200
# Node ID 8d134408ddf233c6fe3a452b9b9f0780f91170e6
# Parent  cbdba2284f36dba539b7f5a0cded571c96f2bc4c
tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry

-O2 -Wall -Werror triggers these warnings:

libvhd-journal.c: In function 'vhd_journal_write_entry':
libvhd-journal.c:335: warning: statement with no effect

Really return the error from vhd_journal_write() to caller.

v2:
 - simplify the patch by just adding the missing return statement

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r cbdba2284f36 -r 8d134408ddf2 tools/blktap2/vhd/lib/libvhd-journal.c
--- a/tools/blktap2/vhd/lib/libvhd-journal.c
+++ b/tools/blktap2/vhd/lib/libvhd-journal.c
@@ -332,7 +332,7 @@ vhd_journal_write_entry(vhd_journal_t *j
 
 	err = vhd_journal_write(j, &e, sizeof(vhd_journal_entry_t));
 	if (err)
-		err;
+		return err;
 
 	return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnfZ-0005eb-Ob; Mon, 02 Apr 2012 20:16:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEnfW-0005cY-U0
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:16:03 +0000
Received: from [85.158.138.51:34019] by server-5.bemta-3.messagelabs.com id
	FF/D2-31925-2090A7F4; Mon, 02 Apr 2012 20:16:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333397761!20414944!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjEwMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24991 invoked from network); 2 Apr 2012 20:16:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:16:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333397760; l=961;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=ld8QOoFtSnXUNQfNJsj254PEt18=;
	b=buJCOXRatmuhQMYQwHfaBYr8cp2N3QR4If7N6T7RbLRzEFLbbvtmI/MBoKA4Fe8Rhm+
	y+zNn8RHnlLpy6EUksgFZrTjZ1k7sDer7dvu8uySE/bEEWZQ+IgNW+3X5QUUstIC9yhvr
	+xfPV7T7Hu6gcyj68gDHy4gZJMCGlkOh56k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjAQEcXJog==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-103-210.pools.arcor-ip.net [88.65.103.210])
	by smtp.strato.de (cohen mo19) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C02789o32IlHPs ;
	Mon, 2 Apr 2012 22:16:00 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 075BC18637;
	Mon,  2 Apr 2012 22:16:00 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 8d134408ddf233c6fe3a452b9b9f0780f91170e6
Message-Id: <8d134408ddf233c6fe3a.1333397729@probook.site>
In-Reply-To: <patchbomb.1333397723@probook.site>
References: <patchbomb.1333397723@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 02 Apr 2012 22:15:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06 of 18] tools/blktap2: fix build errors caused
 by Werror in vhd_journal_write_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333397533 -7200
# Node ID 8d134408ddf233c6fe3a452b9b9f0780f91170e6
# Parent  cbdba2284f36dba539b7f5a0cded571c96f2bc4c
tools/blktap2: fix build errors caused by Werror in vhd_journal_write_entry

-O2 -Wall -Werror triggers these warnings:

libvhd-journal.c: In function 'vhd_journal_write_entry':
libvhd-journal.c:335: warning: statement with no effect

Really return the error from vhd_journal_write() to caller.

v2:
 - simplify the patch by just adding the missing return statement

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r cbdba2284f36 -r 8d134408ddf2 tools/blktap2/vhd/lib/libvhd-journal.c
--- a/tools/blktap2/vhd/lib/libvhd-journal.c
+++ b/tools/blktap2/vhd/lib/libvhd-journal.c
@@ -332,7 +332,7 @@ vhd_journal_write_entry(vhd_journal_t *j
 
 	err = vhd_journal_write(j, &e, sizeof(vhd_journal_entry_t));
 	if (err)
-		err;
+		return err;
 
 	return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwK-00009m-0B; Mon, 02 Apr 2012 20:33:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwI-00009A-1h
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:22 +0000
Received: from [85.158.138.51:43012] by server-1.bemta-3.messagelabs.com id
	AE/E9-04539-11D0A7F4; Mon, 02 Apr 2012 20:33:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333398799!20490916!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5OTAz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28377 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXB2x010737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX9jS013106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX9h5011448; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 72E3740028; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: f1da2ce71ed41d1b74ebe6916ff7710d6579438e
Message-Id: <f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1333398444@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 49
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F7A0D08.0029,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 3] xen/vga: Add 'vga_delay' parameter to
 delay screen output by X miliseconds per line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1333398408 14400
# Node ID f1da2ce71ed41d1b74ebe6916ff7710d6579438e
# Parent  1088c8557a46ab28e509bb9482e2a73a21590df8
xen/vga: Add 'vga_delay' parameter to delay screen output by X miliseconds per line.

This is useful if you find yourself on machine that has no serial console,
nor any PCI, PCIe to put in a serial card. Nothing really fancy except it allows
to capture the screenshot of the screen using a camera.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 1088c8557a46 -r f1da2ce71ed4 xen/drivers/video/vga.c
--- a/xen/drivers/video/vga.c	Fri Mar 30 21:05:54 2012 +0100
+++ b/xen/drivers/video/vga.c	Mon Apr 02 16:26:48 2012 -0400
@@ -10,7 +10,7 @@
 #include <xen/mm.h>
 #include <xen/vga.h>
 #include <asm/io.h>
-
+#include <xen/delay.h>
 /* Filled in by arch boot code. */
 struct xen_vga_console_info vga_console_info;
 
@@ -49,6 +49,12 @@ void (*vga_puts)(const char *) = vga_noo
 static char __initdata opt_vga[30] = "";
 string_param("vga", opt_vga);
 
+/*
+ * 'vga_delay=miliseconds' which defines to delay to print a line
+ * to the screen. 2 is a a good value to get a good screen output.
+ */
+unsigned int __read_mostly vga_delay;
+integer_param("vga_delay", vga_delay);
 /* VGA text-mode definitions. */
 static unsigned int columns, lines;
 #define ATTRIBUTE   7
@@ -135,6 +141,9 @@ static void vga_text_puts(const char *s)
                 ypos = lines - 1;
                 memmove(video, video + 2 * columns, ypos * 2 * columns);
                 memset(video + ypos * 2 * columns, 0, 2 * xpos);
+                if (vga_delay)
+                    mdelay(vga_delay);
+
             }
             xpos = 0;
         }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwK-00009m-0B; Mon, 02 Apr 2012 20:33:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwI-00009A-1h
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:22 +0000
Received: from [85.158.138.51:43012] by server-1.bemta-3.messagelabs.com id
	AE/E9-04539-11D0A7F4; Mon, 02 Apr 2012 20:33:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333398799!20490916!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5OTAz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28377 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXB2x010737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX9jS013106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX9h5011448; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 72E3740028; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: f1da2ce71ed41d1b74ebe6916ff7710d6579438e
Message-Id: <f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1333398444@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 49
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F7A0D08.0029,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 3] xen/vga: Add 'vga_delay' parameter to
 delay screen output by X miliseconds per line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1333398408 14400
# Node ID f1da2ce71ed41d1b74ebe6916ff7710d6579438e
# Parent  1088c8557a46ab28e509bb9482e2a73a21590df8
xen/vga: Add 'vga_delay' parameter to delay screen output by X miliseconds per line.

This is useful if you find yourself on machine that has no serial console,
nor any PCI, PCIe to put in a serial card. Nothing really fancy except it allows
to capture the screenshot of the screen using a camera.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 1088c8557a46 -r f1da2ce71ed4 xen/drivers/video/vga.c
--- a/xen/drivers/video/vga.c	Fri Mar 30 21:05:54 2012 +0100
+++ b/xen/drivers/video/vga.c	Mon Apr 02 16:26:48 2012 -0400
@@ -10,7 +10,7 @@
 #include <xen/mm.h>
 #include <xen/vga.h>
 #include <asm/io.h>
-
+#include <xen/delay.h>
 /* Filled in by arch boot code. */
 struct xen_vga_console_info vga_console_info;
 
@@ -49,6 +49,12 @@ void (*vga_puts)(const char *) = vga_noo
 static char __initdata opt_vga[30] = "";
 string_param("vga", opt_vga);
 
+/*
+ * 'vga_delay=miliseconds' which defines to delay to print a line
+ * to the screen. 2 is a a good value to get a good screen output.
+ */
+unsigned int __read_mostly vga_delay;
+integer_param("vga_delay", vga_delay);
 /* VGA text-mode definitions. */
 static unsigned int columns, lines;
 #define ATTRIBUTE   7
@@ -135,6 +141,9 @@ static void vga_text_puts(const char *s)
                 ypos = lines - 1;
                 memmove(video, video + 2 * columns, ypos * 2 * columns);
                 memset(video + ypos * 2 * columns, 0, 2 * xpos);
+                if (vga_delay)
+                    mdelay(vga_delay);
+
             }
             xpos = 0;
         }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwJ-00009Y-7W; Mon, 02 Apr 2012 20:33:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwH-000099-Ov
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:21 +0000
Received: from [85.158.143.99:60700] by server-2.bemta-4.messagelabs.com id
	94/41-17550-11D0A7F4; Mon, 02 Apr 2012 20:33:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333398799!21686596!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5OTAz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1896 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXB4u010734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX9aV017908
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX98v011449; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7738840073; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: caefa03c38366c3e70d937bc95740c5d33c0892a
Message-Id: <caefa03c38366c3e70d9.1333398446@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1333398444@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 57
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F7A0D08.0020,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 3] xen/pat: After suspend re-write PAT if
	BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Simon Graham <simon.graham@virtualcomputer.com>
# Date 1333398413 14400
# Node ID caefa03c38366c3e70d937bc95740c5d33c0892a
# Parent  f1da2ce71ed41d1b74ebe6916ff7710d6579438e
xen/pat: After suspend re-write PAT if BIOS changed it.

Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
would reset the PAT MSR causing rather weird issues - where
the pages would (say they would be set to WC) would end up with the
wrong type (as they would use the BIOS PAT instead of the one set by
the hypervisor). And in some cases the PAT was stuck and needed
a couple of WRMSRL to actually take.

Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r f1da2ce71ed4 -r caefa03c3836 xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:48 2012 -0400
+++ b/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:53 2012 -0400
@@ -41,8 +41,27 @@ static DEFINE_SPINLOCK(pm_lock);
 
 struct acpi_sleep_info acpi_sinfo;
 
+static void pat_resume(void);
 void do_suspend_lowlevel(void);
 
+static void
+pat_resume()
+{
+    u64 pat;
+    if (!cpu_has_pat)
+        return;
+
+    rdmsrl(MSR_IA32_CR_PAT, pat);
+    if (pat != host_pat) {
+	printk(KERN_INFO PREFIX "Found PAT MSR: 0x%"PRIx64"\n", pat);
+	printk(KERN_INFO PREFIX "reseting to 0x%"PRIx64"\n", host_pat);
+	wrmsrl(MSR_IA32_CR_PAT, host_pat);
+	rdmsrl(MSR_IA32_CR_PAT, pat);
+	if (pat != host_pat)
+	    printk(KERN_WARNING PREFIX "PAT MSR stuck on: 0x%"PRIx64"\n", pat);
+    }
+}
+
 static int device_power_down(void)
 {
     console_suspend();
@@ -194,6 +213,7 @@ static int enter_state(u32 state)
     if ( cpu_has_efer )
         write_efer(read_efer());
 
+    pat_resume();
     device_power_up();
 
     mcheck_init(&boot_cpu_data, 0);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwJ-00009Y-7W; Mon, 02 Apr 2012 20:33:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwH-000099-Ov
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:21 +0000
Received: from [85.158.143.99:60700] by server-2.bemta-4.messagelabs.com id
	94/41-17550-11D0A7F4; Mon, 02 Apr 2012 20:33:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333398799!21686596!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5OTAz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1896 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXB4u010734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX9aV017908
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX98v011449; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7738840073; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: caefa03c38366c3e70d937bc95740c5d33c0892a
Message-Id: <caefa03c38366c3e70d9.1333398446@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1333398444@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 57
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F7A0D08.0020,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 3] xen/pat: After suspend re-write PAT if
	BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Simon Graham <simon.graham@virtualcomputer.com>
# Date 1333398413 14400
# Node ID caefa03c38366c3e70d937bc95740c5d33c0892a
# Parent  f1da2ce71ed41d1b74ebe6916ff7710d6579438e
xen/pat: After suspend re-write PAT if BIOS changed it.

Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
would reset the PAT MSR causing rather weird issues - where
the pages would (say they would be set to WC) would end up with the
wrong type (as they would use the BIOS PAT instead of the one set by
the hypervisor). And in some cases the PAT was stuck and needed
a couple of WRMSRL to actually take.

Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r f1da2ce71ed4 -r caefa03c3836 xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:48 2012 -0400
+++ b/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:53 2012 -0400
@@ -41,8 +41,27 @@ static DEFINE_SPINLOCK(pm_lock);
 
 struct acpi_sleep_info acpi_sinfo;
 
+static void pat_resume(void);
 void do_suspend_lowlevel(void);
 
+static void
+pat_resume()
+{
+    u64 pat;
+    if (!cpu_has_pat)
+        return;
+
+    rdmsrl(MSR_IA32_CR_PAT, pat);
+    if (pat != host_pat) {
+	printk(KERN_INFO PREFIX "Found PAT MSR: 0x%"PRIx64"\n", pat);
+	printk(KERN_INFO PREFIX "reseting to 0x%"PRIx64"\n", host_pat);
+	wrmsrl(MSR_IA32_CR_PAT, host_pat);
+	rdmsrl(MSR_IA32_CR_PAT, pat);
+	if (pat != host_pat)
+	    printk(KERN_WARNING PREFIX "PAT MSR stuck on: 0x%"PRIx64"\n", pat);
+    }
+}
+
 static int device_power_down(void)
 {
     console_suspend();
@@ -194,6 +213,7 @@ static int enter_state(u32 state)
     if ( cpu_has_efer )
         write_efer(read_efer());
 
+    pat_resume();
     device_power_up();
 
     mcheck_init(&boot_cpu_data, 0);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwI-00009R-Rf; Mon, 02 Apr 2012 20:33:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwH-000098-Ev
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:21 +0000
Received: from [85.158.143.35:25094] by server-3.bemta-4.messagelabs.com id
	64/B4-05853-01D0A7F4; Mon, 02 Apr 2012 20:33:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333398798!8181228!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzMwNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8173 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXBBw026207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX931024577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX9Hs011450; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8066E4031C; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: f789a3effeb6f876b9672e6e64bbd98857f59b61
Message-Id: <f789a3effeb6f876b967.1333398447@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1333398444@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 46
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F7A0D08.004A,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3 of 3] xend: Don't crash due to weird PCI
	devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1333398413 14400
# Node ID f789a3effeb6f876b9672e6e64bbd98857f59b61
# Parent  caefa03c38366c3e70d937bc95740c5d33c0892a
xend: Don't crash due to weird PCI devices

This fixes Red Hat BZ 767742 where a user had some truly
weird PCI devices:

$ lspci -vvv -xxx -s 0000:01:00.0
01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
ff) (prog-if ff)
 !!! Unknown header type 7f
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

And xend would report:

ERROR (pci:1272) Caught 'Looped capability chain: 0000:01:00.0'

This fixes it.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r caefa03c3836 -r f789a3effeb6 tools/python/xen/util/pci.py
--- a/tools/python/xen/util/pci.py	Mon Apr 02 16:26:53 2012 -0400
+++ b/tools/python/xen/util/pci.py	Mon Apr 02 16:26:53 2012 -0400
@@ -1268,7 +1268,12 @@ class PciDevice:
             pass
 
     def get_info_from_sysfs(self):
-        self.find_capability(0x11)
+        try:
+            self.find_capability(0x11)
+        except PciDeviceParseError, err:
+            log.error("Caught '%s'" % err)
+            return False
+
         sysfs_mnt = find_sysfs_mnt()
         if sysfs_mnt == None:
             return False



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwI-00009R-Rf; Mon, 02 Apr 2012 20:33:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwH-000098-Ev
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:21 +0000
Received: from [85.158.143.35:25094] by server-3.bemta-4.messagelabs.com id
	64/B4-05853-01D0A7F4; Mon, 02 Apr 2012 20:33:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333398798!8181228!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzMwNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8173 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXBBw026207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX931024577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX9Hs011450; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8066E4031C; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: f789a3effeb6f876b9672e6e64bbd98857f59b61
Message-Id: <f789a3effeb6f876b967.1333398447@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1333398444@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 46
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F7A0D08.004A,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3 of 3] xend: Don't crash due to weird PCI
	devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1333398413 14400
# Node ID f789a3effeb6f876b9672e6e64bbd98857f59b61
# Parent  caefa03c38366c3e70d937bc95740c5d33c0892a
xend: Don't crash due to weird PCI devices

This fixes Red Hat BZ 767742 where a user had some truly
weird PCI devices:

$ lspci -vvv -xxx -s 0000:01:00.0
01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
ff) (prog-if ff)
 !!! Unknown header type 7f
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

And xend would report:

ERROR (pci:1272) Caught 'Looped capability chain: 0000:01:00.0'

This fixes it.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r caefa03c3836 -r f789a3effeb6 tools/python/xen/util/pci.py
--- a/tools/python/xen/util/pci.py	Mon Apr 02 16:26:53 2012 -0400
+++ b/tools/python/xen/util/pci.py	Mon Apr 02 16:26:53 2012 -0400
@@ -1268,7 +1268,12 @@ class PciDevice:
             pass
 
     def get_info_from_sysfs(self):
-        self.find_capability(0x11)
+        try:
+            self.find_capability(0x11)
+        except PciDeviceParseError, err:
+            log.error("Caught '%s'" % err)
+            return False
+
         sysfs_mnt = find_sysfs_mnt()
         if sysfs_mnt == None:
             return False



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwJ-00009f-Jx; Mon, 02 Apr 2012 20:33:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwH-000098-VE
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:22 +0000
Received: from [85.158.143.35:55672] by server-3.bemta-4.messagelabs.com id
	D4/B4-05853-01D0A7F4; Mon, 02 Apr 2012 20:33:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333398799!13581563!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5MzEw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7470 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXBVv010731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX9X3020942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX9Pi001276; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6D65A4004E; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F7A0D08.0023,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 3] Patches for Xen 4.2 (v2).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Patches that were posted last week - with review comments
addressed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:33:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEnwJ-00009f-Jx; Mon, 02 Apr 2012 20:33:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SEnwH-000098-VE
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:33:22 +0000
Received: from [85.158.143.35:55672] by server-3.bemta-4.messagelabs.com id
	D4/B4-05853-01D0A7F4; Mon, 02 Apr 2012 20:33:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333398799!13581563!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5MzEw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7470 invoked from network); 2 Apr 2012 20:33:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Apr 2012 20:33:20 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q32KXBVv010731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Apr 2012 20:33:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q32KX9X3020942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2012 20:33:10 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q32KX9Pi001276; Mon, 2 Apr 2012 15:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 02 Apr 2012 13:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6D65A4004E; Mon,  2 Apr 2012 16:28:34 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1333398444@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 02 Apr 2012 16:27:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	jbeulich@suse.com
Status: RO
Lines: 3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F7A0D08.0023,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 3] Patches for Xen 4.2 (v2).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Patches that were posted last week - with review comments
addressed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:50:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEoCN-0000pe-IJ; Mon, 02 Apr 2012 20:49:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEoCL-0000pX-AQ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:49:57 +0000
Received: from [85.158.143.99:27450] by server-1.bemta-4.messagelabs.com id
	24/F9-20925-4F01A7F4; Mon, 02 Apr 2012 20:49:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333399796!23448707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2915 invoked from network); 2 Apr 2012 20:49:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 20:49:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="11731316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 20:49:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 21:49:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEoCJ-0005z9-JW;
	Mon, 02 Apr 2012 20:49:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEoCJ-0005ia-E3;
	Mon, 02 Apr 2012 21:49:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12545-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 21:49:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12545: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12545 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12545/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 12542
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12542

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d90c658de78a
baseline version:
 xen                  1088c8557a46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d90c658de78a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable d90c658de78a
+ branch=xen-unstable
+ revision=d90c658de78a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d90c658de78a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 7 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 20:50:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 20:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEoCN-0000pe-IJ; Mon, 02 Apr 2012 20:49:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEoCL-0000pX-AQ
	for xen-devel@lists.xensource.com; Mon, 02 Apr 2012 20:49:57 +0000
Received: from [85.158.143.99:27450] by server-1.bemta-4.messagelabs.com id
	24/F9-20925-4F01A7F4; Mon, 02 Apr 2012 20:49:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333399796!23448707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2915 invoked from network); 2 Apr 2012 20:49:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 20:49:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="11731316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Apr 2012 20:49:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Apr 2012 21:49:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEoCJ-0005z9-JW;
	Mon, 02 Apr 2012 20:49:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEoCJ-0005ia-E3;
	Mon, 02 Apr 2012 21:49:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12545-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Apr 2012 21:49:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12545: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12545 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12545/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 12542
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12542

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d90c658de78a
baseline version:
 xen                  1088c8557a46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d90c658de78a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable d90c658de78a
+ branch=xen-unstable
+ revision=d90c658de78a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d90c658de78a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 7 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 02 21:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 21:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEpCF-0001Vf-Rq; Mon, 02 Apr 2012 21:53:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SEpCD-0001Va-Vm
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 21:53:54 +0000
Received: from [85.158.139.83:47100] by server-9.bemta-5.messagelabs.com id
	21/15-09826-1FF1A7F4; Mon, 02 Apr 2012 21:53:53 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333403630!14792847!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.8 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	INFO_TLD,ML_RADAR_SPEW_LINKS_23,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8354 invoked from network); 2 Apr 2012 21:53:51 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 21:53:51 -0000
Received: by qadb15 with SMTP id b15so2740640qad.16
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 14:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lSbCuCe01Z7+4lWX47eFCdCOyo3KyL2PQfmI8wjxs/Q=;
	b=XkD5GLDDDeFPJMGEsLhcK/Qm1flf4BmgUN2zVXnHoODM7PqvuNi3P6v3gwkWYau0Up
	8cYnd1iZIEgU6omjoFFYK97enfsqC4te5OzccyMH5okQJ6CjEw5aple/n5AGgiVRg33s
	5h9ix356cpPabhNuWYf8r1bPmL3hfjlofShoLxhs5H9+o4nTdebOKVpdV4a+dGfBtACo
	JFSTsVIvBsxIfulzBLGLK4IUhXEH5IuWu6l22k+n72aggVNrwepFXKe7aMIZp/L5oxfN
	ocLGaF3MpSr3eSOhbqIT6/WWnf73Yk1jckHJLlNcdqxe1W6JJJgaz2b8UleUa+hrQ4/v
	SVHw==
MIME-Version: 1.0
Received: by 10.229.69.92 with SMTP id y28mr4133754qci.33.1333403630293; Mon,
	02 Apr 2012 14:53:50 -0700 (PDT)
Received: by 10.229.2.5 with HTTP; Mon, 2 Apr 2012 14:53:50 -0700 (PDT)
In-Reply-To: <CAL08nMG=JjD7ffW9xBAnL54B-fv-EZ6aZULrjpSOLcdENRFUsA@mail.gmail.com>
References: <CAL08nME0XFpStLK_3v3FAxQXRm9oUFAiUuHbq+ydOXNuddZLkw@mail.gmail.com>
	<1332949412.2485.109.camel@leeds.uk.xensource.com>
	<CAL08nMG=JjD7ffW9xBAnL54B-fv-EZ6aZULrjpSOLcdENRFUsA@mail.gmail.com>
Date: Mon, 2 Apr 2012 23:53:50 +0200
X-Google-Sender-Auth: 0F1gz9N81xzJZ5EnfySsmCZDdNM
Message-ID: <CAL08nMFnWVLMHVxP7DdkRZn5-uGqT6PcoyYtXqVs1G_fTDYXcQ@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: Wei Liu <wei.liu2@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Crash/trace when starting oprofile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8406138511222916362=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8406138511222916362==
Content-Type: multipart/alternative; boundary=485b3918ac20b9d47704bcb939c0

--485b3918ac20b9d47704bcb939c0
Content-Type: text/plain; charset=ISO-8859-1

I tried the patches on a vanilla 3.2.13 kernel (patches applied cleanly
\o/) with success!

In case this is helps anybody in the future, the issue here was that
ubuntu's 3.0.0.x kernels with xen-hypervisor 4.1.1 and oprofile 0.9.6 did
not work properly.
In addition to building a stock kernel, I had to build the hypervisor from
source in order to obtain the xen-syms image corresponding to hypervisor
version 4.1.1, the one you specify with --xen to oprofile. (I did this with
apt-get source in order to ensure that I was obtaining the same version).

Thank you for your help,

Pablo

On Wed, Mar 28, 2012 at 10:59 PM, Pablo Llopis <pllopis@arcos.inf.uc3m.es>wrote:

> Thank you, I will try Michael's patches on a vanilla 3.0 or 3.2 kernel and
> report back.
> However, on first sight the patches enable profiling on unprivileged
> guests (although the author calls it passive profiling, which as far as I
> know is the opposite), and I am trying to do unprivileged dom0 profiling.
> Lets hope this helps!
>
>
> On Wed, Mar 28, 2012 at 5:43 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>
>> On Wed, 2012-03-28 at 15:55 +0100, Pablo Llopis wrote:
>> > Hello Xen developers,
>> >
>> >
>> > I sent a similar message to xen-users about a week ago, did not obtain
>> > any response and only now realized that I should have sent this here
>> > instead (http://xenoprof.sourceforge.net/ says to write to this list).
>> > Apologies if you see this message twice.
>> >
>>
>> There are some patches floating around on xen-devel:
>>
>> http://marc.info/?l=xen-devel&m=132779518918042&w=2
>> http://marc.info/?l=xen-devel&m=132708552318073&w=2
>>
>>
>>
>> Wei.
>>
>>
>>
>

--485b3918ac20b9d47704bcb939c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I tried the patches on a vanilla 3.2.13 kernel (patches applied cleanly \o/=
) with success!<div><br></div><div>In case this is helps anybody in the fut=
ure, the issue here was that ubuntu&#39;s 3.0.0.x kernels with xen-hypervis=
or 4.1.1 and oprofile 0.9.6 did not work properly.=A0</div>
<div>In addition to building a stock kernel, I had to build the hypervisor =
from source in order to obtain the xen-syms image corresponding to hypervis=
or version 4.1.1, the one you specify with --xen to oprofile. (I did this w=
ith apt-get source in order to ensure that I was obtaining the same version=
).</div>
<div><br></div><div>Thank you for your help,</div><div><br></div><div>Pablo=
</div><br><div class=3D"gmail_quote">On Wed, Mar 28, 2012 at 10:59 PM, Pabl=
o Llopis <span dir=3D"ltr">&lt;<a href=3D"mailto:pllopis@arcos.inf.uc3m.es"=
>pllopis@arcos.inf.uc3m.es</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Thank you, I will try Michael&#39;s patches =
on a vanilla 3.0 or 3.2 kernel and report back.<div>However, on first sight=
 the patches enable profiling on unprivileged guests (although the author c=
alls it passive profiling, which as far as I know is the opposite), and I a=
m trying to do unprivileged dom0 profiling. Lets hope this helps!<div>
<div class=3D"h5"><span></span><br>
<br><div class=3D"gmail_quote">On Wed, Mar 28, 2012 at 5:43 PM, Wei Liu <sp=
an dir=3D"ltr">&lt;<a>wei.liu2@citrix.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Wed, 2012-03-28 at 15:55 +0100, Pabl=
o Llopis wrote:<br>
&gt; Hello Xen developers,<br>
&gt;<br>
&gt;<br>
&gt; I sent a similar message to xen-users about a week ago, did not obtain=
<br>
&gt; any response and only now realized that I should have sent this here<b=
r>
&gt; instead (<a href=3D"http://xenoprof.sourceforge.net/" target=3D"_blank=
">http://xenoprof.sourceforge.net/</a> says to write to this list).<br>
&gt; Apologies if you see this message twice.<br>
&gt;<br>
<br>
</div>There are some patches floating around on xen-devel:<br>
<br>
<a href=3D"http://marc.info/?l=3Dxen-devel&amp;m=3D132779518918042&amp;w=3D=
2" target=3D"_blank">http://marc.info/?l=3Dxen-devel&amp;m=3D13277951891804=
2&amp;w=3D2</a><br>
<a href=3D"http://marc.info/?l=3Dxen-devel&amp;m=3D132708552318073&amp;w=3D=
2" target=3D"_blank">http://marc.info/?l=3Dxen-devel&amp;m=3D13270855231807=
3&amp;w=3D2</a><br>
<span><font color=3D"#888888"><br>
<br>
<br>
Wei.<br>
<br>
<br>
</font></span></blockquote></div><br></div></div></div>
</blockquote></div><br>

--485b3918ac20b9d47704bcb939c0--


--===============8406138511222916362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8406138511222916362==--


From xen-devel-bounces@lists.xen.org Mon Apr 02 21:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Apr 2012 21:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEpCF-0001Vf-Rq; Mon, 02 Apr 2012 21:53:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SEpCD-0001Va-Vm
	for xen-devel@lists.xen.org; Mon, 02 Apr 2012 21:53:54 +0000
Received: from [85.158.139.83:47100] by server-9.bemta-5.messagelabs.com id
	21/15-09826-1FF1A7F4; Mon, 02 Apr 2012 21:53:53 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333403630!14792847!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.8 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	INFO_TLD,ML_RADAR_SPEW_LINKS_23,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8354 invoked from network); 2 Apr 2012 21:53:51 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Apr 2012 21:53:51 -0000
Received: by qadb15 with SMTP id b15so2740640qad.16
	for <xen-devel@lists.xen.org>; Mon, 02 Apr 2012 14:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lSbCuCe01Z7+4lWX47eFCdCOyo3KyL2PQfmI8wjxs/Q=;
	b=XkD5GLDDDeFPJMGEsLhcK/Qm1flf4BmgUN2zVXnHoODM7PqvuNi3P6v3gwkWYau0Up
	8cYnd1iZIEgU6omjoFFYK97enfsqC4te5OzccyMH5okQJ6CjEw5aple/n5AGgiVRg33s
	5h9ix356cpPabhNuWYf8r1bPmL3hfjlofShoLxhs5H9+o4nTdebOKVpdV4a+dGfBtACo
	JFSTsVIvBsxIfulzBLGLK4IUhXEH5IuWu6l22k+n72aggVNrwepFXKe7aMIZp/L5oxfN
	ocLGaF3MpSr3eSOhbqIT6/WWnf73Yk1jckHJLlNcdqxe1W6JJJgaz2b8UleUa+hrQ4/v
	SVHw==
MIME-Version: 1.0
Received: by 10.229.69.92 with SMTP id y28mr4133754qci.33.1333403630293; Mon,
	02 Apr 2012 14:53:50 -0700 (PDT)
Received: by 10.229.2.5 with HTTP; Mon, 2 Apr 2012 14:53:50 -0700 (PDT)
In-Reply-To: <CAL08nMG=JjD7ffW9xBAnL54B-fv-EZ6aZULrjpSOLcdENRFUsA@mail.gmail.com>
References: <CAL08nME0XFpStLK_3v3FAxQXRm9oUFAiUuHbq+ydOXNuddZLkw@mail.gmail.com>
	<1332949412.2485.109.camel@leeds.uk.xensource.com>
	<CAL08nMG=JjD7ffW9xBAnL54B-fv-EZ6aZULrjpSOLcdENRFUsA@mail.gmail.com>
Date: Mon, 2 Apr 2012 23:53:50 +0200
X-Google-Sender-Auth: 0F1gz9N81xzJZ5EnfySsmCZDdNM
Message-ID: <CAL08nMFnWVLMHVxP7DdkRZn5-uGqT6PcoyYtXqVs1G_fTDYXcQ@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: Wei Liu <wei.liu2@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Crash/trace when starting oprofile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8406138511222916362=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8406138511222916362==
Content-Type: multipart/alternative; boundary=485b3918ac20b9d47704bcb939c0

--485b3918ac20b9d47704bcb939c0
Content-Type: text/plain; charset=ISO-8859-1

I tried the patches on a vanilla 3.2.13 kernel (patches applied cleanly
\o/) with success!

In case this is helps anybody in the future, the issue here was that
ubuntu's 3.0.0.x kernels with xen-hypervisor 4.1.1 and oprofile 0.9.6 did
not work properly.
In addition to building a stock kernel, I had to build the hypervisor from
source in order to obtain the xen-syms image corresponding to hypervisor
version 4.1.1, the one you specify with --xen to oprofile. (I did this with
apt-get source in order to ensure that I was obtaining the same version).

Thank you for your help,

Pablo

On Wed, Mar 28, 2012 at 10:59 PM, Pablo Llopis <pllopis@arcos.inf.uc3m.es>wrote:

> Thank you, I will try Michael's patches on a vanilla 3.0 or 3.2 kernel and
> report back.
> However, on first sight the patches enable profiling on unprivileged
> guests (although the author calls it passive profiling, which as far as I
> know is the opposite), and I am trying to do unprivileged dom0 profiling.
> Lets hope this helps!
>
>
> On Wed, Mar 28, 2012 at 5:43 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>
>> On Wed, 2012-03-28 at 15:55 +0100, Pablo Llopis wrote:
>> > Hello Xen developers,
>> >
>> >
>> > I sent a similar message to xen-users about a week ago, did not obtain
>> > any response and only now realized that I should have sent this here
>> > instead (http://xenoprof.sourceforge.net/ says to write to this list).
>> > Apologies if you see this message twice.
>> >
>>
>> There are some patches floating around on xen-devel:
>>
>> http://marc.info/?l=xen-devel&m=132779518918042&w=2
>> http://marc.info/?l=xen-devel&m=132708552318073&w=2
>>
>>
>>
>> Wei.
>>
>>
>>
>

--485b3918ac20b9d47704bcb939c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I tried the patches on a vanilla 3.2.13 kernel (patches applied cleanly \o/=
) with success!<div><br></div><div>In case this is helps anybody in the fut=
ure, the issue here was that ubuntu&#39;s 3.0.0.x kernels with xen-hypervis=
or 4.1.1 and oprofile 0.9.6 did not work properly.=A0</div>
<div>In addition to building a stock kernel, I had to build the hypervisor =
from source in order to obtain the xen-syms image corresponding to hypervis=
or version 4.1.1, the one you specify with --xen to oprofile. (I did this w=
ith apt-get source in order to ensure that I was obtaining the same version=
).</div>
<div><br></div><div>Thank you for your help,</div><div><br></div><div>Pablo=
</div><br><div class=3D"gmail_quote">On Wed, Mar 28, 2012 at 10:59 PM, Pabl=
o Llopis <span dir=3D"ltr">&lt;<a href=3D"mailto:pllopis@arcos.inf.uc3m.es"=
>pllopis@arcos.inf.uc3m.es</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Thank you, I will try Michael&#39;s patches =
on a vanilla 3.0 or 3.2 kernel and report back.<div>However, on first sight=
 the patches enable profiling on unprivileged guests (although the author c=
alls it passive profiling, which as far as I know is the opposite), and I a=
m trying to do unprivileged dom0 profiling. Lets hope this helps!<div>
<div class=3D"h5"><span></span><br>
<br><div class=3D"gmail_quote">On Wed, Mar 28, 2012 at 5:43 PM, Wei Liu <sp=
an dir=3D"ltr">&lt;<a>wei.liu2@citrix.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Wed, 2012-03-28 at 15:55 +0100, Pabl=
o Llopis wrote:<br>
&gt; Hello Xen developers,<br>
&gt;<br>
&gt;<br>
&gt; I sent a similar message to xen-users about a week ago, did not obtain=
<br>
&gt; any response and only now realized that I should have sent this here<b=
r>
&gt; instead (<a href=3D"http://xenoprof.sourceforge.net/" target=3D"_blank=
">http://xenoprof.sourceforge.net/</a> says to write to this list).<br>
&gt; Apologies if you see this message twice.<br>
&gt;<br>
<br>
</div>There are some patches floating around on xen-devel:<br>
<br>
<a href=3D"http://marc.info/?l=3Dxen-devel&amp;m=3D132779518918042&amp;w=3D=
2" target=3D"_blank">http://marc.info/?l=3Dxen-devel&amp;m=3D13277951891804=
2&amp;w=3D2</a><br>
<a href=3D"http://marc.info/?l=3Dxen-devel&amp;m=3D132708552318073&amp;w=3D=
2" target=3D"_blank">http://marc.info/?l=3Dxen-devel&amp;m=3D13270855231807=
3&amp;w=3D2</a><br>
<span><font color=3D"#888888"><br>
<br>
<br>
Wei.<br>
<br>
<br>
</font></span></blockquote></div><br></div></div></div>
</blockquote></div><br>

--485b3918ac20b9d47704bcb939c0--


--===============8406138511222916362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8406138511222916362==--


From xen-devel-bounces@lists.xen.org Tue Apr 03 01:36:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 01:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEseT-0006Uo-MS; Tue, 03 Apr 2012 01:35:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreww591@gmail.com>) id 1SEseR-0006Uf-Vc
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 01:35:16 +0000
Received: from [85.158.143.35:8641] by server-2.bemta-4.messagelabs.com id
	E9/6D-17550-3D35A7F4; Tue, 03 Apr 2012 01:35:15 +0000
X-Env-Sender: andreww591@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333416912!5318248!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16255 invoked from network); 3 Apr 2012 01:35:14 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 01:35:14 -0000
Received: by iafj26 with SMTP id j26so6367614iaf.32
	for <multiple recipients>; Mon, 02 Apr 2012 18:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=O2uIIC7BiKJlbZbGnAxYiILF+aSKDQjO/Kh//Wtz7uM=;
	b=vhR0AyCwYRZEZO1vdoWnWZPp6gVMXvBud3eRHzu899uKF0TkGFTW7QavCJLu4/3QCZ
	ZAtI3NmBr4Rq+p/yvfHPYGbkQ4DxgKzHVBD/BUlAXFiex6TG2LszxwQ2B8p9fBj0hJ8h
	AwKtrk2M6s3ioyX800x6cqG6uFPJObVnDCyBAtPPMnmJXRv+NyAskMzT3vmMk+vfgpDW
	e0aAD53m3eD1/lt6t/iGs5vCO03idgjFzTFai9nMeU/lbX6t3lKex+x74luYjAazIPmj
	6lQpZTwAUJ1fcI86trnZBF6kBB4JbG2xz2V3ye/F5uZQoQdpVla0rUesOWvH7U5WgQCy
	g69Q==
MIME-Version: 1.0
Received: by 10.50.153.165 with SMTP id vh5mr169932igb.4.1333416912039; Mon,
	02 Apr 2012 18:35:12 -0700 (PDT)
Received: by 10.231.133.201 with HTTP; Mon, 2 Apr 2012 18:35:11 -0700 (PDT)
In-Reply-To: <CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
References: <CAA7N5RYjC4Y+zsd2C25muQ12n8=UmNy0=eS-Y0rD_s9R0sx3DQ@mail.gmail.com>
	<4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com>
	<4F74C205.9070104@amd.com>
	<CAA7N5RZVYcpzHdkdZ2_EY1R8OMGNEbmvrXnFaMFxOM7wrUvLjQ@mail.gmail.com>
	<4F74EA35.4030305@amd.com> <20120331104907.GV12984@reaktio.net>
	<CACC+8CQJxm_s1ZKVOU6PpgzPYiDKC75_sTTYQXBg9w4W81t2Mg@mail.gmail.com>
	<20120331111926.GY12984@reaktio.net>
	<CACC+8CReA_5P8RD3+NNRf0g7VvcrSFxQ=cuYoHq5c0p1p1jvmQ@mail.gmail.com>
	<20120331151104.GZ12984@reaktio.net>
	<CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
Date: Mon, 2 Apr 2012 19:35:11 -0600
Message-ID: <CAD-qYGr3sE3hfnDcMBG6q7+_S+vSM_YPGn_Sff8wH116SXTN6w@mail.gmail.com>
From: Andrew Warkentin <andreww591@gmail.com>
To: xen-users@lists.xen.org
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to
 Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3/31/12, Casey DeLorme <cdelorme@gmail.com> wrote:
> Hi Pasi,
>
> I can confirm that their GPU Passthrough works with consumer models, they
> visited my college and presented a 30 minute demonstration video where they
> acknowledged this.
>
> Wei stated that XenClient ahs a "customized ATI component", and I am quite
> certain he is aware our discussion is about consumer models.
>
>
> XenClient comes with XenDesktop, they market to the on-the-go businessman
> so it was designed with laptops in mind, but I am quite sure it would run
> on a tower.
>
> ~Casey
>

As far as I know, XenClient AMD GPU passthrough only works on 8 models
of HP laptops. This is because it uses filtered passthrough in which
the dom0 graphics server does some extremely model-specific voodoo
with contexts (presumably involving rewriting of GPU commands to limit
them to a particular region of graphics memory) to share the GPU. Poor
support for AMD GPUs in XenClient is a big part of why I am making my
own desktop Xen/Linux distribution, OpenXCI
<http://sourceforge.net/projects/openxci/>. It will support both
primary and secondary AMD GPU passthrough (rather than XenClient-style
filtered passthrough, it will use conventional passthrough for one
domain and a viewer running on that domain to display all other
domains).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 01:36:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 01:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEseT-0006Uo-MS; Tue, 03 Apr 2012 01:35:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreww591@gmail.com>) id 1SEseR-0006Uf-Vc
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 01:35:16 +0000
Received: from [85.158.143.35:8641] by server-2.bemta-4.messagelabs.com id
	E9/6D-17550-3D35A7F4; Tue, 03 Apr 2012 01:35:15 +0000
X-Env-Sender: andreww591@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333416912!5318248!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16255 invoked from network); 3 Apr 2012 01:35:14 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 01:35:14 -0000
Received: by iafj26 with SMTP id j26so6367614iaf.32
	for <multiple recipients>; Mon, 02 Apr 2012 18:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=O2uIIC7BiKJlbZbGnAxYiILF+aSKDQjO/Kh//Wtz7uM=;
	b=vhR0AyCwYRZEZO1vdoWnWZPp6gVMXvBud3eRHzu899uKF0TkGFTW7QavCJLu4/3QCZ
	ZAtI3NmBr4Rq+p/yvfHPYGbkQ4DxgKzHVBD/BUlAXFiex6TG2LszxwQ2B8p9fBj0hJ8h
	AwKtrk2M6s3ioyX800x6cqG6uFPJObVnDCyBAtPPMnmJXRv+NyAskMzT3vmMk+vfgpDW
	e0aAD53m3eD1/lt6t/iGs5vCO03idgjFzTFai9nMeU/lbX6t3lKex+x74luYjAazIPmj
	6lQpZTwAUJ1fcI86trnZBF6kBB4JbG2xz2V3ye/F5uZQoQdpVla0rUesOWvH7U5WgQCy
	g69Q==
MIME-Version: 1.0
Received: by 10.50.153.165 with SMTP id vh5mr169932igb.4.1333416912039; Mon,
	02 Apr 2012 18:35:12 -0700 (PDT)
Received: by 10.231.133.201 with HTTP; Mon, 2 Apr 2012 18:35:11 -0700 (PDT)
In-Reply-To: <CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
References: <CAA7N5RYjC4Y+zsd2C25muQ12n8=UmNy0=eS-Y0rD_s9R0sx3DQ@mail.gmail.com>
	<4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com>
	<4F74C205.9070104@amd.com>
	<CAA7N5RZVYcpzHdkdZ2_EY1R8OMGNEbmvrXnFaMFxOM7wrUvLjQ@mail.gmail.com>
	<4F74EA35.4030305@amd.com> <20120331104907.GV12984@reaktio.net>
	<CACC+8CQJxm_s1ZKVOU6PpgzPYiDKC75_sTTYQXBg9w4W81t2Mg@mail.gmail.com>
	<20120331111926.GY12984@reaktio.net>
	<CACC+8CReA_5P8RD3+NNRf0g7VvcrSFxQ=cuYoHq5c0p1p1jvmQ@mail.gmail.com>
	<20120331151104.GZ12984@reaktio.net>
	<CAA7N5RYoF9kdAGH6xD0_vKUusLGzq1iiTvWR9yvgDNLmUE-qHA@mail.gmail.com>
Date: Mon, 2 Apr 2012 19:35:11 -0600
Message-ID: <CAD-qYGr3sE3hfnDcMBG6q7+_S+vSM_YPGn_Sff8wH116SXTN6w@mail.gmail.com>
From: Andrew Warkentin <andreww591@gmail.com>
To: xen-users@lists.xen.org
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to
 Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 3/31/12, Casey DeLorme <cdelorme@gmail.com> wrote:
> Hi Pasi,
>
> I can confirm that their GPU Passthrough works with consumer models, they
> visited my college and presented a 30 minute demonstration video where they
> acknowledged this.
>
> Wei stated that XenClient ahs a "customized ATI component", and I am quite
> certain he is aware our discussion is about consumer models.
>
>
> XenClient comes with XenDesktop, they market to the on-the-go businessman
> so it was designed with laptops in mind, but I am quite sure it would run
> on a tower.
>
> ~Casey
>

As far as I know, XenClient AMD GPU passthrough only works on 8 models
of HP laptops. This is because it uses filtered passthrough in which
the dom0 graphics server does some extremely model-specific voodoo
with contexts (presumably involving rewriting of GPU commands to limit
them to a particular region of graphics memory) to share the GPU. Poor
support for AMD GPUs in XenClient is a big part of why I am making my
own desktop Xen/Linux distribution, OpenXCI
<http://sourceforge.net/projects/openxci/>. It will support both
primary and secondary AMD GPU passthrough (rather than XenClient-style
filtered passthrough, it will use conventional passthrough for one
domain and a viewer running on that domain to display all other
domains).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 01:56:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 01:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEsyG-00074m-IK; Tue, 03 Apr 2012 01:55:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEsyE-00074h-S6
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 01:55:43 +0000
Received: from [85.158.139.83:63477] by server-4.bemta-5.messagelabs.com id
	63/27-10788-E985A7F4; Tue, 03 Apr 2012 01:55:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333418141!22078244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1563 invoked from network); 3 Apr 2012 01:55:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 01:55:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,361,1330905600"; d="scan'208";a="11733504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 01:55:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 02:55:40 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEsyC-0007vv-5X;
	Tue, 03 Apr 2012 01:55:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEsyC-0004mY-0V;
	Tue, 03 Apr 2012 02:55:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12547-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 02:55:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12547: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12547 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12547/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 01:56:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 01:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEsyG-00074m-IK; Tue, 03 Apr 2012 01:55:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SEsyE-00074h-S6
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 01:55:43 +0000
Received: from [85.158.139.83:63477] by server-4.bemta-5.messagelabs.com id
	63/27-10788-E985A7F4; Tue, 03 Apr 2012 01:55:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333418141!22078244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1563 invoked from network); 3 Apr 2012 01:55:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 01:55:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,361,1330905600"; d="scan'208";a="11733504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 01:55:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 02:55:40 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SEsyC-0007vv-5X;
	Tue, 03 Apr 2012 01:55:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SEsyC-0004mY-0V;
	Tue, 03 Apr 2012 02:55:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12547-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 02:55:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12547: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12547 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12547/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 04:18:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 04:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEvC6-0007yt-5w; Tue, 03 Apr 2012 04:18:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SEvC5-0007yo-Ac
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 04:18:09 +0000
Received: from [85.158.143.35:13371] by server-1.bemta-4.messagelabs.com id
	E1/38-20925-FF97A7F4; Tue, 03 Apr 2012 04:18:07 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333426683!7108366!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9632 invoked from network); 3 Apr 2012 04:18:06 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Apr 2012 04:18:06 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SEvBt-00064d-BU; Tue, 03 Apr 2012 14:17:57 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Apr 2012 14:17:57 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Tue, 3 Apr 2012 14:17:57 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] qemu reverse vnc connection
Thread-Index: AQHNEOAzMu2h3BhLt0W4y/tWQAH6NpaIfuwA
Date: Tue, 3 Apr 2012 04:17:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF53FC1@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
	<alpine.DEB.2.00.1204021549280.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204021549280.15151@kaball-desktop>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Apr 2012 04:17:57.0191 (UTC)
	FILETIME=[BF862D70:01CD1150]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu reverse vnc connection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> On Sun, 1 Apr 2012, James Harper wrote:
> > I was looking at vnc.c to see what would be involved in making a reverse
> > VNC connection (vnc server connects to the client), and it looks possible but I
> > also wondered if there was any reason why libvncserver couldn't be used
> > instead? Both qemu-dm and libvncserver appear to be licensed under GPL
> > although I haven't checked what version.
> 
> A (very) long time ago a decision was made whether to use libvncserver or
> not in QEMU and now we are too far down the road to change it.
> Besides we are switching to upstream QEMU so we try to keep our changes
> to QEMU's tree as small as possible.
> 

So a change to allow qemu to connect to a proxy/repeater would best be made to upstream qemu... very well.

> 
> > I've never figured out whether it's qemu's vnc implementation or
> > VNCViewer but one of them seems pretty buggy - freezing and requiring
> > frequent refreshes under some circumstances, and occasionally not liking
> > resolution changes.
> 
> Few years ago I have done some investigations and I seem to recall that the
> problem lies with vncviewer.

Time to switch viewers then I guess!

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 04:18:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 04:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEvC6-0007yt-5w; Tue, 03 Apr 2012 04:18:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SEvC5-0007yo-Ac
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 04:18:09 +0000
Received: from [85.158.143.35:13371] by server-1.bemta-4.messagelabs.com id
	E1/38-20925-FF97A7F4; Tue, 03 Apr 2012 04:18:07 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333426683!7108366!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9632 invoked from network); 3 Apr 2012 04:18:06 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Apr 2012 04:18:06 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SEvBt-00064d-BU; Tue, 03 Apr 2012 14:17:57 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Apr 2012 14:17:57 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Tue, 3 Apr 2012 14:17:57 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] qemu reverse vnc connection
Thread-Index: AQHNEOAzMu2h3BhLt0W4y/tWQAH6NpaIfuwA
Date: Tue, 3 Apr 2012 04:17:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF53FC1@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1845D098@BITCOM1.int.sbss.com.au>
	<alpine.DEB.2.00.1204021549280.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204021549280.15151@kaball-desktop>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Apr 2012 04:17:57.0191 (UTC)
	FILETIME=[BF862D70:01CD1150]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu reverse vnc connection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> On Sun, 1 Apr 2012, James Harper wrote:
> > I was looking at vnc.c to see what would be involved in making a reverse
> > VNC connection (vnc server connects to the client), and it looks possible but I
> > also wondered if there was any reason why libvncserver couldn't be used
> > instead? Both qemu-dm and libvncserver appear to be licensed under GPL
> > although I haven't checked what version.
> 
> A (very) long time ago a decision was made whether to use libvncserver or
> not in QEMU and now we are too far down the road to change it.
> Besides we are switching to upstream QEMU so we try to keep our changes
> to QEMU's tree as small as possible.
> 

So a change to allow qemu to connect to a proxy/repeater would best be made to upstream qemu... very well.

> 
> > I've never figured out whether it's qemu's vnc implementation or
> > VNCViewer but one of them seems pretty buggy - freezing and requiring
> > frequent refreshes under some circumstances, and occasionally not liking
> > resolution changes.
> 
> Few years ago I have done some investigations and I seem to recall that the
> problem lies with vncviewer.

Time to switch viewers then I guess!

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 04:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 04:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEvRY-00088q-MS; Tue, 03 Apr 2012 04:34:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kuwa@jp.fujitsu.com>) id 1SEvRX-00088l-ED
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 04:34:07 +0000
Received: from [85.158.138.51:7395] by server-8.bemta-3.messagelabs.com id
	7F/DE-29305-EBD7A7F4; Tue, 03 Apr 2012 04:34:06 +0000
X-Env-Sender: kuwa@jp.fujitsu.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333427643!20348340!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDE2Nzkx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21946 invoked from network); 3 Apr 2012 04:34:05 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 04:34:05 -0000
Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 422423EE0BC;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from smail (m3 [127.0.0.1])
	by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 2B62745DE7E;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93])
	by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 100D745DEB5;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 03F121DB803F;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp
	[10.25.192.37])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id ACDDD1DB803C;
	Tue,  3 Apr 2012 13:34:00 +0900 (JST)
Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp
	[10.25.192.39])
	by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs.
	Domain Mail Master) with ESMTP id q334XlmZ003341; 
	Tue, 3 Apr 2012 13:34:00 +0900 (JST)
X-AuditID: 0a19c027-b7b67ae000002cc0-a2-4f7a7db893f0
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp
	[10.25.192.105])
	by vskawa.flab.fujitsu.co.jp (Symantec Brightmail Gateway) with SMTP id
	BC.35.11456.8BD7A7F4; Tue,  3 Apr 2012 13:34:00 +0900 (JST)
Received: from eve.cad.flab.fujitsu.co.jp (eve.cad.flab.fujitsu.co.jp
	[10.25.228.68])
	by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs.
	Kawasaki Domain Mail Master) with ESMTP id q334Y0Ml003501; 
	Tue, 3 Apr 2012 13:34:00 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by eve.cad.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id
	q334Y0xc072743; Tue, 3 Apr 2012 13:34:00 +0900 (JST)
	(envelope-from kuwa@jp.fujitsu.com)
Date: Tue, 03 Apr 2012 13:33:29 +0900 (JST)
Message-Id: <20120403.133329.137901442.kuwa@jp.fujitsu.com>
To: roger.pau@entel.upc.edu
From: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
In-Reply-To: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
References: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: Mew version 6.5rc1 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: yang.z.zhang@intel.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on
 old python versions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

>>>>> On Mon,  2 Apr 2012 11:27:46 +0100
>>>>> roger.pau@entel.upc.edu(Roger Pau Monne)  said:
> 
> Replaced the use of python-config (that is only present in Python >= 2.5.x)
> with the distutils python module.
> 
> Please run ./autogen.sh after applying the patch.
> Again, this has only been tested on OS X Python 2.7.
> Changes since v2:
>  * Added SYSLIBS to library test.
> Changes since v1:
>  * Added Python LDFLAGS to library test.

This patch worked on RHEL4U2(Python 2.3), CentOS5.7(Python 2.4) and
Fedora 16(Python 2.7).

Best regards,
-- 
  KUWAMURA Shin'ya

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 04:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 04:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEvRY-00088q-MS; Tue, 03 Apr 2012 04:34:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kuwa@jp.fujitsu.com>) id 1SEvRX-00088l-ED
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 04:34:07 +0000
Received: from [85.158.138.51:7395] by server-8.bemta-3.messagelabs.com id
	7F/DE-29305-EBD7A7F4; Tue, 03 Apr 2012 04:34:06 +0000
X-Env-Sender: kuwa@jp.fujitsu.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333427643!20348340!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDE2Nzkx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21946 invoked from network); 3 Apr 2012 04:34:05 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 04:34:05 -0000
Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 422423EE0BC;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from smail (m3 [127.0.0.1])
	by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 2B62745DE7E;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93])
	by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 100D745DEB5;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 03F121DB803F;
	Tue,  3 Apr 2012 13:34:01 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp
	[10.25.192.37])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id ACDDD1DB803C;
	Tue,  3 Apr 2012 13:34:00 +0900 (JST)
Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp
	[10.25.192.39])
	by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs.
	Domain Mail Master) with ESMTP id q334XlmZ003341; 
	Tue, 3 Apr 2012 13:34:00 +0900 (JST)
X-AuditID: 0a19c027-b7b67ae000002cc0-a2-4f7a7db893f0
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp
	[10.25.192.105])
	by vskawa.flab.fujitsu.co.jp (Symantec Brightmail Gateway) with SMTP id
	BC.35.11456.8BD7A7F4; Tue,  3 Apr 2012 13:34:00 +0900 (JST)
Received: from eve.cad.flab.fujitsu.co.jp (eve.cad.flab.fujitsu.co.jp
	[10.25.228.68])
	by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs.
	Kawasaki Domain Mail Master) with ESMTP id q334Y0Ml003501; 
	Tue, 3 Apr 2012 13:34:00 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by eve.cad.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id
	q334Y0xc072743; Tue, 3 Apr 2012 13:34:00 +0900 (JST)
	(envelope-from kuwa@jp.fujitsu.com)
Date: Tue, 03 Apr 2012 13:33:29 +0900 (JST)
Message-Id: <20120403.133329.137901442.kuwa@jp.fujitsu.com>
To: roger.pau@entel.upc.edu
From: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
In-Reply-To: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
References: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: Mew version 6.5rc1 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: yang.z.zhang@intel.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on
 old python versions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

>>>>> On Mon,  2 Apr 2012 11:27:46 +0100
>>>>> roger.pau@entel.upc.edu(Roger Pau Monne)  said:
> 
> Replaced the use of python-config (that is only present in Python >= 2.5.x)
> with the distutils python module.
> 
> Please run ./autogen.sh after applying the patch.
> Again, this has only been tested on OS X Python 2.7.
> Changes since v2:
>  * Added SYSLIBS to library test.
> Changes since v1:
>  * Added Python LDFLAGS to library test.

This patch worked on RHEL4U2(Python 2.3), CentOS5.7(Python 2.4) and
Fedora 16(Python 2.7).

Best regards,
-- 
  KUWAMURA Shin'ya

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 06:28:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 06:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SExDj-0000y9-K9; Tue, 03 Apr 2012 06:27:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SExDi-0000y4-2I
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 06:27:58 +0000
Received: from [85.158.143.35:44437] by server-3.bemta-4.messagelabs.com id
	25/AE-05853-D689A7F4; Tue, 03 Apr 2012 06:27:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333434475!7123422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22919 invoked from network); 3 Apr 2012 06:27:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 06:27:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11735654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 06:27:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 07:27:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SExDe-0001OV-Kh;
	Tue, 03 Apr 2012 06:27:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SExDe-0000Jw-Gc;
	Tue, 03 Apr 2012 07:27:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12548-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 07:27:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12548: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12548 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12548/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 12545

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12545

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  d90c658de78a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 06:28:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 06:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SExDj-0000y9-K9; Tue, 03 Apr 2012 06:27:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SExDi-0000y4-2I
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 06:27:58 +0000
Received: from [85.158.143.35:44437] by server-3.bemta-4.messagelabs.com id
	25/AE-05853-D689A7F4; Tue, 03 Apr 2012 06:27:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333434475!7123422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22919 invoked from network); 3 Apr 2012 06:27:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 06:27:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11735654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 06:27:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 07:27:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SExDe-0001OV-Kh;
	Tue, 03 Apr 2012 06:27:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SExDe-0000Jw-Gc;
	Tue, 03 Apr 2012 07:27:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12548-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 07:27:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12548: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12548 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12548/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 12545

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12545

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  d90c658de78a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 07:15:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 07:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SExx3-0001OM-Uy; Tue, 03 Apr 2012 07:14:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SExx2-0001OG-FW
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 07:14:48 +0000
Received: from [85.158.138.51:9035] by server-11.bemta-3.messagelabs.com id
	9F/5B-12049-763AA7F4; Tue, 03 Apr 2012 07:14:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333437286!20494596!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24605 invoked from network); 3 Apr 2012 07:14:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 07:14:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 08:16:32 +0100
Message-Id: <4F7ABF83020000780007C3B0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 08:14:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
	<f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
In-Reply-To: <f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] xen/vga: Add 'vga_delay' parameter
 to delay screen output by X miliseconds per line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.04.12 at 22:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1333398408 14400
> # Node ID f1da2ce71ed41d1b74ebe6916ff7710d6579438e
> # Parent  1088c8557a46ab28e509bb9482e2a73a21590df8
> xen/vga: Add 'vga_delay' parameter to delay screen output by X miliseconds 
> per line.
> 
> This is useful if you find yourself on machine that has no serial console,
> nor any PCI, PCIe to put in a serial card. Nothing really fancy except it 
> allows
> to capture the screenshot of the screen using a camera.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r 1088c8557a46 -r f1da2ce71ed4 xen/drivers/video/vga.c
> --- a/xen/drivers/video/vga.c	Fri Mar 30 21:05:54 2012 +0100
> +++ b/xen/drivers/video/vga.c	Mon Apr 02 16:26:48 2012 -0400
> @@ -10,7 +10,7 @@
>  #include <xen/mm.h>
>  #include <xen/vga.h>
>  #include <asm/io.h>
> -
> +#include <xen/delay.h>
>  /* Filled in by arch boot code. */
>  struct xen_vga_console_info vga_console_info;
>  
> @@ -49,6 +49,12 @@ void (*vga_puts)(const char *) = vga_noo
>  static char __initdata opt_vga[30] = "";
>  string_param("vga", opt_vga);
>  
> +/*
> + * 'vga_delay=miliseconds' which defines to delay to print a line
> + * to the screen. 2 is a a good value to get a good screen output.

Maybe add something like "If you need to use this, do so with care
as it might screw up time handling", since this will suppress the timer
softirq for arbitrary periods of time.

> + */
> +unsigned int __read_mostly vga_delay;

static.

> +integer_param("vga_delay", vga_delay);

Missing blank line.

>  /* VGA text-mode definitions. */
>  static unsigned int columns, lines;
>  #define ATTRIBUTE   7
> @@ -135,6 +141,9 @@ static void vga_text_puts(const char *s)
>                  ypos = lines - 1;
>                  memmove(video, video + 2 * columns, ypos * 2 * columns);
>                  memset(video + ypos * 2 * columns, 0, 2 * xpos);
> +                if (vga_delay)

I don't think a conditional is needed here.

Jan

> +                    mdelay(vga_delay);
> +
>              }
>              xpos = 0;
>          }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 07:15:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 07:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SExx3-0001OM-Uy; Tue, 03 Apr 2012 07:14:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SExx2-0001OG-FW
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 07:14:48 +0000
Received: from [85.158.138.51:9035] by server-11.bemta-3.messagelabs.com id
	9F/5B-12049-763AA7F4; Tue, 03 Apr 2012 07:14:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333437286!20494596!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24605 invoked from network); 3 Apr 2012 07:14:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 07:14:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 08:16:32 +0100
Message-Id: <4F7ABF83020000780007C3B0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 08:14:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
	<f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
In-Reply-To: <f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] xen/vga: Add 'vga_delay' parameter
 to delay screen output by X miliseconds per line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.04.12 at 22:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1333398408 14400
> # Node ID f1da2ce71ed41d1b74ebe6916ff7710d6579438e
> # Parent  1088c8557a46ab28e509bb9482e2a73a21590df8
> xen/vga: Add 'vga_delay' parameter to delay screen output by X miliseconds 
> per line.
> 
> This is useful if you find yourself on machine that has no serial console,
> nor any PCI, PCIe to put in a serial card. Nothing really fancy except it 
> allows
> to capture the screenshot of the screen using a camera.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r 1088c8557a46 -r f1da2ce71ed4 xen/drivers/video/vga.c
> --- a/xen/drivers/video/vga.c	Fri Mar 30 21:05:54 2012 +0100
> +++ b/xen/drivers/video/vga.c	Mon Apr 02 16:26:48 2012 -0400
> @@ -10,7 +10,7 @@
>  #include <xen/mm.h>
>  #include <xen/vga.h>
>  #include <asm/io.h>
> -
> +#include <xen/delay.h>
>  /* Filled in by arch boot code. */
>  struct xen_vga_console_info vga_console_info;
>  
> @@ -49,6 +49,12 @@ void (*vga_puts)(const char *) = vga_noo
>  static char __initdata opt_vga[30] = "";
>  string_param("vga", opt_vga);
>  
> +/*
> + * 'vga_delay=miliseconds' which defines to delay to print a line
> + * to the screen. 2 is a a good value to get a good screen output.

Maybe add something like "If you need to use this, do so with care
as it might screw up time handling", since this will suppress the timer
softirq for arbitrary periods of time.

> + */
> +unsigned int __read_mostly vga_delay;

static.

> +integer_param("vga_delay", vga_delay);

Missing blank line.

>  /* VGA text-mode definitions. */
>  static unsigned int columns, lines;
>  #define ATTRIBUTE   7
> @@ -135,6 +141,9 @@ static void vga_text_puts(const char *s)
>                  ypos = lines - 1;
>                  memmove(video, video + 2 * columns, ypos * 2 * columns);
>                  memset(video + ypos * 2 * columns, 0, 2 * xpos);
> +                if (vga_delay)

I don't think a conditional is needed here.

Jan

> +                    mdelay(vga_delay);
> +
>              }
>              xpos = 0;
>          }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 07:17:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 07:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SExzC-0001Uv-L9; Tue, 03 Apr 2012 07:17:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SExzB-0001Up-E5
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 07:17:01 +0000
Received: from [85.158.138.51:59281] by server-10.bemta-3.messagelabs.com id
	FB/D3-15637-CE3AA7F4; Tue, 03 Apr 2012 07:17:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333437419!20474804!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30651 invoked from network); 3 Apr 2012 07:16:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 07:16:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 08:18:45 +0100
Message-Id: <4F7AC009020000780007C3B3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 08:16:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
	<caefa03c38366c3e70d9.1333398446@phenom.dumpdata.com>
In-Reply-To: <caefa03c38366c3e70d9.1333398446@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: simon.graham@virtualcomputer.com, xen-devel <xen-devel@lists.xen.org>,
	Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/pat: After suspend re-write PAT
 if BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.04.12 at 22:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Simon Graham <simon.graham@virtualcomputer.com>
> # Date 1333398413 14400
> # Node ID caefa03c38366c3e70d937bc95740c5d33c0892a
> # Parent  f1da2ce71ed41d1b74ebe6916ff7710d6579438e
> xen/pat: After suspend re-write PAT if BIOS changed it.
> 
> Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
> would reset the PAT MSR causing rather weird issues - where
> the pages would (say they would be set to WC) would end up with the
> wrong type (as they would use the BIOS PAT instead of the one set by
> the hypervisor). And in some cases the PAT was stuck and needed
> a couple of WRMSRL to actually take.

But you still fail to explain why the existing PAT resume handling is
insufficient, and without understanding that we shouldn't be applying
a patch like this.

Jan

> Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r f1da2ce71ed4 -r caefa03c3836 xen/arch/x86/acpi/power.c
> --- a/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:48 2012 -0400
> +++ b/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:53 2012 -0400
> @@ -41,8 +41,27 @@ static DEFINE_SPINLOCK(pm_lock);
>  
>  struct acpi_sleep_info acpi_sinfo;
>  
> +static void pat_resume(void);
>  void do_suspend_lowlevel(void);
>  
> +static void
> +pat_resume()
> +{
> +    u64 pat;
> +    if (!cpu_has_pat)
> +        return;
> +
> +    rdmsrl(MSR_IA32_CR_PAT, pat);
> +    if (pat != host_pat) {
> +	printk(KERN_INFO PREFIX "Found PAT MSR: 0x%"PRIx64"\n", pat);
> +	printk(KERN_INFO PREFIX "reseting to 0x%"PRIx64"\n", host_pat);
> +	wrmsrl(MSR_IA32_CR_PAT, host_pat);
> +	rdmsrl(MSR_IA32_CR_PAT, pat);
> +	if (pat != host_pat)
> +	    printk(KERN_WARNING PREFIX "PAT MSR stuck on: 0x%"PRIx64"\n", pat);
> +    }
> +}
> +
>  static int device_power_down(void)
>  {
>      console_suspend();
> @@ -194,6 +213,7 @@ static int enter_state(u32 state)
>      if ( cpu_has_efer )
>          write_efer(read_efer());
>  
> +    pat_resume();
>      device_power_up();
>  
>      mcheck_init(&boot_cpu_data, 0);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 07:17:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 07:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SExzC-0001Uv-L9; Tue, 03 Apr 2012 07:17:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SExzB-0001Up-E5
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 07:17:01 +0000
Received: from [85.158.138.51:59281] by server-10.bemta-3.messagelabs.com id
	FB/D3-15637-CE3AA7F4; Tue, 03 Apr 2012 07:17:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333437419!20474804!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30651 invoked from network); 3 Apr 2012 07:16:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 07:16:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 08:18:45 +0100
Message-Id: <4F7AC009020000780007C3B3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 08:16:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
	<caefa03c38366c3e70d9.1333398446@phenom.dumpdata.com>
In-Reply-To: <caefa03c38366c3e70d9.1333398446@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: simon.graham@virtualcomputer.com, xen-devel <xen-devel@lists.xen.org>,
	Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/pat: After suspend re-write PAT
 if BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.04.12 at 22:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Simon Graham <simon.graham@virtualcomputer.com>
> # Date 1333398413 14400
> # Node ID caefa03c38366c3e70d937bc95740c5d33c0892a
> # Parent  f1da2ce71ed41d1b74ebe6916ff7710d6579438e
> xen/pat: After suspend re-write PAT if BIOS changed it.
> 
> Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
> would reset the PAT MSR causing rather weird issues - where
> the pages would (say they would be set to WC) would end up with the
> wrong type (as they would use the BIOS PAT instead of the one set by
> the hypervisor). And in some cases the PAT was stuck and needed
> a couple of WRMSRL to actually take.

But you still fail to explain why the existing PAT resume handling is
insufficient, and without understanding that we shouldn't be applying
a patch like this.

Jan

> Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r f1da2ce71ed4 -r caefa03c3836 xen/arch/x86/acpi/power.c
> --- a/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:48 2012 -0400
> +++ b/xen/arch/x86/acpi/power.c	Mon Apr 02 16:26:53 2012 -0400
> @@ -41,8 +41,27 @@ static DEFINE_SPINLOCK(pm_lock);
>  
>  struct acpi_sleep_info acpi_sinfo;
>  
> +static void pat_resume(void);
>  void do_suspend_lowlevel(void);
>  
> +static void
> +pat_resume()
> +{
> +    u64 pat;
> +    if (!cpu_has_pat)
> +        return;
> +
> +    rdmsrl(MSR_IA32_CR_PAT, pat);
> +    if (pat != host_pat) {
> +	printk(KERN_INFO PREFIX "Found PAT MSR: 0x%"PRIx64"\n", pat);
> +	printk(KERN_INFO PREFIX "reseting to 0x%"PRIx64"\n", host_pat);
> +	wrmsrl(MSR_IA32_CR_PAT, host_pat);
> +	rdmsrl(MSR_IA32_CR_PAT, pat);
> +	if (pat != host_pat)
> +	    printk(KERN_WARNING PREFIX "PAT MSR stuck on: 0x%"PRIx64"\n", pat);
> +    }
> +}
> +
>  static int device_power_down(void)
>  {
>      console_suspend();
> @@ -194,6 +213,7 @@ static int enter_state(u32 state)
>      if ( cpu_has_efer )
>          write_efer(read_efer());
>  
> +    pat_resume();
>      device_power_up();
>  
>      mcheck_init(&boot_cpu_data, 0);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:08:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEyme-0002aM-Qh; Tue, 03 Apr 2012 08:08:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEymd-0002aH-Sv
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:08:07 +0000
Received: from [85.158.143.35:29102] by server-1.bemta-4.messagelabs.com id
	B1/FD-20925-7EFAA7F4; Tue, 03 Apr 2012 08:08:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333440474!16891531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19942 invoked from network); 3 Apr 2012 08:07:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11737456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 08:07:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:07:54 +0100
Message-ID: <1333440471.25602.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 3 Apr 2012 09:07:51 +0100
In-Reply-To: <f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
	<f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] xen/vga: Add 'vga_delay' parameter
 to delay screen output by X miliseconds per line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 21:27 +0100, Konrad Rzeszutek Wilk wrote:
> @@ -49,6 +49,12 @@ void (*vga_puts)(const char *) = vga_noo
>  static char __initdata opt_vga[30] = "";
>  string_param("vga", opt_vga);
>  
> +/*
> + * 'vga_delay=miliseconds' which defines to delay to print a line
> + * to the screen. 2 is a a good value to get a good screen output.
> + */
> +unsigned int __read_mostly vga_delay;
> +integer_param("vga_delay", vga_delay);

Please patch docs/misc/xen-command-line.markdown too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:08:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEyme-0002aM-Qh; Tue, 03 Apr 2012 08:08:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEymd-0002aH-Sv
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:08:07 +0000
Received: from [85.158.143.35:29102] by server-1.bemta-4.messagelabs.com id
	B1/FD-20925-7EFAA7F4; Tue, 03 Apr 2012 08:08:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333440474!16891531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19942 invoked from network); 3 Apr 2012 08:07:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11737456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 08:07:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:07:54 +0100
Message-ID: <1333440471.25602.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 3 Apr 2012 09:07:51 +0100
In-Reply-To: <f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
References: <patchbomb.1333398444@phenom.dumpdata.com>
	<f1da2ce71ed41d1b74eb.1333398445@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] xen/vga: Add 'vga_delay' parameter
 to delay screen output by X miliseconds per line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 21:27 +0100, Konrad Rzeszutek Wilk wrote:
> @@ -49,6 +49,12 @@ void (*vga_puts)(const char *) = vga_noo
>  static char __initdata opt_vga[30] = "";
>  string_param("vga", opt_vga);
>  
> +/*
> + * 'vga_delay=miliseconds' which defines to delay to print a line
> + * to the screen. 2 is a a good value to get a good screen output.
> + */
> +unsigned int __read_mostly vga_delay;
> +integer_param("vga_delay", vga_delay);

Please patch docs/misc/xen-command-line.markdown too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:19:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEywb-0002kj-Tp; Tue, 03 Apr 2012 08:18:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEywa-0002ka-GA
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 08:18:25 +0000
Received: from [85.158.138.51:57603] by server-11.bemta-3.messagelabs.com id
	51/68-12049-F42BA7F4; Tue, 03 Apr 2012 08:18:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333441099!20523447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4607 invoked from network); 3 Apr 2012 08:18:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 08:18:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 09:18:18 +0100
Message-Id: <4F7ACE69020000780007C3E0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 09:18:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,<xen-devel@lists.xen.org>
References: <4F79DEEB020000780007C0F3@nat28.tlf.novell.com>
	<CB9F855E.2FDCE%keir.xen@gmail.com>
In-Reply-To: <CB9F855E.2FDCE%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB6988E59.3__="
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, Ian.Campbell@citrix.com,
	xen-ia64-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB6988E59.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 02.04.12 at 17:33, Keir Fraser <keir.xen@gmail.com> wrote:
> On 02/04/2012 16:16, "Jan Beulich" <JBeulich@suse.com> wrote:
>> now that we apparently having reached consensus here, are you
>> going to purge the ia64 bits from the tree, or do you want me to?
>=20
> Please go ahead.

This is the patch I'm intending to commit (omitting all the ia64 files
that are going to be removed).

It retains IA64-specific bits in code imported from elsewhere (e.g.
ACPI, EFI) as well as in the public headers.

It also doesn't touch the tools, mini-os, and unmodified_drivers
sub-trees.

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,14 +138,6 @@ M:	Tim Deegan <tim@xen.org>
 S:	Supported
 F:	tools/debugger/kdd/
=20
-IA64 ARCHITECTURE
-M:	KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
-S:	Supported
-L:	xen-ia64-devel@lists.xensource.com=20
-F:	xen/arch/ia64/*
-F:	xen/include/asm-ia64/*
-F:	tools/libxc/ia64/*
-
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 M:	Joseph Cihula <joseph.cihula@intel.com>
 M:	Gang Wei <gang.wei@intel.com>
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -58,7 +58,6 @@ subdir-$(CONFIG_COMPAT) +=3D compat
=20
 subdir-$(x86_32) +=3D hvm
 subdir-$(x86_64) +=3D hvm
-subdir-$(ia64) +=3D hvm
=20
 subdir-y +=3D libelf
 subdir-$(HAS_DEVICE_TREE) +=3D libfdt
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1514,9 +1514,7 @@ gnttab_transfer(
             goto copyback;
         }
=20
-#ifndef __ia64__ /* IA64 implicitly replaces the old page in steal_page().=
 */
         guest_physmap_remove_page(d, gop.mfn, mfn, 0);
-#endif
         flush_tlb_mask(d->domain_dirty_cpumask);
=20
         /* Find the target domain. */
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -721,11 +721,7 @@ static void crash_save_vmcoreinfo(void)
     VMCOREINFO_STRUCT_SIZE(domain);
=20
     VMCOREINFO_OFFSET(page_info, count_info);
-#ifdef __ia64__
-    VMCOREINFO_OFFSET_SUB(page_info, u.inuse, _domain);
-#else
     VMCOREINFO_OFFSET_SUB(page_info, v.inuse, _domain);
-#endif
     VMCOREINFO_OFFSET(domain, domain_id);
     VMCOREINFO_OFFSET(domain, next_in_list);
=20
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,9 +23,7 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifndef __ia64__
 #include <asm/p2m.h>
-#endif
 #include <xen/numa.h>
 #include <public/memory.h>
 #include <xsm/xsm.h>
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1141,7 +1141,7 @@ void __init scrub_heap_pages(void)
  * XEN-HEAP SUB-ALLOCATOR
  */
=20
-#if !defined(__x86_64__) && !defined(__ia64__)
+#if !defined(__x86_64__)
=20
 void init_xenheap_pages(paddr_t ps, paddr_t pe)
 {
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -88,7 +88,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
=20
-#if defined(__ia64__) || defined (CONFIG_ARM)
+#if defined(CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long =
*pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -442,16 +442,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
             goto out;
         }
=20
-#ifdef CONFIG_IA64
-        /* for IA64, currently it only supports FFH */
-        if (dom0_px_info->control_register.space_id !=3D
-            ACPI_ADR_SPACE_FIXED_HARDWARE)
-        {
-            ret =3D -EINVAL;
-            goto out;
-        }
-#endif
-
         memcpy ((void *)&pxpt->control_register,
                 (void *)&dom0_px_info->control_register,
                 sizeof(struct xen_pct_register));
@@ -493,7 +483,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
     {
 #ifdef CONFIG_X86
         /* for X86, check domain coordination */
-        /* for IA64, _PSD is optional for current IA64 cpufreq algorithm =
*/
         if (dom0_px_info->shared_type !=3D CPUFREQ_SHARED_TYPE_ALL &&
             dom0_px_info->shared_type !=3D CPUFREQ_SHARED_TYPE_ANY &&
             dom0_px_info->shared_type !=3D CPUFREQ_SHARED_TYPE_HW)
--- a/xen/drivers/passthrough/Makefile
+++ b/xen/drivers/passthrough/Makefile
@@ -1,5 +1,4 @@
 subdir-$(x86) +=3D vtd
-subdir-$(ia64) +=3D vtd
 subdir-$(x86) +=3D amd
 subdir-$(x86_64) +=3D x86
=20
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -419,7 +419,6 @@ int hvm_do_IRQ_dpci(struct domain *d, st
     return 1;
 }
=20
-#ifdef SUPPORT_MSI_REMAPPING
 /* called with d->event_lock held */
 static void __msi_pirq_eoi(struct hvm_pirq_dpci *pirq_dpci)
 {
@@ -479,7 +478,6 @@ static int hvm_pci_msi_assert(struct dom
             ? send_guest_pirq(d, pirq)
             : vmsi_deliver_pirq(d, pirq_dpci));
 }
-#endif
=20
 static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci =
*pirq_dpci,
                             void *arg)
@@ -489,13 +487,12 @@ static int _hvm_dirq_assist(struct domai
=20
     if ( test_and_clear_bool(pirq_dpci->masked) )
     {
-#ifdef SUPPORT_MSI_REMAPPING
         if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
         {
             hvm_pci_msi_assert(d, pirq_dpci);
             return 0;
         }
-#endif
+
         list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
         {
             struct pirq *info =3D dpci_pirq(pirq_dpci);
@@ -508,13 +505,11 @@ static int _hvm_dirq_assist(struct domai
                 hvm_pci_intx_assert(d, device, intx);
             pirq_dpci->pending++;
=20
-#ifdef SUPPORT_MSI_REMAPPING
             if ( pirq_dpci->flags & HVM_IRQ_DPCI_TRANSLATE )
             {
                 /* for translated MSI to INTx interrupt, eoi as early as =
possible */
                 __msi_pirq_eoi(pirq_dpci);
             }
-#endif
         }
=20
         /*
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -593,17 +593,6 @@ int iommu_do_domctl(
         bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
         devfn =3D domctl->u.assign_device.machine_sbdf & 0xff;
=20
-#ifdef __ia64__ /* XXX Is this really needed? */
-        if ( device_assigned(seg, bus, devfn) )
-        {
-            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
-                   "%04x:%02x:%02x.%u already assigned, or non-existent\n"=
,
-                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
-            ret =3D -EINVAL;
-            goto assign_device_out;
-        }
-#endif
-
         ret =3D assign_device(d, seg, bus, devfn);
         if ( ret )
             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
@@ -632,14 +621,6 @@ int iommu_do_domctl(
         bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
         devfn =3D domctl->u.assign_device.machine_sbdf & 0xff;
=20
-#ifdef __ia64__ /* XXX Is this really needed? */
-        if ( !device_assigned(seg, bus, devfn) )
-        {
-            ret =3D -EINVAL;
-            goto deassign_device_out;
-        }
-#endif
-
         spin_lock(&pcidevs_lock);
         ret =3D deassign_device(d, seg, bus, devfn);
         spin_unlock(&pcidevs_lock);
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -696,7 +696,6 @@ void __init setup_dom0_pci_devices(
     spin_unlock(&pcidevs_lock);
 }
=20
-#ifdef SUPPORT_MSI_REMAPPING
 static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
 {
     struct pci_dev *pdev;
@@ -738,8 +737,6 @@ static int __init setup_dump_pcidevs(voi
     return 0;
 }
 __initcall(setup_dump_pcidevs);
-#endif
-
=20
 /*
  * Local variables:
--- a/xen/drivers/passthrough/vtd/Makefile
+++ b/xen/drivers/passthrough/vtd/Makefile
@@ -1,5 +1,4 @@
 subdir-$(x86) +=3D x86
-subdir-$(ia64) +=3D ia64
=20
 obj-y +=3D iommu.o
 obj-y +=3D dmar.o
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -31,26 +31,7 @@
 #include "vtd.h"
 #include "extern.h"
=20
-#ifdef __ia64__
-#define nr_ioapics              iosapic_get_nr_iosapics()
-#define nr_ioapic_entries(i)  iosapic_get_nr_pins(i)
-#define __io_apic_read(apic, reg) \
-    (*IO_APIC_BASE(apic) =3D reg, *(IO_APIC_BASE(apic)+4))
-#define __io_apic_write(apic, reg, val) \
-    (*IO_APIC_BASE(apic) =3D reg, *(IO_APIC_BASE(apic)+4) =3D (val))
-#define __ioapic_read_entry(apic, pin, raw) ({ \
-    struct IO_xAPIC_route_entry _e_; \
-    ASSERT(raw); \
-    ((u32 *)&_e_)[0] =3D __io_apic_read(apic, 0x10 + 2 * (pin)); \
-    ((u32 *)&_e_)[1] =3D __io_apic_read(apic, 0x11 + 2 * (pin)); \
-    _e_; \
-})
-#define __ioapic_write_entry(apic, pin, raw, ent) ({ \
-    ASSERT(raw); \
-    __io_apic_write(apic, 0x10 + 2 * (pin), ((u32 *)&(ent))[0]); \
-    __io_apic_write(apic, 0x11 + 2 * (pin), ((u32 *)&(ent))[1]); \
-})
-#else
+#if defined(__i386__) || defined(__x86_64__)
 #include <asm/apic.h>
 #include <asm/io_apic.h>
 #define nr_ioapic_entries(i)  nr_ioapic_entries[i]
@@ -326,8 +307,6 @@ static int ioapic_rte_to_remap_entry(str
             new_ire.lo.dst =3D value;
         else
             new_ire.lo.dst =3D (value >> 24) << 8;
-#else /* __ia64__ */
-        new_ire.lo.dst =3D value >> 16;
 #endif
     }
     else
@@ -625,12 +604,8 @@ static int msi_msg_to_remap_entry(
     new_ire.lo.dm =3D (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
     new_ire.lo.tm =3D (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
     new_ire.lo.dlm =3D (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x1;
-#ifdef CONFIG_X86
     /* Hardware require RH =3D 1 for LPR delivery mode */
     new_ire.lo.rh =3D (new_ire.lo.dlm =3D=3D dest_LowestPrio);
-#else
-    new_ire.lo.rh =3D 0;
-#endif
     new_ire.lo.avail =3D 0;
     new_ire.lo.res_1 =3D 0;
     new_ire.lo.vector =3D (msg->data >> MSI_DATA_VECTOR_SHIFT) &
@@ -703,18 +678,6 @@ void msi_msg_write_remap_rte(
=20
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
 }
-#elif defined(__ia64__)
-void msi_msg_read_remap_rte(
-    struct msi_desc *msi_desc, struct msi_msg *msg)
-{
-    /* TODO. */
-}
-
-void msi_msg_write_remap_rte(
-    struct msi_desc *msi_desc, struct msi_msg *msg)
-{
-    /* TODO. */
-}
 #endif
=20
 int enable_intremap(struct iommu *iommu, int eim)
@@ -838,8 +801,6 @@ out:
     spin_unlock_irqrestore(&iommu->register_lock, flags);
 }
=20
-#ifndef __ia64__
-
 /*
  * This function is used to enable Interrupt remapping when
  * enable x2apic
@@ -914,5 +875,3 @@ void iommu_disable_x2apic_IR(void)
     for_each_drhd_unit ( drhd )
         disable_qinval(drhd->iommu);
 }
-
-#endif /* !__ia64__ */
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -33,7 +33,7 @@
 #include <xen/keyhandler.h>
 #include <asm/msi.h>
 #include <asm/irq.h>
-#ifndef __ia64__
+#if defined(__i386__) || defined(__x86_64__)
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/p2m.h>
 #include <mach_apic.h>
@@ -44,10 +44,6 @@
 #include "vtd.h"
 #include "../ats.h"
=20
-#ifdef __ia64__
-#define nr_ioapics              iosapic_get_nr_iosapics()
-#endif
-
 /* Possible unfiltered LAPIC/MSI messages from untrusted sources? */
 bool_t __read_mostly untrusted_msi;
=20
@@ -1057,11 +1053,7 @@ static unsigned int dma_msi_startup(stru
     return 0;
 }
=20
-#ifndef __ia64__
 static void dma_msi_end(struct irq_desc *desc, u8 vector)
-#else
-static void dma_msi_end(struct irq_desc *desc)
-#endif
 {
     dma_msi_unmask(desc);
     ack_APIC_irq();
@@ -1841,7 +1833,6 @@ void iommu_pte_flush(struct domain *d, u
=20
 static int vtd_ept_page_compatible(struct iommu *iommu)
 {
-#ifndef __ia64__
     u64 ept_cap, vtd_cap =3D iommu->cap;
=20
     /* EPT is not initialised yet, so we must check the capability in
@@ -1851,9 +1842,6 @@ static int vtd_ept_page_compatible(struc
=20
     return ( ept_has_2mb(ept_cap) =3D=3D cap_sps_2mb(vtd_cap)=20
              && ept_has_1gb(ept_cap) =3D=3D cap_sps_1gb(vtd_cap) );
-#else
-    return 0;
-#endif
 }
=20
 /*
@@ -1861,7 +1849,6 @@ static int vtd_ept_page_compatible(struc
  */
 void iommu_set_pgd(struct domain *d)
 {
-#ifndef __ia64__
     struct hvm_iommu *hd  =3D domain_hvm_iommu(d);
     mfn_t pgd_mfn;
=20
@@ -1872,7 +1859,6 @@ void iommu_set_pgd(struct domain *d)
=20
     pgd_mfn =3D pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
     hd->pgd_maddr =3D pagetable_get_paddr(pagetable_from_mfn(pgd_mfn));
-#endif
 }
=20
 static int rmrr_identity_mapping(struct domain *d,
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -301,8 +301,7 @@ static void dump_iommu_info(unsigned cha
         }
     }
 #else
-    printk("%s: not implemnted on IA64 for now.\n", __func__);
-    /* ia64: TODO */
+    printk("%s: not implemented for now\n", __func__);
 #endif
 }
=20
--- a/xen/drivers/passthrough/vtd/vtd.h
+++ b/xen/drivers/passthrough/vtd/vtd.h
@@ -26,44 +26,8 @@
 #define MAP_ME_PHANTOM_FUNC      1
 #define UNMAP_ME_PHANTOM_FUNC    0
=20
-/* Accomodate both IOAPIC and IOSAPIC. */
-#ifndef __ia64__
+/* Allow for both IOAPIC and IOSAPIC. */
 #define IO_xAPIC_route_entry IO_APIC_route_entry
-#else
-struct IO_xAPIC_route_entry {
-    __u32   vector      :  8,
-        delivery_mode   :  3,   /* 000: FIXED
-                                 * 001: lowest prio
-                                 * 111: ExtINT
-                                 */
-        dest_mode       :  1,   /* 0: physical, 1: logical */
-        delivery_status :  1,
-        polarity        :  1,
-        irr             :  1,
-        trigger         :  1,   /* 0: edge, 1: level */
-        mask            :  1,   /* 0: enabled, 1: disabled */
-        __reserved_2    : 15;
-
-    union {
-        struct { __u32
-            __reserved_1    : 24,
-            physical_dest   :  4,
-            __reserved_2    :  4;
-        } physical;
-
-        struct { __u32
-            __reserved_1    : 24,
-            logical_dest    :  8;
-        } logical;
-
-        struct { __u32
-            __reserved_1    : 16,
-            dest_id         : 16;
-        };
-    } dest;
-
-} __attribute__ ((packed));
-#endif
=20
 struct IO_APIC_route_remap_entry {
     union {
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -38,7 +38,7 @@ suffix-$(CONFIG_X86)      :=3D \#pragma pa
 endif
=20
 public-$(CONFIG_X86) :=3D $(wildcard public/arch-x86/*.h public/arch-x86/*=
/*.h)
-public-$(CONFIG_IA64) :=3D $(wildcard public/arch-ia64/*.h public/arch-ia6=
4/*/*.h)
+public-$(CONFIG_ARM) :=3D $(wildcard public/arch-arm/*.h public/arch-arm/*=
/*.h)
=20
 .PHONY: all
 all: $(headers-y)
@@ -74,8 +74,6 @@ compat/xlat.h: xlat.lst $(filter-out com
 	mv -f $@.new $@
=20
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
-# public/arch-ia64.h explicitly bails on __STRICT_ANSI__
-ifeq ($(CONFIG_IA64),)
=20
 all: headers.chk
=20
@@ -84,7 +82,6 @@ headers.chk: $(filter-out public/arch-%=20
 	mv $@.new $@
=20
 endif
-endif
=20
 clean::
 	rm -rf compat headers.chk
--- a/xen/include/asm-x86/hvm/irq.h
+++ b/xen/include/asm-x86/hvm/irq.h
@@ -104,11 +104,4 @@ struct hvm_intack hvm_vcpu_has_pending_i
 struct hvm_intack hvm_vcpu_ack_pending_irq(struct vcpu *v,
                                            struct hvm_intack intack);
=20
-/*
- * Currently IA64 Xen doesn't support MSI. So for x86, we define this =
macro
- * to control the conditional compilation of some MSI-related functions.
- * This macro will be removed once IA64 has MSI support.
- */
-#define SUPPORT_MSI_REMAPPING 1
-
 #endif /* __ASM_X86_HVM_IRQ_H__ */
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -41,7 +41,7 @@
 /* Direct registers. */
 #define VIOAPIC_REG_SELECT  0x00
 #define VIOAPIC_REG_WINDOW  0x10
-#define VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */
+#define VIOAPIC_REG_EOI     0x40
=20
 /* Indirect registers. */
 #define VIOAPIC_REG_APIC_ID 0x00 /* x86 IOAPIC only */
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -82,7 +82,7 @@ typedef struct cpumask{ DECLARE_BITMAP(b
=20
 extern unsigned int nr_cpu_ids;
=20
-#if NR_CPUS > 4 * BITS_PER_LONG && !defined(__ia64__)
+#if NR_CPUS > 4 * BITS_PER_LONG
 /* Assuming NR_CPUS is huge, a runtime limit is more efficient.  Also,
  * not all bits may be allocated. */
 extern unsigned int nr_cpumask_bits;
@@ -263,37 +263,6 @@ static inline const cpumask_t *cpumask_o
 	return (const cpumask_t *)(p - cpu / BITS_PER_LONG);
 }
=20
-#if defined(__ia64__) /* XXX needs cleanup */
-#define CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)
-
-#if NR_CPUS <=3D BITS_PER_LONG
-
-#define CPU_MASK_ALL							\
-/*(cpumask_t)*/ { {							\
-	[BITS_TO_LONGS(NR_CPUS)-1] =3D CPU_MASK_LAST_WORD			=
\
-} }
-
-#else
-
-#define CPU_MASK_ALL							\
-/*(cpumask_t)*/ { {							\
-	[0 ... BITS_TO_LONGS(NR_CPUS)-2] =3D ~0UL,			\
-	[BITS_TO_LONGS(NR_CPUS)-1] =3D CPU_MASK_LAST_WORD			=
\
-} }
-
-#endif
-
-#define CPU_MASK_NONE							\
-/*(cpumask_t)*/ { {							\
-	0UL								\
-} }
-
-#define CPU_MASK_CPU0							\
-/*(cpumask_t)*/ { {							\
-	[0] =3D  1UL							\
-} }
-#endif /* __ia64__ */
-
 #define cpumask_bits(maskp) ((maskp)->bits)
=20
 static inline int cpumask_scnprintf(char *buf, int len,
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -5,15 +5,11 @@
 #include <xen/types.h>
 #endif
=20
-#if defined(__ia64__)
-# include_next <linux/efi.h>
+#if defined(__i386__)
+# define efi_enabled 0
 #else
-
-# if defined(__i386__)
-#  define efi_enabled 0
-# else
 extern const bool_t efi_enabled;
-# endif
+#endif
=20
 #define EFI_INVALID_TABLE_ADDR (~0UL)
=20
@@ -27,8 +23,6 @@ struct efi {
=20
 extern struct efi efi;
=20
-#endif
-
 #ifndef __ASSEMBLY__
=20
 union xenpf_efi_info;
--- a/xen/include/xen/elfcore.h
+++ b/xen/include/xen/elfcore.h
@@ -69,9 +69,6 @@ typedef struct {
     unsigned long xen_phys_start;
     unsigned long dom0_pfn_to_mfn_frame_list_list;
 #endif
-#if defined(__ia64__)
-    unsigned long dom0_mm_pgd_mfn;
-#endif
 } crash_xen_info_t;
=20
 #endif /* __ELFCOREC_H__ */
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -78,8 +78,6 @@ struct hvm_girq_dpci_mapping {
 #define NR_LINK     4
 #if defined(__i386__) || defined(__x86_64__)
 # define NR_HVM_IRQS VIOAPIC_NUM_PINS
-#elif defined(__ia64__)
-# define NR_HVM_IRQS VIOSAPIC_NUM_PINS
 #endif
=20
 /* Protected by domain's event_lock */
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -35,11 +35,7 @@ extern bool_t iommu_debug;
 extern bool_t amd_iommu_perdev_intremap;
=20
 /* Does this domain have a P2M table we can use as its IOMMU pagetable? =
*/
-#ifndef __ia64__
 #define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
-#else
-#define iommu_use_hap_pt(d) 0
-#endif
=20
 extern struct rangeset *mmio_ro_ranges;
=20
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -95,37 +95,19 @@ int arch_init_one_irq_desc(struct irq_de
=20
 #define irq_desc_initialized(desc) ((desc)->handler !=3D NULL)
=20
-#if defined(__ia64__)
-extern irq_desc_t irq_desc[NR_VECTORS];
-
-#define setup_irq(irq, action) \
-    setup_irq_vector(irq_to_vector(irq), action)
-
-#define release_irq(irq) \
-    release_irq_vector(irq_to_vector(irq))
-
-#define request_irq(irq, handler, irqflags, devname, devid) \
-    request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, =
devid)
-
-#elif defined(__arm__)
+#if defined(__arm__)
=20
 #define NR_IRQS		1024
 #define nr_irqs NR_IRQS
 extern irq_desc_t irq_desc[NR_IRQS];
=20
-extern int setup_irq(unsigned int irq, struct irqaction *);
-extern void release_irq(unsigned int irq);
-extern int request_irq(unsigned int irq,
-               void (*handler)(int, void *, struct cpu_user_regs *),
-               unsigned long irqflags, const char * devname, void =
*dev_id);
+#endif
=20
-#else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
 extern int request_irq(unsigned int irq,
                void (*handler)(int, void *, struct cpu_user_regs *),
                unsigned long irqflags, const char * devname, void =
*dev_id);
-#endif
=20
 extern hw_irq_controller no_irq_type;
 extern void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs);
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
=20
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || =
defined(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -21,13 +21,9 @@ static void __check_printsym_format(cons
 {
 }
=20
-/* ia64 and ppc64 use function descriptors, which contain the real =
address */
-#if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
-#define print_fn_descriptor_symbol(fmt, addr)		\
-do {						\
-	unsigned long *__faddr =3D (unsigned long*) addr;		\
-	print_symbol(fmt, __faddr[0]);		\
-} while (0)
+#if 0
+#define print_fn_descriptor_symbol(fmt, addr)	\
+	print_symbol(fmt, *(unsigned long *)addr)
 #else
 #define print_fn_descriptor_symbol(fmt, addr) print_symbol(fmt, addr)
 #endif



--=__PartB6988E59.3__=
Content-Type: text/plain; name="ia64-purge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-purge.patch"

It retains IA64-specific bits in code imported from elsewhere (e.g.=0AACPI,=
 EFI) as well as in the public headers.=0A=0AIt also doesn't touch the =
tools, mini-os, and unmodified_drivers=0Asub-trees.=0A=0A--- a/MAINTAINERS=
=0A+++ b/MAINTAINERS=0A@@ -138,14 +138,6 @@ M:	Tim Deegan <tim@xen.org>=0A=
 S:	Supported=0A F:	tools/debugger/kdd/=0A =0A-IA64 ARCHITECTURE=0A-M:	=
KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>=0A-S:	Supported=0A-L:	xen-ia64-de=
vel@lists.xensource.com=0A-F:	xen/arch/ia64/*=0A-F:	xen/include/asm-ia6=
4/*=0A-F:	tools/libxc/ia64/*=0A-=0A INTEL(R) TRUSTED EXECUTION =
TECHNOLOGY (TXT)=0A M:	Joseph Cihula <joseph.cihula@intel.com>=0A M:	=
Gang Wei <gang.wei@intel.com>=0A--- a/xen/common/Makefile=0A+++ b/xen/commo=
n/Makefile=0A@@ -58,7 +58,6 @@ subdir-$(CONFIG_COMPAT) +=3D compat=0A =0A =
subdir-$(x86_32) +=3D hvm=0A subdir-$(x86_64) +=3D hvm=0A-subdir-$(ia64) =
+=3D hvm=0A =0A subdir-y +=3D libelf=0A subdir-$(HAS_DEVICE_TREE) +=3D =
libfdt=0A--- a/xen/common/grant_table.c=0A+++ b/xen/common/grant_table.c=0A=
@@ -1514,9 +1514,7 @@ gnttab_transfer(=0A             goto copyback;=0A    =
     }=0A =0A-#ifndef __ia64__ /* IA64 implicitly replaces the old page in =
steal_page(). */=0A         guest_physmap_remove_page(d, gop.mfn, mfn, =
0);=0A-#endif=0A         flush_tlb_mask(d->domain_dirty_cpumask);=0A =0A   =
      /* Find the target domain. */=0A--- a/xen/common/kexec.c=0A+++ =
b/xen/common/kexec.c=0A@@ -721,11 +721,7 @@ static void crash_save_vmcorein=
fo(void)=0A     VMCOREINFO_STRUCT_SIZE(domain);=0A =0A     VMCOREINFO_OFFSE=
T(page_info, count_info);=0A-#ifdef __ia64__=0A-    VMCOREINFO_OFFSET_SUB(p=
age_info, u.inuse, _domain);=0A-#else=0A     VMCOREINFO_OFFSET_SUB(page_inf=
o, v.inuse, _domain);=0A-#endif=0A     VMCOREINFO_OFFSET(domain, domain_id)=
;=0A     VMCOREINFO_OFFSET(domain, next_in_list);=0A =0A--- a/xen/common/me=
mory.c=0A+++ b/xen/common/memory.c=0A@@ -23,9 +23,7 @@=0A #include =
<xen/tmem_xen.h>=0A #include <asm/current.h>=0A #include <asm/hardirq.h>=0A=
-#ifndef __ia64__=0A #include <asm/p2m.h>=0A-#endif=0A #include <xen/numa.h=
>=0A #include <public/memory.h>=0A #include <xsm/xsm.h>=0A--- a/xen/common/=
page_alloc.c=0A+++ b/xen/common/page_alloc.c=0A@@ -1141,7 +1141,7 @@ void =
__init scrub_heap_pages(void)=0A  * XEN-HEAP SUB-ALLOCATOR=0A  */=0A =
=0A-#if !defined(__x86_64__) && !defined(__ia64__)=0A+#if !defined(__x86_64=
__)=0A =0A void init_xenheap_pages(paddr_t ps, paddr_t pe)=0A {=0A--- =
a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ -88,7 +88,7 @@ =
void tmh_copy_page(char *to, char*from)=0A #endif=0A }=0A =0A-#if =
defined(__ia64__) || defined (CONFIG_ARM)=0A+#if defined(CONFIG_ARM)=0A =
static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long =
*pcli_mfn,=0A                                  pfp_t **pcli_pfp, bool_t =
cli_write)=0A {=0A--- a/xen/drivers/cpufreq/cpufreq.c=0A+++ b/xen/drivers/c=
pufreq/cpufreq.c=0A@@ -442,16 +442,6 @@ int set_px_pminfo(uint32_t =
acpi_id, stru=0A             goto out;=0A         }=0A =0A-#ifdef =
CONFIG_IA64=0A-        /* for IA64, currently it only supports FFH */=0A-  =
      if (dom0_px_info->control_register.space_id !=3D=0A-            =
ACPI_ADR_SPACE_FIXED_HARDWARE)=0A-        {=0A-            ret =3D =
-EINVAL;=0A-            goto out;=0A-        }=0A-#endif=0A-=0A         =
memcpy ((void *)&pxpt->control_register,=0A                 (void =
*)&dom0_px_info->control_register,=0A                 sizeof(struct =
xen_pct_register));=0A@@ -493,7 +483,6 @@ int set_px_pminfo(uint32_t =
acpi_id, stru=0A     {=0A #ifdef CONFIG_X86=0A         /* for X86, check =
domain coordination */=0A-        /* for IA64, _PSD is optional for =
current IA64 cpufreq algorithm */=0A         if (dom0_px_info->shared_type =
!=3D CPUFREQ_SHARED_TYPE_ALL &&=0A             dom0_px_info->shared_type =
!=3D CPUFREQ_SHARED_TYPE_ANY &&=0A             dom0_px_info->shared_type =
!=3D CPUFREQ_SHARED_TYPE_HW)=0A--- a/xen/drivers/passthrough/Makefile=0A+++=
 b/xen/drivers/passthrough/Makefile=0A@@ -1,5 +1,4 @@=0A subdir-$(x86) =
+=3D vtd=0A-subdir-$(ia64) +=3D vtd=0A subdir-$(x86) +=3D amd=0A subdir-$(x=
86_64) +=3D x86=0A =0A--- a/xen/drivers/passthrough/io.c=0A+++ b/xen/driver=
s/passthrough/io.c=0A@@ -419,7 +419,6 @@ int hvm_do_IRQ_dpci(struct domain =
*d, st=0A     return 1;=0A }=0A =0A-#ifdef SUPPORT_MSI_REMAPPING=0A /* =
called with d->event_lock held */=0A static void __msi_pirq_eoi(struct =
hvm_pirq_dpci *pirq_dpci)=0A {=0A@@ -479,7 +478,6 @@ static int hvm_pci_msi=
_assert(struct dom=0A             ? send_guest_pirq(d, pirq)=0A            =
 : vmsi_deliver_pirq(d, pirq_dpci));=0A }=0A-#endif=0A =0A static int =
_hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,=0A     =
                        void *arg)=0A@@ -489,13 +487,12 @@ static int =
_hvm_dirq_assist(struct domai=0A =0A     if ( test_and_clear_bool(pirq_dpci=
->masked) )=0A     {=0A-#ifdef SUPPORT_MSI_REMAPPING=0A         if ( =
pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )=0A         {=0A             =
hvm_pci_msi_assert(d, pirq_dpci);=0A             return 0;=0A         =
}=0A-#endif=0A+=0A         list_for_each_entry ( digl, &pirq_dpci->digl_lis=
t, list )=0A         {=0A             struct pirq *info =3D dpci_pirq(pirq_=
dpci);=0A@@ -508,13 +505,11 @@ static int _hvm_dirq_assist(struct domai=0A =
                hvm_pci_intx_assert(d, device, intx);=0A             =
pirq_dpci->pending++;=0A =0A-#ifdef SUPPORT_MSI_REMAPPING=0A             =
if ( pirq_dpci->flags & HVM_IRQ_DPCI_TRANSLATE )=0A             {=0A       =
          /* for translated MSI to INTx interrupt, eoi as early as =
possible */=0A                 __msi_pirq_eoi(pirq_dpci);=0A             =
}=0A-#endif=0A         }=0A =0A         /*=0A--- a/xen/drivers/passthrough/=
iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -593,17 +593,6 @@ int =
iommu_do_domctl(=0A         bus =3D (domctl->u.assign_device.machine_sbdf =
>> 8) & 0xff;=0A         devfn =3D domctl->u.assign_device.machine_sbdf & =
0xff;=0A =0A-#ifdef __ia64__ /* XXX Is this really needed? */=0A-        =
if ( device_assigned(seg, bus, devfn) )=0A-        {=0A-            =
printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "=0A-                   =
"%04x:%02x:%02x.%u already assigned, or non-existent\n",=0A-               =
    seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A-            ret =3D =
-EINVAL;=0A-            goto assign_device_out;=0A-        }=0A-#endif=0A-=
=0A         ret =3D assign_device(d, seg, bus, devfn);=0A         if ( ret =
)=0A             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "=0A@@ =
-632,14 +621,6 @@ int iommu_do_domctl(=0A         bus =3D (domctl->u.assign=
_device.machine_sbdf >> 8) & 0xff;=0A         devfn =3D domctl->u.assign_de=
vice.machine_sbdf & 0xff;=0A =0A-#ifdef __ia64__ /* XXX Is this really =
needed? */=0A-        if ( !device_assigned(seg, bus, devfn) )=0A-        =
{=0A-            ret =3D -EINVAL;=0A-            goto deassign_device_out;=
=0A-        }=0A-#endif=0A-=0A         spin_lock(&pcidevs_lock);=0A        =
 ret =3D deassign_device(d, seg, bus, devfn);=0A         spin_unlock(&pcide=
vs_lock);=0A--- a/xen/drivers/passthrough/pci.c=0A+++ b/xen/drivers/passthr=
ough/pci.c=0A@@ -696,7 +696,6 @@ void __init setup_dom0_pci_devices(=0A    =
 spin_unlock(&pcidevs_lock);=0A }=0A =0A-#ifdef SUPPORT_MSI_REMAPPING=0A =
static int _dump_pci_devices(struct pci_seg *pseg, void *arg)=0A {=0A     =
struct pci_dev *pdev;=0A@@ -738,8 +737,6 @@ static int __init setup_dump_pc=
idevs(voi=0A     return 0;=0A }=0A __initcall(setup_dump_pcidevs);=0A-#endi=
f=0A-=0A =0A /*=0A  * Local variables:=0A--- a/xen/drivers/passthrough/vtd/=
Makefile=0A+++ b/xen/drivers/passthrough/vtd/Makefile=0A@@ -1,5 +1,4 @@=0A =
subdir-$(x86) +=3D x86=0A-subdir-$(ia64) +=3D ia64=0A =0A obj-y +=3D =
iommu.o=0A obj-y +=3D dmar.o=0A--- a/xen/drivers/passthrough/vtd/intremap.c=
=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ -31,26 +31,7 @@=0A =
#include "vtd.h"=0A #include "extern.h"=0A =0A-#ifdef __ia64__=0A-#define =
nr_ioapics              iosapic_get_nr_iosapics()=0A-#define nr_ioapic_entr=
ies(i)  iosapic_get_nr_pins(i)=0A-#define __io_apic_read(apic, reg) \=0A-  =
  (*IO_APIC_BASE(apic) =3D reg, *(IO_APIC_BASE(apic)+4))=0A-#define =
__io_apic_write(apic, reg, val) \=0A-    (*IO_APIC_BASE(apic) =3D reg, =
*(IO_APIC_BASE(apic)+4) =3D (val))=0A-#define __ioapic_read_entry(apic, =
pin, raw) ({ \=0A-    struct IO_xAPIC_route_entry _e_; \=0A-    ASSERT(raw)=
; \=0A-    ((u32 *)&_e_)[0] =3D __io_apic_read(apic, 0x10 + 2 * (pin)); =
\=0A-    ((u32 *)&_e_)[1] =3D __io_apic_read(apic, 0x11 + 2 * (pin)); =
\=0A-    _e_; \=0A-})=0A-#define __ioapic_write_entry(apic, pin, raw, ent) =
({ \=0A-    ASSERT(raw); \=0A-    __io_apic_write(apic, 0x10 + 2 * (pin), =
((u32 *)&(ent))[0]); \=0A-    __io_apic_write(apic, 0x11 + 2 * (pin), =
((u32 *)&(ent))[1]); \=0A-})=0A-#else=0A+#if defined(__i386__) || =
defined(__x86_64__)=0A #include <asm/apic.h>=0A #include <asm/io_apic.h>=0A=
 #define nr_ioapic_entries(i)  nr_ioapic_entries[i]=0A@@ -326,8 +307,6 @@ =
static int ioapic_rte_to_remap_entry(str=0A             new_ire.lo.dst =3D =
value;=0A         else=0A             new_ire.lo.dst =3D (value >> 24) << =
8;=0A-#else /* __ia64__ */=0A-        new_ire.lo.dst =3D value >> 16;=0A =
#endif=0A     }=0A     else=0A@@ -625,12 +604,8 @@ static int msi_msg_to_re=
map_entry(=0A     new_ire.lo.dm =3D (msg->address_lo >> MSI_ADDR_DESTMODE_S=
HIFT) & 0x1;=0A     new_ire.lo.tm =3D (msg->data >> MSI_DATA_TRIGGER_SHIFT)=
 & 0x1;=0A     new_ire.lo.dlm =3D (msg->data >> MSI_DATA_DELIVERY_MODE_SHIF=
T) & 0x1;=0A-#ifdef CONFIG_X86=0A     /* Hardware require RH =3D 1 for LPR =
delivery mode */=0A     new_ire.lo.rh =3D (new_ire.lo.dlm =3D=3D dest_Lowes=
tPrio);=0A-#else=0A-    new_ire.lo.rh =3D 0;=0A-#endif=0A     new_ire.lo.av=
ail =3D 0;=0A     new_ire.lo.res_1 =3D 0;=0A     new_ire.lo.vector =3D =
(msg->data >> MSI_DATA_VECTOR_SHIFT) &=0A@@ -703,18 +678,6 @@ void =
msi_msg_write_remap_rte(=0A =0A     msi_msg_to_remap_entry(iommu, pdev, =
msi_desc, msg);=0A }=0A-#elif defined(__ia64__)=0A-void msi_msg_read_remap_=
rte(=0A-    struct msi_desc *msi_desc, struct msi_msg *msg)=0A-{=0A-    /* =
TODO. */=0A-}=0A-=0A-void msi_msg_write_remap_rte(=0A-    struct msi_desc =
*msi_desc, struct msi_msg *msg)=0A-{=0A-    /* TODO. */=0A-}=0A #endif=0A =
=0A int enable_intremap(struct iommu *iommu, int eim)=0A@@ -838,8 +801,6 =
@@ out:=0A     spin_unlock_irqrestore(&iommu->register_lock, flags);=0A =
}=0A =0A-#ifndef __ia64__=0A-=0A /*=0A  * This function is used to enable =
Interrupt remapping when=0A  * enable x2apic=0A@@ -914,5 +875,3 @@ void =
iommu_disable_x2apic_IR(void)=0A     for_each_drhd_unit ( drhd )=0A        =
 disable_qinval(drhd->iommu);=0A }=0A-=0A-#endif /* !__ia64__ */=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -33,7 +33,7 @@=0A #include <xen/keyhandler.h>=0A #include =
<asm/msi.h>=0A #include <asm/irq.h>=0A-#ifndef __ia64__=0A+#if defined(__i3=
86__) || defined(__x86_64__)=0A #include <asm/hvm/vmx/vmx.h>=0A #include =
<asm/p2m.h>=0A #include <mach_apic.h>=0A@@ -44,10 +44,6 @@=0A #include =
"vtd.h"=0A #include "../ats.h"=0A =0A-#ifdef __ia64__=0A-#define nr_ioapics=
              iosapic_get_nr_iosapics()=0A-#endif=0A-=0A /* Possible =
unfiltered LAPIC/MSI messages from untrusted sources? */=0A bool_t =
__read_mostly untrusted_msi;=0A =0A@@ -1057,11 +1053,7 @@ static unsigned =
int dma_msi_startup(stru=0A     return 0;=0A }=0A =0A-#ifndef __ia64__=0A =
static void dma_msi_end(struct irq_desc *desc, u8 vector)=0A-#else=0A-stati=
c void dma_msi_end(struct irq_desc *desc)=0A-#endif=0A {=0A     dma_msi_unm=
ask(desc);=0A     ack_APIC_irq();=0A@@ -1841,7 +1833,6 @@ void iommu_pte_fl=
ush(struct domain *d, u=0A =0A static int vtd_ept_page_compatible(struct =
iommu *iommu)=0A {=0A-#ifndef __ia64__=0A     u64 ept_cap, vtd_cap =3D =
iommu->cap;=0A =0A     /* EPT is not initialised yet, so we must check the =
capability in=0A@@ -1851,9 +1842,6 @@ static int vtd_ept_page_compatible(st=
ruc=0A =0A     return ( ept_has_2mb(ept_cap) =3D=3D cap_sps_2mb(vtd_cap) =
=0A              && ept_has_1gb(ept_cap) =3D=3D cap_sps_1gb(vtd_cap) =
);=0A-#else=0A-    return 0;=0A-#endif=0A }=0A =0A /*=0A@@ -1861,7 +1849,6 =
@@ static int vtd_ept_page_compatible(struc=0A  */=0A void iommu_set_pgd(st=
ruct domain *d)=0A {=0A-#ifndef __ia64__=0A     struct hvm_iommu *hd  =3D =
domain_hvm_iommu(d);=0A     mfn_t pgd_mfn;=0A =0A@@ -1872,7 +1859,6 @@ =
void iommu_set_pgd(struct domain *d)=0A =0A     pgd_mfn =3D pagetable_get_m=
fn(p2m_get_pagetable(p2m_get_hostp2m(d)));=0A     hd->pgd_maddr =3D =
pagetable_get_paddr(pagetable_from_mfn(pgd_mfn));=0A-#endif=0A }=0A =0A =
static int rmrr_identity_mapping(struct domain *d,=0A--- a/xen/drivers/pass=
through/vtd/utils.c=0A+++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ =
-301,8 +301,7 @@ static void dump_iommu_info(unsigned cha=0A         }=0A  =
   }=0A #else=0A-    printk("%s: not implemnted on IA64 for now.\n", =
__func__);=0A-    /* ia64: TODO */=0A+    printk("%s: not implemented for =
now\n", __func__);=0A #endif=0A }=0A =0A--- a/xen/drivers/passthrough/vtd/v=
td.h=0A+++ b/xen/drivers/passthrough/vtd/vtd.h=0A@@ -26,44 +26,8 @@=0A =
#define MAP_ME_PHANTOM_FUNC      1=0A #define UNMAP_ME_PHANTOM_FUNC    =
0=0A =0A-/* Accomodate both IOAPIC and IOSAPIC. */=0A-#ifndef __ia64__=0A+/=
* Allow for both IOAPIC and IOSAPIC. */=0A #define IO_xAPIC_route_entry =
IO_APIC_route_entry=0A-#else=0A-struct IO_xAPIC_route_entry {=0A-    __u32 =
  vector      :  8,=0A-        delivery_mode   :  3,   /* 000: FIXED=0A-   =
                              * 001: lowest prio=0A-                       =
          * 111: ExtINT=0A-                                 */=0A-        =
dest_mode       :  1,   /* 0: physical, 1: logical */=0A-        delivery_s=
tatus :  1,=0A-        polarity        :  1,=0A-        irr             :  =
1,=0A-        trigger         :  1,   /* 0: edge, 1: level */=0A-        =
mask            :  1,   /* 0: enabled, 1: disabled */=0A-        __reserved=
_2    : 15;=0A-=0A-    union {=0A-        struct { __u32=0A-            =
__reserved_1    : 24,=0A-            physical_dest   :  4,=0A-            =
__reserved_2    :  4;=0A-        } physical;=0A-=0A-        struct { =
__u32=0A-            __reserved_1    : 24,=0A-            logical_dest    =
:  8;=0A-        } logical;=0A-=0A-        struct { __u32=0A-            =
__reserved_1    : 16,=0A-            dest_id         : 16;=0A-        =
};=0A-    } dest;=0A-=0A-} __attribute__ ((packed));=0A-#endif=0A =0A =
struct IO_APIC_route_remap_entry {=0A     union {=0A--- a/xen/include/Makef=
ile=0A+++ b/xen/include/Makefile=0A@@ -38,7 +38,7 @@ suffix-$(CONFIG_X86)  =
    :=3D \#pragma pa=0A endif=0A =0A public-$(CONFIG_X86) :=3D $(wildcard =
public/arch-x86/*.h public/arch-x86/*/*.h)=0A-public-$(CONFIG_IA64) :=3D =
$(wildcard public/arch-ia64/*.h public/arch-ia64/*/*.h)=0A+public-$(CONFIG_=
ARM) :=3D $(wildcard public/arch-arm/*.h public/arch-arm/*/*.h)=0A =0A =
.PHONY: all=0A all: $(headers-y)=0A@@ -74,8 +74,6 @@ compat/xlat.h: =
xlat.lst $(filter-out com=0A 	mv -f $@.new $@=0A =0A ifeq ($(XEN_TARGET_A=
RCH),$(XEN_COMPILE_ARCH))=0A-# public/arch-ia64.h explicitly bails on =
__STRICT_ANSI__=0A-ifeq ($(CONFIG_IA64),)=0A =0A all: headers.chk=0A =0A@@ =
-84,7 +82,6 @@ headers.chk: $(filter-out public/arch-% =0A 	mv $@.new =
$@=0A =0A endif=0A-endif=0A =0A clean::=0A 	rm -rf compat headers.chk=
=0A--- a/xen/include/asm-x86/hvm/irq.h=0A+++ b/xen/include/asm-x86/hvm/irq.=
h=0A@@ -104,11 +104,4 @@ struct hvm_intack hvm_vcpu_has_pending_i=0A =
struct hvm_intack hvm_vcpu_ack_pending_irq(struct vcpu *v,=0A              =
                              struct hvm_intack intack);=0A =0A-/*=0A- * =
Currently IA64 Xen doesn't support MSI. So for x86, we define this =
macro=0A- * to control the conditional compilation of some MSI-related =
functions.=0A- * This macro will be removed once IA64 has MSI support.=0A- =
*/=0A-#define SUPPORT_MSI_REMAPPING 1=0A-=0A #endif /* __ASM_X86_HVM_IRQ_H_=
_ */=0A--- a/xen/include/asm-x86/hvm/vioapic.h=0A+++ b/xen/include/asm-x86/=
hvm/vioapic.h=0A@@ -41,7 +41,7 @@=0A /* Direct registers. */=0A #define =
VIOAPIC_REG_SELECT  0x00=0A #define VIOAPIC_REG_WINDOW  0x10=0A-#define =
VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */=0A+#define VIOAPIC_REG_EOI=
     0x40=0A =0A /* Indirect registers. */=0A #define VIOAPIC_REG_APIC_ID =
0x00 /* x86 IOAPIC only */=0A--- a/xen/include/xen/cpumask.h=0A+++ =
b/xen/include/xen/cpumask.h=0A@@ -82,7 +82,7 @@ typedef struct cpumask{ =
DECLARE_BITMAP(b=0A =0A extern unsigned int nr_cpu_ids;=0A =0A-#if NR_CPUS =
> 4 * BITS_PER_LONG && !defined(__ia64__)=0A+#if NR_CPUS > 4 * BITS_PER_LON=
G=0A /* Assuming NR_CPUS is huge, a runtime limit is more efficient.  =
Also,=0A  * not all bits may be allocated. */=0A extern unsigned int =
nr_cpumask_bits;=0A@@ -263,37 +263,6 @@ static inline const cpumask_t =
*cpumask_o=0A 	return (const cpumask_t *)(p - cpu / BITS_PER_LONG);=0A =
}=0A =0A-#if defined(__ia64__) /* XXX needs cleanup */=0A-#define =
CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)=0A-=0A-#if NR_CPUS <=3D =
BITS_PER_LONG=0A-=0A-#define CPU_MASK_ALL					=
		\=0A-/*(cpumask_t)*/ { {					=
		\=0A-	[BITS_TO_LONGS(NR_CPUS)-1] =3D CPU_MASK_LAST_WORD	=
		\=0A-} }=0A-=0A-#else=0A-=0A-#define CPU_MASK_ALL		=
					\=0A-/*(cpumask_t)*/ { {		=
					\=0A-	[0 ... BITS_TO_LONGS(NR_CPU=
S)-2] =3D ~0UL,			\=0A-	[BITS_TO_LONGS(NR_CPUS)-1] =3D =
CPU_MASK_LAST_WORD			\=0A-} }=0A-=0A-#endif=0A-=0A-#defi=
ne CPU_MASK_NONE							=
\=0A-/*(cpumask_t)*/ { {							=
\=0A-	0UL								=
\=0A-} }=0A-=0A-#define CPU_MASK_CPU0						=
	\=0A-/*(cpumask_t)*/ { {						=
	\=0A-	[0] =3D  1UL							=
\=0A-} }=0A-#endif /* __ia64__ */=0A-=0A #define cpumask_bits(maskp) =
((maskp)->bits)=0A =0A static inline int cpumask_scnprintf(char *buf, int =
len,=0A--- a/xen/include/xen/efi.h=0A+++ b/xen/include/xen/efi.h=0A@@ =
-5,15 +5,11 @@=0A #include <xen/types.h>=0A #endif=0A =0A-#if defined(__ia6=
4__)=0A-# include_next <linux/efi.h>=0A+#if defined(__i386__)=0A+# define =
efi_enabled 0=0A #else=0A-=0A-# if defined(__i386__)=0A-#  define =
efi_enabled 0=0A-# else=0A extern const bool_t efi_enabled;=0A-# endif=0A+#=
endif=0A =0A #define EFI_INVALID_TABLE_ADDR (~0UL)=0A =0A@@ -27,8 +23,6 @@ =
struct efi {=0A =0A extern struct efi efi;=0A =0A-#endif=0A-=0A #ifndef =
__ASSEMBLY__=0A =0A union xenpf_efi_info;=0A--- a/xen/include/xen/elfcore.h=
=0A+++ b/xen/include/xen/elfcore.h=0A@@ -69,9 +69,6 @@ typedef struct {=0A =
    unsigned long xen_phys_start;=0A     unsigned long dom0_pfn_to_mfn_fram=
e_list_list;=0A #endif=0A-#if defined(__ia64__)=0A-    unsigned long =
dom0_mm_pgd_mfn;=0A-#endif=0A } crash_xen_info_t;=0A =0A #endif /* =
__ELFCOREC_H__ */=0A--- a/xen/include/xen/hvm/irq.h=0A+++ b/xen/include/xen=
/hvm/irq.h=0A@@ -78,8 +78,6 @@ struct hvm_girq_dpci_mapping {=0A #define =
NR_LINK     4=0A #if defined(__i386__) || defined(__x86_64__)=0A # define =
NR_HVM_IRQS VIOAPIC_NUM_PINS=0A-#elif defined(__ia64__)=0A-# define =
NR_HVM_IRQS VIOSAPIC_NUM_PINS=0A #endif=0A =0A /* Protected by domain's =
event_lock */=0A--- a/xen/include/xen/iommu.h=0A+++ b/xen/include/xen/iommu=
.h=0A@@ -35,11 +35,7 @@ extern bool_t iommu_debug;=0A extern bool_t =
amd_iommu_perdev_intremap;=0A =0A /* Does this domain have a P2M table we =
can use as its IOMMU pagetable? */=0A-#ifndef __ia64__=0A #define =
iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)=0A-#else=0A-#def=
ine iommu_use_hap_pt(d) 0=0A-#endif=0A =0A extern struct rangeset =
*mmio_ro_ranges;=0A =0A--- a/xen/include/xen/irq.h=0A+++ b/xen/include/xen/=
irq.h=0A@@ -95,37 +95,19 @@ int arch_init_one_irq_desc(struct irq_de=0A =
=0A #define irq_desc_initialized(desc) ((desc)->handler !=3D NULL)=0A =
=0A-#if defined(__ia64__)=0A-extern irq_desc_t irq_desc[NR_VECTORS];=0A-=0A=
-#define setup_irq(irq, action) \=0A-    setup_irq_vector(irq_to_vector(irq=
), action)=0A-=0A-#define release_irq(irq) \=0A-    release_irq_vector(irq_=
to_vector(irq))=0A-=0A-#define request_irq(irq, handler, irqflags, =
devname, devid) \=0A-    request_irq_vector(irq_to_vector(irq), handler, =
irqflags, devname, devid)=0A-=0A-#elif defined(__arm__)=0A+#if defined(__ar=
m__)=0A =0A #define NR_IRQS		1024=0A #define nr_irqs NR_IRQS=0A =
extern irq_desc_t irq_desc[NR_IRQS];=0A =0A-extern int setup_irq(unsigned =
int irq, struct irqaction *);=0A-extern void release_irq(unsigned int =
irq);=0A-extern int request_irq(unsigned int irq,=0A-               void =
(*handler)(int, void *, struct cpu_user_regs *),=0A-               =
unsigned long irqflags, const char * devname, void *dev_id);=0A+#endif=0A =
=0A-#else=0A extern int setup_irq(unsigned int irq, struct irqaction =
*);=0A extern void release_irq(unsigned int irq);=0A extern int request_irq=
(unsigned int irq,=0A                void (*handler)(int, void *, struct =
cpu_user_regs *),=0A                unsigned long irqflags, const char * =
devname, void *dev_id);=0A-#endif=0A =0A extern hw_irq_controller =
no_irq_type;=0A extern void no_action(int cpl, void *dev_id, struct =
cpu_user_regs *regs);=0A--- a/xen/include/xen/libelf.h=0A+++ b/xen/include/=
xen/libelf.h=0A@@ -23,7 +23,7 @@=0A #ifndef __XEN_LIBELF_H__=0A #define =
__XEN_LIBELF_H__=0A =0A-#if defined(__i386__) || defined(__x86_64__) || =
defined(__ia64__) || defined(__arm__)=0A+#if defined(__i386__) || =
defined(__x86_64__) || defined(__arm__)=0A #define XEN_ELF_LITTLE_ENDIAN=0A=
 #else=0A #error define architectural endianness=0A--- a/xen/include/xen/sy=
mbols.h=0A+++ b/xen/include/xen/symbols.h=0A@@ -21,13 +21,9 @@ static void =
__check_printsym_format(cons=0A {=0A }=0A =0A-/* ia64 and ppc64 use =
function descriptors, which contain the real address */=0A-#if defined(CONF=
IG_IA64) || defined(CONFIG_PPC64)=0A-#define print_fn_descriptor_symbol(fmt=
, addr)		\=0A-do {						=
\=0A-	unsigned long *__faddr =3D (unsigned long*) addr;		=
\=0A-	print_symbol(fmt, __faddr[0]);		\=0A-} while (0)=0A+#if =
0=0A+#define print_fn_descriptor_symbol(fmt, addr)	\=0A+	print_symbo=
l(fmt, *(unsigned long *)addr)=0A #else=0A #define print_fn_descriptor_symb=
ol(fmt, addr) print_symbol(fmt, addr)=0A #endif=0A
--=__PartB6988E59.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB6988E59.3__=--


From xen-devel-bounces@lists.xen.org Tue Apr 03 08:19:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEywb-0002kj-Tp; Tue, 03 Apr 2012 08:18:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SEywa-0002ka-GA
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 08:18:25 +0000
Received: from [85.158.138.51:57603] by server-11.bemta-3.messagelabs.com id
	51/68-12049-F42BA7F4; Tue, 03 Apr 2012 08:18:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333441099!20523447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4607 invoked from network); 3 Apr 2012 08:18:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 08:18:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 09:18:18 +0100
Message-Id: <4F7ACE69020000780007C3E0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 09:18:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,<xen-devel@lists.xen.org>
References: <4F79DEEB020000780007C0F3@nat28.tlf.novell.com>
	<CB9F855E.2FDCE%keir.xen@gmail.com>
In-Reply-To: <CB9F855E.2FDCE%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB6988E59.3__="
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, Ian.Campbell@citrix.com,
	xen-ia64-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB6988E59.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 02.04.12 at 17:33, Keir Fraser <keir.xen@gmail.com> wrote:
> On 02/04/2012 16:16, "Jan Beulich" <JBeulich@suse.com> wrote:
>> now that we apparently having reached consensus here, are you
>> going to purge the ia64 bits from the tree, or do you want me to?
>=20
> Please go ahead.

This is the patch I'm intending to commit (omitting all the ia64 files
that are going to be removed).

It retains IA64-specific bits in code imported from elsewhere (e.g.
ACPI, EFI) as well as in the public headers.

It also doesn't touch the tools, mini-os, and unmodified_drivers
sub-trees.

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,14 +138,6 @@ M:	Tim Deegan <tim@xen.org>
 S:	Supported
 F:	tools/debugger/kdd/
=20
-IA64 ARCHITECTURE
-M:	KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
-S:	Supported
-L:	xen-ia64-devel@lists.xensource.com=20
-F:	xen/arch/ia64/*
-F:	xen/include/asm-ia64/*
-F:	tools/libxc/ia64/*
-
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 M:	Joseph Cihula <joseph.cihula@intel.com>
 M:	Gang Wei <gang.wei@intel.com>
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -58,7 +58,6 @@ subdir-$(CONFIG_COMPAT) +=3D compat
=20
 subdir-$(x86_32) +=3D hvm
 subdir-$(x86_64) +=3D hvm
-subdir-$(ia64) +=3D hvm
=20
 subdir-y +=3D libelf
 subdir-$(HAS_DEVICE_TREE) +=3D libfdt
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1514,9 +1514,7 @@ gnttab_transfer(
             goto copyback;
         }
=20
-#ifndef __ia64__ /* IA64 implicitly replaces the old page in steal_page().=
 */
         guest_physmap_remove_page(d, gop.mfn, mfn, 0);
-#endif
         flush_tlb_mask(d->domain_dirty_cpumask);
=20
         /* Find the target domain. */
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -721,11 +721,7 @@ static void crash_save_vmcoreinfo(void)
     VMCOREINFO_STRUCT_SIZE(domain);
=20
     VMCOREINFO_OFFSET(page_info, count_info);
-#ifdef __ia64__
-    VMCOREINFO_OFFSET_SUB(page_info, u.inuse, _domain);
-#else
     VMCOREINFO_OFFSET_SUB(page_info, v.inuse, _domain);
-#endif
     VMCOREINFO_OFFSET(domain, domain_id);
     VMCOREINFO_OFFSET(domain, next_in_list);
=20
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,9 +23,7 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifndef __ia64__
 #include <asm/p2m.h>
-#endif
 #include <xen/numa.h>
 #include <public/memory.h>
 #include <xsm/xsm.h>
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1141,7 +1141,7 @@ void __init scrub_heap_pages(void)
  * XEN-HEAP SUB-ALLOCATOR
  */
=20
-#if !defined(__x86_64__) && !defined(__ia64__)
+#if !defined(__x86_64__)
=20
 void init_xenheap_pages(paddr_t ps, paddr_t pe)
 {
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -88,7 +88,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
=20
-#if defined(__ia64__) || defined (CONFIG_ARM)
+#if defined(CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long =
*pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -442,16 +442,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
             goto out;
         }
=20
-#ifdef CONFIG_IA64
-        /* for IA64, currently it only supports FFH */
-        if (dom0_px_info->control_register.space_id !=3D
-            ACPI_ADR_SPACE_FIXED_HARDWARE)
-        {
-            ret =3D -EINVAL;
-            goto out;
-        }
-#endif
-
         memcpy ((void *)&pxpt->control_register,
                 (void *)&dom0_px_info->control_register,
                 sizeof(struct xen_pct_register));
@@ -493,7 +483,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
     {
 #ifdef CONFIG_X86
         /* for X86, check domain coordination */
-        /* for IA64, _PSD is optional for current IA64 cpufreq algorithm =
*/
         if (dom0_px_info->shared_type !=3D CPUFREQ_SHARED_TYPE_ALL &&
             dom0_px_info->shared_type !=3D CPUFREQ_SHARED_TYPE_ANY &&
             dom0_px_info->shared_type !=3D CPUFREQ_SHARED_TYPE_HW)
--- a/xen/drivers/passthrough/Makefile
+++ b/xen/drivers/passthrough/Makefile
@@ -1,5 +1,4 @@
 subdir-$(x86) +=3D vtd
-subdir-$(ia64) +=3D vtd
 subdir-$(x86) +=3D amd
 subdir-$(x86_64) +=3D x86
=20
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -419,7 +419,6 @@ int hvm_do_IRQ_dpci(struct domain *d, st
     return 1;
 }
=20
-#ifdef SUPPORT_MSI_REMAPPING
 /* called with d->event_lock held */
 static void __msi_pirq_eoi(struct hvm_pirq_dpci *pirq_dpci)
 {
@@ -479,7 +478,6 @@ static int hvm_pci_msi_assert(struct dom
             ? send_guest_pirq(d, pirq)
             : vmsi_deliver_pirq(d, pirq_dpci));
 }
-#endif
=20
 static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci =
*pirq_dpci,
                             void *arg)
@@ -489,13 +487,12 @@ static int _hvm_dirq_assist(struct domai
=20
     if ( test_and_clear_bool(pirq_dpci->masked) )
     {
-#ifdef SUPPORT_MSI_REMAPPING
         if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
         {
             hvm_pci_msi_assert(d, pirq_dpci);
             return 0;
         }
-#endif
+
         list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
         {
             struct pirq *info =3D dpci_pirq(pirq_dpci);
@@ -508,13 +505,11 @@ static int _hvm_dirq_assist(struct domai
                 hvm_pci_intx_assert(d, device, intx);
             pirq_dpci->pending++;
=20
-#ifdef SUPPORT_MSI_REMAPPING
             if ( pirq_dpci->flags & HVM_IRQ_DPCI_TRANSLATE )
             {
                 /* for translated MSI to INTx interrupt, eoi as early as =
possible */
                 __msi_pirq_eoi(pirq_dpci);
             }
-#endif
         }
=20
         /*
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -593,17 +593,6 @@ int iommu_do_domctl(
         bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
         devfn =3D domctl->u.assign_device.machine_sbdf & 0xff;
=20
-#ifdef __ia64__ /* XXX Is this really needed? */
-        if ( device_assigned(seg, bus, devfn) )
-        {
-            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
-                   "%04x:%02x:%02x.%u already assigned, or non-existent\n"=
,
-                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
-            ret =3D -EINVAL;
-            goto assign_device_out;
-        }
-#endif
-
         ret =3D assign_device(d, seg, bus, devfn);
         if ( ret )
             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
@@ -632,14 +621,6 @@ int iommu_do_domctl(
         bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
         devfn =3D domctl->u.assign_device.machine_sbdf & 0xff;
=20
-#ifdef __ia64__ /* XXX Is this really needed? */
-        if ( !device_assigned(seg, bus, devfn) )
-        {
-            ret =3D -EINVAL;
-            goto deassign_device_out;
-        }
-#endif
-
         spin_lock(&pcidevs_lock);
         ret =3D deassign_device(d, seg, bus, devfn);
         spin_unlock(&pcidevs_lock);
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -696,7 +696,6 @@ void __init setup_dom0_pci_devices(
     spin_unlock(&pcidevs_lock);
 }
=20
-#ifdef SUPPORT_MSI_REMAPPING
 static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
 {
     struct pci_dev *pdev;
@@ -738,8 +737,6 @@ static int __init setup_dump_pcidevs(voi
     return 0;
 }
 __initcall(setup_dump_pcidevs);
-#endif
-
=20
 /*
  * Local variables:
--- a/xen/drivers/passthrough/vtd/Makefile
+++ b/xen/drivers/passthrough/vtd/Makefile
@@ -1,5 +1,4 @@
 subdir-$(x86) +=3D x86
-subdir-$(ia64) +=3D ia64
=20
 obj-y +=3D iommu.o
 obj-y +=3D dmar.o
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -31,26 +31,7 @@
 #include "vtd.h"
 #include "extern.h"
=20
-#ifdef __ia64__
-#define nr_ioapics              iosapic_get_nr_iosapics()
-#define nr_ioapic_entries(i)  iosapic_get_nr_pins(i)
-#define __io_apic_read(apic, reg) \
-    (*IO_APIC_BASE(apic) =3D reg, *(IO_APIC_BASE(apic)+4))
-#define __io_apic_write(apic, reg, val) \
-    (*IO_APIC_BASE(apic) =3D reg, *(IO_APIC_BASE(apic)+4) =3D (val))
-#define __ioapic_read_entry(apic, pin, raw) ({ \
-    struct IO_xAPIC_route_entry _e_; \
-    ASSERT(raw); \
-    ((u32 *)&_e_)[0] =3D __io_apic_read(apic, 0x10 + 2 * (pin)); \
-    ((u32 *)&_e_)[1] =3D __io_apic_read(apic, 0x11 + 2 * (pin)); \
-    _e_; \
-})
-#define __ioapic_write_entry(apic, pin, raw, ent) ({ \
-    ASSERT(raw); \
-    __io_apic_write(apic, 0x10 + 2 * (pin), ((u32 *)&(ent))[0]); \
-    __io_apic_write(apic, 0x11 + 2 * (pin), ((u32 *)&(ent))[1]); \
-})
-#else
+#if defined(__i386__) || defined(__x86_64__)
 #include <asm/apic.h>
 #include <asm/io_apic.h>
 #define nr_ioapic_entries(i)  nr_ioapic_entries[i]
@@ -326,8 +307,6 @@ static int ioapic_rte_to_remap_entry(str
             new_ire.lo.dst =3D value;
         else
             new_ire.lo.dst =3D (value >> 24) << 8;
-#else /* __ia64__ */
-        new_ire.lo.dst =3D value >> 16;
 #endif
     }
     else
@@ -625,12 +604,8 @@ static int msi_msg_to_remap_entry(
     new_ire.lo.dm =3D (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
     new_ire.lo.tm =3D (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
     new_ire.lo.dlm =3D (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x1;
-#ifdef CONFIG_X86
     /* Hardware require RH =3D 1 for LPR delivery mode */
     new_ire.lo.rh =3D (new_ire.lo.dlm =3D=3D dest_LowestPrio);
-#else
-    new_ire.lo.rh =3D 0;
-#endif
     new_ire.lo.avail =3D 0;
     new_ire.lo.res_1 =3D 0;
     new_ire.lo.vector =3D (msg->data >> MSI_DATA_VECTOR_SHIFT) &
@@ -703,18 +678,6 @@ void msi_msg_write_remap_rte(
=20
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
 }
-#elif defined(__ia64__)
-void msi_msg_read_remap_rte(
-    struct msi_desc *msi_desc, struct msi_msg *msg)
-{
-    /* TODO. */
-}
-
-void msi_msg_write_remap_rte(
-    struct msi_desc *msi_desc, struct msi_msg *msg)
-{
-    /* TODO. */
-}
 #endif
=20
 int enable_intremap(struct iommu *iommu, int eim)
@@ -838,8 +801,6 @@ out:
     spin_unlock_irqrestore(&iommu->register_lock, flags);
 }
=20
-#ifndef __ia64__
-
 /*
  * This function is used to enable Interrupt remapping when
  * enable x2apic
@@ -914,5 +875,3 @@ void iommu_disable_x2apic_IR(void)
     for_each_drhd_unit ( drhd )
         disable_qinval(drhd->iommu);
 }
-
-#endif /* !__ia64__ */
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -33,7 +33,7 @@
 #include <xen/keyhandler.h>
 #include <asm/msi.h>
 #include <asm/irq.h>
-#ifndef __ia64__
+#if defined(__i386__) || defined(__x86_64__)
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/p2m.h>
 #include <mach_apic.h>
@@ -44,10 +44,6 @@
 #include "vtd.h"
 #include "../ats.h"
=20
-#ifdef __ia64__
-#define nr_ioapics              iosapic_get_nr_iosapics()
-#endif
-
 /* Possible unfiltered LAPIC/MSI messages from untrusted sources? */
 bool_t __read_mostly untrusted_msi;
=20
@@ -1057,11 +1053,7 @@ static unsigned int dma_msi_startup(stru
     return 0;
 }
=20
-#ifndef __ia64__
 static void dma_msi_end(struct irq_desc *desc, u8 vector)
-#else
-static void dma_msi_end(struct irq_desc *desc)
-#endif
 {
     dma_msi_unmask(desc);
     ack_APIC_irq();
@@ -1841,7 +1833,6 @@ void iommu_pte_flush(struct domain *d, u
=20
 static int vtd_ept_page_compatible(struct iommu *iommu)
 {
-#ifndef __ia64__
     u64 ept_cap, vtd_cap =3D iommu->cap;
=20
     /* EPT is not initialised yet, so we must check the capability in
@@ -1851,9 +1842,6 @@ static int vtd_ept_page_compatible(struc
=20
     return ( ept_has_2mb(ept_cap) =3D=3D cap_sps_2mb(vtd_cap)=20
              && ept_has_1gb(ept_cap) =3D=3D cap_sps_1gb(vtd_cap) );
-#else
-    return 0;
-#endif
 }
=20
 /*
@@ -1861,7 +1849,6 @@ static int vtd_ept_page_compatible(struc
  */
 void iommu_set_pgd(struct domain *d)
 {
-#ifndef __ia64__
     struct hvm_iommu *hd  =3D domain_hvm_iommu(d);
     mfn_t pgd_mfn;
=20
@@ -1872,7 +1859,6 @@ void iommu_set_pgd(struct domain *d)
=20
     pgd_mfn =3D pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
     hd->pgd_maddr =3D pagetable_get_paddr(pagetable_from_mfn(pgd_mfn));
-#endif
 }
=20
 static int rmrr_identity_mapping(struct domain *d,
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -301,8 +301,7 @@ static void dump_iommu_info(unsigned cha
         }
     }
 #else
-    printk("%s: not implemnted on IA64 for now.\n", __func__);
-    /* ia64: TODO */
+    printk("%s: not implemented for now\n", __func__);
 #endif
 }
=20
--- a/xen/drivers/passthrough/vtd/vtd.h
+++ b/xen/drivers/passthrough/vtd/vtd.h
@@ -26,44 +26,8 @@
 #define MAP_ME_PHANTOM_FUNC      1
 #define UNMAP_ME_PHANTOM_FUNC    0
=20
-/* Accomodate both IOAPIC and IOSAPIC. */
-#ifndef __ia64__
+/* Allow for both IOAPIC and IOSAPIC. */
 #define IO_xAPIC_route_entry IO_APIC_route_entry
-#else
-struct IO_xAPIC_route_entry {
-    __u32   vector      :  8,
-        delivery_mode   :  3,   /* 000: FIXED
-                                 * 001: lowest prio
-                                 * 111: ExtINT
-                                 */
-        dest_mode       :  1,   /* 0: physical, 1: logical */
-        delivery_status :  1,
-        polarity        :  1,
-        irr             :  1,
-        trigger         :  1,   /* 0: edge, 1: level */
-        mask            :  1,   /* 0: enabled, 1: disabled */
-        __reserved_2    : 15;
-
-    union {
-        struct { __u32
-            __reserved_1    : 24,
-            physical_dest   :  4,
-            __reserved_2    :  4;
-        } physical;
-
-        struct { __u32
-            __reserved_1    : 24,
-            logical_dest    :  8;
-        } logical;
-
-        struct { __u32
-            __reserved_1    : 16,
-            dest_id         : 16;
-        };
-    } dest;
-
-} __attribute__ ((packed));
-#endif
=20
 struct IO_APIC_route_remap_entry {
     union {
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -38,7 +38,7 @@ suffix-$(CONFIG_X86)      :=3D \#pragma pa
 endif
=20
 public-$(CONFIG_X86) :=3D $(wildcard public/arch-x86/*.h public/arch-x86/*=
/*.h)
-public-$(CONFIG_IA64) :=3D $(wildcard public/arch-ia64/*.h public/arch-ia6=
4/*/*.h)
+public-$(CONFIG_ARM) :=3D $(wildcard public/arch-arm/*.h public/arch-arm/*=
/*.h)
=20
 .PHONY: all
 all: $(headers-y)
@@ -74,8 +74,6 @@ compat/xlat.h: xlat.lst $(filter-out com
 	mv -f $@.new $@
=20
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
-# public/arch-ia64.h explicitly bails on __STRICT_ANSI__
-ifeq ($(CONFIG_IA64),)
=20
 all: headers.chk
=20
@@ -84,7 +82,6 @@ headers.chk: $(filter-out public/arch-%=20
 	mv $@.new $@
=20
 endif
-endif
=20
 clean::
 	rm -rf compat headers.chk
--- a/xen/include/asm-x86/hvm/irq.h
+++ b/xen/include/asm-x86/hvm/irq.h
@@ -104,11 +104,4 @@ struct hvm_intack hvm_vcpu_has_pending_i
 struct hvm_intack hvm_vcpu_ack_pending_irq(struct vcpu *v,
                                            struct hvm_intack intack);
=20
-/*
- * Currently IA64 Xen doesn't support MSI. So for x86, we define this =
macro
- * to control the conditional compilation of some MSI-related functions.
- * This macro will be removed once IA64 has MSI support.
- */
-#define SUPPORT_MSI_REMAPPING 1
-
 #endif /* __ASM_X86_HVM_IRQ_H__ */
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -41,7 +41,7 @@
 /* Direct registers. */
 #define VIOAPIC_REG_SELECT  0x00
 #define VIOAPIC_REG_WINDOW  0x10
-#define VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */
+#define VIOAPIC_REG_EOI     0x40
=20
 /* Indirect registers. */
 #define VIOAPIC_REG_APIC_ID 0x00 /* x86 IOAPIC only */
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -82,7 +82,7 @@ typedef struct cpumask{ DECLARE_BITMAP(b
=20
 extern unsigned int nr_cpu_ids;
=20
-#if NR_CPUS > 4 * BITS_PER_LONG && !defined(__ia64__)
+#if NR_CPUS > 4 * BITS_PER_LONG
 /* Assuming NR_CPUS is huge, a runtime limit is more efficient.  Also,
  * not all bits may be allocated. */
 extern unsigned int nr_cpumask_bits;
@@ -263,37 +263,6 @@ static inline const cpumask_t *cpumask_o
 	return (const cpumask_t *)(p - cpu / BITS_PER_LONG);
 }
=20
-#if defined(__ia64__) /* XXX needs cleanup */
-#define CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)
-
-#if NR_CPUS <=3D BITS_PER_LONG
-
-#define CPU_MASK_ALL							\
-/*(cpumask_t)*/ { {							\
-	[BITS_TO_LONGS(NR_CPUS)-1] =3D CPU_MASK_LAST_WORD			=
\
-} }
-
-#else
-
-#define CPU_MASK_ALL							\
-/*(cpumask_t)*/ { {							\
-	[0 ... BITS_TO_LONGS(NR_CPUS)-2] =3D ~0UL,			\
-	[BITS_TO_LONGS(NR_CPUS)-1] =3D CPU_MASK_LAST_WORD			=
\
-} }
-
-#endif
-
-#define CPU_MASK_NONE							\
-/*(cpumask_t)*/ { {							\
-	0UL								\
-} }
-
-#define CPU_MASK_CPU0							\
-/*(cpumask_t)*/ { {							\
-	[0] =3D  1UL							\
-} }
-#endif /* __ia64__ */
-
 #define cpumask_bits(maskp) ((maskp)->bits)
=20
 static inline int cpumask_scnprintf(char *buf, int len,
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -5,15 +5,11 @@
 #include <xen/types.h>
 #endif
=20
-#if defined(__ia64__)
-# include_next <linux/efi.h>
+#if defined(__i386__)
+# define efi_enabled 0
 #else
-
-# if defined(__i386__)
-#  define efi_enabled 0
-# else
 extern const bool_t efi_enabled;
-# endif
+#endif
=20
 #define EFI_INVALID_TABLE_ADDR (~0UL)
=20
@@ -27,8 +23,6 @@ struct efi {
=20
 extern struct efi efi;
=20
-#endif
-
 #ifndef __ASSEMBLY__
=20
 union xenpf_efi_info;
--- a/xen/include/xen/elfcore.h
+++ b/xen/include/xen/elfcore.h
@@ -69,9 +69,6 @@ typedef struct {
     unsigned long xen_phys_start;
     unsigned long dom0_pfn_to_mfn_frame_list_list;
 #endif
-#if defined(__ia64__)
-    unsigned long dom0_mm_pgd_mfn;
-#endif
 } crash_xen_info_t;
=20
 #endif /* __ELFCOREC_H__ */
--- a/xen/include/xen/hvm/irq.h
+++ b/xen/include/xen/hvm/irq.h
@@ -78,8 +78,6 @@ struct hvm_girq_dpci_mapping {
 #define NR_LINK     4
 #if defined(__i386__) || defined(__x86_64__)
 # define NR_HVM_IRQS VIOAPIC_NUM_PINS
-#elif defined(__ia64__)
-# define NR_HVM_IRQS VIOSAPIC_NUM_PINS
 #endif
=20
 /* Protected by domain's event_lock */
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -35,11 +35,7 @@ extern bool_t iommu_debug;
 extern bool_t amd_iommu_perdev_intremap;
=20
 /* Does this domain have a P2M table we can use as its IOMMU pagetable? =
*/
-#ifndef __ia64__
 #define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
-#else
-#define iommu_use_hap_pt(d) 0
-#endif
=20
 extern struct rangeset *mmio_ro_ranges;
=20
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -95,37 +95,19 @@ int arch_init_one_irq_desc(struct irq_de
=20
 #define irq_desc_initialized(desc) ((desc)->handler !=3D NULL)
=20
-#if defined(__ia64__)
-extern irq_desc_t irq_desc[NR_VECTORS];
-
-#define setup_irq(irq, action) \
-    setup_irq_vector(irq_to_vector(irq), action)
-
-#define release_irq(irq) \
-    release_irq_vector(irq_to_vector(irq))
-
-#define request_irq(irq, handler, irqflags, devname, devid) \
-    request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, =
devid)
-
-#elif defined(__arm__)
+#if defined(__arm__)
=20
 #define NR_IRQS		1024
 #define nr_irqs NR_IRQS
 extern irq_desc_t irq_desc[NR_IRQS];
=20
-extern int setup_irq(unsigned int irq, struct irqaction *);
-extern void release_irq(unsigned int irq);
-extern int request_irq(unsigned int irq,
-               void (*handler)(int, void *, struct cpu_user_regs *),
-               unsigned long irqflags, const char * devname, void =
*dev_id);
+#endif
=20
-#else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
 extern int request_irq(unsigned int irq,
                void (*handler)(int, void *, struct cpu_user_regs *),
                unsigned long irqflags, const char * devname, void =
*dev_id);
-#endif
=20
 extern hw_irq_controller no_irq_type;
 extern void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs);
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
=20
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || =
defined(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -21,13 +21,9 @@ static void __check_printsym_format(cons
 {
 }
=20
-/* ia64 and ppc64 use function descriptors, which contain the real =
address */
-#if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
-#define print_fn_descriptor_symbol(fmt, addr)		\
-do {						\
-	unsigned long *__faddr =3D (unsigned long*) addr;		\
-	print_symbol(fmt, __faddr[0]);		\
-} while (0)
+#if 0
+#define print_fn_descriptor_symbol(fmt, addr)	\
+	print_symbol(fmt, *(unsigned long *)addr)
 #else
 #define print_fn_descriptor_symbol(fmt, addr) print_symbol(fmt, addr)
 #endif



--=__PartB6988E59.3__=
Content-Type: text/plain; name="ia64-purge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-purge.patch"

It retains IA64-specific bits in code imported from elsewhere (e.g.=0AACPI,=
 EFI) as well as in the public headers.=0A=0AIt also doesn't touch the =
tools, mini-os, and unmodified_drivers=0Asub-trees.=0A=0A--- a/MAINTAINERS=
=0A+++ b/MAINTAINERS=0A@@ -138,14 +138,6 @@ M:	Tim Deegan <tim@xen.org>=0A=
 S:	Supported=0A F:	tools/debugger/kdd/=0A =0A-IA64 ARCHITECTURE=0A-M:	=
KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>=0A-S:	Supported=0A-L:	xen-ia64-de=
vel@lists.xensource.com=0A-F:	xen/arch/ia64/*=0A-F:	xen/include/asm-ia6=
4/*=0A-F:	tools/libxc/ia64/*=0A-=0A INTEL(R) TRUSTED EXECUTION =
TECHNOLOGY (TXT)=0A M:	Joseph Cihula <joseph.cihula@intel.com>=0A M:	=
Gang Wei <gang.wei@intel.com>=0A--- a/xen/common/Makefile=0A+++ b/xen/commo=
n/Makefile=0A@@ -58,7 +58,6 @@ subdir-$(CONFIG_COMPAT) +=3D compat=0A =0A =
subdir-$(x86_32) +=3D hvm=0A subdir-$(x86_64) +=3D hvm=0A-subdir-$(ia64) =
+=3D hvm=0A =0A subdir-y +=3D libelf=0A subdir-$(HAS_DEVICE_TREE) +=3D =
libfdt=0A--- a/xen/common/grant_table.c=0A+++ b/xen/common/grant_table.c=0A=
@@ -1514,9 +1514,7 @@ gnttab_transfer(=0A             goto copyback;=0A    =
     }=0A =0A-#ifndef __ia64__ /* IA64 implicitly replaces the old page in =
steal_page(). */=0A         guest_physmap_remove_page(d, gop.mfn, mfn, =
0);=0A-#endif=0A         flush_tlb_mask(d->domain_dirty_cpumask);=0A =0A   =
      /* Find the target domain. */=0A--- a/xen/common/kexec.c=0A+++ =
b/xen/common/kexec.c=0A@@ -721,11 +721,7 @@ static void crash_save_vmcorein=
fo(void)=0A     VMCOREINFO_STRUCT_SIZE(domain);=0A =0A     VMCOREINFO_OFFSE=
T(page_info, count_info);=0A-#ifdef __ia64__=0A-    VMCOREINFO_OFFSET_SUB(p=
age_info, u.inuse, _domain);=0A-#else=0A     VMCOREINFO_OFFSET_SUB(page_inf=
o, v.inuse, _domain);=0A-#endif=0A     VMCOREINFO_OFFSET(domain, domain_id)=
;=0A     VMCOREINFO_OFFSET(domain, next_in_list);=0A =0A--- a/xen/common/me=
mory.c=0A+++ b/xen/common/memory.c=0A@@ -23,9 +23,7 @@=0A #include =
<xen/tmem_xen.h>=0A #include <asm/current.h>=0A #include <asm/hardirq.h>=0A=
-#ifndef __ia64__=0A #include <asm/p2m.h>=0A-#endif=0A #include <xen/numa.h=
>=0A #include <public/memory.h>=0A #include <xsm/xsm.h>=0A--- a/xen/common/=
page_alloc.c=0A+++ b/xen/common/page_alloc.c=0A@@ -1141,7 +1141,7 @@ void =
__init scrub_heap_pages(void)=0A  * XEN-HEAP SUB-ALLOCATOR=0A  */=0A =
=0A-#if !defined(__x86_64__) && !defined(__ia64__)=0A+#if !defined(__x86_64=
__)=0A =0A void init_xenheap_pages(paddr_t ps, paddr_t pe)=0A {=0A--- =
a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ -88,7 +88,7 @@ =
void tmh_copy_page(char *to, char*from)=0A #endif=0A }=0A =0A-#if =
defined(__ia64__) || defined (CONFIG_ARM)=0A+#if defined(CONFIG_ARM)=0A =
static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long =
*pcli_mfn,=0A                                  pfp_t **pcli_pfp, bool_t =
cli_write)=0A {=0A--- a/xen/drivers/cpufreq/cpufreq.c=0A+++ b/xen/drivers/c=
pufreq/cpufreq.c=0A@@ -442,16 +442,6 @@ int set_px_pminfo(uint32_t =
acpi_id, stru=0A             goto out;=0A         }=0A =0A-#ifdef =
CONFIG_IA64=0A-        /* for IA64, currently it only supports FFH */=0A-  =
      if (dom0_px_info->control_register.space_id !=3D=0A-            =
ACPI_ADR_SPACE_FIXED_HARDWARE)=0A-        {=0A-            ret =3D =
-EINVAL;=0A-            goto out;=0A-        }=0A-#endif=0A-=0A         =
memcpy ((void *)&pxpt->control_register,=0A                 (void =
*)&dom0_px_info->control_register,=0A                 sizeof(struct =
xen_pct_register));=0A@@ -493,7 +483,6 @@ int set_px_pminfo(uint32_t =
acpi_id, stru=0A     {=0A #ifdef CONFIG_X86=0A         /* for X86, check =
domain coordination */=0A-        /* for IA64, _PSD is optional for =
current IA64 cpufreq algorithm */=0A         if (dom0_px_info->shared_type =
!=3D CPUFREQ_SHARED_TYPE_ALL &&=0A             dom0_px_info->shared_type =
!=3D CPUFREQ_SHARED_TYPE_ANY &&=0A             dom0_px_info->shared_type =
!=3D CPUFREQ_SHARED_TYPE_HW)=0A--- a/xen/drivers/passthrough/Makefile=0A+++=
 b/xen/drivers/passthrough/Makefile=0A@@ -1,5 +1,4 @@=0A subdir-$(x86) =
+=3D vtd=0A-subdir-$(ia64) +=3D vtd=0A subdir-$(x86) +=3D amd=0A subdir-$(x=
86_64) +=3D x86=0A =0A--- a/xen/drivers/passthrough/io.c=0A+++ b/xen/driver=
s/passthrough/io.c=0A@@ -419,7 +419,6 @@ int hvm_do_IRQ_dpci(struct domain =
*d, st=0A     return 1;=0A }=0A =0A-#ifdef SUPPORT_MSI_REMAPPING=0A /* =
called with d->event_lock held */=0A static void __msi_pirq_eoi(struct =
hvm_pirq_dpci *pirq_dpci)=0A {=0A@@ -479,7 +478,6 @@ static int hvm_pci_msi=
_assert(struct dom=0A             ? send_guest_pirq(d, pirq)=0A            =
 : vmsi_deliver_pirq(d, pirq_dpci));=0A }=0A-#endif=0A =0A static int =
_hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,=0A     =
                        void *arg)=0A@@ -489,13 +487,12 @@ static int =
_hvm_dirq_assist(struct domai=0A =0A     if ( test_and_clear_bool(pirq_dpci=
->masked) )=0A     {=0A-#ifdef SUPPORT_MSI_REMAPPING=0A         if ( =
pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )=0A         {=0A             =
hvm_pci_msi_assert(d, pirq_dpci);=0A             return 0;=0A         =
}=0A-#endif=0A+=0A         list_for_each_entry ( digl, &pirq_dpci->digl_lis=
t, list )=0A         {=0A             struct pirq *info =3D dpci_pirq(pirq_=
dpci);=0A@@ -508,13 +505,11 @@ static int _hvm_dirq_assist(struct domai=0A =
                hvm_pci_intx_assert(d, device, intx);=0A             =
pirq_dpci->pending++;=0A =0A-#ifdef SUPPORT_MSI_REMAPPING=0A             =
if ( pirq_dpci->flags & HVM_IRQ_DPCI_TRANSLATE )=0A             {=0A       =
          /* for translated MSI to INTx interrupt, eoi as early as =
possible */=0A                 __msi_pirq_eoi(pirq_dpci);=0A             =
}=0A-#endif=0A         }=0A =0A         /*=0A--- a/xen/drivers/passthrough/=
iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -593,17 +593,6 @@ int =
iommu_do_domctl(=0A         bus =3D (domctl->u.assign_device.machine_sbdf =
>> 8) & 0xff;=0A         devfn =3D domctl->u.assign_device.machine_sbdf & =
0xff;=0A =0A-#ifdef __ia64__ /* XXX Is this really needed? */=0A-        =
if ( device_assigned(seg, bus, devfn) )=0A-        {=0A-            =
printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "=0A-                   =
"%04x:%02x:%02x.%u already assigned, or non-existent\n",=0A-               =
    seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A-            ret =3D =
-EINVAL;=0A-            goto assign_device_out;=0A-        }=0A-#endif=0A-=
=0A         ret =3D assign_device(d, seg, bus, devfn);=0A         if ( ret =
)=0A             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "=0A@@ =
-632,14 +621,6 @@ int iommu_do_domctl(=0A         bus =3D (domctl->u.assign=
_device.machine_sbdf >> 8) & 0xff;=0A         devfn =3D domctl->u.assign_de=
vice.machine_sbdf & 0xff;=0A =0A-#ifdef __ia64__ /* XXX Is this really =
needed? */=0A-        if ( !device_assigned(seg, bus, devfn) )=0A-        =
{=0A-            ret =3D -EINVAL;=0A-            goto deassign_device_out;=
=0A-        }=0A-#endif=0A-=0A         spin_lock(&pcidevs_lock);=0A        =
 ret =3D deassign_device(d, seg, bus, devfn);=0A         spin_unlock(&pcide=
vs_lock);=0A--- a/xen/drivers/passthrough/pci.c=0A+++ b/xen/drivers/passthr=
ough/pci.c=0A@@ -696,7 +696,6 @@ void __init setup_dom0_pci_devices(=0A    =
 spin_unlock(&pcidevs_lock);=0A }=0A =0A-#ifdef SUPPORT_MSI_REMAPPING=0A =
static int _dump_pci_devices(struct pci_seg *pseg, void *arg)=0A {=0A     =
struct pci_dev *pdev;=0A@@ -738,8 +737,6 @@ static int __init setup_dump_pc=
idevs(voi=0A     return 0;=0A }=0A __initcall(setup_dump_pcidevs);=0A-#endi=
f=0A-=0A =0A /*=0A  * Local variables:=0A--- a/xen/drivers/passthrough/vtd/=
Makefile=0A+++ b/xen/drivers/passthrough/vtd/Makefile=0A@@ -1,5 +1,4 @@=0A =
subdir-$(x86) +=3D x86=0A-subdir-$(ia64) +=3D ia64=0A =0A obj-y +=3D =
iommu.o=0A obj-y +=3D dmar.o=0A--- a/xen/drivers/passthrough/vtd/intremap.c=
=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ -31,26 +31,7 @@=0A =
#include "vtd.h"=0A #include "extern.h"=0A =0A-#ifdef __ia64__=0A-#define =
nr_ioapics              iosapic_get_nr_iosapics()=0A-#define nr_ioapic_entr=
ies(i)  iosapic_get_nr_pins(i)=0A-#define __io_apic_read(apic, reg) \=0A-  =
  (*IO_APIC_BASE(apic) =3D reg, *(IO_APIC_BASE(apic)+4))=0A-#define =
__io_apic_write(apic, reg, val) \=0A-    (*IO_APIC_BASE(apic) =3D reg, =
*(IO_APIC_BASE(apic)+4) =3D (val))=0A-#define __ioapic_read_entry(apic, =
pin, raw) ({ \=0A-    struct IO_xAPIC_route_entry _e_; \=0A-    ASSERT(raw)=
; \=0A-    ((u32 *)&_e_)[0] =3D __io_apic_read(apic, 0x10 + 2 * (pin)); =
\=0A-    ((u32 *)&_e_)[1] =3D __io_apic_read(apic, 0x11 + 2 * (pin)); =
\=0A-    _e_; \=0A-})=0A-#define __ioapic_write_entry(apic, pin, raw, ent) =
({ \=0A-    ASSERT(raw); \=0A-    __io_apic_write(apic, 0x10 + 2 * (pin), =
((u32 *)&(ent))[0]); \=0A-    __io_apic_write(apic, 0x11 + 2 * (pin), =
((u32 *)&(ent))[1]); \=0A-})=0A-#else=0A+#if defined(__i386__) || =
defined(__x86_64__)=0A #include <asm/apic.h>=0A #include <asm/io_apic.h>=0A=
 #define nr_ioapic_entries(i)  nr_ioapic_entries[i]=0A@@ -326,8 +307,6 @@ =
static int ioapic_rte_to_remap_entry(str=0A             new_ire.lo.dst =3D =
value;=0A         else=0A             new_ire.lo.dst =3D (value >> 24) << =
8;=0A-#else /* __ia64__ */=0A-        new_ire.lo.dst =3D value >> 16;=0A =
#endif=0A     }=0A     else=0A@@ -625,12 +604,8 @@ static int msi_msg_to_re=
map_entry(=0A     new_ire.lo.dm =3D (msg->address_lo >> MSI_ADDR_DESTMODE_S=
HIFT) & 0x1;=0A     new_ire.lo.tm =3D (msg->data >> MSI_DATA_TRIGGER_SHIFT)=
 & 0x1;=0A     new_ire.lo.dlm =3D (msg->data >> MSI_DATA_DELIVERY_MODE_SHIF=
T) & 0x1;=0A-#ifdef CONFIG_X86=0A     /* Hardware require RH =3D 1 for LPR =
delivery mode */=0A     new_ire.lo.rh =3D (new_ire.lo.dlm =3D=3D dest_Lowes=
tPrio);=0A-#else=0A-    new_ire.lo.rh =3D 0;=0A-#endif=0A     new_ire.lo.av=
ail =3D 0;=0A     new_ire.lo.res_1 =3D 0;=0A     new_ire.lo.vector =3D =
(msg->data >> MSI_DATA_VECTOR_SHIFT) &=0A@@ -703,18 +678,6 @@ void =
msi_msg_write_remap_rte(=0A =0A     msi_msg_to_remap_entry(iommu, pdev, =
msi_desc, msg);=0A }=0A-#elif defined(__ia64__)=0A-void msi_msg_read_remap_=
rte(=0A-    struct msi_desc *msi_desc, struct msi_msg *msg)=0A-{=0A-    /* =
TODO. */=0A-}=0A-=0A-void msi_msg_write_remap_rte(=0A-    struct msi_desc =
*msi_desc, struct msi_msg *msg)=0A-{=0A-    /* TODO. */=0A-}=0A #endif=0A =
=0A int enable_intremap(struct iommu *iommu, int eim)=0A@@ -838,8 +801,6 =
@@ out:=0A     spin_unlock_irqrestore(&iommu->register_lock, flags);=0A =
}=0A =0A-#ifndef __ia64__=0A-=0A /*=0A  * This function is used to enable =
Interrupt remapping when=0A  * enable x2apic=0A@@ -914,5 +875,3 @@ void =
iommu_disable_x2apic_IR(void)=0A     for_each_drhd_unit ( drhd )=0A        =
 disable_qinval(drhd->iommu);=0A }=0A-=0A-#endif /* !__ia64__ */=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -33,7 +33,7 @@=0A #include <xen/keyhandler.h>=0A #include =
<asm/msi.h>=0A #include <asm/irq.h>=0A-#ifndef __ia64__=0A+#if defined(__i3=
86__) || defined(__x86_64__)=0A #include <asm/hvm/vmx/vmx.h>=0A #include =
<asm/p2m.h>=0A #include <mach_apic.h>=0A@@ -44,10 +44,6 @@=0A #include =
"vtd.h"=0A #include "../ats.h"=0A =0A-#ifdef __ia64__=0A-#define nr_ioapics=
              iosapic_get_nr_iosapics()=0A-#endif=0A-=0A /* Possible =
unfiltered LAPIC/MSI messages from untrusted sources? */=0A bool_t =
__read_mostly untrusted_msi;=0A =0A@@ -1057,11 +1053,7 @@ static unsigned =
int dma_msi_startup(stru=0A     return 0;=0A }=0A =0A-#ifndef __ia64__=0A =
static void dma_msi_end(struct irq_desc *desc, u8 vector)=0A-#else=0A-stati=
c void dma_msi_end(struct irq_desc *desc)=0A-#endif=0A {=0A     dma_msi_unm=
ask(desc);=0A     ack_APIC_irq();=0A@@ -1841,7 +1833,6 @@ void iommu_pte_fl=
ush(struct domain *d, u=0A =0A static int vtd_ept_page_compatible(struct =
iommu *iommu)=0A {=0A-#ifndef __ia64__=0A     u64 ept_cap, vtd_cap =3D =
iommu->cap;=0A =0A     /* EPT is not initialised yet, so we must check the =
capability in=0A@@ -1851,9 +1842,6 @@ static int vtd_ept_page_compatible(st=
ruc=0A =0A     return ( ept_has_2mb(ept_cap) =3D=3D cap_sps_2mb(vtd_cap) =
=0A              && ept_has_1gb(ept_cap) =3D=3D cap_sps_1gb(vtd_cap) =
);=0A-#else=0A-    return 0;=0A-#endif=0A }=0A =0A /*=0A@@ -1861,7 +1849,6 =
@@ static int vtd_ept_page_compatible(struc=0A  */=0A void iommu_set_pgd(st=
ruct domain *d)=0A {=0A-#ifndef __ia64__=0A     struct hvm_iommu *hd  =3D =
domain_hvm_iommu(d);=0A     mfn_t pgd_mfn;=0A =0A@@ -1872,7 +1859,6 @@ =
void iommu_set_pgd(struct domain *d)=0A =0A     pgd_mfn =3D pagetable_get_m=
fn(p2m_get_pagetable(p2m_get_hostp2m(d)));=0A     hd->pgd_maddr =3D =
pagetable_get_paddr(pagetable_from_mfn(pgd_mfn));=0A-#endif=0A }=0A =0A =
static int rmrr_identity_mapping(struct domain *d,=0A--- a/xen/drivers/pass=
through/vtd/utils.c=0A+++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ =
-301,8 +301,7 @@ static void dump_iommu_info(unsigned cha=0A         }=0A  =
   }=0A #else=0A-    printk("%s: not implemnted on IA64 for now.\n", =
__func__);=0A-    /* ia64: TODO */=0A+    printk("%s: not implemented for =
now\n", __func__);=0A #endif=0A }=0A =0A--- a/xen/drivers/passthrough/vtd/v=
td.h=0A+++ b/xen/drivers/passthrough/vtd/vtd.h=0A@@ -26,44 +26,8 @@=0A =
#define MAP_ME_PHANTOM_FUNC      1=0A #define UNMAP_ME_PHANTOM_FUNC    =
0=0A =0A-/* Accomodate both IOAPIC and IOSAPIC. */=0A-#ifndef __ia64__=0A+/=
* Allow for both IOAPIC and IOSAPIC. */=0A #define IO_xAPIC_route_entry =
IO_APIC_route_entry=0A-#else=0A-struct IO_xAPIC_route_entry {=0A-    __u32 =
  vector      :  8,=0A-        delivery_mode   :  3,   /* 000: FIXED=0A-   =
                              * 001: lowest prio=0A-                       =
          * 111: ExtINT=0A-                                 */=0A-        =
dest_mode       :  1,   /* 0: physical, 1: logical */=0A-        delivery_s=
tatus :  1,=0A-        polarity        :  1,=0A-        irr             :  =
1,=0A-        trigger         :  1,   /* 0: edge, 1: level */=0A-        =
mask            :  1,   /* 0: enabled, 1: disabled */=0A-        __reserved=
_2    : 15;=0A-=0A-    union {=0A-        struct { __u32=0A-            =
__reserved_1    : 24,=0A-            physical_dest   :  4,=0A-            =
__reserved_2    :  4;=0A-        } physical;=0A-=0A-        struct { =
__u32=0A-            __reserved_1    : 24,=0A-            logical_dest    =
:  8;=0A-        } logical;=0A-=0A-        struct { __u32=0A-            =
__reserved_1    : 16,=0A-            dest_id         : 16;=0A-        =
};=0A-    } dest;=0A-=0A-} __attribute__ ((packed));=0A-#endif=0A =0A =
struct IO_APIC_route_remap_entry {=0A     union {=0A--- a/xen/include/Makef=
ile=0A+++ b/xen/include/Makefile=0A@@ -38,7 +38,7 @@ suffix-$(CONFIG_X86)  =
    :=3D \#pragma pa=0A endif=0A =0A public-$(CONFIG_X86) :=3D $(wildcard =
public/arch-x86/*.h public/arch-x86/*/*.h)=0A-public-$(CONFIG_IA64) :=3D =
$(wildcard public/arch-ia64/*.h public/arch-ia64/*/*.h)=0A+public-$(CONFIG_=
ARM) :=3D $(wildcard public/arch-arm/*.h public/arch-arm/*/*.h)=0A =0A =
.PHONY: all=0A all: $(headers-y)=0A@@ -74,8 +74,6 @@ compat/xlat.h: =
xlat.lst $(filter-out com=0A 	mv -f $@.new $@=0A =0A ifeq ($(XEN_TARGET_A=
RCH),$(XEN_COMPILE_ARCH))=0A-# public/arch-ia64.h explicitly bails on =
__STRICT_ANSI__=0A-ifeq ($(CONFIG_IA64),)=0A =0A all: headers.chk=0A =0A@@ =
-84,7 +82,6 @@ headers.chk: $(filter-out public/arch-% =0A 	mv $@.new =
$@=0A =0A endif=0A-endif=0A =0A clean::=0A 	rm -rf compat headers.chk=
=0A--- a/xen/include/asm-x86/hvm/irq.h=0A+++ b/xen/include/asm-x86/hvm/irq.=
h=0A@@ -104,11 +104,4 @@ struct hvm_intack hvm_vcpu_has_pending_i=0A =
struct hvm_intack hvm_vcpu_ack_pending_irq(struct vcpu *v,=0A              =
                              struct hvm_intack intack);=0A =0A-/*=0A- * =
Currently IA64 Xen doesn't support MSI. So for x86, we define this =
macro=0A- * to control the conditional compilation of some MSI-related =
functions.=0A- * This macro will be removed once IA64 has MSI support.=0A- =
*/=0A-#define SUPPORT_MSI_REMAPPING 1=0A-=0A #endif /* __ASM_X86_HVM_IRQ_H_=
_ */=0A--- a/xen/include/asm-x86/hvm/vioapic.h=0A+++ b/xen/include/asm-x86/=
hvm/vioapic.h=0A@@ -41,7 +41,7 @@=0A /* Direct registers. */=0A #define =
VIOAPIC_REG_SELECT  0x00=0A #define VIOAPIC_REG_WINDOW  0x10=0A-#define =
VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */=0A+#define VIOAPIC_REG_EOI=
     0x40=0A =0A /* Indirect registers. */=0A #define VIOAPIC_REG_APIC_ID =
0x00 /* x86 IOAPIC only */=0A--- a/xen/include/xen/cpumask.h=0A+++ =
b/xen/include/xen/cpumask.h=0A@@ -82,7 +82,7 @@ typedef struct cpumask{ =
DECLARE_BITMAP(b=0A =0A extern unsigned int nr_cpu_ids;=0A =0A-#if NR_CPUS =
> 4 * BITS_PER_LONG && !defined(__ia64__)=0A+#if NR_CPUS > 4 * BITS_PER_LON=
G=0A /* Assuming NR_CPUS is huge, a runtime limit is more efficient.  =
Also,=0A  * not all bits may be allocated. */=0A extern unsigned int =
nr_cpumask_bits;=0A@@ -263,37 +263,6 @@ static inline const cpumask_t =
*cpumask_o=0A 	return (const cpumask_t *)(p - cpu / BITS_PER_LONG);=0A =
}=0A =0A-#if defined(__ia64__) /* XXX needs cleanup */=0A-#define =
CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)=0A-=0A-#if NR_CPUS <=3D =
BITS_PER_LONG=0A-=0A-#define CPU_MASK_ALL					=
		\=0A-/*(cpumask_t)*/ { {					=
		\=0A-	[BITS_TO_LONGS(NR_CPUS)-1] =3D CPU_MASK_LAST_WORD	=
		\=0A-} }=0A-=0A-#else=0A-=0A-#define CPU_MASK_ALL		=
					\=0A-/*(cpumask_t)*/ { {		=
					\=0A-	[0 ... BITS_TO_LONGS(NR_CPU=
S)-2] =3D ~0UL,			\=0A-	[BITS_TO_LONGS(NR_CPUS)-1] =3D =
CPU_MASK_LAST_WORD			\=0A-} }=0A-=0A-#endif=0A-=0A-#defi=
ne CPU_MASK_NONE							=
\=0A-/*(cpumask_t)*/ { {							=
\=0A-	0UL								=
\=0A-} }=0A-=0A-#define CPU_MASK_CPU0						=
	\=0A-/*(cpumask_t)*/ { {						=
	\=0A-	[0] =3D  1UL							=
\=0A-} }=0A-#endif /* __ia64__ */=0A-=0A #define cpumask_bits(maskp) =
((maskp)->bits)=0A =0A static inline int cpumask_scnprintf(char *buf, int =
len,=0A--- a/xen/include/xen/efi.h=0A+++ b/xen/include/xen/efi.h=0A@@ =
-5,15 +5,11 @@=0A #include <xen/types.h>=0A #endif=0A =0A-#if defined(__ia6=
4__)=0A-# include_next <linux/efi.h>=0A+#if defined(__i386__)=0A+# define =
efi_enabled 0=0A #else=0A-=0A-# if defined(__i386__)=0A-#  define =
efi_enabled 0=0A-# else=0A extern const bool_t efi_enabled;=0A-# endif=0A+#=
endif=0A =0A #define EFI_INVALID_TABLE_ADDR (~0UL)=0A =0A@@ -27,8 +23,6 @@ =
struct efi {=0A =0A extern struct efi efi;=0A =0A-#endif=0A-=0A #ifndef =
__ASSEMBLY__=0A =0A union xenpf_efi_info;=0A--- a/xen/include/xen/elfcore.h=
=0A+++ b/xen/include/xen/elfcore.h=0A@@ -69,9 +69,6 @@ typedef struct {=0A =
    unsigned long xen_phys_start;=0A     unsigned long dom0_pfn_to_mfn_fram=
e_list_list;=0A #endif=0A-#if defined(__ia64__)=0A-    unsigned long =
dom0_mm_pgd_mfn;=0A-#endif=0A } crash_xen_info_t;=0A =0A #endif /* =
__ELFCOREC_H__ */=0A--- a/xen/include/xen/hvm/irq.h=0A+++ b/xen/include/xen=
/hvm/irq.h=0A@@ -78,8 +78,6 @@ struct hvm_girq_dpci_mapping {=0A #define =
NR_LINK     4=0A #if defined(__i386__) || defined(__x86_64__)=0A # define =
NR_HVM_IRQS VIOAPIC_NUM_PINS=0A-#elif defined(__ia64__)=0A-# define =
NR_HVM_IRQS VIOSAPIC_NUM_PINS=0A #endif=0A =0A /* Protected by domain's =
event_lock */=0A--- a/xen/include/xen/iommu.h=0A+++ b/xen/include/xen/iommu=
.h=0A@@ -35,11 +35,7 @@ extern bool_t iommu_debug;=0A extern bool_t =
amd_iommu_perdev_intremap;=0A =0A /* Does this domain have a P2M table we =
can use as its IOMMU pagetable? */=0A-#ifndef __ia64__=0A #define =
iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)=0A-#else=0A-#def=
ine iommu_use_hap_pt(d) 0=0A-#endif=0A =0A extern struct rangeset =
*mmio_ro_ranges;=0A =0A--- a/xen/include/xen/irq.h=0A+++ b/xen/include/xen/=
irq.h=0A@@ -95,37 +95,19 @@ int arch_init_one_irq_desc(struct irq_de=0A =
=0A #define irq_desc_initialized(desc) ((desc)->handler !=3D NULL)=0A =
=0A-#if defined(__ia64__)=0A-extern irq_desc_t irq_desc[NR_VECTORS];=0A-=0A=
-#define setup_irq(irq, action) \=0A-    setup_irq_vector(irq_to_vector(irq=
), action)=0A-=0A-#define release_irq(irq) \=0A-    release_irq_vector(irq_=
to_vector(irq))=0A-=0A-#define request_irq(irq, handler, irqflags, =
devname, devid) \=0A-    request_irq_vector(irq_to_vector(irq), handler, =
irqflags, devname, devid)=0A-=0A-#elif defined(__arm__)=0A+#if defined(__ar=
m__)=0A =0A #define NR_IRQS		1024=0A #define nr_irqs NR_IRQS=0A =
extern irq_desc_t irq_desc[NR_IRQS];=0A =0A-extern int setup_irq(unsigned =
int irq, struct irqaction *);=0A-extern void release_irq(unsigned int =
irq);=0A-extern int request_irq(unsigned int irq,=0A-               void =
(*handler)(int, void *, struct cpu_user_regs *),=0A-               =
unsigned long irqflags, const char * devname, void *dev_id);=0A+#endif=0A =
=0A-#else=0A extern int setup_irq(unsigned int irq, struct irqaction =
*);=0A extern void release_irq(unsigned int irq);=0A extern int request_irq=
(unsigned int irq,=0A                void (*handler)(int, void *, struct =
cpu_user_regs *),=0A                unsigned long irqflags, const char * =
devname, void *dev_id);=0A-#endif=0A =0A extern hw_irq_controller =
no_irq_type;=0A extern void no_action(int cpl, void *dev_id, struct =
cpu_user_regs *regs);=0A--- a/xen/include/xen/libelf.h=0A+++ b/xen/include/=
xen/libelf.h=0A@@ -23,7 +23,7 @@=0A #ifndef __XEN_LIBELF_H__=0A #define =
__XEN_LIBELF_H__=0A =0A-#if defined(__i386__) || defined(__x86_64__) || =
defined(__ia64__) || defined(__arm__)=0A+#if defined(__i386__) || =
defined(__x86_64__) || defined(__arm__)=0A #define XEN_ELF_LITTLE_ENDIAN=0A=
 #else=0A #error define architectural endianness=0A--- a/xen/include/xen/sy=
mbols.h=0A+++ b/xen/include/xen/symbols.h=0A@@ -21,13 +21,9 @@ static void =
__check_printsym_format(cons=0A {=0A }=0A =0A-/* ia64 and ppc64 use =
function descriptors, which contain the real address */=0A-#if defined(CONF=
IG_IA64) || defined(CONFIG_PPC64)=0A-#define print_fn_descriptor_symbol(fmt=
, addr)		\=0A-do {						=
\=0A-	unsigned long *__faddr =3D (unsigned long*) addr;		=
\=0A-	print_symbol(fmt, __faddr[0]);		\=0A-} while (0)=0A+#if =
0=0A+#define print_fn_descriptor_symbol(fmt, addr)	\=0A+	print_symbo=
l(fmt, *(unsigned long *)addr)=0A #else=0A #define print_fn_descriptor_symb=
ol(fmt, addr) print_symbol(fmt, addr)=0A #endif=0A
--=__PartB6988E59.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB6988E59.3__=--


From xen-devel-bounces@lists.xen.org Tue Apr 03 08:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEz1F-0002to-QF; Tue, 03 Apr 2012 08:23:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEz1D-0002tb-NB
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:23:11 +0000
Received: from [85.158.139.83:32112] by server-7.bemta-5.messagelabs.com id
	0D/37-16195-E63BA7F4; Tue, 03 Apr 2012 08:23:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333441389!22213461!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26354 invoked from network); 3 Apr 2012 08:23:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:23:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11737889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 08:23:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:23:06 +0100
Message-ID: <1333441383.25602.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 09:23:03 +0100
In-Reply-To: <20120402195425.GA21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 20:54 +0100, Olaf Hering wrote:
> On Mon, Apr 02, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > > node-select.c: In function 'vchan_wr':
> > > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> > 
> > This one is a question of coding style.  Apparently libvchan uses
> > mixed statements/declarations, so this should be fixed by changing the
> > warning flags.
> 
> This is from xen itself:
> 
> .. -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement ..
> 
> Are you saying -Wdeclaration-after-statement should be removed?

No, if appropriate to do so then it should be removed from
tools/libvchan like we do in tools/libxl.

However skimming over node-select.c and io.c (as another random file) it
looks like the use of mixed declarations and code is the exception not
the rule even within libvchan, so I think it would be fine to fix the
two places where this isn't the case.

Ian.

> 
> diff -r 7c29b8723556 Config.mk
> --- a/Config.mk
> +++ b/Config.mk
> @@ -161,7 +161,7 @@ CFLAGS += -Wall -Wstrict-prototypes
>  # and is over-zealous with the printf format lint
>  CFLAGS-$(clang) += -Wno-parentheses -Wno-format
>  
> -$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
> +$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wno-declaration-after-statement)
>  $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
>  $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEz1F-0002to-QF; Tue, 03 Apr 2012 08:23:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEz1D-0002tb-NB
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:23:11 +0000
Received: from [85.158.139.83:32112] by server-7.bemta-5.messagelabs.com id
	0D/37-16195-E63BA7F4; Tue, 03 Apr 2012 08:23:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333441389!22213461!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26354 invoked from network); 3 Apr 2012 08:23:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:23:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11737889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 08:23:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:23:06 +0100
Message-ID: <1333441383.25602.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 09:23:03 +0100
In-Reply-To: <20120402195425.GA21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 20:54 +0100, Olaf Hering wrote:
> On Mon, Apr 02, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > > node-select.c: In function 'vchan_wr':
> > > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> > 
> > This one is a question of coding style.  Apparently libvchan uses
> > mixed statements/declarations, so this should be fixed by changing the
> > warning flags.
> 
> This is from xen itself:
> 
> .. -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement ..
> 
> Are you saying -Wdeclaration-after-statement should be removed?

No, if appropriate to do so then it should be removed from
tools/libvchan like we do in tools/libxl.

However skimming over node-select.c and io.c (as another random file) it
looks like the use of mixed declarations and code is the exception not
the rule even within libvchan, so I think it would be fine to fix the
two places where this isn't the case.

Ian.

> 
> diff -r 7c29b8723556 Config.mk
> --- a/Config.mk
> +++ b/Config.mk
> @@ -161,7 +161,7 @@ CFLAGS += -Wall -Wstrict-prototypes
>  # and is over-zealous with the printf format lint
>  CFLAGS-$(clang) += -Wno-parentheses -Wno-format
>  
> -$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
> +$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wno-declaration-after-statement)
>  $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
>  $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEz8T-00035G-0D; Tue, 03 Apr 2012 08:30:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEz8R-00035B-9O
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:30:39 +0000
Received: from [85.158.143.99:14719] by server-1.bemta-4.messagelabs.com id
	C9/3F-20925-E25BA7F4; Tue, 03 Apr 2012 08:30:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333441837!16829549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26348 invoked from network); 3 Apr 2012 08:30:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:30:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11738090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 08:30:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:30:37 +0100
Message-ID: <1333441832.25602.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 09:30:32 +0100
In-Reply-To: <20120402195816.GB21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 20:58 +0100, Olaf Hering wrote:
> On Mon, Apr 02, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> > > tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback
> > > 
> > > -O2 -Wall -Werror triggers these warnings:
> > > 
> > > libxl.c: In function 'disk_eject_xswatch_callback':
> > > libxl.c:928: warning: zero-length printf format string
> > 
> > There is nothing wrong with zero-length format strings.  This warning
> > should be disabled.  Please do send a patch to do so.
> 
> -Wno-format-zero-length -Wall has no effect, and -Wall comes from
> RPM_OPT_FLAGS which will come last with my current EXTRA_CFLAGS patch.

IMHO it's a little bit unreasonable for RPM to think it knows better
than upstream what warning flags are appropriate. Especially given not
all the warnings are useful and/or make sense (which is certainly the
case for Wformat-zero-length[0]).

I'd suggest that RPM_OPT_FLAGS either ought to omit
Wno-format-zero-length or, if it is a member of some umbrella -W option,
grow a -Wno-format-zero-length. Or if you cannot control RPM_OPT_FLAGS
in that way you should pass it alongside RPM_OPT_FLAGS in via
EXTRA_CFLAGS.

[0] Even gcc(1) says:
       -Wno-format-zero-length (C and Objective-C only)
           If -Wformat is specified, do not warn about zero-length formats.
           The C standard specifies that zero-length formats are allowed.
So quite why it appears that Wall is enabling Wformat-zero-length I have
no idea, this is a clear gcc bug in my opinion.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEz8T-00035G-0D; Tue, 03 Apr 2012 08:30:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEz8R-00035B-9O
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:30:39 +0000
Received: from [85.158.143.99:14719] by server-1.bemta-4.messagelabs.com id
	C9/3F-20925-E25BA7F4; Tue, 03 Apr 2012 08:30:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333441837!16829549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26348 invoked from network); 3 Apr 2012 08:30:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:30:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11738090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 08:30:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:30:37 +0100
Message-ID: <1333441832.25602.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 09:30:32 +0100
In-Reply-To: <20120402195816.GB21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 20:58 +0100, Olaf Hering wrote:
> On Mon, Apr 02, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> > > tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback
> > > 
> > > -O2 -Wall -Werror triggers these warnings:
> > > 
> > > libxl.c: In function 'disk_eject_xswatch_callback':
> > > libxl.c:928: warning: zero-length printf format string
> > 
> > There is nothing wrong with zero-length format strings.  This warning
> > should be disabled.  Please do send a patch to do so.
> 
> -Wno-format-zero-length -Wall has no effect, and -Wall comes from
> RPM_OPT_FLAGS which will come last with my current EXTRA_CFLAGS patch.

IMHO it's a little bit unreasonable for RPM to think it knows better
than upstream what warning flags are appropriate. Especially given not
all the warnings are useful and/or make sense (which is certainly the
case for Wformat-zero-length[0]).

I'd suggest that RPM_OPT_FLAGS either ought to omit
Wno-format-zero-length or, if it is a member of some umbrella -W option,
grow a -Wno-format-zero-length. Or if you cannot control RPM_OPT_FLAGS
in that way you should pass it alongside RPM_OPT_FLAGS in via
EXTRA_CFLAGS.

[0] Even gcc(1) says:
       -Wno-format-zero-length (C and Objective-C only)
           If -Wformat is specified, do not warn about zero-length formats.
           The C standard specifies that zero-length formats are allowed.
So quite why it appears that Wall is enabling Wformat-zero-length I have
no idea, this is a clear gcc bug in my opinion.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzQ1-0003GX-MB; Tue, 03 Apr 2012 08:48:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEzQ0-0003GR-Al
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:48:48 +0000
Received: from [85.158.138.51:21579] by server-12.bemta-3.messagelabs.com id
	F0/CD-30663-F69BA7F4; Tue, 03 Apr 2012 08:48:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333442925!20569814!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA4MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2879 invoked from network); 3 Apr 2012 08:48:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="188773170"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 04:48:45 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	04:48:44 -0400
Message-ID: <4F7AB96B.5030900@citrix.com>
Date: Tue, 3 Apr 2012 09:48:43 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 5/7] xen/setup: Transfer MFNs from non-RAM
 E820	entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> We will now get:
> 
> -Released 283999 pages of unused memory
> +Exchanged 283999 pages
> .. snip..
> -Memory: 6487732k/9208688k available (5817k kernel code, 1136060k absent, 1584896k reserved, 2900k data, 692k init)
> +Memory: 6503888k/8072692k available (5817k kernel code, 1136060k absent, 432744k reserved, 2900k data, 692k init)

This isn't correct.  You've have lost ~1 GB of memory which are the
pages that were supposed to be moved.  The additional 1GB of reserved
memory in the old case is the balloon.

In xen_memory_setup() where it loops through the e820 to clip the RAM
regions you need to factor in the additional memory you've moved.  In
this loop you may need to count the pages in the RAM region instead of
the simple (addr < mem_end) test.  Take care with RAM regions with
partial pages and the like.

> which is more in line with classic XenOLinux.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   85 ++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 files changed, 82 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 1ba8dff..2a12143 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -120,12 +120,89 @@ static unsigned long __init xen_release_chunk(unsigned long start,
>  	return len;
>  }
>  
> +static unsigned long __init xen_exchange_chunk(unsigned long start_pfn,
> +	unsigned long end_pfn, unsigned long nr_pages, unsigned long exchanged,
> +	unsigned long *pages_left, const struct e820entry *list,
> +	size_t map_size)
> +{
[...]
> +
> +		for (pfn = start_pfn; pfn < start_pfn + nr; pfn++) {
> +			unsigned long mfn = pfn_to_mfn(pfn);
> +
> +			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
> +				break;
> +
> +			if (!early_set_phys_to_machine(dest_pfn, mfn))
> +				break;
> +
> +			/* You would think we should do HYPERVISOR_update_va_mapping
> +			 * but we don't need to as the hypervisor only sets up the
> +			 * initial pagetables up to nr_pages, and we stick the MFNs
> +			 * past that.
> +			 */

Hmmm. Are you sure this is safe?  What happens if Linux tries to use
these pages before creating new page tables?  e.g., via some early boot
allocator before the final page tables are setup? (This might not be a
problem, I haven't checked).

You've may have gotten away with it for now because the moved MFNs are
marked as unusable.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzQ1-0003GX-MB; Tue, 03 Apr 2012 08:48:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEzQ0-0003GR-Al
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:48:48 +0000
Received: from [85.158.138.51:21579] by server-12.bemta-3.messagelabs.com id
	F0/CD-30663-F69BA7F4; Tue, 03 Apr 2012 08:48:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333442925!20569814!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA4MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2879 invoked from network); 3 Apr 2012 08:48:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="188773170"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 04:48:45 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	04:48:44 -0400
Message-ID: <4F7AB96B.5030900@citrix.com>
Date: Tue, 3 Apr 2012 09:48:43 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 5/7] xen/setup: Transfer MFNs from non-RAM
 E820	entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> We will now get:
> 
> -Released 283999 pages of unused memory
> +Exchanged 283999 pages
> .. snip..
> -Memory: 6487732k/9208688k available (5817k kernel code, 1136060k absent, 1584896k reserved, 2900k data, 692k init)
> +Memory: 6503888k/8072692k available (5817k kernel code, 1136060k absent, 432744k reserved, 2900k data, 692k init)

This isn't correct.  You've have lost ~1 GB of memory which are the
pages that were supposed to be moved.  The additional 1GB of reserved
memory in the old case is the balloon.

In xen_memory_setup() where it loops through the e820 to clip the RAM
regions you need to factor in the additional memory you've moved.  In
this loop you may need to count the pages in the RAM region instead of
the simple (addr < mem_end) test.  Take care with RAM regions with
partial pages and the like.

> which is more in line with classic XenOLinux.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   85 ++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 files changed, 82 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 1ba8dff..2a12143 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -120,12 +120,89 @@ static unsigned long __init xen_release_chunk(unsigned long start,
>  	return len;
>  }
>  
> +static unsigned long __init xen_exchange_chunk(unsigned long start_pfn,
> +	unsigned long end_pfn, unsigned long nr_pages, unsigned long exchanged,
> +	unsigned long *pages_left, const struct e820entry *list,
> +	size_t map_size)
> +{
[...]
> +
> +		for (pfn = start_pfn; pfn < start_pfn + nr; pfn++) {
> +			unsigned long mfn = pfn_to_mfn(pfn);
> +
> +			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
> +				break;
> +
> +			if (!early_set_phys_to_machine(dest_pfn, mfn))
> +				break;
> +
> +			/* You would think we should do HYPERVISOR_update_va_mapping
> +			 * but we don't need to as the hypervisor only sets up the
> +			 * initial pagetables up to nr_pages, and we stick the MFNs
> +			 * past that.
> +			 */

Hmmm. Are you sure this is safe?  What happens if Linux tries to use
these pages before creating new page tables?  e.g., via some early boot
allocator before the final page tables are setup? (This might not be a
problem, I haven't checked).

You've may have gotten away with it for now because the moved MFNs are
marked as unusable.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:57:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzY5-0003Q1-Ju; Tue, 03 Apr 2012 08:57:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SEzY4-0003Ps-1a
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 08:57:08 +0000
Received: from [85.158.143.35:57683] by server-2.bemta-4.messagelabs.com id
	31/CD-17550-36BBA7F4; Tue, 03 Apr 2012 08:57:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333443425!10969729!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 3 Apr 2012 08:57:05 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:57:05 -0000
Received: by bkcjg9 with SMTP id jg9so3608684bkc.32
	for <multiple recipients>; Tue, 03 Apr 2012 01:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cdlZd1+K4TYko/9mZCFweO5sx5LN3JDAc2ochAiisbc=;
	b=AGipzD+0fCfok9y+3SoEPYyV8zaBy0bk+pWnJcaSdzfcIpcvWj3cY7kd1EDdlq70Ki
	+9oATtzwjicNkxybYSTXHfktXZzAetfAyB+MLRf16JD/gKSUwj4CQljYr3vkUOAQwh2J
	HSLEIGl5xbXHGVxDe/rchlhNskrpu6XrA8JDqdcmzYCH4wC5DveVhdnWneuD5g2Usane
	lfAWzoBt1ABH9CaLz23QbLl7EHT7qn7F+uKweR5Gh/ZGN583jKToaUBQ8OP8MiOI2LZ+
	JKL8T2PxoeUkf/zutXFNfl0eb0ZeFxW0gjWTdaGb8gbSN6qnQd8rMYWiITdttwzrAiKX
	m0Vg==
Received: by 10.204.148.89 with SMTP id o25mr5054833bkv.52.1333443424662;
	Tue, 03 Apr 2012 01:57:04 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id s16sm44126825bkt.3.2012.04.03.01.57.02
	(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 01:57:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 03 Apr 2012 09:57:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CBA079EC.2FF6B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] removal of ia64 port
Thread-Index: Ac0Rd7sEAerbOKTnYk26Nw/IemUboA==
In-Reply-To: <4F7ACE69020000780007C3E0@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, Ian.Campbell@citrix.com,
	xen-ia64-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/04/2012 09:18, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 02.04.12 at 17:33, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 02/04/2012 16:16, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> now that we apparently having reached consensus here, are you
>>> going to purge the ia64 bits from the tree, or do you want me to?
>> 
>> Please go ahead.
> 
> This is the patch I'm intending to commit (omitting all the ia64 files
> that are going to be removed).
> 
> It retains IA64-specific bits in code imported from elsewhere (e.g.
> ACPI, EFI) as well as in the public headers.
> 
> It also doesn't touch the tools, mini-os, and unmodified_drivers
> sub-trees.

Acked-by: Keir Fraser <keir@xen.org>

> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -138,14 +138,6 @@ M: Tim Deegan <tim@xen.org>
>  S: Supported
>  F: tools/debugger/kdd/
>  
> -IA64 ARCHITECTURE
> -M: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
> -S: Supported
> -L: xen-ia64-devel@lists.xensource.com
> -F: xen/arch/ia64/*
> -F: xen/include/asm-ia64/*
> -F: tools/libxc/ia64/*
> -
>  INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>  M: Joseph Cihula <joseph.cihula@intel.com>
>  M: Gang Wei <gang.wei@intel.com>
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -58,7 +58,6 @@ subdir-$(CONFIG_COMPAT) += compat
>  
>  subdir-$(x86_32) += hvm
>  subdir-$(x86_64) += hvm
> -subdir-$(ia64) += hvm
>  
>  subdir-y += libelf
>  subdir-$(HAS_DEVICE_TREE) += libfdt
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1514,9 +1514,7 @@ gnttab_transfer(
>              goto copyback;
>          }
>  
> -#ifndef __ia64__ /* IA64 implicitly replaces the old page in steal_page(). */
>          guest_physmap_remove_page(d, gop.mfn, mfn, 0);
> -#endif
>          flush_tlb_mask(d->domain_dirty_cpumask);
>  
>          /* Find the target domain. */
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -721,11 +721,7 @@ static void crash_save_vmcoreinfo(void)
>      VMCOREINFO_STRUCT_SIZE(domain);
>  
>      VMCOREINFO_OFFSET(page_info, count_info);
> -#ifdef __ia64__
> -    VMCOREINFO_OFFSET_SUB(page_info, u.inuse, _domain);
> -#else
>      VMCOREINFO_OFFSET_SUB(page_info, v.inuse, _domain);
> -#endif
>      VMCOREINFO_OFFSET(domain, domain_id);
>      VMCOREINFO_OFFSET(domain, next_in_list);
>  
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -23,9 +23,7 @@
>  #include <xen/tmem_xen.h>
>  #include <asm/current.h>
>  #include <asm/hardirq.h>
> -#ifndef __ia64__
>  #include <asm/p2m.h>
> -#endif
>  #include <xen/numa.h>
>  #include <public/memory.h>
>  #include <xsm/xsm.h>
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1141,7 +1141,7 @@ void __init scrub_heap_pages(void)
>   * XEN-HEAP SUB-ALLOCATOR
>   */
>  
> -#if !defined(__x86_64__) && !defined(__ia64__)
> +#if !defined(__x86_64__)
>  
>  void init_xenheap_pages(paddr_t ps, paddr_t pe)
>  {
> --- a/xen/common/tmem_xen.c
> +++ b/xen/common/tmem_xen.c
> @@ -88,7 +88,7 @@ void tmh_copy_page(char *to, char*from)
>  #endif
>  }
>  
> -#if defined(__ia64__) || defined (CONFIG_ARM)
> +#if defined(CONFIG_ARM)
>  static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long
> *pcli_mfn,
>                                   pfp_t **pcli_pfp, bool_t cli_write)
>  {
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -442,16 +442,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
>              goto out;
>          }
>  
> -#ifdef CONFIG_IA64
> -        /* for IA64, currently it only supports FFH */
> -        if (dom0_px_info->control_register.space_id !=
> -            ACPI_ADR_SPACE_FIXED_HARDWARE)
> -        {
> -            ret = -EINVAL;
> -            goto out;
> -        }
> -#endif
> -
>          memcpy ((void *)&pxpt->control_register,
>                  (void *)&dom0_px_info->control_register,
>                  sizeof(struct xen_pct_register));
> @@ -493,7 +483,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
>      {
>  #ifdef CONFIG_X86
>          /* for X86, check domain coordination */
> -        /* for IA64, _PSD is optional for current IA64 cpufreq algorithm */
>          if (dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
>              dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ANY &&
>              dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_HW)
> --- a/xen/drivers/passthrough/Makefile
> +++ b/xen/drivers/passthrough/Makefile
> @@ -1,5 +1,4 @@
>  subdir-$(x86) += vtd
> -subdir-$(ia64) += vtd
>  subdir-$(x86) += amd
>  subdir-$(x86_64) += x86
>  
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -419,7 +419,6 @@ int hvm_do_IRQ_dpci(struct domain *d, st
>      return 1;
>  }
>  
> -#ifdef SUPPORT_MSI_REMAPPING
>  /* called with d->event_lock held */
>  static void __msi_pirq_eoi(struct hvm_pirq_dpci *pirq_dpci)
>  {
> @@ -479,7 +478,6 @@ static int hvm_pci_msi_assert(struct dom
>              ? send_guest_pirq(d, pirq)
>              : vmsi_deliver_pirq(d, pirq_dpci));
>  }
> -#endif
>  
>  static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci
> *pirq_dpci,
>                              void *arg)
> @@ -489,13 +487,12 @@ static int _hvm_dirq_assist(struct domai
>  
>      if ( test_and_clear_bool(pirq_dpci->masked) )
>      {
> -#ifdef SUPPORT_MSI_REMAPPING
>          if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
>          {
>              hvm_pci_msi_assert(d, pirq_dpci);
>              return 0;
>          }
> -#endif
> +
>          list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
>          {
>              struct pirq *info = dpci_pirq(pirq_dpci);
> @@ -508,13 +505,11 @@ static int _hvm_dirq_assist(struct domai
>                  hvm_pci_intx_assert(d, device, intx);
>              pirq_dpci->pending++;
>  
> -#ifdef SUPPORT_MSI_REMAPPING
>              if ( pirq_dpci->flags & HVM_IRQ_DPCI_TRANSLATE )
>              {
>                  /* for translated MSI to INTx interrupt, eoi as early as
> possible */
>                  __msi_pirq_eoi(pirq_dpci);
>              }
> -#endif
>          }
>  
>          /*
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -593,17 +593,6 @@ int iommu_do_domctl(
>          bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
>          devfn = domctl->u.assign_device.machine_sbdf & 0xff;
>  
> -#ifdef __ia64__ /* XXX Is this really needed? */
> -        if ( device_assigned(seg, bus, devfn) )
> -        {
> -            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> -                   "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> -                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> -            ret = -EINVAL;
> -            goto assign_device_out;
> -        }
> -#endif
> -
>          ret = assign_device(d, seg, bus, devfn);
>          if ( ret )
>              printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> @@ -632,14 +621,6 @@ int iommu_do_domctl(
>          bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
>          devfn = domctl->u.assign_device.machine_sbdf & 0xff;
>  
> -#ifdef __ia64__ /* XXX Is this really needed? */
> -        if ( !device_assigned(seg, bus, devfn) )
> -        {
> -            ret = -EINVAL;
> -            goto deassign_device_out;
> -        }
> -#endif
> -
>          spin_lock(&pcidevs_lock);
>          ret = deassign_device(d, seg, bus, devfn);
>          spin_unlock(&pcidevs_lock);
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -696,7 +696,6 @@ void __init setup_dom0_pci_devices(
>      spin_unlock(&pcidevs_lock);
>  }
>  
> -#ifdef SUPPORT_MSI_REMAPPING
>  static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
>  {
>      struct pci_dev *pdev;
> @@ -738,8 +737,6 @@ static int __init setup_dump_pcidevs(voi
>      return 0;
>  }
>  __initcall(setup_dump_pcidevs);
> -#endif
> -
>  
>  /*
>   * Local variables:
> --- a/xen/drivers/passthrough/vtd/Makefile
> +++ b/xen/drivers/passthrough/vtd/Makefile
> @@ -1,5 +1,4 @@
>  subdir-$(x86) += x86
> -subdir-$(ia64) += ia64
>  
>  obj-y += iommu.o
>  obj-y += dmar.o
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -31,26 +31,7 @@
>  #include "vtd.h"
>  #include "extern.h"
>  
> -#ifdef __ia64__
> -#define nr_ioapics              iosapic_get_nr_iosapics()
> -#define nr_ioapic_entries(i)  iosapic_get_nr_pins(i)
> -#define __io_apic_read(apic, reg) \
> -    (*IO_APIC_BASE(apic) = reg, *(IO_APIC_BASE(apic)+4))
> -#define __io_apic_write(apic, reg, val) \
> -    (*IO_APIC_BASE(apic) = reg, *(IO_APIC_BASE(apic)+4) = (val))
> -#define __ioapic_read_entry(apic, pin, raw) ({ \
> -    struct IO_xAPIC_route_entry _e_; \
> -    ASSERT(raw); \
> -    ((u32 *)&_e_)[0] = __io_apic_read(apic, 0x10 + 2 * (pin)); \
> -    ((u32 *)&_e_)[1] = __io_apic_read(apic, 0x11 + 2 * (pin)); \
> -    _e_; \
> -})
> -#define __ioapic_write_entry(apic, pin, raw, ent) ({ \
> -    ASSERT(raw); \
> -    __io_apic_write(apic, 0x10 + 2 * (pin), ((u32 *)&(ent))[0]); \
> -    __io_apic_write(apic, 0x11 + 2 * (pin), ((u32 *)&(ent))[1]); \
> -})
> -#else
> +#if defined(__i386__) || defined(__x86_64__)
>  #include <asm/apic.h>
>  #include <asm/io_apic.h>
>  #define nr_ioapic_entries(i)  nr_ioapic_entries[i]
> @@ -326,8 +307,6 @@ static int ioapic_rte_to_remap_entry(str
>              new_ire.lo.dst = value;
>          else
>              new_ire.lo.dst = (value >> 24) << 8;
> -#else /* __ia64__ */
> -        new_ire.lo.dst = value >> 16;
>  #endif
>      }
>      else
> @@ -625,12 +604,8 @@ static int msi_msg_to_remap_entry(
>      new_ire.lo.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
>      new_ire.lo.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
>      new_ire.lo.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x1;
> -#ifdef CONFIG_X86
>      /* Hardware require RH = 1 for LPR delivery mode */
>      new_ire.lo.rh = (new_ire.lo.dlm == dest_LowestPrio);
> -#else
> -    new_ire.lo.rh = 0;
> -#endif
>      new_ire.lo.avail = 0;
>      new_ire.lo.res_1 = 0;
>      new_ire.lo.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
> @@ -703,18 +678,6 @@ void msi_msg_write_remap_rte(
>  
>      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
>  }
> -#elif defined(__ia64__)
> -void msi_msg_read_remap_rte(
> -    struct msi_desc *msi_desc, struct msi_msg *msg)
> -{
> -    /* TODO. */
> -}
> -
> -void msi_msg_write_remap_rte(
> -    struct msi_desc *msi_desc, struct msi_msg *msg)
> -{
> -    /* TODO. */
> -}
>  #endif
>  
>  int enable_intremap(struct iommu *iommu, int eim)
> @@ -838,8 +801,6 @@ out:
>      spin_unlock_irqrestore(&iommu->register_lock, flags);
>  }
>  
> -#ifndef __ia64__
> -
>  /*
>   * This function is used to enable Interrupt remapping when
>   * enable x2apic
> @@ -914,5 +875,3 @@ void iommu_disable_x2apic_IR(void)
>      for_each_drhd_unit ( drhd )
>          disable_qinval(drhd->iommu);
>  }
> -
> -#endif /* !__ia64__ */
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -33,7 +33,7 @@
>  #include <xen/keyhandler.h>
>  #include <asm/msi.h>
>  #include <asm/irq.h>
> -#ifndef __ia64__
> +#if defined(__i386__) || defined(__x86_64__)
>  #include <asm/hvm/vmx/vmx.h>
>  #include <asm/p2m.h>
>  #include <mach_apic.h>
> @@ -44,10 +44,6 @@
>  #include "vtd.h"
>  #include "../ats.h"
>  
> -#ifdef __ia64__
> -#define nr_ioapics              iosapic_get_nr_iosapics()
> -#endif
> -
>  /* Possible unfiltered LAPIC/MSI messages from untrusted sources? */
>  bool_t __read_mostly untrusted_msi;
>  
> @@ -1057,11 +1053,7 @@ static unsigned int dma_msi_startup(stru
>      return 0;
>  }
>  
> -#ifndef __ia64__
>  static void dma_msi_end(struct irq_desc *desc, u8 vector)
> -#else
> -static void dma_msi_end(struct irq_desc *desc)
> -#endif
>  {
>      dma_msi_unmask(desc);
>      ack_APIC_irq();
> @@ -1841,7 +1833,6 @@ void iommu_pte_flush(struct domain *d, u
>  
>  static int vtd_ept_page_compatible(struct iommu *iommu)
>  {
> -#ifndef __ia64__
>      u64 ept_cap, vtd_cap = iommu->cap;
>  
>      /* EPT is not initialised yet, so we must check the capability in
> @@ -1851,9 +1842,6 @@ static int vtd_ept_page_compatible(struc
>  
>      return ( ept_has_2mb(ept_cap) == cap_sps_2mb(vtd_cap)
>               && ept_has_1gb(ept_cap) == cap_sps_1gb(vtd_cap) );
> -#else
> -    return 0;
> -#endif
>  }
>  
>  /*
> @@ -1861,7 +1849,6 @@ static int vtd_ept_page_compatible(struc
>   */
>  void iommu_set_pgd(struct domain *d)
>  {
> -#ifndef __ia64__
>      struct hvm_iommu *hd  = domain_hvm_iommu(d);
>      mfn_t pgd_mfn;
>  
> @@ -1872,7 +1859,6 @@ void iommu_set_pgd(struct domain *d)
>  
>      pgd_mfn = pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
>      hd->pgd_maddr = pagetable_get_paddr(pagetable_from_mfn(pgd_mfn));
> -#endif
>  }
>  
>  static int rmrr_identity_mapping(struct domain *d,
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -301,8 +301,7 @@ static void dump_iommu_info(unsigned cha
>          }
>      }
>  #else
> -    printk("%s: not implemnted on IA64 for now.\n", __func__);
> -    /* ia64: TODO */
> +    printk("%s: not implemented for now\n", __func__);
>  #endif
>  }
>  
> --- a/xen/drivers/passthrough/vtd/vtd.h
> +++ b/xen/drivers/passthrough/vtd/vtd.h
> @@ -26,44 +26,8 @@
>  #define MAP_ME_PHANTOM_FUNC      1
>  #define UNMAP_ME_PHANTOM_FUNC    0
>  
> -/* Accomodate both IOAPIC and IOSAPIC. */
> -#ifndef __ia64__
> +/* Allow for both IOAPIC and IOSAPIC. */
>  #define IO_xAPIC_route_entry IO_APIC_route_entry
> -#else
> -struct IO_xAPIC_route_entry {
> -    __u32   vector      :  8,
> -        delivery_mode   :  3,   /* 000: FIXED
> -                                 * 001: lowest prio
> -                                 * 111: ExtINT
> -                                 */
> -        dest_mode       :  1,   /* 0: physical, 1: logical */
> -        delivery_status :  1,
> -        polarity        :  1,
> -        irr             :  1,
> -        trigger         :  1,   /* 0: edge, 1: level */
> -        mask            :  1,   /* 0: enabled, 1: disabled */
> -        __reserved_2    : 15;
> -
> -    union {
> -        struct { __u32
> -            __reserved_1    : 24,
> -            physical_dest   :  4,
> -            __reserved_2    :  4;
> -        } physical;
> -
> -        struct { __u32
> -            __reserved_1    : 24,
> -            logical_dest    :  8;
> -        } logical;
> -
> -        struct { __u32
> -            __reserved_1    : 16,
> -            dest_id         : 16;
> -        };
> -    } dest;
> -
> -} __attribute__ ((packed));
> -#endif
>  
>  struct IO_APIC_route_remap_entry {
>      union {
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -38,7 +38,7 @@ suffix-$(CONFIG_X86)      := \#pragma pa
>  endif
>  
>  public-$(CONFIG_X86) := $(wildcard public/arch-x86/*.h public/arch-x86/*/*.h)
> -public-$(CONFIG_IA64) := $(wildcard public/arch-ia64/*.h
> public/arch-ia64/*/*.h)
> +public-$(CONFIG_ARM) := $(wildcard public/arch-arm/*.h public/arch-arm/*/*.h)
>  
>  .PHONY: all
>  all: $(headers-y)
> @@ -74,8 +74,6 @@ compat/xlat.h: xlat.lst $(filter-out com
> mv -f $@.new $@
>  
>  ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
> -# public/arch-ia64.h explicitly bails on __STRICT_ANSI__
> -ifeq ($(CONFIG_IA64),)
>  
>  all: headers.chk
>  
> @@ -84,7 +82,6 @@ headers.chk: $(filter-out public/arch-%
> mv $@.new $@
>  
>  endif
> -endif
>  
>  clean::
> rm -rf compat headers.chk
> --- a/xen/include/asm-x86/hvm/irq.h
> +++ b/xen/include/asm-x86/hvm/irq.h
> @@ -104,11 +104,4 @@ struct hvm_intack hvm_vcpu_has_pending_i
>  struct hvm_intack hvm_vcpu_ack_pending_irq(struct vcpu *v,
>                                             struct hvm_intack intack);
>  
> -/*
> - * Currently IA64 Xen doesn't support MSI. So for x86, we define this macro
> - * to control the conditional compilation of some MSI-related functions.
> - * This macro will be removed once IA64 has MSI support.
> - */
> -#define SUPPORT_MSI_REMAPPING 1
> -
>  #endif /* __ASM_X86_HVM_IRQ_H__ */
> --- a/xen/include/asm-x86/hvm/vioapic.h
> +++ b/xen/include/asm-x86/hvm/vioapic.h
> @@ -41,7 +41,7 @@
>  /* Direct registers. */
>  #define VIOAPIC_REG_SELECT  0x00
>  #define VIOAPIC_REG_WINDOW  0x10
> -#define VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */
> +#define VIOAPIC_REG_EOI     0x40
>  
>  /* Indirect registers. */
>  #define VIOAPIC_REG_APIC_ID 0x00 /* x86 IOAPIC only */
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -82,7 +82,7 @@ typedef struct cpumask{ DECLARE_BITMAP(b
>  
>  extern unsigned int nr_cpu_ids;
>  
> -#if NR_CPUS > 4 * BITS_PER_LONG && !defined(__ia64__)
> +#if NR_CPUS > 4 * BITS_PER_LONG
>  /* Assuming NR_CPUS is huge, a runtime limit is more efficient.  Also,
>   * not all bits may be allocated. */
>  extern unsigned int nr_cpumask_bits;
> @@ -263,37 +263,6 @@ static inline const cpumask_t *cpumask_o
> return (const cpumask_t *)(p - cpu / BITS_PER_LONG);
>  }
>  
> -#if defined(__ia64__) /* XXX needs cleanup */
> -#define CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)
> -
> -#if NR_CPUS <= BITS_PER_LONG
> -
> -#define CPU_MASK_ALL       \
> -/*(cpumask_t)*/ { {       \
> - [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD   \
> -} }
> -
> -#else
> -
> -#define CPU_MASK_ALL       \
> -/*(cpumask_t)*/ { {       \
> - [0 ... BITS_TO_LONGS(NR_CPUS)-2] = ~0UL,   \
> - [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD   \
> -} }
> -
> -#endif
> -
> -#define CPU_MASK_NONE       \
> -/*(cpumask_t)*/ { {       \
> - 0UL        \
> -} }
> -
> -#define CPU_MASK_CPU0       \
> -/*(cpumask_t)*/ { {       \
> - [0] =  1UL       \
> -} }
> -#endif /* __ia64__ */
> -
>  #define cpumask_bits(maskp) ((maskp)->bits)
>  
>  static inline int cpumask_scnprintf(char *buf, int len,
> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -5,15 +5,11 @@
>  #include <xen/types.h>
>  #endif
>  
> -#if defined(__ia64__)
> -# include_next <linux/efi.h>
> +#if defined(__i386__)
> +# define efi_enabled 0
>  #else
> -
> -# if defined(__i386__)
> -#  define efi_enabled 0
> -# else
>  extern const bool_t efi_enabled;
> -# endif
> +#endif
>  
>  #define EFI_INVALID_TABLE_ADDR (~0UL)
>  
> @@ -27,8 +23,6 @@ struct efi {
>  
>  extern struct efi efi;
>  
> -#endif
> -
>  #ifndef __ASSEMBLY__
>  
>  union xenpf_efi_info;
> --- a/xen/include/xen/elfcore.h
> +++ b/xen/include/xen/elfcore.h
> @@ -69,9 +69,6 @@ typedef struct {
>      unsigned long xen_phys_start;
>      unsigned long dom0_pfn_to_mfn_frame_list_list;
>  #endif
> -#if defined(__ia64__)
> -    unsigned long dom0_mm_pgd_mfn;
> -#endif
>  } crash_xen_info_t;
>  
>  #endif /* __ELFCOREC_H__ */
> --- a/xen/include/xen/hvm/irq.h
> +++ b/xen/include/xen/hvm/irq.h
> @@ -78,8 +78,6 @@ struct hvm_girq_dpci_mapping {
>  #define NR_LINK     4
>  #if defined(__i386__) || defined(__x86_64__)
>  # define NR_HVM_IRQS VIOAPIC_NUM_PINS
> -#elif defined(__ia64__)
> -# define NR_HVM_IRQS VIOSAPIC_NUM_PINS
>  #endif
>  
>  /* Protected by domain's event_lock */
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -35,11 +35,7 @@ extern bool_t iommu_debug;
>  extern bool_t amd_iommu_perdev_intremap;
>  
>  /* Does this domain have a P2M table we can use as its IOMMU pagetable? */
> -#ifndef __ia64__
>  #define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
> -#else
> -#define iommu_use_hap_pt(d) 0
> -#endif
>  
>  extern struct rangeset *mmio_ro_ranges;
>  
> --- a/xen/include/xen/irq.h
> +++ b/xen/include/xen/irq.h
> @@ -95,37 +95,19 @@ int arch_init_one_irq_desc(struct irq_de
>  
>  #define irq_desc_initialized(desc) ((desc)->handler != NULL)
>  
> -#if defined(__ia64__)
> -extern irq_desc_t irq_desc[NR_VECTORS];
> -
> -#define setup_irq(irq, action) \
> -    setup_irq_vector(irq_to_vector(irq), action)
> -
> -#define release_irq(irq) \
> -    release_irq_vector(irq_to_vector(irq))
> -
> -#define request_irq(irq, handler, irqflags, devname, devid) \
> -    request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
> -
> -#elif defined(__arm__)
> +#if defined(__arm__)
>  
>  #define NR_IRQS  1024
>  #define nr_irqs NR_IRQS
>  extern irq_desc_t irq_desc[NR_IRQS];
>  
> -extern int setup_irq(unsigned int irq, struct irqaction *);
> -extern void release_irq(unsigned int irq);
> -extern int request_irq(unsigned int irq,
> -               void (*handler)(int, void *, struct cpu_user_regs *),
> -               unsigned long irqflags, const char * devname, void *dev_id);
> +#endif
>  
> -#else
>  extern int setup_irq(unsigned int irq, struct irqaction *);
>  extern void release_irq(unsigned int irq);
>  extern int request_irq(unsigned int irq,
>                 void (*handler)(int, void *, struct cpu_user_regs *),
>                 unsigned long irqflags, const char * devname, void *dev_id);
> -#endif
>  
>  extern hw_irq_controller no_irq_type;
>  extern void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs);
> --- a/xen/include/xen/libelf.h
> +++ b/xen/include/xen/libelf.h
> @@ -23,7 +23,7 @@
>  #ifndef __XEN_LIBELF_H__
>  #define __XEN_LIBELF_H__
>  
> -#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) ||
> defined(__arm__)
> +#if defined(__i386__) || defined(__x86_64__) || defined(__arm__)
>  #define XEN_ELF_LITTLE_ENDIAN
>  #else
>  #error define architectural endianness
> --- a/xen/include/xen/symbols.h
> +++ b/xen/include/xen/symbols.h
> @@ -21,13 +21,9 @@ static void __check_printsym_format(cons
>  {
>  }
>  
> -/* ia64 and ppc64 use function descriptors, which contain the real address */
> -#if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
> -#define print_fn_descriptor_symbol(fmt, addr)  \
> -do {      \
> - unsigned long *__faddr = (unsigned long*) addr;  \
> - print_symbol(fmt, __faddr[0]);  \
> -} while (0)
> +#if 0
> +#define print_fn_descriptor_symbol(fmt, addr) \
> + print_symbol(fmt, *(unsigned long *)addr)
>  #else
>  #define print_fn_descriptor_symbol(fmt, addr) print_symbol(fmt, addr)
>  #endif
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:57:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzY5-0003Q1-Ju; Tue, 03 Apr 2012 08:57:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SEzY4-0003Ps-1a
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 08:57:08 +0000
Received: from [85.158.143.35:57683] by server-2.bemta-4.messagelabs.com id
	31/CD-17550-36BBA7F4; Tue, 03 Apr 2012 08:57:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333443425!10969729!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 3 Apr 2012 08:57:05 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:57:05 -0000
Received: by bkcjg9 with SMTP id jg9so3608684bkc.32
	for <multiple recipients>; Tue, 03 Apr 2012 01:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cdlZd1+K4TYko/9mZCFweO5sx5LN3JDAc2ochAiisbc=;
	b=AGipzD+0fCfok9y+3SoEPYyV8zaBy0bk+pWnJcaSdzfcIpcvWj3cY7kd1EDdlq70Ki
	+9oATtzwjicNkxybYSTXHfktXZzAetfAyB+MLRf16JD/gKSUwj4CQljYr3vkUOAQwh2J
	HSLEIGl5xbXHGVxDe/rchlhNskrpu6XrA8JDqdcmzYCH4wC5DveVhdnWneuD5g2Usane
	lfAWzoBt1ABH9CaLz23QbLl7EHT7qn7F+uKweR5Gh/ZGN583jKToaUBQ8OP8MiOI2LZ+
	JKL8T2PxoeUkf/zutXFNfl0eb0ZeFxW0gjWTdaGb8gbSN6qnQd8rMYWiITdttwzrAiKX
	m0Vg==
Received: by 10.204.148.89 with SMTP id o25mr5054833bkv.52.1333443424662;
	Tue, 03 Apr 2012 01:57:04 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id s16sm44126825bkt.3.2012.04.03.01.57.02
	(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 01:57:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 03 Apr 2012 09:57:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CBA079EC.2FF6B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] removal of ia64 port
Thread-Index: Ac0Rd7sEAerbOKTnYk26Nw/IemUboA==
In-Reply-To: <4F7ACE69020000780007C3E0@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>, Ian.Campbell@citrix.com,
	xen-ia64-devel@lists.xen.org
Subject: Re: [Xen-devel] removal of ia64 port
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/04/2012 09:18, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 02.04.12 at 17:33, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 02/04/2012 16:16, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> now that we apparently having reached consensus here, are you
>>> going to purge the ia64 bits from the tree, or do you want me to?
>> 
>> Please go ahead.
> 
> This is the patch I'm intending to commit (omitting all the ia64 files
> that are going to be removed).
> 
> It retains IA64-specific bits in code imported from elsewhere (e.g.
> ACPI, EFI) as well as in the public headers.
> 
> It also doesn't touch the tools, mini-os, and unmodified_drivers
> sub-trees.

Acked-by: Keir Fraser <keir@xen.org>

> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -138,14 +138,6 @@ M: Tim Deegan <tim@xen.org>
>  S: Supported
>  F: tools/debugger/kdd/
>  
> -IA64 ARCHITECTURE
> -M: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
> -S: Supported
> -L: xen-ia64-devel@lists.xensource.com
> -F: xen/arch/ia64/*
> -F: xen/include/asm-ia64/*
> -F: tools/libxc/ia64/*
> -
>  INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>  M: Joseph Cihula <joseph.cihula@intel.com>
>  M: Gang Wei <gang.wei@intel.com>
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -58,7 +58,6 @@ subdir-$(CONFIG_COMPAT) += compat
>  
>  subdir-$(x86_32) += hvm
>  subdir-$(x86_64) += hvm
> -subdir-$(ia64) += hvm
>  
>  subdir-y += libelf
>  subdir-$(HAS_DEVICE_TREE) += libfdt
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1514,9 +1514,7 @@ gnttab_transfer(
>              goto copyback;
>          }
>  
> -#ifndef __ia64__ /* IA64 implicitly replaces the old page in steal_page(). */
>          guest_physmap_remove_page(d, gop.mfn, mfn, 0);
> -#endif
>          flush_tlb_mask(d->domain_dirty_cpumask);
>  
>          /* Find the target domain. */
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -721,11 +721,7 @@ static void crash_save_vmcoreinfo(void)
>      VMCOREINFO_STRUCT_SIZE(domain);
>  
>      VMCOREINFO_OFFSET(page_info, count_info);
> -#ifdef __ia64__
> -    VMCOREINFO_OFFSET_SUB(page_info, u.inuse, _domain);
> -#else
>      VMCOREINFO_OFFSET_SUB(page_info, v.inuse, _domain);
> -#endif
>      VMCOREINFO_OFFSET(domain, domain_id);
>      VMCOREINFO_OFFSET(domain, next_in_list);
>  
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -23,9 +23,7 @@
>  #include <xen/tmem_xen.h>
>  #include <asm/current.h>
>  #include <asm/hardirq.h>
> -#ifndef __ia64__
>  #include <asm/p2m.h>
> -#endif
>  #include <xen/numa.h>
>  #include <public/memory.h>
>  #include <xsm/xsm.h>
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1141,7 +1141,7 @@ void __init scrub_heap_pages(void)
>   * XEN-HEAP SUB-ALLOCATOR
>   */
>  
> -#if !defined(__x86_64__) && !defined(__ia64__)
> +#if !defined(__x86_64__)
>  
>  void init_xenheap_pages(paddr_t ps, paddr_t pe)
>  {
> --- a/xen/common/tmem_xen.c
> +++ b/xen/common/tmem_xen.c
> @@ -88,7 +88,7 @@ void tmh_copy_page(char *to, char*from)
>  #endif
>  }
>  
> -#if defined(__ia64__) || defined (CONFIG_ARM)
> +#if defined(CONFIG_ARM)
>  static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long
> *pcli_mfn,
>                                   pfp_t **pcli_pfp, bool_t cli_write)
>  {
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -442,16 +442,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
>              goto out;
>          }
>  
> -#ifdef CONFIG_IA64
> -        /* for IA64, currently it only supports FFH */
> -        if (dom0_px_info->control_register.space_id !=
> -            ACPI_ADR_SPACE_FIXED_HARDWARE)
> -        {
> -            ret = -EINVAL;
> -            goto out;
> -        }
> -#endif
> -
>          memcpy ((void *)&pxpt->control_register,
>                  (void *)&dom0_px_info->control_register,
>                  sizeof(struct xen_pct_register));
> @@ -493,7 +483,6 @@ int set_px_pminfo(uint32_t acpi_id, stru
>      {
>  #ifdef CONFIG_X86
>          /* for X86, check domain coordination */
> -        /* for IA64, _PSD is optional for current IA64 cpufreq algorithm */
>          if (dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
>              dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_ANY &&
>              dom0_px_info->shared_type != CPUFREQ_SHARED_TYPE_HW)
> --- a/xen/drivers/passthrough/Makefile
> +++ b/xen/drivers/passthrough/Makefile
> @@ -1,5 +1,4 @@
>  subdir-$(x86) += vtd
> -subdir-$(ia64) += vtd
>  subdir-$(x86) += amd
>  subdir-$(x86_64) += x86
>  
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -419,7 +419,6 @@ int hvm_do_IRQ_dpci(struct domain *d, st
>      return 1;
>  }
>  
> -#ifdef SUPPORT_MSI_REMAPPING
>  /* called with d->event_lock held */
>  static void __msi_pirq_eoi(struct hvm_pirq_dpci *pirq_dpci)
>  {
> @@ -479,7 +478,6 @@ static int hvm_pci_msi_assert(struct dom
>              ? send_guest_pirq(d, pirq)
>              : vmsi_deliver_pirq(d, pirq_dpci));
>  }
> -#endif
>  
>  static int _hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci
> *pirq_dpci,
>                              void *arg)
> @@ -489,13 +487,12 @@ static int _hvm_dirq_assist(struct domai
>  
>      if ( test_and_clear_bool(pirq_dpci->masked) )
>      {
> -#ifdef SUPPORT_MSI_REMAPPING
>          if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI )
>          {
>              hvm_pci_msi_assert(d, pirq_dpci);
>              return 0;
>          }
> -#endif
> +
>          list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
>          {
>              struct pirq *info = dpci_pirq(pirq_dpci);
> @@ -508,13 +505,11 @@ static int _hvm_dirq_assist(struct domai
>                  hvm_pci_intx_assert(d, device, intx);
>              pirq_dpci->pending++;
>  
> -#ifdef SUPPORT_MSI_REMAPPING
>              if ( pirq_dpci->flags & HVM_IRQ_DPCI_TRANSLATE )
>              {
>                  /* for translated MSI to INTx interrupt, eoi as early as
> possible */
>                  __msi_pirq_eoi(pirq_dpci);
>              }
> -#endif
>          }
>  
>          /*
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -593,17 +593,6 @@ int iommu_do_domctl(
>          bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
>          devfn = domctl->u.assign_device.machine_sbdf & 0xff;
>  
> -#ifdef __ia64__ /* XXX Is this really needed? */
> -        if ( device_assigned(seg, bus, devfn) )
> -        {
> -            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> -                   "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> -                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> -            ret = -EINVAL;
> -            goto assign_device_out;
> -        }
> -#endif
> -
>          ret = assign_device(d, seg, bus, devfn);
>          if ( ret )
>              printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> @@ -632,14 +621,6 @@ int iommu_do_domctl(
>          bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
>          devfn = domctl->u.assign_device.machine_sbdf & 0xff;
>  
> -#ifdef __ia64__ /* XXX Is this really needed? */
> -        if ( !device_assigned(seg, bus, devfn) )
> -        {
> -            ret = -EINVAL;
> -            goto deassign_device_out;
> -        }
> -#endif
> -
>          spin_lock(&pcidevs_lock);
>          ret = deassign_device(d, seg, bus, devfn);
>          spin_unlock(&pcidevs_lock);
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -696,7 +696,6 @@ void __init setup_dom0_pci_devices(
>      spin_unlock(&pcidevs_lock);
>  }
>  
> -#ifdef SUPPORT_MSI_REMAPPING
>  static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
>  {
>      struct pci_dev *pdev;
> @@ -738,8 +737,6 @@ static int __init setup_dump_pcidevs(voi
>      return 0;
>  }
>  __initcall(setup_dump_pcidevs);
> -#endif
> -
>  
>  /*
>   * Local variables:
> --- a/xen/drivers/passthrough/vtd/Makefile
> +++ b/xen/drivers/passthrough/vtd/Makefile
> @@ -1,5 +1,4 @@
>  subdir-$(x86) += x86
> -subdir-$(ia64) += ia64
>  
>  obj-y += iommu.o
>  obj-y += dmar.o
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -31,26 +31,7 @@
>  #include "vtd.h"
>  #include "extern.h"
>  
> -#ifdef __ia64__
> -#define nr_ioapics              iosapic_get_nr_iosapics()
> -#define nr_ioapic_entries(i)  iosapic_get_nr_pins(i)
> -#define __io_apic_read(apic, reg) \
> -    (*IO_APIC_BASE(apic) = reg, *(IO_APIC_BASE(apic)+4))
> -#define __io_apic_write(apic, reg, val) \
> -    (*IO_APIC_BASE(apic) = reg, *(IO_APIC_BASE(apic)+4) = (val))
> -#define __ioapic_read_entry(apic, pin, raw) ({ \
> -    struct IO_xAPIC_route_entry _e_; \
> -    ASSERT(raw); \
> -    ((u32 *)&_e_)[0] = __io_apic_read(apic, 0x10 + 2 * (pin)); \
> -    ((u32 *)&_e_)[1] = __io_apic_read(apic, 0x11 + 2 * (pin)); \
> -    _e_; \
> -})
> -#define __ioapic_write_entry(apic, pin, raw, ent) ({ \
> -    ASSERT(raw); \
> -    __io_apic_write(apic, 0x10 + 2 * (pin), ((u32 *)&(ent))[0]); \
> -    __io_apic_write(apic, 0x11 + 2 * (pin), ((u32 *)&(ent))[1]); \
> -})
> -#else
> +#if defined(__i386__) || defined(__x86_64__)
>  #include <asm/apic.h>
>  #include <asm/io_apic.h>
>  #define nr_ioapic_entries(i)  nr_ioapic_entries[i]
> @@ -326,8 +307,6 @@ static int ioapic_rte_to_remap_entry(str
>              new_ire.lo.dst = value;
>          else
>              new_ire.lo.dst = (value >> 24) << 8;
> -#else /* __ia64__ */
> -        new_ire.lo.dst = value >> 16;
>  #endif
>      }
>      else
> @@ -625,12 +604,8 @@ static int msi_msg_to_remap_entry(
>      new_ire.lo.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
>      new_ire.lo.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
>      new_ire.lo.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x1;
> -#ifdef CONFIG_X86
>      /* Hardware require RH = 1 for LPR delivery mode */
>      new_ire.lo.rh = (new_ire.lo.dlm == dest_LowestPrio);
> -#else
> -    new_ire.lo.rh = 0;
> -#endif
>      new_ire.lo.avail = 0;
>      new_ire.lo.res_1 = 0;
>      new_ire.lo.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
> @@ -703,18 +678,6 @@ void msi_msg_write_remap_rte(
>  
>      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
>  }
> -#elif defined(__ia64__)
> -void msi_msg_read_remap_rte(
> -    struct msi_desc *msi_desc, struct msi_msg *msg)
> -{
> -    /* TODO. */
> -}
> -
> -void msi_msg_write_remap_rte(
> -    struct msi_desc *msi_desc, struct msi_msg *msg)
> -{
> -    /* TODO. */
> -}
>  #endif
>  
>  int enable_intremap(struct iommu *iommu, int eim)
> @@ -838,8 +801,6 @@ out:
>      spin_unlock_irqrestore(&iommu->register_lock, flags);
>  }
>  
> -#ifndef __ia64__
> -
>  /*
>   * This function is used to enable Interrupt remapping when
>   * enable x2apic
> @@ -914,5 +875,3 @@ void iommu_disable_x2apic_IR(void)
>      for_each_drhd_unit ( drhd )
>          disable_qinval(drhd->iommu);
>  }
> -
> -#endif /* !__ia64__ */
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -33,7 +33,7 @@
>  #include <xen/keyhandler.h>
>  #include <asm/msi.h>
>  #include <asm/irq.h>
> -#ifndef __ia64__
> +#if defined(__i386__) || defined(__x86_64__)
>  #include <asm/hvm/vmx/vmx.h>
>  #include <asm/p2m.h>
>  #include <mach_apic.h>
> @@ -44,10 +44,6 @@
>  #include "vtd.h"
>  #include "../ats.h"
>  
> -#ifdef __ia64__
> -#define nr_ioapics              iosapic_get_nr_iosapics()
> -#endif
> -
>  /* Possible unfiltered LAPIC/MSI messages from untrusted sources? */
>  bool_t __read_mostly untrusted_msi;
>  
> @@ -1057,11 +1053,7 @@ static unsigned int dma_msi_startup(stru
>      return 0;
>  }
>  
> -#ifndef __ia64__
>  static void dma_msi_end(struct irq_desc *desc, u8 vector)
> -#else
> -static void dma_msi_end(struct irq_desc *desc)
> -#endif
>  {
>      dma_msi_unmask(desc);
>      ack_APIC_irq();
> @@ -1841,7 +1833,6 @@ void iommu_pte_flush(struct domain *d, u
>  
>  static int vtd_ept_page_compatible(struct iommu *iommu)
>  {
> -#ifndef __ia64__
>      u64 ept_cap, vtd_cap = iommu->cap;
>  
>      /* EPT is not initialised yet, so we must check the capability in
> @@ -1851,9 +1842,6 @@ static int vtd_ept_page_compatible(struc
>  
>      return ( ept_has_2mb(ept_cap) == cap_sps_2mb(vtd_cap)
>               && ept_has_1gb(ept_cap) == cap_sps_1gb(vtd_cap) );
> -#else
> -    return 0;
> -#endif
>  }
>  
>  /*
> @@ -1861,7 +1849,6 @@ static int vtd_ept_page_compatible(struc
>   */
>  void iommu_set_pgd(struct domain *d)
>  {
> -#ifndef __ia64__
>      struct hvm_iommu *hd  = domain_hvm_iommu(d);
>      mfn_t pgd_mfn;
>  
> @@ -1872,7 +1859,6 @@ void iommu_set_pgd(struct domain *d)
>  
>      pgd_mfn = pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
>      hd->pgd_maddr = pagetable_get_paddr(pagetable_from_mfn(pgd_mfn));
> -#endif
>  }
>  
>  static int rmrr_identity_mapping(struct domain *d,
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -301,8 +301,7 @@ static void dump_iommu_info(unsigned cha
>          }
>      }
>  #else
> -    printk("%s: not implemnted on IA64 for now.\n", __func__);
> -    /* ia64: TODO */
> +    printk("%s: not implemented for now\n", __func__);
>  #endif
>  }
>  
> --- a/xen/drivers/passthrough/vtd/vtd.h
> +++ b/xen/drivers/passthrough/vtd/vtd.h
> @@ -26,44 +26,8 @@
>  #define MAP_ME_PHANTOM_FUNC      1
>  #define UNMAP_ME_PHANTOM_FUNC    0
>  
> -/* Accomodate both IOAPIC and IOSAPIC. */
> -#ifndef __ia64__
> +/* Allow for both IOAPIC and IOSAPIC. */
>  #define IO_xAPIC_route_entry IO_APIC_route_entry
> -#else
> -struct IO_xAPIC_route_entry {
> -    __u32   vector      :  8,
> -        delivery_mode   :  3,   /* 000: FIXED
> -                                 * 001: lowest prio
> -                                 * 111: ExtINT
> -                                 */
> -        dest_mode       :  1,   /* 0: physical, 1: logical */
> -        delivery_status :  1,
> -        polarity        :  1,
> -        irr             :  1,
> -        trigger         :  1,   /* 0: edge, 1: level */
> -        mask            :  1,   /* 0: enabled, 1: disabled */
> -        __reserved_2    : 15;
> -
> -    union {
> -        struct { __u32
> -            __reserved_1    : 24,
> -            physical_dest   :  4,
> -            __reserved_2    :  4;
> -        } physical;
> -
> -        struct { __u32
> -            __reserved_1    : 24,
> -            logical_dest    :  8;
> -        } logical;
> -
> -        struct { __u32
> -            __reserved_1    : 16,
> -            dest_id         : 16;
> -        };
> -    } dest;
> -
> -} __attribute__ ((packed));
> -#endif
>  
>  struct IO_APIC_route_remap_entry {
>      union {
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -38,7 +38,7 @@ suffix-$(CONFIG_X86)      := \#pragma pa
>  endif
>  
>  public-$(CONFIG_X86) := $(wildcard public/arch-x86/*.h public/arch-x86/*/*.h)
> -public-$(CONFIG_IA64) := $(wildcard public/arch-ia64/*.h
> public/arch-ia64/*/*.h)
> +public-$(CONFIG_ARM) := $(wildcard public/arch-arm/*.h public/arch-arm/*/*.h)
>  
>  .PHONY: all
>  all: $(headers-y)
> @@ -74,8 +74,6 @@ compat/xlat.h: xlat.lst $(filter-out com
> mv -f $@.new $@
>  
>  ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
> -# public/arch-ia64.h explicitly bails on __STRICT_ANSI__
> -ifeq ($(CONFIG_IA64),)
>  
>  all: headers.chk
>  
> @@ -84,7 +82,6 @@ headers.chk: $(filter-out public/arch-%
> mv $@.new $@
>  
>  endif
> -endif
>  
>  clean::
> rm -rf compat headers.chk
> --- a/xen/include/asm-x86/hvm/irq.h
> +++ b/xen/include/asm-x86/hvm/irq.h
> @@ -104,11 +104,4 @@ struct hvm_intack hvm_vcpu_has_pending_i
>  struct hvm_intack hvm_vcpu_ack_pending_irq(struct vcpu *v,
>                                             struct hvm_intack intack);
>  
> -/*
> - * Currently IA64 Xen doesn't support MSI. So for x86, we define this macro
> - * to control the conditional compilation of some MSI-related functions.
> - * This macro will be removed once IA64 has MSI support.
> - */
> -#define SUPPORT_MSI_REMAPPING 1
> -
>  #endif /* __ASM_X86_HVM_IRQ_H__ */
> --- a/xen/include/asm-x86/hvm/vioapic.h
> +++ b/xen/include/asm-x86/hvm/vioapic.h
> @@ -41,7 +41,7 @@
>  /* Direct registers. */
>  #define VIOAPIC_REG_SELECT  0x00
>  #define VIOAPIC_REG_WINDOW  0x10
> -#define VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */
> +#define VIOAPIC_REG_EOI     0x40
>  
>  /* Indirect registers. */
>  #define VIOAPIC_REG_APIC_ID 0x00 /* x86 IOAPIC only */
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -82,7 +82,7 @@ typedef struct cpumask{ DECLARE_BITMAP(b
>  
>  extern unsigned int nr_cpu_ids;
>  
> -#if NR_CPUS > 4 * BITS_PER_LONG && !defined(__ia64__)
> +#if NR_CPUS > 4 * BITS_PER_LONG
>  /* Assuming NR_CPUS is huge, a runtime limit is more efficient.  Also,
>   * not all bits may be allocated. */
>  extern unsigned int nr_cpumask_bits;
> @@ -263,37 +263,6 @@ static inline const cpumask_t *cpumask_o
> return (const cpumask_t *)(p - cpu / BITS_PER_LONG);
>  }
>  
> -#if defined(__ia64__) /* XXX needs cleanup */
> -#define CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)
> -
> -#if NR_CPUS <= BITS_PER_LONG
> -
> -#define CPU_MASK_ALL       \
> -/*(cpumask_t)*/ { {       \
> - [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD   \
> -} }
> -
> -#else
> -
> -#define CPU_MASK_ALL       \
> -/*(cpumask_t)*/ { {       \
> - [0 ... BITS_TO_LONGS(NR_CPUS)-2] = ~0UL,   \
> - [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD   \
> -} }
> -
> -#endif
> -
> -#define CPU_MASK_NONE       \
> -/*(cpumask_t)*/ { {       \
> - 0UL        \
> -} }
> -
> -#define CPU_MASK_CPU0       \
> -/*(cpumask_t)*/ { {       \
> - [0] =  1UL       \
> -} }
> -#endif /* __ia64__ */
> -
>  #define cpumask_bits(maskp) ((maskp)->bits)
>  
>  static inline int cpumask_scnprintf(char *buf, int len,
> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -5,15 +5,11 @@
>  #include <xen/types.h>
>  #endif
>  
> -#if defined(__ia64__)
> -# include_next <linux/efi.h>
> +#if defined(__i386__)
> +# define efi_enabled 0
>  #else
> -
> -# if defined(__i386__)
> -#  define efi_enabled 0
> -# else
>  extern const bool_t efi_enabled;
> -# endif
> +#endif
>  
>  #define EFI_INVALID_TABLE_ADDR (~0UL)
>  
> @@ -27,8 +23,6 @@ struct efi {
>  
>  extern struct efi efi;
>  
> -#endif
> -
>  #ifndef __ASSEMBLY__
>  
>  union xenpf_efi_info;
> --- a/xen/include/xen/elfcore.h
> +++ b/xen/include/xen/elfcore.h
> @@ -69,9 +69,6 @@ typedef struct {
>      unsigned long xen_phys_start;
>      unsigned long dom0_pfn_to_mfn_frame_list_list;
>  #endif
> -#if defined(__ia64__)
> -    unsigned long dom0_mm_pgd_mfn;
> -#endif
>  } crash_xen_info_t;
>  
>  #endif /* __ELFCOREC_H__ */
> --- a/xen/include/xen/hvm/irq.h
> +++ b/xen/include/xen/hvm/irq.h
> @@ -78,8 +78,6 @@ struct hvm_girq_dpci_mapping {
>  #define NR_LINK     4
>  #if defined(__i386__) || defined(__x86_64__)
>  # define NR_HVM_IRQS VIOAPIC_NUM_PINS
> -#elif defined(__ia64__)
> -# define NR_HVM_IRQS VIOSAPIC_NUM_PINS
>  #endif
>  
>  /* Protected by domain's event_lock */
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -35,11 +35,7 @@ extern bool_t iommu_debug;
>  extern bool_t amd_iommu_perdev_intremap;
>  
>  /* Does this domain have a P2M table we can use as its IOMMU pagetable? */
> -#ifndef __ia64__
>  #define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
> -#else
> -#define iommu_use_hap_pt(d) 0
> -#endif
>  
>  extern struct rangeset *mmio_ro_ranges;
>  
> --- a/xen/include/xen/irq.h
> +++ b/xen/include/xen/irq.h
> @@ -95,37 +95,19 @@ int arch_init_one_irq_desc(struct irq_de
>  
>  #define irq_desc_initialized(desc) ((desc)->handler != NULL)
>  
> -#if defined(__ia64__)
> -extern irq_desc_t irq_desc[NR_VECTORS];
> -
> -#define setup_irq(irq, action) \
> -    setup_irq_vector(irq_to_vector(irq), action)
> -
> -#define release_irq(irq) \
> -    release_irq_vector(irq_to_vector(irq))
> -
> -#define request_irq(irq, handler, irqflags, devname, devid) \
> -    request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
> -
> -#elif defined(__arm__)
> +#if defined(__arm__)
>  
>  #define NR_IRQS  1024
>  #define nr_irqs NR_IRQS
>  extern irq_desc_t irq_desc[NR_IRQS];
>  
> -extern int setup_irq(unsigned int irq, struct irqaction *);
> -extern void release_irq(unsigned int irq);
> -extern int request_irq(unsigned int irq,
> -               void (*handler)(int, void *, struct cpu_user_regs *),
> -               unsigned long irqflags, const char * devname, void *dev_id);
> +#endif
>  
> -#else
>  extern int setup_irq(unsigned int irq, struct irqaction *);
>  extern void release_irq(unsigned int irq);
>  extern int request_irq(unsigned int irq,
>                 void (*handler)(int, void *, struct cpu_user_regs *),
>                 unsigned long irqflags, const char * devname, void *dev_id);
> -#endif
>  
>  extern hw_irq_controller no_irq_type;
>  extern void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs);
> --- a/xen/include/xen/libelf.h
> +++ b/xen/include/xen/libelf.h
> @@ -23,7 +23,7 @@
>  #ifndef __XEN_LIBELF_H__
>  #define __XEN_LIBELF_H__
>  
> -#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) ||
> defined(__arm__)
> +#if defined(__i386__) || defined(__x86_64__) || defined(__arm__)
>  #define XEN_ELF_LITTLE_ENDIAN
>  #else
>  #error define architectural endianness
> --- a/xen/include/xen/symbols.h
> +++ b/xen/include/xen/symbols.h
> @@ -21,13 +21,9 @@ static void __check_printsym_format(cons
>  {
>  }
>  
> -/* ia64 and ppc64 use function descriptors, which contain the real address */
> -#if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
> -#define print_fn_descriptor_symbol(fmt, addr)  \
> -do {      \
> - unsigned long *__faddr = (unsigned long*) addr;  \
> - print_symbol(fmt, __faddr[0]);  \
> -} while (0)
> +#if 0
> +#define print_fn_descriptor_symbol(fmt, addr) \
> + print_symbol(fmt, *(unsigned long *)addr)
>  #else
>  #define print_fn_descriptor_symbol(fmt, addr) print_symbol(fmt, addr)
>  #endif
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:59:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzZj-0003Vi-8u; Tue, 03 Apr 2012 08:58:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEzZh-0003VU-8C
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:58:49 +0000
Received: from [85.158.139.83:16372] by server-5.bemta-5.messagelabs.com id
	66/7F-13566-8CBBA7F4; Tue, 03 Apr 2012 08:58:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333443526!22240204!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQwNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9243 invoked from network); 3 Apr 2012 08:58:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="23811382"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 04:58:45 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	04:58:45 -0400
Message-ID: <4F7ABBC4.4050106@citrix.com>
Date: Tue, 3 Apr 2012 09:58:44 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> Meaning that we will allocate up to XGB and not consider the
> rest of the memory as a possible balloon goal.

I agree with Jan when he commented on the equivalent Xen patch for this
behaviour.  The current behaviour is better than the classic one.

With your new behaviour it will no longer possible to specify an
unlimited balloon but a limited number of initial pages.  This is
behaviour that Jan said he used.

This problem is better solved by improving the documentation.  A review
of the xen.org wiki where dom0_mem is mentioned would be a good start,
and an update to the recently added section for distro developers.

David

> This results in /proc/meminfo reporting:
> 
> -MemTotal:        2845024 kB
> -MemFree:         2497716 kB
> +MemTotal:        2927192 kB
> +MemFree:         2458952 kB
>  ...
> -DirectMap4k:     8304640 kB
> +DirectMap4k:     3063808 kB
>  DirectMap2M:           0 kB
> 
> on a 8GB machine with 'dom0_mem=3GB' on the Xen hypervisor line.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 2a12143..4e4aa8e 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -261,11 +261,27 @@ static unsigned long __init xen_get_max_pages(void)
>  	 * the current maximum rather than the static maximum. In this
>  	 * case the e820 map provided to us will cover the static
>  	 * maximum region.
> +	 *
> +	 * The dom0_mem=min:X,max:Y tweaks options differently depending
> +	 * on the version, but in general this is what we get:
> +	 *                | XENMEM_maximum_reser  | nr_pages
> +	 * --------------++-----------------------+-------------------
> +	 *  no dom0_mem   | INT_MAX               | the max_phys_pfn
> +	 *  =3G           | INT_MAX               | 786432
> +	 *  =max:3G       | 786432                | 786432
> +	 *  =min:1G,max:3G| 262144                | 786432
> +	 *
> +	 * The =3G is often used and it lead to us initially setting
> +	 * 786432 and allowing dom0 to balloon up to the max_physical_pfn.
> +	 * This is at odd with the classic XenOClassic so lets emulate
> +	 * the classic behavior.
>  	 */
>  	if (xen_initial_domain()) {
>  		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
>  		if (ret > 0)
>  			max_pages = ret;
> +		if (ret == -1UL)
> +			max_pages = xen_start_info->nr_pages;
>  	}
>  
>  	return min(max_pages, MAX_DOMAIN_PAGES);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 08:59:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 08:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzZj-0003Vi-8u; Tue, 03 Apr 2012 08:58:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SEzZh-0003VU-8C
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 08:58:49 +0000
Received: from [85.158.139.83:16372] by server-5.bemta-5.messagelabs.com id
	66/7F-13566-8CBBA7F4; Tue, 03 Apr 2012 08:58:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333443526!22240204!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQwNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9243 invoked from network); 3 Apr 2012 08:58:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 08:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="23811382"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 04:58:45 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	04:58:45 -0400
Message-ID: <4F7ABBC4.4050106@citrix.com>
Date: Tue, 3 Apr 2012 09:58:44 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> Meaning that we will allocate up to XGB and not consider the
> rest of the memory as a possible balloon goal.

I agree with Jan when he commented on the equivalent Xen patch for this
behaviour.  The current behaviour is better than the classic one.

With your new behaviour it will no longer possible to specify an
unlimited balloon but a limited number of initial pages.  This is
behaviour that Jan said he used.

This problem is better solved by improving the documentation.  A review
of the xen.org wiki where dom0_mem is mentioned would be a good start,
and an update to the recently added section for distro developers.

David

> This results in /proc/meminfo reporting:
> 
> -MemTotal:        2845024 kB
> -MemFree:         2497716 kB
> +MemTotal:        2927192 kB
> +MemFree:         2458952 kB
>  ...
> -DirectMap4k:     8304640 kB
> +DirectMap4k:     3063808 kB
>  DirectMap2M:           0 kB
> 
> on a 8GB machine with 'dom0_mem=3GB' on the Xen hypervisor line.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 2a12143..4e4aa8e 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -261,11 +261,27 @@ static unsigned long __init xen_get_max_pages(void)
>  	 * the current maximum rather than the static maximum. In this
>  	 * case the e820 map provided to us will cover the static
>  	 * maximum region.
> +	 *
> +	 * The dom0_mem=min:X,max:Y tweaks options differently depending
> +	 * on the version, but in general this is what we get:
> +	 *                | XENMEM_maximum_reser  | nr_pages
> +	 * --------------++-----------------------+-------------------
> +	 *  no dom0_mem   | INT_MAX               | the max_phys_pfn
> +	 *  =3G           | INT_MAX               | 786432
> +	 *  =max:3G       | 786432                | 786432
> +	 *  =min:1G,max:3G| 262144                | 786432
> +	 *
> +	 * The =3G is often used and it lead to us initially setting
> +	 * 786432 and allowing dom0 to balloon up to the max_physical_pfn.
> +	 * This is at odd with the classic XenOClassic so lets emulate
> +	 * the classic behavior.
>  	 */
>  	if (xen_initial_domain()) {
>  		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
>  		if (ret > 0)
>  			max_pages = ret;
> +		if (ret == -1UL)
> +			max_pages = xen_start_info->nr_pages;
>  	}
>  
>  	return min(max_pages, MAX_DOMAIN_PAGES);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEziS-0003mH-FH; Tue, 03 Apr 2012 09:07:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEziR-0003mC-Gd
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:07:51 +0000
Received: from [85.158.138.51:65150] by server-6.bemta-3.messagelabs.com id
	2F/CB-08206-6EDBA7F4; Tue, 03 Apr 2012 09:07:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333444069!18716463!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15180 invoked from network); 3 Apr 2012 09:07:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 09:07:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333444069; l=990;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qr8dew9JPjIWOn1z+P4NlewQNxY=;
	b=s4+WceBBxCaVGLqDkruyUmVxTERKA6Tqbz7i97KkNu1cujjUFTgQZ+w/Gcpx1LNYZIp
	KXKGp+iokA+hyACRDCcl0OWl6vaXBuAnRz4w/gmHLGBOnGXOVvFg+OKSXgrCbu1HCb3O+
	iO5fp4wLr09dYNKt/1cfwqelkHsHqQXdHD4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (fruni mo42) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id J06f02o338KAnK ;
	Tue, 3 Apr 2012 11:07:49 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id B43CD18637; Tue,  3 Apr 2012 11:07:48 +0200 (CEST)
Date: Tue, 3 Apr 2012 11:07:48 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403090748.GA27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
	<1333441383.25602.105.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333441383.25602.105.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Campbell wrote:

> On Mon, 2012-04-02 at 20:54 +0100, Olaf Hering wrote:
> > On Mon, Apr 02, Ian Jackson wrote:
> > 
> > > Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > > > node-select.c: In function 'vchan_wr':
> > > > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> > > 
> > > This one is a question of coding style.  Apparently libvchan uses
> > > mixed statements/declarations, so this should be fixed by changing the
> > > warning flags.

> However skimming over node-select.c and io.c (as another random file) it
> looks like the use of mixed declarations and code is the exception not
> the rule even within libvchan, so I think it would be fine to fix the
> two places where this isn't the case.

If thats ok with IanJ as well, I will prepare another patch to fix just
that warning in node-select.c

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEziS-0003mH-FH; Tue, 03 Apr 2012 09:07:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEziR-0003mC-Gd
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:07:51 +0000
Received: from [85.158.138.51:65150] by server-6.bemta-3.messagelabs.com id
	2F/CB-08206-6EDBA7F4; Tue, 03 Apr 2012 09:07:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333444069!18716463!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15180 invoked from network); 3 Apr 2012 09:07:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 09:07:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333444069; l=990;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qr8dew9JPjIWOn1z+P4NlewQNxY=;
	b=s4+WceBBxCaVGLqDkruyUmVxTERKA6Tqbz7i97KkNu1cujjUFTgQZ+w/Gcpx1LNYZIp
	KXKGp+iokA+hyACRDCcl0OWl6vaXBuAnRz4w/gmHLGBOnGXOVvFg+OKSXgrCbu1HCb3O+
	iO5fp4wLr09dYNKt/1cfwqelkHsHqQXdHD4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (fruni mo42) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id J06f02o338KAnK ;
	Tue, 3 Apr 2012 11:07:49 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id B43CD18637; Tue,  3 Apr 2012 11:07:48 +0200 (CEST)
Date: Tue, 3 Apr 2012 11:07:48 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403090748.GA27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
	<1333441383.25602.105.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333441383.25602.105.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Campbell wrote:

> On Mon, 2012-04-02 at 20:54 +0100, Olaf Hering wrote:
> > On Mon, Apr 02, Ian Jackson wrote:
> > 
> > > Olaf Hering writes ("[Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> > > > node-select.c: In function 'vchan_wr':
> > > > node-select.c:60:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> > > 
> > > This one is a question of coding style.  Apparently libvchan uses
> > > mixed statements/declarations, so this should be fixed by changing the
> > > warning flags.

> However skimming over node-select.c and io.c (as another random file) it
> looks like the use of mixed declarations and code is the exception not
> the rule even within libvchan, so I think it would be fine to fix the
> two places where this isn't the case.

If thats ok with IanJ as well, I will prepare another patch to fix just
that warning in node-select.c

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:11:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzlz-0003to-4m; Tue, 03 Apr 2012 09:11:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEzlx-0003te-6w
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:11:29 +0000
Received: from [85.158.139.83:9868] by server-12.bemta-5.messagelabs.com id
	02/8C-05587-0CEBA7F4; Tue, 03 Apr 2012 09:11:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333444287!18339650!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDgyNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDgyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27069 invoked from network); 3 Apr 2012 09:11:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 09:11:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333444287; l=592;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=UV5yC8a1bazIjkmpQ4B6MeAv7nI=;
	b=LytnxTnShG8v2zAnbYBwRaIXiFEwtlhZrChFpL4x8qcpd38/Pg/zBCDbaLB22kVfkIP
	o9HyAohcxL9XZg/g07ZN8fcSxUbnNvzrXU+JwaOMrNV2zFRS//lh7NVApN5Jt+znDd67j
	LIJ2ScKzmidwC1zoy+yRI5HG06HSxDqAr1A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (cohen mo58) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id p04470o338c1et ;
	Tue, 3 Apr 2012 11:11:26 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5F1EA18637; Tue,  3 Apr 2012 11:11:26 +0200 (CEST)
Date: Tue, 3 Apr 2012 11:11:26 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403091126.GB27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
	<1333441832.25602.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333441832.25602.112.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Campbell wrote:

> [0] Even gcc(1) says:
>        -Wno-format-zero-length (C and Objective-C only)
>            If -Wformat is specified, do not warn about zero-length formats.
>            The C standard specifies that zero-length formats are allowed.
> So quite why it appears that Wall is enabling Wformat-zero-length I have
> no idea, this is a clear gcc bug in my opinion.

Thats what they say:

"<jakub> olaf_: warnings aren't just about things that aren't allowed in
the standard, but about things considered bad by significant amount of
users"

So gcc wont be changed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:11:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzlz-0003to-4m; Tue, 03 Apr 2012 09:11:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SEzlx-0003te-6w
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:11:29 +0000
Received: from [85.158.139.83:9868] by server-12.bemta-5.messagelabs.com id
	02/8C-05587-0CEBA7F4; Tue, 03 Apr 2012 09:11:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333444287!18339650!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDgyNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDgyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27069 invoked from network); 3 Apr 2012 09:11:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 09:11:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333444287; l=592;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=UV5yC8a1bazIjkmpQ4B6MeAv7nI=;
	b=LytnxTnShG8v2zAnbYBwRaIXiFEwtlhZrChFpL4x8qcpd38/Pg/zBCDbaLB22kVfkIP
	o9HyAohcxL9XZg/g07ZN8fcSxUbnNvzrXU+JwaOMrNV2zFRS//lh7NVApN5Jt+znDd67j
	LIJ2ScKzmidwC1zoy+yRI5HG06HSxDqAr1A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (cohen mo58) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id p04470o338c1et ;
	Tue, 3 Apr 2012 11:11:26 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5F1EA18637; Tue,  3 Apr 2012 11:11:26 +0200 (CEST)
Date: Tue, 3 Apr 2012 11:11:26 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403091126.GB27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
	<1333441832.25602.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333441832.25602.112.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Campbell wrote:

> [0] Even gcc(1) says:
>        -Wno-format-zero-length (C and Objective-C only)
>            If -Wformat is specified, do not warn about zero-length formats.
>            The C standard specifies that zero-length formats are allowed.
> So quite why it appears that Wall is enabling Wformat-zero-length I have
> no idea, this is a clear gcc bug in my opinion.

Thats what they say:

"<jakub> olaf_: warnings aren't just about things that aren't allowed in
the standard, but about things considered bad by significant amount of
users"

So gcc wont be changed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzzF-000463-Fj; Tue, 03 Apr 2012 09:25:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEzzE-00045y-5R
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:25:12 +0000
Received: from [85.158.138.51:18961] by server-6.bemta-3.messagelabs.com id
	EF/49-08206-7F1CA7F4; Tue, 03 Apr 2012 09:25:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333445110!16345721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16987 invoked from network); 3 Apr 2012 09:25:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 09:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11739787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 09:24:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	10:25:00 +0100
Message-ID: <1333445097.25602.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 10:24:57 +0100
In-Reply-To: <20120403091126.GB27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
	<1333441832.25602.112.camel@zakaz.uk.xensource.com>
	<20120403091126.GB27810@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 10:11 +0100, Olaf Hering wrote:
> On Tue, Apr 03, Ian Campbell wrote:
> 
> > [0] Even gcc(1) says:
> >        -Wno-format-zero-length (C and Objective-C only)
> >            If -Wformat is specified, do not warn about zero-length formats.
> >            The C standard specifies that zero-length formats are allowed.
> > So quite why it appears that Wall is enabling Wformat-zero-length I have
> > no idea, this is a clear gcc bug in my opinion.
> 
> Thats what they say:
> 
> "<jakub> olaf_: warnings aren't just about things that aren't allowed in
> the standard, but about things considered bad by significant amount of
> users"

I find it hard to believe that a significant amount of users think this
particular warning is worthwhile, since there are clearly legitimate
uses of an empty format string (our use in libxl__xs_write being the
obvious example!), and as far as I can tell the only argument for it is
that it might waste a few precious cycles, but I've not got the energy
to argue with the gcc developers about it.

> So gcc wont be changed.

Then we should disable this warning, after our own Wall.

If something else (like RPM_OPTS) is also adding Wall then it had better
do the same.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SEzzF-000463-Fj; Tue, 03 Apr 2012 09:25:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SEzzE-00045y-5R
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:25:12 +0000
Received: from [85.158.138.51:18961] by server-6.bemta-3.messagelabs.com id
	EF/49-08206-7F1CA7F4; Tue, 03 Apr 2012 09:25:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333445110!16345721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16987 invoked from network); 3 Apr 2012 09:25:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 09:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11739787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 09:24:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	10:25:00 +0100
Message-ID: <1333445097.25602.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 10:24:57 +0100
In-Reply-To: <20120403091126.GB27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
	<1333441832.25602.112.camel@zakaz.uk.xensource.com>
	<20120403091126.GB27810@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 10:11 +0100, Olaf Hering wrote:
> On Tue, Apr 03, Ian Campbell wrote:
> 
> > [0] Even gcc(1) says:
> >        -Wno-format-zero-length (C and Objective-C only)
> >            If -Wformat is specified, do not warn about zero-length formats.
> >            The C standard specifies that zero-length formats are allowed.
> > So quite why it appears that Wall is enabling Wformat-zero-length I have
> > no idea, this is a clear gcc bug in my opinion.
> 
> Thats what they say:
> 
> "<jakub> olaf_: warnings aren't just about things that aren't allowed in
> the standard, but about things considered bad by significant amount of
> users"

I find it hard to believe that a significant amount of users think this
particular warning is worthwhile, since there are clearly legitimate
uses of an empty format string (our use in libxl__xs_write being the
obvious example!), and as far as I can tell the only argument for it is
that it might waste a few precious cycles, but I've not got the energy
to argue with the gcc developers about it.

> So gcc wont be changed.

Then we should disable this warning, after our own Wall.

If something else (like RPM_OPTS) is also adding Wall then it had better
do the same.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0KM-0004Hh-Cg; Tue, 03 Apr 2012 09:47:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SF0KL-0004Hc-BB
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:47:01 +0000
Received: from [85.158.143.99:63543] by server-1.bemta-4.messagelabs.com id
	64/6F-20925-417CA7F4; Tue, 03 Apr 2012 09:47:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333446403!18713094!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12643 invoked from network); 3 Apr 2012 09:46:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 09:46:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 10:46:43 +0100
Message-Id: <4F7AE321020000780007C456@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 10:46:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
In-Reply-To: <4F7ABBC4.4050106@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
> With your new behaviour it will no longer possible to specify an
> unlimited balloon but a limited number of initial pages.  This is
> behaviour that Jan said he used.

An unlimited balloon was never possible afaict (as that would have
implied setting up an "infinite" number of struct page instances at
boot time.

What I'm using is "dom0_mem=-<num>M" together with the kernel
option "mem=<num>G", such that max-balloon > initial alloc (usually
I set max-balloon to approximately the amount of memory in the
system, so the upper limit is "infinite" in the sense that I can't go
higher anyway, but it's not truly infinity).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0KM-0004Hh-Cg; Tue, 03 Apr 2012 09:47:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SF0KL-0004Hc-BB
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:47:01 +0000
Received: from [85.158.143.99:63543] by server-1.bemta-4.messagelabs.com id
	64/6F-20925-417CA7F4; Tue, 03 Apr 2012 09:47:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333446403!18713094!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12643 invoked from network); 3 Apr 2012 09:46:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 09:46:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Apr 2012 10:46:43 +0100
Message-Id: <4F7AE321020000780007C456@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Apr 2012 10:46:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
In-Reply-To: <4F7ABBC4.4050106@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
> With your new behaviour it will no longer possible to specify an
> unlimited balloon but a limited number of initial pages.  This is
> behaviour that Jan said he used.

An unlimited balloon was never possible afaict (as that would have
implied setting up an "infinite" number of struct page instances at
boot time.

What I'm using is "dom0_mem=-<num>M" together with the kernel
option "mem=<num>G", such that max-balloon > initial alloc (usually
I set max-balloon to approximately the amount of memory in the
system, so the upper limit is "infinite" in the sense that I can't go
higher anyway, but it's not truly infinity).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:55:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0Rj-0004R0-8v; Tue, 03 Apr 2012 09:54:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SF0Ri-0004Qv-56
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:54:38 +0000
Received: from [85.158.143.35:20940] by server-3.bemta-4.messagelabs.com id
	F0/91-05853-DD8CA7F4; Tue, 03 Apr 2012 09:54:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333446875!16928208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9639 invoked from network); 3 Apr 2012 09:54:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 09:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="188778144"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 05:54:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 05:54:34 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SF0Re-0006TQ-3c;
	Tue, 03 Apr 2012 10:54:34 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 3 Apr 2012 10:54:28 +0100
Message-ID: <1333446868-11463-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] docs: clarify documentation for the the
	dom0_mem command line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
This addresses Ian C's comments on v1 of a previous patch (which
was applied instead of v2).
---
 docs/misc/xen-command-line.markdown |   22 +++++++++++++++-------
 1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index c697d68..fb78afe 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -222,19 +222,27 @@ Specify the total size for dom0.
 > `= List of ( min:<size> | max:<size> | <size> )`
 
 Set the amount of memory for the initial domain (dom0). If a size is
-positive, it represents an absolute value.  If a size is negative, the
-size specified is subtracted from the total available memory.
+positive, it represents an absolute value.  If a size is negative, it
+is subtracted from the total available memory.
 
-* `min:<size>` specifies the minimum amount of memory allocated to dom0.
-* `max:<size>` specifies the maximum amount of memory allocated to dom0.
-* `<size>` specified the exact amount of memory allocated to dom0.
+* `<size>` specifies the exact amount of memory.
+* `min:<size>` specifies the minimum amount of memory.
+* `max:<size>` specifies the maximum amount of memory.
+
+If `<size>` is not specified, the default is all the available memory
+minus some reserve.  The reserve is 1/16 of the available memory or
+128 MB (whichever is smaller).
+
+The amount of memory will be at least the minimum but never more than
+the maximum (i.e., `max` overrides the `min` option).  If there isn't
+enough memory then as much as possible is allocated.
 
 `max:<size>` also sets the maximum reservation (the maximum amount of
 memory dom0 can balloon up to).  If this is omitted then the maximum
 reservation is unlimited.
 
-For example, to set dom0's memory to 512 MB but no more than 1 GB use
-`dom0_mem=512M,max:1G`.
+For example, to set dom0's initial memory allocation to 512MB but
+allow it to balloon up as far as 1GB use `dom0_mem=512M,max:1G`
 
 ### dom0\_shadow
 ### dom0\_vcpus\_pin
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 09:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 09:55:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0Rj-0004R0-8v; Tue, 03 Apr 2012 09:54:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SF0Ri-0004Qv-56
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 09:54:38 +0000
Received: from [85.158.143.35:20940] by server-3.bemta-4.messagelabs.com id
	F0/91-05853-DD8CA7F4; Tue, 03 Apr 2012 09:54:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333446875!16928208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9639 invoked from network); 3 Apr 2012 09:54:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 09:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="188778144"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 05:54:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 05:54:34 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SF0Re-0006TQ-3c;
	Tue, 03 Apr 2012 10:54:34 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 3 Apr 2012 10:54:28 +0100
Message-ID: <1333446868-11463-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] docs: clarify documentation for the the
	dom0_mem command line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
This addresses Ian C's comments on v1 of a previous patch (which
was applied instead of v2).
---
 docs/misc/xen-command-line.markdown |   22 +++++++++++++++-------
 1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index c697d68..fb78afe 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -222,19 +222,27 @@ Specify the total size for dom0.
 > `= List of ( min:<size> | max:<size> | <size> )`
 
 Set the amount of memory for the initial domain (dom0). If a size is
-positive, it represents an absolute value.  If a size is negative, the
-size specified is subtracted from the total available memory.
+positive, it represents an absolute value.  If a size is negative, it
+is subtracted from the total available memory.
 
-* `min:<size>` specifies the minimum amount of memory allocated to dom0.
-* `max:<size>` specifies the maximum amount of memory allocated to dom0.
-* `<size>` specified the exact amount of memory allocated to dom0.
+* `<size>` specifies the exact amount of memory.
+* `min:<size>` specifies the minimum amount of memory.
+* `max:<size>` specifies the maximum amount of memory.
+
+If `<size>` is not specified, the default is all the available memory
+minus some reserve.  The reserve is 1/16 of the available memory or
+128 MB (whichever is smaller).
+
+The amount of memory will be at least the minimum but never more than
+the maximum (i.e., `max` overrides the `min` option).  If there isn't
+enough memory then as much as possible is allocated.
 
 `max:<size>` also sets the maximum reservation (the maximum amount of
 memory dom0 can balloon up to).  If this is omitted then the maximum
 reservation is unlimited.
 
-For example, to set dom0's memory to 512 MB but no more than 1 GB use
-`dom0_mem=512M,max:1G`.
+For example, to set dom0's initial memory allocation to 512MB but
+allow it to balloon up as far as 1GB use `dom0_mem=512M,max:1G`
 
 ### dom0\_shadow
 ### dom0\_vcpus\_pin
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:04:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:04:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0aZ-0004eM-93; Tue, 03 Apr 2012 10:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF0aX-0004eE-GV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:03:45 +0000
Received: from [85.158.143.35:14392] by server-2.bemta-4.messagelabs.com id
	AE/F9-17550-00BCA7F4; Tue, 03 Apr 2012 10:03:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333447422!5408716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13498 invoked from network); 3 Apr 2012 10:03:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:03:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11740974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:03:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:03:42 +0100
Date: Tue, 3 Apr 2012 11:05:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.56773.8058.87028@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> > For the support of multiple ioreq server, we add a new option "device_models".
> > It's an array of device model, for each device model, we need to specify
> > which pci, IO range (MMIO, PIO) will be allow.
> 
> I don't think this is really a suitable interface.  The PCI space in
> the guest is controlled by the device models(s) and the user should
> surely specify which devices should be provided by which dms, in terms
> of devices not in terms of PCI space.
 
Julien added a name parameter to select the device, maybe we need
something clearer?
Specifying the PCI address is important, because we have to make sure
the PCI addresses of the devices remain the same in a given VM across
multiple boots.
Thus we could make it optional from the user POV, but in that case we
need a clear, well defined and stable algorithm in xl to figure out a
PCI address from a given config file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:04:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:04:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0aZ-0004eM-93; Tue, 03 Apr 2012 10:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF0aX-0004eE-GV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:03:45 +0000
Received: from [85.158.143.35:14392] by server-2.bemta-4.messagelabs.com id
	AE/F9-17550-00BCA7F4; Tue, 03 Apr 2012 10:03:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333447422!5408716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13498 invoked from network); 3 Apr 2012 10:03:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:03:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11740974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:03:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:03:42 +0100
Date: Tue, 3 Apr 2012 11:05:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.56773.8058.87028@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> > For the support of multiple ioreq server, we add a new option "device_models".
> > It's an array of device model, for each device model, we need to specify
> > which pci, IO range (MMIO, PIO) will be allow.
> 
> I don't think this is really a suitable interface.  The PCI space in
> the guest is controlled by the device models(s) and the user should
> surely specify which devices should be provided by which dms, in terms
> of devices not in terms of PCI space.
 
Julien added a name parameter to select the device, maybe we need
something clearer?
Specifying the PCI address is important, because we have to make sure
the PCI addresses of the devices remain the same in a given VM across
multiple boots.
Thus we could make it optional from the user POV, but in that case we
need a clear, well defined and stable algorithm in xl to figure out a
PCI address from a given config file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:13:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0jy-0004oZ-9S; Tue, 03 Apr 2012 10:13:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0jv-0004oU-QV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:13:28 +0000
Received: from [85.158.139.83:19085] by server-6.bemta-5.messagelabs.com id
	5B/BC-13222-64DCA7F4; Tue, 03 Apr 2012 10:13:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333448003!22244634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7489 invoked from network); 3 Apr 2012 10:13:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:13:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:13:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:13:23 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SF0jr-0002uD-1D;
	Tue, 03 Apr 2012 10:13:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SF0jr-0000Du-07;
	Tue, 03 Apr 2012 11:13:23 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12550-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:13:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12550: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12550 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12550/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11890
 build-amd64                   4 xen-build                 fail REGR. vs. 11890
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 11890
 test-amd64-amd64-xl-win       7 windows-install  fail in 12547 REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12547

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12547 blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 12547 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12547 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 12547 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 12547 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12547 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 12547 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12547 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 12547 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 12547 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 12547 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 12547 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 12547 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 12547 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 12547 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12547 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 12547 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:13:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0jy-0004oZ-9S; Tue, 03 Apr 2012 10:13:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0jv-0004oU-QV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:13:28 +0000
Received: from [85.158.139.83:19085] by server-6.bemta-5.messagelabs.com id
	5B/BC-13222-64DCA7F4; Tue, 03 Apr 2012 10:13:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333448003!22244634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7489 invoked from network); 3 Apr 2012 10:13:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:13:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:13:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:13:23 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SF0jr-0002uD-1D;
	Tue, 03 Apr 2012 10:13:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SF0jr-0000Du-07;
	Tue, 03 Apr 2012 11:13:23 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12550-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:13:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12550: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12550 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12550/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11890
 build-amd64                   4 xen-build                 fail REGR. vs. 11890
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 11890
 test-amd64-amd64-xl-win       7 windows-install  fail in 12547 REGR. vs. 11890

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 12547

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12547 blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 12547 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12547 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 12547 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 12547 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12547 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 12547 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12547 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 12547 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 12547 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 12547 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 12547 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 12547 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 12547 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 12547 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12547 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 12547 never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:17:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:17:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0nV-0004wz-2g; Tue, 03 Apr 2012 10:17:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0nT-0004ws-TC
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:17:08 +0000
Received: from [85.158.139.83:61051] by server-1.bemta-5.messagelabs.com id
	6F/17-28458-32ECA7F4; Tue, 03 Apr 2012 10:17:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333448226!10973715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3756 invoked from network); 3 Apr 2012 10:17:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:17:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:17:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:17:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0nR-0002va-Rc; Tue, 03 Apr 2012 10:17:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0nR-0003dG-O3;
	Tue, 03 Apr 2012 11:17:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.52769.467099.774244@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:17:05 +0100
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
In-Reply-To: <CAOzFzEir5jDuUVoVN8TRGbQy344CDM30q9L6CzpwyDgnu8M_Yw@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
	<20345.48891.162276.828728@mariner.uk.xensource.com>
	<CAOzFzEir5jDuUVoVN8TRGbQy344CDM30q9L6CzpwyDgnu8M_Yw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Joseph Glanville writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> [stuff]

Thanks for your reply.

> What is your call about moving this stuff into domain_create rather
> than libxl_domain_config?

I think that would be correct.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:17:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:17:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0nV-0004wz-2g; Tue, 03 Apr 2012 10:17:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0nT-0004ws-TC
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:17:08 +0000
Received: from [85.158.139.83:61051] by server-1.bemta-5.messagelabs.com id
	6F/17-28458-32ECA7F4; Tue, 03 Apr 2012 10:17:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333448226!10973715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3756 invoked from network); 3 Apr 2012 10:17:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:17:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:17:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:17:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0nR-0002va-Rc; Tue, 03 Apr 2012 10:17:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0nR-0003dG-O3;
	Tue, 03 Apr 2012 11:17:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.52769.467099.774244@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:17:05 +0100
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
In-Reply-To: <CAOzFzEir5jDuUVoVN8TRGbQy344CDM30q9L6CzpwyDgnu8M_Yw@mail.gmail.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<CAOzFzEjLMCx4E9e-dfWXZHwVv+D4csKFKfvCTeb4oQt7jANJzg@mail.gmail.com>
	<CAOzFzEjWJ3UssJxxvL8714hnGMMKU8rY96EQaZgFFXgTxtj=Lg@mail.gmail.com>
	<20345.48891.162276.828728@mariner.uk.xensource.com>
	<CAOzFzEir5jDuUVoVN8TRGbQy344CDM30q9L6CzpwyDgnu8M_Yw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Joseph Glanville writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> [stuff]

Thanks for your reply.

> What is your call about moving this stuff into domain_create rather
> than libxl_domain_config?

I think that would be correct.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:19:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0pA-00053T-Ic; Tue, 03 Apr 2012 10:18:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF0p9-00053K-8w
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:18:51 +0000
Received: from [85.158.143.99:19100] by server-2.bemta-4.messagelabs.com id
	85/4A-17550-A8ECA7F4; Tue, 03 Apr 2012 10:18:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333448329!16820301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26079 invoked from network); 3 Apr 2012 10:18:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:18:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:18:48 +0100
Message-ID: <1333448319.25602.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:18:39 +0100
In-Reply-To: <20341.48435.384005.523480@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-03-30 at 15:03 +0100, Ian Jackson wrote:
> Indeed I think it's arguably a mistake that the on_{poweroff,...}
> items are in libxl_domain_config rather than in something provided in
> xl.

If we're going to change that we should do it before the API gets
declared stable in 4.2...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:19:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0pA-00053T-Ic; Tue, 03 Apr 2012 10:18:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF0p9-00053K-8w
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:18:51 +0000
Received: from [85.158.143.99:19100] by server-2.bemta-4.messagelabs.com id
	85/4A-17550-A8ECA7F4; Tue, 03 Apr 2012 10:18:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333448329!16820301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26079 invoked from network); 3 Apr 2012 10:18:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:18:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:18:48 +0100
Message-ID: <1333448319.25602.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:18:39 +0100
In-Reply-To: <20341.48435.384005.523480@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-03-30 at 15:03 +0100, Ian Jackson wrote:
> Indeed I think it's arguably a mistake that the on_{poweroff,...}
> items are in libxl_domain_config rather than in something provided in
> xl.

If we're going to change that we should do it before the API gets
declared stable in 4.2...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:20:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0qX-00059x-1n; Tue, 03 Apr 2012 10:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0qW-00059q-6g
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:20:16 +0000
Received: from [85.158.143.99:29997] by server-3.bemta-4.messagelabs.com id
	75/1E-05853-FDECA7F4; Tue, 03 Apr 2012 10:20:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333448413!22117939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24679 invoked from network); 3 Apr 2012 10:20:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:20:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:20:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:20:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0qN-0002wl-MU; Tue, 03 Apr 2012 10:20:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0qN-0003di-La;
	Tue, 03 Apr 2012 11:20:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.52951.652228.376946@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:20:07 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120402195425.GA21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> This is from xen itself:
> .. -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement ..

Yes.  That's the default for code in the Xen tree.  But it can be
locally overridden.  See the libxl Makefile for an example.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:20:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0qX-00059x-1n; Tue, 03 Apr 2012 10:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0qW-00059q-6g
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:20:16 +0000
Received: from [85.158.143.99:29997] by server-3.bemta-4.messagelabs.com id
	75/1E-05853-FDECA7F4; Tue, 03 Apr 2012 10:20:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333448413!22117939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24679 invoked from network); 3 Apr 2012 10:20:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:20:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:20:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:20:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0qN-0002wl-MU; Tue, 03 Apr 2012 10:20:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0qN-0003di-La;
	Tue, 03 Apr 2012 11:20:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.52951.652228.376946@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:20:07 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120402195425.GA21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> This is from xen itself:
> .. -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement ..

Yes.  That's the default for code in the Xen tree.  But it can be
locally overridden.  See the libxl Makefile for an example.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:21:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0rk-0005Go-IY; Tue, 03 Apr 2012 10:21:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0rj-0005Gf-IJ
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:21:31 +0000
Received: from [85.158.139.83:52869] by server-12.bemta-5.messagelabs.com id
	3D/B5-05587-A2FCA7F4; Tue, 03 Apr 2012 10:21:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333448489!19536802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 3 Apr 2012 10:21:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:21:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:21:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0rI-0002wz-QP; Tue, 03 Apr 2012 10:21:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0rI-0003do-Pe;
	Tue, 03 Apr 2012 11:21:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53008.699102.318350@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:21:04 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120402195816.GB21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> On Mon, Apr 02, Ian Jackson wrote:
> > There is nothing wrong with zero-length format strings.  This warning
> > should be disabled.  Please do send a patch to do so.
> 
> -Wno-format-zero-length -Wall has no effect, and -Wall comes from
> RPM_OPT_FLAGS which will come last with my current EXTRA_CFLAGS patch.

Every occurrence of -Wall should have -Wno-format-zero-length
appended.  There is no reason ever to warn about zero-length format
strings and it is a mystery why it's still the default.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:21:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0rk-0005Go-IY; Tue, 03 Apr 2012 10:21:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0rj-0005Gf-IJ
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:21:31 +0000
Received: from [85.158.139.83:52869] by server-12.bemta-5.messagelabs.com id
	3D/B5-05587-A2FCA7F4; Tue, 03 Apr 2012 10:21:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333448489!19536802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 3 Apr 2012 10:21:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:21:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:21:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0rI-0002wz-QP; Tue, 03 Apr 2012 10:21:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0rI-0003do-Pe;
	Tue, 03 Apr 2012 11:21:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53008.699102.318350@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:21:04 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120402195816.GB21392@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> On Mon, Apr 02, Ian Jackson wrote:
> > There is nothing wrong with zero-length format strings.  This warning
> > should be disabled.  Please do send a patch to do so.
> 
> -Wno-format-zero-length -Wall has no effect, and -Wall comes from
> RPM_OPT_FLAGS which will come last with my current EXTRA_CFLAGS patch.

Every occurrence of -Wall should have -Wno-format-zero-length
appended.  There is no reason ever to warn about zero-length format
strings and it is a mystery why it's still the default.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:25:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0vZ-0005X0-BV; Tue, 03 Apr 2012 10:25:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0vX-0005Wn-Gd
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:25:27 +0000
Received: from [85.158.139.83:40754] by server-5.bemta-5.messagelabs.com id
	BB/EE-13566-510DA7F4; Tue, 03 Apr 2012 10:25:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333448724!18359271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16096 invoked from network); 3 Apr 2012 10:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:25:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:25:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0v9-0002yX-7W; Tue, 03 Apr 2012 10:25:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0v9-0003dz-6U;
	Tue, 03 Apr 2012 11:25:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53247.182217.288605@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:25:03 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <3d15aa971865cf18dac4.1333397737@probook.site>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> tools/libvchan: fix build errors caused by Werror in io.c
...
> io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
...
> -		writev(-1, iov, 2);
> +		/* Silence gcc warning, will always fail */
> +		if (writev(-1, iov, 2));

I still think this is an unpleasant idiom.  Does casting the result to
void not help ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:25:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0vZ-0005X0-BV; Tue, 03 Apr 2012 10:25:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0vX-0005Wn-Gd
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:25:27 +0000
Received: from [85.158.139.83:40754] by server-5.bemta-5.messagelabs.com id
	BB/EE-13566-510DA7F4; Tue, 03 Apr 2012 10:25:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333448724!18359271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16096 invoked from network); 3 Apr 2012 10:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:25:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:25:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0v9-0002yX-7W; Tue, 03 Apr 2012 10:25:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0v9-0003dz-6U;
	Tue, 03 Apr 2012 11:25:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53247.182217.288605@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:25:03 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <3d15aa971865cf18dac4.1333397737@probook.site>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> tools/libvchan: fix build errors caused by Werror in io.c
...
> io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
...
> -		writev(-1, iov, 2);
> +		/* Silence gcc warning, will always fail */
> +		if (writev(-1, iov, 2));

I still think this is an unpleasant idiom.  Does casting the result to
void not help ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:27:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0x8-0005dd-VM; Tue, 03 Apr 2012 10:27:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0x8-0005dX-9I
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:27:06 +0000
Received: from [85.158.138.51:44255] by server-9.bemta-3.messagelabs.com id
	32/A7-10923-970DA7F4; Tue, 03 Apr 2012 10:27:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333448824!20415114!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14788 invoked from network); 3 Apr 2012 10:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:27:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:27:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0x6-0002zU-5X; Tue, 03 Apr 2012 10:27:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0x6-0003eB-4X;
	Tue, 03 Apr 2012 11:27:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53368.124059.639281@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:27:04 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120403090748.GA27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
	<1333441383.25602.105.camel@zakaz.uk.xensource.com>
	<20120403090748.GA27810@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> On Tue, Apr 03, Ian Campbell wrote:
...
> > However skimming over node-select.c and io.c (as another random file) it
> > looks like the use of mixed declarations and code is the exception not
> > the rule even within libvchan, so I think it would be fine to fix the
> > two places where this isn't the case.
> 
> If thats ok with IanJ as well, I will prepare another patch to fix just
> that warning in node-select.c

That's fine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:27:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0x8-0005dd-VM; Tue, 03 Apr 2012 10:27:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0x8-0005dX-9I
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:27:06 +0000
Received: from [85.158.138.51:44255] by server-9.bemta-3.messagelabs.com id
	32/A7-10923-970DA7F4; Tue, 03 Apr 2012 10:27:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333448824!20415114!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14788 invoked from network); 3 Apr 2012 10:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:27:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:27:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0x6-0002zU-5X; Tue, 03 Apr 2012 10:27:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0x6-0003eB-4X;
	Tue, 03 Apr 2012 11:27:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53368.124059.639281@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:27:04 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120403090748.GA27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<1092e073b88e0aed775e.1333095927@probook.site>
	<20345.45252.747454.411523@mariner.uk.xensource.com>
	<20120402195425.GA21392@aepfle.de>
	<1333441383.25602.105.camel@zakaz.uk.xensource.com>
	<20120403090748.GA27810@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors
 caused by -Werror in node-select.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 10 of 18] tools/libvchan: fix build errors caused by -Werror in node-select.c"):
> On Tue, Apr 03, Ian Campbell wrote:
...
> > However skimming over node-select.c and io.c (as another random file) it
> > looks like the use of mixed declarations and code is the exception not
> > the rule even within libvchan, so I think it would be fine to fix the
> > two places where this isn't the case.
> 
> If thats ok with IanJ as well, I will prepare another patch to fix just
> that warning in node-select.c

That's fine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0y5-0005is-F8; Tue, 03 Apr 2012 10:28:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0y4-0005ih-IV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:28:04 +0000
Received: from [85.158.143.99:30829] by server-1.bemta-4.messagelabs.com id
	A0/4C-20925-3B0DA7F4; Tue, 03 Apr 2012 10:28:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333448883!18723326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31468 invoked from network); 3 Apr 2012 10:28:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:28:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:28:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:28:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0y2-0002zp-57; Tue, 03 Apr 2012 10:28:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0y2-0003eS-4Q;
	Tue, 03 Apr 2012 11:28:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53426.122768.64462@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:28:02 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120403091126.GB27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
	<1333441832.25602.112.camel@zakaz.uk.xensource.com>
	<20120403091126.GB27810@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> On Tue, Apr 03, Ian Campbell wrote:
> > [0] Even gcc(1) says:
> >        -Wno-format-zero-length (C and Objective-C only)
> >            If -Wformat is specified, do not warn about zero-length formats.
> >            The C standard specifies that zero-length formats are allowed.
> > So quite why it appears that Wall is enabling Wformat-zero-length I have
> > no idea, this is a clear gcc bug in my opinion.
> 
> Thats what they say:
> 
> "<jakub> olaf_: warnings aren't just about things that aren't allowed in
> the standard, but about things considered bad by significant amount of
> users"
> 
> So gcc wont be changed.

I haven't found anyone who can come up with a plausible reason to
think that a zero-length format string is wrong.  But I don't want to
get into an argument with gcc upstream.

The right answer is to disable the warning, wherever it is being
enabled.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0y5-0005is-F8; Tue, 03 Apr 2012 10:28:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF0y4-0005ih-IV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:28:04 +0000
Received: from [85.158.143.99:30829] by server-1.bemta-4.messagelabs.com id
	A0/4C-20925-3B0DA7F4; Tue, 03 Apr 2012 10:28:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333448883!18723326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31468 invoked from network); 3 Apr 2012 10:28:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:28:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:28:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:28:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF0y2-0002zp-57; Tue, 03 Apr 2012 10:28:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF0y2-0003eS-4Q;
	Tue, 03 Apr 2012 11:28:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53426.122768.64462@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:28:02 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120403091126.GB27810@aepfle.de>
References: <patchbomb.1333095917@probook.site>
	<46ec38b96a225eadcadd.1333095928@probook.site>
	<20345.44861.163125.224414@mariner.uk.xensource.com>
	<20120402195816.GB21392@aepfle.de>
	<1333441832.25602.112.camel@zakaz.uk.xensource.com>
	<20120403091126.GB27810@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors
 caused by Werror in disk_eject_xswatch_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH 11 of 18] tools/libxl: fix build errors caused by Werror in disk_eject_xswatch_callback"):
> On Tue, Apr 03, Ian Campbell wrote:
> > [0] Even gcc(1) says:
> >        -Wno-format-zero-length (C and Objective-C only)
> >            If -Wformat is specified, do not warn about zero-length formats.
> >            The C standard specifies that zero-length formats are allowed.
> > So quite why it appears that Wall is enabling Wformat-zero-length I have
> > no idea, this is a clear gcc bug in my opinion.
> 
> Thats what they say:
> 
> "<jakub> olaf_: warnings aren't just about things that aren't allowed in
> the standard, but about things considered bad by significant amount of
> users"
> 
> So gcc wont be changed.

I haven't found anyone who can come up with a plausible reason to
think that a zero-length format string is wrong.  But I don't want to
get into an argument with gcc upstream.

The right answer is to disable the warning, wherever it is being
enabled.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:28:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0yN-0005lI-SI; Tue, 03 Apr 2012 10:28:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF0yM-0005l5-OH
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:28:22 +0000
Received: from [85.158.143.99:15009] by server-1.bemta-4.messagelabs.com id
	FD/DC-20925-6C0DA7F4; Tue, 03 Apr 2012 10:28:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333448901!16822675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15421 invoked from network); 3 Apr 2012 10:28:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:28:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:28:20 +0100
Date: Tue, 3 Apr 2012 11:30:31 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
In-Reply-To: <CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204031125300.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Lars Kurth <lars.kurth@xen.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Joseph Glanville wrote:
> On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> >> Hi guys,
> >>
> >> I have started preparing a library of PV-HVM templates for use on Xen
> >> 4.X+ and PVOPS dom0.
> > [...]
> >> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> >> (the final beta, will be updated to final shortly).
> >> Included is an OS image, a config file, a README and the associated
> >> licences etc.
> >
> > This is very cool, and you are correct that these will be very useful
> > for people trying to get something going quickly! Thanks Joseph.
> 
> No problem, I am working on a new dom0 livecd too.
> 
> I need some recommendations on what distro to base it on though...
> Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
> to be more enduring and a more beginner approachable alternative.
> 
> Does anyone have any thoughts on this?

I would definitely keep Ubuntu and maybe add OpenSUSE

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:28:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF0yN-0005lI-SI; Tue, 03 Apr 2012 10:28:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF0yM-0005l5-OH
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:28:22 +0000
Received: from [85.158.143.99:15009] by server-1.bemta-4.messagelabs.com id
	FD/DC-20925-6C0DA7F4; Tue, 03 Apr 2012 10:28:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333448901!16822675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15421 invoked from network); 3 Apr 2012 10:28:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:28:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:28:20 +0100
Date: Tue, 3 Apr 2012 11:30:31 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
In-Reply-To: <CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204031125300.15151@kaball-desktop>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Lars Kurth <lars.kurth@xen.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Joseph Glanville wrote:
> On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> >> Hi guys,
> >>
> >> I have started preparing a library of PV-HVM templates for use on Xen
> >> 4.X+ and PVOPS dom0.
> > [...]
> >> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> >> (the final beta, will be updated to final shortly).
> >> Included is an OS image, a config file, a README and the associated
> >> licences etc.
> >
> > This is very cool, and you are correct that these will be very useful
> > for people trying to get something going quickly! Thanks Joseph.
> 
> No problem, I am working on a new dom0 livecd too.
> 
> I need some recommendations on what distro to base it on though...
> Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
> to be more enduring and a more beginner approachable alternative.
> 
> Does anyone have any thoughts on this?

I would definitely keep Ubuntu and maybe add OpenSUSE

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:31:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF10m-00068A-3B; Tue, 03 Apr 2012 10:30:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF10k-00067u-V6
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:30:51 +0000
Received: from [85.158.138.51:17225] by server-9.bemta-3.messagelabs.com id
	23/11-10923-A51DA7F4; Tue, 03 Apr 2012 10:30:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333449048!20556726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1156 invoked from network); 3 Apr 2012 10:30:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:30:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:30:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:30:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF10h-00030s-Qx; Tue, 03 Apr 2012 10:30:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF10h-0003ea-Py;
	Tue, 03 Apr 2012 11:30:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53591.785495.754183@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:30:47 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333448319.25602.122.camel@zakaz.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> On Fri, 2012-03-30 at 15:03 +0100, Ian Jackson wrote:
> > Indeed I think it's arguably a mistake that the on_{poweroff,...}
> > items are in libxl_domain_config rather than in something provided in
> > xl.
> 
> If we're going to change that we should do it before the API gets
> declared stable in 4.2...

Yes.  Do you agree with my opinion that they should be moved ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:31:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF10m-00068A-3B; Tue, 03 Apr 2012 10:30:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF10k-00067u-V6
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:30:51 +0000
Received: from [85.158.138.51:17225] by server-9.bemta-3.messagelabs.com id
	23/11-10923-A51DA7F4; Tue, 03 Apr 2012 10:30:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333449048!20556726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1156 invoked from network); 3 Apr 2012 10:30:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:30:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11741663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:30:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:30:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF10h-00030s-Qx; Tue, 03 Apr 2012 10:30:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF10h-0003ea-Py;
	Tue, 03 Apr 2012 11:30:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.53591.785495.754183@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:30:47 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333448319.25602.122.camel@zakaz.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> On Fri, 2012-03-30 at 15:03 +0100, Ian Jackson wrote:
> > Indeed I think it's arguably a mistake that the on_{poweroff,...}
> > items are in libxl_domain_config rather than in something provided in
> > xl.
> 
> If we're going to change that we should do it before the API gets
> declared stable in 4.2...

Yes.  Do you agree with my opinion that they should be moved ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:44:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1DG-0006dZ-Gu; Tue, 03 Apr 2012 10:43:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1DE-0006dQ-Jl
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:43:44 +0000
Received: from [85.158.143.99:33933] by server-3.bemta-4.messagelabs.com id
	E6/51-05853-F54DA7F4; Tue, 03 Apr 2012 10:43:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333449823!22058395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10219 invoked from network); 3 Apr 2012 10:43:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:43:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:43:42 +0100
Message-ID: <1333449808.25602.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:43:28 +0100
In-Reply-To: <20346.53591.785495.754183@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
	<20346.53591.785495.754183@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 11:30 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> > On Fri, 2012-03-30 at 15:03 +0100, Ian Jackson wrote:
> > > Indeed I think it's arguably a mistake that the on_{poweroff,...}
> > > items are in libxl_domain_config rather than in something provided in
> > > xl.
> > 
> > If we're going to change that we should do it before the API gets
> > declared stable in 4.2...
> 
> Yes.  Do you agree with my opinion that they should be moved ?

It seems reasonable to err on the side of not including things in the
API initially.

The enum itself could be moved too but the IDL provided functions for
the Enum are quite handy, it'd be a shame to lose them and I'm not sure
how well the IDL will function for non-libxl use -- it uses some
internal functions of which libxl__enum_from_string is of particular
interest here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:44:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1DG-0006dZ-Gu; Tue, 03 Apr 2012 10:43:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1DE-0006dQ-Jl
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:43:44 +0000
Received: from [85.158.143.99:33933] by server-3.bemta-4.messagelabs.com id
	E6/51-05853-F54DA7F4; Tue, 03 Apr 2012 10:43:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333449823!22058395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10219 invoked from network); 3 Apr 2012 10:43:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:43:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:43:42 +0100
Message-ID: <1333449808.25602.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:43:28 +0100
In-Reply-To: <20346.53591.785495.754183@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
	<20346.53591.785495.754183@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 11:30 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> > On Fri, 2012-03-30 at 15:03 +0100, Ian Jackson wrote:
> > > Indeed I think it's arguably a mistake that the on_{poweroff,...}
> > > items are in libxl_domain_config rather than in something provided in
> > > xl.
> > 
> > If we're going to change that we should do it before the API gets
> > declared stable in 4.2...
> 
> Yes.  Do you agree with my opinion that they should be moved ?

It seems reasonable to err on the side of not including things in the
API initially.

The enum itself could be moved too but the IDL provided functions for
the Enum are quite handy, it'd be a shame to lose them and I'm not sure
how well the IDL will function for non-libxl use -- it uses some
internal functions of which libxl__enum_from_string is of particular
interest here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1Gp-0006nf-90; Tue, 03 Apr 2012 10:47:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF1Go-0006nX-Cu
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:47:26 +0000
Received: from [85.158.143.35:2230] by server-3.bemta-4.messagelabs.com id
	26/0A-05853-D35DA7F4; Tue, 03 Apr 2012 10:47:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333450044!7192432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11843 invoked from network); 3 Apr 2012 10:47:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:47:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:47:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF1Gl-0003A4-MG; Tue, 03 Apr 2012 10:47:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF1Gl-0003g2-LE;
	Tue, 03 Apr 2012 11:47:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.54587.632580.646439@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:47:23 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333449808.25602.127.camel@zakaz.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
	<20346.53591.785495.754183@mariner.uk.xensource.com>
	<1333449808.25602.127.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> The enum itself could be moved too but the IDL provided functions for
> the Enum are quite handy, it'd be a shame to lose them and I'm not sure
> how well the IDL will function for non-libxl use -- it uses some
> internal functions of which libxl__enum_from_string is of particular
> interest here.

Can libxl__enum_from_string be made public ?  Or is this too much of a
ball of string ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1Gp-0006nf-90; Tue, 03 Apr 2012 10:47:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF1Go-0006nX-Cu
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:47:26 +0000
Received: from [85.158.143.35:2230] by server-3.bemta-4.messagelabs.com id
	26/0A-05853-D35DA7F4; Tue, 03 Apr 2012 10:47:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333450044!7192432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11843 invoked from network); 3 Apr 2012 10:47:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:47:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 11:47:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF1Gl-0003A4-MG; Tue, 03 Apr 2012 10:47:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF1Gl-0003g2-LE;
	Tue, 03 Apr 2012 11:47:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.54587.632580.646439@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 11:47:23 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333449808.25602.127.camel@zakaz.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
	<20346.53591.785495.754183@mariner.uk.xensource.com>
	<1333449808.25602.127.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> The enum itself could be moved too but the IDL provided functions for
> the Enum are quite handy, it'd be a shame to lose them and I'm not sure
> how well the IDL will function for non-libxl use -- it uses some
> internal functions of which libxl__enum_from_string is of particular
> interest here.

Can libxl__enum_from_string be made public ?  Or is this too much of a
ball of string ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:47:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1Gr-0006o5-Lb; Tue, 03 Apr 2012 10:47:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1Gq-0006nt-Qg
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:47:29 +0000
Received: from [85.158.143.35:37694] by server-2.bemta-4.messagelabs.com id
	32/16-17550-045DA7F4; Tue, 03 Apr 2012 10:47:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333450018!10781702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9036 invoked from network); 3 Apr 2012 10:46:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:46:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:46:57 +0100
Message-ID: <1333450007.25602.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Date: Tue, 3 Apr 2012 11:46:47 +0100
In-Reply-To: <CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 18:59 +0100, Joseph Glanville wrote:
> On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> >> Hi guys,
> >>
> >> I have started preparing a library of PV-HVM templates for use on Xen
> >> 4.X+ and PVOPS dom0.
> > [...]
> >> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> >> (the final beta, will be updated to final shortly).
> >> Included is an OS image, a config file, a README and the associated
> >> licences etc.
> >
> > This is very cool, and you are correct that these will be very useful
> > for people trying to get something going quickly! Thanks Joseph.
> 
> No problem, I am working on a new dom0 livecd too.
> 
> I need some recommendations on what distro to base it on though...
> Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
> to be more enduring and a more beginner approachable alternative.
> 
> Does anyone have any thoughts on this?

My personal preference would be Debian ;-) But pragmatically Ubuntu is,
I think, generally thought to be a good beginner distro and conveniently
it now contains support for Xen so that seems like a good choice.

Also on the plus side is that Ubuntu may well contain the "Debian Live"
packages/infrastructure which make building Live CDs easier (I presume,
I've never tried them). I don't know if that's actually what is used by
Ubuntu to make their live CDs, if not then I'd hope that infrastructure
was in Ubuntu too.

Ian.

> 
> >
> >> The images are bz2 compressed blockdevice images suitable for use on
> >> LVM or a file backed tapdisk if you have the appropriate backend.
> >> (alternatively you can use the loop device but this is discouraged)
> >> All images have serial console enabled, PV network and block devices,
> >> fixed udev rules etc.
> >>
> >> I will add more info about them, an FAQ about how they are setup and
> >> what you should do to customize them, expand the disk image etc soon.
> >>
> >> I am looking for someone to mirror these in the US for me, please
> >> email me if you have spare bandwith.
> >>
> >> Joseph.
> >>
> >
> >
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:47:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1Gr-0006o5-Lb; Tue, 03 Apr 2012 10:47:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1Gq-0006nt-Qg
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:47:29 +0000
Received: from [85.158.143.35:37694] by server-2.bemta-4.messagelabs.com id
	32/16-17550-045DA7F4; Tue, 03 Apr 2012 10:47:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333450018!10781702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9036 invoked from network); 3 Apr 2012 10:46:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:46:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:46:57 +0100
Message-ID: <1333450007.25602.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Date: Tue, 3 Apr 2012 11:46:47 +0100
In-Reply-To: <CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "staff@orionvm.com.au" <staff@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-02 at 18:59 +0100, Joseph Glanville wrote:
> On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> >> Hi guys,
> >>
> >> I have started preparing a library of PV-HVM templates for use on Xen
> >> 4.X+ and PVOPS dom0.
> > [...]
> >> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> >> (the final beta, will be updated to final shortly).
> >> Included is an OS image, a config file, a README and the associated
> >> licences etc.
> >
> > This is very cool, and you are correct that these will be very useful
> > for people trying to get something going quickly! Thanks Joseph.
> 
> No problem, I am working on a new dom0 livecd too.
> 
> I need some recommendations on what distro to base it on though...
> Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
> to be more enduring and a more beginner approachable alternative.
> 
> Does anyone have any thoughts on this?

My personal preference would be Debian ;-) But pragmatically Ubuntu is,
I think, generally thought to be a good beginner distro and conveniently
it now contains support for Xen so that seems like a good choice.

Also on the plus side is that Ubuntu may well contain the "Debian Live"
packages/infrastructure which make building Live CDs easier (I presume,
I've never tried them). I don't know if that's actually what is used by
Ubuntu to make their live CDs, if not then I'd hope that infrastructure
was in Ubuntu too.

Ian.

> 
> >
> >> The images are bz2 compressed blockdevice images suitable for use on
> >> LVM or a file backed tapdisk if you have the appropriate backend.
> >> (alternatively you can use the loop device but this is discouraged)
> >> All images have serial console enabled, PV network and block devices,
> >> fixed udev rules etc.
> >>
> >> I will add more info about them, an FAQ about how they are setup and
> >> what you should do to customize them, expand the disk image etc soon.
> >>
> >> I am looking for someone to mirror these in the US for me, please
> >> email me if you have spare bandwith.
> >>
> >> Joseph.
> >>
> >
> >
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:50:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1Jp-0007BE-UF; Tue, 03 Apr 2012 10:50:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1Jp-0007B0-8H
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:50:33 +0000
Received: from [85.158.138.51:36955] by server-9.bemta-3.messagelabs.com id
	E4/50-10923-8F5DA7F4; Tue, 03 Apr 2012 10:50:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333450230!16366275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3702 invoked from network); 3 Apr 2012 10:50:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:50:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:50:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:50:29 +0100
Message-ID: <1333450222.25602.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:50:22 +0100
In-Reply-To: <20346.53247.182217.288605@mariner.uk.xensource.com>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
	<20346.53247.182217.288605@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 11:25 +0100, Ian Jackson wrote:
> Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > tools/libvchan: fix build errors caused by Werror in io.c
> ...
> > io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
> ...
> > -		writev(-1, iov, 2);
> > +		/* Silence gcc warning, will always fail */
> > +		if (writev(-1, iov, 2));
> 
> I still think this is an unpleasant idiom.  Does casting the result to
> void not help ?

What does writev(-1,...) even mean? Can we not just nuke it?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:50:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1Jp-0007BE-UF; Tue, 03 Apr 2012 10:50:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1Jp-0007B0-8H
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 10:50:33 +0000
Received: from [85.158.138.51:36955] by server-9.bemta-3.messagelabs.com id
	E4/50-10923-8F5DA7F4; Tue, 03 Apr 2012 10:50:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333450230!16366275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3702 invoked from network); 3 Apr 2012 10:50:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:50:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:50:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:50:29 +0100
Message-ID: <1333450222.25602.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:50:22 +0100
In-Reply-To: <20346.53247.182217.288605@mariner.uk.xensource.com>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
	<20346.53247.182217.288605@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 11:25 +0100, Ian Jackson wrote:
> Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > tools/libvchan: fix build errors caused by Werror in io.c
> ...
> > io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
> ...
> > -		writev(-1, iov, 2);
> > +		/* Silence gcc warning, will always fail */
> > +		if (writev(-1, iov, 2));
> 
> I still think this is an unpleasant idiom.  Does casting the result to
> void not help ?

What does writev(-1,...) even mean? Can we not just nuke it?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:57:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1QA-0007WT-QB; Tue, 03 Apr 2012 10:57:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1Q9-0007WO-5h
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:57:05 +0000
Received: from [85.158.143.99:16178] by server-1.bemta-4.messagelabs.com id
	06/98-20925-087DA7F4; Tue, 03 Apr 2012 10:57:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333450623!16379426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 3 Apr 2012 10:57:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:57:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:57:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:57:02 +0100
Message-ID: <1333450609.25602.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:56:49 +0100
In-Reply-To: <20346.54587.632580.646439@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
	<20346.53591.785495.754183@mariner.uk.xensource.com>
	<1333449808.25602.127.camel@zakaz.uk.xensource.com>
	<20346.54587.632580.646439@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 11:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> > The enum itself could be moved too but the IDL provided functions for
> > the Enum are quite handy, it'd be a shame to lose them and I'm not sure
> > how well the IDL will function for non-libxl use -- it uses some
> > internal functions of which libxl__enum_from_string is of particular
> > interest here.
> 
> Can libxl__enum_from_string be made public ?

I think that one is likely to be ok, it's pretty simple and self
contained.

There others are though, like libxl__object_to_json,
libxl__yajl_gen_enum and libxl__string_gen_json (I think that's all).
They'd need slightly more careful handling to restrict the exposure of
yajl stuff only to callers who explicitly ask for libxl_json.h.

> Or is this too much of a ball of string ?

That's my worry.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 10:57:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 10:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1QA-0007WT-QB; Tue, 03 Apr 2012 10:57:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF1Q9-0007WO-5h
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 10:57:05 +0000
Received: from [85.158.143.99:16178] by server-1.bemta-4.messagelabs.com id
	06/98-20925-087DA7F4; Tue, 03 Apr 2012 10:57:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333450623!16379426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 3 Apr 2012 10:57:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 10:57:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11742387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:57:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	11:57:02 +0100
Message-ID: <1333450609.25602.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 11:56:49 +0100
In-Reply-To: <20346.54587.632580.646439@mariner.uk.xensource.com>
References: <CAOzFzEiwsLb+2eh+gJmsEZa19g7huk1+zgswhEt5DUiR7bneSw@mail.gmail.com>
	<20341.48435.384005.523480@mariner.uk.xensource.com>
	<1333448319.25602.122.camel@zakaz.uk.xensource.com>
	<20346.53591.785495.754183@mariner.uk.xensource.com>
	<1333449808.25602.127.camel@zakaz.uk.xensource.com>
	<20346.54587.632580.646439@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 11:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [RFC] Shutdown event script for xl toolstack"):
> > The enum itself could be moved too but the IDL provided functions for
> > the Enum are quite handy, it'd be a shame to lose them and I'm not sure
> > how well the IDL will function for non-libxl use -- it uses some
> > internal functions of which libxl__enum_from_string is of particular
> > interest here.
> 
> Can libxl__enum_from_string be made public ?

I think that one is likely to be ok, it's pretty simple and self
contained.

There others are though, like libxl__object_to_json,
libxl__yajl_gen_enum and libxl__string_gen_json (I think that's all).
They'd need slightly more careful handling to restrict the exposure of
yajl stuff only to callers who explicitly ask for libxl_json.h.

> Or is this too much of a ball of string ?

That's my worry.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 11:23:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 11:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1p3-0007ny-VV; Tue, 03 Apr 2012 11:22:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF1p2-0007nq-4e
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 11:22:48 +0000
Received: from [85.158.138.51:12946] by server-7.bemta-3.messagelabs.com id
	9C/26-07528-78DDA7F4; Tue, 03 Apr 2012 11:22:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333452164!20533750!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26508 invoked from network); 3 Apr 2012 11:22:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 11:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="23813971"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 07:22:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 07:22:43 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SF1or-0007qx-RR; Tue, 03 Apr 2012 12:22:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 3 Apr 2012 12:25:02 +0100
Message-ID: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since when we are using the m2p_override it is not true anymore that the
mmap'ed area doesn't have corresponsing struct pages.

Removing the VM_PFNMAP flag makes get_user_pages work on the mmap'ed user vma.
An example test case would be using a Xen userspace block backend
(QDISK) on a file on NFS using O_DIRECT.

The patch should be backported back to 2.6.38.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/gntdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 99d8151..1ffd03b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
 	vma->vm_flags |= VM_RESERVED|VM_DONTEXPAND;
 
 	if (use_ptemod)
-		vma->vm_flags |= VM_DONTCOPY|VM_PFNMAP;
+		vma->vm_flags |= VM_DONTCOPY;
 
 	vma->vm_private_data = map;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 11:23:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 11:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF1p3-0007ny-VV; Tue, 03 Apr 2012 11:22:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF1p2-0007nq-4e
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 11:22:48 +0000
Received: from [85.158.138.51:12946] by server-7.bemta-3.messagelabs.com id
	9C/26-07528-78DDA7F4; Tue, 03 Apr 2012 11:22:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333452164!20533750!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26508 invoked from network); 3 Apr 2012 11:22:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 11:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="23813971"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 07:22:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 07:22:43 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SF1or-0007qx-RR; Tue, 03 Apr 2012 12:22:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 3 Apr 2012 12:25:02 +0100
Message-ID: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since when we are using the m2p_override it is not true anymore that the
mmap'ed area doesn't have corresponsing struct pages.

Removing the VM_PFNMAP flag makes get_user_pages work on the mmap'ed user vma.
An example test case would be using a Xen userspace block backend
(QDISK) on a file on NFS using O_DIRECT.

The patch should be backported back to 2.6.38.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/gntdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 99d8151..1ffd03b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
 	vma->vm_flags |= VM_RESERVED|VM_DONTEXPAND;
 
 	if (use_ptemod)
-		vma->vm_flags |= VM_DONTCOPY|VM_PFNMAP;
+		vma->vm_flags |= VM_DONTCOPY;
 
 	vma->vm_private_data = map;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 12:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 12:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF2Py-00085u-FP; Tue, 03 Apr 2012 12:00:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF2Pw-00085h-Nz
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 12:00:56 +0000
Received: from [85.158.143.35:47379] by server-1.bemta-4.messagelabs.com id
	69/49-20925-676EA7F4; Tue, 03 Apr 2012 12:00:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333454453!11630650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9130 invoked from network); 3 Apr 2012 12:00:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 12:00:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11743850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 12:00:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 13:00:53 +0100
Date: Tue, 3 Apr 2012 13:03:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.53580.464371.690500@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031302590.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.61376.319377.655549@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301144510.15151@kaball-desktop>
	<20345.53580.464371.690500@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: introduce
 libxl__device_generic_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/6] libxl: introduce libxl__device_generic_add_t"):
> > On Tue, 27 Mar 2012, Ian Jackson wrote:
> > > Can we avoid introducing more of these transaction loops using goto ?
> > 
> > I am afraid I actually prefer the simple goto scheme than the convoluted
> > code below.
> 
> I really can't stomach any more of these gotos.  If you don't want to
> abstract it away, can't you at least write the loop as a loop with
> for() or while() ?

Yes, I can do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 12:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 12:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF2Py-00085u-FP; Tue, 03 Apr 2012 12:00:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF2Pw-00085h-Nz
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 12:00:56 +0000
Received: from [85.158.143.35:47379] by server-1.bemta-4.messagelabs.com id
	69/49-20925-676EA7F4; Tue, 03 Apr 2012 12:00:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333454453!11630650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9130 invoked from network); 3 Apr 2012 12:00:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 12:00:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="11743850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 12:00:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 13:00:53 +0100
Date: Tue, 3 Apr 2012 13:03:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.53580.464371.690500@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031302590.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.61376.319377.655549@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301144510.15151@kaball-desktop>
	<20345.53580.464371.690500@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: introduce
 libxl__device_generic_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/6] libxl: introduce libxl__device_generic_add_t"):
> > On Tue, 27 Mar 2012, Ian Jackson wrote:
> > > Can we avoid introducing more of these transaction loops using goto ?
> > 
> > I am afraid I actually prefer the simple goto scheme than the convoluted
> > code below.
> 
> I really can't stomach any more of these gotos.  If you don't want to
> abstract it away, can't you at least write the loop as a loop with
> for() or while() ?

Yes, I can do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:04:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:04:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3P1-0008Ui-KQ; Tue, 03 Apr 2012 13:04:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tom.goetz@virtualcomputer.com>) id 1SF3Oz-0008Ud-BY
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:04:01 +0000
Received: from [85.158.138.51:7774] by server-4.bemta-3.messagelabs.com id
	EB/89-16467-045FA7F4; Tue, 03 Apr 2012 13:04:00 +0000
X-Env-Sender: tom.goetz@virtualcomputer.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333458238!20511081!1
X-Originating-IP: [72.32.253.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMzIuMjUzLjY4ID0+IDI0OTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30742 invoked from network); 3 Apr 2012 13:04:00 -0000
Received: from server514a.exghost.com (HELO server514.appriver.com)
	(72.32.253.68)
	by server-8.tower-174.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	3 Apr 2012 13:04:00 -0000
X-Note-AR-ScanTimeLocal: 4/3/2012 8:03:57 AM
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: Too many policies to list
X-Primary: tom.goetz@virtualcomputer.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @virtualcomputer.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed: 
X-Country-Path: UNITED STATES->UNITED STATES->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 72.32.253.65
X-Note-Reverse-DNS: 
X-Note-Return-Path: tom.goetz@virtualcomputer.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G237 G238 G239 G240 G244 G245 G256 G347 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [72.32.253.65] (HELO FE06.exg4.exghost.com)
	by server514.appriver.com (CommuniGate Pro SMTP 5.4.4)
	with ESMTP id 277728560; Tue, 03 Apr 2012 08:03:57 -0500
Received: from FE06.exg4.exghost.com ([72.32.253.161]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Apr 2012 08:03:57 -0500
Received: from orion.oldroadcomputing.net ([67.192.118.157]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Apr 2012 08:03:57 -0500
Mime-Version: 1.0 (Apple Message framework v1257)
From: Tom Goetz <tom.goetz@virtualcomputer.com>
In-Reply-To: <20120402152830.GA30162@phenom.dumpdata.com>
Date: Tue, 3 Apr 2012 09:03:55 -0400
Message-Id: <11F89DC1-8FA4-4A8D-A197-BE3B95B6BE41@virtualcomputer.com>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<75798a472b1a9121adda.1332610904@phenom.dumpdata.com>
	<4F7049E3020000780007AD63@nat28.tlf.novell.com>
	<20120402152830.GA30162@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 03 Apr 2012 13:03:57.0257 (UTC)
	FILETIME=[3ACA1390:01CD119A]
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, Jan Beulich <JBeulich@suse.com>,
	keir.fraser@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 6] xen/pat: After suspend re-write PAT
	if BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 2, 2012, at 11:28 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Mar 26, 2012 at 09:50:11AM +0100, Jan Beulich wrote:
>>>>> On 24.03.12 at 18:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>> # HG changeset patch
>>> # User Simon Graham <simon.graham@virtualcomputer.com>
>>> # Date 1332610898 14400
>>> # Node ID 75798a472b1a9121adda166b6fd05ba8473a44f0
>>> # Parent  d097c3ba42f601af65b53a0c84973855aab64aa9
>>> xen/pat: After suspend re-write PAT if BIOS changed it.
>>> 
>>> Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
>>> would reset the PAT MSR causing rather weird issues - where
>>> the pages would (say they would be set to WC) would end up with the
>>> wrong type (as they would use the BIOS PAT instead of the one set by
>>> the hypervisor).
>> 
>> There's a write of the PAT MSR already at the end of
>> restore_rest_processor_state() - are you saying this doesn't do
>> what is needed? Also note that this is properly gated by a check
>> of cpu_has_pat (other than the patch here does).
> 
> Let me double-check with folks at VirtualComputer - but they had
> experienced this with Xen 4.0 (I think) and the c/s 19167 certainly
> was in there.


We've been carrying this patch since before Xen 3.4 days. Given Jan's information we will remove it, retest, and get back to you.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:04:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:04:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3P1-0008Ui-KQ; Tue, 03 Apr 2012 13:04:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tom.goetz@virtualcomputer.com>) id 1SF3Oz-0008Ud-BY
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:04:01 +0000
Received: from [85.158.138.51:7774] by server-4.bemta-3.messagelabs.com id
	EB/89-16467-045FA7F4; Tue, 03 Apr 2012 13:04:00 +0000
X-Env-Sender: tom.goetz@virtualcomputer.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333458238!20511081!1
X-Originating-IP: [72.32.253.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMzIuMjUzLjY4ID0+IDI0OTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30742 invoked from network); 3 Apr 2012 13:04:00 -0000
Received: from server514a.exghost.com (HELO server514.appriver.com)
	(72.32.253.68)
	by server-8.tower-174.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	3 Apr 2012 13:04:00 -0000
X-Note-AR-ScanTimeLocal: 4/3/2012 8:03:57 AM
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: Too many policies to list
X-Primary: tom.goetz@virtualcomputer.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @virtualcomputer.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed: 
X-Country-Path: UNITED STATES->UNITED STATES->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 72.32.253.65
X-Note-Reverse-DNS: 
X-Note-Return-Path: tom.goetz@virtualcomputer.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G237 G238 G239 G240 G244 G245 G256 G347 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [72.32.253.65] (HELO FE06.exg4.exghost.com)
	by server514.appriver.com (CommuniGate Pro SMTP 5.4.4)
	with ESMTP id 277728560; Tue, 03 Apr 2012 08:03:57 -0500
Received: from FE06.exg4.exghost.com ([72.32.253.161]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Apr 2012 08:03:57 -0500
Received: from orion.oldroadcomputing.net ([67.192.118.157]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Apr 2012 08:03:57 -0500
Mime-Version: 1.0 (Apple Message framework v1257)
From: Tom Goetz <tom.goetz@virtualcomputer.com>
In-Reply-To: <20120402152830.GA30162@phenom.dumpdata.com>
Date: Tue, 3 Apr 2012 09:03:55 -0400
Message-Id: <11F89DC1-8FA4-4A8D-A197-BE3B95B6BE41@virtualcomputer.com>
References: <patchbomb.1332610901@phenom.dumpdata.com>
	<75798a472b1a9121adda.1332610904@phenom.dumpdata.com>
	<4F7049E3020000780007AD63@nat28.tlf.novell.com>
	<20120402152830.GA30162@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 03 Apr 2012 13:03:57.0257 (UTC)
	FILETIME=[3ACA1390:01CD119A]
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, Jan Beulich <JBeulich@suse.com>,
	keir.fraser@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 6] xen/pat: After suspend re-write PAT
	if BIOS changed it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 2, 2012, at 11:28 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Mar 26, 2012 at 09:50:11AM +0100, Jan Beulich wrote:
>>>>> On 24.03.12 at 18:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>> # HG changeset patch
>>> # User Simon Graham <simon.graham@virtualcomputer.com>
>>> # Date 1332610898 14400
>>> # Node ID 75798a472b1a9121adda166b6fd05ba8473a44f0
>>> # Parent  d097c3ba42f601af65b53a0c84973855aab64aa9
>>> xen/pat: After suspend re-write PAT if BIOS changed it.
>>> 
>>> Certain AMD machines (this was a MSI or GigaBYTE BIOS) after resume
>>> would reset the PAT MSR causing rather weird issues - where
>>> the pages would (say they would be set to WC) would end up with the
>>> wrong type (as they would use the BIOS PAT instead of the one set by
>>> the hypervisor).
>> 
>> There's a write of the PAT MSR already at the end of
>> restore_rest_processor_state() - are you saying this doesn't do
>> what is needed? Also note that this is properly gated by a check
>> of cpu_has_pat (other than the patch here does).
> 
> Let me double-check with folks at VirtualComputer - but they had
> experienced this with Xen 4.0 (I think) and the c/s 19167 certainly
> was in there.


We've been carrying this patch since before Xen 3.4 days. Given Jan's information we will remove it, retest, and get back to you.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3YN-0000DL-M9; Tue, 03 Apr 2012 13:13:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF3YM-0000DG-V1
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:13:43 +0000
Received: from [85.158.143.35:52772] by server-1.bemta-4.messagelabs.com id
	A5/E9-20925-587FA7F4; Tue, 03 Apr 2012 13:13:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333458816!7446124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10754 invoked from network); 3 Apr 2012 13:13:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:13:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11745831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:13:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:13:35 +0100
Date: Tue, 3 Apr 2012 14:15:57 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.53429.51575.373166@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> > On Fri, 30 Mar 2012, Ian Jackson wrote:
> > > Since we need to be able to allocate some vbds dynamically, the right
> > > approach is to decree that some portion of the dom0 vbd space is
> > > reserved for static allocations by the administrator, and that the
> > > remainder is for dynamic allocations by software which picks a free
> > > vbd.  Naturally the static space should come first.
> > 
> > When you hotplug a new disk on your system, for example a new USB disk
> > to your native Linux box, usually Linux chooses the device name for
> > you. I don't see why this should be any different.
> 
> It is different because Xen vbds do in practice appear in dom0 with a
> stable name.  So this is something that people have reasonably come to
> rely on.
> 
> > The admin is going to call instead:
> >   xl block-attach 0
> > and then checkout dmesg.
> 
> This is hardly automatable.  Doing the same thing with udev rules is
> quite hard work.

I don't feel that strongly about this, but given that the naming scheme
used in the guest is actually arbitrary at the moment (as in not document
or well defined anywhere), I would start the dynamic space before the
26th device: I have the feeling that after "xvdz" the behavior is going
to be even less "defined". I suggest "xvdm" as a starting point.


> > > I don't think that is true.  On each individual guest platform, the
> > > relationship between vbd numbers (the actual interface between
> > > frontend and backend), and whatever that guest has for device names,
> > > needs to be statically defined.
> > 
> > I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never
> > specified what names the guest kernel is allowed to choose for a
> > particular vbd encoding. See the following quote:
> > 
> > "The Xen interface does not specify what name a device should have in the
> > guest (nor what major/minor device number it should have in the guest,
> > if the guest has such a concept)."
> 
> This refers to the promises made by each side of the Xen VBD interface
> to the corresponding other side.  The host's environment is not
> allowed to assume things about the guest's device naming conventions.
> 
> However, that does not mean that the guest should not document its
> naming conventions.  Perhaps this needs to be clarified in the
> document.

Right, but unless I am missing something there isn't such a thing at the
moment, at least in Linux.

I'll try to come up with a linux devid to vdev function true to the
original.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3YN-0000DL-M9; Tue, 03 Apr 2012 13:13:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF3YM-0000DG-V1
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:13:43 +0000
Received: from [85.158.143.35:52772] by server-1.bemta-4.messagelabs.com id
	A5/E9-20925-587FA7F4; Tue, 03 Apr 2012 13:13:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333458816!7446124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10754 invoked from network); 3 Apr 2012 13:13:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:13:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11745831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:13:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:13:35 +0100
Date: Tue, 3 Apr 2012 14:15:57 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.53429.51575.373166@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> > On Fri, 30 Mar 2012, Ian Jackson wrote:
> > > Since we need to be able to allocate some vbds dynamically, the right
> > > approach is to decree that some portion of the dom0 vbd space is
> > > reserved for static allocations by the administrator, and that the
> > > remainder is for dynamic allocations by software which picks a free
> > > vbd.  Naturally the static space should come first.
> > 
> > When you hotplug a new disk on your system, for example a new USB disk
> > to your native Linux box, usually Linux chooses the device name for
> > you. I don't see why this should be any different.
> 
> It is different because Xen vbds do in practice appear in dom0 with a
> stable name.  So this is something that people have reasonably come to
> rely on.
> 
> > The admin is going to call instead:
> >   xl block-attach 0
> > and then checkout dmesg.
> 
> This is hardly automatable.  Doing the same thing with udev rules is
> quite hard work.

I don't feel that strongly about this, but given that the naming scheme
used in the guest is actually arbitrary at the moment (as in not document
or well defined anywhere), I would start the dynamic space before the
26th device: I have the feeling that after "xvdz" the behavior is going
to be even less "defined". I suggest "xvdm" as a starting point.


> > > I don't think that is true.  On each individual guest platform, the
> > > relationship between vbd numbers (the actual interface between
> > > frontend and backend), and whatever that guest has for device names,
> > > needs to be statically defined.
> > 
> > I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never
> > specified what names the guest kernel is allowed to choose for a
> > particular vbd encoding. See the following quote:
> > 
> > "The Xen interface does not specify what name a device should have in the
> > guest (nor what major/minor device number it should have in the guest,
> > if the guest has such a concept)."
> 
> This refers to the promises made by each side of the Xen VBD interface
> to the corresponding other side.  The host's environment is not
> allowed to assume things about the guest's device naming conventions.
> 
> However, that does not mean that the guest should not document its
> naming conventions.  Perhaps this needs to be clarified in the
> document.

Right, but unless I am missing something there isn't such a thing at the
moment, at least in Linux.

I'll try to come up with a linux devid to vdev function true to the
original.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:18:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3cX-0000Iz-Bn; Tue, 03 Apr 2012 13:18:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3cV-0000Ir-Qi
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:18:00 +0000
Received: from [85.158.139.83:19232] by server-3.bemta-5.messagelabs.com id
	3E/91-25237-488FA7F4; Tue, 03 Apr 2012 13:17:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333459075!22281289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3649 invoked from network); 3 Apr 2012 13:17:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11745996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:17:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:17:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3cQ-0004oR-NT; Tue, 03 Apr 2012 13:17:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3cQ-0003q6-MT;
	Tue, 03 Apr 2012 14:17:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.63616.101912.260089@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:17:52 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> I don't feel that strongly about this, but given that the naming scheme
> used in the guest is actually arbitrary at the moment (as in not document
> or well defined anywhere), I would start the dynamic space before the
> 26th device: I have the feeling that after "xvdz" the behavior is going
> to be even less "defined". I suggest "xvdm" as a starting point.

That's fine, if the starting point is configurable.

> > However, that does not mean that the guest should not document its
> > naming conventions.  Perhaps this needs to be clarified in the
> > document.
> 
> Right, but unless I am missing something there isn't such a thing at the
> moment, at least in Linux.
> 
> I'll try to come up with a linux devid to vdev function true to the
> original.

That would be good.  If you felt like documenting the Linux behaviour
properly that would be good.  The section "Notes on Linux as a guest"
in docs/misc/vbd-interface.text.

TBH I think Linux /should/ use the same numbering scheme as the name
supplied in the host config file, just for sanity's sake.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:18:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3cX-0000Iz-Bn; Tue, 03 Apr 2012 13:18:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3cV-0000Ir-Qi
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:18:00 +0000
Received: from [85.158.139.83:19232] by server-3.bemta-5.messagelabs.com id
	3E/91-25237-488FA7F4; Tue, 03 Apr 2012 13:17:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333459075!22281289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3649 invoked from network); 3 Apr 2012 13:17:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11745996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:17:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:17:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3cQ-0004oR-NT; Tue, 03 Apr 2012 13:17:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3cQ-0003q6-MT;
	Tue, 03 Apr 2012 14:17:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.63616.101912.260089@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:17:52 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> I don't feel that strongly about this, but given that the naming scheme
> used in the guest is actually arbitrary at the moment (as in not document
> or well defined anywhere), I would start the dynamic space before the
> 26th device: I have the feeling that after "xvdz" the behavior is going
> to be even less "defined". I suggest "xvdm" as a starting point.

That's fine, if the starting point is configurable.

> > However, that does not mean that the guest should not document its
> > naming conventions.  Perhaps this needs to be clarified in the
> > document.
> 
> Right, but unless I am missing something there isn't such a thing at the
> moment, at least in Linux.
> 
> I'll try to come up with a linux devid to vdev function true to the
> original.

That would be good.  If you felt like documenting the Linux behaviour
properly that would be good.  The section "Notes on Linux as a guest"
in docs/misc/vbd-interface.text.

TBH I think Linux /should/ use the same numbering scheme as the name
supplied in the host config file, just for sanity's sake.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:18:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3d0-0000L3-Om; Tue, 03 Apr 2012 13:18:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SF3cz-0000Kc-HR
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:18:29 +0000
Received: from [85.158.138.51:48451] by server-2.bemta-3.messagelabs.com id
	E3/AC-15460-4A8FA7F4; Tue, 03 Apr 2012 13:18:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333459106!20514646!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUyNDk1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14478 invoked from network); 3 Apr 2012 13:18:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 13:18:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q33DIMOO010792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Apr 2012 13:18:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q33DILAQ021435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Apr 2012 13:18:22 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q33DILYl010575; Tue, 3 Apr 2012 08:18:21 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 06:18:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B9C994004E; Tue,  3 Apr 2012 09:13:44 -0400 (EDT)
Date: Tue, 3 Apr 2012 09:13:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120403131344.GB12464@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
	<4F7AB96B.5030900@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7AB96B.5030900@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F7AF89F.0115,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 5/7] xen/setup: Transfer MFNs from non-RAM
 E820	entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:48:43AM +0100, David Vrabel wrote:
> On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> > We will now get:
> > 
> > -Released 283999 pages of unused memory
> > +Exchanged 283999 pages
> > .. snip..
> > -Memory: 6487732k/9208688k available (5817k kernel code, 1136060k absent, 1584896k reserved, 2900k data, 692k init)
> > +Memory: 6503888k/8072692k available (5817k kernel code, 1136060k absent, 432744k reserved, 2900k data, 692k init)
> 
> This isn't correct.  You've have lost ~1 GB of memory which are the
> pages that were supposed to be moved.  The additional 1GB of reserved
> memory in the old case is the balloon.

Whoops.
> 
> In xen_memory_setup() where it loops through the e820 to clip the RAM
> regions you need to factor in the additional memory you've moved.  In
> this loop you may need to count the pages in the RAM region instead of
> the simple (addr < mem_end) test.  Take care with RAM regions with
> partial pages and the like.

<nods> I did some more exhaustive testing and hit some issues
> 
> > which is more in line with classic XenOLinux.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/setup.c |   85 ++++++++++++++++++++++++++++++++++++++++++++++++--
> >  1 files changed, 82 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 1ba8dff..2a12143 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -120,12 +120,89 @@ static unsigned long __init xen_release_chunk(unsigned long start,
> >  	return len;
> >  }
> >  
> > +static unsigned long __init xen_exchange_chunk(unsigned long start_pfn,
> > +	unsigned long end_pfn, unsigned long nr_pages, unsigned long exchanged,
> > +	unsigned long *pages_left, const struct e820entry *list,
> > +	size_t map_size)
> > +{
> [...]
> > +
> > +		for (pfn = start_pfn; pfn < start_pfn + nr; pfn++) {
> > +			unsigned long mfn = pfn_to_mfn(pfn);
> > +
> > +			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
> > +				break;
> > +
> > +			if (!early_set_phys_to_machine(dest_pfn, mfn))
> > +				break;
> > +
> > +			/* You would think we should do HYPERVISOR_update_va_mapping
> > +			 * but we don't need to as the hypervisor only sets up the
> > +			 * initial pagetables up to nr_pages, and we stick the MFNs
> > +			 * past that.
> > +			 */
> 
> Hmmm. Are you sure this is safe?  What happens if Linux tries to use
> these pages before creating new page tables?  e.g., via some early boot
> allocator before the final page tables are setup? (This might not be a
> problem, I haven't checked).

I think this is what I am hitting actually, but not entirely sure.
> 
> You've may have gotten away with it for now because the moved MFNs are
> marked as unusable.

Right, and they should be marked 'usuable'. There is a forthcoming patch
that does that but it isn't ready yet.

> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:18:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3d0-0000L3-Om; Tue, 03 Apr 2012 13:18:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SF3cz-0000Kc-HR
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:18:29 +0000
Received: from [85.158.138.51:48451] by server-2.bemta-3.messagelabs.com id
	E3/AC-15460-4A8FA7F4; Tue, 03 Apr 2012 13:18:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333459106!20514646!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUyNDk1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14478 invoked from network); 3 Apr 2012 13:18:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 13:18:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q33DIMOO010792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Apr 2012 13:18:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q33DILAQ021435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Apr 2012 13:18:22 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q33DILYl010575; Tue, 3 Apr 2012 08:18:21 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 06:18:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B9C994004E; Tue,  3 Apr 2012 09:13:44 -0400 (EDT)
Date: Tue, 3 Apr 2012 09:13:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120403131344.GB12464@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
	<4F7AB96B.5030900@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7AB96B.5030900@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F7AF89F.0115,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 5/7] xen/setup: Transfer MFNs from non-RAM
 E820	entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:48:43AM +0100, David Vrabel wrote:
> On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> > We will now get:
> > 
> > -Released 283999 pages of unused memory
> > +Exchanged 283999 pages
> > .. snip..
> > -Memory: 6487732k/9208688k available (5817k kernel code, 1136060k absent, 1584896k reserved, 2900k data, 692k init)
> > +Memory: 6503888k/8072692k available (5817k kernel code, 1136060k absent, 432744k reserved, 2900k data, 692k init)
> 
> This isn't correct.  You've have lost ~1 GB of memory which are the
> pages that were supposed to be moved.  The additional 1GB of reserved
> memory in the old case is the balloon.

Whoops.
> 
> In xen_memory_setup() where it loops through the e820 to clip the RAM
> regions you need to factor in the additional memory you've moved.  In
> this loop you may need to count the pages in the RAM region instead of
> the simple (addr < mem_end) test.  Take care with RAM regions with
> partial pages and the like.

<nods> I did some more exhaustive testing and hit some issues
> 
> > which is more in line with classic XenOLinux.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/setup.c |   85 ++++++++++++++++++++++++++++++++++++++++++++++++--
> >  1 files changed, 82 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 1ba8dff..2a12143 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -120,12 +120,89 @@ static unsigned long __init xen_release_chunk(unsigned long start,
> >  	return len;
> >  }
> >  
> > +static unsigned long __init xen_exchange_chunk(unsigned long start_pfn,
> > +	unsigned long end_pfn, unsigned long nr_pages, unsigned long exchanged,
> > +	unsigned long *pages_left, const struct e820entry *list,
> > +	size_t map_size)
> > +{
> [...]
> > +
> > +		for (pfn = start_pfn; pfn < start_pfn + nr; pfn++) {
> > +			unsigned long mfn = pfn_to_mfn(pfn);
> > +
> > +			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
> > +				break;
> > +
> > +			if (!early_set_phys_to_machine(dest_pfn, mfn))
> > +				break;
> > +
> > +			/* You would think we should do HYPERVISOR_update_va_mapping
> > +			 * but we don't need to as the hypervisor only sets up the
> > +			 * initial pagetables up to nr_pages, and we stick the MFNs
> > +			 * past that.
> > +			 */
> 
> Hmmm. Are you sure this is safe?  What happens if Linux tries to use
> these pages before creating new page tables?  e.g., via some early boot
> allocator before the final page tables are setup? (This might not be a
> problem, I haven't checked).

I think this is what I am hitting actually, but not entirely sure.
> 
> You've may have gotten away with it for now because the moved MFNs are
> marked as unusable.

Right, and they should be marked 'usuable'. There is a forthcoming patch
that does that but it isn't ready yet.

> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3ei-0000V7-9q; Tue, 03 Apr 2012 13:20:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3eh-0000Ux-9Y
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:20:15 +0000
Received: from [85.158.143.99:50785] by server-3.bemta-4.messagelabs.com id
	85/6D-05853-E09FA7F4; Tue, 03 Apr 2012 13:20:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333459209!22093644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3909 invoked from network); 3 Apr 2012 13:20:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:20:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:20:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3eb-0004pO-Da; Tue, 03 Apr 2012 13:20:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3eb-0003qI-CV;
	Tue, 03 Apr 2012 14:20:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.63753.211063.200875@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:20:09 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6685b67958b0623064c7.1332321259@probook.site>
References: <6685b67958b0623064c7.1332321259@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> tools/vtpm: use LDLIBS to pass -lgmp
> 
> Linking tpmd will fail with recent toolchains because -lgmp is passed
> via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the
> end of the gcc cmdline and linking tpmd succeeds again.
...
>   CFLAGS  += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
>  +CFLAGS  += -I../../../../tools/vtpm_manager/manager
> - LDFLAGS += -lgmp
> + LDLIBS  += -lgmp
>   
>  -BINDIR  := /usr/sbin/
>  +BINDIR  := /usr/bin/

Please could you make sure not to include unrelated changes in your
patches.  That makes the job of the reviewer /much/ harder, because we
would have to inspect every hunk of your patches looking for this kind
of thing creeping in.

This is a matter of trust for us as maintainers.  Including an
unrelated hunk once can be put down to a mistake.  Doing it
persistently is a breach of the trust that we as committers need to
place in people who submit patches.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3ei-0000V7-9q; Tue, 03 Apr 2012 13:20:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3eh-0000Ux-9Y
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:20:15 +0000
Received: from [85.158.143.99:50785] by server-3.bemta-4.messagelabs.com id
	85/6D-05853-E09FA7F4; Tue, 03 Apr 2012 13:20:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333459209!22093644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3909 invoked from network); 3 Apr 2012 13:20:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:20:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:20:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3eb-0004pO-Da; Tue, 03 Apr 2012 13:20:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3eb-0003qI-CV;
	Tue, 03 Apr 2012 14:20:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.63753.211063.200875@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:20:09 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6685b67958b0623064c7.1332321259@probook.site>
References: <6685b67958b0623064c7.1332321259@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> tools/vtpm: use LDLIBS to pass -lgmp
> 
> Linking tpmd will fail with recent toolchains because -lgmp is passed
> via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the
> end of the gcc cmdline and linking tpmd succeeds again.
...
>   CFLAGS  += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
>  +CFLAGS  += -I../../../../tools/vtpm_manager/manager
> - LDFLAGS += -lgmp
> + LDLIBS  += -lgmp
>   
>  -BINDIR  := /usr/sbin/
>  +BINDIR  := /usr/bin/

Please could you make sure not to include unrelated changes in your
patches.  That makes the job of the reviewer /much/ harder, because we
would have to inspect every hunk of your patches looking for this kind
of thing creeping in.

This is a matter of trust for us as maintainers.  Including an
unrelated hunk once can be put down to a mistake.  Doing it
persistently is a breach of the trust that we as committers need to
place in people who submit patches.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:21:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3fo-0000bl-Oj; Tue, 03 Apr 2012 13:21:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3fn-0000bb-VW
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:21:24 +0000
Received: from [85.158.143.35:14727] by server-3.bemta-4.messagelabs.com id
	EB/FF-05853-359FA7F4; Tue, 03 Apr 2012 13:21:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333459282!10823536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29208 invoked from network); 3 Apr 2012 13:21:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:21:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:21:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:21:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3fl-0004pj-SX; Tue, 03 Apr 2012 13:21:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3fl-0003qa-Rf;
	Tue, 03 Apr 2012 14:21:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.63825.841623.918883@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:21:21 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <33af0a492bf7d2d682fe.1333397741@probook.site>
References: <patchbomb.1333397723@probook.site>
	<33af0a492bf7d2d682fe.1333397741@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 18 of 18] tools/blktap+blktap2: fix build
 errors caused by Werror, remove unused variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[PATCH 18 of 18] tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables"):
> tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables

I'm afraid that I don't have time to eyeball the whole of this patch
for unrelated hunks, not described by the commit message.  And sadly
it would appear that I need to do that.  So I'm going to put off
reviewing it until I have more time.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:21:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3fo-0000bl-Oj; Tue, 03 Apr 2012 13:21:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3fn-0000bb-VW
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:21:24 +0000
Received: from [85.158.143.35:14727] by server-3.bemta-4.messagelabs.com id
	EB/FF-05853-359FA7F4; Tue, 03 Apr 2012 13:21:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333459282!10823536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29208 invoked from network); 3 Apr 2012 13:21:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:21:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:21:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:21:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3fl-0004pj-SX; Tue, 03 Apr 2012 13:21:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3fl-0003qa-Rf;
	Tue, 03 Apr 2012 14:21:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.63825.841623.918883@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:21:21 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <33af0a492bf7d2d682fe.1333397741@probook.site>
References: <patchbomb.1333397723@probook.site>
	<33af0a492bf7d2d682fe.1333397741@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 18 of 18] tools/blktap+blktap2: fix build
 errors caused by Werror, remove unused variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[PATCH 18 of 18] tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables"):
> tools/blktap+blktap2: fix build errors caused by Werror, remove unused variables

I'm afraid that I don't have time to eyeball the whole of this patch
for unrelated hunks, not described by the commit message.  And sadly
it would appear that I need to do that.  So I'm going to put off
reviewing it until I have more time.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:24:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:24:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3ir-0000uP-IJ; Tue, 03 Apr 2012 13:24:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SF3ip-0000uC-F8
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:24:31 +0000
Received: from [85.158.143.99:45279] by server-1.bemta-4.messagelabs.com id
	38/01-20925-E0AFA7F4; Tue, 03 Apr 2012 13:24:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333459468!21832366!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUyNDk1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32261 invoked from network); 3 Apr 2012 13:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 13:24:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q33DOOp9018142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Apr 2012 13:24:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q33DONq5003161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Apr 2012 13:24:23 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q33DONJo016431; Tue, 3 Apr 2012 08:24:23 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 06:24:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4EF934004E; Tue,  3 Apr 2012 09:19:47 -0400 (EDT)
Date: Tue, 3 Apr 2012 09:19:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120403131947.GC12464@phenom.dumpdata.com>
References: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090201.4F7AFA09.0084,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 12:25:02PM +0100, Stefano Stabellini wrote:
> Since when we are using the m2p_override it is not true anymore that the
        ^^^^ - get rid of that.
> mmap'ed area doesn't have corresponsing struct pages.

That reads to me as !!do struct page. Which comes out as:

"m2p_override_* API the mmap-ed are have corresponding struct pages' ?


> 
> Removing the VM_PFNMAP flag makes get_user_pages work on the mmap'ed user vma.
> An example test case would be using a Xen userspace block backend
> (QDISK) on a file on NFS using O_DIRECT.
> 
> The patch should be backported back to 2.6.38.

Add CC: stable@kernel.org then. But does this patch depend on other
patches?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/xen/gntdev.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 99d8151..1ffd03b 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
>  	vma->vm_flags |= VM_RESERVED|VM_DONTEXPAND;
>  
>  	if (use_ptemod)
> -		vma->vm_flags |= VM_DONTCOPY|VM_PFNMAP;
> +		vma->vm_flags |= VM_DONTCOPY;
>  
>  	vma->vm_private_data = map;
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:24:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:24:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3ir-0000uP-IJ; Tue, 03 Apr 2012 13:24:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SF3ip-0000uC-F8
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:24:31 +0000
Received: from [85.158.143.99:45279] by server-1.bemta-4.messagelabs.com id
	38/01-20925-E0AFA7F4; Tue, 03 Apr 2012 13:24:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333459468!21832366!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUyNDk1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32261 invoked from network); 3 Apr 2012 13:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 13:24:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q33DOOp9018142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Apr 2012 13:24:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q33DONq5003161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Apr 2012 13:24:23 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q33DONJo016431; Tue, 3 Apr 2012 08:24:23 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 06:24:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4EF934004E; Tue,  3 Apr 2012 09:19:47 -0400 (EDT)
Date: Tue, 3 Apr 2012 09:19:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120403131947.GC12464@phenom.dumpdata.com>
References: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090201.4F7AFA09.0084,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 12:25:02PM +0100, Stefano Stabellini wrote:
> Since when we are using the m2p_override it is not true anymore that the
        ^^^^ - get rid of that.
> mmap'ed area doesn't have corresponsing struct pages.

That reads to me as !!do struct page. Which comes out as:

"m2p_override_* API the mmap-ed are have corresponding struct pages' ?


> 
> Removing the VM_PFNMAP flag makes get_user_pages work on the mmap'ed user vma.
> An example test case would be using a Xen userspace block backend
> (QDISK) on a file on NFS using O_DIRECT.
> 
> The patch should be backported back to 2.6.38.

Add CC: stable@kernel.org then. But does this patch depend on other
patches?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/xen/gntdev.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 99d8151..1ffd03b 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
>  	vma->vm_flags |= VM_RESERVED|VM_DONTEXPAND;
>  
>  	if (use_ptemod)
> -		vma->vm_flags |= VM_DONTCOPY|VM_PFNMAP;
> +		vma->vm_flags |= VM_DONTCOPY;
>  
>  	vma->vm_private_data = map;
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:31:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3pf-000183-Jr; Tue, 03 Apr 2012 13:31:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3pd-00017y-9Z
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:31:33 +0000
Received: from [85.158.139.83:7528] by server-4.bemta-5.messagelabs.com id
	18/83-10788-4BBFA7F4; Tue, 03 Apr 2012 13:31:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333459889!22231407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8300 invoked from network); 3 Apr 2012 13:31:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:31:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:31:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:31:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3pY-0004t1-K2; Tue, 03 Apr 2012 13:31:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3pX-0006Mt-Sw;
	Tue, 03 Apr 2012 14:31:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.64407.174158.890551@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:31:03 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> On Mon, 2 Apr 2012, Ian Jackson wrote:
> > I don't think this is really a suitable interface.  The PCI space in
> > the guest is controlled by the device models(s) and the user should
> > surely specify which devices should be provided by which dms, in terms
> > of devices not in terms of PCI space.
>  
> Julien added a name parameter to select the device, maybe we need
> something clearer?
> Specifying the PCI address is important, because we have to make sure
> the PCI addresses of the devices remain the same in a given VM across
> multiple boots.

Are the PCI addresses not assigned in a deterministic fashion by code
in qemu-dm, in this case in the qemu-dm which is emulating the pci
bridge ?  If not then that needs to be fixed, surely ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:31:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3pf-000183-Jr; Tue, 03 Apr 2012 13:31:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3pd-00017y-9Z
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:31:33 +0000
Received: from [85.158.139.83:7528] by server-4.bemta-5.messagelabs.com id
	18/83-10788-4BBFA7F4; Tue, 03 Apr 2012 13:31:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333459889!22231407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8300 invoked from network); 3 Apr 2012 13:31:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:31:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:31:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:31:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3pY-0004t1-K2; Tue, 03 Apr 2012 13:31:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3pX-0006Mt-Sw;
	Tue, 03 Apr 2012 14:31:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.64407.174158.890551@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:31:03 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> On Mon, 2 Apr 2012, Ian Jackson wrote:
> > I don't think this is really a suitable interface.  The PCI space in
> > the guest is controlled by the device models(s) and the user should
> > surely specify which devices should be provided by which dms, in terms
> > of devices not in terms of PCI space.
>  
> Julien added a name parameter to select the device, maybe we need
> something clearer?
> Specifying the PCI address is important, because we have to make sure
> the PCI addresses of the devices remain the same in a given VM across
> multiple boots.

Are the PCI addresses not assigned in a deterministic fashion by code
in qemu-dm, in this case in the qemu-dm which is emulating the pci
bridge ?  If not then that needs to be fixed, surely ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:40:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3xs-0001KR-NQ; Tue, 03 Apr 2012 13:40:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3xr-0001KM-AK
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 13:40:03 +0000
Received: from [85.158.143.99:28265] by server-2.bemta-4.messagelabs.com id
	19/D2-17550-2BDFA7F4; Tue, 03 Apr 2012 13:40:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333460401!21237154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15745 invoked from network); 3 Apr 2012 13:40:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:39:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:39:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3xH-0004xd-7b; Tue, 03 Apr 2012 13:39:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3xH-0001u1-1W;
	Tue, 03 Apr 2012 14:39:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.64910.885520.774577@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:39:26 +0100
To: Roger Pau Monne <roger.pau@entel.upc.edu>, KUWAMURA Shin'ya
	<kuwa@jp.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120403.133329.137901442.kuwa@jp.fujitsu.com>,
	<1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
References: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
	<20120403.133329.137901442.kuwa@jp.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: yang.z.zhang@intel.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on
 old python versions [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3] autoconf: fix python-dev detection on old python versions"):
> Replaced the use of python-config (that is only present in Python >= 2.5.x)
> with the distutils python module.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:40:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3xs-0001KR-NQ; Tue, 03 Apr 2012 13:40:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3xr-0001KM-AK
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 13:40:03 +0000
Received: from [85.158.143.99:28265] by server-2.bemta-4.messagelabs.com id
	19/D2-17550-2BDFA7F4; Tue, 03 Apr 2012 13:40:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333460401!21237154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15745 invoked from network); 3 Apr 2012 13:40:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:39:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:39:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3xH-0004xd-7b; Tue, 03 Apr 2012 13:39:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3xH-0001u1-1W;
	Tue, 03 Apr 2012 14:39:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.64910.885520.774577@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:39:26 +0100
To: Roger Pau Monne <roger.pau@entel.upc.edu>, KUWAMURA Shin'ya
	<kuwa@jp.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120403.133329.137901442.kuwa@jp.fujitsu.com>,
	<1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
References: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
	<20120403.133329.137901442.kuwa@jp.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: yang.z.zhang@intel.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on
 old python versions [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3] autoconf: fix python-dev detection on old python versions"):
> Replaced the use of python-config (that is only present in Python >= 2.5.x)
> with the distutils python module.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:40:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3yJ-0001M3-40; Tue, 03 Apr 2012 13:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3yH-0001Lp-OK
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:40:29 +0000
Received: from [85.158.139.83:7524] by server-8.bemta-5.messagelabs.com id
	8A/45-26964-CCDFA7F4; Tue, 03 Apr 2012 13:40:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333460428!22291326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16587 invoked from network); 3 Apr 2012 13:40:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:40:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:40:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3yF-0004y5-SF; Tue, 03 Apr 2012 13:40:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3yF-0001uO-R7;
	Tue, 03 Apr 2012 14:40:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.64971.716207.60354@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:40:27 +0100
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1333446868-11463-1-git-send-email-david.vrabel@citrix.com>
References: <1333446868-11463-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: clarify documentation for the
	the	dom0_mem command line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel writes ("[Xen-devel] [PATCH] docs: clarify documentation for the the dom0_mem command line option"):
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> This addresses Ian C's comments on v1 of a previous patch (which
> was applied instead of v2).

Sorry about that; I have applied the fixup.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:40:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF3yJ-0001M3-40; Tue, 03 Apr 2012 13:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF3yH-0001Lp-OK
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:40:29 +0000
Received: from [85.158.139.83:7524] by server-8.bemta-5.messagelabs.com id
	8A/45-26964-CCDFA7F4; Tue, 03 Apr 2012 13:40:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333460428!22291326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16587 invoked from network); 3 Apr 2012 13:40:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11746749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:40:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:40:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF3yF-0004y5-SF; Tue, 03 Apr 2012 13:40:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF3yF-0001uO-R7;
	Tue, 03 Apr 2012 14:40:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20346.64971.716207.60354@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:40:27 +0100
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1333446868-11463-1-git-send-email-david.vrabel@citrix.com>
References: <1333446868-11463-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: clarify documentation for the
	the	dom0_mem command line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel writes ("[Xen-devel] [PATCH] docs: clarify documentation for the the dom0_mem command line option"):
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> This addresses Ian C's comments on v1 of a previous patch (which
> was applied instead of v2).

Sorry about that; I have applied the fixup.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:44:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF41M-0001Wq-Pc; Tue, 03 Apr 2012 13:43:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF41L-0001Wf-M1
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:43:39 +0000
Received: from [85.158.138.51:2379] by server-10.bemta-3.messagelabs.com id
	6D/B4-15637-A8EFA7F4; Tue, 03 Apr 2012 13:43:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333460616!20521222!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7387 invoked from network); 3 Apr 2012 13:43:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Apr 2012 13:43:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF41H-0007a6-SL
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 06:43:35 -0700
Date: Tue, 3 Apr 2012 06:43:35 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333460615826-5615170.post@n5.nabble.com>
In-Reply-To: <4F701F3D.70601@tiscali.it>
References: <4F701F3D.70601@tiscali.it>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH - RESEND] Autoconf: add variable for pass
 arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I tried with multiple parameters but not work:
./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir --enable-debug"
...
configure: WARNING: unrecognized options: --enable-usb-redir

What I must do for add variable with multiple parameters in autoconf?
Thanks for any reply and sorry for bad english

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-RESEND-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5594506p5615170.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:44:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF41M-0001Wq-Pc; Tue, 03 Apr 2012 13:43:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF41L-0001Wf-M1
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:43:39 +0000
Received: from [85.158.138.51:2379] by server-10.bemta-3.messagelabs.com id
	6D/B4-15637-A8EFA7F4; Tue, 03 Apr 2012 13:43:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333460616!20521222!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7387 invoked from network); 3 Apr 2012 13:43:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Apr 2012 13:43:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF41H-0007a6-SL
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 06:43:35 -0700
Date: Tue, 3 Apr 2012 06:43:35 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333460615826-5615170.post@n5.nabble.com>
In-Reply-To: <4F701F3D.70601@tiscali.it>
References: <4F701F3D.70601@tiscali.it>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH - RESEND] Autoconf: add variable for pass
 arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I tried with multiple parameters but not work:
./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir --enable-debug"
...
configure: WARNING: unrecognized options: --enable-usb-redir

What I must do for add variable with multiple parameters in autoconf?
Thanks for any reply and sorry for bad english

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-RESEND-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5594506p5615170.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF487-0001nG-BY; Tue, 03 Apr 2012 13:50:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF486-0001n4-Ek
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:50:38 +0000
Received: from [85.158.139.83:12126] by server-11.bemta-5.messagelabs.com id
	16/5F-12959-D200B7F4; Tue, 03 Apr 2012 13:50:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333461036!22288648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7005 invoked from network); 3 Apr 2012 13:50:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:50:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:50:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:50:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF484-00053x-Cp; Tue, 03 Apr 2012 13:50:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF484-0001vB-6H;
	Tue, 03 Apr 2012 14:50:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.41.542788.706794@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:50:33 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> Introduce a new save_id to save/restore toolstack specific extra
> information.

This looks plausible.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Although I do have one comment: are you sure it's appropriate that the
"toolstack data" is silently thrown away if the restore caller doesn't
supply the relevant callback ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF487-0001nG-BY; Tue, 03 Apr 2012 13:50:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF486-0001n4-Ek
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:50:38 +0000
Received: from [85.158.139.83:12126] by server-11.bemta-5.messagelabs.com id
	16/5F-12959-D200B7F4; Tue, 03 Apr 2012 13:50:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333461036!22288648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7005 invoked from network); 3 Apr 2012 13:50:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:50:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:50:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 14:50:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF484-00053x-Cp; Tue, 03 Apr 2012 13:50:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF484-0001vB-6H;
	Tue, 03 Apr 2012 14:50:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.41.542788.706794@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 14:50:33 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> Introduce a new save_id to save/restore toolstack specific extra
> information.

This looks plausible.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Although I do have one comment: are you sure it's appropriate that the
"toolstack data" is silently thrown away if the restore caller doesn't
supply the relevant callback ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:54:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Bp-00024e-00; Tue, 03 Apr 2012 13:54:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1SF4Bn-00024Q-1d
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:54:27 +0000
Received: from [85.158.139.83:5686] by server-12.bemta-5.messagelabs.com id
	E7/A3-05587-2110B7F4; Tue, 03 Apr 2012 13:54:26 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333461263!11027171!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17855 invoked from network); 3 Apr 2012 13:54:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="23818839"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 09:54:23 -0400
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:54:22 -0400
Message-ID: <4F7B0122.9090602@citrix.com>
Date: Tue, 3 Apr 2012 14:54:42 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120320 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>	<20345.56773.8058.87028@mariner.uk.xensource.com>	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
In-Reply-To: <20346.64407.174158.890551@mariner.uk.xensource.com>
Cc: Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/03/2012 02:31 PM, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
>    
>> On Mon, 2 Apr 2012, Ian Jackson wrote:
>>      
>>> I don't think this is really a suitable interface.  The PCI space in
>>> the guest is controlled by the device models(s) and the user should
>>> surely specify which devices should be provided by which dms, in terms
>>> of devices not in terms of PCI space.
>>>        
>>
>> Julien added a name parameter to select the device, maybe we need
>> something clearer?
>> Specifying the PCI address is important, because we have to make sure
>> the PCI addresses of the devices remain the same in a given VM across
>> multiple boots.
>>      
> Are the PCI addresses not assigned in a deterministic fashion by code
> in qemu-dm, in this case in the qemu-dm which is emulating the pci
> bridge ?  If not then that needs to be fixed, surely ?
>    
Indeed but each QEMU emulate a subset of the hardware.
So how QEMU can know the available PCI addresses ?
I think that toolstack must allocate the BDF, otherwise we need to have
communication between each qemu-dm.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 13:54:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 13:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Bp-00024e-00; Tue, 03 Apr 2012 13:54:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1SF4Bn-00024Q-1d
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:54:27 +0000
Received: from [85.158.139.83:5686] by server-12.bemta-5.messagelabs.com id
	E7/A3-05587-2110B7F4; Tue, 03 Apr 2012 13:54:26 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333461263!11027171!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17855 invoked from network); 3 Apr 2012 13:54:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="23818839"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 09:54:23 -0400
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	09:54:22 -0400
Message-ID: <4F7B0122.9090602@citrix.com>
Date: Tue, 3 Apr 2012 14:54:42 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120320 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>	<20345.56773.8058.87028@mariner.uk.xensource.com>	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
In-Reply-To: <20346.64407.174158.890551@mariner.uk.xensource.com>
Cc: Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/03/2012 02:31 PM, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
>    
>> On Mon, 2 Apr 2012, Ian Jackson wrote:
>>      
>>> I don't think this is really a suitable interface.  The PCI space in
>>> the guest is controlled by the device models(s) and the user should
>>> surely specify which devices should be provided by which dms, in terms
>>> of devices not in terms of PCI space.
>>>        
>>
>> Julien added a name parameter to select the device, maybe we need
>> something clearer?
>> Specifying the PCI address is important, because we have to make sure
>> the PCI addresses of the devices remain the same in a given VM across
>> multiple boots.
>>      
> Are the PCI addresses not assigned in a deterministic fashion by code
> in qemu-dm, in this case in the qemu-dm which is emulating the pci
> bridge ?  If not then that needs to be fixed, surely ?
>    
Indeed but each QEMU emulate a subset of the hardware.
So how QEMU can know the available PCI addresses ?
I think that toolstack must allocate the BDF, otherwise we need to have
communication between each qemu-dm.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4I1-0002Od-PX; Tue, 03 Apr 2012 14:00:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF4I1-0002OW-66
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:00:53 +0000
Received: from [85.158.138.51:25704] by server-6.bemta-3.messagelabs.com id
	77/7A-08206-4920B7F4; Tue, 03 Apr 2012 14:00:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333461649!20605800!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9929 invoked from network); 3 Apr 2012 14:00:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:00:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="188811999"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:00:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 10:00:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF4Hv-0001zy-FM;
	Tue, 03 Apr 2012 15:00:47 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0625fe50a2ee3943854daccb2331883019473e06
Message-ID: <0625fe50a2ee3943854d.1333461293@kodo2>
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 14:54:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By default pciback only allows PV guests to write "known safe" values into
PCI config space.  But many devices require writes to other areas of config
space in order to operate properly.  One way to do that is with the "quirks"
interface, which specifies areas known safe to a particular device; the
other way is to mark a device as "permissive", which tells pciback to allow
all config space writes for that domain and device.

This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
to write the appropriate value into sysfs to enable the permissive feature for
devices being passed through.  It also adds the permissive config options either
on a per-device basis, or as a global option in the xl command-line.

Because of the potential stability and security implications of enabling
permissive, the flag is left off by default.

v3:
- Return error on failure
- Wrap a long line
- Clarify security warning / recommendation

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 74bb52e4f6a6 -r 0625fe50a2ee docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Apr 02 15:54:08 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Tue Apr 03 14:46:27 2012 +0100
@@ -294,10 +294,31 @@ XXX
 
 XXX
 
+=item B<permissive=BOOLEAN>
+
+(PV only) By default pciback only allows PV guests to write "known
+safe" values into PCI config space.  But many devices require writes
+to other areas of config space in order to operate properly.  This
+tells the pciback driver to allow all writes to PCI config space of
+this device by this domain.  This option should be enabled with
+caution: it gives the guest much more control over the device, which
+may have security or stability implications.  It is recommended to
+enable this option only for trusted VMs under administrator control.
+
 =back
 
 =back
 
+=item B<pci_permissive=BOOLEAN>
+
+(PV only) Changes the default value of 'permissive' for all PCI
+devices for this VM.  This can still be overriden on a per-device
+basis. This option should be enabled with caution: it gives the guest
+much more control over the device, which may have security or
+stability implications.  It is recommended to enable this option only
+for trusted VMs under administrator control.  See the "pci=" section
+for more information on the "permissive" flag.
+
 =back
 
 =head2 Paravirtualised (PV) Guest Specific Options
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Apr 03 14:46:27 2012 +0100
@@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
     if (pcidev->vdevfn)
         flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
     flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
-    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
+    flexarray_append(back,
+              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
+                             pcidev->msitranslate, pcidev->power_mgmt,
+                             pcidev->permissive));
     flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
 }
 
@@ -565,6 +568,31 @@ static int do_pci_add(libxl__gc *gc, uin
             }
         }
         fclose(f);
+
+        /* Don't restrict writes to the PCI config space from this VM */
+        if (pcidev->permissive) {
+            int fd;
+            char *buf;
+            
+            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
+            fd = open(sysfs_path, O_WRONLY);
+            if (fd < 0) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
+                                 sysfs_path);
+                return ERROR_FAIL;
+            }
+ 
+            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
+                                 pcidev->dev, pcidev->func);
+            rc = write(fd, buf, strlen(buf));
+            /* Annoying to have two if's, but we need the errno */
+            if (rc < 0)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                                 "write to %s returned %d", sysfs_path, rc);
+            close(fd);
+            if (rc < 0)
+                return ERROR_FAIL;
+        }
         break;
     }
     default:
@@ -958,6 +986,9 @@ static void libxl__device_pci_from_xs_be
             } else if (!strcmp(p, "power_mgmt")) {
                 p = strtok_r(NULL, ",=", &saveptr);
                 pci->power_mgmt = atoi(p);
+            } else if (!strcmp(p, "permissive")) {
+                p = strtok_r(NULL, ",=", &saveptr);
+                pci->permissive = atoi(p);
             }
         } while ((p = strtok_r(NULL, ",=", &saveptr)) != NULL);
     }
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Apr 03 14:46:27 2012 +0100
@@ -352,6 +352,7 @@ libxl_device_pci = Struct("device_pci", 
     ("vfunc_mask", uint32),
     ("msitranslate", bool),
     ("power_mgmt", bool),
+    ("permissive", bool),
     ])
 
 libxl_diskinfo = Struct("diskinfo", [
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/libxlu_pci.c
--- a/tools/libxl/libxlu_pci.c	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/libxlu_pci.c	Tue Apr 03 14:46:27 2012 +0100
@@ -139,6 +139,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, l
                     pcidev->msitranslate = atoi(tok);
                 }else if ( !strcmp(optkey, "power_mgmt") ) {
                     pcidev->power_mgmt = atoi(tok);
+                }else if ( !strcmp(optkey, "permissive") ) {
+                    pcidev->permissive = atoi(tok);
                 }else{
                     XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
                 }
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 14:46:27 2012 +0100
@@ -518,6 +518,7 @@ static void parse_config_data(const char
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
+    int pci_permissive = 0;
     int e;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -986,6 +987,9 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
+    if (!xlu_cfg_get_long (config, "pci_permissive", &l, 0))
+        pci_permissive = l;
+
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1005,6 +1009,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
+            pcidev->permissive = pci_permissive;
             if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4I3-0002P1-AZ; Tue, 03 Apr 2012 14:00:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF4I1-0002OW-RT
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:00:53 +0000
Received: from [85.158.138.51:50092] by server-6.bemta-3.messagelabs.com id
	CC/7A-08206-5920B7F4; Tue, 03 Apr 2012 14:00:53 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333461649!20605800!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10013 invoked from network); 3 Apr 2012 14:00:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:00:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="188811996"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:00:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 10:00:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF4Hv-0001zy-EI;
	Tue, 03 Apr 2012 15:00:47 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333461291@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 14:54:51 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series adds the "permissive" option for passed-through devices
which access config space out of the "known good" PCI config space.

v2:
- Added patch to move bdf parsing to libxlu
- Addressed some formatting comments

v3:
- Don't make the struct initialization utility function public
- Return error on failure
- Wrap a long line
- Clarify security warning / recommendation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4I1-0002Od-PX; Tue, 03 Apr 2012 14:00:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF4I1-0002OW-66
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:00:53 +0000
Received: from [85.158.138.51:25704] by server-6.bemta-3.messagelabs.com id
	77/7A-08206-4920B7F4; Tue, 03 Apr 2012 14:00:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333461649!20605800!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9929 invoked from network); 3 Apr 2012 14:00:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:00:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="188811999"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:00:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 10:00:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF4Hv-0001zy-FM;
	Tue, 03 Apr 2012 15:00:47 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0625fe50a2ee3943854daccb2331883019473e06
Message-ID: <0625fe50a2ee3943854d.1333461293@kodo2>
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 14:54:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By default pciback only allows PV guests to write "known safe" values into
PCI config space.  But many devices require writes to other areas of config
space in order to operate properly.  One way to do that is with the "quirks"
interface, which specifies areas known safe to a particular device; the
other way is to mark a device as "permissive", which tells pciback to allow
all config space writes for that domain and device.

This adds a "permissive" flag to the libxl_pci struct and teaches libxl how
to write the appropriate value into sysfs to enable the permissive feature for
devices being passed through.  It also adds the permissive config options either
on a per-device basis, or as a global option in the xl command-line.

Because of the potential stability and security implications of enabling
permissive, the flag is left off by default.

v3:
- Return error on failure
- Wrap a long line
- Clarify security warning / recommendation

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 74bb52e4f6a6 -r 0625fe50a2ee docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Apr 02 15:54:08 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Tue Apr 03 14:46:27 2012 +0100
@@ -294,10 +294,31 @@ XXX
 
 XXX
 
+=item B<permissive=BOOLEAN>
+
+(PV only) By default pciback only allows PV guests to write "known
+safe" values into PCI config space.  But many devices require writes
+to other areas of config space in order to operate properly.  This
+tells the pciback driver to allow all writes to PCI config space of
+this device by this domain.  This option should be enabled with
+caution: it gives the guest much more control over the device, which
+may have security or stability implications.  It is recommended to
+enable this option only for trusted VMs under administrator control.
+
 =back
 
 =back
 
+=item B<pci_permissive=BOOLEAN>
+
+(PV only) Changes the default value of 'permissive' for all PCI
+devices for this VM.  This can still be overriden on a per-device
+basis. This option should be enabled with caution: it gives the guest
+much more control over the device, which may have security or
+stability implications.  It is recommended to enable this option only
+for trusted VMs under administrator control.  See the "pci=" section
+for more information on the "permissive" flag.
+
 =back
 
 =head2 Paravirtualised (PV) Guest Specific Options
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Apr 03 14:46:27 2012 +0100
@@ -55,7 +55,10 @@ static void libxl_create_pci_backend_dev
     if (pcidev->vdevfn)
         flexarray_append_pair(back, libxl__sprintf(gc, "vdevfn-%d", num), libxl__sprintf(gc, "%x", pcidev->vdevfn));
     flexarray_append(back, libxl__sprintf(gc, "opts-%d", num));
-    flexarray_append(back, libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt));
+    flexarray_append(back,
+              libxl__sprintf(gc, "msitranslate=%d,power_mgmt=%d,permissive=%d",
+                             pcidev->msitranslate, pcidev->power_mgmt,
+                             pcidev->permissive));
     flexarray_append_pair(back, libxl__sprintf(gc, "state-%d", num), libxl__sprintf(gc, "%d", 1));
 }
 
@@ -565,6 +568,31 @@ static int do_pci_add(libxl__gc *gc, uin
             }
         }
         fclose(f);
+
+        /* Don't restrict writes to the PCI config space from this VM */
+        if (pcidev->permissive) {
+            int fd;
+            char *buf;
+            
+            sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive");
+            fd = open(sysfs_path, O_WRONLY);
+            if (fd < 0) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s",
+                                 sysfs_path);
+                return ERROR_FAIL;
+            }
+ 
+            buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus,
+                                 pcidev->dev, pcidev->func);
+            rc = write(fd, buf, strlen(buf));
+            /* Annoying to have two if's, but we need the errno */
+            if (rc < 0)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                                 "write to %s returned %d", sysfs_path, rc);
+            close(fd);
+            if (rc < 0)
+                return ERROR_FAIL;
+        }
         break;
     }
     default:
@@ -958,6 +986,9 @@ static void libxl__device_pci_from_xs_be
             } else if (!strcmp(p, "power_mgmt")) {
                 p = strtok_r(NULL, ",=", &saveptr);
                 pci->power_mgmt = atoi(p);
+            } else if (!strcmp(p, "permissive")) {
+                p = strtok_r(NULL, ",=", &saveptr);
+                pci->permissive = atoi(p);
             }
         } while ((p = strtok_r(NULL, ",=", &saveptr)) != NULL);
     }
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Apr 03 14:46:27 2012 +0100
@@ -352,6 +352,7 @@ libxl_device_pci = Struct("device_pci", 
     ("vfunc_mask", uint32),
     ("msitranslate", bool),
     ("power_mgmt", bool),
+    ("permissive", bool),
     ])
 
 libxl_diskinfo = Struct("diskinfo", [
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/libxlu_pci.c
--- a/tools/libxl/libxlu_pci.c	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/libxlu_pci.c	Tue Apr 03 14:46:27 2012 +0100
@@ -139,6 +139,8 @@ int xlu_pci_parse_bdf(XLU_Config *cfg, l
                     pcidev->msitranslate = atoi(tok);
                 }else if ( !strcmp(optkey, "power_mgmt") ) {
                     pcidev->power_mgmt = atoi(tok);
+                }else if ( !strcmp(optkey, "permissive") ) {
+                    pcidev->permissive = atoi(tok);
                 }else{
                     XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
                 }
diff -r 74bb52e4f6a6 -r 0625fe50a2ee tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Apr 02 15:54:08 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 14:46:27 2012 +0100
@@ -518,6 +518,7 @@ static void parse_config_data(const char
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
+    int pci_permissive = 0;
     int e;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -986,6 +987,9 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
+    if (!xlu_cfg_get_long (config, "pci_permissive", &l, 0))
+        pci_permissive = l;
+
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
@@ -1005,6 +1009,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
+            pcidev->permissive = pci_permissive;
             if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4I3-0002P1-AZ; Tue, 03 Apr 2012 14:00:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF4I1-0002OW-RT
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:00:53 +0000
Received: from [85.158.138.51:50092] by server-6.bemta-3.messagelabs.com id
	CC/7A-08206-5920B7F4; Tue, 03 Apr 2012 14:00:53 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333461649!20605800!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10013 invoked from network); 3 Apr 2012 14:00:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:00:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="188811996"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:00:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 10:00:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF4Hv-0001zy-EI;
	Tue, 03 Apr 2012 15:00:47 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333461291@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 14:54:51 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series adds the "permissive" option for passed-through devices
which access config space out of the "known good" PCI config space.

v2:
- Added patch to move bdf parsing to libxlu
- Addressed some formatting comments

v3:
- Don't make the struct initialization utility function public
- Return error on failure
- Wrap a long line
- Clarify security warning / recommendation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4I4-0002PK-NQ; Tue, 03 Apr 2012 14:00:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF4I3-0002Oo-5U
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:00:55 +0000
Received: from [85.158.138.51:50215] by server-12.bemta-3.messagelabs.com id
	37/15-30663-6920B7F4; Tue, 03 Apr 2012 14:00:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333461649!20605800!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10065 invoked from network); 3 Apr 2012 14:00:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:00:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="188812001"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:00:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 10:00:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF4Hv-0001zy-Er;
	Tue, 03 Apr 2012 15:00:47 +0100
MIME-Version: 1.0
X-Mercurial-Node: 74bb52e4f6a6e2b0c918f5b8d38e1c15a3b5242d
Message-ID: <74bb52e4f6a6e2b0c918.1333461292@kodo2>
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 14:54:52 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Config parsing functions do not properly belong in libxl.  Move them into
libxlu so that others can use them or not as they see fit.

No functional changes.  One side-effect was making public a private libxl
utility function which just set the elements of a structure from the  function
arguments passed in.

v2:
- Didn't make libxl_pci_dev_init() a public function; renamed to be more
descriptive

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/Makefile	Mon Apr 02 15:54:08 2012 +0100
@@ -57,7 +57,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-	libxlu_disk_l.o libxlu_disk.o
+	libxlu_disk_l.o libxlu_disk.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 CLIENTS = xl testidl
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Apr 02 15:54:08 2012 +0100
@@ -575,13 +575,6 @@ int libxl_device_pci_destroy(libxl_ctx *
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
 
 /*
- * Parse a PCI BDF into a PCI device structure.
- */
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
-                               libxl_device_pci *pcidev,
-                               const char *str);
-
-/*
  * Similar to libxl_device_pci_list but returns all devices which
  * could be assigned to a domain (i.e. are bound to the backend
  * driver) but are not currently.
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Apr 02 15:54:08 2012 +0100
@@ -34,9 +34,9 @@ static unsigned int pcidev_encode_bdf(li
     return value;
 }
 
-static int pcidev_init(libxl_device_pci *pcidev, unsigned int domain,
-                          unsigned int bus, unsigned int dev,
-                          unsigned int func, unsigned int vdevfn)
+static int pcidev_struct_fill(libxl_device_pci *pcidev, unsigned int domain,
+                               unsigned int bus, unsigned int dev,
+                               unsigned int func, unsigned int vdevfn)
 {
     pcidev->domain = domain;
     pcidev->bus = bus;
@@ -46,149 +46,6 @@ static int pcidev_init(libxl_device_pci 
     return 0;
 }
 
-static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
-{
-    unsigned long ret;
-    char *end;
-
-    ret = strtoul(str, &end, 16);
-    if ( end == str || *end != '\0' )
-        return -1;
-    if ( ret & ~mask )
-        return -1;
-    *val = (unsigned int)ret & mask;
-    return 0;
-}
-
-#define STATE_DOMAIN    0
-#define STATE_BUS       1
-#define STATE_DEV       2
-#define STATE_FUNC      3
-#define STATE_VSLOT     4
-#define STATE_OPTIONS_K 6
-#define STATE_OPTIONS_V 7
-#define STATE_TERMINAL  8
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx, libxl_device_pci *pcidev, const char *str)
-{
-    unsigned state = STATE_DOMAIN;
-    unsigned dom, bus, dev, func, vslot = 0;
-    char *buf2, *tok, *ptr, *end, *optkey = NULL;
-
-    if ( NULL == (buf2 = ptr = strdup(str)) )
-        return ERROR_NOMEM;
-
-    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
-        switch(state) {
-        case STATE_DOMAIN:
-            if ( *ptr == ':' ) {
-                state = STATE_BUS;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dom, 0xffff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_BUS:
-            if ( *ptr == ':' ) {
-                state = STATE_DEV;
-                *ptr = '\0';
-                if ( hex_convert(tok, &bus, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }else if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( dom & ~0xff )
-                    goto parse_error;
-                bus = dom;
-                dom = 0;
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_DEV:
-            if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_FUNC:
-            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
-                switch( *ptr ) {
-                case '\0':
-                    state = STATE_TERMINAL;
-                    break;
-                case '@':
-                    state = STATE_VSLOT;
-                    break;
-                case ',':
-                    state = STATE_OPTIONS_K;
-                    break;
-                }
-                *ptr = '\0';
-                if ( !strcmp(tok, "*") ) {
-                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
-                }else{
-                    if ( hex_convert(tok, &func, 0x7) )
-                        goto parse_error;
-                    pcidev->vfunc_mask = (1 << 0);
-                }
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_VSLOT:
-            if ( *ptr == '\0' || *ptr == ',' ) {
-                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( hex_convert(tok, &vslot, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_K:
-            if ( *ptr == '=' ) {
-                state = STATE_OPTIONS_V;
-                *ptr = '\0';
-                optkey = tok;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_V:
-            if ( *ptr == ',' || *ptr == '\0' ) {
-                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( !strcmp(optkey, "msitranslate") ) {
-                    pcidev->msitranslate = atoi(tok);
-                }else if ( !strcmp(optkey, "power_mgmt") ) {
-                    pcidev->power_mgmt = atoi(tok);
-                }else{
-                    LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
-                           "Unknown PCI BDF option: %s", optkey);
-                }
-                tok = ptr + 1;
-            }
-        default:
-            break;
-        }
-    }
-
-    free(buf2);
-
-    if ( tok != ptr || state != STATE_TERMINAL )
-        goto parse_error;
-
-    pcidev_init(pcidev, dom, bus, dev, func, vslot << 3);
-
-    return 0;
-
-parse_error:
-    return ERROR_INVAL;
-}
-
 static void libxl_create_pci_backend_device(libxl__gc *gc, flexarray_t *back, int num, libxl_device_pci *pcidev)
 {
     flexarray_append(back, libxl__sprintf(gc, "key-%d", num));
@@ -436,7 +293,7 @@ static int get_all_assigned_devices(libx
                     *list = realloc(*list, sizeof(libxl_device_pci) * ((*num) + 1));
                     if (*list == NULL)
                         return ERROR_NOMEM;
-                    pcidev_init(*list + *num, dom, bus, dev, func, 0);
+                    pcidev_struct_fill(*list + *num, dom, bus, dev, func, 0);
                     (*num)++;
                 }
             }
@@ -507,7 +364,7 @@ libxl_device_pci *libxl_device_pci_list_
         new = pcidevs + *num;
 
         memset(new, 0, sizeof(*new));
-        pcidev_init(new, dom, bus, dev, func, 0);
+        pcidev_struct_fill(new, dom, bus, dev, func, 0);
         (*num)++;
     }
 
@@ -1086,7 +943,7 @@ static void libxl__device_pci_from_xs_be
     if (s)
         vdevfn = strtol(s, (char **) NULL, 16);
 
-    pcidev_init(pci, domain, bus, dev, func, vdevfn);
+    pcidev_struct_fill(pci, domain, bus, dev, func, vdevfn);
 
     s = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/opts-%d", be_path, nr));
     if (s) {
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxlu_pci.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxlu_pci.c	Mon Apr 02 15:54:08 2012 +0100
@@ -0,0 +1,172 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "libxlu_disk_l.h"
+#include "libxlu_disk_i.h"
+#include "libxlu_cfg_i.h"
+
+
+#define XLU__PCI_ERR(_c, _x, _a...) \
+    if((_c) && (_c)->report) fprintf((_c)->report, _x, ##_a)
+
+static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
+{
+    unsigned long ret;
+    char *end;
+
+    ret = strtoul(str, &end, 16);
+    if ( end == str || *end != '\0' )
+        return -1;
+    if ( ret & ~mask )
+        return -1;
+    *val = (unsigned int)ret & mask;
+    return 0;
+}
+
+static int pcidev_struct_fill(libxl_device_pci *pcidev, unsigned int domain,
+                               unsigned int bus, unsigned int dev,
+                               unsigned int func, unsigned int vdevfn)
+{
+    pcidev->domain = domain;
+    pcidev->bus = bus;
+    pcidev->dev = dev;
+    pcidev->func = func;
+    pcidev->vdevfn = vdevfn;
+    return 0;
+}
+
+#define STATE_DOMAIN    0
+#define STATE_BUS       1
+#define STATE_DEV       2
+#define STATE_FUNC      3
+#define STATE_VSLOT     4
+#define STATE_OPTIONS_K 6
+#define STATE_OPTIONS_V 7
+#define STATE_TERMINAL  8
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str)
+{
+    unsigned state = STATE_DOMAIN;
+    unsigned dom, bus, dev, func, vslot = 0;
+    char *buf2, *tok, *ptr, *end, *optkey = NULL;
+
+    if ( NULL == (buf2 = ptr = strdup(str)) )
+        return ERROR_NOMEM;
+
+    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
+        switch(state) {
+        case STATE_DOMAIN:
+            if ( *ptr == ':' ) {
+                state = STATE_BUS;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dom, 0xffff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_BUS:
+            if ( *ptr == ':' ) {
+                state = STATE_DEV;
+                *ptr = '\0';
+                if ( hex_convert(tok, &bus, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }else if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( dom & ~0xff )
+                    goto parse_error;
+                bus = dom;
+                dom = 0;
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_DEV:
+            if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_FUNC:
+            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
+                switch( *ptr ) {
+                case '\0':
+                    state = STATE_TERMINAL;
+                    break;
+                case '@':
+                    state = STATE_VSLOT;
+                    break;
+                case ',':
+                    state = STATE_OPTIONS_K;
+                    break;
+                }
+                *ptr = '\0';
+                if ( !strcmp(tok, "*") ) {
+                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
+                }else{
+                    if ( hex_convert(tok, &func, 0x7) )
+                        goto parse_error;
+                    pcidev->vfunc_mask = (1 << 0);
+                }
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_VSLOT:
+            if ( *ptr == '\0' || *ptr == ',' ) {
+                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( hex_convert(tok, &vslot, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_K:
+            if ( *ptr == '=' ) {
+                state = STATE_OPTIONS_V;
+                *ptr = '\0';
+                optkey = tok;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_V:
+            if ( *ptr == ',' || *ptr == '\0' ) {
+                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( !strcmp(optkey, "msitranslate") ) {
+                    pcidev->msitranslate = atoi(tok);
+                }else if ( !strcmp(optkey, "power_mgmt") ) {
+                    pcidev->power_mgmt = atoi(tok);
+                }else{
+                    XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
+                }
+                tok = ptr + 1;
+            }
+        default:
+            break;
+        }
+    }
+
+    free(buf2);
+
+    if ( tok != ptr || state != STATE_TERMINAL )
+        goto parse_error;
+
+    /* Just a pretty way to fill in the values */
+    pcidev_struct_fill(pcidev, dom, bus, dev, func, vslot << 3);
+
+    return 0;
+
+parse_error:
+    return ERROR_INVAL;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxlutil.h	Mon Apr 02 15:54:08 2012 +0100
@@ -88,6 +88,11 @@ int xlu_disk_parse(XLU_Config *cfg, int 
    * resulting disk struct is used with libxl.
    */
 
+/*
+ * PCI specification parsing
+ */
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str);
+
 
 #endif /* LIBXLUTIL_H */
 
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 02 15:54:08 2012 +0100
@@ -1005,7 +1005,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
-            if (!libxl_device_pci_parse_bdf(ctx, pcidev, buf))
+            if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -2217,11 +2217,16 @@ int main_pcilist(int argc, char **argv)
 static void pcidetach(const char *dom, const char *bdf, int force)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+    
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-detach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
@@ -2257,11 +2262,16 @@ int main_pcidetach(int argc, char **argv
 static void pciattach(const char *dom, const char *bdf, const char *vs)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-attach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Apr 02 15:54:08 2012 +0100
@@ -40,6 +40,7 @@
 
 #include <libxl.h>
 #include <libxl_utils.h>
+#include <libxlutil.h>
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
@@ -556,7 +557,7 @@ static PyObject *pyxl_pci_parse(XlObject
         return NULL;
     }
 
-    if ( libxl_device_pci_parse_bdf(self->ctx, &pci->obj, str) ) {
+    if ( xlu_pci_parse_bdf(NULL, &pci->obj, str) ) {
         PyErr_SetString(xl_error_obj, "cannot parse pci device spec (BDF)");
         Py_DECREF(pci);
         return NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4I4-0002PK-NQ; Tue, 03 Apr 2012 14:00:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF4I3-0002Oo-5U
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:00:55 +0000
Received: from [85.158.138.51:50215] by server-12.bemta-3.messagelabs.com id
	37/15-30663-6920B7F4; Tue, 03 Apr 2012 14:00:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333461649!20605800!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10065 invoked from network); 3 Apr 2012 14:00:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:00:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="188812001"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 10:00:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 10:00:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF4Hv-0001zy-Er;
	Tue, 03 Apr 2012 15:00:47 +0100
MIME-Version: 1.0
X-Mercurial-Node: 74bb52e4f6a6e2b0c918f5b8d38e1c15a3b5242d
Message-ID: <74bb52e4f6a6e2b0c918.1333461292@kodo2>
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 14:54:52 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Config parsing functions do not properly belong in libxl.  Move them into
libxlu so that others can use them or not as they see fit.

No functional changes.  One side-effect was making public a private libxl
utility function which just set the elements of a structure from the  function
arguments passed in.

v2:
- Didn't make libxl_pci_dev_init() a public function; renamed to be more
descriptive

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/Makefile	Mon Apr 02 15:54:08 2012 +0100
@@ -57,7 +57,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-	libxlu_disk_l.o libxlu_disk.o
+	libxlu_disk_l.o libxlu_disk.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 CLIENTS = xl testidl
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Apr 02 15:54:08 2012 +0100
@@ -575,13 +575,6 @@ int libxl_device_pci_destroy(libxl_ctx *
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
 
 /*
- * Parse a PCI BDF into a PCI device structure.
- */
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx,
-                               libxl_device_pci *pcidev,
-                               const char *str);
-
-/*
  * Similar to libxl_device_pci_list but returns all devices which
  * could be assigned to a domain (i.e. are bound to the backend
  * driver) but are not currently.
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Apr 02 15:54:08 2012 +0100
@@ -34,9 +34,9 @@ static unsigned int pcidev_encode_bdf(li
     return value;
 }
 
-static int pcidev_init(libxl_device_pci *pcidev, unsigned int domain,
-                          unsigned int bus, unsigned int dev,
-                          unsigned int func, unsigned int vdevfn)
+static int pcidev_struct_fill(libxl_device_pci *pcidev, unsigned int domain,
+                               unsigned int bus, unsigned int dev,
+                               unsigned int func, unsigned int vdevfn)
 {
     pcidev->domain = domain;
     pcidev->bus = bus;
@@ -46,149 +46,6 @@ static int pcidev_init(libxl_device_pci 
     return 0;
 }
 
-static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
-{
-    unsigned long ret;
-    char *end;
-
-    ret = strtoul(str, &end, 16);
-    if ( end == str || *end != '\0' )
-        return -1;
-    if ( ret & ~mask )
-        return -1;
-    *val = (unsigned int)ret & mask;
-    return 0;
-}
-
-#define STATE_DOMAIN    0
-#define STATE_BUS       1
-#define STATE_DEV       2
-#define STATE_FUNC      3
-#define STATE_VSLOT     4
-#define STATE_OPTIONS_K 6
-#define STATE_OPTIONS_V 7
-#define STATE_TERMINAL  8
-int libxl_device_pci_parse_bdf(libxl_ctx *ctx, libxl_device_pci *pcidev, const char *str)
-{
-    unsigned state = STATE_DOMAIN;
-    unsigned dom, bus, dev, func, vslot = 0;
-    char *buf2, *tok, *ptr, *end, *optkey = NULL;
-
-    if ( NULL == (buf2 = ptr = strdup(str)) )
-        return ERROR_NOMEM;
-
-    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
-        switch(state) {
-        case STATE_DOMAIN:
-            if ( *ptr == ':' ) {
-                state = STATE_BUS;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dom, 0xffff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_BUS:
-            if ( *ptr == ':' ) {
-                state = STATE_DEV;
-                *ptr = '\0';
-                if ( hex_convert(tok, &bus, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }else if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( dom & ~0xff )
-                    goto parse_error;
-                bus = dom;
-                dom = 0;
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_DEV:
-            if ( *ptr == '.' ) {
-                state = STATE_FUNC;
-                *ptr = '\0';
-                if ( hex_convert(tok, &dev, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_FUNC:
-            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
-                switch( *ptr ) {
-                case '\0':
-                    state = STATE_TERMINAL;
-                    break;
-                case '@':
-                    state = STATE_VSLOT;
-                    break;
-                case ',':
-                    state = STATE_OPTIONS_K;
-                    break;
-                }
-                *ptr = '\0';
-                if ( !strcmp(tok, "*") ) {
-                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
-                }else{
-                    if ( hex_convert(tok, &func, 0x7) )
-                        goto parse_error;
-                    pcidev->vfunc_mask = (1 << 0);
-                }
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_VSLOT:
-            if ( *ptr == '\0' || *ptr == ',' ) {
-                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( hex_convert(tok, &vslot, 0xff) )
-                    goto parse_error;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_K:
-            if ( *ptr == '=' ) {
-                state = STATE_OPTIONS_V;
-                *ptr = '\0';
-                optkey = tok;
-                tok = ptr + 1;
-            }
-            break;
-        case STATE_OPTIONS_V:
-            if ( *ptr == ',' || *ptr == '\0' ) {
-                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
-                *ptr = '\0';
-                if ( !strcmp(optkey, "msitranslate") ) {
-                    pcidev->msitranslate = atoi(tok);
-                }else if ( !strcmp(optkey, "power_mgmt") ) {
-                    pcidev->power_mgmt = atoi(tok);
-                }else{
-                    LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
-                           "Unknown PCI BDF option: %s", optkey);
-                }
-                tok = ptr + 1;
-            }
-        default:
-            break;
-        }
-    }
-
-    free(buf2);
-
-    if ( tok != ptr || state != STATE_TERMINAL )
-        goto parse_error;
-
-    pcidev_init(pcidev, dom, bus, dev, func, vslot << 3);
-
-    return 0;
-
-parse_error:
-    return ERROR_INVAL;
-}
-
 static void libxl_create_pci_backend_device(libxl__gc *gc, flexarray_t *back, int num, libxl_device_pci *pcidev)
 {
     flexarray_append(back, libxl__sprintf(gc, "key-%d", num));
@@ -436,7 +293,7 @@ static int get_all_assigned_devices(libx
                     *list = realloc(*list, sizeof(libxl_device_pci) * ((*num) + 1));
                     if (*list == NULL)
                         return ERROR_NOMEM;
-                    pcidev_init(*list + *num, dom, bus, dev, func, 0);
+                    pcidev_struct_fill(*list + *num, dom, bus, dev, func, 0);
                     (*num)++;
                 }
             }
@@ -507,7 +364,7 @@ libxl_device_pci *libxl_device_pci_list_
         new = pcidevs + *num;
 
         memset(new, 0, sizeof(*new));
-        pcidev_init(new, dom, bus, dev, func, 0);
+        pcidev_struct_fill(new, dom, bus, dev, func, 0);
         (*num)++;
     }
 
@@ -1086,7 +943,7 @@ static void libxl__device_pci_from_xs_be
     if (s)
         vdevfn = strtol(s, (char **) NULL, 16);
 
-    pcidev_init(pci, domain, bus, dev, func, vdevfn);
+    pcidev_struct_fill(pci, domain, bus, dev, func, vdevfn);
 
     s = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/opts-%d", be_path, nr));
     if (s) {
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxlu_pci.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxlu_pci.c	Mon Apr 02 15:54:08 2012 +0100
@@ -0,0 +1,172 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "libxlu_disk_l.h"
+#include "libxlu_disk_i.h"
+#include "libxlu_cfg_i.h"
+
+
+#define XLU__PCI_ERR(_c, _x, _a...) \
+    if((_c) && (_c)->report) fprintf((_c)->report, _x, ##_a)
+
+static int hex_convert(const char *str, unsigned int *val, unsigned int mask)
+{
+    unsigned long ret;
+    char *end;
+
+    ret = strtoul(str, &end, 16);
+    if ( end == str || *end != '\0' )
+        return -1;
+    if ( ret & ~mask )
+        return -1;
+    *val = (unsigned int)ret & mask;
+    return 0;
+}
+
+static int pcidev_struct_fill(libxl_device_pci *pcidev, unsigned int domain,
+                               unsigned int bus, unsigned int dev,
+                               unsigned int func, unsigned int vdevfn)
+{
+    pcidev->domain = domain;
+    pcidev->bus = bus;
+    pcidev->dev = dev;
+    pcidev->func = func;
+    pcidev->vdevfn = vdevfn;
+    return 0;
+}
+
+#define STATE_DOMAIN    0
+#define STATE_BUS       1
+#define STATE_DEV       2
+#define STATE_FUNC      3
+#define STATE_VSLOT     4
+#define STATE_OPTIONS_K 6
+#define STATE_OPTIONS_V 7
+#define STATE_TERMINAL  8
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str)
+{
+    unsigned state = STATE_DOMAIN;
+    unsigned dom, bus, dev, func, vslot = 0;
+    char *buf2, *tok, *ptr, *end, *optkey = NULL;
+
+    if ( NULL == (buf2 = ptr = strdup(str)) )
+        return ERROR_NOMEM;
+
+    for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
+        switch(state) {
+        case STATE_DOMAIN:
+            if ( *ptr == ':' ) {
+                state = STATE_BUS;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dom, 0xffff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_BUS:
+            if ( *ptr == ':' ) {
+                state = STATE_DEV;
+                *ptr = '\0';
+                if ( hex_convert(tok, &bus, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }else if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( dom & ~0xff )
+                    goto parse_error;
+                bus = dom;
+                dom = 0;
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_DEV:
+            if ( *ptr == '.' ) {
+                state = STATE_FUNC;
+                *ptr = '\0';
+                if ( hex_convert(tok, &dev, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_FUNC:
+            if ( *ptr == '\0' || *ptr == '@' || *ptr == ',' ) {
+                switch( *ptr ) {
+                case '\0':
+                    state = STATE_TERMINAL;
+                    break;
+                case '@':
+                    state = STATE_VSLOT;
+                    break;
+                case ',':
+                    state = STATE_OPTIONS_K;
+                    break;
+                }
+                *ptr = '\0';
+                if ( !strcmp(tok, "*") ) {
+                    pcidev->vfunc_mask = LIBXL_PCI_FUNC_ALL;
+                }else{
+                    if ( hex_convert(tok, &func, 0x7) )
+                        goto parse_error;
+                    pcidev->vfunc_mask = (1 << 0);
+                }
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_VSLOT:
+            if ( *ptr == '\0' || *ptr == ',' ) {
+                state = ( *ptr == ',' ) ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( hex_convert(tok, &vslot, 0xff) )
+                    goto parse_error;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_K:
+            if ( *ptr == '=' ) {
+                state = STATE_OPTIONS_V;
+                *ptr = '\0';
+                optkey = tok;
+                tok = ptr + 1;
+            }
+            break;
+        case STATE_OPTIONS_V:
+            if ( *ptr == ',' || *ptr == '\0' ) {
+                state = (*ptr == ',') ? STATE_OPTIONS_K : STATE_TERMINAL;
+                *ptr = '\0';
+                if ( !strcmp(optkey, "msitranslate") ) {
+                    pcidev->msitranslate = atoi(tok);
+                }else if ( !strcmp(optkey, "power_mgmt") ) {
+                    pcidev->power_mgmt = atoi(tok);
+                }else{
+                    XLU__PCI_ERR(cfg, "Unknown PCI BDF option: %s", optkey);
+                }
+                tok = ptr + 1;
+            }
+        default:
+            break;
+        }
+    }
+
+    free(buf2);
+
+    if ( tok != ptr || state != STATE_TERMINAL )
+        goto parse_error;
+
+    /* Just a pretty way to fill in the values */
+    pcidev_struct_fill(pcidev, dom, bus, dev, func, vslot << 3);
+
+    return 0;
+
+parse_error:
+    return ERROR_INVAL;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxlutil.h	Mon Apr 02 15:54:08 2012 +0100
@@ -88,6 +88,11 @@ int xlu_disk_parse(XLU_Config *cfg, int 
    * resulting disk struct is used with libxl.
    */
 
+/*
+ * PCI specification parsing
+ */
+int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev, const char *str);
+
 
 #endif /* LIBXLUTIL_H */
 
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 02 15:54:08 2012 +0100
@@ -1005,7 +1005,7 @@ skip_vfb:
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;
-            if (!libxl_device_pci_parse_bdf(ctx, pcidev, buf))
+            if (!xlu_pci_parse_bdf(config, pcidev, buf))
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -2217,11 +2217,16 @@ int main_pcilist(int argc, char **argv)
 static void pcidetach(const char *dom, const char *bdf, int force)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+    
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-detach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
@@ -2257,11 +2262,16 @@ int main_pcidetach(int argc, char **argv
 static void pciattach(const char *dom, const char *bdf, const char *vs)
 {
     libxl_device_pci pcidev;
+    XLU_Config *config;
 
     find_domain(dom);
 
     memset(&pcidev, 0x00, sizeof(pcidev));
-    if (libxl_device_pci_parse_bdf(ctx, &pcidev, bdf)) {
+
+    config = xlu_cfg_init(stderr, "command line");
+    if (!config) { perror("xlu_cfg_inig"); exit(-1); }
+
+    if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
         fprintf(stderr, "pci-attach: malformed BDF specification \"%s\"\n", bdf);
         exit(2);
     }
diff -r f744e82ea740 -r 74bb52e4f6a6 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Apr 02 15:54:08 2012 +0100
@@ -40,6 +40,7 @@
 
 #include <libxl.h>
 #include <libxl_utils.h>
+#include <libxlutil.h>
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
@@ -556,7 +557,7 @@ static PyObject *pyxl_pci_parse(XlObject
         return NULL;
     }
 
-    if ( libxl_device_pci_parse_bdf(self->ctx, &pci->obj, str) ) {
+    if ( xlu_pci_parse_bdf(NULL, &pci->obj, str) ) {
         PyErr_SetString(xl_error_obj, "cannot parse pci device spec (BDF)");
         Py_DECREF(pci);
         return NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4IY-0002VU-5y; Tue, 03 Apr 2012 14:01:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4IW-0002V6-Tk
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:01:25 +0000
Received: from [85.158.138.51:33805] by server-8.bemta-3.messagelabs.com id
	9F/E5-29305-4B20B7F4; Tue, 03 Apr 2012 14:01:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333461683!20569169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27938 invoked from network); 3 Apr 2012 14:01:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:01:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:01:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:01:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4IU-000579-Ig; Tue, 03 Apr 2012 14:01:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4IU-0001w2-H9;
	Tue, 03 Apr 2012 15:01:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.690.289938.138564@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:01:22 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332246275-13648-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v6 2/3] libxl: save/restore qemu's physmap"):
> Read Qemu's physmap from xenstore and save it using toolstack_save.
> Restore Qemu's physmap using toolstack_restore.

> +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +        uint32_t size, void *data)
...
> +    if (size < sizeof(version) + sizeof(count))
> +        return -1;
> +
> +    memcpy(&version, ptr, sizeof(version));
> +    ptr += sizeof(version);
> +
> +    if (version != TOOLSTACK_SAVE_VERSION)
> +        return -1;

Surely these error exits need log messages.

> +    for (i = 0; i < count; i++) {
> +        pi = (struct libxl__physmap_info*) ptr;
> +        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",

Long line.

> +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
> +        if (ret)
> +            return -1;
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, pi->phys_offset), "%"PRIx64, pi->size);

This whole thing contains a lot of repetitive code.  Can you perhaps
break the xs_write into a helper function and then you'd make the
repetition more explicit by writing something like:

           helper(gc, domid, "start_addr", "%"PRIx64, pi->start_addr);
           helper(gc, domid, "name",       "%"PRIx64, pi->size);
           if (pi->namelen)
                helper(gc, domid, "name",       "%s",      pi->name);

> +static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +        uint32_t *len, void *data)
> +{
...
> +    *buf = calloc(1, *len);

Surely this should come from the gc.

> +        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
> +                    domid, phys_offset));
> +        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/size",
> +                    domid, phys_offset));
> +        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/name",
> +                    domid, phys_offset));

Again, quite a lot of repetition which obscures the similarities
between the different calls.

> +        if (start_addr == NULL || size == NULL || phys_offset == NULL)
> +            return -1;

This seems a rather odd condition.  Surely it is an error if only some
of these parameters are in xenstore ?

> +        if (name == NULL)
> +            namelen = 0;
> +        else
> +            namelen = strlen(name) + 1;
> +        *len += namelen + sizeof(struct libxl__physmap_info);
> +        offset = ptr - (*buf);
> +        *buf = realloc(*buf, *len);

Shouldn't this come from the gc ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:01:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4IY-0002VU-5y; Tue, 03 Apr 2012 14:01:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4IW-0002V6-Tk
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:01:25 +0000
Received: from [85.158.138.51:33805] by server-8.bemta-3.messagelabs.com id
	9F/E5-29305-4B20B7F4; Tue, 03 Apr 2012 14:01:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333461683!20569169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27938 invoked from network); 3 Apr 2012 14:01:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:01:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:01:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:01:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4IU-000579-Ig; Tue, 03 Apr 2012 14:01:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4IU-0001w2-H9;
	Tue, 03 Apr 2012 15:01:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.690.289938.138564@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:01:22 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332246275-13648-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v6 2/3] libxl: save/restore qemu's physmap"):
> Read Qemu's physmap from xenstore and save it using toolstack_save.
> Restore Qemu's physmap using toolstack_restore.

> +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +        uint32_t size, void *data)
...
> +    if (size < sizeof(version) + sizeof(count))
> +        return -1;
> +
> +    memcpy(&version, ptr, sizeof(version));
> +    ptr += sizeof(version);
> +
> +    if (version != TOOLSTACK_SAVE_VERSION)
> +        return -1;

Surely these error exits need log messages.

> +    for (i = 0; i < count; i++) {
> +        pi = (struct libxl__physmap_info*) ptr;
> +        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",

Long line.

> +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
> +        if (ret)
> +            return -1;
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, pi->phys_offset), "%"PRIx64, pi->size);

This whole thing contains a lot of repetitive code.  Can you perhaps
break the xs_write into a helper function and then you'd make the
repetition more explicit by writing something like:

           helper(gc, domid, "start_addr", "%"PRIx64, pi->start_addr);
           helper(gc, domid, "name",       "%"PRIx64, pi->size);
           if (pi->namelen)
                helper(gc, domid, "name",       "%s",      pi->name);

> +static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +        uint32_t *len, void *data)
> +{
...
> +    *buf = calloc(1, *len);

Surely this should come from the gc.

> +        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
> +                    domid, phys_offset));
> +        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/size",
> +                    domid, phys_offset));
> +        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/name",
> +                    domid, phys_offset));

Again, quite a lot of repetition which obscures the similarities
between the different calls.

> +        if (start_addr == NULL || size == NULL || phys_offset == NULL)
> +            return -1;

This seems a rather odd condition.  Surely it is an error if only some
of these parameters are in xenstore ?

> +        if (name == NULL)
> +            namelen = 0;
> +        else
> +            namelen = strlen(name) + 1;
> +        *len += namelen + sizeof(struct libxl__physmap_info);
> +        offset = ptr - (*buf);
> +        *buf = realloc(*buf, *len);

Shouldn't this come from the gc ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4JO-0002f7-KG; Tue, 03 Apr 2012 14:02:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4JN-0002em-7E
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:02:17 +0000
Received: from [85.158.143.99:2603] by server-3.bemta-4.messagelabs.com id
	13/80-05853-8E20B7F4; Tue, 03 Apr 2012 14:02:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333461735!16910460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6725 invoked from network); 3 Apr 2012 14:02:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:02:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:02:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:02:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4JK-00057Y-Rl; Tue, 03 Apr 2012 14:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4JK-0001wK-PM;
	Tue, 03 Apr 2012 15:02:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.742.768963.36907@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:02:14 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <4F7B0122.9090602@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
	<4F7B0122.9090602@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> On 04/03/2012 02:31 PM, Ian Jackson wrote:
> > Are the PCI addresses not assigned in a deterministic fashion by code
> > in qemu-dm, in this case in the qemu-dm which is emulating the pci
> > bridge ?  If not then that needs to be fixed, surely ?
> 
> Indeed but each QEMU emulate a subset of the hardware.
> So how QEMU can know the available PCI addresses ?
> I think that toolstack must allocate the BDF, otherwise we need to have
> communication between each qemu-dm.

Currently the bdfs are allocated by the single qemu-dm, right ?  Why
cannot that functionality stay there, with the pci bridge emulation ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4JO-0002f7-KG; Tue, 03 Apr 2012 14:02:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4JN-0002em-7E
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:02:17 +0000
Received: from [85.158.143.99:2603] by server-3.bemta-4.messagelabs.com id
	13/80-05853-8E20B7F4; Tue, 03 Apr 2012 14:02:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333461735!16910460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6725 invoked from network); 3 Apr 2012 14:02:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:02:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:02:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:02:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4JK-00057Y-Rl; Tue, 03 Apr 2012 14:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4JK-0001wK-PM;
	Tue, 03 Apr 2012 15:02:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.742.768963.36907@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:02:14 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <4F7B0122.9090602@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
	<4F7B0122.9090602@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> On 04/03/2012 02:31 PM, Ian Jackson wrote:
> > Are the PCI addresses not assigned in a deterministic fashion by code
> > in qemu-dm, in this case in the qemu-dm which is emulating the pci
> > bridge ?  If not then that needs to be fixed, surely ?
> 
> Indeed but each QEMU emulate a subset of the hardware.
> So how QEMU can know the available PCI addresses ?
> I think that toolstack must allocate the BDF, otherwise we need to have
> communication between each qemu-dm.

Currently the bdfs are allocated by the single qemu-dm, right ?  Why
cannot that functionality stay there, with the pci bridge emulation ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4MJ-0003Ae-2x; Tue, 03 Apr 2012 14:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4MH-0003AO-VO
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:05:18 +0000
Received: from [85.158.138.51:18097] by server-12.bemta-3.messagelabs.com id
	1B/AF-30663-D930B7F4; Tue, 03 Apr 2012 14:05:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333461915!20637678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15027 invoked from network); 3 Apr 2012 14:05:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:05:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:05:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:05:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4M2-00058d-OG; Tue, 03 Apr 2012 14:05:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4M2-0001wa-Mn;
	Tue, 03 Apr 2012 15:05:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.910.685557.275760@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:05:02 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332246275-13648-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v6 3/3] libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save"):
> Following the recent changes to upstream Qemu, the best monitor command
> to suit or needs is "xen-save-devices-state" rather than "migrate".
> This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
> instead, that uses "xen-save-devices-state".

This looks plausible to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Note that the meat of qmp_send_fd will need to be reintroduced in my
child process series, but I think it's fine for you to delete it here
and for me to later reintroduce it with a different name and
functionality and in a different file.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4MJ-0003Ae-2x; Tue, 03 Apr 2012 14:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4MH-0003AO-VO
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:05:18 +0000
Received: from [85.158.138.51:18097] by server-12.bemta-3.messagelabs.com id
	1B/AF-30663-D930B7F4; Tue, 03 Apr 2012 14:05:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333461915!20637678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15027 invoked from network); 3 Apr 2012 14:05:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:05:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:05:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:05:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4M2-00058d-OG; Tue, 03 Apr 2012 14:05:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4M2-0001wa-Mn;
	Tue, 03 Apr 2012 15:05:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.910.685557.275760@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:05:02 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332246275-13648-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v6 3/3] libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save"):
> Following the recent changes to upstream Qemu, the best monitor command
> to suit or needs is "xen-save-devices-state" rather than "migrate".
> This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
> instead, that uses "xen-save-devices-state".

This looks plausible to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Note that the meat of qmp_send_fd will need to be reintroduced in my
child process series, but I think it's fine for you to delete it here
and for me to later reintroduce it with a different name and
functionality and in a different file.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Pe-0003XC-MR; Tue, 03 Apr 2012 14:08:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF4Pd-0003Wy-DG
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:08:45 +0000
Received: from [85.158.143.35:19397] by server-2.bemta-4.messagelabs.com id
	6C/51-17550-C640B7F4; Tue, 03 Apr 2012 14:08:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333462073!7460688!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzk2Nzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzk2Nzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10236 invoked from network); 3 Apr 2012 14:07:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 14:07:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333462073; l=1014;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mvJY/B+DfBxisD/FxNSUXaQXASs=;
	b=DeiD5boWsC8k5QxB+pi6lye53fwz1i9nKoYCOVKHDPXixKjSP162EUxsR3+5kzjQ3oP
	UsjVBHooeF8NjHwhNWIQ30lRdj1oyNu+5i3shBYj5vcB0kXCkzTcS/5rGP30rJzW8V0/Q
	4s8cnVB3K9EtT1HjRaHTsJSpYquofJe/2qY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (jimi mo8) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f036f7o33DVjT7 ;
	Tue, 3 Apr 2012 16:07:52 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 05F6A18637; Tue,  3 Apr 2012 16:07:51 +0200 (CEST)
Date: Tue, 3 Apr 2012 16:07:51 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120403140751.GA4553@aepfle.de>
References: <6685b67958b0623064c7.1332321259@probook.site>
	<20346.63753.211063.200875@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20346.63753.211063.200875@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> > tools/vtpm: use LDLIBS to pass -lgmp
> > 
> > Linking tpmd will fail with recent toolchains because -lgmp is passed
> > via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the
> > end of the gcc cmdline and linking tpmd succeeds again.
> ...
> >   CFLAGS  += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
> >  +CFLAGS  += -I../../../../tools/vtpm_manager/manager
> > - LDFLAGS += -lgmp
> > + LDLIBS  += -lgmp
> >   
> >  -BINDIR  := /usr/sbin/
> >  +BINDIR  := /usr/bin/
> 
> Please could you make sure not to include unrelated changes in your
> patches.  That makes the job of the reviewer /much/ harder, because we
> would have to inspect every hunk of your patches looking for this kind
> of thing creeping in.

This patch changes a patch file for vtpm which has LDFLAGS in the
context around the changed lines.
See the space between the '-' and LDFLAGS.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Pe-0003XC-MR; Tue, 03 Apr 2012 14:08:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF4Pd-0003Wy-DG
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:08:45 +0000
Received: from [85.158.143.35:19397] by server-2.bemta-4.messagelabs.com id
	6C/51-17550-C640B7F4; Tue, 03 Apr 2012 14:08:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333462073!7460688!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzk2Nzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzk2Nzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10236 invoked from network); 3 Apr 2012 14:07:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 14:07:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333462073; l=1014;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mvJY/B+DfBxisD/FxNSUXaQXASs=;
	b=DeiD5boWsC8k5QxB+pi6lye53fwz1i9nKoYCOVKHDPXixKjSP162EUxsR3+5kzjQ3oP
	UsjVBHooeF8NjHwhNWIQ30lRdj1oyNu+5i3shBYj5vcB0kXCkzTcS/5rGP30rJzW8V0/Q
	4s8cnVB3K9EtT1HjRaHTsJSpYquofJe/2qY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (jimi mo8) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f036f7o33DVjT7 ;
	Tue, 3 Apr 2012 16:07:52 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 05F6A18637; Tue,  3 Apr 2012 16:07:51 +0200 (CEST)
Date: Tue, 3 Apr 2012 16:07:51 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120403140751.GA4553@aepfle.de>
References: <6685b67958b0623064c7.1332321259@probook.site>
	<20346.63753.211063.200875@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20346.63753.211063.200875@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> > tools/vtpm: use LDLIBS to pass -lgmp
> > 
> > Linking tpmd will fail with recent toolchains because -lgmp is passed
> > via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the
> > end of the gcc cmdline and linking tpmd succeeds again.
> ...
> >   CFLAGS  += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
> >  +CFLAGS  += -I../../../../tools/vtpm_manager/manager
> > - LDFLAGS += -lgmp
> > + LDLIBS  += -lgmp
> >   
> >  -BINDIR  := /usr/sbin/
> >  +BINDIR  := /usr/bin/
> 
> Please could you make sure not to include unrelated changes in your
> patches.  That makes the job of the reviewer /much/ harder, because we
> would have to inspect every hunk of your patches looking for this kind
> of thing creeping in.

This patch changes a patch file for vtpm which has LDFLAGS in the
context around the changed lines.
See the space between the '-' and LDFLAGS.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4R4-0003g1-5m; Tue, 03 Apr 2012 14:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4R2-0003fn-KR
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:10:12 +0000
Received: from [85.158.143.99:41115] by server-3.bemta-4.messagelabs.com id
	B4/62-05853-3C40B7F4; Tue, 03 Apr 2012 14:10:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333462211!21843831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2559 invoked from network); 3 Apr 2012 14:10:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:10:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:10:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:10:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4Qq-0005A4-DZ; Tue, 03 Apr 2012 14:10:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4Qq-0001xV-CU;
	Tue, 03 Apr 2012 15:10:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1208.367679.398474@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:10:00 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120403140751.GA4553@aepfle.de>
References: <6685b67958b0623064c7.1332321259@probook.site>
	<20346.63753.211063.200875@mariner.uk.xensource.com>
	<20120403140751.GA4553@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> On Tue, Apr 03, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> > > tools/vtpm: use LDLIBS to pass -lgmp
> > > 
> > > Linking tpmd will fail with recent toolchains because -lgmp is passed
> > > via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the
> > > end of the gcc cmdline and linking tpmd succeeds again.
> > ...
> > >   CFLAGS  += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
> > >  +CFLAGS  += -I../../../../tools/vtpm_manager/manager
> > > - LDFLAGS += -lgmp
> > > + LDLIBS  += -lgmp
> > >   
> > >  -BINDIR  := /usr/sbin/
> > >  +BINDIR  := /usr/bin/
> > 
> > Please could you make sure not to include unrelated changes in your
> > patches.  That makes the job of the reviewer /much/ harder, because we
> > would have to inspect every hunk of your patches looking for this kind
> > of thing creeping in.
> 
> This patch changes a patch file for vtpm which has LDFLAGS in the
> context around the changed lines.
> See the space between the '-' and LDFLAGS.

Oh, god, I missed that.  Sorry.  I will apply your patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4R4-0003g1-5m; Tue, 03 Apr 2012 14:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4R2-0003fn-KR
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:10:12 +0000
Received: from [85.158.143.99:41115] by server-3.bemta-4.messagelabs.com id
	B4/62-05853-3C40B7F4; Tue, 03 Apr 2012 14:10:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333462211!21843831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2559 invoked from network); 3 Apr 2012 14:10:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:10:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:10:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:10:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4Qq-0005A4-DZ; Tue, 03 Apr 2012 14:10:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4Qq-0001xV-CU;
	Tue, 03 Apr 2012 15:10:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1208.367679.398474@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:10:00 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120403140751.GA4553@aepfle.de>
References: <6685b67958b0623064c7.1332321259@probook.site>
	<20346.63753.211063.200875@mariner.uk.xensource.com>
	<20120403140751.GA4553@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> On Tue, Apr 03, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> > > tools/vtpm: use LDLIBS to pass -lgmp
> > > 
> > > Linking tpmd will fail with recent toolchains because -lgmp is passed
> > > via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the
> > > end of the gcc cmdline and linking tpmd succeeds again.
> > ...
> > >   CFLAGS  += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
> > >  +CFLAGS  += -I../../../../tools/vtpm_manager/manager
> > > - LDFLAGS += -lgmp
> > > + LDLIBS  += -lgmp
> > >   
> > >  -BINDIR  := /usr/sbin/
> > >  +BINDIR  := /usr/bin/
> > 
> > Please could you make sure not to include unrelated changes in your
> > patches.  That makes the job of the reviewer /much/ harder, because we
> > would have to inspect every hunk of your patches looking for this kind
> > of thing creeping in.
> 
> This patch changes a patch file for vtpm which has LDFLAGS in the
> context around the changed lines.
> See the space between the '-' and LDFLAGS.

Oh, god, I missed that.  Sorry.  I will apply your patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:11:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4SI-0003mr-LE; Tue, 03 Apr 2012 14:11:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4SH-0003mg-5Z
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:11:29 +0000
Received: from [85.158.143.99:52489] by server-2.bemta-4.messagelabs.com id
	D5/17-17550-0150B7F4; Tue, 03 Apr 2012 14:11:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333462288!18776126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13210 invoked from network); 3 Apr 2012 14:11:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:11:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:11:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:11:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4SF-0005Aj-FL; Tue, 03 Apr 2012 14:11:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4SF-0001xe-EP;
	Tue, 03 Apr 2012 15:11:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1295.429766.715415@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:11:27 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F68A391.90500@tiscali.it>
References: <4F68A391.90500@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
	to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] Autoconf: add variable for pass arbitrary options to qemu upstream"):
> Autoconf: add variable for pass arbitrary options to qemu upstream
> diff -r 4e1d091d10d8 -r c86e026b8fa2 tools/configure.ac
> --- a/tools/configure.ac	ven mar 16 15:24:25 2012 +0000
> +++ b/tools/configure.ac	mar mar 20 13:57:09 2012 +0100
> @@ -66,6 +66,7 @@
>  AC_ARG_VAR([XML], [Path to xml2-config tool])
>  AC_ARG_VAR([BASH], [Path to bash shell])
>  AC_ARG_VAR([XGETTEXT], [Path to xgetttext tool])
> +AC_ARG_VAR([QEMUU_ADD_PAR], [List of qemu upstream additionals build parameters])

Wouldn't this be better done with AC_ARG_ENABLE rather than some magic
environment variable ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:11:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4SI-0003mr-LE; Tue, 03 Apr 2012 14:11:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4SH-0003mg-5Z
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:11:29 +0000
Received: from [85.158.143.99:52489] by server-2.bemta-4.messagelabs.com id
	D5/17-17550-0150B7F4; Tue, 03 Apr 2012 14:11:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333462288!18776126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13210 invoked from network); 3 Apr 2012 14:11:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:11:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:11:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:11:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4SF-0005Aj-FL; Tue, 03 Apr 2012 14:11:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4SF-0001xe-EP;
	Tue, 03 Apr 2012 15:11:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1295.429766.715415@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:11:27 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F68A391.90500@tiscali.it>
References: <4F68A391.90500@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
	to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] Autoconf: add variable for pass arbitrary options to qemu upstream"):
> Autoconf: add variable for pass arbitrary options to qemu upstream
> diff -r 4e1d091d10d8 -r c86e026b8fa2 tools/configure.ac
> --- a/tools/configure.ac	ven mar 16 15:24:25 2012 +0000
> +++ b/tools/configure.ac	mar mar 20 13:57:09 2012 +0100
> @@ -66,6 +66,7 @@
>  AC_ARG_VAR([XML], [Path to xml2-config tool])
>  AC_ARG_VAR([BASH], [Path to bash shell])
>  AC_ARG_VAR([XGETTEXT], [Path to xgetttext tool])
> +AC_ARG_VAR([QEMUU_ADD_PAR], [List of qemu upstream additionals build parameters])

Wouldn't this be better done with AC_ARG_ENABLE rather than some magic
environment variable ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:14:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4VA-00042S-8x; Tue, 03 Apr 2012 14:14:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF4V9-00042K-C6
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:14:27 +0000
Received: from [85.158.143.35:39435] by server-1.bemta-4.messagelabs.com id
	6B/8E-20925-2C50B7F4; Tue, 03 Apr 2012 14:14:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333462461!14518485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10912 invoked from network); 3 Apr 2012 14:14:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:14:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:14:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:14:20 +0100
Date: Tue, 3 Apr 2012 15:16:33 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.742.768963.36907@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031515040.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
	<4F7B0122.9090602@citrix.com>
	<20347.742.768963.36907@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Julien Grall writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> > On 04/03/2012 02:31 PM, Ian Jackson wrote:
> > > Are the PCI addresses not assigned in a deterministic fashion by code
> > > in qemu-dm, in this case in the qemu-dm which is emulating the pci
> > > bridge ?  If not then that needs to be fixed, surely ?
> > 
> > Indeed but each QEMU emulate a subset of the hardware.
> > So how QEMU can know the available PCI addresses ?
> > I think that toolstack must allocate the BDF, otherwise we need to have
> > communication between each qemu-dm.
> 
> Currently the bdfs are allocated by the single qemu-dm, right ?  Why
> cannot that functionality stay there, with the pci bridge emulation ?
 
Because the allocation of most BDFs in QEMU is done ad-hoc in a first
come first served basis. If the first QEMU is not going to emulate these
devices then it is not going to allocate the BDF for them either.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:14:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4VA-00042S-8x; Tue, 03 Apr 2012 14:14:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF4V9-00042K-C6
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:14:27 +0000
Received: from [85.158.143.35:39435] by server-1.bemta-4.messagelabs.com id
	6B/8E-20925-2C50B7F4; Tue, 03 Apr 2012 14:14:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333462461!14518485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10912 invoked from network); 3 Apr 2012 14:14:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:14:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:14:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:14:20 +0100
Date: Tue, 3 Apr 2012 15:16:33 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.742.768963.36907@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031515040.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
	<4F7B0122.9090602@citrix.com>
	<20347.742.768963.36907@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Julien Grall writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> > On 04/03/2012 02:31 PM, Ian Jackson wrote:
> > > Are the PCI addresses not assigned in a deterministic fashion by code
> > > in qemu-dm, in this case in the qemu-dm which is emulating the pci
> > > bridge ?  If not then that needs to be fixed, surely ?
> > 
> > Indeed but each QEMU emulate a subset of the hardware.
> > So how QEMU can know the available PCI addresses ?
> > I think that toolstack must allocate the BDF, otherwise we need to have
> > communication between each qemu-dm.
> 
> Currently the bdfs are allocated by the single qemu-dm, right ?  Why
> cannot that functionality stay there, with the pci bridge emulation ?
 
Because the allocation of most BDFs in QEMU is done ad-hoc in a first
come first served basis. If the first QEMU is not going to emulate these
devices then it is not going to allocate the BDF for them either.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:17:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Xi-0004CI-Sd; Tue, 03 Apr 2012 14:17:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF4Xh-0004CD-DS
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:17:05 +0000
Received: from [85.158.138.51:23437] by server-10.bemta-3.messagelabs.com id
	91/30-15637-0660B7F4; Tue, 03 Apr 2012 14:17:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333462623!20594740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8350 invoked from network); 3 Apr 2012 14:17:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:17:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:17:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:17:03 +0100
Date: Tue, 3 Apr 2012 15:19:26 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20346.63616.101912.260089@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> > I don't feel that strongly about this, but given that the naming scheme
> > used in the guest is actually arbitrary at the moment (as in not document
> > or well defined anywhere), I would start the dynamic space before the
> > 26th device: I have the feeling that after "xvdz" the behavior is going
> > to be even less "defined". I suggest "xvdm" as a starting point.
> 
> That's fine, if the starting point is configurable.

I don't think it is worth adding one more option for something like
this: nobody should be using this option anyway. I am still unconvinced
there is a valid use case for this.
Can't we just agree on a starting point, any really?


> > > However, that does not mean that the guest should not document its
> > > naming conventions.  Perhaps this needs to be clarified in the
> > > document.
> > 
> > Right, but unless I am missing something there isn't such a thing at the
> > moment, at least in Linux.
> > 
> > I'll try to come up with a linux devid to vdev function true to the
> > original.
> 
> That would be good.  If you felt like documenting the Linux behaviour
> properly that would be good.  The section "Notes on Linux as a guest"
> in docs/misc/vbd-interface.text.

the best place for this would be in the Linux Documentation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:17:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Xi-0004CI-Sd; Tue, 03 Apr 2012 14:17:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF4Xh-0004CD-DS
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:17:05 +0000
Received: from [85.158.138.51:23437] by server-10.bemta-3.messagelabs.com id
	91/30-15637-0660B7F4; Tue, 03 Apr 2012 14:17:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333462623!20594740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8350 invoked from network); 3 Apr 2012 14:17:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:17:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11747964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:17:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:17:03 +0100
Date: Tue, 3 Apr 2012 15:19:26 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20346.63616.101912.260089@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> > I don't feel that strongly about this, but given that the naming scheme
> > used in the guest is actually arbitrary at the moment (as in not document
> > or well defined anywhere), I would start the dynamic space before the
> > 26th device: I have the feeling that after "xvdz" the behavior is going
> > to be even less "defined". I suggest "xvdm" as a starting point.
> 
> That's fine, if the starting point is configurable.

I don't think it is worth adding one more option for something like
this: nobody should be using this option anyway. I am still unconvinced
there is a valid use case for this.
Can't we just agree on a starting point, any really?


> > > However, that does not mean that the guest should not document its
> > > naming conventions.  Perhaps this needs to be clarified in the
> > > document.
> > 
> > Right, but unless I am missing something there isn't such a thing at the
> > moment, at least in Linux.
> > 
> > I'll try to come up with a linux devid to vdev function true to the
> > original.
> 
> That would be good.  If you felt like documenting the Linux behaviour
> properly that would be good.  The section "Notes on Linux as a guest"
> in docs/misc/vbd-interface.text.

the best place for this would be in the Linux Documentation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Z5-0004In-BH; Tue, 03 Apr 2012 14:18:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4Z4-0004Ic-Te
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:18:31 +0000
Received: from [85.158.138.51:39816] by server-2.bemta-3.messagelabs.com id
	7F/49-15460-6B60B7F4; Tue, 03 Apr 2012 14:18:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333462704!20610154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14526 invoked from network); 3 Apr 2012 14:18:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:18:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:18:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:18:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4Yx-0005GH-9q; Tue, 03 Apr 2012 14:18:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4Yx-0007Js-7i;
	Tue, 03 Apr 2012 15:18:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1711.221580.83773@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:18:23 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6685b67958b0623064c7.1332321259@probook.site>
References: <6685b67958b0623064c7.1332321259@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> tools/vtpm: use LDLIBS to pass -lgmp

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4Z5-0004In-BH; Tue, 03 Apr 2012 14:18:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4Z4-0004Ic-Te
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:18:31 +0000
Received: from [85.158.138.51:39816] by server-2.bemta-3.messagelabs.com id
	7F/49-15460-6B60B7F4; Tue, 03 Apr 2012 14:18:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333462704!20610154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14526 invoked from network); 3 Apr 2012 14:18:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:18:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:18:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:18:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4Yx-0005GH-9q; Tue, 03 Apr 2012 14:18:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4Yx-0007Js-7i;
	Tue, 03 Apr 2012 15:18:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1711.221580.83773@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:18:23 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6685b67958b0623064c7.1332321259@probook.site>
References: <6685b67958b0623064c7.1332321259@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"):
> tools/vtpm: use LDLIBS to pass -lgmp

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:23:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4dG-0004Xu-1q; Tue, 03 Apr 2012 14:22:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF4dF-0004Xo-9r
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:22:49 +0000
Received: from [85.158.139.83:14128] by server-9.bemta-5.messagelabs.com id
	CE/CE-09826-8B70B7F4; Tue, 03 Apr 2012 14:22:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333462966!22299292!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6710 invoked from network); 3 Apr 2012 14:22:47 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Apr 2012 14:22:47 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF4dA-0003ks-OX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 07:22:44 -0700
Date: Tue, 3 Apr 2012 07:22:44 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333462964743-5615286.post@n5.nabble.com>
In-Reply-To: <20347.1295.429766.715415@mariner.uk.xensource.com>
References: <4F68A391.90500@tiscali.it>
	<20347.1295.429766.715415@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
 to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

already done in past but change for your reply:
http://xen.1045712.n5.nabble.com/PATCH-v3-Added-optional-build-configs-for-qemu-upstream-td5544305.html

--
View this message in context: http://xen.1045712.n5.nabble.com/Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5580361p5615286.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:23:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4dG-0004Xu-1q; Tue, 03 Apr 2012 14:22:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF4dF-0004Xo-9r
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:22:49 +0000
Received: from [85.158.139.83:14128] by server-9.bemta-5.messagelabs.com id
	CE/CE-09826-8B70B7F4; Tue, 03 Apr 2012 14:22:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333462966!22299292!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6710 invoked from network); 3 Apr 2012 14:22:47 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Apr 2012 14:22:47 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SF4dA-0003ks-OX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 07:22:44 -0700
Date: Tue, 3 Apr 2012 07:22:44 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333462964743-5615286.post@n5.nabble.com>
In-Reply-To: <20347.1295.429766.715415@mariner.uk.xensource.com>
References: <4F68A391.90500@tiscali.it>
	<20347.1295.429766.715415@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
 to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

already done in past but change for your reply:
http://xen.1045712.n5.nabble.com/PATCH-v3-Added-optional-build-configs-for-qemu-upstream-td5544305.html

--
View this message in context: http://xen.1045712.n5.nabble.com/Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5580361p5615286.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4dg-0004Zq-F3; Tue, 03 Apr 2012 14:23:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4de-0004Zh-Tx
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:23:15 +0000
Received: from [85.158.138.51:3265] by server-5.bemta-3.messagelabs.com id
	F7/8D-24278-2D70B7F4; Tue, 03 Apr 2012 14:23:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333462992!20641689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6253 invoked from network); 3 Apr 2012 14:23:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:23:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:23:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:23:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4dc-0005Hu-6F; Tue, 03 Apr 2012 14:23:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4dc-0007KT-59;
	Tue, 03 Apr 2012 15:23:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1997.860895.62256@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:23:09 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031515040.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
	<4F7B0122.9090602@citrix.com>
	<20347.742.768963.36907@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031515040.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> On Tue, 3 Apr 2012, Ian Jackson wrote:
> > Currently the bdfs are allocated by the single qemu-dm, right ?  Why
> > cannot that functionality stay there, with the pci bridge emulation ?
>  
> Because the allocation of most BDFs in QEMU is done ad-hoc in a first
> come first served basis. If the first QEMU is not going to emulate these
> devices then it is not going to allocate the BDF for them either.

Do we want the bdf allocation to be stable when switching between the
combined and disaggregated qemu-dms ?  If we do then it still needs to
be done by that qemu-dm using the same algorithm, presumably with
additional ipc.

If we don't then it would be ok for the bdfs to be allocated by new
code in the toolstack somewhere, eg libxl, but it still shouldn't be
up to the user to configure.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4dg-0004Zq-F3; Tue, 03 Apr 2012 14:23:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4de-0004Zh-Tx
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:23:15 +0000
Received: from [85.158.138.51:3265] by server-5.bemta-3.messagelabs.com id
	F7/8D-24278-2D70B7F4; Tue, 03 Apr 2012 14:23:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333462992!20641689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6253 invoked from network); 3 Apr 2012 14:23:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:23:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:23:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:23:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4dc-0005Hu-6F; Tue, 03 Apr 2012 14:23:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4dc-0007KT-59;
	Tue, 03 Apr 2012 15:23:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.1997.860895.62256@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:23:09 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031515040.15151@kaball-desktop>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<eb931c94b4cd00da7e1e74896b2f9531b56ea357.1332430811.git.julien.grall@citrix.com>
	<20345.56773.8058.87028@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031101130.15151@kaball-desktop>
	<20346.64407.174158.890551@mariner.uk.xensource.com>
	<4F7B0122.9090602@citrix.com>
	<20347.742.768963.36907@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031515040.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Julien Grall \(Intern\)" <julien.grall@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new
 option device_models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"):
> On Tue, 3 Apr 2012, Ian Jackson wrote:
> > Currently the bdfs are allocated by the single qemu-dm, right ?  Why
> > cannot that functionality stay there, with the pci bridge emulation ?
>  
> Because the allocation of most BDFs in QEMU is done ad-hoc in a first
> come first served basis. If the first QEMU is not going to emulate these
> devices then it is not going to allocate the BDF for them either.

Do we want the bdf allocation to be stable when switching between the
combined and disaggregated qemu-dms ?  If we do then it still needs to
be done by that qemu-dm using the same algorithm, presumably with
additional ipc.

If we don't then it would be ok for the bdfs to be allocated by new
code in the toolstack somewhere, eg libxl, but it still shouldn't be
up to the user to configure.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4f1-0004iw-3r; Tue, 03 Apr 2012 14:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4f0-0004im-CO
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:24:38 +0000
Received: from [85.158.143.35:50687] by server-1.bemta-4.messagelabs.com id
	88/73-20925-5280B7F4; Tue, 03 Apr 2012 14:24:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333463072!10843960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14590 invoked from network); 3 Apr 2012 14:24:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:24:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:24:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:24:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4et-0005IN-Hh; Tue, 03 Apr 2012 14:24:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4et-0007KX-Ev;
	Tue, 03 Apr 2012 15:24:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2076.974553.319109@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:24:28 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
...
> I don't think it is worth adding one more option for something like
> this: nobody should be using this option anyway. I am still unconvinced
> there is a valid use case for this.

I think it's important.  An additional config option is IMO necessary
to allow the admin to impose their vbd allocation strategy.

> > That would be good.  If you felt like documenting the Linux behaviour
> > properly that would be good.  The section "Notes on Linux as a guest"
> > in docs/misc/vbd-interface.text.
> 
> the best place for this would be in the Linux Documentation

OK...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4f1-0004iw-3r; Tue, 03 Apr 2012 14:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4f0-0004im-CO
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:24:38 +0000
Received: from [85.158.143.35:50687] by server-1.bemta-4.messagelabs.com id
	88/73-20925-5280B7F4; Tue, 03 Apr 2012 14:24:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333463072!10843960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14590 invoked from network); 3 Apr 2012 14:24:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:24:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:24:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:24:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4et-0005IN-Hh; Tue, 03 Apr 2012 14:24:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4et-0007KX-Ev;
	Tue, 03 Apr 2012 15:24:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2076.974553.319109@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:24:28 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
...
> I don't think it is worth adding one more option for something like
> this: nobody should be using this option anyway. I am still unconvinced
> there is a valid use case for this.

I think it's important.  An additional config option is IMO necessary
to allow the admin to impose their vbd allocation strategy.

> > That would be good.  If you felt like documenting the Linux behaviour
> > properly that would be good.  The section "Notes on Linux as a guest"
> > in docs/misc/vbd-interface.text.
> 
> the best place for this would be in the Linux Documentation

OK...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:24:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4fB-0004kI-Gd; Tue, 03 Apr 2012 14:24:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve.johnston@adventiumlabs.com>)
	id 1SF4fA-0004jx-DR
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:24:48 +0000
Received: from [85.158.139.83:18461] by server-5.bemta-5.messagelabs.com id
	58/99-13566-F280B7F4; Tue, 03 Apr 2012 14:24:47 +0000
X-Env-Sender: steve.johnston@adventiumlabs.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333463086!18028726!1
X-Originating-IP: [208.42.184.242]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4LjQyLjE4NC4yNDIgPT4gNTE2Mzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2609 invoked from network); 3 Apr 2012 14:24:46 -0000
Received: from mailfront4.g2host.com (HELO g2host.com) (208.42.184.242)
	by server-14.tower-182.messagelabs.com with SMTP;
	3 Apr 2012 14:24:46 -0000
Received: from [173.8.98.161] (account steve.johnston@adventiumlabs.com HELO
	[192.168.222.173])
	by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11)
	with ESMTPSA id 54716107 for xen-devel@lists.xensource.com;
	Tue, 03 Apr 2012 09:24:46 -0500
Message-ID: <4F7B0844.9000808@adventiumlabs.com>
Date: Tue, 03 Apr 2012 09:25:08 -0500
From: Steve Johnston <steve.johnston@adventiumlabs.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.1.1
Subject: [Xen-devel] Submitting a patch for 4.0.1?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I have been using Xen 4.0.1 and have created/added a new scheduler that
I would like to release into the mainline.

Am I able to submit a patch for an older version of Xen or do I need to
port my changes to the current devel project?

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:24:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4fB-0004kI-Gd; Tue, 03 Apr 2012 14:24:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve.johnston@adventiumlabs.com>)
	id 1SF4fA-0004jx-DR
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:24:48 +0000
Received: from [85.158.139.83:18461] by server-5.bemta-5.messagelabs.com id
	58/99-13566-F280B7F4; Tue, 03 Apr 2012 14:24:47 +0000
X-Env-Sender: steve.johnston@adventiumlabs.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333463086!18028726!1
X-Originating-IP: [208.42.184.242]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4LjQyLjE4NC4yNDIgPT4gNTE2Mzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2609 invoked from network); 3 Apr 2012 14:24:46 -0000
Received: from mailfront4.g2host.com (HELO g2host.com) (208.42.184.242)
	by server-14.tower-182.messagelabs.com with SMTP;
	3 Apr 2012 14:24:46 -0000
Received: from [173.8.98.161] (account steve.johnston@adventiumlabs.com HELO
	[192.168.222.173])
	by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11)
	with ESMTPSA id 54716107 for xen-devel@lists.xensource.com;
	Tue, 03 Apr 2012 09:24:46 -0500
Message-ID: <4F7B0844.9000808@adventiumlabs.com>
Date: Tue, 03 Apr 2012 09:25:08 -0500
From: Steve Johnston <steve.johnston@adventiumlabs.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.1.1
Subject: [Xen-devel] Submitting a patch for 4.0.1?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I have been using Xen 4.0.1 and have created/added a new scheduler that
I would like to release into the mainline.

Am I able to submit a patch for an older version of Xen or do I need to
port my changes to the current devel project?

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:30:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4ka-00059m-9X; Tue, 03 Apr 2012 14:30:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4kY-00059h-SE
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:30:22 +0000
Received: from [85.158.139.83:23291] by server-5.bemta-5.messagelabs.com id
	9A/97-13566-E790B7F4; Tue, 03 Apr 2012 14:30:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333463419!22303311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21350 invoked from network); 3 Apr 2012 14:30:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:30:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:30:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4kU-0005KY-Rj; Tue, 03 Apr 2012 14:30:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4kU-0004Si-OW;
	Tue, 03 Apr 2012 15:30:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2426.458487.82559@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:30:18 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203191518430.923@kaball-desktop>
References: <94066d2f6045e80dc5d2.1332164511@probook.site>
	<alpine.DEB.2.00.1203191518430.923@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: specify datadir for qemu-xen build
 to fix firmware loading
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] tools: specify datadir for qemu-xen build to fix firmware loading"):
> On Mon, 19 Mar 2012, Olaf Hering wrote:
> > tools: specify datadir for qemu-xen build to fix firmware loading
...
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:30:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4ka-00059m-9X; Tue, 03 Apr 2012 14:30:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4kY-00059h-SE
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:30:22 +0000
Received: from [85.158.139.83:23291] by server-5.bemta-5.messagelabs.com id
	9A/97-13566-E790B7F4; Tue, 03 Apr 2012 14:30:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333463419!22303311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21350 invoked from network); 3 Apr 2012 14:30:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:30:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:30:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4kU-0005KY-Rj; Tue, 03 Apr 2012 14:30:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4kU-0004Si-OW;
	Tue, 03 Apr 2012 15:30:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2426.458487.82559@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:30:18 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203191518430.923@kaball-desktop>
References: <94066d2f6045e80dc5d2.1332164511@probook.site>
	<alpine.DEB.2.00.1203191518430.923@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: specify datadir for qemu-xen build
 to fix firmware loading
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] tools: specify datadir for qemu-xen build to fix firmware loading"):
> On Mon, 19 Mar 2012, Olaf Hering wrote:
> > tools: specify datadir for qemu-xen build to fix firmware loading
...
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:31:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4lq-0005Di-RB; Tue, 03 Apr 2012 14:31:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4lo-0005DX-TL
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 14:31:41 +0000
Received: from [85.158.143.35:19402] by server-2.bemta-4.messagelabs.com id
	BF/81-17550-CC90B7F4; Tue, 03 Apr 2012 14:31:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333463498!7466883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27348 invoked from network); 3 Apr 2012 14:31:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:31:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:31:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:31:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4ll-0005L1-MH; Tue, 03 Apr 2012 14:31:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4ll-0004UU-KS;
	Tue, 03 Apr 2012 15:31:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2505.472977.167973@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:31:37 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e10c4b937e8fa9159070.1332167068@cosworth.uk.xensource.com>
References: <e10c4b937e8fa9159070.1332167068@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: log device model arguments to
	aid	debugging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: log device model arguments to aid debugging"):
> libxl: log device model arguments to aid debugging

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:31:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4lq-0005Di-RB; Tue, 03 Apr 2012 14:31:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4lo-0005DX-TL
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 14:31:41 +0000
Received: from [85.158.143.35:19402] by server-2.bemta-4.messagelabs.com id
	BF/81-17550-CC90B7F4; Tue, 03 Apr 2012 14:31:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333463498!7466883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27348 invoked from network); 3 Apr 2012 14:31:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:31:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:31:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:31:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4ll-0005L1-MH; Tue, 03 Apr 2012 14:31:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4ll-0004UU-KS;
	Tue, 03 Apr 2012 15:31:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2505.472977.167973@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:31:37 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e10c4b937e8fa9159070.1332167068@cosworth.uk.xensource.com>
References: <e10c4b937e8fa9159070.1332167068@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: log device model arguments to
	aid	debugging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: log device model arguments to aid debugging"):
> libxl: log device model arguments to aid debugging

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:32:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4mh-0005I9-DD; Tue, 03 Apr 2012 14:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4mg-0005Hp-Mc
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 14:32:34 +0000
Received: from [85.158.143.35:20377] by server-2.bemta-4.messagelabs.com id
	D9/43-17550-10A0B7F4; Tue, 03 Apr 2012 14:32:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333463549!17004866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19884 invoked from network); 3 Apr 2012 14:32:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:32:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:32:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:32:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4ma-0005LN-AS; Tue, 03 Apr 2012 14:32:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4ma-0004d2-7f;
	Tue, 03 Apr 2012 15:32:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2553.796551.427623@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:32:25 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1S9eNO-132113@chiark.greenend.org.uk>
References: <1331732247.23971.438.camel@zakaz.uk.xensource.com>
	<m2n.s.1S9eNO-132113@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-api@lists.xen.org, Bamvor Jian Zhang <bjzhang@suse.com>,
	Jim Fehlig <jfehlig@suse.com>, Zhigang Wang <zhigang.x.wang@oracle.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document API and ABI
	compatibility	guarantees
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: Document API and ABI compatibility guarantees"):
> libxl: Document API and ABI compatibility guarantees.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:32:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4mh-0005I9-DD; Tue, 03 Apr 2012 14:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4mg-0005Hp-Mc
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 14:32:34 +0000
Received: from [85.158.143.35:20377] by server-2.bemta-4.messagelabs.com id
	D9/43-17550-10A0B7F4; Tue, 03 Apr 2012 14:32:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333463549!17004866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19884 invoked from network); 3 Apr 2012 14:32:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:32:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:32:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:32:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4ma-0005LN-AS; Tue, 03 Apr 2012 14:32:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4ma-0004d2-7f;
	Tue, 03 Apr 2012 15:32:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2553.796551.427623@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:32:25 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1S9eNO-132113@chiark.greenend.org.uk>
References: <1331732247.23971.438.camel@zakaz.uk.xensource.com>
	<m2n.s.1S9eNO-132113@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-api@lists.xen.org, Bamvor Jian Zhang <bjzhang@suse.com>,
	Jim Fehlig <jfehlig@suse.com>, Zhigang Wang <zhigang.x.wang@oracle.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Document API and ABI
	compatibility	guarantees
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: Document API and ABI compatibility guarantees"):
> libxl: Document API and ABI compatibility guarantees.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:35:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4pS-0005aL-2p; Tue, 03 Apr 2012 14:35:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4pQ-0005a7-9f
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:35:24 +0000
Received: from [85.158.138.51:14017] by server-6.bemta-3.messagelabs.com id
	70/E2-08206-BAA0B7F4; Tue, 03 Apr 2012 14:35:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333463722!20653153!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15347 invoked from network); 3 Apr 2012 14:35:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:35:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:34:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:34:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4oz-0005Nz-CG; Tue, 03 Apr 2012 14:34:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4oz-0004da-BN;
	Tue, 03 Apr 2012 15:34:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2705.332737.178396@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:34:57 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0625fe50a2ee3943854d.1333461293@kodo2>
References: <patchbomb.1333461291@kodo2>
	<0625fe50a2ee3943854d.1333461293@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> By default pciback only allows PV guests to write "known safe" values into
> PCI config space.  But many devices require writes to other areas of config
> space in order to operate properly.  One way to do that is with the "quirks"
> interface, which specifies areas known safe to a particular device; the
> other way is to mark a device as "permissive", which tells pciback to allow
> all config space writes for that domain and device.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:35:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4pS-0005aL-2p; Tue, 03 Apr 2012 14:35:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4pQ-0005a7-9f
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:35:24 +0000
Received: from [85.158.138.51:14017] by server-6.bemta-3.messagelabs.com id
	70/E2-08206-BAA0B7F4; Tue, 03 Apr 2012 14:35:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333463722!20653153!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15347 invoked from network); 3 Apr 2012 14:35:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:35:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:34:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:34:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4oz-0005Nz-CG; Tue, 03 Apr 2012 14:34:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4oz-0004da-BN;
	Tue, 03 Apr 2012 15:34:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2705.332737.178396@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:34:57 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0625fe50a2ee3943854d.1333461293@kodo2>
References: <patchbomb.1333461291@kodo2>
	<0625fe50a2ee3943854d.1333461293@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl,
 libxl: Add per-device and global permissive config options for pci
 passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl, libxl: Add per-device and global permissive config options for pci passthrough"):
> By default pciback only allows PV guests to write "known safe" values into
> PCI config space.  But many devices require writes to other areas of config
> space in order to operate properly.  One way to do that is with the "quirks"
> interface, which specifies areas known safe to a particular device; the
> other way is to mark a device as "permissive", which tells pciback to allow
> all config space writes for that domain and device.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:35:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4pU-0005af-FE; Tue, 03 Apr 2012 14:35:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4pS-0005aR-RA
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:35:26 +0000
Received: from [85.158.143.35:47996] by server-1.bemta-4.messagelabs.com id
	66/99-20925-EAA0B7F4; Tue, 03 Apr 2012 14:35:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333463716!10846270!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7304 invoked from network); 3 Apr 2012 14:35:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:34:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4oe-0005Nj-0B; Tue, 03 Apr 2012 14:34:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4od-0004dR-VT;
	Tue, 03 Apr 2012 15:34:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2683.908922.703384@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:34:35 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <74bb52e4f6a6e2b0c918.1333461292@kodo2>
References: <patchbomb.1333461291@kodo2>
	<74bb52e4f6a6e2b0c918.1333461292@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu"):
> Config parsing functions do not properly belong in libxl.  Move them into
> libxlu so that others can use them or not as they see fit.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:35:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4pU-0005af-FE; Tue, 03 Apr 2012 14:35:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4pS-0005aR-RA
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:35:26 +0000
Received: from [85.158.143.35:47996] by server-1.bemta-4.messagelabs.com id
	66/99-20925-EAA0B7F4; Tue, 03 Apr 2012 14:35:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333463716!10846270!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7304 invoked from network); 3 Apr 2012 14:35:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:34:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4oe-0005Nj-0B; Tue, 03 Apr 2012 14:34:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4od-0004dR-VT;
	Tue, 03 Apr 2012 15:34:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2683.908922.703384@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:34:35 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <74bb52e4f6a6e2b0c918.1333461292@kodo2>
References: <patchbomb.1333461291@kodo2>
	<74bb52e4f6a6e2b0c918.1333461292@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 1 of 2] libxl: Move bdf parsing into libxlu"):
> Config parsing functions do not properly belong in libxl.  Move them into
> libxlu so that others can use them or not as they see fit.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:37:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4rb-0005pd-1J; Tue, 03 Apr 2012 14:37:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4rZ-0005pT-OC
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:37:37 +0000
Received: from [85.158.143.35:64998] by server-2.bemta-4.messagelabs.com id
	D5/0E-17550-13B0B7F4; Tue, 03 Apr 2012 14:37:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333463856!7468564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30117 invoked from network); 3 Apr 2012 14:37:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:37:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:37:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:37:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4rX-0005Ol-QM; Tue, 03 Apr 2012 14:37:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4rX-0004dw-PL;
	Tue, 03 Apr 2012 15:37:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2863.767056.572291@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:37:35 +0100
To: Fantu <fantonifabio@tiscali.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1333462964743-5615286.post@n5.nabble.com>
References: <4F68A391.90500@tiscali.it>
	<20347.1295.429766.715415@mariner.uk.xensource.com>
	<1333462964743-5615286.post@n5.nabble.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
 to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fantu writes ("Re: [Xen-devel] Autoconf: add variable for pass arbitrary options to	qemu upstream"):
> already done in past but change for your reply:
> http://xen.1045712.n5.nabble.com/PATCH-v3-Added-optional-build-configs-for-qemu-upstream-td5544305.html

Your quoting of context is really deficient and makes it hard to see
what you're talking about.

AFAICT this is a response to me saying:
] Wouldn't this be better done with AC_ARG_ENABLE rather than some magic
] environment variable ?

The earlier version you refer to introduced one corresponding
AC_ARG_ENABLE for each upstream qemu configure script option.

I think the right thing to do is to have one single AC_ARG_ENABLE
option that contains all the intended extra options for the qemu
configure script.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:37:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4rb-0005pd-1J; Tue, 03 Apr 2012 14:37:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4rZ-0005pT-OC
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:37:37 +0000
Received: from [85.158.143.35:64998] by server-2.bemta-4.messagelabs.com id
	D5/0E-17550-13B0B7F4; Tue, 03 Apr 2012 14:37:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333463856!7468564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30117 invoked from network); 3 Apr 2012 14:37:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:37:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:37:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:37:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4rX-0005Ol-QM; Tue, 03 Apr 2012 14:37:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4rX-0004dw-PL;
	Tue, 03 Apr 2012 15:37:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.2863.767056.572291@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:37:35 +0100
To: Fantu <fantonifabio@tiscali.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1333462964743-5615286.post@n5.nabble.com>
References: <4F68A391.90500@tiscali.it>
	<20347.1295.429766.715415@mariner.uk.xensource.com>
	<1333462964743-5615286.post@n5.nabble.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
 to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fantu writes ("Re: [Xen-devel] Autoconf: add variable for pass arbitrary options to	qemu upstream"):
> already done in past but change for your reply:
> http://xen.1045712.n5.nabble.com/PATCH-v3-Added-optional-build-configs-for-qemu-upstream-td5544305.html

Your quoting of context is really deficient and makes it hard to see
what you're talking about.

AFAICT this is a response to me saying:
] Wouldn't this be better done with AC_ARG_ENABLE rather than some magic
] environment variable ?

The earlier version you refer to introduced one corresponding
AC_ARG_ENABLE for each upstream qemu configure script option.

I think the right thing to do is to have one single AC_ARG_ENABLE
option that contains all the intended extra options for the qemu
configure script.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:42:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4w6-00068Q-O3; Tue, 03 Apr 2012 14:42:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF4w5-00068L-53
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 14:42:17 +0000
Received: from [85.158.139.83:62591] by server-1.bemta-5.messagelabs.com id
	71/D2-28458-84C0B7F4; Tue, 03 Apr 2012 14:42:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333464135!21632241!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12073 invoked from network); 3 Apr 2012 14:42:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 14:42:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333464134; l=957;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=KZePWIwrubPqKsqeIQHcODlpEa4=;
	b=JGwwZ5byg8OJvHUqIaDtp0z0Sjs3/zO53F06eXvJZcI1oVCcWnswbkaE92Q3K66UZvq
	EEa8tatb8QCdOAzUw6JV1qmWSDwSKGfBJArIrWibYFAPEmhZC92Y7MvjbV5z65juBl7Uw
	tn33YBtYywJHnOna6e84FdtLitA+grM3l1s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (fruni mo59) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g00617o33DJ7Wm ;
	Tue, 3 Apr 2012 16:42:09 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 4FB5618637; Tue,  3 Apr 2012 16:42:08 +0200 (CEST)
Date: Tue, 3 Apr 2012 16:42:08 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120403144208.GA7284@aepfle.de>
References: <patchbomb.1332863006@xdev.gridcentric.ca>
	<20120329110357.GE72859@ocelot.phlegethon.org>
	<7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: keir@xen.org, andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, wei.wang2@amd.com, jbeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Support for Paging/Sharing on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Mar 29, Andres Lagar-Cavilla wrote:

> The question now is what to do for AMD+paging in Xen 4.2. It works
> partially, there are still VMEXIT_shutdown hvm crashes happening with pv
> drivers.

I tested it with openSuSE 11.4 and the kernel-xen shipped with it and a
sles11sp2 guest. paging works in that combination, I did a fresh
installation in the guest and went half way through it. The cfg is
below, in case it matters.

Its possible that a pvops kernel in host or guest triggers some issues.

Thanks anyway for doing that work, Andres!

Olaf


# /etc/xen/vm/hvm1
builder='hvm'
memory = 512
name = "ExampleHVMDomain1"
disk = [ 'file:/dev/shm/loopfile,hda,w', 'file:/dist/iso/sles11/cdn.novell.com/prot/sles11sp2-x86_64/SLES-11-SP2-DVD-x86_64-GM-DVD1.iso,hdc:cdrom,r' ]
sdl=0
opengl=1
vnc=1
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0
mem_target_paging=123
xenpaging_extra=[ '-f' , '/dev/shm/pagingfile', '-v' ]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:42:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4w6-00068Q-O3; Tue, 03 Apr 2012 14:42:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF4w5-00068L-53
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 14:42:17 +0000
Received: from [85.158.139.83:62591] by server-1.bemta-5.messagelabs.com id
	71/D2-28458-84C0B7F4; Tue, 03 Apr 2012 14:42:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333464135!21632241!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12073 invoked from network); 3 Apr 2012 14:42:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 14:42:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333464134; l=957;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=KZePWIwrubPqKsqeIQHcODlpEa4=;
	b=JGwwZ5byg8OJvHUqIaDtp0z0Sjs3/zO53F06eXvJZcI1oVCcWnswbkaE92Q3K66UZvq
	EEa8tatb8QCdOAzUw6JV1qmWSDwSKGfBJArIrWibYFAPEmhZC92Y7MvjbV5z65juBl7Uw
	tn33YBtYywJHnOna6e84FdtLitA+grM3l1s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (fruni mo59) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g00617o33DJ7Wm ;
	Tue, 3 Apr 2012 16:42:09 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 4FB5618637; Tue,  3 Apr 2012 16:42:08 +0200 (CEST)
Date: Tue, 3 Apr 2012 16:42:08 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120403144208.GA7284@aepfle.de>
References: <patchbomb.1332863006@xdev.gridcentric.ca>
	<20120329110357.GE72859@ocelot.phlegethon.org>
	<7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: keir@xen.org, andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, wei.wang2@amd.com, jbeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Support for Paging/Sharing on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Mar 29, Andres Lagar-Cavilla wrote:

> The question now is what to do for AMD+paging in Xen 4.2. It works
> partially, there are still VMEXIT_shutdown hvm crashes happening with pv
> drivers.

I tested it with openSuSE 11.4 and the kernel-xen shipped with it and a
sles11sp2 guest. paging works in that combination, I did a fresh
installation in the guest and went half way through it. The cfg is
below, in case it matters.

Its possible that a pvops kernel in host or guest triggers some issues.

Thanks anyway for doing that work, Andres!

Olaf


# /etc/xen/vm/hvm1
builder='hvm'
memory = 512
name = "ExampleHVMDomain1"
disk = [ 'file:/dev/shm/loopfile,hda,w', 'file:/dist/iso/sles11/cdn.novell.com/prot/sles11sp2-x86_64/SLES-11-SP2-DVD-x86_64-GM-DVD1.iso,hdc:cdrom,r' ]
sdl=0
opengl=1
vnc=1
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0
mem_target_paging=123
xenpaging_extra=[ '-f' , '/dev/shm/pagingfile', '-v' ]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:44:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4xf-0006HK-G3; Tue, 03 Apr 2012 14:43:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4xd-0006HC-Ee
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:43:53 +0000
Received: from [85.158.143.35:33232] by server-1.bemta-4.messagelabs.com id
	78/EA-20925-8AC0B7F4; Tue, 03 Apr 2012 14:43:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333464232!10845846!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32737 invoked from network); 3 Apr 2012 14:43:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:43:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:43:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4xb-0005Qs-64; Tue, 03 Apr 2012 14:43:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4xa-00057c-Fa;
	Tue, 03 Apr 2012 15:43:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3237.903755.221120@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:43:49 +0100
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1321625125-30726-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
	<1321625125-30726-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen: introduce an event channel for
 buffered io event notifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

stefano.stabellini@eu.citrix.com writes ("[PATCH 1/3] xen: introduce an event channel for buffered io event notifications"):
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
> notifications for buffered io events.
> After the first notification is received leave the event channel masked
> and setup a timer to process the rest of the batch.
> Once we have completed processing the batch, unmask the event channel
> and delete the timer.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:44:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4xf-0006HK-G3; Tue, 03 Apr 2012 14:43:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4xd-0006HC-Ee
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:43:53 +0000
Received: from [85.158.143.35:33232] by server-1.bemta-4.messagelabs.com id
	78/EA-20925-8AC0B7F4; Tue, 03 Apr 2012 14:43:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333464232!10845846!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32737 invoked from network); 3 Apr 2012 14:43:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:43:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:43:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4xb-0005Qs-64; Tue, 03 Apr 2012 14:43:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4xa-00057c-Fa;
	Tue, 03 Apr 2012 15:43:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3237.903755.221120@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:43:49 +0100
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1321625125-30726-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
	<1321625125-30726-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen: introduce an event channel for
 buffered io event notifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

stefano.stabellini@eu.citrix.com writes ("[PATCH 1/3] xen: introduce an event channel for buffered io event notifications"):
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
> notifications for buffered io events.
> After the first notification is received leave the event channel masked
> and setup a timer to process the rest of the batch.
> Once we have completed processing the batch, unmask the event channel
> and delete the timer.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:45:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4zO-0006RZ-2L; Tue, 03 Apr 2012 14:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4zM-0006RP-Cx
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:45:40 +0000
Received: from [85.158.138.51:17691] by server-7.bemta-3.messagelabs.com id
	C5/8B-07528-31D0B7F4; Tue, 03 Apr 2012 14:45:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1333464338!20635605!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6941 invoked from network); 3 Apr 2012 14:45:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:45:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:45:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4zK-0005Rb-0Z; Tue, 03 Apr 2012 14:45:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4zJ-0005Ac-Vp;
	Tue, 03 Apr 2012 15:45:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3345.782946.540229@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:45:37 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203161128590.923@kaball-desktop>
References: <A9667DDFB95DB7438FA9D7D576C3D87E099DF0@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.00.1203161128590.923@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"'Jan Beulich \(JBeulich@suse.com\)'" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v3] use INT64_MAX as max expiration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3] use INT64_MAX as max expiration"):
> On Fri, 16 Mar 2012, Zhang, Yang Z wrote:
> > Currently, the max expiration time is 2147483647ns(INT32_MAX ns). This is enough when guest is busy, but when guest is idle, the next timer will be later than INT32_MAX ns. And those meaningless alarm will harm the pkg C-state.
...
> > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:45:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF4zO-0006RZ-2L; Tue, 03 Apr 2012 14:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF4zM-0006RP-Cx
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:45:40 +0000
Received: from [85.158.138.51:17691] by server-7.bemta-3.messagelabs.com id
	C5/8B-07528-31D0B7F4; Tue, 03 Apr 2012 14:45:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1333464338!20635605!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6941 invoked from network); 3 Apr 2012 14:45:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330905600"; d="scan'208";a="11748829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:45:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:45:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF4zK-0005Rb-0Z; Tue, 03 Apr 2012 14:45:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF4zJ-0005Ac-Vp;
	Tue, 03 Apr 2012 15:45:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3345.782946.540229@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:45:37 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1203161128590.923@kaball-desktop>
References: <A9667DDFB95DB7438FA9D7D576C3D87E099DF0@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.00.1203161128590.923@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"'Jan Beulich \(JBeulich@suse.com\)'" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v3] use INT64_MAX as max expiration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3] use INT64_MAX as max expiration"):
> On Fri, 16 Mar 2012, Zhang, Yang Z wrote:
> > Currently, the max expiration time is 2147483647ns(INT32_MAX ns). This is enough when guest is busy, but when guest is idle, the next timer will be later than INT32_MAX ns. And those meaningless alarm will harm the pkg C-state.
...
> > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF539-0006h7-Nh; Tue, 03 Apr 2012 14:49:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SF538-0006gy-6n
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:49:34 +0000
Received: from [85.158.139.83:59261] by server-1.bemta-5.messagelabs.com id
	B0/44-28458-AFD0B7F4; Tue, 03 Apr 2012 14:49:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333464569!11040258!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22857 invoked from network); 3 Apr 2012 14:49:29 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:49:29 -0000
Received: by bkwj5 with SMTP id j5so3838976bkw.30
	for <multiple recipients>; Tue, 03 Apr 2012 07:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=bcpwPwMvkpn51WVj5bhJ9uJye2S21slxYd85G4nKghM=;
	b=alwGQ9B5WNmLmiJUZRKZ4Tu7IWfMmV5vJO615nCO2cPW8BnZ+EXA+4NjlpK1z0KA3/
	+K70zEs/BXnTAaVkfgXUGPNap+K32zxWTRwVnY8yNVBs/5dL1eoiYBlw9qcHN1vsdMw5
	FaoxfiB+NZZNPSTpp2mX3yj/tLq8uVhnbMzGsukBYO4zW2l6zALgj8jUDCr+7HF9udqO
	pDyjvYNZslhzDtipAFBwsdUEyodE/9g0AnvuijVi6uE//CA+7y8Qk7hzYHCgCYDp5a5R
	TsYMveGxzvUmwrB7yzNKsoBg2XrmZMZi2YqJEjqcUem8gLdd+Xajv8Iz8SkQN7QbfED4
	64gw==
Received: by 10.205.132.73 with SMTP id ht9mr5856828bkc.46.1333464569186;
	Tue, 03 Apr 2012 07:49:29 -0700 (PDT)
Received: from [172.16.25.10] (b0fb52a6.bb.sky.com. [176.251.82.166])
	by mx.google.com with ESMTPS id z17sm46460414bkw.12.2012.04.03.07.49.26
	(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 07:49:27 -0700 (PDT)
Message-ID: <4F7B0DF5.1010602@xen.org>
Date: Tue, 03 Apr 2012 15:49:25 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
	<1333450007.25602.130.camel@zakaz.uk.xensource.com>
	<20120403133038.GA84917@dhcp-3-120.uk.xensource.com>
In-Reply-To: <20120403133038.GA84917@dhcp-3-120.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the effort: do ping me when you guys are ready
Also when LiveCD's and the library is in place, that would be a great 
guest blog post on xen.org
Regards
Lars

On 03/04/2012 14:30, Roger Pau Monne wrote:
> On Tue, Apr 03, 2012 at 11:46:47AM +0100, Ian Campbell wrote:
>> On Mon, 2012-04-02 at 18:59 +0100, Joseph Glanville wrote:
>>> On 3 April 2012 02:11, Ian Campbell<Ian.Campbell@citrix.com>  wrote:
>>>> On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
>>>>> Hi guys,
>>>>>
>>>>> I have started preparing a library of PV-HVM templates for use on Xen
>>>>> 4.X+ and PVOPS dom0.
>>>> [...]
>>>>> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
>>>>> (the final beta, will be updated to final shortly).
>>>>> Included is an OS image, a config file, a README and the associated
>>>>> licences etc.
>>>> This is very cool, and you are correct that these will be very useful
>>>> for people trying to get something going quickly! Thanks Joseph.
>>> No problem, I am working on a new dom0 livecd too.
>>>
>>> I need some recommendations on what distro to base it on though...
>>> Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
>>> to be more enduring and a more beginner approachable alternative.
>>>
>>> Does anyone have any thoughts on this?
> I've been working with the Alpine Linux guys (http://alpinelinux.org/)
> for some time, and we managed to get a working Xen LiveCD, next major
> release (2.4 I think) it's gonna come with Xen Dom0 LiveCDs, since all
> the necessary bits have been added to the upstream distro build
> scripts. You can take a look at the build scripts here:
>
> http://git.alpinelinux.org/cgit/alpine-iso/
>
> It's really easy to generate a LiveCD iso, you just need a working
> Alpine Linux install (which can be a VM) and the alpine-iso scripts.
>
>> My personal preference would be Debian ;-) But pragmatically Ubuntu is,
>> I think, generally thought to be a good beginner distro and conveniently
>> it now contains support for Xen so that seems like a good choice.
>>
>> Also on the plus side is that Ubuntu may well contain the "Debian Live"
>> packages/infrastructure which make building Live CDs easier (I presume,
>> I've never tried them). I don't know if that's actually what is used by
>> Ubuntu to make their live CDs, if not then I'd hope that infrastructure
>> was in Ubuntu too.
>>
>> Ian.
>>
>>>>> The images are bz2 compressed blockdevice images suitable for use on
>>>>> LVM or a file backed tapdisk if you have the appropriate backend.
>>>>> (alternatively you can use the loop device but this is discouraged)
>>>>> All images have serial console enabled, PV network and block devices,
>>>>> fixed udev rules etc.
>>>>>
>>>>> I will add more info about them, an FAQ about how they are setup and
>>>>> what you should do to customize them, expand the disk image etc soon.
>>>>>
>>>>> I am looking for someone to mirror these in the US for me, please
>>>>> email me if you have spare bandwith.
>>>>>
>>>>> Joseph.
>>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF539-0006h7-Nh; Tue, 03 Apr 2012 14:49:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SF538-0006gy-6n
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:49:34 +0000
Received: from [85.158.139.83:59261] by server-1.bemta-5.messagelabs.com id
	B0/44-28458-AFD0B7F4; Tue, 03 Apr 2012 14:49:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333464569!11040258!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22857 invoked from network); 3 Apr 2012 14:49:29 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:49:29 -0000
Received: by bkwj5 with SMTP id j5so3838976bkw.30
	for <multiple recipients>; Tue, 03 Apr 2012 07:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=bcpwPwMvkpn51WVj5bhJ9uJye2S21slxYd85G4nKghM=;
	b=alwGQ9B5WNmLmiJUZRKZ4Tu7IWfMmV5vJO615nCO2cPW8BnZ+EXA+4NjlpK1z0KA3/
	+K70zEs/BXnTAaVkfgXUGPNap+K32zxWTRwVnY8yNVBs/5dL1eoiYBlw9qcHN1vsdMw5
	FaoxfiB+NZZNPSTpp2mX3yj/tLq8uVhnbMzGsukBYO4zW2l6zALgj8jUDCr+7HF9udqO
	pDyjvYNZslhzDtipAFBwsdUEyodE/9g0AnvuijVi6uE//CA+7y8Qk7hzYHCgCYDp5a5R
	TsYMveGxzvUmwrB7yzNKsoBg2XrmZMZi2YqJEjqcUem8gLdd+Xajv8Iz8SkQN7QbfED4
	64gw==
Received: by 10.205.132.73 with SMTP id ht9mr5856828bkc.46.1333464569186;
	Tue, 03 Apr 2012 07:49:29 -0700 (PDT)
Received: from [172.16.25.10] (b0fb52a6.bb.sky.com. [176.251.82.166])
	by mx.google.com with ESMTPS id z17sm46460414bkw.12.2012.04.03.07.49.26
	(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 07:49:27 -0700 (PDT)
Message-ID: <4F7B0DF5.1010602@xen.org>
Date: Tue, 03 Apr 2012 15:49:25 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
	<1333450007.25602.130.camel@zakaz.uk.xensource.com>
	<20120403133038.GA84917@dhcp-3-120.uk.xensource.com>
In-Reply-To: <20120403133038.GA84917@dhcp-3-120.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the effort: do ping me when you guys are ready
Also when LiveCD's and the library is in place, that would be a great 
guest blog post on xen.org
Regards
Lars

On 03/04/2012 14:30, Roger Pau Monne wrote:
> On Tue, Apr 03, 2012 at 11:46:47AM +0100, Ian Campbell wrote:
>> On Mon, 2012-04-02 at 18:59 +0100, Joseph Glanville wrote:
>>> On 3 April 2012 02:11, Ian Campbell<Ian.Campbell@citrix.com>  wrote:
>>>> On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
>>>>> Hi guys,
>>>>>
>>>>> I have started preparing a library of PV-HVM templates for use on Xen
>>>>> 4.X+ and PVOPS dom0.
>>>> [...]
>>>>> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
>>>>> (the final beta, will be updated to final shortly).
>>>>> Included is an OS image, a config file, a README and the associated
>>>>> licences etc.
>>>> This is very cool, and you are correct that these will be very useful
>>>> for people trying to get something going quickly! Thanks Joseph.
>>> No problem, I am working on a new dom0 livecd too.
>>>
>>> I need some recommendations on what distro to base it on though...
>>> Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
>>> to be more enduring and a more beginner approachable alternative.
>>>
>>> Does anyone have any thoughts on this?
> I've been working with the Alpine Linux guys (http://alpinelinux.org/)
> for some time, and we managed to get a working Xen LiveCD, next major
> release (2.4 I think) it's gonna come with Xen Dom0 LiveCDs, since all
> the necessary bits have been added to the upstream distro build
> scripts. You can take a look at the build scripts here:
>
> http://git.alpinelinux.org/cgit/alpine-iso/
>
> It's really easy to generate a LiveCD iso, you just need a working
> Alpine Linux install (which can be a VM) and the alpine-iso scripts.
>
>> My personal preference would be Debian ;-) But pragmatically Ubuntu is,
>> I think, generally thought to be a good beginner distro and conveniently
>> it now contains support for Xen so that seems like a good choice.
>>
>> Also on the plus side is that Ubuntu may well contain the "Debian Live"
>> packages/infrastructure which make building Live CDs easier (I presume,
>> I've never tried them). I don't know if that's actually what is used by
>> Ubuntu to make their live CDs, if not then I'd hope that infrastructure
>> was in Ubuntu too.
>>
>> Ian.
>>
>>>>> The images are bz2 compressed blockdevice images suitable for use on
>>>>> LVM or a file backed tapdisk if you have the appropriate backend.
>>>>> (alternatively you can use the loop device but this is discouraged)
>>>>> All images have serial console enabled, PV network and block devices,
>>>>> fixed udev rules etc.
>>>>>
>>>>> I will add more info about them, an FAQ about how they are setup and
>>>>> what you should do to customize them, expand the disk image etc soon.
>>>>>
>>>>> I am looking for someone to mirror these in the US for me, please
>>>>> email me if you have spare bandwith.
>>>>>
>>>>> Joseph.
>>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:52:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF55h-0006vK-0U; Tue, 03 Apr 2012 14:52:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SF55g-0006v6-2i
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:52:12 +0000
Received: from [85.158.139.83:29636] by server-8.bemta-5.messagelabs.com id
	70/35-26964-B9E0B7F4; Tue, 03 Apr 2012 14:52:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333464729!22221305!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31951 invoked from network); 3 Apr 2012 14:52:10 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:52:10 -0000
Received: by qcsp15 with SMTP id p15so2844216qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Apr 2012 07:52:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lcyRNcT1zWH92GyXY2S1Hp0LzMAxKcL7869VLpkNWkc=;
	b=mLHjXDfOM2ZuoBOphfwZIjFpZPDDYpuH8ClvhRdOdJjRFH4y5PIap7MCIB8LhXhg9N
	TvE/Z66qY8m1b7JkHcSSsSNI6jp/L3FzhhTDIPc73rG46WosEIrUxgOBCvlGoXg1WPwZ
	xh4IG3MhVlFeyjCMKF9xU0oXgwXSmA+timC0LN3rqTenGn4UBocpgSoIsYXtbDMcdQ9z
	uiUUlE+0syvJKuwsiU6b1/l0CKKu42gWahJikKsx0U5mMh0hClGinmnh+dOnyZkyWn07
	GnoE8/LKuOZc+NrP45Px43c4luF7UMNgOE301Vc3gy9S+SelFZRYhDj7VDDp6nulsC7M
	9LGA==
MIME-Version: 1.0
Received: by 10.229.76.26 with SMTP id a26mr5276626qck.126.1333464728975; Tue,
	03 Apr 2012 07:52:08 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Tue, 3 Apr 2012 07:52:08 -0700 (PDT)
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
Date: Tue, 3 Apr 2012 15:52:08 +0100
X-Google-Sender-Auth: rK_HsBUQ6mFxB3kWDBjgT3mSBsk
Message-ID: <CAFLBxZZqPhM_6nYAvAvgGrwQ0GW2+K6=-nuKGa4aV=7sjPyYLA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BTW, that should be "[v3]"...

On Tue, Apr 3, 2012 at 2:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> This patch series adds the "permissive" option for passed-through devices
> which access config space out of the "known good" PCI config space.
>
> v2:
> - Added patch to move bdf parsing to libxlu
> - Addressed some formatting comments
>
> v3:
> - Don't make the struct initialization utility function public
> - Return error on failure
> - Wrap a long line
> - Clarify security warning / recommendation
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:52:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF55h-0006vK-0U; Tue, 03 Apr 2012 14:52:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SF55g-0006v6-2i
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:52:12 +0000
Received: from [85.158.139.83:29636] by server-8.bemta-5.messagelabs.com id
	70/35-26964-B9E0B7F4; Tue, 03 Apr 2012 14:52:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333464729!22221305!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31951 invoked from network); 3 Apr 2012 14:52:10 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:52:10 -0000
Received: by qcsp15 with SMTP id p15so2844216qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Apr 2012 07:52:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lcyRNcT1zWH92GyXY2S1Hp0LzMAxKcL7869VLpkNWkc=;
	b=mLHjXDfOM2ZuoBOphfwZIjFpZPDDYpuH8ClvhRdOdJjRFH4y5PIap7MCIB8LhXhg9N
	TvE/Z66qY8m1b7JkHcSSsSNI6jp/L3FzhhTDIPc73rG46WosEIrUxgOBCvlGoXg1WPwZ
	xh4IG3MhVlFeyjCMKF9xU0oXgwXSmA+timC0LN3rqTenGn4UBocpgSoIsYXtbDMcdQ9z
	uiUUlE+0syvJKuwsiU6b1/l0CKKu42gWahJikKsx0U5mMh0hClGinmnh+dOnyZkyWn07
	GnoE8/LKuOZc+NrP45Px43c4luF7UMNgOE301Vc3gy9S+SelFZRYhDj7VDDp6nulsC7M
	9LGA==
MIME-Version: 1.0
Received: by 10.229.76.26 with SMTP id a26mr5276626qck.126.1333464728975; Tue,
	03 Apr 2012 07:52:08 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Tue, 3 Apr 2012 07:52:08 -0700 (PDT)
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
Date: Tue, 3 Apr 2012 15:52:08 +0100
X-Google-Sender-Auth: rK_HsBUQ6mFxB3kWDBjgT3mSBsk
Message-ID: <CAFLBxZZqPhM_6nYAvAvgGrwQ0GW2+K6=-nuKGa4aV=7sjPyYLA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BTW, that should be "[v3]"...

On Tue, Apr 3, 2012 at 2:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> This patch series adds the "permissive" option for passed-through devices
> which access config space out of the "known good" PCI config space.
>
> v2:
> - Added patch to move bdf parsing to libxlu
> - Addressed some formatting comments
>
> v3:
> - Don't make the struct initialization utility function public
> - Return error on failure
> - Wrap a long line
> - Clarify security warning / recommendation
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:53:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF56m-00073f-FO; Tue, 03 Apr 2012 14:53:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF56l-00073R-B9
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:53:19 +0000
Received: from [85.158.143.99:13283] by server-3.bemta-4.messagelabs.com id
	DE/70-05853-EDE0B7F4; Tue, 03 Apr 2012 14:53:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333464797!16435834!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32739 invoked from network); 3 Apr 2012 14:53:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:53:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:53:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:53:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF56j-0005UQ-1N; Tue, 03 Apr 2012 14:53:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF56i-0005C3-VL;
	Tue, 03 Apr 2012 15:53:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3804.956615.607757@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:53:16 +0100
To: Steve Johnston <steve.johnston@adventiumlabs.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F7B0844.9000808@adventiumlabs.com>
References: <4F7B0844.9000808@adventiumlabs.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Submitting a patch for 4.0.1?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Steve Johnston writes ("[Xen-devel] Submitting a patch for 4.0.1?"):
> I have been using Xen 4.0.1 and have created/added a new scheduler that
> I would like to release into the mainline.
> 
> Am I able to submit a patch for an older version of Xen or do I need to
> port my changes to the current devel project?

New features of this kind will only be accepted into the mainline
development series.

However, it would be worthwhile posting your patches as they are,
against xen-4.0, so that we can see whether we are likely to accept
them.  That might save you some wasted effort if it turns out that
your new code is too hard to get into shape or unsuitable in some way.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:53:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF56m-00073f-FO; Tue, 03 Apr 2012 14:53:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF56l-00073R-B9
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:53:19 +0000
Received: from [85.158.143.99:13283] by server-3.bemta-4.messagelabs.com id
	DE/70-05853-EDE0B7F4; Tue, 03 Apr 2012 14:53:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333464797!16435834!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32739 invoked from network); 3 Apr 2012 14:53:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:53:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:53:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:53:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF56j-0005UQ-1N; Tue, 03 Apr 2012 14:53:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF56i-0005C3-VL;
	Tue, 03 Apr 2012 15:53:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3804.956615.607757@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:53:16 +0100
To: Steve Johnston <steve.johnston@adventiumlabs.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F7B0844.9000808@adventiumlabs.com>
References: <4F7B0844.9000808@adventiumlabs.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Submitting a patch for 4.0.1?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Steve Johnston writes ("[Xen-devel] Submitting a patch for 4.0.1?"):
> I have been using Xen 4.0.1 and have created/added a new scheduler that
> I would like to release into the mainline.
> 
> Am I able to submit a patch for an older version of Xen or do I need to
> port my changes to the current devel project?

New features of this kind will only be accepted into the mainline
development series.

However, it would be worthwhile posting your patches as they are,
against xen-4.0, so that we can see whether we are likely to accept
them.  That might save you some wasted effort if it turns out that
your new code is too hard to get into shape or unsuitable in some way.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:56:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF59b-0007Nm-BI; Tue, 03 Apr 2012 14:56:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF59a-0007Na-I2
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:56:14 +0000
Received: from [85.158.143.99:34761] by server-1.bemta-4.messagelabs.com id
	D1/62-20925-D8F0B7F4; Tue, 03 Apr 2012 14:56:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333464973!22117896!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29599 invoked from network); 3 Apr 2012 14:56:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:56:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:56:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:56:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF59Y-0005VM-Ed; Tue, 03 Apr 2012 14:56:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF59Y-0005Ce-DV;
	Tue, 03 Apr 2012 15:56:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3980.401034.775731@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:56:12 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <eed3dbadeb151d9d93cf.1331751730@probook.site>
References: <eed3dbadeb151d9d93cf.1331751730@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: do not install if vtpm can not
	be	build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: do not install if vtpm can not be build"):
> tools/vtpm: do not install if vtpm can not be build
> 
> A simple 'make tools' fails in vtpm because there is also a 'make install'
> during make tools. vtpm checks only in the build target wether it can be
> built at all, but the check is missing in the install target as well.

Thanks.  I have two comments: firstly, I think it would be best to
avoid repeating the test in the install rule.  If necessary you can
use a make variable to contain the runes.

But my second comment is: shouldn't this kind of test be done with
autoconf nowadays ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 14:56:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 14:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF59b-0007Nm-BI; Tue, 03 Apr 2012 14:56:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF59a-0007Na-I2
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 14:56:14 +0000
Received: from [85.158.143.99:34761] by server-1.bemta-4.messagelabs.com id
	D1/62-20925-D8F0B7F4; Tue, 03 Apr 2012 14:56:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333464973!22117896!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29599 invoked from network); 3 Apr 2012 14:56:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 14:56:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:56:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 15:56:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF59Y-0005VM-Ed; Tue, 03 Apr 2012 14:56:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF59Y-0005Ce-DV;
	Tue, 03 Apr 2012 15:56:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.3980.401034.775731@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 15:56:12 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <eed3dbadeb151d9d93cf.1331751730@probook.site>
References: <eed3dbadeb151d9d93cf.1331751730@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: do not install if vtpm can not
	be	build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: do not install if vtpm can not be build"):
> tools/vtpm: do not install if vtpm can not be build
> 
> A simple 'make tools' fails in vtpm because there is also a 'make install'
> during make tools. vtpm checks only in the build target wether it can be
> built at all, but the check is missing in the install target as well.

Thanks.  I have two comments: firstly, I think it would be best to
avoid repeating the test in the install rule.  If necessary you can
use a make variable to contain the runes.

But my second comment is: shouldn't this kind of test be done with
autoconf nowadays ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5EL-0007ee-3e; Tue, 03 Apr 2012 15:01:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF5EJ-0007eX-FX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:01:07 +0000
Received: from [85.158.143.35:45151] by server-1.bemta-4.messagelabs.com id
	11/3C-20925-2B01B7F4; Tue, 03 Apr 2012 15:01:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333465248!11676655!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31318 invoked from network); 3 Apr 2012 15:00:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:00:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 15:00:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 16:00:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF5E0-0005Wj-Fv; Tue, 03 Apr 2012 15:00:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF5E0-0005FJ-Ex;
	Tue, 03 Apr 2012 16:00:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.4256.425534.505814@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 16:00:48 +0100
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK758OK5Uj1ZDfSfyczSGLVZOW0ZZ3=ndtv62E4TpUOLvQ@mail.gmail.com>
References: <627966a0e6e5466fe71c.1331751845@probook.site>
	<CAPLaKK758OK5Uj1ZDfSfyczSGLVZOW0ZZ3=ndtv62E4TpUOLvQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] config/Tools.mk: remove unused IP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] config/Tools.mk: remove =
unused IP"):
> 2012/3/14 Olaf Hering <olaf@aepfle.de>:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1331751829 -3600
> > # Node ID 627966a0e6e5466fe71c10b79b610beb2e6f5aec
> > # Parent =A073a9d9c3ac9e9e1619167765c3bd9a9016e36e59
> > config/Tools.mk: remove unused IP
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> =

> Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I've submitted a patch some time ago to remove ip from the checks, but
> it looks like it was not fully applied:
> =

> http://lists.xen.org/archives/html/xen-devel/2012-02/msg02375.html

I'm not sure why that hunk seems to have gone astray.  Sorry.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5EL-0007ee-3e; Tue, 03 Apr 2012 15:01:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF5EJ-0007eX-FX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:01:07 +0000
Received: from [85.158.143.35:45151] by server-1.bemta-4.messagelabs.com id
	11/3C-20925-2B01B7F4; Tue, 03 Apr 2012 15:01:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333465248!11676655!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31318 invoked from network); 3 Apr 2012 15:00:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:00:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 15:00:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 16:00:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF5E0-0005Wj-Fv; Tue, 03 Apr 2012 15:00:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF5E0-0005FJ-Ex;
	Tue, 03 Apr 2012 16:00:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.4256.425534.505814@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 16:00:48 +0100
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK758OK5Uj1ZDfSfyczSGLVZOW0ZZ3=ndtv62E4TpUOLvQ@mail.gmail.com>
References: <627966a0e6e5466fe71c.1331751845@probook.site>
	<CAPLaKK758OK5Uj1ZDfSfyczSGLVZOW0ZZ3=ndtv62E4TpUOLvQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] config/Tools.mk: remove unused IP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] config/Tools.mk: remove =
unused IP"):
> 2012/3/14 Olaf Hering <olaf@aepfle.de>:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1331751829 -3600
> > # Node ID 627966a0e6e5466fe71c10b79b610beb2e6f5aec
> > # Parent =A073a9d9c3ac9e9e1619167765c3bd9a9016e36e59
> > config/Tools.mk: remove unused IP
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> =

> Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I've submitted a patch some time ago to remove ip from the checks, but
> it looks like it was not fully applied:
> =

> http://lists.xen.org/archives/html/xen-devel/2012-02/msg02375.html

I'm not sure why that hunk seems to have gone astray.  Sorry.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:02:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5F2-0007iC-H6; Tue, 03 Apr 2012 15:01:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5F1-0007i4-GX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:01:51 +0000
Received: from [85.158.143.35:56858] by server-1.bemta-4.messagelabs.com id
	B7/DD-20925-ED01B7F4; Tue, 03 Apr 2012 15:01:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333465307!8375247!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjA5NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjA5NDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11532 invoked from network); 3 Apr 2012 15:01:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:01:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333465307; l=465;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=NXmiRDS21hL7Q06V7v+ec+w5X7c=;
	b=izTMEyZXF9n+3s6e67aaJziM/2hXkP/fKOQw/3qrgkv7QIGbyX5WI+GOQOeHJC+wolc
	7rOMl73z1yydOot2WHV9YRu7nOFyST8y2Quh6XyZUlEcSzUau5VMX8ebDJcXQs7D4CkRs
	cG5fwmCgzeLSVepeX5uoHmKXqXGxp1iwsNg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (klopstock mo37) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 406aaeo33Emvvi ;
	Tue, 3 Apr 2012 17:01:47 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5E54518637; Tue,  3 Apr 2012 17:01:46 +0200 (CEST)
Date: Tue, 3 Apr 2012 17:01:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120403150146.GA8190@aepfle.de>
References: <eed3dbadeb151d9d93cf.1331751730@probook.site>
	<20347.3980.401034.775731@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20347.3980.401034.775731@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: do not install if vtpm can not
 be build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Jackson wrote:

> But my second comment is: shouldn't this kind of test be done with
> autoconf nowadays ?

Yes, that was my thinking as well after poking around some more in the
vtpm subdirectory. The header check for example can be done with
autoconf.

Since I more or less enabled vtpm by accident, and currently lack the
time to get this in shape for the 4.2 release, please drop this patch.
I will look at this later.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:02:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5F2-0007iC-H6; Tue, 03 Apr 2012 15:01:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5F1-0007i4-GX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:01:51 +0000
Received: from [85.158.143.35:56858] by server-1.bemta-4.messagelabs.com id
	B7/DD-20925-ED01B7F4; Tue, 03 Apr 2012 15:01:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333465307!8375247!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjA5NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjA5NDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11532 invoked from network); 3 Apr 2012 15:01:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:01:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333465307; l=465;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=NXmiRDS21hL7Q06V7v+ec+w5X7c=;
	b=izTMEyZXF9n+3s6e67aaJziM/2hXkP/fKOQw/3qrgkv7QIGbyX5WI+GOQOeHJC+wolc
	7rOMl73z1yydOot2WHV9YRu7nOFyST8y2Quh6XyZUlEcSzUau5VMX8ebDJcXQs7D4CkRs
	cG5fwmCgzeLSVepeX5uoHmKXqXGxp1iwsNg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (klopstock mo37) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 406aaeo33Emvvi ;
	Tue, 3 Apr 2012 17:01:47 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5E54518637; Tue,  3 Apr 2012 17:01:46 +0200 (CEST)
Date: Tue, 3 Apr 2012 17:01:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120403150146.GA8190@aepfle.de>
References: <eed3dbadeb151d9d93cf.1331751730@probook.site>
	<20347.3980.401034.775731@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20347.3980.401034.775731@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/vtpm: do not install if vtpm can not
 be build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Jackson wrote:

> But my second comment is: shouldn't this kind of test be done with
> autoconf nowadays ?

Yes, that was my thinking as well after poking around some more in the
vtpm subdirectory. The header check for example can be done with
autoconf.

Since I more or less enabled vtpm by accident, and currently lack the
time to get this in shape for the 4.2 release, please drop this patch.
I will look at this later.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:04:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:04:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5HJ-0007tx-8p; Tue, 03 Apr 2012 15:04:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF5HH-0007tk-VF
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:04:12 +0000
Received: from [85.158.143.99:35910] by server-3.bemta-4.messagelabs.com id
	6C/37-05853-B611B7F4; Tue, 03 Apr 2012 15:04:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333465449!22185509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20188 invoked from network); 3 Apr 2012 15:04:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 15:04:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 16:04:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF5HF-0005Xy-1m; Tue, 03 Apr 2012 15:04:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF5HF-0005MD-0f;
	Tue, 03 Apr 2012 16:04:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.4456.995330.29521@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 16:04:08 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAEwRVpP8bRd9hZ7dAQSixP9nXVkr5r1bM66MYw0kq0ErEYSiUw@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<CAEc3jaB2_pb+1+_p9_k3u0wi6brndD9c92CLVGSwiXs3VF2BRA@mail.gmail.com>
	<20319.31435.22473.410017@mariner.uk.xensource.com>
	<CAEwRVpOocrYBumgzdOb-4LuespKMFtjgKXiP7cuNCQmUj4X6iQ@mail.gmail.com>
	<20320.33559.746693.761673@mariner.uk.xensource.com>
	<CAEwRVpNX9BGYi+Q-+w5=inDMOqAt2gmXLC0NGFvqEq67GsXDVw@mail.gmail.com>
	<CAEwRVpP8bRd9hZ7dAQSixP9nXVkr5r1bM66MYw0kq0ErEYSiUw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Roderick Colenbrander <thunderbird2k@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
> libxl: write vifname in xenstore if set.
> 
> Simple fix to enable user to specify vif names.
> 
> xen-unstable changeset: 24459:caf9753d4cc1
> Backport-requested-by: Roderick Colenbrander <thunderbird2k@gmail.com>
> 
> Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>

Marvellous, thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:04:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:04:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5HJ-0007tx-8p; Tue, 03 Apr 2012 15:04:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF5HH-0007tk-VF
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:04:12 +0000
Received: from [85.158.143.99:35910] by server-3.bemta-4.messagelabs.com id
	6C/37-05853-B611B7F4; Tue, 03 Apr 2012 15:04:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333465449!22185509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20188 invoked from network); 3 Apr 2012 15:04:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 15:04:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 16:04:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF5HF-0005Xy-1m; Tue, 03 Apr 2012 15:04:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF5HF-0005MD-0f;
	Tue, 03 Apr 2012 16:04:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.4456.995330.29521@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 16:04:08 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAEwRVpP8bRd9hZ7dAQSixP9nXVkr5r1bM66MYw0kq0ErEYSiUw@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<CAEc3jaB2_pb+1+_p9_k3u0wi6brndD9c92CLVGSwiXs3VF2BRA@mail.gmail.com>
	<20319.31435.22473.410017@mariner.uk.xensource.com>
	<CAEwRVpOocrYBumgzdOb-4LuespKMFtjgKXiP7cuNCQmUj4X6iQ@mail.gmail.com>
	<20320.33559.746693.761673@mariner.uk.xensource.com>
	<CAEwRVpNX9BGYi+Q-+w5=inDMOqAt2gmXLC0NGFvqEq67GsXDVw@mail.gmail.com>
	<CAEwRVpP8bRd9hZ7dAQSixP9nXVkr5r1bM66MYw0kq0ErEYSiUw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Roderick Colenbrander <thunderbird2k@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
> libxl: write vifname in xenstore if set.
> 
> Simple fix to enable user to specify vif names.
> 
> xen-unstable changeset: 24459:caf9753d4cc1
> Backport-requested-by: Roderick Colenbrander <thunderbird2k@gmail.com>
> 
> Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>

Marvellous, thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:04:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5Hd-0007wp-OW; Tue, 03 Apr 2012 15:04:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5Hc-0007wG-62
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:04:32 +0000
Received: from [85.158.143.35:21791] by server-2.bemta-4.messagelabs.com id
	02/E2-17550-F711B7F4; Tue, 03 Apr 2012 15:04:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333465469!14531768!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjQxOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjQxOTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26262 invoked from network); 3 Apr 2012 15:04:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:04:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333465469; l=830;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Cgrm+NGzjVOCSRgzFgSl6tdp9r4=;
	b=DPvMGSeKm0e9e+rkf5uF2d1Sry3OfGfELPuuTRVbFS8PBXtaMF+C696397OvC5XDcFK
	YG21d9hBfGRZjNdBbcRI3gRDLODTT9Cb/wVh+Wbc3fNq10LaZv/mjRq0eDwKKS9w1l7P7
	yeabQw+5gawQc3aFj2371ZzHrDkhnean2R4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (klopstock mo45) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 606fc5o33EAiXz ;
	Tue, 3 Apr 2012 17:04:29 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 82F8518637; Tue,  3 Apr 2012 17:04:28 +0200 (CEST)
Date: Tue, 3 Apr 2012 17:04:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403150428.GB8190@aepfle.de>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
	<20346.53247.182217.288605@mariner.uk.xensource.com>
	<1333450222.25602.131.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333450222.25602.131.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Campbell wrote:

> On Tue, 2012-04-03 at 11:25 +0100, Ian Jackson wrote:
> > Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > > tools/libvchan: fix build errors caused by Werror in io.c
> > ...
> > > io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
> > ...
> > > -		writev(-1, iov, 2);
> > > +		/* Silence gcc warning, will always fail */
> > > +		if (writev(-1, iov, 2));
> > 
> > I still think this is an unpleasant idiom.  Does casting the result to
> > void not help ?

Just '(void)writev(...);' does not prevent the warning.

> What does writev(-1,...) even mean? Can we not just nuke it?

Its just there for debugging with strace. Wether the whole debug ca be
removed, no idea.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:04:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5Hd-0007wp-OW; Tue, 03 Apr 2012 15:04:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5Hc-0007wG-62
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:04:32 +0000
Received: from [85.158.143.35:21791] by server-2.bemta-4.messagelabs.com id
	02/E2-17550-F711B7F4; Tue, 03 Apr 2012 15:04:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333465469!14531768!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjQxOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjQxOTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26262 invoked from network); 3 Apr 2012 15:04:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:04:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333465469; l=830;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Cgrm+NGzjVOCSRgzFgSl6tdp9r4=;
	b=DPvMGSeKm0e9e+rkf5uF2d1Sry3OfGfELPuuTRVbFS8PBXtaMF+C696397OvC5XDcFK
	YG21d9hBfGRZjNdBbcRI3gRDLODTT9Cb/wVh+Wbc3fNq10LaZv/mjRq0eDwKKS9w1l7P7
	yeabQw+5gawQc3aFj2371ZzHrDkhnean2R4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (klopstock mo45) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 606fc5o33EAiXz ;
	Tue, 3 Apr 2012 17:04:29 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 82F8518637; Tue,  3 Apr 2012 17:04:28 +0200 (CEST)
Date: Tue, 3 Apr 2012 17:04:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403150428.GB8190@aepfle.de>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
	<20346.53247.182217.288605@mariner.uk.xensource.com>
	<1333450222.25602.131.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333450222.25602.131.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Campbell wrote:

> On Tue, 2012-04-03 at 11:25 +0100, Ian Jackson wrote:
> > Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > > tools/libvchan: fix build errors caused by Werror in io.c
> > ...
> > > io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
> > ...
> > > -		writev(-1, iov, 2);
> > > +		/* Silence gcc warning, will always fail */
> > > +		if (writev(-1, iov, 2));
> > 
> > I still think this is an unpleasant idiom.  Does casting the result to
> > void not help ?

Just '(void)writev(...);' does not prevent the warning.

> What does writev(-1,...) even mean? Can we not just nuke it?

Its just there for debugging with strace. Wether the whole debug ca be
removed, no idea.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:08:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5L7-0008K9-4j; Tue, 03 Apr 2012 15:08:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF5L6-0008K4-9F
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:08:08 +0000
Received: from [85.158.139.83:30824] by server-2.bemta-5.messagelabs.com id
	89/A5-17016-7521B7F4; Tue, 03 Apr 2012 15:08:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333465686!22312153!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18030 invoked from network); 3 Apr 2012 15:08:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 15:08:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 16:08:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF5L4-0005ZJ-5t; Tue, 03 Apr 2012 15:08:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF5L4-0005NL-4j;
	Tue, 03 Apr 2012 16:08:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.4694.131348.751694@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 16:08:06 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120324172757.GA29504@phenom.dumpdata.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
> And also these:
> 24140 tools: xend: tolerate empty state/*.xml

I have backported this.

> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only)
> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h
> 23426 libxl: Add support for passing in the host's E820 for PCI passthrough
> 23428 libxl: Add 'e820_host' option to config file.
> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate.

I'm not really convinced that these are appropriate for backporting to
a supposedly stable tree.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:08:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5L7-0008K9-4j; Tue, 03 Apr 2012 15:08:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF5L6-0008K4-9F
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:08:08 +0000
Received: from [85.158.139.83:30824] by server-2.bemta-5.messagelabs.com id
	89/A5-17016-7521B7F4; Tue, 03 Apr 2012 15:08:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333465686!22312153!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18030 invoked from network); 3 Apr 2012 15:08:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11749405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 15:08:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 16:08:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF5L4-0005ZJ-5t; Tue, 03 Apr 2012 15:08:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF5L4-0005NL-4j;
	Tue, 03 Apr 2012 16:08:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.4694.131348.751694@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 16:08:06 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120324172757.GA29504@phenom.dumpdata.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
> And also these:
> 24140 tools: xend: tolerate empty state/*.xml

I have backported this.

> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only)
> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h
> 23426 libxl: Add support for passing in the host's E820 for PCI passthrough
> 23428 libxl: Add 'e820_host' option to config file.
> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate.

I'm not really convinced that these are appropriate for backporting to
a supposedly stable tree.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:10:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5N0-0008RK-L5; Tue, 03 Apr 2012 15:10:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SF5Mz-0008RC-Gw
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:10:05 +0000
Received: from [85.158.143.35:26394] by server-2.bemta-4.messagelabs.com id
	DA/0E-17550-CC21B7F4; Tue, 03 Apr 2012 15:10:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333465802!11075994!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NzA0\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NzA0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31050 invoked from network); 3 Apr 2012 15:10:03 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-21.messagelabs.com with SMTP;
	3 Apr 2012 15:10:03 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 616CD7EC064;
	Tue,  3 Apr 2012 08:10:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DjOv2KlBMs/tn21wJX7hDGZVlzM5EX07XaMx6LHHoqEO
	yOVvEWl+J5/DnNmX4HpFD8qajXn7ecg0Bz9Y8Zg0rpiTGHhr/aFDL38RZ2TFw188
	spJAz51jMM1+vmeLmuuRVk+jIUcaOq/QCZb1k5JsLg5n4iOhlQ1Ye5LcURJX3t0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5s12g2ejFIFDlDYNwL0IzzXF1E4=; b=qeajz9SR
	dxECzvDlj7azzq3B/yS+gXswfftImKdNHZCE7zL7Oymzsc2L3LKZq0MFzEDb3XA1
	jPfKI2oc0/saqE3wEmPxfe8LJB0haCKe6mlf3lDSp6R8n4QpM1A1sULTYPn45djs
	7IpBQvqJZSGtGWFUpStjT+V2kFGHd8aqw9c=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id C8A307EC076; 
	Tue,  3 Apr 2012 08:09:58 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 3 Apr 2012 08:10:01 -0700
Message-ID: <6f1b5e62a00fdde387f1b242c13a01e8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120403144208.GA7284@aepfle.de>
References: <patchbomb.1332863006@xdev.gridcentric.ca>
	<20120329110357.GE72859@ocelot.phlegethon.org>
	<7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
	<20120403144208.GA7284@aepfle.de>
Date: Tue, 3 Apr 2012 08:10:01 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: keir@xen.org, andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, wei.wang2@amd.com, jbeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Support for Paging/Sharing on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, Mar 29, Andres Lagar-Cavilla wrote:
>
>> The question now is what to do for AMD+paging in Xen 4.2. It works
>> partially, there are still VMEXIT_shutdown hvm crashes happening with pv
>> drivers.
>
> I tested it with openSuSE 11.4 and the kernel-xen shipped with it and a
> sles11sp2 guest. paging works in that combination, I did a fresh
> installation in the guest and went half way through it. The cfg is
> below, in case it matters.
>
> Its possible that a pvops kernel in host or guest triggers some issues.
>
> Thanks anyway for doing that work, Andres!

Not a problem. Very glad it's working nicely.

It's Windows PV drivers on the guest, during resume, that trigger the
issue. Not easiest to track. Wei and his colleagues at AMD have been
lending a a very helpful hand.

If you have time, could you add the following data point: Linux guest with
PV drivers? (hit the network hard, balloon, etc)

Thanks!
Andres
>
> Olaf
>
>
> # /etc/xen/vm/hvm1
> builder='hvm'
> memory = 512
> name = "ExampleHVMDomain1"
> disk = [ 'file:/dev/shm/loopfile,hda,w',
> 'file:/dist/iso/sles11/cdn.novell.com/prot/sles11sp2-x86_64/SLES-11-SP2-DVD-x86_64-GM-DVD1.iso,hdc:cdrom,r'
> ]
> sdl=0
> opengl=1
> vnc=1
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> mem_target_paging=123
> xenpaging_extra=[ '-f' , '/dev/shm/pagingfile', '-v' ]
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:10:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5N0-0008RK-L5; Tue, 03 Apr 2012 15:10:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SF5Mz-0008RC-Gw
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:10:05 +0000
Received: from [85.158.143.35:26394] by server-2.bemta-4.messagelabs.com id
	DA/0E-17550-CC21B7F4; Tue, 03 Apr 2012 15:10:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333465802!11075994!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NzA0\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NzA0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31050 invoked from network); 3 Apr 2012 15:10:03 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-21.messagelabs.com with SMTP;
	3 Apr 2012 15:10:03 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 616CD7EC064;
	Tue,  3 Apr 2012 08:10:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DjOv2KlBMs/tn21wJX7hDGZVlzM5EX07XaMx6LHHoqEO
	yOVvEWl+J5/DnNmX4HpFD8qajXn7ecg0Bz9Y8Zg0rpiTGHhr/aFDL38RZ2TFw188
	spJAz51jMM1+vmeLmuuRVk+jIUcaOq/QCZb1k5JsLg5n4iOhlQ1Ye5LcURJX3t0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5s12g2ejFIFDlDYNwL0IzzXF1E4=; b=qeajz9SR
	dxECzvDlj7azzq3B/yS+gXswfftImKdNHZCE7zL7Oymzsc2L3LKZq0MFzEDb3XA1
	jPfKI2oc0/saqE3wEmPxfe8LJB0haCKe6mlf3lDSp6R8n4QpM1A1sULTYPn45djs
	7IpBQvqJZSGtGWFUpStjT+V2kFGHd8aqw9c=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id C8A307EC076; 
	Tue,  3 Apr 2012 08:09:58 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 3 Apr 2012 08:10:01 -0700
Message-ID: <6f1b5e62a00fdde387f1b242c13a01e8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120403144208.GA7284@aepfle.de>
References: <patchbomb.1332863006@xdev.gridcentric.ca>
	<20120329110357.GE72859@ocelot.phlegethon.org>
	<7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
	<20120403144208.GA7284@aepfle.de>
Date: Tue, 3 Apr 2012 08:10:01 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: keir@xen.org, andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, wei.wang2@amd.com, jbeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Support for Paging/Sharing on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, Mar 29, Andres Lagar-Cavilla wrote:
>
>> The question now is what to do for AMD+paging in Xen 4.2. It works
>> partially, there are still VMEXIT_shutdown hvm crashes happening with pv
>> drivers.
>
> I tested it with openSuSE 11.4 and the kernel-xen shipped with it and a
> sles11sp2 guest. paging works in that combination, I did a fresh
> installation in the guest and went half way through it. The cfg is
> below, in case it matters.
>
> Its possible that a pvops kernel in host or guest triggers some issues.
>
> Thanks anyway for doing that work, Andres!

Not a problem. Very glad it's working nicely.

It's Windows PV drivers on the guest, during resume, that trigger the
issue. Not easiest to track. Wei and his colleagues at AMD have been
lending a a very helpful hand.

If you have time, could you add the following data point: Linux guest with
PV drivers? (hit the network hard, balloon, etc)

Thanks!
Andres
>
> Olaf
>
>
> # /etc/xen/vm/hvm1
> builder='hvm'
> memory = 512
> name = "ExampleHVMDomain1"
> disk = [ 'file:/dev/shm/loopfile,hda,w',
> 'file:/dist/iso/sles11/cdn.novell.com/prot/sles11sp2-x86_64/SLES-11-SP2-DVD-x86_64-GM-DVD1.iso,hdc:cdrom,r'
> ]
> sdl=0
> opengl=1
> vnc=1
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> mem_target_paging=123
> xenpaging_extra=[ '-f' , '/dev/shm/pagingfile', '-v' ]
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5SE-0000Hs-Gm; Tue, 03 Apr 2012 15:15:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SF5SC-0000Hn-IJ
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:15:28 +0000
Received: from [85.158.143.35:34788] by server-3.bemta-4.messagelabs.com id
	A2/3D-05853-F041B7F4; Tue, 03 Apr 2012 15:15:27 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333466124!17016346!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23909 invoked from network); 3 Apr 2012 15:15:26 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:15:26 -0000
Received: by dajx4 with SMTP id x4so4294219daj.28
	for <xen-devel@lists.xen.org>; Tue, 03 Apr 2012 08:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lx13Ajcg7GLmXNiSuavZIVjN246OrggS/MBcfP7wod4=;
	b=SQxWpiiwvygy+JpgV7AieoYDNSsVNJwoH2sGNWkOUxXWu7mnj2FcR8YjDBkueZkaqH
	GrhD7ZN3McMNHXLQMr4zh60RS9HUMAiVMH/kyNzMDc/SBqVRmA5vyd3xC6kEhFNh6+l3
	F+7aM1Z6wyaBpGyzW+GELPUWD7XRoDRc5wUk5t+9ojX/q+uBnpp1BYjp9YeTUdvAA1ja
	iumbVkwAc4k1HBA2U+Hcr2EkYyBDm+l6WWtulxFjsGFsWCNiEeNKcBA6vzcjJpmU1Zhk
	IDCJgPgz4Z9lGPMXGIVjfEKjt9VSu7eP6echS+gyEGyv8XyCXuDqptZfYh3WsZ1oQIfu
	uNWg==
MIME-Version: 1.0
Received: by 10.68.227.73 with SMTP id ry9mr29926240pbc.33.1333466123435; Tue,
	03 Apr 2012 08:15:23 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Tue, 3 Apr 2012 08:15:23 -0700 (PDT)
In-Reply-To: <20347.4694.131348.751694@mariner.uk.xensource.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 23:15:23 +0800
Message-ID: <CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir.xen@gmail.com,
	xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
>> And also these:
>> 24140 tools: xend: tolerate empty state/*.xml
>
> I have backported this.
>
>> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only)
>> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h
>> 23426 libxl: Add support for passing in the host's E820 for PCI passthrough
>> 23428 libxl: Add 'e820_host' option to config file.
>> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate.
>
> I'm not really convinced that these are appropriate for backporting to
> a supposedly stable tree.

What about the changeset 25131:6f81f4d79fde?  It won't be able to
apply cleanly in xen-4.1-testing though and I can provide the backport
version for review if you give an OK?

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5SE-0000Hs-Gm; Tue, 03 Apr 2012 15:15:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SF5SC-0000Hn-IJ
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:15:28 +0000
Received: from [85.158.143.35:34788] by server-3.bemta-4.messagelabs.com id
	A2/3D-05853-F041B7F4; Tue, 03 Apr 2012 15:15:27 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333466124!17016346!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23909 invoked from network); 3 Apr 2012 15:15:26 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:15:26 -0000
Received: by dajx4 with SMTP id x4so4294219daj.28
	for <xen-devel@lists.xen.org>; Tue, 03 Apr 2012 08:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lx13Ajcg7GLmXNiSuavZIVjN246OrggS/MBcfP7wod4=;
	b=SQxWpiiwvygy+JpgV7AieoYDNSsVNJwoH2sGNWkOUxXWu7mnj2FcR8YjDBkueZkaqH
	GrhD7ZN3McMNHXLQMr4zh60RS9HUMAiVMH/kyNzMDc/SBqVRmA5vyd3xC6kEhFNh6+l3
	F+7aM1Z6wyaBpGyzW+GELPUWD7XRoDRc5wUk5t+9ojX/q+uBnpp1BYjp9YeTUdvAA1ja
	iumbVkwAc4k1HBA2U+Hcr2EkYyBDm+l6WWtulxFjsGFsWCNiEeNKcBA6vzcjJpmU1Zhk
	IDCJgPgz4Z9lGPMXGIVjfEKjt9VSu7eP6echS+gyEGyv8XyCXuDqptZfYh3WsZ1oQIfu
	uNWg==
MIME-Version: 1.0
Received: by 10.68.227.73 with SMTP id ry9mr29926240pbc.33.1333466123435; Tue,
	03 Apr 2012 08:15:23 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Tue, 3 Apr 2012 08:15:23 -0700 (PDT)
In-Reply-To: <20347.4694.131348.751694@mariner.uk.xensource.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 23:15:23 +0800
Message-ID: <CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir.xen@gmail.com,
	xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
>> And also these:
>> 24140 tools: xend: tolerate empty state/*.xml
>
> I have backported this.
>
>> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only)
>> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h
>> 23426 libxl: Add support for passing in the host's E820 for PCI passthrough
>> 23428 libxl: Add 'e820_host' option to config file.
>> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate.
>
> I'm not really convinced that these are appropriate for backporting to
> a supposedly stable tree.

What about the changeset 25131:6f81f4d79fde?  It won't be able to
apply cleanly in xen-4.1-testing though and I can provide the backport
version for review if you give an OK?

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:17:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5Th-0000Mt-W7; Tue, 03 Apr 2012 15:17:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5Tg-0000Mn-M5
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:17:00 +0000
Received: from [85.158.138.51:16722] by server-3.bemta-3.messagelabs.com id
	B5/94-10665-B641B7F4; Tue, 03 Apr 2012 15:16:59 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333466219!20637656!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19788 invoked from network); 3 Apr 2012 15:16:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:16:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333466218; l=343;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=84MxtPj/hYvB8lh9+jWiKp8I57I=;
	b=QZVdix1xuQa6SfeKKusv1XJo/Uw+ichZaaKXyhBAdebMFOHGix9P38NcdeJZ71KfwKG
	IfLzVi10RkK27IFsOgNfFM8rts2qCEajWiv2TsnMCyOUBVmQ5Ts4d2O8YrX4XZvOikzff
	+KqPq1BeLNmbWrNa7mrki7nYgRBBLLermeA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by post.strato.de (mrclete mo19) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C02da8o33EhQaL ;
	Tue, 3 Apr 2012 17:16:53 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id C527E18637; Tue,  3 Apr 2012 17:16:52 +0200 (CEST)
Date: Tue, 3 Apr 2012 17:16:52 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120403151652.GA10263@aepfle.de>
References: <patchbomb.1332863006@xdev.gridcentric.ca>
	<20120329110357.GE72859@ocelot.phlegethon.org>
	<7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
	<20120403144208.GA7284@aepfle.de>
	<6f1b5e62a00fdde387f1b242c13a01e8.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6f1b5e62a00fdde387f1b242c13a01e8.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: keir@xen.org, andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, wei.wang2@amd.com, jbeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Support for Paging/Sharing on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Andres Lagar-Cavilla wrote:

> If you have time, could you add the following data point: Linux guest with
> PV drivers? (hit the network hard, balloon, etc)

The workload was just block io, sles11sp2 has PV drivers included. I
forgot to balloon up and down, will do so once I get the chance to do
more testing.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:17:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5Th-0000Mt-W7; Tue, 03 Apr 2012 15:17:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5Tg-0000Mn-M5
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 15:17:00 +0000
Received: from [85.158.138.51:16722] by server-3.bemta-3.messagelabs.com id
	B5/94-10665-B641B7F4; Tue, 03 Apr 2012 15:16:59 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333466219!20637656!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTY4OTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19788 invoked from network); 3 Apr 2012 15:16:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:16:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333466218; l=343;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=84MxtPj/hYvB8lh9+jWiKp8I57I=;
	b=QZVdix1xuQa6SfeKKusv1XJo/Uw+ichZaaKXyhBAdebMFOHGix9P38NcdeJZ71KfwKG
	IfLzVi10RkK27IFsOgNfFM8rts2qCEajWiv2TsnMCyOUBVmQ5Ts4d2O8YrX4XZvOikzff
	+KqPq1BeLNmbWrNa7mrki7nYgRBBLLermeA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by post.strato.de (mrclete mo19) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C02da8o33EhQaL ;
	Tue, 3 Apr 2012 17:16:53 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id C527E18637; Tue,  3 Apr 2012 17:16:52 +0200 (CEST)
Date: Tue, 3 Apr 2012 17:16:52 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120403151652.GA10263@aepfle.de>
References: <patchbomb.1332863006@xdev.gridcentric.ca>
	<20120329110357.GE72859@ocelot.phlegethon.org>
	<7e6f4eefa902b1d9bbfc918e29c867d7.squirrel@webmail.lagarcavilla.org>
	<20120403144208.GA7284@aepfle.de>
	<6f1b5e62a00fdde387f1b242c13a01e8.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6f1b5e62a00fdde387f1b242c13a01e8.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: keir@xen.org, andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, wei.wang2@amd.com, jbeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Support for Paging/Sharing on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Andres Lagar-Cavilla wrote:

> If you have time, could you add the following data point: Linux guest with
> PV drivers? (hit the network hard, balloon, etc)

The workload was just block io, sles11sp2 has PV drivers included. I
forgot to balloon up and down, will do so once I get the chance to do
more testing.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:24:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5af-0000d5-Rz; Tue, 03 Apr 2012 15:24:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5ae-0000cx-In
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:24:12 +0000
Received: from [85.158.143.35:34556] by server-2.bemta-4.messagelabs.com id
	29/C7-17550-B161B7F4; Tue, 03 Apr 2012 15:24:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333466650!14536467!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzU3NjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzU3NjA=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 455 invoked from network); 3 Apr 2012 15:24:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:24:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333466649; l=1901;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=AGWGX+YyQvSap3bhzeu5+k3uvAk=;
	b=zEiU+A3BrBu+jZ78re9TsX+4yGAReKf6gVkKHxp/u/RdjbFm4PUb6exGidlJnZiAhpY
	sgyRD24pH2JXzL1Q2HgonwFljwMWCX0iixywlgUr0LM+v6TcciTov2DNVfoGStw6WVz1s
	mg1mw9FUh3q+rn/gSQwWZAcPK04t6Su02pk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by post.strato.de (mrclete mo37) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 403853o33Em4Cs ;
	Tue, 3 Apr 2012 17:24:09 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E7BC218630;
	Tue,  3 Apr 2012 17:24:08 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 77e9be40fbc8ef0df02e49e74496320729eccb09
Message-Id: <77e9be40fbc8ef0df02e.1333466642@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 03 Apr 2012 17:24:02 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH] domctl.h: document non-standard error codes for
 enabling paging/access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333466579 -7200
# Node ID 77e9be40fbc8ef0df02e49e74496320729eccb09
# Parent  72fc7f65e34f9215af0cb73417ddd47ee0f3bc79
domctl.h: document non-standard error codes for enabling paging/access

The domctl to enable paging and access returns some non-standard error
codes after failure. This can be used in the tools to print specific
error messages. xenpaging recognizes these errno values and shows them
if the init function fails.

Document the return codes in the public header file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 72fc7f65e34f -r 77e9be40fbc8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -716,6 +716,13 @@ struct xen_domctl_gdbsx_domstatus {
  * Domctl interface to set up and tear down the 
  * pager<->hypervisor interface. Use XENMEM_paging_op*
  * to perform per-page operations.
+ *
+ * The XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE domctl returns several
+ * non-standard error codes to indicate why paging could not be enabled:
+ * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
+ * EMLINK - guest has iommu passthrough enabled
+ * EXDEV  - guest has PoD enabled
+ * EBUSY  - guest has or had paging enabled, ring buffer still active
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
@@ -735,6 +742,11 @@ struct xen_domctl_gdbsx_domstatus {
  *
  * The memory event handler can then resume the VCPU and redo the access 
  * with a XENMEM_access_op_resume hypercall.
+ *
+ * The XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE domctl returns several
+ * non-standard error codes to indicate why access could not be enabled:
+ * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
+ * EBUSY  - guest has or had access enabled, ring buffer still active
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:24:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5af-0000d5-Rz; Tue, 03 Apr 2012 15:24:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF5ae-0000cx-In
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:24:12 +0000
Received: from [85.158.143.35:34556] by server-2.bemta-4.messagelabs.com id
	29/C7-17550-B161B7F4; Tue, 03 Apr 2012 15:24:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333466650!14536467!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzU3NjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzU3NjA=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 455 invoked from network); 3 Apr 2012 15:24:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 15:24:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333466649; l=1901;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=AGWGX+YyQvSap3bhzeu5+k3uvAk=;
	b=zEiU+A3BrBu+jZ78re9TsX+4yGAReKf6gVkKHxp/u/RdjbFm4PUb6exGidlJnZiAhpY
	sgyRD24pH2JXzL1Q2HgonwFljwMWCX0iixywlgUr0LM+v6TcciTov2DNVfoGStw6WVz1s
	mg1mw9FUh3q+rn/gSQwWZAcPK04t6Su02pk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by post.strato.de (mrclete mo37) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 403853o33Em4Cs ;
	Tue, 3 Apr 2012 17:24:09 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E7BC218630;
	Tue,  3 Apr 2012 17:24:08 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 77e9be40fbc8ef0df02e49e74496320729eccb09
Message-Id: <77e9be40fbc8ef0df02e.1333466642@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 03 Apr 2012 17:24:02 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH] domctl.h: document non-standard error codes for
 enabling paging/access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333466579 -7200
# Node ID 77e9be40fbc8ef0df02e49e74496320729eccb09
# Parent  72fc7f65e34f9215af0cb73417ddd47ee0f3bc79
domctl.h: document non-standard error codes for enabling paging/access

The domctl to enable paging and access returns some non-standard error
codes after failure. This can be used in the tools to print specific
error messages. xenpaging recognizes these errno values and shows them
if the init function fails.

Document the return codes in the public header file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 72fc7f65e34f -r 77e9be40fbc8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -716,6 +716,13 @@ struct xen_domctl_gdbsx_domstatus {
  * Domctl interface to set up and tear down the 
  * pager<->hypervisor interface. Use XENMEM_paging_op*
  * to perform per-page operations.
+ *
+ * The XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE domctl returns several
+ * non-standard error codes to indicate why paging could not be enabled:
+ * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
+ * EMLINK - guest has iommu passthrough enabled
+ * EXDEV  - guest has PoD enabled
+ * EBUSY  - guest has or had paging enabled, ring buffer still active
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
@@ -735,6 +742,11 @@ struct xen_domctl_gdbsx_domstatus {
  *
  * The memory event handler can then resume the VCPU and redo the access 
  * with a XENMEM_access_op_resume hypercall.
+ *
+ * The XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE domctl returns several
+ * non-standard error codes to indicate why access could not be enabled:
+ * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
+ * EBUSY  - guest has or had access enabled, ring buffer still active
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j7-0000oR-JL; Tue, 03 Apr 2012 15:32:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j6-0000nr-1b
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:56 +0000
Received: from [85.158.138.51:35694] by server-1.bemta-3.messagelabs.com id
	11/AE-04539-7281B7F4; Tue, 03 Apr 2012 15:32:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333467172!20443358!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8137 invoked from network); 3 Apr 2012 15:32:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-3m;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:35 +0100
Message-ID: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 0/8] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.


Please review patches number 1, 2, 3, 4 and 7.



First, we have XenHostPCIDevice that help to access one PCI device of the host.

Then, the PCI passthrough device himself. Cut in 3 parts (or file), there is
one to take care of the initialisation of a passthrough device. The second one
handle everything about the config address space, there are specifics functions
for every config register. The third one is to handle MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change v10-v11:
  host-pci-device:
    - update api: remove IORESOURCE_* defines from header file.
    - address comment of Konrad.
  xen-pt:
    - fix memory mapping (Xen side) for a PCI BAR with a size under the size of
      a page.

Change v9-v10:
  host-pci-device:
    - rename to xen-host-pci-device.
    - suppress usage of scanf and use strtol instead.
    - add irq field
    - no more goto loop
  xen_pt:
    - take machine_irq value from XenHostPCIDevice instead of reading it from
      the pci config space
    - rename xen_pci_device to xen_pt
    - use xen_pt as prefix
      # this should fix namespace issue

Change v8-v9:
  - rename PCI_DEVICE_ID_INTEL_82599_VF to PCI_DEVICE_ID_INTEL_82599_SFP_VF to
    be consistant with Linux.
  - remove the patch about checking bar overlaps, the function is now in
    xen_pci_passthrough.c and uses pci_for_each_device.
  - Introduce an opaque argument to the function pci_for_each_device.
  - Fix the usage of memory listener: declare a stub function for every
    callback in the MemoryListener.

Change v7-v8:
  - rework of the memory mapping of BARs. We now use a memory_listener to update
    a xen memory_mapping when a memory_region is updated.
  - address few comment from Michael in the pci_check_overlap function.
  - fix the handling of the ROM slot.

Change v6-v7:
  - few fix and rebased on master
  - remove of the power management capability, keep the minimum like if it is
    always desactivated.
  - new patch: port of patch from the qemu-xen fork.

Change v5-v6:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.

Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property




Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (5):
  pci_ids: Add INTEL_82599_SFP_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce XenHostPCIDevice to access a pci device on the host.
  pci.c: Add opaque argument to pci_for_each_device.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

 Makefile.target          |    6 +
 configure                |   25 +
 hw/apic-msidef.h         |   30 +
 hw/apic.c                |   11 +-
 hw/pci.c                 |   11 +-
 hw/pci.h                 |    4 +-
 hw/pci_ids.h             |    1 +
 hw/xen-host-pci-device.c |  393 ++++++++++
 hw/xen-host-pci-device.h |   55 ++
 hw/xen_common.h          |    3 +
 hw/xen_platform.c        |    8 +-
 hw/xen_pt.c              |  854 +++++++++++++++++++++
 hw/xen_pt.h              |  301 ++++++++
 hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c          |  620 +++++++++++++++
 xen-all.c                |   12 +
 16 files changed, 4184 insertions(+), 19 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c
 create mode 100644 hw/xen_pt_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j7-0000oR-JL; Tue, 03 Apr 2012 15:32:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j6-0000nr-1b
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:56 +0000
Received: from [85.158.138.51:35694] by server-1.bemta-3.messagelabs.com id
	11/AE-04539-7281B7F4; Tue, 03 Apr 2012 15:32:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333467172!20443358!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8137 invoked from network); 3 Apr 2012 15:32:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-3m;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:35 +0100
Message-ID: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 0/8] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.


Please review patches number 1, 2, 3, 4 and 7.



First, we have XenHostPCIDevice that help to access one PCI device of the host.

Then, the PCI passthrough device himself. Cut in 3 parts (or file), there is
one to take care of the initialisation of a passthrough device. The second one
handle everything about the config address space, there are specifics functions
for every config register. The third one is to handle MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change v10-v11:
  host-pci-device:
    - update api: remove IORESOURCE_* defines from header file.
    - address comment of Konrad.
  xen-pt:
    - fix memory mapping (Xen side) for a PCI BAR with a size under the size of
      a page.

Change v9-v10:
  host-pci-device:
    - rename to xen-host-pci-device.
    - suppress usage of scanf and use strtol instead.
    - add irq field
    - no more goto loop
  xen_pt:
    - take machine_irq value from XenHostPCIDevice instead of reading it from
      the pci config space
    - rename xen_pci_device to xen_pt
    - use xen_pt as prefix
      # this should fix namespace issue

Change v8-v9:
  - rename PCI_DEVICE_ID_INTEL_82599_VF to PCI_DEVICE_ID_INTEL_82599_SFP_VF to
    be consistant with Linux.
  - remove the patch about checking bar overlaps, the function is now in
    xen_pci_passthrough.c and uses pci_for_each_device.
  - Introduce an opaque argument to the function pci_for_each_device.
  - Fix the usage of memory listener: declare a stub function for every
    callback in the MemoryListener.

Change v7-v8:
  - rework of the memory mapping of BARs. We now use a memory_listener to update
    a xen memory_mapping when a memory_region is updated.
  - address few comment from Michael in the pci_check_overlap function.
  - fix the handling of the ROM slot.

Change v6-v7:
  - few fix and rebased on master
  - remove of the power management capability, keep the minimum like if it is
    always desactivated.
  - new patch: port of patch from the qemu-xen fork.

Change v5-v6:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.

Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property




Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (5):
  pci_ids: Add INTEL_82599_SFP_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce XenHostPCIDevice to access a pci device on the host.
  pci.c: Add opaque argument to pci_for_each_device.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

 Makefile.target          |    6 +
 configure                |   25 +
 hw/apic-msidef.h         |   30 +
 hw/apic.c                |   11 +-
 hw/pci.c                 |   11 +-
 hw/pci.h                 |    4 +-
 hw/pci_ids.h             |    1 +
 hw/xen-host-pci-device.c |  393 ++++++++++
 hw/xen-host-pci-device.h |   55 ++
 hw/xen_common.h          |    3 +
 hw/xen_platform.c        |    8 +-
 hw/xen_pt.c              |  854 +++++++++++++++++++++
 hw/xen_pt.h              |  301 ++++++++
 hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c          |  620 +++++++++++++++
 xen-all.c                |   12 +
 16 files changed, 4184 insertions(+), 19 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c
 create mode 100644 hw/xen_pt_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j7-0000oG-7D; Tue, 03 Apr 2012 15:32:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j5-0000nP-4O
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:55 +0000
Received: from [85.158.143.35:30824] by server-2.bemta-4.messagelabs.com id
	01/38-17550-6281B7F4; Tue, 03 Apr 2012 15:32:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12954 invoked from network); 3 Apr 2012 15:32:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824555"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-8r;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:39 +0100
Message-ID: <1333467163-25795-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 4/8] pci.c: Add opaque argument to
	pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The purpose is to have a more generic pci_for_each_device by passing an extra
argument to the function called on every device.

This patch will be used in a next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci.c          |   11 +++++++----
 hw/pci.h          |    4 +++-
 hw/xen_platform.c |    8 ++++----
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 77001fa..49f1bf0 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1123,7 +1123,9 @@ static const pci_class_desc pci_class_descriptions[] =
 };
 
 static void pci_for_each_device_under_bus(PCIBus *bus,
-                                          void (*fn)(PCIBus *b, PCIDevice *d))
+                                          void (*fn)(PCIBus *b, PCIDevice *d,
+                                                     void *opaque),
+                                          void *opaque)
 {
     PCIDevice *d;
     int devfn;
@@ -1131,18 +1133,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
     for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
         d = bus->devices[devfn];
         if (d) {
-            fn(bus, d);
+            fn(bus, d, opaque);
         }
     }
 }
 
 void pci_for_each_device(PCIBus *bus, int bus_num,
-                         void (*fn)(PCIBus *b, PCIDevice *d))
+                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
+                         void *opaque)
 {
     bus = pci_find_bus(bus, bus_num);
 
     if (bus) {
-        pci_for_each_device_under_bus(bus, fn);
+        pci_for_each_device_under_bus(bus, fn, opaque);
     }
 }
 
diff --git a/hw/pci.h b/hw/pci.h
index 4f19fdb..2827fd1 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -296,7 +296,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
 PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
                                const char *default_devaddr);
 int pci_bus_num(PCIBus *s);
-void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
+void pci_for_each_device(PCIBus *bus, int bus_num,
+                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
+                         void *opaque);
 PCIBus *pci_find_root_bus(int domain);
 int pci_find_domain(const PCIBus *bus);
 PCIBus *pci_find_bus(PCIBus *bus, int bus_num);
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 5a7c4cc..88ff5e8 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 #define UNPLUG_ALL_NICS 2
 #define UNPLUG_AUX_IDE_DISKS 4
 
-static void unplug_nic(PCIBus *b, PCIDevice *d)
+static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_NETWORK_ETHERNET) {
@@ -93,10 +93,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_nics(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_nic);
+    pci_for_each_device(bus, 0, unplug_nic, NULL);
 }
 
-static void unplug_disks(PCIBus *b, PCIDevice *d)
+static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_STORAGE_IDE) {
@@ -106,7 +106,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_disks(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_disks);
+    pci_for_each_device(bus, 0, unplug_disks, NULL);
 }
 
 static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j6-0000ny-Er; Tue, 03 Apr 2012 15:32:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j4-0000nP-FS
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:54 +0000
Received: from [85.158.143.35:21685] by server-2.bemta-4.messagelabs.com id
	74/28-17550-5281B7F4; Tue, 03 Apr 2012 15:32:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12855 invoked from network); 3 Apr 2012 15:32:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824553"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-6N;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:37 +0100
Message-ID: <1333467163-25795-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 2/8] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 4b3adc9..c84a252 100755
--- a/configure
+++ b/configure
@@ -136,6 +136,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -682,6 +683,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1034,6 +1039,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1478,6 +1485,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3643,6 +3665,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j7-0000oG-7D; Tue, 03 Apr 2012 15:32:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j5-0000nP-4O
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:55 +0000
Received: from [85.158.143.35:30824] by server-2.bemta-4.messagelabs.com id
	01/38-17550-6281B7F4; Tue, 03 Apr 2012 15:32:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12954 invoked from network); 3 Apr 2012 15:32:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824555"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-8r;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:39 +0100
Message-ID: <1333467163-25795-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 4/8] pci.c: Add opaque argument to
	pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The purpose is to have a more generic pci_for_each_device by passing an extra
argument to the function called on every device.

This patch will be used in a next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci.c          |   11 +++++++----
 hw/pci.h          |    4 +++-
 hw/xen_platform.c |    8 ++++----
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 77001fa..49f1bf0 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1123,7 +1123,9 @@ static const pci_class_desc pci_class_descriptions[] =
 };
 
 static void pci_for_each_device_under_bus(PCIBus *bus,
-                                          void (*fn)(PCIBus *b, PCIDevice *d))
+                                          void (*fn)(PCIBus *b, PCIDevice *d,
+                                                     void *opaque),
+                                          void *opaque)
 {
     PCIDevice *d;
     int devfn;
@@ -1131,18 +1133,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
     for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
         d = bus->devices[devfn];
         if (d) {
-            fn(bus, d);
+            fn(bus, d, opaque);
         }
     }
 }
 
 void pci_for_each_device(PCIBus *bus, int bus_num,
-                         void (*fn)(PCIBus *b, PCIDevice *d))
+                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
+                         void *opaque)
 {
     bus = pci_find_bus(bus, bus_num);
 
     if (bus) {
-        pci_for_each_device_under_bus(bus, fn);
+        pci_for_each_device_under_bus(bus, fn, opaque);
     }
 }
 
diff --git a/hw/pci.h b/hw/pci.h
index 4f19fdb..2827fd1 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -296,7 +296,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
 PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
                                const char *default_devaddr);
 int pci_bus_num(PCIBus *s);
-void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
+void pci_for_each_device(PCIBus *bus, int bus_num,
+                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
+                         void *opaque);
 PCIBus *pci_find_root_bus(int domain);
 int pci_find_domain(const PCIBus *bus);
 PCIBus *pci_find_bus(PCIBus *bus, int bus_num);
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 5a7c4cc..88ff5e8 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 #define UNPLUG_ALL_NICS 2
 #define UNPLUG_AUX_IDE_DISKS 4
 
-static void unplug_nic(PCIBus *b, PCIDevice *d)
+static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_NETWORK_ETHERNET) {
@@ -93,10 +93,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_nics(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_nic);
+    pci_for_each_device(bus, 0, unplug_nic, NULL);
 }
 
-static void unplug_disks(PCIBus *b, PCIDevice *d)
+static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_STORAGE_IDE) {
@@ -106,7 +106,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_disks(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_disks);
+    pci_for_each_device(bus, 0, unplug_disks, NULL);
 }
 
 static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j4-0000nY-UI; Tue, 03 Apr 2012 15:32:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j3-0000nK-Gf
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:53 +0000
Received: from [85.158.143.35:30674] by server-3.bemta-4.messagelabs.com id
	30/DD-05853-4281B7F4; Tue, 03 Apr 2012 15:32:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12806 invoked from network); 3 Apr 2012 15:32:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824552"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-4W;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:36 +0100
Message-ID: <1333467163-25795-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 1/8] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are using this in our quirk lookup provided by patch
titled: Introduce Xen PCI Passthrough, PCI config space helpers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..649e6b3 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j4-0000nY-UI; Tue, 03 Apr 2012 15:32:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j3-0000nK-Gf
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:53 +0000
Received: from [85.158.143.35:30674] by server-3.bemta-4.messagelabs.com id
	30/DD-05853-4281B7F4; Tue, 03 Apr 2012 15:32:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12806 invoked from network); 3 Apr 2012 15:32:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824552"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-4W;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:36 +0100
Message-ID: <1333467163-25795-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 1/8] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are using this in our quirk lookup provided by patch
titled: Introduce Xen PCI Passthrough, PCI config space helpers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..649e6b3 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j6-0000ny-Er; Tue, 03 Apr 2012 15:32:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j4-0000nP-FS
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:54 +0000
Received: from [85.158.143.35:21685] by server-2.bemta-4.messagelabs.com id
	74/28-17550-5281B7F4; Tue, 03 Apr 2012 15:32:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12855 invoked from network); 3 Apr 2012 15:32:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824553"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-6N;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:37 +0100
Message-ID: <1333467163-25795-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 2/8] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 4b3adc9..c84a252 100755
--- a/configure
+++ b/configure
@@ -136,6 +136,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -682,6 +683,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1034,6 +1039,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1478,6 +1485,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3643,6 +3665,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j6-0000o7-S1; Tue, 03 Apr 2012 15:32:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j4-0000nK-MV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:54 +0000
Received: from [85.158.143.35:21771] by server-3.bemta-4.messagelabs.com id
	0E/DD-05853-6281B7F4; Tue, 03 Apr 2012 15:32:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12913 invoked from network); 3 Apr 2012 15:32:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824554"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-B4;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:42 +0100
Message-ID: <1333467163-25795-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 7/8] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 31 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..6e2eb71
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,30 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 4eeaf88..a8da2f1 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define SYNC_FROM_VAPIC                 0x1
 #define SYNC_TO_VAPIC                   0x2
 #define SYNC_ISR_IRR_TO_VAPIC           0x4
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5j6-0000o7-S1; Tue, 03 Apr 2012 15:32:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5j4-0000nK-MV
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:32:54 +0000
Received: from [85.158.143.35:21771] by server-3.bemta-4.messagelabs.com id
	0E/DD-05853-6281B7F4; Tue, 03 Apr 2012 15:32:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1333467170!11815443!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12913 invoked from network); 3 Apr 2012 15:32:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23824554"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-B4;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:42 +0100
Message-ID: <1333467163-25795-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 7/8] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 31 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..6e2eb71
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,30 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 4eeaf88..a8da2f1 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define SYNC_FROM_VAPIC                 0x1
 #define SYNC_TO_VAPIC                   0x2
 #define SYNC_ISR_IRR_TO_VAPIC           0x4
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jF-0000qm-24; Tue, 03 Apr 2012 15:33:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jD-0000pr-Ox
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:04 +0000
Received: from [85.158.138.51:36454] by server-2.bemta-3.messagelabs.com id
	2D/2A-15460-E281B7F4; Tue, 03 Apr 2012 15:33:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333467179!20590125!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7034 invoked from network); 3 Apr 2012 15:33:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833697"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-8G;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:38 +0100
Message-ID: <1333467163-25795-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 3/8] Introduce XenHostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target          |    3 +
 hw/xen-host-pci-device.c |  393 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen-host-pci-device.h |   55 +++++++
 3 files changed, 451 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index cff15f0..4c4e3ad 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -237,6 +237,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
new file mode 100644
index 0000000..5c2b193
--- /dev/null
+++ b/hw/xen-host-pci-device.c
@@ -0,0 +1,393 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "xen-host-pci-device.h"
+
+#define XEN_HOST_PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+#ifdef XEN_HOST_PCI_DEVICE_DEBUG
+#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
+#else
+#  define XEN_HOST_PCI_LOG(f, a...) (void)0
+#endif
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_MEM_64       0x00100000
+
+static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
+                                   const char *name, char *buf, ssize_t size)
+{
+    int rc;
+
+    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
+                  d->domain, d->bus, d->dev, d->func, name);
+
+    if (rc >= size || rc < 0) {
+        /* The ouput is truncated or an other error is encountered */
+        return -ENODEV;
+    }
+    return 0;
+}
+
+#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 512
+static int xen_host_pci_get_resource(XenHostPCIDevice *d)
+{
+    int i, rc, fd;
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+    unsigned long long start, end, flags, size;
+    char *endptr, *s;
+    uint8_t type;
+
+    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    rc = 0;
+
+    s = buf;
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        type = 0;
+
+        start = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        end = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        flags = strtoll(s, &endptr, 16);
+        if (*endptr != '\n' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (flags & IORESOURCE_IO) {
+            type |= XEN_HOST_PCI_REGION_TYPE_IO;
+        }
+        if (flags & IORESOURCE_MEM) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
+        }
+        if (flags & IORESOURCE_PREFETCH) {
+            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
+        }
+        if (flags & IORESOURCE_MEM_64) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].type = type;
+            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.type = type;
+            d->rom.bus_flags = flags & IORESOURCE_BITS;
+        }
+    }
+    if (i != PCI_NUM_REGIONS) {
+        /* Invalid format or input to short */
+        rc = -ENODEV;
+    }
+
+out:
+    close(fd);
+    return rc;
+}
+
+#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 42
+static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
+                                  unsigned int *pvalue, int base)
+{
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
+    int fd, rc;
+    unsigned long value;
+    char *endptr;
+
+    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    value = strtol(buf, &endptr, base);
+    if (endptr == buf || *endptr != '\n') {
+        rc = -1;
+    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
+        rc = -errno;
+    } else {
+        rc = 0;
+        *pvalue = value;
+    }
+out:
+    close(fd);
+    return rc;
+}
+
+static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 16);
+}
+
+static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 10);
+}
+
+static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
+        return false;
+    }
+    return !stat(path, &buf);
+}
+
+static int xen_host_pci_config_open(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    int rc;
+
+    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    d->config_fd = open(path, O_RDWR);
+    if (d->config_fd < 0) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_read(XenHostPCIDevice *d,
+                                    int pos, void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pread(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_write(XenHostPCIDevice *d,
+                                     int pos, const void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pwrite(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
+    if (!rc) {
+        *p = buf;
+    }
+    return rc;
+}
+
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
+    if (!rc) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
+    if (!rc) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_read(d, pos, buf, len);
+}
+
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
+{
+    return xen_host_pci_config_write(d, pos, &data, 1);
+}
+
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return xen_host_pci_config_write(d, pos, &data, 2);
+}
+
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return xen_host_pci_config_write(d, pos, &data, 4);
+}
+
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_write(d, pos, buf, len);
+}
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (xen_host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return -1;
+}
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func)
+{
+    unsigned int v;
+    int rc = 0;
+
+    d->config_fd = -1;
+    d->domain = domain;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    rc = xen_host_pci_config_open(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_resource(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
+    if (rc) {
+        goto error;
+    }
+    d->vendor_id = v;
+    rc = xen_host_pci_get_hex_value(d, "device", &v);
+    if (rc) {
+        goto error;
+    }
+    d->device_id = v;
+    rc = xen_host_pci_get_dec_value(d, "irq", &v);
+    if (rc) {
+        goto error;
+    }
+    d->irq = v;
+    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+
+    return 0;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+    return rc;
+}
+
+void xen_host_pci_device_put(XenHostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+}
diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
new file mode 100644
index 0000000..0079dac
--- /dev/null
+++ b/hw/xen-host-pci-device.h
@@ -0,0 +1,55 @@
+#ifndef XEN_HOST_PCI_DEVICE_H
+#define XEN_HOST_PCI_DEVICE_H
+
+#include "pci.h"
+
+enum {
+    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
+    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
+    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
+    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
+};
+
+typedef struct XenHostPCIIORegion {
+    pcibus_t base_addr;
+    pcibus_t size;
+    uint8_t type;
+    uint8_t bus_flags; /* Bus-specific bits */
+} XenHostPCIIORegion;
+
+typedef struct XenHostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    int irq;
+
+    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    XenHostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} XenHostPCIDevice;
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func);
+void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
+
+#endif /* !XEN_HOST_PCI_DEVICE_H_ */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jF-0000qm-24; Tue, 03 Apr 2012 15:33:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jD-0000pr-Ox
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:04 +0000
Received: from [85.158.138.51:36454] by server-2.bemta-3.messagelabs.com id
	2D/2A-15460-E281B7F4; Tue, 03 Apr 2012 15:33:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333467179!20590125!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7034 invoked from network); 3 Apr 2012 15:33:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833697"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-8G;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:38 +0100
Message-ID: <1333467163-25795-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 3/8] Introduce XenHostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target          |    3 +
 hw/xen-host-pci-device.c |  393 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen-host-pci-device.h |   55 +++++++
 3 files changed, 451 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index cff15f0..4c4e3ad 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -237,6 +237,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
new file mode 100644
index 0000000..5c2b193
--- /dev/null
+++ b/hw/xen-host-pci-device.c
@@ -0,0 +1,393 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "xen-host-pci-device.h"
+
+#define XEN_HOST_PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+#ifdef XEN_HOST_PCI_DEVICE_DEBUG
+#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
+#else
+#  define XEN_HOST_PCI_LOG(f, a...) (void)0
+#endif
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_MEM_64       0x00100000
+
+static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
+                                   const char *name, char *buf, ssize_t size)
+{
+    int rc;
+
+    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
+                  d->domain, d->bus, d->dev, d->func, name);
+
+    if (rc >= size || rc < 0) {
+        /* The ouput is truncated or an other error is encountered */
+        return -ENODEV;
+    }
+    return 0;
+}
+
+#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 512
+static int xen_host_pci_get_resource(XenHostPCIDevice *d)
+{
+    int i, rc, fd;
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+    unsigned long long start, end, flags, size;
+    char *endptr, *s;
+    uint8_t type;
+
+    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    rc = 0;
+
+    s = buf;
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        type = 0;
+
+        start = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        end = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        flags = strtoll(s, &endptr, 16);
+        if (*endptr != '\n' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (flags & IORESOURCE_IO) {
+            type |= XEN_HOST_PCI_REGION_TYPE_IO;
+        }
+        if (flags & IORESOURCE_MEM) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
+        }
+        if (flags & IORESOURCE_PREFETCH) {
+            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
+        }
+        if (flags & IORESOURCE_MEM_64) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].type = type;
+            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.type = type;
+            d->rom.bus_flags = flags & IORESOURCE_BITS;
+        }
+    }
+    if (i != PCI_NUM_REGIONS) {
+        /* Invalid format or input to short */
+        rc = -ENODEV;
+    }
+
+out:
+    close(fd);
+    return rc;
+}
+
+#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 42
+static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
+                                  unsigned int *pvalue, int base)
+{
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
+    int fd, rc;
+    unsigned long value;
+    char *endptr;
+
+    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    value = strtol(buf, &endptr, base);
+    if (endptr == buf || *endptr != '\n') {
+        rc = -1;
+    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
+        rc = -errno;
+    } else {
+        rc = 0;
+        *pvalue = value;
+    }
+out:
+    close(fd);
+    return rc;
+}
+
+static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 16);
+}
+
+static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 10);
+}
+
+static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
+        return false;
+    }
+    return !stat(path, &buf);
+}
+
+static int xen_host_pci_config_open(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    int rc;
+
+    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    d->config_fd = open(path, O_RDWR);
+    if (d->config_fd < 0) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_read(XenHostPCIDevice *d,
+                                    int pos, void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pread(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_write(XenHostPCIDevice *d,
+                                     int pos, const void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pwrite(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
+    if (!rc) {
+        *p = buf;
+    }
+    return rc;
+}
+
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
+    if (!rc) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
+    if (!rc) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_read(d, pos, buf, len);
+}
+
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
+{
+    return xen_host_pci_config_write(d, pos, &data, 1);
+}
+
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return xen_host_pci_config_write(d, pos, &data, 2);
+}
+
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return xen_host_pci_config_write(d, pos, &data, 4);
+}
+
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_write(d, pos, buf, len);
+}
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (xen_host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return -1;
+}
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func)
+{
+    unsigned int v;
+    int rc = 0;
+
+    d->config_fd = -1;
+    d->domain = domain;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    rc = xen_host_pci_config_open(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_resource(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
+    if (rc) {
+        goto error;
+    }
+    d->vendor_id = v;
+    rc = xen_host_pci_get_hex_value(d, "device", &v);
+    if (rc) {
+        goto error;
+    }
+    d->device_id = v;
+    rc = xen_host_pci_get_dec_value(d, "irq", &v);
+    if (rc) {
+        goto error;
+    }
+    d->irq = v;
+    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+
+    return 0;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+    return rc;
+}
+
+void xen_host_pci_device_put(XenHostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+}
diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
new file mode 100644
index 0000000..0079dac
--- /dev/null
+++ b/hw/xen-host-pci-device.h
@@ -0,0 +1,55 @@
+#ifndef XEN_HOST_PCI_DEVICE_H
+#define XEN_HOST_PCI_DEVICE_H
+
+#include "pci.h"
+
+enum {
+    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
+    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
+    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
+    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
+};
+
+typedef struct XenHostPCIIORegion {
+    pcibus_t base_addr;
+    pcibus_t size;
+    uint8_t type;
+    uint8_t bus_flags; /* Bus-specific bits */
+} XenHostPCIIORegion;
+
+typedef struct XenHostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    int irq;
+
+    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    XenHostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} XenHostPCIDevice;
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func);
+void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
+
+#endif /* !XEN_HOST_PCI_DEVICE_H_ */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jJ-0000tS-Bw; Tue, 03 Apr 2012 15:33:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jH-0000sH-VU
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:08 +0000
Received: from [85.158.138.51:36803] by server-11.bemta-3.messagelabs.com id
	6F/D2-28543-3381B7F4; Tue, 03 Apr 2012 15:33:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333467179!20590125!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7230 invoked from network); 3 Apr 2012 15:33:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833699"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-9V;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:40 +0100
Message-ID: <1333467163-25795-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 5/8] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 Makefile.target         |    2 +
 hw/xen_common.h         |    3 +
 hw/xen_pt.c             |  815 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt.h             |  248 ++++++++++++++
 hw/xen_pt_config_init.c |   11 +
 xen-all.c               |   12 +
 6 files changed, 1091 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 4c4e3ad..413198d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -239,6 +239,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
new file mode 100644
index 0000000..afa985a
--- /dev/null
+++ b/hw/xen_pt.c
@@ -0,0 +1,815 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement xen_pt_mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(xen_pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "range.h"
+
+#define XEN_PT_NR_IRQS (256)
+static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int xen_pt_pci_config_access_check(PCIDevice *d, uint32_t addr, int len)
+{
+    /* check offset range */
+    if (addr >= 0xFF) {
+        XEN_PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access length. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (addr & (len - 1)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access size "
+                   "alignment. (addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xen_pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t xen_pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = xen_host_pci_get_block(&s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void xen_pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                    uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = xen_pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < XEN_PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED)) {
+        XEN_PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                    "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            XEN_PT_WARN(d, "Access to 0-Hardwired register. "
+                        "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = xen_host_pci_get_block(&s->real_device, addr,
+                                (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to xen_host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = xen_host_pci_set_block(&s->real_device, addr,
+                                    (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            XEN_PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t xen_pt_bar_read(void *o, target_phys_addr_t addr,
+                                unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    XEN_PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+    return 0;
+}
+static void xen_pt_bar_write(void *o, target_phys_addr_t addr, uint64_t val,
+                             unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as xen_pt_bar_read function */
+    XEN_PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = xen_pt_bar_read,
+    .write = xen_pt_bar_write,
+};
+
+static int xen_pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    XenHostPCIDevice *d = &s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+            }
+        }
+
+        memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                              "xen-pci-pt-bar", r->size);
+        pci_register_bar(&s->dev, i, type, &s->bar[i]);
+
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64" type: %#x)\n",
+                   i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (xen_host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            xen_host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        XEN_PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    XenHostPCIDevice *d = &s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int xen_pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+/*
+ * This function checks if an io_region overlaps an io_region from another
+ * device.  The io_region to check is provided with (addr, size and type)
+ * A callback can be provided and will be called for every region that is
+ * overlapped.
+ * The return value indicates if the region is overlappsed */
+struct CheckBarArgs {
+    XenPCIPassthroughState *s;
+    pcibus_t addr;
+    pcibus_t size;
+    uint8_t type;
+    bool rc;
+};
+static void xen_pt_check_bar_overlap(PCIBus *bus, PCIDevice *d, void *opaque)
+{
+    struct CheckBarArgs *arg = opaque;
+    XenPCIPassthroughState *s = arg->s;
+    uint8_t type = arg->type;
+    int i;
+
+    if (d->devfn == s->dev.devfn) {
+        return;
+    }
+
+    /* xxx: This ignores bridges. */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        const PCIIORegion *r = &d->io_regions[i];
+
+        if (!r->size) {
+            continue;
+        }
+        if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+            != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+            continue;
+        }
+
+        if (ranges_overlap(arg->addr, arg->size, r->addr, r->size)) {
+            XEN_PT_WARN(&s->dev,
+                        "Overlapped to device [%02x:%02x.%x] Region: %i"
+                        " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+                        pci_bus_num(bus), PCI_SLOT(d->devfn),
+                        PCI_FUNC(d->devfn), i, r->addr, r->size);
+            arg->rc = true;
+        }
+    }
+}
+
+static void xen_pt_region_update(XenPCIPassthroughState *s,
+                                 MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+    struct CheckBarArgs args = {
+        .s = s,
+        .addr = sec->offset_within_address_space,
+        .size = sec->size,
+        .rc = false,
+    };
+
+    bar = xen_pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    args.type = d->io_regions[bar].type;
+    pci_for_each_device(d->bus, pci_bus_num(d->bus),
+                        xen_pt_check_bar_overlap, &args);
+    if (args.rc) {
+        XEN_PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                    ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                    bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      XEN_PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(size + XC_PAGE_SIZE - 1),
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void xen_pt_begin(MemoryListener *l)
+{
+}
+
+static void xen_pt_commit(MemoryListener *l)
+{
+}
+
+static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, true);
+}
+
+static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, false);
+}
+
+static void xen_pt_region_nop(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_fns(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_global_fns(MemoryListener *l)
+{
+}
+
+static void xen_pt_eventfd_fns(MemoryListener *l, MemoryRegionSection *s,
+                               bool match_data, uint64_t data, int fd)
+{
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .begin = xen_pt_begin,
+    .commit = xen_pt_commit,
+    .region_add = xen_pt_region_add,
+    .region_nop = xen_pt_region_nop,
+    .region_del = xen_pt_region_del,
+    .log_start = xen_pt_log_fns,
+    .log_stop = xen_pt_log_fns,
+    .log_sync = xen_pt_log_fns,
+    .log_global_start = xen_pt_log_global_fns,
+    .log_global_stop = xen_pt_log_global_fns,
+    .eventfd_add = xen_pt_eventfd_fns,
+    .eventfd_del = xen_pt_eventfd_fns,
+    .priority = 10,
+};
+
+/* init */
+
+static int xen_pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        XEN_PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    XEN_PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+               " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    rc = xen_host_pci_device_get(&s->real_device, dom, bus, slot, func);
+    if (rc) {
+        XEN_PT_ERR(d, "Failed to \"open\" the real pci device. rc: %i\n", rc);
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device.is_virtfn;
+    if (s->is_virtfn) {
+        XEN_PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+                   s->real_device.domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (xen_host_pci_get_block(&s->real_device, 0, d->config,
+                               PCI_CONFIG_SPACE_SIZE) == -1) {
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    xen_pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        XEN_PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    machine_irq = s->real_device.irq;
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+                   machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        xen_host_pci_set_word(&s->real_device,
+                              PCI_COMMAND,
+                              pci_get_word(s->dev.config + PCI_COMMAND)
+                              | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        xen_pt_mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = xen_pt_pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                       e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
+                                  *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                                  | PCI_COMMAND_INTX_DISABLE);
+            xen_pt_mapped_machine_irq[machine_irq]--;
+
+            if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                               " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener, NULL);
+    XEN_PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+               bus, slot, func);
+
+    return 0;
+}
+
+static int xen_pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = xen_pt_pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
+                       " (machine irq: %i, rc: %d)"
+                       " But bravely continuing on..\n",
+                       'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        xen_pt_mapped_machine_irq[machine_irq]--;
+
+        if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                XEN_PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                           " But bravely continuing on..\n",
+                           machine_irq, rc);
+            }
+        }
+    }
+
+    xen_pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    xen_host_pci_device_put(&s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_pt_initfn;
+    k->exit = xen_pt_unregister_device;
+    k->config_read = xen_pt_pci_read_config;
+    k->config_write = xen_pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
new file mode 100644
index 0000000..f029841
--- /dev/null
+++ b/hw/xen_pt.h
@@ -0,0 +1,248 @@
+#ifndef XEN_PT_H
+#define XEN_PT_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "xen-host-pci-device.h"
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
+
+#ifdef XEN_PT_LOGGING_ENABLED
+#  define XEN_PT_LOG(d, _f, _a...)  xen_pt_log(d, "%s: " _f, __func__, ##_a)
+#  define XEN_PT_WARN(d, _f, _a...) \
+    xen_pt_log(d, "%s: Warning: "_f, __func__, ##_a)
+#else
+#  define XEN_PT_LOG(d, _f, _a...)
+#  define XEN_PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef XEN_PT_DEBUG_PCI_CONFIG_ACCESS
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len) \
+    xen_pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+               __func__, addr, val, len)
+#else
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define XEN_PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*xen_pt_conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*xen_pt_conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*xen_pt_conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define XEN_PT_BAR_ALLF 0xFFFFFFFF
+#define XEN_PT_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
+    XEN_PT_GRP_TYPE_EMU,            /* emul reg group */
+} XenPTRegisterGroupType;
+
+typedef enum {
+    XEN_PT_BAR_FLAG_MEM = 0,        /* Memory type BAR */
+    XEN_PT_BAR_FLAG_IO,             /* I/O type BAR */
+    XEN_PT_BAR_FLAG_UPPER,          /* upper 64bit BAR */
+    XEN_PT_BAR_FLAG_UNUSED,         /* unused BAR */
+} XenPTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    XenPTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    xen_pt_conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            xen_pt_conf_dword_write write;
+            xen_pt_conf_dword_read read;
+        } dw;
+        struct {
+            xen_pt_conf_word_write write;
+            xen_pt_conf_word_read read;
+        } w;
+        struct {
+            xen_pt_conf_byte_write write;
+            xen_pt_conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*xen_pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    XenPTRegisterGroupType grp_type;
+    uint8_t grp_size;
+    xen_pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_regs;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define XEN_PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    XenHostPCIDevice real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grps;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int xen_pt_config_init(XenPCIPassthroughState *s);
+void xen_pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int xen_pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t xen_pt_get_emul_size(XenPTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == XEN_PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, xen_pt_pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t xen_pt_pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    xen_host_pci_get_byte(&s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = xen_pt_pci_read_intx(s);
+
+    XEN_PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        XEN_PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+                   " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
new file mode 100644
index 0000000..64d22e8
--- /dev/null
+++ b/hw/xen_pt_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pt.h"
+
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..e9daf8e 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1145,3 +1145,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jJ-0000tS-Bw; Tue, 03 Apr 2012 15:33:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jH-0000sH-VU
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:08 +0000
Received: from [85.158.138.51:36803] by server-11.bemta-3.messagelabs.com id
	6F/D2-28543-3381B7F4; Tue, 03 Apr 2012 15:33:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333467179!20590125!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7230 invoked from network); 3 Apr 2012 15:33:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833699"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-9V;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:40 +0100
Message-ID: <1333467163-25795-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 5/8] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 Makefile.target         |    2 +
 hw/xen_common.h         |    3 +
 hw/xen_pt.c             |  815 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt.h             |  248 ++++++++++++++
 hw/xen_pt_config_init.c |   11 +
 xen-all.c               |   12 +
 6 files changed, 1091 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 4c4e3ad..413198d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -239,6 +239,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
new file mode 100644
index 0000000..afa985a
--- /dev/null
+++ b/hw/xen_pt.c
@@ -0,0 +1,815 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement xen_pt_mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(xen_pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "range.h"
+
+#define XEN_PT_NR_IRQS (256)
+static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int xen_pt_pci_config_access_check(PCIDevice *d, uint32_t addr, int len)
+{
+    /* check offset range */
+    if (addr >= 0xFF) {
+        XEN_PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access length. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (addr & (len - 1)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access size "
+                   "alignment. (addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xen_pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t xen_pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = xen_host_pci_get_block(&s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void xen_pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                    uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = xen_pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < XEN_PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED)) {
+        XEN_PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                    "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            XEN_PT_WARN(d, "Access to 0-Hardwired register. "
+                        "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = xen_host_pci_get_block(&s->real_device, addr,
+                                (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to xen_host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = xen_host_pci_set_block(&s->real_device, addr,
+                                    (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            XEN_PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t xen_pt_bar_read(void *o, target_phys_addr_t addr,
+                                unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    XEN_PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+    return 0;
+}
+static void xen_pt_bar_write(void *o, target_phys_addr_t addr, uint64_t val,
+                             unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as xen_pt_bar_read function */
+    XEN_PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = xen_pt_bar_read,
+    .write = xen_pt_bar_write,
+};
+
+static int xen_pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    XenHostPCIDevice *d = &s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+            }
+        }
+
+        memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                              "xen-pci-pt-bar", r->size);
+        pci_register_bar(&s->dev, i, type, &s->bar[i]);
+
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64" type: %#x)\n",
+                   i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (xen_host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            xen_host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        XEN_PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    XenHostPCIDevice *d = &s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int xen_pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+/*
+ * This function checks if an io_region overlaps an io_region from another
+ * device.  The io_region to check is provided with (addr, size and type)
+ * A callback can be provided and will be called for every region that is
+ * overlapped.
+ * The return value indicates if the region is overlappsed */
+struct CheckBarArgs {
+    XenPCIPassthroughState *s;
+    pcibus_t addr;
+    pcibus_t size;
+    uint8_t type;
+    bool rc;
+};
+static void xen_pt_check_bar_overlap(PCIBus *bus, PCIDevice *d, void *opaque)
+{
+    struct CheckBarArgs *arg = opaque;
+    XenPCIPassthroughState *s = arg->s;
+    uint8_t type = arg->type;
+    int i;
+
+    if (d->devfn == s->dev.devfn) {
+        return;
+    }
+
+    /* xxx: This ignores bridges. */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        const PCIIORegion *r = &d->io_regions[i];
+
+        if (!r->size) {
+            continue;
+        }
+        if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+            != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+            continue;
+        }
+
+        if (ranges_overlap(arg->addr, arg->size, r->addr, r->size)) {
+            XEN_PT_WARN(&s->dev,
+                        "Overlapped to device [%02x:%02x.%x] Region: %i"
+                        " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+                        pci_bus_num(bus), PCI_SLOT(d->devfn),
+                        PCI_FUNC(d->devfn), i, r->addr, r->size);
+            arg->rc = true;
+        }
+    }
+}
+
+static void xen_pt_region_update(XenPCIPassthroughState *s,
+                                 MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+    struct CheckBarArgs args = {
+        .s = s,
+        .addr = sec->offset_within_address_space,
+        .size = sec->size,
+        .rc = false,
+    };
+
+    bar = xen_pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    args.type = d->io_regions[bar].type;
+    pci_for_each_device(d->bus, pci_bus_num(d->bus),
+                        xen_pt_check_bar_overlap, &args);
+    if (args.rc) {
+        XEN_PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                    ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                    bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      XEN_PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(size + XC_PAGE_SIZE - 1),
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void xen_pt_begin(MemoryListener *l)
+{
+}
+
+static void xen_pt_commit(MemoryListener *l)
+{
+}
+
+static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, true);
+}
+
+static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, false);
+}
+
+static void xen_pt_region_nop(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_fns(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_global_fns(MemoryListener *l)
+{
+}
+
+static void xen_pt_eventfd_fns(MemoryListener *l, MemoryRegionSection *s,
+                               bool match_data, uint64_t data, int fd)
+{
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .begin = xen_pt_begin,
+    .commit = xen_pt_commit,
+    .region_add = xen_pt_region_add,
+    .region_nop = xen_pt_region_nop,
+    .region_del = xen_pt_region_del,
+    .log_start = xen_pt_log_fns,
+    .log_stop = xen_pt_log_fns,
+    .log_sync = xen_pt_log_fns,
+    .log_global_start = xen_pt_log_global_fns,
+    .log_global_stop = xen_pt_log_global_fns,
+    .eventfd_add = xen_pt_eventfd_fns,
+    .eventfd_del = xen_pt_eventfd_fns,
+    .priority = 10,
+};
+
+/* init */
+
+static int xen_pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        XEN_PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    XEN_PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+               " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    rc = xen_host_pci_device_get(&s->real_device, dom, bus, slot, func);
+    if (rc) {
+        XEN_PT_ERR(d, "Failed to \"open\" the real pci device. rc: %i\n", rc);
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device.is_virtfn;
+    if (s->is_virtfn) {
+        XEN_PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+                   s->real_device.domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (xen_host_pci_get_block(&s->real_device, 0, d->config,
+                               PCI_CONFIG_SPACE_SIZE) == -1) {
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    xen_pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        XEN_PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    machine_irq = s->real_device.irq;
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+                   machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        xen_host_pci_set_word(&s->real_device,
+                              PCI_COMMAND,
+                              pci_get_word(s->dev.config + PCI_COMMAND)
+                              | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        xen_pt_mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = xen_pt_pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                       e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
+                                  *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                                  | PCI_COMMAND_INTX_DISABLE);
+            xen_pt_mapped_machine_irq[machine_irq]--;
+
+            if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                               " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener, NULL);
+    XEN_PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+               bus, slot, func);
+
+    return 0;
+}
+
+static int xen_pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = xen_pt_pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
+                       " (machine irq: %i, rc: %d)"
+                       " But bravely continuing on..\n",
+                       'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        xen_pt_mapped_machine_irq[machine_irq]--;
+
+        if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                XEN_PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                           " But bravely continuing on..\n",
+                           machine_irq, rc);
+            }
+        }
+    }
+
+    xen_pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    xen_host_pci_device_put(&s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_pt_initfn;
+    k->exit = xen_pt_unregister_device;
+    k->config_read = xen_pt_pci_read_config;
+    k->config_write = xen_pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
new file mode 100644
index 0000000..f029841
--- /dev/null
+++ b/hw/xen_pt.h
@@ -0,0 +1,248 @@
+#ifndef XEN_PT_H
+#define XEN_PT_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "xen-host-pci-device.h"
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
+
+#ifdef XEN_PT_LOGGING_ENABLED
+#  define XEN_PT_LOG(d, _f, _a...)  xen_pt_log(d, "%s: " _f, __func__, ##_a)
+#  define XEN_PT_WARN(d, _f, _a...) \
+    xen_pt_log(d, "%s: Warning: "_f, __func__, ##_a)
+#else
+#  define XEN_PT_LOG(d, _f, _a...)
+#  define XEN_PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef XEN_PT_DEBUG_PCI_CONFIG_ACCESS
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len) \
+    xen_pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+               __func__, addr, val, len)
+#else
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define XEN_PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*xen_pt_conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*xen_pt_conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*xen_pt_conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define XEN_PT_BAR_ALLF 0xFFFFFFFF
+#define XEN_PT_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
+    XEN_PT_GRP_TYPE_EMU,            /* emul reg group */
+} XenPTRegisterGroupType;
+
+typedef enum {
+    XEN_PT_BAR_FLAG_MEM = 0,        /* Memory type BAR */
+    XEN_PT_BAR_FLAG_IO,             /* I/O type BAR */
+    XEN_PT_BAR_FLAG_UPPER,          /* upper 64bit BAR */
+    XEN_PT_BAR_FLAG_UNUSED,         /* unused BAR */
+} XenPTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    XenPTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    xen_pt_conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            xen_pt_conf_dword_write write;
+            xen_pt_conf_dword_read read;
+        } dw;
+        struct {
+            xen_pt_conf_word_write write;
+            xen_pt_conf_word_read read;
+        } w;
+        struct {
+            xen_pt_conf_byte_write write;
+            xen_pt_conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*xen_pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    XenPTRegisterGroupType grp_type;
+    uint8_t grp_size;
+    xen_pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_regs;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define XEN_PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    XenHostPCIDevice real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grps;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int xen_pt_config_init(XenPCIPassthroughState *s);
+void xen_pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int xen_pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t xen_pt_get_emul_size(XenPTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == XEN_PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, xen_pt_pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t xen_pt_pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    xen_host_pci_get_byte(&s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = xen_pt_pci_read_intx(s);
+
+    XEN_PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        XEN_PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+                   " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
new file mode 100644
index 0000000..64d22e8
--- /dev/null
+++ b/hw/xen_pt_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pt.h"
+
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..e9daf8e 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1145,3 +1145,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jH-0000sT-NH; Tue, 03 Apr 2012 15:33:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jF-0000qu-NN
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:06 +0000
Received: from [85.158.138.51:36621] by server-6.bemta-3.messagelabs.com id
	D3/88-08206-0381B7F4; Tue, 03 Apr 2012 15:33:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333467179!20590125!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7148 invoked from network); 3 Apr 2012 15:33:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833703"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-Bh;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:43 +0100
Message-ID: <1333467163-25795-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 8/8] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 Makefile.target         |    1 +
 hw/xen_pt.c             |   31 +++-
 hw/xen_pt.h             |   51 ++++
 hw/xen_pt_config_init.c |  471 +++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c         |  620 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 1173 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_pt_msi.c

diff --git a/Makefile.target b/Makefile.target
index 413198d..1903b92 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -241,6 +241,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index c2e211a..f677919 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(xen_pt_msi_setup, xen_pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(xen_pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -534,7 +548,15 @@ static void xen_pt_region_update(XenPCIPassthroughState *s,
     };
 
     bar = xen_pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = xen_pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -767,6 +789,13 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        xen_pt_msi_disable(s);
+    }
+    if (s->msix) {
+        xen_pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         xen_pt_mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 4bb8cb6..6b59564 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -160,6 +160,36 @@ typedef struct XenPTRegGroup {
 
 
 #define XEN_PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -172,6 +202,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -247,4 +280,22 @@ static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int xen_pt_msi_setup(XenPCIPassthroughState *s);
+int xen_pt_msi_update(XenPCIPassthroughState *d);
+void xen_pt_msi_disable(XenPCIPassthroughState *s);
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void xen_pt_msix_delete(XenPCIPassthroughState *s);
+int xen_pt_msix_update(XenPCIPassthroughState *s);
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void xen_pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 1d97876..00eb3d9 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1022,6 +1022,410 @@ static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool xen_pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int xen_pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        XEN_PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msgctrl_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t raw_val;
+
+    /* Currently no support for multi-vector */
+    if (*val & PCI_MSI_FLAGS_QSIZE) {
+        XEN_PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *val);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    raw_val = *val;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (raw_val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            XEN_PT_LOG(&s->dev, "setup MSI\n");
+            if (xen_pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (xen_pt_msi_update(s)) {
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *val &= ~PCI_MSI_FLAGS_ENABLE;
+    *val |= raw_val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int xen_pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = XEN_PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int xen_pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (xen_pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = XEN_PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int xen_pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int xen_pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        XEN_PT_ERR(&s->dev,
+                   "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!xen_pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        XEN_PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msi[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = xen_pt_msgctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgaddr64_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int xen_pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        XEN_PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                     XenPTReg *cfg_entry, uint16_t *val,
+                                     uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*val & PCI_MSIX_FLAGS_ENABLE)
+        && !(*val & PCI_MSIX_FLAGS_MASKALL)) {
+        xen_pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        XEN_PT_LOG(&s->dev, "%s MSI-X\n",
+                   s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msix[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = xen_pt_msixctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1115,6 +1519,49 @@ static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int xen_pt_msi_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int xen_pt_msix_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = xen_pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid xen_pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
     /* Header Type0 reg group */
@@ -1155,6 +1602,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .grp_size   = 0x04,
         .size_init  = xen_pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_msi_size_init,
+        .emu_regs = xen_pt_emu_reg_msi,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1199,6 +1654,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_pcie_size_init,
         .emu_regs = xen_pt_emu_reg_pcie,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = xen_pt_msix_size_init,
+        .emu_regs = xen_pt_emu_reg_msix,
+    },
     {
         .grp_size = 0,
     },
@@ -1384,6 +1847,14 @@ void xen_pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        xen_pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pt_msi.c b/hw/xen_pt_msi.c
new file mode 100644
index 0000000..2299cc7
--- /dev/null
+++ b/hw/xen_pt_msi.c
@@ -0,0 +1,620 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "apic-msidef.h"
+
+
+#define XEN_PT_AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define XEN_PT_GFLAGS_SHIFT_DEST_ID        0
+#define XEN_PT_GFLAGS_SHIFT_RH             8
+#define XEN_PT_GFLAGS_SHIFT_DM             9
+#define XEN_PT_GFLAGSSHIFT_DELIV_MODE     12
+#define XEN_PT_GFLAGSSHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
+        | (dm << XEN_PT_GFLAGS_SHIFT_DM)
+        | (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
+        | (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    xen_host_pci_get_word(&s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    xen_host_pci_set_word(&s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                          uint64_t addr,
+                          uint32_t data,
+                          int *ppirq,
+                          bool is_msix,
+                          int msix_entry,
+                          bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = XEN_PT_UNASSIGNED_PIRQ;
+        } else {
+            XEN_PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                       " (vec: %#x, entry: %#x)\n",
+                       *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, XEN_PT_AUTO_ASSIGN,
+                                     ppirq, PCI_DEVFN(s->real_device.dev,
+                                                      s->real_device.func),
+                                     s->real_device.bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            XEN_PT_ERR(&s->dev,
+                       "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                       is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
+               " (entry: %#x)\n",
+               is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        XEN_PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+                   is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                       is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            XEN_PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                       is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    XEN_PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+                   is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int xen_pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        XEN_PT_ERR(&s->dev,
+                   "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        XEN_PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    XEN_PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int xen_pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void xen_pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    xen_pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int xen_pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        xen_pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void xen_pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = XEN_PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != XEN_PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n",
+                           entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return xen_pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
+                       " already enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            xen_pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    XenHostPCIDevice *hd = &s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = xen_host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        XEN_PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device.io_regions[bar_index].base_addr;
+    XEN_PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    XEN_PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+               table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    XEN_PT_LOG(d, "mapping physical MSI-X table to %p\n",
+               msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void xen_pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        XEN_PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+                   msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jH-0000sT-NH; Tue, 03 Apr 2012 15:33:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jF-0000qu-NN
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:06 +0000
Received: from [85.158.138.51:36621] by server-6.bemta-3.messagelabs.com id
	D3/88-08206-0381B7F4; Tue, 03 Apr 2012 15:33:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333467179!20590125!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7148 invoked from network); 3 Apr 2012 15:33:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833703"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-Bh;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:43 +0100
Message-ID: <1333467163-25795-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 8/8] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 Makefile.target         |    1 +
 hw/xen_pt.c             |   31 +++-
 hw/xen_pt.h             |   51 ++++
 hw/xen_pt_config_init.c |  471 +++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c         |  620 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 1173 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_pt_msi.c

diff --git a/Makefile.target b/Makefile.target
index 413198d..1903b92 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -241,6 +241,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index c2e211a..f677919 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(xen_pt_msi_setup, xen_pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(xen_pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -534,7 +548,15 @@ static void xen_pt_region_update(XenPCIPassthroughState *s,
     };
 
     bar = xen_pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = xen_pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -767,6 +789,13 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        xen_pt_msi_disable(s);
+    }
+    if (s->msix) {
+        xen_pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         xen_pt_mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 4bb8cb6..6b59564 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -160,6 +160,36 @@ typedef struct XenPTRegGroup {
 
 
 #define XEN_PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -172,6 +202,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -247,4 +280,22 @@ static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int xen_pt_msi_setup(XenPCIPassthroughState *s);
+int xen_pt_msi_update(XenPCIPassthroughState *d);
+void xen_pt_msi_disable(XenPCIPassthroughState *s);
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void xen_pt_msix_delete(XenPCIPassthroughState *s);
+int xen_pt_msix_update(XenPCIPassthroughState *s);
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void xen_pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 1d97876..00eb3d9 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1022,6 +1022,410 @@ static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool xen_pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int xen_pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        XEN_PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msgctrl_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t raw_val;
+
+    /* Currently no support for multi-vector */
+    if (*val & PCI_MSI_FLAGS_QSIZE) {
+        XEN_PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *val);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    raw_val = *val;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (raw_val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            XEN_PT_LOG(&s->dev, "setup MSI\n");
+            if (xen_pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (xen_pt_msi_update(s)) {
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *val &= ~PCI_MSI_FLAGS_ENABLE;
+    *val |= raw_val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int xen_pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = XEN_PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int xen_pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (xen_pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = XEN_PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int xen_pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int xen_pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        XEN_PT_ERR(&s->dev,
+                   "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!xen_pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        XEN_PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msi[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = xen_pt_msgctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgaddr64_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int xen_pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        XEN_PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                     XenPTReg *cfg_entry, uint16_t *val,
+                                     uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*val & PCI_MSIX_FLAGS_ENABLE)
+        && !(*val & PCI_MSIX_FLAGS_MASKALL)) {
+        xen_pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        XEN_PT_LOG(&s->dev, "%s MSI-X\n",
+                   s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msix[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = xen_pt_msixctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1115,6 +1519,49 @@ static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int xen_pt_msi_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int xen_pt_msix_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = xen_pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid xen_pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
     /* Header Type0 reg group */
@@ -1155,6 +1602,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .grp_size   = 0x04,
         .size_init  = xen_pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_msi_size_init,
+        .emu_regs = xen_pt_emu_reg_msi,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1199,6 +1654,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_pcie_size_init,
         .emu_regs = xen_pt_emu_reg_pcie,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = xen_pt_msix_size_init,
+        .emu_regs = xen_pt_emu_reg_msix,
+    },
     {
         .grp_size = 0,
     },
@@ -1384,6 +1847,14 @@ void xen_pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        xen_pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pt_msi.c b/hw/xen_pt_msi.c
new file mode 100644
index 0000000..2299cc7
--- /dev/null
+++ b/hw/xen_pt_msi.c
@@ -0,0 +1,620 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "apic-msidef.h"
+
+
+#define XEN_PT_AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define XEN_PT_GFLAGS_SHIFT_DEST_ID        0
+#define XEN_PT_GFLAGS_SHIFT_RH             8
+#define XEN_PT_GFLAGS_SHIFT_DM             9
+#define XEN_PT_GFLAGSSHIFT_DELIV_MODE     12
+#define XEN_PT_GFLAGSSHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
+        | (dm << XEN_PT_GFLAGS_SHIFT_DM)
+        | (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
+        | (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    xen_host_pci_get_word(&s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    xen_host_pci_set_word(&s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                          uint64_t addr,
+                          uint32_t data,
+                          int *ppirq,
+                          bool is_msix,
+                          int msix_entry,
+                          bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = XEN_PT_UNASSIGNED_PIRQ;
+        } else {
+            XEN_PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                       " (vec: %#x, entry: %#x)\n",
+                       *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, XEN_PT_AUTO_ASSIGN,
+                                     ppirq, PCI_DEVFN(s->real_device.dev,
+                                                      s->real_device.func),
+                                     s->real_device.bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            XEN_PT_ERR(&s->dev,
+                       "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                       is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
+               " (entry: %#x)\n",
+               is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        XEN_PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+                   is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                       is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            XEN_PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                       is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    XEN_PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+                   is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int xen_pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        XEN_PT_ERR(&s->dev,
+                   "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        XEN_PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    XEN_PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int xen_pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void xen_pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    xen_pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int xen_pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        xen_pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void xen_pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = XEN_PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != XEN_PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n",
+                           entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return xen_pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
+                       " already enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            xen_pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    XenHostPCIDevice *hd = &s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = xen_host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        XEN_PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device.io_regions[bar_index].base_addr;
+    XEN_PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    XEN_PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+               table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    XEN_PT_LOG(d, "mapping physical MSI-X table to %p\n",
+               msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void xen_pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        XEN_PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+                   msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jM-0000x2-VG; Tue, 03 Apr 2012 15:33:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jL-0000vQ-CH
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:11 +0000
Received: from [85.158.143.99:63594] by server-3.bemta-4.messagelabs.com id
	44/5E-05853-6381B7F4; Tue, 03 Apr 2012 15:33:10 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333467186!16444217!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28890 invoked from network); 3 Apr 2012 15:33:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833701"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-AL;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:41 +0100
Message-ID: <1333467163-25795-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 6/8] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_pt.c             |   10 +
 hw/xen_pt.h             |    2 +
 hw/xen_pt_config_init.c | 1387 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1399 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index afa985a..c2e211a 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -676,6 +676,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (xen_pt_config_init(s)) {
+        XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         XEN_PT_LOG(d, "no pin interrupt\n");
@@ -774,6 +781,9 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    xen_pt_config_delete(s);
+
     xen_pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index f029841..4bb8cb6 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -62,6 +62,8 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_ALLF 0xFFFFFFFF
 #define XEN_PT_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 64d22e8..1d97876 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1,11 +1,1398 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pt.h"
 
+#define XEN_PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define XEN_PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int xen_pt_hide_dev_cap(const XenHostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * xen_pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_SFP_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grps, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int xen_pt_common_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int xen_pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+
+/* Write register functions */
+
+static int xen_pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint8_t *val, uint8_t dev_value,
+                                 uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *val, uint16_t dev_value,
+                                 uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint32_t *val, uint32_t dev_value,
+                                 uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int xen_pt_vendor_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.vendor_id;
+    return 0;
+}
+static int xen_pt_device_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.device_id;
+    return 0;
+}
+static int xen_pt_status_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = xen_pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                       XenPTRegInfo *reg, uint32_t real_offset,
+                                       uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int xen_pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = xen_pt_pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int xen_pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *val, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*val & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define XEN_PT_BAR_MEM_RO_MASK    0x0000000F  /* BAR ReadOnly mask(Memory) */
+#define XEN_PT_BAR_MEM_EMU_MASK   0xFFFFFFF0  /* BAR emul mask(Memory) */
+#define XEN_PT_BAR_IO_RO_MASK     0x00000003  /* BAR ReadOnly mask(I/O) */
+#define XEN_PT_BAR_IO_EMU_MASK    0xFFFFFFFC  /* BAR emul mask(I/O) */
+
+static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
+                                         XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int type = s->real_device.io_regions[index - 1].type;
+
+        if ((type & XEN_HOST_PCI_REGION_TYPE_MEM)
+            && (type & XEN_HOST_PCI_REGION_TYPE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != XEN_PT_BAR_FLAG_UPPER) {
+                return XEN_PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return XEN_PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device.io_regions[index].type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return XEN_PT_BAR_FLAG_IO;
+    } else {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
+{
+    if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int xen_pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = xen_pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED) {
+        reg_field = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device.io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *val, uint32_t dev_value,
+                                uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = xen_pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (XEN_PT_BAR_ALLF & ~bar_ro_mask)) {
+                XEN_PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                            "Ignore mapping. "
+                            "(offset: 0x%02x, high address: 0x%08x)\n",
+                            reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                        XenPTReg *cfg_entry, uint32_t *val,
+                                        uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = xen_pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_header0[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_vendor_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_device_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_cmd_reg_read,
+        .u.w.write  = xen_pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = xen_pt_status_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = xen_pt_header_type_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_irqpin_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int xen_pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int xen_pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = XEN_PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_devctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint16_t *val,
+                                  uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pm[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_pmcsr_reg_read,
+        .u.w.write  = xen_pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int xen_pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                    const XenPTRegGroupInfo *grp_reg,
+                                    uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int xen_pt_vendor_size_init(XenPCIPassthroughState *s,
+                                   const XenPTRegGroupInfo *grp_reg,
+                                   uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        XEN_PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_header0,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_pm,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_vpd,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_vendor_size_init,
+        .emu_regs = xen_pt_emu_reg_vendor,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_pcie_size_init,
+        .emu_regs = xen_pt_emu_reg_pcie,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (xen_pt_emu_reg_grps[i].grp_id == cap_id) {
+                if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (xen_host_pci_get_byte(&s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (xen_host_pci_get_byte(&s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (xen_host_pci_get_byte(&s->real_device,
+                                  pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int xen_pt_config_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == XEN_PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int xen_pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grps);
+
+    for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, xen_pt_emu_reg_grps[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = xen_pt_emu_reg_grps + i;
+        if (xen_pt_emu_reg_grps[i].size_init) {
+            /* get register group size */
+            rc = xen_pt_emu_reg_grps[i].size_init(s, reg_grp_entry->reg_grp,
+                                                  reg_grp_offset,
+                                                  &reg_grp_entry->size);
+            if (rc < 0) {
+                xen_pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+            if (xen_pt_emu_reg_grps[i].emu_regs) {
+                int j = 0;
+                XenPTRegInfo *regs = xen_pt_emu_reg_grps[i].emu_regs;
+                /* initialize capability register */
+                for (j = 0; regs->size != 0; j++, regs++) {
+                    /* initialize capability register */
+                    rc = xen_pt_config_reg_init(s, reg_grp_entry, regs);
+                    if (rc < 0) {
+                        xen_pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void xen_pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:33:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF5jM-0000x2-VG; Tue, 03 Apr 2012 15:33:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SF5jL-0000vQ-CH
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:33:11 +0000
Received: from [85.158.143.99:63594] by server-3.bemta-4.messagelabs.com id
	44/5E-05853-6381B7F4; Tue, 03 Apr 2012 15:33:10 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1333467186!16444217!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28890 invoked from network); 3 Apr 2012 15:33:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:33:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188833701"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 11:32:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 11:32:49 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SF5iz-0003Nm-AL;
	Tue, 03 Apr 2012 16:32:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 3 Apr 2012 16:32:41 +0100
Message-ID: <1333467163-25795-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
References: <1333467163-25795-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V11 6/8] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_pt.c             |   10 +
 hw/xen_pt.h             |    2 +
 hw/xen_pt_config_init.c | 1387 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1399 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index afa985a..c2e211a 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -676,6 +676,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (xen_pt_config_init(s)) {
+        XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         XEN_PT_LOG(d, "no pin interrupt\n");
@@ -774,6 +781,9 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    xen_pt_config_delete(s);
+
     xen_pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index f029841..4bb8cb6 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -62,6 +62,8 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_ALLF 0xFFFFFFFF
 #define XEN_PT_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 64d22e8..1d97876 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1,11 +1,1398 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pt.h"
 
+#define XEN_PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define XEN_PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int xen_pt_hide_dev_cap(const XenHostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * xen_pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_SFP_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grps, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int xen_pt_common_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int xen_pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+
+/* Write register functions */
+
+static int xen_pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint8_t *val, uint8_t dev_value,
+                                 uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *val, uint16_t dev_value,
+                                 uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint32_t *val, uint32_t dev_value,
+                                 uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int xen_pt_vendor_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.vendor_id;
+    return 0;
+}
+static int xen_pt_device_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.device_id;
+    return 0;
+}
+static int xen_pt_status_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = xen_pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                       XenPTRegInfo *reg, uint32_t real_offset,
+                                       uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int xen_pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = xen_pt_pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int xen_pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *val, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*val & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define XEN_PT_BAR_MEM_RO_MASK    0x0000000F  /* BAR ReadOnly mask(Memory) */
+#define XEN_PT_BAR_MEM_EMU_MASK   0xFFFFFFF0  /* BAR emul mask(Memory) */
+#define XEN_PT_BAR_IO_RO_MASK     0x00000003  /* BAR ReadOnly mask(I/O) */
+#define XEN_PT_BAR_IO_EMU_MASK    0xFFFFFFFC  /* BAR emul mask(I/O) */
+
+static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
+                                         XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int type = s->real_device.io_regions[index - 1].type;
+
+        if ((type & XEN_HOST_PCI_REGION_TYPE_MEM)
+            && (type & XEN_HOST_PCI_REGION_TYPE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != XEN_PT_BAR_FLAG_UPPER) {
+                return XEN_PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return XEN_PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device.io_regions[index].type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return XEN_PT_BAR_FLAG_IO;
+    } else {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
+{
+    if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int xen_pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = xen_pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED) {
+        reg_field = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device.io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *val, uint32_t dev_value,
+                                uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = xen_pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (XEN_PT_BAR_ALLF & ~bar_ro_mask)) {
+                XEN_PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                            "Ignore mapping. "
+                            "(offset: 0x%02x, high address: 0x%08x)\n",
+                            reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                        XenPTReg *cfg_entry, uint32_t *val,
+                                        uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = xen_pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_header0[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_vendor_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_device_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_cmd_reg_read,
+        .u.w.write  = xen_pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = xen_pt_status_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = xen_pt_header_type_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_irqpin_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int xen_pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int xen_pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = XEN_PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_devctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint16_t *val,
+                                  uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pm[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_pmcsr_reg_read,
+        .u.w.write  = xen_pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int xen_pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                    const XenPTRegGroupInfo *grp_reg,
+                                    uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int xen_pt_vendor_size_init(XenPCIPassthroughState *s,
+                                   const XenPTRegGroupInfo *grp_reg,
+                                   uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        XEN_PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_header0,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_pm,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_vpd,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_vendor_size_init,
+        .emu_regs = xen_pt_emu_reg_vendor,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_pcie_size_init,
+        .emu_regs = xen_pt_emu_reg_pcie,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (xen_pt_emu_reg_grps[i].grp_id == cap_id) {
+                if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (xen_host_pci_get_byte(&s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (xen_host_pci_get_byte(&s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (xen_host_pci_get_byte(&s->real_device,
+                                  pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int xen_pt_config_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == XEN_PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int xen_pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grps);
+
+    for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, xen_pt_emu_reg_grps[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = xen_pt_emu_reg_grps + i;
+        if (xen_pt_emu_reg_grps[i].size_init) {
+            /* get register group size */
+            rc = xen_pt_emu_reg_grps[i].size_init(s, reg_grp_entry->reg_grp,
+                                                  reg_grp_offset,
+                                                  &reg_grp_entry->size);
+            if (rc < 0) {
+                xen_pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+            if (xen_pt_emu_reg_grps[i].emu_regs) {
+                int j = 0;
+                XenPTRegInfo *regs = xen_pt_emu_reg_grps[i].emu_regs;
+                /* initialize capability register */
+                for (j = 0; regs->size != 0; j++, regs++) {
+                    /* initialize capability register */
+                    rc = xen_pt_config_reg_init(s, reg_grp_entry, regs);
+                    if (rc < 0) {
+                        xen_pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void xen_pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:56:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF65i-0002SA-FF; Tue, 03 Apr 2012 15:56:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SF65h-0002S5-53
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:56:17 +0000
Received: from [85.158.138.51:3130] by server-3.bemta-3.messagelabs.com id
	08/09-10665-0AD1B7F4; Tue, 03 Apr 2012 15:56:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333468575!18811858!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25281 invoked from network); 3 Apr 2012 15:56:15 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:56:15 -0000
Received: by eekc13 with SMTP id c13so1734030eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Apr 2012 08:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=dTb7hRRF2IxLD4PcThR0/1Y/V77/Cg2dBexZzJyr+hE=;
	b=uj8eqZHd+DSF449FNR6YDSexcBqy3P/FFSXL504gKSl2D1VqfoQHY+Tmv2D3/2tneB
	gH7iwpn5t8UXR8wBPgUzZzF7eqkxbCbde/kIDeXFCzuToKJSRJBWM3Rc2WRHjcCxJ4AD
	gGMoYWgkkns4Ol6gxgk5cY5P6JI++VLP9SEY7iFa4+Z6RBjT5EcUn3Mb8jLueoM+o5eY
	Sm4eKdUVSu7TdqD+CgMxpGUl69olztBBeBAxbG+9NU09Z/Tbam8t9WvFhKAGB/rlXXFQ
	DH0kri8WODQiv2jyklooCmA6K9SOD+SyLV3Sl/vuVd+X22mtv5iahgAaHq2j6XQY8GXo
	vqEw==
Received: by 10.14.52.80 with SMTP id d56mr2436592eec.105.1333468573279;
	Tue, 03 Apr 2012 08:56:13 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id m42sm75257167eef.0.2012.04.03.08.56.10
	(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 08:56:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 03 Apr 2012 16:56:05 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Steve Johnston <steve.johnston@adventiumlabs.com>
Message-ID: <CBA0DC25.3D52B%keir@xen.org>
Thread-Topic: [Xen-devel] Submitting a patch for 4.0.1?
Thread-Index: Ac0RskaamsW7yqZ9Rk6C4FJSm7LJgw==
In-Reply-To: <20347.3804.956615.607757@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Submitting a patch for 4.0.1?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/04/2012 15:53, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Steve Johnston writes ("[Xen-devel] Submitting a patch for 4.0.1?"):
>> I have been using Xen 4.0.1 and have created/added a new scheduler that
>> I would like to release into the mainline.
>> 
>> Am I able to submit a patch for an older version of Xen or do I need to
>> port my changes to the current devel project?
> 
> New features of this kind will only be accepted into the mainline
> development series.
> 
> However, it would be worthwhile posting your patches as they are,
> against xen-4.0, so that we can see whether we are likely to accept
> them.  That might save you some wasted effort if it turns out that
> your new code is too hard to get into shape or unsuitable in some way.

Also, mainline is feature frozen for 4.2.0 right now, so you have a while
before we would accept a new scheduler anyhow.

 -- Keir

> Thanks,
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 15:56:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 15:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF65i-0002SA-FF; Tue, 03 Apr 2012 15:56:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SF65h-0002S5-53
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 15:56:17 +0000
Received: from [85.158.138.51:3130] by server-3.bemta-3.messagelabs.com id
	08/09-10665-0AD1B7F4; Tue, 03 Apr 2012 15:56:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333468575!18811858!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25281 invoked from network); 3 Apr 2012 15:56:15 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 15:56:15 -0000
Received: by eekc13 with SMTP id c13so1734030eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Apr 2012 08:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=dTb7hRRF2IxLD4PcThR0/1Y/V77/Cg2dBexZzJyr+hE=;
	b=uj8eqZHd+DSF449FNR6YDSexcBqy3P/FFSXL504gKSl2D1VqfoQHY+Tmv2D3/2tneB
	gH7iwpn5t8UXR8wBPgUzZzF7eqkxbCbde/kIDeXFCzuToKJSRJBWM3Rc2WRHjcCxJ4AD
	gGMoYWgkkns4Ol6gxgk5cY5P6JI++VLP9SEY7iFa4+Z6RBjT5EcUn3Mb8jLueoM+o5eY
	Sm4eKdUVSu7TdqD+CgMxpGUl69olztBBeBAxbG+9NU09Z/Tbam8t9WvFhKAGB/rlXXFQ
	DH0kri8WODQiv2jyklooCmA6K9SOD+SyLV3Sl/vuVd+X22mtv5iahgAaHq2j6XQY8GXo
	vqEw==
Received: by 10.14.52.80 with SMTP id d56mr2436592eec.105.1333468573279;
	Tue, 03 Apr 2012 08:56:13 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id m42sm75257167eef.0.2012.04.03.08.56.10
	(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 08:56:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 03 Apr 2012 16:56:05 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Steve Johnston <steve.johnston@adventiumlabs.com>
Message-ID: <CBA0DC25.3D52B%keir@xen.org>
Thread-Topic: [Xen-devel] Submitting a patch for 4.0.1?
Thread-Index: Ac0RskaamsW7yqZ9Rk6C4FJSm7LJgw==
In-Reply-To: <20347.3804.956615.607757@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Submitting a patch for 4.0.1?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/04/2012 15:53, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Steve Johnston writes ("[Xen-devel] Submitting a patch for 4.0.1?"):
>> I have been using Xen 4.0.1 and have created/added a new scheduler that
>> I would like to release into the mainline.
>> 
>> Am I able to submit a patch for an older version of Xen or do I need to
>> port my changes to the current devel project?
> 
> New features of this kind will only be accepted into the mainline
> development series.
> 
> However, it would be worthwhile posting your patches as they are,
> against xen-4.0, so that we can see whether we are likely to accept
> them.  That might save you some wasted effort if it turns out that
> your new code is too hard to get into shape or unsuitable in some way.

Also, mainline is feature frozen for 4.2.0 right now, so you have a while
before we would accept a new scheduler anyhow.

 -- Keir

> Thanks,
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6WL-0003Gg-6c; Tue, 03 Apr 2012 16:23:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF6WJ-0003Gb-Op
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:23:47 +0000
Received: from [85.158.139.83:25502] by server-8.bemta-5.messagelabs.com id
	B9/75-26964-2142B7F4; Tue, 03 Apr 2012 16:23:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333470225!19622448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11598 invoked from network); 3 Apr 2012 16:23:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:23:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11751575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:23:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 17:23:45 +0100
Date: Tue, 3 Apr 2012 17:25:58 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120403131947.GC12464@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204031724340.15151@kaball-desktop>
References: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120403131947.GC12464@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 03, 2012 at 12:25:02PM +0100, Stefano Stabellini wrote:
> > Since when we are using the m2p_override it is not true anymore that the
>         ^^^^ - get rid of that.
> > mmap'ed area doesn't have corresponsing struct pages.
> 
> That reads to me as !!do struct page. Which comes out as:
> 
> "m2p_override_* API the mmap-ed are have corresponding struct pages' ?

Yes, indeed: m2p_override_* provides the corresponding struct pages


> > Removing the VM_PFNMAP flag makes get_user_pages work on the mmap'ed user vma.
> > An example test case would be using a Xen userspace block backend
> > (QDISK) on a file on NFS using O_DIRECT.
> > 
> > The patch should be backported back to 2.6.38.
> 
> Add CC: stable@kernel.org then.

I'll resend CCing stable


> But does this patch depend on other
> patches?

only on the m2p_override, that is in Linux since 2.6.38

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6WL-0003Gg-6c; Tue, 03 Apr 2012 16:23:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF6WJ-0003Gb-Op
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:23:47 +0000
Received: from [85.158.139.83:25502] by server-8.bemta-5.messagelabs.com id
	B9/75-26964-2142B7F4; Tue, 03 Apr 2012 16:23:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333470225!19622448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11598 invoked from network); 3 Apr 2012 16:23:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:23:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11751575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:23:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 17:23:45 +0100
Date: Tue, 3 Apr 2012 17:25:58 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120403131947.GC12464@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204031724340.15151@kaball-desktop>
References: <1333452302-5749-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120403131947.GC12464@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 03, 2012 at 12:25:02PM +0100, Stefano Stabellini wrote:
> > Since when we are using the m2p_override it is not true anymore that the
>         ^^^^ - get rid of that.
> > mmap'ed area doesn't have corresponsing struct pages.
> 
> That reads to me as !!do struct page. Which comes out as:
> 
> "m2p_override_* API the mmap-ed are have corresponding struct pages' ?

Yes, indeed: m2p_override_* provides the corresponding struct pages


> > Removing the VM_PFNMAP flag makes get_user_pages work on the mmap'ed user vma.
> > An example test case would be using a Xen userspace block backend
> > (QDISK) on a file on NFS using O_DIRECT.
> > 
> > The patch should be backported back to 2.6.38.
> 
> Add CC: stable@kernel.org then.

I'll resend CCing stable


> But does this patch depend on other
> patches?

only on the m2p_override, that is in Linux since 2.6.38

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:40:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6mD-0003Ub-O4; Tue, 03 Apr 2012 16:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF6mC-0003UW-K5
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:40:12 +0000
Received: from [85.158.139.83:14426] by server-12.bemta-5.messagelabs.com id
	A2/F4-05587-BE72B7F4; Tue, 03 Apr 2012 16:40:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333471210!22352100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22075 invoked from network); 3 Apr 2012 16:40:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11751865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:39:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	17:39:59 +0100
Message-ID: <1333471197.10586.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 17:39:57 +0100
In-Reply-To: <20120403150428.GB8190@aepfle.de>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
	<20346.53247.182217.288605@mariner.uk.xensource.com>
	<1333450222.25602.131.camel@zakaz.uk.xensource.com>
	<20120403150428.GB8190@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 16:04 +0100, Olaf Hering wrote:
> On Tue, Apr 03, Ian Campbell wrote:
> 
> > On Tue, 2012-04-03 at 11:25 +0100, Ian Jackson wrote:
> > > Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > > > tools/libvchan: fix build errors caused by Werror in io.c
> > > ...
> > > > io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
> > > ...
> > > > -		writev(-1, iov, 2);
> > > > +		/* Silence gcc warning, will always fail */
> > > > +		if (writev(-1, iov, 2));
> > > 
> > > I still think this is an unpleasant idiom.  Does casting the result to
> > > void not help ?
> 
> Just '(void)writev(...);' does not prevent the warning.
> 
> > What does writev(-1,...) even mean? Can we not just nuke it?
> 
> Its just there for debugging with strace. Wether the whole debug ca be
> removed, no idea.

Lets just nuke it then, someone who is debugging libvchan can add things
like this locally if they need to.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:40:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6mD-0003Ub-O4; Tue, 03 Apr 2012 16:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SF6mC-0003UW-K5
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:40:12 +0000
Received: from [85.158.139.83:14426] by server-12.bemta-5.messagelabs.com id
	A2/F4-05587-BE72B7F4; Tue, 03 Apr 2012 16:40:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333471210!22352100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22075 invoked from network); 3 Apr 2012 16:40:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11751865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:39:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	17:39:59 +0100
Message-ID: <1333471197.10586.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Apr 2012 17:39:57 +0100
In-Reply-To: <20120403150428.GB8190@aepfle.de>
References: <patchbomb.1333397723@probook.site>
	<3d15aa971865cf18dac4.1333397737@probook.site>
	<20346.53247.182217.288605@mariner.uk.xensource.com>
	<1333450222.25602.131.camel@zakaz.uk.xensource.com>
	<20120403150428.GB8190@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14 of 18] tools/libvchan: fix build errors
 caused by Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 16:04 +0100, Olaf Hering wrote:
> On Tue, Apr 03, Ian Campbell wrote:
> 
> > On Tue, 2012-04-03 at 11:25 +0100, Ian Jackson wrote:
> > > Olaf Hering writes ("[PATCH 14 of 18] tools/libvchan: fix build errors caused by Werror in io.c"):
> > > > tools/libvchan: fix build errors caused by Werror in io.c
> > > ...
> > > > io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
> > > ...
> > > > -		writev(-1, iov, 2);
> > > > +		/* Silence gcc warning, will always fail */
> > > > +		if (writev(-1, iov, 2));
> > > 
> > > I still think this is an unpleasant idiom.  Does casting the result to
> > > void not help ?
> 
> Just '(void)writev(...);' does not prevent the warning.
> 
> > What does writev(-1,...) even mean? Can we not just nuke it?
> 
> Its just there for debugging with strace. Wether the whole debug ca be
> removed, no idea.

Lets just nuke it then, someone who is debugging libvchan can add things
like this locally if they need to.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6rW-0003hH-G3; Tue, 03 Apr 2012 16:45:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SF6rU-0003hA-Lw
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:45:40 +0000
Received: from [85.158.139.83:22278] by server-9.bemta-5.messagelabs.com id
	83/A2-09826-3392B7F4; Tue, 03 Apr 2012 16:45:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333471538!19625979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31844 invoked from network); 3 Apr 2012 16:45:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:45:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11751945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:45:38 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	17:45:38 +0100
Message-ID: <1333471466.2485.259.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue, 3 Apr 2012 17:44:26 +0100
In-Reply-To: <4F4F9C3F.5020201@redhat.com>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
	<4F4E64B5.5080900@siemens.com>
	<1330597236.10387.70.camel@leeds.uk.xensource.com>
	<4F4F5BF5.6010206@siemens.com>
	<1330602678.10387.73.camel@leeds.uk.xensource.com>
	<4F4F71F0.4070109@redhat.com>
	<alpine.DEB.2.00.1203011403140.923@kaball-desktop>
	<4F4F81AE.9080503@redhat.com>
	<alpine.DEB.2.00.1203011446190.923@kaball-desktop>
	<4F4F9C3F.5020201@redhat.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
> Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
> >>> > > That is a good point actually: we already have lapic emulation in Xen,
> >>> > > it makes sense to have apic-msi in Xen too.
> >>> > > We would still need the changes to msi_notify and msix_notify though.
> >> > 
> >> > Why?  The stores would just go to the Xen interrupt controller MMIO area
> >> > which then does the xc_hvm_inject_msi.
> >  
> > Because msi(x)_notify is called by QEMU's emulated devices: it is not
> > possible from QEMU to cause an emulation trap in Xen on behalf of the
> > guest.
> 

I'm not a QEMU expert, so following question may be dumb. However I do
care about a cleaner implementation. So please be patient with me. :-)

> msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
> patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
> 

I don't quite understand "you don't need anymore the msi{,x}_notify
parts". Virtio PCI invokes msi_notify directly. If I don't hook up
msi{,x}_notify, how can I deal with devices like Virtio PCI?


Wei.

> But you could take it further and create a separate subclass of
> apic-common that does absolutely nothing except register an MMIO memory
> region and use it to trap MSI writes.  Basically an even more stripped
> down version than hw/kvm/apic.c, but using memory_region_init_io rather
> than memory_region_init_reservation.  You would also get support for the
> monitor command inject-nmi (there is another hypercall for that in Xen
> IIRC).
> 
> Paolo



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6rW-0003hH-G3; Tue, 03 Apr 2012 16:45:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SF6rU-0003hA-Lw
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:45:40 +0000
Received: from [85.158.139.83:22278] by server-9.bemta-5.messagelabs.com id
	83/A2-09826-3392B7F4; Tue, 03 Apr 2012 16:45:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333471538!19625979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31844 invoked from network); 3 Apr 2012 16:45:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:45:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11751945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:45:38 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	17:45:38 +0100
Message-ID: <1333471466.2485.259.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue, 3 Apr 2012 17:44:26 +0100
In-Reply-To: <4F4F9C3F.5020201@redhat.com>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
	<4F4E64B5.5080900@siemens.com>
	<1330597236.10387.70.camel@leeds.uk.xensource.com>
	<4F4F5BF5.6010206@siemens.com>
	<1330602678.10387.73.camel@leeds.uk.xensource.com>
	<4F4F71F0.4070109@redhat.com>
	<alpine.DEB.2.00.1203011403140.923@kaball-desktop>
	<4F4F81AE.9080503@redhat.com>
	<alpine.DEB.2.00.1203011446190.923@kaball-desktop>
	<4F4F9C3F.5020201@redhat.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
> Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
> >>> > > That is a good point actually: we already have lapic emulation in Xen,
> >>> > > it makes sense to have apic-msi in Xen too.
> >>> > > We would still need the changes to msi_notify and msix_notify though.
> >> > 
> >> > Why?  The stores would just go to the Xen interrupt controller MMIO area
> >> > which then does the xc_hvm_inject_msi.
> >  
> > Because msi(x)_notify is called by QEMU's emulated devices: it is not
> > possible from QEMU to cause an emulation trap in Xen on behalf of the
> > guest.
> 

I'm not a QEMU expert, so following question may be dumb. However I do
care about a cleaner implementation. So please be patient with me. :-)

> msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
> patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
> 

I don't quite understand "you don't need anymore the msi{,x}_notify
parts". Virtio PCI invokes msi_notify directly. If I don't hook up
msi{,x}_notify, how can I deal with devices like Virtio PCI?


Wei.

> But you could take it further and create a separate subclass of
> apic-common that does absolutely nothing except register an MMIO memory
> region and use it to trap MSI writes.  Basically an even more stripped
> down version than hw/kvm/apic.c, but using memory_region_init_io rather
> than memory_region_init_reservation.  You would also get support for the
> monitor command inject-nmi (there is another hypercall for that in Xen
> IIRC).
> 
> Paolo



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:52:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6y4-0003sC-At; Tue, 03 Apr 2012 16:52:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SF6y3-0003s7-6O
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:52:27 +0000
Received: from [85.158.143.99:60104] by server-2.bemta-4.messagelabs.com id
	37/69-17550-ACA2B7F4; Tue, 03 Apr 2012 16:52:26 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333471945!21276089!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDM3MjE0NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25134 invoked from network); 3 Apr 2012 16:52:25 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 16:52:25 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q33GqKa5001804;
	Tue, 3 Apr 2012 18:52:20 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q33GqJob008763;
	Tue, 3 Apr 2012 18:52:19 +0200
Message-ID: <4F7B2AC3.6030304@siemens.com>
Date: Tue, 03 Apr 2012 18:52:19 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
	<4F4E64B5.5080900@siemens.com>
	<1330597236.10387.70.camel@leeds.uk.xensource.com>
	<4F4F5BF5.6010206@siemens.com>
	<1330602678.10387.73.camel@leeds.uk.xensource.com>
	<4F4F71F0.4070109@redhat.com>
	<alpine.DEB.2.00.1203011403140.923@kaball-desktop>
	<4F4F81AE.9080503@redhat.com>
	<alpine.DEB.2.00.1203011446190.923@kaball-desktop>
	<4F4F9C3F.5020201@redhat.com>
	<1333471466.2485.259.camel@leeds.uk.xensource.com>
In-Reply-To: <1333471466.2485.259.camel@leeds.uk.xensource.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-04-03 18:44, Wei Liu wrote:
> On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
>> Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
>>>>>>> That is a good point actually: we already have lapic emulation in Xen,
>>>>>>> it makes sense to have apic-msi in Xen too.
>>>>>>> We would still need the changes to msi_notify and msix_notify though.
>>>>>
>>>>> Why?  The stores would just go to the Xen interrupt controller MMIO area
>>>>> which then does the xc_hvm_inject_msi.
>>>  
>>> Because msi(x)_notify is called by QEMU's emulated devices: it is not
>>> possible from QEMU to cause an emulation trap in Xen on behalf of the
>>> guest.
>>
> 
> I'm not a QEMU expert, so following question may be dumb. However I do
> care about a cleaner implementation. So please be patient with me. :-)
> 
>> msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
>> patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
>>
> 
> I don't quite understand "you don't need anymore the msi{,x}_notify
> parts". Virtio PCI invokes msi_notify directly. If I don't hook up
> msi{,x}_notify, how can I deal with devices like Virtio PCI?

See how KVM will solve this in [1].

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/89121

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:52:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF6y4-0003sC-At; Tue, 03 Apr 2012 16:52:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SF6y3-0003s7-6O
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 16:52:27 +0000
Received: from [85.158.143.99:60104] by server-2.bemta-4.messagelabs.com id
	37/69-17550-ACA2B7F4; Tue, 03 Apr 2012 16:52:26 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333471945!21276089!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDM3MjE0NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25134 invoked from network); 3 Apr 2012 16:52:25 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Apr 2012 16:52:25 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q33GqKa5001804;
	Tue, 3 Apr 2012 18:52:20 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q33GqJob008763;
	Tue, 3 Apr 2012 18:52:19 +0200
Message-ID: <4F7B2AC3.6030304@siemens.com>
Date: Tue, 03 Apr 2012 18:52:19 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
	<4F4E64B5.5080900@siemens.com>
	<1330597236.10387.70.camel@leeds.uk.xensource.com>
	<4F4F5BF5.6010206@siemens.com>
	<1330602678.10387.73.camel@leeds.uk.xensource.com>
	<4F4F71F0.4070109@redhat.com>
	<alpine.DEB.2.00.1203011403140.923@kaball-desktop>
	<4F4F81AE.9080503@redhat.com>
	<alpine.DEB.2.00.1203011446190.923@kaball-desktop>
	<4F4F9C3F.5020201@redhat.com>
	<1333471466.2485.259.camel@leeds.uk.xensource.com>
In-Reply-To: <1333471466.2485.259.camel@leeds.uk.xensource.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-04-03 18:44, Wei Liu wrote:
> On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
>> Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
>>>>>>> That is a good point actually: we already have lapic emulation in Xen,
>>>>>>> it makes sense to have apic-msi in Xen too.
>>>>>>> We would still need the changes to msi_notify and msix_notify though.
>>>>>
>>>>> Why?  The stores would just go to the Xen interrupt controller MMIO area
>>>>> which then does the xc_hvm_inject_msi.
>>>  
>>> Because msi(x)_notify is called by QEMU's emulated devices: it is not
>>> possible from QEMU to cause an emulation trap in Xen on behalf of the
>>> guest.
>>
> 
> I'm not a QEMU expert, so following question may be dumb. However I do
> care about a cleaner implementation. So please be patient with me. :-)
> 
>> msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
>> patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
>>
> 
> I don't quite understand "you don't need anymore the msi{,x}_notify
> parts". Virtio PCI invokes msi_notify directly. If I don't hook up
> msi{,x}_notify, how can I deal with devices like Virtio PCI?

See how KVM will solve this in [1].

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/89121

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF748-000419-4i; Tue, 03 Apr 2012 16:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF746-000413-O0
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 16:58:42 +0000
Received: from [85.158.143.35:9750] by server-1.bemta-4.messagelabs.com id
	FB/0F-20925-14C2B7F4; Tue, 03 Apr 2012 16:58:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333472321!14553823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6262 invoked from network); 3 Apr 2012 16:58:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:58:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 17:58:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF744-0006FY-AJ; Tue, 03 Apr 2012 16:58:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF744-0005S1-9I;
	Tue, 03 Apr 2012 17:58:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.11328.121224.686159@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 17:58:40 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > I'm not really convinced that these are appropriate for backporting to
> > a supposedly stable tree.
> 
> What about the changeset 25131:6f81f4d79fde?  It won't be able to
> apply cleanly in xen-4.1-testing though and I can provide the backport
> version for review if you give an OK?

I would be happy to consider a backport of 25131, yes.  You'll have to
do some work as 4.1 doesn't have libxl_defbool_*.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 16:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 16:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF748-000419-4i; Tue, 03 Apr 2012 16:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF746-000413-O0
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 16:58:42 +0000
Received: from [85.158.143.35:9750] by server-1.bemta-4.messagelabs.com id
	FB/0F-20925-14C2B7F4; Tue, 03 Apr 2012 16:58:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333472321!14553823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6262 invoked from network); 3 Apr 2012 16:58:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 16:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 16:58:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 17:58:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF744-0006FY-AJ; Tue, 03 Apr 2012 16:58:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF744-0005S1-9I;
	Tue, 03 Apr 2012 17:58:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.11328.121224.686159@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 17:58:40 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > I'm not really convinced that these are appropriate for backporting to
> > a supposedly stable tree.
> 
> What about the changeset 25131:6f81f4d79fde?  It won't be able to
> apply cleanly in xen-4.1-testing though and I can provide the backport
> version for review if you give an OK?

I would be happy to consider a backport of 25131, yes.  You'll have to
do some work as 4.1 doesn't have libxl_defbool_*.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:03:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:03:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF78j-0004BP-RL; Tue, 03 Apr 2012 17:03:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF78i-0004BK-NS
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:03:28 +0000
Received: from [85.158.138.51:47366] by server-10.bemta-3.messagelabs.com id
	90/90-15637-F5D2B7F4; Tue, 03 Apr 2012 17:03:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333472605!20627041!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12586 invoked from network); 3 Apr 2012 17:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23828587"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:03:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 13:03:25 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SF78Z-0004i4-F7; Tue, 03 Apr 2012 18:03:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 3 Apr 2012 18:05:47 +0100
Message-ID: <1333472747-11432-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: stable@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since we are using the m2p_override we do have struct pages
corresponding to the user vma mmap'ed by gntdev.

Removing the VM_PFNMAP flag makes get_user_pages work on that vma.
An example test case would be using a Xen userspace block backend
(QDISK) on a file on NFS using O_DIRECT.

The patch should be backported back to 2.6.38.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/gntdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 99d8151..1ffd03b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
 	vma->vm_flags |= VM_RESERVED|VM_DONTEXPAND;
 
 	if (use_ptemod)
-		vma->vm_flags |= VM_DONTCOPY|VM_PFNMAP;
+		vma->vm_flags |= VM_DONTCOPY;
 
 	vma->vm_private_data = map;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:03:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:03:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF78j-0004BP-RL; Tue, 03 Apr 2012 17:03:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SF78i-0004BK-NS
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:03:28 +0000
Received: from [85.158.138.51:47366] by server-10.bemta-3.messagelabs.com id
	90/90-15637-F5D2B7F4; Tue, 03 Apr 2012 17:03:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333472605!20627041!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12586 invoked from network); 3 Apr 2012 17:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23828587"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 13:03:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 13:03:25 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SF78Z-0004i4-F7; Tue, 03 Apr 2012 18:03:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 3 Apr 2012 18:05:47 +0100
Message-ID: <1333472747-11432-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: stable@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] xen/gntdev: do not set VM_PFNMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since we are using the m2p_override we do have struct pages
corresponding to the user vma mmap'ed by gntdev.

Removing the VM_PFNMAP flag makes get_user_pages work on that vma.
An example test case would be using a Xen userspace block backend
(QDISK) on a file on NFS using O_DIRECT.

The patch should be backported back to 2.6.38.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/gntdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 99d8151..1ffd03b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
 	vma->vm_flags |= VM_RESERVED|VM_DONTEXPAND;
 
 	if (use_ptemod)
-		vma->vm_flags |= VM_DONTCOPY|VM_PFNMAP;
+		vma->vm_flags |= VM_DONTCOPY;
 
 	vma->vm_private_data = map;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:13:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7IN-0004PU-0G; Tue, 03 Apr 2012 17:13:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7IL-0004PP-BH
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:13:25 +0000
Received: from [85.158.143.35:53394] by server-1.bemta-4.messagelabs.com id
	3F/CE-20925-4BF2B7F4; Tue, 03 Apr 2012 17:13:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333473203!10876381!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13801 invoked from network); 3 Apr 2012 17:13:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:13:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:13:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7II-0006KN-Qv; Tue, 03 Apr 2012 17:13:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7II-0006Kv-O9;
	Tue, 03 Apr 2012 18:13:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12210.719765.271115@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:13:22 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bb6c07589982cd206f73.1332961005@probook.site>
References: <bb6c07589982cd206f73.1332961005@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com, Fabio Fantoni <fantonifabio@tiscali.it>
Subject: [Xen-devel] [PATCH] tools/configure: add options to
	pass	EXTRA_CLFAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/configure: add options to pass EXTRA_CLFAGS"):
> tools/configure: add options to pass EXTRA_CLFAGS

Much of this looks good to me.  (Although you need to fix the typo
CLFLAGS in the subject...)

I'm happy with the changes to all the tools/*/Makefile.

> This patch extends configure to recognize three environment variables
> which will be written to config/Tools.mk so they will be reused with
> each make invocation:
>   EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
>   EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
>   EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.
> The new feature can be used like this in a rpm xen.spec file:

I'm not sure why it is necessary to plumb these through our configure
and Tools.mk.  Why can't we just take them from the environment (or
the make command line) ?

However, 

>  		cd qemu-xen-traditional-dir; \
> +		env CFLAGS="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
>  		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
>  		$(MAKE) install

I'm not really sure that this is a good idea.  Note that the xen-setup
script in qemu-xen-traditional already imports many of the settings
from the Xen tree.  I think this would be a better approach than a
blanket export of CFLAGS.

> @@ -146,6 +147,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>  		source=.; \
>  	fi; \
>  	cd qemu-xen-dir; \
> +	env CFLAGS="$(EXTRA_CFLAGS_QEMU_XEN)" \
>  	$$source/configure --enable-xen --target-list=i386-softmmu \
>  		--source-path=$$source \
>  		--extra-cflags="-I$(XEN_ROOT)/tools/include \

And this definitely isn't a good idea, unless you can find me some
documentation from qemu upstream which says that it is a supported
approach.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:13:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7IN-0004PU-0G; Tue, 03 Apr 2012 17:13:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7IL-0004PP-BH
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:13:25 +0000
Received: from [85.158.143.35:53394] by server-1.bemta-4.messagelabs.com id
	3F/CE-20925-4BF2B7F4; Tue, 03 Apr 2012 17:13:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333473203!10876381!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13801 invoked from network); 3 Apr 2012 17:13:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:13:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:13:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7II-0006KN-Qv; Tue, 03 Apr 2012 17:13:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7II-0006Kv-O9;
	Tue, 03 Apr 2012 18:13:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12210.719765.271115@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:13:22 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bb6c07589982cd206f73.1332961005@probook.site>
References: <bb6c07589982cd206f73.1332961005@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com, Fabio Fantoni <fantonifabio@tiscali.it>
Subject: [Xen-devel] [PATCH] tools/configure: add options to
	pass	EXTRA_CLFAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/configure: add options to pass EXTRA_CLFAGS"):
> tools/configure: add options to pass EXTRA_CLFAGS

Much of this looks good to me.  (Although you need to fix the typo
CLFLAGS in the subject...)

I'm happy with the changes to all the tools/*/Makefile.

> This patch extends configure to recognize three environment variables
> which will be written to config/Tools.mk so they will be reused with
> each make invocation:
>   EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
>   EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
>   EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.
> The new feature can be used like this in a rpm xen.spec file:

I'm not sure why it is necessary to plumb these through our configure
and Tools.mk.  Why can't we just take them from the environment (or
the make command line) ?

However, 

>  		cd qemu-xen-traditional-dir; \
> +		env CFLAGS="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
>  		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
>  		$(MAKE) install

I'm not really sure that this is a good idea.  Note that the xen-setup
script in qemu-xen-traditional already imports many of the settings
from the Xen tree.  I think this would be a better approach than a
blanket export of CFLAGS.

> @@ -146,6 +147,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>  		source=.; \
>  	fi; \
>  	cd qemu-xen-dir; \
> +	env CFLAGS="$(EXTRA_CFLAGS_QEMU_XEN)" \
>  	$$source/configure --enable-xen --target-list=i386-softmmu \
>  		--source-path=$$source \
>  		--extra-cflags="-I$(XEN_ROOT)/tools/include \

And this definitely isn't a good idea, unless you can find me some
documentation from qemu upstream which says that it is a supported
approach.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:14:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7Io-0004Rp-Ik; Tue, 03 Apr 2012 17:13:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7In-0004RV-PX
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 17:13:53 +0000
Received: from [85.158.138.51:47703] by server-1.bemta-3.messagelabs.com id
	A3/CC-04539-FCF2B7F4; Tue, 03 Apr 2012 17:13:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333473230!20673314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8763 invoked from network); 3 Apr 2012 17:13:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:13:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:13:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7Ij-0006KX-K8; Tue, 03 Apr 2012 17:13:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7Ij-0006L6-JH;
	Tue, 03 Apr 2012 18:13:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12237.583139.606560@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:13:49 +0100
To: Olaf Hering <olaf@aepfle.de>, Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50317ae2a56d66e39079.1329982352@debian.localdomain>,
	<20120315122825.GA18298@aepfle.de>
References: <50317ae2a56d66e39079.1329982352@debian.localdomain>
	<20120315122825.GA18298@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] autoconf: change
 AX_ARG_{DISABLE/ENABLE}_AND_EXPORT to make more sense [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] autoconf: change AX_ARG_{DISABLE/ENABLE}_AND_EXPORT to make more sense"):
> autoconf: change AX_ARG_{DISABLE/ENABLE}_AND_EXPORT to make more sense

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:14:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7Io-0004Rp-Ik; Tue, 03 Apr 2012 17:13:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7In-0004RV-PX
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 17:13:53 +0000
Received: from [85.158.138.51:47703] by server-1.bemta-3.messagelabs.com id
	A3/CC-04539-FCF2B7F4; Tue, 03 Apr 2012 17:13:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333473230!20673314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8763 invoked from network); 3 Apr 2012 17:13:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:13:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:13:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7Ij-0006KX-K8; Tue, 03 Apr 2012 17:13:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7Ij-0006L6-JH;
	Tue, 03 Apr 2012 18:13:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12237.583139.606560@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:13:49 +0100
To: Olaf Hering <olaf@aepfle.de>, Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50317ae2a56d66e39079.1329982352@debian.localdomain>,
	<20120315122825.GA18298@aepfle.de>
References: <50317ae2a56d66e39079.1329982352@debian.localdomain>
	<20120315122825.GA18298@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] autoconf: change
 AX_ARG_{DISABLE/ENABLE}_AND_EXPORT to make more sense [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] autoconf: change AX_ARG_{DISABLE/ENABLE}_AND_EXPORT to make more sense"):
> autoconf: change AX_ARG_{DISABLE/ENABLE}_AND_EXPORT to make more sense

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:15:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7KC-0004ad-1w; Tue, 03 Apr 2012 17:15:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7KA-0004aO-7H
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:15:18 +0000
Received: from [85.158.143.99:49613] by server-3.bemta-4.messagelabs.com id
	A8/BD-05853-5203B7F4; Tue, 03 Apr 2012 17:15:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1333473316!22177387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20912 invoked from network); 3 Apr 2012 17:15:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:15:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:15:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7K7-0006Kx-5T; Tue, 03 Apr 2012 17:15:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7K7-0006MR-4Z;
	Tue, 03 Apr 2012 18:15:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12323.125468.33132@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:15:15 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1331813424-8171-1-git-send-email-anthony.perard@citrix.com>
References: <1331813424-8171-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix parameter pass to qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Fix parameter pass to qemu-xen."):
> QEMU upstream need to kown the amount of RAM given to a guest. This patch give
> the correct value.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:15:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7KC-0004ad-1w; Tue, 03 Apr 2012 17:15:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7KA-0004aO-7H
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:15:18 +0000
Received: from [85.158.143.99:49613] by server-3.bemta-4.messagelabs.com id
	A8/BD-05853-5203B7F4; Tue, 03 Apr 2012 17:15:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1333473316!22177387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20912 invoked from network); 3 Apr 2012 17:15:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:15:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:15:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7K7-0006Kx-5T; Tue, 03 Apr 2012 17:15:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7K7-0006MR-4Z;
	Tue, 03 Apr 2012 18:15:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12323.125468.33132@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:15:15 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1331813424-8171-1-git-send-email-anthony.perard@citrix.com>
References: <1331813424-8171-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix parameter pass to qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Fix parameter pass to qemu-xen."):
> QEMU upstream need to kown the amount of RAM given to a guest. This patch give
> the correct value.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7Nv-0004qB-MI; Tue, 03 Apr 2012 17:19:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7Nv-0004q5-08
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:19:11 +0000
Received: from [85.158.143.99:20216] by server-3.bemta-4.messagelabs.com id
	41/81-05853-E013B7F4; Tue, 03 Apr 2012 17:19:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333473549!21879739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31876 invoked from network); 3 Apr 2012 17:19:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:19:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:19:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:19:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7Ns-0006MS-Qi; Tue, 03 Apr 2012 17:19:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7Ns-0006WP-Ph;
	Tue, 03 Apr 2012 18:19:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12556.576757.747861@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:19:08 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <43d9bd95f981259776cb.1331740983@probook.site>
References: <43d9bd95f981259776cb.1331740983@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/blktap: reorder MEMSHR_DIR to fix
	CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/blktap: reorder MEMSHR_DIR to fix CFLAGS"):
> tools/blktap: reorder MEMSHR_DIR to fix CFLAGS

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7Nv-0004qB-MI; Tue, 03 Apr 2012 17:19:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7Nv-0004q5-08
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:19:11 +0000
Received: from [85.158.143.99:20216] by server-3.bemta-4.messagelabs.com id
	41/81-05853-E013B7F4; Tue, 03 Apr 2012 17:19:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333473549!21879739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31876 invoked from network); 3 Apr 2012 17:19:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:19:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:19:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:19:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7Ns-0006MS-Qi; Tue, 03 Apr 2012 17:19:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7Ns-0006WP-Ph;
	Tue, 03 Apr 2012 18:19:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12556.576757.747861@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:19:08 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <43d9bd95f981259776cb.1331740983@probook.site>
References: <43d9bd95f981259776cb.1331740983@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/blktap: reorder MEMSHR_DIR to fix
	CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/blktap: reorder MEMSHR_DIR to fix CFLAGS"):
> tools/blktap: reorder MEMSHR_DIR to fix CFLAGS

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7Qu-0004yZ-8n; Tue, 03 Apr 2012 17:22:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7Qr-0004yA-Nb
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:22:13 +0000
Received: from [85.158.139.83:33200] by server-12.bemta-5.messagelabs.com id
	8B/4C-05587-4C13B7F4; Tue, 03 Apr 2012 17:22:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333473731!21793609!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22197 invoked from network); 3 Apr 2012 17:22:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:22:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:22:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:22:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7Qp-0006NU-79; Tue, 03 Apr 2012 17:22:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7Qp-0006xf-6B;
	Tue, 03 Apr 2012 18:22:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12739.173257.392499@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:22:11 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <be592e236da2518020f0.1331748359@probook.site>
References: <be592e236da2518020f0.1331748359@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libfsimage: include Rules.mk first
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libfsimage: include Rules.mk first"):
> tools/libfsimage: include Rules.mk first

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7Qu-0004yZ-8n; Tue, 03 Apr 2012 17:22:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF7Qr-0004yA-Nb
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:22:13 +0000
Received: from [85.158.139.83:33200] by server-12.bemta-5.messagelabs.com id
	8B/4C-05587-4C13B7F4; Tue, 03 Apr 2012 17:22:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333473731!21793609!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22197 invoked from network); 3 Apr 2012 17:22:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 17:22:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11752382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 17:22:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 18:22:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SF7Qp-0006NU-79; Tue, 03 Apr 2012 17:22:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SF7Qp-0006xf-6B;
	Tue, 03 Apr 2012 18:22:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20347.12739.173257.392499@mariner.uk.xensource.com>
Date: Tue, 3 Apr 2012 18:22:11 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <be592e236da2518020f0.1331748359@probook.site>
References: <be592e236da2518020f0.1331748359@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libfsimage: include Rules.mk first
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libfsimage: include Rules.mk first"):
> tools/libfsimage: include Rules.mk first

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:32:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7at-0005Bc-JY; Tue, 03 Apr 2012 17:32:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF7ar-0005BX-SY
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:32:34 +0000
Received: from [85.158.138.51:29123] by server-1.bemta-3.messagelabs.com id
	CF/7B-04539-1343B7F4; Tue, 03 Apr 2012 17:32:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333474351!20462075!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29351 invoked from network); 3 Apr 2012 17:32:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 17:32:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333474351; l=904;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=BzptF0WAISgSYuxLplPr88/WTK0=;
	b=ZsJ77sAFT/P4F2jo5f6Vp3UYS0CWAe9o/KDVuW0Czyb+3Ok8sSkn65gC6GnA4JCFK/4
	HePFsIwJet9i89mBlKoIO7VDpVRVGnmQwa0DghFYqd3DRWugN74mLPH76ns1p+dBG2yku
	KFjEhzi3AoMS9UmQpANAMRd9BzOCIbyztfo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by post.strato.de (mrclete mo18) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 502d69o33Gcke5 ;
	Tue, 3 Apr 2012 19:32:28 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5075418637; Tue,  3 Apr 2012 19:32:25 +0200 (CEST)
Date: Tue, 3 Apr 2012 19:32:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: qemu-devel@nongnu.org, xen-devel@lists.xensource.com
Message-ID: <20120403173224.GA22140@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


configure will generate incorrect CFLAGS which will lead to compile
errors due to unknown gcc options, iff CFLAGS was already in the
environment during configure invocation.

Add a space before the -march=i486 gcc option.
Remove += operator usage because configure is not a bash script.

This patch is against the qemu-xen tree, but it should apply also to
qemu.git since it has the same issue. Please apply to both trees.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 configure |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: qemu-xen-dir-remote/configure
===================================================================
--- qemu-xen-dir-remote.orig/configure
+++ qemu-xen-dir-remote/configure
@@ -2637,7 +2637,7 @@ int main(int argc, char **argv)
 }
 EOF
   if ! compile_prog "" "" ; then
-    CFLAGS+="-march=i486"
+    CFLAGS="$CFLAGS -march=i486"
   fi
 fi
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:32:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7at-0005Bc-JY; Tue, 03 Apr 2012 17:32:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF7ar-0005BX-SY
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:32:34 +0000
Received: from [85.158.138.51:29123] by server-1.bemta-3.messagelabs.com id
	CF/7B-04539-1343B7F4; Tue, 03 Apr 2012 17:32:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333474351!20462075!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29351 invoked from network); 3 Apr 2012 17:32:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Apr 2012 17:32:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333474351; l=904;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=BzptF0WAISgSYuxLplPr88/WTK0=;
	b=ZsJ77sAFT/P4F2jo5f6Vp3UYS0CWAe9o/KDVuW0Czyb+3Ok8sSkn65gC6GnA4JCFK/4
	HePFsIwJet9i89mBlKoIO7VDpVRVGnmQwa0DghFYqd3DRWugN74mLPH76ns1p+dBG2yku
	KFjEhzi3AoMS9UmQpANAMRd9BzOCIbyztfo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by post.strato.de (mrclete mo18) (RZmta 28.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 502d69o33Gcke5 ;
	Tue, 3 Apr 2012 19:32:28 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5075418637; Tue,  3 Apr 2012 19:32:25 +0200 (CEST)
Date: Tue, 3 Apr 2012 19:32:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: qemu-devel@nongnu.org, xen-devel@lists.xensource.com
Message-ID: <20120403173224.GA22140@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


configure will generate incorrect CFLAGS which will lead to compile
errors due to unknown gcc options, iff CFLAGS was already in the
environment during configure invocation.

Add a space before the -march=i486 gcc option.
Remove += operator usage because configure is not a bash script.

This patch is against the qemu-xen tree, but it should apply also to
qemu.git since it has the same issue. Please apply to both trees.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 configure |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: qemu-xen-dir-remote/configure
===================================================================
--- qemu-xen-dir-remote.orig/configure
+++ qemu-xen-dir-remote/configure
@@ -2637,7 +2637,7 @@ int main(int argc, char **argv)
 }
 EOF
   if ! compile_prog "" "" ; then
-    CFLAGS+="-march=i486"
+    CFLAGS="$CFLAGS -march=i486"
   fi
 fi
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:36:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7eR-0005Jh-CZ; Tue, 03 Apr 2012 17:36:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF7eP-0005JZ-Qb
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:36:14 +0000
Received: from [85.158.143.35:38328] by server-2.bemta-4.messagelabs.com id
	0D/55-17550-D053B7F4; Tue, 03 Apr 2012 17:36:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333474570!7287442!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25752 invoked from network); 3 Apr 2012 17:36:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 17:36:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333474570; l=2203;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Q7sSNhE9cqe/G59d8n8+D/39qnU=;
	b=neVTi70MIVSkxUAIAqLEissgVL9lxKI0Xvp9qEV8eGSYMCZcyhznW0aEMgKUguzQbnt
	r6oG1/sti0AbtaGEvNqVv3T72C+cqV/X6IAmNHScwcI+EWhYQ8UeM3oKCq8yudz/VppaT
	heCONda1glX+if+BXkkCCcX677s4D5lgMzc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (jimi mo55) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y02f2ao33GXuJI
	for <xen-devel@lists.xensource.com>;
	Tue, 3 Apr 2012 19:36:09 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 34C4818630
	for <xen-devel@lists.xensource.com>;
	Tue,  3 Apr 2012 19:36:09 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 7c0fd18a2ba52da307ba04859086c85ac83223ce
Message-Id: <7c0fd18a2ba52da307ba.1333474566@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 03 Apr 2012 19:36:06 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libvchan: fix build errors caused by
	Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333472656 -7200
# Node ID 7c0fd18a2ba52da307ba04859086c85ac83223ce
# Parent  1a0b5c53a3da2a47a98ec093b296616c4b22d810
tools/libvchan: fix build errors caused by Werror in io.c

-O2 -Wall -Werror triggers these warnings:

io.c: In function 'do_send':
io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
io.c: In function 'do_recv':
io.c:287: warning: ignoring return value of 'writev', declared with attribute warn_unused_result

writev to -1 will always fail, silence the warning by removing the offending
(disabled) debug code.

v3:
 - remove debug code
v2:
 - add comment about writev use case (see comment about strace in the code)

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1a0b5c53a3da -r 7c0fd18a2ba5 tools/libvchan/io.c
--- a/tools/libvchan/io.c
+++ b/tools/libvchan/io.c
@@ -49,11 +49,6 @@
 #define PAGE_SIZE 4096
 #endif
 
-// allow vchan data to be easily observed in strace by doing a
-// writev() to FD -1 with the data being read/written.
-#ifndef VCHAN_DEBUG
-#define VCHAN_DEBUG 0
-#endif
 
 static inline uint32_t rd_prod(struct libxenvchan *ctrl)
 {
@@ -186,15 +181,6 @@ static int do_send(struct libxenvchan *c
 {
 	int real_idx = wr_prod(ctrl) & (wr_ring_size(ctrl) - 1);
 	int avail_contig = wr_ring_size(ctrl) - real_idx;
-	if (VCHAN_DEBUG) {
-		char metainfo[32];
-		struct iovec iov[2];
-		iov[0].iov_base = metainfo;
-		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p wr", ctrl);
-		iov[1].iov_base = (void *)data;
-		iov[1].iov_len = size;
-		writev(-1, iov, 2);
-	}
 	if (avail_contig > size)
 		avail_contig = size;
 	xen_mb(); /* read indexes /then/ write data */
@@ -277,15 +263,6 @@ static int do_recv(struct libxenvchan *c
 	}
 	xen_mb(); /* consume /then/ notify */
 	rd_cons(ctrl) += size;
-	if (VCHAN_DEBUG) {
-		char metainfo[32];
-		struct iovec iov[2];
-		iov[0].iov_base = metainfo;
-		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p rd", ctrl);
-		iov[1].iov_base = data;
-		iov[1].iov_len = size;
-		writev(-1, iov, 2);
-	}
 	if (send_notify(ctrl, VCHAN_NOTIFY_READ))
 		return -1;
 	return size;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 17:36:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 17:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF7eR-0005Jh-CZ; Tue, 03 Apr 2012 17:36:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SF7eP-0005JZ-Qb
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 17:36:14 +0000
Received: from [85.158.143.35:38328] by server-2.bemta-4.messagelabs.com id
	0D/55-17550-D053B7F4; Tue, 03 Apr 2012 17:36:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333474570!7287442!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjkwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25752 invoked from network); 3 Apr 2012 17:36:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 17:36:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333474570; l=2203;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Q7sSNhE9cqe/G59d8n8+D/39qnU=;
	b=neVTi70MIVSkxUAIAqLEissgVL9lxKI0Xvp9qEV8eGSYMCZcyhznW0aEMgKUguzQbnt
	r6oG1/sti0AbtaGEvNqVv3T72C+cqV/X6IAmNHScwcI+EWhYQ8UeM3oKCq8yudz/VppaT
	heCONda1glX+if+BXkkCCcX677s4D5lgMzc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQF1/r
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-045.pools.arcor-ip.net [88.65.100.45])
	by smtp.strato.de (jimi mo55) (RZmta 28.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y02f2ao33GXuJI
	for <xen-devel@lists.xensource.com>;
	Tue, 3 Apr 2012 19:36:09 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 34C4818630
	for <xen-devel@lists.xensource.com>;
	Tue,  3 Apr 2012 19:36:09 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 7c0fd18a2ba52da307ba04859086c85ac83223ce
Message-Id: <7c0fd18a2ba52da307ba.1333474566@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 03 Apr 2012 19:36:06 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libvchan: fix build errors caused by
	Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1333472656 -7200
# Node ID 7c0fd18a2ba52da307ba04859086c85ac83223ce
# Parent  1a0b5c53a3da2a47a98ec093b296616c4b22d810
tools/libvchan: fix build errors caused by Werror in io.c

-O2 -Wall -Werror triggers these warnings:

io.c: In function 'do_send':
io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
io.c: In function 'do_recv':
io.c:287: warning: ignoring return value of 'writev', declared with attribute warn_unused_result

writev to -1 will always fail, silence the warning by removing the offending
(disabled) debug code.

v3:
 - remove debug code
v2:
 - add comment about writev use case (see comment about strace in the code)

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1a0b5c53a3da -r 7c0fd18a2ba5 tools/libvchan/io.c
--- a/tools/libvchan/io.c
+++ b/tools/libvchan/io.c
@@ -49,11 +49,6 @@
 #define PAGE_SIZE 4096
 #endif
 
-// allow vchan data to be easily observed in strace by doing a
-// writev() to FD -1 with the data being read/written.
-#ifndef VCHAN_DEBUG
-#define VCHAN_DEBUG 0
-#endif
 
 static inline uint32_t rd_prod(struct libxenvchan *ctrl)
 {
@@ -186,15 +181,6 @@ static int do_send(struct libxenvchan *c
 {
 	int real_idx = wr_prod(ctrl) & (wr_ring_size(ctrl) - 1);
 	int avail_contig = wr_ring_size(ctrl) - real_idx;
-	if (VCHAN_DEBUG) {
-		char metainfo[32];
-		struct iovec iov[2];
-		iov[0].iov_base = metainfo;
-		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p wr", ctrl);
-		iov[1].iov_base = (void *)data;
-		iov[1].iov_len = size;
-		writev(-1, iov, 2);
-	}
 	if (avail_contig > size)
 		avail_contig = size;
 	xen_mb(); /* read indexes /then/ write data */
@@ -277,15 +263,6 @@ static int do_recv(struct libxenvchan *c
 	}
 	xen_mb(); /* consume /then/ notify */
 	rd_cons(ctrl) += size;
-	if (VCHAN_DEBUG) {
-		char metainfo[32];
-		struct iovec iov[2];
-		iov[0].iov_base = metainfo;
-		iov[0].iov_len = snprintf(metainfo, 32, "vchan@%p rd", ctrl);
-		iov[1].iov_base = data;
-		iov[1].iov_len = size;
-		writev(-1, iov, 2);
-	}
 	if (send_notify(ctrl, VCHAN_NOTIFY_READ))
 		return -1;
 	return size;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:16:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8GB-0006Pe-UG; Tue, 03 Apr 2012 18:15:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF8GA-0006PZ-8D
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:15:14 +0000
Received: from [85.158.138.51:39066] by server-10.bemta-3.messagelabs.com id
	AE/AA-15637-13E3B7F4; Tue, 03 Apr 2012 18:15:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333476911!20466887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1258 invoked from network); 3 Apr 2012 18:15:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:15:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11753046"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 18:15:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 19:15:04 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SF8Fz-0006pp-Oi;
	Tue, 03 Apr 2012 18:15:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SF8Fz-0004TL-FR;
	Tue, 03 Apr 2012 19:15:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12557-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 19:15:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12557: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12557 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12557/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:16:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8GB-0006Pe-UG; Tue, 03 Apr 2012 18:15:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF8GA-0006PZ-8D
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:15:14 +0000
Received: from [85.158.138.51:39066] by server-10.bemta-3.messagelabs.com id
	AE/AA-15637-13E3B7F4; Tue, 03 Apr 2012 18:15:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333476911!20466887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1258 invoked from network); 3 Apr 2012 18:15:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:15:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11753046"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 18:15:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 19:15:04 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SF8Fz-0006pp-Oi;
	Tue, 03 Apr 2012 18:15:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SF8Fz-0004TL-FR;
	Tue, 03 Apr 2012 19:15:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12557-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 19:15:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12557: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12557 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12557/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ee-0006cp-1V; Tue, 03 Apr 2012 18:40:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8ec-0006cA-T2
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:31 +0000
Received: from [85.158.143.99:59437] by server-1.bemta-4.messagelabs.com id
	C4/44-20925-C144B7F4; Tue, 03 Apr 2012 18:40:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333478426!23644992!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14865 invoked from network); 3 Apr 2012 18:40:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188870982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:25 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8Vk-00068f-Vs;
	Tue, 03 Apr 2012 19:31:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0fb728d56baeaed476d218c1e31c7f70db2ca455
Message-ID: <0fb728d56baeaed476d2.1333477788@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:29:48 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since the key information can be fairly simply put on the command-line,
there's no need to require an actual config file.

Also improve the help to cross-reference the xlcpupool.cfg manpage.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 30cc13e25e01 -r 0fb728d56bae docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Apr 03 19:02:19 2012 +0100
+++ b/docs/man/xl.pod.1	Tue Apr 03 19:28:04 2012 +0100
@@ -848,11 +848,13 @@ Cpu-pools can be specified either by nam
 
 =over 4
 
-=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile> [I<Variable=Value> ...]
+=item B<cpupool-create> [I<OPTIONS>] [I<ConfigFile>] [I<Variable=Value> ...]
 
-Create a cpu pool based an I<ConfigFile>.
+Create a cpu pool based an config from a I<ConfigFile> or command-line parameters.
 Variable settings from the I<ConfigFile> may be altered by specifying new
-or additional assignments on the command line.
+or additional assignments on the command line.  
+
+See the xlcpupool.cfg manpage for more information.
 
 B<OPTIONS>
 
diff -r 30cc13e25e01 -r 0fb728d56bae tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:02:19 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:28:04 2012 +0100
@@ -5407,7 +5407,7 @@ int main_tmem_freeable(int argc, char **
 
 int main_cpupoolcreate(int argc, char **argv)
 {
-    const char *filename = NULL;
+    const char *filename = NULL, *config_src=NULL;
     const char *p;
     char extra_config[1024];
     int opt;
@@ -5471,23 +5471,26 @@ int main_cpupoolcreate(int argc, char **
         optind++;
     }
 
-    if (!filename) {
-        help("cpupool-create");
-        return -ERROR_FAIL;
-    }
-
-    if (libxl_read_file_contents(ctx, filename, (void **)&config_data, &config_len)) {
-        fprintf(stderr, "Failed to read config file: %s: %s\n",
-                filename, strerror(errno));
-        return -ERROR_FAIL;
-    }
+    if (filename)
+    {
+        if (libxl_read_file_contents(ctx, filename, (void **)&config_data,
+                                     &config_len)) {
+            fprintf(stderr, "Failed to read config file: %s: %s\n",
+                    filename, strerror(errno));
+            return -ERROR_FAIL;
+        }
+        config_src=filename;
+    }
+    else
+        config_src="command line";
+
     if (strlen(extra_config)) {
         if (config_len > INT_MAX - (strlen(extra_config) + 2)) {
             fprintf(stderr, "Failed to attach extra configration\n");
             return -ERROR_FAIL;
         }
         config_data = xrealloc(config_data,
-                              config_len + strlen(extra_config) + 2);
+                               config_len + strlen(extra_config) + 2);
         if (!config_data) {
             fprintf(stderr, "Failed to realloc config_data\n");
             return -ERROR_FAIL;
@@ -5498,7 +5501,7 @@ int main_cpupoolcreate(int argc, char **
         config_len += strlen(extra_config) + 1;
     }
 
-    config = xlu_cfg_init(stderr, filename);
+    config = xlu_cfg_init(stderr, config_src);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         return -ERROR_FAIL;
@@ -5512,8 +5515,12 @@ int main_cpupoolcreate(int argc, char **
 
     if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
-    else
+    else if (filename)
         name = libxl_basename(filename);
+    else {
+        fprintf(stderr, "Missing cpupool name!\n");
+        return -ERROR_FAIL;
+    }
     if (!libxl_name_to_cpupoolid(ctx, name, &poolid)) {
         fprintf(stderr, "Pool name \"%s\" already exists\n", name);
         return -ERROR_FAIL;
@@ -5595,7 +5602,7 @@ int main_cpupoolcreate(int argc, char **
 
     libxl_uuid_generate(&uuid);
 
-    printf("Using config file \"%s\"\n", filename);
+    printf("Using config file \"%s\"\n", config_src);
     printf("cpupool name:   %s\n", name);
     printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
diff -r 30cc13e25e01 -r 0fb728d56bae tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:02:19 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:28:04 2012 +0100
@@ -364,12 +364,14 @@ struct cmd_spec cmd_table[] = {
     },
     { "cpupool-create",
       &main_cpupoolcreate, 1,
-      "Create a CPU pool based an ConfigFile",
-      "[options] <ConfigFile> [vars]",
+      "Create a new CPU pool",
+      "[options] [<ConfigFile>] [Variable=value ...]",
       "-h, --help                   Print this help.\n"
       "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
       "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
-      "                              (deprecated in favour of global -N option)."
+      "                              (deprecated in favour of global -N option).\n"
+      "\nSee the xlcpupool.cfg manpage for more information.",
+
     },
     { "cpupool-list",
       &main_cpupoollist, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ee-0006cp-1V; Tue, 03 Apr 2012 18:40:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8ec-0006cA-T2
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:31 +0000
Received: from [85.158.143.99:59437] by server-1.bemta-4.messagelabs.com id
	C4/44-20925-C144B7F4; Tue, 03 Apr 2012 18:40:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333478426!23644992!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14865 invoked from network); 3 Apr 2012 18:40:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188870982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:25 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8Vk-00068f-Vs;
	Tue, 03 Apr 2012 19:31:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0fb728d56baeaed476d218c1e31c7f70db2ca455
Message-ID: <0fb728d56baeaed476d2.1333477788@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:29:48 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since the key information can be fairly simply put on the command-line,
there's no need to require an actual config file.

Also improve the help to cross-reference the xlcpupool.cfg manpage.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 30cc13e25e01 -r 0fb728d56bae docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Apr 03 19:02:19 2012 +0100
+++ b/docs/man/xl.pod.1	Tue Apr 03 19:28:04 2012 +0100
@@ -848,11 +848,13 @@ Cpu-pools can be specified either by nam
 
 =over 4
 
-=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile> [I<Variable=Value> ...]
+=item B<cpupool-create> [I<OPTIONS>] [I<ConfigFile>] [I<Variable=Value> ...]
 
-Create a cpu pool based an I<ConfigFile>.
+Create a cpu pool based an config from a I<ConfigFile> or command-line parameters.
 Variable settings from the I<ConfigFile> may be altered by specifying new
-or additional assignments on the command line.
+or additional assignments on the command line.  
+
+See the xlcpupool.cfg manpage for more information.
 
 B<OPTIONS>
 
diff -r 30cc13e25e01 -r 0fb728d56bae tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:02:19 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:28:04 2012 +0100
@@ -5407,7 +5407,7 @@ int main_tmem_freeable(int argc, char **
 
 int main_cpupoolcreate(int argc, char **argv)
 {
-    const char *filename = NULL;
+    const char *filename = NULL, *config_src=NULL;
     const char *p;
     char extra_config[1024];
     int opt;
@@ -5471,23 +5471,26 @@ int main_cpupoolcreate(int argc, char **
         optind++;
     }
 
-    if (!filename) {
-        help("cpupool-create");
-        return -ERROR_FAIL;
-    }
-
-    if (libxl_read_file_contents(ctx, filename, (void **)&config_data, &config_len)) {
-        fprintf(stderr, "Failed to read config file: %s: %s\n",
-                filename, strerror(errno));
-        return -ERROR_FAIL;
-    }
+    if (filename)
+    {
+        if (libxl_read_file_contents(ctx, filename, (void **)&config_data,
+                                     &config_len)) {
+            fprintf(stderr, "Failed to read config file: %s: %s\n",
+                    filename, strerror(errno));
+            return -ERROR_FAIL;
+        }
+        config_src=filename;
+    }
+    else
+        config_src="command line";
+
     if (strlen(extra_config)) {
         if (config_len > INT_MAX - (strlen(extra_config) + 2)) {
             fprintf(stderr, "Failed to attach extra configration\n");
             return -ERROR_FAIL;
         }
         config_data = xrealloc(config_data,
-                              config_len + strlen(extra_config) + 2);
+                               config_len + strlen(extra_config) + 2);
         if (!config_data) {
             fprintf(stderr, "Failed to realloc config_data\n");
             return -ERROR_FAIL;
@@ -5498,7 +5501,7 @@ int main_cpupoolcreate(int argc, char **
         config_len += strlen(extra_config) + 1;
     }
 
-    config = xlu_cfg_init(stderr, filename);
+    config = xlu_cfg_init(stderr, config_src);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         return -ERROR_FAIL;
@@ -5512,8 +5515,12 @@ int main_cpupoolcreate(int argc, char **
 
     if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
-    else
+    else if (filename)
         name = libxl_basename(filename);
+    else {
+        fprintf(stderr, "Missing cpupool name!\n");
+        return -ERROR_FAIL;
+    }
     if (!libxl_name_to_cpupoolid(ctx, name, &poolid)) {
         fprintf(stderr, "Pool name \"%s\" already exists\n", name);
         return -ERROR_FAIL;
@@ -5595,7 +5602,7 @@ int main_cpupoolcreate(int argc, char **
 
     libxl_uuid_generate(&uuid);
 
-    printf("Using config file \"%s\"\n", filename);
+    printf("Using config file \"%s\"\n", config_src);
     printf("cpupool name:   %s\n", name);
     printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
diff -r 30cc13e25e01 -r 0fb728d56bae tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:02:19 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:28:04 2012 +0100
@@ -364,12 +364,14 @@ struct cmd_spec cmd_table[] = {
     },
     { "cpupool-create",
       &main_cpupoolcreate, 1,
-      "Create a CPU pool based an ConfigFile",
-      "[options] <ConfigFile> [vars]",
+      "Create a new CPU pool",
+      "[options] [<ConfigFile>] [Variable=value ...]",
       "-h, --help                   Print this help.\n"
       "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
       "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
-      "                              (deprecated in favour of global -N option)."
+      "                              (deprecated in favour of global -N option).\n"
+      "\nSee the xlcpupool.cfg manpage for more information.",
+
     },
     { "cpupool-list",
       &main_cpupoollist, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ed-0006ca-Gn; Tue, 03 Apr 2012 18:40:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8ec-0006cC-Ci
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:30 +0000
Received: from [85.158.143.99:59473] by server-3.bemta-4.messagelabs.com id
	A4/B4-05853-D144B7F4; Tue, 03 Apr 2012 18:40:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333478426!23644992!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14882 invoked from network); 3 Apr 2012 18:40:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188870983"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:25 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8VN-00068T-KI;
	Tue, 03 Apr 2012 19:30:57 +0100
MIME-Version: 1.0
X-Mercurial-Node: 30cc13e25e015fa0a0479e02db832ced15fec722
Message-ID: <30cc13e25e015fa0a047.1333477722@kodo2>
In-Reply-To: <patchbomb.1333477720@kodo2>
References: <patchbomb.1333477720@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:28:42 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between
 "filename" and "data source"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Many places in xl there's a variable or element named "filename" which
does not contain a filename, but the source of the data for reporting
purposes.  Worse, there are variables which are sometimes actually
used or interpreted as a filename depending on what other variables
are set.  This makes it difficult to tell when a string is purely
cosmetic, and when another bit of code may actually attempt to call
"open" with the string.

This patch makes a consistent distinction between "filename" (which
always refers to the name of an actual file, and may be interpreted as
such at some point) and "source" (which may be a filename, or may be
another data source such as a migration stream or saved data).

This does add some variables and reshuffle where assignments happen;
most notably, the "restore_filename" element of struct domain_create
is now only set when restoring from a file.

But at a high level, there should be no funcitonal changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Tue Apr 03 18:00:24 2012 +0100
+++ b/tools/libxl/libxl_utils.c	Tue Apr 03 19:02:19 2012 +0100
@@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx *
                                                                           \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd,                 \
                            constdata void *data, ssize_t sz,              \
-                           const char *filename, const char *what) {      \
+                           const char *source, const char *what) {      \
       ssize_t got;                                                        \
                                                                           \
       while (sz > 0) {                                                    \
@@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx *
               if (errno == EINTR) continue;                               \
               if (!ctx) return errno;                                     \
               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to " #rw " %s%s%s", \
-                           what?what:"", what?" from ":"", filename);     \
+                           what?what:"", what?" from ":"", source);       \
               return errno;                                               \
           }                                                               \
           if (got == 0) {                                                 \
@@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx *
                      zero_is_eof                                          \
                      ? "file/stream truncated reading %s%s%s"             \
                      : "file/stream write returned 0! writing %s%s%s",    \
-                     what?what:"", what?" from ":"", filename);           \
+                     what?what:"", what?" from ":"", source);             \
               return EPROTO;                                              \
           }                                                               \
           sz -= got;                                                      \
diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Apr 03 18:00:24 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:02:19 2012 +0100
@@ -507,9 +507,9 @@ vcpp_out:
     return rc;
 }
 
-static void parse_config_data(const char *configfile_filename_report,
-                              const char *configfile_data,
-                              int configfile_len,
+static void parse_config_data(const char *config_source,
+                              const char *config_data,
+                              int config_len,
                               libxl_domain_config *d_config)
 {
     const char *buf;
@@ -524,15 +524,15 @@ static void parse_config_data(const char
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
-    config= xlu_cfg_init(stderr, configfile_filename_report);
+    config= xlu_cfg_init(stderr, config_source);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         exit(1);
     }
 
-    e= xlu_cfg_readdata(config, configfile_data, configfile_len);
+    e= xlu_cfg_readdata(config, config_data, config_len);
     if (e) {
-        fprintf(stderr, "Failed to parse config file: %s\n", strerror(e));
+        fprintf(stderr, "Failed to parse config: %s\n", strerror(e));
         exit(1);
     }
 
@@ -1467,6 +1467,8 @@ static int create_domain(struct domain_c
     const char *config_file = dom_info->config_file;
     const char *extra_config = dom_info->extra_config;
     const char *restore_file = dom_info->restore_file;
+    const char *config_source = NULL;
+    const char *restore_source = NULL;
     int migrate_fd = dom_info->migrate_fd;
 
     int i;
@@ -1482,24 +1484,28 @@ static int create_domain(struct domain_c
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
+    int restoring = (restore_file || (migrate_fd >= 0));
+
     memset(&d_config, 0x00, sizeof(d_config));
 
-    if (restore_file) {
+    if (restoring) {
         uint8_t *optdata_begin = 0;
         const uint8_t *optdata_here = 0;
         union { uint32_t u32; char b[4]; } u32buf;
         uint32_t badflags;
 
         if (migrate_fd >= 0) {
+            restore_source = "incoming migration stream";
             restore_fd = migrate_fd;
         } else {
+            restore_source = restore_file;
             restore_fd = open(restore_file, O_RDONLY);
             rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
             if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-                   sizeof(hdr), restore_file, "header") );
+                   sizeof(hdr), restore_source, "header") );
         if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.magic))) {
             fprintf(stderr, "File has wrong magic number -"
                     " corrupt or for a different tool?\n");
@@ -1512,7 +1518,7 @@ static int create_domain(struct domain_c
         fprintf(stderr, "Loading new save file %s"
                 " (new xl fmt info"
                 " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
-                restore_file, hdr.mandatory_flags, hdr.optional_flags,
+                restore_source, hdr.mandatory_flags, hdr.optional_flags,
                 hdr.optional_data_len);
 
         badflags = hdr.mandatory_flags & ~( 0 /* none understood yet */ );
@@ -1525,7 +1531,7 @@ static int create_domain(struct domain_c
         if (hdr.optional_data_len) {
             optdata_begin = xmalloc(hdr.optional_data_len);
             CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, optdata_begin,
-                   hdr.optional_data_len, restore_file, "optdata") );
+                   hdr.optional_data_len, restore_source, "optdata") );
         }
 
 #define OPTDATA_LEFT  (hdr.optional_data_len - (optdata_here - optdata_begin))
@@ -1560,7 +1566,7 @@ static int create_domain(struct domain_c
                                        &config_data, &config_len);
         if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
                            config_file, strerror(errno)); return ERROR_FAIL; }
-        if (!restore_file && extra_config && strlen(extra_config)) {
+        if (!restoring && extra_config && strlen(extra_config)) {
             if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
                 fprintf(stderr, "Failed to attach extra configration\n");
                 return ERROR_FAIL;
@@ -1575,19 +1581,20 @@ static int create_domain(struct domain_c
             config_len += sprintf(config_data + config_len, "\n%s\n",
                 extra_config);
         }
+        config_source=config_file;
     } else {
         if (!config_data) {
             fprintf(stderr, "Config file not specified and"
                     " none in save file\n");
             return ERROR_INVAL;
         }
-        config_file = "<saved>";
+        config_source = "<saved>";
     }
 
     if (!dom_info->quiet)
-        printf("Parsing config file %s\n", config_file);
-
-    parse_config_data(config_file, config_data, config_len, &d_config);
+        printf("Parsing config from %s\n", config_source);
+
+    parse_config_data(config_source, config_data, config_len, &d_config);
 
     if (migrate_fd >= 0) {
         if (d_config.c_info.name) {
@@ -1638,7 +1645,7 @@ start:
         cb = NULL;
     }
 
-    if ( restore_file ) {
+    if ( restoring ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
                                             cb, &child_console_pid,
                                             &domid, restore_fd);
@@ -2410,7 +2417,7 @@ static void list_domains_details(const l
 {
     libxl_domain_config d_config;
 
-    char *config_file;
+    char *config_source;
     uint8_t *data;
     int i, len, rc;
 
@@ -2421,13 +2428,13 @@ static void list_domains_details(const l
         rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
         if (rc)
             continue;
-        CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
+        CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
-        parse_config_data(config_file, (char *)data, len, &d_config);
+        parse_config_data(config_source, (char *)data, len, &d_config);
         printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
-        free(config_file);
+        free(config_source);
     }
 }
 
@@ -2530,7 +2537,7 @@ static void save_domain_core_begin(const
     }
 }
 
-static void save_domain_core_writeconfig(int fd, const char *filename,
+static void save_domain_core_writeconfig(int fd, const char *source,
                                   const uint8_t *config_data, int config_len)
 {
     struct save_file_header hdr;
@@ -2559,13 +2566,13 @@ static void save_domain_core_writeconfig
     /* that's the optional data */
 
     CHK_ERRNO( libxl_write_exactly(ctx, fd,
-        &hdr, sizeof(hdr), filename, "header") );
+        &hdr, sizeof(hdr), source, "header") );
     CHK_ERRNO( libxl_write_exactly(ctx, fd,
-        optdata_begin, hdr.optional_data_len, filename, "header") );
+        optdata_begin, hdr.optional_data_len, source, "header") );
 
     fprintf(stderr, "Saving to %s new xl format (info"
             " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
-            filename, hdr.mandatory_flags, hdr.optional_flags,
+            source, hdr.mandatory_flags, hdr.optional_flags,
             hdr.optional_data_len);
 }
 
@@ -2891,7 +2898,6 @@ static void migrate_receive(int debug, i
     dom_info.daemonize = daemonize;
     dom_info.monitor = monitor;
     dom_info.paused = 1;
-    dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
     dom_info.incr_generationid = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ed-0006ca-Gn; Tue, 03 Apr 2012 18:40:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8ec-0006cC-Ci
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:30 +0000
Received: from [85.158.143.99:59473] by server-3.bemta-4.messagelabs.com id
	A4/B4-05853-D144B7F4; Tue, 03 Apr 2012 18:40:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333478426!23644992!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14882 invoked from network); 3 Apr 2012 18:40:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188870983"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:25 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8VN-00068T-KI;
	Tue, 03 Apr 2012 19:30:57 +0100
MIME-Version: 1.0
X-Mercurial-Node: 30cc13e25e015fa0a0479e02db832ced15fec722
Message-ID: <30cc13e25e015fa0a047.1333477722@kodo2>
In-Reply-To: <patchbomb.1333477720@kodo2>
References: <patchbomb.1333477720@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:28:42 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between
 "filename" and "data source"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Many places in xl there's a variable or element named "filename" which
does not contain a filename, but the source of the data for reporting
purposes.  Worse, there are variables which are sometimes actually
used or interpreted as a filename depending on what other variables
are set.  This makes it difficult to tell when a string is purely
cosmetic, and when another bit of code may actually attempt to call
"open" with the string.

This patch makes a consistent distinction between "filename" (which
always refers to the name of an actual file, and may be interpreted as
such at some point) and "source" (which may be a filename, or may be
another data source such as a migration stream or saved data).

This does add some variables and reshuffle where assignments happen;
most notably, the "restore_filename" element of struct domain_create
is now only set when restoring from a file.

But at a high level, there should be no funcitonal changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Tue Apr 03 18:00:24 2012 +0100
+++ b/tools/libxl/libxl_utils.c	Tue Apr 03 19:02:19 2012 +0100
@@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx *
                                                                           \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd,                 \
                            constdata void *data, ssize_t sz,              \
-                           const char *filename, const char *what) {      \
+                           const char *source, const char *what) {      \
       ssize_t got;                                                        \
                                                                           \
       while (sz > 0) {                                                    \
@@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx *
               if (errno == EINTR) continue;                               \
               if (!ctx) return errno;                                     \
               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to " #rw " %s%s%s", \
-                           what?what:"", what?" from ":"", filename);     \
+                           what?what:"", what?" from ":"", source);       \
               return errno;                                               \
           }                                                               \
           if (got == 0) {                                                 \
@@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx *
                      zero_is_eof                                          \
                      ? "file/stream truncated reading %s%s%s"             \
                      : "file/stream write returned 0! writing %s%s%s",    \
-                     what?what:"", what?" from ":"", filename);           \
+                     what?what:"", what?" from ":"", source);             \
               return EPROTO;                                              \
           }                                                               \
           sz -= got;                                                      \
diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Apr 03 18:00:24 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:02:19 2012 +0100
@@ -507,9 +507,9 @@ vcpp_out:
     return rc;
 }
 
-static void parse_config_data(const char *configfile_filename_report,
-                              const char *configfile_data,
-                              int configfile_len,
+static void parse_config_data(const char *config_source,
+                              const char *config_data,
+                              int config_len,
                               libxl_domain_config *d_config)
 {
     const char *buf;
@@ -524,15 +524,15 @@ static void parse_config_data(const char
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
-    config= xlu_cfg_init(stderr, configfile_filename_report);
+    config= xlu_cfg_init(stderr, config_source);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         exit(1);
     }
 
-    e= xlu_cfg_readdata(config, configfile_data, configfile_len);
+    e= xlu_cfg_readdata(config, config_data, config_len);
     if (e) {
-        fprintf(stderr, "Failed to parse config file: %s\n", strerror(e));
+        fprintf(stderr, "Failed to parse config: %s\n", strerror(e));
         exit(1);
     }
 
@@ -1467,6 +1467,8 @@ static int create_domain(struct domain_c
     const char *config_file = dom_info->config_file;
     const char *extra_config = dom_info->extra_config;
     const char *restore_file = dom_info->restore_file;
+    const char *config_source = NULL;
+    const char *restore_source = NULL;
     int migrate_fd = dom_info->migrate_fd;
 
     int i;
@@ -1482,24 +1484,28 @@ static int create_domain(struct domain_c
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
+    int restoring = (restore_file || (migrate_fd >= 0));
+
     memset(&d_config, 0x00, sizeof(d_config));
 
-    if (restore_file) {
+    if (restoring) {
         uint8_t *optdata_begin = 0;
         const uint8_t *optdata_here = 0;
         union { uint32_t u32; char b[4]; } u32buf;
         uint32_t badflags;
 
         if (migrate_fd >= 0) {
+            restore_source = "incoming migration stream";
             restore_fd = migrate_fd;
         } else {
+            restore_source = restore_file;
             restore_fd = open(restore_file, O_RDONLY);
             rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
             if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-                   sizeof(hdr), restore_file, "header") );
+                   sizeof(hdr), restore_source, "header") );
         if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.magic))) {
             fprintf(stderr, "File has wrong magic number -"
                     " corrupt or for a different tool?\n");
@@ -1512,7 +1518,7 @@ static int create_domain(struct domain_c
         fprintf(stderr, "Loading new save file %s"
                 " (new xl fmt info"
                 " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
-                restore_file, hdr.mandatory_flags, hdr.optional_flags,
+                restore_source, hdr.mandatory_flags, hdr.optional_flags,
                 hdr.optional_data_len);
 
         badflags = hdr.mandatory_flags & ~( 0 /* none understood yet */ );
@@ -1525,7 +1531,7 @@ static int create_domain(struct domain_c
         if (hdr.optional_data_len) {
             optdata_begin = xmalloc(hdr.optional_data_len);
             CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, optdata_begin,
-                   hdr.optional_data_len, restore_file, "optdata") );
+                   hdr.optional_data_len, restore_source, "optdata") );
         }
 
 #define OPTDATA_LEFT  (hdr.optional_data_len - (optdata_here - optdata_begin))
@@ -1560,7 +1566,7 @@ static int create_domain(struct domain_c
                                        &config_data, &config_len);
         if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
                            config_file, strerror(errno)); return ERROR_FAIL; }
-        if (!restore_file && extra_config && strlen(extra_config)) {
+        if (!restoring && extra_config && strlen(extra_config)) {
             if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
                 fprintf(stderr, "Failed to attach extra configration\n");
                 return ERROR_FAIL;
@@ -1575,19 +1581,20 @@ static int create_domain(struct domain_c
             config_len += sprintf(config_data + config_len, "\n%s\n",
                 extra_config);
         }
+        config_source=config_file;
     } else {
         if (!config_data) {
             fprintf(stderr, "Config file not specified and"
                     " none in save file\n");
             return ERROR_INVAL;
         }
-        config_file = "<saved>";
+        config_source = "<saved>";
     }
 
     if (!dom_info->quiet)
-        printf("Parsing config file %s\n", config_file);
-
-    parse_config_data(config_file, config_data, config_len, &d_config);
+        printf("Parsing config from %s\n", config_source);
+
+    parse_config_data(config_source, config_data, config_len, &d_config);
 
     if (migrate_fd >= 0) {
         if (d_config.c_info.name) {
@@ -1638,7 +1645,7 @@ start:
         cb = NULL;
     }
 
-    if ( restore_file ) {
+    if ( restoring ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
                                             cb, &child_console_pid,
                                             &domid, restore_fd);
@@ -2410,7 +2417,7 @@ static void list_domains_details(const l
 {
     libxl_domain_config d_config;
 
-    char *config_file;
+    char *config_source;
     uint8_t *data;
     int i, len, rc;
 
@@ -2421,13 +2428,13 @@ static void list_domains_details(const l
         rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
         if (rc)
             continue;
-        CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
+        CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
-        parse_config_data(config_file, (char *)data, len, &d_config);
+        parse_config_data(config_source, (char *)data, len, &d_config);
         printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
-        free(config_file);
+        free(config_source);
     }
 }
 
@@ -2530,7 +2537,7 @@ static void save_domain_core_begin(const
     }
 }
 
-static void save_domain_core_writeconfig(int fd, const char *filename,
+static void save_domain_core_writeconfig(int fd, const char *source,
                                   const uint8_t *config_data, int config_len)
 {
     struct save_file_header hdr;
@@ -2559,13 +2566,13 @@ static void save_domain_core_writeconfig
     /* that's the optional data */
 
     CHK_ERRNO( libxl_write_exactly(ctx, fd,
-        &hdr, sizeof(hdr), filename, "header") );
+        &hdr, sizeof(hdr), source, "header") );
     CHK_ERRNO( libxl_write_exactly(ctx, fd,
-        optdata_begin, hdr.optional_data_len, filename, "header") );
+        optdata_begin, hdr.optional_data_len, source, "header") );
 
     fprintf(stderr, "Saving to %s new xl format (info"
             " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
-            filename, hdr.mandatory_flags, hdr.optional_flags,
+            source, hdr.mandatory_flags, hdr.optional_flags,
             hdr.optional_data_len);
 }
 
@@ -2891,7 +2898,6 @@ static void migrate_receive(int debug, i
     dom_info.daemonize = daemonize;
     dom_info.monitor = monitor;
     dom_info.paused = 1;
-    dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
     dom_info.incr_generationid = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ee-0006cy-EP; Tue, 03 Apr 2012 18:40:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8ed-0006cC-0r
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:31 +0000
Received: from [85.158.143.99:20086] by server-3.bemta-4.messagelabs.com id
	46/B4-05853-E144B7F4; Tue, 03 Apr 2012 18:40:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333478426!23644992!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14907 invoked from network); 3 Apr 2012 18:40:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188870986"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:26 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8VN-00068T-JH;
	Tue, 03 Apr 2012 19:30:57 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333477720@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:28:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl cleanup: distinguish filenames
	from sources
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ee-0006cy-EP; Tue, 03 Apr 2012 18:40:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8ed-0006cC-0r
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:31 +0000
Received: from [85.158.143.99:20086] by server-3.bemta-4.messagelabs.com id
	46/B4-05853-E144B7F4; Tue, 03 Apr 2012 18:40:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333478426!23644992!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14907 invoked from network); 3 Apr 2012 18:40:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188870986"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:26 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8VN-00068T-JH;
	Tue, 03 Apr 2012 19:30:57 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333477720@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:28:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl cleanup: distinguish filenames
	from sources
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ed-0006cQ-5w; Tue, 03 Apr 2012 18:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8eb-0006cB-Mi
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:29 +0000
Received: from [85.158.139.83:25436] by server-2.bemta-5.messagelabs.com id
	3C/0C-17016-C144B7F4; Tue, 03 Apr 2012 18:40:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333478426!14991593!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5250 invoked from network); 3 Apr 2012 18:40:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23832317"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:25 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8VN-00068T-Jp;
	Tue, 03 Apr 2012 19:30:57 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5ca90c805046b88d6f0325d46bf2d0e8ae9091b5
Message-ID: <5ca90c805046b88d6f03.1333477721@kodo2>
In-Reply-To: <patchbomb.1333477720@kodo2>
References: <patchbomb.1333477720@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:28:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxlu: Rename filename to config_source
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The "filename" is a bit of a misnomer, as it's only used during error
messages, and in most instances cases is actually set to "command
line".

Rename it to "config_source" to make it clear that it's not used to
actually open any files.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0625fe50a2ee -r 5ca90c805046 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Apr 03 14:46:27 2012 +0100
+++ b/tools/libxl/libxlu_cfg.c	Tue Apr 03 18:00:24 2012 +0100
@@ -25,15 +25,15 @@
 #include "libxlu_cfg_l.h"
 #include "libxlu_cfg_i.h"
 
-XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename) {
+XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) {
     XLU_Config *cfg;
 
     cfg= malloc(sizeof(*cfg));
     if (!cfg) return 0;
 
     cfg->report= report;
-    cfg->filename= strdup(report_filename);
-    if (!cfg->filename) { free(cfg); return 0; }
+    cfg->config_source= strdup(report_source);
+    if (!cfg->config_source) { free(cfg); return 0; }
 
     cfg->settings= 0;
     return cfg;
@@ -51,7 +51,7 @@ static int ctx_prep(CfgParseContext *ctx
     e= xlu__cfg_yylex_init_extra(ctx, &ctx->scanner);
     if (e) {
         fprintf(cfg->report,"%s: unable to create scanner: %s\n",
-                cfg->filename, strerror(e));
+                cfg->config_source, strerror(e));
         return e;
     }
     return 0;
@@ -117,7 +117,7 @@ int xlu_cfg_readdata(XLU_Config *cfg, co
     buf = xlu__cfg_yy_scan_bytes(data, length, ctx.scanner);
     if (!buf) {
         fprintf(cfg->report,"%s: unable to allocate scanner buffer\n",
-                cfg->filename);
+                cfg->config_source);
         ctx.err= ENOMEM;
         goto xe;
     }
@@ -151,7 +151,7 @@ void xlu_cfg_destroy(XLU_Config *cfg) {
         set_next= set->next;
         xlu__cfg_set_free(set);
     }
-    free(cfg->filename);
+    free(cfg->config_source);
     free(cfg);
 }
 
@@ -178,7 +178,7 @@ static int find_atom(const XLU_Config *c
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is"
                     " a list but should be a single value\n",
-                    cfg->filename, set->lineno, n);
+                    cfg->config_source, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -223,14 +223,14 @@ int xlu_cfg_get_long(const XLU_Config *c
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' could not be parsed"
                     " as a number: %s\n",
-                    cfg->filename, set->lineno, n, strerror(e));
+                    cfg->config_source, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
         if (!dont_warn)
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is not a valid number\n",
-                    cfg->filename, set->lineno, n);
+                    cfg->config_source, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
@@ -258,7 +258,7 @@ int xlu_cfg_get_list(const XLU_Config *c
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is a single value"
                     " but should be a list\n",
-                    cfg->filename, set->lineno, n);
+                    cfg->config_source, set->lineno, n);
         }
         return EINVAL;
     }
@@ -467,7 +467,7 @@ void xlu__cfg_yyerror(YYLTYPE *loc, CfgP
 
     fprintf(ctx->cfg->report,
             "%s:%d: config parsing error near %s%.*s%s%s: %s\n",
-            ctx->cfg->filename, lineno,
+            ctx->cfg->config_source, lineno,
             len?"`":"", len, text, len?"'":"", newline,
             msg);
     if (!ctx->err) ctx->err= EINVAL;
diff -r 0625fe50a2ee -r 5ca90c805046 tools/libxl/libxlu_disk.c
--- a/tools/libxl/libxlu_disk.c	Tue Apr 03 14:46:27 2012 +0100
+++ b/tools/libxl/libxlu_disk.c	Tue Apr 03 18:00:24 2012 +0100
@@ -10,7 +10,7 @@ void xlu__disk_err(DiskParseContext *dpc
             "%s: config parsing error in disk specification: %s"
             "%s%s%s"
             " in `%s'\n",
-            dpc->cfg->filename, message,
+            dpc->cfg->config_source, message,
             erroneous?": near `":"", erroneous?erroneous:"", erroneous?"'":"",
             dpc->spec);
     if (!dpc->err) dpc->err= EINVAL;
diff -r 0625fe50a2ee -r 5ca90c805046 tools/libxl/libxlu_internal.h
--- a/tools/libxl/libxlu_internal.h	Tue Apr 03 14:46:27 2012 +0100
+++ b/tools/libxl/libxlu_internal.h	Tue Apr 03 18:00:24 2012 +0100
@@ -36,7 +36,7 @@ struct XLU_ConfigSetting { /* transparen
 struct XLU_Config {
     XLU_ConfigSetting *settings;
     FILE *report;
-    char *filename;
+    char *config_source;
 };
 
 typedef struct {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8ed-0006cQ-5w; Tue, 03 Apr 2012 18:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8eb-0006cB-Mi
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:40:29 +0000
Received: from [85.158.139.83:25436] by server-2.bemta-5.messagelabs.com id
	3C/0C-17016-C144B7F4; Tue, 03 Apr 2012 18:40:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333478426!14991593!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5250 invoked from network); 3 Apr 2012 18:40:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="23832317"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:40:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:40:25 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SF8VN-00068T-Jp;
	Tue, 03 Apr 2012 19:30:57 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5ca90c805046b88d6f0325d46bf2d0e8ae9091b5
Message-ID: <5ca90c805046b88d6f03.1333477721@kodo2>
In-Reply-To: <patchbomb.1333477720@kodo2>
References: <patchbomb.1333477720@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 3 Apr 2012 19:28:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxlu: Rename filename to config_source
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The "filename" is a bit of a misnomer, as it's only used during error
messages, and in most instances cases is actually set to "command
line".

Rename it to "config_source" to make it clear that it's not used to
actually open any files.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0625fe50a2ee -r 5ca90c805046 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Apr 03 14:46:27 2012 +0100
+++ b/tools/libxl/libxlu_cfg.c	Tue Apr 03 18:00:24 2012 +0100
@@ -25,15 +25,15 @@
 #include "libxlu_cfg_l.h"
 #include "libxlu_cfg_i.h"
 
-XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename) {
+XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) {
     XLU_Config *cfg;
 
     cfg= malloc(sizeof(*cfg));
     if (!cfg) return 0;
 
     cfg->report= report;
-    cfg->filename= strdup(report_filename);
-    if (!cfg->filename) { free(cfg); return 0; }
+    cfg->config_source= strdup(report_source);
+    if (!cfg->config_source) { free(cfg); return 0; }
 
     cfg->settings= 0;
     return cfg;
@@ -51,7 +51,7 @@ static int ctx_prep(CfgParseContext *ctx
     e= xlu__cfg_yylex_init_extra(ctx, &ctx->scanner);
     if (e) {
         fprintf(cfg->report,"%s: unable to create scanner: %s\n",
-                cfg->filename, strerror(e));
+                cfg->config_source, strerror(e));
         return e;
     }
     return 0;
@@ -117,7 +117,7 @@ int xlu_cfg_readdata(XLU_Config *cfg, co
     buf = xlu__cfg_yy_scan_bytes(data, length, ctx.scanner);
     if (!buf) {
         fprintf(cfg->report,"%s: unable to allocate scanner buffer\n",
-                cfg->filename);
+                cfg->config_source);
         ctx.err= ENOMEM;
         goto xe;
     }
@@ -151,7 +151,7 @@ void xlu_cfg_destroy(XLU_Config *cfg) {
         set_next= set->next;
         xlu__cfg_set_free(set);
     }
-    free(cfg->filename);
+    free(cfg->config_source);
     free(cfg);
 }
 
@@ -178,7 +178,7 @@ static int find_atom(const XLU_Config *c
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is"
                     " a list but should be a single value\n",
-                    cfg->filename, set->lineno, n);
+                    cfg->config_source, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -223,14 +223,14 @@ int xlu_cfg_get_long(const XLU_Config *c
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' could not be parsed"
                     " as a number: %s\n",
-                    cfg->filename, set->lineno, n, strerror(e));
+                    cfg->config_source, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
         if (!dont_warn)
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is not a valid number\n",
-                    cfg->filename, set->lineno, n);
+                    cfg->config_source, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
@@ -258,7 +258,7 @@ int xlu_cfg_get_list(const XLU_Config *c
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is a single value"
                     " but should be a list\n",
-                    cfg->filename, set->lineno, n);
+                    cfg->config_source, set->lineno, n);
         }
         return EINVAL;
     }
@@ -467,7 +467,7 @@ void xlu__cfg_yyerror(YYLTYPE *loc, CfgP
 
     fprintf(ctx->cfg->report,
             "%s:%d: config parsing error near %s%.*s%s%s: %s\n",
-            ctx->cfg->filename, lineno,
+            ctx->cfg->config_source, lineno,
             len?"`":"", len, text, len?"'":"", newline,
             msg);
     if (!ctx->err) ctx->err= EINVAL;
diff -r 0625fe50a2ee -r 5ca90c805046 tools/libxl/libxlu_disk.c
--- a/tools/libxl/libxlu_disk.c	Tue Apr 03 14:46:27 2012 +0100
+++ b/tools/libxl/libxlu_disk.c	Tue Apr 03 18:00:24 2012 +0100
@@ -10,7 +10,7 @@ void xlu__disk_err(DiskParseContext *dpc
             "%s: config parsing error in disk specification: %s"
             "%s%s%s"
             " in `%s'\n",
-            dpc->cfg->filename, message,
+            dpc->cfg->config_source, message,
             erroneous?": near `":"", erroneous?erroneous:"", erroneous?"'":"",
             dpc->spec);
     if (!dpc->err) dpc->err= EINVAL;
diff -r 0625fe50a2ee -r 5ca90c805046 tools/libxl/libxlu_internal.h
--- a/tools/libxl/libxlu_internal.h	Tue Apr 03 14:46:27 2012 +0100
+++ b/tools/libxl/libxlu_internal.h	Tue Apr 03 18:00:24 2012 +0100
@@ -36,7 +36,7 @@ struct XLU_ConfigSetting { /* transparen
 struct XLU_Config {
     XLU_ConfigSetting *settings;
     FILE *report;
-    char *filename;
+    char *config_source;
 };
 
 typedef struct {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8mc-0007Cc-DP; Tue, 03 Apr 2012 18:48:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SF8mb-0007CX-Ek
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 18:48:45 +0000
Received: from [85.158.143.99:9685] by server-3.bemta-4.messagelabs.com id
	47/1B-05853-C064B7F4; Tue, 03 Apr 2012 18:48:44 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333478922!12562400!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzQ2OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32650 invoked from network); 3 Apr 2012 18:48:43 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:48:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="212851700"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2012 18:48:41 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.61.112.123])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q33Ime8F009492; Tue, 3 Apr 2012 18:48:40 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Tue, 03 Apr 2012 11:48:51 -0700
Date: Tue, 3 Apr 2012 11:48:51 -0700
From: Matt Wilson <msw@amazon.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120403184851.GA8916@US-SEA-R8XVZTX>
References: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
	<20120325170728.GP4316@type.famille.thibault.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120325170728.GP4316@type.famille.thibault.fr>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 and
	btrfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Mar 25, 2012 at 10:07:28AM -0700, Samuel Thibault wrote:
> Matt Wilson, le Tue 20 Mar 2012 18:47:46 +0000, a =E9crit :
> > Changes from v1:
> >  - Makefile has been changed to check the exit code from patch
> =

> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> >  - The btrfs patch has been rebased to apply cleanly
> >  - The patch file names have been adjusted to match existing patches
>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

I haven't seen these changes land in staging yet. Is anything blocked
on me?

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8mc-0007Cc-DP; Tue, 03 Apr 2012 18:48:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SF8mb-0007CX-Ek
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 18:48:45 +0000
Received: from [85.158.143.99:9685] by server-3.bemta-4.messagelabs.com id
	47/1B-05853-C064B7F4; Tue, 03 Apr 2012 18:48:44 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333478922!12562400!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzQ2OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32650 invoked from network); 3 Apr 2012 18:48:43 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:48:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="212851700"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2012 18:48:41 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.61.112.123])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q33Ime8F009492; Tue, 3 Apr 2012 18:48:40 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Tue, 03 Apr 2012 11:48:51 -0700
Date: Tue, 3 Apr 2012 11:48:51 -0700
From: Matt Wilson <msw@amazon.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120403184851.GA8916@US-SEA-R8XVZTX>
References: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
	<20120325170728.GP4316@type.famille.thibault.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120325170728.GP4316@type.famille.thibault.fr>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 and
	btrfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Mar 25, 2012 at 10:07:28AM -0700, Samuel Thibault wrote:
> Matt Wilson, le Tue 20 Mar 2012 18:47:46 +0000, a =E9crit :
> > Changes from v1:
> >  - Makefile has been changed to check the exit code from patch
> =

> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> >  - The btrfs patch has been rebased to apply cleanly
> >  - The patch file names have been adjusted to match existing patches
>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

I haven't seen these changes land in staging yet. Is anything blocked
on me?

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:53:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:53:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8rA-0007Kl-3o; Tue, 03 Apr 2012 18:53:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8r8-0007Kg-1U
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:53:26 +0000
Received: from [85.158.138.51:51773] by server-4.bemta-3.messagelabs.com id
	DB/D0-16467-5274B7F4; Tue, 03 Apr 2012 18:53:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333479201!18834076!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10513 invoked from network); 3 Apr 2012 18:53:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:53:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188873073"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:53:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:53:10 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SF8qr-0006W6-UT	for
	xen-devel@lists.xensource.com; Tue, 03 Apr 2012 19:53:09 +0100
Message-ID: <4F7B46FA.3070401@eu.citrix.com>
Date: Tue, 3 Apr 2012 19:52:42 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1333477720@kodo2>
	<30cc13e25e015fa0a047.1333477722@kodo2>
In-Reply-To: <30cc13e25e015fa0a047.1333477722@kodo2>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between
 "filename" and "data source"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/04/12 19:28, George Dunlap wrote:
> Many places in xl there's a variable or element named "filename" which
> does not contain a filename, but the source of the data for reporting
> purposes.  Worse, there are variables which are sometimes actually
> used or interpreted as a filename depending on what other variables
> are set.  This makes it difficult to tell when a string is purely
> cosmetic, and when another bit of code may actually attempt to call
> "open" with the string.
>
> This patch makes a consistent distinction between "filename" (which
> always refers to the name of an actual file, and may be interpreted as
> such at some point) and "source" (which may be a filename, or may be
> another data source such as a migration stream or saved data).
>
> This does add some variables and reshuffle where assignments happen;
> most notably, the "restore_filename" element of struct domain_create
> is now only set when restoring from a file.
>
> But at a high level, there should be no funcitonal changes.
>
> Signed-off-by: George Dunlap<george.dunlap@eu.citrix.com>
Sorry, this was meant to be an RFC patch before I did more thorough 
testing to make sure there aren't actually any regressions. Please give 
your opinions but do not apply yet.
>
> diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c	Tue Apr 03 18:00:24 2012 +0100
> +++ b/tools/libxl/libxl_utils.c	Tue Apr 03 19:02:19 2012 +0100
> @@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx *
>                                                                             \
>     int libxl_##rw##_exactly(libxl_ctx *ctx, int fd,                 \
>                              constdata void *data, ssize_t sz,              \
> -                           const char *filename, const char *what) {      \
> +                           const char *source, const char *what) {      \
>         ssize_t got;                                                        \
>                                                                             \
>         while (sz>  0) {                                                    \
> @@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx *
>                 if (errno == EINTR) continue;                               \
>                 if (!ctx) return errno;                                     \
>                 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to " #rw " %s%s%s", \
> -                           what?what:"", what?" from ":"", filename);     \
> +                           what?what:"", what?" from ":"", source);       \
>                 return errno;                                               \
>             }                                                               \
>             if (got == 0) {                                                 \
> @@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx *
>                        zero_is_eof                                          \
>                        ? "file/stream truncated reading %s%s%s"             \
>                        : "file/stream write returned 0! writing %s%s%s",    \
> -                     what?what:"", what?" from ":"", filename);           \
> +                     what?what:"", what?" from ":"", source);             \
>                 return EPROTO;                                              \
>             }                                                               \
>             sz -= got;                                                      \
> diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Tue Apr 03 18:00:24 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:02:19 2012 +0100
> @@ -507,9 +507,9 @@ vcpp_out:
>       return rc;
>   }
>
> -static void parse_config_data(const char *configfile_filename_report,
> -                              const char *configfile_data,
> -                              int configfile_len,
> +static void parse_config_data(const char *config_source,
> +                              const char *config_data,
> +                              int config_len,
>                                 libxl_domain_config *d_config)
>   {
>       const char *buf;
> @@ -524,15 +524,15 @@ static void parse_config_data(const char
>       libxl_domain_create_info *c_info =&d_config->c_info;
>       libxl_domain_build_info *b_info =&d_config->b_info;
>
> -    config= xlu_cfg_init(stderr, configfile_filename_report);
> +    config= xlu_cfg_init(stderr, config_source);
>       if (!config) {
>           fprintf(stderr, "Failed to allocate for configuration\n");
>           exit(1);
>       }
>
> -    e= xlu_cfg_readdata(config, configfile_data, configfile_len);
> +    e= xlu_cfg_readdata(config, config_data, config_len);
>       if (e) {
> -        fprintf(stderr, "Failed to parse config file: %s\n", strerror(e));
> +        fprintf(stderr, "Failed to parse config: %s\n", strerror(e));
>           exit(1);
>       }
>
> @@ -1467,6 +1467,8 @@ static int create_domain(struct domain_c
>       const char *config_file = dom_info->config_file;
>       const char *extra_config = dom_info->extra_config;
>       const char *restore_file = dom_info->restore_file;
> +    const char *config_source = NULL;
> +    const char *restore_source = NULL;
>       int migrate_fd = dom_info->migrate_fd;
>
>       int i;
> @@ -1482,24 +1484,28 @@ static int create_domain(struct domain_c
>       pid_t child_console_pid = -1;
>       struct save_file_header hdr;
>
> +    int restoring = (restore_file || (migrate_fd>= 0));
> +
>       memset(&d_config, 0x00, sizeof(d_config));
>
> -    if (restore_file) {
> +    if (restoring) {
>           uint8_t *optdata_begin = 0;
>           const uint8_t *optdata_here = 0;
>           union { uint32_t u32; char b[4]; } u32buf;
>           uint32_t badflags;
>
>           if (migrate_fd>= 0) {
> +            restore_source = "incoming migration stream";
>               restore_fd = migrate_fd;
>           } else {
> +            restore_source = restore_file;
>               restore_fd = open(restore_file, O_RDONLY);
>               rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
>               if (rc) return rc;
>           }
>
>           CHK_ERRNO( libxl_read_exactly(ctx, restore_fd,&hdr,
> -                   sizeof(hdr), restore_file, "header") );
> +                   sizeof(hdr), restore_source, "header") );
>           if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.magic))) {
>               fprintf(stderr, "File has wrong magic number -"
>                       " corrupt or for a different tool?\n");
> @@ -1512,7 +1518,7 @@ static int create_domain(struct domain_c
>           fprintf(stderr, "Loading new save file %s"
>                   " (new xl fmt info"
>                   " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
> -                restore_file, hdr.mandatory_flags, hdr.optional_flags,
> +                restore_source, hdr.mandatory_flags, hdr.optional_flags,
>                   hdr.optional_data_len);
>
>           badflags = hdr.mandatory_flags&  ~( 0 /* none understood yet */ );
> @@ -1525,7 +1531,7 @@ static int create_domain(struct domain_c
>           if (hdr.optional_data_len) {
>               optdata_begin = xmalloc(hdr.optional_data_len);
>               CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, optdata_begin,
> -                   hdr.optional_data_len, restore_file, "optdata") );
> +                   hdr.optional_data_len, restore_source, "optdata") );
>           }
>
>   #define OPTDATA_LEFT  (hdr.optional_data_len - (optdata_here - optdata_begin))
> @@ -1560,7 +1566,7 @@ static int create_domain(struct domain_c
>                                          &config_data,&config_len);
>           if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
>                              config_file, strerror(errno)); return ERROR_FAIL; }
> -        if (!restore_file&&  extra_config&&  strlen(extra_config)) {
> +        if (!restoring&&  extra_config&&  strlen(extra_config)) {
>               if (config_len>  INT_MAX - (strlen(extra_config) + 2 + 1)) {
>                   fprintf(stderr, "Failed to attach extra configration\n");
>                   return ERROR_FAIL;
> @@ -1575,19 +1581,20 @@ static int create_domain(struct domain_c
>               config_len += sprintf(config_data + config_len, "\n%s\n",
>                   extra_config);
>           }
> +        config_source=config_file;
>       } else {
>           if (!config_data) {
>               fprintf(stderr, "Config file not specified and"
>                       " none in save file\n");
>               return ERROR_INVAL;
>           }
> -        config_file = "<saved>";
> +        config_source = "<saved>";
>       }
>
>       if (!dom_info->quiet)
> -        printf("Parsing config file %s\n", config_file);
> -
> -    parse_config_data(config_file, config_data, config_len,&d_config);
> +        printf("Parsing config from %s\n", config_source);
> +
> +    parse_config_data(config_source, config_data, config_len,&d_config);
>
>       if (migrate_fd>= 0) {
>           if (d_config.c_info.name) {
> @@ -1638,7 +1645,7 @@ start:
>           cb = NULL;
>       }
>
> -    if ( restore_file ) {
> +    if ( restoring ) {
>           ret = libxl_domain_create_restore(ctx,&d_config,
>                                               cb,&child_console_pid,
>                                               &domid, restore_fd);
> @@ -2410,7 +2417,7 @@ static void list_domains_details(const l
>   {
>       libxl_domain_config d_config;
>
> -    char *config_file;
> +    char *config_source;
>       uint8_t *data;
>       int i, len, rc;
>
> @@ -2421,13 +2428,13 @@ static void list_domains_details(const l
>           rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl",&data,&len);
>           if (rc)
>               continue;
> -        CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
> +        CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
>           memset(&d_config, 0x00, sizeof(d_config));
> -        parse_config_data(config_file, (char *)data, len,&d_config);
> +        parse_config_data(config_source, (char *)data, len,&d_config);
>           printf_info(default_output_format, info[i].domid,&d_config);
>           libxl_domain_config_dispose(&d_config);
>           free(data);
> -        free(config_file);
> +        free(config_source);
>       }
>   }
>
> @@ -2530,7 +2537,7 @@ static void save_domain_core_begin(const
>       }
>   }
>
> -static void save_domain_core_writeconfig(int fd, const char *filename,
> +static void save_domain_core_writeconfig(int fd, const char *source,
>                                     const uint8_t *config_data, int config_len)
>   {
>       struct save_file_header hdr;
> @@ -2559,13 +2566,13 @@ static void save_domain_core_writeconfig
>       /* that's the optional data */
>
>       CHK_ERRNO( libxl_write_exactly(ctx, fd,
> -&hdr, sizeof(hdr), filename, "header") );
> +&hdr, sizeof(hdr), source, "header") );
>       CHK_ERRNO( libxl_write_exactly(ctx, fd,
> -        optdata_begin, hdr.optional_data_len, filename, "header") );
> +        optdata_begin, hdr.optional_data_len, source, "header") );
>
>       fprintf(stderr, "Saving to %s new xl format (info"
>               " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
> -            filename, hdr.mandatory_flags, hdr.optional_flags,
> +            source, hdr.mandatory_flags, hdr.optional_flags,
>               hdr.optional_data_len);
>   }
>
> @@ -2891,7 +2898,6 @@ static void migrate_receive(int debug, i
>       dom_info.daemonize = daemonize;
>       dom_info.monitor = monitor;
>       dom_info.paused = 1;
> -    dom_info.restore_file = "incoming migration stream";
>       dom_info.migrate_fd = 0; /* stdin */
>       dom_info.migration_domname_r =&migration_domname;
>       dom_info.incr_generationid = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 18:53:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 18:53:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF8rA-0007Kl-3o; Tue, 03 Apr 2012 18:53:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SF8r8-0007Kg-1U
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 18:53:26 +0000
Received: from [85.158.138.51:51773] by server-4.bemta-3.messagelabs.com id
	DB/D0-16467-5274B7F4; Tue, 03 Apr 2012 18:53:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333479201!18834076!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDExNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10513 invoked from network); 3 Apr 2012 18:53:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 18:53:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="188873073"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 14:53:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 14:53:10 -0400
Received: from [10.80.3.93]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <george.dunlap@eu.citrix.com>)	id 1SF8qr-0006W6-UT	for
	xen-devel@lists.xensource.com; Tue, 03 Apr 2012 19:53:09 +0100
Message-ID: <4F7B46FA.3070401@eu.citrix.com>
Date: Tue, 3 Apr 2012 19:52:42 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1333477720@kodo2>
	<30cc13e25e015fa0a047.1333477722@kodo2>
In-Reply-To: <30cc13e25e015fa0a047.1333477722@kodo2>
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between
 "filename" and "data source"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/04/12 19:28, George Dunlap wrote:
> Many places in xl there's a variable or element named "filename" which
> does not contain a filename, but the source of the data for reporting
> purposes.  Worse, there are variables which are sometimes actually
> used or interpreted as a filename depending on what other variables
> are set.  This makes it difficult to tell when a string is purely
> cosmetic, and when another bit of code may actually attempt to call
> "open" with the string.
>
> This patch makes a consistent distinction between "filename" (which
> always refers to the name of an actual file, and may be interpreted as
> such at some point) and "source" (which may be a filename, or may be
> another data source such as a migration stream or saved data).
>
> This does add some variables and reshuffle where assignments happen;
> most notably, the "restore_filename" element of struct domain_create
> is now only set when restoring from a file.
>
> But at a high level, there should be no funcitonal changes.
>
> Signed-off-by: George Dunlap<george.dunlap@eu.citrix.com>
Sorry, this was meant to be an RFC patch before I did more thorough 
testing to make sure there aren't actually any regressions. Please give 
your opinions but do not apply yet.
>
> diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c	Tue Apr 03 18:00:24 2012 +0100
> +++ b/tools/libxl/libxl_utils.c	Tue Apr 03 19:02:19 2012 +0100
> @@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx *
>                                                                             \
>     int libxl_##rw##_exactly(libxl_ctx *ctx, int fd,                 \
>                              constdata void *data, ssize_t sz,              \
> -                           const char *filename, const char *what) {      \
> +                           const char *source, const char *what) {      \
>         ssize_t got;                                                        \
>                                                                             \
>         while (sz>  0) {                                                    \
> @@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx *
>                 if (errno == EINTR) continue;                               \
>                 if (!ctx) return errno;                                     \
>                 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to " #rw " %s%s%s", \
> -                           what?what:"", what?" from ":"", filename);     \
> +                           what?what:"", what?" from ":"", source);       \
>                 return errno;                                               \
>             }                                                               \
>             if (got == 0) {                                                 \
> @@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx *
>                        zero_is_eof                                          \
>                        ? "file/stream truncated reading %s%s%s"             \
>                        : "file/stream write returned 0! writing %s%s%s",    \
> -                     what?what:"", what?" from ":"", filename);           \
> +                     what?what:"", what?" from ":"", source);             \
>                 return EPROTO;                                              \
>             }                                                               \
>             sz -= got;                                                      \
> diff -r 5ca90c805046 -r 30cc13e25e01 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Tue Apr 03 18:00:24 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Apr 03 19:02:19 2012 +0100
> @@ -507,9 +507,9 @@ vcpp_out:
>       return rc;
>   }
>
> -static void parse_config_data(const char *configfile_filename_report,
> -                              const char *configfile_data,
> -                              int configfile_len,
> +static void parse_config_data(const char *config_source,
> +                              const char *config_data,
> +                              int config_len,
>                                 libxl_domain_config *d_config)
>   {
>       const char *buf;
> @@ -524,15 +524,15 @@ static void parse_config_data(const char
>       libxl_domain_create_info *c_info =&d_config->c_info;
>       libxl_domain_build_info *b_info =&d_config->b_info;
>
> -    config= xlu_cfg_init(stderr, configfile_filename_report);
> +    config= xlu_cfg_init(stderr, config_source);
>       if (!config) {
>           fprintf(stderr, "Failed to allocate for configuration\n");
>           exit(1);
>       }
>
> -    e= xlu_cfg_readdata(config, configfile_data, configfile_len);
> +    e= xlu_cfg_readdata(config, config_data, config_len);
>       if (e) {
> -        fprintf(stderr, "Failed to parse config file: %s\n", strerror(e));
> +        fprintf(stderr, "Failed to parse config: %s\n", strerror(e));
>           exit(1);
>       }
>
> @@ -1467,6 +1467,8 @@ static int create_domain(struct domain_c
>       const char *config_file = dom_info->config_file;
>       const char *extra_config = dom_info->extra_config;
>       const char *restore_file = dom_info->restore_file;
> +    const char *config_source = NULL;
> +    const char *restore_source = NULL;
>       int migrate_fd = dom_info->migrate_fd;
>
>       int i;
> @@ -1482,24 +1484,28 @@ static int create_domain(struct domain_c
>       pid_t child_console_pid = -1;
>       struct save_file_header hdr;
>
> +    int restoring = (restore_file || (migrate_fd>= 0));
> +
>       memset(&d_config, 0x00, sizeof(d_config));
>
> -    if (restore_file) {
> +    if (restoring) {
>           uint8_t *optdata_begin = 0;
>           const uint8_t *optdata_here = 0;
>           union { uint32_t u32; char b[4]; } u32buf;
>           uint32_t badflags;
>
>           if (migrate_fd>= 0) {
> +            restore_source = "incoming migration stream";
>               restore_fd = migrate_fd;
>           } else {
> +            restore_source = restore_file;
>               restore_fd = open(restore_file, O_RDONLY);
>               rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
>               if (rc) return rc;
>           }
>
>           CHK_ERRNO( libxl_read_exactly(ctx, restore_fd,&hdr,
> -                   sizeof(hdr), restore_file, "header") );
> +                   sizeof(hdr), restore_source, "header") );
>           if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.magic))) {
>               fprintf(stderr, "File has wrong magic number -"
>                       " corrupt or for a different tool?\n");
> @@ -1512,7 +1518,7 @@ static int create_domain(struct domain_c
>           fprintf(stderr, "Loading new save file %s"
>                   " (new xl fmt info"
>                   " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
> -                restore_file, hdr.mandatory_flags, hdr.optional_flags,
> +                restore_source, hdr.mandatory_flags, hdr.optional_flags,
>                   hdr.optional_data_len);
>
>           badflags = hdr.mandatory_flags&  ~( 0 /* none understood yet */ );
> @@ -1525,7 +1531,7 @@ static int create_domain(struct domain_c
>           if (hdr.optional_data_len) {
>               optdata_begin = xmalloc(hdr.optional_data_len);
>               CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, optdata_begin,
> -                   hdr.optional_data_len, restore_file, "optdata") );
> +                   hdr.optional_data_len, restore_source, "optdata") );
>           }
>
>   #define OPTDATA_LEFT  (hdr.optional_data_len - (optdata_here - optdata_begin))
> @@ -1560,7 +1566,7 @@ static int create_domain(struct domain_c
>                                          &config_data,&config_len);
>           if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
>                              config_file, strerror(errno)); return ERROR_FAIL; }
> -        if (!restore_file&&  extra_config&&  strlen(extra_config)) {
> +        if (!restoring&&  extra_config&&  strlen(extra_config)) {
>               if (config_len>  INT_MAX - (strlen(extra_config) + 2 + 1)) {
>                   fprintf(stderr, "Failed to attach extra configration\n");
>                   return ERROR_FAIL;
> @@ -1575,19 +1581,20 @@ static int create_domain(struct domain_c
>               config_len += sprintf(config_data + config_len, "\n%s\n",
>                   extra_config);
>           }
> +        config_source=config_file;
>       } else {
>           if (!config_data) {
>               fprintf(stderr, "Config file not specified and"
>                       " none in save file\n");
>               return ERROR_INVAL;
>           }
> -        config_file = "<saved>";
> +        config_source = "<saved>";
>       }
>
>       if (!dom_info->quiet)
> -        printf("Parsing config file %s\n", config_file);
> -
> -    parse_config_data(config_file, config_data, config_len,&d_config);
> +        printf("Parsing config from %s\n", config_source);
> +
> +    parse_config_data(config_source, config_data, config_len,&d_config);
>
>       if (migrate_fd>= 0) {
>           if (d_config.c_info.name) {
> @@ -1638,7 +1645,7 @@ start:
>           cb = NULL;
>       }
>
> -    if ( restore_file ) {
> +    if ( restoring ) {
>           ret = libxl_domain_create_restore(ctx,&d_config,
>                                               cb,&child_console_pid,
>                                               &domid, restore_fd);
> @@ -2410,7 +2417,7 @@ static void list_domains_details(const l
>   {
>       libxl_domain_config d_config;
>
> -    char *config_file;
> +    char *config_source;
>       uint8_t *data;
>       int i, len, rc;
>
> @@ -2421,13 +2428,13 @@ static void list_domains_details(const l
>           rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl",&data,&len);
>           if (rc)
>               continue;
> -        CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
> +        CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
>           memset(&d_config, 0x00, sizeof(d_config));
> -        parse_config_data(config_file, (char *)data, len,&d_config);
> +        parse_config_data(config_source, (char *)data, len,&d_config);
>           printf_info(default_output_format, info[i].domid,&d_config);
>           libxl_domain_config_dispose(&d_config);
>           free(data);
> -        free(config_file);
> +        free(config_source);
>       }
>   }
>
> @@ -2530,7 +2537,7 @@ static void save_domain_core_begin(const
>       }
>   }
>
> -static void save_domain_core_writeconfig(int fd, const char *filename,
> +static void save_domain_core_writeconfig(int fd, const char *source,
>                                     const uint8_t *config_data, int config_len)
>   {
>       struct save_file_header hdr;
> @@ -2559,13 +2566,13 @@ static void save_domain_core_writeconfig
>       /* that's the optional data */
>
>       CHK_ERRNO( libxl_write_exactly(ctx, fd,
> -&hdr, sizeof(hdr), filename, "header") );
> +&hdr, sizeof(hdr), source, "header") );
>       CHK_ERRNO( libxl_write_exactly(ctx, fd,
> -        optdata_begin, hdr.optional_data_len, filename, "header") );
> +        optdata_begin, hdr.optional_data_len, source, "header") );
>
>       fprintf(stderr, "Saving to %s new xl format (info"
>               " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n",
> -            filename, hdr.mandatory_flags, hdr.optional_flags,
> +            source, hdr.mandatory_flags, hdr.optional_flags,
>               hdr.optional_data_len);
>   }
>
> @@ -2891,7 +2898,6 @@ static void migrate_receive(int debug, i
>       dom_info.daemonize = daemonize;
>       dom_info.monitor = monitor;
>       dom_info.paused = 1;
> -    dom_info.restore_file = "incoming migration stream";
>       dom_info.migrate_fd = 0; /* stdin */
>       dom_info.migration_domname_r =&migration_domname;
>       dom_info.incr_generationid = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 19:14:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 19:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9BS-0007cc-6j; Tue, 03 Apr 2012 19:14:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1SF9BQ-0007cX-J8
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 19:14:24 +0000
Received: from [85.158.143.35:21503] by server-1.bemta-4.messagelabs.com id
	83/8C-20925-F0C4B7F4; Tue, 03 Apr 2012 19:14:23 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333480463!5527907!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyNzY1Nzc=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25730 invoked from network); 3 Apr 2012 19:14:23 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-4.tower-21.messagelabs.com with SMTP;
	3 Apr 2012 19:14:23 -0000
Received: (qmail invoked by alias); 03 Apr 2012 19:14:22 -0000
Received: from xdsl-78-34-175-127.netcologne.de (EHLO Earth.access.denied)
	[78.34.175.127]
	by mail.gmx.net (mp069) with SMTP; 03 Apr 2012 21:14:22 +0200
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX1/hK/gXxTXhhzcLcR2wXd846Fa65jbHHp5AufBkC9
	PjghaIgRG2N4Hn
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>) id 1SF9Dh-0001HJ-4B
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 21:16:45 +0200
Message-ID: <4F7B4BEE.80205@access.denied>
Date: Tue, 03 Apr 2012 21:13:50 +0200
From: "Stefan Kuhne" <stefan.kuhne@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.4
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] Section mismatch with linux-3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1785775856531681945=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1785775856531681945==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigF149649A973938782F18E2E5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF149649A973938782F18E2E5
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hello,

when I try to compile linux-3.4-rc1 I get:

WARNING: arch/x86/built-in.o(.text+0x1745): Section mismatch in
reference from the function xen_align_and_add_e820_region() to the
function .init.text:e820_add_region()
The function xen_align_and_add_e820_region() references
the function __init e820_add_region().
This is often because xen_align_and_add_e820_region lacks a __init
annotation or the annotation of e820_add_region is wrong.

How can I solve this or is this not nesesary?

Regards,
Stefan Kuhne


--------------enigF149649A973938782F18E2E5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPe0vuAAoJEFLNPgL3IBVX1akIAN6+37zZo9ddjRQ8RYccCwEd
5IxgQJZpAVW1b0X8gWPTFEP6sbRokMpQq27ZPL6ExANQSKMQUTw54HlHS2E3yizr
ekmuzbW9m9fRhdF/qOR1PYrg8cCrvc6VXKcOMKBRaskpD/VaaoPQaTXddbO1NyWm
VfL8SRSTz6GetzEDm3gGatv8HOZz2OqT6Ujkl2OyOcIGul5nK8aw8WLj1tWO0+Qd
5u1DJbuVEJYFhoARcR0zkksCWRE4u4MSMbkbunpjcqWbTdivSpO24owNwQNt+7JK
87YN23BP8WzxyRmCN7j4taMt1JGec2Neqs4TA/BCfaBrrKLFAgiV/7SNTJFhpQY=
=Rw2y
-----END PGP SIGNATURE-----

--------------enigF149649A973938782F18E2E5--


--===============1785775856531681945==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1785775856531681945==--


From xen-devel-bounces@lists.xen.org Tue Apr 03 19:14:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 19:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9BS-0007cc-6j; Tue, 03 Apr 2012 19:14:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1SF9BQ-0007cX-J8
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 19:14:24 +0000
Received: from [85.158.143.35:21503] by server-1.bemta-4.messagelabs.com id
	83/8C-20925-F0C4B7F4; Tue, 03 Apr 2012 19:14:23 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333480463!5527907!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyNzY1Nzc=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25730 invoked from network); 3 Apr 2012 19:14:23 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-4.tower-21.messagelabs.com with SMTP;
	3 Apr 2012 19:14:23 -0000
Received: (qmail invoked by alias); 03 Apr 2012 19:14:22 -0000
Received: from xdsl-78-34-175-127.netcologne.de (EHLO Earth.access.denied)
	[78.34.175.127]
	by mail.gmx.net (mp069) with SMTP; 03 Apr 2012 21:14:22 +0200
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX1/hK/gXxTXhhzcLcR2wXd846Fa65jbHHp5AufBkC9
	PjghaIgRG2N4Hn
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>) id 1SF9Dh-0001HJ-4B
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 21:16:45 +0200
Message-ID: <4F7B4BEE.80205@access.denied>
Date: Tue, 03 Apr 2012 21:13:50 +0200
From: "Stefan Kuhne" <stefan.kuhne@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.4
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] Section mismatch with linux-3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1785775856531681945=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1785775856531681945==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigF149649A973938782F18E2E5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF149649A973938782F18E2E5
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hello,

when I try to compile linux-3.4-rc1 I get:

WARNING: arch/x86/built-in.o(.text+0x1745): Section mismatch in
reference from the function xen_align_and_add_e820_region() to the
function .init.text:e820_add_region()
The function xen_align_and_add_e820_region() references
the function __init e820_add_region().
This is often because xen_align_and_add_e820_region lacks a __init
annotation or the annotation of e820_add_region is wrong.

How can I solve this or is this not nesesary?

Regards,
Stefan Kuhne


--------------enigF149649A973938782F18E2E5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPe0vuAAoJEFLNPgL3IBVX1akIAN6+37zZo9ddjRQ8RYccCwEd
5IxgQJZpAVW1b0X8gWPTFEP6sbRokMpQq27ZPL6ExANQSKMQUTw54HlHS2E3yizr
ekmuzbW9m9fRhdF/qOR1PYrg8cCrvc6VXKcOMKBRaskpD/VaaoPQaTXddbO1NyWm
VfL8SRSTz6GetzEDm3gGatv8HOZz2OqT6Ujkl2OyOcIGul5nK8aw8WLj1tWO0+Qd
5u1DJbuVEJYFhoARcR0zkksCWRE4u4MSMbkbunpjcqWbTdivSpO24owNwQNt+7JK
87YN23BP8WzxyRmCN7j4taMt1JGec2Neqs4TA/BCfaBrrKLFAgiV/7SNTJFhpQY=
=Rw2y
-----END PGP SIGNATURE-----

--------------enigF149649A973938782F18E2E5--


--===============1785775856531681945==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1785775856531681945==--


From xen-devel-bounces@lists.xen.org Tue Apr 03 19:51:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 19:51:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9kl-0008Hm-HC; Tue, 03 Apr 2012 19:50:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SF9kj-0008He-K0
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 19:50:53 +0000
Received: from [85.158.139.83:4780] by server-4.bemta-5.messagelabs.com id
	93/F4-10788-C945B7F4; Tue, 03 Apr 2012 19:50:52 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333482650!22292614!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1114 invoked from network); 3 Apr 2012 19:50:52 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 19:50:52 -0000
Received: by pbcuo5 with SMTP id uo5so237469pbc.32
	for <xen-devel@lists.xen.org>; Tue, 03 Apr 2012 12:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=t/81tXpSo1ZZeDQ489MnQPaUgEcyQuHvJZCAtzd3AtU=;
	b=PrrgOsKSTcJ1qSTmfT+GXa0eqIymTFZfVLfq/KI2uX2HkzQoeUtAj7UdjWamaKQDly
	r9OXbB4E4eTdG7nhSkVH8gTgFtuNnx3a/DrdDdxQOFfjwRnMronE+V9z0nEBynXHYpTV
	AFTDOE3uBOmrIUel90gk90vs3hCWJHg1lHxcZbp7Kzae4ct1IXukSg0i9MkkBbCpAkRx
	kQ305K/ODWBBOs3snRhRtuxP/5zRpr9PUJgvhYCV5VYyAoqnFaN0XcSKqu9jso+4Yz/b
	SyoOtMOpwyTfdykA4PIDUkOpYdPKWojHyGEoz/rxBpPXtkyWKo4w6cpWvTuTxibDn1OL
	l03A==
MIME-Version: 1.0
Received: by 10.68.239.233 with SMTP id vv9mr31687361pbc.75.1333482649400;
	Tue, 03 Apr 2012 12:50:49 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Tue, 3 Apr 2012 12:50:49 -0700 (PDT)
In-Reply-To: <20347.11328.121224.686159@mariner.uk.xensource.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 03:50:49 +0800
Message-ID: <CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 4, 2012 at 12:58 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr=
ote:
> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testin=
g"):
>> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com>=
 wrote:
>> > I'm not really convinced that these are appropriate for backporting to
>> > a supposedly stable tree.
>>
>> What about the changeset 25131:6f81f4d79fde? =A0It won't be able to
>> apply cleanly in xen-4.1-testing though and I can provide the backport
>> version for review if you give an OK?
>
> I would be happy to consider a backport of 25131, yes. =A0You'll have to
> do some work as 4.1 doesn't have libxl_defbool_*.

Not just libxl_defbool_* but also couple others :p

Anyway, here is my backport which I have tested and worked as
described in http://lists.xen.org/archives/html/xen-devel/2012-03/msg01452.=
html
For your review and comments please.


libxl: support for "rtc_timeoffset" and "localtime"

Implement "rtc_timeoffset" and "localtime" options compatible as xm.

rtc_timeoffset is the offset between host time and guest time.
localtime means to specify whether the emulted RTC appears as UTC or is
offset by the host.

xen-unstable changeset: 25131:6f81f4d79fde

Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>

---
 tools/libxl/libxl.idl    |    2 ++
 tools/libxl/libxl_dom.c  |    3 +++
 tools/libxl/xl_cmdimpl.c |   13 +++++++++++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl.idl
index 377417a..3193506 100644
--- a/tools/libxl/libxl.idl
+++ b/tools/libxl/libxl.idl
@@ -94,6 +94,8 @@ libxl_domain_build_info =3D Struct("domain_build_info",[
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
+    ("rtc_timeoffset",  uint32),
+    ("localtime",       bool),
     ("disable_migrate", bool),
     ("kernel",          libxl_file_reference),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c702cf7..7ab78db 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -76,6 +76,9 @@ int libxl__build_pre(libxl_ctx *ctx, uint32_t domid,
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);

+    if (info->rtc_timeoffset)
+        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
+
     if (info->hvm) {
         unsigned long shadow;
         shadow =3D (info->shadow_memkb + 1023) / 1024;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2dbced7..74545a5 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -737,6 +737,19 @@ static void parse_config_data(const char
*configfile_filename_report,
     if (!xlu_cfg_get_long(config, "tsc_mode", &l))
         b_info->tsc_mode =3D l;

+    b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
"rtc_timeoffset", &l) ? l : 0;
+
+    b_info->localtime =3D !xlu_cfg_get_long(config, "localtime", &l) ? l :=
 0;
+    if (b_info->localtime) {
+        time_t t;
+        struct tm *tm;
+
+        t =3D time(NULL);
+        tm =3D localtime(&t);
+
+        b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
+    }
+
     if (!xlu_cfg_get_long (config, "videoram", &l))
         b_info->video_memkb =3D l * 1024;



>
> Thanks,
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 19:51:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 19:51:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9kl-0008Hm-HC; Tue, 03 Apr 2012 19:50:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SF9kj-0008He-K0
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 19:50:53 +0000
Received: from [85.158.139.83:4780] by server-4.bemta-5.messagelabs.com id
	93/F4-10788-C945B7F4; Tue, 03 Apr 2012 19:50:52 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333482650!22292614!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1114 invoked from network); 3 Apr 2012 19:50:52 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 19:50:52 -0000
Received: by pbcuo5 with SMTP id uo5so237469pbc.32
	for <xen-devel@lists.xen.org>; Tue, 03 Apr 2012 12:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=t/81tXpSo1ZZeDQ489MnQPaUgEcyQuHvJZCAtzd3AtU=;
	b=PrrgOsKSTcJ1qSTmfT+GXa0eqIymTFZfVLfq/KI2uX2HkzQoeUtAj7UdjWamaKQDly
	r9OXbB4E4eTdG7nhSkVH8gTgFtuNnx3a/DrdDdxQOFfjwRnMronE+V9z0nEBynXHYpTV
	AFTDOE3uBOmrIUel90gk90vs3hCWJHg1lHxcZbp7Kzae4ct1IXukSg0i9MkkBbCpAkRx
	kQ305K/ODWBBOs3snRhRtuxP/5zRpr9PUJgvhYCV5VYyAoqnFaN0XcSKqu9jso+4Yz/b
	SyoOtMOpwyTfdykA4PIDUkOpYdPKWojHyGEoz/rxBpPXtkyWKo4w6cpWvTuTxibDn1OL
	l03A==
MIME-Version: 1.0
Received: by 10.68.239.233 with SMTP id vv9mr31687361pbc.75.1333482649400;
	Tue, 03 Apr 2012 12:50:49 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Tue, 3 Apr 2012 12:50:49 -0700 (PDT)
In-Reply-To: <20347.11328.121224.686159@mariner.uk.xensource.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 03:50:49 +0800
Message-ID: <CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 4, 2012 at 12:58 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr=
ote:
> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testin=
g"):
>> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com>=
 wrote:
>> > I'm not really convinced that these are appropriate for backporting to
>> > a supposedly stable tree.
>>
>> What about the changeset 25131:6f81f4d79fde? =A0It won't be able to
>> apply cleanly in xen-4.1-testing though and I can provide the backport
>> version for review if you give an OK?
>
> I would be happy to consider a backport of 25131, yes. =A0You'll have to
> do some work as 4.1 doesn't have libxl_defbool_*.

Not just libxl_defbool_* but also couple others :p

Anyway, here is my backport which I have tested and worked as
described in http://lists.xen.org/archives/html/xen-devel/2012-03/msg01452.=
html
For your review and comments please.


libxl: support for "rtc_timeoffset" and "localtime"

Implement "rtc_timeoffset" and "localtime" options compatible as xm.

rtc_timeoffset is the offset between host time and guest time.
localtime means to specify whether the emulted RTC appears as UTC or is
offset by the host.

xen-unstable changeset: 25131:6f81f4d79fde

Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>

---
 tools/libxl/libxl.idl    |    2 ++
 tools/libxl/libxl_dom.c  |    3 +++
 tools/libxl/xl_cmdimpl.c |   13 +++++++++++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl.idl
index 377417a..3193506 100644
--- a/tools/libxl/libxl.idl
+++ b/tools/libxl/libxl.idl
@@ -94,6 +94,8 @@ libxl_domain_build_info =3D Struct("domain_build_info",[
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
+    ("rtc_timeoffset",  uint32),
+    ("localtime",       bool),
     ("disable_migrate", bool),
     ("kernel",          libxl_file_reference),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c702cf7..7ab78db 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -76,6 +76,9 @@ int libxl__build_pre(libxl_ctx *ctx, uint32_t domid,
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);

+    if (info->rtc_timeoffset)
+        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
+
     if (info->hvm) {
         unsigned long shadow;
         shadow =3D (info->shadow_memkb + 1023) / 1024;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2dbced7..74545a5 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -737,6 +737,19 @@ static void parse_config_data(const char
*configfile_filename_report,
     if (!xlu_cfg_get_long(config, "tsc_mode", &l))
         b_info->tsc_mode =3D l;

+    b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
"rtc_timeoffset", &l) ? l : 0;
+
+    b_info->localtime =3D !xlu_cfg_get_long(config, "localtime", &l) ? l :=
 0;
+    if (b_info->localtime) {
+        time_t t;
+        struct tm *tm;
+
+        t =3D time(NULL);
+        tm =3D localtime(&t);
+
+        b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
+    }
+
     if (!xlu_cfg_get_long (config, "videoram", &l))
         b_info->video_memkb =3D l * 1024;



>
> Thanks,
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 19:54:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 19:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9no-0008RY-54; Tue, 03 Apr 2012 19:54:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF9nm-0008RN-9A
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 19:54:02 +0000
Received: from [85.158.138.51:17363] by server-1.bemta-3.messagelabs.com id
	4B/55-04539-9555B7F4; Tue, 03 Apr 2012 19:54:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333482840!20622998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16806 invoked from network); 3 Apr 2012 19:54:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 19:54:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11754183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 19:53:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 20:53:59 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SF9nj-0007OE-IU;
	Tue, 03 Apr 2012 19:53:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SF9nj-0003uc-Cn;
	Tue, 03 Apr 2012 20:53:59 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12554-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 20:53:59 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12554: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12554 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12554/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 19:54:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 19:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9no-0008RY-54; Tue, 03 Apr 2012 19:54:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SF9nm-0008RN-9A
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 19:54:02 +0000
Received: from [85.158.138.51:17363] by server-1.bemta-3.messagelabs.com id
	4B/55-04539-9555B7F4; Tue, 03 Apr 2012 19:54:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333482840!20622998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16806 invoked from network); 3 Apr 2012 19:54:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 19:54:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="11754183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 19:53:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 20:53:59 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SF9nj-0007OE-IU;
	Tue, 03 Apr 2012 19:53:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SF9nj-0003uc-Cn;
	Tue, 03 Apr 2012 20:53:59 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12554-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 20:53:59 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12554: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12554 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12554/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 20:03:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 20:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9wS-0000Oj-4R; Tue, 03 Apr 2012 20:03:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SF9wQ-0000Oe-GX
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 20:02:58 +0000
Received: from [85.158.143.99:30545] by server-2.bemta-4.messagelabs.com id
	13/1E-17550-1775B7F4; Tue, 03 Apr 2012 20:02:57 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1333483373!21666739!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24990 invoked from network); 3 Apr 2012 20:02:55 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 20:02:55 -0000
Received: by pbcuo5 with SMTP id uo5so246550pbc.32
	for <xen-devel@lists.xen.org>; Tue, 03 Apr 2012 13:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=BkHDlDx4ncRYJWyWWyGmz2ZLnlx7w8jmYZi/M9ZA7L8=;
	b=fJylkTZbuC7n1Ryus4ovq+/2TdPztsb1lV245t/id+il3KE0ShMBAIjqOydlvXv8Ei
	XqFc2Brx8Kz9T8+rzt2t6awAvHIiWW8C5NQmJz88Zr84AC8U1VHj7GMt8U8IVMV8FYnE
	ZQ7HPwv1kCwIKEpL+NnnCX3gm7T1RnQMJI7gPxzaJaZYH+gJ8MvNOQKNzoN+07N68dcD
	r/HxMq415iY/FUj32uU/V8H5VRzfv+6AUMv6/Jo5uktfsYuR2XVGyaTR/PxHD4jZCGXl
	aclEQOWCfMG1QjhTgOGd0xu5UJWk6muyJeuBwgP14nbl2h8El0rsPIQx7NbaU3WL2/e1
	+akQ==
MIME-Version: 1.0
Received: by 10.68.129.133 with SMTP id nw5mr31605563pbb.159.1333483371309;
	Tue, 03 Apr 2012 13:02:51 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Tue, 3 Apr 2012 13:02:51 -0700 (PDT)
In-Reply-To: <CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
Date: Wed, 4 Apr 2012 04:02:51 +0800
Message-ID: <CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com> w=
rote:
> On Wed, Apr 4, 2012 at 12:58 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> =
wrote:
>> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testi=
ng"):
>>> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com=
> wrote:
>>> > I'm not really convinced that these are appropriate for backporting to
>>> > a supposedly stable tree.
>>>
>>> What about the changeset 25131:6f81f4d79fde? =A0It won't be able to
>>> apply cleanly in xen-4.1-testing though and I can provide the backport
>>> version for review if you give an OK?
>>
>> I would be happy to consider a backport of 25131, yes. =A0You'll have to
>> do some work as 4.1 doesn't have libxl_defbool_*.
>
> Not just libxl_defbool_* but also couple others :p
>
> Anyway, here is my backport which I have tested and worked as
> described in http://lists.xen.org/archives/html/xen-devel/2012-03/msg0145=
2.html
> For your review and comments please.
>
>
> libxl: support for "rtc_timeoffset" and "localtime"
>
> Implement "rtc_timeoffset" and "localtime" options compatible as xm.
>
> rtc_timeoffset is the offset between host time and guest time.
> localtime means to specify whether the emulted RTC appears as UTC or is
> offset by the host.
>
> xen-unstable changeset: 25131:6f81f4d79fde
>
> Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
>
> ---
> =A0tools/libxl/libxl.idl =A0 =A0| =A0 =A02 ++
> =A0tools/libxl/libxl_dom.c =A0| =A0 =A03 +++
> =A0tools/libxl/xl_cmdimpl.c | =A0 13 +++++++++++++
> =A03 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl.idl
> index 377417a..3193506 100644
> --- a/tools/libxl/libxl.idl
> +++ b/tools/libxl/libxl.idl
> @@ -94,6 +94,8 @@ libxl_domain_build_info =3D Struct("domain_build_info",[
> =A0 =A0 ("target_memkb", =A0 =A0uint32),
> =A0 =A0 ("video_memkb", =A0 =A0 uint32),
> =A0 =A0 ("shadow_memkb", =A0 =A0uint32),
> + =A0 =A0("rtc_timeoffset", =A0uint32),
> + =A0 =A0("localtime", =A0 =A0 =A0 bool),
> =A0 =A0 ("disable_migrate", bool),
> =A0 =A0 ("kernel", =A0 =A0 =A0 =A0 =A0libxl_file_reference),
> =A0 =A0 ("cpuid", =A0 =A0 =A0 =A0 =A0 libxl_cpuid_policy_list),
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index c702cf7..7ab78db 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -76,6 +76,9 @@ int libxl__build_pre(libxl_ctx *ctx, uint32_t domid,
> =A0 =A0 if ( info->disable_migrate )
> =A0 =A0 =A0 =A0 xc_domain_disable_migrate(ctx->xch, domid);
>
> + =A0 =A0if (info->rtc_timeoffset)
> + =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, info->rtc_tim=
eoffset);
> +
> =A0 =A0 if (info->hvm) {
> =A0 =A0 =A0 =A0 unsigned long shadow;
> =A0 =A0 =A0 =A0 shadow =3D (info->shadow_memkb + 1023) / 1024;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2dbced7..74545a5 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -737,6 +737,19 @@ static void parse_config_data(const char
> *configfile_filename_report,
> =A0 =A0 if (!xlu_cfg_get_long(config, "tsc_mode", &l))
> =A0 =A0 =A0 =A0 b_info->tsc_mode =3D l;
>
> + =A0 =A0b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
> "rtc_timeoffset", &l) ? l : 0;

Ops... forgot about coding style... need to be within 80 column... I
will roll out another patch to fix this after your review.  Sorry :(

Thanks.

Kindest regards,
Giam Teck Choon


> +
> + =A0 =A0b_info->localtime =3D !xlu_cfg_get_long(config, "localtime", &l)=
 ? l : 0;
> + =A0 =A0if (b_info->localtime) {
> + =A0 =A0 =A0 =A0time_t t;
> + =A0 =A0 =A0 =A0struct tm *tm;
> +
> + =A0 =A0 =A0 =A0t =3D time(NULL);
> + =A0 =A0 =A0 =A0tm =3D localtime(&t);
> +
> + =A0 =A0 =A0 =A0b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
> + =A0 =A0}
> +
> =A0 =A0 if (!xlu_cfg_get_long (config, "videoram", &l))
> =A0 =A0 =A0 =A0 b_info->video_memkb =3D l * 1024;
>
>
>
>>
>> Thanks,
>> Ian.
>
> Thanks.
>
> Kindest regards,
> Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 20:03:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 20:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SF9wS-0000Oj-4R; Tue, 03 Apr 2012 20:03:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SF9wQ-0000Oe-GX
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 20:02:58 +0000
Received: from [85.158.143.99:30545] by server-2.bemta-4.messagelabs.com id
	13/1E-17550-1775B7F4; Tue, 03 Apr 2012 20:02:57 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1333483373!21666739!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24990 invoked from network); 3 Apr 2012 20:02:55 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 20:02:55 -0000
Received: by pbcuo5 with SMTP id uo5so246550pbc.32
	for <xen-devel@lists.xen.org>; Tue, 03 Apr 2012 13:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=BkHDlDx4ncRYJWyWWyGmz2ZLnlx7w8jmYZi/M9ZA7L8=;
	b=fJylkTZbuC7n1Ryus4ovq+/2TdPztsb1lV245t/id+il3KE0ShMBAIjqOydlvXv8Ei
	XqFc2Brx8Kz9T8+rzt2t6awAvHIiWW8C5NQmJz88Zr84AC8U1VHj7GMt8U8IVMV8FYnE
	ZQ7HPwv1kCwIKEpL+NnnCX3gm7T1RnQMJI7gPxzaJaZYH+gJ8MvNOQKNzoN+07N68dcD
	r/HxMq415iY/FUj32uU/V8H5VRzfv+6AUMv6/Jo5uktfsYuR2XVGyaTR/PxHD4jZCGXl
	aclEQOWCfMG1QjhTgOGd0xu5UJWk6muyJeuBwgP14nbl2h8El0rsPIQx7NbaU3WL2/e1
	+akQ==
MIME-Version: 1.0
Received: by 10.68.129.133 with SMTP id nw5mr31605563pbb.159.1333483371309;
	Tue, 03 Apr 2012 13:02:51 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Tue, 3 Apr 2012 13:02:51 -0700 (PDT)
In-Reply-To: <CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
Date: Wed, 4 Apr 2012 04:02:51 +0800
Message-ID: <CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com> w=
rote:
> On Wed, Apr 4, 2012 at 12:58 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> =
wrote:
>> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testi=
ng"):
>>> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com=
> wrote:
>>> > I'm not really convinced that these are appropriate for backporting to
>>> > a supposedly stable tree.
>>>
>>> What about the changeset 25131:6f81f4d79fde? =A0It won't be able to
>>> apply cleanly in xen-4.1-testing though and I can provide the backport
>>> version for review if you give an OK?
>>
>> I would be happy to consider a backport of 25131, yes. =A0You'll have to
>> do some work as 4.1 doesn't have libxl_defbool_*.
>
> Not just libxl_defbool_* but also couple others :p
>
> Anyway, here is my backport which I have tested and worked as
> described in http://lists.xen.org/archives/html/xen-devel/2012-03/msg0145=
2.html
> For your review and comments please.
>
>
> libxl: support for "rtc_timeoffset" and "localtime"
>
> Implement "rtc_timeoffset" and "localtime" options compatible as xm.
>
> rtc_timeoffset is the offset between host time and guest time.
> localtime means to specify whether the emulted RTC appears as UTC or is
> offset by the host.
>
> xen-unstable changeset: 25131:6f81f4d79fde
>
> Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
>
> ---
> =A0tools/libxl/libxl.idl =A0 =A0| =A0 =A02 ++
> =A0tools/libxl/libxl_dom.c =A0| =A0 =A03 +++
> =A0tools/libxl/xl_cmdimpl.c | =A0 13 +++++++++++++
> =A03 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl.idl
> index 377417a..3193506 100644
> --- a/tools/libxl/libxl.idl
> +++ b/tools/libxl/libxl.idl
> @@ -94,6 +94,8 @@ libxl_domain_build_info =3D Struct("domain_build_info",[
> =A0 =A0 ("target_memkb", =A0 =A0uint32),
> =A0 =A0 ("video_memkb", =A0 =A0 uint32),
> =A0 =A0 ("shadow_memkb", =A0 =A0uint32),
> + =A0 =A0("rtc_timeoffset", =A0uint32),
> + =A0 =A0("localtime", =A0 =A0 =A0 bool),
> =A0 =A0 ("disable_migrate", bool),
> =A0 =A0 ("kernel", =A0 =A0 =A0 =A0 =A0libxl_file_reference),
> =A0 =A0 ("cpuid", =A0 =A0 =A0 =A0 =A0 libxl_cpuid_policy_list),
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index c702cf7..7ab78db 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -76,6 +76,9 @@ int libxl__build_pre(libxl_ctx *ctx, uint32_t domid,
> =A0 =A0 if ( info->disable_migrate )
> =A0 =A0 =A0 =A0 xc_domain_disable_migrate(ctx->xch, domid);
>
> + =A0 =A0if (info->rtc_timeoffset)
> + =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, info->rtc_tim=
eoffset);
> +
> =A0 =A0 if (info->hvm) {
> =A0 =A0 =A0 =A0 unsigned long shadow;
> =A0 =A0 =A0 =A0 shadow =3D (info->shadow_memkb + 1023) / 1024;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2dbced7..74545a5 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -737,6 +737,19 @@ static void parse_config_data(const char
> *configfile_filename_report,
> =A0 =A0 if (!xlu_cfg_get_long(config, "tsc_mode", &l))
> =A0 =A0 =A0 =A0 b_info->tsc_mode =3D l;
>
> + =A0 =A0b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
> "rtc_timeoffset", &l) ? l : 0;

Ops... forgot about coding style... need to be within 80 column... I
will roll out another patch to fix this after your review.  Sorry :(

Thanks.

Kindest regards,
Giam Teck Choon


> +
> + =A0 =A0b_info->localtime =3D !xlu_cfg_get_long(config, "localtime", &l)=
 ? l : 0;
> + =A0 =A0if (b_info->localtime) {
> + =A0 =A0 =A0 =A0time_t t;
> + =A0 =A0 =A0 =A0struct tm *tm;
> +
> + =A0 =A0 =A0 =A0t =3D time(NULL);
> + =A0 =A0 =A0 =A0tm =3D localtime(&t);
> +
> + =A0 =A0 =A0 =A0b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
> + =A0 =A0}
> +
> =A0 =A0 if (!xlu_cfg_get_long (config, "videoram", &l))
> =A0 =A0 =A0 =A0 b_info->video_memkb =3D l * 1024;
>
>
>
>>
>> Thanks,
>> Ian.
>
> Thanks.
>
> Kindest regards,
> Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 20:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 20:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFAGm-0001CG-EN; Tue, 03 Apr 2012 20:24:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFAGl-0001CA-DX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 20:23:59 +0000
Received: from [85.158.138.51:4400] by server-9.bemta-3.messagelabs.com id
	1A/21-10923-E5C5B7F4; Tue, 03 Apr 2012 20:23:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333484637!18842494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9378 invoked from network); 3 Apr 2012 20:23:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 20:23:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,365,1330905600"; d="scan'208";a="11754610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 20:23:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 21:23:57 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFAGj-0007Zm-6p;
	Tue, 03 Apr 2012 20:23:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFAGj-00014o-6Q;
	Tue, 03 Apr 2012 21:23:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12552-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 21:23:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12552: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12552 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12552/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12548
 test-amd64-i386-xl-credit2    9 guest-start        fail in 12548 pass in 12552

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12545

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  d90c658de78a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=2386288b1bf1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 2386288b1bf1
+ branch=xen-unstable
+ revision=2386288b1bf1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 2386288b1bf1 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 20 changesets with 37 changes to 28 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 20:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 20:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFAGm-0001CG-EN; Tue, 03 Apr 2012 20:24:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFAGl-0001CA-DX
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 20:23:59 +0000
Received: from [85.158.138.51:4400] by server-9.bemta-3.messagelabs.com id
	1A/21-10923-E5C5B7F4; Tue, 03 Apr 2012 20:23:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333484637!18842494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9378 invoked from network); 3 Apr 2012 20:23:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 20:23:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,365,1330905600"; d="scan'208";a="11754610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 20:23:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Apr 2012 21:23:57 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFAGj-0007Zm-6p;
	Tue, 03 Apr 2012 20:23:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFAGj-00014o-6Q;
	Tue, 03 Apr 2012 21:23:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12552-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Apr 2012 21:23:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12552: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12552 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12552/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12548
 test-amd64-i386-xl-credit2    9 guest-start        fail in 12548 pass in 12552

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12545

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  d90c658de78a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=2386288b1bf1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 2386288b1bf1
+ branch=xen-unstable
+ revision=2386288b1bf1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 2386288b1bf1 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 20 changesets with 37 changes to 28 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 20:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 20:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFAUb-0001Ov-1D; Tue, 03 Apr 2012 20:38:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFAUZ-0001Oq-MT
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 20:38:15 +0000
Received: from [85.158.139.83:49868] by server-4.bemta-5.messagelabs.com id
	DA/C0-10788-6BF5B7F4; Tue, 03 Apr 2012 20:38:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333485492!22359910!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUyNDk1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19578 invoked from network); 3 Apr 2012 20:38:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 20:38:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q33Kc9Xx008124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Apr 2012 20:38:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q33Kc8TX011523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Apr 2012 20:38:09 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q33Kc8PQ019782; Tue, 3 Apr 2012 15:38:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 13:38:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0759C40073; Tue,  3 Apr 2012 16:33:33 -0400 (EDT)
Date: Tue, 3 Apr 2012 16:33:32 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Message-ID: <20120403203332.GA6132@phenom.dumpdata.com>
References: <4F7B4BEE.80205@access.denied>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7B4BEE.80205@access.denied>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F7B5FB2.005A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Section mismatch with linux-3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:13:50PM +0200, Stefan Kuhne wrote:
> Hello,
> 
> when I try to compile linux-3.4-rc1 I get:
> 
> WARNING: arch/x86/built-in.o(.text+0x1745): Section mismatch in
> reference from the function xen_align_and_add_e820_region() to the
> function .init.text:e820_add_region()
> The function xen_align_and_add_e820_region() references
> the function __init e820_add_region().
> This is often because xen_align_and_add_e820_region lacks a __init
> annotation or the annotation of e820_add_region is wrong.

A patch to add '__init' to the xen_align_and_add_e820_region should do it!
Please also attach you SOB to it. Thanks!
> 
> How can I solve this or is this not nesesary?

it will save a couple of bytes (as the _init sections get all removed
at a certain stage in the bootup process).

> 
> Regards,
> Stefan Kuhne
> 



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 20:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 20:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFAUb-0001Ov-1D; Tue, 03 Apr 2012 20:38:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFAUZ-0001Oq-MT
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 20:38:15 +0000
Received: from [85.158.139.83:49868] by server-4.bemta-5.messagelabs.com id
	DA/C0-10788-6BF5B7F4; Tue, 03 Apr 2012 20:38:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333485492!22359910!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUyNDk1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19578 invoked from network); 3 Apr 2012 20:38:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Apr 2012 20:38:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q33Kc9Xx008124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Apr 2012 20:38:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q33Kc8TX011523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Apr 2012 20:38:09 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q33Kc8PQ019782; Tue, 3 Apr 2012 15:38:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 13:38:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0759C40073; Tue,  3 Apr 2012 16:33:33 -0400 (EDT)
Date: Tue, 3 Apr 2012 16:33:32 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Message-ID: <20120403203332.GA6132@phenom.dumpdata.com>
References: <4F7B4BEE.80205@access.denied>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7B4BEE.80205@access.denied>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F7B5FB2.005A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Section mismatch with linux-3.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:13:50PM +0200, Stefan Kuhne wrote:
> Hello,
> 
> when I try to compile linux-3.4-rc1 I get:
> 
> WARNING: arch/x86/built-in.o(.text+0x1745): Section mismatch in
> reference from the function xen_align_and_add_e820_region() to the
> function .init.text:e820_add_region()
> The function xen_align_and_add_e820_region() references
> the function __init e820_add_region().
> This is often because xen_align_and_add_e820_region lacks a __init
> annotation or the annotation of e820_add_region is wrong.

A patch to add '__init' to the xen_align_and_add_e820_region should do it!
Please also attach you SOB to it. Thanks!
> 
> How can I solve this or is this not nesesary?

it will save a couple of bytes (as the _init sections get all removed
at a certain stage in the bootup process).

> 
> Regards,
> Stefan Kuhne
> 



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 03 21:15:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 21:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFB4d-0002h3-46; Tue, 03 Apr 2012 21:15:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SFB4c-0002gy-6M
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 21:15:30 +0000
Received: from [193.109.254.147:63766] by server-6.bemta-14.messagelabs.com id
	E7/48-02047-1786B7F4; Tue, 03 Apr 2012 21:15:29 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333487727!5899!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10164 invoked from network); 3 Apr 2012 21:15:27 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Apr 2012 21:15:27 -0000
Received: from mail103-db3-R.bigfish.com (10.3.81.235) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Apr 2012 21:15:27 +0000
Received: from mail103-db3 (localhost [127.0.0.1])	by
	mail103-db3-R.bigfish.com (Postfix) with ESMTP id 1CD4F3C0503;
	Tue,  3 Apr 2012 21:15:27 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371Ic89bh1432Nc857h98dKzz1202hzz8275bh8275dhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail103-db3 (localhost.localdomain [127.0.0.1]) by mail103-db3
	(MessageSwitch) id 1333487724254984_23127;
	Tue,  3 Apr 2012 21:15:24 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.237])	by
	mail103-db3.bigfish.com (Postfix) with ESMTP id 377802C0043;
	Tue,  3 Apr 2012 21:15:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Apr 2012 21:15:22 +0000
X-WSS-ID: 0M1X9PJ-01-FXS-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 235331028060;	Tue,  3 Apr 2012 16:15:18 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 3 Apr 2012 16:15:28 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	16:15:19 -0500
Message-ID: <4F7B66A3.3080802@amd.com>
Date: Tue, 3 Apr 2012 16:07:47 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: =?UTF-8?B?S3Jpc3RpamFuIExlxI1uaWs=?= <janez3k@gmail.com>
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
In-Reply-To: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------040704040500050502070708"
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------040704040500050502070708
Content-Type: multipart/alternative;
	boundary="------------060803020400000807020702"

--------------060803020400000807020702
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

I just re-spin the patch, but haven't tested it yet. You want to try it=20
(attached)? Make sure you are using AMD GPU as the primary.

-Wei


On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
> Hi,
>
> i am trying to apply AMD/ATI patch on xen4-2 unstable
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwR=
lN3jloS.txt
>
> and there was some changes in code and the patch is unusable, is there=20
> a new patch. or can somebody help me to update the patch?
>
> make[4]: Entering directory=20
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote/i386-dm'
>   CC    i386-dm/pt-graphics.o
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:=20
> In function =E2=80=98igd_register_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:373:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:374:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:=20
> In function =E2=80=98igd_unregister_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:396:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:397:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> make[4]: *** [pt-graphics.o] Error 1
> make[4]: Leaving directory=20
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote/i386-dm'
> make[3]: *** [subdir-i386-dm] Error 2
> make[3]: Leaving directory=20
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote'
> make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
> make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make: *** [install-tools] Error 2
>
> http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-fo=
r-pt-pci-host-read-write-td5016713.html
>
> example:
>
> old syle:
> vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);
>
> new syle:
> vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
>
> Best Regards,
> Kristijan Le=C4=8Dnik


--------------060803020400000807020702
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    I just re-spin the patch, but haven't tested it yet. You want to try
    it (attached)? Make sure you are using AMD GPU as the primary.<br>
    <br>
    -Wei<br>
    <br>
    <br>
    On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
    <blockquote
cite=3D"mid:CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmai=
l.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DU=
TF-8">
      Hi,
      <div><br>
      </div>
      <div>i am trying to apply AMD/ATI patch on xen4-2 unstable</div>
      <div><a moz-do-not-send=3D"true"
href=3D"http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/=
txtNwRlN3jloS.txt">http://old-list-archives.xen.org/archives/html/xen-dev=
el/2010-12/txtNwRlN3jloS.txt</a></div>
      <div><br>
      </div>
      <div>and there was some changes in code and the patch is unusable,
        is there a new patch. or can somebody help me to update the
        patch?</div>
      <div><br>
      </div>
      <div>
        <div>make[4]: Entering directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'</div>
        <div>=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_register_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:373:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:374:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_unregister_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:396:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:397:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>make[4]: *** [pt-graphics.o] Error 1</div>
        <div>make[4]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'</div>
        <div>make[3]: *** [subdir-i386-dm] Error 2</div>
        <div>make[3]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te'</div>
        <div>make[2]: *** [subdir-install-qemu-xen-traditional-dir]
          Error 2</div>
        <div>make[2]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools'</div>
        <div>make[1]: *** [subdirs-install] Error 2</div>
        <div>make[1]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools'</div>
        <div>make: *** [install-tools] Error 2</div>
      </div>
      <div><br>
      </div>
      <div><a moz-do-not-send=3D"true"
href=3D"http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-protot=
ype-for-pt-pci-host-read-write-td5016713.html">http://xen.1045712.n5.nabb=
le.com/PATCH-1-3-qemu-xen-Change-prototype-for-pt-pci-host-read-write-td5=
016713.html</a></div>
      <div><br>
      </div>
      <div>example:</div>
      <div><br>
      </div>
      <div>old syle:</div>
      <div>vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);</div>
      <div><br>
      </div>
      <div>new syle:</div>
      <div>vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);</div>
      <div><br>
      </div>
      <div>Best Regards,</div>
      <div>Kristijan Le=C4=8Dnik</div>
    </blockquote>
    <br>
  </body>
</html>

--------------060803020400000807020702--

--------------040704040500050502070708
Content-Type: text/plain; name="ati_vbios_patch_respin.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ati_vbios_patch_respin.txt"
Content-Description: ati_vbios_patch_respin.txt

ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMKaW5k
ZXggZGJlODgwNC4uYzAxMTc4MiAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmMKKysr
IGIvaHcvcGFzcy10aHJvdWdoLmMKQEAgLTE0MjAsOSArMTQyMCwxNyBAQCBzdGF0aWMgdm9p
ZCBwdF9pb3BvcnRfbWFwKFBDSURldmljZSAqZCwgaW50IGksCiAgICAgaWYgKGVfcGh5cyAh
PSAtMSkKICAgICB7CiAgICAgICAgIC8qIENyZWF0ZSBuZXcgbWFwcGluZyAqLwotICAgICAg
ICByZXQgPSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgZV9w
aHlzLAotICAgICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFj
Y2Vzcy5waW9fYmFzZSwgZV9zaXplLAotICAgICAgICAgICAgICAgICAgICBEUENJX0FERF9N
QVBQSU5HKTsKKyAgICAgICAgaWYgKCB2Z2Ffc2tpcF9pb3BvcnRfbWFwKGQpICkgCisgICAg
ICAgIHsKKyAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9waHlzYmFz
ZSA9IC0xOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAg
ICAgcmV0ID0geGNfZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIGVf
cGh5cywKKyAgICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFj
Y2Vzcy5waW9fYmFzZSwgZV9zaXplLAorICAgICAgICAgICAgICAgICAgIERQQ0lfQUREX01B
UFBJTkcpOworICAgICAgICB9CisKICAgICAgICAgaWYgKCByZXQgIT0gMCApCiAgICAgICAg
IHsKICAgICAgICAgICAgIFBUX0xPRygiRXJyb3I6IGNyZWF0ZSBuZXcgbWFwcGluZyBmYWls
ZWQhXG4iKTsKZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5oIGIvaHcvcGFzcy10aHJv
dWdoLmgKaW5kZXggZTY0MWI1Ni4uOTA1M2IwYyAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJv
dWdoLmgKKysrIGIvaHcvcGFzcy10aHJvdWdoLmgKQEAgLTQxOSw2ICs0MTksMTEgQEAgaW50
IHB0X3BjaV9ob3N0X3dyaXRlKHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2LCB1MzIgYWRkciwg
dTMyIHZhbCwgaW50IGxlbik7CiB2b2lkIGludGVsX3BjaF9pbml0KFBDSUJ1cyAqYnVzKTsK
IGludCByZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSk7
CiBpbnQgdW5yZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2Rldmlj
ZSk7CitpbnQgdmdhX3NraXBfaW9wb3J0X21hcChQQ0lEZXZpY2UgKmQpOworaW50IGlnZF9y
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSk7CitpbnQg
aWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up
OworaW50IGF0aV9yZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2Rl
dmljZSk7CitpbnQgYXRpX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAq
cmVhbF9kZXZpY2UpOwogaW50IHNldHVwX3ZnYV9wdChzdHJ1Y3QgcHRfZGV2ICpyZWFsX2Rl
dmljZSk7CiBQQ0lCdXMgKmludGVsX3BjaV9icmlkZ2VfaW5pdChQQ0lCdXMgKmJ1cywgaW50
IGRldmZuLCB1aW50MTZfdCB2aWQsCiAgICAgICAgICAgIHVpbnQxNl90IGRpZCwgY29uc3Qg
Y2hhciAqbmFtZSwgdWludDE2X3QgcmV2aXNpb24pOwpkaWZmIC0tZ2l0IGEvaHcvcGNpLmgg
Yi9ody9wY2kuaAppbmRleCBlZGM1OGI2Li5mZmRiNDgwIDEwMDY0NAotLS0gYS9ody9wY2ku
aAorKysgYi9ody9wY2kuaApAQCAtNTQsNiArNTQsOCBAQCBleHRlcm4gdGFyZ2V0X3BoeXNf
YWRkcl90IHBjaV9tZW1fYmFzZTsKIAogI2RlZmluZSBQQ0lfVkVORE9SX0lEX0NJUlJVUyAg
ICAgICAgICAgICAweDEwMTMKIAorI2RlZmluZSBQQ0lfVkVORE9SX0lEX0FUSSAgICAgICAg
ICAgICAgICAweDEwMDIKKwogI2RlZmluZSBQQ0lfVkVORE9SX0lEX0lCTSAgICAgICAgICAg
ICAgICAweDEwMTQKICNkZWZpbmUgUENJX0RFVklDRV9JRF9JQk1fT1BFTlBJQzIgICAgICAg
MHhmZmZmCiAKZGlmZiAtLWdpdCBhL2h3L3B0LWdyYXBoaWNzLmMgYi9ody9wdC1ncmFwaGlj
cy5jCmluZGV4IDljNDFmM2UuLjNkMGFhODggMTAwNjQ0Ci0tLSBhL2h3L3B0LWdyYXBoaWNz
LmMKKysrIGIvaHcvcHQtZ3JhcGhpY3MuYwpAQCAtOCwxMSArOCwyNDggQEAKIAogI2luY2x1
ZGUgPHVuaXN0ZC5oPgogI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1ZGUgPHN5cy9p
by5oPgogI2luY2x1ZGUgPGFzc2VydC5oPgogCiBleHRlcm4gaW50IGdmeF9wYXNzdGhydTsK
IGV4dGVybiBpbnQgaWdkX3Bhc3N0aHJ1OwogCisvKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqLworLyogICBDb2RlIGZvciBBVEkgR0ZYIFBhc3N0aHJ1ICAgKi8KKy8qKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCisvKiBBVEkgVkJJT1MgV29ya2luZyBN
ZWNoYW5pc20gCisgKgorICogR2VuZXJhbGx5IHRoZXJlIGFyZSB0aHJlZSBtZW1vcnkgcmVz
b3VyY2VzICh0d28gTU1JTyBhbmQgb25lIFBJTykgCisgKiBhc3NvY2lhdGVkIHdpdGggbW9k
ZXJuIEFUSSBnZnguIFZCSU9TIHVzZXMgc3BlY2lhbCB0cmlja3MgdG8gZmlndXJlIG91dCAK
KyAqIEJBUnMsIGluc3RlYWQgb2YgdXNpbmcgcmVndWxhciBQQ0kgY29uZmlnIHNwYWNlIHJl
YWQuCisgKgorICogICgxKSBWQklPUyByZWxpZXMgb24gSS9PIHBvcnQgMHgzQzMgdG8gcmV0
cmlldmUgUElPIEJBUiAKKyAqICAoMikgVkJJT1MgbWFpbnRhaW5zIGEgc2hhZG93IGNvcHkg
b2YgUENJIGNvbmZpZ3VyZSBzcGFjZS4gSXQgcmV0cmllcyB0aGUgCisgKiAgICAgIE1NSU8g
QkFScyBmcm9tIHRoaXMgc2hhZG93IGNvcHkgdmlhIHNlbmRpbmcgSS9PIHJlcXVlc3RzIHRv
IGZpcnN0IHR3byAKKyAqICAgICAgcmVnaXN0ZXJzIG9mIFBJTyAoTU1JTkRFWCBhbmQgTU1E
QVRBKS4gVGhlIHdvcmtmbG93IGlzIGxpa2UgdGhpczogCisgKiAgICAgIE1NSU5ERVggKHJl
Z2lzdGVyIDApIGlzIHdyaXR0ZW4gd2l0aCBhbiBpbmRleCB2YWx1ZSwgc3BlY2lmeWluZyB0
aGUgCisgKiAgICAgIHJlZ2lzdGVyIFZCSU9TIHdhbnRpbmcgdG8gYWNjZXNzLiBUaGVuIHRo
ZSBzaGFkb3dlZCBkYXRhIGNhbiBiZSAKKyAqICAgICAgcmVhZC93cml0dGVuIGZyb20gTU1E
QVRBIChyZWdpc3RlciAxKS4gRm9yIHR3byBNTUlPIEJBUnMsIHRoZSBpbmRleCAKKyAqICAg
ICAgdmFsdWVzIGFyZSAweDQwMTAgKyA0ICogYmFyX2luZGV4LiBGb3IgaW5zdGFuY2UgdGhl
IGluZGV4IHZhbHVlIGZvcgorICogICAgICBCQVIgMiBpcyAweDQwMTggKDB4NDAxMCArIDQq
MikuCisgKgorICovCisKKyNkZWZpbmUgQVRJX0JBUl9NTUlOREVYX0JBU0UgIDB4NDAxMCAg
Ly9kYXRhIHdyaXR0ZW4gdG8gTU1JTkRFWCBmb3IgTU1JTyBCQVIxCisKK3N0cnVjdCBhdGlf
Z2Z4X2luZm8geworICAgIGludCBpbml0aWFsaXplZDsgICAgICAgICAgICAvKiBpbml0aWFs
aXplZCBhbHJlYWR5PyAqLworCisgICAgLyogUElPICovCisgICAgdWludDMyX3QgaG9zdF9w
aW9fYmFzZTsgICAgIC8qIGhvc3QgYmFzZSBhZGRyIG9mIFBJTyAqLworICAgIHVpbnQzMl90
IGd1ZXN0X3Bpb19iYXNlOyAgICAvKiBndWVzdCBiYXNlIGFkZHIgb2YgUElPICovCisgICAg
dWludDMyX3QgcGlvX2Jhcl9pbmRleDsgICAgIC8qIFBJTyBCQVIgaW5kZXggY2FuIHZhcnkg
ICovCisgICAgdWludDMyX3QgcGlvX3NpemU7ICAgICAgICAgIC8qIFBJTyBzaXplICovCisK
KyAgICAvKiBNTUlPICovCisgICAgdWludDMyX3QgZ3Vlc3RfbW1pb19iYXNlMTsgIC8qIGd1
ZXN0IGJhc2UgYWRkciBvZiBNTUlPIDEgKi8KKyAgICB1aW50MzJfdCBtbWlvX2JhcjFfaW5k
ZXg7ICAgLyogZ3Vlc3QgTU1JTyBCQVIxIGluZGV4ICovCisgICAgdWludDMyX3QgZ3Vlc3Rf
bW1pb19iYXNlMjsgIC8qIGd1ZXN0IGJhc2UgYWRkciBvZiBNTUlPIDIgKi8KKyAgICB1aW50
MzJfdCBtbWlvX2JhcjJfaW5kZXg7ICAgLyogZ3Vlc3QgTU1JTyBCQVIyIGluZGV4ICovCisK
KyAgICAvKiBQSU8gTU1JTkRFWCBhY2Nlc3MgcmVjb3JkaW5nICovCisgICAgdWludDMyX3Qg
cHJlX21taW5kZXhfZGF0YTsgICAgICAgLyogcHJldmlvdXMgZGF0YSB3cml0dGVuIHRvIE1N
SU5ERVggKi8KK307CisKK3N0YXRpYyBzdHJ1Y3QgYXRpX2dmeF9pbmZvIGdmeF9pbmZvOwor
CisvKiBDb252ZXJ0IGd1ZXN0IFBJTyBwb3J0IHRvIGhvc3QgUElPIHBvcnQgKi8KK3N0YXRp
YyB1aW50MTZfdCBncG9ydF90b19ocG9ydCh1aW50MTZfdCBncG9ydCkKK3sKKyAgICByZXR1
cm4gKGdwb3J0IC0gZ2Z4X2luZm8uZ3Vlc3RfcGlvX2Jhc2UpICsgZ2Z4X2luZm8uaG9zdF9w
aW9fYmFzZTsKK30KKworLyogUmVhZCBob3N0IFBJTyBwb3J0ICovCitzdGF0aWMgdWludDMy
X3QgYXRpX2h3X2luKHVpbnQxNl90IGhwb3J0KQoreworICAgIHVuc2lnbmVkIHZhbDsKKwor
ICAgIGlvcGVybShnZnhfaW5mby5ob3N0X3Bpb19iYXNlLCBnZnhfaW5mby5waW9fc2l6ZSwg
MSk7ICAgIAorICAgIGFzbSB2b2xhdGlsZSAoImluICUxLCUwIjoiPWEiKHZhbCk6Ik5kIiho
cG9ydCkpOworICAgIGlvcGVybShnZnhfaW5mby5ob3N0X3Bpb19iYXNlLCBnZnhfaW5mby5w
aW9fc2l6ZSwgMCk7CisKKyAgICByZXR1cm4gdmFsOworfQorCisvKiBXcml0ZSBkYXRhIHRv
IGhvc3QgUElPICovCitzdGF0aWMgdm9pZCBhdGlfaHdfb3V0KHVpbnQxNl90IGhwb3J0LCB1
aW50MzJfdCBkYXRhKQoreworICAgIGlvcGVybShnZnhfaW5mby5ob3N0X3Bpb19iYXNlLCBn
ZnhfaW5mby5waW9fc2l6ZSwgMSk7ICAgIAorICAgIGFzbSB2b2xhdGlsZSAoIm91dCAlMSwg
JTAiOjoiTmQiKGhwb3J0KSwiYSIoZGF0YSkpOworICAgIGlvcGVybShnZnhfaW5mby5ob3N0
X3Bpb19iYXNlLCBnZnhfaW5mby5waW9fc2l6ZSwgMCk7Cit9CisKK3N0YXRpYyB1aW50MzJf
dCBhdGlfaW9fcmVnc19yZWFkKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkcikKK3sKKyAg
ICB1aW50MzJfdCB2YWwsIGluZGV4OworCisgICAgdmFsID0gYXRpX2h3X2luKGdwb3J0X3Rv
X2hwb3J0KGFkZHIpKTsKKworICAgIC8qIHR3ZWFrIHRoZSB2YWx1ZSBpZiBWQklPUyBpcyBy
ZWFkaW5nIE1NSU8gQkFSMSBhbmQgQkFSMiAqLworICAgIGlmICggYWRkciA9PSAoZ2Z4X2lu
Zm8uZ3Vlc3RfcGlvX2Jhc2UgKyA0KSApCisgICAgeworICAgICAgICBpbmRleCA9IChnZnhf
aW5mby5wcmVfbW1pbmRleF9kYXRhIC0gQVRJX0JBUl9NTUlOREVYX0JBU0UpIC8gNDsgCisg
ICAgCisgICAgICAgIGlmICggaW5kZXggPT0gZ2Z4X2luZm8ubW1pb19iYXIxX2luZGV4ICkK
KyAgICAgICAgICAgIHZhbCA9IGdmeF9pbmZvLmd1ZXN0X21taW9fYmFzZTEgfCAodmFsICYg
MHgwMDAwMDAwZik7CisgICAgICAgIGVsc2UgaWYgKCBpbmRleCA9PSBnZnhfaW5mby5tbWlv
X2JhcjJfaW5kZXggKQorICAgICAgICAgICAgdmFsID0gZ2Z4X2luZm8uZ3Vlc3RfbW1pb19i
YXNlMiB8ICh2YWwgJiAweDAwMDAwMDBmKTsKKyAgICB9CisKKyAgICByZXR1cm4gdmFsOwor
fQorCitzdGF0aWMgdm9pZCBhdGlfaW9fcmVnc193cml0ZSh2b2lkICpvcGFxdWUsIHVpbnQz
Ml90IGFkZHIsIHVpbnQzMl90IHZhbCkKK3sKKyAgICBhdGlfaHdfb3V0KGdwb3J0X3RvX2hw
b3J0KGFkZHIpLCB2YWwpOworCisgICAgLyogYm9vayBrZWVwaW5nICovCisgICAgaWYgKCBh
ZGRyID09IGdmeF9pbmZvLmd1ZXN0X3Bpb19iYXNlICkKKyAgICAgICAgZ2Z4X2luZm8ucHJl
X21taW5kZXhfZGF0YSA9IHZhbDsKK30KKworI2RlZmluZSBQQ0lfTlVNX0JBUlMgNgorc3Rh
dGljIHZvaWQgYXRpX2dmeF9pbml0KHN0cnVjdCBwdF9kZXYgKmFzc2lnbmVkKQoreworICAg
IFBDSURldmljZSAqZGV2ID0gKFBDSURldmljZSAqKSZhc3NpZ25lZC0+ZGV2OworICAgIGlu
dCBpLCBtbWlvX2JhcjFfaW5kZXgsIG1taW9fYmFyMl9pbmRleCwgcGlvX2luZGV4OworICAg
IFBDSUlPUmVnaW9uICpyOworCisgICAgcGlvX2luZGV4ID0gbW1pb19iYXIxX2luZGV4ID0g
bW1pb19iYXIyX2luZGV4ID0gLTE7CisKKyAgICAvKiBQQ0kgY29uZmlndXJlIHNwYWNlIG9u
bHkgY29udGFpbnMgNiBCQVJzLiBEb24ndCB1c2UgUENJX05VTV9SRUdJT05TLiAqLworICAg
IGZvciAoIGkgPSAwOyBpIDwgUENJX05VTV9CQVJTOyBpKysgKSAKKyAgICB7CisgICAgICAg
IHIgPSAmZGV2LT5pb19yZWdpb25zW2ldOworCisgICAgICAgIGlmICggci0+c2l6ZSAmJiAo
ci0+YWRkciA+IDApICYmIAorICAgICAgICAgICAgIChyLT50eXBlID09IFBDSV9BRERSRVNT
X1NQQUNFX01FTSB8fAorICAgICAgICAgICAgICByLT50eXBlID09IFBDSV9BRERSRVNTX1NQ
QUNFX01FTV9QUkVGRVRDSCkgKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIG1taW9f
YmFyMV9pbmRleCA8IDAgKQorICAgICAgICAgICAgICAgIG1taW9fYmFyMV9pbmRleCA9IGk7
CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgbW1pb19iYXIyX2luZGV4ID0g
aTsKKyAgICAgICAgfQorICAgICAgICAKKyAgICAgICAgaWYgKCByLT5zaXplICYmIChyLT5h
ZGRyID4gMCkgJiYgKHItPnR5cGUgPT0gUENJX0FERFJFU1NfU1BBQ0VfSU8pICkKKyAgICAg
ICAgeworICAgICAgICAgICAgcGlvX2luZGV4ID0gaTsKKyAgICAgICAgICAgIAorICAgICAg
ICB9CisgICAgfQorCisgICAgaWYgKCBwaW9faW5kZXggPCAwIHx8IG1taW9fYmFyMV9pbmRl
eCA8IDAgfHwgbW1pb19iYXIyX2luZGV4IDwgMCApCisgICAgeworICAgICAgICBQVF9MT0co
IkVycm9yOiBjYW4ndCBmaW5kIGNvcnJlY3QgZ2Z4IG1lbW9yeSByZXNvdXJjZSBCQVJzXG4i
KTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKyAgICAKKyAgICByZWdpc3Rlcl9pb3BvcnRf
cmVhZChkZXYtPmlvX3JlZ2lvbnNbcGlvX2luZGV4XS5hZGRyLCAKKyAgICAgIGRldi0+aW9f
cmVnaW9uc1twaW9faW5kZXhdLnNpemUsIDQsIGF0aV9pb19yZWdzX3JlYWQsIGFzc2lnbmVk
KTsKKworICAgIHJlZ2lzdGVyX2lvcG9ydF93cml0ZShkZXYtPmlvX3JlZ2lvbnNbcGlvX2lu
ZGV4XS5hZGRyLCAKKyAgICAgIGRldi0+aW9fcmVnaW9uc1twaW9faW5kZXhdLnNpemUsIDQs
IGF0aV9pb19yZWdzX3dyaXRlLCBhc3NpZ25lZCk7CisgICAgICAgICAgICAKKyAgICAvKiBp
bml0aWFsaXplIFBJTyBmaWVsZHMgKi8KKyAgICBnZnhfaW5mby5ndWVzdF9waW9fYmFzZSA9
IGRldi0+aW9fcmVnaW9uc1twaW9faW5kZXhdLmFkZHI7CisgICAgZ2Z4X2luZm8ucGlvX3Np
emUgPSBkZXYtPmlvX3JlZ2lvbnNbcGlvX2luZGV4XS5zaXplOworICAgIGdmeF9pbmZvLnBp
b19iYXJfaW5kZXggPSBwaW9faW5kZXg7CisgICAgZ2Z4X2luZm8uaG9zdF9waW9fYmFzZSA9
IGFzc2lnbmVkLT5iYXNlc1twaW9faW5kZXhdLmFjY2Vzcy5waW9fYmFzZTsKKworICAgIC8q
IGluaXRpYWxpemUgTU1JTyBmaWVsZHMgKi8KKyAgICBnZnhfaW5mby5ndWVzdF9tbWlvX2Jh
c2UxID0gZGV2LT5pb19yZWdpb25zW21taW9fYmFyMV9pbmRleF0uYWRkcjsKKyAgICBnZnhf
aW5mby5tbWlvX2JhcjFfaW5kZXggPSBtbWlvX2JhcjFfaW5kZXg7CisgICAgZ2Z4X2luZm8u
Z3Vlc3RfbW1pb19iYXNlMiA9IGRldi0+aW9fcmVnaW9uc1ttbWlvX2JhcjJfaW5kZXhdLmFk
ZHI7CisgICAgZ2Z4X2luZm8ubW1pb19iYXIyX2luZGV4ID0gbW1pb19iYXIyX2luZGV4Owor
ICAgIAorICAgIGdmeF9pbmZvLmluaXRpYWxpemVkID0gMTsKKworICAgIFBUX0xPRygiQVRJ
IEdGWCBHdWVzdCBJbmZvOlxuIgorICAgICAgICAgICAiICAgICAgIHBpb19pbmRleD0weCUw
OHgsICAgICAgIGd1ZXN0X3Bpb19iYXI9MHglMDh4XG4iCisgICAgICAgICAgICIgICAgICAg
bW1pb19iYXIxX2luZGV4PTB4JTA4eCwgZ3Vlc3RfbW1pb19iYXIxPTB4JTA4eFxuIgorICAg
ICAgICAgICAiICAgICAgIG1taW9fYmFyMl9pbmRleD0weCUwOHgsIGd1ZXN0X21taW9fYmFy
Mj0weCUwOHhcbiIsIAorICAgICAgICAgICBnZnhfaW5mby5waW9fYmFyX2luZGV4LCBnZnhf
aW5mby5ndWVzdF9waW9fYmFzZSwgCisgICAgICAgICAgIGdmeF9pbmZvLm1taW9fYmFyMV9p
bmRleCwgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMSwgCisgICAgICAgICAgIGdmeF9pbmZv
Lm1taW9fYmFyMl9pbmRleCwgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMik7Cit9CisKK3N0
YXRpYyB1aW50MzJfdCBhdGlfbGVnYWN5X2lvX3JlYWQodm9pZCAqb3BhcXVlLCB1aW50MzJf
dCBhZGRyKQoreworICAgIHN0cnVjdCBwdF9kZXYgKmFzc2lnbmVkX2RldmljZSA9IG9wYXF1
ZTsKKyAgICBQQ0lEZXZpY2UgKmRldiA9IChQQ0lEZXZpY2UgKikmYXNzaWduZWRfZGV2aWNl
LT5kZXY7CisgICAgdWludDMyX3QgdmFsID0gMHhGRjsKKworICAgIHN3aXRjaCggYWRkciAp
CisgICAgeworICAgIGNhc2UgMHgzYzM6CisgICAgICAgIHZhbCA9IGRldi0+aW9fcmVnaW9u
c1tnZnhfaW5mby5waW9fYmFyX2luZGV4XS5hZGRyID4+IDg7CisgICAgICAgIC8qIEludGVy
Y2VwdCBHRlggSU8gcmVnaXN0ZXJzLiBUaGlzIHN1cHBvc2VzIHRvIGhhcHBlbiBpbiAKKyAg
ICAgICAgICogYXRpX3JlZ2lzdGVyX3ZnYV9yZWdpb25zKCkuIEJ1dCB3ZSBjYW5ub3QgZ2V0
IGd1ZXN0IHBoeXMgSU8gQkFSIAorICAgICAgICAgKiBvdmVyIHRoZXJlLiAqLworICAgICAg
ICBpZiAoICFnZnhfaW5mby5pbml0aWFsaXplZCApCisgICAgICAgICAgICBhdGlfZ2Z4X2lu
aXQoYXNzaWduZWRfZGV2aWNlKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAg
ICAgICAgUFRfTE9HKCJFUlJPUjogcG9ydCAweCV4IEkvTyByZWFkIG5vdCBoYW5kbGVkXG4i
LCBhZGRyKTsKKyAgICAgICAgYnJlYWs7CisgICAgfQorCisgICAgcmV0dXJuIHZhbDsKK30K
Kworc3RhdGljIHZvaWQgYXRpX2xlZ2FjeV9pb193cml0ZSh2b2lkICpvcGFxdWUsIHVpbnQz
Ml90IGFkZHIsIHVpbnQzMl90IHZhbCkKK3sKKyAgICBQVF9MT0coIkVSUk9SOiBwb3J0IDB4
JXggSS9PIHdyaXRlIG5vdCBoYW5kbGVkXG4iLCBhZGRyKTsKK30KKworaW50IGF0aV9yZWdp
c3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKK3sKKyAgICBQ
Q0lEZXZpY2UgKmRldiA9IChQQ0lEZXZpY2UgKikmcmVhbF9kZXZpY2UtPmRldjsKKyAgICBp
bnQgcmV0ID0gMDsKKworICAgIC8qIFdlIG5lZWQgdG8gaW50ZXJjZXB0IFZCSU9TIGFjY2Vz
c2VzIHRvIHBvcnQgMHgzQzMsIHdoaWNoIHJldHVybnMgCisgICAgICogZGV2aWNlIHBvcnQg
SS9PIEJBUi4gRm9yIHRoZSByZXN0IG9mIGxlZ2FjeSBJL08gcG9ydHMsIHdlIGFsbG93IGRp
cmVjdAorICAgICAqIGFjY2Vzc2VzLgorICAgICAqLworICAgIHJldCB8PSB4Y19kb21haW5f
aW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCisgICAgICAgICAgICAw
eDNDMCwgMHgzLCBEUENJX0FERF9NQVBQSU5HKTsKKyAgICAKKyAgICByZXQgfD0geGNfZG9t
YWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0M0LAorICAgICAgICAg
ICAgMHgzQzQsIDB4MUMsIERQQ0lfQUREX01BUFBJTkcpOworCisgICAgcmVnaXN0ZXJfaW9w
b3J0X3JlYWQoMHgzYzMsIDEsIDEsIGF0aV9sZWdhY3lfaW9fcmVhZCwgcmVhbF9kZXZpY2Up
OworICAgIHJlZ2lzdGVyX2lvcG9ydF93cml0ZSgweDNjMywgMSwgMSwgYXRpX2xlZ2FjeV9p
b193cml0ZSwgcmVhbF9kZXZpY2UpOworCisgICAgLyogaW5pdGlhbGl6ZWQgb24gdGhlIGZp
cnN0IHBvcnQgMHgzQzMgYWNjZXNzIGluIGF0aV9nZnhfaW5pdCAqLworICAgIGdmeF9pbmZv
LmluaXRpYWxpemVkID0gMDsKKworICAgIHJldHVybiByZXQ7Cit9CisKK2ludCBhdGlfdW5y
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKK3sKKyAg
ICBpbnQgcmV0ID0gMDsKKworICAgIHJldCB8PSB4Y19kb21haW5faW9wb3J0X21hcHBpbmco
eGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCisgICAgICAgICAgICAweDNDMCwgMHgzLCBEUENJ
X1JFTU9WRV9NQVBQSU5HKTsKKyAgICAKKyAgICByZXQgfD0geGNfZG9tYWluX2lvcG9ydF9t
YXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0M0LAorICAgICAgICAgICAgMHgzQzQsIDB4
MUMsIERQQ0lfUkVNT1ZFX01BUFBJTkcpOworCisgICAgZ2Z4X2luZm8uaW5pdGlhbGl6ZWQg
PSAwOworCisgICAgcmV0dXJuIHJldDsKK30KKworLyoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKi8KKy8qICBDb2RlIGZvciBJbnRlbCBJR0QgUGFzc3RocnUgICovCisvKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwogc3RhdGljIGludCBwY2hfbWFwX2ly
cShQQ0lEZXZpY2UgKnBjaV9kZXYsIGludCBpcnFfbnVtKQogewogICAgIFBUX0xPRygicGNo
X21hcF9pcnEgY2FsbGVkXG4iKTsKQEAgLTEyMyw2ICszNjAsNzkgQEAgcmVhZF9kZWZhdWx0
OgogICAgcmV0dXJuIHBjaV9kZWZhdWx0X3JlYWRfY29uZmlnKHBjaV9kZXYsIGNvbmZpZ19h
ZGRyLCBsZW4pOwogfQogCitpbnQgaWdkX3JlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBw
dF9kZXYgKnJlYWxfZGV2aWNlKQoreworICAgIHUzMiB2ZW5kb3JfaWQsIGlnZF9vcHJlZ2lv
bjsKKyAgICBpbnQgcmV0ID0gMDsKKyAgICAKKyAgICAvKiBsZWdhY3kgSS9PIHBvcnRzIDB4
M0MwIC0tIDB4M0UwICovCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4
Y19oYW5kbGUsIGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJ
X0FERF9NQVBQSU5HKTsKKworICAgIC8qIDE6MSBtYXAgQVNMIFN0b3JhZ2UgcmVnaXN0ZXIg
dmFsdWUgKi8KKyAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNl
LT5wY2lfZGV2LCAwLCAyKTsKKyAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lfaG9zdF9yZWFk
KHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOworICAgIGlm
ICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rfb3ByZWdpb24g
KQorICAgIHsKKyAgICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19o
YW5kbGUsIGRvbWlkLAorICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdF
X1NISUZULAorICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZU
LAorICAgICAgICAgICAgICAgIDIsCisgICAgICAgICAgICAgICAgRFBDSV9BRERfTUFQUElO
Ryk7CisgICAgICAgIFBUX0xPRygicmVnaXN0ZXJfdmdhOiBpZ2Rfb3ByZWdpb24gPSAleFxu
IiwgaWdkX29wcmVnaW9uKTsKKyAgICB9CisKKyAgICByZXR1cm4gcmV0OworfQorCitpbnQg
aWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up
Cit7CisgICAgdTMyIHZlbmRvcl9pZCwgaWdkX29wcmVnaW9uOworICAgIGludCByZXQgPSAw
OworICAgIHN0cnVjdCBwY2lfZGV2ICpwaHlzX2RldiA9IHB0X3BjaV9nZXRfZGV2KDAsIDIs
IDApOworCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUs
IGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX1JFTU9WRV9N
QVBQSU5HKTsKKworICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9ob3N0X3JlYWQocmVhbF9kZXZp
Y2UtPnBjaV9kZXYsIDAsIDIpOworICAgIGlnZF9vcHJlZ2lvbiA9IHB0X3BjaV9ob3N0X3Jl
YWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9JTlRFTF9PUFJFR0lPTiwgNCk7CisgICAg
aWYgKCAodmVuZG9yX2lkID09IFBDSV9WRU5ET1JfSURfSU5URUwpICYmIGlnZF9vcHJlZ2lv
biApCisgICAgeworICAgICAgICByZXQgfD0geGNfZG9tYWluX21lbW9yeV9tYXBwaW5nKHhj
X2hhbmRsZSwgZG9taWQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+IFhDX1BB
R0VfU0hJRlQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+IFhDX1BBR0VfU0hJ
RlQsCisgICAgICAgICAgICAgICAgMiwKKyAgICAgICAgICAgICAgICBEUENJX1JFTU9WRV9N
QVBQSU5HKTsKKyAgICB9CisKKyAgICByZXR1cm4gcmV0OworfQorLyoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKi8KKy8qIEdlbmVyaWMgQ29kZSBmb3IgR0ZYIFBhc3N0aHJ1
ICovCisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworLyogVGhpcyBmdW5j
dGlvbiBkZWNpZGVzIHdoZXRoZXIgSS9PIHBvcnQgbWFwIHNob3VsZCBiZSBza2lwcGVkICov
CitpbnQgdmdhX3NraXBfaW9wb3J0X21hcChQQ0lEZXZpY2UgKmQpCit7CisgICAgc3RydWN0
IHB0X2RldiAqZGV2ID0gKHN0cnVjdCBwdF9kZXYgKilkOworICAgIGludCBza2lwID0gMDsK
KworICAgIGlmICggIWdmeF9wYXNzdGhydSB8fCBkZXYtPnBjaV9kZXYtPmRldmljZV9jbGFz
cyAhPSAweDAzMDAgKQorICAgICAgICByZXR1cm4gMDsKKworICAgIHN3aXRjaCggZGV2LT5w
Y2lfZGV2LT52ZW5kb3JfaWQgKSAKKyAgICB7CisgICAgY2FzZSBQQ0lfVkVORE9SX0lEX0FU
SToKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQU1EOgorICAgICAgICBza2lwID0gMTsKKyAg
ICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAgICAgICAgc2tpcCA9IDA7CisgICAgICAg
IGJyZWFrOworICAgIH0KKyAgICAgICAgCisgICAgcmV0dXJuIHNraXA7Cit9CisKIC8qCiAg
KiByZWdpc3RlciBWR0EgcmVzb3VyY2VzIGZvciB0aGUgZG9tYWluIHdpdGggYXNzaWduZWQg
Z2Z4CiAgKi8KQEAgLTEzNSwyOSArNDQ1LDMwIEBAIGludCByZWdpc3Rlcl92Z2FfcmVnaW9u
cyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKICAgICBpZiAoICFnZnhfcGFzc3RocnUg
fHwgcmVhbF9kZXZpY2UtPnBjaV9kZXYtPmRldmljZV9jbGFzcyAhPSAweDAzMDAgKQogICAg
ICAgICByZXR1cm4gcmV0OwogCisgICAgLyogbGVnYWN5IEkvTyBwb3J0cyAweDNCMCAtIDB4
M0JDICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUs
IGRvbWlkLCAweDNCMCwKICAgICAgICAgICAgIDB4M0IwLCAweEMsIERQQ0lfQUREX01BUFBJ
TkcpOwotCi0gICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUs
IGRvbWlkLCAweDNDMCwKLSAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX0FERF9NQVBQ
SU5HKTsKLQorICAgIAorICAgIC8qIGxlZ2FjeSB2aWRlbyBNTUlPIHJhbmdlIDB4QTAwMDAg
LSAweEJGRkZGICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19o
YW5kbGUsIGRvbWlkLAogICAgICAgICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAog
ICAgICAgICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAogICAgICAgICAgICAgMHgy
MCwKICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOwogCi0gICAgLyogMToxIG1hcCBB
U0wgU3RvcmFnZSByZWdpc3RlciB2YWx1ZSAqLwotICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9o
b3N0X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIDAsIDIpOwotICAgIGlnZF9vcHJlZ2lv
biA9IHB0X3BjaV9ob3N0X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9JTlRFTF9P
UFJFR0lPTiwgNCk7Ci0gICAgaWYgKCAodmVuZG9yX2lkID09IFBDSV9WRU5ET1JfSURfSU5U
RUwgKSAmJiBpZ2Rfb3ByZWdpb24gKQorICAgIHN3aXRjaCggcmVhbF9kZXZpY2UtPnBjaV9k
ZXYtPnZlbmRvcl9pZCApIAogICAgIHsKLSAgICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1v
cnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAotICAgICAgICAgICAgICAgIGlnZF9vcHJl
Z2lvbiA+PiBYQ19QQUdFX1NISUZULAotICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+
PiBYQ19QQUdFX1NISUZULAotICAgICAgICAgICAgICAgIDIsCi0gICAgICAgICAgICAgICAg
RFBDSV9BRERfTUFQUElORyk7Ci0gICAgICAgIFBUX0xPRygicmVnaXN0ZXJfdmdhOiBpZ2Rf
b3ByZWdpb24gPSAleFxuIiwgaWdkX29wcmVnaW9uKTsKKyAgICBjYXNlIFBDSV9WRU5ET1Jf
SURfSU5URUw6CisgICAgICAgIHJldCA9IGlnZF9yZWdpc3Rlcl92Z2FfcmVnaW9ucyhyZWFs
X2RldmljZSk7CisgICAgICAgIGJyZWFrOworICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9BVEk6
CisgICAgY2FzZSBQQ0lfVkVORE9SX0lEX0FNRDoKKyAgICAgICAgcmV0ID0gYXRpX3JlZ2lz
dGVyX3ZnYV9yZWdpb25zKHJlYWxfZGV2aWNlKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVm
YXVsdDoKKyAgICAgICAgUFRfTE9HKCJnZnggY2FyZCB3YXNuJ3Qgc3VwcG9ydGVkIGJ5IFhl
biBwYXNzdGhydSFcbiIpOworICAgICAgICByZXQgPSAxOworICAgICAgICBicmVhazsKICAg
ICB9CiAKICAgICBpZiAoIHJldCAhPSAwICkKQEAgLTE3MSwzMyArNDgyLDM2IEBAIGludCBy
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKICAqLwog
aW50IHVucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up
CiB7Ci0gICAgdTMyIHZlbmRvcl9pZCwgaWdkX29wcmVnaW9uOwogICAgIGludCByZXQgPSAw
OwogCiAgICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8IHJlYWxfZGV2aWNlLT5wY2lfZGV2LT5k
ZXZpY2VfY2xhc3MgIT0gMHgwMzAwICkKICAgICAgICAgcmV0dXJuIHJldDsKIAorICAgIC8q
IGxlZ2FjeSBJL08gcG9ydHMgMHgzQjAgLSAweDNCQyAqLwogICAgIHJldCB8PSB4Y19kb21h
aW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQjAsCiAgICAgICAgICAg
ICAweDNCMCwgMHhDLCBEUENJX1JFTU9WRV9NQVBQSU5HKTsKIAotICAgIHJldCB8PSB4Y19k
b21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCi0gICAgICAg
ICAgICAweDNDMCwgMHgyMCwgRFBDSV9SRU1PVkVfTUFQUElORyk7Ci0KKyAgICAvKiBsZWdh
Y3kgdmlkZW8gTU1JTyByYW5nZSAweEEwMDAwIC0gMHhCRkZGRiAqLwogICAgIHJldCB8PSB4
Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKICAgICAgICAgICAg
IDB4YTAwMDAgPj4gWENfUEFHRV9TSElGVCwKICAgICAgICAgICAgIDB4YTAwMDAgPj4gWENf
UEFHRV9TSElGVCwKICAgICAgICAgICAgIDIwLAogICAgICAgICAgICAgRFBDSV9SRU1PVkVf
TUFQUElORyk7CiAKLSAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2
aWNlLT5wY2lfZGV2LCBQQ0lfVkVORE9SX0lELCAyKTsKLSAgICBpZ2Rfb3ByZWdpb24gPSBw
dF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJ
T04sIDQpOwotICAgIGlmICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAm
JiBpZ2Rfb3ByZWdpb24gKQorICAgIC8qIE90aGVyIFZHQSByZWdpb25zIGFyZSB2ZW5kb3Ig
c3BlY2lmaWMgKi8KKyAgICBzd2l0Y2goIHJlYWxfZGV2aWNlLT5wY2lfZGV2LT52ZW5kb3Jf
aWQgKSAKICAgICB7Ci0gICAgICAgIHJldCB8PSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmco
eGNfaGFuZGxlLCBkb21pZCwKLSAgICAgICAgICAgICAgICBpZ2Rfb3ByZWdpb24gPj4gWENf
UEFHRV9TSElGVCwKLSAgICAgICAgICAgICAgICBpZ2Rfb3ByZWdpb24gPj4gWENfUEFHRV9T
SElGVCwKLSAgICAgICAgICAgICAgICAyLAotICAgICAgICAgICAgICAgIERQQ0lfUkVNT1ZF
X01BUFBJTkcpOworICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9JTlRFTDoKKyAgICAgICAgcmV0
ID0gaWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMocmVhbF9kZXZpY2UpOworICAgICAgICBi
cmVhazsKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQVRJOgorICAgIGNhc2UgUENJX1ZFTkRP
Ul9JRF9BTUQ6CisgICAgICAgIHJldCA9IGF0aV91bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHJl
YWxfZGV2aWNlKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAgICAgICAgUFRf
TE9HKCJnZnggY2FyZCB3YXNuJ3Qgc3VwcG9ydGVkIGJ5IFhlbiBwYXNzdGhydSFcbiIpOwor
ICAgICAgICByZXQgPSAxOworICAgICAgICBicmVhazsKICAgICB9CiAKICAgICBpZiAoIHJl
dCAhPSAwICkKQEAgLTI2NywxMiArNTgxLDEyIEBAIGludCBzZXR1cF92Z2FfcHQoc3RydWN0
IHB0X2RldiAqcmVhbF9kZXZpY2UpCiAgICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8IHJlYWxf
ZGV2aWNlLT5wY2lfZGV2LT5kZXZpY2VfY2xhc3MgIT0gMHgwMzAwICkKICAgICAgICAgcmV0
dXJuIHJjOwogCi0gICAgLyogQWxsb2NhdGVkIDY0SyBmb3IgdGhlIHZnYSBiaW9zICovCi0g
ICAgaWYgKCAhKGJpb3MgPSBtYWxsb2MoNjQgKiAxMDI0KSkgKQorICAgIC8qIEFsbG9jYXRl
ZCAxMjhLIGZvciB0aGUgdmdhIGJpb3MgKi8KKyAgICBpZiAoICEoYmlvcyA9IG1hbGxvYygx
MjggKiAxMDI0KSkgKQogICAgICAgICByZXR1cm4gLTE7CiAKICAgICBiaW9zX3NpemUgPSBn
ZXRfdmdhYmlvcyhiaW9zKTsKLSAgICBpZiAoIGJpb3Nfc2l6ZSA9PSAwIHx8IGJpb3Nfc2l6
ZSA+IDY0ICogMTAyNCkKKyAgICBpZiAoIGJpb3Nfc2l6ZSA9PSAwIHx8IGJpb3Nfc2l6ZSA+
IDEyOCAqIDEwMjQpCiAgICAgewogICAgICAgICBQVF9MT0coInZnYSBiaW9zIHNpemUgKDB4
JXgpIGlzIGludmFsaWQhXG4iLCBiaW9zX3NpemUpOwogICAgICAgICByYyA9IC0xOwo=
--------------040704040500050502070708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040704040500050502070708--


From xen-devel-bounces@lists.xen.org Tue Apr 03 21:15:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Apr 2012 21:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFB4d-0002h3-46; Tue, 03 Apr 2012 21:15:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SFB4c-0002gy-6M
	for xen-devel@lists.xen.org; Tue, 03 Apr 2012 21:15:30 +0000
Received: from [193.109.254.147:63766] by server-6.bemta-14.messagelabs.com id
	E7/48-02047-1786B7F4; Tue, 03 Apr 2012 21:15:29 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333487727!5899!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10164 invoked from network); 3 Apr 2012 21:15:27 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Apr 2012 21:15:27 -0000
Received: from mail103-db3-R.bigfish.com (10.3.81.235) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Apr 2012 21:15:27 +0000
Received: from mail103-db3 (localhost [127.0.0.1])	by
	mail103-db3-R.bigfish.com (Postfix) with ESMTP id 1CD4F3C0503;
	Tue,  3 Apr 2012 21:15:27 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371Ic89bh1432Nc857h98dKzz1202hzz8275bh8275dhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail103-db3 (localhost.localdomain [127.0.0.1]) by mail103-db3
	(MessageSwitch) id 1333487724254984_23127;
	Tue,  3 Apr 2012 21:15:24 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.237])	by
	mail103-db3.bigfish.com (Postfix) with ESMTP id 377802C0043;
	Tue,  3 Apr 2012 21:15:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Apr 2012 21:15:22 +0000
X-WSS-ID: 0M1X9PJ-01-FXS-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 235331028060;	Tue,  3 Apr 2012 16:15:18 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 3 Apr 2012 16:15:28 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012
	16:15:19 -0500
Message-ID: <4F7B66A3.3080802@amd.com>
Date: Tue, 3 Apr 2012 16:07:47 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: =?UTF-8?B?S3Jpc3RpamFuIExlxI1uaWs=?= <janez3k@gmail.com>
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
In-Reply-To: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------040704040500050502070708"
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------040704040500050502070708
Content-Type: multipart/alternative;
	boundary="------------060803020400000807020702"

--------------060803020400000807020702
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

I just re-spin the patch, but haven't tested it yet. You want to try it=20
(attached)? Make sure you are using AMD GPU as the primary.

-Wei


On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
> Hi,
>
> i am trying to apply AMD/ATI patch on xen4-2 unstable
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwR=
lN3jloS.txt
>
> and there was some changes in code and the patch is unusable, is there=20
> a new patch. or can somebody help me to update the patch?
>
> make[4]: Entering directory=20
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote/i386-dm'
>   CC    i386-dm/pt-graphics.o
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:=20
> In function =E2=80=98igd_register_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:373:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:374:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:=20
> In function =E2=80=98igd_unregister_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:396:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/=
pt-graphics.c:397:=20
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> make[4]: *** [pt-graphics.o] Error 1
> make[4]: Leaving directory=20
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote/i386-dm'
> make[3]: *** [subdir-i386-dm] Error 2
> make[3]: Leaving directory=20
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-re=
mote'
> make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
> make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make: *** [install-tools] Error 2
>
> http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-fo=
r-pt-pci-host-read-write-td5016713.html
>
> example:
>
> old syle:
> vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);
>
> new syle:
> vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
>
> Best Regards,
> Kristijan Le=C4=8Dnik


--------------060803020400000807020702
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    I just re-spin the patch, but haven't tested it yet. You want to try
    it (attached)? Make sure you are using AMD GPU as the primary.<br>
    <br>
    -Wei<br>
    <br>
    <br>
    On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
    <blockquote
cite=3D"mid:CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmai=
l.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DU=
TF-8">
      Hi,
      <div><br>
      </div>
      <div>i am trying to apply AMD/ATI patch on xen4-2 unstable</div>
      <div><a moz-do-not-send=3D"true"
href=3D"http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/=
txtNwRlN3jloS.txt">http://old-list-archives.xen.org/archives/html/xen-dev=
el/2010-12/txtNwRlN3jloS.txt</a></div>
      <div><br>
      </div>
      <div>and there was some changes in code and the patch is unusable,
        is there a new patch. or can somebody help me to update the
        patch?</div>
      <div><br>
      </div>
      <div>
        <div>make[4]: Entering directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'</div>
        <div>=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_register_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:373:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:374:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_unregister_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:396:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditio=
nal-dir/hw/pt-graphics.c:397:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>make[4]: *** [pt-graphics.o] Error 1</div>
        <div>make[4]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'</div>
        <div>make[3]: *** [subdir-i386-dm] Error 2</div>
        <div>make[3]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te'</div>
        <div>make[2]: *** [subdir-install-qemu-xen-traditional-dir]
          Error 2</div>
        <div>make[2]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools'</div>
        <div>make[1]: *** [subdirs-install] Error 2</div>
        <div>make[1]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools'</div>
        <div>make: *** [install-tools] Error 2</div>
      </div>
      <div><br>
      </div>
      <div><a moz-do-not-send=3D"true"
href=3D"http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-protot=
ype-for-pt-pci-host-read-write-td5016713.html">http://xen.1045712.n5.nabb=
le.com/PATCH-1-3-qemu-xen-Change-prototype-for-pt-pci-host-read-write-td5=
016713.html</a></div>
      <div><br>
      </div>
      <div>example:</div>
      <div><br>
      </div>
      <div>old syle:</div>
      <div>vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);</div>
      <div><br>
      </div>
      <div>new syle:</div>
      <div>vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);</div>
      <div><br>
      </div>
      <div>Best Regards,</div>
      <div>Kristijan Le=C4=8Dnik</div>
    </blockquote>
    <br>
  </body>
</html>

--------------060803020400000807020702--

--------------040704040500050502070708
Content-Type: text/plain; name="ati_vbios_patch_respin.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ati_vbios_patch_respin.txt"
Content-Description: ati_vbios_patch_respin.txt

ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMKaW5k
ZXggZGJlODgwNC4uYzAxMTc4MiAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmMKKysr
IGIvaHcvcGFzcy10aHJvdWdoLmMKQEAgLTE0MjAsOSArMTQyMCwxNyBAQCBzdGF0aWMgdm9p
ZCBwdF9pb3BvcnRfbWFwKFBDSURldmljZSAqZCwgaW50IGksCiAgICAgaWYgKGVfcGh5cyAh
PSAtMSkKICAgICB7CiAgICAgICAgIC8qIENyZWF0ZSBuZXcgbWFwcGluZyAqLwotICAgICAg
ICByZXQgPSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgZV9w
aHlzLAotICAgICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFj
Y2Vzcy5waW9fYmFzZSwgZV9zaXplLAotICAgICAgICAgICAgICAgICAgICBEUENJX0FERF9N
QVBQSU5HKTsKKyAgICAgICAgaWYgKCB2Z2Ffc2tpcF9pb3BvcnRfbWFwKGQpICkgCisgICAg
ICAgIHsKKyAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9waHlzYmFz
ZSA9IC0xOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAg
ICAgcmV0ID0geGNfZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIGVf
cGh5cywKKyAgICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFj
Y2Vzcy5waW9fYmFzZSwgZV9zaXplLAorICAgICAgICAgICAgICAgICAgIERQQ0lfQUREX01B
UFBJTkcpOworICAgICAgICB9CisKICAgICAgICAgaWYgKCByZXQgIT0gMCApCiAgICAgICAg
IHsKICAgICAgICAgICAgIFBUX0xPRygiRXJyb3I6IGNyZWF0ZSBuZXcgbWFwcGluZyBmYWls
ZWQhXG4iKTsKZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5oIGIvaHcvcGFzcy10aHJv
dWdoLmgKaW5kZXggZTY0MWI1Ni4uOTA1M2IwYyAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJv
dWdoLmgKKysrIGIvaHcvcGFzcy10aHJvdWdoLmgKQEAgLTQxOSw2ICs0MTksMTEgQEAgaW50
IHB0X3BjaV9ob3N0X3dyaXRlKHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2LCB1MzIgYWRkciwg
dTMyIHZhbCwgaW50IGxlbik7CiB2b2lkIGludGVsX3BjaF9pbml0KFBDSUJ1cyAqYnVzKTsK
IGludCByZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSk7
CiBpbnQgdW5yZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2Rldmlj
ZSk7CitpbnQgdmdhX3NraXBfaW9wb3J0X21hcChQQ0lEZXZpY2UgKmQpOworaW50IGlnZF9y
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSk7CitpbnQg
aWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up
OworaW50IGF0aV9yZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2Rl
dmljZSk7CitpbnQgYXRpX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAq
cmVhbF9kZXZpY2UpOwogaW50IHNldHVwX3ZnYV9wdChzdHJ1Y3QgcHRfZGV2ICpyZWFsX2Rl
dmljZSk7CiBQQ0lCdXMgKmludGVsX3BjaV9icmlkZ2VfaW5pdChQQ0lCdXMgKmJ1cywgaW50
IGRldmZuLCB1aW50MTZfdCB2aWQsCiAgICAgICAgICAgIHVpbnQxNl90IGRpZCwgY29uc3Qg
Y2hhciAqbmFtZSwgdWludDE2X3QgcmV2aXNpb24pOwpkaWZmIC0tZ2l0IGEvaHcvcGNpLmgg
Yi9ody9wY2kuaAppbmRleCBlZGM1OGI2Li5mZmRiNDgwIDEwMDY0NAotLS0gYS9ody9wY2ku
aAorKysgYi9ody9wY2kuaApAQCAtNTQsNiArNTQsOCBAQCBleHRlcm4gdGFyZ2V0X3BoeXNf
YWRkcl90IHBjaV9tZW1fYmFzZTsKIAogI2RlZmluZSBQQ0lfVkVORE9SX0lEX0NJUlJVUyAg
ICAgICAgICAgICAweDEwMTMKIAorI2RlZmluZSBQQ0lfVkVORE9SX0lEX0FUSSAgICAgICAg
ICAgICAgICAweDEwMDIKKwogI2RlZmluZSBQQ0lfVkVORE9SX0lEX0lCTSAgICAgICAgICAg
ICAgICAweDEwMTQKICNkZWZpbmUgUENJX0RFVklDRV9JRF9JQk1fT1BFTlBJQzIgICAgICAg
MHhmZmZmCiAKZGlmZiAtLWdpdCBhL2h3L3B0LWdyYXBoaWNzLmMgYi9ody9wdC1ncmFwaGlj
cy5jCmluZGV4IDljNDFmM2UuLjNkMGFhODggMTAwNjQ0Ci0tLSBhL2h3L3B0LWdyYXBoaWNz
LmMKKysrIGIvaHcvcHQtZ3JhcGhpY3MuYwpAQCAtOCwxMSArOCwyNDggQEAKIAogI2luY2x1
ZGUgPHVuaXN0ZC5oPgogI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1ZGUgPHN5cy9p
by5oPgogI2luY2x1ZGUgPGFzc2VydC5oPgogCiBleHRlcm4gaW50IGdmeF9wYXNzdGhydTsK
IGV4dGVybiBpbnQgaWdkX3Bhc3N0aHJ1OwogCisvKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqLworLyogICBDb2RlIGZvciBBVEkgR0ZYIFBhc3N0aHJ1ICAgKi8KKy8qKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCisvKiBBVEkgVkJJT1MgV29ya2luZyBN
ZWNoYW5pc20gCisgKgorICogR2VuZXJhbGx5IHRoZXJlIGFyZSB0aHJlZSBtZW1vcnkgcmVz
b3VyY2VzICh0d28gTU1JTyBhbmQgb25lIFBJTykgCisgKiBhc3NvY2lhdGVkIHdpdGggbW9k
ZXJuIEFUSSBnZnguIFZCSU9TIHVzZXMgc3BlY2lhbCB0cmlja3MgdG8gZmlndXJlIG91dCAK
KyAqIEJBUnMsIGluc3RlYWQgb2YgdXNpbmcgcmVndWxhciBQQ0kgY29uZmlnIHNwYWNlIHJl
YWQuCisgKgorICogICgxKSBWQklPUyByZWxpZXMgb24gSS9PIHBvcnQgMHgzQzMgdG8gcmV0
cmlldmUgUElPIEJBUiAKKyAqICAoMikgVkJJT1MgbWFpbnRhaW5zIGEgc2hhZG93IGNvcHkg
b2YgUENJIGNvbmZpZ3VyZSBzcGFjZS4gSXQgcmV0cmllcyB0aGUgCisgKiAgICAgIE1NSU8g
QkFScyBmcm9tIHRoaXMgc2hhZG93IGNvcHkgdmlhIHNlbmRpbmcgSS9PIHJlcXVlc3RzIHRv
IGZpcnN0IHR3byAKKyAqICAgICAgcmVnaXN0ZXJzIG9mIFBJTyAoTU1JTkRFWCBhbmQgTU1E
QVRBKS4gVGhlIHdvcmtmbG93IGlzIGxpa2UgdGhpczogCisgKiAgICAgIE1NSU5ERVggKHJl
Z2lzdGVyIDApIGlzIHdyaXR0ZW4gd2l0aCBhbiBpbmRleCB2YWx1ZSwgc3BlY2lmeWluZyB0
aGUgCisgKiAgICAgIHJlZ2lzdGVyIFZCSU9TIHdhbnRpbmcgdG8gYWNjZXNzLiBUaGVuIHRo
ZSBzaGFkb3dlZCBkYXRhIGNhbiBiZSAKKyAqICAgICAgcmVhZC93cml0dGVuIGZyb20gTU1E
QVRBIChyZWdpc3RlciAxKS4gRm9yIHR3byBNTUlPIEJBUnMsIHRoZSBpbmRleCAKKyAqICAg
ICAgdmFsdWVzIGFyZSAweDQwMTAgKyA0ICogYmFyX2luZGV4LiBGb3IgaW5zdGFuY2UgdGhl
IGluZGV4IHZhbHVlIGZvcgorICogICAgICBCQVIgMiBpcyAweDQwMTggKDB4NDAxMCArIDQq
MikuCisgKgorICovCisKKyNkZWZpbmUgQVRJX0JBUl9NTUlOREVYX0JBU0UgIDB4NDAxMCAg
Ly9kYXRhIHdyaXR0ZW4gdG8gTU1JTkRFWCBmb3IgTU1JTyBCQVIxCisKK3N0cnVjdCBhdGlf
Z2Z4X2luZm8geworICAgIGludCBpbml0aWFsaXplZDsgICAgICAgICAgICAvKiBpbml0aWFs
aXplZCBhbHJlYWR5PyAqLworCisgICAgLyogUElPICovCisgICAgdWludDMyX3QgaG9zdF9w
aW9fYmFzZTsgICAgIC8qIGhvc3QgYmFzZSBhZGRyIG9mIFBJTyAqLworICAgIHVpbnQzMl90
IGd1ZXN0X3Bpb19iYXNlOyAgICAvKiBndWVzdCBiYXNlIGFkZHIgb2YgUElPICovCisgICAg
dWludDMyX3QgcGlvX2Jhcl9pbmRleDsgICAgIC8qIFBJTyBCQVIgaW5kZXggY2FuIHZhcnkg
ICovCisgICAgdWludDMyX3QgcGlvX3NpemU7ICAgICAgICAgIC8qIFBJTyBzaXplICovCisK
KyAgICAvKiBNTUlPICovCisgICAgdWludDMyX3QgZ3Vlc3RfbW1pb19iYXNlMTsgIC8qIGd1
ZXN0IGJhc2UgYWRkciBvZiBNTUlPIDEgKi8KKyAgICB1aW50MzJfdCBtbWlvX2JhcjFfaW5k
ZXg7ICAgLyogZ3Vlc3QgTU1JTyBCQVIxIGluZGV4ICovCisgICAgdWludDMyX3QgZ3Vlc3Rf
bW1pb19iYXNlMjsgIC8qIGd1ZXN0IGJhc2UgYWRkciBvZiBNTUlPIDIgKi8KKyAgICB1aW50
MzJfdCBtbWlvX2JhcjJfaW5kZXg7ICAgLyogZ3Vlc3QgTU1JTyBCQVIyIGluZGV4ICovCisK
KyAgICAvKiBQSU8gTU1JTkRFWCBhY2Nlc3MgcmVjb3JkaW5nICovCisgICAgdWludDMyX3Qg
cHJlX21taW5kZXhfZGF0YTsgICAgICAgLyogcHJldmlvdXMgZGF0YSB3cml0dGVuIHRvIE1N
SU5ERVggKi8KK307CisKK3N0YXRpYyBzdHJ1Y3QgYXRpX2dmeF9pbmZvIGdmeF9pbmZvOwor
CisvKiBDb252ZXJ0IGd1ZXN0IFBJTyBwb3J0IHRvIGhvc3QgUElPIHBvcnQgKi8KK3N0YXRp
YyB1aW50MTZfdCBncG9ydF90b19ocG9ydCh1aW50MTZfdCBncG9ydCkKK3sKKyAgICByZXR1
cm4gKGdwb3J0IC0gZ2Z4X2luZm8uZ3Vlc3RfcGlvX2Jhc2UpICsgZ2Z4X2luZm8uaG9zdF9w
aW9fYmFzZTsKK30KKworLyogUmVhZCBob3N0IFBJTyBwb3J0ICovCitzdGF0aWMgdWludDMy
X3QgYXRpX2h3X2luKHVpbnQxNl90IGhwb3J0KQoreworICAgIHVuc2lnbmVkIHZhbDsKKwor
ICAgIGlvcGVybShnZnhfaW5mby5ob3N0X3Bpb19iYXNlLCBnZnhfaW5mby5waW9fc2l6ZSwg
MSk7ICAgIAorICAgIGFzbSB2b2xhdGlsZSAoImluICUxLCUwIjoiPWEiKHZhbCk6Ik5kIiho
cG9ydCkpOworICAgIGlvcGVybShnZnhfaW5mby5ob3N0X3Bpb19iYXNlLCBnZnhfaW5mby5w
aW9fc2l6ZSwgMCk7CisKKyAgICByZXR1cm4gdmFsOworfQorCisvKiBXcml0ZSBkYXRhIHRv
IGhvc3QgUElPICovCitzdGF0aWMgdm9pZCBhdGlfaHdfb3V0KHVpbnQxNl90IGhwb3J0LCB1
aW50MzJfdCBkYXRhKQoreworICAgIGlvcGVybShnZnhfaW5mby5ob3N0X3Bpb19iYXNlLCBn
ZnhfaW5mby5waW9fc2l6ZSwgMSk7ICAgIAorICAgIGFzbSB2b2xhdGlsZSAoIm91dCAlMSwg
JTAiOjoiTmQiKGhwb3J0KSwiYSIoZGF0YSkpOworICAgIGlvcGVybShnZnhfaW5mby5ob3N0
X3Bpb19iYXNlLCBnZnhfaW5mby5waW9fc2l6ZSwgMCk7Cit9CisKK3N0YXRpYyB1aW50MzJf
dCBhdGlfaW9fcmVnc19yZWFkKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkcikKK3sKKyAg
ICB1aW50MzJfdCB2YWwsIGluZGV4OworCisgICAgdmFsID0gYXRpX2h3X2luKGdwb3J0X3Rv
X2hwb3J0KGFkZHIpKTsKKworICAgIC8qIHR3ZWFrIHRoZSB2YWx1ZSBpZiBWQklPUyBpcyBy
ZWFkaW5nIE1NSU8gQkFSMSBhbmQgQkFSMiAqLworICAgIGlmICggYWRkciA9PSAoZ2Z4X2lu
Zm8uZ3Vlc3RfcGlvX2Jhc2UgKyA0KSApCisgICAgeworICAgICAgICBpbmRleCA9IChnZnhf
aW5mby5wcmVfbW1pbmRleF9kYXRhIC0gQVRJX0JBUl9NTUlOREVYX0JBU0UpIC8gNDsgCisg
ICAgCisgICAgICAgIGlmICggaW5kZXggPT0gZ2Z4X2luZm8ubW1pb19iYXIxX2luZGV4ICkK
KyAgICAgICAgICAgIHZhbCA9IGdmeF9pbmZvLmd1ZXN0X21taW9fYmFzZTEgfCAodmFsICYg
MHgwMDAwMDAwZik7CisgICAgICAgIGVsc2UgaWYgKCBpbmRleCA9PSBnZnhfaW5mby5tbWlv
X2JhcjJfaW5kZXggKQorICAgICAgICAgICAgdmFsID0gZ2Z4X2luZm8uZ3Vlc3RfbW1pb19i
YXNlMiB8ICh2YWwgJiAweDAwMDAwMDBmKTsKKyAgICB9CisKKyAgICByZXR1cm4gdmFsOwor
fQorCitzdGF0aWMgdm9pZCBhdGlfaW9fcmVnc193cml0ZSh2b2lkICpvcGFxdWUsIHVpbnQz
Ml90IGFkZHIsIHVpbnQzMl90IHZhbCkKK3sKKyAgICBhdGlfaHdfb3V0KGdwb3J0X3RvX2hw
b3J0KGFkZHIpLCB2YWwpOworCisgICAgLyogYm9vayBrZWVwaW5nICovCisgICAgaWYgKCBh
ZGRyID09IGdmeF9pbmZvLmd1ZXN0X3Bpb19iYXNlICkKKyAgICAgICAgZ2Z4X2luZm8ucHJl
X21taW5kZXhfZGF0YSA9IHZhbDsKK30KKworI2RlZmluZSBQQ0lfTlVNX0JBUlMgNgorc3Rh
dGljIHZvaWQgYXRpX2dmeF9pbml0KHN0cnVjdCBwdF9kZXYgKmFzc2lnbmVkKQoreworICAg
IFBDSURldmljZSAqZGV2ID0gKFBDSURldmljZSAqKSZhc3NpZ25lZC0+ZGV2OworICAgIGlu
dCBpLCBtbWlvX2JhcjFfaW5kZXgsIG1taW9fYmFyMl9pbmRleCwgcGlvX2luZGV4OworICAg
IFBDSUlPUmVnaW9uICpyOworCisgICAgcGlvX2luZGV4ID0gbW1pb19iYXIxX2luZGV4ID0g
bW1pb19iYXIyX2luZGV4ID0gLTE7CisKKyAgICAvKiBQQ0kgY29uZmlndXJlIHNwYWNlIG9u
bHkgY29udGFpbnMgNiBCQVJzLiBEb24ndCB1c2UgUENJX05VTV9SRUdJT05TLiAqLworICAg
IGZvciAoIGkgPSAwOyBpIDwgUENJX05VTV9CQVJTOyBpKysgKSAKKyAgICB7CisgICAgICAg
IHIgPSAmZGV2LT5pb19yZWdpb25zW2ldOworCisgICAgICAgIGlmICggci0+c2l6ZSAmJiAo
ci0+YWRkciA+IDApICYmIAorICAgICAgICAgICAgIChyLT50eXBlID09IFBDSV9BRERSRVNT
X1NQQUNFX01FTSB8fAorICAgICAgICAgICAgICByLT50eXBlID09IFBDSV9BRERSRVNTX1NQ
QUNFX01FTV9QUkVGRVRDSCkgKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIG1taW9f
YmFyMV9pbmRleCA8IDAgKQorICAgICAgICAgICAgICAgIG1taW9fYmFyMV9pbmRleCA9IGk7
CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgbW1pb19iYXIyX2luZGV4ID0g
aTsKKyAgICAgICAgfQorICAgICAgICAKKyAgICAgICAgaWYgKCByLT5zaXplICYmIChyLT5h
ZGRyID4gMCkgJiYgKHItPnR5cGUgPT0gUENJX0FERFJFU1NfU1BBQ0VfSU8pICkKKyAgICAg
ICAgeworICAgICAgICAgICAgcGlvX2luZGV4ID0gaTsKKyAgICAgICAgICAgIAorICAgICAg
ICB9CisgICAgfQorCisgICAgaWYgKCBwaW9faW5kZXggPCAwIHx8IG1taW9fYmFyMV9pbmRl
eCA8IDAgfHwgbW1pb19iYXIyX2luZGV4IDwgMCApCisgICAgeworICAgICAgICBQVF9MT0co
IkVycm9yOiBjYW4ndCBmaW5kIGNvcnJlY3QgZ2Z4IG1lbW9yeSByZXNvdXJjZSBCQVJzXG4i
KTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKyAgICAKKyAgICByZWdpc3Rlcl9pb3BvcnRf
cmVhZChkZXYtPmlvX3JlZ2lvbnNbcGlvX2luZGV4XS5hZGRyLCAKKyAgICAgIGRldi0+aW9f
cmVnaW9uc1twaW9faW5kZXhdLnNpemUsIDQsIGF0aV9pb19yZWdzX3JlYWQsIGFzc2lnbmVk
KTsKKworICAgIHJlZ2lzdGVyX2lvcG9ydF93cml0ZShkZXYtPmlvX3JlZ2lvbnNbcGlvX2lu
ZGV4XS5hZGRyLCAKKyAgICAgIGRldi0+aW9fcmVnaW9uc1twaW9faW5kZXhdLnNpemUsIDQs
IGF0aV9pb19yZWdzX3dyaXRlLCBhc3NpZ25lZCk7CisgICAgICAgICAgICAKKyAgICAvKiBp
bml0aWFsaXplIFBJTyBmaWVsZHMgKi8KKyAgICBnZnhfaW5mby5ndWVzdF9waW9fYmFzZSA9
IGRldi0+aW9fcmVnaW9uc1twaW9faW5kZXhdLmFkZHI7CisgICAgZ2Z4X2luZm8ucGlvX3Np
emUgPSBkZXYtPmlvX3JlZ2lvbnNbcGlvX2luZGV4XS5zaXplOworICAgIGdmeF9pbmZvLnBp
b19iYXJfaW5kZXggPSBwaW9faW5kZXg7CisgICAgZ2Z4X2luZm8uaG9zdF9waW9fYmFzZSA9
IGFzc2lnbmVkLT5iYXNlc1twaW9faW5kZXhdLmFjY2Vzcy5waW9fYmFzZTsKKworICAgIC8q
IGluaXRpYWxpemUgTU1JTyBmaWVsZHMgKi8KKyAgICBnZnhfaW5mby5ndWVzdF9tbWlvX2Jh
c2UxID0gZGV2LT5pb19yZWdpb25zW21taW9fYmFyMV9pbmRleF0uYWRkcjsKKyAgICBnZnhf
aW5mby5tbWlvX2JhcjFfaW5kZXggPSBtbWlvX2JhcjFfaW5kZXg7CisgICAgZ2Z4X2luZm8u
Z3Vlc3RfbW1pb19iYXNlMiA9IGRldi0+aW9fcmVnaW9uc1ttbWlvX2JhcjJfaW5kZXhdLmFk
ZHI7CisgICAgZ2Z4X2luZm8ubW1pb19iYXIyX2luZGV4ID0gbW1pb19iYXIyX2luZGV4Owor
ICAgIAorICAgIGdmeF9pbmZvLmluaXRpYWxpemVkID0gMTsKKworICAgIFBUX0xPRygiQVRJ
IEdGWCBHdWVzdCBJbmZvOlxuIgorICAgICAgICAgICAiICAgICAgIHBpb19pbmRleD0weCUw
OHgsICAgICAgIGd1ZXN0X3Bpb19iYXI9MHglMDh4XG4iCisgICAgICAgICAgICIgICAgICAg
bW1pb19iYXIxX2luZGV4PTB4JTA4eCwgZ3Vlc3RfbW1pb19iYXIxPTB4JTA4eFxuIgorICAg
ICAgICAgICAiICAgICAgIG1taW9fYmFyMl9pbmRleD0weCUwOHgsIGd1ZXN0X21taW9fYmFy
Mj0weCUwOHhcbiIsIAorICAgICAgICAgICBnZnhfaW5mby5waW9fYmFyX2luZGV4LCBnZnhf
aW5mby5ndWVzdF9waW9fYmFzZSwgCisgICAgICAgICAgIGdmeF9pbmZvLm1taW9fYmFyMV9p
bmRleCwgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMSwgCisgICAgICAgICAgIGdmeF9pbmZv
Lm1taW9fYmFyMl9pbmRleCwgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMik7Cit9CisKK3N0
YXRpYyB1aW50MzJfdCBhdGlfbGVnYWN5X2lvX3JlYWQodm9pZCAqb3BhcXVlLCB1aW50MzJf
dCBhZGRyKQoreworICAgIHN0cnVjdCBwdF9kZXYgKmFzc2lnbmVkX2RldmljZSA9IG9wYXF1
ZTsKKyAgICBQQ0lEZXZpY2UgKmRldiA9IChQQ0lEZXZpY2UgKikmYXNzaWduZWRfZGV2aWNl
LT5kZXY7CisgICAgdWludDMyX3QgdmFsID0gMHhGRjsKKworICAgIHN3aXRjaCggYWRkciAp
CisgICAgeworICAgIGNhc2UgMHgzYzM6CisgICAgICAgIHZhbCA9IGRldi0+aW9fcmVnaW9u
c1tnZnhfaW5mby5waW9fYmFyX2luZGV4XS5hZGRyID4+IDg7CisgICAgICAgIC8qIEludGVy
Y2VwdCBHRlggSU8gcmVnaXN0ZXJzLiBUaGlzIHN1cHBvc2VzIHRvIGhhcHBlbiBpbiAKKyAg
ICAgICAgICogYXRpX3JlZ2lzdGVyX3ZnYV9yZWdpb25zKCkuIEJ1dCB3ZSBjYW5ub3QgZ2V0
IGd1ZXN0IHBoeXMgSU8gQkFSIAorICAgICAgICAgKiBvdmVyIHRoZXJlLiAqLworICAgICAg
ICBpZiAoICFnZnhfaW5mby5pbml0aWFsaXplZCApCisgICAgICAgICAgICBhdGlfZ2Z4X2lu
aXQoYXNzaWduZWRfZGV2aWNlKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAg
ICAgICAgUFRfTE9HKCJFUlJPUjogcG9ydCAweCV4IEkvTyByZWFkIG5vdCBoYW5kbGVkXG4i
LCBhZGRyKTsKKyAgICAgICAgYnJlYWs7CisgICAgfQorCisgICAgcmV0dXJuIHZhbDsKK30K
Kworc3RhdGljIHZvaWQgYXRpX2xlZ2FjeV9pb193cml0ZSh2b2lkICpvcGFxdWUsIHVpbnQz
Ml90IGFkZHIsIHVpbnQzMl90IHZhbCkKK3sKKyAgICBQVF9MT0coIkVSUk9SOiBwb3J0IDB4
JXggSS9PIHdyaXRlIG5vdCBoYW5kbGVkXG4iLCBhZGRyKTsKK30KKworaW50IGF0aV9yZWdp
c3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKK3sKKyAgICBQ
Q0lEZXZpY2UgKmRldiA9IChQQ0lEZXZpY2UgKikmcmVhbF9kZXZpY2UtPmRldjsKKyAgICBp
bnQgcmV0ID0gMDsKKworICAgIC8qIFdlIG5lZWQgdG8gaW50ZXJjZXB0IFZCSU9TIGFjY2Vz
c2VzIHRvIHBvcnQgMHgzQzMsIHdoaWNoIHJldHVybnMgCisgICAgICogZGV2aWNlIHBvcnQg
SS9PIEJBUi4gRm9yIHRoZSByZXN0IG9mIGxlZ2FjeSBJL08gcG9ydHMsIHdlIGFsbG93IGRp
cmVjdAorICAgICAqIGFjY2Vzc2VzLgorICAgICAqLworICAgIHJldCB8PSB4Y19kb21haW5f
aW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCisgICAgICAgICAgICAw
eDNDMCwgMHgzLCBEUENJX0FERF9NQVBQSU5HKTsKKyAgICAKKyAgICByZXQgfD0geGNfZG9t
YWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0M0LAorICAgICAgICAg
ICAgMHgzQzQsIDB4MUMsIERQQ0lfQUREX01BUFBJTkcpOworCisgICAgcmVnaXN0ZXJfaW9w
b3J0X3JlYWQoMHgzYzMsIDEsIDEsIGF0aV9sZWdhY3lfaW9fcmVhZCwgcmVhbF9kZXZpY2Up
OworICAgIHJlZ2lzdGVyX2lvcG9ydF93cml0ZSgweDNjMywgMSwgMSwgYXRpX2xlZ2FjeV9p
b193cml0ZSwgcmVhbF9kZXZpY2UpOworCisgICAgLyogaW5pdGlhbGl6ZWQgb24gdGhlIGZp
cnN0IHBvcnQgMHgzQzMgYWNjZXNzIGluIGF0aV9nZnhfaW5pdCAqLworICAgIGdmeF9pbmZv
LmluaXRpYWxpemVkID0gMDsKKworICAgIHJldHVybiByZXQ7Cit9CisKK2ludCBhdGlfdW5y
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKK3sKKyAg
ICBpbnQgcmV0ID0gMDsKKworICAgIHJldCB8PSB4Y19kb21haW5faW9wb3J0X21hcHBpbmco
eGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCisgICAgICAgICAgICAweDNDMCwgMHgzLCBEUENJ
X1JFTU9WRV9NQVBQSU5HKTsKKyAgICAKKyAgICByZXQgfD0geGNfZG9tYWluX2lvcG9ydF9t
YXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0M0LAorICAgICAgICAgICAgMHgzQzQsIDB4
MUMsIERQQ0lfUkVNT1ZFX01BUFBJTkcpOworCisgICAgZ2Z4X2luZm8uaW5pdGlhbGl6ZWQg
PSAwOworCisgICAgcmV0dXJuIHJldDsKK30KKworLyoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKi8KKy8qICBDb2RlIGZvciBJbnRlbCBJR0QgUGFzc3RocnUgICovCisvKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwogc3RhdGljIGludCBwY2hfbWFwX2ly
cShQQ0lEZXZpY2UgKnBjaV9kZXYsIGludCBpcnFfbnVtKQogewogICAgIFBUX0xPRygicGNo
X21hcF9pcnEgY2FsbGVkXG4iKTsKQEAgLTEyMyw2ICszNjAsNzkgQEAgcmVhZF9kZWZhdWx0
OgogICAgcmV0dXJuIHBjaV9kZWZhdWx0X3JlYWRfY29uZmlnKHBjaV9kZXYsIGNvbmZpZ19h
ZGRyLCBsZW4pOwogfQogCitpbnQgaWdkX3JlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBw
dF9kZXYgKnJlYWxfZGV2aWNlKQoreworICAgIHUzMiB2ZW5kb3JfaWQsIGlnZF9vcHJlZ2lv
bjsKKyAgICBpbnQgcmV0ID0gMDsKKyAgICAKKyAgICAvKiBsZWdhY3kgSS9PIHBvcnRzIDB4
M0MwIC0tIDB4M0UwICovCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4
Y19oYW5kbGUsIGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJ
X0FERF9NQVBQSU5HKTsKKworICAgIC8qIDE6MSBtYXAgQVNMIFN0b3JhZ2UgcmVnaXN0ZXIg
dmFsdWUgKi8KKyAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNl
LT5wY2lfZGV2LCAwLCAyKTsKKyAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lfaG9zdF9yZWFk
KHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOworICAgIGlm
ICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rfb3ByZWdpb24g
KQorICAgIHsKKyAgICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19o
YW5kbGUsIGRvbWlkLAorICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdF
X1NISUZULAorICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZU
LAorICAgICAgICAgICAgICAgIDIsCisgICAgICAgICAgICAgICAgRFBDSV9BRERfTUFQUElO
Ryk7CisgICAgICAgIFBUX0xPRygicmVnaXN0ZXJfdmdhOiBpZ2Rfb3ByZWdpb24gPSAleFxu
IiwgaWdkX29wcmVnaW9uKTsKKyAgICB9CisKKyAgICByZXR1cm4gcmV0OworfQorCitpbnQg
aWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up
Cit7CisgICAgdTMyIHZlbmRvcl9pZCwgaWdkX29wcmVnaW9uOworICAgIGludCByZXQgPSAw
OworICAgIHN0cnVjdCBwY2lfZGV2ICpwaHlzX2RldiA9IHB0X3BjaV9nZXRfZGV2KDAsIDIs
IDApOworCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUs
IGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX1JFTU9WRV9N
QVBQSU5HKTsKKworICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9ob3N0X3JlYWQocmVhbF9kZXZp
Y2UtPnBjaV9kZXYsIDAsIDIpOworICAgIGlnZF9vcHJlZ2lvbiA9IHB0X3BjaV9ob3N0X3Jl
YWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9JTlRFTF9PUFJFR0lPTiwgNCk7CisgICAg
aWYgKCAodmVuZG9yX2lkID09IFBDSV9WRU5ET1JfSURfSU5URUwpICYmIGlnZF9vcHJlZ2lv
biApCisgICAgeworICAgICAgICByZXQgfD0geGNfZG9tYWluX21lbW9yeV9tYXBwaW5nKHhj
X2hhbmRsZSwgZG9taWQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+IFhDX1BB
R0VfU0hJRlQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+IFhDX1BBR0VfU0hJ
RlQsCisgICAgICAgICAgICAgICAgMiwKKyAgICAgICAgICAgICAgICBEUENJX1JFTU9WRV9N
QVBQSU5HKTsKKyAgICB9CisKKyAgICByZXR1cm4gcmV0OworfQorLyoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKi8KKy8qIEdlbmVyaWMgQ29kZSBmb3IgR0ZYIFBhc3N0aHJ1
ICovCisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworLyogVGhpcyBmdW5j
dGlvbiBkZWNpZGVzIHdoZXRoZXIgSS9PIHBvcnQgbWFwIHNob3VsZCBiZSBza2lwcGVkICov
CitpbnQgdmdhX3NraXBfaW9wb3J0X21hcChQQ0lEZXZpY2UgKmQpCit7CisgICAgc3RydWN0
IHB0X2RldiAqZGV2ID0gKHN0cnVjdCBwdF9kZXYgKilkOworICAgIGludCBza2lwID0gMDsK
KworICAgIGlmICggIWdmeF9wYXNzdGhydSB8fCBkZXYtPnBjaV9kZXYtPmRldmljZV9jbGFz
cyAhPSAweDAzMDAgKQorICAgICAgICByZXR1cm4gMDsKKworICAgIHN3aXRjaCggZGV2LT5w
Y2lfZGV2LT52ZW5kb3JfaWQgKSAKKyAgICB7CisgICAgY2FzZSBQQ0lfVkVORE9SX0lEX0FU
SToKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQU1EOgorICAgICAgICBza2lwID0gMTsKKyAg
ICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAgICAgICAgc2tpcCA9IDA7CisgICAgICAg
IGJyZWFrOworICAgIH0KKyAgICAgICAgCisgICAgcmV0dXJuIHNraXA7Cit9CisKIC8qCiAg
KiByZWdpc3RlciBWR0EgcmVzb3VyY2VzIGZvciB0aGUgZG9tYWluIHdpdGggYXNzaWduZWQg
Z2Z4CiAgKi8KQEAgLTEzNSwyOSArNDQ1LDMwIEBAIGludCByZWdpc3Rlcl92Z2FfcmVnaW9u
cyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKICAgICBpZiAoICFnZnhfcGFzc3RocnUg
fHwgcmVhbF9kZXZpY2UtPnBjaV9kZXYtPmRldmljZV9jbGFzcyAhPSAweDAzMDAgKQogICAg
ICAgICByZXR1cm4gcmV0OwogCisgICAgLyogbGVnYWN5IEkvTyBwb3J0cyAweDNCMCAtIDB4
M0JDICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUs
IGRvbWlkLCAweDNCMCwKICAgICAgICAgICAgIDB4M0IwLCAweEMsIERQQ0lfQUREX01BUFBJ
TkcpOwotCi0gICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUs
IGRvbWlkLCAweDNDMCwKLSAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX0FERF9NQVBQ
SU5HKTsKLQorICAgIAorICAgIC8qIGxlZ2FjeSB2aWRlbyBNTUlPIHJhbmdlIDB4QTAwMDAg
LSAweEJGRkZGICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19o
YW5kbGUsIGRvbWlkLAogICAgICAgICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAog
ICAgICAgICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAogICAgICAgICAgICAgMHgy
MCwKICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOwogCi0gICAgLyogMToxIG1hcCBB
U0wgU3RvcmFnZSByZWdpc3RlciB2YWx1ZSAqLwotICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9o
b3N0X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIDAsIDIpOwotICAgIGlnZF9vcHJlZ2lv
biA9IHB0X3BjaV9ob3N0X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9JTlRFTF9P
UFJFR0lPTiwgNCk7Ci0gICAgaWYgKCAodmVuZG9yX2lkID09IFBDSV9WRU5ET1JfSURfSU5U
RUwgKSAmJiBpZ2Rfb3ByZWdpb24gKQorICAgIHN3aXRjaCggcmVhbF9kZXZpY2UtPnBjaV9k
ZXYtPnZlbmRvcl9pZCApIAogICAgIHsKLSAgICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1v
cnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAotICAgICAgICAgICAgICAgIGlnZF9vcHJl
Z2lvbiA+PiBYQ19QQUdFX1NISUZULAotICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+
PiBYQ19QQUdFX1NISUZULAotICAgICAgICAgICAgICAgIDIsCi0gICAgICAgICAgICAgICAg
RFBDSV9BRERfTUFQUElORyk7Ci0gICAgICAgIFBUX0xPRygicmVnaXN0ZXJfdmdhOiBpZ2Rf
b3ByZWdpb24gPSAleFxuIiwgaWdkX29wcmVnaW9uKTsKKyAgICBjYXNlIFBDSV9WRU5ET1Jf
SURfSU5URUw6CisgICAgICAgIHJldCA9IGlnZF9yZWdpc3Rlcl92Z2FfcmVnaW9ucyhyZWFs
X2RldmljZSk7CisgICAgICAgIGJyZWFrOworICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9BVEk6
CisgICAgY2FzZSBQQ0lfVkVORE9SX0lEX0FNRDoKKyAgICAgICAgcmV0ID0gYXRpX3JlZ2lz
dGVyX3ZnYV9yZWdpb25zKHJlYWxfZGV2aWNlKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVm
YXVsdDoKKyAgICAgICAgUFRfTE9HKCJnZnggY2FyZCB3YXNuJ3Qgc3VwcG9ydGVkIGJ5IFhl
biBwYXNzdGhydSFcbiIpOworICAgICAgICByZXQgPSAxOworICAgICAgICBicmVhazsKICAg
ICB9CiAKICAgICBpZiAoIHJldCAhPSAwICkKQEAgLTE3MSwzMyArNDgyLDM2IEBAIGludCBy
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkKICAqLwog
aW50IHVucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up
CiB7Ci0gICAgdTMyIHZlbmRvcl9pZCwgaWdkX29wcmVnaW9uOwogICAgIGludCByZXQgPSAw
OwogCiAgICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8IHJlYWxfZGV2aWNlLT5wY2lfZGV2LT5k
ZXZpY2VfY2xhc3MgIT0gMHgwMzAwICkKICAgICAgICAgcmV0dXJuIHJldDsKIAorICAgIC8q
IGxlZ2FjeSBJL08gcG9ydHMgMHgzQjAgLSAweDNCQyAqLwogICAgIHJldCB8PSB4Y19kb21h
aW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQjAsCiAgICAgICAgICAg
ICAweDNCMCwgMHhDLCBEUENJX1JFTU9WRV9NQVBQSU5HKTsKIAotICAgIHJldCB8PSB4Y19k
b21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCi0gICAgICAg
ICAgICAweDNDMCwgMHgyMCwgRFBDSV9SRU1PVkVfTUFQUElORyk7Ci0KKyAgICAvKiBsZWdh
Y3kgdmlkZW8gTU1JTyByYW5nZSAweEEwMDAwIC0gMHhCRkZGRiAqLwogICAgIHJldCB8PSB4
Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKICAgICAgICAgICAg
IDB4YTAwMDAgPj4gWENfUEFHRV9TSElGVCwKICAgICAgICAgICAgIDB4YTAwMDAgPj4gWENf
UEFHRV9TSElGVCwKICAgICAgICAgICAgIDIwLAogICAgICAgICAgICAgRFBDSV9SRU1PVkVf
TUFQUElORyk7CiAKLSAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2
aWNlLT5wY2lfZGV2LCBQQ0lfVkVORE9SX0lELCAyKTsKLSAgICBpZ2Rfb3ByZWdpb24gPSBw
dF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJ
T04sIDQpOwotICAgIGlmICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAm
JiBpZ2Rfb3ByZWdpb24gKQorICAgIC8qIE90aGVyIFZHQSByZWdpb25zIGFyZSB2ZW5kb3Ig
c3BlY2lmaWMgKi8KKyAgICBzd2l0Y2goIHJlYWxfZGV2aWNlLT5wY2lfZGV2LT52ZW5kb3Jf
aWQgKSAKICAgICB7Ci0gICAgICAgIHJldCB8PSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmco
eGNfaGFuZGxlLCBkb21pZCwKLSAgICAgICAgICAgICAgICBpZ2Rfb3ByZWdpb24gPj4gWENf
UEFHRV9TSElGVCwKLSAgICAgICAgICAgICAgICBpZ2Rfb3ByZWdpb24gPj4gWENfUEFHRV9T
SElGVCwKLSAgICAgICAgICAgICAgICAyLAotICAgICAgICAgICAgICAgIERQQ0lfUkVNT1ZF
X01BUFBJTkcpOworICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9JTlRFTDoKKyAgICAgICAgcmV0
ID0gaWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMocmVhbF9kZXZpY2UpOworICAgICAgICBi
cmVhazsKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQVRJOgorICAgIGNhc2UgUENJX1ZFTkRP
Ul9JRF9BTUQ6CisgICAgICAgIHJldCA9IGF0aV91bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHJl
YWxfZGV2aWNlKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAgICAgICAgUFRf
TE9HKCJnZnggY2FyZCB3YXNuJ3Qgc3VwcG9ydGVkIGJ5IFhlbiBwYXNzdGhydSFcbiIpOwor
ICAgICAgICByZXQgPSAxOworICAgICAgICBicmVhazsKICAgICB9CiAKICAgICBpZiAoIHJl
dCAhPSAwICkKQEAgLTI2NywxMiArNTgxLDEyIEBAIGludCBzZXR1cF92Z2FfcHQoc3RydWN0
IHB0X2RldiAqcmVhbF9kZXZpY2UpCiAgICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8IHJlYWxf
ZGV2aWNlLT5wY2lfZGV2LT5kZXZpY2VfY2xhc3MgIT0gMHgwMzAwICkKICAgICAgICAgcmV0
dXJuIHJjOwogCi0gICAgLyogQWxsb2NhdGVkIDY0SyBmb3IgdGhlIHZnYSBiaW9zICovCi0g
ICAgaWYgKCAhKGJpb3MgPSBtYWxsb2MoNjQgKiAxMDI0KSkgKQorICAgIC8qIEFsbG9jYXRl
ZCAxMjhLIGZvciB0aGUgdmdhIGJpb3MgKi8KKyAgICBpZiAoICEoYmlvcyA9IG1hbGxvYygx
MjggKiAxMDI0KSkgKQogICAgICAgICByZXR1cm4gLTE7CiAKICAgICBiaW9zX3NpemUgPSBn
ZXRfdmdhYmlvcyhiaW9zKTsKLSAgICBpZiAoIGJpb3Nfc2l6ZSA9PSAwIHx8IGJpb3Nfc2l6
ZSA+IDY0ICogMTAyNCkKKyAgICBpZiAoIGJpb3Nfc2l6ZSA9PSAwIHx8IGJpb3Nfc2l6ZSA+
IDEyOCAqIDEwMjQpCiAgICAgewogICAgICAgICBQVF9MT0coInZnYSBiaW9zIHNpemUgKDB4
JXgpIGlzIGludmFsaWQhXG4iLCBiaW9zX3NpemUpOwogICAgICAgICByYyA9IC0xOwo=
--------------040704040500050502070708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040704040500050502070708--


From xen-devel-bounces@lists.xen.org Wed Apr 04 00:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 00:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFDzy-0004lC-5e; Wed, 04 Apr 2012 00:22:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFDzx-0004l7-24
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 00:22:53 +0000
Received: from [85.158.143.99:50520] by server-1.bemta-4.messagelabs.com id
	40/28-20925-C549B7F4; Wed, 04 Apr 2012 00:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1333498971!15864145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3915 invoked from network); 4 Apr 2012 00:22:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 00:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,366,1330905600"; d="scan'208";a="11756586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 00:22:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 01:22:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFDzu-000157-SJ;
	Wed, 04 Apr 2012 00:22:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFDzs-0001zk-H9;
	Wed, 04 Apr 2012 01:22:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12555-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 01:22:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12555: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12555 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12555/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 5230
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail blocked in 5230

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass

version targeted for testing:
 xen                  cbe8948799bf
baseline version:
 xen                  9b453f96dd46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 00:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 00:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFDzy-0004lC-5e; Wed, 04 Apr 2012 00:22:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFDzx-0004l7-24
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 00:22:53 +0000
Received: from [85.158.143.99:50520] by server-1.bemta-4.messagelabs.com id
	40/28-20925-C549B7F4; Wed, 04 Apr 2012 00:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1333498971!15864145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3915 invoked from network); 4 Apr 2012 00:22:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 00:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,366,1330905600"; d="scan'208";a="11756586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 00:22:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 01:22:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFDzu-000157-SJ;
	Wed, 04 Apr 2012 00:22:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFDzs-0001zk-H9;
	Wed, 04 Apr 2012 01:22:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12555-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 01:22:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12555: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12555 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12555/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 5230
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail blocked in 5230

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass

version targeted for testing:
 xen                  cbe8948799bf
baseline version:
 xen                  9b453f96dd46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 02:15:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 02:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFFke-0001As-8b; Wed, 04 Apr 2012 02:15:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SFFkc-0001Ak-KS
	for Xen-devel@lists.xensource.com; Wed, 04 Apr 2012 02:15:10 +0000
Received: from [85.158.143.35:10080] by server-1.bemta-4.messagelabs.com id
	A9/01-20925-CAEAB7F4; Wed, 04 Apr 2012 02:15:08 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333505706!17084187!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzY2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22963 invoked from network); 4 Apr 2012 02:15:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Apr 2012 02:15:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q342ExfG029756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Apr 2012 02:15:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q342Ewhf020053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Apr 2012 02:14:58 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q342EvJF003466; Tue, 3 Apr 2012 21:14:57 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 19:14:57 -0700
Date: Tue, 3 Apr 2012 19:14:55 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120403191455.6967e409@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A02020B.4F7BAEA5.0008,ss=1,re=0.000,fgs=0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [question]: __gnttab_map_grant_ref()  and  iommu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I'm not able to figure why __gnttab_map_grant_ref() does PV iommu
mappings for GNTMAP_host_map. Should it not check for GNTMAP_device_map
and do for those only?

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 02:15:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 02:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFFke-0001As-8b; Wed, 04 Apr 2012 02:15:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SFFkc-0001Ak-KS
	for Xen-devel@lists.xensource.com; Wed, 04 Apr 2012 02:15:10 +0000
Received: from [85.158.143.35:10080] by server-1.bemta-4.messagelabs.com id
	A9/01-20925-CAEAB7F4; Wed, 04 Apr 2012 02:15:08 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333505706!17084187!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzY2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22963 invoked from network); 4 Apr 2012 02:15:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Apr 2012 02:15:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q342ExfG029756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Apr 2012 02:15:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q342Ewhf020053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Apr 2012 02:14:58 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q342EvJF003466; Tue, 3 Apr 2012 21:14:57 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Apr 2012 19:14:57 -0700
Date: Tue, 3 Apr 2012 19:14:55 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120403191455.6967e409@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A02020B.4F7BAEA5.0008,ss=1,re=0.000,fgs=0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [question]: __gnttab_map_grant_ref()  and  iommu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I'm not able to figure why __gnttab_map_grant_ref() does PV iommu
mappings for GNTMAP_host_map. Should it not check for GNTMAP_device_map
and do for those only?

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 02:42:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 02:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFGAZ-0001Nm-JF; Wed, 04 Apr 2012 02:41:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFGAY-0001Nh-1F
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 02:41:58 +0000
Received: from [85.158.143.35:11511] by server-2.bemta-4.messagelabs.com id
	C0/9C-17550-5F4BB7F4; Wed, 04 Apr 2012 02:41:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333507316!14605084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12010 invoked from network); 4 Apr 2012 02:41:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 02:41:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,366,1330905600"; d="scan'208";a="11756989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 02:41:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 03:41:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFGAV-0001xa-DJ;
	Wed, 04 Apr 2012 02:41:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFGAV-0001WJ-Bj;
	Wed, 04 Apr 2012 03:41:55 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12556-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 03:41:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12556: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12556 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12556/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 02:42:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 02:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFGAZ-0001Nm-JF; Wed, 04 Apr 2012 02:41:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFGAY-0001Nh-1F
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 02:41:58 +0000
Received: from [85.158.143.35:11511] by server-2.bemta-4.messagelabs.com id
	C0/9C-17550-5F4BB7F4; Wed, 04 Apr 2012 02:41:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333507316!14605084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12010 invoked from network); 4 Apr 2012 02:41:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 02:41:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,366,1330905600"; d="scan'208";a="11756989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 02:41:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 03:41:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFGAV-0001xa-DJ;
	Wed, 04 Apr 2012 02:41:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFGAV-0001WJ-Bj;
	Wed, 04 Apr 2012 03:41:55 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12556-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 03:41:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12556: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12556 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12556/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 05:47:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 05:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFJ3F-0002YZ-Nl; Wed, 04 Apr 2012 05:46:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFJ3E-0002YU-Ob
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 05:46:37 +0000
Received: from [85.158.139.83:5680] by server-1.bemta-5.messagelabs.com id
	A7/D6-28458-B30EB7F4; Wed, 04 Apr 2012 05:46:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333518395!21716240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjgzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15978 invoked from network); 4 Apr 2012 05:46:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 05:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="11758405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 05:46:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 06:46:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFJ3C-0003Bh-9n;
	Wed, 04 Apr 2012 05:46:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFJ3C-0006OX-6K;
	Wed, 04 Apr 2012 06:46:34 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12558-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 06:46:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12558: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12558 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12558/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 05:47:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 05:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFJ3F-0002YZ-Nl; Wed, 04 Apr 2012 05:46:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFJ3E-0002YU-Ob
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 05:46:37 +0000
Received: from [85.158.139.83:5680] by server-1.bemta-5.messagelabs.com id
	A7/D6-28458-B30EB7F4; Wed, 04 Apr 2012 05:46:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333518395!21716240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjgzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15978 invoked from network); 4 Apr 2012 05:46:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 05:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="11758405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 05:46:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 06:46:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFJ3C-0003Bh-9n;
	Wed, 04 Apr 2012 05:46:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFJ3C-0006OX-6K;
	Wed, 04 Apr 2012 06:46:34 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12558-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 06:46:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12558: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12558 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12558/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 07:30:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 07:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFKeP-0003Am-54; Wed, 04 Apr 2012 07:29:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFKeN-0003Ah-8m
	for Xen-devel@lists.xensource.com; Wed, 04 Apr 2012 07:29:03 +0000
Received: from [85.158.143.35:19163] by server-1.bemta-4.messagelabs.com id
	67/F0-20925-E38FB7F4; Wed, 04 Apr 2012 07:29:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1333524541!4051087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11480 invoked from network); 4 Apr 2012 07:29:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 07:29:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="11759710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 07:29:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	08:29:00 +0100
Message-ID: <1333524539.12209.20.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 4 Apr 2012 08:28:59 +0100
In-Reply-To: <20120403191455.6967e409@mantra.us.oracle.com>
References: <20120403191455.6967e409@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [question]: __gnttab_map_grant_ref()  and  iommu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-04 at 03:14 +0100, Mukesh Rathor wrote:
> I'm not able to figure why __gnttab_map_grant_ref() does PV iommu
> mappings for GNTMAP_host_map. Should it not check for GNTMAP_device_map
> and do for those only?

I don't know but perhaps it is because when the backend maps a foreign
page there is a reasonably high chance that it is eventually going to
end up passing that page to a hardware device (e.g. a physical NIC or
disk controller) for DMA and therefore the mapping must be reflected in
the IOMMU.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 07:30:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 07:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFKeP-0003Am-54; Wed, 04 Apr 2012 07:29:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFKeN-0003Ah-8m
	for Xen-devel@lists.xensource.com; Wed, 04 Apr 2012 07:29:03 +0000
Received: from [85.158.143.35:19163] by server-1.bemta-4.messagelabs.com id
	67/F0-20925-E38FB7F4; Wed, 04 Apr 2012 07:29:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1333524541!4051087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11480 invoked from network); 4 Apr 2012 07:29:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 07:29:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="11759710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 07:29:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	08:29:00 +0100
Message-ID: <1333524539.12209.20.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 4 Apr 2012 08:28:59 +0100
In-Reply-To: <20120403191455.6967e409@mantra.us.oracle.com>
References: <20120403191455.6967e409@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [question]: __gnttab_map_grant_ref()  and  iommu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-04 at 03:14 +0100, Mukesh Rathor wrote:
> I'm not able to figure why __gnttab_map_grant_ref() does PV iommu
> mappings for GNTMAP_host_map. Should it not check for GNTMAP_device_map
> and do for those only?

I don't know but perhaps it is because when the backend maps a foreign
page there is a reasonably high chance that it is eventually going to
end up passing that page to a hardware device (e.g. a physical NIC or
disk controller) for DMA and therefore the mapping must be reflected in
the IOMMU.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 08:16:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 08:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFLNH-0003vW-BW; Wed, 04 Apr 2012 08:15:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFLNF-0003vR-4o
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 08:15:25 +0000
Received: from [85.158.139.83:37172] by server-12.bemta-5.messagelabs.com id
	80/6E-05587-C130C7F4; Wed, 04 Apr 2012 08:15:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333527322!22413913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjgzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25881 invoked from network); 4 Apr 2012 08:15:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 08:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="11760778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 08:14:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 09:14:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFLMk-0004So-VD;
	Wed, 04 Apr 2012 08:14:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFLMk-0001c0-SG;
	Wed, 04 Apr 2012 09:14:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12559-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 09:14:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12559: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12559 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12559/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2     fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  ed48258053ae

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 08:16:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 08:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFLNH-0003vW-BW; Wed, 04 Apr 2012 08:15:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFLNF-0003vR-4o
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 08:15:25 +0000
Received: from [85.158.139.83:37172] by server-12.bemta-5.messagelabs.com id
	80/6E-05587-C130C7F4; Wed, 04 Apr 2012 08:15:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333527322!22413913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjgzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25881 invoked from network); 4 Apr 2012 08:15:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 08:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="11760778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 08:14:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 09:14:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFLMk-0004So-VD;
	Wed, 04 Apr 2012 08:14:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFLMk-0001c0-SG;
	Wed, 04 Apr 2012 09:14:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12559-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 09:14:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12559: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12559 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12559/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2     fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  ed48258053ae

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMGk-0004F9-4l; Wed, 04 Apr 2012 09:12:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMGi-0004F4-F2
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:12:44 +0000
Received: from [85.158.143.35:29347] by server-2.bemta-4.messagelabs.com id
	4E/A6-17550-B801C7F4; Wed, 04 Apr 2012 09:12:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333530760!11797982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5491 invoked from network); 4 Apr 2012 09:12:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:12:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11762329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:12:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:12:40 +0100
Message-ID: <1333530758.10586.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 4 Apr 2012 10:12:38 +0100
In-Reply-To: <0fb728d56baeaed476d2.1333477788@kodo2>
References: <0fb728d56baeaed476d2.1333477788@kodo2>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 19:29 +0100, George Dunlap wrote:
> Since the key information can be fairly simply put on the command-line,
> there's no need to require an actual config file.
> 
> Also improve the help to cross-reference the xlcpupool.cfg manpage.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Code looks good to me, couple of comments on the docs aspects below.

> diff -r 30cc13e25e01 -r 0fb728d56bae docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Tue Apr 03 19:02:19 2012 +0100
> +++ b/docs/man/xl.pod.1	Tue Apr 03 19:28:04 2012 +0100
> @@ -848,11 +848,13 @@ Cpu-pools can be specified either by nam
>  
>  =over 4
>  
> -=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile> [I<Variable=Value> ...]
> +=item B<cpupool-create> [I<OPTIONS>] [I<ConfigFile>] [I<Variable=Value> ...]
>  
> -Create a cpu pool based an I<ConfigFile>.
> +Create a cpu pool based an config from a I<ConfigFile> or command-line parameters.
>  Variable settings from the I<ConfigFile> may be altered by specifying new
> -or additional assignments on the command line.
> +or additional assignments on the command line.

Could do with rewrapping? Or a blank line between the paras if that's
what they are meant to be (that's prexisting in that case)

> +
> +See the xlcpupool.cfg manpage for more information.

I think this should be "L<xlcpupool.cfg(N)>" in here. (N for whichever
section the manpage is in).

 
> diff -r 30cc13e25e01 -r 0fb728d56bae tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:02:19 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:28:04 2012 +0100
> @@ -364,12 +364,14 @@ struct cmd_spec cmd_table[] = {
>      },
>      { "cpupool-create",
>        &main_cpupoolcreate, 1,
> -      "Create a CPU pool based an ConfigFile",
> -      "[options] <ConfigFile> [vars]",
> +      "Create a new CPU pool",
> +      "[options] [<ConfigFile>] [Variable=value ...]",
>        "-h, --help                   Print this help.\n"
>        "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
>        "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
> -      "                              (deprecated in favour of global -N option)."
> +      "                              (deprecated in favour of global -N option).\n"
> +      "\nSee the xlcpupool.cfg manpage for more information.",

xlcpupool.cfg(N) here too.

> +
>      },
>      { "cpupool-list",
>        &main_cpupoollist, 0,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMGk-0004F9-4l; Wed, 04 Apr 2012 09:12:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMGi-0004F4-F2
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:12:44 +0000
Received: from [85.158.143.35:29347] by server-2.bemta-4.messagelabs.com id
	4E/A6-17550-B801C7F4; Wed, 04 Apr 2012 09:12:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333530760!11797982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5491 invoked from network); 4 Apr 2012 09:12:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:12:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11762329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:12:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:12:40 +0100
Message-ID: <1333530758.10586.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 4 Apr 2012 10:12:38 +0100
In-Reply-To: <0fb728d56baeaed476d2.1333477788@kodo2>
References: <0fb728d56baeaed476d2.1333477788@kodo2>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-03 at 19:29 +0100, George Dunlap wrote:
> Since the key information can be fairly simply put on the command-line,
> there's no need to require an actual config file.
> 
> Also improve the help to cross-reference the xlcpupool.cfg manpage.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Code looks good to me, couple of comments on the docs aspects below.

> diff -r 30cc13e25e01 -r 0fb728d56bae docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Tue Apr 03 19:02:19 2012 +0100
> +++ b/docs/man/xl.pod.1	Tue Apr 03 19:28:04 2012 +0100
> @@ -848,11 +848,13 @@ Cpu-pools can be specified either by nam
>  
>  =over 4
>  
> -=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile> [I<Variable=Value> ...]
> +=item B<cpupool-create> [I<OPTIONS>] [I<ConfigFile>] [I<Variable=Value> ...]
>  
> -Create a cpu pool based an I<ConfigFile>.
> +Create a cpu pool based an config from a I<ConfigFile> or command-line parameters.
>  Variable settings from the I<ConfigFile> may be altered by specifying new
> -or additional assignments on the command line.
> +or additional assignments on the command line.

Could do with rewrapping? Or a blank line between the paras if that's
what they are meant to be (that's prexisting in that case)

> +
> +See the xlcpupool.cfg manpage for more information.

I think this should be "L<xlcpupool.cfg(N)>" in here. (N for whichever
section the manpage is in).

 
> diff -r 30cc13e25e01 -r 0fb728d56bae tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:02:19 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c	Tue Apr 03 19:28:04 2012 +0100
> @@ -364,12 +364,14 @@ struct cmd_spec cmd_table[] = {
>      },
>      { "cpupool-create",
>        &main_cpupoolcreate, 1,
> -      "Create a CPU pool based an ConfigFile",
> -      "[options] <ConfigFile> [vars]",
> +      "Create a new CPU pool",
> +      "[options] [<ConfigFile>] [Variable=value ...]",
>        "-h, --help                   Print this help.\n"
>        "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
>        "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
> -      "                              (deprecated in favour of global -N option)."
> +      "                              (deprecated in favour of global -N option).\n"
> +      "\nSee the xlcpupool.cfg manpage for more information.",

xlcpupool.cfg(N) here too.

> +
>      },
>      { "cpupool-list",
>        &main_cpupoollist, 0,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMXu-0004Pb-Rp; Wed, 04 Apr 2012 09:30:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMXt-0004PW-C4
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:30:29 +0000
Received: from [85.158.139.83:28195] by server-12.bemta-5.messagelabs.com id
	28/90-05587-4B41C7F4; Wed, 04 Apr 2012 09:30:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333531827!22433207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15726 invoked from network); 4 Apr 2012 09:30:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11763099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:30:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:30:17 +0100
Message-ID: <1333531815.20300.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 4 Apr 2012 10:30:15 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Seems like this thread slipped through the cracks, sorry about that.
Please do give us a prod (e.g. a ping message) after a few days/a week
when this happens.

On Thu, 2012-03-22 at 14:03 +0000, Ross Philipson wrote:
> -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: Thursday, March 22, 2012 7:26 AM
> > To: Keir Fraser
> > Cc: xen-devel@lists.xensource.com; Ian Campbell; Ross Philipson
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > Hi,
> > 
> > At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote:
> > > My impression from the earlier discussions is that we're pasing
> > > largish blobs of binary BIOS goop around, which aren't suitable to go
> > > into xenstore.  Dropping them in memory where HVMloader can pick them
> > > up seems reasonable.
> > >
> > > All the control-path stuff - what the blobs are, where they are &c,
> > > should go through Xenstore, though.
> > 
> > So having looked at the code, I think the module system is really
> > overkill - AIUI all the things you're talking about passing through are
> > ACPI tables, which have their own length fields internally. So all
> 
> Ok well fair enough. I can go back and do it again, making something
> smaller. For the record, I am passing in more than just ACPI tables; I
> am passing in parts of the SMBIOS tables. Each of the SMBIOS types
> does not actually report its length but rather you have to parse them
> for the double terminator after the string section. I guess it seems a
> shame to have to do that parse logic in two places.

I think Tim was suggesting that in xs this looks something like:
	.../hvmloader/acpi/address 
	(no .../acpi/length length? encoded in tables)
	.../hvmloader/smbios/address
	.../hvmloader/smbios/length
	.../hvmloader/some-other/{address,length?}...

with the data at the referenced addresses.

If it's convenient (or even just for consistency) there's no reason IMHO
not to include the length even where the length is part of the data.
Similarly you can add checksums etc if those are useful.

> > you'd need to do is have a type code and an address in xenstore
> > somewhere, the same way we pass a type code and a string for the other
> > BIOS customizations.
> > 
> 
> So I am not exactly sure how to proceed here since libxc seems the
> correct place to load the individual blobs (ACPI tables, SMBIOS junk)
> but libxc seems too low level to be writing values to xenstore (and it
> does not do that at present). Would it be better to have a peer API to
> xc_hvm_build() that write the chunks and returns the addresses where
> it loaded them? Or should it be totally moved out of libxc? Advice
> would be appreciated...

The layering relationship between libxc and libxs here is a bit of a
pain, but lets not try and solve that now.

I think you can just add a guest_address field to your struct
xc_hvm_module as an output field which the caller would then push into
xenstore along with the (potentially updated) length field.

Given the above XS layout then I think where you have a list of modules in
xc_hvm_build_args you can just have "struct xc_hvm_module acpi".
Similarly for smbios and whatever new table types come up in the future.
I don't think having each module type explicitly here matters since each
new table type needs a bunch of support code in at least hvmloader
anyway so adding a few lines to libxc to expose it at the same time is
fine.

> Finally, I had made this a generic framework because I thought it
> could be extended in the future to pass in other types of firmware-ish
> blobs at runtime. It also handles the case where the passing of one
> set of tables/blobs is not tied to passing another set. E.g. in our
> work we pass in some static ACPI tables to satisfy one feature and
> construct/pass-in an SSDT to satisfy another unrelated feature.

I think it is ok to have it be up to the caller to glom those together
into a single "ACPI" blob which is processed by hvmloader into the right
places. Or is there a problem with that which hasn't occurred to me?
(Likewise in the SMBIOS case)

If it is a problem then
	.../acpi/0/...
	.../acpi/1/...
(or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things. Not
sure about the libxc level, I'll worry about it when you tell me what
I've missed which makes it necessary ;-)


Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMXu-0004Pb-Rp; Wed, 04 Apr 2012 09:30:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMXt-0004PW-C4
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:30:29 +0000
Received: from [85.158.139.83:28195] by server-12.bemta-5.messagelabs.com id
	28/90-05587-4B41C7F4; Wed, 04 Apr 2012 09:30:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333531827!22433207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15726 invoked from network); 4 Apr 2012 09:30:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11763099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:30:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:30:17 +0100
Message-ID: <1333531815.20300.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 4 Apr 2012 10:30:15 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Seems like this thread slipped through the cracks, sorry about that.
Please do give us a prod (e.g. a ping message) after a few days/a week
when this happens.

On Thu, 2012-03-22 at 14:03 +0000, Ross Philipson wrote:
> -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: Thursday, March 22, 2012 7:26 AM
> > To: Keir Fraser
> > Cc: xen-devel@lists.xensource.com; Ian Campbell; Ross Philipson
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > Hi,
> > 
> > At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote:
> > > My impression from the earlier discussions is that we're pasing
> > > largish blobs of binary BIOS goop around, which aren't suitable to go
> > > into xenstore.  Dropping them in memory where HVMloader can pick them
> > > up seems reasonable.
> > >
> > > All the control-path stuff - what the blobs are, where they are &c,
> > > should go through Xenstore, though.
> > 
> > So having looked at the code, I think the module system is really
> > overkill - AIUI all the things you're talking about passing through are
> > ACPI tables, which have their own length fields internally. So all
> 
> Ok well fair enough. I can go back and do it again, making something
> smaller. For the record, I am passing in more than just ACPI tables; I
> am passing in parts of the SMBIOS tables. Each of the SMBIOS types
> does not actually report its length but rather you have to parse them
> for the double terminator after the string section. I guess it seems a
> shame to have to do that parse logic in two places.

I think Tim was suggesting that in xs this looks something like:
	.../hvmloader/acpi/address 
	(no .../acpi/length length? encoded in tables)
	.../hvmloader/smbios/address
	.../hvmloader/smbios/length
	.../hvmloader/some-other/{address,length?}...

with the data at the referenced addresses.

If it's convenient (or even just for consistency) there's no reason IMHO
not to include the length even where the length is part of the data.
Similarly you can add checksums etc if those are useful.

> > you'd need to do is have a type code and an address in xenstore
> > somewhere, the same way we pass a type code and a string for the other
> > BIOS customizations.
> > 
> 
> So I am not exactly sure how to proceed here since libxc seems the
> correct place to load the individual blobs (ACPI tables, SMBIOS junk)
> but libxc seems too low level to be writing values to xenstore (and it
> does not do that at present). Would it be better to have a peer API to
> xc_hvm_build() that write the chunks and returns the addresses where
> it loaded them? Or should it be totally moved out of libxc? Advice
> would be appreciated...

The layering relationship between libxc and libxs here is a bit of a
pain, but lets not try and solve that now.

I think you can just add a guest_address field to your struct
xc_hvm_module as an output field which the caller would then push into
xenstore along with the (potentially updated) length field.

Given the above XS layout then I think where you have a list of modules in
xc_hvm_build_args you can just have "struct xc_hvm_module acpi".
Similarly for smbios and whatever new table types come up in the future.
I don't think having each module type explicitly here matters since each
new table type needs a bunch of support code in at least hvmloader
anyway so adding a few lines to libxc to expose it at the same time is
fine.

> Finally, I had made this a generic framework because I thought it
> could be extended in the future to pass in other types of firmware-ish
> blobs at runtime. It also handles the case where the passing of one
> set of tables/blobs is not tied to passing another set. E.g. in our
> work we pass in some static ACPI tables to satisfy one feature and
> construct/pass-in an SSDT to satisfy another unrelated feature.

I think it is ok to have it be up to the caller to glom those together
into a single "ACPI" blob which is processed by hvmloader into the right
places. Or is there a problem with that which hasn't occurred to me?
(Likewise in the SMBIOS case)

If it is a problem then
	.../acpi/0/...
	.../acpi/1/...
(or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things. Not
sure about the libxc level, I'll worry about it when you tell me what
I've missed which makes it necessary ;-)


Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMYF-0004Qe-7y; Wed, 04 Apr 2012 09:30:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMYE-0004QY-Jd
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:30:50 +0000
Received: from [85.158.143.99:5141] by server-1.bemta-4.messagelabs.com id
	C6/14-20925-9C41C7F4; Wed, 04 Apr 2012 09:30:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333531849!17044370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29046 invoked from network); 4 Apr 2012 09:30:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:30:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11763124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:30:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:30:49 +0100
Message-ID: <1333531847.20300.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 4 Apr 2012 10:30:47 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
 init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> diff -r 45d2dcc22c18 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:42:36
> 2012 -0400
> +++ b/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:45:12
> 2012 -0400
> @@ -23,6 +23,7 @@
>  #include "util.h"
>  #include "hypercall.h"
>  #include "config.h"
> +#include "modules.h"
>  #include "pci_regs.h"
>  #include "apic_regs.h"
>  #include "acpi/acpi2_0.h"
> @@ -257,6 +258,17 @@ int main(void)
>  {
>      const struct bios_config *bios;
>      int acpi_enabled;
> +    uint32_t mod_lo, mod_hi;
> +    uint64_t mod_base;
> +
> +    /* First get the modules base address passed in ECX:EDC and init
> +     * module support.
> +     */
> +    asm volatile ( "mov %%ecx, %0;" : "=r"(mod_hi));
> +    asm volatile ( "mov %%edx, %0;" : "=r"(mod_lo));

I'm not sure you can rely on %ecx and %edx not having been clobbered
here. I think you probably need to save away the value in the ASM block
at the head of hvmloader.c if we continue down this path.

In fact, it looks like that ASM block deliberately zeroes ecx and edx so how
does this work?

> +    mod_base = mod_hi;
> +    mod_base = (0xFFFFFFFF00000000 & (mod_base << 32)) | mod_lo;
> +    init_hvm_modules(mod_base);
>  
>      /* Initialise hypercall stubs with RET, rendering them no-ops. */
>      memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */,
> PAGE_SIZE); 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMYF-0004Qe-7y; Wed, 04 Apr 2012 09:30:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMYE-0004QY-Jd
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:30:50 +0000
Received: from [85.158.143.99:5141] by server-1.bemta-4.messagelabs.com id
	C6/14-20925-9C41C7F4; Wed, 04 Apr 2012 09:30:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333531849!17044370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29046 invoked from network); 4 Apr 2012 09:30:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:30:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11763124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:30:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:30:49 +0100
Message-ID: <1333531847.20300.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 4 Apr 2012 10:30:47 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
 init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> diff -r 45d2dcc22c18 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:42:36
> 2012 -0400
> +++ b/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:45:12
> 2012 -0400
> @@ -23,6 +23,7 @@
>  #include "util.h"
>  #include "hypercall.h"
>  #include "config.h"
> +#include "modules.h"
>  #include "pci_regs.h"
>  #include "apic_regs.h"
>  #include "acpi/acpi2_0.h"
> @@ -257,6 +258,17 @@ int main(void)
>  {
>      const struct bios_config *bios;
>      int acpi_enabled;
> +    uint32_t mod_lo, mod_hi;
> +    uint64_t mod_base;
> +
> +    /* First get the modules base address passed in ECX:EDC and init
> +     * module support.
> +     */
> +    asm volatile ( "mov %%ecx, %0;" : "=r"(mod_hi));
> +    asm volatile ( "mov %%edx, %0;" : "=r"(mod_lo));

I'm not sure you can rely on %ecx and %edx not having been clobbered
here. I think you probably need to save away the value in the ASM block
at the head of hvmloader.c if we continue down this path.

In fact, it looks like that ASM block deliberately zeroes ecx and edx so how
does this work?

> +    mod_base = mod_hi;
> +    mod_base = (0xFFFFFFFF00000000 & (mod_base << 32)) | mod_lo;
> +    init_hvm_modules(mod_base);
>  
>      /* Initialise hypercall stubs with RET, rendering them no-ops. */
>      memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */,
> PAGE_SIZE); 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:33:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMaZ-0004dN-PR; Wed, 04 Apr 2012 09:33:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMaY-0004dH-IS
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:33:14 +0000
Received: from [85.158.143.99:11273] by server-2.bemta-4.messagelabs.com id
	E9/8C-17550-9551C7F4; Wed, 04 Apr 2012 09:33:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333531993!17004217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9712 invoked from network); 4 Apr 2012 09:33:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:33:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11763220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:33:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:33:12 +0100
Message-ID: <1333531991.20300.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 4 Apr 2012 10:33:11 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAF@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAF@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen control
 tools support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> diff -r e87559f0de44 tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h    Mon Mar 19 16:57:55 2012 -0400
> +++ b/tools/libxc/xenguest.h    Mon Mar 19 17:02:33 2012 -0400
> @@ -176,6 +176,8 @@ struct xc_hvm_build_args {
>      uint64_t mem_target;         /* Memory target in bytes. */
>      uint64_t mmio_size;          /* Size of the MMIO hole in bytes.
> */
>      const char *image_file_name; /* File name of the image to load.
> */
> +    const char **module_names;   /* List of HVM module files to load.
> */
> +    uint32_t module_count;       /* Count of HVM modules. */
>  };

Why files rather than pointers to data in memory? A pointer would be
easier if you wanted to construct a table on the fly and you could still
provide a helper function for the caller to load a file too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:33:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMaZ-0004dN-PR; Wed, 04 Apr 2012 09:33:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMaY-0004dH-IS
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:33:14 +0000
Received: from [85.158.143.99:11273] by server-2.bemta-4.messagelabs.com id
	E9/8C-17550-9551C7F4; Wed, 04 Apr 2012 09:33:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333531993!17004217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9712 invoked from network); 4 Apr 2012 09:33:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:33:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11763220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:33:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:33:12 +0100
Message-ID: <1333531991.20300.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 4 Apr 2012 10:33:11 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAF@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAF@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen control
 tools support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> diff -r e87559f0de44 tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h    Mon Mar 19 16:57:55 2012 -0400
> +++ b/tools/libxc/xenguest.h    Mon Mar 19 17:02:33 2012 -0400
> @@ -176,6 +176,8 @@ struct xc_hvm_build_args {
>      uint64_t mem_target;         /* Memory target in bytes. */
>      uint64_t mmio_size;          /* Size of the MMIO hole in bytes.
> */
>      const char *image_file_name; /* File name of the image to load.
> */
> +    const char **module_names;   /* List of HVM module files to load.
> */
> +    uint32_t module_count;       /* Count of HVM modules. */
>  };

Why files rather than pointers to data in memory? A pointer would be
easier if you wanted to construct a table on the fly and you could still
provide a helper function for the caller to load a file too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:48:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMoY-0004vi-6y; Wed, 04 Apr 2012 09:47:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFMoW-0004vd-5A
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:47:40 +0000
Received: from [85.158.138.51:24414] by server-11.bemta-3.messagelabs.com id
	8B/88-28543-BB81C7F4; Wed, 04 Apr 2012 09:47:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333532857!20742593!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19745 invoked from network); 4 Apr 2012 09:47:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Apr 2012 09:47:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFMoS-0000DY-KH; Wed, 04 Apr 2012 09:47:36 +0000
Date: Wed, 4 Apr 2012 10:47:36 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120404094736.GA99714@ocelot.phlegethon.org>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
	<1333531847.20300.12.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333531847.20300.12.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
	init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:30 +0100 on 04 Apr (1333535447), Ian Campbell wrote:
> On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> > diff -r 45d2dcc22c18 tools/firmware/hvmloader/hvmloader.c
> > --- a/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:42:36
> > 2012 -0400
> > +++ b/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:45:12
> > 2012 -0400
> > @@ -23,6 +23,7 @@
> >  #include "util.h"
> >  #include "hypercall.h"
> >  #include "config.h"
> > +#include "modules.h"
> >  #include "pci_regs.h"
> >  #include "apic_regs.h"
> >  #include "acpi/acpi2_0.h"
> > @@ -257,6 +258,17 @@ int main(void)
> >  {
> >      const struct bios_config *bios;
> >      int acpi_enabled;
> > +    uint32_t mod_lo, mod_hi;
> > +    uint64_t mod_base;
> > +
> > +    /* First get the modules base address passed in ECX:EDC and init
> > +     * module support.
> > +     */
> > +    asm volatile ( "mov %%ecx, %0;" : "=r"(mod_hi));
> > +    asm volatile ( "mov %%edx, %0;" : "=r"(mod_lo));
> 
> I'm not sure you can rely on %ecx and %edx not having been clobbered
> here. I think you probably need to save away the value in the ASM block
> at the head of hvmloader.c if we continue down this path.
> 
> In fact, it looks like that ASM block deliberately zeroes ecx and edx so how
> does this work?

The asm header clears them after calling main().  But yes, you can't
rely on their being still valid; the asm header would have to push them
to the stack as arguments to main().

In any case, this all goes away if the module info is passed in xenstore.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:48:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMoY-0004vi-6y; Wed, 04 Apr 2012 09:47:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFMoW-0004vd-5A
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:47:40 +0000
Received: from [85.158.138.51:24414] by server-11.bemta-3.messagelabs.com id
	8B/88-28543-BB81C7F4; Wed, 04 Apr 2012 09:47:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333532857!20742593!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19745 invoked from network); 4 Apr 2012 09:47:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Apr 2012 09:47:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFMoS-0000DY-KH; Wed, 04 Apr 2012 09:47:36 +0000
Date: Wed, 4 Apr 2012 10:47:36 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120404094736.GA99714@ocelot.phlegethon.org>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
	<1333531847.20300.12.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333531847.20300.12.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
	init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:30 +0100 on 04 Apr (1333535447), Ian Campbell wrote:
> On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> > diff -r 45d2dcc22c18 tools/firmware/hvmloader/hvmloader.c
> > --- a/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:42:36
> > 2012 -0400
> > +++ b/tools/firmware/hvmloader/hvmloader.c      Mon Mar 19 16:45:12
> > 2012 -0400
> > @@ -23,6 +23,7 @@
> >  #include "util.h"
> >  #include "hypercall.h"
> >  #include "config.h"
> > +#include "modules.h"
> >  #include "pci_regs.h"
> >  #include "apic_regs.h"
> >  #include "acpi/acpi2_0.h"
> > @@ -257,6 +258,17 @@ int main(void)
> >  {
> >      const struct bios_config *bios;
> >      int acpi_enabled;
> > +    uint32_t mod_lo, mod_hi;
> > +    uint64_t mod_base;
> > +
> > +    /* First get the modules base address passed in ECX:EDC and init
> > +     * module support.
> > +     */
> > +    asm volatile ( "mov %%ecx, %0;" : "=r"(mod_hi));
> > +    asm volatile ( "mov %%edx, %0;" : "=r"(mod_lo));
> 
> I'm not sure you can rely on %ecx and %edx not having been clobbered
> here. I think you probably need to save away the value in the ASM block
> at the head of hvmloader.c if we continue down this path.
> 
> In fact, it looks like that ASM block deliberately zeroes ecx and edx so how
> does this work?

The asm header clears them after calling main().  But yes, you can't
rely on their being still valid; the asm header would have to push them
to the stack as arguments to main().

In any case, this all goes away if the module info is passed in xenstore.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:51:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:51:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMrb-000539-Uo; Wed, 04 Apr 2012 09:50:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMrb-000533-CY
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:50:51 +0000
Received: from [85.158.138.51:51933] by server-5.bemta-3.messagelabs.com id
	5D/A0-24278-A791C7F4; Wed, 04 Apr 2012 09:50:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333533049!20728590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28739 invoked from network); 4 Apr 2012 09:50:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:50:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11764281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:50:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:50:49 +0100
Message-ID: <1333533047.20582.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 4 Apr 2012 10:50:47 +0100
In-Reply-To: <20120404094736.GA99714@ocelot.phlegethon.org>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
	<1333531847.20300.12.camel@zakaz.uk.xensource.com>
	<20120404094736.GA99714@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
 init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-04 at 10:47 +0100, Tim Deegan wrote:
[...]
> > In fact, it looks like that ASM block deliberately zeroes ecx and edx so how
> > does this work?
> 
> The asm header clears them after calling main().

So it does, I didn't realise that the "go" button in hvmloader was
return from main, subtle!

[...]
> In any case, this all goes away if the module info is passed in xenstore.

Yes.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:51:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:51:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMrb-000539-Uo; Wed, 04 Apr 2012 09:50:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMrb-000533-CY
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 09:50:51 +0000
Received: from [85.158.138.51:51933] by server-5.bemta-3.messagelabs.com id
	5D/A0-24278-A791C7F4; Wed, 04 Apr 2012 09:50:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333533049!20728590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28739 invoked from network); 4 Apr 2012 09:50:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:50:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11764281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 09:50:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012
	10:50:49 +0100
Message-ID: <1333533047.20582.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 4 Apr 2012 10:50:47 +0100
In-Reply-To: <20120404094736.GA99714@ocelot.phlegethon.org>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
	<1333531847.20300.12.camel@zakaz.uk.xensource.com>
	<20120404094736.GA99714@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
 init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-04 at 10:47 +0100, Tim Deegan wrote:
[...]
> > In fact, it looks like that ASM block deliberately zeroes ecx and edx so how
> > does this work?
> 
> The asm header clears them after calling main().

So it does, I didn't realise that the "go" button in hvmloader was
return from main, subtle!

[...]
> In any case, this all goes away if the module info is passed in xenstore.

Yes.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:52:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:52:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMsS-00056q-D8; Wed, 04 Apr 2012 09:51:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMsQ-00056f-Is
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 09:51:42 +0000
Received: from [85.158.138.51:14778] by server-11.bemta-3.messagelabs.com id
	67/B1-28543-DA91C7F4; Wed, 04 Apr 2012 09:51:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333533099!20774652!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31833 invoked from network); 4 Apr 2012 09:51:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="188952724"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 05:51:10 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 05:51:11 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFMru-0003Bw-FD;
	Wed, 04 Apr 2012 10:51:10 +0100
MIME-Version: 1.0
X-Mercurial-Node: d00faeaf21dd280500d2deace00683d884a2dc10
Message-ID: <d00faeaf21dd280500d2.1333533070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 10:51:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: fixup error handling in
	libxl_send_trigger
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1333532948 -3600
# Node ID d00faeaf21dd280500d2deace00683d884a2dc10
# Parent  c99e16a24eabeb6d3ed9f961d35e84acf7cd8cdd
libxl: fixup error handling in libxl_send_trigger

xc_domain_send_trigger returns -1 and sets errno on failure so use
LIBXL__LOG_ERRNO not LIBXL__LOG_ERRNOVAL(rc).

Change the default case of the switch to set rc=-1,errno=EINVAL too.

Also we weren't actually returning the error code we'd decided on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c99e16a24eab -r d00faeaf21dd tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Apr 04 10:37:18 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Apr 04 10:49:08 2012 +0100
@@ -3309,18 +3309,19 @@ int libxl_send_trigger(libxl_ctx *ctx, u
         rc = 0;
         break;
     default:
-        rc = EINVAL;
+        rc = -1;
+        errno = EINVAL;
         break;
     }
 
     if (rc != 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-                            "Send trigger '%s' failed",
-                            libxl_trigger_to_string(trigger));
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "Send trigger '%s' failed",
+                         libxl_trigger_to_string(trigger));
         rc = ERROR_FAIL;
     }
 
-    return 0;
+    return rc;
 }
 
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 09:52:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 09:52:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFMsS-00056q-D8; Wed, 04 Apr 2012 09:51:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFMsQ-00056f-Is
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 09:51:42 +0000
Received: from [85.158.138.51:14778] by server-11.bemta-3.messagelabs.com id
	67/B1-28543-DA91C7F4; Wed, 04 Apr 2012 09:51:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333533099!20774652!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31833 invoked from network); 4 Apr 2012 09:51:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 09:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="188952724"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 05:51:10 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 05:51:11 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFMru-0003Bw-FD;
	Wed, 04 Apr 2012 10:51:10 +0100
MIME-Version: 1.0
X-Mercurial-Node: d00faeaf21dd280500d2deace00683d884a2dc10
Message-ID: <d00faeaf21dd280500d2.1333533070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 10:51:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: fixup error handling in
	libxl_send_trigger
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1333532948 -3600
# Node ID d00faeaf21dd280500d2deace00683d884a2dc10
# Parent  c99e16a24eabeb6d3ed9f961d35e84acf7cd8cdd
libxl: fixup error handling in libxl_send_trigger

xc_domain_send_trigger returns -1 and sets errno on failure so use
LIBXL__LOG_ERRNO not LIBXL__LOG_ERRNOVAL(rc).

Change the default case of the switch to set rc=-1,errno=EINVAL too.

Also we weren't actually returning the error code we'd decided on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c99e16a24eab -r d00faeaf21dd tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Apr 04 10:37:18 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Apr 04 10:49:08 2012 +0100
@@ -3309,18 +3309,19 @@ int libxl_send_trigger(libxl_ctx *ctx, u
         rc = 0;
         break;
     default:
-        rc = EINVAL;
+        rc = -1;
+        errno = EINVAL;
         break;
     }
 
     if (rc != 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-                            "Send trigger '%s' failed",
-                            libxl_trigger_to_string(trigger));
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "Send trigger '%s' failed",
+                         libxl_trigger_to_string(trigger));
         rc = ERROR_FAIL;
     }
 
-    return 0;
+    return rc;
 }
 
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:06:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFN6V-0005TK-RL; Wed, 04 Apr 2012 10:06:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFN6U-0005TF-BJ
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:06:14 +0000
Received: from [85.158.139.83:18396] by server-11.bemta-5.messagelabs.com id
	0E/87-12959-51D1C7F4; Wed, 04 Apr 2012 10:06:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333533972!22436337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9292 invoked from network); 4 Apr 2012 10:06:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:06:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11764699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:06:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 11:06:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFN6R-0005bU-Uk; Wed, 04 Apr 2012 10:06:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFN6R-0007hY-QM;
	Wed, 04 Apr 2012 11:06:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.7441.657436.402765@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 11:06:09 +0100
To: Matt Wilson <msw@amazon.com>
In-Reply-To: <20120403184851.GA8916@US-SEA-R8XVZTX>
References: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
	<20120325170728.GP4316@type.famille.thibault.fr>
	<20120403184851.GA8916@US-SEA-R8XVZTX>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 and
	btrfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("Re: [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 an=
d btrfs"):
> On Sun, Mar 25, 2012 at 10:07:28AM -0700, Samuel Thibault wrote:
> > Matt Wilson, le Tue 20 Mar 2012 18:47:46 +0000, a =E9crit :
> > > Changes from v1:
> > >  - Makefile has been changed to check the exit code from patch
> > =

> > Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> > =

> > >  - The btrfs patch has been rebased to apply cleanly
> > >  - The patch file names have been adjusted to match existing patches
> >
> > Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> I haven't seen these changes land in staging yet. Is anything blocked
> on me?

Looking back at the thread, I had a minor comment about the Makefile,
which you said you were going to repost to change, but TBH it's not
that important.  I will apply the v2 series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:06:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFN6V-0005TK-RL; Wed, 04 Apr 2012 10:06:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFN6U-0005TF-BJ
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:06:14 +0000
Received: from [85.158.139.83:18396] by server-11.bemta-5.messagelabs.com id
	0E/87-12959-51D1C7F4; Wed, 04 Apr 2012 10:06:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333533972!22436337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9292 invoked from network); 4 Apr 2012 10:06:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:06:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11764699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:06:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 11:06:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFN6R-0005bU-Uk; Wed, 04 Apr 2012 10:06:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFN6R-0007hY-QM;
	Wed, 04 Apr 2012 11:06:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.7441.657436.402765@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 11:06:09 +0100
To: Matt Wilson <msw@amazon.com>
In-Reply-To: <20120403184851.GA8916@US-SEA-R8XVZTX>
References: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
	<20120325170728.GP4316@type.famille.thibault.fr>
	<20120403184851.GA8916@US-SEA-R8XVZTX>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 and
	btrfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("Re: [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 an=
d btrfs"):
> On Sun, Mar 25, 2012 at 10:07:28AM -0700, Samuel Thibault wrote:
> > Matt Wilson, le Tue 20 Mar 2012 18:47:46 +0000, a =E9crit :
> > > Changes from v1:
> > >  - Makefile has been changed to check the exit code from patch
> > =

> > Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> > =

> > >  - The btrfs patch has been rebased to apply cleanly
> > >  - The patch file names have been adjusted to match existing patches
> >
> > Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> I haven't seen these changes land in staging yet. Is anything blocked
> on me?

Looking back at the thread, I had a minor comment about the Makefile,
which you said you were going to repost to change, but TBH it's not
that important.  I will apply the v2 series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNKG-0005ij-Bg; Wed, 04 Apr 2012 10:20:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFNKF-0005ie-BU
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:20:27 +0000
Received: from [85.158.139.83:4568] by server-7.bemta-5.messagelabs.com id
	DE/D5-16195-A602C7F4; Wed, 04 Apr 2012 10:20:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333534825!22434579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17657 invoked from network); 4 Apr 2012 10:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11765007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:20:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 11:20:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFNJx-0005gj-Ll; Wed, 04 Apr 2012 10:20:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFNJx-0004iI-Ah;
	Wed, 04 Apr 2012 11:20:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.8281.248391.906730@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 11:20:09 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
References: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4
	and	btrfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("[Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 and btrfs"):
> The following patches add support for ext4 and btrfs to
> PV-GRUB. These patches are taken nearly verbatim from those provided
> by Fedora and Gentoo.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNKG-0005ij-Bg; Wed, 04 Apr 2012 10:20:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFNKF-0005ie-BU
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:20:27 +0000
Received: from [85.158.139.83:4568] by server-7.bemta-5.messagelabs.com id
	DE/D5-16195-A602C7F4; Wed, 04 Apr 2012 10:20:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333534825!22434579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17657 invoked from network); 4 Apr 2012 10:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11765007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:20:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 11:20:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFNJx-0005gj-Ll; Wed, 04 Apr 2012 10:20:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFNJx-0004iI-Ah;
	Wed, 04 Apr 2012 11:20:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.8281.248391.906730@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 11:20:09 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
References: <patchbomb.1332269266@kaos-source-31002.sea31.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4
	and	btrfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("[Xen-devel] [PATCH 0 of 3 v2] PV-GRUB: add support for ext4 and btrfs"):
> The following patches add support for ext4 and btrfs to
> PV-GRUB. These patches are taken nearly verbatim from those provided
> by Fedora and Gentoo.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:22:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNM9-0005oS-Vt; Wed, 04 Apr 2012 10:22:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFNM8-0005oK-6i
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:22:24 +0000
Received: from [85.158.139.83:32954] by server-12.bemta-5.messagelabs.com id
	92/27-05587-FD02C7F4; Wed, 04 Apr 2012 10:22:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333534941!18164918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10087 invoked from network); 4 Apr 2012 10:22:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:22:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11765107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:22:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 11:22:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFNM5-0005hQ-4x; Wed, 04 Apr 2012 10:22:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFNM5-0004id-3e;
	Wed, 04 Apr 2012 11:22:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.8413.77858.455557@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 11:22:21 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
	<CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"=
):
> On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com>=
 wrot> > For your review and comments please.
...
> > libxl: support for "rtc_timeoffset" and "localtime"

Thanks, looks good to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Unfortunately...
> > + =A0 =A0b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
> > "rtc_timeoffset", &l) ? l : 0;

Your email program wrapped it.

> Ops... forgot about coding style... need to be within 80 column... I
> will roll out another patch to fix this after your review.  Sorry :(

I think if you fix the coding style you will avoid the bug in your
email program.  Alternatively, include the patch as an attachment too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:22:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNM9-0005oS-Vt; Wed, 04 Apr 2012 10:22:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFNM8-0005oK-6i
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:22:24 +0000
Received: from [85.158.139.83:32954] by server-12.bemta-5.messagelabs.com id
	92/27-05587-FD02C7F4; Wed, 04 Apr 2012 10:22:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333534941!18164918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10087 invoked from network); 4 Apr 2012 10:22:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:22:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11765107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:22:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 11:22:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFNM5-0005hQ-4x; Wed, 04 Apr 2012 10:22:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFNM5-0004id-3e;
	Wed, 04 Apr 2012 11:22:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.8413.77858.455557@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 11:22:21 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
	<CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"=
):
> On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com>=
 wrot> > For your review and comments please.
...
> > libxl: support for "rtc_timeoffset" and "localtime"

Thanks, looks good to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Unfortunately...
> > + =A0 =A0b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
> > "rtc_timeoffset", &l) ? l : 0;

Your email program wrapped it.

> Ops... forgot about coding style... need to be within 80 column... I
> will roll out another patch to fix this after your review.  Sorry :(

I think if you fix the coding style you will avoid the bug in your
email program.  Alternatively, include the patch as an attachment too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:36:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNZj-00062h-At; Wed, 04 Apr 2012 10:36:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFNZh-00062c-64
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:36:25 +0000
Received: from [85.158.138.51:22218] by server-2.bemta-3.messagelabs.com id
	B2/53-15460-8242C7F4; Wed, 04 Apr 2012 10:36:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333535781!20790684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7198 invoked from network); 4 Apr 2012 10:36:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="23857679"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 06:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 06:36:20 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFNZb-0003pY-Kk;
	Wed, 04 Apr 2012 11:36:19 +0100
MIME-Version: 1.0
X-Mercurial-Node: dc3241cf1ed1b8e5709cc71c9ec8a93b2374cbd5
Message-ID: <dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1333535779@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 11:36:21 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1333535720 -3600
# Node ID dc3241cf1ed1b8e5709cc71c9ec8a93b2374cbd5
# Parent  ac6f863df8f8c86dcc58df15f94333e6088e0bf4
RFC: libxl: move definition of libxl_domain_config into the IDL

This requires adding a new Array type to the IDL.

DO NOT APPLY. This is 4.3 material.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/gentest.py	Wed Apr 04 11:35:20 2012 +0100
@@ -28,6 +28,18 @@ def gen_rand_init(ty, v, indent = "    "
     s = ""
     if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "%s = rand()%%8;\n" % (parent + ty.lenvar.name)
+        s += "%s = calloc(%s, sizeof(*%s));\n" % \
+            (v, parent + ty.lenvar.name, v)
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += gen_rand_init(ty.elem_type, v+"[i]",
+                           indent + "        ", parent)
+        s += "}\n"
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/gentypes.py	Wed Apr 04 11:35:20 2012 +0100
@@ -11,8 +11,12 @@ def libxl_C_instance_of(ty, instancename
             return libxl_C_type_define(ty)
         else:
             return libxl_C_type_define(ty) + " " + instancename
-    else:
-        return ty.typename + " " + instancename
+
+    s = ""
+    if isinstance(ty, idl.Array):
+        s += libxl_C_instance_of(ty.lenvar.type, ty.lenvar.name) + ";\n"
+
+    return s + ty.typename + " " + instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
@@ -66,6 +70,17 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_dispose(ty.elem_type, v+"[i]",
+                                  indent + "        ", parent)
+        if ty.dispose_fn is not None:
+            s += "    %s(%s);\n" % (ty.dispose_fn, ty.pass_arg(v, parent is None))
+        s += "}\n"
     elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -164,7 +179,24 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, idl.Enumeration):
+
+    if isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    s = yajl_gen_array_open(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "    for (i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_gen_json(ty.elem_type, v+"[i]",
+                                   indent + "        ", parent)
+        s += "    }\n"
+        s += "    s = yajl_gen_array_close(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/idl.py	Wed Apr 04 11:35:20 2012 +0100
@@ -251,6 +251,17 @@ string = Builtin("char *", namespace = N
                  json_fn = "libxl__string_gen_json",
                  autogenerate_json = False)
 
+class Array(Type):
+    """An array of the same type"""
+    def __init__(self, elem_type, lenvar_name, **kwargs):
+        kwargs.setdefault('dispose_fn', 'free')
+        Type.__init__(self, typename=elem_type.rawname + " *", **kwargs)
+
+        lv_kwargs = dict([(x.lstrip('lenvar_'),y) for (x,y) in kwargs.items() if x.startswith('lenvar_')])
+        
+        self.lenvar = Field(integer, lenvar_name, **lv_kwargs)
+        self.elem_type = elem_type
+
 class OrderedDict(dict):
     """A dictionary which remembers insertion order.
 
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/idl.txt	Wed Apr 04 11:35:20 2012 +0100
@@ -145,12 +145,24 @@ idl.KeyedUnion
 
  A subclass of idl.Aggregate which represents the C union type
  where the currently valid member of the union can be determined based
- upon another member in the containing type.
+ upon another member in the containing type. An idl.KeyedUnion must
+ always be a member of a containing idl.Aggregate type.
 
- The KeyedUnion.keyvar contains an idl.type the member of the
+ The KeyedUnion.keyvar contains an idl.Type the member of the
  containing type which determines the valid member of the union. The
  must be an instance of the Enumeration type.
 
+idl.Array
+
+  A class representing an array or similar elements. An idl.Array must
+  always be an idl.Field of a containing idl.Aggregate.
+
+  idl.Array.elem_type contains an idl.Type which is the type of all
+  elements of the array.
+
+  idl.Array.len_var contains an idl.Field which is added to the parent
+  idl.Aggregate and will contain the length of the array.
+
 Standard Types
 --------------
 
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl.h	Wed Apr 04 11:35:20 2012 +0100
@@ -432,25 +432,6 @@ typedef struct {
 
 #define LIBXL_VERSION 0
 
-typedef struct {
-    libxl_domain_create_info c_info;
-    libxl_domain_build_info b_info;
-
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
-
-    libxl_device_disk *disks;
-    libxl_device_nic *vifs;
-    libxl_device_pci *pcidevs;
-    libxl_device_vfb *vfbs;
-    libxl_device_vkb *vkbs;
-
-    libxl_action_on_shutdown on_poweroff;
-    libxl_action_on_shutdown on_reboot;
-    libxl_action_on_shutdown on_watchdog;
-    libxl_action_on_shutdown on_crash;
-} libxl_domain_config;
-char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p);
-
 /* context functions */
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
@@ -462,8 +443,6 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
-void libxl_domain_config_init(libxl_domain_config *d_config);
-void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 04 11:35:20 2012 +0100
@@ -22,41 +22,6 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 
-void libxl_domain_config_init(libxl_domain_config *d_config)
-{
-    memset(d_config, 0, sizeof(*d_config));
-    libxl_domain_create_info_init(&d_config->c_info);
-    libxl_domain_build_info_init(&d_config->b_info);
-}
-
-void libxl_domain_config_dispose(libxl_domain_config *d_config)
-{
-    int i;
-
-    for (i=0; i<d_config->num_disks; i++)
-        libxl_device_disk_dispose(&d_config->disks[i]);
-    free(d_config->disks);
-
-    for (i=0; i<d_config->num_vifs; i++)
-        libxl_device_nic_dispose(&d_config->vifs[i]);
-    free(d_config->vifs);
-
-    for (i=0; i<d_config->num_pcidevs; i++)
-        libxl_device_pci_dispose(&d_config->pcidevs[i]);
-    free(d_config->pcidevs);
-
-    for (i=0; i<d_config->num_vfbs; i++)
-        libxl_device_vfb_dispose(&d_config->vfbs[i]);
-    free(d_config->vfbs);
-
-    for (i=0; i<d_config->num_vkbs; i++)
-        libxl_device_vkb_dispose(&d_config->vkbs[i]);
-    free(d_config->vkbs);
-
-    libxl_domain_create_info_dispose(&d_config->c_info);
-    libxl_domain_build_info_dispose(&d_config->b_info);
-}
-
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl_json.c	Wed Apr 04 11:35:20 2012 +0100
@@ -849,158 +849,6 @@ out:
     return ret;
 }
 
-yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
-                                             libxl_domain_config *p)
-{
-    yajl_gen_status s;
-    int i;
-
-    s = yajl_gen_map_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"c_info",
-                        sizeof("c_info")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_domain_create_info_gen_json(hand, &p->c_info);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"b_info",
-                        sizeof("b_info")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_domain_build_info_gen_json(hand, &p->b_info);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"disks",
-                        sizeof("disks")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_disks; i++) {
-        s = libxl_device_disk_gen_json(hand, &p->disks[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"vifs",
-                        sizeof("vifs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_vifs; i++) {
-        s = libxl_device_nic_gen_json(hand, &p->vifs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"pcidevs",
-                        sizeof("pcidevs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_pcidevs; i++) {
-        s = libxl_device_pci_gen_json(hand, &p->pcidevs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"vfbs",
-                        sizeof("vfbs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_vfbs; i++) {
-        s = libxl_device_vfb_gen_json(hand, &p->vfbs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"vkbs",
-                        sizeof("vkbs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_vkbs; i++) {
-        s = libxl_device_vkb_gen_json(hand, &p->vkbs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_poweroff",
-                        sizeof("on_poweroff")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_poweroff);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_reboot",
-                        sizeof("on_reboot")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_reboot);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_watchdog",
-                        sizeof("on_watchdog")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_watchdog);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_crash",
-                        sizeof("on_crash")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_crash);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_map_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    out:
-    return s;
-}
-
-char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p)
-{
-    return libxl__object_to_json(ctx, "libxl_domain_config",
-                        (libxl__gen_json_callback)&libxl_domain_config_gen_json,
-                        (void *)p);
-}
-
 /*
  * Local variables:
  * mode: C
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Apr 04 11:35:20 2012 +0100
@@ -356,6 +356,22 @@ libxl_device_pci = Struct("device_pci", 
     ("power_mgmt", bool),
     ])
 
+libxl_domain_config = Struct("domain_config", [
+    ("c_info", libxl_domain_create_info),
+    ("b_info", libxl_domain_build_info),
+
+    ("disks", Array(libxl_device_disk, "num_disks")),
+    ("vifs", Array(libxl_device_nic, "num_vifs")),
+    ("pcidevs", Array(libxl_device_pci, "num_pcidevs")),
+    ("vfbs", Array(libxl_device_vfb, "num_vfbs")),
+    ("vkbs", Array(libxl_device_vkb, "num_vkbs")),
+
+    ("on_poweroff", libxl_action_on_shutdown),
+    ("on_reboot", libxl_action_on_shutdown),
+    ("on_watchdog", libxl_action_on_shutdown),
+    ("on_crash", libxl_action_on_shutdown),
+    ])
+
 libxl_diskinfo = Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/ocaml/libs/xl/genwrap.py	Wed Apr 04 11:35:20 2012 +0100
@@ -54,7 +54,8 @@ def ocaml_type_of(ty):
             return "int%d" % ty.width
         else:
             return "int"
-
+    elif isinstance(ty,idl.Array):
+        return "%s list" % ocaml_type_of(ty.elem_type)
     elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
@@ -268,6 +269,7 @@ if __name__ == '__main__':
         "cpupoolinfo",
         "domain_create_info",
         "domain_build_info",
+        "domain_config",
         "vcpuinfo",
         "event",
         ]
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/python/genwrap.py	Wed Apr 04 11:35:20 2012 +0100
@@ -4,7 +4,7 @@ import sys,os
 
 import idl
 
-(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_ARRAY, TYPE_AGGREGATE) = range(7)
 
 def py_type(ty):
     if ty == idl.bool:
@@ -18,6 +18,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, idl.Array):
+        return TYPE_ARRAY
     if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
     if ty == idl.string:
@@ -74,7 +76,7 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
         l.append('    return NULL;')
     else:
@@ -105,7 +107,7 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
         l.append('    return -1;')
     else:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:36:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNZj-00062h-At; Wed, 04 Apr 2012 10:36:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFNZh-00062c-64
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:36:25 +0000
Received: from [85.158.138.51:22218] by server-2.bemta-3.messagelabs.com id
	B2/53-15460-8242C7F4; Wed, 04 Apr 2012 10:36:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333535781!20790684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7198 invoked from network); 4 Apr 2012 10:36:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="23857679"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 06:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 06:36:20 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFNZb-0003pY-Kk;
	Wed, 04 Apr 2012 11:36:19 +0100
MIME-Version: 1.0
X-Mercurial-Node: dc3241cf1ed1b8e5709cc71c9ec8a93b2374cbd5
Message-ID: <dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1333535779@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 11:36:21 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1333535720 -3600
# Node ID dc3241cf1ed1b8e5709cc71c9ec8a93b2374cbd5
# Parent  ac6f863df8f8c86dcc58df15f94333e6088e0bf4
RFC: libxl: move definition of libxl_domain_config into the IDL

This requires adding a new Array type to the IDL.

DO NOT APPLY. This is 4.3 material.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/gentest.py	Wed Apr 04 11:35:20 2012 +0100
@@ -28,6 +28,18 @@ def gen_rand_init(ty, v, indent = "    "
     s = ""
     if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "%s = rand()%%8;\n" % (parent + ty.lenvar.name)
+        s += "%s = calloc(%s, sizeof(*%s));\n" % \
+            (v, parent + ty.lenvar.name, v)
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += gen_rand_init(ty.elem_type, v+"[i]",
+                           indent + "        ", parent)
+        s += "}\n"
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/gentypes.py	Wed Apr 04 11:35:20 2012 +0100
@@ -11,8 +11,12 @@ def libxl_C_instance_of(ty, instancename
             return libxl_C_type_define(ty)
         else:
             return libxl_C_type_define(ty) + " " + instancename
-    else:
-        return ty.typename + " " + instancename
+
+    s = ""
+    if isinstance(ty, idl.Array):
+        s += libxl_C_instance_of(ty.lenvar.type, ty.lenvar.name) + ";\n"
+
+    return s + ty.typename + " " + instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
@@ -66,6 +70,17 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_dispose(ty.elem_type, v+"[i]",
+                                  indent + "        ", parent)
+        if ty.dispose_fn is not None:
+            s += "    %s(%s);\n" % (ty.dispose_fn, ty.pass_arg(v, parent is None))
+        s += "}\n"
     elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -164,7 +179,24 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, idl.Enumeration):
+
+    if isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    s = yajl_gen_array_open(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "    for (i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_gen_json(ty.elem_type, v+"[i]",
+                                   indent + "        ", parent)
+        s += "    }\n"
+        s += "    s = yajl_gen_array_close(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/idl.py	Wed Apr 04 11:35:20 2012 +0100
@@ -251,6 +251,17 @@ string = Builtin("char *", namespace = N
                  json_fn = "libxl__string_gen_json",
                  autogenerate_json = False)
 
+class Array(Type):
+    """An array of the same type"""
+    def __init__(self, elem_type, lenvar_name, **kwargs):
+        kwargs.setdefault('dispose_fn', 'free')
+        Type.__init__(self, typename=elem_type.rawname + " *", **kwargs)
+
+        lv_kwargs = dict([(x.lstrip('lenvar_'),y) for (x,y) in kwargs.items() if x.startswith('lenvar_')])
+        
+        self.lenvar = Field(integer, lenvar_name, **lv_kwargs)
+        self.elem_type = elem_type
+
 class OrderedDict(dict):
     """A dictionary which remembers insertion order.
 
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/idl.txt	Wed Apr 04 11:35:20 2012 +0100
@@ -145,12 +145,24 @@ idl.KeyedUnion
 
  A subclass of idl.Aggregate which represents the C union type
  where the currently valid member of the union can be determined based
- upon another member in the containing type.
+ upon another member in the containing type. An idl.KeyedUnion must
+ always be a member of a containing idl.Aggregate type.
 
- The KeyedUnion.keyvar contains an idl.type the member of the
+ The KeyedUnion.keyvar contains an idl.Type the member of the
  containing type which determines the valid member of the union. The
  must be an instance of the Enumeration type.
 
+idl.Array
+
+  A class representing an array or similar elements. An idl.Array must
+  always be an idl.Field of a containing idl.Aggregate.
+
+  idl.Array.elem_type contains an idl.Type which is the type of all
+  elements of the array.
+
+  idl.Array.len_var contains an idl.Field which is added to the parent
+  idl.Aggregate and will contain the length of the array.
+
 Standard Types
 --------------
 
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl.h	Wed Apr 04 11:35:20 2012 +0100
@@ -432,25 +432,6 @@ typedef struct {
 
 #define LIBXL_VERSION 0
 
-typedef struct {
-    libxl_domain_create_info c_info;
-    libxl_domain_build_info b_info;
-
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
-
-    libxl_device_disk *disks;
-    libxl_device_nic *vifs;
-    libxl_device_pci *pcidevs;
-    libxl_device_vfb *vfbs;
-    libxl_device_vkb *vkbs;
-
-    libxl_action_on_shutdown on_poweroff;
-    libxl_action_on_shutdown on_reboot;
-    libxl_action_on_shutdown on_watchdog;
-    libxl_action_on_shutdown on_crash;
-} libxl_domain_config;
-char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p);
-
 /* context functions */
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
@@ -462,8 +443,6 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
-void libxl_domain_config_init(libxl_domain_config *d_config);
-void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 04 11:35:20 2012 +0100
@@ -22,41 +22,6 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 
-void libxl_domain_config_init(libxl_domain_config *d_config)
-{
-    memset(d_config, 0, sizeof(*d_config));
-    libxl_domain_create_info_init(&d_config->c_info);
-    libxl_domain_build_info_init(&d_config->b_info);
-}
-
-void libxl_domain_config_dispose(libxl_domain_config *d_config)
-{
-    int i;
-
-    for (i=0; i<d_config->num_disks; i++)
-        libxl_device_disk_dispose(&d_config->disks[i]);
-    free(d_config->disks);
-
-    for (i=0; i<d_config->num_vifs; i++)
-        libxl_device_nic_dispose(&d_config->vifs[i]);
-    free(d_config->vifs);
-
-    for (i=0; i<d_config->num_pcidevs; i++)
-        libxl_device_pci_dispose(&d_config->pcidevs[i]);
-    free(d_config->pcidevs);
-
-    for (i=0; i<d_config->num_vfbs; i++)
-        libxl_device_vfb_dispose(&d_config->vfbs[i]);
-    free(d_config->vfbs);
-
-    for (i=0; i<d_config->num_vkbs; i++)
-        libxl_device_vkb_dispose(&d_config->vkbs[i]);
-    free(d_config->vkbs);
-
-    libxl_domain_create_info_dispose(&d_config->c_info);
-    libxl_domain_build_info_dispose(&d_config->b_info);
-}
-
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl_json.c	Wed Apr 04 11:35:20 2012 +0100
@@ -849,158 +849,6 @@ out:
     return ret;
 }
 
-yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
-                                             libxl_domain_config *p)
-{
-    yajl_gen_status s;
-    int i;
-
-    s = yajl_gen_map_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"c_info",
-                        sizeof("c_info")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_domain_create_info_gen_json(hand, &p->c_info);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"b_info",
-                        sizeof("b_info")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_domain_build_info_gen_json(hand, &p->b_info);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"disks",
-                        sizeof("disks")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_disks; i++) {
-        s = libxl_device_disk_gen_json(hand, &p->disks[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"vifs",
-                        sizeof("vifs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_vifs; i++) {
-        s = libxl_device_nic_gen_json(hand, &p->vifs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"pcidevs",
-                        sizeof("pcidevs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_pcidevs; i++) {
-        s = libxl_device_pci_gen_json(hand, &p->pcidevs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"vfbs",
-                        sizeof("vfbs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_vfbs; i++) {
-        s = libxl_device_vfb_gen_json(hand, &p->vfbs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"vkbs",
-                        sizeof("vkbs")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    for (i = 0; i < p->num_vkbs; i++) {
-        s = libxl_device_vkb_gen_json(hand, &p->vkbs[i]);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
-    s = yajl_gen_array_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_poweroff",
-                        sizeof("on_poweroff")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_poweroff);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_reboot",
-                        sizeof("on_reboot")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_reboot);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_watchdog",
-                        sizeof("on_watchdog")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_watchdog);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_string(hand, (const unsigned char *)"on_crash",
-                        sizeof("on_crash")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_action_on_shutdown_gen_json(hand, &p->on_crash);
-    if (s != yajl_gen_status_ok)
-        goto out;
-
-    s = yajl_gen_map_close(hand);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    out:
-    return s;
-}
-
-char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p)
-{
-    return libxl__object_to_json(ctx, "libxl_domain_config",
-                        (libxl__gen_json_callback)&libxl_domain_config_gen_json,
-                        (void *)p);
-}
-
 /*
  * Local variables:
  * mode: C
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Apr 04 11:35:20 2012 +0100
@@ -356,6 +356,22 @@ libxl_device_pci = Struct("device_pci", 
     ("power_mgmt", bool),
     ])
 
+libxl_domain_config = Struct("domain_config", [
+    ("c_info", libxl_domain_create_info),
+    ("b_info", libxl_domain_build_info),
+
+    ("disks", Array(libxl_device_disk, "num_disks")),
+    ("vifs", Array(libxl_device_nic, "num_vifs")),
+    ("pcidevs", Array(libxl_device_pci, "num_pcidevs")),
+    ("vfbs", Array(libxl_device_vfb, "num_vfbs")),
+    ("vkbs", Array(libxl_device_vkb, "num_vkbs")),
+
+    ("on_poweroff", libxl_action_on_shutdown),
+    ("on_reboot", libxl_action_on_shutdown),
+    ("on_watchdog", libxl_action_on_shutdown),
+    ("on_crash", libxl_action_on_shutdown),
+    ])
+
 libxl_diskinfo = Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/ocaml/libs/xl/genwrap.py	Wed Apr 04 11:35:20 2012 +0100
@@ -54,7 +54,8 @@ def ocaml_type_of(ty):
             return "int%d" % ty.width
         else:
             return "int"
-
+    elif isinstance(ty,idl.Array):
+        return "%s list" % ocaml_type_of(ty.elem_type)
     elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
@@ -268,6 +269,7 @@ if __name__ == '__main__':
         "cpupoolinfo",
         "domain_create_info",
         "domain_build_info",
+        "domain_config",
         "vcpuinfo",
         "event",
         ]
diff -r ac6f863df8f8 -r dc3241cf1ed1 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Wed Apr 04 10:51:11 2012 +0100
+++ b/tools/python/genwrap.py	Wed Apr 04 11:35:20 2012 +0100
@@ -4,7 +4,7 @@ import sys,os
 
 import idl
 
-(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_ARRAY, TYPE_AGGREGATE) = range(7)
 
 def py_type(ty):
     if ty == idl.bool:
@@ -18,6 +18,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, idl.Array):
+        return TYPE_ARRAY
     if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
     if ty == idl.string:
@@ -74,7 +76,7 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
         l.append('    return NULL;')
     else:
@@ -105,7 +107,7 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
         l.append('    return -1;')
     else:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:37:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:37:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNZy-00063l-TC; Wed, 04 Apr 2012 10:36:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFNZy-00063f-6x
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:36:42 +0000
Received: from [85.158.139.83:48081] by server-9.bemta-5.messagelabs.com id
	AA/01-09826-9342C7F4; Wed, 04 Apr 2012 10:36:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333535798!21767129!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE1MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21914 invoked from network); 4 Apr 2012 10:36:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="188957140"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 06:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 06:36:20 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFNZb-0003pY-JO;
	Wed, 04 Apr 2012 11:36:19 +0100
MIME-Version: 1.0
X-Mercurial-Node: ac6f863df8f8c86dcc58df15f94333e6088e0bf4
Message-ID: <ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1333535779@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 11:36:20 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1333533071 -3600
# Node ID ac6f863df8f8c86dcc58df15f94333e6088e0bf4
# Parent  d00faeaf21dd280500d2deace00683d884a2dc10
libxl: provide libxl_domain_config_init.

Currently this struct is too complicated for the IDL to represent (arrays) so
for now implement by hand.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d00faeaf21dd -r ac6f863df8f8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Apr 04 10:49:08 2012 +0100
+++ b/tools/libxl/libxl.h	Wed Apr 04 10:51:11 2012 +0100
@@ -462,6 +462,7 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff -r d00faeaf21dd -r ac6f863df8f8 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 04 10:49:08 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 04 10:51:11 2012 +0100
@@ -22,6 +22,13 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 
+void libxl_domain_config_init(libxl_domain_config *d_config)
+{
+    memset(d_config, 0, sizeof(*d_config));
+    libxl_domain_create_info_init(&d_config->c_info);
+    libxl_domain_build_info_init(&d_config->b_info);
+}
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
     int i;
diff -r d00faeaf21dd -r ac6f863df8f8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Apr 04 10:49:08 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Apr 04 10:51:11 2012 +0100
@@ -535,8 +535,6 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_create_info_init(c_info);
-
     if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
@@ -582,7 +580,6 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_build_info_init(b_info);
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
@@ -1505,7 +1502,7 @@ static int create_domain(struct domain_c
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
-    memset(&d_config, 0x00, sizeof(d_config));
+    libxl_domain_config_init(&d_config);
 
     if (restore_file) {
         uint8_t *optdata_begin = 0;
@@ -1822,7 +1819,7 @@ start:
 
                 /* Reparse the configuration in case it has changed */
                 libxl_domain_config_dispose(&d_config);
-                memset(&d_config, 0, sizeof(d_config));
+                libxl_domain_config_init(&d_config);
                 parse_config_data(config_file, config_data, config_len,
                                   &d_config);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:37:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:37:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNZy-00063l-TC; Wed, 04 Apr 2012 10:36:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFNZy-00063f-6x
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:36:42 +0000
Received: from [85.158.139.83:48081] by server-9.bemta-5.messagelabs.com id
	AA/01-09826-9342C7F4; Wed, 04 Apr 2012 10:36:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333535798!21767129!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE1MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21914 invoked from network); 4 Apr 2012 10:36:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="188957140"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 06:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 06:36:20 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFNZb-0003pY-JO;
	Wed, 04 Apr 2012 11:36:19 +0100
MIME-Version: 1.0
X-Mercurial-Node: ac6f863df8f8c86dcc58df15f94333e6088e0bf4
Message-ID: <ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1333535779@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 11:36:20 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1333533071 -3600
# Node ID ac6f863df8f8c86dcc58df15f94333e6088e0bf4
# Parent  d00faeaf21dd280500d2deace00683d884a2dc10
libxl: provide libxl_domain_config_init.

Currently this struct is too complicated for the IDL to represent (arrays) so
for now implement by hand.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d00faeaf21dd -r ac6f863df8f8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Apr 04 10:49:08 2012 +0100
+++ b/tools/libxl/libxl.h	Wed Apr 04 10:51:11 2012 +0100
@@ -462,6 +462,7 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff -r d00faeaf21dd -r ac6f863df8f8 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 04 10:49:08 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 04 10:51:11 2012 +0100
@@ -22,6 +22,13 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 
+void libxl_domain_config_init(libxl_domain_config *d_config)
+{
+    memset(d_config, 0, sizeof(*d_config));
+    libxl_domain_create_info_init(&d_config->c_info);
+    libxl_domain_build_info_init(&d_config->b_info);
+}
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
     int i;
diff -r d00faeaf21dd -r ac6f863df8f8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Apr 04 10:49:08 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Apr 04 10:51:11 2012 +0100
@@ -535,8 +535,6 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_create_info_init(c_info);
-
     if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
@@ -582,7 +580,6 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_build_info_init(b_info);
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
@@ -1505,7 +1502,7 @@ static int create_domain(struct domain_c
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
-    memset(&d_config, 0x00, sizeof(d_config));
+    libxl_domain_config_init(&d_config);
 
     if (restore_file) {
         uint8_t *optdata_begin = 0;
@@ -1822,7 +1819,7 @@ start:
 
                 /* Reparse the configuration in case it has changed */
                 libxl_domain_config_dispose(&d_config);
-                memset(&d_config, 0, sizeof(d_config));
+                libxl_domain_config_init(&d_config);
                 parse_config_data(config_file, config_data, config_len,
                                   &d_config);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:37:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNa2-00064L-8t; Wed, 04 Apr 2012 10:36:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFNa1-000644-C3
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:36:45 +0000
Received: from [85.158.139.83:44747] by server-2.bemta-5.messagelabs.com id
	6F/68-17016-C342C7F4; Wed, 04 Apr 2012 10:36:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333535798!21767129!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE1MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22109 invoked from network); 4 Apr 2012 10:36:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:36:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="188957139"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 06:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 06:36:20 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFNZb-0003pY-Ic;
	Wed, 04 Apr 2012 11:36:19 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333535779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 11:36:19 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl: add libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following series implements libxl_domain_config_init as per the
libxl API requirement that each type has an init function.

The first function does this in an open coded manner and is proposed
for Xen 4.2.

The second function is RFC only since it moves the definition of this
type into the IDL and makes the required infrastructure updates to
enable this. I think this is more 4.3 material at this stage.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 10:37:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 10:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFNa2-00064L-8t; Wed, 04 Apr 2012 10:36:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFNa1-000644-C3
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 10:36:45 +0000
Received: from [85.158.139.83:44747] by server-2.bemta-5.messagelabs.com id
	6F/68-17016-C342C7F4; Wed, 04 Apr 2012 10:36:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333535798!21767129!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE1MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22109 invoked from network); 4 Apr 2012 10:36:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 10:36:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330923600"; d="scan'208";a="188957139"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 06:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 06:36:20 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SFNZb-0003pY-Ic;
	Wed, 04 Apr 2012 11:36:19 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333535779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 4 Apr 2012 11:36:19 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl: add libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following series implements libxl_domain_config_init as per the
libxl API requirement that each type has an init function.

The first function does this in an open coded manner and is proposed
for Xen 4.2.

The second function is RFC only since it moves the definition of this
type into the IDL and makes the required infrastructure updates to
enable this. I think this is more 4.3 material at this stage.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 11:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 11:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFOAH-0006et-BU; Wed, 04 Apr 2012 11:14:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1SFOAF-0006eo-A4
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 11:14:11 +0000
Received: from [193.109.254.147:41638] by server-2.bemta-14.messagelabs.com id
	B1/CD-19409-20D2C7F4; Wed, 04 Apr 2012 11:14:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333538049!3199800!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21663 invoked from network); 4 Apr 2012 11:14:09 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 11:14:09 -0000
Received: by lahe6 with SMTP id e6so259797lah.32
	for <xen-devel@lists.xen.org>; Wed, 04 Apr 2012 04:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=AV9oxajDNbmBlqJgWLBfIEAc/thADhWnP77sPq8L7xg=;
	b=nVMMdQ+CXrzJuoFgYnKr9Y/Loa1hxFUWf/moBYjxDb8r6V0d31fi1VMm0/OWh9s749
	U1KV/Z6wrtBfGot0wwtb5L6OrMZj1zMvW11sv4bkdAs4oTqljTLajUgrB3gagLfPBkbQ
	3mhRw5/HqxsBkEUYknaIdDbuXXXahiADLhiOlu/a1ciAKWEFsujODHxCN5p1wNQFGgCe
	Eo1nOZSFyBiBVDgyVpQT8iOwGrD6DaQRdNF3I2eU7LXCWJLYr4Bla77m+myyjcP/Y4t+
	ryGfRBy3+As5IEdc52BxQlUw5y4BGrnbo0TgE88nrcBT+blaroX9hw83i3WK5KP+IcTL
	/mWA==
MIME-Version: 1.0
Received: by 10.152.106.9 with SMTP id gq9mr18234891lab.14.1333538048761; Wed,
	04 Apr 2012 04:14:08 -0700 (PDT)
Received: by 10.152.30.205 with HTTP; Wed, 4 Apr 2012 04:14:08 -0700 (PDT)
In-Reply-To: <20317.55113.339973.333351@mariner.uk.xensource.com>
References: <patchbomb.1329928802@debian.localdomain>
	<04c74f6b97ad74ecd322.1329928804@debian.localdomain>
	<20317.55113.339973.333351@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 12:14:08 +0100
X-Google-Sender-Auth: SmVGyjb9Wo-5Fen_nf8Hi-n2xu0
Message-ID: <CAPLaKK6fGxVavTRzzmZhvJ8Jwp=L-YsKkLEFoY+-YC830j-Q=g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] autoconf: check for as86, ld86,
	bcc and iasl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/3/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl"):
>> autoconf: check for as86, ld86, bcc and iasl
>>
>> Check for this tools, and set the proper paths on config/Tool.mk.
>
> This looks plausible.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Could this be applied before the 4.2 freeze?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 11:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 11:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFOAH-0006et-BU; Wed, 04 Apr 2012 11:14:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1SFOAF-0006eo-A4
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 11:14:11 +0000
Received: from [193.109.254.147:41638] by server-2.bemta-14.messagelabs.com id
	B1/CD-19409-20D2C7F4; Wed, 04 Apr 2012 11:14:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333538049!3199800!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21663 invoked from network); 4 Apr 2012 11:14:09 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 11:14:09 -0000
Received: by lahe6 with SMTP id e6so259797lah.32
	for <xen-devel@lists.xen.org>; Wed, 04 Apr 2012 04:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=AV9oxajDNbmBlqJgWLBfIEAc/thADhWnP77sPq8L7xg=;
	b=nVMMdQ+CXrzJuoFgYnKr9Y/Loa1hxFUWf/moBYjxDb8r6V0d31fi1VMm0/OWh9s749
	U1KV/Z6wrtBfGot0wwtb5L6OrMZj1zMvW11sv4bkdAs4oTqljTLajUgrB3gagLfPBkbQ
	3mhRw5/HqxsBkEUYknaIdDbuXXXahiADLhiOlu/a1ciAKWEFsujODHxCN5p1wNQFGgCe
	Eo1nOZSFyBiBVDgyVpQT8iOwGrD6DaQRdNF3I2eU7LXCWJLYr4Bla77m+myyjcP/Y4t+
	ryGfRBy3+As5IEdc52BxQlUw5y4BGrnbo0TgE88nrcBT+blaroX9hw83i3WK5KP+IcTL
	/mWA==
MIME-Version: 1.0
Received: by 10.152.106.9 with SMTP id gq9mr18234891lab.14.1333538048761; Wed,
	04 Apr 2012 04:14:08 -0700 (PDT)
Received: by 10.152.30.205 with HTTP; Wed, 4 Apr 2012 04:14:08 -0700 (PDT)
In-Reply-To: <20317.55113.339973.333351@mariner.uk.xensource.com>
References: <patchbomb.1329928802@debian.localdomain>
	<04c74f6b97ad74ecd322.1329928804@debian.localdomain>
	<20317.55113.339973.333351@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 12:14:08 +0100
X-Google-Sender-Auth: SmVGyjb9Wo-5Fen_nf8Hi-n2xu0
Message-ID: <CAPLaKK6fGxVavTRzzmZhvJ8Jwp=L-YsKkLEFoY+-YC830j-Q=g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] autoconf: check for as86, ld86,
	bcc and iasl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/3/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl"):
>> autoconf: check for as86, ld86, bcc and iasl
>>
>> Check for this tools, and set the proper paths on config/Tool.mk.
>
> This looks plausible.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Could this be applied before the 4.2 freeze?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 12:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 12:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFPMA-0007Ea-Vn; Wed, 04 Apr 2012 12:30:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFPM8-0007EV-RQ
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 12:30:33 +0000
Received: from [85.158.138.51:65030] by server-4.bemta-3.messagelabs.com id
	20/EF-16467-8EE3C7F4; Wed, 04 Apr 2012 12:30:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333542628!20772434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16132 invoked from network); 4 Apr 2012 12:30:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 12:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11768070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 12:30:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 13:30:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFPLe-0006mH-4A;
	Wed, 04 Apr 2012 12:30:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFPLe-00049n-3Y;
	Wed, 04 Apr 2012 13:30:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12560-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 13:30:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12560: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12560 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12560/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           9 guest-start                 fail pass in 12555

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 5230
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail blocked in 5230

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-amd64-xl          15 guest-stop            fail in 12555 never pass

version targeted for testing:
 xen                  cbe8948799bf
baseline version:
 xen                  9b453f96dd46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 12:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 12:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFPMA-0007Ea-Vn; Wed, 04 Apr 2012 12:30:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFPM8-0007EV-RQ
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 12:30:33 +0000
Received: from [85.158.138.51:65030] by server-4.bemta-3.messagelabs.com id
	20/EF-16467-8EE3C7F4; Wed, 04 Apr 2012 12:30:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333542628!20772434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16132 invoked from network); 4 Apr 2012 12:30:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 12:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,368,1330905600"; d="scan'208";a="11768070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 12:30:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 13:30:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFPLe-0006mH-4A;
	Wed, 04 Apr 2012 12:30:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFPLe-00049n-3Y;
	Wed, 04 Apr 2012 13:30:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12560-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 13:30:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12560: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12560 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12560/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           9 guest-start                 fail pass in 12555

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 5230
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail blocked in 5230

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-amd64-xl          15 guest-stop            fail in 12555 never pass

version targeted for testing:
 xen                  cbe8948799bf
baseline version:
 xen                  9b453f96dd46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 12:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 12:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFPj9-0007lW-Ts; Wed, 04 Apr 2012 12:54:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SFPj7-0007lR-Uh
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 12:54:18 +0000
Received: from [85.158.139.83:49219] by server-3.bemta-5.messagelabs.com id
	A7/91-25237-9744C7F4; Wed, 04 Apr 2012 12:54:17 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333544053!21792967!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29013 invoked from network); 4 Apr 2012 12:54:15 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 12:54:15 -0000
Received: by dajx4 with SMTP id x4so270325daj.28
	for <xen-devel@lists.xen.org>; Wed, 04 Apr 2012 05:54:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=EVZeSAIX68EPas6O93L0avLqLYLP9+SgchItG8sYby0=;
	b=pKYMasDDcejLAGVfV2zcbL7fFDiMtViSdQ6gLqd2SxxlZpTzAVRrdD6cMxO5SAD5kU
	AzBqOToKXuisnNHCAXfuRBUmg4w8zfdvBU47iEE+RVjpUxZpHdKc1AFr5Gw/1nxLHTSF
	Sw9C2v6hhHHaWBVh+O/HlcQvRF8gXXSFFyKD7LWdpsqkSAwgwBh7frGiGG/9OmELzOiS
	sLyfJvzpm4laEG3rRykKhwuGTryRHQLsLxbaBvjbp2N3WXp7zSxTyPKW2ZBuFkRXvmY2
	/9HBDfv9qSNoKm4fDH+rI6swZRdCTqkx9q+3D4TjcNJHeUxr95mZrNXteqjnHo9v6Tp3
	PExw==
MIME-Version: 1.0
Received: by 10.68.226.5 with SMTP id ro5mr36937262pbc.138.1333544052761; Wed,
	04 Apr 2012 05:54:12 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 4 Apr 2012 05:54:12 -0700 (PDT)
In-Reply-To: <20348.8413.77858.455557@mariner.uk.xensource.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
	<CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
	<20348.8413.77858.455557@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 20:54:12 +0800
Message-ID: <CAEwRVpP_Oqu9OTXCFmMKbbj1V5if9BWKd36ikEL3hghG6R7qew@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary=047d7b2e09618ea63a04bcd9eb28
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--047d7b2e09618ea63a04bcd9eb28
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 4, 2012 at 6:22 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wro=
te:
> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testin=
g"):
>> On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com=
> wrot> > For your review and comments please.
> ...
>> > libxl: support for "rtc_timeoffset" and "localtime"
>
> Thanks, looks good to me.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> Unfortunately...
>> > + =A0 =A0b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
>> > "rtc_timeoffset", &l) ? l : 0;
>
> Your email program wrapped it.
>
>> Ops... forgot about coding style... need to be within 80 column... I
>> will roll out another patch to fix this after your review. =A0Sorry :(
>
> I think if you fix the coding style you will avoid the bug in your
> email program. =A0Alternatively, include the patch as an attachment too.

Yes, I know gmail wrapped it as it is longer than 80 in length.
Attached is the fix patch.

>
> Ian.

Thanks Ian for taking time to review ;)

Kindest regards,
Giam Teck Choon

--047d7b2e09618ea63a04bcd9eb28
Content-Type: application/octet-stream; 
	name="backport-unstable-25131-to-xen-4.1-testing.patch"
Content-Disposition: attachment; 
	filename="backport-unstable-25131-to-xen-4.1-testing.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0mdovhk0

bGlieGw6IHN1cHBvcnQgZm9yICJydGNfdGltZW9mZnNldCIgYW5kICJsb2NhbHRpbWUiCgpJbXBs
ZW1lbnQgInJ0Y190aW1lb2Zmc2V0IiBhbmQgImxvY2FsdGltZSIgb3B0aW9ucyBjb21wYXRpYmxl
IGFzIHhtLgoKcnRjX3RpbWVvZmZzZXQgaXMgdGhlIG9mZnNldCBiZXR3ZWVuIGhvc3QgdGltZSBh
bmQgZ3Vlc3QgdGltZS4KbG9jYWx0aW1lIG1lYW5zIHRvIHNwZWNpZnkgd2hldGhlciB0aGUgZW11
bHRlZCBSVEMgYXBwZWFycyBhcyBVVEMgb3IgaXMKb2Zmc2V0IGJ5IHRoZSBob3N0LgoKeGVuLXVu
c3RhYmxlIGNoYW5nZXNldDogMjUxMzE6NmY4MWY0ZDc5ZmRlCgpTaWduZWQtb2ZmLWJ5OiBHaWFt
IFRlY2sgQ2hvb24gPGdpYW10ZWNrY2hvb25AZ21haWwuY29tPgoKLS0tCiB0b29scy9saWJ4bC9s
aWJ4bC5pZGwgICAgfCAgICAyICsrCiB0b29scy9saWJ4bC9saWJ4bF9kb20uYyAgfCAgICAzICsr
KwogdG9vbHMvbGlieGwveGxfY21kaW1wbC5jIHwgICAxNCArKysrKysrKysrKysrKwogMyBmaWxl
cyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh
L3Rvb2xzL2xpYnhsL2xpYnhsLmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsLmlkbAppbmRleCAzNzc0
MTdhLi4zMTkzNTA2IDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bC5pZGwKKysrIGIvdG9v
bHMvbGlieGwvbGlieGwuaWRsCkBAIC05NCw2ICs5NCw4IEBAIGxpYnhsX2RvbWFpbl9idWlsZF9p
bmZvID0gU3RydWN0KCJkb21haW5fYnVpbGRfaW5mbyIsWwogICAgICgidGFyZ2V0X21lbWtiIiwg
ICAgdWludDMyKSwKICAgICAoInZpZGVvX21lbWtiIiwgICAgIHVpbnQzMiksCiAgICAgKCJzaGFk
b3dfbWVta2IiLCAgICB1aW50MzIpLAorICAgICgicnRjX3RpbWVvZmZzZXQiLCAgdWludDMyKSwK
KyAgICAoImxvY2FsdGltZSIsICAgICAgIGJvb2wpLAogICAgICgiZGlzYWJsZV9taWdyYXRlIiwg
Ym9vbCksCiAgICAgKCJrZXJuZWwiLCAgICAgICAgICBsaWJ4bF9maWxlX3JlZmVyZW5jZSksCiAg
ICAgKCJjcHVpZCIsICAgICAgICAgICBsaWJ4bF9jcHVpZF9wb2xpY3lfbGlzdCksCmRpZmYgLS1n
aXQgYS90b29scy9saWJ4bC9saWJ4bF9kb20uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCmlu
ZGV4IGM3MDJjZjcuLjdhYjc4ZGIgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5j
CisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCkBAIC03Niw2ICs3Niw5IEBAIGludCBsaWJ4
bF9fYnVpbGRfcHJlKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwKICAgICBpZiAoIGlu
Zm8tPmRpc2FibGVfbWlncmF0ZSApCiAgICAgICAgIHhjX2RvbWFpbl9kaXNhYmxlX21pZ3JhdGUo
Y3R4LT54Y2gsIGRvbWlkKTsKIAorICAgIGlmIChpbmZvLT5ydGNfdGltZW9mZnNldCkKKyAgICAg
ICAgeGNfZG9tYWluX3NldF90aW1lX29mZnNldChjdHgtPnhjaCwgZG9taWQsIGluZm8tPnJ0Y190
aW1lb2Zmc2V0KTsKKwogICAgIGlmIChpbmZvLT5odm0pIHsKICAgICAgICAgdW5zaWduZWQgbG9u
ZyBzaGFkb3c7CiAgICAgICAgIHNoYWRvdyA9IChpbmZvLT5zaGFkb3dfbWVta2IgKyAxMDIzKSAv
IDEwMjQ7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29scy9saWJ4
bC94bF9jbWRpbXBsLmMKaW5kZXggMmRiY2VkNy4uNmJhY2U0MSAxMDA2NDQKLS0tIGEvdG9vbHMv
bGlieGwveGxfY21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtNzM3
LDYgKzczNywyMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFyICpj
b25maWdmaWxlX2ZpbGVuYW1lX3JlcG9ydCwKICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcoY29u
ZmlnLCAidHNjX21vZGUiLCAmbCkpCiAgICAgICAgIGJfaW5mby0+dHNjX21vZGUgPSBsOwogCisg
ICAgYl9pbmZvLT5ydGNfdGltZW9mZnNldCA9ICF4bHVfY2ZnX2dldF9sb25nKGNvbmZpZywgInJ0
Y190aW1lb2Zmc2V0IiwgJmwpCisgICAgICAgID8gbCA6IDA7CisKKyAgICBiX2luZm8tPmxvY2Fs
dGltZSA9ICF4bHVfY2ZnX2dldF9sb25nKGNvbmZpZywgImxvY2FsdGltZSIsICZsKSA/IGwgOiAw
OworICAgIGlmIChiX2luZm8tPmxvY2FsdGltZSkgeworICAgICAgICB0aW1lX3QgdDsKKyAgICAg
ICAgc3RydWN0IHRtICp0bTsKKworICAgICAgICB0ID0gdGltZShOVUxMKTsKKyAgICAgICAgdG0g
PSBsb2NhbHRpbWUoJnQpOworCisgICAgICAgIGJfaW5mby0+cnRjX3RpbWVvZmZzZXQgKz0gdG0t
PnRtX2dtdG9mZjsKKyAgICB9CisKICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywg
InZpZGVvcmFtIiwgJmwpKQogICAgICAgICBiX2luZm8tPnZpZGVvX21lbWtiID0gbCAqIDEwMjQ7
CiAK
--047d7b2e09618ea63a04bcd9eb28
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b2e09618ea63a04bcd9eb28--


From xen-devel-bounces@lists.xen.org Wed Apr 04 12:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 12:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFPj9-0007lW-Ts; Wed, 04 Apr 2012 12:54:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SFPj7-0007lR-Uh
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 12:54:18 +0000
Received: from [85.158.139.83:49219] by server-3.bemta-5.messagelabs.com id
	A7/91-25237-9744C7F4; Wed, 04 Apr 2012 12:54:17 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333544053!21792967!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29013 invoked from network); 4 Apr 2012 12:54:15 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 12:54:15 -0000
Received: by dajx4 with SMTP id x4so270325daj.28
	for <xen-devel@lists.xen.org>; Wed, 04 Apr 2012 05:54:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=EVZeSAIX68EPas6O93L0avLqLYLP9+SgchItG8sYby0=;
	b=pKYMasDDcejLAGVfV2zcbL7fFDiMtViSdQ6gLqd2SxxlZpTzAVRrdD6cMxO5SAD5kU
	AzBqOToKXuisnNHCAXfuRBUmg4w8zfdvBU47iEE+RVjpUxZpHdKc1AFr5Gw/1nxLHTSF
	Sw9C2v6hhHHaWBVh+O/HlcQvRF8gXXSFFyKD7LWdpsqkSAwgwBh7frGiGG/9OmELzOiS
	sLyfJvzpm4laEG3rRykKhwuGTryRHQLsLxbaBvjbp2N3WXp7zSxTyPKW2ZBuFkRXvmY2
	/9HBDfv9qSNoKm4fDH+rI6swZRdCTqkx9q+3D4TjcNJHeUxr95mZrNXteqjnHo9v6Tp3
	PExw==
MIME-Version: 1.0
Received: by 10.68.226.5 with SMTP id ro5mr36937262pbc.138.1333544052761; Wed,
	04 Apr 2012 05:54:12 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 4 Apr 2012 05:54:12 -0700 (PDT)
In-Reply-To: <20348.8413.77858.455557@mariner.uk.xensource.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
	<CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
	<20348.8413.77858.455557@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 20:54:12 +0800
Message-ID: <CAEwRVpP_Oqu9OTXCFmMKbbj1V5if9BWKd36ikEL3hghG6R7qew@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary=047d7b2e09618ea63a04bcd9eb28
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--047d7b2e09618ea63a04bcd9eb28
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 4, 2012 at 6:22 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wro=
te:
> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testin=
g"):
>> On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com=
> wrot> > For your review and comments please.
> ...
>> > libxl: support for "rtc_timeoffset" and "localtime"
>
> Thanks, looks good to me.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> Unfortunately...
>> > + =A0 =A0b_info->rtc_timeoffset =3D !xlu_cfg_get_long(config,
>> > "rtc_timeoffset", &l) ? l : 0;
>
> Your email program wrapped it.
>
>> Ops... forgot about coding style... need to be within 80 column... I
>> will roll out another patch to fix this after your review. =A0Sorry :(
>
> I think if you fix the coding style you will avoid the bug in your
> email program. =A0Alternatively, include the patch as an attachment too.

Yes, I know gmail wrapped it as it is longer than 80 in length.
Attached is the fix patch.

>
> Ian.

Thanks Ian for taking time to review ;)

Kindest regards,
Giam Teck Choon

--047d7b2e09618ea63a04bcd9eb28
Content-Type: application/octet-stream; 
	name="backport-unstable-25131-to-xen-4.1-testing.patch"
Content-Disposition: attachment; 
	filename="backport-unstable-25131-to-xen-4.1-testing.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0mdovhk0

bGlieGw6IHN1cHBvcnQgZm9yICJydGNfdGltZW9mZnNldCIgYW5kICJsb2NhbHRpbWUiCgpJbXBs
ZW1lbnQgInJ0Y190aW1lb2Zmc2V0IiBhbmQgImxvY2FsdGltZSIgb3B0aW9ucyBjb21wYXRpYmxl
IGFzIHhtLgoKcnRjX3RpbWVvZmZzZXQgaXMgdGhlIG9mZnNldCBiZXR3ZWVuIGhvc3QgdGltZSBh
bmQgZ3Vlc3QgdGltZS4KbG9jYWx0aW1lIG1lYW5zIHRvIHNwZWNpZnkgd2hldGhlciB0aGUgZW11
bHRlZCBSVEMgYXBwZWFycyBhcyBVVEMgb3IgaXMKb2Zmc2V0IGJ5IHRoZSBob3N0LgoKeGVuLXVu
c3RhYmxlIGNoYW5nZXNldDogMjUxMzE6NmY4MWY0ZDc5ZmRlCgpTaWduZWQtb2ZmLWJ5OiBHaWFt
IFRlY2sgQ2hvb24gPGdpYW10ZWNrY2hvb25AZ21haWwuY29tPgoKLS0tCiB0b29scy9saWJ4bC9s
aWJ4bC5pZGwgICAgfCAgICAyICsrCiB0b29scy9saWJ4bC9saWJ4bF9kb20uYyAgfCAgICAzICsr
KwogdG9vbHMvbGlieGwveGxfY21kaW1wbC5jIHwgICAxNCArKysrKysrKysrKysrKwogMyBmaWxl
cyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh
L3Rvb2xzL2xpYnhsL2xpYnhsLmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsLmlkbAppbmRleCAzNzc0
MTdhLi4zMTkzNTA2IDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bC5pZGwKKysrIGIvdG9v
bHMvbGlieGwvbGlieGwuaWRsCkBAIC05NCw2ICs5NCw4IEBAIGxpYnhsX2RvbWFpbl9idWlsZF9p
bmZvID0gU3RydWN0KCJkb21haW5fYnVpbGRfaW5mbyIsWwogICAgICgidGFyZ2V0X21lbWtiIiwg
ICAgdWludDMyKSwKICAgICAoInZpZGVvX21lbWtiIiwgICAgIHVpbnQzMiksCiAgICAgKCJzaGFk
b3dfbWVta2IiLCAgICB1aW50MzIpLAorICAgICgicnRjX3RpbWVvZmZzZXQiLCAgdWludDMyKSwK
KyAgICAoImxvY2FsdGltZSIsICAgICAgIGJvb2wpLAogICAgICgiZGlzYWJsZV9taWdyYXRlIiwg
Ym9vbCksCiAgICAgKCJrZXJuZWwiLCAgICAgICAgICBsaWJ4bF9maWxlX3JlZmVyZW5jZSksCiAg
ICAgKCJjcHVpZCIsICAgICAgICAgICBsaWJ4bF9jcHVpZF9wb2xpY3lfbGlzdCksCmRpZmYgLS1n
aXQgYS90b29scy9saWJ4bC9saWJ4bF9kb20uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCmlu
ZGV4IGM3MDJjZjcuLjdhYjc4ZGIgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5j
CisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCkBAIC03Niw2ICs3Niw5IEBAIGludCBsaWJ4
bF9fYnVpbGRfcHJlKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwKICAgICBpZiAoIGlu
Zm8tPmRpc2FibGVfbWlncmF0ZSApCiAgICAgICAgIHhjX2RvbWFpbl9kaXNhYmxlX21pZ3JhdGUo
Y3R4LT54Y2gsIGRvbWlkKTsKIAorICAgIGlmIChpbmZvLT5ydGNfdGltZW9mZnNldCkKKyAgICAg
ICAgeGNfZG9tYWluX3NldF90aW1lX29mZnNldChjdHgtPnhjaCwgZG9taWQsIGluZm8tPnJ0Y190
aW1lb2Zmc2V0KTsKKwogICAgIGlmIChpbmZvLT5odm0pIHsKICAgICAgICAgdW5zaWduZWQgbG9u
ZyBzaGFkb3c7CiAgICAgICAgIHNoYWRvdyA9IChpbmZvLT5zaGFkb3dfbWVta2IgKyAxMDIzKSAv
IDEwMjQ7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29scy9saWJ4
bC94bF9jbWRpbXBsLmMKaW5kZXggMmRiY2VkNy4uNmJhY2U0MSAxMDA2NDQKLS0tIGEvdG9vbHMv
bGlieGwveGxfY21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtNzM3
LDYgKzczNywyMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFyICpj
b25maWdmaWxlX2ZpbGVuYW1lX3JlcG9ydCwKICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcoY29u
ZmlnLCAidHNjX21vZGUiLCAmbCkpCiAgICAgICAgIGJfaW5mby0+dHNjX21vZGUgPSBsOwogCisg
ICAgYl9pbmZvLT5ydGNfdGltZW9mZnNldCA9ICF4bHVfY2ZnX2dldF9sb25nKGNvbmZpZywgInJ0
Y190aW1lb2Zmc2V0IiwgJmwpCisgICAgICAgID8gbCA6IDA7CisKKyAgICBiX2luZm8tPmxvY2Fs
dGltZSA9ICF4bHVfY2ZnX2dldF9sb25nKGNvbmZpZywgImxvY2FsdGltZSIsICZsKSA/IGwgOiAw
OworICAgIGlmIChiX2luZm8tPmxvY2FsdGltZSkgeworICAgICAgICB0aW1lX3QgdDsKKyAgICAg
ICAgc3RydWN0IHRtICp0bTsKKworICAgICAgICB0ID0gdGltZShOVUxMKTsKKyAgICAgICAgdG0g
PSBsb2NhbHRpbWUoJnQpOworCisgICAgICAgIGJfaW5mby0+cnRjX3RpbWVvZmZzZXQgKz0gdG0t
PnRtX2dtdG9mZjsKKyAgICB9CisKICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywg
InZpZGVvcmFtIiwgJmwpKQogICAgICAgICBiX2luZm8tPnZpZGVvX21lbWtiID0gbCAqIDEwMjQ7
CiAK
--047d7b2e09618ea63a04bcd9eb28
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b2e09618ea63a04bcd9eb28--


From xen-devel-bounces@lists.xen.org Wed Apr 04 13:31:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 13:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFQIl-00081d-1l; Wed, 04 Apr 2012 13:31:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFQIi-00081Y-HT
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 13:31:05 +0000
Received: from [85.158.138.51:30103] by server-3.bemta-3.messagelabs.com id
	F9/B5-10665-71D4C7F4; Wed, 04 Apr 2012 13:31:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333546260!20770312!1
X-Originating-IP: [82.57.200.103]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22399 invoked from network); 4 Apr 2012 13:31:00 -0000
Received: from smtp207.alice.it (HELO smtp207.alice.it) (82.57.200.103)
	by server-4.tower-174.messagelabs.com with SMTP;
	4 Apr 2012 13:31:00 -0000
Received: from [192.168.178.50] (87.2.83.254) by smtp207.alice.it (8.6.023.02)
	id 4F05A6650A8171D7 for xen-devel@lists.xensource.com;
	Wed, 4 Apr 2012 15:30:58 +0200
Message-ID: <4F7C4D0A.1070809@tiscali.it>
Date: Wed, 04 Apr 2012 15:30:50 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] Autoconf: add variable for pass arbitrary
 options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7463004862380400107=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7463004862380400107==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040009030202020409000402"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms040009030202020409000402
Content-Type: multipart/mixed;
 boundary="------------050506080203010500080701"

This is a multi-part message in MIME format.
--------------050506080203010500080701
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Autoconf: add variable for pass arbitrary options to qemu upstream v2

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Patch attached.

--------------050506080203010500080701
Content-Type: text/plain; charset=windows-1252;
 name="autoconf_add_arbitrary_options_qemuu_v2.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="autoconf_add_arbitrary_options_qemuu_v2.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1333545026 -7200
# Node ID 9fb366d55ed2c192f3c0871e678de2a9e5067165
# Parent  527b8ae57ff2fce676c662fb42e31e65007b2036
autoconf: add variable for pass arbitrary options to qemu upstream v2

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 527b8ae57ff2 -r 9fb366d55ed2 config/Tools.mk.in
--- a/config/Tools.mk.in	mer apr 04 14:36:16 2012 +0200
+++ b/config/Tools.mk.in	mer apr 04 15:10:26 2012 +0200
@@ -44,3 +44,4 @@
 CONFIG_GCRYPT       :=3D @libgcrypt@
 CONFIG_EXT2FS       :=3D @libext2fs@
 CURSES_LIBS         :=3D @CURSES_LIBS@
+CONFIG_QEMUU_ADD_PAR:=3D @qemuu_add_par@
diff -r 527b8ae57ff2 -r 9fb366d55ed2 tools/Makefile
--- a/tools/Makefile	mer apr 04 14:36:16 2012 +0200
+++ b/tools/Makefile	mer apr 04 15:10:26 2012 +0200
@@ -157,6 +157,7 @@
 		--datadir=3D$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
 		--python=3D$(PYTHON) \
+		$(CONFIG_QEMUU_ADD_PAR) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install
=20
diff -r 527b8ae57ff2 -r 9fb366d55ed2 tools/configure
--- a/tools/configure	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure	mer apr 04 15:10:26 2012 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
 #
 # Report bugs to <xen-devel@lists.xensource.com>.
 #
@@ -91,6 +91,7 @@
 IFS=3D" ""	$as_nl"
=20
 # Find who we are.  Look in the path if we contain no directory separato=
r.
+as_myself=3D
 case $0 in #((
   *[\\/]* ) as_myself=3D$0 ;;
   *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
@@ -216,11 +217,18 @@
   # We cannot yet assume a decent shell, so we have to provide a
 	# neutralization value for shells without unset; and this also
 	# works around shells that cannot unset nonexistent variables.
+	# Preserve -v and -x to the replacement shell.
 	BASH_ENV=3D/dev/null
 	ENV=3D/dev/null
 	(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
 	export CONFIG_SHELL
-	exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
+	case $- in # ((((
+	  *v*x* | *x*v* ) as_opts=3D-vx ;;
+	  *v* ) as_opts=3D-v ;;
+	  *x* ) as_opts=3D-x ;;
+	  * ) as_opts=3D ;;
+	esac
+	exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
 fi
=20
     if test x$as_have_required =3D xno; then :
@@ -645,6 +653,7 @@
 APPEND_INCLUDES
 PREPEND_LIB
 PREPEND_INCLUDES
+qemuu_add_par
 debug
 lomount
 miniterm
@@ -722,6 +731,9 @@
 enable_miniterm
 enable_lomount
 enable_debug
+enable_qemuu_spice
+enable_qemuu_usbredir
+enable_qemuu_debug
 '
       ac_precious_vars=3D'build_alias
 host_alias
@@ -1153,7 +1165,7 @@
     $as_echo "$as_me: WARNING: you should use --build, --host, --target"=
 >&2
     expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
       $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
-    : ${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_al=
ias=3D$ac_option}
+    : "${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_a=
lias=3D$ac_option}"
     ;;
=20
   esac
@@ -1376,6 +1388,9 @@
   --enable-miniterm       Enable miniterm (default is DISABLED)
   --enable-lomount        Enable lomount (default is DISABLED)
   --disable-debug         Disable debug build of tools (default is ENABL=
ED)
+  --enable-qemuu-spice	Enable Spice build on qemu upstream
+  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream
+  --enable-qemuu-debug	Enable debug build on qemu upstream
=20
 Some influential environment variables:
   CC          C compiler command
@@ -1475,7 +1490,7 @@
 if $ac_init_version; then
   cat <<\_ACEOF
 Xen Hypervisor configure 4.2
-generated by GNU Autoconf 2.67
+generated by GNU Autoconf 2.68
=20
 Copyright (C) 2010 Free Software Foundation, Inc.
 This configure script is free software; the Free Software Foundation
@@ -1521,7 +1536,7 @@
=20
 	ac_retval=3D1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_compile
@@ -1558,7 +1573,7 @@
=20
     ac_retval=3D1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_cpp
@@ -1571,10 +1586,10 @@
 ac_fn_c_check_header_mongrel ()
 {
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
-  if eval "test \"\${$3+set}\"" =3D set; then :
+  if eval \${$3+:} false; then :
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 fi
 eval ac_res=3D\$$3
@@ -1641,7 +1656,7 @@
 esac
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=3D\$ac_header_compiler"
@@ -1650,7 +1665,7 @@
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_header_mongrel
=20
@@ -1691,7 +1706,7 @@
        ac_retval=3D$ac_status
 fi
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_run
@@ -1705,7 +1720,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1723,7 +1738,7 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_header_compile
=20
@@ -1768,11 +1783,65 @@
   # interfere with the next link command; also delete a directory that i=
s
   # left behind by Apple's compiler.  We do this before executing the ac=
tions.
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_link
=20
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# -------------------------------------------
+# Tests whether TYPE exists after having included INCLUDES, setting cach=
e
+# variable VAR accordingly.
+ac_fn_c_check_type ()
+{
+  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval \${$3+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  eval "$3=3Dno"
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof ($2))
+	 return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof (($2)))
+	    return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+
+else
+  eval "$3=3Dyes"
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+eval ac_res=3D\$$3
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+
+} # ac_fn_c_check_type
+
 # ac_fn_c_check_func LINENO FUNC VAR
 # ----------------------------------
 # Tests whether FUNC exists, setting the cache variable VAR accordingly
@@ -1781,7 +1850,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1836,64 +1905,10 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_func
=20
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# -------------------------------------------
-# Tests whether TYPE exists after having included INCLUDES, setting cach=
e
-# variable VAR accordingly.
-ac_fn_c_check_type ()
-{
-  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  eval "$3=3Dno"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof ($2))
-	 return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof (($2)))
-	    return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  eval "$3=3Dyes"
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-eval ac_res=3D\$$3
-	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
-
-} # ac_fn_c_check_type
-
 # ac_fn_c_find_intX_t LINENO BITS VAR
 # -----------------------------------
 # Finds a signed integer type with width BITS, setting cache variable VA=
R
@@ -1903,7 +1918,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
 $as_echo_n "checking for int$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=3Dno"
@@ -1964,7 +1979,7 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_find_intX_t
=20
@@ -1977,7 +1992,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
 $as_echo_n "checking for $2.$3... " >&6; }
-if eval "test \"\${$4+set}\"" =3D set; then :
+if eval \${$4+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -2021,7 +2036,7 @@
 eval ac_res=3D\$$4
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_member
=20
@@ -2034,7 +2049,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
 $as_echo_n "checking for uint$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=3Dno"
@@ -2074,7 +2089,7 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_find_uintX_t
 cat >config.log <<_ACEOF
@@ -2082,7 +2097,7 @@
 running configure, to aid debugging if configure makes a mistake.
=20
 It was created by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
=20
   $ $0 $@
=20
@@ -2340,7 +2355,7 @@
       || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd'=
:" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "failed to load site script $ac_site_file
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
   fi
 done
=20
@@ -2493,7 +2508,7 @@
 set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2533,7 +2548,7 @@
 set dummy gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2586,7 +2601,7 @@
 set dummy ${ac_tool_prefix}cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2626,7 +2641,7 @@
 set dummy cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2685,7 +2700,7 @@
 set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2729,7 +2744,7 @@
 set dummy $ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2784,7 +2799,7 @@
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
=20
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
@@ -2899,7 +2914,7 @@
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error 77 "C compiler cannot create executables
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
@@ -2942,7 +2957,7 @@
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of executables: cannot compile and=
 link
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest conftest$ac_cv_exeext
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
@@ -3001,7 +3016,7 @@
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
     fi
   fi
 fi
@@ -3012,7 +3027,7 @@
 ac_clean_files=3D$ac_clean_files_save
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object f=
iles" >&5
 $as_echo_n "checking for suffix of object files... " >&6; }
-if test "${ac_cv_objext+set}" =3D set; then :
+if ${ac_cv_objext+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3053,7 +3068,7 @@
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of object files: cannot compile
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest.$ac_cv_objext conftest.$ac_ext
 fi
@@ -3063,7 +3078,7 @@
 ac_objext=3D$OBJEXT
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }=

-if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3100,7 +3115,7 @@
 ac_save_CFLAGS=3D$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" =3D set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=3D$ac_c_werror_flag
@@ -3178,7 +3193,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=3Dno
@@ -3286,7 +3301,7 @@
   CPP=3D
 fi
 if test -z "$CPP"; then
-  if test "${ac_cv_prog_CPP+set}" =3D set; then :
+  if ${ac_cv_prog_CPP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
       # Double quotes because CPP needs to be expanded
@@ -3402,7 +3417,7 @@
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
=20
 ac_ext=3Dc
@@ -3414,7 +3429,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles =
long lines and -e" >&5
 $as_echo_n "checking for grep that handles long lines and -e... " >&6; }=

-if test "${ac_cv_path_GREP+set}" =3D set; then :
+if ${ac_cv_path_GREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -z "$GREP"; then
@@ -3477,7 +3492,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
 $as_echo_n "checking for egrep... " >&6; }
-if test "${ac_cv_path_EGREP+set}" =3D set; then :
+if ${ac_cv_path_EGREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
@@ -3544,7 +3559,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header file=
s" >&5
 $as_echo_n "checking for ANSI C header files... " >&6; }
-if test "${ac_cv_header_stdc+set}" =3D set; then :
+if ${ac_cv_header_stdc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3673,7 +3688,7 @@
=20
=20
   ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_=
minix_config_h" "$ac_includes_default"
-if test "x$ac_cv_header_minix_config_h" =3D x""yes; then :
+if test "x$ac_cv_header_minix_config_h" =3D xyes; then :
   MINIX=3Dyes
 else
   MINIX=3D
@@ -3695,7 +3710,7 @@
=20
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe t=
o define __EXTENSIONS__" >&5
 $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&=
6; }
-if test "${ac_cv_safe_to_define___extensions__+set}" =3D set; then :
+if ${ac_cv_safe_to_define___extensions__+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3738,7 +3753,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5=

 $as_echo_n "checking build system type... " >&6; }
-if test "${ac_cv_build+set}" =3D set; then :
+if ${ac_cv_build+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_build_alias=3D$build_alias
@@ -3754,7 +3769,7 @@
 $as_echo "$ac_cv_build" >&6; }
 case $ac_cv_build in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
 esac
 build=3D$ac_cv_build
 ac_save_IFS=3D$IFS; IFS=3D'-'
@@ -3772,7 +3787,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
 $as_echo_n "checking host system type... " >&6; }
-if test "${ac_cv_host+set}" =3D set; then :
+if ${ac_cv_host+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "x$host_alias" =3D x; then
@@ -3787,7 +3802,7 @@
 $as_echo "$ac_cv_host" >&6; }
 case $ac_cv_host in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
 esac
 host=3D$ac_cv_host
 ac_save_IFS=3D$IFS; IFS=3D'-'
@@ -4121,6 +4136,22 @@
 debug=3D$ax_cv_debug
=20
=20
+# Check whether --enable-qemuu-spice was given.
+if test "${enable_qemuu_spice+set}" =3D set; then :
+  enableval=3D$enable_qemuu_spice; qemuu_add_par+=3D" --enable-spice"
+fi
+
+# Check whether --enable-qemuu-usbredir was given.
+if test "${enable_qemuu_usbredir+set}" =3D set; then :
+  enableval=3D$enable_qemuu_usbredir; qemuu_add_par+=3D" --enable-usb-re=
dir"
+fi
+
+# Check whether --enable-qemuu-debug was given.
+if test "${enable_qemuu_debug+set}" =3D set; then :
+  enableval=3D$enable_qemuu_debug; qemuu_add_par+=3D" --enable-debug"
+fi
+
+
=20
=20
=20
@@ -4158,7 +4189,7 @@
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does no=
t truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }=

-if test "${ac_cv_path_SED+set}" =3D set; then :
+if ${ac_cv_path_SED+:} false; then :
   $as_echo_n "(cached) " >&6
 else
             ac_script=3Ds/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbb=
bbbbbbbbbbbbbbbbbbbbbbb/
@@ -4235,7 +4266,7 @@
 set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4275,7 +4306,7 @@
 set dummy gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4328,7 +4359,7 @@
 set dummy ${ac_tool_prefix}cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4368,7 +4399,7 @@
 set dummy cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4427,7 +4458,7 @@
 set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4471,7 +4502,7 @@
 set dummy $ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4526,7 +4557,7 @@
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
=20
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
@@ -4555,7 +4586,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }=

-if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -4592,7 +4623,7 @@
 ac_save_CFLAGS=3D$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" =3D set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=3D$ac_c_werror_flag
@@ -4670,7 +4701,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=3Dno
@@ -4780,7 +4811,7 @@
 $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
 set x ${MAKE-make}
 ac_make=3D`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
-if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" =3D set; then =
:
+if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat >conftest.make <<\_ACEOF
@@ -4824,7 +4855,7 @@
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible i=
nstall" >&5
 $as_echo_n "checking for a BSD-compatible install... " >&6; }
 if test -z "$INSTALL"; then
-if test "${ac_cv_path_install+set}" =3D set; then :
+if ${ac_cv_path_install+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
@@ -4904,7 +4935,7 @@
 set dummy perl; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PERL+set}" =3D set; then :
+if ${ac_cv_path_PERL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PERL in
@@ -4951,7 +4982,7 @@
 set dummy curl-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_CURL+set}" =3D set; then :
+if ${ac_cv_path_CURL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $CURL in
@@ -4996,7 +5027,7 @@
 set dummy xml2-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XML+set}" =3D set; then :
+if ${ac_cv_path_XML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XML in
@@ -5047,7 +5078,7 @@
 set dummy ${ac_tool_prefix}ocamlc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLC+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLC"; then
@@ -5087,7 +5118,7 @@
 set dummy ocamlc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLC"; then
@@ -5158,7 +5189,7 @@
 set dummy ${ac_tool_prefix}ocamlopt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPT+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPT"; then
@@ -5198,7 +5229,7 @@
 set dummy ocamlopt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPT"; then
@@ -5268,7 +5299,7 @@
 set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLCDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLCDOTOPT"; then
@@ -5308,7 +5339,7 @@
 set dummy ocamlc.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLCDOTOPT"; then
@@ -5372,7 +5403,7 @@
 set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPTDOTOPT"; then
@@ -5412,7 +5443,7 @@
 set dummy ocamlopt.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
@@ -5481,7 +5512,7 @@
 set dummy ${ac_tool_prefix}ocaml; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAML+set}" =3D set; then :
+if ${ac_cv_prog_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAML"; then
@@ -5521,7 +5552,7 @@
 set dummy ocaml; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAML+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAML"; then
@@ -5575,7 +5606,7 @@
 set dummy ${ac_tool_prefix}ocamldep; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDEP+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDEP"; then
@@ -5615,7 +5646,7 @@
 set dummy ocamldep; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDEP"; then
@@ -5669,7 +5700,7 @@
 set dummy ${ac_tool_prefix}ocamlmktop; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKTOP+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKTOP"; then
@@ -5709,7 +5740,7 @@
 set dummy ocamlmktop; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKTOP"; then
@@ -5763,7 +5794,7 @@
 set dummy ${ac_tool_prefix}ocamlmklib; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKLIB+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKLIB"; then
@@ -5803,7 +5834,7 @@
 set dummy ocamlmklib; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKLIB"; then
@@ -5857,7 +5888,7 @@
 set dummy ${ac_tool_prefix}ocamldoc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDOC+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDOC"; then
@@ -5897,7 +5928,7 @@
 set dummy ocamldoc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDOC"; then
@@ -5951,7 +5982,7 @@
 set dummy ${ac_tool_prefix}ocamlbuild; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLBUILD+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLBUILD"; then
@@ -5991,7 +6022,7 @@
 set dummy ocamlbuild; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLBUILD"; then
@@ -6054,7 +6085,7 @@
 set dummy bash; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BASH+set}" =3D set; then :
+if ${ac_cv_path_BASH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $BASH in
@@ -6111,7 +6142,7 @@
 set dummy $PYTHON; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PYTHONPATH+set}" =3D set; then :
+if ${ac_cv_path_PYTHONPATH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PYTHONPATH in
@@ -6187,7 +6218,7 @@
     print distutils.sysconfig.get_config_var("LDFLAGS")'`"
=20
 ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h=
" "$ac_includes_default"
-if test "x$ac_cv_header_Python_h" =3D x""yes; then :
+if test "x$ac_cv_header_Python_h" =3D xyes; then :
=20
 else
   as_fn_error $? "Unable to find Python development headers" "$LINENO" 5=

@@ -6197,7 +6228,7 @@
 as_ac_Lib=3D`$as_echo "ac_cv_lib_python$ac_python_version''_PyArg_ParseT=
uple" | $as_tr_sh`
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PyArg_ParseTuple i=
n -lpython$ac_python_version" >&5
 $as_echo_n "checking for PyArg_ParseTuple in -lpython$ac_python_version.=
=2E. " >&6; }
-if eval "test \"\${$as_ac_Lib+set}\"" =3D set; then :
+if eval \${$as_ac_Lib+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6252,7 +6283,7 @@
 set dummy xgettext; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XGETTEXT+set}" =3D set; then :
+if ${ac_cv_path_XGETTEXT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XGETTEXT in
@@ -6295,11 +6326,11 @@
 fi
=20
 ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_=
uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_uuid_h" =3D x""yes; then :
+if test "x$ac_cv_header_uuid_uuid_h" =3D xyes; then :
=20
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in =
-luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
-if test "${ac_cv_lib_uuid_uuid_clear+set}" =3D set; then :
+if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6333,7 +6364,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_cl=
ear" >&5
 $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
-if test "x$ac_cv_lib_uuid_uuid_clear" =3D x""yes; then :
+if test "x$ac_cv_lib_uuid_uuid_clear" =3D xyes; then :
   libuuid=3D"y"
 fi
=20
@@ -6342,7 +6373,7 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$=
ac_includes_default"
-if test "x$ac_cv_header_uuid_h" =3D x""yes; then :
+if test "x$ac_cv_header_uuid_h" =3D xyes; then :
   libuuid=3D"y"
 fi
=20
@@ -6355,11 +6386,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h=
" "$ac_includes_default"
-if test "x$ac_cv_header_curses_h" =3D x""yes; then :
+if test "x$ac_cv_header_curses_h" =3D xyes; then :
=20
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcur=
ses" >&5
 $as_echo_n "checking for clear in -lcurses... " >&6; }
-if test "${ac_cv_lib_curses_clear+set}" =3D set; then :
+if ${ac_cv_lib_curses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6393,7 +6424,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear=
" >&5
 $as_echo "$ac_cv_lib_curses_clear" >&6; }
-if test "x$ac_cv_lib_curses_clear" =3D x""yes; then :
+if test "x$ac_cv_lib_curses_clear" =3D xyes; then :
   curses=3D"y"
 else
   curses=3D"n"
@@ -6406,11 +6437,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses=
_h" "$ac_includes_default"
-if test "x$ac_cv_header_ncurses_h" =3D x""yes; then :
+if test "x$ac_cv_header_ncurses_h" =3D xyes; then :
=20
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncu=
rses" >&5
 $as_echo_n "checking for clear in -lncurses... " >&6; }
-if test "${ac_cv_lib_ncurses_clear+set}" =3D set; then :
+if ${ac_cv_lib_ncurses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6444,7 +6475,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clea=
r" >&5
 $as_echo "$ac_cv_lib_ncurses_clear" >&6; }
-if test "x$ac_cv_lib_ncurses_clear" =3D x""yes; then :
+if test "x$ac_cv_lib_ncurses_clear" =3D xyes; then :
   ncurses=3D"y"
 else
   ncurses=3D"n"
@@ -6491,7 +6522,7 @@
 set dummy ${ac_tool_prefix}pkg-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PKG_CONFIG+set}" =3D set; then :
+if ${ac_cv_path_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PKG_CONFIG in
@@ -6534,7 +6565,7 @@
 set dummy pkg-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" =3D set; then :
+if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $ac_pt_PKG_CONFIG in
@@ -6679,7 +6710,7 @@
 See the pkg-config man page for more details.
=20
 To get pkg-config, see <http://pkg-config.freedesktop.org/>.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
 	glib_CFLAGS=3D$pkg_cv_glib_CFLAGS
 	glib_LIBS=3D$pkg_cv_glib_LIBS
@@ -6715,11 +6746,11 @@
=20
 # Checks for libraries.
 ac_fn_c_check_header_mongrel "$LINENO" "bzlib.h" "ac_cv_header_bzlib_h" =
"$ac_includes_default"
-if test "x$ac_cv_header_bzlib_h" =3D x""yes; then :
+if test "x$ac_cv_header_bzlib_h" =3D xyes; then :
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for BZ2_bzDecompressIn=
it in -lbz2" >&5
 $as_echo_n "checking for BZ2_bzDecompressInit in -lbz2... " >&6; }
-if test "${ac_cv_lib_bz2_BZ2_bzDecompressInit+set}" =3D set; then :
+if ${ac_cv_lib_bz2_BZ2_bzDecompressInit+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6753,7 +6784,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_bz2_BZ2_bzDe=
compressInit" >&5
 $as_echo "$ac_cv_lib_bz2_BZ2_bzDecompressInit" >&6; }
-if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D x""yes; then :
+if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D xyes; then :
   zlib=3D"$zlib -DHAVE_BZLIB -lbz2"
 fi
=20
@@ -6762,11 +6793,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "lzma.h" "ac_cv_header_lzma_h" "$=
ac_includes_default"
-if test "x$ac_cv_header_lzma_h" =3D x""yes; then :
+if test "x$ac_cv_header_lzma_h" =3D xyes; then :
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzma_stream_decode=
r in -llzma" >&5
 $as_echo_n "checking for lzma_stream_decoder in -llzma... " >&6; }
-if test "${ac_cv_lib_lzma_lzma_stream_decoder+set}" =3D set; then :
+if ${ac_cv_lib_lzma_lzma_stream_decoder+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6800,7 +6831,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzma_lzma_st=
ream_decoder" >&5
 $as_echo "$ac_cv_lib_lzma_lzma_stream_decoder" >&6; }
-if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D x""yes; then :
+if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D xyes; then :
   zlib=3D"$zlib -DHAVE_LZMA -llzma"
 fi
=20
@@ -6809,11 +6840,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "lzo/lzo1x.h" "ac_cv_header_lzo_l=
zo1x_h" "$ac_includes_default"
-if test "x$ac_cv_header_lzo_lzo1x_h" =3D x""yes; then :
+if test "x$ac_cv_header_lzo_lzo1x_h" =3D xyes; then :
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzo1x_decompress i=
n -llzo2" >&5
 $as_echo_n "checking for lzo1x_decompress in -llzo2... " >&6; }
-if test "${ac_cv_lib_lzo2_lzo1x_decompress+set}" =3D set; then :
+if ${ac_cv_lib_lzo2_lzo1x_decompress+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6847,7 +6878,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzo2_lzo1x_d=
ecompress" >&5
 $as_echo "$ac_cv_lib_lzo2_lzo1x_decompress" >&6; }
-if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D x""yes; then :
+if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D xyes; then :
   zlib=3D"$zlib -DHAVE_LZO1X -llzo2"
 fi
=20
@@ -6858,7 +6889,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio"=
 >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
-if test "${ac_cv_lib_aio_io_setup+set}" =3D set; then :
+if ${ac_cv_lib_aio_io_setup+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6892,7 +6923,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup=
" >&5
 $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
-if test "x$ac_cv_lib_aio_io_setup" =3D x""yes; then :
+if test "x$ac_cv_lib_aio_io_setup" =3D xyes; then :
   system_aio=3D"y"
 else
   system_aio=3D"n"
@@ -6901,7 +6932,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >=
&5
 $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
-if test "${ac_cv_lib_crypto_MD5+set}" =3D set; then :
+if ${ac_cv_lib_crypto_MD5+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6935,7 +6966,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" =
>&5
 $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
-if test "x$ac_cv_lib_crypto_MD5" =3D x""yes; then :
+if test "x$ac_cv_lib_crypto_MD5" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBCRYPTO 1
 _ACEOF
@@ -6948,7 +6979,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -l=
ext2fs" >&5
 $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
-if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" =3D set; then :
+if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6982,7 +7013,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2f=
s_open2" >&5
 $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
-if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D x""yes; then :
+if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D xyes; then :
   libext2fs=3D"y"
 else
   libext2fs=3D"n"
@@ -6991,7 +7022,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffe=
r in -lgcrypt" >&5
 $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" =3D set; then :
+if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7025,7 +7056,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_=
md_hash_buffer" >&5
 $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D x""yes; then :
+if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D xyes; then :
   libgcrypt=3D"y"
 else
   libgcrypt=3D"n"
@@ -7034,7 +7065,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in =
-lpthread" >&5
 $as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if test "${ac_cv_lib_pthread_pthread_create+set}" =3D set; then :
+if ${ac_cv_lib_pthread_pthread_create+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7068,7 +7099,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthr=
ead_create" >&5
 $as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" =3D x""yes; then :
+if test "x$ac_cv_lib_pthread_pthread_create" =3D xyes; then :
=20
 else
   as_fn_error $? "Could not find libpthread" "$LINENO" 5
@@ -7076,7 +7107,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -=
lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
-if test "${ac_cv_lib_rt_clock_gettime+set}" =3D set; then :
+if ${ac_cv_lib_rt_clock_gettime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7110,7 +7141,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_get=
time" >&5
 $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
-if test "x$ac_cv_lib_rt_clock_gettime" =3D x""yes; then :
+if test "x$ac_cv_lib_rt_clock_gettime" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBRT 1
 _ACEOF
@@ -7121,7 +7152,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lya=
jl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
-if test "${ac_cv_lib_yajl_yajl_alloc+set}" =3D set; then :
+if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7155,7 +7186,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_al=
loc" >&5
 $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
-if test "x$ac_cv_lib_yajl_yajl_alloc" =3D x""yes; then :
+if test "x$ac_cv_lib_yajl_yajl_alloc" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBYAJL 1
 _ACEOF
@@ -7168,7 +7199,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz=
" >&5
 $as_echo_n "checking for deflateCopy in -lz... " >&6; }
-if test "${ac_cv_lib_z_deflateCopy+set}" =3D set; then :
+if ${ac_cv_lib_z_deflateCopy+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7202,7 +7233,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCop=
y" >&5
 $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
-if test "x$ac_cv_lib_z_deflateCopy" =3D x""yes; then :
+if test "x$ac_cv_lib_z_deflateCopy" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBZ 1
 _ACEOF
@@ -7215,7 +7246,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -=
liconv" >&5
 $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
-if test "${ac_cv_lib_iconv_libiconv_open+set}" =3D set; then :
+if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7249,7 +7280,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libico=
nv_open" >&5
 $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
-if test "x$ac_cv_lib_iconv_libiconv_open" =3D x""yes; then :
+if test "x$ac_cv_lib_iconv_libiconv_open" =3D xyes; then :
   libiconv=3D"y"
 else
   libiconv=3D"n"
@@ -7258,11 +7289,22 @@
=20
=20
 # Checks for header files.
+ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
+if test "x$ac_cv_type_size_t" =3D xyes; then :
+
+else
+
+cat >>confdefs.h <<_ACEOF
+#define size_t unsigned int
+_ACEOF
+
+fi
+
 # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
 # for constant arguments.  Useless!
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" =
>&5
 $as_echo_n "checking for working alloca.h... " >&6; }
-if test "${ac_cv_working_alloca_h+set}" =3D set; then :
+if ${ac_cv_working_alloca_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7295,7 +7337,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
 $as_echo_n "checking for alloca... " >&6; }
-if test "${ac_cv_func_alloca_works+set}" =3D set; then :
+if ${ac_cv_func_alloca_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7314,7 +7356,7 @@
  #pragma alloca
 #   else
 #    ifndef alloca /* predefined by HP cc +Olibcalls */
-char *alloca ();
+void *alloca (size_t);
 #    endif
 #   endif
 #  endif
@@ -7358,7 +7400,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' ne=
eds Cray hooks" >&5
 $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
-if test "${ac_cv_os_cray+set}" =3D set; then :
+if ${ac_cv_os_cray+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7399,7 +7441,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C =
alloca" >&5
 $as_echo_n "checking stack direction for C alloca... " >&6; }
-if test "${ac_cv_c_stack_direction+set}" =3D set; then :
+if ${ac_cv_c_stack_direction+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -7470,7 +7512,7 @@
 # Checks for typedefs, structures, and compiler characteristics.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that con=
forms to C99" >&5
 $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
-if test "${ac_cv_header_stdbool_h+set}" =3D set; then :
+if ${ac_cv_header_stdbool_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7502,7 +7544,7 @@
 	char b[false =3D=3D 0 ? 1 : -1];
 	char c[__bool_true_false_are_defined =3D=3D 1 ? 1 : -1];
 	char d[(bool) 0.5 =3D=3D true ? 1 : -1];
-	bool e =3D &s;
+	/* See body of main program for 'e'.  */
 	char f[(_Bool) 0.0 =3D=3D false ? 1 : -1];
 	char g[true];
 	char h[sizeof (_Bool)];
@@ -7513,25 +7555,6 @@
 	_Bool n[m];
 	char o[sizeof n =3D=3D m * sizeof n[0] ? 1 : -1];
 	char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
-#	if defined __xlc__ || defined __GNUC__
-	 /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
-	    reported by James Lemley on 2005-10-05; see
-	    http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.ht=
ml
-	    This test is not quite right, since xlc is allowed to
-	    reject this program, as the initializer for xlcbug is
-	    not one of the forms that C requires support for.
-	    However, doing the test right would require a runtime
-	    test, and that would make cross-compilation harder.
-	    Let us hope that IBM fixes the xlc bug, and also adds
-	    support for this kind of constant expression.  In the
-	    meantime, this test will reject xlc, which is OK, since
-	    our stdbool.h substitute should suffice.  We also test
-	    this with GCC, where it should work, to detect more
-	    quickly whether someone messes up the test in the
-	    future.  */
-	 char digs[] =3D "0123456789";
-	 int xlcbug =3D 1 / (&(digs + 5)[-2 + (bool) 1] =3D=3D &digs[4] ? 1 : -=
1);
-#	endif
 	/* Catch a bug in an HP-UX C compiler.  See
 	   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
 	   http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.htm=
l
@@ -7543,6 +7566,7 @@
 main ()
 {
=20
+	bool e =3D &s;
 	*pq |=3D q;
 	*pq |=3D ! q;
 	/* Refer to every declared value, to avoid compiler optimizations.  */
@@ -7563,7 +7587,7 @@
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h=
" >&5
 $as_echo "$ac_cv_header_stdbool_h" >&6; }
 ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_de=
fault"
-if test "x$ac_cv_type__Bool" =3D x""yes; then :
+if test "x$ac_cv_type__Bool" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE__BOOL 1
@@ -7580,7 +7604,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types=
=2Eh" >&5
 $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
-if test "${ac_cv_type_uid_t+set}" =3D set; then :
+if ${ac_cv_type_uid_t+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7610,7 +7634,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
 $as_echo_n "checking for inline... " >&6; }
-if test "${ac_cv_c_inline+set}" =3D set; then :
+if ${ac_cv_c_inline+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_inline=3Dno
@@ -7695,7 +7719,7 @@
 esac
=20
 ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_=
default"
-if test "x$ac_cv_type_mode_t" =3D x""yes; then :
+if test "x$ac_cv_type_mode_t" =3D xyes; then :
=20
 else
=20
@@ -7706,7 +7730,7 @@
 fi
=20
 ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_de=
fault"
-if test "x$ac_cv_type_off_t" =3D x""yes; then :
+if test "x$ac_cv_type_off_t" =3D xyes; then :
=20
 else
=20
@@ -7717,7 +7741,7 @@
 fi
=20
 ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_de=
fault"
-if test "x$ac_cv_type_pid_t" =3D x""yes; then :
+if test "x$ac_cv_type_pid_t" =3D xyes; then :
=20
 else
=20
@@ -7729,7 +7753,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict key=
word" >&5
 $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
-if test "${ac_cv_c_restrict+set}" =3D set; then :
+if ${ac_cv_c_restrict+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_restrict=3Dno
@@ -7774,7 +7798,7 @@
  esac
=20
 ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
-if test "x$ac_cv_type_size_t" =3D x""yes; then :
+if test "x$ac_cv_type_size_t" =3D xyes; then :
=20
 else
=20
@@ -7785,7 +7809,7 @@
 fi
=20
 ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_include=
s_default"
-if test "x$ac_cv_type_ssize_t" =3D x""yes; then :
+if test "x$ac_cv_type_ssize_t" =3D xyes; then :
=20
 else
=20
@@ -7796,7 +7820,7 @@
 fi
=20
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_=
struct_stat_st_blksize" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blksize" =3D x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blksize" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
@@ -7806,7 +7830,7 @@
 fi
=20
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_s=
truct_stat_st_blocks" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blocks" =3D x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blocks" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLOCKS 1
@@ -7826,7 +7850,7 @@
=20
=20
 ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_str=
uct_stat_st_rdev" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_rdev" =3D x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_rdev" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_RDEV 1
@@ -7890,7 +7914,7 @@
   esac
=20
 ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_inc=
ludes_default"
-if test "x$ac_cv_type_ptrdiff_t" =3D x""yes; then :
+if test "x$ac_cv_type_ptrdiff_t" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_PTRDIFF_T 1
@@ -7903,7 +7927,7 @@
 # Checks for library functions.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5=

 $as_echo_n "checking for error_at_line... " >&6; }
-if test "${ac_cv_lib_error_at_line+set}" =3D set; then :
+if ${ac_cv_lib_error_at_line+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7939,7 +7963,7 @@
 for ac_header in vfork.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h=
" "$ac_includes_default"
-if test "x$ac_cv_header_vfork_h" =3D x""yes; then :
+if test "x$ac_cv_header_vfork_h" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_VFORK_H 1
 _ACEOF
@@ -7963,7 +7987,7 @@
 if test "x$ac_cv_func_fork" =3D xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&=
5
 $as_echo_n "checking for working fork... " >&6; }
-if test "${ac_cv_func_fork_works+set}" =3D set; then :
+if ${ac_cv_func_fork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8016,7 +8040,7 @@
 if test "x$ac_cv_func_vfork" =3D xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >=
&5
 $as_echo_n "checking for working vfork... " >&6; }
-if test "${ac_cv_func_vfork_works+set}" =3D set; then :
+if ${ac_cv_func_vfork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8151,7 +8175,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE =
value needed for large files" >&5
 $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files.=
=2E. " >&6; }
-if test "${ac_cv_sys_largefile_source+set}" =3D set; then :
+if ${ac_cv_sys_largefile_source+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   while :; do
@@ -8219,7 +8243,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctl=
y handles trailing slash" >&5
 $as_echo_n "checking whether lstat correctly handles trailing slash... "=
 >&6; }
-if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" =3D set; =
then :
+if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   rm -f conftest.sym conftest.file
@@ -8281,7 +8305,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h de=
fines makedev" >&5
 $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
-if test "${ac_cv_header_sys_types_h_makedev+set}" =3D set; then :
+if ${ac_cv_header_sys_types_h_makedev+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8309,7 +8333,7 @@
=20
 if test $ac_cv_header_sys_types_h_makedev =3D no; then
 ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_m=
kdev_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_mkdev_h" =3D x""yes; then :
+if test "x$ac_cv_header_sys_mkdev_h" =3D xyes; then :
=20
 $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
=20
@@ -8319,7 +8343,7 @@
=20
   if test $ac_cv_header_sys_mkdev_h =3D no; then
     ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_head=
er_sys_sysmacros_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_sysmacros_h" =3D x""yes; then :
+if test "x$ac_cv_header_sys_sysmacros_h" =3D xyes; then :
=20
 $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
=20
@@ -8332,7 +8356,7 @@
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
+if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8343,7 +8367,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e malloc" >&5
 $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
-if test "${ac_cv_func_malloc_0_nonnull+set}" =3D set; then :
+if ${ac_cv_func_malloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8398,7 +8422,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys=
/time.h may both be included" >&5
 $as_echo_n "checking whether time.h and sys/time.h may both be included.=
=2E. " >&6; }
-if test "${ac_cv_header_time+set}" =3D set; then :
+if ${ac_cv_header_time+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8473,7 +8497,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&=
5
 $as_echo_n "checking for working mktime... " >&6; }
-if test "${ac_cv_func_working_mktime+set}" =3D set; then :
+if ${ac_cv_func_working_mktime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8702,7 +8726,7 @@
 for ac_func in getpagesize
 do :
   ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
-if test "x$ac_cv_func_getpagesize" =3D x""yes; then :
+if test "x$ac_cv_func_getpagesize" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_GETPAGESIZE 1
 _ACEOF
@@ -8712,7 +8736,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
 $as_echo_n "checking for working mmap... " >&6; }
-if test "${ac_cv_func_mmap_fixed_mapped+set}" =3D set; then :
+if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8879,7 +8903,7 @@
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
+if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8890,7 +8914,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e realloc" >&5
 $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
-if test "${ac_cv_func_realloc_0_nonnull+set}" =3D set; then :
+if ${ac_cv_func_realloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8943,13 +8967,17 @@
 fi
=20
=20
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >=
&5
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" =
>&5
 $as_echo_n "checking for working strnlen... " >&6; }
-if test "${ac_cv_func_strnlen_working+set}" =3D set; then :
+if ${ac_cv_func_strnlen_working+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
-  ac_cv_func_strnlen_working=3Dno
+  # Guess no on AIX systems, yes otherwise.
+		case "$host_os" in
+		  aix*) ac_cv_func_strnlen_working=3Dno;;
+		  *)    ac_cv_func_strnlen_working=3Dyes;;
+		esac
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -8998,7 +9026,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&=
5
 $as_echo_n "checking for working strtod... " >&6; }
-if test "${ac_cv_func_strtod+set}" =3D set; then :
+if ${ac_cv_func_strtod+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -9057,14 +9085,14 @@
 esac
=20
 ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
-if test "x$ac_cv_func_pow" =3D x""yes; then :
+if test "x$ac_cv_func_pow" =3D xyes; then :
=20
 fi
=20
 if test $ac_cv_func_pow =3D no; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
 $as_echo_n "checking for pow in -lm... " >&6; }
-if test "${ac_cv_lib_m_pow+set}" =3D set; then :
+if ${ac_cv_lib_m_pow+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -9098,7 +9126,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
 $as_echo "$ac_cv_lib_m_pow" >&6; }
-if test "x$ac_cv_lib_m_pow" =3D x""yes; then :
+if test "x$ac_cv_lib_m_pow" =3D xyes; then :
   POW_LIB=3D-lm
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library =
containing definition of pow" >&5
@@ -9194,10 +9222,21 @@
      :end' >>confcache
 if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
   if test -w "$cache_file"; then
-    test "x$cache_file" !=3D "x/dev/null" &&
+    if test "x$cache_file" !=3D "x/dev/null"; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_fil=
e" >&5
 $as_echo "$as_me: updating cache $cache_file" >&6;}
-    cat confcache >$cache_file
+      if test ! -f "$cache_file" || test -h "$cache_file"; then
+	cat confcache >"$cache_file"
+      else
+        case $cache_file in #(
+        */* | ?:*)
+	  mv -f confcache "$cache_file"$$ &&
+	  mv -f "$cache_file"$$ "$cache_file" ;; #(
+        *)
+	  mv -f confcache "$cache_file" ;;
+	esac
+      fi
+    fi
   else
     { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cac=
he $cache_file" >&5
 $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
@@ -9229,7 +9268,7 @@
=20
=20
=20
-: ${CONFIG_STATUS=3D./config.status}
+: "${CONFIG_STATUS=3D./config.status}"
 ac_write_fail=3D0
 ac_clean_files_save=3D$ac_clean_files
 ac_clean_files=3D"$ac_clean_files $CONFIG_STATUS"
@@ -9330,6 +9369,7 @@
 IFS=3D" ""	$as_nl"
=20
 # Find who we are.  Look in the path if we contain no directory separato=
r.
+as_myself=3D
 case $0 in #((
   *[\\/]* ) as_myself=3D$0 ;;
   *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
@@ -9637,7 +9677,7 @@
 # values after options handling.
 ac_log=3D"
 This file was extended by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
=20
   CONFIG_FILES    =3D $CONFIG_FILES
   CONFIG_HEADERS  =3D $CONFIG_HEADERS
@@ -9699,7 +9739,7 @@
 ac_cs_config=3D"`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\=
$]/\\\\&/g'`"
 ac_cs_version=3D"\\
 Xen Hypervisor config.status 4.2
-configured by $0, generated by GNU Autoconf 2.67,
+configured by $0, generated by GNU Autoconf 2.68,
   with options \\"\$ac_cs_config\\"
=20
 Copyright (C) 2010 Free Software Foundation, Inc.
@@ -9823,7 +9863,7 @@
     "../config/Tools.mk") CONFIG_FILES=3D"$CONFIG_FILES ../config/Tools.=
mk" ;;
     "config.h") CONFIG_HEADERS=3D"$CONFIG_HEADERS config.h" ;;
=20
-  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
 ;;
+  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
;;
   esac
 done
=20
@@ -9845,9 +9885,10 @@
 # after its creation but before its name has been assigned to `$tmp'.
 $debug ||
 {
-  tmp=3D
+  tmp=3D ac_tmp=3D
   trap 'exit_status=3D$?
-  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit=
_status
+  : "${ac_tmp:=3D$tmp}"
+  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
 ' 0
   trap 'as_fn_exit 1' 1 2 13 15
 }
@@ -9855,12 +9896,13 @@
=20
 {
   tmp=3D`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
-  test -n "$tmp" && test -d "$tmp"
+  test -d "$tmp"
 }  ||
 {
   tmp=3D./conf$$-$RANDOM
   (umask 077 && mkdir "$tmp")
 } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO"=
 5
+ac_tmp=3D$tmp
=20
 # Set up the scripts for CONFIG_FILES section.
 # No need to generate them if there are no CONFIG_FILES.
@@ -9882,7 +9924,7 @@
   ac_cs_awk_cr=3D$ac_cr
 fi
=20
-echo 'BEGIN {' >"$tmp/subs1.awk" &&
+echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
 _ACEOF
=20
=20
@@ -9910,7 +9952,7 @@
 rm -f conf$$subs.sh
=20
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
-cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
 _ACEOF
 sed -n '
 h
@@ -9958,7 +10000,7 @@
 rm -f conf$$subs.awk
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
 _ACAWK
-cat >>"\$tmp/subs1.awk" <<_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
   for (key in S) S_is_set[key] =3D 1
   FS =3D "=07"
=20
@@ -9990,7 +10032,7 @@
   sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
 else
   cat
-fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
+fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
   || as_fn_error $? "could not setup config files machinery" "$LINENO" 5=

 _ACEOF
=20
@@ -10024,7 +10066,7 @@
 # No need to generate them if there are no CONFIG_HEADERS.
 # This happens for instance with `./config.status Makefile'.
 if test -n "$CONFIG_HEADERS"; then
-cat >"$tmp/defines.awk" <<\_ACAWK ||
+cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
 BEGIN {
 _ACEOF
=20
@@ -10036,8 +10078,8 @@
 # handling of long lines.
 ac_delim=3D'%!_!# '
 for ac_last_try in false false :; do
-  ac_t=3D`sed -n "/$ac_delim/p" confdefs.h`
-  if test -z "$ac_t"; then
+  ac_tt=3D`sed -n "/$ac_delim/p" confdefs.h`
+  if test -z "$ac_tt"; then
     break
   elif $ac_last_try; then
     as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
@@ -10138,7 +10180,7 @@
   esac
   case $ac_mode$ac_tag in
   :[FHL]*:*);;
-  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
+  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
   :[FH]-) ac_tag=3D-:-;;
   :[FH]*) ac_tag=3D$ac_tag:$ac_tag.in;;
   esac
@@ -10157,7 +10199,7 @@
     for ac_f
     do
       case $ac_f in
-      -) ac_f=3D"$tmp/stdin";;
+      -) ac_f=3D"$ac_tmp/stdin";;
       *) # Look for the file first in the build tree, then in the source=
 tree
 	 # (if the path is not absolute).  The absolute path cannot be DOS-styl=
e,
 	 # because $ac_f cannot contain `:'.
@@ -10166,7 +10208,7 @@
 	   [\\/$]*) false;;
 	   *) test -f "$srcdir/$ac_f" && ac_f=3D"$srcdir/$ac_f";;
 	   esac ||
-	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
+	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
       esac
       case $ac_f in *\'*) ac_f=3D`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\'=
'/g"`;; esac
       as_fn_append ac_file_inputs " '$ac_f'"
@@ -10192,8 +10234,8 @@
     esac
=20
     case $ac_tag in
-    *:-:* | *:-) cat >"$tmp/stdin" \
-      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
+    *:-:* | *:-) cat >"$ac_tmp/stdin" \
+      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
     esac
     ;;
   esac
@@ -10323,21 +10365,22 @@
 s&@INSTALL@&$ac_INSTALL&;t t
 $ac_datarootdir_hack
 "
-eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" =
>$tmp/out \
-  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
+eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.aw=
k" \
+  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5=

=20
 test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
-  { ac_out=3D`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"=
; } &&
-  { ac_out=3D`sed -n '/^[	 ]*datarootdir[	 ]*:*=3D/p' "$tmp/out"`; test =
-z "$ac_out"; } &&
+  { ac_out=3D`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_o=
ut"; } &&
+  { ac_out=3D`sed -n '/^[	 ]*datarootdir[	 ]*:*=3D/p' \
+      "$ac_tmp/out"`; test -z "$ac_out"; } &&
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a =
reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&5
 $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable=
 \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&2;}
=20
-  rm -f "$tmp/stdin"
+  rm -f "$ac_tmp/stdin"
   case $ac_file in
-  -) cat "$tmp/out" && rm -f "$tmp/out";;
-  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
+  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
+  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
   esac \
   || as_fn_error $? "could not create $ac_file" "$LINENO" 5
  ;;
@@ -10348,20 +10391,20 @@
   if test x"$ac_file" !=3D x-; then
     {
       $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
-    } >"$tmp/config.h" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
+    } >"$ac_tmp/config.h" \
       || as_fn_error $? "could not create $ac_file" "$LINENO" 5
-    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
+    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&=
5
 $as_echo "$as_me: $ac_file is unchanged" >&6;}
     else
       rm -f "$ac_file"
-      mv "$tmp/config.h" "$ac_file" \
+      mv "$ac_tmp/config.h" "$ac_file" \
 	|| as_fn_error $? "could not create $ac_file" "$LINENO" 5
     fi
   else
     $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
       || as_fn_error $? "could not create -" "$LINENO" 5
   fi
  ;;
diff -r 527b8ae57ff2 -r 9fb366d55ed2 tools/configure.ac
--- a/tools/configure.ac	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure.ac	mer apr 04 15:10:26 2012 +0200
@@ -44,6 +44,16 @@
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice	Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream=
],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug	Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)
=20
 AC_ARG_VAR([PREPEND_INCLUDES],
     [List of include folders to prepend to CFLAGS (without -I)])

--------------050506080203010500080701--

--------------ms040009030202020409000402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQwNDEzMzA1MFowIwYJKoZIhvcNAQkEMRYEFLlo/opChODbbWsspBoLTPJ3
p2WyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBqBa3rgRryb+8f5SiC6zQ3csJbu4PKNJ3memWCVWOE
r6sfplbTEaDGywf8POASI01MWf5l7NC+/umJgL5qz3xvlxaCa36QOLggezmerOyk+ws0ewTM
46tZrr+k68WjnH0bXxYa2ZcZX3el61G0ymzqNbZJjB04aPAnd21A4fZ8EBB3zMlIhv4ODHG6
XqO+2fOJ8dMyHcuosvjSB0SjD/VMk9uj05jpkqJ6C/550E4De76h3Xr23Y6+ZvhndcLiGmCm
soPbZo/9Ho8heNnkOzCOyEVCiCm19ePFCEpif26jphQJR/rtMMRWhpEwARLF0Rn7+6B6aonP
T3VQ4SEcNpCZAAAAAAAA
--------------ms040009030202020409000402--


--===============7463004862380400107==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7463004862380400107==--


From xen-devel-bounces@lists.xen.org Wed Apr 04 13:31:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 13:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFQIl-00081d-1l; Wed, 04 Apr 2012 13:31:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFQIi-00081Y-HT
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 13:31:05 +0000
Received: from [85.158.138.51:30103] by server-3.bemta-3.messagelabs.com id
	F9/B5-10665-71D4C7F4; Wed, 04 Apr 2012 13:31:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333546260!20770312!1
X-Originating-IP: [82.57.200.103]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22399 invoked from network); 4 Apr 2012 13:31:00 -0000
Received: from smtp207.alice.it (HELO smtp207.alice.it) (82.57.200.103)
	by server-4.tower-174.messagelabs.com with SMTP;
	4 Apr 2012 13:31:00 -0000
Received: from [192.168.178.50] (87.2.83.254) by smtp207.alice.it (8.6.023.02)
	id 4F05A6650A8171D7 for xen-devel@lists.xensource.com;
	Wed, 4 Apr 2012 15:30:58 +0200
Message-ID: <4F7C4D0A.1070809@tiscali.it>
Date: Wed, 04 Apr 2012 15:30:50 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] Autoconf: add variable for pass arbitrary
 options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7463004862380400107=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7463004862380400107==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040009030202020409000402"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms040009030202020409000402
Content-Type: multipart/mixed;
 boundary="------------050506080203010500080701"

This is a multi-part message in MIME format.
--------------050506080203010500080701
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Autoconf: add variable for pass arbitrary options to qemu upstream v2

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Patch attached.

--------------050506080203010500080701
Content-Type: text/plain; charset=windows-1252;
 name="autoconf_add_arbitrary_options_qemuu_v2.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="autoconf_add_arbitrary_options_qemuu_v2.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1333545026 -7200
# Node ID 9fb366d55ed2c192f3c0871e678de2a9e5067165
# Parent  527b8ae57ff2fce676c662fb42e31e65007b2036
autoconf: add variable for pass arbitrary options to qemu upstream v2

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 527b8ae57ff2 -r 9fb366d55ed2 config/Tools.mk.in
--- a/config/Tools.mk.in	mer apr 04 14:36:16 2012 +0200
+++ b/config/Tools.mk.in	mer apr 04 15:10:26 2012 +0200
@@ -44,3 +44,4 @@
 CONFIG_GCRYPT       :=3D @libgcrypt@
 CONFIG_EXT2FS       :=3D @libext2fs@
 CURSES_LIBS         :=3D @CURSES_LIBS@
+CONFIG_QEMUU_ADD_PAR:=3D @qemuu_add_par@
diff -r 527b8ae57ff2 -r 9fb366d55ed2 tools/Makefile
--- a/tools/Makefile	mer apr 04 14:36:16 2012 +0200
+++ b/tools/Makefile	mer apr 04 15:10:26 2012 +0200
@@ -157,6 +157,7 @@
 		--datadir=3D$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
 		--python=3D$(PYTHON) \
+		$(CONFIG_QEMUU_ADD_PAR) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install
=20
diff -r 527b8ae57ff2 -r 9fb366d55ed2 tools/configure
--- a/tools/configure	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure	mer apr 04 15:10:26 2012 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
 #
 # Report bugs to <xen-devel@lists.xensource.com>.
 #
@@ -91,6 +91,7 @@
 IFS=3D" ""	$as_nl"
=20
 # Find who we are.  Look in the path if we contain no directory separato=
r.
+as_myself=3D
 case $0 in #((
   *[\\/]* ) as_myself=3D$0 ;;
   *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
@@ -216,11 +217,18 @@
   # We cannot yet assume a decent shell, so we have to provide a
 	# neutralization value for shells without unset; and this also
 	# works around shells that cannot unset nonexistent variables.
+	# Preserve -v and -x to the replacement shell.
 	BASH_ENV=3D/dev/null
 	ENV=3D/dev/null
 	(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
 	export CONFIG_SHELL
-	exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
+	case $- in # ((((
+	  *v*x* | *x*v* ) as_opts=3D-vx ;;
+	  *v* ) as_opts=3D-v ;;
+	  *x* ) as_opts=3D-x ;;
+	  * ) as_opts=3D ;;
+	esac
+	exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
 fi
=20
     if test x$as_have_required =3D xno; then :
@@ -645,6 +653,7 @@
 APPEND_INCLUDES
 PREPEND_LIB
 PREPEND_INCLUDES
+qemuu_add_par
 debug
 lomount
 miniterm
@@ -722,6 +731,9 @@
 enable_miniterm
 enable_lomount
 enable_debug
+enable_qemuu_spice
+enable_qemuu_usbredir
+enable_qemuu_debug
 '
       ac_precious_vars=3D'build_alias
 host_alias
@@ -1153,7 +1165,7 @@
     $as_echo "$as_me: WARNING: you should use --build, --host, --target"=
 >&2
     expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
       $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
-    : ${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_al=
ias=3D$ac_option}
+    : "${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_a=
lias=3D$ac_option}"
     ;;
=20
   esac
@@ -1376,6 +1388,9 @@
   --enable-miniterm       Enable miniterm (default is DISABLED)
   --enable-lomount        Enable lomount (default is DISABLED)
   --disable-debug         Disable debug build of tools (default is ENABL=
ED)
+  --enable-qemuu-spice	Enable Spice build on qemu upstream
+  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream
+  --enable-qemuu-debug	Enable debug build on qemu upstream
=20
 Some influential environment variables:
   CC          C compiler command
@@ -1475,7 +1490,7 @@
 if $ac_init_version; then
   cat <<\_ACEOF
 Xen Hypervisor configure 4.2
-generated by GNU Autoconf 2.67
+generated by GNU Autoconf 2.68
=20
 Copyright (C) 2010 Free Software Foundation, Inc.
 This configure script is free software; the Free Software Foundation
@@ -1521,7 +1536,7 @@
=20
 	ac_retval=3D1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_compile
@@ -1558,7 +1573,7 @@
=20
     ac_retval=3D1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_cpp
@@ -1571,10 +1586,10 @@
 ac_fn_c_check_header_mongrel ()
 {
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
-  if eval "test \"\${$3+set}\"" =3D set; then :
+  if eval \${$3+:} false; then :
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 fi
 eval ac_res=3D\$$3
@@ -1641,7 +1656,7 @@
 esac
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=3D\$ac_header_compiler"
@@ -1650,7 +1665,7 @@
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_header_mongrel
=20
@@ -1691,7 +1706,7 @@
        ac_retval=3D$ac_status
 fi
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_run
@@ -1705,7 +1720,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1723,7 +1738,7 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_header_compile
=20
@@ -1768,11 +1783,65 @@
   # interfere with the next link command; also delete a directory that i=
s
   # left behind by Apple's compiler.  We do this before executing the ac=
tions.
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
=20
 } # ac_fn_c_try_link
=20
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# -------------------------------------------
+# Tests whether TYPE exists after having included INCLUDES, setting cach=
e
+# variable VAR accordingly.
+ac_fn_c_check_type ()
+{
+  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval \${$3+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  eval "$3=3Dno"
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof ($2))
+	 return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof (($2)))
+	    return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+
+else
+  eval "$3=3Dyes"
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+eval ac_res=3D\$$3
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+
+} # ac_fn_c_check_type
+
 # ac_fn_c_check_func LINENO FUNC VAR
 # ----------------------------------
 # Tests whether FUNC exists, setting the cache variable VAR accordingly
@@ -1781,7 +1850,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1836,64 +1905,10 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_func
=20
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# -------------------------------------------
-# Tests whether TYPE exists after having included INCLUDES, setting cach=
e
-# variable VAR accordingly.
-ac_fn_c_check_type ()
-{
-  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  eval "$3=3Dno"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof ($2))
-	 return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof (($2)))
-	    return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  eval "$3=3Dyes"
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-eval ac_res=3D\$$3
-	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
-
-} # ac_fn_c_check_type
-
 # ac_fn_c_find_intX_t LINENO BITS VAR
 # -----------------------------------
 # Finds a signed integer type with width BITS, setting cache variable VA=
R
@@ -1903,7 +1918,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
 $as_echo_n "checking for int$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=3Dno"
@@ -1964,7 +1979,7 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_find_intX_t
=20
@@ -1977,7 +1992,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
 $as_echo_n "checking for $2.$3... " >&6; }
-if eval "test \"\${$4+set}\"" =3D set; then :
+if eval \${$4+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -2021,7 +2036,7 @@
 eval ac_res=3D\$$4
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_check_member
=20
@@ -2034,7 +2049,7 @@
   as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
 $as_echo_n "checking for uint$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" =3D set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=3Dno"
@@ -2074,7 +2089,7 @@
 eval ac_res=3D\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=3D=
; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
=20
 } # ac_fn_c_find_uintX_t
 cat >config.log <<_ACEOF
@@ -2082,7 +2097,7 @@
 running configure, to aid debugging if configure makes a mistake.
=20
 It was created by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
=20
   $ $0 $@
=20
@@ -2340,7 +2355,7 @@
       || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd'=
:" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "failed to load site script $ac_site_file
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
   fi
 done
=20
@@ -2493,7 +2508,7 @@
 set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2533,7 +2548,7 @@
 set dummy gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2586,7 +2601,7 @@
 set dummy ${ac_tool_prefix}cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2626,7 +2641,7 @@
 set dummy cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2685,7 +2700,7 @@
 set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2729,7 +2744,7 @@
 set dummy $ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2784,7 +2799,7 @@
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
=20
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
@@ -2899,7 +2914,7 @@
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error 77 "C compiler cannot create executables
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
@@ -2942,7 +2957,7 @@
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of executables: cannot compile and=
 link
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest conftest$ac_cv_exeext
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
@@ -3001,7 +3016,7 @@
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
     fi
   fi
 fi
@@ -3012,7 +3027,7 @@
 ac_clean_files=3D$ac_clean_files_save
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object f=
iles" >&5
 $as_echo_n "checking for suffix of object files... " >&6; }
-if test "${ac_cv_objext+set}" =3D set; then :
+if ${ac_cv_objext+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3053,7 +3068,7 @@
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of object files: cannot compile
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest.$ac_cv_objext conftest.$ac_ext
 fi
@@ -3063,7 +3078,7 @@
 ac_objext=3D$OBJEXT
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }=

-if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3100,7 +3115,7 @@
 ac_save_CFLAGS=3D$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" =3D set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=3D$ac_c_werror_flag
@@ -3178,7 +3193,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=3Dno
@@ -3286,7 +3301,7 @@
   CPP=3D
 fi
 if test -z "$CPP"; then
-  if test "${ac_cv_prog_CPP+set}" =3D set; then :
+  if ${ac_cv_prog_CPP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
       # Double quotes because CPP needs to be expanded
@@ -3402,7 +3417,7 @@
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
=20
 ac_ext=3Dc
@@ -3414,7 +3429,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles =
long lines and -e" >&5
 $as_echo_n "checking for grep that handles long lines and -e... " >&6; }=

-if test "${ac_cv_path_GREP+set}" =3D set; then :
+if ${ac_cv_path_GREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -z "$GREP"; then
@@ -3477,7 +3492,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
 $as_echo_n "checking for egrep... " >&6; }
-if test "${ac_cv_path_EGREP+set}" =3D set; then :
+if ${ac_cv_path_EGREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
@@ -3544,7 +3559,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header file=
s" >&5
 $as_echo_n "checking for ANSI C header files... " >&6; }
-if test "${ac_cv_header_stdc+set}" =3D set; then :
+if ${ac_cv_header_stdc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3673,7 +3688,7 @@
=20
=20
   ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_=
minix_config_h" "$ac_includes_default"
-if test "x$ac_cv_header_minix_config_h" =3D x""yes; then :
+if test "x$ac_cv_header_minix_config_h" =3D xyes; then :
   MINIX=3Dyes
 else
   MINIX=3D
@@ -3695,7 +3710,7 @@
=20
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe t=
o define __EXTENSIONS__" >&5
 $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&=
6; }
-if test "${ac_cv_safe_to_define___extensions__+set}" =3D set; then :
+if ${ac_cv_safe_to_define___extensions__+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3738,7 +3753,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5=

 $as_echo_n "checking build system type... " >&6; }
-if test "${ac_cv_build+set}" =3D set; then :
+if ${ac_cv_build+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_build_alias=3D$build_alias
@@ -3754,7 +3769,7 @@
 $as_echo "$ac_cv_build" >&6; }
 case $ac_cv_build in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
 esac
 build=3D$ac_cv_build
 ac_save_IFS=3D$IFS; IFS=3D'-'
@@ -3772,7 +3787,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
 $as_echo_n "checking host system type... " >&6; }
-if test "${ac_cv_host+set}" =3D set; then :
+if ${ac_cv_host+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "x$host_alias" =3D x; then
@@ -3787,7 +3802,7 @@
 $as_echo "$ac_cv_host" >&6; }
 case $ac_cv_host in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
 esac
 host=3D$ac_cv_host
 ac_save_IFS=3D$IFS; IFS=3D'-'
@@ -4121,6 +4136,22 @@
 debug=3D$ax_cv_debug
=20
=20
+# Check whether --enable-qemuu-spice was given.
+if test "${enable_qemuu_spice+set}" =3D set; then :
+  enableval=3D$enable_qemuu_spice; qemuu_add_par+=3D" --enable-spice"
+fi
+
+# Check whether --enable-qemuu-usbredir was given.
+if test "${enable_qemuu_usbredir+set}" =3D set; then :
+  enableval=3D$enable_qemuu_usbredir; qemuu_add_par+=3D" --enable-usb-re=
dir"
+fi
+
+# Check whether --enable-qemuu-debug was given.
+if test "${enable_qemuu_debug+set}" =3D set; then :
+  enableval=3D$enable_qemuu_debug; qemuu_add_par+=3D" --enable-debug"
+fi
+
+
=20
=20
=20
@@ -4158,7 +4189,7 @@
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does no=
t truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }=

-if test "${ac_cv_path_SED+set}" =3D set; then :
+if ${ac_cv_path_SED+:} false; then :
   $as_echo_n "(cached) " >&6
 else
             ac_script=3Ds/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbb=
bbbbbbbbbbbbbbbbbbbbbbb/
@@ -4235,7 +4266,7 @@
 set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4275,7 +4306,7 @@
 set dummy gcc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4328,7 +4359,7 @@
 set dummy ${ac_tool_prefix}cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4368,7 +4399,7 @@
 set dummy cc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4427,7 +4458,7 @@
 set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" =3D set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4471,7 +4502,7 @@
 set dummy $ac_prog; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4526,7 +4557,7 @@
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
=20
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
@@ -4555,7 +4586,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }=

-if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -4592,7 +4623,7 @@
 ac_save_CFLAGS=3D$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" =3D set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=3D$ac_c_werror_flag
@@ -4670,7 +4701,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=3Dno
@@ -4780,7 +4811,7 @@
 $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
 set x ${MAKE-make}
 ac_make=3D`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
-if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" =3D set; then =
:
+if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat >conftest.make <<\_ACEOF
@@ -4824,7 +4855,7 @@
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible i=
nstall" >&5
 $as_echo_n "checking for a BSD-compatible install... " >&6; }
 if test -z "$INSTALL"; then
-if test "${ac_cv_path_install+set}" =3D set; then :
+if ${ac_cv_path_install+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
@@ -4904,7 +4935,7 @@
 set dummy perl; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PERL+set}" =3D set; then :
+if ${ac_cv_path_PERL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PERL in
@@ -4951,7 +4982,7 @@
 set dummy curl-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_CURL+set}" =3D set; then :
+if ${ac_cv_path_CURL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $CURL in
@@ -4996,7 +5027,7 @@
 set dummy xml2-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XML+set}" =3D set; then :
+if ${ac_cv_path_XML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XML in
@@ -5047,7 +5078,7 @@
 set dummy ${ac_tool_prefix}ocamlc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLC+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLC"; then
@@ -5087,7 +5118,7 @@
 set dummy ocamlc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLC"; then
@@ -5158,7 +5189,7 @@
 set dummy ${ac_tool_prefix}ocamlopt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPT+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPT"; then
@@ -5198,7 +5229,7 @@
 set dummy ocamlopt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPT"; then
@@ -5268,7 +5299,7 @@
 set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLCDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLCDOTOPT"; then
@@ -5308,7 +5339,7 @@
 set dummy ocamlc.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLCDOTOPT"; then
@@ -5372,7 +5403,7 @@
 set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPTDOTOPT"; then
@@ -5412,7 +5443,7 @@
 set dummy ocamlopt.opt; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
@@ -5481,7 +5512,7 @@
 set dummy ${ac_tool_prefix}ocaml; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAML+set}" =3D set; then :
+if ${ac_cv_prog_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAML"; then
@@ -5521,7 +5552,7 @@
 set dummy ocaml; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAML+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAML"; then
@@ -5575,7 +5606,7 @@
 set dummy ${ac_tool_prefix}ocamldep; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDEP+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDEP"; then
@@ -5615,7 +5646,7 @@
 set dummy ocamldep; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDEP"; then
@@ -5669,7 +5700,7 @@
 set dummy ${ac_tool_prefix}ocamlmktop; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKTOP+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKTOP"; then
@@ -5709,7 +5740,7 @@
 set dummy ocamlmktop; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKTOP"; then
@@ -5763,7 +5794,7 @@
 set dummy ${ac_tool_prefix}ocamlmklib; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKLIB+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKLIB"; then
@@ -5803,7 +5834,7 @@
 set dummy ocamlmklib; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKLIB"; then
@@ -5857,7 +5888,7 @@
 set dummy ${ac_tool_prefix}ocamldoc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDOC+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDOC"; then
@@ -5897,7 +5928,7 @@
 set dummy ocamldoc; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDOC"; then
@@ -5951,7 +5982,7 @@
 set dummy ${ac_tool_prefix}ocamlbuild; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLBUILD+set}" =3D set; then :
+if ${ac_cv_prog_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLBUILD"; then
@@ -5991,7 +6022,7 @@
 set dummy ocamlbuild; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" =3D set; then :
+if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLBUILD"; then
@@ -6054,7 +6085,7 @@
 set dummy bash; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BASH+set}" =3D set; then :
+if ${ac_cv_path_BASH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $BASH in
@@ -6111,7 +6142,7 @@
 set dummy $PYTHON; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PYTHONPATH+set}" =3D set; then :
+if ${ac_cv_path_PYTHONPATH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PYTHONPATH in
@@ -6187,7 +6218,7 @@
     print distutils.sysconfig.get_config_var("LDFLAGS")'`"
=20
 ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h=
" "$ac_includes_default"
-if test "x$ac_cv_header_Python_h" =3D x""yes; then :
+if test "x$ac_cv_header_Python_h" =3D xyes; then :
=20
 else
   as_fn_error $? "Unable to find Python development headers" "$LINENO" 5=

@@ -6197,7 +6228,7 @@
 as_ac_Lib=3D`$as_echo "ac_cv_lib_python$ac_python_version''_PyArg_ParseT=
uple" | $as_tr_sh`
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PyArg_ParseTuple i=
n -lpython$ac_python_version" >&5
 $as_echo_n "checking for PyArg_ParseTuple in -lpython$ac_python_version.=
=2E. " >&6; }
-if eval "test \"\${$as_ac_Lib+set}\"" =3D set; then :
+if eval \${$as_ac_Lib+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6252,7 +6283,7 @@
 set dummy xgettext; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XGETTEXT+set}" =3D set; then :
+if ${ac_cv_path_XGETTEXT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XGETTEXT in
@@ -6295,11 +6326,11 @@
 fi
=20
 ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_=
uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_uuid_h" =3D x""yes; then :
+if test "x$ac_cv_header_uuid_uuid_h" =3D xyes; then :
=20
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in =
-luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
-if test "${ac_cv_lib_uuid_uuid_clear+set}" =3D set; then :
+if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6333,7 +6364,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_cl=
ear" >&5
 $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
-if test "x$ac_cv_lib_uuid_uuid_clear" =3D x""yes; then :
+if test "x$ac_cv_lib_uuid_uuid_clear" =3D xyes; then :
   libuuid=3D"y"
 fi
=20
@@ -6342,7 +6373,7 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$=
ac_includes_default"
-if test "x$ac_cv_header_uuid_h" =3D x""yes; then :
+if test "x$ac_cv_header_uuid_h" =3D xyes; then :
   libuuid=3D"y"
 fi
=20
@@ -6355,11 +6386,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h=
" "$ac_includes_default"
-if test "x$ac_cv_header_curses_h" =3D x""yes; then :
+if test "x$ac_cv_header_curses_h" =3D xyes; then :
=20
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcur=
ses" >&5
 $as_echo_n "checking for clear in -lcurses... " >&6; }
-if test "${ac_cv_lib_curses_clear+set}" =3D set; then :
+if ${ac_cv_lib_curses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6393,7 +6424,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear=
" >&5
 $as_echo "$ac_cv_lib_curses_clear" >&6; }
-if test "x$ac_cv_lib_curses_clear" =3D x""yes; then :
+if test "x$ac_cv_lib_curses_clear" =3D xyes; then :
   curses=3D"y"
 else
   curses=3D"n"
@@ -6406,11 +6437,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses=
_h" "$ac_includes_default"
-if test "x$ac_cv_header_ncurses_h" =3D x""yes; then :
+if test "x$ac_cv_header_ncurses_h" =3D xyes; then :
=20
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncu=
rses" >&5
 $as_echo_n "checking for clear in -lncurses... " >&6; }
-if test "${ac_cv_lib_ncurses_clear+set}" =3D set; then :
+if ${ac_cv_lib_ncurses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6444,7 +6475,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clea=
r" >&5
 $as_echo "$ac_cv_lib_ncurses_clear" >&6; }
-if test "x$ac_cv_lib_ncurses_clear" =3D x""yes; then :
+if test "x$ac_cv_lib_ncurses_clear" =3D xyes; then :
   ncurses=3D"y"
 else
   ncurses=3D"n"
@@ -6491,7 +6522,7 @@
 set dummy ${ac_tool_prefix}pkg-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PKG_CONFIG+set}" =3D set; then :
+if ${ac_cv_path_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PKG_CONFIG in
@@ -6534,7 +6565,7 @@
 set dummy pkg-config; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" =3D set; then :
+if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $ac_pt_PKG_CONFIG in
@@ -6679,7 +6710,7 @@
 See the pkg-config man page for more details.
=20
 To get pkg-config, see <http://pkg-config.freedesktop.org/>.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
 	glib_CFLAGS=3D$pkg_cv_glib_CFLAGS
 	glib_LIBS=3D$pkg_cv_glib_LIBS
@@ -6715,11 +6746,11 @@
=20
 # Checks for libraries.
 ac_fn_c_check_header_mongrel "$LINENO" "bzlib.h" "ac_cv_header_bzlib_h" =
"$ac_includes_default"
-if test "x$ac_cv_header_bzlib_h" =3D x""yes; then :
+if test "x$ac_cv_header_bzlib_h" =3D xyes; then :
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for BZ2_bzDecompressIn=
it in -lbz2" >&5
 $as_echo_n "checking for BZ2_bzDecompressInit in -lbz2... " >&6; }
-if test "${ac_cv_lib_bz2_BZ2_bzDecompressInit+set}" =3D set; then :
+if ${ac_cv_lib_bz2_BZ2_bzDecompressInit+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6753,7 +6784,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_bz2_BZ2_bzDe=
compressInit" >&5
 $as_echo "$ac_cv_lib_bz2_BZ2_bzDecompressInit" >&6; }
-if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D x""yes; then :
+if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D xyes; then :
   zlib=3D"$zlib -DHAVE_BZLIB -lbz2"
 fi
=20
@@ -6762,11 +6793,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "lzma.h" "ac_cv_header_lzma_h" "$=
ac_includes_default"
-if test "x$ac_cv_header_lzma_h" =3D x""yes; then :
+if test "x$ac_cv_header_lzma_h" =3D xyes; then :
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzma_stream_decode=
r in -llzma" >&5
 $as_echo_n "checking for lzma_stream_decoder in -llzma... " >&6; }
-if test "${ac_cv_lib_lzma_lzma_stream_decoder+set}" =3D set; then :
+if ${ac_cv_lib_lzma_lzma_stream_decoder+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6800,7 +6831,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzma_lzma_st=
ream_decoder" >&5
 $as_echo "$ac_cv_lib_lzma_lzma_stream_decoder" >&6; }
-if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D x""yes; then :
+if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D xyes; then :
   zlib=3D"$zlib -DHAVE_LZMA -llzma"
 fi
=20
@@ -6809,11 +6840,11 @@
=20
=20
 ac_fn_c_check_header_mongrel "$LINENO" "lzo/lzo1x.h" "ac_cv_header_lzo_l=
zo1x_h" "$ac_includes_default"
-if test "x$ac_cv_header_lzo_lzo1x_h" =3D x""yes; then :
+if test "x$ac_cv_header_lzo_lzo1x_h" =3D xyes; then :
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzo1x_decompress i=
n -llzo2" >&5
 $as_echo_n "checking for lzo1x_decompress in -llzo2... " >&6; }
-if test "${ac_cv_lib_lzo2_lzo1x_decompress+set}" =3D set; then :
+if ${ac_cv_lib_lzo2_lzo1x_decompress+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6847,7 +6878,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzo2_lzo1x_d=
ecompress" >&5
 $as_echo "$ac_cv_lib_lzo2_lzo1x_decompress" >&6; }
-if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D x""yes; then :
+if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D xyes; then :
   zlib=3D"$zlib -DHAVE_LZO1X -llzo2"
 fi
=20
@@ -6858,7 +6889,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio"=
 >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
-if test "${ac_cv_lib_aio_io_setup+set}" =3D set; then :
+if ${ac_cv_lib_aio_io_setup+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6892,7 +6923,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup=
" >&5
 $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
-if test "x$ac_cv_lib_aio_io_setup" =3D x""yes; then :
+if test "x$ac_cv_lib_aio_io_setup" =3D xyes; then :
   system_aio=3D"y"
 else
   system_aio=3D"n"
@@ -6901,7 +6932,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >=
&5
 $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
-if test "${ac_cv_lib_crypto_MD5+set}" =3D set; then :
+if ${ac_cv_lib_crypto_MD5+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6935,7 +6966,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" =
>&5
 $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
-if test "x$ac_cv_lib_crypto_MD5" =3D x""yes; then :
+if test "x$ac_cv_lib_crypto_MD5" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBCRYPTO 1
 _ACEOF
@@ -6948,7 +6979,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -l=
ext2fs" >&5
 $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
-if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" =3D set; then :
+if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -6982,7 +7013,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2f=
s_open2" >&5
 $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
-if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D x""yes; then :
+if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D xyes; then :
   libext2fs=3D"y"
 else
   libext2fs=3D"n"
@@ -6991,7 +7022,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffe=
r in -lgcrypt" >&5
 $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" =3D set; then :
+if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7025,7 +7056,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_=
md_hash_buffer" >&5
 $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D x""yes; then :
+if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D xyes; then :
   libgcrypt=3D"y"
 else
   libgcrypt=3D"n"
@@ -7034,7 +7065,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in =
-lpthread" >&5
 $as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if test "${ac_cv_lib_pthread_pthread_create+set}" =3D set; then :
+if ${ac_cv_lib_pthread_pthread_create+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7068,7 +7099,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthr=
ead_create" >&5
 $as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" =3D x""yes; then :
+if test "x$ac_cv_lib_pthread_pthread_create" =3D xyes; then :
=20
 else
   as_fn_error $? "Could not find libpthread" "$LINENO" 5
@@ -7076,7 +7107,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -=
lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
-if test "${ac_cv_lib_rt_clock_gettime+set}" =3D set; then :
+if ${ac_cv_lib_rt_clock_gettime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7110,7 +7141,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_get=
time" >&5
 $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
-if test "x$ac_cv_lib_rt_clock_gettime" =3D x""yes; then :
+if test "x$ac_cv_lib_rt_clock_gettime" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBRT 1
 _ACEOF
@@ -7121,7 +7152,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lya=
jl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
-if test "${ac_cv_lib_yajl_yajl_alloc+set}" =3D set; then :
+if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7155,7 +7186,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_al=
loc" >&5
 $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
-if test "x$ac_cv_lib_yajl_yajl_alloc" =3D x""yes; then :
+if test "x$ac_cv_lib_yajl_yajl_alloc" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBYAJL 1
 _ACEOF
@@ -7168,7 +7199,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz=
" >&5
 $as_echo_n "checking for deflateCopy in -lz... " >&6; }
-if test "${ac_cv_lib_z_deflateCopy+set}" =3D set; then :
+if ${ac_cv_lib_z_deflateCopy+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7202,7 +7233,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCop=
y" >&5
 $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
-if test "x$ac_cv_lib_z_deflateCopy" =3D x""yes; then :
+if test "x$ac_cv_lib_z_deflateCopy" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBZ 1
 _ACEOF
@@ -7215,7 +7246,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -=
liconv" >&5
 $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
-if test "${ac_cv_lib_iconv_libiconv_open+set}" =3D set; then :
+if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -7249,7 +7280,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libico=
nv_open" >&5
 $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
-if test "x$ac_cv_lib_iconv_libiconv_open" =3D x""yes; then :
+if test "x$ac_cv_lib_iconv_libiconv_open" =3D xyes; then :
   libiconv=3D"y"
 else
   libiconv=3D"n"
@@ -7258,11 +7289,22 @@
=20
=20
 # Checks for header files.
+ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
+if test "x$ac_cv_type_size_t" =3D xyes; then :
+
+else
+
+cat >>confdefs.h <<_ACEOF
+#define size_t unsigned int
+_ACEOF
+
+fi
+
 # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
 # for constant arguments.  Useless!
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" =
>&5
 $as_echo_n "checking for working alloca.h... " >&6; }
-if test "${ac_cv_working_alloca_h+set}" =3D set; then :
+if ${ac_cv_working_alloca_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7295,7 +7337,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
 $as_echo_n "checking for alloca... " >&6; }
-if test "${ac_cv_func_alloca_works+set}" =3D set; then :
+if ${ac_cv_func_alloca_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7314,7 +7356,7 @@
  #pragma alloca
 #   else
 #    ifndef alloca /* predefined by HP cc +Olibcalls */
-char *alloca ();
+void *alloca (size_t);
 #    endif
 #   endif
 #  endif
@@ -7358,7 +7400,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' ne=
eds Cray hooks" >&5
 $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
-if test "${ac_cv_os_cray+set}" =3D set; then :
+if ${ac_cv_os_cray+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7399,7 +7441,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C =
alloca" >&5
 $as_echo_n "checking stack direction for C alloca... " >&6; }
-if test "${ac_cv_c_stack_direction+set}" =3D set; then :
+if ${ac_cv_c_stack_direction+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -7470,7 +7512,7 @@
 # Checks for typedefs, structures, and compiler characteristics.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that con=
forms to C99" >&5
 $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
-if test "${ac_cv_header_stdbool_h+set}" =3D set; then :
+if ${ac_cv_header_stdbool_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7502,7 +7544,7 @@
 	char b[false =3D=3D 0 ? 1 : -1];
 	char c[__bool_true_false_are_defined =3D=3D 1 ? 1 : -1];
 	char d[(bool) 0.5 =3D=3D true ? 1 : -1];
-	bool e =3D &s;
+	/* See body of main program for 'e'.  */
 	char f[(_Bool) 0.0 =3D=3D false ? 1 : -1];
 	char g[true];
 	char h[sizeof (_Bool)];
@@ -7513,25 +7555,6 @@
 	_Bool n[m];
 	char o[sizeof n =3D=3D m * sizeof n[0] ? 1 : -1];
 	char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
-#	if defined __xlc__ || defined __GNUC__
-	 /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
-	    reported by James Lemley on 2005-10-05; see
-	    http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.ht=
ml
-	    This test is not quite right, since xlc is allowed to
-	    reject this program, as the initializer for xlcbug is
-	    not one of the forms that C requires support for.
-	    However, doing the test right would require a runtime
-	    test, and that would make cross-compilation harder.
-	    Let us hope that IBM fixes the xlc bug, and also adds
-	    support for this kind of constant expression.  In the
-	    meantime, this test will reject xlc, which is OK, since
-	    our stdbool.h substitute should suffice.  We also test
-	    this with GCC, where it should work, to detect more
-	    quickly whether someone messes up the test in the
-	    future.  */
-	 char digs[] =3D "0123456789";
-	 int xlcbug =3D 1 / (&(digs + 5)[-2 + (bool) 1] =3D=3D &digs[4] ? 1 : -=
1);
-#	endif
 	/* Catch a bug in an HP-UX C compiler.  See
 	   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
 	   http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.htm=
l
@@ -7543,6 +7566,7 @@
 main ()
 {
=20
+	bool e =3D &s;
 	*pq |=3D q;
 	*pq |=3D ! q;
 	/* Refer to every declared value, to avoid compiler optimizations.  */
@@ -7563,7 +7587,7 @@
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h=
" >&5
 $as_echo "$ac_cv_header_stdbool_h" >&6; }
 ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_de=
fault"
-if test "x$ac_cv_type__Bool" =3D x""yes; then :
+if test "x$ac_cv_type__Bool" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE__BOOL 1
@@ -7580,7 +7604,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types=
=2Eh" >&5
 $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
-if test "${ac_cv_type_uid_t+set}" =3D set; then :
+if ${ac_cv_type_uid_t+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7610,7 +7634,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
 $as_echo_n "checking for inline... " >&6; }
-if test "${ac_cv_c_inline+set}" =3D set; then :
+if ${ac_cv_c_inline+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_inline=3Dno
@@ -7695,7 +7719,7 @@
 esac
=20
 ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_=
default"
-if test "x$ac_cv_type_mode_t" =3D x""yes; then :
+if test "x$ac_cv_type_mode_t" =3D xyes; then :
=20
 else
=20
@@ -7706,7 +7730,7 @@
 fi
=20
 ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_de=
fault"
-if test "x$ac_cv_type_off_t" =3D x""yes; then :
+if test "x$ac_cv_type_off_t" =3D xyes; then :
=20
 else
=20
@@ -7717,7 +7741,7 @@
 fi
=20
 ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_de=
fault"
-if test "x$ac_cv_type_pid_t" =3D x""yes; then :
+if test "x$ac_cv_type_pid_t" =3D xyes; then :
=20
 else
=20
@@ -7729,7 +7753,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict key=
word" >&5
 $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
-if test "${ac_cv_c_restrict+set}" =3D set; then :
+if ${ac_cv_c_restrict+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_restrict=3Dno
@@ -7774,7 +7798,7 @@
  esac
=20
 ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
-if test "x$ac_cv_type_size_t" =3D x""yes; then :
+if test "x$ac_cv_type_size_t" =3D xyes; then :
=20
 else
=20
@@ -7785,7 +7809,7 @@
 fi
=20
 ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_include=
s_default"
-if test "x$ac_cv_type_ssize_t" =3D x""yes; then :
+if test "x$ac_cv_type_ssize_t" =3D xyes; then :
=20
 else
=20
@@ -7796,7 +7820,7 @@
 fi
=20
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_=
struct_stat_st_blksize" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blksize" =3D x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blksize" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
@@ -7806,7 +7830,7 @@
 fi
=20
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_s=
truct_stat_st_blocks" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blocks" =3D x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blocks" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLOCKS 1
@@ -7826,7 +7850,7 @@
=20
=20
 ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_str=
uct_stat_st_rdev" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_rdev" =3D x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_rdev" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_RDEV 1
@@ -7890,7 +7914,7 @@
   esac
=20
 ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_inc=
ludes_default"
-if test "x$ac_cv_type_ptrdiff_t" =3D x""yes; then :
+if test "x$ac_cv_type_ptrdiff_t" =3D xyes; then :
=20
 cat >>confdefs.h <<_ACEOF
 #define HAVE_PTRDIFF_T 1
@@ -7903,7 +7927,7 @@
 # Checks for library functions.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5=

 $as_echo_n "checking for error_at_line... " >&6; }
-if test "${ac_cv_lib_error_at_line+set}" =3D set; then :
+if ${ac_cv_lib_error_at_line+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7939,7 +7963,7 @@
 for ac_header in vfork.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h=
" "$ac_includes_default"
-if test "x$ac_cv_header_vfork_h" =3D x""yes; then :
+if test "x$ac_cv_header_vfork_h" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_VFORK_H 1
 _ACEOF
@@ -7963,7 +7987,7 @@
 if test "x$ac_cv_func_fork" =3D xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&=
5
 $as_echo_n "checking for working fork... " >&6; }
-if test "${ac_cv_func_fork_works+set}" =3D set; then :
+if ${ac_cv_func_fork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8016,7 +8040,7 @@
 if test "x$ac_cv_func_vfork" =3D xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >=
&5
 $as_echo_n "checking for working vfork... " >&6; }
-if test "${ac_cv_func_vfork_works+set}" =3D set; then :
+if ${ac_cv_func_vfork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8151,7 +8175,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE =
value needed for large files" >&5
 $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files.=
=2E. " >&6; }
-if test "${ac_cv_sys_largefile_source+set}" =3D set; then :
+if ${ac_cv_sys_largefile_source+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   while :; do
@@ -8219,7 +8243,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctl=
y handles trailing slash" >&5
 $as_echo_n "checking whether lstat correctly handles trailing slash... "=
 >&6; }
-if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" =3D set; =
then :
+if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   rm -f conftest.sym conftest.file
@@ -8281,7 +8305,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h de=
fines makedev" >&5
 $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
-if test "${ac_cv_header_sys_types_h_makedev+set}" =3D set; then :
+if ${ac_cv_header_sys_types_h_makedev+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8309,7 +8333,7 @@
=20
 if test $ac_cv_header_sys_types_h_makedev =3D no; then
 ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_m=
kdev_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_mkdev_h" =3D x""yes; then :
+if test "x$ac_cv_header_sys_mkdev_h" =3D xyes; then :
=20
 $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
=20
@@ -8319,7 +8343,7 @@
=20
   if test $ac_cv_header_sys_mkdev_h =3D no; then
     ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_head=
er_sys_sysmacros_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_sysmacros_h" =3D x""yes; then :
+if test "x$ac_cv_header_sys_sysmacros_h" =3D xyes; then :
=20
 $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
=20
@@ -8332,7 +8356,7 @@
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
+if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8343,7 +8367,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e malloc" >&5
 $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
-if test "${ac_cv_func_malloc_0_nonnull+set}" =3D set; then :
+if ${ac_cv_func_malloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8398,7 +8422,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys=
/time.h may both be included" >&5
 $as_echo_n "checking whether time.h and sys/time.h may both be included.=
=2E. " >&6; }
-if test "${ac_cv_header_time+set}" =3D set; then :
+if ${ac_cv_header_time+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8473,7 +8497,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&=
5
 $as_echo_n "checking for working mktime... " >&6; }
-if test "${ac_cv_func_working_mktime+set}" =3D set; then :
+if ${ac_cv_func_working_mktime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8702,7 +8726,7 @@
 for ac_func in getpagesize
 do :
   ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
-if test "x$ac_cv_func_getpagesize" =3D x""yes; then :
+if test "x$ac_cv_func_getpagesize" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_GETPAGESIZE 1
 _ACEOF
@@ -8712,7 +8736,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
 $as_echo_n "checking for working mmap... " >&6; }
-if test "${ac_cv_func_mmap_fixed_mapped+set}" =3D set; then :
+if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8879,7 +8903,7 @@
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
+if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8890,7 +8914,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e realloc" >&5
 $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
-if test "${ac_cv_func_realloc_0_nonnull+set}" =3D set; then :
+if ${ac_cv_func_realloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -8943,13 +8967,17 @@
 fi
=20
=20
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >=
&5
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" =
>&5
 $as_echo_n "checking for working strnlen... " >&6; }
-if test "${ac_cv_func_strnlen_working+set}" =3D set; then :
+if ${ac_cv_func_strnlen_working+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
-  ac_cv_func_strnlen_working=3Dno
+  # Guess no on AIX systems, yes otherwise.
+		case "$host_os" in
+		  aix*) ac_cv_func_strnlen_working=3Dno;;
+		  *)    ac_cv_func_strnlen_working=3Dyes;;
+		esac
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -8998,7 +9026,7 @@
=20
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&=
5
 $as_echo_n "checking for working strtod... " >&6; }
-if test "${ac_cv_func_strtod+set}" =3D set; then :
+if ${ac_cv_func_strtod+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" =3D yes; then :
@@ -9057,14 +9085,14 @@
 esac
=20
 ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
-if test "x$ac_cv_func_pow" =3D x""yes; then :
+if test "x$ac_cv_func_pow" =3D xyes; then :
=20
 fi
=20
 if test $ac_cv_func_pow =3D no; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
 $as_echo_n "checking for pow in -lm... " >&6; }
-if test "${ac_cv_lib_m_pow+set}" =3D set; then :
+if ${ac_cv_lib_m_pow+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=3D$LIBS
@@ -9098,7 +9126,7 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
 $as_echo "$ac_cv_lib_m_pow" >&6; }
-if test "x$ac_cv_lib_m_pow" =3D x""yes; then :
+if test "x$ac_cv_lib_m_pow" =3D xyes; then :
   POW_LIB=3D-lm
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library =
containing definition of pow" >&5
@@ -9194,10 +9222,21 @@
      :end' >>confcache
 if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
   if test -w "$cache_file"; then
-    test "x$cache_file" !=3D "x/dev/null" &&
+    if test "x$cache_file" !=3D "x/dev/null"; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_fil=
e" >&5
 $as_echo "$as_me: updating cache $cache_file" >&6;}
-    cat confcache >$cache_file
+      if test ! -f "$cache_file" || test -h "$cache_file"; then
+	cat confcache >"$cache_file"
+      else
+        case $cache_file in #(
+        */* | ?:*)
+	  mv -f confcache "$cache_file"$$ &&
+	  mv -f "$cache_file"$$ "$cache_file" ;; #(
+        *)
+	  mv -f confcache "$cache_file" ;;
+	esac
+      fi
+    fi
   else
     { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cac=
he $cache_file" >&5
 $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
@@ -9229,7 +9268,7 @@
=20
=20
=20
-: ${CONFIG_STATUS=3D./config.status}
+: "${CONFIG_STATUS=3D./config.status}"
 ac_write_fail=3D0
 ac_clean_files_save=3D$ac_clean_files
 ac_clean_files=3D"$ac_clean_files $CONFIG_STATUS"
@@ -9330,6 +9369,7 @@
 IFS=3D" ""	$as_nl"
=20
 # Find who we are.  Look in the path if we contain no directory separato=
r.
+as_myself=3D
 case $0 in #((
   *[\\/]* ) as_myself=3D$0 ;;
   *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
@@ -9637,7 +9677,7 @@
 # values after options handling.
 ac_log=3D"
 This file was extended by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
=20
   CONFIG_FILES    =3D $CONFIG_FILES
   CONFIG_HEADERS  =3D $CONFIG_HEADERS
@@ -9699,7 +9739,7 @@
 ac_cs_config=3D"`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\=
$]/\\\\&/g'`"
 ac_cs_version=3D"\\
 Xen Hypervisor config.status 4.2
-configured by $0, generated by GNU Autoconf 2.67,
+configured by $0, generated by GNU Autoconf 2.68,
   with options \\"\$ac_cs_config\\"
=20
 Copyright (C) 2010 Free Software Foundation, Inc.
@@ -9823,7 +9863,7 @@
     "../config/Tools.mk") CONFIG_FILES=3D"$CONFIG_FILES ../config/Tools.=
mk" ;;
     "config.h") CONFIG_HEADERS=3D"$CONFIG_HEADERS config.h" ;;
=20
-  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
 ;;
+  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
;;
   esac
 done
=20
@@ -9845,9 +9885,10 @@
 # after its creation but before its name has been assigned to `$tmp'.
 $debug ||
 {
-  tmp=3D
+  tmp=3D ac_tmp=3D
   trap 'exit_status=3D$?
-  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit=
_status
+  : "${ac_tmp:=3D$tmp}"
+  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
 ' 0
   trap 'as_fn_exit 1' 1 2 13 15
 }
@@ -9855,12 +9896,13 @@
=20
 {
   tmp=3D`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
-  test -n "$tmp" && test -d "$tmp"
+  test -d "$tmp"
 }  ||
 {
   tmp=3D./conf$$-$RANDOM
   (umask 077 && mkdir "$tmp")
 } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO"=
 5
+ac_tmp=3D$tmp
=20
 # Set up the scripts for CONFIG_FILES section.
 # No need to generate them if there are no CONFIG_FILES.
@@ -9882,7 +9924,7 @@
   ac_cs_awk_cr=3D$ac_cr
 fi
=20
-echo 'BEGIN {' >"$tmp/subs1.awk" &&
+echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
 _ACEOF
=20
=20
@@ -9910,7 +9952,7 @@
 rm -f conf$$subs.sh
=20
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
-cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
 _ACEOF
 sed -n '
 h
@@ -9958,7 +10000,7 @@
 rm -f conf$$subs.awk
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
 _ACAWK
-cat >>"\$tmp/subs1.awk" <<_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
   for (key in S) S_is_set[key] =3D 1
   FS =3D "=07"
=20
@@ -9990,7 +10032,7 @@
   sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
 else
   cat
-fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
+fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
   || as_fn_error $? "could not setup config files machinery" "$LINENO" 5=

 _ACEOF
=20
@@ -10024,7 +10066,7 @@
 # No need to generate them if there are no CONFIG_HEADERS.
 # This happens for instance with `./config.status Makefile'.
 if test -n "$CONFIG_HEADERS"; then
-cat >"$tmp/defines.awk" <<\_ACAWK ||
+cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
 BEGIN {
 _ACEOF
=20
@@ -10036,8 +10078,8 @@
 # handling of long lines.
 ac_delim=3D'%!_!# '
 for ac_last_try in false false :; do
-  ac_t=3D`sed -n "/$ac_delim/p" confdefs.h`
-  if test -z "$ac_t"; then
+  ac_tt=3D`sed -n "/$ac_delim/p" confdefs.h`
+  if test -z "$ac_tt"; then
     break
   elif $ac_last_try; then
     as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
@@ -10138,7 +10180,7 @@
   esac
   case $ac_mode$ac_tag in
   :[FHL]*:*);;
-  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
+  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
   :[FH]-) ac_tag=3D-:-;;
   :[FH]*) ac_tag=3D$ac_tag:$ac_tag.in;;
   esac
@@ -10157,7 +10199,7 @@
     for ac_f
     do
       case $ac_f in
-      -) ac_f=3D"$tmp/stdin";;
+      -) ac_f=3D"$ac_tmp/stdin";;
       *) # Look for the file first in the build tree, then in the source=
 tree
 	 # (if the path is not absolute).  The absolute path cannot be DOS-styl=
e,
 	 # because $ac_f cannot contain `:'.
@@ -10166,7 +10208,7 @@
 	   [\\/$]*) false;;
 	   *) test -f "$srcdir/$ac_f" && ac_f=3D"$srcdir/$ac_f";;
 	   esac ||
-	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
+	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
       esac
       case $ac_f in *\'*) ac_f=3D`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\'=
'/g"`;; esac
       as_fn_append ac_file_inputs " '$ac_f'"
@@ -10192,8 +10234,8 @@
     esac
=20
     case $ac_tag in
-    *:-:* | *:-) cat >"$tmp/stdin" \
-      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
+    *:-:* | *:-) cat >"$ac_tmp/stdin" \
+      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
     esac
     ;;
   esac
@@ -10323,21 +10365,22 @@
 s&@INSTALL@&$ac_INSTALL&;t t
 $ac_datarootdir_hack
 "
-eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" =
>$tmp/out \
-  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
+eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.aw=
k" \
+  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5=

=20
 test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
-  { ac_out=3D`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"=
; } &&
-  { ac_out=3D`sed -n '/^[	 ]*datarootdir[	 ]*:*=3D/p' "$tmp/out"`; test =
-z "$ac_out"; } &&
+  { ac_out=3D`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_o=
ut"; } &&
+  { ac_out=3D`sed -n '/^[	 ]*datarootdir[	 ]*:*=3D/p' \
+      "$ac_tmp/out"`; test -z "$ac_out"; } &&
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a =
reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&5
 $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable=
 \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&2;}
=20
-  rm -f "$tmp/stdin"
+  rm -f "$ac_tmp/stdin"
   case $ac_file in
-  -) cat "$tmp/out" && rm -f "$tmp/out";;
-  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
+  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
+  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
   esac \
   || as_fn_error $? "could not create $ac_file" "$LINENO" 5
  ;;
@@ -10348,20 +10391,20 @@
   if test x"$ac_file" !=3D x-; then
     {
       $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
-    } >"$tmp/config.h" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
+    } >"$ac_tmp/config.h" \
       || as_fn_error $? "could not create $ac_file" "$LINENO" 5
-    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
+    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&=
5
 $as_echo "$as_me: $ac_file is unchanged" >&6;}
     else
       rm -f "$ac_file"
-      mv "$tmp/config.h" "$ac_file" \
+      mv "$ac_tmp/config.h" "$ac_file" \
 	|| as_fn_error $? "could not create $ac_file" "$LINENO" 5
     fi
   else
     $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
       || as_fn_error $? "could not create -" "$LINENO" 5
   fi
  ;;
diff -r 527b8ae57ff2 -r 9fb366d55ed2 tools/configure.ac
--- a/tools/configure.ac	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure.ac	mer apr 04 15:10:26 2012 +0200
@@ -44,6 +44,16 @@
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice	Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream=
],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug	Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)
=20
 AC_ARG_VAR([PREPEND_INCLUDES],
     [List of include folders to prepend to CFLAGS (without -I)])

--------------050506080203010500080701--

--------------ms040009030202020409000402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQwNDEzMzA1MFowIwYJKoZIhvcNAQkEMRYEFLlo/opChODbbWsspBoLTPJ3
p2WyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBqBa3rgRryb+8f5SiC6zQ3csJbu4PKNJ3memWCVWOE
r6sfplbTEaDGywf8POASI01MWf5l7NC+/umJgL5qz3xvlxaCa36QOLggezmerOyk+ws0ewTM
46tZrr+k68WjnH0bXxYa2ZcZX3el61G0ymzqNbZJjB04aPAnd21A4fZ8EBB3zMlIhv4ODHG6
XqO+2fOJ8dMyHcuosvjSB0SjD/VMk9uj05jpkqJ6C/550E4De76h3Xr23Y6+ZvhndcLiGmCm
soPbZo/9Ho8heNnkOzCOyEVCiCm19ePFCEpif26jphQJR/rtMMRWhpEwARLF0Rn7+6B6aonP
T3VQ4SEcNpCZAAAAAAAA
--------------ms040009030202020409000402--


--===============7463004862380400107==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7463004862380400107==--


From xen-devel-bounces@lists.xen.org Wed Apr 04 13:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 13:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFQPU-0008Bh-6z; Wed, 04 Apr 2012 13:38:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFQPT-0008Bc-A9
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 13:38:03 +0000
Received: from [85.158.143.35:29715] by server-3.bemta-4.messagelabs.com id
	7F/FC-05853-ABE4C7F4; Wed, 04 Apr 2012 13:38:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333546681!13117585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1434 invoked from network); 4 Apr 2012 13:38:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 13:38:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="11770128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 13:38:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 14:38:00 +0100
Date: Wed, 4 Apr 2012 14:40:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
In-Reply-To: <1333471466.2485.259.camel@leeds.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204041438130.15151@kaball-desktop>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
	<4F4E64B5.5080900@siemens.com>
	<1330597236.10387.70.camel@leeds.uk.xensource.com>
	<4F4F5BF5.6010206@siemens.com>
	<1330602678.10387.73.camel@leeds.uk.xensource.com>
	<4F4F71F0.4070109@redhat.com>
	<alpine.DEB.2.00.1203011403140.923@kaball-desktop>
	<4F4F81AE.9080503@redhat.com>
	<alpine.DEB.2.00.1203011446190.923@kaball-desktop>
	<4F4F9C3F.5020201@redhat.com>
	<1333471466.2485.259.camel@leeds.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Wei Liu (Intern) wrote:
> On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
> > Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
> > >>> > > That is a good point actually: we already have lapic emulation in Xen,
> > >>> > > it makes sense to have apic-msi in Xen too.
> > >>> > > We would still need the changes to msi_notify and msix_notify though.
> > >> > 
> > >> > Why?  The stores would just go to the Xen interrupt controller MMIO area
> > >> > which then does the xc_hvm_inject_msi.
> > >  
> > > Because msi(x)_notify is called by QEMU's emulated devices: it is not
> > > possible from QEMU to cause an emulation trap in Xen on behalf of the
> > > guest.
> > 
> 
> I'm not a QEMU expert, so following question may be dumb. However I do
> care about a cleaner implementation. So please be patient with me. :-)
> 
> > msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
> > patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
> > 
> 
> I don't quite understand "you don't need anymore the msi{,x}_notify
> parts". Virtio PCI invokes msi_notify directly. If I don't hook up
> msi{,x}_notify, how can I deal with devices like Virtio PCI?

msi_notify calls stl_le_phys that is internal to QEMU and goes to the
emulated local apic in QEMU. So you can just hook into the emulated
local apic like KVM, rather than adding a new hook in msi{,x}_notify.

The fact that the real emulated local apic is in Xen is very confusing
for the sake of this discussion. The emulated local apic in Xen is not
involved in Paolo's suggestion.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 13:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 13:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFQPU-0008Bh-6z; Wed, 04 Apr 2012 13:38:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFQPT-0008Bc-A9
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 13:38:03 +0000
Received: from [85.158.143.35:29715] by server-3.bemta-4.messagelabs.com id
	7F/FC-05853-ABE4C7F4; Wed, 04 Apr 2012 13:38:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333546681!13117585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjczMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1434 invoked from network); 4 Apr 2012 13:38:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 13:38:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="11770128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 13:38:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 14:38:00 +0100
Date: Wed, 4 Apr 2012 14:40:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
In-Reply-To: <1333471466.2485.259.camel@leeds.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204041438130.15151@kaball-desktop>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
	<4F4E64B5.5080900@siemens.com>
	<1330597236.10387.70.camel@leeds.uk.xensource.com>
	<4F4F5BF5.6010206@siemens.com>
	<1330602678.10387.73.camel@leeds.uk.xensource.com>
	<4F4F71F0.4070109@redhat.com>
	<alpine.DEB.2.00.1203011403140.923@kaball-desktop>
	<4F4F81AE.9080503@redhat.com>
	<alpine.DEB.2.00.1203011446190.923@kaball-desktop>
	<4F4F9C3F.5020201@redhat.com>
	<1333471466.2485.259.camel@leeds.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Wei Liu (Intern) wrote:
> On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
> > Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
> > >>> > > That is a good point actually: we already have lapic emulation in Xen,
> > >>> > > it makes sense to have apic-msi in Xen too.
> > >>> > > We would still need the changes to msi_notify and msix_notify though.
> > >> > 
> > >> > Why?  The stores would just go to the Xen interrupt controller MMIO area
> > >> > which then does the xc_hvm_inject_msi.
> > >  
> > > Because msi(x)_notify is called by QEMU's emulated devices: it is not
> > > possible from QEMU to cause an emulation trap in Xen on behalf of the
> > > guest.
> > 
> 
> I'm not a QEMU expert, so following question may be dumb. However I do
> care about a cleaner implementation. So please be patient with me. :-)
> 
> > msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
> > patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
> > 
> 
> I don't quite understand "you don't need anymore the msi{,x}_notify
> parts". Virtio PCI invokes msi_notify directly. If I don't hook up
> msi{,x}_notify, how can I deal with devices like Virtio PCI?

msi_notify calls stl_le_phys that is internal to QEMU and goes to the
emulated local apic in QEMU. So you can just hook into the emulated
local apic like KVM, rather than adding a new hook in msi{,x}_notify.

The fact that the real emulated local apic is in Xen is very confusing
for the sake of this discussion. The emulated local apic in Xen is not
involved in Paolo's suggestion.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 14:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 14:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFQlG-000052-Bp; Wed, 04 Apr 2012 14:00:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.paumonne@citrix.com>) id 1SFQlE-00004x-FN
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 14:00:32 +0000
Received: from [85.158.143.99:35117] by server-1.bemta-4.messagelabs.com id
	8E/1F-20925-FF35C7F4; Wed, 04 Apr 2012 14:00:31 +0000
X-Env-Sender: roger.paumonne@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333548029!12697942!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE1MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6567 invoked from network); 4 Apr 2012 14:00:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 14:00:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,369,1330923600"; d="scan'208";a="188986061"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:00:28 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 10:00:28 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.paumonne@citrix.com>)	id 1SFQl9-0006zW-Rt;
	Wed, 04 Apr 2012 15:00:27 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.paumonne@citrix.com>
In-Reply-To: <4F7C4D0A.1070809@tiscali.it>
Date: Wed, 4 Apr 2012 15:00:33 +0100
Message-ID: <824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
	arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 04/04/2012, a las 14:30, Fabio Fantoni escribi=F3:
> Autoconf: add variable for pass arbitrary options to qemu upstream v2
> =

> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

(I'm gonna expand some of the pieces of the patch to comment them)

[...]

--- a/tools/configure	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure	mer apr 04 15:10:26 2012 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.

You should use autoconf 2.67 to update the configure script.

[...]

--- a/tools/configure.ac	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure.ac	mer apr 04 15:10:26 2012 +0200
@@ -44,6 +44,16 @@
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice	Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug	Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)

Why don't you use AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE?

Take a look at:

http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/249b2eeeeae5

This is still not on the main repository, but it won't take long, so I sugg=
est that you base your patch on top of this change.

> =

> Patch attached.
> <autoconf_add_arbitrary_options_qemuu_v2.patch><smime.p7s>_______________=
________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 14:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 14:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFQlG-000052-Bp; Wed, 04 Apr 2012 14:00:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.paumonne@citrix.com>) id 1SFQlE-00004x-FN
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 14:00:32 +0000
Received: from [85.158.143.99:35117] by server-1.bemta-4.messagelabs.com id
	8E/1F-20925-FF35C7F4; Wed, 04 Apr 2012 14:00:31 +0000
X-Env-Sender: roger.paumonne@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333548029!12697942!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE1MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6567 invoked from network); 4 Apr 2012 14:00:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 14:00:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,369,1330923600"; d="scan'208";a="188986061"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 10:00:28 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 4 Apr 2012 10:00:28 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.paumonne@citrix.com>)	id 1SFQl9-0006zW-Rt;
	Wed, 04 Apr 2012 15:00:27 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.paumonne@citrix.com>
In-Reply-To: <4F7C4D0A.1070809@tiscali.it>
Date: Wed, 4 Apr 2012 15:00:33 +0100
Message-ID: <824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
	arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 04/04/2012, a las 14:30, Fabio Fantoni escribi=F3:
> Autoconf: add variable for pass arbitrary options to qemu upstream v2
> =

> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

(I'm gonna expand some of the pieces of the patch to comment them)

[...]

--- a/tools/configure	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure	mer apr 04 15:10:26 2012 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.

You should use autoconf 2.67 to update the configure script.

[...]

--- a/tools/configure.ac	mer apr 04 14:36:16 2012 +0200
+++ b/tools/configure.ac	mer apr 04 15:10:26 2012 +0200
@@ -44,6 +44,16 @@
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice	Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug	Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)

Why don't you use AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE?

Take a look at:

http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/249b2eeeeae5

This is still not on the main repository, but it won't take long, so I sugg=
est that you base your patch on top of this change.

> =

> Patch attached.
> <autoconf_add_arbitrary_options_qemuu_v2.patch><smime.p7s>_______________=
________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 14:31:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 14:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFREj-0000Qi-4x; Wed, 04 Apr 2012 14:31:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFREh-0000Qd-Qe
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 14:30:59 +0000
Received: from [85.158.143.35:7067] by server-3.bemta-4.messagelabs.com id
	7A/44-05853-32B5C7F4; Wed, 04 Apr 2012 14:30:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333549858!11260159!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27722 invoked from network); 4 Apr 2012 14:30:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Apr 2012 14:30:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Apr 2012 15:30:57 +0100
Message-Id: <4F7C7778020000780007C882@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Apr 2012 15:31:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Haitao Shan" <haitao.shan@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] bogus BUG_ON() in 2.6.18's pci_enable_msix()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Haitao,

in c/s 680:583086d5cd26 you added

	BUG_ON(entries[i].vector != evtchn_get_xen_pirq(irq));

to said function, which seems wrong to me for two reasons: For one,
.vector (as output) always holds Linux IRQ numbers, not Xen ones.
And then this field can't be expected to be set on entry at all, hence
expecting *any* particular value seems incorrect.

Thanks for your thoughts,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 14:31:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 14:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFREj-0000Qi-4x; Wed, 04 Apr 2012 14:31:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFREh-0000Qd-Qe
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 14:30:59 +0000
Received: from [85.158.143.35:7067] by server-3.bemta-4.messagelabs.com id
	7A/44-05853-32B5C7F4; Wed, 04 Apr 2012 14:30:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333549858!11260159!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27722 invoked from network); 4 Apr 2012 14:30:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Apr 2012 14:30:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Apr 2012 15:30:57 +0100
Message-Id: <4F7C7778020000780007C882@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Apr 2012 15:31:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Haitao Shan" <haitao.shan@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] bogus BUG_ON() in 2.6.18's pci_enable_msix()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Haitao,

in c/s 680:583086d5cd26 you added

	BUG_ON(entries[i].vector != evtchn_get_xen_pirq(irq));

to said function, which seems wrong to me for two reasons: For one,
.vector (as output) always holds Linux IRQ numbers, not Xen ones.
And then this field can't be expected to be set on entry at all, hence
expecting *any* particular value seems incorrect.

Thanks for your thoughts,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 14:50:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 14:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRXK-0000d9-Sc; Wed, 04 Apr 2012 14:50:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFRXJ-0000d4-4F
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 14:50:13 +0000
Received: from [85.158.143.99:38623] by server-2.bemta-4.messagelabs.com id
	59/9D-17550-4AF5C7F4; Wed, 04 Apr 2012 14:50:12 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333551010!21434153!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23528 invoked from network); 4 Apr 2012 14:50:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Apr 2012 14:50:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFRXF-00012n-A9
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 07:50:09 -0700
Date: Wed, 4 Apr 2012 07:50:09 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333551009308-5617989.post@n5.nabble.com>
In-Reply-To: <20347.2863.767056.572291@mariner.uk.xensource.com>
References: <4F68A391.90500@tiscali.it>
	<20347.1295.429766.715415@mariner.uk.xensource.com>
	<1333462964743-5615286.post@n5.nabble.com>
	<20347.2863.767056.572291@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
 to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I posted new patch, may be okay now?
http://xen.1045712.n5.nabble.com/PATCH-v2-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-td5617799.html

--
View this message in context: http://xen.1045712.n5.nabble.com/Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5580361p5617989.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 14:50:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 14:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRXK-0000d9-Sc; Wed, 04 Apr 2012 14:50:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFRXJ-0000d4-4F
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 14:50:13 +0000
Received: from [85.158.143.99:38623] by server-2.bemta-4.messagelabs.com id
	59/9D-17550-4AF5C7F4; Wed, 04 Apr 2012 14:50:12 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333551010!21434153!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23528 invoked from network); 4 Apr 2012 14:50:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Apr 2012 14:50:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFRXF-00012n-A9
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 07:50:09 -0700
Date: Wed, 4 Apr 2012 07:50:09 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333551009308-5617989.post@n5.nabble.com>
In-Reply-To: <20347.2863.767056.572291@mariner.uk.xensource.com>
References: <4F68A391.90500@tiscali.it>
	<20347.1295.429766.715415@mariner.uk.xensource.com>
	<1333462964743-5615286.post@n5.nabble.com>
	<20347.2863.767056.572291@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Autoconf: add variable for pass arbitrary options
 to	qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I posted new patch, may be okay now?
http://xen.1045712.n5.nabble.com/PATCH-v2-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-td5617799.html

--
View this message in context: http://xen.1045712.n5.nabble.com/Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5580361p5617989.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRnv-00013C-2O; Wed, 04 Apr 2012 15:07:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRnu-000137-FL
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:07:22 +0000
Received: from [85.158.143.35:42541] by server-1.bemta-4.messagelabs.com id
	51/5B-20925-9A36C7F4; Wed, 04 Apr 2012 15:07:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333552040!11267295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7965 invoked from network); 4 Apr 2012 15:07:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:07:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:07:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:07:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRnr-0008H7-PT; Wed, 04 Apr 2012 15:07:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRnr-00057P-Np;
	Wed, 04 Apr 2012 16:07:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.25511.721114.397748@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:07:19 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global permissive config options for pci passthrough"):
> This patch series adds the "permissive" option for passed-through devices
> which access config space out of the "known good" PCI config space.

Applied both, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRnv-00013C-2O; Wed, 04 Apr 2012 15:07:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRnu-000137-FL
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:07:22 +0000
Received: from [85.158.143.35:42541] by server-1.bemta-4.messagelabs.com id
	51/5B-20925-9A36C7F4; Wed, 04 Apr 2012 15:07:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333552040!11267295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7965 invoked from network); 4 Apr 2012 15:07:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:07:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:07:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:07:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRnr-0008H7-PT; Wed, 04 Apr 2012 15:07:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRnr-00057P-Np;
	Wed, 04 Apr 2012 16:07:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.25511.721114.397748@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:07:19 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1333461291@kodo2>
References: <patchbomb.1333461291@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global
 permissive config options for pci passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 0 of 2] [v2] Add per-device and global permissive config options for pci passthrough"):
> This patch series adds the "permissive" option for passed-through devices
> which access config space out of the "known good" PCI config space.

Applied both, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRpL-00017J-HR; Wed, 04 Apr 2012 15:08:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFRpK-00017D-6X
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:08:50 +0000
Received: from [85.158.143.35:20762] by server-1.bemta-4.messagelabs.com id
	3D/2E-20925-1046C7F4; Wed, 04 Apr 2012 15:08:49 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333552122!11033355!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21444 invoked from network); 4 Apr 2012 15:08:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP;
	4 Apr 2012 15:08:43 -0000
Received: from p5b2e3b97.dip.t-dialin.net ([91.46.59.151] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFRpB-0004Bd-1t; Wed, 04 Apr 2012 15:08:41 +0000
Message-ID: <4F7C63EE.6000703@canonical.com>
Date: Wed, 04 Apr 2012 17:08:30 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2804023548070912317=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2804023548070912317==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig797120CC2D607A79DD1B76DA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig797120CC2D607A79DD1B76DA
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Stefano,

quite a while back in time, you and Konrad had a discussion about some HV=
M setup
problems via libvirt. One part was graphics and the problem seemed to be =
that
when creating a new instance through xend for HVM, the use of vfb was wro=
ng. It
mostly does work but then also defines a vkbd which takes a long time in =
the
xenbus setup to finally fail.

Because this was not a really fatal problem it did take a long time to ac=
tually
get back to it. But now I had a look and found that libvirt indeed does u=
se the
vfb form for both the xen-xm and xen-sxpr formats (the latter being used =
to
create guests). The decision is made based on the xend version number in =
the HVM
case. Which would be wrong if I did understand your reply correctly.

I have been testing a patch to libvirt, which would not use a vfb definit=
ion
whenever HVM is used (regardless of xend version). And it does seem to wo=
rk (xm
list -l however has a vfb device definition, but the same happens when cr=
eating
the instance with a xm style config file that definitely has no vfb secti=
on in
it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So=
 I want
to make sure the solution for libvirt is correct for even the current Xen=
 version.

So in short, is this always correct?

if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
   do not define a vfb device
else /* PVM and xend version >=3D 3 */
   define a vfb device

Thanks,
Stefan


--------------enig797120CC2D607A79DD1B76DA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfGP3AAoJEOhnXe7L7s6jmVQQAKFN3BolPllZECJvY9wH31J8
NSIiZ9/Wgv9IqIC6beDX6Wo3kEVvRmY5P4ca9Gjl7YfnL6iUuUXDcv7nQy5Ap9JE
gQl2Nqsmbyt2GIonohzu2KEg8vkNjIbegRAVc36UF/fspE+ccMySftjhRdLKxKxe
brcrMc1BA0jdHvrQ1P1ksaTdRMDWQsgkEhysrhfQX7dITx6eonFAWUe+rwJSJvHo
8vXP2tPMxJlAmS76w/Oo4FemIM0NxV+Lqd8Hm5tU2H7NHTerXiDN/kPPuGOOJ03M
XgAXkylqiSNgiZh0QjdSaHakNzivugLbOFYWRKQwr4or8R/vsB++aQha+THWfExY
x7XTLIWLaQ91FJKt5JPtESuyTN3GxhTODmNTbbakq/ZAwZ39fYDMnEkvXbR6Tozg
smNb/CghTJCeU2UMVPf5hPt8rGBdIggxJd1By1a43SuWpmexoxTYlGy2w9KEkO/q
64Jfu3tVY02zwQoA61E+1f6HWQhRrhXHyJf+T6jI5VoIMBLmrgFsYW2cpKV27MUM
vCW9YZe4Buze+2VRfrqtLqaerpSKTvvoVFEMcXJSBrFS/ECgbMlTTVAi0YfcFrAA
4JjglurARjQ4xbUyur4bgcec1epR/U9/1IuhkS+368ecUOvuF8IOff6+Y1LULt/1
nRaPXPGAZ40hdMek4X9Y
=GaUG
-----END PGP SIGNATURE-----

--------------enig797120CC2D607A79DD1B76DA--


--===============2804023548070912317==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2804023548070912317==--


From xen-devel-bounces@lists.xen.org Wed Apr 04 15:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRpL-00017J-HR; Wed, 04 Apr 2012 15:08:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFRpK-00017D-6X
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:08:50 +0000
Received: from [85.158.143.35:20762] by server-1.bemta-4.messagelabs.com id
	3D/2E-20925-1046C7F4; Wed, 04 Apr 2012 15:08:49 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333552122!11033355!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21444 invoked from network); 4 Apr 2012 15:08:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP;
	4 Apr 2012 15:08:43 -0000
Received: from p5b2e3b97.dip.t-dialin.net ([91.46.59.151] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFRpB-0004Bd-1t; Wed, 04 Apr 2012 15:08:41 +0000
Message-ID: <4F7C63EE.6000703@canonical.com>
Date: Wed, 04 Apr 2012 17:08:30 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2804023548070912317=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2804023548070912317==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig797120CC2D607A79DD1B76DA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig797120CC2D607A79DD1B76DA
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Stefano,

quite a while back in time, you and Konrad had a discussion about some HV=
M setup
problems via libvirt. One part was graphics and the problem seemed to be =
that
when creating a new instance through xend for HVM, the use of vfb was wro=
ng. It
mostly does work but then also defines a vkbd which takes a long time in =
the
xenbus setup to finally fail.

Because this was not a really fatal problem it did take a long time to ac=
tually
get back to it. But now I had a look and found that libvirt indeed does u=
se the
vfb form for both the xen-xm and xen-sxpr formats (the latter being used =
to
create guests). The decision is made based on the xend version number in =
the HVM
case. Which would be wrong if I did understand your reply correctly.

I have been testing a patch to libvirt, which would not use a vfb definit=
ion
whenever HVM is used (regardless of xend version). And it does seem to wo=
rk (xm
list -l however has a vfb device definition, but the same happens when cr=
eating
the instance with a xm style config file that definitely has no vfb secti=
on in
it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So=
 I want
to make sure the solution for libvirt is correct for even the current Xen=
 version.

So in short, is this always correct?

if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
   do not define a vfb device
else /* PVM and xend version >=3D 3 */
   define a vfb device

Thanks,
Stefan


--------------enig797120CC2D607A79DD1B76DA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfGP3AAoJEOhnXe7L7s6jmVQQAKFN3BolPllZECJvY9wH31J8
NSIiZ9/Wgv9IqIC6beDX6Wo3kEVvRmY5P4ca9Gjl7YfnL6iUuUXDcv7nQy5Ap9JE
gQl2Nqsmbyt2GIonohzu2KEg8vkNjIbegRAVc36UF/fspE+ccMySftjhRdLKxKxe
brcrMc1BA0jdHvrQ1P1ksaTdRMDWQsgkEhysrhfQX7dITx6eonFAWUe+rwJSJvHo
8vXP2tPMxJlAmS76w/Oo4FemIM0NxV+Lqd8Hm5tU2H7NHTerXiDN/kPPuGOOJ03M
XgAXkylqiSNgiZh0QjdSaHakNzivugLbOFYWRKQwr4or8R/vsB++aQha+THWfExY
x7XTLIWLaQ91FJKt5JPtESuyTN3GxhTODmNTbbakq/ZAwZ39fYDMnEkvXbR6Tozg
smNb/CghTJCeU2UMVPf5hPt8rGBdIggxJd1By1a43SuWpmexoxTYlGy2w9KEkO/q
64Jfu3tVY02zwQoA61E+1f6HWQhRrhXHyJf+T6jI5VoIMBLmrgFsYW2cpKV27MUM
vCW9YZe4Buze+2VRfrqtLqaerpSKTvvoVFEMcXJSBrFS/ECgbMlTTVAi0YfcFrAA
4JjglurARjQ4xbUyur4bgcec1epR/U9/1IuhkS+368ecUOvuF8IOff6+Y1LULt/1
nRaPXPGAZ40hdMek4X9Y
=GaUG
-----END PGP SIGNATURE-----

--------------enig797120CC2D607A79DD1B76DA--


--===============2804023548070912317==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2804023548070912317==--


From xen-devel-bounces@lists.xen.org Wed Apr 04 15:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRqi-0001F2-0S; Wed, 04 Apr 2012 15:10:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRqg-0001Eu-GF
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:10:14 +0000
Received: from [85.158.143.35:38166] by server-1.bemta-4.messagelabs.com id
	76/21-20925-5546C7F4; Wed, 04 Apr 2012 15:10:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333552212!14722575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21006 invoked from network); 4 Apr 2012 15:10:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:10:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:09:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:09:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRq7-0008Hq-R5; Wed, 04 Apr 2012 15:09:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRq7-0005Dx-Q5;
	Wed, 04 Apr 2012 16:09:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.25651.790891.736712@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:09:39 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpP_Oqu9OTXCFmMKbbj1V5if9BWKd36ikEL3hghG6R7qew@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
	<CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
	<20348.8413.77858.455557@mariner.uk.xensource.com>
	<CAEwRVpP_Oqu9OTXCFmMKbbj1V5if9BWKd36ikEL3hghG6R7qew@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"=
):
> On Wed, Apr 4, 2012 at 6:22 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> w=
rote:
> > I think if you fix the coding style you will avoid the bug in your
> > email program. =A0Alternatively, include the patch as an attachment too.
> =

> Yes, I know gmail wrapped it as it is longer than 80 in length.
> Attached is the fix patch.

Thanks, applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRqi-0001F2-0S; Wed, 04 Apr 2012 15:10:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRqg-0001Eu-GF
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:10:14 +0000
Received: from [85.158.143.35:38166] by server-1.bemta-4.messagelabs.com id
	76/21-20925-5546C7F4; Wed, 04 Apr 2012 15:10:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333552212!14722575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21006 invoked from network); 4 Apr 2012 15:10:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:10:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:09:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:09:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRq7-0008Hq-R5; Wed, 04 Apr 2012 15:09:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRq7-0005Dx-Q5;
	Wed, 04 Apr 2012 16:09:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.25651.790891.736712@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:09:39 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpP_Oqu9OTXCFmMKbbj1V5if9BWKd36ikEL3hghG6R7qew@mail.gmail.com>
References: <4F55F15F02000078000769AC@nat28.tlf.novell.com>
	<4F55EF2D.7010302@citrix.com>
	<20120324172757.GA29504@phenom.dumpdata.com>
	<20347.4694.131348.751694@mariner.uk.xensource.com>
	<CAEwRVpM+qed-3JZrhev3eFWAprvwj1umzwSSM2N7M9STcSvqJg@mail.gmail.com>
	<20347.11328.121224.686159@mariner.uk.xensource.com>
	<CAEwRVpNqQXSYRJ-UeuQy98XqxeUs+btrvPCfHt==2eHSGLYPmg@mail.gmail.com>
	<CAEwRVpNdsYH2Xd9ZNP3XXB8PPpNsY653qHmMmE5HXeSPZHB-gA@mail.gmail.com>
	<20348.8413.77858.455557@mariner.uk.xensource.com>
	<CAEwRVpP_Oqu9OTXCFmMKbbj1V5if9BWKd36ikEL3hghG6R7qew@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport requests for 4.x-testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"=
):
> On Wed, Apr 4, 2012 at 6:22 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> w=
rote:
> > I think if you fix the coding style you will avoid the bug in your
> > email program. =A0Alternatively, include the patch as an attachment too.
> =

> Yes, I know gmail wrapped it as it is longer than 80 in length.
> Attached is the fix patch.

Thanks, applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:10:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:10:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRqz-0001GT-Cq; Wed, 04 Apr 2012 15:10:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRqy-0001GE-3T
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:10:32 +0000
Received: from [85.158.143.99:19296] by server-3.bemta-4.messagelabs.com id
	2D/95-05853-7646C7F4; Wed, 04 Apr 2012 15:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1333552225!22339610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27109 invoked from network); 4 Apr 2012 15:10:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:10:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:10:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRqr-0008I8-DK; Wed, 04 Apr 2012 15:10:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRqr-0005FW-Cb;
	Wed, 04 Apr 2012 16:10:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.25697.373889.799770@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:10:25 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <d00faeaf21dd280500d2.1333533070@cosworth.uk.xensource.com>
References: <d00faeaf21dd280500d2.1333533070@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fixup error handling in
	libxl_send_trigger
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: fixup error handling in libxl_send_trigger"):
> libxl: fixup error handling in libxl_send_trigger

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:10:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:10:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRqz-0001GT-Cq; Wed, 04 Apr 2012 15:10:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRqy-0001GE-3T
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:10:32 +0000
Received: from [85.158.143.99:19296] by server-3.bemta-4.messagelabs.com id
	2D/95-05853-7646C7F4; Wed, 04 Apr 2012 15:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1333552225!22339610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27109 invoked from network); 4 Apr 2012 15:10:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:10:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:10:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRqr-0008I8-DK; Wed, 04 Apr 2012 15:10:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRqr-0005FW-Cb;
	Wed, 04 Apr 2012 16:10:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.25697.373889.799770@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:10:25 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <d00faeaf21dd280500d2.1333533070@cosworth.uk.xensource.com>
References: <d00faeaf21dd280500d2.1333533070@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fixup error handling in
	libxl_send_trigger
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: fixup error handling in libxl_send_trigger"):
> libxl: fixup error handling in libxl_send_trigger

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:16:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRvz-0001j8-RP; Wed, 04 Apr 2012 15:15:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRvy-0001iv-HT
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:15:42 +0000
Received: from [85.158.143.35:31427] by server-1.bemta-4.messagelabs.com id
	E7/AC-20925-D956C7F4; Wed, 04 Apr 2012 15:15:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333552540!14723629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9544 invoked from network); 4 Apr 2012 15:15:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:15:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:15:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRvv-0008PT-W9; Wed, 04 Apr 2012 15:15:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRvv-0001UZ-UE;
	Wed, 04 Apr 2012 16:15:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.26011.879255.713967@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:15:39 +0100
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6fGxVavTRzzmZhvJ8Jwp=L-YsKkLEFoY+-YC830j-Q=g@mail.gmail.com>
References: <patchbomb.1329928802@debian.localdomain>
	<04c74f6b97ad74ecd322.1329928804@debian.localdomain>
	<20317.55113.339973.333351@mariner.uk.xensource.com>
	<CAPLaKK6fGxVavTRzzmZhvJ8Jwp=L-YsKkLEFoY+-YC830j-Q=g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] autoconf: check for as86, ld86,
	bcc and iasl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH 2 of 3] autoconf: check for as86, ld8=
6, bcc and iasl"):
> 2012/3/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Roger Pau Monne writes ("[PATCH 2 of 3] autoconf: check for as86, ld86,=
 bcc and iasl"):
> >> autoconf: check for as86, ld86, bcc and iasl
> >>
> >> Check for this tools, and set the proper paths on config/Tool.mk.
> >
> > This looks plausible.
> >
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> =

> Could this be applied before the 4.2 freeze?

Yes, I have applied it now.  I had acked it, but at that time it
seemed that you were going to repost the series because of other
things in it, and I didn't apply it on its own.  But in fact it looks
fine by itself.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:16:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRvz-0001j8-RP; Wed, 04 Apr 2012 15:15:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRvy-0001iv-HT
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:15:42 +0000
Received: from [85.158.143.35:31427] by server-1.bemta-4.messagelabs.com id
	E7/AC-20925-D956C7F4; Wed, 04 Apr 2012 15:15:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333552540!14723629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9544 invoked from network); 4 Apr 2012 15:15:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:15:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:15:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRvv-0008PT-W9; Wed, 04 Apr 2012 15:15:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRvv-0001UZ-UE;
	Wed, 04 Apr 2012 16:15:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.26011.879255.713967@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:15:39 +0100
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6fGxVavTRzzmZhvJ8Jwp=L-YsKkLEFoY+-YC830j-Q=g@mail.gmail.com>
References: <patchbomb.1329928802@debian.localdomain>
	<04c74f6b97ad74ecd322.1329928804@debian.localdomain>
	<20317.55113.339973.333351@mariner.uk.xensource.com>
	<CAPLaKK6fGxVavTRzzmZhvJ8Jwp=L-YsKkLEFoY+-YC830j-Q=g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] autoconf: check for as86, ld86,
	bcc and iasl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH 2 of 3] autoconf: check for as86, ld8=
6, bcc and iasl"):
> 2012/3/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Roger Pau Monne writes ("[PATCH 2 of 3] autoconf: check for as86, ld86,=
 bcc and iasl"):
> >> autoconf: check for as86, ld86, bcc and iasl
> >>
> >> Check for this tools, and set the proper paths on config/Tool.mk.
> >
> > This looks plausible.
> >
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> =

> Could this be applied before the 4.2 freeze?

Yes, I have applied it now.  I had acked it, but at that time it
seemed that you were going to repost the series because of other
things in it, and I didn't apply it on its own.  But in fact it looks
fine by itself.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:16:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRwX-0001oU-DB; Wed, 04 Apr 2012 15:16:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRwW-0001oA-Fr
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:16:16 +0000
Received: from [193.109.254.147:61846] by server-4.bemta-14.messagelabs.com id
	E2/BE-11570-FB56C7F4; Wed, 04 Apr 2012 15:16:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333552575!3249173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25851 invoked from network); 4 Apr 2012 15:16:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:16:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:16:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRwU-0008Pz-NZ; Wed, 04 Apr 2012 15:16:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRwU-0001Un-Mi;
	Wed, 04 Apr 2012 16:16:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.26046.686582.18393@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:16:14 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120403173224.GA22140@aepfle.de>
References: <20120403173224.GA22140@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386"):
> configure will generate incorrect CFLAGS which will lead to compile
> errors due to unknown gcc options, iff CFLAGS was already in the
> environment during configure invocation.

Don't do that then.

In general, CFLAGS is not a variable you can safely set in your
environment when invoking a nonconsenting build system.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:16:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRwX-0001oU-DB; Wed, 04 Apr 2012 15:16:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRwW-0001oA-Fr
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:16:16 +0000
Received: from [193.109.254.147:61846] by server-4.bemta-14.messagelabs.com id
	E2/BE-11570-FB56C7F4; Wed, 04 Apr 2012 15:16:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333552575!3249173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25851 invoked from network); 4 Apr 2012 15:16:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:16:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:16:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRwU-0008Pz-NZ; Wed, 04 Apr 2012 15:16:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRwU-0001Un-Mi;
	Wed, 04 Apr 2012 16:16:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.26046.686582.18393@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:16:14 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120403173224.GA22140@aepfle.de>
References: <20120403173224.GA22140@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386"):
> configure will generate incorrect CFLAGS which will lead to compile
> errors due to unknown gcc options, iff CFLAGS was already in the
> environment during configure invocation.

Don't do that then.

In general, CFLAGS is not a variable you can safely set in your
environment when invoking a nonconsenting build system.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:18:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRyF-00022C-TZ; Wed, 04 Apr 2012 15:18:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRyE-00021z-Qb
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:18:03 +0000
Received: from [85.158.143.35:49899] by server-1.bemta-4.messagelabs.com id
	60/51-20925-A266C7F4; Wed, 04 Apr 2012 15:18:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333552681!7449641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22786 invoked from network); 4 Apr 2012 15:18:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:18:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:18:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRyC-0008V0-4z; Wed, 04 Apr 2012 15:18:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRyC-0001V6-49;
	Wed, 04 Apr 2012 16:18:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.26152.109398.185901@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:18:00 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <30cc13e25e015fa0a047.1333477722@kodo2>
References: <patchbomb.1333477720@kodo2>
	<30cc13e25e015fa0a047.1333477722@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between
 "filename" and "data source"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between "filename" and "data source""):
> Many places in xl there's a variable or element named "filename" which
> does not contain a filename, but the source of the data for reporting
> purposes.  Worse, there are variables which are sometimes actually
> used or interpreted as a filename depending on what other variables
> are set.  This makes it difficult to tell when a string is purely
> cosmetic, and when another bit of code may actually attempt to call
> "open" with the string.
> 
> This patch makes a consistent distinction between "filename" (which
> always refers to the name of an actual file, and may be interpreted as
> such at some point) and "source" (which may be a filename, or may be
> another data source such as a migration stream or saved data).

I think this is a worthy goal.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:18:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFRyF-00022C-TZ; Wed, 04 Apr 2012 15:18:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFRyE-00021z-Qb
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:18:03 +0000
Received: from [85.158.143.35:49899] by server-1.bemta-4.messagelabs.com id
	60/51-20925-A266C7F4; Wed, 04 Apr 2012 15:18:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333552681!7449641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22786 invoked from network); 4 Apr 2012 15:18:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11773583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:18:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:18:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFRyC-0008V0-4z; Wed, 04 Apr 2012 15:18:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFRyC-0001V6-49;
	Wed, 04 Apr 2012 16:18:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.26152.109398.185901@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:18:00 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <30cc13e25e015fa0a047.1333477722@kodo2>
References: <patchbomb.1333477720@kodo2>
	<30cc13e25e015fa0a047.1333477722@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between
 "filename" and "data source"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between "filename" and "data source""):
> Many places in xl there's a variable or element named "filename" which
> does not contain a filename, but the source of the data for reporting
> purposes.  Worse, there are variables which are sometimes actually
> used or interpreted as a filename depending on what other variables
> are set.  This makes it difficult to tell when a string is purely
> cosmetic, and when another bit of code may actually attempt to call
> "open" with the string.
> 
> This patch makes a consistent distinction between "filename" (which
> always refers to the name of an actual file, and may be interpreted as
> such at some point) and "source" (which may be a filename, or may be
> another data source such as a migration stream or saved data).

I think this is a worthy goal.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:34:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSE0-00034N-Pj; Wed, 04 Apr 2012 15:34:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFSDy-00034G-Vr
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:34:19 +0000
Received: from [193.109.254.147:18649] by server-5.bemta-14.messagelabs.com id
	95/25-30733-AF96C7F4; Wed, 04 Apr 2012 15:34:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333553657!3252038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17879 invoked from network); 4 Apr 2012 15:34:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:34:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11774077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:34:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:34:17 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFSDw-0000dC-Ob;
	Wed, 04 Apr 2012 15:34:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFSDw-00043h-KJ;
	Wed, 04 Apr 2012 16:34:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12561-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 16:34:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12561: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12561 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12561/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested

version targeted for testing:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:34:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSE0-00034N-Pj; Wed, 04 Apr 2012 15:34:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFSDy-00034G-Vr
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:34:19 +0000
Received: from [193.109.254.147:18649] by server-5.bemta-14.messagelabs.com id
	95/25-30733-AF96C7F4; Wed, 04 Apr 2012 15:34:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333553657!3252038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17879 invoked from network); 4 Apr 2012 15:34:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:34:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11774077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:34:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:34:17 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFSDw-0000dC-Ob;
	Wed, 04 Apr 2012 15:34:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFSDw-00043h-KJ;
	Wed, 04 Apr 2012 16:34:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12561-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 16:34:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12561: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12561 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12561/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail baseline untested

version targeted for testing:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSK7-0003Y8-90; Wed, 04 Apr 2012 15:40:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SFSK5-0003Y1-LH
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:40:37 +0000
Received: from [85.158.139.83:6100] by server-11.bemta-5.messagelabs.com id
	A1/77-12959-47B6C7F4; Wed, 04 Apr 2012 15:40:36 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333554034!19790653!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17193 invoked from network); 4 Apr 2012 15:40:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:40:36 -0000
Received: by iadj38 with SMTP id j38so647661iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Apr 2012 08:40:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=bo/U1Ehafj15DAsgyCDt+lzlGsE7kbEWcU/8zh4g7Ds=;
	b=XntuIrh3wbg71QE0yTgXlxnjUCwMsnChBC67pSOgQrYJ4BXv7uZSjqgK7L024Jh5EV
	zVoXCa7Fae7ZOz8L6JZHIIWHZVzQ8U3kBWYLOKEhp9zmpO1WP23w68f1ftTETkc93AjT
	AJuMAt8FWA7Q/36Qd4YjimLKMPcUau9zLdXrcW+iCiYpGqEz3HI8uQsPYYZqSaD9fdab
	LKKQO/g7Fxlx7joTUxU38i/W8Ce07pKdhTXZxdvb+4NYphJ48aqWO5sXII39BYk5hvP5
	lF7XJzW7BKHJmudBHpgYZM1m5SZYxb5jzuL5mg38FJElPwfpiqzlYaqQOUR7mQSk8FeA
	+lEw==
MIME-Version: 1.0
Received: by 10.43.52.10 with SMTP id vk10mr10266924icb.25.1333554034372; Wed,
	04 Apr 2012 08:40:34 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 4 Apr 2012 08:40:34 -0700 (PDT)
In-Reply-To: <20348.26046.686582.18393@mariner.uk.xensource.com>
References: <20120403173224.GA22140@aepfle.de>
	<20348.26046.686582.18393@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:40:34 +0100
Message-ID: <CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQmhchDMSE/DprCr9AGz2e1QTt2WEUo/f0j4Zh2gtDE7pV5POFiQ5LP7QK4E01Dz/7j5LwfU
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 4 April 2012 16:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Olaf Hering writes ("[Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386"):
>> configure will generate incorrect CFLAGS which will lead to compile
>> errors due to unknown gcc options, iff CFLAGS was already in the
>> environment during configure invocation.
>
> Don't do that then.
>
> In general, CFLAGS is not a variable you can safely set in your
> environment when invoking a nonconsenting build system.

Yes. You probably wanted configure's --extra-cflags option.
However that doesn't mean the code in configure at the moment
is actually right...

Having looked at configure I'm pretty sure what we want here is
  QEMU_CFLAGS="-march=i486 $QEMU_CFLAGS"

because we're only doing this for the benefit of a particular bit
of code in hw/vhost.c and so QEMU_CFLAGS is sufficient. Also this
brings it into line with other places where we add a -march flag,
which use QEMU_CFLAGS, not CFLAGS.

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSK7-0003Y8-90; Wed, 04 Apr 2012 15:40:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SFSK5-0003Y1-LH
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 15:40:37 +0000
Received: from [85.158.139.83:6100] by server-11.bemta-5.messagelabs.com id
	A1/77-12959-47B6C7F4; Wed, 04 Apr 2012 15:40:36 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333554034!19790653!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17193 invoked from network); 4 Apr 2012 15:40:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:40:36 -0000
Received: by iadj38 with SMTP id j38so647661iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Apr 2012 08:40:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=bo/U1Ehafj15DAsgyCDt+lzlGsE7kbEWcU/8zh4g7Ds=;
	b=XntuIrh3wbg71QE0yTgXlxnjUCwMsnChBC67pSOgQrYJ4BXv7uZSjqgK7L024Jh5EV
	zVoXCa7Fae7ZOz8L6JZHIIWHZVzQ8U3kBWYLOKEhp9zmpO1WP23w68f1ftTETkc93AjT
	AJuMAt8FWA7Q/36Qd4YjimLKMPcUau9zLdXrcW+iCiYpGqEz3HI8uQsPYYZqSaD9fdab
	LKKQO/g7Fxlx7joTUxU38i/W8Ce07pKdhTXZxdvb+4NYphJ48aqWO5sXII39BYk5hvP5
	lF7XJzW7BKHJmudBHpgYZM1m5SZYxb5jzuL5mg38FJElPwfpiqzlYaqQOUR7mQSk8FeA
	+lEw==
MIME-Version: 1.0
Received: by 10.43.52.10 with SMTP id vk10mr10266924icb.25.1333554034372; Wed,
	04 Apr 2012 08:40:34 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 4 Apr 2012 08:40:34 -0700 (PDT)
In-Reply-To: <20348.26046.686582.18393@mariner.uk.xensource.com>
References: <20120403173224.GA22140@aepfle.de>
	<20348.26046.686582.18393@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:40:34 +0100
Message-ID: <CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQmhchDMSE/DprCr9AGz2e1QTt2WEUo/f0j4Zh2gtDE7pV5POFiQ5LP7QK4E01Dz/7j5LwfU
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 4 April 2012 16:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Olaf Hering writes ("[Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386"):
>> configure will generate incorrect CFLAGS which will lead to compile
>> errors due to unknown gcc options, iff CFLAGS was already in the
>> environment during configure invocation.
>
> Don't do that then.
>
> In general, CFLAGS is not a variable you can safely set in your
> environment when invoking a nonconsenting build system.

Yes. You probably wanted configure's --extra-cflags option.
However that doesn't mean the code in configure at the moment
is actually right...

Having looked at configure I'm pretty sure what we want here is
  QEMU_CFLAGS="-march=i486 $QEMU_CFLAGS"

because we're only doing this for the benefit of a particular bit
of code in hw/vhost.c and so QEMU_CFLAGS is sufficient. Also this
brings it into line with other places where we add a -march flag,
which use QEMU_CFLAGS, not CFLAGS.

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:44:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSNn-0003sN-IH; Wed, 04 Apr 2012 15:44:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SFSNm-0003sB-BK
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:44:26 +0000
Received: from [85.158.139.83:33765] by server-11.bemta-5.messagelabs.com id
	5B/52-12959-95C6C7F4; Wed, 04 Apr 2012 15:44:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333554263!22519435!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTYzNjc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5914 invoked from network); 4 Apr 2012 15:44:24 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-182.messagelabs.com with SMTP;
	4 Apr 2012 15:44:24 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 2053A76C065;
	Wed,  4 Apr 2012 08:44:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=iG88P10LfLw/kLL0l8PPoW
	1x143Q4lMODOPoRqQcXCwoje80UNLFpG1u9rpA7Im2JkZXiupu7F9+OEqz4H59dA
	CJEd06/DD5Z1e5hnzaIG6Fx3BYjlXY4x3xU5zO5a8G/nvKBbeqWa+7OCzLrpIvxp
	WXX7iTAPxY0VQBU+2XY5g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=t4YlYsrKYswd
	x7vS/GzDNvoWWfY=; b=RMko8xGQri2P/swvxorDEWLJNagVy/+A5TO35OgQyOdB
	LMG/ZUEs/RmQG3U5PRm3fVx1IwbPOaxoXqzMNXK56DlXcDFJzkf7LktKiD8E3+Zx
	gC0B2Z4ZMIMEhOdY3eQ6xO9mT7hBiK3Odet3XdDn0ULpS/wuh9T3B9rxMeMAFXk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id CA9EF76C058; 
	Wed,  4 Apr 2012 08:44:18 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6a3e651ee3b6123eca9cc7fce9999547b8aa61ec
Message-Id: <6a3e651ee3b6123eca9c.1333554512@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 04 Apr 2012 11:48:32 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mem sharing: Take care of domain reference
 for shared pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)


Making a page sharable removes it from the previous owner's list. Making it
private adds it. These actions are similar to freeing or allocating a page.
Except that they were not minding the domain reference that is taken/dropped
when the first/last page is allocated/freed.

Without fixing this, a domain might remain zombie when destroyed if all its
pages are shared.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 48763a117b2a -r 6a3e651ee3b6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -401,6 +401,7 @@ static int page_make_sharable(struct dom
                        struct page_info *page, 
                        int expected_refcnt)
 {
+    int drop_dom_ref;
     spin_lock(&d->page_alloc_lock);
 
     /* Change page type and count atomically */
@@ -430,8 +431,12 @@ static int page_make_sharable(struct dom
 
     page_set_owner(page, dom_cow);
     d->tot_pages--;
+    drop_dom_ref = (d->tot_pages == 0);
     page_list_del(page, &d->page_list);
     spin_unlock(&d->page_alloc_lock);
+
+    if ( drop_dom_ref )
+        put_domain(d);
     return 0;
 }
 
@@ -466,7 +471,8 @@ static int page_make_private(struct doma
     ASSERT(page_get_owner(page) == dom_cow);
     page_set_owner(page, d);
 
-    d->tot_pages++;
+    if ( d->tot_pages++ == 0 )
+        get_domain(d);
     page_list_add_tail(page, &d->page_list);
     spin_unlock(&d->page_alloc_lock);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:44:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSNn-0003sN-IH; Wed, 04 Apr 2012 15:44:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SFSNm-0003sB-BK
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:44:26 +0000
Received: from [85.158.139.83:33765] by server-11.bemta-5.messagelabs.com id
	5B/52-12959-95C6C7F4; Wed, 04 Apr 2012 15:44:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333554263!22519435!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTYzNjc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5914 invoked from network); 4 Apr 2012 15:44:24 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-182.messagelabs.com with SMTP;
	4 Apr 2012 15:44:24 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 2053A76C065;
	Wed,  4 Apr 2012 08:44:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=iG88P10LfLw/kLL0l8PPoW
	1x143Q4lMODOPoRqQcXCwoje80UNLFpG1u9rpA7Im2JkZXiupu7F9+OEqz4H59dA
	CJEd06/DD5Z1e5hnzaIG6Fx3BYjlXY4x3xU5zO5a8G/nvKBbeqWa+7OCzLrpIvxp
	WXX7iTAPxY0VQBU+2XY5g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=t4YlYsrKYswd
	x7vS/GzDNvoWWfY=; b=RMko8xGQri2P/swvxorDEWLJNagVy/+A5TO35OgQyOdB
	LMG/ZUEs/RmQG3U5PRm3fVx1IwbPOaxoXqzMNXK56DlXcDFJzkf7LktKiD8E3+Zx
	gC0B2Z4ZMIMEhOdY3eQ6xO9mT7hBiK3Odet3XdDn0ULpS/wuh9T3B9rxMeMAFXk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id CA9EF76C058; 
	Wed,  4 Apr 2012 08:44:18 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6a3e651ee3b6123eca9cc7fce9999547b8aa61ec
Message-Id: <6a3e651ee3b6123eca9c.1333554512@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 04 Apr 2012 11:48:32 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mem sharing: Take care of domain reference
 for shared pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)


Making a page sharable removes it from the previous owner's list. Making it
private adds it. These actions are similar to freeing or allocating a page.
Except that they were not minding the domain reference that is taken/dropped
when the first/last page is allocated/freed.

Without fixing this, a domain might remain zombie when destroyed if all its
pages are shared.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 48763a117b2a -r 6a3e651ee3b6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -401,6 +401,7 @@ static int page_make_sharable(struct dom
                        struct page_info *page, 
                        int expected_refcnt)
 {
+    int drop_dom_ref;
     spin_lock(&d->page_alloc_lock);
 
     /* Change page type and count atomically */
@@ -430,8 +431,12 @@ static int page_make_sharable(struct dom
 
     page_set_owner(page, dom_cow);
     d->tot_pages--;
+    drop_dom_ref = (d->tot_pages == 0);
     page_list_del(page, &d->page_list);
     spin_unlock(&d->page_alloc_lock);
+
+    if ( drop_dom_ref )
+        put_domain(d);
     return 0;
 }
 
@@ -466,7 +471,8 @@ static int page_make_private(struct doma
     ASSERT(page_get_owner(page) == dom_cow);
     page_set_owner(page, d);
 
-    d->tot_pages++;
+    if ( d->tot_pages++ == 0 )
+        get_domain(d);
     page_list_add_tail(page, &d->page_list);
     spin_unlock(&d->page_alloc_lock);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:50:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSTe-0004DJ-Bs; Wed, 04 Apr 2012 15:50:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFSTc-0004DB-Kb
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:50:28 +0000
Received: from [85.158.139.83:38859] by server-6.bemta-5.messagelabs.com id
	39/5C-13222-3CD6C7F4; Wed, 04 Apr 2012 15:50:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333554627!22520436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27261 invoked from network); 4 Apr 2012 15:50:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:50:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11774481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:50:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:50:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFSQ3-0000wZ-B6	for xen-devel@lists.xen.org;
	Wed, 04 Apr 2012 15:46:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFSQ3-0001XP-AA	for
	xen-devel@lists.xen.org; Wed, 04 Apr 2012 16:46:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.27879.297617.171564@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:46:47 +0100
To: xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

During some discussions and handwaving, including discussions with
some experts on the Xenserver/XCP storage architecture, we came up
with what we think might be a plausible proposal for an architecture
for communication between toolstack and driver domain, for storage at
least.

I offered to write it up.  The abstract proposal is as I understand
the consensus from our conversation.  The concrete protocol is my own
invention.

Please comments.  After a round of review here we should consider
whether some of the assumptions need review from the communities
involved in "other" backends (particularly, the BSDs).

(FAOD the implementation of something like this is not 4.3 material,
but it may inform some API decisions etc. we take in 4.2.)

Ian.


Components

 toolstack

 guest
    Might be the toolstack domain, or an (intended) guest vm.

 driver domain
    Responsible for providing the disk service to guests.
    Consists, internally, of (at least):
       control plane
       backend
    but we avoid exposing this internal implementation detail.

    We permit different driver domains on a single host, serving
    different guests or the same guests.  

    The toolstack is expected to know the domid of the driver domain.

 driver domain kind
    We permit different "kinds" of driver domain, perhaps implemented
    by completely different code, which support different facilities.

    Each driver domain kind needs to document what targets (see
    below) are valid and how they are specified, and what preparatory
    steps may need to be taken eg at system boot.

    Driver domain kinds do not have a formal presence in the API.

Objects

 target
     A kind of name.

     Combination of a physical location and data format plus all other
     information needed by the underlying mechanisms, or relating to
     the data format, needed to access it.

     These names are assigned by the driver domain kind; the names may
     be an open class; no facility provided via this API to enumerate
     these.

     Syntactically, these are key/value pairs, mapping short string
     keys to shortish string values, suitable for storage in a
     xenstore directory.

 vdi
     This host's intent to access a specific target.
     Non-persistent, created on request by toolstack, enumerable.
     Possible states: inactive/active.
     Abstract operations: prepare, activate, deactivate, unprepare.

     (We call the "create" operation for this object "prepare" to
     avoid confusion with other kinds of "create".)

     The toolstack promises that no two vdis for the same target
     will simultaneously be active, even if the two vdis are on
     different hosts.

 vbd
     Provision of a facility for a guest to access a particular target
     via a particular vdi.  There may be zero or more of these at any
     point for a particular vdi.

     Non-persistent, created on request by toolstack, enumerable.
     Abstract operations: plug, unplug.

     (We call the "create" operation for this object "plug" to avoid
     confusion with other kinds of "create".)

     vbds may be created/destroyed, and the underlying vdi
     activated/deactivated, in any other.  However IO is only possible
     to a vbd when the corresponding vdi is active.  The reason for
     requiring activation as a separate step is to allow as much of
     the setup for an incoming migration domain's storage to be done
     before committing to the migration and entering the "domain is
     down" stage, during which access is switched from the old to the
     new host.

     We will consider here the case of a vbd which provides
     service as a Xen vbd backend.  Other cases (eg, the driver domain
     is the same as the toolstack domain and the vbd provides a block
     device in the toolstack domain) can be regarded as
     optimisations/shortcuts.

Concrete protocol

 The toolstack gives instructions to the driver domain, and receives
 results, via xenstore, in the path:
   /local/domain/<driverdomid>/backendctrl/vdi
 Both driver domain and toolstack have write access to the whole of
 this area.

 Each vdi which has been requested and/or exists, corresponds to a
 path .../backendctrl/vdi/<vdi> where <vdi> is a string (of
 alphanumerics, hyphens and underscores) chosen by the toolstack.
 Inside this, there are the following nodes:

 /local/domain/<driverdomid>/backendctrl/vdi/<vdi>/
   state       The current state.  Values are "inactive", "active",
               or ENOENT meaning the vdi does not exist.
               Set by the driver domain in response to requests.

   request     Operation requested by the toolstack and currently
               being performed.  Created by the toolstack, but may
               then not be modified by the toolstack.  Deleted
               by the driver domain when the operation has completed.

               The values of "request" are:
                 prepare
                 activate
                 deactivate
                 unprepare
                 plug <vbd>
                 unplug <vbd>
               <vbd> is an id chosen by the toolstack like <vdi>

   result      errno value (in decimal, Xen error number) best
               describing the results of the most recently completed
               operation; 0 means success.  Created or set by the
               driver domain in the same transaction as it deletes
               request.  The toolstack may delete this.

   result_msg  Optional UTF-8 string explaining any error; does not
               exist when result is "0".  Created or deleted by the
               driver domain whenever the driver domain sets result.
               The toolstack may delete this.

   t/*         The target name.  Must be written by the toolstack.
               But may not be removed or changed while either of
               state or request exist.

   vbd/<vbd>/state
               The state of a vbd, "ok" or ENOENT.
               Set or deleted by the driver domain in response to
               requests.

   vbd/<vbd>/frontend
               The frontend path (complete path in xenstore) which the
               xen vbd should be servicing.  Set by the toolstack
               with the plug request and not modified until after
               completion of unplug.

   vbd/<vbd>/backend
               The backend path (complete path in xenstore) which the
               driver domain has chosen for the vbd.  Set by the
               driver domain in response to a plug request.

   vbd/<vbd>/b-copy/*
               The driver domain may request, in response to plug,
               that the toolstack copy these values to the specified
               backend directory, in the same transaction as it
               creates the frontend.  Set by the driver domain in
               response to a plug request; may be deleted by the
               toolstack.  DEPRECATED, see below.

The operations:

 prepare
        Creates a vdi from a target.
        Preconditions:
            state ENOENT
            request ENOENT
        Request (xenstore writes by toolstack):
            request = "prepare"
            t/* as appropriate
        Results on success (xenstore writes by driver domain):
            request ENOENT    } applies to success from all operations,
            result = "0"      }  will not be restated below
            state = "inactive"
        Results on error (applies to all operations):  }
            request ENOENT                             }  applies
            result = some decimal integer errno value  }   to all
            result_msg = ENOENT or a string            }    failures

 activate
        Preconditions:
            state = "inactive"
            request ENOENT
        Request:
            request = "activate"
        Results on success:
            state = "active"

 deactivate
        Preconditions:
            state = "active"
            request ENOENT
        Request:
            request = "deactivate"
        Results on success:
            state = "inactive"

 unprepare
        Preconditions:
            state != ENOENT
            request ENOENT
        Request:
            request = "unprepare"
        Results on success:
            state = ENOENT

 removal, modification, etc. of an unprepared vdi:
        Preconditions:
            state ENOENT
            request ENOENT
        Request:
            any changes to <vdi> directory which do
             not create "state" or "request"
        Results:
            ignored - no response from driver domain

 plug <vbd>
        Preconditions:
            state ENOENT
            request ENOENT
            vbd/<vbd>/state ENOENT
            <frontend> ENOENT
        Request:
            request = "plug <vbd>"
            vbd/<vbd>/frontend = <frontend> ("/local/domain/<guest>/...")
        Results on success:
            vbd/<vbd>/state = "ok"
            vbd/<vbd>/backend = <rel-backend>
                (<rel-backend> is the backend path relative to the
                 driver domain's home directory in xenstore)
            vbd/<vbd>/b-copy/*  may be created    } at least one of these
            <backend>/*  may come into existence  }  must happen
        Next step (xenstore write) by toolstack:
            <frontend>  created and populated, specifically
            <frontend>/backend = <backend>
                ("/local/domain/<driverdomid>/<rel-backend>")
            <backend>    created if necessary
            <backend>/*  copied from  vbd/<vbd>/b-copy/*  if any
            <backend>/frontend = <frontend>  unless already set

 unplug <vbd>
        Preconditions:
            state ENOENT
            request ENOENT
            vbd/<vbd>/state "ok"
        Request:
            request = "unplug <vbd>"
            <frontend> ENOENT
        Results on success:
            vbd/<vbd>/state ENOENT
            <backend> ENOENT

 The toolstack and driver domains should not store state of their own,
 not required for these communication purposes, in the backendctrl/
 directory in xenstore.  If the driver domain wishes to make records
 for its own use in xenstore, it should do so in a different directory
 of its choice (eg, /local/domain/<driverdomid>/private/<something>.


Notes regarding driver domains whose block backend implementation is
controlled from the actual xenstore backend directory:

 The b-copy/* feature exists for compatibility with some of these.  If
 such a backend cannot cope with the backend directory coming into
 existence before the corresponding frontend directory, then it is
 necessary to create and populate the backend in the same xenstore
 transaction as the creation of the frontend.  However, such backends
 should be fixed; the b-copy/* feature is deprecated and will be
 withdrawn at some point.

 Note that a vbd may be created with the vdi inactive.  In this case
 the frontend and backend directories will exist, but the information
 needed to start up the backend properly may be lacking until the vdi
 is activated.  For example, if the existence of a suitable block
 device in the driver domain depends on vdi activation, the block
 device id cannot be made known to the backend until after the backend
 directory has already been created and perhaps has existed for some
 time.  It is believed that existing backends cope with this, because
 they use a "hotplug script" approach - where the backend directory is
 created without specifying the device node, and this backend directory
 creation causes the invocation of machinery which establishes the
 device node, which is subsequently written to xenstore.


Question

 What about network interfaces and other kinds of backend ?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 15:50:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 15:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSTe-0004DJ-Bs; Wed, 04 Apr 2012 15:50:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFSTc-0004DB-Kb
	for xen-devel@lists.xen.org; Wed, 04 Apr 2012 15:50:28 +0000
Received: from [85.158.139.83:38859] by server-6.bemta-5.messagelabs.com id
	39/5C-13222-3CD6C7F4; Wed, 04 Apr 2012 15:50:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333554627!22520436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27261 invoked from network); 4 Apr 2012 15:50:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 15:50:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11774481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:50:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 16:50:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFSQ3-0000wZ-B6	for xen-devel@lists.xen.org;
	Wed, 04 Apr 2012 15:46:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFSQ3-0001XP-AA	for
	xen-devel@lists.xen.org; Wed, 04 Apr 2012 16:46:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20348.27879.297617.171564@mariner.uk.xensource.com>
Date: Wed, 4 Apr 2012 16:46:47 +0100
To: xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

During some discussions and handwaving, including discussions with
some experts on the Xenserver/XCP storage architecture, we came up
with what we think might be a plausible proposal for an architecture
for communication between toolstack and driver domain, for storage at
least.

I offered to write it up.  The abstract proposal is as I understand
the consensus from our conversation.  The concrete protocol is my own
invention.

Please comments.  After a round of review here we should consider
whether some of the assumptions need review from the communities
involved in "other" backends (particularly, the BSDs).

(FAOD the implementation of something like this is not 4.3 material,
but it may inform some API decisions etc. we take in 4.2.)

Ian.


Components

 toolstack

 guest
    Might be the toolstack domain, or an (intended) guest vm.

 driver domain
    Responsible for providing the disk service to guests.
    Consists, internally, of (at least):
       control plane
       backend
    but we avoid exposing this internal implementation detail.

    We permit different driver domains on a single host, serving
    different guests or the same guests.  

    The toolstack is expected to know the domid of the driver domain.

 driver domain kind
    We permit different "kinds" of driver domain, perhaps implemented
    by completely different code, which support different facilities.

    Each driver domain kind needs to document what targets (see
    below) are valid and how they are specified, and what preparatory
    steps may need to be taken eg at system boot.

    Driver domain kinds do not have a formal presence in the API.

Objects

 target
     A kind of name.

     Combination of a physical location and data format plus all other
     information needed by the underlying mechanisms, or relating to
     the data format, needed to access it.

     These names are assigned by the driver domain kind; the names may
     be an open class; no facility provided via this API to enumerate
     these.

     Syntactically, these are key/value pairs, mapping short string
     keys to shortish string values, suitable for storage in a
     xenstore directory.

 vdi
     This host's intent to access a specific target.
     Non-persistent, created on request by toolstack, enumerable.
     Possible states: inactive/active.
     Abstract operations: prepare, activate, deactivate, unprepare.

     (We call the "create" operation for this object "prepare" to
     avoid confusion with other kinds of "create".)

     The toolstack promises that no two vdis for the same target
     will simultaneously be active, even if the two vdis are on
     different hosts.

 vbd
     Provision of a facility for a guest to access a particular target
     via a particular vdi.  There may be zero or more of these at any
     point for a particular vdi.

     Non-persistent, created on request by toolstack, enumerable.
     Abstract operations: plug, unplug.

     (We call the "create" operation for this object "plug" to avoid
     confusion with other kinds of "create".)

     vbds may be created/destroyed, and the underlying vdi
     activated/deactivated, in any other.  However IO is only possible
     to a vbd when the corresponding vdi is active.  The reason for
     requiring activation as a separate step is to allow as much of
     the setup for an incoming migration domain's storage to be done
     before committing to the migration and entering the "domain is
     down" stage, during which access is switched from the old to the
     new host.

     We will consider here the case of a vbd which provides
     service as a Xen vbd backend.  Other cases (eg, the driver domain
     is the same as the toolstack domain and the vbd provides a block
     device in the toolstack domain) can be regarded as
     optimisations/shortcuts.

Concrete protocol

 The toolstack gives instructions to the driver domain, and receives
 results, via xenstore, in the path:
   /local/domain/<driverdomid>/backendctrl/vdi
 Both driver domain and toolstack have write access to the whole of
 this area.

 Each vdi which has been requested and/or exists, corresponds to a
 path .../backendctrl/vdi/<vdi> where <vdi> is a string (of
 alphanumerics, hyphens and underscores) chosen by the toolstack.
 Inside this, there are the following nodes:

 /local/domain/<driverdomid>/backendctrl/vdi/<vdi>/
   state       The current state.  Values are "inactive", "active",
               or ENOENT meaning the vdi does not exist.
               Set by the driver domain in response to requests.

   request     Operation requested by the toolstack and currently
               being performed.  Created by the toolstack, but may
               then not be modified by the toolstack.  Deleted
               by the driver domain when the operation has completed.

               The values of "request" are:
                 prepare
                 activate
                 deactivate
                 unprepare
                 plug <vbd>
                 unplug <vbd>
               <vbd> is an id chosen by the toolstack like <vdi>

   result      errno value (in decimal, Xen error number) best
               describing the results of the most recently completed
               operation; 0 means success.  Created or set by the
               driver domain in the same transaction as it deletes
               request.  The toolstack may delete this.

   result_msg  Optional UTF-8 string explaining any error; does not
               exist when result is "0".  Created or deleted by the
               driver domain whenever the driver domain sets result.
               The toolstack may delete this.

   t/*         The target name.  Must be written by the toolstack.
               But may not be removed or changed while either of
               state or request exist.

   vbd/<vbd>/state
               The state of a vbd, "ok" or ENOENT.
               Set or deleted by the driver domain in response to
               requests.

   vbd/<vbd>/frontend
               The frontend path (complete path in xenstore) which the
               xen vbd should be servicing.  Set by the toolstack
               with the plug request and not modified until after
               completion of unplug.

   vbd/<vbd>/backend
               The backend path (complete path in xenstore) which the
               driver domain has chosen for the vbd.  Set by the
               driver domain in response to a plug request.

   vbd/<vbd>/b-copy/*
               The driver domain may request, in response to plug,
               that the toolstack copy these values to the specified
               backend directory, in the same transaction as it
               creates the frontend.  Set by the driver domain in
               response to a plug request; may be deleted by the
               toolstack.  DEPRECATED, see below.

The operations:

 prepare
        Creates a vdi from a target.
        Preconditions:
            state ENOENT
            request ENOENT
        Request (xenstore writes by toolstack):
            request = "prepare"
            t/* as appropriate
        Results on success (xenstore writes by driver domain):
            request ENOENT    } applies to success from all operations,
            result = "0"      }  will not be restated below
            state = "inactive"
        Results on error (applies to all operations):  }
            request ENOENT                             }  applies
            result = some decimal integer errno value  }   to all
            result_msg = ENOENT or a string            }    failures

 activate
        Preconditions:
            state = "inactive"
            request ENOENT
        Request:
            request = "activate"
        Results on success:
            state = "active"

 deactivate
        Preconditions:
            state = "active"
            request ENOENT
        Request:
            request = "deactivate"
        Results on success:
            state = "inactive"

 unprepare
        Preconditions:
            state != ENOENT
            request ENOENT
        Request:
            request = "unprepare"
        Results on success:
            state = ENOENT

 removal, modification, etc. of an unprepared vdi:
        Preconditions:
            state ENOENT
            request ENOENT
        Request:
            any changes to <vdi> directory which do
             not create "state" or "request"
        Results:
            ignored - no response from driver domain

 plug <vbd>
        Preconditions:
            state ENOENT
            request ENOENT
            vbd/<vbd>/state ENOENT
            <frontend> ENOENT
        Request:
            request = "plug <vbd>"
            vbd/<vbd>/frontend = <frontend> ("/local/domain/<guest>/...")
        Results on success:
            vbd/<vbd>/state = "ok"
            vbd/<vbd>/backend = <rel-backend>
                (<rel-backend> is the backend path relative to the
                 driver domain's home directory in xenstore)
            vbd/<vbd>/b-copy/*  may be created    } at least one of these
            <backend>/*  may come into existence  }  must happen
        Next step (xenstore write) by toolstack:
            <frontend>  created and populated, specifically
            <frontend>/backend = <backend>
                ("/local/domain/<driverdomid>/<rel-backend>")
            <backend>    created if necessary
            <backend>/*  copied from  vbd/<vbd>/b-copy/*  if any
            <backend>/frontend = <frontend>  unless already set

 unplug <vbd>
        Preconditions:
            state ENOENT
            request ENOENT
            vbd/<vbd>/state "ok"
        Request:
            request = "unplug <vbd>"
            <frontend> ENOENT
        Results on success:
            vbd/<vbd>/state ENOENT
            <backend> ENOENT

 The toolstack and driver domains should not store state of their own,
 not required for these communication purposes, in the backendctrl/
 directory in xenstore.  If the driver domain wishes to make records
 for its own use in xenstore, it should do so in a different directory
 of its choice (eg, /local/domain/<driverdomid>/private/<something>.


Notes regarding driver domains whose block backend implementation is
controlled from the actual xenstore backend directory:

 The b-copy/* feature exists for compatibility with some of these.  If
 such a backend cannot cope with the backend directory coming into
 existence before the corresponding frontend directory, then it is
 necessary to create and populate the backend in the same xenstore
 transaction as the creation of the frontend.  However, such backends
 should be fixed; the b-copy/* feature is deprecated and will be
 withdrawn at some point.

 Note that a vbd may be created with the vdi inactive.  In this case
 the frontend and backend directories will exist, but the information
 needed to start up the backend properly may be lacking until the vdi
 is activated.  For example, if the existence of a suitable block
 device in the driver domain depends on vdi activation, the block
 device id cannot be made known to the backend until after the backend
 directory has already been created and perhaps has existed for some
 time.  It is believed that existing backends cope with this, because
 they use a "hotplug script" approach - where the backend directory is
 created without specifying the device node, and this backend directory
 creation causes the invocation of machinery which establishes the
 device node, which is subsequently written to xenstore.


Question

 What about network interfaces and other kinds of backend ?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 16:09:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 16:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSm3-0005Un-M8; Wed, 04 Apr 2012 16:09:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SFSm3-0005Ug-3M
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 16:09:31 +0000
Received: from [85.158.138.51:9965] by server-7.bemta-3.messagelabs.com id
	10/D9-07528-A327C7F4; Wed, 04 Apr 2012 16:09:30 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333555767!20798449!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27017 invoked from network); 4 Apr 2012 16:09:28 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 16:09:28 -0000
Received: by iadj38 with SMTP id j38so684040iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Apr 2012 09:09:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=7xiZFFnfyU/UujO2BUVzRvLffEGnQoYqq1zNFHB+tDw=;
	b=QpmmWkeLVcogHinNv5mkgE7cpzQLJ01QH/1s3Cy5MSxZ3H6KMq5IyKUrlwtamA8oKi
	piDwsnepdqn3M9Ob0G3jtUeojQzVY9mufVwyfawKxWr6JmbzezvZia29SLtXItGZ3CTF
	viZXI0bUgX7jIFpz8oyj2ZTaY5ub/Ne2KAFX0dZZxz/SCqQWW++babCx4lSDLDfcfZN7
	ct7LwwJw20OSlOpn+T4qw+lwMlj5zVts9LLN5HZMne8/54c5x50MpsnNk3DhwRGVLAwQ
	Fms+KH2IJtDOOeE0xnGcC0Xrg2b7GqWjINfzv6IBXXgDXLqStmH4iYPLBGtcR4Awiyse
	foqw==
MIME-Version: 1.0
Received: by 10.50.212.101 with SMTP id nj5mr2205718igc.41.1333555766773; Wed,
	04 Apr 2012 09:09:26 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 4 Apr 2012 09:09:26 -0700 (PDT)
In-Reply-To: <CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
References: <20120403173224.GA22140@aepfle.de>
	<20348.26046.686582.18393@mariner.uk.xensource.com>
	<CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
Date: Wed, 4 Apr 2012 17:09:26 +0100
Message-ID: <CAFEAcA-h2vQdYNNBTb_2hXEHZsK9023V9dVJLL9AvybuejBb_Q@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
X-Gm-Message-State: ALoCoQkyRSx43G0aovT0VOqbSvDYcbP2axE8MtGkVm7C/+QeEq7884o9U/CM8QR0I6u0WNbSZnP6
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gNCBBcHJpbCAyMDEyIDE2OjQwLCBQZXRlciBNYXlkZWxsIDxwZXRlci5tYXlkZWxsQGxpbmFy
by5vcmc+IHdyb3RlOgo+IEhhdmluZyBsb29rZWQgYXQgY29uZmlndXJlIEknbSBwcmV0dHkgc3Vy
ZSB3aGF0IHdlIHdhbnQgaGVyZSBpcwo+IMKgUUVNVV9DRkxBR1M9Ii1tYXJjaD1pNDg2ICRRRU1V
X0NGTEFHUyIKPgo+IGJlY2F1c2Ugd2UncmUgb25seSBkb2luZyB0aGlzIGZvciB0aGUgYmVuZWZp
dCBvZiBhIHBhcnRpY3VsYXIgYml0Cj4gb2YgY29kZSBpbiBody92aG9zdC5jIGFuZCBzbyBRRU1V
X0NGTEFHUyBpcyBzdWZmaWNpZW50LiBBbHNvIHRoaXMKPiBicmluZ3MgaXQgaW50byBsaW5lIHdp
dGggb3RoZXIgcGxhY2VzIHdoZXJlIHdlIGFkZCBhIC1tYXJjaCBmbGFnLAo+IHdoaWNoIHVzZSBR
RU1VX0NGTEFHUywgbm90IENGTEFHUy4KCi4uLmFuZCBoYXZpbmcgZHVnIGFyb3VuZCBpbiB0aGUg
Z2l0IGhpc3Rvcnkgd2UgZmluZCB0aGF0IFFFTVVfQ0ZMQUdTCndlcmUgaW50cm9kdWNlZCBpbiBj
b21taXQgYTU1OGVlMSwgd2hvc2UgY29tbWl0IG1lc3NhZ2UgZGVmaW5lcyB0aGUKZGlmZmVyZW5j
ZSBsaWtlIHRoaXM6CiAgICBRRU1VX0NGTEFHUzogZmxhZ3Mgd2l0aG91dCB3aGljaCB3ZSBjYW4n
dCBjb21waWxlCiAgICBDRkxBR1M6ICItZyAtTzIiCgoiLW1hcmNoPWk0ODYiIGlzIGNsZWFybHkg
ImZsYWdzIHdpdGhvdXQgd2hpY2ggd2UgY2FuJ3QgY29tcGlsZSIsCnNvIHdlIHNob3VsZCBiZSBz
ZXR0aW5nIGl0IGluIFFFTVVfQ0ZMQUdTLCBub3QgQ0ZMQUdTLgoKT2xhZiwgaWYgeW91IHdhbnQg
dG8gc3VibWl0IGEgZml4ZWQgcGF0Y2ggSSB0aGluayB3ZSBzaG91bGQgYXBwbHkKaXQgdG8gdXBz
dHJlYW0gcWVtdS4KClBTOiByZW1hcmtzIGxpa2UKIlRoaXMgcGF0Y2ggaXMgYWdhaW5zdCB0aGUg
cWVtdS14ZW4gdHJlZSwgYnV0IGl0IHNob3VsZCBhcHBseSBhbHNvIHRvCnFlbXUuZ2l0IHNpbmNl
IGl0IGhhcyB0aGUgc2FtZSBpc3N1ZS4gUGxlYXNlIGFwcGx5IHRvIGJvdGggdHJlZXMuIgoKc2hv
dWxkIGdvIGJlbG93IHRoZSAnLS0tJyBpbiBhIHBhdGNoIGVtYWlsIHNvIHRoZXkgZG9uJ3QgYXBw
ZWFyCmluIHRoZSBnaXQgY29tbWl0IG1lc3NhZ2Ugd2hlbiB0aGUgcGF0Y2ggaXMgYXBwbGllZC4K
CnRoYW5rcwotLSBQTU0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 04 16:09:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 16:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFSm3-0005Un-M8; Wed, 04 Apr 2012 16:09:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SFSm3-0005Ug-3M
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 16:09:31 +0000
Received: from [85.158.138.51:9965] by server-7.bemta-3.messagelabs.com id
	10/D9-07528-A327C7F4; Wed, 04 Apr 2012 16:09:30 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333555767!20798449!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27017 invoked from network); 4 Apr 2012 16:09:28 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 16:09:28 -0000
Received: by iadj38 with SMTP id j38so684040iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Apr 2012 09:09:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=7xiZFFnfyU/UujO2BUVzRvLffEGnQoYqq1zNFHB+tDw=;
	b=QpmmWkeLVcogHinNv5mkgE7cpzQLJ01QH/1s3Cy5MSxZ3H6KMq5IyKUrlwtamA8oKi
	piDwsnepdqn3M9Ob0G3jtUeojQzVY9mufVwyfawKxWr6JmbzezvZia29SLtXItGZ3CTF
	viZXI0bUgX7jIFpz8oyj2ZTaY5ub/Ne2KAFX0dZZxz/SCqQWW++babCx4lSDLDfcfZN7
	ct7LwwJw20OSlOpn+T4qw+lwMlj5zVts9LLN5HZMne8/54c5x50MpsnNk3DhwRGVLAwQ
	Fms+KH2IJtDOOeE0xnGcC0Xrg2b7GqWjINfzv6IBXXgDXLqStmH4iYPLBGtcR4Awiyse
	foqw==
MIME-Version: 1.0
Received: by 10.50.212.101 with SMTP id nj5mr2205718igc.41.1333555766773; Wed,
	04 Apr 2012 09:09:26 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 4 Apr 2012 09:09:26 -0700 (PDT)
In-Reply-To: <CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
References: <20120403173224.GA22140@aepfle.de>
	<20348.26046.686582.18393@mariner.uk.xensource.com>
	<CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
Date: Wed, 4 Apr 2012 17:09:26 +0100
Message-ID: <CAFEAcA-h2vQdYNNBTb_2hXEHZsK9023V9dVJLL9AvybuejBb_Q@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
X-Gm-Message-State: ALoCoQkyRSx43G0aovT0VOqbSvDYcbP2axE8MtGkVm7C/+QeEq7884o9U/CM8QR0I6u0WNbSZnP6
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gNCBBcHJpbCAyMDEyIDE2OjQwLCBQZXRlciBNYXlkZWxsIDxwZXRlci5tYXlkZWxsQGxpbmFy
by5vcmc+IHdyb3RlOgo+IEhhdmluZyBsb29rZWQgYXQgY29uZmlndXJlIEknbSBwcmV0dHkgc3Vy
ZSB3aGF0IHdlIHdhbnQgaGVyZSBpcwo+IMKgUUVNVV9DRkxBR1M9Ii1tYXJjaD1pNDg2ICRRRU1V
X0NGTEFHUyIKPgo+IGJlY2F1c2Ugd2UncmUgb25seSBkb2luZyB0aGlzIGZvciB0aGUgYmVuZWZp
dCBvZiBhIHBhcnRpY3VsYXIgYml0Cj4gb2YgY29kZSBpbiBody92aG9zdC5jIGFuZCBzbyBRRU1V
X0NGTEFHUyBpcyBzdWZmaWNpZW50LiBBbHNvIHRoaXMKPiBicmluZ3MgaXQgaW50byBsaW5lIHdp
dGggb3RoZXIgcGxhY2VzIHdoZXJlIHdlIGFkZCBhIC1tYXJjaCBmbGFnLAo+IHdoaWNoIHVzZSBR
RU1VX0NGTEFHUywgbm90IENGTEFHUy4KCi4uLmFuZCBoYXZpbmcgZHVnIGFyb3VuZCBpbiB0aGUg
Z2l0IGhpc3Rvcnkgd2UgZmluZCB0aGF0IFFFTVVfQ0ZMQUdTCndlcmUgaW50cm9kdWNlZCBpbiBj
b21taXQgYTU1OGVlMSwgd2hvc2UgY29tbWl0IG1lc3NhZ2UgZGVmaW5lcyB0aGUKZGlmZmVyZW5j
ZSBsaWtlIHRoaXM6CiAgICBRRU1VX0NGTEFHUzogZmxhZ3Mgd2l0aG91dCB3aGljaCB3ZSBjYW4n
dCBjb21waWxlCiAgICBDRkxBR1M6ICItZyAtTzIiCgoiLW1hcmNoPWk0ODYiIGlzIGNsZWFybHkg
ImZsYWdzIHdpdGhvdXQgd2hpY2ggd2UgY2FuJ3QgY29tcGlsZSIsCnNvIHdlIHNob3VsZCBiZSBz
ZXR0aW5nIGl0IGluIFFFTVVfQ0ZMQUdTLCBub3QgQ0ZMQUdTLgoKT2xhZiwgaWYgeW91IHdhbnQg
dG8gc3VibWl0IGEgZml4ZWQgcGF0Y2ggSSB0aGluayB3ZSBzaG91bGQgYXBwbHkKaXQgdG8gdXBz
dHJlYW0gcWVtdS4KClBTOiByZW1hcmtzIGxpa2UKIlRoaXMgcGF0Y2ggaXMgYWdhaW5zdCB0aGUg
cWVtdS14ZW4gdHJlZSwgYnV0IGl0IHNob3VsZCBhcHBseSBhbHNvIHRvCnFlbXUuZ2l0IHNpbmNl
IGl0IGhhcyB0aGUgc2FtZSBpc3N1ZS4gUGxlYXNlIGFwcGx5IHRvIGJvdGggdHJlZXMuIgoKc2hv
dWxkIGdvIGJlbG93IHRoZSAnLS0tJyBpbiBhIHBhdGNoIGVtYWlsIHNvIHRoZXkgZG9uJ3QgYXBw
ZWFyCmluIHRoZSBnaXQgY29tbWl0IG1lc3NhZ2Ugd2hlbiB0aGUgcGF0Y2ggaXMgYXBwbGllZC4K
CnRoYW5rcwotLSBQTU0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 04 18:43:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 18:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVAb-0008Vk-ER; Wed, 04 Apr 2012 18:43:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFVAZ-0008Vf-Sy
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 18:43:00 +0000
Received: from [85.158.138.51:27637] by server-12.bemta-3.messagelabs.com id
	D2/D9-30663-3369C7F4; Wed, 04 Apr 2012 18:42:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333564977!20746688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28433 invoked from network); 4 Apr 2012 18:42:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 18:42:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11777766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 18:42:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 19:42:57 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFVAX-0002Os-Ag;
	Wed, 04 Apr 2012 18:42:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFVAX-00012G-4E;
	Wed, 04 Apr 2012 19:42:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12562-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 19:42:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12562: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12562 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12562/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 18:43:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 18:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVAb-0008Vk-ER; Wed, 04 Apr 2012 18:43:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFVAZ-0008Vf-Sy
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 18:43:00 +0000
Received: from [85.158.138.51:27637] by server-12.bemta-3.messagelabs.com id
	D2/D9-30663-3369C7F4; Wed, 04 Apr 2012 18:42:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333564977!20746688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28433 invoked from network); 4 Apr 2012 18:42:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 18:42:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="11777766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 18:42:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Apr 2012 19:42:57 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFVAX-0002Os-Ag;
	Wed, 04 Apr 2012 18:42:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFVAX-00012G-4E;
	Wed, 04 Apr 2012 19:42:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12562-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Apr 2012 19:42:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12562: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12562 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12562/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 19:26:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 19:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVpr-0000U6-MS; Wed, 04 Apr 2012 19:25:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFVpq-0000Tv-02
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 19:25:38 +0000
Received: from [85.158.139.83:20112] by server-4.bemta-5.messagelabs.com id
	D8/71-10788-130AC7F4; Wed, 04 Apr 2012 19:25:37 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333567534!18246686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19836 invoked from network); 4 Apr 2012 19:25:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 19:25:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="23881321"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:25:33 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Wed, 4 Apr 2012 15:25:33 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 4 Apr 2012 15:25:52 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0SRYyqqVsx1g4/QeC2m5nMKtH6GAATsLfA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333531815.20300.11.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 04, 2012 5:30 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> Seems like this thread slipped through the cracks, sorry about that.
> Please do give us a prod (e.g. a ping message) after a few days/a week
> when this happens.

Ok, thanks, will do.

> 
> On Thu, 2012-03-22 at 14:03 +0000, Ross Philipson wrote:
> > -----Original Message-----
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Sent: Thursday, March 22, 2012 7:26 AM
> > > To: Keir Fraser
> > > Cc: xen-devel@lists.xensource.com; Ian Campbell; Ross Philipson
> > > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > >
> > > Hi,
> > >
> > > At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote:
> > > > My impression from the earlier discussions is that we're pasing
> > > > largish blobs of binary BIOS goop around, which aren't suitable to
> > > > go into xenstore.  Dropping them in memory where HVMloader can
> > > > pick them up seems reasonable.
> > > >
> > > > All the control-path stuff - what the blobs are, where they are
> > > > &c, should go through Xenstore, though.
> > >
> > > So having looked at the code, I think the module system is really
> > > overkill - AIUI all the things you're talking about passing through
> > > are ACPI tables, which have their own length fields internally. So
> > > all
> >
> > Ok well fair enough. I can go back and do it again, making something
> > smaller. For the record, I am passing in more than just ACPI tables; I
> > am passing in parts of the SMBIOS tables. Each of the SMBIOS types
> > does not actually report its length but rather you have to parse them
> > for the double terminator after the string section. I guess it seems a
> > shame to have to do that parse logic in two places.
> 
> I think Tim was suggesting that in xs this looks something like:
> 	.../hvmloader/acpi/address
> 	(no .../acpi/length length? encoded in tables)
> 	.../hvmloader/smbios/address
> 	.../hvmloader/smbios/length
> 	.../hvmloader/some-other/{address,length?}...
> 
> with the data at the referenced addresses.
> 
> If it's convenient (or even just for consistency) there's no reason IMHO
> not to include the length even where the length is part of the data.
> Similarly you can add checksums etc if those are useful.
> 

Well actually it does not really do any good to have the length in xenstore (at least for the types we are currently talking about) other than knowing the overall extent of the blob. The problem is that we are talking about multiple tables chained together. For ACPI this is not a problem because the table length is specified in the table header. For SMBIOS (where there will almost certainly be multiple tables) the length of each table is not specified and so the set would have to be re-parsed in hvmloader to find each individual table. That was the motivation for a separate table header we define. I still think some simple entry delimiter structure with some small amount of information about each item is a good idea.

But in general I don't have a problem with using xenstore for this sort of thing so I am fine with the basic concept.

> > > you'd need to do is have a type code and an address in xenstore
> > > somewhere, the same way we pass a type code and a string for the
> > > other BIOS customizations.
> > >
> >
> > So I am not exactly sure how to proceed here since libxc seems the
> > correct place to load the individual blobs (ACPI tables, SMBIOS junk)
> > but libxc seems too low level to be writing values to xenstore (and it
> > does not do that at present). Would it be better to have a peer API to
> > xc_hvm_build() that write the chunks and returns the addresses where
> > it loaded them? Or should it be totally moved out of libxc? Advice
> > would be appreciated...
> 
> The layering relationship between libxc and libxs here is a bit of a
> pain, but lets not try and solve that now.
> 
> I think you can just add a guest_address field to your struct
> xc_hvm_module as an output field which the caller would then push into
> xenstore along with the (potentially updated) length field.
> 
> Given the above XS layout then I think where you have a list of modules
> in xc_hvm_build_args you can just have "struct xc_hvm_module acpi".
> Similarly for smbios and whatever new table types come up in the future.
> I don't think having each module type explicitly here matters since each
> new table type needs a bunch of support code in at least hvmloader
> anyway so adding a few lines to libxc to expose it at the same time is
> fine.

That seems like a reasonable way to do it. Especially if (wrt below) we have the caller glom the like bits together.

> 
> > Finally, I had made this a generic framework because I thought it
> > could be extended in the future to pass in other types of firmware-ish
> > blobs at runtime. It also handles the case where the passing of one
> > set of tables/blobs is not tied to passing another set. E.g. in our
> > work we pass in some static ACPI tables to satisfy one feature and
> > construct/pass-in an SSDT to satisfy another unrelated feature.
> 
> I think it is ok to have it be up to the caller to glom those together
> into a single "ACPI" blob which is processed by hvmloader into the right
> places. Or is there a problem with that which hasn't occurred to me?
> (Likewise in the SMBIOS case)
> 
> If it is a problem then
> 	.../acpi/0/...
> 	.../acpi/1/...
> (or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things. Not
> sure about the libxc level, I'll worry about it when you tell me what
> I've missed which makes it necessary ;-)

Well that approach was mostly for flexibility (as in the scenario I pointed out). The only other issue might be the measuring of components by a domain builder but I don't think that that prevents glomming. Presumably the glomming code is part of the overall domain builder code so a measure-then-glom operation can happen. And doing the merge in the tools makes the code in hvmloader simpler so I am good with that.

Given all that, the only real issue I see at the moment is how to deal with multiple entries within a blob that don't readily specify their own lengths. I am in favor of a delimiting struct with possibly a terminating form (like a flag). Then all we put in xenstore is the gpe for each type.

Finally I wanted to bring up again the idea of another helper component (lib maybe) that can be used to build and glom (I like that word) modules. Note that in many cases the passed in firmware is going to be pulled from the host firmware. I already have bunches of codes that do that. Perhaps I should start an RFC thread for that as a separate task? Thoughts on this?

Thanks
Ross

> 
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 19:26:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 19:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVpr-0000U6-MS; Wed, 04 Apr 2012 19:25:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFVpq-0000Tv-02
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 19:25:38 +0000
Received: from [85.158.139.83:20112] by server-4.bemta-5.messagelabs.com id
	D8/71-10788-130AC7F4; Wed, 04 Apr 2012 19:25:37 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333567534!18246686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19836 invoked from network); 4 Apr 2012 19:25:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 19:25:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="23881321"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:25:33 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Wed, 4 Apr 2012 15:25:33 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 4 Apr 2012 15:25:52 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0SRYyqqVsx1g4/QeC2m5nMKtH6GAATsLfA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333531815.20300.11.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 04, 2012 5:30 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> Seems like this thread slipped through the cracks, sorry about that.
> Please do give us a prod (e.g. a ping message) after a few days/a week
> when this happens.

Ok, thanks, will do.

> 
> On Thu, 2012-03-22 at 14:03 +0000, Ross Philipson wrote:
> > -----Original Message-----
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Sent: Thursday, March 22, 2012 7:26 AM
> > > To: Keir Fraser
> > > Cc: xen-devel@lists.xensource.com; Ian Campbell; Ross Philipson
> > > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > >
> > > Hi,
> > >
> > > At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote:
> > > > My impression from the earlier discussions is that we're pasing
> > > > largish blobs of binary BIOS goop around, which aren't suitable to
> > > > go into xenstore.  Dropping them in memory where HVMloader can
> > > > pick them up seems reasonable.
> > > >
> > > > All the control-path stuff - what the blobs are, where they are
> > > > &c, should go through Xenstore, though.
> > >
> > > So having looked at the code, I think the module system is really
> > > overkill - AIUI all the things you're talking about passing through
> > > are ACPI tables, which have their own length fields internally. So
> > > all
> >
> > Ok well fair enough. I can go back and do it again, making something
> > smaller. For the record, I am passing in more than just ACPI tables; I
> > am passing in parts of the SMBIOS tables. Each of the SMBIOS types
> > does not actually report its length but rather you have to parse them
> > for the double terminator after the string section. I guess it seems a
> > shame to have to do that parse logic in two places.
> 
> I think Tim was suggesting that in xs this looks something like:
> 	.../hvmloader/acpi/address
> 	(no .../acpi/length length? encoded in tables)
> 	.../hvmloader/smbios/address
> 	.../hvmloader/smbios/length
> 	.../hvmloader/some-other/{address,length?}...
> 
> with the data at the referenced addresses.
> 
> If it's convenient (or even just for consistency) there's no reason IMHO
> not to include the length even where the length is part of the data.
> Similarly you can add checksums etc if those are useful.
> 

Well actually it does not really do any good to have the length in xenstore (at least for the types we are currently talking about) other than knowing the overall extent of the blob. The problem is that we are talking about multiple tables chained together. For ACPI this is not a problem because the table length is specified in the table header. For SMBIOS (where there will almost certainly be multiple tables) the length of each table is not specified and so the set would have to be re-parsed in hvmloader to find each individual table. That was the motivation for a separate table header we define. I still think some simple entry delimiter structure with some small amount of information about each item is a good idea.

But in general I don't have a problem with using xenstore for this sort of thing so I am fine with the basic concept.

> > > you'd need to do is have a type code and an address in xenstore
> > > somewhere, the same way we pass a type code and a string for the
> > > other BIOS customizations.
> > >
> >
> > So I am not exactly sure how to proceed here since libxc seems the
> > correct place to load the individual blobs (ACPI tables, SMBIOS junk)
> > but libxc seems too low level to be writing values to xenstore (and it
> > does not do that at present). Would it be better to have a peer API to
> > xc_hvm_build() that write the chunks and returns the addresses where
> > it loaded them? Or should it be totally moved out of libxc? Advice
> > would be appreciated...
> 
> The layering relationship between libxc and libxs here is a bit of a
> pain, but lets not try and solve that now.
> 
> I think you can just add a guest_address field to your struct
> xc_hvm_module as an output field which the caller would then push into
> xenstore along with the (potentially updated) length field.
> 
> Given the above XS layout then I think where you have a list of modules
> in xc_hvm_build_args you can just have "struct xc_hvm_module acpi".
> Similarly for smbios and whatever new table types come up in the future.
> I don't think having each module type explicitly here matters since each
> new table type needs a bunch of support code in at least hvmloader
> anyway so adding a few lines to libxc to expose it at the same time is
> fine.

That seems like a reasonable way to do it. Especially if (wrt below) we have the caller glom the like bits together.

> 
> > Finally, I had made this a generic framework because I thought it
> > could be extended in the future to pass in other types of firmware-ish
> > blobs at runtime. It also handles the case where the passing of one
> > set of tables/blobs is not tied to passing another set. E.g. in our
> > work we pass in some static ACPI tables to satisfy one feature and
> > construct/pass-in an SSDT to satisfy another unrelated feature.
> 
> I think it is ok to have it be up to the caller to glom those together
> into a single "ACPI" blob which is processed by hvmloader into the right
> places. Or is there a problem with that which hasn't occurred to me?
> (Likewise in the SMBIOS case)
> 
> If it is a problem then
> 	.../acpi/0/...
> 	.../acpi/1/...
> (or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things. Not
> sure about the libxc level, I'll worry about it when you tell me what
> I've missed which makes it necessary ;-)

Well that approach was mostly for flexibility (as in the scenario I pointed out). The only other issue might be the measuring of components by a domain builder but I don't think that that prevents glomming. Presumably the glomming code is part of the overall domain builder code so a measure-then-glom operation can happen. And doing the merge in the tools makes the code in hvmloader simpler so I am good with that.

Given all that, the only real issue I see at the moment is how to deal with multiple entries within a blob that don't readily specify their own lengths. I am in favor of a delimiting struct with possibly a terminating form (like a flag). Then all we put in xenstore is the gpe for each type.

Finally I wanted to bring up again the idea of another helper component (lib maybe) that can be used to build and glom (I like that word) modules. Note that in many cases the passed in firmware is going to be pulled from the host firmware. I already have bunches of codes that do that. Perhaps I should start an RFC thread for that as a separate task? Thoughts on this?

Thanks
Ross

> 
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 19:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 19:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVuM-0000gq-Co; Wed, 04 Apr 2012 19:30:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFVuK-0000gh-Ko
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 19:30:16 +0000
Received: from [193.109.254.147:40866] by server-2.bemta-14.messagelabs.com id
	F2/5D-19409-741AC7F4; Wed, 04 Apr 2012 19:30:15 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333567813!3283610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27883 invoked from network); 4 Apr 2012 19:30:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 19:30:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="23881565"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:29:47 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Wed, 4 Apr 2012 15:29:48 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 4 Apr 2012 15:30:07 -0400
Thread-Topic: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
	init module support
Thread-Index: Ac0SSGr0Z57rkHKdRK+u+3pEv+/HhgAUIF/g
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E8@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
	<1333531847.20300.12.camel@zakaz.uk.xensource.com>
	<20120404094736.GA99714@ocelot.phlegethon.org>
	<1333533047.20582.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333533047.20582.2.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
 init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 04, 2012 5:51 AM
> To: Tim (Xen.org)
> Cc: Ross Philipson; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough:
> hvmloader init module support
> 
> On Wed, 2012-04-04 at 10:47 +0100, Tim Deegan wrote:
> [...]
> > > In fact, it looks like that ASM block deliberately zeroes ecx and
> > > edx so how does this work?
> >
> > The asm header clears them after calling main().
> 
> So it does, I didn't realise that the "go" button in hvmloader was
> return from main, subtle!
> 
> [...]
> > In any case, this all goes away if the module info is passed in
> xenstore.
> 
> Yes.
> 
> Ian.
> 

I mainly did it this way as a first approach since I was not sure how to use xenstore with libxc etc. I figured this would be called out for critique anyway. But, as noted, it is no longer an issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 19:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 19:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVuM-0000gq-Co; Wed, 04 Apr 2012 19:30:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFVuK-0000gh-Ko
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 19:30:16 +0000
Received: from [193.109.254.147:40866] by server-2.bemta-14.messagelabs.com id
	F2/5D-19409-741AC7F4; Wed, 04 Apr 2012 19:30:15 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333567813!3283610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27883 invoked from network); 4 Apr 2012 19:30:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 19:30:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="23881565"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:29:47 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Wed, 4 Apr 2012 15:29:48 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 4 Apr 2012 15:30:07 -0400
Thread-Topic: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
	init module support
Thread-Index: Ac0SSGr0Z57rkHKdRK+u+3pEv+/HhgAUIF/g
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E8@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAB@FTLPMAILBOX02.citrite.net>
	<1333531847.20300.12.camel@zakaz.uk.xensource.com>
	<20120404094736.GA99714@ocelot.phlegethon.org>
	<1333533047.20582.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333533047.20582.2.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough: hvmloader
 init module support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 04, 2012 5:51 AM
> To: Tim (Xen.org)
> Cc: Ross Philipson; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 03/07] HVM firmware passthrough:
> hvmloader init module support
> 
> On Wed, 2012-04-04 at 10:47 +0100, Tim Deegan wrote:
> [...]
> > > In fact, it looks like that ASM block deliberately zeroes ecx and
> > > edx so how does this work?
> >
> > The asm header clears them after calling main().
> 
> So it does, I didn't realise that the "go" button in hvmloader was
> return from main, subtle!
> 
> [...]
> > In any case, this all goes away if the module info is passed in
> xenstore.
> 
> Yes.
> 
> Ian.
> 

I mainly did it this way as a first approach since I was not sure how to use xenstore with libxc etc. I figured this would be called out for critique anyway. But, as noted, it is no longer an issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 19:32:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 19:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVvf-0000ll-Rv; Wed, 04 Apr 2012 19:31:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFVvd-0000lX-Nm
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 19:31:37 +0000
Received: from [193.109.254.147:48390] by server-7.bemta-14.messagelabs.com id
	42/62-01627-891AC7F4; Wed, 04 Apr 2012 19:31:36 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333567895!3288731!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15857 invoked from network); 4 Apr 2012 19:31:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 19:31:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="23881616"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:31:34 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Wed, 4 Apr 2012 15:31:35 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 4 Apr 2012 15:31:54 -0400
Thread-Topic: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen
	control tools support
Thread-Index: Ac0SRfVgLZv8WP1XQkeEPO69n4StZgAU2f9w
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E9@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAF@FTLPMAILBOX02.citrite.net>
	<1333531991.20300.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333531991.20300.14.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen control
 tools support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 04, 2012 5:33 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen
> control tools support
> 
> On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> > diff -r e87559f0de44 tools/libxc/xenguest.h
> > --- a/tools/libxc/xenguest.h    Mon Mar 19 16:57:55 2012 -0400
> > +++ b/tools/libxc/xenguest.h    Mon Mar 19 17:02:33 2012 -0400
> > @@ -176,6 +176,8 @@ struct xc_hvm_build_args {
> >      uint64_t mem_target;         /* Memory target in bytes. */
> >      uint64_t mmio_size;          /* Size of the MMIO hole in bytes.
> > */
> >      const char *image_file_name; /* File name of the image to load.
> > */
> > +    const char **module_names;   /* List of HVM module files to load.
> > */
> > +    uint32_t module_count;       /* Count of HVM modules. */
> >  };
> 
> Why files rather than pointers to data in memory? A pointer would be
> easier if you wanted to construct a table on the fly and you could still
> provide a helper function for the caller to load a file too.
> 
> Ian.

I only did files because the hvmloader image was passed in that way (so for consistency). I am fine with passing in blobs and it fits better with what we are discussing in the 00/07 thread.

Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 19:32:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 19:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFVvf-0000ll-Rv; Wed, 04 Apr 2012 19:31:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFVvd-0000lX-Nm
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 19:31:37 +0000
Received: from [193.109.254.147:48390] by server-7.bemta-14.messagelabs.com id
	42/62-01627-891AC7F4; Wed, 04 Apr 2012 19:31:36 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333567895!3288731!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ3NjE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15857 invoked from network); 4 Apr 2012 19:31:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 19:31:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="23881616"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 15:31:34 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Wed, 4 Apr 2012 15:31:35 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 4 Apr 2012 15:31:54 -0400
Thread-Topic: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen
	control tools support
Thread-Index: Ac0SRfVgLZv8WP1XQkeEPO69n4StZgAU2f9w
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E9@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAF@FTLPMAILBOX02.citrite.net>
	<1333531991.20300.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333531991.20300.14.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen control
 tools support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 04, 2012 5:33 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 07/07] HVM firmware passthrough: Xen
> control tools support
> 
> On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> > diff -r e87559f0de44 tools/libxc/xenguest.h
> > --- a/tools/libxc/xenguest.h    Mon Mar 19 16:57:55 2012 -0400
> > +++ b/tools/libxc/xenguest.h    Mon Mar 19 17:02:33 2012 -0400
> > @@ -176,6 +176,8 @@ struct xc_hvm_build_args {
> >      uint64_t mem_target;         /* Memory target in bytes. */
> >      uint64_t mmio_size;          /* Size of the MMIO hole in bytes.
> > */
> >      const char *image_file_name; /* File name of the image to load.
> > */
> > +    const char **module_names;   /* List of HVM module files to load.
> > */
> > +    uint32_t module_count;       /* Count of HVM modules. */
> >  };
> 
> Why files rather than pointers to data in memory? A pointer would be
> easier if you wanted to construct a table on the fly and you could still
> provide a helper function for the caller to load a file too.
> 
> Ian.

I only did files because the hvmloader image was passed in that way (so for consistency). I am fine with passing in blobs and it fits better with what we are discussing in the 00/07 thread.

Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 23:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 23:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFZmY-0002WZ-5e; Wed, 04 Apr 2012 23:38:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFZmW-0002WJ-HP
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 23:38:28 +0000
Received: from [193.109.254.147:56483] by server-8.bemta-14.messagelabs.com id
	18/60-23244-37BDC7F4; Wed, 04 Apr 2012 23:38:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333582707!3293902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14543 invoked from network); 4 Apr 2012 23:38:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 23:38:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,371,1330905600"; d="scan'208";a="11780878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 23:38:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 00:38:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFZmU-0004oh-F0;
	Wed, 04 Apr 2012 23:38:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFZmU-0006im-6e;
	Thu, 05 Apr 2012 00:38:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12563-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 00:38:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12563: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12563 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12563/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2     fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  ed48258053ae

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 04 23:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Apr 2012 23:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFZmY-0002WZ-5e; Wed, 04 Apr 2012 23:38:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFZmW-0002WJ-HP
	for xen-devel@lists.xensource.com; Wed, 04 Apr 2012 23:38:28 +0000
Received: from [193.109.254.147:56483] by server-8.bemta-14.messagelabs.com id
	18/60-23244-37BDC7F4; Wed, 04 Apr 2012 23:38:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333582707!3293902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14543 invoked from network); 4 Apr 2012 23:38:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Apr 2012 23:38:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,371,1330905600"; d="scan'208";a="11780878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Apr 2012 23:38:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 00:38:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFZmU-0004oh-F0;
	Wed, 04 Apr 2012 23:38:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFZmU-0006im-6e;
	Thu, 05 Apr 2012 00:38:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12563-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 00:38:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12563: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12563 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12563/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2     fail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  2386288b1bf1
baseline version:
 xen                  ed48258053ae

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 00:08:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 00:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFaF0-0003NZ-N4; Thu, 05 Apr 2012 00:07:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFaEz-0003NU-IM
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 00:07:53 +0000
Received: from [85.158.143.99:47651] by server-2.bemta-4.messagelabs.com id
	BB/31-17550-852EC7F4; Thu, 05 Apr 2012 00:07:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333584470!21486180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28350 invoked from network); 5 Apr 2012 00:07:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 00:07:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,372,1330905600"; d="scan'208";a="11780986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 00:07:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 01:07:49 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFaEv-0004y3-02;
	Thu, 05 Apr 2012 00:07:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFaEu-0005sP-Uw;
	Thu, 05 Apr 2012 01:07:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12564-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 01:07:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12564: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12564 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12564/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                01627d968c8b5e2810fe8c417b406b968297c236
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 00:08:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 00:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFaF0-0003NZ-N4; Thu, 05 Apr 2012 00:07:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFaEz-0003NU-IM
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 00:07:53 +0000
Received: from [85.158.143.99:47651] by server-2.bemta-4.messagelabs.com id
	BB/31-17550-852EC7F4; Thu, 05 Apr 2012 00:07:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333584470!21486180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28350 invoked from network); 5 Apr 2012 00:07:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 00:07:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,372,1330905600"; d="scan'208";a="11780986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 00:07:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 01:07:49 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFaEv-0004y3-02;
	Thu, 05 Apr 2012 00:07:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFaEu-0005sP-Uw;
	Thu, 05 Apr 2012 01:07:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12564-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 01:07:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12564: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12564 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12564/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                01627d968c8b5e2810fe8c417b406b968297c236
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 00:13:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 00:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFaKC-0003ZA-Ea; Thu, 05 Apr 2012 00:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1SFaKB-0003Z5-DV
	for Xen-devel@lists.xensource.com; Thu, 05 Apr 2012 00:13:15 +0000
Received: from [85.158.143.35:5665] by server-3.bemta-4.messagelabs.com id
	E2/84-05853-A93EC7F4; Thu, 05 Apr 2012 00:13:14 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333584793!8620912!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA5OTgwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12937 invoked from network); 5 Apr 2012 00:13:14 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 00:13:14 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q350CEvL008767;
	Thu, 5 Apr 2012 01:12:18 +0100
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q350C1jR010125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 01:12:01 +0100
Received: from vega-a.dur.ac.uk (localhost [127.0.0.1])
	by vega-a.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q350C1AB019229;
	Thu, 5 Apr 2012 01:12:01 +0100
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q350BvA0019223;
	Thu, 5 Apr 2012 01:11:57 +0100
Date: Thu, 5 Apr 2012 01:11:57 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120328162040.GA5711@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
	<alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
	<20120326135349.GB18285@phenom.dumpdata.com>
	<alpine.DEB.2.00.1203272306370.1410@vega-a.dur.ac.uk>
	<20120328162040.GA5711@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q350CEvL008767
Cc: xen@lists.fedoraproject.org,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Fedora Core 17 Xorg can't use /dev/fb0 when using
 Cirrus Logic VGA or Xen PVFB driver,
 Was:Re:  irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 28 Mar 2012, Konrad Rzeszutek Wilk wrote:

> So with extra="console=hvc0 loglevel=8 root=live:http://build/tftpboot/f17-i386/LiveOS/squashfs.img"
>
> I was able to succesfully install, but booting proved interestingly.
>
> When trying the 'pygrub' it would complain about the 'No OS loader', but if I ran
> it on the disk (pygrub /dev/vg_guest/f17_32) it would extract the payload properly.
> (This is with xen-4.1.2-6.fc16). So I worked around by taking those images
> directly:
>
> kernel="/var/run/xend/boot/boot_kernel.jIsJmr"
> ramdisk="/var/run/xend/boot/boot_ramdisk.I4rBjo"
> extra="root=/dev/mapper/vg_f17-lv_root ro rd.md=0 rd.lvm.lv=vg_f17/lv_swap SYSFONT=True  KEYTABLE=us rd.lvm.lv=vg_f17/lv_root rd.luks=0 LANG=en_US.UTF-8 rd.dm=0"

pygrub works for me via xl. It may be a result of how you are booting the 
guest.

> And when booting F17 either as HVM or PV, in both cases I got Xorg to
> tell me:
>
> (EE) FBDEV(0): FBIOBLANK: Invalid argument
>
> and freeze.

That seems to be harmless. However I do get the "an error has occurred" 
message instead of the gdm login screen though until I removed the fprintd 
package (and the dependent fprintd-pam package).

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 00:13:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 00:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFaKC-0003ZA-Ea; Thu, 05 Apr 2012 00:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1SFaKB-0003Z5-DV
	for Xen-devel@lists.xensource.com; Thu, 05 Apr 2012 00:13:15 +0000
Received: from [85.158.143.35:5665] by server-3.bemta-4.messagelabs.com id
	E2/84-05853-A93EC7F4; Thu, 05 Apr 2012 00:13:14 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333584793!8620912!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA5OTgwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12937 invoked from network); 5 Apr 2012 00:13:14 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 00:13:14 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q350CEvL008767;
	Thu, 5 Apr 2012 01:12:18 +0100
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q350C1jR010125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 01:12:01 +0100
Received: from vega-a.dur.ac.uk (localhost [127.0.0.1])
	by vega-a.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q350C1AB019229;
	Thu, 5 Apr 2012 01:12:01 +0100
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q350BvA0019223;
	Thu, 5 Apr 2012 01:11:57 +0100
Date: Thu, 5 Apr 2012 01:11:57 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120328162040.GA5711@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
	<alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
	<20120326135349.GB18285@phenom.dumpdata.com>
	<alpine.DEB.2.00.1203272306370.1410@vega-a.dur.ac.uk>
	<20120328162040.GA5711@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q350CEvL008767
Cc: xen@lists.fedoraproject.org,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Fedora Core 17 Xorg can't use /dev/fb0 when using
 Cirrus Logic VGA or Xen PVFB driver,
 Was:Re:  irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 28 Mar 2012, Konrad Rzeszutek Wilk wrote:

> So with extra="console=hvc0 loglevel=8 root=live:http://build/tftpboot/f17-i386/LiveOS/squashfs.img"
>
> I was able to succesfully install, but booting proved interestingly.
>
> When trying the 'pygrub' it would complain about the 'No OS loader', but if I ran
> it on the disk (pygrub /dev/vg_guest/f17_32) it would extract the payload properly.
> (This is with xen-4.1.2-6.fc16). So I worked around by taking those images
> directly:
>
> kernel="/var/run/xend/boot/boot_kernel.jIsJmr"
> ramdisk="/var/run/xend/boot/boot_ramdisk.I4rBjo"
> extra="root=/dev/mapper/vg_f17-lv_root ro rd.md=0 rd.lvm.lv=vg_f17/lv_swap SYSFONT=True  KEYTABLE=us rd.lvm.lv=vg_f17/lv_root rd.luks=0 LANG=en_US.UTF-8 rd.dm=0"

pygrub works for me via xl. It may be a result of how you are booting the 
guest.

> And when booting F17 either as HVM or PV, in both cases I got Xorg to
> tell me:
>
> (EE) FBDEV(0): FBIOBLANK: Invalid argument
>
> and freeze.

That seems to be harmless. However I do get the "an error has occurred" 
message instead of the gdm login screen though until I removed the fprintd 
package (and the dependent fprintd-pam package).

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 01:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 01:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFbGd-0007k4-96; Thu, 05 Apr 2012 01:13:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SFbGb-0007jz-JD
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 01:13:37 +0000
Received: from [85.158.138.51:14699] by server-9.bemta-3.messagelabs.com id
	11/BE-10923-0C1FC7F4; Thu, 05 Apr 2012 01:13:36 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333588415!19032694!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU4MDk0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10062 invoked from network); 5 Apr 2012 01:13:36 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 01:13:36 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 04 Apr 2012 18:13:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="85464160"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 04 Apr 2012 18:13:33 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 4 Apr 2012 18:13:33 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 5 Apr 2012 09:13:31 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNEPImuKVWc2YDX0uKv0mNtPrh5JaLb5NQ
Date: Thu, 5 Apr 2012 01:13:30 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
In-Reply-To: <20345.56112.630128.747571@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Tuesday, April 03, 2012 1:01 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> > <Porting from Xen 4.1 tree.>
> >
> > libxl: passthrough: avoid passing through devices not owned by pciback
> 
> I'm afraid this no longer applies to xen-unstable.hg tip.
> 
Reason?

If no pciback checking, one device could be assigned to guest even it's being used by dom0, is there security issue?

Thanks,
-Xudong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 01:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 01:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFbGd-0007k4-96; Thu, 05 Apr 2012 01:13:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SFbGb-0007jz-JD
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 01:13:37 +0000
Received: from [85.158.138.51:14699] by server-9.bemta-3.messagelabs.com id
	11/BE-10923-0C1FC7F4; Thu, 05 Apr 2012 01:13:36 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333588415!19032694!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU4MDk0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10062 invoked from network); 5 Apr 2012 01:13:36 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 01:13:36 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 04 Apr 2012 18:13:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="85464160"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 04 Apr 2012 18:13:33 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 4 Apr 2012 18:13:33 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 5 Apr 2012 09:13:31 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNEPImuKVWc2YDX0uKv0mNtPrh5JaLb5NQ
Date: Thu, 5 Apr 2012 01:13:30 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
In-Reply-To: <20345.56112.630128.747571@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Tuesday, April 03, 2012 1:01 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> > <Porting from Xen 4.1 tree.>
> >
> > libxl: passthrough: avoid passing through devices not owned by pciback
> 
> I'm afraid this no longer applies to xen-unstable.hg tip.
> 
Reason?

If no pciback checking, one device could be assigned to guest even it's being used by dom0, is there security issue?

Thanks,
-Xudong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 01:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 01:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFbYf-0007uZ-VW; Thu, 05 Apr 2012 01:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFbYe-0007uU-RW
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 01:32:17 +0000
Received: from [85.158.143.99:41699] by server-1.bemta-4.messagelabs.com id
	68/A9-20925-026FC7F4; Thu, 05 Apr 2012 01:32:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333589535!22090703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29423 invoked from network); 5 Apr 2012 01:32:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 01:32:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,372,1330905600"; d="scan'208";a="11781254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 01:32:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 02:32:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFbYc-0005XG-At;
	Thu, 05 Apr 2012 01:32:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFbYc-0001Xg-85;
	Thu, 05 Apr 2012 02:32:14 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12565-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 02:32:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12565: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12565 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12565/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 01:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 01:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFbYf-0007uZ-VW; Thu, 05 Apr 2012 01:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFbYe-0007uU-RW
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 01:32:17 +0000
Received: from [85.158.143.99:41699] by server-1.bemta-4.messagelabs.com id
	68/A9-20925-026FC7F4; Thu, 05 Apr 2012 01:32:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333589535!22090703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29423 invoked from network); 5 Apr 2012 01:32:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 01:32:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,372,1330905600"; d="scan'208";a="11781254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 01:32:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 02:32:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFbYc-0005XG-At;
	Thu, 05 Apr 2012 01:32:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFbYc-0001Xg-85;
	Thu, 05 Apr 2012 02:32:14 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12565-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 02:32:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12565: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12565 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12565/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 06:32:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 06:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFgE2-00015c-RH; Thu, 05 Apr 2012 06:31:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFgE1-00015X-3B
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 06:31:17 +0000
Received: from [85.158.139.83:9099] by server-11.bemta-5.messagelabs.com id
	A1/EC-12959-43C3D7F4; Thu, 05 Apr 2012 06:31:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333607475!22565343!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2782 invoked from network); 5 Apr 2012 06:31:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 06:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="11782998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 06:31:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 07:31:15 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFgDy-0007qe-Lu;
	Thu, 05 Apr 2012 06:31:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFgDy-0004Fs-Lc;
	Thu, 05 Apr 2012 07:31:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12566-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 07:31:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12566: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12566 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12566/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 5230
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail blocked in 5230

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass

version targeted for testing:
 xen                  cbe8948799bf
baseline version:
 xen                  9b453f96dd46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 06:32:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 06:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFgE2-00015c-RH; Thu, 05 Apr 2012 06:31:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFgE1-00015X-3B
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 06:31:17 +0000
Received: from [85.158.139.83:9099] by server-11.bemta-5.messagelabs.com id
	A1/EC-12959-43C3D7F4; Thu, 05 Apr 2012 06:31:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333607475!22565343!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2782 invoked from network); 5 Apr 2012 06:31:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 06:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="11782998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 06:31:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 07:31:15 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFgDy-0007qe-Lu;
	Thu, 05 Apr 2012 06:31:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFgDy-0004Fs-Lc;
	Thu, 05 Apr 2012 07:31:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12566-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 07:31:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12566: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12566 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12566/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 5230
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail blocked in 5230

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass

version targeted for testing:
 xen                  cbe8948799bf
baseline version:
 xen                  9b453f96dd46

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 07:29:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 07:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFh7O-0001lo-3j; Thu, 05 Apr 2012 07:28:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1SFh7M-0001li-Br
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 07:28:28 +0000
Received: from [85.158.143.99:15253] by server-1.bemta-4.messagelabs.com id
	EB/22-20925-B994D7F4; Thu, 05 Apr 2012 07:28:27 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1333610906!16066364!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31169 invoked from network); 5 Apr 2012 07:28:27 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 07:28:27 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id ED3EC9290E;
	Thu,  5 Apr 2012 09:28:25 +0200 (CEST)
Message-ID: <4F7D4998.8000000@suse.de>
Date: Thu, 05 Apr 2012 09:28:24 +0200
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <20120403173224.GA22140@aepfle.de>
	<20348.26046.686582.18393@mariner.uk.xensource.com>
	<CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
	<CAFEAcA-h2vQdYNNBTb_2hXEHZsK9023V9dVJLL9AvybuejBb_Q@mail.gmail.com>
In-Reply-To: <CAFEAcA-h2vQdYNNBTb_2hXEHZsK9023V9dVJLL9AvybuejBb_Q@mail.gmail.com>
X-Enigmail-Version: 1.4
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QW0gMDQuMDQuMjAxMiAxODowOSwgc2NocmllYiBQZXRlciBNYXlkZWxsOgo+IE9uIDQgQXByaWwg
MjAxMiAxNjo0MCwgUGV0ZXIgTWF5ZGVsbCA8cGV0ZXIubWF5ZGVsbEBsaW5hcm8ub3JnPiB3cm90
ZToKPj4gSGF2aW5nIGxvb2tlZCBhdCBjb25maWd1cmUgSSdtIHByZXR0eSBzdXJlIHdoYXQgd2Ug
d2FudCBoZXJlIGlzCj4+ICBRRU1VX0NGTEFHUz0iLW1hcmNoPWk0ODYgJFFFTVVfQ0ZMQUdTIgo+
Pgo+PiBiZWNhdXNlIHdlJ3JlIG9ubHkgZG9pbmcgdGhpcyBmb3IgdGhlIGJlbmVmaXQgb2YgYSBw
YXJ0aWN1bGFyIGJpdAo+PiBvZiBjb2RlIGluIGh3L3Zob3N0LmMgYW5kIHNvIFFFTVVfQ0ZMQUdT
IGlzIHN1ZmZpY2llbnQuIEFsc28gdGhpcwo+PiBicmluZ3MgaXQgaW50byBsaW5lIHdpdGggb3Ro
ZXIgcGxhY2VzIHdoZXJlIHdlIGFkZCBhIC1tYXJjaCBmbGFnLAo+PiB3aGljaCB1c2UgUUVNVV9D
RkxBR1MsIG5vdCBDRkxBR1MuCj4gCj4gLi4uYW5kIGhhdmluZyBkdWcgYXJvdW5kIGluIHRoZSBn
aXQgaGlzdG9yeSB3ZSBmaW5kIHRoYXQgUUVNVV9DRkxBR1MKPiB3ZXJlIGludHJvZHVjZWQgaW4g
Y29tbWl0IGE1NThlZTEsIHdob3NlIGNvbW1pdCBtZXNzYWdlIGRlZmluZXMgdGhlCj4gZGlmZmVy
ZW5jZSBsaWtlIHRoaXM6Cj4gICAgIFFFTVVfQ0ZMQUdTOiBmbGFncyB3aXRob3V0IHdoaWNoIHdl
IGNhbid0IGNvbXBpbGUKPiAgICAgQ0ZMQUdTOiAiLWcgLU8yIgo+IAo+ICItbWFyY2g9aTQ4NiIg
aXMgY2xlYXJseSAiZmxhZ3Mgd2l0aG91dCB3aGljaCB3ZSBjYW4ndCBjb21waWxlIiwKPiBzbyB3
ZSBzaG91bGQgYmUgc2V0dGluZyBpdCBpbiBRRU1VX0NGTEFHUywgbm90IENGTEFHUy4KPiAKPiBP
bGFmLCBpZiB5b3Ugd2FudCB0byBzdWJtaXQgYSBmaXhlZCBwYXRjaCBJIHRoaW5rIHdlIHNob3Vs
ZCBhcHBseQo+IGl0IHRvIHVwc3RyZWFtIHFlbXUuCj4gCj4gUFM6IHJlbWFya3MgbGlrZQo+ICJU
aGlzIHBhdGNoIGlzIGFnYWluc3QgdGhlIHFlbXUteGVuIHRyZWUsIGJ1dCBpdCBzaG91bGQgYXBw
bHkgYWxzbyB0bwo+IHFlbXUuZ2l0IHNpbmNlIGl0IGhhcyB0aGUgc2FtZSBpc3N1ZS4gUGxlYXNl
IGFwcGx5IHRvIGJvdGggdHJlZXMuIgo+IAo+IHNob3VsZCBnbyBiZWxvdyB0aGUgJy0tLScgaW4g
YSBwYXRjaCBlbWFpbCBzbyB0aGV5IGRvbid0IGFwcGVhcgo+IGluIHRoZSBnaXQgY29tbWl0IG1l
c3NhZ2Ugd2hlbiB0aGUgcGF0Y2ggaXMgYXBwbGllZC4KCkFuZCB5b3UgYWxzbyBmb3Jnb3QgdG8g
dXBkYXRlIHRoZSBzdWJqZWN0IHRvIHNvbWV0aGluZyBsaWtlOgoiY29uZmlndXJlOiBGaXggQ0ZM
QUdTIGhhbmRsaW5nIGZvciBpMzg2IiAtIHRoaXMgaXMgZm9yIHRoZSBRRU1VCnJlcG9zaXRvcnkg
YWZ0ZXIgYWxsLCBzbyBubyBuZWVkIHRvIHB1dCB0aGF0IGludG8gdGhlIGNvbW1pdCBtZXNzYWdl
LgoKQW5kcmVhcwoKLS0gClNVU0UgTElOVVggUHJvZHVjdHMgR21iSCwgTWF4ZmVsZHN0ci4gNSwg
OTA0MDkgTsO8cm5iZXJnLCBHZXJtYW55CkdGOiBKZWZmIEhhd24sIEplbm5pZmVyIEd1aWxkLCBG
ZWxpeCBJbWVuZMO2cmZmZXI7IEhSQiAxNjc0NiBBRyBOw7xybmJlcmcKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Apr 05 07:29:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 07:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFh7O-0001lo-3j; Thu, 05 Apr 2012 07:28:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1SFh7M-0001li-Br
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 07:28:28 +0000
Received: from [85.158.143.99:15253] by server-1.bemta-4.messagelabs.com id
	EB/22-20925-B994D7F4; Thu, 05 Apr 2012 07:28:27 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1333610906!16066364!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31169 invoked from network); 5 Apr 2012 07:28:27 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 07:28:27 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id ED3EC9290E;
	Thu,  5 Apr 2012 09:28:25 +0200 (CEST)
Message-ID: <4F7D4998.8000000@suse.de>
Date: Thu, 05 Apr 2012 09:28:24 +0200
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <20120403173224.GA22140@aepfle.de>
	<20348.26046.686582.18393@mariner.uk.xensource.com>
	<CAFEAcA839S=YEXdL+TM1Wo7TWJRxZ1rxhLmf_HCb+Y3qukmi-g@mail.gmail.com>
	<CAFEAcA-h2vQdYNNBTb_2hXEHZsK9023V9dVJLL9AvybuejBb_Q@mail.gmail.com>
In-Reply-To: <CAFEAcA-h2vQdYNNBTb_2hXEHZsK9023V9dVJLL9AvybuejBb_Q@mail.gmail.com>
X-Enigmail-Version: 1.4
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] qemu/configure: fix CFLAGS
 handling for i386
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QW0gMDQuMDQuMjAxMiAxODowOSwgc2NocmllYiBQZXRlciBNYXlkZWxsOgo+IE9uIDQgQXByaWwg
MjAxMiAxNjo0MCwgUGV0ZXIgTWF5ZGVsbCA8cGV0ZXIubWF5ZGVsbEBsaW5hcm8ub3JnPiB3cm90
ZToKPj4gSGF2aW5nIGxvb2tlZCBhdCBjb25maWd1cmUgSSdtIHByZXR0eSBzdXJlIHdoYXQgd2Ug
d2FudCBoZXJlIGlzCj4+ICBRRU1VX0NGTEFHUz0iLW1hcmNoPWk0ODYgJFFFTVVfQ0ZMQUdTIgo+
Pgo+PiBiZWNhdXNlIHdlJ3JlIG9ubHkgZG9pbmcgdGhpcyBmb3IgdGhlIGJlbmVmaXQgb2YgYSBw
YXJ0aWN1bGFyIGJpdAo+PiBvZiBjb2RlIGluIGh3L3Zob3N0LmMgYW5kIHNvIFFFTVVfQ0ZMQUdT
IGlzIHN1ZmZpY2llbnQuIEFsc28gdGhpcwo+PiBicmluZ3MgaXQgaW50byBsaW5lIHdpdGggb3Ro
ZXIgcGxhY2VzIHdoZXJlIHdlIGFkZCBhIC1tYXJjaCBmbGFnLAo+PiB3aGljaCB1c2UgUUVNVV9D
RkxBR1MsIG5vdCBDRkxBR1MuCj4gCj4gLi4uYW5kIGhhdmluZyBkdWcgYXJvdW5kIGluIHRoZSBn
aXQgaGlzdG9yeSB3ZSBmaW5kIHRoYXQgUUVNVV9DRkxBR1MKPiB3ZXJlIGludHJvZHVjZWQgaW4g
Y29tbWl0IGE1NThlZTEsIHdob3NlIGNvbW1pdCBtZXNzYWdlIGRlZmluZXMgdGhlCj4gZGlmZmVy
ZW5jZSBsaWtlIHRoaXM6Cj4gICAgIFFFTVVfQ0ZMQUdTOiBmbGFncyB3aXRob3V0IHdoaWNoIHdl
IGNhbid0IGNvbXBpbGUKPiAgICAgQ0ZMQUdTOiAiLWcgLU8yIgo+IAo+ICItbWFyY2g9aTQ4NiIg
aXMgY2xlYXJseSAiZmxhZ3Mgd2l0aG91dCB3aGljaCB3ZSBjYW4ndCBjb21waWxlIiwKPiBzbyB3
ZSBzaG91bGQgYmUgc2V0dGluZyBpdCBpbiBRRU1VX0NGTEFHUywgbm90IENGTEFHUy4KPiAKPiBP
bGFmLCBpZiB5b3Ugd2FudCB0byBzdWJtaXQgYSBmaXhlZCBwYXRjaCBJIHRoaW5rIHdlIHNob3Vs
ZCBhcHBseQo+IGl0IHRvIHVwc3RyZWFtIHFlbXUuCj4gCj4gUFM6IHJlbWFya3MgbGlrZQo+ICJU
aGlzIHBhdGNoIGlzIGFnYWluc3QgdGhlIHFlbXUteGVuIHRyZWUsIGJ1dCBpdCBzaG91bGQgYXBw
bHkgYWxzbyB0bwo+IHFlbXUuZ2l0IHNpbmNlIGl0IGhhcyB0aGUgc2FtZSBpc3N1ZS4gUGxlYXNl
IGFwcGx5IHRvIGJvdGggdHJlZXMuIgo+IAo+IHNob3VsZCBnbyBiZWxvdyB0aGUgJy0tLScgaW4g
YSBwYXRjaCBlbWFpbCBzbyB0aGV5IGRvbid0IGFwcGVhcgo+IGluIHRoZSBnaXQgY29tbWl0IG1l
c3NhZ2Ugd2hlbiB0aGUgcGF0Y2ggaXMgYXBwbGllZC4KCkFuZCB5b3UgYWxzbyBmb3Jnb3QgdG8g
dXBkYXRlIHRoZSBzdWJqZWN0IHRvIHNvbWV0aGluZyBsaWtlOgoiY29uZmlndXJlOiBGaXggQ0ZM
QUdTIGhhbmRsaW5nIGZvciBpMzg2IiAtIHRoaXMgaXMgZm9yIHRoZSBRRU1VCnJlcG9zaXRvcnkg
YWZ0ZXIgYWxsLCBzbyBubyBuZWVkIHRvIHB1dCB0aGF0IGludG8gdGhlIGNvbW1pdCBtZXNzYWdl
LgoKQW5kcmVhcwoKLS0gClNVU0UgTElOVVggUHJvZHVjdHMgR21iSCwgTWF4ZmVsZHN0ci4gNSwg
OTA0MDkgTsO8cm5iZXJnLCBHZXJtYW55CkdGOiBKZWZmIEhhd24sIEplbm5pZmVyIEd1aWxkLCBG
ZWxpeCBJbWVuZMO2cmZmZXI7IEhSQiAxNjc0NiBBRyBOw7xybmJlcmcKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Apr 05 08:07:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 08:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFhik-0002sR-F6; Thu, 05 Apr 2012 08:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SFhij-0002sM-2k
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 08:07:05 +0000
Received: from [85.158.138.51:51489] by server-10.bemta-3.messagelabs.com id
	4C/EB-15637-8A25D7F4; Thu, 05 Apr 2012 08:07:04 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333613221!20752254!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20817 invoked from network); 5 Apr 2012 08:07:03 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 08:07:03 -0000
Received: by qcsp15 with SMTP id p15so823168qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Apr 2012 01:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RrYt0JHvpap3a/itam44V5x8nft17p6uSx53myInjyE=;
	b=1Abp6g/gNoqmye8q/BgaUf18ByLqQOtI/q6iSx1XeUMq9CKl47BjXY2aQzeWA36xtp
	PzMzQOaZq1pDAYaQ3rVi4842iNKba37gK1tClXl/jE2l8Oat2mQKvE0NSHEHLeH9XQqR
	3CYK6BYy4aQE1YfAEPReA9C5UbZ533j9YQ3RPOg6Zkz39Hsf1XbNqJcqYZJPV1Rfc3s9
	oBwwEdavG4cCc7z91TyCEw6cTkEgvAICyxcNX8KKqFwm/VEcTtw6Q2qmtajdgP8PsN9T
	TrePIqRyqbwUZfOfhWcwh4C+Gh3Fuuhdn95tNmiVTGUsYR2I92hpQ7vKotIZr5sMqaSf
	gXMA==
MIME-Version: 1.0
Received: by 10.224.210.10 with SMTP id gi10mr2725604qab.47.1333613221182;
	Thu, 05 Apr 2012 01:07:01 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 5 Apr 2012 01:07:01 -0700 (PDT)
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
Date: Thu, 5 Apr 2012 09:07:01 +0100
X-Google-Sender-Auth: bdgYK68dFknotKGA-zLbG0blVq8
Message-ID: <CAFLBxZaQ4kjadTbgX0DTPhcr-azLdA1om7Yth7G7adBW17dFLg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Cc: "Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 5, 2012 at 2:13 AM, Hao, Xudong <xudong.hao@intel.com> wrote:
>
>> -----Original Message-----
>> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
>> Sent: Tuesday, April 03, 2012 1:01 AM
>> To: Hao, Xudong
>> Cc: xen-devel@lists.xensource.com; Kay, Allen M
>> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
>> devices not owned by pciback
>>
>> Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing
>> through devices not owned by pciback"):
>> > <Porting from Xen 4.1 tree.>
>> >
>> > libxl: passthrough: avoid passing through devices not owned by pciback
>>
>> I'm afraid this no longer applies to xen-unstable.hg tip.
>>
> Reason?
>
> If no pciback checking, one device could be assigned to guest even it's being used by dom0, is there security issue?

I think Ian is saying that the actual patch itself doesn't apply. That is,

$ patch -p1 < passthru.diff

fails; so he's asking you to send a new version of the patch.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 08:07:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 08:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFhik-0002sR-F6; Thu, 05 Apr 2012 08:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SFhij-0002sM-2k
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 08:07:05 +0000
Received: from [85.158.138.51:51489] by server-10.bemta-3.messagelabs.com id
	4C/EB-15637-8A25D7F4; Thu, 05 Apr 2012 08:07:04 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333613221!20752254!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20817 invoked from network); 5 Apr 2012 08:07:03 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 08:07:03 -0000
Received: by qcsp15 with SMTP id p15so823168qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Apr 2012 01:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RrYt0JHvpap3a/itam44V5x8nft17p6uSx53myInjyE=;
	b=1Abp6g/gNoqmye8q/BgaUf18ByLqQOtI/q6iSx1XeUMq9CKl47BjXY2aQzeWA36xtp
	PzMzQOaZq1pDAYaQ3rVi4842iNKba37gK1tClXl/jE2l8Oat2mQKvE0NSHEHLeH9XQqR
	3CYK6BYy4aQE1YfAEPReA9C5UbZ533j9YQ3RPOg6Zkz39Hsf1XbNqJcqYZJPV1Rfc3s9
	oBwwEdavG4cCc7z91TyCEw6cTkEgvAICyxcNX8KKqFwm/VEcTtw6Q2qmtajdgP8PsN9T
	TrePIqRyqbwUZfOfhWcwh4C+Gh3Fuuhdn95tNmiVTGUsYR2I92hpQ7vKotIZr5sMqaSf
	gXMA==
MIME-Version: 1.0
Received: by 10.224.210.10 with SMTP id gi10mr2725604qab.47.1333613221182;
	Thu, 05 Apr 2012 01:07:01 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 5 Apr 2012 01:07:01 -0700 (PDT)
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
Date: Thu, 5 Apr 2012 09:07:01 +0100
X-Google-Sender-Auth: bdgYK68dFknotKGA-zLbG0blVq8
Message-ID: <CAFLBxZaQ4kjadTbgX0DTPhcr-azLdA1om7Yth7G7adBW17dFLg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Cc: "Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 5, 2012 at 2:13 AM, Hao, Xudong <xudong.hao@intel.com> wrote:
>
>> -----Original Message-----
>> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
>> Sent: Tuesday, April 03, 2012 1:01 AM
>> To: Hao, Xudong
>> Cc: xen-devel@lists.xensource.com; Kay, Allen M
>> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
>> devices not owned by pciback
>>
>> Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing
>> through devices not owned by pciback"):
>> > <Porting from Xen 4.1 tree.>
>> >
>> > libxl: passthrough: avoid passing through devices not owned by pciback
>>
>> I'm afraid this no longer applies to xen-unstable.hg tip.
>>
> Reason?
>
> If no pciback checking, one device could be assigned to guest even it's being used by dom0, is there security issue?

I think Ian is saying that the actual patch itself doesn't apply. That is,

$ patch -p1 < passthru.diff

fails; so he's asking you to send a new version of the patch.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 08:45:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 08:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFiIp-00038n-Gz; Thu, 05 Apr 2012 08:44:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFiIn-00038i-DK
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 08:44:21 +0000
Received: from [85.158.138.51:28539] by server-11.bemta-3.messagelabs.com id
	F3/DC-28543-46B5D7F4; Thu, 05 Apr 2012 08:44:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333615458!20930960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6242 invoked from network); 5 Apr 2012 08:44:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 08:44:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="11785889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:44:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 09:44:17 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFiIj-0000T1-Lk;
	Thu, 05 Apr 2012 08:44:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFiIj-000066-Ei;
	Thu, 05 Apr 2012 09:44:17 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12567-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 09:44:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12567: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12567 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12567/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-xl-credit2   10 guest-saverestore       fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 08:45:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 08:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFiIp-00038n-Gz; Thu, 05 Apr 2012 08:44:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFiIn-00038i-DK
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 08:44:21 +0000
Received: from [85.158.138.51:28539] by server-11.bemta-3.messagelabs.com id
	F3/DC-28543-46B5D7F4; Thu, 05 Apr 2012 08:44:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333615458!20930960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6242 invoked from network); 5 Apr 2012 08:44:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 08:44:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="11785889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:44:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 09:44:17 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFiIj-0000T1-Lk;
	Thu, 05 Apr 2012 08:44:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFiIj-000066-Ei;
	Thu, 05 Apr 2012 09:44:17 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12567-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 09:44:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12567: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12567 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12567/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-xl-credit2   10 guest-saverestore       fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 08:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 08:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFiJU-0003Ac-Uh; Thu, 05 Apr 2012 08:45:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SFiJT-0003AL-3r
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 08:45:03 +0000
Received: from [193.109.254.147:51361] by server-1.bemta-14.messagelabs.com id
	CE/1E-29372-E8B5D7F4; Thu, 05 Apr 2012 08:45:02 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1333615497!3334906!1
X-Originating-IP: [202.81.31.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MiA9PiAxNjE0MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5895 invoked from network); 5 Apr 2012 08:45:01 -0000
Received: from e23smtp09.au.ibm.com (HELO e23smtp09.au.ibm.com) (202.81.31.142)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 08:45:01 -0000
Received: from /spool/local
	by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 5 Apr 2012 09:34:32 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 5 Apr 2012 09:34:27 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q358cPt93670040
	for <xen-devel@lists.xensource.com>; Thu, 5 Apr 2012 18:38:28 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q358iegu002479
	for <xen-devel@lists.xensource.com>; Thu, 5 Apr 2012 18:44:42 +1000
Received: from [9.124.158.108] (codeblue.in.ibm.com [9.124.158.108])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q358ibqu002347; Thu, 5 Apr 2012 18:44:37 +1000
Message-ID: <4F7D5B4C.3040906@linux.vnet.ibm.com>
Date: Thu, 05 Apr 2012 14:13:56 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@elte.hu>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
In-Reply-To: <4F785DCF.7020809@redhat.com>
x-cbid: 12040423-3568-0000-0000-000001793B87
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 07:23 PM, Avi Kivity wrote:
> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>>> I have patch something like below in mind to try:
>>>>
>>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>>> index d3b98b1..5127668 100644
>>>> --- a/virt/kvm/kvm_main.c
>>>> +++ b/virt/kvm/kvm_main.c
>>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>>         * else and called schedule in __vcpu_run.  Hopefully that
>>>>         * VCPU is holding the lock that we need and will release it.
>>>>         * We approximate round-robin by starting at the last boosted
>>>> VCPU.
>>>> +     * Priority is given to vcpu that are unhalted.
>>>>         */
>>>> -    for (pass = 0; pass<   2&&   !yielded; pass++) {
>>>> +    for (pass = 0; pass<   3&&   !yielded; pass++) {
>>>>            kvm_for_each_vcpu(i, vcpu, kvm) {
>>>>                struct task_struct *task = NULL;
>>>>                struct pid *pid;
>>>> -            if (!pass&&   i<   last_boosted_vcpu) {
>>>> +            if (!pass&&   !vcpu->pv_unhalted)
>>>> +                continue;
>>>> +            else if (pass == 1&&   i<   last_boosted_vcpu) {
>>>>                    i = last_boosted_vcpu;
>>>>                    continue;
>>>> -            } else if (pass&&   i>   last_boosted_vcpu)
>>>> +            } else if (pass == 2&&   i>   last_boosted_vcpu)
>>>>                    break;
>>>>                if (vcpu == me)
>>>>                    continue;
>>>>
>>>

[...]

> I'm interested in how PLE does vs. your patches, both with PLE enabled
> and disabled.
>

  Here is the result taken on PLE machine. Results seem to support all 
our assumptions.
  Following are the observations from results:

  1) There is a huge benefit for Non PLE based configuration. 
(base_nople vs pv_ple) (around 90%)

  2) ticketlock + kvm patches does go well along with PLE (more benefit 
is seen not degradation)
	(base_ple vs pv_ple)

  3) The ticketlock + kvm patches make behaves almost like PLE enabled 
machine (base_ple vs pv_nople)

  4) ple handler modification patches seem to give advantage (pv_ple vs 
pv_ple_optimized). More study needed
     probably with higher M/N ratio Avi pointed.

  configurations:

  base_nople       = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=n - PLE
  base_ple         = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=n  + PLE
  pv_ple           = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=y + PLE + 
ticketlock + kvm patches
  pv_nople         = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=y - PLE + 
ticketlock + kvm patches
  pv_ple_optimized = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=y + PLE + 
optimizaton patch + ticketlock
			+ kvm patches + posted with ple_handler modification (yield to kicked 
vcpu).

  Machine : IBM xSeries with Intel(R) Xeon(R)  X7560 2.27GHz CPU with 32 
core, with 8
          online cores and 4*64GB RAM

  3 guests running with 2GB RAM, 8vCPU.

  Results:
  -------
  case A)
  1x: 1 kernbench 2 idle
  2x: 1 kernbench 1 while1 hog 1 idle
  3x: 1 kernbench 2 while1 hog

  Average time taken in sec for kernbench run (std). [ lower the value 
better ]

       base_nople                 base_ple              pv_ple 
       pv_nople           pv_ple_optimized
	
  1x   72.8284 (89.8757) 	 70.475 (85.6979) 	63.5033 (72.7041) 
65.7634 (77.0504)  64.3284 (73.2688)
  2x   823.053 (1113.05) 	 110.971 (132.829) 	105.099 (128.738) 
139.058 (165.156)  106.268 (129.611)
  3x   3244.37 (4707.61) 	 150.265 (184.766) 	138.341 (172.69) 
139.106 (163.549)  133.238 (168.388)


    Percentage improvement calculation w.r.t base_nople
    -------------------------------------------------

       base_ple  pv_ple    pv_nople pv_ple_optimized

  1x    3.23143  12.8042   9.70089   11.6713
  2x    86.5172  87.2306   83.1046   87.0886
  3x    95.3684  95.736    95.7124   95.8933

-------------------
    Percentage improvement calculation w.r.t base_ple
    -------------------------------------------------

       base_nople  pv_ple    pv_nople  pv_ple_optimized

   1x   -3.3393    9.89244   6.68549   8.72167
   2x   -641.683   5.29147   -25.3102  4.23804
   3x   -2059.1    7.93531   7.42621   11.3313


  case B)
  all 3 guests running kernbench
  Average time taken in sec for kernbench run (std). [ lower the value 
better ].
  Note that std is calculated over 6*3 run average from all 3 guests 
given by kernbench

  base_nople            base_ple                pv_ple 
pv_nople              pv_ple_opt
  2886.92 (18.289131)   204.80333 (7.1784039)   200.22517 (10.134804) 
202.091 (12.249673)   201.60683 (7.881737)


    Percentage improvement calculation w.r.t base_nople
    -------------------------------------------------

       base_ple   pv_ple    pv_nople   pv_ple_optimized
       92.9058    93.0644   93	     93.0166
	


    Percentage improvement calculation w.r.t base_ple
    -------------------------------------------------

       base_nople   pv_ple    pv_nople   pv_ple_optimized
       -1309.606	   2.2354    1.324      1.5607	

  I hope the experimental results should convey same message if somebody 
does benchmarking.

  Also as Ian pointed in the thread, the earlier results from Attilio
and me was to convince that framework is acceptable on native.

  Does this convince to consider for it to go to next merge window?

  comments /suggestions please...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 08:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 08:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFiJU-0003Ac-Uh; Thu, 05 Apr 2012 08:45:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SFiJT-0003AL-3r
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 08:45:03 +0000
Received: from [193.109.254.147:51361] by server-1.bemta-14.messagelabs.com id
	CE/1E-29372-E8B5D7F4; Thu, 05 Apr 2012 08:45:02 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1333615497!3334906!1
X-Originating-IP: [202.81.31.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MiA9PiAxNjE0MDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5895 invoked from network); 5 Apr 2012 08:45:01 -0000
Received: from e23smtp09.au.ibm.com (HELO e23smtp09.au.ibm.com) (202.81.31.142)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 08:45:01 -0000
Received: from /spool/local
	by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 5 Apr 2012 09:34:32 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 5 Apr 2012 09:34:27 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q358cPt93670040
	for <xen-devel@lists.xensource.com>; Thu, 5 Apr 2012 18:38:28 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q358iegu002479
	for <xen-devel@lists.xensource.com>; Thu, 5 Apr 2012 18:44:42 +1000
Received: from [9.124.158.108] (codeblue.in.ibm.com [9.124.158.108])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q358ibqu002347; Thu, 5 Apr 2012 18:44:37 +1000
Message-ID: <4F7D5B4C.3040906@linux.vnet.ibm.com>
Date: Thu, 05 Apr 2012 14:13:56 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@elte.hu>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
In-Reply-To: <4F785DCF.7020809@redhat.com>
x-cbid: 12040423-3568-0000-0000-000001793B87
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/01/2012 07:23 PM, Avi Kivity wrote:
> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>>> I have patch something like below in mind to try:
>>>>
>>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>>> index d3b98b1..5127668 100644
>>>> --- a/virt/kvm/kvm_main.c
>>>> +++ b/virt/kvm/kvm_main.c
>>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>>         * else and called schedule in __vcpu_run.  Hopefully that
>>>>         * VCPU is holding the lock that we need and will release it.
>>>>         * We approximate round-robin by starting at the last boosted
>>>> VCPU.
>>>> +     * Priority is given to vcpu that are unhalted.
>>>>         */
>>>> -    for (pass = 0; pass<   2&&   !yielded; pass++) {
>>>> +    for (pass = 0; pass<   3&&   !yielded; pass++) {
>>>>            kvm_for_each_vcpu(i, vcpu, kvm) {
>>>>                struct task_struct *task = NULL;
>>>>                struct pid *pid;
>>>> -            if (!pass&&   i<   last_boosted_vcpu) {
>>>> +            if (!pass&&   !vcpu->pv_unhalted)
>>>> +                continue;
>>>> +            else if (pass == 1&&   i<   last_boosted_vcpu) {
>>>>                    i = last_boosted_vcpu;
>>>>                    continue;
>>>> -            } else if (pass&&   i>   last_boosted_vcpu)
>>>> +            } else if (pass == 2&&   i>   last_boosted_vcpu)
>>>>                    break;
>>>>                if (vcpu == me)
>>>>                    continue;
>>>>
>>>

[...]

> I'm interested in how PLE does vs. your patches, both with PLE enabled
> and disabled.
>

  Here is the result taken on PLE machine. Results seem to support all 
our assumptions.
  Following are the observations from results:

  1) There is a huge benefit for Non PLE based configuration. 
(base_nople vs pv_ple) (around 90%)

  2) ticketlock + kvm patches does go well along with PLE (more benefit 
is seen not degradation)
	(base_ple vs pv_ple)

  3) The ticketlock + kvm patches make behaves almost like PLE enabled 
machine (base_ple vs pv_nople)

  4) ple handler modification patches seem to give advantage (pv_ple vs 
pv_ple_optimized). More study needed
     probably with higher M/N ratio Avi pointed.

  configurations:

  base_nople       = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=n - PLE
  base_ple         = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=n  + PLE
  pv_ple           = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=y + PLE + 
ticketlock + kvm patches
  pv_nople         = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=y - PLE + 
ticketlock + kvm patches
  pv_ple_optimized = 3.3-rc6 with CONFIG_PARAVIRT_SPINLOCK=y + PLE + 
optimizaton patch + ticketlock
			+ kvm patches + posted with ple_handler modification (yield to kicked 
vcpu).

  Machine : IBM xSeries with Intel(R) Xeon(R)  X7560 2.27GHz CPU with 32 
core, with 8
          online cores and 4*64GB RAM

  3 guests running with 2GB RAM, 8vCPU.

  Results:
  -------
  case A)
  1x: 1 kernbench 2 idle
  2x: 1 kernbench 1 while1 hog 1 idle
  3x: 1 kernbench 2 while1 hog

  Average time taken in sec for kernbench run (std). [ lower the value 
better ]

       base_nople                 base_ple              pv_ple 
       pv_nople           pv_ple_optimized
	
  1x   72.8284 (89.8757) 	 70.475 (85.6979) 	63.5033 (72.7041) 
65.7634 (77.0504)  64.3284 (73.2688)
  2x   823.053 (1113.05) 	 110.971 (132.829) 	105.099 (128.738) 
139.058 (165.156)  106.268 (129.611)
  3x   3244.37 (4707.61) 	 150.265 (184.766) 	138.341 (172.69) 
139.106 (163.549)  133.238 (168.388)


    Percentage improvement calculation w.r.t base_nople
    -------------------------------------------------

       base_ple  pv_ple    pv_nople pv_ple_optimized

  1x    3.23143  12.8042   9.70089   11.6713
  2x    86.5172  87.2306   83.1046   87.0886
  3x    95.3684  95.736    95.7124   95.8933

-------------------
    Percentage improvement calculation w.r.t base_ple
    -------------------------------------------------

       base_nople  pv_ple    pv_nople  pv_ple_optimized

   1x   -3.3393    9.89244   6.68549   8.72167
   2x   -641.683   5.29147   -25.3102  4.23804
   3x   -2059.1    7.93531   7.42621   11.3313


  case B)
  all 3 guests running kernbench
  Average time taken in sec for kernbench run (std). [ lower the value 
better ].
  Note that std is calculated over 6*3 run average from all 3 guests 
given by kernbench

  base_nople            base_ple                pv_ple 
pv_nople              pv_ple_opt
  2886.92 (18.289131)   204.80333 (7.1784039)   200.22517 (10.134804) 
202.091 (12.249673)   201.60683 (7.881737)


    Percentage improvement calculation w.r.t base_nople
    -------------------------------------------------

       base_ple   pv_ple    pv_nople   pv_ple_optimized
       92.9058    93.0644   93	     93.0166
	


    Percentage improvement calculation w.r.t base_ple
    -------------------------------------------------

       base_nople   pv_ple    pv_nople   pv_ple_optimized
       -1309.606	   2.2354    1.324      1.5607	

  I hope the experimental results should convey same message if somebody 
does benchmarking.

  Also as Ian pointed in the thread, the earlier results from Attilio
and me was to convince that framework is acceptable on native.

  Does this convince to consider for it to go to next merge window?

  comments /suggestions please...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:08:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:08:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFig4-0003WF-6O; Thu, 05 Apr 2012 09:08:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SFig3-0003WA-0a
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:08:23 +0000
Received: from [85.158.138.51:54024] by server-10.bemta-3.messagelabs.com id
	EC/6C-15637-6016D7F4; Thu, 05 Apr 2012 09:08:22 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333616900!20867644!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5OTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9965 invoked from network); 5 Apr 2012 09:08:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 09:08:21 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3597rLb005854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 05:07:54 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3591FYH014283; Thu, 5 Apr 2012 05:01:16 -0400
Message-ID: <4F7D5F5B.2020209@redhat.com>
Date: Thu, 05 Apr 2012 12:01:15 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
	<4F7976B6.5050000@linux.vnet.ibm.com>
In-Reply-To: <4F7976B6.5050000@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/02/2012 12:51 PM, Raghavendra K T wrote:
> On 04/01/2012 07:23 PM, Avi Kivity wrote:
> > On 04/01/2012 04:48 PM, Raghavendra K T wrote:
> >>>> I have patch something like below in mind to try:
> >>>>
> >>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> >>>> index d3b98b1..5127668 100644
> >>>> --- a/virt/kvm/kvm_main.c
> >>>> +++ b/virt/kvm/kvm_main.c
> >>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
> >>>>         * else and called schedule in __vcpu_run.  Hopefully that
> >>>>         * VCPU is holding the lock that we need and will release it.
> >>>>         * We approximate round-robin by starting at the last boosted
> >>>> VCPU.
> >>>> +     * Priority is given to vcpu that are unhalted.
> >>>>         */
> >>>> -    for (pass = 0; pass<   2&&   !yielded; pass++) {
> >>>> +    for (pass = 0; pass<   3&&   !yielded; pass++) {
> >>>>            kvm_for_each_vcpu(i, vcpu, kvm) {
> >>>>                struct task_struct *task = NULL;
> >>>>                struct pid *pid;
> >>>> -            if (!pass&&   i<   last_boosted_vcpu) {
> >>>> +            if (!pass&&   !vcpu->pv_unhalted)
> >>>> +                continue;
> >>>> +            else if (pass == 1&&   i<   last_boosted_vcpu) {
> >>>>                    i = last_boosted_vcpu;
> >>>>                    continue;
> >>>> -            } else if (pass&&   i>   last_boosted_vcpu)
> >>>> +            } else if (pass == 2&&   i>   last_boosted_vcpu)
> >>>>                    break;
> >>>>                if (vcpu == me)
> >>>>                    continue;
> >>>>
> >>>
> >>> Actually I think this is unneeded.  The loops tries to find vcpus
> that
> >>> are runnable but not running (vcpu_active(vcpu->wq)), and halted
> vcpus
> >>> don't match this condition.
> >>>
>
> Oh! I think I misinterpreted your statement. hmm I got it. you told to
> remove if (vcpu == me) condition.

No, the entire patch is unneeded.  My original comment was:

> from the PLE handler, don't wake up a vcpu that is sleeping because it
is waiting for a kick

But the PLE handler never wakes up sleeping vcpus anyway.

There's still a conflict with PLE in that it may trigger during the spin
phase and send a random yield_to() somewhere.  Maybe it's sufficient to
tune the PLE timeout to be longer than the spinlock timeout.


-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:08:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:08:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFig4-0003WF-6O; Thu, 05 Apr 2012 09:08:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SFig3-0003WA-0a
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:08:23 +0000
Received: from [85.158.138.51:54024] by server-10.bemta-3.messagelabs.com id
	EC/6C-15637-6016D7F4; Thu, 05 Apr 2012 09:08:22 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333616900!20867644!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5OTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9965 invoked from network); 5 Apr 2012 09:08:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 09:08:21 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3597rLb005854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 05:07:54 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3591FYH014283; Thu, 5 Apr 2012 05:01:16 -0400
Message-ID: <4F7D5F5B.2020209@redhat.com>
Date: Thu, 05 Apr 2012 12:01:15 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
	<4F7976B6.5050000@linux.vnet.ibm.com>
In-Reply-To: <4F7976B6.5050000@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/02/2012 12:51 PM, Raghavendra K T wrote:
> On 04/01/2012 07:23 PM, Avi Kivity wrote:
> > On 04/01/2012 04:48 PM, Raghavendra K T wrote:
> >>>> I have patch something like below in mind to try:
> >>>>
> >>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> >>>> index d3b98b1..5127668 100644
> >>>> --- a/virt/kvm/kvm_main.c
> >>>> +++ b/virt/kvm/kvm_main.c
> >>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
> >>>>         * else and called schedule in __vcpu_run.  Hopefully that
> >>>>         * VCPU is holding the lock that we need and will release it.
> >>>>         * We approximate round-robin by starting at the last boosted
> >>>> VCPU.
> >>>> +     * Priority is given to vcpu that are unhalted.
> >>>>         */
> >>>> -    for (pass = 0; pass<   2&&   !yielded; pass++) {
> >>>> +    for (pass = 0; pass<   3&&   !yielded; pass++) {
> >>>>            kvm_for_each_vcpu(i, vcpu, kvm) {
> >>>>                struct task_struct *task = NULL;
> >>>>                struct pid *pid;
> >>>> -            if (!pass&&   i<   last_boosted_vcpu) {
> >>>> +            if (!pass&&   !vcpu->pv_unhalted)
> >>>> +                continue;
> >>>> +            else if (pass == 1&&   i<   last_boosted_vcpu) {
> >>>>                    i = last_boosted_vcpu;
> >>>>                    continue;
> >>>> -            } else if (pass&&   i>   last_boosted_vcpu)
> >>>> +            } else if (pass == 2&&   i>   last_boosted_vcpu)
> >>>>                    break;
> >>>>                if (vcpu == me)
> >>>>                    continue;
> >>>>
> >>>
> >>> Actually I think this is unneeded.  The loops tries to find vcpus
> that
> >>> are runnable but not running (vcpu_active(vcpu->wq)), and halted
> vcpus
> >>> don't match this condition.
> >>>
>
> Oh! I think I misinterpreted your statement. hmm I got it. you told to
> remove if (vcpu == me) condition.

No, the entire patch is unneeded.  My original comment was:

> from the PLE handler, don't wake up a vcpu that is sleeping because it
is waiting for a kick

But the PLE handler never wakes up sleeping vcpus anyway.

There's still a conflict with PLE in that it may trigger during the spin
phase and send a random yield_to() somewhere.  Maybe it's sufficient to
tune the PLE timeout to be longer than the spinlock timeout.


-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:17:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFinx-0003hK-51; Thu, 05 Apr 2012 09:16:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SFinv-0003hF-NO
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:16:31 +0000
Received: from [85.158.139.83:54670] by server-11.bemta-5.messagelabs.com id
	3B/B2-12959-EE26D7F4; Thu, 05 Apr 2012 09:16:30 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333617389!22593728!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5OTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4870 invoked from network); 5 Apr 2012 09:16:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	5 Apr 2012 09:16:30 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q359G3RD004834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 05:16:03 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q359Fvai028762; Thu, 5 Apr 2012 05:15:57 -0400
Message-ID: <4F7D62CC.9010108@redhat.com>
Date: Thu, 05 Apr 2012 12:15:56 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<4F7858C0.90405@redhat.com>
	<alpine.LFD.2.02.1204021117560.2542@ionos>
In-Reply-To: <alpine.LFD.2.02.1204021117560.2542@ionos>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/02/2012 12:26 PM, Thomas Gleixner wrote:
> > One thing about it is that it can give many false positives.  Consider a
> > fine-grained spinlock that is being accessed by many threads.  That is,
> > the lock is taken and released with high frequency, but there is no
> > contention, because each vcpu is accessing a different instance.  So the
> > host scheduler will needlessly delay preemption of vcpus that happen to
> > be holding a lock, even though this gains nothing.
>
> You're talking about per cpu locks, right? I can see the point there,
> but per cpu stuff might be worth annotating to avoid this.

Or any lock which is simply uncontended.  Say a single process is
running, the rest of the system is idle.  It will take and release many
locks; but it can be preempted at any point by the hypervisor with no
performance loss.

The overhead is arming a timer twice and an extra exit per deferred
context switch.  Perhaps not much given that you don't see tons of
context switches on virt workloads, at least without threaded interrupts
(or maybe interrupt threads should override this mechanism, by being
realtime threads).

> > A second issue may happen with a lock that is taken and released with
> > high frequency, with a high hold percentage.  The host scheduler may
> > always sample the guest in a held state, leading it to conclude that
> > it's exceeding its timeout when in fact the lock is held for a short
> > time only.
>
> Well, no. You can avoid that.
>
> host		VCPU
> 		spin_lock()
> 		 modify_global_state()
>    	exit
> check_global_state()
> mark_global_state()
> reschedule vcpu
>
> 		spin_unlock()
> 		 check_global_state()
> 		  trigger_exit()
>
> So when an exit occures in the locked section, then the host can mark
> the global state to tell the guest to issue a trap on unlock.

Right.

How does this nest?  Do we trigger the exit on the outermost unlock?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:17:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFinx-0003hK-51; Thu, 05 Apr 2012 09:16:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SFinv-0003hF-NO
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:16:31 +0000
Received: from [85.158.139.83:54670] by server-11.bemta-5.messagelabs.com id
	3B/B2-12959-EE26D7F4; Thu, 05 Apr 2012 09:16:30 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333617389!22593728!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5OTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4870 invoked from network); 5 Apr 2012 09:16:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	5 Apr 2012 09:16:30 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q359G3RD004834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 05:16:03 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-85.tlv.redhat.com
	[10.35.4.85])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q359Fvai028762; Thu, 5 Apr 2012 05:15:57 -0400
Message-ID: <4F7D62CC.9010108@redhat.com>
Date: Thu, 05 Apr 2012 12:15:56 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<4F7858C0.90405@redhat.com>
	<alpine.LFD.2.02.1204021117560.2542@ionos>
In-Reply-To: <alpine.LFD.2.02.1204021117560.2542@ionos>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/02/2012 12:26 PM, Thomas Gleixner wrote:
> > One thing about it is that it can give many false positives.  Consider a
> > fine-grained spinlock that is being accessed by many threads.  That is,
> > the lock is taken and released with high frequency, but there is no
> > contention, because each vcpu is accessing a different instance.  So the
> > host scheduler will needlessly delay preemption of vcpus that happen to
> > be holding a lock, even though this gains nothing.
>
> You're talking about per cpu locks, right? I can see the point there,
> but per cpu stuff might be worth annotating to avoid this.

Or any lock which is simply uncontended.  Say a single process is
running, the rest of the system is idle.  It will take and release many
locks; but it can be preempted at any point by the hypervisor with no
performance loss.

The overhead is arming a timer twice and an extra exit per deferred
context switch.  Perhaps not much given that you don't see tons of
context switches on virt workloads, at least without threaded interrupts
(or maybe interrupt threads should override this mechanism, by being
realtime threads).

> > A second issue may happen with a lock that is taken and released with
> > high frequency, with a high hold percentage.  The host scheduler may
> > always sample the guest in a held state, leading it to conclude that
> > it's exceeding its timeout when in fact the lock is held for a short
> > time only.
>
> Well, no. You can avoid that.
>
> host		VCPU
> 		spin_lock()
> 		 modify_global_state()
>    	exit
> check_global_state()
> mark_global_state()
> reschedule vcpu
>
> 		spin_unlock()
> 		 check_global_state()
> 		  trigger_exit()
>
> So when an exit occures in the locked section, then the host can mark
> the global state to tell the guest to issue a trap on unlock.

Right.

How does this nest?  Do we trigger the exit on the outermost unlock?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:23:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:23:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFiua-0003qV-43; Thu, 05 Apr 2012 09:23:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <the.kazak@gmail.com>) id 1SFiuY-0003qG-2s
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 09:23:22 +0000
Received: from [85.158.143.99:53325] by server-3.bemta-4.messagelabs.com id
	5D/49-05853-8846D7F4; Thu, 05 Apr 2012 09:23:20 +0000
X-Env-Sender: the.kazak@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333617799!22470462!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15545 invoked from network); 5 Apr 2012 09:23:19 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:23:19 -0000
Received: by bkcjg9 with SMTP id jg9so1293998bkc.32
	for <multiple recipients>; Thu, 05 Apr 2012 02:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=ozNx+xdKj3m499f6n8WzLq2OO5t/ksFWdX6wb9GLSY8=;
	b=uitzRoyc0qjJ4mzMX36YdX767JhCj8MTYIKaIbt6s3b/xXnSd/33edSmmDGxlLTMXE
	VXc2rbeFToJMifeJIWZxLXd6gfqguOkuhLWjWiVVV/5XlMQbPzl8Eitp3LPzvvWUV2lq
	1F7VWrWottXU65BzqAFiZsDJQIZyCJb7srDDZ4bktJIFX/FvgwozwSV3Txr3l+XwBpO3
	Jcj2uT9ctkn88k965x4OKuMrlR5W/6QDmV5BYsr0kg4QROGt6GXZqQvMKrIGxG9nx1JS
	FpYBtcATaRludKxbo/0mln4lZ4ChzkBV5pGYkxBLk/xHIZqmIOxB4r0VLhKEotvvudKR
	7lWg==
Received: by 10.204.128.201 with SMTP id l9mr786292bks.90.1333617798871;
	Thu, 05 Apr 2012 02:23:18 -0700 (PDT)
Received: from [212.50.0.54] (purple.varna.spnet.net. [212.50.0.54])
	by mx.google.com with ESMTPS id f5sm7372018bke.9.2012.04.05.02.23.17
	(version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 02:23:18 -0700 (PDT)
Message-ID: <4F7D6480.6040704@gmail.com>
Date: Thu, 05 Apr 2012 12:23:12 +0300
From: Dimitar Kazakov <the.kazak@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: xen-api@lists.xen.org, xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary="------------000503040804060600000300"
Subject: [Xen-devel] xe vdi-create failure ot local SR type=file and type=ext
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a multi-part message in MIME format.
--------------000503040804060600000300
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,
have permanent failure when try to create VDI on local SR type=file or
type=ext. On both types it failed with the same error:
SR_BACKEND_FAILURE_78
VDI Creation failed [opterr=error 127]

I am on Debian box with kernel 3.3.0-rc7, Xen version 4.1.2 (Debian
4.1.2-2.1), Xen-API Version: 1.3.2-4 (Kronos)

Is it a bug, or am I missing something? Anybody managed to workaround
this problem?


Here is a short extract from xcp-xapi.log

id=ba4e9e1a-bc42-0dc9-af0e-5db2905666ab type=user name-label=test
virtual-size=1GiB username=root password=null
[20120403T07:57:53.973Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
Session.create trackid=1ef3448b63e70822073569022044e96b pool=false
uname=root is_local_superuser=true auth_user_sid=
parent=trackid=9834f5af41c964e225f24279aefe4e49
[20120403T07:57:53.974Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
Attempting to open /var/lib/xcp/xapi
[20120403T07:57:53.975Z|debug|hyperion|547 UNIX
/var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
D:4cab7e7aa9ae created by task D:93575fa7333c
[20120403T07:57:53.982Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|audit] VDI.create: SR =
'ba4e9e1a-bc42-0dc9-af0e-5db2905666ab (Local storage)'; name label = 'test'
[20120403T07:57:53.983Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Marking SR for
VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
[20120403T07:57:53.984Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|storage_impl] VDI.create
task:OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a
sr:ba4e9e1a-bc42-0dc9-af0e-5db2905666ab vdi_info:{"vdi": "",
"name_label": "test", "name_description": "", "ty": "user",
"metadata_of_pool": "", "is_a_snapshot": false, "snapshot_time":
"19700101T00:00:00Z", "snapshot_of": "", "read_only": false,
"virtual_size": 1073741824, "physical_utilisation": 0} params:
[20120403T07:57:53.984Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dummytaskhelper] task
VDI.create D:db9f2e113fee created by task R:efdfb350d7ac
[20120403T07:57:53.986Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.create
trackid=654ed4437d52fe9cdd8e5d98a5955526 pool=false uname=
is_local_superuser=true auth_user_sid=
parent=trackid=9834f5af41c964e225f24279aefe4e49
[20120403T07:57:53.987Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Attempting to open
/var/lib/xcp/xapi
[20120403T07:57:53.987Z|debug|hyperion|548 UNIX
/var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
D:3829e36dbb97 created by task D:6ec167aaa83d
[20120403T07:57:54.066Z|debug|hyperion|549 UNIX
/var/lib/xcp/xapi||dummytaskhelper] task dispatch:host.get_other_config
D:c813aaba73c4 created by task D:db9f2e113fee
[20120403T07:57:54.071Z|debug|hyperion|549 UNIX
/var/lib/xcp/xapi||http_critical] Premature termination of connection!
[20120403T07:57:54.109Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
sm_exec.ml:220.7-69 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.109Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.destroy
trackid=654ed4437d52fe9cdd8e5d98a5955526
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
pervasiveext.ml:26.22-25 -> server_helpers.ml:76.11-23
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Server_helpers.exec
exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI Creation
failed [opterr=error 127];  ]
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
pervasiveext.ml:26.22-25 -> sm.ml:132.25-98 ->
storage_access.ml:259.36-331 -> storage_access.ml:257.28-492 ->
server_helpers.ml:76.11-23
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher]
Server_helpers.exec exception_handler: Got exception
SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
storage_access.ml:449.8-47 -> message_forwarding.ml:233.25-44 ->
pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Unmarking SR after
VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
[20120403T07:57:54.111Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
pervasiveext.ml:26.22-25 -> server.ml:24034.78-280 -> rbac.ml:229.16-23
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
rbac.ml:238.10-15 -> server_helpers.ml:79.11-41
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher]
Server_helpers.exec exception_handler: Got exception
SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.114Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|backtrace] Raised
at pervasiveext.ml:26.22-25 -> server_helpers.ml:153.10-106 ->
server.ml:24035.19-190 -> server_helpers.ml:119.4-7
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||xapi]
Raised at client.ml:6.37-75 -> client.ml:9043.48-106 ->
cli_operations.ml:1082.11-187 -> xapi_cli.ml:112.18-56 ->
pervasiveext.ml:22.2-9
[20120403T07:57:54.117Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|session.logout D:2d486a4a5b26|xapi] Session.destroy
trackid=1ef3448b63e70822073569022044e96b
[20120403T07:57:54.118Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi||backtrace] Raised at pervasiveext.ml:26.22-25 ->
xapi_cli.ml:111.2-138 -> xapi_cli.ml:205.7-44 -> xapi_cli.ml:257.4-23
[20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
Xapi_cli.exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI
Creation failed [opterr=error 127];  ]
[20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
Raised at string.ml:150.25-34 -> stringext.ml:108.13-29

Thanks,
Dimitar Kazkov

--------------000503040804060600000300
Content-Type: text/x-vcard; charset=utf-8;
 name="the_kazak.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="the_kazak.vcf"

YmVnaW46dmNhcmQNCmZuOkRpbWl0YXIgS2F6YWtvdiAoa0B6QGspDQpuOkthemFrb3Y7RGlt
aXRhcg0Kb3JnOldlYlRvQ2xvdWQNCmFkcjo7OztWYXJuYTs7OTAwMDtCdWxnYXJpYQ0KZW1h
aWw7aW50ZXJuZXQ6dGhlLmthemFrQGdtYWlsLmNvbQ0KdGVsO2hvbWU6KzM1OSAoNTIpIDkx
MTExOQ0KdGVsO2NlbGw6KzM1OSAoODgpIDg1NTk5MDkNCngtbW96aWxsYS1odG1sOkZBTFNF
DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg==
--------------000503040804060600000300
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000503040804060600000300--


From xen-devel-bounces@lists.xen.org Thu Apr 05 09:23:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:23:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFiua-0003qV-43; Thu, 05 Apr 2012 09:23:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <the.kazak@gmail.com>) id 1SFiuY-0003qG-2s
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 09:23:22 +0000
Received: from [85.158.143.99:53325] by server-3.bemta-4.messagelabs.com id
	5D/49-05853-8846D7F4; Thu, 05 Apr 2012 09:23:20 +0000
X-Env-Sender: the.kazak@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333617799!22470462!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15545 invoked from network); 5 Apr 2012 09:23:19 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:23:19 -0000
Received: by bkcjg9 with SMTP id jg9so1293998bkc.32
	for <multiple recipients>; Thu, 05 Apr 2012 02:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=ozNx+xdKj3m499f6n8WzLq2OO5t/ksFWdX6wb9GLSY8=;
	b=uitzRoyc0qjJ4mzMX36YdX767JhCj8MTYIKaIbt6s3b/xXnSd/33edSmmDGxlLTMXE
	VXc2rbeFToJMifeJIWZxLXd6gfqguOkuhLWjWiVVV/5XlMQbPzl8Eitp3LPzvvWUV2lq
	1F7VWrWottXU65BzqAFiZsDJQIZyCJb7srDDZ4bktJIFX/FvgwozwSV3Txr3l+XwBpO3
	Jcj2uT9ctkn88k965x4OKuMrlR5W/6QDmV5BYsr0kg4QROGt6GXZqQvMKrIGxG9nx1JS
	FpYBtcATaRludKxbo/0mln4lZ4ChzkBV5pGYkxBLk/xHIZqmIOxB4r0VLhKEotvvudKR
	7lWg==
Received: by 10.204.128.201 with SMTP id l9mr786292bks.90.1333617798871;
	Thu, 05 Apr 2012 02:23:18 -0700 (PDT)
Received: from [212.50.0.54] (purple.varna.spnet.net. [212.50.0.54])
	by mx.google.com with ESMTPS id f5sm7372018bke.9.2012.04.05.02.23.17
	(version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 02:23:18 -0700 (PDT)
Message-ID: <4F7D6480.6040704@gmail.com>
Date: Thu, 05 Apr 2012 12:23:12 +0300
From: Dimitar Kazakov <the.kazak@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: xen-api@lists.xen.org, xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary="------------000503040804060600000300"
Subject: [Xen-devel] xe vdi-create failure ot local SR type=file and type=ext
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a multi-part message in MIME format.
--------------000503040804060600000300
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,
have permanent failure when try to create VDI on local SR type=file or
type=ext. On both types it failed with the same error:
SR_BACKEND_FAILURE_78
VDI Creation failed [opterr=error 127]

I am on Debian box with kernel 3.3.0-rc7, Xen version 4.1.2 (Debian
4.1.2-2.1), Xen-API Version: 1.3.2-4 (Kronos)

Is it a bug, or am I missing something? Anybody managed to workaround
this problem?


Here is a short extract from xcp-xapi.log

id=ba4e9e1a-bc42-0dc9-af0e-5db2905666ab type=user name-label=test
virtual-size=1GiB username=root password=null
[20120403T07:57:53.973Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
Session.create trackid=1ef3448b63e70822073569022044e96b pool=false
uname=root is_local_superuser=true auth_user_sid=
parent=trackid=9834f5af41c964e225f24279aefe4e49
[20120403T07:57:53.974Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
Attempting to open /var/lib/xcp/xapi
[20120403T07:57:53.975Z|debug|hyperion|547 UNIX
/var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
D:4cab7e7aa9ae created by task D:93575fa7333c
[20120403T07:57:53.982Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|audit] VDI.create: SR =
'ba4e9e1a-bc42-0dc9-af0e-5db2905666ab (Local storage)'; name label = 'test'
[20120403T07:57:53.983Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Marking SR for
VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
[20120403T07:57:53.984Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|storage_impl] VDI.create
task:OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a
sr:ba4e9e1a-bc42-0dc9-af0e-5db2905666ab vdi_info:{"vdi": "",
"name_label": "test", "name_description": "", "ty": "user",
"metadata_of_pool": "", "is_a_snapshot": false, "snapshot_time":
"19700101T00:00:00Z", "snapshot_of": "", "read_only": false,
"virtual_size": 1073741824, "physical_utilisation": 0} params:
[20120403T07:57:53.984Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dummytaskhelper] task
VDI.create D:db9f2e113fee created by task R:efdfb350d7ac
[20120403T07:57:53.986Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.create
trackid=654ed4437d52fe9cdd8e5d98a5955526 pool=false uname=
is_local_superuser=true auth_user_sid=
parent=trackid=9834f5af41c964e225f24279aefe4e49
[20120403T07:57:53.987Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Attempting to open
/var/lib/xcp/xapi
[20120403T07:57:53.987Z|debug|hyperion|548 UNIX
/var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
D:3829e36dbb97 created by task D:6ec167aaa83d
[20120403T07:57:54.066Z|debug|hyperion|549 UNIX
/var/lib/xcp/xapi||dummytaskhelper] task dispatch:host.get_other_config
D:c813aaba73c4 created by task D:db9f2e113fee
[20120403T07:57:54.071Z|debug|hyperion|549 UNIX
/var/lib/xcp/xapi||http_critical] Premature termination of connection!
[20120403T07:57:54.109Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
sm_exec.ml:220.7-69 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.109Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.destroy
trackid=654ed4437d52fe9cdd8e5d98a5955526
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
pervasiveext.ml:26.22-25 -> server_helpers.ml:76.11-23
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Server_helpers.exec
exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI Creation
failed [opterr=error 127];  ]
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
pervasiveext.ml:26.22-25 -> sm.ml:132.25-98 ->
storage_access.ml:259.36-331 -> storage_access.ml:257.28-492 ->
server_helpers.ml:76.11-23
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher]
Server_helpers.exec exception_handler: Got exception
SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
storage_access.ml:449.8-47 -> message_forwarding.ml:233.25-44 ->
pervasiveext.ml:22.2-9
[20120403T07:57:54.110Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Unmarking SR after
VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
[20120403T07:57:54.111Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
pervasiveext.ml:26.22-25 -> server.ml:24034.78-280 -> rbac.ml:229.16-23
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
rbac.ml:238.10-15 -> server_helpers.ml:79.11-41
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher]
Server_helpers.exec exception_handler: Got exception
SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.112Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
string.ml:150.25-34 -> stringext.ml:108.13-29
[20120403T07:57:54.114Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|xapi] Raised at
pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|backtrace] Raised
at pervasiveext.ml:26.22-25 -> server_helpers.ml:153.10-106 ->
server.ml:24035.19-190 -> server_helpers.ml:119.4-7
[20120403T07:57:54.115Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||xapi]
Raised at client.ml:6.37-75 -> client.ml:9043.48-106 ->
cli_operations.ml:1082.11-187 -> xapi_cli.ml:112.18-56 ->
pervasiveext.ml:22.2-9
[20120403T07:57:54.117Z| info|hyperion|546 UNIX
/var/lib/xcp/xapi|session.logout D:2d486a4a5b26|xapi] Session.destroy
trackid=1ef3448b63e70822073569022044e96b
[20120403T07:57:54.118Z|debug|hyperion|546 UNIX
/var/lib/xcp/xapi||backtrace] Raised at pervasiveext.ml:26.22-25 ->
xapi_cli.ml:111.2-138 -> xapi_cli.ml:205.7-44 -> xapi_cli.ml:257.4-23
[20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
Xapi_cli.exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI
Creation failed [opterr=error 127];  ]
[20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
Raised at string.ml:150.25-34 -> stringext.ml:108.13-29

Thanks,
Dimitar Kazkov

--------------000503040804060600000300
Content-Type: text/x-vcard; charset=utf-8;
 name="the_kazak.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="the_kazak.vcf"

YmVnaW46dmNhcmQNCmZuOkRpbWl0YXIgS2F6YWtvdiAoa0B6QGspDQpuOkthemFrb3Y7RGlt
aXRhcg0Kb3JnOldlYlRvQ2xvdWQNCmFkcjo7OztWYXJuYTs7OTAwMDtCdWxnYXJpYQ0KZW1h
aWw7aW50ZXJuZXQ6dGhlLmthemFrQGdtYWlsLmNvbQ0KdGVsO2hvbWU6KzM1OSAoNTIpIDkx
MTExOQ0KdGVsO2NlbGw6KzM1OSAoODgpIDg1NTk5MDkNCngtbW96aWxsYS1odG1sOkZBTFNF
DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg==
--------------000503040804060600000300
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000503040804060600000300--


From xen-devel-bounces@lists.xen.org Thu Apr 05 09:34:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFj4b-00043g-Ar; Thu, 05 Apr 2012 09:33:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SFj4a-00043b-EH
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:33:44 +0000
Received: from [85.158.143.99:6701] by server-1.bemta-4.messagelabs.com id
	F3/90-20925-7F66D7F4; Thu, 05 Apr 2012 09:33:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333618422!12815055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27850 invoked from network); 5 Apr 2012 09:33:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:33:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11787815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:33:42 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	10:33:42 +0100
Message-ID: <1333618350.2513.5.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 5 Apr 2012 10:32:30 +0100
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, liuw@liuw.name,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
Xen HVM guests.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:34:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFj4b-00043g-Ar; Thu, 05 Apr 2012 09:33:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SFj4a-00043b-EH
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:33:44 +0000
Received: from [85.158.143.99:6701] by server-1.bemta-4.messagelabs.com id
	F3/90-20925-7F66D7F4; Thu, 05 Apr 2012 09:33:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333618422!12815055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27850 invoked from network); 5 Apr 2012 09:33:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:33:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11787815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:33:42 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	10:33:42 +0100
Message-ID: <1333618350.2513.5.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 5 Apr 2012 10:32:30 +0100
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, liuw@liuw.name,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
Xen HVM guests.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:35:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFj6M-00048L-QV; Thu, 05 Apr 2012 09:35:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SFj6L-00048D-KB
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:35:33 +0000
Received: from [85.158.139.83:54260] by server-6.bemta-5.messagelabs.com id
	34/0B-13222-4676D7F4; Thu, 05 Apr 2012 09:35:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333618532!18654117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10031 invoked from network); 5 Apr 2012 09:35:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:35:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11787863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:35:32 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	10:35:31 +0100
Message-ID: <1333618460.2513.7.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 5 Apr 2012 10:34:20 +0100
In-Reply-To: <1333618350.2513.5.camel@leeds.uk.xensource.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH 1/2] Xen: basic HVM MSI injection support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 hw/xen.h   |    1 +
 xen-all.c  |    5 +++++
 xen-stub.c |    4 ++++
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index b46879c..e5926b7 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -34,6 +34,7 @@ static inline int xen_enabled(void)
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level);
 
 qemu_irq *xen_interrupt_controller_init(void);
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..abd2b2d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -122,6 +122,11 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+}
+
 static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
diff --git a/xen-stub.c b/xen-stub.c
index 9ea02d4..8ff2b79 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -29,6 +29,10 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 {
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+}
+
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:35:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFj6M-00048L-QV; Thu, 05 Apr 2012 09:35:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SFj6L-00048D-KB
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:35:33 +0000
Received: from [85.158.139.83:54260] by server-6.bemta-5.messagelabs.com id
	34/0B-13222-4676D7F4; Thu, 05 Apr 2012 09:35:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333618532!18654117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzA3Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10031 invoked from network); 5 Apr 2012 09:35:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:35:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11787863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:35:32 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	10:35:31 +0100
Message-ID: <1333618460.2513.7.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 5 Apr 2012 10:34:20 +0100
In-Reply-To: <1333618350.2513.5.camel@leeds.uk.xensource.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH 1/2] Xen: basic HVM MSI injection support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 hw/xen.h   |    1 +
 xen-all.c  |    5 +++++
 xen-stub.c |    4 ++++
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index b46879c..e5926b7 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -34,6 +34,7 @@ static inline int xen_enabled(void)
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level);
 
 qemu_irq *xen_interrupt_controller_init(void);
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..abd2b2d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -122,6 +122,11 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+}
+
 static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
diff --git a/xen-stub.c b/xen-stub.c
index 9ea02d4..8ff2b79 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -29,6 +29,10 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 {
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+}
+
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFj77-0004Bx-7g; Thu, 05 Apr 2012 09:36:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SFj75-0004Bo-0h
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:36:19 +0000
Received: from [193.109.254.147:20716] by server-5.bemta-14.messagelabs.com id
	48/1C-30733-2976D7F4; Thu, 05 Apr 2012 09:36:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333618577!249714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24791 invoked from network); 5 Apr 2012 09:36:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11787906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:36:16 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	10:36:16 +0100
Message-ID: <1333618505.2513.8.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 5 Apr 2012 10:35:05 +0100
In-Reply-To: <1333618350.2513.5.camel@leeds.uk.xensource.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH 2/2] Xen: Add xen-apic support and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 Makefile.target |    2 +-
 hw/pc.c         |    8 +++++
 hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 99 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_apic.c

diff --git a/Makefile.target b/Makefile.target
index cff15f0..6210bae 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -235,7 +235,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
 obj-$(CONFIG_NO_XEN) += xen-stub.o
 
-obj-i386-$(CONFIG_XEN) += xen_platform.o
+obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/pc.c b/hw/pc.c
index 83a1b5b..5585cac 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -42,6 +42,7 @@
 #include "sysbus.h"
 #include "sysemu.h"
 #include "kvm.h"
+#include "xen.h"
 #include "blockdev.h"
 #include "ui/qemu-spice.h"
 #include "memory.h"
@@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
 
     if (kvm_irqchip_in_kernel()) {
         dev = qdev_create(NULL, "kvm-apic");
+    } else if (xen_enabled()) {
+        dev = qdev_create(NULL, "xen-apic");
     } else {
         dev = qdev_create(NULL, "apic");
     }
+
     qdev_prop_set_uint8(dev, "id", apic_id);
     qdev_prop_set_ptr(dev, "cpu_env", env);
     qdev_init_nofail(dev);
@@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
         msi_supported = true;
     }
 
+    if (xen_enabled()) {
+        msi_supported = true;
+    }
+
     return dev;
 }
 
diff --git a/hw/xen_apic.c b/hw/xen_apic.c
new file mode 100644
index 0000000..b1060b7
--- /dev/null
+++ b/hw/xen_apic.c
@@ -0,0 +1,90 @@
+/*
+ * Xen basic APIC support
+ *
+ * Copyright (c) 2012 Citrix
+ *
+ * Authors:
+ *  Wei Liu <wei.liu2@citrix.com>
+ *
+ * This work is licensed under the terms of the GNU GPL version 2.
+ * See the COPYING file in the top-level directory.
+ */
+#include "hw/apic_internal.h"
+#include "hw/msi.h"
+#include "xen.h"
+
+static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
+                                  unsigned size)
+{
+    return -1U;
+}
+
+static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
+                               uint64_t data, unsigned size)
+{
+    if (size != sizeof(uint32_t)) {
+        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
+        return;
+    }
+
+    xen_hvm_inject_msi(addr, data);
+}
+
+static const MemoryRegionOps xen_apic_io_ops = {
+    .read = xen_apic_mem_read,
+    .write = xen_apic_mem_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void xen_apic_init(APICCommonState *s)
+{
+    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
+                          MSI_SPACE_SIZE);
+}
+
+static void xen_apic_set_base(APICCommonState *s, uint64_t val)
+{
+}
+
+static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
+{
+}
+
+static uint8_t xen_apic_get_tpr(APICCommonState *s)
+{
+    return 0;
+}
+
+static void xen_apic_vapic_base_update(APICCommonState *s)
+{
+}
+
+static void xen_apic_external_nmi(APICCommonState *s)
+{
+}
+
+static void xen_apic_class_init(ObjectClass *klass, void *data)
+{
+    APICCommonClass *k = APIC_COMMON_CLASS(klass);
+
+    k->init = xen_apic_init;
+    k->set_base = xen_apic_set_base;
+    k->set_tpr = xen_apic_set_tpr;
+    k->get_tpr = xen_apic_get_tpr;
+    k->vapic_base_update = xen_apic_vapic_base_update;
+    k->external_nmi = xen_apic_external_nmi;
+}
+
+static TypeInfo xen_apic_info = {
+    .name = "xen-apic",
+    .parent = TYPE_APIC_COMMON,
+    .instance_size = sizeof(APICCommonState),
+    .class_init = xen_apic_class_init,
+};
+
+static void xen_apic_register_types(void)
+{
+    type_register_static(&xen_apic_info);
+}
+
+type_init(xen_apic_register_types)
-- 
1.7.2.5





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 09:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 09:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFj77-0004Bx-7g; Thu, 05 Apr 2012 09:36:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1SFj75-0004Bo-0h
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 09:36:19 +0000
Received: from [193.109.254.147:20716] by server-5.bemta-14.messagelabs.com id
	48/1C-30733-2976D7F4; Thu, 05 Apr 2012 09:36:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333618577!249714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24791 invoked from network); 5 Apr 2012 09:36:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 09:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11787906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:36:16 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	10:36:16 +0100
Message-ID: <1333618505.2513.8.camel@leeds.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 5 Apr 2012 10:35:05 +0100
In-Reply-To: <1333618350.2513.5.camel@leeds.uk.xensource.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH 2/2] Xen: Add xen-apic support and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 Makefile.target |    2 +-
 hw/pc.c         |    8 +++++
 hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 99 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_apic.c

diff --git a/Makefile.target b/Makefile.target
index cff15f0..6210bae 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -235,7 +235,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
 obj-$(CONFIG_NO_XEN) += xen-stub.o
 
-obj-i386-$(CONFIG_XEN) += xen_platform.o
+obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/pc.c b/hw/pc.c
index 83a1b5b..5585cac 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -42,6 +42,7 @@
 #include "sysbus.h"
 #include "sysemu.h"
 #include "kvm.h"
+#include "xen.h"
 #include "blockdev.h"
 #include "ui/qemu-spice.h"
 #include "memory.h"
@@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
 
     if (kvm_irqchip_in_kernel()) {
         dev = qdev_create(NULL, "kvm-apic");
+    } else if (xen_enabled()) {
+        dev = qdev_create(NULL, "xen-apic");
     } else {
         dev = qdev_create(NULL, "apic");
     }
+
     qdev_prop_set_uint8(dev, "id", apic_id);
     qdev_prop_set_ptr(dev, "cpu_env", env);
     qdev_init_nofail(dev);
@@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
         msi_supported = true;
     }
 
+    if (xen_enabled()) {
+        msi_supported = true;
+    }
+
     return dev;
 }
 
diff --git a/hw/xen_apic.c b/hw/xen_apic.c
new file mode 100644
index 0000000..b1060b7
--- /dev/null
+++ b/hw/xen_apic.c
@@ -0,0 +1,90 @@
+/*
+ * Xen basic APIC support
+ *
+ * Copyright (c) 2012 Citrix
+ *
+ * Authors:
+ *  Wei Liu <wei.liu2@citrix.com>
+ *
+ * This work is licensed under the terms of the GNU GPL version 2.
+ * See the COPYING file in the top-level directory.
+ */
+#include "hw/apic_internal.h"
+#include "hw/msi.h"
+#include "xen.h"
+
+static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
+                                  unsigned size)
+{
+    return -1U;
+}
+
+static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
+                               uint64_t data, unsigned size)
+{
+    if (size != sizeof(uint32_t)) {
+        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
+        return;
+    }
+
+    xen_hvm_inject_msi(addr, data);
+}
+
+static const MemoryRegionOps xen_apic_io_ops = {
+    .read = xen_apic_mem_read,
+    .write = xen_apic_mem_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void xen_apic_init(APICCommonState *s)
+{
+    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
+                          MSI_SPACE_SIZE);
+}
+
+static void xen_apic_set_base(APICCommonState *s, uint64_t val)
+{
+}
+
+static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
+{
+}
+
+static uint8_t xen_apic_get_tpr(APICCommonState *s)
+{
+    return 0;
+}
+
+static void xen_apic_vapic_base_update(APICCommonState *s)
+{
+}
+
+static void xen_apic_external_nmi(APICCommonState *s)
+{
+}
+
+static void xen_apic_class_init(ObjectClass *klass, void *data)
+{
+    APICCommonClass *k = APIC_COMMON_CLASS(klass);
+
+    k->init = xen_apic_init;
+    k->set_base = xen_apic_set_base;
+    k->set_tpr = xen_apic_set_tpr;
+    k->get_tpr = xen_apic_get_tpr;
+    k->vapic_base_update = xen_apic_vapic_base_update;
+    k->external_nmi = xen_apic_external_nmi;
+}
+
+static TypeInfo xen_apic_info = {
+    .name = "xen-apic",
+    .parent = TYPE_APIC_COMMON,
+    .instance_size = sizeof(APICCommonState),
+    .class_init = xen_apic_class_init,
+};
+
+static void xen_apic_register_types(void)
+{
+    type_register_static(&xen_apic_info);
+}
+
+type_init(xen_apic_register_types)
-- 
1.7.2.5





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjUZ-0004wN-O4; Thu, 05 Apr 2012 10:00:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFjUY-0004wI-Hb
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:00:34 +0000
Received: from [85.158.139.83:37491] by server-3.bemta-5.messagelabs.com id
	93/15-25237-14D6D7F4; Thu, 05 Apr 2012 10:00:33 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333620030!18720974!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9697 invoked from network); 5 Apr 2012 10:00:32 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Apr 2012 10:00:32 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFjUS-0002zt-UH
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 03:00:28 -0700
Date: Thu, 5 Apr 2012 03:00:28 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333620028931-5619975.post@n5.nabble.com>
In-Reply-To: <1333377715290-5612666.post@n5.nabble.com>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
	<alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
	<1333377715290-5612666.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Someone can tell me please how to do full and correct debug with strace?
I try with this command but seem broke domU start:
strace -f -e trace=open xl create /etc/xen/XP.cfg

Thanks for any reply

--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5619975.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjUZ-0004wN-O4; Thu, 05 Apr 2012 10:00:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFjUY-0004wI-Hb
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:00:34 +0000
Received: from [85.158.139.83:37491] by server-3.bemta-5.messagelabs.com id
	93/15-25237-14D6D7F4; Thu, 05 Apr 2012 10:00:33 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333620030!18720974!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9697 invoked from network); 5 Apr 2012 10:00:32 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Apr 2012 10:00:32 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFjUS-0002zt-UH
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 03:00:28 -0700
Date: Thu, 5 Apr 2012 03:00:28 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333620028931-5619975.post@n5.nabble.com>
In-Reply-To: <1333377715290-5612666.post@n5.nabble.com>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
	<alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
	<1333377715290-5612666.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Someone can tell me please how to do full and correct debug with strace?
I try with this command but seem broke domU start:
strace -f -e trace=open xl create /etc/xen/XP.cfg

Thanks for any reply

--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5619975.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjbz-00057w-Oj; Thu, 05 Apr 2012 10:08:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jonathan.Ludlam@eu.citrix.com>) id 1SFjby-00057i-5O
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:08:14 +0000
Received: from [85.158.143.35:10600] by server-1.bemta-4.messagelabs.com id
	BE/99-20925-C0F6D7F4; Thu, 05 Apr 2012 10:08:12 +0000
X-Env-Sender: Jonathan.Ludlam@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333620490!7570595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27477 invoked from network); 5 Apr 2012 10:08:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:08:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11789319"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:08:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 5 Apr 2012
	11:08:10 +0100
From: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
To: Dimitar Kazakov <the.kazak@gmail.com>
Date: Thu, 5 Apr 2012 11:08:08 +0100
Thread-Topic: [Xen-API] xe vdi-create failure ot local SR type=file and
	type=ext
Thread-Index: Ac0TFABqcTeHZXqNSuqhLzKIJ11u8A==
Message-ID: <7549B613-6EB9-4DD8-9741-C0D8556D0176@eu.citrix.com>
References: <4F7D6480.6040704@gmail.com>
In-Reply-To: <4F7D6480.6040704@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-API] xe vdi-create failure ot local SR
 type=file and type=ext
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The log snippet doesn't have the detail in it - have a look in /var/log/SMlog - you might find something more useful in there.

Jon

On 5 Apr 2012, at 10:23, Dimitar Kazakov wrote:

> Hi,
> have permanent failure when try to create VDI on local SR type=file or
> type=ext. On both types it failed with the same error:
> SR_BACKEND_FAILURE_78
> VDI Creation failed [opterr=error 127]
> 
> I am on Debian box with kernel 3.3.0-rc7, Xen version 4.1.2 (Debian
> 4.1.2-2.1), Xen-API Version: 1.3.2-4 (Kronos)
> 
> Is it a bug, or am I missing something? Anybody managed to workaround
> this problem?
> 
> 
> Here is a short extract from xcp-xapi.log
> 
> id=ba4e9e1a-bc42-0dc9-af0e-5db2905666ab type=user name-label=test
> virtual-size=1GiB username=root password=null
> [20120403T07:57:53.973Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
> Session.create trackid=1ef3448b63e70822073569022044e96b pool=false
> uname=root is_local_superuser=true auth_user_sid=
> parent=trackid=9834f5af41c964e225f24279aefe4e49
> [20120403T07:57:53.974Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
> Attempting to open /var/lib/xcp/xapi
> [20120403T07:57:53.975Z|debug|hyperion|547 UNIX
> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
> D:4cab7e7aa9ae created by task D:93575fa7333c
> [20120403T07:57:53.982Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|audit] VDI.create: SR =
> 'ba4e9e1a-bc42-0dc9-af0e-5db2905666ab (Local storage)'; name label = 'test'
> [20120403T07:57:53.983Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Marking SR for
> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
> [20120403T07:57:53.984Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|storage_impl] VDI.create
> task:OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a
> sr:ba4e9e1a-bc42-0dc9-af0e-5db2905666ab vdi_info:{"vdi": "",
> "name_label": "test", "name_description": "", "ty": "user",
> "metadata_of_pool": "", "is_a_snapshot": false, "snapshot_time":
> "19700101T00:00:00Z", "snapshot_of": "", "read_only": false,
> "virtual_size": 1073741824, "physical_utilisation": 0} params:
> [20120403T07:57:53.984Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dummytaskhelper] task
> VDI.create D:db9f2e113fee created by task R:efdfb350d7ac
> [20120403T07:57:53.986Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.create
> trackid=654ed4437d52fe9cdd8e5d98a5955526 pool=false uname=
> is_local_superuser=true auth_user_sid=
> parent=trackid=9834f5af41c964e225f24279aefe4e49
> [20120403T07:57:53.987Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Attempting to open
> /var/lib/xcp/xapi
> [20120403T07:57:53.987Z|debug|hyperion|548 UNIX
> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
> D:3829e36dbb97 created by task D:6ec167aaa83d
> [20120403T07:57:54.066Z|debug|hyperion|549 UNIX
> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:host.get_other_config
> D:c813aaba73c4 created by task D:db9f2e113fee
> [20120403T07:57:54.071Z|debug|hyperion|549 UNIX
> /var/lib/xcp/xapi||http_critical] Premature termination of connection!
> [20120403T07:57:54.109Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
> sm_exec.ml:220.7-69 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.109Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.destroy
> trackid=654ed4437d52fe9cdd8e5d98a5955526
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
> pervasiveext.ml:26.22-25 -> server_helpers.ml:76.11-23
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Server_helpers.exec
> exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI Creation
> failed [opterr=error 127];  ]
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
> pervasiveext.ml:26.22-25 -> sm.ml:132.25-98 ->
> storage_access.ml:259.36-331 -> storage_access.ml:257.28-492 ->
> server_helpers.ml:76.11-23
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher]
> Server_helpers.exec exception_handler: Got exception
> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> storage_access.ml:449.8-47 -> message_forwarding.ml:233.25-44 ->
> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Unmarking SR after
> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
> [20120403T07:57:54.111Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
> pervasiveext.ml:26.22-25 -> server.ml:24034.78-280 -> rbac.ml:229.16-23
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
> rbac.ml:238.10-15 -> server_helpers.ml:79.11-41
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher]
> Server_helpers.exec exception_handler: Got exception
> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.114Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|backtrace] Raised
> at pervasiveext.ml:26.22-25 -> server_helpers.ml:153.10-106 ->
> server.ml:24035.19-190 -> server_helpers.ml:119.4-7
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||xapi]
> Raised at client.ml:6.37-75 -> client.ml:9043.48-106 ->
> cli_operations.ml:1082.11-187 -> xapi_cli.ml:112.18-56 ->
> pervasiveext.ml:22.2-9
> [20120403T07:57:54.117Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|session.logout D:2d486a4a5b26|xapi] Session.destroy
> trackid=1ef3448b63e70822073569022044e96b
> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi||backtrace] Raised at pervasiveext.ml:26.22-25 ->
> xapi_cli.ml:111.2-138 -> xapi_cli.ml:205.7-44 -> xapi_cli.ml:257.4-23
> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
> Xapi_cli.exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI
> Creation failed [opterr=error 127];  ]
> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
> Raised at string.ml:150.25-34 -> stringext.ml:108.13-29
> 
> Thanks,
> Dimitar Kazkov
> <the_kazak.vcf>_______________________________________________
> xen-api mailing list
> xen-api@lists.xen.org
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjbz-00057w-Oj; Thu, 05 Apr 2012 10:08:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jonathan.Ludlam@eu.citrix.com>) id 1SFjby-00057i-5O
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:08:14 +0000
Received: from [85.158.143.35:10600] by server-1.bemta-4.messagelabs.com id
	BE/99-20925-C0F6D7F4; Thu, 05 Apr 2012 10:08:12 +0000
X-Env-Sender: Jonathan.Ludlam@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333620490!7570595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27477 invoked from network); 5 Apr 2012 10:08:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:08:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11789319"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:08:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 5 Apr 2012
	11:08:10 +0100
From: Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
To: Dimitar Kazakov <the.kazak@gmail.com>
Date: Thu, 5 Apr 2012 11:08:08 +0100
Thread-Topic: [Xen-API] xe vdi-create failure ot local SR type=file and
	type=ext
Thread-Index: Ac0TFABqcTeHZXqNSuqhLzKIJ11u8A==
Message-ID: <7549B613-6EB9-4DD8-9741-C0D8556D0176@eu.citrix.com>
References: <4F7D6480.6040704@gmail.com>
In-Reply-To: <4F7D6480.6040704@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-API] xe vdi-create failure ot local SR
 type=file and type=ext
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The log snippet doesn't have the detail in it - have a look in /var/log/SMlog - you might find something more useful in there.

Jon

On 5 Apr 2012, at 10:23, Dimitar Kazakov wrote:

> Hi,
> have permanent failure when try to create VDI on local SR type=file or
> type=ext. On both types it failed with the same error:
> SR_BACKEND_FAILURE_78
> VDI Creation failed [opterr=error 127]
> 
> I am on Debian box with kernel 3.3.0-rc7, Xen version 4.1.2 (Debian
> 4.1.2-2.1), Xen-API Version: 1.3.2-4 (Kronos)
> 
> Is it a bug, or am I missing something? Anybody managed to workaround
> this problem?
> 
> 
> Here is a short extract from xcp-xapi.log
> 
> id=ba4e9e1a-bc42-0dc9-af0e-5db2905666ab type=user name-label=test
> virtual-size=1GiB username=root password=null
> [20120403T07:57:53.973Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
> Session.create trackid=1ef3448b63e70822073569022044e96b pool=false
> uname=root is_local_superuser=true auth_user_sid=
> parent=trackid=9834f5af41c964e225f24279aefe4e49
> [20120403T07:57:53.974Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
> Attempting to open /var/lib/xcp/xapi
> [20120403T07:57:53.975Z|debug|hyperion|547 UNIX
> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
> D:4cab7e7aa9ae created by task D:93575fa7333c
> [20120403T07:57:53.982Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|audit] VDI.create: SR =
> 'ba4e9e1a-bc42-0dc9-af0e-5db2905666ab (Local storage)'; name label = 'test'
> [20120403T07:57:53.983Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Marking SR for
> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
> [20120403T07:57:53.984Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|storage_impl] VDI.create
> task:OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a
> sr:ba4e9e1a-bc42-0dc9-af0e-5db2905666ab vdi_info:{"vdi": "",
> "name_label": "test", "name_description": "", "ty": "user",
> "metadata_of_pool": "", "is_a_snapshot": false, "snapshot_time":
> "19700101T00:00:00Z", "snapshot_of": "", "read_only": false,
> "virtual_size": 1073741824, "physical_utilisation": 0} params:
> [20120403T07:57:53.984Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dummytaskhelper] task
> VDI.create D:db9f2e113fee created by task R:efdfb350d7ac
> [20120403T07:57:53.986Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.create
> trackid=654ed4437d52fe9cdd8e5d98a5955526 pool=false uname=
> is_local_superuser=true auth_user_sid=
> parent=trackid=9834f5af41c964e225f24279aefe4e49
> [20120403T07:57:53.987Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Attempting to open
> /var/lib/xcp/xapi
> [20120403T07:57:53.987Z|debug|hyperion|548 UNIX
> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
> D:3829e36dbb97 created by task D:6ec167aaa83d
> [20120403T07:57:54.066Z|debug|hyperion|549 UNIX
> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:host.get_other_config
> D:c813aaba73c4 created by task D:db9f2e113fee
> [20120403T07:57:54.071Z|debug|hyperion|549 UNIX
> /var/lib/xcp/xapi||http_critical] Premature termination of connection!
> [20120403T07:57:54.109Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
> sm_exec.ml:220.7-69 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.109Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.destroy
> trackid=654ed4437d52fe9cdd8e5d98a5955526
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
> pervasiveext.ml:26.22-25 -> server_helpers.ml:76.11-23
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Server_helpers.exec
> exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI Creation
> failed [opterr=error 127];  ]
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
> pervasiveext.ml:26.22-25 -> sm.ml:132.25-98 ->
> storage_access.ml:259.36-331 -> storage_access.ml:257.28-492 ->
> server_helpers.ml:76.11-23
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher]
> Server_helpers.exec exception_handler: Got exception
> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> storage_access.ml:449.8-47 -> message_forwarding.ml:233.25-44 ->
> pervasiveext.ml:22.2-9
> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Unmarking SR after
> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
> [20120403T07:57:54.111Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
> pervasiveext.ml:26.22-25 -> server.ml:24034.78-280 -> rbac.ml:229.16-23
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
> rbac.ml:238.10-15 -> server_helpers.ml:79.11-41
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher]
> Server_helpers.exec exception_handler: Got exception
> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
> string.ml:150.25-34 -> stringext.ml:108.13-29
> [20120403T07:57:54.114Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|xapi] Raised at
> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|backtrace] Raised
> at pervasiveext.ml:26.22-25 -> server_helpers.ml:153.10-106 ->
> server.ml:24035.19-190 -> server_helpers.ml:119.4-7
> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||xapi]
> Raised at client.ml:6.37-75 -> client.ml:9043.48-106 ->
> cli_operations.ml:1082.11-187 -> xapi_cli.ml:112.18-56 ->
> pervasiveext.ml:22.2-9
> [20120403T07:57:54.117Z| info|hyperion|546 UNIX
> /var/lib/xcp/xapi|session.logout D:2d486a4a5b26|xapi] Session.destroy
> trackid=1ef3448b63e70822073569022044e96b
> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX
> /var/lib/xcp/xapi||backtrace] Raised at pervasiveext.ml:26.22-25 ->
> xapi_cli.ml:111.2-138 -> xapi_cli.ml:205.7-44 -> xapi_cli.ml:257.4-23
> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
> Xapi_cli.exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI
> Creation failed [opterr=error 127];  ]
> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
> Raised at string.ml:150.25-34 -> stringext.ml:108.13-29
> 
> Thanks,
> Dimitar Kazkov
> <the_kazak.vcf>_______________________________________________
> xen-api mailing list
> xen-api@lists.xen.org
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjcC-00059C-8e; Thu, 05 Apr 2012 10:08:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFjcB-000592-9y
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:08:27 +0000
Received: from [85.158.143.35:11759] by server-2.bemta-4.messagelabs.com id
	45/E4-17550-A1F6D7F4; Thu, 05 Apr 2012 10:08:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333620504!7570661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28638 invoked from network); 5 Apr 2012 10:08:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:08:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11789337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:08:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	11:08:24 +0100
Message-ID: <1333620502.937.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Thu, 5 Apr 2012 11:08:22 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-04 at 20:25 +0100, Ross Philipson wrote:
> > If it's convenient (or even just for consistency) there's no reason IMHO
> > not to include the length even where the length is part of the data.
> > Similarly you can add checksums etc if those are useful.
> > 
> 
> Well actually it does not really do any good to have the length in
> xenstore (at least for the types we are currently talking about) other
> than knowing the overall extent of the blob. The problem is that we
> are talking about multiple tables chained together. For ACPI this is
> not a problem because the table length is specified in the table
> header. For SMBIOS (where there will almost certainly be multiple
> tables) the length of each table is not specified and so the set would
> have to be re-parsed in hvmloader to find each individual table.

I see. So you need to be able to find the individual tables so that
smbios_type_<N>_init can check for an overriding table <N> in the
passed-through tables, it seems reasonable to try and avoid needing to
parse a big lump of tables each time to see if the one you are
interested in is there.

I think this can work by having .../smbios/<N>/{address,etc} in
XenStore. You could also have .../smbios/OEM/{...} for the stuff for
smbios_type_vendor_oem_init, which I think could easily just be a single
lump?

I think you don't need the same thing for the ACPI side since there you
just provide secondary tables?

>  That was the motivation for a separate table header we define. I
> still think some simple entry delimiter structure with some small
> amount of information about each item is a good idea.

I think the content of .../smbios/<N>/* serves the same purpose as a
delimiter?

> But in general I don't have a problem with using xenstore for this
> sort of thing so I am fine with the basic concept.
> 
> > > > you'd need to do is have a type code and an address in xenstore
> > > > somewhere, the same way we pass a type code and a string for the
> > > > other BIOS customizations.
> > > >
> > >
> > > So I am not exactly sure how to proceed here since libxc seems the
> > > correct place to load the individual blobs (ACPI tables, SMBIOS junk)
> > > but libxc seems too low level to be writing values to xenstore (and it
> > > does not do that at present). Would it be better to have a peer API to
> > > xc_hvm_build() that write the chunks and returns the addresses where
> > > it loaded them? Or should it be totally moved out of libxc? Advice
> > > would be appreciated...
> > 
> > The layering relationship between libxc and libxs here is a bit of a
> > pain, but lets not try and solve that now.
> > 
> > I think you can just add a guest_address field to your struct
> > xc_hvm_module as an output field which the caller would then push into
> > xenstore along with the (potentially updated) length field.
> > 
> > Given the above XS layout then I think where you have a list of modules
> > in xc_hvm_build_args you can just have "struct xc_hvm_module acpi".
> > Similarly for smbios and whatever new table types come up in the future.
> > I don't think having each module type explicitly here matters since each
> > new table type needs a bunch of support code in at least hvmloader
> > anyway so adding a few lines to libxc to expose it at the same time is
> > fine.
> 
> That seems like a reasonable way to do it. Especially if (wrt below)
> we have the caller glom the like bits together.
> 
> > 
> > > Finally, I had made this a generic framework because I thought it
> > > could be extended in the future to pass in other types of firmware-ish
> > > blobs at runtime. It also handles the case where the passing of one
> > > set of tables/blobs is not tied to passing another set. E.g. in our
> > > work we pass in some static ACPI tables to satisfy one feature and
> > > construct/pass-in an SSDT to satisfy another unrelated feature.
> > 
> > I think it is ok to have it be up to the caller to glom those together
> > into a single "ACPI" blob which is processed by hvmloader into the right
> > places. Or is there a problem with that which hasn't occurred to me?
> > (Likewise in the SMBIOS case)
> > 
> > If it is a problem then
> > 	.../acpi/0/...
> > 	.../acpi/1/...
> > (or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things. Not
> > sure about the libxc level, I'll worry about it when you tell me what
> > I've missed which makes it necessary ;-)
> 
> Well that approach was mostly for flexibility (as in the scenario I
> pointed out). The only other issue might be the measuring of
> components by a domain builder but I don't think that that prevents
> glomming. Presumably the glomming code is part of the overall domain
> builder code so a measure-then-glom operation can happen. And doing
> the merge in the tools makes the code in hvmloader simpler so I am
> good with that.

You've convinced me that having the SMBIOS tables each be presented
separately makes sense.

At the libxc layer you could have "struct xc_hvm_module *smbios". I
expect in the simple case this would just point into an array on the
callers stack but a caller could also do something more dynamic if they
wanted to. If you think it would be useful then a linked-list thing here
would also work.

> Given all that, the only real issue I see at the moment is how to deal
> with multiple entries within a blob that don't readily specify their
> own lengths. I am in favor of a delimiting struct with possibly a
> terminating form (like a flag). Then all we put in xenstore is the gpe
> for each type.
> 
> Finally I wanted to bring up again the idea of another helper
> component (lib maybe) that can be used to build and glom (I like that
> word) modules. Note that in many cases the passed in firmware is going
> to be pulled from the host firmware. I already have bunches of codes
> that do that. Perhaps I should start an RFC thread for that as a
> separate task? Thoughts on this?

You mean some sort of libacpi / libsmbios type things, helper routines
for parsing and manipulating tables etc? (such a thing doesn't already
exist somewhere?)

I suspect your usecases are the ones which would make most extensive use
of such a thing but I also assume that at least some of it would be
useful to any caller which was passing in these tables. If you want to
maintain it within the Xen tree then that works for me.

Ian.

> 
> Thanks
> Ross
> 
> > 
> > 
> > Ian.
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjcC-00059C-8e; Thu, 05 Apr 2012 10:08:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFjcB-000592-9y
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:08:27 +0000
Received: from [85.158.143.35:11759] by server-2.bemta-4.messagelabs.com id
	45/E4-17550-A1F6D7F4; Thu, 05 Apr 2012 10:08:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1333620504!7570661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28638 invoked from network); 5 Apr 2012 10:08:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:08:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11789337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:08:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	11:08:24 +0100
Message-ID: <1333620502.937.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Thu, 5 Apr 2012 11:08:22 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-04 at 20:25 +0100, Ross Philipson wrote:
> > If it's convenient (or even just for consistency) there's no reason IMHO
> > not to include the length even where the length is part of the data.
> > Similarly you can add checksums etc if those are useful.
> > 
> 
> Well actually it does not really do any good to have the length in
> xenstore (at least for the types we are currently talking about) other
> than knowing the overall extent of the blob. The problem is that we
> are talking about multiple tables chained together. For ACPI this is
> not a problem because the table length is specified in the table
> header. For SMBIOS (where there will almost certainly be multiple
> tables) the length of each table is not specified and so the set would
> have to be re-parsed in hvmloader to find each individual table.

I see. So you need to be able to find the individual tables so that
smbios_type_<N>_init can check for an overriding table <N> in the
passed-through tables, it seems reasonable to try and avoid needing to
parse a big lump of tables each time to see if the one you are
interested in is there.

I think this can work by having .../smbios/<N>/{address,etc} in
XenStore. You could also have .../smbios/OEM/{...} for the stuff for
smbios_type_vendor_oem_init, which I think could easily just be a single
lump?

I think you don't need the same thing for the ACPI side since there you
just provide secondary tables?

>  That was the motivation for a separate table header we define. I
> still think some simple entry delimiter structure with some small
> amount of information about each item is a good idea.

I think the content of .../smbios/<N>/* serves the same purpose as a
delimiter?

> But in general I don't have a problem with using xenstore for this
> sort of thing so I am fine with the basic concept.
> 
> > > > you'd need to do is have a type code and an address in xenstore
> > > > somewhere, the same way we pass a type code and a string for the
> > > > other BIOS customizations.
> > > >
> > >
> > > So I am not exactly sure how to proceed here since libxc seems the
> > > correct place to load the individual blobs (ACPI tables, SMBIOS junk)
> > > but libxc seems too low level to be writing values to xenstore (and it
> > > does not do that at present). Would it be better to have a peer API to
> > > xc_hvm_build() that write the chunks and returns the addresses where
> > > it loaded them? Or should it be totally moved out of libxc? Advice
> > > would be appreciated...
> > 
> > The layering relationship between libxc and libxs here is a bit of a
> > pain, but lets not try and solve that now.
> > 
> > I think you can just add a guest_address field to your struct
> > xc_hvm_module as an output field which the caller would then push into
> > xenstore along with the (potentially updated) length field.
> > 
> > Given the above XS layout then I think where you have a list of modules
> > in xc_hvm_build_args you can just have "struct xc_hvm_module acpi".
> > Similarly for smbios and whatever new table types come up in the future.
> > I don't think having each module type explicitly here matters since each
> > new table type needs a bunch of support code in at least hvmloader
> > anyway so adding a few lines to libxc to expose it at the same time is
> > fine.
> 
> That seems like a reasonable way to do it. Especially if (wrt below)
> we have the caller glom the like bits together.
> 
> > 
> > > Finally, I had made this a generic framework because I thought it
> > > could be extended in the future to pass in other types of firmware-ish
> > > blobs at runtime. It also handles the case where the passing of one
> > > set of tables/blobs is not tied to passing another set. E.g. in our
> > > work we pass in some static ACPI tables to satisfy one feature and
> > > construct/pass-in an SSDT to satisfy another unrelated feature.
> > 
> > I think it is ok to have it be up to the caller to glom those together
> > into a single "ACPI" blob which is processed by hvmloader into the right
> > places. Or is there a problem with that which hasn't occurred to me?
> > (Likewise in the SMBIOS case)
> > 
> > If it is a problem then
> > 	.../acpi/0/...
> > 	.../acpi/1/...
> > (or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things. Not
> > sure about the libxc level, I'll worry about it when you tell me what
> > I've missed which makes it necessary ;-)
> 
> Well that approach was mostly for flexibility (as in the scenario I
> pointed out). The only other issue might be the measuring of
> components by a domain builder but I don't think that that prevents
> glomming. Presumably the glomming code is part of the overall domain
> builder code so a measure-then-glom operation can happen. And doing
> the merge in the tools makes the code in hvmloader simpler so I am
> good with that.

You've convinced me that having the SMBIOS tables each be presented
separately makes sense.

At the libxc layer you could have "struct xc_hvm_module *smbios". I
expect in the simple case this would just point into an array on the
callers stack but a caller could also do something more dynamic if they
wanted to. If you think it would be useful then a linked-list thing here
would also work.

> Given all that, the only real issue I see at the moment is how to deal
> with multiple entries within a blob that don't readily specify their
> own lengths. I am in favor of a delimiting struct with possibly a
> terminating form (like a flag). Then all we put in xenstore is the gpe
> for each type.
> 
> Finally I wanted to bring up again the idea of another helper
> component (lib maybe) that can be used to build and glom (I like that
> word) modules. Note that in many cases the passed in firmware is going
> to be pulled from the host firmware. I already have bunches of codes
> that do that. Perhaps I should start an RFC thread for that as a
> separate task? Thoughts on this?

You mean some sort of libacpi / libsmbios type things, helper routines
for parsing and manipulating tables etc? (such a thing doesn't already
exist somewhere?)

I suspect your usecases are the ones which would make most extensive use
of such a thing but I also assume that at least some of it would be
useful to any caller which was passing in these tables. If you want to
maintain it within the Xen tree then that works for me.

Ian.

> 
> Thanks
> Ross
> 
> > 
> > 
> > Ian.
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:09:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjcS-0005BZ-LT; Thu, 05 Apr 2012 10:08:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjcR-0005BB-8x
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:08:43 +0000
Received: from [85.158.143.99:59375] by server-2.bemta-4.messagelabs.com id
	BA/65-17550-A2F6D7F4; Thu, 05 Apr 2012 10:08:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333620521!17220800!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16296 invoked from network); 5 Apr 2012 10:08:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:08:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjcN-00043F-TQ; Thu, 05 Apr 2012 10:08:39 +0000
Date: Thu, 5 Apr 2012 11:08:39 +0100
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120405100839.GA14774@ocelot.phlegethon.org>
References: <34d9828185501f6e7ea2.1333120245@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <34d9828185501f6e7ea2.1333120245@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: add error code to indicate
	iommem passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:10 +0200 on 30 Mar (1333127445), Olaf Hering wrote:
> xenpaging: add error code to indicate iommem passthrough
> 
> Similar to the existing ENODEV and EXDEV error codes, add EMDEV to
> indicate that iommu passthrough is not compatible with paging.
> All error codes are just made-up return codes to give proper error
> messages in the pager.
> 
> Also update the HAP related error message now that paging is enabled
> also on AMD hosts.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:09:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjcS-0005BZ-LT; Thu, 05 Apr 2012 10:08:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjcR-0005BB-8x
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:08:43 +0000
Received: from [85.158.143.99:59375] by server-2.bemta-4.messagelabs.com id
	BA/65-17550-A2F6D7F4; Thu, 05 Apr 2012 10:08:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333620521!17220800!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16296 invoked from network); 5 Apr 2012 10:08:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:08:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjcN-00043F-TQ; Thu, 05 Apr 2012 10:08:39 +0000
Date: Thu, 5 Apr 2012 11:08:39 +0100
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120405100839.GA14774@ocelot.phlegethon.org>
References: <34d9828185501f6e7ea2.1333120245@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <34d9828185501f6e7ea2.1333120245@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: add error code to indicate
	iommem passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:10 +0200 on 30 Mar (1333127445), Olaf Hering wrote:
> xenpaging: add error code to indicate iommem passthrough
> 
> Similar to the existing ENODEV and EXDEV error codes, add EMDEV to
> indicate that iommu passthrough is not compatible with paging.
> All error codes are just made-up return codes to give proper error
> messages in the pager.
> 
> Also update the HAP related error message now that paging is enabled
> also on AMD hosts.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjcp-0005GK-2T; Thu, 05 Apr 2012 10:09:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjcn-0005Fo-Fa
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:09:05 +0000
Received: from [85.158.138.51:36259] by server-11.bemta-3.messagelabs.com id
	6E/A4-28543-E3F6D7F4; Thu, 05 Apr 2012 10:09:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333620541!20883348!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23608 invoked from network); 5 Apr 2012 10:09:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:09:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjcj-00043W-G5; Thu, 05 Apr 2012 10:09:01 +0000
Date: Thu, 5 Apr 2012 11:09:01 +0100
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120405100901.GB14774@ocelot.phlegethon.org>
References: <77e9be40fbc8ef0df02e.1333466642@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <77e9be40fbc8ef0df02e.1333466642@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] domctl.h: document non-standard error codes
	for enabling paging/access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:24 +0200 on 03 Apr (1333473842), Olaf Hering wrote:
> domctl.h: document non-standard error codes for enabling paging/access
> 
> The domctl to enable paging and access returns some non-standard error
> codes after failure. This can be used in the tools to print specific
> error messages. xenpaging recognizes these errno values and shows them
> if the init function fails.
> 
> Document the return codes in the public header file.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjcp-0005GK-2T; Thu, 05 Apr 2012 10:09:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjcn-0005Fo-Fa
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:09:05 +0000
Received: from [85.158.138.51:36259] by server-11.bemta-3.messagelabs.com id
	6E/A4-28543-E3F6D7F4; Thu, 05 Apr 2012 10:09:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333620541!20883348!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23608 invoked from network); 5 Apr 2012 10:09:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:09:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjcj-00043W-G5; Thu, 05 Apr 2012 10:09:01 +0000
Date: Thu, 5 Apr 2012 11:09:01 +0100
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120405100901.GB14774@ocelot.phlegethon.org>
References: <77e9be40fbc8ef0df02e.1333466642@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <77e9be40fbc8ef0df02e.1333466642@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] domctl.h: document non-standard error codes
	for enabling paging/access
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:24 +0200 on 03 Apr (1333473842), Olaf Hering wrote:
> domctl.h: document non-standard error codes for enabling paging/access
> 
> The domctl to enable paging and access returns some non-standard error
> codes after failure. This can be used in the tools to print specific
> error messages. xenpaging recognizes these errno values and shows them
> if the init function fails.
> 
> Document the return codes in the public header file.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjdD-0005MF-I7; Thu, 05 Apr 2012 10:09:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjdC-0005Lw-Lv
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:09:30 +0000
Received: from [193.109.254.147:28095] by server-9.bemta-14.messagelabs.com id
	16/63-05787-95F6D7F4; Thu, 05 Apr 2012 10:09:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333620569!886157!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12406 invoked from network); 5 Apr 2012 10:09:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:09:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjd9-00043r-3b; Thu, 05 Apr 2012 10:09:27 +0000
Date: Thu, 5 Apr 2012 11:09:27 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120405100927.GC14774@ocelot.phlegethon.org>
References: <6a3e651ee3b6123eca9c.1333554512@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6a3e651ee3b6123eca9c.1333554512@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, adin@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem sharing: Take care of domain
	reference for shared pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:48 -0400 on 04 Apr (1333540112), Andres Lagar-Cavilla wrote:
> Making a page sharable removes it from the previous owner's list. Making it
> private adds it. These actions are similar to freeing or allocating a page.
> Except that they were not minding the domain reference that is taken/dropped
> when the first/last page is allocated/freed.
> 
> Without fixing this, a domain might remain zombie when destroyed if all its
> pages are shared.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjdD-0005MF-I7; Thu, 05 Apr 2012 10:09:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjdC-0005Lw-Lv
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:09:30 +0000
Received: from [193.109.254.147:28095] by server-9.bemta-14.messagelabs.com id
	16/63-05787-95F6D7F4; Thu, 05 Apr 2012 10:09:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333620569!886157!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12406 invoked from network); 5 Apr 2012 10:09:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:09:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjd9-00043r-3b; Thu, 05 Apr 2012 10:09:27 +0000
Date: Thu, 5 Apr 2012 11:09:27 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120405100927.GC14774@ocelot.phlegethon.org>
References: <6a3e651ee3b6123eca9c.1333554512@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6a3e651ee3b6123eca9c.1333554512@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, adin@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem sharing: Take care of domain
	reference for shared pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:48 -0400 on 04 Apr (1333540112), Andres Lagar-Cavilla wrote:
> Making a page sharable removes it from the previous owner's list. Making it
> private adds it. These actions are similar to freeing or allocating a page.
> Except that they were not minding the domain reference that is taken/dropped
> when the first/last page is allocated/freed.
> 
> Without fixing this, a domain might remain zombie when destroyed if all its
> pages are shared.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjhq-0005uU-Gy; Thu, 05 Apr 2012 10:14:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1SFjhp-0005tx-1N
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:14:17 +0000
Received: from [85.158.143.99:26306] by server-2.bemta-4.messagelabs.com id
	3B/9F-17550-8707D7F4; Thu, 05 Apr 2012 10:14:16 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333620854!17181256!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyMzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11159 invoked from network); 5 Apr 2012 10:14:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	5 Apr 2012 10:14:15 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q35AEAbD014529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 06:14:10 -0400
Received: from yakj.usersys.redhat.com (ovpn-112-21.ams2.redhat.com
	[10.36.112.21])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q35AE6C1026318; Thu, 5 Apr 2012 06:14:07 -0400
Message-ID: <4F7D706D.5030507@redhat.com>
Date: Thu, 05 Apr 2012 12:14:05 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
In-Reply-To: <1333618350.2513.5.camel@leeds.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, liuw@liuw.name
Subject: Re: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 05/04/2012 11:32, Wei Liu ha scritto:
> Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
> Xen HVM guests.

Only skimmed the patch but yeah, this is what I had in mind.  Thanks!

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjhq-0005uU-Gy; Thu, 05 Apr 2012 10:14:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1SFjhp-0005tx-1N
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:14:17 +0000
Received: from [85.158.143.99:26306] by server-2.bemta-4.messagelabs.com id
	3B/9F-17550-8707D7F4; Thu, 05 Apr 2012 10:14:16 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333620854!17181256!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyMzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11159 invoked from network); 5 Apr 2012 10:14:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	5 Apr 2012 10:14:15 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q35AEAbD014529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 06:14:10 -0400
Received: from yakj.usersys.redhat.com (ovpn-112-21.ams2.redhat.com
	[10.36.112.21])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q35AE6C1026318; Thu, 5 Apr 2012 06:14:07 -0400
Message-ID: <4F7D706D.5030507@redhat.com>
Date: Thu, 05 Apr 2012 12:14:05 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
In-Reply-To: <1333618350.2513.5.camel@leeds.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, liuw@liuw.name
Subject: Re: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 05/04/2012 11:32, Wei Liu ha scritto:
> Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
> Xen HVM guests.

Only skimmed the patch but yeah, this is what I had in mind.  Thanks!

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjjJ-00062l-03; Thu, 05 Apr 2012 10:15:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjjI-00062g-78
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:15:48 +0000
Received: from [85.158.138.51:62783] by server-3.bemta-3.messagelabs.com id
	79/B3-10665-3D07D7F4; Thu, 05 Apr 2012 10:15:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333620946!20916433!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14704 invoked from network); 5 Apr 2012 10:15:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:15:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjjE-00045M-PT; Thu, 05 Apr 2012 10:15:44 +0000
Date: Thu, 5 Apr 2012 11:15:44 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120405101544.GD14774@ocelot.phlegethon.org>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, adin@gridcentric.ca,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
> Document the sharing libxc interface, including failure conditions, meaning of
> stats, and internal semantics/behavior.
> 
> Also remove a stale debug call.
> 
> Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits. Both
> patches touch the tools. Patch #2 is entirely documentation comments.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjjJ-00062l-03; Thu, 05 Apr 2012 10:15:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjjI-00062g-78
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:15:48 +0000
Received: from [85.158.138.51:62783] by server-3.bemta-3.messagelabs.com id
	79/B3-10665-3D07D7F4; Thu, 05 Apr 2012 10:15:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333620946!20916433!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14704 invoked from network); 5 Apr 2012 10:15:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:15:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFjjE-00045M-PT; Thu, 05 Apr 2012 10:15:44 +0000
Date: Thu, 5 Apr 2012 11:15:44 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120405101544.GD14774@ocelot.phlegethon.org>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1333393862@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, adin@gridcentric.ca,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
> Document the sharing libxc interface, including failure conditions, meaning of
> stats, and internal semantics/behavior.
> 
> Also remove a stale debug call.
> 
> Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits. Both
> patches touch the tools. Patch #2 is entirely documentation comments.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjja-00063r-D9; Thu, 05 Apr 2012 10:16:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.paumonne@eu.citrix.com>) id 1SF3ol-00017F-W4
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:30:40 +0000
Received: from [85.158.143.99:6359] by server-3.bemta-4.messagelabs.com id
	B6/45-05853-F7BFA7F4; Tue, 03 Apr 2012 13:30:39 +0000
X-Env-Sender: roger.paumonne@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333459837!23591169!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22107 invoked from network); 3 Apr 2012 13:30:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:30:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="23817772"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 09:30:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 09:30:36 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.paumonne@eu.citrix.com>)	id 1SF3oi-0001WY-GC; Tue, 03 Apr 2012
	14:30:36 +0100
Date: Tue, 3 Apr 2012 14:30:38 +0100
From: Roger Pau Monne <roger.paumonne@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403133038.GA84917@dhcp-3-120.uk.xensource.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
	<1333450007.25602.130.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333450007.25602.130.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 05 Apr 2012 10:16:05 +0000
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>,
	"staff@orionvm.com.au" <staff@orionvm.com.au>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 11:46:47AM +0100, Ian Campbell wrote:
> On Mon, 2012-04-02 at 18:59 +0100, Joseph Glanville wrote:
> > On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> > >> Hi guys,
> > >>
> > >> I have started preparing a library of PV-HVM templates for use on Xen
> > >> 4.X+ and PVOPS dom0.
> > > [...]
> > >> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> > >> (the final beta, will be updated to final shortly).
> > >> Included is an OS image, a config file, a README and the associated
> > >> licences etc.
> > >
> > > This is very cool, and you are correct that these will be very useful
> > > for people trying to get something going quickly! Thanks Joseph.
> > 
> > No problem, I am working on a new dom0 livecd too.
> > 
> > I need some recommendations on what distro to base it on though...
> > Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
> > to be more enduring and a more beginner approachable alternative.
> > 
> > Does anyone have any thoughts on this?
> 

I've been working with the Alpine Linux guys (http://alpinelinux.org/)
for some time, and we managed to get a working Xen LiveCD, next major 
release (2.4 I think) it's gonna come with Xen Dom0 LiveCDs, since all 
the necessary bits have been added to the upstream distro build 
scripts. You can take a look at the build scripts here:

http://git.alpinelinux.org/cgit/alpine-iso/

It's really easy to generate a LiveCD iso, you just need a working 
Alpine Linux install (which can be a VM) and the alpine-iso scripts.

> My personal preference would be Debian ;-) But pragmatically Ubuntu is,
> I think, generally thought to be a good beginner distro and conveniently
> it now contains support for Xen so that seems like a good choice.
> 
> Also on the plus side is that Ubuntu may well contain the "Debian Live"
> packages/infrastructure which make building Live CDs easier (I presume,
> I've never tried them). I don't know if that's actually what is used by
> Ubuntu to make their live CDs, if not then I'd hope that infrastructure
> was in Ubuntu too.
> 
> Ian.
> 
> > 
> > >
> > >> The images are bz2 compressed blockdevice images suitable for use on
> > >> LVM or a file backed tapdisk if you have the appropriate backend.
> > >> (alternatively you can use the loop device but this is discouraged)
> > >> All images have serial console enabled, PV network and block devices,
> > >> fixed udev rules etc.
> > >>
> > >> I will add more info about them, an FAQ about how they are setup and
> > >> what you should do to customize them, expand the disk image etc soon.
> > >>
> > >> I am looking for someone to mirror these in the US for me, please
> > >> email me if you have spare bandwith.
> > >>
> > >> Joseph.
> > >>
> > >
> > >
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjja-00063r-D9; Thu, 05 Apr 2012 10:16:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.paumonne@eu.citrix.com>) id 1SF3ol-00017F-W4
	for xen-devel@lists.xensource.com; Tue, 03 Apr 2012 13:30:40 +0000
Received: from [85.158.143.99:6359] by server-3.bemta-4.messagelabs.com id
	B6/45-05853-F7BFA7F4; Tue, 03 Apr 2012 13:30:39 +0000
X-Env-Sender: roger.paumonne@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333459837!23591169!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQzNTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22107 invoked from network); 3 Apr 2012 13:30:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Apr 2012 13:30:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,363,1330923600"; d="scan'208";a="23817772"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Apr 2012 09:30:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 3 Apr 2012 09:30:36 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.paumonne@eu.citrix.com>)	id 1SF3oi-0001WY-GC; Tue, 03 Apr 2012
	14:30:36 +0100
Date: Tue, 3 Apr 2012 14:30:38 +0100
From: Roger Pau Monne <roger.paumonne@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120403133038.GA84917@dhcp-3-120.uk.xensource.com>
References: <CAOzFzEi3DwFZn_Ta_unEWkeARDKhNkExZXYo+scfbtEhw6dA3g@mail.gmail.com>
	<1333383095.25602.94.camel@zakaz.uk.xensource.com>
	<CAOzFzEiLG3xeKqLWS8UORg2NKGOqe-ndmhwA_vcWBUrbvREq=g@mail.gmail.com>
	<1333450007.25602.130.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1333450007.25602.130.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 05 Apr 2012 10:16:05 +0000
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	xen-devel <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>,
	"staff@orionvm.com.au" <staff@orionvm.com.au>
Subject: Re: [Xen-devel] [ANNOUNCE] Prebuilt Xen PV-HVM templates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 11:46:47AM +0100, Ian Campbell wrote:
> On Mon, 2012-04-02 at 18:59 +0100, Joseph Glanville wrote:
> > On 3 April 2012 02:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Sun, 2012-04-01 at 19:16 +0100, Joseph Glanville wrote:
> > >> Hi guys,
> > >>
> > >> I have started preparing a library of PV-HVM templates for use on Xen
> > >> 4.X+ and PVOPS dom0.
> > > [...]
> > >> Initially there is Debian 6, CentOS 6.2 and Ubuntu 12.04 available
> > >> (the final beta, will be updated to final shortly).
> > >> Included is an OS image, a config file, a README and the associated
> > >> licences etc.
> > >
> > > This is very cool, and you are correct that these will be very useful
> > > for people trying to get something going quickly! Thanks Joseph.
> > 
> > No problem, I am working on a new dom0 livecd too.
> > 
> > I need some recommendations on what distro to base it on though...
> > Personally Gentoo is easiest for me but I think Ubuntu 12.04 is going
> > to be more enduring and a more beginner approachable alternative.
> > 
> > Does anyone have any thoughts on this?
> 

I've been working with the Alpine Linux guys (http://alpinelinux.org/)
for some time, and we managed to get a working Xen LiveCD, next major 
release (2.4 I think) it's gonna come with Xen Dom0 LiveCDs, since all 
the necessary bits have been added to the upstream distro build 
scripts. You can take a look at the build scripts here:

http://git.alpinelinux.org/cgit/alpine-iso/

It's really easy to generate a LiveCD iso, you just need a working 
Alpine Linux install (which can be a VM) and the alpine-iso scripts.

> My personal preference would be Debian ;-) But pragmatically Ubuntu is,
> I think, generally thought to be a good beginner distro and conveniently
> it now contains support for Xen so that seems like a good choice.
> 
> Also on the plus side is that Ubuntu may well contain the "Debian Live"
> packages/infrastructure which make building Live CDs easier (I presume,
> I've never tried them). I don't know if that's actually what is used by
> Ubuntu to make their live CDs, if not then I'd hope that infrastructure
> was in Ubuntu too.
> 
> Ian.
> 
> > 
> > >
> > >> The images are bz2 compressed blockdevice images suitable for use on
> > >> LVM or a file backed tapdisk if you have the appropriate backend.
> > >> (alternatively you can use the loop device but this is discouraged)
> > >> All images have serial console enabled, PV network and block devices,
> > >> fixed udev rules etc.
> > >>
> > >> I will add more info about them, an FAQ about how they are setup and
> > >> what you should do to customize them, expand the disk image etc soon.
> > >>
> > >> I am looking for someone to mirror these in the US for me, please
> > >> email me if you have spare bandwith.
> > >>
> > >> Joseph.
> > >>
> > >
> > >
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjt8-0006PE-HE; Thu, 05 Apr 2012 10:25:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjt6-0006P9-QI
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:25:56 +0000
Received: from [193.109.254.147:35001] by server-4.bemta-14.messagelabs.com id
	EA/EB-11570-3337D7F4; Thu, 05 Apr 2012 10:25:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333621545!3364848!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23761 invoked from network); 5 Apr 2012 10:25:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:25:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189131356"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 06:25:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 06:25:45 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFjsu-00083K-4c; Thu, 05 Apr 2012 11:25:44 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFjst-0007Rt-Tb;
	Thu, 05 Apr 2012 11:25:43 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
Message-ID: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 11:25:43 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333621466 -3600
# Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
tools/blktap2: fix 'make clean'

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r d690c7e896a2 -r 4b6bf18b6790 tools/blktap2/lvm/Makefile
--- a/tools/blktap2/lvm/Makefile	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/blktap2/lvm/Makefile	Thu Apr 05 11:24:26 2012 +0100
@@ -27,7 +27,7 @@ lvm-util: lvm-util.o
 	$(CC) -DLVM_UTIL $(LDFLAGS) -o lvm-util lvm-util.c
 
 clean:
-	rm -rf *.o *~ $(DEPS) $(IBIN)
+	rm -rf *.o *.opic *~ $(DEPS) $(IBIN)
 
 .PHONY: all build clean install lvm-util
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFjt8-0006PE-HE; Thu, 05 Apr 2012 10:25:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFjt6-0006P9-QI
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:25:56 +0000
Received: from [193.109.254.147:35001] by server-4.bemta-14.messagelabs.com id
	EA/EB-11570-3337D7F4; Thu, 05 Apr 2012 10:25:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333621545!3364848!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23761 invoked from network); 5 Apr 2012 10:25:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:25:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189131356"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 06:25:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 06:25:45 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFjsu-00083K-4c; Thu, 05 Apr 2012 11:25:44 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFjst-0007Rt-Tb;
	Thu, 05 Apr 2012 11:25:43 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
Message-ID: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 11:25:43 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333621466 -3600
# Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
tools/blktap2: fix 'make clean'

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r d690c7e896a2 -r 4b6bf18b6790 tools/blktap2/lvm/Makefile
--- a/tools/blktap2/lvm/Makefile	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/blktap2/lvm/Makefile	Thu Apr 05 11:24:26 2012 +0100
@@ -27,7 +27,7 @@ lvm-util: lvm-util.o
 	$(CC) -DLVM_UTIL $(LDFLAGS) -o lvm-util lvm-util.c
 
 clean:
-	rm -rf *.o *~ $(DEPS) $(IBIN)
+	rm -rf *.o *.opic *~ $(DEPS) $(IBIN)
 
 .PHONY: all build clean install lvm-util
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:37:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:37:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk4M-0006ZO-N0; Thu, 05 Apr 2012 10:37:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFk4K-0006ZJ-Kx
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:37:32 +0000
Received: from [85.158.139.83:17138] by server-2.bemta-5.messagelabs.com id
	72/ED-17016-BE57D7F4; Thu, 05 Apr 2012 10:37:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333622250!22521790!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1908 invoked from network); 5 Apr 2012 10:37:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:37:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFk4H-00049A-DM; Thu, 05 Apr 2012 10:37:29 +0000
Date: Thu, 5 Apr 2012 11:37:29 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120405103729.GE14774@ocelot.phlegethon.org>
References: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:52 +0100 on 29 Mar (1333025578), Francisco Rocha wrote:
> Why is e820 being used in arch_init_memory (xen/arch/x86/mm.c in my
> case) and not boot_e820 (the one we changed)?  I am asking because
> from what I understand this will make my use of reserve_e820_ram
> useless, but I think I still not have all the information I need to
> know how it all connects.

arch_init_memory() is only using e820 to find out which addresses are
MMIO regions.  If we were to use boot_e820 we would mark all the
reserve_e820_ram()'d regions as MMIO, which is probably not what you
want.

> To create a range that I can later use as a guest's RAM can I use
> dom_cow instead of dom_io in arch_init_memory? 

No! dom_cow is the owner of all copy-on-write shared pages.  You don't
want to get your reserved area caught up in that lot. :)

> Or will that create problems when allocating the pages to an
> unprivileged domain?  I don't want that memory range in use by the
> main memory pool used by the allocators.

AIUI just calling reserve_e820_ram() to exclude the memory from
boot_e820 should DTRT.  Is that not working for you?

> From what I understand. The pages must have to be assigned to a particular domain, dom_xen|io|cow.
> I see this as keeping them mapped and usable before assigning them to the domU I want. Is that thought correct?

I think it shoudl be OK to leave them with no owner -- as long as
they're not in the memory allocator's free pools they won't get given to
any other domain.  Then once you're ready to use them you can assign the
directly to your domU.

Another option would be to assign them to dom_xen and use
share_xen_page_with_guest to let domU map them.

Can you give us some details about how your current approach is failing?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:37:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:37:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk4M-0006ZO-N0; Thu, 05 Apr 2012 10:37:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFk4K-0006ZJ-Kx
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:37:32 +0000
Received: from [85.158.139.83:17138] by server-2.bemta-5.messagelabs.com id
	72/ED-17016-BE57D7F4; Thu, 05 Apr 2012 10:37:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333622250!22521790!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1908 invoked from network); 5 Apr 2012 10:37:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 10:37:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFk4H-00049A-DM; Thu, 05 Apr 2012 10:37:29 +0000
Date: Thu, 5 Apr 2012 11:37:29 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120405103729.GE14774@ocelot.phlegethon.org>
References: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:52 +0100 on 29 Mar (1333025578), Francisco Rocha wrote:
> Why is e820 being used in arch_init_memory (xen/arch/x86/mm.c in my
> case) and not boot_e820 (the one we changed)?  I am asking because
> from what I understand this will make my use of reserve_e820_ram
> useless, but I think I still not have all the information I need to
> know how it all connects.

arch_init_memory() is only using e820 to find out which addresses are
MMIO regions.  If we were to use boot_e820 we would mark all the
reserve_e820_ram()'d regions as MMIO, which is probably not what you
want.

> To create a range that I can later use as a guest's RAM can I use
> dom_cow instead of dom_io in arch_init_memory? 

No! dom_cow is the owner of all copy-on-write shared pages.  You don't
want to get your reserved area caught up in that lot. :)

> Or will that create problems when allocating the pages to an
> unprivileged domain?  I don't want that memory range in use by the
> main memory pool used by the allocators.

AIUI just calling reserve_e820_ram() to exclude the memory from
boot_e820 should DTRT.  Is that not working for you?

> From what I understand. The pages must have to be assigned to a particular domain, dom_xen|io|cow.
> I see this as keeping them mapped and usable before assigning them to the domU I want. Is that thought correct?

I think it shoudl be OK to leave them with no owner -- as long as
they're not in the memory allocator's free pools they won't get given to
any other domain.  Then once you're ready to use them you can assign the
directly to your domU.

Another option would be to assign them to dom_xen and use
share_xen_page_with_guest to let domU map them.

Can you give us some details about how your current approach is failing?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:38:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk4b-0006aA-2u; Thu, 05 Apr 2012 10:37:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFk4a-0006Zy-2f
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:37:48 +0000
Received: from [85.158.138.51:40324] by server-3.bemta-3.messagelabs.com id
	0F/68-10665-BF57D7F4; Thu, 05 Apr 2012 10:37:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333622266!16728009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18724 invoked from network); 5 Apr 2012 10:37:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:37:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11790704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:37:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	11:37:42 +0100
Message-ID: <1333622260.937.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Thu, 5 Apr 2012 11:37:40 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
 support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
>                              From: 
> Ross Philipson
> <Ross.Philipson@citrix.com>
>                                To: 
> xen-devel@lists.xensource.com
> <xen-devel@lists.xensource.com>
>                           Subject: 
> [Xen-devel] [PATCH 04/07] HVM
> firmware passthrough: SMBIOS
> support
>                              Date: 
> Mon, 19 Mar 2012 22:04:09 +0000
>                        Message-id: 
> <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
> 
> 
> Pass through support for the SMBIOS tables including a few new
> DMTF defines types and support of OEM defined tables. Passed in
> SMBIOS types override the default internal values. Flags control
> the new tables so that with default values the SMBIOS tables look
> exactly as they do before the patches.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> 
> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (hvm-firmware-passthrough-04.patch)
> 
> # HG changeset patch
> # Parent a0d871dadf1d482d77bf57a059a55098e2bfb078
> Pass through support for the SMBIOS tables including a few new
> DMTF defines types and support of OEM defined tables. Passed in
> SMBIOS types override the default internal values. Flags control
> the new tables so that with default values the SMBIOS tables look
> exactly as they do before the patches.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> diff -r a0d871dadf1d tools/firmware/hvmloader/smbios.c
> --- a/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:45:12 2012 -0400
> +++ b/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:52:13 2012 -0400
> @@ -23,8 +23,10 @@
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/version.h>
> +#include <xen/hvm/hvm_defs.h>
>  #include "smbios_types.h"
>  #include "util.h"
> +#include "modules.h"
>  #include "hypercall.h"
>  
>  static int
> @@ -49,6 +51,8 @@ static void *
>  smbios_type_1_init(void *start, const char *xen_version, 
>                     uint8_t uuid[16]);
>  static void *
> +smbios_type_2_init(void *start);
> +static void *
>  smbios_type_3_init(void *start);
>  static void *
>  smbios_type_4_init(void *start, unsigned int cpu_number,
> @@ -64,8 +68,14 @@ smbios_type_19_init(void *start, uint32_
>  static void *
>  smbios_type_20_init(void *start, uint32_t memory_size_mb, int
> instance);
>  static void *
> +smbios_type_22_init(void *start);
> +static void *
>  smbios_type_32_init(void *start);
>  static void *
> +smbios_type_39_init(void *start);
> +static void *
> +smbios_type_vendor_oem_init(void *start);
> +static void *
>  smbios_type_127_init(void *start);
>  
>  static void
> @@ -85,6 +95,35 @@ get_cpu_manufacturer(char *buf, int len)
>          strncpy(buf, "unknown", len);
>  }
>  
> +static uint32_t
> +get_smbios_control_flags(void)
> +{
> +    static uint64_t flags;
> +    static int read = 0;
> +
> +    if ( !read )
> +    {
> +        flags = strtoll(xenstore_read(HVM_XS_SMBIOS_FLAGS, "0"),
> NULL, 0);

Rather than encoding these as a bit field, written as ascii into
xenstore and then parsed back into a number again I think you may as
well just have a node for each individual flag.

> +        read = 1;
> +    }
> +
> +    return (uint32_t)flags;
> +}
> +
> +static void*
> +get_smbios_passthrough_table(uint8_t type, uint32_t *length_out)
> +{
> +    struct hvm_modules_iterator iter;
> +    uint32_t flags = get_smbios_control_flags();
> +
> +    if ( flags & HVM_SMBIOS_DISABLE_PASSTHROUGH )

This check is the same as just not providing the tables?

> +        return NULL;
> +
> +    init_smbios_module_iterator(&iter, type, 0);
> +
> +    return hvm_find_module_entry(&iter, length_out);
> +}
> +
>  static int
>  write_smbios_tables(void *ep, void *start,
>                      uint32_t vcpus, uint64_t memsize,
> [...]
> @@ -338,6 +393,18 @@ smbios_type_1_init(void *start, const ch
>      char uuid_str[37];
>      struct smbios_type_1 *p = (struct smbios_type_1 *)start;
>      const char *s;
> +    void *ptable;
> +    uint32_t length;
> +
> +    ptable = get_smbios_passthrough_table(1, &length);
> +    if ( (ptable != NULL)&&(length > 0) )
> +    {
> +        memcpy(start, ptable, length);
> +
> +        /* Fix up, use consistent handles */
> +        p->header.handle = 0x100;
> +        return (start + length);
> +    }

This seems like a pretty common pattern, could it be pulled up into the
caller of all these init functions?

I know it's a pre-existing problem but perhaps giving the handle numbers
#defined names would make things a bit more obvious. For the OEM tables
and the potential for clashes (which you commented on in that function)
at least then there would be a sort of index of the ones which are
used. 

I suppose you could also then push responsibility for maintaining this
consistency up to whoever was providing the table and if they wanted
they could use there own numbering and ensure consistency across the
board themselves.

>      memset(p, 0, sizeof(*p));
>  
> @@ -380,12 +447,90 @@ smbios_type_1_init(void *start, const ch
>      return start+1; 
>  }
>  
> +/* Type 2 -- System Board */
> +static void *
> +smbios_type_2_init(void *start)
> +{
> +    struct smbios_type_2 *p = (struct smbios_type_2 *)start;
> +    uint8_t *bptr;
> +    const char *s;
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( (get_smbios_control_flags() &
> HVM_SMBIOS_INCLUDE_SYSTEM_BOARD) == 0 )

Is there any reason you wouldn't want this table now that you've added
it?

> +        return start;
> +
> +    ptable = get_smbios_passthrough_table(2, &length);
> +    if ( (ptable != NULL)&&(length > 0) )
> +    {
> +        memcpy(start, ptable, length);
> +
> +        /* Fix up, use consistent handles, set chassis handle */
> +        p->header.handle = 0x200;
> +
> +        if ( p->header.length >= 13 )
> +        {
> +            bptr = ((uint8_t*)start) + 11;
> +            if ( *((uint16_t*)bptr) != 0 )
> +                *((uint16_t*)bptr) = 0x300; /* current chassis handle

This is to match the handle of the type 3 table?

I don't see a corresponding thing in the constructed version of this
table below, is that normal?

>  */
> +        }
> +
> +        return (start + length);
> +    }
> +
> +    memset(p, 0, sizeof(*p));
> +
> +    p->header.type = 2;
> +    p->header.length = sizeof(struct smbios_type_2);
> +    p->header.handle = 0x200;
> +
> +    p->manufacturer_str = 1;
> +    p->product_name_str = 2;
> +    p->version_str = 0;
> +    p->serial_number_str = 0;
> +
> +    start += sizeof(struct smbios_type_2);
> +
> +    s = xenstore_read("bios-strings/board-manufacturer", "Xen");
> +    strcpy((char *)start, s);
> +    start += strlen(s) + 1;
> +
> +    s = xenstore_read("bios-strings/board-product-name", "HVM domU");
> +    strcpy((char *)start, s);
> +    start += strlen(s) + 1;
> +
> +    /* no internal defaults for this if the value is not set */
> +    s = xenstore_read("bios-strings/board-serial-number", NULL);
> +    if ( (s != NULL)&&(*s != '\0') )
> +    {
> +        strcpy((char *)start, s);
> +        start += strlen(s) + 1;        
> +        p->serial_number_str = 3;
> +    }
> +
> +    *((uint8_t *)start) = 0;
> +    return start+1;
> +}

[...]
> @@ -403,9 +548,20 @@ smbios_type_3_init(void *start)
>      p->security_status = 0x02; /* unknown */
>  
>      start += sizeof(struct smbios_type_3);
> -    
> -    strcpy((char *)start, "Xen");
> -    start += strlen("Xen") + 1;
> +
> +    s = xenstore_read("bios-strings/enclosure-manufacturer", "Xen");
> +    strcpy((char *)start, s);
> +    start += strlen(s) + 1;
> +
> +    /* no internal defaults for this if the value is not set */
> +    s = xenstore_read("bios-strings/enclosure-serial-number", NULL);
> +    if ( (s != NULL)&&(*s != '\0') )
> +    {
> +        strcpy((char *)start, s);
> +        start += strlen(s) + 1;
> +        p->serial_number_str = 2;
> +    }
> +
>      *((uint8_t *)start) = 0;
>      return start+1;
>  }
[...]
> @@ -609,6 +777,66 @@ smbios_type_20_init(void *start, uint32_
>      return start+2;
>  }
>  
> +/* Type 22 -- Portable Battery */
> +static void *
> +smbios_type_22_init(void *start)
> +{
> +    struct smbios_type_22 *p = (struct smbios_type_22 *)start;
> +    static const char *smbios_release_date = __SMBIOS_DATE__;
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( (get_smbios_control_flags() &
> HVM_SMBIOS_INCLUDE_PORTABLE_BATTERY)
> +          == 0 )
> +        return start;

Could an argument be made here that either you want to pass through some
underlying table or you don't want the table at all? Or is there a use
case for having hvmloader fake one up?

> +
> +    ptable = get_smbios_passthrough_table(22, &length);
> +    if ( (ptable != NULL)&&(length > 0) )
> +    {
> +        memcpy(start, ptable, length);
> +
> +        /* Fix up, use consistent handles */
> +        p->header.handle = 0x1600;
> +        return (start + length);
> +    }
> +
> +    memset(p, 0, sizeof(*p));
> +
> +    p->header.type = 22;
> +    p->header.length = sizeof(struct smbios_type_22);
> +    p->header.handle = 0x1600;
> +
> +    p->location_str = 1;
> +    p->manufacturer_str = 2;
> +    p->manufacturer_date_str = 3;
> +    p->serial_number_str = 0;
> +    p->device_name_str = 4;
> +    p->device_chemistry = 0x2; /* Unknown */
> +    p->device_capacity = 0; /* Unknown */
> +    p->device_voltage = 0; /* Unknown */
> +    p->sbds_version_number = 0;
> +    p->max_error = 0xff; /* Unknown */
> +    p->sbds_serial_number = 0;
> +    p->sbds_manufacturer_date = 0;
> +    p->sbds_device_chemistry = 0;
> +    p->design_capacity_multiplier = 0;
> +    p->oem_specific = 0;
> +
> +    start += sizeof(struct smbios_type_22);
> +
> +    strcpy((char *)start, "Primary");
> +    start += strlen("Primary") + 1;
> +    strcpy((char *)start, "Xen");
> +    start += strlen("Xen") + 1;
> +    strcpy((char *)start, smbios_release_date);
> +    start += strlen(smbios_release_date) + 1;
> +    strcpy((char *)start, "XEN-VBAT");
> +    start += strlen("XEN-VBAT") + 1;
> +
> +    *((uint8_t *)start) = 0;
> +    return start+1; 
> +}
> +
>  /* Type 32 -- System Boot Information */
>  static void *
>  smbios_type_32_init(void *start)
> @@ -628,6 +856,71 @@ smbios_type_32_init(void *start)
>      return start+2;
>  }
>  
> +/* Type 39 -- Power Supply */
> +static void *
> +smbios_type_39_init(void *start)
> +{
> +    struct smbios_type_39 *p = (struct smbios_type_39 *)start;
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( (get_smbios_control_flags() &
> HVM_SMBIOS_INCLUDE_POWER_SUPPLY)
> +          == 0 )
> +        return start;
> +
> +    /* No default values - only present if the table is passed in */
> +    ptable = get_smbios_passthrough_table(39, &length);
> +    if ( (ptable == NULL)||(length == 0) )
> +        return start;
> +
> +    memcpy(start, ptable, length);
> +
> +    /* Fix up, use consistent handles */
> +    p->header.handle = 0x2700;
> +
> +    /* These devices are not present */
> +    p->input_voltage_probe_handle = 0xFFFF;
> +    p->cooling_device_handle = 0xFFFF;
> +    p->input_current_probe_handle = 0xFFFF;

I think responsibility for setting these up correctly ought to lie with
whoever passed the table in.

> +
> +    return (start + length);
> +}
> +
> +static void *
> +smbios_type_vendor_oem_init(void *start)
> +{
> +    struct hvm_modules_iterator iter;
> +    uint32_t flags = get_smbios_control_flags();
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( ((flags & HVM_SMBIOS_INCLUDE_VENDOR_OEM) == 0)||
> +         (flags & HVM_SMBIOS_DISABLE_PASSTHROUGH) )
> +        return start;
> +
> +    /* Looking for any and all vendor/OEM defined tables passed in.
> */
> +    init_smbios_module_iterator(&iter, 128, 255);
> +
> +    do
> +    {
> +        ptable = hvm_find_module_entry(&iter, &length);
> +        if ( (ptable != NULL)&&(length > 0) )
> +        {
> +            /*
> +             * Vendor/OEM table, copy it in. Note the handle values
> cannot
> +             * be changed since it is unknown what is in each of
> these tables
> +             * but they could contain handle references to other
> tables. This
> +             * means a slight risk of collision with the tables above
> but that
> +             * would have to be dealt with on a case by case basis.
> +             */
> +            memcpy(start, ptable, length);
> +            start += length;

Do you also need to track the size of the largest table as well as the
total number, for the purposes of filling in the fields in the entry
point?

> +        }
> +    } while ( ptable != NULL );
> +
> +    return start;
> +}
> +
>  /* Type 127 -- End of Table */
>  static void *
>  smbios_type_127_init(void *start)
> diff -r a0d871dadf1d tools/firmware/hvmloader/smbios_types.h
> --- a/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:45:12
> 2012 -0400
> +++ b/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:52:13
> 2012 -0400
> @@ -84,6 +84,15 @@ struct smbios_type_1 {
>      uint8_t family_str;
>  } __attribute__ ((packed));
>  
> +/* SMBIOS type 2 - Base Board Information */
> +struct smbios_type_2 {
> +    struct smbios_structure_header header;
> +    uint8_t manufacturer_str;
> +    uint8_t product_name_str;
> +    uint8_t version_str;
> +    uint8_t serial_number_str;
> +} __attribute__ ((packed));
> +
>  /* SMBIOS type 3 - System Enclosure */
>  struct smbios_type_3 {
>      struct smbios_structure_header header;
> @@ -173,6 +182,26 @@ struct smbios_type_20 {
>      uint8_t interleaved_data_depth;
>  } __attribute__ ((packed));
>  
> +/* SMBIOS type 22 - Portable battery */
> +struct smbios_type_22 {
> +    struct smbios_structure_header header;
> +    uint8_t location_str;
> +    uint8_t manufacturer_str;
> +    uint8_t manufacturer_date_str;
> +    uint8_t serial_number_str;
> +    uint8_t device_name_str;
> +    uint8_t device_chemistry;
> +    uint16_t device_capacity;
> +    uint16_t device_voltage;
> +    uint8_t sbds_version_number;
> +    uint8_t max_error;
> +    uint16_t sbds_serial_number;
> +    uint16_t sbds_manufacturer_date;
> +    uint8_t sbds_device_chemistry;
> +    uint8_t design_capacity_multiplier;
> +    uint32_t oem_specific;
> +} __attribute__ ((packed));
> +
>  /* SMBIOS type 32 - System Boot Information */
>  struct smbios_type_32 {
>      struct smbios_structure_header header;
> @@ -180,6 +209,24 @@ struct smbios_type_32 {
>      uint8_t boot_status;
>  } __attribute__ ((packed));
>  
> +/* SMBIOS type 39 - Power Supply */
> +struct smbios_type_39 {
> +    struct smbios_structure_header header;
> +    uint8_t power_unit_group;
> +    uint8_t location_str;
> +    uint8_t device_name_str;
> +    uint8_t manufacturer_str;
> +    uint8_t serial_number_str;
> +    uint8_t asset_tag_number_str;
> +    uint8_t model_part_number_str;
> +    uint8_t revision_level_str;
> +    uint16_t max_capacity;
> +    uint16_t characteristics;
> +    uint16_t input_voltage_probe_handle;
> +    uint16_t cooling_device_handle;
> +    uint16_t input_current_probe_handle;
> +} __attribute__ ((packed));
> +
>  /* SMBIOS type 127 -- End-of-table */
>  struct smbios_type_127 {
>      struct smbios_structure_header header;
> 
> 
> 
> 
> 
> 
> 
> plain text
> document
> attachment
> (ATT00001.txt)
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:38:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk4b-0006aA-2u; Thu, 05 Apr 2012 10:37:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFk4a-0006Zy-2f
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:37:48 +0000
Received: from [85.158.138.51:40324] by server-3.bemta-3.messagelabs.com id
	0F/68-10665-BF57D7F4; Thu, 05 Apr 2012 10:37:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333622266!16728009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18724 invoked from network); 5 Apr 2012 10:37:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:37:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11790704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:37:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	11:37:42 +0100
Message-ID: <1333622260.937.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Thu, 5 Apr 2012 11:37:40 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
 support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
>                              From: 
> Ross Philipson
> <Ross.Philipson@citrix.com>
>                                To: 
> xen-devel@lists.xensource.com
> <xen-devel@lists.xensource.com>
>                           Subject: 
> [Xen-devel] [PATCH 04/07] HVM
> firmware passthrough: SMBIOS
> support
>                              Date: 
> Mon, 19 Mar 2012 22:04:09 +0000
>                        Message-id: 
> <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
> 
> 
> Pass through support for the SMBIOS tables including a few new
> DMTF defines types and support of OEM defined tables. Passed in
> SMBIOS types override the default internal values. Flags control
> the new tables so that with default values the SMBIOS tables look
> exactly as they do before the patches.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> 
> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (hvm-firmware-passthrough-04.patch)
> 
> # HG changeset patch
> # Parent a0d871dadf1d482d77bf57a059a55098e2bfb078
> Pass through support for the SMBIOS tables including a few new
> DMTF defines types and support of OEM defined tables. Passed in
> SMBIOS types override the default internal values. Flags control
> the new tables so that with default values the SMBIOS tables look
> exactly as they do before the patches.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> diff -r a0d871dadf1d tools/firmware/hvmloader/smbios.c
> --- a/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:45:12 2012 -0400
> +++ b/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:52:13 2012 -0400
> @@ -23,8 +23,10 @@
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/version.h>
> +#include <xen/hvm/hvm_defs.h>
>  #include "smbios_types.h"
>  #include "util.h"
> +#include "modules.h"
>  #include "hypercall.h"
>  
>  static int
> @@ -49,6 +51,8 @@ static void *
>  smbios_type_1_init(void *start, const char *xen_version, 
>                     uint8_t uuid[16]);
>  static void *
> +smbios_type_2_init(void *start);
> +static void *
>  smbios_type_3_init(void *start);
>  static void *
>  smbios_type_4_init(void *start, unsigned int cpu_number,
> @@ -64,8 +68,14 @@ smbios_type_19_init(void *start, uint32_
>  static void *
>  smbios_type_20_init(void *start, uint32_t memory_size_mb, int
> instance);
>  static void *
> +smbios_type_22_init(void *start);
> +static void *
>  smbios_type_32_init(void *start);
>  static void *
> +smbios_type_39_init(void *start);
> +static void *
> +smbios_type_vendor_oem_init(void *start);
> +static void *
>  smbios_type_127_init(void *start);
>  
>  static void
> @@ -85,6 +95,35 @@ get_cpu_manufacturer(char *buf, int len)
>          strncpy(buf, "unknown", len);
>  }
>  
> +static uint32_t
> +get_smbios_control_flags(void)
> +{
> +    static uint64_t flags;
> +    static int read = 0;
> +
> +    if ( !read )
> +    {
> +        flags = strtoll(xenstore_read(HVM_XS_SMBIOS_FLAGS, "0"),
> NULL, 0);

Rather than encoding these as a bit field, written as ascii into
xenstore and then parsed back into a number again I think you may as
well just have a node for each individual flag.

> +        read = 1;
> +    }
> +
> +    return (uint32_t)flags;
> +}
> +
> +static void*
> +get_smbios_passthrough_table(uint8_t type, uint32_t *length_out)
> +{
> +    struct hvm_modules_iterator iter;
> +    uint32_t flags = get_smbios_control_flags();
> +
> +    if ( flags & HVM_SMBIOS_DISABLE_PASSTHROUGH )

This check is the same as just not providing the tables?

> +        return NULL;
> +
> +    init_smbios_module_iterator(&iter, type, 0);
> +
> +    return hvm_find_module_entry(&iter, length_out);
> +}
> +
>  static int
>  write_smbios_tables(void *ep, void *start,
>                      uint32_t vcpus, uint64_t memsize,
> [...]
> @@ -338,6 +393,18 @@ smbios_type_1_init(void *start, const ch
>      char uuid_str[37];
>      struct smbios_type_1 *p = (struct smbios_type_1 *)start;
>      const char *s;
> +    void *ptable;
> +    uint32_t length;
> +
> +    ptable = get_smbios_passthrough_table(1, &length);
> +    if ( (ptable != NULL)&&(length > 0) )
> +    {
> +        memcpy(start, ptable, length);
> +
> +        /* Fix up, use consistent handles */
> +        p->header.handle = 0x100;
> +        return (start + length);
> +    }

This seems like a pretty common pattern, could it be pulled up into the
caller of all these init functions?

I know it's a pre-existing problem but perhaps giving the handle numbers
#defined names would make things a bit more obvious. For the OEM tables
and the potential for clashes (which you commented on in that function)
at least then there would be a sort of index of the ones which are
used. 

I suppose you could also then push responsibility for maintaining this
consistency up to whoever was providing the table and if they wanted
they could use there own numbering and ensure consistency across the
board themselves.

>      memset(p, 0, sizeof(*p));
>  
> @@ -380,12 +447,90 @@ smbios_type_1_init(void *start, const ch
>      return start+1; 
>  }
>  
> +/* Type 2 -- System Board */
> +static void *
> +smbios_type_2_init(void *start)
> +{
> +    struct smbios_type_2 *p = (struct smbios_type_2 *)start;
> +    uint8_t *bptr;
> +    const char *s;
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( (get_smbios_control_flags() &
> HVM_SMBIOS_INCLUDE_SYSTEM_BOARD) == 0 )

Is there any reason you wouldn't want this table now that you've added
it?

> +        return start;
> +
> +    ptable = get_smbios_passthrough_table(2, &length);
> +    if ( (ptable != NULL)&&(length > 0) )
> +    {
> +        memcpy(start, ptable, length);
> +
> +        /* Fix up, use consistent handles, set chassis handle */
> +        p->header.handle = 0x200;
> +
> +        if ( p->header.length >= 13 )
> +        {
> +            bptr = ((uint8_t*)start) + 11;
> +            if ( *((uint16_t*)bptr) != 0 )
> +                *((uint16_t*)bptr) = 0x300; /* current chassis handle

This is to match the handle of the type 3 table?

I don't see a corresponding thing in the constructed version of this
table below, is that normal?

>  */
> +        }
> +
> +        return (start + length);
> +    }
> +
> +    memset(p, 0, sizeof(*p));
> +
> +    p->header.type = 2;
> +    p->header.length = sizeof(struct smbios_type_2);
> +    p->header.handle = 0x200;
> +
> +    p->manufacturer_str = 1;
> +    p->product_name_str = 2;
> +    p->version_str = 0;
> +    p->serial_number_str = 0;
> +
> +    start += sizeof(struct smbios_type_2);
> +
> +    s = xenstore_read("bios-strings/board-manufacturer", "Xen");
> +    strcpy((char *)start, s);
> +    start += strlen(s) + 1;
> +
> +    s = xenstore_read("bios-strings/board-product-name", "HVM domU");
> +    strcpy((char *)start, s);
> +    start += strlen(s) + 1;
> +
> +    /* no internal defaults for this if the value is not set */
> +    s = xenstore_read("bios-strings/board-serial-number", NULL);
> +    if ( (s != NULL)&&(*s != '\0') )
> +    {
> +        strcpy((char *)start, s);
> +        start += strlen(s) + 1;        
> +        p->serial_number_str = 3;
> +    }
> +
> +    *((uint8_t *)start) = 0;
> +    return start+1;
> +}

[...]
> @@ -403,9 +548,20 @@ smbios_type_3_init(void *start)
>      p->security_status = 0x02; /* unknown */
>  
>      start += sizeof(struct smbios_type_3);
> -    
> -    strcpy((char *)start, "Xen");
> -    start += strlen("Xen") + 1;
> +
> +    s = xenstore_read("bios-strings/enclosure-manufacturer", "Xen");
> +    strcpy((char *)start, s);
> +    start += strlen(s) + 1;
> +
> +    /* no internal defaults for this if the value is not set */
> +    s = xenstore_read("bios-strings/enclosure-serial-number", NULL);
> +    if ( (s != NULL)&&(*s != '\0') )
> +    {
> +        strcpy((char *)start, s);
> +        start += strlen(s) + 1;
> +        p->serial_number_str = 2;
> +    }
> +
>      *((uint8_t *)start) = 0;
>      return start+1;
>  }
[...]
> @@ -609,6 +777,66 @@ smbios_type_20_init(void *start, uint32_
>      return start+2;
>  }
>  
> +/* Type 22 -- Portable Battery */
> +static void *
> +smbios_type_22_init(void *start)
> +{
> +    struct smbios_type_22 *p = (struct smbios_type_22 *)start;
> +    static const char *smbios_release_date = __SMBIOS_DATE__;
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( (get_smbios_control_flags() &
> HVM_SMBIOS_INCLUDE_PORTABLE_BATTERY)
> +          == 0 )
> +        return start;

Could an argument be made here that either you want to pass through some
underlying table or you don't want the table at all? Or is there a use
case for having hvmloader fake one up?

> +
> +    ptable = get_smbios_passthrough_table(22, &length);
> +    if ( (ptable != NULL)&&(length > 0) )
> +    {
> +        memcpy(start, ptable, length);
> +
> +        /* Fix up, use consistent handles */
> +        p->header.handle = 0x1600;
> +        return (start + length);
> +    }
> +
> +    memset(p, 0, sizeof(*p));
> +
> +    p->header.type = 22;
> +    p->header.length = sizeof(struct smbios_type_22);
> +    p->header.handle = 0x1600;
> +
> +    p->location_str = 1;
> +    p->manufacturer_str = 2;
> +    p->manufacturer_date_str = 3;
> +    p->serial_number_str = 0;
> +    p->device_name_str = 4;
> +    p->device_chemistry = 0x2; /* Unknown */
> +    p->device_capacity = 0; /* Unknown */
> +    p->device_voltage = 0; /* Unknown */
> +    p->sbds_version_number = 0;
> +    p->max_error = 0xff; /* Unknown */
> +    p->sbds_serial_number = 0;
> +    p->sbds_manufacturer_date = 0;
> +    p->sbds_device_chemistry = 0;
> +    p->design_capacity_multiplier = 0;
> +    p->oem_specific = 0;
> +
> +    start += sizeof(struct smbios_type_22);
> +
> +    strcpy((char *)start, "Primary");
> +    start += strlen("Primary") + 1;
> +    strcpy((char *)start, "Xen");
> +    start += strlen("Xen") + 1;
> +    strcpy((char *)start, smbios_release_date);
> +    start += strlen(smbios_release_date) + 1;
> +    strcpy((char *)start, "XEN-VBAT");
> +    start += strlen("XEN-VBAT") + 1;
> +
> +    *((uint8_t *)start) = 0;
> +    return start+1; 
> +}
> +
>  /* Type 32 -- System Boot Information */
>  static void *
>  smbios_type_32_init(void *start)
> @@ -628,6 +856,71 @@ smbios_type_32_init(void *start)
>      return start+2;
>  }
>  
> +/* Type 39 -- Power Supply */
> +static void *
> +smbios_type_39_init(void *start)
> +{
> +    struct smbios_type_39 *p = (struct smbios_type_39 *)start;
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( (get_smbios_control_flags() &
> HVM_SMBIOS_INCLUDE_POWER_SUPPLY)
> +          == 0 )
> +        return start;
> +
> +    /* No default values - only present if the table is passed in */
> +    ptable = get_smbios_passthrough_table(39, &length);
> +    if ( (ptable == NULL)||(length == 0) )
> +        return start;
> +
> +    memcpy(start, ptable, length);
> +
> +    /* Fix up, use consistent handles */
> +    p->header.handle = 0x2700;
> +
> +    /* These devices are not present */
> +    p->input_voltage_probe_handle = 0xFFFF;
> +    p->cooling_device_handle = 0xFFFF;
> +    p->input_current_probe_handle = 0xFFFF;

I think responsibility for setting these up correctly ought to lie with
whoever passed the table in.

> +
> +    return (start + length);
> +}
> +
> +static void *
> +smbios_type_vendor_oem_init(void *start)
> +{
> +    struct hvm_modules_iterator iter;
> +    uint32_t flags = get_smbios_control_flags();
> +    void *ptable;
> +    uint32_t length;
> +
> +    if ( ((flags & HVM_SMBIOS_INCLUDE_VENDOR_OEM) == 0)||
> +         (flags & HVM_SMBIOS_DISABLE_PASSTHROUGH) )
> +        return start;
> +
> +    /* Looking for any and all vendor/OEM defined tables passed in.
> */
> +    init_smbios_module_iterator(&iter, 128, 255);
> +
> +    do
> +    {
> +        ptable = hvm_find_module_entry(&iter, &length);
> +        if ( (ptable != NULL)&&(length > 0) )
> +        {
> +            /*
> +             * Vendor/OEM table, copy it in. Note the handle values
> cannot
> +             * be changed since it is unknown what is in each of
> these tables
> +             * but they could contain handle references to other
> tables. This
> +             * means a slight risk of collision with the tables above
> but that
> +             * would have to be dealt with on a case by case basis.
> +             */
> +            memcpy(start, ptable, length);
> +            start += length;

Do you also need to track the size of the largest table as well as the
total number, for the purposes of filling in the fields in the entry
point?

> +        }
> +    } while ( ptable != NULL );
> +
> +    return start;
> +}
> +
>  /* Type 127 -- End of Table */
>  static void *
>  smbios_type_127_init(void *start)
> diff -r a0d871dadf1d tools/firmware/hvmloader/smbios_types.h
> --- a/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:45:12
> 2012 -0400
> +++ b/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:52:13
> 2012 -0400
> @@ -84,6 +84,15 @@ struct smbios_type_1 {
>      uint8_t family_str;
>  } __attribute__ ((packed));
>  
> +/* SMBIOS type 2 - Base Board Information */
> +struct smbios_type_2 {
> +    struct smbios_structure_header header;
> +    uint8_t manufacturer_str;
> +    uint8_t product_name_str;
> +    uint8_t version_str;
> +    uint8_t serial_number_str;
> +} __attribute__ ((packed));
> +
>  /* SMBIOS type 3 - System Enclosure */
>  struct smbios_type_3 {
>      struct smbios_structure_header header;
> @@ -173,6 +182,26 @@ struct smbios_type_20 {
>      uint8_t interleaved_data_depth;
>  } __attribute__ ((packed));
>  
> +/* SMBIOS type 22 - Portable battery */
> +struct smbios_type_22 {
> +    struct smbios_structure_header header;
> +    uint8_t location_str;
> +    uint8_t manufacturer_str;
> +    uint8_t manufacturer_date_str;
> +    uint8_t serial_number_str;
> +    uint8_t device_name_str;
> +    uint8_t device_chemistry;
> +    uint16_t device_capacity;
> +    uint16_t device_voltage;
> +    uint8_t sbds_version_number;
> +    uint8_t max_error;
> +    uint16_t sbds_serial_number;
> +    uint16_t sbds_manufacturer_date;
> +    uint8_t sbds_device_chemistry;
> +    uint8_t design_capacity_multiplier;
> +    uint32_t oem_specific;
> +} __attribute__ ((packed));
> +
>  /* SMBIOS type 32 - System Boot Information */
>  struct smbios_type_32 {
>      struct smbios_structure_header header;
> @@ -180,6 +209,24 @@ struct smbios_type_32 {
>      uint8_t boot_status;
>  } __attribute__ ((packed));
>  
> +/* SMBIOS type 39 - Power Supply */
> +struct smbios_type_39 {
> +    struct smbios_structure_header header;
> +    uint8_t power_unit_group;
> +    uint8_t location_str;
> +    uint8_t device_name_str;
> +    uint8_t manufacturer_str;
> +    uint8_t serial_number_str;
> +    uint8_t asset_tag_number_str;
> +    uint8_t model_part_number_str;
> +    uint8_t revision_level_str;
> +    uint16_t max_capacity;
> +    uint16_t characteristics;
> +    uint16_t input_voltage_probe_handle;
> +    uint16_t cooling_device_handle;
> +    uint16_t input_current_probe_handle;
> +} __attribute__ ((packed));
> +
>  /* SMBIOS type 127 -- End-of-table */
>  struct smbios_type_127 {
>      struct smbios_structure_header header;
> 
> 
> 
> 
> 
> 
> 
> plain text
> document
> attachment
> (ATT00001.txt)
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk7J-0006qQ-RR; Thu, 05 Apr 2012 10:40:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFk7I-0006qH-63
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:40:36 +0000
Received: from [85.158.143.99:29037] by server-1.bemta-4.messagelabs.com id
	C9/AE-20925-3A67D7F4; Thu, 05 Apr 2012 10:40:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333622432!17226851!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5697 invoked from network); 5 Apr 2012 10:40:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11790759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	11:40:32 +0100
Message-ID: <1333622430.937.79.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 5 Apr 2012 11:40:30 +0100
In-Reply-To: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
References: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-05 at 11:25 +0100, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333621466 -3600
> # Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
> # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> tools/blktap2: fix 'make clean'
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Somebody reported a build error which looked very much like a symptom of
something not getting cleaned up like this a couple of days ago --
unfortunately I can't remember who or where or I'd cc them.

Anyway: 

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r d690c7e896a2 -r 4b6bf18b6790 tools/blktap2/lvm/Makefile
> --- a/tools/blktap2/lvm/Makefile	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/blktap2/lvm/Makefile	Thu Apr 05 11:24:26 2012 +0100
> @@ -27,7 +27,7 @@ lvm-util: lvm-util.o
>  	$(CC) -DLVM_UTIL $(LDFLAGS) -o lvm-util lvm-util.c
>  
>  clean:
> -	rm -rf *.o *~ $(DEPS) $(IBIN)
> +	rm -rf *.o *.opic *~ $(DEPS) $(IBIN)
>  
>  .PHONY: all build clean install lvm-util
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk7J-0006qQ-RR; Thu, 05 Apr 2012 10:40:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SFk7I-0006qH-63
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 10:40:36 +0000
Received: from [85.158.143.99:29037] by server-1.bemta-4.messagelabs.com id
	C9/AE-20925-3A67D7F4; Thu, 05 Apr 2012 10:40:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333622432!17226851!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5697 invoked from network); 5 Apr 2012 10:40:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11790759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	11:40:32 +0100
Message-ID: <1333622430.937.79.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 5 Apr 2012 11:40:30 +0100
In-Reply-To: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
References: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-05 at 11:25 +0100, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333621466 -3600
> # Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
> # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> tools/blktap2: fix 'make clean'
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Somebody reported a build error which looked very much like a symptom of
something not getting cleaned up like this a couple of days ago --
unfortunately I can't remember who or where or I'd cc them.

Anyway: 

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r d690c7e896a2 -r 4b6bf18b6790 tools/blktap2/lvm/Makefile
> --- a/tools/blktap2/lvm/Makefile	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/blktap2/lvm/Makefile	Thu Apr 05 11:24:26 2012 +0100
> @@ -27,7 +27,7 @@ lvm-util: lvm-util.o
>  	$(CC) -DLVM_UTIL $(LDFLAGS) -o lvm-util lvm-util.c
>  
>  clean:
> -	rm -rf *.o *~ $(DEPS) $(IBIN)
> +	rm -rf *.o *.opic *~ $(DEPS) $(IBIN)
>  
>  .PHONY: all build clean install lvm-util
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk7o-0006tA-89; Thu, 05 Apr 2012 10:41:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFk7m-0006sv-4X
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:41:06 +0000
Received: from [193.109.254.147:35229] by server-2.bemta-14.messagelabs.com id
	32/2C-19409-1C67D7F4; Thu, 05 Apr 2012 10:41:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333622463!894981!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21508 invoked from network); 5 Apr 2012 10:41:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11790772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:41:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 11:41:03 +0100
Date: Thu, 5 Apr 2012 11:43:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F7D706D.5030507@redhat.com>
Message-ID: <alpine.DEB.2.00.1204051142560.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<4F7D706D.5030507@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Paolo Bonzini wrote:
> Il 05/04/2012 11:32, Wei Liu ha scritto:
> > Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
> > Xen HVM guests.
> 
> Only skimmed the patch but yeah, this is what I had in mind.  Thanks!

It looks good to me too.
Paolo, can I add your acked-by?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk7o-0006tA-89; Thu, 05 Apr 2012 10:41:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFk7m-0006sv-4X
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:41:06 +0000
Received: from [193.109.254.147:35229] by server-2.bemta-14.messagelabs.com id
	32/2C-19409-1C67D7F4; Thu, 05 Apr 2012 10:41:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333622463!894981!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21508 invoked from network); 5 Apr 2012 10:41:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 10:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11790772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:41:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 11:41:03 +0100
Date: Thu, 5 Apr 2012 11:43:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F7D706D.5030507@redhat.com>
Message-ID: <alpine.DEB.2.00.1204051142560.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<4F7D706D.5030507@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Paolo Bonzini wrote:
> Il 05/04/2012 11:32, Wei Liu ha scritto:
> > Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
> > Xen HVM guests.
> 
> Only skimmed the patch but yeah, this is what I had in mind.  Thanks!

It looks good to me too.
Paolo, can I add your acked-by?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:41:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk8U-0006z9-La; Thu, 05 Apr 2012 10:41:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SFk8T-0006yq-CU
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:41:49 +0000
Received: from [85.158.143.35:34467] by server-1.bemta-4.messagelabs.com id
	A2/80-20925-CE67D7F4; Thu, 05 Apr 2012 10:41:48 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333622506!11171796!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxNTY4NzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4240 invoked from network); 5 Apr 2012 10:41:48 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 10:41:48 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 5 Apr 2012 16:11:44 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 5 Apr 2012 16:11:37 +0530
Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q35AfaZD4386990
	for <xen-devel@lists.xensource.com>; Thu, 5 Apr 2012 16:11:36 +0530
Received: from d28av03.in.ibm.com (loopback [127.0.0.1])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q35GAn20023442
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 02:10:50 +1000
Received: from [9.124.158.108] (codeblue.in.ibm.com [9.124.158.108])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q35GAmmx023420; Fri, 6 Apr 2012 02:10:48 +1000
Message-ID: <4F7D76B4.1090600@linux.vnet.ibm.com>
Date: Thu, 05 Apr 2012 16:10:52 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
	<4F7976B6.5050000@linux.vnet.ibm.com> <4F7D5F5B.2020209@redhat.com>
In-Reply-To: <4F7D5F5B.2020209@redhat.com>
x-cbid: 12040510-2674-0000-0000-000003F34739
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/2012 02:31 PM, Avi Kivity wrote:
> On 04/02/2012 12:51 PM, Raghavendra K T wrote:
>> On 04/01/2012 07:23 PM, Avi Kivity wrote:
>>> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>>>>> I have patch something like below in mind to try:
>>>>>>
>>>>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>>>>> index d3b98b1..5127668 100644
>>>>>> --- a/virt/kvm/kvm_main.c
>>>>>> +++ b/virt/kvm/kvm_main.c
>>>>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>>>>          * else and called schedule in __vcpu_run.  Hopefully that
>>>>>>          * VCPU is holding the lock that we need and will release it.
>>>>>>          * We approximate round-robin by starting at the last boosted
>>>>>> VCPU.
>>>>>> +     * Priority is given to vcpu that are unhalted.
>>>>>>          */
>>>>>> -    for (pass = 0; pass<    2&&    !yielded; pass++) {
>>>>>> +    for (pass = 0; pass<    3&&    !yielded; pass++) {
>>>>>>             kvm_for_each_vcpu(i, vcpu, kvm) {
>>>>>>                 struct task_struct *task = NULL;
>>>>>>                 struct pid *pid;
>>>>>> -            if (!pass&&    i<    last_boosted_vcpu) {
>>>>>> +            if (!pass&&    !vcpu->pv_unhalted)
>>>>>> +                continue;
>>>>>> +            else if (pass == 1&&    i<    last_boosted_vcpu) {
>>>>>>                     i = last_boosted_vcpu;
>>>>>>                     continue;
>>>>>> -            } else if (pass&&    i>    last_boosted_vcpu)
>>>>>> +            } else if (pass == 2&&    i>    last_boosted_vcpu)
>>>>>>                     break;
>>>>>>                 if (vcpu == me)
>>>>>>                     continue;
>>>>>>
>>>>>
>>>>> Actually I think this is unneeded.  The loops tries to find vcpus
>> that
>>>>> are runnable but not running (vcpu_active(vcpu->wq)), and halted
>> vcpus
>>>>> don't match this condition.
>>>>>
>>
>> Oh! I think I misinterpreted your statement. hmm I got it. you told to
>> remove if (vcpu == me) condition.
>
> No, the entire patch is unneeded.  My original comment was:
>
>> from the PLE handler, don't wake up a vcpu that is sleeping because it
> is waiting for a kick
>
> But the PLE handler never wakes up sleeping vcpus anyway.

I agree with you. It is already doing that. But my approach here is
little different.

In 2 classes of vcpus we have (one is subset of another when we try to
do yield_to) viz,

1) runnable and kicked < (subset of) 2) just runnable

what we are trying to do here is targeting 1) first so that we get good
lock progress.

Here was the sequence I was talking.

vcpu1 releases lock->finds that vcpu2  is next candidate ->
kick hypercall -> kvm_pv_kick_cpu_op -> set kicked flag ->
vcpu->kick(vcpu2)

at this point we have vcpu2 waiting for getting scheduled. But
above yield call can wake *anybody*.

I agree this is not serious (rather it is overhead) when there are are 
less number of vcpus, But when we have more number of vcpu/vm.. it may
not scale well. My attempt was to fix that.

Let me know if I am completely missing something..

>
> There's still a conflict with PLE in that it may trigger during the spin
> phase and send a random yield_to() somewhere.  Maybe it's sufficient to
> tune the PLE timeout to be longer than the spinlock timeout.
>

Ok ... But we also should be cautious that, we may do more halt, though 
we are about to get spinlock.
Need more study on this.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:41:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFk8U-0006z9-La; Thu, 05 Apr 2012 10:41:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SFk8T-0006yq-CU
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:41:49 +0000
Received: from [85.158.143.35:34467] by server-1.bemta-4.messagelabs.com id
	A2/80-20925-CE67D7F4; Thu, 05 Apr 2012 10:41:48 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333622506!11171796!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxNTY4NzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4240 invoked from network); 5 Apr 2012 10:41:48 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 10:41:48 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 5 Apr 2012 16:11:44 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 5 Apr 2012 16:11:37 +0530
Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q35AfaZD4386990
	for <xen-devel@lists.xensource.com>; Thu, 5 Apr 2012 16:11:36 +0530
Received: from d28av03.in.ibm.com (loopback [127.0.0.1])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q35GAn20023442
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 02:10:50 +1000
Received: from [9.124.158.108] (codeblue.in.ibm.com [9.124.158.108])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q35GAmmx023420; Fri, 6 Apr 2012 02:10:48 +1000
Message-ID: <4F7D76B4.1090600@linux.vnet.ibm.com>
Date: Thu, 05 Apr 2012 16:10:52 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F707C5F.1000905@redhat.com>	<4F716E31.3000803@linux.vnet.ibm.com>
	<CAMy5W3foop40+R1RLv_JPhnO5ZmV90uMmNERYY-e3QCeaJfqLw@mail.gmail.com>
	<4F73568D.7000703@linux.vnet.ibm.com> <4F743247.5080407@redhat.com>
	<4F74A405.2040609@linux.vnet.ibm.com>
	<4F7585EE.7060203@linux.vnet.ibm.com> <4F7855A1.80107@redhat.com>
	<4F785CC9.7070204@linux.vnet.ibm.com> <4F785DCF.7020809@redhat.com>
	<4F7976B6.5050000@linux.vnet.ibm.com> <4F7D5F5B.2020209@redhat.com>
In-Reply-To: <4F7D5F5B.2020209@redhat.com>
x-cbid: 12040510-2674-0000-0000-000003F34739
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Alan Meadows <alan.meadows@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/2012 02:31 PM, Avi Kivity wrote:
> On 04/02/2012 12:51 PM, Raghavendra K T wrote:
>> On 04/01/2012 07:23 PM, Avi Kivity wrote:
>>> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>>>>> I have patch something like below in mind to try:
>>>>>>
>>>>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>>>>> index d3b98b1..5127668 100644
>>>>>> --- a/virt/kvm/kvm_main.c
>>>>>> +++ b/virt/kvm/kvm_main.c
>>>>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>>>>          * else and called schedule in __vcpu_run.  Hopefully that
>>>>>>          * VCPU is holding the lock that we need and will release it.
>>>>>>          * We approximate round-robin by starting at the last boosted
>>>>>> VCPU.
>>>>>> +     * Priority is given to vcpu that are unhalted.
>>>>>>          */
>>>>>> -    for (pass = 0; pass<    2&&    !yielded; pass++) {
>>>>>> +    for (pass = 0; pass<    3&&    !yielded; pass++) {
>>>>>>             kvm_for_each_vcpu(i, vcpu, kvm) {
>>>>>>                 struct task_struct *task = NULL;
>>>>>>                 struct pid *pid;
>>>>>> -            if (!pass&&    i<    last_boosted_vcpu) {
>>>>>> +            if (!pass&&    !vcpu->pv_unhalted)
>>>>>> +                continue;
>>>>>> +            else if (pass == 1&&    i<    last_boosted_vcpu) {
>>>>>>                     i = last_boosted_vcpu;
>>>>>>                     continue;
>>>>>> -            } else if (pass&&    i>    last_boosted_vcpu)
>>>>>> +            } else if (pass == 2&&    i>    last_boosted_vcpu)
>>>>>>                     break;
>>>>>>                 if (vcpu == me)
>>>>>>                     continue;
>>>>>>
>>>>>
>>>>> Actually I think this is unneeded.  The loops tries to find vcpus
>> that
>>>>> are runnable but not running (vcpu_active(vcpu->wq)), and halted
>> vcpus
>>>>> don't match this condition.
>>>>>
>>
>> Oh! I think I misinterpreted your statement. hmm I got it. you told to
>> remove if (vcpu == me) condition.
>
> No, the entire patch is unneeded.  My original comment was:
>
>> from the PLE handler, don't wake up a vcpu that is sleeping because it
> is waiting for a kick
>
> But the PLE handler never wakes up sleeping vcpus anyway.

I agree with you. It is already doing that. But my approach here is
little different.

In 2 classes of vcpus we have (one is subset of another when we try to
do yield_to) viz,

1) runnable and kicked < (subset of) 2) just runnable

what we are trying to do here is targeting 1) first so that we get good
lock progress.

Here was the sequence I was talking.

vcpu1 releases lock->finds that vcpu2  is next candidate ->
kick hypercall -> kvm_pv_kick_cpu_op -> set kicked flag ->
vcpu->kick(vcpu2)

at this point we have vcpu2 waiting for getting scheduled. But
above yield call can wake *anybody*.

I agree this is not serious (rather it is overhead) when there are are 
less number of vcpus, But when we have more number of vcpu/vm.. it may
not scale well. My attempt was to fix that.

Let me know if I am completely missing something..

>
> There's still a conflict with PLE in that it may trigger during the spin
> phase and send a random yield_to() somewhere.  Maybe it's sufficient to
> tune the PLE timeout to be longer than the spinlock timeout.
>

Ok ... But we also should be cautious that, we may do more halt, though 
we are about to get spinlock.
Need more study on this.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:51:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFkHU-0007NB-OM; Thu, 05 Apr 2012 10:51:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1SFkHT-0007N6-9h
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:51:07 +0000
Received: from [85.158.143.99:35255] by server-3.bemta-4.messagelabs.com id
	E8/FC-05853-A197D7F4; Thu, 05 Apr 2012 10:51:06 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333623065!17228234!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyMzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5310 invoked from network); 5 Apr 2012 10:51:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	5 Apr 2012 10:51:05 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q35Ap13N032027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 06:51:01 -0400
Received: from yakj.usersys.redhat.com (ovpn-112-21.ams2.redhat.com
	[10.36.112.21])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q35Aovw2025787; Thu, 5 Apr 2012 06:50:59 -0400
Message-ID: <4F7D7910.9070508@redhat.com>
Date: Thu, 05 Apr 2012 12:50:56 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<4F7D706D.5030507@redhat.com>
	<alpine.DEB.2.00.1204051142560.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051142560.15151@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, "liuw@liuw.name" <liuw@liuw.name>
Subject: Re: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 05/04/2012 12:43, Stefano Stabellini ha scritto:
>>> > > Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
>>> > > Xen HVM guests.
>> > 
>> > Only skimmed the patch but yeah, this is what I had in mind.  Thanks!
> It looks good to me too.
> Paolo, can I add your acked-by?

Acked-by, yes.  Reviewed-by, no. :)

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 10:51:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 10:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFkHU-0007NB-OM; Thu, 05 Apr 2012 10:51:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1SFkHT-0007N6-9h
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 10:51:07 +0000
Received: from [85.158.143.99:35255] by server-3.bemta-4.messagelabs.com id
	E8/FC-05853-A197D7F4; Thu, 05 Apr 2012 10:51:06 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333623065!17228234!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyMzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5310 invoked from network); 5 Apr 2012 10:51:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	5 Apr 2012 10:51:05 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q35Ap13N032027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 06:51:01 -0400
Received: from yakj.usersys.redhat.com (ovpn-112-21.ams2.redhat.com
	[10.36.112.21])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q35Aovw2025787; Thu, 5 Apr 2012 06:50:59 -0400
Message-ID: <4F7D7910.9070508@redhat.com>
Date: Thu, 05 Apr 2012 12:50:56 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<4F7D706D.5030507@redhat.com>
	<alpine.DEB.2.00.1204051142560.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051142560.15151@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, "liuw@liuw.name" <liuw@liuw.name>
Subject: Re: [Xen-devel] [PATCH 0/0] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 05/04/2012 12:43, Stefano Stabellini ha scritto:
>>> > > Implement a simple Xen APIC module and use it to deliver MSI/MSIX for
>>> > > Xen HVM guests.
>> > 
>> > Only skimmed the patch but yeah, this is what I had in mind.  Thanks!
> It looks good to me too.
> Paolo, can I add your acked-by?

Acked-by, yes.  Reviewed-by, no. :)

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:00:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFkQX-0007Z8-QL; Thu, 05 Apr 2012 11:00:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFkQV-0007Z3-T2
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 11:00:28 +0000
Received: from [193.109.254.147:56098] by server-3.bemta-14.messagelabs.com id
	35/95-23274-B4B7D7F4; Thu, 05 Apr 2012 11:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333623621!3370425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13776 invoked from network); 5 Apr 2012 11:00:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11791266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 11:00:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 12:00:15 +0100
Date: Thu, 5 Apr 2012 12:02:45 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4F7C63EE.6000703@canonical.com>
Message-ID: <alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
References: <4F7C63EE.6000703@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 4 Apr 2012, Stefan Bader wrote:
> Hi Stefano,
> 
> quite a while back in time, you and Konrad had a discussion about some HVM setup
> problems via libvirt. One part was graphics and the problem seemed to be that
> when creating a new instance through xend for HVM, the use of vfb was wrong. It
> mostly does work but then also defines a vkbd which takes a long time in the
> xenbus setup to finally fail.
> 
> Because this was not a really fatal problem it did take a long time to actually
> get back to it. But now I had a look and found that libvirt indeed does use the
> vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> create guests). The decision is made based on the xend version number in the HVM
> case. Which would be wrong if I did understand your reply correctly.
> 
> I have been testing a patch to libvirt, which would not use a vfb definition
> whenever HVM is used (regardless of xend version). And it does seem to work (xm
> list -l however has a vfb device definition, but the same happens when creating
> the instance with a xm style config file that definitely has no vfb section in
> it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> to make sure the solution for libvirt is correct for even the current Xen version.
> 
> So in short, is this always correct?
> 
> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>    do not define a vfb device
> else /* PVM and xend version >= 3 */
>    define a vfb device

vkbd and vfb can be considered optimizations for PV on HVM guests.
No PV on HVM guest that I know should be able to use vfb right now, but
Linux should be able to use vkbd since:

commit 5f098ecd4288333d87e2293239fab1c13ec90dae
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Jul 4 19:22:00 2011 -0700

    Input: xen-kbdfront - enable driver for HVM guests
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

XL in xen-unstable enables vkbd for HVM guests so that you can have
keyboard and mouse without usb emulation (that eats significant
resources in dom0).

That said, vkbd is just a (small) optimization, it is far more
important to get rid of the very annoying wait time at bootup.
Rather than messing with libvirt and xend I would fix it from the Linux
side, see the following thread:

http://marc.info/?l=xen-devel&m=133238564132683&w=2

I think that the right thing to do would be removing the additional wait
time for vfb and vkbd devices in the PV on HVM case. We don't want to
completely remove vfb and vkbd support for PV on HVM guests though.

Konrad, do you agree with the last reply I sent? Do you think you can
come up with a patch? Maybe separating non-essential from essential
devices to have two wait loops is not feasible?
In any case, given the current state of affairs, the first patch in the
thread from Konrad is still better than nothing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:00:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFkQX-0007Z8-QL; Thu, 05 Apr 2012 11:00:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFkQV-0007Z3-T2
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 11:00:28 +0000
Received: from [193.109.254.147:56098] by server-3.bemta-14.messagelabs.com id
	35/95-23274-B4B7D7F4; Thu, 05 Apr 2012 11:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333623621!3370425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13776 invoked from network); 5 Apr 2012 11:00:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11791266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 11:00:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 12:00:15 +0100
Date: Thu, 5 Apr 2012 12:02:45 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4F7C63EE.6000703@canonical.com>
Message-ID: <alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
References: <4F7C63EE.6000703@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 4 Apr 2012, Stefan Bader wrote:
> Hi Stefano,
> 
> quite a while back in time, you and Konrad had a discussion about some HVM setup
> problems via libvirt. One part was graphics and the problem seemed to be that
> when creating a new instance through xend for HVM, the use of vfb was wrong. It
> mostly does work but then also defines a vkbd which takes a long time in the
> xenbus setup to finally fail.
> 
> Because this was not a really fatal problem it did take a long time to actually
> get back to it. But now I had a look and found that libvirt indeed does use the
> vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> create guests). The decision is made based on the xend version number in the HVM
> case. Which would be wrong if I did understand your reply correctly.
> 
> I have been testing a patch to libvirt, which would not use a vfb definition
> whenever HVM is used (regardless of xend version). And it does seem to work (xm
> list -l however has a vfb device definition, but the same happens when creating
> the instance with a xm style config file that definitely has no vfb section in
> it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> to make sure the solution for libvirt is correct for even the current Xen version.
> 
> So in short, is this always correct?
> 
> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>    do not define a vfb device
> else /* PVM and xend version >= 3 */
>    define a vfb device

vkbd and vfb can be considered optimizations for PV on HVM guests.
No PV on HVM guest that I know should be able to use vfb right now, but
Linux should be able to use vkbd since:

commit 5f098ecd4288333d87e2293239fab1c13ec90dae
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Jul 4 19:22:00 2011 -0700

    Input: xen-kbdfront - enable driver for HVM guests
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

XL in xen-unstable enables vkbd for HVM guests so that you can have
keyboard and mouse without usb emulation (that eats significant
resources in dom0).

That said, vkbd is just a (small) optimization, it is far more
important to get rid of the very annoying wait time at bootup.
Rather than messing with libvirt and xend I would fix it from the Linux
side, see the following thread:

http://marc.info/?l=xen-devel&m=133238564132683&w=2

I think that the right thing to do would be removing the additional wait
time for vfb and vkbd devices in the PV on HVM case. We don't want to
completely remove vfb and vkbd support for PV on HVM guests though.

Konrad, do you agree with the last reply I sent? Do you think you can
come up with a patch? Maybe separating non-essential from essential
devices to have two wait loops is not feasible?
In any case, given the current state of affairs, the first patch in the
thread from Konrad is still better than nothing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:03:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFkSr-0007ef-BD; Thu, 05 Apr 2012 11:02:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFkSq-0007eZ-I9
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 11:02:52 +0000
Received: from [85.158.139.83:54019] by server-7.bemta-5.messagelabs.com id
	2E/EA-16195-BDB7D7F4; Thu, 05 Apr 2012 11:02:51 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333623770!22612283!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNzY1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 5 Apr 2012 11:02:50 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 11:02:50 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFkSn-0003KS-Fl; Thu, 05 Apr 2012 12:02:49 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Thu, 5 Apr 2012 12:02:49 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Thu, 5 Apr 2012 12:02:49 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0TGB7xwHD+kZtwR4CZDWk8B2rfCQAAbeHJ
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B689@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>,
	<20120405103729.GE14774@ocelot.phlegethon.org>
In-Reply-To: <20120405103729.GE14774@ocelot.phlegethon.org>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Tim Deegan [tim@xen.org]
Sent: 05 April 2012 11:37
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] reserve e820 ram

At 12:52 +0100 on 29 Mar (1333025578), Francisco Rocha wrote:
> Why is e820 being used in arch_init_memory (xen/arch/x86/mm.c in my
> case) and not boot_e820 (the one we changed)?  I am asking because
> from what I understand this will make my use of reserve_e820_ram
> useless, but I think I still not have all the information I need to
> know how it all connects.

arch_init_memory() is only using e820 to find out which addresses are
MMIO regions.  If we were to use boot_e820 we would mark all the
reserve_e820_ram()'d regions as MMIO, which is probably not what you
want.

> To create a range that I can later use as a guest's RAM can I use
> dom_cow instead of dom_io in arch_init_memory?

No! dom_cow is the owner of all copy-on-write shared pages.  You don't
want to get your reserved area caught up in that lot. :)

> Or will that create problems when allocating the pages to an
> unprivileged domain?  I don't want that memory range in use by the
> main memory pool used by the allocators.

AIUI just calling reserve_e820_ram() to exclude the memory from
boot_e820 should DTRT.  Is that not working for you?

> From what I understand. The pages must have to be assigned to a particular domain, dom_xen|io|cow.
> I see this as keeping them mapped and usable before assigning them to the domU I want. Is that thought correct?

I think it shoudl be OK to leave them with no owner -- as long as
they're not in the memory allocator's free pools they won't get given to
any other domain.  Then once you're ready to use them you can assign the
directly to your domU.

How would this "assign" be done? Because when I remove them from the boot_e820 
they are not mapped. That confuses me a bit.

Another option would be to assign them to dom_xen and use
share_xen_page_with_guest to let domU map them.

Can you give us some details about how your current approach is failing?

So far I have tried this approach.

1. use reserve_e820_ram() with boot_e820 to avoid the main memory pool.

2. use reserve_e820_ram() with e820 and change arch_init_memory() to 
assign the reserved range to a dummy domain I have created and let it 
process the IO areas as normal.

One of the problems happens here because some of the mfns are invalid and I 
always end up getting 65536 pages assign to my domain when I count them using
page_list_for_each. Why is this happening? I am not able to understand it yet.
I have been exploring the pdx_groups to see if it is related.

3. I was planning to change populate_physmap to get the memory from the dummy 
domain. I would have to condition the calls to alloc_domheap_pages and use 
share_xen_page_with_guest, is that it? This part is still not very clear to me.
I was hoping to do something like going through the dummy domain's page list 
and steal them from it. :-)

Cheers,

Tim.

Thank you for the help, cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:03:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFkSr-0007ef-BD; Thu, 05 Apr 2012 11:02:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFkSq-0007eZ-I9
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 11:02:52 +0000
Received: from [85.158.139.83:54019] by server-7.bemta-5.messagelabs.com id
	2E/EA-16195-BDB7D7F4; Thu, 05 Apr 2012 11:02:51 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333623770!22612283!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNzY1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 5 Apr 2012 11:02:50 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 11:02:50 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFkSn-0003KS-Fl; Thu, 05 Apr 2012 12:02:49 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Thu, 5 Apr 2012 12:02:49 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Thu, 5 Apr 2012 12:02:49 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0TGB7xwHD+kZtwR4CZDWk8B2rfCQAAbeHJ
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B689@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>,
	<20120405103729.GE14774@ocelot.phlegethon.org>
In-Reply-To: <20120405103729.GE14774@ocelot.phlegethon.org>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Tim Deegan [tim@xen.org]
Sent: 05 April 2012 11:37
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] reserve e820 ram

At 12:52 +0100 on 29 Mar (1333025578), Francisco Rocha wrote:
> Why is e820 being used in arch_init_memory (xen/arch/x86/mm.c in my
> case) and not boot_e820 (the one we changed)?  I am asking because
> from what I understand this will make my use of reserve_e820_ram
> useless, but I think I still not have all the information I need to
> know how it all connects.

arch_init_memory() is only using e820 to find out which addresses are
MMIO regions.  If we were to use boot_e820 we would mark all the
reserve_e820_ram()'d regions as MMIO, which is probably not what you
want.

> To create a range that I can later use as a guest's RAM can I use
> dom_cow instead of dom_io in arch_init_memory?

No! dom_cow is the owner of all copy-on-write shared pages.  You don't
want to get your reserved area caught up in that lot. :)

> Or will that create problems when allocating the pages to an
> unprivileged domain?  I don't want that memory range in use by the
> main memory pool used by the allocators.

AIUI just calling reserve_e820_ram() to exclude the memory from
boot_e820 should DTRT.  Is that not working for you?

> From what I understand. The pages must have to be assigned to a particular domain, dom_xen|io|cow.
> I see this as keeping them mapped and usable before assigning them to the domU I want. Is that thought correct?

I think it shoudl be OK to leave them with no owner -- as long as
they're not in the memory allocator's free pools they won't get given to
any other domain.  Then once you're ready to use them you can assign the
directly to your domU.

How would this "assign" be done? Because when I remove them from the boot_e820 
they are not mapped. That confuses me a bit.

Another option would be to assign them to dom_xen and use
share_xen_page_with_guest to let domU map them.

Can you give us some details about how your current approach is failing?

So far I have tried this approach.

1. use reserve_e820_ram() with boot_e820 to avoid the main memory pool.

2. use reserve_e820_ram() with e820 and change arch_init_memory() to 
assign the reserved range to a dummy domain I have created and let it 
process the IO areas as normal.

One of the problems happens here because some of the mfns are invalid and I 
always end up getting 65536 pages assign to my domain when I count them using
page_list_for_each. Why is this happening? I am not able to understand it yet.
I have been exploring the pdx_groups to see if it is related.

3. I was planning to change populate_physmap to get the memory from the dummy 
domain. I would have to condition the calls to alloc_domheap_pages and use 
share_xen_page_with_guest, is that it? This part is still not very clear to me.
I was hoping to do something like going through the dummy domain's page list 
and steal them from it. :-)

Cheers,

Tim.

Thank you for the help, cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:53:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlFh-000830-FP; Thu, 05 Apr 2012 11:53:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFlFg-00082v-NK
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:53:20 +0000
Received: from [193.109.254.147:63458] by server-7.bemta-14.messagelabs.com id
	33/1D-01627-FA78D7F4; Thu, 05 Apr 2012 11:53:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1333626799!3358139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26371 invoked from network); 5 Apr 2012 11:53:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:53:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11792871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 11:53:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 12:53:11 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFlFW-0002T6-Mm;
	Thu, 05 Apr 2012 11:53:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFlFW-0004Aw-MP;
	Thu, 05 Apr 2012 12:53:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12570-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 12:53:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12570: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12570 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12570/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11890
 build-amd64                   4 xen-build                 fail REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:53:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlFh-000830-FP; Thu, 05 Apr 2012 11:53:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFlFg-00082v-NK
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:53:20 +0000
Received: from [193.109.254.147:63458] by server-7.bemta-14.messagelabs.com id
	33/1D-01627-FA78D7F4; Thu, 05 Apr 2012 11:53:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1333626799!3358139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26371 invoked from network); 5 Apr 2012 11:53:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:53:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="11792871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 11:53:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 12:53:11 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFlFW-0002T6-Mm;
	Thu, 05 Apr 2012 11:53:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFlFW-0004Aw-MP;
	Thu, 05 Apr 2012 12:53:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12570-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 12:53:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12570: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12570 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12570/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11890
 build-amd64                   4 xen-build                 fail REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJe-0008BI-8V; Thu, 05 Apr 2012 11:57:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJc-0008Ay-Di
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:24 +0000
Received: from [193.109.254.147:57466] by server-7.bemta-14.messagelabs.com id
	B9/AE-01627-3A88D7F4; Thu, 05 Apr 2012 11:57:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16409 invoked from network); 5 Apr 2012 11:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-Kq;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:51 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] xen scheduling: Fix credit2 and cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series fixes some long-standing bugs related to credit2
interacting with cpupools.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJe-0008BI-8V; Thu, 05 Apr 2012 11:57:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJc-0008Ay-Di
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:24 +0000
Received: from [193.109.254.147:57466] by server-7.bemta-14.messagelabs.com id
	B9/AE-01627-3A88D7F4; Thu, 05 Apr 2012 11:57:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16409 invoked from network); 5 Apr 2012 11:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-Kq;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:51 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] xen scheduling: Fix credit2 and cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series fixes some long-standing bugs related to credit2
interacting with cpupools.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJf-0008Bd-BH; Thu, 05 Apr 2012 11:57:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJe-0008Ay-0O
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:26 +0000
Received: from [193.109.254.147:61610] by server-7.bemta-14.messagelabs.com id
	2D/AE-01627-5A88D7F4; Thu, 05 Apr 2012 11:57:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16639 invoked from network); 5 Apr 2012 11:57:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901559"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-Lo;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 761f0a1209f6a7ef323d3dab4091d3c10cf360d0
Message-ID: <761f0a1209f6a7ef323d.1333626893@kodo2>
In-Reply-To: <patchbomb.1333626891@kodo2>
References: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] xen,
 credit2: Put the per-cpu schedule lock back to the default lock
 when releasing cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This fixes a bug that happens when you remove cpus from a credit2 cpupool.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r fd0d2fd2824b -r 761f0a1209f6 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Thu Apr 05 12:20:04 2012 +0100
+++ b/xen/common/sched_credit2.c	Thu Apr 05 12:45:14 2012 +0100
@@ -1952,6 +1952,7 @@ csched_free_pdata(const struct scheduler
     unsigned long flags;
     struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_runqueue_data *rqd;
+    struct schedule_data *sd = &per_cpu(schedule_data, cpu);
     int rqi;
 
     spin_lock_irqsave(&prv->lock, flags);
@@ -1979,6 +1980,11 @@ csched_free_pdata(const struct scheduler
         deactivate_runqueue(prv, rqi);
     }
 
+    /* Move spinlock to the original lock.  */
+    ASSERT(sd->schedule_lock == &rqd->lock);
+    ASSERT(!spin_is_locked(&sd->_lock));
+    sd->schedule_lock = &sd->_lock;
+
     spin_unlock(&rqd->lock);
 
     cpumask_clear_cpu(cpu, &prv->initialized);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJf-0008Bd-BH; Thu, 05 Apr 2012 11:57:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJe-0008Ay-0O
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:26 +0000
Received: from [193.109.254.147:61610] by server-7.bemta-14.messagelabs.com id
	2D/AE-01627-5A88D7F4; Thu, 05 Apr 2012 11:57:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16639 invoked from network); 5 Apr 2012 11:57:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901559"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-Lo;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 761f0a1209f6a7ef323d3dab4091d3c10cf360d0
Message-ID: <761f0a1209f6a7ef323d.1333626893@kodo2>
In-Reply-To: <patchbomb.1333626891@kodo2>
References: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] xen,
 credit2: Put the per-cpu schedule lock back to the default lock
 when releasing cpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This fixes a bug that happens when you remove cpus from a credit2 cpupool.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r fd0d2fd2824b -r 761f0a1209f6 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Thu Apr 05 12:20:04 2012 +0100
+++ b/xen/common/sched_credit2.c	Thu Apr 05 12:45:14 2012 +0100
@@ -1952,6 +1952,7 @@ csched_free_pdata(const struct scheduler
     unsigned long flags;
     struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_runqueue_data *rqd;
+    struct schedule_data *sd = &per_cpu(schedule_data, cpu);
     int rqi;
 
     spin_lock_irqsave(&prv->lock, flags);
@@ -1979,6 +1980,11 @@ csched_free_pdata(const struct scheduler
         deactivate_runqueue(prv, rqi);
     }
 
+    /* Move spinlock to the original lock.  */
+    ASSERT(sd->schedule_lock == &rqd->lock);
+    ASSERT(!spin_is_locked(&sd->_lock));
+    sd->schedule_lock = &sd->_lock;
+
     spin_unlock(&rqd->lock);
 
     cpumask_clear_cpu(cpu, &prv->initialized);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJe-0008BP-Ju; Thu, 05 Apr 2012 11:57:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJd-0008Az-2i
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:25 +0000
Received: from [193.109.254.147:5412] by server-3.bemta-14.messagelabs.com id
	8C/DA-23274-4A88D7F4; Thu, 05 Apr 2012 11:57:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16503 invoked from network); 5 Apr 2012 11:57:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901557"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-LM;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: fd0d2fd2824b63d724ea3d8782ad64bd53b6875e
Message-ID: <fd0d2fd2824b63d724ea.1333626892@kodo2>
In-Reply-To: <patchbomb.1333626891@kodo2>
References: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:52 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] xen: Fix schedule's grabbing of the
	schedule lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the location of the lock can change between the time you read
it and the time you grab it, the per-cpu schedule locks need to check
after lock acquisition that the lock location hasn't changed, and
release and re-try if so.  This change was effected throughout the
source code, but one very important place was apparently missed: in
schedule() itself.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 197e09bf0322 -r fd0d2fd2824b xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Apr 04 11:29:43 2012 +0100
+++ b/xen/common/schedule.c	Thu Apr 05 12:20:04 2012 +0100
@@ -1075,6 +1075,7 @@ static void schedule(void)
     bool_t                tasklet_work_scheduled = 0;
     struct schedule_data *sd;
     struct task_slice     next_slice;
+    int cpu = smp_processor_id();
 
     ASSERT(!in_atomic());
 
@@ -1099,7 +1100,7 @@ static void schedule(void)
         BUG();
     }
 
-    spin_lock_irq(sd->schedule_lock);
+    pcpu_schedule_lock_irq(cpu);
 
     stop_timer(&sd->s_timer);
     
@@ -1116,7 +1117,7 @@ static void schedule(void)
 
     if ( unlikely(prev == next) )
     {
-        spin_unlock_irq(sd->schedule_lock);
+        pcpu_schedule_unlock_irq(cpu);
         trace_continue_running(next);
         return continue_running(prev);
     }
@@ -1154,7 +1155,7 @@ static void schedule(void)
     ASSERT(!next->is_running);
     next->is_running = 1;
 
-    spin_unlock_irq(sd->schedule_lock);
+    pcpu_schedule_unlock_irq(cpu);
 
     perfc_incr(sched_ctx);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJe-0008BP-Ju; Thu, 05 Apr 2012 11:57:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJd-0008Az-2i
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:25 +0000
Received: from [193.109.254.147:5412] by server-3.bemta-14.messagelabs.com id
	8C/DA-23274-4A88D7F4; Thu, 05 Apr 2012 11:57:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16503 invoked from network); 5 Apr 2012 11:57:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901557"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-LM;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: fd0d2fd2824b63d724ea3d8782ad64bd53b6875e
Message-ID: <fd0d2fd2824b63d724ea.1333626892@kodo2>
In-Reply-To: <patchbomb.1333626891@kodo2>
References: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:52 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] xen: Fix schedule's grabbing of the
	schedule lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the location of the lock can change between the time you read
it and the time you grab it, the per-cpu schedule locks need to check
after lock acquisition that the lock location hasn't changed, and
release and re-try if so.  This change was effected throughout the
source code, but one very important place was apparently missed: in
schedule() itself.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 197e09bf0322 -r fd0d2fd2824b xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Apr 04 11:29:43 2012 +0100
+++ b/xen/common/schedule.c	Thu Apr 05 12:20:04 2012 +0100
@@ -1075,6 +1075,7 @@ static void schedule(void)
     bool_t                tasklet_work_scheduled = 0;
     struct schedule_data *sd;
     struct task_slice     next_slice;
+    int cpu = smp_processor_id();
 
     ASSERT(!in_atomic());
 
@@ -1099,7 +1100,7 @@ static void schedule(void)
         BUG();
     }
 
-    spin_lock_irq(sd->schedule_lock);
+    pcpu_schedule_lock_irq(cpu);
 
     stop_timer(&sd->s_timer);
     
@@ -1116,7 +1117,7 @@ static void schedule(void)
 
     if ( unlikely(prev == next) )
     {
-        spin_unlock_irq(sd->schedule_lock);
+        pcpu_schedule_unlock_irq(cpu);
         trace_continue_running(next);
         return continue_running(prev);
     }
@@ -1154,7 +1155,7 @@ static void schedule(void)
     ASSERT(!next->is_running);
     next->is_running = 1;
 
-    spin_unlock_irq(sd->schedule_lock);
+    pcpu_schedule_unlock_irq(cpu);
 
     perfc_incr(sched_ctx);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJe-0008BW-WC; Thu, 05 Apr 2012 11:57:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJd-0008B4-Mg
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:25 +0000
Received: from [193.109.254.147:5448] by server-5.bemta-14.messagelabs.com id
	4D/13-30733-4A88D7F4; Thu, 05 Apr 2012 11:57:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16572 invoked from network); 5 Apr 2012 11:57:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901558"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-ME;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 869ead491d7c470024e1d77f06cdbcb20b7580c1
Message-ID: <869ead491d7c470024e1.1333626894@kodo2>
In-Reply-To: <patchbomb.1333626891@kodo2>
References: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:54 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] xen,
	cpupools: Fix cpupool-move to make more consistent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The full order for creating new private data structures when moving
from one pool to another is now:
* Allocate all new structures
 - Allocate a new private domain structure (but don't point there yet)
 - Allocate per-vcpu data structures (but don't point there yet)
* Remove old structures
 - Remove each vcpu, freeing the associated data structure
 - Free the domain data structure
* Switch to the new structures
 - Set the domain to the new cpupool, with the new private domain structure
 - Set each vcpu to the respective new structure, and insert

This is in line with a (fairly reasonable) assumption in credit2 that the
private structure of the domain will be the private structure pointed to
by the per-vcpu private structure.

Also fix a bug, in which insert_vcpu was called with the *old* vcpu ops
rather than the new ones.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 761f0a1209f6 -r 869ead491d7c xen/common/schedule.c
--- a/xen/common/schedule.c	Thu Apr 05 12:45:14 2012 +0100
+++ b/xen/common/schedule.c	Thu Apr 05 12:54:33 2012 +0100
@@ -261,6 +261,18 @@ int sched_move_domain(struct domain *d, 
 
     domain_pause(d);
 
+    for_each_vcpu ( d, v )
+    {
+        SCHED_OP(VCPU2OP(v), remove_vcpu, v);
+        SCHED_OP(VCPU2OP(v), free_vdata, v->sched_priv);
+        v->sched_priv = NULL;
+    }
+
+    SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
+
+    d->cpupool = c;
+    d->sched_priv = domdata;
+
     new_p = cpumask_first(c->cpu_valid);
     for_each_vcpu ( d, v )
     {
@@ -268,9 +280,6 @@ int sched_move_domain(struct domain *d, 
         migrate_timer(&v->singleshot_timer, new_p);
         migrate_timer(&v->poll_timer, new_p);
 
-        SCHED_OP(VCPU2OP(v), remove_vcpu, v);
-        SCHED_OP(VCPU2OP(v), free_vdata, v->sched_priv);
-
         cpumask_setall(v->cpu_affinity);
         v->processor = new_p;
         v->sched_priv = vcpu_priv[v->vcpu_id];
@@ -278,13 +287,9 @@ int sched_move_domain(struct domain *d, 
 
         new_p = cpumask_cycle(new_p, c->cpu_valid);
 
-        SCHED_OP(VCPU2OP(v), insert_vcpu, v);
+        SCHED_OP(c->sched, insert_vcpu, v);
     }
 
-    d->cpupool = c;
-    SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
-    d->sched_priv = domdata;
-
     domain_update_node_affinity(d);
 
     domain_unpause(d);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 11:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 11:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlJe-0008BW-WC; Thu, 05 Apr 2012 11:57:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFlJd-0008B4-Mg
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 11:57:25 +0000
Received: from [193.109.254.147:5448] by server-5.bemta-14.messagelabs.com id
	4D/13-30733-4A88D7F4; Thu, 05 Apr 2012 11:57:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333627041!3393589!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16572 invoked from network); 5 Apr 2012 11:57:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901558"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 07:57:21 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 07:57:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFlJY-000155-ME;
	Thu, 05 Apr 2012 12:57:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 869ead491d7c470024e1d77f06cdbcb20b7580c1
Message-ID: <869ead491d7c470024e1.1333626894@kodo2>
In-Reply-To: <patchbomb.1333626891@kodo2>
References: <patchbomb.1333626891@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 12:54:54 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] xen,
	cpupools: Fix cpupool-move to make more consistent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The full order for creating new private data structures when moving
from one pool to another is now:
* Allocate all new structures
 - Allocate a new private domain structure (but don't point there yet)
 - Allocate per-vcpu data structures (but don't point there yet)
* Remove old structures
 - Remove each vcpu, freeing the associated data structure
 - Free the domain data structure
* Switch to the new structures
 - Set the domain to the new cpupool, with the new private domain structure
 - Set each vcpu to the respective new structure, and insert

This is in line with a (fairly reasonable) assumption in credit2 that the
private structure of the domain will be the private structure pointed to
by the per-vcpu private structure.

Also fix a bug, in which insert_vcpu was called with the *old* vcpu ops
rather than the new ones.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 761f0a1209f6 -r 869ead491d7c xen/common/schedule.c
--- a/xen/common/schedule.c	Thu Apr 05 12:45:14 2012 +0100
+++ b/xen/common/schedule.c	Thu Apr 05 12:54:33 2012 +0100
@@ -261,6 +261,18 @@ int sched_move_domain(struct domain *d, 
 
     domain_pause(d);
 
+    for_each_vcpu ( d, v )
+    {
+        SCHED_OP(VCPU2OP(v), remove_vcpu, v);
+        SCHED_OP(VCPU2OP(v), free_vdata, v->sched_priv);
+        v->sched_priv = NULL;
+    }
+
+    SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
+
+    d->cpupool = c;
+    d->sched_priv = domdata;
+
     new_p = cpumask_first(c->cpu_valid);
     for_each_vcpu ( d, v )
     {
@@ -268,9 +280,6 @@ int sched_move_domain(struct domain *d, 
         migrate_timer(&v->singleshot_timer, new_p);
         migrate_timer(&v->poll_timer, new_p);
 
-        SCHED_OP(VCPU2OP(v), remove_vcpu, v);
-        SCHED_OP(VCPU2OP(v), free_vdata, v->sched_priv);
-
         cpumask_setall(v->cpu_affinity);
         v->processor = new_p;
         v->sched_priv = vcpu_priv[v->vcpu_id];
@@ -278,13 +287,9 @@ int sched_move_domain(struct domain *d, 
 
         new_p = cpumask_cycle(new_p, c->cpu_valid);
 
-        SCHED_OP(VCPU2OP(v), insert_vcpu, v);
+        SCHED_OP(c->sched, insert_vcpu, v);
     }
 
-    d->cpupool = c;
-    SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
-    d->sched_priv = domdata;
-
     domain_update_node_affinity(d);
 
     domain_unpause(d);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWn-0000Wm-A5; Thu, 05 Apr 2012 12:11:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWl-0000WH-G6
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:59 +0000
Received: from [85.158.139.83:18212] by server-12.bemta-5.messagelabs.com id
	B2/68-05587-2DB8D7F4; Thu, 05 Apr 2012 12:10:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333627856!15274932!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22240 invoked from network); 5 Apr 2012 12:10:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901919"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:54 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWg-0001Ic-L3	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:54 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWg-0005t6-By	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:54 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5a2f5ab5128e4b13b3fd2dbcae1f084bc922584e
Message-ID: <5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:19 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
	variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 5a2f5ab5128e4b13b3fd2dbcae1f084bc922584e
# Parent  5101e5ed24732919076d5285e55c7b53032749c2
x86: explicitly mark an __initdata variable as used.

This stops LLVM from replacing it with a different, auto-generated
variable as part of an optimization.  (The auto-generated variable
ends up in the normal data section, failing the check that this
file only contains __initdata vars).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
--- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
@@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
     struct domain *d, unsigned long max_pages)
 {
     static unsigned int __initdata last_order = MAX_ORDER;
-    static unsigned int __initdata memflags = MEMF_no_dma;
+    static unsigned int __initdata __attribute__((used)) memflags = MEMF_no_dma;
     struct page_info *page;
     unsigned int order = get_order_from_pages(max_pages), free_order;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWn-0000Wm-A5; Thu, 05 Apr 2012 12:11:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWl-0000WH-G6
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:59 +0000
Received: from [85.158.139.83:18212] by server-12.bemta-5.messagelabs.com id
	B2/68-05587-2DB8D7F4; Thu, 05 Apr 2012 12:10:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333627856!15274932!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22240 invoked from network); 5 Apr 2012 12:10:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901919"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:54 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWg-0001Ic-L3	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:54 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWg-0005t6-By	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:54 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5a2f5ab5128e4b13b3fd2dbcae1f084bc922584e
Message-ID: <5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:19 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
	variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 5a2f5ab5128e4b13b3fd2dbcae1f084bc922584e
# Parent  5101e5ed24732919076d5285e55c7b53032749c2
x86: explicitly mark an __initdata variable as used.

This stops LLVM from replacing it with a different, auto-generated
variable as part of an optimization.  (The auto-generated variable
ends up in the normal data section, failing the check that this
file only contains __initdata vars).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
--- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
@@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
     struct domain *d, unsigned long max_pages)
 {
     static unsigned int __initdata last_order = MAX_ORDER;
-    static unsigned int __initdata memflags = MEMF_no_dma;
+    static unsigned int __initdata __attribute__((used)) memflags = MEMF_no_dma;
     struct page_info *page;
     unsigned int order = get_order_from_pages(max_pages), free_order;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWl-0000WK-Hc; Thu, 05 Apr 2012 12:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWj-0000Vw-Pe
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:58 +0000
Received: from [85.158.138.51:35409] by server-1.bemta-3.messagelabs.com id
	63/8C-04539-1DB8D7F4; Thu, 05 Apr 2012 12:10:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333627854!16744421!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30155 invoked from network); 5 Apr 2012 12:10:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901917"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWf-0001IT-PK	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:53 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWf-0005su-G5	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:53 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
Message-ID: <5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:16 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of comparisons of
 unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
# Parent  0ecf439475e12f185553f42f56f099be5f328cce
x86/mm: Another couple of comparisons of unsigned vars with < 0.

Adding the explicit (unsigned) casts in case enums ever end up signed.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0ecf439475e1 -r 5eeaa7b25a60 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
@@ -1305,7 +1305,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m->default_access,
     };
 
-    if ( access >= HVMMEM_access_default || access < 0 )
+    if ( (unsigned) access >= HVMMEM_access_default )
         return -EINVAL;
 
     a = memaccess[access];
@@ -1367,7 +1367,7 @@ int p2m_get_mem_access(struct domain *d,
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     
-    if ( a >= ARRAY_SIZE(memaccess) || a < 0 )
+    if ( (unsigned) a >= ARRAY_SIZE(memaccess) )
         return -ERANGE;
 
     *access =  memaccess[a];

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWl-0000WK-Hc; Thu, 05 Apr 2012 12:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWj-0000Vw-Pe
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:58 +0000
Received: from [85.158.138.51:35409] by server-1.bemta-3.messagelabs.com id
	63/8C-04539-1DB8D7F4; Thu, 05 Apr 2012 12:10:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333627854!16744421!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30155 invoked from network); 5 Apr 2012 12:10:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901917"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWf-0001IT-PK	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:53 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWf-0005su-G5	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:53 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
Message-ID: <5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:16 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of comparisons of
 unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
# Parent  0ecf439475e12f185553f42f56f099be5f328cce
x86/mm: Another couple of comparisons of unsigned vars with < 0.

Adding the explicit (unsigned) casts in case enums ever end up signed.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0ecf439475e1 -r 5eeaa7b25a60 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
@@ -1305,7 +1305,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m->default_access,
     };
 
-    if ( access >= HVMMEM_access_default || access < 0 )
+    if ( (unsigned) access >= HVMMEM_access_default )
         return -EINVAL;
 
     a = memaccess[access];
@@ -1367,7 +1367,7 @@ int p2m_get_mem_access(struct domain *d,
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     
-    if ( a >= ARRAY_SIZE(memaccess) || a < 0 )
+    if ( (unsigned) a >= ARRAY_SIZE(memaccess) )
         return -ERANGE;
 
     *access =  memaccess[a];

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWo-0000X6-Mm; Thu, 05 Apr 2012 12:11:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWn-0000Wg-FH
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:11:01 +0000
Received: from [85.158.138.51:35709] by server-2.bemta-3.messagelabs.com id
	AC/92-15460-4DB8D7F4; Thu, 05 Apr 2012 12:11:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333627855!20951299!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23956 invoked from network); 5 Apr 2012 12:10:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189141894"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:54 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWg-0001IZ-Bf	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:54 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWg-0005t2-2W	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:54 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5101e5ed24732919076d5285e55c7b53032749c2
Message-ID: <5101e5ed24732919076d.1333627638@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:18 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 6] x86: fix memset(ptr, 0, sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 5101e5ed24732919076d5285e55c7b53032749c2
# Parent  dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
x86: fix memset(ptr, 0, sizeof ptr).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
@@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
 		return NULL;
 	}
 
-	memset(mc_ext, 0, sizeof(mc_ext));
+	memset(mc_ext, 0, sizeof(*mc_ext));
 	mc_ext->common.type = MC_TYPE_EXTENDED;
-	mc_ext->common.size = sizeof(mc_ext);
+	mc_ext->common.size = sizeof(*mc_ext);
 	mc_ext->mc_msrs = 3;
 
 	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
@@ -1236,7 +1236,7 @@ bool_t p2m_mem_access_check(unsigned lon
     if ( req )
     {
         *req_ptr = req;
-        memset(req, 0, sizeof(req));
+        memset(req, 0, sizeof (mem_event_request_t));
         req->reason = MEM_EVENT_REASON_VIOLATION;
 
         /* Pause the current VCPU */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWq-0000Xg-3N; Thu, 05 Apr 2012 12:11:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWo-0000X1-Kq
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:11:02 +0000
Received: from [85.158.143.35:54595] by server-1.bemta-4.messagelabs.com id
	E0/C1-20925-5DB8D7F4; Thu, 05 Apr 2012 12:11:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333627853!12013229!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24606 invoked from network); 5 Apr 2012 12:10:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189141887"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWf-0001IQ-Fn	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:53 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWf-0005sq-5d	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:53 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0ecf439475e12f185553f42f56f099be5f328cce
Message-ID: <0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:15 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
 out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 0ecf439475e12f185553f42f56f099be5f328cce
# Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
x86: don't use .subsection to out-of-line failure path in spinlock.h

LLVM's assembler doesn't support the .subsection directive.  Instead,
leave the failure path inline with an unconditional jump past it in
the success path (so the conditional jump is still forwards).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 8518fb0c8c99 -r 0ecf439475e1 xen/include/asm-x86/spinlock.h
--- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
@@ -44,12 +44,11 @@ static always_inline int _raw_read_trylo
 
     asm volatile (
         "    lock; decl %0         \n"
-        "    jns 2f                \n"
-        "1:  .subsection 1         \n"
-        "2:  lock; incl %0         \n"
+        "    jns 1f                \n"
+        "    jmp 2f                \n"
+        "1:  lock; incl %0         \n"
         "    decl %1               \n"
-        "    jmp 1b                \n"
-        "    .subsection 0         \n"
+        "2:                        \n"
         : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
 
     return acquired;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWo-0000X6-Mm; Thu, 05 Apr 2012 12:11:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWn-0000Wg-FH
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:11:01 +0000
Received: from [85.158.138.51:35709] by server-2.bemta-3.messagelabs.com id
	AC/92-15460-4DB8D7F4; Thu, 05 Apr 2012 12:11:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333627855!20951299!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23956 invoked from network); 5 Apr 2012 12:10:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189141894"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:54 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWg-0001IZ-Bf	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:54 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWg-0005t2-2W	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:54 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5101e5ed24732919076d5285e55c7b53032749c2
Message-ID: <5101e5ed24732919076d.1333627638@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:18 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 6] x86: fix memset(ptr, 0, sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 5101e5ed24732919076d5285e55c7b53032749c2
# Parent  dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
x86: fix memset(ptr, 0, sizeof ptr).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
@@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
 		return NULL;
 	}
 
-	memset(mc_ext, 0, sizeof(mc_ext));
+	memset(mc_ext, 0, sizeof(*mc_ext));
 	mc_ext->common.type = MC_TYPE_EXTENDED;
-	mc_ext->common.size = sizeof(mc_ext);
+	mc_ext->common.size = sizeof(*mc_ext);
 	mc_ext->mc_msrs = 3;
 
 	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
@@ -1236,7 +1236,7 @@ bool_t p2m_mem_access_check(unsigned lon
     if ( req )
     {
         *req_ptr = req;
-        memset(req, 0, sizeof(req));
+        memset(req, 0, sizeof (mem_event_request_t));
         req->reason = MEM_EVENT_REASON_VIOLATION;
 
         /* Pause the current VCPU */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWq-0000Xg-3N; Thu, 05 Apr 2012 12:11:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWo-0000X1-Kq
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:11:02 +0000
Received: from [85.158.143.35:54595] by server-1.bemta-4.messagelabs.com id
	E0/C1-20925-5DB8D7F4; Thu, 05 Apr 2012 12:11:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333627853!12013229!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24606 invoked from network); 5 Apr 2012 12:10:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189141887"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWf-0001IQ-Fn	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:53 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWf-0005sq-5d	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:53 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0ecf439475e12f185553f42f56f099be5f328cce
Message-ID: <0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:15 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
 out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 0ecf439475e12f185553f42f56f099be5f328cce
# Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
x86: don't use .subsection to out-of-line failure path in spinlock.h

LLVM's assembler doesn't support the .subsection directive.  Instead,
leave the failure path inline with an unconditional jump past it in
the success path (so the conditional jump is still forwards).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 8518fb0c8c99 -r 0ecf439475e1 xen/include/asm-x86/spinlock.h
--- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
@@ -44,12 +44,11 @@ static always_inline int _raw_read_trylo
 
     asm volatile (
         "    lock; decl %0         \n"
-        "    jns 2f                \n"
-        "1:  .subsection 1         \n"
-        "2:  lock; incl %0         \n"
+        "    jns 1f                \n"
+        "    jmp 2f                \n"
+        "1:  lock; incl %0         \n"
         "    decl %1               \n"
-        "    jmp 1b                \n"
-        "    .subsection 0         \n"
+        "2:                        \n"
         : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
 
     return acquired;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWl-0000WV-Tz; Thu, 05 Apr 2012 12:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWk-0000W5-KU
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:58 +0000
Received: from [85.158.138.51:35493] by server-12.bemta-3.messagelabs.com id
	4E/85-30663-1DB8D7F4; Thu, 05 Apr 2012 12:10:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333627854!16744421!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30188 invoked from network); 5 Apr 2012 12:10:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901918"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:54 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWg-0001IW-2D	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:54 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWf-0005sy-Pe	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:53 +0100
MIME-Version: 1.0
X-Mercurial-Node: dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
Message-ID: <dfe9453c066f3fbfa09c.1333627637@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:17 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 6] x86: fix logical ANDs used to mask
	bitfields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
# Parent  5eeaa7b25a60327c48bf17472e9a00bdfc67378f
x86: fix logical ANDs used to mask bitfields.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
@@ -752,7 +752,7 @@ static void svm_lwp_interrupt(struct cpu
     ack_APIC_irq();
     vlapic_set_irq(
         vcpu_vlapic(curr),
-        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) && 0xff,
+        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) & 0xff,
         0);
 }
 
diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
@@ -1382,7 +1382,7 @@ void vmx_inject_extint(int trap)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_EXT_INTR_MASK ) {
+        if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
                HVM_DELIVER_NO_ERROR_CODE);
@@ -1401,7 +1401,7 @@ void vmx_inject_nmi(void)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_NMI_EXITING ) {
+        if ( pin_based_cntrl & PIN_BASED_NMI_EXITING ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
                HVM_DELIVER_NO_ERROR_CODE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWl-0000WV-Tz; Thu, 05 Apr 2012 12:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWk-0000W5-KU
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:58 +0000
Received: from [85.158.138.51:35493] by server-12.bemta-3.messagelabs.com id
	4E/85-30663-1DB8D7F4; Thu, 05 Apr 2012 12:10:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333627854!16744421!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30188 invoked from network); 5 Apr 2012 12:10:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901918"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:54 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWg-0001IW-2D	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:54 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWf-0005sy-Pe	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:53 +0100
MIME-Version: 1.0
X-Mercurial-Node: dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
Message-ID: <dfe9453c066f3fbfa09c.1333627637@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:17 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 6] x86: fix logical ANDs used to mask
	bitfields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
# Parent  5eeaa7b25a60327c48bf17472e9a00bdfc67378f
x86: fix logical ANDs used to mask bitfields.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
@@ -752,7 +752,7 @@ static void svm_lwp_interrupt(struct cpu
     ack_APIC_irq();
     vlapic_set_irq(
         vcpu_vlapic(curr),
-        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) && 0xff,
+        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) & 0xff,
         0);
 }
 
diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
@@ -1382,7 +1382,7 @@ void vmx_inject_extint(int trap)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_EXT_INTR_MASK ) {
+        if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
                HVM_DELIVER_NO_ERROR_CODE);
@@ -1401,7 +1401,7 @@ void vmx_inject_nmi(void)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_NMI_EXITING ) {
+        if ( pin_based_cntrl & PIN_BASED_NMI_EXITING ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
                HVM_DELIVER_NO_ERROR_CODE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWk-0000W6-5g; Thu, 05 Apr 2012 12:10:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWj-0000Vv-8v
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:57 +0000
Received: from [85.158.138.51:2648] by server-11.bemta-3.messagelabs.com id
	C8/8A-28543-0DB8D7F4; Thu, 05 Apr 2012 12:10:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333627854!16744421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30137 invoked from network); 5 Apr 2012 12:10:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901915"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWf-0001II-5J	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:53 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWe-0005sm-T5	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:52 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8518fb0c8c996dca67efd39d31962a6d3502c2ed
Message-ID: <8518fb0c8c996dca67ef.1333627634@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:14 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 6] xen: Add -Wno-unused-value to the clang
	CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 8518fb0c8c996dca67efd39d31962a6d3502c2ed
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
xen: Add -Wno-unused-value to the clang CFLAGS

clang complains about a lot of functions and macros whose return value
is unused.  I started on patches to drop some functions' return values
and scatter (void)s around callers, but it was getting too messy.
Just turn off the warning instead.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r d690c7e896a2 -r 8518fb0c8c99 Config.mk
--- a/Config.mk	Thu Apr 05 11:06:03 2012 +0100
+++ b/Config.mk	Thu Apr 05 12:55:54 2012 +0100
@@ -159,7 +159,8 @@ CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 # and is over-zealous with the printf format lint
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format
+# and is a bit too fierce about unused return values
+CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWk-0000W6-5g; Thu, 05 Apr 2012 12:10:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWj-0000Vv-8v
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:10:57 +0000
Received: from [85.158.138.51:2648] by server-11.bemta-3.messagelabs.com id
	C8/8A-28543-0DB8D7F4; Thu, 05 Apr 2012 12:10:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333627854!16744421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30137 invoked from network); 5 Apr 2012 12:10:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="23901915"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWf-0001II-5J	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:53 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWe-0005sm-T5	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:52 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8518fb0c8c996dca67efd39d31962a6d3502c2ed
Message-ID: <8518fb0c8c996dca67ef.1333627634@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:14 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 6] xen: Add -Wno-unused-value to the clang
	CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333626954 -3600
# Node ID 8518fb0c8c996dca67efd39d31962a6d3502c2ed
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
xen: Add -Wno-unused-value to the clang CFLAGS

clang complains about a lot of functions and macros whose return value
is unused.  I started on patches to drop some functions' return values
and scatter (void)s around callers, but it was getting too messy.
Just turn off the warning instead.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r d690c7e896a2 -r 8518fb0c8c99 Config.mk
--- a/Config.mk	Thu Apr 05 11:06:03 2012 +0100
+++ b/Config.mk	Thu Apr 05 12:55:54 2012 +0100
@@ -159,7 +159,8 @@ CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 # and is over-zealous with the printf format lint
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format
+# and is a bit too fierce about unused return values
+CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWq-0000Y0-FZ; Thu, 05 Apr 2012 12:11:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWo-0000X2-OF
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:11:02 +0000
Received: from [85.158.143.35:54597] by server-2.bemta-4.messagelabs.com id
	6D/AA-17550-5DB8D7F4; Thu, 05 Apr 2012 12:11:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333627853!12013229!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24545 invoked from network); 5 Apr 2012 12:10:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189141886"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWe-0001IF-Sm	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:52 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWe-0005sj-M6	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:52 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:13 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 6] Make xen build with clang/LLVM again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series makes the hypervisor build with clang/LLVM again,
after a certain amount of bit-rot. 

Some of these are obvious bug-fixes which are picked up by clang's 
slightly different -W* implementation.  Some (the spinlock change
in particular) are working around deficiencies in clang/llvm.  I'm 
happy to change those ones to avoid any concerns people have about
damaging the GCC build. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:11:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFlWq-0000Y0-FZ; Thu, 05 Apr 2012 12:11:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFlWo-0000X2-OF
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:11:02 +0000
Received: from [85.158.143.35:54597] by server-2.bemta-4.messagelabs.com id
	6D/AA-17550-5DB8D7F4; Thu, 05 Apr 2012 12:11:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333627853!12013229!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24545 invoked from network); 5 Apr 2012 12:10:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189141886"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 08:10:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 08:10:53 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFlWe-0001IF-Sm	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 13:10:52 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFlWe-0005sj-M6	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:10:52 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333627633@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 13:07:13 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 6] Make xen build with clang/LLVM again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series makes the hypervisor build with clang/LLVM again,
after a certain amount of bit-rot. 

Some of these are obvious bug-fixes which are picked up by clang's 
slightly different -W* implementation.  Some (the spinlock change
in particular) are working around deficiencies in clang/llvm.  I'm 
happy to change those ones to avoid any concerns people have about
damaging the GCC build. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:23:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFliJ-0001Wl-VE; Thu, 05 Apr 2012 12:22:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <the.kazak@gmail.com>) id 1SFliJ-0001WW-7l
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:22:55 +0000
Received: from [85.158.143.35:57557] by server-3.bemta-4.messagelabs.com id
	A5/E0-05853-D9E8D7F4; Thu, 05 Apr 2012 12:22:53 +0000
X-Env-Sender: the.kazak@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333628570!14867578!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27095 invoked from network); 5 Apr 2012 12:22:51 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:22:51 -0000
Received: by bkcjg9 with SMTP id jg9so1460407bkc.32
	for <multiple recipients>; Thu, 05 Apr 2012 05:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=SroVNrVSLh/KUYGlpxkXsltsootHYK8/avmxzWEiGHM=;
	b=M5vvB+Z4gy13KHCST6Zfy+ONzCcp9j8tkl8qDW/RFs9g7/nPK7nwMh38MFbr+qXiP+
	78xSXyBK2gg0Ucl4+3/JrAAHkCTg+88WrG6IYYcqPzcmVH5skD1H3ngEMLFZnVLPlL0p
	mk9PRcD+oyQUGJJVfMC/T/Z+pvKKs5wTL1xb7xWohrfr9pAloXuWJdbnTkn6z71WmAkH
	en/oGmw/OyUZWoECHtH7290T9GMVixLS2DQjPQJgBWEbaUol3CO9+EEDzbPVOgMV9Bcu
	zD0Ih3OzMAVLqpXKspQikhEVKwG/TJmUM7O5PwE5g8WVS1J2tmhx3a839rHS4cuuHWpP
	igDg==
Received: by 10.204.132.72 with SMTP id a8mr1070276bkt.42.1333628569998;
	Thu, 05 Apr 2012 05:22:49 -0700 (PDT)
Received: from [212.50.0.54] (purple.varna.spnet.net. [212.50.0.54])
	by mx.google.com with ESMTPS id zx16sm8484731bkb.13.2012.04.05.05.22.47
	(version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 05:22:48 -0700 (PDT)
Message-ID: <4F7D8E96.1040808@gmail.com>
Date: Thu, 05 Apr 2012 15:22:46 +0300
From: Dimitar Kazakov <the.kazak@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: xen-api@lists.xen.org, xen-devel@lists.xen.org
References: <4F7D6480.6040704@gmail.com>
	<7549B613-6EB9-4DD8-9741-C0D8556D0176@eu.citrix.com>
In-Reply-To: <7549B613-6EB9-4DD8-9741-C0D8556D0176@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------050905020305040603080804"
Subject: Re: [Xen-devel] [Xen-API] (solved) xe vdi-create failure ot local
 SR type=file and type=ext
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a multi-part message in MIME format.
--------------050905020305040603080804
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Thanks!
I found the problem in SMlog.

/usr/sbin/td-util create vhd 1024
/var/run/sr-mount/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/247b64e4-6b7f-4b2f-bd73-50e848c78d71.vhd
/usr/sbin/td-util: error while loading shared libraries:
libxenctrl.so.4.0: cannot open shared object file: No such file or directory

td-util from blktap-utils 2.0.90-3 (testing) is looking for
libxenctrl.so.4.0, but the package libxen-4.1 4.1.2-2.1 (testing) offers
only  libxenctrl-4.1.so in /usr/lib.
Makeing a link libxenctrl.so.4.0 to libxenctrl-4.1.so in /usr/lib solves
the problem.

SMlog snippet:
[22578] 2012-04-05 14:00:27.322636    ['uuidgen', '-r']
[22578] 2012-04-05 14:00:27.329600    SUCCESS
[22578] 2012-04-05 14:00:27.336360    lock: acquired
/var/lock/sm/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/sr
[22578] 2012-04-05 14:00:27.336677    vdi_create {'sr_uuid':
'4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2', 'subtask_of':
'DummyRef:|7d48c27e-b70e-59eb-6197-51518053c92e|VDI.create', 'vdi_type':
'user', 'args': ['1073741824', 'test', '', '', 'false',
'19700101T00:00:00Z', '', 'false'], 'host_ref':
'OpaqueRef:e5783245-3c2c-df70-80c3-244d77ebc59f', 'session_ref':
'OpaqueRef:0c7299c1-981a-c1b5-f5b7-17a1a467518f', 'device_config':
{'device': '/dev/sdb1', 'SRmaster': 'true'}, 'command': 'vdi_create',
'sr_ref': 'OpaqueRef:ed43ec0a-3570-7535-cac9-d4a086f69d18',
'vdi_sm_config': {}}
[22578] 2012-04-05 14:00:27.337019    ['/usr/sbin/td-util', 'create',
'vhd', '1024',
'/var/run/sr-mount/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/247b64e4-6b7f-4b2f-bd73-50e848c78d71.vhd']
[22578] 2012-04-05 14:00:27.342837    FAILED: (rc 127) stdout: '',
stderr: '/usr/sbin/td-util: error while loading shared libraries:
libxenctrl.so.4.0: cannot open shared object file: No such file or directory
'
[22578] 2012-04-05 14:00:27.361494    Raising exception [78, VDI
Creation failed [opterr=error 127]]
[22578] 2012-04-05 14:00:27.361842    lock: released
/var/lock/sm/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/sr
[22578] 2012-04-05 14:00:27.362757    ***** vdi_create: EXCEPTION <class
'SR.SROSError'>, VDI Creation failed [opterr=error 127]
  File "/usr/lib/xcp/sm/SRCommand.py", line 94, in run
    return self._run_locked(sr)
  File "/usr/lib/xcp/sm/SRCommand.py", line 131, in _run_locked
    return self._run(sr, target)
  File "/usr/lib/xcp/sm/SRCommand.py", line 159, in _run
    return target.create(self.params['sr_uuid'], self.vdi_uuid,
long(self.params['args'][0]))
  File "/usr/lib/xcp/sm/FileSR.py", line 464, in create
    opterr='error %d' % inst.code)
  File "/usr/lib/xcp/sm/xs_errors.py", line 49, in __init__
    raise SR.SROSError(errorcode, errormessage)

[22578] 2012-04-05 14:00:27.363242    lock: closed
/var/lock/sm/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/sr






On 04/05/2012 01:08 PM, Jonathan Ludlam wrote:
> The log snippet doesn't have the detail in it - have a look in /var/log/SMlog - you might find something more useful in there.
>
> Jon
>
> On 5 Apr 2012, at 10:23, Dimitar Kazakov wrote:
>
>> Hi,
>> have permanent failure when try to create VDI on local SR type=file or
>> type=ext. On both types it failed with the same error:
>> SR_BACKEND_FAILURE_78
>> VDI Creation failed [opterr=error 127]
>>
>> I am on Debian box with kernel 3.3.0-rc7, Xen version 4.1.2 (Debian
>> 4.1.2-2.1), Xen-API Version: 1.3.2-4 (Kronos)
>>
>> Is it a bug, or am I missing something? Anybody managed to workaround
>> this problem?
>>
>>
>> Here is a short extract from xcp-xapi.log
>>
>> id=ba4e9e1a-bc42-0dc9-af0e-5db2905666ab type=user name-label=test
>> virtual-size=1GiB username=root password=null
>> [20120403T07:57:53.973Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
>> Session.create trackid=1ef3448b63e70822073569022044e96b pool=false
>> uname=root is_local_superuser=true auth_user_sid=
>> parent=trackid=9834f5af41c964e225f24279aefe4e49
>> [20120403T07:57:53.974Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
>> Attempting to open /var/lib/xcp/xapi
>> [20120403T07:57:53.975Z|debug|hyperion|547 UNIX
>> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
>> D:4cab7e7aa9ae created by task D:93575fa7333c
>> [20120403T07:57:53.982Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|audit] VDI.create: SR =
>> 'ba4e9e1a-bc42-0dc9-af0e-5db2905666ab (Local storage)'; name label = 'test'
>> [20120403T07:57:53.983Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Marking SR for
>> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
>> [20120403T07:57:53.984Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|storage_impl] VDI.create
>> task:OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a
>> sr:ba4e9e1a-bc42-0dc9-af0e-5db2905666ab vdi_info:{"vdi": "",
>> "name_label": "test", "name_description": "", "ty": "user",
>> "metadata_of_pool": "", "is_a_snapshot": false, "snapshot_time":
>> "19700101T00:00:00Z", "snapshot_of": "", "read_only": false,
>> "virtual_size": 1073741824, "physical_utilisation": 0} params:
>> [20120403T07:57:53.984Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dummytaskhelper] task
>> VDI.create D:db9f2e113fee created by task R:efdfb350d7ac
>> [20120403T07:57:53.986Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.create
>> trackid=654ed4437d52fe9cdd8e5d98a5955526 pool=false uname=
>> is_local_superuser=true auth_user_sid=
>> parent=trackid=9834f5af41c964e225f24279aefe4e49
>> [20120403T07:57:53.987Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Attempting to open
>> /var/lib/xcp/xapi
>> [20120403T07:57:53.987Z|debug|hyperion|548 UNIX
>> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
>> D:3829e36dbb97 created by task D:6ec167aaa83d
>> [20120403T07:57:54.066Z|debug|hyperion|549 UNIX
>> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:host.get_other_config
>> D:c813aaba73c4 created by task D:db9f2e113fee
>> [20120403T07:57:54.071Z|debug|hyperion|549 UNIX
>> /var/lib/xcp/xapi||http_critical] Premature termination of connection!
>> [20120403T07:57:54.109Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
>> sm_exec.ml:220.7-69 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.109Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.destroy
>> trackid=654ed4437d52fe9cdd8e5d98a5955526
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
>> pervasiveext.ml:26.22-25 -> server_helpers.ml:76.11-23
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Server_helpers.exec
>> exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI Creation
>> failed [opterr=error 127];  ]
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
>> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
>> pervasiveext.ml:26.22-25 -> sm.ml:132.25-98 ->
>> storage_access.ml:259.36-331 -> storage_access.ml:257.28-492 ->
>> server_helpers.ml:76.11-23
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher]
>> Server_helpers.exec exception_handler: Got exception
>> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
>> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> storage_access.ml:449.8-47 -> message_forwarding.ml:233.25-44 ->
>> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Unmarking SR after
>> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
>> [20120403T07:57:54.111Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
>> pervasiveext.ml:26.22-25 -> server.ml:24034.78-280 -> rbac.ml:229.16-23
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
>> rbac.ml:238.10-15 -> server_helpers.ml:79.11-41
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher]
>> Server_helpers.exec exception_handler: Got exception
>> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.114Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|backtrace] Raised
>> at pervasiveext.ml:26.22-25 -> server_helpers.ml:153.10-106 ->
>> server.ml:24035.19-190 -> server_helpers.ml:119.4-7
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||xapi]
>> Raised at client.ml:6.37-75 -> client.ml:9043.48-106 ->
>> cli_operations.ml:1082.11-187 -> xapi_cli.ml:112.18-56 ->
>> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.117Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|session.logout D:2d486a4a5b26|xapi] Session.destroy
>> trackid=1ef3448b63e70822073569022044e96b
>> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi||backtrace] Raised at pervasiveext.ml:26.22-25 ->
>> xapi_cli.ml:111.2-138 -> xapi_cli.ml:205.7-44 -> xapi_cli.ml:257.4-23
>> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
>> Xapi_cli.exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI
>> Creation failed [opterr=error 127];  ]
>> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
>> Raised at string.ml:150.25-34 -> stringext.ml:108.13-29
>>
>> Thanks,
>> Dimitar Kazkov
>> <the_kazak.vcf>_______________________________________________
>> xen-api mailing list
>> xen-api@lists.xen.org
>> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

--------------050905020305040603080804
Content-Type: text/x-vcard; charset=utf-8;
 name="the_kazak.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="the_kazak.vcf"

YmVnaW46dmNhcmQNCmZuOkRpbWl0YXIgS2F6YWtvdiAoa0B6QGspDQpuOkthemFrb3Y7RGlt
aXRhcg0Kb3JnOldlYlRvQ2xvdWQNCmFkcjo7OztWYXJuYTs7OTAwMDtCdWxnYXJpYQ0KZW1h
aWw7aW50ZXJuZXQ6dGhlLmthemFrQGdtYWlsLmNvbQ0KdGVsO2hvbWU6KzM1OSAoNTIpIDkx
MTExOQ0KdGVsO2NlbGw6KzM1OSAoODgpIDg1NTk5MDkNCngtbW96aWxsYS1odG1sOkZBTFNF
DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg==
--------------050905020305040603080804
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050905020305040603080804--


From xen-devel-bounces@lists.xen.org Thu Apr 05 12:23:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFliJ-0001Wl-VE; Thu, 05 Apr 2012 12:22:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <the.kazak@gmail.com>) id 1SFliJ-0001WW-7l
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:22:55 +0000
Received: from [85.158.143.35:57557] by server-3.bemta-4.messagelabs.com id
	A5/E0-05853-D9E8D7F4; Thu, 05 Apr 2012 12:22:53 +0000
X-Env-Sender: the.kazak@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333628570!14867578!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27095 invoked from network); 5 Apr 2012 12:22:51 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 12:22:51 -0000
Received: by bkcjg9 with SMTP id jg9so1460407bkc.32
	for <multiple recipients>; Thu, 05 Apr 2012 05:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=SroVNrVSLh/KUYGlpxkXsltsootHYK8/avmxzWEiGHM=;
	b=M5vvB+Z4gy13KHCST6Zfy+ONzCcp9j8tkl8qDW/RFs9g7/nPK7nwMh38MFbr+qXiP+
	78xSXyBK2gg0Ucl4+3/JrAAHkCTg+88WrG6IYYcqPzcmVH5skD1H3ngEMLFZnVLPlL0p
	mk9PRcD+oyQUGJJVfMC/T/Z+pvKKs5wTL1xb7xWohrfr9pAloXuWJdbnTkn6z71WmAkH
	en/oGmw/OyUZWoECHtH7290T9GMVixLS2DQjPQJgBWEbaUol3CO9+EEDzbPVOgMV9Bcu
	zD0Ih3OzMAVLqpXKspQikhEVKwG/TJmUM7O5PwE5g8WVS1J2tmhx3a839rHS4cuuHWpP
	igDg==
Received: by 10.204.132.72 with SMTP id a8mr1070276bkt.42.1333628569998;
	Thu, 05 Apr 2012 05:22:49 -0700 (PDT)
Received: from [212.50.0.54] (purple.varna.spnet.net. [212.50.0.54])
	by mx.google.com with ESMTPS id zx16sm8484731bkb.13.2012.04.05.05.22.47
	(version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 05:22:48 -0700 (PDT)
Message-ID: <4F7D8E96.1040808@gmail.com>
Date: Thu, 05 Apr 2012 15:22:46 +0300
From: Dimitar Kazakov <the.kazak@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: xen-api@lists.xen.org, xen-devel@lists.xen.org
References: <4F7D6480.6040704@gmail.com>
	<7549B613-6EB9-4DD8-9741-C0D8556D0176@eu.citrix.com>
In-Reply-To: <7549B613-6EB9-4DD8-9741-C0D8556D0176@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------050905020305040603080804"
Subject: Re: [Xen-devel] [Xen-API] (solved) xe vdi-create failure ot local
 SR type=file and type=ext
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a multi-part message in MIME format.
--------------050905020305040603080804
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Thanks!
I found the problem in SMlog.

/usr/sbin/td-util create vhd 1024
/var/run/sr-mount/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/247b64e4-6b7f-4b2f-bd73-50e848c78d71.vhd
/usr/sbin/td-util: error while loading shared libraries:
libxenctrl.so.4.0: cannot open shared object file: No such file or directory

td-util from blktap-utils 2.0.90-3 (testing) is looking for
libxenctrl.so.4.0, but the package libxen-4.1 4.1.2-2.1 (testing) offers
only  libxenctrl-4.1.so in /usr/lib.
Makeing a link libxenctrl.so.4.0 to libxenctrl-4.1.so in /usr/lib solves
the problem.

SMlog snippet:
[22578] 2012-04-05 14:00:27.322636    ['uuidgen', '-r']
[22578] 2012-04-05 14:00:27.329600    SUCCESS
[22578] 2012-04-05 14:00:27.336360    lock: acquired
/var/lock/sm/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/sr
[22578] 2012-04-05 14:00:27.336677    vdi_create {'sr_uuid':
'4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2', 'subtask_of':
'DummyRef:|7d48c27e-b70e-59eb-6197-51518053c92e|VDI.create', 'vdi_type':
'user', 'args': ['1073741824', 'test', '', '', 'false',
'19700101T00:00:00Z', '', 'false'], 'host_ref':
'OpaqueRef:e5783245-3c2c-df70-80c3-244d77ebc59f', 'session_ref':
'OpaqueRef:0c7299c1-981a-c1b5-f5b7-17a1a467518f', 'device_config':
{'device': '/dev/sdb1', 'SRmaster': 'true'}, 'command': 'vdi_create',
'sr_ref': 'OpaqueRef:ed43ec0a-3570-7535-cac9-d4a086f69d18',
'vdi_sm_config': {}}
[22578] 2012-04-05 14:00:27.337019    ['/usr/sbin/td-util', 'create',
'vhd', '1024',
'/var/run/sr-mount/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/247b64e4-6b7f-4b2f-bd73-50e848c78d71.vhd']
[22578] 2012-04-05 14:00:27.342837    FAILED: (rc 127) stdout: '',
stderr: '/usr/sbin/td-util: error while loading shared libraries:
libxenctrl.so.4.0: cannot open shared object file: No such file or directory
'
[22578] 2012-04-05 14:00:27.361494    Raising exception [78, VDI
Creation failed [opterr=error 127]]
[22578] 2012-04-05 14:00:27.361842    lock: released
/var/lock/sm/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/sr
[22578] 2012-04-05 14:00:27.362757    ***** vdi_create: EXCEPTION <class
'SR.SROSError'>, VDI Creation failed [opterr=error 127]
  File "/usr/lib/xcp/sm/SRCommand.py", line 94, in run
    return self._run_locked(sr)
  File "/usr/lib/xcp/sm/SRCommand.py", line 131, in _run_locked
    return self._run(sr, target)
  File "/usr/lib/xcp/sm/SRCommand.py", line 159, in _run
    return target.create(self.params['sr_uuid'], self.vdi_uuid,
long(self.params['args'][0]))
  File "/usr/lib/xcp/sm/FileSR.py", line 464, in create
    opterr='error %d' % inst.code)
  File "/usr/lib/xcp/sm/xs_errors.py", line 49, in __init__
    raise SR.SROSError(errorcode, errormessage)

[22578] 2012-04-05 14:00:27.363242    lock: closed
/var/lock/sm/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/sr






On 04/05/2012 01:08 PM, Jonathan Ludlam wrote:
> The log snippet doesn't have the detail in it - have a look in /var/log/SMlog - you might find something more useful in there.
>
> Jon
>
> On 5 Apr 2012, at 10:23, Dimitar Kazakov wrote:
>
>> Hi,
>> have permanent failure when try to create VDI on local SR type=file or
>> type=ext. On both types it failed with the same error:
>> SR_BACKEND_FAILURE_78
>> VDI Creation failed [opterr=error 127]
>>
>> I am on Debian box with kernel 3.3.0-rc7, Xen version 4.1.2 (Debian
>> 4.1.2-2.1), Xen-API Version: 1.3.2-4 (Kronos)
>>
>> Is it a bug, or am I missing something? Anybody managed to workaround
>> this problem?
>>
>>
>> Here is a short extract from xcp-xapi.log
>>
>> id=ba4e9e1a-bc42-0dc9-af0e-5db2905666ab type=user name-label=test
>> virtual-size=1GiB username=root password=null
>> [20120403T07:57:53.973Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
>> Session.create trackid=1ef3448b63e70822073569022044e96b pool=false
>> uname=root is_local_superuser=true auth_user_sid=
>> parent=trackid=9834f5af41c964e225f24279aefe4e49
>> [20120403T07:57:53.974Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|session.login_with_password D:93575fa7333c|xapi]
>> Attempting to open /var/lib/xcp/xapi
>> [20120403T07:57:53.975Z|debug|hyperion|547 UNIX
>> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
>> D:4cab7e7aa9ae created by task D:93575fa7333c
>> [20120403T07:57:53.982Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|audit] VDI.create: SR =
>> 'ba4e9e1a-bc42-0dc9-af0e-5db2905666ab (Local storage)'; name label = 'test'
>> [20120403T07:57:53.983Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Marking SR for
>> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
>> [20120403T07:57:53.984Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|storage_impl] VDI.create
>> task:OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a
>> sr:ba4e9e1a-bc42-0dc9-af0e-5db2905666ab vdi_info:{"vdi": "",
>> "name_label": "test", "name_description": "", "ty": "user",
>> "metadata_of_pool": "", "is_a_snapshot": false, "snapshot_time":
>> "19700101T00:00:00Z", "snapshot_of": "", "read_only": false,
>> "virtual_size": 1073741824, "physical_utilisation": 0} params:
>> [20120403T07:57:53.984Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dummytaskhelper] task
>> VDI.create D:db9f2e113fee created by task R:efdfb350d7ac
>> [20120403T07:57:53.986Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.create
>> trackid=654ed4437d52fe9cdd8e5d98a5955526 pool=false uname=
>> is_local_superuser=true auth_user_sid=
>> parent=trackid=9834f5af41c964e225f24279aefe4e49
>> [20120403T07:57:53.987Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Attempting to open
>> /var/lib/xcp/xapi
>> [20120403T07:57:53.987Z|debug|hyperion|548 UNIX
>> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.get_uuid
>> D:3829e36dbb97 created by task D:6ec167aaa83d
>> [20120403T07:57:54.066Z|debug|hyperion|549 UNIX
>> /var/lib/xcp/xapi||dummytaskhelper] task dispatch:host.get_other_config
>> D:c813aaba73c4 created by task D:db9f2e113fee
>> [20120403T07:57:54.071Z|debug|hyperion|549 UNIX
>> /var/lib/xcp/xapi||http_critical] Premature termination of connection!
>> [20120403T07:57:54.109Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
>> sm_exec.ml:220.7-69 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.109Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Session.destroy
>> trackid=654ed4437d52fe9cdd8e5d98a5955526
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
>> pervasiveext.ml:26.22-25 -> server_helpers.ml:76.11-23
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Server_helpers.exec
>> exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI Creation
>> failed [opterr=error 127];  ]
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|dispatcher] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|backtrace] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
>> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|sm_exec D:6ec167aaa83d|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
>> pervasiveext.ml:26.22-25 -> sm.ml:132.25-98 ->
>> storage_access.ml:259.36-331 -> storage_access.ml:257.28-492 ->
>> server_helpers.ml:76.11-23
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher]
>> Server_helpers.exec exception_handler: Got exception
>> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|dispatcher] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|backtrace] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
>> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create D:db9f2e113fee|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> storage_access.ml:449.8-47 -> message_forwarding.ml:233.25-44 ->
>> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.110Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Unmarking SR after
>> VDI.create (task=OpaqueRef:efdfb350-d7ac-c3e3-3a69-9c8e4d560f2a)
>> [20120403T07:57:54.111Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
>> pervasiveext.ml:26.22-25 -> server.ml:24034.78-280 -> rbac.ml:229.16-23
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
>> rbac.ml:238.10-15 -> server_helpers.ml:79.11-41
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher]
>> Server_helpers.exec exception_handler: Got exception
>> SR_BACKEND_FAILURE_78: [ ; VDI Creation failed [opterr=error 127];  ]
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|dispatcher] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.112Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|backtrace] Raised at
>> string.ml:150.25-34 -> stringext.ml:108.13-29
>> [20120403T07:57:54.114Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> server_helpers.ml:94.14-15 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|VDI.create R:efdfb350d7ac|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|xapi] Raised at
>> pervasiveext.ml:26.22-25 -> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi|dispatch:VDI.create D:f979b7f99455|backtrace] Raised
>> at pervasiveext.ml:26.22-25 -> server_helpers.ml:153.10-106 ->
>> server.ml:24035.19-190 -> server_helpers.ml:119.4-7
>> [20120403T07:57:54.115Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||xapi]
>> Raised at client.ml:6.37-75 -> client.ml:9043.48-106 ->
>> cli_operations.ml:1082.11-187 -> xapi_cli.ml:112.18-56 ->
>> pervasiveext.ml:22.2-9
>> [20120403T07:57:54.117Z| info|hyperion|546 UNIX
>> /var/lib/xcp/xapi|session.logout D:2d486a4a5b26|xapi] Session.destroy
>> trackid=1ef3448b63e70822073569022044e96b
>> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX
>> /var/lib/xcp/xapi||backtrace] Raised at pervasiveext.ml:26.22-25 ->
>> xapi_cli.ml:111.2-138 -> xapi_cli.ml:205.7-44 -> xapi_cli.ml:257.4-23
>> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
>> Xapi_cli.exception_handler: Got exception SR_BACKEND_FAILURE_78: [ ; VDI
>> Creation failed [opterr=error 127];  ]
>> [20120403T07:57:54.118Z|debug|hyperion|546 UNIX /var/lib/xcp/xapi||cli]
>> Raised at string.ml:150.25-34 -> stringext.ml:108.13-29
>>
>> Thanks,
>> Dimitar Kazkov
>> <the_kazak.vcf>_______________________________________________
>> xen-api mailing list
>> xen-api@lists.xen.org
>> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

--------------050905020305040603080804
Content-Type: text/x-vcard; charset=utf-8;
 name="the_kazak.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="the_kazak.vcf"

YmVnaW46dmNhcmQNCmZuOkRpbWl0YXIgS2F6YWtvdiAoa0B6QGspDQpuOkthemFrb3Y7RGlt
aXRhcg0Kb3JnOldlYlRvQ2xvdWQNCmFkcjo7OztWYXJuYTs7OTAwMDtCdWxnYXJpYQ0KZW1h
aWw7aW50ZXJuZXQ6dGhlLmthemFrQGdtYWlsLmNvbQ0KdGVsO2hvbWU6KzM1OSAoNTIpIDkx
MTExOQ0KdGVsO2NlbGw6KzM1OSAoODgpIDg1NTk5MDkNCngtbW96aWxsYS1odG1sOkZBTFNF
DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg==
--------------050905020305040603080804
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050905020305040603080804--


From xen-devel-bounces@lists.xen.org Thu Apr 05 12:43:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFm1a-0001nu-UB; Thu, 05 Apr 2012 12:42:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFm1Z-0001no-Oq
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 12:42:50 +0000
Received: from [85.158.143.99:64515] by server-1.bemta-4.messagelabs.com id
	80/0D-20925-8439D7F4; Thu, 05 Apr 2012 12:42:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333629766!12848746!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21215 invoked from network); 5 Apr 2012 12:42:47 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Apr 2012 12:42:47 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFm1W-0005Lt-2Y
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 05:42:46 -0700
Date: Thu, 5 Apr 2012 05:42:46 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333629766072-5620280.post@n5.nabble.com>
In-Reply-To: <1333377715290-5612666.post@n5.nabble.com>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
	<alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
	<1333377715290-5612666.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Stefano Stabellini-3 wrote
>> 
>> On Mon, 2 Apr 2012, Fantu wrote:
>>> Fantu wrote
>>> > 
>>> > 
>>> > Fantu wrote
>>> >> 
>>> >> For many years we used virtualization systems based on xen.
>>> >> Up to now we did quite well despite same issue we are trying to solve
>>> >> with the new version.
>>> >> The main issue that we found are about Windows domU performance and
>>> the
>>> >> thin client interface with rdp is sometimes problematic.
>>> >> We think a possible solution to solve current shortcomings could be
>>> qemu
>>> >> upstream with spice, qxl and USB redirection.
>>> >> We have started preparing a new test system based on Wheezy, the
>>> upstream
>>> >> kernel and xen 4.2.
>>> >> The current test system is:
>>> >> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64
>>> version
>>> >> 3.2.12-1, package blktap-dkms and all dependency packages for xen
>>> spice
>>> >> and usb redirection.
>>> >> -------------------------
>>> >> /etc/modules
>>> >> ------------
>>> >> loop max_loop=64
>>> >> xenfs
>>> >> xen-evtchn
>>> >> blktap
>>> >> -------------------------
>>> >> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
>>> >> 25070)
>>> >> vi Makefile # removed dist-kernel to not compile kernel
>>> >> -------------------------
>>> >> vi Config.mk # qemu upstream unstable and seabios unstable
>>> >> ------------
>>> >> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
>>> >> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
>>> >> SEABIOS_UPSTREAM_TAG ?= master
>>> >> QEMU_TAG ?= master
>>> >> -------------------------
>>> >> Added some patches:
>>> >> - autoconf: add variable for pass arbitrary options to qemu upstream
>>> - my
>>> >> patch to build spice and usbredirection on qemu upstream
>>> >> - QEMU upstream need to kown the amount of RAM given to a guest. This
>>> >> patch give
>>> >> the correct value. - Anthony PERARD patch for try to solve
>>> ram/videoram
>>> >> issue
>>> >> - tools: specify datadir for qemu-xen build to fix firmware loading -
>>> >> Olaf Hering patch for try to solve qxl issue
>>> >> -------------------------
>>> >> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
>>> >> -------------------------
>>> >> vi config/Tools.mk # workaround for libxl compilation problem
>>> >> BISON               := bison
>>> >> FLEX                := flex
>>> >> -------------------------
>>> >> make dist
>>> >> ./install.sh
>>> >> insserv xencommons &&
>>> >> insserv xendomains
>>> >> 
>>> >> 
>>> >> Result:
>>> >> Full PV domU work, just minimal tests done.
>>> >> HVM domU with qemu traditional works but with qemu upstream some
>>> problem
>>> >> encountered.
>>> >> For now I didn't find a way to make Windows run on qemu upstream and
>>> >> nothing on logs.
>>> >> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
>>> >> Spice and usbrediction seem to be working in basic test done now, qxl
>>> >> not.
>>> >> 
>>> >> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on
>>> start,
>>> >> with qemu unstable it starts but with an allocation problem, on xorg
>>> log:
>>> >> Out of video memory: Could not allocate 4198400 bytes
>>> >> I tried to update also seabios to unstable but same problem.
>>> >> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
>>> >> 
>>> >> Current xl domU configuration file:
>>> >> -----------------------------------
>>> >> name='PRECISEHVM'
>>> >> builder="hvm"
>>> >> memory=1024
>>> >> #maxmem=1536
>>> >> vcpus=2
>>> >> #hap=1
>>> >> #pae=1
>>> >> #acpi=1
>>> >> #apic=1
>>> >> #nx=1
>>> >> vif=['bridge=xenbr0']
>>> >> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
>>> >> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
>>> >> '/dev/sr0,raw,hdb,ro,cdrom']
>>> >> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
>>> >> boot='c'
>>> >> xen_platform_pci=1
>>> >> device_model_version='qemu-xen'
>>> >> vnc=0
>>> >> #vncunused=1
>>> >> #vnclisten="0.0.0.0"
>>> >> #keymap="it"
>>> >> #stdvga=1
>>> >> #sdl=0
>>> >> spice=1
>>> >> spicehost='0.0.0.0'
>>> >> spiceport=6000
>>> >> spicedisable_ticketing=1
>>> >> #spicepasswd='test'
>>> >> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>>> >> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
>>> >> device_model_args=["-vga qxl"]
>>> >> #device_model_args=["-usb -device usb-ehci"]
>>> >> #on_crash='preserve'
>>> >> videoram=128
>>> >> #bios="ovmf"
>>> >> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
>>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
>>> >>
>>> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
>>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
>>> >>
>>> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
>>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
>>> >>
>>> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
>>> >> -----------------------------------
>>> >> 
>>> >> Can someone help to solve these issues?
>>> >> Thanks for any reply.
>>> >> 
>>> > Today I have done other tests: windows xp sp3 installs and runs
>>> > successfully on qemu upstream unstable.
>>> > Vnc working but too slow, with stdvga improved but not optimal.
>>> > Spice with qxl is working but with slow graphic performance. It seems
>>> to
>>> > have only 4 mb videoram usable (seem to be same with Precise, see
>>> quote).
>>> > 
>>> > This is the current xl configuration:
>>> > -------------------------------------
>>> > name='XP'
>>> > builder="hvm"
>>> > memory=1024
>>> > vcpus=2
>>> > hap=1
>>> > pae=1
>>> > acpi=1
>>> > apic=1
>>> > nx=1
>>> > vif=['bridge=xenbr0']
>>> > #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>>> > disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>>> > boot='d'
>>> > xen_platform_pci=1
>>> > viridian=1
>>> > device_model_version="qemu-xen"
>>> > device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>>> > vnc=0
>>> > #vncunused=1
>>> > #vnclisten="0.0.0.0"
>>> > #keymap="it"
>>> > spice=1
>>> > spicehost="0.0.0.0"
>>> > spiceport=6000
>>> > spicedisable_ticketing=1
>>> > on_poweroff="destroy"
>>> > on_reboot="restart"
>>> > on_crash="destroy"
>>> > stdvga=0
>>> > device_model_args=["-vga qxl"]
>>> > videoram=128
>>> > -------------------------------------
>>> > 
>>> Also Windows 7 is working with qemu upstream, with patches and
>>> workaround
>>> applied probably, for details see the first post.
>> 
>> Thank you very much for testing!
>> Would you be up for writing a wiki.xen.org page about how to use SPICE
>> with Xen?
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
>> 
> Thanks for reply.
> About Spice I can't do advanced use and test without before solve videoram
> limit to 4 MB problem :(
> Can you help about please?
> QXL vga can be used also without Spice and could be very useful in solving
> the problem of current graphic performances.
> 
If on xl create "xc: info: VIRTUAL MEMORY ARRANGEMENT:" TOTAL include
videoram I probably found the problem.
With the same domU configuration, without videoram:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
With videoram=128:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->0000000038000000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001bf
  1GB PAGES: 0x0000000000000000

There is something wrong on hvmloader?
I hope that this information is helpful in solving the problem, if you need
more information ask.


--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5620280.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:43:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFm1a-0001nu-UB; Thu, 05 Apr 2012 12:42:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFm1Z-0001no-Oq
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 12:42:50 +0000
Received: from [85.158.143.99:64515] by server-1.bemta-4.messagelabs.com id
	80/0D-20925-8439D7F4; Thu, 05 Apr 2012 12:42:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333629766!12848746!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21215 invoked from network); 5 Apr 2012 12:42:47 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Apr 2012 12:42:47 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SFm1W-0005Lt-2Y
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 05:42:46 -0700
Date: Thu, 5 Apr 2012 05:42:46 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333629766072-5620280.post@n5.nabble.com>
In-Reply-To: <1333377715290-5612666.post@n5.nabble.com>
References: <1333017197787-5603330.post@n5.nabble.com>
	<1333120091665-5606945.post@n5.nabble.com>
	<1333366503074-5612226.post@n5.nabble.com>
	<alpine.DEB.2.00.1204021525390.15151@kaball-desktop>
	<1333377715290-5612666.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Problems with xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Stefano Stabellini-3 wrote
>> 
>> On Mon, 2 Apr 2012, Fantu wrote:
>>> Fantu wrote
>>> > 
>>> > 
>>> > Fantu wrote
>>> >> 
>>> >> For many years we used virtualization systems based on xen.
>>> >> Up to now we did quite well despite same issue we are trying to solve
>>> >> with the new version.
>>> >> The main issue that we found are about Windows domU performance and
>>> the
>>> >> thin client interface with rdp is sometimes problematic.
>>> >> We think a possible solution to solve current shortcomings could be
>>> qemu
>>> >> upstream with spice, qxl and USB redirection.
>>> >> We have started preparing a new test system based on Wheezy, the
>>> upstream
>>> >> kernel and xen 4.2.
>>> >> The current test system is:
>>> >> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64
>>> version
>>> >> 3.2.12-1, package blktap-dkms and all dependency packages for xen
>>> spice
>>> >> and usb redirection.
>>> >> -------------------------
>>> >> /etc/modules
>>> >> ------------
>>> >> loop max_loop=64
>>> >> xenfs
>>> >> xen-evtchn
>>> >> blktap
>>> >> -------------------------
>>> >> hg clone http://xenbits.xen.org/xen-unstable.hg (last build changeset
>>> >> 25070)
>>> >> vi Makefile # removed dist-kernel to not compile kernel
>>> >> -------------------------
>>> >> vi Config.mk # qemu upstream unstable and seabios unstable
>>> >> ------------
>>> >> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
>>> >> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
>>> >> SEABIOS_UPSTREAM_TAG ?= master
>>> >> QEMU_TAG ?= master
>>> >> -------------------------
>>> >> Added some patches:
>>> >> - autoconf: add variable for pass arbitrary options to qemu upstream
>>> - my
>>> >> patch to build spice and usbredirection on qemu upstream
>>> >> - QEMU upstream need to kown the amount of RAM given to a guest. This
>>> >> patch give
>>> >> the correct value. - Anthony PERARD patch for try to solve
>>> ram/videoram
>>> >> issue
>>> >> - tools: specify datadir for qemu-xen build to fix firmware loading -
>>> >> Olaf Hering patch for try to solve qxl issue
>>> >> -------------------------
>>> >> ./configure QEMUU_ADD_PAR="--enable-spice --enable-usb-redir"
>>> >> -------------------------
>>> >> vi config/Tools.mk # workaround for libxl compilation problem
>>> >> BISON               := bison
>>> >> FLEX                := flex
>>> >> -------------------------
>>> >> make dist
>>> >> ./install.sh
>>> >> insserv xencommons &&
>>> >> insserv xendomains
>>> >> 
>>> >> 
>>> >> Result:
>>> >> Full PV domU work, just minimal tests done.
>>> >> HVM domU with qemu traditional works but with qemu upstream some
>>> problem
>>> >> encountered.
>>> >> For now I didn't find a way to make Windows run on qemu upstream and
>>> >> nothing on logs.
>>> >> About Linux domU HVM I tried with Precise (Ubuntu 12.04 LTS).
>>> >> Spice and usbrediction seem to be working in basic test done now, qxl
>>> >> not.
>>> >> 
>>> >> About qxl vga with qemu from xen repository (1.0.1) qemu hangs on
>>> start,
>>> >> with qemu unstable it starts but with an allocation problem, on xorg
>>> log:
>>> >> Out of video memory: Could not allocate 4198400 bytes
>>> >> I tried to update also seabios to unstable but same problem.
>>> >> Is the patch incomplete or is there videoram fixed limit to 4 MB? 
>>> >> 
>>> >> Current xl domU configuration file:
>>> >> -----------------------------------
>>> >> name='PRECISEHVM'
>>> >> builder="hvm"
>>> >> memory=1024
>>> >> #maxmem=1536
>>> >> vcpus=2
>>> >> #hap=1
>>> >> #pae=1
>>> >> #acpi=1
>>> >> #apic=1
>>> >> #nx=1
>>> >> vif=['bridge=xenbr0']
>>> >> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
>>> >> #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
>>> >> '/dev/sr0,raw,hdb,ro,cdrom']
>>> >> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw']
>>> >> boot='c'
>>> >> xen_platform_pci=1
>>> >> device_model_version='qemu-xen'
>>> >> vnc=0
>>> >> #vncunused=1
>>> >> #vnclisten="0.0.0.0"
>>> >> #keymap="it"
>>> >> #stdvga=1
>>> >> #sdl=0
>>> >> spice=1
>>> >> spicehost='0.0.0.0'
>>> >> spiceport=6000
>>> >> spicedisable_ticketing=1
>>> >> #spicepasswd='test'
>>> >> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>>> >> #device_model_args=["-vga qxl -global qxl-vga.vram_size=33554432"]
>>> >> device_model_args=["-vga qxl"]
>>> >> #device_model_args=["-usb -device usb-ehci"]
>>> >> #on_crash='preserve'
>>> >> videoram=128
>>> >> #bios="ovmf"
>>> >> #device_model_args=["-readconfig /etc/xen/ich9-ehci-uhci.cfg",
>>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device
>>> >>
>>> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3",
>>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev2 -device
>>> >>
>>> usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3",
>>> >>         "-chardev spicevmc,name=usbredir,id=usbredirchardev3 -device
>>> >>
>>> usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"]
>>> >> -----------------------------------
>>> >> 
>>> >> Can someone help to solve these issues?
>>> >> Thanks for any reply.
>>> >> 
>>> > Today I have done other tests: windows xp sp3 installs and runs
>>> > successfully on qemu upstream unstable.
>>> > Vnc working but too slow, with stdvga improved but not optimal.
>>> > Spice with qxl is working but with slow graphic performance. It seems
>>> to
>>> > have only 4 mb videoram usable (seem to be same with Precise, see
>>> quote).
>>> > 
>>> > This is the current xl configuration:
>>> > -------------------------------------
>>> > name='XP'
>>> > builder="hvm"
>>> > memory=1024
>>> > vcpus=2
>>> > hap=1
>>> > pae=1
>>> > acpi=1
>>> > apic=1
>>> > nx=1
>>> > vif=['bridge=xenbr0']
>>> > #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>>> > disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>>> > boot='d'
>>> > xen_platform_pci=1
>>> > viridian=1
>>> > device_model_version="qemu-xen"
>>> > device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>>> > vnc=0
>>> > #vncunused=1
>>> > #vnclisten="0.0.0.0"
>>> > #keymap="it"
>>> > spice=1
>>> > spicehost="0.0.0.0"
>>> > spiceport=6000
>>> > spicedisable_ticketing=1
>>> > on_poweroff="destroy"
>>> > on_reboot="restart"
>>> > on_crash="destroy"
>>> > stdvga=0
>>> > device_model_args=["-vga qxl"]
>>> > videoram=128
>>> > -------------------------------------
>>> > 
>>> Also Windows 7 is working with qemu upstream, with patches and
>>> workaround
>>> applied probably, for details see the first post.
>> 
>> Thank you very much for testing!
>> Would you be up for writing a wiki.xen.org page about how to use SPICE
>> with Xen?
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
>> 
> Thanks for reply.
> About Spice I can't do advanced use and test without before solve videoram
> limit to 4 MB problem :(
> Can you help about please?
> QXL vga can be used also without Spice and could be very useful in solving
> the problem of current graphic performances.
> 
If on xl create "xc: info: VIRTUAL MEMORY ARRANGEMENT:" TOTAL include
videoram I probably found the problem.
With the same domU configuration, without videoram:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
With videoram=128:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->0000000038000000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001bf
  1GB PAGES: 0x0000000000000000

There is something wrong on hvmloader?
I hope that this information is helpful in solving the problem, if you need
more information ask.


--
View this message in context: http://xen.1045712.n5.nabble.com/Problems-with-xen-4-2-tp5603330p5620280.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:54:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmCY-0001zd-3u; Thu, 05 Apr 2012 12:54:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFmCW-0001zY-KC
	for Xen-devel@lists.xensource.com; Thu, 05 Apr 2012 12:54:08 +0000
Received: from [193.109.254.147:3805] by server-1.bemta-14.messagelabs.com id
	B6/FC-29372-FE59D7F4; Thu, 05 Apr 2012 12:54:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333630445!3397706!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NDI1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6823 invoked from network); 5 Apr 2012 12:54:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 12:54:07 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q35Cqskt001088
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 12:52:55 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q35Cqqbu013938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 12:52:53 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q35CqpGm011150; Thu, 5 Apr 2012 07:52:51 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Apr 2012 05:52:51 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 512AB40328; Thu,  5 Apr 2012 08:48:13 -0400 (EDT)
Date: Thu, 5 Apr 2012 08:48:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120405124813.GA1854@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
	<alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
	<20120326135349.GB18285@phenom.dumpdata.com>
	<alpine.DEB.2.00.1203272306370.1410@vega-a.dur.ac.uk>
	<20120328162040.GA5711@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F7D95AA.004A,ss=1,re=0.000,fgs=0
Cc: xen@lists.fedoraproject.org,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Fedora Core 17 Xorg can't use /dev/fb0 when using
 Cirrus Logic VGA or Xen PVFB driver,
 Was:Re:  irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 05, 2012 at 01:11:57AM +0100, M A Young wrote:
> On Wed, 28 Mar 2012, Konrad Rzeszutek Wilk wrote:
> 
> >So with extra="console=hvc0 loglevel=8 root=live:http://build/tftpboot/f17-i386/LiveOS/squashfs.img"
> >
> >I was able to succesfully install, but booting proved interestingly.
> >
> >When trying the 'pygrub' it would complain about the 'No OS loader', but if I ran
> >it on the disk (pygrub /dev/vg_guest/f17_32) it would extract the payload properly.
> >(This is with xen-4.1.2-6.fc16). So I worked around by taking those images
> >directly:
> >
> >kernel="/var/run/xend/boot/boot_kernel.jIsJmr"
> >ramdisk="/var/run/xend/boot/boot_ramdisk.I4rBjo"
> >extra="root=/dev/mapper/vg_f17-lv_root ro rd.md=0 rd.lvm.lv=vg_f17/lv_swap SYSFONT=True  KEYTABLE=us rd.lvm.lv=vg_f17/lv_root rd.luks=0 LANG=en_US.UTF-8 rd.dm=0"
> 
> pygrub works for me via xl. It may be a result of how you are
> booting the guest.
> 
> >And when booting F17 either as HVM or PV, in both cases I got Xorg to
> >tell me:
> >
> >(EE) FBDEV(0): FBIOBLANK: Invalid argument
> >
> >and freeze.
> 
> That seems to be harmless. However I do get the "an error has
> occurred" message instead of the gdm login screen though until I
> removed the fprintd package (and the dependent fprintd-pam package).

Oh, that fixed it! How did you find out that piece of the puzzle?

> 
> 	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:54:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmCY-0001zd-3u; Thu, 05 Apr 2012 12:54:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFmCW-0001zY-KC
	for Xen-devel@lists.xensource.com; Thu, 05 Apr 2012 12:54:08 +0000
Received: from [193.109.254.147:3805] by server-1.bemta-14.messagelabs.com id
	B6/FC-29372-FE59D7F4; Thu, 05 Apr 2012 12:54:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333630445!3397706!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NDI1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6823 invoked from network); 5 Apr 2012 12:54:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 12:54:07 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q35Cqskt001088
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 12:52:55 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q35Cqqbu013938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 12:52:53 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q35CqpGm011150; Thu, 5 Apr 2012 07:52:51 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Apr 2012 05:52:51 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 512AB40328; Thu,  5 Apr 2012 08:48:13 -0400 (EDT)
Date: Thu, 5 Apr 2012 08:48:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120405124813.GA1854@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
	<alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
	<20120326135349.GB18285@phenom.dumpdata.com>
	<alpine.DEB.2.00.1203272306370.1410@vega-a.dur.ac.uk>
	<20120328162040.GA5711@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F7D95AA.004A,ss=1,re=0.000,fgs=0
Cc: xen@lists.fedoraproject.org,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Fedora Core 17 Xorg can't use /dev/fb0 when using
 Cirrus Logic VGA or Xen PVFB driver,
 Was:Re:  irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 05, 2012 at 01:11:57AM +0100, M A Young wrote:
> On Wed, 28 Mar 2012, Konrad Rzeszutek Wilk wrote:
> 
> >So with extra="console=hvc0 loglevel=8 root=live:http://build/tftpboot/f17-i386/LiveOS/squashfs.img"
> >
> >I was able to succesfully install, but booting proved interestingly.
> >
> >When trying the 'pygrub' it would complain about the 'No OS loader', but if I ran
> >it on the disk (pygrub /dev/vg_guest/f17_32) it would extract the payload properly.
> >(This is with xen-4.1.2-6.fc16). So I worked around by taking those images
> >directly:
> >
> >kernel="/var/run/xend/boot/boot_kernel.jIsJmr"
> >ramdisk="/var/run/xend/boot/boot_ramdisk.I4rBjo"
> >extra="root=/dev/mapper/vg_f17-lv_root ro rd.md=0 rd.lvm.lv=vg_f17/lv_swap SYSFONT=True  KEYTABLE=us rd.lvm.lv=vg_f17/lv_root rd.luks=0 LANG=en_US.UTF-8 rd.dm=0"
> 
> pygrub works for me via xl. It may be a result of how you are
> booting the guest.
> 
> >And when booting F17 either as HVM or PV, in both cases I got Xorg to
> >tell me:
> >
> >(EE) FBDEV(0): FBIOBLANK: Invalid argument
> >
> >and freeze.
> 
> That seems to be harmless. However I do get the "an error has
> occurred" message instead of the gdm login screen though until I
> removed the fprintd package (and the dependent fprintd-pam package).

Oh, that fixed it! How did you find out that piece of the puzzle?

> 
> 	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:56:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:56:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmEF-00023h-Jc; Thu, 05 Apr 2012 12:55:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFmEE-00023c-Sc
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:55:55 +0000
Received: from [85.158.138.51:33063] by server-11.bemta-3.messagelabs.com id
	04/77-28543-A569D7F4; Thu, 05 Apr 2012 12:55:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333630551!20932321!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDU4NzUy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3685 invoked from network); 5 Apr 2012 12:55:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 12:55:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q35CtiKv015100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 12:55:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q35CthJs018274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 12:55:44 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q35CthsP002442; Thu, 5 Apr 2012 07:55:43 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Apr 2012 05:55:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5C50A40328; Thu,  5 Apr 2012 08:51:05 -0400 (EDT)
Date: Thu, 5 Apr 2012 08:51:05 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120405125105.GB1854@phenom.dumpdata.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F7D9652.0016,ss=1,re=0.000,fgs=0
Cc: Stefan Bader <stefan.bader@canonical.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 05, 2012 at 12:02:45PM +0100, Stefano Stabellini wrote:
> On Wed, 4 Apr 2012, Stefan Bader wrote:
> > Hi Stefano,
> > 
> > quite a while back in time, you and Konrad had a discussion about some HVM setup
> > problems via libvirt. One part was graphics and the problem seemed to be that
> > when creating a new instance through xend for HVM, the use of vfb was wrong. It
> > mostly does work but then also defines a vkbd which takes a long time in the
> > xenbus setup to finally fail.
> > 
> > Because this was not a really fatal problem it did take a long time to actually
> > get back to it. But now I had a look and found that libvirt indeed does use the
> > vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> > create guests). The decision is made based on the xend version number in the HVM
> > case. Which would be wrong if I did understand your reply correctly.
> > 
> > I have been testing a patch to libvirt, which would not use a vfb definition
> > whenever HVM is used (regardless of xend version). And it does seem to work (xm
> > list -l however has a vfb device definition, but the same happens when creating
> > the instance with a xm style config file that definitely has no vfb section in
> > it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> > to make sure the solution for libvirt is correct for even the current Xen version.
> > 
> > So in short, is this always correct?
> > 
> > if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
> >    do not define a vfb device
> > else /* PVM and xend version >= 3 */
> >    define a vfb device
> 
> vkbd and vfb can be considered optimizations for PV on HVM guests.
> No PV on HVM guest that I know should be able to use vfb right now, but
> Linux should be able to use vkbd since:
> 
> commit 5f098ecd4288333d87e2293239fab1c13ec90dae
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Mon Jul 4 19:22:00 2011 -0700
> 
>     Input: xen-kbdfront - enable driver for HVM guests
>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> 
> XL in xen-unstable enables vkbd for HVM guests so that you can have
> keyboard and mouse without usb emulation (that eats significant
> resources in dom0).
> 
> That said, vkbd is just a (small) optimization, it is far more
> important to get rid of the very annoying wait time at bootup.
> Rather than messing with libvirt and xend I would fix it from the Linux
> side, see the following thread:
> 
> http://marc.info/?l=xen-devel&m=133238564132683&w=2
> 
> I think that the right thing to do would be removing the additional wait
> time for vfb and vkbd devices in the PV on HVM case. We don't want to
> completely remove vfb and vkbd support for PV on HVM guests though.
> 
> Konrad, do you agree with the last reply I sent? Do you think you can

Yes.
> come up with a patch? Maybe separating non-essential from essential

Yes. I was going to after wresting with the dom0_mem=X patches.

> devices to have two wait loops is not feasible?

It should be no trouble.

> In any case, given the current state of affairs, the first patch in the
> thread from Konrad is still better than nothing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:56:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:56:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmEF-00023h-Jc; Thu, 05 Apr 2012 12:55:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFmEE-00023c-Sc
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:55:55 +0000
Received: from [85.158.138.51:33063] by server-11.bemta-3.messagelabs.com id
	04/77-28543-A569D7F4; Thu, 05 Apr 2012 12:55:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333630551!20932321!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDU4NzUy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3685 invoked from network); 5 Apr 2012 12:55:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 12:55:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q35CtiKv015100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 12:55:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q35CthJs018274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 12:55:44 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q35CthsP002442; Thu, 5 Apr 2012 07:55:43 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Apr 2012 05:55:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5C50A40328; Thu,  5 Apr 2012 08:51:05 -0400 (EDT)
Date: Thu, 5 Apr 2012 08:51:05 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120405125105.GB1854@phenom.dumpdata.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F7D9652.0016,ss=1,re=0.000,fgs=0
Cc: Stefan Bader <stefan.bader@canonical.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 05, 2012 at 12:02:45PM +0100, Stefano Stabellini wrote:
> On Wed, 4 Apr 2012, Stefan Bader wrote:
> > Hi Stefano,
> > 
> > quite a while back in time, you and Konrad had a discussion about some HVM setup
> > problems via libvirt. One part was graphics and the problem seemed to be that
> > when creating a new instance through xend for HVM, the use of vfb was wrong. It
> > mostly does work but then also defines a vkbd which takes a long time in the
> > xenbus setup to finally fail.
> > 
> > Because this was not a really fatal problem it did take a long time to actually
> > get back to it. But now I had a look and found that libvirt indeed does use the
> > vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> > create guests). The decision is made based on the xend version number in the HVM
> > case. Which would be wrong if I did understand your reply correctly.
> > 
> > I have been testing a patch to libvirt, which would not use a vfb definition
> > whenever HVM is used (regardless of xend version). And it does seem to work (xm
> > list -l however has a vfb device definition, but the same happens when creating
> > the instance with a xm style config file that definitely has no vfb section in
> > it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> > to make sure the solution for libvirt is correct for even the current Xen version.
> > 
> > So in short, is this always correct?
> > 
> > if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
> >    do not define a vfb device
> > else /* PVM and xend version >= 3 */
> >    define a vfb device
> 
> vkbd and vfb can be considered optimizations for PV on HVM guests.
> No PV on HVM guest that I know should be able to use vfb right now, but
> Linux should be able to use vkbd since:
> 
> commit 5f098ecd4288333d87e2293239fab1c13ec90dae
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Mon Jul 4 19:22:00 2011 -0700
> 
>     Input: xen-kbdfront - enable driver for HVM guests
>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> 
> XL in xen-unstable enables vkbd for HVM guests so that you can have
> keyboard and mouse without usb emulation (that eats significant
> resources in dom0).
> 
> That said, vkbd is just a (small) optimization, it is far more
> important to get rid of the very annoying wait time at bootup.
> Rather than messing with libvirt and xend I would fix it from the Linux
> side, see the following thread:
> 
> http://marc.info/?l=xen-devel&m=133238564132683&w=2
> 
> I think that the right thing to do would be removing the additional wait
> time for vfb and vkbd devices in the PV on HVM case. We don't want to
> completely remove vfb and vkbd support for PV on HVM guests though.
> 
> Konrad, do you agree with the last reply I sent? Do you think you can

Yes.
> come up with a patch? Maybe separating non-essential from essential

Yes. I was going to after wresting with the dom0_mem=X patches.

> devices to have two wait loops is not feasible?

It should be no trouble.

> In any case, given the current state of affairs, the first patch in the
> thread from Konrad is still better than nothing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 12:56:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmET-00024p-W1; Thu, 05 Apr 2012 12:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFmES-00024c-UH
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:56:09 +0000
Received: from [85.158.138.51:11227] by server-10.bemta-3.messagelabs.com id
	52/2B-15637-8669D7F4; Thu, 05 Apr 2012 12:56:08 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333630566!16751906!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22023 invoked from network); 5 Apr 2012 12:56:06 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 12:56:06 -0000
Received: from p5b2e2631.dip.t-dialin.net ([91.46.38.49] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFmEP-0000eH-U0; Thu, 05 Apr 2012 12:56:06 +0000
Message-ID: <4F7D9664.8080406@canonical.com>
Date: Thu, 05 Apr 2012 14:56:04 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0082248401099379230=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0082248401099379230==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig87163D122552A0693E0564C0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig87163D122552A0693E0564C0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 05.04.2012 13:02, Stefano Stabellini wrote:
> On Wed, 4 Apr 2012, Stefan Bader wrote:
>> Hi Stefano,
>>
>> quite a while back in time, you and Konrad had a discussion about some=
 HVM setup
>> problems via libvirt. One part was graphics and the problem seemed to =
be that
>> when creating a new instance through xend for HVM, the use of vfb was =
wrong. It
>> mostly does work but then also defines a vkbd which takes a long time =
in the
>> xenbus setup to finally fail.
>>
>> Because this was not a really fatal problem it did take a long time to=
 actually
>> get back to it. But now I had a look and found that libvirt indeed doe=
s use the
>> vfb form for both the xen-xm and xen-sxpr formats (the latter being us=
ed to
>> create guests). The decision is made based on the xend version number =
in the HVM
>> case. Which would be wrong if I did understand your reply correctly.
>>
>> I have been testing a patch to libvirt, which would not use a vfb defi=
nition
>> whenever HVM is used (regardless of xend version). And it does seem to=
 work (xm
>> list -l however has a vfb device definition, but the same happens when=
 creating
>> the instance with a xm style config file that definitely has no vfb se=
ction in
>> it). But I am testing based on our 12.04 release which uses Xen 4.1.2.=
 So I want
>> to make sure the solution for libvirt is correct for even the current =
Xen version.
>>
>> So in short, is this always correct?
>>
>> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>>    do not define a vfb device
>> else /* PVM and xend version >=3D 3 */
>>    define a vfb device
>=20
> vkbd and vfb can be considered optimizations for PV on HVM guests.
> No PV on HVM guest that I know should be able to use vfb right now, but=

> Linux should be able to use vkbd since:
>=20
> commit 5f098ecd4288333d87e2293239fab1c13ec90dae
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Mon Jul 4 19:22:00 2011 -0700
>=20
>     Input: xen-kbdfront - enable driver for HVM guests
>    =20
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com=
>
>     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>=20
> XL in xen-unstable enables vkbd for HVM guests so that you can have
> keyboard and mouse without usb emulation (that eats significant
> resources in dom0).
>=20
> That said, vkbd is just a (small) optimization, it is far more
> important to get rid of the very annoying wait time at bootup.
> Rather than messing with libvirt and xend I would fix it from the Linux=

> side, see the following thread:
>=20
> http://marc.info/?l=3Dxen-devel&m=3D133238564132683&w=3D2

That would work as well. The downside being that this modification then h=
as to
go in any kernels between 3.1 and the patch. The approach from the other =
side
seemed to make sense so far as it changes generated output that seems tar=
geted
only at talking to xend. The xen-xm format looks to be usable for xl too.=
 But I
would suspect that whenever libvirt starts to support xen api/xl/libxen i=
t will
be using a different interface which then could make use of vfb and vkbd.=


Of course that does not make the change in the kernel less valuable. It p=
revents
the wait time whenever someone manually configures things with vfb.
It just seems to be useless to generate a config that has no use for an
interface that does not support it.

Stefan

> I think that the right thing to do would be removing the additional wai=
t
> time for vfb and vkbd devices in the PV on HVM case. We don't want to
> completely remove vfb and vkbd support for PV on HVM guests though.
>=20
> Konrad, do you agree with the last reply I sent? Do you think you can
> come up with a patch? Maybe separating non-essential from essential
> devices to have two wait loops is not feasible?
> In any case, given the current state of affairs, the first patch in the=

> thread from Konrad is still better than nothing.



--------------enig87163D122552A0693E0564C0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfZZkAAoJEOhnXe7L7s6jEiUQAJLO5rpRCYErn29avM0Us3bJ
CcMb3ARqCqMWoLCGaH/VJ+RWBod84cZE8zNzW1MGH11I0zn6itVWd0IGQJ1BTWGr
sMuFR4iy0Z9cVyFxsZZtL+/2ksDOuhG0zOC95uhQGYGUDRIcgX6Uy+8RD/q6YoXI
BSrDLDA5Tl7QXqI8jlF1dq62HlzeId2e4S9RVrlxf1L4ChL+4FJHslxXaWfJ7Nb/
KlNoTjdyywGiC9KP/dW5Np5oY8xds8oPqVx1EsqOV/VMRT28UndqRqO9oI68xTgY
kVCCyutE8d2eqXH5mu6FdvLS1o8uDiDtNMnUimZlfuXh9QECObMvj03nNDwn6AWX
FBUOHazxdY7/QromFIVw/wou8KtdvLxZ0EC41z3nqiGHdrB8OXL7PVD70tsH11fg
aRDdFu7Kkn2OjNh0MEfv6geWrMRvdt3dksBPadqWgrLmQb0OL1HgmnV684qnrdaK
f1LVwCdlZJpRKC1JXlKG+h1qXRHV/YglT9fiEZC75lwHPIvIPIpQFoIA/GlPt2YZ
YmCYQcEV/IQLApwXLMRd53BI6FiSOB4OJDDh/XjT8X9s0PSHw0BdRiL4gTjXzHZi
5sWXDsLdzdpPc193sOY4d04BSMdhnFAIv7U2IuuBx2XZitazqNWl6AZJFKTuHxWA
/Um95VIhlNUeJmSelFEg
=gSq+
-----END PGP SIGNATURE-----

--------------enig87163D122552A0693E0564C0--


--===============0082248401099379230==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0082248401099379230==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 12:56:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 12:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmET-00024p-W1; Thu, 05 Apr 2012 12:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFmES-00024c-UH
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 12:56:09 +0000
Received: from [85.158.138.51:11227] by server-10.bemta-3.messagelabs.com id
	52/2B-15637-8669D7F4; Thu, 05 Apr 2012 12:56:08 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333630566!16751906!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22023 invoked from network); 5 Apr 2012 12:56:06 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 12:56:06 -0000
Received: from p5b2e2631.dip.t-dialin.net ([91.46.38.49] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFmEP-0000eH-U0; Thu, 05 Apr 2012 12:56:06 +0000
Message-ID: <4F7D9664.8080406@canonical.com>
Date: Thu, 05 Apr 2012 14:56:04 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0082248401099379230=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0082248401099379230==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig87163D122552A0693E0564C0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig87163D122552A0693E0564C0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 05.04.2012 13:02, Stefano Stabellini wrote:
> On Wed, 4 Apr 2012, Stefan Bader wrote:
>> Hi Stefano,
>>
>> quite a while back in time, you and Konrad had a discussion about some=
 HVM setup
>> problems via libvirt. One part was graphics and the problem seemed to =
be that
>> when creating a new instance through xend for HVM, the use of vfb was =
wrong. It
>> mostly does work but then also defines a vkbd which takes a long time =
in the
>> xenbus setup to finally fail.
>>
>> Because this was not a really fatal problem it did take a long time to=
 actually
>> get back to it. But now I had a look and found that libvirt indeed doe=
s use the
>> vfb form for both the xen-xm and xen-sxpr formats (the latter being us=
ed to
>> create guests). The decision is made based on the xend version number =
in the HVM
>> case. Which would be wrong if I did understand your reply correctly.
>>
>> I have been testing a patch to libvirt, which would not use a vfb defi=
nition
>> whenever HVM is used (regardless of xend version). And it does seem to=
 work (xm
>> list -l however has a vfb device definition, but the same happens when=
 creating
>> the instance with a xm style config file that definitely has no vfb se=
ction in
>> it). But I am testing based on our 12.04 release which uses Xen 4.1.2.=
 So I want
>> to make sure the solution for libvirt is correct for even the current =
Xen version.
>>
>> So in short, is this always correct?
>>
>> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>>    do not define a vfb device
>> else /* PVM and xend version >=3D 3 */
>>    define a vfb device
>=20
> vkbd and vfb can be considered optimizations for PV on HVM guests.
> No PV on HVM guest that I know should be able to use vfb right now, but=

> Linux should be able to use vkbd since:
>=20
> commit 5f098ecd4288333d87e2293239fab1c13ec90dae
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Mon Jul 4 19:22:00 2011 -0700
>=20
>     Input: xen-kbdfront - enable driver for HVM guests
>    =20
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com=
>
>     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>=20
> XL in xen-unstable enables vkbd for HVM guests so that you can have
> keyboard and mouse without usb emulation (that eats significant
> resources in dom0).
>=20
> That said, vkbd is just a (small) optimization, it is far more
> important to get rid of the very annoying wait time at bootup.
> Rather than messing with libvirt and xend I would fix it from the Linux=

> side, see the following thread:
>=20
> http://marc.info/?l=3Dxen-devel&m=3D133238564132683&w=3D2

That would work as well. The downside being that this modification then h=
as to
go in any kernels between 3.1 and the patch. The approach from the other =
side
seemed to make sense so far as it changes generated output that seems tar=
geted
only at talking to xend. The xen-xm format looks to be usable for xl too.=
 But I
would suspect that whenever libvirt starts to support xen api/xl/libxen i=
t will
be using a different interface which then could make use of vfb and vkbd.=


Of course that does not make the change in the kernel less valuable. It p=
revents
the wait time whenever someone manually configures things with vfb.
It just seems to be useless to generate a config that has no use for an
interface that does not support it.

Stefan

> I think that the right thing to do would be removing the additional wai=
t
> time for vfb and vkbd devices in the PV on HVM case. We don't want to
> completely remove vfb and vkbd support for PV on HVM guests though.
>=20
> Konrad, do you agree with the last reply I sent? Do you think you can
> come up with a patch? Maybe separating non-essential from essential
> devices to have two wait loops is not feasible?
> In any case, given the current state of affairs, the first patch in the=

> thread from Konrad is still better than nothing.



--------------enig87163D122552A0693E0564C0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfZZkAAoJEOhnXe7L7s6jEiUQAJLO5rpRCYErn29avM0Us3bJ
CcMb3ARqCqMWoLCGaH/VJ+RWBod84cZE8zNzW1MGH11I0zn6itVWd0IGQJ1BTWGr
sMuFR4iy0Z9cVyFxsZZtL+/2ksDOuhG0zOC95uhQGYGUDRIcgX6Uy+8RD/q6YoXI
BSrDLDA5Tl7QXqI8jlF1dq62HlzeId2e4S9RVrlxf1L4ChL+4FJHslxXaWfJ7Nb/
KlNoTjdyywGiC9KP/dW5Np5oY8xds8oPqVx1EsqOV/VMRT28UndqRqO9oI68xTgY
kVCCyutE8d2eqXH5mu6FdvLS1o8uDiDtNMnUimZlfuXh9QECObMvj03nNDwn6AWX
FBUOHazxdY7/QromFIVw/wou8KtdvLxZ0EC41z3nqiGHdrB8OXL7PVD70tsH11fg
aRDdFu7Kkn2OjNh0MEfv6geWrMRvdt3dksBPadqWgrLmQb0OL1HgmnV684qnrdaK
f1LVwCdlZJpRKC1JXlKG+h1qXRHV/YglT9fiEZC75lwHPIvIPIpQFoIA/GlPt2YZ
YmCYQcEV/IQLApwXLMRd53BI6FiSOB4OJDDh/XjT8X9s0PSHw0BdRiL4gTjXzHZi
5sWXDsLdzdpPc193sOY4d04BSMdhnFAIv7U2IuuBx2XZitazqNWl6AZJFKTuHxWA
/Um95VIhlNUeJmSelFEg
=gSq+
-----END PGP SIGNATURE-----

--------------enig87163D122552A0693E0564C0--


--===============0082248401099379230==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0082248401099379230==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 13:02:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmK1-0002WS-QE; Thu, 05 Apr 2012 13:01:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SFmJz-0002WI-TJ
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:01:52 +0000
Received: from [85.158.138.51:55434] by server-4.bemta-3.messagelabs.com id
	06/48-16467-EB79D7F4; Thu, 05 Apr 2012 13:01:50 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333630909!20982707!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAzODQ0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31169 invoked from network); 5 Apr 2012 13:01:50 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 13:01:50 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 05 Apr 2012 06:01:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="85650500"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 05 Apr 2012 06:01:48 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 5 Apr 2012 06:01:47 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 5 Apr 2012 21:01:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and	xen
	platform
Thread-Index: AQHNDCf6qmcRrTC4dkmeB7vjruTwoZaMP2Vw
Date: Thu, 5 Apr 2012 13:01:45 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923351241B0@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
	<20120226173458.GB18098@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350B9496@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350BAC09@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335105EFA@SHSMSX101.ccr.corp.intel.com>
	<20120326164835.GE10236@phenom.dumpdata.com>
In-Reply-To: <20120326164835.GE10236@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and	xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>> Compare approaches:
>>> 
>>> 1. xen overwritten approach (patches V2, x86_init, osl approach)   
>>>         Pros: a little simpler code
>>>     Cons:
>>>         1). specific to xen, cannot extend to other virt platform;
>>>         2). need to change natvie acpi_pad as modular;
>>> 
>>> 2. paravirt interface approach (original patches V1)     Pros:
>>>         1). standard hypervisor-agnostic interface (USENIX
>>>         conference 2006), can easily hook to Xen/lguest/... on
>>>         demand; 2). arch independent; 3). no need to change native
>>>         acpi_pad as     non-modular; Cons: a little complicated
>>> code, and code patching is some 
>>> overkilled for this case (but no harm);
>>> 
>>> (BTW, in the future we need add more and more pv ops, like
>>> pv_pm_ops, pv_cpu_hotplug_ops, pv_mem_hotplug_ops, etc. So how
>>> about add a pv_misc_ops template to handle them all? seems it's a
>>> common issue). 
>>> 
> 
> I think (and you probabaly have a better idea) is that the maintainer
> of drivers/acpi/* is not very open to adding in code that only
> benefits Xen. 
> 
> If it benefits other architectures (say ARM) then adding in hooks
> there (in osl for example) makes sense - but I am not sure if ARM has
> a form 
> of _PUR code/calls it needs to do.
> 
> So with that in mind, neither of those options seems proper - as all
> of them depend on changing something in drivers/acpi/*.
> 
> I've one or two suggestions of what could be done to still make this
> work, but I need you to first see what happens if the native acpi_pad
> runs under Xen with the latest upstream code (along with three patches
> that are in a BZ I pointed you too).

Konrad, any new idea? seems we hardly totally walk around acpi staff. Thanks, Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:02:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmK1-0002WS-QE; Thu, 05 Apr 2012 13:01:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SFmJz-0002WI-TJ
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:01:52 +0000
Received: from [85.158.138.51:55434] by server-4.bemta-3.messagelabs.com id
	06/48-16467-EB79D7F4; Thu, 05 Apr 2012 13:01:50 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333630909!20982707!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAzODQ0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31169 invoked from network); 5 Apr 2012 13:01:50 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-174.messagelabs.com with SMTP;
	5 Apr 2012 13:01:50 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 05 Apr 2012 06:01:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="85650500"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 05 Apr 2012 06:01:48 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 5 Apr 2012 06:01:47 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 5 Apr 2012 21:01:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and	xen
	platform
Thread-Index: AQHNDCf6qmcRrTC4dkmeB7vjruTwoZaMP2Vw
Date: Thu, 5 Apr 2012 13:01:45 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923351241B0@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
	<20120226173458.GB18098@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350B9496@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350BAC09@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335105EFA@SHSMSX101.ccr.corp.intel.com>
	<20120326164835.GE10236@phenom.dumpdata.com>
In-Reply-To: <20120326164835.GE10236@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and	xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>> Compare approaches:
>>> 
>>> 1. xen overwritten approach (patches V2, x86_init, osl approach)   
>>>         Pros: a little simpler code
>>>     Cons:
>>>         1). specific to xen, cannot extend to other virt platform;
>>>         2). need to change natvie acpi_pad as modular;
>>> 
>>> 2. paravirt interface approach (original patches V1)     Pros:
>>>         1). standard hypervisor-agnostic interface (USENIX
>>>         conference 2006), can easily hook to Xen/lguest/... on
>>>         demand; 2). arch independent; 3). no need to change native
>>>         acpi_pad as     non-modular; Cons: a little complicated
>>> code, and code patching is some 
>>> overkilled for this case (but no harm);
>>> 
>>> (BTW, in the future we need add more and more pv ops, like
>>> pv_pm_ops, pv_cpu_hotplug_ops, pv_mem_hotplug_ops, etc. So how
>>> about add a pv_misc_ops template to handle them all? seems it's a
>>> common issue). 
>>> 
> 
> I think (and you probabaly have a better idea) is that the maintainer
> of drivers/acpi/* is not very open to adding in code that only
> benefits Xen. 
> 
> If it benefits other architectures (say ARM) then adding in hooks
> there (in osl for example) makes sense - but I am not sure if ARM has
> a form 
> of _PUR code/calls it needs to do.
> 
> So with that in mind, neither of those options seems proper - as all
> of them depend on changing something in drivers/acpi/*.
> 
> I've one or two suggestions of what could be done to still make this
> work, but I need you to first see what happens if the native acpi_pad
> runs under Xen with the latest upstream code (along with three patches
> that are in a BZ I pointed you too).

Konrad, any new idea? seems we hardly totally walk around acpi staff. Thanks, Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:02:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmKi-0002Zh-Cn; Thu, 05 Apr 2012 13:02:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1SFmKh-0002ZY-I4
	for Xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:02:35 +0000
Received: from [85.158.138.51:62672] by server-12.bemta-3.messagelabs.com id
	40/8F-30663-AE79D7F4; Thu, 05 Apr 2012 13:02:34 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333630953!20913553!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA5ODkwMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9616 invoked from network); 5 Apr 2012 13:02:34 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 13:02:34 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q35D1NF6018924;
	Thu, 5 Apr 2012 14:01:28 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q35D17pq024828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 14:01:08 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q35D17n4009620;
	Thu, 5 Apr 2012 14:01:07 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q35D16Y3009617; Thu, 5 Apr 2012 14:01:06 +0100 (BST)
Date: Thu, 5 Apr 2012 14:01:06 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120405124813.GA1854@phenom.dumpdata.com>
Message-ID: <alpine.GSO.2.00.1204051357170.9249@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
	<alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
	<20120326135349.GB18285@phenom.dumpdata.com>
	<alpine.DEB.2.00.1203272306370.1410@vega-a.dur.ac.uk>
	<20120328162040.GA5711@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
	<20120405124813.GA1854@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q35D1NF6018924
Cc: xen@lists.fedoraproject.org,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Fedora Core 17 Xorg can't use /dev/fb0 when using
 Cirrus Logic VGA or Xen PVFB driver,
 Was:Re:  irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Konrad Rzeszutek Wilk wrote:

> On Thu, Apr 05, 2012 at 01:11:57AM +0100, M A Young wrote:
>> However I do get the "an error has
>> occurred" message instead of the gdm login screen though until I
>> removed the fprintd package (and the dependent fprintd-pam package).
>
> Oh, that fixed it! How did you find out that piece of the puzzle?

Look in the gdm logs in /var/log/gdm , in particular :0-greeter.log I 
think. There are javascript errors that point the finger at fprintd.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:02:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmKi-0002Zh-Cn; Thu, 05 Apr 2012 13:02:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1SFmKh-0002ZY-I4
	for Xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:02:35 +0000
Received: from [85.158.138.51:62672] by server-12.bemta-3.messagelabs.com id
	40/8F-30663-AE79D7F4; Thu, 05 Apr 2012 13:02:34 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333630953!20913553!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA5ODkwMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9616 invoked from network); 5 Apr 2012 13:02:34 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 13:02:34 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q35D1NF6018924;
	Thu, 5 Apr 2012 14:01:28 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q35D17pq024828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 14:01:08 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q35D17n4009620;
	Thu, 5 Apr 2012 14:01:07 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q35D16Y3009617; Thu, 5 Apr 2012 14:01:06 +0100 (BST)
Date: Thu, 5 Apr 2012 14:01:06 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120405124813.GA1854@phenom.dumpdata.com>
Message-ID: <alpine.GSO.2.00.1204051357170.9249@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
	<alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
	<20120326135349.GB18285@phenom.dumpdata.com>
	<alpine.DEB.2.00.1203272306370.1410@vega-a.dur.ac.uk>
	<20120328162040.GA5711@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204050105190.16672@vega-a.dur.ac.uk>
	<20120405124813.GA1854@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q35D1NF6018924
Cc: xen@lists.fedoraproject.org,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Fedora Core 17 Xorg can't use /dev/fb0 when using
 Cirrus Logic VGA or Xen PVFB driver,
 Was:Re:  irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Konrad Rzeszutek Wilk wrote:

> On Thu, Apr 05, 2012 at 01:11:57AM +0100, M A Young wrote:
>> However I do get the "an error has
>> occurred" message instead of the gdm login screen though until I
>> removed the fprintd package (and the dependent fprintd-pam package).
>
> Oh, that fixed it! How did you find out that piece of the puzzle?

Look in the gdm logs in /var/log/gdm , in particular :0-greeter.log I 
think. There are javascript errors that point the finger at fprintd.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:16:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:16:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmXw-0002uX-Qy; Thu, 05 Apr 2012 13:16:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFmXv-0002uO-QI
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:16:16 +0000
Received: from [85.158.143.99:40241] by server-3.bemta-4.messagelabs.com id
	2A/B0-05853-F1B9D7F4; Thu, 05 Apr 2012 13:16:15 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333631773!21585196!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19614 invoked from network); 5 Apr 2012 13:16:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 13:16:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189154725"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:16:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 09:16:11 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFmXq-0002GA-QC;
	Thu, 05 Apr 2012 14:16:10 +0100
MIME-Version: 1.0
X-Mercurial-Node: c53f124c8c448ea43d753fa562e059e422c1cb36
Message-ID: <c53f124c8c448ea43d75.1333631683@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 14:14:43 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl,
	cpupools: Create empty pool if no cpus are specified
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently, if "xl cpupool-create" is called with no cpus configured,
xl will choose a cpu at random from the list of unassigned cpus, and
if no unassigned cpus are available, it will fail.

This seems to me to be a poor interface.  For one, it makes it impossible
to create an empty cpupool using the xl command-line, except by creating
a pool and then removing the cpus from it.  For two, I don't think assigning
a random cpu is a feature; it's not unreasonable for the user to specify
which cpus to add to which pools.

This patch changes the behavior of "xl cpupool-create" to create an empty
pool if no cpus are specified.  I believe this interface to be more expected
and more script-friendly.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 7530af17cfcf -r c53f124c8c44 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Apr 05 14:04:53 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Apr 05 14:14:32 2012 +0100
@@ -5734,20 +5734,8 @@ int main_cpupoolcreate(int argc, char **
             libxl_cpumap_set(&cpumap, i);
             n_cpus++;
         }
-    } else {
-        n_cpus = 1;
-        n = 0;
-        libxl_for_each_cpu(i, freemap)
-            if (libxl_cpumap_test(&freemap, i)) {
-                n++;
-                libxl_cpumap_set(&cpumap, i);
-                break;
-            }
-        if (n < n_cpus) {
-            fprintf(stderr, "no free cpu found\n");
-            return -ERROR_FAIL;
-        }
-    }
+    } else
+        n_cpus = 0;
 
     libxl_uuid_generate(&uuid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:16:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:16:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmXw-0002uX-Qy; Thu, 05 Apr 2012 13:16:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFmXv-0002uO-QI
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:16:16 +0000
Received: from [85.158.143.99:40241] by server-3.bemta-4.messagelabs.com id
	2A/B0-05853-F1B9D7F4; Thu, 05 Apr 2012 13:16:15 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333631773!21585196!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19614 invoked from network); 5 Apr 2012 13:16:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 13:16:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,375,1330923600"; d="scan'208";a="189154725"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 09:16:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 09:16:11 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFmXq-0002GA-QC;
	Thu, 05 Apr 2012 14:16:10 +0100
MIME-Version: 1.0
X-Mercurial-Node: c53f124c8c448ea43d753fa562e059e422c1cb36
Message-ID: <c53f124c8c448ea43d75.1333631683@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 14:14:43 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl,
	cpupools: Create empty pool if no cpus are specified
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently, if "xl cpupool-create" is called with no cpus configured,
xl will choose a cpu at random from the list of unassigned cpus, and
if no unassigned cpus are available, it will fail.

This seems to me to be a poor interface.  For one, it makes it impossible
to create an empty cpupool using the xl command-line, except by creating
a pool and then removing the cpus from it.  For two, I don't think assigning
a random cpu is a feature; it's not unreasonable for the user to specify
which cpus to add to which pools.

This patch changes the behavior of "xl cpupool-create" to create an empty
pool if no cpus are specified.  I believe this interface to be more expected
and more script-friendly.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 7530af17cfcf -r c53f124c8c44 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Apr 05 14:04:53 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Apr 05 14:14:32 2012 +0100
@@ -5734,20 +5734,8 @@ int main_cpupoolcreate(int argc, char **
             libxl_cpumap_set(&cpumap, i);
             n_cpus++;
         }
-    } else {
-        n_cpus = 1;
-        n = 0;
-        libxl_for_each_cpu(i, freemap)
-            if (libxl_cpumap_test(&freemap, i)) {
-                n++;
-                libxl_cpumap_set(&cpumap, i);
-                break;
-            }
-        if (n < n_cpus) {
-            fprintf(stderr, "no free cpu found\n");
-            return -ERROR_FAIL;
-        }
-    }
+    } else
+        n_cpus = 0;
 
     libxl_uuid_generate(&uuid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmir-0003KI-L4; Thu, 05 Apr 2012 13:27:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmiq-0003KD-JV
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:27:32 +0000
Received: from [85.158.143.99:32053] by server-2.bemta-4.messagelabs.com id
	3A/09-17550-3CD9D7F4; Thu, 05 Apr 2012 13:27:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333632450!21923445!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12519 invoked from network); 5 Apr 2012 13:27:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:27:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:27:30 +0100
Message-Id: <4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:28:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
In-Reply-To: <0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
 out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 0ecf439475e12f185553f42f56f099be5f328cce
> # Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
> x86: don't use .subsection to out-of-line failure path in spinlock.h
> 
> LLVM's assembler doesn't support the .subsection directive.  Instead,
> leave the failure path inline with an unconditional jump past it in
> the success path (so the conditional jump is still forwards).

Please don't - the failure path should really be out-of-line here; that's
why the .subsection directive got added in the first place. And there
are more uses of .subsection elsewhere, which I hope you're not
intending to all undo just because of a shortcoming of a non-standard
assembler. Abstracting this in some way might be doable, e.g.
moving the code into .text.1 or some such when non-gas is used.

Jan

> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 8518fb0c8c99 -r 0ecf439475e1 xen/include/asm-x86/spinlock.h
> --- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
> @@ -44,12 +44,11 @@ static always_inline int _raw_read_trylo
>  
>      asm volatile (
>          "    lock; decl %0         \n"
> -        "    jns 2f                \n"
> -        "1:  .subsection 1         \n"
> -        "2:  lock; incl %0         \n"
> +        "    jns 1f                \n"
> +        "    jmp 2f                \n"
> +        "1:  lock; incl %0         \n"
>          "    decl %1               \n"
> -        "    jmp 1b                \n"
> -        "    .subsection 0         \n"
> +        "2:                        \n"
>          : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
>  
>      return acquired;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmir-0003KI-L4; Thu, 05 Apr 2012 13:27:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmiq-0003KD-JV
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:27:32 +0000
Received: from [85.158.143.99:32053] by server-2.bemta-4.messagelabs.com id
	3A/09-17550-3CD9D7F4; Thu, 05 Apr 2012 13:27:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333632450!21923445!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12519 invoked from network); 5 Apr 2012 13:27:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:27:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:27:30 +0100
Message-Id: <4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:28:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
In-Reply-To: <0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
 out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 0ecf439475e12f185553f42f56f099be5f328cce
> # Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
> x86: don't use .subsection to out-of-line failure path in spinlock.h
> 
> LLVM's assembler doesn't support the .subsection directive.  Instead,
> leave the failure path inline with an unconditional jump past it in
> the success path (so the conditional jump is still forwards).

Please don't - the failure path should really be out-of-line here; that's
why the .subsection directive got added in the first place. And there
are more uses of .subsection elsewhere, which I hope you're not
intending to all undo just because of a shortcoming of a non-standard
assembler. Abstracting this in some way might be doable, e.g.
moving the code into .text.1 or some such when non-gas is used.

Jan

> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 8518fb0c8c99 -r 0ecf439475e1 xen/include/asm-x86/spinlock.h
> --- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 12:55:54 2012 +0100
> @@ -44,12 +44,11 @@ static always_inline int _raw_read_trylo
>  
>      asm volatile (
>          "    lock; decl %0         \n"
> -        "    jns 2f                \n"
> -        "1:  .subsection 1         \n"
> -        "2:  lock; incl %0         \n"
> +        "    jns 1f                \n"
> +        "    jmp 2f                \n"
> +        "1:  lock; incl %0         \n"
>          "    decl %1               \n"
> -        "    jmp 1b                \n"
> -        "    .subsection 0         \n"
> +        "2:                        \n"
>          : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
>  
>      return acquired;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:31:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmlw-0003QW-7t; Thu, 05 Apr 2012 13:30:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmlu-0003QR-Lr
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:30:42 +0000
Received: from [85.158.138.51:47174] by server-3.bemta-3.messagelabs.com id
	8C/12-10665-18E9D7F4; Thu, 05 Apr 2012 13:30:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333632640!20810769!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21662 invoked from network); 5 Apr 2012 13:30:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:30:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:30:40 +0100
Message-Id: <4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:31:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
In-Reply-To: <5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
 comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
> # Parent  0ecf439475e12f185553f42f56f099be5f328cce
> x86/mm: Another couple of comparisons of unsigned vars with < 0.
> 
> Adding the explicit (unsigned) casts in case enums ever end up signed.

Ugly, but unavoidable if range comparisons are done on enums (which
is what ought to get fixed instead imo).

Jan

> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 0ecf439475e1 -r 5eeaa7b25a60 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -1305,7 +1305,7 @@ int p2m_set_mem_access(struct domain *d,
>          p2m->default_access,
>      };
>  
> -    if ( access >= HVMMEM_access_default || access < 0 )
> +    if ( (unsigned) access >= HVMMEM_access_default )
>          return -EINVAL;
>  
>      a = memaccess[access];
> @@ -1367,7 +1367,7 @@ int p2m_get_mem_access(struct domain *d,
>      if ( mfn_x(mfn) == INVALID_MFN )
>          return -ESRCH;
>      
> -    if ( a >= ARRAY_SIZE(memaccess) || a < 0 )
> +    if ( (unsigned) a >= ARRAY_SIZE(memaccess) )
>          return -ERANGE;
>  
>      *access =  memaccess[a];
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:31:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmlw-0003QW-7t; Thu, 05 Apr 2012 13:30:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmlu-0003QR-Lr
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:30:42 +0000
Received: from [85.158.138.51:47174] by server-3.bemta-3.messagelabs.com id
	8C/12-10665-18E9D7F4; Thu, 05 Apr 2012 13:30:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333632640!20810769!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21662 invoked from network); 5 Apr 2012 13:30:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:30:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:30:40 +0100
Message-Id: <4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:31:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
In-Reply-To: <5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
 comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
> # Parent  0ecf439475e12f185553f42f56f099be5f328cce
> x86/mm: Another couple of comparisons of unsigned vars with < 0.
> 
> Adding the explicit (unsigned) casts in case enums ever end up signed.

Ugly, but unavoidable if range comparisons are done on enums (which
is what ought to get fixed instead imo).

Jan

> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 0ecf439475e1 -r 5eeaa7b25a60 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -1305,7 +1305,7 @@ int p2m_set_mem_access(struct domain *d,
>          p2m->default_access,
>      };
>  
> -    if ( access >= HVMMEM_access_default || access < 0 )
> +    if ( (unsigned) access >= HVMMEM_access_default )
>          return -EINVAL;
>  
>      a = memaccess[access];
> @@ -1367,7 +1367,7 @@ int p2m_get_mem_access(struct domain *d,
>      if ( mfn_x(mfn) == INVALID_MFN )
>          return -ESRCH;
>      
> -    if ( a >= ARRAY_SIZE(memaccess) || a < 0 )
> +    if ( (unsigned) a >= ARRAY_SIZE(memaccess) )
>          return -ERANGE;
>  
>      *access =  memaccess[a];
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:32:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmnM-0003VW-Ol; Thu, 05 Apr 2012 13:32:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmnL-0003VH-84
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:32:11 +0000
Received: from [85.158.138.51:63285] by server-11.bemta-3.messagelabs.com id
	97/57-28543-ADE9D7F4; Thu, 05 Apr 2012 13:32:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333632729!20982895!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6570 invoked from network); 5 Apr 2012 13:32:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:32:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:32:09 +0100
Message-Id: <4F7DBB32020000780007CB40@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:33:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<dfe9453c066f3fbfa09c.1333627637@whitby.uk.xensource.com>
In-Reply-To: <dfe9453c066f3fbfa09c.1333627637@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 6] x86: fix logical ANDs used to mask
 bitfields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
> # Parent  5eeaa7b25a60327c48bf17472e9a00bdfc67378f
> x86: fix logical ANDs used to mask bitfields.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -752,7 +752,7 @@ static void svm_lwp_interrupt(struct cpu
>      ack_APIC_irq();
>      vlapic_set_irq(
>          vcpu_vlapic(curr),
> -        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) && 0xff,
> +        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) & 0xff,
>          0);
>  }
>  
> diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -1382,7 +1382,7 @@ void vmx_inject_extint(int trap)
>      if ( nestedhvm_vcpu_in_guestmode(v) ) {
>          pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
>                                       PIN_BASED_VM_EXEC_CONTROL);
> -        if ( pin_based_cntrl && PIN_BASED_EXT_INTR_MASK ) {
> +        if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) {
>              nvmx_enqueue_n2_exceptions (v, 
>                 INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
>                 HVM_DELIVER_NO_ERROR_CODE);
> @@ -1401,7 +1401,7 @@ void vmx_inject_nmi(void)
>      if ( nestedhvm_vcpu_in_guestmode(v) ) {
>          pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
>                                       PIN_BASED_VM_EXEC_CONTROL);
> -        if ( pin_based_cntrl && PIN_BASED_NMI_EXITING ) {
> +        if ( pin_based_cntrl & PIN_BASED_NMI_EXITING ) {
>              nvmx_enqueue_n2_exceptions (v, 
>                 INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
>                 HVM_DELIVER_NO_ERROR_CODE);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:32:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmnM-0003VW-Ol; Thu, 05 Apr 2012 13:32:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmnL-0003VH-84
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:32:11 +0000
Received: from [85.158.138.51:63285] by server-11.bemta-3.messagelabs.com id
	97/57-28543-ADE9D7F4; Thu, 05 Apr 2012 13:32:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1333632729!20982895!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6570 invoked from network); 5 Apr 2012 13:32:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:32:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:32:09 +0100
Message-Id: <4F7DBB32020000780007CB40@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:33:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<dfe9453c066f3fbfa09c.1333627637@whitby.uk.xensource.com>
In-Reply-To: <dfe9453c066f3fbfa09c.1333627637@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 6] x86: fix logical ANDs used to mask
 bitfields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
> # Parent  5eeaa7b25a60327c48bf17472e9a00bdfc67378f
> x86: fix logical ANDs used to mask bitfields.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -752,7 +752,7 @@ static void svm_lwp_interrupt(struct cpu
>      ack_APIC_irq();
>      vlapic_set_irq(
>          vcpu_vlapic(curr),
> -        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) && 0xff,
> +        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) & 0xff,
>          0);
>  }
>  
> diff -r 5eeaa7b25a60 -r dfe9453c066f xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -1382,7 +1382,7 @@ void vmx_inject_extint(int trap)
>      if ( nestedhvm_vcpu_in_guestmode(v) ) {
>          pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
>                                       PIN_BASED_VM_EXEC_CONTROL);
> -        if ( pin_based_cntrl && PIN_BASED_EXT_INTR_MASK ) {
> +        if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) {
>              nvmx_enqueue_n2_exceptions (v, 
>                 INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
>                 HVM_DELIVER_NO_ERROR_CODE);
> @@ -1401,7 +1401,7 @@ void vmx_inject_nmi(void)
>      if ( nestedhvm_vcpu_in_guestmode(v) ) {
>          pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
>                                       PIN_BASED_VM_EXEC_CONTROL);
> -        if ( pin_based_cntrl && PIN_BASED_NMI_EXITING ) {
> +        if ( pin_based_cntrl & PIN_BASED_NMI_EXITING ) {
>              nvmx_enqueue_n2_exceptions (v, 
>                 INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
>                 HVM_DELIVER_NO_ERROR_CODE);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:35:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmqI-0003iX-B4; Thu, 05 Apr 2012 13:35:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SFmqH-0003iO-Hv
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:35:13 +0000
Received: from [85.158.143.35:10883] by server-1.bemta-4.messagelabs.com id
	82/9B-20925-09F9D7F4; Thu, 05 Apr 2012 13:35:12 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333632911!11194713!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7544 invoked from network); 5 Apr 2012 13:35:11 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Apr 2012 13:35:11 -0000
Received: from mail45-am1-R.bigfish.com (10.3.201.244) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 13:35:10 +0000
Received: from mail45-am1 (localhost [127.0.0.1])	by mail45-am1-R.bigfish.com
	(Postfix) with ESMTP id C8D3FE05A3;
	Thu,  5 Apr 2012 13:35:10 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zz4015Izz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail45-am1 (localhost.localdomain [127.0.0.1]) by mail45-am1
	(MessageSwitch) id 1333632908924268_9586;
	Thu,  5 Apr 2012 13:35:08 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.225])	by
	mail45-am1.bigfish.com (Postfix) with ESMTP id DD3D78018B;
	Thu,  5 Apr 2012 13:35:08 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 13:35:07 +0000
X-WSS-ID: 0M20DQG-01-62J-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DE68102806D;	Thu,  5 Apr 2012 08:35:04 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Apr 2012 08:35:19 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 5 Apr 2012 08:35:04 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	09:35:04 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4347649C58B; Thu,  5 Apr 2012
	14:35:02 +0100 (BST)
Message-ID: <4F7DA082.5030503@amd.com>
Date: Thu, 5 Apr 2012 15:39:14 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] acpi: Fix an incorrect code path in
	acpi_processor_idle()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, There seems to be an incorrect code path in acpi_processor_idle(). 
ACPI_STATE_C3 code path might need to be avoided when cpu tries to enter 
c2 but lapic_timer_c2_ok is not set. This bug affects some amd systems 
which have c2 state available. The XenServer 6.0 performance issue[1] 
should also be fixed by this patch. If it looks fine, please apply it to 
unstable, 4.1 and 4.0

Thanks,
Wei

[1]
http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1333626300 -7200
# Node ID bc0e1869ba5c77e85f3ed012a979ac8061094367
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
Fix an incorrect code path in acpi_processor_idle()

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r d690c7e896a2 -r bc0e1869ba5c xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 13:45:00 2012 +0200
@@ -466,8 +466,8 @@ static void acpi_processor_idle(void)
              local_irq_enable();
              /* Compute time (ticks) that we were actually asleep */
              sleep_ticks = ticks_elapsed(t1, t2);
-            break;
          }
+        break;

      case ACPI_STATE_C3:
          /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:35:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmqI-0003iX-B4; Thu, 05 Apr 2012 13:35:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SFmqH-0003iO-Hv
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 13:35:13 +0000
Received: from [85.158.143.35:10883] by server-1.bemta-4.messagelabs.com id
	82/9B-20925-09F9D7F4; Thu, 05 Apr 2012 13:35:12 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333632911!11194713!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7544 invoked from network); 5 Apr 2012 13:35:11 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Apr 2012 13:35:11 -0000
Received: from mail45-am1-R.bigfish.com (10.3.201.244) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 13:35:10 +0000
Received: from mail45-am1 (localhost [127.0.0.1])	by mail45-am1-R.bigfish.com
	(Postfix) with ESMTP id C8D3FE05A3;
	Thu,  5 Apr 2012 13:35:10 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zz4015Izz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail45-am1 (localhost.localdomain [127.0.0.1]) by mail45-am1
	(MessageSwitch) id 1333632908924268_9586;
	Thu,  5 Apr 2012 13:35:08 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.225])	by
	mail45-am1.bigfish.com (Postfix) with ESMTP id DD3D78018B;
	Thu,  5 Apr 2012 13:35:08 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 13:35:07 +0000
X-WSS-ID: 0M20DQG-01-62J-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DE68102806D;	Thu,  5 Apr 2012 08:35:04 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Apr 2012 08:35:19 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 5 Apr 2012 08:35:04 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	09:35:04 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4347649C58B; Thu,  5 Apr 2012
	14:35:02 +0100 (BST)
Message-ID: <4F7DA082.5030503@amd.com>
Date: Thu, 5 Apr 2012 15:39:14 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] acpi: Fix an incorrect code path in
	acpi_processor_idle()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, There seems to be an incorrect code path in acpi_processor_idle(). 
ACPI_STATE_C3 code path might need to be avoided when cpu tries to enter 
c2 but lapic_timer_c2_ok is not set. This bug affects some amd systems 
which have c2 state available. The XenServer 6.0 performance issue[1] 
should also be fixed by this patch. If it looks fine, please apply it to 
unstable, 4.1 and 4.0

Thanks,
Wei

[1]
http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1333626300 -7200
# Node ID bc0e1869ba5c77e85f3ed012a979ac8061094367
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
Fix an incorrect code path in acpi_processor_idle()

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r d690c7e896a2 -r bc0e1869ba5c xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 13:45:00 2012 +0200
@@ -466,8 +466,8 @@ static void acpi_processor_idle(void)
              local_irq_enable();
              /* Compute time (ticks) that we were actually asleep */
              sleep_ticks = ticks_elapsed(t1, t2);
-            break;
          }
+        break;

      case ACPI_STATE_C3:
          /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:38:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmsy-0003uz-TK; Thu, 05 Apr 2012 13:38:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmsx-0003ur-M8
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:37:59 +0000
Received: from [85.158.143.35:27849] by server-3.bemta-4.messagelabs.com id
	40/E2-05853-730AD7F4; Thu, 05 Apr 2012 13:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333633078!11195358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18819 invoked from network); 5 Apr 2012 13:37:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:37:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:37:58 +0100
Message-Id: <4F7DBC8F020000780007CB52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:38:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5101e5ed24732919076d.1333627638@whitby.uk.xensource.com>
In-Reply-To: <5101e5ed24732919076d.1333627638@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5 of 6] x86: fix memset(ptr, 0, sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 5101e5ed24732919076d5285e55c7b53032749c2
> # Parent  dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
> x86: fix memset(ptr, 0, sizeof ptr).
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/cpu/mcheck/amd_f10.c
> --- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
>  		return NULL;
>  	}
>  
> -	memset(mc_ext, 0, sizeof(mc_ext));
> +	memset(mc_ext, 0, sizeof(*mc_ext));
>  	mc_ext->common.type = MC_TYPE_EXTENDED;
> -	mc_ext->common.size = sizeof(mc_ext);
> +	mc_ext->common.size = sizeof(*mc_ext);
>  	mc_ext->mc_msrs = 3;
>  
>  	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
> diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -1236,7 +1236,7 @@ bool_t p2m_mem_access_check(unsigned lon
>      if ( req )
>      {
>          *req_ptr = req;
> -        memset(req, 0, sizeof(req));
> +        memset(req, 0, sizeof (mem_event_request_t));

Why not

        memset(req, 0, sizeof (*req));

? If req's type changes, you still want to clear all of it (and nothing
more).

Oh, wait - this gets xmalloc()-ed immediately before that if(). Mind
simply switching that one to xzalloc(), and deleting the memset()
altogether? (I wonder how many other xmalloc()/memset() pairs
went in again since the introduction of xzalloc() - one of the
purposes of this was to avoid this particular common mistake.)

Apart from that
Acked-by: Jan Beulich <jbeulich@suse.com>

>          req->reason = MEM_EVENT_REASON_VIOLATION;
>  
>          /* Pause the current VCPU */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:38:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmsy-0003uz-TK; Thu, 05 Apr 2012 13:38:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmsx-0003ur-M8
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:37:59 +0000
Received: from [85.158.143.35:27849] by server-3.bemta-4.messagelabs.com id
	40/E2-05853-730AD7F4; Thu, 05 Apr 2012 13:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333633078!11195358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18819 invoked from network); 5 Apr 2012 13:37:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:37:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:37:58 +0100
Message-Id: <4F7DBC8F020000780007CB52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:38:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5101e5ed24732919076d.1333627638@whitby.uk.xensource.com>
In-Reply-To: <5101e5ed24732919076d.1333627638@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5 of 6] x86: fix memset(ptr, 0, sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 5101e5ed24732919076d5285e55c7b53032749c2
> # Parent  dfe9453c066f3fbfa09c847d7ec381cdc0da0f99
> x86: fix memset(ptr, 0, sizeof ptr).
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/cpu/mcheck/amd_f10.c
> --- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
>  		return NULL;
>  	}
>  
> -	memset(mc_ext, 0, sizeof(mc_ext));
> +	memset(mc_ext, 0, sizeof(*mc_ext));
>  	mc_ext->common.type = MC_TYPE_EXTENDED;
> -	mc_ext->common.size = sizeof(mc_ext);
> +	mc_ext->common.size = sizeof(*mc_ext);
>  	mc_ext->mc_msrs = 3;
>  
>  	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
> diff -r dfe9453c066f -r 5101e5ed2473 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -1236,7 +1236,7 @@ bool_t p2m_mem_access_check(unsigned lon
>      if ( req )
>      {
>          *req_ptr = req;
> -        memset(req, 0, sizeof(req));
> +        memset(req, 0, sizeof (mem_event_request_t));

Why not

        memset(req, 0, sizeof (*req));

? If req's type changes, you still want to clear all of it (and nothing
more).

Oh, wait - this gets xmalloc()-ed immediately before that if(). Mind
simply switching that one to xzalloc(), and deleting the memset()
altogether? (I wonder how many other xmalloc()/memset() pairs
went in again since the introduction of xzalloc() - one of the
purposes of this was to avoid this particular common mistake.)

Apart from that
Acked-by: Jan Beulich <jbeulich@suse.com>

>          req->reason = MEM_EVENT_REASON_VIOLATION;
>  
>          /* Pause the current VCPU */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:43:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmy8-000476-Mj; Thu, 05 Apr 2012 13:43:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmy7-00046y-5X
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:43:19 +0000
Received: from [85.158.143.35:20218] by server-2.bemta-4.messagelabs.com id
	72/71-17550-671AD7F4; Thu, 05 Apr 2012 13:43:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333633397!12030803!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7656 invoked from network); 5 Apr 2012 13:43:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:43:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:43:17 +0100
Message-Id: <4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:44:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
In-Reply-To: <5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
 variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 5a2f5ab5128e4b13b3fd2dbcae1f084bc922584e
> # Parent  5101e5ed24732919076d5285e55c7b53032749c2
> x86: explicitly mark an __initdata variable as used.
> 
> This stops LLVM from replacing it with a different, auto-generated
> variable as part of an optimization.  (The auto-generated variable
> ends up in the normal data section, failing the check that this
> file only contains __initdata vars).
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
> --- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
>      struct domain *d, unsigned long max_pages)
>  {
>      static unsigned int __initdata last_order = MAX_ORDER;
> -    static unsigned int __initdata memflags = MEMF_no_dma;
> +    static unsigned int __initdata __attribute__((used)) memflags = MEMF_no_dma;

Without a code comment, the mere fact that this is (a) totally
non-obvious, (b) being done differently for two neighboring
variables of otherwise the exact same kind, and (c) probably
a compiler bug makes it quite likely that your change will get
removed again by a future commit.

Furthermore, it being needed on one but not the other variable
makes it highly likely that the same issue could surface at any
time here or elsewhere in the code.

Jan

>      struct page_info *page;
>      unsigned int order = get_order_from_pages(max_pages), free_order;
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 13:43:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 13:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFmy8-000476-Mj; Thu, 05 Apr 2012 13:43:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFmy7-00046y-5X
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 13:43:19 +0000
Received: from [85.158.143.35:20218] by server-2.bemta-4.messagelabs.com id
	72/71-17550-671AD7F4; Thu, 05 Apr 2012 13:43:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333633397!12030803!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7656 invoked from network); 5 Apr 2012 13:43:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 13:43:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 14:43:17 +0100
Message-Id: <4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 14:44:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
In-Reply-To: <5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
 variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333626954 -3600
> # Node ID 5a2f5ab5128e4b13b3fd2dbcae1f084bc922584e
> # Parent  5101e5ed24732919076d5285e55c7b53032749c2
> x86: explicitly mark an __initdata variable as used.
> 
> This stops LLVM from replacing it with a different, auto-generated
> variable as part of an optimization.  (The auto-generated variable
> ends up in the normal data section, failing the check that this
> file only contains __initdata vars).
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
> --- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> +++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> @@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
>      struct domain *d, unsigned long max_pages)
>  {
>      static unsigned int __initdata last_order = MAX_ORDER;
> -    static unsigned int __initdata memflags = MEMF_no_dma;
> +    static unsigned int __initdata __attribute__((used)) memflags = MEMF_no_dma;

Without a code comment, the mere fact that this is (a) totally
non-obvious, (b) being done differently for two neighboring
variables of otherwise the exact same kind, and (c) probably
a compiler bug makes it quite likely that your change will get
removed again by a future commit.

Furthermore, it being needed on one but not the other variable
makes it highly likely that the same issue could surface at any
time here or elsewhere in the code.

Jan

>      struct page_info *page;
>      unsigned int order = get_order_from_pages(max_pages), free_order;
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:02:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:02:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnGG-0004SM-J9; Thu, 05 Apr 2012 14:02:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnGF-0004SH-9W
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:02:03 +0000
Received: from [85.158.139.83:47951] by server-2.bemta-5.messagelabs.com id
	8B/E8-17016-AD5AD7F4; Thu, 05 Apr 2012 14:02:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333634521!18701828!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32528 invoked from network); 5 Apr 2012 14:02:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:02:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:02:01 +0100
Message-Id: <4F7DC230020000780007CB78@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:02:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4F7DA082.5030503@amd.com>
In-Reply-To: <4F7DA082.5030503@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] acpi: Fix an incorrect code path in
 acpi_processor_idle()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 15:39, Wei Wang <wei.wang2@amd.com> wrote:
> Hi, There seems to be an incorrect code path in acpi_processor_idle(). 
> ACPI_STATE_C3 code path might need to be avoided when cpu tries to enter 
> c2 but lapic_timer_c2_ok is not set. This bug affects some amd systems 
> which have c2 state available. The XenServer 6.0 performance issue[1] 
> should also be fixed by this patch. If it looks fine, please apply it to 
> unstable, 4.1 and 4.0
> 
> Thanks,
> Wei
> 
> [1]
> http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0 
> 
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1333626300 -7200
> # Node ID bc0e1869ba5c77e85f3ed012a979ac8061094367
> # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> Fix an incorrect code path in acpi_processor_idle()
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r d690c7e896a2 -r bc0e1869ba5c xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 13:45:00 2012 +0200
> @@ -466,8 +466,8 @@ static void acpi_processor_idle(void)
>               local_irq_enable();
>               /* Compute time (ticks) that we were actually asleep */
>               sleep_ticks = ticks_elapsed(t1, t2);
> -            break;
>           }
> +        break;

Looking also at check_cx(), I think the fall-through here is intentional.
What you're doing is to disallow entering C2 altogether unless
local_apic_timer_c2_ok. My understanding of the code without your
change is that the more involved C3 entry method gets otherwise
used also for C2 (to cope with the APIC timer potentially stopping).

Quite obviously, disallowing C2 will improve responsiveness (wakeup
latency) of a system, but the question is whether that's really
intended (or whether instead the better power savings matter). In
any case I think you'll need to do some more analysis to determine
the cause of whatever problem you were seeing, and get an ack
from the Intel folks who mostly wrote that code (Cc-ing one of them,
in the hope he might Cc others if necessary).

Jan

> 
>       case ACPI_STATE_C3:
>           /*




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:02:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:02:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnGG-0004SM-J9; Thu, 05 Apr 2012 14:02:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnGF-0004SH-9W
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:02:03 +0000
Received: from [85.158.139.83:47951] by server-2.bemta-5.messagelabs.com id
	8B/E8-17016-AD5AD7F4; Thu, 05 Apr 2012 14:02:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1333634521!18701828!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32528 invoked from network); 5 Apr 2012 14:02:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:02:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:02:01 +0100
Message-Id: <4F7DC230020000780007CB78@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:02:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4F7DA082.5030503@amd.com>
In-Reply-To: <4F7DA082.5030503@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] acpi: Fix an incorrect code path in
 acpi_processor_idle()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 15:39, Wei Wang <wei.wang2@amd.com> wrote:
> Hi, There seems to be an incorrect code path in acpi_processor_idle(). 
> ACPI_STATE_C3 code path might need to be avoided when cpu tries to enter 
> c2 but lapic_timer_c2_ok is not set. This bug affects some amd systems 
> which have c2 state available. The XenServer 6.0 performance issue[1] 
> should also be fixed by this patch. If it looks fine, please apply it to 
> unstable, 4.1 and 4.0
> 
> Thanks,
> Wei
> 
> [1]
> http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0 
> 
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1333626300 -7200
> # Node ID bc0e1869ba5c77e85f3ed012a979ac8061094367
> # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> Fix an incorrect code path in acpi_processor_idle()
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r d690c7e896a2 -r bc0e1869ba5c xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Thu Apr 05 13:45:00 2012 +0200
> @@ -466,8 +466,8 @@ static void acpi_processor_idle(void)
>               local_irq_enable();
>               /* Compute time (ticks) that we were actually asleep */
>               sleep_ticks = ticks_elapsed(t1, t2);
> -            break;
>           }
> +        break;

Looking also at check_cx(), I think the fall-through here is intentional.
What you're doing is to disallow entering C2 altogether unless
local_apic_timer_c2_ok. My understanding of the code without your
change is that the more involved C3 entry method gets otherwise
used also for C2 (to cope with the APIC timer potentially stopping).

Quite obviously, disallowing C2 will improve responsiveness (wakeup
latency) of a system, but the question is whether that's really
intended (or whether instead the better power savings matter). In
any case I think you'll need to do some more analysis to determine
the cause of whatever problem you were seeing, and get an ack
from the Intel folks who mostly wrote that code (Cc-ing one of them,
in the hope he might Cc others if necessary).

Jan

> 
>       case ACPI_STATE_C3:
>           /*




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:06:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnJy-0004ZP-7F; Thu, 05 Apr 2012 14:05:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFnJw-0004ZJ-JL
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:05:52 +0000
Received: from [85.158.139.83:26111] by server-11.bemta-5.messagelabs.com id
	12/BA-12959-FB6AD7F4; Thu, 05 Apr 2012 14:05:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333634750!19939781!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32263 invoked from network); 5 Apr 2012 14:05:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:05:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFnJt-0004mL-UJ; Thu, 05 Apr 2012 14:05:49 +0000
Date: Thu, 5 Apr 2012 15:05:49 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405140549.GF14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
	<4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
	out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:28 +0100 on 05 Apr (1333636106), Jan Beulich wrote:
> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1333626954 -3600
> > # Node ID 0ecf439475e12f185553f42f56f099be5f328cce
> > # Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
> > x86: don't use .subsection to out-of-line failure path in spinlock.h
> > 
> > LLVM's assembler doesn't support the .subsection directive.  Instead,
> > leave the failure path inline with an unconditional jump past it in
> > the success path (so the conditional jump is still forwards).
> 
> Please don't - the failure path should really be out-of-line here; that's
> why the .subsection directive got added in the first place. And there
> are more uses of .subsection elsewhere, which I hope you're not
> intending to all undo just because of a shortcoming of a non-standard
> assembler. 

The other uses are all in .S files, so don't go through clang's
assembler.

> Abstracting this in some way might be doable, e.g.
> moving the code into .text.1 or some such when non-gas is used.

OK.  How about something like this?

diff -r ea2bf1456a52 xen/include/asm-x86/spinlock.h
--- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 14:51:31 2012 +0100
+++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 15:03:31 2012 +0100
@@ -45,11 +45,11 @@ static always_inline int _raw_read_trylo
     asm volatile (
         "    lock; decl %0         \n"
         "    jns 2f                \n"
-        "1:  .subsection 1         \n"
+        "1:  .pushsection .fixup   \n"
         "2:  lock; incl %0         \n"
         "    decl %1               \n"
         "    jmp 1b                \n"
-        "    .subsection 0         \n"
+        "    .popsection           \n"
         : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
 
     return acquired;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:06:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnJy-0004ZP-7F; Thu, 05 Apr 2012 14:05:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFnJw-0004ZJ-JL
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:05:52 +0000
Received: from [85.158.139.83:26111] by server-11.bemta-5.messagelabs.com id
	12/BA-12959-FB6AD7F4; Thu, 05 Apr 2012 14:05:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333634750!19939781!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32263 invoked from network); 5 Apr 2012 14:05:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:05:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFnJt-0004mL-UJ; Thu, 05 Apr 2012 14:05:49 +0000
Date: Thu, 5 Apr 2012 15:05:49 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405140549.GF14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
	<4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
	out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:28 +0100 on 05 Apr (1333636106), Jan Beulich wrote:
> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1333626954 -3600
> > # Node ID 0ecf439475e12f185553f42f56f099be5f328cce
> > # Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
> > x86: don't use .subsection to out-of-line failure path in spinlock.h
> > 
> > LLVM's assembler doesn't support the .subsection directive.  Instead,
> > leave the failure path inline with an unconditional jump past it in
> > the success path (so the conditional jump is still forwards).
> 
> Please don't - the failure path should really be out-of-line here; that's
> why the .subsection directive got added in the first place. And there
> are more uses of .subsection elsewhere, which I hope you're not
> intending to all undo just because of a shortcoming of a non-standard
> assembler. 

The other uses are all in .S files, so don't go through clang's
assembler.

> Abstracting this in some way might be doable, e.g.
> moving the code into .text.1 or some such when non-gas is used.

OK.  How about something like this?

diff -r ea2bf1456a52 xen/include/asm-x86/spinlock.h
--- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 14:51:31 2012 +0100
+++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 15:03:31 2012 +0100
@@ -45,11 +45,11 @@ static always_inline int _raw_read_trylo
     asm volatile (
         "    lock; decl %0         \n"
         "    jns 2f                \n"
-        "1:  .subsection 1         \n"
+        "1:  .pushsection .fixup   \n"
         "2:  lock; incl %0         \n"
         "    decl %1               \n"
         "    jmp 1b                \n"
-        "    .subsection 0         \n"
+        "    .popsection           \n"
         : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
 
     return acquired;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnMh-0004gX-ED; Thu, 05 Apr 2012 14:08:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFnMf-0004gF-7S
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:08:41 +0000
Received: from [85.158.143.35:24910] by server-3.bemta-4.messagelabs.com id
	B2/61-05853-867AD7F4; Thu, 05 Apr 2012 14:08:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333634919!8735482!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8877 invoked from network); 5 Apr 2012 14:08:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:08:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFnMd-0004mi-Iq; Thu, 05 Apr 2012 14:08:39 +0000
Date: Thu, 5 Apr 2012 15:08:39 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405140839.GG14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
	<4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
	comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:31 +0100 on 05 Apr (1333636297), Jan Beulich wrote:
> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1333626954 -3600
> > # Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
> > # Parent  0ecf439475e12f185553f42f56f099be5f328cce
> > x86/mm: Another couple of comparisons of unsigned vars with < 0.
> > 
> > Adding the explicit (unsigned) casts in case enums ever end up signed.
> 
> Ugly, but unavoidable if range comparisons are done on enums (which
> is what ought to get fixed instead imo).

Any suggestions for how?  Turn the array access into a case statement?
That's even uglier IMO. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnMh-0004gX-ED; Thu, 05 Apr 2012 14:08:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFnMf-0004gF-7S
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:08:41 +0000
Received: from [85.158.143.35:24910] by server-3.bemta-4.messagelabs.com id
	B2/61-05853-867AD7F4; Thu, 05 Apr 2012 14:08:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333634919!8735482!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8877 invoked from network); 5 Apr 2012 14:08:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:08:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFnMd-0004mi-Iq; Thu, 05 Apr 2012 14:08:39 +0000
Date: Thu, 5 Apr 2012 15:08:39 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405140839.GG14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
	<4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
	comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:31 +0100 on 05 Apr (1333636297), Jan Beulich wrote:
> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1333626954 -3600
> > # Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
> > # Parent  0ecf439475e12f185553f42f56f099be5f328cce
> > x86/mm: Another couple of comparisons of unsigned vars with < 0.
> > 
> > Adding the explicit (unsigned) casts in case enums ever end up signed.
> 
> Ugly, but unavoidable if range comparisons are done on enums (which
> is what ought to get fixed instead imo).

Any suggestions for how?  Turn the array access into a case statement?
That's even uglier IMO. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:11:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:11:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnOp-0004uF-Vk; Thu, 05 Apr 2012 14:10:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnOo-0004ty-Be
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:10:54 +0000
Received: from [85.158.143.99:30342] by server-1.bemta-4.messagelabs.com id
	B9/12-20925-DE7AD7F4; Thu, 05 Apr 2012 14:10:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333635051!17262309!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9480 invoked from network); 5 Apr 2012 14:10:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:10:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:10:51 +0100
Message-Id: <4F7DC444020000780007CB92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:11:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
	<4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
	<20120405140549.GF14774@ocelot.phlegethon.org>
In-Reply-To: <20120405140549.GF14774@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
 out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 16:05, Tim Deegan <tim@xen.org> wrote:
> At 14:28 +0100 on 05 Apr (1333636106), Jan Beulich wrote:
>> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
>> > # HG changeset patch
>> > # User Tim Deegan <tim@xen.org>
>> > # Date 1333626954 -3600
>> > # Node ID 0ecf439475e12f185553f42f56f099be5f328cce
>> > # Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
>> > x86: don't use .subsection to out-of-line failure path in spinlock.h
>> > 
>> > LLVM's assembler doesn't support the .subsection directive.  Instead,
>> > leave the failure path inline with an unconditional jump past it in
>> > the success path (so the conditional jump is still forwards).
>> 
>> Please don't - the failure path should really be out-of-line here; that's
>> why the .subsection directive got added in the first place. And there
>> are more uses of .subsection elsewhere, which I hope you're not
>> intending to all undo just because of a shortcoming of a non-standard
>> assembler. 
> 
> The other uses are all in .S files, so don't go through clang's
> assembler.

Oh, so the compiler looks at the assembly itself? Or uses other than
gas for assembling (yet gas gets used for dealing with assembly files)?

>> Abstracting this in some way might be doable, e.g.
>> moving the code into .text.1 or some such when non-gas is used.
> 
> OK.  How about something like this?

This looks reasonable - if you package it so that with gcc it will be
.subsection and only with clang it would become .pushsection/
.popsection. (Also, to be generic, you may need to specify the
attributes of the .fixup section.)

Jan

> --- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 14:51:31 2012 +0100
> +++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 15:03:31 2012 +0100
> @@ -45,11 +45,11 @@ static always_inline int _raw_read_trylo
>      asm volatile (
>          "    lock; decl %0         \n"
>          "    jns 2f                \n"
> -        "1:  .subsection 1         \n"
> +        "1:  .pushsection .fixup   \n"
>          "2:  lock; incl %0         \n"
>          "    decl %1               \n"
>          "    jmp 1b                \n"
> -        "    .subsection 0         \n"
> +        "    .popsection           \n"
>          : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
>  
>      return acquired;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:11:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:11:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnOp-0004uF-Vk; Thu, 05 Apr 2012 14:10:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnOo-0004ty-Be
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:10:54 +0000
Received: from [85.158.143.99:30342] by server-1.bemta-4.messagelabs.com id
	B9/12-20925-DE7AD7F4; Thu, 05 Apr 2012 14:10:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333635051!17262309!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9480 invoked from network); 5 Apr 2012 14:10:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:10:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:10:51 +0100
Message-Id: <4F7DC444020000780007CB92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:11:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<0ecf439475e12f185553.1333627635@whitby.uk.xensource.com>
	<4F7DBA1A020000780007CB28@nat28.tlf.novell.com>
	<20120405140549.GF14774@ocelot.phlegethon.org>
In-Reply-To: <20120405140549.GF14774@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86: don't use .subsection to
 out-of-line failure path in spinlock.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 16:05, Tim Deegan <tim@xen.org> wrote:
> At 14:28 +0100 on 05 Apr (1333636106), Jan Beulich wrote:
>> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
>> > # HG changeset patch
>> > # User Tim Deegan <tim@xen.org>
>> > # Date 1333626954 -3600
>> > # Node ID 0ecf439475e12f185553f42f56f099be5f328cce
>> > # Parent  8518fb0c8c996dca67efd39d31962a6d3502c2ed
>> > x86: don't use .subsection to out-of-line failure path in spinlock.h
>> > 
>> > LLVM's assembler doesn't support the .subsection directive.  Instead,
>> > leave the failure path inline with an unconditional jump past it in
>> > the success path (so the conditional jump is still forwards).
>> 
>> Please don't - the failure path should really be out-of-line here; that's
>> why the .subsection directive got added in the first place. And there
>> are more uses of .subsection elsewhere, which I hope you're not
>> intending to all undo just because of a shortcoming of a non-standard
>> assembler. 
> 
> The other uses are all in .S files, so don't go through clang's
> assembler.

Oh, so the compiler looks at the assembly itself? Or uses other than
gas for assembling (yet gas gets used for dealing with assembly files)?

>> Abstracting this in some way might be doable, e.g.
>> moving the code into .text.1 or some such when non-gas is used.
> 
> OK.  How about something like this?

This looks reasonable - if you package it so that with gcc it will be
.subsection and only with clang it would become .pushsection/
.popsection. (Also, to be generic, you may need to specify the
attributes of the .fixup section.)

Jan

> --- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 14:51:31 2012 +0100
> +++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 15:03:31 2012 +0100
> @@ -45,11 +45,11 @@ static always_inline int _raw_read_trylo
>      asm volatile (
>          "    lock; decl %0         \n"
>          "    jns 2f                \n"
> -        "1:  .subsection 1         \n"
> +        "1:  .pushsection .fixup   \n"
>          "2:  lock; incl %0         \n"
>          "    decl %1               \n"
>          "    jmp 1b                \n"
> -        "    .subsection 0         \n"
> +        "    .popsection           \n"
>          : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
>  
>      return acquired;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnPn-000519-Dx; Thu, 05 Apr 2012 14:11:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFnPm-00050s-04
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:11:54 +0000
Received: from [85.158.143.35:38791] by server-1.bemta-4.messagelabs.com id
	32/C3-20925-928AD7F4; Thu, 05 Apr 2012 14:11:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333635112!14889355!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15364 invoked from network); 5 Apr 2012 14:11:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:11:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFnPj-0004o5-TB; Thu, 05 Apr 2012 14:11:51 +0000
Date: Thu, 5 Apr 2012 15:11:51 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405141151.GH14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
	<4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
	variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:44 +0100 on 05 Apr (1333637053), Jan Beulich wrote:
> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> > x86: explicitly mark an __initdata variable as used.
> > 
> > This stops LLVM from replacing it with a different, auto-generated
> > variable as part of an optimization.  (The auto-generated variable
> > ends up in the normal data section, failing the check that this
> > file only contains __initdata vars).
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
> > --- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> > +++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> > @@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
> >      struct domain *d, unsigned long max_pages)
> >  {
> >      static unsigned int __initdata last_order = MAX_ORDER;
> > -    static unsigned int __initdata memflags = MEMF_no_dma;
> > +    static unsigned int __initdata __attribute__((used)) memflags = MEMF_no_dma;
> 
> Without a code comment, the mere fact that this is (a) totally
> non-obvious, (b) being done differently for two neighboring
> variables of otherwise the exact same kind, and (c) probably
> a compiler bug makes it quite likely that your change will get
> removed again by a future commit.

Sorry, yes this deserves a code comment.  I'll add one. 

I agree that this is a compiler bug, but the LLVM developers disagree,
and I have limited time for arguing with compiler devs.

> Furthermore, it being needed on one but not the other variable
> makes it highly likely that the same issue could surface at any
> time here or elsewhere in the code.

I considered putting the __attribute__((used)) into the definition of
__initdata but thought it was more invasive.  I'm happy to reconsider. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnPn-000519-Dx; Thu, 05 Apr 2012 14:11:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFnPm-00050s-04
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:11:54 +0000
Received: from [85.158.143.35:38791] by server-1.bemta-4.messagelabs.com id
	32/C3-20925-928AD7F4; Thu, 05 Apr 2012 14:11:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333635112!14889355!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15364 invoked from network); 5 Apr 2012 14:11:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:11:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFnPj-0004o5-TB; Thu, 05 Apr 2012 14:11:51 +0000
Date: Thu, 5 Apr 2012 15:11:51 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405141151.GH14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
	<4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
	variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:44 +0100 on 05 Apr (1333637053), Jan Beulich wrote:
> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> > x86: explicitly mark an __initdata variable as used.
> > 
> > This stops LLVM from replacing it with a different, auto-generated
> > variable as part of an optimization.  (The auto-generated variable
> > ends up in the normal data section, failing the check that this
> > file only contains __initdata vars).
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
> > --- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> > +++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
> > @@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
> >      struct domain *d, unsigned long max_pages)
> >  {
> >      static unsigned int __initdata last_order = MAX_ORDER;
> > -    static unsigned int __initdata memflags = MEMF_no_dma;
> > +    static unsigned int __initdata __attribute__((used)) memflags = MEMF_no_dma;
> 
> Without a code comment, the mere fact that this is (a) totally
> non-obvious, (b) being done differently for two neighboring
> variables of otherwise the exact same kind, and (c) probably
> a compiler bug makes it quite likely that your change will get
> removed again by a future commit.

Sorry, yes this deserves a code comment.  I'll add one. 

I agree that this is a compiler bug, but the LLVM developers disagree,
and I have limited time for arguing with compiler devs.

> Furthermore, it being needed on one but not the other variable
> makes it highly likely that the same issue could surface at any
> time here or elsewhere in the code.

I considered putting the __attribute__((used)) into the definition of
__initdata but thought it was more invasive.  I'm happy to reconsider. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnSK-0005Ic-MA; Thu, 05 Apr 2012 14:14:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFnSI-0005IR-KX
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 14:14:30 +0000
Received: from [85.158.139.83:30922] by server-10.bemta-5.messagelabs.com id
	6C/2F-08260-5C8AD7F4; Thu, 05 Apr 2012 14:14:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333635267!22644082!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11691 invoked from network); 5 Apr 2012 14:14:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 14:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330923600"; d="scan'208";a="189166506"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:14:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 10:14:26 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFnMh-0003AC-9d;
	Thu, 05 Apr 2012 15:08:43 +0100
MIME-Version: 1.0
X-Mercurial-Node: 41ff0907f4a07f1bfa1b2899e885ebf69f24250f
Message-ID: <41ff0907f4a07f1bfa1b.1333634835@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 15:07:15 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] [v2] xl: Don't require a config file for
	cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since the key information can be fairly simply put on the command-line,
there's no need to require an actual config file.

Also improve the help to cross-reference the xlcpupool.cfg manpage.

v2:
- Include link and manpage section for xlcpupool.cfg references.
- Rewrap man page paragraph.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 3d65214aebe4 -r 41ff0907f4a0 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Apr 05 14:04:51 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Apr 05 15:01:59 2012 +0100
@@ -873,11 +873,13 @@ Cpu-pools can be specified either by nam
 
 =over 4
 
-=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile> [I<Variable=Value> ...]
+=item B<cpupool-create> [I<OPTIONS>] [I<ConfigFile>] [I<Variable=Value> ...]
 
-Create a cpu pool based an I<ConfigFile>.
-Variable settings from the I<ConfigFile> may be altered by specifying new
-or additional assignments on the command line.
+Create a cpu pool based an config from a I<ConfigFile> or command-line
+parameters.  Variable settings from the I<ConfigFile> may be altered
+by specifying new or additional assignments on the command line.
+
+See the L<xlcpupool.cfg(5)> manpage for more information.
 
 B<OPTIONS>
 
diff -r 3d65214aebe4 -r 41ff0907f4a0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Apr 05 14:04:51 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Apr 05 15:01:59 2012 +0100
@@ -5556,7 +5556,7 @@ int main_tmem_freeable(int argc, char **
 
 int main_cpupoolcreate(int argc, char **argv)
 {
-    const char *filename = NULL;
+    const char *filename = NULL, *config_src=NULL;
     const char *p;
     char extra_config[1024];
     int opt;
@@ -5620,23 +5620,26 @@ int main_cpupoolcreate(int argc, char **
         optind++;
     }
 
-    if (!filename) {
-        help("cpupool-create");
-        return -ERROR_FAIL;
-    }
-
-    if (libxl_read_file_contents(ctx, filename, (void **)&config_data, &config_len)) {
-        fprintf(stderr, "Failed to read config file: %s: %s\n",
-                filename, strerror(errno));
-        return -ERROR_FAIL;
-    }
+    if (filename)
+    {
+        if (libxl_read_file_contents(ctx, filename, (void **)&config_data,
+                                     &config_len)) {
+            fprintf(stderr, "Failed to read config file: %s: %s\n",
+                    filename, strerror(errno));
+            return -ERROR_FAIL;
+        }
+        config_src=filename;
+    }
+    else
+        config_src="command line";
+
     if (strlen(extra_config)) {
         if (config_len > INT_MAX - (strlen(extra_config) + 2)) {
             fprintf(stderr, "Failed to attach extra configration\n");
             return -ERROR_FAIL;
         }
         config_data = xrealloc(config_data,
-                              config_len + strlen(extra_config) + 2);
+                               config_len + strlen(extra_config) + 2);
         if (!config_data) {
             fprintf(stderr, "Failed to realloc config_data\n");
             return -ERROR_FAIL;
@@ -5647,7 +5650,7 @@ int main_cpupoolcreate(int argc, char **
         config_len += strlen(extra_config) + 1;
     }
 
-    config = xlu_cfg_init(stderr, filename);
+    config = xlu_cfg_init(stderr, config_src);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         return -ERROR_FAIL;
@@ -5661,8 +5664,12 @@ int main_cpupoolcreate(int argc, char **
 
     if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
-    else
+    else if (filename)
         name = libxl_basename(filename);
+    else {
+        fprintf(stderr, "Missing cpupool name!\n");
+        return -ERROR_FAIL;
+    }
     if (!libxl_name_to_cpupoolid(ctx, name, &poolid)) {
         fprintf(stderr, "Pool name \"%s\" already exists\n", name);
         return -ERROR_FAIL;
@@ -5744,7 +5751,7 @@ int main_cpupoolcreate(int argc, char **
 
     libxl_uuid_generate(&uuid);
 
-    printf("Using config file \"%s\"\n", filename);
+    printf("Using config file \"%s\"\n", config_src);
     printf("cpupool name:   %s\n", name);
     printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
diff -r 3d65214aebe4 -r 41ff0907f4a0 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Apr 05 14:04:51 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Apr 05 15:01:59 2012 +0100
@@ -373,12 +373,14 @@ struct cmd_spec cmd_table[] = {
     },
     { "cpupool-create",
       &main_cpupoolcreate, 1,
-      "Create a CPU pool based an ConfigFile",
-      "[options] <ConfigFile> [vars]",
+      "Create a new CPU pool",
+      "[options] [<ConfigFile>] [Variable=value ...]",
       "-h, --help                   Print this help.\n"
       "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
       "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
-      "                              (deprecated in favour of global -N option)."
+      "                              (deprecated in favour of global -N option).\n"
+      "\nSee the xlcpupool.cfg(5) manpage for more information.",
+
     },
     { "cpupool-list",
       &main_cpupoollist, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnSK-0005Ic-MA; Thu, 05 Apr 2012 14:14:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SFnSI-0005IR-KX
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 14:14:30 +0000
Received: from [85.158.139.83:30922] by server-10.bemta-5.messagelabs.com id
	6C/2F-08260-5C8AD7F4; Thu, 05 Apr 2012 14:14:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333635267!22644082!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11691 invoked from network); 5 Apr 2012 14:14:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 14:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330923600"; d="scan'208";a="189166506"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 10:14:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 10:14:26 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SFnMh-0003AC-9d;
	Thu, 05 Apr 2012 15:08:43 +0100
MIME-Version: 1.0
X-Mercurial-Node: 41ff0907f4a07f1bfa1b2899e885ebf69f24250f
Message-ID: <41ff0907f4a07f1bfa1b.1333634835@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Apr 2012 15:07:15 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] [v2] xl: Don't require a config file for
	cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since the key information can be fairly simply put on the command-line,
there's no need to require an actual config file.

Also improve the help to cross-reference the xlcpupool.cfg manpage.

v2:
- Include link and manpage section for xlcpupool.cfg references.
- Rewrap man page paragraph.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 3d65214aebe4 -r 41ff0907f4a0 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Apr 05 14:04:51 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Apr 05 15:01:59 2012 +0100
@@ -873,11 +873,13 @@ Cpu-pools can be specified either by nam
 
 =over 4
 
-=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile> [I<Variable=Value> ...]
+=item B<cpupool-create> [I<OPTIONS>] [I<ConfigFile>] [I<Variable=Value> ...]
 
-Create a cpu pool based an I<ConfigFile>.
-Variable settings from the I<ConfigFile> may be altered by specifying new
-or additional assignments on the command line.
+Create a cpu pool based an config from a I<ConfigFile> or command-line
+parameters.  Variable settings from the I<ConfigFile> may be altered
+by specifying new or additional assignments on the command line.
+
+See the L<xlcpupool.cfg(5)> manpage for more information.
 
 B<OPTIONS>
 
diff -r 3d65214aebe4 -r 41ff0907f4a0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Apr 05 14:04:51 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Apr 05 15:01:59 2012 +0100
@@ -5556,7 +5556,7 @@ int main_tmem_freeable(int argc, char **
 
 int main_cpupoolcreate(int argc, char **argv)
 {
-    const char *filename = NULL;
+    const char *filename = NULL, *config_src=NULL;
     const char *p;
     char extra_config[1024];
     int opt;
@@ -5620,23 +5620,26 @@ int main_cpupoolcreate(int argc, char **
         optind++;
     }
 
-    if (!filename) {
-        help("cpupool-create");
-        return -ERROR_FAIL;
-    }
-
-    if (libxl_read_file_contents(ctx, filename, (void **)&config_data, &config_len)) {
-        fprintf(stderr, "Failed to read config file: %s: %s\n",
-                filename, strerror(errno));
-        return -ERROR_FAIL;
-    }
+    if (filename)
+    {
+        if (libxl_read_file_contents(ctx, filename, (void **)&config_data,
+                                     &config_len)) {
+            fprintf(stderr, "Failed to read config file: %s: %s\n",
+                    filename, strerror(errno));
+            return -ERROR_FAIL;
+        }
+        config_src=filename;
+    }
+    else
+        config_src="command line";
+
     if (strlen(extra_config)) {
         if (config_len > INT_MAX - (strlen(extra_config) + 2)) {
             fprintf(stderr, "Failed to attach extra configration\n");
             return -ERROR_FAIL;
         }
         config_data = xrealloc(config_data,
-                              config_len + strlen(extra_config) + 2);
+                               config_len + strlen(extra_config) + 2);
         if (!config_data) {
             fprintf(stderr, "Failed to realloc config_data\n");
             return -ERROR_FAIL;
@@ -5647,7 +5650,7 @@ int main_cpupoolcreate(int argc, char **
         config_len += strlen(extra_config) + 1;
     }
 
-    config = xlu_cfg_init(stderr, filename);
+    config = xlu_cfg_init(stderr, config_src);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         return -ERROR_FAIL;
@@ -5661,8 +5664,12 @@ int main_cpupoolcreate(int argc, char **
 
     if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
-    else
+    else if (filename)
         name = libxl_basename(filename);
+    else {
+        fprintf(stderr, "Missing cpupool name!\n");
+        return -ERROR_FAIL;
+    }
     if (!libxl_name_to_cpupoolid(ctx, name, &poolid)) {
         fprintf(stderr, "Pool name \"%s\" already exists\n", name);
         return -ERROR_FAIL;
@@ -5744,7 +5751,7 @@ int main_cpupoolcreate(int argc, char **
 
     libxl_uuid_generate(&uuid);
 
-    printf("Using config file \"%s\"\n", filename);
+    printf("Using config file \"%s\"\n", config_src);
     printf("cpupool name:   %s\n", name);
     printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
diff -r 3d65214aebe4 -r 41ff0907f4a0 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Apr 05 14:04:51 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Apr 05 15:01:59 2012 +0100
@@ -373,12 +373,14 @@ struct cmd_spec cmd_table[] = {
     },
     { "cpupool-create",
       &main_cpupoolcreate, 1,
-      "Create a CPU pool based an ConfigFile",
-      "[options] <ConfigFile> [vars]",
+      "Create a new CPU pool",
+      "[options] [<ConfigFile>] [Variable=value ...]",
       "-h, --help                   Print this help.\n"
       "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
       "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
-      "                              (deprecated in favour of global -N option)."
+      "                              (deprecated in favour of global -N option).\n"
+      "\nSee the xlcpupool.cfg(5) manpage for more information.",
+
     },
     { "cpupool-list",
       &main_cpupoollist, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:19:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:19:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnWZ-0005Yw-C1; Thu, 05 Apr 2012 14:18:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnWY-0005Yn-5a
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:18:54 +0000
Received: from [85.158.143.99:19710] by server-1.bemta-4.messagelabs.com id
	2C/90-20925-DC9AD7F4; Thu, 05 Apr 2012 14:18:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333635531!22194364!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12584 invoked from network); 5 Apr 2012 14:18:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:18:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:18:50 +0100
Message-Id: <4F7DC624020000780007CBB8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:19:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
	<4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
	<20120405140839.GG14774@ocelot.phlegethon.org>
In-Reply-To: <20120405140839.GG14774@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
 comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 16:08, Tim Deegan <tim@xen.org> wrote:
> At 14:31 +0100 on 05 Apr (1333636297), Jan Beulich wrote:
>> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
>> > # HG changeset patch
>> > # User Tim Deegan <tim@xen.org>
>> > # Date 1333626954 -3600
>> > # Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
>> > # Parent  0ecf439475e12f185553f42f56f099be5f328cce
>> > x86/mm: Another couple of comparisons of unsigned vars with < 0.
>> > 
>> > Adding the explicit (unsigned) casts in case enums ever end up signed.
>> 
>> Ugly, but unavoidable if range comparisons are done on enums (which
>> is what ought to get fixed instead imo).
> 
> Any suggestions for how?  Turn the array access into a case statement?
> That's even uglier IMO. 

	switch (<enum-var>) {
	case <low> ... <high>:
		break;
	default:
		<bad>;
	}

doesn't look that bad. But when wanting to do range comparisons,
an enum may not be the best choice anyway (for the very reason of
it possible being signed, and signed array indexes generally being
less efficient than unsigned ones), and hence using #define-s and
an "unsigned int" variable might be the better way.

Otoh, doesn't clang have a command line option to control whether
enums are signed or unsigned? I think gcc does.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:19:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:19:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnWZ-0005Yw-C1; Thu, 05 Apr 2012 14:18:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnWY-0005Yn-5a
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:18:54 +0000
Received: from [85.158.143.99:19710] by server-1.bemta-4.messagelabs.com id
	2C/90-20925-DC9AD7F4; Thu, 05 Apr 2012 14:18:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333635531!22194364!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12584 invoked from network); 5 Apr 2012 14:18:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:18:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:18:50 +0100
Message-Id: <4F7DC624020000780007CBB8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:19:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
	<4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
	<20120405140839.GG14774@ocelot.phlegethon.org>
In-Reply-To: <20120405140839.GG14774@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
 comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 16:08, Tim Deegan <tim@xen.org> wrote:
> At 14:31 +0100 on 05 Apr (1333636297), Jan Beulich wrote:
>> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
>> > # HG changeset patch
>> > # User Tim Deegan <tim@xen.org>
>> > # Date 1333626954 -3600
>> > # Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
>> > # Parent  0ecf439475e12f185553f42f56f099be5f328cce
>> > x86/mm: Another couple of comparisons of unsigned vars with < 0.
>> > 
>> > Adding the explicit (unsigned) casts in case enums ever end up signed.
>> 
>> Ugly, but unavoidable if range comparisons are done on enums (which
>> is what ought to get fixed instead imo).
> 
> Any suggestions for how?  Turn the array access into a case statement?
> That's even uglier IMO. 

	switch (<enum-var>) {
	case <low> ... <high>:
		break;
	default:
		<bad>;
	}

doesn't look that bad. But when wanting to do range comparisons,
an enum may not be the best choice anyway (for the very reason of
it possible being signed, and signed array indexes generally being
less efficient than unsigned ones), and hence using #define-s and
an "unsigned int" variable might be the better way.

Otoh, doesn't clang have a command line option to control whether
enums are signed or unsigned? I think gcc does.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnal-0005mY-5z; Thu, 05 Apr 2012 14:23:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnaj-0005mL-AH
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:23:13 +0000
Received: from [85.158.138.51:46674] by server-12.bemta-3.messagelabs.com id
	A2/65-30663-0DAAD7F4; Thu, 05 Apr 2012 14:23:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333635791!20927442!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19680 invoked from network); 5 Apr 2012 14:23:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:23:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:23:11 +0100
Message-Id: <4F7DC727020000780007CBC2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:24:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
	<4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
	<20120405141151.GH14774@ocelot.phlegethon.org>
In-Reply-To: <20120405141151.GH14774@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
 variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 16:11, Tim Deegan <tim@xen.org> wrote:
> At 14:44 +0100 on 05 Apr (1333637053), Jan Beulich wrote:
>> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
>> > x86: explicitly mark an __initdata variable as used.
>> > 
>> > This stops LLVM from replacing it with a different, auto-generated
>> > variable as part of an optimization.  (The auto-generated variable
>> > ends up in the normal data section, failing the check that this
>> > file only contains __initdata vars).
>> > 
>> > Signed-off-by: Tim Deegan <tim@xen.org>
>> > 
>> > diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
>> > --- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
>> > +++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
>> > @@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
>> >      struct domain *d, unsigned long max_pages)
>> >  {
>> >      static unsigned int __initdata last_order = MAX_ORDER;
>> > -    static unsigned int __initdata memflags = MEMF_no_dma;
>> > +    static unsigned int __initdata __attribute__((used)) memflags = 
> MEMF_no_dma;
>> 
>> Without a code comment, the mere fact that this is (a) totally
>> non-obvious, (b) being done differently for two neighboring
>> variables of otherwise the exact same kind, and (c) probably
>> a compiler bug makes it quite likely that your change will get
>> removed again by a future commit.
> 
> Sorry, yes this deserves a code comment.  I'll add one. 
> 
> I agree that this is a compiler bug, but the LLVM developers disagree,
> and I have limited time for arguing with compiler devs.

Which I can well understand.

>> Furthermore, it being needed on one but not the other variable
>> makes it highly likely that the same issue could surface at any
>> time here or elsewhere in the code.
> 
> I considered putting the __attribute__((used)) into the definition of
> __initdata but thought it was more invasive.  I'm happy to reconsider. 

That's a reasonable idea imo, and you may want to do this for
other section placement directives (__read_mostly) too. And then
ideally only for clang (at least for the time being). Maybe we should
even have a __section()-like thing as Linux has (just that we'd likely
want one for text and one for data, so that the attribute wouldn't
needlessly get applied to functions).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnal-0005mY-5z; Thu, 05 Apr 2012 14:23:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFnaj-0005mL-AH
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:23:13 +0000
Received: from [85.158.138.51:46674] by server-12.bemta-3.messagelabs.com id
	A2/65-30663-0DAAD7F4; Thu, 05 Apr 2012 14:23:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333635791!20927442!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19680 invoked from network); 5 Apr 2012 14:23:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 14:23:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 15:23:11 +0100
Message-Id: <4F7DC727020000780007CBC2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 15:24:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5a2f5ab5128e4b13b3fd.1333627639@whitby.uk.xensource.com>
	<4F7DBDCD020000780007CB60@nat28.tlf.novell.com>
	<20120405141151.GH14774@ocelot.phlegethon.org>
In-Reply-To: <20120405141151.GH14774@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86: explicitly mark an __initdata
 variable as used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 16:11, Tim Deegan <tim@xen.org> wrote:
> At 14:44 +0100 on 05 Apr (1333637053), Jan Beulich wrote:
>> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
>> > x86: explicitly mark an __initdata variable as used.
>> > 
>> > This stops LLVM from replacing it with a different, auto-generated
>> > variable as part of an optimization.  (The auto-generated variable
>> > ends up in the normal data section, failing the check that this
>> > file only contains __initdata vars).
>> > 
>> > Signed-off-by: Tim Deegan <tim@xen.org>
>> > 
>> > diff -r 5101e5ed2473 -r 5a2f5ab5128e xen/arch/x86/domain_build.c
>> > --- a/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
>> > +++ b/xen/arch/x86/domain_build.c	Thu Apr 05 12:55:54 2012 +0100
>> > @@ -129,7 +129,7 @@ static struct page_info * __init alloc_c
>> >      struct domain *d, unsigned long max_pages)
>> >  {
>> >      static unsigned int __initdata last_order = MAX_ORDER;
>> > -    static unsigned int __initdata memflags = MEMF_no_dma;
>> > +    static unsigned int __initdata __attribute__((used)) memflags = 
> MEMF_no_dma;
>> 
>> Without a code comment, the mere fact that this is (a) totally
>> non-obvious, (b) being done differently for two neighboring
>> variables of otherwise the exact same kind, and (c) probably
>> a compiler bug makes it quite likely that your change will get
>> removed again by a future commit.
> 
> Sorry, yes this deserves a code comment.  I'll add one. 
> 
> I agree that this is a compiler bug, but the LLVM developers disagree,
> and I have limited time for arguing with compiler devs.

Which I can well understand.

>> Furthermore, it being needed on one but not the other variable
>> makes it highly likely that the same issue could surface at any
>> time here or elsewhere in the code.
> 
> I considered putting the __attribute__((used)) into the definition of
> __initdata but thought it was more invasive.  I'm happy to reconsider. 

That's a reasonable idea imo, and you may want to do this for
other section placement directives (__read_mostly) too. And then
ideally only for clang (at least for the time being). Maybe we should
even have a __section()-like thing as Linux has (just that we'd likely
want one for text and one for data, so that the attribute wouldn't
needlessly get applied to functions).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnbb-0005r6-Jt; Thu, 05 Apr 2012 14:24:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFnba-0005qv-7c
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:24:06 +0000
Received: from [85.158.143.99:56501] by server-1.bemta-4.messagelabs.com id
	F1/2A-20925-50BAD7F4; Thu, 05 Apr 2012 14:24:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333635845!23953261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8269 invoked from network); 5 Apr 2012 14:24:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 14:24:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11797240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 14:24:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 15:24:05 +0100
Date: Thu, 5 Apr 2012 15:26:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4F7D9664.8080406@canonical.com>
Message-ID: <alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Stefan Bader wrote:
> On 05.04.2012 13:02, Stefano Stabellini wrote:
> > On Wed, 4 Apr 2012, Stefan Bader wrote:
> >> Hi Stefano,
> >>
> >> quite a while back in time, you and Konrad had a discussion about some HVM setup
> >> problems via libvirt. One part was graphics and the problem seemed to be that
> >> when creating a new instance through xend for HVM, the use of vfb was wrong. It
> >> mostly does work but then also defines a vkbd which takes a long time in the
> >> xenbus setup to finally fail.
> >>
> >> Because this was not a really fatal problem it did take a long time to actually
> >> get back to it. But now I had a look and found that libvirt indeed does use the
> >> vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> >> create guests). The decision is made based on the xend version number in the HVM
> >> case. Which would be wrong if I did understand your reply correctly.
> >>
> >> I have been testing a patch to libvirt, which would not use a vfb definition
> >> whenever HVM is used (regardless of xend version). And it does seem to work (xm
> >> list -l however has a vfb device definition, but the same happens when creating
> >> the instance with a xm style config file that definitely has no vfb section in
> >> it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> >> to make sure the solution for libvirt is correct for even the current Xen version.
> >>
> >> So in short, is this always correct?
> >>
> >> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
> >>    do not define a vfb device
> >> else /* PVM and xend version >= 3 */
> >>    define a vfb device
> > 
> > vkbd and vfb can be considered optimizations for PV on HVM guests.
> > No PV on HVM guest that I know should be able to use vfb right now, but
> > Linux should be able to use vkbd since:
> > 
> > commit 5f098ecd4288333d87e2293239fab1c13ec90dae
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date:   Mon Jul 4 19:22:00 2011 -0700
> > 
> >     Input: xen-kbdfront - enable driver for HVM guests
> >     
> >     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> > 
> > XL in xen-unstable enables vkbd for HVM guests so that you can have
> > keyboard and mouse without usb emulation (that eats significant
> > resources in dom0).
> > 
> > That said, vkbd is just a (small) optimization, it is far more
> > important to get rid of the very annoying wait time at bootup.
> > Rather than messing with libvirt and xend I would fix it from the Linux
> > side, see the following thread:
> > 
> > http://marc.info/?l=xen-devel&m=133238564132683&w=2
> 
> That would work as well. The downside being that this modification then has to
> go in any kernels between 3.1 and the patch. The approach from the other side
> seemed to make sense so far as it changes generated output that seems targeted
> only at talking to xend. The xen-xm format looks to be usable for xl too. But I
> would suspect that whenever libvirt starts to support xen api/xl/libxen it will
> be using a different interface which then could make use of vfb and vkbd.
> 
> Of course that does not make the change in the kernel less valuable. It prevents
> the wait time whenever someone manually configures things with vfb.
> It just seems to be useless to generate a config that has no use for an
> interface that does not support it.

Nobody is using vfb right now, but vkbd is already enabled in Linux.
This is why it is not that clear to me what we should do on the xend
side: are we going to disable vfb and keep vkbd?

In any case, as I said before, if the alternatives are keeping the wait
time or patching xend, I would go for patching xend.
If we don't think we can fix Linux and backport the fix in a reasonable
time, patching xend might be the only option.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnbb-0005r6-Jt; Thu, 05 Apr 2012 14:24:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFnba-0005qv-7c
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 14:24:06 +0000
Received: from [85.158.143.99:56501] by server-1.bemta-4.messagelabs.com id
	F1/2A-20925-50BAD7F4; Thu, 05 Apr 2012 14:24:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333635845!23953261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8269 invoked from network); 5 Apr 2012 14:24:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 14:24:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11797240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 14:24:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 15:24:05 +0100
Date: Thu, 5 Apr 2012 15:26:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4F7D9664.8080406@canonical.com>
Message-ID: <alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Stefan Bader wrote:
> On 05.04.2012 13:02, Stefano Stabellini wrote:
> > On Wed, 4 Apr 2012, Stefan Bader wrote:
> >> Hi Stefano,
> >>
> >> quite a while back in time, you and Konrad had a discussion about some HVM setup
> >> problems via libvirt. One part was graphics and the problem seemed to be that
> >> when creating a new instance through xend for HVM, the use of vfb was wrong. It
> >> mostly does work but then also defines a vkbd which takes a long time in the
> >> xenbus setup to finally fail.
> >>
> >> Because this was not a really fatal problem it did take a long time to actually
> >> get back to it. But now I had a look and found that libvirt indeed does use the
> >> vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> >> create guests). The decision is made based on the xend version number in the HVM
> >> case. Which would be wrong if I did understand your reply correctly.
> >>
> >> I have been testing a patch to libvirt, which would not use a vfb definition
> >> whenever HVM is used (regardless of xend version). And it does seem to work (xm
> >> list -l however has a vfb device definition, but the same happens when creating
> >> the instance with a xm style config file that definitely has no vfb section in
> >> it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> >> to make sure the solution for libvirt is correct for even the current Xen version.
> >>
> >> So in short, is this always correct?
> >>
> >> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
> >>    do not define a vfb device
> >> else /* PVM and xend version >= 3 */
> >>    define a vfb device
> > 
> > vkbd and vfb can be considered optimizations for PV on HVM guests.
> > No PV on HVM guest that I know should be able to use vfb right now, but
> > Linux should be able to use vkbd since:
> > 
> > commit 5f098ecd4288333d87e2293239fab1c13ec90dae
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date:   Mon Jul 4 19:22:00 2011 -0700
> > 
> >     Input: xen-kbdfront - enable driver for HVM guests
> >     
> >     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> > 
> > XL in xen-unstable enables vkbd for HVM guests so that you can have
> > keyboard and mouse without usb emulation (that eats significant
> > resources in dom0).
> > 
> > That said, vkbd is just a (small) optimization, it is far more
> > important to get rid of the very annoying wait time at bootup.
> > Rather than messing with libvirt and xend I would fix it from the Linux
> > side, see the following thread:
> > 
> > http://marc.info/?l=xen-devel&m=133238564132683&w=2
> 
> That would work as well. The downside being that this modification then has to
> go in any kernels between 3.1 and the patch. The approach from the other side
> seemed to make sense so far as it changes generated output that seems targeted
> only at talking to xend. The xen-xm format looks to be usable for xl too. But I
> would suspect that whenever libvirt starts to support xen api/xl/libxen it will
> be using a different interface which then could make use of vfb and vkbd.
> 
> Of course that does not make the change in the kernel less valuable. It prevents
> the wait time whenever someone manually configures things with vfb.
> It just seems to be useless to generate a config that has no use for an
> interface that does not support it.

Nobody is using vfb right now, but vkbd is already enabled in Linux.
This is why it is not that clear to me what we should do on the xend
side: are we going to disable vfb and keep vkbd?

In any case, as I said before, if the alternatives are keeping the wait
time or patching xend, I would go for patching xend.
If we don't think we can fix Linux and backport the fix in a reasonable
time, patching xend might be the only option.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:42:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnsd-0006B6-7V; Thu, 05 Apr 2012 14:41:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFnsc-0006B1-GZ
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 14:41:42 +0000
Received: from [85.158.143.35:31758] by server-2.bemta-4.messagelabs.com id
	DA/99-17550-52FAD7F4; Thu, 05 Apr 2012 14:41:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333636901!8741368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32369 invoked from network); 5 Apr 2012 14:41:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 14:41:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11797911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 14:41:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 15:41:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFnsa-0004Qs-GM; Thu, 05 Apr 2012 14:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFnsa-0002bA-CN;
	Thu, 05 Apr 2012 15:41:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20349.44836.366233.162318@mariner.uk.xensource.com>
Date: Thu, 5 Apr 2012 15:41:40 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> 
> > -----Original Message-----
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > Sent: Tuesday, April 03, 2012 1:01 AM
> > To: Hao, Xudong
> > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> > devices not owned by pciback
> > 
> > Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing
> > through devices not owned by pciback"):
> > > <Porting from Xen 4.1 tree.>
> > >
> > > libxl: passthrough: avoid passing through devices not owned by pciback
> > 
> > I'm afraid this no longer applies to xen-unstable.hg tip.
> > 
> Reason?
> 
> If no pciback checking, one device could be assigned to guest even it's being used by dom0, is there security issue?

I mean that it has conflicts when I try to apply it.  You need to
refresh it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 14:42:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 14:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFnsd-0006B6-7V; Thu, 05 Apr 2012 14:41:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFnsc-0006B1-GZ
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 14:41:42 +0000
Received: from [85.158.143.35:31758] by server-2.bemta-4.messagelabs.com id
	DA/99-17550-52FAD7F4; Thu, 05 Apr 2012 14:41:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1333636901!8741368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32369 invoked from network); 5 Apr 2012 14:41:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 14:41:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11797911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 14:41:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 15:41:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFnsa-0004Qs-GM; Thu, 05 Apr 2012 14:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFnsa-0002bA-CN;
	Thu, 05 Apr 2012 15:41:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20349.44836.366233.162318@mariner.uk.xensource.com>
Date: Thu, 5 Apr 2012 15:41:40 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> 
> > -----Original Message-----
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > Sent: Tuesday, April 03, 2012 1:01 AM
> > To: Hao, Xudong
> > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> > devices not owned by pciback
> > 
> > Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid passing
> > through devices not owned by pciback"):
> > > <Porting from Xen 4.1 tree.>
> > >
> > > libxl: passthrough: avoid passing through devices not owned by pciback
> > 
> > I'm afraid this no longer applies to xen-unstable.hg tip.
> > 
> Reason?
> 
> If no pciback checking, one device could be assigned to guest even it's being used by dom0, is there security issue?

I mean that it has conflicts when I try to apply it.  You need to
refresh it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:04:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoEB-0006Qu-6L; Thu, 05 Apr 2012 15:03:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFoEA-0006Qp-BC
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:03:58 +0000
Received: from [85.158.139.83:43903] by server-8.bemta-5.messagelabs.com id
	33/81-26964-D54BD7F4; Thu, 05 Apr 2012 15:03:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333638236!22654608!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11337 invoked from network); 5 Apr 2012 15:03:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:03:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 16:03:56 +0100
Message-Id: <4F7DD0B4020000780007CBF0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 16:04:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-blkfront: module exit handling adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The blkdev major must be released upon exit, or else the module can't
attach to devices using the same majors upon being loaded again. Also
avoid leaking the minor tracking bitmap.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkfront.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- 3.4-rc1/drivers/block/xen-blkfront.c
+++ 3.4-rc1-xen-blkfront-exit-cleanup/drivers/block/xen-blkfront.c
@@ -1497,7 +1497,9 @@ module_init(xlblk_init);
 
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront_driver);
+	xenbus_unregister_driver(&blkfront_driver);
+	unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
+	kfree(minors);
 }
 module_exit(xlblk_exit);
 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:04:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoEB-0006Qu-6L; Thu, 05 Apr 2012 15:03:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFoEA-0006Qp-BC
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:03:58 +0000
Received: from [85.158.139.83:43903] by server-8.bemta-5.messagelabs.com id
	33/81-26964-D54BD7F4; Thu, 05 Apr 2012 15:03:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333638236!22654608!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11337 invoked from network); 5 Apr 2012 15:03:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:03:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 16:03:56 +0100
Message-Id: <4F7DD0B4020000780007CBF0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 16:04:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-blkfront: module exit handling adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The blkdev major must be released upon exit, or else the module can't
attach to devices using the same majors upon being loaded again. Also
avoid leaking the minor tracking bitmap.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkfront.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- 3.4-rc1/drivers/block/xen-blkfront.c
+++ 3.4-rc1-xen-blkfront-exit-cleanup/drivers/block/xen-blkfront.c
@@ -1497,7 +1497,9 @@ module_init(xlblk_init);
 
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront_driver);
+	xenbus_unregister_driver(&blkfront_driver);
+	unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
+	kfree(minors);
 }
 module_exit(xlblk_exit);
 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:09:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoJR-0006ZM-U9; Thu, 05 Apr 2012 15:09:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFoJP-0006ZA-U4
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:09:24 +0000
Received: from [85.158.139.83:60074] by server-11.bemta-5.messagelabs.com id
	03/D4-12959-3A5BD7F4; Thu, 05 Apr 2012 15:09:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333638550!22115324!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18061 invoked from network); 5 Apr 2012 15:09:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:09:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 16:09:10 +0100
Message-Id: <4F7DD1EF020000780007CC05@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 16:10:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/gnttab: add deferred freeing logic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rather than just leaking pages that can't be freed at the point where
access permission for the backend domain gets revoked, put them on a
list and run a timer to (infrequently) retry freeing them. (This can
particularly happen when unloading a frontend driver when devices are
still present, and the backend still has them in non-closed state or
hasn't finished closing them yet.)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/grant-table.c |  106 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 96 insertions(+), 10 deletions(-)

--- 3.4-rc1/drivers/xen/grant-table.c
+++ 3.4-rc1-xen-gnttab-deferred-end-access/drivers/xen/grant-table.c
@@ -426,10 +426,8 @@ static int gnttab_end_foreign_access_ref
 	nflags = *pflags;
 	do {
 		flags = nflags;
-		if (flags & (GTF_reading|GTF_writing)) {
-			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
+		if (flags & (GTF_reading|GTF_writing))
 			return 0;
-		}
 	} while ((nflags = sync_cmpxchg(pflags, flags, 0)) != flags);
 
 	return 1;
@@ -458,12 +456,103 @@ static int gnttab_end_foreign_access_ref
 	return 1;
 }
 
-int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+static inline int _gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+	if (_gnttab_end_foreign_access_ref(ref, readonly))
+		return 1;
+	pr_warn("WARNING: g.e. %#x still in use!\n", ref);
+	return 0;
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
 
+struct deferred_entry {
+	struct list_head list;
+	grant_ref_t ref;
+	bool ro;
+	uint16_t warn_delay;
+	struct page *page;
+};
+static LIST_HEAD(deferred_list);
+static void gnttab_handle_deferred(unsigned long);
+static DEFINE_TIMER(deferred_timer, gnttab_handle_deferred, 0, 0);
+
+static void gnttab_handle_deferred(unsigned long unused)
+{
+	unsigned int nr = 10;
+	struct deferred_entry *first = NULL;
+	unsigned long flags;
+
+	spin_lock_irqsave(&gnttab_list_lock, flags);
+	while (nr--) {
+		struct deferred_entry *entry
+			= list_first_entry(&deferred_list,
+					   struct deferred_entry, list);
+
+		if (entry == first)
+			break;
+		list_del(&entry->list);
+		spin_unlock_irqrestore(&gnttab_list_lock, flags);
+		if (_gnttab_end_foreign_access_ref(entry->ref, entry->ro)) {
+			put_free_entry(entry->ref);
+			if (entry->page) {
+				pr_debug("freeing g.e. %#x (pfn %#lx)\n",
+					 entry->ref, page_to_pfn(entry->page));
+				__free_page(entry->page);
+			} else
+				pr_info("freeing g.e. %#x\n", entry->ref);
+			kfree(entry);
+			entry = NULL;
+		} else {
+			if (!--entry->warn_delay)
+				pr_info("g.e. %#x still pending\n",
+					entry->ref);
+			if (!first)
+				first = entry;
+		}
+		spin_lock_irqsave(&gnttab_list_lock, flags);
+		if (entry)
+			list_add_tail(&entry->list, &deferred_list);
+		else if (list_empty(&deferred_list))
+			break;
+	}
+	if (!list_empty(&deferred_list) && !timer_pending(&deferred_timer)) {
+		deferred_timer.expires = jiffies + HZ;
+		add_timer(&deferred_timer);
+	}
+	spin_unlock_irqrestore(&gnttab_list_lock, flags);
+}
+
+static void gnttab_add_deferred(grant_ref_t ref, bool readonly,
+				struct page *page)
+{
+	struct deferred_entry *entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+	const char *what = KERN_WARNING "leaking";
+
+	if (entry) {
+		unsigned long flags;
+
+		entry->ref = ref;
+		entry->ro = readonly;
+		entry->page = page;
+		entry->warn_delay = 60;
+		spin_lock_irqsave(&gnttab_list_lock, flags);
+		list_add_tail(&entry->list, &deferred_list);
+		if (!timer_pending(&deferred_timer)) {
+			deferred_timer.expires = jiffies + HZ;
+			add_timer(&deferred_timer);
+		}
+		spin_unlock_irqrestore(&gnttab_list_lock, flags);
+		what = KERN_DEBUG "deferring";
+	}
+	printk("%s g.e. %#x (pfn %#lx)\n",
+	       what, ref, page ? page_to_pfn(page) : -1);
+}
+
 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
 			       unsigned long page)
 {
@@ -471,12 +560,9 @@ void gnttab_end_foreign_access(grant_ref
 		put_free_entry(ref);
 		if (page != 0)
 			free_page(page);
-	} else {
-		/* XXX This needs to be fixed so that the ref and page are
-		   placed on a list to be freed up later. */
-		printk(KERN_WARNING
-		       "WARNING: leaking g.e. and page still in use!\n");
-	}
+	} else
+		gnttab_add_deferred(ref, readonly,
+				    page ? virt_to_page(page) : NULL);
 }
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:09:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoJR-0006ZM-U9; Thu, 05 Apr 2012 15:09:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFoJP-0006ZA-U4
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:09:24 +0000
Received: from [85.158.139.83:60074] by server-11.bemta-5.messagelabs.com id
	03/D4-12959-3A5BD7F4; Thu, 05 Apr 2012 15:09:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1333638550!22115324!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18061 invoked from network); 5 Apr 2012 15:09:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:09:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 16:09:10 +0100
Message-Id: <4F7DD1EF020000780007CC05@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 16:10:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/gnttab: add deferred freeing logic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rather than just leaking pages that can't be freed at the point where
access permission for the backend domain gets revoked, put them on a
list and run a timer to (infrequently) retry freeing them. (This can
particularly happen when unloading a frontend driver when devices are
still present, and the backend still has them in non-closed state or
hasn't finished closing them yet.)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/grant-table.c |  106 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 96 insertions(+), 10 deletions(-)

--- 3.4-rc1/drivers/xen/grant-table.c
+++ 3.4-rc1-xen-gnttab-deferred-end-access/drivers/xen/grant-table.c
@@ -426,10 +426,8 @@ static int gnttab_end_foreign_access_ref
 	nflags = *pflags;
 	do {
 		flags = nflags;
-		if (flags & (GTF_reading|GTF_writing)) {
-			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
+		if (flags & (GTF_reading|GTF_writing))
 			return 0;
-		}
 	} while ((nflags = sync_cmpxchg(pflags, flags, 0)) != flags);
 
 	return 1;
@@ -458,12 +456,103 @@ static int gnttab_end_foreign_access_ref
 	return 1;
 }
 
-int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+static inline int _gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+	if (_gnttab_end_foreign_access_ref(ref, readonly))
+		return 1;
+	pr_warn("WARNING: g.e. %#x still in use!\n", ref);
+	return 0;
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
 
+struct deferred_entry {
+	struct list_head list;
+	grant_ref_t ref;
+	bool ro;
+	uint16_t warn_delay;
+	struct page *page;
+};
+static LIST_HEAD(deferred_list);
+static void gnttab_handle_deferred(unsigned long);
+static DEFINE_TIMER(deferred_timer, gnttab_handle_deferred, 0, 0);
+
+static void gnttab_handle_deferred(unsigned long unused)
+{
+	unsigned int nr = 10;
+	struct deferred_entry *first = NULL;
+	unsigned long flags;
+
+	spin_lock_irqsave(&gnttab_list_lock, flags);
+	while (nr--) {
+		struct deferred_entry *entry
+			= list_first_entry(&deferred_list,
+					   struct deferred_entry, list);
+
+		if (entry == first)
+			break;
+		list_del(&entry->list);
+		spin_unlock_irqrestore(&gnttab_list_lock, flags);
+		if (_gnttab_end_foreign_access_ref(entry->ref, entry->ro)) {
+			put_free_entry(entry->ref);
+			if (entry->page) {
+				pr_debug("freeing g.e. %#x (pfn %#lx)\n",
+					 entry->ref, page_to_pfn(entry->page));
+				__free_page(entry->page);
+			} else
+				pr_info("freeing g.e. %#x\n", entry->ref);
+			kfree(entry);
+			entry = NULL;
+		} else {
+			if (!--entry->warn_delay)
+				pr_info("g.e. %#x still pending\n",
+					entry->ref);
+			if (!first)
+				first = entry;
+		}
+		spin_lock_irqsave(&gnttab_list_lock, flags);
+		if (entry)
+			list_add_tail(&entry->list, &deferred_list);
+		else if (list_empty(&deferred_list))
+			break;
+	}
+	if (!list_empty(&deferred_list) && !timer_pending(&deferred_timer)) {
+		deferred_timer.expires = jiffies + HZ;
+		add_timer(&deferred_timer);
+	}
+	spin_unlock_irqrestore(&gnttab_list_lock, flags);
+}
+
+static void gnttab_add_deferred(grant_ref_t ref, bool readonly,
+				struct page *page)
+{
+	struct deferred_entry *entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+	const char *what = KERN_WARNING "leaking";
+
+	if (entry) {
+		unsigned long flags;
+
+		entry->ref = ref;
+		entry->ro = readonly;
+		entry->page = page;
+		entry->warn_delay = 60;
+		spin_lock_irqsave(&gnttab_list_lock, flags);
+		list_add_tail(&entry->list, &deferred_list);
+		if (!timer_pending(&deferred_timer)) {
+			deferred_timer.expires = jiffies + HZ;
+			add_timer(&deferred_timer);
+		}
+		spin_unlock_irqrestore(&gnttab_list_lock, flags);
+		what = KERN_DEBUG "deferring";
+	}
+	printk("%s g.e. %#x (pfn %#lx)\n",
+	       what, ref, page ? page_to_pfn(page) : -1);
+}
+
 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
 			       unsigned long page)
 {
@@ -471,12 +560,9 @@ void gnttab_end_foreign_access(grant_ref
 		put_free_entry(ref);
 		if (page != 0)
 			free_page(page);
-	} else {
-		/* XXX This needs to be fixed so that the ref and page are
-		   placed on a list to be freed up later. */
-		printk(KERN_WARNING
-		       "WARNING: leaking g.e. and page still in use!\n");
-	}
+	} else
+		gnttab_add_deferred(ref, readonly,
+				    page ? virt_to_page(page) : NULL);
 }
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:15:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoPG-0006mZ-Ne; Thu, 05 Apr 2012 15:15:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFoPE-0006mS-PP
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:15:25 +0000
Received: from [85.158.143.99:65118] by server-3.bemta-4.messagelabs.com id
	23/67-05853-C07BD7F4; Thu, 05 Apr 2012 15:15:24 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333638922!17233563!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9245 invoked from network); 5 Apr 2012 15:15:22 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-4.tower-216.messagelabs.com with SMTP;
	5 Apr 2012 15:15:22 -0000
Received: from p5b2e2631.dip.t-dialin.net ([91.46.38.49] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFoPB-0005ty-BQ; Thu, 05 Apr 2012 15:15:21 +0000
Message-ID: <4F7DB706.5010909@canonical.com>
Date: Thu, 05 Apr 2012 17:15:18 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
	<alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2928090477756891074=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2928090477756891074==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig73B8E73C3E5D12671FAFA157"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig73B8E73C3E5D12671FAFA157
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 05.04.2012 16:26, Stefano Stabellini wrote:
> On Thu, 5 Apr 2012, Stefan Bader wrote:
>> On 05.04.2012 13:02, Stefano Stabellini wrote:
>>> On Wed, 4 Apr 2012, Stefan Bader wrote:
>>>> Hi Stefano,
>>>>
>>>> quite a while back in time, you and Konrad had a discussion about so=
me HVM setup
>>>> problems via libvirt. One part was graphics and the problem seemed t=
o be that
>>>> when creating a new instance through xend for HVM, the use of vfb wa=
s wrong. It
>>>> mostly does work but then also defines a vkbd which takes a long tim=
e in the
>>>> xenbus setup to finally fail.
>>>>
>>>> Because this was not a really fatal problem it did take a long time =
to actually
>>>> get back to it. But now I had a look and found that libvirt indeed d=
oes use the
>>>> vfb form for both the xen-xm and xen-sxpr formats (the latter being =
used to
>>>> create guests). The decision is made based on the xend version numbe=
r in the HVM
>>>> case. Which would be wrong if I did understand your reply correctly.=

>>>>
>>>> I have been testing a patch to libvirt, which would not use a vfb de=
finition
>>>> whenever HVM is used (regardless of xend version). And it does seem =
to work (xm
>>>> list -l however has a vfb device definition, but the same happens wh=
en creating
>>>> the instance with a xm style config file that definitely has no vfb =
section in
>>>> it). But I am testing based on our 12.04 release which uses Xen 4.1.=
2. So I want
>>>> to make sure the solution for libvirt is correct for even the curren=
t Xen version.
>>>>
>>>> So in short, is this always correct?
>>>>
>>>> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>>>>    do not define a vfb device
>>>> else /* PVM and xend version >=3D 3 */
>>>>    define a vfb device
>>>
>>> vkbd and vfb can be considered optimizations for PV on HVM guests.
>>> No PV on HVM guest that I know should be able to use vfb right now, b=
ut
>>> Linux should be able to use vkbd since:
>>>
>>> commit 5f098ecd4288333d87e2293239fab1c13ec90dae
>>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Date:   Mon Jul 4 19:22:00 2011 -0700
>>>
>>>     Input: xen-kbdfront - enable driver for HVM guests
>>>    =20
>>>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.c=
om>
>>>     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>>>
>>> XL in xen-unstable enables vkbd for HVM guests so that you can have
>>> keyboard and mouse without usb emulation (that eats significant
>>> resources in dom0).
>>>
>>> That said, vkbd is just a (small) optimization, it is far more
>>> important to get rid of the very annoying wait time at bootup.
>>> Rather than messing with libvirt and xend I would fix it from the Lin=
ux
>>> side, see the following thread:
>>>
>>> http://marc.info/?l=3Dxen-devel&m=3D133238564132683&w=3D2
>>
>> That would work as well. The downside being that this modification the=
n has to
>> go in any kernels between 3.1 and the patch. The approach from the oth=
er side
>> seemed to make sense so far as it changes generated output that seems =
targeted
>> only at talking to xend. The xen-xm format looks to be usable for xl t=
oo. But I
>> would suspect that whenever libvirt starts to support xen api/xl/libxe=
n it will
>> be using a different interface which then could make use of vfb and vk=
bd.
>>
>> Of course that does not make the change in the kernel less valuable. I=
t prevents
>> the wait time whenever someone manually configures things with vfb.
>> It just seems to be useless to generate a config that has no use for a=
n
>> interface that does not support it.
>=20
> Nobody is using vfb right now, but vkbd is already enabled in Linux.
> This is why it is not that clear to me what we should do on the xend
> side: are we going to disable vfb and keep vkbd?
>
> In any case, as I said before, if the alternatives are keeping the wait=

> time or patching xend, I would go for patching xend.
> If we don't think we can fix Linux and backport the fix in a reasonable=

> time, patching xend might be the only option.

My impression is that you (the generic you) would not really want to modi=
fy xend
too much as it and the xm stack should go away anyway.
Instead I would fix libvirt's use of xend when it is known that it is not=

working well (if using "vfb =3D [ 'vnc=3D1, ...' ]" or similar for sxpr i=
s creating
a vkbd and xend/the xm stack does not support it, then just don't use it)=
=2E

The question of removing the delays is not so much (well yes it is too, b=
ut not
always in ones own hands) whether it can be done or how quickly. Providin=
g the
means to run guests is something rather under our control. Be it Ubuntu a=
s dom0
or Xenserver. But which kernels are run as guests is not.

So, as long as xend does not change its behavior, then changing libvirt i=
n a way
that does never use the configuration format which causes a vkbd to be cr=
eated
(for HVM) is ok. And if it gets picked up upstream it helps all users of =
libvirt
the same.
But if xend would change to allow using a vkbd, then it would be good if =
that
could be synced with a xend version change which could be used inside lib=
virt to
modify its config output (as it does now but in some way with the wrong v=
ersion).

The kernel change to remove delays imo is a completely separate issue. An=
d if
just as an additional "pre-caution".


--------------enig73B8E73C3E5D12671FAFA157
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfbcHAAoJEOhnXe7L7s6j+G8QAJ2JbOJUsKhEipQcZb/WgqW3
zWIoptqSk/Nfk3qVcOQZkTsQObM96Y5RXscODJq8QtSE1EP8fJa8FGXMefCqqJxD
d1YJ+LT/4Xqfs0/1R9lzPC2+hbpnBOogU05N3KutxWpLmONC0V4JR5bCtD1CzFvh
CI2UvBz01wpYKMkP5rHWHeUSPvzDMbDA8VILBXpmiSOt4FMiMsSdA8HB5sFMkw/T
1l3x8jaTHXWUoI3+B/8xauaqrnNlZQE0A4bi3j/YOzGmqx3i1wwbJwuMzuVSGRck
NG9j2cnUY5liFmJrAltdPFhiejZnn9KijbXVOKBoWg3xIJuVocZ9eUCWGZkTnxGS
DahaKckcdpsRLztFCXrFz8wpTkLJYGH1+KuYSVwdsyQcQZ0s84W7bBMZ79pi7680
jZYui7URgC5FHFHeOXHFKizCL2FtLujgDSi+0AG29sAH5wksLWB3ixIEoMEmWu+m
2OUdTXP+a0Lu5GpI8bIOIOtfkuxGrdzQQV03ayIkufQXKZBoDiDA0qakjYccpQH1
e/zyOgH27rg1WgTc51zPgsLfeKDtqn/ro46nHMG8xm7MwDtI+Bzy4blkSvW8+3jl
Zxi7Nui/4Px946hoPrzn/t5csVnMqa8rYLWST1ZGHdvvCDfXn8C+pksRb7+8bEPh
TTQC8u9I/Prvzsg+OFai
=YLnV
-----END PGP SIGNATURE-----

--------------enig73B8E73C3E5D12671FAFA157--


--===============2928090477756891074==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2928090477756891074==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 15:15:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoPG-0006mZ-Ne; Thu, 05 Apr 2012 15:15:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFoPE-0006mS-PP
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:15:25 +0000
Received: from [85.158.143.99:65118] by server-3.bemta-4.messagelabs.com id
	23/67-05853-C07BD7F4; Thu, 05 Apr 2012 15:15:24 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1333638922!17233563!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9245 invoked from network); 5 Apr 2012 15:15:22 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-4.tower-216.messagelabs.com with SMTP;
	5 Apr 2012 15:15:22 -0000
Received: from p5b2e2631.dip.t-dialin.net ([91.46.38.49] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFoPB-0005ty-BQ; Thu, 05 Apr 2012 15:15:21 +0000
Message-ID: <4F7DB706.5010909@canonical.com>
Date: Thu, 05 Apr 2012 17:15:18 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
	<alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2928090477756891074=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2928090477756891074==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig73B8E73C3E5D12671FAFA157"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig73B8E73C3E5D12671FAFA157
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 05.04.2012 16:26, Stefano Stabellini wrote:
> On Thu, 5 Apr 2012, Stefan Bader wrote:
>> On 05.04.2012 13:02, Stefano Stabellini wrote:
>>> On Wed, 4 Apr 2012, Stefan Bader wrote:
>>>> Hi Stefano,
>>>>
>>>> quite a while back in time, you and Konrad had a discussion about so=
me HVM setup
>>>> problems via libvirt. One part was graphics and the problem seemed t=
o be that
>>>> when creating a new instance through xend for HVM, the use of vfb wa=
s wrong. It
>>>> mostly does work but then also defines a vkbd which takes a long tim=
e in the
>>>> xenbus setup to finally fail.
>>>>
>>>> Because this was not a really fatal problem it did take a long time =
to actually
>>>> get back to it. But now I had a look and found that libvirt indeed d=
oes use the
>>>> vfb form for both the xen-xm and xen-sxpr formats (the latter being =
used to
>>>> create guests). The decision is made based on the xend version numbe=
r in the HVM
>>>> case. Which would be wrong if I did understand your reply correctly.=

>>>>
>>>> I have been testing a patch to libvirt, which would not use a vfb de=
finition
>>>> whenever HVM is used (regardless of xend version). And it does seem =
to work (xm
>>>> list -l however has a vfb device definition, but the same happens wh=
en creating
>>>> the instance with a xm style config file that definitely has no vfb =
section in
>>>> it). But I am testing based on our 12.04 release which uses Xen 4.1.=
2. So I want
>>>> to make sure the solution for libvirt is correct for even the curren=
t Xen version.
>>>>
>>>> So in short, is this always correct?
>>>>
>>>> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>>>>    do not define a vfb device
>>>> else /* PVM and xend version >=3D 3 */
>>>>    define a vfb device
>>>
>>> vkbd and vfb can be considered optimizations for PV on HVM guests.
>>> No PV on HVM guest that I know should be able to use vfb right now, b=
ut
>>> Linux should be able to use vkbd since:
>>>
>>> commit 5f098ecd4288333d87e2293239fab1c13ec90dae
>>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Date:   Mon Jul 4 19:22:00 2011 -0700
>>>
>>>     Input: xen-kbdfront - enable driver for HVM guests
>>>    =20
>>>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.c=
om>
>>>     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>>>
>>> XL in xen-unstable enables vkbd for HVM guests so that you can have
>>> keyboard and mouse without usb emulation (that eats significant
>>> resources in dom0).
>>>
>>> That said, vkbd is just a (small) optimization, it is far more
>>> important to get rid of the very annoying wait time at bootup.
>>> Rather than messing with libvirt and xend I would fix it from the Lin=
ux
>>> side, see the following thread:
>>>
>>> http://marc.info/?l=3Dxen-devel&m=3D133238564132683&w=3D2
>>
>> That would work as well. The downside being that this modification the=
n has to
>> go in any kernels between 3.1 and the patch. The approach from the oth=
er side
>> seemed to make sense so far as it changes generated output that seems =
targeted
>> only at talking to xend. The xen-xm format looks to be usable for xl t=
oo. But I
>> would suspect that whenever libvirt starts to support xen api/xl/libxe=
n it will
>> be using a different interface which then could make use of vfb and vk=
bd.
>>
>> Of course that does not make the change in the kernel less valuable. I=
t prevents
>> the wait time whenever someone manually configures things with vfb.
>> It just seems to be useless to generate a config that has no use for a=
n
>> interface that does not support it.
>=20
> Nobody is using vfb right now, but vkbd is already enabled in Linux.
> This is why it is not that clear to me what we should do on the xend
> side: are we going to disable vfb and keep vkbd?
>
> In any case, as I said before, if the alternatives are keeping the wait=

> time or patching xend, I would go for patching xend.
> If we don't think we can fix Linux and backport the fix in a reasonable=

> time, patching xend might be the only option.

My impression is that you (the generic you) would not really want to modi=
fy xend
too much as it and the xm stack should go away anyway.
Instead I would fix libvirt's use of xend when it is known that it is not=

working well (if using "vfb =3D [ 'vnc=3D1, ...' ]" or similar for sxpr i=
s creating
a vkbd and xend/the xm stack does not support it, then just don't use it)=
=2E

The question of removing the delays is not so much (well yes it is too, b=
ut not
always in ones own hands) whether it can be done or how quickly. Providin=
g the
means to run guests is something rather under our control. Be it Ubuntu a=
s dom0
or Xenserver. But which kernels are run as guests is not.

So, as long as xend does not change its behavior, then changing libvirt i=
n a way
that does never use the configuration format which causes a vkbd to be cr=
eated
(for HVM) is ok. And if it gets picked up upstream it helps all users of =
libvirt
the same.
But if xend would change to allow using a vkbd, then it would be good if =
that
could be synced with a xend version change which could be used inside lib=
virt to
modify its config output (as it does now but in some way with the wrong v=
ersion).

The kernel change to remove delays imo is a completely separate issue. An=
d if
just as an additional "pre-caution".


--------------enig73B8E73C3E5D12671FAFA157
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfbcHAAoJEOhnXe7L7s6j+G8QAJ2JbOJUsKhEipQcZb/WgqW3
zWIoptqSk/Nfk3qVcOQZkTsQObM96Y5RXscODJq8QtSE1EP8fJa8FGXMefCqqJxD
d1YJ+LT/4Xqfs0/1R9lzPC2+hbpnBOogU05N3KutxWpLmONC0V4JR5bCtD1CzFvh
CI2UvBz01wpYKMkP5rHWHeUSPvzDMbDA8VILBXpmiSOt4FMiMsSdA8HB5sFMkw/T
1l3x8jaTHXWUoI3+B/8xauaqrnNlZQE0A4bi3j/YOzGmqx3i1wwbJwuMzuVSGRck
NG9j2cnUY5liFmJrAltdPFhiejZnn9KijbXVOKBoWg3xIJuVocZ9eUCWGZkTnxGS
DahaKckcdpsRLztFCXrFz8wpTkLJYGH1+KuYSVwdsyQcQZ0s84W7bBMZ79pi7680
jZYui7URgC5FHFHeOXHFKizCL2FtLujgDSi+0AG29sAH5wksLWB3ixIEoMEmWu+m
2OUdTXP+a0Lu5GpI8bIOIOtfkuxGrdzQQV03ayIkufQXKZBoDiDA0qakjYccpQH1
e/zyOgH27rg1WgTc51zPgsLfeKDtqn/ro46nHMG8xm7MwDtI+Bzy4blkSvW8+3jl
Zxi7Nui/4Px946hoPrzn/t5csVnMqa8rYLWST1ZGHdvvCDfXn8C+pksRb7+8bEPh
TTQC8u9I/Prvzsg+OFai
=YLnV
-----END PGP SIGNATURE-----

--------------enig73B8E73C3E5D12671FAFA157--


--===============2928090477756891074==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2928090477756891074==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 15:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoU5-0006ws-Ej; Thu, 05 Apr 2012 15:20:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFoU3-0006wn-U7
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 15:20:24 +0000
Received: from [85.158.143.35:64572] by server-1.bemta-4.messagelabs.com id
	29/DC-20925-738BD7F4; Thu, 05 Apr 2012 15:20:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333639220!12049770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26884 invoked from network); 5 Apr 2012 15:20:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 15:20:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11799124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 15:20:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 16:20:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFoTp-0004kE-R1;
	Thu, 05 Apr 2012 15:20:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFoTp-00016R-PV;
	Thu, 05 Apr 2012 16:20:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12574-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 16:20:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12574 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12574/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12557
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass

version targeted for testing:
 linux                6c216ec636f75d834461be15f83ec41a6759bd2b
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoU5-0006ws-Ej; Thu, 05 Apr 2012 15:20:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFoU3-0006wn-U7
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 15:20:24 +0000
Received: from [85.158.143.35:64572] by server-1.bemta-4.messagelabs.com id
	29/DC-20925-738BD7F4; Thu, 05 Apr 2012 15:20:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333639220!12049770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26884 invoked from network); 5 Apr 2012 15:20:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 15:20:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11799124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 15:20:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 16:20:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFoTp-0004kE-R1;
	Thu, 05 Apr 2012 15:20:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFoTp-00016R-PV;
	Thu, 05 Apr 2012 16:20:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12574-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 16:20:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12574 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12574/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12557
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass

version targeted for testing:
 linux                6c216ec636f75d834461be15f83ec41a6759bd2b
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:26:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:26:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoa8-00077B-7z; Thu, 05 Apr 2012 15:26:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFoa6-000775-Ig
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:26:38 +0000
Received: from [85.158.143.99:11003] by server-2.bemta-4.messagelabs.com id
	B2/68-17550-DA9BD7F4; Thu, 05 Apr 2012 15:26:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333639597!19136884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21430 invoked from network); 5 Apr 2012 15:26:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 15:26:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11799335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 15:26:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 16:26:36 +0100
Date: Thu, 5 Apr 2012 16:29:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4F7DB706.5010909@canonical.com>
Message-ID: <alpine.DEB.2.00.1204051622530.15151@kaball-desktop>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
	<alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
	<4F7DB706.5010909@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Stefan Bader wrote:
> > In any case, as I said before, if the alternatives are keeping the wait
> > time or patching xend, I would go for patching xend.
> > If we don't think we can fix Linux and backport the fix in a reasonable
> > time, patching xend might be the only option.
> 
> My impression is that you (the generic you) would not really want to modify xend
> too much as it and the xm stack should go away anyway.
> Instead I would fix libvirt's use of xend when it is known that it is not
> working well (if using "vfb = [ 'vnc=1, ...' ]" or similar for sxpr is creating
> a vkbd and xend/the xm stack does not support it, then just don't use it).
> 
> The question of removing the delays is not so much (well yes it is too, but not
> always in ones own hands) whether it can be done or how quickly. Providing the
> means to run guests is something rather under our control. Be it Ubuntu as dom0
> or Xenserver. But which kernels are run as guests is not.
> 
> So, as long as xend does not change its behavior, then changing libvirt in a way
> that does never use the configuration format which causes a vkbd to be created
> (for HVM) is ok. And if it gets picked up upstream it helps all users of libvirt
> the same.
> But if xend would change to allow using a vkbd, then it would be good if that
> could be synced with a xend version change which could be used inside libvirt to
> modify its config output (as it does now but in some way with the wrong version).
> 
> The kernel change to remove delays imo is a completely separate issue. And if
> just as an additional "pre-caution".

So the argument is that ATM libvirt uses a vfb config line with HVM
guests and that is wrong.
I agree with you there, the vfb config line is for PV guests only and
should be removed from any HVM guests configurations.
In fact, even if we add a vfb frontend/backend pair for HVM guests, it
probably won't go through a vfb config line, because the vnc/sdl
configuration would be shared between the vfb and vga devices.

So you convinced me that is OK to remove it from libvirt :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:26:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:26:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoa8-00077B-7z; Thu, 05 Apr 2012 15:26:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SFoa6-000775-Ig
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:26:38 +0000
Received: from [85.158.143.99:11003] by server-2.bemta-4.messagelabs.com id
	B2/68-17550-DA9BD7F4; Thu, 05 Apr 2012 15:26:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1333639597!19136884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21430 invoked from network); 5 Apr 2012 15:26:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 15:26:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,376,1330905600"; d="scan'208";a="11799335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 15:26:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 16:26:36 +0100
Date: Thu, 5 Apr 2012 16:29:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4F7DB706.5010909@canonical.com>
Message-ID: <alpine.DEB.2.00.1204051622530.15151@kaball-desktop>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
	<alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
	<4F7DB706.5010909@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Stefan Bader wrote:
> > In any case, as I said before, if the alternatives are keeping the wait
> > time or patching xend, I would go for patching xend.
> > If we don't think we can fix Linux and backport the fix in a reasonable
> > time, patching xend might be the only option.
> 
> My impression is that you (the generic you) would not really want to modify xend
> too much as it and the xm stack should go away anyway.
> Instead I would fix libvirt's use of xend when it is known that it is not
> working well (if using "vfb = [ 'vnc=1, ...' ]" or similar for sxpr is creating
> a vkbd and xend/the xm stack does not support it, then just don't use it).
> 
> The question of removing the delays is not so much (well yes it is too, but not
> always in ones own hands) whether it can be done or how quickly. Providing the
> means to run guests is something rather under our control. Be it Ubuntu as dom0
> or Xenserver. But which kernels are run as guests is not.
> 
> So, as long as xend does not change its behavior, then changing libvirt in a way
> that does never use the configuration format which causes a vkbd to be created
> (for HVM) is ok. And if it gets picked up upstream it helps all users of libvirt
> the same.
> But if xend would change to allow using a vkbd, then it would be good if that
> could be synced with a xend version change which could be used inside libvirt to
> modify its config output (as it does now but in some way with the wrong version).
> 
> The kernel change to remove delays imo is a completely separate issue. And if
> just as an additional "pre-caution".

So the argument is that ATM libvirt uses a vfb config line with HVM
guests and that is wrong.
I agree with you there, the vfb config line is for PV guests only and
should be removed from any HVM guests configurations.
In fact, even if we add a vfb frontend/backend pair for HVM guests, it
probably won't go through a vfb config line, because the vnc/sdl
configuration would be shared between the vfb and vga devices.

So you convinced me that is OK to remove it from libvirt :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:35:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoiO-0007IY-7z; Thu, 05 Apr 2012 15:35:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFoiM-0007IQ-Pc
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:35:10 +0000
Received: from [85.158.143.35:18715] by server-2.bemta-4.messagelabs.com id
	11/E3-17550-EABBD7F4; Thu, 05 Apr 2012 15:35:10 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333640107!11451414!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18758 invoked from network); 5 Apr 2012 15:35:08 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-21.messagelabs.com with SMTP;
	5 Apr 2012 15:35:08 -0000
Received: from p5b2e2631.dip.t-dialin.net ([91.46.38.49] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFoiJ-0006i1-9a; Thu, 05 Apr 2012 15:35:07 +0000
Message-ID: <4F7DBBA9.3010902@canonical.com>
Date: Thu, 05 Apr 2012 17:35:05 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
	<alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
	<4F7DB706.5010909@canonical.com>
	<alpine.DEB.2.00.1204051622530.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051622530.15151@kaball-desktop>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8275528760848171114=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8275528760848171114==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigFFE3263A409ABEAB6AD0ECC4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFFE3263A409ABEAB6AD0ECC4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 05.04.2012 17:29, Stefano Stabellini wrote:
> On Thu, 5 Apr 2012, Stefan Bader wrote:
>>> In any case, as I said before, if the alternatives are keeping the wa=
it
>>> time or patching xend, I would go for patching xend.
>>> If we don't think we can fix Linux and backport the fix in a reasonab=
le
>>> time, patching xend might be the only option.
>>
>> My impression is that you (the generic you) would not really want to m=
odify xend
>> too much as it and the xm stack should go away anyway.
>> Instead I would fix libvirt's use of xend when it is known that it is =
not
>> working well (if using "vfb =3D [ 'vnc=3D1, ...' ]" or similar for sxp=
r is creating
>> a vkbd and xend/the xm stack does not support it, then just don't use =
it).
>>
>> The question of removing the delays is not so much (well yes it is too=
, but not
>> always in ones own hands) whether it can be done or how quickly. Provi=
ding the
>> means to run guests is something rather under our control. Be it Ubunt=
u as dom0
>> or Xenserver. But which kernels are run as guests is not.
>>
>> So, as long as xend does not change its behavior, then changing libvir=
t in a way
>> that does never use the configuration format which causes a vkbd to be=
 created
>> (for HVM) is ok. And if it gets picked up upstream it helps all users =
of libvirt
>> the same.
>> But if xend would change to allow using a vkbd, then it would be good =
if that
>> could be synced with a xend version change which could be used inside =
libvirt to
>> modify its config output (as it does now but in some way with the wron=
g version).
>>
>> The kernel change to remove delays imo is a completely separate issue.=
 And if
>> just as an additional "pre-caution".
>=20
> So the argument is that ATM libvirt uses a vfb config line with HVM
> guests and that is wrong.

Yes! :)

> I agree with you there, the vfb config line is for PV guests only and
> should be removed from any HVM guests configurations.
> In fact, even if we add a vfb frontend/backend pair for HVM guests, it
> probably won't go through a vfb config line, because the vnc/sdl
> configuration would be shared between the vfb and vga devices.
>=20
> So you convinced me that is OK to remove it from libvirt :-)

Ok, then I try to convince them as well. :) Actually I think we were agre=
eing
most of the time... just not always about the same thing. ;) Which is pro=
bably
due to me trying to wrap the issue into too many words...


--------------enigFFE3263A409ABEAB6AD0ECC4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfbupAAoJEOhnXe7L7s6jfooQAKV8umaD9j7NcL8CiUi9ZFz2
nhyC67U62x4xcWmGBeK3hrFo63I5a5BxXvbhYg01qy9E2mbhkKjLd7JDLDsJlac4
m48J0ERl6RB9XPkZpAw25uQmfCdnv6x8YZIdJv3inMwwFpAR4Lp/C3OqQzZBPSId
iWg4vIK8FMf47ddpwK+lmayShApv9SdiJGNXyjHpicxq/p8HhAPfeAk5EIeukrbF
moqLCu7FEOQo9Qac5w90jGMx3HM4q5Jt1KHnK/HLqP6TgO4OaWLcJlToPuvL34eM
Ch0JKriUGVFd4v+LOvccI+GGQzFwDwM7NG/DCMFfiHnJtUZbAq9qpQdLfcWSkm9V
q9G+0lBfIvEOlZ0233s1GIdYNH+6sWC2A2Uy9Ju+rcoZ44Aq6GQ7i1E8ST5hPK+L
xdUD5woiZnGK/PJK4cgxwnesekxs25OW2JSdCqo4DoO1nA5HGWNmCzX+BvvZke2t
aZqwlBeeVTLw34sFHggbR/e27HSi3ugQ4siesYdkQOspUHtfIQ2+nbWgzPzrflHI
66g1sbkBHaBMEc7dOLLD0hdVvS7UjEE2ydHFI/36RZfghSrYu3zVljGVjN22pdJs
4PR1NFgPON12erpD33Lbo13oNevG641mGnH7IReOqZ7lgBIgJiw77pfP8dupG8Tc
p7yCDDDOyezFt3q1x3Sv
=fyVR
-----END PGP SIGNATURE-----

--------------enigFFE3263A409ABEAB6AD0ECC4--


--===============8275528760848171114==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8275528760848171114==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 15:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:35:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoiO-0007IY-7z; Thu, 05 Apr 2012 15:35:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SFoiM-0007IQ-Pc
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:35:10 +0000
Received: from [85.158.143.35:18715] by server-2.bemta-4.messagelabs.com id
	11/E3-17550-EABBD7F4; Thu, 05 Apr 2012 15:35:10 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333640107!11451414!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18758 invoked from network); 5 Apr 2012 15:35:08 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-21.messagelabs.com with SMTP;
	5 Apr 2012 15:35:08 -0000
Received: from p5b2e2631.dip.t-dialin.net ([91.46.38.49] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SFoiJ-0006i1-9a; Thu, 05 Apr 2012 15:35:07 +0000
Message-ID: <4F7DBBA9.3010902@canonical.com>
Date: Thu, 05 Apr 2012 17:35:05 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120402 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <4F7C63EE.6000703@canonical.com>
	<alpine.DEB.2.00.1204051148070.15151@kaball-desktop>
	<4F7D9664.8080406@canonical.com>
	<alpine.DEB.2.00.1204051523120.15151@kaball-desktop>
	<4F7DB706.5010909@canonical.com>
	<alpine.DEB.2.00.1204051622530.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204051622530.15151@kaball-desktop>
X-Enigmail-Version: 1.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8275528760848171114=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8275528760848171114==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigFFE3263A409ABEAB6AD0ECC4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFFE3263A409ABEAB6AD0ECC4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 05.04.2012 17:29, Stefano Stabellini wrote:
> On Thu, 5 Apr 2012, Stefan Bader wrote:
>>> In any case, as I said before, if the alternatives are keeping the wa=
it
>>> time or patching xend, I would go for patching xend.
>>> If we don't think we can fix Linux and backport the fix in a reasonab=
le
>>> time, patching xend might be the only option.
>>
>> My impression is that you (the generic you) would not really want to m=
odify xend
>> too much as it and the xm stack should go away anyway.
>> Instead I would fix libvirt's use of xend when it is known that it is =
not
>> working well (if using "vfb =3D [ 'vnc=3D1, ...' ]" or similar for sxp=
r is creating
>> a vkbd and xend/the xm stack does not support it, then just don't use =
it).
>>
>> The question of removing the delays is not so much (well yes it is too=
, but not
>> always in ones own hands) whether it can be done or how quickly. Provi=
ding the
>> means to run guests is something rather under our control. Be it Ubunt=
u as dom0
>> or Xenserver. But which kernels are run as guests is not.
>>
>> So, as long as xend does not change its behavior, then changing libvir=
t in a way
>> that does never use the configuration format which causes a vkbd to be=
 created
>> (for HVM) is ok. And if it gets picked up upstream it helps all users =
of libvirt
>> the same.
>> But if xend would change to allow using a vkbd, then it would be good =
if that
>> could be synced with a xend version change which could be used inside =
libvirt to
>> modify its config output (as it does now but in some way with the wron=
g version).
>>
>> The kernel change to remove delays imo is a completely separate issue.=
 And if
>> just as an additional "pre-caution".
>=20
> So the argument is that ATM libvirt uses a vfb config line with HVM
> guests and that is wrong.

Yes! :)

> I agree with you there, the vfb config line is for PV guests only and
> should be removed from any HVM guests configurations.
> In fact, even if we add a vfb frontend/backend pair for HVM guests, it
> probably won't go through a vfb config line, because the vnc/sdl
> configuration would be shared between the vfb and vga devices.
>=20
> So you convinced me that is OK to remove it from libvirt :-)

Ok, then I try to convince them as well. :) Actually I think we were agre=
eing
most of the time... just not always about the same thing. ;) Which is pro=
bably
due to me trying to wrap the issue into too many words...


--------------enigFFE3263A409ABEAB6AD0ECC4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPfbupAAoJEOhnXe7L7s6jfooQAKV8umaD9j7NcL8CiUi9ZFz2
nhyC67U62x4xcWmGBeK3hrFo63I5a5BxXvbhYg01qy9E2mbhkKjLd7JDLDsJlac4
m48J0ERl6RB9XPkZpAw25uQmfCdnv6x8YZIdJv3inMwwFpAR4Lp/C3OqQzZBPSId
iWg4vIK8FMf47ddpwK+lmayShApv9SdiJGNXyjHpicxq/p8HhAPfeAk5EIeukrbF
moqLCu7FEOQo9Qac5w90jGMx3HM4q5Jt1KHnK/HLqP6TgO4OaWLcJlToPuvL34eM
Ch0JKriUGVFd4v+LOvccI+GGQzFwDwM7NG/DCMFfiHnJtUZbAq9qpQdLfcWSkm9V
q9G+0lBfIvEOlZ0233s1GIdYNH+6sWC2A2Uy9Ju+rcoZ44Aq6GQ7i1E8ST5hPK+L
xdUD5woiZnGK/PJK4cgxwnesekxs25OW2JSdCqo4DoO1nA5HGWNmCzX+BvvZke2t
aZqwlBeeVTLw34sFHggbR/e27HSi3ugQ4siesYdkQOspUHtfIQ2+nbWgzPzrflHI
66g1sbkBHaBMEc7dOLLD0hdVvS7UjEE2ydHFI/36RZfghSrYu3zVljGVjN22pdJs
4PR1NFgPON12erpD33Lbo13oNevG641mGnH7IReOqZ7lgBIgJiw77pfP8dupG8Tc
p7yCDDDOyezFt3q1x3Sv
=fyVR
-----END PGP SIGNATURE-----

--------------enigFFE3263A409ABEAB6AD0ECC4--


--===============8275528760848171114==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8275528760848171114==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 15:36:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoje-0007Lj-Nd; Thu, 05 Apr 2012 15:36:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFojd-0007Lb-Eo
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:36:29 +0000
Received: from [85.158.139.83:25629] by server-4.bemta-5.messagelabs.com id
	59/55-10788-CFBBD7F4; Thu, 05 Apr 2012 15:36:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333640187!22664965!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12677 invoked from network); 5 Apr 2012 15:36:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:36:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 16:36:26 +0100
Message-Id: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 16:37:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- devices beyond xvdzz didn't get proper names assigned at all
- extended devices with minors not representable within the kernel's
  major/minor bit split spilled into foreign majors

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkfront.c |   40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

--- 3.4-rc1/drivers/block/xen-blkfront.c
+++ 3.4-rc1-xen-blkfront-all-devices/drivers/block/xen-blkfront.c
@@ -528,6 +528,14 @@ static int xen_translate_vdev(int vdevic
 	return 0;
 }
 
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+	if (n >= 26)
+		ptr = encode_disk_name(ptr, n / 26 - 1);
+	*ptr = 'a' + n % 26;
+	return ptr + 1;
+}
+
 static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
 			       struct blkfront_info *info,
 			       u16 vdisk_info, u16 sector_size)
@@ -538,6 +546,7 @@ static int xlvbd_alloc_gendisk(blkif_sec
 	unsigned int offset;
 	int minor;
 	int nr_parts;
+	char *ptr;
 
 	BUG_ON(info->gd != NULL);
 	BUG_ON(info->rq != NULL);
@@ -562,7 +571,11 @@ static int xlvbd_alloc_gendisk(blkif_sec
 					"emulated IDE disks,\n\t choose an xvd device name"
 					"from xvde on\n", info->vdevice);
 	}
-	err = -ENODEV;
+	if (minor >> MINORBITS) {
+		pr_warn("blkfront: %#x's minor (%#x) out of range; ignoring\n",
+			info->vdevice, minor);
+		return -ENODEV;
+	}
 
 	if ((minor % nr_parts) == 0)
 		nr_minors = nr_parts;
@@ -576,23 +589,14 @@ static int xlvbd_alloc_gendisk(blkif_sec
 	if (gd == NULL)
 		goto release;
 
-	if (nr_minors > 1) {
-		if (offset < 26)
-			sprintf(gd->disk_name, "%s%c", DEV_NAME, 'a' + offset);
-		else
-			sprintf(gd->disk_name, "%s%c%c", DEV_NAME,
-				'a' + ((offset / 26)-1), 'a' + (offset % 26));
-	} else {
-		if (offset < 26)
-			sprintf(gd->disk_name, "%s%c%d", DEV_NAME,
-				'a' + offset,
-				minor & (nr_parts - 1));
-		else
-			sprintf(gd->disk_name, "%s%c%c%d", DEV_NAME,
-				'a' + ((offset / 26) - 1),
-				'a' + (offset % 26),
-				minor & (nr_parts - 1));
-	}
+	strcpy(gd->disk_name, DEV_NAME);
+	ptr = encode_disk_name(gd->disk_name + sizeof(DEV_NAME) - 1, offset);
+	BUG_ON(ptr >= gd->disk_name + DISK_NAME_LEN);
+	if (nr_minors > 1)
+		*ptr = 0;
+	else
+		snprintf(ptr, gd->disk_name + DISK_NAME_LEN - ptr,
+			 "%d", minor & (nr_parts - 1));
 
 	gd->major = XENVBD_MAJOR;
 	gd->first_minor = minor;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:36:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFoje-0007Lj-Nd; Thu, 05 Apr 2012 15:36:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SFojd-0007Lb-Eo
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:36:29 +0000
Received: from [85.158.139.83:25629] by server-4.bemta-5.messagelabs.com id
	59/55-10788-CFBBD7F4; Thu, 05 Apr 2012 15:36:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1333640187!22664965!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12677 invoked from network); 5 Apr 2012 15:36:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:36:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Apr 2012 16:36:26 +0100
Message-Id: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Apr 2012 16:37:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- devices beyond xvdzz didn't get proper names assigned at all
- extended devices with minors not representable within the kernel's
  major/minor bit split spilled into foreign majors

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkfront.c |   40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

--- 3.4-rc1/drivers/block/xen-blkfront.c
+++ 3.4-rc1-xen-blkfront-all-devices/drivers/block/xen-blkfront.c
@@ -528,6 +528,14 @@ static int xen_translate_vdev(int vdevic
 	return 0;
 }
 
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+	if (n >= 26)
+		ptr = encode_disk_name(ptr, n / 26 - 1);
+	*ptr = 'a' + n % 26;
+	return ptr + 1;
+}
+
 static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
 			       struct blkfront_info *info,
 			       u16 vdisk_info, u16 sector_size)
@@ -538,6 +546,7 @@ static int xlvbd_alloc_gendisk(blkif_sec
 	unsigned int offset;
 	int minor;
 	int nr_parts;
+	char *ptr;
 
 	BUG_ON(info->gd != NULL);
 	BUG_ON(info->rq != NULL);
@@ -562,7 +571,11 @@ static int xlvbd_alloc_gendisk(blkif_sec
 					"emulated IDE disks,\n\t choose an xvd device name"
 					"from xvde on\n", info->vdevice);
 	}
-	err = -ENODEV;
+	if (minor >> MINORBITS) {
+		pr_warn("blkfront: %#x's minor (%#x) out of range; ignoring\n",
+			info->vdevice, minor);
+		return -ENODEV;
+	}
 
 	if ((minor % nr_parts) == 0)
 		nr_minors = nr_parts;
@@ -576,23 +589,14 @@ static int xlvbd_alloc_gendisk(blkif_sec
 	if (gd == NULL)
 		goto release;
 
-	if (nr_minors > 1) {
-		if (offset < 26)
-			sprintf(gd->disk_name, "%s%c", DEV_NAME, 'a' + offset);
-		else
-			sprintf(gd->disk_name, "%s%c%c", DEV_NAME,
-				'a' + ((offset / 26)-1), 'a' + (offset % 26));
-	} else {
-		if (offset < 26)
-			sprintf(gd->disk_name, "%s%c%d", DEV_NAME,
-				'a' + offset,
-				minor & (nr_parts - 1));
-		else
-			sprintf(gd->disk_name, "%s%c%c%d", DEV_NAME,
-				'a' + ((offset / 26) - 1),
-				'a' + (offset % 26),
-				minor & (nr_parts - 1));
-	}
+	strcpy(gd->disk_name, DEV_NAME);
+	ptr = encode_disk_name(gd->disk_name + sizeof(DEV_NAME) - 1, offset);
+	BUG_ON(ptr >= gd->disk_name + DISK_NAME_LEN);
+	if (nr_minors > 1)
+		*ptr = 0;
+	else
+		snprintf(ptr, gd->disk_name + DISK_NAME_LEN - ptr,
+			 "%d", minor & (nr_parts - 1));
 
 	gd->major = XENVBD_MAJOR;
 	gd->first_minor = minor;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:37:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFokV-0007PE-5I; Thu, 05 Apr 2012 15:37:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SFokT-0007P7-Tc
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 15:37:22 +0000
Received: from [193.109.254.147:48195] by server-4.bemta-14.messagelabs.com id
	0A/64-11570-13CBD7F4; Thu, 05 Apr 2012 15:37:21 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333640239!313469!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAzODQ0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25899 invoked from network); 5 Apr 2012 15:37:20 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-27.messagelabs.com with SMTP;
	5 Apr 2012 15:37:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 05 Apr 2012 08:37:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="85708201"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 05 Apr 2012 08:37:11 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 5 Apr 2012 08:37:10 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id
	14.01.0355.002; Thu, 5 Apr 2012 23:37:09 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNEzo9b8szDONMp0ufANRY641D2paMVoHA
Date: Thu, 5 Apr 2012 15:37:08 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
In-Reply-To: <20349.44836.366233.162318@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

<Porting from xen 4.1, patch on Xen unstable 25138>

libxl: passthrough: avoid passing through devices not owned by pciback

This patch makes sure the passthrough device belongs to pciback before allow them passthrough to the guest.  There are still many other checks missing.

xm terminates the guest startup process when this type of condition is found.  This patch just allows the guest to continue to boot but with no device passthrough.

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff -r 4e1d091d10d8 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Mar 16 15:24:25 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Mar 22 00:43:14 2012 +0800
@@ -779,6 +779,24 @@ int libxl_device_pci_add(libxl_ctx *ctx,
     return rc;
 }
 
+static int libxl_pcidev_assignable(libxl_ctx *ctx, libxl_device_pci 
+*pcidev) {
+    libxl_device_pci *pcidevs;
+    int num, i;
+
+    pcidevs = libxl_device_pci_list_assignable(ctx, &num);
+    for (i = 0; i < num; i++) {
+        if (pcidevs[i].domain == pcidev->domain &&
+            pcidevs[i].bus == pcidev->bus &&
+            pcidevs[i].dev == pcidev->dev &&
+            pcidevs[i].func == pcidev->func)
+        {
+            return 1;
+        }
+    }
+    return 0;
+}
+
 int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting)  {
     libxl_ctx *ctx = libxl__gc_owner(gc); @@ -789,6 +807,13 @@ int libxl__device_pci_add(libxl__gc *gc,
 
     rc = libxl__device_pci_setdefault(gc, pcidev);
     if (rc) goto out;
+
+    if (!libxl_pcidev_assignable(ctx, pcidev)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable",
+                   pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {

Thanks,
-Xudong

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Thursday, April 05, 2012 10:42 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> >
> > > -----Original Message-----
> > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > > Sent: Tuesday, April 03, 2012 1:01 AM
> > > To: Hao, Xudong
> > > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > > Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> > > through devices not owned by pciback
> > >
> > > Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid
> > > passing through devices not owned by pciback"):
> > > > <Porting from Xen 4.1 tree.>
> > > >
> > > > libxl: passthrough: avoid passing through devices not owned by
> > > > pciback
> > >
> > > I'm afraid this no longer applies to xen-unstable.hg tip.
> > >
> > Reason?
> >
> > If no pciback checking, one device could be assigned to guest even it's being
> used by dom0, is there security issue?
> 
> I mean that it has conflicts when I try to apply it.  You need to refresh it.
> 
> Thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:37:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFokV-0007PE-5I; Thu, 05 Apr 2012 15:37:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SFokT-0007P7-Tc
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 15:37:22 +0000
Received: from [193.109.254.147:48195] by server-4.bemta-14.messagelabs.com id
	0A/64-11570-13CBD7F4; Thu, 05 Apr 2012 15:37:21 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333640239!313469!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAzODQ0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25899 invoked from network); 5 Apr 2012 15:37:20 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-27.messagelabs.com with SMTP;
	5 Apr 2012 15:37:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 05 Apr 2012 08:37:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="85708201"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 05 Apr 2012 08:37:11 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 5 Apr 2012 08:37:10 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id
	14.01.0355.002; Thu, 5 Apr 2012 23:37:09 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNEzo9b8szDONMp0ufANRY641D2paMVoHA
Date: Thu, 5 Apr 2012 15:37:08 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
In-Reply-To: <20349.44836.366233.162318@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

<Porting from xen 4.1, patch on Xen unstable 25138>

libxl: passthrough: avoid passing through devices not owned by pciback

This patch makes sure the passthrough device belongs to pciback before allow them passthrough to the guest.  There are still many other checks missing.

xm terminates the guest startup process when this type of condition is found.  This patch just allows the guest to continue to boot but with no device passthrough.

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff -r 4e1d091d10d8 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Mar 16 15:24:25 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Mar 22 00:43:14 2012 +0800
@@ -779,6 +779,24 @@ int libxl_device_pci_add(libxl_ctx *ctx,
     return rc;
 }
 
+static int libxl_pcidev_assignable(libxl_ctx *ctx, libxl_device_pci 
+*pcidev) {
+    libxl_device_pci *pcidevs;
+    int num, i;
+
+    pcidevs = libxl_device_pci_list_assignable(ctx, &num);
+    for (i = 0; i < num; i++) {
+        if (pcidevs[i].domain == pcidev->domain &&
+            pcidevs[i].bus == pcidev->bus &&
+            pcidevs[i].dev == pcidev->dev &&
+            pcidevs[i].func == pcidev->func)
+        {
+            return 1;
+        }
+    }
+    return 0;
+}
+
 int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting)  {
     libxl_ctx *ctx = libxl__gc_owner(gc); @@ -789,6 +807,13 @@ int libxl__device_pci_add(libxl__gc *gc,
 
     rc = libxl__device_pci_setdefault(gc, pcidev);
     if (rc) goto out;
+
+    if (!libxl_pcidev_assignable(ctx, pcidev)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable",
+                   pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {

Thanks,
-Xudong

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Thursday, April 05, 2012 10:42 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> >
> > > -----Original Message-----
> > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > > Sent: Tuesday, April 03, 2012 1:01 AM
> > > To: Hao, Xudong
> > > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > > Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> > > through devices not owned by pciback
> > >
> > > Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid
> > > passing through devices not owned by pciback"):
> > > > <Porting from Xen 4.1 tree.>
> > > >
> > > > libxl: passthrough: avoid passing through devices not owned by
> > > > pciback
> > >
> > > I'm afraid this no longer applies to xen-unstable.hg tip.
> > >
> > Reason?
> >
> > If no pciback checking, one device could be assigned to guest even it's being
> used by dom0, is there security issue?
> 
> I mean that it has conflicts when I try to apply it.  You need to refresh it.
> 
> Thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFomX-0007Z7-Rn; Thu, 05 Apr 2012 15:39:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFomW-0007Z0-EQ
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:39:28 +0000
Received: from [85.158.138.51:9979] by server-11.bemta-3.messagelabs.com id
	51/AB-28543-FACBD7F4; Thu, 05 Apr 2012 15:39:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333640366!20791151!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24365 invoked from network); 5 Apr 2012 15:39:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:39:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFomJ-00054u-Pt; Thu, 05 Apr 2012 15:39:15 +0000
Date: Thu, 5 Apr 2012 16:39:15 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405153915.GI14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
	<4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
	<20120405140839.GG14774@ocelot.phlegethon.org>
	<4F7DC624020000780007CBB8@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DC624020000780007CBB8@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
	comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:19 +0100 on 05 Apr (1333639188), Jan Beulich wrote:
> >>> On 05.04.12 at 16:08, Tim Deegan <tim@xen.org> wrote:
> > At 14:31 +0100 on 05 Apr (1333636297), Jan Beulich wrote:
> >> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> >> > x86/mm: Another couple of comparisons of unsigned vars with < 0.
> >> > 
> >> > Adding the explicit (unsigned) casts in case enums ever end up signed.
> >> 
> >> Ugly, but unavoidable if range comparisons are done on enums (which
> >> is what ought to get fixed instead imo).
> > 
> > Any suggestions for how?  Turn the array access into a case statement?
> > That's even uglier IMO. 
> 
> 	switch (<enum-var>) {
> 	case <low> ... <high>:
> 		break;
> 	default:
> 		<bad>;
> 	}

Hmm.  I really prefer the cast to that.

In both these cases, I could replace this idiom:

 static const array a  = { val_x, val_y, val_z };
 if ( (unsigned) e >= enum_z ) return -EINVAL;
 val = a[e];

with 

 switch (e) {
     case enum_x: val = val_x; break;
     case enum_x: val = val_x; break;
     case enum_x: val = val_x; break;
     default: return -EINVAL;
 }

but unless it's laid out like this (one line per case) it'll get ugly too.

Switching to #defines is a bit tricky as they're in a public header and
I'm not confident we wouldn't break someone else's compile.

> doesn't look that bad. But when wanting to do range comparisons,
> an enum may not be the best choice anyway (for the very reason of
> it possible being signed, and signed array indexes generally being
> less efficient than unsigned ones), and hence using #define-s and
> an "unsigned int" variable might be the better way.
> 
> Otoh, doesn't clang have a command line option to control whether
> enums are signed or unsigned? I think gcc does.

The only gcc flag I can find is -fshort-enums, for making enums into
shorter types.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFomX-0007Z7-Rn; Thu, 05 Apr 2012 15:39:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFomW-0007Z0-EQ
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:39:28 +0000
Received: from [85.158.138.51:9979] by server-11.bemta-3.messagelabs.com id
	51/AB-28543-FACBD7F4; Thu, 05 Apr 2012 15:39:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333640366!20791151!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24365 invoked from network); 5 Apr 2012 15:39:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 15:39:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SFomJ-00054u-Pt; Thu, 05 Apr 2012 15:39:15 +0000
Date: Thu, 5 Apr 2012 16:39:15 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120405153915.GI14774@ocelot.phlegethon.org>
References: <patchbomb.1333627633@whitby.uk.xensource.com>
	<5eeaa7b25a60327c48bf.1333627636@whitby.uk.xensource.com>
	<4F7DBAD9020000780007CB2B@nat28.tlf.novell.com>
	<20120405140839.GG14774@ocelot.phlegethon.org>
	<4F7DC624020000780007CBB8@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7DC624020000780007CBB8@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of
	comparisons of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:19 +0100 on 05 Apr (1333639188), Jan Beulich wrote:
> >>> On 05.04.12 at 16:08, Tim Deegan <tim@xen.org> wrote:
> > At 14:31 +0100 on 05 Apr (1333636297), Jan Beulich wrote:
> >> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xen.org> wrote:
> >> > x86/mm: Another couple of comparisons of unsigned vars with < 0.
> >> > 
> >> > Adding the explicit (unsigned) casts in case enums ever end up signed.
> >> 
> >> Ugly, but unavoidable if range comparisons are done on enums (which
> >> is what ought to get fixed instead imo).
> > 
> > Any suggestions for how?  Turn the array access into a case statement?
> > That's even uglier IMO. 
> 
> 	switch (<enum-var>) {
> 	case <low> ... <high>:
> 		break;
> 	default:
> 		<bad>;
> 	}

Hmm.  I really prefer the cast to that.

In both these cases, I could replace this idiom:

 static const array a  = { val_x, val_y, val_z };
 if ( (unsigned) e >= enum_z ) return -EINVAL;
 val = a[e];

with 

 switch (e) {
     case enum_x: val = val_x; break;
     case enum_x: val = val_x; break;
     case enum_x: val = val_x; break;
     default: return -EINVAL;
 }

but unless it's laid out like this (one line per case) it'll get ugly too.

Switching to #defines is a bit tricky as they're in a public header and
I'm not confident we wouldn't break someone else's compile.

> doesn't look that bad. But when wanting to do range comparisons,
> an enum may not be the best choice anyway (for the very reason of
> it possible being signed, and signed array indexes generally being
> less efficient than unsigned ones), and hence using #define-s and
> an "unsigned int" variable might be the better way.
> 
> Otoh, doesn't clang have a command line option to control whether
> enums are signed or unsigned? I think gcc does.

The only gcc flag I can find is -fshort-enums, for making enums into
shorter types.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:55:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:55:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFp1q-0007yE-D9; Thu, 05 Apr 2012 15:55:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFp1p-0007y9-KW
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 15:55:17 +0000
Received: from [193.109.254.147:45072] by server-4.bemta-14.messagelabs.com id
	F9/CB-11570-560CD7F4; Thu, 05 Apr 2012 15:55:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1333641314!3445998!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NDI1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2260 invoked from network); 5 Apr 2012 15:55:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 15:55:15 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q35Ft9v3019601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 15:55:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q35Ft8pV001478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 15:55:09 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q35Ft7UI021985; Thu, 5 Apr 2012 10:55:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Apr 2012 08:55:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B917C40328; Thu,  5 Apr 2012 11:50:29 -0400 (EDT)
Date: Thu, 5 Apr 2012 11:50:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20120405155029.GC1854@phenom.dumpdata.com>
References: <osstest-12574-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-12574-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020207.4F7DC05F.0025,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-linus test] 12574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 05, 2012 at 04:20:09PM +0100, xen.org wrote:
> flight 12574 linux-linus real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12574/

So I know what fix to push for this. Shall I tell you when it should
be upstream and when it should be working?

> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
>  test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
>  test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
>  test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
>  test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
>  test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
>  test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
>  test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
>  test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12557
>  test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
>  test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
>  test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
>  test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
>  test-amd64-i386-pv            5 xen-boot                     fail   never pass
>  test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
>  test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
>  test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
>  test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
>  test-amd64-i386-win           5 xen-boot                     fail   never pass
>  test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
>  test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
> 
> version targeted for testing:
>  linux                6c216ec636f75d834461be15f83ec41a6759bd2b
> baseline version:
>  linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          fail    
>  test-amd64-i386-xl                                           fail    
>  test-i386-i386-xl                                            fail    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   fail    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
>  test-amd64-i386-xl-multivcpu                                 fail    
>  test-amd64-amd64-pair                                        fail    
>  test-amd64-i386-pair                                         fail    
>  test-i386-i386-pair                                          fail    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          fail    
>  test-amd64-i386-pv                                           fail    
>  test-i386-i386-pv                                            fail    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-i386-i386-xl-qemuu-winxpsp3                             fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:55:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:55:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFp1q-0007yE-D9; Thu, 05 Apr 2012 15:55:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SFp1p-0007y9-KW
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 15:55:17 +0000
Received: from [193.109.254.147:45072] by server-4.bemta-14.messagelabs.com id
	F9/CB-11570-560CD7F4; Thu, 05 Apr 2012 15:55:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1333641314!3445998!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NDI1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2260 invoked from network); 5 Apr 2012 15:55:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Apr 2012 15:55:15 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q35Ft9v3019601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Apr 2012 15:55:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q35Ft8pV001478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Apr 2012 15:55:09 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q35Ft7UI021985; Thu, 5 Apr 2012 10:55:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Apr 2012 08:55:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B917C40328; Thu,  5 Apr 2012 11:50:29 -0400 (EDT)
Date: Thu, 5 Apr 2012 11:50:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20120405155029.GC1854@phenom.dumpdata.com>
References: <osstest-12574-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-12574-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020207.4F7DC05F.0025,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-linus test] 12574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 05, 2012 at 04:20:09PM +0100, xen.org wrote:
> flight 12574 linux-linus real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12574/

So I know what fix to push for this. Shall I tell you when it should
be upstream and when it should be working?

> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
>  test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
>  test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
>  test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
>  test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
>  test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
>  test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
>  test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
>  test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12557
>  test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
>  test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
>  test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
>  test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
>  test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
>  test-amd64-i386-pv            5 xen-boot                     fail   never pass
>  test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
>  test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
>  test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
>  test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
>  test-amd64-i386-win           5 xen-boot                     fail   never pass
>  test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
>  test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
> 
> version targeted for testing:
>  linux                6c216ec636f75d834461be15f83ec41a6759bd2b
> baseline version:
>  linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          fail    
>  test-amd64-i386-xl                                           fail    
>  test-i386-i386-xl                                            fail    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   fail    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
>  test-amd64-i386-xl-multivcpu                                 fail    
>  test-amd64-amd64-pair                                        fail    
>  test-amd64-i386-pair                                         fail    
>  test-i386-i386-pair                                          fail    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          fail    
>  test-amd64-i386-pv                                           fail    
>  test-i386-i386-pv                                            fail    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-i386-i386-xl-qemuu-winxpsp3                             fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:55:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFp25-0007z0-Q4; Thu, 05 Apr 2012 15:55:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SFp24-0007yn-Co
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:55:32 +0000
Received: from [85.158.143.35:60384] by server-3.bemta-4.messagelabs.com id
	4A/9E-05853-370CD7F4; Thu, 05 Apr 2012 15:55:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333641330!11228191!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31585 invoked from network); 5 Apr 2012 15:55:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 15:55:30 -0000
Received: by werp12 with SMTP id p12so1205127wer.32
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 08:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cTjgyGTJLf5w8Sib3koet51+8K6N1EDwhe94MVn+J3A=;
	b=bHIHw+yCRa+yMi/u++QPlbNg6E1dDkH3IlQ9BWzcm6bOPHSHdkl1nr2AMl1yg7+KKi
	9uKYvs4hTtW8mE8S84132f5/SxBhRNWvKp93PUUY7lfvBmWSzrfc3m5GiDnmgiggEFRv
	CSdQnq5zq0IzHV1zIHnkGEfe1OpHIA1gvO0DaoE8v4pdCAtGcIl6aF6rUNLxgfv/UMKJ
	4SPLWVqM5hCR/FjDj1ifbNXvghn6ZxHXSJoMQAKqcFeIFzT/6wVTSf6InD0KYkgP6xk3
	tGDL9tZ7fXiDgYvrJNPFuc2uiBsiD0bzKfKASN4KKAlsefcNW1kKf7hCZWiAIoX86Bxq
	kGKA==
Received: by 10.180.91.165 with SMTP id cf5mr6049611wib.2.1333641328507;
	Thu, 05 Apr 2012 08:55:28 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id k6sm14583489wiy.7.2012.04.05.08.55.25
	(version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:55:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Apr 2012 16:55:24 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	<xen-devel@lists.xen.org>
Message-ID: <CBA37EFC.301F4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 6] Make xen build with clang/LLVM again
Thread-Index: Ac0TRIL9cL5PqWtEok2oWVu7GUFAFg==
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 6] Make xen build with clang/LLVM again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/04/2012 13:07, "Tim Deegan" <tim@xen.org> wrote:

> This series makes the hypervisor build with clang/LLVM again,
> after a certain amount of bit-rot.
> 
> Some of these are obvious bug-fixes which are picked up by clang's
> slightly different -W* implementation.  Some (the spinlock change
> in particular) are working around deficiencies in clang/llvm.  I'm
> happy to change those ones to avoid any concerns people have about
> damaging the GCC build.

I don't have any comments on these beyond Jan's comments on patch 2/6. I
don't care what method you use to keep the out-of-line code ool on standard
toolchain.

 -- keir

> Cheers,
> 
> Tim.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 15:55:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFp25-0007z0-Q4; Thu, 05 Apr 2012 15:55:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SFp24-0007yn-Co
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 15:55:32 +0000
Received: from [85.158.143.35:60384] by server-3.bemta-4.messagelabs.com id
	4A/9E-05853-370CD7F4; Thu, 05 Apr 2012 15:55:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333641330!11228191!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31585 invoked from network); 5 Apr 2012 15:55:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 15:55:30 -0000
Received: by werp12 with SMTP id p12so1205127wer.32
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 08:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cTjgyGTJLf5w8Sib3koet51+8K6N1EDwhe94MVn+J3A=;
	b=bHIHw+yCRa+yMi/u++QPlbNg6E1dDkH3IlQ9BWzcm6bOPHSHdkl1nr2AMl1yg7+KKi
	9uKYvs4hTtW8mE8S84132f5/SxBhRNWvKp93PUUY7lfvBmWSzrfc3m5GiDnmgiggEFRv
	CSdQnq5zq0IzHV1zIHnkGEfe1OpHIA1gvO0DaoE8v4pdCAtGcIl6aF6rUNLxgfv/UMKJ
	4SPLWVqM5hCR/FjDj1ifbNXvghn6ZxHXSJoMQAKqcFeIFzT/6wVTSf6InD0KYkgP6xk3
	tGDL9tZ7fXiDgYvrJNPFuc2uiBsiD0bzKfKASN4KKAlsefcNW1kKf7hCZWiAIoX86Bxq
	kGKA==
Received: by 10.180.91.165 with SMTP id cf5mr6049611wib.2.1333641328507;
	Thu, 05 Apr 2012 08:55:28 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id k6sm14583489wiy.7.2012.04.05.08.55.25
	(version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:55:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Apr 2012 16:55:24 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	<xen-devel@lists.xen.org>
Message-ID: <CBA37EFC.301F4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 6] Make xen build with clang/LLVM again
Thread-Index: Ac0TRIL9cL5PqWtEok2oWVu7GUFAFg==
In-Reply-To: <patchbomb.1333627633@whitby.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 6] Make xen build with clang/LLVM again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/04/2012 13:07, "Tim Deegan" <tim@xen.org> wrote:

> This series makes the hypervisor build with clang/LLVM again,
> after a certain amount of bit-rot.
> 
> Some of these are obvious bug-fixes which are picked up by clang's
> slightly different -W* implementation.  Some (the spinlock change
> in particular) are working around deficiencies in clang/llvm.  I'm
> happy to change those ones to avoid any concerns people have about
> damaging the GCC build.

I don't have any comments on these beyond Jan's comments on patch 2/6. I
don't care what method you use to keep the out-of-line code ool on standard
toolchain.

 -- keir

> Cheers,
> 
> Tim.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEu-0000GF-It; Thu, 05 Apr 2012 16:08:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEs-0000En-4D
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [85.158.139.83:16892] by server-8.bemta-5.messagelabs.com id
	B3/42-26964-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333642121!11392335!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28384 invoked from network); 5 Apr 2012 16:08:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="23913360"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:40 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozT-00054Z-Lw	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozT-0004FB-DE	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: a93381049790e4f8a02f2322851f78175c254c5b
Message-ID: <a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:53 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 7 v2] x86: fix memset(ptr, 0, sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID a93381049790e4f8a02f2322851f78175c254c5b
# Parent  4674ce03c62a3e916954fd445b4510ffe72e64f4
x86: fix memset(ptr, 0, sizeof ptr).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
@@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
 		return NULL;
 	}
 
-	memset(mc_ext, 0, sizeof(mc_ext));
+	memset(mc_ext, 0, sizeof(*mc_ext));
 	mc_ext->common.type = MC_TYPE_EXTENDED;
-	mc_ext->common.size = sizeof(mc_ext);
+	mc_ext->common.size = sizeof(*mc_ext);
 	mc_ext->mc_msrs = 3;
 
 	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
@@ -1232,11 +1232,10 @@ bool_t p2m_mem_access_check(unsigned lon
     }
 
     *req_ptr = NULL;
-    req = xmalloc(mem_event_request_t);
+    req = xzalloc(mem_event_request_t);
     if ( req )
     {
         *req_ptr = req;
-        memset(req, 0, sizeof(req));
         req->reason = MEM_EVENT_REASON_VIOLATION;
 
         /* Pause the current VCPU */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEs-0000FO-Rw; Thu, 05 Apr 2012 16:08:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000EY-3z
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:45 +0000
Received: from [193.109.254.147:25219] by server-2.bemta-14.messagelabs.com id
	90/2C-19409-C83CD7F4; Thu, 05 Apr 2012 16:08:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22727 invoked from network); 5 Apr 2012 16:08:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190449"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:40 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozS-00054T-Lq	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:50 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozS-0004F3-7k	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 08612e81926857363618746fd01f9b08b7c3ac73
Message-ID: <08612e81926857363618.1333641111@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:51 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 7 v2] x86/mm: Another couple of comparisons
 of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 08612e81926857363618746fd01f9b08b7c3ac73
# Parent  7922a921d2034930780e41f1bc71d2c4ddb3b782
x86/mm: Another couple of comparisons of unsigned vars with < 0.

Adding the explicit (unsigned) casts in case enums ever end up signed.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 7922a921d203 -r 08612e819268 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
@@ -1305,7 +1305,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m->default_access,
     };
 
-    if ( access >= HVMMEM_access_default || access < 0 )
+    if ( (unsigned) access >= HVMMEM_access_default )
         return -EINVAL;
 
     a = memaccess[access];
@@ -1367,7 +1367,7 @@ int p2m_get_mem_access(struct domain *d,
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     
-    if ( a >= ARRAY_SIZE(memaccess) || a < 0 )
+    if ( (unsigned) a >= ARRAY_SIZE(memaccess) )
         return -ERANGE;
 
     *access =  memaccess[a];

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEu-0000Ga-WA; Thu, 05 Apr 2012 16:08:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEs-0000En-Kd
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [85.158.139.83:56383] by server-8.bemta-5.messagelabs.com id
	C8/42-26964-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333642121!11392335!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28413 invoked from network); 5 Apr 2012 16:08:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="23913361"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:41 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozR-00054N-Ol	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:49 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozR-0004Ew-CA	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:49 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:49 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series makes the hypervisor build with clang/LLVM again,
after a certain amount of bit-rot.

Since v1:
 - Changed an xmalloc+memset pair to xzalloc in the memset patch
 - Reworked the spinlock patch not to touch gcc builds
 - Added a patch to indirect all __section__ directives through a macro.
 - Commented up the ugly __attribute__((used)) change and moved it
   into the definition of __section().
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEs-0000FO-Rw; Thu, 05 Apr 2012 16:08:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000EY-3z
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:45 +0000
Received: from [193.109.254.147:25219] by server-2.bemta-14.messagelabs.com id
	90/2C-19409-C83CD7F4; Thu, 05 Apr 2012 16:08:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22727 invoked from network); 5 Apr 2012 16:08:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190449"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:40 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozS-00054T-Lq	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:50 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozS-0004F3-7k	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 08612e81926857363618746fd01f9b08b7c3ac73
Message-ID: <08612e81926857363618.1333641111@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:51 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 7 v2] x86/mm: Another couple of comparisons
 of unsigned vars with < 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 08612e81926857363618746fd01f9b08b7c3ac73
# Parent  7922a921d2034930780e41f1bc71d2c4ddb3b782
x86/mm: Another couple of comparisons of unsigned vars with < 0.

Adding the explicit (unsigned) casts in case enums ever end up signed.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 7922a921d203 -r 08612e819268 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
@@ -1305,7 +1305,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m->default_access,
     };
 
-    if ( access >= HVMMEM_access_default || access < 0 )
+    if ( (unsigned) access >= HVMMEM_access_default )
         return -EINVAL;
 
     a = memaccess[access];
@@ -1367,7 +1367,7 @@ int p2m_get_mem_access(struct domain *d,
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     
-    if ( a >= ARRAY_SIZE(memaccess) || a < 0 )
+    if ( (unsigned) a >= ARRAY_SIZE(memaccess) )
         return -ERANGE;
 
     *access =  memaccess[a];

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEt-0000Ft-Oe; Thu, 05 Apr 2012 16:08:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000Ei-QK
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [193.109.254.147:60536] by server-7.bemta-14.messagelabs.com id
	03/00-01627-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23015 invoked from network); 5 Apr 2012 16:08:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190450"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:41 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozS-00054Q-73	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:50 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozR-0004Ez-P5	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:49 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7922a921d2034930780e41f1bc71d2c4ddb3b782
Message-ID: <7922a921d2034930780e.1333641110@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:50 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 7 v2] xen: Add -Wno-unused-value to the
	clang CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 7922a921d2034930780e41f1bc71d2c4ddb3b782
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
xen: Add -Wno-unused-value to the clang CFLAGS

clang complains about a lot of functions and macros whose return value
is unused.  I started on patches to drop some functions' return values
and scatter (void)s around callers, but it was getting too messy.
Just turn off the warning instead.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r d690c7e896a2 -r 7922a921d203 Config.mk
--- a/Config.mk	Thu Apr 05 11:06:03 2012 +0100
+++ b/Config.mk	Thu Apr 05 16:49:15 2012 +0100
@@ -159,7 +159,8 @@ CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 # and is over-zealous with the printf format lint
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format
+# and is a bit too fierce about unused return values
+CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEu-0000GF-It; Thu, 05 Apr 2012 16:08:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEs-0000En-4D
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [85.158.139.83:16892] by server-8.bemta-5.messagelabs.com id
	B3/42-26964-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333642121!11392335!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28384 invoked from network); 5 Apr 2012 16:08:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="23913360"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:40 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozT-00054Z-Lw	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozT-0004FB-DE	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: a93381049790e4f8a02f2322851f78175c254c5b
Message-ID: <a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:53 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 7 v2] x86: fix memset(ptr, 0, sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID a93381049790e4f8a02f2322851f78175c254c5b
# Parent  4674ce03c62a3e916954fd445b4510ffe72e64f4
x86: fix memset(ptr, 0, sizeof ptr).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
@@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
 		return NULL;
 	}
 
-	memset(mc_ext, 0, sizeof(mc_ext));
+	memset(mc_ext, 0, sizeof(*mc_ext));
 	mc_ext->common.type = MC_TYPE_EXTENDED;
-	mc_ext->common.size = sizeof(mc_ext);
+	mc_ext->common.size = sizeof(*mc_ext);
 	mc_ext->mc_msrs = 3;
 
 	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
@@ -1232,11 +1232,10 @@ bool_t p2m_mem_access_check(unsigned lon
     }
 
     *req_ptr = NULL;
-    req = xmalloc(mem_event_request_t);
+    req = xzalloc(mem_event_request_t);
     if ( req )
     {
         *req_ptr = req;
-        memset(req, 0, sizeof(req));
         req->reason = MEM_EVENT_REASON_VIOLATION;
 
         /* Pause the current VCPU */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEu-0000Ga-WA; Thu, 05 Apr 2012 16:08:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEs-0000En-Kd
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [85.158.139.83:56383] by server-8.bemta-5.messagelabs.com id
	C8/42-26964-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333642121!11392335!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28413 invoked from network); 5 Apr 2012 16:08:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="23913361"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:41 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozR-00054N-Ol	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:49 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozR-0004Ew-CA	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:49 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:49 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series makes the hypervisor build with clang/LLVM again,
after a certain amount of bit-rot.

Since v1:
 - Changed an xmalloc+memset pair to xzalloc in the memset patch
 - Reworked the spinlock patch not to touch gcc builds
 - Added a patch to indirect all __section__ directives through a macro.
 - Commented up the ugly __attribute__((used)) change and moved it
   into the definition of __section().
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEt-0000Ft-Oe; Thu, 05 Apr 2012 16:08:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000Ei-QK
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [193.109.254.147:60536] by server-7.bemta-14.messagelabs.com id
	03/00-01627-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23015 invoked from network); 5 Apr 2012 16:08:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190450"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:41 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozS-00054Q-73	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:50 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozR-0004Ez-P5	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:49 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7922a921d2034930780e41f1bc71d2c4ddb3b782
Message-ID: <7922a921d2034930780e.1333641110@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:50 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 7 v2] xen: Add -Wno-unused-value to the
	clang CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 7922a921d2034930780e41f1bc71d2c4ddb3b782
# Parent  d690c7e896a26c54a5ab85458824059de72d5cba
xen: Add -Wno-unused-value to the clang CFLAGS

clang complains about a lot of functions and macros whose return value
is unused.  I started on patches to drop some functions' return values
and scatter (void)s around callers, but it was getting too messy.
Just turn off the warning instead.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r d690c7e896a2 -r 7922a921d203 Config.mk
--- a/Config.mk	Thu Apr 05 11:06:03 2012 +0100
+++ b/Config.mk	Thu Apr 05 16:49:15 2012 +0100
@@ -159,7 +159,8 @@ CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 # and is over-zealous with the printf format lint
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format
+# and is a bit too fierce about unused return values
+CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEs-0000FC-GR; Thu, 05 Apr 2012 16:08:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEq-0000EW-Fr
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:44 +0000
Received: from [193.109.254.147:25155] by server-11.bemta-14.messagelabs.com
	id A3/BF-05858-A83CD7F4; Thu, 05 Apr 2012 16:08:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 5 Apr 2012 16:08:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190438"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:38 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozU-00054i-Fz	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:52 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozU-0004FN-76	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:52 +0100
MIME-Version: 1.0
X-Mercurial-Node: 51174f350092962ad36e406adf7ae1f173330a37
Message-ID: <51174f350092962ad36e.1333641116@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:56 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 7 v2] x86: explicitly mark __initdata
 variables as used when building with clang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 51174f350092962ad36e406adf7ae1f173330a37
# Parent  fba1917c638768c0a4e45c507c29f1020e08dfc1
x86: explicitly mark __initdata variables as used when building with clang.

This stops LLVM from replacing it with a different, auto-generated
variable as part of an optimization.  (The auto-generated variable
ends up in the normal data section.)

Remove stray __read_mostly annotations on declarations that this unmasked.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r fba1917c6387 -r 51174f350092 xen/arch/x86/oprofile/op_x86_model.h
--- a/xen/arch/x86/oprofile/op_x86_model.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/oprofile/op_x86_model.h	Thu Apr 05 16:49:15 2012 +0100
@@ -53,6 +53,6 @@ extern struct op_x86_model_spec const op
 void arch_perfmon_setup_counters(void);
 
 extern int ppro_has_global_ctrl;
-extern struct op_x86_model_spec const *__read_mostly model;
+extern struct op_x86_model_spec const *model;
 
 #endif /* OP_X86_MODEL_H */
diff -r fba1917c6387 -r 51174f350092 xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/acpi/cpufreq/cpufreq.h	Thu Apr 05 16:49:15 2012 +0100
@@ -22,7 +22,7 @@
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
-extern bool_t __read_mostly cpufreq_verbose;
+extern bool_t cpufreq_verbose;
 
 struct cpufreq_governor;
 
diff -r fba1917c6387 -r 51174f350092 xen/include/xen/compiler.h
--- a/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
@@ -14,7 +14,13 @@
 #define always_inline __inline__ __attribute__ ((always_inline))
 #define noinline      __attribute__((noinline))
 
+#ifdef __clang__
+/* Clang can replace some vars with new automatic ones that go in .data;
+ * mark all explicit-segment vars 'used' to prevent that. */
+#define __section(s)      __attribute_used__ __attribute__((__section__(s)))
+#else
 #define __section(s)      __attribute__((__section__(s)))
+#endif
 #define __used_section(s) __attribute_used__ __attribute__((__section__(s)))
 #define __text_section(s) __attribute__((__section__(s)))
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEs-0000FC-GR; Thu, 05 Apr 2012 16:08:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEq-0000EW-Fr
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:44 +0000
Received: from [193.109.254.147:25155] by server-11.bemta-14.messagelabs.com
	id A3/BF-05858-A83CD7F4; Thu, 05 Apr 2012 16:08:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 5 Apr 2012 16:08:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190438"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:38 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozU-00054i-Fz	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:52 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozU-0004FN-76	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:52 +0100
MIME-Version: 1.0
X-Mercurial-Node: 51174f350092962ad36e406adf7ae1f173330a37
Message-ID: <51174f350092962ad36e.1333641116@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:56 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 7 v2] x86: explicitly mark __initdata
 variables as used when building with clang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 51174f350092962ad36e406adf7ae1f173330a37
# Parent  fba1917c638768c0a4e45c507c29f1020e08dfc1
x86: explicitly mark __initdata variables as used when building with clang.

This stops LLVM from replacing it with a different, auto-generated
variable as part of an optimization.  (The auto-generated variable
ends up in the normal data section.)

Remove stray __read_mostly annotations on declarations that this unmasked.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r fba1917c6387 -r 51174f350092 xen/arch/x86/oprofile/op_x86_model.h
--- a/xen/arch/x86/oprofile/op_x86_model.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/oprofile/op_x86_model.h	Thu Apr 05 16:49:15 2012 +0100
@@ -53,6 +53,6 @@ extern struct op_x86_model_spec const op
 void arch_perfmon_setup_counters(void);
 
 extern int ppro_has_global_ctrl;
-extern struct op_x86_model_spec const *__read_mostly model;
+extern struct op_x86_model_spec const *model;
 
 #endif /* OP_X86_MODEL_H */
diff -r fba1917c6387 -r 51174f350092 xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/acpi/cpufreq/cpufreq.h	Thu Apr 05 16:49:15 2012 +0100
@@ -22,7 +22,7 @@
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
-extern bool_t __read_mostly cpufreq_verbose;
+extern bool_t cpufreq_verbose;
 
 struct cpufreq_governor;
 
diff -r fba1917c6387 -r 51174f350092 xen/include/xen/compiler.h
--- a/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
@@ -14,7 +14,13 @@
 #define always_inline __inline__ __attribute__ ((always_inline))
 #define noinline      __attribute__((noinline))
 
+#ifdef __clang__
+/* Clang can replace some vars with new automatic ones that go in .data;
+ * mark all explicit-segment vars 'used' to prevent that. */
+#define __section(s)      __attribute_used__ __attribute__((__section__(s)))
+#else
 #define __section(s)      __attribute__((__section__(s)))
+#endif
 #define __used_section(s) __attribute_used__ __attribute__((__section__(s)))
 #define __text_section(s) __attribute__((__section__(s)))
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEs-0000Ex-3u; Thu, 05 Apr 2012 16:08:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEq-0000EV-Fp
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:44 +0000
Received: from [193.109.254.147:25195] by server-9.bemta-14.messagelabs.com id
	EC/F0-05787-B83CD7F4; Thu, 05 Apr 2012 16:08:43 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22696 invoked from network); 5 Apr 2012 16:08:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190441"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:39 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozT-00054c-Un	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozT-0004FF-MD	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0908535327a5b01e49b69cd96db464be21ff3ee6
Message-ID: <0908535327a5b01e49b6.1333641114@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:54 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 7 v2] x86: don't use .subsection when
	compiling with clang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 0908535327a5b01e49b69cd96db464be21ff3ee6
# Parent  a93381049790e4f8a02f2322851f78175c254c5b
x86: don't use .subsection when compiling with clang

LLVM's assembler doesn't support the .subsection directive, so put
the out-of-line failure path in .fixup instead.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a93381049790 -r 0908535327a5 xen/include/asm-x86/spinlock.h
--- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
@@ -45,11 +45,19 @@ static always_inline int _raw_read_trylo
     asm volatile (
         "    lock; decl %0         \n"
         "    jns 2f                \n"
+#ifdef __clang__ /* clang's builtin assember can't do .subsection */
+        "1:  .pushsection .fixup,\"ax\"\n"
+#else
         "1:  .subsection 1         \n"
+#endif
         "2:  lock; incl %0         \n"
         "    decl %1               \n"
         "    jmp 1b                \n"
+#ifdef __clang__
+        "    .popsection           \n"
+#else
         "    .subsection 0         \n"
+#endif
         : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
 
     return acquired;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEt-0000Fg-DN; Thu, 05 Apr 2012 16:08:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000Eh-Il
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:45 +0000
Received: from [85.158.139.83:16849] by server-12.bemta-5.messagelabs.com id
	46/3C-05587-C83CD7F4; Thu, 05 Apr 2012 16:08:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333642121!11392335!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28346 invoked from network); 5 Apr 2012 16:08:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="23913358"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:39 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozU-00054f-6k	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:52 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozT-0004FJ-V9	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:52 +0100
MIME-Version: 1.0
X-Mercurial-Node: fba1917c638768c0a4e45c507c29f1020e08dfc1
Message-ID: <fba1917c638768c0a4e4.1333641115@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:55 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 7 v2] xen: define __section() and friends
 and use them for section annotations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID fba1917c638768c0a4e45c507c29f1020e08dfc1
# Parent  0908535327a5b01e49b69cd96db464be21ff3ee6
xen: define __section() and friends and use them for section annotations.

By itself this is just code-tidying, but it's also useful for the
following patch, which will adjust __section() for clang compiles.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-arm/cache.h
--- a/xen/include/asm-arm/cache.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-arm/cache.h	Thu Apr 05 16:49:15 2012 +0100
@@ -7,7 +7,7 @@
 #define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
 #define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
 
-#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#define __read_mostly __section(".data.read_mostly")
 
 #endif
 /*
diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-arm/percpu.h
--- a/xen/include/asm-arm/percpu.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-arm/percpu.h	Thu Apr 05 16:49:15 2012 +0100
@@ -8,7 +8,7 @@ void percpu_init_areas(void);
 
 /* Separate out the type, so (int[3], foo) works. */
 #define __DEFINE_PER_CPU(type, name, suffix)                    \
-    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
 
diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-x86/cache.h
--- a/xen/include/asm-x86/cache.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-x86/cache.h	Thu Apr 05 16:49:15 2012 +0100
@@ -10,6 +10,6 @@
 #define L1_CACHE_SHIFT	(CONFIG_X86_L1_CACHE_SHIFT)
 #define L1_CACHE_BYTES	(1 << L1_CACHE_SHIFT)
 
-#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#define __read_mostly __section(".data.read_mostly")
 
 #endif
diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-x86/percpu.h
--- a/xen/include/asm-x86/percpu.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-x86/percpu.h	Thu Apr 05 16:49:15 2012 +0100
@@ -9,7 +9,7 @@ void percpu_init_areas(void);
 
 /* Separate out the type, so (int[3], foo) works. */
 #define __DEFINE_PER_CPU(type, name, suffix)                    \
-    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
 /* var is in discarded region: offset to particular copy we want */
diff -r 0908535327a5 -r fba1917c6387 xen/include/xen/compiler.h
--- a/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
@@ -14,6 +14,10 @@
 #define always_inline __inline__ __attribute__ ((always_inline))
 #define noinline      __attribute__((noinline))
 
+#define __section(s)      __attribute__((__section__(s)))
+#define __used_section(s) __attribute_used__ __attribute__((__section__(s)))
+#define __text_section(s) __attribute__((__section__(s)))
+
 #ifdef INIT_SECTIONS_ONLY
 /*
  * For sources indicated to have only init code, make sure even
diff -r 0908535327a5 -r fba1917c6387 xen/include/xen/init.h
--- a/xen/include/xen/init.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/init.h	Thu Apr 05 16:49:15 2012 +0100
@@ -7,20 +7,13 @@
  * Mark functions and data as being only used at initialization
  * or exit time.
  */
-#define __init       \
-    __attribute__ ((__section__ (".init.text")))
-#define __exit       \
-    __attribute_used__ __attribute__ ((__section__(".exit.text")))
-#define __initdata   \
-    __attribute__ ((__section__ (".init.data")))
-#define __exitdata   \
-    __attribute_used__ __attribute__ ((__section__ (".exit.data")))
-#define __initsetup  \
-    __attribute_used__ __attribute__ ((__section__ (".init.setup")))
-#define __init_call(lvl)  \
-    __attribute_used__ __attribute__ ((__section__ (".initcall" lvl ".init")))
-#define __exit_call  \
-    __attribute_used__ __attribute__ ((__section__ (".exitcall.exit")))
+#define __init            __text_section(".init.text")
+#define __exit            __text_section(".exit.text")
+#define __initdata        __section(".init.data")
+#define __exitdata        __used_section(".exit.data")
+#define __initsetup       __used_section(".init.setup")
+#define __init_call(lvl)  __used_section(".initcall" lvl ".init")
+#define __exit_call       __used_section(".exitcall.exit")
 
 /* These macros are used to mark some functions or 
  * initialized data (doesn't apply to uninitialized data)
@@ -95,7 +88,7 @@ struct kernel_param {
 extern struct kernel_param __setup_start, __setup_end;
 
 #define __setup_str static __initdata __attribute__((__aligned__(1))) char
-#define __kparam static __attribute_used__ __initsetup struct kernel_param
+#define __kparam static __initsetup struct kernel_param
 
 #define custom_param(_name, _var) \
     __setup_str __setup_str_##_var[] = _name; \
diff -r 0908535327a5 -r fba1917c6387 xen/include/xen/spinlock.h
--- a/xen/include/xen/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
@@ -77,8 +77,8 @@ struct lock_profile_qhead {
 
 #define _LOCK_PROFILE(name) { 0, #name, &name, 0, 0, 0, 0, 0 }
 #define _LOCK_PROFILE_PTR(name)                                               \
-    static struct lock_profile *__lock_profile_##name __attribute_used__      \
-    __attribute__ ((__section__(".lockprofile.data"))) =                      \
+    static struct lock_profile *__lock_profile_##name                         \
+    __used_section(".lockprofile.data") =                                     \
     &__lock_profile_data_##name
 #define _SPIN_LOCK_UNLOCKED(x) { _RAW_SPIN_LOCK_UNLOCKED, 0xfffu, 0,          \
                                  _LOCK_DEBUG, x }
diff -r 0908535327a5 -r fba1917c6387 xen/include/xsm/xsm.h
--- a/xen/include/xsm/xsm.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xsm/xsm.h	Thu Apr 05 16:49:15 2012 +0100
@@ -44,7 +44,7 @@ extern xsm_initcall_t __xsm_initcall_sta
 
 #define xsm_initcall(fn) \
     static xsm_initcall_t __initcall_##fn \
-    __attribute_used__ __attribute__((__section__(".xsm_initcall.init"))) = fn
+    __used_section(".xsm_initcall.init") = fn
 
 struct xsm_operations {
     void (*security_domaininfo) (struct domain *d,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEt-0000Fg-DN; Thu, 05 Apr 2012 16:08:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000Eh-Il
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:45 +0000
Received: from [85.158.139.83:16849] by server-12.bemta-5.messagelabs.com id
	46/3C-05587-C83CD7F4; Thu, 05 Apr 2012 16:08:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333642121!11392335!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ2MzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28346 invoked from network); 5 Apr 2012 16:08:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="23913358"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:39 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozU-00054f-6k	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:52 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozT-0004FJ-V9	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:52 +0100
MIME-Version: 1.0
X-Mercurial-Node: fba1917c638768c0a4e45c507c29f1020e08dfc1
Message-ID: <fba1917c638768c0a4e4.1333641115@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:55 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 7 v2] xen: define __section() and friends
 and use them for section annotations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID fba1917c638768c0a4e45c507c29f1020e08dfc1
# Parent  0908535327a5b01e49b69cd96db464be21ff3ee6
xen: define __section() and friends and use them for section annotations.

By itself this is just code-tidying, but it's also useful for the
following patch, which will adjust __section() for clang compiles.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-arm/cache.h
--- a/xen/include/asm-arm/cache.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-arm/cache.h	Thu Apr 05 16:49:15 2012 +0100
@@ -7,7 +7,7 @@
 #define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
 #define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
 
-#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#define __read_mostly __section(".data.read_mostly")
 
 #endif
 /*
diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-arm/percpu.h
--- a/xen/include/asm-arm/percpu.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-arm/percpu.h	Thu Apr 05 16:49:15 2012 +0100
@@ -8,7 +8,7 @@ void percpu_init_areas(void);
 
 /* Separate out the type, so (int[3], foo) works. */
 #define __DEFINE_PER_CPU(type, name, suffix)                    \
-    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
 
diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-x86/cache.h
--- a/xen/include/asm-x86/cache.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-x86/cache.h	Thu Apr 05 16:49:15 2012 +0100
@@ -10,6 +10,6 @@
 #define L1_CACHE_SHIFT	(CONFIG_X86_L1_CACHE_SHIFT)
 #define L1_CACHE_BYTES	(1 << L1_CACHE_SHIFT)
 
-#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#define __read_mostly __section(".data.read_mostly")
 
 #endif
diff -r 0908535327a5 -r fba1917c6387 xen/include/asm-x86/percpu.h
--- a/xen/include/asm-x86/percpu.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-x86/percpu.h	Thu Apr 05 16:49:15 2012 +0100
@@ -9,7 +9,7 @@ void percpu_init_areas(void);
 
 /* Separate out the type, so (int[3], foo) works. */
 #define __DEFINE_PER_CPU(type, name, suffix)                    \
-    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
 /* var is in discarded region: offset to particular copy we want */
diff -r 0908535327a5 -r fba1917c6387 xen/include/xen/compiler.h
--- a/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/compiler.h	Thu Apr 05 16:49:15 2012 +0100
@@ -14,6 +14,10 @@
 #define always_inline __inline__ __attribute__ ((always_inline))
 #define noinline      __attribute__((noinline))
 
+#define __section(s)      __attribute__((__section__(s)))
+#define __used_section(s) __attribute_used__ __attribute__((__section__(s)))
+#define __text_section(s) __attribute__((__section__(s)))
+
 #ifdef INIT_SECTIONS_ONLY
 /*
  * For sources indicated to have only init code, make sure even
diff -r 0908535327a5 -r fba1917c6387 xen/include/xen/init.h
--- a/xen/include/xen/init.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/init.h	Thu Apr 05 16:49:15 2012 +0100
@@ -7,20 +7,13 @@
  * Mark functions and data as being only used at initialization
  * or exit time.
  */
-#define __init       \
-    __attribute__ ((__section__ (".init.text")))
-#define __exit       \
-    __attribute_used__ __attribute__ ((__section__(".exit.text")))
-#define __initdata   \
-    __attribute__ ((__section__ (".init.data")))
-#define __exitdata   \
-    __attribute_used__ __attribute__ ((__section__ (".exit.data")))
-#define __initsetup  \
-    __attribute_used__ __attribute__ ((__section__ (".init.setup")))
-#define __init_call(lvl)  \
-    __attribute_used__ __attribute__ ((__section__ (".initcall" lvl ".init")))
-#define __exit_call  \
-    __attribute_used__ __attribute__ ((__section__ (".exitcall.exit")))
+#define __init            __text_section(".init.text")
+#define __exit            __text_section(".exit.text")
+#define __initdata        __section(".init.data")
+#define __exitdata        __used_section(".exit.data")
+#define __initsetup       __used_section(".init.setup")
+#define __init_call(lvl)  __used_section(".initcall" lvl ".init")
+#define __exit_call       __used_section(".exitcall.exit")
 
 /* These macros are used to mark some functions or 
  * initialized data (doesn't apply to uninitialized data)
@@ -95,7 +88,7 @@ struct kernel_param {
 extern struct kernel_param __setup_start, __setup_end;
 
 #define __setup_str static __initdata __attribute__((__aligned__(1))) char
-#define __kparam static __attribute_used__ __initsetup struct kernel_param
+#define __kparam static __initsetup struct kernel_param
 
 #define custom_param(_name, _var) \
     __setup_str __setup_str_##_var[] = _name; \
diff -r 0908535327a5 -r fba1917c6387 xen/include/xen/spinlock.h
--- a/xen/include/xen/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xen/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
@@ -77,8 +77,8 @@ struct lock_profile_qhead {
 
 #define _LOCK_PROFILE(name) { 0, #name, &name, 0, 0, 0, 0, 0 }
 #define _LOCK_PROFILE_PTR(name)                                               \
-    static struct lock_profile *__lock_profile_##name __attribute_used__      \
-    __attribute__ ((__section__(".lockprofile.data"))) =                      \
+    static struct lock_profile *__lock_profile_##name                         \
+    __used_section(".lockprofile.data") =                                     \
     &__lock_profile_data_##name
 #define _SPIN_LOCK_UNLOCKED(x) { _RAW_SPIN_LOCK_UNLOCKED, 0xfffu, 0,          \
                                  _LOCK_DEBUG, x }
diff -r 0908535327a5 -r fba1917c6387 xen/include/xsm/xsm.h
--- a/xen/include/xsm/xsm.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/xsm/xsm.h	Thu Apr 05 16:49:15 2012 +0100
@@ -44,7 +44,7 @@ extern xsm_initcall_t __xsm_initcall_sta
 
 #define xsm_initcall(fn) \
     static xsm_initcall_t __initcall_##fn \
-    __attribute_used__ __attribute__((__section__(".xsm_initcall.init"))) = fn
+    __used_section(".xsm_initcall.init") = fn
 
 struct xsm_operations {
     void (*security_domaininfo) (struct domain *d,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEu-0000G2-4R; Thu, 05 Apr 2012 16:08:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000Eo-VU
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [85.158.143.35:44249] by server-3.bemta-4.messagelabs.com id
	9D/C0-05853-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333642122!15060432!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9666 invoked from network); 5 Apr 2012 16:08:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190447"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:40 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozT-00054W-Cw	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozS-0004F7-M9	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4674ce03c62a3e916954fd445b4510ffe72e64f4
Message-ID: <4674ce03c62a3e916954.1333641112@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:52 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 7 v2] x86: fix logical ANDs used to mask
	bitfields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 4674ce03c62a3e916954fd445b4510ffe72e64f4
# Parent  08612e81926857363618746fd01f9b08b7c3ac73
x86: fix logical ANDs used to mask bitfields.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>

diff -r 08612e819268 -r 4674ce03c62a xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 16:49:15 2012 +0100
@@ -752,7 +752,7 @@ static void svm_lwp_interrupt(struct cpu
     ack_APIC_irq();
     vlapic_set_irq(
         vcpu_vlapic(curr),
-        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) && 0xff,
+        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) & 0xff,
         0);
 }
 
diff -r 08612e819268 -r 4674ce03c62a xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 16:49:15 2012 +0100
@@ -1382,7 +1382,7 @@ void vmx_inject_extint(int trap)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_EXT_INTR_MASK ) {
+        if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
                HVM_DELIVER_NO_ERROR_CODE);
@@ -1401,7 +1401,7 @@ void vmx_inject_nmi(void)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_NMI_EXITING ) {
+        if ( pin_based_cntrl & PIN_BASED_NMI_EXITING ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
                HVM_DELIVER_NO_ERROR_CODE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEs-0000Ex-3u; Thu, 05 Apr 2012 16:08:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEq-0000EV-Fp
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:44 +0000
Received: from [193.109.254.147:25195] by server-9.bemta-14.messagelabs.com id
	EC/F0-05787-B83CD7F4; Thu, 05 Apr 2012 16:08:43 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333642120!3425007!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22696 invoked from network); 5 Apr 2012 16:08:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190441"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:39 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozT-00054c-Un	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozT-0004FF-MD	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0908535327a5b01e49b69cd96db464be21ff3ee6
Message-ID: <0908535327a5b01e49b6.1333641114@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:54 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 7 v2] x86: don't use .subsection when
	compiling with clang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 0908535327a5b01e49b69cd96db464be21ff3ee6
# Parent  a93381049790e4f8a02f2322851f78175c254c5b
x86: don't use .subsection when compiling with clang

LLVM's assembler doesn't support the .subsection directive, so put
the out-of-line failure path in .fixup instead.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a93381049790 -r 0908535327a5 xen/include/asm-x86/spinlock.h
--- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
@@ -45,11 +45,19 @@ static always_inline int _raw_read_trylo
     asm volatile (
         "    lock; decl %0         \n"
         "    jns 2f                \n"
+#ifdef __clang__ /* clang's builtin assember can't do .subsection */
+        "1:  .pushsection .fixup,\"ax\"\n"
+#else
         "1:  .subsection 1         \n"
+#endif
         "2:  lock; incl %0         \n"
         "    decl %1               \n"
         "    jmp 1b                \n"
+#ifdef __clang__
+        "    .popsection           \n"
+#else
         "    .subsection 0         \n"
+#endif
         : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
 
     return acquired;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpEu-0000G2-4R; Thu, 05 Apr 2012 16:08:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SFpEr-0000Eo-VU
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:08:46 +0000
Received: from [85.158.143.35:44249] by server-3.bemta-4.messagelabs.com id
	9D/C0-05853-D83CD7F4; Thu, 05 Apr 2012 16:08:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333642122!15060432!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9666 invoked from network); 5 Apr 2012 16:08:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189190447"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 12:08:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 5 Apr 2012 12:08:40 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SFozT-00054W-Cw	for xen-devel@lists.xen.org;
	Thu, 05 Apr 2012 16:52:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SFozS-0004F7-M9	for
	xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:52:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4674ce03c62a3e916954fd445b4510ffe72e64f4
Message-ID: <4674ce03c62a3e916954.1333641112@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 5 Apr 2012 16:51:52 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 7 v2] x86: fix logical ANDs used to mask
	bitfields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1333640955 -3600
# Node ID 4674ce03c62a3e916954fd445b4510ffe72e64f4
# Parent  08612e81926857363618746fd01f9b08b7c3ac73
x86: fix logical ANDs used to mask bitfields.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>

diff -r 08612e819268 -r 4674ce03c62a xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 05 16:49:15 2012 +0100
@@ -752,7 +752,7 @@ static void svm_lwp_interrupt(struct cpu
     ack_APIC_irq();
     vlapic_set_irq(
         vcpu_vlapic(curr),
-        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) && 0xff,
+        (curr->arch.hvm_svm.guest_lwp_cfg >> 40) & 0xff,
         0);
 }
 
diff -r 08612e819268 -r 4674ce03c62a xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 16:49:15 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 05 16:49:15 2012 +0100
@@ -1382,7 +1382,7 @@ void vmx_inject_extint(int trap)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_EXT_INTR_MASK ) {
+        if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
                HVM_DELIVER_NO_ERROR_CODE);
@@ -1401,7 +1401,7 @@ void vmx_inject_nmi(void)
     if ( nestedhvm_vcpu_in_guestmode(v) ) {
         pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, 
                                      PIN_BASED_VM_EXEC_CONTROL);
-        if ( pin_based_cntrl && PIN_BASED_NMI_EXITING ) {
+        if ( pin_based_cntrl & PIN_BASED_NMI_EXITING ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
                HVM_DELIVER_NO_ERROR_CODE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:20:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:20:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpQO-0001SA-73; Thu, 05 Apr 2012 16:20:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFpQN-0001S5-8w
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 16:20:39 +0000
Received: from [193.109.254.147:3377] by server-9.bemta-14.messagelabs.com id
	EA/B4-05787-656CD7F4; Thu, 05 Apr 2012 16:20:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333642828!3439659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12596 invoked from network); 5 Apr 2012 16:20:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="11800633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 16:20:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 17:20:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFpQB-0005Mf-UK; Thu, 05 Apr 2012 16:20:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFpQB-0005Up-0q;
	Thu, 05 Apr 2012 17:20:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20349.50762.577023.819759@mariner.uk.xensource.com>
Date: Thu, 5 Apr 2012 17:20:26 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120405155029.GC1854@phenom.dumpdata.com>
References: <osstest-12574-mainreport@xen.org>
	<20120405155029.GC1854@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-linus test] 12574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [linux-linus test] 12574: regressions - FAIL"):
> On Thu, Apr 05, 2012 at 04:20:09PM +0100, xen.org wrote:
> > flight 12574 linux-linus real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/12574/
> 
> So I know what fix to push for this.

Excellent.

>  Shall I tell you when it should
> be upstream and when it should be working?

No, there is no need.  I have this set up to run daily, so it should
come through in due course.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:20:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:20:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpQO-0001SA-73; Thu, 05 Apr 2012 16:20:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFpQN-0001S5-8w
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 16:20:39 +0000
Received: from [193.109.254.147:3377] by server-9.bemta-14.messagelabs.com id
	EA/B4-05787-656CD7F4; Thu, 05 Apr 2012 16:20:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333642828!3439659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12596 invoked from network); 5 Apr 2012 16:20:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="11800633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 16:20:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 17:20:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SFpQB-0005Mf-UK; Thu, 05 Apr 2012 16:20:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SFpQB-0005Up-0q;
	Thu, 05 Apr 2012 17:20:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20349.50762.577023.819759@mariner.uk.xensource.com>
Date: Thu, 5 Apr 2012 17:20:26 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120405155029.GC1854@phenom.dumpdata.com>
References: <osstest-12574-mainreport@xen.org>
	<20120405155029.GC1854@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-linus test] 12574: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [linux-linus test] 12574: regressions - FAIL"):
> On Thu, Apr 05, 2012 at 04:20:09PM +0100, xen.org wrote:
> > flight 12574 linux-linus real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/12574/
> 
> So I know what fix to push for this.

Excellent.

>  Shall I tell you when it should
> be upstream and when it should be working?

No, there is no need.  I have this set up to run daily, so it should
come through in due course.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:35:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpec-0001dE-Nh; Thu, 05 Apr 2012 16:35:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singh.rahul.1983@gmail.com>) id 1SFpeb-0001d9-Ll
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:35:21 +0000
Received: from [193.109.254.147:59013] by server-11.bemta-14.messagelabs.com
	id A9/38-05858-9C9CD7F4; Thu, 05 Apr 2012 16:35:21 +0000
X-Env-Sender: singh.rahul.1983@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333643716!3435953!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 423 invoked from network); 5 Apr 2012 16:35:17 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:35:17 -0000
Received: by qadb15 with SMTP id b15so1541389qad.16
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 09:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer;
	bh=IjqCt/J6mwsUaoXPPUIaCM9ClSR7vwKhwyh3fhrSkDU=;
	b=jqOhHUoWsb0HFKzmbOW31QRk+ba47KFzct7w8aiLRU89GBuaUGhLCkqhDcALAH3RIg
	+XXbvdld3lSMm3YFmq/BXJT7k+n3bo/eY/BSC4JLimvAUmEN500+g4leiSzqPZR48jXn
	em4V8fbM+3hwg+xHxRWRl4hwadrTja+mCYh0n2qU8QDPgplDiaoqZle4wmE0xMA1Jh4q
	kpf8beq2fxtJBO3yBA21haiwu2HKCCieB9QaMVpP51r1OlVq8sdvyK27MtUsUlxOLm7/
	BFWB4vJAj6c/AKXd/wYbrEZkyrX90dznBJ+CNEI/H79A4uK9ueFR2YpBFqMujHDAzeZ6
	w08A==
Received: by 10.224.73.17 with SMTP id o17mr4450892qaj.76.1333643716140;
	Thu, 05 Apr 2012 09:35:16 -0700 (PDT)
Received: from moblix.cs.umass.edu (moblix.cs.umass.edu. [128.119.245.142])
	by mx.google.com with ESMTPS id df8sm6806099qab.6.2012.04.05.09.35.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 05 Apr 2012 09:35:14 -0700 (PDT)
From: Rahul Singh <singh.rahul.1983@gmail.com>
Date: Thu, 5 Apr 2012 12:35:12 -0400
Message-Id: <4B36053D-1489-4739-B9E9-48E0CD30CCE8@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] libxc DPRINTF statements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
I am trying to make some modifications to the live migration part of Xen code. As a first step in this direction i want to figure out how many pages were dirtied in each round of live migration. I compiled the latest xen-unstable-4.2 version. Through some effort i have been able to figure out that the sending part of live migration code resides in xen-unstable/tools/libxc/xc_domain_save.c. This file has a number of DPRINTF statements in it, but i don't see these statements in either /var/log/xen/xend.log or xend-debug.log. Where do these DPRINTF statements go ? How do i turn these DPRINTF statements on ?

Thanking you,
Rahul.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 16:35:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 16:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFpec-0001dE-Nh; Thu, 05 Apr 2012 16:35:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singh.rahul.1983@gmail.com>) id 1SFpeb-0001d9-Ll
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 16:35:21 +0000
Received: from [193.109.254.147:59013] by server-11.bemta-14.messagelabs.com
	id A9/38-05858-9C9CD7F4; Thu, 05 Apr 2012 16:35:21 +0000
X-Env-Sender: singh.rahul.1983@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1333643716!3435953!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 423 invoked from network); 5 Apr 2012 16:35:17 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 16:35:17 -0000
Received: by qadb15 with SMTP id b15so1541389qad.16
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 09:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer;
	bh=IjqCt/J6mwsUaoXPPUIaCM9ClSR7vwKhwyh3fhrSkDU=;
	b=jqOhHUoWsb0HFKzmbOW31QRk+ba47KFzct7w8aiLRU89GBuaUGhLCkqhDcALAH3RIg
	+XXbvdld3lSMm3YFmq/BXJT7k+n3bo/eY/BSC4JLimvAUmEN500+g4leiSzqPZR48jXn
	em4V8fbM+3hwg+xHxRWRl4hwadrTja+mCYh0n2qU8QDPgplDiaoqZle4wmE0xMA1Jh4q
	kpf8beq2fxtJBO3yBA21haiwu2HKCCieB9QaMVpP51r1OlVq8sdvyK27MtUsUlxOLm7/
	BFWB4vJAj6c/AKXd/wYbrEZkyrX90dznBJ+CNEI/H79A4uK9ueFR2YpBFqMujHDAzeZ6
	w08A==
Received: by 10.224.73.17 with SMTP id o17mr4450892qaj.76.1333643716140;
	Thu, 05 Apr 2012 09:35:16 -0700 (PDT)
Received: from moblix.cs.umass.edu (moblix.cs.umass.edu. [128.119.245.142])
	by mx.google.com with ESMTPS id df8sm6806099qab.6.2012.04.05.09.35.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 05 Apr 2012 09:35:14 -0700 (PDT)
From: Rahul Singh <singh.rahul.1983@gmail.com>
Date: Thu, 5 Apr 2012 12:35:12 -0400
Message-Id: <4B36053D-1489-4739-B9E9-48E0CD30CCE8@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] libxc DPRINTF statements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
I am trying to make some modifications to the live migration part of Xen code. As a first step in this direction i want to figure out how many pages were dirtied in each round of live migration. I compiled the latest xen-unstable-4.2 version. Through some effort i have been able to figure out that the sending part of live migration code resides in xen-unstable/tools/libxc/xc_domain_save.c. This file has a number of DPRINTF statements in it, but i don't see these statements in either /var/log/xen/xend.log or xend-debug.log. Where do these DPRINTF statements go ? How do i turn these DPRINTF statements on ?

Thanking you,
Rahul.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 17:39:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 17:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFqeH-0002Oy-G4; Thu, 05 Apr 2012 17:39:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFqeF-0002Ot-Mv
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 17:39:04 +0000
Received: from [85.158.143.35:56223] by server-2.bemta-4.messagelabs.com id
	3C/6B-17550-6B8DD7F4; Thu, 05 Apr 2012 17:39:02 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333647541!5882162!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNDMx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32222 invoked from network); 5 Apr 2012 17:39:01 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 17:39:01 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFqeD-0004qR-En
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 18:39:01 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Thu, 5 Apr 2012 18:37:27 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 5 Apr 2012 18:37:26 +0100
Thread-Topic: lastest xen unstable crash
Thread-Index: AQHNE1LEjObst9pxYU+OBx0LJG67mA==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
Content-Type: multipart/mixed;
	boundary="_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_"
MIME-Version: 1.0
Subject: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

I was trying to build a new machine but the system keeps rebooting.
I used the lasted unstable version from xen-unstable.hg.

I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-ge=
neric).

The output to my serial console is attached.

Cheers,
Francisco=

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_
Content-Type: text/plain; name="xen_crash.txt"
Content-Description: xen_crash.txt
Content-Disposition: attachment; filename="xen_crash.txt"; size=14884;
	creation-date="Thu, 05 Apr 2012 18:32:36 GMT";
	modification-date="Thu, 05 Apr 2012 18:32:36 GMT"
Content-Transfer-Encoding: base64

c2VyaWFsLW92ZXItbGFuIHJlZGlyZWN0aW9uIG9rCmNvbm5lY3RlZCBub3csIHVzZSBeXSB0byBl
c2NhcGUKIF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICAgICAgICAgICAgICAgICAg
IF8gICAgICAgIF8gICAgIF8gICAgICAKIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwg
ICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwgJ18g
XCAgfCB8fCB8XyAgIF9fKSB8X198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBf
IFwKICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy98X198IHxffCB8IHwgfCBcX18gXCB8
fCAoX3wgfCB8XykgfCB8ICBfXy8KIC9fL1xfXF9fX3xffCB8X3wgICAgfF98KF8pX19fX198ICAg
XF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
KFhFTikgWGVuIHZlcnNpb24gNC4yLXVuc3RhYmxlIChyb290QHh4eHh4eHgpIChnY2MgdmVyc2lv
biA0LjYuMSAoVWJ1bnR1L0xpbmFybyA0LjYuMS05dWJ1bnR1MykgKSBUaHUgQXByICA1IDE3OjM0
OjE2IEJTVCAyMDEyCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IE1vbiBBcHIgMDIgMTg6MTQ6MzEg
MjAxMiArMDEwMCAyNTEzODoyMzg2Mjg4YjFiZjEKKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3lu
Y2hyb25vdXMuCihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OS0xMnVidW50dTUKKFhFTikgQ29t
bWFuZCBsaW5lOiBwbGFjZWhvbGRlciBsb2dsdmw9YWxsIHN5bmNfY29uc29sZSBjb25zb2xlX3Rv
X3JpbmcgY29tMT0xMTUyMDAsOG4xLDB4MzA5MCwxOSBjb25zb2xlPWNvbTEKKFhFTikgVmlkZW8g
aW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2RlIDgweDI1LCBmb250IDh4MTYKKFhF
TikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCihY
RU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAxIE1CUiBzaWduYXR1cmVzCihYRU4p
ICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJBTSBt
YXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZWMwMCAodXNhYmxlKQoo
WEVOKSAgMDAwMDAwMDAwMDA5ZWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQooWEVO
KSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVOKSAg
MDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAw
MDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAw
MjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDQwMDAw
MDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDQwMjAwMDAw
IC0gMDAwMDAwMDBhYTFkMDAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDBhYTFkMDAwMCAtIDAw
MDAwMDAwYWExZDAyMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBhYTFkMDIwMCAtIDAwMDAw
MDAwYWExZDMwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBhYTFkMzAwMCAtIDAwMDAwMDAw
YWEyZDAwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBhYTJkMDAwMCAtIDAwMDAwMDAwYWEy
ZjAwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwYWEyZjAwMDAgLSAwMDAwMDAwMGFmYTAw
MDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZjgwMDAwMDAgLSAwMDAwMDAwMGZjMDAwMDAw
IChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMTAwMDAgLSAwMDAwMDAwMGZlZDFhMDAwIChyZXNl
cnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDIwMDAwIChyZXNlcnZl
ZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkK
KFhFTikgIDAwMDAwMDAwZmZjMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKKFhF
TikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWNlNjAwMDAwICh1c2FibGUpCihYRU4pIEFD
UEk6IFJTRFAgMDAwRjAwMzAsIDAwMTQgKHIwIFRPU0hJQikKKFhFTikgQUNQSTogUlNEVCBBQTJF
RjAzOCwgMDA1OCAocjEgVE9TSElCIEEwMDdEICAgICAgICAgICAzICAgICAgIDEwMDAwMTMpCihY
RU4pIEFDUEk6IEZBQ1AgQUEyRUUwMDAsIDAwODEgKHIyIFRPU0hJQiBBMDA3RCAgICAgICAgICAg
MyBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJOiBEU0RUIEFBMkREMDAwLCA4QTQ2IChyMiBUT1NI
SUIgQTAwN0QgICAgMjAxMTEyMjAgSU5UTCAyMDA2MTEwOSkKKFhFTikgQUNQSTogRkFDUyBBQTJB
RDAwMCwgMDA0MAooWEVOKSBBQ1BJOiBIUEVUIEFBMkVEMDAwLCAwMDM4IChyMSBUT1NISUIgQTAw
N0QgICAgICAgICAgIDEgTE9IUiAgICAgICA1RikKKFhFTikgQUNQSTogQVBJQyBBQTJFQzAwMCwg
MDBCQyAocjEgVE9TSElCIEEwMDdEICAgICAgICAgICAxIExPSFIgICAgICAgNUYpCihYRU4pIEFD
UEk6IE1DRkcgQUEyRUIwMDAsIDAwM0MgKHIxIFRPU0hJQiBBMDA3RCAgICAgICAgICAgMSBMT0hS
ICAgICAgIDVGKQooWEVOKSBBQ1BJOiBBU0YhIEFBMkVBMDAwLCAwMEEwIChyMzIgVE9TSElCIEEw
MDdEICAgICAgICAgICAxIExPSFIgICAgICAgNUYpCihYRU4pIEFDUEk6IFRDUEEgQUEyRTkwMDAs
IDAwMzIgKHIyIFRPU0hJQiBBMDA3RCAgICAgICAgICAgMCBMT0hSICAgICAgIDVGKQooWEVOKSBB
Q1BJOiBCT09UIEFBMkU4MDAwLCAwMDI4IChyMSBUT1NISUIgQTAwN0QgICAgICAgICAgIDAgTE9I
UiAgICAgICA1RikKKFhFTikgQUNQSTogU0xJQyBBQTJFNzAwMCwgMDE3NiAocjEgVE9TSElCIEEw
MDdEICAgICAgICAgICAwIExPSFIgICAgICAgNUYpCihYRU4pIEFDUEk6IFNTRFQgQUEyREMwMDAs
IDAzOTUgKHIxIFRPU0hJQiBTYXRhQWhjaSAgICAgMTAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBB
Q1BJOiBTU0RUIEFBMkQ5MDAwLCAwNzIwIChyMSBUT1NISUIgUHRpZERldmMgICAgIDEwMDAgSU5U
TCAyMDA2MTEwOSkKKFhFTikgQUNQSTogU1NEVCBBQTJENzAwMCwgMDgyNyAocjEgIFBtUmVmICBD
cHUwSXN0ICAgICAzMDAwIElOVEwgMjAwNjExMDkpCihYRU4pIEFDUEk6IFNTRFQgQUEyRDYwMDAs
IDA5OTYgKHIxICBQbVJlZiAgICBDcHVQbSAgICAgMzAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBB
Q1BJOiBETUFSIEFBMkQ1MDAwLCAwMTEwIChyMSBJTlRFTCAgICAgIFNOQiAgICAgICAgIDEgSU5U
TCAgICAgICAgMSkKKFhFTikgU3lzdGVtIFJBTTogNjAxOU1CICg2MTYzODk2a0IpCihYRU4pIE5v
IE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZAooWEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAw
MDAwMDAwMDAtMDAwMDAwMDFjZTYwMDAwMAooWEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZAoo
WEVOKSBETUkgMi41IHByZXNlbnQuCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKKFhF
TikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgKKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJ
TkZPOiBwbTF4X2NudFs0MDQsMF0sIHBtMXhfZXZ0WzQwMCwwXQooWEVOKSBBQ1BJOiAgICAgICAg
ICAgICAgICAgIHdha2V1cF92ZWNbYWEyYWQwMGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTog
TG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMwIDY6MTAgQVBJ
QyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4
MDFdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMSA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVO
KSBQcm9jZXNzb3IgIzIgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMzIDY6
MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGlj
X2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBp
Y19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFw
aWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxh
cGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgw
MF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4
MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsw
eDAyXSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRb
MHgwM10gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk
WzB4MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9p
ZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlf
aWRbMHgwNl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3Bp
X2lkWzB4MDddIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgw
Ml0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDIsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMKKFhFTikgQUNQ
STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhF
TikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBs
ZXZlbCkKKFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEy
IHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KKFhF
TikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDEgSS9PIEFQSUNzCihYRU4pIEFD
UEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhmZWQwMDAwMAooWEVOKSBUYWJsZSBpcyBu
b3QgZm91bmQhCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBp
bmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoNCBob3RwbHVnIENQVXMpCihY
RU4pIElSUSBsaW1pdHM6IDI0IEdTSSwgNzYwIE1TSS9NU0ktWAooWEVOKSBTd2l0Y2hlZCB0byBB
UElDIGRyaXZlciB4MmFwaWNfY2x1c3Rlci4KKFhFTikgVXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3Jl
ZGl0IFNjaGVkdWxlciAoY3JlZGl0KQooWEVOKSBEZXRlY3RlZCAyNjkxLjI5OSBNSHogcHJvY2Vz
c29yLgooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLgooWEVOKSB4c3RhdGVfaW5pdDogdXNp
bmcgY250eHRfc2l6ZTogMHgzNDAgYW5kIHN0YXRlczogMHg3CihYRU4pIG1jZV9pbnRlbC5jOjEy
Mzk6IE1DQSBDYXBhYmlsaXR5OiBCQ0FTVCAxIFNFUiAwIENNQ0kgMSBmaXJzdGJhbmsgMCBleHRl
bmRlZCBNQ0UgTVNSIDAKKFhFTikgSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxl
ZAooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGY4MDAwMDAwIHNlZ21lbnQg
MDAwMCBidXNlcyAwMCAtIDNmCihYRU4pIFBDSTogTUNGRyBhcmVhIGF0IGY4MDAwMDAwIHJlc2Vy
dmVkIGluIEU4MjAKKFhFTikgUENJOiBVc2luZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAw
LTNmCihYRU4pIEludGVsIFZULWQgU25vb3AgQ29udHJvbCBub3QgZW5hYmxlZC4KKFhFTikgSW50
ZWwgVlQtZCBEb20wIERNQSBQYXNzdGhyb3VnaCBub3QgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQt
ZCBRdWV1ZWQgSW52YWxpZGF0aW9uIGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgSW50ZXJydXB0
IFJlbWFwcGluZyBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIFNoYXJlZCBFUFQgdGFibGVzIG5v
dCBlbmFibGVkLgooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5hYmxlZAooWEVOKSAgLSBEb20w
IG1vZGU6IFJlbGF4ZWQKKFhFTikgRW5hYmxlZCBkaXJlY3RlZCBFT0kgd2l0aCBpb2FwaWNfYWNr
X29sZCBvbiEKKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBvbGQg
QUNLIG1ldGhvZAooWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGlj
Mj0tMSBwaW4yPS0xCihYRU4pIFRTQyBkZWFkbGluZSB0aW1lciBlbmFibGVkCihYRU4pIFBsYXRm
b3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcg
b2YgMzIgS2lCLgooWEVOKSBWTVg6IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikg
IC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFk
b3cKKFhFTikgIC0gRXh0ZW5kZWQgUGFnZSBUYWJsZXMgKEVQVCkKKFhFTikgIC0gVmlydHVhbC1Q
cm9jZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQpCihYRU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAt
IE1TUiBkaXJlY3QtYWNjZXNzIGJpdG1hcAooWEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhF
TikgSFZNOiBBU0lEcyBlbmFibGVkLgooWEVOKSBIVk06IFZNWCBlbmFibGVkCihYRU4pIEhWTTog
SGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkCihYRU4pIEhWTTogSEFQIHBh
Z2Ugc2l6ZXM6IDRrQiwgMk1CCihYRU4pIEJyb3VnaHQgdXAgNCBDUFVzCihYRU4pIEFDUEkgc2xl
ZXAgbW9kZXM6IFMzCihYRU4pIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGlt
ZXIgc3RhcnRlZC4KKFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioqCihYRU4pIGVsZl9wYXJz
ZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weGFhNTAwMAooWEVOKSBlbGZf
cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjMDAwMDAgbWVtc3o9MHhiYWM4MAooWEVOKSBl
bGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjYmIwMDAgbWVtc3o9MHhkNjAKKFhFTikg
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2JjMDAwIG1lbXN6PTB4MTM3MDAKKFhF
TikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2QwMDAwIG1lbXN6PTB4MzczMDAw
CihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MjA0MzAwMAoo
WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4IgooWEVOKSBlbGZfeGVu
X3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42IgooWEVOKSBlbGZfeGVuX3BhcnNlX25v
dGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklS
VF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5U
UlkgPSAweGZmZmZmZmZmODFjZDAyMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNB
TExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEZF
QVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIgooWEVO
KSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhFTikgZWxmX3hlbl9wYXJz
ZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtu
b3duIHhlbiBlbGYgbm90ZSAoMHhkKQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRf
Q0FOQ0VMID0gMHgxCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhm
ZmZmODAwMDAwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0g
MHgwCihYRU4pIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6CihYRU4pICAgICB2
aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pICAgICBlbGZfcGFkZHJf
b2Zmc2V0ID0gMHgwCihYRU4pICAgICB2aXJ0X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAw
MDAwCihYRU4pICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwCihYRU4p
ICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyMDQzMDAwCihYRU4pICAgICB2aXJ0
X2VudHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxY2QwMjAwCihYRU4pICAgICBwMm1fYmFzZSAgICAg
ICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2Is
IGNvbXBhdDMyCihYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIgMHgx
MDAwMDAwIC0+IDB4MjA0MzAwMAooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihY
RU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwMWMwMDAwMDAwLT4wMDAwMDAwMWM0MDAwMDAwICgx
NDU5MTE5IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAw
MDAxY2MwMDYwMDAtPjAwMDAwMDAxY2U1ZmZhMDAKKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5H
RU1FTlQ6CihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgy
MDQzMDAwCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyMDQzMDAwLT5mZmZmZmZmZjg0
NjNjYTAwCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjg0NjNkMDAwLT5mZmZmZmZmZjg1
MTkxZDQ4CihYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjg1MTkyMDAwLT5mZmZmZmZmZjg1
MTkyNGI0CihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjg1MTkzMDAwLT5mZmZmZmZmZjg1
MWMwMDAwCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjg1MWMwMDAwLT5mZmZmZmZmZjg1
MWMxMDAwCihYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjg1
NDAwMDAwCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2QwMjAwCihYRU4pIERvbTAg
aGFzIG1heGltdW0gNCBWQ1BVcwooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZm
ZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxYWE1MDAwCihYRU4pIGVsZl9sb2FkX2JpbmFy
eTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWMwMDAwMCAtPiAweGZmZmZmZmZmODFjYmFjODAKKFhF
TikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxY2JiMDAwIC0+IDB4ZmZm
ZmZmZmY4MWNiYmQ2MAooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZm
ODFjYmMwMDAgLT4gMHhmZmZmZmZmZjgxY2NmNzAwCihYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhk
ciA0IGF0IDB4ZmZmZmZmZmY4MWNkMDAwMCAtPiAweGZmZmZmZmZmODFkYmEwMDAKKFhFTikgU2Ny
dWJiaW5nIEZyZWUgUkFNOiAuZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhy
ZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVO
KSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioKKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJ
UyBTWU5DSFJPTk9VUwooWEVOKSAqKioqKioqIFRoaXMgb3B0aW9uIGlzIGludGVuZGVkIHRvIGFp
ZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVuc3VyaW5nCihYRU4pICoqKioqKiogdGhhdCBhbGwgb3V0
cHV0IGlzIHN5bmNocm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4KKFhFTikg
KioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFu
ZCBhZmZlY3QKKFhFTikgKioqKioqKiB0aW1la2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVk
IGZvciBwcm9kdWN0aW9uIHVzZSEKKFhFTikgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKgooWEVOKSAzLi4uIDIuLi4gMS4uLiAKKFhFTikgKioqIFNlcmlhbCBp
bnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0
byBYZW4pCihYRU4pIEZyZWVkIDI0NGtCIGluaXQgbWVtb3J5LgptYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQpYZW46IHNldHVwIElTQSBpZGVudGl0eSBtYXBzCmFib3V0IHRvIGdl
dCBzdGFydGVkLi4uClsgICAgNS4zNjU3ODNdIGludmFsaWQgb3Bjb2RlOiAwMDAwIFsjMV0gU01Q
IApbICAgIDUuMzY2NjI3XSBDUFUgMCAKWyAgICA1LjM2Njk3OV0gTW9kdWxlcyBsaW5rZWQgaW46
ClsgICAgNS4zNjc2MDNdIApbICAgIDUuMzY3ODg3XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIgTm90
IHRhaW50ZWQgMy4wLjAtMTctZ2VuZXJpYyAjMzAtVWJ1bnR1IFRPU0hJQkEgVEVDUkEgUjg0MC9Q
b3J0YWJsZSBQQwpbICAgIDUuMzY5ODEzXSBSSVA6IGUwMzA6WzxmZmZmZmZmZjgxMDE0MGVjPl0g
IFs8ZmZmZmZmZmY4MTAxNDBlYz5dIHhzdGF0ZV9lbmFibGUrMHgzYy8weDUwClsgICAgNS4zNzEz
ODVdIFJTUDogZTAyYjpmZmZmZmZmZjgxYzAxZTU4ICBFRkxBR1M6IDAwMDEwMDQ2ClsgICAgNS4z
NzI0MTVdIFJBWDogMDAwMDAwMDAwMDAwMDAwNyBSQlg6IGZmZmZmZmZmODFjMDFlOTQgUkNYOiAw
MDAwMDAwMDAwMDAwMDAwClsgICAgNS4zNzM4OTZdIFJEWDogMDAwMDAwMDAwMDAwMDAwMCBSU0k6
IDAwMDAwMDAwMDAwMDAwMDcgUkRJOiAwMDAwMDAwMDAwMDAyNjYwClsgICAgNS4zNzUyNzJdIFJC
UDogZmZmZmZmZmY4MWMwMWU1OCBSMDg6IGZmZmZmZmZmODFjMDFlOTAgUjA5OiBmZmZmZmZmZjgx
YzAxZTk0ClsgICAgNS4zNzY2NTNdIFIxMDogMDAwMDAwMDBmZmZmZmZmZiBSMTE6IDAwMDAwMDAw
ZmZmZmZmZmYgUjEyOiBmZmZmZmZmZjgxYzAxZTkwClsgICAgNS4zNzgwMjldIFIxMzogZmZmZmZm
ZmY4MWMwMWU4YyBSMTQ6IGZmZmZmZmZmODFjMDFlODggUjE1OiBmZmZmODgwMTZhOGEwZDAwClsg
ICAgNS4zNzk0OTBdIEZTOiAgMDAwMDAwMDAwMDAwMDAwMCgwMDAwKSBHUzpmZmZmODgwMTZhODk0
MDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAKWyAgICA1LjM4MTA1OV0gQ1M6ICBlMDMz
IERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYgpbICAgIDUuMzgyMTY3XSBD
UjI6IDAwMDAwMDAwMDAwMDAwMDAgQ1IzOiAwMDAwMDAwMDAxYzAzMDAwIENSNDogMDAwMDAwMDAw
MDAwMjY2MApbICAgIDUuMzg1MTI0XSBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAw
MDAwMDAwMDAwIERSMjogMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMzg2NTAwXSBEUjM6IDAwMDAw
MDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMApb
ICAgIDUuMzg3ODgxXSBQcm9jZXNzIHN3YXBwZXIgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZm
ZjgxYzAwMDAwLCB0YXNrIGZmZmZmZmZmODFjMGIwMjApClsgICAgNS4zODk1NDFdIFN0YWNrOgpb
ICAgIDUuMzg5OTIzXSAgZmZmZmZmZmY4MWMwMWVjOCBmZmZmZmZmZjgxY2Q5N2FjIDAwMDAwMDAw
MDAwMDAwNDAgMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMzkxMzUwXSAgZmZmZmZmZmY4MTAwN2I0
ZiBmZmZmZmZmZjgxMDA0MDU3IDAwMDAwMjQwMDAwMDAwMDcgMDAwMDAwMDAwMDAwMDM0MApbICAg
IDUuMzkyNzk0XSAgZmZmZjg4MDE2YTg5ZjEwMCAwMDAwMDAwMDAwMDAwMDA4IDAwMDAwMDAwMDAw
MDAwMDQgMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMzk0MjY2XSBDYWxsIFRyYWNlOgpbICAgIDUu
Mzk0NzQ4XSAgWzxmZmZmZmZmZjgxY2Q5N2FjPl0geHN0YXRlX2VuYWJsZV9ib290X2NwdSsweGE5
LzB4MTc0ClsgICAgNS4zOTU5NjJdICBbPGZmZmZmZmZmODEwMDdiNGY+XSA/IHhlbl9yZXN0b3Jl
X2ZsX2RpcmVjdF9yZWxvYysweDQvMHg0ClsgICAgNS4zOTcyMzldICBbPGZmZmZmZmZmODEwMDQw
NTc+XSA/IHhlbl93cml0ZV9jcjArMHg3Ny8weDkwClsgICAgNS4zOTgzMTddICBbPGZmZmZmZmZm
ODE1ZDA2ZWI+XSB4c2F2ZV9pbml0KzB4MjYvMHgyOApbICAgIDUuMzk5MzQ2XSAgWzxmZmZmZmZm
ZjgxNWQyOTMyPl0gY3B1X2luaXQrMHgyYmIvMHgyZDgKWyAgICA1LjQwMDM0Ml0gIFs8ZmZmZmZm
ZmY4MWNkNWZmND5dIHRyYXBfaW5pdCsweDE2OS8weDE3MQpbICAgIDUuNDAxMzQ4XSAgWzxmZmZm
ZmZmZjgxY2QwYTI3Pl0gc3RhcnRfa2VybmVsKzB4MWQwLzB4M2RmClsgICAgNS40MDMzMDVdICBb
PGZmZmZmZmZmODFjZDAzODg+XSB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMyLzB4MTM2
ClsgICAgNS40MDQ2NjFdICBbPGZmZmZmZmZmODFjZDNlYzY+XSB4ZW5fc3RhcnRfa2VybmVsKzB4
NWFjLzB4NWIzClsgICAgNS40MDU3OTBdIENvZGU6IDAwIDA0IDAwIGZmIDE0IDI1IDEwIDMzIGMx
IDgxIDQ4IDg5IGM3IDQ4IDgxIGNmIDAwIDAwIDA0IDAwIGZmIDE0IDI1IDE4IDMzIGMxIDgxIDQ4
IDhiIDA1IDBkIDE1IGRiIDAwIDMxIGM5IDQ4IDg5IGMyIDQ4IGMxIGVhIDIwIDwwZj4gMDEgZDEg
NWQgYzMgNjYgNjYgNjYgNjYgNjYgNjYgMmUgMGYgMWYgODQgMDAgMDAgMDAgMDAgMDAgNTUgClsg
ICAgNS40MDk1NjJdIFJJUCAgWzxmZmZmZmZmZjgxMDE0MGVjPl0geHN0YXRlX2VuYWJsZSsweDNj
LzB4NTAKWyAgICA1LjQxMDY3NF0gIFJTUCA8ZmZmZmZmZmY4MWMwMWU1OD4KWyAgICA1LjQxMTM1
MF0gLS0tWyBlbmQgdHJhY2UgYTc5MTllN2YxN2MwYTcyNSBdLS0tClsgICAgNS40MTIyNDBdIEtl
cm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBBdHRlbXB0ZWQgdG8ga2lsbCB0aGUgaWRsZSB0YXNr
IQpbICAgIDUuNDE0MTM2XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIgVGFpbnRlZDogRyAgICAgIEQg
ICAgIDMuMC4wLTE3LWdlbmVyaWMgIzMwLVVidW50dQpbICAgIDUuNDE1NjM0XSBDYWxsIFRyYWNl
OgpbICAgIDUuNDE2MTAyXSAgWzxmZmZmZmZmZjgxNWRjYTY2Pl0gcGFuaWMrMHg5MS8weDE5NApb
ICAgIDUuNDE3MDM0XSAgWzxmZmZmZmZmZjgxMDYzNDRiPl0gZG9fZXhpdCsweDQwYi8weDQ0MApb
ICAgIDUuNDE4MDA0XSAgWzxmZmZmZmZmZjgxNWY0MzUwPl0gb29wc19lbmQrMHhiMC8weGYwClsg
ICAgNS40MTkwNTNdICBbPGZmZmZmZmZmODEwMGQ5Mzg+XSBkaWUrMHg1OC8weDkwClsgICAgNS40
MTk5MjZdICBbPGZmZmZmZmZmODE1ZjNhMzQ+XSBkb190cmFwKzB4YzQvMHgxNzAKWyAgICA1LjQy
MjA4N10gIFs8ZmZmZmZmZmY4MTAwYWYyNT5dIGRvX2ludmFsaWRfb3ArMHg5NS8weGIwClsgICAg
NS40MjMxMjBdICBbPGZmZmZmZmZmODEwMTQwZWM+XSA/IHhzdGF0ZV9lbmFibGUrMHgzYy8weDUw
ClsgICAgNS40MjQyOTRdICBbPGZmZmZmZmZmODEwMDdiNjI+XSA/IGNoZWNrX2V2ZW50cysweDEy
LzB4MjAKWyAgICA1LjQyNTM1M10gIFs8ZmZmZmZmZmY4MTAwODIzOT5dID8gZ2V0X3BoeXNfdG9f
bWFjaGluZSsweDkvMHg3MApbICAgIDUuNDI2NTE1XSAgWzxmZmZmZmZmZjgxMDA1YzY5Pl0gPyBw
dGVfbWZuX3RvX3BmbisweDg5LzB4ZjAKWyAgICA1LjQyNzYwNF0gIFs8ZmZmZmZmZmY4MTAwNzQz
ZD5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGQvMHgxMApbICAgIDUuNDI4OTQ2XSAg
WzxmZmZmZmZmZjgxNWZjMmRiPl0gaW52YWxpZF9vcCsweDFiLzB4MjAKWyAgICA1LjQyOTkzMl0g
IFs8ZmZmZmZmZmY4MTAxNDBlYz5dID8geHN0YXRlX2VuYWJsZSsweDNjLzB4NTAKWyAgICA1LjQz
MTAxMl0gIFs8ZmZmZmZmZmY4MTAxNDBkYz5dID8geHN0YXRlX2VuYWJsZSsweDJjLzB4NTAKWyAg
ICA1LjQzMjA4Ml0gIFs8ZmZmZmZmZmY4MWNkOTdhYz5dIHhzdGF0ZV9lbmFibGVfYm9vdF9jcHUr
MHhhOS8weDE3NApbICAgIDUuNDMzMjk2XSAgWzxmZmZmZmZmZjgxMDA3YjRmPl0gPyB4ZW5fcmVz
dG9yZV9mbF9kaXJlY3RfcmVsb2MrMHg0LzB4NApbICAgIDUuNDM0OTk1XSAgWzxmZmZmZmZmZjgx
MDA0MDU3Pl0gPyB4ZW5fd3JpdGVfY3IwKzB4NzcvMHg5MApbICAgIDUuNDM2MDcxXSAgWzxmZmZm
ZmZmZjgxNWQwNmViPl0geHNhdmVfaW5pdCsweDI2LzB4MjgKWyAgICA1LjQzNzA2Ml0gIFs8ZmZm
ZmZmZmY4MTVkMjkzMj5dIGNwdV9pbml0KzB4MmJiLzB4MmQ4ClsgICAgNS40MzgwNjJdICBbPGZm
ZmZmZmZmODFjZDVmZjQ+XSB0cmFwX2luaXQrMHgxNjkvMHgxNzEKWyAgICA1LjQ0MTAwMF0gIFs8
ZmZmZmZmZmY4MWNkMGEyNz5dIHN0YXJ0X2tlcm5lbCsweDFkMC8weDNkZgpbICAgIDUuNDQyMjQ3
XSAgWzxmZmZmZmZmZjgxY2QwMzg4Pl0geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMi8w
eDEzNgpbICAgIDUuNDQzNTY4XSAgWzxmZmZmZmZmZjgxY2QzZWM2Pl0geGVuX3N0YXJ0X2tlcm5l
bCsweDVhYy8weDViMwooWEVOKSBEb21haW4gMCBjcmFzaGVkOiByZWJvb3RpbmcgbWFjaGluZSBp
biA1IHNlY29uZHMuCihYRU4pIFJlc2V0dGluZyB3aXRoIEFDUEkgTUVNT1JZIG9yIEkvTyBSRVNF
VF9SRUcuCg==

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_--


From xen-devel-bounces@lists.xen.org Thu Apr 05 17:39:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 17:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFqeH-0002Oy-G4; Thu, 05 Apr 2012 17:39:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFqeF-0002Ot-Mv
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 17:39:04 +0000
Received: from [85.158.143.35:56223] by server-2.bemta-4.messagelabs.com id
	3C/6B-17550-6B8DD7F4; Thu, 05 Apr 2012 17:39:02 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333647541!5882162!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNDMx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32222 invoked from network); 5 Apr 2012 17:39:01 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 17:39:01 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFqeD-0004qR-En
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 18:39:01 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Thu, 5 Apr 2012 18:37:27 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 5 Apr 2012 18:37:26 +0100
Thread-Topic: lastest xen unstable crash
Thread-Index: AQHNE1LEjObst9pxYU+OBx0LJG67mA==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
Content-Type: multipart/mixed;
	boundary="_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_"
MIME-Version: 1.0
Subject: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

I was trying to build a new machine but the system keeps rebooting.
I used the lasted unstable version from xen-unstable.hg.

I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-ge=
neric).

The output to my serial console is attached.

Cheers,
Francisco=

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_
Content-Type: text/plain; name="xen_crash.txt"
Content-Description: xen_crash.txt
Content-Disposition: attachment; filename="xen_crash.txt"; size=14884;
	creation-date="Thu, 05 Apr 2012 18:32:36 GMT";
	modification-date="Thu, 05 Apr 2012 18:32:36 GMT"
Content-Transfer-Encoding: base64

c2VyaWFsLW92ZXItbGFuIHJlZGlyZWN0aW9uIG9rCmNvbm5lY3RlZCBub3csIHVzZSBeXSB0byBl
c2NhcGUKIF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICAgICAgICAgICAgICAgICAg
IF8gICAgICAgIF8gICAgIF8gICAgICAKIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwg
ICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwgJ18g
XCAgfCB8fCB8XyAgIF9fKSB8X198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBf
IFwKICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy98X198IHxffCB8IHwgfCBcX18gXCB8
fCAoX3wgfCB8XykgfCB8ICBfXy8KIC9fL1xfXF9fX3xffCB8X3wgICAgfF98KF8pX19fX198ICAg
XF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
KFhFTikgWGVuIHZlcnNpb24gNC4yLXVuc3RhYmxlIChyb290QHh4eHh4eHgpIChnY2MgdmVyc2lv
biA0LjYuMSAoVWJ1bnR1L0xpbmFybyA0LjYuMS05dWJ1bnR1MykgKSBUaHUgQXByICA1IDE3OjM0
OjE2IEJTVCAyMDEyCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IE1vbiBBcHIgMDIgMTg6MTQ6MzEg
MjAxMiArMDEwMCAyNTEzODoyMzg2Mjg4YjFiZjEKKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3lu
Y2hyb25vdXMuCihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OS0xMnVidW50dTUKKFhFTikgQ29t
bWFuZCBsaW5lOiBwbGFjZWhvbGRlciBsb2dsdmw9YWxsIHN5bmNfY29uc29sZSBjb25zb2xlX3Rv
X3JpbmcgY29tMT0xMTUyMDAsOG4xLDB4MzA5MCwxOSBjb25zb2xlPWNvbTEKKFhFTikgVmlkZW8g
aW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2RlIDgweDI1LCBmb250IDh4MTYKKFhF
TikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCihY
RU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAxIE1CUiBzaWduYXR1cmVzCihYRU4p
ICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJBTSBt
YXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZWMwMCAodXNhYmxlKQoo
WEVOKSAgMDAwMDAwMDAwMDA5ZWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQooWEVO
KSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVOKSAg
MDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAw
MDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAw
MjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDQwMDAw
MDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDQwMjAwMDAw
IC0gMDAwMDAwMDBhYTFkMDAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDBhYTFkMDAwMCAtIDAw
MDAwMDAwYWExZDAyMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBhYTFkMDIwMCAtIDAwMDAw
MDAwYWExZDMwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBhYTFkMzAwMCAtIDAwMDAwMDAw
YWEyZDAwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBhYTJkMDAwMCAtIDAwMDAwMDAwYWEy
ZjAwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwYWEyZjAwMDAgLSAwMDAwMDAwMGFmYTAw
MDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZjgwMDAwMDAgLSAwMDAwMDAwMGZjMDAwMDAw
IChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMTAwMDAgLSAwMDAwMDAwMGZlZDFhMDAwIChyZXNl
cnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDIwMDAwIChyZXNlcnZl
ZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkK
KFhFTikgIDAwMDAwMDAwZmZjMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKKFhF
TikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWNlNjAwMDAwICh1c2FibGUpCihYRU4pIEFD
UEk6IFJTRFAgMDAwRjAwMzAsIDAwMTQgKHIwIFRPU0hJQikKKFhFTikgQUNQSTogUlNEVCBBQTJF
RjAzOCwgMDA1OCAocjEgVE9TSElCIEEwMDdEICAgICAgICAgICAzICAgICAgIDEwMDAwMTMpCihY
RU4pIEFDUEk6IEZBQ1AgQUEyRUUwMDAsIDAwODEgKHIyIFRPU0hJQiBBMDA3RCAgICAgICAgICAg
MyBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJOiBEU0RUIEFBMkREMDAwLCA4QTQ2IChyMiBUT1NI
SUIgQTAwN0QgICAgMjAxMTEyMjAgSU5UTCAyMDA2MTEwOSkKKFhFTikgQUNQSTogRkFDUyBBQTJB
RDAwMCwgMDA0MAooWEVOKSBBQ1BJOiBIUEVUIEFBMkVEMDAwLCAwMDM4IChyMSBUT1NISUIgQTAw
N0QgICAgICAgICAgIDEgTE9IUiAgICAgICA1RikKKFhFTikgQUNQSTogQVBJQyBBQTJFQzAwMCwg
MDBCQyAocjEgVE9TSElCIEEwMDdEICAgICAgICAgICAxIExPSFIgICAgICAgNUYpCihYRU4pIEFD
UEk6IE1DRkcgQUEyRUIwMDAsIDAwM0MgKHIxIFRPU0hJQiBBMDA3RCAgICAgICAgICAgMSBMT0hS
ICAgICAgIDVGKQooWEVOKSBBQ1BJOiBBU0YhIEFBMkVBMDAwLCAwMEEwIChyMzIgVE9TSElCIEEw
MDdEICAgICAgICAgICAxIExPSFIgICAgICAgNUYpCihYRU4pIEFDUEk6IFRDUEEgQUEyRTkwMDAs
IDAwMzIgKHIyIFRPU0hJQiBBMDA3RCAgICAgICAgICAgMCBMT0hSICAgICAgIDVGKQooWEVOKSBB
Q1BJOiBCT09UIEFBMkU4MDAwLCAwMDI4IChyMSBUT1NISUIgQTAwN0QgICAgICAgICAgIDAgTE9I
UiAgICAgICA1RikKKFhFTikgQUNQSTogU0xJQyBBQTJFNzAwMCwgMDE3NiAocjEgVE9TSElCIEEw
MDdEICAgICAgICAgICAwIExPSFIgICAgICAgNUYpCihYRU4pIEFDUEk6IFNTRFQgQUEyREMwMDAs
IDAzOTUgKHIxIFRPU0hJQiBTYXRhQWhjaSAgICAgMTAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBB
Q1BJOiBTU0RUIEFBMkQ5MDAwLCAwNzIwIChyMSBUT1NISUIgUHRpZERldmMgICAgIDEwMDAgSU5U
TCAyMDA2MTEwOSkKKFhFTikgQUNQSTogU1NEVCBBQTJENzAwMCwgMDgyNyAocjEgIFBtUmVmICBD
cHUwSXN0ICAgICAzMDAwIElOVEwgMjAwNjExMDkpCihYRU4pIEFDUEk6IFNTRFQgQUEyRDYwMDAs
IDA5OTYgKHIxICBQbVJlZiAgICBDcHVQbSAgICAgMzAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBB
Q1BJOiBETUFSIEFBMkQ1MDAwLCAwMTEwIChyMSBJTlRFTCAgICAgIFNOQiAgICAgICAgIDEgSU5U
TCAgICAgICAgMSkKKFhFTikgU3lzdGVtIFJBTTogNjAxOU1CICg2MTYzODk2a0IpCihYRU4pIE5v
IE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZAooWEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAw
MDAwMDAwMDAtMDAwMDAwMDFjZTYwMDAwMAooWEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZAoo
WEVOKSBETUkgMi41IHByZXNlbnQuCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKKFhF
TikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgKKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJ
TkZPOiBwbTF4X2NudFs0MDQsMF0sIHBtMXhfZXZ0WzQwMCwwXQooWEVOKSBBQ1BJOiAgICAgICAg
ICAgICAgICAgIHdha2V1cF92ZWNbYWEyYWQwMGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTog
TG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMwIDY6MTAgQVBJ
QyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4
MDFdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMSA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVO
KSBQcm9jZXNzb3IgIzIgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMzIDY6
MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGlj
X2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBp
Y19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFw
aWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxh
cGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgw
MF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4
MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsw
eDAyXSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRb
MHgwM10gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk
WzB4MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9p
ZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlf
aWRbMHgwNl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3Bp
X2lkWzB4MDddIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgw
Ml0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDIsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMKKFhFTikgQUNQ
STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhF
TikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBs
ZXZlbCkKKFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEy
IHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KKFhF
TikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDEgSS9PIEFQSUNzCihYRU4pIEFD
UEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhmZWQwMDAwMAooWEVOKSBUYWJsZSBpcyBu
b3QgZm91bmQhCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBp
bmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoNCBob3RwbHVnIENQVXMpCihY
RU4pIElSUSBsaW1pdHM6IDI0IEdTSSwgNzYwIE1TSS9NU0ktWAooWEVOKSBTd2l0Y2hlZCB0byBB
UElDIGRyaXZlciB4MmFwaWNfY2x1c3Rlci4KKFhFTikgVXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3Jl
ZGl0IFNjaGVkdWxlciAoY3JlZGl0KQooWEVOKSBEZXRlY3RlZCAyNjkxLjI5OSBNSHogcHJvY2Vz
c29yLgooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLgooWEVOKSB4c3RhdGVfaW5pdDogdXNp
bmcgY250eHRfc2l6ZTogMHgzNDAgYW5kIHN0YXRlczogMHg3CihYRU4pIG1jZV9pbnRlbC5jOjEy
Mzk6IE1DQSBDYXBhYmlsaXR5OiBCQ0FTVCAxIFNFUiAwIENNQ0kgMSBmaXJzdGJhbmsgMCBleHRl
bmRlZCBNQ0UgTVNSIDAKKFhFTikgSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxl
ZAooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGY4MDAwMDAwIHNlZ21lbnQg
MDAwMCBidXNlcyAwMCAtIDNmCihYRU4pIFBDSTogTUNGRyBhcmVhIGF0IGY4MDAwMDAwIHJlc2Vy
dmVkIGluIEU4MjAKKFhFTikgUENJOiBVc2luZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAw
LTNmCihYRU4pIEludGVsIFZULWQgU25vb3AgQ29udHJvbCBub3QgZW5hYmxlZC4KKFhFTikgSW50
ZWwgVlQtZCBEb20wIERNQSBQYXNzdGhyb3VnaCBub3QgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQt
ZCBRdWV1ZWQgSW52YWxpZGF0aW9uIGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgSW50ZXJydXB0
IFJlbWFwcGluZyBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIFNoYXJlZCBFUFQgdGFibGVzIG5v
dCBlbmFibGVkLgooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5hYmxlZAooWEVOKSAgLSBEb20w
IG1vZGU6IFJlbGF4ZWQKKFhFTikgRW5hYmxlZCBkaXJlY3RlZCBFT0kgd2l0aCBpb2FwaWNfYWNr
X29sZCBvbiEKKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBvbGQg
QUNLIG1ldGhvZAooWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGlj
Mj0tMSBwaW4yPS0xCihYRU4pIFRTQyBkZWFkbGluZSB0aW1lciBlbmFibGVkCihYRU4pIFBsYXRm
b3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcg
b2YgMzIgS2lCLgooWEVOKSBWTVg6IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikg
IC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFk
b3cKKFhFTikgIC0gRXh0ZW5kZWQgUGFnZSBUYWJsZXMgKEVQVCkKKFhFTikgIC0gVmlydHVhbC1Q
cm9jZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQpCihYRU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAt
IE1TUiBkaXJlY3QtYWNjZXNzIGJpdG1hcAooWEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhF
TikgSFZNOiBBU0lEcyBlbmFibGVkLgooWEVOKSBIVk06IFZNWCBlbmFibGVkCihYRU4pIEhWTTog
SGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVjdGVkCihYRU4pIEhWTTogSEFQIHBh
Z2Ugc2l6ZXM6IDRrQiwgMk1CCihYRU4pIEJyb3VnaHQgdXAgNCBDUFVzCihYRU4pIEFDUEkgc2xl
ZXAgbW9kZXM6IFMzCihYRU4pIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGlt
ZXIgc3RhcnRlZC4KKFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioqCihYRU4pIGVsZl9wYXJz
ZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weGFhNTAwMAooWEVOKSBlbGZf
cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjMDAwMDAgbWVtc3o9MHhiYWM4MAooWEVOKSBl
bGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjYmIwMDAgbWVtc3o9MHhkNjAKKFhFTikg
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2JjMDAwIG1lbXN6PTB4MTM3MDAKKFhF
TikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2QwMDAwIG1lbXN6PTB4MzczMDAw
CihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MjA0MzAwMAoo
WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4IgooWEVOKSBlbGZfeGVu
X3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42IgooWEVOKSBlbGZfeGVuX3BhcnNlX25v
dGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklS
VF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5U
UlkgPSAweGZmZmZmZmZmODFjZDAyMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNB
TExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEZF
QVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIgooWEVO
KSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhFTikgZWxmX3hlbl9wYXJz
ZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtu
b3duIHhlbiBlbGYgbm90ZSAoMHhkKQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRf
Q0FOQ0VMID0gMHgxCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhm
ZmZmODAwMDAwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0g
MHgwCihYRU4pIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6CihYRU4pICAgICB2
aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pICAgICBlbGZfcGFkZHJf
b2Zmc2V0ID0gMHgwCihYRU4pICAgICB2aXJ0X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAw
MDAwCihYRU4pICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwCihYRU4p
ICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyMDQzMDAwCihYRU4pICAgICB2aXJ0
X2VudHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxY2QwMjAwCihYRU4pICAgICBwMm1fYmFzZSAgICAg
ICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2Is
IGNvbXBhdDMyCihYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIgMHgx
MDAwMDAwIC0+IDB4MjA0MzAwMAooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihY
RU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwMWMwMDAwMDAwLT4wMDAwMDAwMWM0MDAwMDAwICgx
NDU5MTE5IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAw
MDAxY2MwMDYwMDAtPjAwMDAwMDAxY2U1ZmZhMDAKKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5H
RU1FTlQ6CihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgy
MDQzMDAwCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyMDQzMDAwLT5mZmZmZmZmZjg0
NjNjYTAwCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjg0NjNkMDAwLT5mZmZmZmZmZjg1
MTkxZDQ4CihYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjg1MTkyMDAwLT5mZmZmZmZmZjg1
MTkyNGI0CihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjg1MTkzMDAwLT5mZmZmZmZmZjg1
MWMwMDAwCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjg1MWMwMDAwLT5mZmZmZmZmZjg1
MWMxMDAwCihYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjg1
NDAwMDAwCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2QwMjAwCihYRU4pIERvbTAg
aGFzIG1heGltdW0gNCBWQ1BVcwooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZm
ZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxYWE1MDAwCihYRU4pIGVsZl9sb2FkX2JpbmFy
eTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWMwMDAwMCAtPiAweGZmZmZmZmZmODFjYmFjODAKKFhF
TikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxY2JiMDAwIC0+IDB4ZmZm
ZmZmZmY4MWNiYmQ2MAooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZm
ODFjYmMwMDAgLT4gMHhmZmZmZmZmZjgxY2NmNzAwCihYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhk
ciA0IGF0IDB4ZmZmZmZmZmY4MWNkMDAwMCAtPiAweGZmZmZmZmZmODFkYmEwMDAKKFhFTikgU2Ny
dWJiaW5nIEZyZWUgUkFNOiAuZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhy
ZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVO
KSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioKKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJ
UyBTWU5DSFJPTk9VUwooWEVOKSAqKioqKioqIFRoaXMgb3B0aW9uIGlzIGludGVuZGVkIHRvIGFp
ZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVuc3VyaW5nCihYRU4pICoqKioqKiogdGhhdCBhbGwgb3V0
cHV0IGlzIHN5bmNocm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4KKFhFTikg
KioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFu
ZCBhZmZlY3QKKFhFTikgKioqKioqKiB0aW1la2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVk
IGZvciBwcm9kdWN0aW9uIHVzZSEKKFhFTikgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKgooWEVOKSAzLi4uIDIuLi4gMS4uLiAKKFhFTikgKioqIFNlcmlhbCBp
bnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0
byBYZW4pCihYRU4pIEZyZWVkIDI0NGtCIGluaXQgbWVtb3J5LgptYXBwaW5nIGtlcm5lbCBpbnRv
IHBoeXNpY2FsIG1lbW9yeQpYZW46IHNldHVwIElTQSBpZGVudGl0eSBtYXBzCmFib3V0IHRvIGdl
dCBzdGFydGVkLi4uClsgICAgNS4zNjU3ODNdIGludmFsaWQgb3Bjb2RlOiAwMDAwIFsjMV0gU01Q
IApbICAgIDUuMzY2NjI3XSBDUFUgMCAKWyAgICA1LjM2Njk3OV0gTW9kdWxlcyBsaW5rZWQgaW46
ClsgICAgNS4zNjc2MDNdIApbICAgIDUuMzY3ODg3XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIgTm90
IHRhaW50ZWQgMy4wLjAtMTctZ2VuZXJpYyAjMzAtVWJ1bnR1IFRPU0hJQkEgVEVDUkEgUjg0MC9Q
b3J0YWJsZSBQQwpbICAgIDUuMzY5ODEzXSBSSVA6IGUwMzA6WzxmZmZmZmZmZjgxMDE0MGVjPl0g
IFs8ZmZmZmZmZmY4MTAxNDBlYz5dIHhzdGF0ZV9lbmFibGUrMHgzYy8weDUwClsgICAgNS4zNzEz
ODVdIFJTUDogZTAyYjpmZmZmZmZmZjgxYzAxZTU4ICBFRkxBR1M6IDAwMDEwMDQ2ClsgICAgNS4z
NzI0MTVdIFJBWDogMDAwMDAwMDAwMDAwMDAwNyBSQlg6IGZmZmZmZmZmODFjMDFlOTQgUkNYOiAw
MDAwMDAwMDAwMDAwMDAwClsgICAgNS4zNzM4OTZdIFJEWDogMDAwMDAwMDAwMDAwMDAwMCBSU0k6
IDAwMDAwMDAwMDAwMDAwMDcgUkRJOiAwMDAwMDAwMDAwMDAyNjYwClsgICAgNS4zNzUyNzJdIFJC
UDogZmZmZmZmZmY4MWMwMWU1OCBSMDg6IGZmZmZmZmZmODFjMDFlOTAgUjA5OiBmZmZmZmZmZjgx
YzAxZTk0ClsgICAgNS4zNzY2NTNdIFIxMDogMDAwMDAwMDBmZmZmZmZmZiBSMTE6IDAwMDAwMDAw
ZmZmZmZmZmYgUjEyOiBmZmZmZmZmZjgxYzAxZTkwClsgICAgNS4zNzgwMjldIFIxMzogZmZmZmZm
ZmY4MWMwMWU4YyBSMTQ6IGZmZmZmZmZmODFjMDFlODggUjE1OiBmZmZmODgwMTZhOGEwZDAwClsg
ICAgNS4zNzk0OTBdIEZTOiAgMDAwMDAwMDAwMDAwMDAwMCgwMDAwKSBHUzpmZmZmODgwMTZhODk0
MDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAKWyAgICA1LjM4MTA1OV0gQ1M6ICBlMDMz
IERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYgpbICAgIDUuMzgyMTY3XSBD
UjI6IDAwMDAwMDAwMDAwMDAwMDAgQ1IzOiAwMDAwMDAwMDAxYzAzMDAwIENSNDogMDAwMDAwMDAw
MDAwMjY2MApbICAgIDUuMzg1MTI0XSBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAw
MDAwMDAwMDAwIERSMjogMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMzg2NTAwXSBEUjM6IDAwMDAw
MDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMApb
ICAgIDUuMzg3ODgxXSBQcm9jZXNzIHN3YXBwZXIgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZm
ZjgxYzAwMDAwLCB0YXNrIGZmZmZmZmZmODFjMGIwMjApClsgICAgNS4zODk1NDFdIFN0YWNrOgpb
ICAgIDUuMzg5OTIzXSAgZmZmZmZmZmY4MWMwMWVjOCBmZmZmZmZmZjgxY2Q5N2FjIDAwMDAwMDAw
MDAwMDAwNDAgMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMzkxMzUwXSAgZmZmZmZmZmY4MTAwN2I0
ZiBmZmZmZmZmZjgxMDA0MDU3IDAwMDAwMjQwMDAwMDAwMDcgMDAwMDAwMDAwMDAwMDM0MApbICAg
IDUuMzkyNzk0XSAgZmZmZjg4MDE2YTg5ZjEwMCAwMDAwMDAwMDAwMDAwMDA4IDAwMDAwMDAwMDAw
MDAwMDQgMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMzk0MjY2XSBDYWxsIFRyYWNlOgpbICAgIDUu
Mzk0NzQ4XSAgWzxmZmZmZmZmZjgxY2Q5N2FjPl0geHN0YXRlX2VuYWJsZV9ib290X2NwdSsweGE5
LzB4MTc0ClsgICAgNS4zOTU5NjJdICBbPGZmZmZmZmZmODEwMDdiNGY+XSA/IHhlbl9yZXN0b3Jl
X2ZsX2RpcmVjdF9yZWxvYysweDQvMHg0ClsgICAgNS4zOTcyMzldICBbPGZmZmZmZmZmODEwMDQw
NTc+XSA/IHhlbl93cml0ZV9jcjArMHg3Ny8weDkwClsgICAgNS4zOTgzMTddICBbPGZmZmZmZmZm
ODE1ZDA2ZWI+XSB4c2F2ZV9pbml0KzB4MjYvMHgyOApbICAgIDUuMzk5MzQ2XSAgWzxmZmZmZmZm
ZjgxNWQyOTMyPl0gY3B1X2luaXQrMHgyYmIvMHgyZDgKWyAgICA1LjQwMDM0Ml0gIFs8ZmZmZmZm
ZmY4MWNkNWZmND5dIHRyYXBfaW5pdCsweDE2OS8weDE3MQpbICAgIDUuNDAxMzQ4XSAgWzxmZmZm
ZmZmZjgxY2QwYTI3Pl0gc3RhcnRfa2VybmVsKzB4MWQwLzB4M2RmClsgICAgNS40MDMzMDVdICBb
PGZmZmZmZmZmODFjZDAzODg+XSB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMyLzB4MTM2
ClsgICAgNS40MDQ2NjFdICBbPGZmZmZmZmZmODFjZDNlYzY+XSB4ZW5fc3RhcnRfa2VybmVsKzB4
NWFjLzB4NWIzClsgICAgNS40MDU3OTBdIENvZGU6IDAwIDA0IDAwIGZmIDE0IDI1IDEwIDMzIGMx
IDgxIDQ4IDg5IGM3IDQ4IDgxIGNmIDAwIDAwIDA0IDAwIGZmIDE0IDI1IDE4IDMzIGMxIDgxIDQ4
IDhiIDA1IDBkIDE1IGRiIDAwIDMxIGM5IDQ4IDg5IGMyIDQ4IGMxIGVhIDIwIDwwZj4gMDEgZDEg
NWQgYzMgNjYgNjYgNjYgNjYgNjYgNjYgMmUgMGYgMWYgODQgMDAgMDAgMDAgMDAgMDAgNTUgClsg
ICAgNS40MDk1NjJdIFJJUCAgWzxmZmZmZmZmZjgxMDE0MGVjPl0geHN0YXRlX2VuYWJsZSsweDNj
LzB4NTAKWyAgICA1LjQxMDY3NF0gIFJTUCA8ZmZmZmZmZmY4MWMwMWU1OD4KWyAgICA1LjQxMTM1
MF0gLS0tWyBlbmQgdHJhY2UgYTc5MTllN2YxN2MwYTcyNSBdLS0tClsgICAgNS40MTIyNDBdIEtl
cm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBBdHRlbXB0ZWQgdG8ga2lsbCB0aGUgaWRsZSB0YXNr
IQpbICAgIDUuNDE0MTM2XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIgVGFpbnRlZDogRyAgICAgIEQg
ICAgIDMuMC4wLTE3LWdlbmVyaWMgIzMwLVVidW50dQpbICAgIDUuNDE1NjM0XSBDYWxsIFRyYWNl
OgpbICAgIDUuNDE2MTAyXSAgWzxmZmZmZmZmZjgxNWRjYTY2Pl0gcGFuaWMrMHg5MS8weDE5NApb
ICAgIDUuNDE3MDM0XSAgWzxmZmZmZmZmZjgxMDYzNDRiPl0gZG9fZXhpdCsweDQwYi8weDQ0MApb
ICAgIDUuNDE4MDA0XSAgWzxmZmZmZmZmZjgxNWY0MzUwPl0gb29wc19lbmQrMHhiMC8weGYwClsg
ICAgNS40MTkwNTNdICBbPGZmZmZmZmZmODEwMGQ5Mzg+XSBkaWUrMHg1OC8weDkwClsgICAgNS40
MTk5MjZdICBbPGZmZmZmZmZmODE1ZjNhMzQ+XSBkb190cmFwKzB4YzQvMHgxNzAKWyAgICA1LjQy
MjA4N10gIFs8ZmZmZmZmZmY4MTAwYWYyNT5dIGRvX2ludmFsaWRfb3ArMHg5NS8weGIwClsgICAg
NS40MjMxMjBdICBbPGZmZmZmZmZmODEwMTQwZWM+XSA/IHhzdGF0ZV9lbmFibGUrMHgzYy8weDUw
ClsgICAgNS40MjQyOTRdICBbPGZmZmZmZmZmODEwMDdiNjI+XSA/IGNoZWNrX2V2ZW50cysweDEy
LzB4MjAKWyAgICA1LjQyNTM1M10gIFs8ZmZmZmZmZmY4MTAwODIzOT5dID8gZ2V0X3BoeXNfdG9f
bWFjaGluZSsweDkvMHg3MApbICAgIDUuNDI2NTE1XSAgWzxmZmZmZmZmZjgxMDA1YzY5Pl0gPyBw
dGVfbWZuX3RvX3BmbisweDg5LzB4ZjAKWyAgICA1LjQyNzYwNF0gIFs8ZmZmZmZmZmY4MTAwNzQz
ZD5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGQvMHgxMApbICAgIDUuNDI4OTQ2XSAg
WzxmZmZmZmZmZjgxNWZjMmRiPl0gaW52YWxpZF9vcCsweDFiLzB4MjAKWyAgICA1LjQyOTkzMl0g
IFs8ZmZmZmZmZmY4MTAxNDBlYz5dID8geHN0YXRlX2VuYWJsZSsweDNjLzB4NTAKWyAgICA1LjQz
MTAxMl0gIFs8ZmZmZmZmZmY4MTAxNDBkYz5dID8geHN0YXRlX2VuYWJsZSsweDJjLzB4NTAKWyAg
ICA1LjQzMjA4Ml0gIFs8ZmZmZmZmZmY4MWNkOTdhYz5dIHhzdGF0ZV9lbmFibGVfYm9vdF9jcHUr
MHhhOS8weDE3NApbICAgIDUuNDMzMjk2XSAgWzxmZmZmZmZmZjgxMDA3YjRmPl0gPyB4ZW5fcmVz
dG9yZV9mbF9kaXJlY3RfcmVsb2MrMHg0LzB4NApbICAgIDUuNDM0OTk1XSAgWzxmZmZmZmZmZjgx
MDA0MDU3Pl0gPyB4ZW5fd3JpdGVfY3IwKzB4NzcvMHg5MApbICAgIDUuNDM2MDcxXSAgWzxmZmZm
ZmZmZjgxNWQwNmViPl0geHNhdmVfaW5pdCsweDI2LzB4MjgKWyAgICA1LjQzNzA2Ml0gIFs8ZmZm
ZmZmZmY4MTVkMjkzMj5dIGNwdV9pbml0KzB4MmJiLzB4MmQ4ClsgICAgNS40MzgwNjJdICBbPGZm
ZmZmZmZmODFjZDVmZjQ+XSB0cmFwX2luaXQrMHgxNjkvMHgxNzEKWyAgICA1LjQ0MTAwMF0gIFs8
ZmZmZmZmZmY4MWNkMGEyNz5dIHN0YXJ0X2tlcm5lbCsweDFkMC8weDNkZgpbICAgIDUuNDQyMjQ3
XSAgWzxmZmZmZmZmZjgxY2QwMzg4Pl0geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMi8w
eDEzNgpbICAgIDUuNDQzNTY4XSAgWzxmZmZmZmZmZjgxY2QzZWM2Pl0geGVuX3N0YXJ0X2tlcm5l
bCsweDVhYy8weDViMwooWEVOKSBEb21haW4gMCBjcmFzaGVkOiByZWJvb3RpbmcgbWFjaGluZSBp
biA1IHNlY29uZHMuCihYRU4pIFJlc2V0dGluZyB3aXRoIEFDUEkgTUVNT1JZIG9yIEkvTyBSRVNF
VF9SRUcuCg==

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B68AEXCCR03camp_--


From xen-devel-bounces@lists.xen.org Thu Apr 05 17:44:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 17:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFqjN-0002Zj-7y; Thu, 05 Apr 2012 17:44:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SFqjL-0002Ze-B5
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 17:44:19 +0000
Received: from [85.158.143.35:24106] by server-3.bemta-4.messagelabs.com id
	07/C7-05853-2F9DD7F4; Thu, 05 Apr 2012 17:44:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333647856!11468953!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA4MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19341 invoked from network); 5 Apr 2012 17:44:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 17:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189207309"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 13:44:15 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	13:44:15 -0400
Message-ID: <4F7DD9EE.3080404@citrix.com>
Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco

What is your Linux command line? does it include "console=hvc0"? 
Perhaps some early_printk settings are required.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 17:44:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 17:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFqjN-0002Zj-7y; Thu, 05 Apr 2012 17:44:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SFqjL-0002Ze-B5
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 17:44:19 +0000
Received: from [85.158.143.35:24106] by server-3.bemta-4.messagelabs.com id
	07/C7-05853-2F9DD7F4; Thu, 05 Apr 2012 17:44:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333647856!11468953!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA4MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19341 invoked from network); 5 Apr 2012 17:44:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 17:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330923600"; d="scan'208";a="189207309"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 13:44:15 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	13:44:15 -0400
Message-ID: <4F7DD9EE.3080404@citrix.com>
Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco

What is your Linux command line? does it include "console=hvc0"? 
Perhaps some early_printk settings are required.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 18:07:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 18:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFr5I-0002r1-8l; Thu, 05 Apr 2012 18:07:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFr5G-0002qw-Qd
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 18:06:59 +0000
Received: from [85.158.139.83:25604] by server-4.bemta-5.messagelabs.com id
	EB/EE-10788-24FDD7F4; Thu, 05 Apr 2012 18:06:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333649217!22697252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27612 invoked from network); 5 Apr 2012 18:06:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 18:06:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="11802489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 18:06:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 19:06:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFr5E-0006NJ-E0;
	Thu, 05 Apr 2012 18:06:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFr5E-0008Ue-Az;
	Thu, 05 Apr 2012 19:06:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12575-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 19:06:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12575: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12575 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12575/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                911bcb25143c2cbe3daac8785285d8daf03cf9fc
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 911bcb25143c2cbe3daac8785285d8daf03cf9fc
Merge: 96cbb60... 01627d9...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 4 12:00:01 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 18:07:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 18:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFr5I-0002r1-8l; Thu, 05 Apr 2012 18:07:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFr5G-0002qw-Qd
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 18:06:59 +0000
Received: from [85.158.139.83:25604] by server-4.bemta-5.messagelabs.com id
	EB/EE-10788-24FDD7F4; Thu, 05 Apr 2012 18:06:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333649217!22697252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27612 invoked from network); 5 Apr 2012 18:06:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 18:06:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="11802489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 18:06:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 19:06:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFr5E-0006NJ-E0;
	Thu, 05 Apr 2012 18:06:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFr5E-0008Ue-Az;
	Thu, 05 Apr 2012 19:06:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12575-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 19:06:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12575: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12575 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12575/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                911bcb25143c2cbe3daac8785285d8daf03cf9fc
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 911bcb25143c2cbe3daac8785285d8daf03cf9fc
Merge: 96cbb60... 01627d9...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 4 12:00:01 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 18:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 18:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFrS6-00037j-HJ; Thu, 05 Apr 2012 18:30:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFrS4-00037e-Ca
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 18:30:32 +0000
Received: from [85.158.143.35:60352] by server-2.bemta-4.messagelabs.com id
	7C/29-17550-7C4ED7F4; Thu, 05 Apr 2012 18:30:31 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333650630!13336874!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAxNzI3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10005 invoked from network); 5 Apr 2012 18:30:30 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 18:30:30 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFrS2-0000tY-AS; Thu, 05 Apr 2012 19:30:30 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Thu, 5 Apr 2012 19:29:58 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 5 Apr 2012 19:26:48 +0100
Thread-Index: AQHNE1mpSZuJQ9gdsEq4ZAG0NQ5eRg==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
Message-ID: <4F7DD9EE.3080404@citrix.com>
Content-Type: text/plain; charset="ISO-8859-1"

On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco

What is your Linux command line? does it include "console=hvc0"? 
Perhaps some early_printk settings are required.

Please include my email in your replies, thank you.

Yes, it includes hvc0. I used your tutorial to setup the SOL.

title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
root         (hd0,0)
kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
module       /initrd-2.6.31.6.img

Something like this, I am not at the machine anymore.

Francisco

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 18:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 18:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFrS6-00037j-HJ; Thu, 05 Apr 2012 18:30:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFrS4-00037e-Ca
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 18:30:32 +0000
Received: from [85.158.143.35:60352] by server-2.bemta-4.messagelabs.com id
	7C/29-17550-7C4ED7F4; Thu, 05 Apr 2012 18:30:31 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333650630!13336874!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAxNzI3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10005 invoked from network); 5 Apr 2012 18:30:30 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 18:30:30 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFrS2-0000tY-AS; Thu, 05 Apr 2012 19:30:30 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Thu, 5 Apr 2012 19:29:58 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 5 Apr 2012 19:26:48 +0100
Thread-Index: AQHNE1mpSZuJQ9gdsEq4ZAG0NQ5eRg==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
Message-ID: <4F7DD9EE.3080404@citrix.com>
Content-Type: text/plain; charset="ISO-8859-1"

On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco

What is your Linux command line? does it include "console=hvc0"? 
Perhaps some early_printk settings are required.

Please include my email in your replies, thank you.

Yes, it includes hvc0. I used your tutorial to setup the SOL.

title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
root         (hd0,0)
kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
module       /initrd-2.6.31.6.img

Something like this, I am not at the machine anymore.

Francisco

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 19:45:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 19:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFsbZ-0003W7-6B; Thu, 05 Apr 2012 19:44:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SFsbY-0003W2-1h
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 19:44:24 +0000
Received: from [193.109.254.147:35597] by server-9.bemta-14.messagelabs.com id
	17/86-05787-716FD7F4; Thu, 05 Apr 2012 19:44:23 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333655057!3446794!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28020 invoked from network); 5 Apr 2012 19:44:18 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Apr 2012 19:44:18 -0000
Received: from mail181-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 19:44:16 +0000
Received: from mail181-tx2 (localhost [127.0.0.1])	by
	mail181-tx2-R.bigfish.com (Postfix) with ESMTP id C77CA4603BC;
	Thu,  5 Apr 2012 19:44:16 +0000 (UTC)
X-SpamScore: -18
X-BigFish: VPS-18(zzbb2dI9371Ic85dh1432N98dK14ffOzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail181-tx2 (localhost.localdomain [127.0.0.1]) by mail181-tx2
	(MessageSwitch) id 1333655050311553_27032;
	Thu,  5 Apr 2012 19:44:10 +0000 (UTC)
Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.248])	by
	mail181-tx2.bigfish.com (Postfix) with ESMTP id 4318C1C029F;
	Thu,  5 Apr 2012 19:44:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 19:44:08 +0000
X-WSS-ID: 0M20UTJ-01-54R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24FF01028068;	Thu,  5 Apr 2012 14:44:06 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Apr 2012 14:44:23 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	14:44:06 -0500
Message-ID: <4F7DF441.5040104@amd.com>
Date: Thu, 5 Apr 2012 14:36:33 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in 
xstate_enable() function to be exact) related. You can try to disable 
xsave to to see if this helps.

-Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 19:45:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 19:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFsbZ-0003W7-6B; Thu, 05 Apr 2012 19:44:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SFsbY-0003W2-1h
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 19:44:24 +0000
Received: from [193.109.254.147:35597] by server-9.bemta-14.messagelabs.com id
	17/86-05787-716FD7F4; Thu, 05 Apr 2012 19:44:23 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333655057!3446794!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28020 invoked from network); 5 Apr 2012 19:44:18 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Apr 2012 19:44:18 -0000
Received: from mail181-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 19:44:16 +0000
Received: from mail181-tx2 (localhost [127.0.0.1])	by
	mail181-tx2-R.bigfish.com (Postfix) with ESMTP id C77CA4603BC;
	Thu,  5 Apr 2012 19:44:16 +0000 (UTC)
X-SpamScore: -18
X-BigFish: VPS-18(zzbb2dI9371Ic85dh1432N98dK14ffOzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail181-tx2 (localhost.localdomain [127.0.0.1]) by mail181-tx2
	(MessageSwitch) id 1333655050311553_27032;
	Thu,  5 Apr 2012 19:44:10 +0000 (UTC)
Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.248])	by
	mail181-tx2.bigfish.com (Postfix) with ESMTP id 4318C1C029F;
	Thu,  5 Apr 2012 19:44:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 19:44:08 +0000
X-WSS-ID: 0M20UTJ-01-54R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24FF01028068;	Thu,  5 Apr 2012 14:44:06 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Apr 2012 14:44:23 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	14:44:06 -0500
Message-ID: <4F7DF441.5040104@amd.com>
Date: Thu, 5 Apr 2012 14:36:33 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in 
xstate_enable() function to be exact) related. You can try to disable 
xsave to to see if this helps.

-Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFswR-0003l7-2O; Thu, 05 Apr 2012 20:05:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFswO-0003kx-TM
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 20:05:57 +0000
Received: from [85.158.139.83:23406] by server-5.bemta-5.messagelabs.com id
	8C/D0-13566-32BFD7F4; Thu, 05 Apr 2012 20:05:55 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333656353!19980685!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8733 invoked from network); 5 Apr 2012 20:05:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330923600"; d="scan'208";a="189231063"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 16:05:53 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Thu, 5 Apr 2012 16:05:53 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 5 Apr 2012 16:06:12 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0TFAooeaEDOrXqQnadFZyqCr2GiQAUAmHg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333620502.937.60.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Thursday, April 05, 2012 6:08 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Wed, 2012-04-04 at 20:25 +0100, Ross Philipson wrote:
> > > If it's convenient (or even just for consistency) there's no reason
> > > IMHO not to include the length even where the length is part of the
> data.
> > > Similarly you can add checksums etc if those are useful.
> > >
> >
> > Well actually it does not really do any good to have the length in
> > xenstore (at least for the types we are currently talking about) other
> > than knowing the overall extent of the blob. The problem is that we
> > are talking about multiple tables chained together. For ACPI this is
> > not a problem because the table length is specified in the table
> > header. For SMBIOS (where there will almost certainly be multiple
> > tables) the length of each table is not specified and so the set would
> > have to be re-parsed in hvmloader to find each individual table.
> 
> I see. So you need to be able to find the individual tables so that
> smbios_type_<N>_init can check for an overriding table <N> in the
> passed-through tables, it seems reasonable to try and avoid needing to
> parse a big lump of tables each time to see if the one you are
> interested in is there.
> 
> I think this can work by having .../smbios/<N>/{address,etc} in
> XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> smbios_type_vendor_oem_init, which I think could easily just be a single
> lump?
> 
> I think you don't need the same thing for the ACPI side since there you
> just provide secondary tables?

There could be quite a few SMBIOS tables being passed in. On the order of 20 - 30 of them and thet are pretty small. It seems a bit odd to break it up like this for lots of little chunks. There could be more than one ACPI table also (multiple SSDTs and/or other static tables). Also the OEM SMBIOS tables are all discrete and they could not go in as a single lump.

This approach will certainly work but I am still not sure about it being the best way. 

> 
> >  That was the motivation for a separate table header we define. I
> > still think some simple entry delimiter structure with some small
> > amount of information about each item is a good idea.
> 
> I think the content of .../smbios/<N>/* serves the same purpose as a
> delimiter?

Yes if we use this approach.

> 
> > But in general I don't have a problem with using xenstore for this
> > sort of thing so I am fine with the basic concept.
> >
> > > > > you'd need to do is have a type code and an address in xenstore
> > > > > somewhere, the same way we pass a type code and a string for the
> > > > > other BIOS customizations.
> > > > >
> > > >
> > > > So I am not exactly sure how to proceed here since libxc seems the
> > > > correct place to load the individual blobs (ACPI tables, SMBIOS
> > > > junk) but libxc seems too low level to be writing values to
> > > > xenstore (and it does not do that at present). Would it be better
> > > > to have a peer API to
> > > > xc_hvm_build() that write the chunks and returns the addresses
> > > > where it loaded them? Or should it be totally moved out of libxc?
> > > > Advice would be appreciated...
> > >
> > > The layering relationship between libxc and libxs here is a bit of a
> > > pain, but lets not try and solve that now.
> > >
> > > I think you can just add a guest_address field to your struct
> > > xc_hvm_module as an output field which the caller would then push
> > > into xenstore along with the (potentially updated) length field.
> > >
> > > Given the above XS layout then I think where you have a list of
> > > modules in xc_hvm_build_args you can just have "struct xc_hvm_module
> acpi".
> > > Similarly for smbios and whatever new table types come up in the
> future.
> > > I don't think having each module type explicitly here matters since
> > > each new table type needs a bunch of support code in at least
> > > hvmloader anyway so adding a few lines to libxc to expose it at the
> > > same time is fine.
> >
> > That seems like a reasonable way to do it. Especially if (wrt below)
> > we have the caller glom the like bits together.
> >
> > >
> > > > Finally, I had made this a generic framework because I thought it
> > > > could be extended in the future to pass in other types of
> > > > firmware-ish blobs at runtime. It also handles the case where the
> > > > passing of one set of tables/blobs is not tied to passing another
> > > > set. E.g. in our work we pass in some static ACPI tables to
> > > > satisfy one feature and construct/pass-in an SSDT to satisfy
> another unrelated feature.
> > >
> > > I think it is ok to have it be up to the caller to glom those
> > > together into a single "ACPI" blob which is processed by hvmloader
> > > into the right places. Or is there a problem with that which hasn't
> occurred to me?
> > > (Likewise in the SMBIOS case)
> > >
> > > If it is a problem then
> > > 	.../acpi/0/...
> > > 	.../acpi/1/...
> > > (or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things.
> > > Not sure about the libxc level, I'll worry about it when you tell me
> > > what I've missed which makes it necessary ;-)
> >
> > Well that approach was mostly for flexibility (as in the scenario I
> > pointed out). The only other issue might be the measuring of
> > components by a domain builder but I don't think that that prevents
> > glomming. Presumably the glomming code is part of the overall domain
> > builder code so a measure-then-glom operation can happen. And doing
> > the merge in the tools makes the code in hvmloader simpler so I am
> > good with that.
> 
> You've convinced me that having the SMBIOS tables each be presented
> separately makes sense.
> 
> At the libxc layer you could have "struct xc_hvm_module *smbios". I
> expect in the simple case this would just point into an array on the
> callers stack but a caller could also do something more dynamic if they
> wanted to. If you think it would be useful then a linked-list thing here
> would also work.

Again assuming the xenstore approach, I guess it would probably have to be a linked list because there could be a fair number of them (mainly SMBIOS).

> 
> > Given all that, the only real issue I see at the moment is how to deal
> > with multiple entries within a blob that don't readily specify their
> > own lengths. I am in favor of a delimiting struct with possibly a
> > terminating form (like a flag). Then all we put in xenstore is the gpe
> > for each type.
> >
> > Finally I wanted to bring up again the idea of another helper
> > component (lib maybe) that can be used to build and glom (I like that
> > word) modules. Note that in many cases the passed in firmware is going
> > to be pulled from the host firmware. I already have bunches of codes
> > that do that. Perhaps I should start an RFC thread for that as a
> > separate task? Thoughts on this?
> 
> You mean some sort of libacpi / libsmbios type things, helper routines
> for parsing and manipulating tables etc? (such a thing doesn't already
> exist somewhere?)
> 
> I suspect your usecases are the ones which would make most extensive use
> of such a thing but I also assume that at least some of it would be
> useful to any caller which was passing in these tables. If you want to
> maintain it within the Xen tree then that works for me.

Yea along those lines. I was thinking of maybe a libxenhvm that had utility routines for collecting the system firmware information that one wanted to pass to a guest. It could also provide an API that wrapped up the setting of the firmware values that hvmloader consumes including the bits that are on the shared info page you want to get rid of. The usefulness of this library is diminished if we go the all xenstore route above so I am going to shelf this until that is settled.

Oh and yea, there are tools to get this information (acpidump/dmidecode) but they unfortunately do not come in library form or necessarily give you the desired output. And in newer kernels ACPI/DMI is accessible through sysfs.

> 
> Ian.
> 
> >
> > Thanks
> > Ross
> >
> > >
> > >
> > > Ian.
> > >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFswR-0003l7-2O; Thu, 05 Apr 2012 20:05:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFswO-0003kx-TM
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 20:05:57 +0000
Received: from [85.158.139.83:23406] by server-5.bemta-5.messagelabs.com id
	8C/D0-13566-32BFD7F4; Thu, 05 Apr 2012 20:05:55 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333656353!19980685!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8733 invoked from network); 5 Apr 2012 20:05:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330923600"; d="scan'208";a="189231063"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 16:05:53 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Thu, 5 Apr 2012 16:05:53 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 5 Apr 2012 16:06:12 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0TFAooeaEDOrXqQnadFZyqCr2GiQAUAmHg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333620502.937.60.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Thursday, April 05, 2012 6:08 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Wed, 2012-04-04 at 20:25 +0100, Ross Philipson wrote:
> > > If it's convenient (or even just for consistency) there's no reason
> > > IMHO not to include the length even where the length is part of the
> data.
> > > Similarly you can add checksums etc if those are useful.
> > >
> >
> > Well actually it does not really do any good to have the length in
> > xenstore (at least for the types we are currently talking about) other
> > than knowing the overall extent of the blob. The problem is that we
> > are talking about multiple tables chained together. For ACPI this is
> > not a problem because the table length is specified in the table
> > header. For SMBIOS (where there will almost certainly be multiple
> > tables) the length of each table is not specified and so the set would
> > have to be re-parsed in hvmloader to find each individual table.
> 
> I see. So you need to be able to find the individual tables so that
> smbios_type_<N>_init can check for an overriding table <N> in the
> passed-through tables, it seems reasonable to try and avoid needing to
> parse a big lump of tables each time to see if the one you are
> interested in is there.
> 
> I think this can work by having .../smbios/<N>/{address,etc} in
> XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> smbios_type_vendor_oem_init, which I think could easily just be a single
> lump?
> 
> I think you don't need the same thing for the ACPI side since there you
> just provide secondary tables?

There could be quite a few SMBIOS tables being passed in. On the order of 20 - 30 of them and thet are pretty small. It seems a bit odd to break it up like this for lots of little chunks. There could be more than one ACPI table also (multiple SSDTs and/or other static tables). Also the OEM SMBIOS tables are all discrete and they could not go in as a single lump.

This approach will certainly work but I am still not sure about it being the best way. 

> 
> >  That was the motivation for a separate table header we define. I
> > still think some simple entry delimiter structure with some small
> > amount of information about each item is a good idea.
> 
> I think the content of .../smbios/<N>/* serves the same purpose as a
> delimiter?

Yes if we use this approach.

> 
> > But in general I don't have a problem with using xenstore for this
> > sort of thing so I am fine with the basic concept.
> >
> > > > > you'd need to do is have a type code and an address in xenstore
> > > > > somewhere, the same way we pass a type code and a string for the
> > > > > other BIOS customizations.
> > > > >
> > > >
> > > > So I am not exactly sure how to proceed here since libxc seems the
> > > > correct place to load the individual blobs (ACPI tables, SMBIOS
> > > > junk) but libxc seems too low level to be writing values to
> > > > xenstore (and it does not do that at present). Would it be better
> > > > to have a peer API to
> > > > xc_hvm_build() that write the chunks and returns the addresses
> > > > where it loaded them? Or should it be totally moved out of libxc?
> > > > Advice would be appreciated...
> > >
> > > The layering relationship between libxc and libxs here is a bit of a
> > > pain, but lets not try and solve that now.
> > >
> > > I think you can just add a guest_address field to your struct
> > > xc_hvm_module as an output field which the caller would then push
> > > into xenstore along with the (potentially updated) length field.
> > >
> > > Given the above XS layout then I think where you have a list of
> > > modules in xc_hvm_build_args you can just have "struct xc_hvm_module
> acpi".
> > > Similarly for smbios and whatever new table types come up in the
> future.
> > > I don't think having each module type explicitly here matters since
> > > each new table type needs a bunch of support code in at least
> > > hvmloader anyway so adding a few lines to libxc to expose it at the
> > > same time is fine.
> >
> > That seems like a reasonable way to do it. Especially if (wrt below)
> > we have the caller glom the like bits together.
> >
> > >
> > > > Finally, I had made this a generic framework because I thought it
> > > > could be extended in the future to pass in other types of
> > > > firmware-ish blobs at runtime. It also handles the case where the
> > > > passing of one set of tables/blobs is not tied to passing another
> > > > set. E.g. in our work we pass in some static ACPI tables to
> > > > satisfy one feature and construct/pass-in an SSDT to satisfy
> another unrelated feature.
> > >
> > > I think it is ok to have it be up to the caller to glom those
> > > together into a single "ACPI" blob which is processed by hvmloader
> > > into the right places. Or is there a problem with that which hasn't
> occurred to me?
> > > (Likewise in the SMBIOS case)
> > >
> > > If it is a problem then
> > > 	.../acpi/0/...
> > > 	.../acpi/1/...
> > > (or s/0/SSDT0/ and s/1/SSDT1/ etc) works for the XS side of things.
> > > Not sure about the libxc level, I'll worry about it when you tell me
> > > what I've missed which makes it necessary ;-)
> >
> > Well that approach was mostly for flexibility (as in the scenario I
> > pointed out). The only other issue might be the measuring of
> > components by a domain builder but I don't think that that prevents
> > glomming. Presumably the glomming code is part of the overall domain
> > builder code so a measure-then-glom operation can happen. And doing
> > the merge in the tools makes the code in hvmloader simpler so I am
> > good with that.
> 
> You've convinced me that having the SMBIOS tables each be presented
> separately makes sense.
> 
> At the libxc layer you could have "struct xc_hvm_module *smbios". I
> expect in the simple case this would just point into an array on the
> callers stack but a caller could also do something more dynamic if they
> wanted to. If you think it would be useful then a linked-list thing here
> would also work.

Again assuming the xenstore approach, I guess it would probably have to be a linked list because there could be a fair number of them (mainly SMBIOS).

> 
> > Given all that, the only real issue I see at the moment is how to deal
> > with multiple entries within a blob that don't readily specify their
> > own lengths. I am in favor of a delimiting struct with possibly a
> > terminating form (like a flag). Then all we put in xenstore is the gpe
> > for each type.
> >
> > Finally I wanted to bring up again the idea of another helper
> > component (lib maybe) that can be used to build and glom (I like that
> > word) modules. Note that in many cases the passed in firmware is going
> > to be pulled from the host firmware. I already have bunches of codes
> > that do that. Perhaps I should start an RFC thread for that as a
> > separate task? Thoughts on this?
> 
> You mean some sort of libacpi / libsmbios type things, helper routines
> for parsing and manipulating tables etc? (such a thing doesn't already
> exist somewhere?)
> 
> I suspect your usecases are the ones which would make most extensive use
> of such a thing but I also assume that at least some of it would be
> useful to any caller which was passing in these tables. If you want to
> maintain it within the Xen tree then that works for me.

Yea along those lines. I was thinking of maybe a libxenhvm that had utility routines for collecting the system firmware information that one wanted to pass to a guest. It could also provide an API that wrapped up the setting of the firmware values that hvmloader consumes including the bits that are on the shared info page you want to get rid of. The usefulness of this library is diminished if we go the all xenstore route above so I am going to shelf this until that is settled.

Oh and yea, there are tools to get this information (acpidump/dmidecode) but they unfortunately do not come in library form or necessarily give you the desired output. And in newer kernels ACPI/DMI is accessible through sysfs.

> 
> Ian.
> 
> >
> > Thanks
> > Ross
> >
> > >
> > >
> > > Ian.
> > >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFswR-0003lE-DY; Thu, 05 Apr 2012 20:05:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alain.tchana@inria.fr>) id 1SFswQ-0003l2-2X
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:05:58 +0000
Received: from [85.158.139.83:32907] by server-10.bemta-5.messagelabs.com id
	3B/2C-08260-52BFD7F4; Thu, 05 Apr 2012 20:05:57 +0000
X-Env-Sender: alain.tchana@inria.fr
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333656354!18413282!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26384 invoked from network); 5 Apr 2012 20:05:55 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330902000"; 
	d="scan'208,217";a="139245822"
Received: from zmbs2.inria.fr ([128.93.142.15])
	by mail4-relais-sop.national.inria.fr with ESMTP;
	05 Apr 2012 22:05:53 +0200
Date: Thu, 5 Apr 2012 22:05:53 +0200 (CEST)
From: Alain Tchana <alain.tchana@inria.fr>
To: xen-devel@lists.xen.org
Message-ID: <93792556.794910.1333656353242.JavaMail.root@zmbs2.inria.fr>
In-Reply-To: <759798916.794821.1333655343974.JavaMail.root@zmbs2.inria.fr>
MIME-Version: 1.0
X-Originating-IP: [88.138.59.239]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - FF3.0
	(Linux)/6.0.15_GA_2995)
Subject: [Xen-devel] Domain migration source code interpretation in xl/libxl
	(xen-4.1.2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4570810394396298646=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4570810394396298646==
Content-Type: multipart/alternative; 
	boundary="----=_Part_794909_1362578652.1333656353241"

------=_Part_794909_1362578652.1333656353241
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi all, 
I am trying to understand domU migration in xen-4.1.2/tools/libxl/xm_cmdimpl.c. Here are my questions: 

1) Is there any documentation which explain each functions? 

2) What is the difference between these two functions: int main_migrate(int argc, char **argv) and int main_migrate_receive(int argc, char **argv)? 

3) In the function: static void migrate_domain(const char *domain_spec, const char *rune, const char *override_config_file) , 
what does: 

*) save_domain_core_begin(domain_spec, override_config_file, &config_data, &config_len); 

*)migrate_read_fixedmessage(recv_fd, migrate_receiver_banner, 
sizeof(migrate_receiver_banner)-1, 
"banner", rune); 

*)save_domain_core_writeconfig(send_fd, "migration stream", 
config_data, config_len); 

*)migration_child_report(child, recv_fd); 

*)Finally, which section of the" migrate_domain" function performs memory copy from the initial host to the target host? 

Please, apologize the number of questions. 

Thanks in advance for your answers. 
Alain 

------=_Part_794909_1362578652.1333656353241
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: times new roman,new york,times,serif; font-size: =
12pt; color: #000000'>Hi all,<br>I am trying to understand domU migration i=
n xen-4.1.2/tools/libxl/xm_cmdimpl.c. Here are my questions:<br><br>1) Is t=
here any documentation which explain each functions?<br><br>2) What is the =
difference between these two functions: int main_migrate(int argc, char **a=
rgv) and int main_migrate_receive(int argc, char **argv)?<br><br>3) In the =
function: static void migrate_domain(const char *domain_spec, const char *r=
une, const char *override_config_file), <br>&nbsp;&nbsp;&nbsp; what does:<b=
r>&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; *) save_domain_core_begin(domain_spec=
, override_config_file, &amp;config_data, &amp;config_len);<br><br>&nbsp;&n=
bsp;&nbsp; *)migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,<br=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sizeof(migrate_rece=
iver_banner)-1,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "=
banner", rune);<br><br>&nbsp;&nbsp;&nbsp; *)save_domain_core_writeconfig(se=
nd_fd, "migration stream",<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; co=
nfig_data, config_len);<br><br>&nbsp;&nbsp;&nbsp; *)migration_child_report(=
child, recv_fd);<br>&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; *)Finally, which se=
ction of the" migrate_domain" function performs memory copy from the initia=
l host to the target host?<br><br>Please, apologize the number of questions=
.<br><br>Thanks in advance for your answers.<br>Alain<br></div></body></htm=
l>
------=_Part_794909_1362578652.1333656353241--


--===============4570810394396298646==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4570810394396298646==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 20:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFswR-0003lE-DY; Thu, 05 Apr 2012 20:05:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alain.tchana@inria.fr>) id 1SFswQ-0003l2-2X
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:05:58 +0000
Received: from [85.158.139.83:32907] by server-10.bemta-5.messagelabs.com id
	3B/2C-08260-52BFD7F4; Thu, 05 Apr 2012 20:05:57 +0000
X-Env-Sender: alain.tchana@inria.fr
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333656354!18413282!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26384 invoked from network); 5 Apr 2012 20:05:55 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330902000"; 
	d="scan'208,217";a="139245822"
Received: from zmbs2.inria.fr ([128.93.142.15])
	by mail4-relais-sop.national.inria.fr with ESMTP;
	05 Apr 2012 22:05:53 +0200
Date: Thu, 5 Apr 2012 22:05:53 +0200 (CEST)
From: Alain Tchana <alain.tchana@inria.fr>
To: xen-devel@lists.xen.org
Message-ID: <93792556.794910.1333656353242.JavaMail.root@zmbs2.inria.fr>
In-Reply-To: <759798916.794821.1333655343974.JavaMail.root@zmbs2.inria.fr>
MIME-Version: 1.0
X-Originating-IP: [88.138.59.239]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - FF3.0
	(Linux)/6.0.15_GA_2995)
Subject: [Xen-devel] Domain migration source code interpretation in xl/libxl
	(xen-4.1.2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4570810394396298646=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4570810394396298646==
Content-Type: multipart/alternative; 
	boundary="----=_Part_794909_1362578652.1333656353241"

------=_Part_794909_1362578652.1333656353241
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi all, 
I am trying to understand domU migration in xen-4.1.2/tools/libxl/xm_cmdimpl.c. Here are my questions: 

1) Is there any documentation which explain each functions? 

2) What is the difference between these two functions: int main_migrate(int argc, char **argv) and int main_migrate_receive(int argc, char **argv)? 

3) In the function: static void migrate_domain(const char *domain_spec, const char *rune, const char *override_config_file) , 
what does: 

*) save_domain_core_begin(domain_spec, override_config_file, &config_data, &config_len); 

*)migrate_read_fixedmessage(recv_fd, migrate_receiver_banner, 
sizeof(migrate_receiver_banner)-1, 
"banner", rune); 

*)save_domain_core_writeconfig(send_fd, "migration stream", 
config_data, config_len); 

*)migration_child_report(child, recv_fd); 

*)Finally, which section of the" migrate_domain" function performs memory copy from the initial host to the target host? 

Please, apologize the number of questions. 

Thanks in advance for your answers. 
Alain 

------=_Part_794909_1362578652.1333656353241
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: times new roman,new york,times,serif; font-size: =
12pt; color: #000000'>Hi all,<br>I am trying to understand domU migration i=
n xen-4.1.2/tools/libxl/xm_cmdimpl.c. Here are my questions:<br><br>1) Is t=
here any documentation which explain each functions?<br><br>2) What is the =
difference between these two functions: int main_migrate(int argc, char **a=
rgv) and int main_migrate_receive(int argc, char **argv)?<br><br>3) In the =
function: static void migrate_domain(const char *domain_spec, const char *r=
une, const char *override_config_file), <br>&nbsp;&nbsp;&nbsp; what does:<b=
r>&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; *) save_domain_core_begin(domain_spec=
, override_config_file, &amp;config_data, &amp;config_len);<br><br>&nbsp;&n=
bsp;&nbsp; *)migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,<br=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sizeof(migrate_rece=
iver_banner)-1,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "=
banner", rune);<br><br>&nbsp;&nbsp;&nbsp; *)save_domain_core_writeconfig(se=
nd_fd, "migration stream",<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; co=
nfig_data, config_len);<br><br>&nbsp;&nbsp;&nbsp; *)migration_child_report(=
child, recv_fd);<br>&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; *)Finally, which se=
ction of the" migrate_domain" function performs memory copy from the initia=
l host to the target host?<br><br>Please, apologize the number of questions=
.<br><br>Thanks in advance for your answers.<br>Alain<br></div></body></htm=
l>
------=_Part_794909_1362578652.1333656353241--


--===============4570810394396298646==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4570810394396298646==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 20:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFt84-00044K-KC; Thu, 05 Apr 2012 20:18:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFt83-00044F-JB
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 20:17:59 +0000
Received: from [85.158.138.51:27787] by server-12.bemta-3.messagelabs.com id
	61/6C-30663-5FDFD7F4; Thu, 05 Apr 2012 20:17:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333657076!20818949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25336 invoked from network); 5 Apr 2012 20:17:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:17:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330905600"; d="scan'208";a="11803980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 20:17:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 21:17:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFt7z-0007Ez-Cz;
	Thu, 05 Apr 2012 20:17:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFt7y-0003Ne-SG;
	Thu, 05 Apr 2012 21:17:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12578-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 21:17:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12578: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12578 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12578/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12567

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  6f224431eca2
baseline version:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=6f224431eca2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 6f224431eca2
+ branch=xen-4.1-testing
+ revision=6f224431eca2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-4.1-testing.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 6f224431eca2 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 5 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFt84-00044K-KC; Thu, 05 Apr 2012 20:18:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFt83-00044F-JB
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 20:17:59 +0000
Received: from [85.158.138.51:27787] by server-12.bemta-3.messagelabs.com id
	61/6C-30663-5FDFD7F4; Thu, 05 Apr 2012 20:17:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1333657076!20818949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25336 invoked from network); 5 Apr 2012 20:17:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:17:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330905600"; d="scan'208";a="11803980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 20:17:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Apr 2012 21:17:55 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFt7z-0007Ez-Cz;
	Thu, 05 Apr 2012 20:17:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFt7y-0003Ne-SG;
	Thu, 05 Apr 2012 21:17:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12578-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Apr 2012 21:17:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12578: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12578 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12578/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12567

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  6f224431eca2
baseline version:
 xen                  b574b8b6bb10

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=6f224431eca2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 6f224431eca2
+ branch=xen-4.1-testing
+ revision=6f224431eca2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-4.1-testing.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 6f224431eca2 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 5 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFt89-00044t-5i; Thu, 05 Apr 2012 20:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFt87-00044d-La
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:18:03 +0000
Received: from [193.109.254.147:30967] by server-9.bemta-14.messagelabs.com id
	AB/30-05787-AFDFD7F4; Thu, 05 Apr 2012 20:18:02 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333657081!3446710!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAxODc1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28390 invoked from network); 5 Apr 2012 20:18:02 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 20:18:02 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFt85-0002CM-Br; Thu, 05 Apr 2012 21:18:01 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Thu, 5 Apr 2012 21:17:18 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Thu, 5 Apr 2012 21:17:17 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0TZIJfNaO2nJEASjWbYakGkBmdEwAA9xar
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
In-Reply-To: <4F7DF441.5040104@amd.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 20:36
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in
xstate_enable() function to be exact) related. You can try to disable
xsave to to see if this helps.

-Wei

Sorry about the untitled message. 

Should I be the one disabling xsave or is that for Andrew to change something?
How can I do that?

Anyway, shouldn't Xen support it?

cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFt89-00044t-5i; Thu, 05 Apr 2012 20:18:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFt87-00044d-La
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:18:03 +0000
Received: from [193.109.254.147:30967] by server-9.bemta-14.messagelabs.com id
	AB/30-05787-AFDFD7F4; Thu, 05 Apr 2012 20:18:02 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333657081!3446710!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAxODc1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28390 invoked from network); 5 Apr 2012 20:18:02 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 20:18:02 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFt85-0002CM-Br; Thu, 05 Apr 2012 21:18:01 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Thu, 5 Apr 2012 21:17:18 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Thu, 5 Apr 2012 21:17:17 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0TZIJfNaO2nJEASjWbYakGkBmdEwAA9xar
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
In-Reply-To: <4F7DF441.5040104@amd.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 20:36
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in
xstate_enable() function to be exact) related. You can try to disable
xsave to to see if this helps.

-Wei

Sorry about the untitled message. 

Should I be the one disabling xsave or is that for Andrew to change something?
How can I do that?

Anyway, shouldn't Xen support it?

cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:29:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:29:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFtJB-0004Tm-Js; Thu, 05 Apr 2012 20:29:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFtJA-0004Th-C7
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 20:29:28 +0000
Received: from [85.158.138.51:13571] by server-9.bemta-3.messagelabs.com id
	16/F1-10923-7A00E7F4; Thu, 05 Apr 2012 20:29:27 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333657763!20968272!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11640 invoked from network); 5 Apr 2012 20:29:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:29:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330923600"; d="scan'208";a="189234165"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 16:29:22 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Thu, 5 Apr 2012 16:29:22 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 5 Apr 2012 16:29:41 -0400
Thread-Topic: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
	support
Thread-Index: Ac0TGCIUQTDIgeTuSjWl6s/GwRg9sAAT3lrA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE5446@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
	<1333622260.937.78.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333622260.937.78.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
 support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: Thursday, April 05, 2012 6:38 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
> support
>
> On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> >                              From:
> > Ross Philipson
> > <Ross.Philipson@citrix.com>
> >                                To:
> > xen-devel@lists.xensource.com
> > <xen-devel@lists.xensource.com>
> >                           Subject:
> > [Xen-devel] [PATCH 04/07] HVM
> > firmware passthrough: SMBIOS
> > support
> >                              Date:
> > Mon, 19 Mar 2012 22:04:09 +0000
> >                        Message-id:
> > <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
> >
> >
> > Pass through support for the SMBIOS tables including a few new DMTF
> > defines types and support of OEM defined tables. Passed in SMBIOS
> > types override the default internal values. Flags control the new
> > tables so that with default values the SMBIOS tables look exactly as
> > they do before the patches.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> >
> >
> >
> >
> >
> >
> >
> > differences
> > between files
> > attachment
> > (hvm-firmware-passthrough-04.patch)
> >
> > # HG changeset patch
> > # Parent a0d871dadf1d482d77bf57a059a55098e2bfb078
> > Pass through support for the SMBIOS tables including a few new DMTF
> > defines types and support of OEM defined tables. Passed in SMBIOS
> > types override the default internal values. Flags control the new
> > tables so that with default values the SMBIOS tables look exactly as
> > they do before the patches.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> > diff -r a0d871dadf1d tools/firmware/hvmloader/smbios.c
> > --- a/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:45:12 2012 -0400
> > +++ b/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:52:13 2012 -0400
> > @@ -23,8 +23,10 @@
> >  #include <stdint.h>
> >  #include <xen/xen.h>
> >  #include <xen/version.h>
> > +#include <xen/hvm/hvm_defs.h>
> >  #include "smbios_types.h"
> >  #include "util.h"
> > +#include "modules.h"
> >  #include "hypercall.h"
> >
> >  static int
> > @@ -49,6 +51,8 @@ static void *
> >  smbios_type_1_init(void *start, const char *xen_version,
> >                     uint8_t uuid[16]);  static void *
> > +smbios_type_2_init(void *start);
> > +static void *
> >  smbios_type_3_init(void *start);
> >  static void *
> >  smbios_type_4_init(void *start, unsigned int cpu_number, @@ -64,8
> > +68,14 @@ smbios_type_19_init(void *start, uint32_  static void *
> > smbios_type_20_init(void *start, uint32_t memory_size_mb, int
> > instance);  static void *
> > +smbios_type_22_init(void *start);
> > +static void *
> >  smbios_type_32_init(void *start);
> >  static void *
> > +smbios_type_39_init(void *start);
> > +static void *
> > +smbios_type_vendor_oem_init(void *start); static void *
> >  smbios_type_127_init(void *start);
> >
> >  static void
> > @@ -85,6 +95,35 @@ get_cpu_manufacturer(char *buf, int len)
> >          strncpy(buf, "unknown", len);  }
> >
> > +static uint32_t
> > +get_smbios_control_flags(void)
> > +{
> > +    static uint64_t flags;
> > +    static int read = 0;
> > +
> > +    if ( !read )
> > +    {
> > +        flags = strtoll(xenstore_read(HVM_XS_SMBIOS_FLAGS, "0"),
> > NULL, 0);
>
> Rather than encoding these as a bit field, written as ascii into
> xenstore and then parsed back into a number again I think you may as
> well just have a node for each individual flag.

Yes that would be better.

>
> > +        read = 1;
> > +    }
> > +
> > +    return (uint32_t)flags;
> > +}
> > +
> > +static void*
> > +get_smbios_passthrough_table(uint8_t type, uint32_t *length_out) {
> > +    struct hvm_modules_iterator iter;
> > +    uint32_t flags = get_smbios_control_flags();
> > +
> > +    if ( flags & HVM_SMBIOS_DISABLE_PASSTHROUGH )
>
> This check is the same as just not providing the tables?

Yeah I need to rethink the flags in general.

>
> > +        return NULL;
> > +
> > +    init_smbios_module_iterator(&iter, type, 0);
> > +
> > +    return hvm_find_module_entry(&iter, length_out); }
> > +
> >  static int
> >  write_smbios_tables(void *ep, void *start,
> >                      uint32_t vcpus, uint64_t memsize, [...] @@ -338,6
> > +393,18 @@ smbios_type_1_init(void *start, const ch
> >      char uuid_str[37];
> >      struct smbios_type_1 *p = (struct smbios_type_1 *)start;
> >      const char *s;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    ptable = get_smbios_passthrough_table(1, &length);
> > +    if ( (ptable != NULL)&&(length > 0) )
> > +    {
> > +        memcpy(start, ptable, length);
> > +
> > +        /* Fix up, use consistent handles */
> > +        p->header.handle = 0x100;
> > +        return (start + length);
> > +    }
>
> This seems like a pretty common pattern, could it be pulled up into the
> caller of all these init functions?

I can try to make some of it common.

>
> I know it's a pre-existing problem but perhaps giving the handle numbers
> #defined names would make things a bit more obvious. For the OEM tables
> and the potential for clashes (which you commented on in that function)
> at least then there would be a sort of index of the ones which are used.
>
> I suppose you could also then push responsibility for maintaining this
> consistency up to whoever was providing the table and if they wanted
> they could use there own numbering and ensure consistency across the
> board themselves.

Yes I really like that idea of defining the handles we use. I will make things much clearer.

>
> >      memset(p, 0, sizeof(*p));
> >
> > @@ -380,12 +447,90 @@ smbios_type_1_init(void *start, const ch
> >      return start+1;
> >  }
> >
> > +/* Type 2 -- System Board */
> > +static void *
> > +smbios_type_2_init(void *start)
> > +{
> > +    struct smbios_type_2 *p = (struct smbios_type_2 *)start;
> > +    uint8_t *bptr;
> > +    const char *s;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( (get_smbios_control_flags() &
> > HVM_SMBIOS_INCLUDE_SYSTEM_BOARD) == 0 )
>
> Is there any reason you wouldn't want this table now that you've added
> it?

My thinking was that by default if you passed nothing in and did not set any flags it would be exactly the same as before I started.

>
> > +        return start;
> > +
> > +    ptable = get_smbios_passthrough_table(2, &length);
> > +    if ( (ptable != NULL)&&(length > 0) )
> > +    {
> > +        memcpy(start, ptable, length);
> > +
> > +        /* Fix up, use consistent handles, set chassis handle */
> > +        p->header.handle = 0x200;
> > +
> > +        if ( p->header.length >= 13 )
> > +        {
> > +            bptr = ((uint8_t*)start) + 11;
> > +            if ( *((uint16_t*)bptr) != 0 )
> > +                *((uint16_t*)bptr) = 0x300; /* current chassis handle
>
> This is to match the handle of the type 3 table?
>
> I don't see a corresponding thing in the constructed version of this
> table below, is that normal?

So per the spec, the table can vary in size. The default one is the minimum but if the passed in one contains the chassis handle field, it should match the actual chassis table's handle. There is a bug here though; it should be:
 if ( p->header.length > 13 )

>
> >  */
> > +        }
> > +
> > +        return (start + length);
> > +    }
> > +
> > +    memset(p, 0, sizeof(*p));
> > +
> > +    p->header.type = 2;
> > +    p->header.length = sizeof(struct smbios_type_2);
> > +    p->header.handle = 0x200;
> > +
> > +    p->manufacturer_str = 1;
> > +    p->product_name_str = 2;
> > +    p->version_str = 0;
> > +    p->serial_number_str = 0;
> > +
> > +    start += sizeof(struct smbios_type_2);
> > +
> > +    s = xenstore_read("bios-strings/board-manufacturer", "Xen");
> > +    strcpy((char *)start, s);
> > +    start += strlen(s) + 1;
> > +
> > +    s = xenstore_read("bios-strings/board-product-name", "HVM domU");
> > +    strcpy((char *)start, s);
> > +    start += strlen(s) + 1;
> > +
> > +    /* no internal defaults for this if the value is not set */
> > +    s = xenstore_read("bios-strings/board-serial-number", NULL);
> > +    if ( (s != NULL)&&(*s != '\0') )
> > +    {
> > +        strcpy((char *)start, s);
> > +        start += strlen(s) + 1;
> > +        p->serial_number_str = 3;
> > +    }
> > +
> > +    *((uint8_t *)start) = 0;
> > +    return start+1;
> > +}
>
> [...]
> > @@ -403,9 +548,20 @@ smbios_type_3_init(void *start)
> >      p->security_status = 0x02; /* unknown */
> >
> >      start += sizeof(struct smbios_type_3);
> > -
> > -    strcpy((char *)start, "Xen");
> > -    start += strlen("Xen") + 1;
> > +
> > +    s = xenstore_read("bios-strings/enclosure-manufacturer", "Xen");
> > +    strcpy((char *)start, s);
> > +    start += strlen(s) + 1;
> > +
> > +    /* no internal defaults for this if the value is not set */
> > +    s = xenstore_read("bios-strings/enclosure-serial-number", NULL);
> > +    if ( (s != NULL)&&(*s != '\0') )
> > +    {
> > +        strcpy((char *)start, s);
> > +        start += strlen(s) + 1;
> > +        p->serial_number_str = 2;
> > +    }
> > +
> >      *((uint8_t *)start) = 0;
> >      return start+1;
> >  }
> [...]
> > @@ -609,6 +777,66 @@ smbios_type_20_init(void *start, uint32_
> >      return start+2;
> >  }
> >
> > +/* Type 22 -- Portable Battery */
> > +static void *
> > +smbios_type_22_init(void *start)
> > +{
> > +    struct smbios_type_22 *p = (struct smbios_type_22 *)start;
> > +    static const char *smbios_release_date = __SMBIOS_DATE__;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( (get_smbios_control_flags() &
> > HVM_SMBIOS_INCLUDE_PORTABLE_BATTERY)
> > +          == 0 )
> > +        return start;
>
> Could an argument be made here that either you want to pass through some
> underlying table or you don't want the table at all? Or is there a use
> case for having hvmloader fake one up?

TBH I am not 100% sure about this one. The faked up table was introduced when we started surfacing ACPI battery devices in the guests. There are no comments or records as to what the tie might be. This would need some testing with HVM guests.

>
> > +
> > +    ptable = get_smbios_passthrough_table(22, &length);
> > +    if ( (ptable != NULL)&&(length > 0) )
> > +    {
> > +        memcpy(start, ptable, length);
> > +
> > +        /* Fix up, use consistent handles */
> > +        p->header.handle = 0x1600;
> > +        return (start + length);
> > +    }
> > +
> > +    memset(p, 0, sizeof(*p));
> > +
> > +    p->header.type = 22;
> > +    p->header.length = sizeof(struct smbios_type_22);
> > +    p->header.handle = 0x1600;
> > +
> > +    p->location_str = 1;
> > +    p->manufacturer_str = 2;
> > +    p->manufacturer_date_str = 3;
> > +    p->serial_number_str = 0;
> > +    p->device_name_str = 4;
> > +    p->device_chemistry = 0x2; /* Unknown */
> > +    p->device_capacity = 0; /* Unknown */
> > +    p->device_voltage = 0; /* Unknown */
> > +    p->sbds_version_number = 0;
> > +    p->max_error = 0xff; /* Unknown */
> > +    p->sbds_serial_number = 0;
> > +    p->sbds_manufacturer_date = 0;
> > +    p->sbds_device_chemistry = 0;
> > +    p->design_capacity_multiplier = 0;
> > +    p->oem_specific = 0;
> > +
> > +    start += sizeof(struct smbios_type_22);
> > +
> > +    strcpy((char *)start, "Primary");
> > +    start += strlen("Primary") + 1;
> > +    strcpy((char *)start, "Xen");
> > +    start += strlen("Xen") + 1;
> > +    strcpy((char *)start, smbios_release_date);
> > +    start += strlen(smbios_release_date) + 1;
> > +    strcpy((char *)start, "XEN-VBAT");
> > +    start += strlen("XEN-VBAT") + 1;
> > +
> > +    *((uint8_t *)start) = 0;
> > +    return start+1;
> > +}
> > +
> >  /* Type 32 -- System Boot Information */  static void *
> > smbios_type_32_init(void *start) @@ -628,6 +856,71 @@
> > smbios_type_32_init(void *start)
> >      return start+2;
> >  }
> >
> > +/* Type 39 -- Power Supply */
> > +static void *
> > +smbios_type_39_init(void *start)
> > +{
> > +    struct smbios_type_39 *p = (struct smbios_type_39 *)start;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( (get_smbios_control_flags() &
> > HVM_SMBIOS_INCLUDE_POWER_SUPPLY)
> > +          == 0 )
> > +        return start;
> > +
> > +    /* No default values - only present if the table is passed in */
> > +    ptable = get_smbios_passthrough_table(39, &length);
> > +    if ( (ptable == NULL)||(length == 0) )
> > +        return start;
> > +
> > +    memcpy(start, ptable, length);
> > +
> > +    /* Fix up, use consistent handles */
> > +    p->header.handle = 0x2700;
> > +
> > +    /* These devices are not present */
> > +    p->input_voltage_probe_handle = 0xFFFF;
> > +    p->cooling_device_handle = 0xFFFF;
> > +    p->input_current_probe_handle = 0xFFFF;
>
> I think responsibility for setting these up correctly ought to lie with
> whoever passed the table in.

Agreed

>
> > +
> > +    return (start + length);
> > +}
> > +
> > +static void *
> > +smbios_type_vendor_oem_init(void *start) {
> > +    struct hvm_modules_iterator iter;
> > +    uint32_t flags = get_smbios_control_flags();
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( ((flags & HVM_SMBIOS_INCLUDE_VENDOR_OEM) == 0)||
> > +         (flags & HVM_SMBIOS_DISABLE_PASSTHROUGH) )
> > +        return start;
> > +
> > +    /* Looking for any and all vendor/OEM defined tables passed in.
> > */
> > +    init_smbios_module_iterator(&iter, 128, 255);
> > +
> > +    do
> > +    {
> > +        ptable = hvm_find_module_entry(&iter, &length);
> > +        if ( (ptable != NULL)&&(length > 0) )
> > +        {
> > +            /*
> > +             * Vendor/OEM table, copy it in. Note the handle values
> > cannot
> > +             * be changed since it is unknown what is in each of
> > these tables
> > +             * but they could contain handle references to other
> > tables. This
> > +             * means a slight risk of collision with the tables above
> > but that
> > +             * would have to be dealt with on a case by case basis.
> > +             */
> > +            memcpy(start, ptable, length);
> > +            start += length;
>
> Do you also need to track the size of the largest table as well as the
> total number, for the purposes of filling in the fields in the entry
> point?

No. The start += length and the do_struct() macro do that work.

>
> > +        }
> > +    } while ( ptable != NULL );
> > +
> > +    return start;
> > +}
> > +
> >  /* Type 127 -- End of Table */
> >  static void *
> >  smbios_type_127_init(void *start)
> > diff -r a0d871dadf1d tools/firmware/hvmloader/smbios_types.h
> > --- a/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:45:12
> > 2012 -0400
> > +++ b/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:52:13
> > 2012 -0400
> > @@ -84,6 +84,15 @@ struct smbios_type_1 {
> >      uint8_t family_str;
> >  } __attribute__ ((packed));
> >
> > +/* SMBIOS type 2 - Base Board Information */ struct smbios_type_2 {
> > +    struct smbios_structure_header header;
> > +    uint8_t manufacturer_str;
> > +    uint8_t product_name_str;
> > +    uint8_t version_str;
> > +    uint8_t serial_number_str;
> > +} __attribute__ ((packed));
> > +
> >  /* SMBIOS type 3 - System Enclosure */  struct smbios_type_3 {
> >      struct smbios_structure_header header; @@ -173,6 +182,26 @@
> > struct smbios_type_20 {
> >      uint8_t interleaved_data_depth;
> >  } __attribute__ ((packed));
> >
> > +/* SMBIOS type 22 - Portable battery */ struct smbios_type_22 {
> > +    struct smbios_structure_header header;
> > +    uint8_t location_str;
> > +    uint8_t manufacturer_str;
> > +    uint8_t manufacturer_date_str;
> > +    uint8_t serial_number_str;
> > +    uint8_t device_name_str;
> > +    uint8_t device_chemistry;
> > +    uint16_t device_capacity;
> > +    uint16_t device_voltage;
> > +    uint8_t sbds_version_number;
> > +    uint8_t max_error;
> > +    uint16_t sbds_serial_number;
> > +    uint16_t sbds_manufacturer_date;
> > +    uint8_t sbds_device_chemistry;
> > +    uint8_t design_capacity_multiplier;
> > +    uint32_t oem_specific;
> > +} __attribute__ ((packed));
> > +
> >  /* SMBIOS type 32 - System Boot Information */  struct smbios_type_32
> > {
> >      struct smbios_structure_header header; @@ -180,6 +209,24 @@
> > struct smbios_type_32 {
> >      uint8_t boot_status;
> >  } __attribute__ ((packed));
> >
> > +/* SMBIOS type 39 - Power Supply */
> > +struct smbios_type_39 {
> > +    struct smbios_structure_header header;
> > +    uint8_t power_unit_group;
> > +    uint8_t location_str;
> > +    uint8_t device_name_str;
> > +    uint8_t manufacturer_str;
> > +    uint8_t serial_number_str;
> > +    uint8_t asset_tag_number_str;
> > +    uint8_t model_part_number_str;
> > +    uint8_t revision_level_str;
> > +    uint16_t max_capacity;
> > +    uint16_t characteristics;
> > +    uint16_t input_voltage_probe_handle;
> > +    uint16_t cooling_device_handle;
> > +    uint16_t input_current_probe_handle; } __attribute__ ((packed));
> > +
> >  /* SMBIOS type 127 -- End-of-table */  struct smbios_type_127 {
> >      struct smbios_structure_header header;
> >
> >
> >
> >
> >
> >
> >
> > plain text
> > document
> > attachment
> > (ATT00001.txt)
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:29:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:29:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFtJB-0004Tm-Js; Thu, 05 Apr 2012 20:29:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SFtJA-0004Th-C7
	for xen-devel@lists.xensource.com; Thu, 05 Apr 2012 20:29:28 +0000
Received: from [85.158.138.51:13571] by server-9.bemta-3.messagelabs.com id
	16/F1-10923-7A00E7F4; Thu, 05 Apr 2012 20:29:27 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333657763!20968272!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDE4NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11640 invoked from network); 5 Apr 2012 20:29:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 20:29:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,378,1330923600"; d="scan'208";a="189234165"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Apr 2012 16:29:22 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Thu, 5 Apr 2012 16:29:22 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 5 Apr 2012 16:29:41 -0400
Thread-Topic: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
	support
Thread-Index: Ac0TGCIUQTDIgeTuSjWl6s/GwRg9sAAT3lrA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE5446@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
	<1333622260.937.78.camel@zakaz.uk.xensource.com>
In-Reply-To: <1333622260.937.78.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
 support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: Thursday, April 05, 2012 6:38 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 04/07] HVM firmware passthrough: SMBIOS
> support
>
> On Mon, 2012-03-19 at 22:04 +0000, Ross Philipson wrote:
> >                              From:
> > Ross Philipson
> > <Ross.Philipson@citrix.com>
> >                                To:
> > xen-devel@lists.xensource.com
> > <xen-devel@lists.xensource.com>
> >                           Subject:
> > [Xen-devel] [PATCH 04/07] HVM
> > firmware passthrough: SMBIOS
> > support
> >                              Date:
> > Mon, 19 Mar 2012 22:04:09 +0000
> >                        Message-id:
> > <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAAC@FTLPMAILBOX02.citrite.net>
> >
> >
> > Pass through support for the SMBIOS tables including a few new DMTF
> > defines types and support of OEM defined tables. Passed in SMBIOS
> > types override the default internal values. Flags control the new
> > tables so that with default values the SMBIOS tables look exactly as
> > they do before the patches.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> >
> >
> >
> >
> >
> >
> >
> > differences
> > between files
> > attachment
> > (hvm-firmware-passthrough-04.patch)
> >
> > # HG changeset patch
> > # Parent a0d871dadf1d482d77bf57a059a55098e2bfb078
> > Pass through support for the SMBIOS tables including a few new DMTF
> > defines types and support of OEM defined tables. Passed in SMBIOS
> > types override the default internal values. Flags control the new
> > tables so that with default values the SMBIOS tables look exactly as
> > they do before the patches.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> > diff -r a0d871dadf1d tools/firmware/hvmloader/smbios.c
> > --- a/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:45:12 2012 -0400
> > +++ b/tools/firmware/hvmloader/smbios.c Mon Mar 19 16:52:13 2012 -0400
> > @@ -23,8 +23,10 @@
> >  #include <stdint.h>
> >  #include <xen/xen.h>
> >  #include <xen/version.h>
> > +#include <xen/hvm/hvm_defs.h>
> >  #include "smbios_types.h"
> >  #include "util.h"
> > +#include "modules.h"
> >  #include "hypercall.h"
> >
> >  static int
> > @@ -49,6 +51,8 @@ static void *
> >  smbios_type_1_init(void *start, const char *xen_version,
> >                     uint8_t uuid[16]);  static void *
> > +smbios_type_2_init(void *start);
> > +static void *
> >  smbios_type_3_init(void *start);
> >  static void *
> >  smbios_type_4_init(void *start, unsigned int cpu_number, @@ -64,8
> > +68,14 @@ smbios_type_19_init(void *start, uint32_  static void *
> > smbios_type_20_init(void *start, uint32_t memory_size_mb, int
> > instance);  static void *
> > +smbios_type_22_init(void *start);
> > +static void *
> >  smbios_type_32_init(void *start);
> >  static void *
> > +smbios_type_39_init(void *start);
> > +static void *
> > +smbios_type_vendor_oem_init(void *start); static void *
> >  smbios_type_127_init(void *start);
> >
> >  static void
> > @@ -85,6 +95,35 @@ get_cpu_manufacturer(char *buf, int len)
> >          strncpy(buf, "unknown", len);  }
> >
> > +static uint32_t
> > +get_smbios_control_flags(void)
> > +{
> > +    static uint64_t flags;
> > +    static int read = 0;
> > +
> > +    if ( !read )
> > +    {
> > +        flags = strtoll(xenstore_read(HVM_XS_SMBIOS_FLAGS, "0"),
> > NULL, 0);
>
> Rather than encoding these as a bit field, written as ascii into
> xenstore and then parsed back into a number again I think you may as
> well just have a node for each individual flag.

Yes that would be better.

>
> > +        read = 1;
> > +    }
> > +
> > +    return (uint32_t)flags;
> > +}
> > +
> > +static void*
> > +get_smbios_passthrough_table(uint8_t type, uint32_t *length_out) {
> > +    struct hvm_modules_iterator iter;
> > +    uint32_t flags = get_smbios_control_flags();
> > +
> > +    if ( flags & HVM_SMBIOS_DISABLE_PASSTHROUGH )
>
> This check is the same as just not providing the tables?

Yeah I need to rethink the flags in general.

>
> > +        return NULL;
> > +
> > +    init_smbios_module_iterator(&iter, type, 0);
> > +
> > +    return hvm_find_module_entry(&iter, length_out); }
> > +
> >  static int
> >  write_smbios_tables(void *ep, void *start,
> >                      uint32_t vcpus, uint64_t memsize, [...] @@ -338,6
> > +393,18 @@ smbios_type_1_init(void *start, const ch
> >      char uuid_str[37];
> >      struct smbios_type_1 *p = (struct smbios_type_1 *)start;
> >      const char *s;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    ptable = get_smbios_passthrough_table(1, &length);
> > +    if ( (ptable != NULL)&&(length > 0) )
> > +    {
> > +        memcpy(start, ptable, length);
> > +
> > +        /* Fix up, use consistent handles */
> > +        p->header.handle = 0x100;
> > +        return (start + length);
> > +    }
>
> This seems like a pretty common pattern, could it be pulled up into the
> caller of all these init functions?

I can try to make some of it common.

>
> I know it's a pre-existing problem but perhaps giving the handle numbers
> #defined names would make things a bit more obvious. For the OEM tables
> and the potential for clashes (which you commented on in that function)
> at least then there would be a sort of index of the ones which are used.
>
> I suppose you could also then push responsibility for maintaining this
> consistency up to whoever was providing the table and if they wanted
> they could use there own numbering and ensure consistency across the
> board themselves.

Yes I really like that idea of defining the handles we use. I will make things much clearer.

>
> >      memset(p, 0, sizeof(*p));
> >
> > @@ -380,12 +447,90 @@ smbios_type_1_init(void *start, const ch
> >      return start+1;
> >  }
> >
> > +/* Type 2 -- System Board */
> > +static void *
> > +smbios_type_2_init(void *start)
> > +{
> > +    struct smbios_type_2 *p = (struct smbios_type_2 *)start;
> > +    uint8_t *bptr;
> > +    const char *s;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( (get_smbios_control_flags() &
> > HVM_SMBIOS_INCLUDE_SYSTEM_BOARD) == 0 )
>
> Is there any reason you wouldn't want this table now that you've added
> it?

My thinking was that by default if you passed nothing in and did not set any flags it would be exactly the same as before I started.

>
> > +        return start;
> > +
> > +    ptable = get_smbios_passthrough_table(2, &length);
> > +    if ( (ptable != NULL)&&(length > 0) )
> > +    {
> > +        memcpy(start, ptable, length);
> > +
> > +        /* Fix up, use consistent handles, set chassis handle */
> > +        p->header.handle = 0x200;
> > +
> > +        if ( p->header.length >= 13 )
> > +        {
> > +            bptr = ((uint8_t*)start) + 11;
> > +            if ( *((uint16_t*)bptr) != 0 )
> > +                *((uint16_t*)bptr) = 0x300; /* current chassis handle
>
> This is to match the handle of the type 3 table?
>
> I don't see a corresponding thing in the constructed version of this
> table below, is that normal?

So per the spec, the table can vary in size. The default one is the minimum but if the passed in one contains the chassis handle field, it should match the actual chassis table's handle. There is a bug here though; it should be:
 if ( p->header.length > 13 )

>
> >  */
> > +        }
> > +
> > +        return (start + length);
> > +    }
> > +
> > +    memset(p, 0, sizeof(*p));
> > +
> > +    p->header.type = 2;
> > +    p->header.length = sizeof(struct smbios_type_2);
> > +    p->header.handle = 0x200;
> > +
> > +    p->manufacturer_str = 1;
> > +    p->product_name_str = 2;
> > +    p->version_str = 0;
> > +    p->serial_number_str = 0;
> > +
> > +    start += sizeof(struct smbios_type_2);
> > +
> > +    s = xenstore_read("bios-strings/board-manufacturer", "Xen");
> > +    strcpy((char *)start, s);
> > +    start += strlen(s) + 1;
> > +
> > +    s = xenstore_read("bios-strings/board-product-name", "HVM domU");
> > +    strcpy((char *)start, s);
> > +    start += strlen(s) + 1;
> > +
> > +    /* no internal defaults for this if the value is not set */
> > +    s = xenstore_read("bios-strings/board-serial-number", NULL);
> > +    if ( (s != NULL)&&(*s != '\0') )
> > +    {
> > +        strcpy((char *)start, s);
> > +        start += strlen(s) + 1;
> > +        p->serial_number_str = 3;
> > +    }
> > +
> > +    *((uint8_t *)start) = 0;
> > +    return start+1;
> > +}
>
> [...]
> > @@ -403,9 +548,20 @@ smbios_type_3_init(void *start)
> >      p->security_status = 0x02; /* unknown */
> >
> >      start += sizeof(struct smbios_type_3);
> > -
> > -    strcpy((char *)start, "Xen");
> > -    start += strlen("Xen") + 1;
> > +
> > +    s = xenstore_read("bios-strings/enclosure-manufacturer", "Xen");
> > +    strcpy((char *)start, s);
> > +    start += strlen(s) + 1;
> > +
> > +    /* no internal defaults for this if the value is not set */
> > +    s = xenstore_read("bios-strings/enclosure-serial-number", NULL);
> > +    if ( (s != NULL)&&(*s != '\0') )
> > +    {
> > +        strcpy((char *)start, s);
> > +        start += strlen(s) + 1;
> > +        p->serial_number_str = 2;
> > +    }
> > +
> >      *((uint8_t *)start) = 0;
> >      return start+1;
> >  }
> [...]
> > @@ -609,6 +777,66 @@ smbios_type_20_init(void *start, uint32_
> >      return start+2;
> >  }
> >
> > +/* Type 22 -- Portable Battery */
> > +static void *
> > +smbios_type_22_init(void *start)
> > +{
> > +    struct smbios_type_22 *p = (struct smbios_type_22 *)start;
> > +    static const char *smbios_release_date = __SMBIOS_DATE__;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( (get_smbios_control_flags() &
> > HVM_SMBIOS_INCLUDE_PORTABLE_BATTERY)
> > +          == 0 )
> > +        return start;
>
> Could an argument be made here that either you want to pass through some
> underlying table or you don't want the table at all? Or is there a use
> case for having hvmloader fake one up?

TBH I am not 100% sure about this one. The faked up table was introduced when we started surfacing ACPI battery devices in the guests. There are no comments or records as to what the tie might be. This would need some testing with HVM guests.

>
> > +
> > +    ptable = get_smbios_passthrough_table(22, &length);
> > +    if ( (ptable != NULL)&&(length > 0) )
> > +    {
> > +        memcpy(start, ptable, length);
> > +
> > +        /* Fix up, use consistent handles */
> > +        p->header.handle = 0x1600;
> > +        return (start + length);
> > +    }
> > +
> > +    memset(p, 0, sizeof(*p));
> > +
> > +    p->header.type = 22;
> > +    p->header.length = sizeof(struct smbios_type_22);
> > +    p->header.handle = 0x1600;
> > +
> > +    p->location_str = 1;
> > +    p->manufacturer_str = 2;
> > +    p->manufacturer_date_str = 3;
> > +    p->serial_number_str = 0;
> > +    p->device_name_str = 4;
> > +    p->device_chemistry = 0x2; /* Unknown */
> > +    p->device_capacity = 0; /* Unknown */
> > +    p->device_voltage = 0; /* Unknown */
> > +    p->sbds_version_number = 0;
> > +    p->max_error = 0xff; /* Unknown */
> > +    p->sbds_serial_number = 0;
> > +    p->sbds_manufacturer_date = 0;
> > +    p->sbds_device_chemistry = 0;
> > +    p->design_capacity_multiplier = 0;
> > +    p->oem_specific = 0;
> > +
> > +    start += sizeof(struct smbios_type_22);
> > +
> > +    strcpy((char *)start, "Primary");
> > +    start += strlen("Primary") + 1;
> > +    strcpy((char *)start, "Xen");
> > +    start += strlen("Xen") + 1;
> > +    strcpy((char *)start, smbios_release_date);
> > +    start += strlen(smbios_release_date) + 1;
> > +    strcpy((char *)start, "XEN-VBAT");
> > +    start += strlen("XEN-VBAT") + 1;
> > +
> > +    *((uint8_t *)start) = 0;
> > +    return start+1;
> > +}
> > +
> >  /* Type 32 -- System Boot Information */  static void *
> > smbios_type_32_init(void *start) @@ -628,6 +856,71 @@
> > smbios_type_32_init(void *start)
> >      return start+2;
> >  }
> >
> > +/* Type 39 -- Power Supply */
> > +static void *
> > +smbios_type_39_init(void *start)
> > +{
> > +    struct smbios_type_39 *p = (struct smbios_type_39 *)start;
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( (get_smbios_control_flags() &
> > HVM_SMBIOS_INCLUDE_POWER_SUPPLY)
> > +          == 0 )
> > +        return start;
> > +
> > +    /* No default values - only present if the table is passed in */
> > +    ptable = get_smbios_passthrough_table(39, &length);
> > +    if ( (ptable == NULL)||(length == 0) )
> > +        return start;
> > +
> > +    memcpy(start, ptable, length);
> > +
> > +    /* Fix up, use consistent handles */
> > +    p->header.handle = 0x2700;
> > +
> > +    /* These devices are not present */
> > +    p->input_voltage_probe_handle = 0xFFFF;
> > +    p->cooling_device_handle = 0xFFFF;
> > +    p->input_current_probe_handle = 0xFFFF;
>
> I think responsibility for setting these up correctly ought to lie with
> whoever passed the table in.

Agreed

>
> > +
> > +    return (start + length);
> > +}
> > +
> > +static void *
> > +smbios_type_vendor_oem_init(void *start) {
> > +    struct hvm_modules_iterator iter;
> > +    uint32_t flags = get_smbios_control_flags();
> > +    void *ptable;
> > +    uint32_t length;
> > +
> > +    if ( ((flags & HVM_SMBIOS_INCLUDE_VENDOR_OEM) == 0)||
> > +         (flags & HVM_SMBIOS_DISABLE_PASSTHROUGH) )
> > +        return start;
> > +
> > +    /* Looking for any and all vendor/OEM defined tables passed in.
> > */
> > +    init_smbios_module_iterator(&iter, 128, 255);
> > +
> > +    do
> > +    {
> > +        ptable = hvm_find_module_entry(&iter, &length);
> > +        if ( (ptable != NULL)&&(length > 0) )
> > +        {
> > +            /*
> > +             * Vendor/OEM table, copy it in. Note the handle values
> > cannot
> > +             * be changed since it is unknown what is in each of
> > these tables
> > +             * but they could contain handle references to other
> > tables. This
> > +             * means a slight risk of collision with the tables above
> > but that
> > +             * would have to be dealt with on a case by case basis.
> > +             */
> > +            memcpy(start, ptable, length);
> > +            start += length;
>
> Do you also need to track the size of the largest table as well as the
> total number, for the purposes of filling in the fields in the entry
> point?

No. The start += length and the do_struct() macro do that work.

>
> > +        }
> > +    } while ( ptable != NULL );
> > +
> > +    return start;
> > +}
> > +
> >  /* Type 127 -- End of Table */
> >  static void *
> >  smbios_type_127_init(void *start)
> > diff -r a0d871dadf1d tools/firmware/hvmloader/smbios_types.h
> > --- a/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:45:12
> > 2012 -0400
> > +++ b/tools/firmware/hvmloader/smbios_types.h   Mon Mar 19 16:52:13
> > 2012 -0400
> > @@ -84,6 +84,15 @@ struct smbios_type_1 {
> >      uint8_t family_str;
> >  } __attribute__ ((packed));
> >
> > +/* SMBIOS type 2 - Base Board Information */ struct smbios_type_2 {
> > +    struct smbios_structure_header header;
> > +    uint8_t manufacturer_str;
> > +    uint8_t product_name_str;
> > +    uint8_t version_str;
> > +    uint8_t serial_number_str;
> > +} __attribute__ ((packed));
> > +
> >  /* SMBIOS type 3 - System Enclosure */  struct smbios_type_3 {
> >      struct smbios_structure_header header; @@ -173,6 +182,26 @@
> > struct smbios_type_20 {
> >      uint8_t interleaved_data_depth;
> >  } __attribute__ ((packed));
> >
> > +/* SMBIOS type 22 - Portable battery */ struct smbios_type_22 {
> > +    struct smbios_structure_header header;
> > +    uint8_t location_str;
> > +    uint8_t manufacturer_str;
> > +    uint8_t manufacturer_date_str;
> > +    uint8_t serial_number_str;
> > +    uint8_t device_name_str;
> > +    uint8_t device_chemistry;
> > +    uint16_t device_capacity;
> > +    uint16_t device_voltage;
> > +    uint8_t sbds_version_number;
> > +    uint8_t max_error;
> > +    uint16_t sbds_serial_number;
> > +    uint16_t sbds_manufacturer_date;
> > +    uint8_t sbds_device_chemistry;
> > +    uint8_t design_capacity_multiplier;
> > +    uint32_t oem_specific;
> > +} __attribute__ ((packed));
> > +
> >  /* SMBIOS type 32 - System Boot Information */  struct smbios_type_32
> > {
> >      struct smbios_structure_header header; @@ -180,6 +209,24 @@
> > struct smbios_type_32 {
> >      uint8_t boot_status;
> >  } __attribute__ ((packed));
> >
> > +/* SMBIOS type 39 - Power Supply */
> > +struct smbios_type_39 {
> > +    struct smbios_structure_header header;
> > +    uint8_t power_unit_group;
> > +    uint8_t location_str;
> > +    uint8_t device_name_str;
> > +    uint8_t manufacturer_str;
> > +    uint8_t serial_number_str;
> > +    uint8_t asset_tag_number_str;
> > +    uint8_t model_part_number_str;
> > +    uint8_t revision_level_str;
> > +    uint16_t max_capacity;
> > +    uint16_t characteristics;
> > +    uint16_t input_voltage_probe_handle;
> > +    uint16_t cooling_device_handle;
> > +    uint16_t input_current_probe_handle; } __attribute__ ((packed));
> > +
> >  /* SMBIOS type 127 -- End-of-table */  struct smbios_type_127 {
> >      struct smbios_structure_header header;
> >
> >
> >
> >
> >
> >
> >
> > plain text
> > document
> > attachment
> > (ATT00001.txt)
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:36:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFtPC-0004eQ-Kv; Thu, 05 Apr 2012 20:35:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SFtPA-0004eL-Sa
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:35:41 +0000
Received: from [193.109.254.147:53424] by server-6.bemta-14.messagelabs.com id
	68/B0-02047-C120E7F4; Thu, 05 Apr 2012 20:35:40 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333658138!3449172!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20421 invoked from network); 5 Apr 2012 20:35:39 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Apr 2012 20:35:39 -0000
Received: from mail178-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 20:35:37 +0000
Received: from mail178-va3 (localhost [127.0.0.1])	by
	mail178-va3-R.bigfish.com (Postfix) with ESMTP id D54612C0124;
	Thu,  5 Apr 2012 20:35:36 +0000 (UTC)
X-SpamScore: -21
X-BigFish: VPS-21(zzbb2dI9371I146fKc85dh1432N98dK14ffOzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail178-va3 (localhost.localdomain [127.0.0.1]) by mail178-va3
	(MessageSwitch) id 1333658135778127_9193;
	Thu,  5 Apr 2012 20:35:35 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.251])	by
	mail178-va3.bigfish.com (Postfix) with ESMTP id B06C8320052;
	Thu,  5 Apr 2012 20:35:35 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 20:35:34 +0000
X-WSS-ID: 0M20X77-01-8EN-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B5751028100;	Thu,  5 Apr 2012 15:35:31 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Apr 2012 15:35:47 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	15:35:31 -0500
Message-ID: <4F7E004D.5090908@amd.com>
Date: Thu, 5 Apr 2012 15:27:57 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which 
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz 
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:36:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFtPC-0004eQ-Kv; Thu, 05 Apr 2012 20:35:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SFtPA-0004eL-Sa
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:35:41 +0000
Received: from [193.109.254.147:53424] by server-6.bemta-14.messagelabs.com id
	68/B0-02047-C120E7F4; Thu, 05 Apr 2012 20:35:40 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333658138!3449172!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20421 invoked from network); 5 Apr 2012 20:35:39 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Apr 2012 20:35:39 -0000
Received: from mail178-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 20:35:37 +0000
Received: from mail178-va3 (localhost [127.0.0.1])	by
	mail178-va3-R.bigfish.com (Postfix) with ESMTP id D54612C0124;
	Thu,  5 Apr 2012 20:35:36 +0000 (UTC)
X-SpamScore: -21
X-BigFish: VPS-21(zzbb2dI9371I146fKc85dh1432N98dK14ffOzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail178-va3 (localhost.localdomain [127.0.0.1]) by mail178-va3
	(MessageSwitch) id 1333658135778127_9193;
	Thu,  5 Apr 2012 20:35:35 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.251])	by
	mail178-va3.bigfish.com (Postfix) with ESMTP id B06C8320052;
	Thu,  5 Apr 2012 20:35:35 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Apr 2012 20:35:34 +0000
X-WSS-ID: 0M20X77-01-8EN-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B5751028100;	Thu,  5 Apr 2012 15:35:31 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Apr 2012 15:35:47 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Apr 2012
	15:35:31 -0500
Message-ID: <4F7E004D.5090908@amd.com>
Date: Thu, 5 Apr 2012 15:27:57 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which 
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz 
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:46:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFtZI-0004r5-Qy; Thu, 05 Apr 2012 20:46:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFtZG-0004r0-T5
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:46:07 +0000
Received: from [193.109.254.147:7990] by server-6.bemta-14.messagelabs.com id
	A8/53-02047-E840E7F4; Thu, 05 Apr 2012 20:46:06 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333658765!3433921!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNzY1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32679 invoked from network); 5 Apr 2012 20:46:05 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 20:46:05 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFtZE-0006DB-G3; Thu, 05 Apr 2012 21:46:05 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Thu, 5 Apr 2012 21:45:35 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Thu, 5 Apr 2012 21:43:57 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0Ta7H6QRNJd0RcRIyWhO5/9JmtjwAASDR7
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>
In-Reply-To: <4F7E004D.5090908@amd.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 20:46:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 20:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFtZI-0004r5-Qy; Thu, 05 Apr 2012 20:46:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFtZG-0004r0-T5
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 20:46:07 +0000
Received: from [193.109.254.147:7990] by server-6.bemta-14.messagelabs.com id
	A8/53-02047-E840E7F4; Thu, 05 Apr 2012 20:46:06 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333658765!3433921!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNzY1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32679 invoked from network); 5 Apr 2012 20:46:05 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Apr 2012 20:46:05 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SFtZE-0006DB-G3; Thu, 05 Apr 2012 21:46:05 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Thu, 5 Apr 2012 21:45:35 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Thu, 5 Apr 2012 21:43:57 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0Ta7H6QRNJd0RcRIyWhO5/9JmtjwAASDR7
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>
In-Reply-To: <4F7E004D.5090908@amd.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 22:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 22:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFvBz-0005Xl-6D; Thu, 05 Apr 2012 22:30:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SFvBx-0005XY-Nm
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 22:30:09 +0000
Received: from [193.109.254.147:34013] by server-11.bemta-14.messagelabs.com
	id FA/0B-05858-0FC1E7F4; Thu, 05 Apr 2012 22:30:08 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333665005!3455826!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17468 invoked from network); 5 Apr 2012 22:30:07 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 22:30:07 -0000
Received: by qadb15 with SMTP id b15so83778qad.16
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 15:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=vQY+VhOHXsM26KR90fTr/EBmsu66EGWTkMouS9YpF3M=;
	b=DBN+494v4XFFzNjXpiM8kXzXIwRpx+YmEUMeN95tShoJkrI8tayCPXNrXAkW9qxdKK
	ppvtAP+jyC5+VXRo/9U6m869ewo+veBHXLOXaTeSXixvxkVlJMEdthKRXpggyiq5VPDX
	nmTbi9HRxcByGVOPJpSNXVrt+wXxb3Uva/hCYi4oFmUM/grUPK7eHGOCpvEtlcLBjaCF
	qUa0dz7Zz+K3d32hm08g8+lD/f12lY8zAv+6WWDgwH+XYYRL4mIybpQ/m3IL0FAu3xFX
	1FqNMePTnp5vn3crIWP4Tk2fPY3xpy6+CiQuP1jUjjCWO98z0V2s6R7jWXE99fPxRuzz
	EVow==
MIME-Version: 1.0
Received: by 10.229.106.193 with SMTP id y1mr1827360qco.73.1333665005214; Thu,
	05 Apr 2012 15:30:05 -0700 (PDT)
Received: by 10.229.2.5 with HTTP; Thu, 5 Apr 2012 15:30:05 -0700 (PDT)
Date: Fri, 6 Apr 2012 00:30:05 +0200
X-Google-Sender-Auth: VWAqndvCCSLyojrKQ3jfu83MDCk
Message-ID: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1747988716038587086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1747988716038587086==
Content-Type: multipart/alternative; boundary=0023544706b0e29be904bcf61473

--0023544706b0e29be904bcf61473
Content-Type: text/plain; charset=ISO-8859-1

Hi there Xen community,

I am trying to benchmark and compare I/O in Xen/domU to native performance.

In order to do this I started trying to benchmark writes so as to avoid
caching effects that surely turn up when performing reads due to the page
cache et al.
However, I have quickly run into a problem: Xen domU reports that a 128MB
file is written at close to 300MB/s, while the disk's performance peaks at
about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with no
hypervisor).
Please note that I fsync() after all writes in hopes to avoid the effect of
write buffers. I have tried with O_SYNC as well, observing a similar
outcome.
I can confirm this writing a simple program, and verified exactly same
results running bonnie++ with the fsync() option turned on.

I am surprised to see writes reaching a throughput as high as 300MB/s, as
the disk surely isn't physically capable of reaching that bandwidth,
meaning that writes are not being really synced to disk.

Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
fdatasync, O_SYNC, etc..?
How would I proceed to measure and compare real read/write speeds on a Xen
domU ?

My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
could not get the tapdisk driver to work properly, I tried with vanilla 3.2
and 3.0.0 ubuntu kernels)
Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 kernel

Thank you in advance,

Pablo

--0023544706b0e29be904bcf61473
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi there Xen community,<div><br></div><div>I am trying to benchmark and com=
pare I/O in Xen/domU to native performance.</div><div><br></div><div>In ord=
er to do this I started trying to benchmark writes so as to avoid caching e=
ffects that surely turn up when performing reads due to the page cache et a=
l.</div>

<div>However, I have quickly run into a problem: Xen domU reports that a 12=
8MB file is written at close to 300MB/s, while the disk&#39;s performance p=
eaks at about 80MB/s (I observed this on a dom0 and on a bare-metal kernel =
with no hypervisor).</div>

<div>Please note that I fsync() after all writes in hopes to avoid the effe=
ct of write buffers.=A0I have tried with O_SYNC as well, observing a simila=
r outcome.</div><div>I can confirm this writing a simple program, and verif=
ied exactly same results running bonnie++ with the fsync() option turned on=
.</div>
<div><br></div><div>I am surprised to see writes reaching a throughput as h=
igh as 300MB/s, as the disk surely isn&#39;t physically capable of reaching=
 that bandwidth, meaning that writes are not being really synced to disk.=
=A0</div>
<div><br></div><div>Is this a bug in Xen, or is there a way to make Xen not=
 ignore fsync, fdatasync, O_SYNC, etc..?=A0</div><div>How would I proceed t=
o measure and compare real read/write speeds on a Xen domU ?<br>
</div><div><br></div><div>My disk drivers are specified with &quot;file:/pa=
th/to/image.img,xvda,1,w&quot; (I could not get the tapdisk driver to work =
properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)</div><div>
Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)</div><div>=
For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 kerne=
l</div><div><br></div><div>Thank you in advance,</div><div><br></div><div>
Pablo</div>

--0023544706b0e29be904bcf61473--


--===============1747988716038587086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1747988716038587086==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 22:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 22:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFvBz-0005Xl-6D; Thu, 05 Apr 2012 22:30:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SFvBx-0005XY-Nm
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 22:30:09 +0000
Received: from [193.109.254.147:34013] by server-11.bemta-14.messagelabs.com
	id FA/0B-05858-0FC1E7F4; Thu, 05 Apr 2012 22:30:08 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333665005!3455826!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17468 invoked from network); 5 Apr 2012 22:30:07 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 22:30:07 -0000
Received: by qadb15 with SMTP id b15so83778qad.16
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 15:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=vQY+VhOHXsM26KR90fTr/EBmsu66EGWTkMouS9YpF3M=;
	b=DBN+494v4XFFzNjXpiM8kXzXIwRpx+YmEUMeN95tShoJkrI8tayCPXNrXAkW9qxdKK
	ppvtAP+jyC5+VXRo/9U6m869ewo+veBHXLOXaTeSXixvxkVlJMEdthKRXpggyiq5VPDX
	nmTbi9HRxcByGVOPJpSNXVrt+wXxb3Uva/hCYi4oFmUM/grUPK7eHGOCpvEtlcLBjaCF
	qUa0dz7Zz+K3d32hm08g8+lD/f12lY8zAv+6WWDgwH+XYYRL4mIybpQ/m3IL0FAu3xFX
	1FqNMePTnp5vn3crIWP4Tk2fPY3xpy6+CiQuP1jUjjCWO98z0V2s6R7jWXE99fPxRuzz
	EVow==
MIME-Version: 1.0
Received: by 10.229.106.193 with SMTP id y1mr1827360qco.73.1333665005214; Thu,
	05 Apr 2012 15:30:05 -0700 (PDT)
Received: by 10.229.2.5 with HTTP; Thu, 5 Apr 2012 15:30:05 -0700 (PDT)
Date: Fri, 6 Apr 2012 00:30:05 +0200
X-Google-Sender-Auth: VWAqndvCCSLyojrKQ3jfu83MDCk
Message-ID: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1747988716038587086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1747988716038587086==
Content-Type: multipart/alternative; boundary=0023544706b0e29be904bcf61473

--0023544706b0e29be904bcf61473
Content-Type: text/plain; charset=ISO-8859-1

Hi there Xen community,

I am trying to benchmark and compare I/O in Xen/domU to native performance.

In order to do this I started trying to benchmark writes so as to avoid
caching effects that surely turn up when performing reads due to the page
cache et al.
However, I have quickly run into a problem: Xen domU reports that a 128MB
file is written at close to 300MB/s, while the disk's performance peaks at
about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with no
hypervisor).
Please note that I fsync() after all writes in hopes to avoid the effect of
write buffers. I have tried with O_SYNC as well, observing a similar
outcome.
I can confirm this writing a simple program, and verified exactly same
results running bonnie++ with the fsync() option turned on.

I am surprised to see writes reaching a throughput as high as 300MB/s, as
the disk surely isn't physically capable of reaching that bandwidth,
meaning that writes are not being really synced to disk.

Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
fdatasync, O_SYNC, etc..?
How would I proceed to measure and compare real read/write speeds on a Xen
domU ?

My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
could not get the tapdisk driver to work properly, I tried with vanilla 3.2
and 3.0.0 ubuntu kernels)
Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 kernel

Thank you in advance,

Pablo

--0023544706b0e29be904bcf61473
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi there Xen community,<div><br></div><div>I am trying to benchmark and com=
pare I/O in Xen/domU to native performance.</div><div><br></div><div>In ord=
er to do this I started trying to benchmark writes so as to avoid caching e=
ffects that surely turn up when performing reads due to the page cache et a=
l.</div>

<div>However, I have quickly run into a problem: Xen domU reports that a 12=
8MB file is written at close to 300MB/s, while the disk&#39;s performance p=
eaks at about 80MB/s (I observed this on a dom0 and on a bare-metal kernel =
with no hypervisor).</div>

<div>Please note that I fsync() after all writes in hopes to avoid the effe=
ct of write buffers.=A0I have tried with O_SYNC as well, observing a simila=
r outcome.</div><div>I can confirm this writing a simple program, and verif=
ied exactly same results running bonnie++ with the fsync() option turned on=
.</div>
<div><br></div><div>I am surprised to see writes reaching a throughput as h=
igh as 300MB/s, as the disk surely isn&#39;t physically capable of reaching=
 that bandwidth, meaning that writes are not being really synced to disk.=
=A0</div>
<div><br></div><div>Is this a bug in Xen, or is there a way to make Xen not=
 ignore fsync, fdatasync, O_SYNC, etc..?=A0</div><div>How would I proceed t=
o measure and compare real read/write speeds on a Xen domU ?<br>
</div><div><br></div><div>My disk drivers are specified with &quot;file:/pa=
th/to/image.img,xvda,1,w&quot; (I could not get the tapdisk driver to work =
properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)</div><div>
Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)</div><div>=
For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 kerne=
l</div><div><br></div><div>Thank you in advance,</div><div><br></div><div>
Pablo</div>

--0023544706b0e29be904bcf61473--


--===============1747988716038587086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1747988716038587086==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 23:04:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 23:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFvix-0005qz-VF; Thu, 05 Apr 2012 23:04:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SFvix-0005qu-59
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 23:04:15 +0000
Received: from [85.158.143.99:41229] by server-1.bemta-4.messagelabs.com id
	D2/F6-20925-EE42E7F4; Thu, 05 Apr 2012 23:04:14 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333667052!17315904!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26655 invoked from network); 5 Apr 2012 23:04:13 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 23:04:13 -0000
Received: by obbup19 with SMTP id up19so1291018obb.32
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 16:04:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=98W95zy8rQEFqXIQ+A29caGkLaGqHUtKOKUfySHcCJk=;
	b=AfMcD1dIDExO6Ww0WyJs/lDMis7HbeyoH5+SHQEtEcyEzSGQvcBqMWiSRCvxdmRMiu
	S3/pvhJ7tLint0OCiceOqQM3wKLF7/2DDpMVLnMBxvx3mcR/oRaMZlppOXDiWpXyY2oG
	RupL6EOV/jQm+X1X3zetojnkFZBDI6uJNVdzQ5lb7VlAtSB1hPd6e8ZZ87wkpaQ7dBwg
	0Vtn/pks3wr/hwm6RpiVvtBvdZABEQostu8YsJ9djqZPTpGT6AN3//Sf7s8Q5v4K8zij
	TC2mh5aObKib310mlvZNB8vdmaSw37HnR5JK8EdhvSIm+B7rGnhYXP2XoufUjR9kTrgP
	522g==
MIME-Version: 1.0
Received: by 10.60.4.1 with SMTP id g1mr6338242oeg.55.1333667051825; Thu, 05
	Apr 2012 16:04:11 -0700 (PDT)
Received: by 10.182.92.77 with HTTP; Thu, 5 Apr 2012 16:04:11 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
In-Reply-To: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
Date: Fri, 6 Apr 2012 09:04:11 +1000
Message-ID: <CAOzFzEjkpaGSHfv_ouTFs6a1FQDybpvFrVMmB7GZRYrDYvDnTw@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
X-Gm-Message-State: ALoCoQnMkGD4DP2rwIll6SZoQb0NVkpP5L6HVVGQ6BZFlMMgXHnJcJVsUM1YNCZjWq/TZunU++Rg
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6 April 2012 08:30, Pablo Llopis <pllopis@arcos.inf.uc3m.es> wrote:
> Hi there Xen community,
>
> I am trying to benchmark and compare I/O in Xen/domU to native performanc=
e.
>
> In order to do this I started trying to benchmark writes so as to avoid
> caching effects that surely turn up when performing reads due to the page
> cache et al.
> However, I have quickly run into a problem: Xen domU reports that a 128MB
> file is written at close to 300MB/s, while the disk's performance peaks at
> about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with no
> hypervisor).
> Please note that I fsync() after all writes in hopes to avoid the effect =
of
> write buffers.=A0I have tried with O_SYNC as well, observing a similar
> outcome.
> I can confirm this writing a simple program, and verified exactly same
> results running bonnie++ with the fsync() option turned on.
>
> I am surprised to see writes reaching a throughput as high as 300MB/s, as
> the disk surely isn't physically capable of reaching that bandwidth, mean=
ing
> that writes are not being really synced to disk.
>
> Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
> fdatasync, O_SYNC, etc..?
> How would I proceed to measure and compare real read/write speeds on a Xen
> domU ?
>
> My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
> could not get the tapdisk driver to work properly, I tried with vanilla 3=
.2
> and 3.0.0 ubuntu kernels)

To measure real disk speed I recommend using the phy:/ handler with a
block device.
You can use a partition, an LVM logical volume or an entire disk.
Use of files on filesytems for domain block devices is discouraged and
should be avoided at all costs.

For testing IO throughput actively I wouldn't use bonnie++ as it is a
filesystem level tool and not overly accurate at that.
Use the Flexible IO Tester (aka fio) by Jens Axobe.
You can install it on Ubuntu with:
apt-get install fio

I would also recommend using the libaio engine with fio if you are
using an SSD and need to drive the queue depth up to get a better idea
of the IOPs the device can deliver.
You will need to install libaio with:
apt-get install libaio

> Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 ker=
nel
>
> Thank you in advance,
>
> Pablo
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 23:04:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 23:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFvix-0005qz-VF; Thu, 05 Apr 2012 23:04:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1SFvix-0005qu-59
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 23:04:15 +0000
Received: from [85.158.143.99:41229] by server-1.bemta-4.messagelabs.com id
	D2/F6-20925-EE42E7F4; Thu, 05 Apr 2012 23:04:14 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333667052!17315904!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26655 invoked from network); 5 Apr 2012 23:04:13 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 23:04:13 -0000
Received: by obbup19 with SMTP id up19so1291018obb.32
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 16:04:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=98W95zy8rQEFqXIQ+A29caGkLaGqHUtKOKUfySHcCJk=;
	b=AfMcD1dIDExO6Ww0WyJs/lDMis7HbeyoH5+SHQEtEcyEzSGQvcBqMWiSRCvxdmRMiu
	S3/pvhJ7tLint0OCiceOqQM3wKLF7/2DDpMVLnMBxvx3mcR/oRaMZlppOXDiWpXyY2oG
	RupL6EOV/jQm+X1X3zetojnkFZBDI6uJNVdzQ5lb7VlAtSB1hPd6e8ZZ87wkpaQ7dBwg
	0Vtn/pks3wr/hwm6RpiVvtBvdZABEQostu8YsJ9djqZPTpGT6AN3//Sf7s8Q5v4K8zij
	TC2mh5aObKib310mlvZNB8vdmaSw37HnR5JK8EdhvSIm+B7rGnhYXP2XoufUjR9kTrgP
	522g==
MIME-Version: 1.0
Received: by 10.60.4.1 with SMTP id g1mr6338242oeg.55.1333667051825; Thu, 05
	Apr 2012 16:04:11 -0700 (PDT)
Received: by 10.182.92.77 with HTTP; Thu, 5 Apr 2012 16:04:11 -0700 (PDT)
X-Originating-IP: [59.167.234.130]
In-Reply-To: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
Date: Fri, 6 Apr 2012 09:04:11 +1000
Message-ID: <CAOzFzEjkpaGSHfv_ouTFs6a1FQDybpvFrVMmB7GZRYrDYvDnTw@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
X-Gm-Message-State: ALoCoQnMkGD4DP2rwIll6SZoQb0NVkpP5L6HVVGQ6BZFlMMgXHnJcJVsUM1YNCZjWq/TZunU++Rg
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6 April 2012 08:30, Pablo Llopis <pllopis@arcos.inf.uc3m.es> wrote:
> Hi there Xen community,
>
> I am trying to benchmark and compare I/O in Xen/domU to native performanc=
e.
>
> In order to do this I started trying to benchmark writes so as to avoid
> caching effects that surely turn up when performing reads due to the page
> cache et al.
> However, I have quickly run into a problem: Xen domU reports that a 128MB
> file is written at close to 300MB/s, while the disk's performance peaks at
> about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with no
> hypervisor).
> Please note that I fsync() after all writes in hopes to avoid the effect =
of
> write buffers.=A0I have tried with O_SYNC as well, observing a similar
> outcome.
> I can confirm this writing a simple program, and verified exactly same
> results running bonnie++ with the fsync() option turned on.
>
> I am surprised to see writes reaching a throughput as high as 300MB/s, as
> the disk surely isn't physically capable of reaching that bandwidth, mean=
ing
> that writes are not being really synced to disk.
>
> Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
> fdatasync, O_SYNC, etc..?
> How would I proceed to measure and compare real read/write speeds on a Xen
> domU ?
>
> My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
> could not get the tapdisk driver to work properly, I tried with vanilla 3=
.2
> and 3.0.0 ubuntu kernels)

To measure real disk speed I recommend using the phy:/ handler with a
block device.
You can use a partition, an LVM logical volume or an entire disk.
Use of files on filesytems for domain block devices is discouraged and
should be avoided at all costs.

For testing IO throughput actively I wouldn't use bonnie++ as it is a
filesystem level tool and not overly accurate at that.
Use the Flexible IO Tester (aka fio) by Jens Axobe.
You can install it on Ubuntu with:
apt-get install fio

I would also recommend using the libaio engine with fio if you are
using an SSD and need to drive the queue depth up to get a better idea
of the IOPs the device can deliver.
You will need to install libaio with:
apt-get install libaio

> Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 ker=
nel
>
> Thank you in advance,
>
> Pablo
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

Joseph.

-- =

Founder | Director | VP Research
Orion Virtualisation Solutions=A0|=A0www.orionvm.com.au=A0| Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 05 23:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 23:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFwS4-00066v-Ke; Thu, 05 Apr 2012 23:50:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SFwS2-00066q-Gr
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 23:50:50 +0000
Received: from [85.158.138.51:2416] by server-4.bemta-3.messagelabs.com id
	9E/23-16467-9DF2E7F4; Thu, 05 Apr 2012 23:50:49 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333669846!21050843!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29441 invoked from network); 5 Apr 2012 23:50:47 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 23:50:47 -0000
Received: by qabg40 with SMTP id g40so109092qab.11
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 16:50:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=mqcef3g13Jfnjly9rmI4Fc4ZKTrvYq+Ttbt6ZqlVdOM=;
	b=1IoWDOrOScBtlOHndHVY/TPjQsyTrqXVe6qcW+cqHLoDYEzFfUzaphLW/ML/uEdd1T
	XRqhTSj8K55xkTGq3rANzfAjgbwXTkEkaFa01opx22l7USF+TuXFU/MqC4B7mLAfrXRz
	Bf7rpks2rb0GJKKvChQ1G4YLLn4CFCntxRku+ppqofcWeEeHvZkILihweTm0y2xPGyVx
	5Cb9ZXGP+ZwUYvNnYiwY+DiOH2pFX0EioccWKV8PN9bCsJJl1E6Lm8AvHnhwwtTFjm90
	tphlO2twd2tNG/2lq/28vFB9uVeSBQiI9CH24Rb+Sx8g4htTvXrCt68BnVCURtf9BGxD
	KOpw==
MIME-Version: 1.0
Received: by 10.224.211.9 with SMTP id gm9mr6693552qab.78.1333669845689; Thu,
	05 Apr 2012 16:50:45 -0700 (PDT)
Received: by 10.229.2.5 with HTTP; Thu, 5 Apr 2012 16:50:45 -0700 (PDT)
In-Reply-To: <CAOzFzEjkpaGSHfv_ouTFs6a1FQDybpvFrVMmB7GZRYrDYvDnTw@mail.gmail.com>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
	<CAOzFzEjkpaGSHfv_ouTFs6a1FQDybpvFrVMmB7GZRYrDYvDnTw@mail.gmail.com>
Date: Fri, 6 Apr 2012 01:50:45 +0200
X-Google-Sender-Auth: j8XcxFK1vd3-nJsU0X7XPwx-aQ0
Message-ID: <CAL08nMEq3D9+xH30cMOp3GVqLGBJKGFUr6hUk6ZjOa+Vff35RQ@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1101164546681373364=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1101164546681373364==
Content-Type: multipart/alternative; boundary=20cf300fa95366636904bcf73557

--20cf300fa95366636904bcf73557
Content-Type: text/plain; charset=ISO-8859-1

thank you a lot for your advice, I will try to repeat the experiments with
the phy driver (and that will hopefully sync properly), and check out fio
for benchmarking :)

On Fri, Apr 6, 2012 at 1:04 AM, Joseph Glanville <
joseph.glanville@orionvm.com.au> wrote:

> On 6 April 2012 08:30, Pablo Llopis <pllopis@arcos.inf.uc3m.es> wrote:
> > Hi there Xen community,
> >
> > I am trying to benchmark and compare I/O in Xen/domU to native
> performance.
> >
> > In order to do this I started trying to benchmark writes so as to avoid
> > caching effects that surely turn up when performing reads due to the page
> > cache et al.
> > However, I have quickly run into a problem: Xen domU reports that a 128MB
> > file is written at close to 300MB/s, while the disk's performance peaks
> at
> > about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with
> no
> > hypervisor).
> > Please note that I fsync() after all writes in hopes to avoid the effect
> of
> > write buffers. I have tried with O_SYNC as well, observing a similar
> > outcome.
> > I can confirm this writing a simple program, and verified exactly same
> > results running bonnie++ with the fsync() option turned on.
> >
> > I am surprised to see writes reaching a throughput as high as 300MB/s, as
> > the disk surely isn't physically capable of reaching that bandwidth,
> meaning
> > that writes are not being really synced to disk.
> >
> > Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
> > fdatasync, O_SYNC, etc..?
> > How would I proceed to measure and compare real read/write speeds on a
> Xen
> > domU ?
> >
> > My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
> > could not get the tapdisk driver to work properly, I tried with vanilla
> 3.2
> > and 3.0.0 ubuntu kernels)
>
> To measure real disk speed I recommend using the phy:/ handler with a
> block device.
> You can use a partition, an LVM logical volume or an entire disk.
> Use of files on filesytems for domain block devices is discouraged and
> should be avoided at all costs.
>
> For testing IO throughput actively I wouldn't use bonnie++ as it is a
> filesystem level tool and not overly accurate at that.
> Use the Flexible IO Tester (aka fio) by Jens Axobe.
> You can install it on Ubuntu with:
> apt-get install fio
>
> I would also recommend using the libaio engine with fio if you are
> using an SSD and need to drive the queue depth up to get a better idea
> of the IOPs the device can deliver.
> You will need to install libaio with:
> apt-get install libaio
>
> > Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> > For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0
> kernel
> >
> > Thank you in advance,
> >
> > Pablo
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
> Joseph.
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> 99 52 | Mobile: 0428 754 846
>

--20cf300fa95366636904bcf73557
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

thank you a lot for your advice, I will try to repeat the experiments with =
the phy driver (and that will hopefully sync properly), and check out fio f=
or benchmarking :)<br><br><div class=3D"gmail_quote">On Fri, Apr 6, 2012 at=
 1:04 AM, Joseph Glanville <span dir=3D"ltr">&lt;<a href=3D"mailto:joseph.g=
lanville@orionvm.com.au" target=3D"_blank">joseph.glanville@orionvm.com.au<=
/a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div>On 6 April 2012 08:30, Pablo Llopi=
s &lt;<a href=3D"mailto:pllopis@arcos.inf.uc3m.es" target=3D"_blank">pllopi=
s@arcos.inf.uc3m.es</a>&gt; wrote:<br>


&gt; Hi there Xen community,<br>
&gt;<br>
&gt; I am trying to benchmark and compare I/O in Xen/domU to native perform=
ance.<br>
&gt;<br>
&gt; In order to do this I started trying to benchmark writes so as to avoi=
d<br>
&gt; caching effects that surely turn up when performing reads due to the p=
age<br>
&gt; cache et al.<br>
&gt; However, I have quickly run into a problem: Xen domU reports that a 12=
8MB<br>
&gt; file is written at close to 300MB/s, while the disk&#39;s performance =
peaks at<br>
&gt; about 80MB/s (I observed this on a dom0 and on a bare-metal kernel wit=
h no<br>
&gt; hypervisor).<br>
&gt; Please note that I fsync() after all writes in hopes to avoid the effe=
ct of<br>
&gt; write buffers.=A0I have tried with O_SYNC as well, observing a similar=
<br>
&gt; outcome.<br>
&gt; I can confirm this writing a simple program, and verified exactly same=
<br>
&gt; results running bonnie++ with the fsync() option turned on.<br>
&gt;<br>
&gt; I am surprised to see writes reaching a throughput as high as 300MB/s,=
 as<br>
&gt; the disk surely isn&#39;t physically capable of reaching that bandwidt=
h, meaning<br>
&gt; that writes are not being really synced to disk.<br>
&gt;<br>
&gt; Is this a bug in Xen, or is there a way to make Xen not ignore fsync,<=
br>
&gt; fdatasync, O_SYNC, etc..?<br>
&gt; How would I proceed to measure and compare real read/write speeds on a=
 Xen<br>
&gt; domU ?<br>
&gt;<br>
&gt; My disk drivers are specified with &quot;file:/path/to/image.img,xvda,=
1,w&quot; (I<br>
&gt; could not get the tapdisk driver to work properly, I tried with vanill=
a 3.2<br>
&gt; and 3.0.0 ubuntu kernels)<br>
<br>
</div></div>To measure real disk speed I recommend using the phy:/ handler =
with a<br>
block device.<br>
You can use a partition, an LVM logical volume or an entire disk.<br>
Use of files on filesytems for domain block devices is discouraged and<br>
should be avoided at all costs.<br>
<br>
For testing IO throughput actively I wouldn&#39;t use bonnie++ as it is a<b=
r>
filesystem level tool and not overly accurate at that.<br>
Use the Flexible IO Tester (aka fio) by Jens Axobe.<br>
You can install it on Ubuntu with:<br>
apt-get install fio<br>
<br>
I would also recommend using the libaio engine with fio if you are<br>
using an SSD and need to drive the queue depth up to get a better idea<br>
of the IOPs the device can deliver.<br>
You will need to install libaio with:<br>
apt-get install libaio<br>
<div><br>
&gt; Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)<br>
&gt; For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 =
kernel<br>
&gt;<br>
&gt; Thank you in advance,<br>
&gt;<br>
&gt; Pablo<br>
&gt;<br>
</div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
<span><font color=3D"#888888"><br>
Joseph.<br>
<br>
--<br>
Founder | Director | VP Research<br>
Orion Virtualisation Solutions=A0|=A0<a href=3D"http://www.orionvm.com.au" =
target=3D"_blank">www.orionvm.com.au</a>=A0| Phone: 1300 56<br>
99 52 | Mobile: 0428 754 846<br>
</font></span></blockquote></div><br>

--20cf300fa95366636904bcf73557--


--===============1101164546681373364==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1101164546681373364==--


From xen-devel-bounces@lists.xen.org Thu Apr 05 23:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Apr 2012 23:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFwS4-00066v-Ke; Thu, 05 Apr 2012 23:50:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SFwS2-00066q-Gr
	for xen-devel@lists.xen.org; Thu, 05 Apr 2012 23:50:50 +0000
Received: from [85.158.138.51:2416] by server-4.bemta-3.messagelabs.com id
	9E/23-16467-9DF2E7F4; Thu, 05 Apr 2012 23:50:49 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333669846!21050843!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29441 invoked from network); 5 Apr 2012 23:50:47 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Apr 2012 23:50:47 -0000
Received: by qabg40 with SMTP id g40so109092qab.11
	for <xen-devel@lists.xen.org>; Thu, 05 Apr 2012 16:50:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=mqcef3g13Jfnjly9rmI4Fc4ZKTrvYq+Ttbt6ZqlVdOM=;
	b=1IoWDOrOScBtlOHndHVY/TPjQsyTrqXVe6qcW+cqHLoDYEzFfUzaphLW/ML/uEdd1T
	XRqhTSj8K55xkTGq3rANzfAjgbwXTkEkaFa01opx22l7USF+TuXFU/MqC4B7mLAfrXRz
	Bf7rpks2rb0GJKKvChQ1G4YLLn4CFCntxRku+ppqofcWeEeHvZkILihweTm0y2xPGyVx
	5Cb9ZXGP+ZwUYvNnYiwY+DiOH2pFX0EioccWKV8PN9bCsJJl1E6Lm8AvHnhwwtTFjm90
	tphlO2twd2tNG/2lq/28vFB9uVeSBQiI9CH24Rb+Sx8g4htTvXrCt68BnVCURtf9BGxD
	KOpw==
MIME-Version: 1.0
Received: by 10.224.211.9 with SMTP id gm9mr6693552qab.78.1333669845689; Thu,
	05 Apr 2012 16:50:45 -0700 (PDT)
Received: by 10.229.2.5 with HTTP; Thu, 5 Apr 2012 16:50:45 -0700 (PDT)
In-Reply-To: <CAOzFzEjkpaGSHfv_ouTFs6a1FQDybpvFrVMmB7GZRYrDYvDnTw@mail.gmail.com>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
	<CAOzFzEjkpaGSHfv_ouTFs6a1FQDybpvFrVMmB7GZRYrDYvDnTw@mail.gmail.com>
Date: Fri, 6 Apr 2012 01:50:45 +0200
X-Google-Sender-Auth: j8XcxFK1vd3-nJsU0X7XPwx-aQ0
Message-ID: <CAL08nMEq3D9+xH30cMOp3GVqLGBJKGFUr6hUk6ZjOa+Vff35RQ@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1101164546681373364=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1101164546681373364==
Content-Type: multipart/alternative; boundary=20cf300fa95366636904bcf73557

--20cf300fa95366636904bcf73557
Content-Type: text/plain; charset=ISO-8859-1

thank you a lot for your advice, I will try to repeat the experiments with
the phy driver (and that will hopefully sync properly), and check out fio
for benchmarking :)

On Fri, Apr 6, 2012 at 1:04 AM, Joseph Glanville <
joseph.glanville@orionvm.com.au> wrote:

> On 6 April 2012 08:30, Pablo Llopis <pllopis@arcos.inf.uc3m.es> wrote:
> > Hi there Xen community,
> >
> > I am trying to benchmark and compare I/O in Xen/domU to native
> performance.
> >
> > In order to do this I started trying to benchmark writes so as to avoid
> > caching effects that surely turn up when performing reads due to the page
> > cache et al.
> > However, I have quickly run into a problem: Xen domU reports that a 128MB
> > file is written at close to 300MB/s, while the disk's performance peaks
> at
> > about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with
> no
> > hypervisor).
> > Please note that I fsync() after all writes in hopes to avoid the effect
> of
> > write buffers. I have tried with O_SYNC as well, observing a similar
> > outcome.
> > I can confirm this writing a simple program, and verified exactly same
> > results running bonnie++ with the fsync() option turned on.
> >
> > I am surprised to see writes reaching a throughput as high as 300MB/s, as
> > the disk surely isn't physically capable of reaching that bandwidth,
> meaning
> > that writes are not being really synced to disk.
> >
> > Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
> > fdatasync, O_SYNC, etc..?
> > How would I proceed to measure and compare real read/write speeds on a
> Xen
> > domU ?
> >
> > My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
> > could not get the tapdisk driver to work properly, I tried with vanilla
> 3.2
> > and 3.0.0 ubuntu kernels)
>
> To measure real disk speed I recommend using the phy:/ handler with a
> block device.
> You can use a partition, an LVM logical volume or an entire disk.
> Use of files on filesytems for domain block devices is discouraged and
> should be avoided at all costs.
>
> For testing IO throughput actively I wouldn't use bonnie++ as it is a
> filesystem level tool and not overly accurate at that.
> Use the Flexible IO Tester (aka fio) by Jens Axobe.
> You can install it on Ubuntu with:
> apt-get install fio
>
> I would also recommend using the libaio engine with fio if you are
> using an SSD and need to drive the queue depth up to get a better idea
> of the IOPs the device can deliver.
> You will need to install libaio with:
> apt-get install libaio
>
> > Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> > For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0
> kernel
> >
> > Thank you in advance,
> >
> > Pablo
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
> Joseph.
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> 99 52 | Mobile: 0428 754 846
>

--20cf300fa95366636904bcf73557
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

thank you a lot for your advice, I will try to repeat the experiments with =
the phy driver (and that will hopefully sync properly), and check out fio f=
or benchmarking :)<br><br><div class=3D"gmail_quote">On Fri, Apr 6, 2012 at=
 1:04 AM, Joseph Glanville <span dir=3D"ltr">&lt;<a href=3D"mailto:joseph.g=
lanville@orionvm.com.au" target=3D"_blank">joseph.glanville@orionvm.com.au<=
/a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div>On 6 April 2012 08:30, Pablo Llopi=
s &lt;<a href=3D"mailto:pllopis@arcos.inf.uc3m.es" target=3D"_blank">pllopi=
s@arcos.inf.uc3m.es</a>&gt; wrote:<br>


&gt; Hi there Xen community,<br>
&gt;<br>
&gt; I am trying to benchmark and compare I/O in Xen/domU to native perform=
ance.<br>
&gt;<br>
&gt; In order to do this I started trying to benchmark writes so as to avoi=
d<br>
&gt; caching effects that surely turn up when performing reads due to the p=
age<br>
&gt; cache et al.<br>
&gt; However, I have quickly run into a problem: Xen domU reports that a 12=
8MB<br>
&gt; file is written at close to 300MB/s, while the disk&#39;s performance =
peaks at<br>
&gt; about 80MB/s (I observed this on a dom0 and on a bare-metal kernel wit=
h no<br>
&gt; hypervisor).<br>
&gt; Please note that I fsync() after all writes in hopes to avoid the effe=
ct of<br>
&gt; write buffers.=A0I have tried with O_SYNC as well, observing a similar=
<br>
&gt; outcome.<br>
&gt; I can confirm this writing a simple program, and verified exactly same=
<br>
&gt; results running bonnie++ with the fsync() option turned on.<br>
&gt;<br>
&gt; I am surprised to see writes reaching a throughput as high as 300MB/s,=
 as<br>
&gt; the disk surely isn&#39;t physically capable of reaching that bandwidt=
h, meaning<br>
&gt; that writes are not being really synced to disk.<br>
&gt;<br>
&gt; Is this a bug in Xen, or is there a way to make Xen not ignore fsync,<=
br>
&gt; fdatasync, O_SYNC, etc..?<br>
&gt; How would I proceed to measure and compare real read/write speeds on a=
 Xen<br>
&gt; domU ?<br>
&gt;<br>
&gt; My disk drivers are specified with &quot;file:/path/to/image.img,xvda,=
1,w&quot; (I<br>
&gt; could not get the tapdisk driver to work properly, I tried with vanill=
a 3.2<br>
&gt; and 3.0.0 ubuntu kernels)<br>
<br>
</div></div>To measure real disk speed I recommend using the phy:/ handler =
with a<br>
block device.<br>
You can use a partition, an LVM logical volume or an entire disk.<br>
Use of files on filesytems for domain block devices is discouraged and<br>
should be avoided at all costs.<br>
<br>
For testing IO throughput actively I wouldn&#39;t use bonnie++ as it is a<b=
r>
filesystem level tool and not overly accurate at that.<br>
Use the Flexible IO Tester (aka fio) by Jens Axobe.<br>
You can install it on Ubuntu with:<br>
apt-get install fio<br>
<br>
I would also recommend using the libaio engine with fio if you are<br>
using an SSD and need to drive the queue depth up to get a better idea<br>
of the IOPs the device can deliver.<br>
You will need to install libaio with:<br>
apt-get install libaio<br>
<div><br>
&gt; Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)<br>
&gt; For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 =
kernel<br>
&gt;<br>
&gt; Thank you in advance,<br>
&gt;<br>
&gt; Pablo<br>
&gt;<br>
</div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
<span><font color=3D"#888888"><br>
Joseph.<br>
<br>
--<br>
Founder | Director | VP Research<br>
Orion Virtualisation Solutions=A0|=A0<a href=3D"http://www.orionvm.com.au" =
target=3D"_blank">www.orionvm.com.au</a>=A0| Phone: 1300 56<br>
99 52 | Mobile: 0428 754 846<br>
</font></span></blockquote></div><br>

--20cf300fa95366636904bcf73557--


--===============1101164546681373364==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1101164546681373364==--


From xen-devel-bounces@lists.xen.org Fri Apr 06 02:03:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 02:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFyVS-0003zF-V5; Fri, 06 Apr 2012 02:02:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFyVR-0003zA-32
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 02:02:29 +0000
Received: from [193.109.254.147:49071] by server-7.bemta-14.messagelabs.com id
	C4/E3-01627-4BE4E7F4; Fri, 06 Apr 2012 02:02:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1333677747!3446071!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE4Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3662 invoked from network); 6 Apr 2012 02:02:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 02:02:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,379,1330905600"; d="scan'208";a="11806070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 02:02:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 03:02:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFyVP-00012b-83;
	Fri, 06 Apr 2012 02:02:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFyVO-0005hw-2L;
	Fri, 06 Apr 2012 03:02:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12580-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 03:02:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12580: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12580 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12580/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-i386-i386-qemuu-win      7 windows-install          fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 02:03:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 02:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFyVS-0003zF-V5; Fri, 06 Apr 2012 02:02:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFyVR-0003zA-32
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 02:02:29 +0000
Received: from [193.109.254.147:49071] by server-7.bemta-14.messagelabs.com id
	C4/E3-01627-4BE4E7F4; Fri, 06 Apr 2012 02:02:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1333677747!3446071!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE4Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3662 invoked from network); 6 Apr 2012 02:02:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 02:02:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,379,1330905600"; d="scan'208";a="11806070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 02:02:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 03:02:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFyVP-00012b-83;
	Fri, 06 Apr 2012 02:02:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFyVO-0005hw-2L;
	Fri, 06 Apr 2012 03:02:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12580-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 03:02:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12580: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12580 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12580/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-i386-i386-qemuu-win      7 windows-install          fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 02:26:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 02:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFysP-0004Bt-To; Fri, 06 Apr 2012 02:26:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFysO-0004Bl-3s
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 02:26:12 +0000
Received: from [85.158.143.99:58659] by server-1.bemta-4.messagelabs.com id
	B6/60-20925-3445E7F4; Fri, 06 Apr 2012 02:26:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333679170!22521062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE4Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31891 invoked from network); 6 Apr 2012 02:26:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 02:26:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,379,1330905600"; d="scan'208";a="11806146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 02:26:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 03:26:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFysL-0001AT-QQ;
	Fri, 06 Apr 2012 02:26:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFysL-0002ev-Ph;
	Fri, 06 Apr 2012 03:26:09 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12579-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 03:26:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12579: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12579 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12579/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12563

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  2386288b1bf1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d690c7e896a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable d690c7e896a2
+ branch=xen-unstable
+ revision=d690c7e896a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d690c7e896a2 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 23 changesets with 75 changes to 65 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 02:26:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 02:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SFysP-0004Bt-To; Fri, 06 Apr 2012 02:26:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SFysO-0004Bl-3s
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 02:26:12 +0000
Received: from [85.158.143.99:58659] by server-1.bemta-4.messagelabs.com id
	B6/60-20925-3445E7F4; Fri, 06 Apr 2012 02:26:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1333679170!22521062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzE4Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31891 invoked from network); 6 Apr 2012 02:26:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 02:26:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,379,1330905600"; d="scan'208";a="11806146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 02:26:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 03:26:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SFysL-0001AT-QQ;
	Fri, 06 Apr 2012 02:26:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SFysL-0002ev-Ph;
	Fri, 06 Apr 2012 03:26:09 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12579-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 03:26:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12579: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12579 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12579/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12563

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  2386288b1bf1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d690c7e896a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable d690c7e896a2
+ branch=xen-unstable
+ revision=d690c7e896a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d690c7e896a2 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 23 changesets with 75 changes to 65 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 08:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 08:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG4EZ-0007Is-Qw; Fri, 06 Apr 2012 08:09:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG4EX-0007In-BI
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 08:09:26 +0000
Received: from [85.158.143.35:63581] by server-3.bemta-4.messagelabs.com id
	7E/F6-05853-4B4AE7F4; Fri, 06 Apr 2012 08:09:24 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333699762!3811151!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17981 invoked from network); 6 Apr 2012 08:09:23 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 08:09:23 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG4ET-0008B9-F7
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 01:09:21 -0700
Date: Fri, 6 Apr 2012 01:09:21 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333699761452-5622311.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Question about hvmloader, vgabios and qxl problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I spent several days to test xen-unstable with qemu upstream and spice qxl
usbredirection, I found several problems resolved or resolution in progress.
Unfortunately there is a problem that I can not fix or workaround, the qxl
graphic, with qemu and seabios unstable working but with ram assigned not
working more than 4 mb.
There is something missing or wrong in the initialization of the xen domU
that prevents the proper use of videoram with qxl but when I did not find
exactly what.
I am currently looking hvmloader and vgabios, apparently they did not
provide support for qxl and more videoram, so maybe the problem is there.
Vgabios is not updated to last version with qxl support, is used by qemu
upstream and need to be updated?
Hvmloader need to be modify for qxl support?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Question-about-hvmloader-vgabios-and-qxl-problem-tp5622311p5622311.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 08:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 08:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG4EZ-0007Is-Qw; Fri, 06 Apr 2012 08:09:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG4EX-0007In-BI
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 08:09:26 +0000
Received: from [85.158.143.35:63581] by server-3.bemta-4.messagelabs.com id
	7E/F6-05853-4B4AE7F4; Fri, 06 Apr 2012 08:09:24 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333699762!3811151!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17981 invoked from network); 6 Apr 2012 08:09:23 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 08:09:23 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG4ET-0008B9-F7
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 01:09:21 -0700
Date: Fri, 6 Apr 2012 01:09:21 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333699761452-5622311.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Question about hvmloader, vgabios and qxl problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I spent several days to test xen-unstable with qemu upstream and spice qxl
usbredirection, I found several problems resolved or resolution in progress.
Unfortunately there is a problem that I can not fix or workaround, the qxl
graphic, with qemu and seabios unstable working but with ram assigned not
working more than 4 mb.
There is something missing or wrong in the initialization of the xen domU
that prevents the proper use of videoram with qxl but when I did not find
exactly what.
I am currently looking hvmloader and vgabios, apparently they did not
provide support for qxl and more videoram, so maybe the problem is there.
Vgabios is not updated to last version with qxl support, is used by qemu
upstream and need to be updated?
Hvmloader need to be modify for qxl support?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Question-about-hvmloader-vgabios-and-qxl-problem-tp5622311p5622311.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 09:02:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 09:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG53L-0007cl-9s; Fri, 06 Apr 2012 09:01:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG53J-0007cg-1Z
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 09:01:53 +0000
Received: from [193.109.254.147:35381] by server-9.bemta-14.messagelabs.com id
	7B/3C-05787-001BE7F4; Fri, 06 Apr 2012 09:01:52 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333702910!395550!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20279 invoked from network); 6 Apr 2012 09:01:51 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 09:01:51 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG53F-0005Oq-Ip
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 02:01:49 -0700
Date: Fri, 6 Apr 2012 02:01:49 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333702909575-5622369.post@n5.nabble.com>
In-Reply-To: <824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
	<824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
 arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Roger Pau Monne wrote
> 
> You should use autoconf 2.67 to update the configure script.
> 
> [...]
> 
> Why don't you use AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE?
> 
On notebook I have Mint 12 and Precise, on testing server Wheezy, all with
autoconf 2.68, I'll redo on other pc with old s.o.

About AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE do enable/disable and
export it, I not export but use it for bash command, I must need
AC_ARG_ENABLE or my mistake about?


--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-v2-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5617799p5622369.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 09:02:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 09:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG53L-0007cl-9s; Fri, 06 Apr 2012 09:01:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG53J-0007cg-1Z
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 09:01:53 +0000
Received: from [193.109.254.147:35381] by server-9.bemta-14.messagelabs.com id
	7B/3C-05787-001BE7F4; Fri, 06 Apr 2012 09:01:52 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1333702910!395550!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20279 invoked from network); 6 Apr 2012 09:01:51 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 09:01:51 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SG53F-0005Oq-Ip
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 02:01:49 -0700
Date: Fri, 6 Apr 2012 02:01:49 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1333702909575-5622369.post@n5.nabble.com>
In-Reply-To: <824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
	<824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
 arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Roger Pau Monne wrote
> 
> You should use autoconf 2.67 to update the configure script.
> 
> [...]
> 
> Why don't you use AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE?
> 
On notebook I have Mint 12 and Precise, on testing server Wheezy, all with
autoconf 2.68, I'll redo on other pc with old s.o.

About AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE do enable/disable and
export it, I not export but use it for bash command, I must need
AC_ARG_ENABLE or my mistake about?


--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-v2-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5617799p5622369.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 09:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 09:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG56E-0007iD-VB; Fri, 06 Apr 2012 09:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1SG56D-0007i6-Hq
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 09:04:53 +0000
Received: from [85.158.139.83:30908] by server-12.bemta-5.messagelabs.com id
	25/01-05587-4B1BE7F4; Fri, 06 Apr 2012 09:04:52 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333703091!20033880!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU5MDE4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16617 invoked from network); 6 Apr 2012 09:04:52 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-182.messagelabs.com with SMTP;
	6 Apr 2012 09:04:52 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 06 Apr 2012 02:04:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127829412"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 06 Apr 2012 02:04:50 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 6 Apr 2012 02:04:49 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id
	14.01.0355.002; Fri, 6 Apr 2012 17:04:47 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:25110 & Dom0:d93dc5c...
Thread-Index: Ac0T1FABJo+AM9zlSYqJ9m8QkJEBAQ==
Date: Fri, 6 Apr 2012 09:04:46 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FCDDC0F@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:25110 & Dom0:d93dc5c...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree. One old issue got fixed.

Version Info:
=================================================================
xen-changeset:   25110
Dom0:          linux.git  3.1.0-rc7 (commit: d93dc5c...) 
=================================================================

New issue(0)
==============

Fixed issue(1)
==============
1.Dom0 hang when bootup a guest with a VF(the guest has been bootup with a different VF before)
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1810

Old issues(8)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. [VT-D] device reset fail when create/destroy guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752
6. when detaching a VF from hvm guest, "xl dmesg" will show some warning information
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809
7. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
8. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812



Thanks
Zhou, Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 09:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 09:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG56E-0007iD-VB; Fri, 06 Apr 2012 09:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1SG56D-0007i6-Hq
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 09:04:53 +0000
Received: from [85.158.139.83:30908] by server-12.bemta-5.messagelabs.com id
	25/01-05587-4B1BE7F4; Fri, 06 Apr 2012 09:04:52 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333703091!20033880!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU5MDE4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16617 invoked from network); 6 Apr 2012 09:04:52 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-182.messagelabs.com with SMTP;
	6 Apr 2012 09:04:52 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 06 Apr 2012 02:04:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127829412"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 06 Apr 2012 02:04:50 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 6 Apr 2012 02:04:49 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id
	14.01.0355.002; Fri, 6 Apr 2012 17:04:47 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:25110 & Dom0:d93dc5c...
Thread-Index: Ac0T1FABJo+AM9zlSYqJ9m8QkJEBAQ==
Date: Fri, 6 Apr 2012 09:04:46 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FCDDC0F@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:25110 & Dom0:d93dc5c...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree. One old issue got fixed.

Version Info:
=================================================================
xen-changeset:   25110
Dom0:          linux.git  3.1.0-rc7 (commit: d93dc5c...) 
=================================================================

New issue(0)
==============

Fixed issue(1)
==============
1.Dom0 hang when bootup a guest with a VF(the guest has been bootup with a different VF before)
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1810

Old issues(8)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. [VT-D] device reset fail when create/destroy guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752
6. when detaching a VF from hvm guest, "xl dmesg" will show some warning information
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809
7. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
8. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812



Thanks
Zhou, Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 10:21:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 10:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG6HD-0008FX-39; Fri, 06 Apr 2012 10:20:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SG6HB-0008FS-D1
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 10:20:17 +0000
Received: from [85.158.139.83:36253] by server-10.bemta-5.messagelabs.com id
	90/21-08260-063CE7F4; Fri, 06 Apr 2012 10:20:16 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333707614!22657877!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23116 invoked from network); 6 Apr 2012 10:20:15 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 10:20:15 -0000
Received: by yhkk6 with SMTP id k6so1478367yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 03:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=9D/gkajowHxV3E7IsQX4CSI8gw8ug+Yf+BbRhnlP/Fc=;
	b=YfwxVmLpMj/KFv7GqVLL6EFI4qgEDvRg722+c6rwjlBpwuYvAnt9n1G9VYYCiiquG+
	AMID0KnjVUZ8aIN2EYmijQQuC7PqddktN8e3o4OW4VtbT/zQ9tgrCXPxvj1vB619Q8Hm
	GN/hxQG/+vRiqAq7E8K5B35S80MzSRKQvFO6dk3mgtdfN286/RhBDvJrUXoyhu4LFqsV
	g4BJcmomUT7cAPHBQqQIbM/1eyVyC2O5JkpsBhSIxx+LVnlDQa9CNZxI0WQxiafKOeDo
	FnIxpGUVM3dANksmH3AV32zLTGWWm+LjdPJc9/9ndQie9llHfbDUiNgaCpXuk+BbyjW3
	TgJQ==
MIME-Version: 1.0
Received: by 10.236.76.37 with SMTP id a25mr3518131yhe.42.1333707614042; Fri,
	06 Apr 2012 03:20:14 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Fri, 6 Apr 2012 03:20:13 -0700 (PDT)
Date: Fri, 6 Apr 2012 19:20:13 +0900
Message-ID: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hello All,

I am still working on the PV Drivers for SeaBIOS using upstream qemu.
And, I have two questions.
1.
Here is the location of all relevant data structs:
blkfront_info:0x000fd620 shared_ring:0x0009a000 private_ring:0x0009b000
DEBUG Read op private ring at 0x0009b000-0x000ab000, idx 63478
Here is my problem, when I do:
        ring_req =3D
GLOBALFLAT2GLOBAL(RING_GET_REQUEST(GET_GLOBALFLAT(bi->private),GLOBALFLAT2G=
LOBAL(GET_GLOBALFLAT(bi->private)->req_prod_pvt)));
 //please ignore the MACROS for now, or read further down.
I get:
After RING_GET_REQUEST operation ring request is at 0xe18ea40f id:0
But I have the feeling that the request should be between
0x0009b000-0x000ab000. Right?

2.
As you can see in the above code I use some SeaBIOS macros to access
32Bit addresses in 16Bit code. My second questions is: How the memory
access macros affect the RING macros? Do I need to rewrite the ring
macros to use the memory macros inside, for example:
/* How big is this ring? */
#define RING_SIZE(_r)                                                   \
    ((_r)->nr_ents)

Should be instead:
/* How big is this ring? */
#define RING_SIZE(_r)                                                   \
    (GET_GLOBAL((_r)->nr_ents))

SeaBIOS macros need to be around ALL memory accesses.

This is a short message for something that might be to complex to
explain briefly, so please ask any questions that you deem necessary
to understand. Right now, I am developing the first stage of boot when
the BIOS requests address 7c00 to get the Boot sector. Once I get this
working we should have a working prototype for PV-drivers in seabios.

Thank you all for your interest,

Daniel

-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 10:21:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 10:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG6HD-0008FX-39; Fri, 06 Apr 2012 10:20:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SG6HB-0008FS-D1
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 10:20:17 +0000
Received: from [85.158.139.83:36253] by server-10.bemta-5.messagelabs.com id
	90/21-08260-063CE7F4; Fri, 06 Apr 2012 10:20:16 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333707614!22657877!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23116 invoked from network); 6 Apr 2012 10:20:15 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 10:20:15 -0000
Received: by yhkk6 with SMTP id k6so1478367yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 03:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=9D/gkajowHxV3E7IsQX4CSI8gw8ug+Yf+BbRhnlP/Fc=;
	b=YfwxVmLpMj/KFv7GqVLL6EFI4qgEDvRg722+c6rwjlBpwuYvAnt9n1G9VYYCiiquG+
	AMID0KnjVUZ8aIN2EYmijQQuC7PqddktN8e3o4OW4VtbT/zQ9tgrCXPxvj1vB619Q8Hm
	GN/hxQG/+vRiqAq7E8K5B35S80MzSRKQvFO6dk3mgtdfN286/RhBDvJrUXoyhu4LFqsV
	g4BJcmomUT7cAPHBQqQIbM/1eyVyC2O5JkpsBhSIxx+LVnlDQa9CNZxI0WQxiafKOeDo
	FnIxpGUVM3dANksmH3AV32zLTGWWm+LjdPJc9/9ndQie9llHfbDUiNgaCpXuk+BbyjW3
	TgJQ==
MIME-Version: 1.0
Received: by 10.236.76.37 with SMTP id a25mr3518131yhe.42.1333707614042; Fri,
	06 Apr 2012 03:20:14 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Fri, 6 Apr 2012 03:20:13 -0700 (PDT)
Date: Fri, 6 Apr 2012 19:20:13 +0900
Message-ID: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hello All,

I am still working on the PV Drivers for SeaBIOS using upstream qemu.
And, I have two questions.
1.
Here is the location of all relevant data structs:
blkfront_info:0x000fd620 shared_ring:0x0009a000 private_ring:0x0009b000
DEBUG Read op private ring at 0x0009b000-0x000ab000, idx 63478
Here is my problem, when I do:
        ring_req =3D
GLOBALFLAT2GLOBAL(RING_GET_REQUEST(GET_GLOBALFLAT(bi->private),GLOBALFLAT2G=
LOBAL(GET_GLOBALFLAT(bi->private)->req_prod_pvt)));
 //please ignore the MACROS for now, or read further down.
I get:
After RING_GET_REQUEST operation ring request is at 0xe18ea40f id:0
But I have the feeling that the request should be between
0x0009b000-0x000ab000. Right?

2.
As you can see in the above code I use some SeaBIOS macros to access
32Bit addresses in 16Bit code. My second questions is: How the memory
access macros affect the RING macros? Do I need to rewrite the ring
macros to use the memory macros inside, for example:
/* How big is this ring? */
#define RING_SIZE(_r)                                                   \
    ((_r)->nr_ents)

Should be instead:
/* How big is this ring? */
#define RING_SIZE(_r)                                                   \
    (GET_GLOBAL((_r)->nr_ents))

SeaBIOS macros need to be around ALL memory accesses.

This is a short message for something that might be to complex to
explain briefly, so please ask any questions that you deem necessary
to understand. Right now, I am developing the first stage of boot when
the BIOS requests address 7c00 to get the Boot sector. Once I get this
working we should have a working prototype for PV-drivers in seabios.

Thank you all for your interest,

Daniel

-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 10:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 10:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG6qC-0000Rz-2q; Fri, 06 Apr 2012 10:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SG6qA-0000Ru-Nr
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 10:56:26 +0000
Received: from [85.158.143.35:65194] by server-1.bemta-4.messagelabs.com id
	F4/F0-20925-9DBCE7F4; Fri, 06 Apr 2012 10:56:25 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333709782!11332443!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4400 invoked from network); 6 Apr 2012 10:56:24 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 10:56:24 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SG6q1-0003nw-ML; Fri, 06 Apr 2012 20:56:17 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Apr 2012 20:56:17 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 6 Apr 2012 20:56:14 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Tobias Geiger <tobias.geiger@vido.info>
Thread-Topic: [Xen-devel] Signed GPLPV drivers available for download
Thread-Index: Acxy+YkWI1pOnpezTaeWDYNydOr/1iY7BJ3A//9ZnwD/72CqEA==
Date: Fri, 6 Apr 2012 10:56:14 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
References: <201109090950.05043.muehlenhoff@univention.de>
	<201109141814.29461.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B10AD86AC@BITCOM1.int.sbss.com.au>
	<201203270952.56490.tobias.geiger@vido.info>
In-Reply-To: <201203270952.56490.tobias.geiger@vido.info>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Apr 2012 10:56:17.0496 (UTC)
	FILETIME=[E4748D80:01CD13E3]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> glad you ask - because just yesterday i re-tested the 357-version of the
> drivers under Windows7 64bit HVM guest - here are the results:
> 
> (everyting in mb/s)
> 
> W/O gplpv-drivers and WITH pci-passthrough:
> 
> Seq. reading: 311.8
> Seq. writing:  106.3
> 4k    reading: 10.2
> 4k    writing:   9.3
> 4k64thread reading: 11.1
> 4k64threads writing: 10.9
> 
> 
> WITH gplpv-drivers and WITH pci-passthrough:
> 
> Seq. reading: 98.8
> Seq. writing:  31.6
> 4k    reading: 12.0
> 4k    writing:  19.3
> 4k64thread reading: 15.4
> 4k64threads writing: 29.6
> 
> 
> WITH gplpv-drivers and WITHOUT pci-passthrough:
> 
> Seq. reading: 104.4
> Seq. writing:   85.2
> 4k    reading:  12.7
> 4k    writing:   20.4
> 4k64thread reading: 16.6
> 4k64threads writing: 32.6
> 
> 
> Strange thing is, that even without pci-passthrough the performance with
> gplpv is'nt that much better compared to w/o gplpv but with pci-passthrough
> - well it is overall a bit better, but just a bit, and seq. read performance is
> much worse...
> i haven't made a test without gplpv and without passthrough at the same
> time - tell me if you want to see how that performs.
> 
> Greetings!
> Tobias
> 
> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this tests.
> 

What are you testing this with? I just ran some tests with iometer under 2008R2 and it reminded me of something... DRBD *hates* having outstanding writes to the same block, and complains about it, so gplpv serialises such requests (stalling the queue until the first request is complete). This almost never happens in production but iometer sends such requests frequently, which will significantly impact performance.

You can test with the debug build to see if this is happening with whatever you are testing with - you'll see messages like "Concurrent outstanding write detected". Be aware though that qemu will rate limit writes to the debug log so if it happens a lot (like under iometer) it will slow to a crawl.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 10:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 10:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG6qC-0000Rz-2q; Fri, 06 Apr 2012 10:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SG6qA-0000Ru-Nr
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 10:56:26 +0000
Received: from [85.158.143.35:65194] by server-1.bemta-4.messagelabs.com id
	F4/F0-20925-9DBCE7F4; Fri, 06 Apr 2012 10:56:25 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333709782!11332443!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4400 invoked from network); 6 Apr 2012 10:56:24 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 10:56:24 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SG6q1-0003nw-ML; Fri, 06 Apr 2012 20:56:17 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Apr 2012 20:56:17 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 6 Apr 2012 20:56:14 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Tobias Geiger <tobias.geiger@vido.info>
Thread-Topic: [Xen-devel] Signed GPLPV drivers available for download
Thread-Index: Acxy+YkWI1pOnpezTaeWDYNydOr/1iY7BJ3A//9ZnwD/72CqEA==
Date: Fri, 6 Apr 2012 10:56:14 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
References: <201109090950.05043.muehlenhoff@univention.de>
	<201109141814.29461.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B10AD86AC@BITCOM1.int.sbss.com.au>
	<201203270952.56490.tobias.geiger@vido.info>
In-Reply-To: <201203270952.56490.tobias.geiger@vido.info>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Apr 2012 10:56:17.0496 (UTC)
	FILETIME=[E4748D80:01CD13E3]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> glad you ask - because just yesterday i re-tested the 357-version of the
> drivers under Windows7 64bit HVM guest - here are the results:
> 
> (everyting in mb/s)
> 
> W/O gplpv-drivers and WITH pci-passthrough:
> 
> Seq. reading: 311.8
> Seq. writing:  106.3
> 4k    reading: 10.2
> 4k    writing:   9.3
> 4k64thread reading: 11.1
> 4k64threads writing: 10.9
> 
> 
> WITH gplpv-drivers and WITH pci-passthrough:
> 
> Seq. reading: 98.8
> Seq. writing:  31.6
> 4k    reading: 12.0
> 4k    writing:  19.3
> 4k64thread reading: 15.4
> 4k64threads writing: 29.6
> 
> 
> WITH gplpv-drivers and WITHOUT pci-passthrough:
> 
> Seq. reading: 104.4
> Seq. writing:   85.2
> 4k    reading:  12.7
> 4k    writing:   20.4
> 4k64thread reading: 16.6
> 4k64threads writing: 32.6
> 
> 
> Strange thing is, that even without pci-passthrough the performance with
> gplpv is'nt that much better compared to w/o gplpv but with pci-passthrough
> - well it is overall a bit better, but just a bit, and seq. read performance is
> much worse...
> i haven't made a test without gplpv and without passthrough at the same
> time - tell me if you want to see how that performs.
> 
> Greetings!
> Tobias
> 
> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this tests.
> 

What are you testing this with? I just ran some tests with iometer under 2008R2 and it reminded me of something... DRBD *hates* having outstanding writes to the same block, and complains about it, so gplpv serialises such requests (stalling the queue until the first request is complete). This almost never happens in production but iometer sends such requests frequently, which will significantly impact performance.

You can test with the debug build to see if this is happening with whatever you are testing with - you'll see messages like "Concurrent outstanding write detected". Be aware though that qemu will rate limit writes to the debug log so if it happens a lot (like under iometer) it will slow to a crawl.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 11:01:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 11:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG6um-0000bF-Q3; Fri, 06 Apr 2012 11:01:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1SG6ul-0000b4-4j
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 11:01:11 +0000
Received: from [85.158.143.35:56075] by server-2.bemta-4.messagelabs.com id
	C1/8A-17550-6FCCE7F4; Fri, 06 Apr 2012 11:01:10 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333710066!11332868!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11746 invoked from network); 6 Apr 2012 11:01:07 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 11:01:07 -0000
Received: by lagr15 with SMTP id r15so2540279lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 04:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=aTNzS1xsTTxA2wvEfkX4knzXtgP6o+FcLpZCelEv1po=;
	b=U7qFf/TOaGqbckEpRTsFosb69UCk/tnSLF82hmrvXssPzFQ10czZHmzLAwCU63Qrg3
	Gxywb7lP+tMZY1Ne8N8qtBmDXgb5SnknVpH1Z4+Kkw74xeDTNJQaD/Us2AAr9b2s6mpi
	UvJa7m0aWUiyQsemx5bAmRgbzlKPkbekJVpdg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=aTNzS1xsTTxA2wvEfkX4knzXtgP6o+FcLpZCelEv1po=;
	b=dzN6l8D5E9W3Cmf2vg+utj45YslW34dQlQ251lw3cL+nuqa8yVYvyobPMp1xH69/xR
	7snZGFzfmdfiSK+vARCa8uUhoRSpOvqZSx9KltJNStSiYzZexqTwnd6Bt76eALOz/u7c
	8obTOImCGxSgPgXXYKurssBHBxuS8aECnmUZh6tn2kwS7L0rbBrXtfvy5PbbKDVfVLaf
	LSDYKIEBP3ZgaMncSoY21ATHGsmT/XGF6M7Hf/MQgHMsFQjtOpE7mX8x3078wlXioln6
	ZYlGcBR4LlICfRcZwKIzUyGBNx5LhEtZ+p48h4MEPkJ+YCT0yLQ/8tbei/J4yJm5B9h9
	wD9Q==
Received: by 10.152.132.6 with SMTP id oq6mr7996176lab.44.1333710066260; Fri,
	06 Apr 2012 04:01:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.37.234 with HTTP; Fri, 6 Apr 2012 04:00:51 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
References: <201109090950.05043.muehlenhoff@univention.de>
	<201109141814.29461.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B10AD86AC@BITCOM1.int.sbss.com.au>
	<201203270952.56490.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 6 Apr 2012 15:00:51 +0400
X-Google-Sender-Auth: Pz6kGfqNstRR9tjF438zf4mcKa0
Message-ID: <CACaajQv4afgmrHO6F8DqHoePMqPMyWD7OjXnZmh=NKir8ipfnA@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQkMyvEY5XQ3uuZHB5GUQxj6+EM0zykOPy83In477+Y3xeKZKey30PNqOiksi6/Sa3UdJKjR
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/4/6 James Harper <james.harper@bendigoit.com.au>:
>
> What are you testing this with? I just ran some tests with iometer under 2008R2 and it reminded me of something... DRBD *hates* having outstanding writes to the same block, and complains about it, so gplpv serialises such requests (stalling the queue until the first request is complete). This almost never happens in production but iometer sends such requests frequently, which will significantly impact performance.
>
> You can test with the debug build to see if this is happening with whatever you are testing with - you'll see messages like "Concurrent outstanding write detected". Be aware though that qemu will rate limit writes to the debug log so if it happens a lot (like under iometer) it will slow to a crawl.
>
> James
>

Sorry, but i have another problem with disk write when use gplpv:

 I'm create simple winpe windows installer with windows aik and
integrate into it xen gpl pv drivers. Sometimes i can't install
windows to hard drive.
Windows syas, that hard disk not properly configured in bios or not
able to boot from it.
Disk is the phisical device, domU config:

kernel='hvmloader'
builder='hvm'
memory=1024
name="21-706"
vcpus=4
vif="mac=00:16:3e:00:17:b9,ip=62.76.47.68,type=paravirtualised"
disk="file:/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso,hdc:cdrom,r"
disk="phy:/dev/disk/vbd/21-1206,hda,w"
device_model='qemu-dm'
boot='c'
vnc=1
vncpasswd='uRFCg8oPkD'
serial='pty'
usbdevice='tablet'
keymap='en-us'
boot='d'
-p
disk="file:/var/storage/iso/winpe_amd64.iso,hdb:cdrom,r"
on_reboot=destroy
on_poweroff=destroy
on_crash=destroy

qemu-dm log conains this messages:

domid: 1155
Using file /var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
in read-only mode
Using file /dev/disk/vbd/21-1206 in read-write mode
Using file /var/storage/iso/winpe_amd64.iso in read-only mode
Watching /local/domain/0/device-model/1155/logdirty/cmd
Watching /local/domain/0/device-model/1155/command
char device redirected to /dev/pts/59
qemu_map_cache_init nr_buckets = 10000 size 4194304
/usr/src/packages/BUILD/xen-4.0.1-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
Init blktap pipes
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 64ebb4f3-827b-4bbd-3ada-358b66e61a95
Time offset set 0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/1155/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 0):
/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdb' (index: 2): /var/storage/iso/winpe_amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/1155/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
log_throttling disabled
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
12974973492593: XenPCI --> XenPci_InitialBalloonDown
12974973492593: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492593: XenPCI     Xen Version 4.0
12974973492593: XenPCI     Hypercall area at FFFFFA80010B7000
12974973492593: XenPCI     XENMEM_maximum_reservation = 263168
12974973492593: XenPCI     XENMEM_current_reservation = 263160
12974973492593: XenPCI     Trying to give 32 KB (0 MB) to Xen
12974973492609: XenPCI <-- XenPci_InitialBalloonDown
12974973492609: XenPCI     KeInitializeCrashDumpHeader status =
00000000, size = 8192
12974973492609: XenPCI GPLPV 0.10.0.357
12974973492609: XenPCI --> XenPci_FixLoadOrder
12974973492609: XenPCI     dummy_group_index = -1
12974973492609: XenPCI     wdf_load_group_index = 2
12974973492609: XenPCI     xenpci_group_index = -1
12974973492609: XenPCI     boot_bus_extender_index = 3
12974973492609: XenPCI <-- XenPci_FixLoadOrder
12974973492609: XenPCI     SystemStartOptions =  MININT  REDIRECT
RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088
RDPATH=MULTI(0)DISK(0)CDROM(0)\SOURCES\BOOT.WIM
12974973492625: XenPCI     Version = 1
Unknown PV product 2 loaded in guest
PV driver build 1
12974973492625: XenPCI     Disabled qemu devices 01
12974973492625: XenPCI <-- DriverEntry
12974973492625: XenPCI     Xen PCI device found - must be fdo
12974973492625: XenPCI --> XenPci_EvtDeviceAdd_XenPci
12974973492625: XenPCI <-- XenPci_EvtDeviceAdd_XenPci
12974973492640: XenPCI --> XenPci_EvtDevicePrepareHardware
12974973492640: XenPCI     IoPort Address(c000) Length: 256
12974973492640: XenPCI     Private Data: 0x01 0x00 0x00
12974973492640: XenPCI     Memory mapped CSR:(f2000000:0) Length:(16777216)
12974973492640: XenPCI     Memory flags = 0084
12974973492640: XenPCI     Private Data: 0x01 0x01 0x00
12974973492640: XenPCI     irq_number = 01c
12974973492640: XenPCI     irq_vector = 0a2
12974973492640: XenPCI     irq_level = 00a
12974973492640: XenPCI     irq_mode = LevelSensitive
12974973492656: XenPCI     ShareDisposition = CmResourceShareShared
12974973492656: XenPCI <-- XenPci_EvtDevicePrepareHardware
12974973492656: XenPCI --> XenPci_EvtDeviceD0Entry
12974973492656: XenPCI     WdfPowerDeviceD3Final
12974973492656: XenPCI --> XenPci_Init
12974973492656: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492656: XenPCI     Xen Version 4.0
12974973492656: XenPCI     Hypercall area at FFFFFA80011BD000
12974973492656: XenPCI     shared_info_area_unmapped.QuadPart = f2000000
12974973492656: XenPCI     gpfn = f2000
12974973492656: XenPCI     hypervisor memory op
(XENMAPSPACE_shared_info) ret = 0
12974973492671: XenPCI <-- XenPci_Init
12974973492671: XenPCI --> GntTbl_Init
12974973492671: XenPCI     grant_frames = 32
12974973492671: XenPCI     grant_entries = 16384
12974973492671: XenPCI     pfn = 3fa1e
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1e
12974973492671: XenPCI     decreased 1 pages for grant table frame 0
12974973492671: XenPCI     pfn = 3fa1f
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1f
12974973492671: XenPCI     decreased 1 pages for grant table frame 1
12974973492671: XenPCI     pfn = 3fa20
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa20
12974973492687: XenPCI     decreased 1 pages for grant table frame 2
12974973492687: XenPCI     pfn = 3fa21
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa21
12974973492687: XenPCI     decreased 1 pages for grant table frame 3
12974973492687: XenPCI     pfn = 3fa22
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa22
12974973492687: XenPCI     decreased 1 pages for grant table frame 4
12974973492687: XenPCI     pfn = 3fa23
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa23
12974973492703: XenPCI     decreased 1 pages for grant table frame 5
12974973492703: XenPCI     pfn = 3fa24
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa24
12974973492703: XenPCI     decreased 1 pages for grant table frame 6
12974973492703: XenPCI     pfn = 3fa25
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa25
12974973492703: XenPCI     decreased 1 pages for grant table frame 7
12974973492718: XenPCI     pfn = 3fa26
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa26
12974973492718: XenPCI     decreased 1 pages for grant table frame 8
12974973492718: XenPCI     pfn = 3fa27
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa27
12974973492718: XenPCI     decreased 1 pages for grant table frame 9
12974973492718: XenPCI     pfn = 3fa28
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa28
12974973492718: XenPCI     decreased 1 pages for grant table frame 10
12974973492734: XenPCI     pfn = 3fa29
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa29
12974973492734: XenPCI     decreased 1 pages for grant table frame 11
12974973492734: XenPCI     pfn = 3fa2a
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2a
12974973492734: XenPCI     decreased 1 pages for grant table frame 12
12974973492734: XenPCI     pfn = 3fa2b
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2b
12974973492750: XenPCI     decreased 1 pages for grant table frame 13
12974973492750: XenPCI     pfn = 3fa2c
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2c
12974973492750: XenPCI     decreased 1 pages for grant table frame 14
12974973492750: XenPCI     pfn = 3fa2d
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2d
12974973492750: XenPCI     decreased 1 pages for grant table frame 15
12974973492750: XenPCI     pfn = 3fa2e
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2e
12974973492765: XenPCI     decreased 1 pages for grant table frame 16
12974973492765: XenPCI     pfn = 3fa2f
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2f
12974973492765: XenPCI     decreased 1 pages for grant table frame 17
12974973492765: XenPCI     pfn = 3fa30
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa30
12974973492765: XenPCI     decreased 1 pages for grant table frame 18
12974973492765: XenPCI     pfn = 3fa31
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa31
12974973492765: XenPCI     decreased 1 pages for grant table frame 19
12974973492781: XenPCI     pfn = 3fa32
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa32
12974973492781: XenPCI     decreased 1 pages for grant table frame 20
12974973492781: XenPCI     pfn = 3fa33
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa33
12974973492781: XenPCI     decreased 1 pages for grant table frame 21
12974973492781: XenPCI     pfn = 3fa34
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa34
12974973492796: XenPCI     decreased 1 pages for grant table frame 22
12974973492796: XenPCI     pfn = 3fa35
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa35
12974973492796: XenPCI     decreased 1 pages for grant table frame 23
12974973492796: XenPCI     pfn = 3fa36
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa36
12974973492796: XenPCI     decreased 1 pages for grant table frame 24
12974973492796: XenPCI     pfn = 3fa37
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa37
12974973492812: XenPCI     decreased 1 pages for grant table frame 25
12974973492812: XenPCI     pfn = 3fa38
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa38
12974973492812: XenPCI     decreased 1 pages for grant table frame 26
12974973492812: XenPCI     pfn = 3fa39
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa39
12974973492812: XenPCI     decreased 1 pages for grant table frame 27
12974973492812: XenPCI     pfn = 3fa3a
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3a
12974973492828: XenPCI     decreased 1 pages for grant table frame 28
12974973492828: XenPCI     pfn = 3fa3b
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3b
12974973492828: XenPCI     decreased 1 pages for grant table frame 29
12974973492828: XenPCI     pfn = 3fa3c
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3c
12974973492828: XenPCI     decreased 1 pages for grant table frame 30
12974973492828: XenPCI     pfn = 3fa3d
12974973492843: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3d
12974973492843: XenPCI     decreased 1 pages for grant table frame 31
12974973492859: XenPCI --> GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Init
12974973492875: XenPCI --> EvtChn_Init
12974973492875: XenPCI --> _hvm_set_parameter
12974973492890: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492890: XenPCI <-- _hvm_set_parameter
12974973492890: XenPCI     hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0
12974973492890: XenPCI --> EvtChn_AllocIpi
12974973492890: XenPCI <-- EvtChn_AllocIpi
12974973492890: XenPCI --> EvtChn_BindDpc
12974973492890: XenPCI <-- EvtChn_BindDpc
12974973492890: XenPCI     pdo_event_channel = 7
12974973492890: XenPCI <-- EvtChn_Init
12974973492890: XenPCI <-- XenPci_EvtDeviceD0Entry
12974973492890: XenPCI --> EvtChn_EvtInterruptEnable
12974973492890: XenPCI <-- EvtChn_EvtInterruptEnable
12974973492906: XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492906: XenPCI --> XenBus_Init
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI <-- XenBus_Init
12974973492906: XenPCI     suspend event channel = 8
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI --> XenPci_SysrqHandler
12974973492906: XenPCI     SysRq Value = (null)
12974973492921: XenPCI <-- XenPci_SysrqHandler
12974973492921: XenPCI --> XenPci_ShutdownHandler
12974973492921: XenPCI     Initial Memory Value = 1048576 (1048576)
12974973492953: Error reading shutdown path - ENOENT
12974973492953: XenPCI <-- XenPci_ShutdownHandler
12974973492953: XenPCI --> XenPci_BalloonThreadProc
12974973492953: XenPCI --> XenPci_DeviceWatchHandler
12974973492953: XenPCI     low_mem_event = FFFFFA8000C865C0, state = 0
12974973492953: XenPCI <-- XenPci_DeviceWatchHandler
12974973492953: XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492953: XenPCI --> XenPci_BalloonHandler
12974973492953: XenPCI --> XenPci_EvtChildListScanForChildren
12974973492953: XenPCI     target memory value = 1048576 (1048576)
12974973492953: XenPCI     Found path = device/vfb/0
12974973492953: XenPCI     Got balloon event, current = 1048576,
target = 1048576
12974973492968: XenPCI     Found path = device/vbd/5632
12974973492968: XenPCI     No change to memory
12974973492968: XenPCI <-- XenPci_BalloonHandler
12974973492968: XenPCI     Found path = device/vbd/768
12974973492968: XenPCI     Found path = device/vbd/832
12974973492968: XenPCI     Found path = device/vif/0
12974973492968: XenPCI     Found path = device/suspend/event-channel
12974973492968: XenPCI <-- XenPci_EvtChildListScanForChildren
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492968: XenPCI     device = 'vfb', index = '0', path = 'device/vfb/0'
12974973492968: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '5632', path =
'device/vbd/5632'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '768', path =
'device/vbd/768'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '832', path =
'device/vbd/832'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vif', index = '0', path = 'device/vif/0'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973493000: XenPCI     device = 'suspend', index = '0', path =
'device/suspend/event-channel'
12974973493000: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973503046: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI     device/vbd/5632
12974973503046: XenPCI     CmResourceTypeMemory (0)
12974973503046: XenPCI     Start = f2000000, Length = 0
12974973503046: XenPCI     pfn[0] = 0001b0ac
12974973503046: XenPCI     New Start = 000000001b0ac000, Length = 4096
12974973503046: XenPCI     CmResourceTypeMemory (1)
12974973503046: XenPCI     Start = f2000001, Length = 0
12974973503046: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503062: XenPCI     path = device/vbd/5632
12974973503062: XenPCI     WdfPowerDeviceD3Final
12974973503062: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503062: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503062: XenPCI --> XenPci_UpdateBackendState
12974973503078: XenPCI --> XenConfig_InitConfigPage
12974973503078: XenPCI     Backend State Changed to InitWait
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503078: XenPCI <-- XenPci_UpdateBackendState
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI <-- XenConfig_InitConfigPage
12974973503078: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503078: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503093: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503093: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503093: XenVbd     IRQL = 0
12974973503093: XenVbd     xvdd = FFFFFA80013C8008
12974973503093: XenVbd     BusInterruptLevel = 28
12974973503093: XenVbd     BusInterruptVector = 01c
12974973503093: XenVbd     NumberOfAccessRanges = 1
12974973503093: XenVbd     RangeStart = 1b0ac000, RangeLength = 00001000
12974973503093: XenVbd --> XenVbd_InitConfig
12974973503109: XenVbd     XEN_INIT_TYPE_13
12974973503109: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503109: XenVbd     XEN_INIT_TYPE_11
12974973503109: XenVbd     XEN_INIT_TYPE_17
12974973503109: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
12974973503109: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 9
12974973503109: XenPCI --> XenPci_DeviceWatchHandler
12974973503109: XenPCI --> EvtChn_BindDpc
12974973503109: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- EvtChn_BindDpc
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendState
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_UpdateBackendState
12974973503140: XenPCI     Backend State Changed to Connected
12974973503140: XenPCI <-- XenPci_UpdateBackendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI --> XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503156: XenPCI <-- XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503156: XenVbd <-- XenVbd_InitConfig
12974973503156: XenVbd --> XenVbd_InitFromConfig
12974973503156: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503156: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 00000000013795D0
12974973503156: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503156: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 9 (00000009)
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503156: XenVbd     device-type = CDROM
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503156: XenVbd     mode = r
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 6544648
12974973503171: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503171: XenVbd     qemu_hide_flags_value = 1
12974973503171: XenVbd     Device is inactive
12974973503171: XenVbd <-- XenVbd_InitFromConfig
12974973503171: XenVbd     aligned_buffer_data = FFFFFA80013CA8E8
12974973503171: XenVbd     aligned_buffer = FFFFFA80013CB000
12974973503171: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503171: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503171: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503187: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503187: XenVbd     Dma64BitAddresses supported
12974973503187: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503187: XenVbd --> XenVbd_HwStorInitialize
12974973503187: XenVbd     IRQL = 0
12974973503187: XenVbd     dump_mode = 0
12974973503187: XenVbd <-- XenVbd_HwStorInitialize
12974973503187: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503203: XenPCI     device/vbd/768
12974973503203: XenPCI     CmResourceTypeMemory (0)
12974973503203: XenPCI     Start = f2000000, Length = 0
12974973503203: XenPCI     pfn[0] = 0001afad
12974973503203: XenPCI     New Start = 000000001afad000, Length = 4096
12974973503203: XenPCI     CmResourceTypeMemory (1)
12974973503203: XenPCI     Start = f2000001, Length = 0
12974973503218: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503218: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503234: XenPCI     path = device/vbd/768
12974973503234: XenPCI     WdfPowerDeviceD3Final
12974973503234: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503234: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503234: XenPCI --> XenPci_UpdateBackendState
12974973503234: XenPCI --> XenConfig_InitConfigPage
12974973503234: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503250: XenPCI     Backend State Changed to InitWait
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenPci_UpdateBackendState
12974973503250: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenConfig_InitConfigPage
12974973503250: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503265: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503281: XenVbd     IRQL = 0
12974973503281: XenVbd     xvdd = FFFFFA800141B008
12974973503281: XenVbd     BusInterruptLevel = 28
12974973503281: XenVbd     BusInterruptVector = 01c
12974973503281: XenVbd     NumberOfAccessRanges = 1
12974973503281: XenVbd     RangeStart = 1afad000, RangeLength = 00001000
12974973503281: XenVbd --> XenVbd_InitConfig
12974973503281: XenVbd     XEN_INIT_TYPE_13
12974973503281: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503296: XenVbd     XEN_INIT_TYPE_11
12974973503296: XenVbd     XEN_INIT_TYPE_17
12974973503296: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16382
12974973503296: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 10
12974973503312: XenPCI --> XenPci_DeviceWatchHandler
12974973503328: XenPCI --> EvtChn_BindDpc
12974973503343: XenPCI <-- XenPci_DeviceWatchHandler
12974973503343: XenPCI <-- EvtChn_BindDpc
12974973503343: XenPCI --> XenPci_DeviceWatchHandler
12974973503343: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503375: XenPCI <-- XenPci_DeviceWatchHandler
12974973503375: XenPCI --> XenPci_ChangeFrontendState
12974973503390: XenPCI --> XenPci_DeviceWatchHandler
12974973503390: XenPCI <-- XenPci_DeviceWatchHandler
12974973503390: XenPCI --> XenPci_UpdateBackendState
12974973503406: XenPCI     Backend State Changed to Connected
12974973503406: XenPCI <-- XenPci_UpdateBackendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503406: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503421: XenPCI --> XenPci_ChangeFrontendState
12974973503421: XenPCI <-- XenPci_ChangeFrontendState
12974973503421: XenPCI --> XenPci_DeviceWatchHandler
12974973503421: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503437: XenPCI <-- XenPci_DeviceWatchHandler
12974973503437: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503437: XenVbd <-- XenVbd_InitConfig
12974973503437: XenVbd --> XenVbd_InitFromConfig
12974973503437: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503437: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137B5D0
12974973503437: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503453: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 10 (0000000a)
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = disk
12974973503453: XenVbd     device-type = Disk
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = w
12974973503453: XenVbd     mode = w
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 44038000
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503468: XenVbd     qemu_hide_flags_value = 1
12974973503468: XenVbd <-- XenVbd_InitFromConfig
12974973503468: XenVbd     aligned_buffer_data = FFFFFA800141D8E8
12974973503468: XenVbd     aligned_buffer = FFFFFA800141E000
12974973503484: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503484: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503484: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503484: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503500: XenVbd     Dma64BitAddresses supported
12974973503500: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503515: XenVbd --> XenVbd_HwStorInitialize
12974973503515: XenVbd     IRQL = 0
12974973503515: XenVbd     dump_mode = 0
12974973503515: XenVbd <-- XenVbd_HwStorInitialize
12974973503515: XenVbd --- HwStorStartIo (Still figuring out ring)
12974973503531: XenVbd     ring_detect_state = 1, index = 0, operation
= ff, id = 0, status = -1
12974973503531: XenVbd     req_prod = 2, rsp_prod = 1, rsp_cons = 0
12974973503531: XenVbd     ring_detect_state = 2, index = 1, operation
= ff, id = 0, status = -1
12974973503546: XenVbd     req_prod = 2, rsp_prod = 2, rsp_cons = 1
12974973503656: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973503656: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd     SRB_FUNCTION_PNP
12974973503671: XenVbd      StorQueryCapabilities
12974973503671: XenVbd      SrbPnPFlags = 00000000
12974973503671: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503718: XenPCI     device/vbd/832
12974973503718: XenPCI     CmResourceTypeMemory (0)
12974973503718: XenPCI     Start = f2000000, Length = 0
12974973503718: XenPCI     pfn[0] = 0001afae
12974973503718: XenPCI     New Start = 000000001afae000, Length = 4096
12974973503718: XenPCI     CmResourceTypeMemory (1)
12974973503718: XenPCI     Start = f2000001, Length = 0
12974973503718: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503734: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503734: XenPCI     path = device/vbd/832
12974973503734: XenPCI     WdfPowerDeviceD3Final
12974973503734: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503734: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503734: XenPCI --> XenPci_UpdateBackendState
12974973503750: XenPCI --> XenConfig_InitConfigPage
12974973503750: XenPCI     Backend State Changed to InitWait
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503750: XenPCI <-- XenPci_UpdateBackendState
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI <-- XenConfig_InitConfigPage
12974973503750: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503750: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503750: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503765: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503765: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503765: XenVbd     IRQL = 0
12974973503765: XenVbd     xvdd = FFFFFA8001471008
12974973503765: XenVbd     BusInterruptLevel = 28
12974973503765: XenVbd     BusInterruptVector = 01c
12974973503781: XenVbd     NumberOfAccessRanges = 1
12974973503781: XenVbd     RangeStart = 1afae000, RangeLength = 00001000
12974973503781: XenVbd --> XenVbd_InitConfig
12974973503781: XenVbd     XEN_INIT_TYPE_13
12974973503781: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503796: XenVbd     XEN_INIT_TYPE_11
12974973503796: XenVbd     XEN_INIT_TYPE_17
12974973503796: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16381
12974973503812: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 11
12974973503828: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> EvtChn_BindDpc
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- EvtChn_BindDpc
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendState
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503859: XenPCI --> XenPci_UpdateBackendState
12974973503859: XenPCI     Backend State Changed to Connected
12974973503859: XenPCI <-- XenPci_UpdateBackendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI --> XenPci_DeviceWatchHandler
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503875: XenPCI <-- XenPci_DeviceWatchHandler
12974973503875: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503875: XenVbd <-- XenVbd_InitConfig
12974973503875: XenVbd --> XenVbd_InitFromConfig
12974973503875: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503875: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137C9C0
12974973503875: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503875: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 11 (0000000b)
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503875: XenVbd     device-type = CDROM
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503875: XenVbd     mode = r
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 422560
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503890: XenVbd     qemu_hide_flags_value = 1
12974973503890: XenVbd     Device is inactive
12974973503890: XenVbd <-- XenVbd_InitFromConfig
12974973503890: XenVbd     aligned_buffer_data = FFFFFA80014738E8
12974973503890: XenVbd     aligned_buffer = FFFFFA8001474000
12974973503890: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503890: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503890: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503906: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503906: XenVbd     Dma64BitAddresses supported
12974973503906: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503906: XenVbd --> XenVbd_HwStorInitialize
12974973503906: XenVbd     IRQL = 0
12974973503906: XenVbd     dump_mode = 0
12974973503906: XenVbd <-- XenVbd_HwStorInitialize
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503921: XenVbd     SRB_FUNCTION_IO_CONTROL
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 28, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503937: XenVbd     SRB_FUNCTION_PNP
12974973503937: XenVbd      StorQueryCapabilities
12974973503937: XenVbd      SrbPnPFlags = 00000000
12974973504203: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973504218: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973505265: Trying to enable physical device already in use.
12974973524343: XenNet --> DriverEntry
12974973524343: XenNet     Driver MajorNdisVersion = 6, Driver
MinorNdisVersion = 1
12974973524359: XenNet     Windows MajorNdisVersion = 6, Windows
MinorNdisVersion = 20
12974973524359: XenNet --> XenNet_SetOptions
12974973524359: XenNet <-- XenNet_SetOptions
12974973524359: XenNet <-- DriverEntry
12974973524359: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524375: XenPCI     device/vif/0
12974973524375: XenPCI     CmResourceTypeMemory (0)
12974973524375: XenPCI     Start = f2000000, Length = 0
12974973524375: XenPCI     pfn[0] = 0001afaf
12974973524375: XenPCI     New Start = 000000001afaf000, Length = 4096
12974973524375: XenPCI     CmResourceTypeMemory (1)
12974973524390: XenPCI     Start = f2000001, Length = 0
12974973524390: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524390: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973524390: XenPCI     path = device/vif/0
12974973524406: XenPCI     WdfPowerDeviceD3Final
12974973524406: XenPCI --> XenPci_GetBackendAndAddWatch
12974973524406: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973524406: XenPCI --> XenPci_UpdateBackendState
12974973524421: XenPCI --> XenConfig_InitConfigPage
12974973524421: XenPCI     Backend State Changed to InitWait
12974973524421: XenPCI     fdo_driver_object = FFFFFA8001BB7060
12974973524421: XenPCI <-- XenPci_UpdateBackendState
12974973524421: XenPCI     fdo_driver_extension = 0000000000000000
12974973524421: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973524437: XenPCI     fdo_driver_extension = 0000000000000000
12974973524437: XenPCI <-- XenConfig_InitConfigPage
12974973524437: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524437: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524437: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524453: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973524468: XenNet --> XenNet_Initialize
12974973524468: XenNet     XEN_INIT_TYPE_13
12974973524468: XenNet     XEN_INIT_TYPE_VECTORS
12974973524468: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524468: ScatterGather = 1
12974973524468: LargeSendOffload = 61440
12974973524500: LargeSendOffloadRxSplitMTU = 1
12974973524500: ChecksumOffload = 1
12974973524500: MTU = 1500
12974973524515: Could not read NetworkAddress value (c0000001) or
value is invalid
12974973524515: XenNet --> XenNet_D0Entry
12974973524515: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = 16380
12974973524531: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524546: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = 16379
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524562: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI --> EvtChn_Bind
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI <-- EvtChn_Bind
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendState
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_UpdateBackendState
12974973524593: XenPCI     Backend State Changed to Connected
12974973524593: XenPCI <-- XenPci_UpdateBackendState
12974973524593: XenPCI <-- XenPci_ChangeFrontendState
12974973524609: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524609: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524609: XenNet --> XenNet_ConnectBackend
12974973524609: XenNet     XEN_INIT_TYPE_13
12974973524609: XenNet     XEN_INIT_TYPE_VECTORS
12974973524609: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524609: XenNet     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524609: XenNet     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524609: XenNet     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - mac = 00:16:3e:00:17:b9
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - feature-sg = 1
12974973524625: XenNet     XEN_INIT_TYPE_READ_STRING - feature-gso-tcpv4 = 1
12974973524625: XenNet     XEN_INIT_TYPE_17
12974973524625: XenNet <-- XenNet_ConnectBackend
12974973524625: XenNet --> XenNet_RxInit
12974973524625: XenNet <-- XenNet_RxInit
12974973524625: XenNet <-- XenNet_D0Entry
12974973524640: XenNet     Supporting 00010102
(OID_GEN_HARDWARE_STATUS) get only 4 bytes
12974973524640: XenNet     Supporting 00010108
(OID_GEN_TRANSMIT_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 00010109
(OID_GEN_RECEIVE_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010a
(OID_GEN_TRANSMIT_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010b
(OID_GEN_RECEIVE_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010c (OID_GEN_VENDOR_ID) get
only 4 bytes
12974973524656: XenNet     Supporting 0001010d
(OID_GEN_VENDOR_DESCRIPTION) get only 10 bytes
12974973524656: XenNet     Supporting 00010116
(OID_GEN_VENDOR_DRIVER_VERSION) get only 4 bytes
12974973524656: XenNet     Supporting 0001010e
(OID_GEN_CURRENT_PACKET_FILTER) get/set 4 bytes
12974973524656: XenNet     Supporting 0001010f
(OID_GEN_CURRENT_LOOKAHEAD) get/set 4 bytes
12974973524656: XenNet     Supporting 00010111
(OID_GEN_MAXIMUM_TOTAL_SIZE) get only 4 bytes
12974973524656: XenNet     Supporting 00010208
(OID_GEN_LINK_PARAMETERS) set only 32 bytes
12974973524656: XenNet     Supporting 00010209
(OID_GEN_INTERRUPT_MODERATION) get/set 12 bytes
12974973524671: XenNet     Supporting 00010115
(OID_GEN_MAXIMUM_SEND_PACKETS) get only 4 bytes
12974973524671: XenNet     Supporting 00010103
(OID_GEN_MEDIA_SUPPORTED) get only 4 bytes
12974973524671: XenNet     Supporting 00010104 (OID_GEN_MEDIA_IN_USE)
get only 4 bytes
12974973524671: XenNet     Supporting 00010105
(OID_GEN_MAXIMUM_LOOKAHEAD) get only 4 bytes
12974973524671: XenNet     Supporting 00010118
(OID_GEN_NETWORK_LAYER_ADDRESSES) set only 6 bytes
12974973524671: XenNet     Supporting 0001021a (OID_GEN_MACHINE_NAME)
set only 0 bytes
12974973524687: XenNet     Supporting 0101010a
(OID_OFFLOAD_ENCAPSULATION) set only 28 bytes
12974973524687: XenNet     Supporting fd010101 (OID_PNP_SET_POWER) set
only 4 bytes
12974973524687: XenNet     Supporting 00020101 (OID_GEN_XMIT_OK) get
only 0 bytes
12974973524687: XenNet     Supporting 00020102 (OID_GEN_RCV_OK) get only 0 bytes
12974973524687: XenNet     Supporting 00020103 (OID_GEN_XMIT_ERROR)
get only 0 bytes
12974973524703: XenNet     Supporting 00020104 (OID_GEN_RCV_ERROR) get
only 0 bytes
12974973524703: XenNet     Supporting 00020105 (OID_GEN_RCV_NO_BUFFER)
get only 0 bytes
12974973524703: XenNet     Supporting 01020101
(OID_802_3_RCV_ERROR_ALIGNMENT) get only 0 bytes
12974973524703: XenNet     Supporting 01020102
(OID_802_3_XMIT_ONE_COLLISION) get only 0 bytes
12974973524703: XenNet     Supporting 01020103
(OID_802_3_XMIT_MORE_COLLISIONS) get only 0 bytes
12974973524703: XenNet     Supporting fc010209 (OID_IP4_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting fc01020a (OID_IP6_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting 00020106 (OID_GEN_STATISTICS)
get only 152 bytes
12974973524718: XenNet     Supporting 01010101
(OID_802_3_PERMANENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010102
(OID_802_3_CURRENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010103
(OID_802_3_MULTICAST_LIST) get/set 0 bytes
12974973524734: XenNet     Supporting 01010104
(OID_802_3_MAXIMUM_LIST_SIZE) get only 4 bytes
12974973524734: XenNet     name = minint-ps2nl91
12974973524734: XenNet --> XenNet_Restart
12974973524734: XenNet <-- XenNet_Restart
12974973524734: XenNet --> XenNet_DevicePnPEventNotify
12974973524734: XenNet     NdisDevicePnPEventPowerProfileChanged
12974973524734: XenNet <-- XenNet_DevicePnPEventNotify
12974973524734: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 62 (FFFFFA8001BB9000)
12974973524750: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524750: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524750: XenNet     Unsupported OID 00010117
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524781: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 82 (FFFFFA8001BB9000)
12974973524781: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524796: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524796: XenNet     NDIS_PACKET_TYPE_BROADCAST
12974973524796: XenNet      IPv4.Enabled = NDIS_OFFLOAD_SET_ON
12974973524796: XenNet      IPv4.HeaderSize = 14
12974973524796: XenNet      IPv6.EncapsulationType = 0
12974973524796: XenNet      IPv6.Enabled = NDIS_OFFLOAD_SET_OFF
12974973524812: XenNet      IPv6.HeaderSize = 0
12974973534531: XenNet     AddressType = 2
12974973534531: XenNet     AddressCount = 1
12974973534531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973534531: XenNet     Address[0].Length = 16
12974973534531: XenNet     Address[0].in_addr = 169.254.239.84
12974973586906: XenPCI --> XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoWrite
12974973586921: XenPCI     36 bytes of write buffer remaining
12974973586921: XenPCI     completing request with length 36
12974973586921: XenPCI <-- XenBus_EvtIoWrite
12974973586921: XenPCI <-- XenPci_EvtIoDefault
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoRead
12974973586921: XenPCI     found pending read
12974973586937: XenPCI <-- XenBus_ProcessReadRequest
12974973586937: XenPCI <-- XenBus_EvtIoRead
12974973586937: XenPCI <-- XenPci_EvtIoDefault
12974973586937: XenPCI --> XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenPci_EvtFileClose
12974973586937: XenPCI --> XenBus_EvtFileClose
12974973586937: XenPCI <-- XenBus_EvtFileClose
12974973586937: XenPCI <-- XenPci_EvtFileClose
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591531: XenNet     Address[0].Length = 16
12974973591531: XenNet     Address[0].in_addr = 62.76.47.68
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591546: XenNet     Address[0].Length = 16
12974973591546: XenNet     Address[0].in_addr = 62.76.47.68
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973612640: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613343: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613390: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613453: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613468: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613500: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613531: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613812: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613859: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613890: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613953: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613968: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614015: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973618406: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629718: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629750: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629765: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973635718: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973640703: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973648015: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973652000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 11:01:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 11:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG6um-0000bF-Q3; Fri, 06 Apr 2012 11:01:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1SG6ul-0000b4-4j
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 11:01:11 +0000
Received: from [85.158.143.35:56075] by server-2.bemta-4.messagelabs.com id
	C1/8A-17550-6FCCE7F4; Fri, 06 Apr 2012 11:01:10 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-10.tower-21.messagelabs.com!1333710066!11332868!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11746 invoked from network); 6 Apr 2012 11:01:07 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 11:01:07 -0000
Received: by lagr15 with SMTP id r15so2540279lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 04:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=aTNzS1xsTTxA2wvEfkX4knzXtgP6o+FcLpZCelEv1po=;
	b=U7qFf/TOaGqbckEpRTsFosb69UCk/tnSLF82hmrvXssPzFQ10czZHmzLAwCU63Qrg3
	Gxywb7lP+tMZY1Ne8N8qtBmDXgb5SnknVpH1Z4+Kkw74xeDTNJQaD/Us2AAr9b2s6mpi
	UvJa7m0aWUiyQsemx5bAmRgbzlKPkbekJVpdg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=aTNzS1xsTTxA2wvEfkX4knzXtgP6o+FcLpZCelEv1po=;
	b=dzN6l8D5E9W3Cmf2vg+utj45YslW34dQlQ251lw3cL+nuqa8yVYvyobPMp1xH69/xR
	7snZGFzfmdfiSK+vARCa8uUhoRSpOvqZSx9KltJNStSiYzZexqTwnd6Bt76eALOz/u7c
	8obTOImCGxSgPgXXYKurssBHBxuS8aECnmUZh6tn2kwS7L0rbBrXtfvy5PbbKDVfVLaf
	LSDYKIEBP3ZgaMncSoY21ATHGsmT/XGF6M7Hf/MQgHMsFQjtOpE7mX8x3078wlXioln6
	ZYlGcBR4LlICfRcZwKIzUyGBNx5LhEtZ+p48h4MEPkJ+YCT0yLQ/8tbei/J4yJm5B9h9
	wD9Q==
Received: by 10.152.132.6 with SMTP id oq6mr7996176lab.44.1333710066260; Fri,
	06 Apr 2012 04:01:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.37.234 with HTTP; Fri, 6 Apr 2012 04:00:51 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
References: <201109090950.05043.muehlenhoff@univention.de>
	<201109141814.29461.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B10AD86AC@BITCOM1.int.sbss.com.au>
	<201203270952.56490.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 6 Apr 2012 15:00:51 +0400
X-Google-Sender-Auth: Pz6kGfqNstRR9tjF438zf4mcKa0
Message-ID: <CACaajQv4afgmrHO6F8DqHoePMqPMyWD7OjXnZmh=NKir8ipfnA@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQkMyvEY5XQ3uuZHB5GUQxj6+EM0zykOPy83In477+Y3xeKZKey30PNqOiksi6/Sa3UdJKjR
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/4/6 James Harper <james.harper@bendigoit.com.au>:
>
> What are you testing this with? I just ran some tests with iometer under 2008R2 and it reminded me of something... DRBD *hates* having outstanding writes to the same block, and complains about it, so gplpv serialises such requests (stalling the queue until the first request is complete). This almost never happens in production but iometer sends such requests frequently, which will significantly impact performance.
>
> You can test with the debug build to see if this is happening with whatever you are testing with - you'll see messages like "Concurrent outstanding write detected". Be aware though that qemu will rate limit writes to the debug log so if it happens a lot (like under iometer) it will slow to a crawl.
>
> James
>

Sorry, but i have another problem with disk write when use gplpv:

 I'm create simple winpe windows installer with windows aik and
integrate into it xen gpl pv drivers. Sometimes i can't install
windows to hard drive.
Windows syas, that hard disk not properly configured in bios or not
able to boot from it.
Disk is the phisical device, domU config:

kernel='hvmloader'
builder='hvm'
memory=1024
name="21-706"
vcpus=4
vif="mac=00:16:3e:00:17:b9,ip=62.76.47.68,type=paravirtualised"
disk="file:/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso,hdc:cdrom,r"
disk="phy:/dev/disk/vbd/21-1206,hda,w"
device_model='qemu-dm'
boot='c'
vnc=1
vncpasswd='uRFCg8oPkD'
serial='pty'
usbdevice='tablet'
keymap='en-us'
boot='d'
-p
disk="file:/var/storage/iso/winpe_amd64.iso,hdb:cdrom,r"
on_reboot=destroy
on_poweroff=destroy
on_crash=destroy

qemu-dm log conains this messages:

domid: 1155
Using file /var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
in read-only mode
Using file /dev/disk/vbd/21-1206 in read-write mode
Using file /var/storage/iso/winpe_amd64.iso in read-only mode
Watching /local/domain/0/device-model/1155/logdirty/cmd
Watching /local/domain/0/device-model/1155/command
char device redirected to /dev/pts/59
qemu_map_cache_init nr_buckets = 10000 size 4194304
/usr/src/packages/BUILD/xen-4.0.1-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
Init blktap pipes
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 64ebb4f3-827b-4bbd-3ada-358b66e61a95
Time offset set 0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/1155/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 0):
/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdb' (index: 2): /var/storage/iso/winpe_amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/1155/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
log_throttling disabled
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
12974973492593: XenPCI --> XenPci_InitialBalloonDown
12974973492593: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492593: XenPCI     Xen Version 4.0
12974973492593: XenPCI     Hypercall area at FFFFFA80010B7000
12974973492593: XenPCI     XENMEM_maximum_reservation = 263168
12974973492593: XenPCI     XENMEM_current_reservation = 263160
12974973492593: XenPCI     Trying to give 32 KB (0 MB) to Xen
12974973492609: XenPCI <-- XenPci_InitialBalloonDown
12974973492609: XenPCI     KeInitializeCrashDumpHeader status =
00000000, size = 8192
12974973492609: XenPCI GPLPV 0.10.0.357
12974973492609: XenPCI --> XenPci_FixLoadOrder
12974973492609: XenPCI     dummy_group_index = -1
12974973492609: XenPCI     wdf_load_group_index = 2
12974973492609: XenPCI     xenpci_group_index = -1
12974973492609: XenPCI     boot_bus_extender_index = 3
12974973492609: XenPCI <-- XenPci_FixLoadOrder
12974973492609: XenPCI     SystemStartOptions =  MININT  REDIRECT
RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088
RDPATH=MULTI(0)DISK(0)CDROM(0)\SOURCES\BOOT.WIM
12974973492625: XenPCI     Version = 1
Unknown PV product 2 loaded in guest
PV driver build 1
12974973492625: XenPCI     Disabled qemu devices 01
12974973492625: XenPCI <-- DriverEntry
12974973492625: XenPCI     Xen PCI device found - must be fdo
12974973492625: XenPCI --> XenPci_EvtDeviceAdd_XenPci
12974973492625: XenPCI <-- XenPci_EvtDeviceAdd_XenPci
12974973492640: XenPCI --> XenPci_EvtDevicePrepareHardware
12974973492640: XenPCI     IoPort Address(c000) Length: 256
12974973492640: XenPCI     Private Data: 0x01 0x00 0x00
12974973492640: XenPCI     Memory mapped CSR:(f2000000:0) Length:(16777216)
12974973492640: XenPCI     Memory flags = 0084
12974973492640: XenPCI     Private Data: 0x01 0x01 0x00
12974973492640: XenPCI     irq_number = 01c
12974973492640: XenPCI     irq_vector = 0a2
12974973492640: XenPCI     irq_level = 00a
12974973492640: XenPCI     irq_mode = LevelSensitive
12974973492656: XenPCI     ShareDisposition = CmResourceShareShared
12974973492656: XenPCI <-- XenPci_EvtDevicePrepareHardware
12974973492656: XenPCI --> XenPci_EvtDeviceD0Entry
12974973492656: XenPCI     WdfPowerDeviceD3Final
12974973492656: XenPCI --> XenPci_Init
12974973492656: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492656: XenPCI     Xen Version 4.0
12974973492656: XenPCI     Hypercall area at FFFFFA80011BD000
12974973492656: XenPCI     shared_info_area_unmapped.QuadPart = f2000000
12974973492656: XenPCI     gpfn = f2000
12974973492656: XenPCI     hypervisor memory op
(XENMAPSPACE_shared_info) ret = 0
12974973492671: XenPCI <-- XenPci_Init
12974973492671: XenPCI --> GntTbl_Init
12974973492671: XenPCI     grant_frames = 32
12974973492671: XenPCI     grant_entries = 16384
12974973492671: XenPCI     pfn = 3fa1e
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1e
12974973492671: XenPCI     decreased 1 pages for grant table frame 0
12974973492671: XenPCI     pfn = 3fa1f
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1f
12974973492671: XenPCI     decreased 1 pages for grant table frame 1
12974973492671: XenPCI     pfn = 3fa20
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa20
12974973492687: XenPCI     decreased 1 pages for grant table frame 2
12974973492687: XenPCI     pfn = 3fa21
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa21
12974973492687: XenPCI     decreased 1 pages for grant table frame 3
12974973492687: XenPCI     pfn = 3fa22
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa22
12974973492687: XenPCI     decreased 1 pages for grant table frame 4
12974973492687: XenPCI     pfn = 3fa23
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa23
12974973492703: XenPCI     decreased 1 pages for grant table frame 5
12974973492703: XenPCI     pfn = 3fa24
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa24
12974973492703: XenPCI     decreased 1 pages for grant table frame 6
12974973492703: XenPCI     pfn = 3fa25
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa25
12974973492703: XenPCI     decreased 1 pages for grant table frame 7
12974973492718: XenPCI     pfn = 3fa26
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa26
12974973492718: XenPCI     decreased 1 pages for grant table frame 8
12974973492718: XenPCI     pfn = 3fa27
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa27
12974973492718: XenPCI     decreased 1 pages for grant table frame 9
12974973492718: XenPCI     pfn = 3fa28
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa28
12974973492718: XenPCI     decreased 1 pages for grant table frame 10
12974973492734: XenPCI     pfn = 3fa29
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa29
12974973492734: XenPCI     decreased 1 pages for grant table frame 11
12974973492734: XenPCI     pfn = 3fa2a
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2a
12974973492734: XenPCI     decreased 1 pages for grant table frame 12
12974973492734: XenPCI     pfn = 3fa2b
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2b
12974973492750: XenPCI     decreased 1 pages for grant table frame 13
12974973492750: XenPCI     pfn = 3fa2c
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2c
12974973492750: XenPCI     decreased 1 pages for grant table frame 14
12974973492750: XenPCI     pfn = 3fa2d
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2d
12974973492750: XenPCI     decreased 1 pages for grant table frame 15
12974973492750: XenPCI     pfn = 3fa2e
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2e
12974973492765: XenPCI     decreased 1 pages for grant table frame 16
12974973492765: XenPCI     pfn = 3fa2f
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2f
12974973492765: XenPCI     decreased 1 pages for grant table frame 17
12974973492765: XenPCI     pfn = 3fa30
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa30
12974973492765: XenPCI     decreased 1 pages for grant table frame 18
12974973492765: XenPCI     pfn = 3fa31
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa31
12974973492765: XenPCI     decreased 1 pages for grant table frame 19
12974973492781: XenPCI     pfn = 3fa32
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa32
12974973492781: XenPCI     decreased 1 pages for grant table frame 20
12974973492781: XenPCI     pfn = 3fa33
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa33
12974973492781: XenPCI     decreased 1 pages for grant table frame 21
12974973492781: XenPCI     pfn = 3fa34
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa34
12974973492796: XenPCI     decreased 1 pages for grant table frame 22
12974973492796: XenPCI     pfn = 3fa35
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa35
12974973492796: XenPCI     decreased 1 pages for grant table frame 23
12974973492796: XenPCI     pfn = 3fa36
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa36
12974973492796: XenPCI     decreased 1 pages for grant table frame 24
12974973492796: XenPCI     pfn = 3fa37
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa37
12974973492812: XenPCI     decreased 1 pages for grant table frame 25
12974973492812: XenPCI     pfn = 3fa38
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa38
12974973492812: XenPCI     decreased 1 pages for grant table frame 26
12974973492812: XenPCI     pfn = 3fa39
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa39
12974973492812: XenPCI     decreased 1 pages for grant table frame 27
12974973492812: XenPCI     pfn = 3fa3a
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3a
12974973492828: XenPCI     decreased 1 pages for grant table frame 28
12974973492828: XenPCI     pfn = 3fa3b
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3b
12974973492828: XenPCI     decreased 1 pages for grant table frame 29
12974973492828: XenPCI     pfn = 3fa3c
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3c
12974973492828: XenPCI     decreased 1 pages for grant table frame 30
12974973492828: XenPCI     pfn = 3fa3d
12974973492843: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3d
12974973492843: XenPCI     decreased 1 pages for grant table frame 31
12974973492859: XenPCI --> GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Init
12974973492875: XenPCI --> EvtChn_Init
12974973492875: XenPCI --> _hvm_set_parameter
12974973492890: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492890: XenPCI <-- _hvm_set_parameter
12974973492890: XenPCI     hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0
12974973492890: XenPCI --> EvtChn_AllocIpi
12974973492890: XenPCI <-- EvtChn_AllocIpi
12974973492890: XenPCI --> EvtChn_BindDpc
12974973492890: XenPCI <-- EvtChn_BindDpc
12974973492890: XenPCI     pdo_event_channel = 7
12974973492890: XenPCI <-- EvtChn_Init
12974973492890: XenPCI <-- XenPci_EvtDeviceD0Entry
12974973492890: XenPCI --> EvtChn_EvtInterruptEnable
12974973492890: XenPCI <-- EvtChn_EvtInterruptEnable
12974973492906: XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492906: XenPCI --> XenBus_Init
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI <-- XenBus_Init
12974973492906: XenPCI     suspend event channel = 8
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI --> XenPci_SysrqHandler
12974973492906: XenPCI     SysRq Value = (null)
12974973492921: XenPCI <-- XenPci_SysrqHandler
12974973492921: XenPCI --> XenPci_ShutdownHandler
12974973492921: XenPCI     Initial Memory Value = 1048576 (1048576)
12974973492953: Error reading shutdown path - ENOENT
12974973492953: XenPCI <-- XenPci_ShutdownHandler
12974973492953: XenPCI --> XenPci_BalloonThreadProc
12974973492953: XenPCI --> XenPci_DeviceWatchHandler
12974973492953: XenPCI     low_mem_event = FFFFFA8000C865C0, state = 0
12974973492953: XenPCI <-- XenPci_DeviceWatchHandler
12974973492953: XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492953: XenPCI --> XenPci_BalloonHandler
12974973492953: XenPCI --> XenPci_EvtChildListScanForChildren
12974973492953: XenPCI     target memory value = 1048576 (1048576)
12974973492953: XenPCI     Found path = device/vfb/0
12974973492953: XenPCI     Got balloon event, current = 1048576,
target = 1048576
12974973492968: XenPCI     Found path = device/vbd/5632
12974973492968: XenPCI     No change to memory
12974973492968: XenPCI <-- XenPci_BalloonHandler
12974973492968: XenPCI     Found path = device/vbd/768
12974973492968: XenPCI     Found path = device/vbd/832
12974973492968: XenPCI     Found path = device/vif/0
12974973492968: XenPCI     Found path = device/suspend/event-channel
12974973492968: XenPCI <-- XenPci_EvtChildListScanForChildren
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492968: XenPCI     device = 'vfb', index = '0', path = 'device/vfb/0'
12974973492968: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '5632', path =
'device/vbd/5632'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '768', path =
'device/vbd/768'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '832', path =
'device/vbd/832'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vif', index = '0', path = 'device/vif/0'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973493000: XenPCI     device = 'suspend', index = '0', path =
'device/suspend/event-channel'
12974973493000: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973503046: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI     device/vbd/5632
12974973503046: XenPCI     CmResourceTypeMemory (0)
12974973503046: XenPCI     Start = f2000000, Length = 0
12974973503046: XenPCI     pfn[0] = 0001b0ac
12974973503046: XenPCI     New Start = 000000001b0ac000, Length = 4096
12974973503046: XenPCI     CmResourceTypeMemory (1)
12974973503046: XenPCI     Start = f2000001, Length = 0
12974973503046: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503062: XenPCI     path = device/vbd/5632
12974973503062: XenPCI     WdfPowerDeviceD3Final
12974973503062: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503062: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503062: XenPCI --> XenPci_UpdateBackendState
12974973503078: XenPCI --> XenConfig_InitConfigPage
12974973503078: XenPCI     Backend State Changed to InitWait
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503078: XenPCI <-- XenPci_UpdateBackendState
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI <-- XenConfig_InitConfigPage
12974973503078: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503078: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503093: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503093: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503093: XenVbd     IRQL = 0
12974973503093: XenVbd     xvdd = FFFFFA80013C8008
12974973503093: XenVbd     BusInterruptLevel = 28
12974973503093: XenVbd     BusInterruptVector = 01c
12974973503093: XenVbd     NumberOfAccessRanges = 1
12974973503093: XenVbd     RangeStart = 1b0ac000, RangeLength = 00001000
12974973503093: XenVbd --> XenVbd_InitConfig
12974973503109: XenVbd     XEN_INIT_TYPE_13
12974973503109: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503109: XenVbd     XEN_INIT_TYPE_11
12974973503109: XenVbd     XEN_INIT_TYPE_17
12974973503109: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
12974973503109: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 9
12974973503109: XenPCI --> XenPci_DeviceWatchHandler
12974973503109: XenPCI --> EvtChn_BindDpc
12974973503109: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- EvtChn_BindDpc
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendState
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_UpdateBackendState
12974973503140: XenPCI     Backend State Changed to Connected
12974973503140: XenPCI <-- XenPci_UpdateBackendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI --> XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503156: XenPCI <-- XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503156: XenVbd <-- XenVbd_InitConfig
12974973503156: XenVbd --> XenVbd_InitFromConfig
12974973503156: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503156: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 00000000013795D0
12974973503156: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503156: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 9 (00000009)
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503156: XenVbd     device-type = CDROM
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503156: XenVbd     mode = r
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 6544648
12974973503171: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503171: XenVbd     qemu_hide_flags_value = 1
12974973503171: XenVbd     Device is inactive
12974973503171: XenVbd <-- XenVbd_InitFromConfig
12974973503171: XenVbd     aligned_buffer_data = FFFFFA80013CA8E8
12974973503171: XenVbd     aligned_buffer = FFFFFA80013CB000
12974973503171: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503171: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503171: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503187: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503187: XenVbd     Dma64BitAddresses supported
12974973503187: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503187: XenVbd --> XenVbd_HwStorInitialize
12974973503187: XenVbd     IRQL = 0
12974973503187: XenVbd     dump_mode = 0
12974973503187: XenVbd <-- XenVbd_HwStorInitialize
12974973503187: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503203: XenPCI     device/vbd/768
12974973503203: XenPCI     CmResourceTypeMemory (0)
12974973503203: XenPCI     Start = f2000000, Length = 0
12974973503203: XenPCI     pfn[0] = 0001afad
12974973503203: XenPCI     New Start = 000000001afad000, Length = 4096
12974973503203: XenPCI     CmResourceTypeMemory (1)
12974973503203: XenPCI     Start = f2000001, Length = 0
12974973503218: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503218: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503234: XenPCI     path = device/vbd/768
12974973503234: XenPCI     WdfPowerDeviceD3Final
12974973503234: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503234: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503234: XenPCI --> XenPci_UpdateBackendState
12974973503234: XenPCI --> XenConfig_InitConfigPage
12974973503234: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503250: XenPCI     Backend State Changed to InitWait
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenPci_UpdateBackendState
12974973503250: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenConfig_InitConfigPage
12974973503250: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503265: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503281: XenVbd     IRQL = 0
12974973503281: XenVbd     xvdd = FFFFFA800141B008
12974973503281: XenVbd     BusInterruptLevel = 28
12974973503281: XenVbd     BusInterruptVector = 01c
12974973503281: XenVbd     NumberOfAccessRanges = 1
12974973503281: XenVbd     RangeStart = 1afad000, RangeLength = 00001000
12974973503281: XenVbd --> XenVbd_InitConfig
12974973503281: XenVbd     XEN_INIT_TYPE_13
12974973503281: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503296: XenVbd     XEN_INIT_TYPE_11
12974973503296: XenVbd     XEN_INIT_TYPE_17
12974973503296: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16382
12974973503296: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 10
12974973503312: XenPCI --> XenPci_DeviceWatchHandler
12974973503328: XenPCI --> EvtChn_BindDpc
12974973503343: XenPCI <-- XenPci_DeviceWatchHandler
12974973503343: XenPCI <-- EvtChn_BindDpc
12974973503343: XenPCI --> XenPci_DeviceWatchHandler
12974973503343: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503375: XenPCI <-- XenPci_DeviceWatchHandler
12974973503375: XenPCI --> XenPci_ChangeFrontendState
12974973503390: XenPCI --> XenPci_DeviceWatchHandler
12974973503390: XenPCI <-- XenPci_DeviceWatchHandler
12974973503390: XenPCI --> XenPci_UpdateBackendState
12974973503406: XenPCI     Backend State Changed to Connected
12974973503406: XenPCI <-- XenPci_UpdateBackendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503406: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503421: XenPCI --> XenPci_ChangeFrontendState
12974973503421: XenPCI <-- XenPci_ChangeFrontendState
12974973503421: XenPCI --> XenPci_DeviceWatchHandler
12974973503421: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503437: XenPCI <-- XenPci_DeviceWatchHandler
12974973503437: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503437: XenVbd <-- XenVbd_InitConfig
12974973503437: XenVbd --> XenVbd_InitFromConfig
12974973503437: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503437: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137B5D0
12974973503437: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503453: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 10 (0000000a)
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = disk
12974973503453: XenVbd     device-type = Disk
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = w
12974973503453: XenVbd     mode = w
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 44038000
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503468: XenVbd     qemu_hide_flags_value = 1
12974973503468: XenVbd <-- XenVbd_InitFromConfig
12974973503468: XenVbd     aligned_buffer_data = FFFFFA800141D8E8
12974973503468: XenVbd     aligned_buffer = FFFFFA800141E000
12974973503484: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503484: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503484: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503484: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503500: XenVbd     Dma64BitAddresses supported
12974973503500: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503515: XenVbd --> XenVbd_HwStorInitialize
12974973503515: XenVbd     IRQL = 0
12974973503515: XenVbd     dump_mode = 0
12974973503515: XenVbd <-- XenVbd_HwStorInitialize
12974973503515: XenVbd --- HwStorStartIo (Still figuring out ring)
12974973503531: XenVbd     ring_detect_state = 1, index = 0, operation
= ff, id = 0, status = -1
12974973503531: XenVbd     req_prod = 2, rsp_prod = 1, rsp_cons = 0
12974973503531: XenVbd     ring_detect_state = 2, index = 1, operation
= ff, id = 0, status = -1
12974973503546: XenVbd     req_prod = 2, rsp_prod = 2, rsp_cons = 1
12974973503656: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973503656: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd     SRB_FUNCTION_PNP
12974973503671: XenVbd      StorQueryCapabilities
12974973503671: XenVbd      SrbPnPFlags = 00000000
12974973503671: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503718: XenPCI     device/vbd/832
12974973503718: XenPCI     CmResourceTypeMemory (0)
12974973503718: XenPCI     Start = f2000000, Length = 0
12974973503718: XenPCI     pfn[0] = 0001afae
12974973503718: XenPCI     New Start = 000000001afae000, Length = 4096
12974973503718: XenPCI     CmResourceTypeMemory (1)
12974973503718: XenPCI     Start = f2000001, Length = 0
12974973503718: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503734: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503734: XenPCI     path = device/vbd/832
12974973503734: XenPCI     WdfPowerDeviceD3Final
12974973503734: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503734: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503734: XenPCI --> XenPci_UpdateBackendState
12974973503750: XenPCI --> XenConfig_InitConfigPage
12974973503750: XenPCI     Backend State Changed to InitWait
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503750: XenPCI <-- XenPci_UpdateBackendState
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI <-- XenConfig_InitConfigPage
12974973503750: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503750: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503750: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503765: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503765: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503765: XenVbd     IRQL = 0
12974973503765: XenVbd     xvdd = FFFFFA8001471008
12974973503765: XenVbd     BusInterruptLevel = 28
12974973503765: XenVbd     BusInterruptVector = 01c
12974973503781: XenVbd     NumberOfAccessRanges = 1
12974973503781: XenVbd     RangeStart = 1afae000, RangeLength = 00001000
12974973503781: XenVbd --> XenVbd_InitConfig
12974973503781: XenVbd     XEN_INIT_TYPE_13
12974973503781: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503796: XenVbd     XEN_INIT_TYPE_11
12974973503796: XenVbd     XEN_INIT_TYPE_17
12974973503796: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16381
12974973503812: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 11
12974973503828: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> EvtChn_BindDpc
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- EvtChn_BindDpc
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendState
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503859: XenPCI --> XenPci_UpdateBackendState
12974973503859: XenPCI     Backend State Changed to Connected
12974973503859: XenPCI <-- XenPci_UpdateBackendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI --> XenPci_DeviceWatchHandler
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503875: XenPCI <-- XenPci_DeviceWatchHandler
12974973503875: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503875: XenVbd <-- XenVbd_InitConfig
12974973503875: XenVbd --> XenVbd_InitFromConfig
12974973503875: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503875: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137C9C0
12974973503875: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503875: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 11 (0000000b)
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503875: XenVbd     device-type = CDROM
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503875: XenVbd     mode = r
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 422560
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503890: XenVbd     qemu_hide_flags_value = 1
12974973503890: XenVbd     Device is inactive
12974973503890: XenVbd <-- XenVbd_InitFromConfig
12974973503890: XenVbd     aligned_buffer_data = FFFFFA80014738E8
12974973503890: XenVbd     aligned_buffer = FFFFFA8001474000
12974973503890: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503890: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503890: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503906: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503906: XenVbd     Dma64BitAddresses supported
12974973503906: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503906: XenVbd --> XenVbd_HwStorInitialize
12974973503906: XenVbd     IRQL = 0
12974973503906: XenVbd     dump_mode = 0
12974973503906: XenVbd <-- XenVbd_HwStorInitialize
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503921: XenVbd     SRB_FUNCTION_IO_CONTROL
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 28, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503937: XenVbd     SRB_FUNCTION_PNP
12974973503937: XenVbd      StorQueryCapabilities
12974973503937: XenVbd      SrbPnPFlags = 00000000
12974973504203: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973504218: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973505265: Trying to enable physical device already in use.
12974973524343: XenNet --> DriverEntry
12974973524343: XenNet     Driver MajorNdisVersion = 6, Driver
MinorNdisVersion = 1
12974973524359: XenNet     Windows MajorNdisVersion = 6, Windows
MinorNdisVersion = 20
12974973524359: XenNet --> XenNet_SetOptions
12974973524359: XenNet <-- XenNet_SetOptions
12974973524359: XenNet <-- DriverEntry
12974973524359: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524375: XenPCI     device/vif/0
12974973524375: XenPCI     CmResourceTypeMemory (0)
12974973524375: XenPCI     Start = f2000000, Length = 0
12974973524375: XenPCI     pfn[0] = 0001afaf
12974973524375: XenPCI     New Start = 000000001afaf000, Length = 4096
12974973524375: XenPCI     CmResourceTypeMemory (1)
12974973524390: XenPCI     Start = f2000001, Length = 0
12974973524390: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524390: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973524390: XenPCI     path = device/vif/0
12974973524406: XenPCI     WdfPowerDeviceD3Final
12974973524406: XenPCI --> XenPci_GetBackendAndAddWatch
12974973524406: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973524406: XenPCI --> XenPci_UpdateBackendState
12974973524421: XenPCI --> XenConfig_InitConfigPage
12974973524421: XenPCI     Backend State Changed to InitWait
12974973524421: XenPCI     fdo_driver_object = FFFFFA8001BB7060
12974973524421: XenPCI <-- XenPci_UpdateBackendState
12974973524421: XenPCI     fdo_driver_extension = 0000000000000000
12974973524421: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973524437: XenPCI     fdo_driver_extension = 0000000000000000
12974973524437: XenPCI <-- XenConfig_InitConfigPage
12974973524437: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524437: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524437: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524453: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973524468: XenNet --> XenNet_Initialize
12974973524468: XenNet     XEN_INIT_TYPE_13
12974973524468: XenNet     XEN_INIT_TYPE_VECTORS
12974973524468: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524468: ScatterGather = 1
12974973524468: LargeSendOffload = 61440
12974973524500: LargeSendOffloadRxSplitMTU = 1
12974973524500: ChecksumOffload = 1
12974973524500: MTU = 1500
12974973524515: Could not read NetworkAddress value (c0000001) or
value is invalid
12974973524515: XenNet --> XenNet_D0Entry
12974973524515: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = 16380
12974973524531: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524546: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = 16379
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524562: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI --> EvtChn_Bind
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI <-- EvtChn_Bind
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendState
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_UpdateBackendState
12974973524593: XenPCI     Backend State Changed to Connected
12974973524593: XenPCI <-- XenPci_UpdateBackendState
12974973524593: XenPCI <-- XenPci_ChangeFrontendState
12974973524609: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524609: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524609: XenNet --> XenNet_ConnectBackend
12974973524609: XenNet     XEN_INIT_TYPE_13
12974973524609: XenNet     XEN_INIT_TYPE_VECTORS
12974973524609: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524609: XenNet     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524609: XenNet     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524609: XenNet     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - mac = 00:16:3e:00:17:b9
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - feature-sg = 1
12974973524625: XenNet     XEN_INIT_TYPE_READ_STRING - feature-gso-tcpv4 = 1
12974973524625: XenNet     XEN_INIT_TYPE_17
12974973524625: XenNet <-- XenNet_ConnectBackend
12974973524625: XenNet --> XenNet_RxInit
12974973524625: XenNet <-- XenNet_RxInit
12974973524625: XenNet <-- XenNet_D0Entry
12974973524640: XenNet     Supporting 00010102
(OID_GEN_HARDWARE_STATUS) get only 4 bytes
12974973524640: XenNet     Supporting 00010108
(OID_GEN_TRANSMIT_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 00010109
(OID_GEN_RECEIVE_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010a
(OID_GEN_TRANSMIT_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010b
(OID_GEN_RECEIVE_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010c (OID_GEN_VENDOR_ID) get
only 4 bytes
12974973524656: XenNet     Supporting 0001010d
(OID_GEN_VENDOR_DESCRIPTION) get only 10 bytes
12974973524656: XenNet     Supporting 00010116
(OID_GEN_VENDOR_DRIVER_VERSION) get only 4 bytes
12974973524656: XenNet     Supporting 0001010e
(OID_GEN_CURRENT_PACKET_FILTER) get/set 4 bytes
12974973524656: XenNet     Supporting 0001010f
(OID_GEN_CURRENT_LOOKAHEAD) get/set 4 bytes
12974973524656: XenNet     Supporting 00010111
(OID_GEN_MAXIMUM_TOTAL_SIZE) get only 4 bytes
12974973524656: XenNet     Supporting 00010208
(OID_GEN_LINK_PARAMETERS) set only 32 bytes
12974973524656: XenNet     Supporting 00010209
(OID_GEN_INTERRUPT_MODERATION) get/set 12 bytes
12974973524671: XenNet     Supporting 00010115
(OID_GEN_MAXIMUM_SEND_PACKETS) get only 4 bytes
12974973524671: XenNet     Supporting 00010103
(OID_GEN_MEDIA_SUPPORTED) get only 4 bytes
12974973524671: XenNet     Supporting 00010104 (OID_GEN_MEDIA_IN_USE)
get only 4 bytes
12974973524671: XenNet     Supporting 00010105
(OID_GEN_MAXIMUM_LOOKAHEAD) get only 4 bytes
12974973524671: XenNet     Supporting 00010118
(OID_GEN_NETWORK_LAYER_ADDRESSES) set only 6 bytes
12974973524671: XenNet     Supporting 0001021a (OID_GEN_MACHINE_NAME)
set only 0 bytes
12974973524687: XenNet     Supporting 0101010a
(OID_OFFLOAD_ENCAPSULATION) set only 28 bytes
12974973524687: XenNet     Supporting fd010101 (OID_PNP_SET_POWER) set
only 4 bytes
12974973524687: XenNet     Supporting 00020101 (OID_GEN_XMIT_OK) get
only 0 bytes
12974973524687: XenNet     Supporting 00020102 (OID_GEN_RCV_OK) get only 0 bytes
12974973524687: XenNet     Supporting 00020103 (OID_GEN_XMIT_ERROR)
get only 0 bytes
12974973524703: XenNet     Supporting 00020104 (OID_GEN_RCV_ERROR) get
only 0 bytes
12974973524703: XenNet     Supporting 00020105 (OID_GEN_RCV_NO_BUFFER)
get only 0 bytes
12974973524703: XenNet     Supporting 01020101
(OID_802_3_RCV_ERROR_ALIGNMENT) get only 0 bytes
12974973524703: XenNet     Supporting 01020102
(OID_802_3_XMIT_ONE_COLLISION) get only 0 bytes
12974973524703: XenNet     Supporting 01020103
(OID_802_3_XMIT_MORE_COLLISIONS) get only 0 bytes
12974973524703: XenNet     Supporting fc010209 (OID_IP4_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting fc01020a (OID_IP6_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting 00020106 (OID_GEN_STATISTICS)
get only 152 bytes
12974973524718: XenNet     Supporting 01010101
(OID_802_3_PERMANENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010102
(OID_802_3_CURRENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010103
(OID_802_3_MULTICAST_LIST) get/set 0 bytes
12974973524734: XenNet     Supporting 01010104
(OID_802_3_MAXIMUM_LIST_SIZE) get only 4 bytes
12974973524734: XenNet     name = minint-ps2nl91
12974973524734: XenNet --> XenNet_Restart
12974973524734: XenNet <-- XenNet_Restart
12974973524734: XenNet --> XenNet_DevicePnPEventNotify
12974973524734: XenNet     NdisDevicePnPEventPowerProfileChanged
12974973524734: XenNet <-- XenNet_DevicePnPEventNotify
12974973524734: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 62 (FFFFFA8001BB9000)
12974973524750: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524750: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524750: XenNet     Unsupported OID 00010117
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524781: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 82 (FFFFFA8001BB9000)
12974973524781: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524796: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524796: XenNet     NDIS_PACKET_TYPE_BROADCAST
12974973524796: XenNet      IPv4.Enabled = NDIS_OFFLOAD_SET_ON
12974973524796: XenNet      IPv4.HeaderSize = 14
12974973524796: XenNet      IPv6.EncapsulationType = 0
12974973524796: XenNet      IPv6.Enabled = NDIS_OFFLOAD_SET_OFF
12974973524812: XenNet      IPv6.HeaderSize = 0
12974973534531: XenNet     AddressType = 2
12974973534531: XenNet     AddressCount = 1
12974973534531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973534531: XenNet     Address[0].Length = 16
12974973534531: XenNet     Address[0].in_addr = 169.254.239.84
12974973586906: XenPCI --> XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoWrite
12974973586921: XenPCI     36 bytes of write buffer remaining
12974973586921: XenPCI     completing request with length 36
12974973586921: XenPCI <-- XenBus_EvtIoWrite
12974973586921: XenPCI <-- XenPci_EvtIoDefault
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoRead
12974973586921: XenPCI     found pending read
12974973586937: XenPCI <-- XenBus_ProcessReadRequest
12974973586937: XenPCI <-- XenBus_EvtIoRead
12974973586937: XenPCI <-- XenPci_EvtIoDefault
12974973586937: XenPCI --> XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenPci_EvtFileClose
12974973586937: XenPCI --> XenBus_EvtFileClose
12974973586937: XenPCI <-- XenBus_EvtFileClose
12974973586937: XenPCI <-- XenPci_EvtFileClose
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591531: XenNet     Address[0].Length = 16
12974973591531: XenNet     Address[0].in_addr = 62.76.47.68
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591546: XenNet     Address[0].Length = 16
12974973591546: XenNet     Address[0].in_addr = 62.76.47.68
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973612640: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613343: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613390: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613453: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613468: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613500: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613531: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613812: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613859: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613890: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613953: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613968: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614015: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973618406: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629718: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629750: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629765: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973635718: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973640703: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973648015: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973652000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 11:52:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 11:52:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG7hZ-0000wD-Qy; Fri, 06 Apr 2012 11:51:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SG7hY-0000w8-I6
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 11:51:36 +0000
Received: from [85.158.139.83:14721] by server-10.bemta-5.messagelabs.com id
	6C/D8-08260-7C8DE7F4; Fri, 06 Apr 2012 11:51:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333713094!22751735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4597 invoked from network); 6 Apr 2012 11:51:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 11:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="11810720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 11:51:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 12:51:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SG7hW-0005F8-0T;
	Fri, 06 Apr 2012 11:51:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SG7hV-0007hk-W1;
	Fri, 06 Apr 2012 12:51:34 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12586-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 12:51:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12586: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12586 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12586/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 11:52:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 11:52:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG7hZ-0000wD-Qy; Fri, 06 Apr 2012 11:51:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SG7hY-0000w8-I6
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 11:51:36 +0000
Received: from [85.158.139.83:14721] by server-10.bemta-5.messagelabs.com id
	6C/D8-08260-7C8DE7F4; Fri, 06 Apr 2012 11:51:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333713094!22751735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4597 invoked from network); 6 Apr 2012 11:51:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 11:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="11810720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 11:51:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 12:51:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SG7hW-0005F8-0T;
	Fri, 06 Apr 2012 11:51:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SG7hV-0007hk-W1;
	Fri, 06 Apr 2012 12:51:34 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12586-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 12:51:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12586: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12586 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12586/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8Dt-0001Lw-II; Fri, 06 Apr 2012 12:25:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SG8Dr-0001Lr-5b
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:24:59 +0000
Received: from [85.158.138.51:34728] by server-2.bemta-3.messagelabs.com id
	93/AE-15460-A90EE7F4; Fri, 06 Apr 2012 12:24:58 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333715094!10072623!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14295 invoked from network); 6 Apr 2012 12:24:57 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 12:24:57 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SG8DZ-00042T-PQ; Fri, 06 Apr 2012 22:24:41 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Apr 2012 22:24:41 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 6 Apr 2012 22:24:41 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Thread-Topic: GPLPV error
Thread-Index: Ac0T7mO/YMdNKnQRTlSq+qfiZkheFQ==
Date: Fri, 6 Apr 2012 12:24:39 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Apr 2012 12:24:41.0614 (UTC)
	FILETIME=[3DF4BAE0:01CD13F0]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Sorry, but i have another problem with disk write when use gplpv:
> 
>  I'm create simple winpe windows installer with windows aik and
> integrate into it xen gpl pv drivers. Sometimes i can't install
> windows to hard drive.
> Windows syas, that hard disk not properly configured in bios or not
> able to boot from it.
> Disk is the phisical device, domU config:
> 
> kernel='hvmloader'
> builder='hvm'
> memory=1024
> name="21-706"
> vcpus=4
> vif="mac=00:16:3e:00:17:b9,ip=62.76.47.68,type=paravirtualised"
> disk="file:/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008
> _R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso,hdc:cdrom,r"
> disk="phy:/dev/disk/vbd/21-1206,hda,w"
> device_model='qemu-dm'
> boot='c'
> vnc=1
> vncpasswd='uRFCg8oPkD'
> serial='pty'
> usbdevice='tablet'
> keymap='en-us'
> boot='d'
> -p
> disk="file:/var/storage/iso/winpe_amd64.iso,hdb:cdrom,r"
> on_reboot=destroy
> on_poweroff=destroy
> on_crash=destroy

I thought you couldn't have multiple disk= lines like that. I thought only the last one would take effect... that's not what your qemu log says though.

I can't see any obvious errors in your logs. The only thing that maybe is a concern is:

> 12974973492609: XenPCI GPLPV 0.10.0.357
> 12974973492609: XenPCI --> XenPci_FixLoadOrder
> 12974973492609: XenPCI     dummy_group_index = -1
> 12974973492609: XenPCI     wdf_load_group_index = 2
> 12974973492609: XenPCI     xenpci_group_index = -1
> 12974973492609: XenPCI     boot_bus_extender_index = 3
> 12974973492609: XenPCI <-- XenPci_FixLoadOrder

It should look more like this:

12978176025734: XenPCI GPLPV 0.10.0.357
12978176025734: XenPCI --> XenPci_FixLoadOrder
12978176025734: XenPCI     dummy_group_index = 1
12978176025750: XenPCI     wdf_load_group_index = 2
12978176025750: XenPCI     xenpci_group_index = 3
12978176025750: XenPCI     boot_bus_extender_index = 5
12978176025750: XenPCI <-- XenPci_FixLoadOrder

Which ensures that xenpci loads before "boot_bus_extender" devices, and so is active before windows finds the ide path to the harddisk. If windows spotted both the ide and the gplpv paths to the harddisk it may get a bit confused, especially if gplpv hides the ide drive a bit later on. I have tried to be very careful to ensure that this cannot happen (both paths active at the same time) though as it can trash filesystems if Windows doesn't detect them as the same device.

Where does Windows tell you there is a problem with the harddisk?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8Dt-0001Lw-II; Fri, 06 Apr 2012 12:25:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SG8Dr-0001Lr-5b
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:24:59 +0000
Received: from [85.158.138.51:34728] by server-2.bemta-3.messagelabs.com id
	93/AE-15460-A90EE7F4; Fri, 06 Apr 2012 12:24:58 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333715094!10072623!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14295 invoked from network); 6 Apr 2012 12:24:57 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 12:24:57 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SG8DZ-00042T-PQ; Fri, 06 Apr 2012 22:24:41 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Apr 2012 22:24:41 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 6 Apr 2012 22:24:41 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Thread-Topic: GPLPV error
Thread-Index: Ac0T7mO/YMdNKnQRTlSq+qfiZkheFQ==
Date: Fri, 6 Apr 2012 12:24:39 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Apr 2012 12:24:41.0614 (UTC)
	FILETIME=[3DF4BAE0:01CD13F0]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Sorry, but i have another problem with disk write when use gplpv:
> 
>  I'm create simple winpe windows installer with windows aik and
> integrate into it xen gpl pv drivers. Sometimes i can't install
> windows to hard drive.
> Windows syas, that hard disk not properly configured in bios or not
> able to boot from it.
> Disk is the phisical device, domU config:
> 
> kernel='hvmloader'
> builder='hvm'
> memory=1024
> name="21-706"
> vcpus=4
> vif="mac=00:16:3e:00:17:b9,ip=62.76.47.68,type=paravirtualised"
> disk="file:/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008
> _R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso,hdc:cdrom,r"
> disk="phy:/dev/disk/vbd/21-1206,hda,w"
> device_model='qemu-dm'
> boot='c'
> vnc=1
> vncpasswd='uRFCg8oPkD'
> serial='pty'
> usbdevice='tablet'
> keymap='en-us'
> boot='d'
> -p
> disk="file:/var/storage/iso/winpe_amd64.iso,hdb:cdrom,r"
> on_reboot=destroy
> on_poweroff=destroy
> on_crash=destroy

I thought you couldn't have multiple disk= lines like that. I thought only the last one would take effect... that's not what your qemu log says though.

I can't see any obvious errors in your logs. The only thing that maybe is a concern is:

> 12974973492609: XenPCI GPLPV 0.10.0.357
> 12974973492609: XenPCI --> XenPci_FixLoadOrder
> 12974973492609: XenPCI     dummy_group_index = -1
> 12974973492609: XenPCI     wdf_load_group_index = 2
> 12974973492609: XenPCI     xenpci_group_index = -1
> 12974973492609: XenPCI     boot_bus_extender_index = 3
> 12974973492609: XenPCI <-- XenPci_FixLoadOrder

It should look more like this:

12978176025734: XenPCI GPLPV 0.10.0.357
12978176025734: XenPCI --> XenPci_FixLoadOrder
12978176025734: XenPCI     dummy_group_index = 1
12978176025750: XenPCI     wdf_load_group_index = 2
12978176025750: XenPCI     xenpci_group_index = 3
12978176025750: XenPCI     boot_bus_extender_index = 5
12978176025750: XenPCI <-- XenPci_FixLoadOrder

Which ensures that xenpci loads before "boot_bus_extender" devices, and so is active before windows finds the ide path to the harddisk. If windows spotted both the ide and the gplpv paths to the harddisk it may get a bit confused, especially if gplpv hides the ide drive a bit later on. I have tried to be very careful to ensure that this cannot happen (both paths active at the same time) though as it can trash filesystems if Windows doesn't detect them as the same device.

Where does Windows tell you there is a problem with the harddisk?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:37:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8PU-0001Vp-Ok; Fri, 06 Apr 2012 12:37:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1SG8PT-0001Vk-LQ
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:36:59 +0000
Received: from [85.158.143.35:2581] by server-1.bemta-4.messagelabs.com id
	B1/1C-20925-A63EE7F4; Fri, 06 Apr 2012 12:36:58 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333715817!12166714!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1394 invoked from network); 6 Apr 2012 12:36:58 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 12:36:58 -0000
Received: by lbon3 with SMTP id n3so719355lbo.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 05:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=NrJtlwteI27sReCMQnU90SorUqphudSPy3+zcVsJZ/c=;
	b=Jt9hYx+Var2K3k3mIvJU3bCyA9zmMT62lMGVcSNo/a7i4pdzxujMvZMyb50MLa/OhI
	uxtzhlr/X7/b+Wz1GkRN4rwlNgJXYf/ZLr43CHvsMsW7aFkeRgmXEQR2CjlrbUU6j2XR
	iEaADRz5+gM8WYNZQk2L/vpyOlv7CEAzEc/cI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=NrJtlwteI27sReCMQnU90SorUqphudSPy3+zcVsJZ/c=;
	b=nZ+XgWmWWLmhh9Zcf62rFwrDbs7S21IbT35cOQ7zr4CYpw1d5ALdUcgYY0l37hE46I
	6oaN5bx7gsbtQShiWh8mottlC7aH1QBDsf+yalVDLNpHoIVdCMcSekRslP6NH8660pkV
	U5sr9GbFWS8F1/4H69dD+glETqZJEAnbS2cZREVJSEG1TYyrumR3V0MZkriaAq7C8u7H
	UENBYJSZBFhnxjyrMCZUBD4XlWU8uUbT7AifhbMeKfru3IJj6kKJgXIaJUeRAqVws3DL
	iSss83MG3gvLOGKHpgm2hn0/8s68eUxA0/P2Fqkxcak2h6lFPvMHnbBZZqjfcUzefu/9
	1ibg==
Received: by 10.152.102.145 with SMTP id fo17mr8506519lab.2.1333715817143;
	Fri, 06 Apr 2012 05:36:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.37.234 with HTTP; Fri, 6 Apr 2012 05:36:41 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 6 Apr 2012 16:36:41 +0400
X-Google-Sender-Auth: GHBuB4zAJ6yRIa1NSFG3LtyOs0U
Message-ID: <CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQlmN6dcadbNIgyGUem2imegyCyILbNv+YCekST5uQFqvn2i9og0KOXOsBSaCG9c7ipovF++
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi80LzYgSmFtZXMgSGFycGVyIDxqYW1lcy5oYXJwZXJAYmVuZGlnb2l0LmNvbS5hdT46Cgo+
Cj4gSSB0aG91Z2h0IHlvdSBjb3VsZG4ndCBoYXZlIG11bHRpcGxlIGRpc2s9IGxpbmVzIGxpa2Ug
dGhhdC4gSSB0aG91Z2h0IG9ubHkgdGhlIGxhc3Qgb25lIHdvdWxkIHRha2UgZWZmZWN0Li4uIHRo
YXQncyBub3Qgd2hhdCB5b3VyIHFlbXUgbG9nIHNheXMgdGhvdWdoLgoKVGhpcyBpcyBjb21tYW5k
IGxpbmUgYXJncyB0byB4bSBjcmVhdGUgLCBpbiB0aGlzIGNhc2UgbXVsdGlwbHkgZGlzawpsaW5l
cyBhbGxvd2VkLi4uCgo+Cj4gSSBjYW4ndCBzZWUgYW55IG9idmlvdXMgZXJyb3JzIGluIHlvdXIg
bG9ncy4gVGhlIG9ubHkgdGhpbmcgdGhhdCBtYXliZSBpcyBhIGNvbmNlcm4gaXM6Cj4KPj4gMTI5
NzQ5NzM0OTI2MDk6IFhlblBDSSBHUExQViAwLjEwLjAuMzU3Cj4+IDEyOTc0OTczNDkyNjA5OiBY
ZW5QQ0kgLS0+IFhlblBjaV9GaXhMb2FkT3JkZXIKPj4gMTI5NzQ5NzM0OTI2MDk6IFhlblBDSSDC
oCDCoCBkdW1teV9ncm91cF9pbmRleCA9IC0xCj4+IDEyOTc0OTczNDkyNjA5OiBYZW5QQ0kgwqAg
wqAgd2RmX2xvYWRfZ3JvdXBfaW5kZXggPSAyCj4+IDEyOTc0OTczNDkyNjA5OiBYZW5QQ0kgwqAg
wqAgeGVucGNpX2dyb3VwX2luZGV4ID0gLTEKPj4gMTI5NzQ5NzM0OTI2MDk6IFhlblBDSSDCoCDC
oCBib290X2J1c19leHRlbmRlcl9pbmRleCA9IDMKPj4gMTI5NzQ5NzM0OTI2MDk6IFhlblBDSSA8
LS0gWGVuUGNpX0ZpeExvYWRPcmRlcgo+Cj4gSXQgc2hvdWxkIGxvb2sgbW9yZSBsaWtlIHRoaXM6
Cj4KPiAxMjk3ODE3NjAyNTczNDogWGVuUENJIEdQTFBWIDAuMTAuMC4zNTcKPiAxMjk3ODE3NjAy
NTczNDogWGVuUENJIC0tPiBYZW5QY2lfRml4TG9hZE9yZGVyCj4gMTI5NzgxNzYwMjU3MzQ6IFhl
blBDSSDCoCDCoCBkdW1teV9ncm91cF9pbmRleCA9IDEKPiAxMjk3ODE3NjAyNTc1MDogWGVuUENJ
IMKgIMKgIHdkZl9sb2FkX2dyb3VwX2luZGV4ID0gMgo+IDEyOTc4MTc2MDI1NzUwOiBYZW5QQ0kg
wqAgwqAgeGVucGNpX2dyb3VwX2luZGV4ID0gMwo+IDEyOTc4MTc2MDI1NzUwOiBYZW5QQ0kgwqAg
wqAgYm9vdF9idXNfZXh0ZW5kZXJfaW5kZXggPSA1Cj4gMTI5NzgxNzYwMjU3NTA6IFhlblBDSSA8
LS0gWGVuUGNpX0ZpeExvYWRPcmRlcgo+Cj4gV2hpY2ggZW5zdXJlcyB0aGF0IHhlbnBjaSBsb2Fk
cyBiZWZvcmUgImJvb3RfYnVzX2V4dGVuZGVyIiBkZXZpY2VzLCBhbmQgc28gaXMgYWN0aXZlIGJl
Zm9yZSB3aW5kb3dzIGZpbmRzIHRoZSBpZGUgcGF0aCB0byB0aGUgaGFyZGRpc2suIElmIHdpbmRv
d3Mgc3BvdHRlZCBib3RoIHRoZSBpZGUgYW5kIHRoZSBncGxwdiBwYXRocyB0byB0aGUgaGFyZGRp
c2sgaXQgbWF5IGdldCBhIGJpdCBjb25mdXNlZCwgZXNwZWNpYWxseSBpZiBncGxwdiBoaWRlcyB0
aGUgaWRlIGRyaXZlIGEgYml0IGxhdGVyIG9uLiBJIGhhdmUgdHJpZWQgdG8gYmUgdmVyeSBjYXJl
ZnVsIHRvIGVuc3VyZSB0aGF0IHRoaXMgY2Fubm90IGhhcHBlbiAoYm90aCBwYXRocyBhY3RpdmUg
YXQgdGhlIHNhbWUgdGltZSkgdGhvdWdoIGFzIGl0IGNhbiB0cmFzaCBmaWxlc3lzdGVtcyBpZiBX
aW5kb3dzIGRvZXNuJ3QgZGV0ZWN0IHRoZW0gYXMgdGhlIHNhbWUgZGV2aWNlLgo+Cj4gV2hlcmUg
ZG9lcyBXaW5kb3dzIHRlbGwgeW91IHRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIHRoZSBoYXJkZGlz
az8KPgoKV2luZG93cyBzYXlzIHRoaXMgZXJyb3Igd2hlbiBpIHJ1biBzZXR1cC5leGUgZnJvbSBp
c28gYW5kIGdvIHRvCmluc3RhbGwgd2luZG93cy4gQWZ0ZXIgd2luZG93cyBkZXRlY3RzIGhhcmQg
ZHJpdmVzIGl0IHNheXMgdGhpcyBlcnJvcjoKaGFyZCBkaXNrIG5vdCBwcm9wZXJseSBjb25maWd1
cmVkIGluIGJpb3Mgb3Igbm90IGFibGUgdG8gYm9vdAoKCgoKCi0tIApWYXNpbGl5IFRvbHN0b3Ys
CkNsb2RvLnJ1CmUtbWFpbDogdi50b2xzdG92QHNlbGZpcC5ydQpqYWJiZXI6IHZhc2VAc2VsZmlw
LnJ1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:37:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8PU-0001Vp-Ok; Fri, 06 Apr 2012 12:37:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1SG8PT-0001Vk-LQ
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:36:59 +0000
Received: from [85.158.143.35:2581] by server-1.bemta-4.messagelabs.com id
	B1/1C-20925-A63EE7F4; Fri, 06 Apr 2012 12:36:58 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-21.messagelabs.com!1333715817!12166714!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1394 invoked from network); 6 Apr 2012 12:36:58 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 12:36:58 -0000
Received: by lbon3 with SMTP id n3so719355lbo.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 05:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=NrJtlwteI27sReCMQnU90SorUqphudSPy3+zcVsJZ/c=;
	b=Jt9hYx+Var2K3k3mIvJU3bCyA9zmMT62lMGVcSNo/a7i4pdzxujMvZMyb50MLa/OhI
	uxtzhlr/X7/b+Wz1GkRN4rwlNgJXYf/ZLr43CHvsMsW7aFkeRgmXEQR2CjlrbUU6j2XR
	iEaADRz5+gM8WYNZQk2L/vpyOlv7CEAzEc/cI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=NrJtlwteI27sReCMQnU90SorUqphudSPy3+zcVsJZ/c=;
	b=nZ+XgWmWWLmhh9Zcf62rFwrDbs7S21IbT35cOQ7zr4CYpw1d5ALdUcgYY0l37hE46I
	6oaN5bx7gsbtQShiWh8mottlC7aH1QBDsf+yalVDLNpHoIVdCMcSekRslP6NH8660pkV
	U5sr9GbFWS8F1/4H69dD+glETqZJEAnbS2cZREVJSEG1TYyrumR3V0MZkriaAq7C8u7H
	UENBYJSZBFhnxjyrMCZUBD4XlWU8uUbT7AifhbMeKfru3IJj6kKJgXIaJUeRAqVws3DL
	iSss83MG3gvLOGKHpgm2hn0/8s68eUxA0/P2Fqkxcak2h6lFPvMHnbBZZqjfcUzefu/9
	1ibg==
Received: by 10.152.102.145 with SMTP id fo17mr8506519lab.2.1333715817143;
	Fri, 06 Apr 2012 05:36:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.37.234 with HTTP; Fri, 6 Apr 2012 05:36:41 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 6 Apr 2012 16:36:41 +0400
X-Google-Sender-Auth: GHBuB4zAJ6yRIa1NSFG3LtyOs0U
Message-ID: <CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQlmN6dcadbNIgyGUem2imegyCyILbNv+YCekST5uQFqvn2i9og0KOXOsBSaCG9c7ipovF++
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi80LzYgSmFtZXMgSGFycGVyIDxqYW1lcy5oYXJwZXJAYmVuZGlnb2l0LmNvbS5hdT46Cgo+
Cj4gSSB0aG91Z2h0IHlvdSBjb3VsZG4ndCBoYXZlIG11bHRpcGxlIGRpc2s9IGxpbmVzIGxpa2Ug
dGhhdC4gSSB0aG91Z2h0IG9ubHkgdGhlIGxhc3Qgb25lIHdvdWxkIHRha2UgZWZmZWN0Li4uIHRo
YXQncyBub3Qgd2hhdCB5b3VyIHFlbXUgbG9nIHNheXMgdGhvdWdoLgoKVGhpcyBpcyBjb21tYW5k
IGxpbmUgYXJncyB0byB4bSBjcmVhdGUgLCBpbiB0aGlzIGNhc2UgbXVsdGlwbHkgZGlzawpsaW5l
cyBhbGxvd2VkLi4uCgo+Cj4gSSBjYW4ndCBzZWUgYW55IG9idmlvdXMgZXJyb3JzIGluIHlvdXIg
bG9ncy4gVGhlIG9ubHkgdGhpbmcgdGhhdCBtYXliZSBpcyBhIGNvbmNlcm4gaXM6Cj4KPj4gMTI5
NzQ5NzM0OTI2MDk6IFhlblBDSSBHUExQViAwLjEwLjAuMzU3Cj4+IDEyOTc0OTczNDkyNjA5OiBY
ZW5QQ0kgLS0+IFhlblBjaV9GaXhMb2FkT3JkZXIKPj4gMTI5NzQ5NzM0OTI2MDk6IFhlblBDSSDC
oCDCoCBkdW1teV9ncm91cF9pbmRleCA9IC0xCj4+IDEyOTc0OTczNDkyNjA5OiBYZW5QQ0kgwqAg
wqAgd2RmX2xvYWRfZ3JvdXBfaW5kZXggPSAyCj4+IDEyOTc0OTczNDkyNjA5OiBYZW5QQ0kgwqAg
wqAgeGVucGNpX2dyb3VwX2luZGV4ID0gLTEKPj4gMTI5NzQ5NzM0OTI2MDk6IFhlblBDSSDCoCDC
oCBib290X2J1c19leHRlbmRlcl9pbmRleCA9IDMKPj4gMTI5NzQ5NzM0OTI2MDk6IFhlblBDSSA8
LS0gWGVuUGNpX0ZpeExvYWRPcmRlcgo+Cj4gSXQgc2hvdWxkIGxvb2sgbW9yZSBsaWtlIHRoaXM6
Cj4KPiAxMjk3ODE3NjAyNTczNDogWGVuUENJIEdQTFBWIDAuMTAuMC4zNTcKPiAxMjk3ODE3NjAy
NTczNDogWGVuUENJIC0tPiBYZW5QY2lfRml4TG9hZE9yZGVyCj4gMTI5NzgxNzYwMjU3MzQ6IFhl
blBDSSDCoCDCoCBkdW1teV9ncm91cF9pbmRleCA9IDEKPiAxMjk3ODE3NjAyNTc1MDogWGVuUENJ
IMKgIMKgIHdkZl9sb2FkX2dyb3VwX2luZGV4ID0gMgo+IDEyOTc4MTc2MDI1NzUwOiBYZW5QQ0kg
wqAgwqAgeGVucGNpX2dyb3VwX2luZGV4ID0gMwo+IDEyOTc4MTc2MDI1NzUwOiBYZW5QQ0kgwqAg
wqAgYm9vdF9idXNfZXh0ZW5kZXJfaW5kZXggPSA1Cj4gMTI5NzgxNzYwMjU3NTA6IFhlblBDSSA8
LS0gWGVuUGNpX0ZpeExvYWRPcmRlcgo+Cj4gV2hpY2ggZW5zdXJlcyB0aGF0IHhlbnBjaSBsb2Fk
cyBiZWZvcmUgImJvb3RfYnVzX2V4dGVuZGVyIiBkZXZpY2VzLCBhbmQgc28gaXMgYWN0aXZlIGJl
Zm9yZSB3aW5kb3dzIGZpbmRzIHRoZSBpZGUgcGF0aCB0byB0aGUgaGFyZGRpc2suIElmIHdpbmRv
d3Mgc3BvdHRlZCBib3RoIHRoZSBpZGUgYW5kIHRoZSBncGxwdiBwYXRocyB0byB0aGUgaGFyZGRp
c2sgaXQgbWF5IGdldCBhIGJpdCBjb25mdXNlZCwgZXNwZWNpYWxseSBpZiBncGxwdiBoaWRlcyB0
aGUgaWRlIGRyaXZlIGEgYml0IGxhdGVyIG9uLiBJIGhhdmUgdHJpZWQgdG8gYmUgdmVyeSBjYXJl
ZnVsIHRvIGVuc3VyZSB0aGF0IHRoaXMgY2Fubm90IGhhcHBlbiAoYm90aCBwYXRocyBhY3RpdmUg
YXQgdGhlIHNhbWUgdGltZSkgdGhvdWdoIGFzIGl0IGNhbiB0cmFzaCBmaWxlc3lzdGVtcyBpZiBX
aW5kb3dzIGRvZXNuJ3QgZGV0ZWN0IHRoZW0gYXMgdGhlIHNhbWUgZGV2aWNlLgo+Cj4gV2hlcmUg
ZG9lcyBXaW5kb3dzIHRlbGwgeW91IHRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIHRoZSBoYXJkZGlz
az8KPgoKV2luZG93cyBzYXlzIHRoaXMgZXJyb3Igd2hlbiBpIHJ1biBzZXR1cC5leGUgZnJvbSBp
c28gYW5kIGdvIHRvCmluc3RhbGwgd2luZG93cy4gQWZ0ZXIgd2luZG93cyBkZXRlY3RzIGhhcmQg
ZHJpdmVzIGl0IHNheXMgdGhpcyBlcnJvcjoKaGFyZCBkaXNrIG5vdCBwcm9wZXJseSBjb25maWd1
cmVkIGluIGJpb3Mgb3Igbm90IGFibGUgdG8gYm9vdAoKCgoKCi0tIApWYXNpbGl5IFRvbHN0b3Ys
CkNsb2RvLnJ1CmUtbWFpbDogdi50b2xzdG92QHNlbGZpcC5ydQpqYWJiZXI6IHZhc2VAc2VsZmlw
LnJ1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:45:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8XC-0001h2-So; Fri, 06 Apr 2012 12:44:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SG8XB-0001gv-8P
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:44:57 +0000
Received: from [85.158.138.51:50369] by server-9.bemta-3.messagelabs.com id
	86/2A-10923-845EE7F4; Fri, 06 Apr 2012 12:44:56 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333716294!20936956!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11733 invoked from network); 6 Apr 2012 12:44:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 12:44:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36Ciq4v004961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 12:44:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36CipHx009992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 12:44:52 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36CipnG016183
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 07:44:51 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 05:44:51 -0700
Message-ID: <4F7EE57D.4020207@oracle.com>
Date: Fri, 06 Apr 2012 08:45:49 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F7EE546.0008,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I see this output from xm info:

# xm info
...

release                : 2.6.32.21-45.6xen
version                : #1 SMP Wed Feb 29 23:42:59 EST 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2826

I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core

But the above output is not.

Could anyone explain it a little?

Thanks,

Zhigang




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:45:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8XC-0001h2-So; Fri, 06 Apr 2012 12:44:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SG8XB-0001gv-8P
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:44:57 +0000
Received: from [85.158.138.51:50369] by server-9.bemta-3.messagelabs.com id
	86/2A-10923-845EE7F4; Fri, 06 Apr 2012 12:44:56 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333716294!20936956!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11733 invoked from network); 6 Apr 2012 12:44:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 12:44:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36Ciq4v004961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 12:44:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36CipHx009992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 12:44:52 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36CipnG016183
	for <xen-devel@lists.xensource.com>; Fri, 6 Apr 2012 07:44:51 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 05:44:51 -0700
Message-ID: <4F7EE57D.4020207@oracle.com>
Date: Fri, 06 Apr 2012 08:45:49 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F7EE546.0008,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I see this output from xm info:

# xm info
...

release                : 2.6.32.21-45.6xen
version                : #1 SMP Wed Feb 29 23:42:59 EST 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2826

I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core

But the above output is not.

Could anyone explain it a little?

Thanks,

Zhigang




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:52:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8dy-0001qi-OR; Fri, 06 Apr 2012 12:51:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SG8dx-0001qd-Jm
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:51:57 +0000
Received: from [85.158.139.83:62704] by server-4.bemta-5.messagelabs.com id
	B4/D7-10788-CE6EE7F4; Fri, 06 Apr 2012 12:51:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333716712!22756964!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5054 invoked from network); 6 Apr 2012 12:51:55 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 12:51:55 -0000
Received: from smtp2.bendigoit.com.au ([203.16.207.99]
	helo=mail.bendigoit.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SG8do-0004B5-Bk; Fri, 06 Apr 2012 22:51:48 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Apr 2012 22:51:48 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 6 Apr 2012 22:51:47 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Thread-Topic: GPLPV error
Thread-Index: Ac0T7mO/YMdNKnQRTlSq+qfiZkheFf//X2qA//9UY+A=
Date: Fri, 6 Apr 2012 12:51:46 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF5F3CA@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
	<CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
In-Reply-To: <CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Apr 2012 12:51:48.0236 (UTC)
	FILETIME=[077F8CC0:01CD13F4]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Windows says this error when i run setup.exe from iso and go to install
> windows. After windows detects hard drives it says this error:
> hard disk not properly configured in bios or not able to boot
> 

Does the qemu log you sent earlier capture things up to this point?

I wonder if gplpv needs to tell Windows something about that it is a boot disk... this has never been a problem before but I've never tried installing like you are doing.

James
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 12:52:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 12:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8dy-0001qi-OR; Fri, 06 Apr 2012 12:51:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1SG8dx-0001qd-Jm
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 12:51:57 +0000
Received: from [85.158.139.83:62704] by server-4.bemta-5.messagelabs.com id
	B4/D7-10788-CE6EE7F4; Fri, 06 Apr 2012 12:51:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333716712!22756964!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5054 invoked from network); 6 Apr 2012 12:51:55 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Apr 2012 12:51:55 -0000
Received: from smtp2.bendigoit.com.au ([203.16.207.99]
	helo=mail.bendigoit.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1SG8do-0004B5-Bk; Fri, 06 Apr 2012 22:51:48 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Apr 2012 22:51:48 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 6 Apr 2012 22:51:47 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Thread-Topic: GPLPV error
Thread-Index: Ac0T7mO/YMdNKnQRTlSq+qfiZkheFf//X2qA//9UY+A=
Date: Fri, 6 Apr 2012 12:51:46 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B1AF5F3CA@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
	<CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
In-Reply-To: <CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Apr 2012 12:51:48.0236 (UTC)
	FILETIME=[077F8CC0:01CD13F4]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Windows says this error when i run setup.exe from iso and go to install
> windows. After windows detects hard drives it says this error:
> hard disk not properly configured in bios or not able to boot
> 

Does the qemu log you sent earlier capture things up to this point?

I wonder if gplpv needs to tell Windows something about that it is a boot disk... this has never been a problem before but I've never tried installing like you are doing.

James
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 13:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8rr-00022u-5u; Fri, 06 Apr 2012 13:06:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1SG8rp-00022p-8z
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 13:06:17 +0000
Received: from [85.158.139.83:37252] by server-2.bemta-5.messagelabs.com id
	6D/14-17016-84AEE7F4; Fri, 06 Apr 2012 13:06:16 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333717575!18487605!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12566 invoked from network); 6 Apr 2012 13:06:15 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 13:06:15 -0000
Received: by lagr15 with SMTP id r15so2596860lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 06:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=QBHZgI+Qn9bvkjkexwThpgDDyabhiiHrUnz8+TLnjOA=;
	b=WcFJAVUzahl4rpNJYJ01dsZeT/MLMMB2bf7PWlMVFqtBsOUhgEn6KtwaVfyerim5ne
	mFoPBy3rNQTxDYd4ItyMc5Wp9XcNyrKzzLarOrH7CctbYoMeWDSXHxWoqdUppz/PsYxS
	YBsrQYH093z/lA1Vqb0kmmPtAyt4k5ITNpsfU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:x-gm-message-state;
	bh=QBHZgI+Qn9bvkjkexwThpgDDyabhiiHrUnz8+TLnjOA=;
	b=E+at9450brDVN/WR5UcCFwbPUdtl5U7IPeul8/yDedgDKiffEgf92Wc7FQewi8xjM8
	T7wXOLO4UMLHyRsuQ2LG/f9PvaTWgYWAUqFUvFqCDGOzoTPjPKOp6C+nLMul4F/7tL7A
	1UNqafqy6QMwPb29wnWJ5trJpTOj4tZ0DoycDKEQ0EX4lutP5o7VpOBPi6kb+Uy/bP/7
	elxGTu6w25jXoNDkCAHOyR5aalSr4ke8u7Lzx0ILQ5uvIY457ON33HTjNkT6fUNCYvqX
	23vLJIvj9NLDQT+RKe+DL1iQBpKKk6xyWwjYN5/xT5MdxIBOpynRiHkTWuqcZhUhX978
	c0ZQ==
Received: by 10.152.102.145 with SMTP id fo17mr8632677lab.2.1333717573243;
	Fri, 06 Apr 2012 06:06:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.37.234 with HTTP; Fri, 6 Apr 2012 06:05:58 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5F3CA@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
	<CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B1AF5F3CA@BITCOM1.int.sbss.com.au>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 6 Apr 2012 17:05:58 +0400
X-Google-Sender-Auth: Ldt--vvYEjWKH5wNtUaYI4greLA
Message-ID: <CACaajQsF=3k3SZdUKeYLHdMA21LNOkRni-Zghkrgy3qSrMtb3Q@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQk4aH5gWA1Epg7jAkeng1kAfoK2La1EX3LmCAQoWN7qPaLFUYSrPqcjRG7479xz1/b2WTve
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/4/6 James Harper <james.harper@bendigoit.com.au>:
>>
>> Windows says this error when i run setup.exe from iso and go to install
>> windows. After windows detects hard drives it says this error:
>> hard disk not properly configured in bios or not able to boot
>>
>
> Does the qemu log you sent earlier capture things up to this point?
>
> I wonder if gplpv needs to tell Windows something about that it is a boot disk... this has never been a problem before but I've never tried installing like you are doing.
>
> James

No, time after time all works fine without modify. And my checks says,
that error displays more often than underline disk storage have big
latency. But then the latency is small, all works without
modifications.

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 13:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SG8rr-00022u-5u; Fri, 06 Apr 2012 13:06:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1SG8rp-00022p-8z
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 13:06:17 +0000
Received: from [85.158.139.83:37252] by server-2.bemta-5.messagelabs.com id
	6D/14-17016-84AEE7F4; Fri, 06 Apr 2012 13:06:16 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333717575!18487605!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12566 invoked from network); 6 Apr 2012 13:06:15 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 13:06:15 -0000
Received: by lagr15 with SMTP id r15so2596860lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 06:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=QBHZgI+Qn9bvkjkexwThpgDDyabhiiHrUnz8+TLnjOA=;
	b=WcFJAVUzahl4rpNJYJ01dsZeT/MLMMB2bf7PWlMVFqtBsOUhgEn6KtwaVfyerim5ne
	mFoPBy3rNQTxDYd4ItyMc5Wp9XcNyrKzzLarOrH7CctbYoMeWDSXHxWoqdUppz/PsYxS
	YBsrQYH093z/lA1Vqb0kmmPtAyt4k5ITNpsfU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type
	:x-gm-message-state;
	bh=QBHZgI+Qn9bvkjkexwThpgDDyabhiiHrUnz8+TLnjOA=;
	b=E+at9450brDVN/WR5UcCFwbPUdtl5U7IPeul8/yDedgDKiffEgf92Wc7FQewi8xjM8
	T7wXOLO4UMLHyRsuQ2LG/f9PvaTWgYWAUqFUvFqCDGOzoTPjPKOp6C+nLMul4F/7tL7A
	1UNqafqy6QMwPb29wnWJ5trJpTOj4tZ0DoycDKEQ0EX4lutP5o7VpOBPi6kb+Uy/bP/7
	elxGTu6w25jXoNDkCAHOyR5aalSr4ke8u7Lzx0ILQ5uvIY457ON33HTjNkT6fUNCYvqX
	23vLJIvj9NLDQT+RKe+DL1iQBpKKk6xyWwjYN5/xT5MdxIBOpynRiHkTWuqcZhUhX978
	c0ZQ==
Received: by 10.152.102.145 with SMTP id fo17mr8632677lab.2.1333717573243;
	Fri, 06 Apr 2012 06:06:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.37.234 with HTTP; Fri, 6 Apr 2012 06:05:58 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5F3CA@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B1AF5F36A@BITCOM1.int.sbss.com.au>
	<CACaajQt3jWuHrsjM9hDtcP8xXTuA4NY+ZZFoCDuA+QbGgJ9rmQ@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B1AF5F3CA@BITCOM1.int.sbss.com.au>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 6 Apr 2012 17:05:58 +0400
X-Google-Sender-Auth: Ldt--vvYEjWKH5wNtUaYI4greLA
Message-ID: <CACaajQsF=3k3SZdUKeYLHdMA21LNOkRni-Zghkrgy3qSrMtb3Q@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQk4aH5gWA1Epg7jAkeng1kAfoK2La1EX3LmCAQoWN7qPaLFUYSrPqcjRG7479xz1/b2WTve
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/4/6 James Harper <james.harper@bendigoit.com.au>:
>>
>> Windows says this error when i run setup.exe from iso and go to install
>> windows. After windows detects hard drives it says this error:
>> hard disk not properly configured in bios or not able to boot
>>
>
> Does the qemu log you sent earlier capture things up to this point?
>
> I wonder if gplpv needs to tell Windows something about that it is a boot disk... this has never been a problem before but I've never tried installing like you are doing.
>
> James

No, time after time all works fine without modify. And my checks says,
that error displays more often than underline disk storage have big
latency. But then the latency is small, all works without
modifications.

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 14:33:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 14:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGADV-00034e-Ax; Fri, 06 Apr 2012 14:32:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGADT-00034Z-LJ
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 14:32:43 +0000
Received: from [85.158.138.51:44442] by server-11.bemta-3.messagelabs.com id
	FD/8D-28543-A8EFE7F4; Fri, 06 Apr 2012 14:32:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333722761!21100926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4679 invoked from network); 6 Apr 2012 14:32:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 14:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="11812794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 14:32:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 15:32:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGADQ-0006M0-Kv;
	Fri, 06 Apr 2012 14:32:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGADQ-0001fO-EH;
	Fri, 06 Apr 2012 15:32:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12587-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 15:32:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12587: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12587 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12587/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12579

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 14:33:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 14:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGADV-00034e-Ax; Fri, 06 Apr 2012 14:32:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGADT-00034Z-LJ
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 14:32:43 +0000
Received: from [85.158.138.51:44442] by server-11.bemta-3.messagelabs.com id
	FD/8D-28543-A8EFE7F4; Fri, 06 Apr 2012 14:32:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1333722761!21100926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4679 invoked from network); 6 Apr 2012 14:32:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 14:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="11812794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 14:32:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 15:32:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGADQ-0006M0-Kv;
	Fri, 06 Apr 2012 14:32:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGADQ-0001fO-EH;
	Fri, 06 Apr 2012 15:32:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12587-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 15:32:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12587: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12587 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12587/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12579

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 14:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 14:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAZg-0003NW-FH; Fri, 06 Apr 2012 14:55:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAZf-0003NR-8H
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 14:55:39 +0000
Received: from [85.158.139.83:30652] by server-12.bemta-5.messagelabs.com id
	AF/08-05587-AE30F7F4; Fri, 06 Apr 2012 14:55:38 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333724137!22681850!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAyMTAx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29220 invoked from network); 6 Apr 2012 14:55:37 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 14:55:37 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAZd-0003Rn-D0; Fri, 06 Apr 2012 15:55:37 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Fri, 6 Apr 2012 15:54:34 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Fri, 6 Apr 2012 15:53:39 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0Ta7H6QRNJd0RcRIyWhO5/9JmtjwAASDR7ACYOi08=
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>,
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Francisco Rocha
Sent: 05 April 2012 21:43
To: wei.huang2@amd.com
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] (no subject)

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

The xsave=0 command line parameter solves the problem.

Thank you,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 14:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 14:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAZg-0003NW-FH; Fri, 06 Apr 2012 14:55:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAZf-0003NR-8H
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 14:55:39 +0000
Received: from [85.158.139.83:30652] by server-12.bemta-5.messagelabs.com id
	AF/08-05587-AE30F7F4; Fri, 06 Apr 2012 14:55:38 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-15.tower-182.messagelabs.com!1333724137!22681850!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAyMTAx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29220 invoked from network); 6 Apr 2012 14:55:37 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 14:55:37 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAZd-0003Rn-D0; Fri, 06 Apr 2012 15:55:37 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Fri, 6 Apr 2012 15:54:34 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Fri, 6 Apr 2012 15:53:39 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0Ta7H6QRNJd0RcRIyWhO5/9JmtjwAASDR7ACYOi08=
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>,
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Francisco Rocha
Sent: 05 April 2012 21:43
To: wei.huang2@amd.com
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] (no subject)

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

The xsave=0 command line parameter solves the problem.

Thank you,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAdV-0003Th-3q; Fri, 06 Apr 2012 14:59:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SGAdT-0003TZ-KG
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 14:59:35 +0000
Received: from [85.158.143.35:25519] by server-2.bemta-4.messagelabs.com id
	C8/B4-17550-6D40F7F4; Fri, 06 Apr 2012 14:59:34 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333724373!17517091!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15945 invoked from network); 6 Apr 2012 14:59:34 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-15.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Apr 2012 14:59:34 -0000
Received: from mail200-ch1-R.bigfish.com (10.43.68.226) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 14:59:32 +0000
Received: from mail200-ch1 (localhost [127.0.0.1])	by
	mail200-ch1-R.bigfish.com (Postfix) with ESMTP id 63DDDC04AD;
	Fri,  6 Apr 2012 14:59:32 +0000 (UTC)
X-SpamScore: -21
X-BigFish: VPS-21(zzbb2dI9371I146fKc85dh1432N98dK14ffOzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail200-ch1 (localhost.localdomain [127.0.0.1]) by mail200-ch1
	(MessageSwitch) id 1333724370545451_20574;
	Fri,  6 Apr 2012 14:59:30 +0000 (UTC)
Received: from CH1EHSMHS019.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.226])	by mail200-ch1.bigfish.com (Postfix) with ESMTP id
	7765346024E;	Fri,  6 Apr 2012 14:59:30 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 14:59:29 +0000
X-WSS-ID: 0M22CB3-01-61T-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23AC11028068;	Fri,  6 Apr 2012 09:59:27 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 6 Apr 2012 09:59:45 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Apr 2012
	09:59:26 -0500
Message-ID: <4F7F0308.2090601@amd.com>
Date: Fri, 6 Apr 2012 09:51:52 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>,
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with 
xsave/xrstor.

-Wei

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAdV-0003Th-3q; Fri, 06 Apr 2012 14:59:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SGAdT-0003TZ-KG
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 14:59:35 +0000
Received: from [85.158.143.35:25519] by server-2.bemta-4.messagelabs.com id
	C8/B4-17550-6D40F7F4; Fri, 06 Apr 2012 14:59:34 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1333724373!17517091!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15945 invoked from network); 6 Apr 2012 14:59:34 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-15.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Apr 2012 14:59:34 -0000
Received: from mail200-ch1-R.bigfish.com (10.43.68.226) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 14:59:32 +0000
Received: from mail200-ch1 (localhost [127.0.0.1])	by
	mail200-ch1-R.bigfish.com (Postfix) with ESMTP id 63DDDC04AD;
	Fri,  6 Apr 2012 14:59:32 +0000 (UTC)
X-SpamScore: -21
X-BigFish: VPS-21(zzbb2dI9371I146fKc85dh1432N98dK14ffOzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail200-ch1 (localhost.localdomain [127.0.0.1]) by mail200-ch1
	(MessageSwitch) id 1333724370545451_20574;
	Fri,  6 Apr 2012 14:59:30 +0000 (UTC)
Received: from CH1EHSMHS019.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.226])	by mail200-ch1.bigfish.com (Postfix) with ESMTP id
	7765346024E;	Fri,  6 Apr 2012 14:59:30 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 14:59:29 +0000
X-WSS-ID: 0M22CB3-01-61T-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23AC11028068;	Fri,  6 Apr 2012 09:59:27 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 6 Apr 2012 09:59:45 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Apr 2012
	09:59:26 -0500
Message-ID: <4F7F0308.2090601@amd.com>
Date: Fri, 6 Apr 2012 09:51:52 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>,
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with 
xsave/xrstor.

-Wei

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:04:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAhq-0003fM-QJ; Fri, 06 Apr 2012 15:04:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAhp-0003fH-3u
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 15:04:05 +0000
Received: from [85.158.143.35:38279] by server-2.bemta-4.messagelabs.com id
	13/97-17550-4E50F7F4; Fri, 06 Apr 2012 15:04:04 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333724643!13443642!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAxNzI3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13070 invoked from network); 6 Apr 2012 15:04:03 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 15:04:03 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAhn-0007gO-BY; Fri, 06 Apr 2012 16:04:03 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Fri, 6 Apr 2012 16:03:58 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Fri, 6 Apr 2012 16:02:10 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0UBeTv3JnIyz99SymjkgZLKI3viAAAFkfB
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B690@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>,
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>,
	<4F7F0308.2090601@amd.com>
In-Reply-To: <4F7F0308.2090601@amd.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 06 April 2012 15:51
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
xsave/xrstor.

-Wei

I didn't change the kernel, it's a fresh install.
I tried the latest for Fedora 16 and Xubuntu 11.10 both 
rebooted the machine.

Cheers,
Francisco

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:04:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAhq-0003fM-QJ; Fri, 06 Apr 2012 15:04:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAhp-0003fH-3u
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 15:04:05 +0000
Received: from [85.158.143.35:38279] by server-2.bemta-4.messagelabs.com id
	13/97-17550-4E50F7F4; Fri, 06 Apr 2012 15:04:04 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-13.tower-21.messagelabs.com!1333724643!13443642!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAxNzI3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13070 invoked from network); 6 Apr 2012 15:04:03 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 15:04:03 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGAhn-0007gO-BY; Fri, 06 Apr 2012 16:04:03 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi;
	Fri, 6 Apr 2012 16:03:58 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "wei.huang2@amd.com" <wei.huang2@amd.com>
Date: Fri, 6 Apr 2012 16:02:10 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0UBeTv3JnIyz99SymjkgZLKI3viAAAFkfB
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B690@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>,
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>,
	<4F7E004D.5090908@amd.com>,
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>,
	<4F7F0308.2090601@amd.com>
In-Reply-To: <4F7F0308.2090601@amd.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 06 April 2012 15:51
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
xsave/xrstor.

-Wei

I didn't change the kernel, it's a fresh install.
I tried the latest for Fedora 16 and Xubuntu 11.10 both 
rebooted the machine.

Cheers,
Francisco

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:19:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAwV-0003ta-8B; Fri, 06 Apr 2012 15:19:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGAwT-0003tV-An
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 15:19:13 +0000
Received: from [85.158.138.51:39143] by server-3.bemta-3.messagelabs.com id
	12/F4-10665-0790F7F4; Fri, 06 Apr 2012 15:19:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333725550!21127428!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12257 invoked from network); 6 Apr 2012 15:19:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 15:19:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36FJ7CT017733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 15:19:07 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36FJ61x020571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 15:19:06 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36FJ5gl029244; Fri, 6 Apr 2012 10:19:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 08:19:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5CE0A4031D; Fri,  6 Apr 2012 11:14:27 -0400 (EDT)
Date: Fri, 6 Apr 2012 11:14:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120406151427.GC19124@phenom.dumpdata.com>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
	<4F7E004D.5090908@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
	<4F7F0308.2090601@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7F0308.2090601@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F7F096C.0016,ss=1,re=0.000,fgs=0
Cc: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:19:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGAwV-0003ta-8B; Fri, 06 Apr 2012 15:19:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGAwT-0003tV-An
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 15:19:13 +0000
Received: from [85.158.138.51:39143] by server-3.bemta-3.messagelabs.com id
	12/F4-10665-0790F7F4; Fri, 06 Apr 2012 15:19:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1333725550!21127428!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12257 invoked from network); 6 Apr 2012 15:19:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 15:19:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36FJ7CT017733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 15:19:07 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36FJ61x020571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 15:19:06 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36FJ5gl029244; Fri, 6 Apr 2012 10:19:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 08:19:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5CE0A4031D; Fri,  6 Apr 2012 11:14:27 -0400 (EDT)
Date: Fri, 6 Apr 2012 11:14:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120406151427.GC19124@phenom.dumpdata.com>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
	<4F7E004D.5090908@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
	<4F7F0308.2090601@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7F0308.2090601@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F7F096C.0016,ss=1,re=0.000,fgs=0
Cc: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:42:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGBI6-00044f-6X; Fri, 06 Apr 2012 15:41:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SGBI4-00044a-Ti
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 15:41:33 +0000
Received: from [85.158.138.51:51381] by server-5.bemta-3.messagelabs.com id
	79/74-24278-BAE0F7F4; Fri, 06 Apr 2012 15:41:31 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333726889!21080618!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 6 Apr 2012 15:41:30 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-4.tower-174.messagelabs.com with SMTP;
	6 Apr 2012 15:41:30 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id F234CDBC28
	for <xen-devel@lists.xen.org>; Fri,  6 Apr 2012 23:41:14 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so1087045vcb.32
	for <xen-devel@lists.xen.org>; Fri, 06 Apr 2012 08:41:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.142.82 with SMTP id p18mr238970vcu.5.1333726872175; Fri,
	06 Apr 2012 08:41:12 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Fri, 6 Apr 2012 08:41:12 -0700 (PDT)
Date: Fri, 6 Apr 2012 23:41:12 +0800
Message-ID: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Virtualization of the CPU Performance Monitoring Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi list,

Is anybody working on virtualization of the CPU Performance Monitoring Unit?

There are 2 PMU related projects listed on GSoC 2012 page.
http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas

- Virtualization of the CPU Performance Monitoring Unit
- Perf support for Xen

I'm interested on these 2 projects.

Regards,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 15:42:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 15:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGBI6-00044f-6X; Fri, 06 Apr 2012 15:41:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SGBI4-00044a-Ti
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 15:41:33 +0000
Received: from [85.158.138.51:51381] by server-5.bemta-3.messagelabs.com id
	79/74-24278-BAE0F7F4; Fri, 06 Apr 2012 15:41:31 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333726889!21080618!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 6 Apr 2012 15:41:30 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-4.tower-174.messagelabs.com with SMTP;
	6 Apr 2012 15:41:30 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id F234CDBC28
	for <xen-devel@lists.xen.org>; Fri,  6 Apr 2012 23:41:14 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so1087045vcb.32
	for <xen-devel@lists.xen.org>; Fri, 06 Apr 2012 08:41:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.142.82 with SMTP id p18mr238970vcu.5.1333726872175; Fri,
	06 Apr 2012 08:41:12 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Fri, 6 Apr 2012 08:41:12 -0700 (PDT)
Date: Fri, 6 Apr 2012 23:41:12 +0800
Message-ID: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Virtualization of the CPU Performance Monitoring Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi list,

Is anybody working on virtualization of the CPU Performance Monitoring Unit?

There are 2 PMU related projects listed on GSoC 2012 page.
http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas

- Virtualization of the CPU Performance Monitoring Unit
- Perf support for Xen

I'm interested on these 2 projects.

Regards,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 16:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 16:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGBjG-0004hP-Hq; Fri, 06 Apr 2012 16:09:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGBjE-0004hK-I5
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 16:09:36 +0000
Received: from [85.158.143.99:32534] by server-3.bemta-4.messagelabs.com id
	13/37-05853-F351F7F4; Fri, 06 Apr 2012 16:09:35 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333728575!17395227!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAyMDkx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31836 invoked from network); 6 Apr 2012 16:09:35 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 16:09:35 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGBjC-00056p-CW; Fri, 06 Apr 2012 17:09:34 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Fri, 6 Apr 2012 17:09:33 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Wei Huang
	<wei.huang2@amd.com>
Date: Fri, 6 Apr 2012 17:09:33 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0UCKTvhFKvm3aJQO+2Igr5chg+xAABXJBR
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B691@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
	<4F7E004D.5090908@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
	<4F7F0308.2090601@amd.com>, <20120406151427.GC19124@phenom.dumpdata.com>
In-Reply-To: <20120406151427.GC19124@phenom.dumpdata.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
Sent: 06 April 2012 16:14
To: Wei Huang
Cc: Francisco Rocha; Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

I downloaded the latest version from xen-unstable.hg yesterday.

My machine is a Toshiba laptop R840-12F. Here is some info:

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x25
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5382.80
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

BIOS: TOSHIBA
Version: Version 3.60  
Release Date: 01/24/2012

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 16:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 16:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGBjG-0004hP-Hq; Fri, 06 Apr 2012 16:09:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGBjE-0004hK-I5
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 16:09:36 +0000
Received: from [85.158.143.99:32534] by server-3.bemta-4.messagelabs.com id
	13/37-05853-F351F7F4; Fri, 06 Apr 2012 16:09:35 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-12.tower-216.messagelabs.com!1333728575!17395227!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAyMDkx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31836 invoked from network); 6 Apr 2012 16:09:35 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 16:09:35 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SGBjC-00056p-CW; Fri, 06 Apr 2012 17:09:34 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi;
	Fri, 6 Apr 2012 17:09:33 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Wei Huang
	<wei.huang2@amd.com>
Date: Fri, 6 Apr 2012 17:09:33 +0100
Thread-Topic: [Xen-devel] (no subject)
Thread-Index: Ac0UCKTvhFKvm3aJQO+2Igr5chg+xAABXJBR
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B691@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68B@EXCCR03.campus.ncl.ac.uk>
	<4F7DF441.5040104@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68C@EXCCR03.campus.ncl.ac.uk>
	<4F7E004D.5090908@amd.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68D@EXCCR03.campus.ncl.ac.uk>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B68F@EXCCR03.campus.ncl.ac.uk>
	<4F7F0308.2090601@amd.com>, <20120406151427.GC19124@phenom.dumpdata.com>
In-Reply-To: <20120406151427.GC19124@phenom.dumpdata.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
Sent: 06 April 2012 16:14
To: Wei Huang
Cc: Francisco Rocha; Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

I downloaded the latest version from xen-unstable.hg yesterday.

My machine is a Toshiba laptop R840-12F. Here is some info:

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x25
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5382.80
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

BIOS: TOSHIBA
Version: Version 3.60  
Release Date: 01/24/2012

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 16:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 16:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGBt4-0004uQ-On; Fri, 06 Apr 2012 16:19:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGBt3-0004uJ-5r
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 16:19:45 +0000
Received: from [85.158.143.35:27792] by server-1.bemta-4.messagelabs.com id
	E6/E4-20925-0A71F7F4; Fri, 06 Apr 2012 16:19:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333729183!11352414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17027 invoked from network); 6 Apr 2012 16:19:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,382,1330905600"; d="scan'208";a="11814059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 16:19:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 17:19:43 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGBt1-0006xY-3r;
	Fri, 06 Apr 2012 16:19:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGBt0-0006k3-T0;
	Fri, 06 Apr 2012 17:19:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12589-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 17:19:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12589: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12589 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12589/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12557
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass

version targeted for testing:
 linux                314489bd4c7780fde6a069783d5128f6cef52919
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 16:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 16:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGBt4-0004uQ-On; Fri, 06 Apr 2012 16:19:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGBt3-0004uJ-5r
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 16:19:45 +0000
Received: from [85.158.143.35:27792] by server-1.bemta-4.messagelabs.com id
	E6/E4-20925-0A71F7F4; Fri, 06 Apr 2012 16:19:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1333729183!11352414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjkyMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17027 invoked from network); 6 Apr 2012 16:19:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,382,1330905600"; d="scan'208";a="11814059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 16:19:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 17:19:43 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGBt1-0006xY-3r;
	Fri, 06 Apr 2012 16:19:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGBt0-0006k3-T0;
	Fri, 06 Apr 2012 17:19:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12589-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 17:19:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12589: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12589 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12589/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12557
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass

version targeted for testing:
 linux                314489bd4c7780fde6a069783d5128f6cef52919
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 16:51:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 16:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGCN4-00058l-CM; Fri, 06 Apr 2012 16:50:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SGCN3-00058g-He
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 16:50:45 +0000
Received: from [85.158.143.35:43397] by server-3.bemta-4.messagelabs.com id
	83/59-05853-4EE1F7F4; Fri, 06 Apr 2012 16:50:44 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333731042!15043732!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3012 invoked from network); 6 Apr 2012 16:50:44 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Apr 2012 16:50:44 -0000
Received: from mail194-ch1-R.bigfish.com (10.43.68.239) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 16:50:42 +0000
Received: from mail194-ch1 (localhost [127.0.0.1])	by
	mail194-ch1-R.bigfish.com (Postfix) with ESMTP id 559B23C0197;
	Fri,  6 Apr 2012 16:50:42 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail194-ch1 (localhost.localdomain [127.0.0.1]) by mail194-ch1
	(MessageSwitch) id 133373104029121_25764;
	Fri,  6 Apr 2012 16:50:40 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.238])	by mail194-ch1.bigfish.com (Postfix) with ESMTP id
	03807A004E;	Fri,  6 Apr 2012 16:50:40 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 16:50:38 +0000
X-WSS-ID: 0M22HG8-02-45K-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21369C80AB;	Fri,  6 Apr 2012 11:50:31 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 6 Apr 2012 11:50:54 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Apr 2012
	11:50:34 -0500
Message-ID: <4F7F1D14.9040208@amd.com>
Date: Fri, 6 Apr 2012 11:43:00 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Lin Ming <mlin@ss.pku.edu.cn>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
In-Reply-To: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/06/2012 10:41 AM, Lin Ming wrote:
> Hi list,
>
> Is anybody working on virtualization of the CPU Performance Monitoring Unit?
>
> There are 2 PMU related projects listed on GSoC 2012 page.
> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
>
> - Virtualization of the CPU Performance Monitoring Unit
> - Perf support for Xen
>
> I'm interested on these 2 projects.
Hi Lin,

1. I don't think Xen was accepted as an organization for 2012 GSOC. See 
http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
2. The PMU project description in the wiki is vague. I know HVM guests 
support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and 
/vmx directories. You better ask mentors for details (maybe this is XCP 
specific?).

-Wei
>
> Regards,
> Lin Ming
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 16:51:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 16:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGCN4-00058l-CM; Fri, 06 Apr 2012 16:50:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SGCN3-00058g-He
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 16:50:45 +0000
Received: from [85.158.143.35:43397] by server-3.bemta-4.messagelabs.com id
	83/59-05853-4EE1F7F4; Fri, 06 Apr 2012 16:50:44 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1333731042!15043732!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3012 invoked from network); 6 Apr 2012 16:50:44 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Apr 2012 16:50:44 -0000
Received: from mail194-ch1-R.bigfish.com (10.43.68.239) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 16:50:42 +0000
Received: from mail194-ch1 (localhost [127.0.0.1])	by
	mail194-ch1-R.bigfish.com (Postfix) with ESMTP id 559B23C0197;
	Fri,  6 Apr 2012 16:50:42 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail194-ch1 (localhost.localdomain [127.0.0.1]) by mail194-ch1
	(MessageSwitch) id 133373104029121_25764;
	Fri,  6 Apr 2012 16:50:40 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.238])	by mail194-ch1.bigfish.com (Postfix) with ESMTP id
	03807A004E;	Fri,  6 Apr 2012 16:50:40 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Apr 2012 16:50:38 +0000
X-WSS-ID: 0M22HG8-02-45K-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21369C80AB;	Fri,  6 Apr 2012 11:50:31 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 6 Apr 2012 11:50:54 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Apr 2012
	11:50:34 -0500
Message-ID: <4F7F1D14.9040208@amd.com>
Date: Fri, 6 Apr 2012 11:43:00 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Lin Ming <mlin@ss.pku.edu.cn>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
In-Reply-To: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/06/2012 10:41 AM, Lin Ming wrote:
> Hi list,
>
> Is anybody working on virtualization of the CPU Performance Monitoring Unit?
>
> There are 2 PMU related projects listed on GSoC 2012 page.
> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
>
> - Virtualization of the CPU Performance Monitoring Unit
> - Perf support for Xen
>
> I'm interested on these 2 projects.
Hi Lin,

1. I don't think Xen was accepted as an organization for 2012 GSOC. See 
http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
2. The PMU project description in the wiki is vague. I know HVM guests 
support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and 
/vmx directories. You better ask mentors for details (maybe this is XCP 
specific?).

-Wei
>
> Regards,
> Lin Ming
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 17:17:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 17:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGCmW-0005Ol-CT; Fri, 06 Apr 2012 17:17:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1SGCmU-0005OT-O4
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 17:17:02 +0000
Received: from [193.109.254.147:9046] by server-6.bemta-14.messagelabs.com id
	69/78-02047-D052F7F4; Fri, 06 Apr 2012 17:17:01 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333732619!3544328!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21374 invoked from network); 6 Apr 2012 17:17:01 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 17:17:01 -0000
Received: by iadj38 with SMTP id j38so4393351iad.30
	for <multiple recipients>; Fri, 06 Apr 2012 10:16:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:from:date:x-google-sender-auth:message-id
	:subject:to:content-type;
	bh=SU/AaaZOBKw2tKy2oq7O+SEct5R90OeEbI3U/mJKQmY=;
	b=OJbLtoRrgkwizHky2HS5Nd7S/WjbMHgy9kYot93K2sGUSgE4R3QAvV/hosGpGXikNC
	NCAmfsjulzcAOr+U3Van6XhWPMJgbmYD93imkxzZPa1TpEqCL0d5zt/Gpcmj8dPnWciW
	sBpwjNUUSYvpBl8iSuibWKsOln0gs2T1juByqv1SvRhgfqdYuEfB/n3y6Y1tMS8jdMPu
	7mAFEfC2sCQrggj9/TeKDWpGBGi6ZbRIqEalG9fMe4TcEhT3PIP0CwXRwU4BeCqJV0Vv
	LR36rwdtrw++i+MSa6j5h5+f1AZtR1W75FABEdT6ahJOroFl4qVcxCf83/OWi4xYur/g
	U0vg==
Received: by 10.43.54.143 with SMTP id vu15mr5122750icb.40.1333732619124; Fri,
	06 Apr 2012 10:16:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.103.70 with HTTP; Fri, 6 Apr 2012 10:16:38 -0700 (PDT)
From: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 6 Apr 2012 13:16:38 -0400
X-Google-Sender-Auth: L882xKoH6k8BjKouQWGVp4leM88
Message-ID: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
To: xen-users mailing list <Xen-users@lists.xensource.com>, 
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Fedora Xen List <fedora-xen@redhat.com>
Subject: [Xen-devel] Calling all Fedora Xen users, testers, and developers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Fedora community is holding a virtualization test day [1] next
week (Thursday) and it would be great if we could help them on the Xen
side of things

Let me know if you are interested in helping out and I'll coordinated
the Xen efforts.

Thanks,
Todd

[1] http://fedoraproject.org/wiki/Test_Day:2012-04-12_Virtualization_Test_Day

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 17:17:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 17:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGCmW-0005Ol-CT; Fri, 06 Apr 2012 17:17:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1SGCmU-0005OT-O4
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 17:17:02 +0000
Received: from [193.109.254.147:9046] by server-6.bemta-14.messagelabs.com id
	69/78-02047-D052F7F4; Fri, 06 Apr 2012 17:17:01 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333732619!3544328!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21374 invoked from network); 6 Apr 2012 17:17:01 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 17:17:01 -0000
Received: by iadj38 with SMTP id j38so4393351iad.30
	for <multiple recipients>; Fri, 06 Apr 2012 10:16:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:from:date:x-google-sender-auth:message-id
	:subject:to:content-type;
	bh=SU/AaaZOBKw2tKy2oq7O+SEct5R90OeEbI3U/mJKQmY=;
	b=OJbLtoRrgkwizHky2HS5Nd7S/WjbMHgy9kYot93K2sGUSgE4R3QAvV/hosGpGXikNC
	NCAmfsjulzcAOr+U3Van6XhWPMJgbmYD93imkxzZPa1TpEqCL0d5zt/Gpcmj8dPnWciW
	sBpwjNUUSYvpBl8iSuibWKsOln0gs2T1juByqv1SvRhgfqdYuEfB/n3y6Y1tMS8jdMPu
	7mAFEfC2sCQrggj9/TeKDWpGBGi6ZbRIqEalG9fMe4TcEhT3PIP0CwXRwU4BeCqJV0Vv
	LR36rwdtrw++i+MSa6j5h5+f1AZtR1W75FABEdT6ahJOroFl4qVcxCf83/OWi4xYur/g
	U0vg==
Received: by 10.43.54.143 with SMTP id vu15mr5122750icb.40.1333732619124; Fri,
	06 Apr 2012 10:16:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.103.70 with HTTP; Fri, 6 Apr 2012 10:16:38 -0700 (PDT)
From: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 6 Apr 2012 13:16:38 -0400
X-Google-Sender-Auth: L882xKoH6k8BjKouQWGVp4leM88
Message-ID: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
To: xen-users mailing list <Xen-users@lists.xensource.com>, 
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Fedora Xen List <fedora-xen@redhat.com>
Subject: [Xen-devel] Calling all Fedora Xen users, testers, and developers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Fedora community is holding a virtualization test day [1] next
week (Thursday) and it would be great if we could help them on the Xen
side of things

Let me know if you are interested in helping out and I'll coordinated
the Xen efforts.

Thanks,
Todd

[1] http://fedoraproject.org/wiki/Test_Day:2012-04-12_Virtualization_Test_Day

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 18:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 18:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGE5q-0006Xw-C6; Fri, 06 Apr 2012 18:41:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGE5p-0006Xr-1M
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 18:41:05 +0000
Received: from [193.109.254.147:48747] by server-3.bemta-14.messagelabs.com id
	32/56-23274-0C83F7F4; Fri, 06 Apr 2012 18:41:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333737662!3549161!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8028 invoked from network); 6 Apr 2012 18:41:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 18:41:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36IewDx013741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 18:40:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36Ievwr008574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 18:40:58 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36IevMP027644; Fri, 6 Apr 2012 13:40:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 11:40:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D21004032C; Fri,  6 Apr 2012 14:36:18 -0400 (EDT)
Date: Fri, 6 Apr 2012 14:36:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120406183618.GA13473@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7F1D14.9040208@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F7F38BC.0022,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org, Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
> On 04/06/2012 10:41 AM, Lin Ming wrote:
> >Hi list,
> >
> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
> >
> >There are 2 PMU related projects listed on GSoC 2012 page.
> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> >
> >- Virtualization of the CPU Performance Monitoring Unit
> >- Perf support for Xen
> >
> >I'm interested on these 2 projects.
> Hi Lin,
> 
> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
> See
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> 2. The PMU project description in the wiki is vague. I know HVM
> guests support virtualized PMU. Please check vpmu.c files in /hvm,
> /svm, and /vmx directories. You better ask mentors for details
> (maybe this is XCP specific?).

This is dom0 related. So being able to use perf to instrument
the hypervisor (and the guests from dom0).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 18:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 18:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGE5q-0006Xw-C6; Fri, 06 Apr 2012 18:41:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGE5p-0006Xr-1M
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 18:41:05 +0000
Received: from [193.109.254.147:48747] by server-3.bemta-14.messagelabs.com id
	32/56-23274-0C83F7F4; Fri, 06 Apr 2012 18:41:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1333737662!3549161!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8028 invoked from network); 6 Apr 2012 18:41:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 18:41:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36IewDx013741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 18:40:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36Ievwr008574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 18:40:58 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36IevMP027644; Fri, 6 Apr 2012 13:40:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 11:40:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D21004032C; Fri,  6 Apr 2012 14:36:18 -0400 (EDT)
Date: Fri, 6 Apr 2012 14:36:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120406183618.GA13473@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7F1D14.9040208@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F7F38BC.0022,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org, Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
> On 04/06/2012 10:41 AM, Lin Ming wrote:
> >Hi list,
> >
> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
> >
> >There are 2 PMU related projects listed on GSoC 2012 page.
> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> >
> >- Virtualization of the CPU Performance Monitoring Unit
> >- Perf support for Xen
> >
> >I'm interested on these 2 projects.
> Hi Lin,
> 
> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
> See
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> 2. The PMU project description in the wiki is vague. I know HVM
> guests support virtualized PMU. Please check vpmu.c files in /hvm,
> /svm, and /vmx directories. You better ask mentors for details
> (maybe this is XCP specific?).

This is dom0 related. So being able to use perf to instrument
the hypervisor (and the guests from dom0).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 18:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 18:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGEM6-0006lC-Tj; Fri, 06 Apr 2012 18:57:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGEM4-0006l7-UG
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 18:57:53 +0000
Received: from [85.158.138.51:4671] by server-12.bemta-3.messagelabs.com id
	07/9F-30663-FAC3F7F4; Fri, 06 Apr 2012 18:57:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333738671!20965901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12684 invoked from network); 6 Apr 2012 18:57:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 18:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,382,1330905600"; d="scan'208";a="11815240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 18:57:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 19:57:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGEM2-0008AI-CV;
	Fri, 06 Apr 2012 18:57:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGEM2-0001iS-6f;
	Fri, 06 Apr 2012 19:57:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12590-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 19:57:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12590: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12590 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12590/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                c0994f584243578a83f7691429071a0996869abd
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit c0994f584243578a83f7691429071a0996869abd
Merge: 3b08864... 314489b...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 6 10:38:32 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 18:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 18:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGEM6-0006lC-Tj; Fri, 06 Apr 2012 18:57:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGEM4-0006l7-UG
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 18:57:53 +0000
Received: from [85.158.138.51:4671] by server-12.bemta-3.messagelabs.com id
	07/9F-30663-FAC3F7F4; Fri, 06 Apr 2012 18:57:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333738671!20965901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12684 invoked from network); 6 Apr 2012 18:57:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 18:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,382,1330905600"; d="scan'208";a="11815240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 18:57:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Apr 2012 19:57:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGEM2-0008AI-CV;
	Fri, 06 Apr 2012 18:57:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGEM2-0001iS-6f;
	Fri, 06 Apr 2012 19:57:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12590-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Apr 2012 19:57:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12590: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12590 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12590/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                c0994f584243578a83f7691429071a0996869abd
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit c0994f584243578a83f7691429071a0996869abd
Merge: 3b08864... 314489b...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 6 10:38:32 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 19:53:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 19:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFDP-00078y-5T; Fri, 06 Apr 2012 19:52:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1SGFDN-00078t-TF
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 19:52:58 +0000
Received: from [85.158.139.83:46185] by server-10.bemta-5.messagelabs.com id
	99/EA-08260-8994F7F4; Fri, 06 Apr 2012 19:52:56 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333741975!22785759!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29954 invoked from network); 6 Apr 2012 19:52:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 19:52:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Apr 2012 20:54:18 +0100
Message-Id: <4F7F57A502000078000821B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Apr 2012 20:52:53 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <zhigang.x.wang@oracle.com>
References: <4F7EE57D.4020207@oracle.com>
In-Reply-To: <4F7EE57D.4020207@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
>nr_cpus                : 8
>nr_nodes               : 1
>cores_per_socket       : 4
>threads_per_core       : 1
>
>I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core

nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 19:53:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 19:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFDP-00078y-5T; Fri, 06 Apr 2012 19:52:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1SGFDN-00078t-TF
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 19:52:58 +0000
Received: from [85.158.139.83:46185] by server-10.bemta-5.messagelabs.com id
	99/EA-08260-8994F7F4; Fri, 06 Apr 2012 19:52:56 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1333741975!22785759!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29954 invoked from network); 6 Apr 2012 19:52:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 19:52:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Apr 2012 20:54:18 +0100
Message-Id: <4F7F57A502000078000821B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Apr 2012 20:52:53 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <zhigang.x.wang@oracle.com>
References: <4F7EE57D.4020207@oracle.com>
In-Reply-To: <4F7EE57D.4020207@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
>nr_cpus                : 8
>nr_nodes               : 1
>cores_per_socket       : 4
>threads_per_core       : 1
>
>I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core

nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 19:59:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 19:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFJE-0007G3-Uh; Fri, 06 Apr 2012 19:59:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFJD-0007Fy-Nd
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 19:58:59 +0000
Received: from [193.109.254.147:45743] by server-9.bemta-14.messagelabs.com id
	E9/53-05787-20B4F7F4; Fri, 06 Apr 2012 19:58:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333742336!3538297!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6762 invoked from network); 6 Apr 2012 19:58:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 19:58:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36JwsrC000762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 19:58:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36Jwrqd001178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 19:58:54 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36JwrwQ024093; Fri, 6 Apr 2012 14:58:53 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 12:58:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5BE3F4032C; Fri,  6 Apr 2012 15:54:15 -0400 (EDT)
Date: Fri, 6 Apr 2012 15:54:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Castro <evil.dani@gmail.com>
Message-ID: <20120406195414.GA13732@phenom.dumpdata.com>
References: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090202.4F7F4AFF.0062,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 07:20:13PM +0900, Daniel Castro wrote:
> hello All,
> =

> I am still working on the PV Drivers for SeaBIOS using upstream qemu.
> And, I have two questions.
> 1.
> Here is the location of all relevant data structs:
> blkfront_info:0x000fd620 shared_ring:0x0009a000 private_ring:0x0009b000

I surmise this is the guest PFNs.

> DEBUG Read op private ring at 0x0009b000-0x000ab000, idx 63478
> Here is my problem, when I do:
>         ring_req =3D
> GLOBALFLAT2GLOBAL(RING_GET_REQUEST(GET_GLOBALFLAT(bi->private),GLOBALFLAT=
2GLOBAL(GET_GLOBALFLAT(bi->private)->req_prod_pvt)));
>  //please ignore the MACROS for now, or read further down.
> I get:
> After RING_GET_REQUEST operation ring request is at 0xe18ea40f id:0
> But I have the feeling that the request should be between
> 0x0009b000-0x000ab000. Right?

That would imply a physical address - but if you are running with
pagetables (which I think you are?) then it would be virtual address.

You should have some basic macros to translate from virtual to physical
and vice-versa.

> =

> 2.
> As you can see in the above code I use some SeaBIOS macros to access
> 32Bit addresses in 16Bit code. My second questions is: How the memory

16-bit code. Refresh my memory - does that mean you can only
use segments and no paging? So you need to move a 16-bit window
around to get to your 32-bit address?

> access macros affect the RING macros? Do I need to rewrite the ring
> macros to use the memory macros inside, for example:

It should fit within a 16-bit (64K) contingous memory space.
I don't think it matters where that the block is - as long as you
have a segment selector activated for that 16-bit block.

> /* How big is this ring? */
> #define RING_SIZE(_r)                                                   \
>     ((_r)->nr_ents)

That tells you just how many entries are on it. Not how big
the structure is. For that it is sizeof(struct ..).

> =

> Should be instead:
> /* How big is this ring? */
> #define RING_SIZE(_r)                                                   \
>     (GET_GLOBAL((_r)->nr_ents))
> =

> SeaBIOS macros need to be around ALL memory accesses.
> =

> This is a short message for something that might be to complex to
> explain briefly, so please ask any questions that you deem necessary
> to understand. Right now, I am developing the first stage of boot when
> the BIOS requests address 7c00 to get the Boot sector. Once I get this
> working we should have a working prototype for PV-drivers in seabios.
> =

> Thank you all for your interest,
> =

> Daniel
> =

> -- =

> +-=3D=3D=3D=3D=3D---------------------------+
> | +---------------------------------+ | This space intentionally blank
> for notetaking.
> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> | |=A0=A0 | Consultant/Programmer.|
> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
> +-------------------------------------+
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 19:59:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 19:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFJE-0007G3-Uh; Fri, 06 Apr 2012 19:59:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFJD-0007Fy-Nd
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 19:58:59 +0000
Received: from [193.109.254.147:45743] by server-9.bemta-14.messagelabs.com id
	E9/53-05787-20B4F7F4; Fri, 06 Apr 2012 19:58:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1333742336!3538297!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6762 invoked from network); 6 Apr 2012 19:58:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 19:58:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36JwsrC000762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 19:58:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36Jwrqd001178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 19:58:54 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36JwrwQ024093; Fri, 6 Apr 2012 14:58:53 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 12:58:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5BE3F4032C; Fri,  6 Apr 2012 15:54:15 -0400 (EDT)
Date: Fri, 6 Apr 2012 15:54:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Castro <evil.dani@gmail.com>
Message-ID: <20120406195414.GA13732@phenom.dumpdata.com>
References: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090202.4F7F4AFF.0062,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 07:20:13PM +0900, Daniel Castro wrote:
> hello All,
> =

> I am still working on the PV Drivers for SeaBIOS using upstream qemu.
> And, I have two questions.
> 1.
> Here is the location of all relevant data structs:
> blkfront_info:0x000fd620 shared_ring:0x0009a000 private_ring:0x0009b000

I surmise this is the guest PFNs.

> DEBUG Read op private ring at 0x0009b000-0x000ab000, idx 63478
> Here is my problem, when I do:
>         ring_req =3D
> GLOBALFLAT2GLOBAL(RING_GET_REQUEST(GET_GLOBALFLAT(bi->private),GLOBALFLAT=
2GLOBAL(GET_GLOBALFLAT(bi->private)->req_prod_pvt)));
>  //please ignore the MACROS for now, or read further down.
> I get:
> After RING_GET_REQUEST operation ring request is at 0xe18ea40f id:0
> But I have the feeling that the request should be between
> 0x0009b000-0x000ab000. Right?

That would imply a physical address - but if you are running with
pagetables (which I think you are?) then it would be virtual address.

You should have some basic macros to translate from virtual to physical
and vice-versa.

> =

> 2.
> As you can see in the above code I use some SeaBIOS macros to access
> 32Bit addresses in 16Bit code. My second questions is: How the memory

16-bit code. Refresh my memory - does that mean you can only
use segments and no paging? So you need to move a 16-bit window
around to get to your 32-bit address?

> access macros affect the RING macros? Do I need to rewrite the ring
> macros to use the memory macros inside, for example:

It should fit within a 16-bit (64K) contingous memory space.
I don't think it matters where that the block is - as long as you
have a segment selector activated for that 16-bit block.

> /* How big is this ring? */
> #define RING_SIZE(_r)                                                   \
>     ((_r)->nr_ents)

That tells you just how many entries are on it. Not how big
the structure is. For that it is sizeof(struct ..).

> =

> Should be instead:
> /* How big is this ring? */
> #define RING_SIZE(_r)                                                   \
>     (GET_GLOBAL((_r)->nr_ents))
> =

> SeaBIOS macros need to be around ALL memory accesses.
> =

> This is a short message for something that might be to complex to
> explain briefly, so please ask any questions that you deem necessary
> to understand. Right now, I am developing the first stage of boot when
> the BIOS requests address 7c00 to get the Boot sector. Once I get this
> working we should have a working prototype for PV-drivers in seabios.
> =

> Thank you all for your interest,
> =

> Daniel
> =

> -- =

> +-=3D=3D=3D=3D=3D---------------------------+
> | +---------------------------------+ | This space intentionally blank
> for notetaking.
> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> | |=A0=A0 | Consultant/Programmer.|
> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
> +-------------------------------------+
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:00:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFKU-0007No-DT; Fri, 06 Apr 2012 20:00:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SGFKS-0007Ne-SA
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 20:00:17 +0000
Received: from [85.158.143.35:16077] by server-3.bemta-4.messagelabs.com id
	6B/FA-05853-05B4F7F4; Fri, 06 Apr 2012 20:00:16 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333742413!11468687!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24637 invoked from network); 6 Apr 2012 20:00:15 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 20:00:15 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36K0Coq001774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:00:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36K0AWc026610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:00:11 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36K084P003029; Fri, 6 Apr 2012 15:00:10 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:00:07 -0700
Message-ID: <4F7F4B82.6040007@oracle.com>
Date: Fri, 06 Apr 2012 16:01:06 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <4F7EE57D.4020207@oracle.com>
	<4F7F57A502000078000821B6@nat28.tlf.novell.com>
In-Reply-To: <4F7F57A502000078000821B6@nat28.tlf.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F7F4B4D.0028,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/06/2012 03:52 PM, Jan Beulich wrote:
>>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
>> nr_cpus                : 8
>> nr_nodes               : 1
>> cores_per_socket       : 4
>> threads_per_core       : 1
>>
>> I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core
> nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core
It seems on xm/xl info we don't show how many sockets_per_node. Can we do that
in the future?

It seems this machine has: sockets_per_node = 2.

Thanks very much Jan.

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:00:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFKU-0007No-DT; Fri, 06 Apr 2012 20:00:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SGFKS-0007Ne-SA
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 20:00:17 +0000
Received: from [85.158.143.35:16077] by server-3.bemta-4.messagelabs.com id
	6B/FA-05853-05B4F7F4; Fri, 06 Apr 2012 20:00:16 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333742413!11468687!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24637 invoked from network); 6 Apr 2012 20:00:15 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 20:00:15 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36K0Coq001774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:00:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36K0AWc026610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:00:11 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36K084P003029; Fri, 6 Apr 2012 15:00:10 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:00:07 -0700
Message-ID: <4F7F4B82.6040007@oracle.com>
Date: Fri, 06 Apr 2012 16:01:06 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <4F7EE57D.4020207@oracle.com>
	<4F7F57A502000078000821B6@nat28.tlf.novell.com>
In-Reply-To: <4F7F57A502000078000821B6@nat28.tlf.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F7F4B4D.0028,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/06/2012 03:52 PM, Jan Beulich wrote:
>>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
>> nr_cpus                : 8
>> nr_nodes               : 1
>> cores_per_socket       : 4
>> threads_per_core       : 1
>>
>> I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core
> nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core
It seems on xm/xl info we don't show how many sockets_per_node. Can we do that
in the future?

It seems this machine has: sockets_per_node = 2.

Thanks very much Jan.

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFRw-0007dZ-9z; Fri, 06 Apr 2012 20:08:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1SGFRu-0007dU-B3
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:07:58 +0000
Received: from [85.158.143.35:35799] by server-3.bemta-4.messagelabs.com id
	4D/3D-05853-D1D4F7F4; Fri, 06 Apr 2012 20:07:57 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333742876!11602996!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 438 invoked from network); 6 Apr 2012 20:07:57 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 20:07:57 -0000
Received: by lagr15 with SMTP id r15so2794086lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 13:07:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:x-gm-message-state;
	bh=1PJb+XKNp7sVKxUo93DWkNxsKd/rbz6q6LHDRLBP+IM=;
	b=UFiSKGhP/RvE/yBR+8wumWsj3jw4xoIMo+pqp5yI7SMZlh2ZEZqE3OkuWMyfbzi5Um
	r34oVSqG0gbtUX3SDpBJsGM0Yt5onyJevdaw4tsbLvNGltevDeXCZWE0Kdik6V9bEUj4
	XaevLALu8TPYx55DG3blBwZOK5V0guq9k2pwoHVvTGMLTa/aOEujeIwP423etJIj15Ut
	nhpCEqRIkQWTqfePwfBLB534x+lXzq/FYw+QVksQ2thOB+M10FocTamFwl/LpRULYun1
	DjcU4O9/LZbxPrAqMRd9tEF1kE5jIvjiGFkd2KZu4KsB0NYENacyiTIS0/M21di5JMVU
	oBRQ==
MIME-Version: 1.0
Received: by 10.152.123.229 with SMTP id md5mr10214571lab.34.1333742876225;
	Fri, 06 Apr 2012 13:07:56 -0700 (PDT)
Received: by 10.112.42.167 with HTTP; Fri, 6 Apr 2012 13:07:56 -0700 (PDT)
Date: Fri, 6 Apr 2012 13:07:56 -0700
Message-ID: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQmT88xR8J9/74/hGCpceKtGr00wqzEOE1AnYjJr5EbmV/07JWlZMfAKpsXU4pAb593rZFf7
Subject: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1406430526394440979=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1406430526394440979==
Content-Type: multipart/alternative; boundary=f46d04426aa45bf1b204bd0836d0

--f46d04426aa45bf1b204bd0836d0
Content-Type: text/plain; charset=ISO-8859-1

I've been having some problems with Windows HVM domains not shutting down
cleanly.  I have the latest GPLPV drivers installed... although that
doesn't appear to be related.

The symptoms are exactly like this bug and it only occurs with xl.
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1769

In addition to that, it only seems to occur with a secondary graphics card
being passed through.
I end up with a null domain that I can't shutdown.

Killing the qemu-dm process with kill pid sorts that out though.

I'm running dom0 kernel 2.6.32.50.

Matt

--f46d04426aa45bf1b204bd0836d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;ve been having some problems with Windows HVM domains not shutting do=
wn cleanly. =A0I have the latest GPLPV=A0drivers installed... although that=
 doesn&#39;t appear to be related.<div><div><br></div><div>The symptoms are=
 exactly like this bug and it only occurs with xl.</div>
<div><a href=3D"http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769">ht=
tp://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769</a></div><div><br></d=
iv><div>In addition to that, it only seems to occur with a secondary graphi=
cs card being passed through.</div>
<div>I end up with a null domain that I can&#39;t shutdown.</div><div><br><=
/div><div>Killing the qemu-dm process with kill pid sorts that out though.<=
/div><div><br></div><div>I&#39;m running dom0 kernel 2.6.32.50.</div><div>
<br></div><div>Matt</div><div><br></div></div>

--f46d04426aa45bf1b204bd0836d0--


--===============1406430526394440979==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1406430526394440979==--


From xen-devel-bounces@lists.xen.org Fri Apr 06 20:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFRw-0007dZ-9z; Fri, 06 Apr 2012 20:08:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1SGFRu-0007dU-B3
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:07:58 +0000
Received: from [85.158.143.35:35799] by server-3.bemta-4.messagelabs.com id
	4D/3D-05853-D1D4F7F4; Fri, 06 Apr 2012 20:07:57 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333742876!11602996!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 438 invoked from network); 6 Apr 2012 20:07:57 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 20:07:57 -0000
Received: by lagr15 with SMTP id r15so2794086lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 13:07:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:x-gm-message-state;
	bh=1PJb+XKNp7sVKxUo93DWkNxsKd/rbz6q6LHDRLBP+IM=;
	b=UFiSKGhP/RvE/yBR+8wumWsj3jw4xoIMo+pqp5yI7SMZlh2ZEZqE3OkuWMyfbzi5Um
	r34oVSqG0gbtUX3SDpBJsGM0Yt5onyJevdaw4tsbLvNGltevDeXCZWE0Kdik6V9bEUj4
	XaevLALu8TPYx55DG3blBwZOK5V0guq9k2pwoHVvTGMLTa/aOEujeIwP423etJIj15Ut
	nhpCEqRIkQWTqfePwfBLB534x+lXzq/FYw+QVksQ2thOB+M10FocTamFwl/LpRULYun1
	DjcU4O9/LZbxPrAqMRd9tEF1kE5jIvjiGFkd2KZu4KsB0NYENacyiTIS0/M21di5JMVU
	oBRQ==
MIME-Version: 1.0
Received: by 10.152.123.229 with SMTP id md5mr10214571lab.34.1333742876225;
	Fri, 06 Apr 2012 13:07:56 -0700 (PDT)
Received: by 10.112.42.167 with HTTP; Fri, 6 Apr 2012 13:07:56 -0700 (PDT)
Date: Fri, 6 Apr 2012 13:07:56 -0700
Message-ID: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQmT88xR8J9/74/hGCpceKtGr00wqzEOE1AnYjJr5EbmV/07JWlZMfAKpsXU4pAb593rZFf7
Subject: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1406430526394440979=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1406430526394440979==
Content-Type: multipart/alternative; boundary=f46d04426aa45bf1b204bd0836d0

--f46d04426aa45bf1b204bd0836d0
Content-Type: text/plain; charset=ISO-8859-1

I've been having some problems with Windows HVM domains not shutting down
cleanly.  I have the latest GPLPV drivers installed... although that
doesn't appear to be related.

The symptoms are exactly like this bug and it only occurs with xl.
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1769

In addition to that, it only seems to occur with a secondary graphics card
being passed through.
I end up with a null domain that I can't shutdown.

Killing the qemu-dm process with kill pid sorts that out though.

I'm running dom0 kernel 2.6.32.50.

Matt

--f46d04426aa45bf1b204bd0836d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;ve been having some problems with Windows HVM domains not shutting do=
wn cleanly. =A0I have the latest GPLPV=A0drivers installed... although that=
 doesn&#39;t appear to be related.<div><div><br></div><div>The symptoms are=
 exactly like this bug and it only occurs with xl.</div>
<div><a href=3D"http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769">ht=
tp://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769</a></div><div><br></d=
iv><div>In addition to that, it only seems to occur with a secondary graphi=
cs card being passed through.</div>
<div>I end up with a null domain that I can&#39;t shutdown.</div><div><br><=
/div><div>Killing the qemu-dm process with kill pid sorts that out though.<=
/div><div><br></div><div>I&#39;m running dom0 kernel 2.6.32.50.</div><div>
<br></div><div>Matt</div><div><br></div></div>

--f46d04426aa45bf1b204bd0836d0--


--===============1406430526394440979==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1406430526394440979==--


From xen-devel-bounces@lists.xen.org Fri Apr 06 20:18:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFc5-0007q4-D9; Fri, 06 Apr 2012 20:18:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFc4-0007pz-9r
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:18:28 +0000
Received: from [85.158.139.83:9464] by server-1.bemta-5.messagelabs.com id
	ED/92-28458-39F4F7F4; Fri, 06 Apr 2012 20:18:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333743505!18516637!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3267 invoked from network); 6 Apr 2012 20:18:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 20:18:26 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36KINih020098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:18:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36KIMIg020595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:18:23 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36KIL23011863; Fri, 6 Apr 2012 15:18:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:18:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BF82B4032C; Fri,  6 Apr 2012 16:13:43 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:13:43 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matthew Hook <matthew.hook@otoy.com>
Message-ID: <20120406201343.GA20747@phenom.dumpdata.com>
References: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F7F4F90.005E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:
> I've been having some problems with Windows HVM domains not shutting down
> cleanly.  I have the latest GPLPV drivers installed... although that
> doesn't appear to be related.
> 
> The symptoms are exactly like this bug and it only occurs with xl.
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1769
> 
> In addition to that, it only seems to occur with a secondary graphics card
> being passed through.
> I end up with a null domain that I can't shutdown.
> 
> Killing the qemu-dm process with kill pid sorts that out though.

I think that was a bug with Xen. Have you tried to upgrade to the most
recent version?
> 
> I'm running dom0 kernel 2.6.32.50.

I don't recall that having an impact, but maybe it did..
Do you see the problem if you are running with the 3.3 kernel?

> 
> Matt

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:18:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFc5-0007q4-D9; Fri, 06 Apr 2012 20:18:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFc4-0007pz-9r
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:18:28 +0000
Received: from [85.158.139.83:9464] by server-1.bemta-5.messagelabs.com id
	ED/92-28458-39F4F7F4; Fri, 06 Apr 2012 20:18:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333743505!18516637!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3267 invoked from network); 6 Apr 2012 20:18:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Apr 2012 20:18:26 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36KINih020098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:18:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36KIMIg020595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:18:23 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36KIL23011863; Fri, 6 Apr 2012 15:18:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:18:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BF82B4032C; Fri,  6 Apr 2012 16:13:43 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:13:43 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matthew Hook <matthew.hook@otoy.com>
Message-ID: <20120406201343.GA20747@phenom.dumpdata.com>
References: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F7F4F90.005E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:
> I've been having some problems with Windows HVM domains not shutting down
> cleanly.  I have the latest GPLPV drivers installed... although that
> doesn't appear to be related.
> 
> The symptoms are exactly like this bug and it only occurs with xl.
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1769
> 
> In addition to that, it only seems to occur with a secondary graphics card
> being passed through.
> I end up with a null domain that I can't shutdown.
> 
> Killing the qemu-dm process with kill pid sorts that out though.

I think that was a bug with Xen. Have you tried to upgrade to the most
recent version?
> 
> I'm running dom0 kernel 2.6.32.50.

I don't recall that having an impact, but maybe it did..
Do you see the problem if you are running with the 3.3 kernel?

> 
> Matt

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:23:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFgc-0007xb-3B; Fri, 06 Apr 2012 20:23:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1SGFgb-0007xS-6A
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:23:09 +0000
Received: from [85.158.139.83:11412] by server-11.bemta-5.messagelabs.com id
	3E/49-12959-CA05F7F4; Fri, 06 Apr 2012 20:23:08 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333743786!22788073!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19319 invoked from network); 6 Apr 2012 20:23:07 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 20:23:07 -0000
Received: by lagr15 with SMTP id r15so2799986lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 13:23:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=OrYijQgZ707cGbxo+zRn6q3+FmycChmsGB7V5HTItK4=;
	b=nw9Q1U/+Lwi7r5/QlFbJ39ngi0e4r86lIIvp3iGYEH2vTwVcWDdSH/HGRrHARsifrt
	jwf2kbefA+OgKvH7ikE8rROIcHfcWhUh84aJW1dav9GraYoxphlC1CQwTUunf55xdhqi
	m921urNyzpnZ+t6AwcZu0jqMFJRe4YFJg6vDXcQWHkR7MmC+NnJYTZhv+dL8eND8hBVz
	5Q9DWb9mRaskFDLWnpwUJ/hlSIFSJd2f8QPYnHuad77GLrBsfX+NRs8QoH/tk7XkK5r2
	Wjukjl3f2kZFcH6QGSl+ai9BOGGrZegty3otMBO4ao7YrVJ+OC2t6vWQt6n4aicvKx5S
	uGVA==
MIME-Version: 1.0
Received: by 10.152.129.137 with SMTP id nw9mr10253228lab.48.1333743786595;
	Fri, 06 Apr 2012 13:23:06 -0700 (PDT)
Received: by 10.112.42.167 with HTTP; Fri, 6 Apr 2012 13:23:06 -0700 (PDT)
In-Reply-To: <20120406201343.GA20747@phenom.dumpdata.com>
References: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
	<20120406201343.GA20747@phenom.dumpdata.com>
Date: Fri, 6 Apr 2012 13:23:06 -0700
Message-ID: <CAMrHX2UpGUp2ShbsCFyBFnvAq9-+Qs2gVdVVQGH_gN4YVpenEQ@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Gm-Message-State: ALoCoQlTpef85Lcebqop+dH1iX4LAGxR4qeb0rMDUw4Q5W1mhaOUfgrMbyR9CEqIxGJrHo7xTi8k
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5489817649780855010=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5489817649780855010==
Content-Type: multipart/alternative; boundary=f46d0430878e9f16ac04bd086ca1

--f46d0430878e9f16ac04bd086ca1
Content-Type: text/plain; charset=ISO-8859-1

Konrad, thanks for the reply.

No I haven't tried the latest Xen. It'd be good to test that just to see
whether this bug is still there.
Also kernel 3.3 would be worth trying.
I'll get onto this next week and feedback.

Matt


On 6 April 2012 13:13, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Fri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:
> > I've been having some problems with Windows HVM domains not shutting down
> > cleanly.  I have the latest GPLPV drivers installed... although that
> > doesn't appear to be related.
> >
> > The symptoms are exactly like this bug and it only occurs with xl.
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1769
> >
> > In addition to that, it only seems to occur with a secondary graphics
> card
> > being passed through.
> > I end up with a null domain that I can't shutdown.
> >
> > Killing the qemu-dm process with kill pid sorts that out though.
>
> I think that was a bug with Xen. Have you tried to upgrade to the most
> recent version?
> >
> > I'm running dom0 kernel 2.6.32.50.
>
> I don't recall that having an impact, but maybe it did..
> Do you see the problem if you are running with the 3.3 kernel?
>
> >
> > Matt
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>

--f46d0430878e9f16ac04bd086ca1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Konrad, thanks for the reply.<div><br></div><div>No I haven&#39;t tried the=
 latest Xen.=A0It&#39;d be good to test that just to see whether this bug i=
s still there.</div><div>Also kernel 3.3 would be worth trying.</div><div>
I&#39;ll get onto this next week and feedback.</div><div><br></div><div>Mat=
t</div><div><br></div><div><br><div class=3D"gmail_quote">On 6 April 2012 1=
3:13, Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.=
wilk@oracle.com">konrad.wilk@oracle.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On F=
ri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:<br>
&gt; I&#39;ve been having some problems with Windows HVM domains not shutti=
ng down<br>
&gt; cleanly. =A0I have the latest GPLPV drivers installed... although that=
<br>
&gt; doesn&#39;t appear to be related.<br>
&gt;<br>
&gt; The symptoms are exactly like this bug and it only occurs with xl.<br>
&gt; <a href=3D"http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769" ta=
rget=3D"_blank">http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769</a>=
<br>
&gt;<br>
&gt; In addition to that, it only seems to occur with a secondary graphics =
card<br>
&gt; being passed through.<br>
&gt; I end up with a null domain that I can&#39;t shutdown.<br>
&gt;<br>
&gt; Killing the qemu-dm process with kill pid sorts that out though.<br>
<br>
</div></div>I think that was a bug with Xen. Have you tried to upgrade to t=
he most<br>
recent version?<br>
<div class=3D"im">&gt;<br>
&gt; I&#39;m running dom0 kernel 2.6.32.50.<br>
<br>
</div>I don&#39;t recall that having an impact, but maybe it did..<br>
Do you see the problem if you are running with the 3.3 kernel?<br>
<br>
&gt;<br>
&gt; Matt<br>
<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<br>
</blockquote></div><br></div>

--f46d0430878e9f16ac04bd086ca1--


--===============5489817649780855010==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5489817649780855010==--


From xen-devel-bounces@lists.xen.org Fri Apr 06 20:23:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFgc-0007xb-3B; Fri, 06 Apr 2012 20:23:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1SGFgb-0007xS-6A
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:23:09 +0000
Received: from [85.158.139.83:11412] by server-11.bemta-5.messagelabs.com id
	3E/49-12959-CA05F7F4; Fri, 06 Apr 2012 20:23:08 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333743786!22788073!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19319 invoked from network); 6 Apr 2012 20:23:07 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 20:23:07 -0000
Received: by lagr15 with SMTP id r15so2799986lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 13:23:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=OrYijQgZ707cGbxo+zRn6q3+FmycChmsGB7V5HTItK4=;
	b=nw9Q1U/+Lwi7r5/QlFbJ39ngi0e4r86lIIvp3iGYEH2vTwVcWDdSH/HGRrHARsifrt
	jwf2kbefA+OgKvH7ikE8rROIcHfcWhUh84aJW1dav9GraYoxphlC1CQwTUunf55xdhqi
	m921urNyzpnZ+t6AwcZu0jqMFJRe4YFJg6vDXcQWHkR7MmC+NnJYTZhv+dL8eND8hBVz
	5Q9DWb9mRaskFDLWnpwUJ/hlSIFSJd2f8QPYnHuad77GLrBsfX+NRs8QoH/tk7XkK5r2
	Wjukjl3f2kZFcH6QGSl+ai9BOGGrZegty3otMBO4ao7YrVJ+OC2t6vWQt6n4aicvKx5S
	uGVA==
MIME-Version: 1.0
Received: by 10.152.129.137 with SMTP id nw9mr10253228lab.48.1333743786595;
	Fri, 06 Apr 2012 13:23:06 -0700 (PDT)
Received: by 10.112.42.167 with HTTP; Fri, 6 Apr 2012 13:23:06 -0700 (PDT)
In-Reply-To: <20120406201343.GA20747@phenom.dumpdata.com>
References: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
	<20120406201343.GA20747@phenom.dumpdata.com>
Date: Fri, 6 Apr 2012 13:23:06 -0700
Message-ID: <CAMrHX2UpGUp2ShbsCFyBFnvAq9-+Qs2gVdVVQGH_gN4YVpenEQ@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Gm-Message-State: ALoCoQlTpef85Lcebqop+dH1iX4LAGxR4qeb0rMDUw4Q5W1mhaOUfgrMbyR9CEqIxGJrHo7xTi8k
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5489817649780855010=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5489817649780855010==
Content-Type: multipart/alternative; boundary=f46d0430878e9f16ac04bd086ca1

--f46d0430878e9f16ac04bd086ca1
Content-Type: text/plain; charset=ISO-8859-1

Konrad, thanks for the reply.

No I haven't tried the latest Xen. It'd be good to test that just to see
whether this bug is still there.
Also kernel 3.3 would be worth trying.
I'll get onto this next week and feedback.

Matt


On 6 April 2012 13:13, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Fri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:
> > I've been having some problems with Windows HVM domains not shutting down
> > cleanly.  I have the latest GPLPV drivers installed... although that
> > doesn't appear to be related.
> >
> > The symptoms are exactly like this bug and it only occurs with xl.
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1769
> >
> > In addition to that, it only seems to occur with a secondary graphics
> card
> > being passed through.
> > I end up with a null domain that I can't shutdown.
> >
> > Killing the qemu-dm process with kill pid sorts that out though.
>
> I think that was a bug with Xen. Have you tried to upgrade to the most
> recent version?
> >
> > I'm running dom0 kernel 2.6.32.50.
>
> I don't recall that having an impact, but maybe it did..
> Do you see the problem if you are running with the 3.3 kernel?
>
> >
> > Matt
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>

--f46d0430878e9f16ac04bd086ca1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Konrad, thanks for the reply.<div><br></div><div>No I haven&#39;t tried the=
 latest Xen.=A0It&#39;d be good to test that just to see whether this bug i=
s still there.</div><div>Also kernel 3.3 would be worth trying.</div><div>
I&#39;ll get onto this next week and feedback.</div><div><br></div><div>Mat=
t</div><div><br></div><div><br><div class=3D"gmail_quote">On 6 April 2012 1=
3:13, Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.=
wilk@oracle.com">konrad.wilk@oracle.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On F=
ri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:<br>
&gt; I&#39;ve been having some problems with Windows HVM domains not shutti=
ng down<br>
&gt; cleanly. =A0I have the latest GPLPV drivers installed... although that=
<br>
&gt; doesn&#39;t appear to be related.<br>
&gt;<br>
&gt; The symptoms are exactly like this bug and it only occurs with xl.<br>
&gt; <a href=3D"http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769" ta=
rget=3D"_blank">http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769</a>=
<br>
&gt;<br>
&gt; In addition to that, it only seems to occur with a secondary graphics =
card<br>
&gt; being passed through.<br>
&gt; I end up with a null domain that I can&#39;t shutdown.<br>
&gt;<br>
&gt; Killing the qemu-dm process with kill pid sorts that out though.<br>
<br>
</div></div>I think that was a bug with Xen. Have you tried to upgrade to t=
he most<br>
recent version?<br>
<div class=3D"im">&gt;<br>
&gt; I&#39;m running dom0 kernel 2.6.32.50.<br>
<br>
</div>I don&#39;t recall that having an impact, but maybe it did..<br>
Do you see the problem if you are running with the 3.3 kernel?<br>
<br>
&gt;<br>
&gt; Matt<br>
<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<br>
</blockquote></div><br></div>

--f46d0430878e9f16ac04bd086ca1--


--===============5489817649780855010==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5489817649780855010==--


From xen-devel-bounces@lists.xen.org Fri Apr 06 20:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFtn-00088p-E5; Fri, 06 Apr 2012 20:36:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFtm-00088k-1o
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:36:46 +0000
Received: from [85.158.139.83:27052] by server-4.bemta-5.messagelabs.com id
	93/A1-10788-DD35F7F4; Fri, 06 Apr 2012 20:36:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333744593!22812196!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4220 invoked from network); 6 Apr 2012 20:36:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 20:36:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36KaVre003772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:36:32 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36KaVqR011592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:36:31 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36KaUS8020764; Fri, 6 Apr 2012 15:36:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:36:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4731E4032C; Fri,  6 Apr 2012 16:31:52 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:31:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Vijay Chander <vijay.chander@gmail.com>
Message-ID: <20120406203152.GB15674@phenom.dumpdata.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
	<CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F7F53D0.0043,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
 appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Feb 25, 2012 at 07:46:36AM -0800, Vijay Chander wrote:
> If anybody encountered a similar situation as below where the netfront TX
> ring is stuck ,
> can you pls provide some pointers on how to get around this problem ?
> 
> This typically happens after about 2days of overnight traffic tests.

What kind of traffic? As in netperf for 48hrs? Is this from guest to guest
traffic or from outside host to the guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFtn-00088p-E5; Fri, 06 Apr 2012 20:36:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFtm-00088k-1o
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:36:46 +0000
Received: from [85.158.139.83:27052] by server-4.bemta-5.messagelabs.com id
	93/A1-10788-DD35F7F4; Fri, 06 Apr 2012 20:36:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1333744593!22812196!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4220 invoked from network); 6 Apr 2012 20:36:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 20:36:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36KaVre003772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:36:32 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36KaVqR011592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:36:31 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36KaUS8020764; Fri, 6 Apr 2012 15:36:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:36:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4731E4032C; Fri,  6 Apr 2012 16:31:52 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:31:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Vijay Chander <vijay.chander@gmail.com>
Message-ID: <20120406203152.GB15674@phenom.dumpdata.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
	<CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F7F53D0.0043,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
 appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Feb 25, 2012 at 07:46:36AM -0800, Vijay Chander wrote:
> If anybody encountered a similar situation as below where the netfront TX
> ring is stuck ,
> can you pls provide some pointers on how to get around this problem ?
> 
> This typically happens after about 2days of overnight traffic tests.

What kind of traffic? As in netperf for 48hrs? Is this from guest to guest
traffic or from outside host to the guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:39:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFwU-0008Gp-4T; Fri, 06 Apr 2012 20:39:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFwR-0008Gj-Tc
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:39:32 +0000
Received: from [85.158.143.99:55159] by server-2.bemta-4.messagelabs.com id
	0C/98-17550-3845F7F4; Fri, 06 Apr 2012 20:39:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333744769!22670036!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 6 Apr 2012 20:39:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 20:39:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36KdQl7027664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:39:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36KdQrd025477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:39:26 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36KdPV5022761; Fri, 6 Apr 2012 15:39:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:39:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D6B054032C; Fri,  6 Apr 2012 16:34:47 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:34:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Castro <evil.dani@gmail.com>
Message-ID: <20120406203447.GC15674@phenom.dumpdata.com>
References: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F7F547F.00A4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 09, 2012 at 08:35:40AM +0900, Daniel Castro wrote:
> Hello All,
> =

> I have a little setback with the development of PV Drivers for Xen in Sea=
BIOS.

Hey, seems I read your emails out of sync.

> The initialization code that runs in 32 Bit is working properly.
> But, when the system tries to read on the disk I use the ring macros
> to get a request. The macro usage looks like this:
> struct blkif_ring * shared =3D memalign_low(4096,4096); //return
> 0x000fd630 this above 16bit address space
> SHARED_RING_INIT(shared);
> So far I have a pointer located at 0x0009a000
> Under 32bit the struct is correct and all is working according to plan.
> =

> But on 16bit operation read on disk I have
> struct blkfront_info * shared_ring =3D
> container_of(op->drive_g.info->shared)); // I get d630 I should get it
> from the correct segment, but how?
> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
> something 0xa010 segment SS or something like that
> =

> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by
> changing the segment register, yet I do not know in what segment the
> ring is located, and the macros are not applied inside the procedure
> of the macro, for example:

There should be some way to set your physical address (so
9a000) to a segment?

> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
> But this will change a 16Bit pointer of segment SS to a 32 bit
> segment. There is also the reverse but, again I do not know the
> segment in which I should look for. Lastly the process inside the
> macro does not get this benefin, and I do not know if the macro will
> work with a pointer of size 16bits.

16-bits should be fine. The problem is if you run your pointer
outside the 16-bit segment.

> =

> Any help will be GREATLY appreciated, I am almost done.
> =

> Thanks,
> =

> Daniel
> -- =

> +-=3D=3D=3D=3D=3D---------------------------+
> | +---------------------------------+ | This space intentionally blank
> for notetaking.
> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> | |=A0=A0 | Consultant/Programmer.|
> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
> +-------------------------------------+
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 20:39:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 20:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGFwU-0008Gp-4T; Fri, 06 Apr 2012 20:39:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGFwR-0008Gj-Tc
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 20:39:32 +0000
Received: from [85.158.143.99:55159] by server-2.bemta-4.messagelabs.com id
	0C/98-17550-3845F7F4; Fri, 06 Apr 2012 20:39:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1333744769!22670036!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 6 Apr 2012 20:39:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 20:39:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36KdQl7027664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 20:39:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36KdQrd025477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 20:39:26 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36KdPV5022761; Fri, 6 Apr 2012 15:39:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 13:39:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D6B054032C; Fri,  6 Apr 2012 16:34:47 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:34:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Castro <evil.dani@gmail.com>
Message-ID: <20120406203447.GC15674@phenom.dumpdata.com>
References: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F7F547F.00A4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 09, 2012 at 08:35:40AM +0900, Daniel Castro wrote:
> Hello All,
> =

> I have a little setback with the development of PV Drivers for Xen in Sea=
BIOS.

Hey, seems I read your emails out of sync.

> The initialization code that runs in 32 Bit is working properly.
> But, when the system tries to read on the disk I use the ring macros
> to get a request. The macro usage looks like this:
> struct blkif_ring * shared =3D memalign_low(4096,4096); //return
> 0x000fd630 this above 16bit address space
> SHARED_RING_INIT(shared);
> So far I have a pointer located at 0x0009a000
> Under 32bit the struct is correct and all is working according to plan.
> =

> But on 16bit operation read on disk I have
> struct blkfront_info * shared_ring =3D
> container_of(op->drive_g.info->shared)); // I get d630 I should get it
> from the correct segment, but how?
> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
> something 0xa010 segment SS or something like that
> =

> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by
> changing the segment register, yet I do not know in what segment the
> ring is located, and the macros are not applied inside the procedure
> of the macro, for example:

There should be some way to set your physical address (so
9a000) to a segment?

> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
> But this will change a 16Bit pointer of segment SS to a 32 bit
> segment. There is also the reverse but, again I do not know the
> segment in which I should look for. Lastly the process inside the
> macro does not get this benefin, and I do not know if the macro will
> work with a pointer of size 16bits.

16-bits should be fine. The problem is if you run your pointer
outside the 16-bit segment.

> =

> Any help will be GREATLY appreciated, I am almost done.
> =

> Thanks,
> =

> Daniel
> -- =

> +-=3D=3D=3D=3D=3D---------------------------+
> | +---------------------------------+ | This space intentionally blank
> for notetaking.
> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> | |=A0=A0 | Consultant/Programmer.|
> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
> +-------------------------------------+
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:04:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGK5-00008u-7K; Fri, 06 Apr 2012 21:03:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGGK4-00008p-DN
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 21:03:56 +0000
Received: from [85.158.143.99:58811] by server-3.bemta-4.messagelabs.com id
	B2/DB-05853-B3A5F7F4; Fri, 06 Apr 2012 21:03:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333746233!24099290!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21109 invoked from network); 6 Apr 2012 21:03:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:03:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L3nda027984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:03:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L3mkt024040
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:03:49 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L3loB002326; Fri, 6 Apr 2012 16:03:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 14:03:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8F21B4032C; Fri,  6 Apr 2012 16:59:09 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:59:09 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120406205909.GA26309@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7ABBC4.4050106@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F7F5A37.004A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:58:44AM +0100, David Vrabel wrote:
> On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> > Meaning that we will allocate up to XGB and not consider the
> > rest of the memory as a possible balloon goal.
> 
> I agree with Jan when he commented on the equivalent Xen patch for this
> behaviour.  The current behaviour is better than the classic one.

Current behavior in the hypervisor or with current Linux kernel?
> 
> With your new behaviour it will no longer possible to specify an
> unlimited balloon but a limited number of initial pages.  This is
> behaviour that Jan said he used.

I am not sure I see the problem - I mean if one uses:

dom0_mem=min:8G,max:16G

I understand that we want to start at 8GB and if the user
choose to - balloon up to 16GB.

But doing this:

dom0_mem=8G

and allocating pagetables up to .. say 32GB, seems counter-intuive
as the effect is similar to having no 'dom0_mem' except that the initial
size is smaller.

> 
> This problem is better solved by improving the documentation.  A review
> of the xen.org wiki where dom0_mem is mentioned would be a good start,
> and an update to the recently added section for distro developers.
> 
> David
> 
> > This results in /proc/meminfo reporting:
> > 
> > -MemTotal:        2845024 kB
> > -MemFree:         2497716 kB
> > +MemTotal:        2927192 kB
> > +MemFree:         2458952 kB
> >  ...
> > -DirectMap4k:     8304640 kB
> > +DirectMap4k:     3063808 kB
> >  DirectMap2M:           0 kB
> > 
> > on a 8GB machine with 'dom0_mem=3GB' on the Xen hypervisor line.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/setup.c |   16 ++++++++++++++++
> >  1 files changed, 16 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 2a12143..4e4aa8e 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -261,11 +261,27 @@ static unsigned long __init xen_get_max_pages(void)
> >  	 * the current maximum rather than the static maximum. In this
> >  	 * case the e820 map provided to us will cover the static
> >  	 * maximum region.
> > +	 *
> > +	 * The dom0_mem=min:X,max:Y tweaks options differently depending
> > +	 * on the version, but in general this is what we get:
> > +	 *                | XENMEM_maximum_reser  | nr_pages
> > +	 * --------------++-----------------------+-------------------
> > +	 *  no dom0_mem   | INT_MAX               | the max_phys_pfn
> > +	 *  =3G           | INT_MAX               | 786432
> > +	 *  =max:3G       | 786432                | 786432
> > +	 *  =min:1G,max:3G| 262144                | 786432
> > +	 *
> > +	 * The =3G is often used and it lead to us initially setting
> > +	 * 786432 and allowing dom0 to balloon up to the max_physical_pfn.
> > +	 * This is at odd with the classic XenOClassic so lets emulate
> > +	 * the classic behavior.
> >  	 */
> >  	if (xen_initial_domain()) {
> >  		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> >  		if (ret > 0)
> >  			max_pages = ret;
> > +		if (ret == -1UL)
> > +			max_pages = xen_start_info->nr_pages;
> >  	}
> >  
> >  	return min(max_pages, MAX_DOMAIN_PAGES);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:04:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGK5-00008u-7K; Fri, 06 Apr 2012 21:03:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGGK4-00008p-DN
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 21:03:56 +0000
Received: from [85.158.143.99:58811] by server-3.bemta-4.messagelabs.com id
	B2/DB-05853-B3A5F7F4; Fri, 06 Apr 2012 21:03:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1333746233!24099290!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21109 invoked from network); 6 Apr 2012 21:03:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:03:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L3nda027984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:03:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L3mkt024040
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:03:49 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L3loB002326; Fri, 6 Apr 2012 16:03:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 14:03:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8F21B4032C; Fri,  6 Apr 2012 16:59:09 -0400 (EDT)
Date: Fri, 6 Apr 2012 16:59:09 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120406205909.GA26309@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7ABBC4.4050106@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F7F5A37.004A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:58:44AM +0100, David Vrabel wrote:
> On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> > Meaning that we will allocate up to XGB and not consider the
> > rest of the memory as a possible balloon goal.
> 
> I agree with Jan when he commented on the equivalent Xen patch for this
> behaviour.  The current behaviour is better than the classic one.

Current behavior in the hypervisor or with current Linux kernel?
> 
> With your new behaviour it will no longer possible to specify an
> unlimited balloon but a limited number of initial pages.  This is
> behaviour that Jan said he used.

I am not sure I see the problem - I mean if one uses:

dom0_mem=min:8G,max:16G

I understand that we want to start at 8GB and if the user
choose to - balloon up to 16GB.

But doing this:

dom0_mem=8G

and allocating pagetables up to .. say 32GB, seems counter-intuive
as the effect is similar to having no 'dom0_mem' except that the initial
size is smaller.

> 
> This problem is better solved by improving the documentation.  A review
> of the xen.org wiki where dom0_mem is mentioned would be a good start,
> and an update to the recently added section for distro developers.
> 
> David
> 
> > This results in /proc/meminfo reporting:
> > 
> > -MemTotal:        2845024 kB
> > -MemFree:         2497716 kB
> > +MemTotal:        2927192 kB
> > +MemFree:         2458952 kB
> >  ...
> > -DirectMap4k:     8304640 kB
> > +DirectMap4k:     3063808 kB
> >  DirectMap2M:           0 kB
> > 
> > on a 8GB machine with 'dom0_mem=3GB' on the Xen hypervisor line.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/setup.c |   16 ++++++++++++++++
> >  1 files changed, 16 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 2a12143..4e4aa8e 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -261,11 +261,27 @@ static unsigned long __init xen_get_max_pages(void)
> >  	 * the current maximum rather than the static maximum. In this
> >  	 * case the e820 map provided to us will cover the static
> >  	 * maximum region.
> > +	 *
> > +	 * The dom0_mem=min:X,max:Y tweaks options differently depending
> > +	 * on the version, but in general this is what we get:
> > +	 *                | XENMEM_maximum_reser  | nr_pages
> > +	 * --------------++-----------------------+-------------------
> > +	 *  no dom0_mem   | INT_MAX               | the max_phys_pfn
> > +	 *  =3G           | INT_MAX               | 786432
> > +	 *  =max:3G       | 786432                | 786432
> > +	 *  =min:1G,max:3G| 262144                | 786432
> > +	 *
> > +	 * The =3G is often used and it lead to us initially setting
> > +	 * 786432 and allowing dom0 to balloon up to the max_physical_pfn.
> > +	 * This is at odd with the classic XenOClassic so lets emulate
> > +	 * the classic behavior.
> >  	 */
> >  	if (xen_initial_domain()) {
> >  		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> >  		if (ret > 0)
> >  			max_pages = ret;
> > +		if (ret == -1UL)
> > +			max_pages = xen_start_info->nr_pages;
> >  	}
> >  
> >  	return min(max_pages, MAX_DOMAIN_PAGES);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGM8-0000Ds-O4; Fri, 06 Apr 2012 21:06:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGGM7-0000Dl-RW
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 21:06:04 +0000
Received: from [85.158.139.83:21626] by server-5.bemta-5.messagelabs.com id
	90/6C-13566-ABA5F7F4; Fri, 06 Apr 2012 21:06:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333746360!18913862!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16170 invoked from network); 6 Apr 2012 21:06:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:06:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L5vIo029797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:05:58 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L5uUT026649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:05:57 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L5ugL025196; Fri, 6 Apr 2012 16:05:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 14:05:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1E5D64032C; Fri,  6 Apr 2012 17:01:18 -0400 (EDT)
Date: Fri, 6 Apr 2012 17:01:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120406210117.GB26309@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<4F7AE321020000780007C456@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7AE321020000780007C456@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F7F5AB6.0099,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 10:46:41AM +0100, Jan Beulich wrote:
> >>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
> > With your new behaviour it will no longer possible to specify an
> > unlimited balloon but a limited number of initial pages.  This is
> > behaviour that Jan said he used.
> 
> An unlimited balloon was never possible afaict (as that would have
> implied setting up an "infinite" number of struct page instances at
> boot time.
> 
> What I'm using is "dom0_mem=-<num>M" together with the kernel
> option "mem=<num>G", such that max-balloon > initial alloc (usually
> I set max-balloon to approximately the amount of memory in the
> system, so the upper limit is "infinite" in the sense that I can't go
> higher anyway, but it's not truly infinity).

Couldn't you do the same thing with 'dom0_mem=X,max:Y'
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGM8-0000Ds-O4; Fri, 06 Apr 2012 21:06:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGGM7-0000Dl-RW
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 21:06:04 +0000
Received: from [85.158.139.83:21626] by server-5.bemta-5.messagelabs.com id
	90/6C-13566-ABA5F7F4; Fri, 06 Apr 2012 21:06:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333746360!18913862!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16170 invoked from network); 6 Apr 2012 21:06:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:06:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L5vIo029797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:05:58 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L5uUT026649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:05:57 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L5ugL025196; Fri, 6 Apr 2012 16:05:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 14:05:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1E5D64032C; Fri,  6 Apr 2012 17:01:18 -0400 (EDT)
Date: Fri, 6 Apr 2012 17:01:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120406210117.GB26309@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<4F7AE321020000780007C456@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7AE321020000780007C456@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F7F5AB6.0099,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 10:46:41AM +0100, Jan Beulich wrote:
> >>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
> > With your new behaviour it will no longer possible to specify an
> > unlimited balloon but a limited number of initial pages.  This is
> > behaviour that Jan said he used.
> 
> An unlimited balloon was never possible afaict (as that would have
> implied setting up an "infinite" number of struct page instances at
> boot time.
> 
> What I'm using is "dom0_mem=-<num>M" together with the kernel
> option "mem=<num>G", such that max-balloon > initial alloc (usually
> I set max-balloon to approximately the amount of memory in the
> system, so the upper limit is "infinite" in the sense that I can't go
> higher anyway, but it's not truly infinity).

Couldn't you do the same thing with 'dom0_mem=X,max:Y'
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:07:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGNI-0000Ig-6f; Fri, 06 Apr 2012 21:07:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGGNG-0000IU-AZ
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 21:07:14 +0000
Received: from [193.109.254.147:53634] by server-9.bemta-14.messagelabs.com id
	D8/75-05787-10B5F7F4; Fri, 06 Apr 2012 21:07:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333746431!3569331!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11313 invoked from network); 6 Apr 2012 21:07:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:07:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L79Lw030862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:07:10 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L784i026959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:07:09 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L78rs003930; Fri, 6 Apr 2012 16:07:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 14:07:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9D7F24032C; Fri,  6 Apr 2012 17:02:30 -0400 (EDT)
Date: Fri, 6 Apr 2012 17:02:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120406210230.GC26309@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
	<4F7AB96B.5030900@citrix.com>
	<20120403131344.GB12464@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120403131344.GB12464@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F7F5AFE.0029,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 5/7] xen/setup: Transfer MFNs from non-RAM
 E820	entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:13:44AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 03, 2012 at 09:48:43AM +0100, David Vrabel wrote:
> > On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> > > We will now get:
> > > 
> > > -Released 283999 pages of unused memory
> > > +Exchanged 283999 pages
> > > .. snip..
> > > -Memory: 6487732k/9208688k available (5817k kernel code, 1136060k absent, 1584896k reserved, 2900k data, 692k init)
> > > +Memory: 6503888k/8072692k available (5817k kernel code, 1136060k absent, 432744k reserved, 2900k data, 692k init)
> > 
> > This isn't correct.  You've have lost ~1 GB of memory which are the
> > pages that were supposed to be moved.  The additional 1GB of reserved
> > memory in the old case is the balloon.
> 
> Whoops.
> > 
> > In xen_memory_setup() where it loops through the e820 to clip the RAM
> > regions you need to factor in the additional memory you've moved.  In
> > this loop you may need to count the pages in the RAM region instead of
> > the simple (addr < mem_end) test.  Take care with RAM regions with
> > partial pages and the like.
> 
> <nods> I did some more exhaustive testing and hit some issues

.. which is that moving the MFNs in the P2M is fine from the Linux kernel perspective
but the changes won't be reflected in the M2P. To make the M2P have the new
PFNs I have to use the populate_physmap hypercall.

A new-ish version will be posted soon.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:07:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGNI-0000Ig-6f; Fri, 06 Apr 2012 21:07:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SGGNG-0000IU-AZ
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 21:07:14 +0000
Received: from [193.109.254.147:53634] by server-9.bemta-14.messagelabs.com id
	D8/75-05787-10B5F7F4; Fri, 06 Apr 2012 21:07:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333746431!3569331!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1NzEwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11313 invoked from network); 6 Apr 2012 21:07:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:07:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L79Lw030862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:07:10 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L784i026959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:07:09 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L78rs003930; Fri, 6 Apr 2012 16:07:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Apr 2012 14:07:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9D7F24032C; Fri,  6 Apr 2012 17:02:30 -0400 (EDT)
Date: Fri, 6 Apr 2012 17:02:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120406210230.GC26309@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-6-git-send-email-konrad.wilk@oracle.com>
	<4F7AB96B.5030900@citrix.com>
	<20120403131344.GB12464@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120403131344.GB12464@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F7F5AFE.0029,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 5/7] xen/setup: Transfer MFNs from non-RAM
 E820	entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, 2012 at 09:13:44AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 03, 2012 at 09:48:43AM +0100, David Vrabel wrote:
> > On 30/03/12 21:37, Konrad Rzeszutek Wilk wrote:
> > > We will now get:
> > > 
> > > -Released 283999 pages of unused memory
> > > +Exchanged 283999 pages
> > > .. snip..
> > > -Memory: 6487732k/9208688k available (5817k kernel code, 1136060k absent, 1584896k reserved, 2900k data, 692k init)
> > > +Memory: 6503888k/8072692k available (5817k kernel code, 1136060k absent, 432744k reserved, 2900k data, 692k init)
> > 
> > This isn't correct.  You've have lost ~1 GB of memory which are the
> > pages that were supposed to be moved.  The additional 1GB of reserved
> > memory in the old case is the balloon.
> 
> Whoops.
> > 
> > In xen_memory_setup() where it loops through the e820 to clip the RAM
> > regions you need to factor in the additional memory you've moved.  In
> > this loop you may need to count the pages in the RAM region instead of
> > the simple (addr < mem_end) test.  Take care with RAM regions with
> > partial pages and the like.
> 
> <nods> I did some more exhaustive testing and hit some issues

.. which is that moving the MFNs in the P2M is fine from the Linux kernel perspective
but the changes won't be reflected in the M2P. To make the M2P have the new
PFNs I have to use the populate_physmap hypercall.

A new-ish version will be posted soon.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGPY-0000TV-OQ; Fri, 06 Apr 2012 21:09:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SGGPX-0000TL-NE
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 21:09:35 +0000
Received: from [85.158.138.51:63074] by server-8.bemta-3.messagelabs.com id
	0F/E2-29305-E8B5F7F4; Fri, 06 Apr 2012 21:09:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333746572!21100948!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14909 invoked from network); 6 Apr 2012 21:09:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:09:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L9TR3014075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:09:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L9T4d020010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:09:29 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L9TYZ026733; Fri, 6 Apr 2012 16:09:29 -0500
MIME-Version: 1.0
Message-ID: <38323a78-6bbd-4206-a2b0-e637240f68bf@default>
Date: Fri, 6 Apr 2012 14:09:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>, Jan Beulich <jbeulich@suse.com>
References: <4F7EE57D.4020207@oracle.com>
	<4F7F57A502000078000821B6@nat28.tlf.novell.com>
	<4F7F4B82.6040007@oracle.com>
In-Reply-To: <4F7F4B82.6040007@oracle.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F7F5B8B.0010,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Zhigang Wang
> Sent: Friday, April 06, 2012 2:01 PM
> To: Jan Beulich
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] strange cpu number from xm info
> 
> On 04/06/2012 03:52 PM, Jan Beulich wrote:
> >>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
> >> nr_cpus                : 8
> >> nr_nodes               : 1
> >> cores_per_socket       : 4
> >> threads_per_core       : 1
> >>
> >> I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core
> > nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core
> It seems on xm/xl info we don't show how many sockets_per_node. Can we do that
> in the future?
> 
> It seems this machine has: sockets_per_node = 2.
> 
> Thanks very much Jan.
> 
> Zhigang

Hi Zhigang --

Unfortunately, the world of CPUs is getting more complicated
and can no longer be described so simply.  See for example:

http://lists.xen.org/archives/html/xen-devel/2009-11/msg00885.html 

On a Friday afternoon, this makes my head hurt...

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGPY-0000TV-OQ; Fri, 06 Apr 2012 21:09:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SGGPX-0000TL-NE
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 21:09:35 +0000
Received: from [85.158.138.51:63074] by server-8.bemta-3.messagelabs.com id
	0F/E2-29305-E8B5F7F4; Fri, 06 Apr 2012 21:09:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333746572!21100948!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYxNDg1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14909 invoked from network); 6 Apr 2012 21:09:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Apr 2012 21:09:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q36L9TR3014075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Apr 2012 21:09:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q36L9T4d020010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2012 21:09:29 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q36L9TYZ026733; Fri, 6 Apr 2012 16:09:29 -0500
MIME-Version: 1.0
Message-ID: <38323a78-6bbd-4206-a2b0-e637240f68bf@default>
Date: Fri, 6 Apr 2012 14:09:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>, Jan Beulich <jbeulich@suse.com>
References: <4F7EE57D.4020207@oracle.com>
	<4F7F57A502000078000821B6@nat28.tlf.novell.com>
	<4F7F4B82.6040007@oracle.com>
In-Reply-To: <4F7F4B82.6040007@oracle.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F7F5B8B.0010,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Zhigang Wang
> Sent: Friday, April 06, 2012 2:01 PM
> To: Jan Beulich
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] strange cpu number from xm info
> 
> On 04/06/2012 03:52 PM, Jan Beulich wrote:
> >>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
> >> nr_cpus                : 8
> >> nr_nodes               : 1
> >> cores_per_socket       : 4
> >> threads_per_core       : 1
> >>
> >> I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core
> > nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core
> It seems on xm/xl info we don't show how many sockets_per_node. Can we do that
> in the future?
> 
> It seems this machine has: sockets_per_node = 2.
> 
> Thanks very much Jan.
> 
> Zhigang

Hi Zhigang --

Unfortunately, the world of CPUs is getting more complicated
and can no longer be described so simply.  See for example:

http://lists.xen.org/archives/html/xen-devel/2009-11/msg00885.html 

On a Friday afternoon, this makes my head hurt...

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 21:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGe7-0000me-6I; Fri, 06 Apr 2012 21:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <twwood@gmail.com>) id 1SGGe5-0000mZ-Mu
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 21:24:37 +0000
Received: from [193.109.254.147:49206] by server-6.bemta-14.messagelabs.com id
	3E/B0-02047-51F5F7F4; Fri, 06 Apr 2012 21:24:37 +0000
X-Env-Sender: twwood@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333747475!3561538!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31240 invoked from network); 6 Apr 2012 21:24:36 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 21:24:36 -0000
Received: by wgbed3 with SMTP id ed3so1906142wgb.32
	for <xen-devel@lists.xen.org>; Fri, 06 Apr 2012 14:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=3oAdRxJEb/h393ACEbucQXNRnFu79CSZCw4ZHM46hrg=;
	b=Wu/V+yma/8Tfy1SpzZXRx1fXuTowKxV9veYKEePej6XmB2HdwK+ihuolcnstnMrcUg
	fAIDeWu+ATwpfqBgV2LG3EagU6Wg8MdZ3y4BTAVkZn3D++b4QpIz7RLhOWuPCHjDc18h
	ST+z8k2s8L0inVJV12UtEHhpxv56sBvqU3As5wfZM5NgPcPg3LqWe+7zArK0jWE29KEZ
	N7soFU4yi8iJqwALPHn729fmCVxnm7zaqtZyCstbGdHlvpP447EiBCZIh9AAsCfUro9L
	F5dfzFNDVWybVNZJnaSu7Ab2kUK1O0tniAXB4WjFf3yQ9Jacr3m8+6HDj4P2mjZja2I8
	7C5g==
Received: by 10.216.132.169 with SMTP id o41mr4504245wei.121.1333747475693;
	Fri, 06 Apr 2012 14:24:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.75 with HTTP; Fri, 6 Apr 2012 14:24:15 -0700 (PDT)
From: Tim Wood <twwood@gmail.com>
Date: Fri, 6 Apr 2012 17:24:15 -0400
Message-ID: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7674020407171484074=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7674020407171484074==
Content-Type: multipart/alternative; boundary=0016e6dd8bfc823ef404bd094890

--0016e6dd8bfc823ef404bd094890
Content-Type: text/plain; charset=ISO-8859-1

In xen 4.0.X I was able to write custom blktap2 drivers as a nice way to
intercept VM disk traffic.  I'm now trying to take a step up to xen 4.1.2
and find that blktap2 doesn't seem to be supported anymore, or at least it
requires a kernel module which I'm not sure where to find.  Is blktap2
still in use, or is there an entirely different way I should be approaching
this?

Previously I could run commands like:

tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img

the new tapdisk2 doesn't support that interface anymore, but it seems like
the correct approach is now:

xm block-attach 0 tap2:aio:/path/disk.img xvda w 0
Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
module not installed )

What is the "proper" way of getting the blktap kernel module installed?  I
found this:
http://packages.debian.org/sid/blktap-dkms

but couldn't get it to actually install.  In any case, it seems unlikely
that is the best way to go.

Also, I will admit that I am running 4.1.2 (from source) rather than
unstable---looking through the threads here doesn't make it sound like
upgrading to that will fix anything, but I can do so if need be.

thanks for any suggestions

--0016e6dd8bfc823ef404bd094890
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>In xen 4.0.X I was able to write custom blktap2 drivers as a nice way =
to intercept VM disk traffic. =A0I&#39;m now trying to take a step up to xe=
n 4.1.2 and find that blktap2 doesn&#39;t seem to be supported anymore, or =
at least it requires a kernel module which I&#39;m not sure where to find. =
=A0Is blktap2 still in use, or is there an entirely different way I should =
be approaching this?</div>

<div><br></div><div>Previously I could run commands like:</div><div><br></d=
iv><div><span style=3D"background-color:rgb(255,255,255);font-size:12px;lin=
e-height:20px;text-align:justify">tapdisk2 -n tap:aio:/home/twood/vms/testd=
isk.img</span>=A0</div>

<div><br></div><div>the new tapdisk2 doesn&#39;t support that interface any=
more, but it seems like the correct approach is now:</div><div><br></div><d=
iv><div>xm block-attach 0 tap2:aio:/path/disk.img xvda w 0=A0</div><div>
Error: (&#39;create&#39;, &#39;-aaio:/path/disk.img&#39;) failed (55808 blk=
tap kernel module not installed )</div>
</div><div><br></div><div>What is the &quot;proper&quot; way of getting the=
 blktap kernel module installed? =A0I found this:</div><div><a href=3D"http=
://packages.debian.org/sid/blktap-dkms">http://packages.debian.org/sid/blkt=
ap-dkms</a></div>

<div><br></div><div>but couldn&#39;t get it to actually install. =A0In any =
case, it seems unlikely that is the best way to go.</div><div><br></div><di=
v>Also, I will admit that I am running 4.1.2 (from source) rather than unst=
able---looking through the threads here doesn&#39;t make it sound like upgr=
ading to that will fix anything, but I can do so if need be.</div>

<div><br></div><div>thanks for any suggestions</div>

--0016e6dd8bfc823ef404bd094890--


--===============7674020407171484074==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7674020407171484074==--


From xen-devel-bounces@lists.xen.org Fri Apr 06 21:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 21:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGGe7-0000me-6I; Fri, 06 Apr 2012 21:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <twwood@gmail.com>) id 1SGGe5-0000mZ-Mu
	for xen-devel@lists.xen.org; Fri, 06 Apr 2012 21:24:37 +0000
Received: from [193.109.254.147:49206] by server-6.bemta-14.messagelabs.com id
	3E/B0-02047-51F5F7F4; Fri, 06 Apr 2012 21:24:37 +0000
X-Env-Sender: twwood@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1333747475!3561538!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31240 invoked from network); 6 Apr 2012 21:24:36 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 21:24:36 -0000
Received: by wgbed3 with SMTP id ed3so1906142wgb.32
	for <xen-devel@lists.xen.org>; Fri, 06 Apr 2012 14:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=3oAdRxJEb/h393ACEbucQXNRnFu79CSZCw4ZHM46hrg=;
	b=Wu/V+yma/8Tfy1SpzZXRx1fXuTowKxV9veYKEePej6XmB2HdwK+ihuolcnstnMrcUg
	fAIDeWu+ATwpfqBgV2LG3EagU6Wg8MdZ3y4BTAVkZn3D++b4QpIz7RLhOWuPCHjDc18h
	ST+z8k2s8L0inVJV12UtEHhpxv56sBvqU3As5wfZM5NgPcPg3LqWe+7zArK0jWE29KEZ
	N7soFU4yi8iJqwALPHn729fmCVxnm7zaqtZyCstbGdHlvpP447EiBCZIh9AAsCfUro9L
	F5dfzFNDVWybVNZJnaSu7Ab2kUK1O0tniAXB4WjFf3yQ9Jacr3m8+6HDj4P2mjZja2I8
	7C5g==
Received: by 10.216.132.169 with SMTP id o41mr4504245wei.121.1333747475693;
	Fri, 06 Apr 2012 14:24:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.75 with HTTP; Fri, 6 Apr 2012 14:24:15 -0700 (PDT)
From: Tim Wood <twwood@gmail.com>
Date: Fri, 6 Apr 2012 17:24:15 -0400
Message-ID: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7674020407171484074=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7674020407171484074==
Content-Type: multipart/alternative; boundary=0016e6dd8bfc823ef404bd094890

--0016e6dd8bfc823ef404bd094890
Content-Type: text/plain; charset=ISO-8859-1

In xen 4.0.X I was able to write custom blktap2 drivers as a nice way to
intercept VM disk traffic.  I'm now trying to take a step up to xen 4.1.2
and find that blktap2 doesn't seem to be supported anymore, or at least it
requires a kernel module which I'm not sure where to find.  Is blktap2
still in use, or is there an entirely different way I should be approaching
this?

Previously I could run commands like:

tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img

the new tapdisk2 doesn't support that interface anymore, but it seems like
the correct approach is now:

xm block-attach 0 tap2:aio:/path/disk.img xvda w 0
Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
module not installed )

What is the "proper" way of getting the blktap kernel module installed?  I
found this:
http://packages.debian.org/sid/blktap-dkms

but couldn't get it to actually install.  In any case, it seems unlikely
that is the best way to go.

Also, I will admit that I am running 4.1.2 (from source) rather than
unstable---looking through the threads here doesn't make it sound like
upgrading to that will fix anything, but I can do so if need be.

thanks for any suggestions

--0016e6dd8bfc823ef404bd094890
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>In xen 4.0.X I was able to write custom blktap2 drivers as a nice way =
to intercept VM disk traffic. =A0I&#39;m now trying to take a step up to xe=
n 4.1.2 and find that blktap2 doesn&#39;t seem to be supported anymore, or =
at least it requires a kernel module which I&#39;m not sure where to find. =
=A0Is blktap2 still in use, or is there an entirely different way I should =
be approaching this?</div>

<div><br></div><div>Previously I could run commands like:</div><div><br></d=
iv><div><span style=3D"background-color:rgb(255,255,255);font-size:12px;lin=
e-height:20px;text-align:justify">tapdisk2 -n tap:aio:/home/twood/vms/testd=
isk.img</span>=A0</div>

<div><br></div><div>the new tapdisk2 doesn&#39;t support that interface any=
more, but it seems like the correct approach is now:</div><div><br></div><d=
iv><div>xm block-attach 0 tap2:aio:/path/disk.img xvda w 0=A0</div><div>
Error: (&#39;create&#39;, &#39;-aaio:/path/disk.img&#39;) failed (55808 blk=
tap kernel module not installed )</div>
</div><div><br></div><div>What is the &quot;proper&quot; way of getting the=
 blktap kernel module installed? =A0I found this:</div><div><a href=3D"http=
://packages.debian.org/sid/blktap-dkms">http://packages.debian.org/sid/blkt=
ap-dkms</a></div>

<div><br></div><div>but couldn&#39;t get it to actually install. =A0In any =
case, it seems unlikely that is the best way to go.</div><div><br></div><di=
v>Also, I will admit that I am running 4.1.2 (from source) rather than unst=
able---looking through the threads here doesn&#39;t make it sound like upgr=
ading to that will fix anything, but I can do so if need be.</div>

<div><br></div><div>thanks for any suggestions</div>

--0016e6dd8bfc823ef404bd094890--


--===============7674020407171484074==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7674020407171484074==--


From xen-devel-bounces@lists.xen.org Fri Apr 06 23:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 23:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGI9U-0001Yw-8B; Fri, 06 Apr 2012 23:01:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGI9S-0001Yp-Ex
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 23:01:06 +0000
Received: from [85.158.138.51:45205] by server-6.bemta-3.messagelabs.com id
	D1/9E-08206-1B57F7F4; Fri, 06 Apr 2012 23:01:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333753264!20978854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30448 invoked from network); 6 Apr 2012 23:01:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 23:01:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208";a="11816954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 23:01:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 00:01:03 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGI9P-00013K-LF;
	Fri, 06 Apr 2012 23:01:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGI9P-00051G-Gf;
	Sat, 07 Apr 2012 00:01:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12592-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 00:01:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12592: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12592 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12592/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-i386-i386-xl            14 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-pv          10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-credit2   10 guest-saverestore            fail   never pass
 test-i386-i386-pv            10 guest-saverestore            fail   never pass
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-xl-sedf     10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)            broken never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3)      broken never pass
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)            broken never pass
 test-amd64-i386-xl            3 host-install(3)              broken never pass
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken never pass
 test-amd64-i386-pv            3 host-install(3)              broken never pass
 test-i386-i386-win            3 host-install(3)              broken never pass
 test-amd64-i386-xend-winxpsp3  3 host-install(3)             broken never pass
 test-amd64-i386-win-vcpus1    3 host-install(3)              broken never pass
 test-amd64-amd64-pair       17 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 06 23:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Apr 2012 23:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGI9U-0001Yw-8B; Fri, 06 Apr 2012 23:01:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGI9S-0001Yp-Ex
	for xen-devel@lists.xensource.com; Fri, 06 Apr 2012 23:01:06 +0000
Received: from [85.158.138.51:45205] by server-6.bemta-3.messagelabs.com id
	D1/9E-08206-1B57F7F4; Fri, 06 Apr 2012 23:01:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1333753264!20978854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30448 invoked from network); 6 Apr 2012 23:01:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Apr 2012 23:01:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208";a="11816954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Apr 2012 23:01:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 00:01:03 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGI9P-00013K-LF;
	Fri, 06 Apr 2012 23:01:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGI9P-00051G-Gf;
	Sat, 07 Apr 2012 00:01:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12592-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 00:01:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12592: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 12592 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12592/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-i386-i386-xl            14 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-pv          10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-credit2   10 guest-saverestore            fail   never pass
 test-i386-i386-pv            10 guest-saverestore            fail   never pass
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-xl-sedf     10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)            broken never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3)      broken never pass
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)            broken never pass
 test-amd64-i386-xl            3 host-install(3)              broken never pass
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken never pass
 test-amd64-i386-pv            3 host-install(3)              broken never pass
 test-i386-i386-win            3 host-install(3)              broken never pass
 test-amd64-i386-xend-winxpsp3  3 host-install(3)             broken never pass
 test-amd64-i386-win-vcpus1    3 host-install(3)              broken never pass
 test-amd64-amd64-pair       17 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 03:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 03:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGLuy-0007CS-Lh; Sat, 07 Apr 2012 03:02:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGLux-0007CN-7a
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 03:02:23 +0000
Received: from [85.158.138.51:43501] by server-5.bemta-3.messagelabs.com id
	B7/C9-24278-E3EAF7F4; Sat, 07 Apr 2012 03:02:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333767741!19311503!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32758 invoked from network); 7 Apr 2012 03:02:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 03:02:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208";a="11817687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 03:02:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 04:02:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGLuu-0002K9-HB;
	Sat, 07 Apr 2012 03:02:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGLuu-0005ia-93;
	Sat, 07 Apr 2012 04:02:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12593-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 04:02:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12593: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12593 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12593/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 03:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 03:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGLuy-0007CS-Lh; Sat, 07 Apr 2012 03:02:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGLux-0007CN-7a
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 03:02:23 +0000
Received: from [85.158.138.51:43501] by server-5.bemta-3.messagelabs.com id
	B7/C9-24278-E3EAF7F4; Sat, 07 Apr 2012 03:02:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333767741!19311503!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32758 invoked from network); 7 Apr 2012 03:02:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 03:02:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208";a="11817687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 03:02:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 04:02:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGLuu-0002K9-HB;
	Sat, 07 Apr 2012 03:02:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGLuu-0005ia-93;
	Sat, 07 Apr 2012 04:02:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12593-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 04:02:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12593: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12593 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12593/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 06:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 06:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGP5Z-0008Gt-BR; Sat, 07 Apr 2012 06:25:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mohitdhingras@gmail.com>) id 1SGP5Y-0008Go-1Y
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 06:25:32 +0000
Received: from [85.158.139.83:50640] by server-4.bemta-5.messagelabs.com id
	26/A3-10788-BDDDF7F4; Sat, 07 Apr 2012 06:25:31 +0000
X-Env-Sender: mohitdhingras@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333779929!18222111!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30289 invoked from network); 7 Apr 2012 06:25:29 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 06:25:29 -0000
Received: by werm1 with SMTP id m1so2105436wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 23:25:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=pl8Dt88sIdgM7W9VfnG+PBuBEWWxY5SC69UOvq313Fc=;
	b=jYkJSSQkjq33uPTOTaL6i7ySuqoD5PCEwkzh8ZD1mzVvSOjGDUjfBjYBoTrPlhLdbZ
	9ZM37VOnwcAdwaJxfasoI0ypvSBbrdN5xEO5J+9ZfLfV5yOxCi4LAbl9u/ZtPLLnOiNl
	LG75op5LmoWmoMwFkVi0WeFtZJ1FzNGB/shg3OskqoLWWbEmW/xDmDXmNMOTYXr0EpIY
	VMWXZBKqxc50CHrxP1hrU7jyi6KNLAkJp68bHcM53c2jXpY5DrCQwmaLbKM3RtXMqwlr
	tqhN+itDKAXvrem+FB/oxOr6zzbHeWfYMmMCAIIL0dVnDa+9uQoIyL9tPEgi8hNhU6VC
	SCdA==
Received: by 10.180.89.9 with SMTP id bk9mr1262685wib.11.1333779929459; Fri,
	06 Apr 2012 23:25:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.105.170 with HTTP; Fri, 6 Apr 2012 23:25:09 -0700 (PDT)
In-Reply-To: <20120402092105.GA25886@aepfle.de>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
	<1333356972.25602.11.camel@zakaz.uk.xensource.com>
	<20120402092105.GA25886@aepfle.de>
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sat, 7 Apr 2012 11:55:09 +0530
Message-ID: <CAGkgU9X3oGe1dy9GXFjhmosopqqZDbr2YessWmne3cHcajfEdA@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4294834049876662956=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4294834049876662956==
Content-Type: multipart/alternative; boundary=f46d0444812de76c0f04bd10d6f3

--f46d0444812de76c0f04bd10d6f3
Content-Type: text/plain; charset=ISO-8859-1

*Hi Ian/All,*

I am sorry, I was mistaken by "For now, a 32 bits host environnment is
necessary to build successfuly. building on a 64 bits host machine is not
yet supported" in http://xen.org/products/xci_source.html

Well, I am now able to build the xen binary image xen4.1.2, (after
installing the missing packages as suggested by you)

-rw-r--r--  1 root root   691748 Jul 27  2011 xen-4.0.2_52-0.2.1.gz
lrwxrwxrwx  1 root root       21 Feb  9 23:49 xen-4.0.gz ->
xen-4.0.2_52-0.2.1.gz
-rw-r--r--  1 root root   734699 Apr  7 11:39 xen-4.1.2.gz
lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.1.gz -> xen-4.1.2.gz
lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.gz -> xen-4.1.2.gz

I earlier had the xen-4.0.2 installed through zypper in Dom0 (opensuse 11.4)
(cadlab:/srv/xen-4.1.2 # uname -a
Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 +0100 x86_64
x86_64 x86_64 GNU/Linux
)


But xm commands are not working now.

cadlab:/srv/xen-4.1.2 # xm list
Error: Unable to connect to xend: Connection refused. Is xend running?

Is it not compatible with the openSUSE11.4? Or is there something which I
am missing out.

*
----------------------------
Thanks & Regards
Mohit Dhingra
+919611190435*


On 2 April 2012 14:51, Olaf Hering <olaf@aepfle.de> wrote:

> On Mon, Apr 02, Ian Campbell wrote:
>
> > On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
> > > Hello All,
> > >
> > > I am a newbie to Linux and Xen. I tried compiling Xen Source code (I
> > > want to make some changes and see how it works), but it failed on my
> > > system as it couldn't find gnu-stubs32.h. Later, on looking at
> > > Makefile, I figured out that for x86_64, it is not yet supported !!
>
> > WRT gnu-stubs32.h I suspect you are missing some -devel package or
> > other. I don't know about how SuSE lays things out but you should locate
> > the package containing this file and install it. Googling suggests that
> > perhaps you meant gnu/stubs32.h? In which case you probably want to
> > install glibc-devel.
>
> Running configure and/or make in a 32bit shell is not needed.
> "zypper in gcc-32bit glibc-devel-32bit" will install the required
> packages to compile the 32bit parts in the firmware.
>
> Olaf
>

--f46d0444812de76c0f04bd10d6f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<b>Hi Ian/All,</b><br><br>I am sorry, I was mistaken by &quot;For now, a 32=
 bits host environnment is necessary to build successfuly. building on a 64=
 bits host machine is not yet supported&quot; in <a href=3D"http://xen.org/=
products/xci_source.html" target=3D"_blank">http://xen.org/products/xci_sou=
rce.html</a><br>





<br>Well, I am now able to build the xen binary image xen4.1.2, (after inst=
alling the missing packages as suggested by you)<br><br>-rw-r--r--=A0 1 roo=
t root=A0=A0 691748 Jul 27=A0 2011 xen-4.0.2_52-0.2.1.gz<br>lrwxrwxrwx=A0 1=
 root root=A0=A0=A0=A0=A0=A0 21 Feb=A0 9 23:49 xen-4.0.gz -&gt; xen-4.0.2_5=
2-0.2.1.gz<br>

-rw-r--r--=A0 1 root root=A0=A0 734699 Apr=A0 7 11:39 xen-4.1.2.gz<br>lrwxr=
wxrwx=A0 1 root root=A0=A0=A0=A0=A0=A0 12 Apr=A0 7 11:39 xen-4.1.gz -&gt; x=
en-4.1.2.gz<br>lrwxrwxrwx=A0 1 root root=A0=A0=A0=A0=A0=A0 12 Apr=A0 7 11:3=
9 xen-4.gz -&gt; xen-4.1.2.gz<br><br>

I earlier had the xen-4.0.2 installed through zypper in Dom0 (opensuse 11.4=
)<br>(cadlab:/srv/xen-4.1.2 # uname -a<br>Linux cadlab 2.6.37.6-0.11-xen #1=
 SMP 2011-12-19 23:39:38 +0100 x86_64 x86_64 x86_64 GNU/Linux<br>)<br>
<br>
<br>But xm commands are not working now. <br><br>cadlab:/srv/xen-4.1.2 # xm=
 list<br>Error: Unable to connect to xend: Connection refused. Is xend runn=
ing?<br><br>Is it not compatible with the openSUSE11.4? Or is there somethi=
ng which I am missing out.<br>

<br><b><div><b>---------------------------- <br></b></div>Thanks &amp; Rega=
rds<br><font color=3D"#888888">Mohit Dhingra=A0<br>+919611190435</font></b>=
<br>
<br><br><div class=3D"gmail_quote">On 2 April 2012 14:51, Olaf Hering <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:olaf@aepfle.de" target=3D"_blank">olaf@a=
epfle.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div>On Mon, Apr 02, Ian Campbell wrote:<br>
<br>
&gt; On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:<br>
&gt; &gt; Hello All,<br>
&gt; &gt;<br>
&gt; &gt; I am a newbie to Linux and Xen. I tried compiling Xen Source code=
 (I<br>
&gt; &gt; want to make some changes and see how it works), but it failed on=
 my<br>
&gt; &gt; system as it couldn&#39;t find gnu-stubs32.h. Later, on looking a=
t<br>
&gt; &gt; Makefile, I figured out that for x86_64, it is not yet supported =
!!<br>
<br>
</div><div>&gt; WRT gnu-stubs32.h I suspect you are missing some -devel pac=
kage or<br>
&gt; other. I don&#39;t know about how SuSE lays things out but you should =
locate<br>
&gt; the package containing this file and install it. Googling suggests tha=
t<br>
&gt; perhaps you meant gnu/stubs32.h? In which case you probably want to<br=
>
&gt; install glibc-devel.<br>
<br>
</div>Running configure and/or make in a 32bit shell is not needed.<br>
&quot;zypper in gcc-32bit glibc-devel-32bit&quot; will install the required=
<br>
packages to compile the 32bit parts in the firmware.<br>
<span><font color=3D"#888888"><br>
Olaf<br>
</font></span></blockquote></div><br>

--f46d0444812de76c0f04bd10d6f3--


--===============4294834049876662956==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4294834049876662956==--


From xen-devel-bounces@lists.xen.org Sat Apr 07 06:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 06:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGP5Z-0008Gt-BR; Sat, 07 Apr 2012 06:25:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mohitdhingras@gmail.com>) id 1SGP5Y-0008Go-1Y
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 06:25:32 +0000
Received: from [85.158.139.83:50640] by server-4.bemta-5.messagelabs.com id
	26/A3-10788-BDDDF7F4; Sat, 07 Apr 2012 06:25:31 +0000
X-Env-Sender: mohitdhingras@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333779929!18222111!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30289 invoked from network); 7 Apr 2012 06:25:29 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 06:25:29 -0000
Received: by werm1 with SMTP id m1so2105436wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Apr 2012 23:25:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=pl8Dt88sIdgM7W9VfnG+PBuBEWWxY5SC69UOvq313Fc=;
	b=jYkJSSQkjq33uPTOTaL6i7ySuqoD5PCEwkzh8ZD1mzVvSOjGDUjfBjYBoTrPlhLdbZ
	9ZM37VOnwcAdwaJxfasoI0ypvSBbrdN5xEO5J+9ZfLfV5yOxCi4LAbl9u/ZtPLLnOiNl
	LG75op5LmoWmoMwFkVi0WeFtZJ1FzNGB/shg3OskqoLWWbEmW/xDmDXmNMOTYXr0EpIY
	VMWXZBKqxc50CHrxP1hrU7jyi6KNLAkJp68bHcM53c2jXpY5DrCQwmaLbKM3RtXMqwlr
	tqhN+itDKAXvrem+FB/oxOr6zzbHeWfYMmMCAIIL0dVnDa+9uQoIyL9tPEgi8hNhU6VC
	SCdA==
Received: by 10.180.89.9 with SMTP id bk9mr1262685wib.11.1333779929459; Fri,
	06 Apr 2012 23:25:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.105.170 with HTTP; Fri, 6 Apr 2012 23:25:09 -0700 (PDT)
In-Reply-To: <20120402092105.GA25886@aepfle.de>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
	<1333356972.25602.11.camel@zakaz.uk.xensource.com>
	<20120402092105.GA25886@aepfle.de>
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sat, 7 Apr 2012 11:55:09 +0530
Message-ID: <CAGkgU9X3oGe1dy9GXFjhmosopqqZDbr2YessWmne3cHcajfEdA@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4294834049876662956=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4294834049876662956==
Content-Type: multipart/alternative; boundary=f46d0444812de76c0f04bd10d6f3

--f46d0444812de76c0f04bd10d6f3
Content-Type: text/plain; charset=ISO-8859-1

*Hi Ian/All,*

I am sorry, I was mistaken by "For now, a 32 bits host environnment is
necessary to build successfuly. building on a 64 bits host machine is not
yet supported" in http://xen.org/products/xci_source.html

Well, I am now able to build the xen binary image xen4.1.2, (after
installing the missing packages as suggested by you)

-rw-r--r--  1 root root   691748 Jul 27  2011 xen-4.0.2_52-0.2.1.gz
lrwxrwxrwx  1 root root       21 Feb  9 23:49 xen-4.0.gz ->
xen-4.0.2_52-0.2.1.gz
-rw-r--r--  1 root root   734699 Apr  7 11:39 xen-4.1.2.gz
lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.1.gz -> xen-4.1.2.gz
lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.gz -> xen-4.1.2.gz

I earlier had the xen-4.0.2 installed through zypper in Dom0 (opensuse 11.4)
(cadlab:/srv/xen-4.1.2 # uname -a
Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 +0100 x86_64
x86_64 x86_64 GNU/Linux
)


But xm commands are not working now.

cadlab:/srv/xen-4.1.2 # xm list
Error: Unable to connect to xend: Connection refused. Is xend running?

Is it not compatible with the openSUSE11.4? Or is there something which I
am missing out.

*
----------------------------
Thanks & Regards
Mohit Dhingra
+919611190435*


On 2 April 2012 14:51, Olaf Hering <olaf@aepfle.de> wrote:

> On Mon, Apr 02, Ian Campbell wrote:
>
> > On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
> > > Hello All,
> > >
> > > I am a newbie to Linux and Xen. I tried compiling Xen Source code (I
> > > want to make some changes and see how it works), but it failed on my
> > > system as it couldn't find gnu-stubs32.h. Later, on looking at
> > > Makefile, I figured out that for x86_64, it is not yet supported !!
>
> > WRT gnu-stubs32.h I suspect you are missing some -devel package or
> > other. I don't know about how SuSE lays things out but you should locate
> > the package containing this file and install it. Googling suggests that
> > perhaps you meant gnu/stubs32.h? In which case you probably want to
> > install glibc-devel.
>
> Running configure and/or make in a 32bit shell is not needed.
> "zypper in gcc-32bit glibc-devel-32bit" will install the required
> packages to compile the 32bit parts in the firmware.
>
> Olaf
>

--f46d0444812de76c0f04bd10d6f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<b>Hi Ian/All,</b><br><br>I am sorry, I was mistaken by &quot;For now, a 32=
 bits host environnment is necessary to build successfuly. building on a 64=
 bits host machine is not yet supported&quot; in <a href=3D"http://xen.org/=
products/xci_source.html" target=3D"_blank">http://xen.org/products/xci_sou=
rce.html</a><br>





<br>Well, I am now able to build the xen binary image xen4.1.2, (after inst=
alling the missing packages as suggested by you)<br><br>-rw-r--r--=A0 1 roo=
t root=A0=A0 691748 Jul 27=A0 2011 xen-4.0.2_52-0.2.1.gz<br>lrwxrwxrwx=A0 1=
 root root=A0=A0=A0=A0=A0=A0 21 Feb=A0 9 23:49 xen-4.0.gz -&gt; xen-4.0.2_5=
2-0.2.1.gz<br>

-rw-r--r--=A0 1 root root=A0=A0 734699 Apr=A0 7 11:39 xen-4.1.2.gz<br>lrwxr=
wxrwx=A0 1 root root=A0=A0=A0=A0=A0=A0 12 Apr=A0 7 11:39 xen-4.1.gz -&gt; x=
en-4.1.2.gz<br>lrwxrwxrwx=A0 1 root root=A0=A0=A0=A0=A0=A0 12 Apr=A0 7 11:3=
9 xen-4.gz -&gt; xen-4.1.2.gz<br><br>

I earlier had the xen-4.0.2 installed through zypper in Dom0 (opensuse 11.4=
)<br>(cadlab:/srv/xen-4.1.2 # uname -a<br>Linux cadlab 2.6.37.6-0.11-xen #1=
 SMP 2011-12-19 23:39:38 +0100 x86_64 x86_64 x86_64 GNU/Linux<br>)<br>
<br>
<br>But xm commands are not working now. <br><br>cadlab:/srv/xen-4.1.2 # xm=
 list<br>Error: Unable to connect to xend: Connection refused. Is xend runn=
ing?<br><br>Is it not compatible with the openSUSE11.4? Or is there somethi=
ng which I am missing out.<br>

<br><b><div><b>---------------------------- <br></b></div>Thanks &amp; Rega=
rds<br><font color=3D"#888888">Mohit Dhingra=A0<br>+919611190435</font></b>=
<br>
<br><br><div class=3D"gmail_quote">On 2 April 2012 14:51, Olaf Hering <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:olaf@aepfle.de" target=3D"_blank">olaf@a=
epfle.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div>On Mon, Apr 02, Ian Campbell wrote:<br>
<br>
&gt; On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:<br>
&gt; &gt; Hello All,<br>
&gt; &gt;<br>
&gt; &gt; I am a newbie to Linux and Xen. I tried compiling Xen Source code=
 (I<br>
&gt; &gt; want to make some changes and see how it works), but it failed on=
 my<br>
&gt; &gt; system as it couldn&#39;t find gnu-stubs32.h. Later, on looking a=
t<br>
&gt; &gt; Makefile, I figured out that for x86_64, it is not yet supported =
!!<br>
<br>
</div><div>&gt; WRT gnu-stubs32.h I suspect you are missing some -devel pac=
kage or<br>
&gt; other. I don&#39;t know about how SuSE lays things out but you should =
locate<br>
&gt; the package containing this file and install it. Googling suggests tha=
t<br>
&gt; perhaps you meant gnu/stubs32.h? In which case you probably want to<br=
>
&gt; install glibc-devel.<br>
<br>
</div>Running configure and/or make in a 32bit shell is not needed.<br>
&quot;zypper in gcc-32bit glibc-devel-32bit&quot; will install the required=
<br>
packages to compile the 32bit parts in the firmware.<br>
<span><font color=3D"#888888"><br>
Olaf<br>
</font></span></blockquote></div><br>

--f46d0444812de76c0f04bd10d6f3--


--===============4294834049876662956==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4294834049876662956==--


From xen-devel-bounces@lists.xen.org Sat Apr 07 07:38:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 07:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGQDM-0000Zr-Dk; Sat, 07 Apr 2012 07:37:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGQDL-0000Zi-Jc
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 07:37:39 +0000
Received: from [85.158.139.83:31323] by server-9.bemta-5.messagelabs.com id
	1F/3B-09826-2CEEF7F4; Sat, 07 Apr 2012 07:37:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333784257!15472256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12618 invoked from network); 7 Apr 2012 07:37:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 07:37:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 07:37:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	08:37:37 +0100
Message-ID: <1333784256.12209.107.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Wood <twwood@gmail.com>
Date: Sat, 7 Apr 2012 08:37:36 +0100
In-Reply-To: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
References: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:
> In xen 4.0.X I was able to write custom blktap2 drivers as a nice way
> to intercept VM disk traffic.  I'm now trying to take a step up to xen
> 4.1.2 and find that blktap2 doesn't seem to be supported anymore, or
> at least it requires a kernel module which I'm not sure where to
> find.  Is blktap2 still in use, or is there an entirely different way
> I should be approaching this?
> 
> 
> Previously I could run commands like:
> 
> 
> tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img 
> 
> 
> the new tapdisk2 doesn't support that interface anymore,

What do you mean? I don't think the tap interface has changed (but I'm
not sure). In any case I'm pretty sure the functionality should be there
even if the command line has changed.

>  but it seems like the correct approach is now:
> 
> 
> xm block-attach 0 tap2:aio:/path/disk.img xvda w 0 
> Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
> module not installed )

I think this ultimately turns into the same sort of command as the one
above.

> What is the "proper" way of getting the blktap kernel module
> installed?  I found this:
> http://packages.debian.org/sid/blktap-dkms

Unfortunately the blktap2 module is not something which can be
upstreamed.

The DKMS package is probably a good bet for now. The other alternative
is to switch to a slightly older kernel which has the blktap2 driver in
it, for example the 2.6.32 based xen.git kernel tree or one of the
classic Xen forward ports.

You mentioned writing your own blktap modules so the qemu-supplied qdisk
backend is probably not much use to you. This is used by the "xl"
toolstack by default when blktap is not present, but isn't supported by
xm and doesn't allow for custom modules .

I'm actually quite interested in the fact that you are writing custom
blktap modules -- are you able to share the details?

> but couldn't get it to actually install.

Please share the details so we can try and figure out why.

> In any case, it seems unlikely that is the best way to go.

Sadly it is, for now.

Long term someone is working on a "blktap3" which is fully userspace and
so doesn't require a kernel module. We hope to see this for 4.3. For 4.2
it looks like we'll be sticking with the qdisk backend.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 07:38:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 07:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGQDM-0000Zr-Dk; Sat, 07 Apr 2012 07:37:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGQDL-0000Zi-Jc
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 07:37:39 +0000
Received: from [85.158.139.83:31323] by server-9.bemta-5.messagelabs.com id
	1F/3B-09826-2CEEF7F4; Sat, 07 Apr 2012 07:37:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1333784257!15472256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12618 invoked from network); 7 Apr 2012 07:37:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 07:37:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 07:37:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	08:37:37 +0100
Message-ID: <1333784256.12209.107.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Wood <twwood@gmail.com>
Date: Sat, 7 Apr 2012 08:37:36 +0100
In-Reply-To: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
References: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:
> In xen 4.0.X I was able to write custom blktap2 drivers as a nice way
> to intercept VM disk traffic.  I'm now trying to take a step up to xen
> 4.1.2 and find that blktap2 doesn't seem to be supported anymore, or
> at least it requires a kernel module which I'm not sure where to
> find.  Is blktap2 still in use, or is there an entirely different way
> I should be approaching this?
> 
> 
> Previously I could run commands like:
> 
> 
> tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img 
> 
> 
> the new tapdisk2 doesn't support that interface anymore,

What do you mean? I don't think the tap interface has changed (but I'm
not sure). In any case I'm pretty sure the functionality should be there
even if the command line has changed.

>  but it seems like the correct approach is now:
> 
> 
> xm block-attach 0 tap2:aio:/path/disk.img xvda w 0 
> Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
> module not installed )

I think this ultimately turns into the same sort of command as the one
above.

> What is the "proper" way of getting the blktap kernel module
> installed?  I found this:
> http://packages.debian.org/sid/blktap-dkms

Unfortunately the blktap2 module is not something which can be
upstreamed.

The DKMS package is probably a good bet for now. The other alternative
is to switch to a slightly older kernel which has the blktap2 driver in
it, for example the 2.6.32 based xen.git kernel tree or one of the
classic Xen forward ports.

You mentioned writing your own blktap modules so the qemu-supplied qdisk
backend is probably not much use to you. This is used by the "xl"
toolstack by default when blktap is not present, but isn't supported by
xm and doesn't allow for custom modules .

I'm actually quite interested in the fact that you are writing custom
blktap modules -- are you able to share the details?

> but couldn't get it to actually install.

Please share the details so we can try and figure out why.

> In any case, it seems unlikely that is the best way to go.

Sadly it is, for now.

Long term someone is working on a "blktap3" which is fully userspace and
so doesn't require a kernel module. We hope to see this for 4.3. For 4.2
it looks like we'll be sticking with the qdisk backend.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 07:39:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 07:39:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGQEo-0000df-Sh; Sat, 07 Apr 2012 07:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGQEn-0000dT-Qm
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 07:39:09 +0000
Received: from [85.158.138.51:26348] by server-2.bemta-3.messagelabs.com id
	5F/37-15460-D1FEF7F4; Sat, 07 Apr 2012 07:39:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333784347!19327154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30525 invoked from network); 7 Apr 2012 07:39:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 07:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 07:39:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	08:39:06 +0100
Message-ID: <1333784346.12209.108.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Sat, 7 Apr 2012 08:39:06 +0100
In-Reply-To: <4F7F4B82.6040007@oracle.com>
References: <4F7EE57D.4020207@oracle.com>
	<4F7F57A502000078000821B6@nat28.tlf.novell.com>
	<4F7F4B82.6040007@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-06 at 21:01 +0100, Zhigang Wang wrote:
> On 04/06/2012 03:52 PM, Jan Beulich wrote:
> >>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
> >> nr_cpus                : 8
> >> nr_nodes               : 1
> >> cores_per_socket       : 4
> >> threads_per_core       : 1
> >>
> >> I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core
> > nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core
> It seems on xm/xl info we don't show how many sockets_per_node. Can we do that
> in the future?

We can and should. Are you able to send a patch for xl at least?

Thanks,
Ian.

> It seems this machine has: sockets_per_node = 2.
> 
> Thanks very much Jan.
> 
> Zhigang
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 07:39:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 07:39:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGQEo-0000df-Sh; Sat, 07 Apr 2012 07:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGQEn-0000dT-Qm
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 07:39:09 +0000
Received: from [85.158.138.51:26348] by server-2.bemta-3.messagelabs.com id
	5F/37-15460-D1FEF7F4; Sat, 07 Apr 2012 07:39:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1333784347!19327154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30525 invoked from network); 7 Apr 2012 07:39:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 07:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 07:39:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	08:39:06 +0100
Message-ID: <1333784346.12209.108.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Sat, 7 Apr 2012 08:39:06 +0100
In-Reply-To: <4F7F4B82.6040007@oracle.com>
References: <4F7EE57D.4020207@oracle.com>
	<4F7F57A502000078000821B6@nat28.tlf.novell.com>
	<4F7F4B82.6040007@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] strange cpu number from xm info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-06 at 21:01 +0100, Zhigang Wang wrote:
> On 04/06/2012 03:52 PM, Jan Beulich wrote:
> >>>> Zhigang Wang <zhigang.x.wang@oracle.com> 04/06/12 2:45 PM >>>
> >> nr_cpus                : 8
> >> nr_nodes               : 1
> >> cores_per_socket       : 4
> >> threads_per_core       : 1
> >>
> >> I thought nr_cpus = nr_nodes * cores_per_socket * threads_per_core
> > nr_cpus = nr_nodes * sockets_per_node * cores_per_socket * threads_per_core
> It seems on xm/xl info we don't show how many sockets_per_node. Can we do that
> in the future?

We can and should. Are you able to send a patch for xl at least?

Thanks,
Ian.

> It seems this machine has: sockets_per_node = 2.
> 
> Thanks very much Jan.
> 
> Zhigang
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 08:09:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 08:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGQhC-0001Zx-C6; Sat, 07 Apr 2012 08:08:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGQhA-0001Zs-Ft
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 08:08:28 +0000
Received: from [193.109.254.147:13988] by server-8.bemta-14.messagelabs.com id
	05/18-23244-BF5FF7F4; Sat, 07 Apr 2012 08:08:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333786107!3543383!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17256 invoked from network); 7 Apr 2012 08:08:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 08:08:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 08:08:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 09:08:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGQh7-0003xZ-3m;
	Sat, 07 Apr 2012 08:08:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGQh7-0000fB-2t;
	Sat, 07 Apr 2012 09:08:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12595-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 09:08:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12595: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12595 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12595/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 12587

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 12587
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 12587
 test-i386-i386-xl             3 host-install(3)           broken pass in 12587
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 12587
 test-amd64-amd64-win          3 host-install(3)           broken pass in 12587
 test-amd64-i386-xl            3 host-install(3)           broken pass in 12587
 test-amd64-i386-xl-credit2    9 guest-start                 fail pass in 12587

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12587

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 12587 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 12587 never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 08:09:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 08:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGQhC-0001Zx-C6; Sat, 07 Apr 2012 08:08:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGQhA-0001Zs-Ft
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 08:08:28 +0000
Received: from [193.109.254.147:13988] by server-8.bemta-14.messagelabs.com id
	05/18-23244-BF5FF7F4; Sat, 07 Apr 2012 08:08:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333786107!3543383!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17256 invoked from network); 7 Apr 2012 08:08:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 08:08:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 08:08:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 09:08:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGQh7-0003xZ-3m;
	Sat, 07 Apr 2012 08:08:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGQh7-0000fB-2t;
	Sat, 07 Apr 2012 09:08:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12595-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 09:08:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12595: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12595 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12595/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 12587

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 12587
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 12587
 test-i386-i386-xl             3 host-install(3)           broken pass in 12587
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 12587
 test-amd64-amd64-win          3 host-install(3)           broken pass in 12587
 test-amd64-i386-xl            3 host-install(3)           broken pass in 12587
 test-amd64-i386-xl-credit2    9 guest-start                 fail pass in 12587

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12587

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 12587 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 12587 never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 08:59:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 08:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGRTh-00021E-JS; Sat, 07 Apr 2012 08:58:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGRTf-000219-Aa
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 08:58:35 +0000
Received: from [85.158.143.35:36584] by server-1.bemta-4.messagelabs.com id
	62/7C-20925-AB1008F4; Sat, 07 Apr 2012 08:58:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333789114!6061085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27943 invoked from network); 7 Apr 2012 08:58:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 08:58:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,386,1330905600"; d="scan'208";a="11818909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 08:58:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 09:58:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGRTd-0004Dz-Ak;
	Sat, 07 Apr 2012 08:58:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGRTd-0003lh-7V;
	Sat, 07 Apr 2012 09:58:33 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12596-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 09:58:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12596: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12596 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12596/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 08:59:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 08:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGRTh-00021E-JS; Sat, 07 Apr 2012 08:58:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGRTf-000219-Aa
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 08:58:35 +0000
Received: from [85.158.143.35:36584] by server-1.bemta-4.messagelabs.com id
	62/7C-20925-AB1008F4; Sat, 07 Apr 2012 08:58:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1333789114!6061085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27943 invoked from network); 7 Apr 2012 08:58:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 08:58:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,386,1330905600"; d="scan'208";a="11818909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 08:58:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 09:58:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGRTd-0004Dz-Ak;
	Sat, 07 Apr 2012 08:58:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGRTd-0003lh-7V;
	Sat, 07 Apr 2012 09:58:33 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12596-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 09:58:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12596: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12596 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12596/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 10:58:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 10:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGTL2-0002eu-MT; Sat, 07 Apr 2012 10:57:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SGTL1-0002eo-Of
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 10:57:47 +0000
Received: from [193.109.254.147:9418] by server-10.bemta-14.messagelabs.com id
	53/BB-05847-BAD108F4; Sat, 07 Apr 2012 10:57:47 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333796264!3615263!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3116 invoked from network); 7 Apr 2012 10:57:46 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 10:57:46 -0000
Received: by pbcwz12 with SMTP id wz12so3409444pbc.30
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Apr 2012 03:57:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=B4TOnIJltSx6SyK8KBH0nbI2eVe1oEH89FxBBt26j98=;
	b=eCPWRsex8Fim4sl7/x4NJLy99alp3Xd1A4PwZjuDLMmUs+dLPVlWY1S4lCF3gXbwai
	XP2h++je87Lerw668g0kgASMxbAuXGO8YzECkCVYevctAI+R7+HH5+dg6ARxQzzOMP9M
	vSWA3IFmRWPomY+OQqTpHr2lbPAFseKndzPAQFzhG6reoxjvSPDzPYtZ6nTQ39ackkWm
	K89dV/52quScSL7A3YE5oM+U5J+ME1u0e+QSS8fEXFLMK7NYKLF/PDL+uUq4BUQs9vSs
	aYxmF9A+mfSj9yRi9bGXro+6O2VYphWvxb+tUCoaoq/mwhxWsTi+uDlL/H2mhdqgo6ph
	4PGQ==
MIME-Version: 1.0
Received: by 10.68.72.138 with SMTP id d10mr3242582pbv.15.1333796263597; Sat,
	07 Apr 2012 03:57:43 -0700 (PDT)
Received: by 10.68.7.39 with HTTP; Sat, 7 Apr 2012 03:57:43 -0700 (PDT)
In-Reply-To: <20120406203447.GC15674@phenom.dumpdata.com>
References: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
	<20120406203447.GC15674@phenom.dumpdata.com>
Date: Sat, 7 Apr 2012 19:57:43 +0900
Message-ID: <CAP2B8586-+sRN_QgUMhF2t1WMhUYZq0vfgPG_AuSLqWt9z3YrQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 7, 2012 at 5:34 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Mar 09, 2012 at 08:35:40AM +0900, Daniel Castro wrote:
>> Hello All,
>>
>> I have a little setback with the development of PV Drivers for Xen in Se=
aBIOS.
>
> Hey, seems I read your emails out of sync.
>
>> The initialization code that runs in 32 Bit is working properly.
>> But, when the system tries to read on the disk I use the ring macros
>> to get a request. The macro usage looks like this:
>> struct blkif_ring * shared =3D memalign_low(4096,4096); //return
>> 0x000fd630 this above 16bit address space
>> SHARED_RING_INIT(shared);
>> So far I have a pointer located at 0x0009a000
>> Under 32bit the struct is correct and all is working according to plan.
>>
>> But on 16bit operation read on disk I have
>> struct blkfront_info * shared_ring =3D
>> container_of(op->drive_g.info->shared)); // I get d630 I should get it
>> from the correct segment, but how?
>> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
>> something 0xa010 segment SS or something like that
>>
>> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by
>> changing the segment register, yet I do not know in what segment the
>> ring is located, and the macros are not applied inside the procedure
>> of the macro, for example:
>
> There should be some way to set your physical address (so
> 9a000) to a segment?
>
>> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
>> But this will change a 16Bit pointer of segment SS to a 32 bit
>> segment. There is also the reverse but, again I do not know the
>> segment in which I should look for. Lastly the process inside the
>> macro does not get this benefin, and I do not know if the macro will
>> work with a pointer of size 16bits.
>
> 16-bits should be fine. The problem is if you run your pointer
> outside the 16-bit segment.
Thanks for the response Konrad, Seabios provides some macross that
will set the segment automatically, you only need to use a specific
malloc to get the memory; For example:
int * pointer VAR16VISIBLE;
pointer =3D mallow_low(sizeof(pointer));
This code will create the pointer in a specific segment, so later when I us=
e:
printf("%p",GET_GLOBALFLAT(pointer)); This will return the 32bit
address of it, If I do not use the GET_GLOBAL macro I will only get
the offset on the segment.
>
>>
>> Any help will be GREATLY appreciated, I am almost done.
>>
>> Thanks,
>>
>> Daniel
>> --
>> +-=3D=3D=3D=3D=3D---------------------------+
>> | +---------------------------------+ | This space intentionally blank
>> for notetaking.
>> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> | |=A0=A0 | Consultant/Programmer.|
>> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
>> +-------------------------------------+
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 10:58:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 10:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGTL2-0002eu-MT; Sat, 07 Apr 2012 10:57:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SGTL1-0002eo-Of
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 10:57:47 +0000
Received: from [193.109.254.147:9418] by server-10.bemta-14.messagelabs.com id
	53/BB-05847-BAD108F4; Sat, 07 Apr 2012 10:57:47 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1333796264!3615263!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3116 invoked from network); 7 Apr 2012 10:57:46 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 10:57:46 -0000
Received: by pbcwz12 with SMTP id wz12so3409444pbc.30
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Apr 2012 03:57:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=B4TOnIJltSx6SyK8KBH0nbI2eVe1oEH89FxBBt26j98=;
	b=eCPWRsex8Fim4sl7/x4NJLy99alp3Xd1A4PwZjuDLMmUs+dLPVlWY1S4lCF3gXbwai
	XP2h++je87Lerw668g0kgASMxbAuXGO8YzECkCVYevctAI+R7+HH5+dg6ARxQzzOMP9M
	vSWA3IFmRWPomY+OQqTpHr2lbPAFseKndzPAQFzhG6reoxjvSPDzPYtZ6nTQ39ackkWm
	K89dV/52quScSL7A3YE5oM+U5J+ME1u0e+QSS8fEXFLMK7NYKLF/PDL+uUq4BUQs9vSs
	aYxmF9A+mfSj9yRi9bGXro+6O2VYphWvxb+tUCoaoq/mwhxWsTi+uDlL/H2mhdqgo6ph
	4PGQ==
MIME-Version: 1.0
Received: by 10.68.72.138 with SMTP id d10mr3242582pbv.15.1333796263597; Sat,
	07 Apr 2012 03:57:43 -0700 (PDT)
Received: by 10.68.7.39 with HTTP; Sat, 7 Apr 2012 03:57:43 -0700 (PDT)
In-Reply-To: <20120406203447.GC15674@phenom.dumpdata.com>
References: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
	<20120406203447.GC15674@phenom.dumpdata.com>
Date: Sat, 7 Apr 2012 19:57:43 +0900
Message-ID: <CAP2B8586-+sRN_QgUMhF2t1WMhUYZq0vfgPG_AuSLqWt9z3YrQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 7, 2012 at 5:34 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Mar 09, 2012 at 08:35:40AM +0900, Daniel Castro wrote:
>> Hello All,
>>
>> I have a little setback with the development of PV Drivers for Xen in Se=
aBIOS.
>
> Hey, seems I read your emails out of sync.
>
>> The initialization code that runs in 32 Bit is working properly.
>> But, when the system tries to read on the disk I use the ring macros
>> to get a request. The macro usage looks like this:
>> struct blkif_ring * shared =3D memalign_low(4096,4096); //return
>> 0x000fd630 this above 16bit address space
>> SHARED_RING_INIT(shared);
>> So far I have a pointer located at 0x0009a000
>> Under 32bit the struct is correct and all is working according to plan.
>>
>> But on 16bit operation read on disk I have
>> struct blkfront_info * shared_ring =3D
>> container_of(op->drive_g.info->shared)); // I get d630 I should get it
>> from the correct segment, but how?
>> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
>> something 0xa010 segment SS or something like that
>>
>> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by
>> changing the segment register, yet I do not know in what segment the
>> ring is located, and the macros are not applied inside the procedure
>> of the macro, for example:
>
> There should be some way to set your physical address (so
> 9a000) to a segment?
>
>> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
>> But this will change a 16Bit pointer of segment SS to a 32 bit
>> segment. There is also the reverse but, again I do not know the
>> segment in which I should look for. Lastly the process inside the
>> macro does not get this benefin, and I do not know if the macro will
>> work with a pointer of size 16bits.
>
> 16-bits should be fine. The problem is if you run your pointer
> outside the 16-bit segment.
Thanks for the response Konrad, Seabios provides some macross that
will set the segment automatically, you only need to use a specific
malloc to get the memory; For example:
int * pointer VAR16VISIBLE;
pointer =3D mallow_low(sizeof(pointer));
This code will create the pointer in a specific segment, so later when I us=
e:
printf("%p",GET_GLOBALFLAT(pointer)); This will return the 32bit
address of it, If I do not use the GET_GLOBAL macro I will only get
the offset on the segment.
>
>>
>> Any help will be GREATLY appreciated, I am almost done.
>>
>> Thanks,
>>
>> Daniel
>> --
>> +-=3D=3D=3D=3D=3D---------------------------+
>> | +---------------------------------+ | This space intentionally blank
>> for notetaking.
>> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> | |=A0=A0 | Consultant/Programmer.|
>> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
>> +-------------------------------------+
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 11:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 11:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGTOS-0002mK-Ak; Sat, 07 Apr 2012 11:01:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SGTOQ-0002mF-Qc
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 11:01:19 +0000
Received: from [193.109.254.147:34453] by server-9.bemta-14.messagelabs.com id
	3A/B1-05787-E7E108F4; Sat, 07 Apr 2012 11:01:18 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333796475!3620567!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28636 invoked from network); 7 Apr 2012 11:01:17 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 11:01:17 -0000
Received: by pbcwz12 with SMTP id wz12so3411246pbc.30
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Apr 2012 04:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GRyujzbmAaZVxuKnQUwViuzIGqbFsIy4tV9wrPYD9j0=;
	b=RZ3goV9WKLe79IlfhQiU767m5psiQjokWumH/YuK3E6RsGKLoKoDxOvLCg9hGOVmGJ
	NX1vY/hHcpehq4pdgFr720jYKpFCr8SXGRlBsv4m6R2AuFEtp8+6UqJrmkLBSg0VR5+4
	9uhAEfdebFmlBJhzxZcsumWs8Umqz7GdmrAlJp9stKfsI0nA4XklFzRA68n/LFtwjGnc
	m9n5h5g4YVT52iiSJOqTvoPq/ir0Wx8HLVipphQYCzxaLbYT6lemWcG6DeCgwv4OSFzF
	WVu9jWLwBiQzjSj3+If6iGkbcHXCEH2+IYHn0Zd+xn/32xMpdoeJS5JTRK6kXd2G3ksf
	gtOw==
MIME-Version: 1.0
Received: by 10.68.226.42 with SMTP id rp10mr2614500pbc.162.1333796474827;
	Sat, 07 Apr 2012 04:01:14 -0700 (PDT)
Received: by 10.68.7.39 with HTTP; Sat, 7 Apr 2012 04:01:14 -0700 (PDT)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B10A95EAB@BITCOM1.int.sbss.com.au>
References: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B10A95EAB@BITCOM1.int.sbss.com.au>
Date: Sat, 7 Apr 2012 20:01:14 +0900
Message-ID: <CAP2B858QfdVabT+ogvgck-AfLumJ7kw8Y+z3cssjGZEL9gmONg@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Yes, out of sync, anyway...

On Fri, Mar 9, 2012 at 8:59 AM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> Hello All,
>>
>> I have a little setback with the development of PV Drivers for Xen in Se=
aBIOS.
>> The initialization code that runs in 32 Bit is working properly.
>> But, when the system tries to read on the disk I use the ring macros to =
get a
>> request. The macro usage looks like this:
>> struct blkif_ring * shared =3D memalign_low(4096,4096); //return
>> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So
>> far I have a pointer located at 0x0009a000 Under 32bit the struct is cor=
rect
>> and all is working according to plan.
>>
>> But on 16bit operation read on disk I have struct blkfront_info * shared=
_ring
>> =3D container_of(op->drive_g.info->shared)); // I get d630 I should get =
it from
>> the correct segment, but how?
>> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
>> something 0xa010 segment SS or something like that
>
> Just curios, does 16 bit include the required atomic instructions to mani=
pulate the 32 bit ring counters? Or are you manipulating the ring in 32 bit=
 mode and only accessing the requests already retrieved from the ring in 16=
 bit mode?
This is my current problem, when I do
RING_GET_REQUEST(GET_GLOBAL(blk_info->private),GET_GLOBAL(blk_info->private=
->req_prod_pvt));
The return address is incorrect, so I guess since inside the
RING_REQUEST MACRO I make memory access I will need to rewrite the
macro to include the SeaBios macros needed to address 32bit pointers
in 16bit mode.
>
>> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by chan=
ging
>> the segment register, yet I do not know in what segment the ring is loca=
ted,
>> and the macros are not applied inside the procedure of the macro, for
>> example:
>> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
>> But this will change a 16Bit pointer of segment SS to a 32 bit segment. =
There
>> is also the reverse but, again I do not know the segment in which I shou=
ld
>> look for. Lastly the process inside the macro does not get this benefin,=
 and I
>> do not know if the macro will work with a pointer of size 16bits.
>>
>> Any help will be GREATLY appreciated, I am almost done.
>>
>
> I'm not sure if this would be useful, but is there a way to hand over the=
 ring to the OS PV drivers and avoid the teardown/setup?
This is before there is an OS. The bios handles the boot process,
right now I am trying to get the first read on the drive, the boot
sector.
>
> James
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 11:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 11:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGTOS-0002mK-Ak; Sat, 07 Apr 2012 11:01:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SGTOQ-0002mF-Qc
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 11:01:19 +0000
Received: from [193.109.254.147:34453] by server-9.bemta-14.messagelabs.com id
	3A/B1-05787-E7E108F4; Sat, 07 Apr 2012 11:01:18 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333796475!3620567!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28636 invoked from network); 7 Apr 2012 11:01:17 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 11:01:17 -0000
Received: by pbcwz12 with SMTP id wz12so3411246pbc.30
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Apr 2012 04:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GRyujzbmAaZVxuKnQUwViuzIGqbFsIy4tV9wrPYD9j0=;
	b=RZ3goV9WKLe79IlfhQiU767m5psiQjokWumH/YuK3E6RsGKLoKoDxOvLCg9hGOVmGJ
	NX1vY/hHcpehq4pdgFr720jYKpFCr8SXGRlBsv4m6R2AuFEtp8+6UqJrmkLBSg0VR5+4
	9uhAEfdebFmlBJhzxZcsumWs8Umqz7GdmrAlJp9stKfsI0nA4XklFzRA68n/LFtwjGnc
	m9n5h5g4YVT52iiSJOqTvoPq/ir0Wx8HLVipphQYCzxaLbYT6lemWcG6DeCgwv4OSFzF
	WVu9jWLwBiQzjSj3+If6iGkbcHXCEH2+IYHn0Zd+xn/32xMpdoeJS5JTRK6kXd2G3ksf
	gtOw==
MIME-Version: 1.0
Received: by 10.68.226.42 with SMTP id rp10mr2614500pbc.162.1333796474827;
	Sat, 07 Apr 2012 04:01:14 -0700 (PDT)
Received: by 10.68.7.39 with HTTP; Sat, 7 Apr 2012 04:01:14 -0700 (PDT)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B10A95EAB@BITCOM1.int.sbss.com.au>
References: <CAP2B85-Q0BRb8j40e10CS39Mo4Z09nbiYWKw2Oo7ODGO=Wh0NQ@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B10A95EAB@BITCOM1.int.sbss.com.au>
Date: Sat, 7 Apr 2012 20:01:14 +0900
Message-ID: <CAP2B858QfdVabT+ogvgck-AfLumJ7kw8Y+z3cssjGZEL9gmONg@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Yes, out of sync, anyway...

On Fri, Mar 9, 2012 at 8:59 AM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> Hello All,
>>
>> I have a little setback with the development of PV Drivers for Xen in Se=
aBIOS.
>> The initialization code that runs in 32 Bit is working properly.
>> But, when the system tries to read on the disk I use the ring macros to =
get a
>> request. The macro usage looks like this:
>> struct blkif_ring * shared =3D memalign_low(4096,4096); //return
>> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So
>> far I have a pointer located at 0x0009a000 Under 32bit the struct is cor=
rect
>> and all is working according to plan.
>>
>> But on 16bit operation read on disk I have struct blkfront_info * shared=
_ring
>> =3D container_of(op->drive_g.info->shared)); // I get d630 I should get =
it from
>> the correct segment, but how?
>> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be
>> something 0xa010 segment SS or something like that
>
> Just curios, does 16 bit include the required atomic instructions to mani=
pulate the 32 bit ring counters? Or are you manipulating the ring in 32 bit=
 mode and only accessing the requests already retrieved from the ring in 16=
 bit mode?
This is my current problem, when I do
RING_GET_REQUEST(GET_GLOBAL(blk_info->private),GET_GLOBAL(blk_info->private=
->req_prod_pvt));
The return address is incorrect, so I guess since inside the
RING_REQUEST MACRO I make memory access I will need to rewrite the
macro to include the SeaBios macros needed to address 32bit pointers
in 16bit mode.
>
>> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by chan=
ging
>> the segment register, yet I do not know in what segment the ring is loca=
ted,
>> and the macros are not applied inside the procedure of the macro, for
>> example:
>> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring));
>> But this will change a 16Bit pointer of segment SS to a 32 bit segment. =
There
>> is also the reverse but, again I do not know the segment in which I shou=
ld
>> look for. Lastly the process inside the macro does not get this benefin,=
 and I
>> do not know if the macro will work with a pointer of size 16bits.
>>
>> Any help will be GREATLY appreciated, I am almost done.
>>
>
> I'm not sure if this would be useful, but is there a way to hand over the=
 ring to the OS PV drivers and avoid the teardown/setup?
This is before there is an OS. The bios handles the boot process,
right now I am trying to get the first read on the drive, the boot
sector.
>
> James
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 11:17:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 11:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGTdF-0003QY-2X; Sat, 07 Apr 2012 11:16:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SGTdC-0003QN-Ry
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 11:16:35 +0000
Received: from [85.158.138.51:60685] by server-9.bemta-3.messagelabs.com id
	38/C3-10923-112208F4; Sat, 07 Apr 2012 11:16:33 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333797391!21149728!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30041 invoked from network); 7 Apr 2012 11:16:32 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 11:16:32 -0000
Received: by dadp12 with SMTP id p12so4540682dad.7
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Apr 2012 04:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=zyFktlaBS7+f0gzjdhe/7CChYX+Cxe+Vp4MuZqih0js=;
	b=bCn9UXUnTTPAVPIAV0iAeFBRfkMyg2/JVRq2PH9irBLEWcJ3i4E0uuVrzoJ7Tx0rrQ
	7rlgoi54fRpaQ0xr1BJHnYgy8J3xGqWkcuCy9ZIkmHfXvnoBCFeqUQAwfz37pZr9t2D0
	0uZl7DKHv7lm3kTFsDHBpdk1KXX66u/v7lv+Jtd89eWX/1x/BNbMZ4l7xjZ2Equs/Uj9
	v/dTyFHwg746hv9q30u1npZb51sd34K31g7XpU3iqmMINJCH+a9JLhej2NEdbUoMaFZ1
	yX+XxoeFh4KF8SyytocpbyfzkGjsikX+q9hZCY2UOZsnbzyV2Yxx7W5eZzSbHbbS/fUj
	Fa0g==
MIME-Version: 1.0
Received: by 10.68.72.138 with SMTP id d10mr3362053pbv.15.1333797390618; Sat,
	07 Apr 2012 04:16:30 -0700 (PDT)
Received: by 10.68.7.39 with HTTP; Sat, 7 Apr 2012 04:16:30 -0700 (PDT)
In-Reply-To: <20120406195414.GA13732@phenom.dumpdata.com>
References: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
	<20120406195414.GA13732@phenom.dumpdata.com>
Date: Sat, 7 Apr 2012 20:16:30 +0900
Message-ID: <CAP2B858PZO=kLgbahFg7ODQ4QSLs2+t-oanBw+N=KSeJ0J5QjA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the response.

On Sat, Apr 7, 2012 at 4:54 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Apr 06, 2012 at 07:20:13PM +0900, Daniel Castro wrote:
>> hello All,
>>
>> I am still working on the PV Drivers for SeaBIOS using upstream qemu.
>> And, I have two questions.
>> 1.
>> Here is the location of all relevant data structs:
>> blkfront_info:0x000fd620 shared_ring:0x0009a000 private_ring:0x0009b000
>
> I surmise this is the guest PFNs.

Well this are virtual addresses seen by the BIOS on runtime.
>
>> DEBUG Read op private ring at 0x0009b000-0x000ab000, idx 63478
>> Here is my problem, when I do:
>> =A0 =A0 =A0 =A0 ring_req =3D
>> GLOBALFLAT2GLOBAL(RING_GET_REQUEST(GET_GLOBALFLAT(bi->private),GLOBALFLA=
T2GLOBAL(GET_GLOBALFLAT(bi->private)->req_prod_pvt)));
>> =A0//please ignore the MACROS for now, or read further down.
>> I get:
>> After RING_GET_REQUEST operation ring request is at 0xe18ea40f id:0
>> But I have the feeling that the request should be between
>> 0x0009b000-0x000ab000. Right?
>
> That would imply a physical address - but if you are running with
> pagetables (which I think you are?) then it would be virtual address.
>
> You should have some basic macros to translate from virtual to physical
> and vice-versa.
I can do the usual bit wise operation to get the page.
>
>>
>> 2.
>> As you can see in the above code I use some SeaBIOS macros to access
>> 32Bit addresses in 16Bit code. My second questions is: How the memory
>
> 16-bit code. Refresh my memory - does that mean you can only
> use segments and no paging? So you need to move a 16-bit window
> around to get to your 32-bit address?
Yes, but Seabios allows you to use a special malloc so that you do not
neet to handle the segment directly, if done correctly you can wrap
the memory access on a MACRO that will set the memory access with the
segment selector, make the access, and change the result to a 32bit
format.
>
>> access macros affect the RING macros? Do I need to rewrite the ring
>> macros to use the memory macros inside, for example:
>
> It should fit within a 16-bit (64K) contingous memory space.
> I don't think it matters where that the block is - as long as you
> have a segment selector activated for that 16-bit block.
>
>> /* How big is this ring? */
>> #define RING_SIZE(_r) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> =A0 =A0 ((_r)->nr_ents)
>
> That tells you just how many entries are on it. Not how big
> the structure is. For that it is sizeof(struct ..).
The problem on this particular case is this: (_r)->nr_ents; _r is a
pointer, if run in 16bit mode without the macros it will just be a an
offset, and since this is the BIOS there is no segmentation fault
generated, the BIOS allows me to make any access I want, even
incorrect ones.
I call this function like this: RING_SIZE(private_ring);
Where private_ring is a pointer created in 32bit mode, but is being
access with a 16bit address space. I can use the wrapper around the
pointer and make the Xen Macros call, but then I do not know if inside
the macros expansion it will be called under 32bit address or 16bit
address. For example:
Before the expansion
RING_SIZE(0x000d6200)                RING_SIZE(0x6200)
After the expansion
RING_SIZE((0x000d6200)->nr_ents)               RING_SIZE((0x6200)->nr_ents)
But here when the system does "->nr_ents" will this be done on 32bit
address or 16bit address? Clearly from the evidence it is doing it
under 16Bit address, hence my erratic answers.

I guess there could be a way to tell the compiler to expand the macro
with the use of the macros? or I am gust over complicating the problem
and I should directly rewrite the macros to include SeaBIOS macros?

One last explanation:
As I understand it, the macros works like this:
1. Set segment selector to appropriate value
2. make memory access
3. but return value on stack
4. set old value of segment selector
5. set value from stack on variable

variables on the stack can be considered 32bit.
>
>>
>> Should be instead:
>> /* How big is this ring? */
>> #define RING_SIZE(_r) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> =A0 =A0 (GET_GLOBAL((_r)->nr_ents))
>>
>> SeaBIOS macros need to be around ALL memory accesses.
>>
>> This is a short message for something that might be to complex to
>> explain briefly, so please ask any questions that you deem necessary
>> to understand. Right now, I am developing the first stage of boot when
>> the BIOS requests address 7c00 to get the Boot sector. Once I get this
>> working we should have a working prototype for PV-drivers in seabios.
>>
>> Thank you all for your interest,
>>
>> Daniel
>>
>> --
>> +-=3D=3D=3D=3D=3D---------------------------+
>> | +---------------------------------+ | This space intentionally blank
>> for notetaking.
>> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> | |=A0=A0 | Consultant/Programmer.|
>> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
>> +-------------------------------------+
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 11:17:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 11:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGTdF-0003QY-2X; Sat, 07 Apr 2012 11:16:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SGTdC-0003QN-Ry
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 11:16:35 +0000
Received: from [85.158.138.51:60685] by server-9.bemta-3.messagelabs.com id
	38/C3-10923-112208F4; Sat, 07 Apr 2012 11:16:33 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1333797391!21149728!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30041 invoked from network); 7 Apr 2012 11:16:32 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 11:16:32 -0000
Received: by dadp12 with SMTP id p12so4540682dad.7
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Apr 2012 04:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=zyFktlaBS7+f0gzjdhe/7CChYX+Cxe+Vp4MuZqih0js=;
	b=bCn9UXUnTTPAVPIAV0iAeFBRfkMyg2/JVRq2PH9irBLEWcJ3i4E0uuVrzoJ7Tx0rrQ
	7rlgoi54fRpaQ0xr1BJHnYgy8J3xGqWkcuCy9ZIkmHfXvnoBCFeqUQAwfz37pZr9t2D0
	0uZl7DKHv7lm3kTFsDHBpdk1KXX66u/v7lv+Jtd89eWX/1x/BNbMZ4l7xjZ2Equs/Uj9
	v/dTyFHwg746hv9q30u1npZb51sd34K31g7XpU3iqmMINJCH+a9JLhej2NEdbUoMaFZ1
	yX+XxoeFh4KF8SyytocpbyfzkGjsikX+q9hZCY2UOZsnbzyV2Yxx7W5eZzSbHbbS/fUj
	Fa0g==
MIME-Version: 1.0
Received: by 10.68.72.138 with SMTP id d10mr3362053pbv.15.1333797390618; Sat,
	07 Apr 2012 04:16:30 -0700 (PDT)
Received: by 10.68.7.39 with HTTP; Sat, 7 Apr 2012 04:16:30 -0700 (PDT)
In-Reply-To: <20120406195414.GA13732@phenom.dumpdata.com>
References: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
	<20120406195414.GA13732@phenom.dumpdata.com>
Date: Sat, 7 Apr 2012 20:16:30 +0900
Message-ID: <CAP2B858PZO=kLgbahFg7ODQ4QSLs2+t-oanBw+N=KSeJ0J5QjA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the response.

On Sat, Apr 7, 2012 at 4:54 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Apr 06, 2012 at 07:20:13PM +0900, Daniel Castro wrote:
>> hello All,
>>
>> I am still working on the PV Drivers for SeaBIOS using upstream qemu.
>> And, I have two questions.
>> 1.
>> Here is the location of all relevant data structs:
>> blkfront_info:0x000fd620 shared_ring:0x0009a000 private_ring:0x0009b000
>
> I surmise this is the guest PFNs.

Well this are virtual addresses seen by the BIOS on runtime.
>
>> DEBUG Read op private ring at 0x0009b000-0x000ab000, idx 63478
>> Here is my problem, when I do:
>> =A0 =A0 =A0 =A0 ring_req =3D
>> GLOBALFLAT2GLOBAL(RING_GET_REQUEST(GET_GLOBALFLAT(bi->private),GLOBALFLA=
T2GLOBAL(GET_GLOBALFLAT(bi->private)->req_prod_pvt)));
>> =A0//please ignore the MACROS for now, or read further down.
>> I get:
>> After RING_GET_REQUEST operation ring request is at 0xe18ea40f id:0
>> But I have the feeling that the request should be between
>> 0x0009b000-0x000ab000. Right?
>
> That would imply a physical address - but if you are running with
> pagetables (which I think you are?) then it would be virtual address.
>
> You should have some basic macros to translate from virtual to physical
> and vice-versa.
I can do the usual bit wise operation to get the page.
>
>>
>> 2.
>> As you can see in the above code I use some SeaBIOS macros to access
>> 32Bit addresses in 16Bit code. My second questions is: How the memory
>
> 16-bit code. Refresh my memory - does that mean you can only
> use segments and no paging? So you need to move a 16-bit window
> around to get to your 32-bit address?
Yes, but Seabios allows you to use a special malloc so that you do not
neet to handle the segment directly, if done correctly you can wrap
the memory access on a MACRO that will set the memory access with the
segment selector, make the access, and change the result to a 32bit
format.
>
>> access macros affect the RING macros? Do I need to rewrite the ring
>> macros to use the memory macros inside, for example:
>
> It should fit within a 16-bit (64K) contingous memory space.
> I don't think it matters where that the block is - as long as you
> have a segment selector activated for that 16-bit block.
>
>> /* How big is this ring? */
>> #define RING_SIZE(_r) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> =A0 =A0 ((_r)->nr_ents)
>
> That tells you just how many entries are on it. Not how big
> the structure is. For that it is sizeof(struct ..).
The problem on this particular case is this: (_r)->nr_ents; _r is a
pointer, if run in 16bit mode without the macros it will just be a an
offset, and since this is the BIOS there is no segmentation fault
generated, the BIOS allows me to make any access I want, even
incorrect ones.
I call this function like this: RING_SIZE(private_ring);
Where private_ring is a pointer created in 32bit mode, but is being
access with a 16bit address space. I can use the wrapper around the
pointer and make the Xen Macros call, but then I do not know if inside
the macros expansion it will be called under 32bit address or 16bit
address. For example:
Before the expansion
RING_SIZE(0x000d6200)                RING_SIZE(0x6200)
After the expansion
RING_SIZE((0x000d6200)->nr_ents)               RING_SIZE((0x6200)->nr_ents)
But here when the system does "->nr_ents" will this be done on 32bit
address or 16bit address? Clearly from the evidence it is doing it
under 16Bit address, hence my erratic answers.

I guess there could be a way to tell the compiler to expand the macro
with the use of the macros? or I am gust over complicating the problem
and I should directly rewrite the macros to include SeaBIOS macros?

One last explanation:
As I understand it, the macros works like this:
1. Set segment selector to appropriate value
2. make memory access
3. but return value on stack
4. set old value of segment selector
5. set value from stack on variable

variables on the stack can be considered 32bit.
>
>>
>> Should be instead:
>> /* How big is this ring? */
>> #define RING_SIZE(_r) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> =A0 =A0 (GET_GLOBAL((_r)->nr_ents))
>>
>> SeaBIOS macros need to be around ALL memory accesses.
>>
>> This is a short message for something that might be to complex to
>> explain briefly, so please ask any questions that you deem necessary
>> to understand. Right now, I am developing the first stage of boot when
>> the BIOS requests address 7c00 to get the Boot sector. Once I get this
>> working we should have a working prototype for PV-drivers in seabios.
>>
>> Thank you all for your interest,
>>
>> Daniel
>>
>> --
>> +-=3D=3D=3D=3D=3D---------------------------+
>> | +---------------------------------+ | This space intentionally blank
>> for notetaking.
>> | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> | |=A0=A0 | Consultant/Programmer.|
>> | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
>> +-------------------------------------+
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 12:42:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 12:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGUxY-0004GM-Fx; Sat, 07 Apr 2012 12:41:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGUxW-0004GH-W5
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 12:41:39 +0000
Received: from [85.158.139.83:64397] by server-12.bemta-5.messagelabs.com id
	F7/E9-05587-206308F4; Sat, 07 Apr 2012 12:41:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333802497!22171084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5523 invoked from network); 7 Apr 2012 12:41:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 12:41:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,386,1330905600"; d="scan'208";a="11819586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 12:39:51 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	13:39:51 +0100
Message-ID: <1333802390.12209.126.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Sat, 7 Apr 2012 13:39:50 +0100
In-Reply-To: <CAP2B858PZO=kLgbahFg7ODQ4QSLs2+t-oanBw+N=KSeJ0J5QjA@mail.gmail.com>
References: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
	<20120406195414.GA13732@phenom.dumpdata.com>
	<CAP2B858PZO=kLgbahFg7ODQ4QSLs2+t-oanBw+N=KSeJ0J5QjA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-07 at 12:16 +0100, Daniel Castro wrote:
> I guess there could be a way to tell the compiler to expand the macro
> with the use of the macros?

I don't think there is.

>  or I am gust over complicating the problem
> and I should directly rewrite the macros to include SeaBIOS macros? 

I think this is what you need to do.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 12:42:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 12:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGUxY-0004GM-Fx; Sat, 07 Apr 2012 12:41:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGUxW-0004GH-W5
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 12:41:39 +0000
Received: from [85.158.139.83:64397] by server-12.bemta-5.messagelabs.com id
	F7/E9-05587-206308F4; Sat, 07 Apr 2012 12:41:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1333802497!22171084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5523 invoked from network); 7 Apr 2012 12:41:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 12:41:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,386,1330905600"; d="scan'208";a="11819586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 12:39:51 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	13:39:51 +0100
Message-ID: <1333802390.12209.126.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Sat, 7 Apr 2012 13:39:50 +0100
In-Reply-To: <CAP2B858PZO=kLgbahFg7ODQ4QSLs2+t-oanBw+N=KSeJ0J5QjA@mail.gmail.com>
References: <CAP2B859xAsT7jPckxOzDranK88hM-o2DYHkFW_bCYqxJU-3UVQ@mail.gmail.com>
	<20120406195414.GA13732@phenom.dumpdata.com>
	<CAP2B858PZO=kLgbahFg7ODQ4QSLs2+t-oanBw+N=KSeJ0J5QjA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] C Macros and Xen RING Macros Questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-07 at 12:16 +0100, Daniel Castro wrote:
> I guess there could be a way to tell the compiler to expand the macro
> with the use of the macros?

I don't think there is.

>  or I am gust over complicating the problem
> and I should directly rewrite the macros to include SeaBIOS macros? 

I think this is what you need to do.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 13:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGVLH-0004Wx-JZ; Sat, 07 Apr 2012 13:06:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGVLG-0004Wp-9r
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 13:06:10 +0000
Received: from [193.109.254.147:25394] by server-10.bemta-14.messagelabs.com
	id 38/E3-05847-1CB308F4; Sat, 07 Apr 2012 13:06:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333803968!1137023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16094 invoked from network); 7 Apr 2012 13:06:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 13:06:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,386,1330905600"; d="scan'208";a="11819645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 13:06:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 14:06:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGVLD-0005ce-HS;
	Sat, 07 Apr 2012 13:06:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGVLD-0003nk-Gz;
	Sat, 07 Apr 2012 14:06:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12598-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 14:06:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12598: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12598 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12598/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64                   2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 13:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGVLH-0004Wx-JZ; Sat, 07 Apr 2012 13:06:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGVLG-0004Wp-9r
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 13:06:10 +0000
Received: from [193.109.254.147:25394] by server-10.bemta-14.messagelabs.com
	id 38/E3-05847-1CB308F4; Sat, 07 Apr 2012 13:06:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333803968!1137023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16094 invoked from network); 7 Apr 2012 13:06:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 13:06:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,386,1330905600"; d="scan'208";a="11819645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 13:06:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 14:06:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGVLD-0005ce-HS;
	Sat, 07 Apr 2012 13:06:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGVLD-0003nk-Gz;
	Sat, 07 Apr 2012 14:06:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12598-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 14:06:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12598: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12598 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12598/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64                   2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 14:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 14:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGWIu-0004wJ-F6; Sat, 07 Apr 2012 14:07:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SGWIt-0004wD-DQ
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 14:07:47 +0000
Received: from [85.158.139.83:25293] by server-2.bemta-5.messagelabs.com id
	45/33-17016-23A408F4; Sat, 07 Apr 2012 14:07:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333807664!18574630!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDMwODY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDMwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14014 invoked from network); 7 Apr 2012 14:07:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Apr 2012 14:07:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333807663; l=3024;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TohaOaWswunlkta49GNG7Yh/1gA=;
	b=pYZ031z+YzmLuHW02T8nI/IooEO2nR9Vdxe2KzDllrYnOXPyyKa9njVTnXha5D6fEJ7
	21hE0sUmWsGYGJu5SnYa/hcve7k6cfii4DKC0IDNyJOfqIg5nxLdpmYm6J142uWj9RWK5
	wPUK7ny9LjLbfFN39DOWvv4rIKeFo/w/aqA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiC0MEc3e
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-086-227.pools.arcor-ip.net [88.65.86.227])
	by smtp.strato.de (klopstock mo13) (RZmta 28.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y03655o37BmvYt ;
	Sat, 7 Apr 2012 16:07:42 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id BF9D818637; Sat,  7 Apr 2012 16:07:41 +0200 (CEST)
Date: Sat, 7 Apr 2012 16:07:41 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20120407140741.GA20086@aepfle.de>
References: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
	<20120403.133329.137901442.kuwa@jp.fujitsu.com>
	<20346.64910.885520.774577@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20346.64910.885520.774577@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: yang.z.zhang@intel.com, KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on
 old python versions [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Jackson wrote:

> Roger Pau Monne writes ("[Xen-devel] [PATCH v3] autoconf: fix python-dev detection on old python versions"):
> > Replaced the use of python-config (that is only present in Python >= 2.5.x)
> > with the distutils python module.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I think this is the cause for a regression between changeset 25138 and
25161 in openSuSE 11.4, 12.1 and upcoming 12.2. SLES11 still builds
fine:

...
configure:6205: checking for Python.h
configure:6205: result: yes
configure:6214: checking for PyArg_ParseTuple in -lpython2.7
configure:6239: gcc -o conftest  -g -O2   -g -O2  -I/usr/include/python2.7 -fno-strict-aliasing -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g    -lpthread -ldl  -lutil -lm -L/usr/lib64/python2.7/config -Xlinker -export-dynamic  conftest.c -lpython2.7   >&5
/usr/lib64/python2.7/config/libpython2.7.a(longobject.o): In function `PyLong_FromString':
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/longobject.c:1851: undefined reference to `log'
/usr/lib64/python2.7/config/libpython2.7.a(signalmodule.o): In function `timeval_from_double':
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:112: undefined reference to `floor'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:113: undefined reference to `fmod'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:112: undefined reference to `floor'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:113: undefined reference to `fmod'
/usr/lib64/python2.7/config/libpython2.7.a(complexobject.o): In function `_Py_c_pow':
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:139: undefined reference to `hypot'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:140: undefined reference to `pow'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:141: undefined reference to `atan2'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:145: undefined reference to `sincos'
...


I havent followed the discussion about the python detection. My
immediate reaction would be to use python-config when available.
This is what I get in the build chroot:

 python-config --cflags
 -I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing
 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
 -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG
 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
 -funwind-tables -fasynchronous-unwind-tables -g

 python-config --ldflags
 -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic

 python-config --libs
 -lpthread -ldl -lutil -lm -lpython2.7

 python-config --includes
 -I/usr/include/python2.7 -I/usr/include/python2.7


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 14:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 14:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGWIu-0004wJ-F6; Sat, 07 Apr 2012 14:07:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SGWIt-0004wD-DQ
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 14:07:47 +0000
Received: from [85.158.139.83:25293] by server-2.bemta-5.messagelabs.com id
	45/33-17016-23A408F4; Sat, 07 Apr 2012 14:07:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333807664!18574630!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDMwODY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDMwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14014 invoked from network); 7 Apr 2012 14:07:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Apr 2012 14:07:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1333807663; l=3024;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TohaOaWswunlkta49GNG7Yh/1gA=;
	b=pYZ031z+YzmLuHW02T8nI/IooEO2nR9Vdxe2KzDllrYnOXPyyKa9njVTnXha5D6fEJ7
	21hE0sUmWsGYGJu5SnYa/hcve7k6cfii4DKC0IDNyJOfqIg5nxLdpmYm6J142uWj9RWK5
	wPUK7ny9LjLbfFN39DOWvv4rIKeFo/w/aqA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiC0MEc3e
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-086-227.pools.arcor-ip.net [88.65.86.227])
	by smtp.strato.de (klopstock mo13) (RZmta 28.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y03655o37BmvYt ;
	Sat, 7 Apr 2012 16:07:42 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id BF9D818637; Sat,  7 Apr 2012 16:07:41 +0200 (CEST)
Date: Sat, 7 Apr 2012 16:07:41 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20120407140741.GA20086@aepfle.de>
References: <1333362466-2809-1-git-send-email-roger.pau@entel.upc.edu>
	<20120403.133329.137901442.kuwa@jp.fujitsu.com>
	<20346.64910.885520.774577@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20346.64910.885520.774577@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: yang.z.zhang@intel.com, KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] autoconf: fix python-dev detection on
 old python versions [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 03, Ian Jackson wrote:

> Roger Pau Monne writes ("[Xen-devel] [PATCH v3] autoconf: fix python-dev detection on old python versions"):
> > Replaced the use of python-config (that is only present in Python >= 2.5.x)
> > with the distutils python module.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I think this is the cause for a regression between changeset 25138 and
25161 in openSuSE 11.4, 12.1 and upcoming 12.2. SLES11 still builds
fine:

...
configure:6205: checking for Python.h
configure:6205: result: yes
configure:6214: checking for PyArg_ParseTuple in -lpython2.7
configure:6239: gcc -o conftest  -g -O2   -g -O2  -I/usr/include/python2.7 -fno-strict-aliasing -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g    -lpthread -ldl  -lutil -lm -L/usr/lib64/python2.7/config -Xlinker -export-dynamic  conftest.c -lpython2.7   >&5
/usr/lib64/python2.7/config/libpython2.7.a(longobject.o): In function `PyLong_FromString':
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/longobject.c:1851: undefined reference to `log'
/usr/lib64/python2.7/config/libpython2.7.a(signalmodule.o): In function `timeval_from_double':
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:112: undefined reference to `floor'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:113: undefined reference to `fmod'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:112: undefined reference to `floor'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/./Modules/signalmodule.c:113: undefined reference to `fmod'
/usr/lib64/python2.7/config/libpython2.7.a(complexobject.o): In function `_Py_c_pow':
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:139: undefined reference to `hypot'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:140: undefined reference to `pow'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:141: undefined reference to `atan2'
/home/abuild/rpmbuild/BUILD/Python-2.7.2/Objects/complexobject.c:145: undefined reference to `sincos'
...


I havent followed the discussion about the python detection. My
immediate reaction would be to use python-config when available.
This is what I get in the build chroot:

 python-config --cflags
 -I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing
 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
 -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG
 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
 -funwind-tables -fasynchronous-unwind-tables -g

 python-config --ldflags
 -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic

 python-config --libs
 -lpthread -ldl -lutil -lm -lpython2.7

 python-config --includes
 -I/usr/include/python2.7 -I/usr/include/python2.7


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 15:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 15:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGY2k-0005W5-Pi; Sat, 07 Apr 2012 15:59:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SGY2j-0005W0-C3
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 15:59:13 +0000
Received: from [85.158.139.83:2704] by server-10.bemta-5.messagelabs.com id
	03/21-08260-054608F4; Sat, 07 Apr 2012 15:59:12 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333814350!20150316!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21047 invoked from network); 7 Apr 2012 15:59:11 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-182.messagelabs.com with SMTP;
	7 Apr 2012 15:59:11 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q37Fx657004224;
	Sat, 7 Apr 2012 10:59:06 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q37Fx5u3004223;
	Sat, 7 Apr 2012 10:59:05 -0500
Date: Sat, 7 Apr 2012 10:59:05 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204071559.q37Fx5u3004223@wind.enjellic.com>
In-Reply-To: Ian Campbell <Ian.Campbell@citrix.com>
	"Re: [Xen-devel] Basic blktap2 functionality issues." (Mar 30, 12:23pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sat, 07 Apr 2012 10:59:06 -0500 (CDT)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mar 30, 12:23pm, Ian Campbell wrote:
} Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

Hi, hope the weekend is going well for everyone.

Sorry for the delay in getting back to everyone on this, had a
deadline on another project.

> On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > I think an approach worth trying would be to have
> > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > doing the actual detach. i.e. it would respond with "Yes, I will do
> > that" rather than "Yes, I have done that". My speculation is that this
> > will allow libxl to continue and hopefully avoid the deadlock.

> This seems to be the case as the following fixes things for
> me. Thanks very much for your analysis which lead me to this
> solution...

I ported your fix into 4.1.2 but I think we still have a problem, at
least in this codebase.

I no longer see the select timeout delay when xl shuts down but upon
shutdown the minor number is not freed.  A 'tap-ctl list' shows a
steadily increasing set of orphaned minor numbers as VM's are started
up and shutdown.

Are you seeing this in your development codebase?

The culprit is a failed ioctl call for BLKTAP2_IOCTL_FREE_TAP in
tap_ctl_free().  The underlying reason for the ioctl failure is the
check in [linuxsrc]:drivers/block/blktap/ring.c:blktap_ring_destroy()
for whether or not the task_struct pointer in the blktap_ring
structure has been NULLed.

Which certainly makes sense since there is a race between xl's call to
tap_ctl_free() and tapdisk2 getting to the point where it can close
its descriptor to the blktap instance and thus invoke the .release
method which translates into a call to blktap_ring_release() which
NULL's the task_struct pointer.

If you are not seeing the orphan minor numbers there must be ordering
changes in the unstable version of xl which eliminate or alters the
race timing.

For the sake of completeness of information for this thread I captured
the following stack trace of a tapdisk2 when it is deadlocked against
xl:

---------------------------------------------------------------------------
Apr  1 07:03:45 hooter kernel: Call Trace:
Apr  1 07:03:45 hooter kernel:  [<c10aa791>] ? blkdev_get_blocks+0xb4/0xb4
Apr  1 07:03:45 hooter kernel:  [<c109ab11>] ? iput+0x28/0x143
Apr  1 07:03:45 hooter kernel:  [<c10e9fec>] ? blk_peek_request+0x155/0x165
Apr  1 07:03:45 hooter kernel:  [<c128279c>] schedule+0x4d/0x4f
Apr  1 07:03:45 hooter kernel:  [<f7a9053b>] blktap_device_destroy_sync+0x63/0x76 [blktap]
Apr  1 07:03:45 hooter kernel:  [<c104204a>] ? wake_up_bit+0x61/0x61
Apr  1 07:03:45 hooter kernel:  [<f7a8f57a>] blktap_ring_release+0xe/0x29 [blktap]
Apr  1 07:03:45 hooter kernel:  [<c108aba7>] fput+0xce/0x167
Apr  1 07:03:45 hooter kernel:  [<c107944a>] remove_vma+0x28/0x47
Apr  1 07:03:45 hooter kernel:  [<c107a19a>] do_munmap+0x1e8/0x204
Apr  1 07:03:45 hooter kernel:  [<c107a1de>] sys_munmap+0x28/0x37
Apr  1 07:03:45 hooter kernel:  [<c1284adc>] sysenter_do_call+0x12/0x2c
Apr  1 07:03:45 hooter kernel:  [<c1280000>] ? migration_call+0x1d9/0x1f2
Apr  1 07:03:45 hooter kernel:  c686dad0 00000286 c1045bcd e86581c0 e84f6380 c13d1c80 c13d1c80 d753476c
Apr  1 07:03:45 hooter kernel:  e9185b00 e9185c78 00000000 d75346cb 00002ad2 d75346cb e8515ae4 e8515ae4
Apr  1 07:03:45 hooter kernel:  c1005597 00000000 ed7d80c8 c686dae4 c686da98 c1005d10 ed7d02c0 00000000
---------------------------------------------------------------------------

Let me know if you are seeing the issues I'm seeing, in the meantime I
will keep hunting to see if I can rundown the ultimate cause of the
deadlock.  Given the above trace it has to be an issue with xl
orchestrating the release of resources which reference the tapdev
block device.

> Ian.

Will look forward to your thoughts.

Have a good weekend.

}-- End of excerpt from Ian Campbell

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"According to the philosopher Ly Tin Wheedle, chaos is found in greatest
 abundance wherever order is being sought.  It always defeats order,
 because it is better organized."
                                -- Terry Pratchett
                                   Interesting Times

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 15:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 15:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGY2k-0005W5-Pi; Sat, 07 Apr 2012 15:59:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SGY2j-0005W0-C3
	for xen-devel@lists.xen.org; Sat, 07 Apr 2012 15:59:13 +0000
Received: from [85.158.139.83:2704] by server-10.bemta-5.messagelabs.com id
	03/21-08260-054608F4; Sat, 07 Apr 2012 15:59:12 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333814350!20150316!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21047 invoked from network); 7 Apr 2012 15:59:11 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-4.tower-182.messagelabs.com with SMTP;
	7 Apr 2012 15:59:11 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q37Fx657004224;
	Sat, 7 Apr 2012 10:59:06 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q37Fx5u3004223;
	Sat, 7 Apr 2012 10:59:05 -0500
Date: Sat, 7 Apr 2012 10:59:05 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204071559.q37Fx5u3004223@wind.enjellic.com>
In-Reply-To: Ian Campbell <Ian.Campbell@citrix.com>
	"Re: [Xen-devel] Basic blktap2 functionality issues." (Mar 30, 12:23pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sat, 07 Apr 2012 10:59:06 -0500 (CDT)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mar 30, 12:23pm, Ian Campbell wrote:
} Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

Hi, hope the weekend is going well for everyone.

Sorry for the delay in getting back to everyone on this, had a
deadline on another project.

> On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > I think an approach worth trying would be to have
> > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > doing the actual detach. i.e. it would respond with "Yes, I will do
> > that" rather than "Yes, I have done that". My speculation is that this
> > will allow libxl to continue and hopefully avoid the deadlock.

> This seems to be the case as the following fixes things for
> me. Thanks very much for your analysis which lead me to this
> solution...

I ported your fix into 4.1.2 but I think we still have a problem, at
least in this codebase.

I no longer see the select timeout delay when xl shuts down but upon
shutdown the minor number is not freed.  A 'tap-ctl list' shows a
steadily increasing set of orphaned minor numbers as VM's are started
up and shutdown.

Are you seeing this in your development codebase?

The culprit is a failed ioctl call for BLKTAP2_IOCTL_FREE_TAP in
tap_ctl_free().  The underlying reason for the ioctl failure is the
check in [linuxsrc]:drivers/block/blktap/ring.c:blktap_ring_destroy()
for whether or not the task_struct pointer in the blktap_ring
structure has been NULLed.

Which certainly makes sense since there is a race between xl's call to
tap_ctl_free() and tapdisk2 getting to the point where it can close
its descriptor to the blktap instance and thus invoke the .release
method which translates into a call to blktap_ring_release() which
NULL's the task_struct pointer.

If you are not seeing the orphan minor numbers there must be ordering
changes in the unstable version of xl which eliminate or alters the
race timing.

For the sake of completeness of information for this thread I captured
the following stack trace of a tapdisk2 when it is deadlocked against
xl:

---------------------------------------------------------------------------
Apr  1 07:03:45 hooter kernel: Call Trace:
Apr  1 07:03:45 hooter kernel:  [<c10aa791>] ? blkdev_get_blocks+0xb4/0xb4
Apr  1 07:03:45 hooter kernel:  [<c109ab11>] ? iput+0x28/0x143
Apr  1 07:03:45 hooter kernel:  [<c10e9fec>] ? blk_peek_request+0x155/0x165
Apr  1 07:03:45 hooter kernel:  [<c128279c>] schedule+0x4d/0x4f
Apr  1 07:03:45 hooter kernel:  [<f7a9053b>] blktap_device_destroy_sync+0x63/0x76 [blktap]
Apr  1 07:03:45 hooter kernel:  [<c104204a>] ? wake_up_bit+0x61/0x61
Apr  1 07:03:45 hooter kernel:  [<f7a8f57a>] blktap_ring_release+0xe/0x29 [blktap]
Apr  1 07:03:45 hooter kernel:  [<c108aba7>] fput+0xce/0x167
Apr  1 07:03:45 hooter kernel:  [<c107944a>] remove_vma+0x28/0x47
Apr  1 07:03:45 hooter kernel:  [<c107a19a>] do_munmap+0x1e8/0x204
Apr  1 07:03:45 hooter kernel:  [<c107a1de>] sys_munmap+0x28/0x37
Apr  1 07:03:45 hooter kernel:  [<c1284adc>] sysenter_do_call+0x12/0x2c
Apr  1 07:03:45 hooter kernel:  [<c1280000>] ? migration_call+0x1d9/0x1f2
Apr  1 07:03:45 hooter kernel:  c686dad0 00000286 c1045bcd e86581c0 e84f6380 c13d1c80 c13d1c80 d753476c
Apr  1 07:03:45 hooter kernel:  e9185b00 e9185c78 00000000 d75346cb 00002ad2 d75346cb e8515ae4 e8515ae4
Apr  1 07:03:45 hooter kernel:  c1005597 00000000 ed7d80c8 c686dae4 c686da98 c1005d10 ed7d02c0 00000000
---------------------------------------------------------------------------

Let me know if you are seeing the issues I'm seeing, in the meantime I
will keep hunting to see if I can rundown the ultimate cause of the
deadlock.  Given the above trace it has to be an issue with xl
orchestrating the release of resources which reference the tapdev
block device.

> Ian.

Will look forward to your thoughts.

Have a good weekend.

}-- End of excerpt from Ian Campbell

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"According to the philosopher Ly Tin Wheedle, chaos is found in greatest
 abundance wherever order is being sought.  It always defeats order,
 because it is better organized."
                                -- Terry Pratchett
                                   Interesting Times

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 16:30:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 16:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGYWR-0006mL-He; Sat, 07 Apr 2012 16:29:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGYWP-0006mE-G2
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 16:29:53 +0000
Received: from [85.158.139.83:25203] by server-11.bemta-5.messagelabs.com id
	82/30-12959-08B608F4; Sat, 07 Apr 2012 16:29:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333816189!22854912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11391 invoked from network); 7 Apr 2012 16:29:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 16:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,387,1330905600"; d="scan'208";a="11820828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 16:29:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 17:29:46 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGYWI-0006gG-Ln;
	Sat, 07 Apr 2012 16:29:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGYWI-0008Ie-ER;
	Sat, 07 Apr 2012 17:29:46 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12599-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 17:29:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12599: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12599 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12599/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 12557
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 12557
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass

version targeted for testing:
 linux                f68e556e23d1a4176b563bcb25d8baf2c5313f91
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 16:30:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 16:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGYWR-0006mL-He; Sat, 07 Apr 2012 16:29:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGYWP-0006mE-G2
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 16:29:53 +0000
Received: from [85.158.139.83:25203] by server-11.bemta-5.messagelabs.com id
	82/30-12959-08B608F4; Sat, 07 Apr 2012 16:29:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1333816189!22854912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11391 invoked from network); 7 Apr 2012 16:29:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 16:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,387,1330905600"; d="scan'208";a="11820828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 16:29:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 17:29:46 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGYWI-0006gG-Ln;
	Sat, 07 Apr 2012 16:29:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGYWI-0008Ie-ER;
	Sat, 07 Apr 2012 17:29:46 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12599-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 17:29:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12599: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12599 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12599/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12557
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 12557
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12557
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 12557
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12557
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass

version targeted for testing:
 linux                f68e556e23d1a4176b563bcb25d8baf2c5313f91
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 18:41:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 18:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGaYq-0007Zv-Fw; Sat, 07 Apr 2012 18:40:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGaYo-0007Zq-O4
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 18:40:31 +0000
Received: from [85.158.138.51:54158] by server-9.bemta-3.messagelabs.com id
	D9/CB-10923-D1A808F4; Sat, 07 Apr 2012 18:40:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333824028!16994439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26217 invoked from network); 7 Apr 2012 18:40:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 18:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,387,1330905600"; d="scan'208";a="11821741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 18:40:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 19:40:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGaYM-0007Mb-Jq;
	Sat, 07 Apr 2012 18:40:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGaYM-0001k1-Hs;
	Sat, 07 Apr 2012 19:40:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12600-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 19:40:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12600: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12600 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12600/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                c0994f584243578a83f7691429071a0996869abd
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit c0994f584243578a83f7691429071a0996869abd
Merge: 3b08864... 314489b...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 6 10:38:32 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 18:41:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 18:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGaYq-0007Zv-Fw; Sat, 07 Apr 2012 18:40:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGaYo-0007Zq-O4
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 18:40:31 +0000
Received: from [85.158.138.51:54158] by server-9.bemta-3.messagelabs.com id
	D9/CB-10923-D1A808F4; Sat, 07 Apr 2012 18:40:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1333824028!16994439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26217 invoked from network); 7 Apr 2012 18:40:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 18:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,387,1330905600"; d="scan'208";a="11821741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 18:40:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 19:40:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGaYM-0007Mb-Jq;
	Sat, 07 Apr 2012 18:40:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGaYM-0001k1-Hs;
	Sat, 07 Apr 2012 19:40:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12600-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 19:40:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12600: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12600 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12600/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                c0994f584243578a83f7691429071a0996869abd
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit c0994f584243578a83f7691429071a0996869abd
Merge: 3b08864... 314489b...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 6 10:38:32 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 19:10:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 19:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGb0u-0007t9-4Q; Sat, 07 Apr 2012 19:09:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGb0s-0007sy-G6
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 19:09:30 +0000
Received: from [85.158.138.51:15349] by server-4.bemta-3.messagelabs.com id
	6E/59-16467-9E0908F4; Sat, 07 Apr 2012 19:09:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333825768!21189630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28689 invoked from network); 7 Apr 2012 19:09:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 19:09:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,387,1330905600"; d="scan'208";a="11821822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 19:09:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 20:09:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGb0p-0007Vs-Hk;
	Sat, 07 Apr 2012 19:09:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGb0p-0004d3-HD;
	Sat, 07 Apr 2012 20:09:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12601-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 20:09:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12601: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12601 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12601/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 build-i386                    2 host-install(2)         broken REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 19:10:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 19:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGb0u-0007t9-4Q; Sat, 07 Apr 2012 19:09:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGb0s-0007sy-G6
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 19:09:30 +0000
Received: from [85.158.138.51:15349] by server-4.bemta-3.messagelabs.com id
	6E/59-16467-9E0908F4; Sat, 07 Apr 2012 19:09:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1333825768!21189630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28689 invoked from network); 7 Apr 2012 19:09:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 19:09:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,387,1330905600"; d="scan'208";a="11821822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 19:09:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Apr 2012 20:09:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGb0p-0007Vs-Hk;
	Sat, 07 Apr 2012 19:09:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGb0p-0004d3-HD;
	Sat, 07 Apr 2012 20:09:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12601-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Apr 2012 20:09:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12601: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12601 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12601/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 build-i386                    2 host-install(2)         broken REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 23:30:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 23:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGf4Z-0000Tq-CU; Sat, 07 Apr 2012 23:29:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGf4Y-0000Tl-3S
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 23:29:34 +0000
Received: from [85.158.139.83:55696] by server-7.bemta-5.messagelabs.com id
	28/6C-16195-DDDC08F4; Sat, 07 Apr 2012 23:29:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333841371!11604655!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12090 invoked from network); 7 Apr 2012 23:29:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 23:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,388,1330905600"; d="scan'208";a="11822340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 23:29:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 00:29:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGf4V-0000ZO-2f;
	Sat, 07 Apr 2012 23:29:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGf4V-0004qe-0B;
	Sun, 08 Apr 2012 00:29:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12603-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 00:29:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12603: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12603 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12603/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 07 23:30:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Apr 2012 23:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGf4Z-0000Tq-CU; Sat, 07 Apr 2012 23:29:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGf4Y-0000Tl-3S
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 23:29:34 +0000
Received: from [85.158.139.83:55696] by server-7.bemta-5.messagelabs.com id
	28/6C-16195-DDDC08F4; Sat, 07 Apr 2012 23:29:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1333841371!11604655!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzIzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12090 invoked from network); 7 Apr 2012 23:29:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 23:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,388,1330905600"; d="scan'208";a="11822340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 23:29:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 00:29:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGf4V-0000ZO-2f;
	Sat, 07 Apr 2012 23:29:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGf4V-0004qe-0B;
	Sun, 08 Apr 2012 00:29:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12603-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 00:29:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12603: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12603 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12603/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 05:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 05:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGkMj-0006Q5-ND; Sun, 08 Apr 2012 05:08:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGkMh-0006Q0-SN
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 05:08:40 +0000
Received: from [85.158.143.99:49070] by server-3.bemta-4.messagelabs.com id
	BB/44-05853-75D118F4; Sun, 08 Apr 2012 05:08:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333861718!22180721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23912 invoked from network); 8 Apr 2012 05:08:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 05:08:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,389,1330905600"; d="scan'208";a="11822870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 05:08:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 06:08:37 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGkMf-0002NN-Dm;
	Sun, 08 Apr 2012 05:08:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGkMf-000146-An;
	Sun, 08 Apr 2012 06:08:37 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12605-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 06:08:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12605: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12605 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12605/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 05:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 05:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGkMj-0006Q5-ND; Sun, 08 Apr 2012 05:08:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGkMh-0006Q0-SN
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 05:08:40 +0000
Received: from [85.158.143.99:49070] by server-3.bemta-4.messagelabs.com id
	BB/44-05853-75D118F4; Sun, 08 Apr 2012 05:08:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333861718!22180721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23912 invoked from network); 8 Apr 2012 05:08:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 05:08:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,389,1330905600"; d="scan'208";a="11822870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 05:08:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 06:08:37 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGkMf-0002NN-Dm;
	Sun, 08 Apr 2012 05:08:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGkMf-000146-An;
	Sun, 08 Apr 2012 06:08:37 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12605-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 06:08:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12605: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12605 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12605/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 06:49:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 06:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGlvc-0006vn-Gc; Sun, 08 Apr 2012 06:48:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SGlvb-0006vh-CT
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 06:48:47 +0000
Received: from [85.158.139.83:20287] by server-5.bemta-5.messagelabs.com id
	54/CF-13566-EC4318F4; Sun, 08 Apr 2012 06:48:46 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333867724!19018119!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14973 invoked from network); 8 Apr 2012 06:48:45 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-6.tower-182.messagelabs.com with SMTP;
	8 Apr 2012 06:48:45 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id C7A8EDBBB1
	for <xen-devel@lists.xen.org>; Sun,  8 Apr 2012 14:48:28 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so1795265vcb.32
	for <xen-devel@lists.xen.org>; Sat, 07 Apr 2012 23:48:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.201.199 with SMTP id fb7mr1696168vcb.15.1333867705192;
	Sat, 07 Apr 2012 23:48:25 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Sat, 7 Apr 2012 23:48:25 -0700 (PDT)
In-Reply-To: <4F7F1D14.9040208@amd.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
Date: Sun, 8 Apr 2012 14:48:25 +0800
Message-ID: <CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: wei.huang2@amd.com
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, marcus.granado@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 7, 2012 at 12:43 AM, Wei Huang <wei.huang2@amd.com> wrote:
> On 04/06/2012 10:41 AM, Lin Ming wrote:
>>
>> Hi list,
>>
>> Is anybody working on virtualization of the CPU Performance Monitoring
>> Unit?
>>
>> There are 2 PMU related projects listed on GSoC 2012 page.
>> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
>>
>> - Virtualization of the CPU Performance Monitoring Unit
>> - Perf support for Xen
>>
>> I'm interested on these 2 projects.
>
> Hi Lin,
>
> 1. I don't think Xen was accepted as an organization for 2012 GSOC. See
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.

It doesn't matter.
I just want to find something valuable to do.

> 2. The PMU project description in the wiki is vague. I know HVM guests
> support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> directories. You better ask mentors for details (maybe this is XCP
> specific?).

(CC mentors)

I tested PMU/Perf support with xen-unstable, dom0 3.3 kernel, domU
3.4-rc1 kernel.
Here is the result on an Intel SandyBrige machine.

- In dom0

# dmesg |grep -i "Performance Event"
Performance Events: unsupported p6 CPU model 42 no PMU driver,
software events only.

Hardware events are not supported yet in dom0.

- In domU
# dmesg |grep -i "Performance Events"
Performance Events: 16-deep LBR, SandyBridge events, Intel PMU driver.

Seems domU has support for hardware events.
But "perf" does not work on domU.
Run "perf top", but no data was collected.

# cat /proc/interrupts |grep "PMI"
 PMI:          0          0   Performance monitoring interrupts

No PMU interrupts.

BTW, I also tested KVM-Qemu.
"perf" works well on KVM-Qemu.

Thanks,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 06:49:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 06:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGlvc-0006vn-Gc; Sun, 08 Apr 2012 06:48:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SGlvb-0006vh-CT
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 06:48:47 +0000
Received: from [85.158.139.83:20287] by server-5.bemta-5.messagelabs.com id
	54/CF-13566-EC4318F4; Sun, 08 Apr 2012 06:48:46 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-6.tower-182.messagelabs.com!1333867724!19018119!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14973 invoked from network); 8 Apr 2012 06:48:45 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-6.tower-182.messagelabs.com with SMTP;
	8 Apr 2012 06:48:45 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id C7A8EDBBB1
	for <xen-devel@lists.xen.org>; Sun,  8 Apr 2012 14:48:28 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so1795265vcb.32
	for <xen-devel@lists.xen.org>; Sat, 07 Apr 2012 23:48:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.201.199 with SMTP id fb7mr1696168vcb.15.1333867705192;
	Sat, 07 Apr 2012 23:48:25 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Sat, 7 Apr 2012 23:48:25 -0700 (PDT)
In-Reply-To: <4F7F1D14.9040208@amd.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
Date: Sun, 8 Apr 2012 14:48:25 +0800
Message-ID: <CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: wei.huang2@amd.com
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, marcus.granado@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 7, 2012 at 12:43 AM, Wei Huang <wei.huang2@amd.com> wrote:
> On 04/06/2012 10:41 AM, Lin Ming wrote:
>>
>> Hi list,
>>
>> Is anybody working on virtualization of the CPU Performance Monitoring
>> Unit?
>>
>> There are 2 PMU related projects listed on GSoC 2012 page.
>> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
>>
>> - Virtualization of the CPU Performance Monitoring Unit
>> - Perf support for Xen
>>
>> I'm interested on these 2 projects.
>
> Hi Lin,
>
> 1. I don't think Xen was accepted as an organization for 2012 GSOC. See
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.

It doesn't matter.
I just want to find something valuable to do.

> 2. The PMU project description in the wiki is vague. I know HVM guests
> support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> directories. You better ask mentors for details (maybe this is XCP
> specific?).

(CC mentors)

I tested PMU/Perf support with xen-unstable, dom0 3.3 kernel, domU
3.4-rc1 kernel.
Here is the result on an Intel SandyBrige machine.

- In dom0

# dmesg |grep -i "Performance Event"
Performance Events: unsupported p6 CPU model 42 no PMU driver,
software events only.

Hardware events are not supported yet in dom0.

- In domU
# dmesg |grep -i "Performance Events"
Performance Events: 16-deep LBR, SandyBridge events, Intel PMU driver.

Seems domU has support for hardware events.
But "perf" does not work on domU.
Run "perf top", but no data was collected.

# cat /proc/interrupts |grep "PMI"
 PMI:          0          0   Performance monitoring interrupts

No PMU interrupts.

BTW, I also tested KVM-Qemu.
"perf" works well on KVM-Qemu.

Thanks,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 06:59:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 06:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGm58-000756-JC; Sun, 08 Apr 2012 06:58:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SGm56-000751-FI
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 06:58:36 +0000
Received: from [85.158.138.51:3670] by server-4.bemta-3.messagelabs.com id
	EC/B6-16467-B17318F4; Sun, 08 Apr 2012 06:58:35 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333868313!21143353!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5208 invoked from network); 8 Apr 2012 06:58:34 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-8.tower-174.messagelabs.com with SMTP;
	8 Apr 2012 06:58:34 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 865A6DBC93
	for <xen-devel@lists.xen.org>; Sun,  8 Apr 2012 14:58:16 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so1797219vcb.32
	for <xen-devel@lists.xen.org>; Sat, 07 Apr 2012 23:58:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.201.199 with SMTP id fb7mr1705872vcb.15.1333868294445;
	Sat, 07 Apr 2012 23:58:14 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Sat, 7 Apr 2012 23:58:14 -0700 (PDT)
In-Reply-To: <20120406183618.GA13473@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<20120406183618.GA13473@phenom.dumpdata.com>
Date: Sun, 8 Apr 2012 14:58:14 +0800
Message-ID: <CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Wei Huang <wei.huang2@amd.com>, marcus.granado@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 7, 2012 at 2:36 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
>> On 04/06/2012 10:41 AM, Lin Ming wrote:
>> >Hi list,
>> >
>> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
>> >
>> >There are 2 PMU related projects listed on GSoC 2012 page.
>> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
>> >
>> >- Virtualization of the CPU Performance Monitoring Unit
>> >- Perf support for Xen
>> >
>> >I'm interested on these 2 projects.
>> Hi Lin,
>>
>> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
>> See
>> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
>> 2. The PMU project description in the wiki is vague. I know HVM
>> guests support virtualized PMU. Please check vpmu.c files in /hvm,
>> /svm, and /vmx directories. You better ask mentors for details
>> (maybe this is XCP specific?).
>
> This is dom0 related. So being able to use perf to instrument
> the hypervisor (and the guests from dom0).

For guests instrument:

How about use perf on guests(domU) directly?

Thanks,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 06:59:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 06:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGm58-000756-JC; Sun, 08 Apr 2012 06:58:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SGm56-000751-FI
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 06:58:36 +0000
Received: from [85.158.138.51:3670] by server-4.bemta-3.messagelabs.com id
	EC/B6-16467-B17318F4; Sun, 08 Apr 2012 06:58:35 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-8.tower-174.messagelabs.com!1333868313!21143353!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5208 invoked from network); 8 Apr 2012 06:58:34 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-8.tower-174.messagelabs.com with SMTP;
	8 Apr 2012 06:58:34 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 865A6DBC93
	for <xen-devel@lists.xen.org>; Sun,  8 Apr 2012 14:58:16 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so1797219vcb.32
	for <xen-devel@lists.xen.org>; Sat, 07 Apr 2012 23:58:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.201.199 with SMTP id fb7mr1705872vcb.15.1333868294445;
	Sat, 07 Apr 2012 23:58:14 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Sat, 7 Apr 2012 23:58:14 -0700 (PDT)
In-Reply-To: <20120406183618.GA13473@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<20120406183618.GA13473@phenom.dumpdata.com>
Date: Sun, 8 Apr 2012 14:58:14 +0800
Message-ID: <CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Wei Huang <wei.huang2@amd.com>, marcus.granado@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 7, 2012 at 2:36 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
>> On 04/06/2012 10:41 AM, Lin Ming wrote:
>> >Hi list,
>> >
>> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
>> >
>> >There are 2 PMU related projects listed on GSoC 2012 page.
>> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
>> >
>> >- Virtualization of the CPU Performance Monitoring Unit
>> >- Perf support for Xen
>> >
>> >I'm interested on these 2 projects.
>> Hi Lin,
>>
>> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
>> See
>> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
>> 2. The PMU project description in the wiki is vague. I know HVM
>> guests support virtualized PMU. Please check vpmu.c files in /hvm,
>> /svm, and /vmx directories. You better ask mentors for details
>> (maybe this is XCP specific?).
>
> This is dom0 related. So being able to use perf to instrument
> the hypervisor (and the guests from dom0).

For guests instrument:

How about use perf on guests(domU) directly?

Thanks,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 09:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 09:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGo40-000090-B1; Sun, 08 Apr 2012 09:05:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGo3y-00008t-Du
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 09:05:34 +0000
Received: from [85.158.143.35:17000] by server-1.bemta-4.messagelabs.com id
	5A/75-20925-DD4518F4; Sun, 08 Apr 2012 09:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333875932!15332891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4682 invoked from network); 8 Apr 2012 09:05:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 09:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,389,1330905600"; d="scan'208";a="11823618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 09:05:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 10:05:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGo3s-0003fc-UV;
	Sun, 08 Apr 2012 09:05:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGo3s-0004U4-Q0;
	Sun, 08 Apr 2012 10:05:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12606-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 10:05:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12606: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12606 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12606/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern          2 host-install(2) broken in 12595 REGR. vs. 12606

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 12595
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 12595
 test-amd64-i386-xl-multivcpu  3 host-install(3)  broken in 12595 pass in 12606
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 12595 pass in 12606
 test-i386-i386-xl             3 host-install(3)  broken in 12595 pass in 12606
 test-amd64-i386-xl-credit2    9 guest-start        fail in 12595 pass in 12606

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12595
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)             broken like 12595
 test-amd64-amd64-win          3 host-install(3)              broken like 12595
 test-amd64-i386-xl            3 host-install(3)              broken like 12595

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 09:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 09:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGo40-000090-B1; Sun, 08 Apr 2012 09:05:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGo3y-00008t-Du
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 09:05:34 +0000
Received: from [85.158.143.35:17000] by server-1.bemta-4.messagelabs.com id
	5A/75-20925-DD4518F4; Sun, 08 Apr 2012 09:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333875932!15332891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4682 invoked from network); 8 Apr 2012 09:05:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 09:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,389,1330905600"; d="scan'208";a="11823618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 09:05:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 10:05:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGo3s-0003fc-UV;
	Sun, 08 Apr 2012 09:05:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGo3s-0004U4-Q0;
	Sun, 08 Apr 2012 10:05:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12606-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 10:05:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12606: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12606 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12606/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern          2 host-install(2) broken in 12595 REGR. vs. 12606

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 12595
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 12595
 test-amd64-i386-xl-multivcpu  3 host-install(3)  broken in 12595 pass in 12606
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 12595 pass in 12606
 test-i386-i386-xl             3 host-install(3)  broken in 12595 pass in 12606
 test-amd64-i386-xl-credit2    9 guest-start        fail in 12595 pass in 12606

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12595
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)             broken like 12595
 test-amd64-amd64-win          3 host-install(3)              broken like 12595
 test-amd64-i386-xl            3 host-install(3)              broken like 12595

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 12:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 12:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGrQz-0001tj-N5; Sun, 08 Apr 2012 12:41:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGrQy-0001te-HT
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 12:41:32 +0000
Received: from [85.158.143.99:15152] by server-3.bemta-4.messagelabs.com id
	86/C5-05853-B77818F4; Sun, 08 Apr 2012 12:41:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333888890!21868170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30771 invoked from network); 8 Apr 2012 12:41:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 12:41:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,389,1330905600"; d="scan'208";a="11824468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 12:41:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 13:41:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGrQu-0004tI-Uo;
	Sun, 08 Apr 2012 12:41:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGrQu-0000KF-Px;
	Sun, 08 Apr 2012 13:41:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12608-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 13:41:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12608: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12608 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12608/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 12:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 12:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGrQz-0001tj-N5; Sun, 08 Apr 2012 12:41:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGrQy-0001te-HT
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 12:41:32 +0000
Received: from [85.158.143.99:15152] by server-3.bemta-4.messagelabs.com id
	86/C5-05853-B77818F4; Sun, 08 Apr 2012 12:41:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1333888890!21868170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30771 invoked from network); 8 Apr 2012 12:41:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 12:41:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,389,1330905600"; d="scan'208";a="11824468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 12:41:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 13:41:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGrQu-0004tI-Uo;
	Sun, 08 Apr 2012 12:41:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGrQu-0000KF-Px;
	Sun, 08 Apr 2012 13:41:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12608-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 13:41:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12608: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12608 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12608/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 13:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 13:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGsJW-0002bA-Lz; Sun, 08 Apr 2012 13:37:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SGsJV-0002b5-4T
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 13:37:53 +0000
Received: from [85.158.143.35:22161] by server-3.bemta-4.messagelabs.com id
	AA/C4-05853-0B4918F4; Sun, 08 Apr 2012 13:37:52 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333892270!11616649!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5276 invoked from network); 8 Apr 2012 13:37:50 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 13:37:50 -0000
Received: by bkcjg9 with SMTP id jg9so3284679bkc.32
	for <xen-devel@lists.xen.org>; Sun, 08 Apr 2012 06:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AkFQEuQ3CEsD2cjJSuHr95Woj+jGp/f+2oIjgrGSs04=;
	b=v5XQrnpX5+gBpR2Rtuqa2MQQAq+BOTFrkKPzOXH1B4F4yPZVzcIx0IYg9BfHsYhU7E
	pY3VBQLeZAVR6gghQdEUdZxTeaQcge+ARR7BNx5rCHTruh7ibMlWMwMQoJQU00pXEjkv
	EEnMs8cLjA79PCoCd1N6wu35r1Oe7Cyne39IcoS5fzvratYa+HUYDm5pNoYIWZixBifF
	W4W+RjA2NtrPpELOh1c+ODZ5/g/Zu4fNydqj5qEBzrgjo3Bf09umJgRPyDXV5nZRa0Vn
	G1kRmGjY4wPR7gTpP7gg73tTagC2n5fzs1yDZXba0HYj1AIBz3zt4OVNTxb9JPv1cJ1k
	kaaQ==
MIME-Version: 1.0
Received: by 10.204.9.198 with SMTP id m6mr1706013bkm.38.1333892269643; Sun,
	08 Apr 2012 06:37:49 -0700 (PDT)
Received: by 10.204.155.145 with HTTP; Sun, 8 Apr 2012 06:37:49 -0700 (PDT)
In-Reply-To: <4F7B66A3.3080802@amd.com>
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
	<4F7B66A3.3080802@amd.com>
Date: Sun, 8 Apr 2012 15:37:49 +0200
Message-ID: <CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: wei.huang2@amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0185759653428181340=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0185759653428181340==
Content-Type: multipart/alternative; boundary=0015175d0334e6963a04bd2afe95

--0015175d0334e6963a04bd2afe95
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

just try to compile with xen unstable 4.2 repo from 8.april 2012

make --directory=3Darch/x86
OBJ_DIR=3D/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || ex=
it
1;
make[3]: Entering directory `/root/xen-unstable.hg/extras/mini-os/arch/x86'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/root/xen-unstable.hg/extras/mini-os/arch/x86'
ld -r -nostdlib
-L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
elf_x86_64
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86/x86_64.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os_app.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/blkfront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gntmap.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gnttab.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/hypervisor.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lock.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/main.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mm.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/netfront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/sched.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/ctype.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/math.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/printf.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/stack_chk_fail.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/string.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xmalloc.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/xenbus/xenbus.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/console.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xencons_ring.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xenbus.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwip.a
-L/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64  -lc
-o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
objcopy -w -G xenos_* -G _start
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
ld -nostdlib
-L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
elf_x86_64 -T arch/x86/minios-x86_64.lds
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o  -o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os
ld: warning: section `.bss' type changed to PROGBITS
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
`ati_hw_out':
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:82: undefined
reference to `ioperm'
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:84: undefined
reference to `ioperm'
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
`ati_hw_in':
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:72: undefined
reference to `ioperm'
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:74: undefined
reference to `ioperm'
make[2]: *** [/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os]
Error 1
make[2]: Leaving directory `/root/xen-unstable.hg/extras/mini-os'
make[1]: *** [ioemu-stubdom] Error 2
make[1]: Leaving directory `/root/xen-unstable.hg/stubdom'
make: *** [install-stubdom] Error 2

using linux kernel 3.3

nm /usr/lib/libc.a |grep -i ioperm
ioperm.o:
0000000000000000 T ioperm

Best Regards,
Kristijan Lecnik


On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang <wei.huang2@amd.com> wrote:

>  I just re-spin the patch, but haven't tested it yet. You want to try it
> (attached)? Make sure you are using AMD GPU as the primary.
>
> -Wei
>
>
>
> On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
>
> Hi,
>
>  i am trying to apply AMD/ATI patch on xen4-2 unstable
>
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN=
3jloS.txt
>
>  and there was some changes in code and the patch is unusable, is there a
> new patch. or can somebody help me to update the patch?
>
>  make[4]: Entering directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
>   CC    i386-dm/pt-graphics.o
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_register_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:373:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:374:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_unregister_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:396:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:397:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> make[4]: *** [pt-graphics.o] Error 1
> make[4]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
> make[3]: *** [subdir-i386-dm] Error 2
> make[3]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te'
> make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
> make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make: *** [install-tools] Error 2
>
>
> http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-=
pt-pci-host-read-write-td5016713.html
>
>  example:
>
>  old syle:
> vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);
>
>  new syle:
> vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
>
>  Best Regards,
> Kristijan Le=C4=8Dnik
>
>
>

--0015175d0334e6963a04bd2afe95
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>just try to compile with xen unstable 4.2 repo from =
8.april 2012</div><div><br></div><div><div>make --directory=3Darch/x86 OBJ_=
DIR=3D/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || exit 1=
;</div>
<div>make[3]: Entering directory `/root/xen-unstable.hg/extras/mini-os/arch=
/x86&#39;</div><div>make[3]: Nothing to be done for `all&#39;.</div><div>ma=
ke[3]: Leaving directory `/root/xen-unstable.hg/extras/mini-os/arch/x86&#39=
;</div>
<div>ld -r -nostdlib -L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_=
64-xen-elf/lib =C2=A0-m elf_x86_64 /root/xen-unstable.hg/stubdom/mini-os-x8=
6_64-ioemu/arch/x86/x86_64.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-i=
oemu/mini-os_app.o =C2=A0/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu=
/blkfront.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o /ro=
ot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o /root/xen-unstabl=
e.hg/stubdom/mini-os-x86_64-ioemu/gntmap.o /root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/gnttab.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-io=
emu/hypervisor.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.=
o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lock.o /root/xen-unsta=
ble.hg/stubdom/mini-os-x86_64-ioemu/main.o /root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/mm.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/=
netfront.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o /r=
oot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/sched.o /root/xen-unstable=
.hg/stubdom/mini-os-x86_64-ioemu/lib/ctype.o /root/xen-unstable.hg/stubdom/=
mini-os-x86_64-ioemu/lib/math.o /root/xen-unstable.hg/stubdom/mini-os-x86_6=
4-ioemu/lib/printf.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib=
/stack_chk_fail.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/st=
ring.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o /root/x=
en-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xmalloc.o /root/xen-unstabl=
e.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o /root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/xenbus/xenbus.o /root/xen-unstable.hg/stubdom/mini-os-x8=
6_64-ioemu/console/console.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-i=
oemu/console/xencons_ring.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-io=
emu/console/xenbus.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwi=
p.a -L/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64 =
=C2=A0-lc -o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o</=
div>
<div>objcopy -w -G xenos_* -G _start /root/xen-unstable.hg/stubdom/mini-os-=
x86_64-ioemu/mini-os.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/m=
ini-os.o</div><div>ld -nostdlib -L/root/xen-unstable.hg/stubdom/cross-root-=
x86_64/x86_64-xen-elf/lib =C2=A0-m elf_x86_64 -T arch/x86/minios-x86_64.lds=
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o =C2=A0-o /roo=
t/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os</div>
<div>ld: warning: section `.bss&#39; type changed to PROGBITS</div><div>/ro=
ot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function `ati=
_hw_out&#39;:</div><div>/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.=
c:82: undefined reference to `ioperm&#39;</div>
<div>/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:84: undefined ref=
erence to `ioperm&#39;</div><div>/root/xen-unstable.hg/stubdom/mini-os-x86_=
64-ioemu/mini-os.o: In function `ati_hw_in&#39;:</div><div>/root/xen-unstab=
le.hg/stubdom/ioemu/hw/pt-graphics.c:72: undefined reference to `ioperm&#39=
;</div>
<div>/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:74: undefined ref=
erence to `ioperm&#39;</div><div>make[2]: *** [/root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/mini-os] Error 1</div><div>make[2]: Leaving director=
y `/root/xen-unstable.hg/extras/mini-os&#39;</div>
<div>make[1]: *** [ioemu-stubdom] Error 2</div><div>make[1]: Leaving direct=
ory `/root/xen-unstable.hg/stubdom&#39;</div><div>make: *** [install-stubdo=
m] Error 2</div><div><br></div><div>using linux kernel 3.3</div><div><br>
</div><div><div>nm /usr/lib/libc.a |grep -i ioperm</div><div>ioperm.o:</div=
><div>0000000000000000 T ioperm</div><div><br></div><div>Best Regards,</div=
></div><div>Kristijan Lecnik</div><div><br></div><br><div class=3D"gmail_qu=
ote">
On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang <span dir=3D"ltr">&lt;<a href=3D=
"mailto:wei.huang2@amd.com">wei.huang2@amd.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    I just re-spin the patch, but haven&#39;t tested it yet. You want to tr=
y
    it (attached)? Make sure you are using AMD GPU as the primary.<span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br>
    <br>
    -Wei</font></span><div><div class=3D"h5"><br>
    <br>
    <br>
    On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
    <blockquote type=3D"cite">
     =20
      Hi,
      <div><br>
      </div>
      <div>i am trying to apply AMD/ATI patch on xen4-2 unstable</div>
      <div><a href=3D"http://old-list-archives.xen.org/archives/html/xen-de=
vel/2010-12/txtNwRlN3jloS.txt" target=3D"_blank">http://old-list-archives.x=
en.org/archives/html/xen-devel/2010-12/txtNwRlN3jloS.txt</a></div>
      <div><br>
      </div>
      <div>and there was some changes in code and the patch is unusable,
        is there a new patch. or can somebody help me to update the
        patch?</div>
      <div><br>
      </div>
      <div>
        <div>make[4]: Entering directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm&#39;</div>
        <div>=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_register_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:373:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:374:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_unregister_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:396:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:397:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>make[4]: *** [pt-graphics.o] Error 1</div>
        <div>make[4]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm&#39;</div>
        <div>make[3]: *** [subdir-i386-dm] Error 2</div>
        <div>make[3]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
&#39;</div>
        <div>make[2]: *** [subdir-install-qemu-xen-traditional-dir]
          Error 2</div>
        <div>make[2]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div>
        <div>make[1]: *** [subdirs-install] Error 2</div>
        <div>make[1]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div>
        <div>make: *** [install-tools] Error 2</div>
      </div>
      <div><br>
      </div>
      <div><a href=3D"http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-C=
hange-prototype-for-pt-pci-host-read-write-td5016713.html" target=3D"_blank=
">http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-=
pt-pci-host-read-write-td5016713.html</a></div>

      <div><br>
      </div>
      <div>example:</div>
      <div><br>
      </div>
      <div>old syle:</div>
      <div>vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);</div>
      <div><br>
      </div>
      <div>new syle:</div>
      <div>vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);</div>
      <div><br>
      </div>
      <div>Best Regards,</div>
      <div>Kristijan Le=C4=8Dnik</div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>

--0015175d0334e6963a04bd2afe95--


--===============0185759653428181340==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0185759653428181340==--


From xen-devel-bounces@lists.xen.org Sun Apr 08 13:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 13:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGsJW-0002bA-Lz; Sun, 08 Apr 2012 13:37:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SGsJV-0002b5-4T
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 13:37:53 +0000
Received: from [85.158.143.35:22161] by server-3.bemta-4.messagelabs.com id
	AA/C4-05853-0B4918F4; Sun, 08 Apr 2012 13:37:52 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333892270!11616649!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5276 invoked from network); 8 Apr 2012 13:37:50 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 13:37:50 -0000
Received: by bkcjg9 with SMTP id jg9so3284679bkc.32
	for <xen-devel@lists.xen.org>; Sun, 08 Apr 2012 06:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AkFQEuQ3CEsD2cjJSuHr95Woj+jGp/f+2oIjgrGSs04=;
	b=v5XQrnpX5+gBpR2Rtuqa2MQQAq+BOTFrkKPzOXH1B4F4yPZVzcIx0IYg9BfHsYhU7E
	pY3VBQLeZAVR6gghQdEUdZxTeaQcge+ARR7BNx5rCHTruh7ibMlWMwMQoJQU00pXEjkv
	EEnMs8cLjA79PCoCd1N6wu35r1Oe7Cyne39IcoS5fzvratYa+HUYDm5pNoYIWZixBifF
	W4W+RjA2NtrPpELOh1c+ODZ5/g/Zu4fNydqj5qEBzrgjo3Bf09umJgRPyDXV5nZRa0Vn
	G1kRmGjY4wPR7gTpP7gg73tTagC2n5fzs1yDZXba0HYj1AIBz3zt4OVNTxb9JPv1cJ1k
	kaaQ==
MIME-Version: 1.0
Received: by 10.204.9.198 with SMTP id m6mr1706013bkm.38.1333892269643; Sun,
	08 Apr 2012 06:37:49 -0700 (PDT)
Received: by 10.204.155.145 with HTTP; Sun, 8 Apr 2012 06:37:49 -0700 (PDT)
In-Reply-To: <4F7B66A3.3080802@amd.com>
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
	<4F7B66A3.3080802@amd.com>
Date: Sun, 8 Apr 2012 15:37:49 +0200
Message-ID: <CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: wei.huang2@amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0185759653428181340=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0185759653428181340==
Content-Type: multipart/alternative; boundary=0015175d0334e6963a04bd2afe95

--0015175d0334e6963a04bd2afe95
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

just try to compile with xen unstable 4.2 repo from 8.april 2012

make --directory=3Darch/x86
OBJ_DIR=3D/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || ex=
it
1;
make[3]: Entering directory `/root/xen-unstable.hg/extras/mini-os/arch/x86'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/root/xen-unstable.hg/extras/mini-os/arch/x86'
ld -r -nostdlib
-L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
elf_x86_64
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86/x86_64.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os_app.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/blkfront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gntmap.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gnttab.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/hypervisor.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lock.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/main.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mm.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/netfront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/sched.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/ctype.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/math.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/printf.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/stack_chk_fail.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/string.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xmalloc.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/xenbus/xenbus.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/console.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xencons_ring.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xenbus.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwip.a
-L/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64  -lc
-o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
objcopy -w -G xenos_* -G _start
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
ld -nostdlib
-L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
elf_x86_64 -T arch/x86/minios-x86_64.lds
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o  -o
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os
ld: warning: section `.bss' type changed to PROGBITS
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
`ati_hw_out':
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:82: undefined
reference to `ioperm'
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:84: undefined
reference to `ioperm'
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
`ati_hw_in':
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:72: undefined
reference to `ioperm'
/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:74: undefined
reference to `ioperm'
make[2]: *** [/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os]
Error 1
make[2]: Leaving directory `/root/xen-unstable.hg/extras/mini-os'
make[1]: *** [ioemu-stubdom] Error 2
make[1]: Leaving directory `/root/xen-unstable.hg/stubdom'
make: *** [install-stubdom] Error 2

using linux kernel 3.3

nm /usr/lib/libc.a |grep -i ioperm
ioperm.o:
0000000000000000 T ioperm

Best Regards,
Kristijan Lecnik


On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang <wei.huang2@amd.com> wrote:

>  I just re-spin the patch, but haven't tested it yet. You want to try it
> (attached)? Make sure you are using AMD GPU as the primary.
>
> -Wei
>
>
>
> On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
>
> Hi,
>
>  i am trying to apply AMD/ATI patch on xen4-2 unstable
>
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN=
3jloS.txt
>
>  and there was some changes in code and the patch is unusable, is there a
> new patch. or can somebody help me to update the patch?
>
>  make[4]: Entering directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
>   CC    i386-dm/pt-graphics.o
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_register_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:373:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:374:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_unregister_vga_regions=E2=80=99:
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:396:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:397:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99
> make[4]: *** [pt-graphics.o] Error 1
> make[4]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
> make[3]: *** [subdir-i386-dm] Error 2
> make[3]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te'
> make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
> make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'
> make: *** [install-tools] Error 2
>
>
> http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-=
pt-pci-host-read-write-td5016713.html
>
>  example:
>
>  old syle:
> vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);
>
>  new syle:
> vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
>
>  Best Regards,
> Kristijan Le=C4=8Dnik
>
>
>

--0015175d0334e6963a04bd2afe95
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>just try to compile with xen unstable 4.2 repo from =
8.april 2012</div><div><br></div><div><div>make --directory=3Darch/x86 OBJ_=
DIR=3D/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || exit 1=
;</div>
<div>make[3]: Entering directory `/root/xen-unstable.hg/extras/mini-os/arch=
/x86&#39;</div><div>make[3]: Nothing to be done for `all&#39;.</div><div>ma=
ke[3]: Leaving directory `/root/xen-unstable.hg/extras/mini-os/arch/x86&#39=
;</div>
<div>ld -r -nostdlib -L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_=
64-xen-elf/lib =C2=A0-m elf_x86_64 /root/xen-unstable.hg/stubdom/mini-os-x8=
6_64-ioemu/arch/x86/x86_64.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-i=
oemu/mini-os_app.o =C2=A0/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu=
/blkfront.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o /ro=
ot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o /root/xen-unstabl=
e.hg/stubdom/mini-os-x86_64-ioemu/gntmap.o /root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/gnttab.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-io=
emu/hypervisor.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.=
o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lock.o /root/xen-unsta=
ble.hg/stubdom/mini-os-x86_64-ioemu/main.o /root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/mm.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/=
netfront.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o /r=
oot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/sched.o /root/xen-unstable=
.hg/stubdom/mini-os-x86_64-ioemu/lib/ctype.o /root/xen-unstable.hg/stubdom/=
mini-os-x86_64-ioemu/lib/math.o /root/xen-unstable.hg/stubdom/mini-os-x86_6=
4-ioemu/lib/printf.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib=
/stack_chk_fail.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/st=
ring.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o /root/x=
en-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xmalloc.o /root/xen-unstabl=
e.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o /root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/xenbus/xenbus.o /root/xen-unstable.hg/stubdom/mini-os-x8=
6_64-ioemu/console/console.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-i=
oemu/console/xencons_ring.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-io=
emu/console/xenbus.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwi=
p.a -L/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64 =
=C2=A0-lc -o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o</=
div>
<div>objcopy -w -G xenos_* -G _start /root/xen-unstable.hg/stubdom/mini-os-=
x86_64-ioemu/mini-os.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/m=
ini-os.o</div><div>ld -nostdlib -L/root/xen-unstable.hg/stubdom/cross-root-=
x86_64/x86_64-xen-elf/lib =C2=A0-m elf_x86_64 -T arch/x86/minios-x86_64.lds=
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o =C2=A0-o /roo=
t/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os</div>
<div>ld: warning: section `.bss&#39; type changed to PROGBITS</div><div>/ro=
ot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function `ati=
_hw_out&#39;:</div><div>/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.=
c:82: undefined reference to `ioperm&#39;</div>
<div>/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:84: undefined ref=
erence to `ioperm&#39;</div><div>/root/xen-unstable.hg/stubdom/mini-os-x86_=
64-ioemu/mini-os.o: In function `ati_hw_in&#39;:</div><div>/root/xen-unstab=
le.hg/stubdom/ioemu/hw/pt-graphics.c:72: undefined reference to `ioperm&#39=
;</div>
<div>/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:74: undefined ref=
erence to `ioperm&#39;</div><div>make[2]: *** [/root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/mini-os] Error 1</div><div>make[2]: Leaving director=
y `/root/xen-unstable.hg/extras/mini-os&#39;</div>
<div>make[1]: *** [ioemu-stubdom] Error 2</div><div>make[1]: Leaving direct=
ory `/root/xen-unstable.hg/stubdom&#39;</div><div>make: *** [install-stubdo=
m] Error 2</div><div><br></div><div>using linux kernel 3.3</div><div><br>
</div><div><div>nm /usr/lib/libc.a |grep -i ioperm</div><div>ioperm.o:</div=
><div>0000000000000000 T ioperm</div><div><br></div><div>Best Regards,</div=
></div><div>Kristijan Lecnik</div><div><br></div><br><div class=3D"gmail_qu=
ote">
On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang <span dir=3D"ltr">&lt;<a href=3D=
"mailto:wei.huang2@amd.com">wei.huang2@amd.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    I just re-spin the patch, but haven&#39;t tested it yet. You want to tr=
y
    it (attached)? Make sure you are using AMD GPU as the primary.<span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br>
    <br>
    -Wei</font></span><div><div class=3D"h5"><br>
    <br>
    <br>
    On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote:
    <blockquote type=3D"cite">
     =20
      Hi,
      <div><br>
      </div>
      <div>i am trying to apply AMD/ATI patch on xen4-2 unstable</div>
      <div><a href=3D"http://old-list-archives.xen.org/archives/html/xen-de=
vel/2010-12/txtNwRlN3jloS.txt" target=3D"_blank">http://old-list-archives.x=
en.org/archives/html/xen-devel/2010-12/txtNwRlN3jloS.txt</a></div>
      <div><br>
      </div>
      <div>and there was some changes in code and the patch is unusable,
        is there a new patch. or can somebody help me to update the
        patch?</div>
      <div><br>
      </div>
      <div>
        <div>make[4]: Entering directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm&#39;</div>
        <div>=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_register_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:373:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:374:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:
          In function =E2=80=98igd_unregister_vga_regions=E2=80=99:</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:396:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditiona=
l-dir/hw/pt-graphics.c:397:
          error: too many arguments to function =E2=80=98pt_pci_host_read=
=E2=80=99</div>
        <div>make[4]: *** [pt-graphics.o] Error 1</div>
        <div>make[4]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
/i386-dm&#39;</div>
        <div>make[3]: *** [subdir-i386-dm] Error 2</div>
        <div>make[3]: Leaving directory
`/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remote=
&#39;</div>
        <div>make[2]: *** [subdir-install-qemu-xen-traditional-dir]
          Error 2</div>
        <div>make[2]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div>
        <div>make[1]: *** [subdirs-install] Error 2</div>
        <div>make[1]: Leaving directory
          `/root/xen-unstable.hg-IN_USE_PATCHED/tools&#39;</div>
        <div>make: *** [install-tools] Error 2</div>
      </div>
      <div><br>
      </div>
      <div><a href=3D"http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-C=
hange-prototype-for-pt-pci-host-read-write-td5016713.html" target=3D"_blank=
">http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-=
pt-pci-host-read-write-td5016713.html</a></div>

      <div><br>
      </div>
      <div>example:</div>
      <div><br>
      </div>
      <div>old syle:</div>
      <div>vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);</div>
      <div><br>
      </div>
      <div>new syle:</div>
      <div>vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);</div>
      <div><br>
      </div>
      <div>Best Regards,</div>
      <div>Kristijan Le=C4=8Dnik</div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>

--0015175d0334e6963a04bd2afe95--


--===============0185759653428181340==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0185759653428181340==--


From xen-devel-bounces@lists.xen.org Sun Apr 08 13:45:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 13:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGsQ8-0002kZ-HW; Sun, 08 Apr 2012 13:44:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SGsQ7-0002kT-Dr
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 13:44:43 +0000
Received: from [85.158.143.35:37566] by server-1.bemta-4.messagelabs.com id
	BA/95-20925-A46918F4; Sun, 08 Apr 2012 13:44:42 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333892681!11617115!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15232 invoked from network); 8 Apr 2012 13:44:41 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-21.messagelabs.com with SMTP;
	8 Apr 2012 13:44:41 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 0E4CED3474F;
	Sun,  8 Apr 2012 15:44:41 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id DWx3wEsVm8kP; Sun,  8 Apr 2012 15:44:38 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 491C5D3471B;
	Sun,  8 Apr 2012 15:44:38 +0200 (CEST)
Message-ID: <4F819645.4060404@vido.info>
Date: Sun, 08 Apr 2012 15:44:37 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <201109090950.05043.muehlenhoff@univention.de>
	<201109141814.29461.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B10AD86AC@BITCOM1.int.sbss.com.au>
	<201203270952.56490.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

I used "http://www.heise.de/download/as-ssd-benchmark.html" (sorry - 
german website), but i remember similar results with the famous "HD Tune 
Pro" tool...

Nowhere here DRBD is involved - sorry; the disk line refers to a phy lvm 
disk which is directly on a block device (ssd).

But i can test with debug build if you still think this (what?) is an 
issue here - tell me if you want to see that!

Greetings - and happy Easter!
Tobias

Am 06.04.2012 12:56, schrieb James Harper:
>> glad you ask - because just yesterday i re-tested the 357-version of the
>> drivers under Windows7 64bit HVM guest - here are the results:
>>
>> (everyting in mb/s)
>>
>> W/O gplpv-drivers and WITH pci-passthrough:
>>
>> Seq. reading: 311.8
>> Seq. writing:  106.3
>> 4k    reading: 10.2
>> 4k    writing:   9.3
>> 4k64thread reading: 11.1
>> 4k64threads writing: 10.9
>>
>>
>> WITH gplpv-drivers and WITH pci-passthrough:
>>
>> Seq. reading: 98.8
>> Seq. writing:  31.6
>> 4k    reading: 12.0
>> 4k    writing:  19.3
>> 4k64thread reading: 15.4
>> 4k64threads writing: 29.6
>>
>>
>> WITH gplpv-drivers and WITHOUT pci-passthrough:
>>
>> Seq. reading: 104.4
>> Seq. writing:   85.2
>> 4k    reading:  12.7
>> 4k    writing:   20.4
>> 4k64thread reading: 16.6
>> 4k64threads writing: 32.6
>>
>>
>> Strange thing is, that even without pci-passthrough the performance with
>> gplpv is'nt that much better compared to w/o gplpv but with pci-passthrough
>> - well it is overall a bit better, but just a bit, and seq. read performance is
>> much worse...
>> i haven't made a test without gplpv and without passthrough at the same
>> time - tell me if you want to see how that performs.
>>
>> Greetings!
>> Tobias
>>
>> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this tests.
>>
> What are you testing this with? I just ran some tests with iometer under 2008R2 and it reminded me of something... DRBD *hates* having outstanding writes to the same block, and complains about it, so gplpv serialises such requests (stalling the queue until the first request is complete). This almost never happens in production but iometer sends such requests frequently, which will significantly impact performance.
>
> You can test with the debug build to see if this is happening with whatever you are testing with - you'll see messages like "Concurrent outstanding write detected". Be aware though that qemu will rate limit writes to the debug log so if it happens a lot (like under iometer) it will slow to a crawl.
>
> James
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 13:45:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 13:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGsQ8-0002kZ-HW; Sun, 08 Apr 2012 13:44:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SGsQ7-0002kT-Dr
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 13:44:43 +0000
Received: from [85.158.143.35:37566] by server-1.bemta-4.messagelabs.com id
	BA/95-20925-A46918F4; Sun, 08 Apr 2012 13:44:42 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333892681!11617115!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15232 invoked from network); 8 Apr 2012 13:44:41 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-21.messagelabs.com with SMTP;
	8 Apr 2012 13:44:41 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 0E4CED3474F;
	Sun,  8 Apr 2012 15:44:41 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id DWx3wEsVm8kP; Sun,  8 Apr 2012 15:44:38 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 491C5D3471B;
	Sun,  8 Apr 2012 15:44:38 +0200 (CEST)
Message-ID: <4F819645.4060404@vido.info>
Date: Sun, 08 Apr 2012 15:44:37 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <201109090950.05043.muehlenhoff@univention.de>
	<201109141814.29461.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B10AD86AC@BITCOM1.int.sbss.com.au>
	<201203270952.56490.tobias.geiger@vido.info>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

I used "http://www.heise.de/download/as-ssd-benchmark.html" (sorry - 
german website), but i remember similar results with the famous "HD Tune 
Pro" tool...

Nowhere here DRBD is involved - sorry; the disk line refers to a phy lvm 
disk which is directly on a block device (ssd).

But i can test with debug build if you still think this (what?) is an 
issue here - tell me if you want to see that!

Greetings - and happy Easter!
Tobias

Am 06.04.2012 12:56, schrieb James Harper:
>> glad you ask - because just yesterday i re-tested the 357-version of the
>> drivers under Windows7 64bit HVM guest - here are the results:
>>
>> (everyting in mb/s)
>>
>> W/O gplpv-drivers and WITH pci-passthrough:
>>
>> Seq. reading: 311.8
>> Seq. writing:  106.3
>> 4k    reading: 10.2
>> 4k    writing:   9.3
>> 4k64thread reading: 11.1
>> 4k64threads writing: 10.9
>>
>>
>> WITH gplpv-drivers and WITH pci-passthrough:
>>
>> Seq. reading: 98.8
>> Seq. writing:  31.6
>> 4k    reading: 12.0
>> 4k    writing:  19.3
>> 4k64thread reading: 15.4
>> 4k64threads writing: 29.6
>>
>>
>> WITH gplpv-drivers and WITHOUT pci-passthrough:
>>
>> Seq. reading: 104.4
>> Seq. writing:   85.2
>> 4k    reading:  12.7
>> 4k    writing:   20.4
>> 4k64thread reading: 16.6
>> 4k64threads writing: 32.6
>>
>>
>> Strange thing is, that even without pci-passthrough the performance with
>> gplpv is'nt that much better compared to w/o gplpv but with pci-passthrough
>> - well it is overall a bit better, but just a bit, and seq. read performance is
>> much worse...
>> i haven't made a test without gplpv and without passthrough at the same
>> time - tell me if you want to see how that performs.
>>
>> Greetings!
>> Tobias
>>
>> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this tests.
>>
> What are you testing this with? I just ran some tests with iometer under 2008R2 and it reminded me of something... DRBD *hates* having outstanding writes to the same block, and complains about it, so gplpv serialises such requests (stalling the queue until the first request is complete). This almost never happens in production but iometer sends such requests frequently, which will significantly impact performance.
>
> You can test with the debug build to see if this is happening with whatever you are testing with - you'll see messages like "Concurrent outstanding write detected". Be aware though that qemu will rate limit writes to the debug log so if it happens a lot (like under iometer) it will slow to a crawl.
>
> James
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 14:01:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 14:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGsgF-0003Ki-Tl; Sun, 08 Apr 2012 14:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1SGsgE-0003Kd-1O
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 14:01:22 +0000
Received: from [85.158.139.83:16362] by server-12.bemta-5.messagelabs.com id
	71/E5-05587-13A918F4; Sun, 08 Apr 2012 14:01:21 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333893680!18326533!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18231 invoked from network); 8 Apr 2012 14:01:20 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-11.tower-182.messagelabs.com with SMTP;
	8 Apr 2012 14:01:20 -0000
Received: (qmail 8133 invoked from network); 8 Apr 2012 16:01:18 +0200
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,
	URI_HEX,USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	8 Apr 2012 16:01:18 +0200
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xen.org
Date: Sun, 8 Apr 2012 16:01:17 +0200
User-Agent: KMail/1.13.7 (Linux/3.3.0; KDE/4.7.4; x86_64; ; )
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
	<4F7B66A3.3080802@amd.com>
	<CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
In-Reply-To: <CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <201204081601.17963.pavel@netsafe.cz>
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuIDguIG9mIEFwcmlsIDIwMTIgMTU6Mzc6NDkgS3Jpc3RpamFuIExlxI1uaWsgd3JvdGU6
Cj4gSGksCj4gCj4ganVzdCB0cnkgdG8gY29tcGlsZSB3aXRoIHhlbiB1bnN0YWJsZSA0LjIgcmVw
byBmcm9tIDguYXByaWwgMjAxMgo+IAo+IG1ha2UgLS1kaXJlY3Rvcnk9YXJjaC94ODYKPiBPQkpf
RElSPS9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2Fy
Y2gveDg2IHx8IGV4aXQKPiAxOwo+IG1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Jvb3Qv
eGVuLXVuc3RhYmxlLmhnL2V4dHJhcy9taW5pLW9zL2FyY2gveDg2Jwo+IG1ha2VbM106IE5vdGhp
bmcgdG8gYmUgZG9uZSBmb3IgYGFsbCcuCj4gbWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC9y
b290L3hlbi11bnN0YWJsZS5oZy9leHRyYXMvbWluaS1vcy9hcmNoL3g4NicKPiBsZCAtciAtbm9z
dGRsaWIKPiAtTC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL2Nyb3NzLXJvb3QteDg2XzY0
L3g4Nl82NC14ZW4tZWxmL2xpYiAgLW0KPiBlbGZfeDg2XzY0Cj4gL3Jvb3QveGVuLXVuc3RhYmxl
LmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvYXJjaC94ODYveDg2XzY0Lm8KPiAvcm9v
dC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9taW5pLW9zX2Fw
cC5vCj4gIC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11
L2Jsa2Zyb250Lm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82
NC1pb2VtdS9ldmVudHMubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3Mt
eDg2XzY0LWlvZW11L2ZiZnJvbnQubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21p
bmktb3MteDg2XzY0LWlvZW11L2dudG1hcC5vCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJk
b20vbWluaS1vcy14ODZfNjQtaW9lbXUvZ250dGFiLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcv
c3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9oeXBlcnZpc29yLm8KPiAvcm9vdC94ZW4tdW5z
dGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9rZXJuZWwubwo+IC9yb290L3hl
bi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2xvY2subwo+IC9yb290
L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L21haW4ubwo+IC9y
b290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L21tLm8KPiAv
cm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9uZXRmcm9u
dC5vCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUv
cGNpZnJvbnQubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0
LWlvZW11L3NjaGVkLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4
Nl82NC1pb2VtdS9saWIvY3R5cGUubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21p
bmktb3MteDg2XzY0LWlvZW11L2xpYi9tYXRoLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1
YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9saWIvcHJpbnRmLm8KPiAvcm9vdC94ZW4tdW5zdGFi
bGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9saWIvc3RhY2tfY2hrX2ZhaWwubwo+
IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2xpYi9z
dHJpbmcubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlv
ZW11L2xpYi9zeXMubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2
XzY0LWlvZW11L2xpYi94bWFsbG9jLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9t
aW5pLW9zLXg4Nl82NC1pb2VtdS9saWIveHMubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHVi
ZG9tL21pbmktb3MteDg2XzY0LWlvZW11L3hlbmJ1cy94ZW5idXMubwo+IC9yb290L3hlbi11bnN0
YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2NvbnNvbGUvY29uc29sZS5vCj4g
L3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvY29uc29s
ZS94ZW5jb25zX3Jpbmcubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3Mt
eDg2XzY0LWlvZW11L2NvbnNvbGUveGVuYnVzLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1
YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9sd2lwLmEKPiAtTC9yb290L3hlbi11bnN0YWJsZS5o
Zy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2FyY2gveDg2IC1seDg2XzY0ICAtbGMKPiAt
byAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9taW5p
LW9zLm8KPiBvYmpjb3B5IC13IC1HIHhlbm9zXyogLUcgX3N0YXJ0Cj4gL3Jvb3QveGVuLXVuc3Rh
YmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvbWluaS1vcy5vCj4gL3Jvb3QveGVu
LXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvbWluaS1vcy5vCj4gbGQg
LW5vc3RkbGliCj4gLUwvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9jcm9zcy1yb290LXg4
Nl82NC94ODZfNjQteGVuLWVsZi9saWIgIC1tCj4gZWxmX3g4Nl82NCAtVCBhcmNoL3g4Ni9taW5p
b3MteDg2XzY0Lmxkcwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2
XzY0LWlvZW11L21pbmktb3MubyAgLW8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9t
aW5pLW9zLXg4Nl82NC1pb2VtdS9taW5pLW9zCj4gbGQ6IHdhcm5pbmc6IHNlY3Rpb24gYC5ic3Mn
IHR5cGUgY2hhbmdlZCB0byBQUk9HQklUUwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9t
L21pbmktb3MteDg2XzY0LWlvZW11L21pbmktb3MubzogSW4gZnVuY3Rpb24KPiBgYXRpX2h3X291
dCc6Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vaW9lbXUvaHcvcHQtZ3JhcGhpY3Mu
Yzo4MjogdW5kZWZpbmVkCj4gcmVmZXJlbmNlIHRvIGBpb3Blcm0nCj4gL3Jvb3QveGVuLXVuc3Rh
YmxlLmhnL3N0dWJkb20vaW9lbXUvaHcvcHQtZ3JhcGhpY3MuYzo4NDogdW5kZWZpbmVkCj4gcmVm
ZXJlbmNlIHRvIGBpb3Blcm0nCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1v
cy14ODZfNjQtaW9lbXUvbWluaS1vcy5vOiBJbiBmdW5jdGlvbgo+IGBhdGlfaHdfaW4nOgo+IC9y
b290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL2lvZW11L2h3L3B0LWdyYXBoaWNzLmM6NzI6IHVu
ZGVmaW5lZAo+IHJlZmVyZW5jZSB0byBgaW9wZXJtJwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9z
dHViZG9tL2lvZW11L2h3L3B0LWdyYXBoaWNzLmM6NzQ6IHVuZGVmaW5lZAo+IHJlZmVyZW5jZSB0
byBgaW9wZXJtJwo+IG1ha2VbMl06ICoqKiBbL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20v
bWluaS1vcy14ODZfNjQtaW9lbXUvbWluaS1vc10KPiBFcnJvciAxCj4gbWFrZVsyXTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9yb290L3hlbi11bnN0YWJsZS5oZy9leHRyYXMvbWluaS1vcycKPiBtYWtl
WzFdOiAqKiogW2lvZW11LXN0dWJkb21dIEVycm9yIDIKPiBtYWtlWzFdOiBMZWF2aW5nIGRpcmVj
dG9yeSBgL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20nCj4gbWFrZTogKioqIFtpbnN0YWxs
LXN0dWJkb21dIEVycm9yIDIKPiAKPiB1c2luZyBsaW51eCBrZXJuZWwgMy4zCj4gCj4gbm0gL3Vz
ci9saWIvbGliYy5hIHxncmVwIC1pIGlvcGVybQo+IGlvcGVybS5vOgo+IDAwMDAwMDAwMDAwMDAw
MDAgVCBpb3Blcm0KPiAKPiBCZXN0IFJlZ2FyZHMsCj4gS3Jpc3RpamFuIExlY25pawo+IAo+IE9u
IFR1ZSwgQXByIDMsIDIwMTIgYXQgMTE6MDcgUE0sIFdlaSBIdWFuZyA8d2VpLmh1YW5nMkBhbWQu
Y29tPiB3cm90ZToKPiA+ICBJIGp1c3QgcmUtc3BpbiB0aGUgcGF0Y2gsIGJ1dCBoYXZlbid0IHRl
c3RlZCBpdCB5ZXQuIFlvdSB3YW50IHRvIHRyeSBpdAo+ID4gCj4gPiAoYXR0YWNoZWQpPyBNYWtl
IHN1cmUgeW91IGFyZSB1c2luZyBBTUQgR1BVIGFzIHRoZSBwcmltYXJ5Lgo+ID4gCj4gPiAtV2Vp
Cj4gPiAKPiA+IAo+ID4gCj4gPiBPbiAwNC8wMS8yMDEyIDA4OjAzIFBNLCBLcmlzdGlqYW4gTGXE
jW5payB3cm90ZToKPiA+IAo+ID4gSGksCj4gPiAKPiA+ICBpIGFtIHRyeWluZyB0byBhcHBseSBB
TUQvQVRJIHBhdGNoIG9uIHhlbjQtMiB1bnN0YWJsZQo+ID4gCj4gPiBodHRwOi8vb2xkLWxpc3Qt
YXJjaGl2ZXMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEwLTEyL3R4dE53UmxO
Cj4gPiAzamxvUy50eHQKPiA+IAo+ID4gIGFuZCB0aGVyZSB3YXMgc29tZSBjaGFuZ2VzIGluIGNv
ZGUgYW5kIHRoZSBwYXRjaCBpcyB1bnVzYWJsZSwgaXMgdGhlcmUgYQo+ID4gCj4gPiBuZXcgcGF0
Y2guIG9yIGNhbiBzb21lYm9keSBoZWxwIG1lIHRvIHVwZGF0ZSB0aGUgcGF0Y2g/Cj4gPiAKPiA+
ICBtYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkKPiA+IAo+ID4gYC9yb290L3hlbi11bnN0YWJs
ZS5oZy1JTl9VU0VfUEFUQ0hFRC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtbwo+
ID4gdGUvaTM4Ni1kbScKPiA+IAo+ID4gICBDQyAgICBpMzg2LWRtL3B0LWdyYXBoaWNzLm8KPiA+
IAo+ID4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VTRV9QQVRDSEVEL3Rvb2xzL3FlbXUteGVu
LXRyYWRpdGlvbmFsLWRpci9ody9wdAo+ID4gLWdyYXBoaWNzLmM6IEluIGZ1bmN0aW9uIOKAmGln
ZF9yZWdpc3Rlcl92Z2FfcmVnaW9uc+KAmToKPiA+IC9yb290L3hlbi11bnN0YWJsZS5oZy1JTl9V
U0VfUEFUQ0hFRC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcHQKPiA+IC1ncmFw
aGljcy5jOjM3MzogZXJyb3I6IHRvbyBtYW55IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDigJhwdF9w
Y2lfaG9zdF9yZWFk4oCZCj4gPiAvcm9vdC94ZW4tdW5zdGFibGUuaGctSU5fVVNFX1BBVENIRUQv
dG9vbHMvcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyL2h3L3B0Cj4gPiAtZ3JhcGhpY3MuYzozNzQ6
IGVycm9yOiB0b28gbWFueSBhcmd1bWVudHMgdG8gZnVuY3Rpb24g4oCYcHRfcGNpX2hvc3RfcmVh
ZOKAmQo+ID4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VTRV9QQVRDSEVEL3Rvb2xzL3FlbXUt
eGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdAo+ID4gLWdyYXBoaWNzLmM6IEluIGZ1bmN0aW9uIOKA
mGlnZF91bnJlZ2lzdGVyX3ZnYV9yZWdpb25z4oCZOgo+ID4gL3Jvb3QveGVuLXVuc3RhYmxlLmhn
LUlOX1VTRV9QQVRDSEVEL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdAo+ID4g
LWdyYXBoaWNzLmM6Mzk2OiBlcnJvcjogdG9vIG1hbnkgYXJndW1lbnRzIHRvIGZ1bmN0aW9uIOKA
mHB0X3BjaV9ob3N0X3JlYWTigJkKPiA+IC9yb290L3hlbi11bnN0YWJsZS5oZy1JTl9VU0VfUEFU
Q0hFRC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcHQKPiA+IC1ncmFwaGljcy5j
OjM5NzogZXJyb3I6IHRvbyBtYW55IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDigJhwdF9wY2lfaG9z
dF9yZWFk4oCZCj4gPiBtYWtlWzRdOiAqKiogW3B0LWdyYXBoaWNzLm9dIEVycm9yIDEKPiA+IG1h
a2VbNF06IExlYXZpbmcgZGlyZWN0b3J5Cj4gPiBgL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VT
RV9QQVRDSEVEL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci1yZW1vCj4gPiB0ZS9pMzg2
LWRtJyBtYWtlWzNdOiAqKiogW3N1YmRpci1pMzg2LWRtXSBFcnJvciAyCj4gPiBtYWtlWzNdOiBM
ZWF2aW5nIGRpcmVjdG9yeQo+ID4gYC9yb290L3hlbi11bnN0YWJsZS5oZy1JTl9VU0VfUEFUQ0hF
RC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtbwo+ID4gdGUnIG1ha2VbMl06ICoq
KiBbc3ViZGlyLWluc3RhbGwtcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyXSBFcnJvciAyCj4gPiBt
YWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VTRV9Q
QVRDSEVEL3Rvb2xzJwo+ID4gbWFrZVsxXTogKioqIFtzdWJkaXJzLWluc3RhbGxdIEVycm9yIDIK
PiA+IG1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4tdW5zdGFibGUuaGctSU5f
VVNFX1BBVENIRUQvdG9vbHMnCj4gPiBtYWtlOiAqKiogW2luc3RhbGwtdG9vbHNdIEVycm9yIDIK
PiA+IAo+ID4gCj4gPiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9QQVRDSC0xLTMt
cWVtdS14ZW4tQ2hhbmdlLXByb3RvdHlwZS1mb3ItCj4gPiBwdC1wY2ktaG9zdC1yZWFkLXdyaXRl
LXRkNTAxNjcxMy5odG1sCj4gPiAKPiA+ICBleGFtcGxlOgo+ID4gCj4gPiAgb2xkIHN5bGU6Cj4g
PiB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKDAsIDIsIDAsIDAsIDIpOwo+ID4gCj4gPiAg
bmV3IHN5bGU6Cj4gPiB2aWQgPSBwdF9wY2lfaG9zdF9yZWFkKHBjaV9kZXZfMWYsIFBDSV9WRU5E
T1JfSUQsIDIpOwo+ID4gCj4gPiAgQmVzdCBSZWdhcmRzLAo+ID4gCj4gPiBLcmlzdGlqYW4gTGXE
jW5pawoKSGksCnN0aWxsIHRoZSBzYW1lIHN0b3J5Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hp
dmVzL2h0bWwveGVuLWRldmVsLzIwMTEtMDUvbXNnMDE3MzQuaHRtbAoKQnV0IGFsbCBteSByZWNl
bnQgYXR0ZW1wdHMgZmFpbGVkIGFueXdheS4gTXkgbGFzdCB3b3JraW5nIHNldHVwIGlzIHdpdGgg
b2xkIAoyLjYuMzIueCBrZXJuZWwuCi0tIApQYXZlbCBNYXRlamEKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Apr 08 14:01:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 14:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGsgF-0003Ki-Tl; Sun, 08 Apr 2012 14:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1SGsgE-0003Kd-1O
	for xen-devel@lists.xen.org; Sun, 08 Apr 2012 14:01:22 +0000
Received: from [85.158.139.83:16362] by server-12.bemta-5.messagelabs.com id
	71/E5-05587-13A918F4; Sun, 08 Apr 2012 14:01:21 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-11.tower-182.messagelabs.com!1333893680!18326533!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18231 invoked from network); 8 Apr 2012 14:01:20 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-11.tower-182.messagelabs.com with SMTP;
	8 Apr 2012 14:01:20 -0000
Received: (qmail 8133 invoked from network); 8 Apr 2012 16:01:18 +0200
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,
	URI_HEX,USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	8 Apr 2012 16:01:18 +0200
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xen.org
Date: Sun, 8 Apr 2012 16:01:17 +0200
User-Agent: KMail/1.13.7 (Linux/3.3.0; KDE/4.7.4; x86_64; ; )
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
	<4F7B66A3.3080802@amd.com>
	<CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
In-Reply-To: <CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <201204081601.17963.pavel@netsafe.cz>
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuIDguIG9mIEFwcmlsIDIwMTIgMTU6Mzc6NDkgS3Jpc3RpamFuIExlxI1uaWsgd3JvdGU6
Cj4gSGksCj4gCj4ganVzdCB0cnkgdG8gY29tcGlsZSB3aXRoIHhlbiB1bnN0YWJsZSA0LjIgcmVw
byBmcm9tIDguYXByaWwgMjAxMgo+IAo+IG1ha2UgLS1kaXJlY3Rvcnk9YXJjaC94ODYKPiBPQkpf
RElSPS9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2Fy
Y2gveDg2IHx8IGV4aXQKPiAxOwo+IG1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Jvb3Qv
eGVuLXVuc3RhYmxlLmhnL2V4dHJhcy9taW5pLW9zL2FyY2gveDg2Jwo+IG1ha2VbM106IE5vdGhp
bmcgdG8gYmUgZG9uZSBmb3IgYGFsbCcuCj4gbWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC9y
b290L3hlbi11bnN0YWJsZS5oZy9leHRyYXMvbWluaS1vcy9hcmNoL3g4NicKPiBsZCAtciAtbm9z
dGRsaWIKPiAtTC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL2Nyb3NzLXJvb3QteDg2XzY0
L3g4Nl82NC14ZW4tZWxmL2xpYiAgLW0KPiBlbGZfeDg2XzY0Cj4gL3Jvb3QveGVuLXVuc3RhYmxl
LmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvYXJjaC94ODYveDg2XzY0Lm8KPiAvcm9v
dC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9taW5pLW9zX2Fw
cC5vCj4gIC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11
L2Jsa2Zyb250Lm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82
NC1pb2VtdS9ldmVudHMubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3Mt
eDg2XzY0LWlvZW11L2ZiZnJvbnQubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21p
bmktb3MteDg2XzY0LWlvZW11L2dudG1hcC5vCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJk
b20vbWluaS1vcy14ODZfNjQtaW9lbXUvZ250dGFiLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcv
c3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9oeXBlcnZpc29yLm8KPiAvcm9vdC94ZW4tdW5z
dGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9rZXJuZWwubwo+IC9yb290L3hl
bi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2xvY2subwo+IC9yb290
L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L21haW4ubwo+IC9y
b290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L21tLm8KPiAv
cm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9uZXRmcm9u
dC5vCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUv
cGNpZnJvbnQubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0
LWlvZW11L3NjaGVkLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4
Nl82NC1pb2VtdS9saWIvY3R5cGUubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21p
bmktb3MteDg2XzY0LWlvZW11L2xpYi9tYXRoLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1
YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9saWIvcHJpbnRmLm8KPiAvcm9vdC94ZW4tdW5zdGFi
bGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9saWIvc3RhY2tfY2hrX2ZhaWwubwo+
IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2xpYi9z
dHJpbmcubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlv
ZW11L2xpYi9zeXMubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2
XzY0LWlvZW11L2xpYi94bWFsbG9jLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9t
aW5pLW9zLXg4Nl82NC1pb2VtdS9saWIveHMubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHVi
ZG9tL21pbmktb3MteDg2XzY0LWlvZW11L3hlbmJ1cy94ZW5idXMubwo+IC9yb290L3hlbi11bnN0
YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2NvbnNvbGUvY29uc29sZS5vCj4g
L3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvY29uc29s
ZS94ZW5jb25zX3Jpbmcubwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3Mt
eDg2XzY0LWlvZW11L2NvbnNvbGUveGVuYnVzLm8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1
YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9sd2lwLmEKPiAtTC9yb290L3hlbi11bnN0YWJsZS5o
Zy9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2FyY2gveDg2IC1seDg2XzY0ICAtbGMKPiAt
byAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9taW5pLW9zLXg4Nl82NC1pb2VtdS9taW5p
LW9zLm8KPiBvYmpjb3B5IC13IC1HIHhlbm9zXyogLUcgX3N0YXJ0Cj4gL3Jvb3QveGVuLXVuc3Rh
YmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvbWluaS1vcy5vCj4gL3Jvb3QveGVu
LXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvbWluaS1vcy5vCj4gbGQg
LW5vc3RkbGliCj4gLUwvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9jcm9zcy1yb290LXg4
Nl82NC94ODZfNjQteGVuLWVsZi9saWIgIC1tCj4gZWxmX3g4Nl82NCAtVCBhcmNoL3g4Ni9taW5p
b3MteDg2XzY0Lmxkcwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL21pbmktb3MteDg2
XzY0LWlvZW11L21pbmktb3MubyAgLW8KPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvc3R1YmRvbS9t
aW5pLW9zLXg4Nl82NC1pb2VtdS9taW5pLW9zCj4gbGQ6IHdhcm5pbmc6IHNlY3Rpb24gYC5ic3Mn
IHR5cGUgY2hhbmdlZCB0byBQUk9HQklUUwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9t
L21pbmktb3MteDg2XzY0LWlvZW11L21pbmktb3MubzogSW4gZnVuY3Rpb24KPiBgYXRpX2h3X291
dCc6Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vaW9lbXUvaHcvcHQtZ3JhcGhpY3Mu
Yzo4MjogdW5kZWZpbmVkCj4gcmVmZXJlbmNlIHRvIGBpb3Blcm0nCj4gL3Jvb3QveGVuLXVuc3Rh
YmxlLmhnL3N0dWJkb20vaW9lbXUvaHcvcHQtZ3JhcGhpY3MuYzo4NDogdW5kZWZpbmVkCj4gcmVm
ZXJlbmNlIHRvIGBpb3Blcm0nCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20vbWluaS1v
cy14ODZfNjQtaW9lbXUvbWluaS1vcy5vOiBJbiBmdW5jdGlvbgo+IGBhdGlfaHdfaW4nOgo+IC9y
b290L3hlbi11bnN0YWJsZS5oZy9zdHViZG9tL2lvZW11L2h3L3B0LWdyYXBoaWNzLmM6NzI6IHVu
ZGVmaW5lZAo+IHJlZmVyZW5jZSB0byBgaW9wZXJtJwo+IC9yb290L3hlbi11bnN0YWJsZS5oZy9z
dHViZG9tL2lvZW11L2h3L3B0LWdyYXBoaWNzLmM6NzQ6IHVuZGVmaW5lZAo+IHJlZmVyZW5jZSB0
byBgaW9wZXJtJwo+IG1ha2VbMl06ICoqKiBbL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20v
bWluaS1vcy14ODZfNjQtaW9lbXUvbWluaS1vc10KPiBFcnJvciAxCj4gbWFrZVsyXTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9yb290L3hlbi11bnN0YWJsZS5oZy9leHRyYXMvbWluaS1vcycKPiBtYWtl
WzFdOiAqKiogW2lvZW11LXN0dWJkb21dIEVycm9yIDIKPiBtYWtlWzFdOiBMZWF2aW5nIGRpcmVj
dG9yeSBgL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3N0dWJkb20nCj4gbWFrZTogKioqIFtpbnN0YWxs
LXN0dWJkb21dIEVycm9yIDIKPiAKPiB1c2luZyBsaW51eCBrZXJuZWwgMy4zCj4gCj4gbm0gL3Vz
ci9saWIvbGliYy5hIHxncmVwIC1pIGlvcGVybQo+IGlvcGVybS5vOgo+IDAwMDAwMDAwMDAwMDAw
MDAgVCBpb3Blcm0KPiAKPiBCZXN0IFJlZ2FyZHMsCj4gS3Jpc3RpamFuIExlY25pawo+IAo+IE9u
IFR1ZSwgQXByIDMsIDIwMTIgYXQgMTE6MDcgUE0sIFdlaSBIdWFuZyA8d2VpLmh1YW5nMkBhbWQu
Y29tPiB3cm90ZToKPiA+ICBJIGp1c3QgcmUtc3BpbiB0aGUgcGF0Y2gsIGJ1dCBoYXZlbid0IHRl
c3RlZCBpdCB5ZXQuIFlvdSB3YW50IHRvIHRyeSBpdAo+ID4gCj4gPiAoYXR0YWNoZWQpPyBNYWtl
IHN1cmUgeW91IGFyZSB1c2luZyBBTUQgR1BVIGFzIHRoZSBwcmltYXJ5Lgo+ID4gCj4gPiAtV2Vp
Cj4gPiAKPiA+IAo+ID4gCj4gPiBPbiAwNC8wMS8yMDEyIDA4OjAzIFBNLCBLcmlzdGlqYW4gTGXE
jW5payB3cm90ZToKPiA+IAo+ID4gSGksCj4gPiAKPiA+ICBpIGFtIHRyeWluZyB0byBhcHBseSBB
TUQvQVRJIHBhdGNoIG9uIHhlbjQtMiB1bnN0YWJsZQo+ID4gCj4gPiBodHRwOi8vb2xkLWxpc3Qt
YXJjaGl2ZXMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEwLTEyL3R4dE53UmxO
Cj4gPiAzamxvUy50eHQKPiA+IAo+ID4gIGFuZCB0aGVyZSB3YXMgc29tZSBjaGFuZ2VzIGluIGNv
ZGUgYW5kIHRoZSBwYXRjaCBpcyB1bnVzYWJsZSwgaXMgdGhlcmUgYQo+ID4gCj4gPiBuZXcgcGF0
Y2guIG9yIGNhbiBzb21lYm9keSBoZWxwIG1lIHRvIHVwZGF0ZSB0aGUgcGF0Y2g/Cj4gPiAKPiA+
ICBtYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkKPiA+IAo+ID4gYC9yb290L3hlbi11bnN0YWJs
ZS5oZy1JTl9VU0VfUEFUQ0hFRC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtbwo+
ID4gdGUvaTM4Ni1kbScKPiA+IAo+ID4gICBDQyAgICBpMzg2LWRtL3B0LWdyYXBoaWNzLm8KPiA+
IAo+ID4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VTRV9QQVRDSEVEL3Rvb2xzL3FlbXUteGVu
LXRyYWRpdGlvbmFsLWRpci9ody9wdAo+ID4gLWdyYXBoaWNzLmM6IEluIGZ1bmN0aW9uIOKAmGln
ZF9yZWdpc3Rlcl92Z2FfcmVnaW9uc+KAmToKPiA+IC9yb290L3hlbi11bnN0YWJsZS5oZy1JTl9V
U0VfUEFUQ0hFRC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcHQKPiA+IC1ncmFw
aGljcy5jOjM3MzogZXJyb3I6IHRvbyBtYW55IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDigJhwdF9w
Y2lfaG9zdF9yZWFk4oCZCj4gPiAvcm9vdC94ZW4tdW5zdGFibGUuaGctSU5fVVNFX1BBVENIRUQv
dG9vbHMvcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyL2h3L3B0Cj4gPiAtZ3JhcGhpY3MuYzozNzQ6
IGVycm9yOiB0b28gbWFueSBhcmd1bWVudHMgdG8gZnVuY3Rpb24g4oCYcHRfcGNpX2hvc3RfcmVh
ZOKAmQo+ID4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VTRV9QQVRDSEVEL3Rvb2xzL3FlbXUt
eGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdAo+ID4gLWdyYXBoaWNzLmM6IEluIGZ1bmN0aW9uIOKA
mGlnZF91bnJlZ2lzdGVyX3ZnYV9yZWdpb25z4oCZOgo+ID4gL3Jvb3QveGVuLXVuc3RhYmxlLmhn
LUlOX1VTRV9QQVRDSEVEL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdAo+ID4g
LWdyYXBoaWNzLmM6Mzk2OiBlcnJvcjogdG9vIG1hbnkgYXJndW1lbnRzIHRvIGZ1bmN0aW9uIOKA
mHB0X3BjaV9ob3N0X3JlYWTigJkKPiA+IC9yb290L3hlbi11bnN0YWJsZS5oZy1JTl9VU0VfUEFU
Q0hFRC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcHQKPiA+IC1ncmFwaGljcy5j
OjM5NzogZXJyb3I6IHRvbyBtYW55IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDigJhwdF9wY2lfaG9z
dF9yZWFk4oCZCj4gPiBtYWtlWzRdOiAqKiogW3B0LWdyYXBoaWNzLm9dIEVycm9yIDEKPiA+IG1h
a2VbNF06IExlYXZpbmcgZGlyZWN0b3J5Cj4gPiBgL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VT
RV9QQVRDSEVEL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci1yZW1vCj4gPiB0ZS9pMzg2
LWRtJyBtYWtlWzNdOiAqKiogW3N1YmRpci1pMzg2LWRtXSBFcnJvciAyCj4gPiBtYWtlWzNdOiBM
ZWF2aW5nIGRpcmVjdG9yeQo+ID4gYC9yb290L3hlbi11bnN0YWJsZS5oZy1JTl9VU0VfUEFUQ0hF
RC90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtbwo+ID4gdGUnIG1ha2VbMl06ICoq
KiBbc3ViZGlyLWluc3RhbGwtcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyXSBFcnJvciAyCj4gPiBt
YWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QveGVuLXVuc3RhYmxlLmhnLUlOX1VTRV9Q
QVRDSEVEL3Rvb2xzJwo+ID4gbWFrZVsxXTogKioqIFtzdWJkaXJzLWluc3RhbGxdIEVycm9yIDIK
PiA+IG1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4tdW5zdGFibGUuaGctSU5f
VVNFX1BBVENIRUQvdG9vbHMnCj4gPiBtYWtlOiAqKiogW2luc3RhbGwtdG9vbHNdIEVycm9yIDIK
PiA+IAo+ID4gCj4gPiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9QQVRDSC0xLTMt
cWVtdS14ZW4tQ2hhbmdlLXByb3RvdHlwZS1mb3ItCj4gPiBwdC1wY2ktaG9zdC1yZWFkLXdyaXRl
LXRkNTAxNjcxMy5odG1sCj4gPiAKPiA+ICBleGFtcGxlOgo+ID4gCj4gPiAgb2xkIHN5bGU6Cj4g
PiB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKDAsIDIsIDAsIDAsIDIpOwo+ID4gCj4gPiAg
bmV3IHN5bGU6Cj4gPiB2aWQgPSBwdF9wY2lfaG9zdF9yZWFkKHBjaV9kZXZfMWYsIFBDSV9WRU5E
T1JfSUQsIDIpOwo+ID4gCj4gPiAgQmVzdCBSZWdhcmRzLAo+ID4gCj4gPiBLcmlzdGlqYW4gTGXE
jW5pawoKSGksCnN0aWxsIHRoZSBzYW1lIHN0b3J5Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hp
dmVzL2h0bWwveGVuLWRldmVsLzIwMTEtMDUvbXNnMDE3MzQuaHRtbAoKQnV0IGFsbCBteSByZWNl
bnQgYXR0ZW1wdHMgZmFpbGVkIGFueXdheS4gTXkgbGFzdCB3b3JraW5nIHNldHVwIGlzIHdpdGgg
b2xkIAoyLjYuMzIueCBrZXJuZWwuCi0tIApQYXZlbCBNYXRlamEKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Apr 08 16:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGunI-0004Ei-2m; Sun, 08 Apr 2012 16:16:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGunG-0004Ea-Ki
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 16:16:46 +0000
Received: from [85.158.143.35:12094] by server-2.bemta-4.messagelabs.com id
	44/59-17550-DE9B18F4; Sun, 08 Apr 2012 16:16:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333901805!15359849!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9289 invoked from network); 8 Apr 2012 16:16:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 16:16:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,390,1330905600"; d="scan'208";a="11825204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 16:16:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 17:16:44 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGunE-00060a-8P;
	Sun, 08 Apr 2012 16:16:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGunD-0004E9-Sf;
	Sun, 08 Apr 2012 17:16:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12609-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 17:16:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12609: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12609 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12609/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 16:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGunI-0004Ei-2m; Sun, 08 Apr 2012 16:16:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGunG-0004Ea-Ki
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 16:16:46 +0000
Received: from [85.158.143.35:12094] by server-2.bemta-4.messagelabs.com id
	44/59-17550-DE9B18F4; Sun, 08 Apr 2012 16:16:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1333901805!15359849!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9289 invoked from network); 8 Apr 2012 16:16:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 16:16:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,390,1330905600"; d="scan'208";a="11825204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 16:16:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 17:16:44 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGunE-00060a-8P;
	Sun, 08 Apr 2012 16:16:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGunD-0004E9-Sf;
	Sun, 08 Apr 2012 17:16:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12609-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 17:16:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12609: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12609 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12609/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 18:06:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 18:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGwUd-0004hf-8L; Sun, 08 Apr 2012 18:05:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGwUa-0004ha-No
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 18:05:37 +0000
Received: from [85.158.139.83:45424] by server-9.bemta-5.messagelabs.com id
	BA/E3-09826-073D18F4; Sun, 08 Apr 2012 18:05:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333908334!20235700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22900 invoked from network); 8 Apr 2012 18:05:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 18:05:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,390,1330905600"; d="scan'208";a="11826107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 18:05:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 19:05:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGwUW-0006Zu-Vz;
	Sun, 08 Apr 2012 18:05:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGwUW-00018v-Um;
	Sun, 08 Apr 2012 19:05:32 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12610-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 19:05:32 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12610: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12610 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12610/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                498c91166125fdcf66741cd7ee784461d371adf8
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 498c91166125fdcf66741cd7ee784461d371adf8
Merge: c00cc3c1... 8c91c53...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 6 18:46:10 2012 +0200

    Merge branch 'x86/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 18:06:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 18:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGwUd-0004hf-8L; Sun, 08 Apr 2012 18:05:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGwUa-0004ha-No
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 18:05:37 +0000
Received: from [85.158.139.83:45424] by server-9.bemta-5.messagelabs.com id
	BA/E3-09826-073D18F4; Sun, 08 Apr 2012 18:05:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1333908334!20235700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22900 invoked from network); 8 Apr 2012 18:05:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 18:05:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,390,1330905600"; d="scan'208";a="11826107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 18:05:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 19:05:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGwUW-0006Zu-Vz;
	Sun, 08 Apr 2012 18:05:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGwUW-00018v-Um;
	Sun, 08 Apr 2012 19:05:32 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12610-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 19:05:32 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12610: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12610 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12610/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12565
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12565
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12565
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12565
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12565
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12565
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12565
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12565
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12565
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12565
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12565
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12565
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass

version targeted for testing:
 linux                498c91166125fdcf66741cd7ee784461d371adf8
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 498c91166125fdcf66741cd7ee784461d371adf8
Merge: c00cc3c1... 8c91c53...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 6 18:46:10 2012 +0200

    Merge branch 'x86/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 21:13:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 21:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGzPk-0005QZ-Un; Sun, 08 Apr 2012 21:12:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGzPj-0005QU-Tk
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 21:12:48 +0000
Received: from [85.158.143.99:56826] by server-2.bemta-4.messagelabs.com id
	B3/D1-17550-F4FF18F4; Sun, 08 Apr 2012 21:12:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333919566!13167574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6372 invoked from network); 8 Apr 2012 21:12:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 21:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="11826683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 21:12:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 22:12:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGzPg-0007YH-MX;
	Sun, 08 Apr 2012 21:12:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGzPg-0006pU-Bl;
	Sun, 08 Apr 2012 22:12:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12612-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 22:12:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12612: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12612 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12612/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl            3 host-install(3)              broken never pass
 test-i386-i386-win            3 host-install(3)              broken never pass
 test-amd64-i386-win-vcpus1    3 host-install(3)              broken never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 21:13:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 21:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGzPk-0005QZ-Un; Sun, 08 Apr 2012 21:12:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGzPj-0005QU-Tk
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 21:12:48 +0000
Received: from [85.158.143.99:56826] by server-2.bemta-4.messagelabs.com id
	B3/D1-17550-F4FF18F4; Sun, 08 Apr 2012 21:12:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1333919566!13167574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6372 invoked from network); 8 Apr 2012 21:12:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 21:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="11826683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 21:12:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 22:12:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGzPg-0007YH-MX;
	Sun, 08 Apr 2012 21:12:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGzPg-0006pU-Bl;
	Sun, 08 Apr 2012 22:12:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12612-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 22:12:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12612: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12612 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12612/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl            3 host-install(3)              broken never pass
 test-i386-i386-win            3 host-install(3)              broken never pass
 test-amd64-i386-win-vcpus1    3 host-install(3)              broken never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 21:15:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 21:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGzRe-0005W7-JV; Sun, 08 Apr 2012 21:14:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <killian.de.volder@scarlet.be>) id 1SGzRc-0005Vz-Gs
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 21:14:44 +0000
Received: from [85.158.143.99:17126] by server-2.bemta-4.messagelabs.com id
	B0/62-17550-3CFF18F4; Sun, 08 Apr 2012 21:14:43 +0000
X-Env-Sender: killian.de.volder@scarlet.be
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333919683!22235822!1
X-Originating-IP: [195.130.132.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNTAgPT4gMjc4MDM2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26360 invoked from network); 8 Apr 2012 21:14:43 -0000
Received: from jacques.telenet-ops.be (HELO jacques.telenet-ops.be)
	(195.130.132.50) by server-3.tower-216.messagelabs.com with SMTP;
	8 Apr 2012 21:14:43 -0000
Received: from [172.17.0.70] ([78.22.225.157])
	by jacques.telenet-ops.be with bizsmtp
	id vZEi1i00C3QNqd20JZEiTX; Sun, 08 Apr 2012 23:14:42 +0200
Message-ID: <4F81FFC2.5040800@scarlet.be>
Date: Sun, 08 Apr 2012 23:14:42 +0200
From: Killian De Volder <killian.de.volder@scarlet.be>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120405 Thunderbird/10.0.3
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] DomU network stalling when Dom0 generates a lot of TX
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I'm experiencing the following troubles:
When Dom0 generates a lot of TX traffic, the DomU's often stall (once every ~2mins, but it's fairly irregular), anywhere from 300ms up to 1800ms.
I made a little python script to try and figure out if the machine was getting cpu time:(If this is a correct way to test it.)
The time result of the script below is fairly consistent, indicating to me the machine is not stalling. (Unless the time is also stalled ofcours, but ntpq -p look fine.)
"""
import time

while True:
     ts=time.time()
     for i in range(0,10**6):
         i=i+1-1
     te=time.time()
     print te-ts
"""

It's also safe (I think) to exclude the network driver from the equation, as the same problem occurs on a bridge without a physical network drive. (bridge: dmz)

"""
# brctl show
bridge name    bridge id        STP enabled    interfaces
dmz        8000.feffffffffff    no        vif1.2
                             vif2.0
lan        8000.00c049593d25    no        eth_lan
                             vif1.0
                             vif11.0
wan        8000.00c049593e3f    no        eth_wan
                             vif1.1
"""

Example of a bad ping:
64 bytes from doc (172.17.0.2): icmp_req=3288 ttl=64 time=1130 ms
64 bytes from doc (172.17.0.2): icmp_req=3289 ttl=64 time=920 ms
64 bytes from doc (172.17.0.2): icmp_req=3290 ttl=64 time=710 ms
64 bytes from doc (172.17.0.2): icmp_req=3291 ttl=64 time=500 ms
64 bytes from doc (172.17.0.2): icmp_req=3292 ttl=64 time=300 ms
64 bytes from doc (172.17.0.2): icmp_req=3293 ttl=64 time=91.0 ms
64 bytes from doc (172.17.0.2): icmp_req=3294 ttl=64 time=0.147 ms
64 bytes from doc (172.17.0.2): icmp_req=3295 ttl=64 time=0.180 ms
(However during the same time dom0 is quite responsive.)

I also tried turning of offloading (TX,TO,GPO,...)

The TXqueuelen is 1000.
Dom0 is loaded with CPU during this time, but manually starting CPU load does not seem to create the problem.

Version info:
Kernel: xen 3.2.1-gentoo-r2
Xen-Hyp: Xen version 4.1.2


Does anyone has any ideas left of what could cause this ?

Kind regards,
Killian De Volder

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 21:15:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 21:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGzRe-0005W7-JV; Sun, 08 Apr 2012 21:14:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <killian.de.volder@scarlet.be>) id 1SGzRc-0005Vz-Gs
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 21:14:44 +0000
Received: from [85.158.143.99:17126] by server-2.bemta-4.messagelabs.com id
	B0/62-17550-3CFF18F4; Sun, 08 Apr 2012 21:14:43 +0000
X-Env-Sender: killian.de.volder@scarlet.be
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333919683!22235822!1
X-Originating-IP: [195.130.132.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNTAgPT4gMjc4MDM2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26360 invoked from network); 8 Apr 2012 21:14:43 -0000
Received: from jacques.telenet-ops.be (HELO jacques.telenet-ops.be)
	(195.130.132.50) by server-3.tower-216.messagelabs.com with SMTP;
	8 Apr 2012 21:14:43 -0000
Received: from [172.17.0.70] ([78.22.225.157])
	by jacques.telenet-ops.be with bizsmtp
	id vZEi1i00C3QNqd20JZEiTX; Sun, 08 Apr 2012 23:14:42 +0200
Message-ID: <4F81FFC2.5040800@scarlet.be>
Date: Sun, 08 Apr 2012 23:14:42 +0200
From: Killian De Volder <killian.de.volder@scarlet.be>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120405 Thunderbird/10.0.3
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] DomU network stalling when Dom0 generates a lot of TX
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I'm experiencing the following troubles:
When Dom0 generates a lot of TX traffic, the DomU's often stall (once every ~2mins, but it's fairly irregular), anywhere from 300ms up to 1800ms.
I made a little python script to try and figure out if the machine was getting cpu time:(If this is a correct way to test it.)
The time result of the script below is fairly consistent, indicating to me the machine is not stalling. (Unless the time is also stalled ofcours, but ntpq -p look fine.)
"""
import time

while True:
     ts=time.time()
     for i in range(0,10**6):
         i=i+1-1
     te=time.time()
     print te-ts
"""

It's also safe (I think) to exclude the network driver from the equation, as the same problem occurs on a bridge without a physical network drive. (bridge: dmz)

"""
# brctl show
bridge name    bridge id        STP enabled    interfaces
dmz        8000.feffffffffff    no        vif1.2
                             vif2.0
lan        8000.00c049593d25    no        eth_lan
                             vif1.0
                             vif11.0
wan        8000.00c049593e3f    no        eth_wan
                             vif1.1
"""

Example of a bad ping:
64 bytes from doc (172.17.0.2): icmp_req=3288 ttl=64 time=1130 ms
64 bytes from doc (172.17.0.2): icmp_req=3289 ttl=64 time=920 ms
64 bytes from doc (172.17.0.2): icmp_req=3290 ttl=64 time=710 ms
64 bytes from doc (172.17.0.2): icmp_req=3291 ttl=64 time=500 ms
64 bytes from doc (172.17.0.2): icmp_req=3292 ttl=64 time=300 ms
64 bytes from doc (172.17.0.2): icmp_req=3293 ttl=64 time=91.0 ms
64 bytes from doc (172.17.0.2): icmp_req=3294 ttl=64 time=0.147 ms
64 bytes from doc (172.17.0.2): icmp_req=3295 ttl=64 time=0.180 ms
(However during the same time dom0 is quite responsive.)

I also tried turning of offloading (TX,TO,GPO,...)

The TXqueuelen is 1000.
Dom0 is loaded with CPU during this time, but manually starting CPU load does not seem to create the problem.

Version info:
Kernel: xen 3.2.1-gentoo-r2
Xen-Hyp: Xen version 4.1.2


Does anyone has any ideas left of what could cause this ?

Kind regards,
Killian De Volder

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 21:17:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 21:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGzTN-0005bp-2r; Sun, 08 Apr 2012 21:16:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGzTL-0005bi-LX
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 21:16:31 +0000
Received: from [85.158.143.35:9050] by server-2.bemta-4.messagelabs.com id
	FE/C2-17550-E20028F4; Sun, 08 Apr 2012 21:16:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333919790!11642593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25953 invoked from network); 8 Apr 2012 21:16:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 21:16:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="11826693"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 21:16:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 22:16:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGzTJ-0007ZR-F9;
	Sun, 08 Apr 2012 21:16:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGzTJ-0004Pl-9V;
	Sun, 08 Apr 2012 22:16:29 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12613-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 22:16:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12613: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12613 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12613/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64                   2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 08 21:17:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Apr 2012 21:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SGzTN-0005bp-2r; Sun, 08 Apr 2012 21:16:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SGzTL-0005bi-LX
	for xen-devel@lists.xensource.com; Sun, 08 Apr 2012 21:16:31 +0000
Received: from [85.158.143.35:9050] by server-2.bemta-4.messagelabs.com id
	FE/C2-17550-E20028F4; Sun, 08 Apr 2012 21:16:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1333919790!11642593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25953 invoked from network); 8 Apr 2012 21:16:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Apr 2012 21:16:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="11826693"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Apr 2012 21:16:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Apr 2012 22:16:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SGzTJ-0007ZR-F9;
	Sun, 08 Apr 2012 21:16:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SGzTJ-0004Pl-9V;
	Sun, 08 Apr 2012 22:16:29 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12613-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Apr 2012 22:16:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12613: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12613 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12613/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64                   2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 05:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 05:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SH6qq-0004Ow-FA; Mon, 09 Apr 2012 05:09:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wnlo.zwt@gmail.com>) id 1SH6qo-0004Or-7f
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 05:09:14 +0000
Received: from [85.158.139.83:61527] by server-8.bemta-5.messagelabs.com id
	AE/BC-26964-9FE628F4; Mon, 09 Apr 2012 05:09:13 +0000
X-Env-Sender: wnlo.zwt@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333948151!18704075!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22970 invoked from network); 9 Apr 2012 05:09:12 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 05:09:12 -0000
Received: by vbbfs19 with SMTP id fs19so2752784vbb.32
	for <xen-devel@lists.xen.org>; Sun, 08 Apr 2012 22:09:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=xvubN6GV7nyB8R4ta9EypV4g3kKGu8FlgfYUnQU5WDs=;
	b=qS5Eh0a3BfFokBB0WOYNsVeeQUs7X/48cbl9fGpm+Q5kNbDO24sKoISAT40ZdV7DS5
	KfsQcsevjmLeAb0unrBHz3NUkLoIQIJLbrxQIJPNEW67/bYvSaF26CKb2LSHM1Uk6hHf
	GphM9TYsa3I4j2PApNgnBYUb7i8q2Y5O0N9mu/TuYWDkNsyjslTuzFfqFAmF3KvSVSQc
	m+cxSnjrsU0vifsqcsMNjtUaavDRYZzfQjkkqdDU7GdwfRdifCrrnjqnXUL8W9djV6D4
	hh+1sZGzeoeRU61vnZP736iWdPjiYAcz/M7/0KksPCWc1h28rz7kWhCJHqMIfvWZ2aAF
	7Qmw==
MIME-Version: 1.0
Received: by 10.220.117.203 with SMTP id s11mr3000103vcq.33.1333948151345;
	Sun, 08 Apr 2012 22:09:11 -0700 (PDT)
Received: by 10.52.31.137 with HTTP; Sun, 8 Apr 2012 22:09:11 -0700 (PDT)
Date: Mon, 9 Apr 2012 13:09:11 +0800
Message-ID: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
From: Wentao Zhang <wnlo.zwt@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] How to add debug information in libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4388331070839891640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4388331070839891640==
Content-Type: multipart/alternative; boundary=485b39618d12b5b48904bd3801a8

--485b39618d12b5b48904bd3801a8
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
        I want to add debug information in /tools/libxc/xc_csched.c, I have
used PERROR to output the information, but I don`t know how to find the
output information,
    I used xm dm to look at it, but there is nothing, and I also read the
xend.log, nothing either. How should I do to add debug information, and to
find the output information ?
        thank you !

-- 
Best wishes !

--485b39618d12b5b48904bd3801a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span>Hi all,</span><div>=A0 =A0 =A0 =A0 I want to add debug information in=
 /tools/libxc/xc_csched.c, I have used PERROR to output the information, bu=
t I don`t know how to find the output information,</div><div>=A0 =A0 I used=
 xm dm to look at it, but there is nothing, and I also read the xend.log, n=
othing either. How should I do to add debug information, and to find the ou=
tput information ?</div>


<div>=A0 =A0 =A0 =A0 thank you !</div><div><br></div>-- <br>Best wishes !<b=
r>

--485b39618d12b5b48904bd3801a8--


--===============4388331070839891640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4388331070839891640==--


From xen-devel-bounces@lists.xen.org Mon Apr 09 05:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 05:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SH6qq-0004Ow-FA; Mon, 09 Apr 2012 05:09:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wnlo.zwt@gmail.com>) id 1SH6qo-0004Or-7f
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 05:09:14 +0000
Received: from [85.158.139.83:61527] by server-8.bemta-5.messagelabs.com id
	AE/BC-26964-9FE628F4; Mon, 09 Apr 2012 05:09:13 +0000
X-Env-Sender: wnlo.zwt@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1333948151!18704075!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22970 invoked from network); 9 Apr 2012 05:09:12 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 05:09:12 -0000
Received: by vbbfs19 with SMTP id fs19so2752784vbb.32
	for <xen-devel@lists.xen.org>; Sun, 08 Apr 2012 22:09:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=xvubN6GV7nyB8R4ta9EypV4g3kKGu8FlgfYUnQU5WDs=;
	b=qS5Eh0a3BfFokBB0WOYNsVeeQUs7X/48cbl9fGpm+Q5kNbDO24sKoISAT40ZdV7DS5
	KfsQcsevjmLeAb0unrBHz3NUkLoIQIJLbrxQIJPNEW67/bYvSaF26CKb2LSHM1Uk6hHf
	GphM9TYsa3I4j2PApNgnBYUb7i8q2Y5O0N9mu/TuYWDkNsyjslTuzFfqFAmF3KvSVSQc
	m+cxSnjrsU0vifsqcsMNjtUaavDRYZzfQjkkqdDU7GdwfRdifCrrnjqnXUL8W9djV6D4
	hh+1sZGzeoeRU61vnZP736iWdPjiYAcz/M7/0KksPCWc1h28rz7kWhCJHqMIfvWZ2aAF
	7Qmw==
MIME-Version: 1.0
Received: by 10.220.117.203 with SMTP id s11mr3000103vcq.33.1333948151345;
	Sun, 08 Apr 2012 22:09:11 -0700 (PDT)
Received: by 10.52.31.137 with HTTP; Sun, 8 Apr 2012 22:09:11 -0700 (PDT)
Date: Mon, 9 Apr 2012 13:09:11 +0800
Message-ID: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
From: Wentao Zhang <wnlo.zwt@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] How to add debug information in libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4388331070839891640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4388331070839891640==
Content-Type: multipart/alternative; boundary=485b39618d12b5b48904bd3801a8

--485b39618d12b5b48904bd3801a8
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
        I want to add debug information in /tools/libxc/xc_csched.c, I have
used PERROR to output the information, but I don`t know how to find the
output information,
    I used xm dm to look at it, but there is nothing, and I also read the
xend.log, nothing either. How should I do to add debug information, and to
find the output information ?
        thank you !

-- 
Best wishes !

--485b39618d12b5b48904bd3801a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span>Hi all,</span><div>=A0 =A0 =A0 =A0 I want to add debug information in=
 /tools/libxc/xc_csched.c, I have used PERROR to output the information, bu=
t I don`t know how to find the output information,</div><div>=A0 =A0 I used=
 xm dm to look at it, but there is nothing, and I also read the xend.log, n=
othing either. How should I do to add debug information, and to find the ou=
tput information ?</div>


<div>=A0 =A0 =A0 =A0 thank you !</div><div><br></div>-- <br>Best wishes !<b=
r>

--485b39618d12b5b48904bd3801a8--


--===============4388331070839891640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4388331070839891640==--


From xen-devel-bounces@lists.xen.org Mon Apr 09 05:46:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 05:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SH7Q7-0004ed-6d; Mon, 09 Apr 2012 05:45:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SH7Q5-0004eT-Vo
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 05:45:42 +0000
Received: from [193.109.254.147:33793] by server-1.bemta-14.messagelabs.com id
	D7/2B-29372-587728F4; Mon, 09 Apr 2012 05:45:41 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333950337!1274475!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6384 invoked from network); 9 Apr 2012 05:45:38 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-27.messagelabs.com with SMTP;
	9 Apr 2012 05:45:38 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 25367DBC93
	for <xen-devel@lists.xen.org>; Mon,  9 Apr 2012 13:45:22 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so2183067vcb.32
	for <xen-devel@lists.xen.org>; Sun, 08 Apr 2012 22:45:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.228 with SMTP id fb4mr2698775vdb.62.1333950317364; Sun,
	08 Apr 2012 22:45:17 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Sun, 8 Apr 2012 22:45:17 -0700 (PDT)
In-Reply-To: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
References: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
Date: Mon, 9 Apr 2012 13:45:17 +0800
Message-ID: <CAF1ivSaU1+G0H3WwQ+F3THY60SheywOVcxpja+Z=bRksju7fVA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Wentao Zhang <wnlo.zwt@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] How to add debug information in libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 9, 2012 at 1:09 PM, Wentao Zhang <wnlo.zwt@gmail.com> wrote:
> Hi all,
> =A0 =A0 =A0 =A0 I want to add debug information in /tools/libxc/xc_csched=
.c, I have
> used PERROR to output the information, but I don`t know how to find the
> output information,
> =A0 =A0 I used xm dm to look at it, but there is nothing, and I also read=
 the
> xend.log, nothing either. How should I do to add debug information, and to
> find the output information ?

I guess you are still using the old installed library.

Try:

export LD_LIBRARY_PATH=3D<your xen source dir>/tools/libxc:$LD_LIBRARY_PATH

Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 05:46:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 05:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SH7Q7-0004ed-6d; Mon, 09 Apr 2012 05:45:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SH7Q5-0004eT-Vo
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 05:45:42 +0000
Received: from [193.109.254.147:33793] by server-1.bemta-14.messagelabs.com id
	D7/2B-29372-587728F4; Mon, 09 Apr 2012 05:45:41 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-27.messagelabs.com!1333950337!1274475!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6384 invoked from network); 9 Apr 2012 05:45:38 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-27.messagelabs.com with SMTP;
	9 Apr 2012 05:45:38 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 25367DBC93
	for <xen-devel@lists.xen.org>; Mon,  9 Apr 2012 13:45:22 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so2183067vcb.32
	for <xen-devel@lists.xen.org>; Sun, 08 Apr 2012 22:45:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.228 with SMTP id fb4mr2698775vdb.62.1333950317364; Sun,
	08 Apr 2012 22:45:17 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Sun, 8 Apr 2012 22:45:17 -0700 (PDT)
In-Reply-To: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
References: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
Date: Mon, 9 Apr 2012 13:45:17 +0800
Message-ID: <CAF1ivSaU1+G0H3WwQ+F3THY60SheywOVcxpja+Z=bRksju7fVA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Wentao Zhang <wnlo.zwt@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] How to add debug information in libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 9, 2012 at 1:09 PM, Wentao Zhang <wnlo.zwt@gmail.com> wrote:
> Hi all,
> =A0 =A0 =A0 =A0 I want to add debug information in /tools/libxc/xc_csched=
.c, I have
> used PERROR to output the information, but I don`t know how to find the
> output information,
> =A0 =A0 I used xm dm to look at it, but there is nothing, and I also read=
 the
> xend.log, nothing either. How should I do to add debug information, and to
> find the output information ?

I guess you are still using the old installed library.

Try:

export LD_LIBRARY_PATH=3D<your xen source dir>/tools/libxc:$LD_LIBRARY_PATH

Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 06:25:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 06:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SH823-0005ET-E8; Mon, 09 Apr 2012 06:24:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SH821-0005EO-PJ
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 06:24:53 +0000
Received: from [193.109.254.147:45548] by server-11.bemta-14.messagelabs.com
	id BB/E5-05858-5B0828F4; Mon, 09 Apr 2012 06:24:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333952599!1276577!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32602 invoked from network); 9 Apr 2012 06:24:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 06:24:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,392,1330905600"; d="scan'208";a="11828129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 04:20:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 05:20:46 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SH65u-0001OL-Cd;
	Mon, 09 Apr 2012 04:20:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SH65u-00043r-2z;
	Mon, 09 Apr 2012 05:20:46 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12615-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 05:20:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12615: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12615 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12615/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 06:25:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 06:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SH823-0005ET-E8; Mon, 09 Apr 2012 06:24:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SH821-0005EO-PJ
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 06:24:53 +0000
Received: from [193.109.254.147:45548] by server-11.bemta-14.messagelabs.com
	id BB/E5-05858-5B0828F4; Mon, 09 Apr 2012 06:24:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333952599!1276577!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32602 invoked from network); 9 Apr 2012 06:24:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 06:24:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,392,1330905600"; d="scan'208";a="11828129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 04:20:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 05:20:46 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SH65u-0001OL-Cd;
	Mon, 09 Apr 2012 04:20:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SH65u-00043r-2z;
	Mon, 09 Apr 2012 05:20:46 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12615-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 05:20:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12615: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12615 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12615/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11890
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 10:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 10:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHBZ6-0007JZ-6c; Mon, 09 Apr 2012 10:11:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHBZ5-0007JU-5v
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 10:11:15 +0000
Received: from [85.158.138.51:42831] by server-2.bemta-3.messagelabs.com id
	8A/DA-15460-2C5B28F4; Mon, 09 Apr 2012 10:11:14 +0000
X-Env-Sender: mitsov@seznam.cz
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333966272!21298498!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7485 invoked from network); 9 Apr 2012 10:11:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Apr 2012 10:11:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHBZ1-00062o-Cu
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 03:11:11 -0700
Date: Mon, 9 Apr 2012 03:11:11 -0700 (PDT)
From: dmitzov <mitsov@seznam.cz>
To: xen-devel@lists.xensource.com
Message-ID: <1333966271393-5627103.post@n5.nabble.com>
In-Reply-To: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
References: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] VGA Passthrough Experience
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
I am trying to run xen 4.1.1 on the same motherboard ( Asrock 890fx deluxe 5
bios v1.50) and gentoo 3.2.12 but the PC cannot but into xen. The machine
reboots immediately a short moment after starting to load Dom0. 
http://xen.1045712.n5.nabble.com/file/n5627103/xen_fail.jpg  Probably the
problem is in the Dom0 kernel itself. I can however boot this kernel without
xen.
I also noticed this error on the screen
(XEN) AMD-Vi: IOMMU not found!
I have certainly iommu enabled in the bios.
Did you encounter these problems? Could you send me more details of your
configuration?

Thanks,
Deyan

--
View this message in context: http://xen.1045712.n5.nabble.com/VGA-Passthrough-Experience-tp5134194p5627103.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 10:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 10:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHBZ6-0007JZ-6c; Mon, 09 Apr 2012 10:11:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHBZ5-0007JU-5v
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 10:11:15 +0000
Received: from [85.158.138.51:42831] by server-2.bemta-3.messagelabs.com id
	8A/DA-15460-2C5B28F4; Mon, 09 Apr 2012 10:11:14 +0000
X-Env-Sender: mitsov@seznam.cz
X-Msg-Ref: server-11.tower-174.messagelabs.com!1333966272!21298498!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7485 invoked from network); 9 Apr 2012 10:11:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Apr 2012 10:11:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHBZ1-00062o-Cu
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 03:11:11 -0700
Date: Mon, 9 Apr 2012 03:11:11 -0700 (PDT)
From: dmitzov <mitsov@seznam.cz>
To: xen-devel@lists.xensource.com
Message-ID: <1333966271393-5627103.post@n5.nabble.com>
In-Reply-To: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
References: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] VGA Passthrough Experience
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
I am trying to run xen 4.1.1 on the same motherboard ( Asrock 890fx deluxe 5
bios v1.50) and gentoo 3.2.12 but the PC cannot but into xen. The machine
reboots immediately a short moment after starting to load Dom0. 
http://xen.1045712.n5.nabble.com/file/n5627103/xen_fail.jpg  Probably the
problem is in the Dom0 kernel itself. I can however boot this kernel without
xen.
I also noticed this error on the screen
(XEN) AMD-Vi: IOMMU not found!
I have certainly iommu enabled in the bios.
Did you encounter these problems? Could you send me more details of your
configuration?

Thanks,
Deyan

--
View this message in context: http://xen.1045712.n5.nabble.com/VGA-Passthrough-Experience-tp5134194p5627103.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 12:14:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 12:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHDTv-0007xl-45; Mon, 09 Apr 2012 12:14:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <twwood@gmail.com>) id 1SHDTu-0007xg-7f
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 12:14:02 +0000
Received: from [193.109.254.147:46682] by server-7.bemta-14.messagelabs.com id
	C1/D8-01627-982D28F4; Mon, 09 Apr 2012 12:14:01 +0000
X-Env-Sender: twwood@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333973639!3785366!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29163 invoked from network); 9 Apr 2012 12:14:00 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 12:14:00 -0000
Received: by qadb15 with SMTP id b15so1914009qad.16
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 05:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=/iywxE+S+UwNLtAUzuz+sP/jYDZs36tdYnAyGt3NzWk=;
	b=h70Duv2S2dJJURHDwXpajsui6FmSb1uiez8V9sYGmLLDNEc5ZJ9L/NH24zSfW6alVV
	dciQTA1BhY5hqFZs6NB2mbcpw4Fj4PVEDLSvhtJo/KX3bH4JaCfJsHz5qGvSwaprzRGi
	rA8/qpKfBYbNmfCJkHhRcBxo9+FCaEPdcMSk7Y0gw1tjFixVyiL5m0XvLnuPIL/WUYYD
	un2TOZz24lGid4+N2+AqNw3/Z7e2bULYSO75ozb4yYm+3ja9ftotc53czURh/dSCu4do
	bbvYk8X/U2n8x8DEdvaRpwSFvtdmz3VT8FkFjr5ggIqtp2qYIZWjrOdbNULbrHl9U5Fi
	Ip8Q==
Received: by 10.224.187.2 with SMTP id cu2mr8672923qab.88.1333973638515; Mon,
	09 Apr 2012 05:13:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.136.70 with HTTP; Mon, 9 Apr 2012 05:13:38 -0700 (PDT)
In-Reply-To: <1333784256.12209.107.camel@dagon.hellion.org.uk>
References: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
	<1333784256.12209.107.camel@dagon.hellion.org.uk>
From: Tim Wood <twwood@gmail.com>
Date: Mon, 9 Apr 2012 08:13:38 -0400
Message-ID: <CABm+uF9BNFbroLnu9pj5n9s7KhoFduBWP-_XzxQ2OwqCEuyVHQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7717086364008156002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7717086364008156002==
Content-Type: multipart/alternative; boundary=485b397dd775dd0da404bd3df0b5

--485b397dd775dd0da404bd3df0b5
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 7, 2012 at 3:37 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:
> > In xen 4.0.X I was able to write custom blktap2 drivers as a nice way
> > to intercept VM disk traffic.  I'm now trying to take a step up to xen
> > 4.1.2 and find that blktap2 doesn't seem to be supported anymore, or
> > at least it requires a kernel module which I'm not sure where to
> > find.  Is blktap2 still in use, or is there an entirely different way
> > I should be approaching this?
> >
> >
> > Previously I could run commands like:
> >
> >
> > tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img
> >
> >
> > the new tapdisk2 doesn't support that interface anymore,
>
> What do you mean? I don't think the tap interface has changed (but I'm
> not sure). In any case I'm pretty sure the functionality should be there
> even if the command line has changed.
>

Sorry, I wasn't clear--the functionality is still there but the command
line interface has changed.  The xm-block attach command below seems to be
equivalent.


>
> >  but it seems like the correct approach is now:
> >
> >
> > xm block-attach 0 tap2:aio:/path/disk.img xvda w 0
> > Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
> > module not installed )
>
> I think this ultimately turns into the same sort of command as the one
> above.
>
> > What is the "proper" way of getting the blktap kernel module
> > installed?  I found this:
> > http://packages.debian.org/sid/blktap-dkms
>
> Unfortunately the blktap2 module is not something which can be
> upstreamed.
>
> The DKMS package is probably a good bet for now. The other alternative
> is to switch to a slightly older kernel which has the blktap2 driver in
> it, for example the 2.6.32 based xen.git kernel tree or one of the
> classic Xen forward ports.
>

OK, I will fiddle with DKMS a bit more or switch to 2.6.32.

>
> You mentioned writing your own blktap modules so the qemu-supplied qdisk
> backend is probably not much use to you. This is used by the "xl"
> toolstack by default when blktap is not present, but isn't supported by
> xm and doesn't allow for custom modules .
>
> I'm actually quite interested in the fact that you are writing custom
> blktap modules -- are you able to share the details?
>
>
Sure, I'm a CS professor and do research on what cool stuff you can add in
the virtualization layer.  What I did before was a module similar to
remus's, but designed for WAN replication and synchronizing across groups
of VMs.  The paper can be a bit tough to get through, but it has some of
the details:
http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.pdf

Blktap is a very handy way for us to prototype these types of features
without having to muck through the core xen code.


> > but couldn't get it to actually install.
>
> Please share the details so we can try and figure out why.
>
> > In any case, it seems unlikely that is the best way to go.
>
> Sadly it is, for now.
>
> Long term someone is working on a "blktap3" which is fully userspace and
> so doesn't require a kernel module. We hope to see this for 4.3. For 4.2
> it looks like we'll be sticking with the qdisk backend.
>
> Sounds great, I look forward to it.

--485b397dd775dd0da404bd3df0b5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Sat, Apr 7, 2012 at 3:37 AM, Ian Campbell <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@=
citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:<br>
&gt; In xen 4.0.X I was able to write custom blktap2 drivers as a nice way<=
br>
&gt; to intercept VM disk traffic. =A0I&#39;m now trying to take a step up =
to xen<br>
&gt; 4.1.2 and find that blktap2 doesn&#39;t seem to be supported anymore, =
or<br>
&gt; at least it requires a kernel module which I&#39;m not sure where to<b=
r>
&gt; find. =A0Is blktap2 still in use, or is there an entirely different wa=
y<br>
&gt; I should be approaching this?<br>
&gt;<br>
&gt;<br>
&gt; Previously I could run commands like:<br>
&gt;<br>
&gt;<br>
&gt; tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img<br>
&gt;<br>
&gt;<br>
&gt; the new tapdisk2 doesn&#39;t support that interface anymore,<br>
<br>
</div>What do you mean? I don&#39;t think the tap interface has changed (bu=
t I&#39;m<br>
not sure). In any case I&#39;m pretty sure the functionality should be ther=
e<br>
even if the command line has changed.<br></blockquote><div><br></div><div>S=
orry, I wasn&#39;t clear--the functionality is still there but the command =
line interface has changed. =A0The xm-block attach command below seems to b=
e equivalent.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
&gt; =A0but it seems like the correct approach is now:<br>
&gt;<br>
&gt;<br>
&gt; xm block-attach 0 tap2:aio:/path/disk.img xvda w 0<br>
&gt; Error: (&#39;create&#39;, &#39;-aaio:/path/disk.img&#39;) failed (5580=
8 blktap kernel<br>
&gt; module not installed )<br>
<br>
</div>I think this ultimately turns into the same sort of command as the on=
e<br>
above.<br>
<div class=3D"im"><br>
&gt; What is the &quot;proper&quot; way of getting the blktap kernel module=
<br>
&gt; installed? =A0I found this:<br>
&gt; <a href=3D"http://packages.debian.org/sid/blktap-dkms" target=3D"_blan=
k">http://packages.debian.org/sid/blktap-dkms</a><br>
<br>
</div>Unfortunately the blktap2 module is not something which can be<br>
upstreamed.<br>
<br>
The DKMS package is probably a good bet for now. The other alternative<br>
is to switch to a slightly older kernel which has the blktap2 driver in<br>
it, for example the 2.6.32 based xen.git kernel tree or one of the<br>
classic Xen forward ports.<br></blockquote><div><br></div><div>OK, I will f=
iddle with DKMS a bit more or switch to 2.6.32.</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">


<br>
You mentioned writing your own blktap modules so the qemu-supplied qdisk<br=
>
backend is probably not much use to you. This is used by the &quot;xl&quot;=
<br>
toolstack by default when blktap is not present, but isn&#39;t supported by=
<br>
xm and doesn&#39;t allow for custom modules .<br>
<br>
I&#39;m actually quite interested in the fact that you are writing custom<b=
r>
blktap modules -- are you able to share the details?<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>Sure, I&#39;m =
a CS professor and do research on what cool stuff you can add in the virtua=
lization layer. =A0What I did before was a module similar to remus&#39;s, b=
ut designed for WAN replication and synchronizing across groups of VMs. =A0=
The paper can be a bit tough to get through, but it has some of the details=
:</div>

<div><a href=3D"http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.=
pdf">http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.pdf</a></di=
v><div><br></div><div>Blktap is a very handy way for us to prototype these =
types of features without having to muck through the core xen code.=A0</div=
>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt; but couldn&#39;t get it to actually install.<br>
<br>
</div>Please share the details so we can try and figure out why.<br>
<div class=3D"im"><br>
&gt; In any case, it seems unlikely that is the best way to go.<br>
<br>
</div>Sadly it is, for now.<br>
<br>
Long term someone is working on a &quot;blktap3&quot; which is fully usersp=
ace and<br>
so doesn&#39;t require a kernel module. We hope to see this for 4.3. For 4.=
2<br>
it looks like we&#39;ll be sticking with the qdisk backend.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div>Sounds great, I look forward to it.</div><div><br></div></div>

--485b397dd775dd0da404bd3df0b5--


--===============7717086364008156002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7717086364008156002==--


From xen-devel-bounces@lists.xen.org Mon Apr 09 12:14:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 12:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHDTv-0007xl-45; Mon, 09 Apr 2012 12:14:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <twwood@gmail.com>) id 1SHDTu-0007xg-7f
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 12:14:02 +0000
Received: from [193.109.254.147:46682] by server-7.bemta-14.messagelabs.com id
	C1/D8-01627-982D28F4; Mon, 09 Apr 2012 12:14:01 +0000
X-Env-Sender: twwood@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1333973639!3785366!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29163 invoked from network); 9 Apr 2012 12:14:00 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 12:14:00 -0000
Received: by qadb15 with SMTP id b15so1914009qad.16
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 05:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=/iywxE+S+UwNLtAUzuz+sP/jYDZs36tdYnAyGt3NzWk=;
	b=h70Duv2S2dJJURHDwXpajsui6FmSb1uiez8V9sYGmLLDNEc5ZJ9L/NH24zSfW6alVV
	dciQTA1BhY5hqFZs6NB2mbcpw4Fj4PVEDLSvhtJo/KX3bH4JaCfJsHz5qGvSwaprzRGi
	rA8/qpKfBYbNmfCJkHhRcBxo9+FCaEPdcMSk7Y0gw1tjFixVyiL5m0XvLnuPIL/WUYYD
	un2TOZz24lGid4+N2+AqNw3/Z7e2bULYSO75ozb4yYm+3ja9ftotc53czURh/dSCu4do
	bbvYk8X/U2n8x8DEdvaRpwSFvtdmz3VT8FkFjr5ggIqtp2qYIZWjrOdbNULbrHl9U5Fi
	Ip8Q==
Received: by 10.224.187.2 with SMTP id cu2mr8672923qab.88.1333973638515; Mon,
	09 Apr 2012 05:13:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.136.70 with HTTP; Mon, 9 Apr 2012 05:13:38 -0700 (PDT)
In-Reply-To: <1333784256.12209.107.camel@dagon.hellion.org.uk>
References: <CABm+uF-pgymyAKjLkQ9nOsJLvacBrEyeV_A2y1obejCjjr_h=A@mail.gmail.com>
	<1333784256.12209.107.camel@dagon.hellion.org.uk>
From: Tim Wood <twwood@gmail.com>
Date: Mon, 9 Apr 2012 08:13:38 -0400
Message-ID: <CABm+uF9BNFbroLnu9pj5n9s7KhoFduBWP-_XzxQ2OwqCEuyVHQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7717086364008156002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7717086364008156002==
Content-Type: multipart/alternative; boundary=485b397dd775dd0da404bd3df0b5

--485b397dd775dd0da404bd3df0b5
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 7, 2012 at 3:37 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:
> > In xen 4.0.X I was able to write custom blktap2 drivers as a nice way
> > to intercept VM disk traffic.  I'm now trying to take a step up to xen
> > 4.1.2 and find that blktap2 doesn't seem to be supported anymore, or
> > at least it requires a kernel module which I'm not sure where to
> > find.  Is blktap2 still in use, or is there an entirely different way
> > I should be approaching this?
> >
> >
> > Previously I could run commands like:
> >
> >
> > tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img
> >
> >
> > the new tapdisk2 doesn't support that interface anymore,
>
> What do you mean? I don't think the tap interface has changed (but I'm
> not sure). In any case I'm pretty sure the functionality should be there
> even if the command line has changed.
>

Sorry, I wasn't clear--the functionality is still there but the command
line interface has changed.  The xm-block attach command below seems to be
equivalent.


>
> >  but it seems like the correct approach is now:
> >
> >
> > xm block-attach 0 tap2:aio:/path/disk.img xvda w 0
> > Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
> > module not installed )
>
> I think this ultimately turns into the same sort of command as the one
> above.
>
> > What is the "proper" way of getting the blktap kernel module
> > installed?  I found this:
> > http://packages.debian.org/sid/blktap-dkms
>
> Unfortunately the blktap2 module is not something which can be
> upstreamed.
>
> The DKMS package is probably a good bet for now. The other alternative
> is to switch to a slightly older kernel which has the blktap2 driver in
> it, for example the 2.6.32 based xen.git kernel tree or one of the
> classic Xen forward ports.
>

OK, I will fiddle with DKMS a bit more or switch to 2.6.32.

>
> You mentioned writing your own blktap modules so the qemu-supplied qdisk
> backend is probably not much use to you. This is used by the "xl"
> toolstack by default when blktap is not present, but isn't supported by
> xm and doesn't allow for custom modules .
>
> I'm actually quite interested in the fact that you are writing custom
> blktap modules -- are you able to share the details?
>
>
Sure, I'm a CS professor and do research on what cool stuff you can add in
the virtualization layer.  What I did before was a module similar to
remus's, but designed for WAN replication and synchronizing across groups
of VMs.  The paper can be a bit tough to get through, but it has some of
the details:
http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.pdf

Blktap is a very handy way for us to prototype these types of features
without having to muck through the core xen code.


> > but couldn't get it to actually install.
>
> Please share the details so we can try and figure out why.
>
> > In any case, it seems unlikely that is the best way to go.
>
> Sadly it is, for now.
>
> Long term someone is working on a "blktap3" which is fully userspace and
> so doesn't require a kernel module. We hope to see this for 4.3. For 4.2
> it looks like we'll be sticking with the qdisk backend.
>
> Sounds great, I look forward to it.

--485b397dd775dd0da404bd3df0b5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Sat, Apr 7, 2012 at 3:37 AM, Ian Campbell <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@=
citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:<br>
&gt; In xen 4.0.X I was able to write custom blktap2 drivers as a nice way<=
br>
&gt; to intercept VM disk traffic. =A0I&#39;m now trying to take a step up =
to xen<br>
&gt; 4.1.2 and find that blktap2 doesn&#39;t seem to be supported anymore, =
or<br>
&gt; at least it requires a kernel module which I&#39;m not sure where to<b=
r>
&gt; find. =A0Is blktap2 still in use, or is there an entirely different wa=
y<br>
&gt; I should be approaching this?<br>
&gt;<br>
&gt;<br>
&gt; Previously I could run commands like:<br>
&gt;<br>
&gt;<br>
&gt; tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img<br>
&gt;<br>
&gt;<br>
&gt; the new tapdisk2 doesn&#39;t support that interface anymore,<br>
<br>
</div>What do you mean? I don&#39;t think the tap interface has changed (bu=
t I&#39;m<br>
not sure). In any case I&#39;m pretty sure the functionality should be ther=
e<br>
even if the command line has changed.<br></blockquote><div><br></div><div>S=
orry, I wasn&#39;t clear--the functionality is still there but the command =
line interface has changed. =A0The xm-block attach command below seems to b=
e equivalent.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
&gt; =A0but it seems like the correct approach is now:<br>
&gt;<br>
&gt;<br>
&gt; xm block-attach 0 tap2:aio:/path/disk.img xvda w 0<br>
&gt; Error: (&#39;create&#39;, &#39;-aaio:/path/disk.img&#39;) failed (5580=
8 blktap kernel<br>
&gt; module not installed )<br>
<br>
</div>I think this ultimately turns into the same sort of command as the on=
e<br>
above.<br>
<div class=3D"im"><br>
&gt; What is the &quot;proper&quot; way of getting the blktap kernel module=
<br>
&gt; installed? =A0I found this:<br>
&gt; <a href=3D"http://packages.debian.org/sid/blktap-dkms" target=3D"_blan=
k">http://packages.debian.org/sid/blktap-dkms</a><br>
<br>
</div>Unfortunately the blktap2 module is not something which can be<br>
upstreamed.<br>
<br>
The DKMS package is probably a good bet for now. The other alternative<br>
is to switch to a slightly older kernel which has the blktap2 driver in<br>
it, for example the 2.6.32 based xen.git kernel tree or one of the<br>
classic Xen forward ports.<br></blockquote><div><br></div><div>OK, I will f=
iddle with DKMS a bit more or switch to 2.6.32.</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">


<br>
You mentioned writing your own blktap modules so the qemu-supplied qdisk<br=
>
backend is probably not much use to you. This is used by the &quot;xl&quot;=
<br>
toolstack by default when blktap is not present, but isn&#39;t supported by=
<br>
xm and doesn&#39;t allow for custom modules .<br>
<br>
I&#39;m actually quite interested in the fact that you are writing custom<b=
r>
blktap modules -- are you able to share the details?<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>Sure, I&#39;m =
a CS professor and do research on what cool stuff you can add in the virtua=
lization layer. =A0What I did before was a module similar to remus&#39;s, b=
ut designed for WAN replication and synchronizing across groups of VMs. =A0=
The paper can be a bit tough to get through, but it has some of the details=
:</div>

<div><a href=3D"http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.=
pdf">http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.pdf</a></di=
v><div><br></div><div>Blktap is a very handy way for us to prototype these =
types of features without having to muck through the core xen code.=A0</div=
>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt; but couldn&#39;t get it to actually install.<br>
<br>
</div>Please share the details so we can try and figure out why.<br>
<div class=3D"im"><br>
&gt; In any case, it seems unlikely that is the best way to go.<br>
<br>
</div>Sadly it is, for now.<br>
<br>
Long term someone is working on a &quot;blktap3&quot; which is fully usersp=
ace and<br>
so doesn&#39;t require a kernel module. We hope to see this for 4.3. For 4.=
2<br>
it looks like we&#39;ll be sticking with the qdisk backend.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div>Sounds great, I look forward to it.</div><div><br></div></div>

--485b397dd775dd0da404bd3df0b5--


--===============7717086364008156002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7717086364008156002==--


From xen-devel-bounces@lists.xen.org Mon Apr 09 12:17:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 12:17:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHDWM-00082L-Lr; Mon, 09 Apr 2012 12:16:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHDWL-00082B-JK
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 12:16:33 +0000
Received: from [193.109.254.147:57162] by server-6.bemta-14.messagelabs.com id
	24/F8-02047-023D28F4; Mon, 09 Apr 2012 12:16:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333973791!3783751!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28873 invoked from network); 9 Apr 2012 12:16:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 12:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="11831162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 12:16:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 13:16:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHDWJ-00057k-5Y;
	Mon, 09 Apr 2012 12:16:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHDWI-00047J-UC;
	Mon, 09 Apr 2012 13:16:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12617-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 13:16:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12617: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12617 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12617/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 12606
 test-amd64-i386-pv            3 host-install(3)           broken pass in 12606
 test-i386-i386-pv             3 host-install(3)  broken in 12606 pass in 12617
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 12606 pass in 12617

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken like 12595
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12606
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)             broken like 12606
 test-amd64-amd64-win          3 host-install(3)              broken like 12606
 test-amd64-i386-xl            3 host-install(3)              broken like 12606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 12:17:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 12:17:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHDWM-00082L-Lr; Mon, 09 Apr 2012 12:16:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHDWL-00082B-JK
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 12:16:33 +0000
Received: from [193.109.254.147:57162] by server-6.bemta-14.messagelabs.com id
	24/F8-02047-023D28F4; Mon, 09 Apr 2012 12:16:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1333973791!3783751!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28873 invoked from network); 9 Apr 2012 12:16:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 12:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="11831162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 12:16:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 13:16:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHDWJ-00057k-5Y;
	Mon, 09 Apr 2012 12:16:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHDWI-00047J-UC;
	Mon, 09 Apr 2012 13:16:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12617-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 13:16:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12617: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12617 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12617/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 12606
 test-amd64-i386-pv            3 host-install(3)           broken pass in 12606
 test-i386-i386-pv             3 host-install(3)  broken in 12606 pass in 12617
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 12606 pass in 12617

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken like 12595
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12606
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)             broken like 12606
 test-amd64-amd64-win          3 host-install(3)              broken like 12606
 test-amd64-i386-xl            3 host-install(3)              broken like 12606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 12:50:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 12:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHE2i-0008Jk-Bm; Mon, 09 Apr 2012 12:50:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHE2g-0008Jf-W5
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 12:49:59 +0000
Received: from [193.109.254.147:40986] by server-6.bemta-14.messagelabs.com id
	E7/24-02047-6FAD28F4; Mon, 09 Apr 2012 12:49:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333975797!1310919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1090 invoked from network); 9 Apr 2012 12:49:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 12:49:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="11831428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 12:48:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 13:48:54 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHE1e-0005Tu-Cy;
	Mon, 09 Apr 2012 12:48:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHE1e-0001tj-9j;
	Mon, 09 Apr 2012 13:48:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12618-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 13:48:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12618: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12618 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12618/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 12:50:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 12:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHE2i-0008Jk-Bm; Mon, 09 Apr 2012 12:50:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHE2g-0008Jf-W5
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 12:49:59 +0000
Received: from [193.109.254.147:40986] by server-6.bemta-14.messagelabs.com id
	E7/24-02047-6FAD28F4; Mon, 09 Apr 2012 12:49:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1333975797!1310919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1090 invoked from network); 9 Apr 2012 12:49:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 12:49:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="11831428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 12:48:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 13:48:54 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHE1e-0005Tu-Cy;
	Mon, 09 Apr 2012 12:48:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHE1e-0001tj-9j;
	Mon, 09 Apr 2012 13:48:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12618-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 13:48:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12618: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12618 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12618/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 16:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 16:34:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHHXZ-00020P-Lp; Mon, 09 Apr 2012 16:34:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHHXY-00020J-AC
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 16:34:04 +0000
Received: from [193.109.254.147:53599] by server-11.bemta-14.messagelabs.com
	id 34/50-05858-B7F038F4; Mon, 09 Apr 2012 16:34:03 +0000
X-Env-Sender: mitsov@seznam.cz
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333989241!3822281!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23944 invoked from network); 9 Apr 2012 16:34:03 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Apr 2012 16:34:03 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHHXV-0004JE-8R
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 09:34:01 -0700
Date: Mon, 9 Apr 2012 09:34:01 -0700 (PDT)
From: dmitzov <mitsov@seznam.cz>
To: xen-devel@lists.xensource.com
Message-ID: <1333989241254-5627711.post@n5.nabble.com>
In-Reply-To: <1333966271393-5627103.post@n5.nabble.com>
References: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
	<1333966271393-5627103.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] VGA Passthrough Experience
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Solved! I finally realised that GRUB2 was my trouble from the very beginning
since I went for GPT disks. I converted the disk (luckily without having to
reinstall) to MBR and replaced grub2 with grub-legacy. All is working, IOMMU
recognized by xen too.

Deyan

--
View this message in context: http://xen.1045712.n5.nabble.com/VGA-Passthrough-Experience-tp5134194p5627711.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 16:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 16:34:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHHXZ-00020P-Lp; Mon, 09 Apr 2012 16:34:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHHXY-00020J-AC
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 16:34:04 +0000
Received: from [193.109.254.147:53599] by server-11.bemta-14.messagelabs.com
	id 34/50-05858-B7F038F4; Mon, 09 Apr 2012 16:34:03 +0000
X-Env-Sender: mitsov@seznam.cz
X-Msg-Ref: server-13.tower-27.messagelabs.com!1333989241!3822281!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23944 invoked from network); 9 Apr 2012 16:34:03 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Apr 2012 16:34:03 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <mitsov@seznam.cz>) id 1SHHXV-0004JE-8R
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 09:34:01 -0700
Date: Mon, 9 Apr 2012 09:34:01 -0700 (PDT)
From: dmitzov <mitsov@seznam.cz>
To: xen-devel@lists.xensource.com
Message-ID: <1333989241254-5627711.post@n5.nabble.com>
In-Reply-To: <1333966271393-5627103.post@n5.nabble.com>
References: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
	<1333966271393-5627103.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] VGA Passthrough Experience
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Solved! I finally realised that GRUB2 was my trouble from the very beginning
since I went for GPT disks. I converted the disk (luckily without having to
reinstall) to MBR and replaced grub2 with grub-legacy. All is working, IOMMU
recognized by xen too.

Deyan

--
View this message in context: http://xen.1045712.n5.nabble.com/VGA-Passthrough-Experience-tp5134194p5627711.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 16:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 16:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHHd0-0002A1-J3; Mon, 09 Apr 2012 16:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1SHHcy-00029o-Jy
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 16:39:40 +0000
Received: from [85.158.143.99:31920] by server-3.bemta-4.messagelabs.com id
	37/7B-05853-BC0138F4; Mon, 09 Apr 2012 16:39:39 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333989578!22318662!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10098 invoked from network); 9 Apr 2012 16:39:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 16:39:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Apr 2012 17:39:36 +0100
Message-Id: <4F831ED7020000780008228C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Apr 2012 17:39:35 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<4F7AE321020000780007C456@nat28.tlf.novell.com>
	<20120406210117.GB26309@phenom.dumpdata.com>
In-Reply-To: <20120406210117.GB26309@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:06 PM >>>
>On Tue, Apr 03, 2012 at 10:46:41AM +0100, Jan Beulich wrote:
>> >>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
>> > With your new behaviour it will no longer possible to specify an
>> > unlimited balloon but a limited number of initial pages.  This is
>> > behaviour that Jan said he used.
>> 
>> An unlimited balloon was never possible afaict (as that would have
>> implied setting up an "infinite" number of struct page instances at
>> boot time.
>> 
>> What I'm using is "dom0_mem=-<num>M" together with the kernel
>> option "mem=<num>G", such that max-balloon > initial alloc (usually
>> I set max-balloon to approximately the amount of memory in the
>> system, so the upper limit is "infinite" in the sense that I can't go
>> higher anyway, but it's not truly infinity).
>
>Couldn't you do the same thing with 'dom0_mem=X,max:Y'

That would be possible (albeit not exactly identical in behavior). But my
main point in the discussion was to not modify existing behavior without
actual need to (including the desire to not have to modify dozens of
command lines).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 16:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 16:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHHd0-0002A1-J3; Mon, 09 Apr 2012 16:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1SHHcy-00029o-Jy
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 16:39:40 +0000
Received: from [85.158.143.99:31920] by server-3.bemta-4.messagelabs.com id
	37/7B-05853-BC0138F4; Mon, 09 Apr 2012 16:39:39 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1333989578!22318662!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10098 invoked from network); 9 Apr 2012 16:39:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 16:39:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Apr 2012 17:39:36 +0100
Message-Id: <4F831ED7020000780008228C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Apr 2012 17:39:35 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<4F7AE321020000780007C456@nat28.tlf.novell.com>
	<20120406210117.GB26309@phenom.dumpdata.com>
In-Reply-To: <20120406210117.GB26309@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:06 PM >>>
>On Tue, Apr 03, 2012 at 10:46:41AM +0100, Jan Beulich wrote:
>> >>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
>> > With your new behaviour it will no longer possible to specify an
>> > unlimited balloon but a limited number of initial pages.  This is
>> > behaviour that Jan said he used.
>> 
>> An unlimited balloon was never possible afaict (as that would have
>> implied setting up an "infinite" number of struct page instances at
>> boot time.
>> 
>> What I'm using is "dom0_mem=-<num>M" together with the kernel
>> option "mem=<num>G", such that max-balloon > initial alloc (usually
>> I set max-balloon to approximately the amount of memory in the
>> system, so the upper limit is "infinite" in the sense that I can't go
>> higher anyway, but it's not truly infinity).
>
>Couldn't you do the same thing with 'dom0_mem=X,max:Y'

That would be possible (albeit not exactly identical in behavior). But my
main point in the discussion was to not modify existing behavior without
actual need to (including the desire to not have to modify dozens of
command lines).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 16:56:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 16:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHHt1-0002OV-EO; Mon, 09 Apr 2012 16:56:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1SHHt0-0002OQ-0a
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 16:56:14 +0000
Received: from [85.158.143.35:37936] by server-1.bemta-4.messagelabs.com id
	C1/BB-20925-DA4138F4; Mon, 09 Apr 2012 16:56:13 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333990572!11862070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9325 invoked from network); 9 Apr 2012 16:56:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 16:56:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Apr 2012 17:56:12 +0100
Message-Id: <4F8322BB020000780008229D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Apr 2012 17:56:11 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <david.vrabel@citrix.com>,<konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<20120406205909.GA26309@phenom.dumpdata.com>
In-Reply-To: <20120406205909.GA26309@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:04 PM >>>
>> With your new behaviour it will no longer possible to specify an
>> unlimited balloon but a limited number of initial pages.  This is
>> behaviour that Jan said he used.
>
>I am not sure I see the problem - I mean if one uses:
>
>dom0_mem=min:8G,max:16G
>
>I understand that we want to start at 8GB and if the user
>choose to - balloon up to 16GB.
>
>But doing this:
>
>dom0_mem=8G
>
>and allocating pagetables up to .. say 32GB, seems counter-intuive
>as the effect is similar to having no 'dom0_mem' except that the initial
>size is smaller.

What's counter intuitive here? There may not be a need - from the perspective
of the kernel - for a hard upper limit enforced by Xen (i.e. the pseudo infinity
we have right now may be quite fine).

Anyway, as said in the other reply already - unless this is to address a bug, I
don't see the point in changing behavior that has been that way for a pretty
long time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 16:56:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 16:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHHt1-0002OV-EO; Mon, 09 Apr 2012 16:56:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1SHHt0-0002OQ-0a
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 16:56:14 +0000
Received: from [85.158.143.35:37936] by server-1.bemta-4.messagelabs.com id
	C1/BB-20925-DA4138F4; Mon, 09 Apr 2012 16:56:13 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1333990572!11862070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9325 invoked from network); 9 Apr 2012 16:56:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 16:56:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Apr 2012 17:56:12 +0100
Message-Id: <4F8322BB020000780008229D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Apr 2012 17:56:11 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <david.vrabel@citrix.com>,<konrad.wilk@oracle.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<20120406205909.GA26309@phenom.dumpdata.com>
In-Reply-To: <20120406205909.GA26309@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:04 PM >>>
>> With your new behaviour it will no longer possible to specify an
>> unlimited balloon but a limited number of initial pages.  This is
>> behaviour that Jan said he used.
>
>I am not sure I see the problem - I mean if one uses:
>
>dom0_mem=min:8G,max:16G
>
>I understand that we want to start at 8GB and if the user
>choose to - balloon up to 16GB.
>
>But doing this:
>
>dom0_mem=8G
>
>and allocating pagetables up to .. say 32GB, seems counter-intuive
>as the effect is similar to having no 'dom0_mem' except that the initial
>size is smaller.

What's counter intuitive here? There may not be a need - from the perspective
of the kernel - for a hard upper limit enforced by Xen (i.e. the pseudo infinity
we have right now may be quite fine).

Anyway, as said in the other reply already - unless this is to address a bug, I
don't see the point in changing behavior that has been that way for a pretty
long time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 17:51:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 17:51:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHIkB-00032D-Dj; Mon, 09 Apr 2012 17:51:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHIk9-000325-Ae
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 17:51:09 +0000
Received: from [85.158.139.83:19572] by server-1.bemta-5.messagelabs.com id
	12/40-28458-C81238F4; Mon, 09 Apr 2012 17:51:08 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333993866!23041477!1
X-Originating-IP: [98.138.91.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27771 invoked from network); 9 Apr 2012 17:51:06 -0000
Received: from nm20-vm2.bullet.mail.ne1.yahoo.com (HELO
	nm20-vm2.bullet.mail.ne1.yahoo.com) (98.138.91.208)
	by server-2.tower-182.messagelabs.com with SMTP;
	9 Apr 2012 17:51:06 -0000
Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 17:51:05 -0000
Received: from [98.138.89.166] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 17:51:05 -0000
Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 17:51:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 710429.77586.bm@omp1022.mail.ne1.yahoo.com
Received: (qmail 95895 invoked by uid 60001); 9 Apr 2012 17:51:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1333993865; bh=WoOYIz5BJoS6KsQuDnQA0pwFzIBozCca9S64CZekMKs=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=aBA63qoQU+HXhk5px3GWZoaHItxPBsl0Y+wadFEgQgGgBWe4J0Ecty6lhYZad059gAx/eM9GAYbB/s/9/NWih8XaivmcUbQcwONoHKnaOGyCPlKi0mx9Vibz0C5m1LK/XATkj/DFEZC453KnSogkSedEkC9Ye6L8dFVQFRcSOzY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=QpBG+l8dty5dVU22yO/HV0CJMICsA2fj0C5aoBpy0oLKDU2bMfXWy4M5M4Z3mxB5GkLBnCK05HJGbbCoVIzw+aLvUWHPTY/VDfOrkORwXmf5gHjcBm/LiYC3kHk/w8NlIo0MYnKaG/Xf1Bm8masBpUOvv1vTtIH52ciyRWaKFuE=;
X-YMail-OSG: 0T.f3.cVM1lb0ljRTrkV.C_e1TCbNKyu4xoWEBgtU.2EI2S
	2x0T8nyy4xbobCAWL0FkBp_gU70EyjrnzU4iLMd2GXNl3PFqsqZMf.LCkABr
	Dc2Qvy2kGA5AUv1kob0Ig1lOPfWEJa9DDleLejWNXgVm.TsGGG_aHt5NDeZJ
	_o2wp9ZJGUlkjMoaZCuOghwIfUPhd7_Sdu83MhEo6lwZejQG9Ufg.2M8Z0dc
	_yEzfu5wPip96bmDHidZ4ITon2qjOkFuUhdWhnW6_rMMubUf7E1H8vhQeM21
	gOrMKz4CTUcqeg0jbjJpsbAz61XwXpgBTVVcSutiledKEt2mPPOYdG3dQj8u
	cQZoDOOjPYxWGGt8whDMmBJt1kkwilDw_8ijwqVibNCB2b.2dlviYR7pcT7y
	W4ouqmym1kH0IHOnFOA_YDSpGN3RbkeLlmsfOleDTICItGqG9azi8IhPRrXp
	XffO0owBWdG4-
Received: from [128.173.237.43] by web124504.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 10:51:05 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
Message-ID: <1333993865.95130.YahooMailNeo@web124504.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 10:51:05 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

I am curious how I can properly support hypercall continuation and wait_event. I have a dedicated VCPU in a domain which makes a special hypercall, and the hypercall waits for certain event to arrive. I am using queues available in Xen, so wait_event will be invoked in the hypercall once its ready to accept events. However, my understanding that even though I have a dedicated VCPU for this hypercall, I still may need to support hypercall continuation properly. (Is this the case?) So, my question is how exactly the need for hypercall preemption may affect wait_event() and wait() operations, and where would I need to do hypercall_preempt_check()?

Thank you!
Ruslan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 17:51:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 17:51:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHIkB-00032D-Dj; Mon, 09 Apr 2012 17:51:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHIk9-000325-Ae
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 17:51:09 +0000
Received: from [85.158.139.83:19572] by server-1.bemta-5.messagelabs.com id
	12/40-28458-C81238F4; Mon, 09 Apr 2012 17:51:08 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1333993866!23041477!1
X-Originating-IP: [98.138.91.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27771 invoked from network); 9 Apr 2012 17:51:06 -0000
Received: from nm20-vm2.bullet.mail.ne1.yahoo.com (HELO
	nm20-vm2.bullet.mail.ne1.yahoo.com) (98.138.91.208)
	by server-2.tower-182.messagelabs.com with SMTP;
	9 Apr 2012 17:51:06 -0000
Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 17:51:05 -0000
Received: from [98.138.89.166] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 17:51:05 -0000
Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 17:51:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 710429.77586.bm@omp1022.mail.ne1.yahoo.com
Received: (qmail 95895 invoked by uid 60001); 9 Apr 2012 17:51:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1333993865; bh=WoOYIz5BJoS6KsQuDnQA0pwFzIBozCca9S64CZekMKs=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=aBA63qoQU+HXhk5px3GWZoaHItxPBsl0Y+wadFEgQgGgBWe4J0Ecty6lhYZad059gAx/eM9GAYbB/s/9/NWih8XaivmcUbQcwONoHKnaOGyCPlKi0mx9Vibz0C5m1LK/XATkj/DFEZC453KnSogkSedEkC9Ye6L8dFVQFRcSOzY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=QpBG+l8dty5dVU22yO/HV0CJMICsA2fj0C5aoBpy0oLKDU2bMfXWy4M5M4Z3mxB5GkLBnCK05HJGbbCoVIzw+aLvUWHPTY/VDfOrkORwXmf5gHjcBm/LiYC3kHk/w8NlIo0MYnKaG/Xf1Bm8masBpUOvv1vTtIH52ciyRWaKFuE=;
X-YMail-OSG: 0T.f3.cVM1lb0ljRTrkV.C_e1TCbNKyu4xoWEBgtU.2EI2S
	2x0T8nyy4xbobCAWL0FkBp_gU70EyjrnzU4iLMd2GXNl3PFqsqZMf.LCkABr
	Dc2Qvy2kGA5AUv1kob0Ig1lOPfWEJa9DDleLejWNXgVm.TsGGG_aHt5NDeZJ
	_o2wp9ZJGUlkjMoaZCuOghwIfUPhd7_Sdu83MhEo6lwZejQG9Ufg.2M8Z0dc
	_yEzfu5wPip96bmDHidZ4ITon2qjOkFuUhdWhnW6_rMMubUf7E1H8vhQeM21
	gOrMKz4CTUcqeg0jbjJpsbAz61XwXpgBTVVcSutiledKEt2mPPOYdG3dQj8u
	cQZoDOOjPYxWGGt8whDMmBJt1kkwilDw_8ijwqVibNCB2b.2dlviYR7pcT7y
	W4ouqmym1kH0IHOnFOA_YDSpGN3RbkeLlmsfOleDTICItGqG9azi8IhPRrXp
	XffO0owBWdG4-
Received: from [128.173.237.43] by web124504.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 10:51:05 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
Message-ID: <1333993865.95130.YahooMailNeo@web124504.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 10:51:05 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

I am curious how I can properly support hypercall continuation and wait_event. I have a dedicated VCPU in a domain which makes a special hypercall, and the hypercall waits for certain event to arrive. I am using queues available in Xen, so wait_event will be invoked in the hypercall once its ready to accept events. However, my understanding that even though I have a dedicated VCPU for this hypercall, I still may need to support hypercall continuation properly. (Is this the case?) So, my question is how exactly the need for hypercall preemption may affect wait_event() and wait() operations, and where would I need to do hypercall_preempt_check()?

Thank you!
Ruslan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 18:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 18:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHJAa-0003J9-Ni; Mon, 09 Apr 2012 18:18:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHJAZ-0003J4-4V
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 18:18:27 +0000
Received: from [85.158.138.51:23602] by server-3.bemta-3.messagelabs.com id
	FF/FF-10665-2F7238F4; Mon, 09 Apr 2012 18:18:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333995505!10376368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 9 Apr 2012 18:18:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 18:18:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,394,1330905600"; d="scan'208";a="11834911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 18:18:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 19:18:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHJAW-0007jR-W6;
	Mon, 09 Apr 2012 18:18:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHJAW-0008KI-Vg;
	Mon, 09 Apr 2012 19:18:24 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12620-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 19:18:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12620: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12620 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12620/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 12557
 build-i386                    2 host-install(2)         broken REGR. vs. 12557
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install   fail in 12609 REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3 3 host-install(3) broken in 12609 REGR. vs. 12557

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12609
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 12609

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot            fail in 12609 never pass
 test-amd64-i386-pv            5 xen-boot              fail in 12609 never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot             fail in 12609 never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot              fail in 12609 never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot             fail in 12609 never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot          fail in 12609 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot      fail in 12609 never pass
 test-amd64-i386-win           5 xen-boot              fail in 12609 never pass
 test-amd64-i386-win-vcpus1    5 xen-boot              fail in 12609 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12609 never pass
 test-amd64-i386-xl-multivcpu  7 debian-install        fail in 12609 never pass
 test-i386-i386-pair        11 debian-install/dst_host fail in 12609 never pass
 test-i386-i386-xl             7 debian-install        fail in 12609 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12609 never pass
 test-i386-i386-win           16 leak-check/check      fail in 12609 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12609 never pass

version targeted for testing:
 linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 18:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 18:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHJAa-0003J9-Ni; Mon, 09 Apr 2012 18:18:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHJAZ-0003J4-4V
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 18:18:27 +0000
Received: from [85.158.138.51:23602] by server-3.bemta-3.messagelabs.com id
	FF/FF-10665-2F7238F4; Mon, 09 Apr 2012 18:18:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333995505!10376368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI1MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 9 Apr 2012 18:18:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 18:18:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,394,1330905600"; d="scan'208";a="11834911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 18:18:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 19:18:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHJAW-0007jR-W6;
	Mon, 09 Apr 2012 18:18:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHJAW-0008KI-Vg;
	Mon, 09 Apr 2012 19:18:24 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12620-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 19:18:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12620: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12620 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12620/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 12557
 build-i386                    2 host-install(2)         broken REGR. vs. 12557
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install   fail in 12609 REGR. vs. 12557
 test-amd64-i386-xend-winxpsp3 3 host-install(3) broken in 12609 REGR. vs. 12557

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12609
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 12609

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot            fail in 12609 never pass
 test-amd64-i386-pv            5 xen-boot              fail in 12609 never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot             fail in 12609 never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot              fail in 12609 never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot             fail in 12609 never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot          fail in 12609 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot      fail in 12609 never pass
 test-amd64-i386-win           5 xen-boot              fail in 12609 never pass
 test-amd64-i386-win-vcpus1    5 xen-boot              fail in 12609 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12609 never pass
 test-amd64-i386-xl-multivcpu  7 debian-install        fail in 12609 never pass
 test-i386-i386-pair        11 debian-install/dst_host fail in 12609 never pass
 test-i386-i386-xl             7 debian-install        fail in 12609 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12609 never pass
 test-i386-i386-win           16 leak-check/check      fail in 12609 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12609 never pass

version targeted for testing:
 linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 18:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 18:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHJjN-0003XH-KN; Mon, 09 Apr 2012 18:54:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHJjM-0003XB-3J
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 18:54:24 +0000
Received: from [85.158.143.35:11729] by server-2.bemta-4.messagelabs.com id
	2A/26-17550-F50338F4; Mon, 09 Apr 2012 18:54:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333997662!4146055!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21674 invoked from network); 9 Apr 2012 18:54:22 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 18:54:22 -0000
Received: by wibhn6 with SMTP id hn6so2283561wib.14
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 11:54:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tdyrLWytwlgyYILnHys4gTgK/qjgq/ktyCs2Ooekmf4=;
	b=EspHYJXSP6yyqOM4A8qQFmhivT7IS2FRIl2mM6C6ZmzzlNhMI60yM1IaFRoU5bICHN
	ELN1YGefdCrDk1A3SWr6sITFMslvSTbGHTHlOq8M6UFIKRUlIhT8EsKy2loZqr7wbayM
	rQsOfheB2kOzb0h38jiCGdwe7oLd6D4DwFAuDrMbKHSlHgT500xdL5mR9eMEb9v9yrKJ
	qL2WHeJvWruxOVRmYJBe0PsJXj1TQCksQRgL3aGFTIYiWxJUVkbN47EFOaadzhpXMC9G
	WJet4vkjkFz6Ew3kLPIuRxMCzBsBX2UKHXpenKRfV5o2WdV9dQq/7eVd7AjdqYeyKTB4
	OuTA==
Received: by 10.180.100.230 with SMTP id fb6mr384219wib.3.1333997661613;
	Mon, 09 Apr 2012 11:54:21 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id e6sm32247237wix.8.2012.04.09.11.54.19
	(version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 11:54:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Apr 2012 19:54:22 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA8EEEE.303F1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0Wgiz90b0h9huNCEm1pJLBcYdddA==
In-Reply-To: <1333993865.95130.YahooMailNeo@web124504.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Hi
> 
> I am curious how I can properly support hypercall continuation and wait_event.
> I have a dedicated VCPU in a domain which makes a special hypercall, and the
> hypercall waits for certain event to arrive. I am using queues available in
> Xen, so wait_event will be invoked in the hypercall once its ready to accept
> events. However, my understanding that even though I have a dedicated VCPU for
> this hypercall, I still may need to support hypercall continuation properly.
> (Is this the case?) So, my question is how exactly the need for hypercall

No it's not the case, the old hypercall_create_continuation() mechanism does
not need to be used with wait_event().

 -- Keir

> preemption may affect wait_event() and wait() operations, and where would I
> need to do hypercall_preempt_check()?
> 
> Thank you!
> Ruslan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 18:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 18:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHJjN-0003XH-KN; Mon, 09 Apr 2012 18:54:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHJjM-0003XB-3J
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 18:54:24 +0000
Received: from [85.158.143.35:11729] by server-2.bemta-4.messagelabs.com id
	2A/26-17550-F50338F4; Mon, 09 Apr 2012 18:54:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1333997662!4146055!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21674 invoked from network); 9 Apr 2012 18:54:22 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 18:54:22 -0000
Received: by wibhn6 with SMTP id hn6so2283561wib.14
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 11:54:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tdyrLWytwlgyYILnHys4gTgK/qjgq/ktyCs2Ooekmf4=;
	b=EspHYJXSP6yyqOM4A8qQFmhivT7IS2FRIl2mM6C6ZmzzlNhMI60yM1IaFRoU5bICHN
	ELN1YGefdCrDk1A3SWr6sITFMslvSTbGHTHlOq8M6UFIKRUlIhT8EsKy2loZqr7wbayM
	rQsOfheB2kOzb0h38jiCGdwe7oLd6D4DwFAuDrMbKHSlHgT500xdL5mR9eMEb9v9yrKJ
	qL2WHeJvWruxOVRmYJBe0PsJXj1TQCksQRgL3aGFTIYiWxJUVkbN47EFOaadzhpXMC9G
	WJet4vkjkFz6Ew3kLPIuRxMCzBsBX2UKHXpenKRfV5o2WdV9dQq/7eVd7AjdqYeyKTB4
	OuTA==
Received: by 10.180.100.230 with SMTP id fb6mr384219wib.3.1333997661613;
	Mon, 09 Apr 2012 11:54:21 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id e6sm32247237wix.8.2012.04.09.11.54.19
	(version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 11:54:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Apr 2012 19:54:22 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA8EEEE.303F1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0Wgiz90b0h9huNCEm1pJLBcYdddA==
In-Reply-To: <1333993865.95130.YahooMailNeo@web124504.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Hi
> 
> I am curious how I can properly support hypercall continuation and wait_event.
> I have a dedicated VCPU in a domain which makes a special hypercall, and the
> hypercall waits for certain event to arrive. I am using queues available in
> Xen, so wait_event will be invoked in the hypercall once its ready to accept
> events. However, my understanding that even though I have a dedicated VCPU for
> this hypercall, I still may need to support hypercall continuation properly.
> (Is this the case?) So, my question is how exactly the need for hypercall

No it's not the case, the old hypercall_create_continuation() mechanism does
not need to be used with wait_event().

 -- Keir

> preemption may affect wait_event() and wait() operations, and where would I
> need to do hypercall_preempt_check()?
> 
> Thank you!
> Ruslan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 19:13:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 19:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHK10-00040U-Rf; Mon, 09 Apr 2012 19:12:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve.prochniak@oracle.com>) id 1SHK0z-00040O-Va
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 19:12:38 +0000
Received: from [85.158.138.51:3999] by server-7.bemta-3.messagelabs.com id
	FA/8C-07528-5A4338F4; Mon, 09 Apr 2012 19:12:37 +0000
X-Env-Sender: steve.prochniak@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333998754!21350780!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5362 invoked from network); 9 Apr 2012 19:12:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Apr 2012 19:12:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39JCWVZ019446
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:12:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39JCVeN014452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:12:32 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39JCVdu032262
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 14:12:31 -0500
MIME-Version: 1.0
Message-ID: <7df0d150-21e5-48ba-b3a4-41ae7e45b4f7@default>
Date: Mon, 9 Apr 2012 12:09:19 -0700 (PDT)
From: Steve Prochniak <steve.prochniak@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
	<CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
	<20120406203152.GB15674@phenom.dumpdata.com>
In-Reply-To: <20120406203152.GB15674@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	11.8326.8341 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8334A1.0092,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
 appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I recall running into this problem while in development for a Network PV driver - though I don't recall if it was the TX or RX ring that would stall (maybe it was both or either).  During longevity testing, after days of nonstop traffic, something would go wrong and the interrupt would fail to clear.  This seemed to be a "after so many interrupts" bug, since halving the traffic would double the time necessary to reproduce.  At the time, we figured that we never saw this with the disk because it would have taken weeks to repro.

Mainly because of the length of time required to reproduce this, we never found out whether the problem was on the Dom0 or DomU side.  I worked around the problem by adding code that would detect that the condition was occurring, and then would trigger a reset of the event channel or interrupt.

Steve

-----Original Message-----
From: Konrad Rzeszutek Wilk 
Sent: Friday, April 06, 2012 4:32 PM
To: Vijay Chander
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues appreciated)

On Sat, Feb 25, 2012 at 07:46:36AM -0800, Vijay Chander wrote:
> If anybody encountered a similar situation as below where the netfront TX
> ring is stuck ,
> can you pls provide some pointers on how to get around this problem ?
> 
> This typically happens after about 2days of overnight traffic tests.

What kind of traffic? As in netperf for 48hrs? Is this from guest to guest
traffic or from outside host to the guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 19:13:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 19:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHK10-00040U-Rf; Mon, 09 Apr 2012 19:12:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve.prochniak@oracle.com>) id 1SHK0z-00040O-Va
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 19:12:38 +0000
Received: from [85.158.138.51:3999] by server-7.bemta-3.messagelabs.com id
	FA/8C-07528-5A4338F4; Mon, 09 Apr 2012 19:12:37 +0000
X-Env-Sender: steve.prochniak@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1333998754!21350780!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5362 invoked from network); 9 Apr 2012 19:12:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Apr 2012 19:12:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39JCWVZ019446
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:12:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39JCVeN014452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:12:32 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39JCVdu032262
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 14:12:31 -0500
MIME-Version: 1.0
Message-ID: <7df0d150-21e5-48ba-b3a4-41ae7e45b4f7@default>
Date: Mon, 9 Apr 2012 12:09:19 -0700 (PDT)
From: Steve Prochniak <steve.prochniak@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
	<CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
	<20120406203152.GB15674@phenom.dumpdata.com>
In-Reply-To: <20120406203152.GB15674@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	11.8326.8341 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8334A1.0092,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
 appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I recall running into this problem while in development for a Network PV driver - though I don't recall if it was the TX or RX ring that would stall (maybe it was both or either).  During longevity testing, after days of nonstop traffic, something would go wrong and the interrupt would fail to clear.  This seemed to be a "after so many interrupts" bug, since halving the traffic would double the time necessary to reproduce.  At the time, we figured that we never saw this with the disk because it would have taken weeks to repro.

Mainly because of the length of time required to reproduce this, we never found out whether the problem was on the Dom0 or DomU side.  I worked around the problem by adding code that would detect that the condition was occurring, and then would trigger a reset of the event channel or interrupt.

Steve

-----Original Message-----
From: Konrad Rzeszutek Wilk 
Sent: Friday, April 06, 2012 4:32 PM
To: Vijay Chander
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues appreciated)

On Sat, Feb 25, 2012 at 07:46:36AM -0800, Vijay Chander wrote:
> If anybody encountered a similar situation as below where the netfront TX
> ring is stuck ,
> can you pls provide some pointers on how to get around this problem ?
> 
> This typically happens after about 2days of overnight traffic tests.

What kind of traffic? As in netperf for 48hrs? Is this from guest to guest
traffic or from outside host to the guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 19:19:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 19:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHK74-0004DV-L1; Mon, 09 Apr 2012 19:18:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHK73-0004DP-GW
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 19:18:53 +0000
Received: from [193.109.254.147:54658] by server-4.bemta-14.messagelabs.com id
	F6/2F-11570-C16338F4; Mon, 09 Apr 2012 19:18:52 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333999131!3766589!1
X-Originating-IP: [98.138.229.102]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16591 invoked from network); 9 Apr 2012 19:18:51 -0000
Received: from nm35-vm6.bullet.mail.ne1.yahoo.com (HELO
	nm35-vm6.bullet.mail.ne1.yahoo.com) (98.138.229.102)
	by server-2.tower-27.messagelabs.com with SMTP;
	9 Apr 2012 19:18:51 -0000
Received: from [98.138.90.51] by nm35.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 19:18:50 -0000
Received: from [98.138.89.192] by tm4.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 19:18:50 -0000
Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 19:18:50 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 644161.10098.bm@omp1050.mail.ne1.yahoo.com
Received: (qmail 55125 invoked by uid 60001); 9 Apr 2012 19:18:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1333999130; bh=ObcqUxiaGegnsgZiILAnwY/eTVABubzyT3nEQK1o2m8=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=AA/ufVIO071oxUjnLyK19+ZZF7k4uE6vb4YSNauRC6RMFvQGNgveeDkO0KnH7/axx2MVSOIyg5oVumRAhah50neYr4WoI6ZkNPDR7p1dr13VZAaS0ybHkTgns9eE78ZJ6FhReMt6cAWQV6d9eodn4w+V8oTo8b9yy2Wu6V9LTGc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=6RMp3Fgv8tkT3pCPCnbIkAoWEpxH1cfV7u9Yo1wKCjuct6kb4iBRilCqY2pNpicWuBniT5HTfzgnM5rVnJ2oRiZMWQw5R4kQFvJiD1KjErK+dR+3yQlIM9Lf13PqKhlONeHdjNvYOyCNXAEewnyRkIXbddCq5V633kM4ru+VqqU=;
X-YMail-OSG: 65yDy10VM1mOtALjIUT0gY7Q8fI.UvlYCrdjz34J12biB9W
	TMOl9gVKoWm7YGPKyTjgDJYc5C9S301av5KUqQfbOH7p4V_G5rVW0XlDzYdu
	WLiwjQFsH3q3gu23OgvBym.BOrZoFst2BKb3yJ8b2qiVpEAyrvR59Y5scM.y
	Kly9GU8oxUV.BPrA8LobJMAwNmcaHkGoUe3ZGYeleuJpiEfCYvecxrdm3faZ
	BfOADDY4Ht29ykJB1ZTIJzdKehO2HNq38nXBrIPbXEkBjMEixdiGP0a.v7j9
	q0UndausoULfcu7BoMPfUtkv3fcHa6DafYKZF7uT4ko01VaIj.JSG5lkXLHs
	PfwAh7vUXvArc8HqyXkiwNix0AAEj0SzUGrKyPGrmJec2F9d6K6nkVgKytnO
	J0ycS_0paBQt8xzQMmshsObpOCrtYw7SJ6.IhHoWjkUwLJLdkUIIGs5kKohF
	pRCOBeb4eY95swdRsodTX1pn953QpoOFi9Q--
Received: from [128.173.237.43] by web124501.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 12:18:50 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1333993865.95130.YahooMailNeo@web124504.mail.ne1.yahoo.com>
	<CBA8EEEE.303F1%keir.xen@gmail.com>
Message-ID: <1333999130.48871.YahooMailNeo@web124501.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 12:18:50 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA8EEEE.303F1%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the reply. 

Since it can take arbitrarily long for an event to arrive (e.g., it is coming from a different guest on a user request), how do I need to handle this case?Does it mean that I only need to make sure that nothings get scheduled on this VCPU in the guest?
Also, it is not exactly clear to me how wait_event avoids the need for hypercall continuation. What about local_events_need_delivery() or softirq_pending()? Are they going to be handled by wait_event internally?

Ruslan






----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: 
Sent: Monday, April 9, 2012 6:54 PM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Hi
> 
> I am curious how I can properly support hypercall continuation and wait_event.
> I have a dedicated VCPU in a domain which makes a special hypercall, and the
> hypercall waits for certain event to arrive. I am using queues available in
> Xen, so wait_event will be invoked in the hypercall once its ready to accept
> events. However, my understanding that even though I have a dedicated VCPU for
> this hypercall, I still may need to support hypercall continuation properly.
> (Is this the case?) So, my question is how exactly the need for hypercall

No it's not the case, the old hypercall_create_continuation() mechanism does
not need to be used with wait_event().

-- Keir

> preemption may affect wait_event() and wait() operations, and where would I
> need to do hypercall_preempt_check()?
> 
> Thank you!
> Ruslan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 19:19:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 19:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHK74-0004DV-L1; Mon, 09 Apr 2012 19:18:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHK73-0004DP-GW
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 19:18:53 +0000
Received: from [193.109.254.147:54658] by server-4.bemta-14.messagelabs.com id
	F6/2F-11570-C16338F4; Mon, 09 Apr 2012 19:18:52 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1333999131!3766589!1
X-Originating-IP: [98.138.229.102]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16591 invoked from network); 9 Apr 2012 19:18:51 -0000
Received: from nm35-vm6.bullet.mail.ne1.yahoo.com (HELO
	nm35-vm6.bullet.mail.ne1.yahoo.com) (98.138.229.102)
	by server-2.tower-27.messagelabs.com with SMTP;
	9 Apr 2012 19:18:51 -0000
Received: from [98.138.90.51] by nm35.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 19:18:50 -0000
Received: from [98.138.89.192] by tm4.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 19:18:50 -0000
Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 19:18:50 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 644161.10098.bm@omp1050.mail.ne1.yahoo.com
Received: (qmail 55125 invoked by uid 60001); 9 Apr 2012 19:18:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1333999130; bh=ObcqUxiaGegnsgZiILAnwY/eTVABubzyT3nEQK1o2m8=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=AA/ufVIO071oxUjnLyK19+ZZF7k4uE6vb4YSNauRC6RMFvQGNgveeDkO0KnH7/axx2MVSOIyg5oVumRAhah50neYr4WoI6ZkNPDR7p1dr13VZAaS0ybHkTgns9eE78ZJ6FhReMt6cAWQV6d9eodn4w+V8oTo8b9yy2Wu6V9LTGc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=6RMp3Fgv8tkT3pCPCnbIkAoWEpxH1cfV7u9Yo1wKCjuct6kb4iBRilCqY2pNpicWuBniT5HTfzgnM5rVnJ2oRiZMWQw5R4kQFvJiD1KjErK+dR+3yQlIM9Lf13PqKhlONeHdjNvYOyCNXAEewnyRkIXbddCq5V633kM4ru+VqqU=;
X-YMail-OSG: 65yDy10VM1mOtALjIUT0gY7Q8fI.UvlYCrdjz34J12biB9W
	TMOl9gVKoWm7YGPKyTjgDJYc5C9S301av5KUqQfbOH7p4V_G5rVW0XlDzYdu
	WLiwjQFsH3q3gu23OgvBym.BOrZoFst2BKb3yJ8b2qiVpEAyrvR59Y5scM.y
	Kly9GU8oxUV.BPrA8LobJMAwNmcaHkGoUe3ZGYeleuJpiEfCYvecxrdm3faZ
	BfOADDY4Ht29ykJB1ZTIJzdKehO2HNq38nXBrIPbXEkBjMEixdiGP0a.v7j9
	q0UndausoULfcu7BoMPfUtkv3fcHa6DafYKZF7uT4ko01VaIj.JSG5lkXLHs
	PfwAh7vUXvArc8HqyXkiwNix0AAEj0SzUGrKyPGrmJec2F9d6K6nkVgKytnO
	J0ycS_0paBQt8xzQMmshsObpOCrtYw7SJ6.IhHoWjkUwLJLdkUIIGs5kKohF
	pRCOBeb4eY95swdRsodTX1pn953QpoOFi9Q--
Received: from [128.173.237.43] by web124501.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 12:18:50 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1333993865.95130.YahooMailNeo@web124504.mail.ne1.yahoo.com>
	<CBA8EEEE.303F1%keir.xen@gmail.com>
Message-ID: <1333999130.48871.YahooMailNeo@web124501.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 12:18:50 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA8EEEE.303F1%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the reply. 

Since it can take arbitrarily long for an event to arrive (e.g., it is coming from a different guest on a user request), how do I need to handle this case?Does it mean that I only need to make sure that nothings get scheduled on this VCPU in the guest?
Also, it is not exactly clear to me how wait_event avoids the need for hypercall continuation. What about local_events_need_delivery() or softirq_pending()? Are they going to be handled by wait_event internally?

Ruslan






----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: 
Sent: Monday, April 9, 2012 6:54 PM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Hi
> 
> I am curious how I can properly support hypercall continuation and wait_event.
> I have a dedicated VCPU in a domain which makes a special hypercall, and the
> hypercall waits for certain event to arrive. I am using queues available in
> Xen, so wait_event will be invoked in the hypercall once its ready to accept
> events. However, my understanding that even though I have a dedicated VCPU for
> this hypercall, I still may need to support hypercall continuation properly.
> (Is this the case?) So, my question is how exactly the need for hypercall

No it's not the case, the old hypercall_create_continuation() mechanism does
not need to be used with wait_event().

-- Keir

> preemption may affect wait_event() and wait() operations, and where would I
> need to do hypercall_preempt_check()?
> 
> Thank you!
> Ruslan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 19:25:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 19:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHKCm-0004OO-Ja; Mon, 09 Apr 2012 19:24:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve.prochniak@oracle.com>) id 1SHKCk-0004OE-Tq
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 19:24:47 +0000
Received: from [85.158.138.51:30619] by server-11.bemta-3.messagelabs.com id
	DC/B1-28543-E77338F4; Mon, 09 Apr 2012 19:24:46 +0000
X-Env-Sender: steve.prochniak@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333999483!10381591!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26544 invoked from network); 9 Apr 2012 19:24:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 19:24:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39JOfFJ004420
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:24:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39JOeDL026830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:24:41 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39JOeoP024451
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 14:24:40 -0500
MIME-Version: 1.0
Message-ID: <67227b6c-9596-488a-91f0-7912b1c05385@default>
Date: Mon, 9 Apr 2012 12:21:28 -0700 (PDT)
From: Steve Prochniak <steve.prochniak@oracle.com>
To: xen-devel@lists.xensource.com
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
	<CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
	<20120406203152.GB15674@phenom.dumpdata.com>
	<7df0d150-21e5-48ba-b3a4-41ae7e45b4f7@default>
In-Reply-To: <7df0d150-21e5-48ba-b3a4-41ae7e45b4f7@default>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	11.8326.8341 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F83377B.000B,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
 appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After digging up the code, when we observed this issue it was specific to the RX ring and it took about 4 days of nonstop traffic to reproduce.  So perhaps the issues are not related.

-----Original Message-----
From: Steve Prochniak 
Sent: Monday, April 09, 2012 3:09 PM
To: Konrad Wilk
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues appreciated)

I recall running into this problem while in development for a Network PV driver - though I don't recall if it was the TX or RX ring that would stall (maybe it was both or either).  During longevity testing, after days of nonstop traffic, something would go wrong and the interrupt would fail to clear.  This seemed to be a "after so many interrupts" bug, since halving the traffic would double the time necessary to reproduce.  At the time, we figured that we never saw this with the disk because it would have taken weeks to repro.

Mainly because of the length of time required to reproduce this, we never found out whether the problem was on the Dom0 or DomU side.  I worked around the problem by adding code that would detect that the condition was occurring, and then would trigger a reset of the event channel or interrupt.

Steve

-----Original Message-----
From: Konrad Rzeszutek Wilk 
Sent: Friday, April 06, 2012 4:32 PM
To: Vijay Chander
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues appreciated)

On Sat, Feb 25, 2012 at 07:46:36AM -0800, Vijay Chander wrote:
> If anybody encountered a similar situation as below where the netfront TX
> ring is stuck ,
> can you pls provide some pointers on how to get around this problem ?
> 
> This typically happens after about 2days of overnight traffic tests.

What kind of traffic? As in netperf for 48hrs? Is this from guest to guest
traffic or from outside host to the guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 19:25:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 19:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHKCm-0004OO-Ja; Mon, 09 Apr 2012 19:24:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve.prochniak@oracle.com>) id 1SHKCk-0004OE-Tq
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 19:24:47 +0000
Received: from [85.158.138.51:30619] by server-11.bemta-3.messagelabs.com id
	DC/B1-28543-E77338F4; Mon, 09 Apr 2012 19:24:46 +0000
X-Env-Sender: steve.prochniak@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1333999483!10381591!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26544 invoked from network); 9 Apr 2012 19:24:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 19:24:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39JOfFJ004420
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:24:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39JOeDL026830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 19:24:41 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39JOeoP024451
	for <xen-devel@lists.xensource.com>; Mon, 9 Apr 2012 14:24:40 -0500
MIME-Version: 1.0
Message-ID: <67227b6c-9596-488a-91f0-7912b1c05385@default>
Date: Mon, 9 Apr 2012 12:21:28 -0700 (PDT)
From: Steve Prochniak <steve.prochniak@oracle.com>
To: xen-devel@lists.xensource.com
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
	<CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
	<20120406203152.GB15674@phenom.dumpdata.com>
	<7df0d150-21e5-48ba-b3a4-41ae7e45b4f7@default>
In-Reply-To: <7df0d150-21e5-48ba-b3a4-41ae7e45b4f7@default>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	11.8326.8341 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F83377B.000B,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
 appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After digging up the code, when we observed this issue it was specific to the RX ring and it took about 4 days of nonstop traffic to reproduce.  So perhaps the issues are not related.

-----Original Message-----
From: Steve Prochniak 
Sent: Monday, April 09, 2012 3:09 PM
To: Konrad Wilk
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues appreciated)

I recall running into this problem while in development for a Network PV driver - though I don't recall if it was the TX or RX ring that would stall (maybe it was both or either).  During longevity testing, after days of nonstop traffic, something would go wrong and the interrupt would fail to clear.  This seemed to be a "after so many interrupts" bug, since halving the traffic would double the time necessary to reproduce.  At the time, we figured that we never saw this with the disk because it would have taken weeks to repro.

Mainly because of the length of time required to reproduce this, we never found out whether the problem was on the Dom0 or DomU side.  I worked around the problem by adding code that would detect that the condition was occurring, and then would trigger a reset of the event channel or interrupt.

Steve

-----Original Message-----
From: Konrad Rzeszutek Wilk 
Sent: Friday, April 06, 2012 4:32 PM
To: Vijay Chander
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues appreciated)

On Sat, Feb 25, 2012 at 07:46:36AM -0800, Vijay Chander wrote:
> If anybody encountered a similar situation as below where the netfront TX
> ring is stuck ,
> can you pls provide some pointers on how to get around this problem ?
> 
> This typically happens after about 2days of overnight traffic tests.

What kind of traffic? As in netperf for 48hrs? Is this from guest to guest
traffic or from outside host to the guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 20:09:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 20:09:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHKtx-0004iQ-1y; Mon, 09 Apr 2012 20:09:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHKtw-0004iL-Fj
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 20:09:24 +0000
Received: from [85.158.138.51:11656] by server-11.bemta-3.messagelabs.com id
	41/34-28543-3F1438F4; Mon, 09 Apr 2012 20:09:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334002162!17193887!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32037 invoked from network); 9 Apr 2012 20:09:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 20:09:22 -0000
Received: by werp12 with SMTP id p12so3559914wer.32
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 13:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ugmsrewgfOc8VdnXN/iArCXodLol+LMQsEYUA97yUSo=;
	b=sSLO8f91VER29+6LPacCOos45DakdfROzh2vfoMeaEQDv6R/QqiS+4F5OzyhRudAAD
	oY9y7rI19vrIioygytCnRCaks3R9PccJY0yuqAt2K/CD67+lzct0Xn/OoD0SjbihdSmJ
	O8ldHdddOcNDC5f/sI+MPN7HCyAeDuvt2C5ZbKxAMDoz150Mv60hkTmnY/WENQrJayMD
	GPtuc8gP3u3iCIbVe6ns5M7+ePM9goINuXd0+VJZq9cFfbplPMR3sxFcw5GF2PbWVhTc
	TtPGRYkJRjCYXOPkI1I6XsAL2BwKxsH41QAAYU0HiA2y3lHbVzXNDPZDxb56hmgI/YSD
	lAPA==
Received: by 10.180.92.228 with SMTP id cp4mr763789wib.2.1334002162349;
	Mon, 09 Apr 2012 13:09:22 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id gg2sm52715362wib.7.2012.04.09.13.09.21
	(version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 13:09:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Apr 2012 21:09:19 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA9007F.3040B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0WjKVpjYXL4kn/IEmniXkllqeTNw==
In-Reply-To: <1333999130.48871.YahooMailNeo@web124501.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Thanks for the reply.
> 
> Since it can take arbitrarily long for an event to arrive (e.g., it is coming
> from a different guest on a user request), how do I need to handle this
> case?Does it mean that I only need to make sure that nothings get scheduled on
> this VCPU in the guest?

Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
sleep within wait_event within the hypercall context. Hence you must not
hold any hypervisor spinlocks either, for example.

> Also, it is not exactly clear to me how wait_event avoids the need for
> hypercall continuation. What about local_events_need_delivery() or
> softirq_pending()? Are they going to be handled by wait_event internally?

Your VCPU gets descheduled. Hence softirq_pending() is not your concern for
the duration that you're descheduled. And if local_event_need_delivery(),
that's too bad, they have to wait for the vcpu to wake up on the event.

 -- Keir

> Ruslan
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: 
> Sent: Monday, April 9, 2012 6:54 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> 
> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> 
>> Hi
>> 
>> I am curious how I can properly support hypercall continuation and
>> wait_event.
>> I have a dedicated VCPU in a domain which makes a special hypercall, and the
>> hypercall waits for certain event to arrive. I am using queues available in
>> Xen, so wait_event will be invoked in the hypercall once its ready to accept
>> events. However, my understanding that even though I have a dedicated VCPU
>> for
>> this hypercall, I still may need to support hypercall continuation properly.
>> (Is this the case?) So, my question is how exactly the need for hypercall
> 
> No it's not the case, the old hypercall_create_continuation() mechanism does
> not need to be used with wait_event().
> 
> -- Keir
> 
>> preemption may affect wait_event() and wait() operations, and where would I
>> need to do hypercall_preempt_check()?
>> 
>> Thank you!
>> Ruslan
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 20:09:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 20:09:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHKtx-0004iQ-1y; Mon, 09 Apr 2012 20:09:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHKtw-0004iL-Fj
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 20:09:24 +0000
Received: from [85.158.138.51:11656] by server-11.bemta-3.messagelabs.com id
	41/34-28543-3F1438F4; Mon, 09 Apr 2012 20:09:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334002162!17193887!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32037 invoked from network); 9 Apr 2012 20:09:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 20:09:22 -0000
Received: by werp12 with SMTP id p12so3559914wer.32
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 13:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ugmsrewgfOc8VdnXN/iArCXodLol+LMQsEYUA97yUSo=;
	b=sSLO8f91VER29+6LPacCOos45DakdfROzh2vfoMeaEQDv6R/QqiS+4F5OzyhRudAAD
	oY9y7rI19vrIioygytCnRCaks3R9PccJY0yuqAt2K/CD67+lzct0Xn/OoD0SjbihdSmJ
	O8ldHdddOcNDC5f/sI+MPN7HCyAeDuvt2C5ZbKxAMDoz150Mv60hkTmnY/WENQrJayMD
	GPtuc8gP3u3iCIbVe6ns5M7+ePM9goINuXd0+VJZq9cFfbplPMR3sxFcw5GF2PbWVhTc
	TtPGRYkJRjCYXOPkI1I6XsAL2BwKxsH41QAAYU0HiA2y3lHbVzXNDPZDxb56hmgI/YSD
	lAPA==
Received: by 10.180.92.228 with SMTP id cp4mr763789wib.2.1334002162349;
	Mon, 09 Apr 2012 13:09:22 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id gg2sm52715362wib.7.2012.04.09.13.09.21
	(version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 13:09:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Apr 2012 21:09:19 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA9007F.3040B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0WjKVpjYXL4kn/IEmniXkllqeTNw==
In-Reply-To: <1333999130.48871.YahooMailNeo@web124501.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Thanks for the reply.
> 
> Since it can take arbitrarily long for an event to arrive (e.g., it is coming
> from a different guest on a user request), how do I need to handle this
> case?Does it mean that I only need to make sure that nothings get scheduled on
> this VCPU in the guest?

Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
sleep within wait_event within the hypercall context. Hence you must not
hold any hypervisor spinlocks either, for example.

> Also, it is not exactly clear to me how wait_event avoids the need for
> hypercall continuation. What about local_events_need_delivery() or
> softirq_pending()? Are they going to be handled by wait_event internally?

Your VCPU gets descheduled. Hence softirq_pending() is not your concern for
the duration that you're descheduled. And if local_event_need_delivery(),
that's too bad, they have to wait for the vcpu to wake up on the event.

 -- Keir

> Ruslan
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: 
> Sent: Monday, April 9, 2012 6:54 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> 
> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> 
>> Hi
>> 
>> I am curious how I can properly support hypercall continuation and
>> wait_event.
>> I have a dedicated VCPU in a domain which makes a special hypercall, and the
>> hypercall waits for certain event to arrive. I am using queues available in
>> Xen, so wait_event will be invoked in the hypercall once its ready to accept
>> events. However, my understanding that even though I have a dedicated VCPU
>> for
>> this hypercall, I still may need to support hypercall continuation properly.
>> (Is this the case?) So, my question is how exactly the need for hypercall
> 
> No it's not the case, the old hypercall_create_continuation() mechanism does
> not need to be used with wait_event().
> 
> -- Keir
> 
>> preemption may affect wait_event() and wait() operations, and where would I
>> need to do hypercall_preempt_check()?
>> 
>> Thank you!
>> Ruslan
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 20:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 20:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHL3j-0004tJ-4c; Mon, 09 Apr 2012 20:19:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHL3h-0004tD-W2
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 20:19:30 +0000
Received: from [85.158.138.51:47547] by server-7.bemta-3.messagelabs.com id
	0B/58-07528-054438F4; Mon, 09 Apr 2012 20:19:28 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334002766!21207444!1
X-Originating-IP: [98.138.91.62]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8369 invoked from network); 9 Apr 2012 20:19:27 -0000
Received: from nm13-vm1.bullet.mail.ne1.yahoo.com (HELO
	nm13-vm1.bullet.mail.ne1.yahoo.com) (98.138.91.62)
	by server-14.tower-174.messagelabs.com with SMTP;
	9 Apr 2012 20:19:27 -0000
Received: from [98.138.90.57] by nm13.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 20:16:29 -0000
Received: from [98.138.87.7] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 20:16:29 -0000
Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 20:16:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 748617.71067.bm@omp1007.mail.ne1.yahoo.com
Received: (qmail 52657 invoked by uid 60001); 9 Apr 2012 20:16:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334002589; bh=pSiOJoznunVWpG+4L7kH5Wz7n+JvQbbmST7L4DNoAts=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=e5mz2ygFapdxlUb0Wslo7nmitVebJ0DKap7Nb/B/PjqNx9vWODunyjFomvSdgr5m9ajj256GVvw/jU+j73tJr/jz3SmT3j2FZm/cfcfb5AZ42IKRmtq7ieOBNUVNEf5LevjmfANxf1ONZ6onkaNi/mDfewRXUq7HuuFToxSG//4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=p1pXTudCK6Ov0WK1CiiqxRpX0Du7Qk/rQhdCvPPUBHrFWSLn6Av6c0YF/4OgQ4horDog6zRv4PWWNyEdFKRvQ4aH7HBqrCMX7pRNRl/c2cXYEFSYVdonJUfhXZ6G5pvudI415YsfThQyAB4X+OoDVatmUkUuE1Z29Na3KUR6jYk=;
X-YMail-OSG: fqy87xUVM1kIhpVRr30JaJNPxnHl_njXNS5eDcdndnkyw5N
	LvqeivYD.97i6HGbJ6nxsHKx77YPWvjpqKXjAplOSVugUFVDu8db.Eb7lihd
	iWCS9tF5pr5ellmw_EgUt1EuKR3YI0FahOKxfD2Thex.1aDoymhOtWczyzAB
	V77BsY1QTkeFFh_kAmJu.VYS1.OtkxwsfTw05iN4UsLP8mdN_oxhr94JEak9
	Fl825sucrjEe3EhgUs06bE1qw9htkmOUsHQi8WWGHIyTAtF648YMQ28cphG5
	Aqqpda.qnCBdNQFrhE81gkckzLnGgBP.nOECcBBCOBfI5mDtsLqbGmFlbCJl
	g26tG4hSaBhu.FSJwqs.wqMKe1wzPGn_tT2Z5ff4bDVW526wCeig5o2FMT3J
	.4ql86KfEvUCX1B06HEhfn2uI10092u2gR4mcU0Av5dvFbwhNpb1xGi0iGGb
	b4m4JnuUjtORTELJxhATOlNaLEjvVNKiLzw--
Received: from [128.173.237.43] by web124502.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 13:16:29 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1333999130.48871.YahooMailNeo@web124501.mail.ne1.yahoo.com>
	<CBA9007F.3040B%keir.xen@gmail.com>
Message-ID: <1334002589.51814.YahooMailNeo@web124502.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 13:16:29 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA9007F.3040B%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir,

Thanks for your replies! Just one more question about local_event_need_delivery(). Under what (common) conditions I would expect to have local events that need delivery?

Ruslan



----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: 
Sent: Monday, April 9, 2012 8:09 PM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Thanks for the reply.
> 
> Since it can take arbitrarily long for an event to arrive (e.g., it is coming
> from a different guest on a user request), how do I need to handle this
> case?Does it mean that I only need to make sure that nothings get scheduled on
> this VCPU in the guest?

Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
sleep within wait_event within the hypercall context. Hence you must not
hold any hypervisor spinlocks either, for example.

> Also, it is not exactly clear to me how wait_event avoids the need for
> hypercall continuation. What about local_events_need_delivery() or
> softirq_pending()? Are they going to be handled by wait_event internally?

Your VCPU gets descheduled. Hence softirq_pending() is not your concern for
the duration that you're descheduled. And if local_event_need_delivery(),
that's too bad, they have to wait for the vcpu to wake up on the event.

-- Keir

> Ruslan
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: 
> Sent: Monday, April 9, 2012 6:54 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> 
> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> 
>> Hi
>> 
>> I am curious how I can properly support hypercall continuation and
>> wait_event.
>> I have a dedicated VCPU in a domain which makes a special hypercall, and the
>> hypercall waits for certain event to arrive. I am using queues available in
>> Xen, so wait_event will be invoked in the hypercall once its ready to accept
>> events. However, my understanding that even though I have a dedicated VCPU
>> for
>> this hypercall, I still may need to support hypercall continuation properly.
>> (Is this the case?) So, my question is how exactly the need for hypercall
> 
> No it's not the case, the old hypercall_create_continuation() mechanism does
> not need to be used with wait_event().
> 
> -- Keir
> 
>> preemption may affect wait_event() and wait() operations, and where would I
>> need to do hypercall_preempt_check()?
>> 
>> Thank you!
>> Ruslan
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 20:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 20:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHL3j-0004tJ-4c; Mon, 09 Apr 2012 20:19:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHL3h-0004tD-W2
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 20:19:30 +0000
Received: from [85.158.138.51:47547] by server-7.bemta-3.messagelabs.com id
	0B/58-07528-054438F4; Mon, 09 Apr 2012 20:19:28 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334002766!21207444!1
X-Originating-IP: [98.138.91.62]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8369 invoked from network); 9 Apr 2012 20:19:27 -0000
Received: from nm13-vm1.bullet.mail.ne1.yahoo.com (HELO
	nm13-vm1.bullet.mail.ne1.yahoo.com) (98.138.91.62)
	by server-14.tower-174.messagelabs.com with SMTP;
	9 Apr 2012 20:19:27 -0000
Received: from [98.138.90.57] by nm13.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 20:16:29 -0000
Received: from [98.138.87.7] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 20:16:29 -0000
Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 20:16:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 748617.71067.bm@omp1007.mail.ne1.yahoo.com
Received: (qmail 52657 invoked by uid 60001); 9 Apr 2012 20:16:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334002589; bh=pSiOJoznunVWpG+4L7kH5Wz7n+JvQbbmST7L4DNoAts=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=e5mz2ygFapdxlUb0Wslo7nmitVebJ0DKap7Nb/B/PjqNx9vWODunyjFomvSdgr5m9ajj256GVvw/jU+j73tJr/jz3SmT3j2FZm/cfcfb5AZ42IKRmtq7ieOBNUVNEf5LevjmfANxf1ONZ6onkaNi/mDfewRXUq7HuuFToxSG//4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=p1pXTudCK6Ov0WK1CiiqxRpX0Du7Qk/rQhdCvPPUBHrFWSLn6Av6c0YF/4OgQ4horDog6zRv4PWWNyEdFKRvQ4aH7HBqrCMX7pRNRl/c2cXYEFSYVdonJUfhXZ6G5pvudI415YsfThQyAB4X+OoDVatmUkUuE1Z29Na3KUR6jYk=;
X-YMail-OSG: fqy87xUVM1kIhpVRr30JaJNPxnHl_njXNS5eDcdndnkyw5N
	LvqeivYD.97i6HGbJ6nxsHKx77YPWvjpqKXjAplOSVugUFVDu8db.Eb7lihd
	iWCS9tF5pr5ellmw_EgUt1EuKR3YI0FahOKxfD2Thex.1aDoymhOtWczyzAB
	V77BsY1QTkeFFh_kAmJu.VYS1.OtkxwsfTw05iN4UsLP8mdN_oxhr94JEak9
	Fl825sucrjEe3EhgUs06bE1qw9htkmOUsHQi8WWGHIyTAtF648YMQ28cphG5
	Aqqpda.qnCBdNQFrhE81gkckzLnGgBP.nOECcBBCOBfI5mDtsLqbGmFlbCJl
	g26tG4hSaBhu.FSJwqs.wqMKe1wzPGn_tT2Z5ff4bDVW526wCeig5o2FMT3J
	.4ql86KfEvUCX1B06HEhfn2uI10092u2gR4mcU0Av5dvFbwhNpb1xGi0iGGb
	b4m4JnuUjtORTELJxhATOlNaLEjvVNKiLzw--
Received: from [128.173.237.43] by web124502.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 13:16:29 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1333999130.48871.YahooMailNeo@web124501.mail.ne1.yahoo.com>
	<CBA9007F.3040B%keir.xen@gmail.com>
Message-ID: <1334002589.51814.YahooMailNeo@web124502.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 13:16:29 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA9007F.3040B%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir,

Thanks for your replies! Just one more question about local_event_need_delivery(). Under what (common) conditions I would expect to have local events that need delivery?

Ruslan



----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: 
Sent: Monday, April 9, 2012 8:09 PM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Thanks for the reply.
> 
> Since it can take arbitrarily long for an event to arrive (e.g., it is coming
> from a different guest on a user request), how do I need to handle this
> case?Does it mean that I only need to make sure that nothings get scheduled on
> this VCPU in the guest?

Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
sleep within wait_event within the hypercall context. Hence you must not
hold any hypervisor spinlocks either, for example.

> Also, it is not exactly clear to me how wait_event avoids the need for
> hypercall continuation. What about local_events_need_delivery() or
> softirq_pending()? Are they going to be handled by wait_event internally?

Your VCPU gets descheduled. Hence softirq_pending() is not your concern for
the duration that you're descheduled. And if local_event_need_delivery(),
that's too bad, they have to wait for the vcpu to wake up on the event.

-- Keir

> Ruslan
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: 
> Sent: Monday, April 9, 2012 6:54 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> 
> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> 
>> Hi
>> 
>> I am curious how I can properly support hypercall continuation and
>> wait_event.
>> I have a dedicated VCPU in a domain which makes a special hypercall, and the
>> hypercall waits for certain event to arrive. I am using queues available in
>> Xen, so wait_event will be invoked in the hypercall once its ready to accept
>> events. However, my understanding that even though I have a dedicated VCPU
>> for
>> this hypercall, I still may need to support hypercall continuation properly.
>> (Is this the case?) So, my question is how exactly the need for hypercall
> 
> No it's not the case, the old hypercall_create_continuation() mechanism does
> not need to be used with wait_event().
> 
> -- Keir
> 
>> preemption may affect wait_event() and wait() operations, and where would I
>> need to do hypercall_preempt_check()?
>> 
>> Thank you!
>> Ruslan
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 20:59:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 20:59:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHLfv-00057a-9u; Mon, 09 Apr 2012 20:58:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHLfu-00057V-0r
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 20:58:58 +0000
Received: from [85.158.143.35:11025] by server-3.bemta-4.messagelabs.com id
	81/CD-05853-19D438F4; Mon, 09 Apr 2012 20:58:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334005136!12477512!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19566 invoked from network); 9 Apr 2012 20:58:56 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 20:58:56 -0000
Received: by wgbds1 with SMTP id ds1so2623997wgb.2
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 13:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nxJBxNbtrpHC2rnzxIkGquJtp+UpeQEx//vK/IeNGxU=;
	b=VnX4LZO9jJu+sIDzp0Icy0rASipF6DvjCM3zm+VNHOThsSOQA/1j2Zpa0bGF7JBzJx
	IDEZg3WTo2meJqgcsGU+1hikTV0doGo/nKW9+A2I1OLjd5FW1JoH4PG+p1eWFmGWWOkO
	4OXCbZ2U9gkz1RyKmbFmtRXIx3lKX3A2TKv3D/JwYHuN1etTx/trhJm6svZdpfwUaYC/
	rqOSXP95oTv5Fei51/hLlbNU1MMBzCgWjAgnEW0oHyJaFM7J9Cja+w4R6CrlASseZPrY
	up0t98FbgfJC0wrF06Z3uw5u0Ll/dvEQnSa49K1s/KyFO/rHHcJWymiwt0ULRuTF154F
	DqHw==
Received: by 10.180.105.194 with SMTP id go2mr929195wib.22.1334005136281;
	Mon, 09 Apr 2012 13:58:56 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id b3sm33010805wib.4.2012.04.09.13.58.54
	(version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 13:58:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Apr 2012 21:58:51 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA90C1B.30417%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0Wk5DcrY2G8TEH5kWoZVlgg4cKLQ==
In-Reply-To: <1334002589.51814.YahooMailNeo@web124502.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It means the vcpu has an interrupt pending (in the pv case, that means an
event channel has a pending event).


On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> 
> Thanks for your replies! Just one more question about
> local_event_need_delivery(). Under what (common) conditions I would expect to
> have local events that need delivery?
> 
> Ruslan
> 
> 
> 
> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: 
> Sent: Monday, April 9, 2012 8:09 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> 
> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> 
>> Thanks for the reply.
>> 
>> Since it can take arbitrarily long for an event to arrive (e.g., it is coming
>> from a different guest on a user request), how do I need to handle this
>> case?Does it mean that I only need to make sure that nothings get scheduled
>> on
>> this VCPU in the guest?
> 
> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
> sleep within wait_event within the hypercall context. Hence you must not
> hold any hypervisor spinlocks either, for example.
> 
>> Also, it is not exactly clear to me how wait_event avoids the need for
>> hypercall continuation. What about local_events_need_delivery() or
>> softirq_pending()? Are they going to be handled by wait_event internally?
> 
> Your VCPU gets descheduled. Hence softirq_pending() is not your concern for
> the duration that you're descheduled. And if local_event_need_delivery(),
> that's too bad, they have to wait for the vcpu to wake up on the event.
> 
> -- Keir
> 
>> Ruslan
>> 
>> 
>> 
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: 
>> Sent: Monday, April 9, 2012 6:54 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> 
>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> 
>>> Hi
>>> 
>>> I am curious how I can properly support hypercall continuation and
>>> wait_event.
>>> I have a dedicated VCPU in a domain which makes a special hypercall, and the
>>> hypercall waits for certain event to arrive. I am using queues available in
>>> Xen, so wait_event will be invoked in the hypercall once its ready to accept
>>> events. However, my understanding that even though I have a dedicated VCPU
>>> for
>>> this hypercall, I still may need to support hypercall continuation properly.
>>> (Is this the case?) So, my question is how exactly the need for hypercall
>> 
>> No it's not the case, the old hypercall_create_continuation() mechanism does
>> not need to be used with wait_event().
>> 
>> -- Keir
>> 
>>> preemption may affect wait_event() and wait() operations, and where would I
>>> need to do hypercall_preempt_check()?
>>> 
>>> Thank you!
>>> Ruslan
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 20:59:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 20:59:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHLfv-00057a-9u; Mon, 09 Apr 2012 20:58:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHLfu-00057V-0r
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 20:58:58 +0000
Received: from [85.158.143.35:11025] by server-3.bemta-4.messagelabs.com id
	81/CD-05853-19D438F4; Mon, 09 Apr 2012 20:58:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334005136!12477512!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19566 invoked from network); 9 Apr 2012 20:58:56 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 20:58:56 -0000
Received: by wgbds1 with SMTP id ds1so2623997wgb.2
	for <xen-devel@lists.xen.org>; Mon, 09 Apr 2012 13:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nxJBxNbtrpHC2rnzxIkGquJtp+UpeQEx//vK/IeNGxU=;
	b=VnX4LZO9jJu+sIDzp0Icy0rASipF6DvjCM3zm+VNHOThsSOQA/1j2Zpa0bGF7JBzJx
	IDEZg3WTo2meJqgcsGU+1hikTV0doGo/nKW9+A2I1OLjd5FW1JoH4PG+p1eWFmGWWOkO
	4OXCbZ2U9gkz1RyKmbFmtRXIx3lKX3A2TKv3D/JwYHuN1etTx/trhJm6svZdpfwUaYC/
	rqOSXP95oTv5Fei51/hLlbNU1MMBzCgWjAgnEW0oHyJaFM7J9Cja+w4R6CrlASseZPrY
	up0t98FbgfJC0wrF06Z3uw5u0Ll/dvEQnSa49K1s/KyFO/rHHcJWymiwt0ULRuTF154F
	DqHw==
Received: by 10.180.105.194 with SMTP id go2mr929195wib.22.1334005136281;
	Mon, 09 Apr 2012 13:58:56 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id b3sm33010805wib.4.2012.04.09.13.58.54
	(version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 13:58:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Apr 2012 21:58:51 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA90C1B.30417%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0Wk5DcrY2G8TEH5kWoZVlgg4cKLQ==
In-Reply-To: <1334002589.51814.YahooMailNeo@web124502.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It means the vcpu has an interrupt pending (in the pv case, that means an
event channel has a pending event).


On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> 
> Thanks for your replies! Just one more question about
> local_event_need_delivery(). Under what (common) conditions I would expect to
> have local events that need delivery?
> 
> Ruslan
> 
> 
> 
> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: 
> Sent: Monday, April 9, 2012 8:09 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> 
> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> 
>> Thanks for the reply.
>> 
>> Since it can take arbitrarily long for an event to arrive (e.g., it is coming
>> from a different guest on a user request), how do I need to handle this
>> case?Does it mean that I only need to make sure that nothings get scheduled
>> on
>> this VCPU in the guest?
> 
> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
> sleep within wait_event within the hypercall context. Hence you must not
> hold any hypervisor spinlocks either, for example.
> 
>> Also, it is not exactly clear to me how wait_event avoids the need for
>> hypercall continuation. What about local_events_need_delivery() or
>> softirq_pending()? Are they going to be handled by wait_event internally?
> 
> Your VCPU gets descheduled. Hence softirq_pending() is not your concern for
> the duration that you're descheduled. And if local_event_need_delivery(),
> that's too bad, they have to wait for the vcpu to wake up on the event.
> 
> -- Keir
> 
>> Ruslan
>> 
>> 
>> 
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: 
>> Sent: Monday, April 9, 2012 6:54 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> 
>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> 
>>> Hi
>>> 
>>> I am curious how I can properly support hypercall continuation and
>>> wait_event.
>>> I have a dedicated VCPU in a domain which makes a special hypercall, and the
>>> hypercall waits for certain event to arrive. I am using queues available in
>>> Xen, so wait_event will be invoked in the hypercall once its ready to accept
>>> events. However, my understanding that even though I have a dedicated VCPU
>>> for
>>> this hypercall, I still may need to support hypercall continuation properly.
>>> (Is this the case?) So, my question is how exactly the need for hypercall
>> 
>> No it's not the case, the old hypercall_create_continuation() mechanism does
>> not need to be used with wait_event().
>> 
>> -- Keir
>> 
>>> preemption may affect wait_event() and wait() operations, and where would I
>>> need to do hypercall_preempt_check()?
>>> 
>>> Thank you!
>>> Ruslan
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 21:20:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 21:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHM08-0005Lo-5N; Mon, 09 Apr 2012 21:19:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHM05-0005Li-PW
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 21:19:50 +0000
Received: from [85.158.139.83:8683] by server-2.bemta-5.messagelabs.com id
	90/E9-17016-472538F4; Mon, 09 Apr 2012 21:19:48 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334006387!23057180!1
X-Originating-IP: [98.138.91.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1077 invoked from network); 9 Apr 2012 21:19:47 -0000
Received: from nm8-vm1.bullet.mail.ne1.yahoo.com (HELO
	nm8-vm1.bullet.mail.ne1.yahoo.com) (98.138.91.65)
	by server-12.tower-182.messagelabs.com with SMTP;
	9 Apr 2012 21:19:47 -0000
Received: from [98.138.90.48] by nm8.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 21:19:46 -0000
Received: from [98.138.87.8] by tm1.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 21:19:46 -0000
Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 21:19:46 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 768333.10707.bm@omp1008.mail.ne1.yahoo.com
Received: (qmail 85404 invoked by uid 60001); 9 Apr 2012 21:19:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334006386; bh=tJV9BQOzRhNg79yIknUh/WGqv0aXTrTpCiFlsmPX/pM=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=hZB91Xm7XkejSeNoU111so0Fa8kTNVN+Z+YZypgVwnBHzAs9d1Im7TN7aFEqhvgKrhMgvQeGeEi6pFOiucU3HF0dyDeOFfMxQMfDHLucDhwmqamRYXUo96tJnGgMT64uqD2vcvAL5ZTApps153ckWW103Hshbb6Cv13ojXYM/eA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=4RMvk7EDapwpsP24W2fN6vJcMqhz/G8k2rw/XfHrl0W3Q4v7j+CyYpr0jen/N5QiLbVZZGwGLgIHHan02e+x5WgaBVG6QLIdj/uhOR/VFM11gg5b3Tm6hIF59TcmXYZZQzt5c0viarRzpQZS7zoy9cXLICKpnJT9IhKKXXDwJwE=;
X-YMail-OSG: V5stMyEVM1kJqvJmxVExjBNn8EcQCLZnTXYAyB97HUujhzE
	V_qHA6yYFUqJO1JNGGBKvK.Z.3hPd8_xQWO_0yHMOUgKZOL1HYOD7YVrVFWg
	XxwFWuzEzF7usSQ3fgm7AJn4Ga_lVrw5FLCEAvFGLT6XjZ59okGSJy.cQuZO
	BrfLMKRSao9pxeExDlU9QhtyvAABgwmA7yhmAcglmaSHTeuww_zn26JCCKeW
	PGjhwggxGPJhAazXpp_paqZOgEC.kkvYAgrE_Wr0ASqICiyzt4Y8YNCCfsGt
	IyvrV5WEOdgGz3ezrSbjCzojZz.BA79RPkyB9r.gqVN3h_7.rd.OAZO7cYXd
	Afy9BsIY.MMNow06K9XDypvFQDEVCYqMQnMy.JI65q7scqGssbxUu9tnhxP4
	8dKbu6arySiujLCqWqbVKhVEDt0sCNCtUWjoKOioGrYESWng.xSJDtGPFlRH
	adM.iSD2tH.3xjsZ7BPMl97p0rE7pXXp5CA--
Received: from [128.173.237.43] by web124506.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 14:19:46 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1334002589.51814.YahooMailNeo@web124502.mail.ne1.yahoo.com>
	<CBA90C1B.30417%keir.xen@gmail.com>
Message-ID: <1334006386.85318.YahooMailNeo@web124506.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 14:19:46 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA90C1B.30417%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir,

Thanks again! When I used the scheme I have described, I periodically recei=
ve kernel errors as shown below. Notice that I use HVM domain and also 'iso=
lcpus' as a Linux kernel option to prevent a dedicated VCPU from being norm=
ally used. A hypercall is being made from a special kernel thread (which is=
 bind to the dedicated VCPU before the call).

What could be the reason of these messages? Looks like it is something rela=
ted to a timer.


[ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>] defau=
lt_send_IPI_mask_sequence_phys+0x95/0xce
[ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
[ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX: 00000000000=
00020
[ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI: 00000000000=
00300
[ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09: ffffffff816=
3eb20
[ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12: 00000000000=
0d602
[ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15: ffffffff816=
3eb20
[ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000) knlG=
S:0000000000000000
[ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4: 00000000000=
006a0
[ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000=
00000
[ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400
[ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, task=
 ffff88007c4f1650)
[ 1039.319957] Stack:
[ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88 000000=
0000002710
[ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001 ffffff=
ff8161a4c0
[ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98 ffffff=
ff8101bb81
[ 1039.319957] Call Trace:
[ 1039.319957]=A0 <IRQ>
[ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
[ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x4b/=
0x6e
[ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
[ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
[ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
[ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
[ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
[ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
[ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
[ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0xb4
[ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0xb4
[ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0xb4
[ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
[ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
[ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
[ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
[ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
[ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
[ 1039.319957]=A0 <EOI>
[ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
[ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
[ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
[ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
[ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1



Thanks,
Ruslan


----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <x=
en-devel@lists.xen.org>
Cc: =

Sent: Monday, April 9, 2012 8:58 PM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

It means the vcpu has an interrupt pending (in the pv case, that means an
event channel has a pending event).


On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> Thanks for your replies! Just one more question about
> local_event_need_delivery(). Under what (common) conditions I would expec=
t to
> have local events that need delivery?
> =

> Ruslan
> =

> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Monday, April 9, 2012 8:09 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Thanks for the reply.
>> =

>> Since it can take arbitrarily long for an event to arrive (e.g., it is c=
oming
>> from a different guest on a user request), how do I need to handle this
>> case?Does it mean that I only need to make sure that nothings get schedu=
led
>> on
>> this VCPU in the guest?
> =

> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
> sleep within wait_event within the hypercall context. Hence you must not
> hold any hypervisor spinlocks either, for example.
> =

>> Also, it is not exactly clear to me how wait_event avoids the need for
>> hypercall continuation. What about local_events_need_delivery() or
>> softirq_pending()? Are they going to be handled by wait_event internally?
> =

> Your VCPU gets descheduled. Hence softirq_pending() is not your concern f=
or
> the duration that you're descheduled. And if local_event_need_delivery(),
> that's too bad, they have to wait for the vcpu to wake up on the event.
> =

> -- Keir
> =

>> Ruslan
>> =

>> =

>> =

>> =

>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 6:54 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Hi
>>> =

>>> I am curious how I can properly support hypercall continuation and
>>> wait_event.
>>> I have a dedicated VCPU in a domain which makes a special hypercall, an=
d the
>>> hypercall waits for certain event to arrive. I am using queues availabl=
e in
>>> Xen, so wait_event will be invoked in the hypercall once its ready to a=
ccept
>>> events. However, my understanding that even though I have a dedicated V=
CPU
>>> for
>>> this hypercall, I still may need to support hypercall continuation prop=
erly.
>>> (Is this the case?) So, my question is how exactly the need for hyperca=
ll
>> =

>> No it's not the case, the old hypercall_create_continuation() mechanism =
does
>> not need to be used with wait_event().
>> =

>> -- Keir
>> =

>>> preemption may affect wait_event() and wait() operations, and where wou=
ld I
>>> need to do hypercall_preempt_check()?
>>> =

>>> Thank you!
>>> Ruslan
>>> =

>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 21:20:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 21:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHM08-0005Lo-5N; Mon, 09 Apr 2012 21:19:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SHM05-0005Li-PW
	for xen-devel@lists.xen.org; Mon, 09 Apr 2012 21:19:50 +0000
Received: from [85.158.139.83:8683] by server-2.bemta-5.messagelabs.com id
	90/E9-17016-472538F4; Mon, 09 Apr 2012 21:19:48 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334006387!23057180!1
X-Originating-IP: [98.138.91.65]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1077 invoked from network); 9 Apr 2012 21:19:47 -0000
Received: from nm8-vm1.bullet.mail.ne1.yahoo.com (HELO
	nm8-vm1.bullet.mail.ne1.yahoo.com) (98.138.91.65)
	by server-12.tower-182.messagelabs.com with SMTP;
	9 Apr 2012 21:19:47 -0000
Received: from [98.138.90.48] by nm8.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 21:19:46 -0000
Received: from [98.138.87.8] by tm1.bullet.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 21:19:46 -0000
Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP;
	09 Apr 2012 21:19:46 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 768333.10707.bm@omp1008.mail.ne1.yahoo.com
Received: (qmail 85404 invoked by uid 60001); 9 Apr 2012 21:19:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334006386; bh=tJV9BQOzRhNg79yIknUh/WGqv0aXTrTpCiFlsmPX/pM=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=hZB91Xm7XkejSeNoU111so0Fa8kTNVN+Z+YZypgVwnBHzAs9d1Im7TN7aFEqhvgKrhMgvQeGeEi6pFOiucU3HF0dyDeOFfMxQMfDHLucDhwmqamRYXUo96tJnGgMT64uqD2vcvAL5ZTApps153ckWW103Hshbb6Cv13ojXYM/eA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=4RMvk7EDapwpsP24W2fN6vJcMqhz/G8k2rw/XfHrl0W3Q4v7j+CyYpr0jen/N5QiLbVZZGwGLgIHHan02e+x5WgaBVG6QLIdj/uhOR/VFM11gg5b3Tm6hIF59TcmXYZZQzt5c0viarRzpQZS7zoy9cXLICKpnJT9IhKKXXDwJwE=;
X-YMail-OSG: V5stMyEVM1kJqvJmxVExjBNn8EcQCLZnTXYAyB97HUujhzE
	V_qHA6yYFUqJO1JNGGBKvK.Z.3hPd8_xQWO_0yHMOUgKZOL1HYOD7YVrVFWg
	XxwFWuzEzF7usSQ3fgm7AJn4Ga_lVrw5FLCEAvFGLT6XjZ59okGSJy.cQuZO
	BrfLMKRSao9pxeExDlU9QhtyvAABgwmA7yhmAcglmaSHTeuww_zn26JCCKeW
	PGjhwggxGPJhAazXpp_paqZOgEC.kkvYAgrE_Wr0ASqICiyzt4Y8YNCCfsGt
	IyvrV5WEOdgGz3ezrSbjCzojZz.BA79RPkyB9r.gqVN3h_7.rd.OAZO7cYXd
	Afy9BsIY.MMNow06K9XDypvFQDEVCYqMQnMy.JI65q7scqGssbxUu9tnhxP4
	8dKbu6arySiujLCqWqbVKhVEDt0sCNCtUWjoKOioGrYESWng.xSJDtGPFlRH
	adM.iSD2tH.3xjsZ7BPMl97p0rE7pXXp5CA--
Received: from [128.173.237.43] by web124506.mail.ne1.yahoo.com via HTTP;
	Mon, 09 Apr 2012 14:19:46 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1334002589.51814.YahooMailNeo@web124502.mail.ne1.yahoo.com>
	<CBA90C1B.30417%keir.xen@gmail.com>
Message-ID: <1334006386.85318.YahooMailNeo@web124506.mail.ne1.yahoo.com>
Date: Mon, 9 Apr 2012 14:19:46 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA90C1B.30417%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir,

Thanks again! When I used the scheme I have described, I periodically recei=
ve kernel errors as shown below. Notice that I use HVM domain and also 'iso=
lcpus' as a Linux kernel option to prevent a dedicated VCPU from being norm=
ally used. A hypercall is being made from a special kernel thread (which is=
 bind to the dedicated VCPU before the call).

What could be the reason of these messages? Looks like it is something rela=
ted to a timer.


[ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>] defau=
lt_send_IPI_mask_sequence_phys+0x95/0xce
[ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
[ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX: 00000000000=
00020
[ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI: 00000000000=
00300
[ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09: ffffffff816=
3eb20
[ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12: 00000000000=
0d602
[ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15: ffffffff816=
3eb20
[ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000) knlG=
S:0000000000000000
[ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4: 00000000000=
006a0
[ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000=
00000
[ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400
[ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, task=
 ffff88007c4f1650)
[ 1039.319957] Stack:
[ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88 000000=
0000002710
[ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001 ffffff=
ff8161a4c0
[ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98 ffffff=
ff8101bb81
[ 1039.319957] Call Trace:
[ 1039.319957]=A0 <IRQ>
[ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
[ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x4b/=
0x6e
[ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
[ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
[ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
[ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
[ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
[ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
[ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
[ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0xb4
[ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0xb4
[ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0xb4
[ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
[ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
[ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
[ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
[ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
[ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
[ 1039.319957]=A0 <EOI>
[ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
[ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
[ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
[ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
[ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1



Thanks,
Ruslan


----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <x=
en-devel@lists.xen.org>
Cc: =

Sent: Monday, April 9, 2012 8:58 PM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

It means the vcpu has an interrupt pending (in the pv case, that means an
event channel has a pending event).


On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> Thanks for your replies! Just one more question about
> local_event_need_delivery(). Under what (common) conditions I would expec=
t to
> have local events that need delivery?
> =

> Ruslan
> =

> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Monday, April 9, 2012 8:09 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Thanks for the reply.
>> =

>> Since it can take arbitrarily long for an event to arrive (e.g., it is c=
oming
>> from a different guest on a user request), how do I need to handle this
>> case?Does it mean that I only need to make sure that nothings get schedu=
led
>> on
>> this VCPU in the guest?
> =

> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
> sleep within wait_event within the hypercall context. Hence you must not
> hold any hypervisor spinlocks either, for example.
> =

>> Also, it is not exactly clear to me how wait_event avoids the need for
>> hypercall continuation. What about local_events_need_delivery() or
>> softirq_pending()? Are they going to be handled by wait_event internally?
> =

> Your VCPU gets descheduled. Hence softirq_pending() is not your concern f=
or
> the duration that you're descheduled. And if local_event_need_delivery(),
> that's too bad, they have to wait for the vcpu to wake up on the event.
> =

> -- Keir
> =

>> Ruslan
>> =

>> =

>> =

>> =

>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 6:54 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Hi
>>> =

>>> I am curious how I can properly support hypercall continuation and
>>> wait_event.
>>> I have a dedicated VCPU in a domain which makes a special hypercall, an=
d the
>>> hypercall waits for certain event to arrive. I am using queues availabl=
e in
>>> Xen, so wait_event will be invoked in the hypercall once its ready to a=
ccept
>>> events. However, my understanding that even though I have a dedicated V=
CPU
>>> for
>>> this hypercall, I still may need to support hypercall continuation prop=
erly.
>>> (Is this the case?) So, my question is how exactly the need for hyperca=
ll
>> =

>> No it's not the case, the old hypercall_create_continuation() mechanism =
does
>> not need to be used with wait_event().
>> =

>> -- Keir
>> =

>>> preemption may affect wait_event() and wait() operations, and where wou=
ld I
>>> need to do hypercall_preempt_check()?
>>> =

>>> Thank you!
>>> Ruslan
>>> =

>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 21:38:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 21:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHMI3-0005Y4-23; Mon, 09 Apr 2012 21:38:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SHMI2-0005Xz-5V
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 21:38:22 +0000
Received: from [85.158.138.51:64518] by server-1.bemta-3.messagelabs.com id
	EC/2D-04539-DC6538F4; Mon, 09 Apr 2012 21:38:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334007499!21213063!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17934 invoked from network); 9 Apr 2012 21:38:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 21:38:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39LcFaq000518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Apr 2012 21:38:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39LcED8020324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Apr 2012 21:38:15 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39LcDK7024219; Mon, 9 Apr 2012 16:38:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Apr 2012 14:38:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B02C4032C; Mon,  9 Apr 2012 17:33:29 -0400 (EDT)
Date: Mon, 9 Apr 2012 17:33:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20120409213329.GC12783@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<4F7AE321020000780007C456@nat28.tlf.novell.com>
	<20120406210117.GB26309@phenom.dumpdata.com>
	<4F831ED7020000780008228C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F831ED7020000780008228C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F8356C9.003B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 09, 2012 at 05:39:35PM +0100, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:06 PM >>>
> >On Tue, Apr 03, 2012 at 10:46:41AM +0100, Jan Beulich wrote:
> >> >>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
> >> > With your new behaviour it will no longer possible to specify an
> >> > unlimited balloon but a limited number of initial pages.  This is
> >> > behaviour that Jan said he used.
> >> 
> >> An unlimited balloon was never possible afaict (as that would have
> >> implied setting up an "infinite" number of struct page instances at
> >> boot time.
> >> 
> >> What I'm using is "dom0_mem=-<num>M" together with the kernel
> >> option "mem=<num>G", such that max-balloon > initial alloc (usually
> >> I set max-balloon to approximately the amount of memory in the
> >> system, so the upper limit is "infinite" in the sense that I can't go
> >> higher anyway, but it's not truly infinity).
> >
> >Couldn't you do the same thing with 'dom0_mem=X,max:Y'
> 
> That would be possible (albeit not exactly identical in behavior). But my
> main point in the discussion was to not modify existing behavior without
> actual need to (including the desire to not have to modify dozens of
> command lines).

Right. I don't want to modify the hypervisor - my goal is to bring the pvops
kernel in line with how XenOLinux does it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 21:38:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 21:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHMI3-0005Y4-23; Mon, 09 Apr 2012 21:38:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SHMI2-0005Xz-5V
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 21:38:22 +0000
Received: from [85.158.138.51:64518] by server-1.bemta-3.messagelabs.com id
	EC/2D-04539-DC6538F4; Mon, 09 Apr 2012 21:38:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334007499!21213063!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17934 invoked from network); 9 Apr 2012 21:38:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Apr 2012 21:38:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39LcFaq000518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Apr 2012 21:38:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39LcED8020324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Apr 2012 21:38:15 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39LcDK7024219; Mon, 9 Apr 2012 16:38:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Apr 2012 14:38:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B02C4032C; Mon,  9 Apr 2012 17:33:29 -0400 (EDT)
Date: Mon, 9 Apr 2012 17:33:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20120409213329.GC12783@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<4F7AE321020000780007C456@nat28.tlf.novell.com>
	<20120406210117.GB26309@phenom.dumpdata.com>
	<4F831ED7020000780008228C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F831ED7020000780008228C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F8356C9.003B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 09, 2012 at 05:39:35PM +0100, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:06 PM >>>
> >On Tue, Apr 03, 2012 at 10:46:41AM +0100, Jan Beulich wrote:
> >> >>> On 03.04.12 at 10:58, David Vrabel <david.vrabel@citrix.com> wrote:
> >> > With your new behaviour it will no longer possible to specify an
> >> > unlimited balloon but a limited number of initial pages.  This is
> >> > behaviour that Jan said he used.
> >> 
> >> An unlimited balloon was never possible afaict (as that would have
> >> implied setting up an "infinite" number of struct page instances at
> >> boot time.
> >> 
> >> What I'm using is "dom0_mem=-<num>M" together with the kernel
> >> option "mem=<num>G", such that max-balloon > initial alloc (usually
> >> I set max-balloon to approximately the amount of memory in the
> >> system, so the upper limit is "infinite" in the sense that I can't go
> >> higher anyway, but it's not truly infinity).
> >
> >Couldn't you do the same thing with 'dom0_mem=X,max:Y'
> 
> That would be possible (albeit not exactly identical in behavior). But my
> main point in the discussion was to not modify existing behavior without
> actual need to (including the desire to not have to modify dozens of
> command lines).

Right. I don't want to modify the hypervisor - my goal is to bring the pvops
kernel in line with how XenOLinux does it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 21:54:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 21:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHMXh-0005vE-53; Mon, 09 Apr 2012 21:54:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SHMXg-0005v9-H8
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 21:54:32 +0000
Received: from [85.158.143.99:52115] by server-1.bemta-4.messagelabs.com id
	C6/16-20925-79A538F4; Mon, 09 Apr 2012 21:54:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334008469!13150421!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYzMzM0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13565 invoked from network); 9 Apr 2012 21:54:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Apr 2012 21:54:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39LsRWr022092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Apr 2012 21:54:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39LsQXl008624
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Apr 2012 21:54:26 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39LsPEm018516; Mon, 9 Apr 2012 16:54:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Apr 2012 14:54:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A0D64032C; Mon,  9 Apr 2012 17:49:40 -0400 (EDT)
Date: Mon, 9 Apr 2012 17:49:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20120409214940.GD12783@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<20120406205909.GA26309@phenom.dumpdata.com>
	<4F8322BB020000780008229D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8322BB020000780008229D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F835A94.0035,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 09, 2012 at 05:56:11PM +0100, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:04 PM >>>
> >> With your new behaviour it will no longer possible to specify an
> >> unlimited balloon but a limited number of initial pages.  This is
> >> behaviour that Jan said he used.
> >
> >I am not sure I see the problem - I mean if one uses:
> >
> >dom0_mem=min:8G,max:16G
> >
> >I understand that we want to start at 8GB and if the user
> >choose to - balloon up to 16GB.
> >
> >But doing this:
> >
> >dom0_mem=8G
> >
> >and allocating pagetables up to .. say 32GB, seems counter-intuive
> >as the effect is similar to having no 'dom0_mem' except that the initial
> >size is smaller.
> 
> What's counter intuitive here? There may not be a need - from the perspective
> of the kernel - for a hard upper limit enforced by Xen (i.e. the pseudo infinity
> we have right now may be quite fine).

Counter intuitive in that when one uses 'dom0_mem=8G' it implies some clipping.
And with the pvops kernel we don't do any clipping - we allocate pagetables
up to the the limit of the E820 space. So on a 32GB box, we end up with pagetables
addressing 32GB, of which 24GB are balloon space.

> 
> Anyway, as said in the other reply already - unless this is to address a bug, I
> don't see the point in changing behavior that has been that way for a pretty
> long time.

The bug here is that if you say 'dom0_mem=max:4G' the amount of memory
that dom0 boots is not the same. It actually is smaller (by about one 1GB since
that is the amount of memort that gets ballooned out from the E820 gaps and E820
RESERVED/ACPI PFN spots). The first set of patches did this a bit ineptly, but the
next version populate's the P2M and M2P so you actually end up with 4GB of memory
in dom0 instead of the 3GB.

This is what we end up with without any dom0_mem argument:

2.6.32 SLES:
Memory: 7538688k/8079432k available (3971k kernel code, 8192k absent, 532300k reserved, 2491k data, 348k init)
MemTotal:        8063140 kB
MemFree:         7421504 kB
DirectMap4k:     8071240 kB
Domain-0                                     0  7873     4     r-----     20.3

3.3:
Memory: 6486452k/9208688k available (5825k kernel code, 1136060k absent, 1586176k reserved, 2890k data, 692k init)
MemTotal:        6716156 kB
MemFree:         6365696 kB
DirectMap4k:     8078192 kB
Domain-0                                     0  6774     4     r-----     26.0

3.3+patches:
Memory: 7621460k/9208688k available (5817k kernel code, 1136060k absent, 451168k reserved, 2899k data, 692k init)
MemTotal:        7849924 kB
MemFree:         7500748 kB
DirectMap4k:     8078192 kB
Domain-0                                     0  7883     4     r-----     11.9


and .. hm, I lost the outputs I had with dom0_mem=X, but this is what I get
with 3.3 and 3.3+this patch:

dom0_mem=1G
-Memory: 610884k/9435136k available (5817k kernel code, 1136060k absent, 7688192k reserved, 2899k data, 696k init)
+Memory: 724184k/1053064k available (5817k kernel code, 4552k absent, 324328k reserved, 2899k data, 696k init)
   
I think the SLES kernel has the same behavior, but will have to wait
until next week when I am back to be double sure.


 
When it comes to "infinite" balloon - I think the work that Daniel did
on using the memory hotplug mechanism to add memory is preferable. That
way pagetables are put in the newly added memory space.


> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 21:54:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 21:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHMXh-0005vE-53; Mon, 09 Apr 2012 21:54:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SHMXg-0005v9-H8
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 21:54:32 +0000
Received: from [85.158.143.99:52115] by server-1.bemta-4.messagelabs.com id
	C6/16-20925-79A538F4; Mon, 09 Apr 2012 21:54:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334008469!13150421!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDYzMzM0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13565 invoked from network); 9 Apr 2012 21:54:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Apr 2012 21:54:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39LsRWr022092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Apr 2012 21:54:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39LsQXl008624
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Apr 2012 21:54:26 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39LsPEm018516; Mon, 9 Apr 2012 16:54:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Apr 2012 14:54:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A0D64032C; Mon,  9 Apr 2012 17:49:40 -0400 (EDT)
Date: Mon, 9 Apr 2012 17:49:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20120409214940.GD12783@phenom.dumpdata.com>
References: <1333139850-28456-1-git-send-email-konrad.wilk@oracle.com>
	<1333139850-28456-7-git-send-email-konrad.wilk@oracle.com>
	<4F7ABBC4.4050106@citrix.com>
	<20120406205909.GA26309@phenom.dumpdata.com>
	<4F8322BB020000780008229D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8322BB020000780008229D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F835A94.0035,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/7] xen/setup: Make dom0_mem=XGB behavior
 be similar to classic Xen kernels.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 09, 2012 at 05:56:11PM +0100, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/06/12 11:04 PM >>>
> >> With your new behaviour it will no longer possible to specify an
> >> unlimited balloon but a limited number of initial pages.  This is
> >> behaviour that Jan said he used.
> >
> >I am not sure I see the problem - I mean if one uses:
> >
> >dom0_mem=min:8G,max:16G
> >
> >I understand that we want to start at 8GB and if the user
> >choose to - balloon up to 16GB.
> >
> >But doing this:
> >
> >dom0_mem=8G
> >
> >and allocating pagetables up to .. say 32GB, seems counter-intuive
> >as the effect is similar to having no 'dom0_mem' except that the initial
> >size is smaller.
> 
> What's counter intuitive here? There may not be a need - from the perspective
> of the kernel - for a hard upper limit enforced by Xen (i.e. the pseudo infinity
> we have right now may be quite fine).

Counter intuitive in that when one uses 'dom0_mem=8G' it implies some clipping.
And with the pvops kernel we don't do any clipping - we allocate pagetables
up to the the limit of the E820 space. So on a 32GB box, we end up with pagetables
addressing 32GB, of which 24GB are balloon space.

> 
> Anyway, as said in the other reply already - unless this is to address a bug, I
> don't see the point in changing behavior that has been that way for a pretty
> long time.

The bug here is that if you say 'dom0_mem=max:4G' the amount of memory
that dom0 boots is not the same. It actually is smaller (by about one 1GB since
that is the amount of memort that gets ballooned out from the E820 gaps and E820
RESERVED/ACPI PFN spots). The first set of patches did this a bit ineptly, but the
next version populate's the P2M and M2P so you actually end up with 4GB of memory
in dom0 instead of the 3GB.

This is what we end up with without any dom0_mem argument:

2.6.32 SLES:
Memory: 7538688k/8079432k available (3971k kernel code, 8192k absent, 532300k reserved, 2491k data, 348k init)
MemTotal:        8063140 kB
MemFree:         7421504 kB
DirectMap4k:     8071240 kB
Domain-0                                     0  7873     4     r-----     20.3

3.3:
Memory: 6486452k/9208688k available (5825k kernel code, 1136060k absent, 1586176k reserved, 2890k data, 692k init)
MemTotal:        6716156 kB
MemFree:         6365696 kB
DirectMap4k:     8078192 kB
Domain-0                                     0  6774     4     r-----     26.0

3.3+patches:
Memory: 7621460k/9208688k available (5817k kernel code, 1136060k absent, 451168k reserved, 2899k data, 692k init)
MemTotal:        7849924 kB
MemFree:         7500748 kB
DirectMap4k:     8078192 kB
Domain-0                                     0  7883     4     r-----     11.9


and .. hm, I lost the outputs I had with dom0_mem=X, but this is what I get
with 3.3 and 3.3+this patch:

dom0_mem=1G
-Memory: 610884k/9435136k available (5817k kernel code, 1136060k absent, 7688192k reserved, 2899k data, 696k init)
+Memory: 724184k/1053064k available (5817k kernel code, 4552k absent, 324328k reserved, 2899k data, 696k init)
   
I think the SLES kernel has the same behavior, but will have to wait
until next week when I am back to be double sure.


 
When it comes to "infinite" balloon - I think the work that Daniel did
on using the memory hotplug mechanism to add memory is preferable. That
way pagetables are put in the newly added memory space.


> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 22:37:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 22:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHNCi-0006K7-TI; Mon, 09 Apr 2012 22:36:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SHNCg-0006K2-UM
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 22:36:55 +0000
Received: from [85.158.139.83:13693] by server-4.bemta-5.messagelabs.com id
	DE/D1-10788-684638F4; Mon, 09 Apr 2012 22:36:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334011011!23083222!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22371 invoked from network); 9 Apr 2012 22:36:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Apr 2012 22:36:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39Makb3026349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Apr 2012 22:36:47 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39Maj3T004861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Apr 2012 22:36:45 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39MajsG006790; Mon, 9 Apr 2012 17:36:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Apr 2012 15:36:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C66D54032C; Mon,  9 Apr 2012 18:32:00 -0400 (EDT)
Date: Mon, 9 Apr 2012 18:32:00 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20120409223200.GF12783@phenom.dumpdata.com>
References: <osstest-12620-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-12620-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F83647F.003D,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-linus test] 12620: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 09, 2012 at 07:18:24PM +0100, xen.org wrote:
> flight 12620 linux-linus real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12620/
> version targeted for testing:
.. snip..
>  linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e

Hm, that version should have worked.


> baseline version:
>  linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   broken  

Ah, so b/c of that the other things broke. I am not actually
sure what is broken except that the initrd looks to have not been
pushed properly?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 22:37:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 22:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHNCi-0006K7-TI; Mon, 09 Apr 2012 22:36:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SHNCg-0006K2-UM
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 22:36:55 +0000
Received: from [85.158.139.83:13693] by server-4.bemta-5.messagelabs.com id
	DE/D1-10788-684638F4; Mon, 09 Apr 2012 22:36:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334011011!23083222!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1ODk0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22371 invoked from network); 9 Apr 2012 22:36:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Apr 2012 22:36:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q39Makb3026349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Apr 2012 22:36:47 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q39Maj3T004861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Apr 2012 22:36:45 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q39MajsG006790; Mon, 9 Apr 2012 17:36:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Apr 2012 15:36:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C66D54032C; Mon,  9 Apr 2012 18:32:00 -0400 (EDT)
Date: Mon, 9 Apr 2012 18:32:00 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20120409223200.GF12783@phenom.dumpdata.com>
References: <osstest-12620-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-12620-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F83647F.003D,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-linus test] 12620: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 09, 2012 at 07:18:24PM +0100, xen.org wrote:
> flight 12620 linux-linus real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12620/
> version targeted for testing:
.. snip..
>  linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e

Hm, that version should have worked.


> baseline version:
>  linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   broken  

Ah, so b/c of that the other things broke. I am not actually
sure what is broken except that the initrd looks to have not been
pushed properly?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 22:56:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 22:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHNVH-0006WG-Ib; Mon, 09 Apr 2012 22:56:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHNVF-0006WB-BW
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 22:56:05 +0000
Received: from [85.158.138.51:32735] by server-6.bemta-3.messagelabs.com id
	8D/07-08206-409638F4; Mon, 09 Apr 2012 22:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334012163!19579016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15834 invoked from network); 9 Apr 2012 22:56:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 22:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="11836994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 22:56:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 23:56:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHNVC-0001Ex-M5;
	Mon, 09 Apr 2012 22:56:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHNVC-000112-JR;
	Mon, 09 Apr 2012 23:56:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12621-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 23:56:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12621: trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12621 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12621/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                e63089b08140adea85d011da136c7b56d73296ee
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit e63089b08140adea85d011da136c7b56d73296ee
Merge: 23e4889... 0034102...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Apr 9 10:00:37 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 09 22:56:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Apr 2012 22:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHNVH-0006WG-Ib; Mon, 09 Apr 2012 22:56:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHNVF-0006WB-BW
	for xen-devel@lists.xensource.com; Mon, 09 Apr 2012 22:56:05 +0000
Received: from [85.158.138.51:32735] by server-6.bemta-3.messagelabs.com id
	8D/07-08206-409638F4; Mon, 09 Apr 2012 22:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334012163!19579016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15834 invoked from network); 9 Apr 2012 22:56:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Apr 2012 22:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="11836994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Apr 2012 22:56:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Apr 2012 23:56:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHNVC-0001Ex-M5;
	Mon, 09 Apr 2012 22:56:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHNVC-000112-JR;
	Mon, 09 Apr 2012 23:56:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12621-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Apr 2012 23:56:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12621: trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12621 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12621/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 12565
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 12565

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                e63089b08140adea85d011da136c7b56d73296ee
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit e63089b08140adea85d011da136c7b56d73296ee
Merge: 23e4889... 0034102...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Apr 9 10:00:37 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 00:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 00:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHOvR-0007hq-0m; Tue, 10 Apr 2012 00:27:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHOvP-0007hi-0E
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 00:27:11 +0000
Received: from [85.158.143.35:2864] by server-3.bemta-4.messagelabs.com id
	F6/C6-05853-E5E738F4; Tue, 10 Apr 2012 00:27:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334017629!4168814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2608 invoked from network); 10 Apr 2012 00:27:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 00:27:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="11837590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 00:27:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 01:27:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHOvM-0001iN-BF;
	Tue, 10 Apr 2012 00:27:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHOvM-0003RM-9l;
	Tue, 10 Apr 2012 01:27:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12622-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 01:27:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12622: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12622 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12622/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl            3 host-install(3)              broken never pass
 test-i386-i386-win            3 host-install(3)              broken never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 00:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 00:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHOvR-0007hq-0m; Tue, 10 Apr 2012 00:27:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHOvP-0007hi-0E
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 00:27:11 +0000
Received: from [85.158.143.35:2864] by server-3.bemta-4.messagelabs.com id
	F6/C6-05853-E5E738F4; Tue, 10 Apr 2012 00:27:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334017629!4168814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2608 invoked from network); 10 Apr 2012 00:27:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 00:27:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="11837590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 00:27:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 01:27:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHOvM-0001iN-BF;
	Tue, 10 Apr 2012 00:27:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHOvM-0003RM-9l;
	Tue, 10 Apr 2012 01:27:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12622-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 01:27:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12622: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12622 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12622/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl            3 host-install(3)              broken never pass
 test-i386-i386-win            3 host-install(3)              broken never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 01:02:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 01:02:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHPSb-0005Qn-4G; Tue, 10 Apr 2012 01:01:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHPSa-0005Ad-2l
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 01:01:28 +0000
Received: from [85.158.143.35:37772] by server-1.bemta-4.messagelabs.com id
	F2/B9-20925-766838F4; Tue, 10 Apr 2012 01:01:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334019686!11896330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23126 invoked from network); 10 Apr 2012 01:01:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 01:01:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="11837893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 01:01:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 02:01:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHPSX-0001tk-Dd;
	Tue, 10 Apr 2012 01:01:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHPSX-0004en-D8;
	Tue, 10 Apr 2012 02:01:25 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12623-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 02:01:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12623: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12623 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12623/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 01:02:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 01:02:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHPSb-0005Qn-4G; Tue, 10 Apr 2012 01:01:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHPSa-0005Ad-2l
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 01:01:28 +0000
Received: from [85.158.143.35:37772] by server-1.bemta-4.messagelabs.com id
	F2/B9-20925-766838F4; Tue, 10 Apr 2012 01:01:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334019686!11896330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23126 invoked from network); 10 Apr 2012 01:01:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 01:01:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="11837893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 01:01:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 02:01:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHPSX-0001tk-Dd;
	Tue, 10 Apr 2012 01:01:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHPSX-0004en-D8;
	Tue, 10 Apr 2012 02:01:25 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12623-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 02:01:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12623: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12623 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12623/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 05:49:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 05:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHTws-0005Yj-55; Tue, 10 Apr 2012 05:49:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SHTwq-0005Ye-DX
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 05:49:01 +0000
Received: from [85.158.139.83:57114] by server-12.bemta-5.messagelabs.com id
	A2/E8-05587-BC9C38F4; Tue, 10 Apr 2012 05:48:59 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334036937!23089997!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ0MDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ0MDg=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2772 invoked from network); 10 Apr 2012 05:48:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 05:48:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1334036936; l=16750;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fff+VTKkKVY1VDMVwpWHG3wmtXU=;
	b=IRI9j4K4uzgL2ziXokK7eHfdgMhO5X1x4FK3W+uUMYDH4OUsGrau+mwVFk99WBDuzVT
	bPgtpVb1AbwN31jhkS31L8QOxp12KaR+avOEcpF9Twzq6hLSQLk078Z5whv15C16Ftl95
	ifeQSEn6StPozdHd4qV2AuDyawXcU8Q+clM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7jfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-008.pools.arcor-ip.net [84.57.94.8])
	by smtp.strato.de (cohen mo36) (RZmta 28.8 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x07224o3A5HZ4v ;
	Tue, 10 Apr 2012 07:48:55 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A862D18630;
	Tue, 10 Apr 2012 07:48:54 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 01bf6f0872247dbd0d925b0e4676af53a5662129
Message-Id: <01bf6f0872247dbd0d92.1334036900@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 10 Apr 2012 07:48:20 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: roger.pau@entel.upc.edu, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools/configure: add options to pass
	EXTRA_CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1334036879 -7200
# Node ID 01bf6f0872247dbd0d925b0e4676af53a5662129
# Parent  c9ed3eecb19f8e09c740e107e9c1d040328f3ec0
tools/configure: add options to pass EXTRA_CFLAGS

Currently qemu-xen will be compiled with CFLAGS only if CFLAGS was
already in the environment during make invocation. If CFLAGS is in
environment then make will append all of the various flags specified in
xen Makefiles to this environment variable, which is then used in qemu
configure. Since qemu-xen is not ready for compiler flags like
"-std=gnu99" compilation will fail. If CFLAGS is not in environment,
then configure will use just "-O2 -g" because make does not export its
own CFLAGS variable.

>From a distro perspective, it is required to build libraries and
binaries with certain global cflags (arbitrary gcc options). Up to the
point when qemu-xen was imported it worked as expected by exporting
CFLAGS before 'make tools'.  Now qemu-upstream reuses these CFLAGS, but
it cant deal with the result.

This patch extends the Makefiles in the tools directory to recognize three
environment variables to pass arbitrary options to gcc:

  EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
  EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
  EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.

The new feature can be used like this in a rpm xen.spec file:

   export EXTRA_CFLAGS_XEN_TOOLS="${RPM_OPT_FLAGS} -Wno-error"
   export EXTRA_CFLAGS_QEMU_TRADITIONAL="${RPM_OPT_FLAGS}"
   export EXTRA_CFLAGS_QEMU_XEN="${RPM_OPT_FLAGS}"
   make tools

v4:
 - remove all configure related changes, EXTRA_CFLAGS_* will be
   taken from either environment or as make command line.
 - move EXTRA_CFLAGS_QEMU_XEN to existing --extra-cflags option
 - add --extra-cflags option to xen-setup to pass EXTRA_CFLAGS_QEMU_TRADITIONAL

v3:
 - move EXTRA_CFLAGS_XEN_TOOLS from rules in tools/Rules.mk to every
   Makefile except firmware because it runs in guest context and can not
   deal with gcc options like -fstack-protector. This turns
   EXTRA_CFLAGS_XEN_TOOLS into a HOST_CFLAGS kind of thing.

v2:
 - add new EXTRA_CFLAGS_XEN_TOOLS variable to config/Tools.mk.in instead
   of modifying CFLAGS in this file. Also remove include order change in
   tools/Rules.mk since its now not needed anymore
 - add EXTRA_CFLAGS_XEN_TOOLS to all rules in tools/Rules.mk
 - update help output in tools/configure.ac

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c9ed3eecb19f -r 01bf6f087224 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -122,7 +122,9 @@ subdir-all-qemu-xen-traditional-dir subd
 	set -e; \
 		$(buildmakevars2shellvars); \
 		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(QEMU_ROOT)/xen-setup \
+		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
+		$(IOEMU_CONFIGURE_CROSS); \
 		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
@@ -150,7 +152,8 @@ subdir-all-qemu-xen-dir subdir-install-q
 		--source-path=$$source \
 		--extra-cflags="-I$(XEN_ROOT)/tools/include \
 		-I$(XEN_ROOT)/tools/libxc \
-		-I$(XEN_ROOT)/tools/xenstore" \
+		-I$(XEN_ROOT)/tools/xenstore \
+		$(EXTRA_CFLAGS_QEMU_XEN)" \
 		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=$(LIBEXEC) \
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap/drivers/Makefile
--- a/tools/blktap/drivers/Makefile
+++ b/tools/blktap/drivers/Makefile
@@ -35,6 +35,8 @@ else
 AIOLIBS     := -laio
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
 LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap/lib/Makefile
--- a/tools/blktap/lib/Makefile
+++ b/tools/blktap/lib/Makefile
@@ -19,6 +19,8 @@ CFLAGS   += -fPIC
 # get asprintf():
 CFLAGS   += -D _GNU_SOURCE
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 OBJS     = $(SRCS:.c=.o)
 OBJS_PIC = $(SRCS:.c=.opic)
 IBINS   :=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/Makefile
--- a/tools/blktap2/Makefile
+++ b/tools/blktap2/Makefile
@@ -2,6 +2,8 @@ XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 
 SUBDIRS-y :=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/control/Makefile
--- a/tools/blktap2/control/Makefile
+++ b/tools/blktap2/control/Makefile
@@ -16,6 +16,8 @@ CFLAGS            += $(CFLAGS_libxenctrl
 CFLAGS            += -D_GNU_SOURCE
 CFLAGS            += -DTAPCTL
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CTL_OBJS  := tap-ctl-ipc.o
 CTL_OBJS  += tap-ctl-list.o
 CTL_OBJS  += tap-ctl-allocate.o
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile
+++ b/tools/blktap2/drivers/Makefile
@@ -49,6 +49,8 @@ ifeq ($(VHD_STATIC),y)
 td-util: CFLAGS += -static
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 PORTABLE-OBJS-y :=
 PORTABLE-OBJS-$(CONFIG_Linux)  += blk_linux.o
 PORTABLE-OBJS-$(CONFIG_NetBSD) += blk_netbsd.o
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/lvm/Makefile
--- a/tools/blktap2/lvm/Makefile
+++ b/tools/blktap2/lvm/Makefile
@@ -15,6 +15,8 @@ ifeq ($(CONFIG_X86_64),y)
 CFLAGS            += -fPIC
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LVM-OBJS          := lvm-util.o
 
 all: build
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/vhd/Makefile
--- a/tools/blktap2/vhd/Makefile
+++ b/tools/blktap2/vhd/Makefile
@@ -21,6 +21,8 @@ ifeq ($(VHD_STATIC),y)
 CFLAGS            += -static
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LIBS              := -Llib -lvhd
 
 all: subdirs-all build
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -19,6 +19,8 @@ CFLAGS          += -D_GNU_SOURCE
 CFLAGS          += -fPIC
 CFLAGS          += -g
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 ifeq ($(CONFIG_Linux),y)
 LIBS            := -luuid
 endif
diff -r c9ed3eecb19f -r 01bf6f087224 tools/console/Makefile
--- a/tools/console/Makefile
+++ b/tools/console/Makefile
@@ -5,6 +5,9 @@ CFLAGS  += -Werror
 
 CFLAGS  += $(CFLAGS_libxenctrl)
 CFLAGS  += $(CFLAGS_libxenstore)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 LDLIBS += $(LDLIBS_libxenstore)
 LDLIBS += $(SOCKET_LIBS)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/debugger/kdd/Makefile
--- a/tools/debugger/kdd/Makefile
+++ b/tools/debugger/kdd/Makefile
@@ -2,6 +2,9 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS  += $(LDLIBS_libxenctrl)
 
 CFILES  := kdd.c kdd-xen.c
diff -r c9ed3eecb19f -r 01bf6f087224 tools/debugger/xenitp/Makefile
--- a/tools/debugger/xenitp/Makefile
+++ b/tools/debugger/xenitp/Makefile
@@ -5,6 +5,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LIBBIN   = 
 
 ifeq ($(XEN_TARGET_ARCH),ia64)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/flask/utils/Makefile
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 CFLAGS += -Wall -g -Werror
 CFLAGS += $(CFLAGS_libxenctrl)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
 TESTENV  = XENSTORED_ROOTDIR=$(TESTDIR) XENSTORED_RUNDIR=$(TESTDIR)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libaio/src/Makefile
--- a/tools/libaio/src/Makefile
+++ b/tools/libaio/src/Makefile
@@ -7,6 +7,9 @@ libdir=$(prefix)/lib
 
 ARCH := $(shell uname -m | sed -e s/i.86/i386/)
 CFLAGS = -nostdlib -nostartfiles -Wall -I. -g -fomit-frame-pointer -O2 -fPIC
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 SO_CFLAGS=-shared $(CFLAGS)
 L_CFLAGS=$(CFLAGS)
 LINK_FLAGS=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libfsimage/Makefile
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
 SUBDIRS-$(CONFIG_X86) += xfs
 ifeq ($(CONFIG_EXT2FS), y)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libvchan/Makefile
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -19,6 +19,8 @@ MINOR = 0
 
 CFLAGS += -I../include -I.
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libxc/Makefile
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -73,6 +73,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libxen/Makefile
--- a/tools/libxen/Makefile
+++ b/tools/libxen/Makefile
@@ -26,6 +26,8 @@ CFLAGS += -Iinclude                     
           $(shell $(CURL_CONFIG) --cflags) \
           -fPIC
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDFLAGS += $(shell $(XML2_CONFIG) --libs) \
            $(shell $(CURL_CONFIG) --libs)
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -72,6 +72,8 @@ testidl.c: libxl_types.idl gentest.py li
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/memshr/Makefile
--- a/tools/memshr/Makefile
+++ b/tools/memshr/Makefile
@@ -11,6 +11,8 @@ CFLAGS          += -D_GNU_SOURCE
 CFLAGS          += -fPIC
 CFLAGS          += -g
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LIB-SRCS        := interface.c
 LIB-SRCS        += shm.c
 LIB-SRCS        += bidir-daemon.c
diff -r c9ed3eecb19f -r 01bf6f087224 tools/misc/Makefile
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -30,6 +30,8 @@ INSTALL_SBIN := $(INSTALL_SBIN-y)
 # Include configure output (config.h) to headers search path
 CFLAGS += -I$(XEN_ROOT)/tools
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/misc/lomount/Makefile
--- a/tools/misc/lomount/Makefile
+++ b/tools/misc/lomount/Makefile
@@ -3,6 +3,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += -Werror
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 
@@ -20,4 +22,4 @@ clean:
 lomount: lomount.o
 	$(CC) $(CFLAGS) -o $@ $< 
 
--include $(DEPS)
\ No newline at end of file
+-include $(DEPS)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/misc/nsplitd/Makefile
--- a/tools/misc/nsplitd/Makefile
+++ b/tools/misc/nsplitd/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT := $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CFILES = $(wildcard *.c)
 
 HDRS     = $(wildcard *.h)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/pygrub/Makefile
--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -2,6 +2,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 .PHONY: build
diff -r c9ed3eecb19f -r 01bf6f087224 tools/python/Makefile
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/Makefile
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -2,6 +2,9 @@ XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 
 SUBDIRS-y :=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/mce-test/tools/Makefile
--- a/tools/tests/mce-test/tools/Makefile
+++ b/tools/tests/mce-test/tools/Makefile
@@ -7,6 +7,8 @@ CFLAGS += $(CFLAGS_libxenguest)
 CFLAGS += $(CFLAGS_libxenstore) 
 CFLAGS += $(CFLAGS_xeninclude) 
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: xen-mceinj
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/mem-sharing/Makefile
--- a/tools/tests/mem-sharing/Makefile
+++ b/tools/tests/mem-sharing/Makefile
@@ -6,6 +6,8 @@ CFLAGS += -Werror
 CFLAGS += $(CFLAGS_libxenctrl)
 CFLAGS += $(CFLAGS_xeninclude)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 TARGETS-y := 
 TARGETS-$(CONFIG_X86) += memshrtool
 TARGETS := $(TARGETS-y)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/xen-access/Makefile
--- a/tools/tests/xen-access/Makefile
+++ b/tools/tests/xen-access/Makefile
@@ -7,6 +7,8 @@ CFLAGS += $(CFLAGS_libxenctrl)
 CFLAGS += $(CFLAGS_libxenguest)
 CFLAGS += $(CFLAGS_xeninclude)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 TARGETS-y := 
 TARGETS-$(CONFIG_X86) += xen-access
 TARGETS := $(TARGETS-y)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xcutils/Makefile
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -15,6 +15,8 @@ PROGRAMS = xc_restore xc_save readnotes 
 
 CFLAGS += -Werror
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenbackendd/Makefile
--- a/tools/xenbackendd/Makefile
+++ b/tools/xenbackendd/Makefile
@@ -14,6 +14,9 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += -Werror
 CFLAGS  += $(CFLAGS_libxenstore)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CPPFLAGS += -DXEN_SCRIPT_DIR="\"$(XEN_SCRIPT_DIR)\""
 LDLIBS  += $(LDLIBS_libxenstore)
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenmon/Makefile
--- a/tools/xenmon/Makefile
+++ b/tools/xenmon/Makefile
@@ -15,6 +15,9 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += -Werror
 CFLAGS  += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS  += $(LDLIBS_libxenctrl)
 
 SCRIPTS = xenmon.py
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -14,6 +14,8 @@ CFLAGS   += -Werror
 CFLAGS   += -Wno-unused
 CFLAGS   += -g
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 OBJS     = $(SRCS:.c=.o)
 IBINS    = xenpaging
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenpmd/Makefile
--- a/tools/xenpmd/Makefile
+++ b/tools/xenpmd/Makefile
@@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 CFLAGS += -Werror
 CFLAGS += $(CFLAGS_libxenstore)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenstore)
 
 .PHONY: all
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstat/Makefile
--- a/tools/xenstat/Makefile
+++ b/tools/xenstat/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 SUBDIRS :=
 SUBDIRS += libxenstat
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstat/libxenstat/Makefile
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenstat/libxenstat/Makefile
@@ -39,6 +39,8 @@ WARN_FLAGS=-Wall -Werror
 CFLAGS+=-fPIC
 CFLAGS+=-Isrc $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore) $(CFLAGS_xeninclude)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS-y = $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl)
 LDLIBS-$(CONFIG_SunOS) += -lkstat
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstat/xentop/Makefile
--- a/tools/xenstat/xentop/Makefile
+++ b/tools/xenstat/xentop/Makefile
@@ -25,6 +25,8 @@ CFLAGS += -DHOST_$(XEN_OS)
 # Include configure output (config.h) to headers search path
 CFLAGS += -I$(XEN_ROOT)/tools
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: xentop
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -52,6 +52,8 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
 
 init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xentrace/Makefile
--- a/tools/xentrace/Makefile
+++ b/tools/xentrace/Makefile
@@ -4,6 +4,9 @@ include $(XEN_ROOT)/tools/Rules.mk
 CFLAGS += -Werror
 
 CFLAGS += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 
 BIN      = xentrace xentrace_setsize

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 05:49:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 05:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHTws-0005Yj-55; Tue, 10 Apr 2012 05:49:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SHTwq-0005Ye-DX
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 05:49:01 +0000
Received: from [85.158.139.83:57114] by server-12.bemta-5.messagelabs.com id
	A2/E8-05587-BC9C38F4; Tue, 10 Apr 2012 05:48:59 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334036937!23089997!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ0MDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ0MDg=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2772 invoked from network); 10 Apr 2012 05:48:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 05:48:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1334036936; l=16750;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fff+VTKkKVY1VDMVwpWHG3wmtXU=;
	b=IRI9j4K4uzgL2ziXokK7eHfdgMhO5X1x4FK3W+uUMYDH4OUsGrau+mwVFk99WBDuzVT
	bPgtpVb1AbwN31jhkS31L8QOxp12KaR+avOEcpF9Twzq6hLSQLk078Z5whv15C16Ftl95
	ifeQSEn6StPozdHd4qV2AuDyawXcU8Q+clM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7jfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-008.pools.arcor-ip.net [84.57.94.8])
	by smtp.strato.de (cohen mo36) (RZmta 28.8 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x07224o3A5HZ4v ;
	Tue, 10 Apr 2012 07:48:55 +0200 (MEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A862D18630;
	Tue, 10 Apr 2012 07:48:54 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 01bf6f0872247dbd0d925b0e4676af53a5662129
Message-Id: <01bf6f0872247dbd0d92.1334036900@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 10 Apr 2012 07:48:20 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: roger.pau@entel.upc.edu, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools/configure: add options to pass
	EXTRA_CFLAGS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1334036879 -7200
# Node ID 01bf6f0872247dbd0d925b0e4676af53a5662129
# Parent  c9ed3eecb19f8e09c740e107e9c1d040328f3ec0
tools/configure: add options to pass EXTRA_CFLAGS

Currently qemu-xen will be compiled with CFLAGS only if CFLAGS was
already in the environment during make invocation. If CFLAGS is in
environment then make will append all of the various flags specified in
xen Makefiles to this environment variable, which is then used in qemu
configure. Since qemu-xen is not ready for compiler flags like
"-std=gnu99" compilation will fail. If CFLAGS is not in environment,
then configure will use just "-O2 -g" because make does not export its
own CFLAGS variable.

>From a distro perspective, it is required to build libraries and
binaries with certain global cflags (arbitrary gcc options). Up to the
point when qemu-xen was imported it worked as expected by exporting
CFLAGS before 'make tools'.  Now qemu-upstream reuses these CFLAGS, but
it cant deal with the result.

This patch extends the Makefiles in the tools directory to recognize three
environment variables to pass arbitrary options to gcc:

  EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
  EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
  EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.

The new feature can be used like this in a rpm xen.spec file:

   export EXTRA_CFLAGS_XEN_TOOLS="${RPM_OPT_FLAGS} -Wno-error"
   export EXTRA_CFLAGS_QEMU_TRADITIONAL="${RPM_OPT_FLAGS}"
   export EXTRA_CFLAGS_QEMU_XEN="${RPM_OPT_FLAGS}"
   make tools

v4:
 - remove all configure related changes, EXTRA_CFLAGS_* will be
   taken from either environment or as make command line.
 - move EXTRA_CFLAGS_QEMU_XEN to existing --extra-cflags option
 - add --extra-cflags option to xen-setup to pass EXTRA_CFLAGS_QEMU_TRADITIONAL

v3:
 - move EXTRA_CFLAGS_XEN_TOOLS from rules in tools/Rules.mk to every
   Makefile except firmware because it runs in guest context and can not
   deal with gcc options like -fstack-protector. This turns
   EXTRA_CFLAGS_XEN_TOOLS into a HOST_CFLAGS kind of thing.

v2:
 - add new EXTRA_CFLAGS_XEN_TOOLS variable to config/Tools.mk.in instead
   of modifying CFLAGS in this file. Also remove include order change in
   tools/Rules.mk since its now not needed anymore
 - add EXTRA_CFLAGS_XEN_TOOLS to all rules in tools/Rules.mk
 - update help output in tools/configure.ac

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c9ed3eecb19f -r 01bf6f087224 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -122,7 +122,9 @@ subdir-all-qemu-xen-traditional-dir subd
 	set -e; \
 		$(buildmakevars2shellvars); \
 		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(QEMU_ROOT)/xen-setup \
+		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
+		$(IOEMU_CONFIGURE_CROSS); \
 		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
@@ -150,7 +152,8 @@ subdir-all-qemu-xen-dir subdir-install-q
 		--source-path=$$source \
 		--extra-cflags="-I$(XEN_ROOT)/tools/include \
 		-I$(XEN_ROOT)/tools/libxc \
-		-I$(XEN_ROOT)/tools/xenstore" \
+		-I$(XEN_ROOT)/tools/xenstore \
+		$(EXTRA_CFLAGS_QEMU_XEN)" \
 		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=$(LIBEXEC) \
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap/drivers/Makefile
--- a/tools/blktap/drivers/Makefile
+++ b/tools/blktap/drivers/Makefile
@@ -35,6 +35,8 @@ else
 AIOLIBS     := -laio
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
 LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap/lib/Makefile
--- a/tools/blktap/lib/Makefile
+++ b/tools/blktap/lib/Makefile
@@ -19,6 +19,8 @@ CFLAGS   += -fPIC
 # get asprintf():
 CFLAGS   += -D _GNU_SOURCE
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 OBJS     = $(SRCS:.c=.o)
 OBJS_PIC = $(SRCS:.c=.opic)
 IBINS   :=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/Makefile
--- a/tools/blktap2/Makefile
+++ b/tools/blktap2/Makefile
@@ -2,6 +2,8 @@ XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 
 SUBDIRS-y :=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/control/Makefile
--- a/tools/blktap2/control/Makefile
+++ b/tools/blktap2/control/Makefile
@@ -16,6 +16,8 @@ CFLAGS            += $(CFLAGS_libxenctrl
 CFLAGS            += -D_GNU_SOURCE
 CFLAGS            += -DTAPCTL
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CTL_OBJS  := tap-ctl-ipc.o
 CTL_OBJS  += tap-ctl-list.o
 CTL_OBJS  += tap-ctl-allocate.o
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile
+++ b/tools/blktap2/drivers/Makefile
@@ -49,6 +49,8 @@ ifeq ($(VHD_STATIC),y)
 td-util: CFLAGS += -static
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 PORTABLE-OBJS-y :=
 PORTABLE-OBJS-$(CONFIG_Linux)  += blk_linux.o
 PORTABLE-OBJS-$(CONFIG_NetBSD) += blk_netbsd.o
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/lvm/Makefile
--- a/tools/blktap2/lvm/Makefile
+++ b/tools/blktap2/lvm/Makefile
@@ -15,6 +15,8 @@ ifeq ($(CONFIG_X86_64),y)
 CFLAGS            += -fPIC
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LVM-OBJS          := lvm-util.o
 
 all: build
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/vhd/Makefile
--- a/tools/blktap2/vhd/Makefile
+++ b/tools/blktap2/vhd/Makefile
@@ -21,6 +21,8 @@ ifeq ($(VHD_STATIC),y)
 CFLAGS            += -static
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LIBS              := -Llib -lvhd
 
 all: subdirs-all build
diff -r c9ed3eecb19f -r 01bf6f087224 tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -19,6 +19,8 @@ CFLAGS          += -D_GNU_SOURCE
 CFLAGS          += -fPIC
 CFLAGS          += -g
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 ifeq ($(CONFIG_Linux),y)
 LIBS            := -luuid
 endif
diff -r c9ed3eecb19f -r 01bf6f087224 tools/console/Makefile
--- a/tools/console/Makefile
+++ b/tools/console/Makefile
@@ -5,6 +5,9 @@ CFLAGS  += -Werror
 
 CFLAGS  += $(CFLAGS_libxenctrl)
 CFLAGS  += $(CFLAGS_libxenstore)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 LDLIBS += $(LDLIBS_libxenstore)
 LDLIBS += $(SOCKET_LIBS)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/debugger/kdd/Makefile
--- a/tools/debugger/kdd/Makefile
+++ b/tools/debugger/kdd/Makefile
@@ -2,6 +2,9 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS  += $(LDLIBS_libxenctrl)
 
 CFILES  := kdd.c kdd-xen.c
diff -r c9ed3eecb19f -r 01bf6f087224 tools/debugger/xenitp/Makefile
--- a/tools/debugger/xenitp/Makefile
+++ b/tools/debugger/xenitp/Makefile
@@ -5,6 +5,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LIBBIN   = 
 
 ifeq ($(XEN_TARGET_ARCH),ia64)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/flask/utils/Makefile
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 CFLAGS += -Wall -g -Werror
 CFLAGS += $(CFLAGS_libxenctrl)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
 TESTENV  = XENSTORED_ROOTDIR=$(TESTDIR) XENSTORED_RUNDIR=$(TESTDIR)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libaio/src/Makefile
--- a/tools/libaio/src/Makefile
+++ b/tools/libaio/src/Makefile
@@ -7,6 +7,9 @@ libdir=$(prefix)/lib
 
 ARCH := $(shell uname -m | sed -e s/i.86/i386/)
 CFLAGS = -nostdlib -nostartfiles -Wall -I. -g -fomit-frame-pointer -O2 -fPIC
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 SO_CFLAGS=-shared $(CFLAGS)
 L_CFLAGS=$(CFLAGS)
 LINK_FLAGS=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libfsimage/Makefile
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
 SUBDIRS-$(CONFIG_X86) += xfs
 ifeq ($(CONFIG_EXT2FS), y)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libvchan/Makefile
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -19,6 +19,8 @@ MINOR = 0
 
 CFLAGS += -I../include -I.
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libxc/Makefile
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -73,6 +73,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libxen/Makefile
--- a/tools/libxen/Makefile
+++ b/tools/libxen/Makefile
@@ -26,6 +26,8 @@ CFLAGS += -Iinclude                     
           $(shell $(CURL_CONFIG) --cflags) \
           -fPIC
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDFLAGS += $(shell $(XML2_CONFIG) --libs) \
            $(shell $(CURL_CONFIG) --libs)
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -72,6 +72,8 @@ testidl.c: libxl_types.idl gentest.py li
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/memshr/Makefile
--- a/tools/memshr/Makefile
+++ b/tools/memshr/Makefile
@@ -11,6 +11,8 @@ CFLAGS          += -D_GNU_SOURCE
 CFLAGS          += -fPIC
 CFLAGS          += -g
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LIB-SRCS        := interface.c
 LIB-SRCS        += shm.c
 LIB-SRCS        += bidir-daemon.c
diff -r c9ed3eecb19f -r 01bf6f087224 tools/misc/Makefile
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -30,6 +30,8 @@ INSTALL_SBIN := $(INSTALL_SBIN-y)
 # Include configure output (config.h) to headers search path
 CFLAGS += -I$(XEN_ROOT)/tools
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/misc/lomount/Makefile
--- a/tools/misc/lomount/Makefile
+++ b/tools/misc/lomount/Makefile
@@ -3,6 +3,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += -Werror
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 
@@ -20,4 +22,4 @@ clean:
 lomount: lomount.o
 	$(CC) $(CFLAGS) -o $@ $< 
 
--include $(DEPS)
\ No newline at end of file
+-include $(DEPS)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/misc/nsplitd/Makefile
--- a/tools/misc/nsplitd/Makefile
+++ b/tools/misc/nsplitd/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT := $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CFILES = $(wildcard *.c)
 
 HDRS     = $(wildcard *.h)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/pygrub/Makefile
--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -2,6 +2,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 .PHONY: build
diff -r c9ed3eecb19f -r 01bf6f087224 tools/python/Makefile
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: build
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/Makefile
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -2,6 +2,9 @@ XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 
 SUBDIRS-y :=
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/mce-test/tools/Makefile
--- a/tools/tests/mce-test/tools/Makefile
+++ b/tools/tests/mce-test/tools/Makefile
@@ -7,6 +7,8 @@ CFLAGS += $(CFLAGS_libxenguest)
 CFLAGS += $(CFLAGS_libxenstore) 
 CFLAGS += $(CFLAGS_xeninclude) 
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: xen-mceinj
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/mem-sharing/Makefile
--- a/tools/tests/mem-sharing/Makefile
+++ b/tools/tests/mem-sharing/Makefile
@@ -6,6 +6,8 @@ CFLAGS += -Werror
 CFLAGS += $(CFLAGS_libxenctrl)
 CFLAGS += $(CFLAGS_xeninclude)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 TARGETS-y := 
 TARGETS-$(CONFIG_X86) += memshrtool
 TARGETS := $(TARGETS-y)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/tests/xen-access/Makefile
--- a/tools/tests/xen-access/Makefile
+++ b/tools/tests/xen-access/Makefile
@@ -7,6 +7,8 @@ CFLAGS += $(CFLAGS_libxenctrl)
 CFLAGS += $(CFLAGS_libxenguest)
 CFLAGS += $(CFLAGS_xeninclude)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 TARGETS-y := 
 TARGETS-$(CONFIG_X86) += xen-access
 TARGETS := $(TARGETS-y)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xcutils/Makefile
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -15,6 +15,8 @@ PROGRAMS = xc_restore xc_save readnotes 
 
 CFLAGS += -Werror
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenbackendd/Makefile
--- a/tools/xenbackendd/Makefile
+++ b/tools/xenbackendd/Makefile
@@ -14,6 +14,9 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += -Werror
 CFLAGS  += $(CFLAGS_libxenstore)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 CPPFLAGS += -DXEN_SCRIPT_DIR="\"$(XEN_SCRIPT_DIR)\""
 LDLIBS  += $(LDLIBS_libxenstore)
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenmon/Makefile
--- a/tools/xenmon/Makefile
+++ b/tools/xenmon/Makefile
@@ -15,6 +15,9 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 CFLAGS  += -Werror
 CFLAGS  += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS  += $(LDLIBS_libxenctrl)
 
 SCRIPTS = xenmon.py
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -14,6 +14,8 @@ CFLAGS   += -Werror
 CFLAGS   += -Wno-unused
 CFLAGS   += -g
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 OBJS     = $(SRCS:.c=.o)
 IBINS    = xenpaging
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenpmd/Makefile
--- a/tools/xenpmd/Makefile
+++ b/tools/xenpmd/Makefile
@@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 CFLAGS += -Werror
 CFLAGS += $(CFLAGS_libxenstore)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenstore)
 
 .PHONY: all
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstat/Makefile
--- a/tools/xenstat/Makefile
+++ b/tools/xenstat/Makefile
@@ -1,6 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 SUBDIRS :=
 SUBDIRS += libxenstat
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstat/libxenstat/Makefile
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenstat/libxenstat/Makefile
@@ -39,6 +39,8 @@ WARN_FLAGS=-Wall -Werror
 CFLAGS+=-fPIC
 CFLAGS+=-Isrc $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore) $(CFLAGS_xeninclude)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS-y = $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl)
 LDLIBS-$(CONFIG_SunOS) += -lkstat
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstat/xentop/Makefile
--- a/tools/xenstat/xentop/Makefile
+++ b/tools/xenstat/xentop/Makefile
@@ -25,6 +25,8 @@ CFLAGS += -DHOST_$(XEN_OS)
 # Include configure output (config.h) to headers search path
 CFLAGS += -I$(XEN_ROOT)/tools
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 .PHONY: all
 all: xentop
 
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -52,6 +52,8 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
 
 init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
diff -r c9ed3eecb19f -r 01bf6f087224 tools/xentrace/Makefile
--- a/tools/xentrace/Makefile
+++ b/tools/xentrace/Makefile
@@ -4,6 +4,9 @@ include $(XEN_ROOT)/tools/Rules.mk
 CFLAGS += -Werror
 
 CFLAGS += $(CFLAGS_libxenctrl)
+
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 LDLIBS += $(LDLIBS_libxenctrl)
 
 BIN      = xentrace xentrace_setsize

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVe8-0007Ck-Rb; Tue, 10 Apr 2012 07:37:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHVe7-0007Cc-F4
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:37:47 +0000
Received: from [85.158.143.99:12596] by server-1.bemta-4.messagelabs.com id
	2B/C7-20925-A43E38F4; Tue, 10 Apr 2012 07:37:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334043465!13316627!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24866 invoked from network); 10 Apr 2012 07:37:45 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 07:37:45 -0000
Received: by wgbds1 with SMTP id ds1so2933788wgb.2
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 00:37:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MHVcqUW0sjtrkUd90KqMtIxf+bLQG5XiBHLCAvmShwM=;
	b=jiside02FEZ1OFIFT+5eUizlJ+FkVSkE6ixri2h4+MNHTk3D2IhF3yvh4syCTD/79r
	j0J4hiX3uXTI6lsC/xJze3DjJzulaCSyq/OuRaEEcwtwdAdCcMlDeIRhfhBSjNJHBStC
	cbKDJUGyDLQL6Z5d5aA42ZEp1Bcqs8+9GEaHuvmCGUQWJ0NNTtecfLff5O6UIXovUhV2
	+gZBnO8o0KtXQnC5G5sojAIY79qKuSimulfDeQt0Hg/Z2BbXfy8m+AhcgrLkQqYEpWPA
	NwjxUkEyc5bIS5HA8GQQreMxUb1VnduHbZoW0Lh5kuUdbS/HF0LRlDYSndosWChDh8Lm
	om7g==
Received: by 10.180.81.166 with SMTP id b6mr4489331wiy.0.1334043465005;
	Tue, 10 Apr 2012 00:37:45 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id n8sm58302023wix.10.2012.04.10.00.37.43
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 00:37:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Apr 2012 08:37:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA9A1D5.3042B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0W7M9SUI/+p9xPH0qQpI9QRoMgyg==
In-Reply-To: <1334006386.85318.YahooMailNeo@web124506.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Not sure. Did you snip some lines from the call trace that might explain why
the call trace is being generated (e.g., watchdog timeout, page fault, ...)?
>From the lines you provide, we can't even tell which vcpu it is that is
dumping the call trace.

 -- Keir

On 09/04/2012 22:19, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> Thanks again! When I used the scheme I have described, I periodically rec=
eive
> kernel errors as shown below. Notice that I use HVM domain and also 'isol=
cpus'
> as a Linux kernel option to prevent a dedicated VCPU from being normally =
used.
> A hypercall is being made from a special kernel thread (which is bind to =
the
> dedicated VCPU before the call).
> =

> What could be the reason of these messages? Looks like it is something re=
lated
> to a timer.
> =

> =

> [ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>]
> default_send_IPI_mask_sequence_phys+0x95/0xce
> [ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
> [ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX:
> 0000000000000020
> [ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI:
> 0000000000000300
> [ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09:
> ffffffff8163eb20
> [ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12:
> 000000000000d602
> [ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15:
> ffffffff8163eb20
> [ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000)
> knlGS:0000000000000000
> [ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4:
> 00000000000006a0
> [ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, ta=
sk
> ffff88007c4f1650)
> [ 1039.319957] Stack:
> [ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88
> 0000000000002710
> [ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001
> ffffffff8161a4c0
> [ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98
> ffffffff8101bb81
> [ 1039.319957] Call Trace:
> [ 1039.319957]=A0 <IRQ>
> [ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
> [ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x4=
b/0x6e
> [ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
> [ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
> [ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
> [ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
> [ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
> [ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
> [ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
> [ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
> [ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
> [ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
> [ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
> [ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
> [ 1039.319957]=A0 <EOI>
> [ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
> [ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
> [ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
> [ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
> [ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1
> =

> =

> =

> Thanks,
> Ruslan
> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Monday, April 9, 2012 8:58 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> It means the vcpu has an interrupt pending (in the pv case, that means an
> event channel has a pending event).
> =

> =

> On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Keir,
>> =

>> Thanks for your replies! Just one more question about
>> local_event_need_delivery(). Under what (common) conditions I would expe=
ct to
>> have local events that need delivery?
>> =

>> Ruslan
>> =

>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 8:09 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Thanks for the reply.
>>> =

>>> Since it can take arbitrarily long for an event to arrive (e.g., it is
>>> coming
>>> from a different guest on a user request), how do I need to handle this
>>> case?Does it mean that I only need to make sure that nothings get sched=
uled
>>> on
>>> this VCPU in the guest?
>> =

>> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
>> sleep within wait_event within the hypercall context. Hence you must not
>> hold any hypervisor spinlocks either, for example.
>> =

>>> Also, it is not exactly clear to me how wait_event avoids the need for
>>> hypercall continuation. What about local_events_need_delivery() or
>>> softirq_pending()? Are they going to be handled by wait_event internall=
y?
>> =

>> Your VCPU gets descheduled. Hence softirq_pending() is not your concern =
for
>> the duration that you're descheduled. And if local_event_need_delivery(),
>> that's too bad, they have to wait for the vcpu to wake up on the event.
>> =

>> -- Keir
>> =

>>> Ruslan
>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>> ----- Original Message -----
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>>> <xen-devel@lists.xen.org>
>>> Cc: =

>>> Sent: Monday, April 9, 2012 6:54 PM
>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>> =

>>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>> =

>>>> Hi
>>>> =

>>>> I am curious how I can properly support hypercall continuation and
>>>> wait_event.
>>>> I have a dedicated VCPU in a domain which makes a special hypercall, a=
nd
>>>> the
>>>> hypercall waits for certain event to arrive. I am using queues availab=
le in
>>>> Xen, so wait_event will be invoked in the hypercall once its ready to
>>>> accept
>>>> events. However, my understanding that even though I have a dedicated =
VCPU
>>>> for
>>>> this hypercall, I still may need to support hypercall continuation
>>>> properly.
>>>> (Is this the case?) So, my question is how exactly the need for hyperc=
all
>>> =

>>> No it's not the case, the old hypercall_create_continuation() mechanism=
 does
>>> not need to be used with wait_event().
>>> =

>>> -- Keir
>>> =

>>>> preemption may affect wait_event() and wait() operations, and where wo=
uld I
>>>> need to do hypercall_preempt_check()?
>>>> =

>>>> Thank you!
>>>> Ruslan
>>>> =

>>>> =

>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVe8-0007Ck-Rb; Tue, 10 Apr 2012 07:37:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHVe7-0007Cc-F4
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:37:47 +0000
Received: from [85.158.143.99:12596] by server-1.bemta-4.messagelabs.com id
	2B/C7-20925-A43E38F4; Tue, 10 Apr 2012 07:37:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334043465!13316627!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24866 invoked from network); 10 Apr 2012 07:37:45 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 07:37:45 -0000
Received: by wgbds1 with SMTP id ds1so2933788wgb.2
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 00:37:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MHVcqUW0sjtrkUd90KqMtIxf+bLQG5XiBHLCAvmShwM=;
	b=jiside02FEZ1OFIFT+5eUizlJ+FkVSkE6ixri2h4+MNHTk3D2IhF3yvh4syCTD/79r
	j0J4hiX3uXTI6lsC/xJze3DjJzulaCSyq/OuRaEEcwtwdAdCcMlDeIRhfhBSjNJHBStC
	cbKDJUGyDLQL6Z5d5aA42ZEp1Bcqs8+9GEaHuvmCGUQWJ0NNTtecfLff5O6UIXovUhV2
	+gZBnO8o0KtXQnC5G5sojAIY79qKuSimulfDeQt0Hg/Z2BbXfy8m+AhcgrLkQqYEpWPA
	NwjxUkEyc5bIS5HA8GQQreMxUb1VnduHbZoW0Lh5kuUdbS/HF0LRlDYSndosWChDh8Lm
	om7g==
Received: by 10.180.81.166 with SMTP id b6mr4489331wiy.0.1334043465005;
	Tue, 10 Apr 2012 00:37:45 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id n8sm58302023wix.10.2012.04.10.00.37.43
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 00:37:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Apr 2012 08:37:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBA9A1D5.3042B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0W7M9SUI/+p9xPH0qQpI9QRoMgyg==
In-Reply-To: <1334006386.85318.YahooMailNeo@web124506.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Not sure. Did you snip some lines from the call trace that might explain why
the call trace is being generated (e.g., watchdog timeout, page fault, ...)?
>From the lines you provide, we can't even tell which vcpu it is that is
dumping the call trace.

 -- Keir

On 09/04/2012 22:19, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> Thanks again! When I used the scheme I have described, I periodically rec=
eive
> kernel errors as shown below. Notice that I use HVM domain and also 'isol=
cpus'
> as a Linux kernel option to prevent a dedicated VCPU from being normally =
used.
> A hypercall is being made from a special kernel thread (which is bind to =
the
> dedicated VCPU before the call).
> =

> What could be the reason of these messages? Looks like it is something re=
lated
> to a timer.
> =

> =

> [ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>]
> default_send_IPI_mask_sequence_phys+0x95/0xce
> [ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
> [ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX:
> 0000000000000020
> [ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI:
> 0000000000000300
> [ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09:
> ffffffff8163eb20
> [ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12:
> 000000000000d602
> [ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15:
> ffffffff8163eb20
> [ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000)
> knlGS:0000000000000000
> [ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4:
> 00000000000006a0
> [ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, ta=
sk
> ffff88007c4f1650)
> [ 1039.319957] Stack:
> [ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88
> 0000000000002710
> [ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001
> ffffffff8161a4c0
> [ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98
> ffffffff8101bb81
> [ 1039.319957] Call Trace:
> [ 1039.319957]=A0 <IRQ>
> [ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
> [ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x4=
b/0x6e
> [ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
> [ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
> [ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
> [ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
> [ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
> [ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
> [ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
> [ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
> [ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
> [ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
> [ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
> [ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
> [ 1039.319957]=A0 <EOI>
> [ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
> [ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
> [ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
> [ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
> [ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1
> =

> =

> =

> Thanks,
> Ruslan
> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Monday, April 9, 2012 8:58 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> It means the vcpu has an interrupt pending (in the pv case, that means an
> event channel has a pending event).
> =

> =

> On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Keir,
>> =

>> Thanks for your replies! Just one more question about
>> local_event_need_delivery(). Under what (common) conditions I would expe=
ct to
>> have local events that need delivery?
>> =

>> Ruslan
>> =

>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 8:09 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Thanks for the reply.
>>> =

>>> Since it can take arbitrarily long for an event to arrive (e.g., it is
>>> coming
>>> from a different guest on a user request), how do I need to handle this
>>> case?Does it mean that I only need to make sure that nothings get sched=
uled
>>> on
>>> this VCPU in the guest?
>> =

>> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
>> sleep within wait_event within the hypercall context. Hence you must not
>> hold any hypervisor spinlocks either, for example.
>> =

>>> Also, it is not exactly clear to me how wait_event avoids the need for
>>> hypercall continuation. What about local_events_need_delivery() or
>>> softirq_pending()? Are they going to be handled by wait_event internall=
y?
>> =

>> Your VCPU gets descheduled. Hence softirq_pending() is not your concern =
for
>> the duration that you're descheduled. And if local_event_need_delivery(),
>> that's too bad, they have to wait for the vcpu to wake up on the event.
>> =

>> -- Keir
>> =

>>> Ruslan
>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>> ----- Original Message -----
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>>> <xen-devel@lists.xen.org>
>>> Cc: =

>>> Sent: Monday, April 9, 2012 6:54 PM
>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>> =

>>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>> =

>>>> Hi
>>>> =

>>>> I am curious how I can properly support hypercall continuation and
>>>> wait_event.
>>>> I have a dedicated VCPU in a domain which makes a special hypercall, a=
nd
>>>> the
>>>> hypercall waits for certain event to arrive. I am using queues availab=
le in
>>>> Xen, so wait_event will be invoked in the hypercall once its ready to
>>>> accept
>>>> events. However, my understanding that even though I have a dedicated =
VCPU
>>>> for
>>>> this hypercall, I still may need to support hypercall continuation
>>>> properly.
>>>> (Is this the case?) So, my question is how exactly the need for hyperc=
all
>>> =

>>> No it's not the case, the old hypercall_create_continuation() mechanism=
 does
>>> not need to be used with wait_event().
>>> =

>>> -- Keir
>>> =

>>>> preemption may affect wait_event() and wait() operations, and where wo=
uld I
>>>> need to do hypercall_preempt_check()?
>>>> =

>>>> Thank you!
>>>> Ruslan
>>>> =

>>>> =

>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:41:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVhb-0007WH-7Z; Tue, 10 Apr 2012 07:41:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHVhZ-0007W2-Dj
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:41:21 +0000
Received: from [85.158.138.51:29197] by server-12.bemta-3.messagelabs.com id
	C0/08-30663-024E38F4; Tue, 10 Apr 2012 07:41:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334043679!21479394!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25577 invoked from network); 10 Apr 2012 07:41:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 07:41:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 08:41:18 +0100
Message-Id: <4F84003C020000780007CF23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 08:41:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
	<a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
In-Reply-To: <a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 7 v2] x86: fix memset(ptr, 0,
 sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333640955 -3600
> # Node ID a93381049790e4f8a02f2322851f78175c254c5b
> # Parent  4674ce03c62a3e916954fd445b4510ffe72e64f4
> x86: fix memset(ptr, 0, sizeof ptr).
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/cpu/mcheck/amd_f10.c
> --- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
>  		return NULL;
>  	}
>  
> -	memset(mc_ext, 0, sizeof(mc_ext));
> +	memset(mc_ext, 0, sizeof(*mc_ext));
>  	mc_ext->common.type = MC_TYPE_EXTENDED;
> -	mc_ext->common.size = sizeof(mc_ext);
> +	mc_ext->common.size = sizeof(*mc_ext);
>  	mc_ext->mc_msrs = 3;
>  
>  	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -1232,11 +1232,10 @@ bool_t p2m_mem_access_check(unsigned lon
>      }
>  
>      *req_ptr = NULL;
> -    req = xmalloc(mem_event_request_t);
> +    req = xzalloc(mem_event_request_t);
>      if ( req )
>      {
>          *req_ptr = req;
> -        memset(req, 0, sizeof(req));
>          req->reason = MEM_EVENT_REASON_VIOLATION;
>  
>          /* Pause the current VCPU */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:41:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVhb-0007WH-7Z; Tue, 10 Apr 2012 07:41:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHVhZ-0007W2-Dj
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:41:21 +0000
Received: from [85.158.138.51:29197] by server-12.bemta-3.messagelabs.com id
	C0/08-30663-024E38F4; Tue, 10 Apr 2012 07:41:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334043679!21479394!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25577 invoked from network); 10 Apr 2012 07:41:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 07:41:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 08:41:18 +0100
Message-Id: <4F84003C020000780007CF23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 08:41:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
	<a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
In-Reply-To: <a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 7 v2] x86: fix memset(ptr, 0,
 sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333640955 -3600
> # Node ID a93381049790e4f8a02f2322851f78175c254c5b
> # Parent  4674ce03c62a3e916954fd445b4510ffe72e64f4
> x86: fix memset(ptr, 0, sizeof ptr).
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/cpu/mcheck/amd_f10.c
> --- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
>  		return NULL;
>  	}
>  
> -	memset(mc_ext, 0, sizeof(mc_ext));
> +	memset(mc_ext, 0, sizeof(*mc_ext));
>  	mc_ext->common.type = MC_TYPE_EXTENDED;
> -	mc_ext->common.size = sizeof(mc_ext);
> +	mc_ext->common.size = sizeof(*mc_ext);
>  	mc_ext->mc_msrs = 3;
>  
>  	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -1232,11 +1232,10 @@ bool_t p2m_mem_access_check(unsigned lon
>      }
>  
>      *req_ptr = NULL;
> -    req = xmalloc(mem_event_request_t);
> +    req = xzalloc(mem_event_request_t);
>      if ( req )
>      {
>          *req_ptr = req;
> -        memset(req, 0, sizeof(req));
>          req->reason = MEM_EVENT_REASON_VIOLATION;
>  
>          /* Pause the current VCPU */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVjV-0007h6-Nm; Tue, 10 Apr 2012 07:43:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHVjT-0007gs-MV
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:43:19 +0000
Received: from [85.158.138.51:56504] by server-11.bemta-3.messagelabs.com id
	37/48-28543-694E38F4; Tue, 10 Apr 2012 07:43:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334043797!10441474!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20311 invoked from network); 10 Apr 2012 07:43:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 07:43:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 08:43:17 +0100
Message-Id: <4F8400B1020000780007CF26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 08:43:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
	<0908535327a5b01e49b6.1333641114@whitby.uk.xensource.com>
In-Reply-To: <0908535327a5b01e49b6.1333641114@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5 of 7 v2] x86: don't use .subsection when
 compiling with clang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333640955 -3600
> # Node ID 0908535327a5b01e49b69cd96db464be21ff3ee6
> # Parent  a93381049790e4f8a02f2322851f78175c254c5b
> x86: don't use .subsection when compiling with clang
> 
> LLVM's assembler doesn't support the .subsection directive, so put
> the out-of-line failure path in .fixup instead.

Given that it's a single place only, addressing this inline rather than
creating a proper abstraction is probably fine, so ...

> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r a93381049790 -r 0908535327a5 xen/include/asm-x86/spinlock.h
> --- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
> @@ -45,11 +45,19 @@ static always_inline int _raw_read_trylo
>      asm volatile (
>          "    lock; decl %0         \n"
>          "    jns 2f                \n"
> +#ifdef __clang__ /* clang's builtin assember can't do .subsection */
> +        "1:  .pushsection .fixup,\"ax\"\n"
> +#else
>          "1:  .subsection 1         \n"
> +#endif
>          "2:  lock; incl %0         \n"
>          "    decl %1               \n"
>          "    jmp 1b                \n"
> +#ifdef __clang__
> +        "    .popsection           \n"
> +#else
>          "    .subsection 0         \n"
> +#endif
>          : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
>  
>      return acquired;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVjV-0007h6-Nm; Tue, 10 Apr 2012 07:43:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHVjT-0007gs-MV
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:43:19 +0000
Received: from [85.158.138.51:56504] by server-11.bemta-3.messagelabs.com id
	37/48-28543-694E38F4; Tue, 10 Apr 2012 07:43:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334043797!10441474!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20311 invoked from network); 10 Apr 2012 07:43:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 07:43:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 08:43:17 +0100
Message-Id: <4F8400B1020000780007CF26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 08:43:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
	<0908535327a5b01e49b6.1333641114@whitby.uk.xensource.com>
In-Reply-To: <0908535327a5b01e49b6.1333641114@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5 of 7 v2] x86: don't use .subsection when
 compiling with clang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333640955 -3600
> # Node ID 0908535327a5b01e49b69cd96db464be21ff3ee6
> # Parent  a93381049790e4f8a02f2322851f78175c254c5b
> x86: don't use .subsection when compiling with clang
> 
> LLVM's assembler doesn't support the .subsection directive, so put
> the out-of-line failure path in .fixup instead.

Given that it's a single place only, addressing this inline rather than
creating a proper abstraction is probably fine, so ...

> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r a93381049790 -r 0908535327a5 xen/include/asm-x86/spinlock.h
> --- a/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/include/asm-x86/spinlock.h	Thu Apr 05 16:49:15 2012 +0100
> @@ -45,11 +45,19 @@ static always_inline int _raw_read_trylo
>      asm volatile (
>          "    lock; decl %0         \n"
>          "    jns 2f                \n"
> +#ifdef __clang__ /* clang's builtin assember can't do .subsection */
> +        "1:  .pushsection .fixup,\"ax\"\n"
> +#else
>          "1:  .subsection 1         \n"
> +#endif
>          "2:  lock; incl %0         \n"
>          "    decl %1               \n"
>          "    jmp 1b                \n"
> +#ifdef __clang__
> +        "    .popsection           \n"
> +#else
>          "    .subsection 0         \n"
> +#endif
>          : "=m" (rw->lock), "=r" (acquired) : "1" (1) : "memory" );
>  
>      return acquired;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:46:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVmI-0007sS-B3; Tue, 10 Apr 2012 07:46:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHVmH-0007sF-0g
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:46:13 +0000
Received: from [85.158.138.51:6246] by server-11.bemta-3.messagelabs.com id
	34/CC-28543-445E38F4; Tue, 10 Apr 2012 07:46:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334043971!21457883!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3571 invoked from network); 10 Apr 2012 07:46:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 07:46:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 08:46:10 +0100
Message-Id: <4F84015E020000780007CF37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 08:46:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM
 again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
> This series makes the hypervisor build with clang/LLVM again,
> after a certain amount of bit-rot.

I ack-ed the ones I uesfully can; the rest looks good to me too but
may need an ack from Keir.

Jan

> Since v1:
>  - Changed an xmalloc+memset pair to xzalloc in the memset patch
>  - Reworked the spinlock patch not to touch gcc builds
>  - Added a patch to indirect all __section__ directives through a macro.
>  - Commented up the ugly __attribute__((used)) change and moved it
>    into the definition of __section().
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 07:46:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 07:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHVmI-0007sS-B3; Tue, 10 Apr 2012 07:46:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHVmH-0007sF-0g
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 07:46:13 +0000
Received: from [85.158.138.51:6246] by server-11.bemta-3.messagelabs.com id
	34/CC-28543-445E38F4; Tue, 10 Apr 2012 07:46:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334043971!21457883!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3571 invoked from network); 10 Apr 2012 07:46:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 07:46:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 08:46:10 +0100
Message-Id: <4F84015E020000780007CF37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 08:46:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1333641109@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM
 again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
> This series makes the hypervisor build with clang/LLVM again,
> after a certain amount of bit-rot.

I ack-ed the ones I uesfully can; the rest looks good to me too but
may need an ack from Keir.

Jan

> Since v1:
>  - Changed an xmalloc+memset pair to xzalloc in the memset patch
>  - Reworked the spinlock patch not to touch gcc builds
>  - Added a patch to indirect all __section__ directives through a macro.
>  - Commented up the ugly __attribute__((used)) change and moved it
>    into the definition of __section().
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 08:36:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 08:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHWYg-0000f8-SX; Tue, 10 Apr 2012 08:36:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHWYe-0000f3-Tg
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 08:36:13 +0000
Received: from [85.158.139.83:4565] by server-11.bemta-5.messagelabs.com id
	A0/26-12959-CF0F38F4; Tue, 10 Apr 2012 08:36:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334046970!18518157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32079 invoked from network); 10 Apr 2012 08:36:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 08:36:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11843943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 08:35:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 09:35:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHWXw-0004gl-SH;
	Tue, 10 Apr 2012 08:35:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHWXw-0005if-Pg;
	Tue, 10 Apr 2012 09:35:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12627-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 09:35:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12627: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12627 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12627/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12617
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 12617

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv           3 host-install(3)              broken like 12617
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12617
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)             broken like 12617
 test-amd64-amd64-win          3 host-install(3)              broken like 12617
 test-amd64-i386-pv            3 host-install(3)              broken like 12617
 test-amd64-i386-xl-multivcpu  3 host-install(3)     broken in 12617 like 12595
 test-amd64-i386-xl            3 host-install(3)     broken in 12617 like 12606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12617 never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 08:36:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 08:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHWYg-0000f8-SX; Tue, 10 Apr 2012 08:36:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHWYe-0000f3-Tg
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 08:36:13 +0000
Received: from [85.158.139.83:4565] by server-11.bemta-5.messagelabs.com id
	A0/26-12959-CF0F38F4; Tue, 10 Apr 2012 08:36:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334046970!18518157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32079 invoked from network); 10 Apr 2012 08:36:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 08:36:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11843943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 08:35:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 09:35:29 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHWXw-0004gl-SH;
	Tue, 10 Apr 2012 08:35:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHWXw-0005if-Pg;
	Tue, 10 Apr 2012 09:35:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12627-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 09:35:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12627: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12627 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12627/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12617
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 12617

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv           3 host-install(3)              broken like 12617
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12617
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)             broken like 12617
 test-amd64-amd64-win          3 host-install(3)              broken like 12617
 test-amd64-i386-pv            3 host-install(3)              broken like 12617
 test-amd64-i386-xl-multivcpu  3 host-install(3)     broken in 12617 like 12595
 test-amd64-i386-xl            3 host-install(3)     broken in 12617 like 12606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12617 never pass

version targeted for testing:
 xen                  d690c7e896a2
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHX41-00011Z-JV; Tue, 10 Apr 2012 09:08:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHX3z-00011U-Km
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:08:35 +0000
Received: from [85.158.143.35:35927] by server-3.bemta-4.messagelabs.com id
	38/B9-05853-298F38F4; Tue, 10 Apr 2012 09:08:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334048913!11951150!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7113 invoked from network); 10 Apr 2012 09:08:34 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:08:34 -0000
Received: by bkcjg9 with SMTP id jg9so4607274bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 02:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jWDCtubNuGWC2Xl/CNONfiM41ig9OJVpc+7CsPXxmNA=;
	b=s5RBorT32sc9YO/Aw00pdWQzkDaMnK3hfgVgds3HcN0N+eHlXmoZws2fGSS8Dwq9uM
	Ovlk3Qkbb4mE+h/8Zf397KV2ZaVgQGogiCqftVrT38i781liQj9oRorsWChgZp8f+yZk
	RbvtZ+5Xn+wyIfIfKbuZZ/t6brMw378n9h1beWxsqs+FjOHY0HORZRnKHoBnbt1/+Keu
	+qVkbLxuFIlekavt9P0yrn4LpRL2n989BmDMG+0xCK+MlERpaHNgk5VJOfZOk8ntAMHX
	chB120mNQEylAoqLJj/bwAbJjVyOmTX1kHTt4f0NyN8jfYyo9WClSwl6RgP989EN87Oq
	UyfA==
Received: by 10.204.156.216 with SMTP id y24mr4338134bkw.60.1334048913660;
	Tue, 10 Apr 2012 02:08:33 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id cy11sm34619512bkb.7.2012.04.10.02.08.32
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 02:08:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Apr 2012 10:08:23 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CBA9B717.3D803%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM
	again
Thread-Index: Ac0W+XsB80m9PF7uk0OPkDBL/BXkvA==
In-Reply-To: <4F84015E020000780007CF37@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM
 again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/04/2012 08:46, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
>> This series makes the hypervisor build with clang/LLVM again,
>> after a certain amount of bit-rot.
> 
> I ack-ed the ones I uesfully can; the rest looks good to me too but
> may need an ack from Keir.

I acked already, I think, but just in case
Acked-by: Keir Fraser <keir@xen.org>

> Jan
> 
>> Since v1:
>>  - Changed an xmalloc+memset pair to xzalloc in the memset patch
>>  - Reworked the spinlock patch not to touch gcc builds
>>  - Added a patch to indirect all __section__ directives through a macro.
>>  - Commented up the ugly __attribute__((used)) change and moved it
>>    into the definition of __section().
>>  
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHX41-00011Z-JV; Tue, 10 Apr 2012 09:08:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHX3z-00011U-Km
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:08:35 +0000
Received: from [85.158.143.35:35927] by server-3.bemta-4.messagelabs.com id
	38/B9-05853-298F38F4; Tue, 10 Apr 2012 09:08:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334048913!11951150!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7113 invoked from network); 10 Apr 2012 09:08:34 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:08:34 -0000
Received: by bkcjg9 with SMTP id jg9so4607274bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 02:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jWDCtubNuGWC2Xl/CNONfiM41ig9OJVpc+7CsPXxmNA=;
	b=s5RBorT32sc9YO/Aw00pdWQzkDaMnK3hfgVgds3HcN0N+eHlXmoZws2fGSS8Dwq9uM
	Ovlk3Qkbb4mE+h/8Zf397KV2ZaVgQGogiCqftVrT38i781liQj9oRorsWChgZp8f+yZk
	RbvtZ+5Xn+wyIfIfKbuZZ/t6brMw378n9h1beWxsqs+FjOHY0HORZRnKHoBnbt1/+Keu
	+qVkbLxuFIlekavt9P0yrn4LpRL2n989BmDMG+0xCK+MlERpaHNgk5VJOfZOk8ntAMHX
	chB120mNQEylAoqLJj/bwAbJjVyOmTX1kHTt4f0NyN8jfYyo9WClSwl6RgP989EN87Oq
	UyfA==
Received: by 10.204.156.216 with SMTP id y24mr4338134bkw.60.1334048913660;
	Tue, 10 Apr 2012 02:08:33 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id cy11sm34619512bkb.7.2012.04.10.02.08.32
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 02:08:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Apr 2012 10:08:23 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CBA9B717.3D803%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM
	again
Thread-Index: Ac0W+XsB80m9PF7uk0OPkDBL/BXkvA==
In-Reply-To: <4F84015E020000780007CF37@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 7 v2] Make xen build with clang/LLVM
 again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/04/2012 08:46, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 05.04.12 at 17:51, Tim Deegan <tim@xen.org> wrote:
>> This series makes the hypervisor build with clang/LLVM again,
>> after a certain amount of bit-rot.
> 
> I ack-ed the ones I uesfully can; the rest looks good to me too but
> may need an ack from Keir.

I acked already, I think, but just in case
Acked-by: Keir Fraser <keir@xen.org>

> Jan
> 
>> Since v1:
>>  - Changed an xmalloc+memset pair to xzalloc in the memset patch
>>  - Reworked the spinlock patch not to touch gcc builds
>>  - Added a patch to indirect all __section__ directives through a macro.
>>  - Commented up the ugly __attribute__((used)) change and moved it
>>    into the definition of __section().
>>  
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:11:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHX6i-000190-6D; Tue, 10 Apr 2012 09:11:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SHX6g-00018s-PL
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 09:11:23 +0000
Received: from [85.158.138.51:17021] by server-12.bemta-3.messagelabs.com id
	A9/85-30663-939F38F4; Tue, 10 Apr 2012 09:11:21 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334049080!21281548!1
X-Originating-IP: [209.85.216.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16358 invoked from network); 10 Apr 2012 09:11:21 -0000
Received: from mail-qa0-f41.google.com (HELO mail-qa0-f41.google.com)
	(209.85.216.41)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:11:21 -0000
Received: by qafl39 with SMTP id l39so2728548qaf.7
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Apr 2012 02:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ywSeLF1mpseCAG0JlDUs+rHQsLCnZscRwxq7PdA4/w4=;
	b=WmgVyljbNhntVgaoGp9E3ANISekKiYcDYgu4yq8wUZhTdsbJe8BT3F4IHwrp/ubcnw
	/s5CaHKYR2nd0m4MPP7aGwT/CiB1LrNa+xHqcE7d4KoTAU3QUopd6mF9IT5Fd9wle8az
	zDtEUrCv2ybjSoSr1V0/f21hW/Z50D26tEBGYUNuG/i3sH+KCh2qThkhCxqhNIMoLquR
	PcTVt3/gcBsHYpUpOJ5vm4JRojUkqF+Z1pXU0xCEmvfHGi12U838rW5OEquHo48Gqdyu
	hxbOOpqsKtzNEVVp/psRZbqgmqbTUzJ61xIFdvVmUwfLIlolrMve2fOIpLFolCOp3uGn
	D95g==
MIME-Version: 1.0
Received: by 10.224.179.201 with SMTP id br9mr13416013qab.34.1334049079723;
	Tue, 10 Apr 2012 02:11:19 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Tue, 10 Apr 2012 02:11:19 -0700 (PDT)
In-Reply-To: <CAMrHX2UpGUp2ShbsCFyBFnvAq9-+Qs2gVdVVQGH_gN4YVpenEQ@mail.gmail.com>
References: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
	<20120406201343.GA20747@phenom.dumpdata.com>
	<CAMrHX2UpGUp2ShbsCFyBFnvAq9-+Qs2gVdVVQGH_gN4YVpenEQ@mail.gmail.com>
Date: Tue, 10 Apr 2012 10:11:19 +0100
X-Google-Sender-Auth: JrNKX5MMMPZT9CUADiYUb3GhQn4
Message-ID: <CAFLBxZY3FcrsZ80Di2Sx0PDq+QJh5GWcSMPZPnj4RYfEieYkVw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Hook <matthew.hook@otoy.com>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 6, 2012 at 9:23 PM, Matthew Hook <matthew.hook@otoy.com> wrote:
> Konrad, thanks for the reply.
>
> No I haven't tried the latest Xen.=A0It'd be good to test that just to see
> whether this bug is still there.
> Also kernel 3.3 would be worth trying.
> I'll get onto this next week and feedback.

I've seen "zombie" VMs hanging around after passing a device through
as well.  Xen reports that there is an outstanding reference to one of
the domain's pages.  It's fairly short on my to-do list.  I'll send
you an e-mail when I've got it fixed at my end, and you can see if it
fixes it for you as well.

P.S.: FYI, the convention on xen-devel is to reply in-line, not to
top-post. :-)  (Catches me out sometimes too.)

 -George

>
> Matt
>
>
> On 6 April 2012 13:13, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wro=
te:
>>
>> On Fri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:
>> > I've been having some problems with Windows HVM domains not shutting
>> > down
>> > cleanly. =A0I have the latest GPLPV drivers installed... although that
>> > doesn't appear to be related.
>> >
>> > The symptoms are exactly like this bug and it only occurs with xl.
>> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769
>> >
>> > In addition to that, it only seems to occur with a secondary graphics
>> > card
>> > being passed through.
>> > I end up with a null domain that I can't shutdown.
>> >
>> > Killing the qemu-dm process with kill pid sorts that out though.
>>
>> I think that was a bug with Xen. Have you tried to upgrade to the most
>> recent version?
>> >
>> > I'm running dom0 kernel 2.6.32.50.
>>
>> I don't recall that having an impact, but maybe it did..
>> Do you see the problem if you are running with the 3.3 kernel?
>>
>> >
>> > Matt
>>
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/xen-devel
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:11:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHX6i-000190-6D; Tue, 10 Apr 2012 09:11:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SHX6g-00018s-PL
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 09:11:23 +0000
Received: from [85.158.138.51:17021] by server-12.bemta-3.messagelabs.com id
	A9/85-30663-939F38F4; Tue, 10 Apr 2012 09:11:21 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334049080!21281548!1
X-Originating-IP: [209.85.216.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16358 invoked from network); 10 Apr 2012 09:11:21 -0000
Received: from mail-qa0-f41.google.com (HELO mail-qa0-f41.google.com)
	(209.85.216.41)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:11:21 -0000
Received: by qafl39 with SMTP id l39so2728548qaf.7
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Apr 2012 02:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ywSeLF1mpseCAG0JlDUs+rHQsLCnZscRwxq7PdA4/w4=;
	b=WmgVyljbNhntVgaoGp9E3ANISekKiYcDYgu4yq8wUZhTdsbJe8BT3F4IHwrp/ubcnw
	/s5CaHKYR2nd0m4MPP7aGwT/CiB1LrNa+xHqcE7d4KoTAU3QUopd6mF9IT5Fd9wle8az
	zDtEUrCv2ybjSoSr1V0/f21hW/Z50D26tEBGYUNuG/i3sH+KCh2qThkhCxqhNIMoLquR
	PcTVt3/gcBsHYpUpOJ5vm4JRojUkqF+Z1pXU0xCEmvfHGi12U838rW5OEquHo48Gqdyu
	hxbOOpqsKtzNEVVp/psRZbqgmqbTUzJ61xIFdvVmUwfLIlolrMve2fOIpLFolCOp3uGn
	D95g==
MIME-Version: 1.0
Received: by 10.224.179.201 with SMTP id br9mr13416013qab.34.1334049079723;
	Tue, 10 Apr 2012 02:11:19 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Tue, 10 Apr 2012 02:11:19 -0700 (PDT)
In-Reply-To: <CAMrHX2UpGUp2ShbsCFyBFnvAq9-+Qs2gVdVVQGH_gN4YVpenEQ@mail.gmail.com>
References: <CAMrHX2V6RuVT+YFU0jEM8x72jUmyd5+CCdhgMju_iFbLyos=vg@mail.gmail.com>
	<20120406201343.GA20747@phenom.dumpdata.com>
	<CAMrHX2UpGUp2ShbsCFyBFnvAq9-+Qs2gVdVVQGH_gN4YVpenEQ@mail.gmail.com>
Date: Tue, 10 Apr 2012 10:11:19 +0100
X-Google-Sender-Auth: JrNKX5MMMPZT9CUADiYUb3GhQn4
Message-ID: <CAFLBxZY3FcrsZ80Di2Sx0PDq+QJh5GWcSMPZPnj4RYfEieYkVw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Hook <matthew.hook@otoy.com>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Shutdown/restart bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 6, 2012 at 9:23 PM, Matthew Hook <matthew.hook@otoy.com> wrote:
> Konrad, thanks for the reply.
>
> No I haven't tried the latest Xen.=A0It'd be good to test that just to see
> whether this bug is still there.
> Also kernel 3.3 would be worth trying.
> I'll get onto this next week and feedback.

I've seen "zombie" VMs hanging around after passing a device through
as well.  Xen reports that there is an outstanding reference to one of
the domain's pages.  It's fairly short on my to-do list.  I'll send
you an e-mail when I've got it fixed at my end, and you can see if it
fixes it for you as well.

P.S.: FYI, the convention on xen-devel is to reply in-line, not to
top-post. :-)  (Catches me out sometimes too.)

 -George

>
> Matt
>
>
> On 6 April 2012 13:13, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wro=
te:
>>
>> On Fri, Apr 06, 2012 at 01:07:56PM -0700, Matthew Hook wrote:
>> > I've been having some problems with Windows HVM domains not shutting
>> > down
>> > cleanly. =A0I have the latest GPLPV drivers installed... although that
>> > doesn't appear to be related.
>> >
>> > The symptoms are exactly like this bug and it only occurs with xl.
>> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1769
>> >
>> > In addition to that, it only seems to occur with a secondary graphics
>> > card
>> > being passed through.
>> > I end up with a null domain that I can't shutdown.
>> >
>> > Killing the qemu-dm process with kill pid sorts that out though.
>>
>> I think that was a bug with Xen. Have you tried to upgrade to the most
>> recent version?
>> >
>> > I'm running dom0 kernel 2.6.32.50.
>>
>> I don't recall that having an impact, but maybe it did..
>> Do you see the problem if you are running with the 3.3 kernel?
>>
>> >
>> > Matt
>>
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/xen-devel
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:31:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXPz-0001Xm-UZ; Tue, 10 Apr 2012 09:31:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHXPy-0001Xh-Ec
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:31:18 +0000
Received: from [85.158.143.99:49697] by server-2.bemta-4.messagelabs.com id
	DA/0C-17550-5EDF38F4; Tue, 10 Apr 2012 09:31:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334050276!17736273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 10 Apr 2012 09:31:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:31:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11846804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 09:31:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:16 +0100
Message-ID: <1334050275.12209.153.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Tue, 10 Apr 2012 10:31:15 +0100
In-Reply-To: <CAF1ivSaU1+G0H3WwQ+F3THY60SheywOVcxpja+Z=bRksju7fVA@mail.gmail.com>
References: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
	<CAF1ivSaU1+G0H3WwQ+F3THY60SheywOVcxpja+Z=bRksju7fVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Wentao Zhang <wnlo.zwt@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to add debug information in libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-09 at 06:45 +0100, Lin Ming wrote:
> On Mon, Apr 9, 2012 at 1:09 PM, Wentao Zhang <wnlo.zwt@gmail.com> wrote:
> > Hi all,
> >         I want to add debug information in /tools/libxc/xc_csched.c, I have
> > used PERROR to output the information, but I don`t know how to find the
> > output information,
> >     I used xm dm to look at it, but there is nothing, and I also read the
> > xend.log, nothing either. How should I do to add debug information, and to
> > find the output information ?
> 
> I guess you are still using the old installed library.
> 
> Try:
> 
> export LD_LIBRARY_PATH=<your xen source dir>/tools/libxc:$LD_LIBRARY_PATH

If you are using xend then most of the libxc calls will happen in the
context of the long running xend daemon and not in the context of the xm
cli utility, so unless you have restarted xend with the new library you
may not see any change.

Also note that xend is deprecated and all new development should happen
with xl. In this case this has the advantage that xl is entirely self
contained so it is easier to arrange for it to run with specific
libraries etc.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:31:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXPz-0001Xm-UZ; Tue, 10 Apr 2012 09:31:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHXPy-0001Xh-Ec
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:31:18 +0000
Received: from [85.158.143.99:49697] by server-2.bemta-4.messagelabs.com id
	DA/0C-17550-5EDF38F4; Tue, 10 Apr 2012 09:31:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334050276!17736273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 10 Apr 2012 09:31:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:31:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11846804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 09:31:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:16 +0100
Message-ID: <1334050275.12209.153.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Tue, 10 Apr 2012 10:31:15 +0100
In-Reply-To: <CAF1ivSaU1+G0H3WwQ+F3THY60SheywOVcxpja+Z=bRksju7fVA@mail.gmail.com>
References: <CAJZuLfch5ennyAYNi58enkoaix2EPD1bhvEv0Wr3tKG4RKJ3dQ@mail.gmail.com>
	<CAF1ivSaU1+G0H3WwQ+F3THY60SheywOVcxpja+Z=bRksju7fVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Wentao Zhang <wnlo.zwt@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to add debug information in libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-09 at 06:45 +0100, Lin Ming wrote:
> On Mon, Apr 9, 2012 at 1:09 PM, Wentao Zhang <wnlo.zwt@gmail.com> wrote:
> > Hi all,
> >         I want to add debug information in /tools/libxc/xc_csched.c, I have
> > used PERROR to output the information, but I don`t know how to find the
> > output information,
> >     I used xm dm to look at it, but there is nothing, and I also read the
> > xend.log, nothing either. How should I do to add debug information, and to
> > find the output information ?
> 
> I guess you are still using the old installed library.
> 
> Try:
> 
> export LD_LIBRARY_PATH=<your xen source dir>/tools/libxc:$LD_LIBRARY_PATH

If you are using xend then most of the libxc calls will happen in the
context of the long running xend daemon and not in the context of the xm
cli utility, so unless you have restarted xend with the new library you
may not see any change.

Also note that xend is deprecated and all new development should happen
with xl. In this case this has the advantage that xl is entirely self
contained so it is easier to arrange for it to run with specific
libraries etc.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXR6-0001bn-HI; Tue, 10 Apr 2012 09:32:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.paumonne@citrix.com>) id 1SHXR5-0001bf-HN
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 09:32:27 +0000
Received: from [193.109.254.147:18201] by server-5.bemta-14.messagelabs.com id
	AB/D0-30733-A2EF38F4; Tue, 10 Apr 2012 09:32:26 +0000
X-Env-Sender: roger.paumonne@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334050344!3918136!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3436 invoked from network); 10 Apr 2012 09:32:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:32:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330923600"; d="scan'208";a="189614127"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 05:31:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 05:31:59 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.paumonne@citrix.com>)	id 1SHXQc-0005BZ-Rd;
	Tue, 10 Apr 2012 10:31:58 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.paumonne@citrix.com>
In-Reply-To: <1333702909575-5622369.post@n5.nabble.com>
Date: Tue, 10 Apr 2012 10:31:58 +0100
Message-ID: <9641D0F0-4AB5-48DA-9553-55EEED4D1D41@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
	<824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
	<1333702909575-5622369.post@n5.nabble.com>
To: Fantu <fantonifabio@tiscali.it>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
	arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 06/04/2012, a las 10:01, Fantu escribi=F3:
> Roger Pau Monne wrote
>> =

>> You should use autoconf 2.67 to update the configure script.
>> =

>> [...]
>> =

>> Why don't you use AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE?
>> =

> On notebook I have Mint 12 and Precise, on testing server Wheezy, all with
> autoconf 2.68, I'll redo on other pc with old s.o.

Don't worry about the autoconf version, just send the patch without the aut=
oconf output and clearly state in the commit message that the maintainer sh=
ould rebuild the configure script to apply the change.

> About AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE do enable/disable a=
nd
> export it, I not export but use it for bash command, I must need
> AC_ARG_ENABLE or my mistake about?

You are basically doing the same thing that this macro does, and you are "e=
xporting" it using AC_SUBST, so you can write the result to the config Make=
file (Tools.mk). Instead of saving the whole parameter line you wish to pas=
s to Qemu, just save the options chosen by the user (e.g: QEMUDEBUG :=3D y)=
 and generate the appropriate options to pass to Qemu from the tools Makefi=
le.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXR6-0001bn-HI; Tue, 10 Apr 2012 09:32:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.paumonne@citrix.com>) id 1SHXR5-0001bf-HN
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 09:32:27 +0000
Received: from [193.109.254.147:18201] by server-5.bemta-14.messagelabs.com id
	AB/D0-30733-A2EF38F4; Tue, 10 Apr 2012 09:32:26 +0000
X-Env-Sender: roger.paumonne@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334050344!3918136!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3436 invoked from network); 10 Apr 2012 09:32:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:32:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330923600"; d="scan'208";a="189614127"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 05:31:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 05:31:59 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.paumonne@citrix.com>)	id 1SHXQc-0005BZ-Rd;
	Tue, 10 Apr 2012 10:31:58 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.paumonne@citrix.com>
In-Reply-To: <1333702909575-5622369.post@n5.nabble.com>
Date: Tue, 10 Apr 2012 10:31:58 +0100
Message-ID: <9641D0F0-4AB5-48DA-9553-55EEED4D1D41@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
	<824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
	<1333702909575-5622369.post@n5.nabble.com>
To: Fantu <fantonifabio@tiscali.it>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
	arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 06/04/2012, a las 10:01, Fantu escribi=F3:
> Roger Pau Monne wrote
>> =

>> You should use autoconf 2.67 to update the configure script.
>> =

>> [...]
>> =

>> Why don't you use AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE?
>> =

> On notebook I have Mint 12 and Precise, on testing server Wheezy, all with
> autoconf 2.68, I'll redo on other pc with old s.o.

Don't worry about the autoconf version, just send the patch without the aut=
oconf output and clearly state in the commit message that the maintainer sh=
ould rebuild the configure script to apply the change.

> About AX_ARG_DEFAULT_DISABLE or AX_ARG_DEFAULT_ENABLE do enable/disable a=
nd
> export it, I not export but use it for bash command, I must need
> AC_ARG_ENABLE or my mistake about?

You are basically doing the same thing that this macro does, and you are "e=
xporting" it using AC_SUBST, so you can write the result to the config Make=
file (Tools.mk). Instead of saving the whole parameter line you wish to pas=
s to Qemu, just save the options chosen by the user (e.g: QEMUDEBUG :=3D y)=
 and generate the appropriate options to pass to Qemu from the tools Makefi=
le.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:52:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXkO-0002Ar-4J; Tue, 10 Apr 2012 09:52:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHXkM-0002Ak-PB
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:52:22 +0000
Received: from [85.158.139.83:60960] by server-4.bemta-5.messagelabs.com id
	F6/B0-10788-6D2048F4; Tue, 10 Apr 2012 09:52:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334051540!23044301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32228 invoked from network); 10 Apr 2012 09:52:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11848120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 09:52:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:52:19 +0100
Message-ID: <1334051539.12209.158.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Tue, 10 Apr 2012 10:52:19 +0100
In-Reply-To: <CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>	<20120406183618.GA13473@phenom.dumpdata.com>
	<CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-08 at 07:58 +0100, Lin Ming wrote:
> On Sat, Apr 7, 2012 at 2:36 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
> >> On 04/06/2012 10:41 AM, Lin Ming wrote:
> >> >Hi list,
> >> >
> >> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
> >> >
> >> >There are 2 PMU related projects listed on GSoC 2012 page.
> >> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> >> >
> >> >- Virtualization of the CPU Performance Monitoring Unit
> >> >- Perf support for Xen
> >> >
> >> >I'm interested on these 2 projects.
> >> Hi Lin,
> >>
> >> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
> >> See
> >> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> >> 2. The PMU project description in the wiki is vague. I know HVM
> >> guests support virtualized PMU. Please check vpmu.c files in /hvm,
> >> /svm, and /vmx directories. You better ask mentors for details
> >> (maybe this is XCP specific?).
> >
> > This is dom0 related. So being able to use perf to instrument
> > the hypervisor (and the guests from dom0).
> 
> For guests instrument:
> 
> How about use perf on guests(domU) directly?

I guess that would be a subset of the dom0 support? e.g. the ability for
a PV guest to run perf on itself.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:52:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXkO-0002Ar-4J; Tue, 10 Apr 2012 09:52:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHXkM-0002Ak-PB
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:52:22 +0000
Received: from [85.158.139.83:60960] by server-4.bemta-5.messagelabs.com id
	F6/B0-10788-6D2048F4; Tue, 10 Apr 2012 09:52:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334051540!23044301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32228 invoked from network); 10 Apr 2012 09:52:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 09:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11848120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 09:52:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:52:19 +0100
Message-ID: <1334051539.12209.158.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Tue, 10 Apr 2012 10:52:19 +0100
In-Reply-To: <CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>	<20120406183618.GA13473@phenom.dumpdata.com>
	<CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-08 at 07:58 +0100, Lin Ming wrote:
> On Sat, Apr 7, 2012 at 2:36 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
> >> On 04/06/2012 10:41 AM, Lin Ming wrote:
> >> >Hi list,
> >> >
> >> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
> >> >
> >> >There are 2 PMU related projects listed on GSoC 2012 page.
> >> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> >> >
> >> >- Virtualization of the CPU Performance Monitoring Unit
> >> >- Perf support for Xen
> >> >
> >> >I'm interested on these 2 projects.
> >> Hi Lin,
> >>
> >> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
> >> See
> >> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> >> 2. The PMU project description in the wiki is vague. I know HVM
> >> guests support virtualized PMU. Please check vpmu.c files in /hvm,
> >> /svm, and /vmx directories. You better ask mentors for details
> >> (maybe this is XCP specific?).
> >
> > This is dom0 related. So being able to use perf to instrument
> > the hypervisor (and the guests from dom0).
> 
> For guests instrument:
> 
> How about use perf on guests(domU) directly?

I guess that would be a subset of the dom0 support? e.g. the ability for
a PV guest to run perf on itself.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 09:56:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXoF-0002KC-P0; Tue, 10 Apr 2012 09:56:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SHXoE-0002K4-Q9
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:56:23 +0000
Received: from [85.158.143.35:62774] by server-1.bemta-4.messagelabs.com id
	34/72-20925-6C3048F4; Tue, 10 Apr 2012 09:56:22 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334051779!11734447!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30791 invoked from network); 10 Apr 2012 09:56:21 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-10.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Apr 2012 09:56:21 -0000
Received: from mail29-ch1-R.bigfish.com (10.43.68.231) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 09:56:19 +0000
Received: from mail29-ch1 (localhost [127.0.0.1])	by mail29-ch1-R.bigfish.com
	(Postfix) with ESMTP id 32DCC4A019F	for <xen-devel@lists.xen.org>;
	Tue, 10 Apr 2012 09:56:19 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail29-ch1 (localhost.localdomain [127.0.0.1]) by mail29-ch1
	(MessageSwitch) id 1334051777902281_15413;
	Tue, 10 Apr 2012 09:56:17 +0000 (UTC)
Received: from CH1EHSMHS023.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.231])	by mail29-ch1.bigfish.com (Postfix) with ESMTP id
	DA1E31C004A
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 09:56:17 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 09:56:16 +0000
X-WSS-ID: 0M29CXN-02-1E3-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2BEAEC80C9	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012
	04:56:10 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Apr 2012 04:56:20 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 10 Apr 2012 04:56:12 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Apr 2012
	05:56:12 -0400
Message-ID: <4F8403BA.3040904@amd.com>
Date: Tue, 10 Apr 2012 11:56:10 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------060904010403020304010403"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] blktap: build fix uncovered with c/s 25149
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------060904010403020304010403
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Fix build error uncovered with c/s 25149 when compiling
tools w/o MEMSHR.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

--------------060904010403020304010403
Content-Type: text/plain; name="xen_tools_blktapctrl.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_blktapctrl.diff"
Content-Description: xen_tools_blktapctrl.diff

diff -r 5fb9677f06f9 tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c	Thu Apr 05 17:41:34 2012 +0200
+++ b/tools/blktap/drivers/blktapctrl.c	Tue Apr 10 11:46:03 2012 +0200
@@ -50,7 +50,9 @@
 #include <xs.h>
 #include <sys/time.h>
 #include <syslog.h>
+#ifdef MEMSHR
 #include <memshr.h>
+#endif
 #include <sys/stat.h>
                                                                      
 #include "blktaplib.h"

--------------060904010403020304010403
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060904010403020304010403--


From xen-devel-bounces@lists.xen.org Tue Apr 10 09:56:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 09:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXoF-0002KC-P0; Tue, 10 Apr 2012 09:56:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SHXoE-0002K4-Q9
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 09:56:23 +0000
Received: from [85.158.143.35:62774] by server-1.bemta-4.messagelabs.com id
	34/72-20925-6C3048F4; Tue, 10 Apr 2012 09:56:22 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334051779!11734447!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30791 invoked from network); 10 Apr 2012 09:56:21 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-10.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Apr 2012 09:56:21 -0000
Received: from mail29-ch1-R.bigfish.com (10.43.68.231) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 09:56:19 +0000
Received: from mail29-ch1 (localhost [127.0.0.1])	by mail29-ch1-R.bigfish.com
	(Postfix) with ESMTP id 32DCC4A019F	for <xen-devel@lists.xen.org>;
	Tue, 10 Apr 2012 09:56:19 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail29-ch1 (localhost.localdomain [127.0.0.1]) by mail29-ch1
	(MessageSwitch) id 1334051777902281_15413;
	Tue, 10 Apr 2012 09:56:17 +0000 (UTC)
Received: from CH1EHSMHS023.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.231])	by mail29-ch1.bigfish.com (Postfix) with ESMTP id
	DA1E31C004A
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 09:56:17 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 09:56:16 +0000
X-WSS-ID: 0M29CXN-02-1E3-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2BEAEC80C9	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012
	04:56:10 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Apr 2012 04:56:20 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 10 Apr 2012 04:56:12 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Apr 2012
	05:56:12 -0400
Message-ID: <4F8403BA.3040904@amd.com>
Date: Tue, 10 Apr 2012 11:56:10 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------060904010403020304010403"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] blktap: build fix uncovered with c/s 25149
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------060904010403020304010403
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Fix build error uncovered with c/s 25149 when compiling
tools w/o MEMSHR.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

--------------060904010403020304010403
Content-Type: text/plain; name="xen_tools_blktapctrl.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_blktapctrl.diff"
Content-Description: xen_tools_blktapctrl.diff

diff -r 5fb9677f06f9 tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c	Thu Apr 05 17:41:34 2012 +0200
+++ b/tools/blktap/drivers/blktapctrl.c	Tue Apr 10 11:46:03 2012 +0200
@@ -50,7 +50,9 @@
 #include <xs.h>
 #include <sys/time.h>
 #include <syslog.h>
+#ifdef MEMSHR
 #include <memshr.h>
+#endif
 #include <sys/stat.h>
                                                                      
 #include "blktaplib.h"

--------------060904010403020304010403
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060904010403020304010403--


From xen-devel-bounces@lists.xen.org Tue Apr 10 10:05:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXwW-0002d6-Ok; Tue, 10 Apr 2012 10:04:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHXwV-0002cw-0a
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:04:55 +0000
Received: from [85.158.138.51:14055] by server-10.bemta-3.messagelabs.com id
	3E/6C-15637-6C5048F4; Tue, 10 Apr 2012 10:04:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334052293!21333748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25047 invoked from network); 10 Apr 2012 10:04:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:04:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11848808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:04:52 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:04:52 +0100
Message-ID: <1334052292.12209.164.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "greg@enjellic.com" <greg@enjellic.com>
Date: Tue, 10 Apr 2012 10:04:52 +0000
In-Reply-To: <201204071559.q37Fx5u3004223@wind.enjellic.com>
References: <201204071559.q37Fx5u3004223@wind.enjellic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-07 at 16:59 +0100, Dr. Greg Wettstein wrote:
> On Mar 30, 12:23pm, Ian Campbell wrote:
> } Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
> 
> Hi, hope the weekend is going well for everyone.
> 
> Sorry for the delay in getting back to everyone on this, had a
> deadline on another project.
> 
> > On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > > I think an approach worth trying would be to have
> > > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > > doing the actual detach. i.e. it would respond with "Yes, I will do
> > > that" rather than "Yes, I have done that". My speculation is that this
> > > will allow libxl to continue and hopefully avoid the deadlock.
> 
> > This seems to be the case as the following fixes things for
> > me. Thanks very much for your analysis which lead me to this
> > solution...
> 
> I ported your fix into 4.1.2 but I think we still have a problem, at
> least in this codebase.
> 
> I no longer see the select timeout delay when xl shuts down but upon
> shutdown the minor number is not freed.  A 'tap-ctl list' shows a
> steadily increasing set of orphaned minor numbers as VM's are started
> up and shutdown.
> 
> Are you seeing this in your development codebase?

It turns out that I am, yes. e.g. after starting/stopping a guest 3
times:
# tap-ctl list
       -  0    -          - -
       -  1    -          - -
       -  2    -          - -

> The culprit is a failed ioctl call for BLKTAP2_IOCTL_FREE_TAP in
> tap_ctl_free().  The underlying reason for the ioctl failure is the
> check in [linuxsrc]:drivers/block/blktap/ring.c:blktap_ring_destroy()

drivers/*xen*/... right? Or do you have a different blktap to me?

> for whether or not the task_struct pointer in the blktap_ring
> structure has been NULLed.
> 
> Which certainly makes sense since there is a race between xl's call to
> tap_ctl_free() and tapdisk2 getting to the point where it can close
> its descriptor to the blktap instance and thus invoke the .release
> method which translates into a call to blktap_ring_release() which
> NULL's the task_struct pointer.

Sounds right, but then you would expect both the ioctl and release path
to cleanup, depending on who loses the race? 

There also seems to be a BLKTAP_SHUTDOWN_REQUESTED bit which looks like
it is involved somehow...

We've gotten way beyond my understanding of blktap internals though.

> If you are not seeing the orphan minor numbers there must be ordering
> changes in the unstable version of xl which eliminate or alters the
> race timing.
> 
> For the sake of completeness of information for this thread I captured
> the following stack trace of a tapdisk2 when it is deadlocked against
> xl:
[... thanks ...]
> Let me know if you are seeing the issues I'm seeing, in the meantime I
> will keep hunting to see if I can rundown the ultimate cause of the
> deadlock.  Given the above trace it has to be an issue with xl
> orchestrating the release of resources which reference the tapdev
> block device.

I'm not convinced that the shutdown stuff on the kernel side isn't
either horribly broken or at best fragile (perhaps xl just tickles it
differently to xend).

Please do keep hunting and let us know what you find...

Thanks,
Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:05:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHXwW-0002d6-Ok; Tue, 10 Apr 2012 10:04:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHXwV-0002cw-0a
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:04:55 +0000
Received: from [85.158.138.51:14055] by server-10.bemta-3.messagelabs.com id
	3E/6C-15637-6C5048F4; Tue, 10 Apr 2012 10:04:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334052293!21333748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25047 invoked from network); 10 Apr 2012 10:04:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:04:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11848808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:04:52 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:04:52 +0100
Message-ID: <1334052292.12209.164.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "greg@enjellic.com" <greg@enjellic.com>
Date: Tue, 10 Apr 2012 10:04:52 +0000
In-Reply-To: <201204071559.q37Fx5u3004223@wind.enjellic.com>
References: <201204071559.q37Fx5u3004223@wind.enjellic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-07 at 16:59 +0100, Dr. Greg Wettstein wrote:
> On Mar 30, 12:23pm, Ian Campbell wrote:
> } Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
> 
> Hi, hope the weekend is going well for everyone.
> 
> Sorry for the delay in getting back to everyone on this, had a
> deadline on another project.
> 
> > On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > > I think an approach worth trying would be to have
> > > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > > doing the actual detach. i.e. it would respond with "Yes, I will do
> > > that" rather than "Yes, I have done that". My speculation is that this
> > > will allow libxl to continue and hopefully avoid the deadlock.
> 
> > This seems to be the case as the following fixes things for
> > me. Thanks very much for your analysis which lead me to this
> > solution...
> 
> I ported your fix into 4.1.2 but I think we still have a problem, at
> least in this codebase.
> 
> I no longer see the select timeout delay when xl shuts down but upon
> shutdown the minor number is not freed.  A 'tap-ctl list' shows a
> steadily increasing set of orphaned minor numbers as VM's are started
> up and shutdown.
> 
> Are you seeing this in your development codebase?

It turns out that I am, yes. e.g. after starting/stopping a guest 3
times:
# tap-ctl list
       -  0    -          - -
       -  1    -          - -
       -  2    -          - -

> The culprit is a failed ioctl call for BLKTAP2_IOCTL_FREE_TAP in
> tap_ctl_free().  The underlying reason for the ioctl failure is the
> check in [linuxsrc]:drivers/block/blktap/ring.c:blktap_ring_destroy()

drivers/*xen*/... right? Or do you have a different blktap to me?

> for whether or not the task_struct pointer in the blktap_ring
> structure has been NULLed.
> 
> Which certainly makes sense since there is a race between xl's call to
> tap_ctl_free() and tapdisk2 getting to the point where it can close
> its descriptor to the blktap instance and thus invoke the .release
> method which translates into a call to blktap_ring_release() which
> NULL's the task_struct pointer.

Sounds right, but then you would expect both the ioctl and release path
to cleanup, depending on who loses the race? 

There also seems to be a BLKTAP_SHUTDOWN_REQUESTED bit which looks like
it is involved somehow...

We've gotten way beyond my understanding of blktap internals though.

> If you are not seeing the orphan minor numbers there must be ordering
> changes in the unstable version of xl which eliminate or alters the
> race timing.
> 
> For the sake of completeness of information for this thread I captured
> the following stack trace of a tapdisk2 when it is deadlocked against
> xl:
[... thanks ...]
> Let me know if you are seeing the issues I'm seeing, in the meantime I
> will keep hunting to see if I can rundown the ultimate cause of the
> deadlock.  Given the above trace it has to be an issue with xl
> orchestrating the release of resources which reference the tapdev
> block device.

I'm not convinced that the shutdown stuff on the kernel side isn't
either horribly broken or at best fragile (perhaps xl just tickles it
differently to xend).

Please do keep hunting and let us know what you find...

Thanks,
Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:09:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHY0T-0002kS-DW; Tue, 10 Apr 2012 10:09:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SHY0S-0002kM-IJ
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:09:00 +0000
Received: from [193.109.254.147:37831] by server-10.bemta-14.messagelabs.com
	id 74/1E-05847-BB6048F4; Tue, 10 Apr 2012 10:08:59 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334052537!801353!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 10 Apr 2012 10:08:59 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Apr 2012 10:08:59 -0000
Received: from mail114-ch1-R.bigfish.com (10.43.68.233) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 10:08:57 +0000
Received: from mail114-ch1 (localhost [127.0.0.1])	by
	mail114-ch1-R.bigfish.com (Postfix) with ESMTP id 0C3E6240481;
	Tue, 10 Apr 2012 10:08:57 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail114-ch1 (localhost.localdomain [127.0.0.1]) by mail114-ch1
	(MessageSwitch) id 1334052535238519_17155;
	Tue, 10 Apr 2012 10:08:55 +0000 (UTC)
Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.240])	by mail114-ch1.bigfish.com (Postfix) with ESMTP id
	2AF25200D7;	Tue, 10 Apr 2012 10:08:55 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 10:08:54 +0000
X-WSS-ID: 0M29DIQ-02-23L-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26BA5C80D3;	Tue, 10 Apr 2012 05:08:50 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Apr 2012 05:09:00 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 10 Apr 2012 05:08:52 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Apr 2012
	06:08:52 -0400
Message-ID: <4F8406B2.6090001@amd.com>
Date: Tue, 10 Apr 2012 12:08:50 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
	<a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
In-Reply-To: <a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 7 v2] x86: fix memset(ptr, 0,
 sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/12 17:51, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan<tim@xen.org>
> # Date 1333640955 -3600
> # Node ID a93381049790e4f8a02f2322851f78175c254c5b
> # Parent  4674ce03c62a3e916954fd445b4510ffe72e64f4
> x86: fix memset(ptr, 0, sizeof ptr).
>
> Signed-off-by: Tim Deegan<tim@xen.org>

Acked-by: Christoph Egger <Christoph.Egger@amd.com>

>
> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/cpu/mcheck/amd_f10.c
> --- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
>   		return NULL;
>   	}
>
> -	memset(mc_ext, 0, sizeof(mc_ext));
> +	memset(mc_ext, 0, sizeof(*mc_ext));
>   	mc_ext->common.type = MC_TYPE_EXTENDED;
> -	mc_ext->common.size = sizeof(mc_ext);
> +	mc_ext->common.size = sizeof(*mc_ext);
>   	mc_ext->mc_msrs = 3;
>
>   	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -1232,11 +1232,10 @@ bool_t p2m_mem_access_check(unsigned lon
>       }
>
>       *req_ptr = NULL;
> -    req = xmalloc(mem_event_request_t);
> +    req = xzalloc(mem_event_request_t);
>       if ( req )
>       {
>           *req_ptr = req;
> -        memset(req, 0, sizeof(req));
>           req->reason = MEM_EVENT_REASON_VIOLATION;
>
>           /* Pause the current VCPU */
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:09:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHY0T-0002kS-DW; Tue, 10 Apr 2012 10:09:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SHY0S-0002kM-IJ
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:09:00 +0000
Received: from [193.109.254.147:37831] by server-10.bemta-14.messagelabs.com
	id 74/1E-05847-BB6048F4; Tue, 10 Apr 2012 10:08:59 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334052537!801353!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 10 Apr 2012 10:08:59 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Apr 2012 10:08:59 -0000
Received: from mail114-ch1-R.bigfish.com (10.43.68.233) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 10:08:57 +0000
Received: from mail114-ch1 (localhost [127.0.0.1])	by
	mail114-ch1-R.bigfish.com (Postfix) with ESMTP id 0C3E6240481;
	Tue, 10 Apr 2012 10:08:57 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail114-ch1 (localhost.localdomain [127.0.0.1]) by mail114-ch1
	(MessageSwitch) id 1334052535238519_17155;
	Tue, 10 Apr 2012 10:08:55 +0000 (UTC)
Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.240])	by mail114-ch1.bigfish.com (Postfix) with ESMTP id
	2AF25200D7;	Tue, 10 Apr 2012 10:08:55 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Apr 2012 10:08:54 +0000
X-WSS-ID: 0M29DIQ-02-23L-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26BA5C80D3;	Tue, 10 Apr 2012 05:08:50 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Apr 2012 05:09:00 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 10 Apr 2012 05:08:52 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Apr 2012
	06:08:52 -0400
Message-ID: <4F8406B2.6090001@amd.com>
Date: Tue, 10 Apr 2012 12:08:50 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1333641109@whitby.uk.xensource.com>
	<a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
In-Reply-To: <a93381049790e4f8a02f.1333641113@whitby.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 7 v2] x86: fix memset(ptr, 0,
 sizeof ptr)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/05/12 17:51, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan<tim@xen.org>
> # Date 1333640955 -3600
> # Node ID a93381049790e4f8a02f2322851f78175c254c5b
> # Parent  4674ce03c62a3e916954fd445b4510ffe72e64f4
> x86: fix memset(ptr, 0, sizeof ptr).
>
> Signed-off-by: Tim Deegan<tim@xen.org>

Acked-by: Christoph Egger <Christoph.Egger@amd.com>

>
> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/cpu/mcheck/amd_f10.c
> --- a/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -73,9 +73,9 @@ amd_f10_handler(struct mc_info *mi, uint
>   		return NULL;
>   	}
>
> -	memset(mc_ext, 0, sizeof(mc_ext));
> +	memset(mc_ext, 0, sizeof(*mc_ext));
>   	mc_ext->common.type = MC_TYPE_EXTENDED;
> -	mc_ext->common.size = sizeof(mc_ext);
> +	mc_ext->common.size = sizeof(*mc_ext);
>   	mc_ext->mc_msrs = 3;
>
>   	mc_ext->mc_msr[0].reg = MSR_F10_MC4_MISC1;
> diff -r 4674ce03c62a -r a93381049790 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> +++ b/xen/arch/x86/mm/p2m.c	Thu Apr 05 16:49:15 2012 +0100
> @@ -1232,11 +1232,10 @@ bool_t p2m_mem_access_check(unsigned lon
>       }
>
>       *req_ptr = NULL;
> -    req = xmalloc(mem_event_request_t);
> +    req = xzalloc(mem_event_request_t);
>       if ( req )
>       {
>           *req_ptr = req;
> -        memset(req, 0, sizeof(req));
>           req->reason = MEM_EVENT_REASON_VIOLATION;
>
>           /* Pause the current VCPU */
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHY98-0002yx-DR; Tue, 10 Apr 2012 10:17:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHY96-0002ys-Th
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:17:57 +0000
Received: from [85.158.138.51:22080] by server-1.bemta-3.messagelabs.com id
	5D/C8-04539-3D8048F4; Tue, 10 Apr 2012 10:17:55 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334053071!21488877!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10769 invoked from network); 10 Apr 2012 10:17:53 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 10:17:53 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHY8z-0001ns-RW
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 03:17:49 -0700
Date: Tue, 10 Apr 2012 03:17:49 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334053069843-5629542.post@n5.nabble.com>
In-Reply-To: <1333699761452-5622311.post@n5.nabble.com>
References: <1333699761452-5622311.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Question about hvmloader, vgabios and qxl problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm still desperately trying to solve the problem videoram/qxl.
About hvmloader I see pci.c on tools/firmware/hvmloader, virtual_vga
considers only std and cirrus, this can cause problems?
About memory allocation on libxc have limit for effective videoram
allocation to 16mb? I see for example this old patch:
changeset 19036 with allowing user to specify up to 16mb of vram
I see change on tools/libxc/xc_hvm_build.c but I not understand if limit
memory allocation or is other.
About libxl there are recent patch about ram/videoram fix but I not sure I
am not sure of the complete resolution of the problem in libxl, here too,
unfortunately I have trouble understanding some things and I can not find
any problems.
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Question-about-hvmloader-vgabios-and-qxl-problem-tp5622311p5629542.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHY98-0002yx-DR; Tue, 10 Apr 2012 10:17:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHY96-0002ys-Th
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:17:57 +0000
Received: from [85.158.138.51:22080] by server-1.bemta-3.messagelabs.com id
	5D/C8-04539-3D8048F4; Tue, 10 Apr 2012 10:17:55 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334053071!21488877!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10769 invoked from network); 10 Apr 2012 10:17:53 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 10:17:53 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHY8z-0001ns-RW
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 03:17:49 -0700
Date: Tue, 10 Apr 2012 03:17:49 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334053069843-5629542.post@n5.nabble.com>
In-Reply-To: <1333699761452-5622311.post@n5.nabble.com>
References: <1333699761452-5622311.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Question about hvmloader, vgabios and qxl problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm still desperately trying to solve the problem videoram/qxl.
About hvmloader I see pci.c on tools/firmware/hvmloader, virtual_vga
considers only std and cirrus, this can cause problems?
About memory allocation on libxc have limit for effective videoram
allocation to 16mb? I see for example this old patch:
changeset 19036 with allowing user to specify up to 16mb of vram
I see change on tools/libxc/xc_hvm_build.c but I not understand if limit
memory allocation or is other.
About libxl there are recent patch about ram/videoram fix but I not sure I
am not sure of the complete resolution of the problem in libxl, here too,
unfortunately I have trouble understanding some things and I can not find
any problems.
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Question-about-hvmloader-vgabios-and-qxl-problem-tp5622311p5629542.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYFr-00038U-Aq; Tue, 10 Apr 2012 10:24:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHYFp-00038O-LI
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:24:53 +0000
Received: from [85.158.143.35:13517] by server-2.bemta-4.messagelabs.com id
	82/BF-17550-47A048F4; Tue, 10 Apr 2012 10:24:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334053491!11966628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4067 invoked from network); 10 Apr 2012 10:24:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:24:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11849540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:24:51 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:24:50 +0100
Message-ID: <1334053490.12209.176.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 10:24:50 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Plan for a 4.2 release:
http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html

The time line is as follows:

19 March        -- TODO list locked down
2 April         -- Feature Freeze
					               << WE ARE HERE
Mid/Late April  -- First release candidate
Weekly          -- RCN+1 until it is ready

The updated TODO list follows. Per the release plan a strong case will
now have to be made as to why new items should be added to the list,
especially as a blocker, rather than deferred to 4.3.

We have now entered Feature Freeze. Patches which have been posted
before or which address something on the list below are still acceptable
(for now, we will gradually be getting stricter about this), everything
else will be deferred until 4.3 by default.

Lots more DONE this week, still a few big ticket items or items with no
progress (that I've noticed) please let me know if the status of
anything has changed.

>From next week I think I will start also tracking bugs on these lists.
Please let me know if you have something which you feel should be listed
here, as well as your justification for it being a blocker rather than
"nice to fix".

hypervisor, blockers:
      * NONE?
 =

tools, blockers:
      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * Safe fork vs. fd handling hooks. Involves API changes
                (Ian J, patches posted)
              * locking/serialization, e.g., for domain creation. As of
                now,  nothing is provided for this purpose, and
                downstream toolstacks have to put their own mechanisms
                in place. E.g., xl uses a fcntl() lock around the whole
                process of domain creation. It should OTOH be libxl job
                to offer a proper set of hooks --placed at the proper
                spots during the domain creation process-- for the
                downstreams to fill with the proper callbacks. (Dario
                Faggioli)
                      * Thinking to defer this until 4.3?
              * agree & document compatibility guarantees + associated
                technical measures (Ian C, DONE)
      * xl compatibility with xm:
              * feature parity wrt driver domain support (George Dunlap,
                DONE)
              * xl support for "rtc_timeoffset" and "localtime" (Lin
                Ming, DONE)
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.
      * Domain 0 block attach & general hotplug when using qdisk backend
        (need to start qemu as necessary etc) (Stefano S, patches
        posted)
      * file:// backend performance. qemu-xen-tradition's qdisk is quite
        slow & blktap2 not available in upstream kernels. Need to
        consider our options:
              * qemu-xen's qdisk is thought to be well performing but
                qemu-xen is not yet the default. Complexity arising from
                splitting qemu-for-qdisk out from qemu-for-dm and
                running N qemu's.
              * potentially fully userspace blktap could be ready for
                4.2 (unlikely to be available in 4.2)
              * use /dev/loop+blkback. This requires loop driver AIO and
                O_DIRECT patches which are not (AFAIK) yet upstream.
              * Leverage XCP's blktap2 DKMS work. (Useful fallback for
                some usecases
        Stefano has done a lot of work here and has proposed some
        performance improvements for qdisk in both qemu-xen and
        qemu-xen-traditional which make them a plausible alternative for
        Xen 4.2. This is likely the route we will now take. Need to
        mention in release notes?
      * Improved Hotplug script support (Roger Pau Monn=E9, patches
        posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monn=E9)

hypervisor, nice to have:
      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al -- patches posted)
              * "The last patch to use a waitqueue in
                __get_gfn_type_access() from Tim works.  However, there
                are a few users who call __get_gfn_type_access with the
                domain_lock held. This part needs to be addressed in
                some way."
      * Sharing support for AMD (Tim, Andres).
      * PoD performance improvements (George Dunlap)

tools, nice to have:
      * Configure/control paging via xl/libxl (Olaf Herring, lots of
        discussion around interface, general consensus reached on what
        it should look like. Olaf has let me know that he is probably
        not going to have time to do this for 4.2, will likely slip to
        4.3 unless someone else want to pick up that work)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard,
                patches sent)
              * Upstream qemu save restore (Anthony Perard, Stefano
                Stabellini, qemu patches applied, waiting for libxl etc
                side which has been recently reposted)
      * Nested-virtualisation. Currently "experimental". Likely to
        release that way.
              * Nested SVM. Tested in a variety of configurations but
                still some issues with the most important use case (w7
                XP mode) [0]  (Christoph Egger)
              * Nested VMX. Needs nested EPT to be genuinely useful.
                Need more data on testedness etc (Intel)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, patches reposted recently, was blocked behind qemu
        save restore patches which are now in)
      * xl compatibility with xm:
              * xl support for autospawning vncviewer (vncviewer=3D1 or
                otherwise) (Goncalo Gomes, patches posted)
              * support for vif "rate" parameter (Mathieu Gagn=E9, patches
                posted)
              * expose PCI back "permissive" parameter (George Dunlap)

[0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYFr-00038U-Aq; Tue, 10 Apr 2012 10:24:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHYFp-00038O-LI
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:24:53 +0000
Received: from [85.158.143.35:13517] by server-2.bemta-4.messagelabs.com id
	82/BF-17550-47A048F4; Tue, 10 Apr 2012 10:24:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334053491!11966628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4067 invoked from network); 10 Apr 2012 10:24:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:24:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11849540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:24:51 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:24:50 +0100
Message-ID: <1334053490.12209.176.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 10:24:50 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Plan for a 4.2 release:
http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html

The time line is as follows:

19 March        -- TODO list locked down
2 April         -- Feature Freeze
					               << WE ARE HERE
Mid/Late April  -- First release candidate
Weekly          -- RCN+1 until it is ready

The updated TODO list follows. Per the release plan a strong case will
now have to be made as to why new items should be added to the list,
especially as a blocker, rather than deferred to 4.3.

We have now entered Feature Freeze. Patches which have been posted
before or which address something on the list below are still acceptable
(for now, we will gradually be getting stricter about this), everything
else will be deferred until 4.3 by default.

Lots more DONE this week, still a few big ticket items or items with no
progress (that I've noticed) please let me know if the status of
anything has changed.

>From next week I think I will start also tracking bugs on these lists.
Please let me know if you have something which you feel should be listed
here, as well as your justification for it being a blocker rather than
"nice to fix".

hypervisor, blockers:
      * NONE?
 =

tools, blockers:
      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * Safe fork vs. fd handling hooks. Involves API changes
                (Ian J, patches posted)
              * locking/serialization, e.g., for domain creation. As of
                now,  nothing is provided for this purpose, and
                downstream toolstacks have to put their own mechanisms
                in place. E.g., xl uses a fcntl() lock around the whole
                process of domain creation. It should OTOH be libxl job
                to offer a proper set of hooks --placed at the proper
                spots during the domain creation process-- for the
                downstreams to fill with the proper callbacks. (Dario
                Faggioli)
                      * Thinking to defer this until 4.3?
              * agree & document compatibility guarantees + associated
                technical measures (Ian C, DONE)
      * xl compatibility with xm:
              * feature parity wrt driver domain support (George Dunlap,
                DONE)
              * xl support for "rtc_timeoffset" and "localtime" (Lin
                Ming, DONE)
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.
      * Domain 0 block attach & general hotplug when using qdisk backend
        (need to start qemu as necessary etc) (Stefano S, patches
        posted)
      * file:// backend performance. qemu-xen-tradition's qdisk is quite
        slow & blktap2 not available in upstream kernels. Need to
        consider our options:
              * qemu-xen's qdisk is thought to be well performing but
                qemu-xen is not yet the default. Complexity arising from
                splitting qemu-for-qdisk out from qemu-for-dm and
                running N qemu's.
              * potentially fully userspace blktap could be ready for
                4.2 (unlikely to be available in 4.2)
              * use /dev/loop+blkback. This requires loop driver AIO and
                O_DIRECT patches which are not (AFAIK) yet upstream.
              * Leverage XCP's blktap2 DKMS work. (Useful fallback for
                some usecases
        Stefano has done a lot of work here and has proposed some
        performance improvements for qdisk in both qemu-xen and
        qemu-xen-traditional which make them a plausible alternative for
        Xen 4.2. This is likely the route we will now take. Need to
        mention in release notes?
      * Improved Hotplug script support (Roger Pau Monn=E9, patches
        posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monn=E9)

hypervisor, nice to have:
      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al -- patches posted)
              * "The last patch to use a waitqueue in
                __get_gfn_type_access() from Tim works.  However, there
                are a few users who call __get_gfn_type_access with the
                domain_lock held. This part needs to be addressed in
                some way."
      * Sharing support for AMD (Tim, Andres).
      * PoD performance improvements (George Dunlap)

tools, nice to have:
      * Configure/control paging via xl/libxl (Olaf Herring, lots of
        discussion around interface, general consensus reached on what
        it should look like. Olaf has let me know that he is probably
        not going to have time to do this for 4.2, will likely slip to
        4.3 unless someone else want to pick up that work)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard,
                patches sent)
              * Upstream qemu save restore (Anthony Perard, Stefano
                Stabellini, qemu patches applied, waiting for libxl etc
                side which has been recently reposted)
      * Nested-virtualisation. Currently "experimental". Likely to
        release that way.
              * Nested SVM. Tested in a variety of configurations but
                still some issues with the most important use case (w7
                XP mode) [0]  (Christoph Egger)
              * Nested VMX. Needs nested EPT to be genuinely useful.
                Need more data on testedness etc (Intel)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, patches reposted recently, was blocked behind qemu
        save restore patches which are now in)
      * xl compatibility with xm:
              * xl support for autospawning vncviewer (vncviewer=3D1 or
                otherwise) (Goncalo Gomes, patches posted)
              * support for vif "rate" parameter (Mathieu Gagn=E9, patches
                posted)
              * expose PCI back "permissive" parameter (George Dunlap)

[0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:38:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYSo-0003K1-PN; Tue, 10 Apr 2012 10:38:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHYSn-0003Jt-Eu
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:38:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334053263!12353349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23687 invoked from network); 10 Apr 2012 10:21:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:21:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11849414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:20:27 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:20:27 +0100
Message-ID: <1334053226.12209.173.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Goncalo Gomes <Goncalo.Gomes@eu.citrix.com>
Date: Tue, 10 Apr 2012 11:20:26 +0100
In-Reply-To: <20120320200023.GA7821@eire.uk.xensource.com>
References: <20120320155046.GA20897@eire.uk.xensource.com>
	<1332259534.9223.357.camel@zakaz.uk.xensource.com>
	<20120320164311.GA22388@eire.uk.xensource.com>
	<1332261837.9223.367.camel@zakaz.uk.xensource.com>
	<20120320200023.GA7821@eire.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Add vncviewer xm compatibility options the
 'xl create' command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-03-20 at 20:00 +0000, Goncalo Gomes wrote:

Hi Goncalo,

are you still looking into this?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:38:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYSo-0003K1-PN; Tue, 10 Apr 2012 10:38:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHYSn-0003Jt-Eu
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 10:38:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334053263!12353349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23687 invoked from network); 10 Apr 2012 10:21:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:21:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11849414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:20:27 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:20:27 +0100
Message-ID: <1334053226.12209.173.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Goncalo Gomes <Goncalo.Gomes@eu.citrix.com>
Date: Tue, 10 Apr 2012 11:20:26 +0100
In-Reply-To: <20120320200023.GA7821@eire.uk.xensource.com>
References: <20120320155046.GA20897@eire.uk.xensource.com>
	<1332259534.9223.357.camel@zakaz.uk.xensource.com>
	<20120320164311.GA22388@eire.uk.xensource.com>
	<1332261837.9223.367.camel@zakaz.uk.xensource.com>
	<20120320200023.GA7821@eire.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Add vncviewer xm compatibility options the
 'xl create' command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-03-20 at 20:00 +0000, Goncalo Gomes wrote:

Hi Goncalo,

are you still looking into this?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYTc-0003Mt-8a; Tue, 10 Apr 2012 10:39:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHYTb-0003Mn-ED
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:39:07 +0000
Received: from [85.158.143.35:57669] by server-2.bemta-4.messagelabs.com id
	35/28-17550-ACD048F4; Tue, 10 Apr 2012 10:39:06 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334051609!15561221!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19619 invoked from network); 10 Apr 2012 09:53:31 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 09:53:31 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHXlR-0006sf-2l
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 02:53:29 -0700
Date: Tue, 10 Apr 2012 02:53:29 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334051609079-5629497.post@n5.nabble.com>
In-Reply-To: <9641D0F0-4AB5-48DA-9553-55EEED4D1D41@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
	<824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
	<1333702909575-5622369.post@n5.nabble.com>
	<9641D0F0-4AB5-48DA-9553-55EEED4D1D41@citrix.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
 arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply, I probably had already done:
http://xen.1045712.n5.nabble.com/PATCH-v3-Added-optional-build-configs-for-qemu-upstream-td5544305.html
but seem to be not good, or I not understand something?

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-v2-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5617799p5629497.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYTc-0003Mt-8a; Tue, 10 Apr 2012 10:39:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHYTb-0003Mn-ED
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:39:07 +0000
Received: from [85.158.143.35:57669] by server-2.bemta-4.messagelabs.com id
	35/28-17550-ACD048F4; Tue, 10 Apr 2012 10:39:06 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334051609!15561221!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19619 invoked from network); 10 Apr 2012 09:53:31 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 09:53:31 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHXlR-0006sf-2l
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 02:53:29 -0700
Date: Tue, 10 Apr 2012 02:53:29 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334051609079-5629497.post@n5.nabble.com>
In-Reply-To: <9641D0F0-4AB5-48DA-9553-55EEED4D1D41@citrix.com>
References: <4F7C4D0A.1070809@tiscali.it>
	<824697E8-C963-4E7B-91A1-3EFF61DF5EC6@citrix.com>
	<1333702909575-5622369.post@n5.nabble.com>
	<9641D0F0-4AB5-48DA-9553-55EEED4D1D41@citrix.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v2] Autoconf: add variable for pass
 arbitrary options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply, I probably had already done:
http://xen.1045712.n5.nabble.com/PATCH-v3-Added-optional-build-configs-for-qemu-upstream-td5544305.html
but seem to be not good, or I not understand something?

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-v2-Autoconf-add-variable-for-pass-arbitrary-options-to-qemu-upstream-tp5617799p5629497.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYaX-0003fA-4C; Tue, 10 Apr 2012 10:46:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHYaV-0003f5-AX
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:46:15 +0000
Received: from [193.109.254.147:29132] by server-5.bemta-14.messagelabs.com id
	C5/4F-30733-67F048F4; Tue, 10 Apr 2012 10:46:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334054772!3918162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25908 invoked from network); 10 Apr 2012 10:46:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11850352"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:46:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 11:46:12 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHYaR-0005xH-Md;
	Tue, 10 Apr 2012 10:46:11 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHYaR-0000D3-KN;
	Tue, 10 Apr 2012 11:46:11 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12628-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 11:46:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12628: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12628 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12628/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2    fail blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYaX-0003fA-4C; Tue, 10 Apr 2012 10:46:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHYaV-0003f5-AX
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:46:15 +0000
Received: from [193.109.254.147:29132] by server-5.bemta-14.messagelabs.com id
	C5/4F-30733-67F048F4; Tue, 10 Apr 2012 10:46:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334054772!3918162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25908 invoked from network); 10 Apr 2012 10:46:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11850352"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:46:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 11:46:12 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHYaR-0005xH-Md;
	Tue, 10 Apr 2012 10:46:11 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHYaR-0000D3-KN;
	Tue, 10 Apr 2012 11:46:11 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12628-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 11:46:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12628: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12628 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12628/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-amd64-qemuu-win    3 host-install(3)        broken blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2    fail blocked in 11890
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3) broken blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   broken  
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYdc-0003lS-Lx; Tue, 10 Apr 2012 10:49:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHYdb-0003lN-Vs
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:49:28 +0000
Received: from [85.158.139.83:11875] by server-3.bemta-5.messagelabs.com id
	62/0E-25237-730148F4; Tue, 10 Apr 2012 10:49:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334054966!23143288!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3225 invoked from network); 10 Apr 2012 10:49:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11850474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:49:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 11:49:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHYdZ-0005yQ-Tq; Tue, 10 Apr 2012 10:49:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHYdZ-0001AY-Rt;
	Tue, 10 Apr 2012 11:49:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20356.4149.847968.733515@mariner.uk.xensource.com>
Date: Tue, 10 Apr 2012 11:49:25 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen.org
	<ian.jackson@eu.citrix.com>
In-Reply-To: <osstest-12620-mainreport@xen.org>,
	<20120409223200.GF12783@phenom.dumpdata.com>
References: <osstest-12620-mainreport@xen.org>
	<20120409223200.GF12783@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-linus test] 12620: regressions - trouble:
 blocked/broken/fail/pass [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [linux-linus test] 12620: regressions - trouble: blocked/broken/fail/pass"):
> On Mon, Apr 09, 2012 at 07:18:24PM +0100, xen.org wrote:
> > flight 12620 linux-linus real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/12620/
> > version targeted for testing:
> .. snip..
> >  linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e
> 
> Hm, that version should have worked.

Thanks for looking.

> > jobs:
> >  build-amd64                                                  pass    
> >  build-i386                                                   broken  
> 
> Ah, so b/c of that the other things broke. I am not actually
> sure what is broken except that the initrd looks to have not been
> pushed properly?

These failures:

> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-pvops              2 host-install(2)      broken REGR. vs. 12557
>  build-i386                    2 host-install(2)      broken REGR. vs. 12557
>  test-amd64-amd64-xl-win       3 host-install(3)      broken REGR. vs. 12557
>  test-amd64-i386-xend-winxpsp3 3 host-install(3) broken in 12609 REGR. vs. 12557

are because one my my test boxes forgot how to boot from its network
card and reverted to booting from its hard disk.  It seems that
something I am doing to my machines (perhaps the repeated power
cycling) makes this happen occasionally - the machine forgets its boot
order.  I have "fixed" this machine.

(I haven't bothered trying to get this fixed by the suppliers because
it happens to each affected machine only once in several months.)

>  test-amd64-i386-xl          7 debian-install   fail in 12609 REGR. vs. 12557

This is a different failure.  It appears to be an intermittent
problem.

At the time only dom0 was running.  The step that failed was doing a
debootstrap of a Debian guest, which is heavy on disk and network IO.
The failure was that it took more than 2000 seconds.  This operation
does depend on services from the Internet, notably our local debian
cacheing proxy and also security.debian.org.  It's most likely that
this was a transient problem with security.debian.org although I don't
see any direct evidence for that theory.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYdc-0003lS-Lx; Tue, 10 Apr 2012 10:49:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHYdb-0003lN-Vs
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:49:28 +0000
Received: from [85.158.139.83:11875] by server-3.bemta-5.messagelabs.com id
	62/0E-25237-730148F4; Tue, 10 Apr 2012 10:49:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334054966!23143288!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3225 invoked from network); 10 Apr 2012 10:49:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11850474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:49:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 11:49:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHYdZ-0005yQ-Tq; Tue, 10 Apr 2012 10:49:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHYdZ-0001AY-Rt;
	Tue, 10 Apr 2012 11:49:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20356.4149.847968.733515@mariner.uk.xensource.com>
Date: Tue, 10 Apr 2012 11:49:25 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen.org
	<ian.jackson@eu.citrix.com>
In-Reply-To: <osstest-12620-mainreport@xen.org>,
	<20120409223200.GF12783@phenom.dumpdata.com>
References: <osstest-12620-mainreport@xen.org>
	<20120409223200.GF12783@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-linus test] 12620: regressions - trouble:
 blocked/broken/fail/pass [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [linux-linus test] 12620: regressions - trouble: blocked/broken/fail/pass"):
> On Mon, Apr 09, 2012 at 07:18:24PM +0100, xen.org wrote:
> > flight 12620 linux-linus real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/12620/
> > version targeted for testing:
> .. snip..
> >  linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e
> 
> Hm, that version should have worked.

Thanks for looking.

> > jobs:
> >  build-amd64                                                  pass    
> >  build-i386                                                   broken  
> 
> Ah, so b/c of that the other things broke. I am not actually
> sure what is broken except that the initrd looks to have not been
> pushed properly?

These failures:

> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-pvops              2 host-install(2)      broken REGR. vs. 12557
>  build-i386                    2 host-install(2)      broken REGR. vs. 12557
>  test-amd64-amd64-xl-win       3 host-install(3)      broken REGR. vs. 12557
>  test-amd64-i386-xend-winxpsp3 3 host-install(3) broken in 12609 REGR. vs. 12557

are because one my my test boxes forgot how to boot from its network
card and reverted to booting from its hard disk.  It seems that
something I am doing to my machines (perhaps the repeated power
cycling) makes this happen occasionally - the machine forgets its boot
order.  I have "fixed" this machine.

(I haven't bothered trying to get this fixed by the suppliers because
it happens to each affected machine only once in several months.)

>  test-amd64-i386-xl          7 debian-install   fail in 12609 REGR. vs. 12557

This is a different failure.  It appears to be an intermittent
problem.

At the time only dom0 was running.  The step that failed was doing a
debootstrap of a Debian guest, which is heavy on disk and network IO.
The failure was that it took more than 2000 seconds.  This operation
does depend on services from the Internet, notably our local debian
cacheing proxy and also security.debian.org.  It's most likely that
this was a transient problem with security.debian.org although I don't
see any direct evidence for that theory.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:51:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYey-0003r7-5D; Tue, 10 Apr 2012 10:50:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHYew-0003qx-LT
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:50:50 +0000
Received: from [85.158.138.51:11185] by server-11.bemta-3.messagelabs.com id
	69/EA-28543-980148F4; Tue, 10 Apr 2012 10:50:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334055048!21495558!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4542 invoked from network); 10 Apr 2012 10:50:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:50:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11850562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:50:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 11:50:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHYeh-0005yw-Fn	for xen-devel@lists.xensource.com;
	Tue, 10 Apr 2012 10:50:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHYeh-0001Al-F9	for
	xen-devel@lists.xensource.com; Tue, 10 Apr 2012 11:50:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20356.4219.454454.886096@mariner.uk.xensource.com>
Date: Tue, 10 Apr 2012 11:50:35 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-12628-mainreport@xen.org>
References: <osstest-12628-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [qemu-upstream-unstable test] 12628: tolerable
 trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[qemu-upstream-unstable test] 12628: tolerable trouble: broken/fail/pass"):
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly

Needless to say this is a bug.  I hope the fix will make it through
the mill soon, at which point the push will work and it'll stop
pointlessly retesting this update.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 10:51:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 10:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYey-0003r7-5D; Tue, 10 Apr 2012 10:50:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHYew-0003qx-LT
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 10:50:50 +0000
Received: from [85.158.138.51:11185] by server-11.bemta-3.messagelabs.com id
	69/EA-28543-980148F4; Tue, 10 Apr 2012 10:50:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334055048!21495558!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4542 invoked from network); 10 Apr 2012 10:50:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:50:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11850562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:50:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 11:50:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHYeh-0005yw-Fn	for xen-devel@lists.xensource.com;
	Tue, 10 Apr 2012 10:50:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHYeh-0001Al-F9	for
	xen-devel@lists.xensource.com; Tue, 10 Apr 2012 11:50:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20356.4219.454454.886096@mariner.uk.xensource.com>
Date: Tue, 10 Apr 2012 11:50:35 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-12628-mainreport@xen.org>
References: <osstest-12628-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [qemu-upstream-unstable test] 12628: tolerable
 trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[qemu-upstream-unstable test] 12628: tolerable trouble: broken/fail/pass"):
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git push :git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly

Needless to say this is a bug.  I hope the fix will make it through
the mill soon, at which point the push will work and it'll stop
pointlessly retesting this update.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYvz-00049I-P4; Tue, 10 Apr 2012 11:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHYvy-00049D-IB
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 11:08:26 +0000
Received: from [85.158.143.35:43960] by server-1.bemta-4.messagelabs.com id
	BE/84-20925-9A4148F4; Tue, 10 Apr 2012 11:08:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334056105!11738932!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3416 invoked from network); 10 Apr 2012 11:08:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 11:08:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 12:08:24 +0100
Message-Id: <4F8430C7020000780007CFD3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 12:08:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Francisco Rocha" <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 19:37, Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk> wrote:
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
> 
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 
> (3.0.0.17-generic).
> 
> The output to my serial console is attached.

So as already said by someone else, this is a fault on an XSETBV
instruction. In the kernel this immediately follows the setting of
CR4.OSXSAVE, yet in Xen's emulation code the only way to get
#UD here is that (virtual) CR4 bit is not set; all other failure
paths result in #GP.

The emulation code handling the setting of this CR4 bit, however,
would issue a warning if the kernel was attempting to set a bit
that the hypervisor doesn't allow to be set, yet no such warning
is present in the log you provided (and you're already running at
the highest logging level).

In any case, a fundamental question is whether your CPU has
XSAVE support in the first place, and whether kernel and
hypervisor disagree about that for some reason. Could you
for that purpose post /proc/cpuinfo contents from when running
a native kernel?

Beyond that, adding some tracing to the hypervisor may be
necessary to monitor the Dom0 CR4 writes and maybe how
XSAVE support gets initialized in Xen. Would you be able to do
so on your own, and post the results?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHYvz-00049I-P4; Tue, 10 Apr 2012 11:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHYvy-00049D-IB
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 11:08:26 +0000
Received: from [85.158.143.35:43960] by server-1.bemta-4.messagelabs.com id
	BE/84-20925-9A4148F4; Tue, 10 Apr 2012 11:08:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334056105!11738932!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3416 invoked from network); 10 Apr 2012 11:08:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 11:08:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 12:08:24 +0100
Message-Id: <4F8430C7020000780007CFD3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 12:08:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Francisco Rocha" <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.04.12 at 19:37, Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk> wrote:
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
> 
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 
> (3.0.0.17-generic).
> 
> The output to my serial console is attached.

So as already said by someone else, this is a fault on an XSETBV
instruction. In the kernel this immediately follows the setting of
CR4.OSXSAVE, yet in Xen's emulation code the only way to get
#UD here is that (virtual) CR4 bit is not set; all other failure
paths result in #GP.

The emulation code handling the setting of this CR4 bit, however,
would issue a warning if the kernel was attempting to set a bit
that the hypervisor doesn't allow to be set, yet no such warning
is present in the log you provided (and you're already running at
the highest logging level).

In any case, a fundamental question is whether your CPU has
XSAVE support in the first place, and whether kernel and
hypervisor disagree about that for some reason. Could you
for that purpose post /proc/cpuinfo contents from when running
a native kernel?

Beyond that, adding some tracing to the hypervisor may be
necessary to monitor the Dom0 CR4 writes and maybe how
XSAVE support gets initialized in Xen. Would you be able to do
so on your own, and post the results?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:20:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:20:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZ71-0004MQ-Tb; Tue, 10 Apr 2012 11:19:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHZ70-0004ML-90
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 11:19:50 +0000
Received: from [85.158.143.35:57930] by server-3.bemta-4.messagelabs.com id
	A8/46-05853-557148F4; Tue, 10 Apr 2012 11:19:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334053600!15567306!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2068 invoked from network); 10 Apr 2012 10:26:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:26:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11849583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:26:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:26:40 +0100
Message-ID: <1334053599.12209.178.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Tue, 10 Apr 2012 10:26:39 +0000
In-Reply-To: <1333699761452-5622311.post@n5.nabble.com>
References: <1333699761452-5622311.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about hvmloader, vgabios and qxl problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-06 at 09:09 +0100, Fantu wrote:

> I am currently looking hvmloader and vgabios, apparently they did not
> provide support for qxl and more videoram, so maybe the problem is there.

> Vgabios is not updated to last version with qxl support, is used by qemu
> upstream and need to be updated?

VGA BIOS is not used with SeaBIOS (and therefore not used with upstream
qemu), it is only used with ROMBIOS. SeaBIOS loads any option ROMs
directly from the (emulated) hardware devices (like a real BIOS would).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:20:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:20:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZ71-0004MQ-Tb; Tue, 10 Apr 2012 11:19:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHZ70-0004ML-90
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 11:19:50 +0000
Received: from [85.158.143.35:57930] by server-3.bemta-4.messagelabs.com id
	A8/46-05853-557148F4; Tue, 10 Apr 2012 11:19:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334053600!15567306!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2068 invoked from network); 10 Apr 2012 10:26:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 10:26:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="11849583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:26:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:26:40 +0100
Message-ID: <1334053599.12209.178.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Tue, 10 Apr 2012 10:26:39 +0000
In-Reply-To: <1333699761452-5622311.post@n5.nabble.com>
References: <1333699761452-5622311.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about hvmloader, vgabios and qxl problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-06 at 09:09 +0100, Fantu wrote:

> I am currently looking hvmloader and vgabios, apparently they did not
> provide support for qxl and more videoram, so maybe the problem is there.

> Vgabios is not updated to last version with qxl support, is used by qemu
> upstream and need to be updated?

VGA BIOS is not used with SeaBIOS (and therefore not used with upstream
qemu), it is only used with ROMBIOS. SeaBIOS loads any option ROMs
directly from the (emulated) hardware devices (like a real BIOS would).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:21:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:21:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZ7n-0004Oc-AX; Tue, 10 Apr 2012 11:20:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHZ7l-0004OU-WE
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 11:20:38 +0000
Received: from [85.158.143.99:39596] by server-2.bemta-4.messagelabs.com id
	20/63-17550-587148F4; Tue, 10 Apr 2012 11:20:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334056836!22991736!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4184 invoked from network); 10 Apr 2012 11:20:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 11:20:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 12:20:35 +0100
Message-Id: <4F8433A0020000780007CFE6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 12:20:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Francisco Rocha" <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
	<4F8430C7020000780007CFD3@nat28.tlf.novell.com>
In-Reply-To: <4F8430C7020000780007CFD3@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> In any case, a fundamental question is whether your CPU has
> XSAVE support in the first place, and whether kernel and
> hypervisor disagree about that for some reason. Could you
> for that purpose post /proc/cpuinfo contents from when running
> a native kernel?

Just realized that this question is answered by the log you provided:

(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7

so indeed the fastest approach (short of someone seeing something
obviously wrong with the code) appears to be to add some tracing to
the CR4 handling (pv_guest_cr4_fixup() and the XSETBV handling in
emulate_privileged_op()), particularly also because the register dump
indicates that the relevant bit was not set in CR4 at the point where
the XSETBV faulted.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:21:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:21:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZ7n-0004Oc-AX; Tue, 10 Apr 2012 11:20:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHZ7l-0004OU-WE
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 11:20:38 +0000
Received: from [85.158.143.99:39596] by server-2.bemta-4.messagelabs.com id
	20/63-17550-587148F4; Tue, 10 Apr 2012 11:20:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334056836!22991736!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4184 invoked from network); 10 Apr 2012 11:20:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 11:20:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 12:20:35 +0100
Message-Id: <4F8433A0020000780007CFE6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 12:20:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Francisco Rocha" <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
	<4F8430C7020000780007CFD3@nat28.tlf.novell.com>
In-Reply-To: <4F8430C7020000780007CFD3@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> In any case, a fundamental question is whether your CPU has
> XSAVE support in the first place, and whether kernel and
> hypervisor disagree about that for some reason. Could you
> for that purpose post /proc/cpuinfo contents from when running
> a native kernel?

Just realized that this question is answered by the log you provided:

(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7

so indeed the fastest approach (short of someone seeing something
obviously wrong with the code) appears to be to add some tracing to
the CR4 handling (pv_guest_cr4_fixup() and the XSETBV handling in
emulate_privileged_op()), particularly also because the register dump
indicates that the relevant bit was not set in CR4 at the point where
the XSETBV faulted.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:30:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZHA-0004fq-H2; Tue, 10 Apr 2012 11:30:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SHZH9-0004fl-DJ
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 11:30:19 +0000
Received: from [85.158.143.99:52035] by server-1.bemta-4.messagelabs.com id
	78/8C-20925-AC9148F4; Tue, 10 Apr 2012 11:30:18 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334057416!24447912!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26408 invoked from network); 10 Apr 2012 11:30:17 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 11:30:17 -0000
Received: by vbbfq11 with SMTP id fq11so3488045vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Apr 2012 04:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=DkzY+VIdx66AiDhpxabJjHnbqZSmmo/K+dqzsEoU2Dw=;
	b=SaP2BHKxcdUj3rOhvti6havG+DyeYk6qKViBxr/MIgJgAqn/53aP7cWm8VpXPOCRHk
	28pg26nrkI9SnFrZ07vKTw7mt1FsT3B5SKk5j9FFz3fZ/Nc+G+BdaLmria7WPutJFdFT
	CJDCVT2cJHTXt+7kzfAUTa1z7CCHTr8615Cwlr4igYKRH8UK4DhtDmM/DsZm4ZTKkCxe
	wfUTRTIWYcnTmVKFJ+ccywkcb4h2e58wkOe47Foj0IwuATXJ0mC/6Es3IA3WFjXTUT0u
	SR2AzTVGOfRDxB7rWAnSY9kImAVjuDqOemFQrAyGWY1CBBA+VlzsKq9MC9PnsNZjMLPZ
	DjVw==
MIME-Version: 1.0
Received: by 10.52.174.176 with SMTP id bt16mr4413208vdc.59.1334057416026;
	Tue, 10 Apr 2012 04:30:16 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Tue, 10 Apr 2012 04:30:15 -0700 (PDT)
Date: Tue, 10 Apr 2012 20:30:15 +0900
Message-ID: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello All,

I am writing the PV-Drivers for Seabios.

When I put a request on the front ring and issue the hypercall to
notify, the hvm guest crashes.

Here is the dmesg output:

(XEN) realmode.c:116:d10 Failed to emulate insn.
(XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
0f aa ba b2 00 ec
(XEN) domain_crash called from realmode.c:167
(XEN) Domain 10 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    f000:[<0000000000001c4b>]
(XEN) RFLAGS: 0000000000000097   CONTEXT: hvm guest
(XEN) rax: 00000000000a0000   rbx: 000000000003fef8   rcx: 0000000000000320
(XEN) rdx: 00000000000000b3   rsi: 00000000000fd600   rdi: 0000000000000340
(XEN) rbp: 000000000009a040   rsp: 0000000000000308   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000800000   cr2: 0000000000000000
(XEN) ds: 9940   es: 9940   fs: 0000   gs: 0000   ss: 9940   cs: f000

Here is the code for issue the hypercall:
        	dprintf(1,"Start notify procedure\n");
        	evtchn_send_t send;
        	send.port =3D GET_GLOBALFLAT(bi->port);
        	dprintf(1,"In notify before hypercall port is %d =3D %d",send.port=
);
        	//hypercall_event_channel_op(EVTCHNOP_send, &send);
        	dprintf(1,"read operation notify res %d\n",
hypercall_event_channel_op(EVTCHNOP_send, &send));
Nothing out of the ordinary. Except that the hypercall is issued under
16bit, It works under 32bit.

Any ideas what could be wrong?

-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 11:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 11:30:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZHA-0004fq-H2; Tue, 10 Apr 2012 11:30:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SHZH9-0004fl-DJ
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 11:30:19 +0000
Received: from [85.158.143.99:52035] by server-1.bemta-4.messagelabs.com id
	78/8C-20925-AC9148F4; Tue, 10 Apr 2012 11:30:18 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334057416!24447912!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26408 invoked from network); 10 Apr 2012 11:30:17 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 11:30:17 -0000
Received: by vbbfq11 with SMTP id fq11so3488045vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Apr 2012 04:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=DkzY+VIdx66AiDhpxabJjHnbqZSmmo/K+dqzsEoU2Dw=;
	b=SaP2BHKxcdUj3rOhvti6havG+DyeYk6qKViBxr/MIgJgAqn/53aP7cWm8VpXPOCRHk
	28pg26nrkI9SnFrZ07vKTw7mt1FsT3B5SKk5j9FFz3fZ/Nc+G+BdaLmria7WPutJFdFT
	CJDCVT2cJHTXt+7kzfAUTa1z7CCHTr8615Cwlr4igYKRH8UK4DhtDmM/DsZm4ZTKkCxe
	wfUTRTIWYcnTmVKFJ+ccywkcb4h2e58wkOe47Foj0IwuATXJ0mC/6Es3IA3WFjXTUT0u
	SR2AzTVGOfRDxB7rWAnSY9kImAVjuDqOemFQrAyGWY1CBBA+VlzsKq9MC9PnsNZjMLPZ
	DjVw==
MIME-Version: 1.0
Received: by 10.52.174.176 with SMTP id bt16mr4413208vdc.59.1334057416026;
	Tue, 10 Apr 2012 04:30:16 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Tue, 10 Apr 2012 04:30:15 -0700 (PDT)
Date: Tue, 10 Apr 2012 20:30:15 +0900
Message-ID: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello All,

I am writing the PV-Drivers for Seabios.

When I put a request on the front ring and issue the hypercall to
notify, the hvm guest crashes.

Here is the dmesg output:

(XEN) realmode.c:116:d10 Failed to emulate insn.
(XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
0f aa ba b2 00 ec
(XEN) domain_crash called from realmode.c:167
(XEN) Domain 10 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    f000:[<0000000000001c4b>]
(XEN) RFLAGS: 0000000000000097   CONTEXT: hvm guest
(XEN) rax: 00000000000a0000   rbx: 000000000003fef8   rcx: 0000000000000320
(XEN) rdx: 00000000000000b3   rsi: 00000000000fd600   rdi: 0000000000000340
(XEN) rbp: 000000000009a040   rsp: 0000000000000308   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000800000   cr2: 0000000000000000
(XEN) ds: 9940   es: 9940   fs: 0000   gs: 0000   ss: 9940   cs: f000

Here is the code for issue the hypercall:
        	dprintf(1,"Start notify procedure\n");
        	evtchn_send_t send;
        	send.port =3D GET_GLOBALFLAT(bi->port);
        	dprintf(1,"In notify before hypercall port is %d =3D %d",send.port=
);
        	//hypercall_event_channel_op(EVTCHNOP_send, &send);
        	dprintf(1,"read operation notify res %d\n",
hypercall_event_channel_op(EVTCHNOP_send, &send));
Nothing out of the ordinary. Except that the hypercall is issued under
16bit, It works under 32bit.

Any ideas what could be wrong?

-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 12:10:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:10:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZtH-00059d-KJ; Tue, 10 Apr 2012 12:09:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHZtG-00059Y-Fq
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 12:09:42 +0000
Received: from [85.158.143.99:44752] by server-1.bemta-4.messagelabs.com id
	E5/21-20925-503248F4; Tue, 10 Apr 2012 12:09:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334059780!22964825!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15489 invoked from network); 10 Apr 2012 12:09:40 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 12:09:40 -0000
Received: by bkwj5 with SMTP id j5so4554671bkw.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Apr 2012 05:09:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LFZI9+FiWbSzuan6p0Md9CIbBxvBRAy4+/f1j9ScBcE=;
	b=qg+kuId8v73L5hbq0sW/M6neL5yfen9nQSqVrNkxE13Y0UV4yPa7g7IECJ85I9mEaV
	nZxzXFyjH5anxmGiq5XLnaiv6/rKRG9jD//0tg0YbxkTpQCwjUNGJYjxhwz+zjp8+DDY
	tmDPEGXDQ5ScN0Z1stNd3Dqidmoavzc7jk/tRq3+T2acPp5Tyv/4MiCoMAHXnJmFkUHT
	4aS0tNjLY3s95obsSWIfXrgp6ynbcY3ZMOnCRQFJPZJTJl6+MZdw2eEbMLc0x16NDK92
	HByb8VQZz1JOvFHkQxsFz+kI4uT++psZppaDo6hPEA4Mt9R4GMfwlFUF0ElZHv6QTfYk
	PhbA==
Received: by 10.204.133.205 with SMTP id g13mr4676902bkt.94.1334059779782;
	Tue, 10 Apr 2012 05:09:39 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id f11sm24923031bkw.6.2012.04.10.05.09.38
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 05:09:39 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Apr 2012 13:09:31 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel Castro <evil.dani@gmail.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CBA9E18B.3D835%keir@xen.org>
Thread-Topic: [Xen-devel] hvm crash on hypercall event channel
Thread-Index: Ac0XEsjXdu1JTGDH3kqfnBohuGzXUg==
In-Reply-To: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
Mime-version: 1.0
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/04/2012 12:30, "Daniel Castro" <evil.dani@gmail.com> wrote:

> Hello All,
> 
> I am writing the PV-Drivers for Seabios.
> 
> When I put a request on the front ring and issue the hypercall to
> notify, the hvm guest crashes.
> 
> Here is the dmesg output:
> 
> (XEN) realmode.c:116:d10 Failed to emulate insn.
> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
> 0f aa ba b2 00 ec

Looks like instruction RSM (return from SMM mode). Seems unlikely!

However, even if you are trying to run VMCALL (opcode 0F 01 C1) from
realmode it may not work as we emulate real mode for older Intel CPUs, and
our emulator does not include the vmcall instruction. Also the hypercall
stub code we provide to guests is only correct for 32-bit and 64-bit modes.
You can't legitimately use the hypercall stubs from real mode, vm86 mode, or
16-bit protected mode.

Could you just do the hypercalls from 32-bit mode? Our old rombios had a
32-bit code area for stuff like this, quite probably seabios has similar. Or
perhaps if not it could gain this functionality. Hypercalls from 16-bit mode
are not something we care to add support for, I think.

 -- Keir

> (XEN) domain_crash called from realmode.c:167
> (XEN) Domain 10 (vcpu#0) crashed on cpu#1:
> (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    1
> (XEN) RIP:    f000:[<0000000000001c4b>]
> (XEN) RFLAGS: 0000000000000097   CONTEXT: hvm guest
> (XEN) rax: 00000000000a0000   rbx: 000000000003fef8   rcx: 0000000000000320
> (XEN) rdx: 00000000000000b3   rsi: 00000000000fd600   rdi: 0000000000000340
> (XEN) rbp: 000000000009a040   rsp: 0000000000000308   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000800000   cr2: 0000000000000000
> (XEN) ds: 9940   es: 9940   fs: 0000   gs: 0000   ss: 9940   cs: f000
> 
> Here is the code for issue the hypercall:
> dprintf(1,"Start notify procedure\n");
> evtchn_send_t send;
> send.port = GET_GLOBALFLAT(bi->port);
> dprintf(1,"In notify before hypercall port is %d = %d",send.port);
> //hypercall_event_channel_op(EVTCHNOP_send, &send);
> dprintf(1,"read operation notify res %d\n",
> hypercall_event_channel_op(EVTCHNOP_send, &send));
> Nothing out of the ordinary. Except that the hypercall is issued under
> 16bit, It works under 32bit.
> 
> Any ideas what could be wrong?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 12:10:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:10:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZtH-00059d-KJ; Tue, 10 Apr 2012 12:09:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHZtG-00059Y-Fq
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 12:09:42 +0000
Received: from [85.158.143.99:44752] by server-1.bemta-4.messagelabs.com id
	E5/21-20925-503248F4; Tue, 10 Apr 2012 12:09:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334059780!22964825!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15489 invoked from network); 10 Apr 2012 12:09:40 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 12:09:40 -0000
Received: by bkwj5 with SMTP id j5so4554671bkw.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Apr 2012 05:09:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LFZI9+FiWbSzuan6p0Md9CIbBxvBRAy4+/f1j9ScBcE=;
	b=qg+kuId8v73L5hbq0sW/M6neL5yfen9nQSqVrNkxE13Y0UV4yPa7g7IECJ85I9mEaV
	nZxzXFyjH5anxmGiq5XLnaiv6/rKRG9jD//0tg0YbxkTpQCwjUNGJYjxhwz+zjp8+DDY
	tmDPEGXDQ5ScN0Z1stNd3Dqidmoavzc7jk/tRq3+T2acPp5Tyv/4MiCoMAHXnJmFkUHT
	4aS0tNjLY3s95obsSWIfXrgp6ynbcY3ZMOnCRQFJPZJTJl6+MZdw2eEbMLc0x16NDK92
	HByb8VQZz1JOvFHkQxsFz+kI4uT++psZppaDo6hPEA4Mt9R4GMfwlFUF0ElZHv6QTfYk
	PhbA==
Received: by 10.204.133.205 with SMTP id g13mr4676902bkt.94.1334059779782;
	Tue, 10 Apr 2012 05:09:39 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id f11sm24923031bkw.6.2012.04.10.05.09.38
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 05:09:39 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Apr 2012 13:09:31 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel Castro <evil.dani@gmail.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CBA9E18B.3D835%keir@xen.org>
Thread-Topic: [Xen-devel] hvm crash on hypercall event channel
Thread-Index: Ac0XEsjXdu1JTGDH3kqfnBohuGzXUg==
In-Reply-To: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
Mime-version: 1.0
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/04/2012 12:30, "Daniel Castro" <evil.dani@gmail.com> wrote:

> Hello All,
> 
> I am writing the PV-Drivers for Seabios.
> 
> When I put a request on the front ring and issue the hypercall to
> notify, the hvm guest crashes.
> 
> Here is the dmesg output:
> 
> (XEN) realmode.c:116:d10 Failed to emulate insn.
> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
> 0f aa ba b2 00 ec

Looks like instruction RSM (return from SMM mode). Seems unlikely!

However, even if you are trying to run VMCALL (opcode 0F 01 C1) from
realmode it may not work as we emulate real mode for older Intel CPUs, and
our emulator does not include the vmcall instruction. Also the hypercall
stub code we provide to guests is only correct for 32-bit and 64-bit modes.
You can't legitimately use the hypercall stubs from real mode, vm86 mode, or
16-bit protected mode.

Could you just do the hypercalls from 32-bit mode? Our old rombios had a
32-bit code area for stuff like this, quite probably seabios has similar. Or
perhaps if not it could gain this functionality. Hypercalls from 16-bit mode
are not something we care to add support for, I think.

 -- Keir

> (XEN) domain_crash called from realmode.c:167
> (XEN) Domain 10 (vcpu#0) crashed on cpu#1:
> (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    1
> (XEN) RIP:    f000:[<0000000000001c4b>]
> (XEN) RFLAGS: 0000000000000097   CONTEXT: hvm guest
> (XEN) rax: 00000000000a0000   rbx: 000000000003fef8   rcx: 0000000000000320
> (XEN) rdx: 00000000000000b3   rsi: 00000000000fd600   rdi: 0000000000000340
> (XEN) rbp: 000000000009a040   rsp: 0000000000000308   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000800000   cr2: 0000000000000000
> (XEN) ds: 9940   es: 9940   fs: 0000   gs: 0000   ss: 9940   cs: f000
> 
> Here is the code for issue the hypercall:
> dprintf(1,"Start notify procedure\n");
> evtchn_send_t send;
> send.port = GET_GLOBALFLAT(bi->port);
> dprintf(1,"In notify before hypercall port is %d = %d",send.port);
> //hypercall_event_channel_op(EVTCHNOP_send, &send);
> dprintf(1,"read operation notify res %d\n",
> hypercall_event_channel_op(EVTCHNOP_send, &send));
> Nothing out of the ordinary. Except that the hypercall is issued under
> 16bit, It works under 32bit.
> 
> Any ideas what could be wrong?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 12:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZxE-0005Gz-D7; Tue, 10 Apr 2012 12:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SHZxD-0005Gr-B7
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 12:13:47 +0000
Received: from [85.158.143.35:36049] by server-1.bemta-4.messagelabs.com id
	42/C7-20925-AF3248F4; Tue, 10 Apr 2012 12:13:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334060025!11988564!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24159 invoked from network); 10 Apr 2012 12:13:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 12:13:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SHZxA-0000Z5-Hr; Tue, 10 Apr 2012 12:13:44 +0000
Date: Tue, 10 Apr 2012 13:13:44 +0100
From: Tim Deegan <tim@xen.org>
To: Daniel Castro <evil.dani@gmail.com>, g@phlegethon.org
Message-ID: <20120410121344.GA1955@ocelot.phlegethon.org>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
> Hello All,
> 
> I am writing the PV-Drivers for Seabios.
> 
> When I put a request on the front ring and issue the hypercall to
> notify, the hvm guest crashes.
> 
> Here is the dmesg output:
> 
> (XEN) realmode.c:116:d10 Failed to emulate insn.
> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
> 0f aa ba b2 00 ec

0F AA is RSM, which is a pretty surprising instruction to find in a
hypercall invocation -- or indeed anywhere outside machine-specific SMM
code.  Is there SMM code in SeaBIOS?  It may be that you've ended up
jumping to a misaligned instruction boundary.

> Nothing out of the ordinary. Except that the hypercall is issued under
> 16bit, It works under 32bit.

Are you using the hypercall page to make your hypercall?  Its contents
don't make sense in 16-bit mode, only in 32-bit and 64-bit.  Since the
register arguments are 32-bit anyway you might want to make all your
hypercalls from 32-bit code anyway; otherwise you'll need to make your
own 16-bit stubs, with the right prefixes for the MOV imm32.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 12:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHZxE-0005Gz-D7; Tue, 10 Apr 2012 12:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SHZxD-0005Gr-B7
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 12:13:47 +0000
Received: from [85.158.143.35:36049] by server-1.bemta-4.messagelabs.com id
	42/C7-20925-AF3248F4; Tue, 10 Apr 2012 12:13:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334060025!11988564!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24159 invoked from network); 10 Apr 2012 12:13:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 12:13:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SHZxA-0000Z5-Hr; Tue, 10 Apr 2012 12:13:44 +0000
Date: Tue, 10 Apr 2012 13:13:44 +0100
From: Tim Deegan <tim@xen.org>
To: Daniel Castro <evil.dani@gmail.com>, g@phlegethon.org
Message-ID: <20120410121344.GA1955@ocelot.phlegethon.org>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
> Hello All,
> 
> I am writing the PV-Drivers for Seabios.
> 
> When I put a request on the front ring and issue the hypercall to
> notify, the hvm guest crashes.
> 
> Here is the dmesg output:
> 
> (XEN) realmode.c:116:d10 Failed to emulate insn.
> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
> 0f aa ba b2 00 ec

0F AA is RSM, which is a pretty surprising instruction to find in a
hypercall invocation -- or indeed anywhere outside machine-specific SMM
code.  Is there SMM code in SeaBIOS?  It may be that you've ended up
jumping to a misaligned instruction boundary.

> Nothing out of the ordinary. Except that the hypercall is issued under
> 16bit, It works under 32bit.

Are you using the hypercall page to make your hypercall?  Its contents
don't make sense in 16-bit mode, only in 32-bit and 64-bit.  Since the
register arguments are 32-bit anyway you might want to make all your
hypercalls from 32-bit code anyway; otherwise you'll need to make your
own 16-bit stubs, with the right prefixes for the MOV imm32.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 12:24:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHa7M-0005h5-4j; Tue, 10 Apr 2012 12:24:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHa7J-0005h0-UR
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 12:24:14 +0000
Received: from [85.158.138.51:41517] by server-5.bemta-3.messagelabs.com id
	C0/2D-24278-D66248F4; Tue, 10 Apr 2012 12:24:13 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334060651!21467810!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAyMTMz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22024 invoked from network); 10 Apr 2012 12:24:11 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 12:24:11 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHa7G-0002EN-AT; Tue, 10 Apr 2012 13:24:10 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Tue, 10 Apr 2012
	13:23:21 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 10 Apr 2012 13:23:21 +0100
Thread-Topic: [Xen-devel] lastest xen unstable crash
Thread-Index: Ac0XC/jC3OO1BMjzReC9ZvI+H16b4QABRY5d
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B693@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
	<4F8430C7020000780007CFD3@nat28.tlf.novell.com>,
	<4F8433A0020000780007CFE6@nat28.tlf.novell.com>
In-Reply-To: <4F8433A0020000780007CFE6@nat28.tlf.novell.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
Content-Type: multipart/mixed;
	boundary="_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


________________________________________
From: Jan Beulich [JBeulich@suse.com]
Sent: 10 April 2012 12:20
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] lastest xen unstable crash

>>> On 10.04.12 at 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> In any case, a fundamental question is whether your CPU has
> XSAVE support in the first place, and whether kernel and
> hypervisor disagree about that for some reason. Could you
> for that purpose post /proc/cpuinfo contents from when running
> a native kernel?

Just realized that this question is answered by the log you provided:

(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7

so indeed the fastest approach (short of someone seeing something
obviously wrong with the code) appears to be to add some tracing to
the CR4 handling (pv_guest_cr4_fixup() and the XSETBV handling in
emulate_privileged_op()), particularly also because the register dump
indicates that the relevant bit was not set in CR4 at the point where
the XSETBV faulted.

Jan

I have added some prints in the functions you mentioned. Is this what you n=
eed?=20
These are the new lines in the dmesg, the attached file contains the rest.

(XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=3D0 hv_cr4: 00002660 ->=
 guest_cr4:00002660
(XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=3D0 hv_cr4: 00002660 gues=
t_cr4: 00002660 return: 00002660
(XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=3D0 hv_cr4: 00002660 ->=
 guest_cr4:00002660
(XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=3D0 hv_cr4: 00002660 gues=
t_cr4: 00002660 return: 00002660
(XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=3D0 hv_cr4: 00002660 ->=
 guest_cr4:00002660
(XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=3D0 hv_cr4: 00002660 gues=
t_cr4: 00002660 return: 00002660
(XEN) traps.c:2243:d0 @XSETBV: new_xfeature: 0000000000000007
(XEN) traps.c:2246:d0 @XSETBV: (v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_OSXSAV=
E): 0000000000000000

Here is the /proc/cpuinfo running on a native kernel:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x25
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat =
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm =
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aper=
fmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr =
pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf=
_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5382.77
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

and /proc/cpuinfo with dom0 running with xsave=3D0:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x23
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse=
 sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc aperfmperf=
 pni pclmulqdq est ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_time=
r aes hypervisor lahf_lm ida arat epb pln pts dts
bogomips	: 5382.58
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Cheers,
Francisco=

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_
Content-Type: text/plain; name="xen_xsave_crash.txt"
Content-Description: xen_xsave_crash.txt
Content-Disposition: attachment; filename="xen_xsave_crash.txt"; size=23007;
	creation-date="Tue, 10 Apr 2012 13:19:08 GMT";
	modification-date="Tue, 10 Apr 2012 13:19:08 GMT"
Content-Transfer-Encoding: base64

IFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBf
XyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwgJ18gXCAgfCB8fCB8XyAgIF9fKSB8X198IHwg
fCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBfIFwKICAvICBcICBfXy8gfCB8IHwgfF9f
ICAgX3wgLyBfXy98X198IHxffCB8IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8KIC9f
L1xfXF9fX3xffCB8X3wgICAgfF98KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxf
fF8uX18vfF98XF9fX3wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24gNC4yLXVu
c3RhYmxlIChyb290QG5jbC5hYy51aykgKGdjYyB2ZXJzaW9uIDQuNi4zIDIwMTIwMzA2IChSZWQg
SGF0IDQuNi4zLTIpIChHQ0MpICkgVHVlIEFwciAxMCAxMzowODozOSBCU1QgMjAxMgooWEVOKSBM
YXRlc3QgQ2hhbmdlU2V0OiBUaHUgQXByIDA1IDExOjA2OjAzIDIwMTIgKzAxMDAgMjUxNjE6ZDY5
MGM3ZTg5NmEyCihYRU4pIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9ub3VzLgooWEVOKSBCb290
bG9hZGVyOiBHUlVCIDEuOTkKKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBsb2dsdmw9
YWxsIGRvbTBfbWVtPTIwNDhNIHN5bmNfY29uc29sZSBjb20xPTExNTIwMCw4bjEsMHgzMDkwLDE5
IGNvbnNvbGU9Y29tMSx2Z2EKKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMg
dGV4dCBtb2RlIDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVE
SUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4p
ICBGb3VuZCAxIE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBz
dHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAw
IC0gMDAwMDAwMDAwMDA5ZWMwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5ZWMwMCAtIDAw
MDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAw
MDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAw
MjAwMDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAw
MDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwMjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAw
ICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAocmVz
ZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDQwMjAwMDAwIC0gMDAwMDAwMDBhYTFkMDAwMCAodXNhYmxl
KQooWEVOKSAgMDAwMDAwMDBhYTFkMDAwMCAtIDAwMDAwMDAwYWExZDAyMDAgKEFDUEkgTlZTKQoo
WEVOKSAgMDAwMDAwMDBhYTFkMDIwMCAtIDAwMDAwMDAwYWExZDMwMDAgKHJlc2VydmVkKQooWEVO
KSAgMDAwMDAwMDBhYTFkMzAwMCAtIDAwMDAwMDAwYWEyZDAwMDAgKEFDUEkgTlZTKQooWEVOKSAg
MDAwMDAwMDBhYTJkMDAwMCAtIDAwMDAwMDAwYWEyZjAwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAw
MDAwMDAwYWEyZjAwMDAgLSAwMDAwMDAwMGFmYTAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAw
MDAwZjgwMDAwMDAgLSAwMDAwMDAwMGZjMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAw
ZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVk
MTAwMDAgLSAwMDAwMDAwMGZlZDFhMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMWMw
MDAgLSAwMDAwMDAwMGZlZDIwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAg
LSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmZjMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAw
MDAwMWNlNjAwMDAwICh1c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRjAwMzAsIDAwMTQgKHIw
IFRPU0hJQikKKFhFTikgQUNQSTogUlNEVCBBQTJFRjAzOCwgMDA1OCAocjEgVE9TSElCIEEwMDdE
ICAgICAgICAgICAzICAgICAgIDEwMDAwMTMpCihYRU4pIEFDUEk6IEZBQ1AgQUEyRUUwMDAsIDAw
ODEgKHIyIFRPU0hJQiBBMDA3RCAgICAgICAgICAgMyBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJ
OiBEU0RUIEFBMkREMDAwLCA4QTQ2IChyMiBUT1NISUIgQTAwN0QgICAgMjAxMTEyMjAgSU5UTCAy
MDA2MTEwOSkKKFhFTikgQUNQSTogRkFDUyBBQTJBRDAwMCwgMDA0MAooWEVOKSBBQ1BJOiBIUEVU
IEFBMkVEMDAwLCAwMDM4IChyMSBUT1NISUIgQTAwN0QgICAgICAgICAgIDEgTE9IUiAgICAgICA1
RikKKFhFTikgQUNQSTogQVBJQyBBQTJFQzAwMCwgMDBCQyAocjEgVE9TSElCIEEwMDdEICAgICAg
ICAgICAxIExPSFIgICAgICAgNUYpCihYRU4pIEFDUEk6IE1DRkcgQUEyRUIwMDAsIDAwM0MgKHIx
IFRPU0hJQiBBMDA3RCAgICAgICAgICAgMSBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJOiBBU0Yh
IEFBMkVBMDAwLCAwMEEwIChyMzIgVE9TSElCIEEwMDdEICAgICAgICAgICAxIExPSFIgICAgICAg
NUYpCihYRU4pIEFDUEk6IFRDUEEgQUEyRTkwMDAsIDAwMzIgKHIyIFRPU0hJQiBBMDA3RCAgICAg
ICAgICAgMCBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJOiBCT09UIEFBMkU4MDAwLCAwMDI4IChy
MSBUT1NISUIgQTAwN0QgICAgICAgICAgIDAgTE9IUiAgICAgICA1RikKKFhFTikgQUNQSTogU0xJ
QyBBQTJFNzAwMCwgMDE3NiAocjEgVE9TSElCIEEwMDdEICAgICAgICAgICAwIExPSFIgICAgICAg
NUYpCihYRU4pIEFDUEk6IFNTRFQgQUEyREMwMDAsIDAzOTUgKHIxIFRPU0hJQiBTYXRhQWhjaSAg
ICAgMTAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBBQ1BJOiBTU0RUIEFBMkQ5MDAwLCAwNzIwIChy
MSBUT1NISUIgUHRpZERldmMgICAgIDEwMDAgSU5UTCAyMDA2MTEwOSkKKFhFTikgQUNQSTogU1NE
VCBBQTJENzAwMCwgMDgyNyAocjEgIFBtUmVmICBDcHUwSXN0ICAgICAzMDAwIElOVEwgMjAwNjEx
MDkpCihYRU4pIEFDUEk6IFNTRFQgQUEyRDYwMDAsIDA5OTYgKHIxICBQbVJlZiAgICBDcHVQbSAg
ICAgMzAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBBQ1BJOiBETUFSIEFBMkQ1MDAwLCAwMTEwIChy
MSBJTlRFTCAgICAgIFNOQiAgICAgICAgIDEgSU5UTCAgICAgICAgMSkKKFhFTikgU3lzdGVtIFJB
TTogNjAxOU1CICg2MTYzODk2a0IpCihYRU4pIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZAoo
WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDFjZTYwMDAwMAoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZAooWEVOKSBETUkgMi41IHByZXNlbnQuCihYRU4p
IFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDog
MHg0MDgKKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs0MDQsMF0sIHBtMXhf
ZXZ0WzQwMCwwXQooWEVOKSBBQ1BJOiAgICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbYWEyYWQw
MGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAw
MDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxl
ZCkKKFhFTikgUHJvY2Vzc29yICMwIDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3Nv
ciAjMSA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAy
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzIgNjoxMCBBUElDIHZl
cnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10g
ZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMzIDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVO
KSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhF
TikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihY
RU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAyXSBoaWdoIGVkZ2UgbGludFsweDFdKQoo
WEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwM10gaGlnaCBlZGdlIGxpbnRbMHgxXSkK
KFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0p
CihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFd
KQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNl0gaGlnaCBlZGdlIGxpbnRbMHgx
XSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDddIGhpZ2ggZWRnZSBsaW50WzB4
MV0pCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwMl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDIsIHZlcnNpb24gMzIsIGFkZHJlc3Mg
MHhmZWMwMDAwMCwgR1NJIDAtMjMKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19p
cnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAw
IGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkKKFhFTikgQUNQSTogSVJRMCB1c2Vk
IGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFD
UEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxh
dC4gIFVzaW5nIDEgSS9PIEFQSUNzCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFz
ZTogMHhmZWQwMDAwMAooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCihYRU4pIFVzaW5nIEFDUEkg
KE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93
aW5nIDggQ1BVcyAoNCBob3RwbHVnIENQVXMpCihYRU4pIElSUSBsaW1pdHM6IDI0IEdTSSwgNzYw
IE1TSS9NU0ktWAooWEVOKSBTd2l0Y2hlZCB0byBBUElDIGRyaXZlciB4MmFwaWNfY2x1c3Rlci4K
KFhFTikgVXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQooWEVO
KSBEZXRlY3RlZCAyNjkxLjMyNiBNSHogcHJvY2Vzc29yLgooWEVOKSBJbml0aW5nIG1lbW9yeSBz
aGFyaW5nLgooWEVOKSB4c3RhdGVfaW5pdDogdXNpbmcgY250eHRfc2l6ZTogMHgzNDAgYW5kIHN0
YXRlczogMHg3CihYRU4pIG1jZV9pbnRlbC5jOjEyMzk6IE1DQSBDYXBhYmlsaXR5OiBCQ0FTVCAx
IFNFUiAwIENNQ0kgMSBmaXJzdGJhbmsgMCBleHRlbmRlZCBNQ0UgTVNSIDAKKFhFTikgSW50ZWwg
bWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZAooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJh
dGlvbiAwOiBiYXNlIGY4MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDNmCihYRU4pIFBD
STogTUNGRyBhcmVhIGF0IGY4MDAwMDAwIHJlc2VydmVkIGluIEU4MjAKKFhFTikgUENJOiBVc2lu
ZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLTNmCihYRU4pIEludGVsIFZULWQgU25vb3Ag
Q29udHJvbCBub3QgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBEb20wIERNQSBQYXNzdGhyb3Vn
aCBub3QgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBRdWV1ZWQgSW52YWxpZGF0aW9uIGVuYWJs
ZWQuCihYRU4pIEludGVsIFZULWQgSW50ZXJydXB0IFJlbWFwcGluZyBlbmFibGVkLgooWEVOKSBJ
bnRlbCBWVC1kIFNoYXJlZCBFUFQgdGFibGVzIG5vdCBlbmFibGVkLgooWEVOKSBJL08gdmlydHVh
bGlzYXRpb24gZW5hYmxlZAooWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKKFhFTikgRW5hYmxl
ZCBkaXJlY3RlZCBFT0kgd2l0aCBpb2FwaWNfYWNrX29sZCBvbiEKKFhFTikgRU5BQkxJTkcgSU8t
QVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBvbGQgQUNLIG1ldGhvZAooWEVOKSAuLlRJTUVSOiB2
ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCihYRU4pIFRTQyBkZWFk
bGluZSB0aW1lciBlbmFibGVkCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVU
CihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgMzIgS2lCLgooWEVOKSBWTVg6IFN1cHBv
cnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFs
aXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gRXh0ZW5kZWQgUGFnZSBU
YWJsZXMgKEVQVCkKKFhFTikgIC0gVmlydHVhbC1Qcm9jZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQp
CihYRU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNzIGJpdG1hcAoo
WEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhFTikgSFZNOiBBU0lEcyBlbmFibGVkLgooWEVO
KSBIVk06IFZNWCBlbmFibGVkCihYRU4pIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChI
QVApIGRldGVjdGVkCihYRU4pIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1CCihYRU4pIEJy
b3VnaHQgdXAgNCBDUFVzCihYRU4pIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4pIG1jaGVja19w
b2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikgKioqIExPQURJ
TkcgRE9NQUlOIDAgKioqCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAw
MDAwMCBtZW1zej0weGE4NjAwMAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0w
eDFjMDAwMDAgbWVtc3o9MHhkYTBlMAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRk
cj0weDFjZGIwMDAgbWVtc3o9MHgxNDM4MAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBw
YWRkcj0weDFjZjAwMDAgbWVtc3o9MHg2YTgwMDAKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogbWVt
b3J5OiAweDEwMDAwMDAgLT4gMHgyMzk4MDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VF
U1RfT1MgPSAibGludXgiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9
ICIyLjYiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIK
KFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDAK
KFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MWNmMDIwMAooWEVO
KSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAw
CihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFi
bGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01P
REUgPSAieWVzIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmljIgoo
WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpCihYRU4p
IGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKKFhFTikgZWxmX3hl
bl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAKKFhFTikgZWxmX3hlbl9hZGRyX2NhbGNf
Y2hlY2s6IGFkZHJlc3NlczoKKFhFTikgICAgIHZpcnRfYmFzZSAgICAgICAgPSAweGZmZmZmZmZm
ODAwMDAwMDAKKFhFTikgICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKKFhFTikgICAgIHZpcnRf
b2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgICAgIHZpcnRfa3N0YXJ0ICAg
ICAgPSAweGZmZmZmZmZmODEwMDAwMDAKKFhFTikgICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZm
ZmZmZmZmODIzOTgwMDAKKFhFTikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZmZmZmODFj
ZjAyMDAKKFhFTikgICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYKKFhF
TikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgIERvbTAga2VybmVs
OiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgyMzk4MDAwCihYRU4pIFBI
WVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAx
YzAwMDAwMDAtPjAwMDAwMDAxYzQwMDAwMDAgKDQ5NjIyMiBwYWdlcyB0byBiZSBhbGxvY2F0ZWQp
CihYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMWNiODVlMDAwLT4wMDAwMDAwMWNlNjAwMDAw
CihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDog
ZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MjM5ODAwMAooWEVOKSAgSW5pdC4gcmFtZGlzazog
ZmZmZmZmZmY4MjM5ODAwMC0+ZmZmZmZmZmY4NTEzYTAwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDog
ZmZmZmZmZmY4NTEzYTAwMC0+ZmZmZmZmZmY4NTUzYTAwMAooWEVOKSAgU3RhcnQgaW5mbzogICAg
ZmZmZmZmZmY4NTUzYTAwMC0+ZmZmZmZmZmY4NTUzYTRiNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAg
ZmZmZmZmZmY4NTUzYjAwMC0+ZmZmZmZmZmY4NTU2YTAwMAooWEVOKSAgQm9vdCBzdGFjazogICAg
ZmZmZmZmZmY4NTU2YTAwMC0+ZmZmZmZmZmY4NTU2YjAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAg
ZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NTgwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzog
ZmZmZmZmZmY4MWNmMDIwMAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDQgVkNQVXMKKFhFTikgZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4
MWE4NjAwMAooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFjMDAw
MDAgLT4gMHhmZmZmZmZmZjgxY2RhMGUwCihYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0
IDB4ZmZmZmZmZmY4MWNkYjAwMCAtPiAweGZmZmZmZmZmODFjZWYzODAKKFhFTikgZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxY2YwMDAwIC0+IDB4ZmZmZmZmZmY4MWRkYzAw
MAooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNl
dCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVOKSBHdWVzdCBM
b2dsZXZlbDogQWxsCihYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioKKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJP
Tk9VUwooWEVOKSAqKioqKioqIFRoaXMgb3B0aW9uIGlzIGludGVuZGVkIHRvIGFpZCBkZWJ1Z2dp
bmcgb2YgWGVuIGJ5IGVuc3VyaW5nCihYRU4pICoqKioqKiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5
bmNocm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4KKFhFTikgKioqKioqKiBI
b3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QK
KFhFTikgKioqKioqKiB0aW1la2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVkIGZvciBwcm9k
dWN0aW9uIHVzZSEKKFhFTikgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKgooWEVOKSAzLi4uIDIuLi4gMS4uLiAKKFhFTikgWGVuIGlzIHJlbGlucXVpc2hpbmcg
VkdBIGNvbnNvbGUuCihYRU4pICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1h
JyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQooWEVOKSBGcmVlZCAyNzZrQiBp
bml0IG1lbW9yeS4KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKWGVuOiBzZXR1
cCBJU0EgaWRlbnRpdHkgbWFwcwphYm91dCB0byBnZXQgc3RhcnRlZC4uLgpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVzZXQKWyAgICAwLjAwMDAwMF0gSW5pdGlh
bGl6aW5nIGNncm91cCBzdWJzeXMgY3B1ClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy4z
LjAtOC5mYzE2Lng4Nl82NCAobW9ja2J1aWxkQHg4Ni0wNS5waHgyLmZlZG9yYXByb2plY3Qub3Jn
KSAoZ2NjIHZlcnNpb24gNC42LjMgMjAxMjAzMDYgKFJlZCBIYXQgNC42LjMtMikgKEdDQykgKSAj
MSBTTVAgVGh1IE1hciAyOSAxODozNzoxOSBVVEMgMjAxMgpbICAgIDAuMDAwMDAwXSBDb21tYW5k
IGxpbmU6IHBsYWNlaG9sZGVyIGVhcmx5cHJpbnRrPXhlbiByb290PS9kZXYvbWFwcGVyL3ZnX2hh
bW1lcnN0b3JtLWx2X3Jvb3Qgcm8gcmQubWQ9MCByZC5kbT0wIFNZU0ZPTlQ9bGF0YXJjeXJoZWIt
c3VuMTYgcmhnYiBLRVlUQUJMRT11ayByZC5sdWtzPTAgcmQubHZtLmx2PXZnX2hhbW1lcnN0b3Jt
L2x2X3Jvb3QgcmQubHZtLmx2PXZnX2hhbW1lcnN0b3JtL2x2X3N3YXAgTEFORz1lbl9VUy5VVEYt
OApbICAgIDAuMDAwMDAwXSBGcmVlaW5nICA5ZS0xMDAgcGZuIHJhbmdlOiA5OCBwYWdlcyBmcmVl
ZApbICAgIDAuMDAwMDAwXSBGcmVlaW5nICAyMDAwMC0yMDIwMCBwZm4gcmFuZ2U6IDUxMiBwYWdl
cyBmcmVlZApbICAgIDAuMDAwMDAwXSBGcmVlaW5nICA0MDAwMC00MDIwMCBwZm4gcmFuZ2U6IDUx
MiBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAxMTIyIHBhZ2VzIG9mIHVudXNl
ZCBtZW1vcnkKWyAgICAwLjAwMDAwMF0gU2V0IDM1MjkxNCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5n
ClsgICAgMC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAw
MDAwMF0gIFhlbjogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWUwMDAgKHVzYWJsZSkK
WyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDA5ZWMwMCAtIDAwMDAwMDAwMDAxMDAwMDAg
KHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAw
MDAyMDAwMDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDIwMDAwMDAw
IC0gMDAwMDAwMDAyMDIwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw
MDAwMjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBY
ZW46IDAwMDAwMDAwNDAwMDAwMDAgLSAwMDAwMDAwMDQwMjAwMDAwIChyZXNlcnZlZCkKWyAgICAw
LjAwMDAwMF0gIFhlbjogMDAwMDAwMDA0MDIwMDAwMCAtIDAwMDAwMDAwYWExZDAwMDAgKHVzYWJs
ZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBhYTFkMDAwMCAtIDAwMDAwMDAwYWExZDAy
MDAgKEFDUEkgTlZTKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGFhMWQwMjAwIC0gMDAw
MDAwMDBhYTFkMzAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYWEx
ZDMwMDAgLSAwMDAwMDAwMGFhMmQwMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjog
MDAwMDAwMDBhYTJkMDAwMCAtIDAwMDAwMDAwYWEyZjAwMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAw
MDAwMF0gIFhlbjogMDAwMDAwMDBhYTJmMDAwMCAtIDAwMDAwMDAwYWZhMDAwMDAgKHJlc2VydmVk
KQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGY4MDAwMDAwIC0gMDAwMDAwMDBmYzAwMDAw
MCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAw
MDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWQx
MDAwMCAtIDAwMDAwMDAwZmVkMWEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAw
MDAwMDAwMGZlZDFjMDAwIC0gMDAwMDAwMDBmZWQyMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAw
MDBdICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkK
WyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZmMwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAg
KHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAw
MDFjZTYwMDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBd
IGVuYWJsZWQKWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjog
YWN0aXZlClsgICAgMC4wMDAwMDBdIERNSSAyLjUgcHJlc2VudC4KWyAgICAwLjAwMDAwMF0gTm8g
QUdQIGJyaWRnZSBmb3VuZApbICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MWNlNjAwIG1heF9h
cmNoX3BmbiA9IDB4NDAwMDAwMDAwClsgICAgMC4wMDAwMDBdIHgyYXBpYyBlbmFibGVkIGJ5IEJJ
T1MsIHN3aXRjaGluZyB0byB4MmFwaWMgb3BzClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0gMHhh
YTFkMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBpbml0X21lbW9y
eV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwYWExZDAwMDAKWyAgICAwLjAwMDAw
MF0gaW5pdF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDEwMDAwMDAwMC0wMDAwMDAwMWNlNjAwMDAw
ClsgICAgMC4wMDAwMDBdIFJBTURJU0s6IDAyMzk4MDAwIC0gMDUxM2EwMDAKWyAgICAwLjAwMDAw
MF0gQUNQSTogUlNEUCAwMDAwMDAwMDAwMGYwMDMwIDAwMDE0ICh2MDAgVE9TSElCKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBSU0RUIDAwMDAwMDAwYWEyZWYwMzggMDAwNTggKHYwMSBUT1NISUIgQTAw
N0QgICAgMDAwMDAwMDMgICAgICAwMTAwMDAxMykKWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAw
MDAwMDAwMGFhMmVlMDAwIDAwMDgxICh2MDIgVE9TSElCIEEwMDdEICAgIDAwMDAwMDAzIExPSFIg
MDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQgMDAwMDAwMDBhYTJkZDAwMCAwOEE0
NiAodjAyIFRPU0hJQiBBMDA3RCAgICAyMDExMTIyMCBJTlRMIDIwMDYxMTA5KQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBGQUNTIDAwMDAwMDAwYWEyYWQwMDAgMDAwNDAKWyAgICAwLjAwMDAwMF0gQUNQ
STogSFBFVCAwMDAwMDAwMGFhMmVkMDAwIDAwMDM4ICh2MDEgVE9TSElCIEEwMDdEICAgIDAwMDAw
MDAxIExPSFIgMDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBhYTJl
YzAwMCAwMDBCQyAodjAxIFRPU0hJQiBBMDA3RCAgICAwMDAwMDAwMSBMT0hSIDAwMDAwMDVGKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwYWEyZWIwMDAgMDAwM0MgKHYwMSBUT1NI
SUIgQTAwN0QgICAgMDAwMDAwMDEgTE9IUiAwMDAwMDA1RikKWyAgICAwLjAwMDAwMF0gQUNQSTog
QVNGISAwMDAwMDAwMGFhMmVhMDAwIDAwMEEwICh2MzIgVE9TSElCIEEwMDdEICAgIDAwMDAwMDAx
IExPSFIgMDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IFRDUEEgMDAwMDAwMDBhYTJlOTAw
MCAwMDAzMiAodjAyIFRPU0hJQiBBMDA3RCAgICAwMDAwMDAwMCBMT0hSIDAwMDAwMDVGKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBCT09UIDAwMDAwMDAwYWEyZTgwMDAgMDAwMjggKHYwMSBUT1NISUIg
QTAwN0QgICAgMDAwMDAwMDAgTE9IUiAwMDAwMDA1RikKWyAgICAwLjAwMDAwMF0gQUNQSTogU0xJ
QyAwMDAwMDAwMGFhMmU3MDAwIDAwMTc2ICh2MDEgVE9TSElCIEEwMDdEICAgIDAwMDAwMDAwIExP
SFIgMDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDBhYTJkYzAwMCAw
MDM5NSAodjAxIFRPU0hJQiBTYXRhQWhjaSAwMDAwMTAwMCBJTlRMIDIwMDYxMTA5KQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYWEyZDkwMDAgMDA3MjAgKHYwMSBUT1NISUIgUHRp
ZERldmMgMDAwMDEwMDAgSU5UTCAyMDA2MTEwOSkKWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAw
MDAwMDAwMGFhMmQ3MDAwIDAwODI3ICh2MDEgIFBtUmVmICBDcHUwSXN0IDAwMDAzMDAwIElOVEwg
MjAwNjExMDkpClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDBhYTJkNjAwMCAwMDk5
NiAodjAxICBQbVJlZiAgICBDcHVQbSAwMDAwMzAwMCBJTlRMIDIwMDYxMTA5KQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBYTUFSIDAwMDAwMDAwYWEyZDUwMDAgMDAxMTAgKHYwMSBJTlRFTCAgICAgIFNO
QiAgMDAwMDAwMDEgSU5UTCAwMDAwMDAwMSkKWyAgICAwLjAwMDAwMF0gU2V0dGluZyBBUElDIHJv
dXRpbmcgdG8gY2x1c3RlciB4MmFwaWMuClsgICAgMC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJh
dGlvbiBmb3VuZApbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAw
MDAtMDAwMDAwMDFjZTYwMDAwMApbICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCAw
MDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAxY2U2MDAwMDAKWyAgICAwLjAwMDAwMF0gICBOT0RFX0RB
VEEgWzAwMDAwMDAwN2ZmZWMwMDAgLSAwMDAwMDAwMDdmZmZmZmZmXQpbICAgIDAuMDAwMDAwXSBa
b25lIFBGTiByYW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAgICAgMHgwMDAwMDAxMCAtPiAw
eDAwMDAxMDAwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgMHgwMDAwMTAwMCAtPiAweDAwMTAw
MDAwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgMHgwMDEwMDAwMCAtPiAweDAwMWNlNjAwClsg
ICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQpbICAgIDAu
MDAwMDAwXSBFYXJseSBtZW1vcnkgUEZOIHJhbmdlcwpbICAgIDAuMDAwMDAwXSAgICAgMDogMHgw
MDAwMDAxMCAtPiAweDAwMDAwMDllClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMTAwIC0+
IDB4MDAwMjAwMDAKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMjAyMDAgLT4gMHgwMDA0MDAw
MApbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDA0MDIwMCAtPiAweDAwMGFhMWQwClsgICAgMC4w
MDAwMDBdICAgICAwOiAweDAwMTAwMDAwIC0+IDB4MDAxY2U2MDAKWyAgICAwLjAwMDAwMF0gQUNQ
STogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5h
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRb
MHgwMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVd
IGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDA2XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAwXSBoaWdoIGVkZ2UgbGludFsweDFdKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMV0gaGlnaCBlZGdlIGxp
bnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDJdIGhp
Z2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9p
ZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19O
TUkgKGFjcGlfaWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDVdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA2XSBoaWdoIGVkZ2UgbGludFsweDFd
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwN10gaGlnaCBlZGdl
IGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDAyXSBhZGRyZXNz
WzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMF06IGFwaWNf
aWQgMiwgdmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yMwpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwg
ZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGds
b2JhbF9pcnEgOSBoaWdoIGxldmVsKQpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBm
b3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBF
VCBpZDogMHg4MDg2YTIwMSBiYXNlOiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDogQWxs
b3dpbmcgOCBDUFVzLCA0IGhvdHBsdWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMDAwMDllMDAwIC0gMDAwMDAwMDAwMDA5ZjAwMApbICAg
IDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMDAwMDlmMDAw
IC0gMDAwMDAwMDAwMDEwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUg
bWVtb3J5OiAwMDAwMDAwMDIwMDAwMDAwIC0gMDAwMDAwMDAyMDIwMDAwMApbICAgIDAuMDAwMDAw
XSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAw
MDA0MDIwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAw
MDAwMDAwMGFhMWQwMDAwIC0gMDAwMDAwMDBhYTFkMTAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVn
aXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFhMWQxMDAwIC0gMDAwMDAwMDBhYTFkMzAw
MApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFh
MWQzMDAwIC0gMDAwMDAwMDBhYTJkMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBu
b3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFhMmQwMDAwIC0gMDAwMDAwMDBhYTJmMDAwMApbICAgIDAu
MDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFhMmYwMDAwIC0g
MDAwMDAwMDBhZmEwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVt
b3J5OiAwMDAwMDAwMGFmYTAwMDAwIC0gMDAwMDAwMDBmODAwMDAwMApbICAgIDAuMDAwMDAwXSBQ
TTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGY4MDAwMDAwIC0gMDAwMDAwMDBm
YzAwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAw
MDAwMGZjMDAwMDAwIC0gMDAwMDAwMDBmZWMwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0
ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMTAwMApb
ICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlYzAx
MDAwIC0gMDAwMDAwMDBmZWQxMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3Nh
dmUgbWVtb3J5OiAwMDAwMDAwMGZlZDEwMDAwIC0gMDAwMDAwMDBmZWQxYTAwMApbICAgIDAuMDAw
MDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZDFhMDAwIC0gMDAw
MDAwMDBmZWQxYzAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5
OiAwMDAwMDAwMGZlZDFjMDAwIC0gMDAwMDAwMDBmZWQyMDAwMApbICAgIDAuMDAwMDAwXSBQTTog
UmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWUw
MDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAw
MGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZTAxMDAwIC0gMDAwMDAwMDBmZmMwMDAwMApbICAg
IDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZmYzAwMDAw
IC0gMDAwMDAwMDEwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBBbGxvY2F0aW5nIFBDSSByZXNvdXJj
ZXMgc3RhcnRpbmcgYXQgYWZhMDAwMDAgKGdhcDogYWZhMDAwMDA6NDg2MDAwMDApClsgICAgMC4w
MDAwMDBdIEJvb3RpbmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4KWyAgICAwLjAwMDAw
MF0gWGVuIHZlcnNpb246IDQuMi11bnN0YWJsZSAocHJlc2VydmUtQUQpClsgICAgMC4wMDAwMDBd
IHNldHVwX3BlcmNwdTogTlJfQ1BVUzoyNTYgbnJfY3B1bWFza19iaXRzOjI1NiBucl9jcHVfaWRz
OjggbnJfbm9kZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2Vz
L2NwdSBAZmZmZjg4MDA3ZmVkMzAwMCBzODI4MTYgcjgxOTIgZDIzNjgwIHUxMTQ2ODgKWyAgICA1
LjA0NTQwMV0gQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9uZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBp
bmcgb24uICBUb3RhbCBwYWdlczogMTUxMDA0NgpbICAgIDUuMDQ2OTg3XSBQb2xpY3kgem9uZTog
Tm9ybWFsClsgICAgNS4wNDc2MDJdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIGVh
cmx5cHJpbnRrPXhlbiByb290PS9kZXYvbWFwcGVyL3ZnX2hhbW1lcnN0b3JtLWx2X3Jvb3Qgcm8g
cmQubWQ9MCByZC5kbT0wIFNZU0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgcmhnYiBLRVlUQUJMRT11
ayByZC5sdWtzPTAgcmQubHZtLmx2PXZnX2hhbW1lcnN0b3JtL2x2X3Jvb3QgcmQubHZtLmx2PXZn
X2hhbW1lcnN0b3JtL2x2X3N3YXAgTEFORz1lbl9VUy5VVEYtOApbICAgIDUuMDUyNzQ4XSBQSUQg
aGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3NjggYnl0ZXMpCihYRU4pIGRv
bWFpbi5jOjY5MTpkMCBAcHZfZ3Vlc3RfY3I0X2ZpeHVwLXN0YXJ0OiBpZD0wIGh2X2NyNDogMDAw
MDI2NjAgLT4gZ3Vlc3RfY3I0OjAwMDAyNjYwCihYRU4pIGRvbWFpbi5jOjcwNzpkMCBAcHZfZ3Vl
c3RfY3I0X2ZpeHVwLWVuZDogaWQ9MCBodl9jcjQ6IDAwMDAyNjYwIGd1ZXN0X2NyNDogMDAwMDI2
NjAgcmV0dXJuOiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTE6ZDAgQHB2X2d1ZXN0X2NyNF9m
aXh1cC1zdGFydDogaWQ9MCBodl9jcjQ6IDAwMDAyNjYwIC0+IGd1ZXN0X2NyNDowMDAwMjY2MAoo
WEVOKSBkb21haW4uYzo3MDc6ZDAgQHB2X2d1ZXN0X2NyNF9maXh1cC1lbmQ6IGlkPTAgaHZfY3I0
OiAwMDAwMjY2MCBndWVzdF9jcjQ6IDAwMDAyNjYwIHJldHVybjogMDAwMDI2NjAKKFhFTikgZG9t
YWluLmM6NjkxOmQwIEBwdl9ndWVzdF9jcjRfZml4dXAtc3RhcnQ6IGlkPTAgaHZfY3I0OiAwMDAw
MjY2MCAtPiBndWVzdF9jcjQ6MDAwMDI2NjAKKFhFTikgZG9tYWluLmM6NzA3OmQwIEBwdl9ndWVz
dF9jcjRfZml4dXAtZW5kOiBpZD0wIGh2X2NyNDogMDAwMDI2NjAgZ3Vlc3RfY3I0OiAwMDAwMjY2
MCByZXR1cm46IDAwMDAyNjYwCihYRU4pIHRyYXBzLmM6MjI0MzpkMCBAWFNFVEJWOiBuZXdfeGZl
YXR1cmU6IDAwMDAwMDAwMDAwMDAwMDcKKFhFTikgdHJhcHMuYzoyMjQ2OmQwIEBYU0VUQlY6ICh2
LT5hcmNoLnB2X3ZjcHUuY3RybHJlZ1s0XSAmIFg4Nl9DUjRfT1NYU0FWRSk6IDAwMDAwMDAwMDAw
MDAwMDAKWyAgICA1LjA2Nzk0OV0gaW52YWxpZCBvcGNvZGU6IDAwMDAgWyMxXSBTTVAgClsgICAg
NS4wNjg3NTJdIENQVSAwIApbICAgIDUuMDY5MTE5XSBNb2R1bGVzIGxpbmtlZCBpbjoKWyAgICA1
LjA2OTgzMV0gClsgICAgNS4wNzAxMjJdIFBpZDogMCwgY29tbTogc3dhcHBlciBOb3QgdGFpbnRl
ZCAzLjMuMC04LmZjMTYueDg2XzY0ICMxIFRPU0hJQkEgVEVDUkEgUjg0MC9Qb3J0YWJsZSBQQwpb
ICAgIDUuMDcxOTA0XSBSSVA6IGUwMzA6WzxmZmZmZmZmZjgxMDFlOGE3Pl0gIFs8ZmZmZmZmZmY4
MTAxZThhNz5dIHhzdGF0ZV9lbmFibGUrMHgzNy8weDQwClsgICAgNS4wNzM4NjVdIFJTUDogZTAy
YjpmZmZmZmZmZjgxYzAxZTQ4ICBFRkxBR1M6IDAwMDEwMDQ2ClsgICAgNS4wNzUxMDRdIFJBWDog
MDAwMDAwMDAwMDAwMDAwNyBSQlg6IGZmZmZmZmZmODFjMDFlODQgUkNYOiAwMDAwMDAwMDAwMDAw
MDAwClsgICAgNS4wNzY1MDNdIFJEWDogMDAwMDAwMDAwMDAwMDAwMCBSU0k6IDAwMDAwMDAwMDAw
MDAwMDcgUkRJOiAwMDAwMDAwMDAwMDAyNjYwClsgICAgNS4wNzgyNTVdIFJCUDogZmZmZmZmZmY4
MWMwMWU0OCBSMDg6IGZmZmZmZmZmODFjMDFlODAgUjA5OiBmZmZmZmZmZjgxYzAxZTg0ClsgICAg
NS4wNzk3OTNdIFIxMDogMDAwMDAwMDBmZmZmZmZmZiBSMTE6IDAwMDAwMDAwZmZmZmZmZmYgUjEy
OiBmZmZmZmZmZjgxYzAxZTgwClsgICAgNS4wODExOTFdIFIxMzogZmZmZmZmZmY4MWMwMWU3YyBS
MTQ6IGZmZmZmZmZmODFjMDFlNzggUjE1OiBmZmZmODgwMDdmZWRmNmUwClsgICAgNS4wODI1OTVd
IEZTOiAgMDAwMDAwMDAwMDAwMDAwMCgwMDAwKSBHUzpmZmZmODgwMDdmZWQzMDAwKDAwMDApIGtu
bEdTOjAwMDAwMDAwMDAwMDAwMDAKWyAgICA1LjA4NDE3Nl0gQ1M6ICBlMDMzIERTOiAwMDAwIEVT
OiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYgpbICAgIDUuMDg1MzQxXSBDUjI6IDAwMDAwMDAw
MDAwMDAwMDAgQ1IzOiAwMDAwMDAwMDAxYzA1MDAwIENSNDogMDAwMDAwMDAwMDAwMjY2MApbICAg
IDUuMDg2NzQ0XSBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAwMDAwMDAwIERS
MjogMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMDg4MTQ0XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAg
RFI2OiAwMDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMApbICAgIDUuMDg5NTg3
XSBQcm9jZXNzIHN3YXBwZXIgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZmZjgxYzAwMDAwLCB0
YXNrIGZmZmZmZmZmODFjMGQwMjApClsgICAgNS4wOTEzMjZdIFN0YWNrOgpbICAgIDUuMDkxNzE2
XSAgZmZmZmZmZmY4MWMwMWVjOCBmZmZmZmZmZjgxY2Y4YjEzIGZmZmZmZmZmODEwMGE4ZmYgZmZm
ZmZmZmY4MTAwNDYzZApbICAgIDUuMDkzMTc5XSAgZmZmZjg4MDA3ZmVkZTE1MCBmZmZmODgwMDdm
ZWRlOTUwIDAwMDAwMjQwMDAwMDAwMDcgMDAwMDAwMDAwMDAwMDM0MApbICAgIDUuMDk0NzE1XSAg
ZmZmZjg4MDA3ZmVkZTE1MCAwMDAwMDAwMDAwMDAwMDA4IDAwMDAwMDAwMDAwMDAwMDQgMDAwMDAw
MDAwMDAwMDAwOApbICAgIDUuMDk2NTU2XSBDYWxsIFRyYWNlOgpbICAgIDUuMDk3MDUyXSAgWzxm
ZmZmZmZmZjgxY2Y4YjEzPl0geHN0YXRlX2VuYWJsZV9ib290X2NwdSsweGE5LzB4MjYzClsgICAg
NS4wOTgyODNdICBbPGZmZmZmZmZmODEwMGE4ZmY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9y
ZWxvYysweDQvMHg0ClsgICAgNS4wOTk5NThdICBbPGZmZmZmZmZmODEwMDQ2M2Q+XSA/IHhlbl9j
bHRzKzB4OGQvMHgxOTAKWyAgICA1LjEwMDk3NV0gIFs8ZmZmZmZmZmY4MTVkZTViOT5dIHhzYXZl
X2luaXQrMHgyNi8weDI4ClsgICAgNS4xMDE5ODFdICBbPGZmZmZmZmZmODE1ZTA4NmY+XSBjcHVf
aW5pdCsweDJmOC8weDMxNQpbICAgIDUuMTAyOTg4XSAgWzxmZmZmZmZmZjgxY2Y1MTc0Pl0gdHJh
cF9pbml0KzB4MTY5LzB4MWRlClsgICAgNS4xMDQwMTFdICBbPGZmZmZmZmZmODFjZjBhMTM+XSBz
dGFydF9rZXJuZWwrMHgxZDUvMHgzYzUKWyAgICA1LjEwNTM2NF0gIFs8ZmZmZmZmZmY4MWNmMDM0
Nj5dIHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzUKWyAgICA1LjEwNjY2Nl0g
IFs8ZmZmZmZmZmY4MWNmMmZlMj5dIHhlbl9zdGFydF9rZXJuZWwrMHg1NzQvMHg1N2IKWyAgICA1
LjEwNzgwNF0gQ29kZTogNDggODkgZTUgZmYgMTQgMjUgZDAgNzQgYzEgODEgNDggODkgYzcgNDgg
ODEgY2YgMDAgMDAgMDQgMDAgZmYgMTQgMjUgZDggNzQgYzEgODEgNDggOGIgMDUgYjIgN2YgZGQg
MDAgMzEgYzkgNDggODkgYzIgNDggYzEgZWEgMjAgPDBmPiAwMSBkMSA1ZCBjMyAwZiAxZiA0MCAw
MCA1NSA0OCA4OSBlNSA0MSA1NSA0MSA1NCA1MyA0OCA4MyBlYyAKWyAgICA1LjExMjM0NF0gUklQ
ICBbPGZmZmZmZmZmODEwMWU4YTc+XSB4c3RhdGVfZW5hYmxlKzB4MzcvMHg0MApbICAgIDUuMTEz
NDY5XSAgUlNQIDxmZmZmZmZmZjgxYzAxZTQ4PgpbICAgIDUuMTE0NDI1XSAtLS1bIGVuZCB0cmFj
ZSBhNzkxOWU3ZjE3YzBhNzI1IF0tLS0KWyAgICA1LjExNTQyNl0gS2VybmVsIHBhbmljIC0gbm90
IHN5bmNpbmc6IEF0dGVtcHRlZCB0byBraWxsIHRoZSBpZGxlIHRhc2shCihYRU4pIERvbWFpbiAw
IGNyYXNoZWQ6IHJlYm9vdGluZyBtYWNoaW5lIGluIDUgc2Vjb25kcy4KKFhFTikgUmVzZXR0aW5n
IHdpdGggQUNQSSBNRU1PUlkgb3IgSS9PIFJFU0VUX1JFRy4K

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_--


From xen-devel-bounces@lists.xen.org Tue Apr 10 12:24:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHa7M-0005h5-4j; Tue, 10 Apr 2012 12:24:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHa7J-0005h0-UR
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 12:24:14 +0000
Received: from [85.158.138.51:41517] by server-5.bemta-3.messagelabs.com id
	C0/2D-24278-D66248F4; Tue, 10 Apr 2012 12:24:13 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334060651!21467810!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAyMTMz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22024 invoked from network); 10 Apr 2012 12:24:11 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 12:24:11 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHa7G-0002EN-AT; Tue, 10 Apr 2012 13:24:10 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Tue, 10 Apr 2012
	13:23:21 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 10 Apr 2012 13:23:21 +0100
Thread-Topic: [Xen-devel] lastest xen unstable crash
Thread-Index: Ac0XC/jC3OO1BMjzReC9ZvI+H16b4QABRY5d
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B693@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
	<4F8430C7020000780007CFD3@nat28.tlf.novell.com>,
	<4F8433A0020000780007CFE6@nat28.tlf.novell.com>
In-Reply-To: <4F8433A0020000780007CFE6@nat28.tlf.novell.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
Content-Type: multipart/mixed;
	boundary="_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


________________________________________
From: Jan Beulich [JBeulich@suse.com]
Sent: 10 April 2012 12:20
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] lastest xen unstable crash

>>> On 10.04.12 at 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> In any case, a fundamental question is whether your CPU has
> XSAVE support in the first place, and whether kernel and
> hypervisor disagree about that for some reason. Could you
> for that purpose post /proc/cpuinfo contents from when running
> a native kernel?

Just realized that this question is answered by the log you provided:

(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7

so indeed the fastest approach (short of someone seeing something
obviously wrong with the code) appears to be to add some tracing to
the CR4 handling (pv_guest_cr4_fixup() and the XSETBV handling in
emulate_privileged_op()), particularly also because the register dump
indicates that the relevant bit was not set in CR4 at the point where
the XSETBV faulted.

Jan

I have added some prints in the functions you mentioned. Is this what you n=
eed?=20
These are the new lines in the dmesg, the attached file contains the rest.

(XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=3D0 hv_cr4: 00002660 ->=
 guest_cr4:00002660
(XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=3D0 hv_cr4: 00002660 gues=
t_cr4: 00002660 return: 00002660
(XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=3D0 hv_cr4: 00002660 ->=
 guest_cr4:00002660
(XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=3D0 hv_cr4: 00002660 gues=
t_cr4: 00002660 return: 00002660
(XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=3D0 hv_cr4: 00002660 ->=
 guest_cr4:00002660
(XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=3D0 hv_cr4: 00002660 gues=
t_cr4: 00002660 return: 00002660
(XEN) traps.c:2243:d0 @XSETBV: new_xfeature: 0000000000000007
(XEN) traps.c:2246:d0 @XSETBV: (v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_OSXSAV=
E): 0000000000000000

Here is the /proc/cpuinfo running on a native kernel:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x25
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat =
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm =
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aper=
fmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr =
pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf=
_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5382.77
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

and /proc/cpuinfo with dom0 running with xsave=3D0:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x23
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse=
 sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc aperfmperf=
 pni pclmulqdq est ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_time=
r aes hypervisor lahf_lm ida arat epb pln pts dts
bogomips	: 5382.58
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Cheers,
Francisco=

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_
Content-Type: text/plain; name="xen_xsave_crash.txt"
Content-Description: xen_xsave_crash.txt
Content-Disposition: attachment; filename="xen_xsave_crash.txt"; size=23007;
	creation-date="Tue, 10 Apr 2012 13:19:08 GMT";
	modification-date="Tue, 10 Apr 2012 13:19:08 GMT"
Content-Transfer-Encoding: base64

IFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBf
XyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwgJ18gXCAgfCB8fCB8XyAgIF9fKSB8X198IHwg
fCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBfIFwKICAvICBcICBfXy8gfCB8IHwgfF9f
ICAgX3wgLyBfXy98X198IHxffCB8IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8KIC9f
L1xfXF9fX3xffCB8X3wgICAgfF98KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxf
fF8uX18vfF98XF9fX3wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24gNC4yLXVu
c3RhYmxlIChyb290QG5jbC5hYy51aykgKGdjYyB2ZXJzaW9uIDQuNi4zIDIwMTIwMzA2IChSZWQg
SGF0IDQuNi4zLTIpIChHQ0MpICkgVHVlIEFwciAxMCAxMzowODozOSBCU1QgMjAxMgooWEVOKSBM
YXRlc3QgQ2hhbmdlU2V0OiBUaHUgQXByIDA1IDExOjA2OjAzIDIwMTIgKzAxMDAgMjUxNjE6ZDY5
MGM3ZTg5NmEyCihYRU4pIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9ub3VzLgooWEVOKSBCb290
bG9hZGVyOiBHUlVCIDEuOTkKKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBsb2dsdmw9
YWxsIGRvbTBfbWVtPTIwNDhNIHN5bmNfY29uc29sZSBjb20xPTExNTIwMCw4bjEsMHgzMDkwLDE5
IGNvbnNvbGU9Y29tMSx2Z2EKKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMg
dGV4dCBtb2RlIDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVE
SUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4p
ICBGb3VuZCAxIE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBz
dHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAw
IC0gMDAwMDAwMDAwMDA5ZWMwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5ZWMwMCAtIDAw
MDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAw
MDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAw
MjAwMDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAw
MDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwMjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAw
ICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAocmVz
ZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDQwMjAwMDAwIC0gMDAwMDAwMDBhYTFkMDAwMCAodXNhYmxl
KQooWEVOKSAgMDAwMDAwMDBhYTFkMDAwMCAtIDAwMDAwMDAwYWExZDAyMDAgKEFDUEkgTlZTKQoo
WEVOKSAgMDAwMDAwMDBhYTFkMDIwMCAtIDAwMDAwMDAwYWExZDMwMDAgKHJlc2VydmVkKQooWEVO
KSAgMDAwMDAwMDBhYTFkMzAwMCAtIDAwMDAwMDAwYWEyZDAwMDAgKEFDUEkgTlZTKQooWEVOKSAg
MDAwMDAwMDBhYTJkMDAwMCAtIDAwMDAwMDAwYWEyZjAwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAw
MDAwMDAwYWEyZjAwMDAgLSAwMDAwMDAwMGFmYTAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAw
MDAwZjgwMDAwMDAgLSAwMDAwMDAwMGZjMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAw
ZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVk
MTAwMDAgLSAwMDAwMDAwMGZlZDFhMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVkMWMw
MDAgLSAwMDAwMDAwMGZlZDIwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAg
LSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmZjMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAw
MDAwMWNlNjAwMDAwICh1c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRjAwMzAsIDAwMTQgKHIw
IFRPU0hJQikKKFhFTikgQUNQSTogUlNEVCBBQTJFRjAzOCwgMDA1OCAocjEgVE9TSElCIEEwMDdE
ICAgICAgICAgICAzICAgICAgIDEwMDAwMTMpCihYRU4pIEFDUEk6IEZBQ1AgQUEyRUUwMDAsIDAw
ODEgKHIyIFRPU0hJQiBBMDA3RCAgICAgICAgICAgMyBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJ
OiBEU0RUIEFBMkREMDAwLCA4QTQ2IChyMiBUT1NISUIgQTAwN0QgICAgMjAxMTEyMjAgSU5UTCAy
MDA2MTEwOSkKKFhFTikgQUNQSTogRkFDUyBBQTJBRDAwMCwgMDA0MAooWEVOKSBBQ1BJOiBIUEVU
IEFBMkVEMDAwLCAwMDM4IChyMSBUT1NISUIgQTAwN0QgICAgICAgICAgIDEgTE9IUiAgICAgICA1
RikKKFhFTikgQUNQSTogQVBJQyBBQTJFQzAwMCwgMDBCQyAocjEgVE9TSElCIEEwMDdEICAgICAg
ICAgICAxIExPSFIgICAgICAgNUYpCihYRU4pIEFDUEk6IE1DRkcgQUEyRUIwMDAsIDAwM0MgKHIx
IFRPU0hJQiBBMDA3RCAgICAgICAgICAgMSBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJOiBBU0Yh
IEFBMkVBMDAwLCAwMEEwIChyMzIgVE9TSElCIEEwMDdEICAgICAgICAgICAxIExPSFIgICAgICAg
NUYpCihYRU4pIEFDUEk6IFRDUEEgQUEyRTkwMDAsIDAwMzIgKHIyIFRPU0hJQiBBMDA3RCAgICAg
ICAgICAgMCBMT0hSICAgICAgIDVGKQooWEVOKSBBQ1BJOiBCT09UIEFBMkU4MDAwLCAwMDI4IChy
MSBUT1NISUIgQTAwN0QgICAgICAgICAgIDAgTE9IUiAgICAgICA1RikKKFhFTikgQUNQSTogU0xJ
QyBBQTJFNzAwMCwgMDE3NiAocjEgVE9TSElCIEEwMDdEICAgICAgICAgICAwIExPSFIgICAgICAg
NUYpCihYRU4pIEFDUEk6IFNTRFQgQUEyREMwMDAsIDAzOTUgKHIxIFRPU0hJQiBTYXRhQWhjaSAg
ICAgMTAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBBQ1BJOiBTU0RUIEFBMkQ5MDAwLCAwNzIwIChy
MSBUT1NISUIgUHRpZERldmMgICAgIDEwMDAgSU5UTCAyMDA2MTEwOSkKKFhFTikgQUNQSTogU1NE
VCBBQTJENzAwMCwgMDgyNyAocjEgIFBtUmVmICBDcHUwSXN0ICAgICAzMDAwIElOVEwgMjAwNjEx
MDkpCihYRU4pIEFDUEk6IFNTRFQgQUEyRDYwMDAsIDA5OTYgKHIxICBQbVJlZiAgICBDcHVQbSAg
ICAgMzAwMCBJTlRMIDIwMDYxMTA5KQooWEVOKSBBQ1BJOiBETUFSIEFBMkQ1MDAwLCAwMTEwIChy
MSBJTlRFTCAgICAgIFNOQiAgICAgICAgIDEgSU5UTCAgICAgICAgMSkKKFhFTikgU3lzdGVtIFJB
TTogNjAxOU1CICg2MTYzODk2a0IpCihYRU4pIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZAoo
WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDFjZTYwMDAwMAoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZAooWEVOKSBETUkgMi41IHByZXNlbnQuCihYRU4p
IFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDog
MHg0MDgKKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs0MDQsMF0sIHBtMXhf
ZXZ0WzQwMCwwXQooWEVOKSBBQ1BJOiAgICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbYWEyYWQw
MGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAw
MDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxl
ZCkKKFhFTikgUHJvY2Vzc29yICMwIDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3Nv
ciAjMSA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAy
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzIgNjoxMCBBUElDIHZl
cnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10g
ZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMzIDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVO
KSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhF
TikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihY
RU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAyXSBoaWdoIGVkZ2UgbGludFsweDFdKQoo
WEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwM10gaGlnaCBlZGdlIGxpbnRbMHgxXSkK
KFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0p
CihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFd
KQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNl0gaGlnaCBlZGdlIGxpbnRbMHgx
XSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDddIGhpZ2ggZWRnZSBsaW50WzB4
MV0pCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwMl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDIsIHZlcnNpb24gMzIsIGFkZHJlc3Mg
MHhmZWMwMDAwMCwgR1NJIDAtMjMKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19p
cnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAw
IGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkKKFhFTikgQUNQSTogSVJRMCB1c2Vk
IGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFD
UEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxh
dC4gIFVzaW5nIDEgSS9PIEFQSUNzCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFz
ZTogMHhmZWQwMDAwMAooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCihYRU4pIFVzaW5nIEFDUEkg
KE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93
aW5nIDggQ1BVcyAoNCBob3RwbHVnIENQVXMpCihYRU4pIElSUSBsaW1pdHM6IDI0IEdTSSwgNzYw
IE1TSS9NU0ktWAooWEVOKSBTd2l0Y2hlZCB0byBBUElDIGRyaXZlciB4MmFwaWNfY2x1c3Rlci4K
KFhFTikgVXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQooWEVO
KSBEZXRlY3RlZCAyNjkxLjMyNiBNSHogcHJvY2Vzc29yLgooWEVOKSBJbml0aW5nIG1lbW9yeSBz
aGFyaW5nLgooWEVOKSB4c3RhdGVfaW5pdDogdXNpbmcgY250eHRfc2l6ZTogMHgzNDAgYW5kIHN0
YXRlczogMHg3CihYRU4pIG1jZV9pbnRlbC5jOjEyMzk6IE1DQSBDYXBhYmlsaXR5OiBCQ0FTVCAx
IFNFUiAwIENNQ0kgMSBmaXJzdGJhbmsgMCBleHRlbmRlZCBNQ0UgTVNSIDAKKFhFTikgSW50ZWwg
bWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZAooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJh
dGlvbiAwOiBiYXNlIGY4MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDNmCihYRU4pIFBD
STogTUNGRyBhcmVhIGF0IGY4MDAwMDAwIHJlc2VydmVkIGluIEU4MjAKKFhFTikgUENJOiBVc2lu
ZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLTNmCihYRU4pIEludGVsIFZULWQgU25vb3Ag
Q29udHJvbCBub3QgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBEb20wIERNQSBQYXNzdGhyb3Vn
aCBub3QgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBRdWV1ZWQgSW52YWxpZGF0aW9uIGVuYWJs
ZWQuCihYRU4pIEludGVsIFZULWQgSW50ZXJydXB0IFJlbWFwcGluZyBlbmFibGVkLgooWEVOKSBJ
bnRlbCBWVC1kIFNoYXJlZCBFUFQgdGFibGVzIG5vdCBlbmFibGVkLgooWEVOKSBJL08gdmlydHVh
bGlzYXRpb24gZW5hYmxlZAooWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKKFhFTikgRW5hYmxl
ZCBkaXJlY3RlZCBFT0kgd2l0aCBpb2FwaWNfYWNrX29sZCBvbiEKKFhFTikgRU5BQkxJTkcgSU8t
QVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBvbGQgQUNLIG1ldGhvZAooWEVOKSAuLlRJTUVSOiB2
ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCihYRU4pIFRTQyBkZWFk
bGluZSB0aW1lciBlbmFibGVkCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVU
CihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgMzIgS2lCLgooWEVOKSBWTVg6IFN1cHBv
cnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFs
aXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gRXh0ZW5kZWQgUGFnZSBU
YWJsZXMgKEVQVCkKKFhFTikgIC0gVmlydHVhbC1Qcm9jZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQp
CihYRU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNzIGJpdG1hcAoo
WEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhFTikgSFZNOiBBU0lEcyBlbmFibGVkLgooWEVO
KSBIVk06IFZNWCBlbmFibGVkCihYRU4pIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChI
QVApIGRldGVjdGVkCihYRU4pIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1CCihYRU4pIEJy
b3VnaHQgdXAgNCBDUFVzCihYRU4pIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4pIG1jaGVja19w
b2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikgKioqIExPQURJ
TkcgRE9NQUlOIDAgKioqCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAw
MDAwMCBtZW1zej0weGE4NjAwMAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0w
eDFjMDAwMDAgbWVtc3o9MHhkYTBlMAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRk
cj0weDFjZGIwMDAgbWVtc3o9MHgxNDM4MAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBw
YWRkcj0weDFjZjAwMDAgbWVtc3o9MHg2YTgwMDAKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogbWVt
b3J5OiAweDEwMDAwMDAgLT4gMHgyMzk4MDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VF
U1RfT1MgPSAibGludXgiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9
ICIyLjYiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIK
KFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDAK
KFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MWNmMDIwMAooWEVO
KSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAw
CihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFi
bGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01P
REUgPSAieWVzIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmljIgoo
WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpCihYRU4p
IGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKKFhFTikgZWxmX3hl
bl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAKKFhFTikgZWxmX3hlbl9hZGRyX2NhbGNf
Y2hlY2s6IGFkZHJlc3NlczoKKFhFTikgICAgIHZpcnRfYmFzZSAgICAgICAgPSAweGZmZmZmZmZm
ODAwMDAwMDAKKFhFTikgICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKKFhFTikgICAgIHZpcnRf
b2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgICAgIHZpcnRfa3N0YXJ0ICAg
ICAgPSAweGZmZmZmZmZmODEwMDAwMDAKKFhFTikgICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZm
ZmZmZmZmODIzOTgwMDAKKFhFTikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZmZmZmODFj
ZjAyMDAKKFhFTikgICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYKKFhF
TikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKKFhFTikgIERvbTAga2VybmVs
OiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgyMzk4MDAwCihYRU4pIFBI
WVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAx
YzAwMDAwMDAtPjAwMDAwMDAxYzQwMDAwMDAgKDQ5NjIyMiBwYWdlcyB0byBiZSBhbGxvY2F0ZWQp
CihYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMWNiODVlMDAwLT4wMDAwMDAwMWNlNjAwMDAw
CihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDog
ZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MjM5ODAwMAooWEVOKSAgSW5pdC4gcmFtZGlzazog
ZmZmZmZmZmY4MjM5ODAwMC0+ZmZmZmZmZmY4NTEzYTAwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDog
ZmZmZmZmZmY4NTEzYTAwMC0+ZmZmZmZmZmY4NTUzYTAwMAooWEVOKSAgU3RhcnQgaW5mbzogICAg
ZmZmZmZmZmY4NTUzYTAwMC0+ZmZmZmZmZmY4NTUzYTRiNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAg
ZmZmZmZmZmY4NTUzYjAwMC0+ZmZmZmZmZmY4NTU2YTAwMAooWEVOKSAgQm9vdCBzdGFjazogICAg
ZmZmZmZmZmY4NTU2YTAwMC0+ZmZmZmZmZmY4NTU2YjAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAg
ZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NTgwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzog
ZmZmZmZmZmY4MWNmMDIwMAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDQgVkNQVXMKKFhFTikgZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4
MWE4NjAwMAooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFjMDAw
MDAgLT4gMHhmZmZmZmZmZjgxY2RhMGUwCihYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0
IDB4ZmZmZmZmZmY4MWNkYjAwMCAtPiAweGZmZmZmZmZmODFjZWYzODAKKFhFTikgZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxY2YwMDAwIC0+IDB4ZmZmZmZmZmY4MWRkYzAw
MAooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNl
dCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVOKSBHdWVzdCBM
b2dsZXZlbDogQWxsCihYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioKKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJP
Tk9VUwooWEVOKSAqKioqKioqIFRoaXMgb3B0aW9uIGlzIGludGVuZGVkIHRvIGFpZCBkZWJ1Z2dp
bmcgb2YgWGVuIGJ5IGVuc3VyaW5nCihYRU4pICoqKioqKiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5
bmNocm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4KKFhFTikgKioqKioqKiBI
b3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QK
KFhFTikgKioqKioqKiB0aW1la2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVkIGZvciBwcm9k
dWN0aW9uIHVzZSEKKFhFTikgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKgooWEVOKSAzLi4uIDIuLi4gMS4uLiAKKFhFTikgWGVuIGlzIHJlbGlucXVpc2hpbmcg
VkdBIGNvbnNvbGUuCihYRU4pICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1h
JyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQooWEVOKSBGcmVlZCAyNzZrQiBp
bml0IG1lbW9yeS4KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkKWGVuOiBzZXR1
cCBJU0EgaWRlbnRpdHkgbWFwcwphYm91dCB0byBnZXQgc3RhcnRlZC4uLgpbICAgIDAuMDAwMDAw
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVzZXQKWyAgICAwLjAwMDAwMF0gSW5pdGlh
bGl6aW5nIGNncm91cCBzdWJzeXMgY3B1ClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy4z
LjAtOC5mYzE2Lng4Nl82NCAobW9ja2J1aWxkQHg4Ni0wNS5waHgyLmZlZG9yYXByb2plY3Qub3Jn
KSAoZ2NjIHZlcnNpb24gNC42LjMgMjAxMjAzMDYgKFJlZCBIYXQgNC42LjMtMikgKEdDQykgKSAj
MSBTTVAgVGh1IE1hciAyOSAxODozNzoxOSBVVEMgMjAxMgpbICAgIDAuMDAwMDAwXSBDb21tYW5k
IGxpbmU6IHBsYWNlaG9sZGVyIGVhcmx5cHJpbnRrPXhlbiByb290PS9kZXYvbWFwcGVyL3ZnX2hh
bW1lcnN0b3JtLWx2X3Jvb3Qgcm8gcmQubWQ9MCByZC5kbT0wIFNZU0ZPTlQ9bGF0YXJjeXJoZWIt
c3VuMTYgcmhnYiBLRVlUQUJMRT11ayByZC5sdWtzPTAgcmQubHZtLmx2PXZnX2hhbW1lcnN0b3Jt
L2x2X3Jvb3QgcmQubHZtLmx2PXZnX2hhbW1lcnN0b3JtL2x2X3N3YXAgTEFORz1lbl9VUy5VVEYt
OApbICAgIDAuMDAwMDAwXSBGcmVlaW5nICA5ZS0xMDAgcGZuIHJhbmdlOiA5OCBwYWdlcyBmcmVl
ZApbICAgIDAuMDAwMDAwXSBGcmVlaW5nICAyMDAwMC0yMDIwMCBwZm4gcmFuZ2U6IDUxMiBwYWdl
cyBmcmVlZApbICAgIDAuMDAwMDAwXSBGcmVlaW5nICA0MDAwMC00MDIwMCBwZm4gcmFuZ2U6IDUx
MiBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAxMTIyIHBhZ2VzIG9mIHVudXNl
ZCBtZW1vcnkKWyAgICAwLjAwMDAwMF0gU2V0IDM1MjkxNCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5n
ClsgICAgMC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAw
MDAwMF0gIFhlbjogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWUwMDAgKHVzYWJsZSkK
WyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDA5ZWMwMCAtIDAwMDAwMDAwMDAxMDAwMDAg
KHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAw
MDAyMDAwMDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDIwMDAwMDAw
IC0gMDAwMDAwMDAyMDIwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw
MDAwMjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBY
ZW46IDAwMDAwMDAwNDAwMDAwMDAgLSAwMDAwMDAwMDQwMjAwMDAwIChyZXNlcnZlZCkKWyAgICAw
LjAwMDAwMF0gIFhlbjogMDAwMDAwMDA0MDIwMDAwMCAtIDAwMDAwMDAwYWExZDAwMDAgKHVzYWJs
ZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBhYTFkMDAwMCAtIDAwMDAwMDAwYWExZDAy
MDAgKEFDUEkgTlZTKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGFhMWQwMjAwIC0gMDAw
MDAwMDBhYTFkMzAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYWEx
ZDMwMDAgLSAwMDAwMDAwMGFhMmQwMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjog
MDAwMDAwMDBhYTJkMDAwMCAtIDAwMDAwMDAwYWEyZjAwMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAw
MDAwMF0gIFhlbjogMDAwMDAwMDBhYTJmMDAwMCAtIDAwMDAwMDAwYWZhMDAwMDAgKHJlc2VydmVk
KQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGY4MDAwMDAwIC0gMDAwMDAwMDBmYzAwMDAw
MCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAw
MDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWQx
MDAwMCAtIDAwMDAwMDAwZmVkMWEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAw
MDAwMDAwMGZlZDFjMDAwIC0gMDAwMDAwMDBmZWQyMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAw
MDBdICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkK
WyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZmMwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAg
KHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAw
MDFjZTYwMDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBd
IGVuYWJsZWQKWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjog
YWN0aXZlClsgICAgMC4wMDAwMDBdIERNSSAyLjUgcHJlc2VudC4KWyAgICAwLjAwMDAwMF0gTm8g
QUdQIGJyaWRnZSBmb3VuZApbICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MWNlNjAwIG1heF9h
cmNoX3BmbiA9IDB4NDAwMDAwMDAwClsgICAgMC4wMDAwMDBdIHgyYXBpYyBlbmFibGVkIGJ5IEJJ
T1MsIHN3aXRjaGluZyB0byB4MmFwaWMgb3BzClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0gMHhh
YTFkMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBpbml0X21lbW9y
eV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwYWExZDAwMDAKWyAgICAwLjAwMDAw
MF0gaW5pdF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDEwMDAwMDAwMC0wMDAwMDAwMWNlNjAwMDAw
ClsgICAgMC4wMDAwMDBdIFJBTURJU0s6IDAyMzk4MDAwIC0gMDUxM2EwMDAKWyAgICAwLjAwMDAw
MF0gQUNQSTogUlNEUCAwMDAwMDAwMDAwMGYwMDMwIDAwMDE0ICh2MDAgVE9TSElCKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBSU0RUIDAwMDAwMDAwYWEyZWYwMzggMDAwNTggKHYwMSBUT1NISUIgQTAw
N0QgICAgMDAwMDAwMDMgICAgICAwMTAwMDAxMykKWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAw
MDAwMDAwMGFhMmVlMDAwIDAwMDgxICh2MDIgVE9TSElCIEEwMDdEICAgIDAwMDAwMDAzIExPSFIg
MDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQgMDAwMDAwMDBhYTJkZDAwMCAwOEE0
NiAodjAyIFRPU0hJQiBBMDA3RCAgICAyMDExMTIyMCBJTlRMIDIwMDYxMTA5KQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBGQUNTIDAwMDAwMDAwYWEyYWQwMDAgMDAwNDAKWyAgICAwLjAwMDAwMF0gQUNQ
STogSFBFVCAwMDAwMDAwMGFhMmVkMDAwIDAwMDM4ICh2MDEgVE9TSElCIEEwMDdEICAgIDAwMDAw
MDAxIExPSFIgMDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBhYTJl
YzAwMCAwMDBCQyAodjAxIFRPU0hJQiBBMDA3RCAgICAwMDAwMDAwMSBMT0hSIDAwMDAwMDVGKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwYWEyZWIwMDAgMDAwM0MgKHYwMSBUT1NI
SUIgQTAwN0QgICAgMDAwMDAwMDEgTE9IUiAwMDAwMDA1RikKWyAgICAwLjAwMDAwMF0gQUNQSTog
QVNGISAwMDAwMDAwMGFhMmVhMDAwIDAwMEEwICh2MzIgVE9TSElCIEEwMDdEICAgIDAwMDAwMDAx
IExPSFIgMDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IFRDUEEgMDAwMDAwMDBhYTJlOTAw
MCAwMDAzMiAodjAyIFRPU0hJQiBBMDA3RCAgICAwMDAwMDAwMCBMT0hSIDAwMDAwMDVGKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBCT09UIDAwMDAwMDAwYWEyZTgwMDAgMDAwMjggKHYwMSBUT1NISUIg
QTAwN0QgICAgMDAwMDAwMDAgTE9IUiAwMDAwMDA1RikKWyAgICAwLjAwMDAwMF0gQUNQSTogU0xJ
QyAwMDAwMDAwMGFhMmU3MDAwIDAwMTc2ICh2MDEgVE9TSElCIEEwMDdEICAgIDAwMDAwMDAwIExP
SFIgMDAwMDAwNUYpClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDBhYTJkYzAwMCAw
MDM5NSAodjAxIFRPU0hJQiBTYXRhQWhjaSAwMDAwMTAwMCBJTlRMIDIwMDYxMTA5KQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYWEyZDkwMDAgMDA3MjAgKHYwMSBUT1NISUIgUHRp
ZERldmMgMDAwMDEwMDAgSU5UTCAyMDA2MTEwOSkKWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAw
MDAwMDAwMGFhMmQ3MDAwIDAwODI3ICh2MDEgIFBtUmVmICBDcHUwSXN0IDAwMDAzMDAwIElOVEwg
MjAwNjExMDkpClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDBhYTJkNjAwMCAwMDk5
NiAodjAxICBQbVJlZiAgICBDcHVQbSAwMDAwMzAwMCBJTlRMIDIwMDYxMTA5KQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBYTUFSIDAwMDAwMDAwYWEyZDUwMDAgMDAxMTAgKHYwMSBJTlRFTCAgICAgIFNO
QiAgMDAwMDAwMDEgSU5UTCAwMDAwMDAwMSkKWyAgICAwLjAwMDAwMF0gU2V0dGluZyBBUElDIHJv
dXRpbmcgdG8gY2x1c3RlciB4MmFwaWMuClsgICAgMC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJh
dGlvbiBmb3VuZApbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAw
MDAtMDAwMDAwMDFjZTYwMDAwMApbICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCAw
MDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAxY2U2MDAwMDAKWyAgICAwLjAwMDAwMF0gICBOT0RFX0RB
VEEgWzAwMDAwMDAwN2ZmZWMwMDAgLSAwMDAwMDAwMDdmZmZmZmZmXQpbICAgIDAuMDAwMDAwXSBa
b25lIFBGTiByYW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAgICAgMHgwMDAwMDAxMCAtPiAw
eDAwMDAxMDAwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgMHgwMDAwMTAwMCAtPiAweDAwMTAw
MDAwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgMHgwMDEwMDAwMCAtPiAweDAwMWNlNjAwClsg
ICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQpbICAgIDAu
MDAwMDAwXSBFYXJseSBtZW1vcnkgUEZOIHJhbmdlcwpbICAgIDAuMDAwMDAwXSAgICAgMDogMHgw
MDAwMDAxMCAtPiAweDAwMDAwMDllClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMTAwIC0+
IDB4MDAwMjAwMDAKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMjAyMDAgLT4gMHgwMDA0MDAw
MApbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDA0MDIwMCAtPiAweDAwMGFhMWQwClsgICAgMC4w
MDAwMDBdICAgICAwOiAweDAwMTAwMDAwIC0+IDB4MDAxY2U2MDAKWyAgICAwLjAwMDAwMF0gQUNQ
STogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKWyAg
ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5h
YmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRb
MHgwMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVd
IGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDA2XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAwXSBoaWdoIGVkZ2UgbGludFsweDFdKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMV0gaGlnaCBlZGdlIGxp
bnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDJdIGhp
Z2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9p
ZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19O
TUkgKGFjcGlfaWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDVdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA2XSBoaWdoIGVkZ2UgbGludFsweDFd
KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwN10gaGlnaCBlZGdl
IGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDAyXSBhZGRyZXNz
WzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMF06IGFwaWNf
aWQgMiwgdmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yMwpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwg
ZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGds
b2JhbF9pcnEgOSBoaWdoIGxldmVsKQpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBm
b3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBF
VCBpZDogMHg4MDg2YTIwMSBiYXNlOiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDogQWxs
b3dpbmcgOCBDUFVzLCA0IGhvdHBsdWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMDAwMDllMDAwIC0gMDAwMDAwMDAwMDA5ZjAwMApbICAg
IDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMDAwMDlmMDAw
IC0gMDAwMDAwMDAwMDEwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUg
bWVtb3J5OiAwMDAwMDAwMDIwMDAwMDAwIC0gMDAwMDAwMDAyMDIwMDAwMApbICAgIDAuMDAwMDAw
XSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAw
MDA0MDIwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAw
MDAwMDAwMGFhMWQwMDAwIC0gMDAwMDAwMDBhYTFkMTAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVn
aXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFhMWQxMDAwIC0gMDAwMDAwMDBhYTFkMzAw
MApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFh
MWQzMDAwIC0gMDAwMDAwMDBhYTJkMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBu
b3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFhMmQwMDAwIC0gMDAwMDAwMDBhYTJmMDAwMApbICAgIDAu
MDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGFhMmYwMDAwIC0g
MDAwMDAwMDBhZmEwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVt
b3J5OiAwMDAwMDAwMGFmYTAwMDAwIC0gMDAwMDAwMDBmODAwMDAwMApbICAgIDAuMDAwMDAwXSBQ
TTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGY4MDAwMDAwIC0gMDAwMDAwMDBm
YzAwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAw
MDAwMGZjMDAwMDAwIC0gMDAwMDAwMDBmZWMwMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0
ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMTAwMApb
ICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlYzAx
MDAwIC0gMDAwMDAwMDBmZWQxMDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3Nh
dmUgbWVtb3J5OiAwMDAwMDAwMGZlZDEwMDAwIC0gMDAwMDAwMDBmZWQxYTAwMApbICAgIDAuMDAw
MDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZDFhMDAwIC0gMDAw
MDAwMDBmZWQxYzAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5
OiAwMDAwMDAwMGZlZDFjMDAwIC0gMDAwMDAwMDBmZWQyMDAwMApbICAgIDAuMDAwMDAwXSBQTTog
UmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWUw
MDAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAw
MGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAwMApbICAgIDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZTAxMDAwIC0gMDAwMDAwMDBmZmMwMDAwMApbICAg
IDAuMDAwMDAwXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZmYzAwMDAw
IC0gMDAwMDAwMDEwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBBbGxvY2F0aW5nIFBDSSByZXNvdXJj
ZXMgc3RhcnRpbmcgYXQgYWZhMDAwMDAgKGdhcDogYWZhMDAwMDA6NDg2MDAwMDApClsgICAgMC4w
MDAwMDBdIEJvb3RpbmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4KWyAgICAwLjAwMDAw
MF0gWGVuIHZlcnNpb246IDQuMi11bnN0YWJsZSAocHJlc2VydmUtQUQpClsgICAgMC4wMDAwMDBd
IHNldHVwX3BlcmNwdTogTlJfQ1BVUzoyNTYgbnJfY3B1bWFza19iaXRzOjI1NiBucl9jcHVfaWRz
OjggbnJfbm9kZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2Vz
L2NwdSBAZmZmZjg4MDA3ZmVkMzAwMCBzODI4MTYgcjgxOTIgZDIzNjgwIHUxMTQ2ODgKWyAgICA1
LjA0NTQwMV0gQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9uZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBp
bmcgb24uICBUb3RhbCBwYWdlczogMTUxMDA0NgpbICAgIDUuMDQ2OTg3XSBQb2xpY3kgem9uZTog
Tm9ybWFsClsgICAgNS4wNDc2MDJdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIGVh
cmx5cHJpbnRrPXhlbiByb290PS9kZXYvbWFwcGVyL3ZnX2hhbW1lcnN0b3JtLWx2X3Jvb3Qgcm8g
cmQubWQ9MCByZC5kbT0wIFNZU0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgcmhnYiBLRVlUQUJMRT11
ayByZC5sdWtzPTAgcmQubHZtLmx2PXZnX2hhbW1lcnN0b3JtL2x2X3Jvb3QgcmQubHZtLmx2PXZn
X2hhbW1lcnN0b3JtL2x2X3N3YXAgTEFORz1lbl9VUy5VVEYtOApbICAgIDUuMDUyNzQ4XSBQSUQg
aGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3NjggYnl0ZXMpCihYRU4pIGRv
bWFpbi5jOjY5MTpkMCBAcHZfZ3Vlc3RfY3I0X2ZpeHVwLXN0YXJ0OiBpZD0wIGh2X2NyNDogMDAw
MDI2NjAgLT4gZ3Vlc3RfY3I0OjAwMDAyNjYwCihYRU4pIGRvbWFpbi5jOjcwNzpkMCBAcHZfZ3Vl
c3RfY3I0X2ZpeHVwLWVuZDogaWQ9MCBodl9jcjQ6IDAwMDAyNjYwIGd1ZXN0X2NyNDogMDAwMDI2
NjAgcmV0dXJuOiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTE6ZDAgQHB2X2d1ZXN0X2NyNF9m
aXh1cC1zdGFydDogaWQ9MCBodl9jcjQ6IDAwMDAyNjYwIC0+IGd1ZXN0X2NyNDowMDAwMjY2MAoo
WEVOKSBkb21haW4uYzo3MDc6ZDAgQHB2X2d1ZXN0X2NyNF9maXh1cC1lbmQ6IGlkPTAgaHZfY3I0
OiAwMDAwMjY2MCBndWVzdF9jcjQ6IDAwMDAyNjYwIHJldHVybjogMDAwMDI2NjAKKFhFTikgZG9t
YWluLmM6NjkxOmQwIEBwdl9ndWVzdF9jcjRfZml4dXAtc3RhcnQ6IGlkPTAgaHZfY3I0OiAwMDAw
MjY2MCAtPiBndWVzdF9jcjQ6MDAwMDI2NjAKKFhFTikgZG9tYWluLmM6NzA3OmQwIEBwdl9ndWVz
dF9jcjRfZml4dXAtZW5kOiBpZD0wIGh2X2NyNDogMDAwMDI2NjAgZ3Vlc3RfY3I0OiAwMDAwMjY2
MCByZXR1cm46IDAwMDAyNjYwCihYRU4pIHRyYXBzLmM6MjI0MzpkMCBAWFNFVEJWOiBuZXdfeGZl
YXR1cmU6IDAwMDAwMDAwMDAwMDAwMDcKKFhFTikgdHJhcHMuYzoyMjQ2OmQwIEBYU0VUQlY6ICh2
LT5hcmNoLnB2X3ZjcHUuY3RybHJlZ1s0XSAmIFg4Nl9DUjRfT1NYU0FWRSk6IDAwMDAwMDAwMDAw
MDAwMDAKWyAgICA1LjA2Nzk0OV0gaW52YWxpZCBvcGNvZGU6IDAwMDAgWyMxXSBTTVAgClsgICAg
NS4wNjg3NTJdIENQVSAwIApbICAgIDUuMDY5MTE5XSBNb2R1bGVzIGxpbmtlZCBpbjoKWyAgICA1
LjA2OTgzMV0gClsgICAgNS4wNzAxMjJdIFBpZDogMCwgY29tbTogc3dhcHBlciBOb3QgdGFpbnRl
ZCAzLjMuMC04LmZjMTYueDg2XzY0ICMxIFRPU0hJQkEgVEVDUkEgUjg0MC9Qb3J0YWJsZSBQQwpb
ICAgIDUuMDcxOTA0XSBSSVA6IGUwMzA6WzxmZmZmZmZmZjgxMDFlOGE3Pl0gIFs8ZmZmZmZmZmY4
MTAxZThhNz5dIHhzdGF0ZV9lbmFibGUrMHgzNy8weDQwClsgICAgNS4wNzM4NjVdIFJTUDogZTAy
YjpmZmZmZmZmZjgxYzAxZTQ4ICBFRkxBR1M6IDAwMDEwMDQ2ClsgICAgNS4wNzUxMDRdIFJBWDog
MDAwMDAwMDAwMDAwMDAwNyBSQlg6IGZmZmZmZmZmODFjMDFlODQgUkNYOiAwMDAwMDAwMDAwMDAw
MDAwClsgICAgNS4wNzY1MDNdIFJEWDogMDAwMDAwMDAwMDAwMDAwMCBSU0k6IDAwMDAwMDAwMDAw
MDAwMDcgUkRJOiAwMDAwMDAwMDAwMDAyNjYwClsgICAgNS4wNzgyNTVdIFJCUDogZmZmZmZmZmY4
MWMwMWU0OCBSMDg6IGZmZmZmZmZmODFjMDFlODAgUjA5OiBmZmZmZmZmZjgxYzAxZTg0ClsgICAg
NS4wNzk3OTNdIFIxMDogMDAwMDAwMDBmZmZmZmZmZiBSMTE6IDAwMDAwMDAwZmZmZmZmZmYgUjEy
OiBmZmZmZmZmZjgxYzAxZTgwClsgICAgNS4wODExOTFdIFIxMzogZmZmZmZmZmY4MWMwMWU3YyBS
MTQ6IGZmZmZmZmZmODFjMDFlNzggUjE1OiBmZmZmODgwMDdmZWRmNmUwClsgICAgNS4wODI1OTVd
IEZTOiAgMDAwMDAwMDAwMDAwMDAwMCgwMDAwKSBHUzpmZmZmODgwMDdmZWQzMDAwKDAwMDApIGtu
bEdTOjAwMDAwMDAwMDAwMDAwMDAKWyAgICA1LjA4NDE3Nl0gQ1M6ICBlMDMzIERTOiAwMDAwIEVT
OiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYgpbICAgIDUuMDg1MzQxXSBDUjI6IDAwMDAwMDAw
MDAwMDAwMDAgQ1IzOiAwMDAwMDAwMDAxYzA1MDAwIENSNDogMDAwMDAwMDAwMDAwMjY2MApbICAg
IDUuMDg2NzQ0XSBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAwMDAwMDAwIERS
MjogMDAwMDAwMDAwMDAwMDAwMApbICAgIDUuMDg4MTQ0XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAg
RFI2OiAwMDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMApbICAgIDUuMDg5NTg3
XSBQcm9jZXNzIHN3YXBwZXIgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZmZjgxYzAwMDAwLCB0
YXNrIGZmZmZmZmZmODFjMGQwMjApClsgICAgNS4wOTEzMjZdIFN0YWNrOgpbICAgIDUuMDkxNzE2
XSAgZmZmZmZmZmY4MWMwMWVjOCBmZmZmZmZmZjgxY2Y4YjEzIGZmZmZmZmZmODEwMGE4ZmYgZmZm
ZmZmZmY4MTAwNDYzZApbICAgIDUuMDkzMTc5XSAgZmZmZjg4MDA3ZmVkZTE1MCBmZmZmODgwMDdm
ZWRlOTUwIDAwMDAwMjQwMDAwMDAwMDcgMDAwMDAwMDAwMDAwMDM0MApbICAgIDUuMDk0NzE1XSAg
ZmZmZjg4MDA3ZmVkZTE1MCAwMDAwMDAwMDAwMDAwMDA4IDAwMDAwMDAwMDAwMDAwMDQgMDAwMDAw
MDAwMDAwMDAwOApbICAgIDUuMDk2NTU2XSBDYWxsIFRyYWNlOgpbICAgIDUuMDk3MDUyXSAgWzxm
ZmZmZmZmZjgxY2Y4YjEzPl0geHN0YXRlX2VuYWJsZV9ib290X2NwdSsweGE5LzB4MjYzClsgICAg
NS4wOTgyODNdICBbPGZmZmZmZmZmODEwMGE4ZmY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9y
ZWxvYysweDQvMHg0ClsgICAgNS4wOTk5NThdICBbPGZmZmZmZmZmODEwMDQ2M2Q+XSA/IHhlbl9j
bHRzKzB4OGQvMHgxOTAKWyAgICA1LjEwMDk3NV0gIFs8ZmZmZmZmZmY4MTVkZTViOT5dIHhzYXZl
X2luaXQrMHgyNi8weDI4ClsgICAgNS4xMDE5ODFdICBbPGZmZmZmZmZmODE1ZTA4NmY+XSBjcHVf
aW5pdCsweDJmOC8weDMxNQpbICAgIDUuMTAyOTg4XSAgWzxmZmZmZmZmZjgxY2Y1MTc0Pl0gdHJh
cF9pbml0KzB4MTY5LzB4MWRlClsgICAgNS4xMDQwMTFdICBbPGZmZmZmZmZmODFjZjBhMTM+XSBz
dGFydF9rZXJuZWwrMHgxZDUvMHgzYzUKWyAgICA1LjEwNTM2NF0gIFs8ZmZmZmZmZmY4MWNmMDM0
Nj5dIHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzUKWyAgICA1LjEwNjY2Nl0g
IFs8ZmZmZmZmZmY4MWNmMmZlMj5dIHhlbl9zdGFydF9rZXJuZWwrMHg1NzQvMHg1N2IKWyAgICA1
LjEwNzgwNF0gQ29kZTogNDggODkgZTUgZmYgMTQgMjUgZDAgNzQgYzEgODEgNDggODkgYzcgNDgg
ODEgY2YgMDAgMDAgMDQgMDAgZmYgMTQgMjUgZDggNzQgYzEgODEgNDggOGIgMDUgYjIgN2YgZGQg
MDAgMzEgYzkgNDggODkgYzIgNDggYzEgZWEgMjAgPDBmPiAwMSBkMSA1ZCBjMyAwZiAxZiA0MCAw
MCA1NSA0OCA4OSBlNSA0MSA1NSA0MSA1NCA1MyA0OCA4MyBlYyAKWyAgICA1LjExMjM0NF0gUklQ
ICBbPGZmZmZmZmZmODEwMWU4YTc+XSB4c3RhdGVfZW5hYmxlKzB4MzcvMHg0MApbICAgIDUuMTEz
NDY5XSAgUlNQIDxmZmZmZmZmZjgxYzAxZTQ4PgpbICAgIDUuMTE0NDI1XSAtLS1bIGVuZCB0cmFj
ZSBhNzkxOWU3ZjE3YzBhNzI1IF0tLS0KWyAgICA1LjExNTQyNl0gS2VybmVsIHBhbmljIC0gbm90
IHN5bmNpbmc6IEF0dGVtcHRlZCB0byBraWxsIHRoZSBpZGxlIHRhc2shCihYRU4pIERvbWFpbiAw
IGNyYXNoZWQ6IHJlYm9vdGluZyBtYWNoaW5lIGluIDUgc2Vjb25kcy4KKFhFTikgUmVzZXR0aW5n
IHdpdGggQUNQSSBNRU1PUlkgb3IgSS9PIFJFU0VUX1JFRy4K

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_5E615268CEC26C4E920B9D9911A2307C0345ECC5B693EXCCR03camp_--


From xen-devel-bounces@lists.xen.org Tue Apr 10 12:33:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHaGB-0005zm-Bd; Tue, 10 Apr 2012 12:33:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1SHaG9-0005zh-Gy
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 12:33:21 +0000
Received: from [85.158.143.35:49034] by server-1.bemta-4.messagelabs.com id
	C9/27-20925-098248F4; Tue, 10 Apr 2012 12:33:20 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334061199!11764859!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2528 invoked from network); 10 Apr 2012 12:33:19 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-10.tower-21.messagelabs.com with SMTP;
	10 Apr 2012 12:33:19 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 69CBC1AC21C;
	Tue, 10 Apr 2012 14:33:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id yliBqeQ4cx9M; Tue, 10 Apr 2012 14:33:17 +0200 (CEST)
Received: from [10.0.0.1] (p5DCB79E6.dip.t-dialin.net [93.203.121.230])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 10 Apr 2012 14:33:17 +0200 (CEST)
Message-ID: <4F84288E.1070407@hfp.de>
Date: Tue, 10 Apr 2012 14:33:18 +0200
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Philippe.Simonet@swisscom.com
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
In-Reply-To: <FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
Cc: xen-devel@lists.xensource.com, joy@entuzijast.net
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have the same problem. Do you use ntpd? Which version? I suspect some 
link between the problem and ntpd.

Andreas

On 05.01.2012 10:39, Philippe.Simonet@swisscom.com wrote:
> Hi
>
> I have the same problem with 4 machines (hp dl385, AMD), the problem appears one time per machine and per month ...
> No chance to re-produce it faster. On some other machine with another AMD processor, I never had this problem. Olivier Hanesse
> reported the problem on some Intel CPU and not on other processor.
>
> I'm using debian squeeze, with
>
> xen-hypervisor-4.0-amd64                4.0.1-4
> linux-image-2.6.32-5-xen-amd64          2.6.32-38 (dom0)
>
> that last changes that I have done is to add cpuidle=0 to hypervisor command line. stable since 3-4 weeks (...)
>
> I have e test system that runs 20 paravirt. domus, with wheezy, with same problematic HW, with
> xen-hypervisor-4.1-amd64                4.1.2-2
> linux-image-3.1.0-1-amd64               3.1.6-1 (dom0)
> and this system never had the TSC jump problem. but test system are test system ....
>
> I would be happy if you could reproduce the problem faster a me, so testing new xen / dom0 version could be
> easier ...
>
> thanks and regards
>
> Philippe
>
>
>
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Josip Rodin
>> Sent: Wednesday, January 04, 2012 6:24 PM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
>> wrapped 10 or more times.
>>
>> Hi,
>>
>> Sometimes, seemingly randomly, long-running Xen domains, using
>> clocksource xen, have their clock shift by ~3000 or ~36000 seconds, often
>> with the dom0 complaining about clocksource tsc. The number changes if the
>> hypervisor is explicitly told to use clocksource=pit, but it still happens. It
>> doesn't seem to be particularly hardware-specific.
>>
>> See also http://bugs.debian.org/599161
>>
>> I see from the archives that others have reported this problem here in
>> February last year, but I couldn't find a resolution. Can anyone help?
>>
>> (Please Cc: responses, I'm not subscribed.)
>>
>> --
>>       2. That which causes joy or happiness.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 12:33:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 12:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHaGB-0005zm-Bd; Tue, 10 Apr 2012 12:33:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1SHaG9-0005zh-Gy
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 12:33:21 +0000
Received: from [85.158.143.35:49034] by server-1.bemta-4.messagelabs.com id
	C9/27-20925-098248F4; Tue, 10 Apr 2012 12:33:20 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334061199!11764859!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2528 invoked from network); 10 Apr 2012 12:33:19 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-10.tower-21.messagelabs.com with SMTP;
	10 Apr 2012 12:33:19 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 69CBC1AC21C;
	Tue, 10 Apr 2012 14:33:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id yliBqeQ4cx9M; Tue, 10 Apr 2012 14:33:17 +0200 (CEST)
Received: from [10.0.0.1] (p5DCB79E6.dip.t-dialin.net [93.203.121.230])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 10 Apr 2012 14:33:17 +0200 (CEST)
Message-ID: <4F84288E.1070407@hfp.de>
Date: Tue, 10 Apr 2012 14:33:18 +0200
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Philippe.Simonet@swisscom.com
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
In-Reply-To: <FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
Cc: xen-devel@lists.xensource.com, joy@entuzijast.net
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have the same problem. Do you use ntpd? Which version? I suspect some 
link between the problem and ntpd.

Andreas

On 05.01.2012 10:39, Philippe.Simonet@swisscom.com wrote:
> Hi
>
> I have the same problem with 4 machines (hp dl385, AMD), the problem appears one time per machine and per month ...
> No chance to re-produce it faster. On some other machine with another AMD processor, I never had this problem. Olivier Hanesse
> reported the problem on some Intel CPU and not on other processor.
>
> I'm using debian squeeze, with
>
> xen-hypervisor-4.0-amd64                4.0.1-4
> linux-image-2.6.32-5-xen-amd64          2.6.32-38 (dom0)
>
> that last changes that I have done is to add cpuidle=0 to hypervisor command line. stable since 3-4 weeks (...)
>
> I have e test system that runs 20 paravirt. domus, with wheezy, with same problematic HW, with
> xen-hypervisor-4.1-amd64                4.1.2-2
> linux-image-3.1.0-1-amd64               3.1.6-1 (dom0)
> and this system never had the TSC jump problem. but test system are test system ....
>
> I would be happy if you could reproduce the problem faster a me, so testing new xen / dom0 version could be
> easier ...
>
> thanks and regards
>
> Philippe
>
>
>
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Josip Rodin
>> Sent: Wednesday, January 04, 2012 6:24 PM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
>> wrapped 10 or more times.
>>
>> Hi,
>>
>> Sometimes, seemingly randomly, long-running Xen domains, using
>> clocksource xen, have their clock shift by ~3000 or ~36000 seconds, often
>> with the dom0 complaining about clocksource tsc. The number changes if the
>> hypervisor is explicitly told to use clocksource=pit, but it still happens. It
>> doesn't seem to be particularly hardware-specific.
>>
>> See also http://bugs.debian.org/599161
>>
>> I see from the archives that others have reported this problem here in
>> February last year, but I couldn't find a resolution. Can anyone help?
>>
>> (Please Cc: responses, I'm not subscribed.)
>>
>> --
>>       2. That which causes joy or happiness.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 13:14:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 13:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHatO-0006ht-By; Tue, 10 Apr 2012 13:13:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1SHatN-0006ho-Ka
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 13:13:53 +0000
X-Env-Sender: joy@entuzijast.net
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334063113!12380064!1
X-Originating-IP: [161.53.160.90]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26555 invoked from network); 10 Apr 2012 13:05:14 -0000
Received: from orion.carnet.hr (HELO orion.carnet.hr) (161.53.160.90)
	by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 13:05:14 -0000
Received: from joy by orion.carnet.hr with local (Exim 4.72)
	(envelope-from <joy@entuzijast.net>)
	id 1SHaky-0002B6-5B; Tue, 10 Apr 2012 15:05:12 +0200
Date: Tue, 10 Apr 2012 15:05:12 +0200
From: Josip Rodin <joy@entuzijast.net>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Message-ID: <20120410130512.GA3598@entuzijast.net>
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
	<4F84288E.1070407@hfp.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F84288E.1070407@hfp.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 02:33:18PM +0200, Andreas Kinzler wrote:
> I have the same problem. Do you use ntpd? Which version? I suspect
> some link between the problem and ntpd.

But ntpd is still a userland program, shouldn't the kernel exert the
ultimate control over who gets to screw with the system's clock source?

In any case, I did a quick grep of ntpd sources and found references to
RDTSC only in the Windows port, so the link doesn't seem obvious.

-- 
     2. That which causes joy or happiness.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 13:14:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 13:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHatO-0006ht-By; Tue, 10 Apr 2012 13:13:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1SHatN-0006ho-Ka
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 13:13:53 +0000
X-Env-Sender: joy@entuzijast.net
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334063113!12380064!1
X-Originating-IP: [161.53.160.90]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26555 invoked from network); 10 Apr 2012 13:05:14 -0000
Received: from orion.carnet.hr (HELO orion.carnet.hr) (161.53.160.90)
	by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 13:05:14 -0000
Received: from joy by orion.carnet.hr with local (Exim 4.72)
	(envelope-from <joy@entuzijast.net>)
	id 1SHaky-0002B6-5B; Tue, 10 Apr 2012 15:05:12 +0200
Date: Tue, 10 Apr 2012 15:05:12 +0200
From: Josip Rodin <joy@entuzijast.net>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Message-ID: <20120410130512.GA3598@entuzijast.net>
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
	<4F84288E.1070407@hfp.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F84288E.1070407@hfp.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 02:33:18PM +0200, Andreas Kinzler wrote:
> I have the same problem. Do you use ntpd? Which version? I suspect
> some link between the problem and ntpd.

But ntpd is still a userland program, shouldn't the kernel exert the
ultimate control over who gets to screw with the system's clock source?

In any case, I did a quick grep of ntpd sources and found references to
RDTSC only in the Windows port, so the link doesn't seem obvious.

-- 
     2. That which causes joy or happiness.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHbbl-0007XY-7L; Tue, 10 Apr 2012 13:59:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1SHbbk-0007XS-3m
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 13:59:44 +0000
Received: from [85.158.143.99:60124] by server-1.bemta-4.messagelabs.com id
	6B/CF-20925-FCC348F4; Tue, 10 Apr 2012 13:59:43 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334066382!13266795!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31904 invoked from network); 10 Apr 2012 13:59:42 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-8.tower-216.messagelabs.com with SMTP;
	10 Apr 2012 13:59:42 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id DFE241A2E80;
	Tue, 10 Apr 2012 15:59:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id BeGQm61C5efS; Tue, 10 Apr 2012 15:59:41 +0200 (CEST)
Received: from [10.0.0.1] (p5DCB79E6.dip.t-dialin.net [93.203.121.230])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 10 Apr 2012 15:59:41 +0200 (CEST)
Message-ID: <4F843CCE.7010307@hfp.de>
Date: Tue, 10 Apr 2012 15:59:42 +0200
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Josip Rodin <joy@entuzijast.net>
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
	<4F84288E.1070407@hfp.de> <20120410130512.GA3598@entuzijast.net>
In-Reply-To: <20120410130512.GA3598@entuzijast.net>
Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Tue, Apr 10, 2012 at 02:33:18PM +0200, Andreas Kinzler wrote:
>> I have the same problem. Do you use ntpd? Which version? I suspect
>> some link between the problem and ntpd.
> But ntpd is still a userland program, shouldn't the kernel exert the
> ultimate control over who gets to screw with the system's clock source?
> In any case, I did a quick grep of ntpd sources and found references to
> RDTSC only in the Windows port, so the link doesn't seem obvious.

Right, there is no obvious link (but which hard to reproduce bug is 
obvious?) but see 
"http://lists.xen.org/archives/html/xen-devel/2011-10/msg01269.html". 
There seems to be some connection.

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHbbl-0007XY-7L; Tue, 10 Apr 2012 13:59:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1SHbbk-0007XS-3m
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 13:59:44 +0000
Received: from [85.158.143.99:60124] by server-1.bemta-4.messagelabs.com id
	6B/CF-20925-FCC348F4; Tue, 10 Apr 2012 13:59:43 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334066382!13266795!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31904 invoked from network); 10 Apr 2012 13:59:42 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-8.tower-216.messagelabs.com with SMTP;
	10 Apr 2012 13:59:42 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id DFE241A2E80;
	Tue, 10 Apr 2012 15:59:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id BeGQm61C5efS; Tue, 10 Apr 2012 15:59:41 +0200 (CEST)
Received: from [10.0.0.1] (p5DCB79E6.dip.t-dialin.net [93.203.121.230])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 10 Apr 2012 15:59:41 +0200 (CEST)
Message-ID: <4F843CCE.7010307@hfp.de>
Date: Tue, 10 Apr 2012 15:59:42 +0200
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Josip Rodin <joy@entuzijast.net>
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
	<4F84288E.1070407@hfp.de> <20120410130512.GA3598@entuzijast.net>
In-Reply-To: <20120410130512.GA3598@entuzijast.net>
Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Tue, Apr 10, 2012 at 02:33:18PM +0200, Andreas Kinzler wrote:
>> I have the same problem. Do you use ntpd? Which version? I suspect
>> some link between the problem and ntpd.
> But ntpd is still a userland program, shouldn't the kernel exert the
> ultimate control over who gets to screw with the system's clock source?
> In any case, I did a quick grep of ntpd sources and found references to
> RDTSC only in the Windows port, so the link doesn't seem obvious.

Right, there is no obvious link (but which hard to reproduce bug is 
obvious?) but see 
"http://lists.xen.org/archives/html/xen-devel/2011-10/msg01269.html". 
There seems to be some connection.

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHbjk-0007zR-UK; Tue, 10 Apr 2012 14:08:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1SHbjj-0007zJ-Qc
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 14:07:59 +0000
Received: from [193.109.254.147:39714] by server-11.bemta-14.messagelabs.com
	id 6B/80-05858-FBE348F4; Tue, 10 Apr 2012 14:07:59 +0000
X-Env-Sender: joy@entuzijast.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334066878!3946271!1
X-Originating-IP: [161.53.160.90]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 501 invoked from network); 10 Apr 2012 14:07:58 -0000
Received: from orion.carnet.hr (HELO orion.carnet.hr) (161.53.160.90)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 14:07:58 -0000
Received: from joy by orion.carnet.hr with local (Exim 4.72)
	(envelope-from <joy@entuzijast.net>)
	id 1SHbjh-0006hh-AT; Tue, 10 Apr 2012 16:07:57 +0200
Date: Tue, 10 Apr 2012 16:07:57 +0200
From: Josip Rodin <joy@entuzijast.net>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Message-ID: <20120410140757.GA24893@entuzijast.net>
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
	<4F84288E.1070407@hfp.de> <20120410130512.GA3598@entuzijast.net>
	<4F843CCE.7010307@hfp.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F843CCE.7010307@hfp.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:59:42PM +0200, Andreas Kinzler wrote:
> >On Tue, Apr 10, 2012 at 02:33:18PM +0200, Andreas Kinzler wrote:
> >>I have the same problem. Do you use ntpd? Which version? I suspect
> >>some link between the problem and ntpd.
> >But ntpd is still a userland program, shouldn't the kernel exert the
> >ultimate control over who gets to screw with the system's clock source?
> >In any case, I did a quick grep of ntpd sources and found references to
> >RDTSC only in the Windows port, so the link doesn't seem obvious.
> 
> Right, there is no obvious link (but which hard to reproduce bug is
> obvious?) but see
> "http://lists.xen.org/archives/html/xen-devel/2011-10/msg01269.html".
> There seems to be some connection.

>From that (garbled) log, I don't see it - you didn't even post the matching
kernel log message with timestamp, so it's impossible to see if and when
it coincided when the ntpd messages.

Over here we're running ntpd, obviously, in dom0 and in domU, but the only
observed interaction of this problem with ntpd is that they become useless
with this kind of a major drift.

-- 
     2. That which causes joy or happiness.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHbjk-0007zR-UK; Tue, 10 Apr 2012 14:08:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1SHbjj-0007zJ-Qc
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 14:07:59 +0000
Received: from [193.109.254.147:39714] by server-11.bemta-14.messagelabs.com
	id 6B/80-05858-FBE348F4; Tue, 10 Apr 2012 14:07:59 +0000
X-Env-Sender: joy@entuzijast.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334066878!3946271!1
X-Originating-IP: [161.53.160.90]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 501 invoked from network); 10 Apr 2012 14:07:58 -0000
Received: from orion.carnet.hr (HELO orion.carnet.hr) (161.53.160.90)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Apr 2012 14:07:58 -0000
Received: from joy by orion.carnet.hr with local (Exim 4.72)
	(envelope-from <joy@entuzijast.net>)
	id 1SHbjh-0006hh-AT; Tue, 10 Apr 2012 16:07:57 +0200
Date: Tue, 10 Apr 2012 16:07:57 +0200
From: Josip Rodin <joy@entuzijast.net>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Message-ID: <20120410140757.GA24893@entuzijast.net>
References: <20120104172343.GA30630@entuzijast.net>
	<FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
	<4F84288E.1070407@hfp.de> <20120410130512.GA3598@entuzijast.net>
	<4F843CCE.7010307@hfp.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F843CCE.7010307@hfp.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:59:42PM +0200, Andreas Kinzler wrote:
> >On Tue, Apr 10, 2012 at 02:33:18PM +0200, Andreas Kinzler wrote:
> >>I have the same problem. Do you use ntpd? Which version? I suspect
> >>some link between the problem and ntpd.
> >But ntpd is still a userland program, shouldn't the kernel exert the
> >ultimate control over who gets to screw with the system's clock source?
> >In any case, I did a quick grep of ntpd sources and found references to
> >RDTSC only in the Windows port, so the link doesn't seem obvious.
> 
> Right, there is no obvious link (but which hard to reproduce bug is
> obvious?) but see
> "http://lists.xen.org/archives/html/xen-devel/2011-10/msg01269.html".
> There seems to be some connection.

>From that (garbled) log, I don't see it - you didn't even post the matching
kernel log message with timestamp, so it's impossible to see if and when
it coincided when the ntpd messages.

Over here we're running ntpd, obviously, in dom0 and in domU, but the only
observed interaction of this problem with ntpd is that they become useless
with this kind of a major drift.

-- 
     2. That which causes joy or happiness.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:22:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHbx6-0008NG-BQ; Tue, 10 Apr 2012 14:21:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHbx4-0008N8-Vk
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 14:21:47 +0000
Received: from [85.158.139.83:17438] by server-12.bemta-5.messagelabs.com id
	A2/69-05587-AF1448F4; Tue, 10 Apr 2012 14:21:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334067704!22646092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3043 invoked from network); 10 Apr 2012 14:21:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:21:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11858218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 14:21:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 15:21:43 +0100
Message-ID: <1334067702.5394.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 10 Apr 2012 15:21:42 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > I see. So you need to be able to find the individual tables so that
> > smbios_type_<N>_init can check for an overriding table <N> in the
> > passed-through tables, it seems reasonable to try and avoid needing to
> > parse a big lump of tables each time to see if the one you are
> > interested in is there.
> > 
> > I think this can work by having .../smbios/<N>/{address,etc} in
> > XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> > smbios_type_vendor_oem_init, which I think could easily just be a single
> > lump?
> > 
> > I think you don't need the same thing for the ACPI side since there you
> > just provide secondary tables?
> 
> There could be quite a few SMBIOS tables being passed in. On the order
> of 20 - 30 of them and thet are pretty small. It seems a bit odd to
> break it up like this for lots of little chunks. There could be more
> than one ACPI table also (multiple SSDTs and/or other static tables).
> Also the OEM SMBIOS tables are all discrete and they could not go in
> as a single lump.

I'm not sure if there are arguments here both for and against having a
single smbios blob vs multiple?

> > At the libxc layer you could have "struct xc_hvm_module *smbios". I
> > expect in the simple case this would just point into an array on the
> > callers stack but a caller could also do something more dynamic if they
> > wanted to. If you think it would be useful then a linked-list thing here
> > would also work.
> 
> Again assuming the xenstore approach, I guess it would probably have
> to be a linked list because there could be a fair number of them
> (mainly SMBIOS).

This is userspace so an array of, say, 100 items isn't really much of a
problem. But if a link list works better for your use cases then that's
fine.

> > 
> > > Given all that, the only real issue I see at the moment is how to deal
> > > with multiple entries within a blob that don't readily specify their
> > > own lengths. I am in favor of a delimiting struct with possibly a
> > > terminating form (like a flag). Then all we put in xenstore is the gpe
> > > for each type.
> > >
> > > Finally I wanted to bring up again the idea of another helper
> > > component (lib maybe) that can be used to build and glom (I like that
> > > word) modules. Note that in many cases the passed in firmware is going
> > > to be pulled from the host firmware. I already have bunches of codes
> > > that do that. Perhaps I should start an RFC thread for that as a
> > > separate task? Thoughts on this?
> > 
> > You mean some sort of libacpi / libsmbios type things, helper routines
> > for parsing and manipulating tables etc? (such a thing doesn't already
> > exist somewhere?)
> > 
> > I suspect your usecases are the ones which would make most extensive use
> > of such a thing but I also assume that at least some of it would be
> > useful to any caller which was passing in these tables. If you want to
> > maintain it within the Xen tree then that works for me.
> 
> Yea along those lines. I was thinking of maybe a libxenhvm that had
> utility routines for collecting the system firmware information that
> one wanted to pass to a guest. It could also provide an API that
> wrapped up the setting of the firmware values that hvmloader consumes
> including the bits that are on the shared info page you want to get
> rid of. The usefulness of this library is diminished if we go the all
> xenstore route above so I am going to shelf this until that is
> settled.

OK.

> Oh and yea, there are tools to get this information
> (acpidump/dmidecode) but they unfortunately do not come in library
> form or necessarily give you the desired output. And in newer kernels
> ACPI/DMI is accessible through sysfs.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:22:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHbx6-0008NG-BQ; Tue, 10 Apr 2012 14:21:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHbx4-0008N8-Vk
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 14:21:47 +0000
Received: from [85.158.139.83:17438] by server-12.bemta-5.messagelabs.com id
	A2/69-05587-AF1448F4; Tue, 10 Apr 2012 14:21:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334067704!22646092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3043 invoked from network); 10 Apr 2012 14:21:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:21:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11858218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 14:21:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 15:21:43 +0100
Message-ID: <1334067702.5394.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 10 Apr 2012 15:21:42 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > I see. So you need to be able to find the individual tables so that
> > smbios_type_<N>_init can check for an overriding table <N> in the
> > passed-through tables, it seems reasonable to try and avoid needing to
> > parse a big lump of tables each time to see if the one you are
> > interested in is there.
> > 
> > I think this can work by having .../smbios/<N>/{address,etc} in
> > XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> > smbios_type_vendor_oem_init, which I think could easily just be a single
> > lump?
> > 
> > I think you don't need the same thing for the ACPI side since there you
> > just provide secondary tables?
> 
> There could be quite a few SMBIOS tables being passed in. On the order
> of 20 - 30 of them and thet are pretty small. It seems a bit odd to
> break it up like this for lots of little chunks. There could be more
> than one ACPI table also (multiple SSDTs and/or other static tables).
> Also the OEM SMBIOS tables are all discrete and they could not go in
> as a single lump.

I'm not sure if there are arguments here both for and against having a
single smbios blob vs multiple?

> > At the libxc layer you could have "struct xc_hvm_module *smbios". I
> > expect in the simple case this would just point into an array on the
> > callers stack but a caller could also do something more dynamic if they
> > wanted to. If you think it would be useful then a linked-list thing here
> > would also work.
> 
> Again assuming the xenstore approach, I guess it would probably have
> to be a linked list because there could be a fair number of them
> (mainly SMBIOS).

This is userspace so an array of, say, 100 items isn't really much of a
problem. But if a link list works better for your use cases then that's
fine.

> > 
> > > Given all that, the only real issue I see at the moment is how to deal
> > > with multiple entries within a blob that don't readily specify their
> > > own lengths. I am in favor of a delimiting struct with possibly a
> > > terminating form (like a flag). Then all we put in xenstore is the gpe
> > > for each type.
> > >
> > > Finally I wanted to bring up again the idea of another helper
> > > component (lib maybe) that can be used to build and glom (I like that
> > > word) modules. Note that in many cases the passed in firmware is going
> > > to be pulled from the host firmware. I already have bunches of codes
> > > that do that. Perhaps I should start an RFC thread for that as a
> > > separate task? Thoughts on this?
> > 
> > You mean some sort of libacpi / libsmbios type things, helper routines
> > for parsing and manipulating tables etc? (such a thing doesn't already
> > exist somewhere?)
> > 
> > I suspect your usecases are the ones which would make most extensive use
> > of such a thing but I also assume that at least some of it would be
> > useful to any caller which was passing in these tables. If you want to
> > maintain it within the Xen tree then that works for me.
> 
> Yea along those lines. I was thinking of maybe a libxenhvm that had
> utility routines for collecting the system firmware information that
> one wanted to pass to a guest. It could also provide an API that
> wrapped up the setting of the firmware values that hvmloader consumes
> including the bits that are on the shared info page you want to get
> rid of. The usefulness of this library is diminished if we go the all
> xenstore route above so I am going to shelf this until that is
> settled.

OK.

> Oh and yea, there are tools to get this information
> (acpidump/dmidecode) but they unfortunately do not come in library
> form or necessarily give you the desired output. And in newer kernels
> ACPI/DMI is accessible through sysfs.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:26:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc1O-0000E1-8n; Tue, 10 Apr 2012 14:26:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc1L-0000DR-SJ
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:26:12 +0000
Received: from [85.158.138.51:44396] by server-9.bemta-3.messagelabs.com id
	9D/9D-26691-303448F4; Tue, 10 Apr 2012 14:26:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334067968!21488044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1011 invoked from network); 10 Apr 2012 14:26:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11858318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 14:26:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 15:26:07 +0100
Message-ID: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Tue, 10 Apr 2012 15:26:05 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Bart Van Assche <bvanassche@acm.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, David VomLehn <dvomlehn@cisco.com>,
	xen-devel <xen-devel@lists.xen.org>, David Miller <davem@davemloft.net>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I think this is v4, but I've sort of lost count, sorry that it's taken
me so long to get back to this stuff.

The following series makes use of the skb fragment API (which is in 3.2
+) to add a per-paged-fragment destructor callback. This can be used by
creators of skbs who are interested in the lifecycle of the pages
included in that skb after they have handed it off to the network stack.

The mail at [0] contains some more background and rationale but
basically the completed series will allow entities which inject pages
into the networking stack to receive a notification when the stack has
really finished with those pages (i.e. including retransmissions,
clones, pull-ups etc) and not just when the original skb is finished
with, which is beneficial to many subsystems which wish to inject pages
into the network stack without giving up full ownership of those page's
lifecycle. It implements something broadly along the lines of what was
described in [1].

I have also included a patch to the RPC subsystem which uses this API to
fix the bug which I describe at [2].

I've also had some interest from David VemLehn and Bart Van Assche
regarding using this functionality in the context of vmsplice and iSCSI
targets respectively (I think).

Changes since last time:

      * Added skb_orphan_frags API for the use of recipients of SKBs who
        may hold onto the SKB for a long time (this is analogous to
        skb_orphan). This was pointed out by Michael. The TUN driver is
        currently the only user.
              * I can't for the life of me get anything to actually hit
                this code path. I've been trying with an NFS server
                running in a Xen HVM domain with emulated (e.g. tap)
                networking and a client in domain 0, using the NFS fix
                in this series which generates SKBs with destructors
                set, so far -- nothing. I suspect that lack of TSO/GSO
                etc on the TAP interface is causing the frags to be
                copied to normal pages during skb_segment().
      * Various fixups related to the change of alignment/padding in
        shinfo, in particular to build_skb as pointed out by Eric.
      * Tweaked ordering of shinfo members to ensure that all hotpath
        variables up to and including the first frag fit within (and are
        aligned to) a single 64 byte cache line. (Eric again)

I ran a monothread UDP benchmark (similar to that described by Eric in
e52fcb2462ac) and don't see any difference in pps throughput, it was
~810,000 pps both before and after.

Cheers,
Ian.

[0] http://marc.info/?l=linux-netdev&m=131072801125521&w=2
[1] http://marc.info/?l=linux-netdev&m=130925719513084&w=2
[2] http://marc.info/?l=linux-nfs&m=122424132729720&w=2






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:26:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc1O-0000E1-8n; Tue, 10 Apr 2012 14:26:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc1L-0000DR-SJ
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:26:12 +0000
Received: from [85.158.138.51:44396] by server-9.bemta-3.messagelabs.com id
	9D/9D-26691-303448F4; Tue, 10 Apr 2012 14:26:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334067968!21488044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1011 invoked from network); 10 Apr 2012 14:26:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11858318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 14:26:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 15:26:07 +0100
Message-ID: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Tue, 10 Apr 2012 15:26:05 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Bart Van Assche <bvanassche@acm.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, David VomLehn <dvomlehn@cisco.com>,
	xen-devel <xen-devel@lists.xen.org>, David Miller <davem@davemloft.net>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I think this is v4, but I've sort of lost count, sorry that it's taken
me so long to get back to this stuff.

The following series makes use of the skb fragment API (which is in 3.2
+) to add a per-paged-fragment destructor callback. This can be used by
creators of skbs who are interested in the lifecycle of the pages
included in that skb after they have handed it off to the network stack.

The mail at [0] contains some more background and rationale but
basically the completed series will allow entities which inject pages
into the networking stack to receive a notification when the stack has
really finished with those pages (i.e. including retransmissions,
clones, pull-ups etc) and not just when the original skb is finished
with, which is beneficial to many subsystems which wish to inject pages
into the network stack without giving up full ownership of those page's
lifecycle. It implements something broadly along the lines of what was
described in [1].

I have also included a patch to the RPC subsystem which uses this API to
fix the bug which I describe at [2].

I've also had some interest from David VemLehn and Bart Van Assche
regarding using this functionality in the context of vmsplice and iSCSI
targets respectively (I think).

Changes since last time:

      * Added skb_orphan_frags API for the use of recipients of SKBs who
        may hold onto the SKB for a long time (this is analogous to
        skb_orphan). This was pointed out by Michael. The TUN driver is
        currently the only user.
              * I can't for the life of me get anything to actually hit
                this code path. I've been trying with an NFS server
                running in a Xen HVM domain with emulated (e.g. tap)
                networking and a client in domain 0, using the NFS fix
                in this series which generates SKBs with destructors
                set, so far -- nothing. I suspect that lack of TSO/GSO
                etc on the TAP interface is causing the frags to be
                copied to normal pages during skb_segment().
      * Various fixups related to the change of alignment/padding in
        shinfo, in particular to build_skb as pointed out by Eric.
      * Tweaked ordering of shinfo members to ensure that all hotpath
        variables up to and including the first frag fit within (and are
        aligned to) a single 64 byte cache line. (Eric again)

I ran a monothread UDP benchmark (similar to that described by Eric in
e52fcb2462ac) and don't see any difference in pps throughput, it was
~810,000 pps both before and after.

Cheers,
Ian.

[0] http://marc.info/?l=linux-netdev&m=131072801125521&w=2
[1] http://marc.info/?l=linux-netdev&m=130925719513084&w=2
[2] http://marc.info/?l=linux-nfs&m=122424132729720&w=2






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:31:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:31:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc6h-0000gx-1W; Tue, 10 Apr 2012 14:31:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc6f-0000gq-Vd
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:31:42 +0000
Received: from [85.158.143.35:60862] by server-2.bemta-4.messagelabs.com id
	6D/AD-17550-D44448F4; Tue, 10 Apr 2012 14:31:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334068297!11789417!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ1Nzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23162 invoked from network); 10 Apr 2012 14:31:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24024974"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-2M;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:17 +0100
Message-ID: <1334067984-7706-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>, Divy Le Ray <divy@chelsio.com>
Subject: [Xen-devel] [PATCH 03/10] chelsio: use SKB_WITH_OVERHEAD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Divy Le Ray <divy@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb/sge.c  |    3 +--
 drivers/net/ethernet/chelsio/cxgb3/sge.c |    6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb/sge.c b/drivers/net/ethernet/chelsio/cxgb/sge.c
index 47a8435..52373db 100644
--- a/drivers/net/ethernet/chelsio/cxgb/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb/sge.c
@@ -599,8 +599,7 @@ static int alloc_rx_resources(struct sge *sge, struct sge_params *p)
 		sizeof(struct cpl_rx_data) +
 		sge->freelQ[!sge->jumbo_fl].dma_offset;
 
-		size = (16 * 1024) -
-		    SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	size = SKB_WITH_OVERHEAD(16 * 1024);
 
 	sge->freelQ[sge->jumbo_fl].rx_buffer_size = size;
 
diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index cfb60e1..b804470 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -3043,7 +3043,7 @@ int t3_sge_alloc_qset(struct adapter *adapter, unsigned int id, int nports,
 	q->fl[1].buf_size = FL1_PG_CHUNK_SIZE;
 #else
 	q->fl[1].buf_size = is_offload(adapter) ?
-		(16 * 1024) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) :
+		SKB_WITH_OVERHEAD(16 * 1024) :
 		MAX_FRAME_SIZE + 2 + sizeof(struct cpl_rx_pkt);
 #endif
 
@@ -3282,8 +3282,8 @@ void t3_sge_prep(struct adapter *adap, struct sge_params *p)
 {
 	int i;
 
-	p->max_pkt_size = (16 * 1024) - sizeof(struct cpl_rx_data) -
-	    SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	p->max_pkt_size =
+		SKB_WITH_OVERHEAD((16*1024) - sizeof(struct cpl_rx_data));
 
 	for (i = 0; i < SGE_QSETS; ++i) {
 		struct qset_params *q = p->qset + i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:31:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:31:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc6h-0000gx-1W; Tue, 10 Apr 2012 14:31:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc6f-0000gq-Vd
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:31:42 +0000
Received: from [85.158.143.35:60862] by server-2.bemta-4.messagelabs.com id
	6D/AD-17550-D44448F4; Tue, 10 Apr 2012 14:31:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334068297!11789417!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ1Nzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23162 invoked from network); 10 Apr 2012 14:31:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24024974"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-2M;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:17 +0100
Message-ID: <1334067984-7706-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>, Divy Le Ray <divy@chelsio.com>
Subject: [Xen-devel] [PATCH 03/10] chelsio: use SKB_WITH_OVERHEAD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Divy Le Ray <divy@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb/sge.c  |    3 +--
 drivers/net/ethernet/chelsio/cxgb3/sge.c |    6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb/sge.c b/drivers/net/ethernet/chelsio/cxgb/sge.c
index 47a8435..52373db 100644
--- a/drivers/net/ethernet/chelsio/cxgb/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb/sge.c
@@ -599,8 +599,7 @@ static int alloc_rx_resources(struct sge *sge, struct sge_params *p)
 		sizeof(struct cpl_rx_data) +
 		sge->freelQ[!sge->jumbo_fl].dma_offset;
 
-		size = (16 * 1024) -
-		    SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	size = SKB_WITH_OVERHEAD(16 * 1024);
 
 	sge->freelQ[sge->jumbo_fl].rx_buffer_size = size;
 
diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index cfb60e1..b804470 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -3043,7 +3043,7 @@ int t3_sge_alloc_qset(struct adapter *adapter, unsigned int id, int nports,
 	q->fl[1].buf_size = FL1_PG_CHUNK_SIZE;
 #else
 	q->fl[1].buf_size = is_offload(adapter) ?
-		(16 * 1024) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) :
+		SKB_WITH_OVERHEAD(16 * 1024) :
 		MAX_FRAME_SIZE + 2 + sizeof(struct cpl_rx_pkt);
 #endif
 
@@ -3282,8 +3282,8 @@ void t3_sge_prep(struct adapter *adap, struct sge_params *p)
 {
 	int i;
 
-	p->max_pkt_size = (16 * 1024) - sizeof(struct cpl_rx_data) -
-	    SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	p->max_pkt_size =
+		SKB_WITH_OVERHEAD((16*1024) - sizeof(struct cpl_rx_data));
 
 	for (i = 0; i < SGE_QSETS; ++i) {
 		struct qset_params *q = p->qset + i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc6j-0000hV-In; Tue, 10 Apr 2012 14:31:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc6h-0000gp-Tu
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:31:44 +0000
Received: from [85.158.143.35:60771] by server-3.bemta-4.messagelabs.com id
	A9/00-05853-C44448F4; Tue, 10 Apr 2012 14:31:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334068297!11789417!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ1Nzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23102 invoked from network); 10 Apr 2012 14:31:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:31:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24024973"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:36 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:36 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-F6;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:24 +0100
Message-ID: <1334067984-7706-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: linux-nfs@vger.kernel.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Neil Brown <neilb@suse.de>, xen-devel@lists.xen.org,
	"J. Bruce Fields" <bfields@fieldses.org>,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 10/10] sunrpc: use SKB fragment destructors to
	delay completion until page is released by network stack.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This prevents an issue where an ACK is delayed, a retransmit is queued (either
at the RPC or TCP level) and the ACK arrives before the retransmission hits the
wire. If this happens to an NFS WRITE RPC then the write() system call
completes and the userspace process can continue, potentially modifying data
referenced by the retransmission before the retransmission occurs.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Neil Brown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 include/linux/sunrpc/xdr.h  |    2 ++
 include/linux/sunrpc/xprt.h |    5 ++++-
 net/sunrpc/clnt.c           |   27 ++++++++++++++++++++++-----
 net/sunrpc/svcsock.c        |    3 ++-
 net/sunrpc/xprt.c           |   12 ++++++++++++
 net/sunrpc/xprtsock.c       |    3 ++-
 6 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/include/linux/sunrpc/xdr.h b/include/linux/sunrpc/xdr.h
index af70af3..ff1b121 100644
--- a/include/linux/sunrpc/xdr.h
+++ b/include/linux/sunrpc/xdr.h
@@ -16,6 +16,7 @@
 #include <asm/byteorder.h>
 #include <asm/unaligned.h>
 #include <linux/scatterlist.h>
+#include <linux/skbuff.h>
 
 /*
  * Buffer adjustment
@@ -57,6 +58,7 @@ struct xdr_buf {
 			tail[1];	/* Appended after page data */
 
 	struct page **	pages;		/* Array of contiguous pages */
+	struct skb_frag_destructor *destructor;
 	unsigned int	page_base,	/* Start of page data */
 			page_len,	/* Length of page data */
 			flags;		/* Flags for data disposition */
diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
index 77d278d..e8d3f18 100644
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -92,7 +92,10 @@ struct rpc_rqst {
 						/* A cookie used to track the
 						   state of the transport
 						   connection */
-	
+	struct skb_frag_destructor destructor;	/* SKB paged fragment
+						 * destructor for
+						 * transmitted pages*/
+
 	/*
 	 * Partial send handling
 	 */
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 7a4cb5f..4e94e2a 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -62,6 +62,7 @@ static void	call_reserve(struct rpc_task *task);
 static void	call_reserveresult(struct rpc_task *task);
 static void	call_allocate(struct rpc_task *task);
 static void	call_decode(struct rpc_task *task);
+static void	call_complete(struct rpc_task *task);
 static void	call_bind(struct rpc_task *task);
 static void	call_bind_status(struct rpc_task *task);
 static void	call_transmit(struct rpc_task *task);
@@ -1417,6 +1418,8 @@ rpc_xdr_encode(struct rpc_task *task)
 			 (char *)req->rq_buffer + req->rq_callsize,
 			 req->rq_rcvsize);
 
+	req->rq_snd_buf.destructor = &req->destructor;
+
 	p = rpc_encode_header(task);
 	if (p == NULL) {
 		printk(KERN_INFO "RPC: couldn't encode RPC header, exit EIO\n");
@@ -1582,6 +1585,7 @@ call_connect_status(struct rpc_task *task)
 static void
 call_transmit(struct rpc_task *task)
 {
+	struct rpc_rqst *req = task->tk_rqstp;
 	dprint_status(task);
 
 	task->tk_action = call_status;
@@ -1615,8 +1619,8 @@ call_transmit(struct rpc_task *task)
 	call_transmit_status(task);
 	if (rpc_reply_expected(task))
 		return;
-	task->tk_action = rpc_exit_task;
-	rpc_wake_up_queued_task(&task->tk_xprt->pending, task);
+	task->tk_action = call_complete;
+	skb_frag_destructor_unref(&req->destructor);
 }
 
 /*
@@ -1689,7 +1693,8 @@ call_bc_transmit(struct rpc_task *task)
 		return;
 	}
 
-	task->tk_action = rpc_exit_task;
+	task->tk_action = call_complete;
+	skb_frag_destructor_unref(&req->destructor);
 	if (task->tk_status < 0) {
 		printk(KERN_NOTICE "RPC: Could not send backchannel reply "
 			"error: %d\n", task->tk_status);
@@ -1729,7 +1734,6 @@ call_bc_transmit(struct rpc_task *task)
 			"error: %d\n", task->tk_status);
 		break;
 	}
-	rpc_wake_up_queued_task(&req->rq_xprt->pending, task);
 }
 #endif /* CONFIG_SUNRPC_BACKCHANNEL */
 
@@ -1907,12 +1911,14 @@ call_decode(struct rpc_task *task)
 		return;
 	}
 
-	task->tk_action = rpc_exit_task;
+	task->tk_action = call_complete;
 
 	if (decode) {
 		task->tk_status = rpcauth_unwrap_resp(task, decode, req, p,
 						      task->tk_msg.rpc_resp);
 	}
+	rpc_sleep_on(&req->rq_xprt->pending, task, NULL);
+	skb_frag_destructor_unref(&req->destructor);
 	dprintk("RPC: %5u call_decode result %d\n", task->tk_pid,
 			task->tk_status);
 	return;
@@ -1927,6 +1933,17 @@ out_retry:
 	}
 }
 
+/*
+ * 8.	Wait for pages to be released by the network stack.
+ */
+static void
+call_complete(struct rpc_task *task)
+{
+	dprintk("RPC: %5u call_complete result %d\n",
+		task->tk_pid, task->tk_status);
+	task->tk_action = rpc_exit_task;
+}
+
 static __be32 *
 rpc_encode_header(struct rpc_task *task)
 {
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 706305b..efa95df 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -198,7 +198,8 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 	while (pglen > 0) {
 		if (slen == size)
 			flags = 0;
-		result = kernel_sendpage(sock, *ppage, NULL, base, size, flags);
+		result = kernel_sendpage(sock, *ppage, xdr->destructor,
+					 base, size, flags);
 		if (result > 0)
 			len += result;
 		if (result != size)
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 0cbcd1a..a252759 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1108,6 +1108,16 @@ static inline void xprt_init_xid(struct rpc_xprt *xprt)
 	xprt->xid = net_random();
 }
 
+static int xprt_complete_skb_pages(struct skb_frag_destructor *destroy)
+{
+	struct rpc_rqst	*req =
+		container_of(destroy, struct rpc_rqst, destructor);
+
+	dprintk("RPC: %5u completing skb pages\n", req->rq_task->tk_pid);
+	rpc_wake_up_queued_task(&req->rq_xprt->pending, req->rq_task);
+	return 0;
+}
+
 static void xprt_request_init(struct rpc_task *task, struct rpc_xprt *xprt)
 {
 	struct rpc_rqst	*req = task->tk_rqstp;
@@ -1120,6 +1130,8 @@ static void xprt_request_init(struct rpc_task *task, struct rpc_xprt *xprt)
 	req->rq_xid     = xprt_alloc_xid(xprt);
 	req->rq_release_snd_buf = NULL;
 	xprt_reset_majortimeo(req);
+	atomic_set(&req->destructor.ref, 1);
+	req->destructor.destroy = &xprt_complete_skb_pages;
 	dprintk("RPC: %5u reserved req %p xid %08x\n", task->tk_pid,
 			req, ntohl(req->rq_xid));
 }
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index f05082b..b6ee8b7 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -408,7 +408,8 @@ static int xs_send_pagedata(struct socket *sock, struct xdr_buf *xdr, unsigned i
 		remainder -= len;
 		if (remainder != 0 || more)
 			flags |= MSG_MORE;
-		err = sock->ops->sendpage(sock, *ppage, NULL, base, len, flags);
+		err = sock->ops->sendpage(sock, *ppage, xdr->destructor,
+					  base, len, flags);
 		if (remainder == 0 || err != len)
 			break;
 		sent += err;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc6j-0000hV-In; Tue, 10 Apr 2012 14:31:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc6h-0000gp-Tu
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:31:44 +0000
Received: from [85.158.143.35:60771] by server-3.bemta-4.messagelabs.com id
	A9/00-05853-C44448F4; Tue, 10 Apr 2012 14:31:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334068297!11789417!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzQ1Nzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23102 invoked from network); 10 Apr 2012 14:31:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:31:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24024973"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:36 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:36 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-F6;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:24 +0100
Message-ID: <1334067984-7706-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: linux-nfs@vger.kernel.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Neil Brown <neilb@suse.de>, xen-devel@lists.xen.org,
	"J. Bruce Fields" <bfields@fieldses.org>,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 10/10] sunrpc: use SKB fragment destructors to
	delay completion until page is released by network stack.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This prevents an issue where an ACK is delayed, a retransmit is queued (either
at the RPC or TCP level) and the ACK arrives before the retransmission hits the
wire. If this happens to an NFS WRITE RPC then the write() system call
completes and the userspace process can continue, potentially modifying data
referenced by the retransmission before the retransmission occurs.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Neil Brown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 include/linux/sunrpc/xdr.h  |    2 ++
 include/linux/sunrpc/xprt.h |    5 ++++-
 net/sunrpc/clnt.c           |   27 ++++++++++++++++++++++-----
 net/sunrpc/svcsock.c        |    3 ++-
 net/sunrpc/xprt.c           |   12 ++++++++++++
 net/sunrpc/xprtsock.c       |    3 ++-
 6 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/include/linux/sunrpc/xdr.h b/include/linux/sunrpc/xdr.h
index af70af3..ff1b121 100644
--- a/include/linux/sunrpc/xdr.h
+++ b/include/linux/sunrpc/xdr.h
@@ -16,6 +16,7 @@
 #include <asm/byteorder.h>
 #include <asm/unaligned.h>
 #include <linux/scatterlist.h>
+#include <linux/skbuff.h>
 
 /*
  * Buffer adjustment
@@ -57,6 +58,7 @@ struct xdr_buf {
 			tail[1];	/* Appended after page data */
 
 	struct page **	pages;		/* Array of contiguous pages */
+	struct skb_frag_destructor *destructor;
 	unsigned int	page_base,	/* Start of page data */
 			page_len,	/* Length of page data */
 			flags;		/* Flags for data disposition */
diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
index 77d278d..e8d3f18 100644
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -92,7 +92,10 @@ struct rpc_rqst {
 						/* A cookie used to track the
 						   state of the transport
 						   connection */
-	
+	struct skb_frag_destructor destructor;	/* SKB paged fragment
+						 * destructor for
+						 * transmitted pages*/
+
 	/*
 	 * Partial send handling
 	 */
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 7a4cb5f..4e94e2a 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -62,6 +62,7 @@ static void	call_reserve(struct rpc_task *task);
 static void	call_reserveresult(struct rpc_task *task);
 static void	call_allocate(struct rpc_task *task);
 static void	call_decode(struct rpc_task *task);
+static void	call_complete(struct rpc_task *task);
 static void	call_bind(struct rpc_task *task);
 static void	call_bind_status(struct rpc_task *task);
 static void	call_transmit(struct rpc_task *task);
@@ -1417,6 +1418,8 @@ rpc_xdr_encode(struct rpc_task *task)
 			 (char *)req->rq_buffer + req->rq_callsize,
 			 req->rq_rcvsize);
 
+	req->rq_snd_buf.destructor = &req->destructor;
+
 	p = rpc_encode_header(task);
 	if (p == NULL) {
 		printk(KERN_INFO "RPC: couldn't encode RPC header, exit EIO\n");
@@ -1582,6 +1585,7 @@ call_connect_status(struct rpc_task *task)
 static void
 call_transmit(struct rpc_task *task)
 {
+	struct rpc_rqst *req = task->tk_rqstp;
 	dprint_status(task);
 
 	task->tk_action = call_status;
@@ -1615,8 +1619,8 @@ call_transmit(struct rpc_task *task)
 	call_transmit_status(task);
 	if (rpc_reply_expected(task))
 		return;
-	task->tk_action = rpc_exit_task;
-	rpc_wake_up_queued_task(&task->tk_xprt->pending, task);
+	task->tk_action = call_complete;
+	skb_frag_destructor_unref(&req->destructor);
 }
 
 /*
@@ -1689,7 +1693,8 @@ call_bc_transmit(struct rpc_task *task)
 		return;
 	}
 
-	task->tk_action = rpc_exit_task;
+	task->tk_action = call_complete;
+	skb_frag_destructor_unref(&req->destructor);
 	if (task->tk_status < 0) {
 		printk(KERN_NOTICE "RPC: Could not send backchannel reply "
 			"error: %d\n", task->tk_status);
@@ -1729,7 +1734,6 @@ call_bc_transmit(struct rpc_task *task)
 			"error: %d\n", task->tk_status);
 		break;
 	}
-	rpc_wake_up_queued_task(&req->rq_xprt->pending, task);
 }
 #endif /* CONFIG_SUNRPC_BACKCHANNEL */
 
@@ -1907,12 +1911,14 @@ call_decode(struct rpc_task *task)
 		return;
 	}
 
-	task->tk_action = rpc_exit_task;
+	task->tk_action = call_complete;
 
 	if (decode) {
 		task->tk_status = rpcauth_unwrap_resp(task, decode, req, p,
 						      task->tk_msg.rpc_resp);
 	}
+	rpc_sleep_on(&req->rq_xprt->pending, task, NULL);
+	skb_frag_destructor_unref(&req->destructor);
 	dprintk("RPC: %5u call_decode result %d\n", task->tk_pid,
 			task->tk_status);
 	return;
@@ -1927,6 +1933,17 @@ out_retry:
 	}
 }
 
+/*
+ * 8.	Wait for pages to be released by the network stack.
+ */
+static void
+call_complete(struct rpc_task *task)
+{
+	dprintk("RPC: %5u call_complete result %d\n",
+		task->tk_pid, task->tk_status);
+	task->tk_action = rpc_exit_task;
+}
+
 static __be32 *
 rpc_encode_header(struct rpc_task *task)
 {
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 706305b..efa95df 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -198,7 +198,8 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 	while (pglen > 0) {
 		if (slen == size)
 			flags = 0;
-		result = kernel_sendpage(sock, *ppage, NULL, base, size, flags);
+		result = kernel_sendpage(sock, *ppage, xdr->destructor,
+					 base, size, flags);
 		if (result > 0)
 			len += result;
 		if (result != size)
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 0cbcd1a..a252759 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1108,6 +1108,16 @@ static inline void xprt_init_xid(struct rpc_xprt *xprt)
 	xprt->xid = net_random();
 }
 
+static int xprt_complete_skb_pages(struct skb_frag_destructor *destroy)
+{
+	struct rpc_rqst	*req =
+		container_of(destroy, struct rpc_rqst, destructor);
+
+	dprintk("RPC: %5u completing skb pages\n", req->rq_task->tk_pid);
+	rpc_wake_up_queued_task(&req->rq_xprt->pending, req->rq_task);
+	return 0;
+}
+
 static void xprt_request_init(struct rpc_task *task, struct rpc_xprt *xprt)
 {
 	struct rpc_rqst	*req = task->tk_rqstp;
@@ -1120,6 +1130,8 @@ static void xprt_request_init(struct rpc_task *task, struct rpc_xprt *xprt)
 	req->rq_xid     = xprt_alloc_xid(xprt);
 	req->rq_release_snd_buf = NULL;
 	xprt_reset_majortimeo(req);
+	atomic_set(&req->destructor.ref, 1);
+	req->destructor.destroy = &xprt_complete_skb_pages;
 	dprintk("RPC: %5u reserved req %p xid %08x\n", task->tk_pid,
 			req, ntohl(req->rq_xid));
 }
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index f05082b..b6ee8b7 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -408,7 +408,8 @@ static int xs_send_pagedata(struct socket *sock, struct xdr_buf *xdr, unsigned i
 		remainder -= len;
 		if (remainder != 0 || more)
 			flags |= MSG_MORE;
-		err = sock->ops->sendpage(sock, *ppage, NULL, base, len, flags);
+		err = sock->ops->sendpage(sock, *ppage, xdr->destructor,
+					  base, len, flags);
 		if (remainder == 0 || err != len)
 			break;
 		sent += err;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc78-0000lm-Vw; Tue, 10 Apr 2012 14:32:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHc77-0000lN-3a
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:09 +0000
Received: from [85.158.138.51:62266] by server-10.bemta-3.messagelabs.com id
	3A/AA-29478-864448F4; Tue, 10 Apr 2012 14:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334068327!21516701!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 10 Apr 2012 14:32:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 14:32:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 15:32:06 +0100
Message-Id: <4F846085020000780007D06D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 15:32:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Francisco Rocha" <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
	<4F8430C7020000780007CFD3@nat28.tlf.novell.com>,
	<4F8433A0020000780007CFE6@nat28.tlf.novell.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B693@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B693@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 14:23, Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk> wrote:
> I have added some prints in the functions you mentioned. Is this what you 
> need? 

Yes.

> These are the new lines in the dmesg, the attached file contains the rest.
> 
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 guest_cr4: 00002660 return: 00002660
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 guest_cr4: 00002660 return: 00002660
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 guest_cr4: 00002660 return: 00002660
> (XEN) traps.c:2243:d0 @XSETBV: new_xfeature: 0000000000000007
> (XEN) traps.c:2246:d0 @XSETBV: (v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_OSXSAVE): 0000000000000000

So as far as Xen is concerned, there's not even an attempt from the
Dom0 kernel to set bit 18. That's rather odd given that the only
instance of XSETBV should sit right ahead of the CR4 write. You
may want to verify that this is the case in the kernel binary, and if
so you may need to also add tracing at the kernel side (e.g. in
set_in_cr4()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc78-0000lm-Vw; Tue, 10 Apr 2012 14:32:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHc77-0000lN-3a
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:09 +0000
Received: from [85.158.138.51:62266] by server-10.bemta-3.messagelabs.com id
	3A/AA-29478-864448F4; Tue, 10 Apr 2012 14:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334068327!21516701!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 10 Apr 2012 14:32:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 14:32:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 15:32:06 +0100
Message-Id: <4F846085020000780007D06D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 15:32:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Francisco Rocha" <f.e.liberal-rocha@newcastle.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B68A@EXCCR03.campus.ncl.ac.uk>
	<4F8430C7020000780007CFD3@nat28.tlf.novell.com>,
	<4F8433A0020000780007CFE6@nat28.tlf.novell.com>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B693@EXCCR03.campus.ncl.ac.uk>
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B693@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 14:23, Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk> wrote:
> I have added some prints in the functions you mentioned. Is this what you 
> need? 

Yes.

> These are the new lines in the dmesg, the attached file contains the rest.
> 
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 guest_cr4: 00002660 return: 00002660
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 guest_cr4: 00002660 return: 00002660
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 guest_cr4: 00002660 return: 00002660
> (XEN) traps.c:2243:d0 @XSETBV: new_xfeature: 0000000000000007
> (XEN) traps.c:2246:d0 @XSETBV: (v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_OSXSAVE): 0000000000000000

So as far as Xen is concerned, there's not even an attempt from the
Dom0 kernel to set bit 18. That's rather odd given that the only
instance of XSETBV should sit right ahead of the CR4 write. You
may want to verify that this is the case in the kernel binary, and if
so you may need to also add tracing at the kernel side (e.g. in
set_in_cr4()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7g-0000rw-QR; Tue, 10 Apr 2012 14:32:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7f-0000rM-6e
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:43 +0000
Received: from [85.158.143.99:52964] by server-1.bemta-4.messagelabs.com id
	22/E6-20925-A84448F4; Tue, 10 Apr 2012 14:32:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334068359!22496312!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13430 invoked from network); 10 Apr 2012 14:32:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657713"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:38 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-5H;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:19 +0100
Message-ID: <1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front of
	sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As of the previous patch we align the end (rather than the start) of the struct
to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
increase from the next patch, the first 8 bytes of the struct end up on a
different cache line to the rest of it so make sure it is something relatively
unimportant to avoid hitting an extra cache line on hot operations such as
kfree_skb.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
 include/linux/skbuff.h |   15 ++++++++++-----
 net/core/skbuff.c      |    5 ++++-
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0ad6a46..f0ae39c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -265,6 +265,15 @@ struct ubuf_info {
  * the end of the header data, ie. at skb->end.
  */
 struct skb_shared_info {
+	/* Intermediate layers must ensure that destructor_arg
+	 * remains valid until skb destructor */
+	void		*destructor_arg;
+
+	/*
+	 * Warning: all fields from here until dataref are cleared in
+	 * __alloc_skb()
+	 *
+	 */
 	unsigned char	nr_frags;
 	__u8		tx_flags;
 	unsigned short	gso_size;
@@ -276,14 +285,10 @@ struct skb_shared_info {
 	__be32          ip6_frag_id;
 
 	/*
-	 * Warning : all fields before dataref are cleared in __alloc_skb()
+	 * Warning: all fields before dataref are cleared in __alloc_skb()
 	 */
 	atomic_t	dataref;
 
-	/* Intermediate layers must ensure that destructor_arg
-	 * remains valid until skb destructor */
-	void *		destructor_arg;
-
 	/* must be last field, see pskb_expand_head() */
 	skb_frag_t	frags[MAX_SKB_FRAGS];
 };
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d4e139e..b8a41d6 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
 
 	/* make sure we initialize shinfo sequentially */
 	shinfo = skb_shinfo(skb);
-	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
+
+	memset(&shinfo->nr_frags, 0,
+	       offsetof(struct skb_shared_info, dataref)
+	       - offsetof(struct skb_shared_info, nr_frags));
 	atomic_set(&shinfo->dataref, 1);
 	kmemcheck_annotate_variable(shinfo->destructor_arg);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7g-0000rw-QR; Tue, 10 Apr 2012 14:32:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7f-0000rM-6e
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:43 +0000
Received: from [85.158.143.99:52964] by server-1.bemta-4.messagelabs.com id
	22/E6-20925-A84448F4; Tue, 10 Apr 2012 14:32:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334068359!22496312!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13430 invoked from network); 10 Apr 2012 14:32:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657713"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:38 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-5H;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:19 +0100
Message-ID: <1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front of
	sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As of the previous patch we align the end (rather than the start) of the struct
to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
increase from the next patch, the first 8 bytes of the struct end up on a
different cache line to the rest of it so make sure it is something relatively
unimportant to avoid hitting an extra cache line on hot operations such as
kfree_skb.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
 include/linux/skbuff.h |   15 ++++++++++-----
 net/core/skbuff.c      |    5 ++++-
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0ad6a46..f0ae39c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -265,6 +265,15 @@ struct ubuf_info {
  * the end of the header data, ie. at skb->end.
  */
 struct skb_shared_info {
+	/* Intermediate layers must ensure that destructor_arg
+	 * remains valid until skb destructor */
+	void		*destructor_arg;
+
+	/*
+	 * Warning: all fields from here until dataref are cleared in
+	 * __alloc_skb()
+	 *
+	 */
 	unsigned char	nr_frags;
 	__u8		tx_flags;
 	unsigned short	gso_size;
@@ -276,14 +285,10 @@ struct skb_shared_info {
 	__be32          ip6_frag_id;
 
 	/*
-	 * Warning : all fields before dataref are cleared in __alloc_skb()
+	 * Warning: all fields before dataref are cleared in __alloc_skb()
 	 */
 	atomic_t	dataref;
 
-	/* Intermediate layers must ensure that destructor_arg
-	 * remains valid until skb destructor */
-	void *		destructor_arg;
-
 	/* must be last field, see pskb_expand_head() */
 	skb_frag_t	frags[MAX_SKB_FRAGS];
 };
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d4e139e..b8a41d6 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
 
 	/* make sure we initialize shinfo sequentially */
 	shinfo = skb_shinfo(skb);
-	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
+
+	memset(&shinfo->nr_frags, 0,
+	       offsetof(struct skb_shared_info, dataref)
+	       - offsetof(struct skb_shared_info, nr_frags));
 	atomic_set(&shinfo->dataref, 1);
 	kmemcheck_annotate_variable(shinfo->destructor_arg);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7h-0000sG-6L; Tue, 10 Apr 2012 14:32:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7f-0000rI-Gs
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:43 +0000
Received: from [85.158.143.99:52998] by server-3.bemta-4.messagelabs.com id
	41/C1-05853-B84448F4; Tue, 10 Apr 2012 14:32:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334068360!22991246!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19871 invoked from network); 10 Apr 2012 14:32:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657717"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:40 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Y-0001r9-Vb;
	Tue, 10 Apr 2012 15:26:24 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:15 +0100
Message-ID: <1334067984-7706-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 01/10] net: add and use SKB_ALLOCSIZE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This gives the allocation size required for an skb containing X bytes of data

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/ethernet/broadcom/bnx2.c        |    7 +++----
 drivers/net/ethernet/broadcom/bnx2x/bnx2x.h |    3 +--
 drivers/net/ethernet/broadcom/tg3.c         |    3 +--
 include/linux/skbuff.h                      |   12 ++++++++++++
 net/core/skbuff.c                           |    8 +-------
 5 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 8297e28..dede71f 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -5321,8 +5321,7 @@ bnx2_set_rx_ring_size(struct bnx2 *bp, u32 size)
 	/* 8 for CRC and VLAN */
 	rx_size = bp->dev->mtu + ETH_HLEN + BNX2_RX_OFFSET + 8;
 
-	rx_space = SKB_DATA_ALIGN(rx_size + BNX2_RX_ALIGN) + NET_SKB_PAD +
-		SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	rx_space = SKB_ALLOCSIZE(rx_size + BNX2_RX_ALIGN) + NET_SKB_PAD;
 
 	bp->rx_copy_thresh = BNX2_RX_COPY_THRESH;
 	bp->rx_pg_ring_size = 0;
@@ -5345,8 +5344,8 @@ bnx2_set_rx_ring_size(struct bnx2 *bp, u32 size)
 
 	bp->rx_buf_use_size = rx_size;
 	/* hw alignment + build_skb() overhead*/
-	bp->rx_buf_size = SKB_DATA_ALIGN(bp->rx_buf_use_size + BNX2_RX_ALIGN) +
-		NET_SKB_PAD + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	bp->rx_buf_size = SKB_ALLOCSIZE(bp->rx_buf_use_size + BNX2_RX_ALIGN) +
+		NET_SKB_PAD;
 	bp->rx_jumbo_thresh = rx_size - BNX2_RX_OFFSET;
 	bp->rx_ring_size = size;
 	bp->rx_max_ring = bnx2_find_max_ring(size, MAX_RX_RINGS);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index e37161f..12f2ceb 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1229,8 +1229,7 @@ struct bnx2x {
 #define BNX2X_FW_RX_ALIGN_START	(1UL << BNX2X_RX_ALIGN_SHIFT)
 
 #define BNX2X_FW_RX_ALIGN_END					\
-	max(1UL << BNX2X_RX_ALIGN_SHIFT, 			\
-	    SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+	max(1UL << BNX2X_RX_ALIGN_SHIFT, SKB_ALLOCSIZE(0))
 
 #define BNX2X_PXP_DRAM_ALIGN		(BNX2X_RX_ALIGN_SHIFT - 5)
 
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 7b71387..4d4b063 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -5672,8 +5672,7 @@ static int tg3_alloc_rx_data(struct tg3 *tp, struct tg3_rx_prodring_set *tpr,
 	 * Callers depend upon this behavior and assume that
 	 * we leave everything unchanged if we fail.
 	 */
-	skb_size = SKB_DATA_ALIGN(data_size + TG3_RX_OFFSET(tp)) +
-		   SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	skb_size = SKB_ALLOCSIZE(data_size + TG3_RX_OFFSET(tp));
 	data = kmalloc(skb_size, GFP_ATOMIC);
 	if (!data)
 		return -ENOMEM;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 192250b..fbc92b2 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -41,8 +41,20 @@
 
 #define SKB_DATA_ALIGN(X)	(((X) + (SMP_CACHE_BYTES - 1)) & \
 				 ~(SMP_CACHE_BYTES - 1))
+/* maximum data size which can fit into an allocation of X bytes */
 #define SKB_WITH_OVERHEAD(X)	\
 	((X) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+/*
+ * minimum allocation size required for an skb containing X bytes of data
+ *
+ * We do our best to align skb_shared_info on a separate cache
+ * line. It usually works because kmalloc(X > SMP_CACHE_BYTES) gives
+ * aligned memory blocks, unless SLUB/SLAB debug is enabled.  Both
+ * skb->head and skb_shared_info are cache line aligned.
+ */
+#define SKB_ALLOCSIZE(X)	\
+	(SKB_DATA_ALIGN((X)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+
 #define SKB_MAX_ORDER(X, ORDER) \
 	SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
 #define SKB_MAX_HEAD(X)		(SKB_MAX_ORDER((X), 0))
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index a690cae..59a1ecb 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -184,13 +184,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
 		goto out;
 	prefetchw(skb);
 
-	/* We do our best to align skb_shared_info on a separate cache
-	 * line. It usually works because kmalloc(X > SMP_CACHE_BYTES) gives
-	 * aligned memory blocks, unless SLUB/SLAB debug is enabled.
-	 * Both skb->head and skb_shared_info are cache line aligned.
-	 */
-	size = SKB_DATA_ALIGN(size);
-	size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	size = SKB_ALLOCSIZE(size);
 	data = kmalloc_node_track_caller(size, gfp_mask, node);
 	if (!data)
 		goto nodata;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7h-0000sG-6L; Tue, 10 Apr 2012 14:32:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7f-0000rI-Gs
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:43 +0000
Received: from [85.158.143.99:52998] by server-3.bemta-4.messagelabs.com id
	41/C1-05853-B84448F4; Tue, 10 Apr 2012 14:32:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334068360!22991246!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19871 invoked from network); 10 Apr 2012 14:32:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657717"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:40 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Y-0001r9-Vb;
	Tue, 10 Apr 2012 15:26:24 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:15 +0100
Message-ID: <1334067984-7706-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 01/10] net: add and use SKB_ALLOCSIZE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This gives the allocation size required for an skb containing X bytes of data

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/ethernet/broadcom/bnx2.c        |    7 +++----
 drivers/net/ethernet/broadcom/bnx2x/bnx2x.h |    3 +--
 drivers/net/ethernet/broadcom/tg3.c         |    3 +--
 include/linux/skbuff.h                      |   12 ++++++++++++
 net/core/skbuff.c                           |    8 +-------
 5 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 8297e28..dede71f 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -5321,8 +5321,7 @@ bnx2_set_rx_ring_size(struct bnx2 *bp, u32 size)
 	/* 8 for CRC and VLAN */
 	rx_size = bp->dev->mtu + ETH_HLEN + BNX2_RX_OFFSET + 8;
 
-	rx_space = SKB_DATA_ALIGN(rx_size + BNX2_RX_ALIGN) + NET_SKB_PAD +
-		SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	rx_space = SKB_ALLOCSIZE(rx_size + BNX2_RX_ALIGN) + NET_SKB_PAD;
 
 	bp->rx_copy_thresh = BNX2_RX_COPY_THRESH;
 	bp->rx_pg_ring_size = 0;
@@ -5345,8 +5344,8 @@ bnx2_set_rx_ring_size(struct bnx2 *bp, u32 size)
 
 	bp->rx_buf_use_size = rx_size;
 	/* hw alignment + build_skb() overhead*/
-	bp->rx_buf_size = SKB_DATA_ALIGN(bp->rx_buf_use_size + BNX2_RX_ALIGN) +
-		NET_SKB_PAD + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	bp->rx_buf_size = SKB_ALLOCSIZE(bp->rx_buf_use_size + BNX2_RX_ALIGN) +
+		NET_SKB_PAD;
 	bp->rx_jumbo_thresh = rx_size - BNX2_RX_OFFSET;
 	bp->rx_ring_size = size;
 	bp->rx_max_ring = bnx2_find_max_ring(size, MAX_RX_RINGS);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index e37161f..12f2ceb 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1229,8 +1229,7 @@ struct bnx2x {
 #define BNX2X_FW_RX_ALIGN_START	(1UL << BNX2X_RX_ALIGN_SHIFT)
 
 #define BNX2X_FW_RX_ALIGN_END					\
-	max(1UL << BNX2X_RX_ALIGN_SHIFT, 			\
-	    SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+	max(1UL << BNX2X_RX_ALIGN_SHIFT, SKB_ALLOCSIZE(0))
 
 #define BNX2X_PXP_DRAM_ALIGN		(BNX2X_RX_ALIGN_SHIFT - 5)
 
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 7b71387..4d4b063 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -5672,8 +5672,7 @@ static int tg3_alloc_rx_data(struct tg3 *tp, struct tg3_rx_prodring_set *tpr,
 	 * Callers depend upon this behavior and assume that
 	 * we leave everything unchanged if we fail.
 	 */
-	skb_size = SKB_DATA_ALIGN(data_size + TG3_RX_OFFSET(tp)) +
-		   SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	skb_size = SKB_ALLOCSIZE(data_size + TG3_RX_OFFSET(tp));
 	data = kmalloc(skb_size, GFP_ATOMIC);
 	if (!data)
 		return -ENOMEM;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 192250b..fbc92b2 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -41,8 +41,20 @@
 
 #define SKB_DATA_ALIGN(X)	(((X) + (SMP_CACHE_BYTES - 1)) & \
 				 ~(SMP_CACHE_BYTES - 1))
+/* maximum data size which can fit into an allocation of X bytes */
 #define SKB_WITH_OVERHEAD(X)	\
 	((X) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+/*
+ * minimum allocation size required for an skb containing X bytes of data
+ *
+ * We do our best to align skb_shared_info on a separate cache
+ * line. It usually works because kmalloc(X > SMP_CACHE_BYTES) gives
+ * aligned memory blocks, unless SLUB/SLAB debug is enabled.  Both
+ * skb->head and skb_shared_info are cache line aligned.
+ */
+#define SKB_ALLOCSIZE(X)	\
+	(SKB_DATA_ALIGN((X)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+
 #define SKB_MAX_ORDER(X, ORDER) \
 	SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
 #define SKB_MAX_HEAD(X)		(SKB_MAX_ORDER((X), 0))
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index a690cae..59a1ecb 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -184,13 +184,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
 		goto out;
 	prefetchw(skb);
 
-	/* We do our best to align skb_shared_info on a separate cache
-	 * line. It usually works because kmalloc(X > SMP_CACHE_BYTES) gives
-	 * aligned memory blocks, unless SLUB/SLAB debug is enabled.
-	 * Both skb->head and skb_shared_info are cache line aligned.
-	 */
-	size = SKB_DATA_ALIGN(size);
-	size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	size = SKB_ALLOCSIZE(size);
 	data = kmalloc_node_track_caller(size, gfp_mask, node);
 	if (!data)
 		goto nodata;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7g-0000rl-E2; Tue, 10 Apr 2012 14:32:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7e-0000rI-Uo
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:43 +0000
Received: from [85.158.143.99:26773] by server-3.bemta-4.messagelabs.com id
	4A/B1-05853-A84448F4; Tue, 10 Apr 2012 14:32:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334068359!22496312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13363 invoked from network); 10 Apr 2012 14:32:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:38 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-7S;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:20 +0100
Message-ID: <1334067984-7706-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	=?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 06/10] net: add support for per-paged-fragment
	destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RW50aXRpZXMgd2hpY2ggY2FyZSBhYm91dCB0aGUgY29tcGxldGUgbGlmZWN5Y2xlIG9mIHBhZ2Vz
IHdoaWNoIHRoZXkgaW5qZWN0CmludG8gdGhlIG5ldHdvcmsgc3RhY2sgdmlhIGFuIHNrYiBwYWdl
ZCBmcmFnbWVudCBjYW4gY2hvb3NlIHRvIHNldCB0aGlzCmRlc3RydWN0b3IgaW4gb3JkZXIgdG8g
cmVjZWl2ZSBhIGNhbGxiYWNrIHdoZW4gdGhlIHN0YWNrIGlzIHJlYWxseSBmaW5pc2hlZAp3aXRo
IGEgcGFnZSAoaW5jbHVkaW5nIGFsbCBjbG9uZXMsIHJldHJhbnNtaXRzLCBwdWxsLXVwcyBldGMg
ZXRjKS4KClRoaXMgZGVzdHJ1Y3RvciB3aWxsIGFsd2F5cyBiZSBwcm9wYWdhdGVkIGFsb25nc2lk
ZSB0aGUgc3RydWN0IHBhZ2Ugd2hlbgpjb3B5aW5nIHNrYl9mcmFnX3QtPnBhZ2UuIFRoaXMgaXMg
dGhlIHJlYXNvbiBJIGNob3NlIHRvIGVtYmVkIHRoZSBkZXN0cnVjdG9yIGluCmEgInN0cnVjdCB7
IH0gcGFnZSIgd2l0aGluIHRoZSBza2JfZnJhZ190LCByYXRoZXIgdGhhbiBhcyBhIHNlcGFyYXRl
IGZpZWxkLApzaW5jZSBpdCBhbGxvd3MgZXhpc3RpbmcgY29kZSB3aGljaCBwcm9wYWdhdGVzIC0+
ZnJhZ3NbTl0ucGFnZSB0byBKdXN0CldvcmsodG0pLgoKV2hlbiB0aGUgZGVzdHJ1Y3RvciBpcyBw
cmVzZW50IHRoZSBwYWdlIHJlZmVyZW5jZSBjb3VudGluZyBpcyBkb25lIHNsaWdodGx5CmRpZmZl
cmVudGx5LiBObyByZWZlcmVuY2VzIGFyZSBoZWxkIGJ5IHRoZSBuZXR3b3JrIHN0YWNrIG9uIHRo
ZSBzdHJ1Y3QgcGFnZSAoaXQKaXMgdXAgdG8gdGhlIGNhbGxlciB0byBtYW5hZ2UgdGhpcyBhcyBu
ZWNlc3NhcnkpIGluc3RlYWQgdGhlIG5ldHdvcmsgc3RhY2sgd2lsbAp0cmFjayByZWZlcmVuY2Vz
IHZpYSB0aGUgY291bnQgZW1iZWRkZWQgaW4gdGhlIGRlc3RydWN0b3Igc3RydWN0dXJlLiBXaGVu
IHRoaXMKcmVmZXJlbmNlIGNvdW50IHJlYWNoZXMgemVybyB0aGVuIHRoZSBkZXN0cnVjdG9yIHdp
bGwgYmUgY2FsbGVkIGFuZCB0aGUgY2FsbGVyCmNhbiB0YWtlIHRoZSBuZWNlc2FyeSBzdGVwcyB0
byByZWxlYXNlIHRoZSBwYWdlIChpLmUuIHJlbGVhc2UgdGhlIHN0cnVjdCBwYWdlCnJlZmVyZW5j
ZSBpdHNlbGYpLgoKVGhlIGludGVudGlvbiBpcyB0aGF0IGNhbGxlcnMgY2FuIHVzZSB0aGlzIGNh
bGxiYWNrIHRvIGRlbGF5IGNvbXBsZXRpb24gdG8KX3RoZWlyXyBjYWxsZXJzIHVudGlsIHRoZSBu
ZXR3b3JrIHN0YWNrIGhhcyBjb21wbGV0ZWx5IHJlbGVhc2VkIHRoZSBwYWdlLCBpbgpvcmRlciB0
byBwcmV2ZW50IHVzZS1hZnRlci1mcmVlIG9yIG1vZGlmaWNhdGlvbiBvZiBkYXRhIHBhZ2VzIHdo
aWNoIGFyZSBzdGlsbAppbiB1c2UgYnkgdGhlIHN0YWNrLgoKSXQgaXMgYWxsb3dhYmxlIChpbmRl
ZWQgZXhwZWN0ZWQpIGZvciBhIGNhbGxlciB0byBzaGFyZSBhIHNpbmdsZSBkZXN0cnVjdG9yCmlu
c3RhbmNlIGJldHdlZW4gbXVsdGlwbGUgcGFnZXMgaW5qZWN0ZWQgaW50byB0aGUgc3RhY2sgZS5n
LiBhIGdyb3VwIG9mIHBhZ2VzCmluY2x1ZGVkIGluIGEgc2luZ2xlIGhpZ2hlciBsZXZlbCBvcGVy
YXRpb24gbWlnaHQgc2hhcmUgYSBkZXN0cnVjdG9yIHdoaWNoIGlzCnVzZWQgdG8gY29tcGxldGUg
dGhhdCBoaWdoZXIgbGV2ZWwgb3BlcmF0aW9uLgoKV2l0aCB0aGlzIGNoYW5nZSBhbmQgdGhlIHBy
ZXZpb3VzIHR3byBjaGFuZ2VzIHRvIHNoaW5mbyBhbGlnbm1lbnQgYW5kIGZpZWxkCm9yZGVycmlu
ZyBpdCBpcyBub3cgdGhlIGNhc2UgdHloYXQgb24gYSA2NCBiaXQgc3lzdGVtIHdpdGggNjQgYnl0
ZSBjYWNoZSBsaW5lcywKZXZlcnl0aGluZyBmcm9tIG5yX2ZyYWdzIHVudGlsIHRoZSBlbmQgb2Yg
ZnJhZ3NbMF0gaXMgb24gdGhlIHNhbWUgY2FjaGVsaW5lLgoKU2lnbmVkLW9mZi1ieTogSWFuIENh
bXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6ICJEYXZpZCBTLiBNaWxsZXIiIDxk
YXZlbUBkYXZlbWxvZnQubmV0PgpDYzogRXJpYyBEdW1hemV0IDxlcmljLmR1bWF6ZXRAZ21haWwu
Y29tPgpDYzogIk1pY2hhxYIgTWlyb3PFgmF3IiA8bWlycS1saW51eEByZXJlLnFtcW0ucGw+CkNj
OiBuZXRkZXZAdmdlci5rZXJuZWwub3JnCi0tLQogaW5jbHVkZS9saW51eC9za2J1ZmYuaCB8ICAg
NDMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogbmV0L2NvcmUv
c2tidWZmLmMgICAgICB8ICAgMTcgKysrKysrKysrKysrKysrKysKIDIgZmlsZXMgY2hhbmdlZCwg
NjAgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9pbmNsdWRlL2xp
bnV4L3NrYnVmZi5oIGIvaW5jbHVkZS9saW51eC9za2J1ZmYuaAppbmRleCBmMGFlMzljLi42YWMy
ODNlIDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4L3NrYnVmZi5oCisrKyBiL2luY2x1ZGUvbGlu
dXgvc2tidWZmLmgKQEAgLTE2Niw5ICsxNjYsMTUgQEAgc3RydWN0IHNrX2J1ZmY7CiAKIHR5cGVk
ZWYgc3RydWN0IHNrYl9mcmFnX3N0cnVjdCBza2JfZnJhZ190OwogCitzdHJ1Y3Qgc2tiX2ZyYWdf
ZGVzdHJ1Y3RvciB7CisJYXRvbWljX3QgcmVmOworCWludCAoKmRlc3Ryb3kpKHN0cnVjdCBza2Jf
ZnJhZ19kZXN0cnVjdG9yICpkZXN0cnVjdG9yKTsKK307CisKIHN0cnVjdCBza2JfZnJhZ19zdHJ1
Y3QgewogCXN0cnVjdCB7CiAJCXN0cnVjdCBwYWdlICpwOworCQlzdHJ1Y3Qgc2tiX2ZyYWdfZGVz
dHJ1Y3RvciAqZGVzdHJ1Y3RvcjsKIAl9IHBhZ2U7CiAjaWYgKEJJVFNfUEVSX0xPTkcgPiAzMikg
fHwgKFBBR0VfU0laRSA+PSA2NTUzNikKIAlfX3UzMiBwYWdlX29mZnNldDsKQEAgLTEyMjEsNiAr
MTIyNywzMSBAQCBzdGF0aWMgaW5saW5lIGludCBza2JfcGFnZWxlbihjb25zdCBzdHJ1Y3Qgc2tf
YnVmZiAqc2tiKQogfQogCiAvKioKKyAqIHNrYl9mcmFnX3NldF9kZXN0cnVjdG9yIC0gc2V0IGRl
c3RydWN0b3IgZm9yIGEgcGFnZWQgZnJhZ21lbnQKKyAqIEBza2I6IGJ1ZmZlciBjb250YWluaW5n
IGZyYWdtZW50IHRvIGJlIGluaXRpYWxpc2VkCisgKiBAaTogcGFnZWQgZnJhZ21lbnQgaW5kZXgg
dG8gaW5pdGlhbGlzZQorICogQGRlc3Ryb3k6IHRoZSBkZXN0cnVjdG9yIHRvIHVzZSBmb3IgdGhp
cyBmcmFnbWVudAorICoKKyAqIFNldHMgQGRlc3Ryb3kgYXMgdGhlIGRlc3RydWN0b3IgdG8gYmUg
Y2FsbGVkIHdoZW4gYWxsIHJlZmVyZW5jZXMgdG8KKyAqIHRoZSBmcmFnIEBpIGluIEBza2IgKHRy
YWNrZWQgb3ZlciBza2JfY2xvbmUsIHJldHJhbnNtaXQsIHB1bGwtdXBzLAorICogZXRjKSBhcmUg
cmVsZWFzZWQuCisgKgorICogV2hlbiBhIGRlc3RydWN0b3IgaXMgc2V0IHRoZW4gcmVmZXJlbmNl
IGNvdW50aW5nIGlzIHBlcmZvcm1lZCBvbgorICogQGRlc3Ryb3ktPnJlZi4gV2hlbiB0aGUgcmVm
IHJlYWNoZXMgemVybyB0aGVuIEBkZXN0cm95LT5kZXN0cm95CisgKiB3aWxsIGJlIGNhbGxlZC4g
VGhlIGNhbGxlciBpcyByZXNwb25zaWJsZSBmb3IgaG9sZGluZyBhbmQgbWFuYWdpbmcKKyAqIGFu
eSBvdGhlciByZWZlcmVuY2VzIChzdWNoIGEgdGhlIHN0cnVjdCBwYWdlIHJlZmVyZW5jZSBjb3Vu
dCkuCisgKgorICogVGhpcyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBiZWZvcmUgYW55IHVzZSBv
ZiBza2JfZnJhZ19yZWYoKSBvcgorICogc2tiX2ZyYWdfdW5yZWYoKS4KKyAqLworc3RhdGljIGlu
bGluZSB2b2lkIHNrYl9mcmFnX3NldF9kZXN0cnVjdG9yKHN0cnVjdCBza19idWZmICpza2IsIGlu
dCBpLAorCQkJCQkgICBzdHJ1Y3Qgc2tiX2ZyYWdfZGVzdHJ1Y3RvciAqZGVzdHJveSkKK3sKKwlz
a2JfZnJhZ190ICpmcmFnID0gJnNrYl9zaGluZm8oc2tiKS0+ZnJhZ3NbaV07CisJZnJhZy0+cGFn
ZS5kZXN0cnVjdG9yID0gZGVzdHJveTsKK30KKworLyoqCiAgKiBfX3NrYl9maWxsX3BhZ2VfZGVz
YyAtIGluaXRpYWxpc2UgYSBwYWdlZCBmcmFnbWVudCBpbiBhbiBza2IKICAqIEBza2I6IGJ1ZmZl
ciBjb250YWluaW5nIGZyYWdtZW50IHRvIGJlIGluaXRpYWxpc2VkCiAgKiBAaTogcGFnZWQgZnJh
Z21lbnQgaW5kZXggdG8gaW5pdGlhbGlzZQpAQCAtMTIzOSw2ICsxMjcwLDcgQEAgc3RhdGljIGlu
bGluZSB2b2lkIF9fc2tiX2ZpbGxfcGFnZV9kZXNjKHN0cnVjdCBza19idWZmICpza2IsIGludCBp
LAogCXNrYl9mcmFnX3QgKmZyYWcgPSAmc2tiX3NoaW5mbyhza2IpLT5mcmFnc1tpXTsKIAogCWZy
YWctPnBhZ2UucAkJICA9IHBhZ2U7CisJZnJhZy0+cGFnZS5kZXN0cnVjdG9yICAgICA9IE5VTEw7
CiAJZnJhZy0+cGFnZV9vZmZzZXQJICA9IG9mZjsKIAlza2JfZnJhZ19zaXplX3NldChmcmFnLCBz
aXplKTsKIH0KQEAgLTE3NDMsNiArMTc3NSw5IEBAIHN0YXRpYyBpbmxpbmUgc3RydWN0IHBhZ2Ug
KnNrYl9mcmFnX3BhZ2UoY29uc3Qgc2tiX2ZyYWdfdCAqZnJhZykKIAlyZXR1cm4gZnJhZy0+cGFn
ZS5wOwogfQogCitleHRlcm4gdm9pZCBza2JfZnJhZ19kZXN0cnVjdG9yX3JlZihzdHJ1Y3Qgc2ti
X2ZyYWdfZGVzdHJ1Y3RvciAqZGVzdHJveSk7CitleHRlcm4gdm9pZCBza2JfZnJhZ19kZXN0cnVj
dG9yX3VucmVmKHN0cnVjdCBza2JfZnJhZ19kZXN0cnVjdG9yICpkZXN0cm95KTsKKwogLyoqCiAg
KiBfX3NrYl9mcmFnX3JlZiAtIHRha2UgYW4gYWRkaXRpb24gcmVmZXJlbmNlIG9uIGEgcGFnZWQg
ZnJhZ21lbnQuCiAgKiBAZnJhZzogdGhlIHBhZ2VkIGZyYWdtZW50CkBAIC0xNzUxLDYgKzE3ODYs
MTAgQEAgc3RhdGljIGlubGluZSBzdHJ1Y3QgcGFnZSAqc2tiX2ZyYWdfcGFnZShjb25zdCBza2Jf
ZnJhZ190ICpmcmFnKQogICovCiBzdGF0aWMgaW5saW5lIHZvaWQgX19za2JfZnJhZ19yZWYoc2ti
X2ZyYWdfdCAqZnJhZykKIHsKKwlpZiAodW5saWtlbHkoZnJhZy0+cGFnZS5kZXN0cnVjdG9yKSkg
eworCQlza2JfZnJhZ19kZXN0cnVjdG9yX3JlZihmcmFnLT5wYWdlLmRlc3RydWN0b3IpOworCQly
ZXR1cm47CisJfQogCWdldF9wYWdlKHNrYl9mcmFnX3BhZ2UoZnJhZykpOwogfQogCkBAIC0xNzc0
LDYgKzE4MTMsMTAgQEAgc3RhdGljIGlubGluZSB2b2lkIHNrYl9mcmFnX3JlZihzdHJ1Y3Qgc2tf
YnVmZiAqc2tiLCBpbnQgZikKICAqLwogc3RhdGljIGlubGluZSB2b2lkIF9fc2tiX2ZyYWdfdW5y
ZWYoc2tiX2ZyYWdfdCAqZnJhZykKIHsKKwlpZiAodW5saWtlbHkoZnJhZy0+cGFnZS5kZXN0cnVj
dG9yKSkgeworCQlza2JfZnJhZ19kZXN0cnVjdG9yX3VucmVmKGZyYWctPnBhZ2UuZGVzdHJ1Y3Rv
cik7CisJCXJldHVybjsKKwl9CiAJcHV0X3BhZ2Uoc2tiX2ZyYWdfcGFnZShmcmFnKSk7CiB9CiAK
ZGlmZiAtLWdpdCBhL25ldC9jb3JlL3NrYnVmZi5jIGIvbmV0L2NvcmUvc2tidWZmLmMKaW5kZXgg
YjhhNDFkNi4uOWVjODhjZSAxMDA2NDQKLS0tIGEvbmV0L2NvcmUvc2tidWZmLmMKKysrIGIvbmV0
L2NvcmUvc2tidWZmLmMKQEAgLTM0OSw2ICszNDksMjMgQEAgc3RydWN0IHNrX2J1ZmYgKmRldl9h
bGxvY19za2IodW5zaWduZWQgaW50IGxlbmd0aCkKIH0KIEVYUE9SVF9TWU1CT0woZGV2X2FsbG9j
X3NrYik7CiAKK3ZvaWQgc2tiX2ZyYWdfZGVzdHJ1Y3Rvcl9yZWYoc3RydWN0IHNrYl9mcmFnX2Rl
c3RydWN0b3IgKmRlc3Ryb3kpCit7CisJQlVHX09OKGRlc3Ryb3kgPT0gTlVMTCk7CisJYXRvbWlj
X2luYygmZGVzdHJveS0+cmVmKTsKK30KK0VYUE9SVF9TWU1CT0woc2tiX2ZyYWdfZGVzdHJ1Y3Rv
cl9yZWYpOworCit2b2lkIHNrYl9mcmFnX2Rlc3RydWN0b3JfdW5yZWYoc3RydWN0IHNrYl9mcmFn
X2Rlc3RydWN0b3IgKmRlc3Ryb3kpCit7CisJaWYgKGRlc3Ryb3kgPT0gTlVMTCkKKwkJcmV0dXJu
OworCisJaWYgKGF0b21pY19kZWNfYW5kX3Rlc3QoJmRlc3Ryb3ktPnJlZikpCisJCWRlc3Ryb3kt
PmRlc3Ryb3koZGVzdHJveSk7Cit9CitFWFBPUlRfU1lNQk9MKHNrYl9mcmFnX2Rlc3RydWN0b3Jf
dW5yZWYpOworCiBzdGF0aWMgdm9pZCBza2JfZHJvcF9saXN0KHN0cnVjdCBza19idWZmICoqbGlz
dHApCiB7CiAJc3RydWN0IHNrX2J1ZmYgKmxpc3QgPSAqbGlzdHA7Ci0tIAoxLjcuMi41CgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7g-0000rl-E2; Tue, 10 Apr 2012 14:32:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7e-0000rI-Uo
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:43 +0000
Received: from [85.158.143.99:26773] by server-3.bemta-4.messagelabs.com id
	4A/B1-05853-A84448F4; Tue, 10 Apr 2012 14:32:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334068359!22496312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13363 invoked from network); 10 Apr 2012 14:32:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:38 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-7S;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:20 +0100
Message-ID: <1334067984-7706-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	=?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 06/10] net: add support for per-paged-fragment
	destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RW50aXRpZXMgd2hpY2ggY2FyZSBhYm91dCB0aGUgY29tcGxldGUgbGlmZWN5Y2xlIG9mIHBhZ2Vz
IHdoaWNoIHRoZXkgaW5qZWN0CmludG8gdGhlIG5ldHdvcmsgc3RhY2sgdmlhIGFuIHNrYiBwYWdl
ZCBmcmFnbWVudCBjYW4gY2hvb3NlIHRvIHNldCB0aGlzCmRlc3RydWN0b3IgaW4gb3JkZXIgdG8g
cmVjZWl2ZSBhIGNhbGxiYWNrIHdoZW4gdGhlIHN0YWNrIGlzIHJlYWxseSBmaW5pc2hlZAp3aXRo
IGEgcGFnZSAoaW5jbHVkaW5nIGFsbCBjbG9uZXMsIHJldHJhbnNtaXRzLCBwdWxsLXVwcyBldGMg
ZXRjKS4KClRoaXMgZGVzdHJ1Y3RvciB3aWxsIGFsd2F5cyBiZSBwcm9wYWdhdGVkIGFsb25nc2lk
ZSB0aGUgc3RydWN0IHBhZ2Ugd2hlbgpjb3B5aW5nIHNrYl9mcmFnX3QtPnBhZ2UuIFRoaXMgaXMg
dGhlIHJlYXNvbiBJIGNob3NlIHRvIGVtYmVkIHRoZSBkZXN0cnVjdG9yIGluCmEgInN0cnVjdCB7
IH0gcGFnZSIgd2l0aGluIHRoZSBza2JfZnJhZ190LCByYXRoZXIgdGhhbiBhcyBhIHNlcGFyYXRl
IGZpZWxkLApzaW5jZSBpdCBhbGxvd3MgZXhpc3RpbmcgY29kZSB3aGljaCBwcm9wYWdhdGVzIC0+
ZnJhZ3NbTl0ucGFnZSB0byBKdXN0CldvcmsodG0pLgoKV2hlbiB0aGUgZGVzdHJ1Y3RvciBpcyBw
cmVzZW50IHRoZSBwYWdlIHJlZmVyZW5jZSBjb3VudGluZyBpcyBkb25lIHNsaWdodGx5CmRpZmZl
cmVudGx5LiBObyByZWZlcmVuY2VzIGFyZSBoZWxkIGJ5IHRoZSBuZXR3b3JrIHN0YWNrIG9uIHRo
ZSBzdHJ1Y3QgcGFnZSAoaXQKaXMgdXAgdG8gdGhlIGNhbGxlciB0byBtYW5hZ2UgdGhpcyBhcyBu
ZWNlc3NhcnkpIGluc3RlYWQgdGhlIG5ldHdvcmsgc3RhY2sgd2lsbAp0cmFjayByZWZlcmVuY2Vz
IHZpYSB0aGUgY291bnQgZW1iZWRkZWQgaW4gdGhlIGRlc3RydWN0b3Igc3RydWN0dXJlLiBXaGVu
IHRoaXMKcmVmZXJlbmNlIGNvdW50IHJlYWNoZXMgemVybyB0aGVuIHRoZSBkZXN0cnVjdG9yIHdp
bGwgYmUgY2FsbGVkIGFuZCB0aGUgY2FsbGVyCmNhbiB0YWtlIHRoZSBuZWNlc2FyeSBzdGVwcyB0
byByZWxlYXNlIHRoZSBwYWdlIChpLmUuIHJlbGVhc2UgdGhlIHN0cnVjdCBwYWdlCnJlZmVyZW5j
ZSBpdHNlbGYpLgoKVGhlIGludGVudGlvbiBpcyB0aGF0IGNhbGxlcnMgY2FuIHVzZSB0aGlzIGNh
bGxiYWNrIHRvIGRlbGF5IGNvbXBsZXRpb24gdG8KX3RoZWlyXyBjYWxsZXJzIHVudGlsIHRoZSBu
ZXR3b3JrIHN0YWNrIGhhcyBjb21wbGV0ZWx5IHJlbGVhc2VkIHRoZSBwYWdlLCBpbgpvcmRlciB0
byBwcmV2ZW50IHVzZS1hZnRlci1mcmVlIG9yIG1vZGlmaWNhdGlvbiBvZiBkYXRhIHBhZ2VzIHdo
aWNoIGFyZSBzdGlsbAppbiB1c2UgYnkgdGhlIHN0YWNrLgoKSXQgaXMgYWxsb3dhYmxlIChpbmRl
ZWQgZXhwZWN0ZWQpIGZvciBhIGNhbGxlciB0byBzaGFyZSBhIHNpbmdsZSBkZXN0cnVjdG9yCmlu
c3RhbmNlIGJldHdlZW4gbXVsdGlwbGUgcGFnZXMgaW5qZWN0ZWQgaW50byB0aGUgc3RhY2sgZS5n
LiBhIGdyb3VwIG9mIHBhZ2VzCmluY2x1ZGVkIGluIGEgc2luZ2xlIGhpZ2hlciBsZXZlbCBvcGVy
YXRpb24gbWlnaHQgc2hhcmUgYSBkZXN0cnVjdG9yIHdoaWNoIGlzCnVzZWQgdG8gY29tcGxldGUg
dGhhdCBoaWdoZXIgbGV2ZWwgb3BlcmF0aW9uLgoKV2l0aCB0aGlzIGNoYW5nZSBhbmQgdGhlIHBy
ZXZpb3VzIHR3byBjaGFuZ2VzIHRvIHNoaW5mbyBhbGlnbm1lbnQgYW5kIGZpZWxkCm9yZGVycmlu
ZyBpdCBpcyBub3cgdGhlIGNhc2UgdHloYXQgb24gYSA2NCBiaXQgc3lzdGVtIHdpdGggNjQgYnl0
ZSBjYWNoZSBsaW5lcywKZXZlcnl0aGluZyBmcm9tIG5yX2ZyYWdzIHVudGlsIHRoZSBlbmQgb2Yg
ZnJhZ3NbMF0gaXMgb24gdGhlIHNhbWUgY2FjaGVsaW5lLgoKU2lnbmVkLW9mZi1ieTogSWFuIENh
bXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6ICJEYXZpZCBTLiBNaWxsZXIiIDxk
YXZlbUBkYXZlbWxvZnQubmV0PgpDYzogRXJpYyBEdW1hemV0IDxlcmljLmR1bWF6ZXRAZ21haWwu
Y29tPgpDYzogIk1pY2hhxYIgTWlyb3PFgmF3IiA8bWlycS1saW51eEByZXJlLnFtcW0ucGw+CkNj
OiBuZXRkZXZAdmdlci5rZXJuZWwub3JnCi0tLQogaW5jbHVkZS9saW51eC9za2J1ZmYuaCB8ICAg
NDMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogbmV0L2NvcmUv
c2tidWZmLmMgICAgICB8ICAgMTcgKysrKysrKysrKysrKysrKysKIDIgZmlsZXMgY2hhbmdlZCwg
NjAgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9pbmNsdWRlL2xp
bnV4L3NrYnVmZi5oIGIvaW5jbHVkZS9saW51eC9za2J1ZmYuaAppbmRleCBmMGFlMzljLi42YWMy
ODNlIDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4L3NrYnVmZi5oCisrKyBiL2luY2x1ZGUvbGlu
dXgvc2tidWZmLmgKQEAgLTE2Niw5ICsxNjYsMTUgQEAgc3RydWN0IHNrX2J1ZmY7CiAKIHR5cGVk
ZWYgc3RydWN0IHNrYl9mcmFnX3N0cnVjdCBza2JfZnJhZ190OwogCitzdHJ1Y3Qgc2tiX2ZyYWdf
ZGVzdHJ1Y3RvciB7CisJYXRvbWljX3QgcmVmOworCWludCAoKmRlc3Ryb3kpKHN0cnVjdCBza2Jf
ZnJhZ19kZXN0cnVjdG9yICpkZXN0cnVjdG9yKTsKK307CisKIHN0cnVjdCBza2JfZnJhZ19zdHJ1
Y3QgewogCXN0cnVjdCB7CiAJCXN0cnVjdCBwYWdlICpwOworCQlzdHJ1Y3Qgc2tiX2ZyYWdfZGVz
dHJ1Y3RvciAqZGVzdHJ1Y3RvcjsKIAl9IHBhZ2U7CiAjaWYgKEJJVFNfUEVSX0xPTkcgPiAzMikg
fHwgKFBBR0VfU0laRSA+PSA2NTUzNikKIAlfX3UzMiBwYWdlX29mZnNldDsKQEAgLTEyMjEsNiAr
MTIyNywzMSBAQCBzdGF0aWMgaW5saW5lIGludCBza2JfcGFnZWxlbihjb25zdCBzdHJ1Y3Qgc2tf
YnVmZiAqc2tiKQogfQogCiAvKioKKyAqIHNrYl9mcmFnX3NldF9kZXN0cnVjdG9yIC0gc2V0IGRl
c3RydWN0b3IgZm9yIGEgcGFnZWQgZnJhZ21lbnQKKyAqIEBza2I6IGJ1ZmZlciBjb250YWluaW5n
IGZyYWdtZW50IHRvIGJlIGluaXRpYWxpc2VkCisgKiBAaTogcGFnZWQgZnJhZ21lbnQgaW5kZXgg
dG8gaW5pdGlhbGlzZQorICogQGRlc3Ryb3k6IHRoZSBkZXN0cnVjdG9yIHRvIHVzZSBmb3IgdGhp
cyBmcmFnbWVudAorICoKKyAqIFNldHMgQGRlc3Ryb3kgYXMgdGhlIGRlc3RydWN0b3IgdG8gYmUg
Y2FsbGVkIHdoZW4gYWxsIHJlZmVyZW5jZXMgdG8KKyAqIHRoZSBmcmFnIEBpIGluIEBza2IgKHRy
YWNrZWQgb3ZlciBza2JfY2xvbmUsIHJldHJhbnNtaXQsIHB1bGwtdXBzLAorICogZXRjKSBhcmUg
cmVsZWFzZWQuCisgKgorICogV2hlbiBhIGRlc3RydWN0b3IgaXMgc2V0IHRoZW4gcmVmZXJlbmNl
IGNvdW50aW5nIGlzIHBlcmZvcm1lZCBvbgorICogQGRlc3Ryb3ktPnJlZi4gV2hlbiB0aGUgcmVm
IHJlYWNoZXMgemVybyB0aGVuIEBkZXN0cm95LT5kZXN0cm95CisgKiB3aWxsIGJlIGNhbGxlZC4g
VGhlIGNhbGxlciBpcyByZXNwb25zaWJsZSBmb3IgaG9sZGluZyBhbmQgbWFuYWdpbmcKKyAqIGFu
eSBvdGhlciByZWZlcmVuY2VzIChzdWNoIGEgdGhlIHN0cnVjdCBwYWdlIHJlZmVyZW5jZSBjb3Vu
dCkuCisgKgorICogVGhpcyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBiZWZvcmUgYW55IHVzZSBv
ZiBza2JfZnJhZ19yZWYoKSBvcgorICogc2tiX2ZyYWdfdW5yZWYoKS4KKyAqLworc3RhdGljIGlu
bGluZSB2b2lkIHNrYl9mcmFnX3NldF9kZXN0cnVjdG9yKHN0cnVjdCBza19idWZmICpza2IsIGlu
dCBpLAorCQkJCQkgICBzdHJ1Y3Qgc2tiX2ZyYWdfZGVzdHJ1Y3RvciAqZGVzdHJveSkKK3sKKwlz
a2JfZnJhZ190ICpmcmFnID0gJnNrYl9zaGluZm8oc2tiKS0+ZnJhZ3NbaV07CisJZnJhZy0+cGFn
ZS5kZXN0cnVjdG9yID0gZGVzdHJveTsKK30KKworLyoqCiAgKiBfX3NrYl9maWxsX3BhZ2VfZGVz
YyAtIGluaXRpYWxpc2UgYSBwYWdlZCBmcmFnbWVudCBpbiBhbiBza2IKICAqIEBza2I6IGJ1ZmZl
ciBjb250YWluaW5nIGZyYWdtZW50IHRvIGJlIGluaXRpYWxpc2VkCiAgKiBAaTogcGFnZWQgZnJh
Z21lbnQgaW5kZXggdG8gaW5pdGlhbGlzZQpAQCAtMTIzOSw2ICsxMjcwLDcgQEAgc3RhdGljIGlu
bGluZSB2b2lkIF9fc2tiX2ZpbGxfcGFnZV9kZXNjKHN0cnVjdCBza19idWZmICpza2IsIGludCBp
LAogCXNrYl9mcmFnX3QgKmZyYWcgPSAmc2tiX3NoaW5mbyhza2IpLT5mcmFnc1tpXTsKIAogCWZy
YWctPnBhZ2UucAkJICA9IHBhZ2U7CisJZnJhZy0+cGFnZS5kZXN0cnVjdG9yICAgICA9IE5VTEw7
CiAJZnJhZy0+cGFnZV9vZmZzZXQJICA9IG9mZjsKIAlza2JfZnJhZ19zaXplX3NldChmcmFnLCBz
aXplKTsKIH0KQEAgLTE3NDMsNiArMTc3NSw5IEBAIHN0YXRpYyBpbmxpbmUgc3RydWN0IHBhZ2Ug
KnNrYl9mcmFnX3BhZ2UoY29uc3Qgc2tiX2ZyYWdfdCAqZnJhZykKIAlyZXR1cm4gZnJhZy0+cGFn
ZS5wOwogfQogCitleHRlcm4gdm9pZCBza2JfZnJhZ19kZXN0cnVjdG9yX3JlZihzdHJ1Y3Qgc2ti
X2ZyYWdfZGVzdHJ1Y3RvciAqZGVzdHJveSk7CitleHRlcm4gdm9pZCBza2JfZnJhZ19kZXN0cnVj
dG9yX3VucmVmKHN0cnVjdCBza2JfZnJhZ19kZXN0cnVjdG9yICpkZXN0cm95KTsKKwogLyoqCiAg
KiBfX3NrYl9mcmFnX3JlZiAtIHRha2UgYW4gYWRkaXRpb24gcmVmZXJlbmNlIG9uIGEgcGFnZWQg
ZnJhZ21lbnQuCiAgKiBAZnJhZzogdGhlIHBhZ2VkIGZyYWdtZW50CkBAIC0xNzUxLDYgKzE3ODYs
MTAgQEAgc3RhdGljIGlubGluZSBzdHJ1Y3QgcGFnZSAqc2tiX2ZyYWdfcGFnZShjb25zdCBza2Jf
ZnJhZ190ICpmcmFnKQogICovCiBzdGF0aWMgaW5saW5lIHZvaWQgX19za2JfZnJhZ19yZWYoc2ti
X2ZyYWdfdCAqZnJhZykKIHsKKwlpZiAodW5saWtlbHkoZnJhZy0+cGFnZS5kZXN0cnVjdG9yKSkg
eworCQlza2JfZnJhZ19kZXN0cnVjdG9yX3JlZihmcmFnLT5wYWdlLmRlc3RydWN0b3IpOworCQly
ZXR1cm47CisJfQogCWdldF9wYWdlKHNrYl9mcmFnX3BhZ2UoZnJhZykpOwogfQogCkBAIC0xNzc0
LDYgKzE4MTMsMTAgQEAgc3RhdGljIGlubGluZSB2b2lkIHNrYl9mcmFnX3JlZihzdHJ1Y3Qgc2tf
YnVmZiAqc2tiLCBpbnQgZikKICAqLwogc3RhdGljIGlubGluZSB2b2lkIF9fc2tiX2ZyYWdfdW5y
ZWYoc2tiX2ZyYWdfdCAqZnJhZykKIHsKKwlpZiAodW5saWtlbHkoZnJhZy0+cGFnZS5kZXN0cnVj
dG9yKSkgeworCQlza2JfZnJhZ19kZXN0cnVjdG9yX3VucmVmKGZyYWctPnBhZ2UuZGVzdHJ1Y3Rv
cik7CisJCXJldHVybjsKKwl9CiAJcHV0X3BhZ2Uoc2tiX2ZyYWdfcGFnZShmcmFnKSk7CiB9CiAK
ZGlmZiAtLWdpdCBhL25ldC9jb3JlL3NrYnVmZi5jIGIvbmV0L2NvcmUvc2tidWZmLmMKaW5kZXgg
YjhhNDFkNi4uOWVjODhjZSAxMDA2NDQKLS0tIGEvbmV0L2NvcmUvc2tidWZmLmMKKysrIGIvbmV0
L2NvcmUvc2tidWZmLmMKQEAgLTM0OSw2ICszNDksMjMgQEAgc3RydWN0IHNrX2J1ZmYgKmRldl9h
bGxvY19za2IodW5zaWduZWQgaW50IGxlbmd0aCkKIH0KIEVYUE9SVF9TWU1CT0woZGV2X2FsbG9j
X3NrYik7CiAKK3ZvaWQgc2tiX2ZyYWdfZGVzdHJ1Y3Rvcl9yZWYoc3RydWN0IHNrYl9mcmFnX2Rl
c3RydWN0b3IgKmRlc3Ryb3kpCit7CisJQlVHX09OKGRlc3Ryb3kgPT0gTlVMTCk7CisJYXRvbWlj
X2luYygmZGVzdHJveS0+cmVmKTsKK30KK0VYUE9SVF9TWU1CT0woc2tiX2ZyYWdfZGVzdHJ1Y3Rv
cl9yZWYpOworCit2b2lkIHNrYl9mcmFnX2Rlc3RydWN0b3JfdW5yZWYoc3RydWN0IHNrYl9mcmFn
X2Rlc3RydWN0b3IgKmRlc3Ryb3kpCit7CisJaWYgKGRlc3Ryb3kgPT0gTlVMTCkKKwkJcmV0dXJu
OworCisJaWYgKGF0b21pY19kZWNfYW5kX3Rlc3QoJmRlc3Ryb3ktPnJlZikpCisJCWRlc3Ryb3kt
PmRlc3Ryb3koZGVzdHJveSk7Cit9CitFWFBPUlRfU1lNQk9MKHNrYl9mcmFnX2Rlc3RydWN0b3Jf
dW5yZWYpOworCiBzdGF0aWMgdm9pZCBza2JfZHJvcF9saXN0KHN0cnVjdCBza19idWZmICoqbGlz
dHApCiB7CiAJc3RydWN0IHNrX2J1ZmYgKmxpc3QgPSAqbGlzdHA7Ci0tIAoxLjcuMi41CgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7i-0000t8-PN; Tue, 10 Apr 2012 14:32:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7h-0000rM-44
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:45 +0000
Received: from [85.158.143.99:53102] by server-1.bemta-4.messagelabs.com id
	11/F6-20925-C84448F4; Tue, 10 Apr 2012 14:32:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334068359!22496312!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13508 invoked from network); 10 Apr 2012 14:32:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657710"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:37 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-9r;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:21 +0100
Message-ID: <1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	James Morris <jmorris@namei.org>, xen-devel@lists.xen.org,
	Patrick McHardy <kaber@trash.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	=?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>,
	"Pekka Savola \(ipv6\)" <pekkas@netcore.fi>
Subject: [Xen-devel] [PATCH 07/10] net: only allow paged fragments with the
	same destructor to be coalesced.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6
ICJEYXZpZCBTLiBNaWxsZXIiIDxkYXZlbUBkYXZlbWxvZnQubmV0PgpDYzogQWxleGV5IEt1em5l
dHNvdiA8a3V6bmV0QG1zMi5pbnIuYWMucnU+CkNjOiAiUGVra2EgU2F2b2xhIChpcHY2KSIgPHBl
a2thc0BuZXRjb3JlLmZpPgpDYzogSmFtZXMgTW9ycmlzIDxqbW9ycmlzQG5hbWVpLm9yZz4KQ2M6
IEhpZGVha2kgWU9TSElGVUpJIDx5b3NoZnVqaUBsaW51eC1pcHY2Lm9yZz4KQ2M6IFBhdHJpY2sg
TWNIYXJkeSA8a2FiZXJAdHJhc2gubmV0PgpDYzogRXJpYyBEdW1hemV0IDxlcmljLmR1bWF6ZXRA
Z21haWwuY29tPgpDYzogIk1pY2hhxYIgTWlyb3PFgmF3IiA8bWlycS1saW51eEByZXJlLnFtcW0u
cGw+CkNjOiBuZXRkZXZAdmdlci5rZXJuZWwub3JnCi0tLQogaW5jbHVkZS9saW51eC9za2J1ZmYu
aCB8ICAgIDcgKysrKystLQogbmV0L2NvcmUvc2tidWZmLmMgICAgICB8ICAgIDEgKwogbmV0L2lw
djQvaXBfb3V0cHV0LmMgICB8ICAgIDIgKy0KIG5ldC9pcHY0L3RjcC5jICAgICAgICAgfCAgICA0
ICsrLS0KIDQgZmlsZXMgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQoK
ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvc2tidWZmLmggYi9pbmNsdWRlL2xpbnV4L3NrYnVm
Zi5oCmluZGV4IDZhYzI4M2UuLjg1OTNhYzIgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGludXgvc2ti
dWZmLmgKKysrIGIvaW5jbHVkZS9saW51eC9za2J1ZmYuaApAQCAtMjAxNCwxMyArMjAxNCwxNiBA
QCBzdGF0aWMgaW5saW5lIGludCBza2JfYWRkX2RhdGEoc3RydWN0IHNrX2J1ZmYgKnNrYiwKIH0K
IAogc3RhdGljIGlubGluZSBpbnQgc2tiX2Nhbl9jb2FsZXNjZShzdHJ1Y3Qgc2tfYnVmZiAqc2ti
LCBpbnQgaSwKLQkJCQkgICBjb25zdCBzdHJ1Y3QgcGFnZSAqcGFnZSwgaW50IG9mZikKKwkJCQkg
ICBjb25zdCBzdHJ1Y3QgcGFnZSAqcGFnZSwKKwkJCQkgICBjb25zdCBzdHJ1Y3Qgc2tiX2ZyYWdf
ZGVzdHJ1Y3RvciAqZGVzdHJveSwKKwkJCQkgICBpbnQgb2ZmKQogewogCWlmIChpKSB7CiAJCWNv
bnN0IHN0cnVjdCBza2JfZnJhZ19zdHJ1Y3QgKmZyYWcgPSAmc2tiX3NoaW5mbyhza2IpLT5mcmFn
c1tpIC0gMV07CiAKIAkJcmV0dXJuIHBhZ2UgPT0gc2tiX2ZyYWdfcGFnZShmcmFnKSAmJgotCQkg
ICAgICAgb2ZmID09IGZyYWctPnBhZ2Vfb2Zmc2V0ICsgc2tiX2ZyYWdfc2l6ZShmcmFnKTsKKwkJ
ICAgICAgIG9mZiA9PSBmcmFnLT5wYWdlX29mZnNldCArIHNrYl9mcmFnX3NpemUoZnJhZykgJiYK
KwkJICAgICAgIGZyYWctPnBhZ2UuZGVzdHJ1Y3RvciA9PSBkZXN0cm95OwogCX0KIAlyZXR1cm4g
MDsKIH0KZGlmZiAtLWdpdCBhL25ldC9jb3JlL3NrYnVmZi5jIGIvbmV0L2NvcmUvc2tidWZmLmMK
aW5kZXggOWVjODhjZS4uZTYzYTRhNiAxMDA2NDQKLS0tIGEvbmV0L2NvcmUvc2tidWZmLmMKKysr
IGIvbmV0L2NvcmUvc2tidWZmLmMKQEAgLTIzMjMsNiArMjMyMyw3IEBAIGludCBza2Jfc2hpZnQo
c3RydWN0IHNrX2J1ZmYgKnRndCwgc3RydWN0IHNrX2J1ZmYgKnNrYiwgaW50IHNoaWZ0bGVuKQog
CSAqLwogCWlmICghdG8gfHwKIAkgICAgIXNrYl9jYW5fY29hbGVzY2UodGd0LCB0bywgc2tiX2Zy
YWdfcGFnZShmcmFnZnJvbSksCisJCQkgICAgICBmcmFnZnJvbS0+cGFnZS5kZXN0cnVjdG9yLAog
CQkJICAgICAgZnJhZ2Zyb20tPnBhZ2Vfb2Zmc2V0KSkgewogCQltZXJnZSA9IC0xOwogCX0gZWxz
ZSB7CmRpZmYgLS1naXQgYS9uZXQvaXB2NC9pcF9vdXRwdXQuYyBiL25ldC9pcHY0L2lwX291dHB1
dC5jCmluZGV4IGZmMzAyYmQuLjllNGVjYTYgMTAwNjQ0Ci0tLSBhL25ldC9pcHY0L2lwX291dHB1
dC5jCisrKyBiL25ldC9pcHY0L2lwX291dHB1dC5jCkBAIC0xMjQzLDcgKzEyNDMsNyBAQCBzc2l6
ZV90CWlwX2FwcGVuZF9wYWdlKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IGZsb3dpNCAqZmw0LCBz
dHJ1Y3QgcGFnZSAqcGFnZSwKIAkJaSA9IHNrYl9zaGluZm8oc2tiKS0+bnJfZnJhZ3M7CiAJCWlm
IChsZW4gPiBzaXplKQogCQkJbGVuID0gc2l6ZTsKLQkJaWYgKHNrYl9jYW5fY29hbGVzY2Uoc2ti
LCBpLCBwYWdlLCBvZmZzZXQpKSB7CisJCWlmIChza2JfY2FuX2NvYWxlc2NlKHNrYiwgaSwgcGFn
ZSwgTlVMTCwgb2Zmc2V0KSkgewogCQkJc2tiX2ZyYWdfc2l6ZV9hZGQoJnNrYl9zaGluZm8oc2ti
KS0+ZnJhZ3NbaS0xXSwgbGVuKTsKIAkJfSBlbHNlIGlmIChpIDwgTUFYX1NLQl9GUkFHUykgewog
CQkJZ2V0X3BhZ2UocGFnZSk7CmRpZmYgLS1naXQgYS9uZXQvaXB2NC90Y3AuYyBiL25ldC9pcHY0
L3RjcC5jCmluZGV4IGNmZDdlZGQuLmIxNjEyZTkgMTAwNjQ0Ci0tLSBhL25ldC9pcHY0L3RjcC5j
CisrKyBiL25ldC9pcHY0L3RjcC5jCkBAIC04MDQsNyArODA0LDcgQEAgbmV3X3NlZ21lbnQ6CiAJ
CQljb3B5ID0gc2l6ZTsKIAogCQlpID0gc2tiX3NoaW5mbyhza2IpLT5ucl9mcmFnczsKLQkJY2Fu
X2NvYWxlc2NlID0gc2tiX2Nhbl9jb2FsZXNjZShza2IsIGksIHBhZ2UsIG9mZnNldCk7CisJCWNh
bl9jb2FsZXNjZSA9IHNrYl9jYW5fY29hbGVzY2Uoc2tiLCBpLCBwYWdlLCBOVUxMLCBvZmZzZXQp
OwogCQlpZiAoIWNhbl9jb2FsZXNjZSAmJiBpID49IE1BWF9TS0JfRlJBR1MpIHsKIAkJCXRjcF9t
YXJrX3B1c2godHAsIHNrYik7CiAJCQlnb3RvIG5ld19zZWdtZW50OwpAQCAtMTAxMyw3ICsxMDEz
LDcgQEAgbmV3X3NlZ21lbnQ6CiAKIAkJCQlvZmYgPSBzay0+c2tfc25kbXNnX29mZjsKIAotCQkJ
CWlmIChza2JfY2FuX2NvYWxlc2NlKHNrYiwgaSwgcGFnZSwgb2ZmKSAmJgorCQkJCWlmIChza2Jf
Y2FuX2NvYWxlc2NlKHNrYiwgaSwgcGFnZSwgTlVMTCwgb2ZmKSAmJgogCQkJCSAgICBvZmYgIT0g
UEFHRV9TSVpFKSB7CiAJCQkJCS8qIFdlIGNhbiBleHRlbmQgdGhlIGxhc3QgcGFnZQogCQkJCQkg
KiBmcmFnbWVudC4gKi8KLS0gCjEuNy4yLjUKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7i-0000t8-PN; Tue, 10 Apr 2012 14:32:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7h-0000rM-44
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:45 +0000
Received: from [85.158.143.99:53102] by server-1.bemta-4.messagelabs.com id
	11/F6-20925-C84448F4; Tue, 10 Apr 2012 14:32:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334068359!22496312!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13508 invoked from network); 10 Apr 2012 14:32:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657710"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:37 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-9r;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:21 +0100
Message-ID: <1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	James Morris <jmorris@namei.org>, xen-devel@lists.xen.org,
	Patrick McHardy <kaber@trash.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	=?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>,
	"Pekka Savola \(ipv6\)" <pekkas@netcore.fi>
Subject: [Xen-devel] [PATCH 07/10] net: only allow paged fragments with the
	same destructor to be coalesced.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6
ICJEYXZpZCBTLiBNaWxsZXIiIDxkYXZlbUBkYXZlbWxvZnQubmV0PgpDYzogQWxleGV5IEt1em5l
dHNvdiA8a3V6bmV0QG1zMi5pbnIuYWMucnU+CkNjOiAiUGVra2EgU2F2b2xhIChpcHY2KSIgPHBl
a2thc0BuZXRjb3JlLmZpPgpDYzogSmFtZXMgTW9ycmlzIDxqbW9ycmlzQG5hbWVpLm9yZz4KQ2M6
IEhpZGVha2kgWU9TSElGVUpJIDx5b3NoZnVqaUBsaW51eC1pcHY2Lm9yZz4KQ2M6IFBhdHJpY2sg
TWNIYXJkeSA8a2FiZXJAdHJhc2gubmV0PgpDYzogRXJpYyBEdW1hemV0IDxlcmljLmR1bWF6ZXRA
Z21haWwuY29tPgpDYzogIk1pY2hhxYIgTWlyb3PFgmF3IiA8bWlycS1saW51eEByZXJlLnFtcW0u
cGw+CkNjOiBuZXRkZXZAdmdlci5rZXJuZWwub3JnCi0tLQogaW5jbHVkZS9saW51eC9za2J1ZmYu
aCB8ICAgIDcgKysrKystLQogbmV0L2NvcmUvc2tidWZmLmMgICAgICB8ICAgIDEgKwogbmV0L2lw
djQvaXBfb3V0cHV0LmMgICB8ICAgIDIgKy0KIG5ldC9pcHY0L3RjcC5jICAgICAgICAgfCAgICA0
ICsrLS0KIDQgZmlsZXMgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQoK
ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvc2tidWZmLmggYi9pbmNsdWRlL2xpbnV4L3NrYnVm
Zi5oCmluZGV4IDZhYzI4M2UuLjg1OTNhYzIgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGludXgvc2ti
dWZmLmgKKysrIGIvaW5jbHVkZS9saW51eC9za2J1ZmYuaApAQCAtMjAxNCwxMyArMjAxNCwxNiBA
QCBzdGF0aWMgaW5saW5lIGludCBza2JfYWRkX2RhdGEoc3RydWN0IHNrX2J1ZmYgKnNrYiwKIH0K
IAogc3RhdGljIGlubGluZSBpbnQgc2tiX2Nhbl9jb2FsZXNjZShzdHJ1Y3Qgc2tfYnVmZiAqc2ti
LCBpbnQgaSwKLQkJCQkgICBjb25zdCBzdHJ1Y3QgcGFnZSAqcGFnZSwgaW50IG9mZikKKwkJCQkg
ICBjb25zdCBzdHJ1Y3QgcGFnZSAqcGFnZSwKKwkJCQkgICBjb25zdCBzdHJ1Y3Qgc2tiX2ZyYWdf
ZGVzdHJ1Y3RvciAqZGVzdHJveSwKKwkJCQkgICBpbnQgb2ZmKQogewogCWlmIChpKSB7CiAJCWNv
bnN0IHN0cnVjdCBza2JfZnJhZ19zdHJ1Y3QgKmZyYWcgPSAmc2tiX3NoaW5mbyhza2IpLT5mcmFn
c1tpIC0gMV07CiAKIAkJcmV0dXJuIHBhZ2UgPT0gc2tiX2ZyYWdfcGFnZShmcmFnKSAmJgotCQkg
ICAgICAgb2ZmID09IGZyYWctPnBhZ2Vfb2Zmc2V0ICsgc2tiX2ZyYWdfc2l6ZShmcmFnKTsKKwkJ
ICAgICAgIG9mZiA9PSBmcmFnLT5wYWdlX29mZnNldCArIHNrYl9mcmFnX3NpemUoZnJhZykgJiYK
KwkJICAgICAgIGZyYWctPnBhZ2UuZGVzdHJ1Y3RvciA9PSBkZXN0cm95OwogCX0KIAlyZXR1cm4g
MDsKIH0KZGlmZiAtLWdpdCBhL25ldC9jb3JlL3NrYnVmZi5jIGIvbmV0L2NvcmUvc2tidWZmLmMK
aW5kZXggOWVjODhjZS4uZTYzYTRhNiAxMDA2NDQKLS0tIGEvbmV0L2NvcmUvc2tidWZmLmMKKysr
IGIvbmV0L2NvcmUvc2tidWZmLmMKQEAgLTIzMjMsNiArMjMyMyw3IEBAIGludCBza2Jfc2hpZnQo
c3RydWN0IHNrX2J1ZmYgKnRndCwgc3RydWN0IHNrX2J1ZmYgKnNrYiwgaW50IHNoaWZ0bGVuKQog
CSAqLwogCWlmICghdG8gfHwKIAkgICAgIXNrYl9jYW5fY29hbGVzY2UodGd0LCB0bywgc2tiX2Zy
YWdfcGFnZShmcmFnZnJvbSksCisJCQkgICAgICBmcmFnZnJvbS0+cGFnZS5kZXN0cnVjdG9yLAog
CQkJICAgICAgZnJhZ2Zyb20tPnBhZ2Vfb2Zmc2V0KSkgewogCQltZXJnZSA9IC0xOwogCX0gZWxz
ZSB7CmRpZmYgLS1naXQgYS9uZXQvaXB2NC9pcF9vdXRwdXQuYyBiL25ldC9pcHY0L2lwX291dHB1
dC5jCmluZGV4IGZmMzAyYmQuLjllNGVjYTYgMTAwNjQ0Ci0tLSBhL25ldC9pcHY0L2lwX291dHB1
dC5jCisrKyBiL25ldC9pcHY0L2lwX291dHB1dC5jCkBAIC0xMjQzLDcgKzEyNDMsNyBAQCBzc2l6
ZV90CWlwX2FwcGVuZF9wYWdlKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IGZsb3dpNCAqZmw0LCBz
dHJ1Y3QgcGFnZSAqcGFnZSwKIAkJaSA9IHNrYl9zaGluZm8oc2tiKS0+bnJfZnJhZ3M7CiAJCWlm
IChsZW4gPiBzaXplKQogCQkJbGVuID0gc2l6ZTsKLQkJaWYgKHNrYl9jYW5fY29hbGVzY2Uoc2ti
LCBpLCBwYWdlLCBvZmZzZXQpKSB7CisJCWlmIChza2JfY2FuX2NvYWxlc2NlKHNrYiwgaSwgcGFn
ZSwgTlVMTCwgb2Zmc2V0KSkgewogCQkJc2tiX2ZyYWdfc2l6ZV9hZGQoJnNrYl9zaGluZm8oc2ti
KS0+ZnJhZ3NbaS0xXSwgbGVuKTsKIAkJfSBlbHNlIGlmIChpIDwgTUFYX1NLQl9GUkFHUykgewog
CQkJZ2V0X3BhZ2UocGFnZSk7CmRpZmYgLS1naXQgYS9uZXQvaXB2NC90Y3AuYyBiL25ldC9pcHY0
L3RjcC5jCmluZGV4IGNmZDdlZGQuLmIxNjEyZTkgMTAwNjQ0Ci0tLSBhL25ldC9pcHY0L3RjcC5j
CisrKyBiL25ldC9pcHY0L3RjcC5jCkBAIC04MDQsNyArODA0LDcgQEAgbmV3X3NlZ21lbnQ6CiAJ
CQljb3B5ID0gc2l6ZTsKIAogCQlpID0gc2tiX3NoaW5mbyhza2IpLT5ucl9mcmFnczsKLQkJY2Fu
X2NvYWxlc2NlID0gc2tiX2Nhbl9jb2FsZXNjZShza2IsIGksIHBhZ2UsIG9mZnNldCk7CisJCWNh
bl9jb2FsZXNjZSA9IHNrYl9jYW5fY29hbGVzY2Uoc2tiLCBpLCBwYWdlLCBOVUxMLCBvZmZzZXQp
OwogCQlpZiAoIWNhbl9jb2FsZXNjZSAmJiBpID49IE1BWF9TS0JfRlJBR1MpIHsKIAkJCXRjcF9t
YXJrX3B1c2godHAsIHNrYik7CiAJCQlnb3RvIG5ld19zZWdtZW50OwpAQCAtMTAxMyw3ICsxMDEz
LDcgQEAgbmV3X3NlZ21lbnQ6CiAKIAkJCQlvZmYgPSBzay0+c2tfc25kbXNnX29mZjsKIAotCQkJ
CWlmIChza2JfY2FuX2NvYWxlc2NlKHNrYiwgaSwgcGFnZSwgb2ZmKSAmJgorCQkJCWlmIChza2Jf
Y2FuX2NvYWxlc2NlKHNrYiwgaSwgcGFnZSwgTlVMTCwgb2ZmKSAmJgogCQkJCSAgICBvZmYgIT0g
UEFHRV9TSVpFKSB7CiAJCQkJCS8qIFdlIGNhbiBleHRlbmQgdGhlIGxhc3QgcGFnZQogCQkJCQkg
KiBmcmFnbWVudC4gKi8KLS0gCjEuNy4yLjUKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7o-0000w8-8l; Tue, 10 Apr 2012 14:32:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7m-0000uf-84
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:10516] by server-2.bemta-4.messagelabs.com id
	E3/6F-17550-194448F4; Tue, 10 Apr 2012 14:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 301 invoked from network); 10 Apr 2012 14:32:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657715"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-3C;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:18 +0100
Message-ID: <1334067984-7706-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 04/10] net: pad skb data and shinfo as a whole
	rather than individually
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This reduces the minimum overhead required for this allocation such that the
shinfo can be grown in the following patch without overflowing 2048 bytes for a
1500 byte frame.

Reducing this overhead while also growing the shinfo means that sometimes the
tail end of the data can end up in the same cache line as the beginning of the
shinfo. Specifically in the case of the 64 byte cache lines on a 64 bit system
the first 8 bytes of shinfo can overlap the tail cacheline of the data. In many
cases the allocation slop means that there is no overlap.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
 include/linux/skbuff.h |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index fbc92b2..0ad6a46 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -43,17 +43,20 @@
 				 ~(SMP_CACHE_BYTES - 1))
 /* maximum data size which can fit into an allocation of X bytes */
 #define SKB_WITH_OVERHEAD(X)	\
-	((X) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+	((X) - sizeof(struct skb_shared_info))
 /*
  * minimum allocation size required for an skb containing X bytes of data
  *
  * We do our best to align skb_shared_info on a separate cache
  * line. It usually works because kmalloc(X > SMP_CACHE_BYTES) gives
- * aligned memory blocks, unless SLUB/SLAB debug is enabled.  Both
- * skb->head and skb_shared_info are cache line aligned.
+ * aligned memory blocks, unless SLUB/SLAB debug is enabled.
+ * skb->head is aligned to a cache line while the tail of
+ * skb_shared_info is cache line aligned.  We arrange that the order
+ * of the fields in skb_shared_info is such that the interesting
+ * fields are cache line aligned and fit within a 64 byte cache line.
  */
 #define SKB_ALLOCSIZE(X)	\
-	(SKB_DATA_ALIGN((X)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+	(SKB_DATA_ALIGN((X) + sizeof(struct skb_shared_info)))
 
 #define SKB_MAX_ORDER(X, ORDER) \
 	SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
@@ -63,7 +66,7 @@
 /* return minimum truesize of one skb containing X bytes of data */
 #define SKB_TRUESIZE(X) ((X) +						\
 			 SKB_DATA_ALIGN(sizeof(struct sk_buff)) +	\
-			 SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+			 sizeof(struct skb_shared_info))
 
 /* A. Checksumming of received packets by device.
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7o-0000w8-8l; Tue, 10 Apr 2012 14:32:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7m-0000uf-84
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:10516] by server-2.bemta-4.messagelabs.com id
	E3/6F-17550-194448F4; Tue, 10 Apr 2012 14:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 301 invoked from network); 10 Apr 2012 14:32:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657715"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-3C;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:18 +0100
Message-ID: <1334067984-7706-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 04/10] net: pad skb data and shinfo as a whole
	rather than individually
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This reduces the minimum overhead required for this allocation such that the
shinfo can be grown in the following patch without overflowing 2048 bytes for a
1500 byte frame.

Reducing this overhead while also growing the shinfo means that sometimes the
tail end of the data can end up in the same cache line as the beginning of the
shinfo. Specifically in the case of the 64 byte cache lines on a 64 bit system
the first 8 bytes of shinfo can overlap the tail cacheline of the data. In many
cases the allocation slop means that there is no overlap.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
 include/linux/skbuff.h |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index fbc92b2..0ad6a46 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -43,17 +43,20 @@
 				 ~(SMP_CACHE_BYTES - 1))
 /* maximum data size which can fit into an allocation of X bytes */
 #define SKB_WITH_OVERHEAD(X)	\
-	((X) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+	((X) - sizeof(struct skb_shared_info))
 /*
  * minimum allocation size required for an skb containing X bytes of data
  *
  * We do our best to align skb_shared_info on a separate cache
  * line. It usually works because kmalloc(X > SMP_CACHE_BYTES) gives
- * aligned memory blocks, unless SLUB/SLAB debug is enabled.  Both
- * skb->head and skb_shared_info are cache line aligned.
+ * aligned memory blocks, unless SLUB/SLAB debug is enabled.
+ * skb->head is aligned to a cache line while the tail of
+ * skb_shared_info is cache line aligned.  We arrange that the order
+ * of the fields in skb_shared_info is such that the interesting
+ * fields are cache line aligned and fit within a 64 byte cache line.
  */
 #define SKB_ALLOCSIZE(X)	\
-	(SKB_DATA_ALIGN((X)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+	(SKB_DATA_ALIGN((X) + sizeof(struct skb_shared_info)))
 
 #define SKB_MAX_ORDER(X, ORDER) \
 	SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
@@ -63,7 +66,7 @@
 /* return minimum truesize of one skb containing X bytes of data */
 #define SKB_TRUESIZE(X) ((X) +						\
 			 SKB_DATA_ALIGN(sizeof(struct sk_buff)) +	\
-			 SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+			 sizeof(struct skb_shared_info))
 
 /* A. Checksumming of received packets by device.
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7p-0000we-1b; Tue, 10 Apr 2012 14:32:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7m-0000uR-SM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:56587] by server-3.bemta-4.messagelabs.com id
	31/F1-05853-294448F4; Tue, 10 Apr 2012 14:32:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 10 Apr 2012 14:32:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657716"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:40 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-0D;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:16 +0100
Message-ID: <1334067984-7706-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 02/10] net: Use SKB_WITH_OVERHEAD in build_skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 net/core/skbuff.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 59a1ecb..d4e139e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -264,7 +264,7 @@ struct sk_buff *build_skb(void *data)
 	if (!skb)
 		return NULL;
 
-	size = ksize(data) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	size = SKB_WITH_OVERHEAD(ksize(data));
 
 	memset(skb, 0, offsetof(struct sk_buff, tail));
 	skb->truesize = SKB_TRUESIZE(size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7p-0000we-1b; Tue, 10 Apr 2012 14:32:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7m-0000uR-SM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:56587] by server-3.bemta-4.messagelabs.com id
	31/F1-05853-294448F4; Tue, 10 Apr 2012 14:32:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 10 Apr 2012 14:32:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657716"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:40 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-0D;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:16 +0100
Message-ID: <1334067984-7706-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 02/10] net: Use SKB_WITH_OVERHEAD in build_skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 net/core/skbuff.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 59a1ecb..d4e139e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -264,7 +264,7 @@ struct sk_buff *build_skb(void *data)
 	if (!skb)
 		return NULL;
 
-	size = ksize(data) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+	size = SKB_WITH_OVERHEAD(ksize(data));
 
 	memset(skb, 0, offsetof(struct sk_buff, tail));
 	skb->truesize = SKB_TRUESIZE(size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7o-0000wP-KX; Tue, 10 Apr 2012 14:32:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7m-0000uR-G7
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:10515] by server-3.bemta-4.messagelabs.com id
	D9/E1-05853-194448F4; Tue, 10 Apr 2012 14:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32588 invoked from network); 10 Apr 2012 14:32:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657708"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:38 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:37 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-C5;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:22 +0100
Message-ID: <1334067984-7706-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 08/10] net: add skb_orphan_frags to copy aside
	frags with destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should be used by drivers which need to hold on to an skb for an extended
(perhaps unbounded) period of time. e.g. the tun driver which relies on
userspace consuming the skb.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: mst@redhat.com
---
 drivers/net/tun.c      |    1 +
 include/linux/skbuff.h |   11 ++++++++
 net/core/skbuff.c      |   67 ++++++++++++++++++++++++++++++++++-------------
 3 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 74d7f76..b20789e 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -416,6 +416,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
 	/* Orphan the skb - required as we might hang on to it
 	 * for indefinite time. */
 	skb_orphan(skb);
+	skb_orphan_frags(skb, GFP_KERNEL);
 
 	/* Enqueue packet */
 	skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb);
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8593ac2..77145f0 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1688,6 +1688,17 @@ static inline void skb_orphan(struct sk_buff *skb)
 }
 
 /**
+ *	skb_orphan_frags - orphan the frags contained in a buffer
+ *	@skb: buffer to orphan frags from
+ *	@gfp_mask: allocation mask for replacement pages
+ *
+ *	For each frag in the SKB which has a destructor (i.e. has an
+ *	owner) create a copy of that frag and release the original
+ *	page by calling the destructor.
+ */
+extern int skb_orphan_frags(struct sk_buff *skb, gfp_t gfp_mask);
+
+/**
  *	__skb_queue_purge - empty a list
  *	@list: list to empty
  *
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index e63a4a6..d0a1603 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -688,31 +688,25 @@ struct sk_buff *skb_morph(struct sk_buff *dst, struct sk_buff *src)
 }
 EXPORT_SYMBOL_GPL(skb_morph);
 
-/*	skb_copy_ubufs	-	copy userspace skb frags buffers to kernel
- *	@skb: the skb to modify
- *	@gfp_mask: allocation priority
- *
- *	This must be called on SKBTX_DEV_ZEROCOPY skb.
- *	It will copy all frags into kernel and drop the reference
- *	to userspace pages.
- *
- *	If this function is called from an interrupt gfp_mask() must be
- *	%GFP_ATOMIC.
- *
- *	Returns 0 on success or a negative error code on failure
- *	to allocate kernel memory to copy to.
+/*
+ * If uarg != NULL copy and replace all frags.
+ * If uarg == NULL then only copy and replace those which have a destructor
+ * pointer.
  */
-int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
+static int skb_copy_frags(struct sk_buff *skb, gfp_t gfp_mask,
+			  struct ubuf_info *uarg)
 {
 	int i;
 	int num_frags = skb_shinfo(skb)->nr_frags;
 	struct page *page, *head = NULL;
-	struct ubuf_info *uarg = skb_shinfo(skb)->destructor_arg;
 
 	for (i = 0; i < num_frags; i++) {
 		u8 *vaddr;
 		skb_frag_t *f = &skb_shinfo(skb)->frags[i];
 
+		if (!uarg && !f->page.destructor)
+			continue;
+
 		page = alloc_page(GFP_ATOMIC);
 		if (!page) {
 			while (head) {
@@ -730,11 +724,16 @@ int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
 		head = page;
 	}
 
-	/* skb frags release userspace buffers */
-	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
+	/* skb frags release buffers */
+	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+		skb_frag_t *f = &skb_shinfo(skb)->frags[i];
+		if (!uarg && !f->page.destructor)
+			continue;
 		skb_frag_unref(skb, i);
+	}
 
-	uarg->callback(uarg);
+	if (uarg)
+		uarg->callback(uarg);
 
 	/* skb frags point to kernel buffers */
 	for (i = skb_shinfo(skb)->nr_frags; i > 0; i--) {
@@ -743,10 +742,40 @@ int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
 		head = (struct page *)head->private;
 	}
 
-	skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
 	return 0;
 }
 
+/*	skb_copy_ubufs	-	copy userspace skb frags buffers to kernel
+ *	@skb: the skb to modify
+ *	@gfp_mask: allocation priority
+ *
+ *	This must be called on SKBTX_DEV_ZEROCOPY skb.
+ *	It will copy all frags into kernel and drop the reference
+ *	to userspace pages.
+ *
+ *	If this function is called from an interrupt gfp_mask() must be
+ *	%GFP_ATOMIC.
+ *
+ *	Returns 0 on success or a negative error code on failure
+ *	to allocate kernel memory to copy to.
+ */
+int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
+{
+	struct ubuf_info *uarg = skb_shinfo(skb)->destructor_arg;
+	int rc;
+
+	rc = skb_copy_frags(skb, gfp_mask, uarg);
+
+	if (rc == 0)
+		skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
+
+	return rc;
+}
+
+int skb_orphan_frags(struct sk_buff *skb, gfp_t gfp_mask)
+{
+	return skb_copy_frags(skb, gfp_mask, NULL);
+}
 
 /**
  *	skb_clone	-	duplicate an sk_buff
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:32:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHc7o-0000wP-KX; Tue, 10 Apr 2012 14:32:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7m-0000uR-G7
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:10515] by server-3.bemta-4.messagelabs.com id
	D9/E1-05853-194448F4; Tue, 10 Apr 2012 14:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32588 invoked from network); 10 Apr 2012 14:32:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657708"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:38 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:37 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-C5;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:22 +0100
Message-ID: <1334067984-7706-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 08/10] net: add skb_orphan_frags to copy aside
	frags with destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should be used by drivers which need to hold on to an skb for an extended
(perhaps unbounded) period of time. e.g. the tun driver which relies on
userspace consuming the skb.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: mst@redhat.com
---
 drivers/net/tun.c      |    1 +
 include/linux/skbuff.h |   11 ++++++++
 net/core/skbuff.c      |   67 ++++++++++++++++++++++++++++++++++-------------
 3 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 74d7f76..b20789e 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -416,6 +416,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
 	/* Orphan the skb - required as we might hang on to it
 	 * for indefinite time. */
 	skb_orphan(skb);
+	skb_orphan_frags(skb, GFP_KERNEL);
 
 	/* Enqueue packet */
 	skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb);
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8593ac2..77145f0 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1688,6 +1688,17 @@ static inline void skb_orphan(struct sk_buff *skb)
 }
 
 /**
+ *	skb_orphan_frags - orphan the frags contained in a buffer
+ *	@skb: buffer to orphan frags from
+ *	@gfp_mask: allocation mask for replacement pages
+ *
+ *	For each frag in the SKB which has a destructor (i.e. has an
+ *	owner) create a copy of that frag and release the original
+ *	page by calling the destructor.
+ */
+extern int skb_orphan_frags(struct sk_buff *skb, gfp_t gfp_mask);
+
+/**
  *	__skb_queue_purge - empty a list
  *	@list: list to empty
  *
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index e63a4a6..d0a1603 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -688,31 +688,25 @@ struct sk_buff *skb_morph(struct sk_buff *dst, struct sk_buff *src)
 }
 EXPORT_SYMBOL_GPL(skb_morph);
 
-/*	skb_copy_ubufs	-	copy userspace skb frags buffers to kernel
- *	@skb: the skb to modify
- *	@gfp_mask: allocation priority
- *
- *	This must be called on SKBTX_DEV_ZEROCOPY skb.
- *	It will copy all frags into kernel and drop the reference
- *	to userspace pages.
- *
- *	If this function is called from an interrupt gfp_mask() must be
- *	%GFP_ATOMIC.
- *
- *	Returns 0 on success or a negative error code on failure
- *	to allocate kernel memory to copy to.
+/*
+ * If uarg != NULL copy and replace all frags.
+ * If uarg == NULL then only copy and replace those which have a destructor
+ * pointer.
  */
-int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
+static int skb_copy_frags(struct sk_buff *skb, gfp_t gfp_mask,
+			  struct ubuf_info *uarg)
 {
 	int i;
 	int num_frags = skb_shinfo(skb)->nr_frags;
 	struct page *page, *head = NULL;
-	struct ubuf_info *uarg = skb_shinfo(skb)->destructor_arg;
 
 	for (i = 0; i < num_frags; i++) {
 		u8 *vaddr;
 		skb_frag_t *f = &skb_shinfo(skb)->frags[i];
 
+		if (!uarg && !f->page.destructor)
+			continue;
+
 		page = alloc_page(GFP_ATOMIC);
 		if (!page) {
 			while (head) {
@@ -730,11 +724,16 @@ int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
 		head = page;
 	}
 
-	/* skb frags release userspace buffers */
-	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
+	/* skb frags release buffers */
+	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+		skb_frag_t *f = &skb_shinfo(skb)->frags[i];
+		if (!uarg && !f->page.destructor)
+			continue;
 		skb_frag_unref(skb, i);
+	}
 
-	uarg->callback(uarg);
+	if (uarg)
+		uarg->callback(uarg);
 
 	/* skb frags point to kernel buffers */
 	for (i = skb_shinfo(skb)->nr_frags; i > 0; i--) {
@@ -743,10 +742,40 @@ int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
 		head = (struct page *)head->private;
 	}
 
-	skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
 	return 0;
 }
 
+/*	skb_copy_ubufs	-	copy userspace skb frags buffers to kernel
+ *	@skb: the skb to modify
+ *	@gfp_mask: allocation priority
+ *
+ *	This must be called on SKBTX_DEV_ZEROCOPY skb.
+ *	It will copy all frags into kernel and drop the reference
+ *	to userspace pages.
+ *
+ *	If this function is called from an interrupt gfp_mask() must be
+ *	%GFP_ATOMIC.
+ *
+ *	Returns 0 on success or a negative error code on failure
+ *	to allocate kernel memory to copy to.
+ */
+int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
+{
+	struct ubuf_info *uarg = skb_shinfo(skb)->destructor_arg;
+	int rc;
+
+	rc = skb_copy_frags(skb, gfp_mask, uarg);
+
+	if (rc == 0)
+		skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
+
+	return rc;
+}
+
+int skb_orphan_frags(struct sk_buff *skb, gfp_t gfp_mask)
+{
+	return skb_copy_frags(skb, gfp_mask, NULL);
+}
 
 /**
  *	skb_clone	-	duplicate an sk_buff
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:42:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcH8-0002Yv-Sx; Tue, 10 Apr 2012 14:42:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcH8-0002Yo-Fo
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:42:30 +0000
Received: from [85.158.139.83:18172] by server-11.bemta-5.messagelabs.com id
	C4/0A-12959-5D6448F4; Tue, 10 Apr 2012 14:42:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334068947!18591805!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23787 invoked from network); 10 Apr 2012 14:42:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:42:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189660040"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:41:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:41:59 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcGc-0002K0-V7;
	Tue, 10 Apr 2012 15:41:59 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 15:41:56 +0100
Message-ID: <1334068916-1486-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: remove poller from list in
	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove poller from the list once it has been requested. To be merged with Ian
Jackson series.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
---
 tools/libxl/libxl_event.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index dcd5802..91b1bb1 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1050,8 +1050,10 @@ libxl__poller *libxl__poller_get(libxl_ctx *ctx)
     int rc;
 
     libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
-    if (p)
+    if (p) {
+        LIBXL_LIST_REMOVE(p, entry);
         return p;
+    }
 
     p = malloc(sizeof(*p));
     if (!p) {
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:42:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcH8-0002Yv-Sx; Tue, 10 Apr 2012 14:42:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcH8-0002Yo-Fo
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:42:30 +0000
Received: from [85.158.139.83:18172] by server-11.bemta-5.messagelabs.com id
	C4/0A-12959-5D6448F4; Tue, 10 Apr 2012 14:42:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334068947!18591805!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23787 invoked from network); 10 Apr 2012 14:42:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:42:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189660040"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:41:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:41:59 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcGc-0002K0-V7;
	Tue, 10 Apr 2012 15:41:59 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 15:41:56 +0100
Message-ID: <1334068916-1486-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: remove poller from list in
	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove poller from the list once it has been requested. To be merged with Ian
Jackson series.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
---
 tools/libxl/libxl_event.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index dcd5802..91b1bb1 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1050,8 +1050,10 @@ libxl__poller *libxl__poller_get(libxl_ctx *ctx)
     int rc;
 
     libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
-    if (p)
+    if (p) {
+        LIBXL_LIST_REMOVE(p, entry);
         return p;
+    }
 
     p = malloc(sizeof(*p));
     if (!p) {
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:46:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcKw-0002m1-Kq; Tue, 10 Apr 2012 14:46:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1SHcKv-0002ls-Ck
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:46:25 +0000
Received: from [85.158.143.99:23749] by server-2.bemta-4.messagelabs.com id
	AF/05-17550-0C7448F4; Tue, 10 Apr 2012 14:46:24 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334069183!24484449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8981 invoked from network); 10 Apr 2012 14:46:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11858892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 14:46:22 +0000
Received: from [10.80.3.59] (10.80.3.59) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 15:46:22 +0100
Message-ID: <4F84478A.5010701@citrix.com>
Date: Tue, 10 Apr 2012 15:45:30 +0100
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: Lin Ming <mlin@ss.pku.edu.cn>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
In-Reply-To: <CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/04/12 07:48, Lin Ming wrote:
>> 2. The PMU project description in the wiki is vague. I know HVM guests
>> support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
>> directories. You better ask mentors for details (maybe this is XCP
>> specific?).
Yes, the description is vague, we should update the page. The idea was 
to enable users to run hardware profilers in dom0 and in any domU, PV or 
HVM. This would include implementing what is missing for dom0/PV 
domains, and to confirm in HVM domains that profilers such as oprofile, 
hwpmc, intel performance counter monitor at least are running without 
problems in the existing vPMU implementation. The original idea was to 
add support to XCP, but please feel free to add support to xen-unstable 
and the latest linux kernel; XCP will use those at some point.
cheers,
Marcus



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:46:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcKw-0002m1-Kq; Tue, 10 Apr 2012 14:46:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1SHcKv-0002ls-Ck
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:46:25 +0000
Received: from [85.158.143.99:23749] by server-2.bemta-4.messagelabs.com id
	AF/05-17550-0C7448F4; Tue, 10 Apr 2012 14:46:24 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334069183!24484449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8981 invoked from network); 10 Apr 2012 14:46:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11858892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 14:46:22 +0000
Received: from [10.80.3.59] (10.80.3.59) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 15:46:22 +0100
Message-ID: <4F84478A.5010701@citrix.com>
Date: Tue, 10 Apr 2012 15:45:30 +0100
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: Lin Ming <mlin@ss.pku.edu.cn>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
In-Reply-To: <CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/04/12 07:48, Lin Ming wrote:
>> 2. The PMU project description in the wiki is vague. I know HVM guests
>> support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
>> directories. You better ask mentors for details (maybe this is XCP
>> specific?).
Yes, the description is vague, we should update the page. The idea was 
to enable users to run hardware profilers in dom0 and in any domU, PV or 
HVM. This would include implementing what is missing for dom0/PV 
domains, and to confirm in HVM domains that profilers such as oprofile, 
hwpmc, intel performance counter monitor at least are running without 
problems in the existing vPMU implementation. The original idea was to 
add support to XCP, but please feel free to add support to xen-unstable 
and the latest linux kernel; XCP will use those at some point.
cheers,
Marcus



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:53:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcRv-00030t-Ix; Tue, 10 Apr 2012 14:53:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SHcRt-00030n-Kw
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:53:37 +0000
Received: from [85.158.139.83:4193] by server-9.bemta-5.messagelabs.com id
	C2/F8-09826-079448F4; Tue, 10 Apr 2012 14:53:36 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334069614!11921014!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22301 invoked from network); 10 Apr 2012 14:53:35 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-8.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 14:53:35 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q3AErS3A019387;
	Tue, 10 Apr 2012 09:53:29 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q3AErS7i019386;
	Tue, 10 Apr 2012 09:53:28 -0500
Date: Tue, 10 Apr 2012 09:53:28 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204101453.q3AErS7i019386@wind.enjellic.com>
In-Reply-To: Tim Wood <twwood@gmail.com>
	"Re: [Xen-devel] where to find blktap2 kernel module" (Apr  9, 8:13am)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Tim Wood <twwood@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Tue, 10 Apr 2012 09:53:29 -0500 (CDT)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Apr 9,  8:13am, Tim Wood wrote:
} Subject: Re: [Xen-devel] where to find blktap2 kernel module

Hi, hope the day is going well for efveryone.

> --485b397dd775dd0da404bd3df0b5
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Sat, Apr 7, 2012 at 3:37 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
> 
> > On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:
> > > In xen 4.0.X I was able to write custom blktap2 drivers as a nice way
> > > to intercept VM disk traffic.  I'm now trying to take a step up to xen
> > > 4.1.2 and find that blktap2 doesn't seem to be supported anymore, or
> > > at least it requires a kernel module which I'm not sure where to
> > > find.  Is blktap2 still in use, or is there an entirely different way
> > > I should be approaching this?
> > >
> > >
> > > Previously I could run commands like:
> > >
> > >
> > > tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img
> > >
> > >
> > > the new tapdisk2 doesn't support that interface anymore,
> >
> > What do you mean? I don't think the tap interface has changed (but I'm
> > not sure). In any case I'm pretty sure the functionality should be there
> > even if the command line has changed.
> >
> 
> Sorry, I wasn't clear--the functionality is still there but the command
> line interface has changed.  The xm-block attach command below seems to be
> equivalent.
> 
> 
> >
> > >  but it seems like the correct approach is now:
> > >
> > >
> > > xm block-attach 0 tap2:aio:/path/disk.img xvda w 0
> > > Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
> > > module not installed )
> >
> > I think this ultimately turns into the same sort of command as the one
> > above.

The documentation in the Xen sources is out of date with respect to
userspace interfaces to blktap2.  The 'tap-ctl' command is the
simplest way to manage dom0 instances of block devices.  Its actually
a pretty well defined interface.

Here is a brief recipe:

1.) Allocate a blktap minor device:

	tap-ctl allocate

2.) Spawn a userspace driver:

	tap-ctl spawn

    The 'tap-ctl list' command is useful at this point in order to get
    the status of available devices and process numbers.  In the
    following commands substitue PPP with the PID of the userspace
    driver and MMM with the minor number of the device you are working
    with.

3.) Bind the userspace driver to a minor instance:

	tap-ctl attach -p PPP -m MMM

4.) Open a filesystem image with an appropriate driver.  In this case
    it is aio, if you are rolling your own subsitute the driver prefix
    (aio:) with the name of your driver.

	tap-ctl open -p PPP -m MMM aio:FNAME

    If this command succeeds you will see a hotplug/udev inventing
    indicating that a new block device was created.  The 'official'
    device node locations should be:

	/dev/xen/blktap-2/tapdevMMM

    Where MMM is replaced with the minor number of the block device.

5.) Close the filesystem image:

	tap-ctl close -p PPP -m MMM

6.) Detach the process from the allocated minor number:

	tap-ctl detach -p PPP -m MMM

7.) Free the minor number:

	tap-ctl free -m 0

> > > What is the "proper" way of getting the blktap kernel module
> > > installed?  I found this:
> > > http://packages.debian.org/sid/blktap-dkms
> >
> > Unfortunately the blktap2 module is not something which can be
> > upstreamed.
> >
> > The DKMS package is probably a good bet for now. The other alternative
> > is to switch to a slightly older kernel which has the blktap2 driver in
> > it, for example the 2.6.32 based xen.git kernel tree or one of the
> > classic Xen forward ports.

> OK, I will fiddle with DKMS a bit more or switch to 2.6.32.

We have a vested interest in all so in the interests of advancing this
technology we have clean kernel patches available at the following
locations:

	ftp://ftp.enjellic.com/pub/xen/blktap2-3.0.patch

	ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch

These are basically cleanups from the last available GIT tree which
Dan Stodden had made available.

There are minimal dependencies so they should drop into other kernels
without too much effort.  We are focusing on 3.0 and 3.2 since they
seem to be odds on favorites for 'stable' kernels.

> > You mentioned writing your own blktap modules so the qemu-supplied qdisk
> > backend is probably not much use to you. This is used by the "xl"
> > toolstack by default when blktap is not present, but isn't supported by
> > xm and doesn't allow for custom modules .
> >
> > I'm actually quite interested in the fact that you are writing custom
> > blktap modules -- are you able to share the details?

> Sure, I'm a CS professor and do research on what cool stuff you can
> add in the virtualization layer.  What I did before was a module
> similar to remus's, but designed for WAN replication and
> synchronizing across groups of VMs.  The paper can be a bit tough to
> get through, but it has some of the details:
>
> http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.pdf

Thanks for forwarding the reference.

> Blktap is a very handy way for us to prototype these types of
> features without having to muck through the core xen code.

Indeed, we are looking at it with respect to NPIV support.  QEMU is
difficult to deal with as it is.  It seems to be an architectural
advantage to have an independent block support architecture given what
people want to do with block devices these days.

blktap2 is a very useful architecture, it seems to suffer mainly from
a lack of attention.  Hopefully this can be improved a bit.

> > Long term someone is working on a "blktap3" which is fully userspace and
> > so doesn't require a kernel module. We hope to see this for 4.3. For 4.2
> > it looks like we'll be sticking with the qdisk backend.
> >
> > Sounds great, I look forward to it.

A pure userspace implementation would be obviously an advantage.  That
would seem to be a ways out however and if our observations are useful
it seems that moving user Xen implementations forward are suffering a
bit secondary to the number of things which change a bit from release
to release and make maintenance troublesome.

Hope the above is useful.

Good luck with your efforts.

Greg

}-- End of excerpt from Tim Wood

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"In the future, company names will be a 32-character hex string."
                                -- Bruce Schneier

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:53:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcRv-00030t-Ix; Tue, 10 Apr 2012 14:53:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SHcRt-00030n-Kw
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:53:37 +0000
Received: from [85.158.139.83:4193] by server-9.bemta-5.messagelabs.com id
	C2/F8-09826-079448F4; Tue, 10 Apr 2012 14:53:36 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334069614!11921014!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22301 invoked from network); 10 Apr 2012 14:53:35 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-8.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 14:53:35 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q3AErS3A019387;
	Tue, 10 Apr 2012 09:53:29 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q3AErS7i019386;
	Tue, 10 Apr 2012 09:53:28 -0500
Date: Tue, 10 Apr 2012 09:53:28 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204101453.q3AErS7i019386@wind.enjellic.com>
In-Reply-To: Tim Wood <twwood@gmail.com>
	"Re: [Xen-devel] where to find blktap2 kernel module" (Apr  9, 8:13am)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Tim Wood <twwood@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Tue, 10 Apr 2012 09:53:29 -0500 (CDT)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] where to find blktap2 kernel module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Apr 9,  8:13am, Tim Wood wrote:
} Subject: Re: [Xen-devel] where to find blktap2 kernel module

Hi, hope the day is going well for efveryone.

> --485b397dd775dd0da404bd3df0b5
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Sat, Apr 7, 2012 at 3:37 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
> 
> > On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:
> > > In xen 4.0.X I was able to write custom blktap2 drivers as a nice way
> > > to intercept VM disk traffic.  I'm now trying to take a step up to xen
> > > 4.1.2 and find that blktap2 doesn't seem to be supported anymore, or
> > > at least it requires a kernel module which I'm not sure where to
> > > find.  Is blktap2 still in use, or is there an entirely different way
> > > I should be approaching this?
> > >
> > >
> > > Previously I could run commands like:
> > >
> > >
> > > tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img
> > >
> > >
> > > the new tapdisk2 doesn't support that interface anymore,
> >
> > What do you mean? I don't think the tap interface has changed (but I'm
> > not sure). In any case I'm pretty sure the functionality should be there
> > even if the command line has changed.
> >
> 
> Sorry, I wasn't clear--the functionality is still there but the command
> line interface has changed.  The xm-block attach command below seems to be
> equivalent.
> 
> 
> >
> > >  but it seems like the correct approach is now:
> > >
> > >
> > > xm block-attach 0 tap2:aio:/path/disk.img xvda w 0
> > > Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
> > > module not installed )
> >
> > I think this ultimately turns into the same sort of command as the one
> > above.

The documentation in the Xen sources is out of date with respect to
userspace interfaces to blktap2.  The 'tap-ctl' command is the
simplest way to manage dom0 instances of block devices.  Its actually
a pretty well defined interface.

Here is a brief recipe:

1.) Allocate a blktap minor device:

	tap-ctl allocate

2.) Spawn a userspace driver:

	tap-ctl spawn

    The 'tap-ctl list' command is useful at this point in order to get
    the status of available devices and process numbers.  In the
    following commands substitue PPP with the PID of the userspace
    driver and MMM with the minor number of the device you are working
    with.

3.) Bind the userspace driver to a minor instance:

	tap-ctl attach -p PPP -m MMM

4.) Open a filesystem image with an appropriate driver.  In this case
    it is aio, if you are rolling your own subsitute the driver prefix
    (aio:) with the name of your driver.

	tap-ctl open -p PPP -m MMM aio:FNAME

    If this command succeeds you will see a hotplug/udev inventing
    indicating that a new block device was created.  The 'official'
    device node locations should be:

	/dev/xen/blktap-2/tapdevMMM

    Where MMM is replaced with the minor number of the block device.

5.) Close the filesystem image:

	tap-ctl close -p PPP -m MMM

6.) Detach the process from the allocated minor number:

	tap-ctl detach -p PPP -m MMM

7.) Free the minor number:

	tap-ctl free -m 0

> > > What is the "proper" way of getting the blktap kernel module
> > > installed?  I found this:
> > > http://packages.debian.org/sid/blktap-dkms
> >
> > Unfortunately the blktap2 module is not something which can be
> > upstreamed.
> >
> > The DKMS package is probably a good bet for now. The other alternative
> > is to switch to a slightly older kernel which has the blktap2 driver in
> > it, for example the 2.6.32 based xen.git kernel tree or one of the
> > classic Xen forward ports.

> OK, I will fiddle with DKMS a bit more or switch to 2.6.32.

We have a vested interest in all so in the interests of advancing this
technology we have clean kernel patches available at the following
locations:

	ftp://ftp.enjellic.com/pub/xen/blktap2-3.0.patch

	ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch

These are basically cleanups from the last available GIT tree which
Dan Stodden had made available.

There are minimal dependencies so they should drop into other kernels
without too much effort.  We are focusing on 3.0 and 3.2 since they
seem to be odds on favorites for 'stable' kernels.

> > You mentioned writing your own blktap modules so the qemu-supplied qdisk
> > backend is probably not much use to you. This is used by the "xl"
> > toolstack by default when blktap is not present, but isn't supported by
> > xm and doesn't allow for custom modules .
> >
> > I'm actually quite interested in the fact that you are writing custom
> > blktap modules -- are you able to share the details?

> Sure, I'm a CS professor and do research on what cool stuff you can
> add in the virtualization layer.  What I did before was a module
> similar to remus's, but designed for WAN replication and
> synchronizing across groups of VMs.  The paper can be a bit tough to
> get through, but it has some of the details:
>
> http://faculty.cs.gwu.edu/~timwood/papers/SOCC11-PipeCloud.pdf

Thanks for forwarding the reference.

> Blktap is a very handy way for us to prototype these types of
> features without having to muck through the core xen code.

Indeed, we are looking at it with respect to NPIV support.  QEMU is
difficult to deal with as it is.  It seems to be an architectural
advantage to have an independent block support architecture given what
people want to do with block devices these days.

blktap2 is a very useful architecture, it seems to suffer mainly from
a lack of attention.  Hopefully this can be improved a bit.

> > Long term someone is working on a "blktap3" which is fully userspace and
> > so doesn't require a kernel module. We hope to see this for 4.3. For 4.2
> > it looks like we'll be sticking with the qdisk backend.
> >
> > Sounds great, I look forward to it.

A pure userspace implementation would be obviously an advantage.  That
would seem to be a ways out however and if our observations are useful
it seems that moving user Xen implementations forward are suffering a
bit secondary to the number of things which change a bit from release
to release and make maintenance troublesome.

Hope the above is useful.

Good luck with your efforts.

Greg

}-- End of excerpt from Tim Wood

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"In the future, company names will be a 32-character hex string."
                                -- Bruce Schneier

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:58:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcVw-0003Dm-D5; Tue, 10 Apr 2012 14:57:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcVu-0003DZ-Oe
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:57:46 +0000
Received: from [85.158.138.51:9735] by server-6.bemta-3.messagelabs.com id
	56/B4-05145-96A448F4; Tue, 10 Apr 2012 14:57:45 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334069865!21566694!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31257 invoked from network); 10 Apr 2012 14:57:45 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:57:45 -0000
Received: by bkcjg9 with SMTP id jg9so4982693bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 07:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=7UCXR34TQe0siEh69RpJFbZ76RjQXtA2kkrY9qqzlPU=;
	b=T/6RSRCGc4zrxxGbiXiD9pJWWpAr/P9u7MFvVfi0/v7D+yoTiPMDB/zqkwcNygT9kH
	65P19UpHXAAFcc1xNvJ5LBeZ1DG99cnudD+3qNH7bbBXtUipMXgXWwQHtfyu1wVe/NsQ
	MJfLNRw9up5XdaATfQungTbrI00OqCr5oxn71qMCN3d+2FkmRJuLeFFc5f50Oi5QRrjg
	QHdfh9ggYZMstd3RHc5Pa5a3ZxomFLIMVrZ39+ek82fn5eSANlunbafeglrti6x++zQR
	sChA6Hp/R/Cy9KGSkynKRpC+gc8XfBraqrELkmNH18Y12uvekBr58D5qtwHx9ZB1uVzE
	iMqw==
Received: by 10.204.149.218 with SMTP id u26mr5066359bkv.82.1334069865019;
	Tue, 10 Apr 2012 07:57:45 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id z17sm36805653bkw.12.2012.04.10.07.57.42
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 07:57:43 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-1-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-1-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 16:57:41 +0200
Message-ID: <1334069861.5300.52.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 01/10] net: add and use SKB_ALLOCSIZE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> This gives the allocation size required for an skb containing X bytes of data
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  drivers/net/ethernet/broadcom/bnx2.c        |    7 +++----
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x.h |    3 +--
>  drivers/net/ethernet/broadcom/tg3.c         |    3 +--
>  include/linux/skbuff.h                      |   12 ++++++++++++
>  net/core/skbuff.c                           |    8 +-------
>  5 files changed, 18 insertions(+), 15 deletions(-)
> 

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:58:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcVw-0003Dm-D5; Tue, 10 Apr 2012 14:57:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcVu-0003DZ-Oe
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:57:46 +0000
Received: from [85.158.138.51:9735] by server-6.bemta-3.messagelabs.com id
	56/B4-05145-96A448F4; Tue, 10 Apr 2012 14:57:45 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334069865!21566694!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31257 invoked from network); 10 Apr 2012 14:57:45 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:57:45 -0000
Received: by bkcjg9 with SMTP id jg9so4982693bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 07:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=7UCXR34TQe0siEh69RpJFbZ76RjQXtA2kkrY9qqzlPU=;
	b=T/6RSRCGc4zrxxGbiXiD9pJWWpAr/P9u7MFvVfi0/v7D+yoTiPMDB/zqkwcNygT9kH
	65P19UpHXAAFcc1xNvJ5LBeZ1DG99cnudD+3qNH7bbBXtUipMXgXWwQHtfyu1wVe/NsQ
	MJfLNRw9up5XdaATfQungTbrI00OqCr5oxn71qMCN3d+2FkmRJuLeFFc5f50Oi5QRrjg
	QHdfh9ggYZMstd3RHc5Pa5a3ZxomFLIMVrZ39+ek82fn5eSANlunbafeglrti6x++zQR
	sChA6Hp/R/Cy9KGSkynKRpC+gc8XfBraqrELkmNH18Y12uvekBr58D5qtwHx9ZB1uVzE
	iMqw==
Received: by 10.204.149.218 with SMTP id u26mr5066359bkv.82.1334069865019;
	Tue, 10 Apr 2012 07:57:45 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id z17sm36805653bkw.12.2012.04.10.07.57.42
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 07:57:43 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-1-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-1-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 16:57:41 +0200
Message-ID: <1334069861.5300.52.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 01/10] net: add and use SKB_ALLOCSIZE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> This gives the allocation size required for an skb containing X bytes of data
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  drivers/net/ethernet/broadcom/bnx2.c        |    7 +++----
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x.h |    3 +--
>  drivers/net/ethernet/broadcom/tg3.c         |    3 +--
>  include/linux/skbuff.h                      |   12 ++++++++++++
>  net/core/skbuff.c                           |    8 +-------
>  5 files changed, 18 insertions(+), 15 deletions(-)
> 

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:58:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcWR-0003GO-Qt; Tue, 10 Apr 2012 14:58:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHcWQ-0003GC-Ma
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 14:58:18 +0000
Received: from [85.158.139.83:4351] by server-11.bemta-5.messagelabs.com id
	A5/6C-12959-98A448F4; Tue, 10 Apr 2012 14:58:17 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334069895!23193651!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG, SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7682 invoked from network); 10 Apr 2012 14:58:16 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 14:58:16 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 5C4F3DBC58;
	Tue, 10 Apr 2012 22:58:00 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Tue, 10 Apr 2012 22:57:18 +0800
Message-ID: <1334069838.5865.130.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Xiantao Zhang <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [RFC PATCH] xen: get correct nr_irqs_gsi value from
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

nr_irqs_gsi is set in probe_nr_irqs_gsi()
	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY;

gsi_top is set in mp_register_ioapic()
	gsi_top = gsi_cfg->gsi_end + 1;

mp_register_ioapic() calls io_apic_read, which don't have a Xen specific
version. Actually, io_apic_read() always return -1 on Xen Dom0 kernel.

So currently, nr_irqs_gsi is always wrong on Xen Dom0 kernel.

This patch gets the correct nr_irqs_gsi value from Xen hypervisor with a
hypercall.

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
--
 arch/x86/include/asm/io_apic.h  |    2 ++
 arch/x86/kernel/apic/io_apic.c  |    2 +-
 arch/x86/xen/setup.c            |    9 +++++++++
 include/xen/interface/physdev.h |    6 ++++++
 4 files changed, 18 insertions(+), 1 deletions(-)

(I will send xen hypervisor patch in another mail)

Here comes the detail story.

Xen Dom0 kernel panics with 3.4-rc1. I took the panics picture at
http://www.sendspace.com/file/12ob33

Bisected to below commit.

commit 73d63d038ee9f769f5e5b46792d227fe20e442c5
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date:   Mon Mar 12 11:36:33 2012 -0700

    x86/ioapic: Add register level checks to detect bogus io-apic entries

But this commit itself has no problem.
This commit just triggers the panic.

The panic happens at xen_irq_init(..)

pci_enable_device
__pci_enable_device_flags
do_pci_enable_device
pcibios_enable_device
acpi_pci_irq_enable
acpi_register_gsi
acpi_register_gsi_xen
xen_register_gsi
xen_register_pirq
xen_bind_pirq_gsi_to_irq
xen_allocate_irq_gsi:
        irq = irq_alloc_desc_at(gsi, -1);
        xen_irq_init(irq);

On my machine, when enable PCI root port, gsi 16 is passed into
irq_alloc_desc_at, but it returns -17(-EEXIST) because irq 16 was
already took by xen timer(see below). Then negative value -17 is passed
into xen_irq_init --> irq_to_desc --> radix_tree_lookup, which causes
the panic.

xen timer allocates the irq number "nr_irqs_gsi"
nr_irqs_gsi is set in probe_nr_irqs_gsi()
	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY
gsi_top is set in mp_register_ioapic()
	gsi_top = gsi_cfg->gsi_end + 1;

In 3.4-rc1 kernel:

mp_register_ioapic
  bad_ioapic_register (added in 3.4-rc1)
    <always return true(bad) on Xen Dom0 kernel>

So mp_register_ioapic exist and gsi_top was not set up. It is left as
the initialized value(zero). So nr_irqs_gsi is 16(NR_IRQS_LEGACY).
That's why Xen timer allocated irq 16.


Actually, gsi_top was never setup correctly in mp_register_ioapic on Xen
Dom0 kernel. Because mp_register_ioapic calls io_apic_read, which is not
implemented with hypercall in Linux kernel. So io_apic_read() always
return -1 on Xen Dom0 kernel.

For 3.3 kernel in Xen Dom0, the dmesg shows

IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255
......
nr_irqs_gsi: 272

This is obviously wrong, "255" is actually -1(0xFFFF).


diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 2c4943d..a8bf3b2 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -115,6 +115,8 @@ struct IR_IO_APIC_route_entry {
  */
 extern int nr_ioapics;
 
+extern int nr_irqs_gsi;
+
 extern int mpc_ioapic_id(int ioapic);
 extern unsigned int mpc_ioapic_addr(int ioapic);
 extern struct mp_ioapic_gsi *mp_ioapic_gsi_routing(int ioapic);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e88300d..8bff292 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -140,7 +140,7 @@ struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
 int mp_irq_entries;
 
 /* GSI interrupts */
-static int nr_irqs_gsi = NR_IRQS_LEGACY;
+int nr_irqs_gsi = NR_IRQS_LEGACY;
 
 #if defined (CONFIG_MCA) || defined (CONFIG_EISA)
 int mp_bus_id_to_type[MAX_MP_BUSSES];
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 1ba8dff..9ce82bc 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -389,6 +389,9 @@ void __cpuinit xen_enable_syscall(void)
 
 void __init xen_arch_setup(void)
 {
+	struct physdev_nr_irqs_gsi irqs_gsi;
+	int rc;
+
 	xen_panic_handler_init();
 
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
@@ -424,4 +427,10 @@ void __init xen_arch_setup(void)
 	disable_cpufreq();
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
+
+	rc = HYPERVISOR_physdev_op(PHYSDEVOP_nr_irqs_gsi, &irqs_gsi);
+	if (rc)
+		printk(KERN_ERR "Failed to init nr_irqs_gsi, err_code:%d\n", rc);
+	else
+		nr_irqs_gsi = irqs_gsi.nr_irqs_gsi;
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..180a0a3 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,12 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_nr_irqs_gsi           29
+struct physdev_nr_irqs_gsi {
+    /* OUT */
+    uint32_t nr_irqs_gsi;
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:58:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcWR-0003GO-Qt; Tue, 10 Apr 2012 14:58:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHcWQ-0003GC-Ma
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 14:58:18 +0000
Received: from [85.158.139.83:4351] by server-11.bemta-5.messagelabs.com id
	A5/6C-12959-98A448F4; Tue, 10 Apr 2012 14:58:17 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334069895!23193651!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG, SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7682 invoked from network); 10 Apr 2012 14:58:16 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 14:58:16 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 5C4F3DBC58;
	Tue, 10 Apr 2012 22:58:00 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Tue, 10 Apr 2012 22:57:18 +0800
Message-ID: <1334069838.5865.130.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Xiantao Zhang <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [RFC PATCH] xen: get correct nr_irqs_gsi value from
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

nr_irqs_gsi is set in probe_nr_irqs_gsi()
	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY;

gsi_top is set in mp_register_ioapic()
	gsi_top = gsi_cfg->gsi_end + 1;

mp_register_ioapic() calls io_apic_read, which don't have a Xen specific
version. Actually, io_apic_read() always return -1 on Xen Dom0 kernel.

So currently, nr_irqs_gsi is always wrong on Xen Dom0 kernel.

This patch gets the correct nr_irqs_gsi value from Xen hypervisor with a
hypercall.

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
--
 arch/x86/include/asm/io_apic.h  |    2 ++
 arch/x86/kernel/apic/io_apic.c  |    2 +-
 arch/x86/xen/setup.c            |    9 +++++++++
 include/xen/interface/physdev.h |    6 ++++++
 4 files changed, 18 insertions(+), 1 deletions(-)

(I will send xen hypervisor patch in another mail)

Here comes the detail story.

Xen Dom0 kernel panics with 3.4-rc1. I took the panics picture at
http://www.sendspace.com/file/12ob33

Bisected to below commit.

commit 73d63d038ee9f769f5e5b46792d227fe20e442c5
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date:   Mon Mar 12 11:36:33 2012 -0700

    x86/ioapic: Add register level checks to detect bogus io-apic entries

But this commit itself has no problem.
This commit just triggers the panic.

The panic happens at xen_irq_init(..)

pci_enable_device
__pci_enable_device_flags
do_pci_enable_device
pcibios_enable_device
acpi_pci_irq_enable
acpi_register_gsi
acpi_register_gsi_xen
xen_register_gsi
xen_register_pirq
xen_bind_pirq_gsi_to_irq
xen_allocate_irq_gsi:
        irq = irq_alloc_desc_at(gsi, -1);
        xen_irq_init(irq);

On my machine, when enable PCI root port, gsi 16 is passed into
irq_alloc_desc_at, but it returns -17(-EEXIST) because irq 16 was
already took by xen timer(see below). Then negative value -17 is passed
into xen_irq_init --> irq_to_desc --> radix_tree_lookup, which causes
the panic.

xen timer allocates the irq number "nr_irqs_gsi"
nr_irqs_gsi is set in probe_nr_irqs_gsi()
	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY
gsi_top is set in mp_register_ioapic()
	gsi_top = gsi_cfg->gsi_end + 1;

In 3.4-rc1 kernel:

mp_register_ioapic
  bad_ioapic_register (added in 3.4-rc1)
    <always return true(bad) on Xen Dom0 kernel>

So mp_register_ioapic exist and gsi_top was not set up. It is left as
the initialized value(zero). So nr_irqs_gsi is 16(NR_IRQS_LEGACY).
That's why Xen timer allocated irq 16.


Actually, gsi_top was never setup correctly in mp_register_ioapic on Xen
Dom0 kernel. Because mp_register_ioapic calls io_apic_read, which is not
implemented with hypercall in Linux kernel. So io_apic_read() always
return -1 on Xen Dom0 kernel.

For 3.3 kernel in Xen Dom0, the dmesg shows

IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255
......
nr_irqs_gsi: 272

This is obviously wrong, "255" is actually -1(0xFFFF).


diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 2c4943d..a8bf3b2 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -115,6 +115,8 @@ struct IR_IO_APIC_route_entry {
  */
 extern int nr_ioapics;
 
+extern int nr_irqs_gsi;
+
 extern int mpc_ioapic_id(int ioapic);
 extern unsigned int mpc_ioapic_addr(int ioapic);
 extern struct mp_ioapic_gsi *mp_ioapic_gsi_routing(int ioapic);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e88300d..8bff292 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -140,7 +140,7 @@ struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
 int mp_irq_entries;
 
 /* GSI interrupts */
-static int nr_irqs_gsi = NR_IRQS_LEGACY;
+int nr_irqs_gsi = NR_IRQS_LEGACY;
 
 #if defined (CONFIG_MCA) || defined (CONFIG_EISA)
 int mp_bus_id_to_type[MAX_MP_BUSSES];
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 1ba8dff..9ce82bc 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -389,6 +389,9 @@ void __cpuinit xen_enable_syscall(void)
 
 void __init xen_arch_setup(void)
 {
+	struct physdev_nr_irqs_gsi irqs_gsi;
+	int rc;
+
 	xen_panic_handler_init();
 
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
@@ -424,4 +427,10 @@ void __init xen_arch_setup(void)
 	disable_cpufreq();
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
+
+	rc = HYPERVISOR_physdev_op(PHYSDEVOP_nr_irqs_gsi, &irqs_gsi);
+	if (rc)
+		printk(KERN_ERR "Failed to init nr_irqs_gsi, err_code:%d\n", rc);
+	else
+		nr_irqs_gsi = irqs_gsi.nr_irqs_gsi;
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..180a0a3 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,12 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_nr_irqs_gsi           29
+struct physdev_nr_irqs_gsi {
+    /* OUT */
+    uint32_t nr_irqs_gsi;
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:58:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcWr-0003Jv-7Y; Tue, 10 Apr 2012 14:58:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SHcWp-0003Ja-8z
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:58:43 +0000
Received: from [85.158.138.51:53021] by server-5.bemta-3.messagelabs.com id
	60/39-17113-2AA448F4; Tue, 10 Apr 2012 14:58:42 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334069921!21543805!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIyOTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30652 invoked from network); 10 Apr 2012 14:58:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 14:58:41 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3AEwZR7011920
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Apr 2012 10:58:35 -0400
Received: from redhat.com (reserved-201-240.tlv.redhat.com [10.35.201.240]
	(may be forged))
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q3AEwVZQ001447; Tue, 10 Apr 2012 10:58:32 -0400
Date: Tue, 10 Apr 2012 17:58:47 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120410145845.GF19556@redhat.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Wei Liu <wei.liu2@citrix.com>, Bart Van Assche <bvanassche@acm.org>,
	Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:26:05PM +0100, Ian Campbell wrote:
>               * I can't for the life of me get anything to actually hit
>                 this code path. I've been trying with an NFS server
>                 running in a Xen HVM domain with emulated (e.g. tap)
>                 networking and a client in domain 0, using the NFS fix
>                 in this series which generates SKBs with destructors
>                 set, so far -- nothing. I suspect that lack of TSO/GSO
>                 etc on the TAP interface is causing the frags to be
>                 copied to normal pages during skb_segment().

To enable gso you need to call TUNSETOFFLOAD.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:58:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcWr-0003Jv-7Y; Tue, 10 Apr 2012 14:58:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SHcWp-0003Ja-8z
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:58:43 +0000
Received: from [85.158.138.51:53021] by server-5.bemta-3.messagelabs.com id
	60/39-17113-2AA448F4; Tue, 10 Apr 2012 14:58:42 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334069921!21543805!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIyOTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30652 invoked from network); 10 Apr 2012 14:58:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 14:58:41 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3AEwZR7011920
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Apr 2012 10:58:35 -0400
Received: from redhat.com (reserved-201-240.tlv.redhat.com [10.35.201.240]
	(may be forged))
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q3AEwVZQ001447; Tue, 10 Apr 2012 10:58:32 -0400
Date: Tue, 10 Apr 2012 17:58:47 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120410145845.GF19556@redhat.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Wei Liu <wei.liu2@citrix.com>, Bart Van Assche <bvanassche@acm.org>,
	Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:26:05PM +0100, Ian Campbell wrote:
>               * I can't for the life of me get anything to actually hit
>                 this code path. I've been trying with an NFS server
>                 running in a Xen HVM domain with emulated (e.g. tap)
>                 networking and a client in domain 0, using the NFS fix
>                 in this series which generates SKBs with destructors
>                 set, so far -- nothing. I suspect that lack of TSO/GSO
>                 etc on the TAP interface is causing the frags to be
>                 copied to normal pages during skb_segment().

To enable gso you need to call TUNSETOFFLOAD.

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcWz-0003Ll-KV; Tue, 10 Apr 2012 14:58:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcWx-0003Kr-CV
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:58:51 +0000
Received: from [85.158.143.99:49403] by server-1.bemta-4.messagelabs.com id
	81/10-20925-AAA448F4; Tue, 10 Apr 2012 14:58:50 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334069922!22471351!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 990 invoked from network); 10 Apr 2012 14:58:43 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:58:43 -0000
Received: by bkcjg9 with SMTP id jg9so4983789bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 07:58:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=wFNW3T8a/NwC3YtOuxT9W+wKMIKKrDqmVvyS+Ie/Wrk=;
	b=QjCqu0joGMrVUIlJeUe7v6K/V3rW2VAj7YlAI7mQ2yNBZXq/lYjd2YCyLcla1SSy0T
	tX9L1XLghyRAv1ancUXAeZNEbQ5tTXxslqsaR/vNTXMg0aOGS2PnKl0imvFNRqTPpx3b
	DWBgMKnbhx8QRvWG6Qe3k8iwm3iO5HvVdoPDFdpg7+K7WTMwnJNfXUwlpghEZpG2XTp6
	61eMWChH4XW814hy/1F/CASqkyhdCQmrW7X+EJzlq2EA8nKVBQuhKA1EtnUXN2q6ydZR
	vXmg5992G2UcWeUmvPWd2/J6YTdz2bkn9KvzC9Pl9c66XA7+Cs5W6v4uOvvM3GM45ovm
	4oZg==
Received: by 10.205.139.77 with SMTP id iv13mr4763642bkc.91.1334069921402;
	Tue, 10 Apr 2012 07:58:41 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id s16sm36844739bkt.3.2012.04.10.07.58.38
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 07:58:40 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-2-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-2-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 16:58:36 +0200
Message-ID: <1334069916.5300.54.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 02/10] net: Use SKB_WITH_OVERHEAD in
	build_skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  net/core/skbuff.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 59a1ecb..d4e139e 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -264,7 +264,7 @@ struct sk_buff *build_skb(void *data)
>  	if (!skb)
>  		return NULL;
>  
> -	size = ksize(data) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> +	size = SKB_WITH_OVERHEAD(ksize(data));
>  
>  	memset(skb, 0, offsetof(struct sk_buff, tail));
>  	skb->truesize = SKB_TRUESIZE(size);

Well, why not ;)

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 14:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 14:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcWz-0003Ll-KV; Tue, 10 Apr 2012 14:58:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcWx-0003Kr-CV
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:58:51 +0000
Received: from [85.158.143.99:49403] by server-1.bemta-4.messagelabs.com id
	81/10-20925-AAA448F4; Tue, 10 Apr 2012 14:58:50 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334069922!22471351!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 990 invoked from network); 10 Apr 2012 14:58:43 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:58:43 -0000
Received: by bkcjg9 with SMTP id jg9so4983789bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 07:58:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=wFNW3T8a/NwC3YtOuxT9W+wKMIKKrDqmVvyS+Ie/Wrk=;
	b=QjCqu0joGMrVUIlJeUe7v6K/V3rW2VAj7YlAI7mQ2yNBZXq/lYjd2YCyLcla1SSy0T
	tX9L1XLghyRAv1ancUXAeZNEbQ5tTXxslqsaR/vNTXMg0aOGS2PnKl0imvFNRqTPpx3b
	DWBgMKnbhx8QRvWG6Qe3k8iwm3iO5HvVdoPDFdpg7+K7WTMwnJNfXUwlpghEZpG2XTp6
	61eMWChH4XW814hy/1F/CASqkyhdCQmrW7X+EJzlq2EA8nKVBQuhKA1EtnUXN2q6ydZR
	vXmg5992G2UcWeUmvPWd2/J6YTdz2bkn9KvzC9Pl9c66XA7+Cs5W6v4uOvvM3GM45ovm
	4oZg==
Received: by 10.205.139.77 with SMTP id iv13mr4763642bkc.91.1334069921402;
	Tue, 10 Apr 2012 07:58:41 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id s16sm36844739bkt.3.2012.04.10.07.58.38
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 07:58:40 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-2-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-2-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 16:58:36 +0200
Message-ID: <1334069916.5300.54.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 02/10] net: Use SKB_WITH_OVERHEAD in
	build_skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  net/core/skbuff.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 59a1ecb..d4e139e 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -264,7 +264,7 @@ struct sk_buff *build_skb(void *data)
>  	if (!skb)
>  		return NULL;
>  
> -	size = ksize(data) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> +	size = SKB_WITH_OVERHEAD(ksize(data));
>  
>  	memset(skb, 0, offsetof(struct sk_buff, tail));
>  	skb->truesize = SKB_TRUESIZE(size);

Well, why not ;)

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcXw-0003Wj-2m; Tue, 10 Apr 2012 14:59:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcXv-0003WS-8S
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:59:51 +0000
Received: from [85.158.143.35:10162] by server-2.bemta-4.messagelabs.com id
	B1/C9-17550-6EA448F4; Tue, 10 Apr 2012 14:59:50 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334069989!4199467!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19865 invoked from network); 10 Apr 2012 14:59:49 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:59:49 -0000
Received: by bkcjg9 with SMTP id jg9so4985134bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 07:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=It2WPF94WgnKtG02OZsQSJqUqE+p0DJZ30lb7CG0Bfg=;
	b=WaZ6D0GFMpxaYhCdzkoWH7sbpwkqpJKliIGVRfWU5CZYnaogQ3OhhGnew9mBaL0Zz5
	yz0xdh4hO5qQKw37cTbRNz9FdGdLEgAIeiIpBYiIdFYmG5yzwu/E2g771JwLgo7HE4Bg
	WzcJr80OTHJMgXZmVYOHCD1ESdwg4dsFAyoYgqFObTLul1rVrc58jsoG2JxsiaYkf73v
	e8Cu4g7OKZQVFEi3MayyOY/t7zNSLeZ4DT2ubAyDIpbOa68N027hbWd2MrZuJb2wFTZS
	LTIRQHmalXfUVhmBAEMoVyTc/h4WBwvO1UtYagD86PtXVIrEvKC8bNLItQskNObFQhag
	L05w==
Received: by 10.204.154.2 with SMTP id m2mr4749383bkw.110.1334069989108;
	Tue, 10 Apr 2012 07:59:49 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id f5sm36831179bke.9.2012.04.10.07.59.45
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 07:59:47 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-3-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-3-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 16:59:43 +0200
Message-ID: <1334069983.5300.56.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Wei Liu <wei.liu2@citrix.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	netdev@vger.kernel.org, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>, Divy Le Ray <divy@chelsio.com>
Subject: Re: [Xen-devel] [PATCH 03/10] chelsio: use SKB_WITH_OVERHEAD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Divy Le Ray <divy@chelsio.com>
> ---
>  drivers/net/ethernet/chelsio/cxgb/sge.c  |    3 +--
>  drivers/net/ethernet/chelsio/cxgb3/sge.c |    6 +++---
>  2 files changed, 4 insertions(+), 5 deletions(-)
> 
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcXw-0003Wj-2m; Tue, 10 Apr 2012 14:59:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcXv-0003WS-8S
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:59:51 +0000
Received: from [85.158.143.35:10162] by server-2.bemta-4.messagelabs.com id
	B1/C9-17550-6EA448F4; Tue, 10 Apr 2012 14:59:50 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334069989!4199467!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19865 invoked from network); 10 Apr 2012 14:59:49 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:59:49 -0000
Received: by bkcjg9 with SMTP id jg9so4985134bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 07:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=It2WPF94WgnKtG02OZsQSJqUqE+p0DJZ30lb7CG0Bfg=;
	b=WaZ6D0GFMpxaYhCdzkoWH7sbpwkqpJKliIGVRfWU5CZYnaogQ3OhhGnew9mBaL0Zz5
	yz0xdh4hO5qQKw37cTbRNz9FdGdLEgAIeiIpBYiIdFYmG5yzwu/E2g771JwLgo7HE4Bg
	WzcJr80OTHJMgXZmVYOHCD1ESdwg4dsFAyoYgqFObTLul1rVrc58jsoG2JxsiaYkf73v
	e8Cu4g7OKZQVFEi3MayyOY/t7zNSLeZ4DT2ubAyDIpbOa68N027hbWd2MrZuJb2wFTZS
	LTIRQHmalXfUVhmBAEMoVyTc/h4WBwvO1UtYagD86PtXVIrEvKC8bNLItQskNObFQhag
	L05w==
Received: by 10.204.154.2 with SMTP id m2mr4749383bkw.110.1334069989108;
	Tue, 10 Apr 2012 07:59:49 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id f5sm36831179bke.9.2012.04.10.07.59.45
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 07:59:47 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-3-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-3-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 16:59:43 +0200
Message-ID: <1334069983.5300.56.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Wei Liu <wei.liu2@citrix.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	netdev@vger.kernel.org, xen-devel@lists.xen.org,
	David Miller <davem@davemloft.net>, Divy Le Ray <divy@chelsio.com>
Subject: Re: [Xen-devel] [PATCH 03/10] chelsio: use SKB_WITH_OVERHEAD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Divy Le Ray <divy@chelsio.com>
> ---
>  drivers/net/ethernet/chelsio/cxgb/sge.c  |    3 +--
>  drivers/net/ethernet/chelsio/cxgb3/sge.c |    6 +++---
>  2 files changed, 4 insertions(+), 5 deletions(-)
> 
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:00:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcYu-0003in-Id; Tue, 10 Apr 2012 15:00:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SHcYt-0003iF-Ge
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:00:51 +0000
Received: from [85.158.138.51:57067] by server-1.bemta-3.messagelabs.com id
	3A/7A-11491-12B448F4; Tue, 10 Apr 2012 15:00:49 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334070048!21521939!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIyOTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19475 invoked from network); 10 Apr 2012 15:00:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 15:00:48 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3AF0UDL011686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Apr 2012 11:00:43 -0400
Received: from redhat.com (reserved-201-240.tlv.redhat.com [10.35.201.240]
	(may be forged))
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q3AF0QVe013315; Tue, 10 Apr 2012 11:00:27 -0400
Date: Tue, 10 Apr 2012 18:00:42 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120410150040.GG19556@redhat.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Wei Liu <wei.liu2@citrix.com>, Bart Van Assche <bvanassche@acm.org>,
	Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:26:05PM +0100, Ian Campbell wrote:
> I think this is v4, but I've sort of lost count, sorry that it's taken
> me so long to get back to this stuff.
> 
> The following series makes use of the skb fragment API (which is in 3.2
> +) to add a per-paged-fragment destructor callback. This can be used by
> creators of skbs who are interested in the lifecycle of the pages
> included in that skb after they have handed it off to the network stack.
> 
> The mail at [0] contains some more background and rationale but
> basically the completed series will allow entities which inject pages
> into the networking stack to receive a notification when the stack has
> really finished with those pages (i.e. including retransmissions,
> clones, pull-ups etc) and not just when the original skb is finished
> with, which is beneficial to many subsystems which wish to inject pages
> into the network stack without giving up full ownership of those page's
> lifecycle. It implements something broadly along the lines of what was
> described in [1].
> 
> I have also included a patch to the RPC subsystem which uses this API to
> fix the bug which I describe at [2].
> 
> I've also had some interest from David VemLehn and Bart Van Assche
> regarding using this functionality in the context of vmsplice and iSCSI
> targets respectively (I think).
> 
> Changes since last time:
> 
>       * Added skb_orphan_frags API for the use of recipients of SKBs who
>         may hold onto the SKB for a long time (this is analogous to
>         skb_orphan). This was pointed out by Michael. The TUN driver is
>         currently the only user.
>               * I can't for the life of me get anything to actually hit
>                 this code path. I've been trying with an NFS server
>                 running in a Xen HVM domain with emulated (e.g. tap)
>                 networking and a client in domain 0, using the NFS fix
>                 in this series which generates SKBs with destructors
>                 set, so far -- nothing. I suspect that lack of TSO/GSO
>                 etc on the TAP interface is causing the frags to be
>                 copied to normal pages during skb_segment().

Will take a look tomorrow, thanks!

>       * Various fixups related to the change of alignment/padding in
>         shinfo, in particular to build_skb as pointed out by Eric.
>       * Tweaked ordering of shinfo members to ensure that all hotpath
>         variables up to and including the first frag fit within (and are
>         aligned to) a single 64 byte cache line. (Eric again)
> 
> I ran a monothread UDP benchmark (similar to that described by Eric in
> e52fcb2462ac) and don't see any difference in pps throughput, it was
> ~810,000 pps both before and after.
> 
> Cheers,
> Ian.
> 
> [0] http://marc.info/?l=linux-netdev&m=131072801125521&w=2
> [1] http://marc.info/?l=linux-netdev&m=130925719513084&w=2
> [2] http://marc.info/?l=linux-nfs&m=122424132729720&w=2
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:00:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcYu-0003in-Id; Tue, 10 Apr 2012 15:00:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SHcYt-0003iF-Ge
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:00:51 +0000
Received: from [85.158.138.51:57067] by server-1.bemta-3.messagelabs.com id
	3A/7A-11491-12B448F4; Tue, 10 Apr 2012 15:00:49 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334070048!21521939!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIyOTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19475 invoked from network); 10 Apr 2012 15:00:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 15:00:48 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3AF0UDL011686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Apr 2012 11:00:43 -0400
Received: from redhat.com (reserved-201-240.tlv.redhat.com [10.35.201.240]
	(may be forged))
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q3AF0QVe013315; Tue, 10 Apr 2012 11:00:27 -0400
Date: Tue, 10 Apr 2012 18:00:42 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120410150040.GG19556@redhat.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Wei Liu <wei.liu2@citrix.com>, Bart Van Assche <bvanassche@acm.org>,
	Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:26:05PM +0100, Ian Campbell wrote:
> I think this is v4, but I've sort of lost count, sorry that it's taken
> me so long to get back to this stuff.
> 
> The following series makes use of the skb fragment API (which is in 3.2
> +) to add a per-paged-fragment destructor callback. This can be used by
> creators of skbs who are interested in the lifecycle of the pages
> included in that skb after they have handed it off to the network stack.
> 
> The mail at [0] contains some more background and rationale but
> basically the completed series will allow entities which inject pages
> into the networking stack to receive a notification when the stack has
> really finished with those pages (i.e. including retransmissions,
> clones, pull-ups etc) and not just when the original skb is finished
> with, which is beneficial to many subsystems which wish to inject pages
> into the network stack without giving up full ownership of those page's
> lifecycle. It implements something broadly along the lines of what was
> described in [1].
> 
> I have also included a patch to the RPC subsystem which uses this API to
> fix the bug which I describe at [2].
> 
> I've also had some interest from David VemLehn and Bart Van Assche
> regarding using this functionality in the context of vmsplice and iSCSI
> targets respectively (I think).
> 
> Changes since last time:
> 
>       * Added skb_orphan_frags API for the use of recipients of SKBs who
>         may hold onto the SKB for a long time (this is analogous to
>         skb_orphan). This was pointed out by Michael. The TUN driver is
>         currently the only user.
>               * I can't for the life of me get anything to actually hit
>                 this code path. I've been trying with an NFS server
>                 running in a Xen HVM domain with emulated (e.g. tap)
>                 networking and a client in domain 0, using the NFS fix
>                 in this series which generates SKBs with destructors
>                 set, so far -- nothing. I suspect that lack of TSO/GSO
>                 etc on the TAP interface is causing the frags to be
>                 copied to normal pages during skb_segment().

Will take a look tomorrow, thanks!

>       * Various fixups related to the change of alignment/padding in
>         shinfo, in particular to build_skb as pointed out by Eric.
>       * Tweaked ordering of shinfo members to ensure that all hotpath
>         variables up to and including the first frag fit within (and are
>         aligned to) a single 64 byte cache line. (Eric again)
> 
> I ran a monothread UDP benchmark (similar to that described by Eric in
> e52fcb2462ac) and don't see any difference in pps throughput, it was
> ~810,000 pps both before and after.
> 
> Cheers,
> Ian.
> 
> [0] http://marc.info/?l=linux-netdev&m=131072801125521&w=2
> [1] http://marc.info/?l=linux-netdev&m=130925719513084&w=2
> [2] http://marc.info/?l=linux-nfs&m=122424132729720&w=2
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:02:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcaZ-0003y5-3p; Tue, 10 Apr 2012 15:02:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcaX-0003xh-Aa
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:02:33 +0000
Received: from [85.158.139.83:11203] by server-10.bemta-5.messagelabs.com id
	7E/1E-08260-88B448F4; Tue, 10 Apr 2012 15:02:32 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334070099!15843950!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18679 invoked from network); 10 Apr 2012 15:01:39 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:01:39 -0000
Received: by bkcjg9 with SMTP id jg9so4987243bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 08:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=7QGr73jRkqM705W8OE8zhHd0mCL7oIG+CivbrrhFVzY=;
	b=ImXKBSG2kt8Et5xeuXq4FCE/cKXNpq9TTWqxtGpOffJkMwE80OUvNR1cCLcWtfXl7G
	GKfCwEOHp4fE1Oq1rgr5ohn46HN8JnSRY/vRe8ZY7vXaP/ZqodEVYsde9wJYiJKpN2Ou
	jSxn1gL7qMeKIlZ0YXZkpnQiZlUiA2RpTpnE84auxSUuFACeU+T7XN6kxSnj5fDYMBvM
	gPyVOIhN+JKmmJqNdswZwfBjgoX4VCTrQMJ1Mekbq8cJBuSpjJCfO5DGhfLukdo4EOGi
	/1CCVanRSdRtxRGKUs4lqEIblbSDdjaKGnEr9uNyHXEreNQesyap6A0+Y4mgNBbCdTY7
	L1hg==
Received: by 10.204.148.89 with SMTP id o25mr4839038bkv.52.1334070098946;
	Tue, 10 Apr 2012 08:01:38 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id r14sm36835064bkv.11.2012.04.10.08.01.31
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 08:01:33 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-4-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-4-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 17:01:30 +0200
Message-ID: <1334070090.5300.59.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 04/10] net: pad skb data and shinfo as a
 whole rather than individually
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> This reduces the minimum overhead required for this allocation such that the
> shinfo can be grown in the following patch without overflowing 2048 bytes for a
> 1500 byte frame.
> 
> Reducing this overhead while also growing the shinfo means that sometimes the
> tail end of the data can end up in the same cache line as the beginning of the
> shinfo. Specifically in the case of the 64 byte cache lines on a 64 bit system
> the first 8 bytes of shinfo can overlap the tail cacheline of the data. In many
> cases the allocation slop means that there is no overlap.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> ---

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:02:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcaZ-0003y5-3p; Tue, 10 Apr 2012 15:02:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcaX-0003xh-Aa
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:02:33 +0000
Received: from [85.158.139.83:11203] by server-10.bemta-5.messagelabs.com id
	7E/1E-08260-88B448F4; Tue, 10 Apr 2012 15:02:32 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334070099!15843950!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18679 invoked from network); 10 Apr 2012 15:01:39 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:01:39 -0000
Received: by bkcjg9 with SMTP id jg9so4987243bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 08:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=7QGr73jRkqM705W8OE8zhHd0mCL7oIG+CivbrrhFVzY=;
	b=ImXKBSG2kt8Et5xeuXq4FCE/cKXNpq9TTWqxtGpOffJkMwE80OUvNR1cCLcWtfXl7G
	GKfCwEOHp4fE1Oq1rgr5ohn46HN8JnSRY/vRe8ZY7vXaP/ZqodEVYsde9wJYiJKpN2Ou
	jSxn1gL7qMeKIlZ0YXZkpnQiZlUiA2RpTpnE84auxSUuFACeU+T7XN6kxSnj5fDYMBvM
	gPyVOIhN+JKmmJqNdswZwfBjgoX4VCTrQMJ1Mekbq8cJBuSpjJCfO5DGhfLukdo4EOGi
	/1CCVanRSdRtxRGKUs4lqEIblbSDdjaKGnEr9uNyHXEreNQesyap6A0+Y4mgNBbCdTY7
	L1hg==
Received: by 10.204.148.89 with SMTP id o25mr4839038bkv.52.1334070098946;
	Tue, 10 Apr 2012 08:01:38 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id r14sm36835064bkv.11.2012.04.10.08.01.31
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 08:01:33 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-4-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-4-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 17:01:30 +0200
Message-ID: <1334070090.5300.59.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 04/10] net: pad skb data and shinfo as a
 whole rather than individually
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> This reduces the minimum overhead required for this allocation such that the
> shinfo can be grown in the following patch without overflowing 2048 bytes for a
> 1500 byte frame.
> 
> Reducing this overhead while also growing the shinfo means that sometimes the
> tail end of the data can end up in the same cache line as the beginning of the
> shinfo. Specifically in the case of the 64 byte cache lines on a 64 bit system
> the first 8 bytes of shinfo can overlap the tail cacheline of the data. In many
> cases the allocation slop means that there is no overlap.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> ---

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcdJ-0004Gk-Su; Tue, 10 Apr 2012 15:05:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcdI-0004GY-CO
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:05:24 +0000
Received: from [85.158.143.35:48796] by server-1.bemta-4.messagelabs.com id
	2C/EB-20925-33C448F4; Tue, 10 Apr 2012 15:05:23 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334070307!6434654!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19836 invoked from network); 10 Apr 2012 15:05:11 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:05:11 -0000
Received: by bkcjg9 with SMTP id jg9so4991205bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 08:05:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=GBH7VRCMd+hFFKwjU+Tnc3IWzrACmiWv/gozpU7NS6s=;
	b=Hjhb6/vi5WQ8ErWMNvIe4ib0Rub71bfM9FtRvd+r8hqBcpIRZ+Fv8jRUCu17/1nfmv
	ZxAw+cpzkpT/Ca8pZL5pUkqyB013Uaz3epkUZa6vC4gk58R1mIhk0rviaLkDrFBCyjAI
	c4HJieUVRnQPMUDwKcKASaZnWfNY9CNJs2gkmepC57Dh6F7QFkdjoify6CJiG6rkPaEA
	oD2wBXzq+yk/F06ziyo9NO7CQVh/8g8N+dEQqUO1smJRiNTnKZPYRTBLxVD/C424yVA8
	tm84zkC+XbT/64HxexKKHsvnMxWP/I77ly5Ot0BDOObreiyjsumSxf7OKi30GV77LyQg
	78bw==
Received: by 10.204.154.194 with SMTP id p2mr4804222bkw.80.1334070307591;
	Tue, 10 Apr 2012 08:05:07 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id
	zx16sm36849151bkb.13.2012.04.10.08.05.05
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 08:05:06 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 17:05:01 +0200
Message-ID: <1334070301.5300.65.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> As of the previous patch we align the end (rather than the start) of the struct
> to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> increase from the next patch, the first 8 bytes of the struct end up on a
> different cache line to the rest of it so make sure it is something relatively
> unimportant to avoid hitting an extra cache line on hot operations such as
> kfree_skb.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>  include/linux/skbuff.h |   15 ++++++++++-----
>  net/core/skbuff.c      |    5 ++++-
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 0ad6a46..f0ae39c 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -265,6 +265,15 @@ struct ubuf_info {
>   * the end of the header data, ie. at skb->end.
>   */
>  struct skb_shared_info {
> +	/* Intermediate layers must ensure that destructor_arg
> +	 * remains valid until skb destructor */
> +	void		*destructor_arg;
> +
> +	/*
> +	 * Warning: all fields from here until dataref are cleared in
> +	 * __alloc_skb()
> +	 *
> +	 */
>  	unsigned char	nr_frags;
>  	__u8		tx_flags;
>  	unsigned short	gso_size;
> @@ -276,14 +285,10 @@ struct skb_shared_info {
>  	__be32          ip6_frag_id;
>  
>  	/*
> -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> +	 * Warning: all fields before dataref are cleared in __alloc_skb()
>  	 */
>  	atomic_t	dataref;
>  
> -	/* Intermediate layers must ensure that destructor_arg
> -	 * remains valid until skb destructor */
> -	void *		destructor_arg;
> -
>  	/* must be last field, see pskb_expand_head() */
>  	skb_frag_t	frags[MAX_SKB_FRAGS];
>  };
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index d4e139e..b8a41d6 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
>  
>  	/* make sure we initialize shinfo sequentially */
>  	shinfo = skb_shinfo(skb);
> -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> +
> +	memset(&shinfo->nr_frags, 0,
> +	       offsetof(struct skb_shared_info, dataref)
> +	       - offsetof(struct skb_shared_info, nr_frags));
>  	atomic_set(&shinfo->dataref, 1);
>  	kmemcheck_annotate_variable(shinfo->destructor_arg);
>  

Not sure if we can do the same in build_skb()



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcdJ-0004Gk-Su; Tue, 10 Apr 2012 15:05:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHcdI-0004GY-CO
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:05:24 +0000
Received: from [85.158.143.35:48796] by server-1.bemta-4.messagelabs.com id
	2C/EB-20925-33C448F4; Tue, 10 Apr 2012 15:05:23 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334070307!6434654!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19836 invoked from network); 10 Apr 2012 15:05:11 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:05:11 -0000
Received: by bkcjg9 with SMTP id jg9so4991205bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 08:05:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=GBH7VRCMd+hFFKwjU+Tnc3IWzrACmiWv/gozpU7NS6s=;
	b=Hjhb6/vi5WQ8ErWMNvIe4ib0Rub71bfM9FtRvd+r8hqBcpIRZ+Fv8jRUCu17/1nfmv
	ZxAw+cpzkpT/Ca8pZL5pUkqyB013Uaz3epkUZa6vC4gk58R1mIhk0rviaLkDrFBCyjAI
	c4HJieUVRnQPMUDwKcKASaZnWfNY9CNJs2gkmepC57Dh6F7QFkdjoify6CJiG6rkPaEA
	oD2wBXzq+yk/F06ziyo9NO7CQVh/8g8N+dEQqUO1smJRiNTnKZPYRTBLxVD/C424yVA8
	tm84zkC+XbT/64HxexKKHsvnMxWP/I77ly5Ot0BDOObreiyjsumSxf7OKi30GV77LyQg
	78bw==
Received: by 10.204.154.194 with SMTP id p2mr4804222bkw.80.1334070307591;
	Tue, 10 Apr 2012 08:05:07 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id
	zx16sm36849151bkb.13.2012.04.10.08.05.05
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 08:05:06 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 17:05:01 +0200
Message-ID: <1334070301.5300.65.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Wei Liu <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> As of the previous patch we align the end (rather than the start) of the struct
> to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> increase from the next patch, the first 8 bytes of the struct end up on a
> different cache line to the rest of it so make sure it is something relatively
> unimportant to avoid hitting an extra cache line on hot operations such as
> kfree_skb.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>  include/linux/skbuff.h |   15 ++++++++++-----
>  net/core/skbuff.c      |    5 ++++-
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 0ad6a46..f0ae39c 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -265,6 +265,15 @@ struct ubuf_info {
>   * the end of the header data, ie. at skb->end.
>   */
>  struct skb_shared_info {
> +	/* Intermediate layers must ensure that destructor_arg
> +	 * remains valid until skb destructor */
> +	void		*destructor_arg;
> +
> +	/*
> +	 * Warning: all fields from here until dataref are cleared in
> +	 * __alloc_skb()
> +	 *
> +	 */
>  	unsigned char	nr_frags;
>  	__u8		tx_flags;
>  	unsigned short	gso_size;
> @@ -276,14 +285,10 @@ struct skb_shared_info {
>  	__be32          ip6_frag_id;
>  
>  	/*
> -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> +	 * Warning: all fields before dataref are cleared in __alloc_skb()
>  	 */
>  	atomic_t	dataref;
>  
> -	/* Intermediate layers must ensure that destructor_arg
> -	 * remains valid until skb destructor */
> -	void *		destructor_arg;
> -
>  	/* must be last field, see pskb_expand_head() */
>  	skb_frag_t	frags[MAX_SKB_FRAGS];
>  };
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index d4e139e..b8a41d6 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
>  
>  	/* make sure we initialize shinfo sequentially */
>  	shinfo = skb_shinfo(skb);
> -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> +
> +	memset(&shinfo->nr_frags, 0,
> +	       offsetof(struct skb_shared_info, dataref)
> +	       - offsetof(struct skb_shared_info, nr_frags));
>  	atomic_set(&shinfo->dataref, 1);
>  	kmemcheck_annotate_variable(shinfo->destructor_arg);
>  

Not sure if we can do the same in build_skb()



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:06:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHce4-0004Kw-Aq; Tue, 10 Apr 2012 15:06:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1SHce3-0004Kf-02
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:06:11 +0000
Received: from [85.158.139.83:2168] by server-10.bemta-5.messagelabs.com id
	14/7A-08260-26C448F4; Tue, 10 Apr 2012 15:06:10 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334070369!23193303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25167 invoked from network); 10 Apr 2012 15:06:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:06:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11859836"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:06:09 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 10 Apr 2012
	16:06:09 +0100
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 16:06:36 +0100
Thread-Topic: [Xen-devel] Driver domains communication protocol proposal
Thread-Index: Ac0Se0EyJbrpvkxMRgWX046N6yih5gErt4YA
Message-ID: <291EDFCB1E9E224A99088639C4762022C8235B7099@LONPMAILBOX01.citrite.net>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
In-Reply-To: <20348.27879.297617.171564@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Ian Jackson
> Sent: 04 April 2012 16:47
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Driver domains communication protocol proposal
> 
> During some discussions and handwaving, including discussions with some
> experts on the Xenserver/XCP storage architecture, we came up with what
> we think might be a plausible proposal for an architecture for
> communication between toolstack and driver domain, for storage at least.
> 
> I offered to write it up.  The abstract proposal is as I understand the
> consensus from our conversation.  The concrete protocol is my own
> invention.
> 
> Please comments.  After a round of review here we should consider
> whether some of the assumptions need review from the communities
> involved in "other" backends (particularly, the BSDs).
> 
> (FAOD the implementation of something like this is not 4.3 material, but it
> may inform some API decisions etc. we take in 4.2.)
> 

I'm wondering how we should deal with driver domain re-starts (possibly because of a crash). One of the compelling reasons for using driver domains is the ability to re-start them, possibly transparently to the frontend.
If a driver domain were to crash, I guess it would be the responsibility of the tools to notice this and build a new one as quickly as possible. A frontend could notice the loss of a driver domain backend by, presumably a backend state watch firing followed by an inability to read the backend state key, as presumably a clean unplug should go through the usual closing->closed dance first. The frontend could then, perhaps, stall I/O while the tools build a new driver domain and re-build communications when it notices the <frontend>/backend key get updated by the tools. Does that sequence sound plausible?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:06:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHce4-0004Kw-Aq; Tue, 10 Apr 2012 15:06:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1SHce3-0004Kf-02
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:06:11 +0000
Received: from [85.158.139.83:2168] by server-10.bemta-5.messagelabs.com id
	14/7A-08260-26C448F4; Tue, 10 Apr 2012 15:06:10 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334070369!23193303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25167 invoked from network); 10 Apr 2012 15:06:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:06:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11859836"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:06:09 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 10 Apr 2012
	16:06:09 +0100
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 16:06:36 +0100
Thread-Topic: [Xen-devel] Driver domains communication protocol proposal
Thread-Index: Ac0Se0EyJbrpvkxMRgWX046N6yih5gErt4YA
Message-ID: <291EDFCB1E9E224A99088639C4762022C8235B7099@LONPMAILBOX01.citrite.net>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
In-Reply-To: <20348.27879.297617.171564@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Ian Jackson
> Sent: 04 April 2012 16:47
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Driver domains communication protocol proposal
> 
> During some discussions and handwaving, including discussions with some
> experts on the Xenserver/XCP storage architecture, we came up with what
> we think might be a plausible proposal for an architecture for
> communication between toolstack and driver domain, for storage at least.
> 
> I offered to write it up.  The abstract proposal is as I understand the
> consensus from our conversation.  The concrete protocol is my own
> invention.
> 
> Please comments.  After a round of review here we should consider
> whether some of the assumptions need review from the communities
> involved in "other" backends (particularly, the BSDs).
> 
> (FAOD the implementation of something like this is not 4.3 material, but it
> may inform some API decisions etc. we take in 4.2.)
> 

I'm wondering how we should deal with driver domain re-starts (possibly because of a crash). One of the compelling reasons for using driver domains is the ability to re-start them, possibly transparently to the frontend.
If a driver domain were to crash, I guess it would be the responsibility of the tools to notice this and build a new one as quickly as possible. A frontend could notice the loss of a driver domain backend by, presumably a backend state watch firing followed by an inability to read the backend state key, as presumably a clean unplug should go through the usual closing->closed dance first. The frontend could then, perhaps, stall I/O while the tools build a new driver domain and re-build communications when it notices the <frontend>/backend key get updated by the tools. Does that sequence sound plausible?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcli-0004hy-A4; Tue, 10 Apr 2012 15:14:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHclg-0004ht-JC
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:14:04 +0000
Received: from [85.158.139.83:52221] by server-11.bemta-5.messagelabs.com id
	8E/61-12959-B3E448F4; Tue, 10 Apr 2012 15:14:03 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334070841!19254053!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12251 invoked from network); 10 Apr 2012 15:14:02 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-7.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 15:14:02 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id A8DF8DBCAA;
	Tue, 10 Apr 2012 23:13:47 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Apr 2012 23:13:06 +0800
Message-ID: <1334070786.5865.133.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Xiantao Zhang <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
	PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new physdev_op is added for Linux guest kernel to get the correct
nr_irqs_gsi value.

See below Linux kernel patch for detail explanation.

[RFC PATCH] xen: get correct nr_irqs_gsi value from hypervisor
http://marc.info/?l=xen-devel&m=133407004503365&w=2

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 xen/arch/x86/physdev.c       |    8 ++++++++
 xen/include/public/physdev.h |    6 ++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 05fff9e..0912db0 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -688,6 +688,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
                               setup_gsi.polarity);
         break; 
     }
+    case PHYSDEVOP_nr_irqs_gsi: {
+        struct physdev_nr_irqs_gsi out;
+
+        out.nr_irqs_gsi = nr_irqs_gsi;
+        ret = copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
+
+        break;
+    }
     case PHYSDEVOP_get_free_pirq: {
         struct physdev_get_free_pirq out;
         struct domain *d;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index b78eeba..7856fc2 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -312,6 +312,12 @@ struct physdev_pci_device {
 typedef struct physdev_pci_device physdev_pci_device_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 
+#define PHYSDEVOP_nr_irqs_gsi           29
+struct physdev_nr_irqs_gsi {
+    /* OUT */
+    uint32_t nr_irqs_gsi;
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcli-0004hy-A4; Tue, 10 Apr 2012 15:14:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHclg-0004ht-JC
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:14:04 +0000
Received: from [85.158.139.83:52221] by server-11.bemta-5.messagelabs.com id
	8E/61-12959-B3E448F4; Tue, 10 Apr 2012 15:14:03 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334070841!19254053!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12251 invoked from network); 10 Apr 2012 15:14:02 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-7.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 15:14:02 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id A8DF8DBCAA;
	Tue, 10 Apr 2012 23:13:47 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Apr 2012 23:13:06 +0800
Message-ID: <1334070786.5865.133.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Xiantao Zhang <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
	PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new physdev_op is added for Linux guest kernel to get the correct
nr_irqs_gsi value.

See below Linux kernel patch for detail explanation.

[RFC PATCH] xen: get correct nr_irqs_gsi value from hypervisor
http://marc.info/?l=xen-devel&m=133407004503365&w=2

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 xen/arch/x86/physdev.c       |    8 ++++++++
 xen/include/public/physdev.h |    6 ++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 05fff9e..0912db0 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -688,6 +688,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
                               setup_gsi.polarity);
         break; 
     }
+    case PHYSDEVOP_nr_irqs_gsi: {
+        struct physdev_nr_irqs_gsi out;
+
+        out.nr_irqs_gsi = nr_irqs_gsi;
+        ret = copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
+
+        break;
+    }
     case PHYSDEVOP_get_free_pirq: {
         struct physdev_get_free_pirq out;
         struct domain *d;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index b78eeba..7856fc2 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -312,6 +312,12 @@ struct physdev_pci_device {
 typedef struct physdev_pci_device physdev_pci_device_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 
+#define PHYSDEVOP_nr_irqs_gsi           29
+struct physdev_nr_irqs_gsi {
+    /* OUT */
+    uint32_t nr_irqs_gsi;
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcp3-0004pf-U7; Tue, 10 Apr 2012 15:17:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHcp3-0004pZ-5f
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:17:33 +0000
Received: from [85.158.139.83:19309] by server-4.bemta-5.messagelabs.com id
	36/13-10788-C0F448F4; Tue, 10 Apr 2012 15:17:32 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334071049!23202898!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=3.4 required=7.0 tests=INFO_TLD,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24420 invoked from network); 10 Apr 2012 15:17:30 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 15:17:30 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 227B6DBCAA;
	Tue, 10 Apr 2012 23:17:17 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
In-Reply-To: <1334069838.5865.130.camel@hp6530s>
References: <1334069838.5865.130.camel@hp6530s>
Date: Tue, 10 Apr 2012 23:16:35 +0800
Message-ID: <1334070995.5865.135.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Xiantao Zhang <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] xen: get correct nr_irqs_gsi value from
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 22:57 +0800, Lin Ming wrote:
> nr_irqs_gsi is set in probe_nr_irqs_gsi()
> 	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY;
> 
> gsi_top is set in mp_register_ioapic()
> 	gsi_top = gsi_cfg->gsi_end + 1;
> 
> mp_register_ioapic() calls io_apic_read, which don't have a Xen specific
> version. Actually, io_apic_read() always return -1 on Xen Dom0 kernel.
> 
> So currently, nr_irqs_gsi is always wrong on Xen Dom0 kernel.
> 
> This patch gets the correct nr_irqs_gsi value from Xen hypervisor with a
> hypercall.
> 
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> --
>  arch/x86/include/asm/io_apic.h  |    2 ++
>  arch/x86/kernel/apic/io_apic.c  |    2 +-
>  arch/x86/xen/setup.c            |    9 +++++++++
>  include/xen/interface/physdev.h |    6 ++++++
>  4 files changed, 18 insertions(+), 1 deletions(-)
> 
> (I will send xen hypervisor patch in another mail)\

Here is xen hypervisor side patch:

[RFC PATCH] x86: Add a new physdev_op PHYSDEVOP_nr_irqs_gsi
http://marc.info/?l=xen-devel&m=133407101003891&w=2

Regards,
Lin Ming


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcp3-0004pf-U7; Tue, 10 Apr 2012 15:17:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHcp3-0004pZ-5f
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:17:33 +0000
Received: from [85.158.139.83:19309] by server-4.bemta-5.messagelabs.com id
	36/13-10788-C0F448F4; Tue, 10 Apr 2012 15:17:32 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334071049!23202898!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=3.4 required=7.0 tests=INFO_TLD,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24420 invoked from network); 10 Apr 2012 15:17:30 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 15:17:30 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 227B6DBCAA;
	Tue, 10 Apr 2012 23:17:17 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
In-Reply-To: <1334069838.5865.130.camel@hp6530s>
References: <1334069838.5865.130.camel@hp6530s>
Date: Tue, 10 Apr 2012 23:16:35 +0800
Message-ID: <1334070995.5865.135.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Xiantao Zhang <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] xen: get correct nr_irqs_gsi value from
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 22:57 +0800, Lin Ming wrote:
> nr_irqs_gsi is set in probe_nr_irqs_gsi()
> 	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY;
> 
> gsi_top is set in mp_register_ioapic()
> 	gsi_top = gsi_cfg->gsi_end + 1;
> 
> mp_register_ioapic() calls io_apic_read, which don't have a Xen specific
> version. Actually, io_apic_read() always return -1 on Xen Dom0 kernel.
> 
> So currently, nr_irqs_gsi is always wrong on Xen Dom0 kernel.
> 
> This patch gets the correct nr_irqs_gsi value from Xen hypervisor with a
> hypercall.
> 
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> --
>  arch/x86/include/asm/io_apic.h  |    2 ++
>  arch/x86/kernel/apic/io_apic.c  |    2 +-
>  arch/x86/xen/setup.c            |    9 +++++++++
>  include/xen/interface/physdev.h |    6 ++++++
>  4 files changed, 18 insertions(+), 1 deletions(-)
> 
> (I will send xen hypervisor patch in another mail)\

Here is xen hypervisor side patch:

[RFC PATCH] x86: Add a new physdev_op PHYSDEVOP_nr_irqs_gsi
http://marc.info/?l=xen-devel&m=133407101003891&w=2

Regards,
Lin Ming


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:19:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcqq-0004vp-EL; Tue, 10 Apr 2012 15:19:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHcqo-0004vg-V9
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:19:23 +0000
Received: from [193.109.254.147:56510] by server-4.bemta-14.messagelabs.com id
	9A/AC-11570-A7F448F4; Tue, 10 Apr 2012 15:19:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334071161!3980012!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6136 invoked from network); 10 Apr 2012 15:19:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:19:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:19:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 16:19:20 +0100
Message-ID: <1334071159.5394.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Apr 2012 16:19:19 +0100
In-Reply-To: <1334070301.5300.65.camel@edumazet-glaptop>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<1334070301.5300.65.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Wei Liu
	\(Intern\)" <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:05 +0100, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> > As of the previous patch we align the end (rather than the start) of the struct
> > to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> > increase from the next patch, the first 8 bytes of the struct end up on a
> > different cache line to the rest of it so make sure it is something relatively
> > unimportant to avoid hitting an extra cache line on hot operations such as
> > kfree_skb.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> >  include/linux/skbuff.h |   15 ++++++++++-----
> >  net/core/skbuff.c      |    5 ++++-
> >  2 files changed, 14 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 0ad6a46..f0ae39c 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -265,6 +265,15 @@ struct ubuf_info {
> >   * the end of the header data, ie. at skb->end.
> >   */
> >  struct skb_shared_info {
> > +	/* Intermediate layers must ensure that destructor_arg
> > +	 * remains valid until skb destructor */
> > +	void		*destructor_arg;
> > +
> > +	/*
> > +	 * Warning: all fields from here until dataref are cleared in
> > +	 * __alloc_skb()
> > +	 *
> > +	 */
> >  	unsigned char	nr_frags;
> >  	__u8		tx_flags;
> >  	unsigned short	gso_size;
> > @@ -276,14 +285,10 @@ struct skb_shared_info {
> >  	__be32          ip6_frag_id;
> >  
> >  	/*
> > -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> > +	 * Warning: all fields before dataref are cleared in __alloc_skb()
> >  	 */
> >  	atomic_t	dataref;
> >  
> > -	/* Intermediate layers must ensure that destructor_arg
> > -	 * remains valid until skb destructor */
> > -	void *		destructor_arg;
> > -
> >  	/* must be last field, see pskb_expand_head() */
> >  	skb_frag_t	frags[MAX_SKB_FRAGS];
> >  };
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index d4e139e..b8a41d6 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> >  
> >  	/* make sure we initialize shinfo sequentially */
> >  	shinfo = skb_shinfo(skb);
> > -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> > +
> > +	memset(&shinfo->nr_frags, 0,
> > +	       offsetof(struct skb_shared_info, dataref)
> > +	       - offsetof(struct skb_shared_info, nr_frags));
> >  	atomic_set(&shinfo->dataref, 1);
> >  	kmemcheck_annotate_variable(shinfo->destructor_arg);
> >  
> 
> Not sure if we can do the same in build_skb()

I don't think there's any chance of there being a destructor_arg to
preserve in that case?

Regardless of that though I think for consistency it would be worth
pulling the common shinfo init out into a helper and using it in both
places.

I'll make that change.

Ian.

> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:19:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcqq-0004vp-EL; Tue, 10 Apr 2012 15:19:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHcqo-0004vg-V9
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:19:23 +0000
Received: from [193.109.254.147:56510] by server-4.bemta-14.messagelabs.com id
	9A/AC-11570-A7F448F4; Tue, 10 Apr 2012 15:19:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334071161!3980012!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6136 invoked from network); 10 Apr 2012 15:19:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:19:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:19:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 16:19:20 +0100
Message-ID: <1334071159.5394.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Apr 2012 16:19:19 +0100
In-Reply-To: <1334070301.5300.65.camel@edumazet-glaptop>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<1334070301.5300.65.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Wei Liu
	\(Intern\)" <wei.liu2@citrix.com>, David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:05 +0100, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> > As of the previous patch we align the end (rather than the start) of the struct
> > to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> > increase from the next patch, the first 8 bytes of the struct end up on a
> > different cache line to the rest of it so make sure it is something relatively
> > unimportant to avoid hitting an extra cache line on hot operations such as
> > kfree_skb.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> >  include/linux/skbuff.h |   15 ++++++++++-----
> >  net/core/skbuff.c      |    5 ++++-
> >  2 files changed, 14 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 0ad6a46..f0ae39c 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -265,6 +265,15 @@ struct ubuf_info {
> >   * the end of the header data, ie. at skb->end.
> >   */
> >  struct skb_shared_info {
> > +	/* Intermediate layers must ensure that destructor_arg
> > +	 * remains valid until skb destructor */
> > +	void		*destructor_arg;
> > +
> > +	/*
> > +	 * Warning: all fields from here until dataref are cleared in
> > +	 * __alloc_skb()
> > +	 *
> > +	 */
> >  	unsigned char	nr_frags;
> >  	__u8		tx_flags;
> >  	unsigned short	gso_size;
> > @@ -276,14 +285,10 @@ struct skb_shared_info {
> >  	__be32          ip6_frag_id;
> >  
> >  	/*
> > -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> > +	 * Warning: all fields before dataref are cleared in __alloc_skb()
> >  	 */
> >  	atomic_t	dataref;
> >  
> > -	/* Intermediate layers must ensure that destructor_arg
> > -	 * remains valid until skb destructor */
> > -	void *		destructor_arg;
> > -
> >  	/* must be last field, see pskb_expand_head() */
> >  	skb_frag_t	frags[MAX_SKB_FRAGS];
> >  };
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index d4e139e..b8a41d6 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> >  
> >  	/* make sure we initialize shinfo sequentially */
> >  	shinfo = skb_shinfo(skb);
> > -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> > +
> > +	memset(&shinfo->nr_frags, 0,
> > +	       offsetof(struct skb_shared_info, dataref)
> > +	       - offsetof(struct skb_shared_info, nr_frags));
> >  	atomic_set(&shinfo->dataref, 1);
> >  	kmemcheck_annotate_variable(shinfo->destructor_arg);
> >  
> 
> Not sure if we can do the same in build_skb()

I don't think there's any chance of there being a destructor_arg to
preserve in that case?

Regardless of that though I think for consistency it would be worth
pulling the common shinfo init out into a helper and using it in both
places.

I'll make that change.

Ian.

> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:22:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHctl-00057K-1a; Tue, 10 Apr 2012 15:22:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHctj-00057D-M7
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:22:23 +0000
Received: from [85.158.143.35:21238] by server-1.bemta-4.messagelabs.com id
	64/A5-20925-D20548F4; Tue, 10 Apr 2012 15:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334071337!12619624!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32457 invoked from network); 10 Apr 2012 15:22:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:22:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 16:22:17 +0100
Date: Tue, 10 Apr 2012 16:25:44 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
In-Reply-To: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-503233747-1334071560=:15151"
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
 O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-503233747-1334071560=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Thu, 5 Apr 2012, Pablo Llopis wrote:
> Hi there Xen community,
> I am trying to benchmark and compare I/O in Xen/domU to native performance.
> 
> In order to do this I started trying to benchmark writes so as to avoid caching effects that surely turn up when
> performing reads due to the page cache et al.
> However, I have quickly run into a problem: Xen domU reports that a 128MB file is written at close to 300MB/s, while the
> disk's performance peaks at about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with no hypervisor).
> Please note that I fsync() after all writes in hopes to avoid the effect of write buffers. I have tried with O_SYNC as
> well, observing a similar outcome.
> I can confirm this writing a simple program, and verified exactly same results running bonnie++ with the fsync() option
> turned on.
> 
> I am surprised to see writes reaching a throughput as high as 300MB/s, as the disk surely isn't physically capable of
> reaching that bandwidth, meaning that writes are not being really synced to disk. 
> 
> Is this a bug in Xen, or is there a way to make Xen not ignore fsync, fdatasync, O_SYNC, etc..? 
> How would I proceed to measure and compare real read/write speeds on a Xen domU ?
> 
> My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I could not get the tapdisk driver to work
> properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)
> Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 kernel

Are you using xend/xm to create the guest? In that case you are using
a loop device with blkback behind the scenes, that might go through the
disk cache.
--8323329-503233747-1334071560=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-503233747-1334071560=:15151--


From xen-devel-bounces@lists.xen.org Tue Apr 10 15:22:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHctl-00057K-1a; Tue, 10 Apr 2012 15:22:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHctj-00057D-M7
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:22:23 +0000
Received: from [85.158.143.35:21238] by server-1.bemta-4.messagelabs.com id
	64/A5-20925-D20548F4; Tue, 10 Apr 2012 15:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334071337!12619624!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32457 invoked from network); 10 Apr 2012 15:22:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:22:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 16:22:17 +0100
Date: Tue, 10 Apr 2012 16:25:44 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
In-Reply-To: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-503233747-1334071560=:15151"
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
 O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-503233747-1334071560=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Thu, 5 Apr 2012, Pablo Llopis wrote:
> Hi there Xen community,
> I am trying to benchmark and compare I/O in Xen/domU to native performance.
> 
> In order to do this I started trying to benchmark writes so as to avoid caching effects that surely turn up when
> performing reads due to the page cache et al.
> However, I have quickly run into a problem: Xen domU reports that a 128MB file is written at close to 300MB/s, while the
> disk's performance peaks at about 80MB/s (I observed this on a dom0 and on a bare-metal kernel with no hypervisor).
> Please note that I fsync() after all writes in hopes to avoid the effect of write buffers. I have tried with O_SYNC as
> well, observing a similar outcome.
> I can confirm this writing a simple program, and verified exactly same results running bonnie++ with the fsync() option
> turned on.
> 
> I am surprised to see writes reaching a throughput as high as 300MB/s, as the disk surely isn't physically capable of
> reaching that bandwidth, meaning that writes are not being really synced to disk. 
> 
> Is this a bug in Xen, or is there a way to make Xen not ignore fsync, fdatasync, O_SYNC, etc..? 
> How would I proceed to measure and compare real read/write speeds on a Xen domU ?
> 
> My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I could not get the tapdisk driver to work
> properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)
> Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 kernel

Are you using xend/xm to create the guest? In that case you are using
a loop device with blkback behind the scenes, that might go through the
disk cache.
--8323329-503233747-1334071560=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-503233747-1334071560=:15151--


From xen-devel-bounces@lists.xen.org Tue Apr 10 15:27:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:27:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcya-0005Iu-Ol; Tue, 10 Apr 2012 15:27:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcyZ-0005Il-2r
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:27:23 +0000
Received: from [85.158.138.51:42430] by server-4.bemta-3.messagelabs.com id
	AB/C7-15341-A51548F4; Tue, 10 Apr 2012 15:27:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334071640!21498952!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21847 invoked from network); 10 Apr 2012 15:27:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:27:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24027462"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:27:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:27:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcyV-0003Iq-Ap;
	Tue, 10 Apr 2012 16:27:19 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 16:27:15 +0100
Message-ID: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59992b6..16ebef3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 1261499..30908d1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -991,7 +991,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d486af2..2181774 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -949,8 +949,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:27:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:27:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcya-0005Iu-Ol; Tue, 10 Apr 2012 15:27:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcyZ-0005Il-2r
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:27:23 +0000
Received: from [85.158.138.51:42430] by server-4.bemta-3.messagelabs.com id
	AB/C7-15341-A51548F4; Tue, 10 Apr 2012 15:27:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334071640!21498952!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21847 invoked from network); 10 Apr 2012 15:27:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:27:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24027462"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:27:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:27:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcyV-0003Iq-Ap;
	Tue, 10 Apr 2012 16:27:19 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 16:27:15 +0100
Message-ID: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59992b6..16ebef3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 1261499..30908d1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -991,7 +991,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d486af2..2181774 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -949,8 +949,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:27:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcyc-0005JO-AM; Tue, 10 Apr 2012 15:27:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcya-0005It-F6
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:27:25 +0000
Received: from [85.158.138.51:19873] by server-12.bemta-3.messagelabs.com id
	49/17-29760-B51548F4; Tue, 10 Apr 2012 15:27:23 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334071640!21498952!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21925 invoked from network); 10 Apr 2012 15:27:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:27:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24027463"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:27:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:27:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcyV-0003Iq-BT;
	Tue, 10 Apr 2012 16:27:19 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 16:27:16 +0100
Message-ID: <1334071637-2758-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
References: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: call hotplug scripts from libxl for
	vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl.c          |  101 ++++++++++++++++++++++++++-----
 tools/libxl/libxl.h          |    7 ++-
 tools/libxl/libxl_create.c   |    4 +-
 tools/libxl/libxl_device.c   |  134 +++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_dm.c       |    4 +-
 tools/libxl/libxl_hotplug.c  |   67 +++++++++++++++++++++
 tools/libxl/libxl_internal.h |   43 +++++++++++++-
 tools/libxl/libxl_linux.c    |  114 +++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c     |   14 ++--
 10 files changed, 453 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b30d11f..ac8b810 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 16ebef3..f253a6b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
@@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1420,14 +1436,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+    } else {
+        /* no need to execute hotplug scripts */
+        libxl__ao_complete(egc, ao, 0);
+    }
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1467,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1702,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1909,7 +1945,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2256,7 +2303,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2389,7 +2447,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 50bae2f..b7347be 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,7 +394,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -523,7 +524,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..8acda75 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,26 +356,90 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
 
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events where added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -392,7 +456,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -413,6 +476,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -420,7 +484,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -428,8 +492,50 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, be_path);
+    return 0;
+}
+
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
+{
+    AO_GC;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
     return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
@@ -446,13 +552,14 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -482,11 +589,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events where added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 30908d1..2d51a7f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -790,7 +790,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1044,7 +1044,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..52dccb0
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.paumonne@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2181774..a39346c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -455,6 +456,37 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -740,7 +772,8 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -763,6 +796,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..372b95d 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,117 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    flexarray_t *f_env;
+    int nr = 0;
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
+                               libxl__sprintf(gc, "%s/%s",
+                                              be_path,
+                                              "script")));
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        flexarray_set(f_env, nr++, "vif");
+        flexarray_set(f_env, nr++,
+                      libxl__sprintf(gc, "%s%u.%d",
+                      libxl__device_kind_to_string(dev->backend_kind),
+                      dev->domid, dev->devid));
+    }
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 08815a3..01ff363 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1301,7 +1301,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1862,7 +1862,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2339,7 +2339,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2613,7 +2613,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2846,7 +2846,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2964,7 +2964,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5011,7 +5011,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:27:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcyc-0005JO-AM; Tue, 10 Apr 2012 15:27:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcya-0005It-F6
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:27:25 +0000
Received: from [85.158.138.51:19873] by server-12.bemta-3.messagelabs.com id
	49/17-29760-B51548F4; Tue, 10 Apr 2012 15:27:23 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334071640!21498952!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21925 invoked from network); 10 Apr 2012 15:27:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:27:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24027463"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:27:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:27:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcyV-0003Iq-BT;
	Tue, 10 Apr 2012 16:27:19 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 16:27:16 +0100
Message-ID: <1334071637-2758-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
References: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: call hotplug scripts from libxl for
	vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl.c          |  101 ++++++++++++++++++++++++++-----
 tools/libxl/libxl.h          |    7 ++-
 tools/libxl/libxl_create.c   |    4 +-
 tools/libxl/libxl_device.c   |  134 +++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_dm.c       |    4 +-
 tools/libxl/libxl_hotplug.c  |   67 +++++++++++++++++++++
 tools/libxl/libxl_internal.h |   43 +++++++++++++-
 tools/libxl/libxl_linux.c    |  114 +++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c     |   14 ++--
 10 files changed, 453 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b30d11f..ac8b810 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 16ebef3..f253a6b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
@@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1420,14 +1436,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+    } else {
+        /* no need to execute hotplug scripts */
+        libxl__ao_complete(egc, ao, 0);
+    }
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1467,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1702,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1909,7 +1945,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2256,7 +2303,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2389,7 +2447,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 50bae2f..b7347be 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,7 +394,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -523,7 +524,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..8acda75 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,26 +356,90 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
 
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events where added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -392,7 +456,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -413,6 +476,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -420,7 +484,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -428,8 +492,50 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, be_path);
+    return 0;
+}
+
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
+{
+    AO_GC;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
     return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
@@ -446,13 +552,14 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -482,11 +589,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events where added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 30908d1..2d51a7f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -790,7 +790,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1044,7 +1044,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..52dccb0
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.paumonne@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2181774..a39346c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -455,6 +456,37 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -740,7 +772,8 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -763,6 +796,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..372b95d 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,117 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    flexarray_t *f_env;
+    int nr = 0;
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
+                               libxl__sprintf(gc, "%s/%s",
+                                              be_path,
+                                              "script")));
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        flexarray_set(f_env, nr++, "vif");
+        flexarray_set(f_env, nr++,
+                      libxl__sprintf(gc, "%s%u.%d",
+                      libxl__device_kind_to_string(dev->backend_kind),
+                      dev->domid, dev->devid));
+    }
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 08815a3..01ff363 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1301,7 +1301,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1862,7 +1862,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2339,7 +2339,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2613,7 +2613,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2846,7 +2846,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2964,7 +2964,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5011,7 +5011,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:27:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcyx-0005Nk-TR; Tue, 10 Apr 2012 15:27:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcyv-0005N8-PL
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:27:46 +0000
Received: from [85.158.138.51:46199] by server-12.bemta-3.messagelabs.com id
	FF/D7-29760-171548F4; Tue, 10 Apr 2012 15:27:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334071662!21572091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 838 invoked from network); 10 Apr 2012 15:27:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189669837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:27:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:27:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcyV-0003Iq-CF;
	Tue, 10 Apr 2012 16:27:19 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 16:27:17 +0100
Message-ID: <1334071637-2758-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
References: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: call hotplug scripts from libxl for
	vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c        |   13 ++++++----
 tools/libxl/libxl.h        |    3 +-
 tools/libxl/libxl_create.c |    2 +-
 tools/libxl/libxl_dm.c     |    2 +-
 tools/libxl/libxl_linux.c  |   57 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c   |    2 +-
 6 files changed, 70 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f253a6b..1bf2e00 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1839,9 +1839,10 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1923,14 +1924,16 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    rc = libxl__initiate_device_add(egc, ao, &device);
+    if (rc) goto out_free;
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b7347be..6da6107 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -551,7 +551,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..d66f714 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 2d51a7f..ba5bef7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -795,7 +795,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 372b95d..74c84c3 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -123,6 +123,60 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
+    flexarray_set(f_args, nr++, "type_if=vif");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -132,6 +186,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 01ff363..fd9a9f6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4901,7 +4901,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:27:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHcyx-0005Nk-TR; Tue, 10 Apr 2012 15:27:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHcyv-0005N8-PL
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:27:46 +0000
Received: from [85.158.138.51:46199] by server-12.bemta-3.messagelabs.com id
	FF/D7-29760-171548F4; Tue, 10 Apr 2012 15:27:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334071662!21572091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 838 invoked from network); 10 Apr 2012 15:27:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189669837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:27:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 11:27:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHcyV-0003Iq-CF;
	Tue, 10 Apr 2012 16:27:19 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 16:27:17 +0100
Message-ID: <1334071637-2758-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
References: <1334071637-2758-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: call hotplug scripts from libxl for
	vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c        |   13 ++++++----
 tools/libxl/libxl.h        |    3 +-
 tools/libxl/libxl_create.c |    2 +-
 tools/libxl/libxl_dm.c     |    2 +-
 tools/libxl/libxl_linux.c  |   57 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c   |    2 +-
 6 files changed, 70 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f253a6b..1bf2e00 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1839,9 +1839,10 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1923,14 +1924,16 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    rc = libxl__initiate_device_add(egc, ao, &device);
+    if (rc) goto out_free;
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b7347be..6da6107 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -551,7 +551,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..d66f714 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 2d51a7f..ba5bef7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -795,7 +795,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 372b95d..74c84c3 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -123,6 +123,60 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
+    flexarray_set(f_args, nr++, "type_if=vif");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -132,6 +186,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 01ff363..fd9a9f6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4901,7 +4901,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:29:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHd0G-0005aZ-BI; Tue, 10 Apr 2012 15:29:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SHd0F-0005aS-Gn
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:29:07 +0000
Received: from [85.158.139.83:48942] by server-10.bemta-5.messagelabs.com id
	C7/8D-08260-2C1548F4; Tue, 10 Apr 2012 15:29:06 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334071744!11927793!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30616 invoked from network); 10 Apr 2012 15:29:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189670171"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:28:53 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Tue, 10 Apr 2012
	11:28:53 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 10 Apr 2012 11:28:50 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0XJUFkbOKUDHZwTN6BtmHjb7LnvgAB6LRQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334067702.5394.18.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Tuesday, April 10, 2012 10:22 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > > I see. So you need to be able to find the individual tables so that
> > > smbios_type_<N>_init can check for an overriding table <N> in the
> > > passed-through tables, it seems reasonable to try and avoid needing
> > > to parse a big lump of tables each time to see if the one you are
> > > interested in is there.
> > >
> > > I think this can work by having .../smbios/<N>/{address,etc} in
> > > XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> > > smbios_type_vendor_oem_init, which I think could easily just be a
> > > single lump?
> > >
> > > I think you don't need the same thing for the ACPI side since there
> > > you just provide secondary tables?
> >
> > There could be quite a few SMBIOS tables being passed in. On the order
> > of 20 - 30 of them and thet are pretty small. It seems a bit odd to
> > break it up like this for lots of little chunks. There could be more
> > than one ACPI table also (multiple SSDTs and/or other static tables).
> > Also the OEM SMBIOS tables are all discrete and they could not go in
> > as a single lump.
> 
> I'm not sure if there are arguments here both for and against having a
> single smbios blob vs multiple?

Oh sorry. I am trying to answer 2 different things here. In summary what I would like to do is not make any distinction between vendor and predefined tables but rather send all SMBIOS tables in as a single lump with some sort of internal delimiter structs. If that is unacceptable then all the SMBIOS tables would be put in xenstore per what you said above (.../smbios/<N>/{address,etc}). It just seems odd to me to break up the (usually rather small and potentially numerous) SMBIOS tables into individual items passed in xenstore.

> 
> > > At the libxc layer you could have "struct xc_hvm_module *smbios". I
> > > expect in the simple case this would just point into an array on the
> > > callers stack but a caller could also do something more dynamic if
> > > they wanted to. If you think it would be useful then a linked-list
> > > thing here would also work.
> >
> > Again assuming the xenstore approach, I guess it would probably have
> > to be a linked list because there could be a fair number of them
> > (mainly SMBIOS).
> 
> This is userspace so an array of, say, 100 items isn't really much of a
> problem. But if a link list works better for your use cases then that's
> fine.
> 
> > >
> > > > Given all that, the only real issue I see at the moment is how to
> > > > deal with multiple entries within a blob that don't readily
> > > > specify their own lengths. I am in favor of a delimiting struct
> > > > with possibly a terminating form (like a flag). Then all we put in
> > > > xenstore is the gpe for each type.
> > > >
> > > > Finally I wanted to bring up again the idea of another helper
> > > > component (lib maybe) that can be used to build and glom (I like
> > > > that
> > > > word) modules. Note that in many cases the passed in firmware is
> > > > going to be pulled from the host firmware. I already have bunches
> > > > of codes that do that. Perhaps I should start an RFC thread for
> > > > that as a separate task? Thoughts on this?
> > >
> > > You mean some sort of libacpi / libsmbios type things, helper
> > > routines for parsing and manipulating tables etc? (such a thing
> > > doesn't already exist somewhere?)
> > >
> > > I suspect your usecases are the ones which would make most extensive
> > > use of such a thing but I also assume that at least some of it would
> > > be useful to any caller which was passing in these tables. If you
> > > want to maintain it within the Xen tree then that works for me.
> >
> > Yea along those lines. I was thinking of maybe a libxenhvm that had
> > utility routines for collecting the system firmware information that
> > one wanted to pass to a guest. It could also provide an API that
> > wrapped up the setting of the firmware values that hvmloader consumes
> > including the bits that are on the shared info page you want to get
> > rid of. The usefulness of this library is diminished if we go the all
> > xenstore route above so I am going to shelf this until that is
> > settled.
> 
> OK.
> 
> > Oh and yea, there are tools to get this information
> > (acpidump/dmidecode) but they unfortunately do not come in library
> > form or necessarily give you the desired output. And in newer kernels
> > ACPI/DMI is accessible through sysfs.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:29:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHd0G-0005aZ-BI; Tue, 10 Apr 2012 15:29:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SHd0F-0005aS-Gn
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:29:07 +0000
Received: from [85.158.139.83:48942] by server-10.bemta-5.messagelabs.com id
	C7/8D-08260-2C1548F4; Tue, 10 Apr 2012 15:29:06 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334071744!11927793!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30616 invoked from network); 10 Apr 2012 15:29:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189670171"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 11:28:53 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Tue, 10 Apr 2012
	11:28:53 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 10 Apr 2012 11:28:50 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0XJUFkbOKUDHZwTN6BtmHjb7LnvgAB6LRQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334067702.5394.18.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Tuesday, April 10, 2012 10:22 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > > I see. So you need to be able to find the individual tables so that
> > > smbios_type_<N>_init can check for an overriding table <N> in the
> > > passed-through tables, it seems reasonable to try and avoid needing
> > > to parse a big lump of tables each time to see if the one you are
> > > interested in is there.
> > >
> > > I think this can work by having .../smbios/<N>/{address,etc} in
> > > XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> > > smbios_type_vendor_oem_init, which I think could easily just be a
> > > single lump?
> > >
> > > I think you don't need the same thing for the ACPI side since there
> > > you just provide secondary tables?
> >
> > There could be quite a few SMBIOS tables being passed in. On the order
> > of 20 - 30 of them and thet are pretty small. It seems a bit odd to
> > break it up like this for lots of little chunks. There could be more
> > than one ACPI table also (multiple SSDTs and/or other static tables).
> > Also the OEM SMBIOS tables are all discrete and they could not go in
> > as a single lump.
> 
> I'm not sure if there are arguments here both for and against having a
> single smbios blob vs multiple?

Oh sorry. I am trying to answer 2 different things here. In summary what I would like to do is not make any distinction between vendor and predefined tables but rather send all SMBIOS tables in as a single lump with some sort of internal delimiter structs. If that is unacceptable then all the SMBIOS tables would be put in xenstore per what you said above (.../smbios/<N>/{address,etc}). It just seems odd to me to break up the (usually rather small and potentially numerous) SMBIOS tables into individual items passed in xenstore.

> 
> > > At the libxc layer you could have "struct xc_hvm_module *smbios". I
> > > expect in the simple case this would just point into an array on the
> > > callers stack but a caller could also do something more dynamic if
> > > they wanted to. If you think it would be useful then a linked-list
> > > thing here would also work.
> >
> > Again assuming the xenstore approach, I guess it would probably have
> > to be a linked list because there could be a fair number of them
> > (mainly SMBIOS).
> 
> This is userspace so an array of, say, 100 items isn't really much of a
> problem. But if a link list works better for your use cases then that's
> fine.
> 
> > >
> > > > Given all that, the only real issue I see at the moment is how to
> > > > deal with multiple entries within a blob that don't readily
> > > > specify their own lengths. I am in favor of a delimiting struct
> > > > with possibly a terminating form (like a flag). Then all we put in
> > > > xenstore is the gpe for each type.
> > > >
> > > > Finally I wanted to bring up again the idea of another helper
> > > > component (lib maybe) that can be used to build and glom (I like
> > > > that
> > > > word) modules. Note that in many cases the passed in firmware is
> > > > going to be pulled from the host firmware. I already have bunches
> > > > of codes that do that. Perhaps I should start an RFC thread for
> > > > that as a separate task? Thoughts on this?
> > >
> > > You mean some sort of libacpi / libsmbios type things, helper
> > > routines for parsing and manipulating tables etc? (such a thing
> > > doesn't already exist somewhere?)
> > >
> > > I suspect your usecases are the ones which would make most extensive
> > > use of such a thing but I also assume that at least some of it would
> > > be useful to any caller which was passing in these tables. If you
> > > want to maintain it within the Xen tree then that works for me.
> >
> > Yea along those lines. I was thinking of maybe a libxenhvm that had
> > utility routines for collecting the system firmware information that
> > one wanted to pass to a guest. It could also provide an API that
> > wrapped up the setting of the firmware values that hvmloader consumes
> > including the bits that are on the shared info page you want to get
> > rid of. The usefulness of this library is diminished if we go the all
> > xenstore route above so I am going to shelf this until that is
> > settled.
> 
> OK.
> 
> > Oh and yea, there are tools to get this information
> > (acpidump/dmidecode) but they unfortunately do not come in library
> > form or necessarily give you the desired output. And in newer kernels
> > ACPI/DMI is accessible through sysfs.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:33:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHd4S-0005uT-1T; Tue, 10 Apr 2012 15:33:28 +0000
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 1SHd4R-0005uK-4x
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:33:27 +0000
Received: from [193.109.254.147:29659] by server-2.bemta-14.messagelabs.com id
	93/F1-19409-6C2548F4; Tue, 10 Apr 2012 15:33:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334072005!3973130!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 10 Apr 2012 15:33:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 15:33:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 16:33:25 +0100
Message-Id: <4F846EE3020000780007D0F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 16:33:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334070786.5865.133.camel@hp6530s>
In-Reply-To: <1334070786.5865.133.camel@hp6530s>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> This new physdev_op is added for Linux guest kernel to get the correct
> nr_irqs_gsi value.

I'm not convinced this is really needed - the kernel can work out the
right number without any hypercall afaict.

Jan

> See below Linux kernel patch for detail explanation.
> 
> [RFC PATCH] xen: get correct nr_irqs_gsi value from hypervisor
> http://marc.info/?l=xen-devel&m=133407004503365&w=2 
> 
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
>  xen/arch/x86/physdev.c       |    8 ++++++++
>  xen/include/public/physdev.h |    6 ++++++
>  2 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index 05fff9e..0912db0 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -688,6 +688,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>                                setup_gsi.polarity);
>          break; 
>      }
> +    case PHYSDEVOP_nr_irqs_gsi: {
> +        struct physdev_nr_irqs_gsi out;
> +
> +        out.nr_irqs_gsi = nr_irqs_gsi;
> +        ret = copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
> +
> +        break;
> +    }
>      case PHYSDEVOP_get_free_pirq: {
>          struct physdev_get_free_pirq out;
>          struct domain *d;
> diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
> index b78eeba..7856fc2 100644
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -312,6 +312,12 @@ struct physdev_pci_device {
>  typedef struct physdev_pci_device physdev_pci_device_t;
>  DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
>  
> +#define PHYSDEVOP_nr_irqs_gsi           29
> +struct physdev_nr_irqs_gsi {
> +    /* OUT */
> +    uint32_t nr_irqs_gsi;
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.5
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:33:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHd4S-0005uT-1T; Tue, 10 Apr 2012 15:33:28 +0000
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 1SHd4R-0005uK-4x
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:33:27 +0000
Received: from [193.109.254.147:29659] by server-2.bemta-14.messagelabs.com id
	93/F1-19409-6C2548F4; Tue, 10 Apr 2012 15:33:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334072005!3973130!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=3.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 10 Apr 2012 15:33:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 15:33:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 16:33:25 +0100
Message-Id: <4F846EE3020000780007D0F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 16:33:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334070786.5865.133.camel@hp6530s>
In-Reply-To: <1334070786.5865.133.camel@hp6530s>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> This new physdev_op is added for Linux guest kernel to get the correct
> nr_irqs_gsi value.

I'm not convinced this is really needed - the kernel can work out the
right number without any hypercall afaict.

Jan

> See below Linux kernel patch for detail explanation.
> 
> [RFC PATCH] xen: get correct nr_irqs_gsi value from hypervisor
> http://marc.info/?l=xen-devel&m=133407004503365&w=2 
> 
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
>  xen/arch/x86/physdev.c       |    8 ++++++++
>  xen/include/public/physdev.h |    6 ++++++
>  2 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index 05fff9e..0912db0 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -688,6 +688,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>                                setup_gsi.polarity);
>          break; 
>      }
> +    case PHYSDEVOP_nr_irqs_gsi: {
> +        struct physdev_nr_irqs_gsi out;
> +
> +        out.nr_irqs_gsi = nr_irqs_gsi;
> +        ret = copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
> +
> +        break;
> +    }
>      case PHYSDEVOP_get_free_pirq: {
>          struct physdev_get_free_pirq out;
>          struct domain *d;
> diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
> index b78eeba..7856fc2 100644
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -312,6 +312,12 @@ struct physdev_pci_device {
>  typedef struct physdev_pci_device physdev_pci_device_t;
>  DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
>  
> +#define PHYSDEVOP_nr_irqs_gsi           29
> +struct physdev_nr_irqs_gsi {
> +    /* OUT */
> +    uint32_t nr_irqs_gsi;
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.5
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:39:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHd9w-00064m-QS; Tue, 10 Apr 2012 15:39:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHd9v-00064f-5W
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:39:07 +0000
Received: from [85.158.139.83:10686] by server-12.bemta-5.messagelabs.com id
	52/BA-05587-A14548F4; Tue, 10 Apr 2012 15:39:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334072345!15849736!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3194 invoked from network); 10 Apr 2012 15:39:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:39:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:39:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 16:39:05 +0100
Message-ID: <1334072343.5394.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 10 Apr 2012 16:39:03 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Tim
	Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:28 +0100, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: Tuesday, April 10, 2012 10:22 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > > > I see. So you need to be able to find the individual tables so that
> > > > smbios_type_<N>_init can check for an overriding table <N> in the
> > > > passed-through tables, it seems reasonable to try and avoid needing
> > > > to parse a big lump of tables each time to see if the one you are
> > > > interested in is there.
> > > >
> > > > I think this can work by having .../smbios/<N>/{address,etc} in
> > > > XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> > > > smbios_type_vendor_oem_init, which I think could easily just be a
> > > > single lump?
> > > >
> > > > I think you don't need the same thing for the ACPI side since there
> > > > you just provide secondary tables?
> > >
> > > There could be quite a few SMBIOS tables being passed in. On the order
> > > of 20 - 30 of them and thet are pretty small. It seems a bit odd to
> > > break it up like this for lots of little chunks. There could be more
> > > than one ACPI table also (multiple SSDTs and/or other static tables).
> > > Also the OEM SMBIOS tables are all discrete and they could not go in
> > > as a single lump.
> > 
> > I'm not sure if there are arguments here both for and against having a
> > single smbios blob vs multiple?
> 
> Oh sorry. I am trying to answer 2 different things here. In summary
> what I would like to do is not make any distinction between vendor and
> predefined tables but rather send all SMBIOS tables in as a single
> lump with some sort of internal delimiter structs. If that is
> unacceptable then all the SMBIOS tables would be put in xenstore per
> what you said above (.../smbios/<N>/{address,etc}). It just seems odd
> to me to break up the (usually rather small and potentially numerous)
> SMBIOS tables into individual items passed in xenstore.

What sort of delimiter were you thinking of? Perhaps something as simple
as:
	<length><blob><length><blob>
?

Or can you use the length field in the smbios entry header?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:39:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHd9w-00064m-QS; Tue, 10 Apr 2012 15:39:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHd9v-00064f-5W
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 15:39:07 +0000
Received: from [85.158.139.83:10686] by server-12.bemta-5.messagelabs.com id
	52/BA-05587-A14548F4; Tue, 10 Apr 2012 15:39:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334072345!15849736!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3194 invoked from network); 10 Apr 2012 15:39:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:39:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:39:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 16:39:05 +0100
Message-ID: <1334072343.5394.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 10 Apr 2012 16:39:03 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Tim
	Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:28 +0100, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: Tuesday, April 10, 2012 10:22 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > > > I see. So you need to be able to find the individual tables so that
> > > > smbios_type_<N>_init can check for an overriding table <N> in the
> > > > passed-through tables, it seems reasonable to try and avoid needing
> > > > to parse a big lump of tables each time to see if the one you are
> > > > interested in is there.
> > > >
> > > > I think this can work by having .../smbios/<N>/{address,etc} in
> > > > XenStore. You could also have .../smbios/OEM/{...} for the stuff for
> > > > smbios_type_vendor_oem_init, which I think could easily just be a
> > > > single lump?
> > > >
> > > > I think you don't need the same thing for the ACPI side since there
> > > > you just provide secondary tables?
> > >
> > > There could be quite a few SMBIOS tables being passed in. On the order
> > > of 20 - 30 of them and thet are pretty small. It seems a bit odd to
> > > break it up like this for lots of little chunks. There could be more
> > > than one ACPI table also (multiple SSDTs and/or other static tables).
> > > Also the OEM SMBIOS tables are all discrete and they could not go in
> > > as a single lump.
> > 
> > I'm not sure if there are arguments here both for and against having a
> > single smbios blob vs multiple?
> 
> Oh sorry. I am trying to answer 2 different things here. In summary
> what I would like to do is not make any distinction between vendor and
> predefined tables but rather send all SMBIOS tables in as a single
> lump with some sort of internal delimiter structs. If that is
> unacceptable then all the SMBIOS tables would be put in xenstore per
> what you said above (.../smbios/<N>/{address,etc}). It just seems odd
> to me to break up the (usually rather small and potentially numerous)
> SMBIOS tables into individual items passed in xenstore.

What sort of delimiter were you thinking of? Perhaps something as simple
as:
	<length><blob><length><blob>
?

Or can you use the length field in the smbios entry header?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdHZ-0006O5-Tl; Tue, 10 Apr 2012 15:47:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdHX-0006O0-Pa
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:46:59 +0000
Received: from [85.158.143.35:13339] by server-2.bemta-4.messagelabs.com id
	B6/C3-17550-3F5548F4; Tue, 10 Apr 2012 15:46:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334072818!11897420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1848 invoked from network); 10 Apr 2012 15:46:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:46:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860959"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:46:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 16:46:57 +0100
Date: Tue, 10 Apr 2012 16:50:25 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
References: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Jan Beulich wrote:
> - devices beyond xvdzz didn't get proper names assigned at all
> - extended devices with minors not representable within the kernel's
>   major/minor bit split spilled into foreign majors
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The patch is OK.

Would you be up for writing a couple of lines under Documentation to
clearly state what device names are going to be given by blkfront in
correspondence to vdev numbers?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdHZ-0006O5-Tl; Tue, 10 Apr 2012 15:47:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdHX-0006O0-Pa
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:46:59 +0000
Received: from [85.158.143.35:13339] by server-2.bemta-4.messagelabs.com id
	B6/C3-17550-3F5548F4; Tue, 10 Apr 2012 15:46:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334072818!11897420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1848 invoked from network); 10 Apr 2012 15:46:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:46:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11860959"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:46:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 16:46:57 +0100
Date: Tue, 10 Apr 2012 16:50:25 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
References: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 5 Apr 2012, Jan Beulich wrote:
> - devices beyond xvdzz didn't get proper names assigned at all
> - extended devices with minors not representable within the kernel's
>   major/minor bit split spilled into foreign majors
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The patch is OK.

Would you be up for writing a couple of lines under Documentation to
clearly state what device names are going to be given by blkfront in
correspondence to vdev numbers?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:50:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdKb-0006e4-CL; Tue, 10 Apr 2012 15:50:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHdKZ-0006dq-L6
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:50:07 +0000
Received: from [85.158.139.83:31432] by server-7.bemta-5.messagelabs.com id
	E4/16-16195-EA6548F4; Tue, 10 Apr 2012 15:50:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334073006!18931802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9228 invoked from network); 10 Apr 2012 15:50:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:50:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11861021"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:50:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 16:50:05 +0100
Message-ID: <1334073004.5394.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bart Van Assche <bvanassche@acm.org>
Date: Tue, 10 Apr 2012 16:50:04 +0100
In-Reply-To: <4F8455EE.8010709@acm.org>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<4F8455EE.8010709@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>, David
	VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:46 +0100, Bart Van Assche wrote:
> On 04/10/12 14:26, Ian Campbell wrote:
> 
> > I think this is v4, but I've sort of lost count, sorry that it's taken
> > me so long to get back to this stuff.
> > 
> > The following series makes use of the skb fragment API (which is in 3.2
> > +) to add a per-paged-fragment destructor callback. This can be used by
> > creators of skbs who are interested in the lifecycle of the pages
> > included in that skb after they have handed it off to the network stack.
> 
> 
> Hello Ian,
> 
> Great to see v4 of this patch series. But which kernel version has this
> patch series been based on ? I've tried to apply this series on 3.4-rc2

It's based on net-next/master. Specifically commit de8856d2c11f.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:50:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdKb-0006e4-CL; Tue, 10 Apr 2012 15:50:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHdKZ-0006dq-L6
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:50:07 +0000
Received: from [85.158.139.83:31432] by server-7.bemta-5.messagelabs.com id
	E4/16-16195-EA6548F4; Tue, 10 Apr 2012 15:50:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334073006!18931802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9228 invoked from network); 10 Apr 2012 15:50:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 15:50:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11861021"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:50:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 16:50:05 +0100
Message-ID: <1334073004.5394.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bart Van Assche <bvanassche@acm.org>
Date: Tue, 10 Apr 2012 16:50:04 +0100
In-Reply-To: <4F8455EE.8010709@acm.org>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<4F8455EE.8010709@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>, David
	VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:46 +0100, Bart Van Assche wrote:
> On 04/10/12 14:26, Ian Campbell wrote:
> 
> > I think this is v4, but I've sort of lost count, sorry that it's taken
> > me so long to get back to this stuff.
> > 
> > The following series makes use of the skb fragment API (which is in 3.2
> > +) to add a per-paged-fragment destructor callback. This can be used by
> > creators of skbs who are interested in the lifecycle of the pages
> > included in that skb after they have handed it off to the network stack.
> 
> 
> Hello Ian,
> 
> Great to see v4 of this patch series. But which kernel version has this
> patch series been based on ? I've tried to apply this series on 3.4-rc2

It's based on net-next/master. Specifically commit de8856d2c11f.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:51:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdLY-0006lx-RP; Tue, 10 Apr 2012 15:51:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHdLW-0006lc-UM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:51:07 +0000
Received: from [85.158.143.99:51349] by server-1.bemta-4.messagelabs.com id
	BC/61-20925-AE6548F4; Tue, 10 Apr 2012 15:51:06 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334073064!24494552!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14771 invoked from network); 10 Apr 2012 15:51:05 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-216.messagelabs.com with SMTP;
	10 Apr 2012 15:51:05 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 3F959DBC58;
	Tue, 10 Apr 2012 23:50:50 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F846EE3020000780007D0F7@nat28.tlf.novell.com>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
Date: Tue, 10 Apr 2012 23:50:08 +0800
Message-ID: <1334073008.9703.6.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > This new physdev_op is added for Linux guest kernel to get the correct
> > nr_irqs_gsi value.
> 
> I'm not convinced this is really needed - the kernel can work out the
> right number without any hypercall afaict.

In Linux kernel:

mp_register_ioapic(...):

        entries = io_apic_get_redir_entries(idx);
        gsi_cfg = mp_ioapic_gsi_routing(idx);
        gsi_cfg->gsi_base = gsi_base;
        gsi_cfg->gsi_end = gsi_base + entries - 1;

        /*
         * The number of IO-APIC IRQ registers (== #pins):
         */
        ioapics[idx].nr_registers = entries;

        if (gsi_cfg->gsi_end >= gsi_top)
                gsi_top = gsi_cfg->gsi_end + 1;

io_apic_get_redir_entries calls io_apic_read(), which returns wrong
value(0xFFFFFFFF) on Xen Dom0 kernel.

How can we get the correct gsi_top value, which is used to set
nr_irqs_gsi, without hypercall?

The problem here is we don't have a Xen version of io_apic_read in Linux
kernel.

Thanks,
Lin Ming

> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 15:51:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 15:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdLY-0006lx-RP; Tue, 10 Apr 2012 15:51:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHdLW-0006lc-UM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:51:07 +0000
Received: from [85.158.143.99:51349] by server-1.bemta-4.messagelabs.com id
	BC/61-20925-AE6548F4; Tue, 10 Apr 2012 15:51:06 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334073064!24494552!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14771 invoked from network); 10 Apr 2012 15:51:05 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-216.messagelabs.com with SMTP;
	10 Apr 2012 15:51:05 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 3F959DBC58;
	Tue, 10 Apr 2012 23:50:50 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F846EE3020000780007D0F7@nat28.tlf.novell.com>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
Date: Tue, 10 Apr 2012 23:50:08 +0800
Message-ID: <1334073008.9703.6.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > This new physdev_op is added for Linux guest kernel to get the correct
> > nr_irqs_gsi value.
> 
> I'm not convinced this is really needed - the kernel can work out the
> right number without any hypercall afaict.

In Linux kernel:

mp_register_ioapic(...):

        entries = io_apic_get_redir_entries(idx);
        gsi_cfg = mp_ioapic_gsi_routing(idx);
        gsi_cfg->gsi_base = gsi_base;
        gsi_cfg->gsi_end = gsi_base + entries - 1;

        /*
         * The number of IO-APIC IRQ registers (== #pins):
         */
        ioapics[idx].nr_registers = entries;

        if (gsi_cfg->gsi_end >= gsi_top)
                gsi_top = gsi_cfg->gsi_end + 1;

io_apic_get_redir_entries calls io_apic_read(), which returns wrong
value(0xFFFFFFFF) on Xen Dom0 kernel.

How can we get the correct gsi_top value, which is used to set
nr_irqs_gsi, without hypercall?

The problem here is we don't have a Xen version of io_apic_read in Linux
kernel.

Thanks,
Lin Ming

> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:02:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdWQ-0007aW-AQ; Tue, 10 Apr 2012 16:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHdWO-0007aR-Pb
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:02:20 +0000
Received: from [85.158.143.35:46365] by server-2.bemta-4.messagelabs.com id
	69/49-17550-B89548F4; Tue, 10 Apr 2012 16:02:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334073738!8201836!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2357 invoked from network); 10 Apr 2012 16:02:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 16:02:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 17:02:17 +0100
Message-Id: <4F8475A7020000780007D139@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 17:02:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 17:50, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Would you be up for writing a couple of lines under Documentation to
> clearly state what device names are going to be given by blkfront in
> correspondence to vdev numbers?

I'm not really eager to, and in order to be useful, this should imo include
the compat mapping, and specifically for this I'd prefer someone (you?)
who was involved in putting this together to do eventual write-ups for it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:02:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdWQ-0007aW-AQ; Tue, 10 Apr 2012 16:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHdWO-0007aR-Pb
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:02:20 +0000
Received: from [85.158.143.35:46365] by server-2.bemta-4.messagelabs.com id
	69/49-17550-B89548F4; Tue, 10 Apr 2012 16:02:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334073738!8201836!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2357 invoked from network); 10 Apr 2012 16:02:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Apr 2012 16:02:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 17:02:17 +0100
Message-Id: <4F8475A7020000780007D139@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 17:02:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 17:50, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Would you be up for writing a couple of lines under Documentation to
> clearly state what device names are going to be given by blkfront in
> correspondence to vdev numbers?

I'm not really eager to, and in order to be useful, this should imo include
the compat mapping, and specifically for this I'd prefer someone (you?)
who was involved in putting this together to do eventual write-ups for it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdgM-0007of-DJ; Tue, 10 Apr 2012 16:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdgK-0007oa-Kp
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:12:36 +0000
Received: from [193.109.254.147:23612] by server-7.bemta-14.messagelabs.com id
	3F/30-01627-3FB548F4; Tue, 10 Apr 2012 16:12:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334074355!3993708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23106 invoked from network); 10 Apr 2012 16:12:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11861929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 16:12:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 17:12:34 +0100
Date: Tue, 10 Apr 2012 17:16:01 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F8475A7020000780007D139@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1204101710010.15151@kaball-desktop>
References: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
	<4F8475A7020000780007D139@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 10 Apr 2012, Jan Beulich wrote:
> >>> On 10.04.12 at 17:50, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Would you be up for writing a couple of lines under Documentation to
> > clearly state what device names are going to be given by blkfront in
> > correspondence to vdev numbers?
> 
> I'm not really eager to, and in order to be useful, this should imo include
> the compat mapping, and specifically for this I'd prefer someone (you?)
> who was involved in putting this together to do eventual write-ups for it.
 
What compat mappings?
Do you mean the non-extended vdev names?

If you refer to the behavior of older kernels, I don't think it matters
here: the document is supposed to specify what the corresponding kernel
codebase does about xen block names, not what past kernels used to do.
Also, the Xen side vdev policy doesn't matter that much, because we
already clarified that it is up to the guest to choose whatever name it
wants for a given vdev.

In any case if you don't feel like writing it up, I'll do it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdgM-0007of-DJ; Tue, 10 Apr 2012 16:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdgK-0007oa-Kp
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:12:36 +0000
Received: from [193.109.254.147:23612] by server-7.bemta-14.messagelabs.com id
	3F/30-01627-3FB548F4; Tue, 10 Apr 2012 16:12:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334074355!3993708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23106 invoked from network); 10 Apr 2012 16:12:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11861929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 16:12:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 17:12:34 +0100
Date: Tue, 10 Apr 2012 17:16:01 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F8475A7020000780007D139@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1204101710010.15151@kaball-desktop>
References: <4F7DD852020000780007CC2A@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1204101645000.15151@kaball-desktop>
	<4F8475A7020000780007D139@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: properly name all devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 10 Apr 2012, Jan Beulich wrote:
> >>> On 10.04.12 at 17:50, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Would you be up for writing a couple of lines under Documentation to
> > clearly state what device names are going to be given by blkfront in
> > correspondence to vdev numbers?
> 
> I'm not really eager to, and in order to be useful, this should imo include
> the compat mapping, and specifically for this I'd prefer someone (you?)
> who was involved in putting this together to do eventual write-ups for it.
 
What compat mappings?
Do you mean the non-extended vdev names?

If you refer to the behavior of older kernels, I don't think it matters
here: the document is supposed to specify what the corresponding kernel
codebase does about xen block names, not what past kernels used to do.
Also, the Xen side vdev policy doesn't matter that much, because we
already clarified that it is up to the guest to choose whatever name it
wants for a given vdev.

In any case if you don't feel like writing it up, I'll do it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdlc-000859-4r; Tue, 10 Apr 2012 16:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdlb-00084n-7c
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:18:03 +0000
Received: from [85.158.143.99:12040] by server-3.bemta-4.messagelabs.com id
	DC/46-05853-A3D548F4; Tue, 10 Apr 2012 16:18:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334074680!19673744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 10 Apr 2012 16:18:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11862058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 16:18:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 17:18:00 +0100
Date: Tue, 10 Apr 2012 17:21:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Lin Ming <mlin@ss.pku.edu.cn>
In-Reply-To: <1334073008.9703.6.camel@hp6530s>
Message-ID: <alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 10 Apr 2012, Lin Ming wrote:
> On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > This new physdev_op is added for Linux guest kernel to get the correct
> > > nr_irqs_gsi value.
> > 
> > I'm not convinced this is really needed - the kernel can work out the
> > right number without any hypercall afaict.
> 
> In Linux kernel:
> 
> mp_register_ioapic(...):
> 
>         entries = io_apic_get_redir_entries(idx);
>         gsi_cfg = mp_ioapic_gsi_routing(idx);
>         gsi_cfg->gsi_base = gsi_base;
>         gsi_cfg->gsi_end = gsi_base + entries - 1;
> 
>         /*
>          * The number of IO-APIC IRQ registers (== #pins):
>          */
>         ioapics[idx].nr_registers = entries;
> 
>         if (gsi_cfg->gsi_end >= gsi_top)
>                 gsi_top = gsi_cfg->gsi_end + 1;
> 
> io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> value(0xFFFFFFFF) on Xen Dom0 kernel.
> 
> How can we get the correct gsi_top value, which is used to set
> nr_irqs_gsi, without hypercall?
> 
> The problem here is we don't have a Xen version of io_apic_read in Linux
> kernel.

Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdlc-000859-4r; Tue, 10 Apr 2012 16:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdlb-00084n-7c
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:18:03 +0000
Received: from [85.158.143.99:12040] by server-3.bemta-4.messagelabs.com id
	DC/46-05853-A3D548F4; Tue, 10 Apr 2012 16:18:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334074680!19673744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 10 Apr 2012 16:18:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11862058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 16:18:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 17:18:00 +0100
Date: Tue, 10 Apr 2012 17:21:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Lin Ming <mlin@ss.pku.edu.cn>
In-Reply-To: <1334073008.9703.6.camel@hp6530s>
Message-ID: <alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 10 Apr 2012, Lin Ming wrote:
> On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > This new physdev_op is added for Linux guest kernel to get the correct
> > > nr_irqs_gsi value.
> > 
> > I'm not convinced this is really needed - the kernel can work out the
> > right number without any hypercall afaict.
> 
> In Linux kernel:
> 
> mp_register_ioapic(...):
> 
>         entries = io_apic_get_redir_entries(idx);
>         gsi_cfg = mp_ioapic_gsi_routing(idx);
>         gsi_cfg->gsi_base = gsi_base;
>         gsi_cfg->gsi_end = gsi_base + entries - 1;
> 
>         /*
>          * The number of IO-APIC IRQ registers (== #pins):
>          */
>         ioapics[idx].nr_registers = entries;
> 
>         if (gsi_cfg->gsi_end >= gsi_top)
>                 gsi_top = gsi_cfg->gsi_end + 1;
> 
> io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> value(0xFFFFFFFF) on Xen Dom0 kernel.
> 
> How can we get the correct gsi_top value, which is used to set
> nr_irqs_gsi, without hypercall?
> 
> The problem here is we don't have a Xen version of io_apic_read in Linux
> kernel.

Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:22:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdpQ-0008EZ-PO; Tue, 10 Apr 2012 16:22:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdpP-0008ES-3V
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:21:59 +0000
Received: from [85.158.139.83:13702] by server-9.bemta-5.messagelabs.com id
	BC/3C-09826-62E548F4; Tue, 10 Apr 2012 16:21:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334074915!19325909!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32105 invoked from network); 10 Apr 2012 16:21:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:21:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24030591"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:21:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:21:52 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHdpD-0004DZ-II; Tue, 10 Apr 2012 17:21:47 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 10 Apr 2012 17:25:19 +0100
Message-ID: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME
	when sharing them
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Set pages as FOREIGN_FRAME whenever blkfront shares them with another
domain. Then when blkfront un-share them, also removes the
FOREIGN_FRAME_BIT from the p2m.

We do it so that when the source and the destination domain are the same
(blkfront connected to blkback in the same domain) we can more easily
recognize which ones are the source pfns and which ones are the
destination pfns (both are going to be pointing to the same mfns).

Without this patch enstablishing a connection between blkfront and QEMU
qdisk in the same domain causes QEMU to hang and never return.


Changes in v3:
- only set_phys_to_machine if xen_pv_domain.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/block/xen-blkfront.c |   33 ++++++++++++++++++++++++++++-----
 1 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..cabfbbb 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -262,7 +262,7 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode,
 static int blkif_queue_request(struct request *req)
 {
 	struct blkfront_info *info = req->rq_disk->private_data;
-	unsigned long buffer_mfn;
+	unsigned long buffer_mfn, buffer_pfn;
 	struct blkif_request *ring_req;
 	unsigned long id;
 	unsigned int fsect, lsect;
@@ -321,7 +321,8 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
+			buffer_pfn = page_to_pfn(sg_page(sg));
+			buffer_mfn = pfn_to_mfn(buffer_pfn);
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
 			/* install a grant reference. */
@@ -340,6 +341,17 @@ static int blkif_queue_request(struct request *req)
 						.gref       = ref,
 						.first_sect = fsect,
 						.last_sect  = lsect };
+			/* 
+			 * Set the page as foreign, considering that we are giving
+			 * it to a foreign domain.
+			 * This is important in case the destination domain is
+			 * ourselves, so that we can more easily recognize the
+			 * source pfn from destination pfn, both mapping to the same
+			 * mfn.
+			 */
+			if (xen_pv_domain())
+				set_phys_to_machine(buffer_pfn,
+						FOREIGN_FRAME(buffer_mfn));
 		}
 	}
 
@@ -715,8 +727,12 @@ static void blkif_completion(struct blk_shadow *s)
 	int i;
 	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
 	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
 		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+		if (xen_pv_domain())
+			set_phys_to_machine(s->frame[i],
+					get_phys_to_machine(s->frame[i]) & ~FOREIGN_FRAME_BIT);
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -1051,13 +1067,20 @@ static int blkif_recover(struct blkfront_info *info)
 		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
 
 		if (req->operation != BLKIF_OP_DISCARD) {
+			unsigned long buffer_pfn;
+			unsigned long buffer_mfn;
 		/* Rewrite any grant references invalidated by susp/resume. */
-			for (j = 0; j < req->u.rw.nr_segments; j++)
+			for (j = 0; j < req->u.rw.nr_segments; j++) {
+				buffer_pfn = info->shadow[req->u.rw.id].frame[j];
+				buffer_mfn = pfn_to_mfn(buffer_pfn);
 				gnttab_grant_foreign_access_ref(
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
-					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					buffer_mfn,
 					rq_data_dir(info->shadow[req->u.rw.id].request));
+				if (xen_pv_domain())
+					set_phys_to_machine(buffer_pfn, FOREIGN_FRAME(buffer_mfn));
+			}
 		}
 		info->shadow[req->u.rw.id].req = *req;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:22:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdpQ-0008EZ-PO; Tue, 10 Apr 2012 16:22:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdpP-0008ES-3V
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:21:59 +0000
Received: from [85.158.139.83:13702] by server-9.bemta-5.messagelabs.com id
	BC/3C-09826-62E548F4; Tue, 10 Apr 2012 16:21:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334074915!19325909!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32105 invoked from network); 10 Apr 2012 16:21:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:21:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24030591"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:21:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:21:52 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHdpD-0004DZ-II; Tue, 10 Apr 2012 17:21:47 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 10 Apr 2012 17:25:19 +0100
Message-ID: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME
	when sharing them
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Set pages as FOREIGN_FRAME whenever blkfront shares them with another
domain. Then when blkfront un-share them, also removes the
FOREIGN_FRAME_BIT from the p2m.

We do it so that when the source and the destination domain are the same
(blkfront connected to blkback in the same domain) we can more easily
recognize which ones are the source pfns and which ones are the
destination pfns (both are going to be pointing to the same mfns).

Without this patch enstablishing a connection between blkfront and QEMU
qdisk in the same domain causes QEMU to hang and never return.


Changes in v3:
- only set_phys_to_machine if xen_pv_domain.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/block/xen-blkfront.c |   33 ++++++++++++++++++++++++++++-----
 1 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..cabfbbb 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -262,7 +262,7 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode,
 static int blkif_queue_request(struct request *req)
 {
 	struct blkfront_info *info = req->rq_disk->private_data;
-	unsigned long buffer_mfn;
+	unsigned long buffer_mfn, buffer_pfn;
 	struct blkif_request *ring_req;
 	unsigned long id;
 	unsigned int fsect, lsect;
@@ -321,7 +321,8 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
+			buffer_pfn = page_to_pfn(sg_page(sg));
+			buffer_mfn = pfn_to_mfn(buffer_pfn);
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
 			/* install a grant reference. */
@@ -340,6 +341,17 @@ static int blkif_queue_request(struct request *req)
 						.gref       = ref,
 						.first_sect = fsect,
 						.last_sect  = lsect };
+			/* 
+			 * Set the page as foreign, considering that we are giving
+			 * it to a foreign domain.
+			 * This is important in case the destination domain is
+			 * ourselves, so that we can more easily recognize the
+			 * source pfn from destination pfn, both mapping to the same
+			 * mfn.
+			 */
+			if (xen_pv_domain())
+				set_phys_to_machine(buffer_pfn,
+						FOREIGN_FRAME(buffer_mfn));
 		}
 	}
 
@@ -715,8 +727,12 @@ static void blkif_completion(struct blk_shadow *s)
 	int i;
 	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
 	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
 		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+		if (xen_pv_domain())
+			set_phys_to_machine(s->frame[i],
+					get_phys_to_machine(s->frame[i]) & ~FOREIGN_FRAME_BIT);
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -1051,13 +1067,20 @@ static int blkif_recover(struct blkfront_info *info)
 		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
 
 		if (req->operation != BLKIF_OP_DISCARD) {
+			unsigned long buffer_pfn;
+			unsigned long buffer_mfn;
 		/* Rewrite any grant references invalidated by susp/resume. */
-			for (j = 0; j < req->u.rw.nr_segments; j++)
+			for (j = 0; j < req->u.rw.nr_segments; j++) {
+				buffer_pfn = info->shadow[req->u.rw.id].frame[j];
+				buffer_mfn = pfn_to_mfn(buffer_pfn);
 				gnttab_grant_foreign_access_ref(
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
-					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					buffer_mfn,
 					rq_data_dir(info->shadow[req->u.rw.id].request));
+				if (xen_pv_domain())
+					set_phys_to_machine(buffer_pfn, FOREIGN_FRAME(buffer_mfn));
+			}
 		}
 		info->shadow[req->u.rw.id].req = *req;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:26:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdtL-0008Nr-Pv; Tue, 10 Apr 2012 16:26:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdtK-0008NY-3g
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:26:02 +0000
Received: from [85.158.143.99:53271] by server-2.bemta-4.messagelabs.com id
	5E/C7-17550-91F548F4; Tue, 10 Apr 2012 16:26:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334075158!22514238!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24700 invoked from network); 10 Apr 2012 16:26:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:26:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24030726"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:25:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:25:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHdtA-0004H6-Lj; Tue, 10 Apr 2012 17:25:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 10 Apr 2012 17:29:34 +0100
Message-ID: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
	m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.

Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL.  Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
going to be batched together, otherwise they are issued one at a time.

Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
m2p_add/remove_override calls forces paravirt_lazy_mode to
PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.


Changes in v3:
- do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
can be called in interrupt context.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/block/xen-blkback/blkback.c |    2 ++
 drivers/xen/grant-table.c           |    8 ++++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 0088bf6..0453695 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -386,6 +386,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
+	arch_enter_lazy_mmu_mode();
 	for (i = 0; i < nseg; i++) {
 		if (unlikely(map[i].status != 0)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
@@ -410,6 +411,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 		seg[i].buf  = map[i].dev_bus_addr |
 			(req->u.rw.seg[i].first_sect << 9);
 	}
+	arch_leave_lazy_mmu_mode();
 	return ret;
 }
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b4d4eac..c7dc2d6 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -751,6 +751,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	arch_enter_lazy_mmu_mode();
+
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
 		if (map_ops[i].status)
@@ -769,6 +771,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			return ret;
 	}
 
+	arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
@@ -785,12 +789,16 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	arch_enter_lazy_mmu_mode();
+
 	for (i = 0; i < count; i++) {
 		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
 
+	arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:26:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdtL-0008Nr-Pv; Tue, 10 Apr 2012 16:26:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdtK-0008NY-3g
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:26:02 +0000
Received: from [85.158.143.99:53271] by server-2.bemta-4.messagelabs.com id
	5E/C7-17550-91F548F4; Tue, 10 Apr 2012 16:26:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334075158!22514238!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24700 invoked from network); 10 Apr 2012 16:26:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:26:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24030726"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:25:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:25:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHdtA-0004H6-Lj; Tue, 10 Apr 2012 17:25:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 10 Apr 2012 17:29:34 +0100
Message-ID: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
	m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.

Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL.  Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
going to be batched together, otherwise they are issued one at a time.

Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
m2p_add/remove_override calls forces paravirt_lazy_mode to
PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.


Changes in v3:
- do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
can be called in interrupt context.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/block/xen-blkback/blkback.c |    2 ++
 drivers/xen/grant-table.c           |    8 ++++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 0088bf6..0453695 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -386,6 +386,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
+	arch_enter_lazy_mmu_mode();
 	for (i = 0; i < nseg; i++) {
 		if (unlikely(map[i].status != 0)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
@@ -410,6 +411,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 		seg[i].buf  = map[i].dev_bus_addr |
 			(req->u.rw.seg[i].first_sect << 9);
 	}
+	arch_leave_lazy_mmu_mode();
 	return ret;
 }
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b4d4eac..c7dc2d6 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -751,6 +751,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	arch_enter_lazy_mmu_mode();
+
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
 		if (map_ops[i].status)
@@ -769,6 +771,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			return ret;
 	}
 
+	arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
@@ -785,12 +789,16 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	arch_enter_lazy_mmu_mode();
+
 	for (i = 0; i < count; i++) {
 		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
 
+	arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:26:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdtL-0008Nj-Ey; Tue, 10 Apr 2012 16:26:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdtJ-0008NY-J7
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:26:01 +0000
Received: from [85.158.143.99:53243] by server-2.bemta-4.messagelabs.com id
	AB/C7-17550-81F548F4; Tue, 10 Apr 2012 16:26:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334075158!22514238!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24672 invoked from network); 10 Apr 2012 16:26:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:26:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24030725"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:25:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:25:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHdtA-0004H6-NY; Tue, 10 Apr 2012 17:25:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 10 Apr 2012 17:29:35 +0100
Message-ID: <1334075375-25442-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/2] m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use list_for_each_entry_safe and remove the spin_lock acquisition in
m2p_find_override: getting stale entries is OK because we should never
get an m2p_find_override call looking for an entry that we are about to
add or delete.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/x86/xen/p2m.c |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7ece122..9092278 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -808,23 +808,18 @@ EXPORT_SYMBOL_GPL(m2p_remove_override);
 
 struct page *m2p_find_override(unsigned long mfn)
 {
-	unsigned long flags;
 	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
+	struct page *p, *t, *ret;
 
 	ret = NULL;
 
-	spin_lock_irqsave(&m2p_override_lock, flags);
-
-	list_for_each_entry(p, bucket, lru) {
+	list_for_each_entry_safe(p, t, bucket, lru) {
 		if (page_private(p) == mfn) {
 			ret = p;
 			break;
 		}
 	}
 
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
 	return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:26:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdtL-0008Nj-Ey; Tue, 10 Apr 2012 16:26:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHdtJ-0008NY-J7
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:26:01 +0000
Received: from [85.158.143.99:53243] by server-2.bemta-4.messagelabs.com id
	AB/C7-17550-81F548F4; Tue, 10 Apr 2012 16:26:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334075158!22514238!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24672 invoked from network); 10 Apr 2012 16:26:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:26:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="24030725"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:25:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:25:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHdtA-0004H6-NY; Tue, 10 Apr 2012 17:25:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 10 Apr 2012 17:29:35 +0100
Message-ID: <1334075375-25442-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/2] m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use list_for_each_entry_safe and remove the spin_lock acquisition in
m2p_find_override: getting stale entries is OK because we should never
get an m2p_find_override call looking for an entry that we are about to
add or delete.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/x86/xen/p2m.c |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 7ece122..9092278 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -808,23 +808,18 @@ EXPORT_SYMBOL_GPL(m2p_remove_override);
 
 struct page *m2p_find_override(unsigned long mfn)
 {
-	unsigned long flags;
 	struct list_head *bucket = &m2p_overrides[mfn_hash(mfn)];
-	struct page *p, *ret;
+	struct page *p, *t, *ret;
 
 	ret = NULL;
 
-	spin_lock_irqsave(&m2p_override_lock, flags);
-
-	list_for_each_entry(p, bucket, lru) {
+	list_for_each_entry_safe(p, t, bucket, lru) {
 		if (page_private(p) == mfn) {
 			ret = p;
 			break;
 		}
 	}
 
-	spin_unlock_irqrestore(&m2p_override_lock, flags);
-
 	return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:26:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:26:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdtz-0008TH-HQ; Tue, 10 Apr 2012 16:26:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHdty-0008Sq-IP
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:26:42 +0000
Received: from [85.158.138.51:36119] by server-3.bemta-3.messagelabs.com id
	EB/D7-04048-04F548F4; Tue, 10 Apr 2012 16:26:40 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334075198!21544804!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27774 invoked from network); 10 Apr 2012 16:26:39 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 16:26:39 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 4541BDBCAA;
	Wed, 11 Apr 2012 00:26:24 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334051539.12209.158.camel@dagon.hellion.org.uk>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>	<20120406183618.GA13473@phenom.dumpdata.com>
	<CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
	<1334051539.12209.158.camel@dagon.hellion.org.uk>
Date: Wed, 11 Apr 2012 00:25:42 +0800
Message-ID: <1334075142.10187.0.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 10:52 +0100, Ian Campbell wrote:
> On Sun, 2012-04-08 at 07:58 +0100, Lin Ming wrote:
> > On Sat, Apr 7, 2012 at 2:36 AM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > > On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
> > >> On 04/06/2012 10:41 AM, Lin Ming wrote:
> > >> >Hi list,
> > >> >
> > >> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
> > >> >
> > >> >There are 2 PMU related projects listed on GSoC 2012 page.
> > >> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> > >> >
> > >> >- Virtualization of the CPU Performance Monitoring Unit
> > >> >- Perf support for Xen
> > >> >
> > >> >I'm interested on these 2 projects.
> > >> Hi Lin,
> > >>
> > >> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
> > >> See
> > >> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> > >> 2. The PMU project description in the wiki is vague. I know HVM
> > >> guests support virtualized PMU. Please check vpmu.c files in /hvm,
> > >> /svm, and /vmx directories. You better ask mentors for details
> > >> (maybe this is XCP specific?).
> > >
> > > This is dom0 related. So being able to use perf to instrument
> > > the hypervisor (and the guests from dom0).
> > 
> > For guests instrument:
> > 
> > How about use perf on guests(domU) directly?
> 
> I guess that would be a subset of the dom0 support? e.g. the ability for
> a PV guest to run perf on itself.

Yes.

> 
> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:26:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:26:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdtz-0008TH-HQ; Tue, 10 Apr 2012 16:26:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHdty-0008Sq-IP
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:26:42 +0000
Received: from [85.158.138.51:36119] by server-3.bemta-3.messagelabs.com id
	EB/D7-04048-04F548F4; Tue, 10 Apr 2012 16:26:40 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334075198!21544804!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27774 invoked from network); 10 Apr 2012 16:26:39 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 16:26:39 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 4541BDBCAA;
	Wed, 11 Apr 2012 00:26:24 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334051539.12209.158.camel@dagon.hellion.org.uk>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>	<20120406183618.GA13473@phenom.dumpdata.com>
	<CAF1ivSYTaFOUA36hNNUtH9NtPW3VM=XV97m-daB-JgDjhPprxA@mail.gmail.com>
	<1334051539.12209.158.camel@dagon.hellion.org.uk>
Date: Wed, 11 Apr 2012 00:25:42 +0800
Message-ID: <1334075142.10187.0.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 10:52 +0100, Ian Campbell wrote:
> On Sun, 2012-04-08 at 07:58 +0100, Lin Ming wrote:
> > On Sat, Apr 7, 2012 at 2:36 AM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > > On Fri, Apr 06, 2012 at 11:43:00AM -0500, Wei Huang wrote:
> > >> On 04/06/2012 10:41 AM, Lin Ming wrote:
> > >> >Hi list,
> > >> >
> > >> >Is anybody working on virtualization of the CPU Performance Monitoring Unit?
> > >> >
> > >> >There are 2 PMU related projects listed on GSoC 2012 page.
> > >> >http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> > >> >
> > >> >- Virtualization of the CPU Performance Monitoring Unit
> > >> >- Perf support for Xen
> > >> >
> > >> >I'm interested on these 2 projects.
> > >> Hi Lin,
> > >>
> > >> 1. I don't think Xen was accepted as an organization for 2012 GSOC.
> > >> See
> > >> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> > >> 2. The PMU project description in the wiki is vague. I know HVM
> > >> guests support virtualized PMU. Please check vpmu.c files in /hvm,
> > >> /svm, and /vmx directories. You better ask mentors for details
> > >> (maybe this is XCP specific?).
> > >
> > > This is dom0 related. So being able to use perf to instrument
> > > the hypervisor (and the guests from dom0).
> > 
> > For guests instrument:
> > 
> > How about use perf on guests(domU) directly?
> 
> I guess that would be a subset of the dom0 support? e.g. the ability for
> a PV guest to run perf on itself.

Yes.

> 
> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdvA-0000Bt-Vr; Tue, 10 Apr 2012 16:27:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHdv9-0000Be-4B
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:27:55 +0000
Received: from [85.158.139.83:52124] by server-11.bemta-5.messagelabs.com id
	7B/41-12959-A8F548F4; Tue, 10 Apr 2012 16:27:54 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334075272!18609360!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5052 invoked from network); 10 Apr 2012 16:27:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 16:27:53 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 0C3D8DBCAA;
	Wed, 11 Apr 2012 00:27:40 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Marcus Granado <marcus.granado@citrix.com>
In-Reply-To: <4F84478A.5010701@citrix.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<4F84478A.5010701@citrix.com>
Date: Wed, 11 Apr 2012 00:26:58 +0800
Message-ID: <1334075218.10187.2.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:45 +0100, Marcus Granado wrote:
> On 08/04/12 07:48, Lin Ming wrote:
> >> 2. The PMU project description in the wiki is vague. I know HVM guests
> >> support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> >> directories. You better ask mentors for details (maybe this is XCP
> >> specific?).
> Yes, the description is vague, we should update the page. The idea was 
> to enable users to run hardware profilers in dom0 and in any domU, PV or 
> HVM. This would include implementing what is missing for dom0/PV 
> domains, and to confirm in HVM domains that profilers such as oprofile, 
> hwpmc, intel performance counter monitor at least are running without 
> problems in the existing vPMU implementation. The original idea was to 
> add support to XCP, but please feel free to add support to xen-unstable 
> and the latest linux kernel; XCP will use those at some point.

Thanks for the clarification.

I'll investigate this first.

> cheers,
> Marcus
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHdvA-0000Bt-Vr; Tue, 10 Apr 2012 16:27:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHdv9-0000Be-4B
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:27:55 +0000
Received: from [85.158.139.83:52124] by server-11.bemta-5.messagelabs.com id
	7B/41-12959-A8F548F4; Tue, 10 Apr 2012 16:27:54 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334075272!18609360!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5052 invoked from network); 10 Apr 2012 16:27:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-182.messagelabs.com with SMTP;
	10 Apr 2012 16:27:53 -0000
Received: from [192.168.1.200] (unknown [180.159.254.100])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 0C3D8DBCAA;
	Wed, 11 Apr 2012 00:27:40 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Marcus Granado <marcus.granado@citrix.com>
In-Reply-To: <4F84478A.5010701@citrix.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<4F84478A.5010701@citrix.com>
Date: Wed, 11 Apr 2012 00:26:58 +0800
Message-ID: <1334075218.10187.2.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 15:45 +0100, Marcus Granado wrote:
> On 08/04/12 07:48, Lin Ming wrote:
> >> 2. The PMU project description in the wiki is vague. I know HVM guests
> >> support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> >> directories. You better ask mentors for details (maybe this is XCP
> >> specific?).
> Yes, the description is vague, we should update the page. The idea was 
> to enable users to run hardware profilers in dom0 and in any domU, PV or 
> HVM. This would include implementing what is missing for dom0/PV 
> domains, and to confirm in HVM domains that profilers such as oprofile, 
> hwpmc, intel performance counter monitor at least are running without 
> problems in the existing vPMU implementation. The original idea was to 
> add support to XCP, but please feel free to add support to xen-unstable 
> and the latest linux kernel; XCP will use those at some point.

Thanks for the clarification.

I'll investigate this first.

> cheers,
> Marcus
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHe5t-0000Xe-5j; Tue, 10 Apr 2012 16:39:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHe5s-0000XZ-5Z
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:39:00 +0000
Received: from [85.158.138.51:47776] by server-4.bemta-3.messagelabs.com id
	6F/91-15341-322648F4; Tue, 10 Apr 2012 16:38:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334075936!21365728!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6957 invoked from network); 10 Apr 2012 16:38:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:38:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189685552"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:38:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:38:55 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHe5m-0004SX-N8;
	Tue, 10 Apr 2012 17:38:54 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 17:38:48 +0100
Message-ID: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] autoconf: use python-config when present,
	if not switch to distutils
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use python-config utility when possible, and if it is not present switch to
distutils.

Should fix the bug reported by Olaf Hering on SuSE.

Rerun autoconf after applying the patch.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>
---
 tools/m4/python_devel.m4 |   42 +++++++++++++++++++++++++-----------------
 1 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4
index 8bfcd0c..0a2202c 100644
--- a/tools/m4/python_devel.m4
+++ b/tools/m4/python_devel.m4
@@ -1,23 +1,31 @@
 AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
-ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("VERSION")'`
 ac_previous_cppflags=$CPPFLAGS
-CPPFLAGS="$CFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
-CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("CFLAGS")'`"
 ac_previous_ldflags=$LDFLAGS
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("LIBS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("SYSLIBS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
-    standard_lib=1) + "/config"'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("LINKFORSHARED")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("LDFLAGS")'`"
+ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("VERSION")'`
+AC_PATH_PROG([pyconfig], [$PYTHON-config], [no])
+AS_IF([test x"$pyconfig" == x"no"], [
+    dnl For those that don't have python-config
+    CPPFLAGS="$CFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
+    CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("CFLAGS")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("LIBS")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("SYSLIBS")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
+        standard_lib=1) + "/config"'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("LINKFORSHARED")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("LDFLAGS")'`"
+], [
+    dnl If python-config is found use it
+    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`"
+    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`"
+])
 
 AC_CHECK_HEADER([Python.h], [],
     [AC_MSG_ERROR([Unable to find Python development headers])],)
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHe5t-0000Xe-5j; Tue, 10 Apr 2012 16:39:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SHe5s-0000XZ-5Z
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 16:39:00 +0000
Received: from [85.158.138.51:47776] by server-4.bemta-3.messagelabs.com id
	6F/91-15341-322648F4; Tue, 10 Apr 2012 16:38:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334075936!21365728!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6957 invoked from network); 10 Apr 2012 16:38:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:38:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189685552"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 12:38:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 12:38:55 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SHe5m-0004SX-N8;
	Tue, 10 Apr 2012 17:38:54 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 17:38:48 +0100
Message-ID: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] autoconf: use python-config when present,
	if not switch to distutils
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use python-config utility when possible, and if it is not present switch to
distutils.

Should fix the bug reported by Olaf Hering on SuSE.

Rerun autoconf after applying the patch.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>
---
 tools/m4/python_devel.m4 |   42 +++++++++++++++++++++++++-----------------
 1 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4
index 8bfcd0c..0a2202c 100644
--- a/tools/m4/python_devel.m4
+++ b/tools/m4/python_devel.m4
@@ -1,23 +1,31 @@
 AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
-ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("VERSION")'`
 ac_previous_cppflags=$CPPFLAGS
-CPPFLAGS="$CFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
-CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("CFLAGS")'`"
 ac_previous_ldflags=$LDFLAGS
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("LIBS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("SYSLIBS")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
-    standard_lib=1) + "/config"'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("LINKFORSHARED")'`"
-LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
-    print distutils.sysconfig.get_config_var("LDFLAGS")'`"
+ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
+    print distutils.sysconfig.get_config_var("VERSION")'`
+AC_PATH_PROG([pyconfig], [$PYTHON-config], [no])
+AS_IF([test x"$pyconfig" == x"no"], [
+    dnl For those that don't have python-config
+    CPPFLAGS="$CFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
+    CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("CFLAGS")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("LIBS")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("SYSLIBS")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
+        standard_lib=1) + "/config"'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("LINKFORSHARED")'`"
+    LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
+        print distutils.sysconfig.get_config_var("LDFLAGS")'`"
+], [
+    dnl If python-config is found use it
+    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`"
+    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`"
+])
 
 AC_CHECK_HEADER([Python.h], [],
     [AC_MSG_ERROR([Unable to find Python development headers])],)
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHe7q-0000f4-Lr; Tue, 10 Apr 2012 16:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHe7o-0000et-Mz
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:41:01 +0000
Received: from [85.158.138.51:59363] by server-4.bemta-3.messagelabs.com id
	B0/C3-15341-B92648F4; Tue, 10 Apr 2012 16:40:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334076059!21509870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20932 invoked from network); 10 Apr 2012 16:40:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:40:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11862396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 16:40:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 17:40:58 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHe7m-0000zv-CV;
	Tue, 10 Apr 2012 16:40:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHe7m-0001TK-AX;
	Tue, 10 Apr 2012 17:40:58 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12630-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 17:40:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12630: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12630 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12630/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557
 test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 linux                258f742635360175564e9470eb060ff4d4b984e7
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHe7q-0000f4-Lr; Tue, 10 Apr 2012 16:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHe7o-0000et-Mz
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 16:41:01 +0000
Received: from [85.158.138.51:59363] by server-4.bemta-3.messagelabs.com id
	B0/C3-15341-B92648F4; Tue, 10 Apr 2012 16:40:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334076059!21509870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20932 invoked from network); 10 Apr 2012 16:40:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 16:40:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="11862396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 16:40:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 17:40:58 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHe7m-0000zv-CV;
	Tue, 10 Apr 2012 16:40:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHe7m-0001TK-AX;
	Tue, 10 Apr 2012 17:40:58 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12630-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 17:40:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12630: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12630 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12630/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557
 test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 linux                258f742635360175564e9470eb060ff4d4b984e7
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeMM-00010S-9B; Tue, 10 Apr 2012 16:56:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGQ6J-0000Kf-Ub
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 07:30:24 +0000
Received: from [85.158.143.99:29691] by server-3.bemta-4.messagelabs.com id
	64/EB-05853-F0DEF7F4; Sat, 07 Apr 2012 07:30:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333783822!22373951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30919 invoked from network); 7 Apr 2012 07:30:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 07:30:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 07:30:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	08:30:10 +0100
Message-ID: <1333783810.12209.99.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sat, 7 Apr 2012 08:30:10 +0100
In-Reply-To: <CAGkgU9X3oGe1dy9GXFjhmosopqqZDbr2YessWmne3cHcajfEdA@mail.gmail.com>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
	<1333356972.25602.11.camel@zakaz.uk.xensource.com>
	<20120402092105.GA25886@aepfle.de>
	<CAGkgU9X3oGe1dy9GXFjhmosopqqZDbr2YessWmne3cHcajfEdA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 10 Apr 2012 16:56:01 +0000
Cc: xen-users <xen-users@lists.xen.org>, Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Redirecting to xen-uers@ where this belongs.

On Sat, 2012-04-07 at 07:25 +0100, Mohit Dhingra wrote:
> Hi Ian/All,
> 
> I am sorry, I was mistaken by "For now, a 32 bits host environnment is
> necessary to build successfuly. building on a 64 bits host machine is
> not yet supported" in http://xen.org/products/xci_source.html
> 
> Well, I am now able to build the xen binary image xen4.1.2, (after
> installing the missing packages as suggested by you)
> 
> -rw-r--r--  1 root root   691748 Jul 27  2011 xen-4.0.2_52-0.2.1.gz
> lrwxrwxrwx  1 root root       21 Feb  9 23:49 xen-4.0.gz ->
> xen-4.0.2_52-0.2.1.gz
> -rw-r--r--  1 root root   734699 Apr  7 11:39 xen-4.1.2.gz
> lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.1.gz ->
> xen-4.1.2.gz
> lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.gz -> xen-4.1.2.gz
> 
> I earlier had the xen-4.0.2 installed through zypper in Dom0 (opensuse
> 11.4)

You removed this before installing 4.1?

> (cadlab:/srv/xen-4.1.2 # uname -a
> Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 +0100 x86_64
> x86_64 x86_64 GNU/Linux
> )
> 
> 
> But xm commands are not working now. 
> 
> cadlab:/srv/xen-4.1.2 # xm list
> Error: Unable to connect to xend: Connection refused. Is xend running?
> 
> Is it not compatible with the openSUSE11.4? Or is there something
> which I am missing out.

Please check the logs under /var/log/xen/ for clues.

Note that xm is going to be deprecated in 4.2 so you might want to
consider using the new xl toolstack instead.

Ian.

> 
> ---------------------------- 
> 
> Thanks & Regards
> Mohit Dhingra 
> +919611190435
> 
> 
> On 2 April 2012 14:51, Olaf Hering <olaf@aepfle.de> wrote:
>         On Mon, Apr 02, Ian Campbell wrote:
>         
>         > On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
>         > > Hello All,
>         > >
>         > > I am a newbie to Linux and Xen. I tried compiling Xen
>         Source code (I
>         > > want to make some changes and see how it works), but it
>         failed on my
>         > > system as it couldn't find gnu-stubs32.h. Later, on
>         looking at
>         > > Makefile, I figured out that for x86_64, it is not yet
>         supported !!
>         
>         
>         > WRT gnu-stubs32.h I suspect you are missing some -devel
>         package or
>         > other. I don't know about how SuSE lays things out but you
>         should locate
>         > the package containing this file and install it. Googling
>         suggests that
>         > perhaps you meant gnu/stubs32.h? In which case you probably
>         want to
>         > install glibc-devel.
>         
>         
>         Running configure and/or make in a 32bit shell is not needed.
>         "zypper in gcc-32bit glibc-devel-32bit" will install the
>         required
>         packages to compile the 32bit parts in the firmware.
>         
>         Olaf
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeMM-00010S-9B; Tue, 10 Apr 2012 16:56:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SGQ6J-0000Kf-Ub
	for xen-devel@lists.xensource.com; Sat, 07 Apr 2012 07:30:24 +0000
Received: from [85.158.143.99:29691] by server-3.bemta-4.messagelabs.com id
	64/EB-05853-F0DEF7F4; Sat, 07 Apr 2012 07:30:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1333783822!22373951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzI3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30919 invoked from network); 7 Apr 2012 07:30:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Apr 2012 07:30:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="11818656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Apr 2012 07:30:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 7 Apr 2012
	08:30:10 +0100
Message-ID: <1333783810.12209.99.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sat, 7 Apr 2012 08:30:10 +0100
In-Reply-To: <CAGkgU9X3oGe1dy9GXFjhmosopqqZDbr2YessWmne3cHcajfEdA@mail.gmail.com>
References: <CAGkgU9Ufs_LS-4RQj_3vbe4OognkJqxTCf1mJsUam_Tc0Qoe_g@mail.gmail.com>
	<1333356972.25602.11.camel@zakaz.uk.xensource.com>
	<20120402092105.GA25886@aepfle.de>
	<CAGkgU9X3oGe1dy9GXFjhmosopqqZDbr2YessWmne3cHcajfEdA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 10 Apr 2012 16:56:01 +0000
Cc: xen-users <xen-users@lists.xen.org>, Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] Xen Source code build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Redirecting to xen-uers@ where this belongs.

On Sat, 2012-04-07 at 07:25 +0100, Mohit Dhingra wrote:
> Hi Ian/All,
> 
> I am sorry, I was mistaken by "For now, a 32 bits host environnment is
> necessary to build successfuly. building on a 64 bits host machine is
> not yet supported" in http://xen.org/products/xci_source.html
> 
> Well, I am now able to build the xen binary image xen4.1.2, (after
> installing the missing packages as suggested by you)
> 
> -rw-r--r--  1 root root   691748 Jul 27  2011 xen-4.0.2_52-0.2.1.gz
> lrwxrwxrwx  1 root root       21 Feb  9 23:49 xen-4.0.gz ->
> xen-4.0.2_52-0.2.1.gz
> -rw-r--r--  1 root root   734699 Apr  7 11:39 xen-4.1.2.gz
> lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.1.gz ->
> xen-4.1.2.gz
> lrwxrwxrwx  1 root root       12 Apr  7 11:39 xen-4.gz -> xen-4.1.2.gz
> 
> I earlier had the xen-4.0.2 installed through zypper in Dom0 (opensuse
> 11.4)

You removed this before installing 4.1?

> (cadlab:/srv/xen-4.1.2 # uname -a
> Linux cadlab 2.6.37.6-0.11-xen #1 SMP 2011-12-19 23:39:38 +0100 x86_64
> x86_64 x86_64 GNU/Linux
> )
> 
> 
> But xm commands are not working now. 
> 
> cadlab:/srv/xen-4.1.2 # xm list
> Error: Unable to connect to xend: Connection refused. Is xend running?
> 
> Is it not compatible with the openSUSE11.4? Or is there something
> which I am missing out.

Please check the logs under /var/log/xen/ for clues.

Note that xm is going to be deprecated in 4.2 so you might want to
consider using the new xl toolstack instead.

Ian.

> 
> ---------------------------- 
> 
> Thanks & Regards
> Mohit Dhingra 
> +919611190435
> 
> 
> On 2 April 2012 14:51, Olaf Hering <olaf@aepfle.de> wrote:
>         On Mon, Apr 02, Ian Campbell wrote:
>         
>         > On Sun, 2012-04-01 at 06:34 +0100, Mohit Dhingra wrote:
>         > > Hello All,
>         > >
>         > > I am a newbie to Linux and Xen. I tried compiling Xen
>         Source code (I
>         > > want to make some changes and see how it works), but it
>         failed on my
>         > > system as it couldn't find gnu-stubs32.h. Later, on
>         looking at
>         > > Makefile, I figured out that for x86_64, it is not yet
>         supported !!
>         
>         
>         > WRT gnu-stubs32.h I suspect you are missing some -devel
>         package or
>         > other. I don't know about how SuSE lays things out but you
>         should locate
>         > the package containing this file and install it. Googling
>         suggests that
>         > perhaps you meant gnu/stubs32.h? In which case you probably
>         want to
>         > install glibc-devel.
>         
>         
>         Running configure and/or make in a 32bit shell is not needed.
>         "zypper in gcc-32bit glibc-devel-32bit" will install the
>         required
>         packages to compile the 32bit parts in the firmware.
>         
>         Olaf
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeMM-00010Z-LW; Tue, 10 Apr 2012 16:56:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7l-0000uR-Ph
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:56543] by server-3.bemta-4.messagelabs.com id
	86/E1-05853-194448F4; Tue, 10 Apr 2012 14:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32404 invoked from network); 10 Apr 2012 14:32:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657704"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:36 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-DZ;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:23 +0100
Message-ID: <1334067984-7706-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 10 Apr 2012 16:56:01 +0000
Cc: devel@driverdev.osuosl.org, rds-devel@oss.oracle.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Trond Myklebust <Trond.Myklebust@netapp.com>,
	James Morris <jmorris@namei.org>, xen-devel@lists.xen.org,
	cluster-devel@redhat.com, ocfs2-devel@oss.oracle.com,
	Patrick McHardy <kaber@trash.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org,
	David Miller <davem@davemloft.net>, drbd-user@lists.linbit.com,
	"Pekka Savola \(ipv6\)" <pekkas@netcore.fi>
Subject: [Xen-devel] [PATCH 09/10] net: add paged frag destructor support to
	kernel_sendpage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires adding a new argument to various sendpage hooks up and down the
stack. At the moment this parameter is always NULL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: drbd-user@lists.linbit.com
Cc: devel@driverdev.osuosl.org
Cc: cluster-devel@redhat.com
Cc: ocfs2-devel@oss.oracle.com
Cc: netdev@vger.kernel.org
Cc: ceph-devel@vger.kernel.org
Cc: rds-devel@oss.oracle.com
Cc: linux-nfs@vger.kernel.org
---
 drivers/block/drbd/drbd_main.c           |    1 +
 drivers/scsi/iscsi_tcp.c                 |    4 ++--
 drivers/scsi/iscsi_tcp.h                 |    3 ++-
 drivers/target/iscsi/iscsi_target_util.c |    3 ++-
 fs/dlm/lowcomms.c                        |    4 ++--
 fs/ocfs2/cluster/tcp.c                   |    1 +
 include/linux/net.h                      |    6 +++++-
 include/net/inet_common.h                |    4 +++-
 include/net/ip.h                         |    4 +++-
 include/net/sock.h                       |    8 +++++---
 include/net/tcp.h                        |    4 +++-
 net/ceph/messenger.c                     |    2 +-
 net/core/sock.c                          |    6 +++++-
 net/ipv4/af_inet.c                       |    9 ++++++---
 net/ipv4/ip_output.c                     |    6 ++++--
 net/ipv4/tcp.c                           |   24 +++++++++++++++---------
 net/ipv4/udp.c                           |   11 ++++++-----
 net/ipv4/udp_impl.h                      |    5 +++--
 net/rds/tcp_send.c                       |    1 +
 net/socket.c                             |   11 +++++++----
 net/sunrpc/svcsock.c                     |    6 +++---
 net/sunrpc/xprtsock.c                    |    2 +-
 22 files changed, 81 insertions(+), 44 deletions(-)

diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 211fc44..e70ba0c 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2584,6 +2584,7 @@ static int _drbd_send_page(struct drbd_conf *mdev, struct page *page,
 	set_fs(KERNEL_DS);
 	do {
 		sent = mdev->data.socket->ops->sendpage(mdev->data.socket, page,
+							NULL,
 							offset, len,
 							msg_flags);
 		if (sent == -EAGAIN) {
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 453a740..df9f7dd 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -284,8 +284,8 @@ static int iscsi_sw_tcp_xmit_segment(struct iscsi_tcp_conn *tcp_conn,
 		if (!segment->data) {
 			sg = segment->sg;
 			offset += segment->sg_offset + sg->offset;
-			r = tcp_sw_conn->sendpage(sk, sg_page(sg), offset,
-						  copy, flags);
+			r = tcp_sw_conn->sendpage(sk, sg_page(sg), NULL,
+						  offset, copy, flags);
 		} else {
 			struct msghdr msg = { .msg_flags = flags };
 			struct kvec iov = {
diff --git a/drivers/scsi/iscsi_tcp.h b/drivers/scsi/iscsi_tcp.h
index 666fe09..1e23265 100644
--- a/drivers/scsi/iscsi_tcp.h
+++ b/drivers/scsi/iscsi_tcp.h
@@ -52,7 +52,8 @@ struct iscsi_sw_tcp_conn {
 	uint32_t		sendpage_failures_cnt;
 	uint32_t		discontiguous_hdr_cnt;
 
-	ssize_t (*sendpage)(struct socket *, struct page *, int, size_t, int);
+	ssize_t (*sendpage)(struct socket *, struct page *,
+			    struct skb_frag_destructor *, int, size_t, int);
 };
 
 struct iscsi_sw_tcp_host {
diff --git a/drivers/target/iscsi/iscsi_target_util.c b/drivers/target/iscsi/iscsi_target_util.c
index 4eba86d..d876dae 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -1323,7 +1323,8 @@ send_hdr:
 		u32 sub_len = min_t(u32, data_len, space);
 send_pg:
 		tx_sent = conn->sock->ops->sendpage(conn->sock,
-					sg_page(sg), sg->offset + offset, sub_len, 0);
+					sg_page(sg), NULL,
+					sg->offset + offset, sub_len, 0);
 		if (tx_sent != sub_len) {
 			if (tx_sent == -EAGAIN) {
 				pr_err("tcp_sendpage() returned"
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 133ef6d..0673cea 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1336,8 +1336,8 @@ static void send_to_sock(struct connection *con)
 
 		ret = 0;
 		if (len) {
-			ret = kernel_sendpage(con->sock, e->page, offset, len,
-					      msg_flags);
+			ret = kernel_sendpage(con->sock, e->page, NULL,
+					      offset, len, msg_flags);
 			if (ret == -EAGAIN || ret == 0) {
 				if (ret == -EAGAIN &&
 				    test_bit(SOCK_ASYNC_NOSPACE, &con->sock->flags) &&
diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index 044e7b5..e13851e 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
@@ -983,6 +983,7 @@ static void o2net_sendpage(struct o2net_sock_container *sc,
 		mutex_lock(&sc->sc_send_lock);
 		ret = sc->sc_sock->ops->sendpage(sc->sc_sock,
 						 virt_to_page(kmalloced_virt),
+						 NULL,
 						 (long)kmalloced_virt & ~PAGE_MASK,
 						 size, MSG_DONTWAIT);
 		mutex_unlock(&sc->sc_send_lock);
diff --git a/include/linux/net.h b/include/linux/net.h
index be60c7f..d9b0d648 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -157,6 +157,7 @@ struct kiocb;
 struct sockaddr;
 struct msghdr;
 struct module;
+struct skb_frag_destructor;
 
 struct proto_ops {
 	int		family;
@@ -203,6 +204,7 @@ struct proto_ops {
 	int		(*mmap)	     (struct file *file, struct socket *sock,
 				      struct vm_area_struct * vma);
 	ssize_t		(*sendpage)  (struct socket *sock, struct page *page,
+				      struct skb_frag_destructor *destroy,
 				      int offset, size_t size, int flags);
 	ssize_t 	(*splice_read)(struct socket *sock,  loff_t *ppos,
 				       struct pipe_inode_info *pipe, size_t len, unsigned int flags);
@@ -274,7 +276,9 @@ extern int kernel_getsockopt(struct socket *sock, int level, int optname,
 			     char *optval, int *optlen);
 extern int kernel_setsockopt(struct socket *sock, int level, int optname,
 			     char *optval, unsigned int optlen);
-extern int kernel_sendpage(struct socket *sock, struct page *page, int offset,
+extern int kernel_sendpage(struct socket *sock, struct page *page,
+			   struct skb_frag_destructor *destroy,
+			   int offset,
 			   size_t size, int flags);
 extern int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
 extern int kernel_sock_shutdown(struct socket *sock,
diff --git a/include/net/inet_common.h b/include/net/inet_common.h
index 22fac98..91cd8d0 100644
--- a/include/net/inet_common.h
+++ b/include/net/inet_common.h
@@ -21,7 +21,9 @@ extern int inet_dgram_connect(struct socket *sock, struct sockaddr * uaddr,
 extern int inet_accept(struct socket *sock, struct socket *newsock, int flags);
 extern int inet_sendmsg(struct kiocb *iocb, struct socket *sock,
 			struct msghdr *msg, size_t size);
-extern ssize_t inet_sendpage(struct socket *sock, struct page *page, int offset,
+extern ssize_t inet_sendpage(struct socket *sock, struct page *page,
+			     struct skb_frag_destructor *frag,
+			     int offset,
 			     size_t size, int flags);
 extern int inet_recvmsg(struct kiocb *iocb, struct socket *sock,
 			struct msghdr *msg, size_t size, int flags);
diff --git a/include/net/ip.h b/include/net/ip.h
index b53d65f..6bf9926 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -114,7 +114,9 @@ extern int		ip_append_data(struct sock *sk, struct flowi4 *fl4,
 				struct rtable **rt,
 				unsigned int flags);
 extern int		ip_generic_getfrag(void *from, char *to, int offset, int len, int odd, struct sk_buff *skb);
-extern ssize_t		ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
+extern ssize_t		ip_append_page(struct sock *sk, struct flowi4 *fl4,
+				struct page *page,
+				struct skb_frag_destructor *destroy,
 				int offset, size_t size, int flags);
 extern struct sk_buff  *__ip_make_skb(struct sock *sk,
 				      struct flowi4 *fl4,
diff --git a/include/net/sock.h b/include/net/sock.h
index a6ba1f8..c927997 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -834,6 +834,7 @@ struct proto {
 					size_t len, int noblock, int flags, 
 					int *addr_len);
 	int			(*sendpage)(struct sock *sk, struct page *page,
+					struct skb_frag_destructor *destroy,
 					int offset, size_t size, int flags);
 	int			(*bind)(struct sock *sk, 
 					struct sockaddr *uaddr, int addr_len);
@@ -1452,9 +1453,10 @@ extern int			sock_no_mmap(struct file *file,
 					     struct socket *sock,
 					     struct vm_area_struct *vma);
 extern ssize_t			sock_no_sendpage(struct socket *sock,
-						struct page *page,
-						int offset, size_t size, 
-						int flags);
+					struct page *page,
+					struct skb_frag_destructor *destroy,
+					int offset, size_t size,
+					int flags);
 
 /*
  * Functions to fill in entries in struct proto_ops when a protocol
diff --git a/include/net/tcp.h b/include/net/tcp.h
index f75a04d..7536266 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -331,7 +331,9 @@ extern void *tcp_v4_tw_get_peer(struct sock *sk);
 extern int tcp_v4_tw_remember_stamp(struct inet_timewait_sock *tw);
 extern int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 		       size_t size);
-extern int tcp_sendpage(struct sock *sk, struct page *page, int offset,
+extern int tcp_sendpage(struct sock *sk, struct page *page,
+			struct skb_frag_destructor *destroy,
+			int offset,
 			size_t size, int flags);
 extern int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg);
 extern int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index ad5b708..69f049b 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -851,7 +851,7 @@ static int write_partial_msg_pages(struct ceph_connection *con)
 				cpu_to_le32(crc32c(tmpcrc, base, len));
 			con->out_msg_pos.did_page_crc = 1;
 		}
-		ret = kernel_sendpage(con->sock, page,
+		ret = kernel_sendpage(con->sock, page, NULL,
 				      con->out_msg_pos.page_pos + page_shift,
 				      len,
 				      MSG_DONTWAIT | MSG_NOSIGNAL |
diff --git a/net/core/sock.c b/net/core/sock.c
index 9be6d0d..f56fc8c 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1965,7 +1965,9 @@ int sock_no_mmap(struct file *file, struct socket *sock, struct vm_area_struct *
 }
 EXPORT_SYMBOL(sock_no_mmap);
 
-ssize_t sock_no_sendpage(struct socket *sock, struct page *page, int offset, size_t size, int flags)
+ssize_t sock_no_sendpage(struct socket *sock, struct page *page,
+			 struct skb_frag_destructor *destroy,
+			 int offset, size_t size, int flags)
 {
 	ssize_t res;
 	struct msghdr msg = {.msg_flags = flags};
@@ -1975,6 +1977,8 @@ ssize_t sock_no_sendpage(struct socket *sock, struct page *page, int offset, siz
 	iov.iov_len = size;
 	res = kernel_sendmsg(sock, &msg, &iov, 1, size);
 	kunmap(page);
+	/* kernel_sendmsg copies so we can destroy immediately */
+	skb_frag_destructor_unref(destroy);
 	return res;
 }
 EXPORT_SYMBOL(sock_no_sendpage);
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index fdf49fd..e55a6e1 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -748,7 +748,9 @@ int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
 }
 EXPORT_SYMBOL(inet_sendmsg);
 
-ssize_t inet_sendpage(struct socket *sock, struct page *page, int offset,
+ssize_t inet_sendpage(struct socket *sock, struct page *page,
+		      struct skb_frag_destructor *destroy,
+		      int offset,
 		      size_t size, int flags)
 {
 	struct sock *sk = sock->sk;
@@ -761,8 +763,9 @@ ssize_t inet_sendpage(struct socket *sock, struct page *page, int offset,
 		return -EAGAIN;
 
 	if (sk->sk_prot->sendpage)
-		return sk->sk_prot->sendpage(sk, page, offset, size, flags);
-	return sock_no_sendpage(sock, page, offset, size, flags);
+		return sk->sk_prot->sendpage(sk, page, destroy,
+					     offset, size, flags);
+	return sock_no_sendpage(sock, page, destroy, offset, size, flags);
 }
 EXPORT_SYMBOL(inet_sendpage);
 
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 9e4eca6..2ce0b8e 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1130,6 +1130,7 @@ int ip_append_data(struct sock *sk, struct flowi4 *fl4,
 }
 
 ssize_t	ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
+		       struct skb_frag_destructor *destroy,
 		       int offset, size_t size, int flags)
 {
 	struct inet_sock *inet = inet_sk(sk);
@@ -1243,11 +1244,12 @@ ssize_t	ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
 		i = skb_shinfo(skb)->nr_frags;
 		if (len > size)
 			len = size;
-		if (skb_can_coalesce(skb, i, page, NULL, offset)) {
+		if (skb_can_coalesce(skb, i, page, destroy, offset)) {
 			skb_frag_size_add(&skb_shinfo(skb)->frags[i-1], len);
 		} else if (i < MAX_SKB_FRAGS) {
-			get_page(page);
 			skb_fill_page_desc(skb, i, page, offset, len);
+			skb_frag_set_destructor(skb, i, destroy);
+			skb_frag_ref(skb, i);
 		} else {
 			err = -EMSGSIZE;
 			goto error;
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b1612e9..89d4db0 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -757,8 +757,11 @@ static int tcp_send_mss(struct sock *sk, int *size_goal, int flags)
 	return mss_now;
 }
 
-static ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffset,
-			 size_t psize, int flags)
+static ssize_t do_tcp_sendpages(struct sock *sk,
+				struct page **pages,
+				struct skb_frag_destructor *destroy,
+				int poffset,
+				size_t psize, int flags)
 {
 	struct tcp_sock *tp = tcp_sk(sk);
 	int mss_now, size_goal;
@@ -804,7 +807,7 @@ new_segment:
 			copy = size;
 
 		i = skb_shinfo(skb)->nr_frags;
-		can_coalesce = skb_can_coalesce(skb, i, page, NULL, offset);
+		can_coalesce = skb_can_coalesce(skb, i, page, destroy, offset);
 		if (!can_coalesce && i >= MAX_SKB_FRAGS) {
 			tcp_mark_push(tp, skb);
 			goto new_segment;
@@ -815,8 +818,9 @@ new_segment:
 		if (can_coalesce) {
 			skb_frag_size_add(&skb_shinfo(skb)->frags[i - 1], copy);
 		} else {
-			get_page(page);
 			skb_fill_page_desc(skb, i, page, offset, copy);
+			skb_frag_set_destructor(skb, i, destroy);
+			skb_frag_ref(skb, i);
 		}
 
 		skb->len += copy;
@@ -871,18 +875,20 @@ out_err:
 	return sk_stream_error(sk, flags, err);
 }
 
-int tcp_sendpage(struct sock *sk, struct page *page, int offset,
-		 size_t size, int flags)
+int tcp_sendpage(struct sock *sk, struct page *page,
+		 struct skb_frag_destructor *destroy,
+		 int offset, size_t size, int flags)
 {
 	ssize_t res;
 
 	if (!(sk->sk_route_caps & NETIF_F_SG) ||
 	    !(sk->sk_route_caps & NETIF_F_ALL_CSUM))
-		return sock_no_sendpage(sk->sk_socket, page, offset, size,
-					flags);
+		return sock_no_sendpage(sk->sk_socket, page, destroy,
+					offset, size, flags);
 
 	lock_sock(sk);
-	res = do_tcp_sendpages(sk, &page, offset, size, flags);
+	res = do_tcp_sendpages(sk, &page, destroy,
+			       offset, size, flags);
 	release_sock(sk);
 	return res;
 }
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index d6f5fee..f9038e4 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1032,8 +1032,9 @@ do_confirm:
 }
 EXPORT_SYMBOL(udp_sendmsg);
 
-int udp_sendpage(struct sock *sk, struct page *page, int offset,
-		 size_t size, int flags)
+int udp_sendpage(struct sock *sk, struct page *page,
+		 struct skb_frag_destructor *destroy,
+		 int offset, size_t size, int flags)
 {
 	struct inet_sock *inet = inet_sk(sk);
 	struct udp_sock *up = udp_sk(sk);
@@ -1061,11 +1062,11 @@ int udp_sendpage(struct sock *sk, struct page *page, int offset,
 	}
 
 	ret = ip_append_page(sk, &inet->cork.fl.u.ip4,
-			     page, offset, size, flags);
+			     page, destroy, offset, size, flags);
 	if (ret == -EOPNOTSUPP) {
 		release_sock(sk);
-		return sock_no_sendpage(sk->sk_socket, page, offset,
-					size, flags);
+		return sock_no_sendpage(sk->sk_socket, page, destroy,
+					offset, size, flags);
 	}
 	if (ret < 0) {
 		udp_flush_pending_frames(sk);
diff --git a/net/ipv4/udp_impl.h b/net/ipv4/udp_impl.h
index aaad650..4923d82 100644
--- a/net/ipv4/udp_impl.h
+++ b/net/ipv4/udp_impl.h
@@ -23,8 +23,9 @@ extern int	compat_udp_getsockopt(struct sock *sk, int level, int optname,
 #endif
 extern int	udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 			    size_t len, int noblock, int flags, int *addr_len);
-extern int	udp_sendpage(struct sock *sk, struct page *page, int offset,
-			     size_t size, int flags);
+extern int	udp_sendpage(struct sock *sk, struct page *page,
+			     struct skb_frag_destructor *destroy,
+			     int offset, size_t size, int flags);
 extern int	udp_queue_rcv_skb(struct sock * sk, struct sk_buff *skb);
 extern void	udp_destroy_sock(struct sock *sk);
 
diff --git a/net/rds/tcp_send.c b/net/rds/tcp_send.c
index 1b4fd68..71503ad 100644
--- a/net/rds/tcp_send.c
+++ b/net/rds/tcp_send.c
@@ -119,6 +119,7 @@ int rds_tcp_xmit(struct rds_connection *conn, struct rds_message *rm,
 	while (sg < rm->data.op_nents) {
 		ret = tc->t_sock->ops->sendpage(tc->t_sock,
 						sg_page(&rm->data.op_sg[sg]),
+						NULL,
 						rm->data.op_sg[sg].offset + off,
 						rm->data.op_sg[sg].length - off,
 						MSG_DONTWAIT|MSG_NOSIGNAL);
diff --git a/net/socket.c b/net/socket.c
index 12a48d8..d0c0d8d 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -815,7 +815,7 @@ static ssize_t sock_sendpage(struct file *file, struct page *page,
 	if (more)
 		flags |= MSG_MORE;
 
-	return kernel_sendpage(sock, page, offset, size, flags);
+	return kernel_sendpage(sock, page, NULL, offset, size, flags);
 }
 
 static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
@@ -3350,15 +3350,18 @@ int kernel_setsockopt(struct socket *sock, int level, int optname,
 }
 EXPORT_SYMBOL(kernel_setsockopt);
 
-int kernel_sendpage(struct socket *sock, struct page *page, int offset,
+int kernel_sendpage(struct socket *sock, struct page *page,
+		    struct skb_frag_destructor *destroy,
+		    int offset,
 		    size_t size, int flags)
 {
 	sock_update_classid(sock->sk);
 
 	if (sock->ops->sendpage)
-		return sock->ops->sendpage(sock, page, offset, size, flags);
+		return sock->ops->sendpage(sock, page, destroy,
+					   offset, size, flags);
 
-	return sock_no_sendpage(sock, page, offset, size, flags);
+	return sock_no_sendpage(sock, page, destroy, offset, size, flags);
 }
 EXPORT_SYMBOL(kernel_sendpage);
 
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 40ae884..706305b 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -185,7 +185,7 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 	/* send head */
 	if (slen == xdr->head[0].iov_len)
 		flags = 0;
-	len = kernel_sendpage(sock, headpage, headoffset,
+	len = kernel_sendpage(sock, headpage, NULL, headoffset,
 				  xdr->head[0].iov_len, flags);
 	if (len != xdr->head[0].iov_len)
 		goto out;
@@ -198,7 +198,7 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 	while (pglen > 0) {
 		if (slen == size)
 			flags = 0;
-		result = kernel_sendpage(sock, *ppage, base, size, flags);
+		result = kernel_sendpage(sock, *ppage, NULL, base, size, flags);
 		if (result > 0)
 			len += result;
 		if (result != size)
@@ -212,7 +212,7 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 
 	/* send tail */
 	if (xdr->tail[0].iov_len) {
-		result = kernel_sendpage(sock, tailpage, tailoffset,
+		result = kernel_sendpage(sock, tailpage, NULL, tailoffset,
 				   xdr->tail[0].iov_len, 0);
 		if (result > 0)
 			len += result;
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 92bc518..f05082b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -408,7 +408,7 @@ static int xs_send_pagedata(struct socket *sock, struct xdr_buf *xdr, unsigned i
 		remainder -= len;
 		if (remainder != 0 || more)
 			flags |= MSG_MORE;
-		err = sock->ops->sendpage(sock, *ppage, base, len, flags);
+		err = sock->ops->sendpage(sock, *ppage, NULL, base, len, flags);
 		if (remainder == 0 || err != len)
 			break;
 		sent += err;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeMM-00010Z-LW; Tue, 10 Apr 2012 16:56:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHc7l-0000uR-Ph
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 14:32:50 +0000
Received: from [85.158.143.35:56543] by server-3.bemta-4.messagelabs.com id
	86/E1-05853-194448F4; Tue, 10 Apr 2012 14:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334068357!12610195!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32404 invoked from network); 10 Apr 2012 14:32:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 14:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189657704"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 10:31:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 10:31:36 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SHc1Z-0001r9-DZ;
	Tue, 10 Apr 2012 15:26:25 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Tue, 10 Apr 2012 15:26:23 +0100
Message-ID: <1334067984-7706-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 10 Apr 2012 16:56:01 +0000
Cc: devel@driverdev.osuosl.org, rds-devel@oss.oracle.com,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Trond Myklebust <Trond.Myklebust@netapp.com>,
	James Morris <jmorris@namei.org>, xen-devel@lists.xen.org,
	cluster-devel@redhat.com, ocfs2-devel@oss.oracle.com,
	Patrick McHardy <kaber@trash.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org,
	David Miller <davem@davemloft.net>, drbd-user@lists.linbit.com,
	"Pekka Savola \(ipv6\)" <pekkas@netcore.fi>
Subject: [Xen-devel] [PATCH 09/10] net: add paged frag destructor support to
	kernel_sendpage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires adding a new argument to various sendpage hooks up and down the
stack. At the moment this parameter is always NULL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: drbd-user@lists.linbit.com
Cc: devel@driverdev.osuosl.org
Cc: cluster-devel@redhat.com
Cc: ocfs2-devel@oss.oracle.com
Cc: netdev@vger.kernel.org
Cc: ceph-devel@vger.kernel.org
Cc: rds-devel@oss.oracle.com
Cc: linux-nfs@vger.kernel.org
---
 drivers/block/drbd/drbd_main.c           |    1 +
 drivers/scsi/iscsi_tcp.c                 |    4 ++--
 drivers/scsi/iscsi_tcp.h                 |    3 ++-
 drivers/target/iscsi/iscsi_target_util.c |    3 ++-
 fs/dlm/lowcomms.c                        |    4 ++--
 fs/ocfs2/cluster/tcp.c                   |    1 +
 include/linux/net.h                      |    6 +++++-
 include/net/inet_common.h                |    4 +++-
 include/net/ip.h                         |    4 +++-
 include/net/sock.h                       |    8 +++++---
 include/net/tcp.h                        |    4 +++-
 net/ceph/messenger.c                     |    2 +-
 net/core/sock.c                          |    6 +++++-
 net/ipv4/af_inet.c                       |    9 ++++++---
 net/ipv4/ip_output.c                     |    6 ++++--
 net/ipv4/tcp.c                           |   24 +++++++++++++++---------
 net/ipv4/udp.c                           |   11 ++++++-----
 net/ipv4/udp_impl.h                      |    5 +++--
 net/rds/tcp_send.c                       |    1 +
 net/socket.c                             |   11 +++++++----
 net/sunrpc/svcsock.c                     |    6 +++---
 net/sunrpc/xprtsock.c                    |    2 +-
 22 files changed, 81 insertions(+), 44 deletions(-)

diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 211fc44..e70ba0c 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2584,6 +2584,7 @@ static int _drbd_send_page(struct drbd_conf *mdev, struct page *page,
 	set_fs(KERNEL_DS);
 	do {
 		sent = mdev->data.socket->ops->sendpage(mdev->data.socket, page,
+							NULL,
 							offset, len,
 							msg_flags);
 		if (sent == -EAGAIN) {
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 453a740..df9f7dd 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -284,8 +284,8 @@ static int iscsi_sw_tcp_xmit_segment(struct iscsi_tcp_conn *tcp_conn,
 		if (!segment->data) {
 			sg = segment->sg;
 			offset += segment->sg_offset + sg->offset;
-			r = tcp_sw_conn->sendpage(sk, sg_page(sg), offset,
-						  copy, flags);
+			r = tcp_sw_conn->sendpage(sk, sg_page(sg), NULL,
+						  offset, copy, flags);
 		} else {
 			struct msghdr msg = { .msg_flags = flags };
 			struct kvec iov = {
diff --git a/drivers/scsi/iscsi_tcp.h b/drivers/scsi/iscsi_tcp.h
index 666fe09..1e23265 100644
--- a/drivers/scsi/iscsi_tcp.h
+++ b/drivers/scsi/iscsi_tcp.h
@@ -52,7 +52,8 @@ struct iscsi_sw_tcp_conn {
 	uint32_t		sendpage_failures_cnt;
 	uint32_t		discontiguous_hdr_cnt;
 
-	ssize_t (*sendpage)(struct socket *, struct page *, int, size_t, int);
+	ssize_t (*sendpage)(struct socket *, struct page *,
+			    struct skb_frag_destructor *, int, size_t, int);
 };
 
 struct iscsi_sw_tcp_host {
diff --git a/drivers/target/iscsi/iscsi_target_util.c b/drivers/target/iscsi/iscsi_target_util.c
index 4eba86d..d876dae 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -1323,7 +1323,8 @@ send_hdr:
 		u32 sub_len = min_t(u32, data_len, space);
 send_pg:
 		tx_sent = conn->sock->ops->sendpage(conn->sock,
-					sg_page(sg), sg->offset + offset, sub_len, 0);
+					sg_page(sg), NULL,
+					sg->offset + offset, sub_len, 0);
 		if (tx_sent != sub_len) {
 			if (tx_sent == -EAGAIN) {
 				pr_err("tcp_sendpage() returned"
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 133ef6d..0673cea 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1336,8 +1336,8 @@ static void send_to_sock(struct connection *con)
 
 		ret = 0;
 		if (len) {
-			ret = kernel_sendpage(con->sock, e->page, offset, len,
-					      msg_flags);
+			ret = kernel_sendpage(con->sock, e->page, NULL,
+					      offset, len, msg_flags);
 			if (ret == -EAGAIN || ret == 0) {
 				if (ret == -EAGAIN &&
 				    test_bit(SOCK_ASYNC_NOSPACE, &con->sock->flags) &&
diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index 044e7b5..e13851e 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
@@ -983,6 +983,7 @@ static void o2net_sendpage(struct o2net_sock_container *sc,
 		mutex_lock(&sc->sc_send_lock);
 		ret = sc->sc_sock->ops->sendpage(sc->sc_sock,
 						 virt_to_page(kmalloced_virt),
+						 NULL,
 						 (long)kmalloced_virt & ~PAGE_MASK,
 						 size, MSG_DONTWAIT);
 		mutex_unlock(&sc->sc_send_lock);
diff --git a/include/linux/net.h b/include/linux/net.h
index be60c7f..d9b0d648 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -157,6 +157,7 @@ struct kiocb;
 struct sockaddr;
 struct msghdr;
 struct module;
+struct skb_frag_destructor;
 
 struct proto_ops {
 	int		family;
@@ -203,6 +204,7 @@ struct proto_ops {
 	int		(*mmap)	     (struct file *file, struct socket *sock,
 				      struct vm_area_struct * vma);
 	ssize_t		(*sendpage)  (struct socket *sock, struct page *page,
+				      struct skb_frag_destructor *destroy,
 				      int offset, size_t size, int flags);
 	ssize_t 	(*splice_read)(struct socket *sock,  loff_t *ppos,
 				       struct pipe_inode_info *pipe, size_t len, unsigned int flags);
@@ -274,7 +276,9 @@ extern int kernel_getsockopt(struct socket *sock, int level, int optname,
 			     char *optval, int *optlen);
 extern int kernel_setsockopt(struct socket *sock, int level, int optname,
 			     char *optval, unsigned int optlen);
-extern int kernel_sendpage(struct socket *sock, struct page *page, int offset,
+extern int kernel_sendpage(struct socket *sock, struct page *page,
+			   struct skb_frag_destructor *destroy,
+			   int offset,
 			   size_t size, int flags);
 extern int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
 extern int kernel_sock_shutdown(struct socket *sock,
diff --git a/include/net/inet_common.h b/include/net/inet_common.h
index 22fac98..91cd8d0 100644
--- a/include/net/inet_common.h
+++ b/include/net/inet_common.h
@@ -21,7 +21,9 @@ extern int inet_dgram_connect(struct socket *sock, struct sockaddr * uaddr,
 extern int inet_accept(struct socket *sock, struct socket *newsock, int flags);
 extern int inet_sendmsg(struct kiocb *iocb, struct socket *sock,
 			struct msghdr *msg, size_t size);
-extern ssize_t inet_sendpage(struct socket *sock, struct page *page, int offset,
+extern ssize_t inet_sendpage(struct socket *sock, struct page *page,
+			     struct skb_frag_destructor *frag,
+			     int offset,
 			     size_t size, int flags);
 extern int inet_recvmsg(struct kiocb *iocb, struct socket *sock,
 			struct msghdr *msg, size_t size, int flags);
diff --git a/include/net/ip.h b/include/net/ip.h
index b53d65f..6bf9926 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -114,7 +114,9 @@ extern int		ip_append_data(struct sock *sk, struct flowi4 *fl4,
 				struct rtable **rt,
 				unsigned int flags);
 extern int		ip_generic_getfrag(void *from, char *to, int offset, int len, int odd, struct sk_buff *skb);
-extern ssize_t		ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
+extern ssize_t		ip_append_page(struct sock *sk, struct flowi4 *fl4,
+				struct page *page,
+				struct skb_frag_destructor *destroy,
 				int offset, size_t size, int flags);
 extern struct sk_buff  *__ip_make_skb(struct sock *sk,
 				      struct flowi4 *fl4,
diff --git a/include/net/sock.h b/include/net/sock.h
index a6ba1f8..c927997 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -834,6 +834,7 @@ struct proto {
 					size_t len, int noblock, int flags, 
 					int *addr_len);
 	int			(*sendpage)(struct sock *sk, struct page *page,
+					struct skb_frag_destructor *destroy,
 					int offset, size_t size, int flags);
 	int			(*bind)(struct sock *sk, 
 					struct sockaddr *uaddr, int addr_len);
@@ -1452,9 +1453,10 @@ extern int			sock_no_mmap(struct file *file,
 					     struct socket *sock,
 					     struct vm_area_struct *vma);
 extern ssize_t			sock_no_sendpage(struct socket *sock,
-						struct page *page,
-						int offset, size_t size, 
-						int flags);
+					struct page *page,
+					struct skb_frag_destructor *destroy,
+					int offset, size_t size,
+					int flags);
 
 /*
  * Functions to fill in entries in struct proto_ops when a protocol
diff --git a/include/net/tcp.h b/include/net/tcp.h
index f75a04d..7536266 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -331,7 +331,9 @@ extern void *tcp_v4_tw_get_peer(struct sock *sk);
 extern int tcp_v4_tw_remember_stamp(struct inet_timewait_sock *tw);
 extern int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 		       size_t size);
-extern int tcp_sendpage(struct sock *sk, struct page *page, int offset,
+extern int tcp_sendpage(struct sock *sk, struct page *page,
+			struct skb_frag_destructor *destroy,
+			int offset,
 			size_t size, int flags);
 extern int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg);
 extern int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index ad5b708..69f049b 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -851,7 +851,7 @@ static int write_partial_msg_pages(struct ceph_connection *con)
 				cpu_to_le32(crc32c(tmpcrc, base, len));
 			con->out_msg_pos.did_page_crc = 1;
 		}
-		ret = kernel_sendpage(con->sock, page,
+		ret = kernel_sendpage(con->sock, page, NULL,
 				      con->out_msg_pos.page_pos + page_shift,
 				      len,
 				      MSG_DONTWAIT | MSG_NOSIGNAL |
diff --git a/net/core/sock.c b/net/core/sock.c
index 9be6d0d..f56fc8c 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1965,7 +1965,9 @@ int sock_no_mmap(struct file *file, struct socket *sock, struct vm_area_struct *
 }
 EXPORT_SYMBOL(sock_no_mmap);
 
-ssize_t sock_no_sendpage(struct socket *sock, struct page *page, int offset, size_t size, int flags)
+ssize_t sock_no_sendpage(struct socket *sock, struct page *page,
+			 struct skb_frag_destructor *destroy,
+			 int offset, size_t size, int flags)
 {
 	ssize_t res;
 	struct msghdr msg = {.msg_flags = flags};
@@ -1975,6 +1977,8 @@ ssize_t sock_no_sendpage(struct socket *sock, struct page *page, int offset, siz
 	iov.iov_len = size;
 	res = kernel_sendmsg(sock, &msg, &iov, 1, size);
 	kunmap(page);
+	/* kernel_sendmsg copies so we can destroy immediately */
+	skb_frag_destructor_unref(destroy);
 	return res;
 }
 EXPORT_SYMBOL(sock_no_sendpage);
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index fdf49fd..e55a6e1 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -748,7 +748,9 @@ int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
 }
 EXPORT_SYMBOL(inet_sendmsg);
 
-ssize_t inet_sendpage(struct socket *sock, struct page *page, int offset,
+ssize_t inet_sendpage(struct socket *sock, struct page *page,
+		      struct skb_frag_destructor *destroy,
+		      int offset,
 		      size_t size, int flags)
 {
 	struct sock *sk = sock->sk;
@@ -761,8 +763,9 @@ ssize_t inet_sendpage(struct socket *sock, struct page *page, int offset,
 		return -EAGAIN;
 
 	if (sk->sk_prot->sendpage)
-		return sk->sk_prot->sendpage(sk, page, offset, size, flags);
-	return sock_no_sendpage(sock, page, offset, size, flags);
+		return sk->sk_prot->sendpage(sk, page, destroy,
+					     offset, size, flags);
+	return sock_no_sendpage(sock, page, destroy, offset, size, flags);
 }
 EXPORT_SYMBOL(inet_sendpage);
 
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 9e4eca6..2ce0b8e 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1130,6 +1130,7 @@ int ip_append_data(struct sock *sk, struct flowi4 *fl4,
 }
 
 ssize_t	ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
+		       struct skb_frag_destructor *destroy,
 		       int offset, size_t size, int flags)
 {
 	struct inet_sock *inet = inet_sk(sk);
@@ -1243,11 +1244,12 @@ ssize_t	ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
 		i = skb_shinfo(skb)->nr_frags;
 		if (len > size)
 			len = size;
-		if (skb_can_coalesce(skb, i, page, NULL, offset)) {
+		if (skb_can_coalesce(skb, i, page, destroy, offset)) {
 			skb_frag_size_add(&skb_shinfo(skb)->frags[i-1], len);
 		} else if (i < MAX_SKB_FRAGS) {
-			get_page(page);
 			skb_fill_page_desc(skb, i, page, offset, len);
+			skb_frag_set_destructor(skb, i, destroy);
+			skb_frag_ref(skb, i);
 		} else {
 			err = -EMSGSIZE;
 			goto error;
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b1612e9..89d4db0 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -757,8 +757,11 @@ static int tcp_send_mss(struct sock *sk, int *size_goal, int flags)
 	return mss_now;
 }
 
-static ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffset,
-			 size_t psize, int flags)
+static ssize_t do_tcp_sendpages(struct sock *sk,
+				struct page **pages,
+				struct skb_frag_destructor *destroy,
+				int poffset,
+				size_t psize, int flags)
 {
 	struct tcp_sock *tp = tcp_sk(sk);
 	int mss_now, size_goal;
@@ -804,7 +807,7 @@ new_segment:
 			copy = size;
 
 		i = skb_shinfo(skb)->nr_frags;
-		can_coalesce = skb_can_coalesce(skb, i, page, NULL, offset);
+		can_coalesce = skb_can_coalesce(skb, i, page, destroy, offset);
 		if (!can_coalesce && i >= MAX_SKB_FRAGS) {
 			tcp_mark_push(tp, skb);
 			goto new_segment;
@@ -815,8 +818,9 @@ new_segment:
 		if (can_coalesce) {
 			skb_frag_size_add(&skb_shinfo(skb)->frags[i - 1], copy);
 		} else {
-			get_page(page);
 			skb_fill_page_desc(skb, i, page, offset, copy);
+			skb_frag_set_destructor(skb, i, destroy);
+			skb_frag_ref(skb, i);
 		}
 
 		skb->len += copy;
@@ -871,18 +875,20 @@ out_err:
 	return sk_stream_error(sk, flags, err);
 }
 
-int tcp_sendpage(struct sock *sk, struct page *page, int offset,
-		 size_t size, int flags)
+int tcp_sendpage(struct sock *sk, struct page *page,
+		 struct skb_frag_destructor *destroy,
+		 int offset, size_t size, int flags)
 {
 	ssize_t res;
 
 	if (!(sk->sk_route_caps & NETIF_F_SG) ||
 	    !(sk->sk_route_caps & NETIF_F_ALL_CSUM))
-		return sock_no_sendpage(sk->sk_socket, page, offset, size,
-					flags);
+		return sock_no_sendpage(sk->sk_socket, page, destroy,
+					offset, size, flags);
 
 	lock_sock(sk);
-	res = do_tcp_sendpages(sk, &page, offset, size, flags);
+	res = do_tcp_sendpages(sk, &page, destroy,
+			       offset, size, flags);
 	release_sock(sk);
 	return res;
 }
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index d6f5fee..f9038e4 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1032,8 +1032,9 @@ do_confirm:
 }
 EXPORT_SYMBOL(udp_sendmsg);
 
-int udp_sendpage(struct sock *sk, struct page *page, int offset,
-		 size_t size, int flags)
+int udp_sendpage(struct sock *sk, struct page *page,
+		 struct skb_frag_destructor *destroy,
+		 int offset, size_t size, int flags)
 {
 	struct inet_sock *inet = inet_sk(sk);
 	struct udp_sock *up = udp_sk(sk);
@@ -1061,11 +1062,11 @@ int udp_sendpage(struct sock *sk, struct page *page, int offset,
 	}
 
 	ret = ip_append_page(sk, &inet->cork.fl.u.ip4,
-			     page, offset, size, flags);
+			     page, destroy, offset, size, flags);
 	if (ret == -EOPNOTSUPP) {
 		release_sock(sk);
-		return sock_no_sendpage(sk->sk_socket, page, offset,
-					size, flags);
+		return sock_no_sendpage(sk->sk_socket, page, destroy,
+					offset, size, flags);
 	}
 	if (ret < 0) {
 		udp_flush_pending_frames(sk);
diff --git a/net/ipv4/udp_impl.h b/net/ipv4/udp_impl.h
index aaad650..4923d82 100644
--- a/net/ipv4/udp_impl.h
+++ b/net/ipv4/udp_impl.h
@@ -23,8 +23,9 @@ extern int	compat_udp_getsockopt(struct sock *sk, int level, int optname,
 #endif
 extern int	udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 			    size_t len, int noblock, int flags, int *addr_len);
-extern int	udp_sendpage(struct sock *sk, struct page *page, int offset,
-			     size_t size, int flags);
+extern int	udp_sendpage(struct sock *sk, struct page *page,
+			     struct skb_frag_destructor *destroy,
+			     int offset, size_t size, int flags);
 extern int	udp_queue_rcv_skb(struct sock * sk, struct sk_buff *skb);
 extern void	udp_destroy_sock(struct sock *sk);
 
diff --git a/net/rds/tcp_send.c b/net/rds/tcp_send.c
index 1b4fd68..71503ad 100644
--- a/net/rds/tcp_send.c
+++ b/net/rds/tcp_send.c
@@ -119,6 +119,7 @@ int rds_tcp_xmit(struct rds_connection *conn, struct rds_message *rm,
 	while (sg < rm->data.op_nents) {
 		ret = tc->t_sock->ops->sendpage(tc->t_sock,
 						sg_page(&rm->data.op_sg[sg]),
+						NULL,
 						rm->data.op_sg[sg].offset + off,
 						rm->data.op_sg[sg].length - off,
 						MSG_DONTWAIT|MSG_NOSIGNAL);
diff --git a/net/socket.c b/net/socket.c
index 12a48d8..d0c0d8d 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -815,7 +815,7 @@ static ssize_t sock_sendpage(struct file *file, struct page *page,
 	if (more)
 		flags |= MSG_MORE;
 
-	return kernel_sendpage(sock, page, offset, size, flags);
+	return kernel_sendpage(sock, page, NULL, offset, size, flags);
 }
 
 static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
@@ -3350,15 +3350,18 @@ int kernel_setsockopt(struct socket *sock, int level, int optname,
 }
 EXPORT_SYMBOL(kernel_setsockopt);
 
-int kernel_sendpage(struct socket *sock, struct page *page, int offset,
+int kernel_sendpage(struct socket *sock, struct page *page,
+		    struct skb_frag_destructor *destroy,
+		    int offset,
 		    size_t size, int flags)
 {
 	sock_update_classid(sock->sk);
 
 	if (sock->ops->sendpage)
-		return sock->ops->sendpage(sock, page, offset, size, flags);
+		return sock->ops->sendpage(sock, page, destroy,
+					   offset, size, flags);
 
-	return sock_no_sendpage(sock, page, offset, size, flags);
+	return sock_no_sendpage(sock, page, destroy, offset, size, flags);
 }
 EXPORT_SYMBOL(kernel_sendpage);
 
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 40ae884..706305b 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -185,7 +185,7 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 	/* send head */
 	if (slen == xdr->head[0].iov_len)
 		flags = 0;
-	len = kernel_sendpage(sock, headpage, headoffset,
+	len = kernel_sendpage(sock, headpage, NULL, headoffset,
 				  xdr->head[0].iov_len, flags);
 	if (len != xdr->head[0].iov_len)
 		goto out;
@@ -198,7 +198,7 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 	while (pglen > 0) {
 		if (slen == size)
 			flags = 0;
-		result = kernel_sendpage(sock, *ppage, base, size, flags);
+		result = kernel_sendpage(sock, *ppage, NULL, base, size, flags);
 		if (result > 0)
 			len += result;
 		if (result != size)
@@ -212,7 +212,7 @@ int svc_send_common(struct socket *sock, struct xdr_buf *xdr,
 
 	/* send tail */
 	if (xdr->tail[0].iov_len) {
-		result = kernel_sendpage(sock, tailpage, tailoffset,
+		result = kernel_sendpage(sock, tailpage, NULL, tailoffset,
 				   xdr->tail[0].iov_len, 0);
 		if (result > 0)
 			len += result;
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 92bc518..f05082b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -408,7 +408,7 @@ static int xs_send_pagedata(struct socket *sock, struct xdr_buf *xdr, unsigned i
 		remainder -= len;
 		if (remainder != 0 || more)
 			flags |= MSG_MORE;
-		err = sock->ops->sendpage(sock, *ppage, base, len, flags);
+		err = sock->ops->sendpage(sock, *ppage, NULL, base, len, flags);
 		if (remainder == 0 || err != len)
 			break;
 		sent += err;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:56:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeMk-00013d-7y; Tue, 10 Apr 2012 16:56:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bvanassche@acm.org>) id 1SHdHf-0006Oj-BK
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:47:07 +0000
Received: from [85.158.143.35:20090] by server-1.bemta-4.messagelabs.com id
	E8/2C-20925-AF5548F4; Tue, 10 Apr 2012 15:47:06 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334072826!15482833!1
X-Originating-IP: [212.53.5.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjUzLjUuMjE4ID0+IDE4ODQ2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21917 invoked from network); 10 Apr 2012 15:47:06 -0000
Received: from relay03ant.iops.be (HELO relay03ant.iops.be) (212.53.5.218)
	by server-14.tower-21.messagelabs.com with SMTP;
	10 Apr 2012 15:47:06 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by relay03ant.iops.be (Postfix) with ESMTP id 063F46BF0096;
	Tue, 10 Apr 2012 17:47:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iops.be; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:references:subject:subject:mime-version:user-agent:from:from
	:date:date:message-id:received:received; s=scooby; i=
	postadmin@iops.be; t=1334072825; bh=gkBBIqJI8nDTixUEtDNI2QQJA82Q
	2V0UsIU4tEu/Ac4=; b=kwTMnXRB/YMvK3Zcy9Q6FmwiODV6726iN02v6JjFN7bV
	a/13fAkhhHAUybT87wt/xnPRrBE1BbNxFib2cxuUlXfCPFU/W9zV4MYnMg744IBb
	fkeeuo0vccDFzQHSnfM05rKAzpXsrAd+5FoqGc6iM/OPZnLypLiMf6vYBwvil5I=
X-Virus-Scanned: amavisd-new at iops.be
Received: from relay03ant.iops.be ([127.0.0.1])
	by localhost (bdell028.dcn.iops.be [127.0.0.1]) (amavisd-new,
	port 10026)
	with LMTP id hMi2B5xm99ZG; Tue, 10 Apr 2012 17:47:05 +0200 (CEST)
Received: from [192.168.3.246] (cust-67-22-110-94.dyn.as47377.net
	[94.110.22.67])
	by relay03ant.iops.be (Postfix) with ESMTP id 10E6F6BF008D;
	Tue, 10 Apr 2012 17:46:55 +0200 (CEST)
Message-ID: <4F8455EE.8010709@acm.org>
Date: Tue, 10 Apr 2012 15:46:54 +0000
From: Bart Van Assche <bvanassche@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
X-Mailman-Approved-At: Tue, 10 Apr 2012 16:56:25 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/12 14:26, Ian Campbell wrote:

> I think this is v4, but I've sort of lost count, sorry that it's taken
> me so long to get back to this stuff.
> 
> The following series makes use of the skb fragment API (which is in 3.2
> +) to add a per-paged-fragment destructor callback. This can be used by
> creators of skbs who are interested in the lifecycle of the pages
> included in that skb after they have handed it off to the network stack.


Hello Ian,

Great to see v4 of this patch series. But which kernel version has this
patch series been based on ? I've tried to apply this series on 3.4-rc2 but
apparently applying patch 09/10 failed:

patching file net/ceph/messenger.c
Hunk #1 FAILED at 851.
1 out of 1 hunk FAILED -- saving rejects to file net/ceph/messenger.c.rej

Regards,

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 16:56:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 16:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeMk-00013d-7y; Tue, 10 Apr 2012 16:56:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bvanassche@acm.org>) id 1SHdHf-0006Oj-BK
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 15:47:07 +0000
Received: from [85.158.143.35:20090] by server-1.bemta-4.messagelabs.com id
	E8/2C-20925-AF5548F4; Tue, 10 Apr 2012 15:47:06 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334072826!15482833!1
X-Originating-IP: [212.53.5.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjUzLjUuMjE4ID0+IDE4ODQ2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21917 invoked from network); 10 Apr 2012 15:47:06 -0000
Received: from relay03ant.iops.be (HELO relay03ant.iops.be) (212.53.5.218)
	by server-14.tower-21.messagelabs.com with SMTP;
	10 Apr 2012 15:47:06 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by relay03ant.iops.be (Postfix) with ESMTP id 063F46BF0096;
	Tue, 10 Apr 2012 17:47:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iops.be; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:references:subject:subject:mime-version:user-agent:from:from
	:date:date:message-id:received:received; s=scooby; i=
	postadmin@iops.be; t=1334072825; bh=gkBBIqJI8nDTixUEtDNI2QQJA82Q
	2V0UsIU4tEu/Ac4=; b=kwTMnXRB/YMvK3Zcy9Q6FmwiODV6726iN02v6JjFN7bV
	a/13fAkhhHAUybT87wt/xnPRrBE1BbNxFib2cxuUlXfCPFU/W9zV4MYnMg744IBb
	fkeeuo0vccDFzQHSnfM05rKAzpXsrAd+5FoqGc6iM/OPZnLypLiMf6vYBwvil5I=
X-Virus-Scanned: amavisd-new at iops.be
Received: from relay03ant.iops.be ([127.0.0.1])
	by localhost (bdell028.dcn.iops.be [127.0.0.1]) (amavisd-new,
	port 10026)
	with LMTP id hMi2B5xm99ZG; Tue, 10 Apr 2012 17:47:05 +0200 (CEST)
Received: from [192.168.3.246] (cust-67-22-110-94.dyn.as47377.net
	[94.110.22.67])
	by relay03ant.iops.be (Postfix) with ESMTP id 10E6F6BF008D;
	Tue, 10 Apr 2012 17:46:55 +0200 (CEST)
Message-ID: <4F8455EE.8010709@acm.org>
Date: Tue, 10 Apr 2012 15:46:54 +0000
From: Bart Van Assche <bvanassche@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
X-Mailman-Approved-At: Tue, 10 Apr 2012 16:56:25 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/12 14:26, Ian Campbell wrote:

> I think this is v4, but I've sort of lost count, sorry that it's taken
> me so long to get back to this stuff.
> 
> The following series makes use of the skb fragment API (which is in 3.2
> +) to add a per-paged-fragment destructor callback. This can be used by
> creators of skbs who are interested in the lifecycle of the pages
> included in that skb after they have handed it off to the network stack.


Hello Ian,

Great to see v4 of this patch series. But which kernel version has this
patch series been based on ? I've tried to apply this series on 3.4-rc2 but
apparently applying patch 09/10 failed:

patching file net/ceph/messenger.c
Hunk #1 FAILED at 851.
1 out of 1 hunk FAILED -- saving rejects to file net/ceph/messenger.c.rej

Regards,

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 17:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 17:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeZL-0001Ve-4w; Tue, 10 Apr 2012 17:09:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SHeZJ-0001VZ-Of
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 17:09:25 +0000
Received: from [193.109.254.147:29303] by server-8.bemta-14.messagelabs.com id
	C4/DE-23244-549648F4; Tue, 10 Apr 2012 17:09:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334077762!3996666!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6337 invoked from network); 10 Apr 2012 17:09:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 17:09:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189691153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 13:08:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 13:08:50 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SHeYk-0004wj-1v;
	Tue, 10 Apr 2012 18:08:50 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 10 Apr 2012 18:08:24 +0100
Message-ID: <1334077704-5449-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] x86: fix delta calculation in TSC deadline
	timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

In the virtual LAPIC, correct the delta calculation when emulating the
TSC deadline timer.

Without this fix, XenServer (which is based on Xen 4.1) does not work
when running as an HVM guest.  dom0 fails to boot because its timer
interrupts are very delayed (by several minutes in some cases).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
A 4.1.x candidate?
---
 xen/arch/x86/hvm/vlapic.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 8401756..1aa2810 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -913,9 +913,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
     guest_time = hvm_get_guest_time(v);
     if ( value > guest_tsc )
     {
-        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
-        delta = gtsc_to_gtime(v->domain, delta);
-        delta = max_t(s64, delta - guest_time, 0);
+        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
+        delta = max_t(s64, delta, 0);
 
         HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", delta);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 17:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 17:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHeZL-0001Ve-4w; Tue, 10 Apr 2012 17:09:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SHeZJ-0001VZ-Of
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 17:09:25 +0000
Received: from [193.109.254.147:29303] by server-8.bemta-14.messagelabs.com id
	C4/DE-23244-549648F4; Tue, 10 Apr 2012 17:09:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334077762!3996666!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI1OTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6337 invoked from network); 10 Apr 2012 17:09:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 17:09:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="189691153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 13:08:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Apr 2012 13:08:50 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SHeYk-0004wj-1v;
	Tue, 10 Apr 2012 18:08:50 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 10 Apr 2012 18:08:24 +0100
Message-ID: <1334077704-5449-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] x86: fix delta calculation in TSC deadline
	timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

In the virtual LAPIC, correct the delta calculation when emulating the
TSC deadline timer.

Without this fix, XenServer (which is based on Xen 4.1) does not work
when running as an HVM guest.  dom0 fails to boot because its timer
interrupts are very delayed (by several minutes in some cases).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
A 4.1.x candidate?
---
 xen/arch/x86/hvm/vlapic.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 8401756..1aa2810 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -913,9 +913,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
     guest_time = hvm_get_guest_time(v);
     if ( value > guest_tsc )
     {
-        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
-        delta = gtsc_to_gtime(v->domain, delta);
-        delta = max_t(s64, delta - guest_time, 0);
+        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
+        delta = max_t(s64, delta, 0);
 
         HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", delta);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 17:34:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 17:34:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHewh-00026X-Sa; Tue, 10 Apr 2012 17:33:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHewg-00026Q-FT
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 17:33:34 +0000
Received: from [85.158.143.35:14712] by server-1.bemta-4.messagelabs.com id
	90/4D-20925-DEE648F4; Tue, 10 Apr 2012 17:33:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334079213!4316766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21753 invoked from network); 10 Apr 2012 17:33:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 17:33:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11863498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 17:33:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 18:33:33 +0100
Date: Tue, 10 Apr 2012 18:37:11 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.2076.974553.319109@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204101832320.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
	<20347.2076.974553.319109@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> ...
> > I don't think it is worth adding one more option for something like
> > this: nobody should be using this option anyway. I am still unconvinced
> > there is a valid use case for this.
> 
> I think it's important.  An additional config option is IMO necessary
> to allow the admin to impose their vbd allocation strategy.

It shouldn't be a per-VM paramater (part of libxl_domain_config, for
example) and I don't think it is a good idea to plumb a new parameter
through from XL to libxl_create for this purpose.

What did you have in mind when you thought about having a new paramater
for this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 17:34:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 17:34:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHewh-00026X-Sa; Tue, 10 Apr 2012 17:33:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHewg-00026Q-FT
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 17:33:34 +0000
Received: from [85.158.143.35:14712] by server-1.bemta-4.messagelabs.com id
	90/4D-20925-DEE648F4; Tue, 10 Apr 2012 17:33:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334079213!4316766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21753 invoked from network); 10 Apr 2012 17:33:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 17:33:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11863498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 17:33:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 18:33:33 +0100
Date: Tue, 10 Apr 2012 18:37:11 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.2076.974553.319109@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204101832320.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
	<20347.2076.974553.319109@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> ...
> > I don't think it is worth adding one more option for something like
> > this: nobody should be using this option anyway. I am still unconvinced
> > there is a valid use case for this.
> 
> I think it's important.  An additional config option is IMO necessary
> to allow the admin to impose their vbd allocation strategy.

It shouldn't be a per-VM paramater (part of libxl_domain_config, for
example) and I don't think it is a good idea to plumb a new parameter
through from XL to libxl_create for this purpose.

What did you have in mind when you thought about having a new paramater
for this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 18:41:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 18:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHg0A-0004UR-Ac; Tue, 10 Apr 2012 18:41:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHg09-0004UM-B1
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 18:41:13 +0000
Received: from [85.158.143.99:55565] by server-1.bemta-4.messagelabs.com id
	BB/F0-20925-8CE748F4; Tue, 10 Apr 2012 18:41:12 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334083271!22753155!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8393 invoked from network); 10 Apr 2012 18:41:11 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 18:41:11 -0000
Received: by bkcjg9 with SMTP id jg9so95110bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 11:41:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=ZCP1up106rowQebNEXhW82E7PSWtu84WlESvG/LSP+k=;
	b=jJdlUZKDcJB2sHzdgE3LgJCLNnTANCa/S+TJBqbdbK9XIhNSMb6TqjFzgqpBrK6FQf
	cydwXzzmL5W8Ft0KFLCaCo8qaE+Ux3thFf+/UNKz4YG7lWwm1SM6wEUzwGqJGekTKqxP
	mU55LgNzRhWfsOfFMpelfLlKp/RW26SFe+DVb/I3c3hZnq6tmNCOYsEtXgfVe/35W39I
	Ct5gPI0aCT40bwRsE8Oo757R0qiYmo3V+1QLfviP76KuuVBGqsJHNTHnX6vZPr67VgSJ
	73MXB55+syN1SDYww48ZsqzdZAwA2RlymUAHw/T2yXwQ46X4eHtZmi4txKo7AV3wPoYe
	w7oQ==
Received: by 10.204.151.86 with SMTP id b22mr5243032bkw.81.1334083271224;
	Tue, 10 Apr 2012 11:41:11 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id s16sm264791bkt.3.2012.04.10.11.41.06
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 11:41:08 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
In-Reply-To: <4F847CF9.3090701@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
Date: Tue, 10 Apr 2012 20:41:05 +0200
Message-ID: <1334083265.5300.288.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:

> Have you checked this for 32 bit as well as 64?  Based on my math your
> next patch will still mess up the memset on 32 bit with the structure
> being split somewhere just in front of hwtstamps.
> 
> Why not just take frags and move it to the start of the structure?  It
> is already an unknown value because it can be either 16 or 17 depending
> on the value of PAGE_SIZE, and since you are making changes to frags the
> changes wouldn't impact the alignment of the other values later on since
> you are aligning the end of the structure.  That way you would be
> guaranteed that all of the fields that will be memset would be in the
> last 64 bytes.
> 

Now when a fragmented packet is copied in pskb_expand_head(), you access
two separate zones of memory to copy the shinfo. But its supposed to be
slow path.

Problem with this is that the offsets of often used fields will be big
(instead of being < 127) and code will be bigger on x86.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 18:41:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 18:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHg0A-0004UR-Ac; Tue, 10 Apr 2012 18:41:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHg09-0004UM-B1
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 18:41:13 +0000
Received: from [85.158.143.99:55565] by server-1.bemta-4.messagelabs.com id
	BB/F0-20925-8CE748F4; Tue, 10 Apr 2012 18:41:12 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334083271!22753155!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8393 invoked from network); 10 Apr 2012 18:41:11 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 18:41:11 -0000
Received: by bkcjg9 with SMTP id jg9so95110bkc.32
	for <xen-devel@lists.xen.org>; Tue, 10 Apr 2012 11:41:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=ZCP1up106rowQebNEXhW82E7PSWtu84WlESvG/LSP+k=;
	b=jJdlUZKDcJB2sHzdgE3LgJCLNnTANCa/S+TJBqbdbK9XIhNSMb6TqjFzgqpBrK6FQf
	cydwXzzmL5W8Ft0KFLCaCo8qaE+Ux3thFf+/UNKz4YG7lWwm1SM6wEUzwGqJGekTKqxP
	mU55LgNzRhWfsOfFMpelfLlKp/RW26SFe+DVb/I3c3hZnq6tmNCOYsEtXgfVe/35W39I
	Ct5gPI0aCT40bwRsE8Oo757R0qiYmo3V+1QLfviP76KuuVBGqsJHNTHnX6vZPr67VgSJ
	73MXB55+syN1SDYww48ZsqzdZAwA2RlymUAHw/T2yXwQ46X4eHtZmi4txKo7AV3wPoYe
	w7oQ==
Received: by 10.204.151.86 with SMTP id b22mr5243032bkw.81.1334083271224;
	Tue, 10 Apr 2012 11:41:11 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id s16sm264791bkt.3.2012.04.10.11.41.06
	(version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 11:41:08 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
In-Reply-To: <4F847CF9.3090701@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
Date: Tue, 10 Apr 2012 20:41:05 +0200
Message-ID: <1334083265.5300.288.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:

> Have you checked this for 32 bit as well as 64?  Based on my math your
> next patch will still mess up the memset on 32 bit with the structure
> being split somewhere just in front of hwtstamps.
> 
> Why not just take frags and move it to the start of the structure?  It
> is already an unknown value because it can be either 16 or 17 depending
> on the value of PAGE_SIZE, and since you are making changes to frags the
> changes wouldn't impact the alignment of the other values later on since
> you are aligning the end of the structure.  That way you would be
> guaranteed that all of the fields that will be memset would be in the
> last 64 bytes.
> 

Now when a fragmented packet is copied in pskb_expand_head(), you access
two separate zones of memory to copy the shinfo. But its supposed to be
slow path.

Problem with this is that the offsets of often used fields will be big
(instead of being < 127) and code will be bigger on x86.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:04:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgMM-0005AV-Hc; Tue, 10 Apr 2012 19:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SHgML-0005AO-QB
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 19:04:10 +0000
Received: from [85.158.143.99:29614] by server-1.bemta-4.messagelabs.com id
	38/A0-20925-924848F4; Tue, 10 Apr 2012 19:04:09 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334084646!23026753!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22730 invoked from network); 10 Apr 2012 19:04:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330923600"; d="scan'208";a="24035808"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:04:05 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 10 Apr 2012
	15:04:05 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 10 Apr 2012 15:04:03 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0XMBCct2S3V6WzSlW5pdCxXKXprQAG8eFg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334072343.5394.58.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Tuesday, April 10, 2012 11:39 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com; Tim (Xen.org)
> Subject: RE: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Tue, 2012-04-10 at 16:28 +0100, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: Tuesday, April 10, 2012 10:22 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > >
> > > On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > > > > I see. So you need to be able to find the individual tables so
> > > > > that smbios_type_<N>_init can check for an overriding table <N>
> > > > > in the passed-through tables, it seems reasonable to try and
> > > > > avoid needing to parse a big lump of tables each time to see if
> > > > > the one you are interested in is there.
> > > > >
> > > > > I think this can work by having .../smbios/<N>/{address,etc} in
> > > > > XenStore. You could also have .../smbios/OEM/{...} for the stuff
> > > > > for smbios_type_vendor_oem_init, which I think could easily just
> > > > > be a single lump?
> > > > >
> > > > > I think you don't need the same thing for the ACPI side since
> > > > > there you just provide secondary tables?
> > > >
> > > > There could be quite a few SMBIOS tables being passed in. On the
> > > > order of 20 - 30 of them and thet are pretty small. It seems a bit
> > > > odd to break it up like this for lots of little chunks. There
> > > > could be more than one ACPI table also (multiple SSDTs and/or
> other static tables).
> > > > Also the OEM SMBIOS tables are all discrete and they could not go
> > > > in as a single lump.
> > >
> > > I'm not sure if there are arguments here both for and against having
> > > a single smbios blob vs multiple?
> >
> > Oh sorry. I am trying to answer 2 different things here. In summary
> > what I would like to do is not make any distinction between vendor and
> > predefined tables but rather send all SMBIOS tables in as a single
> > lump with some sort of internal delimiter structs. If that is
> > unacceptable then all the SMBIOS tables would be put in xenstore per
> > what you said above (.../smbios/<N>/{address,etc}). It just seems odd
> > to me to break up the (usually rather small and potentially numerous)
> > SMBIOS tables into individual items passed in xenstore.
> 
> What sort of delimiter were you thinking of? Perhaps something as simple
> as:
> 	<length><blob><length><blob>

Yea, that would suffice.

> ?
> 
> Or can you use the length field in the smbios entry header?
> 
> Ian.
> 

Not really. I think part of the problem here is my mixing of terminology. For SMBIOS bits I am pulling apart the overall SMBIOS table and just grabbing a desired subset of the SMBIOS structures. The individual structures are the entities that do not have an overall length field so I want to stick them back together as one lump with a length delimiter - what you described above is perfectly sufficient.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:04:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgMM-0005AV-Hc; Tue, 10 Apr 2012 19:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SHgML-0005AO-QB
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 19:04:10 +0000
Received: from [85.158.143.99:29614] by server-1.bemta-4.messagelabs.com id
	38/A0-20925-924848F4; Tue, 10 Apr 2012 19:04:09 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334084646!23026753!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzUzNTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22730 invoked from network); 10 Apr 2012 19:04:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330923600"; d="scan'208";a="24035808"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 15:04:05 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 10 Apr 2012
	15:04:05 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 10 Apr 2012 15:04:03 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0XMBCct2S3V6WzSlW5pdCxXKXprQAG8eFg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334072343.5394.58.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Tuesday, April 10, 2012 11:39 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com; Tim (Xen.org)
> Subject: RE: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Tue, 2012-04-10 at 16:28 +0100, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: Tuesday, April 10, 2012 10:22 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > >
> > > On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > > > > I see. So you need to be able to find the individual tables so
> > > > > that smbios_type_<N>_init can check for an overriding table <N>
> > > > > in the passed-through tables, it seems reasonable to try and
> > > > > avoid needing to parse a big lump of tables each time to see if
> > > > > the one you are interested in is there.
> > > > >
> > > > > I think this can work by having .../smbios/<N>/{address,etc} in
> > > > > XenStore. You could also have .../smbios/OEM/{...} for the stuff
> > > > > for smbios_type_vendor_oem_init, which I think could easily just
> > > > > be a single lump?
> > > > >
> > > > > I think you don't need the same thing for the ACPI side since
> > > > > there you just provide secondary tables?
> > > >
> > > > There could be quite a few SMBIOS tables being passed in. On the
> > > > order of 20 - 30 of them and thet are pretty small. It seems a bit
> > > > odd to break it up like this for lots of little chunks. There
> > > > could be more than one ACPI table also (multiple SSDTs and/or
> other static tables).
> > > > Also the OEM SMBIOS tables are all discrete and they could not go
> > > > in as a single lump.
> > >
> > > I'm not sure if there are arguments here both for and against having
> > > a single smbios blob vs multiple?
> >
> > Oh sorry. I am trying to answer 2 different things here. In summary
> > what I would like to do is not make any distinction between vendor and
> > predefined tables but rather send all SMBIOS tables in as a single
> > lump with some sort of internal delimiter structs. If that is
> > unacceptable then all the SMBIOS tables would be put in xenstore per
> > what you said above (.../smbios/<N>/{address,etc}). It just seems odd
> > to me to break up the (usually rather small and potentially numerous)
> > SMBIOS tables into individual items passed in xenstore.
> 
> What sort of delimiter were you thinking of? Perhaps something as simple
> as:
> 	<length><blob><length><blob>

Yea, that would suffice.

> ?
> 
> Or can you use the length field in the smbios entry header?
> 
> Ian.
> 

Not really. I think part of the problem here is my mixing of terminology. For SMBIOS bits I am pulling apart the overall SMBIOS table and just grabbing a desired subset of the SMBIOS structures. The individual structures are the entities that do not have an overall length field so I want to stick them back together as one lump with a length delimiter - what you described above is perfectly sufficient.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQG-0005Xs-Pq; Tue, 10 Apr 2012 19:08:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQF-0005Xc-HY
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:11 +0000
Received: from [85.158.143.99:46275] by server-3.bemta-4.messagelabs.com id
	B6/66-05853-A15848F4; Tue, 10 Apr 2012 19:08:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2971 invoked from network); 10 Apr 2012 19:08:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQD-0002KM-6a; Tue, 10 Apr 2012 19:08:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQD-0003mV-3o;
	Tue, 10 Apr 2012 20:08:09 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 20:07:34 +0100
Message-ID: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v4 00/31] libxl child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series has now been tested and is in a suitable form for review
and, if thought fit, committing to xen-unstable.  It still culminates
in a patch to convert bootloader execution to the new event machinery.

Changes since v3 ("[RFC PATCH 00/20]") include:
 - All comments on previous version addressed.
 - Several new bugfix patches etc., marked with * below.
 - Broke the bootloader execution rewrite up into three patches.
 - Testing and consequent fixes (only to previously un-acked patches);
   in particular, the final patch has some significant changes.

Bugfixes for problems reported by Roger Pau Monne:
  02/31 libxl: ao: allow immediate completion
  03/31 libxl: fix hang due to libxl__initiate_device_remove
  04/31 libxl: Fix eventloop_iteration over-locking
* 05/31 libxl: remove poller from list in libxl__poller_get

Other general bugfixes:
* 01/31 .gitignore: Add a missing file
  06/31 libxl: Fix leak of ctx->lock
  07/31 tools: Correct PTHREAD options in config/StdGNU.mk
  08/31 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
  09/31 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
  26/31 libxl: Clean up setdefault in do_domain_create
  30/31 libxl: make libxl_create_logfile const-correct

Clarifications and improvements related to memory allocation:
  10/31 libxl: Crash (more sensibly) on malloc failure
  11/31 libxl: Make libxl__zalloc et al tolerate a NULL gc

Preparatory work:
  12/31 libxl: Introduce some convenience macros
  13/31 libxl: include <ctype.h> and introduce CTYPE helper macro
  14/31 libxl: Provide libxl_string_list_length
  15/31 libxl: include <_libxl_paths.h> in libxl_internal.h
  16/31 libxl: abolish libxl_ctx_postfork
* 23/31 autoconf: New test for openpty et al.
* 24/31 libxl: provide libxl__remove_file et al.
* 25/31 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds

Event-related infrastructure and fixes:
  17/31 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
  18/31 libxl: Protect fds with CLOEXEC even with forking threads
* 19/31 libxl: provide STATE_AO_GC
* 20/31 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
* 21/31 libxl: support multiple libxl__ev_fds for the same fd
  22/31 libxl: event API: new facilities for waiting for subprocesses
  27/31 libxl: provide libxl__datacopier_*
  28/31 libxl: provide libxl__openpty_*
  29/31 libxl: ao: Convert libxl_run_bootloader
* 31/31 libxl: log bootloader output


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQO-0005eN-BU; Tue, 10 Apr 2012 19:08:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005YB-FL
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46461] by server-2.bemta-4.messagelabs.com id
	11/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3106 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L2-N8; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nb-MD;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:50 +0100
Message-ID: <1334084885-14474-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/31] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b376316..edbca53 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -461,7 +461,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d6cd78d..0cbd85e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -365,13 +365,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..62c0abd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -94,6 +94,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0a3d628..7e258d5 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -105,6 +105,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..c9e9943 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1441,7 +1441,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1728,11 +1728,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQN-0005dP-FM; Tue, 10 Apr 2012 19:08:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Xc-71
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:63084] by server-3.bemta-4.messagelabs.com id
	60/76-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25043 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LL-W4; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003o3-UI;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:57 +0100
Message-ID: <1334084885-14474-24-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/31] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/Tools.mk.in             |    2 +
 tools/configure                |   51 ++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac             |    2 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 +++
 tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
 6 files changed, 84 insertions(+), 1 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 912d021..eb879dd 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 86618f5..eeaf901 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,7 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -3947,6 +3948,8 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -7315,6 +7318,54 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        ax_cv_ptyfuncs_libs=-lutil
+
+    saved_LIBS="$LIBS"
+
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
 if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..b4f72e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -132,6 +133,7 @@ AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
+AX_CHECK_PTYFUNCS
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..5ba144f 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..2846a6d
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,24 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        ax_cv_ptyfuncs_libs=-lutil
+        AX_SAVEVAR_SAVE(LIBS)
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+])
+        AX_SAVEVAR_RESTORE(LIBS)],
+    [],[
+        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQQ-0005gq-EE; Tue, 10 Apr 2012 19:08:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005YB-Ro
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:63093] by server-2.bemta-4.messagelabs.com id
	22/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!16
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3137 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LD-SO; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nv-QZ;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:55 +0100
Message-ID: <1334084885-14474-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/31] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..672e3fe 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each elemebnt in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9f2583d..1a2139c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -257,8 +261,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQG-0005Xs-Pq; Tue, 10 Apr 2012 19:08:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQF-0005Xc-HY
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:11 +0000
Received: from [85.158.143.99:46275] by server-3.bemta-4.messagelabs.com id
	B6/66-05853-A15848F4; Tue, 10 Apr 2012 19:08:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2971 invoked from network); 10 Apr 2012 19:08:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQD-0002KM-6a; Tue, 10 Apr 2012 19:08:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQD-0003mV-3o;
	Tue, 10 Apr 2012 20:08:09 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 20:07:34 +0100
Message-ID: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v4 00/31] libxl child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series has now been tested and is in a suitable form for review
and, if thought fit, committing to xen-unstable.  It still culminates
in a patch to convert bootloader execution to the new event machinery.

Changes since v3 ("[RFC PATCH 00/20]") include:
 - All comments on previous version addressed.
 - Several new bugfix patches etc., marked with * below.
 - Broke the bootloader execution rewrite up into three patches.
 - Testing and consequent fixes (only to previously un-acked patches);
   in particular, the final patch has some significant changes.

Bugfixes for problems reported by Roger Pau Monne:
  02/31 libxl: ao: allow immediate completion
  03/31 libxl: fix hang due to libxl__initiate_device_remove
  04/31 libxl: Fix eventloop_iteration over-locking
* 05/31 libxl: remove poller from list in libxl__poller_get

Other general bugfixes:
* 01/31 .gitignore: Add a missing file
  06/31 libxl: Fix leak of ctx->lock
  07/31 tools: Correct PTHREAD options in config/StdGNU.mk
  08/31 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
  09/31 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
  26/31 libxl: Clean up setdefault in do_domain_create
  30/31 libxl: make libxl_create_logfile const-correct

Clarifications and improvements related to memory allocation:
  10/31 libxl: Crash (more sensibly) on malloc failure
  11/31 libxl: Make libxl__zalloc et al tolerate a NULL gc

Preparatory work:
  12/31 libxl: Introduce some convenience macros
  13/31 libxl: include <ctype.h> and introduce CTYPE helper macro
  14/31 libxl: Provide libxl_string_list_length
  15/31 libxl: include <_libxl_paths.h> in libxl_internal.h
  16/31 libxl: abolish libxl_ctx_postfork
* 23/31 autoconf: New test for openpty et al.
* 24/31 libxl: provide libxl__remove_file et al.
* 25/31 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds

Event-related infrastructure and fixes:
  17/31 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
  18/31 libxl: Protect fds with CLOEXEC even with forking threads
* 19/31 libxl: provide STATE_AO_GC
* 20/31 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
* 21/31 libxl: support multiple libxl__ev_fds for the same fd
  22/31 libxl: event API: new facilities for waiting for subprocesses
  27/31 libxl: provide libxl__datacopier_*
  28/31 libxl: provide libxl__openpty_*
  29/31 libxl: ao: Convert libxl_run_bootloader
* 31/31 libxl: log bootloader output


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQO-0005eN-BU; Tue, 10 Apr 2012 19:08:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005YB-FL
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46461] by server-2.bemta-4.messagelabs.com id
	11/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3106 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L2-N8; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nb-MD;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:50 +0100
Message-ID: <1334084885-14474-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/31] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b376316..edbca53 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -461,7 +461,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d6cd78d..0cbd85e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -365,13 +365,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..62c0abd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -94,6 +94,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0a3d628..7e258d5 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -105,6 +105,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..c9e9943 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1441,7 +1441,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1728,11 +1728,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQQ-0005gq-EE; Tue, 10 Apr 2012 19:08:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005YB-Ro
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:63093] by server-2.bemta-4.messagelabs.com id
	22/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!16
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3137 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LD-SO; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nv-QZ;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:55 +0100
Message-ID: <1334084885-14474-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/31] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..672e3fe 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each elemebnt in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9f2583d..1a2139c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -257,8 +261,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQN-0005dP-FM; Tue, 10 Apr 2012 19:08:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Xc-71
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:63084] by server-3.bemta-4.messagelabs.com id
	60/76-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25043 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LL-W4; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003o3-UI;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:57 +0100
Message-ID: <1334084885-14474-24-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/31] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/Tools.mk.in             |    2 +
 tools/configure                |   51 ++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac             |    2 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 +++
 tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
 6 files changed, 84 insertions(+), 1 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 912d021..eb879dd 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 86618f5..eeaf901 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,7 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -3947,6 +3948,8 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -7315,6 +7318,54 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        ax_cv_ptyfuncs_libs=-lutil
+
+    saved_LIBS="$LIBS"
+
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
 if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..b4f72e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -132,6 +133,7 @@ AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
+AX_CHECK_PTYFUNCS
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..5ba144f 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..2846a6d
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,24 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        ax_cv_ptyfuncs_libs=-lutil
+        AX_SAVEVAR_SAVE(LIBS)
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+])
+        AX_SAVEVAR_RESTORE(LIBS)],
+    [],[
+        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQM-0005cO-81; Tue, 10 Apr 2012 19:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005Xc-Qr
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:46441] by server-3.bemta-4.messagelabs.com id
	DE/66-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3071 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kp-El; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nH-CO;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:45 +0100
Message-ID: <1334084885-14474-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/31] libxl: Make libxl__zalloc et al tolerate
	a NULL gc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Arrange that if we pass NULL as a gc, we simply don't register the
pointer.  This instantly gives us non-gc'ing but error-checking
versions of malloc, realloc, vasprintf, etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    5 ++++-
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 2270234..541f20b 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -34,6 +34,9 @@ void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
+    if (!gc)
+        return;
+
     if (!ptr)
         return;
 
@@ -101,7 +104,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr) {
+    } else if (new_ptr != ptr && gc != NULL) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ad446a..9340bde 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -384,30 +384,35 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  *
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
+ *
+ * However, where the argument is stated to be "gc_opt", NULL may be
+ * passed instead, in which case no garbage collection will occur; the
+ * pointer must later be freed with free().  This is for memory
+ * allocations of types (b) and (c).
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQP-0005fG-3n; Tue, 10 Apr 2012 19:08:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Xc-Ja
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46477] by server-3.bemta-4.messagelabs.com id
	A0/76-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25051 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LM-WB; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003o7-Uq;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:58 +0100
Message-ID: <1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a60171c..8e47213 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..c9157a6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQP-0005fs-Lx; Tue, 10 Apr 2012 19:08:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Z2-Or
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:63071] by server-2.bemta-4.messagelabs.com id
	A1/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!15
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3123 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L5-OU; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nf-Mj;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:51 +0100
Message-ID: <1334084885-14474-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/31] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 9cb172a..638b9ab 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQO-0005e1-0I; Tue, 10 Apr 2012 19:08:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Z2-9F
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46459] by server-2.bemta-4.messagelabs.com id
	E0/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25025 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LA-Qi; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nr-Q5;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:54 +0100
Message-ID: <1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 76875bb..9f2583d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQR-0005hn-9i; Tue, 10 Apr 2012 19:08:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005ZQ-Re
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.139.83:11860] by server-3.bemta-5.messagelabs.com id
	D2/E6-25237-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334084893!23223547!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32508 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LS-25; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oR-1I;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:03 +0100
Message-ID: <1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 29/31] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  708 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 415 insertions(+), 342 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..54f3813 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 03e71f6..477b72a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -494,7 +494,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..1361117 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,215 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
+
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
 
-    return pid;
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
-        }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
-
-    libxl__ptr_add(gc, output);
-    return output;
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-out_err:
-    free(output);
-    return NULL;
-}
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    bl->diskpath = NULL;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    libxl__datacopier_init(&bl->keystrokes);
+    libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        bl->callback(egc, bl, 0);
+        rc = 0;
         goto out;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +330,187 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
 
-        goto out_close;
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
+
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (bl->child.pid >= 0) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status) {
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..dbc3cf0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -572,8 +572,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6850097..fd96b31 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -449,6 +450,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1531,6 +1533,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQS-0005kU-DV; Tue, 10 Apr 2012 19:08:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YP-Bm
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63039] by server-1.bemta-4.messagelabs.com id
	CC/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3092 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kx-IQ; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nP-GR;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:47 +0100
Message-ID: <1334084885-14474-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/31] libxl: include <ctype.h> and introduce
	CTYPE helper macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 95c34f3..b35421f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -33,6 +33,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <ctype.h>
 
 #include <sys/mman.h>
 #include <sys/poll.h>
@@ -1469,6 +1470,25 @@ static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
     } while(0)
 
 
+/*
+ * int CTYPE(ISFOO, char c);
+ * int CTYPE(toupper, char c);
+ * int CTYPE(tolower, char c);
+ *
+ * This is necessary because passing a simple char to a ctype.h
+ * is forbidden.  ctype.h macros take ints derived from _unsigned_ chars.
+ *
+ * If you have a char which might be EOF then you should already have
+ * it in an int representing an unsigned char, and you can use the
+ * <ctype.h> macros directly.  This generally happens only with values
+ * from fgetc et al.
+ *
+ * For any value known to be a character (eg, anything that came from
+ * a char[]), use CTYPE.
+ */
+#define CTYPE(isfoo,c) (isfoo((unsigned char)(c)))
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQM-0005cO-81; Tue, 10 Apr 2012 19:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005Xc-Qr
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:46441] by server-3.bemta-4.messagelabs.com id
	DE/66-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3071 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kp-El; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nH-CO;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:45 +0100
Message-ID: <1334084885-14474-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/31] libxl: Make libxl__zalloc et al tolerate
	a NULL gc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Arrange that if we pass NULL as a gc, we simply don't register the
pointer.  This instantly gives us non-gc'ing but error-checking
versions of malloc, realloc, vasprintf, etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    5 ++++-
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 2270234..541f20b 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -34,6 +34,9 @@ void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
+    if (!gc)
+        return;
+
     if (!ptr)
         return;
 
@@ -101,7 +104,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr) {
+    } else if (new_ptr != ptr && gc != NULL) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ad446a..9340bde 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -384,30 +384,35 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  *
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
+ *
+ * However, where the argument is stated to be "gc_opt", NULL may be
+ * passed instead, in which case no garbage collection will occur; the
+ * pointer must later be freed with free().  This is for memory
+ * allocations of types (b) and (c).
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQQ-0005gL-1x; Tue, 10 Apr 2012 19:08:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005ZH-Jb
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.139.83:43992] by server-11.bemta-5.messagelabs.com id
	6B/1C-12959-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334084893!23223547!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32503 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LP-12; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oI-0C;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:01 +0100
Message-ID: <1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 231 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5ba144f..6e253b1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..c1229e4
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        libxl__datacopier_kill(dc);
+        dc->callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a3955a4..8eabcfa 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -830,6 +830,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1455,6 +1456,45 @@ int libxl__carefd_close(libxl__carefd*);
 int libxl__carefd_fd(const libxl__carefd*);
 
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errno is valid
+ * onwrite==0 means failure happened when reading
+ *     errno==0 means we got eof and all data was written
+ *     errno!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQK-0005ao-L8; Tue, 10 Apr 2012 19:08:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YC-4H
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:62997] by server-1.bemta-4.messagelabs.com id
	4B/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3050 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kc-4b; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003mx-20;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:40 +0100
Message-ID: <1334084885-14474-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/31] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dd948a8..f41b62f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQP-0005fG-3n; Tue, 10 Apr 2012 19:08:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Xc-Ja
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46477] by server-3.bemta-4.messagelabs.com id
	A0/76-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25051 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LM-WB; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003o7-Uq;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:58 +0100
Message-ID: <1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a60171c..8e47213 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..c9157a6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQJ-0005Zn-Nq; Tue, 10 Apr 2012 19:08:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQH-0005Xc-MG
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:13 +0000
Received: from [85.158.143.99:46395] by server-3.bemta-4.messagelabs.com id
	BC/66-05853-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3039 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002KW-09; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mp-Td;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:38 +0100
Message-ID: <1334084885-14474-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/31] libxl: Fix eventloop_iteration
	over-locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c89add8..5ac6334 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5167b71..04f13f6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1191,7 +1191,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1287,7 +1287,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQR-0005hn-9i; Tue, 10 Apr 2012 19:08:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005ZQ-Re
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.139.83:11860] by server-3.bemta-5.messagelabs.com id
	D2/E6-25237-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334084893!23223547!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32508 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LS-25; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oR-1I;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:03 +0100
Message-ID: <1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 29/31] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  708 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 415 insertions(+), 342 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..54f3813 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 03e71f6..477b72a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -494,7 +494,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..1361117 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,215 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
+
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
 
-    return pid;
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
-        }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
-
-    libxl__ptr_add(gc, output);
-    return output;
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-out_err:
-    free(output);
-    return NULL;
-}
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    bl->diskpath = NULL;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    libxl__datacopier_init(&bl->keystrokes);
+    libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        bl->callback(egc, bl, 0);
+        rc = 0;
         goto out;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +330,187 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
 
-        goto out_close;
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
+
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (bl->child.pid >= 0) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status) {
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..dbc3cf0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -572,8 +572,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6850097..fd96b31 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -449,6 +450,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1531,6 +1533,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQL-0005bn-F3; Tue, 10 Apr 2012 19:08:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YB-JI
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:63007] by server-2.bemta-4.messagelabs.com id
	FE/BA-17550-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3059 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Ki-8u; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003n5-6s;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:42 +0100
Message-ID: <1334084885-14474-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/31] libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be needed for pthread_atfork.  It is a mystery why it
hasn't been needed before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 748d057..b0143e6 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -22,6 +22,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQO-0005e1-0I; Tue, 10 Apr 2012 19:08:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Z2-9F
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46459] by server-2.bemta-4.messagelabs.com id
	E0/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25025 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LA-Qi; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nr-Q5;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:54 +0100
Message-ID: <1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 76875bb..9f2583d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQP-0005fs-Lx; Tue, 10 Apr 2012 19:08:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Z2-Or
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:63071] by server-2.bemta-4.messagelabs.com id
	A1/CA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!15
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3123 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L5-OU; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nf-Mj;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:51 +0100
Message-ID: <1334084885-14474-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/31] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 9cb172a..638b9ab 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQS-0005kU-DV; Tue, 10 Apr 2012 19:08:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YP-Bm
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63039] by server-1.bemta-4.messagelabs.com id
	CC/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3092 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kx-IQ; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nP-GR;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:47 +0100
Message-ID: <1334084885-14474-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/31] libxl: include <ctype.h> and introduce
	CTYPE helper macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 95c34f3..b35421f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -33,6 +33,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <ctype.h>
 
 #include <sys/mman.h>
 #include <sys/poll.h>
@@ -1469,6 +1470,25 @@ static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
     } while(0)
 
 
+/*
+ * int CTYPE(ISFOO, char c);
+ * int CTYPE(toupper, char c);
+ * int CTYPE(tolower, char c);
+ *
+ * This is necessary because passing a simple char to a ctype.h
+ * is forbidden.  ctype.h macros take ints derived from _unsigned_ chars.
+ *
+ * If you have a char which might be EOF then you should already have
+ * it in an int representing an unsigned char, and you can use the
+ * <ctype.h> macros directly.  This generally happens only with values
+ * from fgetc et al.
+ *
+ * For any value known to be a character (eg, anything that came from
+ * a char[]), use CTYPE.
+ */
+#define CTYPE(isfoo,c) (isfoo((unsigned char)(c)))
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQK-0005ao-L8; Tue, 10 Apr 2012 19:08:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YC-4H
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:62997] by server-1.bemta-4.messagelabs.com id
	4B/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3050 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kc-4b; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003mx-20;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:40 +0100
Message-ID: <1334084885-14474-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/31] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dd948a8..f41b62f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQQ-0005gL-1x; Tue, 10 Apr 2012 19:08:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005ZH-Jb
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.139.83:43992] by server-11.bemta-5.messagelabs.com id
	6B/1C-12959-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334084893!23223547!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32503 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LP-12; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oI-0C;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:01 +0100
Message-ID: <1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 231 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5ba144f..6e253b1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..c1229e4
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        libxl__datacopier_kill(dc);
+        dc->callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a3955a4..8eabcfa 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -830,6 +830,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1455,6 +1456,45 @@ int libxl__carefd_close(libxl__carefd*);
 int libxl__carefd_fd(const libxl__carefd*);
 
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errno is valid
+ * onwrite==0 means failure happened when reading
+ *     errno==0 means we got eof and all data was written
+ *     errno!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQW-0005r4-7m; Tue, 10 Apr 2012 19:08:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQL-0005Z7-Az
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:46483] by server-1.bemta-4.messagelabs.com id
	20/83-20925-025848F4; Tue, 10 Apr 2012 19:08:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!17
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3145 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LQ-1o; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oM-0j;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:02 +0100
Message-ID: <1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index c1229e4..b33abe4 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8eabcfa..6850097 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1495,6 +1495,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQS-0005l8-Rf; Tue, 10 Apr 2012 19:08:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Z2-8i
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46494] by server-2.bemta-4.messagelabs.com id
	D2/CA-17550-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25068 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LF-UT; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nz-Rz;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:56 +0100
Message-ID: <1334084885-14474-23-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/31] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   59 +++++++++-
 6 files changed, 512 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..42ac89f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..03e71f6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 672e3fe..1b7495a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 4751ef4..aac9598 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -104,6 +110,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -115,6 +122,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -138,6 +149,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1a2139c..a60171c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -315,10 +328,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -566,6 +583,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon, and should not make
+ * any further libxl event calls in the meantime.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -619,6 +663,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQJ-0005Zn-Nq; Tue, 10 Apr 2012 19:08:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQH-0005Xc-MG
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:13 +0000
Received: from [85.158.143.99:46395] by server-3.bemta-4.messagelabs.com id
	BC/66-05853-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3039 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002KW-09; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mp-Td;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:38 +0100
Message-ID: <1334084885-14474-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/31] libxl: Fix eventloop_iteration
	over-locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c89add8..5ac6334 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5167b71..04f13f6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1191,7 +1191,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1287,7 +1287,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQL-0005bn-F3; Tue, 10 Apr 2012 19:08:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YB-JI
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:63007] by server-2.bemta-4.messagelabs.com id
	FE/BA-17550-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3059 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Ki-8u; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003n5-6s;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:42 +0100
Message-ID: <1334084885-14474-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/31] libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be needed for pthread_atfork.  It is a mystery why it
hasn't been needed before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 748d057..b0143e6 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -22,6 +22,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQL-0005c7-RV; Tue, 10 Apr 2012 19:08:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YC-Jp
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:46423] by server-1.bemta-4.messagelabs.com id
	3C/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3065 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kl-Bm; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003n9-8f;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:43 +0100
Message-ID: <1334084885-14474-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/31] tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Replace all literal occurrences of -lpthread and -pthread in Makefiles
by references to PTHREAD_CFLAGS, PTHREAD_LDFLAGS and PTHREAD_LIBS.
These are the new variables set by configure, and currently expand to
-pthread on the compilation and link lines as is required.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap/drivers/Makefile       |    7 +++++--
 tools/libfsimage/common/Makefile    |    5 ++++-
 tools/vtpm_manager/manager/Makefile |    4 +++-
 tools/xenpaging/Makefile            |    5 +++--
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
index addb2fe..941592e 100644
--- a/tools/blktap/drivers/Makefile
+++ b/tools/blktap/drivers/Makefile
@@ -35,8 +35,11 @@ else
 AIOLIBS     := -laio
 endif
 
-LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
-LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
+LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm $(PTHREAD_LIBS)
+LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) $(PTHREAD_LIBS) -lz
 
 BLK-OBJS-y  := block-aio.o
 BLK-OBJS-y  += block-sync.o
diff --git a/tools/libfsimage/common/Makefile b/tools/libfsimage/common/Makefile
index 11621e7..3684913 100644
--- a/tools/libfsimage/common/Makefile
+++ b/tools/libfsimage/common/Makefile
@@ -8,6 +8,9 @@ LDFLAGS-$(CONFIG_SunOS) = -Wl,-M -Wl,mapfile-SunOS
 LDFLAGS-$(CONFIG_Linux) = -Wl,mapfile-GNU
 LDFLAGS = $(LDFLAGS-y)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
 LIB_SRCS-y = fsimage.c fsimage_plugin.c fsimage_grub.c
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
@@ -37,7 +40,7 @@ libfsimage.so.$(MAJOR): libfsimage.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libfsimage.so.$(MAJOR).$(MINOR): $(PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ -lpthread
+	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(PTHREAD_LIBS)
 
 -include $(DEPS)
 
diff --git a/tools/vtpm_manager/manager/Makefile b/tools/vtpm_manager/manager/Makefile
index 149f01d..7564af1 100644
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -33,4 +33,6 @@ $(BIN): $(OBJS)
 
 # libraries
 LIBS += ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.a
-LIBS += -lcrypto -lpthread -lm
+LIBS += -lcrypto $(PTHREAD_LIBS) -lm
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/xenpaging/Makefile b/tools/xenpaging/Makefile
index 08230a6..548d9dd 100644
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -1,8 +1,9 @@
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore)
-LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -pthread
+CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore) $(PTHREAD_CFLAGS)
+LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(PTHREAD_LIBS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
 
 POLICY    = default
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQS-0005l8-Rf; Tue, 10 Apr 2012 19:08:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Z2-8i
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46494] by server-2.bemta-4.messagelabs.com id
	D2/CA-17550-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25068 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002LF-UT; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nz-Rz;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:56 +0100
Message-ID: <1334084885-14474-23-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/31] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   59 +++++++++-
 6 files changed, 512 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..42ac89f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..03e71f6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 672e3fe..1b7495a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 4751ef4..aac9598 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -104,6 +110,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -115,6 +122,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -138,6 +149,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1a2139c..a60171c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -315,10 +328,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -566,6 +583,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon, and should not make
+ * any further libxl event calls in the meantime.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -619,6 +663,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQW-0005r4-7m; Tue, 10 Apr 2012 19:08:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQL-0005Z7-Az
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:46483] by server-1.bemta-4.messagelabs.com id
	20/83-20925-025848F4; Tue, 10 Apr 2012 19:08:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!17
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3145 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LQ-1o; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oM-0j;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:02 +0100
Message-ID: <1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index c1229e4..b33abe4 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8eabcfa..6850097 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1495,6 +1495,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQL-0005c7-RV; Tue, 10 Apr 2012 19:08:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YC-Jp
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:46423] by server-1.bemta-4.messagelabs.com id
	3C/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3065 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kl-Bm; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003n9-8f;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:43 +0100
Message-ID: <1334084885-14474-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/31] tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Replace all literal occurrences of -lpthread and -pthread in Makefiles
by references to PTHREAD_CFLAGS, PTHREAD_LDFLAGS and PTHREAD_LIBS.
These are the new variables set by configure, and currently expand to
-pthread on the compilation and link lines as is required.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap/drivers/Makefile       |    7 +++++--
 tools/libfsimage/common/Makefile    |    5 ++++-
 tools/vtpm_manager/manager/Makefile |    4 +++-
 tools/xenpaging/Makefile            |    5 +++--
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
index addb2fe..941592e 100644
--- a/tools/blktap/drivers/Makefile
+++ b/tools/blktap/drivers/Makefile
@@ -35,8 +35,11 @@ else
 AIOLIBS     := -laio
 endif
 
-LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
-LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
+LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm $(PTHREAD_LIBS)
+LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) $(PTHREAD_LIBS) -lz
 
 BLK-OBJS-y  := block-aio.o
 BLK-OBJS-y  += block-sync.o
diff --git a/tools/libfsimage/common/Makefile b/tools/libfsimage/common/Makefile
index 11621e7..3684913 100644
--- a/tools/libfsimage/common/Makefile
+++ b/tools/libfsimage/common/Makefile
@@ -8,6 +8,9 @@ LDFLAGS-$(CONFIG_SunOS) = -Wl,-M -Wl,mapfile-SunOS
 LDFLAGS-$(CONFIG_Linux) = -Wl,mapfile-GNU
 LDFLAGS = $(LDFLAGS-y)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
 LIB_SRCS-y = fsimage.c fsimage_plugin.c fsimage_grub.c
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
@@ -37,7 +40,7 @@ libfsimage.so.$(MAJOR): libfsimage.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libfsimage.so.$(MAJOR).$(MINOR): $(PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ -lpthread
+	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(PTHREAD_LIBS)
 
 -include $(DEPS)
 
diff --git a/tools/vtpm_manager/manager/Makefile b/tools/vtpm_manager/manager/Makefile
index 149f01d..7564af1 100644
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -33,4 +33,6 @@ $(BIN): $(OBJS)
 
 # libraries
 LIBS += ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.a
-LIBS += -lcrypto -lpthread -lm
+LIBS += -lcrypto $(PTHREAD_LIBS) -lm
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/xenpaging/Makefile b/tools/xenpaging/Makefile
index 08230a6..548d9dd 100644
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -1,8 +1,9 @@
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore)
-LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -pthread
+CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore) $(PTHREAD_CFLAGS)
+LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(PTHREAD_LIBS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
 
 POLICY    = default
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQI-0005YL-5t; Tue, 10 Apr 2012 19:08:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQH-0005Xc-9r
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:13 +0000
Received: from [85.158.143.99:62983] by server-3.bemta-4.messagelabs.com id
	0C/66-05853-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3029 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQF-0002KP-PO; Tue, 10 Apr 2012 19:08:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mf-Oh;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:35 +0100
Message-ID: <1334084885-14474-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/31] .gitignore: Add a missing file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2782ee5..cd12b56 100644
--- a/.gitignore
+++ b/.gitignore
@@ -357,6 +357,7 @@ tools/firmware/etherboot/eb-roms.h
 tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
 tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
+tools/misc/xen-lowmemd
 tools/libvchan/vchan-node[12]
 tools/ocaml/*/.ocamldep.make
 tools/ocaml/*/*.cm[ixao]
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQT-0005ln-8g; Tue, 10 Apr 2012 19:08:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Z7-Eu
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46436] by server-1.bemta-4.messagelabs.com id
	8C/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24997 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002KZ-2C; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mt-W4;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:39 +0100
Message-ID: <1334084885-14474-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 05/31] libxl: remove poller from list in
	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Roger Pau Monne <roger.pau@citrix.com>

Remove poller from the list once it has been requested.
Fixes a double-free bug.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@citrix.com>
---
 tools/libxl/libxl_event.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5ac6334..9cb172a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1010,8 +1010,10 @@ libxl__poller *libxl__poller_get(libxl_ctx *ctx)
     int rc;
 
     libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
-    if (p)
+    if (p) {
+        LIBXL_LIST_REMOVE(p, entry);
         return p;
+    }
 
     p = malloc(sizeof(*p));
     if (!p) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQN-0005d3-1P; Tue, 10 Apr 2012 19:08:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YB-Vi
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46442] by server-2.bemta-4.messagelabs.com id
	EF/BA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25007 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Km-CX; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nD-Bb;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:44 +0100
Message-ID: <1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc
	failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Formally change the libxl memory allocation failure policy to "crash".

Previously we had a very uneven approach; much code assumed that
libxl__sprintf (for example) would never return NULL, but some code
was written more carefully.

We think it is unlikely that we will be able to make the library
actually robust against allocation failure (since that would be an
awful lot of never-tested error paths) and few calling environments
will be able to cope anyway.  So, instead, adopt the alternative
approach: provide allocation functions which never return null, but
will crash the whole process instead.

Consequently,
 - New noreturn function libxl__alloc_failed which may be used for
   printing a vaguely-useful error message, rather than simply
   dereferencing a null pointer.
 - libxl__ptr_add now returns void as it crashes on failure.
 - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
   libxl__alloc_failed.  So all the code that uses these can no longer
   dereference null on malloc failure.

While we're at it, make libxl__ptr_add use realloc rather than
emulating it with calloc and free, and make it grow the array
exponentially rather than linearly.

Things left to do:
 - Provide versions of malloc, realloc and free which do the
   checking but which do not enroll the pointer in the gc.
 - Remove a lot of now-spurious error handling.
 - Remove the ERROR_NOMEM error code.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |    4 ++
 tools/libxl/libxl_internal.c |   87 ++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |    8 +++-
 3 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 2aec910..0219f81 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -194,6 +194,10 @@
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
+ *
+ * Memory allocation failures are not handled gracefully.  If malloc
+ * (or realloc) fails, libxl will cause the entire process to print
+ * a message to stderr and exit with status 255.
  */
 /*
  * libxl types
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..2270234 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -17,40 +17,45 @@
 
 #include "libxl_internal.h"
 
-int libxl__error_set(libxl__gc *gc, int code)
-{
-    return 0;
+void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
+                         size_t nmemb, size_t size) {
+#define M "libxl: FATAL ERROR: memory allocation failure"
+#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
+          func, (unsigned long)nmemb, (unsigned long)size
+    libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, L);
+    fprintf(stderr, L);
+    fflush(stderr);
+    _exit(-1);
+#undef M
+#undef L
 }
 
-int libxl__ptr_add(libxl__gc *gc, void *ptr)
+void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
-    void **re;
 
     if (!ptr)
-        return 0;
+        return;
 
     /* fast case: we have space in the array for storing the pointer */
     for (i = 0; i < gc->alloc_maxsize; i++) {
         if (!gc->alloc_ptrs[i]) {
             gc->alloc_ptrs[i] = ptr;
-            return 0;
+            return;
         }
     }
-    /* realloc alloc_ptrs manually with calloc/free/replace */
-    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
-    if (!re)
-        return -1;
-    for (i = 0; i < gc->alloc_maxsize; i++)
-        re[i] = gc->alloc_ptrs[i];
-    /* assign the next pointer */
-    re[i] = ptr;
+    int new_maxsize = gc->alloc_maxsize * 2 + 25;
+    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
+    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
+    if (!gc->alloc_ptrs)
+        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);
 
-    /* replace the old alloc_ptr */
-    free(gc->alloc_ptrs);
-    gc->alloc_ptrs = re;
-    gc->alloc_maxsize += 25;
-    return 0;
+    gc->alloc_ptrs[gc->alloc_maxsize++] = ptr;
+
+    while (gc->alloc_maxsize < new_maxsize)
+        gc->alloc_ptrs[gc->alloc_maxsize++] = 0;
+
+    return;
 }
 
 void libxl__free_all(libxl__gc *gc)
@@ -71,10 +76,7 @@ void libxl__free_all(libxl__gc *gc)
 void *libxl__zalloc(libxl__gc *gc, int bytes)
 {
     void *ptr = calloc(bytes, 1);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, bytes, 1);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -83,10 +85,7 @@ void *libxl__zalloc(libxl__gc *gc, int bytes)
 void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size)
 {
     void *ptr = calloc(nmemb, size);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, nmemb, size);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -97,9 +96,8 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
     void *new_ptr = realloc(ptr, new_size);
     int i = 0;
 
-    if (new_ptr == NULL && new_size != 0) {
-        return NULL;
-    }
+    if (new_ptr == NULL && new_size != 0)
+        libxl__alloc_failed(CTX, __func__, new_size, 1);
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
@@ -112,7 +110,6 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
         }
     }
 
-
     return new_ptr;
 }
 
@@ -126,16 +123,13 @@ char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...)
     ret = vsnprintf(NULL, 0, fmt, ap);
     va_end(ap);
 
-    if (ret < 0) {
-        return NULL;
-    }
+    assert(ret >= 0);
 
     s = libxl__zalloc(gc, ret + 1);
-    if (s) {
-        va_start(ap, fmt);
-        ret = vsnprintf(s, ret + 1, fmt, ap);
-        va_end(ap);
-    }
+    va_start(ap, fmt);
+    ret = vsnprintf(s, ret + 1, fmt, ap);
+    va_end(ap);
+
     return s;
 }
 
@@ -143,8 +137,9 @@ char *libxl__strdup(libxl__gc *gc, const char *c)
 {
     char *s = strdup(c);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, strlen(c), 1);
+
+    libxl__ptr_add(gc, s);
 
     return s;
 }
@@ -153,8 +148,7 @@ char *libxl__strndup(libxl__gc *gc, const char *c, size_t n)
 {
     char *s = strndup(c, n);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, n, 1);
 
     return s;
 }
@@ -175,6 +169,9 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
              const char *fmt, va_list ap)
 {
+    /* WARNING this function may not call any libxl-provided
+     * memory allocation function, as those may
+     * call libxl__alloc_failed which calls libxl__logv. */
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
     int rc, esave;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 04f13f6..2ad446a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -116,6 +116,12 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
+void libxl__alloc_failed(libxl_ctx *, const char *func,
+                         size_t nmemb, size_t size) __attribute__((noreturn));
+  /* func, size and nmemb are used only in the log message.
+   * You may pass size==0 if size and nmemb are not meaningful
+   * and should not be printed. */
+
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
@@ -380,7 +386,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * collection on exit from the outermost libxl callframe.
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQT-0005mV-LS; Tue, 10 Apr 2012 19:08:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YC-Bn
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63041] by server-1.bemta-4.messagelabs.com id
	EC/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3081 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kf-74; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003n1-4S;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:41 +0100
Message-ID: <1334084885-14474-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/31] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

Fix the configure test to test -pthread, and plumb the resulting flag
through to PTHREAD_{CFLAGS,LDFLAGS} in Tools.mk; also substitute
PTHREAD_LIBS (although this will currently always be empty).
Remove PTHREAD_LIBS setting from StdGNU.mk.

Fix the one user (libxc) to use PTHREAD_{CFLAGS,LDFLAGS} too.

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 config/StdGNU.mk     |    1 -
 config/Tools.mk.in   |    4 ++
 tools/configure      |  101 ++++++++++++++++++++++++++++++++++++--------------
 tools/configure.ac   |    5 +-
 tools/libxc/Makefile |    4 +-
 tools/m4/pthread.m4  |   41 ++++++++++++++++++++
 tools/m4/savevar.m4  |    6 +++
 7 files changed, 130 insertions(+), 32 deletions(-)
 create mode 100644 tools/m4/pthread.m4
 create mode 100644 tools/m4/savevar.m4

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index e2c9335..e2f2e1e 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,6 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 339a7b6..912d021 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -26,6 +26,10 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
+PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
+PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
+PTHREAD_LIBS        := @PTHREAD_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 64b7eb5..86618f5 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,9 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTHREAD_LIBS
+PTHREAD_LDFLAGS
+PTHREAD_CFLAGS
 libgcrypt
 libext2fs
 system_aio
@@ -3861,6 +3864,9 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
+
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -3924,6 +3930,22 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+
+
+
+
+
+
+
 
 # Enable/disable options
 
@@ -7228,47 +7250,70 @@ else
 fi
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in -lpthread" >&5
-$as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if test "${ac_cv_lib_pthread_pthread_create+set}" = set; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
+$as_echo_n "checking for pthread flag... " >&6; }
+if test "${ax_cv_pthread_flags+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
-  ac_check_lib_save_LIBS=$LIBS
-LIBS="-lpthread  $LIBS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+
+        ax_cv_pthread_flags=-pthread
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
+    saved_CFLAGS="$CFLAGS"
+
+    saved_LDFLAGS="$LDFLAGS"
+
+    saved_LIBS="$LIBS"
+
+
+    CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+    LDFLAGS="$LDFLAGS $PTHREAD_LDFLAGS"
+
+    LIBS="$LIBS $PTHREAD_LIBS"
+
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
-/* Override any GCC internal prototype to avoid an error.
-   Use char because int might match the return type of a GCC
-   builtin and then its argument prototype would still apply.  */
-#ifdef __cplusplus
-extern "C"
-#endif
-char pthread_create ();
-int
-main ()
-{
-return pthread_create ();
-  ;
-  return 0;
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
 }
+
 _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
-  ac_cv_lib_pthread_pthread_create=yes
+
 else
-  ac_cv_lib_pthread_pthread_create=no
+  ax_cv_pthread_flags=failed
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthread_create" >&5
-$as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" = x""yes; then :
 
-else
-  as_fn_error $? "Could not find libpthread" "$LINENO" 5
+    CFLAGS="$saved_CFLAGS"
+
+    LDFLAGS="$saved_LDFLAGS"
+
+    LIBS="$saved_LIBS"
+
+
 fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_pthread_flags" >&5
+$as_echo "$ax_cv_pthread_flags" >&6; }
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        as_fn_error $? "-pthread does not work" "$LINENO" 5
+    fi
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index 0204e36..250dffd 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -23,6 +23,7 @@ AC_USE_SYSTEM_EXTENSIONS
 AC_CANONICAL_HOST
 
 # M4 Macro includes
+m4_include([m4/savevar.m4])
 m4_include([m4/features.m4])
 m4_include([m4/path_or_fail.m4])
 m4_include([m4/python_version.m4])
@@ -33,6 +34,7 @@ m4_include([m4/set_cflags_ldflags.m4])
 m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
+m4_include([m4/pthread.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -129,8 +131,7 @@ AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
 AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
-AC_CHECK_LIB([pthread], [pthread_create], [] ,
-    [AC_MSG_ERROR([Could not find libpthread])])
+AX_CHECK_PTHREAD
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 55eb755..a1ba134 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -73,6 +73,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -157,7 +159,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
diff --git a/tools/m4/pthread.m4 b/tools/m4/pthread.m4
new file mode 100644
index 0000000..57ea85c
--- /dev/null
+++ b/tools/m4/pthread.m4
@@ -0,0 +1,41 @@
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+AC_DEFUN([AX_PTHREAD_CV2VARS],[
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+])
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+AC_DEFUN([AX_PTHREAD_VARS],[$1(CFLAGS) $1(LDFLAGS) $1(LIBS)])
+
+AC_DEFUN([AX_PTHREAD_VAR_APPLY],[
+    $1="$$1 $PTHREAD_$1"
+])
+AC_DEFUN([AX_PTHREAD_VAR_SUBST],[AC_SUBST(PTHREAD_$1)])
+
+AC_DEFUN([AX_CHECK_PTHREAD],[
+    AC_CACHE_CHECK([for pthread flag], [ax_cv_pthread_flags], [
+        ax_cv_pthread_flags=-pthread
+        AX_PTHREAD_CV2VARS
+        AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
+        AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
+        AC_LINK_IFELSE([
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
+}
+],[],[ax_cv_pthread_flags=failed])
+        AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
+    ])
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        AC_MSG_ERROR([-pthread does not work])
+    fi
+    AX_PTHREAD_CV2VARS
+    AX_PTHREAD_VARS([AX_PTHREAD_VAR_SUBST])
+])
diff --git a/tools/m4/savevar.m4 b/tools/m4/savevar.m4
new file mode 100644
index 0000000..2156bee
--- /dev/null
+++ b/tools/m4/savevar.m4
@@ -0,0 +1,6 @@
+AC_DEFUN([AX_SAVEVAR_SAVE],[
+    saved_$1="$$1"
+])
+AC_DEFUN([AX_SAVEVAR_RESTORE],[
+    $1="$saved_$1"
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQQ-0005h8-PP; Tue, 10 Apr 2012 19:08:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Xc-0M
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63111] by server-3.bemta-4.messagelabs.com id
	41/76-05853-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!18
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3160 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LO-0e; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003oD-Vr;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:00 +0100
Message-ID: <1334084885-14474-27-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 26/31] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..3675afe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQK-0005aH-4z; Tue, 10 Apr 2012 19:08:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YB-0g
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:46396] by server-2.bemta-4.messagelabs.com id
	6E/BA-17550-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3034 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQF-0002KQ-RM; Tue, 10 Apr 2012 19:08:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mh-PE;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:36 +0100
Message-ID: <1334084885-14474-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/31] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Also fix the wording in the libxl_internal.h comment forbidding use of
ao_how-taking functions from within libxl.  (There are sadly currently
some such functions.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..c89add8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,9 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->constructing);
     assert(ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b1e0588 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -347,7 +347,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1209,7 +1209,11 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * operation ("ao") machinery.  The function should take a parameter
  * const libxl_asyncop_how *ao_how and must start with a call to
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * outside libxl, because they can cause reentrancy callbacks.
+ * inside libxl, because they can cause reentrancy callbacks.
+ *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
  *
  * Lifecycle of an ao:
  *
@@ -1240,8 +1244,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1255,12 +1258,14 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
     AO_GC;
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1269,6 +1274,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQT-0005ln-8g; Tue, 10 Apr 2012 19:08:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Z7-Eu
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46436] by server-1.bemta-4.messagelabs.com id
	8C/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24997 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002KZ-2C; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mt-W4;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:39 +0100
Message-ID: <1334084885-14474-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 05/31] libxl: remove poller from list in
	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Roger Pau Monne <roger.pau@citrix.com>

Remove poller from the list once it has been requested.
Fixes a double-free bug.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@citrix.com>
---
 tools/libxl/libxl_event.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5ac6334..9cb172a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1010,8 +1010,10 @@ libxl__poller *libxl__poller_get(libxl_ctx *ctx)
     int rc;
 
     libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
-    if (p)
+    if (p) {
+        LIBXL_LIST_REMOVE(p, entry);
         return p;
+    }
 
     p = malloc(sizeof(*p));
     if (!p) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQQ-0005h8-PP; Tue, 10 Apr 2012 19:08:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Xc-0M
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63111] by server-3.bemta-4.messagelabs.com id
	41/76-05853-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!18
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3160 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LO-0e; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003oD-Vr;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:00 +0100
Message-ID: <1334084885-14474-27-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 26/31] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..3675afe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQN-0005d3-1P; Tue, 10 Apr 2012 19:08:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YB-Vi
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.143.99:46442] by server-2.bemta-4.messagelabs.com id
	EF/BA-17550-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25007 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Km-CX; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nD-Bb;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:44 +0100
Message-ID: <1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc
	failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Formally change the libxl memory allocation failure policy to "crash".

Previously we had a very uneven approach; much code assumed that
libxl__sprintf (for example) would never return NULL, but some code
was written more carefully.

We think it is unlikely that we will be able to make the library
actually robust against allocation failure (since that would be an
awful lot of never-tested error paths) and few calling environments
will be able to cope anyway.  So, instead, adopt the alternative
approach: provide allocation functions which never return null, but
will crash the whole process instead.

Consequently,
 - New noreturn function libxl__alloc_failed which may be used for
   printing a vaguely-useful error message, rather than simply
   dereferencing a null pointer.
 - libxl__ptr_add now returns void as it crashes on failure.
 - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
   libxl__alloc_failed.  So all the code that uses these can no longer
   dereference null on malloc failure.

While we're at it, make libxl__ptr_add use realloc rather than
emulating it with calloc and free, and make it grow the array
exponentially rather than linearly.

Things left to do:
 - Provide versions of malloc, realloc and free which do the
   checking but which do not enroll the pointer in the gc.
 - Remove a lot of now-spurious error handling.
 - Remove the ERROR_NOMEM error code.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |    4 ++
 tools/libxl/libxl_internal.c |   87 ++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |    8 +++-
 3 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 2aec910..0219f81 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -194,6 +194,10 @@
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
+ *
+ * Memory allocation failures are not handled gracefully.  If malloc
+ * (or realloc) fails, libxl will cause the entire process to print
+ * a message to stderr and exit with status 255.
  */
 /*
  * libxl types
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..2270234 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -17,40 +17,45 @@
 
 #include "libxl_internal.h"
 
-int libxl__error_set(libxl__gc *gc, int code)
-{
-    return 0;
+void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
+                         size_t nmemb, size_t size) {
+#define M "libxl: FATAL ERROR: memory allocation failure"
+#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
+          func, (unsigned long)nmemb, (unsigned long)size
+    libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, L);
+    fprintf(stderr, L);
+    fflush(stderr);
+    _exit(-1);
+#undef M
+#undef L
 }
 
-int libxl__ptr_add(libxl__gc *gc, void *ptr)
+void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
-    void **re;
 
     if (!ptr)
-        return 0;
+        return;
 
     /* fast case: we have space in the array for storing the pointer */
     for (i = 0; i < gc->alloc_maxsize; i++) {
         if (!gc->alloc_ptrs[i]) {
             gc->alloc_ptrs[i] = ptr;
-            return 0;
+            return;
         }
     }
-    /* realloc alloc_ptrs manually with calloc/free/replace */
-    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
-    if (!re)
-        return -1;
-    for (i = 0; i < gc->alloc_maxsize; i++)
-        re[i] = gc->alloc_ptrs[i];
-    /* assign the next pointer */
-    re[i] = ptr;
+    int new_maxsize = gc->alloc_maxsize * 2 + 25;
+    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
+    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
+    if (!gc->alloc_ptrs)
+        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);
 
-    /* replace the old alloc_ptr */
-    free(gc->alloc_ptrs);
-    gc->alloc_ptrs = re;
-    gc->alloc_maxsize += 25;
-    return 0;
+    gc->alloc_ptrs[gc->alloc_maxsize++] = ptr;
+
+    while (gc->alloc_maxsize < new_maxsize)
+        gc->alloc_ptrs[gc->alloc_maxsize++] = 0;
+
+    return;
 }
 
 void libxl__free_all(libxl__gc *gc)
@@ -71,10 +76,7 @@ void libxl__free_all(libxl__gc *gc)
 void *libxl__zalloc(libxl__gc *gc, int bytes)
 {
     void *ptr = calloc(bytes, 1);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, bytes, 1);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -83,10 +85,7 @@ void *libxl__zalloc(libxl__gc *gc, int bytes)
 void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size)
 {
     void *ptr = calloc(nmemb, size);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, nmemb, size);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -97,9 +96,8 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
     void *new_ptr = realloc(ptr, new_size);
     int i = 0;
 
-    if (new_ptr == NULL && new_size != 0) {
-        return NULL;
-    }
+    if (new_ptr == NULL && new_size != 0)
+        libxl__alloc_failed(CTX, __func__, new_size, 1);
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
@@ -112,7 +110,6 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
         }
     }
 
-
     return new_ptr;
 }
 
@@ -126,16 +123,13 @@ char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...)
     ret = vsnprintf(NULL, 0, fmt, ap);
     va_end(ap);
 
-    if (ret < 0) {
-        return NULL;
-    }
+    assert(ret >= 0);
 
     s = libxl__zalloc(gc, ret + 1);
-    if (s) {
-        va_start(ap, fmt);
-        ret = vsnprintf(s, ret + 1, fmt, ap);
-        va_end(ap);
-    }
+    va_start(ap, fmt);
+    ret = vsnprintf(s, ret + 1, fmt, ap);
+    va_end(ap);
+
     return s;
 }
 
@@ -143,8 +137,9 @@ char *libxl__strdup(libxl__gc *gc, const char *c)
 {
     char *s = strdup(c);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, strlen(c), 1);
+
+    libxl__ptr_add(gc, s);
 
     return s;
 }
@@ -153,8 +148,7 @@ char *libxl__strndup(libxl__gc *gc, const char *c, size_t n)
 {
     char *s = strndup(c, n);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, n, 1);
 
     return s;
 }
@@ -175,6 +169,9 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
              const char *fmt, va_list ap)
 {
+    /* WARNING this function may not call any libxl-provided
+     * memory allocation function, as those may
+     * call libxl__alloc_failed which calls libxl__logv. */
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
     int rc, esave;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 04f13f6..2ad446a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -116,6 +116,12 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
+void libxl__alloc_failed(libxl_ctx *, const char *func,
+                         size_t nmemb, size_t size) __attribute__((noreturn));
+  /* func, size and nmemb are used only in the log message.
+   * You may pass size==0 if size and nmemb are not meaningful
+   * and should not be printed. */
+
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
@@ -380,7 +386,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * collection on exit from the outermost libxl callframe.
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQK-0005aH-4z; Tue, 10 Apr 2012 19:08:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YB-0g
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:46396] by server-2.bemta-4.messagelabs.com id
	6E/BA-17550-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3034 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQF-0002KQ-RM; Tue, 10 Apr 2012 19:08:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mh-PE;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:36 +0100
Message-ID: <1334084885-14474-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/31] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Also fix the wording in the libxl_internal.h comment forbidding use of
ao_how-taking functions from within libxl.  (There are sadly currently
some such functions.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..c89add8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,9 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->constructing);
     assert(ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b1e0588 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -347,7 +347,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1209,7 +1209,11 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * operation ("ao") machinery.  The function should take a parameter
  * const libxl_asyncop_how *ao_how and must start with a call to
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * outside libxl, because they can cause reentrancy callbacks.
+ * inside libxl, because they can cause reentrancy callbacks.
+ *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
  *
  * Lifecycle of an ao:
  *
@@ -1240,8 +1244,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1255,12 +1258,14 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
     AO_GC;
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1269,6 +1274,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQI-0005YL-5t; Tue, 10 Apr 2012 19:08:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQH-0005Xc-9r
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:13 +0000
Received: from [85.158.143.99:62983] by server-3.bemta-4.messagelabs.com id
	0C/66-05853-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3029 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQF-0002KP-PO; Tue, 10 Apr 2012 19:08:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003mf-Oh;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:35 +0100
Message-ID: <1334084885-14474-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/31] .gitignore: Add a missing file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2782ee5..cd12b56 100644
--- a/.gitignore
+++ b/.gitignore
@@ -357,6 +357,7 @@ tools/firmware/etherboot/eb-roms.h
 tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
 tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
+tools/misc/xen-lowmemd
 tools/libvchan/vchan-node[12]
 tools/ocaml/*/.ocamldep.make
 tools/ocaml/*/*.cm[ixao]
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQT-0005mV-LS; Tue, 10 Apr 2012 19:08:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YC-Bn
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63041] by server-1.bemta-4.messagelabs.com id
	EC/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3081 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Kf-74; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003n1-4S;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:41 +0100
Message-ID: <1334084885-14474-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/31] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

Fix the configure test to test -pthread, and plumb the resulting flag
through to PTHREAD_{CFLAGS,LDFLAGS} in Tools.mk; also substitute
PTHREAD_LIBS (although this will currently always be empty).
Remove PTHREAD_LIBS setting from StdGNU.mk.

Fix the one user (libxc) to use PTHREAD_{CFLAGS,LDFLAGS} too.

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 config/StdGNU.mk     |    1 -
 config/Tools.mk.in   |    4 ++
 tools/configure      |  101 ++++++++++++++++++++++++++++++++++++--------------
 tools/configure.ac   |    5 +-
 tools/libxc/Makefile |    4 +-
 tools/m4/pthread.m4  |   41 ++++++++++++++++++++
 tools/m4/savevar.m4  |    6 +++
 7 files changed, 130 insertions(+), 32 deletions(-)
 create mode 100644 tools/m4/pthread.m4
 create mode 100644 tools/m4/savevar.m4

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index e2c9335..e2f2e1e 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,6 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 339a7b6..912d021 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -26,6 +26,10 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
+PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
+PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
+PTHREAD_LIBS        := @PTHREAD_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 64b7eb5..86618f5 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,9 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTHREAD_LIBS
+PTHREAD_LDFLAGS
+PTHREAD_CFLAGS
 libgcrypt
 libext2fs
 system_aio
@@ -3861,6 +3864,9 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
+
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -3924,6 +3930,22 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+
+
+
+
+
+
+
 
 # Enable/disable options
 
@@ -7228,47 +7250,70 @@ else
 fi
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in -lpthread" >&5
-$as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if test "${ac_cv_lib_pthread_pthread_create+set}" = set; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
+$as_echo_n "checking for pthread flag... " >&6; }
+if test "${ax_cv_pthread_flags+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
-  ac_check_lib_save_LIBS=$LIBS
-LIBS="-lpthread  $LIBS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+
+        ax_cv_pthread_flags=-pthread
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
+    saved_CFLAGS="$CFLAGS"
+
+    saved_LDFLAGS="$LDFLAGS"
+
+    saved_LIBS="$LIBS"
+
+
+    CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+    LDFLAGS="$LDFLAGS $PTHREAD_LDFLAGS"
+
+    LIBS="$LIBS $PTHREAD_LIBS"
+
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
-/* Override any GCC internal prototype to avoid an error.
-   Use char because int might match the return type of a GCC
-   builtin and then its argument prototype would still apply.  */
-#ifdef __cplusplus
-extern "C"
-#endif
-char pthread_create ();
-int
-main ()
-{
-return pthread_create ();
-  ;
-  return 0;
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
 }
+
 _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
-  ac_cv_lib_pthread_pthread_create=yes
+
 else
-  ac_cv_lib_pthread_pthread_create=no
+  ax_cv_pthread_flags=failed
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthread_create" >&5
-$as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" = x""yes; then :
 
-else
-  as_fn_error $? "Could not find libpthread" "$LINENO" 5
+    CFLAGS="$saved_CFLAGS"
+
+    LDFLAGS="$saved_LDFLAGS"
+
+    LIBS="$saved_LIBS"
+
+
 fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_pthread_flags" >&5
+$as_echo "$ax_cv_pthread_flags" >&6; }
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        as_fn_error $? "-pthread does not work" "$LINENO" 5
+    fi
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index 0204e36..250dffd 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -23,6 +23,7 @@ AC_USE_SYSTEM_EXTENSIONS
 AC_CANONICAL_HOST
 
 # M4 Macro includes
+m4_include([m4/savevar.m4])
 m4_include([m4/features.m4])
 m4_include([m4/path_or_fail.m4])
 m4_include([m4/python_version.m4])
@@ -33,6 +34,7 @@ m4_include([m4/set_cflags_ldflags.m4])
 m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
+m4_include([m4/pthread.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -129,8 +131,7 @@ AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
 AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
-AC_CHECK_LIB([pthread], [pthread_create], [] ,
-    [AC_MSG_ERROR([Could not find libpthread])])
+AX_CHECK_PTHREAD
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 55eb755..a1ba134 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -73,6 +73,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -157,7 +159,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
diff --git a/tools/m4/pthread.m4 b/tools/m4/pthread.m4
new file mode 100644
index 0000000..57ea85c
--- /dev/null
+++ b/tools/m4/pthread.m4
@@ -0,0 +1,41 @@
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+AC_DEFUN([AX_PTHREAD_CV2VARS],[
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+])
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+AC_DEFUN([AX_PTHREAD_VARS],[$1(CFLAGS) $1(LDFLAGS) $1(LIBS)])
+
+AC_DEFUN([AX_PTHREAD_VAR_APPLY],[
+    $1="$$1 $PTHREAD_$1"
+])
+AC_DEFUN([AX_PTHREAD_VAR_SUBST],[AC_SUBST(PTHREAD_$1)])
+
+AC_DEFUN([AX_CHECK_PTHREAD],[
+    AC_CACHE_CHECK([for pthread flag], [ax_cv_pthread_flags], [
+        ax_cv_pthread_flags=-pthread
+        AX_PTHREAD_CV2VARS
+        AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
+        AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
+        AC_LINK_IFELSE([
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
+}
+],[],[ax_cv_pthread_flags=failed])
+        AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
+    ])
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        AC_MSG_ERROR([-pthread does not work])
+    fi
+    AX_PTHREAD_CV2VARS
+    AX_PTHREAD_VARS([AX_PTHREAD_VAR_SUBST])
+])
diff --git a/tools/m4/savevar.m4 b/tools/m4/savevar.m4
new file mode 100644
index 0000000..2156bee
--- /dev/null
+++ b/tools/m4/savevar.m4
@@ -0,0 +1,6 @@
+AC_DEFUN([AX_SAVEVAR_SAVE],[
+    saved_$1="$$1"
+])
+AC_DEFUN([AX_SAVEVAR_RESTORE],[
+    $1="$saved_$1"
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQU-0005oq-Tx; Tue, 10 Apr 2012 19:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Z7-Ul
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:63061] by server-1.bemta-4.messagelabs.com id
	1E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25032 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L9-QO; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nn-Or;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:53 +0100
Message-ID: <1334084885-14474-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/31] libxl: provide STATE_AO_GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Provide a convenience macro for use in ao callback functions, and
document that it should be used.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a8372bb..76875bb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1266,9 +1266,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
  *    - The one in ao, whose lifetime is the asynchronous operation
- *   Usually callback function should use CONTAINER_OF
- *   to obtain its own structure, containing a pointer to the ao,
- *   and then use the gc from that ao.
+ *   Usually callback function should use CONTAINER_OF to obtain its
+ *   own state structure, containing a pointer to the ao.  It should
+ *   then obtain the ao and use the ao's gc; this is most easily done
+ *   using the convenience macro STATE_AO_GC.
  */
 
 #define AO_CREATE(ctx, domid, ao_how)                           \
@@ -1298,6 +1299,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 #define AO_GC                                   \
     libxl__gc *const gc = &ao->gc
 
+#define STATE_AO_GC(op)                         \
+    libxl__ao *const ao = op->ao;               \
+    AO_GC
+
 
 /* All of these MUST be called with the ctx locked.
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQU-0005oq-Tx; Tue, 10 Apr 2012 19:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005Z7-Ul
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:63061] by server-1.bemta-4.messagelabs.com id
	1E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25032 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L9-QO; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nn-Or;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:53 +0100
Message-ID: <1334084885-14474-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/31] libxl: provide STATE_AO_GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Provide a convenience macro for use in ao callback functions, and
document that it should be used.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a8372bb..76875bb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1266,9 +1266,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
  *    - The one in ao, whose lifetime is the asynchronous operation
- *   Usually callback function should use CONTAINER_OF
- *   to obtain its own structure, containing a pointer to the ao,
- *   and then use the gc from that ao.
+ *   Usually callback function should use CONTAINER_OF to obtain its
+ *   own state structure, containing a pointer to the ao.  It should
+ *   then obtain the ao and use the ao's gc; this is most easily done
+ *   using the convenience macro STATE_AO_GC.
  */
 
 #define AO_CREATE(ctx, domid, ao_how)                           \
@@ -1298,6 +1299,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 #define AO_GC                                   \
     libxl__gc *const gc = &ao->gc
 
+#define STATE_AO_GC(op)                         \
+    libxl__ao *const ao = op->ao;               \
+    AO_GC
+
 
 /* All of these MUST be called with the ctx locked.
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQM-0005cf-Kg; Tue, 10 Apr 2012 19:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YP-OX
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:63000] by server-1.bemta-4.messagelabs.com id
	7B/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3041 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQF-0002KT-UI; Tue, 10 Apr 2012 19:08:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003ml-R9;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:37 +0100
Message-ID: <1334084885-14474-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/31] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7a54524..dd948a8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1406,7 +1406,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1873,7 +1873,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2220,7 +2220,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2353,7 +2353,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b1e0588..5167b71 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -692,7 +692,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQM-0005cf-Kg; Tue, 10 Apr 2012 19:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005YP-OX
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:63000] by server-1.bemta-4.messagelabs.com id
	7B/73-20925-D15848F4; Tue, 10 Apr 2012 19:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3041 invoked from network); 10 Apr 2012 19:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQF-0002KT-UI; Tue, 10 Apr 2012 19:08:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQF-0003ml-R9;
	Tue, 10 Apr 2012 20:08:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:37 +0100
Message-ID: <1334084885-14474-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/31] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7a54524..dd948a8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1406,7 +1406,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1873,7 +1873,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2220,7 +2220,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2353,7 +2353,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b1e0588..5167b71 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -692,7 +692,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQR-0005ij-N8; Tue, 10 Apr 2012 19:08:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YB-81
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63115] by server-2.bemta-4.messagelabs.com id
	B2/CA-17550-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!19
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3170 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LX-3c; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oZ-2T;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:05 +0100
Message-ID: <1334084885-14474-32-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 31/31] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index b33abe4..1b17c84 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 1361117..47ced8a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -234,6 +234,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -256,6 +260,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -268,6 +274,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -305,6 +327,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
     return;
 
  out:
+    free(logfile_tmp);
     assert(rc);
     bootloader_callback(egc, bl, rc);
 }
@@ -462,6 +485,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fd96b31..c846144 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1485,6 +1485,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1547,7 +1548,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQR-0005ij-N8; Tue, 10 Apr 2012 19:08:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YB-81
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:63115] by server-2.bemta-4.messagelabs.com id
	B2/CA-17550-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!19
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3170 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LX-3c; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oZ-2T;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:05 +0100
Message-ID: <1334084885-14474-32-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 31/31] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index b33abe4..1b17c84 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 1361117..47ced8a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -234,6 +234,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -256,6 +260,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -268,6 +274,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -305,6 +327,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
     return;
 
  out:
+    free(logfile_tmp);
     assert(rc);
     bootloader_callback(egc, bl, rc);
 }
@@ -462,6 +485,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fd96b31..c846144 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1485,6 +1485,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1547,7 +1548,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQO-0005ep-NF; Tue, 10 Apr 2012 19:08:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Z1-98
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.139.83:11836] by server-10.bemta-5.messagelabs.com id
	55/AA-08260-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334084893!23223547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32498 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LN-00; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003oA-VK;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 20:07:59 +0100
Message-ID: <1334084885-14474-26-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 25/31] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8e47213..a3955a4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1125,6 +1125,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..83c22b3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index c9157a6..dc25ab0 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQO-0005ep-NF; Tue, 10 Apr 2012 19:08:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQJ-0005Z1-98
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:15 +0000
Received: from [85.158.139.83:11836] by server-10.bemta-5.messagelabs.com id
	55/AA-08260-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334084893!23223547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32498 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LN-00; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003oA-VK;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 20:07:59 +0100
Message-ID: <1334084885-14474-26-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 25/31] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8e47213..a3955a4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1125,6 +1125,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..83c22b3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index c9157a6..dc25ab0 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQL-0005bM-0z; Tue, 10 Apr 2012 19:08:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005Xc-BN
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:63034] by server-3.bemta-4.messagelabs.com id
	8E/66-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25002 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Ks-Ge; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nL-EP;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:46 +0100
Message-ID: <1334084885-14474-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/31] libxl: Introduce some convenience macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce:
   <type> *GCNEW(<type> *var);
   <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
   <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
   char *GCSPRINTF(const char *fmt, ...);
   void LOG(<xtl_level_suffix>, const char *fmt, ...);
   void LOGE(<xtl_level_suffix>, const char *fmt, ...);
   void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
all of which expect, in the calling context,
   libxl__gc *gc;

Most of these will find callers in subsequent patches.  The exceptions
are the orthogonally necessary LOGE and LOGEV, and GCREALLOC_ARRAY.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   72 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9340bde..95c34f3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1349,6 +1349,78 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
+/* Allocation macros all of which use the gc. */
+
+#define ARRAY_SIZE_OK(ptr, nmemb) ((nmemb) < INT_MAX / (sizeof(*(ptr)) * 2))
+
+/*
+ * Expression statement  <type> *GCNEW(<type> *var);
+ * Uses                  libxl__gc *gc;
+ *
+ * Allocates a new object of type <type> from the gc and zeroes it
+ * with memset.  Sets var to point to the new object or zero (setting
+ * errno).  Returns the new value of var.
+ */
+#define GCNEW(var)                                      \
+    (((var) = libxl__zalloc((gc),sizeof(*(var)))))
+
+/*
+ * Expression statement  <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Like GCNEW but allocates an array of nmemb elements, as if from
+ * calloc.  Does check for integer overflow due to large nmemb.  If
+ * nmemb is 0 may succeed by returning 0.
+ */
+#define GCNEW_ARRAY(var, nmemb)                                 \
+    ((var) = libxl__calloc((gc), (nmemb), sizeof(*(var))))
+    
+/*
+ * Expression statement  <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Reallocates the array var to be of size nmemb elements.  Updates
+ * var and returns the new value of var.  Does check for integer
+ * overflow due to large nmemb.
+ *
+ * Do not pass nmemb==0.  old may be 0 on entry.
+ */
+#define GCREALLOC_ARRAY(var, nmemb)                                     \
+    (assert(nmemb > 0),                                                 \
+     assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+
+
+/*
+ * Expression            char *GCSPRINTF(const char *fmt, ...);
+ * Uses                  libxl__gc *gc;
+ *
+ * Trivial convenience wrapper for libxl__sprintf.
+ */
+#define GCSPRINTF(fmt, ...) (libxl__sprintf((gc), (fmt), __VA_ARGS__))
+
+
+/*
+ * Expression statements
+ *    void LOG(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGE(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
+ * Use
+ *    libxl__gc *gc;
+ *
+ * Trivial convenience wrappers for LIBXL__LOG, LIBXL__LOG_ERRNO and
+ * LIBXL__LOG_ERRNOVAL, respectively (and thus for libxl__log).
+ *
+ * XTL_<xtl_level_suffix> should exist and be an xentoollog.h log level
+ * So <xtl_level_suffix> should be one of
+ *   DEBUG VERBOSE DETAIL PROGRESS INFO NOTICE WARN ERROR ERROR CRITICAL
+ * Of these, most of libxl uses
+ *   DEBUG INFO WARN ERROR
+ */
+#define LOG(l,f, ...)     LIBXL__LOG(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGE(l,f, ...)    LIBXL__LOG_ERRNO(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGEV(l,e,f, ...) LIBXL__LOG_ERRNOVAL(CTX,XTL_##l,(e),(f),##__VA_ARGS__)
+
 
 /* Locking functions.  See comment for "lock" member of libxl__ctx. */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQL-0005bM-0z; Tue, 10 Apr 2012 19:08:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQI-0005Xc-BN
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:14 +0000
Received: from [85.158.143.99:63034] by server-3.bemta-4.messagelabs.com id
	8E/66-05853-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25002 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Ks-Ge; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nL-EP;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:46 +0100
Message-ID: <1334084885-14474-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/31] libxl: Introduce some convenience macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce:
   <type> *GCNEW(<type> *var);
   <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
   <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
   char *GCSPRINTF(const char *fmt, ...);
   void LOG(<xtl_level_suffix>, const char *fmt, ...);
   void LOGE(<xtl_level_suffix>, const char *fmt, ...);
   void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
all of which expect, in the calling context,
   libxl__gc *gc;

Most of these will find callers in subsequent patches.  The exceptions
are the orthogonally necessary LOGE and LOGEV, and GCREALLOC_ARRAY.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   72 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9340bde..95c34f3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1349,6 +1349,78 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
+/* Allocation macros all of which use the gc. */
+
+#define ARRAY_SIZE_OK(ptr, nmemb) ((nmemb) < INT_MAX / (sizeof(*(ptr)) * 2))
+
+/*
+ * Expression statement  <type> *GCNEW(<type> *var);
+ * Uses                  libxl__gc *gc;
+ *
+ * Allocates a new object of type <type> from the gc and zeroes it
+ * with memset.  Sets var to point to the new object or zero (setting
+ * errno).  Returns the new value of var.
+ */
+#define GCNEW(var)                                      \
+    (((var) = libxl__zalloc((gc),sizeof(*(var)))))
+
+/*
+ * Expression statement  <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Like GCNEW but allocates an array of nmemb elements, as if from
+ * calloc.  Does check for integer overflow due to large nmemb.  If
+ * nmemb is 0 may succeed by returning 0.
+ */
+#define GCNEW_ARRAY(var, nmemb)                                 \
+    ((var) = libxl__calloc((gc), (nmemb), sizeof(*(var))))
+    
+/*
+ * Expression statement  <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Reallocates the array var to be of size nmemb elements.  Updates
+ * var and returns the new value of var.  Does check for integer
+ * overflow due to large nmemb.
+ *
+ * Do not pass nmemb==0.  old may be 0 on entry.
+ */
+#define GCREALLOC_ARRAY(var, nmemb)                                     \
+    (assert(nmemb > 0),                                                 \
+     assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+
+
+/*
+ * Expression            char *GCSPRINTF(const char *fmt, ...);
+ * Uses                  libxl__gc *gc;
+ *
+ * Trivial convenience wrapper for libxl__sprintf.
+ */
+#define GCSPRINTF(fmt, ...) (libxl__sprintf((gc), (fmt), __VA_ARGS__))
+
+
+/*
+ * Expression statements
+ *    void LOG(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGE(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
+ * Use
+ *    libxl__gc *gc;
+ *
+ * Trivial convenience wrappers for LIBXL__LOG, LIBXL__LOG_ERRNO and
+ * LIBXL__LOG_ERRNOVAL, respectively (and thus for libxl__log).
+ *
+ * XTL_<xtl_level_suffix> should exist and be an xentoollog.h log level
+ * So <xtl_level_suffix> should be one of
+ *   DEBUG VERBOSE DETAIL PROGRESS INFO NOTICE WARN ERROR ERROR CRITICAL
+ * Of these, most of libxl uses
+ *   DEBUG INFO WARN ERROR
+ */
+#define LOG(l,f, ...)     LIBXL__LOG(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGE(l,f, ...)    LIBXL__LOG_ERRNO(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGEV(l,e,f, ...) LIBXL__LOG_ERRNOVAL(CTX,XTL_##l,(e),(f),##__VA_ARGS__)
+
 
 /* Locking functions.  See comment for "lock" member of libxl__ctx. */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQU-0005nJ-3R; Tue, 10 Apr 2012 19:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YB-Lc
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46496] by server-2.bemta-4.messagelabs.com id
	23/CA-17550-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25060 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LT-2j; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oV-1v;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:04 +0100
Message-ID: <1334084885-14474-31-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 30/31] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index dc25ab0..8eacebf 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQU-0005nJ-3R; Tue, 10 Apr 2012 19:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YB-Lc
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46496] by server-2.bemta-4.messagelabs.com id
	23/CA-17550-F15848F4; Tue, 10 Apr 2012 19:08:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25060 invoked from network); 10 Apr 2012 19:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQH-0002LT-2j; Tue, 10 Apr 2012 19:08:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQH-0003oV-1v;
	Tue, 10 Apr 2012 20:08:13 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:08:04 +0100
Message-ID: <1334084885-14474-31-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 30/31] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index dc25ab0..8eacebf 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQU-0005o9-HC; Tue, 10 Apr 2012 19:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YP-OM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46467] by server-1.bemta-4.messagelabs.com id
	0E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3100 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L1-MP; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nX-KQ;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 20:07:49 +0100
Message-ID: <1334084885-14474-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/31] libxl: include <_libxl_paths.h> in
	libxl_internal.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ie, we permit general code in libxl direct access to the manifest
constants such as XEN_RUN_DIR.  This simplifies their use in (eg)
format strings.

This might be controversial because it will make it difficult to make
any of these runtime-configurable later without changing lots of use
sites.  But I don't think it's likely we'll want to do that.

For the moment, leave existing call sites of all the functions in
libxl_paths.c unchanged.  The simplified use arrangements can be used
in new code and when we update call sites for other reasons.

Also correct the dependencies in the Makefile so that _libxl_paths.h
is generated before anything that uses libxl_internal.h.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile         |    4 +---
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_paths.c    |    1 -
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b0143e6..9f7e454 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -102,11 +102,9 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl_paths.c: _libxl_paths.h
-
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
-libxl_internal.h: _libxl_types_internal.h
+libxl_internal.h: _libxl_types_internal.h _libxl_paths.h
 libxl_internal_json.h: _libxl_types_internal_json.h
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b35421f..740bde2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -51,6 +51,7 @@
 #include <xen/io/xenbus.h>
 
 #include "libxl.h"
+#include "_libxl_paths.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index a95d29f..388b344 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
-#include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQU-0005o9-HC; Tue, 10 Apr 2012 19:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YP-OM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:16 +0000
Received: from [85.158.143.99:46467] by server-1.bemta-4.messagelabs.com id
	0E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3100 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L1-MP; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nX-KQ;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 10 Apr 2012 20:07:49 +0100
Message-ID: <1334084885-14474-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/31] libxl: include <_libxl_paths.h> in
	libxl_internal.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ie, we permit general code in libxl direct access to the manifest
constants such as XEN_RUN_DIR.  This simplifies their use in (eg)
format strings.

This might be controversial because it will make it difficult to make
any of these runtime-configurable later without changing lots of use
sites.  But I don't think it's likely we'll want to do that.

For the moment, leave existing call sites of all the functions in
libxl_paths.c unchanged.  The simplified use arrangements can be used
in new code and when we update call sites for other reasons.

Also correct the dependencies in the Makefile so that _libxl_paths.h
is generated before anything that uses libxl_internal.h.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile         |    4 +---
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_paths.c    |    1 -
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b0143e6..9f7e454 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -102,11 +102,9 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl_paths.c: _libxl_paths.h
-
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
-libxl_internal.h: _libxl_types_internal.h
+libxl_internal.h: _libxl_types_internal.h _libxl_paths.h
 libxl_internal_json.h: _libxl_types_internal_json.h
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b35421f..740bde2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -51,6 +51,7 @@
 #include <xen/io/xenbus.h>
 
 #include "libxl.h"
+#include "_libxl_paths.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index a95d29f..388b344 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
-#include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQV-0005pe-Bi; Tue, 10 Apr 2012 19:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YC-Uq
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:63083] by server-1.bemta-4.messagelabs.com id
	8E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25020 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Ky-Ka; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nT-II;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:48 +0100
Message-ID: <1334084885-14474-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/31] libxl: Provide libxl_string_list_length
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    8 ++++++++
 tools/libxl/libxl.h |    1 +
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f41b62f..8910420 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -177,6 +177,14 @@ void libxl_string_list_dispose(libxl_string_list *psl)
     free(sl);
 }
 
+int libxl_string_list_length(const libxl_string_list *psl)
+{
+    if (!psl) return 0;
+    int i = 0;
+    while (*psl++) i++;
+    return i;
+}
+
 void libxl_key_value_list_dispose(libxl_key_value_list *pkvl)
 {
     int i;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0219f81..b376316 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -273,6 +273,7 @@ typedef uint8_t libxl_mac[6];
 
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
+int libxl_string_list_length(const libxl_string_list *sl);
 
 typedef char **libxl_key_value_list;
 void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQV-0005pe-Bi; Tue, 10 Apr 2012 19:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQK-0005YC-Uq
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:63083] by server-1.bemta-4.messagelabs.com id
	8E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334084892!22159753!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25020 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002Ky-Ka; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nT-II;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:48 +0100
Message-ID: <1334084885-14474-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/31] libxl: Provide libxl_string_list_length
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    8 ++++++++
 tools/libxl/libxl.h |    1 +
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f41b62f..8910420 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -177,6 +177,14 @@ void libxl_string_list_dispose(libxl_string_list *psl)
     free(sl);
 }
 
+int libxl_string_list_length(const libxl_string_list *psl)
+{
+    if (!psl) return 0;
+    int i = 0;
+    while (*psl++) i++;
+    return i;
+}
+
 void libxl_key_value_list_dispose(libxl_key_value_list *pkvl)
 {
     int i;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0219f81..b376316 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -273,6 +273,7 @@ typedef uint8_t libxl_mac[6];
 
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
+int libxl_string_list_length(const libxl_string_list *sl);
 
 typedef char **libxl_key_value_list;
 void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQV-0005qI-PA; Tue, 10 Apr 2012 19:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQL-0005YP-4g
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:63064] by server-1.bemta-4.messagelabs.com id
	5E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3116 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L6-P0; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nj-ON;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:52 +0100
Message-ID: <1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywhere in libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   13 ++++
 tools/libxl/libxl_fork.c     |  146 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 229 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9f7e454..e5ea867 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8910420..60dbfdc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index ea553f6..2d2196f 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -371,6 +371,19 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl_postfork_child_noexec in the child.  One call
+ * on any existing (or specially made) ctx is sufficient; after
+ * this all previously existing libxl_ctx's are invalidated and
+ * must not be used - or even freed.  It is harmless to call this
+ * postfork function and then exec anyway.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..4751ef4
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered) { rc = 0; goto out; }
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) libxl__alloc_failed(ctx, __func__, 0,0);
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    libxl_fd_set_cloexec(ctx, fd, 1);
+    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    cf = libxl__carefd_record(ctx, fd);
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            if (r)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING,
+                                 "failed to close fd=%d"
+                                 " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    atfork_lock();
+    LIBXL_LIST_REMOVE(cf, entry);
+    atfork_unlock();
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 740bde2..a8372bb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -611,6 +611,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1307,6 +1310,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  Cannot fail. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  Cannot fail. */
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 62c0abd..a6ffd25 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -96,6 +96,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 19:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 19:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHgQV-0005qI-PA; Tue, 10 Apr 2012 19:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHgQL-0005YP-4g
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:08:17 +0000
Received: from [85.158.143.99:63064] by server-1.bemta-4.messagelabs.com id
	5E/73-20925-E15848F4; Tue, 10 Apr 2012 19:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334084889!19691659!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzMzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3116 invoked from network); 10 Apr 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,400,1330905600"; d="scan'208";a="11864762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 20:08:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHgQG-0002L6-P0; Tue, 10 Apr 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHgQG-0003nj-ON;
	Tue, 10 Apr 2012 20:08:12 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 10 Apr 2012 20:07:52 +0100
Message-ID: <1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywhere in libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   13 ++++
 tools/libxl/libxl_fork.c     |  146 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 229 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9f7e454..e5ea867 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8910420..60dbfdc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index ea553f6..2d2196f 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -371,6 +371,19 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl_postfork_child_noexec in the child.  One call
+ * on any existing (or specially made) ctx is sufficient; after
+ * this all previously existing libxl_ctx's are invalidated and
+ * must not be used - or even freed.  It is harmless to call this
+ * postfork function and then exec anyway.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..4751ef4
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered) { rc = 0; goto out; }
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) libxl__alloc_failed(ctx, __func__, 0,0);
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    libxl_fd_set_cloexec(ctx, fd, 1);
+    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    cf = libxl__carefd_record(ctx, fd);
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            if (r)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING,
+                                 "failed to close fd=%d"
+                                 " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    atfork_lock();
+    LIBXL_LIST_REMOVE(cf, entry);
+    atfork_unlock();
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 740bde2..a8372bb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -611,6 +611,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1307,6 +1310,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  Cannot fail. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  Cannot fail. */
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 62c0abd..a6ffd25 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -96,6 +96,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 20:12:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 20:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHhPl-0004XG-9t; Tue, 10 Apr 2012 20:11:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1SHhPk-0004XB-6I
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 20:11:44 +0000
Received: from [85.158.143.99:47821] by server-3.bemta-4.messagelabs.com id
	F7/AE-05853-FF3948F4; Tue, 10 Apr 2012 20:11:43 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334088699!13312305!1
X-Originating-IP: [216.237.3.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7678 invoked from network); 10 Apr 2012 20:11:41 -0000
Received: from mail.solarflare.com (HELO ocex02.SolarFlarecom.com)
	(216.237.3.220)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Apr 2012 20:11:41 -0000
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Tue, 10 Apr 2012 13:11:37 -0700
Message-ID: <1334088690.2624.1.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
To: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 21:11:30 +0100
In-Reply-To: <1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
Organization: Solarflare Communications
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
MIME-Version: 1.0
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.800.1017-18828.005
X-TM-AS-Result: No--9.445000-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: Wei Liu <wei.liu2@citrix.com>, "Pekka Savola \(ipv6\)" <pekkas@netcore.fi>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	netdev@vger.kernel.org, James Morris <jmorris@namei.org>,
	xen-devel@lists.xen.org, Patrick McHardy <kaber@trash.net>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	=?UTF-8?Q?Micha=C5=82_Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 07/10] net: only allow paged fragments with
 the same destructor to be coalesced.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shouldn't this be folded into the previous change 'net: add support for
per-paged-fragment destructors'?  Maybe it doesn't matter since nothing
is setting a non-NULL fragment destructor yet.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 20:12:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 20:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHhPl-0004XG-9t; Tue, 10 Apr 2012 20:11:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1SHhPk-0004XB-6I
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 20:11:44 +0000
Received: from [85.158.143.99:47821] by server-3.bemta-4.messagelabs.com id
	F7/AE-05853-FF3948F4; Tue, 10 Apr 2012 20:11:43 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334088699!13312305!1
X-Originating-IP: [216.237.3.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7678 invoked from network); 10 Apr 2012 20:11:41 -0000
Received: from mail.solarflare.com (HELO ocex02.SolarFlarecom.com)
	(216.237.3.220)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Apr 2012 20:11:41 -0000
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Tue, 10 Apr 2012 13:11:37 -0700
Message-ID: <1334088690.2624.1.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
To: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 10 Apr 2012 21:11:30 +0100
In-Reply-To: <1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
Organization: Solarflare Communications
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
MIME-Version: 1.0
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.800.1017-18828.005
X-TM-AS-Result: No--9.445000-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: Wei Liu <wei.liu2@citrix.com>, "Pekka Savola \(ipv6\)" <pekkas@netcore.fi>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	netdev@vger.kernel.org, James Morris <jmorris@namei.org>,
	xen-devel@lists.xen.org, Patrick McHardy <kaber@trash.net>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	=?UTF-8?Q?Micha=C5=82_Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 07/10] net: only allow paged fragments with
 the same destructor to be coalesced.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shouldn't this be folded into the previous change 'net: add support for
per-paged-fragment destructors'?  Maybe it doesn't matter since nothing
is setting a non-NULL fragment destructor yet.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 22:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 22:24:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHjTj-0005vn-BR; Tue, 10 Apr 2012 22:23:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHjTh-0005vi-M5
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 22:23:58 +0000
Received: from [85.158.143.35:24170] by server-1.bemta-4.messagelabs.com id
	EF/FA-20925-CF2B48F4; Tue, 10 Apr 2012 22:23:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334096635!8238222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12553 invoked from network); 10 Apr 2012 22:23:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 22:23:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,401,1330905600"; d="scan'208";a="11866142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 22:23:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 23:23:53 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHjTd-0003rj-92;
	Tue, 10 Apr 2012 22:23:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHjTd-00023Q-3Y;
	Tue, 10 Apr 2012 23:23:53 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12632-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 23:23:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12632 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                e63089b08140adea85d011da136c7b56d73296ee
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-mingo-tip-master
+ revision=e63089b08140adea85d011da136c7b56d73296ee
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-mingo-tip-master e63089b08140adea85d011da136c7b56d73296ee
+ branch=linux-mingo-tip-master
+ revision=e63089b08140adea85d011da136c7b56d73296ee
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-mingo-tip-master
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-mingo-tip-master
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.linux-mingo-tip-master
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree linux-mingo-tip-master
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
+ : -f
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-mingo-tip-master
+ : tested/linux-mingo-tip-master
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push -f xen@xenbits.xensource.com:git/linux-pvops.git e63089b08140adea85d011da136c7b56d73296ee:tested/linux-mingo-tip-master
Counting objects: 1   
Counting objects: 7   
Counting objects: 10   
Counting objects: 422   
Counting objects: 809   
Counting objects: 3371   
Counting objects: 7557   
Counting objects: 16162   
Counting objects: 31711   
Counting objects: 49542   
Counting objects: 74361   
Counting objects: 102682   
Counting objects: 118617, done.
Compressing objects:   0% (1/19257)   
Compressing objects:   0% (173/19257)   
Compressing objects:   1% (193/19257)   
Compressing objects:   2% (386/19257)   
Compressing objects:   2% (482/19257)   
Compressing objects:   3% (578/19257)   
Compressing objects:   4% (771/19257)   
Compressing objects:   5% (963/19257)   
Compressing objects:   5% (1108/19257)   
Compressing objects:   6% (1156/19257)   
Compressing objects:   7% (1348/19257)   
Compressing objects:   7% (1400/19257)   
Compressing objects:   8% (1541/19257)   
Compressing objects:   8% (1710/19257)   
Compressing objects:   9% (1734/19257)   
Compressing objects:  10% (1926/19257)   
Compressing objects:  11% (2119/19257)   
Compressing objects:  11% (2195/19257)   
Compressing objects:  12% (2311/19257)   
Compressing objects:  13% (2504/19257)   
Compressing objects:  13% (2566/19257)   
Compressing objects:  14% (2696/19257)   
Compressing objects:  14% (2882/19257)   
Compressing objects:  15% (2889/19257)   
Compressing objects:  16% (3082/19257)   
Compressing objects:  16% (3116/19257)   
Compressing objects:  17% (3274/19257)   
Compressing objects:  18% (3467/19257)   
Compressing objects:  19% (3659/19257)   
Compressing objects:  20% (3852/19257)   
Compressing objects:  21% (4044/19257)   
Compressing objects:  22% (4237/19257)   
Compressing objects:  23% (4430/19257)   
Compressing objects:  24% (4622/19257)   
Compressing objects:  25% (4815/19257)   
Compressing objects:  26% (5007/19257)   
Compressing objects:  27% (5200/19257)   
Compressing objects:  28% (5392/19257)   
Compressing objects:  29% (5585/19257)   
Compressing objects:  30% (5778/19257)   
Compressing objects:  31% (5970/19257)   
Compressing objects:  32% (6163/19257)   
Compressing objects:  33% (6355/19257)   
Compressing objects:  34% (6548/19257)   
Compressing objects:  35% (6740/19257)   
Compressing objects:  36% (6933/19257)   
Compressing objects:  37% (7126/19257)   
Compressing objects:  38% (7318/19257)   
Compressing objects:  39% (7511/19257)   
Compressing objects:  40% (7703/19257)   
Compressing objects:  41% (7896/19257)   
Compressing objects:  42% (8088/19257)   
Compressing objects:  43% (8281/19257)   
Compressing objects:  44% (8474/19257)   
Compressing objects:  45% (8666/19257)   
Compressing objects:  45% (8739/19257)   
Compressing objects:  46% (8859/19257)   
Compressing objects:  47% (9051/19257)   
Compressing objects:  48% (9244/19257)   
Compressing objects:  49% (9436/19257)   
Compressing objects:  50% (9629/19257)   
Compressing objects:  51% (9822/19257)   
Compressing objects:  52% (10014/19257)   
Compressing objects:  53% (10207/19257)   
Compressing objects:  54% (10399/19257)   
Compressing objects:  55% (10592/19257)   
Compressing objects:  56% (10784/19257)   
Compressing objects:  57% (10977/19257)   
Compressing objects:  58% (11170/19257)   
Compressing objects:  59% (11362/19257)   
Compressing objects:  60% (11555/19257)   
Compressing objects:  61% (11747/19257)   
Compressing objects:  62% (11940/19257)   
Compressing objects:  63% (12132/19257)   
Compressing objects:  64% (12325/19257)   
Compressing objects:  65% (12518/19257)   
Compressing objects:  66% (12710/19257)   
Compressing objects:  67% (12903/19257)   
Compressing objects:  68% (13095/19257)   
Compressing objects:  69% (13288/19257)   
Compressing objects:  70% (13480/19257)   
Compressing objects:  71% (13673/19257)   
Compressing objects:  72% (13866/19257)   
Compressing objects:  73% (14058/19257)   
Compressing objects:  74% (14251/19257)   
Compressing objects:  75% (14443/19257)   
Compressing objects:  76% (14636/19257)   
Compressing objects:  77% (14828/19257)   
Compressing objects:  78% (15021/19257)   
Compressing objects:  79% (15214/19257)   
Compressing objects:  80% (15406/19257)   
Compressing objects:  81% (15599/19257)   
Compressing objects:  82% (15791/19257)   
Compressing objects:  83% (15984/19257)   
Compressing objects:  84% (16176/19257)   
Compressing objects:  85% (16369/19257)   
Compressing objects:  86% (16562/19257)   
Compressing objects:  87% (16754/19257)   
Compressing objects:  88% (16947/19257)   
Compressing objects:  89% (17139/19257)   
Compressing objects:  90% (17332/19257)   
Compressing objects:  91% (17524/19257)   
Compressing objects:  92% (17717/19257)   
Compressing objects:  93% (17910/19257)   
Compressing objects:  94% (18102/19257)   
Compressing objects:  95% (18295/19257)   
Compressing objects:  96% (18487/19257)   
Compressing objects:  97% (18680/19257)   
Compressing objects:  98% (18872/19257)   
Compressing objects:  99% (19065/19257)   
Compressing objects: 100% (19257/19257)   
Compressing objects: 100% (19257/19257), done.
Writing objects:   0% (1/101021)   
Writing objects:   1% (1011/101021)   
Writing objects:   2% (2021/101021)   
Writing objects:   3% (3031/101021)   
Writing objects:   4% (4041/101021)   
Writing objects:   5% (5052/101021)   
Writing objects:   5% (5436/101021), 2.14 MiB | 1466 KiB/s   
Writing objects:   5% (5575/101021), 2.19 MiB | 1062 KiB/s   
Writing objects:   6% (6062/101021), 2.32 MiB | 894 KiB/s   
Writing objects:   7% (7072/101021), 2.32 MiB | 894 KiB/s   
Writing objects:   7% (7213/101021), 2.32 MiB | 894 KiB/s   
Writing objects:   8% (8082/101021), 3.08 MiB | 981 KiB/s   
Writing objects:   9% (9092/101021), 3.08 MiB | 981 KiB/s   
Writing objects:   9% (9555/101021), 3.46 MiB | 906 KiB/s   
Writing objects:  10% (10103/101021), 3.46 MiB | 906 KiB/s   
Writing objects:  10% (11008/101021), 3.84 MiB | 869 KiB/s   
Writing objects:  11% (11113/101021), 3.84 MiB | 869 KiB/s   
Writing objects:  12% (12123/101021), 4.21 MiB | 810 KiB/s   
Writing objects:  12% (12724/101021), 4.58 MiB | 784 KiB/s   
Writing objects:  13% (13133/101021), 4.58 MiB | 784 KiB/s   
Writing objects:  14% (14144/101021), 4.96 MiB | 500 KiB/s   
Writing objects:  14% (14256/101021), 5.21 MiB | 541 KiB/s   
Writing objects:  14% (14782/101021), 5.46 MiB | 558 KiB/s   
Writing objects:  15% (15155/101021), 5.46 MiB | 558 KiB/s   
Writing objects:  15% (15476/101021), 5.71 MiB | 558 KiB/s   
Writing objects:  15% (15903/101021), 5.96 MiB | 458 KiB/s   
Writing objects:  16% (16164/101021), 6.21 MiB | 441 KiB/s   
Writing objects:  16% (16865/101021), 6.58 MiB | 439 KiB/s   
Writing objects:  17% (17174/101021), 6.58 MiB | 439 KiB/s   
Writing objects:  17% (17838/101021), 6.96 MiB | 454 KiB/s   
Writing objects:  18% (18185/101021), 7.33 MiB | 451 KiB/s   
Writing objects:  18% (18916/101021), 7.71 MiB | 452 KiB/s   
Writing objects:  19% (19194/101021), 7.71 MiB | 452 KiB/s   
Writing objects:  20% (20205/101021), 8.08 MiB | 475 KiB/s   
Writing objects:  20% (20221/101021), 8.46 MiB | 511 KiB/s   
Writing objects:  20% (20991/101021), 8.83 MiB | 544 KiB/s   
Writing objects:  21% (21217/101021), 8.83 MiB | 544 KiB/s   
Writing objects:  21% (22219/101021), 9.46 MiB | 594 KiB/s   
Writing objects:  22% (22225/101021), 9.46 MiB | 594 KiB/s   
Writing objects:  23% (23235/101021), 9.83 MiB | 595 KiB/s   
Writing objects:  23% (23246/101021), 10.21 MiB | 589 KiB/s   
Writing objects:  24% (24248/101021), 10.58 MiB | 592 KiB/s   
Writing objects:  24% (24304/101021), 10.58 MiB | 592 KiB/s   
Writing objects:  25% (25256/101021), 10.96 MiB | 593 KiB/s   
Writing objects:  25% (25743/101021), 11.33 MiB | 594 KiB/s   
Writing objects:  26% (26266/101021), 11.33 MiB | 594 KiB/s   
Writing objects:  27% (27276/101021), 11.71 MiB | 595 KiB/s   
Writing objects:  27% (27624/101021), 11.96 MiB | 583 KiB/s   
Writing objects:  28% (28287/101021), 11.96 MiB | 583 KiB/s   
Writing objects:  28% (28747/101021), 12.33 MiB | 592 KiB/s   
Writing objects:  29% (29297/101021), 12.33 MiB | 592 KiB/s   
Writing objects:  30% (30307/101021), 12.71 MiB | 590 KiB/s   
Writing objects:  31% (31317/101021), 12.71 MiB | 590 KiB/s   
Writing objects:  31% (31543/101021), 12.96 MiB | 578 KiB/s   
Writing objects:  32% (32327/101021), 12.96 MiB | 578 KiB/s   
Writing objects:  33% (33337/101021), 12.96 MiB | 578 KiB/s   
Writing objects:  34% (34348/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  35% (35358/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  35% (35825/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  36% (36369/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  37% (37378/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  38% (38388/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  39% (39399/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  40% (40409/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  41% (41420/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  41% (41488/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  42% (42429/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  43% (43440/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  44% (44450/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  45% (45460/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  45% (45852/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  46% (46470/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  47% (47480/101021), 14.83 MiB | 574 KiB/s   
Writing objects:  48% (48492/101021), 14.83 MiB | 574 KiB/s   
Writing objects:  49% (49501/101021), 14.83 MiB | 574 KiB/s   
Writing objects:  50% (50511/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  50% (50758/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  51% (51521/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  52% (52531/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  53% (53542/101021), 15.58 MiB | 583 KiB/s   
Writing objects:  54% (54552/101021), 15.58 MiB | 583 KiB/s   
Writing objects:  55% (55562/101021), 15.58 MiB | 583 KiB/s   
Writing objects:  55% (56373/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  56% (56572/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  57% (57582/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  58% (58594/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  59% (59603/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  60% (60613/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  60% (61041/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  61% (61623/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  62% (62634/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  63% (63644/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  64% (64654/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  65% (65664/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  66% (66674/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  66% (66990/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  67% (67685/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  68% (68695/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  69% (69705/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  70% (70715/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  71% (71726/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  72% (72736/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  72% (73271/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  73% (73746/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  74% (74756/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  75% (75766/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  76% (76776/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  77% (77787/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  77% (78471/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  78% (78799/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  79% (79808/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  80% (80817/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  81% (81828/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  82% (82838/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  83% (83848/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  83% (84657/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  84% (84858/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  85% (85868/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  86% (86879/101021), 18.96 MiB | 603 KiB/s   
Writing objects:  87% (87890/101021), 18.96 MiB | 603 KiB/s   
Writing objects:  88% (88899/101021), 18.96 MiB | 603 KiB/s   
Writing objects:  89% (89909/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  89% (90835/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  90% (90919/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  91% (91930/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  92% (92940/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  93% (93950/101021), 19.71 MiB | 603 KiB/s   
Writing objects:  94% (94960/101021), 19.71 MiB | 603 KiB/s   
Writing objects:  95% (95971/101021), 19.71 MiB | 603 KiB/s   
Writing objects:  95% (96582/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  96% (96981/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  97% (97991/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  98% (99001/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  99% (100011/101021), 20.08 MiB | 596 KiB/s   
Writing objects: 100% (101021/101021), 20.46 MiB | 593 KiB/s   
Writing objects: 100% (101021/101021), 20.51 MiB | 597 KiB/s, done.
Total 101021 (delta 84244), reused 96025 (delta 79512)
To xen@xenbits.xensource.com:git/linux-pvops.git
   c16fa4f..e63089b  e63089b08140adea85d011da136c7b56d73296ee -> tested/linux-mingo-tip-master
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 10 22:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Apr 2012 22:24:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHjTj-0005vn-BR; Tue, 10 Apr 2012 22:23:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHjTh-0005vi-M5
	for xen-devel@lists.xensource.com; Tue, 10 Apr 2012 22:23:58 +0000
Received: from [85.158.143.35:24170] by server-1.bemta-4.messagelabs.com id
	EF/FA-20925-CF2B48F4; Tue, 10 Apr 2012 22:23:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334096635!8238222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12553 invoked from network); 10 Apr 2012 22:23:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Apr 2012 22:23:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,401,1330905600"; d="scan'208";a="11866142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Apr 2012 22:23:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Apr 2012 23:23:53 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHjTd-0003rj-92;
	Tue, 10 Apr 2012 22:23:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHjTd-00023Q-3Y;
	Tue, 10 Apr 2012 23:23:53 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12632-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Apr 2012 23:23:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12632 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                e63089b08140adea85d011da136c7b56d73296ee
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-mingo-tip-master
+ revision=e63089b08140adea85d011da136c7b56d73296ee
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-mingo-tip-master e63089b08140adea85d011da136c7b56d73296ee
+ branch=linux-mingo-tip-master
+ revision=e63089b08140adea85d011da136c7b56d73296ee
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-mingo-tip-master
+ : master
+ : tested/2.6.39.x
+ : :git/qemu-upstream-unstable.git
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-mingo-tip-master
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : :git/qemu-upstream-unstable.git
++ : daily-cron.linux-mingo-tip-master
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ info_linux_tree linux-mingo-tip-master
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
+ : -f
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-mingo-tip-master
+ : tested/linux-mingo-tip-master
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push -f xen@xenbits.xensource.com:git/linux-pvops.git e63089b08140adea85d011da136c7b56d73296ee:tested/linux-mingo-tip-master
Counting objects: 1   
Counting objects: 7   
Counting objects: 10   
Counting objects: 422   
Counting objects: 809   
Counting objects: 3371   
Counting objects: 7557   
Counting objects: 16162   
Counting objects: 31711   
Counting objects: 49542   
Counting objects: 74361   
Counting objects: 102682   
Counting objects: 118617, done.
Compressing objects:   0% (1/19257)   
Compressing objects:   0% (173/19257)   
Compressing objects:   1% (193/19257)   
Compressing objects:   2% (386/19257)   
Compressing objects:   2% (482/19257)   
Compressing objects:   3% (578/19257)   
Compressing objects:   4% (771/19257)   
Compressing objects:   5% (963/19257)   
Compressing objects:   5% (1108/19257)   
Compressing objects:   6% (1156/19257)   
Compressing objects:   7% (1348/19257)   
Compressing objects:   7% (1400/19257)   
Compressing objects:   8% (1541/19257)   
Compressing objects:   8% (1710/19257)   
Compressing objects:   9% (1734/19257)   
Compressing objects:  10% (1926/19257)   
Compressing objects:  11% (2119/19257)   
Compressing objects:  11% (2195/19257)   
Compressing objects:  12% (2311/19257)   
Compressing objects:  13% (2504/19257)   
Compressing objects:  13% (2566/19257)   
Compressing objects:  14% (2696/19257)   
Compressing objects:  14% (2882/19257)   
Compressing objects:  15% (2889/19257)   
Compressing objects:  16% (3082/19257)   
Compressing objects:  16% (3116/19257)   
Compressing objects:  17% (3274/19257)   
Compressing objects:  18% (3467/19257)   
Compressing objects:  19% (3659/19257)   
Compressing objects:  20% (3852/19257)   
Compressing objects:  21% (4044/19257)   
Compressing objects:  22% (4237/19257)   
Compressing objects:  23% (4430/19257)   
Compressing objects:  24% (4622/19257)   
Compressing objects:  25% (4815/19257)   
Compressing objects:  26% (5007/19257)   
Compressing objects:  27% (5200/19257)   
Compressing objects:  28% (5392/19257)   
Compressing objects:  29% (5585/19257)   
Compressing objects:  30% (5778/19257)   
Compressing objects:  31% (5970/19257)   
Compressing objects:  32% (6163/19257)   
Compressing objects:  33% (6355/19257)   
Compressing objects:  34% (6548/19257)   
Compressing objects:  35% (6740/19257)   
Compressing objects:  36% (6933/19257)   
Compressing objects:  37% (7126/19257)   
Compressing objects:  38% (7318/19257)   
Compressing objects:  39% (7511/19257)   
Compressing objects:  40% (7703/19257)   
Compressing objects:  41% (7896/19257)   
Compressing objects:  42% (8088/19257)   
Compressing objects:  43% (8281/19257)   
Compressing objects:  44% (8474/19257)   
Compressing objects:  45% (8666/19257)   
Compressing objects:  45% (8739/19257)   
Compressing objects:  46% (8859/19257)   
Compressing objects:  47% (9051/19257)   
Compressing objects:  48% (9244/19257)   
Compressing objects:  49% (9436/19257)   
Compressing objects:  50% (9629/19257)   
Compressing objects:  51% (9822/19257)   
Compressing objects:  52% (10014/19257)   
Compressing objects:  53% (10207/19257)   
Compressing objects:  54% (10399/19257)   
Compressing objects:  55% (10592/19257)   
Compressing objects:  56% (10784/19257)   
Compressing objects:  57% (10977/19257)   
Compressing objects:  58% (11170/19257)   
Compressing objects:  59% (11362/19257)   
Compressing objects:  60% (11555/19257)   
Compressing objects:  61% (11747/19257)   
Compressing objects:  62% (11940/19257)   
Compressing objects:  63% (12132/19257)   
Compressing objects:  64% (12325/19257)   
Compressing objects:  65% (12518/19257)   
Compressing objects:  66% (12710/19257)   
Compressing objects:  67% (12903/19257)   
Compressing objects:  68% (13095/19257)   
Compressing objects:  69% (13288/19257)   
Compressing objects:  70% (13480/19257)   
Compressing objects:  71% (13673/19257)   
Compressing objects:  72% (13866/19257)   
Compressing objects:  73% (14058/19257)   
Compressing objects:  74% (14251/19257)   
Compressing objects:  75% (14443/19257)   
Compressing objects:  76% (14636/19257)   
Compressing objects:  77% (14828/19257)   
Compressing objects:  78% (15021/19257)   
Compressing objects:  79% (15214/19257)   
Compressing objects:  80% (15406/19257)   
Compressing objects:  81% (15599/19257)   
Compressing objects:  82% (15791/19257)   
Compressing objects:  83% (15984/19257)   
Compressing objects:  84% (16176/19257)   
Compressing objects:  85% (16369/19257)   
Compressing objects:  86% (16562/19257)   
Compressing objects:  87% (16754/19257)   
Compressing objects:  88% (16947/19257)   
Compressing objects:  89% (17139/19257)   
Compressing objects:  90% (17332/19257)   
Compressing objects:  91% (17524/19257)   
Compressing objects:  92% (17717/19257)   
Compressing objects:  93% (17910/19257)   
Compressing objects:  94% (18102/19257)   
Compressing objects:  95% (18295/19257)   
Compressing objects:  96% (18487/19257)   
Compressing objects:  97% (18680/19257)   
Compressing objects:  98% (18872/19257)   
Compressing objects:  99% (19065/19257)   
Compressing objects: 100% (19257/19257)   
Compressing objects: 100% (19257/19257), done.
Writing objects:   0% (1/101021)   
Writing objects:   1% (1011/101021)   
Writing objects:   2% (2021/101021)   
Writing objects:   3% (3031/101021)   
Writing objects:   4% (4041/101021)   
Writing objects:   5% (5052/101021)   
Writing objects:   5% (5436/101021), 2.14 MiB | 1466 KiB/s   
Writing objects:   5% (5575/101021), 2.19 MiB | 1062 KiB/s   
Writing objects:   6% (6062/101021), 2.32 MiB | 894 KiB/s   
Writing objects:   7% (7072/101021), 2.32 MiB | 894 KiB/s   
Writing objects:   7% (7213/101021), 2.32 MiB | 894 KiB/s   
Writing objects:   8% (8082/101021), 3.08 MiB | 981 KiB/s   
Writing objects:   9% (9092/101021), 3.08 MiB | 981 KiB/s   
Writing objects:   9% (9555/101021), 3.46 MiB | 906 KiB/s   
Writing objects:  10% (10103/101021), 3.46 MiB | 906 KiB/s   
Writing objects:  10% (11008/101021), 3.84 MiB | 869 KiB/s   
Writing objects:  11% (11113/101021), 3.84 MiB | 869 KiB/s   
Writing objects:  12% (12123/101021), 4.21 MiB | 810 KiB/s   
Writing objects:  12% (12724/101021), 4.58 MiB | 784 KiB/s   
Writing objects:  13% (13133/101021), 4.58 MiB | 784 KiB/s   
Writing objects:  14% (14144/101021), 4.96 MiB | 500 KiB/s   
Writing objects:  14% (14256/101021), 5.21 MiB | 541 KiB/s   
Writing objects:  14% (14782/101021), 5.46 MiB | 558 KiB/s   
Writing objects:  15% (15155/101021), 5.46 MiB | 558 KiB/s   
Writing objects:  15% (15476/101021), 5.71 MiB | 558 KiB/s   
Writing objects:  15% (15903/101021), 5.96 MiB | 458 KiB/s   
Writing objects:  16% (16164/101021), 6.21 MiB | 441 KiB/s   
Writing objects:  16% (16865/101021), 6.58 MiB | 439 KiB/s   
Writing objects:  17% (17174/101021), 6.58 MiB | 439 KiB/s   
Writing objects:  17% (17838/101021), 6.96 MiB | 454 KiB/s   
Writing objects:  18% (18185/101021), 7.33 MiB | 451 KiB/s   
Writing objects:  18% (18916/101021), 7.71 MiB | 452 KiB/s   
Writing objects:  19% (19194/101021), 7.71 MiB | 452 KiB/s   
Writing objects:  20% (20205/101021), 8.08 MiB | 475 KiB/s   
Writing objects:  20% (20221/101021), 8.46 MiB | 511 KiB/s   
Writing objects:  20% (20991/101021), 8.83 MiB | 544 KiB/s   
Writing objects:  21% (21217/101021), 8.83 MiB | 544 KiB/s   
Writing objects:  21% (22219/101021), 9.46 MiB | 594 KiB/s   
Writing objects:  22% (22225/101021), 9.46 MiB | 594 KiB/s   
Writing objects:  23% (23235/101021), 9.83 MiB | 595 KiB/s   
Writing objects:  23% (23246/101021), 10.21 MiB | 589 KiB/s   
Writing objects:  24% (24248/101021), 10.58 MiB | 592 KiB/s   
Writing objects:  24% (24304/101021), 10.58 MiB | 592 KiB/s   
Writing objects:  25% (25256/101021), 10.96 MiB | 593 KiB/s   
Writing objects:  25% (25743/101021), 11.33 MiB | 594 KiB/s   
Writing objects:  26% (26266/101021), 11.33 MiB | 594 KiB/s   
Writing objects:  27% (27276/101021), 11.71 MiB | 595 KiB/s   
Writing objects:  27% (27624/101021), 11.96 MiB | 583 KiB/s   
Writing objects:  28% (28287/101021), 11.96 MiB | 583 KiB/s   
Writing objects:  28% (28747/101021), 12.33 MiB | 592 KiB/s   
Writing objects:  29% (29297/101021), 12.33 MiB | 592 KiB/s   
Writing objects:  30% (30307/101021), 12.71 MiB | 590 KiB/s   
Writing objects:  31% (31317/101021), 12.71 MiB | 590 KiB/s   
Writing objects:  31% (31543/101021), 12.96 MiB | 578 KiB/s   
Writing objects:  32% (32327/101021), 12.96 MiB | 578 KiB/s   
Writing objects:  33% (33337/101021), 12.96 MiB | 578 KiB/s   
Writing objects:  34% (34348/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  35% (35358/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  35% (35825/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  36% (36369/101021), 13.33 MiB | 578 KiB/s   
Writing objects:  37% (37378/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  38% (38388/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  39% (39399/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  40% (40409/101021), 13.71 MiB | 580 KiB/s   
Writing objects:  41% (41420/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  41% (41488/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  42% (42429/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  43% (43440/101021), 14.08 MiB | 580 KiB/s   
Writing objects:  44% (44450/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  45% (45460/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  45% (45852/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  46% (46470/101021), 14.46 MiB | 580 KiB/s   
Writing objects:  47% (47480/101021), 14.83 MiB | 574 KiB/s   
Writing objects:  48% (48492/101021), 14.83 MiB | 574 KiB/s   
Writing objects:  49% (49501/101021), 14.83 MiB | 574 KiB/s   
Writing objects:  50% (50511/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  50% (50758/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  51% (51521/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  52% (52531/101021), 15.21 MiB | 587 KiB/s   
Writing objects:  53% (53542/101021), 15.58 MiB | 583 KiB/s   
Writing objects:  54% (54552/101021), 15.58 MiB | 583 KiB/s   
Writing objects:  55% (55562/101021), 15.58 MiB | 583 KiB/s   
Writing objects:  55% (56373/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  56% (56572/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  57% (57582/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  58% (58594/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  59% (59603/101021), 15.96 MiB | 587 KiB/s   
Writing objects:  60% (60613/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  60% (61041/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  61% (61623/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  62% (62634/101021), 16.33 MiB | 593 KiB/s   
Writing objects:  63% (63644/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  64% (64654/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  65% (65664/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  66% (66674/101021), 16.71 MiB | 597 KiB/s   
Writing objects:  66% (66990/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  67% (67685/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  68% (68695/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  69% (69705/101021), 17.08 MiB | 601 KiB/s   
Writing objects:  70% (70715/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  71% (71726/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  72% (72736/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  72% (73271/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  73% (73746/101021), 17.46 MiB | 596 KiB/s   
Writing objects:  74% (74756/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  75% (75766/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  76% (76776/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  77% (77787/101021), 17.83 MiB | 596 KiB/s   
Writing objects:  77% (78471/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  78% (78799/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  79% (79808/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  80% (80817/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  81% (81828/101021), 18.21 MiB | 598 KiB/s   
Writing objects:  82% (82838/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  83% (83848/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  83% (84657/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  84% (84858/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  85% (85868/101021), 18.58 MiB | 597 KiB/s   
Writing objects:  86% (86879/101021), 18.96 MiB | 603 KiB/s   
Writing objects:  87% (87890/101021), 18.96 MiB | 603 KiB/s   
Writing objects:  88% (88899/101021), 18.96 MiB | 603 KiB/s   
Writing objects:  89% (89909/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  89% (90835/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  90% (90919/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  91% (91930/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  92% (92940/101021), 19.33 MiB | 598 KiB/s   
Writing objects:  93% (93950/101021), 19.71 MiB | 603 KiB/s   
Writing objects:  94% (94960/101021), 19.71 MiB | 603 KiB/s   
Writing objects:  95% (95971/101021), 19.71 MiB | 603 KiB/s   
Writing objects:  95% (96582/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  96% (96981/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  97% (97991/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  98% (99001/101021), 20.08 MiB | 596 KiB/s   
Writing objects:  99% (100011/101021), 20.08 MiB | 596 KiB/s   
Writing objects: 100% (101021/101021), 20.46 MiB | 593 KiB/s   
Writing objects: 100% (101021/101021), 20.51 MiB | 597 KiB/s, done.
Total 101021 (delta 84244), reused 96025 (delta 79512)
To xen@xenbits.xensource.com:git/linux-pvops.git
   c16fa4f..e63089b  e63089b08140adea85d011da136c7b56d73296ee -> tested/linux-mingo-tip-master
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 00:37:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 00:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHlYG-0007Oz-SN; Wed, 11 Apr 2012 00:36:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1SHlYF-0007Os-Kr
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 00:36:47 +0000
Received: from [193.109.254.147:58797] by server-6.bemta-14.messagelabs.com id
	C6/CD-02047-E12D48F4; Wed, 11 Apr 2012 00:36:46 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334104605!4031154!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYxMzU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3279 invoked from network); 11 Apr 2012 00:36:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-27.messagelabs.com with SMTP;
	11 Apr 2012 00:36:46 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 10 Apr 2012 17:36:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="129415888"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 10 Apr 2012 17:36:44 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 10 Apr 2012 17:36:44 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.125]) with mapi id
	14.01.0355.002; Wed, 11 Apr 2012 08:36:42 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Lin Ming
	<mlin@ss.pku.edu.cn>
Thread-Topic: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
	PHYSDEVOP_nr_irqs_gsi
Thread-Index: AQHNFzWDN1WMsJd+kU+UmSFUXuuye5aUx2/Q
Date: Wed, 11 Apr 2012 00:36:41 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, April 11, 2012 12:21 AM
> To: Lin Ming
> Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> PHYSDEVOP_nr_irqs_gsi
> 
> On Tue, 10 Apr 2012, Lin Ming wrote:
> > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > This new physdev_op is added for Linux guest kernel to get the
> > > > correct nr_irqs_gsi value.
> > >
> > > I'm not convinced this is really needed - the kernel can work out
> > > the right number without any hypercall afaict.
> >
> > In Linux kernel:
> >
> > mp_register_ioapic(...):
> >
> >         entries = io_apic_get_redir_entries(idx);
> >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> >         gsi_cfg->gsi_base = gsi_base;
> >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> >
> >         /*
> >          * The number of IO-APIC IRQ registers (== #pins):
> >          */
> >         ioapics[idx].nr_registers = entries;
> >
> >         if (gsi_cfg->gsi_end >= gsi_top)
> >                 gsi_top = gsi_cfg->gsi_end + 1;
> >
> > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > value(0xFFFFFFFF) on Xen Dom0 kernel.
> >
> > How can we get the correct gsi_top value, which is used to set
> > nr_irqs_gsi, without hypercall?
> >
> > The problem here is we don't have a Xen version of io_apic_read in
> > Linux kernel.
> 
> Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519

This is not enough, seems fixed value are returned for each read ?
Xiantao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 00:37:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 00:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHlYG-0007Oz-SN; Wed, 11 Apr 2012 00:36:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1SHlYF-0007Os-Kr
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 00:36:47 +0000
Received: from [193.109.254.147:58797] by server-6.bemta-14.messagelabs.com id
	C6/CD-02047-E12D48F4; Wed, 11 Apr 2012 00:36:46 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334104605!4031154!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYxMzU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3279 invoked from network); 11 Apr 2012 00:36:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-27.messagelabs.com with SMTP;
	11 Apr 2012 00:36:46 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 10 Apr 2012 17:36:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="129415888"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 10 Apr 2012 17:36:44 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 10 Apr 2012 17:36:44 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.125]) with mapi id
	14.01.0355.002; Wed, 11 Apr 2012 08:36:42 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Lin Ming
	<mlin@ss.pku.edu.cn>
Thread-Topic: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
	PHYSDEVOP_nr_irqs_gsi
Thread-Index: AQHNFzWDN1WMsJd+kU+UmSFUXuuye5aUx2/Q
Date: Wed, 11 Apr 2012 00:36:41 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, April 11, 2012 12:21 AM
> To: Lin Ming
> Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> PHYSDEVOP_nr_irqs_gsi
> 
> On Tue, 10 Apr 2012, Lin Ming wrote:
> > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > This new physdev_op is added for Linux guest kernel to get the
> > > > correct nr_irqs_gsi value.
> > >
> > > I'm not convinced this is really needed - the kernel can work out
> > > the right number without any hypercall afaict.
> >
> > In Linux kernel:
> >
> > mp_register_ioapic(...):
> >
> >         entries = io_apic_get_redir_entries(idx);
> >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> >         gsi_cfg->gsi_base = gsi_base;
> >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> >
> >         /*
> >          * The number of IO-APIC IRQ registers (== #pins):
> >          */
> >         ioapics[idx].nr_registers = entries;
> >
> >         if (gsi_cfg->gsi_end >= gsi_top)
> >                 gsi_top = gsi_cfg->gsi_end + 1;
> >
> > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > value(0xFFFFFFFF) on Xen Dom0 kernel.
> >
> > How can we get the correct gsi_top value, which is used to set
> > nr_irqs_gsi, without hypercall?
> >
> > The problem here is we don't have a Xen version of io_apic_read in
> > Linux kernel.
> 
> Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519

This is not enough, seems fixed value are returned for each read ?
Xiantao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 01:34:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 01:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHmRh-0003bc-Tw; Wed, 11 Apr 2012 01:34:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SHmRg-0003bX-0v
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 01:34:04 +0000
Received: from [85.158.139.83:8528] by server-12.bemta-5.messagelabs.com id
	F3/A3-05587-B8FD48F4; Wed, 11 Apr 2012 01:34:03 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334108041!15896352!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI0MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 11 Apr 2012 01:34:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	11 Apr 2012 01:34:02 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3B1XVM7008069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Apr 2012 21:33:31 -0400
Received: from amt.cnet (vpn-11-107.rdu.redhat.com [10.11.11.107])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3B1XTNO027064; Tue, 10 Apr 2012 21:33:29 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 65D0365202B;
	Tue, 10 Apr 2012 22:29:49 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3B1Td5i014989;
	Tue, 10 Apr 2012 22:29:39 -0300
Date: Tue, 10 Apr 2012 22:29:38 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120411012938.GC7245@amt.cnet>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 12:07:58AM +0200, Thomas Gleixner wrote:
> On Fri, 30 Mar 2012, H. Peter Anvin wrote:
> 
> > What is the current status of this patchset?  I haven't looked at it too
> > closely because I have been focused on 3.4 up until now...
> 
> The real question is whether these heuristics are the correct approach
> or not.
> 
> If I look at it from the non virtualized kernel side then this is ass
> backwards. We know already that we are holding a spinlock which might
> cause other (v)cpus going into eternal spin. The non virtualized
> kernel solves this by disabling preemption and therefor getting out of
> the critical section as fast as possible,
> 
> The virtualization problem reminds me a lot of the problem which RT
> kernels are observing where non raw spinlocks are turned into
> "sleeping spinlocks" and therefor can cause throughput issues for non
> RT workloads.
> 
> Though the virtualized situation is even worse. Any preempted guest
> section which holds a spinlock is prone to cause unbound delays.
> 
> The paravirt ticketlock solution can only mitigate the problem, but
> not solve it. With massive overcommit there is always a way to trigger
> worst case scenarious unless you are educating the scheduler to cope
> with that.
> 
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.
> 
> I know that Peter is going to go berserk on me, but if we are running
> a paravirt guest then it's simple to provide a mechanism which allows
> the host (aka hypervisor) to check that in the guest just by looking
> at some global state.
> 
> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be
> modified to indicate the guest to invoke an exit when the last nested
> lock has been released.

Remember that the host is scheduling other processes than vcpus of guests. 

The case where a higher priority task (whatever that task is) interrupts
a vcpu which holds a spinlock should be frequent, in a overcommit
scenario. Whenever that is the case, other vcpus _must_ be able to stop
spinning. 

Now extrapolate that to guests with large number of vcpus. There is no
replacement for sleep-in-hypervisor-instead-of-spin.

> Of course this needs to be time bound, so a rogue guest cannot
> monopolize the cpu forever, but that's the least to worry about
> problem simply because a guest which does not get out of a spinlocked
> region within a certain amount of time is borked and elegible to
> killing anyway.
> 
> Thoughts ?
> 
> Thanks,
> 
> 	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 01:34:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 01:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHmRh-0003bc-Tw; Wed, 11 Apr 2012 01:34:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SHmRg-0003bX-0v
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 01:34:04 +0000
Received: from [85.158.139.83:8528] by server-12.bemta-5.messagelabs.com id
	F3/A3-05587-B8FD48F4; Wed, 11 Apr 2012 01:34:03 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334108041!15896352!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI0MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 11 Apr 2012 01:34:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	11 Apr 2012 01:34:02 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3B1XVM7008069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Apr 2012 21:33:31 -0400
Received: from amt.cnet (vpn-11-107.rdu.redhat.com [10.11.11.107])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3B1XTNO027064; Tue, 10 Apr 2012 21:33:29 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 65D0365202B;
	Tue, 10 Apr 2012 22:29:49 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3B1Td5i014989;
	Tue, 10 Apr 2012 22:29:39 -0300
Date: Tue, 10 Apr 2012 22:29:38 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120411012938.GC7245@amt.cnet>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1203302333560.2542@ionos>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 12:07:58AM +0200, Thomas Gleixner wrote:
> On Fri, 30 Mar 2012, H. Peter Anvin wrote:
> 
> > What is the current status of this patchset?  I haven't looked at it too
> > closely because I have been focused on 3.4 up until now...
> 
> The real question is whether these heuristics are the correct approach
> or not.
> 
> If I look at it from the non virtualized kernel side then this is ass
> backwards. We know already that we are holding a spinlock which might
> cause other (v)cpus going into eternal spin. The non virtualized
> kernel solves this by disabling preemption and therefor getting out of
> the critical section as fast as possible,
> 
> The virtualization problem reminds me a lot of the problem which RT
> kernels are observing where non raw spinlocks are turned into
> "sleeping spinlocks" and therefor can cause throughput issues for non
> RT workloads.
> 
> Though the virtualized situation is even worse. Any preempted guest
> section which holds a spinlock is prone to cause unbound delays.
> 
> The paravirt ticketlock solution can only mitigate the problem, but
> not solve it. With massive overcommit there is always a way to trigger
> worst case scenarious unless you are educating the scheduler to cope
> with that.
> 
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing around.
> 
> I know that Peter is going to go berserk on me, but if we are running
> a paravirt guest then it's simple to provide a mechanism which allows
> the host (aka hypervisor) to check that in the guest just by looking
> at some global state.
> 
> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be
> modified to indicate the guest to invoke an exit when the last nested
> lock has been released.

Remember that the host is scheduling other processes than vcpus of guests. 

The case where a higher priority task (whatever that task is) interrupts
a vcpu which holds a spinlock should be frequent, in a overcommit
scenario. Whenever that is the case, other vcpus _must_ be able to stop
spinning. 

Now extrapolate that to guests with large number of vcpus. There is no
replacement for sleep-in-hypervisor-instead-of-spin.

> Of course this needs to be time bound, so a rogue guest cannot
> monopolize the cpu forever, but that's the least to worry about
> problem simply because a guest which does not get out of a spinlocked
> region within a certain amount of time is borked and elegible to
> killing anyway.
> 
> Thoughts ?
> 
> Thanks,
> 
> 	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 01:38:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 01:38:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHmVO-0003t9-PL; Wed, 11 Apr 2012 01:37:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHmVO-0003t0-8D
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 01:37:54 +0000
Received: from [193.109.254.147:30939] by server-9.bemta-14.messagelabs.com id
	03/11-05787-170E48F4; Wed, 11 Apr 2012 01:37:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334108272!1549210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3488 invoked from network); 11 Apr 2012 01:37:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 01:37:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208";a="11866947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 01:37:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 02:37:52 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHmVM-0004zD-2F;
	Wed, 11 Apr 2012 01:37:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHmVG-000131-Ah;
	Wed, 11 Apr 2012 02:37:51 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12634-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 02:37:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12634: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12634 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12634/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2    fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 01:38:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 01:38:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHmVO-0003t9-PL; Wed, 11 Apr 2012 01:37:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHmVO-0003t0-8D
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 01:37:54 +0000
Received: from [193.109.254.147:30939] by server-9.bemta-14.messagelabs.com id
	03/11-05787-170E48F4; Wed, 11 Apr 2012 01:37:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334108272!1549210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3488 invoked from network); 11 Apr 2012 01:37:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 01:37:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208";a="11866947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 01:37:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 02:37:52 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHmVM-0004zD-2F;
	Wed, 11 Apr 2012 01:37:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHmVG-000131-Ah;
	Wed, 11 Apr 2012 02:37:51 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12634-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 02:37:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12634: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12634 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12634/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11890

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2    fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 07:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 07:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsF4-0000O3-Qh; Wed, 11 Apr 2012 07:45:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHsF2-0000Ny-Hf
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 07:45:24 +0000
Received: from [85.158.139.83:6180] by server-3.bemta-5.messagelabs.com id
	51/01-25237-396358F4; Wed, 11 Apr 2012 07:45:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334130322!19013595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19895 invoked from network); 11 Apr 2012 07:45:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 07:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11869714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 07:45:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 08:45:21 +0100
Message-ID: <1334130319.12209.187.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 11 Apr 2012 07:45:19 +0000
In-Reply-To: <1334088690.2624.1.camel@bwh-desktop.uk.solarflarecom.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
	<1334088690.2624.1.camel@bwh-desktop.uk.solarflarecom.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"Pekka Savola \(ipv6\)" <pekkas@netcore.fi>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>, Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>, James
	Morris <jmorris@namei.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Patrick McHardy <kaber@trash.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	=?UTF-8?Q?Micha=C5=82_Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 07/10] net: only allow paged fragments with
 the same destructor to be coalesced.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 21:11 +0100, Ben Hutchings wrote:
> Shouldn't this be folded into the previous change 'net: add support for
> per-paged-fragment destructors'?  Maybe it doesn't matter since nothing
> is setting a non-NULL fragment destructor yet.

I keep following exactly the same thought pattern and then ending up
leaving it due to indecision. I'll squash it next time unless anyone
thinks it is worth keeping split out.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 07:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 07:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsF4-0000O3-Qh; Wed, 11 Apr 2012 07:45:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHsF2-0000Ny-Hf
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 07:45:24 +0000
Received: from [85.158.139.83:6180] by server-3.bemta-5.messagelabs.com id
	51/01-25237-396358F4; Wed, 11 Apr 2012 07:45:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334130322!19013595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19895 invoked from network); 11 Apr 2012 07:45:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 07:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11869714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 07:45:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 08:45:21 +0100
Message-ID: <1334130319.12209.187.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 11 Apr 2012 07:45:19 +0000
In-Reply-To: <1334088690.2624.1.camel@bwh-desktop.uk.solarflarecom.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
	<1334088690.2624.1.camel@bwh-desktop.uk.solarflarecom.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"Pekka Savola \(ipv6\)" <pekkas@netcore.fi>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>, Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>, James
	Morris <jmorris@namei.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Patrick McHardy <kaber@trash.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	=?UTF-8?Q?Micha=C5=82_Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 07/10] net: only allow paged fragments with
 the same destructor to be coalesced.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 21:11 +0100, Ben Hutchings wrote:
> Shouldn't this be folded into the previous change 'net: add support for
> per-paged-fragment destructors'?  Maybe it doesn't matter since nothing
> is setting a non-NULL fragment destructor yet.

I keep following exactly the same thought pattern and then ending up
leaving it due to indecision. I'll squash it next time unless anyone
thinks it is worth keeping split out.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 07:53:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 07:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsLq-0000WW-Mi; Wed, 11 Apr 2012 07:52:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHsLp-0000WP-5x
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 07:52:25 +0000
Received: from [85.158.138.51:20214] by server-11.bemta-3.messagelabs.com id
	2B/E9-18894-838358F4; Wed, 11 Apr 2012 07:52:24 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334130740!21590900!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5443 invoked from network); 11 Apr 2012 07:52:22 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 07:52:22 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHsLj-0000Tx-Jg
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 00:52:19 -0700
Date: Wed, 11 Apr 2012 00:52:19 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334130739587-5632069.post@n5.nabble.com>
In-Reply-To: <osstest-12634-mainreport@xen.org>
References: <osstest-12634-mainreport@xen.org>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [qemu-upstream-unstable test] 12634: regressions -
	FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I had tested with latest xen-unstable (changeset 25161:d690c7e896a2) and qemu
upstream unstable windows xp and windows 7 work with xl, the issue found
that there is still no solution are:
- qxl vga and/or videoram over 4 mb
- reboot the domU not working (after shutdown seem destroy it)
- graphic performance issue: with vnc and cirrus very high latency of
refresh, with stdvga usable but performance is not good, with spice and
stdvga not enough but better, with qxl limited by only 4 mb videoram usable
Save/restore not tested for now, probably I will try it today.

--
View this message in context: http://xen.1045712.n5.nabble.com/qemu-upstream-unstable-test-12634-regressions-FAIL-tp5631581p5632069.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 07:53:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 07:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsLq-0000WW-Mi; Wed, 11 Apr 2012 07:52:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHsLp-0000WP-5x
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 07:52:25 +0000
Received: from [85.158.138.51:20214] by server-11.bemta-3.messagelabs.com id
	2B/E9-18894-838358F4; Wed, 11 Apr 2012 07:52:24 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334130740!21590900!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5443 invoked from network); 11 Apr 2012 07:52:22 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 07:52:22 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHsLj-0000Tx-Jg
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 00:52:19 -0700
Date: Wed, 11 Apr 2012 00:52:19 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334130739587-5632069.post@n5.nabble.com>
In-Reply-To: <osstest-12634-mainreport@xen.org>
References: <osstest-12634-mainreport@xen.org>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [qemu-upstream-unstable test] 12634: regressions -
	FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I had tested with latest xen-unstable (changeset 25161:d690c7e896a2) and qemu
upstream unstable windows xp and windows 7 work with xl, the issue found
that there is still no solution are:
- qxl vga and/or videoram over 4 mb
- reboot the domU not working (after shutdown seem destroy it)
- graphic performance issue: with vnc and cirrus very high latency of
refresh, with stdvga usable but performance is not good, with spice and
stdvga not enough but better, with qxl limited by only 4 mb videoram usable
Save/restore not tested for now, probably I will try it today.

--
View this message in context: http://xen.1045712.n5.nabble.com/qemu-upstream-unstable-test-12634-regressions-FAIL-tp5631581p5632069.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 07:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 07:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsPk-0000dL-Be; Wed, 11 Apr 2012 07:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHsPi-0000dG-Ny
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 07:56:26 +0000
Received: from [85.158.143.99:6217] by server-2.bemta-4.messagelabs.com id
	C7/33-17550-A29358F4; Wed, 11 Apr 2012 07:56:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334130985!23122086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20348 invoked from network); 11 Apr 2012 07:56:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 07:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11869929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 07:56:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 08:56:25 +0100
Message-ID: <1334130984.12209.195.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 11 Apr 2012 07:56:24 +0000
In-Reply-To: <4F847CF9.3090701@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 19:33 +0100, Alexander Duyck wrote:
> On 04/10/2012 07:26 AM, Ian Campbell wrote:
> > As of the previous patch we align the end (rather than the start) of the struct
> > to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> > increase from the next patch, the first 8 bytes of the struct end up on a
> > different cache line to the rest of it so make sure it is something relatively
> > unimportant to avoid hitting an extra cache line on hot operations such as
> > kfree_skb.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> >  include/linux/skbuff.h |   15 ++++++++++-----
> >  net/core/skbuff.c      |    5 ++++-
> >  2 files changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 0ad6a46..f0ae39c 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -265,6 +265,15 @@ struct ubuf_info {
> >   * the end of the header data, ie. at skb->end.
> >   */
> >  struct skb_shared_info {
> > +	/* Intermediate layers must ensure that destructor_arg
> > +	 * remains valid until skb destructor */
> > +	void		*destructor_arg;
> > +
> > +	/*
> > +	 * Warning: all fields from here until dataref are cleared in
> > +	 * __alloc_skb()
> > +	 *
> > +	 */
> >  	unsigned char	nr_frags;
> >  	__u8		tx_flags;
> >  	unsigned short	gso_size;
> > @@ -276,14 +285,10 @@ struct skb_shared_info {
> >  	__be32          ip6_frag_id;
> >  
> >  	/*
> > -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> > +	 * Warning: all fields before dataref are cleared in __alloc_skb()
> >  	 */
> >  	atomic_t	dataref;
> >  
> > -	/* Intermediate layers must ensure that destructor_arg
> > -	 * remains valid until skb destructor */
> > -	void *		destructor_arg;
> > -
> >  	/* must be last field, see pskb_expand_head() */
> >  	skb_frag_t	frags[MAX_SKB_FRAGS];
> >  };
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index d4e139e..b8a41d6 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> >  
> >  	/* make sure we initialize shinfo sequentially */
> >  	shinfo = skb_shinfo(skb);
> > -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> > +
> > +	memset(&shinfo->nr_frags, 0,
> > +	       offsetof(struct skb_shared_info, dataref)
> > +	       - offsetof(struct skb_shared_info, nr_frags));
> >  	atomic_set(&shinfo->dataref, 1);
> >  	kmemcheck_annotate_variable(shinfo->destructor_arg);
> >  
> 
> Have you checked this for 32 bit as well as 64?  Based on my math your
> next patch will still mess up the memset on 32 bit with the structure
> being split somewhere just in front of hwtstamps.

You mean 32 byte cache lines? If so then yes there is a split half way
through the structure in that case but there's no way all this data
could ever fit in a single 32 byte cache line. Not including the frags
or destructor_arg the region nr_frags up to and including dataref is 36
bytes on 32 bit and 40 bytes on 64 bit. I've not changed anything in
this respect.

If you meant 64 byte cache lines with 32 bit structure sizes then by my
calculations everything from destructor_arg (in fact a bit earlier, from
12 bytes before then) up to and including frag[0] is in the same 64 byte
cache line.

I find the easiest way to check is to use gdb and open code an offsetof
macro.

(gdb) print/d sizeof(struct skb_shared_info) - (unsigned long)&(((struct skb_shared_info *)0)->nr_frags)
$3 = 240
(gdb) print/d sizeof(struct skb_shared_info) - (unsigned long)&(((struct skb_shared_info *)0)->frags[1])
$4 = 192

So given 64 byte cache lines the interesting area starts at 240/64=3.75
cache lines from the (aligned) end and it finishes just before 192/64=3
cache lines from the end, so nr_frags through to frags[0] are therefore
on the same cache line.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 07:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 07:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsPk-0000dL-Be; Wed, 11 Apr 2012 07:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHsPi-0000dG-Ny
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 07:56:26 +0000
Received: from [85.158.143.99:6217] by server-2.bemta-4.messagelabs.com id
	C7/33-17550-A29358F4; Wed, 11 Apr 2012 07:56:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334130985!23122086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20348 invoked from network); 11 Apr 2012 07:56:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 07:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11869929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 07:56:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 08:56:25 +0100
Message-ID: <1334130984.12209.195.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 11 Apr 2012 07:56:24 +0000
In-Reply-To: <4F847CF9.3090701@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 19:33 +0100, Alexander Duyck wrote:
> On 04/10/2012 07:26 AM, Ian Campbell wrote:
> > As of the previous patch we align the end (rather than the start) of the struct
> > to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> > increase from the next patch, the first 8 bytes of the struct end up on a
> > different cache line to the rest of it so make sure it is something relatively
> > unimportant to avoid hitting an extra cache line on hot operations such as
> > kfree_skb.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> >  include/linux/skbuff.h |   15 ++++++++++-----
> >  net/core/skbuff.c      |    5 ++++-
> >  2 files changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 0ad6a46..f0ae39c 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -265,6 +265,15 @@ struct ubuf_info {
> >   * the end of the header data, ie. at skb->end.
> >   */
> >  struct skb_shared_info {
> > +	/* Intermediate layers must ensure that destructor_arg
> > +	 * remains valid until skb destructor */
> > +	void		*destructor_arg;
> > +
> > +	/*
> > +	 * Warning: all fields from here until dataref are cleared in
> > +	 * __alloc_skb()
> > +	 *
> > +	 */
> >  	unsigned char	nr_frags;
> >  	__u8		tx_flags;
> >  	unsigned short	gso_size;
> > @@ -276,14 +285,10 @@ struct skb_shared_info {
> >  	__be32          ip6_frag_id;
> >  
> >  	/*
> > -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> > +	 * Warning: all fields before dataref are cleared in __alloc_skb()
> >  	 */
> >  	atomic_t	dataref;
> >  
> > -	/* Intermediate layers must ensure that destructor_arg
> > -	 * remains valid until skb destructor */
> > -	void *		destructor_arg;
> > -
> >  	/* must be last field, see pskb_expand_head() */
> >  	skb_frag_t	frags[MAX_SKB_FRAGS];
> >  };
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index d4e139e..b8a41d6 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> >  
> >  	/* make sure we initialize shinfo sequentially */
> >  	shinfo = skb_shinfo(skb);
> > -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> > +
> > +	memset(&shinfo->nr_frags, 0,
> > +	       offsetof(struct skb_shared_info, dataref)
> > +	       - offsetof(struct skb_shared_info, nr_frags));
> >  	atomic_set(&shinfo->dataref, 1);
> >  	kmemcheck_annotate_variable(shinfo->destructor_arg);
> >  
> 
> Have you checked this for 32 bit as well as 64?  Based on my math your
> next patch will still mess up the memset on 32 bit with the structure
> being split somewhere just in front of hwtstamps.

You mean 32 byte cache lines? If so then yes there is a split half way
through the structure in that case but there's no way all this data
could ever fit in a single 32 byte cache line. Not including the frags
or destructor_arg the region nr_frags up to and including dataref is 36
bytes on 32 bit and 40 bytes on 64 bit. I've not changed anything in
this respect.

If you meant 64 byte cache lines with 32 bit structure sizes then by my
calculations everything from destructor_arg (in fact a bit earlier, from
12 bytes before then) up to and including frag[0] is in the same 64 byte
cache line.

I find the easiest way to check is to use gdb and open code an offsetof
macro.

(gdb) print/d sizeof(struct skb_shared_info) - (unsigned long)&(((struct skb_shared_info *)0)->nr_frags)
$3 = 240
(gdb) print/d sizeof(struct skb_shared_info) - (unsigned long)&(((struct skb_shared_info *)0)->frags[1])
$4 = 192

So given 64 byte cache lines the interesting area starts at 240/64=3.75
cache lines from the (aligned) end and it finishes just before 192/64=3
cache lines from the end, so nr_frags through to frags[0] are therefore
on the same cache line.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:01:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsUB-0001Gy-74; Wed, 11 Apr 2012 08:01:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHsU9-0001Gr-A9
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:01:01 +0000
Received: from [85.158.139.83:56012] by server-11.bemta-5.messagelabs.com id
	1C/A1-12959-C3A358F4; Wed, 11 Apr 2012 08:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334131259!23198884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1929 invoked from network); 11 Apr 2012 08:00:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:00:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11870027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:00:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:00:42 +0100
Message-ID: <1334131241.12209.199.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 11 Apr 2012 08:00:41 +0000
In-Reply-To: <4F8486E7.5050604@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:15 +0100, Alexander Duyck wrote:
> On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> > On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
> >
> >> Have you checked this for 32 bit as well as 64?  Based on my math your
> >> next patch will still mess up the memset on 32 bit with the structure
> >> being split somewhere just in front of hwtstamps.
> >>
> >> Why not just take frags and move it to the start of the structure?  It
> >> is already an unknown value because it can be either 16 or 17 depending
> >> on the value of PAGE_SIZE, and since you are making changes to frags the
> >> changes wouldn't impact the alignment of the other values later on since
> >> you are aligning the end of the structure.  That way you would be
> >> guaranteed that all of the fields that will be memset would be in the
> >> last 64 bytes.
> >>
> > Now when a fragmented packet is copied in pskb_expand_head(), you access
> > two separate zones of memory to copy the shinfo. But its supposed to be
> > slow path.
> >
> > Problem with this is that the offsets of often used fields will be big
> > (instead of being < 127) and code will be bigger on x86.
> 
> Actually now that I think about it my concerns go much further than the
> memset.  I'm convinced that this is going to cause a pretty significant
> performance regression on multiple drivers, especially on non x86_64
> architecture.  What we have right now on most platforms is a
> skb_shared_info structure in which everything up to and including frag 0
> is all in one cache line.  This gives us pretty good performance for igb
> and ixgbe since that is our common case when jumbo frames are not
> enabled is to split the head and place the data in a page.

With all the changes in this series it is still possible to fit a
maximum standard MTU frame and the shinfo on the same 4K page while also
have the skb_shared_info up to and including frag [0] aligned to the
same 64 byte cache line. 

The only exception is destructor_arg on 64 bit which is on the preceding
cache line but that is not a field used in any hot path.

> However the change being recommend here only resolves the issue for one
> specific architecture, and that is what I don't agree with.  What we
> need is a solution that also works for 64K pages or 32 bit pointers and
> I am fairly certain this current solution does not.

I think it does work for 32 bit pointers. What issue to do you see with
64K pages?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:01:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsUB-0001Gy-74; Wed, 11 Apr 2012 08:01:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHsU9-0001Gr-A9
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:01:01 +0000
Received: from [85.158.139.83:56012] by server-11.bemta-5.messagelabs.com id
	1C/A1-12959-C3A358F4; Wed, 11 Apr 2012 08:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334131259!23198884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1929 invoked from network); 11 Apr 2012 08:00:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:00:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11870027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:00:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:00:42 +0100
Message-ID: <1334131241.12209.199.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 11 Apr 2012 08:00:41 +0000
In-Reply-To: <4F8486E7.5050604@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:15 +0100, Alexander Duyck wrote:
> On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> > On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
> >
> >> Have you checked this for 32 bit as well as 64?  Based on my math your
> >> next patch will still mess up the memset on 32 bit with the structure
> >> being split somewhere just in front of hwtstamps.
> >>
> >> Why not just take frags and move it to the start of the structure?  It
> >> is already an unknown value because it can be either 16 or 17 depending
> >> on the value of PAGE_SIZE, and since you are making changes to frags the
> >> changes wouldn't impact the alignment of the other values later on since
> >> you are aligning the end of the structure.  That way you would be
> >> guaranteed that all of the fields that will be memset would be in the
> >> last 64 bytes.
> >>
> > Now when a fragmented packet is copied in pskb_expand_head(), you access
> > two separate zones of memory to copy the shinfo. But its supposed to be
> > slow path.
> >
> > Problem with this is that the offsets of often used fields will be big
> > (instead of being < 127) and code will be bigger on x86.
> 
> Actually now that I think about it my concerns go much further than the
> memset.  I'm convinced that this is going to cause a pretty significant
> performance regression on multiple drivers, especially on non x86_64
> architecture.  What we have right now on most platforms is a
> skb_shared_info structure in which everything up to and including frag 0
> is all in one cache line.  This gives us pretty good performance for igb
> and ixgbe since that is our common case when jumbo frames are not
> enabled is to split the head and place the data in a page.

With all the changes in this series it is still possible to fit a
maximum standard MTU frame and the shinfo on the same 4K page while also
have the skb_shared_info up to and including frag [0] aligned to the
same 64 byte cache line. 

The only exception is destructor_arg on 64 bit which is on the preceding
cache line but that is not a field used in any hot path.

> However the change being recommend here only resolves the issue for one
> specific architecture, and that is what I don't agree with.  What we
> need is a solution that also works for 64K pages or 32 bit pointers and
> I am fairly certain this current solution does not.

I think it does work for 32 bit pointers. What issue to do you see with
64K pages?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:21:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsn9-0001c8-0O; Wed, 11 Apr 2012 08:20:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHsn6-0001c3-TE
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:20:37 +0000
Received: from [193.109.254.147:23906] by server-7.bemta-14.messagelabs.com id
	F6/EF-01627-4DE358F4; Wed, 11 Apr 2012 08:20:36 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334132432!1591693!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2036 invoked from network); 11 Apr 2012 08:20:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:20:33 -0000
Received: by bkcjg9 with SMTP id jg9so547064bkc.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 01:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=g40gyn1tf9U3tSiHIvWiHPCusxc+jTOjAis566+SXPA=;
	b=eeynuY2LFCuvvn0QosZJcxAU6DyAdSgdeBfBbc2JaJr51+/qzFw+zvX1EcpIeLCMH4
	H1Ur6T5RbFckzcp5R40Tj0rB8NCrtZHqfcgHqSEpr/Dl4YnJxNljIbgDE9uZ3K5iiUs5
	2fuSSTwT0LH6t6WDlpEqzXruCwzfSP0y5Muw+h2Ic6S48G0LAne/fDK4yVaTPvHd93PR
	AvRiLTuSARDv65UCucYHBjO+UY0h6yE4tSZQwOpGYar7cUXGU0ooLFxPZBVz1chyTMtg
	t5WytPN+h7fqb3/KqTuzv6ao13OWviOsJ4j0lQC2ZcXDW8K1K02EnShZ8epxycjFHvZo
	uEvA==
Received: by 10.205.130.12 with SMTP id hk12mr5907800bkc.76.1334132432704;
	Wed, 11 Apr 2012 01:20:32 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id iv11sm3051579bkc.16.2012.04.11.01.20.29
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 01:20:31 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
In-Reply-To: <4F8486E7.5050604@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
Date: Wed, 11 Apr 2012 10:20:28 +0200
Message-ID: <1334132428.5300.2685.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 12:15 -0700, Alexander Duyck wrote:

> 
> Actually now that I think about it my concerns go much further than the
> memset.  I'm convinced that this is going to cause a pretty significant
> performance regression on multiple drivers, especially on non x86_64
> architecture.  What we have right now on most platforms is a
> skb_shared_info structure in which everything up to and including frag 0
> is all in one cache line.  This gives us pretty good performance for igb
> and ixgbe since that is our common case when jumbo frames are not
> enabled is to split the head and place the data in a page.

I dont understand this split thing for MTU=1500 frames.

Even using half a page per fragment, each skb :

needs 2 allocations for sk_buff and skb->head, plus one page alloc /
reference.

skb->truesize = ksize(skb->head) + sizeof(*skb) + PAGE_SIZE/2 = 512 +
256 + 2048 = 2816 bytes


With non split you have :

2 allocations for sk_buff and skb->head.

skb->truesize = ksize(skb->head) + sizeof(*skb) = 2048 + 256 = 2304
bytes

less overhead and less calls to page allocator...

This only can benefit if GRO is on, since aggregation can use fragments
and a single sk_buff, instead of a frag_list




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:21:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHsn9-0001c8-0O; Wed, 11 Apr 2012 08:20:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1SHsn6-0001c3-TE
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:20:37 +0000
Received: from [193.109.254.147:23906] by server-7.bemta-14.messagelabs.com id
	F6/EF-01627-4DE358F4; Wed, 11 Apr 2012 08:20:36 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334132432!1591693!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2036 invoked from network); 11 Apr 2012 08:20:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:20:33 -0000
Received: by bkcjg9 with SMTP id jg9so547064bkc.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 01:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=g40gyn1tf9U3tSiHIvWiHPCusxc+jTOjAis566+SXPA=;
	b=eeynuY2LFCuvvn0QosZJcxAU6DyAdSgdeBfBbc2JaJr51+/qzFw+zvX1EcpIeLCMH4
	H1Ur6T5RbFckzcp5R40Tj0rB8NCrtZHqfcgHqSEpr/Dl4YnJxNljIbgDE9uZ3K5iiUs5
	2fuSSTwT0LH6t6WDlpEqzXruCwzfSP0y5Muw+h2Ic6S48G0LAne/fDK4yVaTPvHd93PR
	AvRiLTuSARDv65UCucYHBjO+UY0h6yE4tSZQwOpGYar7cUXGU0ooLFxPZBVz1chyTMtg
	t5WytPN+h7fqb3/KqTuzv6ao13OWviOsJ4j0lQC2ZcXDW8K1K02EnShZ8epxycjFHvZo
	uEvA==
Received: by 10.205.130.12 with SMTP id hk12mr5907800bkc.76.1334132432704;
	Wed, 11 Apr 2012 01:20:32 -0700 (PDT)
Received: from [172.28.94.133] ([74.125.122.49])
	by mx.google.com with ESMTPS id iv11sm3051579bkc.16.2012.04.11.01.20.29
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 01:20:31 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
In-Reply-To: <4F8486E7.5050604@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
Date: Wed, 11 Apr 2012 10:20:28 +0200
Message-ID: <1334132428.5300.2685.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 12:15 -0700, Alexander Duyck wrote:

> 
> Actually now that I think about it my concerns go much further than the
> memset.  I'm convinced that this is going to cause a pretty significant
> performance regression on multiple drivers, especially on non x86_64
> architecture.  What we have right now on most platforms is a
> skb_shared_info structure in which everything up to and including frag 0
> is all in one cache line.  This gives us pretty good performance for igb
> and ixgbe since that is our common case when jumbo frames are not
> enabled is to split the head and place the data in a page.

I dont understand this split thing for MTU=1500 frames.

Even using half a page per fragment, each skb :

needs 2 allocations for sk_buff and skb->head, plus one page alloc /
reference.

skb->truesize = ksize(skb->head) + sizeof(*skb) + PAGE_SIZE/2 = 512 +
256 + 2048 = 2816 bytes


With non split you have :

2 allocations for sk_buff and skb->head.

skb->truesize = ksize(skb->head) + sizeof(*skb) = 2048 + 256 = 2304
bytes

less overhead and less calls to page allocator...

This only can benefit if GRO is on, since aggregation can use fragments
and a single sk_buff, instead of a frag_list




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:36:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHt23-0001mH-Nk; Wed, 11 Apr 2012 08:36:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHt22-0001mC-0r
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 08:36:02 +0000
Received: from [85.158.143.35:44597] by server-2.bemta-4.messagelabs.com id
	9F/AE-17550-172458F4; Wed, 11 Apr 2012 08:36:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334133359!11888481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29240 invoked from network); 11 Apr 2012 08:36:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:36:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:35:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 09:35:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHt1v-0008QX-Bz;
	Wed, 11 Apr 2012 08:35:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHt1v-00063y-8f;
	Wed, 11 Apr 2012 09:35:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12635-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 09:35:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12635: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12635 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12635/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 12627

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12627

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass

version targeted for testing:
 xen                  5bbda657a016
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:36:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHt23-0001mH-Nk; Wed, 11 Apr 2012 08:36:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHt22-0001mC-0r
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 08:36:02 +0000
Received: from [85.158.143.35:44597] by server-2.bemta-4.messagelabs.com id
	9F/AE-17550-172458F4; Wed, 11 Apr 2012 08:36:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334133359!11888481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29240 invoked from network); 11 Apr 2012 08:36:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:36:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:35:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 09:35:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHt1v-0008QX-Bz;
	Wed, 11 Apr 2012 08:35:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHt1v-00063y-8f;
	Wed, 11 Apr 2012 09:35:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12635-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 09:35:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12635: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12635 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12635/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 12627

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12627

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass

version targeted for testing:
 xen                  5bbda657a016
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:38:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHt3f-0001q6-6o; Wed, 11 Apr 2012 08:37:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHt3d-0001pv-3E
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 08:37:41 +0000
Received: from [85.158.143.35:17861] by server-1.bemta-4.messagelabs.com id
	7D/F7-20925-4D2458F4; Wed, 11 Apr 2012 08:37:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334133459!4400695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27509 invoked from network); 11 Apr 2012 08:37:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:37:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:37:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 09:37:39 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHt3b-0008R2-35;
	Wed, 11 Apr 2012 08:37:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHt3b-0000k0-03;
	Wed, 11 Apr 2012 09:37:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12638-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 09:37:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12638: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12638 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12638/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:38:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHt3f-0001q6-6o; Wed, 11 Apr 2012 08:37:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHt3d-0001pv-3E
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 08:37:41 +0000
Received: from [85.158.143.35:17861] by server-1.bemta-4.messagelabs.com id
	7D/F7-20925-4D2458F4; Wed, 11 Apr 2012 08:37:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334133459!4400695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27509 invoked from network); 11 Apr 2012 08:37:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:37:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:37:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 09:37:39 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHt3b-0008R2-35;
	Wed, 11 Apr 2012 08:37:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHt3b-0000k0-03;
	Wed, 11 Apr 2012 09:37:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12638-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 09:37:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12638: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12638 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12638/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11890

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHt7j-0002AV-SH; Wed, 11 Apr 2012 08:41:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHt7i-0002AM-OH
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:41:54 +0000
Received: from [85.158.138.51:53928] by server-6.bemta-3.messagelabs.com id
	6B/06-05145-1D3458F4; Wed, 11 Apr 2012 08:41:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334133712!21454121!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31403 invoked from network); 11 Apr 2012 08:41:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 08:41:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Apr 2012 09:41:52 +0100
Message-Id: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Apr 2012 09:41:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334077704-5449-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334077704-5449-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: fix delta calculation in TSC deadline
 timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 19:08, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In the virtual LAPIC, correct the delta calculation when emulating the
> TSC deadline timer.
> 
> Without this fix, XenServer (which is based on Xen 4.1) does not work
> when running as an HVM guest.  dom0 fails to boot because its timer
> interrupts are very delayed (by several minutes in some cases).

Looks generally fine to me, but I'd like you to clean up a little more:
guest_time is now not needed here anymore, and really should also
not matter in this function at all (we're only dealing with TSC values).
Hence I'd like to ask that the variable, its initialization, and its sole
remaining use (passed to the HVM_DBG_LOG() at the end of the
function) be deleted as part of the patch. If you agree, feel free
to add my ack when you resend.

Jan

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> ---
> A 4.1.x candidate?
> ---
>  xen/arch/x86/hvm/vlapic.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 8401756..1aa2810 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -913,9 +913,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t 
> value)
>      guest_time = hvm_get_guest_time(v);
>      if ( value > guest_tsc )
>      {
> -        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
> -        delta = gtsc_to_gtime(v->domain, delta);
> -        delta = max_t(s64, delta - guest_time, 0);
> +        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
> +        delta = max_t(s64, delta, 0);
>  
>          HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", 
> delta);
>  
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHt7j-0002AV-SH; Wed, 11 Apr 2012 08:41:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHt7i-0002AM-OH
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:41:54 +0000
Received: from [85.158.138.51:53928] by server-6.bemta-3.messagelabs.com id
	6B/06-05145-1D3458F4; Wed, 11 Apr 2012 08:41:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334133712!21454121!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31403 invoked from network); 11 Apr 2012 08:41:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 08:41:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Apr 2012 09:41:52 +0100
Message-Id: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Apr 2012 09:41:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334077704-5449-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334077704-5449-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: fix delta calculation in TSC deadline
 timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 19:08, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In the virtual LAPIC, correct the delta calculation when emulating the
> TSC deadline timer.
> 
> Without this fix, XenServer (which is based on Xen 4.1) does not work
> when running as an HVM guest.  dom0 fails to boot because its timer
> interrupts are very delayed (by several minutes in some cases).

Looks generally fine to me, but I'd like you to clean up a little more:
guest_time is now not needed here anymore, and really should also
not matter in this function at all (we're only dealing with TSC values).
Hence I'd like to ask that the variable, its initialization, and its sole
remaining use (passed to the HVM_DBG_LOG() at the end of the
function) be deleted as part of the patch. If you agree, feel free
to add my ack when you resend.

Jan

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> ---
> A 4.1.x candidate?
> ---
>  xen/arch/x86/hvm/vlapic.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 8401756..1aa2810 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -913,9 +913,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t 
> value)
>      guest_time = hvm_get_guest_time(v);
>      if ( value > guest_tsc )
>      {
> -        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
> -        delta = gtsc_to_gtime(v->domain, delta);
> -        delta = max_t(s64, delta - guest_time, 0);
> +        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
> +        delta = max_t(s64, delta, 0);
>  
>          HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", 
> delta);
>  
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:44:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtAJ-0002Ht-Ed; Wed, 11 Apr 2012 08:44:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtAH-0002Ho-N2
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 08:44:33 +0000
Received: from [85.158.138.51:18397] by server-12.bemta-3.messagelabs.com id
	DD/7D-29760-074458F4; Wed, 11 Apr 2012 08:44:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334133872!17441369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17929 invoked from network); 11 Apr 2012 08:44:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:44:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:44:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:44:31 +0100
Message-ID: <1334133870.5394.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 11 Apr 2012 09:44:30 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:04 +0100, Ross Philipson wrote:
> Not really. I think part of the problem here is my mixing of
> terminology. For SMBIOS bits I am pulling apart the overall SMBIOS
> table and just grabbing a desired subset of the SMBIOS structures. The
> individual structures are the entities that do not have an overall
> length field

So, to use the terminology of tools/firmware/hvmloader/smbios_types.h,
you have entities which are subsets of a structure and so do not start
with a "struct smbios_structure_header"?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:44:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtAJ-0002Ht-Ed; Wed, 11 Apr 2012 08:44:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtAH-0002Ho-N2
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 08:44:33 +0000
Received: from [85.158.138.51:18397] by server-12.bemta-3.messagelabs.com id
	DD/7D-29760-074458F4; Wed, 11 Apr 2012 08:44:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334133872!17441369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzUxOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17929 invoked from network); 11 Apr 2012 08:44:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:44:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:44:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:44:31 +0100
Message-ID: <1334133870.5394.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Wed, 11 Apr 2012 09:44:30 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:04 +0100, Ross Philipson wrote:
> Not really. I think part of the problem here is my mixing of
> terminology. For SMBIOS bits I am pulling apart the overall SMBIOS
> table and just grabbing a desired subset of the SMBIOS structures. The
> individual structures are the entities that do not have an overall
> length field

So, to use the terminology of tools/firmware/hvmloader/smbios_types.h,
you have entities which are subsets of a structure and so do not start
with a "struct smbios_structure_header"?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtAy-0002MB-LD; Wed, 11 Apr 2012 08:45:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtAx-0002Lv-Hm
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:45:15 +0000
Received: from [85.158.138.51:21383] by server-5.bemta-3.messagelabs.com id
	89/85-17113-A94458F4; Wed, 11 Apr 2012 08:45:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334133913!10632446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19902 invoked from network); 11 Apr 2012 08:45:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:45:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:44:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:44:56 +0100
Message-ID: <1334133894.5394.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 09:44:54 +0100
In-Reply-To: <1334084885-14474-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/31] .gitignore: Add a missing file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  .gitignore |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 2782ee5..cd12b56 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -357,6 +357,7 @@ tools/firmware/etherboot/eb-roms.h
>  tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
>  tools/misc/xenwatchdogd
>  tools/misc/xen-hvmcrash
> +tools/misc/xen-lowmemd
>  tools/libvchan/vchan-node[12]
>  tools/ocaml/*/.ocamldep.make
>  tools/ocaml/*/*.cm[ixao]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 08:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 08:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtAy-0002MB-LD; Wed, 11 Apr 2012 08:45:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtAx-0002Lv-Hm
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 08:45:15 +0000
Received: from [85.158.138.51:21383] by server-5.bemta-3.messagelabs.com id
	89/85-17113-A94458F4; Wed, 11 Apr 2012 08:45:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334133913!10632446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19902 invoked from network); 11 Apr 2012 08:45:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 08:45:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 08:44:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:44:56 +0100
Message-ID: <1334133894.5394.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 09:44:54 +0100
In-Reply-To: <1334084885-14474-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/31] .gitignore: Add a missing file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  .gitignore |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 2782ee5..cd12b56 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -357,6 +357,7 @@ tools/firmware/etherboot/eb-roms.h
>  tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
>  tools/misc/xenwatchdogd
>  tools/misc/xen-hvmcrash
> +tools/misc/xen-lowmemd
>  tools/libvchan/vchan-node[12]
>  tools/ocaml/*/.ocamldep.make
>  tools/ocaml/*/*.cm[ixao]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtRH-0003Cs-2e; Wed, 11 Apr 2012 09:02:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtRE-0003Cl-VL
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:02:05 +0000
Received: from [85.158.138.51:19897] by server-12.bemta-3.messagelabs.com id
	D3/9E-29760-C88458F4; Wed, 11 Apr 2012 09:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334134923!21674826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17905 invoked from network); 11 Apr 2012 09:02:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:02:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:02:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:02:03 +0100
Message-ID: <1334134921.5394.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:02:01 +0100
In-Reply-To: <1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Formally change the libxl memory allocation failure policy to "crash".
> 
> Previously we had a very uneven approach; much code assumed that
> libxl__sprintf (for example) would never return NULL, but some code
> was written more carefully.
> 
> We think it is unlikely that we will be able to make the library
> actually robust against allocation failure (since that would be an
> awful lot of never-tested error paths) and few calling environments
> will be able to cope anyway.  So, instead, adopt the alternative
> approach: provide allocation functions which never return null, but
> will crash the whole process instead.
> 
> Consequently,
>  - New noreturn function libxl__alloc_failed which may be used for
>    printing a vaguely-useful error message, rather than simply
>    dereferencing a null pointer.

We got that in the next patch?

>  - libxl__ptr_add now returns void as it crashes on failure.
>  - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
>    libxl__alloc_failed.  So all the code that uses these can no longer
>    dereference null on malloc failure.
> 
> While we're at it, make libxl__ptr_add use realloc rather than
> emulating it with calloc and free, and make it grow the array
> exponentially rather than linearly.
> 
> Things left to do:
>  - Provide versions of malloc, realloc and free which do the
>    checking but which do not enroll the pointer in the gc.
>  - Remove a lot of now-spurious error handling.
>  - Remove the ERROR_NOMEM error code.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Couple of unimportant nits below.

>              gc->alloc_ptrs[i] = ptr;
> -            return 0;
> +            return;
>          }
>      }
> -    /* realloc alloc_ptrs manually with calloc/free/replace */
> -    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
> -    if (!re)
> -        return -1;
> -    for (i = 0; i < gc->alloc_maxsize; i++)
> -        re[i] = gc->alloc_ptrs[i];
> -    /* assign the next pointer */
> -    re[i] = ptr;
> +    int new_maxsize = gc->alloc_maxsize * 2 + 25;

+ 25? (I don't mind, seems even more arbitrary now that we have the *2
though).

> +    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
> +    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
> +    if (!gc->alloc_ptrs)
> +        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);

Strictly this should be "..., new_maxsize, sizeof(void*)" since the
arguments are nmemb and size?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtRH-0003Cs-2e; Wed, 11 Apr 2012 09:02:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtRE-0003Cl-VL
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:02:05 +0000
Received: from [85.158.138.51:19897] by server-12.bemta-3.messagelabs.com id
	D3/9E-29760-C88458F4; Wed, 11 Apr 2012 09:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334134923!21674826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17905 invoked from network); 11 Apr 2012 09:02:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:02:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11871984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:02:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:02:03 +0100
Message-ID: <1334134921.5394.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:02:01 +0100
In-Reply-To: <1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Formally change the libxl memory allocation failure policy to "crash".
> 
> Previously we had a very uneven approach; much code assumed that
> libxl__sprintf (for example) would never return NULL, but some code
> was written more carefully.
> 
> We think it is unlikely that we will be able to make the library
> actually robust against allocation failure (since that would be an
> awful lot of never-tested error paths) and few calling environments
> will be able to cope anyway.  So, instead, adopt the alternative
> approach: provide allocation functions which never return null, but
> will crash the whole process instead.
> 
> Consequently,
>  - New noreturn function libxl__alloc_failed which may be used for
>    printing a vaguely-useful error message, rather than simply
>    dereferencing a null pointer.

We got that in the next patch?

>  - libxl__ptr_add now returns void as it crashes on failure.
>  - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
>    libxl__alloc_failed.  So all the code that uses these can no longer
>    dereference null on malloc failure.
> 
> While we're at it, make libxl__ptr_add use realloc rather than
> emulating it with calloc and free, and make it grow the array
> exponentially rather than linearly.
> 
> Things left to do:
>  - Provide versions of malloc, realloc and free which do the
>    checking but which do not enroll the pointer in the gc.
>  - Remove a lot of now-spurious error handling.
>  - Remove the ERROR_NOMEM error code.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Couple of unimportant nits below.

>              gc->alloc_ptrs[i] = ptr;
> -            return 0;
> +            return;
>          }
>      }
> -    /* realloc alloc_ptrs manually with calloc/free/replace */
> -    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
> -    if (!re)
> -        return -1;
> -    for (i = 0; i < gc->alloc_maxsize; i++)
> -        re[i] = gc->alloc_ptrs[i];
> -    /* assign the next pointer */
> -    re[i] = ptr;
> +    int new_maxsize = gc->alloc_maxsize * 2 + 25;

+ 25? (I don't mind, seems even more arbitrary now that we have the *2
though).

> +    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
> +    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
> +    if (!gc->alloc_ptrs)
> +        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);

Strictly this should be "..., new_maxsize, sizeof(void*)" since the
arguments are nmemb and size?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:05:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:05:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtTt-0003KK-KY; Wed, 11 Apr 2012 09:04:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtTs-0003KD-9u
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:04:48 +0000
Received: from [193.109.254.147:37616] by server-7.bemta-14.messagelabs.com id
	5E/FF-01627-F29458F4; Wed, 11 Apr 2012 09:04:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334135084!4082923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7428 invoked from network); 11 Apr 2012 09:04:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:04:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:04:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:04:44 +0100
Message-ID: <1334135082.5394.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:04:42 +0100
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4 00/31] libxl child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> This series has now been tested and is in a suitable form for review
> and, if thought fit, committing to xen-unstable.  It still culminates
> in a patch to convert bootloader execution to the new event machinery.
> 
> Changes since v3 ("[RFC PATCH 00/20]") include:
>  - All comments on previous version addressed.
>  - Several new bugfix patches etc., marked with * below.
>  - Broke the bootloader execution rewrite up into three patches.
>  - Testing and consequent fixes (only to previously un-acked patches);
>    in particular, the final patch has some significant changes.
> 
> Bugfixes for problems reported by Roger Pau Monne:
>   02/31 libxl: ao: allow immediate completion
>   03/31 libxl: fix hang due to libxl__initiate_device_remove
>   04/31 libxl: Fix eventloop_iteration over-locking
> * 05/31 libxl: remove poller from list in libxl__poller_get
> 
> Other general bugfixes:
> * 01/31 .gitignore: Add a missing file
>   06/31 libxl: Fix leak of ctx->lock
>   07/31 tools: Correct PTHREAD options in config/StdGNU.mk
>   08/31 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
>   09/31 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS

I think all of the above are now acked and since they are largely
unrelated to the overall thrust of the series could easily go in now?

>   26/31 libxl: Clean up setdefault in do_domain_create
>   30/31 libxl: make libxl_create_logfile const-correct
> 
> Clarifications and improvements related to memory allocation:
>   10/31 libxl: Crash (more sensibly) on malloc failure
>   11/31 libxl: Make libxl__zalloc et al tolerate a NULL gc

These two could probably go in now too, especially 10/31 would be useful
to have sooner rather than later so we can stop writing error handling
code...

Actually the more I read the more I see that a good chunk of the front
of this series could go in now. Is that what you are planning to do?

> Preparatory work:
>   12/31 libxl: Introduce some convenience macros
>   13/31 libxl: include <ctype.h> and introduce CTYPE helper macro
>   14/31 libxl: Provide libxl_string_list_length
>   15/31 libxl: include <_libxl_paths.h> in libxl_internal.h
>   16/31 libxl: abolish libxl_ctx_postfork
> * 23/31 autoconf: New test for openpty et al.
> * 24/31 libxl: provide libxl__remove_file et al.
> * 25/31 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
> 
> Event-related infrastructure and fixes:
>   17/31 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
>   18/31 libxl: Protect fds with CLOEXEC even with forking threads
> * 19/31 libxl: provide STATE_AO_GC
> * 20/31 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
> * 21/31 libxl: support multiple libxl__ev_fds for the same fd
>   22/31 libxl: event API: new facilities for waiting for subprocesses
>   27/31 libxl: provide libxl__datacopier_*
>   28/31 libxl: provide libxl__openpty_*
>   29/31 libxl: ao: Convert libxl_run_bootloader
> * 31/31 libxl: log bootloader output
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:05:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:05:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtTt-0003KK-KY; Wed, 11 Apr 2012 09:04:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtTs-0003KD-9u
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:04:48 +0000
Received: from [193.109.254.147:37616] by server-7.bemta-14.messagelabs.com id
	5E/FF-01627-F29458F4; Wed, 11 Apr 2012 09:04:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334135084!4082923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7428 invoked from network); 11 Apr 2012 09:04:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:04:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:04:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:04:44 +0100
Message-ID: <1334135082.5394.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:04:42 +0100
In-Reply-To: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4 00/31] libxl child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> This series has now been tested and is in a suitable form for review
> and, if thought fit, committing to xen-unstable.  It still culminates
> in a patch to convert bootloader execution to the new event machinery.
> 
> Changes since v3 ("[RFC PATCH 00/20]") include:
>  - All comments on previous version addressed.
>  - Several new bugfix patches etc., marked with * below.
>  - Broke the bootloader execution rewrite up into three patches.
>  - Testing and consequent fixes (only to previously un-acked patches);
>    in particular, the final patch has some significant changes.
> 
> Bugfixes for problems reported by Roger Pau Monne:
>   02/31 libxl: ao: allow immediate completion
>   03/31 libxl: fix hang due to libxl__initiate_device_remove
>   04/31 libxl: Fix eventloop_iteration over-locking
> * 05/31 libxl: remove poller from list in libxl__poller_get
> 
> Other general bugfixes:
> * 01/31 .gitignore: Add a missing file
>   06/31 libxl: Fix leak of ctx->lock
>   07/31 tools: Correct PTHREAD options in config/StdGNU.mk
>   08/31 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
>   09/31 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS

I think all of the above are now acked and since they are largely
unrelated to the overall thrust of the series could easily go in now?

>   26/31 libxl: Clean up setdefault in do_domain_create
>   30/31 libxl: make libxl_create_logfile const-correct
> 
> Clarifications and improvements related to memory allocation:
>   10/31 libxl: Crash (more sensibly) on malloc failure
>   11/31 libxl: Make libxl__zalloc et al tolerate a NULL gc

These two could probably go in now too, especially 10/31 would be useful
to have sooner rather than later so we can stop writing error handling
code...

Actually the more I read the more I see that a good chunk of the front
of this series could go in now. Is that what you are planning to do?

> Preparatory work:
>   12/31 libxl: Introduce some convenience macros
>   13/31 libxl: include <ctype.h> and introduce CTYPE helper macro
>   14/31 libxl: Provide libxl_string_list_length
>   15/31 libxl: include <_libxl_paths.h> in libxl_internal.h
>   16/31 libxl: abolish libxl_ctx_postfork
> * 23/31 autoconf: New test for openpty et al.
> * 24/31 libxl: provide libxl__remove_file et al.
> * 25/31 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
> 
> Event-related infrastructure and fixes:
>   17/31 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
>   18/31 libxl: Protect fds with CLOEXEC even with forking threads
> * 19/31 libxl: provide STATE_AO_GC
> * 20/31 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
> * 21/31 libxl: support multiple libxl__ev_fds for the same fd
>   22/31 libxl: event API: new facilities for waiting for subprocesses
>   27/31 libxl: provide libxl__datacopier_*
>   28/31 libxl: provide libxl__openpty_*
>   29/31 libxl: ao: Convert libxl_run_bootloader
> * 31/31 libxl: log bootloader output
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtdg-00045Q-Oq; Wed, 11 Apr 2012 09:14:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtdf-00045K-CP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:14:55 +0000
Received: from [85.158.138.51:14320] by server-4.bemta-3.messagelabs.com id
	21/78-15341-E8B458F4; Wed, 11 Apr 2012 09:14:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334135693!21677623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17400 invoked from network); 11 Apr 2012 09:14:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:14:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:14:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:14:52 +0100
Message-ID: <1334135691.5394.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:14:51 +0100
In-Reply-To: <1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> We introduce a new "carefd" concept, which relates to fds that we care
> about not being inherited by long-lived children.
> 
> As yet we do not use this anywhere in libxl.  Until all locations in
> libxl which make such fds are converted, libxl__postfork may not work
> entirely properly.  If these locations do not use O_CLOEXEC (or use
> calls for which there is no O_CLOEXEC) then multithreaded programs may
> not work properly.
> 
> This introduces a new API call libxl_postfork_child_noexec which must
> be called by applications which make long-running non-execing
> children.  Add the appropriate call to xl's postfork function.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/Makefile         |    2 +-
>  tools/libxl/libxl.c          |    3 +
>  tools/libxl/libxl_event.h    |   13 ++++
>  tools/libxl/libxl_fork.c     |  146 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
>  tools/libxl/xl.c             |    3 +
>  6 files changed, 229 insertions(+), 1 deletions(-)
>  create mode 100644 tools/libxl/libxl_fork.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 9f7e454..e5ea867 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -53,7 +53,7 @@ LIBXL_LIBS += -lyajl
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
> -                       libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
> +                       libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 8910420..60dbfdc 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> 
>      /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
> 
> +    rc = libxl__atfork_init(ctx);
> +    if (rc) goto out;
> +
>      rc = libxl__poller_init(ctx, &ctx->poller_app);
>      if (rc) goto out;
> 
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index ea553f6..2d2196f 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -371,6 +371,19 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
>   */
>  void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> 
> +
> +/*
> + * An application which initialises a libxl_ctx in a parent process
> + * and then forks a child which does not quickly exec, must
> + * instead libxl_postfork_child_noexec in the child.  One call
> + * on any existing (or specially made) ctx is sufficient; after
> + * this all previously existing libxl_ctx's are invalidated and
> + * must not be used - or even freed.  It is harmless to call this
> + * postfork function and then exec anyway.
> + */
> +void libxl_postfork_child_noexec(libxl_ctx *ctx);
> +
> +
>  #endif
> 
>  /*
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> new file mode 100644
> index 0000000..4751ef4
> --- /dev/null
> +++ b/tools/libxl/libxl_fork.c
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal child process machinery for use by other parts of libxl
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * carefd arrangements
> + *
> + * carefd_begin and _unlock take out the no_forking lock, which we
> + * also take and release in our pthread_atfork handlers.  So when this
> + * lock is held the whole process cannot fork.  We therefore protect
> + * our fds from leaking into children made by other threads.
> + *
> + * We maintain a list of all the carefds, so that if the application
> + * wants to fork a long-running but non-execing child, we can close
> + * them all.
> + *
> + * So the record function sets CLOEXEC for the benefit of execing
> + * children, and makes a note of the fd for the benefit of non-execing
> + * ones.
> + */
> +
> +struct libxl__carefd {
> +    LIBXL_LIST_ENTRY(libxl__carefd) entry;
> +    int fd;
> +};
> +
> +static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
> +static int atfork_registered;
> +static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
> +    LIBXL_LIST_HEAD_INITIALIZER(carefds);
> +
> +static void atfork_lock(void)
> +{
> +    int r = pthread_mutex_lock(&no_forking);
> +    assert(!r);
> +}
> +
> +static void atfork_unlock(void)
> +{
> +    int r = pthread_mutex_unlock(&no_forking);
> +    assert(!r);
> +}
> +
> +int libxl__atfork_init(libxl_ctx *ctx)
> +{
> +    int r, rc;
> +
> +    atfork_lock();
> +    if (atfork_registered) { rc = 0; goto out; }
> +
> +    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
> +    if (r) libxl__alloc_failed(ctx, __func__, 0,0);

This is a bit subtle -- the only documented error from pthread_atfork is
ENOMEM. Perhaps "assert(r == 0 || errno == ENOMEM)" as both
belt'n'braces and doc?

Actually, pthread_atfork(3) says it "returns an error code" so maybe
that should be "r == 0 || r == ENOMEM" ? Seems oddly inconsistent to
norms though.

The above wouldn't stop me from acking though:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.

> +
> +    atfork_registered = 1;
> +    rc = 0;
> + out:
> +    atfork_unlock();
> +    return rc;
> +}
> +
> +void libxl__carefd_begin(void) { atfork_lock(); }
> +void libxl__carefd_unlock(void) { atfork_unlock(); }
> +
> +libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
> +{
> +    libxl__carefd *cf = 0;
> +
> +    libxl_fd_set_cloexec(ctx, fd, 1);
> +    cf = libxl__zalloc(NULL, sizeof(*cf));
> +    cf->fd = fd;
> +    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
> +    return cf;
> +}
> +
> +libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
> +{
> +    libxl__carefd *cf = 0;
> +
> +    cf = libxl__carefd_record(ctx, fd);
> +    libxl__carefd_unlock();
> +    return cf;
> +}
> +
> +void libxl_postfork_child_noexec(libxl_ctx *ctx)
> +{
> +    libxl__carefd *cf, *cf_tmp;
> +    int r;
> +
> +    atfork_lock();
> +    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
> +        if (cf->fd >= 0) {
> +            r = close(cf->fd);
> +            if (r)
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING,
> +                                 "failed to close fd=%d"
> +                                 " (perhaps of another libxl ctx)", cf->fd);
> +        }
> +        free(cf);
> +    }
> +    LIBXL_LIST_INIT(&carefds);
> +    atfork_unlock();
> +}
> +
> +int libxl__carefd_close(libxl__carefd *cf)
> +{
> +    if (!cf) return 0;
> +    int r = cf->fd < 0 ? 0 : close(cf->fd);
> +    int esave = errno;
> +    atfork_lock();
> +    LIBXL_LIST_REMOVE(cf, entry);
> +    atfork_unlock();
> +    free(cf);
> +    errno = esave;
> +    return r;
> +}
> +
> +int libxl__carefd_fd(const libxl__carefd *cf)
> +{
> +    if (!cf) return -1;
> +    return cf->fd;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 740bde2..a8372bb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -611,6 +611,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
>  void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
> 
> 
> +int libxl__atfork_init(libxl_ctx *ctx);
> +
> +
>  /* from xl_dom */
>  _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
> @@ -1307,6 +1310,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
>  /* For use by ao machinery ONLY */
>  _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
> 
> +
> +/*
> + * File descriptors and CLOEXEC
> + */
> +
> +/*
> + * For libxl functions which create file descriptors, at least one
> + * of the following must be true:
> + *  (a) libxl does not care if copies of this open-file are inherited
> + *      by random children and might remain open indefinitely
> + *  (b) libxl must take extra care for the fd (the actual descriptor,
> + *      not the open-file) as below.  We call this a "carefd".
> + *
> + * The rules for opening a carefd are:
> + *  (i)   Before bringing any carefds into existence,
> + *        libxl code must call libxl__carefd_begin.
> + *  (ii)  Then for each carefd brought into existence,
> + *        libxl code must call libxl__carefd_record
> + *        and remember the libxl__carefd_record*.
> + *  (iii) Then it must call libxl__carefd_unlock.
> + *  (iv)  When in a child process the fd is to be passed across
> + *        exec by libxl, the libxl code must unset FD_CLOEXEC
> + *        on the fd eg by using libxl_fd_set_cloexec.
> + *  (v)   Later, when the fd is to be closed in the same process,
> + *        libxl code must not call close.  Instead, it must call
> + *        libxl__carefd_close.
> + * Steps (ii) and (iii) can be combined by calling the convenience
> + * function libxl__carefd_opened.
> + */
> +/* libxl__carefd_begin and _unlock (or _opened) must be called always
> + * in pairs.  They may be called with the CTX lock held.  In between
> + * _begin and _unlock, the following are prohibited:
> + *   - anything which might block
> + *   - any callbacks to the application
> + *   - nested calls to libxl__carefd_begin
> + *   - fork (libxl__fork)
> + * In general nothing should be done before _unlock that could be done
> + * afterwards.
> + */
> +typedef struct libxl__carefd libxl__carefd;
> +
> +void libxl__carefd_begin(void);
> +void libxl__carefd_unlock(void);
> +
> +/* fd may be -1, in which case this returns a dummy libxl__fd_record
> + * on which it _carefd_close is a no-op.  Cannot fail. */
> +libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
> +
> +/* Combines _record and _unlock in a single call.  If fd==-1,
> + * still does the unlock, but returns 0.  Cannot fail. */
> +libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
> +
> +/* Works just like close(2).  You may pass NULL, in which case it's
> + * a successful no-op. */
> +int libxl__carefd_close(libxl__carefd*);
> +
> +/* You may pass NULL in which case the answer is -1. */
> +int libxl__carefd_fd(const libxl__carefd*);
> +
> +
>  /*
>   * Convenience macros.
>   */
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index 62c0abd..a6ffd25 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -96,6 +96,9 @@ static void parse_global_config(const char *configfile,
> 
>  void postfork(void)
>  {
> +    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
> +    ctx = 0;
> +
>      if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
>          fprintf(stderr, "cannot reinit xl context after fork\n");
>          exit(-1);
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtdg-00045Q-Oq; Wed, 11 Apr 2012 09:14:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtdf-00045K-CP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:14:55 +0000
Received: from [85.158.138.51:14320] by server-4.bemta-3.messagelabs.com id
	21/78-15341-E8B458F4; Wed, 11 Apr 2012 09:14:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334135693!21677623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17400 invoked from network); 11 Apr 2012 09:14:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:14:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:14:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:14:52 +0100
Message-ID: <1334135691.5394.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:14:51 +0100
In-Reply-To: <1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> We introduce a new "carefd" concept, which relates to fds that we care
> about not being inherited by long-lived children.
> 
> As yet we do not use this anywhere in libxl.  Until all locations in
> libxl which make such fds are converted, libxl__postfork may not work
> entirely properly.  If these locations do not use O_CLOEXEC (or use
> calls for which there is no O_CLOEXEC) then multithreaded programs may
> not work properly.
> 
> This introduces a new API call libxl_postfork_child_noexec which must
> be called by applications which make long-running non-execing
> children.  Add the appropriate call to xl's postfork function.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/Makefile         |    2 +-
>  tools/libxl/libxl.c          |    3 +
>  tools/libxl/libxl_event.h    |   13 ++++
>  tools/libxl/libxl_fork.c     |  146 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
>  tools/libxl/xl.c             |    3 +
>  6 files changed, 229 insertions(+), 1 deletions(-)
>  create mode 100644 tools/libxl/libxl_fork.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 9f7e454..e5ea867 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -53,7 +53,7 @@ LIBXL_LIBS += -lyajl
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
> -                       libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
> +                       libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 8910420..60dbfdc 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> 
>      /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
> 
> +    rc = libxl__atfork_init(ctx);
> +    if (rc) goto out;
> +
>      rc = libxl__poller_init(ctx, &ctx->poller_app);
>      if (rc) goto out;
> 
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index ea553f6..2d2196f 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -371,6 +371,19 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
>   */
>  void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> 
> +
> +/*
> + * An application which initialises a libxl_ctx in a parent process
> + * and then forks a child which does not quickly exec, must
> + * instead libxl_postfork_child_noexec in the child.  One call
> + * on any existing (or specially made) ctx is sufficient; after
> + * this all previously existing libxl_ctx's are invalidated and
> + * must not be used - or even freed.  It is harmless to call this
> + * postfork function and then exec anyway.
> + */
> +void libxl_postfork_child_noexec(libxl_ctx *ctx);
> +
> +
>  #endif
> 
>  /*
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> new file mode 100644
> index 0000000..4751ef4
> --- /dev/null
> +++ b/tools/libxl/libxl_fork.c
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal child process machinery for use by other parts of libxl
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * carefd arrangements
> + *
> + * carefd_begin and _unlock take out the no_forking lock, which we
> + * also take and release in our pthread_atfork handlers.  So when this
> + * lock is held the whole process cannot fork.  We therefore protect
> + * our fds from leaking into children made by other threads.
> + *
> + * We maintain a list of all the carefds, so that if the application
> + * wants to fork a long-running but non-execing child, we can close
> + * them all.
> + *
> + * So the record function sets CLOEXEC for the benefit of execing
> + * children, and makes a note of the fd for the benefit of non-execing
> + * ones.
> + */
> +
> +struct libxl__carefd {
> +    LIBXL_LIST_ENTRY(libxl__carefd) entry;
> +    int fd;
> +};
> +
> +static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
> +static int atfork_registered;
> +static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
> +    LIBXL_LIST_HEAD_INITIALIZER(carefds);
> +
> +static void atfork_lock(void)
> +{
> +    int r = pthread_mutex_lock(&no_forking);
> +    assert(!r);
> +}
> +
> +static void atfork_unlock(void)
> +{
> +    int r = pthread_mutex_unlock(&no_forking);
> +    assert(!r);
> +}
> +
> +int libxl__atfork_init(libxl_ctx *ctx)
> +{
> +    int r, rc;
> +
> +    atfork_lock();
> +    if (atfork_registered) { rc = 0; goto out; }
> +
> +    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
> +    if (r) libxl__alloc_failed(ctx, __func__, 0,0);

This is a bit subtle -- the only documented error from pthread_atfork is
ENOMEM. Perhaps "assert(r == 0 || errno == ENOMEM)" as both
belt'n'braces and doc?

Actually, pthread_atfork(3) says it "returns an error code" so maybe
that should be "r == 0 || r == ENOMEM" ? Seems oddly inconsistent to
norms though.

The above wouldn't stop me from acking though:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.

> +
> +    atfork_registered = 1;
> +    rc = 0;
> + out:
> +    atfork_unlock();
> +    return rc;
> +}
> +
> +void libxl__carefd_begin(void) { atfork_lock(); }
> +void libxl__carefd_unlock(void) { atfork_unlock(); }
> +
> +libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
> +{
> +    libxl__carefd *cf = 0;
> +
> +    libxl_fd_set_cloexec(ctx, fd, 1);
> +    cf = libxl__zalloc(NULL, sizeof(*cf));
> +    cf->fd = fd;
> +    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
> +    return cf;
> +}
> +
> +libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
> +{
> +    libxl__carefd *cf = 0;
> +
> +    cf = libxl__carefd_record(ctx, fd);
> +    libxl__carefd_unlock();
> +    return cf;
> +}
> +
> +void libxl_postfork_child_noexec(libxl_ctx *ctx)
> +{
> +    libxl__carefd *cf, *cf_tmp;
> +    int r;
> +
> +    atfork_lock();
> +    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
> +        if (cf->fd >= 0) {
> +            r = close(cf->fd);
> +            if (r)
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING,
> +                                 "failed to close fd=%d"
> +                                 " (perhaps of another libxl ctx)", cf->fd);
> +        }
> +        free(cf);
> +    }
> +    LIBXL_LIST_INIT(&carefds);
> +    atfork_unlock();
> +}
> +
> +int libxl__carefd_close(libxl__carefd *cf)
> +{
> +    if (!cf) return 0;
> +    int r = cf->fd < 0 ? 0 : close(cf->fd);
> +    int esave = errno;
> +    atfork_lock();
> +    LIBXL_LIST_REMOVE(cf, entry);
> +    atfork_unlock();
> +    free(cf);
> +    errno = esave;
> +    return r;
> +}
> +
> +int libxl__carefd_fd(const libxl__carefd *cf)
> +{
> +    if (!cf) return -1;
> +    return cf->fd;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 740bde2..a8372bb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -611,6 +611,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
>  void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
> 
> 
> +int libxl__atfork_init(libxl_ctx *ctx);
> +
> +
>  /* from xl_dom */
>  _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
> @@ -1307,6 +1310,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
>  /* For use by ao machinery ONLY */
>  _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
> 
> +
> +/*
> + * File descriptors and CLOEXEC
> + */
> +
> +/*
> + * For libxl functions which create file descriptors, at least one
> + * of the following must be true:
> + *  (a) libxl does not care if copies of this open-file are inherited
> + *      by random children and might remain open indefinitely
> + *  (b) libxl must take extra care for the fd (the actual descriptor,
> + *      not the open-file) as below.  We call this a "carefd".
> + *
> + * The rules for opening a carefd are:
> + *  (i)   Before bringing any carefds into existence,
> + *        libxl code must call libxl__carefd_begin.
> + *  (ii)  Then for each carefd brought into existence,
> + *        libxl code must call libxl__carefd_record
> + *        and remember the libxl__carefd_record*.
> + *  (iii) Then it must call libxl__carefd_unlock.
> + *  (iv)  When in a child process the fd is to be passed across
> + *        exec by libxl, the libxl code must unset FD_CLOEXEC
> + *        on the fd eg by using libxl_fd_set_cloexec.
> + *  (v)   Later, when the fd is to be closed in the same process,
> + *        libxl code must not call close.  Instead, it must call
> + *        libxl__carefd_close.
> + * Steps (ii) and (iii) can be combined by calling the convenience
> + * function libxl__carefd_opened.
> + */
> +/* libxl__carefd_begin and _unlock (or _opened) must be called always
> + * in pairs.  They may be called with the CTX lock held.  In between
> + * _begin and _unlock, the following are prohibited:
> + *   - anything which might block
> + *   - any callbacks to the application
> + *   - nested calls to libxl__carefd_begin
> + *   - fork (libxl__fork)
> + * In general nothing should be done before _unlock that could be done
> + * afterwards.
> + */
> +typedef struct libxl__carefd libxl__carefd;
> +
> +void libxl__carefd_begin(void);
> +void libxl__carefd_unlock(void);
> +
> +/* fd may be -1, in which case this returns a dummy libxl__fd_record
> + * on which it _carefd_close is a no-op.  Cannot fail. */
> +libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
> +
> +/* Combines _record and _unlock in a single call.  If fd==-1,
> + * still does the unlock, but returns 0.  Cannot fail. */
> +libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
> +
> +/* Works just like close(2).  You may pass NULL, in which case it's
> + * a successful no-op. */
> +int libxl__carefd_close(libxl__carefd*);
> +
> +/* You may pass NULL in which case the answer is -1. */
> +int libxl__carefd_fd(const libxl__carefd*);
> +
> +
>  /*
>   * Convenience macros.
>   */
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index 62c0abd..a6ffd25 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -96,6 +96,9 @@ static void parse_global_config(const char *configfile,
> 
>  void postfork(void)
>  {
> +    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
> +    ctx = 0;
> +
>      if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
>          fprintf(stderr, "cannot reinit xl context after fork\n");
>          exit(-1);
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:18:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHth2-0004MC-57; Wed, 11 Apr 2012 09:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHth0-0004Lm-MD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:18:22 +0000
Received: from [85.158.143.99:22843] by server-2.bemta-4.messagelabs.com id
	C2/33-17550-D5C458F4; Wed, 11 Apr 2012 09:18:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334135900!17871135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20238 invoked from network); 11 Apr 2012 09:18:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872423"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:17:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:17:17 +0100
Message-ID: <1334135836.5394.87.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:17:16 +0100
In-Reply-To: <1334084885-14474-20-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-20-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/31] libxl: provide STATE_AO_GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Provide a convenience macro for use in ao callback functions, and
> document that it should be used.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index a8372bb..76875bb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1266,9 +1266,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   * - Note that during callback functions, two gcs are available:
>   *    - The one in egc, whose lifetime is only this callback
>   *    - The one in ao, whose lifetime is the asynchronous operation
> - *   Usually callback function should use CONTAINER_OF
> - *   to obtain its own structure, containing a pointer to the ao,
> - *   and then use the gc from that ao.
> + *   Usually callback function should use CONTAINER_OF to obtain its
> + *   own state structure, containing a pointer to the ao.  It should
> + *   then obtain the ao and use the ao's gc; this is most easily done
> + *   using the convenience macro STATE_AO_GC.
>   */
>  
>  #define AO_CREATE(ctx, domid, ao_how)                           \
> @@ -1298,6 +1299,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>  #define AO_GC                                   \
>      libxl__gc *const gc = &ao->gc
>  
> +#define STATE_AO_GC(op)                         \
> +    libxl__ao *const ao = op->ao;               \
> +    AO_GC
> +
>  
>  /* All of these MUST be called with the ctx locked.
>   * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:18:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHth2-0004MC-57; Wed, 11 Apr 2012 09:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHth0-0004Lm-MD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:18:22 +0000
Received: from [85.158.143.99:22843] by server-2.bemta-4.messagelabs.com id
	C2/33-17550-D5C458F4; Wed, 11 Apr 2012 09:18:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334135900!17871135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20238 invoked from network); 11 Apr 2012 09:18:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872423"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:17:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:17:17 +0100
Message-ID: <1334135836.5394.87.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:17:16 +0100
In-Reply-To: <1334084885-14474-20-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-20-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/31] libxl: provide STATE_AO_GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Provide a convenience macro for use in ao callback functions, and
> document that it should be used.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index a8372bb..76875bb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1266,9 +1266,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   * - Note that during callback functions, two gcs are available:
>   *    - The one in egc, whose lifetime is only this callback
>   *    - The one in ao, whose lifetime is the asynchronous operation
> - *   Usually callback function should use CONTAINER_OF
> - *   to obtain its own structure, containing a pointer to the ao,
> - *   and then use the gc from that ao.
> + *   Usually callback function should use CONTAINER_OF to obtain its
> + *   own state structure, containing a pointer to the ao.  It should
> + *   then obtain the ao and use the ao's gc; this is most easily done
> + *   using the convenience macro STATE_AO_GC.
>   */
>  
>  #define AO_CREATE(ctx, domid, ao_how)                           \
> @@ -1298,6 +1299,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>  #define AO_GC                                   \
>      libxl__gc *const gc = &ao->gc
>  
> +#define STATE_AO_GC(op)                         \
> +    libxl__ao *const ao = op->ao;               \
> +    AO_GC
> +
>  
>  /* All of these MUST be called with the ctx locked.
>   * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:21:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtkB-0004f5-Ua; Wed, 11 Apr 2012 09:21:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtkB-0004ey-BP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:21:39 +0000
Received: from [85.158.143.99:46080] by server-1.bemta-4.messagelabs.com id
	95/ED-20925-22D458F4; Wed, 11 Apr 2012 09:21:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334136097!22580059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25152 invoked from network); 11 Apr 2012 09:21:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:21:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:21:36 +0100
Message-ID: <1334136095.5394.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:21:35 +0100
In-Reply-To: <1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
> Crash on POLLNVAL since that means our fds are messed up.
> 
> Document the behaviour (including the fact that poll sometimes sets
> POLLHUP or POLLERR even if only POLLIN was requested.
> 
> Fix the one current fd callback to do something with POLLERR|POLLHUP.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |    7 ++++++-
>  tools/libxl/libxl_internal.h |    5 +++++
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 638b9ab..5e1a207 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>  {
>      EGC_GC;
>  
> +    if (revents & (POLLERR|POLLHUP))
> +        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);

If this can happen even when we didn't ask for it then is that really a
disaster? Could we just log it and move on (or ignore it)?

Under what circumstances does poll actually behave this way? Is it an
indication that something has gone horribly wrong already?

> +
>      for (;;) {
>          char **event = xs_check_watch(CTX->xsh);
>          if (!event) {
> @@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
>          /* again, stale slot entry */
>          return 0;
>  
> -    int revents = fds[slot].revents & events;
> +    assert(!(fds[slot].revents & POLLNVAL));
> +
> +    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
>      /* we mask in case requested events have changed */
>  
>      return revents;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 76875bb..9f2583d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
>  typedef struct libxl__ev_fd libxl__ev_fd;
>  typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>                                     int fd, short events, short revents);
> +  /* Note that revents may contain POLLERR or POLLHUP regardless of
> +   * events; otherwise revents contains only bits in events.  Contrary
> +   * to the documentation for poll(2), POLLERR and POLLHUP can occur
> +   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
> +   * error and will cause libxl event machinery to fail an assertion.) */
>  struct libxl__ev_fd {
>      /* caller should include this in their own struct */
>      /* read-only for caller, who may read only when registered: */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:21:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHtkB-0004f5-Ua; Wed, 11 Apr 2012 09:21:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHtkB-0004ey-BP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:21:39 +0000
Received: from [85.158.143.99:46080] by server-1.bemta-4.messagelabs.com id
	95/ED-20925-22D458F4; Wed, 11 Apr 2012 09:21:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334136097!22580059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25152 invoked from network); 11 Apr 2012 09:21:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11872524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:21:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:21:36 +0100
Message-ID: <1334136095.5394.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:21:35 +0100
In-Reply-To: <1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
> Crash on POLLNVAL since that means our fds are messed up.
> 
> Document the behaviour (including the fact that poll sometimes sets
> POLLHUP or POLLERR even if only POLLIN was requested.
> 
> Fix the one current fd callback to do something with POLLERR|POLLHUP.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |    7 ++++++-
>  tools/libxl/libxl_internal.h |    5 +++++
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 638b9ab..5e1a207 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>  {
>      EGC_GC;
>  
> +    if (revents & (POLLERR|POLLHUP))
> +        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);

If this can happen even when we didn't ask for it then is that really a
disaster? Could we just log it and move on (or ignore it)?

Under what circumstances does poll actually behave this way? Is it an
indication that something has gone horribly wrong already?

> +
>      for (;;) {
>          char **event = xs_check_watch(CTX->xsh);
>          if (!event) {
> @@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
>          /* again, stale slot entry */
>          return 0;
>  
> -    int revents = fds[slot].revents & events;
> +    assert(!(fds[slot].revents & POLLNVAL));
> +
> +    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
>      /* we mask in case requested events have changed */
>  
>      return revents;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 76875bb..9f2583d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
>  typedef struct libxl__ev_fd libxl__ev_fd;
>  typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>                                     int fd, short events, short revents);
> +  /* Note that revents may contain POLLERR or POLLHUP regardless of
> +   * events; otherwise revents contains only bits in events.  Contrary
> +   * to the documentation for poll(2), POLLERR and POLLHUP can occur
> +   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
> +   * error and will cause libxl event machinery to fail an assertion.) */
>  struct libxl__ev_fd {
>      /* caller should include this in their own struct */
>      /* read-only for caller, who may read only when registered: */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:42:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHu4T-0005BI-Ul; Wed, 11 Apr 2012 09:42:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHu4R-0005BD-Tq
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:42:36 +0000
Received: from [85.158.143.35:24617] by server-2.bemta-4.messagelabs.com id
	D5/93-17550-B02558F4; Wed, 11 Apr 2012 09:42:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334137353!4415325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19123 invoked from network); 11 Apr 2012 09:42:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:42:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:42:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:42:33 +0100
Message-ID: <1334137352.5394.92.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:42:32 +0100
In-Reply-To: <1334084885-14474-23-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-23-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/31] libxl: event API: new facilities for
 waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> The current arrangements in libxl for spawning subprocesses have two
> key problems: (i) they make unwarranted (and largely undocumented)
> assumptions about the caller's use of subprocesses, (ii) they aren't
> integrated into the event system and can't be made asynchronous etc.
> 
> So replace them with a new set of facilities.
> 
> Primarily, from the point of view of code inside libxl, this is
> libxl__ev_child_fork which is both (a) a version of fork() and (b) an
> event source which generates a callback when the child dies.
> 
> From the point of view of the application, we fully document our use
> of SIGCHLD.  The application can tell us whether it wants to own
> SIGCHLD or not; if it does, it has to tell us about deaths of our
> children.
> 
> Currently there are no callers in libxl which use these facilities.
> All code in libxl which forks needs to be converted and libxl_fork
> needse to be be abolished.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c          |   17 +++-
>  tools/libxl/libxl.h          |    1 +
>  tools/libxl/libxl_event.c    |   53 +++++++--
>  tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
>  tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   59 +++++++++-
>  6 files changed, 512 insertions(+), 20 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 60dbfdc..42ac89f 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      memset(ctx, 0, sizeof(libxl_ctx));
>      ctx->lg = lg;
> 
> -    /* First initialise pointers (cannot fail) */
> +    /* First initialise pointers etc. (cannot fail) */
> 
>      LIBXL_TAILQ_INIT(&ctx->occurred);
> 
> @@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      LIBXL_TAILQ_INIT(&ctx->death_list);
>      libxl__ev_xswatch_init(&ctx->death_watch);
> 
> +    ctx->childproc_hooks = &libxl__childproc_default_hooks;
> +    ctx->childproc_user = 0;
> +
> +    ctx->sigchld_selfpipe[0] = -1;
> +
>      /* The mutex is special because we can't idempotently destroy it */
> 
>      if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
> @@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
> 
>      discard_events(&ctx->occurred);
> 
> +    /* If we have outstanding children, then the application inherits
> +     * them; we wish the application good luck with understanding
> +     * this if and when it reaps them. */
> +    libxl__sigchld_removehandler(ctx);
> +
> +    if (ctx->sigchld_selfpipe[0] >= 0) {
> +        close(ctx->sigchld_selfpipe[0]);
> +        close(ctx->sigchld_selfpipe[1]);
> +    }
> +
>      pthread_mutex_destroy(&ctx->lock);
> 
>      GC_FREE;
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index edbca53..03e71f6 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -380,6 +380,7 @@ enum {
>      ERROR_NOT_READY = -11,
>      ERROR_OSEVENT_REG_FAIL = -12,
>      ERROR_BUFFERFULL = -13,
> +    ERROR_UNKNOWN_CHILD = -14,
>  };
> 
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 672e3fe..1b7495a 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>                                                                         \
>          REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
>                                                                         \
> +        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
> +        if (selfpipe >= 0)                                             \
> +            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
> +                                                                       \
>      }while(0)
> 
>  #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
> @@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
>                                 int nfds, const struct pollfd *fds,
>                                 struct timeval now)
>  {
> +    /* May make callbacks into the application for child processes.
> +     * ctx must be locked exactly once */
>      EGC_GC;
>      libxl__ev_fd *efd;
> 
> -
>      LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
>          if (!efd->events)
>              continue;
> @@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
>      }
> 
>      if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
> -        char buf[256];
> -        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
> -        if (r < 0)
> -            if (errno != EINTR && errno != EWOULDBLOCK)
> -                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
> +        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
> +        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
> +    }
> +
> +    int selfpipe = libxl__fork_selfpipe_active(CTX);
> +    if (selfpipe >= 0 &&
> +        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
> +        int e = libxl__self_pipe_eatall(selfpipe);
> +        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
> +        libxl__fork_selfpipe_woken(egc);
>      }
> 
>      for (;;) {
> @@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
> 
>  void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
>  {
> +    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
> +    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
> +}
> +
> +int libxl__self_pipe_wakeup(int fd)
> +{
>      static const char buf[1] = "";
> 
>      for (;;) {
> -        int r = write(p->wakeup_pipe[1], buf, 1);
> -        if (r==1) return;
> +        int r = write(fd, buf, 1);
> +        if (r==1) return 0;
>          assert(r==-1);
>          if (errno == EINTR) continue;
> -        if (errno == EWOULDBLOCK) return;
> -        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
> -        return;
> +        if (errno == EWOULDBLOCK) return 0;
> +        assert(errno);
> +        return errno;
> +    }
> +}
> +
> +int libxl__self_pipe_eatall(int fd)
> +{
> +    char buf[256];
> +    for (;;) {
> +        int r = read(fd, buf, sizeof(buf));
> +        if (r == sizeof(buf)) continue;
> +        if (r >= 0) return 0;
> +        assert(r == -1);
> +        if (errno == EINTR) continue;
> +        if (errno == EWOULDBLOCK) return 0;
> +        assert(errno);
> +        return errno;
>      }
>  }
> 
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 2d2196f..713d96d 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
>   * After libxl_ctx_free, all corresponding evgen handles become
>   * invalid and must no longer be passed to evdisable.
>   *
> - * Events enabled with evenable prior to a fork and libxl_ctx_postfork
> - * are no longer generated after the fork/postfork; however the evgen
> - * structures are still valid and must be passed to evdisable if the
> - * memory they use should not be leaked.
> - *
>   * Applications should ensure that they eventually retrieve every
>   * event using libxl_event_check or libxl_event_wait, since events
>   * which occur but are not retreived by the application will be queued
> @@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
>  void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> 
> 
> +/*======================================================================*/
> +
> +/*
> + * Subprocess handling.
> + *
> + * Unfortunately the POSIX interface makes this very awkward.
> + *
> + * There are two possible arrangements for collecting statuses from
> + * wait/waitpid.
> + *
> + * For naive programs:
> + *
> + *     libxl will keep a SIGCHLD handler installed whenever it has an
> + *     active (unreaped) child.  It will reap all children with
> + *     wait(); any children it does not recognise will be passed to
> + *     the application via an optional callback (and will result in
> + *     logged warnings if no callback is provided or the callback
> + *     denies responsibility for the child).
> + *
> + *     libxl may have children whenever:
> + *
> + *       - libxl is performing an operation which can be made
> + *         asynchronous; ie one taking a libxl_asyncop_how, even
> + *         if NULL is passed indicating that the operation is
> + *         synchronous; or
> + *
> + *       - events of any kind are being generated, as requested
> + *         by libxl_evenable_....
> + *
> + *     A multithreaded application which is naive in this sense may
> + *     block SIGCHLD on some of its threads, but there must be at
> + *     least one thread that has SIGCHLD unblocked.  libxl will not
> + *     modify the blocking flag for SIGCHLD (except that it may create
> + *     internal service threads with all signals blocked).
> + *
> + *     A naive program must only have at any one time only
> + *     one libxl context which might have children.
> + *
> + * For programs which run their own children alongside libxl's:
> + *
> + *     A program which does this must call libxl_childproc_setmode.
> + *     There are two options:
> + *
> + *     libxl_sigchld_owner_mainloop:
> + *       The application must install a SIGCHLD handler and reap (at
> + *       least) all of libxl's children and pass their exit status
> + *       to libxl by calling libxl_childproc_exited.
> + *
> + *     libxl_sigchld_owner_libxl_always:
> + *       The application expects libxl to reap all of its children,
> + *       and provides a callback to be notified of their exit
> + *       statues.
> + *
> + * An application which fails to call setmode, or which passes 0 for
> + * hooks, while it uses any libxl operation which might
> + * create or use child processes (see above):
> + *   - Must not have any child processes running.
> + *   - Must not install a SIGCHLD handler.
> + *   - Must not reap any children.
> + */
> +
> +
> +typedef enum {
> +    /* libxl owns SIGCHLD whenever it has a child. */
> +    libxl_sigchld_owner_libxl,
> +
> +    /* Application promises to call libxl_childproc_exited but NOT
> +     * from within a signal handler.  libxl will not itself arrange to
> +     * (un)block or catch SIGCHLD. */
> +    libxl_sigchld_owner_mainloop,
> +
> +    /* libxl owns SIGCHLD all the time, and the application is
> +     * relying on libxl's event loop for reaping its own children. */
> +    libxl_sigchld_owner_libxl_always,
> +} libxl_sigchld_owner;
> +
> +typedef struct {
> +    libxl_sigchld_owner chldowner;
> +
> +    /* All of these are optional: */
> +
> +    /* Called by libxl instead of fork.  Should behave exactly like
> +     * fork, including setting errno etc.  May NOT reenter into libxl.
> +     * Application may use this to discover pids of libxl's children,
> +     * for example.
> +     */
> +    pid_t (*fork_replacement)(void *user);
> +
> +    /* With libxl_sigchld_owner_libxl, called by libxl when it has
> +     * reaped a pid.  (Not permitted with _owner_mainloop.)
> +     *
> +     * Should return 0 if the child was recognised by the application
> +     * (or if the application does not keep those kind of records),
> +     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
> +     * the application's; if it returns another error code it is a
> +     * disaster as described for libxl_event_register_callbacks.
> +     * (libxl will report unexpected children to its error log.)
> +     *
> +     * If not supplied, the application is assumed not to start
> +     * any children of its own.
> +     *
> +     * This function is NOT called from within the signal handler.
> +     * Rather it will be called from inside a libxl's event handling
> +     * code and thus only when libxl is running, for example from
> +     * within libxl_event_wait.  (libxl uses the self-pipe trick
> +     * to implement this.)
> +     *
> +     * childproc_exited_callback may call back into libxl, but it
> +     * is best to avoid making long-running libxl calls as that might
> +     * stall the calling event loop while the nested operation
> +     * completes.
> +     */
> +    int (*reaped_callback)(pid_t, int status, void *user);
> +} libxl_childproc_hooks;
> +
> +/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
> + *
> + * May not be called when libxl might have any child processes, or the
> + * behaviour is undefined.  So it is best to call this at
> + * initialisation.
> + */
> +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
> +                             void *user);
> +
> +/*
> + * This function is for an application which owns SIGCHLD and which
> + * therefore reaps all of the process's children.
> + *
> + * May be called only by an application which has called setmode with
> + * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
> + * by this instance of libxl, returns 0 after doing whatever
> + * processing is appropriate.  Otherwise silently returns
> + * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
> + *
> + * May NOT be called from within a signal handler which might
> + * interrupt any libxl operation.  The application will almost
> + * certainly need to use the self-pipe trick (or a working pselect or
> + * ppoll) to implement this.
> + */
> +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
> +
> +
>  /*
>   * An application which initialises a libxl_ctx in a parent process
>   * and then forks a child which does not quickly exec, must
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> index 4751ef4..aac9598 100644
> --- a/tools/libxl/libxl_fork.c
> +++ b/tools/libxl/libxl_fork.c
> @@ -46,6 +46,12 @@ static int atfork_registered;
>  static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
>      LIBXL_LIST_HEAD_INITIALIZER(carefds);
> 
> +/* non-null iff installed, protected by no_forking */
> +static libxl_ctx *sigchld_owner;
> +static struct sigaction sigchld_saved_action;
> +
> +static void sigchld_removehandler_core(void);
> +
>  static void atfork_lock(void)
>  {
>      int r = pthread_mutex_lock(&no_forking);
> @@ -104,6 +110,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
>      int r;
> 
>      atfork_lock();
> +
>      LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
>          if (cf->fd >= 0) {
>              r = close(cf->fd);
> @@ -115,6 +122,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
>          free(cf);
>      }
>      LIBXL_LIST_INIT(&carefds);
> +
> +    if (sigchld_owner)
> +        sigchld_removehandler_core();
> +
>      atfork_unlock();
>  }
> 
> @@ -138,6 +149,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
>  }
> 
>  /*
> + * Actual child process handling
> + */
> +
> +static void sigchld_handler(int signo)
> +{
> +    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
> +    assert(!e); /* errors are probably EBADF, very bad */
> +}
> +
> +static void sigchld_removehandler_core(void)
> +{
> +    struct sigaction was;
> +    int r;
> +
> +    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
> +    assert(!r);
> +    assert(!(was.sa_flags & SA_SIGINFO));
> +    assert(was.sa_handler == sigchld_handler);
> +    sigchld_owner = 0;
> +}
> +
> +void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
> +{
> +    atfork_lock();
> +    if (sigchld_owner == ctx)
> +        sigchld_removehandler_core();
> +    atfork_unlock();
> +}
> +
> +int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
> +{
> +    int r, rc;
> +
> +    if (ctx->sigchld_selfpipe[0] < 0) {
> +        r = pipe(ctx->sigchld_selfpipe);
> +        if (r) {
> +            ctx->sigchld_selfpipe[0] = -1;
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                             "failed to create sigchld pipe");
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +    }
> +
> +    atfork_lock();
> +    if (sigchld_owner != ctx) {
> +        struct sigaction ours;
> +
> +        assert(!sigchld_owner);
> +        sigchld_owner = ctx;
> +
> +        memset(&ours,0,sizeof(ours));
> +        ours.sa_handler = sigchld_handler;
> +        sigemptyset(&ours.sa_mask);
> +        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
> +        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
> +        assert(!r);
> +
> +        assert(((void)"application must negotiate with libxl about SIGCHLD",
> +                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
> +                (sigchld_saved_action.sa_handler == SIG_DFL ||
> +                 sigchld_saved_action.sa_handler == SIG_IGN)));
> +    }
> +    atfork_unlock();
> +
> +    rc = 0;
> + out:
> +    return rc;
> +}
> +
> +static int chldmode_ours(libxl_ctx *ctx)
> +{
> +    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
> +}
> +
> +int libxl__fork_selfpipe_active(libxl_ctx *ctx)
> +{
> +    /* Returns the fd to read, or -1 */
> +    if (!chldmode_ours(ctx))
> +        return -1;
> +
> +    if (LIBXL_LIST_EMPTY(&ctx->children))
> +        return -1;
> +
> +    return ctx->sigchld_selfpipe[0];
> +}
> +
> +static void perhaps_removehandler(libxl_ctx *ctx)
> +{
> +    if (LIBXL_LIST_EMPTY(&ctx->children) &&
> +        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
> +        libxl__sigchld_removehandler(ctx);
> +}
> +
> +static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
> +{
> +    EGC_GC;
> +    libxl__ev_child *ch;
> +
> +    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
> +        if (ch->pid == pid)
> +            goto found;
> +
> +    /* not found */
> +    return ERROR_UNKNOWN_CHILD;
> +
> + found:
> +    LIBXL_LIST_REMOVE(ch, entry);
> +    ch->pid = -1;
> +    ch->callback(egc, ch, pid, status);
> +
> +    perhaps_removehandler(CTX);
> +
> +    return 0;
> +}
> +
> +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
> +{
> +    EGC_INIT(ctx);
> +    CTX_LOCK;
> +    int rc = childproc_reaped(egc, pid, status);
> +    CTX_UNLOCK;
> +    EGC_FREE;
> +    return rc;
> +}
> +
> +void libxl__fork_selfpipe_woken(libxl__egc *egc)
> +{
> +    /* May make callbacks into the application for child processes.
> +     * ctx must be locked EXACTLY ONCE */
> +    EGC_GC;
> +
> +    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
> +        int status;
> +        pid_t pid = waitpid(-1, &status, WNOHANG);
> +
> +        if (pid == 0) return;
> +
> +        if (pid == -1) {
> +            if (errno == ECHILD) return;
> +            if (errno == EINTR) continue;
> +            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
> +            return;
> +        }
> +
> +        int rc = childproc_reaped(egc, pid, status);
> +
> +        if (rc) {
> +            if (CTX->childproc_hooks->reaped_callback) {
> +                CTX_UNLOCK;
> +                rc = CTX->childproc_hooks->reaped_callback
> +                        (pid, status, CTX->childproc_user);
> +                CTX_LOCK;
> +                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
> +                    char disasterbuf[200];
> +                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
> +                             " libxl_childproc_hooks->reaped_callback"
> +                             " (for pid=%lu, status=%d; error code %d)",
> +                             (unsigned long)pid, status, rc);
> +                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
> +                    return;
> +                }
> +            } else {
> +                rc = ERROR_UNKNOWN_CHILD;
> +            }
> +            if (rc)
> +                libxl_report_child_exitstatus(CTX, XTL_WARN,
> +                                "unknown child", (long)pid, status);
> +        }
> +    }
> +}
> +
> +pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
> +                           libxl__ev_child_callback *death)
> +{
> +    CTX_LOCK;
> +    int rc;
> +
> +    if (chldmode_ours(CTX)) {
> +        rc = libxl__sigchld_installhandler(CTX);
> +        if (rc) goto out;
> +    }
> +
> +    pid_t pid =
> +        CTX->childproc_hooks->fork_replacement
> +        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
> +        : fork();
> +    if (pid == -1) {
> +        LOGE(ERROR, "fork failed");
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (!pid) {
> +        /* woohoo! */
> +        return 0; /* Yes, CTX is left locked in the child. */
> +    }
> +
> +    ch->pid = pid;
> +    ch->callback = death;
> +    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
> +    rc = pid;
> +
> + out:
> +    perhaps_removehandler(CTX);
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
> +                             void *user)
> +{
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    assert(LIBXL_LIST_EMPTY(&CTX->children));
> +
> +    if (!hooks)
> +        hooks = &libxl__childproc_default_hooks;
> +
> +    ctx->childproc_hooks = hooks;
> +    ctx->childproc_user = user;
> +
> +    switch (ctx->childproc_hooks->chldowner) {
> +    case libxl_sigchld_owner_mainloop:
> +    case libxl_sigchld_owner_libxl:
> +        libxl__sigchld_removehandler(ctx);
> +        break;
> +    case libxl_sigchld_owner_libxl_always:
> +        libxl__sigchld_installhandler(ctx);
> +        break;
> +    default:
> +        abort();
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +const libxl_childproc_hooks libxl__childproc_default_hooks = {
> +    libxl_sigchld_owner_libxl, 0, 0
> +};
> +
> +/*
>   * Local variables:
>   * mode: C
>   * c-basic-offset: 4
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1a2139c..a60171c 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
>  libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
> 
> 
> +typedef struct libxl__ev_child libxl__ev_child;
> +typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
> +                                      pid_t pid, int status);
> +struct libxl__ev_child {
> +    /* caller should include this in their own struct */
> +    /* read-only for caller: */
> +    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
> +    libxl__ev_child_callback *callback;
> +    /* remainder is private for libxl__ev_... */
> +    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
> +};
> +
> +
>  /*
>   * evgen structures, which are the state we use for generating
>   * events for the caller.
> @@ -315,10 +328,14 @@ struct libxl__ctx {
> 
>      LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
> 
> -    /* for callers who reap children willy-nilly; caller must only
> -     * set this after libxl_init and before any other call - or
> -     * may leave them untouched */
> +    const libxl_childproc_hooks *childproc_hooks;
> +    void *childproc_user;
> +    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
> +    LIBXL_LIST_HEAD(, libxl__ev_child) children;
> +
> +    /* This is obsolete and must be removed: */
>      int (*waitpid_instead)(pid_t pid, int *status, int flags);
> +
>      libxl_version_info version_info;
>  };
> 
> @@ -566,6 +583,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
> 
> 
>  /*
> + * For making subprocesses.  This is the only permitted mechanism for
> + * code in libxl to do so.
> + *
> + * In the parent, returns the pid, filling in childw_out.
> + * In the child, returns 0.
> + * If it fails, returns a libxl error (all of which are -ve).
> + *
> + * The child should go on to exec (or exit) soon, and should not make
> + * any further libxl event calls in the meantime.
> + *
> + * The parent may signal the child but it must not reap it.  That will
> + * be done by the event machinery.  death may be NULL in which case
> + * the child is still reaped but its death is ignored.
> + *
> + * It is not possible to "deregister" the child death event source.
> + * It will generate exactly one event callback; until then the childw
> + * is Active and may not be reused.
> + */
> +_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
> +                                 libxl__ev_child_callback *death);
> +static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
> +                { childw_out->pid = -1; }
> +static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> +                { return childw_out->pid >= 0; }
> +
> +
> +/*
>   * Other event-handling support provided by the libxl event core to
>   * the rest of libxl.
>   */
> @@ -619,6 +663,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
>   * ctx must be locked. */
>  void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
> 
> +/* Internal to fork and child reaping machinery */
> +extern const libxl_childproc_hooks libxl__childproc_default_hooks;
> +int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
> +void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
> +int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
> +void libxl__fork_selfpipe_woken(libxl__egc *egc);
> +int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
> +int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
> +
> 
>  int libxl__atfork_init(libxl_ctx *ctx);
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:42:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHu4T-0005BI-Ul; Wed, 11 Apr 2012 09:42:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHu4R-0005BD-Tq
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:42:36 +0000
Received: from [85.158.143.35:24617] by server-2.bemta-4.messagelabs.com id
	D5/93-17550-B02558F4; Wed, 11 Apr 2012 09:42:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334137353!4415325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19123 invoked from network); 11 Apr 2012 09:42:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:42:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:42:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:42:33 +0100
Message-ID: <1334137352.5394.92.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:42:32 +0100
In-Reply-To: <1334084885-14474-23-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-23-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/31] libxl: event API: new facilities for
 waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> The current arrangements in libxl for spawning subprocesses have two
> key problems: (i) they make unwarranted (and largely undocumented)
> assumptions about the caller's use of subprocesses, (ii) they aren't
> integrated into the event system and can't be made asynchronous etc.
> 
> So replace them with a new set of facilities.
> 
> Primarily, from the point of view of code inside libxl, this is
> libxl__ev_child_fork which is both (a) a version of fork() and (b) an
> event source which generates a callback when the child dies.
> 
> From the point of view of the application, we fully document our use
> of SIGCHLD.  The application can tell us whether it wants to own
> SIGCHLD or not; if it does, it has to tell us about deaths of our
> children.
> 
> Currently there are no callers in libxl which use these facilities.
> All code in libxl which forks needs to be converted and libxl_fork
> needse to be be abolished.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c          |   17 +++-
>  tools/libxl/libxl.h          |    1 +
>  tools/libxl/libxl_event.c    |   53 +++++++--
>  tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
>  tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   59 +++++++++-
>  6 files changed, 512 insertions(+), 20 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 60dbfdc..42ac89f 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      memset(ctx, 0, sizeof(libxl_ctx));
>      ctx->lg = lg;
> 
> -    /* First initialise pointers (cannot fail) */
> +    /* First initialise pointers etc. (cannot fail) */
> 
>      LIBXL_TAILQ_INIT(&ctx->occurred);
> 
> @@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      LIBXL_TAILQ_INIT(&ctx->death_list);
>      libxl__ev_xswatch_init(&ctx->death_watch);
> 
> +    ctx->childproc_hooks = &libxl__childproc_default_hooks;
> +    ctx->childproc_user = 0;
> +
> +    ctx->sigchld_selfpipe[0] = -1;
> +
>      /* The mutex is special because we can't idempotently destroy it */
> 
>      if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
> @@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
> 
>      discard_events(&ctx->occurred);
> 
> +    /* If we have outstanding children, then the application inherits
> +     * them; we wish the application good luck with understanding
> +     * this if and when it reaps them. */
> +    libxl__sigchld_removehandler(ctx);
> +
> +    if (ctx->sigchld_selfpipe[0] >= 0) {
> +        close(ctx->sigchld_selfpipe[0]);
> +        close(ctx->sigchld_selfpipe[1]);
> +    }
> +
>      pthread_mutex_destroy(&ctx->lock);
> 
>      GC_FREE;
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index edbca53..03e71f6 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -380,6 +380,7 @@ enum {
>      ERROR_NOT_READY = -11,
>      ERROR_OSEVENT_REG_FAIL = -12,
>      ERROR_BUFFERFULL = -13,
> +    ERROR_UNKNOWN_CHILD = -14,
>  };
> 
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 672e3fe..1b7495a 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>                                                                         \
>          REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
>                                                                         \
> +        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
> +        if (selfpipe >= 0)                                             \
> +            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
> +                                                                       \
>      }while(0)
> 
>  #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
> @@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
>                                 int nfds, const struct pollfd *fds,
>                                 struct timeval now)
>  {
> +    /* May make callbacks into the application for child processes.
> +     * ctx must be locked exactly once */
>      EGC_GC;
>      libxl__ev_fd *efd;
> 
> -
>      LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
>          if (!efd->events)
>              continue;
> @@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
>      }
> 
>      if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
> -        char buf[256];
> -        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
> -        if (r < 0)
> -            if (errno != EINTR && errno != EWOULDBLOCK)
> -                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
> +        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
> +        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
> +    }
> +
> +    int selfpipe = libxl__fork_selfpipe_active(CTX);
> +    if (selfpipe >= 0 &&
> +        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
> +        int e = libxl__self_pipe_eatall(selfpipe);
> +        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
> +        libxl__fork_selfpipe_woken(egc);
>      }
> 
>      for (;;) {
> @@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
> 
>  void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
>  {
> +    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
> +    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
> +}
> +
> +int libxl__self_pipe_wakeup(int fd)
> +{
>      static const char buf[1] = "";
> 
>      for (;;) {
> -        int r = write(p->wakeup_pipe[1], buf, 1);
> -        if (r==1) return;
> +        int r = write(fd, buf, 1);
> +        if (r==1) return 0;
>          assert(r==-1);
>          if (errno == EINTR) continue;
> -        if (errno == EWOULDBLOCK) return;
> -        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
> -        return;
> +        if (errno == EWOULDBLOCK) return 0;
> +        assert(errno);
> +        return errno;
> +    }
> +}
> +
> +int libxl__self_pipe_eatall(int fd)
> +{
> +    char buf[256];
> +    for (;;) {
> +        int r = read(fd, buf, sizeof(buf));
> +        if (r == sizeof(buf)) continue;
> +        if (r >= 0) return 0;
> +        assert(r == -1);
> +        if (errno == EINTR) continue;
> +        if (errno == EWOULDBLOCK) return 0;
> +        assert(errno);
> +        return errno;
>      }
>  }
> 
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 2d2196f..713d96d 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
>   * After libxl_ctx_free, all corresponding evgen handles become
>   * invalid and must no longer be passed to evdisable.
>   *
> - * Events enabled with evenable prior to a fork and libxl_ctx_postfork
> - * are no longer generated after the fork/postfork; however the evgen
> - * structures are still valid and must be passed to evdisable if the
> - * memory they use should not be leaked.
> - *
>   * Applications should ensure that they eventually retrieve every
>   * event using libxl_event_check or libxl_event_wait, since events
>   * which occur but are not retreived by the application will be queued
> @@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
>  void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> 
> 
> +/*======================================================================*/
> +
> +/*
> + * Subprocess handling.
> + *
> + * Unfortunately the POSIX interface makes this very awkward.
> + *
> + * There are two possible arrangements for collecting statuses from
> + * wait/waitpid.
> + *
> + * For naive programs:
> + *
> + *     libxl will keep a SIGCHLD handler installed whenever it has an
> + *     active (unreaped) child.  It will reap all children with
> + *     wait(); any children it does not recognise will be passed to
> + *     the application via an optional callback (and will result in
> + *     logged warnings if no callback is provided or the callback
> + *     denies responsibility for the child).
> + *
> + *     libxl may have children whenever:
> + *
> + *       - libxl is performing an operation which can be made
> + *         asynchronous; ie one taking a libxl_asyncop_how, even
> + *         if NULL is passed indicating that the operation is
> + *         synchronous; or
> + *
> + *       - events of any kind are being generated, as requested
> + *         by libxl_evenable_....
> + *
> + *     A multithreaded application which is naive in this sense may
> + *     block SIGCHLD on some of its threads, but there must be at
> + *     least one thread that has SIGCHLD unblocked.  libxl will not
> + *     modify the blocking flag for SIGCHLD (except that it may create
> + *     internal service threads with all signals blocked).
> + *
> + *     A naive program must only have at any one time only
> + *     one libxl context which might have children.
> + *
> + * For programs which run their own children alongside libxl's:
> + *
> + *     A program which does this must call libxl_childproc_setmode.
> + *     There are two options:
> + *
> + *     libxl_sigchld_owner_mainloop:
> + *       The application must install a SIGCHLD handler and reap (at
> + *       least) all of libxl's children and pass their exit status
> + *       to libxl by calling libxl_childproc_exited.
> + *
> + *     libxl_sigchld_owner_libxl_always:
> + *       The application expects libxl to reap all of its children,
> + *       and provides a callback to be notified of their exit
> + *       statues.
> + *
> + * An application which fails to call setmode, or which passes 0 for
> + * hooks, while it uses any libxl operation which might
> + * create or use child processes (see above):
> + *   - Must not have any child processes running.
> + *   - Must not install a SIGCHLD handler.
> + *   - Must not reap any children.
> + */
> +
> +
> +typedef enum {
> +    /* libxl owns SIGCHLD whenever it has a child. */
> +    libxl_sigchld_owner_libxl,
> +
> +    /* Application promises to call libxl_childproc_exited but NOT
> +     * from within a signal handler.  libxl will not itself arrange to
> +     * (un)block or catch SIGCHLD. */
> +    libxl_sigchld_owner_mainloop,
> +
> +    /* libxl owns SIGCHLD all the time, and the application is
> +     * relying on libxl's event loop for reaping its own children. */
> +    libxl_sigchld_owner_libxl_always,
> +} libxl_sigchld_owner;
> +
> +typedef struct {
> +    libxl_sigchld_owner chldowner;
> +
> +    /* All of these are optional: */
> +
> +    /* Called by libxl instead of fork.  Should behave exactly like
> +     * fork, including setting errno etc.  May NOT reenter into libxl.
> +     * Application may use this to discover pids of libxl's children,
> +     * for example.
> +     */
> +    pid_t (*fork_replacement)(void *user);
> +
> +    /* With libxl_sigchld_owner_libxl, called by libxl when it has
> +     * reaped a pid.  (Not permitted with _owner_mainloop.)
> +     *
> +     * Should return 0 if the child was recognised by the application
> +     * (or if the application does not keep those kind of records),
> +     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
> +     * the application's; if it returns another error code it is a
> +     * disaster as described for libxl_event_register_callbacks.
> +     * (libxl will report unexpected children to its error log.)
> +     *
> +     * If not supplied, the application is assumed not to start
> +     * any children of its own.
> +     *
> +     * This function is NOT called from within the signal handler.
> +     * Rather it will be called from inside a libxl's event handling
> +     * code and thus only when libxl is running, for example from
> +     * within libxl_event_wait.  (libxl uses the self-pipe trick
> +     * to implement this.)
> +     *
> +     * childproc_exited_callback may call back into libxl, but it
> +     * is best to avoid making long-running libxl calls as that might
> +     * stall the calling event loop while the nested operation
> +     * completes.
> +     */
> +    int (*reaped_callback)(pid_t, int status, void *user);
> +} libxl_childproc_hooks;
> +
> +/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
> + *
> + * May not be called when libxl might have any child processes, or the
> + * behaviour is undefined.  So it is best to call this at
> + * initialisation.
> + */
> +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
> +                             void *user);
> +
> +/*
> + * This function is for an application which owns SIGCHLD and which
> + * therefore reaps all of the process's children.
> + *
> + * May be called only by an application which has called setmode with
> + * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
> + * by this instance of libxl, returns 0 after doing whatever
> + * processing is appropriate.  Otherwise silently returns
> + * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
> + *
> + * May NOT be called from within a signal handler which might
> + * interrupt any libxl operation.  The application will almost
> + * certainly need to use the self-pipe trick (or a working pselect or
> + * ppoll) to implement this.
> + */
> +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
> +
> +
>  /*
>   * An application which initialises a libxl_ctx in a parent process
>   * and then forks a child which does not quickly exec, must
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> index 4751ef4..aac9598 100644
> --- a/tools/libxl/libxl_fork.c
> +++ b/tools/libxl/libxl_fork.c
> @@ -46,6 +46,12 @@ static int atfork_registered;
>  static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
>      LIBXL_LIST_HEAD_INITIALIZER(carefds);
> 
> +/* non-null iff installed, protected by no_forking */
> +static libxl_ctx *sigchld_owner;
> +static struct sigaction sigchld_saved_action;
> +
> +static void sigchld_removehandler_core(void);
> +
>  static void atfork_lock(void)
>  {
>      int r = pthread_mutex_lock(&no_forking);
> @@ -104,6 +110,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
>      int r;
> 
>      atfork_lock();
> +
>      LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
>          if (cf->fd >= 0) {
>              r = close(cf->fd);
> @@ -115,6 +122,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
>          free(cf);
>      }
>      LIBXL_LIST_INIT(&carefds);
> +
> +    if (sigchld_owner)
> +        sigchld_removehandler_core();
> +
>      atfork_unlock();
>  }
> 
> @@ -138,6 +149,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
>  }
> 
>  /*
> + * Actual child process handling
> + */
> +
> +static void sigchld_handler(int signo)
> +{
> +    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
> +    assert(!e); /* errors are probably EBADF, very bad */
> +}
> +
> +static void sigchld_removehandler_core(void)
> +{
> +    struct sigaction was;
> +    int r;
> +
> +    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
> +    assert(!r);
> +    assert(!(was.sa_flags & SA_SIGINFO));
> +    assert(was.sa_handler == sigchld_handler);
> +    sigchld_owner = 0;
> +}
> +
> +void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
> +{
> +    atfork_lock();
> +    if (sigchld_owner == ctx)
> +        sigchld_removehandler_core();
> +    atfork_unlock();
> +}
> +
> +int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
> +{
> +    int r, rc;
> +
> +    if (ctx->sigchld_selfpipe[0] < 0) {
> +        r = pipe(ctx->sigchld_selfpipe);
> +        if (r) {
> +            ctx->sigchld_selfpipe[0] = -1;
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                             "failed to create sigchld pipe");
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +    }
> +
> +    atfork_lock();
> +    if (sigchld_owner != ctx) {
> +        struct sigaction ours;
> +
> +        assert(!sigchld_owner);
> +        sigchld_owner = ctx;
> +
> +        memset(&ours,0,sizeof(ours));
> +        ours.sa_handler = sigchld_handler;
> +        sigemptyset(&ours.sa_mask);
> +        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
> +        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
> +        assert(!r);
> +
> +        assert(((void)"application must negotiate with libxl about SIGCHLD",
> +                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
> +                (sigchld_saved_action.sa_handler == SIG_DFL ||
> +                 sigchld_saved_action.sa_handler == SIG_IGN)));
> +    }
> +    atfork_unlock();
> +
> +    rc = 0;
> + out:
> +    return rc;
> +}
> +
> +static int chldmode_ours(libxl_ctx *ctx)
> +{
> +    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
> +}
> +
> +int libxl__fork_selfpipe_active(libxl_ctx *ctx)
> +{
> +    /* Returns the fd to read, or -1 */
> +    if (!chldmode_ours(ctx))
> +        return -1;
> +
> +    if (LIBXL_LIST_EMPTY(&ctx->children))
> +        return -1;
> +
> +    return ctx->sigchld_selfpipe[0];
> +}
> +
> +static void perhaps_removehandler(libxl_ctx *ctx)
> +{
> +    if (LIBXL_LIST_EMPTY(&ctx->children) &&
> +        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
> +        libxl__sigchld_removehandler(ctx);
> +}
> +
> +static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
> +{
> +    EGC_GC;
> +    libxl__ev_child *ch;
> +
> +    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
> +        if (ch->pid == pid)
> +            goto found;
> +
> +    /* not found */
> +    return ERROR_UNKNOWN_CHILD;
> +
> + found:
> +    LIBXL_LIST_REMOVE(ch, entry);
> +    ch->pid = -1;
> +    ch->callback(egc, ch, pid, status);
> +
> +    perhaps_removehandler(CTX);
> +
> +    return 0;
> +}
> +
> +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
> +{
> +    EGC_INIT(ctx);
> +    CTX_LOCK;
> +    int rc = childproc_reaped(egc, pid, status);
> +    CTX_UNLOCK;
> +    EGC_FREE;
> +    return rc;
> +}
> +
> +void libxl__fork_selfpipe_woken(libxl__egc *egc)
> +{
> +    /* May make callbacks into the application for child processes.
> +     * ctx must be locked EXACTLY ONCE */
> +    EGC_GC;
> +
> +    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
> +        int status;
> +        pid_t pid = waitpid(-1, &status, WNOHANG);
> +
> +        if (pid == 0) return;
> +
> +        if (pid == -1) {
> +            if (errno == ECHILD) return;
> +            if (errno == EINTR) continue;
> +            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
> +            return;
> +        }
> +
> +        int rc = childproc_reaped(egc, pid, status);
> +
> +        if (rc) {
> +            if (CTX->childproc_hooks->reaped_callback) {
> +                CTX_UNLOCK;
> +                rc = CTX->childproc_hooks->reaped_callback
> +                        (pid, status, CTX->childproc_user);
> +                CTX_LOCK;
> +                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
> +                    char disasterbuf[200];
> +                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
> +                             " libxl_childproc_hooks->reaped_callback"
> +                             " (for pid=%lu, status=%d; error code %d)",
> +                             (unsigned long)pid, status, rc);
> +                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
> +                    return;
> +                }
> +            } else {
> +                rc = ERROR_UNKNOWN_CHILD;
> +            }
> +            if (rc)
> +                libxl_report_child_exitstatus(CTX, XTL_WARN,
> +                                "unknown child", (long)pid, status);
> +        }
> +    }
> +}
> +
> +pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
> +                           libxl__ev_child_callback *death)
> +{
> +    CTX_LOCK;
> +    int rc;
> +
> +    if (chldmode_ours(CTX)) {
> +        rc = libxl__sigchld_installhandler(CTX);
> +        if (rc) goto out;
> +    }
> +
> +    pid_t pid =
> +        CTX->childproc_hooks->fork_replacement
> +        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
> +        : fork();
> +    if (pid == -1) {
> +        LOGE(ERROR, "fork failed");
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (!pid) {
> +        /* woohoo! */
> +        return 0; /* Yes, CTX is left locked in the child. */
> +    }
> +
> +    ch->pid = pid;
> +    ch->callback = death;
> +    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
> +    rc = pid;
> +
> + out:
> +    perhaps_removehandler(CTX);
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
> +                             void *user)
> +{
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    assert(LIBXL_LIST_EMPTY(&CTX->children));
> +
> +    if (!hooks)
> +        hooks = &libxl__childproc_default_hooks;
> +
> +    ctx->childproc_hooks = hooks;
> +    ctx->childproc_user = user;
> +
> +    switch (ctx->childproc_hooks->chldowner) {
> +    case libxl_sigchld_owner_mainloop:
> +    case libxl_sigchld_owner_libxl:
> +        libxl__sigchld_removehandler(ctx);
> +        break;
> +    case libxl_sigchld_owner_libxl_always:
> +        libxl__sigchld_installhandler(ctx);
> +        break;
> +    default:
> +        abort();
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +const libxl_childproc_hooks libxl__childproc_default_hooks = {
> +    libxl_sigchld_owner_libxl, 0, 0
> +};
> +
> +/*
>   * Local variables:
>   * mode: C
>   * c-basic-offset: 4
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1a2139c..a60171c 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
>  libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
> 
> 
> +typedef struct libxl__ev_child libxl__ev_child;
> +typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
> +                                      pid_t pid, int status);
> +struct libxl__ev_child {
> +    /* caller should include this in their own struct */
> +    /* read-only for caller: */
> +    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
> +    libxl__ev_child_callback *callback;
> +    /* remainder is private for libxl__ev_... */
> +    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
> +};
> +
> +
>  /*
>   * evgen structures, which are the state we use for generating
>   * events for the caller.
> @@ -315,10 +328,14 @@ struct libxl__ctx {
> 
>      LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
> 
> -    /* for callers who reap children willy-nilly; caller must only
> -     * set this after libxl_init and before any other call - or
> -     * may leave them untouched */
> +    const libxl_childproc_hooks *childproc_hooks;
> +    void *childproc_user;
> +    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
> +    LIBXL_LIST_HEAD(, libxl__ev_child) children;
> +
> +    /* This is obsolete and must be removed: */
>      int (*waitpid_instead)(pid_t pid, int *status, int flags);
> +
>      libxl_version_info version_info;
>  };
> 
> @@ -566,6 +583,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
> 
> 
>  /*
> + * For making subprocesses.  This is the only permitted mechanism for
> + * code in libxl to do so.
> + *
> + * In the parent, returns the pid, filling in childw_out.
> + * In the child, returns 0.
> + * If it fails, returns a libxl error (all of which are -ve).
> + *
> + * The child should go on to exec (or exit) soon, and should not make
> + * any further libxl event calls in the meantime.
> + *
> + * The parent may signal the child but it must not reap it.  That will
> + * be done by the event machinery.  death may be NULL in which case
> + * the child is still reaped but its death is ignored.
> + *
> + * It is not possible to "deregister" the child death event source.
> + * It will generate exactly one event callback; until then the childw
> + * is Active and may not be reused.
> + */
> +_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
> +                                 libxl__ev_child_callback *death);
> +static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
> +                { childw_out->pid = -1; }
> +static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> +                { return childw_out->pid >= 0; }
> +
> +
> +/*
>   * Other event-handling support provided by the libxl event core to
>   * the rest of libxl.
>   */
> @@ -619,6 +663,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
>   * ctx must be locked. */
>  void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
> 
> +/* Internal to fork and child reaping machinery */
> +extern const libxl_childproc_hooks libxl__childproc_default_hooks;
> +int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
> +void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
> +int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
> +void libxl__fork_selfpipe_woken(libxl__egc *egc);
> +int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
> +int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
> +
> 
>  int libxl__atfork_init(libxl_ctx *ctx);
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:54:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:54:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuFx-0005NO-Hs; Wed, 11 Apr 2012 09:54:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuFv-0005NJ-E8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:54:27 +0000
Received: from [85.158.139.83:31090] by server-3.bemta-5.messagelabs.com id
	C6/FB-25237-2D4558F4; Wed, 11 Apr 2012 09:54:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334138066!22638791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16511 invoked from network); 11 Apr 2012 09:54:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:54:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:54:24 +0100
Message-ID: <1334138063.5394.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:54:23 +0100
In-Reply-To: <1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> These utility functions cope with EINTR AND ENOENT, do error logging,
> and we provide a recursive version to delete whole directory trees.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_internal.h |    7 ++++
>  tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index a60171c..8e47213 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
>   * string. (similar to a gc'd dirname(3)). */
>  _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
>  
> +/* Each of these logs errors and returns a libxl error code.
> + * They do not mind if path is already removed.
> + * For _file, path must not be a directory; for _directory it must be. */
> +_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
> +_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
> +_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
> +
>  _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
>  
>  _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 0cbd85e..c9157a6 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
>  READ_WRITE_EXACTLY(read, 1, /* */)
>  READ_WRITE_EXACTLY(write, 0, const)
>  
> +int libxl__remove_file(libxl__gc *gc, const char *path)
> +{
> +    for (;;) {
> +        int r = unlink(path);
> +        if (!r) return 0;
> +        if (errno == ENOENT) return 0;
> +        if (errno == EINTR) continue;
> +        LOGE(ERROR, "failed to remove file %s", path);
> +        return ERROR_FAIL;
> +     }
> +}
> +
> +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
> +{
> +    for (;;) {
> +        int r = rmdir(path);
> +        if (!r) return 0;
> +        if (errno == ENOENT) return 0;
> +        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
> +        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
> +        if (errno == EINTR) continue;

starting to look a bit like a switch statement...

> +        LOGE(ERROR, "failed to remove %s", path);
> +        return ERROR_FAIL;
> +     }
> +}
> +
> +int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
> +{
> +    int rc = 0;
> +    DIR *d = 0;
> +
> +    d = opendir(dirpath);
> +    if (!d) {
> +        if (errno == ENOENT)
> +            goto out;
> +
> +        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    size_t need = offsetof(struct dirent, d_name) +
> +        pathconf(dirpath, _PC_NAME_MAX) + 1;
> +    struct dirent *de_buf = libxl__zalloc(gc, need);
> +    struct dirent *de;
> +
> +    for (;;) {
> +        int r = readdir_r(d, de_buf, &de);
> +        if (r) {
> +            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
> +            rc = ERROR_FAIL;
> +            break;
> +        }
> +        if (!de)
> +            break;
> +
> +        if (!strcmp(de->d_name, ".") ||
> +            !strcmp(de->d_name, ".."))
> +            continue;
> +
> +        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
> +        if (libxl__remove_file_or_directory(gc, subpath))
> +            rc = ERROR_FAIL;
> +    }
> +
> +    for (;;) {
> +        int r = rmdir(dirpath);
> +        if (!r) break;
> +        if (errno == ENOENT) return 0;

This misses the closedir() at out?

> +        if (errno == EINTR) continue;
> +        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
> +        rc = ERROR_FAIL;
> +    }
> +
> + out:
> +    if (d) closedir(d);
> +
> +    return rc;
> +}
>  
>  pid_t libxl_fork(libxl_ctx *ctx)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:54:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:54:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuFx-0005NO-Hs; Wed, 11 Apr 2012 09:54:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuFv-0005NJ-E8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:54:27 +0000
Received: from [85.158.139.83:31090] by server-3.bemta-5.messagelabs.com id
	C6/FB-25237-2D4558F4; Wed, 11 Apr 2012 09:54:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334138066!22638791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16511 invoked from network); 11 Apr 2012 09:54:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:54:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:54:24 +0100
Message-ID: <1334138063.5394.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:54:23 +0100
In-Reply-To: <1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> These utility functions cope with EINTR AND ENOENT, do error logging,
> and we provide a recursive version to delete whole directory trees.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_internal.h |    7 ++++
>  tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index a60171c..8e47213 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
>   * string. (similar to a gc'd dirname(3)). */
>  _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
>  
> +/* Each of these logs errors and returns a libxl error code.
> + * They do not mind if path is already removed.
> + * For _file, path must not be a directory; for _directory it must be. */
> +_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
> +_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
> +_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
> +
>  _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
>  
>  _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 0cbd85e..c9157a6 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
>  READ_WRITE_EXACTLY(read, 1, /* */)
>  READ_WRITE_EXACTLY(write, 0, const)
>  
> +int libxl__remove_file(libxl__gc *gc, const char *path)
> +{
> +    for (;;) {
> +        int r = unlink(path);
> +        if (!r) return 0;
> +        if (errno == ENOENT) return 0;
> +        if (errno == EINTR) continue;
> +        LOGE(ERROR, "failed to remove file %s", path);
> +        return ERROR_FAIL;
> +     }
> +}
> +
> +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
> +{
> +    for (;;) {
> +        int r = rmdir(path);
> +        if (!r) return 0;
> +        if (errno == ENOENT) return 0;
> +        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
> +        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
> +        if (errno == EINTR) continue;

starting to look a bit like a switch statement...

> +        LOGE(ERROR, "failed to remove %s", path);
> +        return ERROR_FAIL;
> +     }
> +}
> +
> +int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
> +{
> +    int rc = 0;
> +    DIR *d = 0;
> +
> +    d = opendir(dirpath);
> +    if (!d) {
> +        if (errno == ENOENT)
> +            goto out;
> +
> +        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    size_t need = offsetof(struct dirent, d_name) +
> +        pathconf(dirpath, _PC_NAME_MAX) + 1;
> +    struct dirent *de_buf = libxl__zalloc(gc, need);
> +    struct dirent *de;
> +
> +    for (;;) {
> +        int r = readdir_r(d, de_buf, &de);
> +        if (r) {
> +            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
> +            rc = ERROR_FAIL;
> +            break;
> +        }
> +        if (!de)
> +            break;
> +
> +        if (!strcmp(de->d_name, ".") ||
> +            !strcmp(de->d_name, ".."))
> +            continue;
> +
> +        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
> +        if (libxl__remove_file_or_directory(gc, subpath))
> +            rc = ERROR_FAIL;
> +    }
> +
> +    for (;;) {
> +        int r = rmdir(dirpath);
> +        if (!r) break;
> +        if (errno == ENOENT) return 0;

This misses the closedir() at out?

> +        if (errno == EINTR) continue;
> +        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
> +        rc = ERROR_FAIL;
> +    }
> +
> + out:
> +    if (d) closedir(d);
> +
> +    return rc;
> +}
>  
>  pid_t libxl_fork(libxl_ctx *ctx)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:57:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuIz-0005Tg-6M; Wed, 11 Apr 2012 09:57:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuIx-0005Tb-52
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:57:35 +0000
Received: from [193.109.254.147:53674] by server-1.bemta-14.messagelabs.com id
	8F/0E-29372-E85558F4; Wed, 11 Apr 2012 09:57:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334138253!4060191!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15834 invoked from network); 11 Apr 2012 09:57:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:57:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:57:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:57:33 +0100
Message-ID: <1334138252.5394.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:57:32 +0100
In-Reply-To: <1334084885-14474-27-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-27-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 26/31] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> do_domain_create called libxl__domain_create_info_setdefault twice.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> ---
>  tools/libxl/libxl_create.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..3675afe 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>      ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
>      if (ret) goto error_out;
>  
> -    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
> -    if (ret) goto error_out;
> -
>      ret = libxl__domain_make(gc, &d_config->c_info, &domid);
>      if (ret) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:57:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuIz-0005Tg-6M; Wed, 11 Apr 2012 09:57:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuIx-0005Tb-52
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:57:35 +0000
Received: from [193.109.254.147:53674] by server-1.bemta-14.messagelabs.com id
	8F/0E-29372-E85558F4; Wed, 11 Apr 2012 09:57:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334138253!4060191!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15834 invoked from network); 11 Apr 2012 09:57:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:57:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:57:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:57:33 +0100
Message-ID: <1334138252.5394.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:57:32 +0100
In-Reply-To: <1334084885-14474-27-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-27-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 26/31] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> do_domain_create called libxl__domain_create_info_setdefault twice.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> ---
>  tools/libxl/libxl_create.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..3675afe 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>      ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
>      if (ret) goto error_out;
>  
> -    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
> -    if (ret) goto error_out;
> -
>      ret = libxl__domain_make(gc, &d_config->c_info, &domid);
>      if (ret) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:58:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuK2-0005Yy-KY; Wed, 11 Apr 2012 09:58:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuK1-0005Yo-1c
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:58:41 +0000
Received: from [85.158.138.51:13190] by server-6.bemta-3.messagelabs.com id
	24/74-05145-0D5558F4; Wed, 11 Apr 2012 09:58:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334138319!21685234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25658 invoked from network); 11 Apr 2012 09:58:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:58:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:58:38 +0100
Message-ID: <1334138317.5394.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:58:37 +0100
In-Reply-To: <1334084885-14474-31-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-31-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 30/31] libxl: make libxl_create_logfile
 const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_utils.c |    2 +-
>  tools/libxl/libxl_utils.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index dc25ab0..8eacebf 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
>      return 0;
>  }
>  
> -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
> +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
>  {
>      GC_INIT(ctx);
>      struct stat stat_buf;
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index ca53a8a..2b47622 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
>  char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
>  int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
>  int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
> -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
> +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
>  int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
>  
>  int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 09:58:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 09:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuK2-0005Yy-KY; Wed, 11 Apr 2012 09:58:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuK1-0005Yo-1c
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 09:58:41 +0000
Received: from [85.158.138.51:13190] by server-6.bemta-3.messagelabs.com id
	24/74-05145-0D5558F4; Wed, 11 Apr 2012 09:58:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334138319!21685234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25658 invoked from network); 11 Apr 2012 09:58:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 09:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:58:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 10:58:38 +0100
Message-ID: <1334138317.5394.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 10:58:37 +0100
In-Reply-To: <1334084885-14474-31-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-31-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 30/31] libxl: make libxl_create_logfile
 const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_utils.c |    2 +-
>  tools/libxl/libxl_utils.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index dc25ab0..8eacebf 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
>      return 0;
>  }
>  
> -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
> +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
>  {
>      GC_INIT(ctx);
>      struct stat stat_buf;
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index ca53a8a..2b47622 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
>  char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
>  int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
>  int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
> -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
> +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
>  int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
>  
>  int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:00:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuLV-0005kC-3f; Wed, 11 Apr 2012 10:00:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuLR-0005js-Ki
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:00:12 +0000
Received: from [85.158.139.83:38837] by server-12.bemta-5.messagelabs.com id
	54/20-05587-826558F4; Wed, 11 Apr 2012 10:00:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334138407!23309593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2207 invoked from network); 11 Apr 2012 10:00:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:00:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:00:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:00:07 +0100
Message-ID: <1334138406.5394.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:00:06 +0100
In-Reply-To: <1334084885-14474-32-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-32-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/31] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> This involves adding a new log feature to libxl__datacopier, and then
> using it.
> 
> If the bootloader exits nonzero we print the log filename in a log
> message from libxl.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

This has been an annoying omission for ages, thanks!

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_aoutils.c    |   10 ++++++++++
>  tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h   |    3 ++-
>  3 files changed, 36 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index b33abe4..1b17c84 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
> @@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
>              libxl__ev_fd_deregister(gc, &dc->toread);
>              break;
>          }
> +        if (dc->log) {
> +            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
> +            if (wrote != r) {
> +                assert(ferror(dc->log));
> +                assert(errno);
> +                LOGE(ERROR, "error logging %s", dc->copywhat);
> +                datacopier_callback(egc, dc, 0, errno);
> +                return;
> +            }
> +        }
>          buf->used += r;
>          dc->used += r;
>          assert(buf->used <= sizeof(buf->buf));
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index 1361117..47ced8a 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -234,6 +234,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
>          libxl__carefd_close(bl->ptys[i].master);
>          libxl__carefd_close(bl->ptys[i].slave);
>      }
> +    if (bl->display.log) {
> +        fclose(bl->display.log);
> +        bl->display.log = NULL;
> +    }
>  }
>  
>  static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
> @@ -256,6 +260,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
>  {
>      STATE_AO_GC(bl);
>      libxl_domain_build_info *info = bl->info;
> +    uint32_t domid = bl->domid;
> +    char *logfile_tmp = NULL;
>      int rc, r;
>  
>      libxl__bootloader_init(bl);
> @@ -268,6 +274,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
>  
>      bootloader_setpaths(gc, bl);
>  
> +    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
> +    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
> +    if (rc) goto out;
> +
> +    /* Transfer ownership of log filename to bl and the gc */
> +    bl->logfile = logfile_tmp;
> +    libxl__ptr_add(gc, logfile_tmp);
> +    logfile_tmp = NULL;
> +
> +    bl->display.log = fopen(bl->logfile, "a");
> +    if (!bl->display.log) {
> +        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
>      for (;;) {
>          r = mkdir(bl->outputdir, 0600);
>          if (!r) break;
> @@ -305,6 +327,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
>      return;
>  
>   out:
> +    free(logfile_tmp);
>      assert(rc);
>      bootloader_callback(egc, bl, rc);
>  }
> @@ -462,6 +485,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
>      libxl__datacopier_kill(&bl->display);
>  
>      if (status) {
> +        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
>          libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
>                                        pid, status);
>          rc = ERROR_FAIL;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index fd96b31..c846144 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1485,6 +1485,7 @@ struct libxl__datacopier_state {
>      int readfd, writefd;
>      ssize_t maxsz;
>      const char *copywhat, *readwhat, *writewhat; /* for error msgs */
> +    FILE *log; /* gets a copy of everything */
>      libxl__datacopier_callback *callback;
>      /* remaining fields are private to datacopier */
>      libxl__ev_fd toread, towrite;
> @@ -1547,7 +1548,7 @@ struct libxl__bootloader_state {
>      libxl_device_disk *disk;
>      uint32_t domid;
>      /* private to libxl__run_bootloader */
> -    char *outputpath, *outputdir;
> +    char *outputpath, *outputdir, *logfile;
>      char *diskpath; /* not from gc, represents actually attached disk */
>      libxl__openpty_state openpty;
>      libxl__openpty_result ptys[2];  /* [0] is for bootloader */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:00:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuLV-0005kC-3f; Wed, 11 Apr 2012 10:00:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHuLR-0005js-Ki
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:00:12 +0000
Received: from [85.158.139.83:38837] by server-12.bemta-5.messagelabs.com id
	54/20-05587-826558F4; Wed, 11 Apr 2012 10:00:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334138407!23309593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2207 invoked from network); 11 Apr 2012 10:00:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:00:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:00:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:00:07 +0100
Message-ID: <1334138406.5394.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:00:06 +0100
In-Reply-To: <1334084885-14474-32-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-32-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/31] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> This involves adding a new log feature to libxl__datacopier, and then
> using it.
> 
> If the bootloader exits nonzero we print the log filename in a log
> message from libxl.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

This has been an annoying omission for ages, thanks!

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_aoutils.c    |   10 ++++++++++
>  tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h   |    3 ++-
>  3 files changed, 36 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index b33abe4..1b17c84 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
> @@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
>              libxl__ev_fd_deregister(gc, &dc->toread);
>              break;
>          }
> +        if (dc->log) {
> +            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
> +            if (wrote != r) {
> +                assert(ferror(dc->log));
> +                assert(errno);
> +                LOGE(ERROR, "error logging %s", dc->copywhat);
> +                datacopier_callback(egc, dc, 0, errno);
> +                return;
> +            }
> +        }
>          buf->used += r;
>          dc->used += r;
>          assert(buf->used <= sizeof(buf->buf));
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index 1361117..47ced8a 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -234,6 +234,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
>          libxl__carefd_close(bl->ptys[i].master);
>          libxl__carefd_close(bl->ptys[i].slave);
>      }
> +    if (bl->display.log) {
> +        fclose(bl->display.log);
> +        bl->display.log = NULL;
> +    }
>  }
>  
>  static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
> @@ -256,6 +260,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
>  {
>      STATE_AO_GC(bl);
>      libxl_domain_build_info *info = bl->info;
> +    uint32_t domid = bl->domid;
> +    char *logfile_tmp = NULL;
>      int rc, r;
>  
>      libxl__bootloader_init(bl);
> @@ -268,6 +274,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
>  
>      bootloader_setpaths(gc, bl);
>  
> +    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
> +    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
> +    if (rc) goto out;
> +
> +    /* Transfer ownership of log filename to bl and the gc */
> +    bl->logfile = logfile_tmp;
> +    libxl__ptr_add(gc, logfile_tmp);
> +    logfile_tmp = NULL;
> +
> +    bl->display.log = fopen(bl->logfile, "a");
> +    if (!bl->display.log) {
> +        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
>      for (;;) {
>          r = mkdir(bl->outputdir, 0600);
>          if (!r) break;
> @@ -305,6 +327,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
>      return;
>  
>   out:
> +    free(logfile_tmp);
>      assert(rc);
>      bootloader_callback(egc, bl, rc);
>  }
> @@ -462,6 +485,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
>      libxl__datacopier_kill(&bl->display);
>  
>      if (status) {
> +        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
>          libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
>                                        pid, status);
>          rc = ERROR_FAIL;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index fd96b31..c846144 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1485,6 +1485,7 @@ struct libxl__datacopier_state {
>      int readfd, writefd;
>      ssize_t maxsz;
>      const char *copywhat, *readwhat, *writewhat; /* for error msgs */
> +    FILE *log; /* gets a copy of everything */
>      libxl__datacopier_callback *callback;
>      /* remaining fields are private to datacopier */
>      libxl__ev_fd toread, towrite;
> @@ -1547,7 +1548,7 @@ struct libxl__bootloader_state {
>      libxl_device_disk *disk;
>      uint32_t domid;
>      /* private to libxl__run_bootloader */
> -    char *outputpath, *outputdir;
> +    char *outputpath, *outputdir, *logfile;
>      char *diskpath; /* not from gc, represents actually attached disk */
>      libxl__openpty_state openpty;
>      libxl__openpty_result ptys[2];  /* [0] is for bootloader */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuLo-0005mM-Gf; Wed, 11 Apr 2012 10:00:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SHuLm-0005m5-M5
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:00:30 +0000
Received: from [85.158.139.83:30144] by server-4.bemta-5.messagelabs.com id
	B3/DB-10788-D36558F4; Wed, 11 Apr 2012 10:00:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334138428!12038461!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTcxMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTcxMDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18340 invoked from network); 11 Apr 2012 10:00:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Apr 2012 10:00:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1334138428; l=305;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WZXs6xy2GKa8Y5PX2b6wFXx1UTc=;
	b=FX4olJcWBkIlFzoBPFD6qdlXu+Op9lOxqeh7FR5Ny8i8SSHGc+w2RUpVciKv3CDV+87
	jMZF8q3Z/JPGV9o5D/f/RhO6nscu9Ufmi/Enve2rb+JrMimBPZLbJ9++CxyJIPKf3ErNl
	hI43rjPzuZ0jk2OTFNSNDpBHCUqPipg6Ers=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIiy0ME0l4
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-065-200.pools.arcor-ip.net [88.65.65.200])
	by smtp.strato.de (klopstock mo1) (RZmta 28.1 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e00591o3B5jgnF ;
	Wed, 11 Apr 2012 12:00:28 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0D95018637; Wed, 11 Apr 2012 12:00:26 +0200 (CEST)
Date: Wed, 11 Apr 2012 12:00:26 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120411100026.GA12203@aepfle.de>
References: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] autoconf: use python-config when present,
 if not switch to distutils
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, Roger Pau Monne wrote:

> Use python-config utility when possible, and if it is not present switch to
> distutils.
> 
> Should fix the bug reported by Olaf Hering on SuSE.
> 
> Rerun autoconf after applying the patch.

Yes, this fixes the build on openSuSE 11.4 and later.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuLo-0005mM-Gf; Wed, 11 Apr 2012 10:00:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SHuLm-0005m5-M5
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:00:30 +0000
Received: from [85.158.139.83:30144] by server-4.bemta-5.messagelabs.com id
	B3/DB-10788-D36558F4; Wed, 11 Apr 2012 10:00:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334138428!12038461!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTcxMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTcxMDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18340 invoked from network); 11 Apr 2012 10:00:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Apr 2012 10:00:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1334138428; l=305;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WZXs6xy2GKa8Y5PX2b6wFXx1UTc=;
	b=FX4olJcWBkIlFzoBPFD6qdlXu+Op9lOxqeh7FR5Ny8i8SSHGc+w2RUpVciKv3CDV+87
	jMZF8q3Z/JPGV9o5D/f/RhO6nscu9Ufmi/Enve2rb+JrMimBPZLbJ9++CxyJIPKf3ErNl
	hI43rjPzuZ0jk2OTFNSNDpBHCUqPipg6Ers=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIiy0ME0l4
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-065-200.pools.arcor-ip.net [88.65.65.200])
	by smtp.strato.de (klopstock mo1) (RZmta 28.1 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e00591o3B5jgnF ;
	Wed, 11 Apr 2012 12:00:28 +0200 (MEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0D95018637; Wed, 11 Apr 2012 12:00:26 +0200 (CEST)
Date: Wed, 11 Apr 2012 12:00:26 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120411100026.GA12203@aepfle.de>
References: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] autoconf: use python-config when present,
 if not switch to distutils
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, Roger Pau Monne wrote:

> Use python-config utility when possible, and if it is not present switch to
> distutils.
> 
> Should fix the bug reported by Olaf Hering on SuSE.
> 
> Rerun autoconf after applying the patch.

Yes, this fixes the build on openSuSE 11.4 and later.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuNY-0005ym-19; Wed, 11 Apr 2012 10:02:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bvanassche@acm.org>) id 1SHuNW-0005ya-N1
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:02:18 +0000
Received: from [85.158.143.99:20481] by server-2.bemta-4.messagelabs.com id
	85/2B-17550-AA6558F4; Wed, 11 Apr 2012 10:02:18 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334138537!19778132!1
X-Originating-IP: [212.53.5.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjUzLjUuMjE4ID0+IDE4OTc1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32486 invoked from network); 11 Apr 2012 10:02:17 -0000
Received: from relay03ant.iops.be (HELO relay03ant.iops.be) (212.53.5.218)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Apr 2012 10:02:17 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by relay03ant.iops.be (Postfix) with ESMTP id C2F196BF0012;
	Wed, 11 Apr 2012 12:02:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iops.be; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:references:subject:subject:mime-version:user-agent:from:from
	:date:date:message-id:received:received; s=scooby; i=
	postadmin@iops.be; t=1334138531; bh=7PzS+aE+4maj9PBngsL6YyCyjHhZ
	9H84gFUbHVhuoNw=; b=xSC7ZLiobr4b7VacSAxQPnz7GzGSOpETgW4COW0ToYax
	Pm1M3Q5th8GJcrBtADsMH7rmCQloLk1zhTT8MI8V1fPT7j98A9q+A0A0VQ9uK68Y
	xA+DiBHFP6n9uJTLR8dACfc/XcYa5UMhuy7gTucOGB0mmISmsMJYpABQ7traf4Y=
X-Virus-Scanned: amavisd-new at iops.be
Received: from relay03ant.iops.be ([127.0.0.1])
	by localhost (bdell028.dcn.iops.be [127.0.0.1]) (amavisd-new,
	port 10026)
	with LMTP id 2tqXZhZ9wbUN; Wed, 11 Apr 2012 12:02:11 +0200 (CEST)
Received: from [192.168.3.246] (cust-67-22-110-94.dyn.as47377.net
	[94.110.22.67])
	by relay03ant.iops.be (Postfix) with ESMTP id C76B86BF012D;
	Wed, 11 Apr 2012 12:02:08 +0200 (CEST)
Message-ID: <4F85569F.1070806@acm.org>
Date: Wed, 11 Apr 2012 10:02:07 +0000
From: Bart Van Assche <bvanassche@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<4F8455EE.8010709@acm.org>
	<1334073004.5394.59.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334073004.5394.59.camel@zakaz.uk.xensource.com>
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/12 15:50, Ian Campbell wrote:

> On Tue, 2012-04-10 at 16:46 +0100, Bart Van Assche wrote:
>> Great to see v4 of this patch series. But which kernel version has this
>> patch series been based on ? I've tried to apply this series on 3.4-rc2
> 
> It's based on net-next/master. Specifically commit de8856d2c11f.


Thanks, that information allowed me to apply the patch series and to
test it with kernel 3.4-rc2 and iSCSI target code. The test ran fine.

The failure to apply this patch series on 3.4-rc2 I had reported turned
out to be an easy to resolve merge conflict:

+ static int ceph_tcp_sendpage(struct socket *sock, struct page *page,
+ 		     int offset, size_t size, int more)
+ {
+ 	int flags = MSG_DONTWAIT | MSG_NOSIGNAL | (more ? MSG_MORE : MSG_EOR);
+ 	int ret;
+ 
 -	ret = kernel_sendpage(sock, page, offset, size, flags);
++	ret = kernel_sendpage(sock, page, NULL, offset, size, flags);
+ 	if (ret == -EAGAIN)
+ 		ret = 0;
+ 
+ 	return ret;
+ }
+ 

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuNY-0005ym-19; Wed, 11 Apr 2012 10:02:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bvanassche@acm.org>) id 1SHuNW-0005ya-N1
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:02:18 +0000
Received: from [85.158.143.99:20481] by server-2.bemta-4.messagelabs.com id
	85/2B-17550-AA6558F4; Wed, 11 Apr 2012 10:02:18 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334138537!19778132!1
X-Originating-IP: [212.53.5.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjUzLjUuMjE4ID0+IDE4OTc1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32486 invoked from network); 11 Apr 2012 10:02:17 -0000
Received: from relay03ant.iops.be (HELO relay03ant.iops.be) (212.53.5.218)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Apr 2012 10:02:17 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by relay03ant.iops.be (Postfix) with ESMTP id C2F196BF0012;
	Wed, 11 Apr 2012 12:02:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iops.be; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:references:subject:subject:mime-version:user-agent:from:from
	:date:date:message-id:received:received; s=scooby; i=
	postadmin@iops.be; t=1334138531; bh=7PzS+aE+4maj9PBngsL6YyCyjHhZ
	9H84gFUbHVhuoNw=; b=xSC7ZLiobr4b7VacSAxQPnz7GzGSOpETgW4COW0ToYax
	Pm1M3Q5th8GJcrBtADsMH7rmCQloLk1zhTT8MI8V1fPT7j98A9q+A0A0VQ9uK68Y
	xA+DiBHFP6n9uJTLR8dACfc/XcYa5UMhuy7gTucOGB0mmISmsMJYpABQ7traf4Y=
X-Virus-Scanned: amavisd-new at iops.be
Received: from relay03ant.iops.be ([127.0.0.1])
	by localhost (bdell028.dcn.iops.be [127.0.0.1]) (amavisd-new,
	port 10026)
	with LMTP id 2tqXZhZ9wbUN; Wed, 11 Apr 2012 12:02:11 +0200 (CEST)
Received: from [192.168.3.246] (cust-67-22-110-94.dyn.as47377.net
	[94.110.22.67])
	by relay03ant.iops.be (Postfix) with ESMTP id C76B86BF012D;
	Wed, 11 Apr 2012 12:02:08 +0200 (CEST)
Message-ID: <4F85569F.1070806@acm.org>
Date: Wed, 11 Apr 2012 10:02:07 +0000
From: Bart Van Assche <bvanassche@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<4F8455EE.8010709@acm.org>
	<1334073004.5394.59.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334073004.5394.59.camel@zakaz.uk.xensource.com>
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David VomLehn <dvomlehn@cisco.com>, xen-devel <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH v4 0/10] skb paged fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/12 15:50, Ian Campbell wrote:

> On Tue, 2012-04-10 at 16:46 +0100, Bart Van Assche wrote:
>> Great to see v4 of this patch series. But which kernel version has this
>> patch series been based on ? I've tried to apply this series on 3.4-rc2
> 
> It's based on net-next/master. Specifically commit de8856d2c11f.


Thanks, that information allowed me to apply the patch series and to
test it with kernel 3.4-rc2 and iSCSI target code. The test ran fine.

The failure to apply this patch series on 3.4-rc2 I had reported turned
out to be an easy to resolve merge conflict:

+ static int ceph_tcp_sendpage(struct socket *sock, struct page *page,
+ 		     int offset, size_t size, int more)
+ {
+ 	int flags = MSG_DONTWAIT | MSG_NOSIGNAL | (more ? MSG_MORE : MSG_EOR);
+ 	int ret;
+ 
 -	ret = kernel_sendpage(sock, page, offset, size, flags);
++	ret = kernel_sendpage(sock, page, NULL, offset, size, flags);
+ 	if (ret == -EAGAIN)
+ 		ret = 0;
+ 
+ 	return ret;
+ }
+ 

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuSA-0006KS-Bf; Wed, 11 Apr 2012 10:07:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SHuS8-0006KC-Bk
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:07:04 +0000
Received: from [85.158.143.99:15458] by server-3.bemta-4.messagelabs.com id
	34/83-05853-7C7558F4; Wed, 11 Apr 2012 10:07:03 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334138821!19779196!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21763 invoked from network); 11 Apr 2012 10:07:02 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:07:02 -0000
Received: by qcsc20 with SMTP id c20so556766qcs.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 03:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=rn8yUgoBNv3HKZ5z1No7RjcSvdY+Ew5EWF+d3BQo4b4=;
	b=F84rQPYw3jW9enm4qWgQEk0EsF0jtZVy/yJgcSKe4Tx1barwkxIUlHraOltGx2gEVC
	AhOlQukeVBaQJ4Sfq5csKrx3KETjc5aXpLgc+eFXlexM99e2KU4pzKk/gqOm2vIhNeQj
	0zWup9AEzGaCVeazhaO04GK0SNKP7hCMb+RyzhtyaF8CyjEvmcDNm9Qxsaa+G7LTHGXv
	3rGHGZskR4+WAZKtz7yVUgaBeTYGJGK58wXLTAiDvwbtkWE8mLDhSqqTLXG8YrnqcFr3
	dTf2+/toIqM2pwR8TJs+EY7L7rwxYwJTDz6ejB9dxdSfvsKuFVocxy1HFIWeyiFcA9lA
	N4cg==
MIME-Version: 1.0
Received: by 10.224.116.6 with SMTP id k6mr19245231qaq.91.1334138820797; Wed,
	11 Apr 2012 03:07:00 -0700 (PDT)
Received: by 10.229.246.2 with HTTP; Wed, 11 Apr 2012 03:07:00 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
	<alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
Date: Wed, 11 Apr 2012 12:07:00 +0200
X-Google-Sender-Auth: ZJHIlXTDTpxzquszaNVAO3K9x7Q
Message-ID: <CAL08nMFsN=Ufjocig-u5Q0c3J3ddLFMQRka_2kuOV=C5CUF1AQ@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1452445915308781002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1452445915308781002==
Content-Type: multipart/alternative; boundary=20cf3074b0b27ea38004bd646646

--20cf3074b0b27ea38004bd646646
Content-Type: text/plain; charset=ISO-8859-1

Yes, I am using "xm create" to instance the guest (xen-tools to actually
create the guest image). And yes, I am pretty sure I am using blkback in
combination with a loopback device (I'm using file:/ after all).
But I thought the xend backend systems would somehow, at least, force a
fsync() for that file. It seems that when using file:/ sync operations
don't really ensure that contents are being synced to disk, but only to the
loopback-mounted file, which is probably still affected by the pagecache
(but that's only a guess).

For the record, I tried with phy:/ and a LVM volume and everything works as
expected (i.e. sync and fsync operations sync data to disk).

Thanks!

On Tue, Apr 10, 2012 at 5:25 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> On Thu, 5 Apr 2012, Pablo Llopis wrote:
> > Hi there Xen community,
> > I am trying to benchmark and compare I/O in Xen/domU to native
> performance.
> >
> > In order to do this I started trying to benchmark writes so as to avoid
> caching effects that surely turn up when
> > performing reads due to the page cache et al.
> > However, I have quickly run into a problem: Xen domU reports that a
> 128MB file is written at close to 300MB/s, while the
> > disk's performance peaks at about 80MB/s (I observed this on a dom0 and
> on a bare-metal kernel with no hypervisor).
> > Please note that I fsync() after all writes in hopes to avoid the effect
> of write buffers. I have tried with O_SYNC as
> > well, observing a similar outcome.
> > I can confirm this writing a simple program, and verified exactly same
> results running bonnie++ with the fsync() option
> > turned on.
> >
> > I am surprised to see writes reaching a throughput as high as 300MB/s,
> as the disk surely isn't physically capable of
> > reaching that bandwidth, meaning that writes are not being really synced
> to disk.
> >
> > Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
> fdatasync, O_SYNC, etc..?
> > How would I proceed to measure and compare real read/write speeds on a
> Xen domU ?
> >
> > My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
> could not get the tapdisk driver to work
> > properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)
> > Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> > For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0
> kernel
>
> Are you using xend/xm to create the guest? In that case you are using
> a loop device with blkback behind the scenes, that might go through the
> disk cache.

--20cf3074b0b27ea38004bd646646
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, I am using &quot;xm create&quot; to instance the guest (xen-tools to a=
ctually create the guest image). And yes, I am pretty sure I am using blkba=
ck in combination with a loopback device (I&#39;m using file:/ after all).=
=A0<div>
But I thought the xend backend systems would somehow, at least, force a fsy=
nc() for that file. It seems that when using file:/ sync operations don&#39=
;t really ensure that contents are being synced to disk, but only to the lo=
opback-mounted file, which is probably still affected by the pagecache (but=
 that&#39;s only a guess).=A0</div>
<div><br></div><div>For the record, I tried with phy:/ and a LVM volume and=
 everything works as expected (i.e. sync and fsync operations sync data to =
disk).=A0</div><div><br></div><div>Thanks!<br><br><div class=3D"gmail_quote=
">
On Tue, Apr 10, 2012 at 5:25 PM, Stefano Stabellini <span dir=3D"ltr">&lt;<=
a href=3D"mailto:stefano.stabellini@eu.citrix.com">stefano.stabellini@eu.ci=
trix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Thu, 5 Apr 2012, Pablo Llopis wr=
ote:<br>
&gt; Hi there Xen community,<br>
&gt; I am trying to benchmark and compare I/O in Xen/domU to native perform=
ance.<br>
&gt;<br>
&gt; In order to do this I started trying to benchmark writes so as to avoi=
d caching effects that surely turn up when<br>
&gt; performing reads due to the page cache et al.<br>
&gt; However, I have quickly run into a problem: Xen domU reports that a 12=
8MB file is written at close to 300MB/s, while the<br>
&gt; disk&#39;s performance peaks at about 80MB/s (I observed this on a dom=
0 and on a bare-metal kernel with no hypervisor).<br>
&gt; Please note that I fsync() after all writes in hopes to avoid the effe=
ct of write buffers.=A0I have tried with O_SYNC as<br>
&gt; well, observing a similar outcome.<br>
&gt; I can confirm this writing a simple program, and verified exactly same=
 results running bonnie++ with the fsync() option<br>
&gt; turned on.<br>
&gt;<br>
&gt; I am surprised to see writes reaching a throughput as high as 300MB/s,=
 as the disk surely isn&#39;t physically capable of<br>
&gt; reaching that bandwidth, meaning that writes are not being really sync=
ed to disk.=A0<br>
&gt;<br>
&gt; Is this a bug in Xen, or is there a way to make Xen not ignore fsync, =
fdatasync, O_SYNC, etc..?=A0<br>
&gt; How would I proceed to measure and compare real read/write speeds on a=
 Xen domU ?<br>
&gt;<br>
&gt; My disk drivers are specified with &quot;file:/path/to/image.img,xvda,=
1,w&quot; (I could not get the tapdisk driver to work<br>
&gt; properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)<br>
&gt; Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)<br>
&gt; For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 =
kernel<br>
<br>
</div></div>Are you using xend/xm to create the guest? In that case you are=
 using<br>
a loop device with blkback behind the scenes, that might go through the<br>
disk cache.</blockquote></div><br></div>

--20cf3074b0b27ea38004bd646646--


--===============1452445915308781002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1452445915308781002==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 10:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuSA-0006KS-Bf; Wed, 11 Apr 2012 10:07:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pablo.llopis@gmail.com>) id 1SHuS8-0006KC-Bk
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:07:04 +0000
Received: from [85.158.143.99:15458] by server-3.bemta-4.messagelabs.com id
	34/83-05853-7C7558F4; Wed, 11 Apr 2012 10:07:03 +0000
X-Env-Sender: pablo.llopis@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334138821!19779196!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21763 invoked from network); 11 Apr 2012 10:07:02 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:07:02 -0000
Received: by qcsc20 with SMTP id c20so556766qcs.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 03:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=rn8yUgoBNv3HKZ5z1No7RjcSvdY+Ew5EWF+d3BQo4b4=;
	b=F84rQPYw3jW9enm4qWgQEk0EsF0jtZVy/yJgcSKe4Tx1barwkxIUlHraOltGx2gEVC
	AhOlQukeVBaQJ4Sfq5csKrx3KETjc5aXpLgc+eFXlexM99e2KU4pzKk/gqOm2vIhNeQj
	0zWup9AEzGaCVeazhaO04GK0SNKP7hCMb+RyzhtyaF8CyjEvmcDNm9Qxsaa+G7LTHGXv
	3rGHGZskR4+WAZKtz7yVUgaBeTYGJGK58wXLTAiDvwbtkWE8mLDhSqqTLXG8YrnqcFr3
	dTf2+/toIqM2pwR8TJs+EY7L7rwxYwJTDz6ejB9dxdSfvsKuFVocxy1HFIWeyiFcA9lA
	N4cg==
MIME-Version: 1.0
Received: by 10.224.116.6 with SMTP id k6mr19245231qaq.91.1334138820797; Wed,
	11 Apr 2012 03:07:00 -0700 (PDT)
Received: by 10.229.246.2 with HTTP; Wed, 11 Apr 2012 03:07:00 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
	<alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
Date: Wed, 11 Apr 2012 12:07:00 +0200
X-Google-Sender-Auth: ZJHIlXTDTpxzquszaNVAO3K9x7Q
Message-ID: <CAL08nMFsN=Ufjocig-u5Q0c3J3ddLFMQRka_2kuOV=C5CUF1AQ@mail.gmail.com>
From: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
	O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1452445915308781002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1452445915308781002==
Content-Type: multipart/alternative; boundary=20cf3074b0b27ea38004bd646646

--20cf3074b0b27ea38004bd646646
Content-Type: text/plain; charset=ISO-8859-1

Yes, I am using "xm create" to instance the guest (xen-tools to actually
create the guest image). And yes, I am pretty sure I am using blkback in
combination with a loopback device (I'm using file:/ after all).
But I thought the xend backend systems would somehow, at least, force a
fsync() for that file. It seems that when using file:/ sync operations
don't really ensure that contents are being synced to disk, but only to the
loopback-mounted file, which is probably still affected by the pagecache
(but that's only a guess).

For the record, I tried with phy:/ and a LVM volume and everything works as
expected (i.e. sync and fsync operations sync data to disk).

Thanks!

On Tue, Apr 10, 2012 at 5:25 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> On Thu, 5 Apr 2012, Pablo Llopis wrote:
> > Hi there Xen community,
> > I am trying to benchmark and compare I/O in Xen/domU to native
> performance.
> >
> > In order to do this I started trying to benchmark writes so as to avoid
> caching effects that surely turn up when
> > performing reads due to the page cache et al.
> > However, I have quickly run into a problem: Xen domU reports that a
> 128MB file is written at close to 300MB/s, while the
> > disk's performance peaks at about 80MB/s (I observed this on a dom0 and
> on a bare-metal kernel with no hypervisor).
> > Please note that I fsync() after all writes in hopes to avoid the effect
> of write buffers. I have tried with O_SYNC as
> > well, observing a similar outcome.
> > I can confirm this writing a simple program, and verified exactly same
> results running bonnie++ with the fsync() option
> > turned on.
> >
> > I am surprised to see writes reaching a throughput as high as 300MB/s,
> as the disk surely isn't physically capable of
> > reaching that bandwidth, meaning that writes are not being really synced
> to disk.
> >
> > Is this a bug in Xen, or is there a way to make Xen not ignore fsync,
> fdatasync, O_SYNC, etc..?
> > How would I proceed to measure and compare real read/write speeds on a
> Xen domU ?
> >
> > My disk drivers are specified with "file:/path/to/image.img,xvda,1,w" (I
> could not get the tapdisk driver to work
> > properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)
> > Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)
> > For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0
> kernel
>
> Are you using xend/xm to create the guest? In that case you are using
> a loop device with blkback behind the scenes, that might go through the
> disk cache.

--20cf3074b0b27ea38004bd646646
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, I am using &quot;xm create&quot; to instance the guest (xen-tools to a=
ctually create the guest image). And yes, I am pretty sure I am using blkba=
ck in combination with a loopback device (I&#39;m using file:/ after all).=
=A0<div>
But I thought the xend backend systems would somehow, at least, force a fsy=
nc() for that file. It seems that when using file:/ sync operations don&#39=
;t really ensure that contents are being synced to disk, but only to the lo=
opback-mounted file, which is probably still affected by the pagecache (but=
 that&#39;s only a guess).=A0</div>
<div><br></div><div>For the record, I tried with phy:/ and a LVM volume and=
 everything works as expected (i.e. sync and fsync operations sync data to =
disk).=A0</div><div><br></div><div>Thanks!<br><br><div class=3D"gmail_quote=
">
On Tue, Apr 10, 2012 at 5:25 PM, Stefano Stabellini <span dir=3D"ltr">&lt;<=
a href=3D"mailto:stefano.stabellini@eu.citrix.com">stefano.stabellini@eu.ci=
trix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Thu, 5 Apr 2012, Pablo Llopis wr=
ote:<br>
&gt; Hi there Xen community,<br>
&gt; I am trying to benchmark and compare I/O in Xen/domU to native perform=
ance.<br>
&gt;<br>
&gt; In order to do this I started trying to benchmark writes so as to avoi=
d caching effects that surely turn up when<br>
&gt; performing reads due to the page cache et al.<br>
&gt; However, I have quickly run into a problem: Xen domU reports that a 12=
8MB file is written at close to 300MB/s, while the<br>
&gt; disk&#39;s performance peaks at about 80MB/s (I observed this on a dom=
0 and on a bare-metal kernel with no hypervisor).<br>
&gt; Please note that I fsync() after all writes in hopes to avoid the effe=
ct of write buffers.=A0I have tried with O_SYNC as<br>
&gt; well, observing a similar outcome.<br>
&gt; I can confirm this writing a simple program, and verified exactly same=
 results running bonnie++ with the fsync() option<br>
&gt; turned on.<br>
&gt;<br>
&gt; I am surprised to see writes reaching a throughput as high as 300MB/s,=
 as the disk surely isn&#39;t physically capable of<br>
&gt; reaching that bandwidth, meaning that writes are not being really sync=
ed to disk.=A0<br>
&gt;<br>
&gt; Is this a bug in Xen, or is there a way to make Xen not ignore fsync, =
fdatasync, O_SYNC, etc..?=A0<br>
&gt; How would I proceed to measure and compare real read/write speeds on a=
 Xen domU ?<br>
&gt;<br>
&gt; My disk drivers are specified with &quot;file:/path/to/image.img,xvda,=
1,w&quot; (I could not get the tapdisk driver to work<br>
&gt; properly, I tried with vanilla 3.2 and 3.0.0 ubuntu kernels)<br>
&gt; Xen is version 4.1.1 and is running Oneiric domUs (kernel 3.0.0)<br>
&gt; For the dom0 I have a 3.2 vanilla kernel and a ubuntu (oneiric) 3.0.0 =
kernel<br>
<br>
</div></div>Are you using xend/xm to create the guest? In that case you are=
 using<br>
a loop device with blkback behind the scenes, that might go through the<br>
disk cache.</blockquote></div><br></div>

--20cf3074b0b27ea38004bd646646--


--===============1452445915308781002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1452445915308781002==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 10:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuWE-0006pY-6g; Wed, 11 Apr 2012 10:11:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuWD-0006pP-Du
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:11:17 +0000
Received: from [85.158.139.83:18845] by server-11.bemta-5.messagelabs.com id
	FA/68-12959-4C8558F4; Wed, 11 Apr 2012 10:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334139075!23226934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20210 invoked from network); 11 Apr 2012 10:11:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:11:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:11:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuVw-0001HX-GY; Wed, 11 Apr 2012 10:11:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuVw-0004wT-E9;
	Wed, 11 Apr 2012 11:11:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.22708.423961.379442@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:11:00 +0100
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C8235B7099@LONPMAILBOX01.citrite.net>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C8235B7099@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paul Durrant writes ("RE: [Xen-devel] Driver domains communication protocol proposal"):
> I'm wondering how we should deal with driver domain re-starts
> (possibly because of a crash). One of the compelling reasons for
> using driver domains is the ability to re-start them, possibly
> transparently to the frontend.

Right.

> If a driver domain were to crash, I guess it would be the
> responsibility of the tools to notice this and build a new one as
> quickly as possible. A frontend could notice the loss of a driver
> domain backend by, presumably a backend state watch firing followed
> by an inability to read the backend state key,

No, I don't think anything would necessarily remove the backend from
xenstore.  So the frontend shouldn't notice anything (other than a
stall, obviously) until the <frontend>/backend node was updated to
point to the replacement.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuWE-0006pY-6g; Wed, 11 Apr 2012 10:11:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuWD-0006pP-Du
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:11:17 +0000
Received: from [85.158.139.83:18845] by server-11.bemta-5.messagelabs.com id
	FA/68-12959-4C8558F4; Wed, 11 Apr 2012 10:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334139075!23226934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20210 invoked from network); 11 Apr 2012 10:11:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11873802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:11:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:11:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuVw-0001HX-GY; Wed, 11 Apr 2012 10:11:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuVw-0004wT-E9;
	Wed, 11 Apr 2012 11:11:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.22708.423961.379442@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:11:00 +0100
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C8235B7099@LONPMAILBOX01.citrite.net>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C8235B7099@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paul Durrant writes ("RE: [Xen-devel] Driver domains communication protocol proposal"):
> I'm wondering how we should deal with driver domain re-starts
> (possibly because of a crash). One of the compelling reasons for
> using driver domains is the ability to re-start them, possibly
> transparently to the frontend.

Right.

> If a driver domain were to crash, I guess it would be the
> responsibility of the tools to notice this and build a new one as
> quickly as possible. A frontend could notice the loss of a driver
> domain backend by, presumably a backend state watch firing followed
> by an inability to read the backend state key,

No, I don't think anything would necessarily remove the backend from
xenstore.  So the frontend shouldn't notice anything (other than a
stall, obviously) until the <frontend>/backend node was updated to
point to the replacement.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:21:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHug5-0007EP-4y; Wed, 11 Apr 2012 10:21:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHug3-0007EF-Fc
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:21:27 +0000
Received: from [85.158.143.35:14064] by server-3.bemta-4.messagelabs.com id
	36/B1-05853-62B558F4; Wed, 11 Apr 2012 10:21:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334139685!4424212!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22739 invoked from network); 11 Apr 2012 10:21:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 10:21:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Apr 2012 11:21:24 +0100
Message-Id: <4F857744020000780007D348@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Apr 2012 11:21:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] checking d->grant_table against NULL?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

gnttab_prepare_for_transfer() is the only place in grant_table.c where
such a check happens. Is this check superfluous (and hence slightly
misleading), or are similar checks missing throughout the file? I suppose
the former, given that domains get inserted to the hash table only after
grant_table_create() ran, and get removed again before calling
grant_table_destroy().

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:21:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHug5-0007EP-4y; Wed, 11 Apr 2012 10:21:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SHug3-0007EF-Fc
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:21:27 +0000
Received: from [85.158.143.35:14064] by server-3.bemta-4.messagelabs.com id
	36/B1-05853-62B558F4; Wed, 11 Apr 2012 10:21:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334139685!4424212!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22739 invoked from network); 11 Apr 2012 10:21:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 10:21:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Apr 2012 11:21:24 +0100
Message-Id: <4F857744020000780007D348@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Apr 2012 11:21:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] checking d->grant_table against NULL?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

gnttab_prepare_for_transfer() is the only place in grant_table.c where
such a check happens. Is this check superfluous (and hence slightly
misleading), or are similar checks missing throughout the file? I suppose
the former, given that domains get inserted to the hash table only after
grant_table_create() ran, and get removed again before calling
grant_table_destroy().

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:24:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuj0-0007Qm-NS; Wed, 11 Apr 2012 10:24:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuiz-0007Qh-Og
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:24:29 +0000
Received: from [85.158.143.99:25053] by server-1.bemta-4.messagelabs.com id
	3C/8B-20925-DDB558F4; Wed, 11 Apr 2012 10:24:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334139867!19782923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26057 invoked from network); 11 Apr 2012 10:24:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:24:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:24:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuiw-0001Nh-8s; Wed, 11 Apr 2012 10:24:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuiw-00052x-7s;
	Wed, 11 Apr 2012 11:24:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.23514.59542.527454@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:24:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334134921.5394.78.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
...
> > Consequently,
> >  - New noreturn function libxl__alloc_failed which may be used for
> >    printing a vaguely-useful error message, rather than simply
> >    dereferencing a null pointer.
> 
> We got that in the next patch?

Uh ?  libxl__alloc_failed is in this patch.  I'm not sure what you
mean.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ta.

> > +    int new_maxsize = gc->alloc_maxsize * 2 + 25;
> 
> + 25? (I don't mind, seems even more arbitrary now that we have the *2
> though).

Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
overhead and will probably avoid triggering a realloc too often.

> > +    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
> > +    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
> > +    if (!gc->alloc_ptrs)
> > +        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);
> 
> Strictly this should be "..., new_maxsize, sizeof(void*)" since the
> arguments are nmemb and size?

I was going to say "we should do this the same way as fwrite and
calloc" so I looked them up, and they have the nmemb and size
arguments in THE OPPOSITE ORDER.  No wonder I can never remember!

I guess this is more like calloc and it should mirror libxl_calloc so
the prototype is right and this call site is wrong.  Fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:24:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuj0-0007Qm-NS; Wed, 11 Apr 2012 10:24:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuiz-0007Qh-Og
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:24:29 +0000
Received: from [85.158.143.99:25053] by server-1.bemta-4.messagelabs.com id
	3C/8B-20925-DDB558F4; Wed, 11 Apr 2012 10:24:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334139867!19782923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26057 invoked from network); 11 Apr 2012 10:24:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:24:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:24:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuiw-0001Nh-8s; Wed, 11 Apr 2012 10:24:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuiw-00052x-7s;
	Wed, 11 Apr 2012 11:24:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.23514.59542.527454@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:24:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334134921.5394.78.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
...
> > Consequently,
> >  - New noreturn function libxl__alloc_failed which may be used for
> >    printing a vaguely-useful error message, rather than simply
> >    dereferencing a null pointer.
> 
> We got that in the next patch?

Uh ?  libxl__alloc_failed is in this patch.  I'm not sure what you
mean.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ta.

> > +    int new_maxsize = gc->alloc_maxsize * 2 + 25;
> 
> + 25? (I don't mind, seems even more arbitrary now that we have the *2
> though).

Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
overhead and will probably avoid triggering a realloc too often.

> > +    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
> > +    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
> > +    if (!gc->alloc_ptrs)
> > +        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);
> 
> Strictly this should be "..., new_maxsize, sizeof(void*)" since the
> arguments are nmemb and size?

I was going to say "we should do this the same way as fwrite and
calloc" so I looked them up, and they have the nmemb and size
arguments in THE OPPOSITE ORDER.  No wonder I can never remember!

I guess this is more like calloc and it should mirror libxl_calloc so
the prototype is right and this call site is wrong.  Fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:32:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuqp-0007hj-Ln; Wed, 11 Apr 2012 10:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SHuqo-0007hd-Dj
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 10:32:34 +0000
Received: from [85.158.143.99:18671] by server-3.bemta-4.messagelabs.com id
	86/C6-05853-1CD558F4; Wed, 11 Apr 2012 10:32:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334140351!22252883!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10219 invoked from network); 11 Apr 2012 10:32:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:32:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330923600"; d="scan'208";a="189794010"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 06:32:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 06:32:03 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SHuqI-0004J2-Q8;
	Wed, 11 Apr 2012 11:32:02 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 11:31:48 +0100
Message-ID: <1334140308-9914-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
References: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCHv2] x86: fix delta calculation in TSC deadline
	timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

In the virtual LAPIC, correct the delta calculation when emulating the
TSC deadline timer.

Without this fix, XenServer (which is based on Xen 4.1) does not work
when running as an HVM guest.  dom0 fails to boot because its timer
interrupts are very delayed (by several minutes in some cases).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
---
A 4.1.x candidate?

Changes since v1:
- remove unused guest_time variable
---
 xen/arch/x86/hvm/vlapic.c |   12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 8401756..abdb556 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -898,7 +898,6 @@ uint64_t  vlapic_tdt_msr_get(struct vlapic *vlapic)
 void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
 {
     uint64_t guest_tsc;
-    uint64_t guest_time;
     struct vcpu *v = vlapic_vcpu(vlapic);
 
     /* may need to exclude some other conditions like vlapic->hw.disabled */
@@ -910,12 +909,10 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
     
     /* new_value = 0, >0 && <= now, > now */
     guest_tsc = hvm_get_guest_tsc(v);
-    guest_time = hvm_get_guest_time(v);
     if ( value > guest_tsc )
     {
-        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
-        delta = gtsc_to_gtime(v->domain, delta);
-        delta = max_t(s64, delta - guest_time, 0);
+        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
+        delta = max_t(s64, delta, 0);
 
         HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", delta);
 
@@ -949,9 +946,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
 
     HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER,
                 "tdt_msr[0x%016"PRIx64"],"
-                " gtsc[0x%016"PRIx64"],"
-                " gtime[0x%016"PRIx64"]",
-                vlapic->hw.tdt_msr, guest_tsc, guest_time);
+                " gtsc[0x%016"PRIx64"]",
+                vlapic->hw.tdt_msr, guest_tsc);
 }
 
 static int __vlapic_accept_pic_intr(struct vcpu *v)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:32:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuqp-0007hj-Ln; Wed, 11 Apr 2012 10:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SHuqo-0007hd-Dj
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 10:32:34 +0000
Received: from [85.158.143.99:18671] by server-3.bemta-4.messagelabs.com id
	86/C6-05853-1CD558F4; Wed, 11 Apr 2012 10:32:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334140351!22252883!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10219 invoked from network); 11 Apr 2012 10:32:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:32:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330923600"; d="scan'208";a="189794010"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 06:32:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 06:32:03 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SHuqI-0004J2-Q8;
	Wed, 11 Apr 2012 11:32:02 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 11:31:48 +0100
Message-ID: <1334140308-9914-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
References: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCHv2] x86: fix delta calculation in TSC deadline
	timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

In the virtual LAPIC, correct the delta calculation when emulating the
TSC deadline timer.

Without this fix, XenServer (which is based on Xen 4.1) does not work
when running as an HVM guest.  dom0 fails to boot because its timer
interrupts are very delayed (by several minutes in some cases).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
---
A 4.1.x candidate?

Changes since v1:
- remove unused guest_time variable
---
 xen/arch/x86/hvm/vlapic.c |   12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 8401756..abdb556 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -898,7 +898,6 @@ uint64_t  vlapic_tdt_msr_get(struct vlapic *vlapic)
 void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
 {
     uint64_t guest_tsc;
-    uint64_t guest_time;
     struct vcpu *v = vlapic_vcpu(vlapic);
 
     /* may need to exclude some other conditions like vlapic->hw.disabled */
@@ -910,12 +909,10 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
     
     /* new_value = 0, >0 && <= now, > now */
     guest_tsc = hvm_get_guest_tsc(v);
-    guest_time = hvm_get_guest_time(v);
     if ( value > guest_tsc )
     {
-        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
-        delta = gtsc_to_gtime(v->domain, delta);
-        delta = max_t(s64, delta - guest_time, 0);
+        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
+        delta = max_t(s64, delta, 0);
 
         HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", delta);
 
@@ -949,9 +946,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
 
     HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER,
                 "tdt_msr[0x%016"PRIx64"],"
-                " gtsc[0x%016"PRIx64"],"
-                " gtime[0x%016"PRIx64"]",
-                vlapic->hw.tdt_msr, guest_tsc, guest_time);
+                " gtsc[0x%016"PRIx64"]",
+                vlapic->hw.tdt_msr, guest_tsc);
 }
 
 static int __vlapic_accept_pic_intr(struct vcpu *v)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:36:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuu8-0007pX-9I; Wed, 11 Apr 2012 10:36:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuu6-0007pL-5D
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:35:58 +0000
Received: from [85.158.143.99:37913] by server-1.bemta-4.messagelabs.com id
	BC/2F-20925-D8E558F4; Wed, 11 Apr 2012 10:35:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334140556!23154930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12666 invoked from network); 11 Apr 2012 10:35:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:35:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:35:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuth-0001WP-6G; Wed, 11 Apr 2012 10:35:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuth-00053U-5H;
	Wed, 11 Apr 2012 11:35:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.24181.146410.826599@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:35:33 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334135082.5394.80.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334135082.5394.80.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4 00/31] libxl child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 00/31] libxl child process handling"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > Bugfixes for problems reported by Roger Pau Monne:
> >   02/31 libxl: ao: allow immediate completion
> >   03/31 libxl: fix hang due to libxl__initiate_device_remove
> >   04/31 libxl: Fix eventloop_iteration over-locking
> > * 05/31 libxl: remove poller from list in libxl__poller_get
> > 
> > Other general bugfixes:
> > * 01/31 .gitignore: Add a missing file
> >   06/31 libxl: Fix leak of ctx->lock
> >   07/31 tools: Correct PTHREAD options in config/StdGNU.mk
> >   08/31 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
> >   09/31 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
> 
> I think all of the above are now acked and since they are largely
> unrelated to the overall thrust of the series could easily go in now?

Yes.

> >   26/31 libxl: Clean up setdefault in do_domain_create
> >   30/31 libxl: make libxl_create_logfile const-correct
> > 
> > Clarifications and improvements related to memory allocation:
> >   10/31 libxl: Crash (more sensibly) on malloc failure
> >   11/31 libxl: Make libxl__zalloc et al tolerate a NULL gc
> 
> These two could probably go in now too, especially 10/31 would be useful
> to have sooner rather than later so we can stop writing error handling
> code...

Yes.

> Actually the more I read the more I see that a good chunk of the front
> of this series could go in now. Is that what you are planning to do?

Indeed.  I was holding off before because I hadn't actually executed
any of it, but I have now.

I intend to apply as much as I quickly get acks for.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:36:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuu8-0007pX-9I; Wed, 11 Apr 2012 10:36:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuu6-0007pL-5D
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:35:58 +0000
Received: from [85.158.143.99:37913] by server-1.bemta-4.messagelabs.com id
	BC/2F-20925-D8E558F4; Wed, 11 Apr 2012 10:35:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334140556!23154930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12666 invoked from network); 11 Apr 2012 10:35:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:35:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:35:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuth-0001WP-6G; Wed, 11 Apr 2012 10:35:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuth-00053U-5H;
	Wed, 11 Apr 2012 11:35:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.24181.146410.826599@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:35:33 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334135082.5394.80.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334135082.5394.80.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4 00/31] libxl child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 00/31] libxl child process handling"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > Bugfixes for problems reported by Roger Pau Monne:
> >   02/31 libxl: ao: allow immediate completion
> >   03/31 libxl: fix hang due to libxl__initiate_device_remove
> >   04/31 libxl: Fix eventloop_iteration over-locking
> > * 05/31 libxl: remove poller from list in libxl__poller_get
> > 
> > Other general bugfixes:
> > * 01/31 .gitignore: Add a missing file
> >   06/31 libxl: Fix leak of ctx->lock
> >   07/31 tools: Correct PTHREAD options in config/StdGNU.mk
> >   08/31 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
> >   09/31 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
> 
> I think all of the above are now acked and since they are largely
> unrelated to the overall thrust of the series could easily go in now?

Yes.

> >   26/31 libxl: Clean up setdefault in do_domain_create
> >   30/31 libxl: make libxl_create_logfile const-correct
> > 
> > Clarifications and improvements related to memory allocation:
> >   10/31 libxl: Crash (more sensibly) on malloc failure
> >   11/31 libxl: Make libxl__zalloc et al tolerate a NULL gc
> 
> These two could probably go in now too, especially 10/31 would be useful
> to have sooner rather than later so we can stop writing error handling
> code...

Yes.

> Actually the more I read the more I see that a good chunk of the front
> of this series could go in now. Is that what you are planning to do?

Indeed.  I was holding off before because I hadn't actually executed
any of it, but I have now.

I intend to apply as much as I quickly get acks for.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:37:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuvD-0007uY-N3; Wed, 11 Apr 2012 10:37:07 +0000
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 1SHuvC-0007uH-Aq
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:37:06 +0000
Received: from [193.109.254.147:58197] by server-3.bemta-14.messagelabs.com id
	DF/9C-23274-1DE558F4; Wed, 11 Apr 2012 10:37:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334140624!4103946!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32645 invoked from network); 11 Apr 2012 10:37:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 10:37:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Apr 2012 11:37:04 +0100
Message-Id: <4F857AF0020000780007D365@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Apr 2012 11:37:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
	<1334140308-9914-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334140308-9914-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv2] x86: fix delta calculation in TSC
 deadline timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.04.12 at 12:31, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In the virtual LAPIC, correct the delta calculation when emulating the
> TSC deadline timer.
> 
> Without this fix, XenServer (which is based on Xen 4.1) does not work
> when running as an HVM guest.  dom0 fails to boot because its timer
> interrupts are very delayed (by several minutes in some cases).
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
> A 4.1.x candidate?

Presumably.

> Changes since v1:
> - remove unused guest_time variable
> ---
>  xen/arch/x86/hvm/vlapic.c |   12 ++++--------
>  1 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 8401756..abdb556 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -898,7 +898,6 @@ uint64_t  vlapic_tdt_msr_get(struct vlapic *vlapic)
>  void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
>  {
>      uint64_t guest_tsc;
> -    uint64_t guest_time;
>      struct vcpu *v = vlapic_vcpu(vlapic);
>  
>      /* may need to exclude some other conditions like vlapic->hw.disabled */
> @@ -910,12 +909,10 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t 
> value)
>      
>      /* new_value = 0, >0 && <= now, > now */
>      guest_tsc = hvm_get_guest_tsc(v);
> -    guest_time = hvm_get_guest_time(v);
>      if ( value > guest_tsc )
>      {
> -        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
> -        delta = gtsc_to_gtime(v->domain, delta);
> -        delta = max_t(s64, delta - guest_time, 0);
> +        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
> +        delta = max_t(s64, delta, 0);
>  
>          HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", 
> delta);
>  
> @@ -949,9 +946,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t 
> value)
>  
>      HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER,
>                  "tdt_msr[0x%016"PRIx64"],"
> -                " gtsc[0x%016"PRIx64"],"
> -                " gtime[0x%016"PRIx64"]",
> -                vlapic->hw.tdt_msr, guest_tsc, guest_time);
> +                " gtsc[0x%016"PRIx64"]",
> +                vlapic->hw.tdt_msr, guest_tsc);
>  }
>  
>  static int __vlapic_accept_pic_intr(struct vcpu *v)
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:37:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuvD-0007uY-N3; Wed, 11 Apr 2012 10:37:07 +0000
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 1SHuvC-0007uH-Aq
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:37:06 +0000
Received: from [193.109.254.147:58197] by server-3.bemta-14.messagelabs.com id
	DF/9C-23274-1DE558F4; Wed, 11 Apr 2012 10:37:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334140624!4103946!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32645 invoked from network); 11 Apr 2012 10:37:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 10:37:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Apr 2012 11:37:04 +0100
Message-Id: <4F857AF0020000780007D365@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Apr 2012 11:37:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <4F855FEE020000780007D2DB@nat28.tlf.novell.com>
	<1334140308-9914-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334140308-9914-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv2] x86: fix delta calculation in TSC
 deadline timer emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.04.12 at 12:31, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In the virtual LAPIC, correct the delta calculation when emulating the
> TSC deadline timer.
> 
> Without this fix, XenServer (which is based on Xen 4.1) does not work
> when running as an HVM guest.  dom0 fails to boot because its timer
> interrupts are very delayed (by several minutes in some cases).
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
> A 4.1.x candidate?

Presumably.

> Changes since v1:
> - remove unused guest_time variable
> ---
>  xen/arch/x86/hvm/vlapic.c |   12 ++++--------
>  1 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 8401756..abdb556 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -898,7 +898,6 @@ uint64_t  vlapic_tdt_msr_get(struct vlapic *vlapic)
>  void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
>  {
>      uint64_t guest_tsc;
> -    uint64_t guest_time;
>      struct vcpu *v = vlapic_vcpu(vlapic);
>  
>      /* may need to exclude some other conditions like vlapic->hw.disabled */
> @@ -910,12 +909,10 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t 
> value)
>      
>      /* new_value = 0, >0 && <= now, > now */
>      guest_tsc = hvm_get_guest_tsc(v);
> -    guest_time = hvm_get_guest_time(v);
>      if ( value > guest_tsc )
>      {
> -        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
> -        delta = gtsc_to_gtime(v->domain, delta);
> -        delta = max_t(s64, delta - guest_time, 0);
> +        uint64_t delta = gtsc_to_gtime(v->domain, value - guest_tsc);
> +        delta = max_t(s64, delta, 0);
>  
>          HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", 
> delta);
>  
> @@ -949,9 +946,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t 
> value)
>  
>      HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER,
>                  "tdt_msr[0x%016"PRIx64"],"
> -                " gtsc[0x%016"PRIx64"],"
> -                " gtime[0x%016"PRIx64"]",
> -                vlapic->hw.tdt_msr, guest_tsc, guest_time);
> +                " gtsc[0x%016"PRIx64"]",
> +                vlapic->hw.tdt_msr, guest_tsc);
>  }
>  
>  static int __vlapic_accept_pic_intr(struct vcpu *v)
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:38:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuw9-000809-AV; Wed, 11 Apr 2012 10:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuw8-0007zy-84
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:38:04 +0000
Received: from [85.158.143.99:54717] by server-1.bemta-4.messagelabs.com id
	DB/A2-20925-B0F558F4; Wed, 11 Apr 2012 10:38:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334140681!22623215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12212 invoked from network); 11 Apr 2012 10:38:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:38:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:38:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:38:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuw5-0001YM-DN; Wed, 11 Apr 2012 10:38:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuw5-00054H-CP;
	Wed, 11 Apr 2012 11:38:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.24329.215011.7201@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:38:01 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334135691.5394.85.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
	<1334135691.5394.85.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even with forking threads"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > +    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
> > +    if (r) libxl__alloc_failed(ctx, __func__, 0,0);
> 
> This is a bit subtle -- the only documented error from pthread_atfork is
> ENOMEM. Perhaps "assert(r == 0 || errno == ENOMEM)" as both
> belt'n'braces and doc?

Sure.  I have done this:

      r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
      if (r) {
          assert(r == ENOMEM);
          libxl__alloc_failed(ctx, __func__, 0,0);
      }

> The above wouldn't stop me from acking though:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:38:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHuw9-000809-AV; Wed, 11 Apr 2012 10:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHuw8-0007zy-84
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:38:04 +0000
Received: from [85.158.143.99:54717] by server-1.bemta-4.messagelabs.com id
	DB/A2-20925-B0F558F4; Wed, 11 Apr 2012 10:38:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334140681!22623215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12212 invoked from network); 11 Apr 2012 10:38:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:38:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:38:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:38:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHuw5-0001YM-DN; Wed, 11 Apr 2012 10:38:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHuw5-00054H-CP;
	Wed, 11 Apr 2012 11:38:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.24329.215011.7201@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:38:01 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334135691.5394.85.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-19-git-send-email-ian.jackson@eu.citrix.com>
	<1334135691.5394.85.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 18/31] libxl: Protect fds with CLOEXEC even with forking threads"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > +    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
> > +    if (r) libxl__alloc_failed(ctx, __func__, 0,0);
> 
> This is a bit subtle -- the only documented error from pthread_atfork is
> ENOMEM. Perhaps "assert(r == 0 || errno == ENOMEM)" as both
> belt'n'braces and doc?

Sure.  I have done this:

      r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
      if (r) {
          assert(r == ENOMEM);
          libxl__alloc_failed(ctx, __func__, 0,0);
      }

> The above wouldn't stop me from acking though:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:47:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHv4x-0008Tu-B8; Wed, 11 Apr 2012 10:47:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHv4u-0008Tp-VW
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:47:09 +0000
Received: from [85.158.138.51:43879] by server-10.bemta-3.messagelabs.com id
	4B/92-29478-C21658F4; Wed, 11 Apr 2012 10:47:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334141226!10656817!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1219 invoked from network); 11 Apr 2012 10:47:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:47:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:47:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:47:05 +0100
Message-ID: <1334141224.5394.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:47:04 +0100
In-Reply-To: <20357.23514.59542.527454@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 11:24 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> > On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> ...
> > > Consequently,
> > >  - New noreturn function libxl__alloc_failed which may be used for
> > >    printing a vaguely-useful error message, rather than simply
> > >    dereferencing a null pointer.
> > 
> > We got that in the next patch?
> 
> Uh ?  libxl__alloc_failed is in this patch.  I'm not sure what you
> mean.

Quoted the wrong bullet! From the wrong list!

I was trying to respond to:

> Things left to do:
>  - Provide versions of malloc, realloc and free which do the
>    checking but which do not enroll the pointer in the gc.

> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Ta.
> 
> > > +    int new_maxsize = gc->alloc_maxsize * 2 + 25;
> > 
> > + 25? (I don't mind, seems even more arbitrary now that we have the *2
> > though).
> 
> Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
> bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
> overhead and will probably avoid triggering a realloc too often.

Why isn't just doubling each time adequate?

> > > +    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
> > > +    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
> > > +    if (!gc->alloc_ptrs)
> > > +        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);
> > 
> > Strictly this should be "..., new_maxsize, sizeof(void*)" since the
> > arguments are nmemb and size?
> 
> I was going to say "we should do this the same way as fwrite and
> calloc" so I looked them up, and they have the nmemb and size
> arguments in THE OPPOSITE ORDER.  No wonder I can never remember!

I'd never noticed that, how confusing.

> I guess this is more like calloc and it should mirror libxl_calloc so
> the prototype is right and this call site is wrong.  Fixed.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:47:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHv4x-0008Tu-B8; Wed, 11 Apr 2012 10:47:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHv4u-0008Tp-VW
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:47:09 +0000
Received: from [85.158.138.51:43879] by server-10.bemta-3.messagelabs.com id
	4B/92-29478-C21658F4; Wed, 11 Apr 2012 10:47:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334141226!10656817!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1219 invoked from network); 11 Apr 2012 10:47:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:47:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:47:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:47:05 +0100
Message-ID: <1334141224.5394.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:47:04 +0100
In-Reply-To: <20357.23514.59542.527454@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 11:24 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> > On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> ...
> > > Consequently,
> > >  - New noreturn function libxl__alloc_failed which may be used for
> > >    printing a vaguely-useful error message, rather than simply
> > >    dereferencing a null pointer.
> > 
> > We got that in the next patch?
> 
> Uh ?  libxl__alloc_failed is in this patch.  I'm not sure what you
> mean.

Quoted the wrong bullet! From the wrong list!

I was trying to respond to:

> Things left to do:
>  - Provide versions of malloc, realloc and free which do the
>    checking but which do not enroll the pointer in the gc.

> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Ta.
> 
> > > +    int new_maxsize = gc->alloc_maxsize * 2 + 25;
> > 
> > + 25? (I don't mind, seems even more arbitrary now that we have the *2
> > though).
> 
> Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
> bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
> overhead and will probably avoid triggering a realloc too often.

Why isn't just doubling each time adequate?

> > > +    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
> > > +    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
> > > +    if (!gc->alloc_ptrs)
> > > +        libxl__alloc_failed(CTX, __func__, sizeof(void*), new_maxsize);
> > 
> > Strictly this should be "..., new_maxsize, sizeof(void*)" since the
> > arguments are nmemb and size?
> 
> I was going to say "we should do this the same way as fwrite and
> calloc" so I looked them up, and they have the nmemb and size
> arguments in THE OPPOSITE ORDER.  No wonder I can never remember!

I'd never noticed that, how confusing.

> I guess this is more like calloc and it should mirror libxl_calloc so
> the prototype is right and this call site is wrong.  Fixed.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:48:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHv5g-00005v-Em; Wed, 11 Apr 2012 10:47:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHv5e-00005n-Qg
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:47:55 +0000
Received: from [85.158.143.35:18376] by server-2.bemta-4.messagelabs.com id
	DA/D1-17550-A51658F4; Wed, 11 Apr 2012 10:47:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334141273!4429756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23961 invoked from network); 11 Apr 2012 10:47:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:47:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:47:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:47:52 +0100
Message-ID: <1334141271.5394.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:47:51 +0100
In-Reply-To: <1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> General facility for ao operations to shovel data between fds.
> 
> This will be used by the bootloader machinery.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
[...]
> +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents);
> +
> +static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
> +{
> +    STATE_AO_GC(dc);
> +    int rc;
> +
> +    if (dc->used) {
> +        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
> +            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
> +                                       dc->writefd, POLLOUT);
> +            if (rc) {
> +                LOG(ERROR, "unable to establish write event on %s"
> +                    " during copy of %s", dc->writewhat, dc->copywhat);
> +                datacopier_callback(egc, dc, -1, 0);
> +                return;
> +            }
> +        }
> +    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
> +        /* we have had eof */
> +        libxl__datacopier_kill(dc);
> +        dc->callback(egc, dc, 0, 0);

This looks like an open coded datacopier_callback().

[...]
> @@ -1455,6 +1456,45 @@ int libxl__carefd_close(libxl__carefd*);
>  int libxl__carefd_fd(const libxl__carefd*);
> 
> 
> +/*----- datacopier: copies data from one fd to another -----*/
> +
> +typedef struct libxl__datacopier_state libxl__datacopier_state;
> +typedef struct libxl__datacopier_buf libxl__datacopier_buf;
> +
> +/* onwrite==1 means failure happened when writing, logged, errno is valid
> + * onwrite==0 means failure happened when reading
> + *     errno==0 means we got eof and all data was written
> + *     errno!=0 means we had a read error, logged

ITYM errnoval in every case here rather than actual errno ?

> + * onwrite==-1 means some other internal failure, errnoval not valid, logged
> + * in all cases copier is killed before calling this callback */
> +typedef void libxl__datacopier_callback(libxl__egc *egc,
> +     libxl__datacopier_state *dc, int onwrite, int errnoval);
> +

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:48:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHv5g-00005v-Em; Wed, 11 Apr 2012 10:47:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHv5e-00005n-Qg
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:47:55 +0000
Received: from [85.158.143.35:18376] by server-2.bemta-4.messagelabs.com id
	DA/D1-17550-A51658F4; Wed, 11 Apr 2012 10:47:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334141273!4429756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23961 invoked from network); 11 Apr 2012 10:47:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:47:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:47:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:47:52 +0100
Message-ID: <1334141271.5394.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:47:51 +0100
In-Reply-To: <1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> General facility for ao operations to shovel data between fds.
> 
> This will be used by the bootloader machinery.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
[...]
> +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents);
> +
> +static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
> +{
> +    STATE_AO_GC(dc);
> +    int rc;
> +
> +    if (dc->used) {
> +        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
> +            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
> +                                       dc->writefd, POLLOUT);
> +            if (rc) {
> +                LOG(ERROR, "unable to establish write event on %s"
> +                    " during copy of %s", dc->writewhat, dc->copywhat);
> +                datacopier_callback(egc, dc, -1, 0);
> +                return;
> +            }
> +        }
> +    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
> +        /* we have had eof */
> +        libxl__datacopier_kill(dc);
> +        dc->callback(egc, dc, 0, 0);

This looks like an open coded datacopier_callback().

[...]
> @@ -1455,6 +1456,45 @@ int libxl__carefd_close(libxl__carefd*);
>  int libxl__carefd_fd(const libxl__carefd*);
> 
> 
> +/*----- datacopier: copies data from one fd to another -----*/
> +
> +typedef struct libxl__datacopier_state libxl__datacopier_state;
> +typedef struct libxl__datacopier_buf libxl__datacopier_buf;
> +
> +/* onwrite==1 means failure happened when writing, logged, errno is valid
> + * onwrite==0 means failure happened when reading
> + *     errno==0 means we got eof and all data was written
> + *     errno!=0 means we had a read error, logged

ITYM errnoval in every case here rather than actual errno ?

> + * onwrite==-1 means some other internal failure, errnoval not valid, logged
> + * in all cases copier is killed before calling this callback */
> +typedef void libxl__datacopier_callback(libxl__egc *egc,
> +     libxl__datacopier_state *dc, int onwrite, int errnoval);
> +

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:51:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHv8c-0000Hk-38; Wed, 11 Apr 2012 10:50:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHv8a-0000Hb-D8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:50:56 +0000
Received: from [85.158.143.99:23045] by server-3.bemta-4.messagelabs.com id
	13/08-05853-F02658F4; Wed, 11 Apr 2012 10:50:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334141454!22850914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27003 invoked from network); 11 Apr 2012 10:50:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:50:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:50:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:50:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHv89-0001en-Gb; Wed, 11 Apr 2012 10:50:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHv89-00056v-FW;
	Wed, 11 Apr 2012 11:50:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.25077.463938.950992@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:50:29 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334136095.5394.89.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
	<1334136095.5394.89.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP, POLLNVAL properly"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > +    if (revents & (POLLERR|POLLHUP))
> > +        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
> 
> If this can happen even when we didn't ask for it then is that really a
> disaster? Could we just log it and move on (or ignore it)?

You never ask for POLLERR or POLLHUP.  They happen regardless.  If
they happen, poll() will keep reporting them.  So we have to stop
polling on this fd entirely - ie effectively the fd has become broken,
unless we know what the cause is and can do something sane about it.
Since this is supposedly the xenstore fd, it is indeed a disaster.

For comparison, if we get eof on the xenstore fd, libxenstore causes
xs_read_watch to return 0 setting errno to EBADF (!) (xs.c:365), which
is also a DISASTER (libxl_event.c:343).

> Under what circumstances does poll actually behave this way? Is it an
> indication that something has gone horribly wrong already?

Yes, exactly.

POLLPRI occurs on sockets and means that the socket has urgent data
(TCP) or out of band data (some other protocols); an application using
TCP would take this as a signal to read data from the fd until it
catches up with the urgent pointer.

POLLHUP occurs when (eg) a pty's other end has been closed and the pty
is shut down.  An application which sees POLLHUP would typically close
the fd.  Eg, in an earlier version of the bootloader rework I had a
bug which would fail to keep an fd open onto the slave side of the
xenconsole pty, so libxl would get POLLHUP on the master side the
bootloader execution would be aborted.  This was handy for my error
testing :-) and is an example of a POLLHUP which isn't a DISASTER,
although it is pretty fatal for the fd in question.

These events should not occur on the xenstore handle.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:51:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHv8c-0000Hk-38; Wed, 11 Apr 2012 10:50:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHv8a-0000Hb-D8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:50:56 +0000
Received: from [85.158.143.99:23045] by server-3.bemta-4.messagelabs.com id
	13/08-05853-F02658F4; Wed, 11 Apr 2012 10:50:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334141454!22850914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27003 invoked from network); 11 Apr 2012 10:50:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:50:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11874955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:50:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:50:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHv89-0001en-Gb; Wed, 11 Apr 2012 10:50:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHv89-00056v-FW;
	Wed, 11 Apr 2012 11:50:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.25077.463938.950992@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:50:29 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334136095.5394.89.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
	<1334136095.5394.89.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP, POLLNVAL properly"):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > +    if (revents & (POLLERR|POLLHUP))
> > +        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
> 
> If this can happen even when we didn't ask for it then is that really a
> disaster? Could we just log it and move on (or ignore it)?

You never ask for POLLERR or POLLHUP.  They happen regardless.  If
they happen, poll() will keep reporting them.  So we have to stop
polling on this fd entirely - ie effectively the fd has become broken,
unless we know what the cause is and can do something sane about it.
Since this is supposedly the xenstore fd, it is indeed a disaster.

For comparison, if we get eof on the xenstore fd, libxenstore causes
xs_read_watch to return 0 setting errno to EBADF (!) (xs.c:365), which
is also a DISASTER (libxl_event.c:343).

> Under what circumstances does poll actually behave this way? Is it an
> indication that something has gone horribly wrong already?

Yes, exactly.

POLLPRI occurs on sockets and means that the socket has urgent data
(TCP) or out of band data (some other protocols); an application using
TCP would take this as a signal to read data from the fd until it
catches up with the urgent pointer.

POLLHUP occurs when (eg) a pty's other end has been closed and the pty
is shut down.  An application which sees POLLHUP would typically close
the fd.  Eg, in an earlier version of the bootloader rework I had a
bug which would fail to keep an fd open onto the slave side of the
xenconsole pty, so libxl would get POLLHUP on the master side the
bootloader execution would be aborted.  This was handy for my error
testing :-) and is an example of a POLLHUP which isn't a DISASTER,
although it is pretty fatal for the fd in question.

These events should not occur on the xenstore handle.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:53:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvAU-0000QL-JF; Wed, 11 Apr 2012 10:52:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvAT-0000QC-BI
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:52:53 +0000
Received: from [85.158.143.99:27297] by server-3.bemta-4.messagelabs.com id
	11/BB-05853-482658F4; Wed, 11 Apr 2012 10:52:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334141571!23186739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11659 invoked from network); 11 Apr 2012 10:52:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:52:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:52:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:52:51 +0100
Message-ID: <1334141569.5394.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:52:49 +0100
In-Reply-To: <20357.25077.463938.950992@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
	<1334136095.5394.89.camel@zakaz.uk.xensource.com>
	<20357.25077.463938.950992@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
 POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 11:50 +0100, Ian Jackson wrote:
[...snip...]
> These events should not occur on the xenstore handle.

All made sense, thanks for the explanation.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:53:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvAU-0000QL-JF; Wed, 11 Apr 2012 10:52:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvAT-0000QC-BI
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:52:53 +0000
Received: from [85.158.143.99:27297] by server-3.bemta-4.messagelabs.com id
	11/BB-05853-482658F4; Wed, 11 Apr 2012 10:52:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334141571!23186739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11659 invoked from network); 11 Apr 2012 10:52:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:52:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:52:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 11:52:51 +0100
Message-ID: <1334141569.5394.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 11:52:49 +0100
In-Reply-To: <20357.25077.463938.950992@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-21-git-send-email-ian.jackson@eu.citrix.com>
	<1334136095.5394.89.camel@zakaz.uk.xensource.com>
	<20357.25077.463938.950992@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/31] libxl: handle POLLERR, POLLHUP,
 POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 11:50 +0100, Ian Jackson wrote:
[...snip...]
> These events should not occur on the xenstore handle.

All made sense, thanks for the explanation.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:56:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvDo-0000bG-6N; Wed, 11 Apr 2012 10:56:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvDm-0000b6-DD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:56:18 +0000
Received: from [193.109.254.147:31608] by server-7.bemta-14.messagelabs.com id
	D0/E0-01627-153658F4; Wed, 11 Apr 2012 10:56:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334141776!1620294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22662 invoked from network); 11 Apr 2012 10:56:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:56:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:56:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:56:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvDk-0001gt-06; Wed, 11 Apr 2012 10:56:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvDj-000596-VI;
	Wed, 11 Apr 2012 11:56:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.25423.953494.600764@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:56:15 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334138063.5394.97.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
	<1334138063.5394.97.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et al."):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
> > +{
> > +    for (;;) {
> > +        int r = rmdir(path);
> > +        if (!r) return 0;
> > +        if (errno == ENOENT) return 0;
> > +        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
> > +        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
> > +        if (errno == EINTR) continue;
> 
> starting to look a bit like a switch statement...

Perhaps.  I'm not sure I want to obscure the similarity with (and the
differences from) the other analogous error-handling code, and those
other sites typically have only a couple of errno cases making a
switch overkill.  Also of course a switch would switch only on errno
whereas the branching is on r too, so it would add another level of
nesting.

> > +    for (;;) {
> > +        int r = rmdir(dirpath);
> > +        if (!r) break;
> > +        if (errno == ENOENT) return 0;
> 
> This misses the closedir() at out?

Well spotted, fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 10:56:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 10:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvDo-0000bG-6N; Wed, 11 Apr 2012 10:56:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvDm-0000b6-DD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 10:56:18 +0000
Received: from [193.109.254.147:31608] by server-7.bemta-14.messagelabs.com id
	D0/E0-01627-153658F4; Wed, 11 Apr 2012 10:56:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334141776!1620294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22662 invoked from network); 11 Apr 2012 10:56:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 10:56:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 10:56:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 11:56:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvDk-0001gt-06; Wed, 11 Apr 2012 10:56:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvDj-000596-VI;
	Wed, 11 Apr 2012 11:56:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.25423.953494.600764@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 11:56:15 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334138063.5394.97.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
	<1334138063.5394.97.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et al."):
> On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
> > +{
> > +    for (;;) {
> > +        int r = rmdir(path);
> > +        if (!r) return 0;
> > +        if (errno == ENOENT) return 0;
> > +        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
> > +        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
> > +        if (errno == EINTR) continue;
> 
> starting to look a bit like a switch statement...

Perhaps.  I'm not sure I want to obscure the similarity with (and the
differences from) the other analogous error-handling code, and those
other sites typically have only a couple of errno cases making a
switch overkill.  Also of course a switch would switch only on errno
whereas the branching is on r too, so it would add another level of
nesting.

> > +    for (;;) {
> > +        int r = rmdir(dirpath);
> > +        if (!r) break;
> > +        if (errno == ENOENT) return 0;
> 
> This misses the closedir() at out?

Well spotted, fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:04:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvKk-0000oM-4l; Wed, 11 Apr 2012 11:03:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvKi-0000oH-QC
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:03:29 +0000
Received: from [85.158.143.35:16188] by server-3.bemta-4.messagelabs.com id
	21/C1-05853-005658F4; Wed, 11 Apr 2012 11:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334142207!14018103!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 587 invoked from network); 11 Apr 2012 11:03:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:03:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:03:26 +0100
Message-ID: <1334142205.5394.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:03:25 +0100
In-Reply-To: <20357.25423.953494.600764@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
	<1334138063.5394.97.camel@zakaz.uk.xensource.com>
	<20357.25423.953494.600764@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 11:56 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et al."):
> > On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > > +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
> > > +{
> > > +    for (;;) {
> > > +        int r = rmdir(path);
> > > +        if (!r) return 0;
> > > +        if (errno == ENOENT) return 0;
> > > +        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
> > > +        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
> > > +        if (errno == EINTR) continue;
> > 
> > starting to look a bit like a switch statement...
> 
> Perhaps.  I'm not sure I want to obscure the similarity with (and the
> differences from) the other analogous error-handling code, and those
> other sites typically have only a couple of errno cases making a
> switch overkill.  Also of course a switch would switch only on errno
> whereas the branching is on r too, so it would add another level of
> nesting.

Sounds reasonable to leave it as is then.

> 
> > > +    for (;;) {
> > > +        int r = rmdir(dirpath);
> > > +        if (!r) break;
> > > +        if (errno == ENOENT) return 0;
> > 
> > This misses the closedir() at out?
> 
> Well spotted, fixed.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:04:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvKk-0000oM-4l; Wed, 11 Apr 2012 11:03:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvKi-0000oH-QC
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:03:29 +0000
Received: from [85.158.143.35:16188] by server-3.bemta-4.messagelabs.com id
	21/C1-05853-005658F4; Wed, 11 Apr 2012 11:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334142207!14018103!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 587 invoked from network); 11 Apr 2012 11:03:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:03:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:03:26 +0100
Message-ID: <1334142205.5394.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:03:25 +0100
In-Reply-To: <20357.25423.953494.600764@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-25-git-send-email-ian.jackson@eu.citrix.com>
	<1334138063.5394.97.camel@zakaz.uk.xensource.com>
	<20357.25423.953494.600764@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 11:56 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/31] libxl: provide libxl__remove_file et al."):
> > On Tue, 2012-04-10 at 20:07 +0100, Ian Jackson wrote:
> > > +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
> > > +{
> > > +    for (;;) {
> > > +        int r = rmdir(path);
> > > +        if (!r) return 0;
> > > +        if (errno == ENOENT) return 0;
> > > +        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
> > > +        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
> > > +        if (errno == EINTR) continue;
> > 
> > starting to look a bit like a switch statement...
> 
> Perhaps.  I'm not sure I want to obscure the similarity with (and the
> differences from) the other analogous error-handling code, and those
> other sites typically have only a couple of errno cases making a
> switch overkill.  Also of course a switch would switch only on errno
> whereas the branching is on r too, so it would add another level of
> nesting.

Sounds reasonable to leave it as is then.

> 
> > > +    for (;;) {
> > > +        int r = rmdir(dirpath);
> > > +        if (!r) break;
> > > +        if (errno == ENOENT) return 0;
> > 
> > This misses the closedir() at out?
> 
> Well spotted, fixed.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:04:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:04:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvLJ-0000pC-HZ; Wed, 11 Apr 2012 11:04:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvLH-0000p0-BU
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:04:03 +0000
Received: from [85.158.138.51:32993] by server-1.bemta-3.messagelabs.com id
	17/75-11491-225658F4; Wed, 11 Apr 2012 11:04:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334142241!21698463!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 11 Apr 2012 11:04:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:04:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:04:01 +0100
Message-ID: <1334142239.5394.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:03:59 +0100
In-Reply-To: <1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> General facility for ao operations to open ptys.
> 
> This will be used by the bootloader machinery.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   36 ++++++++++++
>  2 files changed, 163 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index c1229e4..b33abe4 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
[...]
> +int libxl__openptys(libxl__openpty_state *op,
> +                    const struct termios *termp,
> +                    const struct winsize *winp) {
> +    /*
> +     * This is completely crazy.

;-)

>   openpty calls grantpt which the spec
> +     * says may fork, and may not be called with a SIGCHLD handler.
> +     * Now our application may have a SIGCHLD handler so that's bad.
> +     * We could perhaps block it but we'd need to block it on all
> +     * threads.  This is just Too Hard.
> +     *
> +     * So instead, we run openpty in a child process.  That child
> +     * process then of course has only our own thread and our own
> +     * signal handlers.  We pass the fds back.
> +     *
> +     * Since our only current caller actually wants two ptys, we
> +     * support calling openpty multiple times for a single fork.
> +     */
> +    STATE_AO_GC(op);
> +    int count = op->count;
> +    int r, i, rc, sockets[2], ptyfds[count][2];
> +    libxl__carefd *for_child = 0;
> +    pid_t pid = -1;
> +
> +    for (i=0; i<count; i++) {
> +        ptyfds[i][0] = ptyfds[i][1] = -1;
> +        libxl__openpty_result *res = &op->results[i];
> +        assert(!res->master);
> +        assert(!res->slave);
> +    }
> +    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
> +
> +    libxl__carefd_begin();
> +    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
> +    if (r) { sockets[0] = sockets[1] = -1; }
> +    for_child = libxl__carefd_opened(CTX, sockets[1]);
> +    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
> +
> +    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
> +    if (pid == -1) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (!pid) {
> +        /* child */
> +        close(sockets[0]);
> +        signal(SIGCHLD, SIG_DFL);
> +
> +        for (i=0; i<count; i++) {
> +            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
> +            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
> +        }
> +        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
> +                                2*count, &ptyfds[0][0], "ptys");
> +        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }

Buried in this LOGE is a CTX somewhere, right? Is it valid to keep using
it? Perhaps it's OK just for this logging.

I suppose we don't need to call the postfork-noexecing handler because
we are inside libxl?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:04:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:04:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvLJ-0000pC-HZ; Wed, 11 Apr 2012 11:04:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvLH-0000p0-BU
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:04:03 +0000
Received: from [85.158.138.51:32993] by server-1.bemta-3.messagelabs.com id
	17/75-11491-225658F4; Wed, 11 Apr 2012 11:04:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334142241!21698463!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 11 Apr 2012 11:04:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:04:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:04:01 +0100
Message-ID: <1334142239.5394.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:03:59 +0100
In-Reply-To: <1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> General facility for ao operations to open ptys.
> 
> This will be used by the bootloader machinery.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   36 ++++++++++++
>  2 files changed, 163 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index c1229e4..b33abe4 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
[...]
> +int libxl__openptys(libxl__openpty_state *op,
> +                    const struct termios *termp,
> +                    const struct winsize *winp) {
> +    /*
> +     * This is completely crazy.

;-)

>   openpty calls grantpt which the spec
> +     * says may fork, and may not be called with a SIGCHLD handler.
> +     * Now our application may have a SIGCHLD handler so that's bad.
> +     * We could perhaps block it but we'd need to block it on all
> +     * threads.  This is just Too Hard.
> +     *
> +     * So instead, we run openpty in a child process.  That child
> +     * process then of course has only our own thread and our own
> +     * signal handlers.  We pass the fds back.
> +     *
> +     * Since our only current caller actually wants two ptys, we
> +     * support calling openpty multiple times for a single fork.
> +     */
> +    STATE_AO_GC(op);
> +    int count = op->count;
> +    int r, i, rc, sockets[2], ptyfds[count][2];
> +    libxl__carefd *for_child = 0;
> +    pid_t pid = -1;
> +
> +    for (i=0; i<count; i++) {
> +        ptyfds[i][0] = ptyfds[i][1] = -1;
> +        libxl__openpty_result *res = &op->results[i];
> +        assert(!res->master);
> +        assert(!res->slave);
> +    }
> +    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
> +
> +    libxl__carefd_begin();
> +    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
> +    if (r) { sockets[0] = sockets[1] = -1; }
> +    for_child = libxl__carefd_opened(CTX, sockets[1]);
> +    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
> +
> +    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
> +    if (pid == -1) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (!pid) {
> +        /* child */
> +        close(sockets[0]);
> +        signal(SIGCHLD, SIG_DFL);
> +
> +        for (i=0; i<count; i++) {
> +            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
> +            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
> +        }
> +        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
> +                                2*count, &ptyfds[0][0], "ptys");
> +        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }

Buried in this LOGE is a CTX somewhere, right? Is it valid to keep using
it? Perhaps it's OK just for this logging.

I suppose we don't need to call the postfork-noexecing handler because
we are inside libxl?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:05:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvLf-0000ri-Ur; Wed, 11 Apr 2012 11:04:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvLe-0000rT-Ch
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:04:26 +0000
Received: from [85.158.143.99:54883] by server-1.bemta-4.messagelabs.com id
	43/14-20925-935658F4; Wed, 11 Apr 2012 11:04:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334142265!24613440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16057 invoked from network); 11 Apr 2012 11:04:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:04:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:04:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:04:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvLc-0001jt-Ue; Wed, 11 Apr 2012 11:04:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvLc-0005Lp-Tj;
	Wed, 11 Apr 2012 12:04:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.25912.898502.188820@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:04:24 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334141224.5394.106.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> On Wed, 2012-04-11 at 11:24 +0100, Ian Jackson wrote:
> > Things left to do:
> >  - Provide versions of malloc, realloc and free which do the
> >    checking but which do not enroll the pointer in the gc.
...
> We got that in the next patch?

Yes.  I don't think this bullet point is actually helpful in that
commit message as it's not so much a deficiency in the code at that
point as a thing I was intending to fix when I wrote it, so I have
removed it.

> > Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
> > bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
> > overhead and will probably avoid triggering a realloc too often.
> 
> Why isn't just doubling each time adequate?

alloc_maxsize is initialised to 0.  Doubling zero gives zero.

NB that libxl__ptr_add needs to be rewritten not to be quadratic in
the number of pointrs added (!)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:05:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvLf-0000ri-Ur; Wed, 11 Apr 2012 11:04:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvLe-0000rT-Ch
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:04:26 +0000
Received: from [85.158.143.99:54883] by server-1.bemta-4.messagelabs.com id
	43/14-20925-935658F4; Wed, 11 Apr 2012 11:04:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334142265!24613440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16057 invoked from network); 11 Apr 2012 11:04:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:04:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:04:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:04:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvLc-0001jt-Ue; Wed, 11 Apr 2012 11:04:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvLc-0005Lp-Tj;
	Wed, 11 Apr 2012 12:04:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.25912.898502.188820@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:04:24 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334141224.5394.106.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> On Wed, 2012-04-11 at 11:24 +0100, Ian Jackson wrote:
> > Things left to do:
> >  - Provide versions of malloc, realloc and free which do the
> >    checking but which do not enroll the pointer in the gc.
...
> We got that in the next patch?

Yes.  I don't think this bullet point is actually helpful in that
commit message as it's not so much a deficiency in the code at that
point as a thing I was intending to fix when I wrote it, so I have
removed it.

> > Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
> > bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
> > overhead and will probably avoid triggering a realloc too often.
> 
> Why isn't just doubling each time adequate?

alloc_maxsize is initialised to 0.  Doubling zero gives zero.

NB that libxl__ptr_add needs to be rewritten not to be quadratic in
the number of pointrs added (!)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:11:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvS7-0001MY-Py; Wed, 11 Apr 2012 11:11:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvS6-0001MT-CF
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:11:06 +0000
Received: from [193.109.254.147:11009] by server-10.bemta-14.messagelabs.com
	id 3B/EE-05847-9C6658F4; Wed, 11 Apr 2012 11:11:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334142664!4043919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21680 invoked from network); 11 Apr 2012 11:11:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:11:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:11:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvS1-0001oH-Ox; Wed, 11 Apr 2012 11:11:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvS1-0005NJ-Nz;
	Wed, 11 Apr 2012 12:11:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.26309.727713.132845@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:11:01 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334141271.5394.107.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
	<1334141271.5394.107.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*"):
> On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> > +        /* we have had eof */
> > +        libxl__datacopier_kill(dc);
> > +        dc->callback(egc, dc, 0, 0);
> 
> This looks like an open coded datacopier_callback().

Fixed.

> > +/* onwrite==1 means failure happened when writing, logged, errno is valid
> > + * onwrite==0 means failure happened when reading
> > + *     errno==0 means we got eof and all data was written
> > + *     errno!=0 means we had a read error, logged
> 
> ITYM errnoval in every case here rather than actual errno ?

Yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:11:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvS7-0001MY-Py; Wed, 11 Apr 2012 11:11:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvS6-0001MT-CF
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:11:06 +0000
Received: from [193.109.254.147:11009] by server-10.bemta-14.messagelabs.com
	id 3B/EE-05847-9C6658F4; Wed, 11 Apr 2012 11:11:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334142664!4043919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21680 invoked from network); 11 Apr 2012 11:11:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:11:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:11:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvS1-0001oH-Ox; Wed, 11 Apr 2012 11:11:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvS1-0005NJ-Nz;
	Wed, 11 Apr 2012 12:11:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.26309.727713.132845@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:11:01 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334141271.5394.107.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-28-git-send-email-ian.jackson@eu.citrix.com>
	<1334141271.5394.107.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 27/31] libxl: provide libxl__datacopier_*"):
> On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> > +        /* we have had eof */
> > +        libxl__datacopier_kill(dc);
> > +        dc->callback(egc, dc, 0, 0);
> 
> This looks like an open coded datacopier_callback().

Fixed.

> > +/* onwrite==1 means failure happened when writing, logged, errno is valid
> > + * onwrite==0 means failure happened when reading
> > + *     errno==0 means we got eof and all data was written
> > + *     errno!=0 means we had a read error, logged
> 
> ITYM errnoval in every case here rather than actual errno ?

Yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvT7-0001Y2-DC; Wed, 11 Apr 2012 11:12:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHvT5-0001Wn-PL
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:12:07 +0000
Received: from [85.158.143.99:48006] by server-2.bemta-4.messagelabs.com id
	33/6F-17550-707658F4; Wed, 11 Apr 2012 11:12:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334142726!17927029!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30024 invoked from network); 11 Apr 2012 11:12:06 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:12:06 -0000
Received: by bkcjg9 with SMTP id jg9so701089bkc.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 04:12:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=R6yHnekDZykToGQR9ixLQV3oAUMdneUA9w9i5sCIwvg=;
	b=adtXnnbO+E7H+2PNguKPARgzMPyOh2xoIqwqaAZObq0C416lZ1A2MYYSZmNH6wKk9F
	f+/HkZ+RutswAyjZNzdSK+nLNf+ytijII4CcD6KyKnchITLIvJWlS3x5x3QGX0z6rrDQ
	mBB4svNJfKkl066XLok/cuSX3y6ipPd8Jx/Lm/W9pbD/b9kWVQZWQ0/FRnvjITXNSFgn
	TGcCVLdB7uvlPvWCsh6E/FG4BDBgiWu3YfK1uLG8B6bnILjALrMagjQ2t47dpavrgSDq
	ABi6YiggtA42OcF6jQ72g5TujSSJZQ5wJishmjDC1p2lUdYl3ucoOBO219mN8htFTPQL
	xaXA==
Received: by 10.204.129.21 with SMTP id m21mr5978320bks.124.1334142726099;
	Wed, 11 Apr 2012 04:12:06 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id jr13sm4096408bkb.14.2012.04.11.04.12.04
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 04:12:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Apr 2012 12:12:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBAB2591.306C4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] checking d->grant_table against NULL?
Thread-Index: Ac0X0+rkPFYAgQgHgkOUPF+zfwNDOw==
In-Reply-To: <4F857744020000780007D348@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] checking d->grant_table against NULL?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2012 11:21, "Jan Beulich" <JBeulich@suse.com> wrote:

> gnttab_prepare_for_transfer() is the only place in grant_table.c where
> such a check happens. Is this check superfluous (and hence slightly
> misleading), or are similar checks missing throughout the file? I suppose
> the former, given that domains get inserted to the hash table only after
> grant_table_create() ran, and get removed again before calling
> grant_table_destroy().

I agree, I'm pretty sure it's superfluous.

> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvT7-0001Y2-DC; Wed, 11 Apr 2012 11:12:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHvT5-0001Wn-PL
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:12:07 +0000
Received: from [85.158.143.99:48006] by server-2.bemta-4.messagelabs.com id
	33/6F-17550-707658F4; Wed, 11 Apr 2012 11:12:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334142726!17927029!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30024 invoked from network); 11 Apr 2012 11:12:06 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:12:06 -0000
Received: by bkcjg9 with SMTP id jg9so701089bkc.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 04:12:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=R6yHnekDZykToGQR9ixLQV3oAUMdneUA9w9i5sCIwvg=;
	b=adtXnnbO+E7H+2PNguKPARgzMPyOh2xoIqwqaAZObq0C416lZ1A2MYYSZmNH6wKk9F
	f+/HkZ+RutswAyjZNzdSK+nLNf+ytijII4CcD6KyKnchITLIvJWlS3x5x3QGX0z6rrDQ
	mBB4svNJfKkl066XLok/cuSX3y6ipPd8Jx/Lm/W9pbD/b9kWVQZWQ0/FRnvjITXNSFgn
	TGcCVLdB7uvlPvWCsh6E/FG4BDBgiWu3YfK1uLG8B6bnILjALrMagjQ2t47dpavrgSDq
	ABi6YiggtA42OcF6jQ72g5TujSSJZQ5wJishmjDC1p2lUdYl3ucoOBO219mN8htFTPQL
	xaXA==
Received: by 10.204.129.21 with SMTP id m21mr5978320bks.124.1334142726099;
	Wed, 11 Apr 2012 04:12:06 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id jr13sm4096408bkb.14.2012.04.11.04.12.04
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 04:12:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Apr 2012 12:12:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBAB2591.306C4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] checking d->grant_table against NULL?
Thread-Index: Ac0X0+rkPFYAgQgHgkOUPF+zfwNDOw==
In-Reply-To: <4F857744020000780007D348@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] checking d->grant_table against NULL?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2012 11:21, "Jan Beulich" <JBeulich@suse.com> wrote:

> gnttab_prepare_for_transfer() is the only place in grant_table.c where
> such a check happens. Is this check superfluous (and hence slightly
> misleading), or are similar checks missing throughout the file? I suppose
> the former, given that domains get inserted to the hash table only after
> grant_table_create() ran, and get removed again before calling
> grant_table_destroy().

I agree, I'm pretty sure it's superfluous.

> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvU3-0001ee-RQ; Wed, 11 Apr 2012 11:13:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHvU3-0001eU-4q
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:13:07 +0000
Received: from [85.158.139.83:33543] by server-7.bemta-5.messagelabs.com id
	B4/5A-16195-247658F4; Wed, 11 Apr 2012 11:13:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334142785!23324064!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26141 invoked from network); 11 Apr 2012 11:13:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:13:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:13:04 +0100
Date: Wed, 11 Apr 2012 12:16:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
In-Reply-To: <CAL08nMFsN=Ufjocig-u5Q0c3J3ddLFMQRka_2kuOV=C5CUF1AQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204111215130.15151@kaball-desktop>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
	<alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
	<CAL08nMFsN=Ufjocig-u5Q0c3J3ddLFMQRka_2kuOV=C5CUF1AQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-112930903-1334143015=:15151"
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
 O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-112930903-1334143015=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Apr 2012, Pablo Llopis wrote:
> Yes, I am using "xm create" to instance the guest (xen-tools to actually create the guest image). And yes, I am pretty
> sure I am using blkback in combination with a loopback device (I'm using file:/ after all).  But I thought the xend
> backend systems would somehow, at least, force a fsync() for that file. It seems that when using file:/ sync operations
> don't really ensure that contents are being synced to disk, but only to the loopback-mounted file, which is probably still
> affected by the pagecache (but that's only a guess). 
> 
> For the record, I tried with phy:/ and a LVM volume and everything works as expected (i.e. sync and fsync operations sync
> data to disk). 

That would be the best solution with Xen 4.1 and it is also the fastest.
--8323329-112930903-1334143015=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-112930903-1334143015=:15151--


From xen-devel-bounces@lists.xen.org Wed Apr 11 11:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvU3-0001ee-RQ; Wed, 11 Apr 2012 11:13:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHvU3-0001eU-4q
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:13:07 +0000
Received: from [85.158.139.83:33543] by server-7.bemta-5.messagelabs.com id
	B4/5A-16195-247658F4; Wed, 11 Apr 2012 11:13:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334142785!23324064!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26141 invoked from network); 11 Apr 2012 11:13:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:13:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:13:04 +0100
Date: Wed, 11 Apr 2012 12:16:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Pablo Llopis <pllopis@arcos.inf.uc3m.es>
In-Reply-To: <CAL08nMFsN=Ufjocig-u5Q0c3J3ddLFMQRka_2kuOV=C5CUF1AQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204111215130.15151@kaball-desktop>
References: <CAL08nMEQfAEYZPj48vK92q3vCoYAw1_cOUCc4HaiQrUbhh5-Ow@mail.gmail.com>
	<alpine.DEB.2.00.1204101621020.15151@kaball-desktop>
	<CAL08nMFsN=Ufjocig-u5Q0c3J3ddLFMQRka_2kuOV=C5CUF1AQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-112930903-1334143015=:15151"
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Benchmark Xen writes with sync - Xen ignores fsync,
 O_SYNC?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-112930903-1334143015=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Apr 2012, Pablo Llopis wrote:
> Yes, I am using "xm create" to instance the guest (xen-tools to actually create the guest image). And yes, I am pretty
> sure I am using blkback in combination with a loopback device (I'm using file:/ after all).  But I thought the xend
> backend systems would somehow, at least, force a fsync() for that file. It seems that when using file:/ sync operations
> don't really ensure that contents are being synced to disk, but only to the loopback-mounted file, which is probably still
> affected by the pagecache (but that's only a guess). 
> 
> For the record, I tried with phy:/ and a LVM volume and everything works as expected (i.e. sync and fsync operations sync
> data to disk). 

That would be the best solution with Xen 4.1 and it is also the fastest.
--8323329-112930903-1334143015=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-112930903-1334143015=:15151--


From xen-devel-bounces@lists.xen.org Wed Apr 11 11:15:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvVs-0001p5-C4; Wed, 11 Apr 2012 11:15:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvVq-0001oh-9b
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:14:58 +0000
Received: from [85.158.139.83:29481] by server-11.bemta-5.messagelabs.com id
	4A/BE-12959-1B7658F4; Wed, 11 Apr 2012 11:14:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334142896!22654359!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8786 invoked from network); 11 Apr 2012 11:14:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:14:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:14:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:14:56 +0100
Message-ID: <1334142894.5394.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:14:54 +0100
In-Reply-To: <20357.25912.898502.188820@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> > On Wed, 2012-04-11 at 11:24 +0100, Ian Jackson wrote:
> > > Things left to do:
> > >  - Provide versions of malloc, realloc and free which do the
> > >    checking but which do not enroll the pointer in the gc.
> ...
> > We got that in the next patch?
> 
> Yes.  I don't think this bullet point is actually helpful in that
> commit message as it's not so much a deficiency in the code at that
> point as a thing I was intending to fix when I wrote it, so I have
> removed it.
> 
> > > Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
> > > bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
> > > overhead and will probably avoid triggering a realloc too often.
> > 
> > Why isn't just doubling each time adequate?
> 
> alloc_maxsize is initialised to 0.  Doubling zero gives zero.

Oh, for some reason I expected it would be initialised to >=1.

> NB that libxl__ptr_add needs to be rewritten not to be quadratic in
> the number of pointrs added (!)

Isn't it O(N) in numbers of pointers?

I also just noticed that the initial:
   /* fast case: we have space in the array for storing the pointer */
    for (i = 0; i < gc->alloc_maxsize; i++) {
        if (!gc->alloc_ptrs[i]) {
            gc->alloc_ptrs[i] = ptr;
            return 0;
        }
    }
is a bit suboptimal since we never remove a ptr from the array, so we
may as well track the max actually used. Then the fast path might
actually be fast...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:15:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvVs-0001p5-C4; Wed, 11 Apr 2012 11:15:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvVq-0001oh-9b
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:14:58 +0000
Received: from [85.158.139.83:29481] by server-11.bemta-5.messagelabs.com id
	4A/BE-12959-1B7658F4; Wed, 11 Apr 2012 11:14:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334142896!22654359!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8786 invoked from network); 11 Apr 2012 11:14:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:14:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:14:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:14:56 +0100
Message-ID: <1334142894.5394.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:14:54 +0100
In-Reply-To: <20357.25912.898502.188820@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> > On Wed, 2012-04-11 at 11:24 +0100, Ian Jackson wrote:
> > > Things left to do:
> > >  - Provide versions of malloc, realloc and free which do the
> > >    checking but which do not enroll the pointer in the gc.
> ...
> > We got that in the next patch?
> 
> Yes.  I don't think this bullet point is actually helpful in that
> commit message as it's not so much a deficiency in the code at that
> point as a thing I was intending to fix when I wrote it, so I have
> removed it.
> 
> > > Well, zero isn't adequate :-).  So yes, it's arbitrary.  25 is 100
> > > bytes (i386) or 200 bytes (amd64) which seems a reasonable initial
> > > overhead and will probably avoid triggering a realloc too often.
> > 
> > Why isn't just doubling each time adequate?
> 
> alloc_maxsize is initialised to 0.  Doubling zero gives zero.

Oh, for some reason I expected it would be initialised to >=1.

> NB that libxl__ptr_add needs to be rewritten not to be quadratic in
> the number of pointrs added (!)

Isn't it O(N) in numbers of pointers?

I also just noticed that the initial:
   /* fast case: we have space in the array for storing the pointer */
    for (i = 0; i < gc->alloc_maxsize; i++) {
        if (!gc->alloc_ptrs[i]) {
            gc->alloc_ptrs[i] = ptr;
            return 0;
        }
    }
is a bit suboptimal since we never remove a ptr from the array, so we
may as well track the max actually used. Then the fast path might
actually be fast...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:19:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvZr-00023E-1V; Wed, 11 Apr 2012 11:19:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvZp-000239-HT
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:19:05 +0000
Received: from [85.158.143.99:35974] by server-1.bemta-4.messagelabs.com id
	E7/BD-20925-8A8658F4; Wed, 11 Apr 2012 11:19:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334143143!17894855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8858 invoked from network); 11 Apr 2012 11:19:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875612"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:19:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:19:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvZn-0001tw-0f; Wed, 11 Apr 2012 11:19:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvZm-0005YJ-Vs;
	Wed, 11 Apr 2012 12:19:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.26790.965987.73781@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:19:02 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334142239.5394.116.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
	<1334142239.5394.116.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*"):
> On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> > General facility for ao operations to open ptys.
...
> > +    if (!pid) {
> > +        /* child */
> > +        close(sockets[0]);
> > +        signal(SIGCHLD, SIG_DFL);
> > +
> > +        for (i=0; i<count; i++) {
> > +            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
> > +            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
> > +        }
> > +        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
> > +                                2*count, &ptyfds[0][0], "ptys");
> > +        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
> 
> Buried in this LOGE is a CTX somewhere, right? Is it valid to keep using
> it? Perhaps it's OK just for this logging.

This should be documented somewhere.  But I see it isn't.  The closest
we have is:

  * The child should go on to exec (or exit) soon, and should not make
  * any further libxl event calls in the meantime.

I have clarified this:

 * The child should go on to exec (or exit) soon.  The child may not
 * make any further calls to libxl infrastructure, except for memory
 * allocation and logging.  If the child needs to use xenstore it
 * must open its own xs handle and use it directly, rather than via
 * the libxl event machinery.

> I suppose we don't need to call the postfork-noexecing handler because
> we are inside libxl?

No, we don't need to call it because we're fast ("exit ... soon",
above).  The worst case is that we hold onto unwanted fds while the
openpty helper runs etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:19:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvZr-00023E-1V; Wed, 11 Apr 2012 11:19:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvZp-000239-HT
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:19:05 +0000
Received: from [85.158.143.99:35974] by server-1.bemta-4.messagelabs.com id
	E7/BD-20925-8A8658F4; Wed, 11 Apr 2012 11:19:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334143143!17894855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8858 invoked from network); 11 Apr 2012 11:19:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875612"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:19:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:19:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvZn-0001tw-0f; Wed, 11 Apr 2012 11:19:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvZm-0005YJ-Vs;
	Wed, 11 Apr 2012 12:19:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.26790.965987.73781@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:19:02 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334142239.5394.116.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
	<1334142239.5394.116.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*"):
> On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> > General facility for ao operations to open ptys.
...
> > +    if (!pid) {
> > +        /* child */
> > +        close(sockets[0]);
> > +        signal(SIGCHLD, SIG_DFL);
> > +
> > +        for (i=0; i<count; i++) {
> > +            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
> > +            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
> > +        }
> > +        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
> > +                                2*count, &ptyfds[0][0], "ptys");
> > +        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
> 
> Buried in this LOGE is a CTX somewhere, right? Is it valid to keep using
> it? Perhaps it's OK just for this logging.

This should be documented somewhere.  But I see it isn't.  The closest
we have is:

  * The child should go on to exec (or exit) soon, and should not make
  * any further libxl event calls in the meantime.

I have clarified this:

 * The child should go on to exec (or exit) soon.  The child may not
 * make any further calls to libxl infrastructure, except for memory
 * allocation and logging.  If the child needs to use xenstore it
 * must open its own xs handle and use it directly, rather than via
 * the libxl event machinery.

> I suppose we don't need to call the postfork-noexecing handler because
> we are inside libxl?

No, we don't need to call it because we're fast ("exit ... soon",
above).  The worst case is that we hold onto unwanted fds while the
openpty helper runs etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:21:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvc9-00029R-Iu; Wed, 11 Apr 2012 11:21:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvc7-00029L-W8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:21:28 +0000
Received: from [85.158.139.83:30205] by server-8.bemta-5.messagelabs.com id
	F1/F0-26964-739658F4; Wed, 11 Apr 2012 11:21:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334143285!23325921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27879 invoked from network); 11 Apr 2012 11:21:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:21:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:21:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:21:24 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvc4-0001vJ-89; Wed, 11 Apr 2012 11:21:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvc4-0005Yb-6w;
	Wed, 11 Apr 2012 12:21:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.26932.161008.384380@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:21:24 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334142894.5394.125.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
	<1334142894.5394.125.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> On Wed, 2012-04-11 at 12:04 +0100, Ian Jackson wrote:
> > NB that libxl__ptr_add needs to be rewritten not to be quadratic in
> > the number of pointrs added (!)
> 
> Isn't it O(N) in numbers of pointers?

Yes, each addition is O(N).  Adding N pointers is O(N^2).

> I also just noticed that the initial:
>    /* fast case: we have space in the array for storing the pointer */
>     for (i = 0; i < gc->alloc_maxsize; i++) {
>         if (!gc->alloc_ptrs[i]) {
>             gc->alloc_ptrs[i] = ptr;
>             return 0;
>         }
>     }
> is a bit suboptimal since we never remove a ptr from the array, so we
> may as well track the max actually used. Then the fast path might
> actually be fast...

I thought we used to have a function for removing pointers from the gc
but I see that it has gone.  So yes this could be rewritten fairly
simply.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:21:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvc9-00029R-Iu; Wed, 11 Apr 2012 11:21:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvc7-00029L-W8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:21:28 +0000
Received: from [85.158.139.83:30205] by server-8.bemta-5.messagelabs.com id
	F1/F0-26964-739658F4; Wed, 11 Apr 2012 11:21:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334143285!23325921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27879 invoked from network); 11 Apr 2012 11:21:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:21:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:21:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:21:24 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvc4-0001vJ-89; Wed, 11 Apr 2012 11:21:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvc4-0005Yb-6w;
	Wed, 11 Apr 2012 12:21:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.26932.161008.384380@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:21:24 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334142894.5394.125.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
	<1334142894.5394.125.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> On Wed, 2012-04-11 at 12:04 +0100, Ian Jackson wrote:
> > NB that libxl__ptr_add needs to be rewritten not to be quadratic in
> > the number of pointrs added (!)
> 
> Isn't it O(N) in numbers of pointers?

Yes, each addition is O(N).  Adding N pointers is O(N^2).

> I also just noticed that the initial:
>    /* fast case: we have space in the array for storing the pointer */
>     for (i = 0; i < gc->alloc_maxsize; i++) {
>         if (!gc->alloc_ptrs[i]) {
>             gc->alloc_ptrs[i] = ptr;
>             return 0;
>         }
>     }
> is a bit suboptimal since we never remove a ptr from the array, so we
> may as well track the max actually used. Then the fast path might
> actually be fast...

I thought we used to have a function for removing pointers from the gc
but I see that it has gone.  So yes this could be rewritten fairly
simply.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvel-0002Ii-4p; Wed, 11 Apr 2012 11:24:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvej-0002Ia-VU
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:24:10 +0000
Received: from [85.158.143.35:45063] by server-3.bemta-4.messagelabs.com id
	4B/77-05853-9D9658F4; Wed, 11 Apr 2012 11:24:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334143441!8332197!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23788 invoked from network); 11 Apr 2012 11:24:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:24:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:24:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:24:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHveZ-0001zV-S5; Wed, 11 Apr 2012 11:23:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHveZ-0005Z6-R9;
	Wed, 11 Apr 2012 12:23:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.27087.808130.550541@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:23:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
In-Reply-To: <20357.26932.161008.384380@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
	<1334142894.5394.125.camel@zakaz.uk.xensource.com>
	<20357.26932.161008.384380@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> I thought we used to have a function for removing pointers from the gc
> but I see that it has gone.  So yes this could be rewritten fairly
> simply.

Yes, libxl_free, removed on 16 August 2010.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvel-0002Ii-4p; Wed, 11 Apr 2012 11:24:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvej-0002Ia-VU
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:24:10 +0000
Received: from [85.158.143.35:45063] by server-3.bemta-4.messagelabs.com id
	4B/77-05853-9D9658F4; Wed, 11 Apr 2012 11:24:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334143441!8332197!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23788 invoked from network); 11 Apr 2012 11:24:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:24:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:24:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:24:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHveZ-0001zV-S5; Wed, 11 Apr 2012 11:23:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHveZ-0005Z6-R9;
	Wed, 11 Apr 2012 12:23:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.27087.808130.550541@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:23:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
In-Reply-To: <20357.26932.161008.384380@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
	<1334142894.5394.125.camel@zakaz.uk.xensource.com>
	<20357.26932.161008.384380@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> I thought we used to have a function for removing pointers from the gc
> but I see that it has gone.  So yes this could be rewritten fairly
> simply.

Yes, libxl_free, removed on 16 August 2010.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvhs-0002bZ-FF; Wed, 11 Apr 2012 11:27:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHvhr-0002bK-PJ
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:27:23 +0000
Received: from [85.158.143.99:31017] by server-1.bemta-4.messagelabs.com id
	BF/FB-20925-B9A658F4; Wed, 11 Apr 2012 11:27:23 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334143640!23164376!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAyNTc4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 11 Apr 2012 11:27:21 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 11:27:21 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHvhn-0002TL-FR; Wed, 11 Apr 2012 12:27:19 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Wed, 11 Apr 2012
	12:26:10 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 11 Apr 2012 12:22:53 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0TGB7xwHD+kZtwR4CZDWk8B2rfCQEvVDCv
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>,
	<20120405103729.GE14774@ocelot.phlegethon.org>
In-Reply-To: <20120405103729.GE14774@ocelot.phlegethon.org>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Tim Deegan [tim@xen.org]
Sent: 05 April 2012 11:37
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] reserve e820 ram

At 12:52 +0100 on 29 Mar (1333025578), Francisco Rocha wrote:
> Why is e820 being used in arch_init_memory (xen/arch/x86/mm.c in my
> case) and not boot_e820 (the one we changed)?  I am asking because
> from what I understand this will make my use of reserve_e820_ram
> useless, but I think I still not have all the information I need to
> know how it all connects.

arch_init_memory() is only using e820 to find out which addresses are
MMIO regions.  If we were to use boot_e820 we would mark all the
reserve_e820_ram()'d regions as MMIO, which is probably not what you
want.

> To create a range that I can later use as a guest's RAM can I use
> dom_cow instead of dom_io in arch_init_memory?

No! dom_cow is the owner of all copy-on-write shared pages.  You don't
want to get your reserved area caught up in that lot. :)

> Or will that create problems when allocating the pages to an
> unprivileged domain?  I don't want that memory range in use by the
> main memory pool used by the allocators.

AIUI just calling reserve_e820_ram() to exclude the memory from
boot_e820 should DTRT.  Is that not working for you?

> From what I understand. The pages must have to be assigned to a particular domain, dom_xen|io|cow.
> I see this as keeping them mapped and usable before assigning them to the domU I want. Is that thought correct?

I think it shoudl be OK to leave them with no owner -- as long as
they're not in the memory allocator's free pools they won't get given to
any other domain.  Then once you're ready to use them you can assign the
directly to your domU.

Another option would be to assign them to dom_xen and use
share_xen_page_with_guest to let domU map them.

Can you give us some details about how your current approach is failing?

Cheers,

Tim.

This part is working.

I am able to reserve a range of memory and boot a HVM guest 
that uses pages from that range. The problem is when I try 
to restrict dom0 from accessing does pages, it fails in allocating 
the memory to the guest.

Is get_page_from_l1e always called by dom0?
Can a guest run when dom0 is restricted from 
accessing its memory? I would only want to restrict access 
for certain operations.

Cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvhs-0002bZ-FF; Wed, 11 Apr 2012 11:27:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHvhr-0002bK-PJ
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:27:23 +0000
Received: from [85.158.143.99:31017] by server-1.bemta-4.messagelabs.com id
	BF/FB-20925-B9A658F4; Wed, 11 Apr 2012 11:27:23 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334143640!23164376!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAyNTc4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 11 Apr 2012 11:27:21 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 11:27:21 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHvhn-0002TL-FR; Wed, 11 Apr 2012 12:27:19 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Wed, 11 Apr 2012
	12:26:10 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 11 Apr 2012 12:22:53 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0TGB7xwHD+kZtwR4CZDWk8B2rfCQEvVDCv
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0341252F9E42@EXCCR03.campus.ncl.ac.uk>,
	<20120405103729.GE14774@ocelot.phlegethon.org>
In-Reply-To: <20120405103729.GE14774@ocelot.phlegethon.org>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Tim Deegan [tim@xen.org]
Sent: 05 April 2012 11:37
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] reserve e820 ram

At 12:52 +0100 on 29 Mar (1333025578), Francisco Rocha wrote:
> Why is e820 being used in arch_init_memory (xen/arch/x86/mm.c in my
> case) and not boot_e820 (the one we changed)?  I am asking because
> from what I understand this will make my use of reserve_e820_ram
> useless, but I think I still not have all the information I need to
> know how it all connects.

arch_init_memory() is only using e820 to find out which addresses are
MMIO regions.  If we were to use boot_e820 we would mark all the
reserve_e820_ram()'d regions as MMIO, which is probably not what you
want.

> To create a range that I can later use as a guest's RAM can I use
> dom_cow instead of dom_io in arch_init_memory?

No! dom_cow is the owner of all copy-on-write shared pages.  You don't
want to get your reserved area caught up in that lot. :)

> Or will that create problems when allocating the pages to an
> unprivileged domain?  I don't want that memory range in use by the
> main memory pool used by the allocators.

AIUI just calling reserve_e820_ram() to exclude the memory from
boot_e820 should DTRT.  Is that not working for you?

> From what I understand. The pages must have to be assigned to a particular domain, dom_xen|io|cow.
> I see this as keeping them mapped and usable before assigning them to the domU I want. Is that thought correct?

I think it shoudl be OK to leave them with no owner -- as long as
they're not in the memory allocator's free pools they won't get given to
any other domain.  Then once you're ready to use them you can assign the
directly to your domU.

Another option would be to assign them to dom_xen and use
share_xen_page_with_guest to let domU map them.

Can you give us some details about how your current approach is failing?

Cheers,

Tim.

This part is working.

I am able to reserve a range of memory and boot a HVM guest 
that uses pages from that range. The problem is when I try 
to restrict dom0 from accessing does pages, it fails in allocating 
the memory to the guest.

Is get_page_from_l1e always called by dom0?
Can a guest run when dom0 is restricted from 
accessing its memory? I would only want to restrict access 
for certain operations.

Cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:32:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:32:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvmA-0002qZ-54; Wed, 11 Apr 2012 11:31:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvm9-0002qS-3l
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:31:49 +0000
Received: from [85.158.143.35:5503] by server-2.bemta-4.messagelabs.com id
	71/51-17550-4AB658F4; Wed, 11 Apr 2012 11:31:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334143906!12756733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11431 invoked from network); 11 Apr 2012 11:31:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:31:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:31:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:31:46 +0100
Message-ID: <1334143904.5394.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:31:44 +0100
In-Reply-To: <1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert
 libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[...]
> +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
> +static void bootloader_keystrokes_copyfail(libxl__egc *egc,
> +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> +static void bootloader_display_copyfail(libxl__egc *egc,
> +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
> +                                pid_t pid, int status);

I suppose that in here there is a sequence of callbacks which get
chained together? Might be worth pulling those out and ordering them in
the normal expected chain of execution?

[...]
> +/*----- synchronous subroutines -----*/
> +
> +static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
> +                                 char *slave_path, size_t slave_path_len)
>  {
> +    STATE_AO_GC(bl);

I wondered about this in the patch which defined it but didn't really
consider it til I saw this user.

I didn't quite realise back then that STATE_AO_GC takes a pointer to a
struct which is user (a libxl internal user, but still) defined and
requires that it has a member "ao". I don't mind that for cases where
the struct is defined alongside the macro as part of a while API but for
separately defined structs its a bit nasty. Could it be:
	STATE_AO_GC(bl->ao)
instead?

I suppose that isn't really a criticism of this patch but rather of the
patch which added the macro, so this patch in itself is:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:32:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:32:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvmA-0002qZ-54; Wed, 11 Apr 2012 11:31:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvm9-0002qS-3l
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:31:49 +0000
Received: from [85.158.143.35:5503] by server-2.bemta-4.messagelabs.com id
	71/51-17550-4AB658F4; Wed, 11 Apr 2012 11:31:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334143906!12756733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11431 invoked from network); 11 Apr 2012 11:31:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:31:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:31:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:31:46 +0100
Message-ID: <1334143904.5394.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:31:44 +0100
In-Reply-To: <1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert
 libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[...]
> +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
> +static void bootloader_keystrokes_copyfail(libxl__egc *egc,
> +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> +static void bootloader_display_copyfail(libxl__egc *egc,
> +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
> +                                pid_t pid, int status);

I suppose that in here there is a sequence of callbacks which get
chained together? Might be worth pulling those out and ordering them in
the normal expected chain of execution?

[...]
> +/*----- synchronous subroutines -----*/
> +
> +static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
> +                                 char *slave_path, size_t slave_path_len)
>  {
> +    STATE_AO_GC(bl);

I wondered about this in the patch which defined it but didn't really
consider it til I saw this user.

I didn't quite realise back then that STATE_AO_GC takes a pointer to a
struct which is user (a libxl internal user, but still) defined and
requires that it has a member "ao". I don't mind that for cases where
the struct is defined alongside the macro as part of a while API but for
separately defined structs its a bit nasty. Could it be:
	STATE_AO_GC(bl->ao)
instead?

I suppose that isn't really a criticism of this patch but rather of the
patch which added the macro, so this patch in itself is:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:33:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvnh-0002yH-PP; Wed, 11 Apr 2012 11:33:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvnf-0002y4-Kv
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:33:23 +0000
Received: from [85.158.138.51:2047] by server-5.bemta-3.messagelabs.com id
	72/FD-17113-20C658F4; Wed, 11 Apr 2012 11:33:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334143999!10666306!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12553 invoked from network); 11 Apr 2012 11:33:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:33:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:33:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:33:18 +0100
Message-ID: <1334143997.5394.140.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:33:17 +0100
In-Reply-To: <20357.26790.965987.73781@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
	<1334142239.5394.116.camel@zakaz.uk.xensource.com>
	<20357.26790.965987.73781@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:19 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*"):
> > On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> > > General facility for ao operations to open ptys.
> ...
> > > +    if (!pid) {
> > > +        /* child */
> > > +        close(sockets[0]);
> > > +        signal(SIGCHLD, SIG_DFL);
> > > +
> > > +        for (i=0; i<count; i++) {
> > > +            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
> > > +            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
> > > +        }
> > > +        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
> > > +                                2*count, &ptyfds[0][0], "ptys");
> > > +        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
> > 
> > Buried in this LOGE is a CTX somewhere, right? Is it valid to keep using
> > it? Perhaps it's OK just for this logging.
> 
> This should be documented somewhere.  But I see it isn't.  The closest
> we have is:
> 
>   * The child should go on to exec (or exit) soon, and should not make
>   * any further libxl event calls in the meantime.
> 
> I have clarified this:
> 
>  * The child should go on to exec (or exit) soon.  The child may not
>  * make any further calls to libxl infrastructure, except for memory
>  * allocation and logging.  If the child needs to use xenstore it
>  * must open its own xs handle and use it directly, rather than via
>  * the libxl event machinery.

Sounds good. I think I had mentally omitted the "event" in the original
too.

> > I suppose we don't need to call the postfork-noexecing handler because
> > we are inside libxl?
> 
> No, we don't need to call it because we're fast ("exit ... soon",
> above).  The worst case is that we hold onto unwanted fds while the
> openpty helper runs etc.

Oh, yes, of course.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:33:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvnh-0002yH-PP; Wed, 11 Apr 2012 11:33:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvnf-0002y4-Kv
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:33:23 +0000
Received: from [85.158.138.51:2047] by server-5.bemta-3.messagelabs.com id
	72/FD-17113-20C658F4; Wed, 11 Apr 2012 11:33:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334143999!10666306!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12553 invoked from network); 11 Apr 2012 11:33:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:33:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:33:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:33:18 +0100
Message-ID: <1334143997.5394.140.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:33:17 +0100
In-Reply-To: <20357.26790.965987.73781@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-29-git-send-email-ian.jackson@eu.citrix.com>
	<1334142239.5394.116.camel@zakaz.uk.xensource.com>
	<20357.26790.965987.73781@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:19 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*"):
> > On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> > > General facility for ao operations to open ptys.
> ...
> > > +    if (!pid) {
> > > +        /* child */
> > > +        close(sockets[0]);
> > > +        signal(SIGCHLD, SIG_DFL);
> > > +
> > > +        for (i=0; i<count; i++) {
> > > +            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
> > > +            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
> > > +        }
> > > +        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
> > > +                                2*count, &ptyfds[0][0], "ptys");
> > > +        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
> > 
> > Buried in this LOGE is a CTX somewhere, right? Is it valid to keep using
> > it? Perhaps it's OK just for this logging.
> 
> This should be documented somewhere.  But I see it isn't.  The closest
> we have is:
> 
>   * The child should go on to exec (or exit) soon, and should not make
>   * any further libxl event calls in the meantime.
> 
> I have clarified this:
> 
>  * The child should go on to exec (or exit) soon.  The child may not
>  * make any further calls to libxl infrastructure, except for memory
>  * allocation and logging.  If the child needs to use xenstore it
>  * must open its own xs handle and use it directly, rather than via
>  * the libxl event machinery.

Sounds good. I think I had mentally omitted the "event" in the original
too.

> > I suppose we don't need to call the postfork-noexecing handler because
> > we are inside libxl?
> 
> No, we don't need to call it because we're fast ("exit ... soon",
> above).  The worst case is that we hold onto unwanted fds while the
> openpty helper runs etc.

Oh, yes, of course.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:34:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvoL-000332-8g; Wed, 11 Apr 2012 11:34:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvoJ-00032j-08
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:34:03 +0000
Received: from [85.158.143.99:44871] by server-3.bemta-4.messagelabs.com id
	D5/49-05853-A2C658F4; Wed, 11 Apr 2012 11:34:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334144041!19796157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8903 invoked from network); 11 Apr 2012 11:34:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:34:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:34:01 +0100
Message-ID: <1334144039.5394.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:33:59 +0100
In-Reply-To: <20357.26932.161008.384380@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
	<1334142894.5394.125.camel@zakaz.uk.xensource.com>
	<20357.26932.161008.384380@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> > On Wed, 2012-04-11 at 12:04 +0100, Ian Jackson wrote:
> > > NB that libxl__ptr_add needs to be rewritten not to be quadratic in
> > > the number of pointrs added (!)
> > 
> > Isn't it O(N) in numbers of pointers?
> 
> Yes, each addition is O(N).  Adding N pointers is O(N^2).

Oh, right, yes.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:34:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvoL-000332-8g; Wed, 11 Apr 2012 11:34:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHvoJ-00032j-08
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:34:03 +0000
Received: from [85.158.143.99:44871] by server-3.bemta-4.messagelabs.com id
	D5/49-05853-A2C658F4; Wed, 11 Apr 2012 11:34:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334144041!19796157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8903 invoked from network); 11 Apr 2012 11:34:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11875954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:34:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:34:01 +0100
Message-ID: <1334144039.5394.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:33:59 +0100
In-Reply-To: <20357.26932.161008.384380@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-11-git-send-email-ian.jackson@eu.citrix.com>
	<1334134921.5394.78.camel@zakaz.uk.xensource.com>
	<20357.23514.59542.527454@mariner.uk.xensource.com>
	<1334141224.5394.106.camel@zakaz.uk.xensource.com>
	<20357.25912.898502.188820@mariner.uk.xensource.com>
	<1334142894.5394.125.camel@zakaz.uk.xensource.com>
	<20357.26932.161008.384380@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on
 malloc failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/31] libxl: Crash (more sensibly) on malloc failure"):
> > On Wed, 2012-04-11 at 12:04 +0100, Ian Jackson wrote:
> > > NB that libxl__ptr_add needs to be rewritten not to be quadratic in
> > > the number of pointrs added (!)
> > 
> > Isn't it O(N) in numbers of pointers?
> 
> Yes, each addition is O(N).  Adding N pointers is O(N^2).

Oh, right, yes.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvtK-0003NG-0b; Wed, 11 Apr 2012 11:39:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHvtJ-0003N8-2C
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:39:13 +0000
Received: from [85.158.143.35:24003] by server-1.bemta-4.messagelabs.com id
	86/60-20925-06D658F4; Wed, 11 Apr 2012 11:39:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334144349!10840955!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 623 invoked from network); 11 Apr 2012 11:39:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:39:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:39:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:39:08 +0100
Date: Wed, 11 Apr 2012 12:42:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
In-Reply-To: <B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
	<B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 11 Apr 2012, Zhang, Xiantao wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, April 11, 2012 12:21 AM
> > To: Lin Ming
> > Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> > Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> > PHYSDEVOP_nr_irqs_gsi
> > 
> > On Tue, 10 Apr 2012, Lin Ming wrote:
> > > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > > This new physdev_op is added for Linux guest kernel to get the
> > > > > correct nr_irqs_gsi value.
> > > >
> > > > I'm not convinced this is really needed - the kernel can work out
> > > > the right number without any hypercall afaict.
> > >
> > > In Linux kernel:
> > >
> > > mp_register_ioapic(...):
> > >
> > >         entries = io_apic_get_redir_entries(idx);
> > >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> > >         gsi_cfg->gsi_base = gsi_base;
> > >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> > >
> > >         /*
> > >          * The number of IO-APIC IRQ registers (== #pins):
> > >          */
> > >         ioapics[idx].nr_registers = entries;
> > >
> > >         if (gsi_cfg->gsi_end >= gsi_top)
> > >                 gsi_top = gsi_cfg->gsi_end + 1;
> > >
> > > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > > value(0xFFFFFFFF) on Xen Dom0 kernel.
> > >
> > > How can we get the correct gsi_top value, which is used to set
> > > nr_irqs_gsi, without hypercall?
> > >
> > > The problem here is we don't have a Xen version of io_apic_read in
> > > Linux kernel.
> > 
> > Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519
> 
> This is not enough, seems fixed value are returned for each read ?

Yes, it looks like we are always returning 0x00170020, that means 24
entries that I guess is correct for the vast majority of io_apics.

We could limit ourselves to adding a comment saying "we assume the
io_apic has 24 redir entries".

Or we could use PHYSDEVOP_apic_read to do an actual io_apic read for
reg 0x1.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvtK-0003NG-0b; Wed, 11 Apr 2012 11:39:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHvtJ-0003N8-2C
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:39:13 +0000
Received: from [85.158.143.35:24003] by server-1.bemta-4.messagelabs.com id
	86/60-20925-06D658F4; Wed, 11 Apr 2012 11:39:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334144349!10840955!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 623 invoked from network); 11 Apr 2012 11:39:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:39:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:39:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:39:08 +0100
Date: Wed, 11 Apr 2012 12:42:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
In-Reply-To: <B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
	<B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 11 Apr 2012, Zhang, Xiantao wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, April 11, 2012 12:21 AM
> > To: Lin Ming
> > Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> > Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> > PHYSDEVOP_nr_irqs_gsi
> > 
> > On Tue, 10 Apr 2012, Lin Ming wrote:
> > > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > > This new physdev_op is added for Linux guest kernel to get the
> > > > > correct nr_irqs_gsi value.
> > > >
> > > > I'm not convinced this is really needed - the kernel can work out
> > > > the right number without any hypercall afaict.
> > >
> > > In Linux kernel:
> > >
> > > mp_register_ioapic(...):
> > >
> > >         entries = io_apic_get_redir_entries(idx);
> > >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> > >         gsi_cfg->gsi_base = gsi_base;
> > >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> > >
> > >         /*
> > >          * The number of IO-APIC IRQ registers (== #pins):
> > >          */
> > >         ioapics[idx].nr_registers = entries;
> > >
> > >         if (gsi_cfg->gsi_end >= gsi_top)
> > >                 gsi_top = gsi_cfg->gsi_end + 1;
> > >
> > > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > > value(0xFFFFFFFF) on Xen Dom0 kernel.
> > >
> > > How can we get the correct gsi_top value, which is used to set
> > > nr_irqs_gsi, without hypercall?
> > >
> > > The problem here is we don't have a Xen version of io_apic_read in
> > > Linux kernel.
> > 
> > Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519
> 
> This is not enough, seems fixed value are returned for each read ?

Yes, it looks like we are always returning 0x00170020, that means 24
entries that I guess is correct for the vast majority of io_apics.

We could limit ourselves to adding a comment saying "we assume the
io_apic has 24 redir entries".

Or we could use PHYSDEVOP_apic_read to do an actual io_apic read for
reg 0x1.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:40:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvu5-0003S4-Ek; Wed, 11 Apr 2012 11:40:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvu4-0003Rs-J2
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:40:00 +0000
Received: from [85.158.138.51:15670] by server-11.bemta-3.messagelabs.com id
	6E/9C-18894-F8D658F4; Wed, 11 Apr 2012 11:39:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334144399!21705966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 455 invoked from network); 11 Apr 2012 11:39:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:39:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvu2-00028R-BV; Wed, 11 Apr 2012 11:39:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvu2-0007rG-5V;
	Wed, 11 Apr 2012 12:39:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.28045.892990.229358@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:39:57 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334143904.5394.139.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
	<1334143904.5394.139.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert
 libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert libxl_run_bootloader"):
> [...]
> > +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
> > +static void bootloader_keystrokes_copyfail(libxl__egc *egc,
> > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > +static void bootloader_display_copyfail(libxl__egc *egc,
> > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
> > +                                pid_t pid, int status);
> 
> I suppose that in here there is a sequence of callbacks which get
> chained together? Might be worth pulling those out and ordering them in
> the normal expected chain of execution?

Yes.  The two "normal" callbacks are gotptys and finished, which
happen in that order.  The copyfail callbacks may happen in between.
So these are already in execution order.

> I wondered about this in the patch which defined it but didn't really
> consider it til I saw this user.
> 
> I didn't quite realise back then that STATE_AO_GC takes a pointer to a
> struct which is user (a libxl internal user, but still) defined and
> requires that it has a member "ao".

This seemed a fine restriction to me, but I'm not wedded to it.

> I don't mind that for cases where
> the struct is defined alongside the macro as part of a while API but for
> separately defined structs its a bit nasty. Could it be:
> 	STATE_AO_GC(bl->ao)
> instead?

So I will do this.  (I have removed your ack from my copy of that
underlying patch.)

> I suppose that isn't really a criticism of this patch but rather of the
> patch which added the macro, so this patch in itself is:

Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:40:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHvu5-0003S4-Ek; Wed, 11 Apr 2012 11:40:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHvu4-0003Rs-J2
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:40:00 +0000
Received: from [85.158.138.51:15670] by server-11.bemta-3.messagelabs.com id
	6E/9C-18894-F8D658F4; Wed, 11 Apr 2012 11:39:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334144399!21705966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 455 invoked from network); 11 Apr 2012 11:39:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 12:39:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHvu2-00028R-BV; Wed, 11 Apr 2012 11:39:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHvu2-0007rG-5V;
	Wed, 11 Apr 2012 12:39:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.28045.892990.229358@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 12:39:57 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334143904.5394.139.camel@zakaz.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
	<1334143904.5394.139.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert
 libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert libxl_run_bootloader"):
> [...]
> > +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
> > +static void bootloader_keystrokes_copyfail(libxl__egc *egc,
> > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > +static void bootloader_display_copyfail(libxl__egc *egc,
> > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
> > +                                pid_t pid, int status);
> 
> I suppose that in here there is a sequence of callbacks which get
> chained together? Might be worth pulling those out and ordering them in
> the normal expected chain of execution?

Yes.  The two "normal" callbacks are gotptys and finished, which
happen in that order.  The copyfail callbacks may happen in between.
So these are already in execution order.

> I wondered about this in the patch which defined it but didn't really
> consider it til I saw this user.
> 
> I didn't quite realise back then that STATE_AO_GC takes a pointer to a
> struct which is user (a libxl internal user, but still) defined and
> requires that it has a member "ao".

This seemed a fine restriction to me, but I'm not wedded to it.

> I don't mind that for cases where
> the struct is defined alongside the macro as part of a while API but for
> separately defined structs its a bit nasty. Could it be:
> 	STATE_AO_GC(bl->ao)
> instead?

So I will do this.  (I have removed your ack from my copy of that
underlying patch.)

> I suppose that isn't really a criticism of this patch but rather of the
> patch which added the macro, so this patch in itself is:

Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:49:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHw34-0003te-Gg; Wed, 11 Apr 2012 11:49:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHw32-0003tZ-GB
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:49:16 +0000
Received: from [85.158.139.83:2092] by server-12.bemta-5.messagelabs.com id
	69/71-05587-BBF658F4; Wed, 11 Apr 2012 11:49:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334144954!18733414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9756 invoked from network); 11 Apr 2012 11:49:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:49:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:49:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:49:14 +0100
Message-ID: <1334144952.5394.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:49:12 +0100
In-Reply-To: <alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
	<B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Lin Ming <mlin@ss.pku.edu.cn>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:42 +0100, Stefano Stabellini wrote:
> On Wed, 11 Apr 2012, Zhang, Xiantao wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, April 11, 2012 12:21 AM
> > > To: Lin Ming
> > > Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> > > Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> > > PHYSDEVOP_nr_irqs_gsi
> > > 
> > > On Tue, 10 Apr 2012, Lin Ming wrote:
> > > > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > > > This new physdev_op is added for Linux guest kernel to get the
> > > > > > correct nr_irqs_gsi value.
> > > > >
> > > > > I'm not convinced this is really needed - the kernel can work out
> > > > > the right number without any hypercall afaict.
> > > >
> > > > In Linux kernel:
> > > >
> > > > mp_register_ioapic(...):
> > > >
> > > >         entries = io_apic_get_redir_entries(idx);
> > > >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> > > >         gsi_cfg->gsi_base = gsi_base;
> > > >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> > > >
> > > >         /*
> > > >          * The number of IO-APIC IRQ registers (== #pins):
> > > >          */
> > > >         ioapics[idx].nr_registers = entries;
> > > >
> > > >         if (gsi_cfg->gsi_end >= gsi_top)
> > > >                 gsi_top = gsi_cfg->gsi_end + 1;
> > > >
> > > > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > > > value(0xFFFFFFFF) on Xen Dom0 kernel.
> > > >
> > > > How can we get the correct gsi_top value, which is used to set
> > > > nr_irqs_gsi, without hypercall?
> > > >
> > > > The problem here is we don't have a Xen version of io_apic_read in
> > > > Linux kernel.
> > > 
> > > Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519

Why was this patch never seen on xen-devel?
 
> > This is not enough, seems fixed value are returned for each read ?
> 
> Yes, it looks like we are always returning 0x00170020, that means 24
> entries that I guess is correct for the vast majority of io_apics.
> 
> We could limit ourselves to adding a comment saying "we assume the
> io_apic has 24 redir entries".
> 
> Or we could use PHYSDEVOP_apic_read to do an actual io_apic read for
> reg 0x1.

This seems like the obviously right thing to do, compared with
hardcoding 24...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:49:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHw34-0003te-Gg; Wed, 11 Apr 2012 11:49:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHw32-0003tZ-GB
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:49:16 +0000
Received: from [85.158.139.83:2092] by server-12.bemta-5.messagelabs.com id
	69/71-05587-BBF658F4; Wed, 11 Apr 2012 11:49:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334144954!18733414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9756 invoked from network); 11 Apr 2012 11:49:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:49:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:49:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:49:14 +0100
Message-ID: <1334144952.5394.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:49:12 +0100
In-Reply-To: <alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
	<B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Lin Ming <mlin@ss.pku.edu.cn>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:42 +0100, Stefano Stabellini wrote:
> On Wed, 11 Apr 2012, Zhang, Xiantao wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, April 11, 2012 12:21 AM
> > > To: Lin Ming
> > > Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> > > Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> > > PHYSDEVOP_nr_irqs_gsi
> > > 
> > > On Tue, 10 Apr 2012, Lin Ming wrote:
> > > > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > > > This new physdev_op is added for Linux guest kernel to get the
> > > > > > correct nr_irqs_gsi value.
> > > > >
> > > > > I'm not convinced this is really needed - the kernel can work out
> > > > > the right number without any hypercall afaict.
> > > >
> > > > In Linux kernel:
> > > >
> > > > mp_register_ioapic(...):
> > > >
> > > >         entries = io_apic_get_redir_entries(idx);
> > > >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> > > >         gsi_cfg->gsi_base = gsi_base;
> > > >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> > > >
> > > >         /*
> > > >          * The number of IO-APIC IRQ registers (== #pins):
> > > >          */
> > > >         ioapics[idx].nr_registers = entries;
> > > >
> > > >         if (gsi_cfg->gsi_end >= gsi_top)
> > > >                 gsi_top = gsi_cfg->gsi_end + 1;
> > > >
> > > > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > > > value(0xFFFFFFFF) on Xen Dom0 kernel.
> > > >
> > > > How can we get the correct gsi_top value, which is used to set
> > > > nr_irqs_gsi, without hypercall?
> > > >
> > > > The problem here is we don't have a Xen version of io_apic_read in
> > > > Linux kernel.
> > > 
> > > Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519

Why was this patch never seen on xen-devel?
 
> > This is not enough, seems fixed value are returned for each read ?
> 
> Yes, it looks like we are always returning 0x00170020, that means 24
> entries that I guess is correct for the vast majority of io_apics.
> 
> We could limit ourselves to adding a comment saying "we assume the
> io_apic has 24 redir entries".
> 
> Or we could use PHYSDEVOP_apic_read to do an actual io_apic read for
> reg 0x1.

This seems like the obviously right thing to do, compared with
hardcoding 24...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:59:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwCK-0004HA-53; Wed, 11 Apr 2012 11:58:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SHwCI-0004H5-T9
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:58:51 +0000
Received: from [85.158.139.83:65283] by server-12.bemta-5.messagelabs.com id
	4D/2E-05587-AF1758F4; Wed, 11 Apr 2012 11:58:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334145529!15981735!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5299 invoked from network); 11 Apr 2012 11:58:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 11:58:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SHwCH-0004XO-5E; Wed, 11 Apr 2012 11:58:49 +0000
Date: Wed, 11 Apr 2012 12:58:49 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120411115849.GA14661@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 12:22 +0100 on 11 Apr (1334146973), Francisco Rocha wrote:
> This part is working.
> 
> I am able to reserve a range of memory and boot a HVM guest 
> that uses pages from that range. The problem is when I try 
> to restrict dom0 from accessing does pages, it fails in allocating 
> the memory to the guest.

Doe sit fail in allocating the memory or in populating it?  Dom0 has to
map the new domain's memory to put the BIOs and firmware in before it
boots. 

> Is get_page_from_l1e always called by dom0?

get_page_from_l1e is called for any pagetables entry (PV or shadowed HVM)
that maps a page of memory.  So it will be called when dom0 triues to
map the memory.

> Can a guest run when dom0 is restricted from 
> accessing its memory? I would only want to restrict access 
> for certain operations.

Dom0 maps domU's memory three times:
 Once (by force) to populate the BIOS &C at buid time.
 In Qemu (again, by force) to emulate domU's hardware.
 In the PV backend drivers (using the grant tables) for block & net I/O.

You can handle the build-time map by allowing them and the making sure
they all get pulled down before the domain is unpaused for the first
time (Or by having a separate trusted/privileged builder domain that
does nothing but build domains).  You can handle the second by using
stub domains to run qemu in a different domain, or by only usoing PV
domUs.  The third is pretty much a requirement if the domU's going to do
any I/O via dom0, but at least with grant tables the ACL is under domU's
control.  Or if you have an IOMMU you can give the domU direct access to
its own network card and disk controller.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 11:59:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 11:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwCK-0004HA-53; Wed, 11 Apr 2012 11:58:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SHwCI-0004H5-T9
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 11:58:51 +0000
Received: from [85.158.139.83:65283] by server-12.bemta-5.messagelabs.com id
	4D/2E-05587-AF1758F4; Wed, 11 Apr 2012 11:58:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334145529!15981735!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5299 invoked from network); 11 Apr 2012 11:58:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 11:58:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SHwCH-0004XO-5E; Wed, 11 Apr 2012 11:58:49 +0000
Date: Wed, 11 Apr 2012 12:58:49 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120411115849.GA14661@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 12:22 +0100 on 11 Apr (1334146973), Francisco Rocha wrote:
> This part is working.
> 
> I am able to reserve a range of memory and boot a HVM guest 
> that uses pages from that range. The problem is when I try 
> to restrict dom0 from accessing does pages, it fails in allocating 
> the memory to the guest.

Doe sit fail in allocating the memory or in populating it?  Dom0 has to
map the new domain's memory to put the BIOs and firmware in before it
boots. 

> Is get_page_from_l1e always called by dom0?

get_page_from_l1e is called for any pagetables entry (PV or shadowed HVM)
that maps a page of memory.  So it will be called when dom0 triues to
map the memory.

> Can a guest run when dom0 is restricted from 
> accessing its memory? I would only want to restrict access 
> for certain operations.

Dom0 maps domU's memory three times:
 Once (by force) to populate the BIOS &C at buid time.
 In Qemu (again, by force) to emulate domU's hardware.
 In the PV backend drivers (using the grant tables) for block & net I/O.

You can handle the build-time map by allowing them and the making sure
they all get pulled down before the domain is unpaused for the first
time (Or by having a separate trusted/privileged builder domain that
does nothing but build domains).  You can handle the second by using
stub domains to run qemu in a different domain, or by only usoing PV
domUs.  The third is pretty much a requirement if the domU's going to do
any I/O via dom0, but at least with grant tables the ACL is under domU's
control.  Or if you have an IOMMU you can give the domU direct access to
its own network card and disk controller.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:02:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwFq-0004Yx-Od; Wed, 11 Apr 2012 12:02:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SHwFo-0004Yc-OA
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:02:28 +0000
Received: from [85.158.138.51:49551] by server-9.bemta-3.messagelabs.com id
	CB/5B-26691-3D2758F4; Wed, 11 Apr 2012 12:02:27 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334145745!21672959!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5644 invoked from network); 11 Apr 2012 12:02:26 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:02:26 -0000
Received: by vcbfl15 with SMTP id fl15so631170vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 05:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=n6pGs4df1zY5DyxXfG5o+zzxnmgIF1kFlwyvvgtsRT4=;
	b=moHZw0jhz+NYKTRBLj9ywprgjrt9Abw/pvurfIvjA2Y9W0FPKjJXEJt9C9i19Togux
	/syPqK/2mALi3cvzFlclReTOhYwGt874XvgApFwYDVggp3+kmqMBTQj5PS6t6PC6Gc4Q
	sP83c/POybKfQ6mH3K2MHhJ6GQfOWgQVQl9jbjEDgCLZsUvnaooOKYKVuZcicgfAgNHi
	+ArDeqFB4To//pvKgoh8NDr+UwlWuuL4qWU8fGNEFzwkiU4HvU5HX/k9r6FU38G+L6dr
	soeik10JsZ9j/zS+heMeDn/q2Bh6CCOHcBmr94O8onCefkBCQO39oApnXL7YHuXRO9cU
	oXdg==
MIME-Version: 1.0
Received: by 10.220.38.8 with SMTP id z8mr8226258vcd.68.1334145745069; Wed, 11
	Apr 2012 05:02:25 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Wed, 11 Apr 2012 05:02:24 -0700 (PDT)
In-Reply-To: <20120410121344.GA1955@ocelot.phlegethon.org>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
	<20120410121344.GA1955@ocelot.phlegethon.org>
Date: Wed, 11 Apr 2012 21:02:24 +0900
Message-ID: <CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: g@phlegethon.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 9:13 PM, Tim Deegan <tim@xen.org> wrote:
> At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
>> Hello All,
>>
>> I am writing the PV-Drivers for Seabios.
>>
>> When I put a request on the front ring and issue the hypercall to
>> notify, the hvm guest crashes.
>>
>> Here is the dmesg output:
>>
>> (XEN) realmode.c:116:d10 Failed to emulate insn.
>> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
>> 0f aa ba b2 00 ec
>
> 0F AA is RSM, which is a pretty surprising instruction to find in a
> hypercall invocation -- or indeed anywhere outside machine-specific SMM
> code. =A0Is there SMM code in SeaBIOS? =A0It may be that you've ended up
> jumping to a misaligned instruction boundary.
>
>> Nothing out of the ordinary. Except that the hypercall is issued under
>> 16bit, It works under 32bit.
>
> Are you using the hypercall page to make your hypercall? =A0Its contents
> don't make sense in 16-bit mode, only in 32-bit and 64-bit. =A0Since the
> register arguments are 32-bit anyway you might want to make all your
> hypercalls from 32-bit code anyway; otherwise you'll need to make your
> own 16-bit stubs, with the right prefixes for the MOV imm32.

I have no idea how to fix this :(
>
> Cheers,
>
> Tim.



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:02:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwFq-0004Yx-Od; Wed, 11 Apr 2012 12:02:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SHwFo-0004Yc-OA
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:02:28 +0000
Received: from [85.158.138.51:49551] by server-9.bemta-3.messagelabs.com id
	CB/5B-26691-3D2758F4; Wed, 11 Apr 2012 12:02:27 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334145745!21672959!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5644 invoked from network); 11 Apr 2012 12:02:26 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:02:26 -0000
Received: by vcbfl15 with SMTP id fl15so631170vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 05:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=n6pGs4df1zY5DyxXfG5o+zzxnmgIF1kFlwyvvgtsRT4=;
	b=moHZw0jhz+NYKTRBLj9ywprgjrt9Abw/pvurfIvjA2Y9W0FPKjJXEJt9C9i19Togux
	/syPqK/2mALi3cvzFlclReTOhYwGt874XvgApFwYDVggp3+kmqMBTQj5PS6t6PC6Gc4Q
	sP83c/POybKfQ6mH3K2MHhJ6GQfOWgQVQl9jbjEDgCLZsUvnaooOKYKVuZcicgfAgNHi
	+ArDeqFB4To//pvKgoh8NDr+UwlWuuL4qWU8fGNEFzwkiU4HvU5HX/k9r6FU38G+L6dr
	soeik10JsZ9j/zS+heMeDn/q2Bh6CCOHcBmr94O8onCefkBCQO39oApnXL7YHuXRO9cU
	oXdg==
MIME-Version: 1.0
Received: by 10.220.38.8 with SMTP id z8mr8226258vcd.68.1334145745069; Wed, 11
	Apr 2012 05:02:25 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Wed, 11 Apr 2012 05:02:24 -0700 (PDT)
In-Reply-To: <20120410121344.GA1955@ocelot.phlegethon.org>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
	<20120410121344.GA1955@ocelot.phlegethon.org>
Date: Wed, 11 Apr 2012 21:02:24 +0900
Message-ID: <CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: g@phlegethon.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 9:13 PM, Tim Deegan <tim@xen.org> wrote:
> At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
>> Hello All,
>>
>> I am writing the PV-Drivers for Seabios.
>>
>> When I put a request on the front ring and issue the hypercall to
>> notify, the hvm guest crashes.
>>
>> Here is the dmesg output:
>>
>> (XEN) realmode.c:116:d10 Failed to emulate insn.
>> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
>> 0f aa ba b2 00 ec
>
> 0F AA is RSM, which is a pretty surprising instruction to find in a
> hypercall invocation -- or indeed anywhere outside machine-specific SMM
> code. =A0Is there SMM code in SeaBIOS? =A0It may be that you've ended up
> jumping to a misaligned instruction boundary.
>
>> Nothing out of the ordinary. Except that the hypercall is issued under
>> 16bit, It works under 32bit.
>
> Are you using the hypercall page to make your hypercall? =A0Its contents
> don't make sense in 16-bit mode, only in 32-bit and 64-bit. =A0Since the
> register arguments are 32-bit anyway you might want to make all your
> hypercalls from 32-bit code anyway; otherwise you'll need to make your
> own 16-bit stubs, with the right prefixes for the MOV imm32.

I have no idea how to fix this :(
>
> Cheers,
>
> Tim.



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:06:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwJm-0004oz-DS; Wed, 11 Apr 2012 12:06:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHwJl-0004ou-17
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:06:33 +0000
Received: from [85.158.143.35:31693] by server-2.bemta-4.messagelabs.com id
	55/6C-17550-8C3758F4; Wed, 11 Apr 2012 12:06:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334145991!18110469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20077 invoked from network); 11 Apr 2012 12:06:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:06:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:06:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 13:06:31 +0100
Message-ID: <1334145989.16387.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Wed, 11 Apr 2012 13:06:29 +0100
In-Reply-To: <CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
	<20120410121344.GA1955@ocelot.phlegethon.org>
	<CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "g@phlegethon.org" <g@phlegethon.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 13:02 +0100, Daniel Castro wrote:
> On Tue, Apr 10, 2012 at 9:13 PM, Tim Deegan <tim@xen.org> wrote:
> > At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
> >> Hello All,
> >>
> >> I am writing the PV-Drivers for Seabios.
> >>
> >> When I put a request on the front ring and issue the hypercall to
> >> notify, the hvm guest crashes.
> >>
> >> Here is the dmesg output:
> >>
> >> (XEN) realmode.c:116:d10 Failed to emulate insn.
> >> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
> >> 0f aa ba b2 00 ec
> >
> > 0F AA is RSM, which is a pretty surprising instruction to find in a
> > hypercall invocation -- or indeed anywhere outside machine-specific SMM
> > code.  Is there SMM code in SeaBIOS?  It may be that you've ended up
> > jumping to a misaligned instruction boundary.
> >
> >> Nothing out of the ordinary. Except that the hypercall is issued under
> >> 16bit, It works under 32bit.
> >
> > Are you using the hypercall page to make your hypercall?  Its contents
> > don't make sense in 16-bit mode, only in 32-bit and 64-bit.  Since the
> > register arguments are 32-bit anyway you might want to make all your
> > hypercalls from 32-bit code anyway; otherwise you'll need to make your
> > own 16-bit stubs, with the right prefixes for the MOV imm32.
> 
> I have no idea how to fix this :(

It's looking likely that you'll have to go to 32 bit mode to do all of
the actual I/O associated with the PV devices. That ought to simplify a
bunch of stuff WRT handling the rings etc too.

Ian.
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:06:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwJm-0004oz-DS; Wed, 11 Apr 2012 12:06:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHwJl-0004ou-17
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:06:33 +0000
Received: from [85.158.143.35:31693] by server-2.bemta-4.messagelabs.com id
	55/6C-17550-8C3758F4; Wed, 11 Apr 2012 12:06:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334145991!18110469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20077 invoked from network); 11 Apr 2012 12:06:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:06:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:06:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 13:06:31 +0100
Message-ID: <1334145989.16387.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Wed, 11 Apr 2012 13:06:29 +0100
In-Reply-To: <CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
	<20120410121344.GA1955@ocelot.phlegethon.org>
	<CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "g@phlegethon.org" <g@phlegethon.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 13:02 +0100, Daniel Castro wrote:
> On Tue, Apr 10, 2012 at 9:13 PM, Tim Deegan <tim@xen.org> wrote:
> > At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
> >> Hello All,
> >>
> >> I am writing the PV-Drivers for Seabios.
> >>
> >> When I put a request on the front ring and issue the hypercall to
> >> notify, the hvm guest crashes.
> >>
> >> Here is the dmesg output:
> >>
> >> (XEN) realmode.c:116:d10 Failed to emulate insn.
> >> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
> >> 0f aa ba b2 00 ec
> >
> > 0F AA is RSM, which is a pretty surprising instruction to find in a
> > hypercall invocation -- or indeed anywhere outside machine-specific SMM
> > code.  Is there SMM code in SeaBIOS?  It may be that you've ended up
> > jumping to a misaligned instruction boundary.
> >
> >> Nothing out of the ordinary. Except that the hypercall is issued under
> >> 16bit, It works under 32bit.
> >
> > Are you using the hypercall page to make your hypercall?  Its contents
> > don't make sense in 16-bit mode, only in 32-bit and 64-bit.  Since the
> > register arguments are 32-bit anyway you might want to make all your
> > hypercalls from 32-bit code anyway; otherwise you'll need to make your
> > own 16-bit stubs, with the right prefixes for the MOV imm32.
> 
> I have no idea how to fix this :(

It's looking likely that you'll have to go to 32 bit mode to do all of
the actual I/O associated with the PV devices. That ought to simplify a
bunch of stuff WRT handling the rings etc too.

Ian.
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:07:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwKc-0004se-RI; Wed, 11 Apr 2012 12:07:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHwKc-0004sV-0F
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:07:26 +0000
Received: from [85.158.143.99:60114] by server-3.bemta-4.messagelabs.com id
	C1/54-05853-DF3758F4; Wed, 11 Apr 2012 12:07:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334144758!12484641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28838 invoked from network); 11 Apr 2012 11:45:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:45:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:45:33 +0100
Message-ID: <1334144732.5394.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:45:32 +0100
In-Reply-To: <20357.28045.892990.229358@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
	<1334143904.5394.139.camel@zakaz.uk.xensource.com>
	<20357.28045.892990.229358@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert
 libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:39 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert libxl_run_bootloader"):
> > [...]
> > > +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
> > > +static void bootloader_keystrokes_copyfail(libxl__egc *egc,
> > > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > > +static void bootloader_display_copyfail(libxl__egc *egc,
> > > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > > +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
> > > +                                pid_t pid, int status);
> > 
> > I suppose that in here there is a sequence of callbacks which get
> > chained together? Might be worth pulling those out and ordering them in
> > the normal expected chain of execution?
> 
> Yes.  The two "normal" callbacks are gotptys and finished, which
> happen in that order.  The copyfail callbacks may happen in between.
> So these are already in execution order.

Oh, good then. I suppose that proves that ordering them that way is not
as helpful as I thought it would be ;-)

> > I wondered about this in the patch which defined it but didn't really
> > consider it til I saw this user.
> > 
> > I didn't quite realise back then that STATE_AO_GC takes a pointer to a
> > struct which is user (a libxl internal user, but still) defined and
> > requires that it has a member "ao".
> 
> This seemed a fine restriction to me, but I'm not wedded to it.
> 
> > I don't mind that for cases where
> > the struct is defined alongside the macro as part of a while API but for
> > separately defined structs its a bit nasty. Could it be:
> > 	STATE_AO_GC(bl->ao)
> > instead?
> 
> So I will do this.  (I have removed your ack from my copy of that
> underlying patch.)

Thanks, sorry for prematurely Acking that patch.

FWIW, with the change above you could put it back...

> 
> > I suppose that isn't really a criticism of this patch but rather of the
> > patch which added the macro, so this patch in itself is:
> 
> Thanks.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:07:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwKc-0004se-RI; Wed, 11 Apr 2012 12:07:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHwKc-0004sV-0F
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:07:26 +0000
Received: from [85.158.143.99:60114] by server-3.bemta-4.messagelabs.com id
	C1/54-05853-DF3758F4; Wed, 11 Apr 2012 12:07:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334144758!12484641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28838 invoked from network); 11 Apr 2012 11:45:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 11:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,405,1330905600"; d="scan'208";a="11876186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 11:45:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:45:33 +0100
Message-ID: <1334144732.5394.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 12:45:32 +0100
In-Reply-To: <20357.28045.892990.229358@mariner.uk.xensource.com>
References: <1334084885-14474-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334084885-14474-30-git-send-email-ian.jackson@eu.citrix.com>
	<1334143904.5394.139.camel@zakaz.uk.xensource.com>
	<20357.28045.892990.229358@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert
 libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 12:39 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 29/31] libxl: ao: Convert libxl_run_bootloader"):
> > [...]
> > > +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
> > > +static void bootloader_keystrokes_copyfail(libxl__egc *egc,
> > > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > > +static void bootloader_display_copyfail(libxl__egc *egc,
> > > +       libxl__datacopier_state *dc, int onwrite, int errnoval);
> > > +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
> > > +                                pid_t pid, int status);
> > 
> > I suppose that in here there is a sequence of callbacks which get
> > chained together? Might be worth pulling those out and ordering them in
> > the normal expected chain of execution?
> 
> Yes.  The two "normal" callbacks are gotptys and finished, which
> happen in that order.  The copyfail callbacks may happen in between.
> So these are already in execution order.

Oh, good then. I suppose that proves that ordering them that way is not
as helpful as I thought it would be ;-)

> > I wondered about this in the patch which defined it but didn't really
> > consider it til I saw this user.
> > 
> > I didn't quite realise back then that STATE_AO_GC takes a pointer to a
> > struct which is user (a libxl internal user, but still) defined and
> > requires that it has a member "ao".
> 
> This seemed a fine restriction to me, but I'm not wedded to it.
> 
> > I don't mind that for cases where
> > the struct is defined alongside the macro as part of a while API but for
> > separately defined structs its a bit nasty. Could it be:
> > 	STATE_AO_GC(bl->ao)
> > instead?
> 
> So I will do this.  (I have removed your ack from my copy of that
> underlying patch.)

Thanks, sorry for prematurely Acking that patch.

FWIW, with the change above you could put it back...

> 
> > I suppose that isn't really a criticism of this patch but rather of the
> > patch which added the macro, so this patch in itself is:
> 
> Thanks.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:25:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwbO-0005mO-SI; Wed, 11 Apr 2012 12:24:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SHwbN-0005mC-5W
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:24:45 +0000
Received: from [85.158.138.51:54665] by server-12.bemta-3.messagelabs.com id
	36/89-29760-C08758F4; Wed, 11 Apr 2012 12:24:44 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334147082!21641808!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25912 invoked from network); 11 Apr 2012 12:24:43 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:24:43 -0000
Received: by vbbfq11 with SMTP id fq11so658942vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 05:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=PQk5Pgtvz/sJWyqXex5EObYYEAh2tut6AiE1v2M6kaY=;
	b=xVwR61SjJMusmSvUa5q0KRKyOOotJ9XGoeEG06eBAJOk1KwOlIZrb1OSIqXYIJCswj
	g4nSbOTKkvmq7eSaclUZkiTl289PWTXcqhd/YmZ6u46u7GO4jXLG1TkLi2HH8a0lgy2e
	5qIqGV99HmHXH9rnv/q/UMhQoyNhJ5Fp3TkA8s+nlvUS0dkJwNC08whh7ZkE37oqTlNr
	yNvvqmtu5JHtlyLwtvkzfV9miLA9t/uLvnNwUor73Ih8LJrSRkjYYX55+w/Ir7fsFp8Z
	/1xVAqc83I4Ur0YOt74E0rS/pcmBj8TqiD8MPloiaNMmoaqgKBLu+XXnkti7ngVPa5gp
	YKCQ==
MIME-Version: 1.0
Received: by 10.220.59.3 with SMTP id j3mr8240401vch.58.1334147081560; Wed, 11
	Apr 2012 05:24:41 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Wed, 11 Apr 2012 05:24:41 -0700 (PDT)
In-Reply-To: <1334145989.16387.7.camel@zakaz.uk.xensource.com>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
	<20120410121344.GA1955@ocelot.phlegethon.org>
	<CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
	<1334145989.16387.7.camel@zakaz.uk.xensource.com>
Date: Wed, 11 Apr 2012 21:24:41 +0900
Message-ID: <CAP2B859XfBRU+APY_2M_-rDRaaarLw_BSKK3gDfbipeVAHzjtQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 9:06 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Wed, 2012-04-11 at 13:02 +0100, Daniel Castro wrote:
>> On Tue, Apr 10, 2012 at 9:13 PM, Tim Deegan <tim@xen.org> wrote:
>> > At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
>> >> Hello All,
>> >>
>> >> I am writing the PV-Drivers for Seabios.
>> >>
>> >> When I put a request on the front ring and issue the hypercall to
>> >> notify, the hvm guest crashes.
>> >>
>> >> Here is the dmesg output:
>> >>
>> >> (XEN) realmode.c:116:d10 Failed to emulate insn.
>> >> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
>> >> 0f aa ba b2 00 ec
>> >
>> > 0F AA is RSM, which is a pretty surprising instruction to find in a
>> > hypercall invocation -- or indeed anywhere outside machine-specific SMM
>> > code. =A0Is there SMM code in SeaBIOS? =A0It may be that you've ended =
up
>> > jumping to a misaligned instruction boundary.
>> >
>> >> Nothing out of the ordinary. Except that the hypercall is issued under
>> >> 16bit, It works under 32bit.
>> >
>> > Are you using the hypercall page to make your hypercall? =A0Its conten=
ts
>> > don't make sense in 16-bit mode, only in 32-bit and 64-bit. =A0Since t=
he
>> > register arguments are 32-bit anyway you might want to make all your
>> > hypercalls from 32-bit code anyway; otherwise you'll need to make your
>> > own 16-bit stubs, with the right prefixes for the MOV imm32.
>>
>> I have no idea how to fix this :(
>
> It's looking likely that you'll have to go to 32 bit mode to do all of
> the actual I/O associated with the PV devices. That ought to simplify a
> bunch of stuff WRT handling the rings etc too.

What are my choices?
1. Add support for 16bit hypercalls on Xen.
2. Jump to 32 bit
3. make a 16bit "special" hypercall on SeaBIOS
4. Any other choice?

Thanks to all the comments.

>
> Ian.
>
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:25:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwbO-0005mO-SI; Wed, 11 Apr 2012 12:24:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SHwbN-0005mC-5W
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:24:45 +0000
Received: from [85.158.138.51:54665] by server-12.bemta-3.messagelabs.com id
	36/89-29760-C08758F4; Wed, 11 Apr 2012 12:24:44 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334147082!21641808!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25912 invoked from network); 11 Apr 2012 12:24:43 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:24:43 -0000
Received: by vbbfq11 with SMTP id fq11so658942vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 05:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=PQk5Pgtvz/sJWyqXex5EObYYEAh2tut6AiE1v2M6kaY=;
	b=xVwR61SjJMusmSvUa5q0KRKyOOotJ9XGoeEG06eBAJOk1KwOlIZrb1OSIqXYIJCswj
	g4nSbOTKkvmq7eSaclUZkiTl289PWTXcqhd/YmZ6u46u7GO4jXLG1TkLi2HH8a0lgy2e
	5qIqGV99HmHXH9rnv/q/UMhQoyNhJ5Fp3TkA8s+nlvUS0dkJwNC08whh7ZkE37oqTlNr
	yNvvqmtu5JHtlyLwtvkzfV9miLA9t/uLvnNwUor73Ih8LJrSRkjYYX55+w/Ir7fsFp8Z
	/1xVAqc83I4Ur0YOt74E0rS/pcmBj8TqiD8MPloiaNMmoaqgKBLu+XXnkti7ngVPa5gp
	YKCQ==
MIME-Version: 1.0
Received: by 10.220.59.3 with SMTP id j3mr8240401vch.58.1334147081560; Wed, 11
	Apr 2012 05:24:41 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Wed, 11 Apr 2012 05:24:41 -0700 (PDT)
In-Reply-To: <1334145989.16387.7.camel@zakaz.uk.xensource.com>
References: <CAP2B85-gvjJ4qbP2Lyz6qEtOb2Gzs6F_EMVHkD5K73KeFHJV1A@mail.gmail.com>
	<20120410121344.GA1955@ocelot.phlegethon.org>
	<CAP2B859SaKU6YD3=DPuC8ceofz7uHgjodjDfMv5sW5U=xVQgvw@mail.gmail.com>
	<1334145989.16387.7.camel@zakaz.uk.xensource.com>
Date: Wed, 11 Apr 2012 21:24:41 +0900
Message-ID: <CAP2B859XfBRU+APY_2M_-rDRaaarLw_BSKK3gDfbipeVAHzjtQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 9:06 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Wed, 2012-04-11 at 13:02 +0100, Daniel Castro wrote:
>> On Tue, Apr 10, 2012 at 9:13 PM, Tim Deegan <tim@xen.org> wrote:
>> > At 20:30 +0900 on 10 Apr (1334089815), Daniel Castro wrote:
>> >> Hello All,
>> >>
>> >> I am writing the PV-Drivers for Seabios.
>> >>
>> >> When I put a request on the front ring and issue the hypercall to
>> >> notify, the hvm guest crashes.
>> >>
>> >> Here is the dmesg output:
>> >>
>> >> (XEN) realmode.c:116:d10 Failed to emulate insn.
>> >> (XEN) realmode.c:166:d10 Real-mode emulation failed @ f000:00001c4b:
>> >> 0f aa ba b2 00 ec
>> >
>> > 0F AA is RSM, which is a pretty surprising instruction to find in a
>> > hypercall invocation -- or indeed anywhere outside machine-specific SMM
>> > code. =A0Is there SMM code in SeaBIOS? =A0It may be that you've ended =
up
>> > jumping to a misaligned instruction boundary.
>> >
>> >> Nothing out of the ordinary. Except that the hypercall is issued under
>> >> 16bit, It works under 32bit.
>> >
>> > Are you using the hypercall page to make your hypercall? =A0Its conten=
ts
>> > don't make sense in 16-bit mode, only in 32-bit and 64-bit. =A0Since t=
he
>> > register arguments are 32-bit anyway you might want to make all your
>> > hypercalls from 32-bit code anyway; otherwise you'll need to make your
>> > own 16-bit stubs, with the right prefixes for the MOV imm32.
>>
>> I have no idea how to fix this :(
>
> It's looking likely that you'll have to go to 32 bit mode to do all of
> the actual I/O associated with the PV devices. That ought to simplify a
> bunch of stuff WRT handling the rings etc too.

What are my choices?
1. Add support for 16bit hypercalls on Xen.
2. Jump to 32 bit
3. make a 16bit "special" hypercall on SeaBIOS
4. Any other choice?

Thanks to all the comments.

>
> Ian.
>
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwv5-0006SN-Aj; Wed, 11 Apr 2012 12:45:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHwv4-0006SG-C7
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:45:06 +0000
Received: from [85.158.139.83:51350] by server-12.bemta-5.messagelabs.com id
	B1/0B-05587-1DC758F4; Wed, 11 Apr 2012 12:45:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334148304!22671617!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12108 invoked from network); 11 Apr 2012 12:45:04 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:45:04 -0000
Received: by wibhj13 with SMTP id hj13so3798505wib.6
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 05:45:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oP7ytLp6zpmWhGM4q+qIusARK7qrbnx4FSw0m0yVvXI=;
	b=LC/hvRjS+M/y/WWulFU47ofYMSM6LnWiEgw2XICohBpLoNZZt0eXqvSmQ+X36/DAp8
	fiUJwkiIH6UE0bSmqtrn3Eyn0TPWphcKcuvuLl7Y/1Tq3tqTGVwYe3Vh812IeH3PgV0J
	Emb8MJwDp9SXlmL5XQOEL4sCWMh5UNu76fU/R+0MpgiIGQNDGrTwnuFH+fxsnIXkY2wT
	0+YvXEkZrccVHcoQ0s1aaax0ckAeBd3zIR1q68q3A+PP7oJ3FwHSvlvZcL1UaQ6TAivj
	6serZJ+9L20+Fja9tATSeFz44q2orJJrIyb8Wyhw7J8DpMe8MK4kpmTQZPxgEgVrHg7W
	bwrQ==
Received: by 10.216.52.8 with SMTP id d8mr501493wec.104.1334148302534;
	Wed, 11 Apr 2012 05:45:02 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60]) by mx.google.com with ESMTPS id
	ev10sm24407723wid.10.2012.04.11.05.45.01
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 05:45:02 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Apr 2012 13:44:54 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel Castro <evil.dani@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CBAB3B56.3D923%keir@xen.org>
Thread-Topic: [Xen-devel] hvm crash on hypercall event channel
Thread-Index: Ac0X4OSowbAShyh6wUayx+YlmeL5kA==
In-Reply-To: <CAP2B859XfBRU+APY_2M_-rDRaaarLw_BSKK3gDfbipeVAHzjtQ@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2012 13:24, "Daniel Castro" <evil.dani@gmail.com> wrote:

>> It's looking likely that you'll have to go to 32 bit mode to do all of
>> the actual I/O associated with the PV devices. That ought to simplify a
>> bunch of stuff WRT handling the rings etc too.
> 
> What are my choices?
> 1. Add support for 16bit hypercalls on Xen.
> 2. Jump to 32 bit

I think this is best. Compile the 32-bit drivers as 32-bit code, then use
stubs to transfer between 16-bit and 32-bit execution modes at run time. Our
old rombios has code you could borrow for this, if seabios doesn't already
have such functionality.

 -- Keir

> 3. make a 16bit "special" hypercall on SeaBIOS
> 4. Any other choice?
> 
> Thanks to all the comments.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHwv5-0006SN-Aj; Wed, 11 Apr 2012 12:45:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SHwv4-0006SG-C7
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 12:45:06 +0000
Received: from [85.158.139.83:51350] by server-12.bemta-5.messagelabs.com id
	B1/0B-05587-1DC758F4; Wed, 11 Apr 2012 12:45:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334148304!22671617!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12108 invoked from network); 11 Apr 2012 12:45:04 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:45:04 -0000
Received: by wibhj13 with SMTP id hj13so3798505wib.6
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 05:45:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oP7ytLp6zpmWhGM4q+qIusARK7qrbnx4FSw0m0yVvXI=;
	b=LC/hvRjS+M/y/WWulFU47ofYMSM6LnWiEgw2XICohBpLoNZZt0eXqvSmQ+X36/DAp8
	fiUJwkiIH6UE0bSmqtrn3Eyn0TPWphcKcuvuLl7Y/1Tq3tqTGVwYe3Vh812IeH3PgV0J
	Emb8MJwDp9SXlmL5XQOEL4sCWMh5UNu76fU/R+0MpgiIGQNDGrTwnuFH+fxsnIXkY2wT
	0+YvXEkZrccVHcoQ0s1aaax0ckAeBd3zIR1q68q3A+PP7oJ3FwHSvlvZcL1UaQ6TAivj
	6serZJ+9L20+Fja9tATSeFz44q2orJJrIyb8Wyhw7J8DpMe8MK4kpmTQZPxgEgVrHg7W
	bwrQ==
Received: by 10.216.52.8 with SMTP id d8mr501493wec.104.1334148302534;
	Wed, 11 Apr 2012 05:45:02 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60]) by mx.google.com with ESMTPS id
	ev10sm24407723wid.10.2012.04.11.05.45.01
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 05:45:02 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Apr 2012 13:44:54 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel Castro <evil.dani@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CBAB3B56.3D923%keir@xen.org>
Thread-Topic: [Xen-devel] hvm crash on hypercall event channel
Thread-Index: Ac0X4OSowbAShyh6wUayx+YlmeL5kA==
In-Reply-To: <CAP2B859XfBRU+APY_2M_-rDRaaarLw_BSKK3gDfbipeVAHzjtQ@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2012 13:24, "Daniel Castro" <evil.dani@gmail.com> wrote:

>> It's looking likely that you'll have to go to 32 bit mode to do all of
>> the actual I/O associated with the PV devices. That ought to simplify a
>> bunch of stuff WRT handling the rings etc too.
> 
> What are my choices?
> 1. Add support for 16bit hypercalls on Xen.
> 2. Jump to 32 bit

I think this is best. Compile the 32-bit drivers as 32-bit code, then use
stubs to transfer between 16-bit and 32-bit execution modes at run time. Our
old rombios has code you could borrow for this, if seabios doesn't already
have such functionality.

 -- Keir

> 3. make a 16bit "special" hypercall on SeaBIOS
> 4. Any other choice?
> 
> Thanks to all the comments.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:55:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx4V-0006fP-CI; Wed, 11 Apr 2012 12:54:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHx4T-0006fK-GP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:54:49 +0000
Received: from [85.158.143.35:59208] by server-2.bemta-4.messagelabs.com id
	26/0E-17550-81F758F4; Wed, 11 Apr 2012 12:54:48 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334148887!9475370!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNDE2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27930 invoked from network); 11 Apr 2012 12:54:47 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 12:54:47 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHx4R-0002sO-D5; Wed, 11 Apr 2012 13:54:47 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 11 Apr 2012
	13:53:15 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 11 Apr 2012 13:53:15 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0X2nnLgP+cEHVPRZqpMti6D+NflgABgiFr
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>,
	<20120411115849.GA14661@ocelot.phlegethon.org>
In-Reply-To: <20120411115849.GA14661@ocelot.phlegethon.org>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Tim Deegan [tim@xen.org]
Sent: 11 April 2012 12:58
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] reserve e820 ram

Hi,

At 12:22 +0100 on 11 Apr (1334146973), Francisco Rocha wrote:
> This part is working.
>
> I am able to reserve a range of memory and boot a HVM guest
> that uses pages from that range. The problem is when I try
> to restrict dom0 from accessing does pages, it fails in allocating
> the memory to the guest.

Doe sit fail in allocating the memory or in populating it?  Dom0 has to
map the new domain's memory to put the BIOs and firmware in before it
boots.

Sorry, it allocates the memory but fails when trying to populate it.
This happened because I changed get_page_from_l1e to restrict access.

> Is get_page_from_l1e always called by dom0?

get_page_from_l1e is called for any pagetables entry (PV or shadowed HVM)
that maps a page of memory.  So it will be called when dom0 triues to
map the memory.

Thank you.

> Can a guest run when dom0 is restricted from
> accessing its memory? I would only want to restrict access
> for certain operations.

Dom0 maps domU's memory three times:
 Once (by force) to populate the BIOS &C at buid time.
 In Qemu (again, by force) to emulate domU's hardware.
 In the PV backend drivers (using the grant tables) for block & net I/O.

You can handle the build-time map by allowing them and the making sure
they all get pulled down before the domain is unpaused for the first
time (Or by having a separate trusted/privileged builder domain that
does nothing but build domains).

All right, I will look for this stage in the code.

You can handle the second by using
stub domains to run qemu in a different domain, or by only usoing PV
domUs.

If I use the stub domain provided with xen the dom0 will not perform the 
second mapping, right?

The third is pretty much a requirement if the domU's going to do
any I/O via dom0, but at least with grant tables the ACL is under domU's
control.  Or if you have an IOMMU you can give the domU direct access to
its own network card and disk controller.

I only have one ethernet card but i can get an ethernet expresscard.

Can I do this in my the machine that gives me the output that follows?

(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.

The not enabled means I should enable them in the BIOS?
Because I have looked everywhere and I can't find any other 
options realted to VT-d.

(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB

Cheers,

Tim.

Thank you for the help Tim! Cheers,

Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 12:55:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 12:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx4V-0006fP-CI; Wed, 11 Apr 2012 12:54:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHx4T-0006fK-GP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:54:49 +0000
Received: from [85.158.143.35:59208] by server-2.bemta-4.messagelabs.com id
	26/0E-17550-81F758F4; Wed, 11 Apr 2012 12:54:48 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334148887!9475370!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAxNDE2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27930 invoked from network); 11 Apr 2012 12:54:47 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 12:54:47 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SHx4R-0002sO-D5; Wed, 11 Apr 2012 13:54:47 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 11 Apr 2012
	13:53:15 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 11 Apr 2012 13:53:15 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0X2nnLgP+cEHVPRZqpMti6D+NflgABgiFr
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B69F@EXCCR03.campus.ncl.ac.uk>,
	<20120411115849.GA14661@ocelot.phlegethon.org>
In-Reply-To: <20120411115849.GA14661@ocelot.phlegethon.org>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Tim Deegan [tim@xen.org]
Sent: 11 April 2012 12:58
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] reserve e820 ram

Hi,

At 12:22 +0100 on 11 Apr (1334146973), Francisco Rocha wrote:
> This part is working.
>
> I am able to reserve a range of memory and boot a HVM guest
> that uses pages from that range. The problem is when I try
> to restrict dom0 from accessing does pages, it fails in allocating
> the memory to the guest.

Doe sit fail in allocating the memory or in populating it?  Dom0 has to
map the new domain's memory to put the BIOs and firmware in before it
boots.

Sorry, it allocates the memory but fails when trying to populate it.
This happened because I changed get_page_from_l1e to restrict access.

> Is get_page_from_l1e always called by dom0?

get_page_from_l1e is called for any pagetables entry (PV or shadowed HVM)
that maps a page of memory.  So it will be called when dom0 triues to
map the memory.

Thank you.

> Can a guest run when dom0 is restricted from
> accessing its memory? I would only want to restrict access
> for certain operations.

Dom0 maps domU's memory three times:
 Once (by force) to populate the BIOS &C at buid time.
 In Qemu (again, by force) to emulate domU's hardware.
 In the PV backend drivers (using the grant tables) for block & net I/O.

You can handle the build-time map by allowing them and the making sure
they all get pulled down before the domain is unpaused for the first
time (Or by having a separate trusted/privileged builder domain that
does nothing but build domains).

All right, I will look for this stage in the code.

You can handle the second by using
stub domains to run qemu in a different domain, or by only usoing PV
domUs.

If I use the stub domain provided with xen the dom0 will not perform the 
second mapping, right?

The third is pretty much a requirement if the domU's going to do
any I/O via dom0, but at least with grant tables the ACL is under domU's
control.  Or if you have an IOMMU you can give the domU direct access to
its own network card and disk controller.

I only have one ethernet card but i can get an ethernet expresscard.

Can I do this in my the machine that gives me the output that follows?

(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.

The not enabled means I should enable them in the BIOS?
Because I have looked everywhere and I can't find any other 
options realted to VT-d.

(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB

Cheers,

Tim.

Thank you for the help Tim! Cheers,

Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9O-0006ss-7Y; Wed, 11 Apr 2012 12:59:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006ne-V3
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [85.158.139.83:11869] by server-1.bemta-5.messagelabs.com id
	CA/42-28458-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17765 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kV-Jf; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kg-Hi;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:24 +0100
Message-ID: <1334149181-2834-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/19] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Also fix the wording in the libxl_internal.h comment forbidding use of
ao_how-taking functions from within libxl.  (There are sadly currently
some such functions.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..c89add8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,9 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->constructing);
     assert(ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b1e0588 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -347,7 +347,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1209,7 +1209,11 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * operation ("ao") machinery.  The function should take a parameter
  * const libxl_asyncop_how *ao_how and must start with a call to
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * outside libxl, because they can cause reentrancy callbacks.
+ * inside libxl, because they can cause reentrancy callbacks.
+ *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
  *
  * Lifecycle of an ao:
  *
@@ -1240,8 +1244,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1255,12 +1258,14 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
     AO_GC;
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1269,6 +1274,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9O-0006ss-7Y; Wed, 11 Apr 2012 12:59:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006ne-V3
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [85.158.139.83:11869] by server-1.bemta-5.messagelabs.com id
	CA/42-28458-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17765 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kV-Jf; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kg-Hi;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:24 +0100
Message-ID: <1334149181-2834-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/19] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Also fix the wording in the libxl_internal.h comment forbidding use of
ao_how-taking functions from within libxl.  (There are sadly currently
some such functions.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..c89add8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,9 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->constructing);
     assert(ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b1e0588 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -347,7 +347,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1209,7 +1209,11 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * operation ("ao") machinery.  The function should take a parameter
  * const libxl_asyncop_how *ao_how and must start with a call to
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * outside libxl, because they can cause reentrancy callbacks.
+ * inside libxl, because they can cause reentrancy callbacks.
+ *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
  *
  * Lifecycle of an ao:
  *
@@ -1240,8 +1244,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1255,12 +1258,14 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
     AO_GC;
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1269,6 +1274,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9Q-0006uz-6W; Wed, 11 Apr 2012 12:59:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9L-0006om-UA
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:52 +0000
Received: from [85.158.139.83:12060] by server-9.bemta-5.messagelabs.com id
	FC/6F-09826-440858F4; Wed, 11 Apr 2012 12:59:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17918 invoked from network); 11 Apr 2012 12:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kr-TH; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lW-RP;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:36 +0100
Message-ID: <1334149181-2834-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/19] libxl: Provide libxl_string_list_length
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    8 ++++++++
 tools/libxl/libxl.h |    1 +
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f41b62f..8910420 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -177,6 +177,14 @@ void libxl_string_list_dispose(libxl_string_list *psl)
     free(sl);
 }
 
+int libxl_string_list_length(const libxl_string_list *psl)
+{
+    if (!psl) return 0;
+    int i = 0;
+    while (*psl++) i++;
+    return i;
+}
+
 void libxl_key_value_list_dispose(libxl_key_value_list *pkvl)
 {
     int i;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0219f81..b376316 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -273,6 +273,7 @@ typedef uint8_t libxl_mac[6];
 
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
+int libxl_string_list_length(const libxl_string_list *sl);
 
 typedef char **libxl_key_value_list;
 void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9Q-0006uz-6W; Wed, 11 Apr 2012 12:59:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9L-0006om-UA
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:52 +0000
Received: from [85.158.139.83:12060] by server-9.bemta-5.messagelabs.com id
	FC/6F-09826-440858F4; Wed, 11 Apr 2012 12:59:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17918 invoked from network); 11 Apr 2012 12:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kr-TH; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lW-RP;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:36 +0100
Message-ID: <1334149181-2834-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/19] libxl: Provide libxl_string_list_length
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    8 ++++++++
 tools/libxl/libxl.h |    1 +
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f41b62f..8910420 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -177,6 +177,14 @@ void libxl_string_list_dispose(libxl_string_list *psl)
     free(sl);
 }
 
+int libxl_string_list_length(const libxl_string_list *psl)
+{
+    if (!psl) return 0;
+    int i = 0;
+    while (*psl++) i++;
+    return i;
+}
+
 void libxl_key_value_list_dispose(libxl_key_value_list *pkvl)
 {
     int i;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0219f81..b376316 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -273,6 +273,7 @@ typedef uint8_t libxl_mac[6];
 
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
+int libxl_string_list_length(const libxl_string_list *sl);
 
 typedef char **libxl_key_value_list;
 void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9K-0006q3-VK; Wed, 11 Apr 2012 12:59:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nC-Id
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11878] by server-6.bemta-5.messagelabs.com id
	5B/A7-13222-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17827 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ke-OE; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000l4-ND;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:30 +0100
Message-ID: <1334149181-2834-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/19] libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be needed for pthread_atfork.  It is a mystery why it
hasn't been needed before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 748d057..b0143e6 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -22,6 +22,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9L-0006qI-BN; Wed, 11 Apr 2012 12:59:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nO-GV
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11837] by server-5.bemta-5.messagelabs.com id
	8D/17-13566-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17787 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kg-Ot; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000l7-No;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:31 +0100
Message-ID: <1334149181-2834-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/19] tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Replace all literal occurrences of -lpthread and -pthread in Makefiles
by references to PTHREAD_CFLAGS, PTHREAD_LDFLAGS and PTHREAD_LIBS.
These are the new variables set by configure, and currently expand to
-pthread on the compilation and link lines as is required.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap/drivers/Makefile       |    7 +++++--
 tools/libfsimage/common/Makefile    |    5 ++++-
 tools/vtpm_manager/manager/Makefile |    4 +++-
 tools/xenpaging/Makefile            |    5 +++--
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
index addb2fe..941592e 100644
--- a/tools/blktap/drivers/Makefile
+++ b/tools/blktap/drivers/Makefile
@@ -35,8 +35,11 @@ else
 AIOLIBS     := -laio
 endif
 
-LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
-LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
+LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm $(PTHREAD_LIBS)
+LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) $(PTHREAD_LIBS) -lz
 
 BLK-OBJS-y  := block-aio.o
 BLK-OBJS-y  += block-sync.o
diff --git a/tools/libfsimage/common/Makefile b/tools/libfsimage/common/Makefile
index 11621e7..3684913 100644
--- a/tools/libfsimage/common/Makefile
+++ b/tools/libfsimage/common/Makefile
@@ -8,6 +8,9 @@ LDFLAGS-$(CONFIG_SunOS) = -Wl,-M -Wl,mapfile-SunOS
 LDFLAGS-$(CONFIG_Linux) = -Wl,mapfile-GNU
 LDFLAGS = $(LDFLAGS-y)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
 LIB_SRCS-y = fsimage.c fsimage_plugin.c fsimage_grub.c
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
@@ -37,7 +40,7 @@ libfsimage.so.$(MAJOR): libfsimage.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libfsimage.so.$(MAJOR).$(MINOR): $(PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ -lpthread
+	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(PTHREAD_LIBS)
 
 -include $(DEPS)
 
diff --git a/tools/vtpm_manager/manager/Makefile b/tools/vtpm_manager/manager/Makefile
index 149f01d..7564af1 100644
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -33,4 +33,6 @@ $(BIN): $(OBJS)
 
 # libraries
 LIBS += ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.a
-LIBS += -lcrypto -lpthread -lm
+LIBS += -lcrypto $(PTHREAD_LIBS) -lm
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/xenpaging/Makefile b/tools/xenpaging/Makefile
index 08230a6..548d9dd 100644
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -1,8 +1,9 @@
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore)
-LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -pthread
+CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore) $(PTHREAD_CFLAGS)
+LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(PTHREAD_LIBS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
 
 POLICY    = default
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9L-0006qI-BN; Wed, 11 Apr 2012 12:59:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nO-GV
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11837] by server-5.bemta-5.messagelabs.com id
	8D/17-13566-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17787 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kg-Ot; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000l7-No;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:31 +0100
Message-ID: <1334149181-2834-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/19] tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Replace all literal occurrences of -lpthread and -pthread in Makefiles
by references to PTHREAD_CFLAGS, PTHREAD_LDFLAGS and PTHREAD_LIBS.
These are the new variables set by configure, and currently expand to
-pthread on the compilation and link lines as is required.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap/drivers/Makefile       |    7 +++++--
 tools/libfsimage/common/Makefile    |    5 ++++-
 tools/vtpm_manager/manager/Makefile |    4 +++-
 tools/xenpaging/Makefile            |    5 +++--
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/blktap/drivers/Makefile b/tools/blktap/drivers/Makefile
index addb2fe..941592e 100644
--- a/tools/blktap/drivers/Makefile
+++ b/tools/blktap/drivers/Makefile
@@ -35,8 +35,11 @@ else
 AIOLIBS     := -laio
 endif
 
-LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
-LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
+LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm $(PTHREAD_LIBS)
+LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) $(PTHREAD_LIBS) -lz
 
 BLK-OBJS-y  := block-aio.o
 BLK-OBJS-y  += block-sync.o
diff --git a/tools/libfsimage/common/Makefile b/tools/libfsimage/common/Makefile
index 11621e7..3684913 100644
--- a/tools/libfsimage/common/Makefile
+++ b/tools/libfsimage/common/Makefile
@@ -8,6 +8,9 @@ LDFLAGS-$(CONFIG_SunOS) = -Wl,-M -Wl,mapfile-SunOS
 LDFLAGS-$(CONFIG_Linux) = -Wl,mapfile-GNU
 LDFLAGS = $(LDFLAGS-y)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
 LIB_SRCS-y = fsimage.c fsimage_plugin.c fsimage_grub.c
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
@@ -37,7 +40,7 @@ libfsimage.so.$(MAJOR): libfsimage.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libfsimage.so.$(MAJOR).$(MINOR): $(PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ -lpthread
+	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libfsimage.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(PTHREAD_LIBS)
 
 -include $(DEPS)
 
diff --git a/tools/vtpm_manager/manager/Makefile b/tools/vtpm_manager/manager/Makefile
index 149f01d..7564af1 100644
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -33,4 +33,6 @@ $(BIN): $(OBJS)
 
 # libraries
 LIBS += ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.a
-LIBS += -lcrypto -lpthread -lm
+LIBS += -lcrypto $(PTHREAD_LIBS) -lm
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/xenpaging/Makefile b/tools/xenpaging/Makefile
index 08230a6..548d9dd 100644
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -1,8 +1,9 @@
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore)
-LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -pthread
+CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore) $(PTHREAD_CFLAGS)
+LDLIBS += $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(PTHREAD_LIBS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
 
 POLICY    = default
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9M-0006rO-MA; Wed, 11 Apr 2012 12:59:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nN-RG
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:4396] by server-11.bemta-5.messagelabs.com id
	AC/2A-12959-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17809 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ko-Re; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lP-Qt;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:35 +0100
Message-ID: <1334149181-2834-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/19] libxl: include <ctype.h> and introduce
	CTYPE helper macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 95c34f3..b35421f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -33,6 +33,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <ctype.h>
 
 #include <sys/mman.h>
 #include <sys/poll.h>
@@ -1469,6 +1470,25 @@ static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
     } while(0)
 
 
+/*
+ * int CTYPE(ISFOO, char c);
+ * int CTYPE(toupper, char c);
+ * int CTYPE(tolower, char c);
+ *
+ * This is necessary because passing a simple char to a ctype.h
+ * is forbidden.  ctype.h macros take ints derived from _unsigned_ chars.
+ *
+ * If you have a char which might be EOF then you should already have
+ * it in an int representing an unsigned char, and you can use the
+ * <ctype.h> macros directly.  This generally happens only with values
+ * from fgetc et al.
+ *
+ * For any value known to be a character (eg, anything that came from
+ * a char[]), use CTYPE.
+ */
+#define CTYPE(isfoo,c) (isfoo((unsigned char)(c)))
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9K-0006q3-VK; Wed, 11 Apr 2012 12:59:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nC-Id
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11878] by server-6.bemta-5.messagelabs.com id
	5B/A7-13222-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17827 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ke-OE; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000l4-ND;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:30 +0100
Message-ID: <1334149181-2834-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/19] libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be needed for pthread_atfork.  It is a mystery why it
hasn't been needed before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 748d057..b0143e6 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -22,6 +22,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9I-0006ok-T4; Wed, 11 Apr 2012 12:59:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nE-Qs
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:49721] by server-2.bemta-14.messagelabs.com id
	B4/4F-19409-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26251 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ka-ML; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kr-KM;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:27 +0100
Message-ID: <1334149181-2834-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 05/19] libxl: remove poller from list in
	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Roger Pau Monne <roger.pau@citrix.com>

Remove poller from the list once it has been requested.
Fixes a double-free bug.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@citrix.com>
---
 tools/libxl/libxl_event.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5ac6334..9cb172a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1010,8 +1010,10 @@ libxl__poller *libxl__poller_get(libxl_ctx *ctx)
     int rc;
 
     libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
-    if (p)
+    if (p) {
+        LIBXL_LIST_REMOVE(p, entry);
         return p;
+    }
 
     p = malloc(sizeof(*p));
     if (!p) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9O-0006tZ-VZ; Wed, 11 Apr 2012 12:59:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006oS-Os
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [85.158.139.83:11968] by server-2.bemta-5.messagelabs.com id
	1B/BF-17016-440858F4; Wed, 11 Apr 2012 12:59:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17894 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ku-UU; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lh-TY;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:38 +0100
Message-ID: <1334149181-2834-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/19] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b376316..edbca53 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -461,7 +461,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d6cd78d..0cbd85e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -365,13 +365,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..62c0abd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -94,6 +94,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0a3d628..7e258d5 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -105,6 +105,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..c9e9943 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1441,7 +1441,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1728,11 +1728,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9J-0006pH-MM; Wed, 11 Apr 2012 12:59:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nB-1K
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11808] by server-4.bemta-5.messagelabs.com id
	92/7C-10788-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878046"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kY-KM; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kk-JG;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:25 +0100
Message-ID: <1334149181-2834-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/19] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7a54524..dd948a8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1406,7 +1406,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1873,7 +1873,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2220,7 +2220,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2353,7 +2353,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b1e0588..5167b71 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -692,7 +692,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9N-0006rm-2j; Wed, 11 Apr 2012 12:59:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nC-Vc
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [85.158.139.83:11931] by server-6.bemta-5.messagelabs.com id
	AF/A7-13222-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17850 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kn-RH; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lJ-PV;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:34 +0100
Message-ID: <1334149181-2834-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/19] libxl: Introduce some convenience macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce:
   <type> *GCNEW(<type> *var);
   <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
   <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
   char *GCSPRINTF(const char *fmt, ...);
   void LOG(<xtl_level_suffix>, const char *fmt, ...);
   void LOGE(<xtl_level_suffix>, const char *fmt, ...);
   void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
all of which expect, in the calling context,
   libxl__gc *gc;

Most of these will find callers in subsequent patches.  The exceptions
are the orthogonally necessary LOGE and LOGEV, and GCREALLOC_ARRAY.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   72 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9340bde..95c34f3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1349,6 +1349,78 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
+/* Allocation macros all of which use the gc. */
+
+#define ARRAY_SIZE_OK(ptr, nmemb) ((nmemb) < INT_MAX / (sizeof(*(ptr)) * 2))
+
+/*
+ * Expression statement  <type> *GCNEW(<type> *var);
+ * Uses                  libxl__gc *gc;
+ *
+ * Allocates a new object of type <type> from the gc and zeroes it
+ * with memset.  Sets var to point to the new object or zero (setting
+ * errno).  Returns the new value of var.
+ */
+#define GCNEW(var)                                      \
+    (((var) = libxl__zalloc((gc),sizeof(*(var)))))
+
+/*
+ * Expression statement  <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Like GCNEW but allocates an array of nmemb elements, as if from
+ * calloc.  Does check for integer overflow due to large nmemb.  If
+ * nmemb is 0 may succeed by returning 0.
+ */
+#define GCNEW_ARRAY(var, nmemb)                                 \
+    ((var) = libxl__calloc((gc), (nmemb), sizeof(*(var))))
+    
+/*
+ * Expression statement  <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Reallocates the array var to be of size nmemb elements.  Updates
+ * var and returns the new value of var.  Does check for integer
+ * overflow due to large nmemb.
+ *
+ * Do not pass nmemb==0.  old may be 0 on entry.
+ */
+#define GCREALLOC_ARRAY(var, nmemb)                                     \
+    (assert(nmemb > 0),                                                 \
+     assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+
+
+/*
+ * Expression            char *GCSPRINTF(const char *fmt, ...);
+ * Uses                  libxl__gc *gc;
+ *
+ * Trivial convenience wrapper for libxl__sprintf.
+ */
+#define GCSPRINTF(fmt, ...) (libxl__sprintf((gc), (fmt), __VA_ARGS__))
+
+
+/*
+ * Expression statements
+ *    void LOG(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGE(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
+ * Use
+ *    libxl__gc *gc;
+ *
+ * Trivial convenience wrappers for LIBXL__LOG, LIBXL__LOG_ERRNO and
+ * LIBXL__LOG_ERRNOVAL, respectively (and thus for libxl__log).
+ *
+ * XTL_<xtl_level_suffix> should exist and be an xentoollog.h log level
+ * So <xtl_level_suffix> should be one of
+ *   DEBUG VERBOSE DETAIL PROGRESS INFO NOTICE WARN ERROR ERROR CRITICAL
+ * Of these, most of libxl uses
+ *   DEBUG INFO WARN ERROR
+ */
+#define LOG(l,f, ...)     LIBXL__LOG(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGE(l,f, ...)    LIBXL__LOG_ERRNO(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGEV(l,e,f, ...) LIBXL__LOG_ERRNOVAL(CTX,XTL_##l,(e),(f),##__VA_ARGS__)
+
 
 /* Locking functions.  See comment for "lock" member of libxl__ctx. */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9M-0006rO-MA; Wed, 11 Apr 2012 12:59:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nN-RG
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:4396] by server-11.bemta-5.messagelabs.com id
	AC/2A-12959-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17809 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ko-Re; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lP-Qt;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:35 +0100
Message-ID: <1334149181-2834-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/19] libxl: include <ctype.h> and introduce
	CTYPE helper macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 95c34f3..b35421f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -33,6 +33,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <ctype.h>
 
 #include <sys/mman.h>
 #include <sys/poll.h>
@@ -1469,6 +1470,25 @@ static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
     } while(0)
 
 
+/*
+ * int CTYPE(ISFOO, char c);
+ * int CTYPE(toupper, char c);
+ * int CTYPE(tolower, char c);
+ *
+ * This is necessary because passing a simple char to a ctype.h
+ * is forbidden.  ctype.h macros take ints derived from _unsigned_ chars.
+ *
+ * If you have a char which might be EOF then you should already have
+ * it in an int representing an unsigned char, and you can use the
+ * <ctype.h> macros directly.  This generally happens only with values
+ * from fgetc et al.
+ *
+ * For any value known to be a character (eg, anything that came from
+ * a char[]), use CTYPE.
+ */
+#define CTYPE(isfoo,c) (isfoo((unsigned char)(c)))
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9I-0006oA-3j; Wed, 11 Apr 2012 12:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nB-H3
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:46 +0000
Received: from [85.158.139.83:4257] by server-4.bemta-5.messagelabs.com id
	FB/6C-10788-140858F4; Wed, 11 Apr 2012 12:59:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17682 invoked from network); 11 Apr 2012 12:59:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9D-0002kR-Ev; Wed, 11 Apr 2012 12:59:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9D-0000kU-CB;
	Wed, 11 Apr 2012 13:59:43 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:22 +0100
Message-ID: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v5 00/19] libxl: improvements,
	prep for subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is the initial portion of my child process series which has been
acked and which I intend to apply right away.  Changes are exactly
those discussed on the list since v4; I'm reposting the final version
for form's sake.

Bugfixes for problems reported by Roger Pau Monne:
 02/19 libxl: ao: allow immediate completion
 03/19 libxl: fix hang due to libxl__initiate_device_remove
 04/19 libxl: Fix eventloop_iteration over-locking
 05/19 libxl: remove poller from list in libxl__poller_get

Other general bugfixes:
 01/19 .gitignore: Add a missing file
 06/19 libxl: Fix leak of ctx->lock
 07/19 tools: Correct PTHREAD options in config/StdGNU.mk
 08/19 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
 09/19 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS

Clarifications and improvements related to memory allocation:
 10/19 libxl: Crash (more sensibly) on malloc failure
 11/19 libxl: Make libxl__zalloc et al tolerate a NULL gc

Preparatory work for child process handling:
 12/19 libxl: Introduce some convenience macros
 13/19 libxl: include <ctype.h> and introduce CTYPE helper macro
 14/19 libxl: Provide libxl_string_list_length
 15/19 libxl: include <_libxl_paths.h> in libxl_internal.h
 16/19 libxl: abolish libxl_ctx_postfork

Event-related infrastructure and fixes:
 17/19 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 18/19 libxl: Protect fds with CLOEXEC even with forking threads
 19/19 libxl: provide STATE_AO_GC

The remaining patches (20-31 from v4) remain outstanding.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9I-0006oZ-Gq; Wed, 11 Apr 2012 12:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nC-LG
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:46 +0000
Received: from [85.158.139.83:11771] by server-6.bemta-5.messagelabs.com id
	29/97-13222-140858F4; Wed, 11 Apr 2012 12:59:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17707 invoked from network); 11 Apr 2012 12:59:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kU-Hy; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000ke-HD;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:23 +0100
Message-ID: <1334149181-2834-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/19] .gitignore: Add a missing file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2782ee5..cd12b56 100644
--- a/.gitignore
+++ b/.gitignore
@@ -357,6 +357,7 @@ tools/firmware/etherboot/eb-roms.h
 tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
 tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
+tools/misc/xen-lowmemd
 tools/libvchan/vchan-node[12]
 tools/ocaml/*/.ocamldep.make
 tools/ocaml/*/*.cm[ixao]
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9K-0006pb-6D; Wed, 11 Apr 2012 12:59:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nN-Av
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11816] by server-11.bemta-5.messagelabs.com id
	F2/2A-12959-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17748 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kZ-KZ; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000ko-Jr;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:26 +0100
Message-ID: <1334149181-2834-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/19] libxl: Fix eventloop_iteration
	over-locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c89add8..5ac6334 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5167b71..04f13f6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1191,7 +1191,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1287,7 +1287,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9K-0006pl-J1; Wed, 11 Apr 2012 12:59:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nE-AL
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:9882] by server-2.bemta-14.messagelabs.com id
	E5/4F-19409-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26302 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kh-QB; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lB-OT;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:32 +0100
Message-ID: <1334149181-2834-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/19] libxl: Crash (more sensibly) on malloc
	failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Formally change the libxl memory allocation failure policy to "crash".

Previously we had a very uneven approach; much code assumed that
libxl__sprintf (for example) would never return NULL, but some code
was written more carefully.

We think it is unlikely that we will be able to make the library
actually robust against allocation failure (since that would be an
awful lot of never-tested error paths) and few calling environments
will be able to cope anyway.  So, instead, adopt the alternative
approach: provide allocation functions which never return null, but
will crash the whole process instead.

Consequently,
 - New noreturn function libxl__alloc_failed which may be used for
   printing a vaguely-useful error message, rather than simply
   dereferencing a null pointer.
 - libxl__ptr_add now returns void as it crashes on failure.
 - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
   libxl__alloc_failed.  So all the code that uses these can no longer
   dereference null on malloc failure.

While we're at it, make libxl__ptr_add use realloc rather than
emulating it with calloc and free, and make it grow the array
exponentially rather than linearly.

Things left to do:
 - Remove a lot of now-spurious error handling.
 - Remove the ERROR_NOMEM error code.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h          |    4 ++
 tools/libxl/libxl_internal.c |   87 ++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |    8 +++-
 3 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 2aec910..0219f81 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -194,6 +194,10 @@
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
+ *
+ * Memory allocation failures are not handled gracefully.  If malloc
+ * (or realloc) fails, libxl will cause the entire process to print
+ * a message to stderr and exit with status 255.
  */
 /*
  * libxl types
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..4ed9412 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -17,40 +17,45 @@
 
 #include "libxl_internal.h"
 
-int libxl__error_set(libxl__gc *gc, int code)
-{
-    return 0;
+void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
+                         size_t nmemb, size_t size) {
+#define M "libxl: FATAL ERROR: memory allocation failure"
+#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
+          func, (unsigned long)nmemb, (unsigned long)size
+    libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, L);
+    fprintf(stderr, L);
+    fflush(stderr);
+    _exit(-1);
+#undef M
+#undef L
 }
 
-int libxl__ptr_add(libxl__gc *gc, void *ptr)
+void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
-    void **re;
 
     if (!ptr)
-        return 0;
+        return;
 
     /* fast case: we have space in the array for storing the pointer */
     for (i = 0; i < gc->alloc_maxsize; i++) {
         if (!gc->alloc_ptrs[i]) {
             gc->alloc_ptrs[i] = ptr;
-            return 0;
+            return;
         }
     }
-    /* realloc alloc_ptrs manually with calloc/free/replace */
-    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
-    if (!re)
-        return -1;
-    for (i = 0; i < gc->alloc_maxsize; i++)
-        re[i] = gc->alloc_ptrs[i];
-    /* assign the next pointer */
-    re[i] = ptr;
+    int new_maxsize = gc->alloc_maxsize * 2 + 25;
+    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
+    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
+    if (!gc->alloc_ptrs)
+        libxl__alloc_failed(CTX, __func__, new_maxsize, sizeof(void*));
 
-    /* replace the old alloc_ptr */
-    free(gc->alloc_ptrs);
-    gc->alloc_ptrs = re;
-    gc->alloc_maxsize += 25;
-    return 0;
+    gc->alloc_ptrs[gc->alloc_maxsize++] = ptr;
+
+    while (gc->alloc_maxsize < new_maxsize)
+        gc->alloc_ptrs[gc->alloc_maxsize++] = 0;
+
+    return;
 }
 
 void libxl__free_all(libxl__gc *gc)
@@ -71,10 +76,7 @@ void libxl__free_all(libxl__gc *gc)
 void *libxl__zalloc(libxl__gc *gc, int bytes)
 {
     void *ptr = calloc(bytes, 1);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, bytes, 1);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -83,10 +85,7 @@ void *libxl__zalloc(libxl__gc *gc, int bytes)
 void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size)
 {
     void *ptr = calloc(nmemb, size);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, nmemb, size);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -97,9 +96,8 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
     void *new_ptr = realloc(ptr, new_size);
     int i = 0;
 
-    if (new_ptr == NULL && new_size != 0) {
-        return NULL;
-    }
+    if (new_ptr == NULL && new_size != 0)
+        libxl__alloc_failed(CTX, __func__, new_size, 1);
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
@@ -112,7 +110,6 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
         }
     }
 
-
     return new_ptr;
 }
 
@@ -126,16 +123,13 @@ char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...)
     ret = vsnprintf(NULL, 0, fmt, ap);
     va_end(ap);
 
-    if (ret < 0) {
-        return NULL;
-    }
+    assert(ret >= 0);
 
     s = libxl__zalloc(gc, ret + 1);
-    if (s) {
-        va_start(ap, fmt);
-        ret = vsnprintf(s, ret + 1, fmt, ap);
-        va_end(ap);
-    }
+    va_start(ap, fmt);
+    ret = vsnprintf(s, ret + 1, fmt, ap);
+    va_end(ap);
+
     return s;
 }
 
@@ -143,8 +137,9 @@ char *libxl__strdup(libxl__gc *gc, const char *c)
 {
     char *s = strdup(c);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, strlen(c), 1);
+
+    libxl__ptr_add(gc, s);
 
     return s;
 }
@@ -153,8 +148,7 @@ char *libxl__strndup(libxl__gc *gc, const char *c, size_t n)
 {
     char *s = strndup(c, n);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, n, 1);
 
     return s;
 }
@@ -175,6 +169,9 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
              const char *fmt, va_list ap)
 {
+    /* WARNING this function may not call any libxl-provided
+     * memory allocation function, as those may
+     * call libxl__alloc_failed which calls libxl__logv. */
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
     int rc, esave;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 04f13f6..2ad446a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -116,6 +116,12 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
+void libxl__alloc_failed(libxl_ctx *, const char *func,
+                         size_t nmemb, size_t size) __attribute__((noreturn));
+  /* func, size and nmemb are used only in the log message.
+   * You may pass size==0 if size and nmemb are not meaningful
+   * and should not be printed. */
+
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
@@ -380,7 +386,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * collection on exit from the outermost libxl callframe.
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9I-0006ok-T4; Wed, 11 Apr 2012 12:59:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nE-Qs
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:49721] by server-2.bemta-14.messagelabs.com id
	B4/4F-19409-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26251 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ka-ML; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kr-KM;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:27 +0100
Message-ID: <1334149181-2834-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 05/19] libxl: remove poller from list in
	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Roger Pau Monne <roger.pau@citrix.com>

Remove poller from the list once it has been requested.
Fixes a double-free bug.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@citrix.com>
---
 tools/libxl/libxl_event.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5ac6334..9cb172a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1010,8 +1010,10 @@ libxl__poller *libxl__poller_get(libxl_ctx *ctx)
     int rc;
 
     libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
-    if (p)
+    if (p) {
+        LIBXL_LIST_REMOVE(p, entry);
         return p;
+    }
 
     p = malloc(sizeof(*p));
     if (!p) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9J-0006pH-MM; Wed, 11 Apr 2012 12:59:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nB-1K
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11808] by server-4.bemta-5.messagelabs.com id
	92/7C-10788-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878046"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kY-KM; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kk-JG;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:25 +0100
Message-ID: <1334149181-2834-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/19] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7a54524..dd948a8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1406,7 +1406,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1873,7 +1873,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2220,7 +2220,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2353,7 +2353,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b1e0588..5167b71 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -692,7 +692,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9N-0006sR-R0; Wed, 11 Apr 2012 12:59:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nd-Ve
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [193.109.254.147:20703] by server-4.bemta-14.messagelabs.com id
	83/E2-11570-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26380 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kv-Uw; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lk-U8;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:39 +0100
Message-ID: <1334149181-2834-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/19] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 9cb172a..638b9ab 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9I-0006oA-3j; Wed, 11 Apr 2012 12:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nB-H3
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:46 +0000
Received: from [85.158.139.83:4257] by server-4.bemta-5.messagelabs.com id
	FB/6C-10788-140858F4; Wed, 11 Apr 2012 12:59:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17682 invoked from network); 11 Apr 2012 12:59:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9D-0002kR-Ev; Wed, 11 Apr 2012 12:59:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9D-0000kU-CB;
	Wed, 11 Apr 2012 13:59:43 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:22 +0100
Message-ID: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v5 00/19] libxl: improvements,
	prep for subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is the initial portion of my child process series which has been
acked and which I intend to apply right away.  Changes are exactly
those discussed on the list since v4; I'm reposting the final version
for form's sake.

Bugfixes for problems reported by Roger Pau Monne:
 02/19 libxl: ao: allow immediate completion
 03/19 libxl: fix hang due to libxl__initiate_device_remove
 04/19 libxl: Fix eventloop_iteration over-locking
 05/19 libxl: remove poller from list in libxl__poller_get

Other general bugfixes:
 01/19 .gitignore: Add a missing file
 06/19 libxl: Fix leak of ctx->lock
 07/19 tools: Correct PTHREAD options in config/StdGNU.mk
 08/19 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
 09/19 tools: Use PTHREAD_CFLAGS, _LDFLAGS, _LIBS

Clarifications and improvements related to memory allocation:
 10/19 libxl: Crash (more sensibly) on malloc failure
 11/19 libxl: Make libxl__zalloc et al tolerate a NULL gc

Preparatory work for child process handling:
 12/19 libxl: Introduce some convenience macros
 13/19 libxl: include <ctype.h> and introduce CTYPE helper macro
 14/19 libxl: Provide libxl_string_list_length
 15/19 libxl: include <_libxl_paths.h> in libxl_internal.h
 16/19 libxl: abolish libxl_ctx_postfork

Event-related infrastructure and fixes:
 17/19 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 18/19 libxl: Protect fds with CLOEXEC even with forking threads
 19/19 libxl: provide STATE_AO_GC

The remaining patches (20-31 from v4) remain outstanding.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9K-0006pb-6D; Wed, 11 Apr 2012 12:59:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nN-Av
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [85.158.139.83:11816] by server-11.bemta-5.messagelabs.com id
	F2/2A-12959-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17748 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kZ-KZ; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000ko-Jr;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:26 +0100
Message-ID: <1334149181-2834-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/19] libxl: Fix eventloop_iteration
	over-locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c89add8..5ac6334 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5167b71..04f13f6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1191,7 +1191,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1287,7 +1287,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9N-0006rm-2j; Wed, 11 Apr 2012 12:59:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nC-Vc
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [85.158.139.83:11931] by server-6.bemta-5.messagelabs.com id
	AF/A7-13222-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17850 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kn-RH; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lJ-PV;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:34 +0100
Message-ID: <1334149181-2834-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/19] libxl: Introduce some convenience macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce:
   <type> *GCNEW(<type> *var);
   <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
   <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
   char *GCSPRINTF(const char *fmt, ...);
   void LOG(<xtl_level_suffix>, const char *fmt, ...);
   void LOGE(<xtl_level_suffix>, const char *fmt, ...);
   void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
all of which expect, in the calling context,
   libxl__gc *gc;

Most of these will find callers in subsequent patches.  The exceptions
are the orthogonally necessary LOGE and LOGEV, and GCREALLOC_ARRAY.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   72 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9340bde..95c34f3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1349,6 +1349,78 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
+/* Allocation macros all of which use the gc. */
+
+#define ARRAY_SIZE_OK(ptr, nmemb) ((nmemb) < INT_MAX / (sizeof(*(ptr)) * 2))
+
+/*
+ * Expression statement  <type> *GCNEW(<type> *var);
+ * Uses                  libxl__gc *gc;
+ *
+ * Allocates a new object of type <type> from the gc and zeroes it
+ * with memset.  Sets var to point to the new object or zero (setting
+ * errno).  Returns the new value of var.
+ */
+#define GCNEW(var)                                      \
+    (((var) = libxl__zalloc((gc),sizeof(*(var)))))
+
+/*
+ * Expression statement  <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Like GCNEW but allocates an array of nmemb elements, as if from
+ * calloc.  Does check for integer overflow due to large nmemb.  If
+ * nmemb is 0 may succeed by returning 0.
+ */
+#define GCNEW_ARRAY(var, nmemb)                                 \
+    ((var) = libxl__calloc((gc), (nmemb), sizeof(*(var))))
+    
+/*
+ * Expression statement  <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Reallocates the array var to be of size nmemb elements.  Updates
+ * var and returns the new value of var.  Does check for integer
+ * overflow due to large nmemb.
+ *
+ * Do not pass nmemb==0.  old may be 0 on entry.
+ */
+#define GCREALLOC_ARRAY(var, nmemb)                                     \
+    (assert(nmemb > 0),                                                 \
+     assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+
+
+/*
+ * Expression            char *GCSPRINTF(const char *fmt, ...);
+ * Uses                  libxl__gc *gc;
+ *
+ * Trivial convenience wrapper for libxl__sprintf.
+ */
+#define GCSPRINTF(fmt, ...) (libxl__sprintf((gc), (fmt), __VA_ARGS__))
+
+
+/*
+ * Expression statements
+ *    void LOG(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGE(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
+ * Use
+ *    libxl__gc *gc;
+ *
+ * Trivial convenience wrappers for LIBXL__LOG, LIBXL__LOG_ERRNO and
+ * LIBXL__LOG_ERRNOVAL, respectively (and thus for libxl__log).
+ *
+ * XTL_<xtl_level_suffix> should exist and be an xentoollog.h log level
+ * So <xtl_level_suffix> should be one of
+ *   DEBUG VERBOSE DETAIL PROGRESS INFO NOTICE WARN ERROR ERROR CRITICAL
+ * Of these, most of libxl uses
+ *   DEBUG INFO WARN ERROR
+ */
+#define LOG(l,f, ...)     LIBXL__LOG(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGE(l,f, ...)    LIBXL__LOG_ERRNO(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGEV(l,e,f, ...) LIBXL__LOG_ERRNOVAL(CTX,XTL_##l,(e),(f),##__VA_ARGS__)
+
 
 /* Locking functions.  See comment for "lock" member of libxl__ctx. */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9O-0006tZ-VZ; Wed, 11 Apr 2012 12:59:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006oS-Os
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [85.158.139.83:11968] by server-2.bemta-5.messagelabs.com id
	1B/BF-17016-440858F4; Wed, 11 Apr 2012 12:59:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17894 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ku-UU; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lh-TY;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:38 +0100
Message-ID: <1334149181-2834-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/19] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b376316..edbca53 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -461,7 +461,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d6cd78d..0cbd85e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -365,13 +365,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..62c0abd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -94,6 +94,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0a3d628..7e258d5 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -105,6 +105,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..c9e9943 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1441,7 +1441,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1728,11 +1728,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9J-0006p0-9A; Wed, 11 Apr 2012 12:59:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nD-UD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:20620] by server-10.bemta-14.messagelabs.com
	id A3/D5-05847-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26266 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kb-My; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kw-LO;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:28 +0100
Message-ID: <1334149181-2834-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/19] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dd948a8..f41b62f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9N-0006sR-R0; Wed, 11 Apr 2012 12:59:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nd-Ve
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [193.109.254.147:20703] by server-4.bemta-14.messagelabs.com id
	83/E2-11570-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26380 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kv-Uw; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lk-U8;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:39 +0100
Message-ID: <1334149181-2834-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/19] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 9cb172a..638b9ab 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9M-0006qw-8F; Wed, 11 Apr 2012 12:59:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nU-Hw
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:9898] by server-9.bemta-14.messagelabs.com id
	84/27-05787-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26318 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kd-Nk; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000l0-Mj;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:29 +0100
Message-ID: <1334149181-2834-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/19] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

Fix the configure test to test -pthread, and plumb the resulting flag
through to PTHREAD_{CFLAGS,LDFLAGS} in Tools.mk; also substitute
PTHREAD_LIBS (although this will currently always be empty).
Remove PTHREAD_LIBS setting from StdGNU.mk.

Fix the one user (libxc) to use PTHREAD_{CFLAGS,LDFLAGS} too.

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 config/StdGNU.mk     |    1 -
 config/Tools.mk.in   |    4 ++
 tools/configure      |  101 ++++++++++++++++++++++++++++++++++++--------------
 tools/configure.ac   |    5 +-
 tools/libxc/Makefile |    4 +-
 tools/m4/pthread.m4  |   41 ++++++++++++++++++++
 tools/m4/savevar.m4  |    6 +++
 7 files changed, 130 insertions(+), 32 deletions(-)
 create mode 100644 tools/m4/pthread.m4
 create mode 100644 tools/m4/savevar.m4

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index e2c9335..e2f2e1e 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,6 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 339a7b6..912d021 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -26,6 +26,10 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
+PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
+PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
+PTHREAD_LIBS        := @PTHREAD_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 64b7eb5..86618f5 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,9 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTHREAD_LIBS
+PTHREAD_LDFLAGS
+PTHREAD_CFLAGS
 libgcrypt
 libext2fs
 system_aio
@@ -3861,6 +3864,9 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
+
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -3924,6 +3930,22 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+
+
+
+
+
+
+
 
 # Enable/disable options
 
@@ -7228,47 +7250,70 @@ else
 fi
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in -lpthread" >&5
-$as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if test "${ac_cv_lib_pthread_pthread_create+set}" = set; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
+$as_echo_n "checking for pthread flag... " >&6; }
+if test "${ax_cv_pthread_flags+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
-  ac_check_lib_save_LIBS=$LIBS
-LIBS="-lpthread  $LIBS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+
+        ax_cv_pthread_flags=-pthread
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
+    saved_CFLAGS="$CFLAGS"
+
+    saved_LDFLAGS="$LDFLAGS"
+
+    saved_LIBS="$LIBS"
+
+
+    CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+    LDFLAGS="$LDFLAGS $PTHREAD_LDFLAGS"
+
+    LIBS="$LIBS $PTHREAD_LIBS"
+
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
-/* Override any GCC internal prototype to avoid an error.
-   Use char because int might match the return type of a GCC
-   builtin and then its argument prototype would still apply.  */
-#ifdef __cplusplus
-extern "C"
-#endif
-char pthread_create ();
-int
-main ()
-{
-return pthread_create ();
-  ;
-  return 0;
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
 }
+
 _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
-  ac_cv_lib_pthread_pthread_create=yes
+
 else
-  ac_cv_lib_pthread_pthread_create=no
+  ax_cv_pthread_flags=failed
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthread_create" >&5
-$as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" = x""yes; then :
 
-else
-  as_fn_error $? "Could not find libpthread" "$LINENO" 5
+    CFLAGS="$saved_CFLAGS"
+
+    LDFLAGS="$saved_LDFLAGS"
+
+    LIBS="$saved_LIBS"
+
+
 fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_pthread_flags" >&5
+$as_echo "$ax_cv_pthread_flags" >&6; }
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        as_fn_error $? "-pthread does not work" "$LINENO" 5
+    fi
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index 0204e36..250dffd 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -23,6 +23,7 @@ AC_USE_SYSTEM_EXTENSIONS
 AC_CANONICAL_HOST
 
 # M4 Macro includes
+m4_include([m4/savevar.m4])
 m4_include([m4/features.m4])
 m4_include([m4/path_or_fail.m4])
 m4_include([m4/python_version.m4])
@@ -33,6 +34,7 @@ m4_include([m4/set_cflags_ldflags.m4])
 m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
+m4_include([m4/pthread.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -129,8 +131,7 @@ AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
 AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
-AC_CHECK_LIB([pthread], [pthread_create], [] ,
-    [AC_MSG_ERROR([Could not find libpthread])])
+AX_CHECK_PTHREAD
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 55eb755..a1ba134 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -73,6 +73,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -157,7 +159,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
diff --git a/tools/m4/pthread.m4 b/tools/m4/pthread.m4
new file mode 100644
index 0000000..57ea85c
--- /dev/null
+++ b/tools/m4/pthread.m4
@@ -0,0 +1,41 @@
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+AC_DEFUN([AX_PTHREAD_CV2VARS],[
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+])
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+AC_DEFUN([AX_PTHREAD_VARS],[$1(CFLAGS) $1(LDFLAGS) $1(LIBS)])
+
+AC_DEFUN([AX_PTHREAD_VAR_APPLY],[
+    $1="$$1 $PTHREAD_$1"
+])
+AC_DEFUN([AX_PTHREAD_VAR_SUBST],[AC_SUBST(PTHREAD_$1)])
+
+AC_DEFUN([AX_CHECK_PTHREAD],[
+    AC_CACHE_CHECK([for pthread flag], [ax_cv_pthread_flags], [
+        ax_cv_pthread_flags=-pthread
+        AX_PTHREAD_CV2VARS
+        AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
+        AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
+        AC_LINK_IFELSE([
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
+}
+],[],[ax_cv_pthread_flags=failed])
+        AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
+    ])
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        AC_MSG_ERROR([-pthread does not work])
+    fi
+    AX_PTHREAD_CV2VARS
+    AX_PTHREAD_VARS([AX_PTHREAD_VAR_SUBST])
+])
diff --git a/tools/m4/savevar.m4 b/tools/m4/savevar.m4
new file mode 100644
index 0000000..2156bee
--- /dev/null
+++ b/tools/m4/savevar.m4
@@ -0,0 +1,6 @@
+AC_DEFUN([AX_SAVEVAR_SAVE],[
+    saved_$1="$$1"
+])
+AC_DEFUN([AX_SAVEVAR_RESTORE],[
+    $1="$saved_$1"
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9N-0006sB-Fk; Wed, 11 Apr 2012 12:59:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006nh-0O
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [193.109.254.147:20732] by server-11.bemta-14.messagelabs.com
	id CC/52-05858-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26409 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9F-0002kz-0U; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lt-Vn;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:41 +0100
Message-ID: <1334149181-2834-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/19] libxl: provide STATE_AO_GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Provide a convenience macro for use in ao callback functions, and
document that it should be used.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a8372bb..a4b933b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1266,9 +1266,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
  *    - The one in ao, whose lifetime is the asynchronous operation
- *   Usually callback function should use CONTAINER_OF
- *   to obtain its own structure, containing a pointer to the ao,
- *   and then use the gc from that ao.
+ *   Usually callback function should use CONTAINER_OF to obtain its
+ *   own state structure, containing a pointer to the ao.  It should
+ *   then obtain the ao and use the ao's gc; this is most easily done
+ *   using the convenience macro STATE_AO_GC.
  */
 
 #define AO_CREATE(ctx, domid, ao_how)                           \
@@ -1298,6 +1299,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 #define AO_GC                                   \
     libxl__gc *const gc = &ao->gc
 
+#define STATE_AO_GC(op_ao)                      \
+    libxl__ao *const ao = (op_ao);              \
+    AO_GC
+
 
 /* All of these MUST be called with the ctx locked.
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9K-0006pl-J1; Wed, 11 Apr 2012 12:59:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nE-AL
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:9882] by server-2.bemta-14.messagelabs.com id
	E5/4F-19409-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26302 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kh-QB; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lB-OT;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:32 +0100
Message-ID: <1334149181-2834-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/19] libxl: Crash (more sensibly) on malloc
	failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Formally change the libxl memory allocation failure policy to "crash".

Previously we had a very uneven approach; much code assumed that
libxl__sprintf (for example) would never return NULL, but some code
was written more carefully.

We think it is unlikely that we will be able to make the library
actually robust against allocation failure (since that would be an
awful lot of never-tested error paths) and few calling environments
will be able to cope anyway.  So, instead, adopt the alternative
approach: provide allocation functions which never return null, but
will crash the whole process instead.

Consequently,
 - New noreturn function libxl__alloc_failed which may be used for
   printing a vaguely-useful error message, rather than simply
   dereferencing a null pointer.
 - libxl__ptr_add now returns void as it crashes on failure.
 - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
   libxl__alloc_failed.  So all the code that uses these can no longer
   dereference null on malloc failure.

While we're at it, make libxl__ptr_add use realloc rather than
emulating it with calloc and free, and make it grow the array
exponentially rather than linearly.

Things left to do:
 - Remove a lot of now-spurious error handling.
 - Remove the ERROR_NOMEM error code.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h          |    4 ++
 tools/libxl/libxl_internal.c |   87 ++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |    8 +++-
 3 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 2aec910..0219f81 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -194,6 +194,10 @@
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
+ *
+ * Memory allocation failures are not handled gracefully.  If malloc
+ * (or realloc) fails, libxl will cause the entire process to print
+ * a message to stderr and exit with status 255.
  */
 /*
  * libxl types
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..4ed9412 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -17,40 +17,45 @@
 
 #include "libxl_internal.h"
 
-int libxl__error_set(libxl__gc *gc, int code)
-{
-    return 0;
+void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
+                         size_t nmemb, size_t size) {
+#define M "libxl: FATAL ERROR: memory allocation failure"
+#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
+          func, (unsigned long)nmemb, (unsigned long)size
+    libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, L);
+    fprintf(stderr, L);
+    fflush(stderr);
+    _exit(-1);
+#undef M
+#undef L
 }
 
-int libxl__ptr_add(libxl__gc *gc, void *ptr)
+void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
-    void **re;
 
     if (!ptr)
-        return 0;
+        return;
 
     /* fast case: we have space in the array for storing the pointer */
     for (i = 0; i < gc->alloc_maxsize; i++) {
         if (!gc->alloc_ptrs[i]) {
             gc->alloc_ptrs[i] = ptr;
-            return 0;
+            return;
         }
     }
-    /* realloc alloc_ptrs manually with calloc/free/replace */
-    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
-    if (!re)
-        return -1;
-    for (i = 0; i < gc->alloc_maxsize; i++)
-        re[i] = gc->alloc_ptrs[i];
-    /* assign the next pointer */
-    re[i] = ptr;
+    int new_maxsize = gc->alloc_maxsize * 2 + 25;
+    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
+    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
+    if (!gc->alloc_ptrs)
+        libxl__alloc_failed(CTX, __func__, new_maxsize, sizeof(void*));
 
-    /* replace the old alloc_ptr */
-    free(gc->alloc_ptrs);
-    gc->alloc_ptrs = re;
-    gc->alloc_maxsize += 25;
-    return 0;
+    gc->alloc_ptrs[gc->alloc_maxsize++] = ptr;
+
+    while (gc->alloc_maxsize < new_maxsize)
+        gc->alloc_ptrs[gc->alloc_maxsize++] = 0;
+
+    return;
 }
 
 void libxl__free_all(libxl__gc *gc)
@@ -71,10 +76,7 @@ void libxl__free_all(libxl__gc *gc)
 void *libxl__zalloc(libxl__gc *gc, int bytes)
 {
     void *ptr = calloc(bytes, 1);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, bytes, 1);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -83,10 +85,7 @@ void *libxl__zalloc(libxl__gc *gc, int bytes)
 void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size)
 {
     void *ptr = calloc(nmemb, size);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(CTX, __func__, nmemb, size);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -97,9 +96,8 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
     void *new_ptr = realloc(ptr, new_size);
     int i = 0;
 
-    if (new_ptr == NULL && new_size != 0) {
-        return NULL;
-    }
+    if (new_ptr == NULL && new_size != 0)
+        libxl__alloc_failed(CTX, __func__, new_size, 1);
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
@@ -112,7 +110,6 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
         }
     }
 
-
     return new_ptr;
 }
 
@@ -126,16 +123,13 @@ char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...)
     ret = vsnprintf(NULL, 0, fmt, ap);
     va_end(ap);
 
-    if (ret < 0) {
-        return NULL;
-    }
+    assert(ret >= 0);
 
     s = libxl__zalloc(gc, ret + 1);
-    if (s) {
-        va_start(ap, fmt);
-        ret = vsnprintf(s, ret + 1, fmt, ap);
-        va_end(ap);
-    }
+    va_start(ap, fmt);
+    ret = vsnprintf(s, ret + 1, fmt, ap);
+    va_end(ap);
+
     return s;
 }
 
@@ -143,8 +137,9 @@ char *libxl__strdup(libxl__gc *gc, const char *c)
 {
     char *s = strdup(c);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, strlen(c), 1);
+
+    libxl__ptr_add(gc, s);
 
     return s;
 }
@@ -153,8 +148,7 @@ char *libxl__strndup(libxl__gc *gc, const char *c, size_t n)
 {
     char *s = strndup(c, n);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(CTX, __func__, n, 1);
 
     return s;
 }
@@ -175,6 +169,9 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
              const char *fmt, va_list ap)
 {
+    /* WARNING this function may not call any libxl-provided
+     * memory allocation function, as those may
+     * call libxl__alloc_failed which calls libxl__logv. */
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
     int rc, esave;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 04f13f6..2ad446a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -116,6 +116,12 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
+void libxl__alloc_failed(libxl_ctx *, const char *func,
+                         size_t nmemb, size_t size) __attribute__((noreturn));
+  /* func, size and nmemb are used only in the log message.
+   * You may pass size==0 if size and nmemb are not meaningful
+   * and should not be printed. */
+
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
@@ -380,7 +386,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * collection on exit from the outermost libxl callframe.
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9I-0006oZ-Gq; Wed, 11 Apr 2012 12:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nC-LG
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:46 +0000
Received: from [85.158.139.83:11771] by server-6.bemta-5.messagelabs.com id
	29/97-13222-140858F4; Wed, 11 Apr 2012 12:59:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17707 invoked from network); 11 Apr 2012 12:59:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kU-Hy; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000ke-HD;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:23 +0100
Message-ID: <1334149181-2834-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/19] .gitignore: Add a missing file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2782ee5..cd12b56 100644
--- a/.gitignore
+++ b/.gitignore
@@ -357,6 +357,7 @@ tools/firmware/etherboot/eb-roms.h
 tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
 tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
+tools/misc/xen-lowmemd
 tools/libvchan/vchan-node[12]
 tools/ocaml/*/.ocamldep.make
 tools/ocaml/*/*.cm[ixao]
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9L-0006qb-Ob; Wed, 11 Apr 2012 12:59:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nT-LJ
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:49801] by server-7.bemta-14.messagelabs.com id
	AA/99-01627-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26341 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002km-QW; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lG-P0;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:33 +0100
Message-ID: <1334149181-2834-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/19] libxl: Make libxl__zalloc et al tolerate
	a NULL gc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Arrange that if we pass NULL as a gc, we simply don't register the
pointer.  This instantly gives us non-gc'ing but error-checking
versions of malloc, realloc, vasprintf, etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    5 ++++-
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 4ed9412..b89aef7 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -34,6 +34,9 @@ void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
+    if (!gc)
+        return;
+
     if (!ptr)
         return;
 
@@ -101,7 +104,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr) {
+    } else if (new_ptr != ptr && gc != NULL) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ad446a..9340bde 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -384,30 +384,35 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  *
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
+ *
+ * However, where the argument is stated to be "gc_opt", NULL may be
+ * passed instead, in which case no garbage collection will occur; the
+ * pointer must later be freed with free().  This is for memory
+ * allocations of types (b) and (c).
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9O-0006tF-JT; Wed, 11 Apr 2012 12:59:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006nh-Fa
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [193.109.254.147:49865] by server-11.bemta-14.messagelabs.com
	id DE/52-05858-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26452 invoked from network); 11 Apr 2012 12:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ks-UK; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000ld-T1;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:37 +0100
Message-ID: <1334149181-2834-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/19] libxl: include <_libxl_paths.h> in
	libxl_internal.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ie, we permit general code in libxl direct access to the manifest
constants such as XEN_RUN_DIR.  This simplifies their use in (eg)
format strings.

This might be controversial because it will make it difficult to make
any of these runtime-configurable later without changing lots of use
sites.  But I don't think it's likely we'll want to do that.

For the moment, leave existing call sites of all the functions in
libxl_paths.c unchanged.  The simplified use arrangements can be used
in new code and when we update call sites for other reasons.

Also correct the dependencies in the Makefile so that _libxl_paths.h
is generated before anything that uses libxl_internal.h.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile         |    4 +---
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_paths.c    |    1 -
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b0143e6..9f7e454 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -102,11 +102,9 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl_paths.c: _libxl_paths.h
-
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
-libxl_internal.h: _libxl_types_internal.h
+libxl_internal.h: _libxl_types_internal.h _libxl_paths.h
 libxl_internal_json.h: _libxl_types_internal_json.h
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b35421f..740bde2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -51,6 +51,7 @@
 #include <xen/io/xenbus.h>
 
 #include "libxl.h"
+#include "_libxl_paths.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index a95d29f..388b344 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
-#include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9J-0006p0-9A; Wed, 11 Apr 2012 12:59:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9G-0006nD-UD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:20620] by server-10.bemta-14.messagelabs.com
	id A3/D5-05847-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26266 invoked from network); 11 Apr 2012 12:59:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kb-My; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000kw-LO;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:28 +0100
Message-ID: <1334149181-2834-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/19] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dd948a8..f41b62f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9N-0006sB-Fk; Wed, 11 Apr 2012 12:59:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006nh-0O
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [193.109.254.147:20732] by server-11.bemta-14.messagelabs.com
	id CC/52-05858-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26409 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9F-0002kz-0U; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lt-Vn;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:41 +0100
Message-ID: <1334149181-2834-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/19] libxl: provide STATE_AO_GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Provide a convenience macro for use in ao callback functions, and
document that it should be used.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a8372bb..a4b933b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1266,9 +1266,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
  *    - The one in ao, whose lifetime is the asynchronous operation
- *   Usually callback function should use CONTAINER_OF
- *   to obtain its own structure, containing a pointer to the ao,
- *   and then use the gc from that ao.
+ *   Usually callback function should use CONTAINER_OF to obtain its
+ *   own state structure, containing a pointer to the ao.  It should
+ *   then obtain the ao and use the ao's gc; this is most easily done
+ *   using the convenience macro STATE_AO_GC.
  */
 
 #define AO_CREATE(ctx, domid, ao_how)                           \
@@ -1298,6 +1299,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 #define AO_GC                                   \
     libxl__gc *const gc = &ao->gc
 
+#define STATE_AO_GC(op_ao)                      \
+    libxl__ao *const ao = (op_ao);              \
+    AO_GC
+
 
 /* All of these MUST be called with the ctx locked.
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9M-0006qw-8F; Wed, 11 Apr 2012 12:59:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nU-Hw
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:9898] by server-9.bemta-14.messagelabs.com id
	84/27-05787-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26318 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kd-Nk; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000l0-Mj;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:29 +0100
Message-ID: <1334149181-2834-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/19] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

Fix the configure test to test -pthread, and plumb the resulting flag
through to PTHREAD_{CFLAGS,LDFLAGS} in Tools.mk; also substitute
PTHREAD_LIBS (although this will currently always be empty).
Remove PTHREAD_LIBS setting from StdGNU.mk.

Fix the one user (libxc) to use PTHREAD_{CFLAGS,LDFLAGS} too.

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 config/StdGNU.mk     |    1 -
 config/Tools.mk.in   |    4 ++
 tools/configure      |  101 ++++++++++++++++++++++++++++++++++++--------------
 tools/configure.ac   |    5 +-
 tools/libxc/Makefile |    4 +-
 tools/m4/pthread.m4  |   41 ++++++++++++++++++++
 tools/m4/savevar.m4  |    6 +++
 7 files changed, 130 insertions(+), 32 deletions(-)
 create mode 100644 tools/m4/pthread.m4
 create mode 100644 tools/m4/savevar.m4

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index e2c9335..e2f2e1e 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,6 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 339a7b6..912d021 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -26,6 +26,10 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
+PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
+PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
+PTHREAD_LIBS        := @PTHREAD_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 64b7eb5..86618f5 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,9 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTHREAD_LIBS
+PTHREAD_LDFLAGS
+PTHREAD_CFLAGS
 libgcrypt
 libext2fs
 system_aio
@@ -3861,6 +3864,9 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
+
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -3924,6 +3930,22 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+
+
+
+
+
+
+
 
 # Enable/disable options
 
@@ -7228,47 +7250,70 @@ else
 fi
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in -lpthread" >&5
-$as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if test "${ac_cv_lib_pthread_pthread_create+set}" = set; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
+$as_echo_n "checking for pthread flag... " >&6; }
+if test "${ax_cv_pthread_flags+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
-  ac_check_lib_save_LIBS=$LIBS
-LIBS="-lpthread  $LIBS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+
+        ax_cv_pthread_flags=-pthread
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
+    saved_CFLAGS="$CFLAGS"
+
+    saved_LDFLAGS="$LDFLAGS"
+
+    saved_LIBS="$LIBS"
+
+
+    CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+    LDFLAGS="$LDFLAGS $PTHREAD_LDFLAGS"
+
+    LIBS="$LIBS $PTHREAD_LIBS"
+
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
-/* Override any GCC internal prototype to avoid an error.
-   Use char because int might match the return type of a GCC
-   builtin and then its argument prototype would still apply.  */
-#ifdef __cplusplus
-extern "C"
-#endif
-char pthread_create ();
-int
-main ()
-{
-return pthread_create ();
-  ;
-  return 0;
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
 }
+
 _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
-  ac_cv_lib_pthread_pthread_create=yes
+
 else
-  ac_cv_lib_pthread_pthread_create=no
+  ax_cv_pthread_flags=failed
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthread_create" >&5
-$as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" = x""yes; then :
 
-else
-  as_fn_error $? "Could not find libpthread" "$LINENO" 5
+    CFLAGS="$saved_CFLAGS"
+
+    LDFLAGS="$saved_LDFLAGS"
+
+    LIBS="$saved_LIBS"
+
+
 fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_pthread_flags" >&5
+$as_echo "$ax_cv_pthread_flags" >&6; }
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        as_fn_error $? "-pthread does not work" "$LINENO" 5
+    fi
+
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+
+
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index 0204e36..250dffd 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -23,6 +23,7 @@ AC_USE_SYSTEM_EXTENSIONS
 AC_CANONICAL_HOST
 
 # M4 Macro includes
+m4_include([m4/savevar.m4])
 m4_include([m4/features.m4])
 m4_include([m4/path_or_fail.m4])
 m4_include([m4/python_version.m4])
@@ -33,6 +34,7 @@ m4_include([m4/set_cflags_ldflags.m4])
 m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
+m4_include([m4/pthread.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -129,8 +131,7 @@ AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
 AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
-AC_CHECK_LIB([pthread], [pthread_create], [] ,
-    [AC_MSG_ERROR([Could not find libpthread])])
+AX_CHECK_PTHREAD
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 55eb755..a1ba134 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -73,6 +73,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -157,7 +159,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
diff --git a/tools/m4/pthread.m4 b/tools/m4/pthread.m4
new file mode 100644
index 0000000..57ea85c
--- /dev/null
+++ b/tools/m4/pthread.m4
@@ -0,0 +1,41 @@
+# We define, separately, PTHREAD_CFLAGS, _LDFLAGS and _LIBS
+# even though currently we don't set them very separately.
+# This means that the makefiles will not need to change in
+# the future if we make the test more sophisticated.
+
+AC_DEFUN([AX_PTHREAD_CV2VARS],[
+    PTHREAD_CFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LDFLAGS="$ax_cv_pthread_flags"
+    PTHREAD_LIBS=""
+])
+
+# We invoke AX_PTHREAD_VARS with the name of another macro
+# which is then expanded once for each variable.
+AC_DEFUN([AX_PTHREAD_VARS],[$1(CFLAGS) $1(LDFLAGS) $1(LIBS)])
+
+AC_DEFUN([AX_PTHREAD_VAR_APPLY],[
+    $1="$$1 $PTHREAD_$1"
+])
+AC_DEFUN([AX_PTHREAD_VAR_SUBST],[AC_SUBST(PTHREAD_$1)])
+
+AC_DEFUN([AX_CHECK_PTHREAD],[
+    AC_CACHE_CHECK([for pthread flag], [ax_cv_pthread_flags], [
+        ax_cv_pthread_flags=-pthread
+        AX_PTHREAD_CV2VARS
+        AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
+        AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
+        AC_LINK_IFELSE([
+#include <pthread.h>
+int main(void) {
+  pthread_atfork(0,0,0);
+  pthread_create(0,0,0,0);
+}
+],[],[ax_cv_pthread_flags=failed])
+        AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
+    ])
+    if test "x$ax_cv_pthread_flags" = xfailed; then
+        AC_MSG_ERROR([-pthread does not work])
+    fi
+    AX_PTHREAD_CV2VARS
+    AX_PTHREAD_VARS([AX_PTHREAD_VAR_SUBST])
+])
diff --git a/tools/m4/savevar.m4 b/tools/m4/savevar.m4
new file mode 100644
index 0000000..2156bee
--- /dev/null
+++ b/tools/m4/savevar.m4
@@ -0,0 +1,6 @@
+AC_DEFUN([AX_SAVEVAR_SAVE],[
+    saved_$1="$$1"
+])
+AC_DEFUN([AX_SAVEVAR_RESTORE],[
+    $1="$saved_$1"
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9O-0006tF-JT; Wed, 11 Apr 2012 12:59:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006nh-Fa
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:48 +0000
Received: from [193.109.254.147:49865] by server-11.bemta-14.messagelabs.com
	id DE/52-05858-340858F4; Wed, 11 Apr 2012 12:59:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26452 invoked from network); 11 Apr 2012 12:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002ks-UK; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000ld-T1;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:37 +0100
Message-ID: <1334149181-2834-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/19] libxl: include <_libxl_paths.h> in
	libxl_internal.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ie, we permit general code in libxl direct access to the manifest
constants such as XEN_RUN_DIR.  This simplifies their use in (eg)
format strings.

This might be controversial because it will make it difficult to make
any of these runtime-configurable later without changing lots of use
sites.  But I don't think it's likely we'll want to do that.

For the moment, leave existing call sites of all the functions in
libxl_paths.c unchanged.  The simplified use arrangements can be used
in new code and when we update call sites for other reasons.

Also correct the dependencies in the Makefile so that _libxl_paths.h
is generated before anything that uses libxl_internal.h.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile         |    4 +---
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_paths.c    |    1 -
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b0143e6..9f7e454 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -102,11 +102,9 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl_paths.c: _libxl_paths.h
-
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
-libxl_internal.h: _libxl_types_internal.h
+libxl_internal.h: _libxl_types_internal.h _libxl_paths.h
 libxl_internal_json.h: _libxl_types_internal_json.h
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b35421f..740bde2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -51,6 +51,7 @@
 #include <xen/io/xenbus.h>
 
 #include "libxl.h"
+#include "_libxl_paths.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index a95d29f..388b344 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
-#include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9L-0006qb-Ob; Wed, 11 Apr 2012 12:59:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9H-0006nT-LJ
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:47 +0000
Received: from [193.109.254.147:49801] by server-7.bemta-14.messagelabs.com id
	AA/99-01627-240858F4; Wed, 11 Apr 2012 12:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334149185!1015151!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26341 invoked from network); 11 Apr 2012 12:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002km-QW; Wed, 11 Apr 2012 12:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lG-P0;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:33 +0100
Message-ID: <1334149181-2834-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/19] libxl: Make libxl__zalloc et al tolerate
	a NULL gc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Arrange that if we pass NULL as a gc, we simply don't register the
pointer.  This instantly gives us non-gc'ing but error-checking
versions of malloc, realloc, vasprintf, etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    5 ++++-
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 4ed9412..b89aef7 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -34,6 +34,9 @@ void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
+    if (!gc)
+        return;
+
     if (!ptr)
         return;
 
@@ -101,7 +104,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr) {
+    } else if (new_ptr != ptr && gc != NULL) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ad446a..9340bde 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -384,30 +384,35 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  *
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
+ *
+ * However, where the argument is stated to be "gc_opt", NULL may be
+ * passed instead, in which case no garbage collection will occur; the
+ * pointer must later be freed with free().  This is for memory
+ * allocations of types (b) and (c).
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9P-0006tt-BJ; Wed, 11 Apr 2012 12:59:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006nO-SK
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:49 +0000
Received: from [85.158.139.83:12029] by server-5.bemta-5.messagelabs.com id
	7B/27-13566-440858F4; Wed, 11 Apr 2012 12:59:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17942 invoked from network); 11 Apr 2012 12:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kx-Vy; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lp-Ul;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:40 +0100
Message-ID: <1334149181-2834-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/19] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywhere in libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   13 ++++
 tools/libxl/libxl_fork.c     |  149 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 232 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9f7e454..e5ea867 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8910420..60dbfdc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index ea553f6..2d2196f 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -371,6 +371,19 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl_postfork_child_noexec in the child.  One call
+ * on any existing (or specially made) ctx is sufficient; after
+ * this all previously existing libxl_ctx's are invalidated and
+ * must not be used - or even freed.  It is harmless to call this
+ * postfork function and then exec anyway.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..dce88ad
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered) { rc = 0; goto out; }
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) {
+        assert(r == ENOMEM);
+        libxl__alloc_failed(ctx, __func__, 0,0);
+    }
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    libxl_fd_set_cloexec(ctx, fd, 1);
+    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    cf = libxl__carefd_record(ctx, fd);
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            if (r)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING,
+                                 "failed to close fd=%d"
+                                 " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    atfork_lock();
+    LIBXL_LIST_REMOVE(cf, entry);
+    atfork_unlock();
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 740bde2..a8372bb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -611,6 +611,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1307,6 +1310,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  Cannot fail. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  Cannot fail. */
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 62c0abd..a6ffd25 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -96,6 +96,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:00:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHx9P-0006tt-BJ; Wed, 11 Apr 2012 12:59:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHx9I-0006nO-SK
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 12:59:49 +0000
Received: from [85.158.139.83:12029] by server-5.bemta-5.messagelabs.com id
	7B/27-13566-440858F4; Wed, 11 Apr 2012 12:59:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334149184!19077302!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17942 invoked from network); 11 Apr 2012 12:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 12:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:59:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 13:59:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHx9E-0002kx-Vy; Wed, 11 Apr 2012 12:59:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHx9E-0000lp-Ul;
	Wed, 11 Apr 2012 13:59:44 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 11 Apr 2012 13:59:40 +0100
Message-ID: <1334149181-2834-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/19] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywhere in libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   13 ++++
 tools/libxl/libxl_fork.c     |  149 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 232 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9f7e454..e5ea867 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8910420..60dbfdc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index ea553f6..2d2196f 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -371,6 +371,19 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl_postfork_child_noexec in the child.  One call
+ * on any existing (or specially made) ctx is sufficient; after
+ * this all previously existing libxl_ctx's are invalidated and
+ * must not be used - or even freed.  It is harmless to call this
+ * postfork function and then exec anyway.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..dce88ad
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered) { rc = 0; goto out; }
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) {
+        assert(r == ENOMEM);
+        libxl__alloc_failed(ctx, __func__, 0,0);
+    }
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    libxl_fd_set_cloexec(ctx, fd, 1);
+    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    cf = libxl__carefd_record(ctx, fd);
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            if (r)
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING,
+                                 "failed to close fd=%d"
+                                 " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    atfork_lock();
+    LIBXL_LIST_REMOVE(cf, entry);
+    atfork_unlock();
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 740bde2..a8372bb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -611,6 +611,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1307,6 +1310,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  Cannot fail. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  Cannot fail. */
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 62c0abd..a6ffd25 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -96,6 +96,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:23:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxVj-0001XW-45; Wed, 11 Apr 2012 13:22:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxVi-0001XR-EB
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:22:58 +0000
Received: from [193.109.254.147:18097] by server-1.bemta-14.messagelabs.com id
	82/8D-29372-1B5858F4; Wed, 11 Apr 2012 13:22:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334150577!1648363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2523 invoked from network); 11 Apr 2012 13:22:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:22:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 13:22:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 14:22:56 +0100
Date: Wed, 11 Apr 2012 14:26:43 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/6] qdisk local attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch implements local_attach support for QDISK: that means that
you can use qcow2 as disk format for your PV guests disks and use
pygrub to retrieve the kernel and initrd in dom0.

The idea is that we start a QEMU instance at boot time to listen to
local_attach requests. When libxl_device_disk_local_attach is called on
a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk
so that blkfront in dom0 will create a new xvd device for it.
Then pygrub can be pointed at this device to retrieve kernel and
initrd.


Changes in v2:
- make libxl_device_disk_local_(de)attach internal functions;
- allocate the new disk in libxl_device_disk_local_attatch on the GC;
- remove libxl__device_generic_add_t, add a transaction parameter to
libxl__device_generic_add instead;
- add a new patch to introduce a blkdev_start option to xl.conf;
- reimplement libxl__alloc_vdev checking for the frontend path and
starting from blkdev_start;
- introduce a Linux specific libxl__devid_to_vdev function based on last
Jan's patch to blkfront.


Stefano Stabellini (6):
      libxl: libxl__device_disk_local_attach return a new libxl_device_disk
      libxl: add a transaction parameter to libxl__device_generic_add
      libxl: introduce libxl__device_disk_add_t
      xl/libxl: add a blkdev_start parameter
      libxl: introduce libxl__alloc_vdev
      xl/libxl: implement QDISK libxl_device_disk_local_attach

 tools/examples/xl.conf                          |    3 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl.c                             |  232 +------------------
 tools/libxl/libxl.h                             |   17 +-
 tools/libxl/libxl_bootloader.c                  |   13 +-
 tools/libxl/libxl_create.c                      |   18 +-
 tools/libxl/libxl_device.c                      |   14 +-
 tools/libxl/libxl_internal.c                    |  285 +++++++++++++++++++++++
 tools/libxl/libxl_internal.h                    |   24 ++-
 tools/libxl/libxl_linux.c                       |   40 ++++
 tools/libxl/libxl_netbsd.c                      |    6 +
 tools/libxl/libxl_pci.c                         |    2 +-
 tools/libxl/xl.c                                |    3 +
 tools/libxl/xl.h                                |    1 +
 tools/libxl/xl_cmdimpl.c                        |    5 +-
 16 files changed, 408 insertions(+), 261 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:23:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxVj-0001XW-45; Wed, 11 Apr 2012 13:22:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxVi-0001XR-EB
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:22:58 +0000
Received: from [193.109.254.147:18097] by server-1.bemta-14.messagelabs.com id
	82/8D-29372-1B5858F4; Wed, 11 Apr 2012 13:22:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334150577!1648363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2523 invoked from network); 11 Apr 2012 13:22:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:22:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11878698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 13:22:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 14:22:56 +0100
Date: Wed, 11 Apr 2012 14:26:43 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/6] qdisk local attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch implements local_attach support for QDISK: that means that
you can use qcow2 as disk format for your PV guests disks and use
pygrub to retrieve the kernel and initrd in dom0.

The idea is that we start a QEMU instance at boot time to listen to
local_attach requests. When libxl_device_disk_local_attach is called on
a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk
so that blkfront in dom0 will create a new xvd device for it.
Then pygrub can be pointed at this device to retrieve kernel and
initrd.


Changes in v2:
- make libxl_device_disk_local_(de)attach internal functions;
- allocate the new disk in libxl_device_disk_local_attatch on the GC;
- remove libxl__device_generic_add_t, add a transaction parameter to
libxl__device_generic_add instead;
- add a new patch to introduce a blkdev_start option to xl.conf;
- reimplement libxl__alloc_vdev checking for the frontend path and
starting from blkdev_start;
- introduce a Linux specific libxl__devid_to_vdev function based on last
Jan's patch to blkfront.


Stefano Stabellini (6):
      libxl: libxl__device_disk_local_attach return a new libxl_device_disk
      libxl: add a transaction parameter to libxl__device_generic_add
      libxl: introduce libxl__device_disk_add_t
      xl/libxl: add a blkdev_start parameter
      libxl: introduce libxl__alloc_vdev
      xl/libxl: implement QDISK libxl_device_disk_local_attach

 tools/examples/xl.conf                          |    3 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl.c                             |  232 +------------------
 tools/libxl/libxl.h                             |   17 +-
 tools/libxl/libxl_bootloader.c                  |   13 +-
 tools/libxl/libxl_create.c                      |   18 +-
 tools/libxl/libxl_device.c                      |   14 +-
 tools/libxl/libxl_internal.c                    |  285 +++++++++++++++++++++++
 tools/libxl/libxl_internal.h                    |   24 ++-
 tools/libxl/libxl_linux.c                       |   40 ++++
 tools/libxl/libxl_netbsd.c                      |    6 +
 tools/libxl/libxl_pci.c                         |    2 +-
 tools/libxl/xl.c                                |    3 +
 tools/libxl/xl.h                                |    1 +
 tools/libxl/xl_cmdimpl.c                        |    5 +-
 16 files changed, 408 insertions(+), 261 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:27:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaO-0001iB-Qx; Wed, 11 Apr 2012 13:27:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaN-0001i5-3Z
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:47 +0000
Received: from [85.158.139.83:39785] by server-12.bemta-5.messagelabs.com id
	3E/03-05587-2D6858F4; Wed, 11 Apr 2012 13:27:46 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23902 invoked from network); 11 Apr 2012 13:27:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:44 -0000
Received: by eeit10 with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=M1UIo+TtHpaEQhZeAzacjmJp7hBVC4ijOYO4+4OWzU8=;
	b=zF2exQcMwbQaHE9cbjV/UXQbq+81Gdg2srtrY707pPXUoqu15xBUMNo2oyZrplYq1O
	5Bs5Vgw3J/XfVI1I4jm9jTWWOkoEMmAn4wKRk7eL++zQc2UwUS3SPzJ3PRTC0yQGq9kQ
	t6Fk5H7S3tRXSguF3Wt3nyVoB7Djoxns+TB6delsH4DaDc+kzPP4+AoGKq17/3cZBTIc
	mq74R8gqVRAs0ygogM5ldfyR1lpdou6dS18Uonmzb1vQ6e9KbbU7I9nw2f8DZCvK5tJ6
	QYNMdCAkqsdtfR8mdWaBP0G5+hkomuyNs9i9D3FMn42kziAWL5ZaPOIvC242iQQwlw+T
	YnBg==
Received: by 10.14.119.137 with SMTP id n9mr1975005eeh.69.1334150863905;
	Wed, 11 Apr 2012 06:27:43 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:42 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:47 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 00 of 10 [RFC]] Automatically place guest on
 host's NUMA nodes with xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Everybody,

This is the first take of the automatic placement of a guest on the host NUMA
nodes I've been working on for a while. It, right now, takes into account the
amount of memory the guest needs as compared to the amount of free memory on
the various nodes.

It's still in [RFC] status, as there are still quite a bit of design choices
I'd like to discuss, and quite a bit of changes I've made on which I'd really
like to have a second opinion. :-P

Just very quickly, these are refactorings of existing data structures and code,
paving the way for the real "meat":

 1 of 10  libxc: Generalize xenctl_cpumap to just xenctl_map
 2 of 10  libxl: Generalize libxl_cpumap to just libxl_map
 3 of 10  libxc, libxl: Introduce xc_nodemap_t and libxl_nodemap
 4 of 10  libxl: Introduce libxl_get_numainfo() calling xc_numainfo()


These enable NUMA affinity to be eplicitly specified with xl, both via
config file and command line:

 5 of 10  xl: Explicit node affinity specification for guests via config file
 6 of 10  xl: Allow user to set or change node affinity on-line


And this is where the fun happens, as these patches contain the core of the
automatic placement logic and the modifications to the (credit) scheduler
needed for taking NUMA node affinity into account:

 7 of 10  sched_credit: Let the scheduler know about `node affinity`
 8 of 10  xl: Introduce First Fit memory-wise placement of guests on nodes
 9 of 10  xl: Introduce Best and Worst Fit guest placement algorithms

Finally, here it comes some rationale and user-level oriented documentation:
 10 of 10 xl: Some automatic NUMA placement documentation


Some of the changelogs contain a TODO list, with stuff that need to be
considered, thought about, or just added, perhaps in the next version of the
series. Also, the various patches have quite a bit of 'XXX' marked code
comments, to better highlight the spots where I think I might have done
something scary, or where I would like discussion the to concentrate on.
Providing any kind of feedback about these design and coding decisions (I mean
the TODOs and XXXs) I made, is really going to be of great help to me! :-)

As per the timing... I know we're in feature freeze, and I don't see much about
the issue this series tackles in the release plan. So, I'll be more than happy
if (even if just some of) the patches becomes 4.2 material, and I can commit on
giving them as much testing and benchmarking as possible, but I understand if
this is judged to be too immature for being considered.

I did some benchmarking about the current performances of Xen on a (small) NUMA
machine, and you can see them here:

 http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005/

This is _before_ any of these patches, just xen-unstable with plain
vcpu-pinning.  As changelogs say, I'm benchmarking the various features this
series introduces as well, and I'll share the results as soon as they'll be
ready.

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:27:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaO-0001iB-Qx; Wed, 11 Apr 2012 13:27:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaN-0001i5-3Z
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:47 +0000
Received: from [85.158.139.83:39785] by server-12.bemta-5.messagelabs.com id
	3E/03-05587-2D6858F4; Wed, 11 Apr 2012 13:27:46 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23902 invoked from network); 11 Apr 2012 13:27:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:44 -0000
Received: by eeit10 with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=M1UIo+TtHpaEQhZeAzacjmJp7hBVC4ijOYO4+4OWzU8=;
	b=zF2exQcMwbQaHE9cbjV/UXQbq+81Gdg2srtrY707pPXUoqu15xBUMNo2oyZrplYq1O
	5Bs5Vgw3J/XfVI1I4jm9jTWWOkoEMmAn4wKRk7eL++zQc2UwUS3SPzJ3PRTC0yQGq9kQ
	t6Fk5H7S3tRXSguF3Wt3nyVoB7Djoxns+TB6delsH4DaDc+kzPP4+AoGKq17/3cZBTIc
	mq74R8gqVRAs0ygogM5ldfyR1lpdou6dS18Uonmzb1vQ6e9KbbU7I9nw2f8DZCvK5tJ6
	QYNMdCAkqsdtfR8mdWaBP0G5+hkomuyNs9i9D3FMn42kziAWL5ZaPOIvC242iQQwlw+T
	YnBg==
Received: by 10.14.119.137 with SMTP id n9mr1975005eeh.69.1334150863905;
	Wed, 11 Apr 2012 06:27:43 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:42 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:47 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 00 of 10 [RFC]] Automatically place guest on
 host's NUMA nodes with xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Everybody,

This is the first take of the automatic placement of a guest on the host NUMA
nodes I've been working on for a while. It, right now, takes into account the
amount of memory the guest needs as compared to the amount of free memory on
the various nodes.

It's still in [RFC] status, as there are still quite a bit of design choices
I'd like to discuss, and quite a bit of changes I've made on which I'd really
like to have a second opinion. :-P

Just very quickly, these are refactorings of existing data structures and code,
paving the way for the real "meat":

 1 of 10  libxc: Generalize xenctl_cpumap to just xenctl_map
 2 of 10  libxl: Generalize libxl_cpumap to just libxl_map
 3 of 10  libxc, libxl: Introduce xc_nodemap_t and libxl_nodemap
 4 of 10  libxl: Introduce libxl_get_numainfo() calling xc_numainfo()


These enable NUMA affinity to be eplicitly specified with xl, both via
config file and command line:

 5 of 10  xl: Explicit node affinity specification for guests via config file
 6 of 10  xl: Allow user to set or change node affinity on-line


And this is where the fun happens, as these patches contain the core of the
automatic placement logic and the modifications to the (credit) scheduler
needed for taking NUMA node affinity into account:

 7 of 10  sched_credit: Let the scheduler know about `node affinity`
 8 of 10  xl: Introduce First Fit memory-wise placement of guests on nodes
 9 of 10  xl: Introduce Best and Worst Fit guest placement algorithms

Finally, here it comes some rationale and user-level oriented documentation:
 10 of 10 xl: Some automatic NUMA placement documentation


Some of the changelogs contain a TODO list, with stuff that need to be
considered, thought about, or just added, perhaps in the next version of the
series. Also, the various patches have quite a bit of 'XXX' marked code
comments, to better highlight the spots where I think I might have done
something scary, or where I would like discussion the to concentrate on.
Providing any kind of feedback about these design and coding decisions (I mean
the TODOs and XXXs) I made, is really going to be of great help to me! :-)

As per the timing... I know we're in feature freeze, and I don't see much about
the issue this series tackles in the release plan. So, I'll be more than happy
if (even if just some of) the patches becomes 4.2 material, and I can commit on
giving them as much testing and benchmarking as possible, but I understand if
this is judged to be too immature for being considered.

I did some benchmarking about the current performances of Xen on a (small) NUMA
machine, and you can see them here:

 http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005/

This is _before_ any of these patches, just xen-unstable with plain
vcpu-pinning.  As changelogs say, I'm benchmarking the various features this
series introduces as well, and I'll share the results as soon as they'll be
ready.

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:27:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaQ-0001ic-CV; Wed, 11 Apr 2012 13:27:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaO-0001iA-Q3
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:49 +0000
Received: from [85.158.139.83:2520] by server-4.bemta-5.messagelabs.com id
	AD/29-10788-3D6858F4; Wed, 11 Apr 2012 13:27:47 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24016 invoked from network); 11 Apr 2012 13:27:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:46 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=YGZnIArGLJF+lveRSOySeiIj8CeJ9AEIXMjt8X1t2F8=;
	b=fBuX/4qmua46qm3ndebvGGODLMhN3jF14g2L1UGOvJdTfScQvLwiaPLlc7j1RiSKp2
	j5/zu69h0oJVuPkzbGeRAxF+z2ay/MlnzI7A3bsmmltzWBDEDKvvqVDiIv8h/6mSiuGh
	hk3sclZUFDndFKVFOMBYs0ZlGr/q/HfluBX0ZPQKgJzG2LDyWNaF6gp+97IUxPcFqVNW
	CGiaTFtJP92CwHKO1LWLci3hgG6ez/r9Pt6Pk4LcRa4EdnELQKkRwdTaB5XL8EmIv7o4
	JQVCFHaUN1km/6tnhgH+4+YP6asKbPfcnoPWvo/CyGyvDp5VrhLftk07LyV7IEW6gNKi
	uuhQ==
Received: by 10.213.34.142 with SMTP id l14mr974481ebd.0.1334150866441;
	Wed, 11 Apr 2012 06:27:46 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:45 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e63c137d9fc551ca941aa9904a241614a0047df5
Message-Id: <e63c137d9fc551ca941a.1334150268@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:48 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize xenctl_cpumap
 to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for adding an xc_nodemap_t and its related
hadling logic. Just add one indirection layer, and try to
retain the interface as much as possible (although some
small bits here and there have been affected).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>

diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
--- a/tools/libxc/xc_cpupool.c
+++ b/tools/libxc/xc_cpupool.c
@@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_
     sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO;
     sysctl.u.cpupool_op.cpupool_id = poolid;
     set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
-    sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8;
+    sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8;
 
     err = do_sysctl_save(xch, &sysctl);
 
@@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter
     sysctl.cmd = XEN_SYSCTL_cpupool_op;
     sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO;
     set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
-    sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8;
+    sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8;
 
     err = do_sysctl_save(xch, &sysctl);
 
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc
 
     set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
 
-    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
+    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
 
     ret = do_domctl(xch, &domctl);
 
@@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc
     domctl.u.vcpuaffinity.vcpu = vcpu;
 
     set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
-    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
+    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
 
     ret = do_domctl(xch, &domctl);
 
diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c
--- a/tools/libxc/xc_tbuf.c
+++ b/tools/libxc/xc_tbuf.c
@@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x
     bitmap_64_to_byte(bytemap, &mask64, sizeof (mask64) * 8);
 
     set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap);
-    sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8;
+    sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8;
 
     ret = do_sysctl(xch, &sysctl);
 
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -365,7 +365,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     {
         uint32_t cpu;
         uint64_t idletime, now = NOW();
-        struct xenctl_cpumap ctlmap;
+        struct xenctl_map ctlmap;
         cpumask_var_t cpumap;
         XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
         XEN_GUEST_HANDLE(uint64) idletimes;
@@ -378,7 +378,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
         if ( cpufreq_controller != FREQCTL_dom0_kernel )
             break;
 
-        ctlmap.nr_cpus  = op->u.getidletime.cpumap_nr_cpus;
+        ctlmap.nr_elems  = op->u.getidletime.cpumap_nr_cpus;
         guest_from_compat_handle(cpumap_bitmap,
                                  op->u.getidletime.cpumap_bitmap);
         ctlmap.bitmap.p = cpumap_bitmap.p; /* handle -> handle_64 conversion */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -31,28 +31,29 @@
 static DEFINE_SPINLOCK(domctl_lock);
 DEFINE_SPINLOCK(vcpu_alloc_lock);
 
-int cpumask_to_xenctl_cpumap(
-    struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
+int bitmap_to_xenctl_map(struct xenctl_map *xenctl_map,
+                         const unsigned long *bitmap,
+                         unsigned int nbits)
 {
     unsigned int guest_bytes, copy_bytes, i;
     uint8_t zero = 0;
     int err = 0;
-    uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
+    uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8);
 
     if ( !bytemap )
         return -ENOMEM;
 
-    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
-    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
+    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
+    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
 
-    bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids);
+    bitmap_long_to_byte(bytemap, bitmap, nbits);
 
     if ( copy_bytes != 0 )
-        if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) )
+        if ( copy_to_guest(xenctl_map->bitmap, bytemap, copy_bytes) )
             err = -EFAULT;
 
     for ( i = copy_bytes; !err && i < guest_bytes; i++ )
-        if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i, &zero, 1) )
+        if ( copy_to_guest_offset(xenctl_map->bitmap, i, &zero, 1) )
             err = -EFAULT;
 
     xfree(bytemap);
@@ -60,36 +61,58 @@ int cpumask_to_xenctl_cpumap(
     return err;
 }
 
-int xenctl_cpumap_to_cpumask(
-    cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap)
+int xenctl_map_to_bitmap(unsigned long *bitmap,
+                         const struct xenctl_map *xenctl_map,
+                         unsigned int nbits)
 {
     unsigned int guest_bytes, copy_bytes;
     int err = 0;
-    uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
+    uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8);
 
     if ( !bytemap )
         return -ENOMEM;
 
-    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
-    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
+    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
+    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
 
     if ( copy_bytes != 0 )
     {
-        if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) )
+        if ( copy_from_guest(bytemap, xenctl_map->bitmap, copy_bytes) )
             err = -EFAULT;
-        if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes <= sizeof(bytemap)) )
-            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7));
+        if ( (xenctl_map->nr_elems & 7) && (guest_bytes <= sizeof(bytemap)) )
+            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_map->nr_elems & 7));
     }
 
-    if ( err )
-        /* nothing */;
-    else if ( alloc_cpumask_var(cpumask) )
-        bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids);
+    if ( !err )
+        bitmap_byte_to_long(bitmap, bytemap, nbits);
+
+    xfree(bytemap);
+
+    return err;
+}
+
+int cpumask_to_xenctl_cpumap(struct xenctl_map *xenctl_cpumap,
+                             const cpumask_t *cpumask)
+{
+    return bitmap_to_xenctl_map(xenctl_cpumap, cpumask_bits(cpumask),
+                                nr_cpu_ids);
+}
+
+int xenctl_cpumap_to_cpumask(cpumask_var_t *cpumask,
+                             const struct xenctl_map *xenctl_cpumap)
+{
+    int err = 0;
+
+    if ( alloc_cpumask_var(cpumask) ) {
+        err = xenctl_map_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap,
+                                   nr_cpu_ids);
+        /* In case of error, cleanup is up to us, as the caller won't care! */
+        if ( err )
+            free_cpumask_var(*cpumask);
+    }
     else
         err = -ENOMEM;
 
-    xfree(bytemap);
-
     return err;
 }
 
diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -414,7 +414,7 @@ struct xen_mc_mceinject {
 
 struct xen_mc_inject_v2 {
 	uint32_t flags;
-	struct xenctl_cpumap cpumap;
+	struct xenctl_map cpumap;
 };
 #endif
 
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -283,7 +283,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc
 /* XEN_DOMCTL_getvcpuaffinity */
 struct xen_domctl_vcpuaffinity {
     uint32_t  vcpu;              /* IN */
-    struct xenctl_cpumap cpumap; /* IN/OUT */
+    struct xenctl_map cpumap;    /* IN/OUT */
 };
 typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t);
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -71,8 +71,8 @@ struct xen_sysctl_tbuf_op {
 #define XEN_SYSCTL_TBUFOP_disable      5
     uint32_t cmd;
     /* IN/OUT variables */
-    struct xenctl_cpumap cpu_mask;
-    uint32_t             evt_mask;
+    struct xenctl_map cpu_mask;
+    uint32_t          evt_mask;
     /* OUT variables */
     uint64_aligned_t buffer_mfn;
     uint32_t size;  /* Also an IN variable! */
@@ -531,7 +531,7 @@ struct xen_sysctl_cpupool_op {
     uint32_t domid;       /* IN: M              */
     uint32_t cpu;         /* IN: AR             */
     uint32_t n_dom;       /*            OUT: I  */
-    struct xenctl_cpumap cpumap; /*     OUT: IF */
+    struct xenctl_map cpumap;    /*     OUT: IF */
 };
 typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -822,9 +822,9 @@ typedef uint8_t xen_domain_handle_t[16];
 #endif
 
 #ifndef __ASSEMBLY__
-struct xenctl_cpumap {
+struct xenctl_map {
     XEN_GUEST_HANDLE_64(uint8) bitmap;
-    uint32_t nr_cpus;
+    uint32_t nr_elems;
 };
 #endif
 
diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
 #define for_each_present_cpu(cpu)  for_each_cpu(cpu, &cpu_present_map)
 
 /* Copy to/from cpumap provided by control tools. */
-struct xenctl_cpumap;
-int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *);
-int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *);
+struct xenctl_map;
+int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *);
+int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_map *);
 
 #endif /* __XEN_CPUMASK_H */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -2,7 +2,7 @@
 # ! - needs translation
 # ? - needs checking
 ?	dom0_vga_console_info		xen.h
-?	xenctl_cpumap			xen.h
+?	xenctl_map			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
 !	start_info			xen.h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:27:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaQ-0001ic-CV; Wed, 11 Apr 2012 13:27:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaO-0001iA-Q3
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:49 +0000
Received: from [85.158.139.83:2520] by server-4.bemta-5.messagelabs.com id
	AD/29-10788-3D6858F4; Wed, 11 Apr 2012 13:27:47 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24016 invoked from network); 11 Apr 2012 13:27:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:46 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=YGZnIArGLJF+lveRSOySeiIj8CeJ9AEIXMjt8X1t2F8=;
	b=fBuX/4qmua46qm3ndebvGGODLMhN3jF14g2L1UGOvJdTfScQvLwiaPLlc7j1RiSKp2
	j5/zu69h0oJVuPkzbGeRAxF+z2ay/MlnzI7A3bsmmltzWBDEDKvvqVDiIv8h/6mSiuGh
	hk3sclZUFDndFKVFOMBYs0ZlGr/q/HfluBX0ZPQKgJzG2LDyWNaF6gp+97IUxPcFqVNW
	CGiaTFtJP92CwHKO1LWLci3hgG6ez/r9Pt6Pk4LcRa4EdnELQKkRwdTaB5XL8EmIv7o4
	JQVCFHaUN1km/6tnhgH+4+YP6asKbPfcnoPWvo/CyGyvDp5VrhLftk07LyV7IEW6gNKi
	uuhQ==
Received: by 10.213.34.142 with SMTP id l14mr974481ebd.0.1334150866441;
	Wed, 11 Apr 2012 06:27:46 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:45 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e63c137d9fc551ca941aa9904a241614a0047df5
Message-Id: <e63c137d9fc551ca941a.1334150268@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:48 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize xenctl_cpumap
 to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for adding an xc_nodemap_t and its related
hadling logic. Just add one indirection layer, and try to
retain the interface as much as possible (although some
small bits here and there have been affected).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>

diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
--- a/tools/libxc/xc_cpupool.c
+++ b/tools/libxc/xc_cpupool.c
@@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_
     sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO;
     sysctl.u.cpupool_op.cpupool_id = poolid;
     set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
-    sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8;
+    sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8;
 
     err = do_sysctl_save(xch, &sysctl);
 
@@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter
     sysctl.cmd = XEN_SYSCTL_cpupool_op;
     sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO;
     set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
-    sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8;
+    sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8;
 
     err = do_sysctl_save(xch, &sysctl);
 
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc
 
     set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
 
-    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
+    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
 
     ret = do_domctl(xch, &domctl);
 
@@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc
     domctl.u.vcpuaffinity.vcpu = vcpu;
 
     set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
-    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
+    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
 
     ret = do_domctl(xch, &domctl);
 
diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c
--- a/tools/libxc/xc_tbuf.c
+++ b/tools/libxc/xc_tbuf.c
@@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x
     bitmap_64_to_byte(bytemap, &mask64, sizeof (mask64) * 8);
 
     set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap);
-    sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8;
+    sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8;
 
     ret = do_sysctl(xch, &sysctl);
 
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -365,7 +365,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     {
         uint32_t cpu;
         uint64_t idletime, now = NOW();
-        struct xenctl_cpumap ctlmap;
+        struct xenctl_map ctlmap;
         cpumask_var_t cpumap;
         XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
         XEN_GUEST_HANDLE(uint64) idletimes;
@@ -378,7 +378,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
         if ( cpufreq_controller != FREQCTL_dom0_kernel )
             break;
 
-        ctlmap.nr_cpus  = op->u.getidletime.cpumap_nr_cpus;
+        ctlmap.nr_elems  = op->u.getidletime.cpumap_nr_cpus;
         guest_from_compat_handle(cpumap_bitmap,
                                  op->u.getidletime.cpumap_bitmap);
         ctlmap.bitmap.p = cpumap_bitmap.p; /* handle -> handle_64 conversion */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -31,28 +31,29 @@
 static DEFINE_SPINLOCK(domctl_lock);
 DEFINE_SPINLOCK(vcpu_alloc_lock);
 
-int cpumask_to_xenctl_cpumap(
-    struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
+int bitmap_to_xenctl_map(struct xenctl_map *xenctl_map,
+                         const unsigned long *bitmap,
+                         unsigned int nbits)
 {
     unsigned int guest_bytes, copy_bytes, i;
     uint8_t zero = 0;
     int err = 0;
-    uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
+    uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8);
 
     if ( !bytemap )
         return -ENOMEM;
 
-    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
-    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
+    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
+    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
 
-    bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids);
+    bitmap_long_to_byte(bytemap, bitmap, nbits);
 
     if ( copy_bytes != 0 )
-        if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) )
+        if ( copy_to_guest(xenctl_map->bitmap, bytemap, copy_bytes) )
             err = -EFAULT;
 
     for ( i = copy_bytes; !err && i < guest_bytes; i++ )
-        if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i, &zero, 1) )
+        if ( copy_to_guest_offset(xenctl_map->bitmap, i, &zero, 1) )
             err = -EFAULT;
 
     xfree(bytemap);
@@ -60,36 +61,58 @@ int cpumask_to_xenctl_cpumap(
     return err;
 }
 
-int xenctl_cpumap_to_cpumask(
-    cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap)
+int xenctl_map_to_bitmap(unsigned long *bitmap,
+                         const struct xenctl_map *xenctl_map,
+                         unsigned int nbits)
 {
     unsigned int guest_bytes, copy_bytes;
     int err = 0;
-    uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
+    uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8);
 
     if ( !bytemap )
         return -ENOMEM;
 
-    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
-    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
+    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
+    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
 
     if ( copy_bytes != 0 )
     {
-        if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) )
+        if ( copy_from_guest(bytemap, xenctl_map->bitmap, copy_bytes) )
             err = -EFAULT;
-        if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes <= sizeof(bytemap)) )
-            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7));
+        if ( (xenctl_map->nr_elems & 7) && (guest_bytes <= sizeof(bytemap)) )
+            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_map->nr_elems & 7));
     }
 
-    if ( err )
-        /* nothing */;
-    else if ( alloc_cpumask_var(cpumask) )
-        bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids);
+    if ( !err )
+        bitmap_byte_to_long(bitmap, bytemap, nbits);
+
+    xfree(bytemap);
+
+    return err;
+}
+
+int cpumask_to_xenctl_cpumap(struct xenctl_map *xenctl_cpumap,
+                             const cpumask_t *cpumask)
+{
+    return bitmap_to_xenctl_map(xenctl_cpumap, cpumask_bits(cpumask),
+                                nr_cpu_ids);
+}
+
+int xenctl_cpumap_to_cpumask(cpumask_var_t *cpumask,
+                             const struct xenctl_map *xenctl_cpumap)
+{
+    int err = 0;
+
+    if ( alloc_cpumask_var(cpumask) ) {
+        err = xenctl_map_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap,
+                                   nr_cpu_ids);
+        /* In case of error, cleanup is up to us, as the caller won't care! */
+        if ( err )
+            free_cpumask_var(*cpumask);
+    }
     else
         err = -ENOMEM;
 
-    xfree(bytemap);
-
     return err;
 }
 
diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -414,7 +414,7 @@ struct xen_mc_mceinject {
 
 struct xen_mc_inject_v2 {
 	uint32_t flags;
-	struct xenctl_cpumap cpumap;
+	struct xenctl_map cpumap;
 };
 #endif
 
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -283,7 +283,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc
 /* XEN_DOMCTL_getvcpuaffinity */
 struct xen_domctl_vcpuaffinity {
     uint32_t  vcpu;              /* IN */
-    struct xenctl_cpumap cpumap; /* IN/OUT */
+    struct xenctl_map cpumap;    /* IN/OUT */
 };
 typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t);
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -71,8 +71,8 @@ struct xen_sysctl_tbuf_op {
 #define XEN_SYSCTL_TBUFOP_disable      5
     uint32_t cmd;
     /* IN/OUT variables */
-    struct xenctl_cpumap cpu_mask;
-    uint32_t             evt_mask;
+    struct xenctl_map cpu_mask;
+    uint32_t          evt_mask;
     /* OUT variables */
     uint64_aligned_t buffer_mfn;
     uint32_t size;  /* Also an IN variable! */
@@ -531,7 +531,7 @@ struct xen_sysctl_cpupool_op {
     uint32_t domid;       /* IN: M              */
     uint32_t cpu;         /* IN: AR             */
     uint32_t n_dom;       /*            OUT: I  */
-    struct xenctl_cpumap cpumap; /*     OUT: IF */
+    struct xenctl_map cpumap;    /*     OUT: IF */
 };
 typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -822,9 +822,9 @@ typedef uint8_t xen_domain_handle_t[16];
 #endif
 
 #ifndef __ASSEMBLY__
-struct xenctl_cpumap {
+struct xenctl_map {
     XEN_GUEST_HANDLE_64(uint8) bitmap;
-    uint32_t nr_cpus;
+    uint32_t nr_elems;
 };
 #endif
 
diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
 #define for_each_present_cpu(cpu)  for_each_cpu(cpu, &cpu_present_map)
 
 /* Copy to/from cpumap provided by control tools. */
-struct xenctl_cpumap;
-int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *);
-int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *);
+struct xenctl_map;
+int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *);
+int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_map *);
 
 #endif /* __XEN_CPUMASK_H */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -2,7 +2,7 @@
 # ! - needs translation
 # ? - needs checking
 ?	dom0_vga_console_info		xen.h
-?	xenctl_cpumap			xen.h
+?	xenctl_map			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
 !	start_info			xen.h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaR-0001j0-Oh; Wed, 11 Apr 2012 13:27:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaQ-0001ig-UY
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:51 +0000
Received: from [85.158.139.83:40137] by server-7.bemta-5.messagelabs.com id
	92/2C-16195-6D6858F4; Wed, 11 Apr 2012 13:27:50 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!3
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24167 invoked from network); 11 Apr 2012 13:27:49 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:49 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=DoOos6i0dzz5D67Z43YVC5dPyP8YVMeQDTFa2rdASE0=;
	b=loW37OcXqWywi3J9WsB5xH1BcYhzO7h3qhlowYHWFocwlaJFN8EbA16gXFgjBaw9Ww
	GPMldP6A2RtOyapbiQmQbavIHl1U6qD5KYaytUthAF0Vi3C8Vy/dMbJr+xF0YHmzj09p
	7FSnqh94ng1poQHPOO6mGzz0sOJmY/QO1ibV3GarENc44ZJcu3O05DQNKfHROjqZB1b6
	9dkXJ6vqDZQa3nX4mP6A5WxrfBjma/HfKnfHr1TFmt6b+PcPnMBKVfUXWt7qKL1AGSHD
	OkWyyYbDfbvKZLaaa7nlfVaWrFIMLKVi/3EXhxsOPf83m6Efvm8nN6YDPTOJKKlQQjA4
	tnTw==
Received: by 10.213.8.130 with SMTP id h2mr980676ebh.32.1334150868837;
	Wed, 11 Apr 2012 06:27:48 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.46
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:47 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 3edc8654216a9004331066bc8e7977e2935363a4
Message-Id: <3edc8654216a90043310.1334150269@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:49 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 02 of 10 [RFC]] libxl: Generalize libxl_cpumap
 to just libxl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for adding a libxl_nodemap and its related
hadling logic. No changes to the interface this time.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -277,11 +277,23 @@ typedef uint32_t libxl_hwcap[8];
 
 typedef uint64_t libxl_ev_user;
 
-typedef struct {
+struct libxl_map {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
-} libxl_cpumap;
-void libxl_cpumap_dispose(libxl_cpumap *map);
+};
+void libxl_map_dispose(struct libxl_map *map);
+
+typedef struct libxl_map libxl_cpumap;
+static inline void libxl_cpumap_dispose(libxl_cpumap *cpumap)
+{
+    return libxl_map_dispose(cpumap);
+}
+
+typedef struct libxl_map libxl_nodemap;
+static inline void libxl_nodemap_dispose(libxl_nodemap *nodemap)
+{
+    return libxl_map_dispose(nodemap);
+}
 
 typedef struct {
     /*
@@ -474,6 +486,9 @@ int libxl_domain_preserve(libxl_ctx *ctx
 /* get max. number of cpus supported by hypervisor */
 int libxl_get_max_cpus(libxl_ctx *ctx);
 
+/* get max. number of NUMA nodes supported by hypervisor */
+int libxl_get_max_nodes(libxl_ctx *ctx);
+
 /*
  * Run the configured bootloader for a PV domain and update
  * info->kernel, info->u.pv.ramdisk and info->u.pv.cmdline as
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -437,47 +437,53 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }
 
+void libxl_map_dispose(struct libxl_map *map)
+{
+    free(map->map);
+}
+
+static int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
+{
+    int sz;
+
+    sz = (n_elems + 7) / 8;
+    map->map = calloc(sz, sizeof(*map->map));
+    if (!map->map)
+        return ERROR_NOMEM;
+    map->size = sz;
+    return 0;
+}
+
+int libxl_map_test(struct libxl_map *map, int elem)
+{
+    if (elem >= map->size * 8)
+        return 0;
+    return (map->map[elem / 8] & (1 << (elem & 7))) ? 1 : 0;
+}
+
+void libxl_map_set(struct libxl_map *map, int elem)
+{
+    if (elem >= map->size * 8)
+        return;
+    map->map[elem / 8] |= 1 << (elem & 7);
+}
+
+void libxl_map_reset(struct libxl_map *map, int elem)
+{
+    if (elem >= map->size * 8)
+        return;
+    map->map[elem / 8] &= ~(1 << (elem & 7));
+}
+
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
 {
     int max_cpus;
-    int sz;
 
     max_cpus = libxl_get_max_cpus(ctx);
     if (max_cpus == 0)
         return ERROR_FAIL;
 
-    sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
-        return ERROR_NOMEM;
-    cpumap->size = sz;
-    return 0;
-}
-
-void libxl_cpumap_dispose(libxl_cpumap *map)
-{
-    free(map->map);
-}
-
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
-{
-    if (cpu >= cpumap->size * 8)
-        return 0;
-    return (cpumap->map[cpu / 8] & (1 << (cpu & 7))) ? 1 : 0;
-}
-
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu)
-{
-    if (cpu >= cpumap->size * 8)
-        return;
-    cpumap->map[cpu / 8] |= 1 << (cpu & 7);
-}
-
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu)
-{
-    if (cpu >= cpumap->size * 8)
-        return;
-    cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
+    return libxl_map_alloc(ctx, cpumap, max_cpus);
 }
 
 int libxl_get_max_cpus(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,21 +64,46 @@ int libxl_devid_to_device_nic(libxl_ctx 
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
+int libxl_map_test(struct libxl_map *map, int elem);
+void libxl_map_set(struct libxl_map *map, int elem);
+void libxl_map_reset(struct libxl_map *map, int elem);
+static inline void libxl_map_set_any(struct libxl_map *map)
+{
+    memset(map->map, -1, map->size);
+}
+static inline void libxl_map_set_none(struct libxl_map *map)
+{
+    memset(map->map, 0, map->size);
+}
+static inline int libxl_map_elem_valid(struct libxl_map *map, int elem)
+{
+    return elem >= 0 && elem < (map->size * 8);
+}
+
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+static inline int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
+{
+    return libxl_map_test(cpumap, cpu);
+}
+static inline void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu)
+{
+    libxl_map_set(cpumap, cpu);
+}
+static inline void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu)
+{
+    libxl_map_reset(cpumap, cpu);
+}
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
-    memset(cpumap->map, -1, cpumap->size);
+    libxl_map_set_any(cpumap);
 }
 static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
 {
-    memset(cpumap->map, 0, cpumap->size);
+    libxl_map_set_none(cpumap);
 }
 static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
 {
-    return cpu >= 0 && cpu < (cpumap->size * 8);
+    return libxl_map_elem_valid(cpumap, cpu);
 }
 #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
 #define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaR-0001j0-Oh; Wed, 11 Apr 2012 13:27:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaQ-0001ig-UY
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:51 +0000
Received: from [85.158.139.83:40137] by server-7.bemta-5.messagelabs.com id
	92/2C-16195-6D6858F4; Wed, 11 Apr 2012 13:27:50 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!3
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24167 invoked from network); 11 Apr 2012 13:27:49 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:49 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=DoOos6i0dzz5D67Z43YVC5dPyP8YVMeQDTFa2rdASE0=;
	b=loW37OcXqWywi3J9WsB5xH1BcYhzO7h3qhlowYHWFocwlaJFN8EbA16gXFgjBaw9Ww
	GPMldP6A2RtOyapbiQmQbavIHl1U6qD5KYaytUthAF0Vi3C8Vy/dMbJr+xF0YHmzj09p
	7FSnqh94ng1poQHPOO6mGzz0sOJmY/QO1ibV3GarENc44ZJcu3O05DQNKfHROjqZB1b6
	9dkXJ6vqDZQa3nX4mP6A5WxrfBjma/HfKnfHr1TFmt6b+PcPnMBKVfUXWt7qKL1AGSHD
	OkWyyYbDfbvKZLaaa7nlfVaWrFIMLKVi/3EXhxsOPf83m6Efvm8nN6YDPTOJKKlQQjA4
	tnTw==
Received: by 10.213.8.130 with SMTP id h2mr980676ebh.32.1334150868837;
	Wed, 11 Apr 2012 06:27:48 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.46
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:47 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 3edc8654216a9004331066bc8e7977e2935363a4
Message-Id: <3edc8654216a90043310.1334150269@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:49 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 02 of 10 [RFC]] libxl: Generalize libxl_cpumap
 to just libxl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for adding a libxl_nodemap and its related
hadling logic. No changes to the interface this time.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -277,11 +277,23 @@ typedef uint32_t libxl_hwcap[8];
 
 typedef uint64_t libxl_ev_user;
 
-typedef struct {
+struct libxl_map {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
-} libxl_cpumap;
-void libxl_cpumap_dispose(libxl_cpumap *map);
+};
+void libxl_map_dispose(struct libxl_map *map);
+
+typedef struct libxl_map libxl_cpumap;
+static inline void libxl_cpumap_dispose(libxl_cpumap *cpumap)
+{
+    return libxl_map_dispose(cpumap);
+}
+
+typedef struct libxl_map libxl_nodemap;
+static inline void libxl_nodemap_dispose(libxl_nodemap *nodemap)
+{
+    return libxl_map_dispose(nodemap);
+}
 
 typedef struct {
     /*
@@ -474,6 +486,9 @@ int libxl_domain_preserve(libxl_ctx *ctx
 /* get max. number of cpus supported by hypervisor */
 int libxl_get_max_cpus(libxl_ctx *ctx);
 
+/* get max. number of NUMA nodes supported by hypervisor */
+int libxl_get_max_nodes(libxl_ctx *ctx);
+
 /*
  * Run the configured bootloader for a PV domain and update
  * info->kernel, info->u.pv.ramdisk and info->u.pv.cmdline as
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -437,47 +437,53 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }
 
+void libxl_map_dispose(struct libxl_map *map)
+{
+    free(map->map);
+}
+
+static int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
+{
+    int sz;
+
+    sz = (n_elems + 7) / 8;
+    map->map = calloc(sz, sizeof(*map->map));
+    if (!map->map)
+        return ERROR_NOMEM;
+    map->size = sz;
+    return 0;
+}
+
+int libxl_map_test(struct libxl_map *map, int elem)
+{
+    if (elem >= map->size * 8)
+        return 0;
+    return (map->map[elem / 8] & (1 << (elem & 7))) ? 1 : 0;
+}
+
+void libxl_map_set(struct libxl_map *map, int elem)
+{
+    if (elem >= map->size * 8)
+        return;
+    map->map[elem / 8] |= 1 << (elem & 7);
+}
+
+void libxl_map_reset(struct libxl_map *map, int elem)
+{
+    if (elem >= map->size * 8)
+        return;
+    map->map[elem / 8] &= ~(1 << (elem & 7));
+}
+
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
 {
     int max_cpus;
-    int sz;
 
     max_cpus = libxl_get_max_cpus(ctx);
     if (max_cpus == 0)
         return ERROR_FAIL;
 
-    sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
-        return ERROR_NOMEM;
-    cpumap->size = sz;
-    return 0;
-}
-
-void libxl_cpumap_dispose(libxl_cpumap *map)
-{
-    free(map->map);
-}
-
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
-{
-    if (cpu >= cpumap->size * 8)
-        return 0;
-    return (cpumap->map[cpu / 8] & (1 << (cpu & 7))) ? 1 : 0;
-}
-
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu)
-{
-    if (cpu >= cpumap->size * 8)
-        return;
-    cpumap->map[cpu / 8] |= 1 << (cpu & 7);
-}
-
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu)
-{
-    if (cpu >= cpumap->size * 8)
-        return;
-    cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
+    return libxl_map_alloc(ctx, cpumap, max_cpus);
 }
 
 int libxl_get_max_cpus(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,21 +64,46 @@ int libxl_devid_to_device_nic(libxl_ctx 
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
+int libxl_map_test(struct libxl_map *map, int elem);
+void libxl_map_set(struct libxl_map *map, int elem);
+void libxl_map_reset(struct libxl_map *map, int elem);
+static inline void libxl_map_set_any(struct libxl_map *map)
+{
+    memset(map->map, -1, map->size);
+}
+static inline void libxl_map_set_none(struct libxl_map *map)
+{
+    memset(map->map, 0, map->size);
+}
+static inline int libxl_map_elem_valid(struct libxl_map *map, int elem)
+{
+    return elem >= 0 && elem < (map->size * 8);
+}
+
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+static inline int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
+{
+    return libxl_map_test(cpumap, cpu);
+}
+static inline void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu)
+{
+    libxl_map_set(cpumap, cpu);
+}
+static inline void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu)
+{
+    libxl_map_reset(cpumap, cpu);
+}
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
-    memset(cpumap->map, -1, cpumap->size);
+    libxl_map_set_any(cpumap);
 }
 static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
 {
-    memset(cpumap->map, 0, cpumap->size);
+    libxl_map_set_none(cpumap);
 }
 static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
 {
-    return cpu >= 0 && cpu < (cpumap->size * 8);
+    return libxl_map_elem_valid(cpumap, cpu);
 }
 #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
 #define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaU-0001jb-5i; Wed, 11 Apr 2012 13:27:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaT-0001ig-24
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:53 +0000
Received: from [85.158.139.83:2934] by server-7.bemta-5.messagelabs.com id
	29/3C-16195-8D6858F4; Wed, 11 Apr 2012 13:27:52 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!4
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24298 invoked from network); 11 Apr 2012 13:27:51 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:51 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=7D+Bt/95GAGaPaNKXFpqzhBO2YJdnTUTrIHp2mYBGPc=;
	b=lpwWtGSb/3YYw0lowl3euYRXjEuYgEJXu4c9bvsTggh+eDMWF5ohKPX1p7ycie5bAX
	PTKaaF2Egm487fLq2ayHByDpvEKMif8kJ7e5uely5gurVugZAOt7fhgH+/MDIqmjJ2zT
	e0lQspgUxic3Hd9GchqMzenVWTAKED7UEGAipAuGf8dI7y/e/ROLWsj7Hv500MbaRO6s
	vMaxEQpO0Ikv92jffvfFLejY3TOEsuOxhApkmi3w8khUn9L31eFdfjr3Ztt3gex/S6LE
	WoHZZVaLJN66QxXB2HWo9HjspF/zjyO0mpcPXexY1EfHrtCNrmobF7RKR+jsA1BOc8px
	UzqA==
Received: by 10.14.29.13 with SMTP id h13mr1931654eea.48.1334150871328;
	Wed, 11 Apr 2012 06:27:51 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:50 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2077d51764e0ff1e33a9a37e1ec65b136daded6e
Message-Id: <2077d51764e0ff1e33a9.1334150270@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:50 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 03 of 10 [RFC]] libxc,
 libxl: Introduce xc_nodemap_t and libxl_nodemap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Exactly as we have xc_cpumap_t, something similar for representing
NUMA nodes (i.e., xc_nodemap_t and nodemap_t) could be useful. The
same applies to libxl_cpumap, which on its turn now has its
node-related counterpart, libxl_nodemap.

This is all in preparation for making it possible explicit
specification of the `node affinity` of a guest.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -35,21 +35,49 @@ int xc_get_max_cpus(xc_interface *xch)
     return max_cpus;
 }
 
+int xc_get_max_nodes(xc_interface *xch)
+{
+    static int max_nodes = 0;
+    xc_physinfo_t physinfo;
+
+    if ( max_nodes )
+        return max_nodes;
+
+    if ( !xc_physinfo(xch, &physinfo) )
+        max_nodes = physinfo.max_node_id + 1;
+
+    return max_nodes;
+}
+
 int xc_get_cpumap_size(xc_interface *xch)
 {
     return (xc_get_max_cpus(xch) + 7) / 8;
 }
 
-xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
+int xc_get_nodemap_size(xc_interface *xch)
 {
-    int sz;
+    return (xc_get_max_nodes(xch) + 7) / 8;
+}
 
-    sz = xc_get_cpumap_size(xch);
+/* XXX See [*] below ... */
+static xc_cpumap_t __xc_map_alloc(xc_interface *xch, int sz)
+{
     if (sz == 0)
         return NULL;
     return calloc(1, sz);
 }
 
+xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
+{
+    return __xc_map_alloc(xch, xc_get_cpumap_size(xch));
+}
+
+xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
+{
+    /* XXX [*] How bad is this? Ideas? */
+    return (xc_nodemap_t) __xc_map_alloc(xch, xc_get_nodemap_size(xch));
+}
+
 int xc_readconsolering(xc_interface *xch,
                        char *buffer,
                        unsigned int *pnr_chars,
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -330,6 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
 
 /*
+ * NODEMAP handling
+ */
+typedef uint8_t *xc_nodemap_t;
+
+/* return maximum number of NUMA nodes the hypervisor supports */
+int xc_get_max_nodes(xc_interface *xch);
+
+/* return array size for nodemap */
+int xc_get_nodemap_size(xc_interface *xch);
+
+/* allocate a nodemap */
+xc_nodemap_t xc_nodemap_alloc(xc_interface *xch);
+
+/*
  * DOMAIN DEBUGGING FUNCTIONS
  */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -486,11 +486,27 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
     return libxl_map_alloc(ctx, cpumap, max_cpus);
 }
 
+int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap)
+{
+    int max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+        return ERROR_FAIL;
+
+    return libxl_map_alloc(ctx, nodemap, max_nodes);
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
 }
 
+int libxl_get_max_nodes(libxl_ctx *ctx)
+{
+    return xc_get_max_nodes(ctx->xch);
+}
+
 int libxl__enum_from_string(const libxl_enum_string_table *t,
                             const char *s, int *e)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -109,6 +109,35 @@ static inline int libxl_cpumap_cpu_valid
 #define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \
                                              if (libxl_cpumap_test(&(m), v))
 
+int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap);
+static inline int libxl_nodemap_test(libxl_nodemap *nodemap, int node)
+{
+    return libxl_map_test(nodemap, node);
+}
+static inline void libxl_nodemap_set(libxl_nodemap *nodemap, int node)
+{
+    libxl_map_set(nodemap, node);
+}
+static inline void libxl_nodemap_reset(libxl_nodemap *nodemap, int node)
+{
+    libxl_map_reset(nodemap, node);
+}
+static inline void libxl_nodemap_set_any(libxl_nodemap *nodemap)
+{
+    libxl_map_set_any(nodemap);
+}
+static inline void libxl_nodemap_set_none(libxl_nodemap *nodemap)
+{
+    libxl_map_set_none(nodemap);
+}
+static inline int libxl_nodemap_node_valid(libxl_nodemap *nodemap, int node)
+{
+    return libxl_map_elem_valid(nodemap, node);
+}
+#define libxl_for_each_node(var, map) for (var = 0; var < (map).size * 8; var++)
+#define libxl_for_each_set_node(v, m) for (v = 0; v < (m).size * 8; v++) \
+                                              if (libxl_nodemap_test(&(m), v))
+
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
 }
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -116,6 +116,14 @@ int xenctl_cpumap_to_cpumask(cpumask_var
     return err;
 }
 
+int xenctl_nodemap_to_nodemask(nodemask_t *nodemask,
+                               const struct xenctl_map *xenctl_nodemap)
+{
+    return xenctl_map_to_bitmap(nodes_addr(*nodemask),
+                                xenctl_nodemap,
+                                MAX_NUMNODES);
+}
+
 static inline int is_free_domid(domid_t dom)
 {
     struct domain *d;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaU-0001jb-5i; Wed, 11 Apr 2012 13:27:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaT-0001ig-24
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:53 +0000
Received: from [85.158.139.83:2934] by server-7.bemta-5.messagelabs.com id
	29/3C-16195-8D6858F4; Wed, 11 Apr 2012 13:27:52 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!4
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24298 invoked from network); 11 Apr 2012 13:27:51 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:51 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=7D+Bt/95GAGaPaNKXFpqzhBO2YJdnTUTrIHp2mYBGPc=;
	b=lpwWtGSb/3YYw0lowl3euYRXjEuYgEJXu4c9bvsTggh+eDMWF5ohKPX1p7ycie5bAX
	PTKaaF2Egm487fLq2ayHByDpvEKMif8kJ7e5uely5gurVugZAOt7fhgH+/MDIqmjJ2zT
	e0lQspgUxic3Hd9GchqMzenVWTAKED7UEGAipAuGf8dI7y/e/ROLWsj7Hv500MbaRO6s
	vMaxEQpO0Ikv92jffvfFLejY3TOEsuOxhApkmi3w8khUn9L31eFdfjr3Ztt3gex/S6LE
	WoHZZVaLJN66QxXB2HWo9HjspF/zjyO0mpcPXexY1EfHrtCNrmobF7RKR+jsA1BOc8px
	UzqA==
Received: by 10.14.29.13 with SMTP id h13mr1931654eea.48.1334150871328;
	Wed, 11 Apr 2012 06:27:51 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:50 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2077d51764e0ff1e33a9a37e1ec65b136daded6e
Message-Id: <2077d51764e0ff1e33a9.1334150270@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:50 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 03 of 10 [RFC]] libxc,
 libxl: Introduce xc_nodemap_t and libxl_nodemap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Exactly as we have xc_cpumap_t, something similar for representing
NUMA nodes (i.e., xc_nodemap_t and nodemap_t) could be useful. The
same applies to libxl_cpumap, which on its turn now has its
node-related counterpart, libxl_nodemap.

This is all in preparation for making it possible explicit
specification of the `node affinity` of a guest.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -35,21 +35,49 @@ int xc_get_max_cpus(xc_interface *xch)
     return max_cpus;
 }
 
+int xc_get_max_nodes(xc_interface *xch)
+{
+    static int max_nodes = 0;
+    xc_physinfo_t physinfo;
+
+    if ( max_nodes )
+        return max_nodes;
+
+    if ( !xc_physinfo(xch, &physinfo) )
+        max_nodes = physinfo.max_node_id + 1;
+
+    return max_nodes;
+}
+
 int xc_get_cpumap_size(xc_interface *xch)
 {
     return (xc_get_max_cpus(xch) + 7) / 8;
 }
 
-xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
+int xc_get_nodemap_size(xc_interface *xch)
 {
-    int sz;
+    return (xc_get_max_nodes(xch) + 7) / 8;
+}
 
-    sz = xc_get_cpumap_size(xch);
+/* XXX See [*] below ... */
+static xc_cpumap_t __xc_map_alloc(xc_interface *xch, int sz)
+{
     if (sz == 0)
         return NULL;
     return calloc(1, sz);
 }
 
+xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
+{
+    return __xc_map_alloc(xch, xc_get_cpumap_size(xch));
+}
+
+xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
+{
+    /* XXX [*] How bad is this? Ideas? */
+    return (xc_nodemap_t) __xc_map_alloc(xch, xc_get_nodemap_size(xch));
+}
+
 int xc_readconsolering(xc_interface *xch,
                        char *buffer,
                        unsigned int *pnr_chars,
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -330,6 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
 
 /*
+ * NODEMAP handling
+ */
+typedef uint8_t *xc_nodemap_t;
+
+/* return maximum number of NUMA nodes the hypervisor supports */
+int xc_get_max_nodes(xc_interface *xch);
+
+/* return array size for nodemap */
+int xc_get_nodemap_size(xc_interface *xch);
+
+/* allocate a nodemap */
+xc_nodemap_t xc_nodemap_alloc(xc_interface *xch);
+
+/*
  * DOMAIN DEBUGGING FUNCTIONS
  */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -486,11 +486,27 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
     return libxl_map_alloc(ctx, cpumap, max_cpus);
 }
 
+int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap)
+{
+    int max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+        return ERROR_FAIL;
+
+    return libxl_map_alloc(ctx, nodemap, max_nodes);
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
 }
 
+int libxl_get_max_nodes(libxl_ctx *ctx)
+{
+    return xc_get_max_nodes(ctx->xch);
+}
+
 int libxl__enum_from_string(const libxl_enum_string_table *t,
                             const char *s, int *e)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -109,6 +109,35 @@ static inline int libxl_cpumap_cpu_valid
 #define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \
                                              if (libxl_cpumap_test(&(m), v))
 
+int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap);
+static inline int libxl_nodemap_test(libxl_nodemap *nodemap, int node)
+{
+    return libxl_map_test(nodemap, node);
+}
+static inline void libxl_nodemap_set(libxl_nodemap *nodemap, int node)
+{
+    libxl_map_set(nodemap, node);
+}
+static inline void libxl_nodemap_reset(libxl_nodemap *nodemap, int node)
+{
+    libxl_map_reset(nodemap, node);
+}
+static inline void libxl_nodemap_set_any(libxl_nodemap *nodemap)
+{
+    libxl_map_set_any(nodemap);
+}
+static inline void libxl_nodemap_set_none(libxl_nodemap *nodemap)
+{
+    libxl_map_set_none(nodemap);
+}
+static inline int libxl_nodemap_node_valid(libxl_nodemap *nodemap, int node)
+{
+    return libxl_map_elem_valid(nodemap, node);
+}
+#define libxl_for_each_node(var, map) for (var = 0; var < (map).size * 8; var++)
+#define libxl_for_each_set_node(v, m) for (v = 0; v < (m).size * 8; v++) \
+                                              if (libxl_nodemap_test(&(m), v))
+
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
 }
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -116,6 +116,14 @@ int xenctl_cpumap_to_cpumask(cpumask_var
     return err;
 }
 
+int xenctl_nodemap_to_nodemask(nodemask_t *nodemask,
+                               const struct xenctl_map *xenctl_nodemap)
+{
+    return xenctl_map_to_bitmap(nodes_addr(*nodemask),
+                                xenctl_nodemap,
+                                MAX_NUMNODES);
+}
+
 static inline int is_free_domid(domid_t dom)
 {
     struct domain *d;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaY-0001lJ-PH; Wed, 11 Apr 2012 13:27:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaW-0001kR-Hc
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:56 +0000
Received: from [85.158.143.35:2357] by server-1.bemta-4.messagelabs.com id
	C2/0F-20925-BD6858F4; Wed, 11 Apr 2012 13:27:55 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28311 invoked from network); 11 Apr 2012 13:27:54 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:54 -0000
Received: by eaaf11 with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=KQCp5W747hqGXDqWgVg+dFvFZdhkCyM5P/RUotaNNG4=;
	b=RV5x/j7uswaegLzkgfUekTyfBqQdcxvsWLQjBJRIWRNXoa8pI1GlfIhFE0Rqix/KfA
	HzJKmqsXxpMAXICIdHafxCRu0cHgp9pq5gFpd8l3Yc/LZP5gFXSjR842oDNtQreJ+PTJ
	cchInm2YFrEkzQxee8lqbIRTyDMCZMnSl9+5JFfvAjS8IQ12+oNvq0IKD2a3VJtX7CKs
	CCl/d981Y8TeGe5bU6Qa09caOgKlMthUb7Lx29sYUMhsChspTrheCqzshTsBz+Ys/0cn
	LLjkds3zI+DWZL9aI7ErZTlMW14PkQftL4uyWIRmLJAZxUof5LrR0bSsWGkc9vVSFgGq
	GWWw==
Received: by 10.14.133.10 with SMTP id p10mr1974738eei.36.1334150873929;
	Wed, 11 Apr 2012 06:27:53 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:52 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 25844ab11bcace4163b901b7373f98a0beeb29f8
Message-Id: <25844ab11bcace4163b9.1334150271@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:51 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 04 of 10 [RFC]] libxl: Introduce
 libxl_get_numainfo() calling xc_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xc_numainfo is already there, and it provides information about
things like free memory on each NUMA node and `distances` among
the various nodes. In preparation of putting an automatic
domain-on-nodes placement logic --which will benefit a lot from
having such information available-- make it possible to retrieve
them within libxl by a new libxl_get_numainfo() API call (very
similar to libxl_get_topologyinfo).

TODO: * Enable exporting node distances as soon as we figure out
        how to stick an array in an IDL defined type (patches
        have been posted, will rebase onto them if it'll turn
        out to be the case.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2830,6 +2830,83 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
+{
+    xc_numainfo_t ninfo;
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memsize_t, memsize);
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memfree_t, memfree);
+    DECLARE_HYPERCALL_BUFFER(uint32_t, node_distances);
+    libxl_numainfo *ret = NULL;
+    int i, max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of NODES");
+        return NULL;
+    }
+
+    memsize = xc_hypercall_buffer_alloc
+        (ctx->xch, memsize, sizeof(*memsize) * max_nodes);
+    memfree = xc_hypercall_buffer_alloc
+        (ctx->xch, memfree, sizeof(*memfree) * max_nodes);
+    node_distances = xc_hypercall_buffer_alloc
+        (ctx->xch, node_distances, sizeof(*node_distances) * max_nodes * max_nodes);
+    if ((memsize == NULL) || (memfree == NULL) || (node_distances == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
+        goto fail;
+    }
+
+    set_xen_guest_handle(ninfo.node_to_memsize, memsize);
+    set_xen_guest_handle(ninfo.node_to_memfree, memfree);
+    set_xen_guest_handle(ninfo.node_to_node_distance, node_distances);
+    ninfo.max_node_index = max_nodes - 1;
+    if (xc_numainfo(ctx->xch, &ninfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting numainfo");
+        goto fail;
+    }
+
+    ret = malloc(sizeof(libxl_numainfo) * max_nodes);
+    if (ret == NULL) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate return value");
+        goto fail;
+    }
+    /* XXX Neglect node distances for now, as we need some sort of array
+     *     type support in the IDL. RFC patches for that have been posted,
+     *     will rebase on top of those for next round if it is the case.
+     *
+     * for (i = 0; i < max_nodes; i++) {
+     *     ret[i].distances = malloc(sizeof(*node_distances) * max_nodes);
+     *     if (ret == NULL) {
+     *         for (int j = i; j >=0; j--)
+     *             free(ret[i].distances);
+     *         free(ret);
+     *         goto fail;
+     *     }
+     * }
+     */
+
+    for (i = 0; i < max_nodes; i++) {
+        ret[i].size = memsize[i];
+        ret[i].free = memfree[i];
+        /* for (int j = 0; j < max_nodes; j++)
+         *    ret[i].distances[j] =
+         *        node_distances[i*(max_nodes+1) + j];
+         */
+    }
+
+fail:
+    xc_hypercall_buffer_free(ctx->xch, memsize);
+    xc_hypercall_buffer_free(ctx->xch, memfree);
+    xc_hypercall_buffer_free(ctx->xch, node_distances);
+
+    if (ret)
+        *nr = max_nodes;
+    return ret;
+}
+
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
     xc_topologyinfo_t tinfo;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -716,6 +716,8 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
+void libxl_numainfo_list_free(libxl_numainfo *, int nr);
 #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
 void libxl_cputopology_list_free(libxl_cputopology *, int nr);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -411,6 +411,12 @@ libxl_physinfo = Struct("physinfo", [
     ("cap_hvm_directio", bool),
     ], dir=DIR_OUT)
 
+libxl_numainfo = Struct("numainfo", [
+    ("size", uint64),
+    ("free", uint64),
+    ("distances", uint32),
+    ], dir=DIR_OUT)
+
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
     ("socket", uint32),
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -521,6 +521,14 @@ int libxl__enum_from_string(const libxl_
     return ERROR_FAIL;
 }
 
+void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_numainfo_dispose(&list[i]);
+    free(list);
+}
+
 void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
 {
     int i;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaY-0001lJ-PH; Wed, 11 Apr 2012 13:27:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaW-0001kR-Hc
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:27:56 +0000
Received: from [85.158.143.35:2357] by server-1.bemta-4.messagelabs.com id
	C2/0F-20925-BD6858F4; Wed, 11 Apr 2012 13:27:55 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28311 invoked from network); 11 Apr 2012 13:27:54 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:54 -0000
Received: by eaaf11 with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=KQCp5W747hqGXDqWgVg+dFvFZdhkCyM5P/RUotaNNG4=;
	b=RV5x/j7uswaegLzkgfUekTyfBqQdcxvsWLQjBJRIWRNXoa8pI1GlfIhFE0Rqix/KfA
	HzJKmqsXxpMAXICIdHafxCRu0cHgp9pq5gFpd8l3Yc/LZP5gFXSjR842oDNtQreJ+PTJ
	cchInm2YFrEkzQxee8lqbIRTyDMCZMnSl9+5JFfvAjS8IQ12+oNvq0IKD2a3VJtX7CKs
	CCl/d981Y8TeGe5bU6Qa09caOgKlMthUb7Lx29sYUMhsChspTrheCqzshTsBz+Ys/0cn
	LLjkds3zI+DWZL9aI7ErZTlMW14PkQftL4uyWIRmLJAZxUof5LrR0bSsWGkc9vVSFgGq
	GWWw==
Received: by 10.14.133.10 with SMTP id p10mr1974738eei.36.1334150873929;
	Wed, 11 Apr 2012 06:27:53 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:52 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 25844ab11bcace4163b901b7373f98a0beeb29f8
Message-Id: <25844ab11bcace4163b9.1334150271@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:51 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 04 of 10 [RFC]] libxl: Introduce
 libxl_get_numainfo() calling xc_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xc_numainfo is already there, and it provides information about
things like free memory on each NUMA node and `distances` among
the various nodes. In preparation of putting an automatic
domain-on-nodes placement logic --which will benefit a lot from
having such information available-- make it possible to retrieve
them within libxl by a new libxl_get_numainfo() API call (very
similar to libxl_get_topologyinfo).

TODO: * Enable exporting node distances as soon as we figure out
        how to stick an array in an IDL defined type (patches
        have been posted, will rebase onto them if it'll turn
        out to be the case.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2830,6 +2830,83 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
+{
+    xc_numainfo_t ninfo;
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memsize_t, memsize);
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memfree_t, memfree);
+    DECLARE_HYPERCALL_BUFFER(uint32_t, node_distances);
+    libxl_numainfo *ret = NULL;
+    int i, max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of NODES");
+        return NULL;
+    }
+
+    memsize = xc_hypercall_buffer_alloc
+        (ctx->xch, memsize, sizeof(*memsize) * max_nodes);
+    memfree = xc_hypercall_buffer_alloc
+        (ctx->xch, memfree, sizeof(*memfree) * max_nodes);
+    node_distances = xc_hypercall_buffer_alloc
+        (ctx->xch, node_distances, sizeof(*node_distances) * max_nodes * max_nodes);
+    if ((memsize == NULL) || (memfree == NULL) || (node_distances == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
+        goto fail;
+    }
+
+    set_xen_guest_handle(ninfo.node_to_memsize, memsize);
+    set_xen_guest_handle(ninfo.node_to_memfree, memfree);
+    set_xen_guest_handle(ninfo.node_to_node_distance, node_distances);
+    ninfo.max_node_index = max_nodes - 1;
+    if (xc_numainfo(ctx->xch, &ninfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting numainfo");
+        goto fail;
+    }
+
+    ret = malloc(sizeof(libxl_numainfo) * max_nodes);
+    if (ret == NULL) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate return value");
+        goto fail;
+    }
+    /* XXX Neglect node distances for now, as we need some sort of array
+     *     type support in the IDL. RFC patches for that have been posted,
+     *     will rebase on top of those for next round if it is the case.
+     *
+     * for (i = 0; i < max_nodes; i++) {
+     *     ret[i].distances = malloc(sizeof(*node_distances) * max_nodes);
+     *     if (ret == NULL) {
+     *         for (int j = i; j >=0; j--)
+     *             free(ret[i].distances);
+     *         free(ret);
+     *         goto fail;
+     *     }
+     * }
+     */
+
+    for (i = 0; i < max_nodes; i++) {
+        ret[i].size = memsize[i];
+        ret[i].free = memfree[i];
+        /* for (int j = 0; j < max_nodes; j++)
+         *    ret[i].distances[j] =
+         *        node_distances[i*(max_nodes+1) + j];
+         */
+    }
+
+fail:
+    xc_hypercall_buffer_free(ctx->xch, memsize);
+    xc_hypercall_buffer_free(ctx->xch, memfree);
+    xc_hypercall_buffer_free(ctx->xch, node_distances);
+
+    if (ret)
+        *nr = max_nodes;
+    return ret;
+}
+
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
     xc_topologyinfo_t tinfo;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -716,6 +716,8 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
+void libxl_numainfo_list_free(libxl_numainfo *, int nr);
 #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
 void libxl_cputopology_list_free(libxl_cputopology *, int nr);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -411,6 +411,12 @@ libxl_physinfo = Struct("physinfo", [
     ("cap_hvm_directio", bool),
     ], dir=DIR_OUT)
 
+libxl_numainfo = Struct("numainfo", [
+    ("size", uint64),
+    ("free", uint64),
+    ("distances", uint32),
+    ], dir=DIR_OUT)
+
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
     ("socket", uint32),
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -521,6 +521,14 @@ int libxl__enum_from_string(const libxl_
     return ERROR_FAIL;
 }
 
+void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_numainfo_dispose(&list[i]);
+    free(list);
+}
+
 void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
 {
     int i;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxab-0001mo-5n; Wed, 11 Apr 2012 13:28:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaZ-0001lX-IF
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:00 +0000
Received: from [85.158.139.83:40979] by server-9.bemta-5.messagelabs.com id
	FC/AC-09826-ED6858F4; Wed, 11 Apr 2012 13:27:58 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!5
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24675 invoked from network); 11 Apr 2012 13:27:56 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:56 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=KiojuhQqN3lMFJorayAwH5RePoSw/MXJgrHDKR/2q7I=;
	b=XECNyi4smQRzE+7wOC9jAHraytZTMaXch5Dz8Qy4fC/eG/OpO1G9Q6Dq+XKNsqIwDg
	fdTvZdd2hFiEuOV7M7TYRkA9CrvAfkUPTUu6ty8Xuqd4X7i3+FIuJB1OZBGCyEUnu0pN
	Y8jO5ob/2tIe+M7U2iRYyVfzcf3eTUYV2MDxr9UBO0llatoCj047E/52cqjTBKl/34Fk
	PKGOyjIfQvA8MTzebqdQw1qhtK+gunvfgarMi5WN4P+8MxicvZbcY8+B8SjlKWB6VoBU
	Z6DFcSWaDmzit+uD+qnz/QPVy0JptQ/vAsIhKNoLTfTBd3/ELOt5fHMWkl8wkkbTaWuL
	WklQ==
Received: by 10.14.100.71 with SMTP id y47mr2009693eef.9.1334150876583;
	Wed, 11 Apr 2012 06:27:56 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 7e76233448b02810f0ae473cb651215fb82dc1f9
Message-Id: <7e76233448b02810f0ae.1334150272@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:52 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Let the user specify the NUMA node affinity of a guest via the
'nodes=' config switch. Explicitly listing the intended target host
nodes is required as of now.

A valid setting will directly impact the node_affinity mask
of the guest, i.e., it will change the behaviour of the low level
memory allocator. On the other hand, this commit does not affect
by any means how the guest's vCPUs are scheduled on the host's
pCPUs.

TODO: * Better investigate and test interactions with cpupools.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,15 @@ List of which cpus the guest is allowed 
 (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
 
+=item B<nodes=[ NODE, NODE, ...]>
+
+List of the NUMA nodes of the host the guest should be considered
+`affine` with. Being affine to a (set of) NUMA node(s) mainly means
+the guest's memory is going to be allocated on those node(s).
+
+A list of nodes should be specified as follows: `nodes=["0", "3"]`
+for the guest to be affine with nodes 0 and 3.
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -110,6 +110,44 @@ int xc_domain_shutdown(xc_interface *xch
 }
 
 
+int xc_domain_node_affinity(xc_interface *xch,
+                            uint32_t domid,
+                            xc_nodemap_t node_affinity)
+{
+    DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BUFFER(uint8_t, local);
+    int ret = -1;
+    int nodesize;
+
+    nodesize = xc_get_nodemap_size(xch);
+    if (!nodesize)
+    {
+        PERROR("Could not get number of nodes");
+        goto out;
+    }
+
+    local = xc_hypercall_buffer_alloc(xch, local, nodesize);
+    if ( local == NULL )
+    {
+        PERROR("Could not allocate memory for domain_node_affinity domctl hypercall");
+        goto out;
+    }
+
+    domctl.cmd = XEN_DOMCTL_node_affinity;
+    domctl.domain = (domid_t)domid;
+
+    memcpy(local, node_affinity, nodesize);
+    set_xen_guest_handle(domctl.u.node_affinity.nodemap.bitmap, local);
+    domctl.u.node_affinity.nodemap.nr_elems = nodesize * 8;
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_buffer_free(xch, local);
+
+ out:
+    return ret;
+}
+
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -520,6 +520,19 @@ int xc_watchdog(xc_interface *xch,
 		uint32_t id,
 		uint32_t timeout);
 
+/**
+ * This function explicitly sets the affinity of a domain with the
+ * host NUMA nodes.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id in which vcpus are to be created.
+ * @parm node_affinity the map of the affine nodes.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_domain_node_affinity(xc_interface *xch,
+                            uint32_t domind,
+                            xc_nodemap_t node_affinity);
+
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,
diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -20,7 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_nodemap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
@@ -119,6 +119,19 @@ static void libxl_cpumap_rand_init(libxl
     }
 }
 
+static void libxl_nodemap_rand_init(libxl_nodemap *nodemap)
+{
+    int i;
+    nodemap->size = rand() % 16;
+    nodemap->map = calloc(nodemap->size, sizeof(*nodemap->map));
+    libxl_for_each_node(i, *nodemap) {
+        if (rand() % 2)
+            libxl_nodemap_set(nodemap, i);
+        else
+            libxl_nodemap_reset(nodemap, i);
+    }
+}
+
 static void libxl_key_value_list_rand_init(libxl_key_value_list *pkvl)
 {
     int i, nr_kvp = rand() % 16;
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3082,6 +3082,16 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
     return rc;
 }
 
+int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
+                            libxl_nodemap *nodemap)
+{
+    if (xc_domain_node_affinity(ctx->xch, domid, nodemap->map)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -727,6 +727,8 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
                            libxl_cpumap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
                                unsigned int max_vcpus, libxl_cpumap *cpumap);
+int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
+                            libxl_nodemap *nodemap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
 
 libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -121,6 +121,12 @@ int libxl__domain_build_info_setdefault(
         libxl_cpumap_set_any(&b_info->cpumap);
     }
 
+    if (!b_info->nodemap.size) {
+        if (libxl_nodemap_alloc(CTX, &b_info->nodemap))
+            return ERROR_NOMEM;
+        libxl_nodemap_set_none(&b_info->nodemap);
+    }
+
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->max_memkb = 32 * 1024;
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -67,6 +67,7 @@ int libxl__build_pre(libxl__gc *gc, uint
     char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
+    libxl_set_node_affinity(ctx, domid, &info->nodemap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -119,6 +119,26 @@ out:
     return s;
 }
 
+yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand,
+                                       libxl_nodemap *nodemap)
+{
+    yajl_gen_status s;
+    int i;
+
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    libxl_for_each_node(i, *nodemap) {
+        if (libxl_nodemap_test(nodemap, i)) {
+            s = yajl_gen_integer(hand, i);
+            if (s != yajl_gen_status_ok) goto out;
+        }
+    }
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
                                               libxl_key_value_list *pkvl)
 {
diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -27,6 +27,7 @@ yajl_gen_status libxl_domid_gen_json(yaj
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
 yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
 yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand, libxl_nodemap *p);
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                                  libxl_cpuid_policy_list *p);
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -11,6 +11,7 @@ libxl_domid = Builtin("domid", json_fn =
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
 libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
+libxl_nodemap = Builtin("nodemap", dispose_fn="libxl_nodemap_dispose", passby=PASS_BY_REFERENCE)
 libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
 
 libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
@@ -233,6 +234,7 @@ libxl_domain_build_info = Struct("domain
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
     ("cpumap",          libxl_cpumap),
+    ("nodemap",         libxl_nodemap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -515,7 +515,7 @@ static void parse_config_data(const char
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *nodes, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
     int pci_permissive = 0;
@@ -628,6 +628,39 @@ static void parse_config_data(const char
         free(buf2);
     }
 
+    if (!xlu_cfg_get_list (config, "nodes", &nodes, 0, 0)) {
+        int i, n_nodes = 0;
+
+        if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+            fprintf(stderr, "Unable to allocate nodemap\n");
+            exit(1);
+        }
+
+        libxl_nodemap_set_none(&b_info->nodemap);
+        while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
+            i = atoi(buf);
+            if (!libxl_nodemap_node_valid(&b_info->nodemap, i)) {
+                fprintf(stderr, "node %d illegal\n", i);
+                exit(1);
+            }
+            libxl_nodemap_set(&b_info->nodemap, i);
+            n_nodes++;
+        }
+
+        if (n_nodes == 0)
+            fprintf(stderr, "No valid node found: no affinity will be set\n");
+    }
+    else {
+        /*
+         * XXX What would a sane default be? I think doing nothing
+         *     (i.e., relying on cpu-affinity/cpupool ==> the current
+         *     behavior) should be just fine.
+         *     That would mean we're saying to the user "if you want us
+         *     to take care of NUMA, please tell us, maybe just putting
+         *     'nodes=auto', but tell us... otherwise we do as usual".
+         */
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -243,6 +243,18 @@ int attrib__libxl_cpumap_set(PyObject *v
     return 0;
 }
 
+int attrib__libxl_nodemap_set(PyObject *v, libxl_nodemap *pptr)
+{
+    int i;
+    long node;
+
+    for (i = 0; i < PyList_Size(v); i++) {
+        node = PyInt_AsLong(PyList_GetItem(v, i));
+        libxl_nodemap_set(pptr, node);
+    }
+    return 0;
+}
+
 int attrib__libxl_file_reference_set(PyObject *v, libxl_file_reference *pptr)
 {
     return genwrap__string_set(v, &pptr->path);
diff --git a/xen/common/domain.c b/xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -222,6 +222,7 @@ struct domain *domain_create(
 
     spin_lock_init(&d->node_affinity_lock);
     d->node_affinity = NODE_MASK_ALL;
+    d->has_node_affinity = 0;
 
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
@@ -337,7 +338,7 @@ void domain_update_node_affinity(struct 
 {
     cpumask_var_t cpumask;
     cpumask_var_t online_affinity;
-    const cpumask_t *online;
+    const cpumask_t *online = cpupool_online_cpumask(d->cpupool);
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
@@ -350,9 +351,22 @@ void domain_update_node_affinity(struct 
         return;
     }
 
-    online = cpupool_online_cpumask(d->cpupool);
+    spin_lock(&d->node_affinity_lock);
 
-    spin_lock(&d->node_affinity_lock);
+    /*
+     * If someone explicitly told us our NUMA affinity, avoid messing
+     * that up. Notice, however, that vcpu affinity is still what
+     * drives all scheduling decisions.
+     *
+     * XXX I'm quite sure this is fine wrt to the various v->cpu_affinity
+     *     (at least, that was the intended design!). Could it be useful
+     *     to cross-check d->node_affinity against `online`? The basic
+     *     idea here is "Hey, if you shoot yourself in the foot... You've
+     *     shot in the foot!", but, you know...
+     */
+    if ( d->has_node_affinity )
+        goto out;
+
 
     for_each_vcpu ( d, v )
     {
@@ -365,6 +379,8 @@ void domain_update_node_affinity(struct 
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
+
+out:
     spin_unlock(&d->node_affinity_lock);
 
     free_cpumask_var(online_affinity);
@@ -372,6 +388,31 @@ void domain_update_node_affinity(struct 
 }
 
 
+int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
+{
+    spin_lock(&d->node_affinity_lock);
+
+    /*
+     * Being/becoming affine to _no_ nodes is not going to work,
+     * let's take it as the `reset node affinity` command.
+     */
+    if ( nodes_empty(*affinity) )
+    {
+        d->has_node_affinity = 0;
+        spin_unlock(&d->node_affinity_lock);
+        domain_update_node_affinity(d);
+        return 0;
+    }
+
+    d->has_node_affinity = 1;
+    d->node_affinity = *affinity;
+
+    spin_unlock(&d->node_affinity_lock);
+
+    return 0;
+}
+
+
 struct domain *get_domain_by_id(domid_t dom)
 {
     struct domain *d;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -621,6 +621,27 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
     }
     break;
 
+    case XEN_DOMCTL_node_affinity:
+    {
+        domid_t dom = op->domain;
+        struct domain *d = rcu_lock_domain_by_id(dom);
+        nodemask_t new_affinity;
+
+        ret = -ESRCH;
+        if ( d == NULL )
+            break;
+
+        /* XXX We need an xsm_* for this I guess, right? */
+
+        ret = xenctl_nodemap_to_nodemask(&new_affinity,
+                                         &op->u.node_affinity.nodemap);
+        if ( !ret )
+            ret = domain_set_node_affinity(d, &new_affinity);
+
+        rcu_unlock_domain(d);
+    }
+    break;
+
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
     {
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -217,6 +217,14 @@ static void cpuset_print(char *set, int 
     *set++ = '\0';
 }
 
+static void nodeset_print(char *set, int size, const nodemask_t *mask)
+{
+    *set++ = '[';
+    set += nodelist_scnprintf(set, size-2, mask);
+    *set++ = ']';
+    *set++ = '\0';
+}
+
 static void periodic_timer_print(char *str, int size, uint64_t period)
 {
     if ( period == 0 )
@@ -272,6 +280,9 @@ static void dump_domains(unsigned char k
 
         dump_pageframe_info(d);
                
+        nodeset_print(tmpstr, sizeof(tmpstr), &d->node_affinity);
+        printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr);
+
         printk("VCPU information and callbacks for domain %u:\n",
                d->domain_id);
         for_each_vcpu ( d, v )
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -278,6 +278,15 @@ typedef struct xen_domctl_getvcpuinfo xe
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
 
 
+/* Set the NUMA node(s) with which the guest is `affine`. */
+/* XEN_DOMCTL_node_affinity */
+struct xen_domctl_node_affinity {
+    struct xenctl_map nodemap;   /* IN */
+};
+typedef struct xen_domctl_node_affinity xen_domctl_node_affinity_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_node_affinity_t);
+
+
 /* Get/set which physical cpus a vcpu can execute on. */
 /* XEN_DOMCTL_setvcpuaffinity */
 /* XEN_DOMCTL_getvcpuaffinity */
@@ -914,6 +923,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_node_affinity                 67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -927,6 +937,7 @@ struct xen_domctl {
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
         struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
         struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
+        struct xen_domctl_node_affinity     node_affinity;
         struct xen_domctl_vcpuaffinity      vcpuaffinity;
         struct xen_domctl_shadow_op         shadow_op;
         struct xen_domctl_max_mem           max_mem;
diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
--- a/xen/include/xen/nodemask.h
+++ b/xen/include/xen/nodemask.h
@@ -8,8 +8,9 @@
  * See detailed comments in the file linux/bitmap.h describing the
  * data type on which these nodemasks are based.
  *
- * For details of nodemask_scnprintf() and nodemask_parse(),
- * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c.
+ * For details of nodemask_scnprintf(), nodelist_scnpintf() and
+ * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse()
+ * in lib/bitmap.c.
  *
  * The available nodemask operations are:
  *
@@ -48,6 +49,7 @@
  * unsigned long *nodes_addr(mask)	Array of unsigned long's in mask
  *
  * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
+ * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing
  * int nodemask_parse(ubuf, ulen, mask)	Parse ascii string as nodemask
  *
  * for_each_node_mask(node, mask)	for-loop node over mask
@@ -280,6 +282,14 @@ static inline int __first_unset_node(con
 
 #define nodes_addr(src) ((src).bits)
 
+#define nodelist_scnprintf(buf, len, src) \
+			__nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES)
+static inline int __nodelist_scnprintf(char *buf, int len,
+					const nodemask_t *srcp, int nbits)
+{
+	return bitmap_scnlistprintf(buf, len, srcp->bits, nbits);
+}
+
 #if 0
 #define nodemask_scnprintf(buf, len, src) \
 			__nodemask_scnprintf((buf), (len), &(src), MAX_NUMNODES)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -346,8 +346,12 @@ struct domain
     /* Various mem_events */
     struct mem_event_per_domain *mem_event;
 
-    /* Currently computed from union of all vcpu cpu-affinity masks. */
+    /*
+     * Can be specified by the user. If that is not the case, it is
+     * computed from the union of all the vcpu cpu-affinity masks.
+     */
     nodemask_t node_affinity;
+    int has_node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
 };
@@ -416,6 +420,7 @@ static inline void get_knownalive_domain
     ASSERT(!(atomic_read(&d->refcnt) & DOMAIN_DESTROYED));
 }
 
+int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
 void domain_update_node_affinity(struct domain *d);
 
 struct domain *domain_create(

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxab-0001mo-5n; Wed, 11 Apr 2012 13:28:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxaZ-0001lX-IF
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:00 +0000
Received: from [85.158.139.83:40979] by server-9.bemta-5.messagelabs.com id
	FC/AC-09826-ED6858F4; Wed, 11 Apr 2012 13:27:58 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!5
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24675 invoked from network); 11 Apr 2012 13:27:56 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:27:56 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=KiojuhQqN3lMFJorayAwH5RePoSw/MXJgrHDKR/2q7I=;
	b=XECNyi4smQRzE+7wOC9jAHraytZTMaXch5Dz8Qy4fC/eG/OpO1G9Q6Dq+XKNsqIwDg
	fdTvZdd2hFiEuOV7M7TYRkA9CrvAfkUPTUu6ty8Xuqd4X7i3+FIuJB1OZBGCyEUnu0pN
	Y8jO5ob/2tIe+M7U2iRYyVfzcf3eTUYV2MDxr9UBO0llatoCj047E/52cqjTBKl/34Fk
	PKGOyjIfQvA8MTzebqdQw1qhtK+gunvfgarMi5WN4P+8MxicvZbcY8+B8SjlKWB6VoBU
	Z6DFcSWaDmzit+uD+qnz/QPVy0JptQ/vAsIhKNoLTfTBd3/ELOt5fHMWkl8wkkbTaWuL
	WklQ==
Received: by 10.14.100.71 with SMTP id y47mr2009693eef.9.1334150876583;
	Wed, 11 Apr 2012 06:27:56 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 7e76233448b02810f0ae473cb651215fb82dc1f9
Message-Id: <7e76233448b02810f0ae.1334150272@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:52 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Let the user specify the NUMA node affinity of a guest via the
'nodes=' config switch. Explicitly listing the intended target host
nodes is required as of now.

A valid setting will directly impact the node_affinity mask
of the guest, i.e., it will change the behaviour of the low level
memory allocator. On the other hand, this commit does not affect
by any means how the guest's vCPUs are scheduled on the host's
pCPUs.

TODO: * Better investigate and test interactions with cpupools.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,15 @@ List of which cpus the guest is allowed 
 (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
 
+=item B<nodes=[ NODE, NODE, ...]>
+
+List of the NUMA nodes of the host the guest should be considered
+`affine` with. Being affine to a (set of) NUMA node(s) mainly means
+the guest's memory is going to be allocated on those node(s).
+
+A list of nodes should be specified as follows: `nodes=["0", "3"]`
+for the guest to be affine with nodes 0 and 3.
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -110,6 +110,44 @@ int xc_domain_shutdown(xc_interface *xch
 }
 
 
+int xc_domain_node_affinity(xc_interface *xch,
+                            uint32_t domid,
+                            xc_nodemap_t node_affinity)
+{
+    DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BUFFER(uint8_t, local);
+    int ret = -1;
+    int nodesize;
+
+    nodesize = xc_get_nodemap_size(xch);
+    if (!nodesize)
+    {
+        PERROR("Could not get number of nodes");
+        goto out;
+    }
+
+    local = xc_hypercall_buffer_alloc(xch, local, nodesize);
+    if ( local == NULL )
+    {
+        PERROR("Could not allocate memory for domain_node_affinity domctl hypercall");
+        goto out;
+    }
+
+    domctl.cmd = XEN_DOMCTL_node_affinity;
+    domctl.domain = (domid_t)domid;
+
+    memcpy(local, node_affinity, nodesize);
+    set_xen_guest_handle(domctl.u.node_affinity.nodemap.bitmap, local);
+    domctl.u.node_affinity.nodemap.nr_elems = nodesize * 8;
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_buffer_free(xch, local);
+
+ out:
+    return ret;
+}
+
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -520,6 +520,19 @@ int xc_watchdog(xc_interface *xch,
 		uint32_t id,
 		uint32_t timeout);
 
+/**
+ * This function explicitly sets the affinity of a domain with the
+ * host NUMA nodes.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id in which vcpus are to be created.
+ * @parm node_affinity the map of the affine nodes.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_domain_node_affinity(xc_interface *xch,
+                            uint32_t domind,
+                            xc_nodemap_t node_affinity);
+
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,
diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -20,7 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_nodemap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
@@ -119,6 +119,19 @@ static void libxl_cpumap_rand_init(libxl
     }
 }
 
+static void libxl_nodemap_rand_init(libxl_nodemap *nodemap)
+{
+    int i;
+    nodemap->size = rand() % 16;
+    nodemap->map = calloc(nodemap->size, sizeof(*nodemap->map));
+    libxl_for_each_node(i, *nodemap) {
+        if (rand() % 2)
+            libxl_nodemap_set(nodemap, i);
+        else
+            libxl_nodemap_reset(nodemap, i);
+    }
+}
+
 static void libxl_key_value_list_rand_init(libxl_key_value_list *pkvl)
 {
     int i, nr_kvp = rand() % 16;
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3082,6 +3082,16 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
     return rc;
 }
 
+int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
+                            libxl_nodemap *nodemap)
+{
+    if (xc_domain_node_affinity(ctx->xch, domid, nodemap->map)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -727,6 +727,8 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
                            libxl_cpumap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
                                unsigned int max_vcpus, libxl_cpumap *cpumap);
+int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
+                            libxl_nodemap *nodemap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
 
 libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -121,6 +121,12 @@ int libxl__domain_build_info_setdefault(
         libxl_cpumap_set_any(&b_info->cpumap);
     }
 
+    if (!b_info->nodemap.size) {
+        if (libxl_nodemap_alloc(CTX, &b_info->nodemap))
+            return ERROR_NOMEM;
+        libxl_nodemap_set_none(&b_info->nodemap);
+    }
+
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->max_memkb = 32 * 1024;
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -67,6 +67,7 @@ int libxl__build_pre(libxl__gc *gc, uint
     char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
+    libxl_set_node_affinity(ctx, domid, &info->nodemap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -119,6 +119,26 @@ out:
     return s;
 }
 
+yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand,
+                                       libxl_nodemap *nodemap)
+{
+    yajl_gen_status s;
+    int i;
+
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    libxl_for_each_node(i, *nodemap) {
+        if (libxl_nodemap_test(nodemap, i)) {
+            s = yajl_gen_integer(hand, i);
+            if (s != yajl_gen_status_ok) goto out;
+        }
+    }
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
                                               libxl_key_value_list *pkvl)
 {
diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -27,6 +27,7 @@ yajl_gen_status libxl_domid_gen_json(yaj
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
 yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
 yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand, libxl_nodemap *p);
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                                  libxl_cpuid_policy_list *p);
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -11,6 +11,7 @@ libxl_domid = Builtin("domid", json_fn =
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
 libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
+libxl_nodemap = Builtin("nodemap", dispose_fn="libxl_nodemap_dispose", passby=PASS_BY_REFERENCE)
 libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
 
 libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
@@ -233,6 +234,7 @@ libxl_domain_build_info = Struct("domain
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
     ("cpumap",          libxl_cpumap),
+    ("nodemap",         libxl_nodemap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -515,7 +515,7 @@ static void parse_config_data(const char
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *nodes, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
     int pci_permissive = 0;
@@ -628,6 +628,39 @@ static void parse_config_data(const char
         free(buf2);
     }
 
+    if (!xlu_cfg_get_list (config, "nodes", &nodes, 0, 0)) {
+        int i, n_nodes = 0;
+
+        if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+            fprintf(stderr, "Unable to allocate nodemap\n");
+            exit(1);
+        }
+
+        libxl_nodemap_set_none(&b_info->nodemap);
+        while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
+            i = atoi(buf);
+            if (!libxl_nodemap_node_valid(&b_info->nodemap, i)) {
+                fprintf(stderr, "node %d illegal\n", i);
+                exit(1);
+            }
+            libxl_nodemap_set(&b_info->nodemap, i);
+            n_nodes++;
+        }
+
+        if (n_nodes == 0)
+            fprintf(stderr, "No valid node found: no affinity will be set\n");
+    }
+    else {
+        /*
+         * XXX What would a sane default be? I think doing nothing
+         *     (i.e., relying on cpu-affinity/cpupool ==> the current
+         *     behavior) should be just fine.
+         *     That would mean we're saying to the user "if you want us
+         *     to take care of NUMA, please tell us, maybe just putting
+         *     'nodes=auto', but tell us... otherwise we do as usual".
+         */
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -243,6 +243,18 @@ int attrib__libxl_cpumap_set(PyObject *v
     return 0;
 }
 
+int attrib__libxl_nodemap_set(PyObject *v, libxl_nodemap *pptr)
+{
+    int i;
+    long node;
+
+    for (i = 0; i < PyList_Size(v); i++) {
+        node = PyInt_AsLong(PyList_GetItem(v, i));
+        libxl_nodemap_set(pptr, node);
+    }
+    return 0;
+}
+
 int attrib__libxl_file_reference_set(PyObject *v, libxl_file_reference *pptr)
 {
     return genwrap__string_set(v, &pptr->path);
diff --git a/xen/common/domain.c b/xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -222,6 +222,7 @@ struct domain *domain_create(
 
     spin_lock_init(&d->node_affinity_lock);
     d->node_affinity = NODE_MASK_ALL;
+    d->has_node_affinity = 0;
 
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
@@ -337,7 +338,7 @@ void domain_update_node_affinity(struct 
 {
     cpumask_var_t cpumask;
     cpumask_var_t online_affinity;
-    const cpumask_t *online;
+    const cpumask_t *online = cpupool_online_cpumask(d->cpupool);
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
@@ -350,9 +351,22 @@ void domain_update_node_affinity(struct 
         return;
     }
 
-    online = cpupool_online_cpumask(d->cpupool);
+    spin_lock(&d->node_affinity_lock);
 
-    spin_lock(&d->node_affinity_lock);
+    /*
+     * If someone explicitly told us our NUMA affinity, avoid messing
+     * that up. Notice, however, that vcpu affinity is still what
+     * drives all scheduling decisions.
+     *
+     * XXX I'm quite sure this is fine wrt to the various v->cpu_affinity
+     *     (at least, that was the intended design!). Could it be useful
+     *     to cross-check d->node_affinity against `online`? The basic
+     *     idea here is "Hey, if you shoot yourself in the foot... You've
+     *     shot in the foot!", but, you know...
+     */
+    if ( d->has_node_affinity )
+        goto out;
+
 
     for_each_vcpu ( d, v )
     {
@@ -365,6 +379,8 @@ void domain_update_node_affinity(struct 
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
+
+out:
     spin_unlock(&d->node_affinity_lock);
 
     free_cpumask_var(online_affinity);
@@ -372,6 +388,31 @@ void domain_update_node_affinity(struct 
 }
 
 
+int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
+{
+    spin_lock(&d->node_affinity_lock);
+
+    /*
+     * Being/becoming affine to _no_ nodes is not going to work,
+     * let's take it as the `reset node affinity` command.
+     */
+    if ( nodes_empty(*affinity) )
+    {
+        d->has_node_affinity = 0;
+        spin_unlock(&d->node_affinity_lock);
+        domain_update_node_affinity(d);
+        return 0;
+    }
+
+    d->has_node_affinity = 1;
+    d->node_affinity = *affinity;
+
+    spin_unlock(&d->node_affinity_lock);
+
+    return 0;
+}
+
+
 struct domain *get_domain_by_id(domid_t dom)
 {
     struct domain *d;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -621,6 +621,27 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
     }
     break;
 
+    case XEN_DOMCTL_node_affinity:
+    {
+        domid_t dom = op->domain;
+        struct domain *d = rcu_lock_domain_by_id(dom);
+        nodemask_t new_affinity;
+
+        ret = -ESRCH;
+        if ( d == NULL )
+            break;
+
+        /* XXX We need an xsm_* for this I guess, right? */
+
+        ret = xenctl_nodemap_to_nodemask(&new_affinity,
+                                         &op->u.node_affinity.nodemap);
+        if ( !ret )
+            ret = domain_set_node_affinity(d, &new_affinity);
+
+        rcu_unlock_domain(d);
+    }
+    break;
+
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
     {
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -217,6 +217,14 @@ static void cpuset_print(char *set, int 
     *set++ = '\0';
 }
 
+static void nodeset_print(char *set, int size, const nodemask_t *mask)
+{
+    *set++ = '[';
+    set += nodelist_scnprintf(set, size-2, mask);
+    *set++ = ']';
+    *set++ = '\0';
+}
+
 static void periodic_timer_print(char *str, int size, uint64_t period)
 {
     if ( period == 0 )
@@ -272,6 +280,9 @@ static void dump_domains(unsigned char k
 
         dump_pageframe_info(d);
                
+        nodeset_print(tmpstr, sizeof(tmpstr), &d->node_affinity);
+        printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr);
+
         printk("VCPU information and callbacks for domain %u:\n",
                d->domain_id);
         for_each_vcpu ( d, v )
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -278,6 +278,15 @@ typedef struct xen_domctl_getvcpuinfo xe
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
 
 
+/* Set the NUMA node(s) with which the guest is `affine`. */
+/* XEN_DOMCTL_node_affinity */
+struct xen_domctl_node_affinity {
+    struct xenctl_map nodemap;   /* IN */
+};
+typedef struct xen_domctl_node_affinity xen_domctl_node_affinity_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_node_affinity_t);
+
+
 /* Get/set which physical cpus a vcpu can execute on. */
 /* XEN_DOMCTL_setvcpuaffinity */
 /* XEN_DOMCTL_getvcpuaffinity */
@@ -914,6 +923,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_node_affinity                 67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -927,6 +937,7 @@ struct xen_domctl {
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
         struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
         struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
+        struct xen_domctl_node_affinity     node_affinity;
         struct xen_domctl_vcpuaffinity      vcpuaffinity;
         struct xen_domctl_shadow_op         shadow_op;
         struct xen_domctl_max_mem           max_mem;
diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
--- a/xen/include/xen/nodemask.h
+++ b/xen/include/xen/nodemask.h
@@ -8,8 +8,9 @@
  * See detailed comments in the file linux/bitmap.h describing the
  * data type on which these nodemasks are based.
  *
- * For details of nodemask_scnprintf() and nodemask_parse(),
- * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c.
+ * For details of nodemask_scnprintf(), nodelist_scnpintf() and
+ * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse()
+ * in lib/bitmap.c.
  *
  * The available nodemask operations are:
  *
@@ -48,6 +49,7 @@
  * unsigned long *nodes_addr(mask)	Array of unsigned long's in mask
  *
  * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
+ * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing
  * int nodemask_parse(ubuf, ulen, mask)	Parse ascii string as nodemask
  *
  * for_each_node_mask(node, mask)	for-loop node over mask
@@ -280,6 +282,14 @@ static inline int __first_unset_node(con
 
 #define nodes_addr(src) ((src).bits)
 
+#define nodelist_scnprintf(buf, len, src) \
+			__nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES)
+static inline int __nodelist_scnprintf(char *buf, int len,
+					const nodemask_t *srcp, int nbits)
+{
+	return bitmap_scnlistprintf(buf, len, srcp->bits, nbits);
+}
+
 #if 0
 #define nodemask_scnprintf(buf, len, src) \
 			__nodemask_scnprintf((buf), (len), &(src), MAX_NUMNODES)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -346,8 +346,12 @@ struct domain
     /* Various mem_events */
     struct mem_event_per_domain *mem_event;
 
-    /* Currently computed from union of all vcpu cpu-affinity masks. */
+    /*
+     * Can be specified by the user. If that is not the case, it is
+     * computed from the union of all the vcpu cpu-affinity masks.
+     */
     nodemask_t node_affinity;
+    int has_node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
 };
@@ -416,6 +420,7 @@ static inline void get_knownalive_domain
     ASSERT(!(atomic_read(&d->refcnt) & DOMAIN_DESTROYED));
 }
 
+int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
 void domain_update_node_affinity(struct domain *d);
 
 struct domain *domain_create(

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxac-0001o7-Qi; Wed, 11 Apr 2012 13:28:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxab-0001kR-Cx
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:01 +0000
Received: from [85.158.143.35:58460] by server-1.bemta-4.messagelabs.com id
	79/2F-20925-1E6858F4; Wed, 11 Apr 2012 13:28:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!2
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28601 invoked from network); 11 Apr 2012 13:28:00 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:00 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=Va3hO1D97GU5l8UxRvcVoaeU6joiO6OkSwjzpCM1xIE=;
	b=NhVTvfoPSw30W48OSHx2fPsFhmZhdXVMjHD6w13vIx7orRRS/nk6317Wi6VNq4qUx8
	sFQ39RfvykN+qPhkMapP4ZOaQPpMumSh0o3FBmI4cEYtBui2L02C5HEId2BU2ShcRTZ4
	OW1tojqLGpixfomUMIak4PX16eQN22Tjqzlhs0eI5O5jbr367j/35aqQxPg3aZq2r3Yi
	fUoyAcU710O+f1FW7jNjfQMZLq7wtP8Qlutt3jG8gnxfKIHv1qfPdjhRTnKBMhwLOmFx
	BlcVcP2SxIwI61fxAtST5bxeMys6FBYEFFe7Kl2m+JhKKUodeM/YW0TIIENm4AXkbAov
	S7EA==
Received: by 10.213.21.148 with SMTP id j20mr964464ebb.158.1334150879846;
	Wed, 11 Apr 2012 06:27:59 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:58 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 64547b45cb112a35d3a2937ff8ac51c2a3b4bf57
Message-Id: <64547b45cb112a35d3a2.1334150273@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:53 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 06 of 10 [RFC]] xl: Allow user to set or change
 node affinity on-line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For feature parity with vcpu affinity, allow for specifying
node affinity not only at domain creation time, but at run-time
too.

Of course this is not going to be equally effective, as it will
only affect future memory allocations without touching what's
already there. However, in future we might want to change this,
and use this as an interface for sort-of manual "domain node
migration".

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -556,6 +556,26 @@ different run state is appropriate.  Pin
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
+=item B<node-affinity> I<domain-id> I<nodes>
+
+Set the NUMA node affinity for the domain, i.e., the set of NUMA
+nodes of the host from which the memory of the domain will be
+allocated. More specificallly, the domain's memory will be split
+in equal (well, as equal as possible) parts among all the nodes
+it is affine with, The keyword B<all> can be used to have the
+domain affine to all NUMA nodes in the host.
+
+Normally NUMA node affinity of a domain is automatically computed
+from its VCPU affinity. The default behaviour is to have it equal
+to all the nodes the PCPUs onto which the VCPUs of the domain are
+pinned belong to. Manually specifying it can be used to restrict
+this to a specific subset of the host NUMA nodes, for improved
+locality of memory accesses by the domain. Notice, however, that
+this will not affect the memory that has already been allocated.
+For having the full amount of memory allocated on specific node(s)
+at domain creation time, the domain's configuration file is what
+should be used.
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -442,7 +442,7 @@ void libxl_map_dispose(struct libxl_map 
     free(map->map);
 }
 
-static int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
+int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
 {
     int sz;
 
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,7 @@ int libxl_devid_to_device_nic(libxl_ctx 
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
+int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems);
 int libxl_map_test(struct libxl_map *map, int elem);
 void libxl_map_set(struct libxl_map *map, int elem);
 void libxl_map_reset(struct libxl_map *map, int elem);
@@ -79,6 +80,10 @@ static inline int libxl_map_elem_valid(s
 {
     return elem >= 0 && elem < (map->size * 8);
 }
+#define libxl_for_each_elem(v, m) for (v = 0; v < (m).size * 8; v++)
+#define libxl_for_each_set_elem(v, m) for (v = 0; v < (m).size * 8; v++) \
+                                              if (libxl_map_test(&(m), v))
+
 
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
 static inline int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -54,6 +54,7 @@ int main_config_update(int argc, char **
 int main_button_press(int argc, char **argv);
 int main_vcpupin(int argc, char **argv);
 int main_vcpuset(int argc, char **argv);
+int main_nodeaffinity(int argc, char **argv);
 int main_memmax(int argc, char **argv);
 int main_memset(int argc, char **argv);
 int main_sched_credit(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -448,65 +448,75 @@ static void split_string_into_string_lis
     free(s);
 }
 
-static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+static int affinity_parse(char *str, struct libxl_map *map, int n_elems)
 {
-    libxl_cpumap exclude_cpumap;
-    uint32_t cpuida, cpuidb;
+    struct libxl_map exclude_map;
+    uint32_t stra, strb;
     char *endptr, *toka, *tokb, *saveptr = NULL;
-    int i, rc = 0, rmcpu;
-
-    if (!strcmp(cpu, "all")) {
-        libxl_cpumap_set_any(cpumap);
+    int i, rc = 0, rmelem;
+
+    if (!strcmp(str, "all")) {
+        libxl_map_set_any(map);
         return 0;
     }
 
-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
-        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+    if (libxl_map_alloc(ctx, &exclude_map, n_elems)) {
+        fprintf(stderr, "Error: Failed to allocate libxl_map.\n");
         return ENOMEM;
     }
 
-    for (toka = strtok_r(cpu, ",", &saveptr); toka;
+    for (toka = strtok_r(str, ",", &saveptr); toka;
          toka = strtok_r(NULL, ",", &saveptr)) {
-        rmcpu = 0;
+        rmelem = 0;
         if (*toka == '^') {
             /* This (These) Cpu(s) will be removed from the map */
             toka++;
-            rmcpu = 1;
+            rmelem = 1;
         }
         /* Extract a valid (range of) cpu(s) */
-        cpuida = cpuidb = strtoul(toka, &endptr, 10);
+        stra = strb = strtoul(toka, &endptr, 10);
         if (endptr == toka) {
             fprintf(stderr, "Error: Invalid argument.\n");
             rc = EINVAL;
-            goto vcpp_out;
+            goto afp_out;
         }
         if (*endptr == '-') {
             tokb = endptr + 1;
-            cpuidb = strtoul(tokb, &endptr, 10);
-            if (endptr == tokb || cpuida > cpuidb) {
+            strb = strtoul(tokb, &endptr, 10);
+            if (endptr == tokb || stra > strb) {
                 fprintf(stderr, "Error: Invalid argument.\n");
                 rc = EINVAL;
-                goto vcpp_out;
+                goto afp_out;
             }
         }
-        while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
-                         libxl_cpumap_set(&exclude_cpumap, cpuida);
-            cpuida++;
+        while (stra <= strb) {
+            rmelem == 0 ? libxl_map_set(map, stra) :
+                          libxl_map_set(&exclude_map, stra);
+            stra++;
         }
     }
 
     /* Clear all the cpus from the removal list */
-    libxl_for_each_set_cpu(i, exclude_cpumap) {
-        libxl_cpumap_reset(cpumap, i);
-    }
-
-vcpp_out:
-    libxl_cpumap_dispose(&exclude_cpumap);
+    libxl_for_each_set_elem(i, exclude_map) {
+        libxl_map_reset(map, i);
+    }
+
+afp_out:
+    libxl_map_dispose(&exclude_map);
 
     return rc;
 }
 
+static inline int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    return affinity_parse(cpu, cpumap, libxl_get_max_cpus(ctx));
+}
+
+static inline int nodeaffinity_parse(char *nodes, libxl_nodemap *nodemap)
+{
+    return affinity_parse(nodes, nodemap, libxl_get_max_nodes(ctx));
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -3873,6 +3883,40 @@ int main_vcpuset(int argc, char **argv)
     return 0;
 }
 
+static void nodeaffinity(const char *d, char *nodes)
+{
+    libxl_nodemap nodemap;
+
+    find_domain(d);
+
+    if (libxl_nodemap_alloc(ctx, &nodemap))
+        goto nodeaffinity_out;
+
+    if (!strcmp(nodes, "all"))
+        libxl_nodemap_set_any(&nodemap);
+    else if (nodeaffinity_parse(nodes, &nodemap))
+        goto nodeaffinity_out1;
+
+    if (libxl_set_node_affinity(ctx, domid, &nodemap) == -1)
+        fprintf(stderr, "Could not set node affinity for dom `%d'.\n", domid);
+
+  nodeaffinity_out1:
+    libxl_nodemap_dispose(&nodemap);
+  nodeaffinity_out:
+    ;
+}
+
+int main_nodeaffinity(int argc, char **argv)
+{
+    int opt;
+
+    if ((opt = def_getopt(argc, argv, "", "node-affinity", 2)) != -1)
+        return opt;
+
+    nodeaffinity(argv[optind], argv[optind+1]);
+    return 0;
+}
+
 static void output_xeninfo(void)
 {
     const libxl_version_info *info;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -195,6 +195,11 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
+    { "node-affinity",
+      &main_nodeaffinity, 0,
+      "Set the NUMA node affinity for the domain",
+      "<Domain> <Nodes|all>",
+    },
     { "list-vm",
       &main_list_vm, 0,
       "List the VMs,without DOM0",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxac-0001o7-Qi; Wed, 11 Apr 2012 13:28:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxab-0001kR-Cx
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:01 +0000
Received: from [85.158.143.35:58460] by server-1.bemta-4.messagelabs.com id
	79/2F-20925-1E6858F4; Wed, 11 Apr 2012 13:28:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!2
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28601 invoked from network); 11 Apr 2012 13:28:00 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:00 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=Va3hO1D97GU5l8UxRvcVoaeU6joiO6OkSwjzpCM1xIE=;
	b=NhVTvfoPSw30W48OSHx2fPsFhmZhdXVMjHD6w13vIx7orRRS/nk6317Wi6VNq4qUx8
	sFQ39RfvykN+qPhkMapP4ZOaQPpMumSh0o3FBmI4cEYtBui2L02C5HEId2BU2ShcRTZ4
	OW1tojqLGpixfomUMIak4PX16eQN22Tjqzlhs0eI5O5jbr367j/35aqQxPg3aZq2r3Yi
	fUoyAcU710O+f1FW7jNjfQMZLq7wtP8Qlutt3jG8gnxfKIHv1qfPdjhRTnKBMhwLOmFx
	BlcVcP2SxIwI61fxAtST5bxeMys6FBYEFFe7Kl2m+JhKKUodeM/YW0TIIENm4AXkbAov
	S7EA==
Received: by 10.213.21.148 with SMTP id j20mr964464ebb.158.1334150879846;
	Wed, 11 Apr 2012 06:27:59 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:27:58 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 64547b45cb112a35d3a2937ff8ac51c2a3b4bf57
Message-Id: <64547b45cb112a35d3a2.1334150273@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:53 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 06 of 10 [RFC]] xl: Allow user to set or change
 node affinity on-line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For feature parity with vcpu affinity, allow for specifying
node affinity not only at domain creation time, but at run-time
too.

Of course this is not going to be equally effective, as it will
only affect future memory allocations without touching what's
already there. However, in future we might want to change this,
and use this as an interface for sort-of manual "domain node
migration".

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -556,6 +556,26 @@ different run state is appropriate.  Pin
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
+=item B<node-affinity> I<domain-id> I<nodes>
+
+Set the NUMA node affinity for the domain, i.e., the set of NUMA
+nodes of the host from which the memory of the domain will be
+allocated. More specificallly, the domain's memory will be split
+in equal (well, as equal as possible) parts among all the nodes
+it is affine with, The keyword B<all> can be used to have the
+domain affine to all NUMA nodes in the host.
+
+Normally NUMA node affinity of a domain is automatically computed
+from its VCPU affinity. The default behaviour is to have it equal
+to all the nodes the PCPUs onto which the VCPUs of the domain are
+pinned belong to. Manually specifying it can be used to restrict
+this to a specific subset of the host NUMA nodes, for improved
+locality of memory accesses by the domain. Notice, however, that
+this will not affect the memory that has already been allocated.
+For having the full amount of memory allocated on specific node(s)
+at domain creation time, the domain's configuration file is what
+should be used.
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -442,7 +442,7 @@ void libxl_map_dispose(struct libxl_map 
     free(map->map);
 }
 
-static int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
+int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
 {
     int sz;
 
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,7 @@ int libxl_devid_to_device_nic(libxl_ctx 
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
+int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems);
 int libxl_map_test(struct libxl_map *map, int elem);
 void libxl_map_set(struct libxl_map *map, int elem);
 void libxl_map_reset(struct libxl_map *map, int elem);
@@ -79,6 +80,10 @@ static inline int libxl_map_elem_valid(s
 {
     return elem >= 0 && elem < (map->size * 8);
 }
+#define libxl_for_each_elem(v, m) for (v = 0; v < (m).size * 8; v++)
+#define libxl_for_each_set_elem(v, m) for (v = 0; v < (m).size * 8; v++) \
+                                              if (libxl_map_test(&(m), v))
+
 
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
 static inline int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -54,6 +54,7 @@ int main_config_update(int argc, char **
 int main_button_press(int argc, char **argv);
 int main_vcpupin(int argc, char **argv);
 int main_vcpuset(int argc, char **argv);
+int main_nodeaffinity(int argc, char **argv);
 int main_memmax(int argc, char **argv);
 int main_memset(int argc, char **argv);
 int main_sched_credit(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -448,65 +448,75 @@ static void split_string_into_string_lis
     free(s);
 }
 
-static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+static int affinity_parse(char *str, struct libxl_map *map, int n_elems)
 {
-    libxl_cpumap exclude_cpumap;
-    uint32_t cpuida, cpuidb;
+    struct libxl_map exclude_map;
+    uint32_t stra, strb;
     char *endptr, *toka, *tokb, *saveptr = NULL;
-    int i, rc = 0, rmcpu;
-
-    if (!strcmp(cpu, "all")) {
-        libxl_cpumap_set_any(cpumap);
+    int i, rc = 0, rmelem;
+
+    if (!strcmp(str, "all")) {
+        libxl_map_set_any(map);
         return 0;
     }
 
-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
-        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+    if (libxl_map_alloc(ctx, &exclude_map, n_elems)) {
+        fprintf(stderr, "Error: Failed to allocate libxl_map.\n");
         return ENOMEM;
     }
 
-    for (toka = strtok_r(cpu, ",", &saveptr); toka;
+    for (toka = strtok_r(str, ",", &saveptr); toka;
          toka = strtok_r(NULL, ",", &saveptr)) {
-        rmcpu = 0;
+        rmelem = 0;
         if (*toka == '^') {
             /* This (These) Cpu(s) will be removed from the map */
             toka++;
-            rmcpu = 1;
+            rmelem = 1;
         }
         /* Extract a valid (range of) cpu(s) */
-        cpuida = cpuidb = strtoul(toka, &endptr, 10);
+        stra = strb = strtoul(toka, &endptr, 10);
         if (endptr == toka) {
             fprintf(stderr, "Error: Invalid argument.\n");
             rc = EINVAL;
-            goto vcpp_out;
+            goto afp_out;
         }
         if (*endptr == '-') {
             tokb = endptr + 1;
-            cpuidb = strtoul(tokb, &endptr, 10);
-            if (endptr == tokb || cpuida > cpuidb) {
+            strb = strtoul(tokb, &endptr, 10);
+            if (endptr == tokb || stra > strb) {
                 fprintf(stderr, "Error: Invalid argument.\n");
                 rc = EINVAL;
-                goto vcpp_out;
+                goto afp_out;
             }
         }
-        while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
-                         libxl_cpumap_set(&exclude_cpumap, cpuida);
-            cpuida++;
+        while (stra <= strb) {
+            rmelem == 0 ? libxl_map_set(map, stra) :
+                          libxl_map_set(&exclude_map, stra);
+            stra++;
         }
     }
 
     /* Clear all the cpus from the removal list */
-    libxl_for_each_set_cpu(i, exclude_cpumap) {
-        libxl_cpumap_reset(cpumap, i);
-    }
-
-vcpp_out:
-    libxl_cpumap_dispose(&exclude_cpumap);
+    libxl_for_each_set_elem(i, exclude_map) {
+        libxl_map_reset(map, i);
+    }
+
+afp_out:
+    libxl_map_dispose(&exclude_map);
 
     return rc;
 }
 
+static inline int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    return affinity_parse(cpu, cpumap, libxl_get_max_cpus(ctx));
+}
+
+static inline int nodeaffinity_parse(char *nodes, libxl_nodemap *nodemap)
+{
+    return affinity_parse(nodes, nodemap, libxl_get_max_nodes(ctx));
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -3873,6 +3883,40 @@ int main_vcpuset(int argc, char **argv)
     return 0;
 }
 
+static void nodeaffinity(const char *d, char *nodes)
+{
+    libxl_nodemap nodemap;
+
+    find_domain(d);
+
+    if (libxl_nodemap_alloc(ctx, &nodemap))
+        goto nodeaffinity_out;
+
+    if (!strcmp(nodes, "all"))
+        libxl_nodemap_set_any(&nodemap);
+    else if (nodeaffinity_parse(nodes, &nodemap))
+        goto nodeaffinity_out1;
+
+    if (libxl_set_node_affinity(ctx, domid, &nodemap) == -1)
+        fprintf(stderr, "Could not set node affinity for dom `%d'.\n", domid);
+
+  nodeaffinity_out1:
+    libxl_nodemap_dispose(&nodemap);
+  nodeaffinity_out:
+    ;
+}
+
+int main_nodeaffinity(int argc, char **argv)
+{
+    int opt;
+
+    if ((opt = def_getopt(argc, argv, "", "node-affinity", 2)) != -1)
+        return opt;
+
+    nodeaffinity(argv[optind], argv[optind+1]);
+    return 0;
+}
+
 static void output_xeninfo(void)
 {
     const libxl_version_info *info;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -195,6 +195,11 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
+    { "node-affinity",
+      &main_nodeaffinity, 0,
+      "Set the NUMA node affinity for the domain",
+      "<Domain> <Nodes|all>",
+    },
     { "list-vm",
       &main_list_vm, 0,
       "List the VMs,without DOM0",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxag-0001qu-SP; Wed, 11 Apr 2012 13:28:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxae-0001pB-U8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:05 +0000
Received: from [85.158.143.35:58660] by server-3.bemta-4.messagelabs.com id
	90/76-05853-4E6858F4; Wed, 11 Apr 2012 13:28:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!3
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28856 invoked from network); 11 Apr 2012 13:28:02 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:02 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=NSc4thXnvE5RCxPeAsp832BlLabe1ZKpsXgS+IeX9Z0=;
	b=BP+YXbKDBDx20sI+sIlHLoHeh0jnQzn36P49MUGYkL5X+TnhWrYx1kp09IO+ljzj8l
	/MQhZ1Mu+We1mb0PWlttFbypJz+B31baF/4qGaRHv9iSYVjUCSxEdO2n7uB+ln/RBrEE
	EbaqvJYVnXY9oyYqNc0C/5v5JFmiwNBJ5hmRLwOtqqHFbHrgKUV6FDo1/IsUKM8imCtn
	m8cfQaYRx029viH/tObQzATuYondpI9d0/5krBjt43b+fbXt0GkXwx5/tZneYvpS+/w+
	PAquNjvc+ZVmaey1lP717CFaNGlvXmvC/0DSUpFM3ihPHUlifPc5eTbYv8kM71Y2r2pw
	dBZg==
Received: by 10.213.32.65 with SMTP id b1mr946821ebd.285.1334150882422;
	Wed, 11 Apr 2012 06:28:02 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:01 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1f4b55806de9e7109ff6fce14c06c67cb585f17c
Message-Id: <1f4b55806de9e7109ff6.1334150274@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:54 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the scheduler
 know about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Basic idea is: cpu-affinity tells where a vcpu can run,
while node-affinity tells where (in terms of on what NUMA nodes,
but that of course imply a set of CPUs) all the vcpus of the
domain should/prefer to run... Problems starts when you have
both of them speaking at the same time!

Respecting vcpu-affinity should remain the primary concern, thus
what we do here is add some two-step logic here and there in the
scheduler (i.e., where vcpu-affinity related decisions are being
undertaken). During the first step, we check the `&&` of vcpu and
node affinity masks, aiming at giving some precedence to the CPUs
that are both suitable and preferrable for the domain. However,
if that fails in finding a valid CPU, the node-affinity is just
ignored and, in the second step, we just fallback to vcpu-affinity,
as the original behaviour was.

Both the introduced overhead and the benefits this provides has
to be investigated and compared against each other, possibly in
varying conditions and running different workloads.

Finally, although still at the RFC level, efforts have been made
to write the code in a flexible enough fashion so that, if we
ever want to introduce further balancing steps, it shouldn't be
too much of a pain.

TODO: * Better investigate and test interactions with cpupools.
      * Test, verify and benchmark. Then test, verify and benchmark
        again, and again and again. What I know as of know is that
        it does not explode that easily, but whether it works properly
        and, more important, brings any benefit, this has to be
        proven (and yes, I'm out running these tests and benchs already,
        but do not esitate to manifest your will for helping with
        that :-D).
      * Add some counter/stats, e.g., to serve the purpose outlined
        right above.

XXX I'm benchmarking this just right now, and peeking at the results
    they don't seem too bad. Numbers are mostly close to the case where
    the VM is already pinned to a node when created. I'll post the
    results as soon as I can, and I'll be happy to investigate any issue,
    if you feel like the approach could be the right one.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -117,6 +117,8 @@ will run on cpus 2 and 3).
 List of the NUMA nodes of the host the guest should be considered
 `affine` with. Being affine to a (set of) NUMA node(s) mainly means
 the guest's memory is going to be allocated on those node(s).
+Also, the scheduler will prefer (but not force) running the guest's
+vcpus on the cpus of the affine node(s).
 
 A list of nodes should be specified as follows: `nodes=["0", "3"]`
 for the guest to be affine with nodes 0 and 3.
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -101,6 +101,15 @@
 
 
 /*
+ * Node Balancing
+ */
+#define CSCHED_BALANCE_NODE_AFFINITY    1
+#define CSCHED_BALANCE_CPU_AFFINITY     0
+#define CSCHED_BALANCE_START_STEP       CSCHED_BALANCE_NODE_AFFINITY
+#define CSCHED_BALANCE_END_STEP         CSCHED_BALANCE_CPU_AFFINITY
+
+
+/*
  * Boot parameters
  */
 static bool_t __read_mostly sched_credit_default_yield;
@@ -150,6 +159,17 @@ struct csched_dom {
     struct list_head active_vcpu;
     struct list_head active_sdom_elem;
     struct domain *dom;
+    /*
+     * Let's cache domain's dom->node_affinity here as an
+     * optimization for a couple of hot paths. In fact,
+     * knowing  whether or not dom->node_affinity has changed
+     * would allow us to avoid rebuilding node_affinity_cpumask
+     * (below) duing node balancing and/or scheduling.
+     */
+    nodemask_t node_affinity_cache;
+    /* Basing on what dom->node_affinity says,
+     * on what CPUs would we like to run most? */
+    cpumask_t node_affinity_cpumask;
     uint16_t active_vcpu_count;
     uint16_t weight;
     uint16_t cap;
@@ -230,6 +250,87 @@ static inline void
     list_del_init(&svc->runq_elem);
 }
 
+#define csched_balance(__step) \
+    for ( (__step) = CSCHED_BALANCE_START_STEP; \
+          (__step) >= CSCHED_BALANCE_END_STEP; \
+          (__step)-- )
+
+/*
+ * Sort-of conversion between node-affinity and vcpu-affinity for the domain,
+ * i.e., a cpumask containing all the cpus from all the set nodes in the
+ * node-affinity mask of the domain.
+ *
+ * Notice that we completely forget about serializing this (both here and
+ * in the various sites where node_affinity_cpumask is used) against
+ * d->node_affinity_lock. That would be hard to do properly, as that lock
+ * is a non IRQ-safe one, and it would be nearly impossible to access it
+ * from the scheduling code. However, although this leaves some room for
+ * races with code paths that updates d->node_affinity, it all should still
+ * be fine, considering:
+ *  (1) d->node_affinity updates are going to be quite rare;
+ *  (2) this balancing logic is kind-of "best effort" anyway;
+ *  (3) given (1), any inconsistencies are likely to be fixed by the next
+ *      call to this same function without risking going into instability.
+ *
+ * XXX Validate (via testing/benchmarking) whether this is true, as it
+ *     likely sounds to be, or it causes unexpected issues.
+ */
+static void
+csched_build_balance_cpumask(struct csched_dom *sdom)
+{
+    struct domain *d = sdom->dom;
+    int node;
+
+    /* Check whether we need to refresh the node-affinity cache we keep */
+    if ( likely(nodes_equal(d->node_affinity, sdom->node_affinity_cache)) )
+        return;
+    else
+        nodes_copy(sdom->node_affinity_cache, sdom->dom->node_affinity);
+
+    /* Create the cpumask matching the current node-affinity mask */
+    cpumask_clear(&sdom->node_affinity_cpumask);
+    for_each_node_mask( node, sdom->node_affinity_cache )
+        cpumask_or(&sdom->node_affinity_cpumask, &sdom->node_affinity_cpumask,
+                   &node_to_cpumask(node));
+}
+
+/* Put together the cpumask we are going to use for this balancing step */
+static int
+csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
+{
+    struct domain *d = vc->domain;
+    struct csched_dom *sdom = CSCHED_DOM(d);
+
+    /*
+     * Only two possible steps exists for now: node and vcpu affinity.
+     * If this domain does not have a node-affinity or is affine to all the
+     * nodes, just return th vcpu-affinity mask (for *this* vcpu) and
+     * stop the balancing process.
+     */
+    if ( !d->has_node_affinity || nodes_full(d->node_affinity) ||
+         step == CSCHED_BALANCE_CPU_AFFINITY )
+    {
+        cpumask_copy(mask, vc->cpu_affinity);
+        return CSCHED_BALANCE_CPU_AFFINITY;
+    }
+
+    csched_build_balance_cpumask(sdom);
+
+    /*
+     * XXX As of now (with only two possible steps, this is easy and readable
+     *     enough. If more steps become necessary at some point in time, we
+     *     can keep an array of cpumask_t in dom_data and return the proper
+     *     element via step-indexing such an array. Of course, we can turn
+     *     this like that even right now... Thoughts?
+     */
+    if ( step == CSCHED_BALANCE_NODE_AFFINITY )
+        cpumask_and(mask, &sdom->node_affinity_cpumask, vc->cpu_affinity);
+    else
+        cpumask_copy(mask, vc->cpu_affinity);
+
+    return step;
+}
+
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
@@ -252,6 +353,20 @@ boolean_param("tickle_one_idle_cpu", opt
 DEFINE_PER_CPU(unsigned int, last_tickle_cpu);
 
 static inline void
+__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask)
+{
+    CSCHED_STAT_CRANK(tickle_idlers_some);
+    if ( opt_tickle_one_idle )
+    {
+        this_cpu(last_tickle_cpu) = 
+            cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask);
+        cpumask_set_cpu(this_cpu(last_tickle_cpu), mask);
+    }
+    else
+        cpumask_or(mask, mask, idle_mask);
+}
+
+static inline void
 __runq_tickle(unsigned int cpu, struct csched_vcpu *new)
 {
     struct csched_vcpu * const cur =
@@ -289,22 +404,27 @@ static inline void
         }
         else
         {
-            cpumask_t idle_mask;
+            cpumask_t idle_mask, balance_mask;
+            int balance_step;
 
-            cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
-            if ( !cpumask_empty(&idle_mask) )
+            csched_balance(balance_step)
             {
-                CSCHED_STAT_CRANK(tickle_idlers_some);
-                if ( opt_tickle_one_idle )
-                {
-                    this_cpu(last_tickle_cpu) = 
-                        cpumask_cycle(this_cpu(last_tickle_cpu), &idle_mask);
-                    cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
-                }
-                else
-                    cpumask_or(&mask, &mask, &idle_mask);
+                /*
+                 * A each balancing step, look for any idler in the poper
+                 * affinity mask for the step itself (for new->vcpu).
+                 */
+                csched_balance_cpumask(new->vcpu, balance_step, &balance_mask);
+                cpumask_and(&idle_mask, prv->idlers, &balance_mask);
+
+                if ( !cpumask_empty(&idle_mask) )
+                    __cpumask_tickle(&mask, &idle_mask);
+
+                cpumask_and(&mask, &mask, &balance_mask);
+
+                /* We can quit balancing if we found someone to tickle */
+                if ( !cpumask_empty(&mask) )
+                    break;
             }
-            cpumask_and(&mask, &mask, new->vcpu->cpu_affinity);
         }
     }
 
@@ -445,7 +565,7 @@ static inline int
 }
 
 static inline int
-__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu)
+__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu, cpumask_t *mask)
 {
     /*
      * Don't pick up work that's in the peer's scheduling tail or hot on
@@ -453,27 +573,37 @@ static inline int
      */
     return !vc->is_running &&
            !__csched_vcpu_is_cache_hot(vc) &&
-           cpumask_test_cpu(dest_cpu, vc->cpu_affinity);
+           cpumask_test_cpu(dest_cpu, mask);
 }
 
 static int
 _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t commit)
 {
-    cpumask_t cpus;
+    cpumask_t cpus, start_cpus;
     cpumask_t idlers;
     cpumask_t *online;
+    struct csched_dom *sdom = CSCHED_DOM(vc->domain);
     struct csched_pcpu *spc = NULL;
     int cpu;
 
+    csched_build_balance_cpumask(sdom);
+
     /*
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
+     *
+     * It's worth tying to take balancing into account,
+     * at least for selecting from which cpu to start looking
+     * around from. XXX ... Or is this going to be too much?
      */
     online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
-    cpu = cpumask_test_cpu(vc->processor, &cpus)
+    cpumask_and(&start_cpus, &cpus, &sdom->node_affinity_cpumask);
+    if ( unlikely(cpumask_empty(&start_cpus)) )
+        cpumask_copy(&start_cpus, &cpus);
+    cpu = cpumask_test_cpu(vc->processor, &start_cpus)
             ? vc->processor
-            : cpumask_cycle(vc->processor, &cpus);
+            : cpumask_cycle(vc->processor, &start_cpus);
     ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) );
 
     /*
@@ -877,6 +1007,14 @@ csched_alloc_domdata(const struct schedu
     sdom->active_vcpu_count = 0;
     INIT_LIST_HEAD(&sdom->active_sdom_elem);
     sdom->dom = dom;
+    /*
+     *XXX This would be 'The Right Thing', but as it is still too
+     *    early and d->node_affinity has not settled yet, maybe we
+     *    can just init the two masks with something like all-nodes
+     *    and all-cpus and rely on the first balancing call for
+     *    having them updated?
+     */
+    csched_build_balance_cpumask(sdom);
     sdom->weight = CSCHED_DEFAULT_WEIGHT;
     sdom->cap = 0U;
 
@@ -1216,30 +1354,54 @@ csched_runq_steal(int peer_cpu, int cpu,
      */
     if ( peer_pcpu != NULL && !is_idle_vcpu(peer_vcpu) )
     {
-        list_for_each( iter, &peer_pcpu->runq )
+        int balance_step;
+
+        /*
+         * Idea here is trying take NUMA affinity (if any) into account.
+         * While at it, try to be general enough, exploiting the balancing
+         * infrastructure as follows:
+         *  - we act in steps (two for now: node and vcpu affinity);
+         *  - at each step we check each item of peer_pcpu's runq
+         *    looking for a candidate vcpu against the proper CPU
+         *    mask, depending on the step itself;
+         *  - masks are (should be!) checked in order of preference,
+         *    as a match will cause the end of the balancing process;
+         *  - a preferred mask should not contain any 'illegal' CPU(s)
+         *    (wrt to, e.g., the domain's 'cpu_affinity', if any), as
+         *    this might cause the vcpu to be shipped there!
+         */
+        csched_balance(balance_step)
         {
-            speer = __runq_elem(iter);
+            list_for_each( iter, &peer_pcpu->runq )
+            {
+                cpumask_t balance_mask;
 
-            /*
-             * If next available VCPU here is not of strictly higher
-             * priority than ours, this PCPU is useless to us.
-             */
-            if ( speer->pri <= pri )
-                break;
+                speer = __runq_elem(iter);
 
-            /* Is this VCPU is runnable on our PCPU? */
-            vc = speer->vcpu;
-            BUG_ON( is_idle_vcpu(vc) );
+                /*
+                 * If next available VCPU here is not of strictly higher
+                 * priority than ours, this PCPU is useless to us.
+                 */
+                if ( speer->pri <= pri )
+                    break;
 
-            if (__csched_vcpu_is_migrateable(vc, cpu))
-            {
-                /* We got a candidate. Grab it! */
-                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
-                CSCHED_STAT_CRANK(migrate_queued);
-                WARN_ON(vc->is_urgent);
-                __runq_remove(speer);
-                vc->processor = cpu;
-                return speer;
+                /* Is this VCPU is runnable on our PCPU? */
+                vc = speer->vcpu;
+                BUG_ON( is_idle_vcpu(vc) );
+
+                balance_step = csched_balance_cpumask(vc, balance_step,
+                                                      &balance_mask);
+
+                if (__csched_vcpu_is_migrateable(vc, cpu, &balance_mask))
+                {
+                    /* We got a candidate. Grab it! */
+                    CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
+                    CSCHED_STAT_CRANK(migrate_queued);
+                    WARN_ON(vc->is_urgent);
+                    __runq_remove(speer);
+                    vc->processor = cpu;
+                    return speer;
+                }
             }
         }
     }
diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
--- a/xen/include/xen/nodemask.h
+++ b/xen/include/xen/nodemask.h
@@ -195,6 +195,13 @@ static inline int __nodes_weight(const n
 	return bitmap_weight(srcp->bits, nbits);
 }
 
+#define nodes_copy(dst, src) __nodes_copy(&(dst), &(src), MAX_NUMNODES)
+static inline void __nodes_copy(nodemask_t *dstp,
+				const nodemask_t *srcp, int nbits)
+{
+	bitmap_copy(dstp->bits, srcp->bits, nbits);
+}
+
 #define nodes_shift_right(dst, src, n) \
 			__nodes_shift_right(&(dst), &(src), (n), MAX_NUMNODES)
 static inline void __nodes_shift_right(nodemask_t *dstp,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxag-0001qu-SP; Wed, 11 Apr 2012 13:28:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxae-0001pB-U8
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:05 +0000
Received: from [85.158.143.35:58660] by server-3.bemta-4.messagelabs.com id
	90/76-05853-4E6858F4; Wed, 11 Apr 2012 13:28:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!3
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28856 invoked from network); 11 Apr 2012 13:28:02 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:02 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=NSc4thXnvE5RCxPeAsp832BlLabe1ZKpsXgS+IeX9Z0=;
	b=BP+YXbKDBDx20sI+sIlHLoHeh0jnQzn36P49MUGYkL5X+TnhWrYx1kp09IO+ljzj8l
	/MQhZ1Mu+We1mb0PWlttFbypJz+B31baF/4qGaRHv9iSYVjUCSxEdO2n7uB+ln/RBrEE
	EbaqvJYVnXY9oyYqNc0C/5v5JFmiwNBJ5hmRLwOtqqHFbHrgKUV6FDo1/IsUKM8imCtn
	m8cfQaYRx029viH/tObQzATuYondpI9d0/5krBjt43b+fbXt0GkXwx5/tZneYvpS+/w+
	PAquNjvc+ZVmaey1lP717CFaNGlvXmvC/0DSUpFM3ihPHUlifPc5eTbYv8kM71Y2r2pw
	dBZg==
Received: by 10.213.32.65 with SMTP id b1mr946821ebd.285.1334150882422;
	Wed, 11 Apr 2012 06:28:02 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.27.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:01 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1f4b55806de9e7109ff6fce14c06c67cb585f17c
Message-Id: <1f4b55806de9e7109ff6.1334150274@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:54 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the scheduler
 know about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Basic idea is: cpu-affinity tells where a vcpu can run,
while node-affinity tells where (in terms of on what NUMA nodes,
but that of course imply a set of CPUs) all the vcpus of the
domain should/prefer to run... Problems starts when you have
both of them speaking at the same time!

Respecting vcpu-affinity should remain the primary concern, thus
what we do here is add some two-step logic here and there in the
scheduler (i.e., where vcpu-affinity related decisions are being
undertaken). During the first step, we check the `&&` of vcpu and
node affinity masks, aiming at giving some precedence to the CPUs
that are both suitable and preferrable for the domain. However,
if that fails in finding a valid CPU, the node-affinity is just
ignored and, in the second step, we just fallback to vcpu-affinity,
as the original behaviour was.

Both the introduced overhead and the benefits this provides has
to be investigated and compared against each other, possibly in
varying conditions and running different workloads.

Finally, although still at the RFC level, efforts have been made
to write the code in a flexible enough fashion so that, if we
ever want to introduce further balancing steps, it shouldn't be
too much of a pain.

TODO: * Better investigate and test interactions with cpupools.
      * Test, verify and benchmark. Then test, verify and benchmark
        again, and again and again. What I know as of know is that
        it does not explode that easily, but whether it works properly
        and, more important, brings any benefit, this has to be
        proven (and yes, I'm out running these tests and benchs already,
        but do not esitate to manifest your will for helping with
        that :-D).
      * Add some counter/stats, e.g., to serve the purpose outlined
        right above.

XXX I'm benchmarking this just right now, and peeking at the results
    they don't seem too bad. Numbers are mostly close to the case where
    the VM is already pinned to a node when created. I'll post the
    results as soon as I can, and I'll be happy to investigate any issue,
    if you feel like the approach could be the right one.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -117,6 +117,8 @@ will run on cpus 2 and 3).
 List of the NUMA nodes of the host the guest should be considered
 `affine` with. Being affine to a (set of) NUMA node(s) mainly means
 the guest's memory is going to be allocated on those node(s).
+Also, the scheduler will prefer (but not force) running the guest's
+vcpus on the cpus of the affine node(s).
 
 A list of nodes should be specified as follows: `nodes=["0", "3"]`
 for the guest to be affine with nodes 0 and 3.
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -101,6 +101,15 @@
 
 
 /*
+ * Node Balancing
+ */
+#define CSCHED_BALANCE_NODE_AFFINITY    1
+#define CSCHED_BALANCE_CPU_AFFINITY     0
+#define CSCHED_BALANCE_START_STEP       CSCHED_BALANCE_NODE_AFFINITY
+#define CSCHED_BALANCE_END_STEP         CSCHED_BALANCE_CPU_AFFINITY
+
+
+/*
  * Boot parameters
  */
 static bool_t __read_mostly sched_credit_default_yield;
@@ -150,6 +159,17 @@ struct csched_dom {
     struct list_head active_vcpu;
     struct list_head active_sdom_elem;
     struct domain *dom;
+    /*
+     * Let's cache domain's dom->node_affinity here as an
+     * optimization for a couple of hot paths. In fact,
+     * knowing  whether or not dom->node_affinity has changed
+     * would allow us to avoid rebuilding node_affinity_cpumask
+     * (below) duing node balancing and/or scheduling.
+     */
+    nodemask_t node_affinity_cache;
+    /* Basing on what dom->node_affinity says,
+     * on what CPUs would we like to run most? */
+    cpumask_t node_affinity_cpumask;
     uint16_t active_vcpu_count;
     uint16_t weight;
     uint16_t cap;
@@ -230,6 +250,87 @@ static inline void
     list_del_init(&svc->runq_elem);
 }
 
+#define csched_balance(__step) \
+    for ( (__step) = CSCHED_BALANCE_START_STEP; \
+          (__step) >= CSCHED_BALANCE_END_STEP; \
+          (__step)-- )
+
+/*
+ * Sort-of conversion between node-affinity and vcpu-affinity for the domain,
+ * i.e., a cpumask containing all the cpus from all the set nodes in the
+ * node-affinity mask of the domain.
+ *
+ * Notice that we completely forget about serializing this (both here and
+ * in the various sites where node_affinity_cpumask is used) against
+ * d->node_affinity_lock. That would be hard to do properly, as that lock
+ * is a non IRQ-safe one, and it would be nearly impossible to access it
+ * from the scheduling code. However, although this leaves some room for
+ * races with code paths that updates d->node_affinity, it all should still
+ * be fine, considering:
+ *  (1) d->node_affinity updates are going to be quite rare;
+ *  (2) this balancing logic is kind-of "best effort" anyway;
+ *  (3) given (1), any inconsistencies are likely to be fixed by the next
+ *      call to this same function without risking going into instability.
+ *
+ * XXX Validate (via testing/benchmarking) whether this is true, as it
+ *     likely sounds to be, or it causes unexpected issues.
+ */
+static void
+csched_build_balance_cpumask(struct csched_dom *sdom)
+{
+    struct domain *d = sdom->dom;
+    int node;
+
+    /* Check whether we need to refresh the node-affinity cache we keep */
+    if ( likely(nodes_equal(d->node_affinity, sdom->node_affinity_cache)) )
+        return;
+    else
+        nodes_copy(sdom->node_affinity_cache, sdom->dom->node_affinity);
+
+    /* Create the cpumask matching the current node-affinity mask */
+    cpumask_clear(&sdom->node_affinity_cpumask);
+    for_each_node_mask( node, sdom->node_affinity_cache )
+        cpumask_or(&sdom->node_affinity_cpumask, &sdom->node_affinity_cpumask,
+                   &node_to_cpumask(node));
+}
+
+/* Put together the cpumask we are going to use for this balancing step */
+static int
+csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
+{
+    struct domain *d = vc->domain;
+    struct csched_dom *sdom = CSCHED_DOM(d);
+
+    /*
+     * Only two possible steps exists for now: node and vcpu affinity.
+     * If this domain does not have a node-affinity or is affine to all the
+     * nodes, just return th vcpu-affinity mask (for *this* vcpu) and
+     * stop the balancing process.
+     */
+    if ( !d->has_node_affinity || nodes_full(d->node_affinity) ||
+         step == CSCHED_BALANCE_CPU_AFFINITY )
+    {
+        cpumask_copy(mask, vc->cpu_affinity);
+        return CSCHED_BALANCE_CPU_AFFINITY;
+    }
+
+    csched_build_balance_cpumask(sdom);
+
+    /*
+     * XXX As of now (with only two possible steps, this is easy and readable
+     *     enough. If more steps become necessary at some point in time, we
+     *     can keep an array of cpumask_t in dom_data and return the proper
+     *     element via step-indexing such an array. Of course, we can turn
+     *     this like that even right now... Thoughts?
+     */
+    if ( step == CSCHED_BALANCE_NODE_AFFINITY )
+        cpumask_and(mask, &sdom->node_affinity_cpumask, vc->cpu_affinity);
+    else
+        cpumask_copy(mask, vc->cpu_affinity);
+
+    return step;
+}
+
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
@@ -252,6 +353,20 @@ boolean_param("tickle_one_idle_cpu", opt
 DEFINE_PER_CPU(unsigned int, last_tickle_cpu);
 
 static inline void
+__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask)
+{
+    CSCHED_STAT_CRANK(tickle_idlers_some);
+    if ( opt_tickle_one_idle )
+    {
+        this_cpu(last_tickle_cpu) = 
+            cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask);
+        cpumask_set_cpu(this_cpu(last_tickle_cpu), mask);
+    }
+    else
+        cpumask_or(mask, mask, idle_mask);
+}
+
+static inline void
 __runq_tickle(unsigned int cpu, struct csched_vcpu *new)
 {
     struct csched_vcpu * const cur =
@@ -289,22 +404,27 @@ static inline void
         }
         else
         {
-            cpumask_t idle_mask;
+            cpumask_t idle_mask, balance_mask;
+            int balance_step;
 
-            cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
-            if ( !cpumask_empty(&idle_mask) )
+            csched_balance(balance_step)
             {
-                CSCHED_STAT_CRANK(tickle_idlers_some);
-                if ( opt_tickle_one_idle )
-                {
-                    this_cpu(last_tickle_cpu) = 
-                        cpumask_cycle(this_cpu(last_tickle_cpu), &idle_mask);
-                    cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
-                }
-                else
-                    cpumask_or(&mask, &mask, &idle_mask);
+                /*
+                 * A each balancing step, look for any idler in the poper
+                 * affinity mask for the step itself (for new->vcpu).
+                 */
+                csched_balance_cpumask(new->vcpu, balance_step, &balance_mask);
+                cpumask_and(&idle_mask, prv->idlers, &balance_mask);
+
+                if ( !cpumask_empty(&idle_mask) )
+                    __cpumask_tickle(&mask, &idle_mask);
+
+                cpumask_and(&mask, &mask, &balance_mask);
+
+                /* We can quit balancing if we found someone to tickle */
+                if ( !cpumask_empty(&mask) )
+                    break;
             }
-            cpumask_and(&mask, &mask, new->vcpu->cpu_affinity);
         }
     }
 
@@ -445,7 +565,7 @@ static inline int
 }
 
 static inline int
-__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu)
+__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu, cpumask_t *mask)
 {
     /*
      * Don't pick up work that's in the peer's scheduling tail or hot on
@@ -453,27 +573,37 @@ static inline int
      */
     return !vc->is_running &&
            !__csched_vcpu_is_cache_hot(vc) &&
-           cpumask_test_cpu(dest_cpu, vc->cpu_affinity);
+           cpumask_test_cpu(dest_cpu, mask);
 }
 
 static int
 _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t commit)
 {
-    cpumask_t cpus;
+    cpumask_t cpus, start_cpus;
     cpumask_t idlers;
     cpumask_t *online;
+    struct csched_dom *sdom = CSCHED_DOM(vc->domain);
     struct csched_pcpu *spc = NULL;
     int cpu;
 
+    csched_build_balance_cpumask(sdom);
+
     /*
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
+     *
+     * It's worth tying to take balancing into account,
+     * at least for selecting from which cpu to start looking
+     * around from. XXX ... Or is this going to be too much?
      */
     online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
-    cpu = cpumask_test_cpu(vc->processor, &cpus)
+    cpumask_and(&start_cpus, &cpus, &sdom->node_affinity_cpumask);
+    if ( unlikely(cpumask_empty(&start_cpus)) )
+        cpumask_copy(&start_cpus, &cpus);
+    cpu = cpumask_test_cpu(vc->processor, &start_cpus)
             ? vc->processor
-            : cpumask_cycle(vc->processor, &cpus);
+            : cpumask_cycle(vc->processor, &start_cpus);
     ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) );
 
     /*
@@ -877,6 +1007,14 @@ csched_alloc_domdata(const struct schedu
     sdom->active_vcpu_count = 0;
     INIT_LIST_HEAD(&sdom->active_sdom_elem);
     sdom->dom = dom;
+    /*
+     *XXX This would be 'The Right Thing', but as it is still too
+     *    early and d->node_affinity has not settled yet, maybe we
+     *    can just init the two masks with something like all-nodes
+     *    and all-cpus and rely on the first balancing call for
+     *    having them updated?
+     */
+    csched_build_balance_cpumask(sdom);
     sdom->weight = CSCHED_DEFAULT_WEIGHT;
     sdom->cap = 0U;
 
@@ -1216,30 +1354,54 @@ csched_runq_steal(int peer_cpu, int cpu,
      */
     if ( peer_pcpu != NULL && !is_idle_vcpu(peer_vcpu) )
     {
-        list_for_each( iter, &peer_pcpu->runq )
+        int balance_step;
+
+        /*
+         * Idea here is trying take NUMA affinity (if any) into account.
+         * While at it, try to be general enough, exploiting the balancing
+         * infrastructure as follows:
+         *  - we act in steps (two for now: node and vcpu affinity);
+         *  - at each step we check each item of peer_pcpu's runq
+         *    looking for a candidate vcpu against the proper CPU
+         *    mask, depending on the step itself;
+         *  - masks are (should be!) checked in order of preference,
+         *    as a match will cause the end of the balancing process;
+         *  - a preferred mask should not contain any 'illegal' CPU(s)
+         *    (wrt to, e.g., the domain's 'cpu_affinity', if any), as
+         *    this might cause the vcpu to be shipped there!
+         */
+        csched_balance(balance_step)
         {
-            speer = __runq_elem(iter);
+            list_for_each( iter, &peer_pcpu->runq )
+            {
+                cpumask_t balance_mask;
 
-            /*
-             * If next available VCPU here is not of strictly higher
-             * priority than ours, this PCPU is useless to us.
-             */
-            if ( speer->pri <= pri )
-                break;
+                speer = __runq_elem(iter);
 
-            /* Is this VCPU is runnable on our PCPU? */
-            vc = speer->vcpu;
-            BUG_ON( is_idle_vcpu(vc) );
+                /*
+                 * If next available VCPU here is not of strictly higher
+                 * priority than ours, this PCPU is useless to us.
+                 */
+                if ( speer->pri <= pri )
+                    break;
 
-            if (__csched_vcpu_is_migrateable(vc, cpu))
-            {
-                /* We got a candidate. Grab it! */
-                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
-                CSCHED_STAT_CRANK(migrate_queued);
-                WARN_ON(vc->is_urgent);
-                __runq_remove(speer);
-                vc->processor = cpu;
-                return speer;
+                /* Is this VCPU is runnable on our PCPU? */
+                vc = speer->vcpu;
+                BUG_ON( is_idle_vcpu(vc) );
+
+                balance_step = csched_balance_cpumask(vc, balance_step,
+                                                      &balance_mask);
+
+                if (__csched_vcpu_is_migrateable(vc, cpu, &balance_mask))
+                {
+                    /* We got a candidate. Grab it! */
+                    CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
+                    CSCHED_STAT_CRANK(migrate_queued);
+                    WARN_ON(vc->is_urgent);
+                    __runq_remove(speer);
+                    vc->processor = cpu;
+                    return speer;
+                }
             }
         }
     }
diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
--- a/xen/include/xen/nodemask.h
+++ b/xen/include/xen/nodemask.h
@@ -195,6 +195,13 @@ static inline int __nodes_weight(const n
 	return bitmap_weight(srcp->bits, nbits);
 }
 
+#define nodes_copy(dst, src) __nodes_copy(&(dst), &(src), MAX_NUMNODES)
+static inline void __nodes_copy(nodemask_t *dstp,
+				const nodemask_t *srcp, int nbits)
+{
+	bitmap_copy(dstp->bits, srcp->bits, nbits);
+}
+
 #define nodes_shift_right(dst, src, n) \
 			__nodes_shift_right(&(dst), &(src), (n), MAX_NUMNODES)
 static inline void __nodes_shift_right(nodemask_t *dstp,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxal-0001v7-S4; Wed, 11 Apr 2012 13:28:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxak-0001tZ-4n
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:10 +0000
Received: from [85.158.139.83:4331] by server-6.bemta-5.messagelabs.com id
	76/C3-13222-9E6858F4; Wed, 11 Apr 2012 13:28:09 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!6
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25794 invoked from network); 11 Apr 2012 13:28:08 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:08 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=ciCp/74opAZjYhvt/W/P7lJMqcaCEfTY03CA83MiAaM=;
	b=FLmierYpDQONKFnGnJNJwx0Qle92VIynfbI7IR3DHhUGtn5Lg2nWbSkIQ+nVZgSx5t
	ZziGm4maZJd2UGPMyEyBpL0SRGpa85Mn4LC3XTyeT3fFZYd0GXS7Qm8o3TybDtrnYbpv
	s7BtDJ2XSWLjO7pLE6Am5/qI6dv1Yu7ppjqEaZY4iuMWf7CgdzUoOn3oO0BHmpV7RbJJ
	z8mL1zzfLn/2Ya8RuMx2H89jCMkoMvt5Lfqplkt2MWX99GvVF7vpgYplAGjcG4E5uGjo
	jylHv/eiLrkmyCv9JD8OE66qbm71yOxfYFHAk2egN+igMBKJNgG+VTE5BHJM+Xse1w7W
	KNgg==
Received: by 10.14.28.76 with SMTP id f52mr1918309eea.117.1334150888037;
	Wed, 11 Apr 2012 06:28:08 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.28.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:06 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 62ef1186c24b850cbc1c40f554f507bf9304d317
Message-Id: <62ef1186c24b850cbc1c.1334150276@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:56 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 09 of 10 [RFC]] xl: Introduce Best and Worst Fit
 guest placement algorithms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Besides than "auto" and "ffit", as per the previous patch, enable
Best and Worst Fit placement heuristics to `xl`, for the user to
chose them in the config file. Implementation just sits on top
of the First Fit algorithm code, with just the proper reordering
of the nodes and their free memory before invoking it (and after
it finishes).

TODO: * As usual for this series, benchmarking and testing,
        as much thorough and comprehensive as possible!

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -146,6 +146,16 @@ to try automatically fitting the guest o
 use the First Fit algorithm to try automatically fitting the
 guest on the host's NUMA nodes
 
+=item B<bfit>
+
+use the Best Fit algorithm to try automatically fitting the
+guest on the host's NUMA nodes
+
+=item B<wfit>
+
+use the Worst Fit algorithm to try automatically fitting the
+guest on the host's NUMA nodes
+
 =back
 
 This option interacts with `nodes=` such that, if the number of
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -117,6 +117,8 @@ static const char *action_on_shutdown_na
  *  NONE   : no automatic placement at all;
  *  STATIC : explicit nodes specification.
  *  FFIT   : use the First Fit algorithm for automatic placement;
+ *  BFIT   : use the Best Fit algorithm for automatic placement;
+ *  WFIT   : use the Worst Fit algorithm for automatic placement;
  *  AUTO   : an not better specified automatic placement, likely
  *           to be implemented as a short circuit to (one of)
  *           the above(s);
@@ -124,7 +126,9 @@ static const char *action_on_shutdown_na
 #define NODES_POLICY_NONE    0
 #define NODES_POLICY_STATIC  1
 #define NODES_POLICY_FFIT    2
-#define NODES_POLICY_AUTO    3
+#define NODES_POLICY_BFIT    3
+#define NODES_POLICY_WFIT    4
+#define NODES_POLICY_AUTO    5
 
 /* Default behaviour wrt to automatic domain placement on nodes,
  * maximum number of attempts made for applying the desired
@@ -153,6 +157,8 @@ static const char *nodes_policy_names[] 
     [NODES_POLICY_NONE]   = "none",
     [NODES_POLICY_STATIC] = "static",
     [NODES_POLICY_FFIT]   = "ffit",
+    [NODES_POLICY_BFIT]   = "bfit",
+    [NODES_POLICY_WFIT]   = "wfit",
     [NODES_POLICY_AUTO]   = "auto",
 };
 
@@ -595,10 +601,17 @@ static inline void __add_nodes_to_nodema
 /*
  * First Fit automatic placement. Just scan all the nodes in the
  * provided map (@nodemap) linearly and pick up the fist @nodes
- * that fit the memory requirements (@memkb) of the domain.
+ * that fit the memory requirements (@memb) of the domain.
  * This also returns the actual number of used nodes (still via
  * @nodes) and the actual nodes map to be used (still via @nodemap),
  * as they both can change depending on the retry policy (@retry).
+ *
+ * The idea behing First Fit is to be efficient and quick, and it
+ * generally works better than Best Fit wrt fragmentation, although
+ * it tends to occupy "early" nodes more than "late" ones.
+ *
+ * This function is also used as the ground for implementing Best
+ * and Worst Fit placement solutions too.
  */
 static int place_domain_ffit(const libxl_numainfo *numa, uint64_t memb,
                              int retry, int nr_nodes, int *nodes,
@@ -678,6 +691,133 @@ static int place_domain_ffit(const libxl
     return rc;
 }
 
+typedef struct {
+    int idx;
+    uint32_t memfree;
+} numa_reorderer;
+
+typedef int (*reorderer_cmp)(const void *, const void *);
+
+static int reorderer_cmp_asc(const void *r1,
+                             const void *r2)
+{
+    return ((const numa_reorderer*) r1)->memfree -
+        ((const numa_reorderer*) r2)->memfree;
+}
+
+/* Turns the comparison the other way around for descending ordering */
+static int reorderer_cmp_desc(const void *r1,
+                              const void *r2)
+{
+    return ((const numa_reorderer*) r2)->memfree -
+        ((const numa_reorderer*) r1)->memfree;
+}
+
+static int __place_domain_bw_fit(const libxl_numainfo *numa, uint64_t memb,
+                                 int retry, int nr_nodes, int *nodes,
+                                 libxl_nodemap *nodemap, reorderer_cmp cmpr)
+{
+    numa_reorderer *n;
+    libxl_numainfo *numa_ord;
+    libxl_nodemap nodemap_ord;
+    int i, rc;
+
+    n = malloc(sizeof(*n) * nr_nodes);
+    if (!n) {
+        fprintf(stderr, "malloc failed\n");
+        return ENOMEM;
+    }
+    numa_ord = malloc(sizeof(*numa) * nr_nodes);
+    if (!numa_ord) {
+        fprintf(stderr, "malloc failed\n");
+        rc = ENOMEM;
+        goto out_n;
+    }
+    if (libxl_nodemap_alloc(ctx, &nodemap_ord) < 0) {
+        fprintf(stderr, "libxl_nodemap_alloc failed\n");
+        rc = ENOMEM;
+        goto out_numaord;
+    }
+
+    /* Initialize the reordering structure so that we can
+     * 'sort' the idx basing on the values of memfree, and
+     * thus have the full trace of the permutations applied
+     * by the sorting algorithm. */
+    for (i = 0; i < nr_nodes; i++) {
+        n[i].idx = i;
+        n[i].memfree = numa[i].free;
+   } 
+
+    qsort(n, nr_nodes, sizeof(*n), cmpr);
+
+    /* Apply the permutation to the numainfo array as
+     * well as to the nodemap. */
+    for (i = 0; i < nr_nodes; i++) {
+        numa_ord[i] = numa[n[i].idx];
+        if (libxl_nodemap_test(nodemap, n[i].idx))
+            libxl_nodemap_set(&nodemap_ord, i);
+    }
+
+    /* Now let First Fit do his job on the ordered data */
+    rc = place_domain_ffit(numa_ord, memb, retry, nr_nodes,
+                           nodes, &nodemap_ord);
+
+    /* `Rollback` the permutation of the node map */
+    libxl_nodemap_set_none(nodemap);
+    for (i = 0; i < nr_nodes; i++) {
+        if (libxl_nodemap_test(&nodemap_ord, i))
+            libxl_nodemap_set(nodemap, n[i].idx);
+    }
+
+    libxl_nodemap_dispose(&nodemap_ord);
+out_numaord:
+    free(numa_ord);
+out_n:
+    free(n);
+
+    return rc;
+}
+
+/* Best Fit automatic placement. It will (try to) find the node(s)
+ * with the smallest possible amount of free memory that also satisfies
+ * the domain memory requirements (@memb).
+ *
+ * The idea behing Best Fit is to optimize memory usage, although it
+ * might introduce quite a bit of fragmentation, by leaving a large
+ * amount of small free areas.
+ *
+ * This is easily implemented by sorting the nodes array in
+ * ascending order (of free memory on each node) and then
+ * asking First Fit to run on the now-ordered data.
+ */
+static int place_domain_bfit(const libxl_numainfo *numa, uint64_t memb,
+                             int retry, int nr_nodes, int *nodes,
+                             libxl_nodemap *nodemap)
+{
+    return __place_domain_bw_fit(numa, memb, retry, nr_nodes,
+                                 nodes, nodemap, reorderer_cmp_asc);
+}
+
+/* Worst Fit automatic placement. It will (try to) find the node(s)
+ * with the highest possible amount of free memory that also satisfies
+ * domain memory requirements (@memb).
+ *
+ * The idea behind Worst Fit is that it will leave big enough free
+ * memory areas to limit the amount of fragmentation, especially
+ * compared to Best Fit.
+ *
+ * This is easily implemented by sorting the nodes array in
+ * ascending order (of free memory on each node) and then
+ * asking First Fit to run on the now-ordered data.
+ */
+static int place_domain_wfit(const libxl_numainfo *numa, uint64_t memb,
+                             int retry, int nr_nodes, int *nodes,
+                             libxl_nodemap *nodemap)
+{
+    return __place_domain_bw_fit(numa, memb, retry, nr_nodes,
+                                 nodes, nodemap, reorderer_cmp_desc);
+}
+
 /* Try to achieve optimal node-affinity for the domain */
 static int place_domain(libxl_domain_build_info *b_info)
 {
@@ -804,6 +944,16 @@ static int place_domain(libxl_domain_bui
                                    retry_policy, nr_nodes, &use_nodes,
                                    &new_nodemap);
             break;
+        case NODES_POLICY_BFIT:
+            rc = place_domain_bfit(numa, (uint64_t) need_memkb * 1024,
+                                   retry_policy, nr_nodes, &use_nodes,
+                                   &new_nodemap);
+            break;
+        case NODES_POLICY_WFIT:
+            rc = place_domain_wfit(numa, (uint64_t) need_memkb * 1024,
+                                   retry_policy, nr_nodes, &use_nodes,
+                                   &new_nodemap);
+            break;
         }
 
         if (rc)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxal-0001v7-S4; Wed, 11 Apr 2012 13:28:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxak-0001tZ-4n
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:10 +0000
Received: from [85.158.139.83:4331] by server-6.bemta-5.messagelabs.com id
	76/C3-13222-9E6858F4; Wed, 11 Apr 2012 13:28:09 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334150864!22813013!6
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25794 invoked from network); 11 Apr 2012 13:28:08 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:08 -0000
Received: by mail-ee0-f45.google.com with SMTP id t10so239338eei.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=ciCp/74opAZjYhvt/W/P7lJMqcaCEfTY03CA83MiAaM=;
	b=FLmierYpDQONKFnGnJNJwx0Qle92VIynfbI7IR3DHhUGtn5Lg2nWbSkIQ+nVZgSx5t
	ZziGm4maZJd2UGPMyEyBpL0SRGpa85Mn4LC3XTyeT3fFZYd0GXS7Qm8o3TybDtrnYbpv
	s7BtDJ2XSWLjO7pLE6Am5/qI6dv1Yu7ppjqEaZY4iuMWf7CgdzUoOn3oO0BHmpV7RbJJ
	z8mL1zzfLn/2Ya8RuMx2H89jCMkoMvt5Lfqplkt2MWX99GvVF7vpgYplAGjcG4E5uGjo
	jylHv/eiLrkmyCv9JD8OE66qbm71yOxfYFHAk2egN+igMBKJNgG+VTE5BHJM+Xse1w7W
	KNgg==
Received: by 10.14.28.76 with SMTP id f52mr1918309eea.117.1334150888037;
	Wed, 11 Apr 2012 06:28:08 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.28.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:06 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 62ef1186c24b850cbc1c40f554f507bf9304d317
Message-Id: <62ef1186c24b850cbc1c.1334150276@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:56 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 09 of 10 [RFC]] xl: Introduce Best and Worst Fit
 guest placement algorithms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Besides than "auto" and "ffit", as per the previous patch, enable
Best and Worst Fit placement heuristics to `xl`, for the user to
chose them in the config file. Implementation just sits on top
of the First Fit algorithm code, with just the proper reordering
of the nodes and their free memory before invoking it (and after
it finishes).

TODO: * As usual for this series, benchmarking and testing,
        as much thorough and comprehensive as possible!

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -146,6 +146,16 @@ to try automatically fitting the guest o
 use the First Fit algorithm to try automatically fitting the
 guest on the host's NUMA nodes
 
+=item B<bfit>
+
+use the Best Fit algorithm to try automatically fitting the
+guest on the host's NUMA nodes
+
+=item B<wfit>
+
+use the Worst Fit algorithm to try automatically fitting the
+guest on the host's NUMA nodes
+
 =back
 
 This option interacts with `nodes=` such that, if the number of
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -117,6 +117,8 @@ static const char *action_on_shutdown_na
  *  NONE   : no automatic placement at all;
  *  STATIC : explicit nodes specification.
  *  FFIT   : use the First Fit algorithm for automatic placement;
+ *  BFIT   : use the Best Fit algorithm for automatic placement;
+ *  WFIT   : use the Worst Fit algorithm for automatic placement;
  *  AUTO   : an not better specified automatic placement, likely
  *           to be implemented as a short circuit to (one of)
  *           the above(s);
@@ -124,7 +126,9 @@ static const char *action_on_shutdown_na
 #define NODES_POLICY_NONE    0
 #define NODES_POLICY_STATIC  1
 #define NODES_POLICY_FFIT    2
-#define NODES_POLICY_AUTO    3
+#define NODES_POLICY_BFIT    3
+#define NODES_POLICY_WFIT    4
+#define NODES_POLICY_AUTO    5
 
 /* Default behaviour wrt to automatic domain placement on nodes,
  * maximum number of attempts made for applying the desired
@@ -153,6 +157,8 @@ static const char *nodes_policy_names[] 
     [NODES_POLICY_NONE]   = "none",
     [NODES_POLICY_STATIC] = "static",
     [NODES_POLICY_FFIT]   = "ffit",
+    [NODES_POLICY_BFIT]   = "bfit",
+    [NODES_POLICY_WFIT]   = "wfit",
     [NODES_POLICY_AUTO]   = "auto",
 };
 
@@ -595,10 +601,17 @@ static inline void __add_nodes_to_nodema
 /*
  * First Fit automatic placement. Just scan all the nodes in the
  * provided map (@nodemap) linearly and pick up the fist @nodes
- * that fit the memory requirements (@memkb) of the domain.
+ * that fit the memory requirements (@memb) of the domain.
  * This also returns the actual number of used nodes (still via
  * @nodes) and the actual nodes map to be used (still via @nodemap),
  * as they both can change depending on the retry policy (@retry).
+ *
+ * The idea behing First Fit is to be efficient and quick, and it
+ * generally works better than Best Fit wrt fragmentation, although
+ * it tends to occupy "early" nodes more than "late" ones.
+ *
+ * This function is also used as the ground for implementing Best
+ * and Worst Fit placement solutions too.
  */
 static int place_domain_ffit(const libxl_numainfo *numa, uint64_t memb,
                              int retry, int nr_nodes, int *nodes,
@@ -678,6 +691,133 @@ static int place_domain_ffit(const libxl
     return rc;
 }
 
+typedef struct {
+    int idx;
+    uint32_t memfree;
+} numa_reorderer;
+
+typedef int (*reorderer_cmp)(const void *, const void *);
+
+static int reorderer_cmp_asc(const void *r1,
+                             const void *r2)
+{
+    return ((const numa_reorderer*) r1)->memfree -
+        ((const numa_reorderer*) r2)->memfree;
+}
+
+/* Turns the comparison the other way around for descending ordering */
+static int reorderer_cmp_desc(const void *r1,
+                              const void *r2)
+{
+    return ((const numa_reorderer*) r2)->memfree -
+        ((const numa_reorderer*) r1)->memfree;
+}
+
+static int __place_domain_bw_fit(const libxl_numainfo *numa, uint64_t memb,
+                                 int retry, int nr_nodes, int *nodes,
+                                 libxl_nodemap *nodemap, reorderer_cmp cmpr)
+{
+    numa_reorderer *n;
+    libxl_numainfo *numa_ord;
+    libxl_nodemap nodemap_ord;
+    int i, rc;
+
+    n = malloc(sizeof(*n) * nr_nodes);
+    if (!n) {
+        fprintf(stderr, "malloc failed\n");
+        return ENOMEM;
+    }
+    numa_ord = malloc(sizeof(*numa) * nr_nodes);
+    if (!numa_ord) {
+        fprintf(stderr, "malloc failed\n");
+        rc = ENOMEM;
+        goto out_n;
+    }
+    if (libxl_nodemap_alloc(ctx, &nodemap_ord) < 0) {
+        fprintf(stderr, "libxl_nodemap_alloc failed\n");
+        rc = ENOMEM;
+        goto out_numaord;
+    }
+
+    /* Initialize the reordering structure so that we can
+     * 'sort' the idx basing on the values of memfree, and
+     * thus have the full trace of the permutations applied
+     * by the sorting algorithm. */
+    for (i = 0; i < nr_nodes; i++) {
+        n[i].idx = i;
+        n[i].memfree = numa[i].free;
+   } 
+
+    qsort(n, nr_nodes, sizeof(*n), cmpr);
+
+    /* Apply the permutation to the numainfo array as
+     * well as to the nodemap. */
+    for (i = 0; i < nr_nodes; i++) {
+        numa_ord[i] = numa[n[i].idx];
+        if (libxl_nodemap_test(nodemap, n[i].idx))
+            libxl_nodemap_set(&nodemap_ord, i);
+    }
+
+    /* Now let First Fit do his job on the ordered data */
+    rc = place_domain_ffit(numa_ord, memb, retry, nr_nodes,
+                           nodes, &nodemap_ord);
+
+    /* `Rollback` the permutation of the node map */
+    libxl_nodemap_set_none(nodemap);
+    for (i = 0; i < nr_nodes; i++) {
+        if (libxl_nodemap_test(&nodemap_ord, i))
+            libxl_nodemap_set(nodemap, n[i].idx);
+    }
+
+    libxl_nodemap_dispose(&nodemap_ord);
+out_numaord:
+    free(numa_ord);
+out_n:
+    free(n);
+
+    return rc;
+}
+
+/* Best Fit automatic placement. It will (try to) find the node(s)
+ * with the smallest possible amount of free memory that also satisfies
+ * the domain memory requirements (@memb).
+ *
+ * The idea behing Best Fit is to optimize memory usage, although it
+ * might introduce quite a bit of fragmentation, by leaving a large
+ * amount of small free areas.
+ *
+ * This is easily implemented by sorting the nodes array in
+ * ascending order (of free memory on each node) and then
+ * asking First Fit to run on the now-ordered data.
+ */
+static int place_domain_bfit(const libxl_numainfo *numa, uint64_t memb,
+                             int retry, int nr_nodes, int *nodes,
+                             libxl_nodemap *nodemap)
+{
+    return __place_domain_bw_fit(numa, memb, retry, nr_nodes,
+                                 nodes, nodemap, reorderer_cmp_asc);
+}
+
+/* Worst Fit automatic placement. It will (try to) find the node(s)
+ * with the highest possible amount of free memory that also satisfies
+ * domain memory requirements (@memb).
+ *
+ * The idea behind Worst Fit is that it will leave big enough free
+ * memory areas to limit the amount of fragmentation, especially
+ * compared to Best Fit.
+ *
+ * This is easily implemented by sorting the nodes array in
+ * ascending order (of free memory on each node) and then
+ * asking First Fit to run on the now-ordered data.
+ */
+static int place_domain_wfit(const libxl_numainfo *numa, uint64_t memb,
+                             int retry, int nr_nodes, int *nodes,
+                             libxl_nodemap *nodemap)
+{
+    return __place_domain_bw_fit(numa, memb, retry, nr_nodes,
+                                 nodes, nodemap, reorderer_cmp_desc);
+}
+
 /* Try to achieve optimal node-affinity for the domain */
 static int place_domain(libxl_domain_build_info *b_info)
 {
@@ -804,6 +944,16 @@ static int place_domain(libxl_domain_bui
                                    retry_policy, nr_nodes, &use_nodes,
                                    &new_nodemap);
             break;
+        case NODES_POLICY_BFIT:
+            rc = place_domain_bfit(numa, (uint64_t) need_memkb * 1024,
+                                   retry_policy, nr_nodes, &use_nodes,
+                                   &new_nodemap);
+            break;
+        case NODES_POLICY_WFIT:
+            rc = place_domain_wfit(numa, (uint64_t) need_memkb * 1024,
+                                   retry_policy, nr_nodes, &use_nodes,
+                                   &new_nodemap);
+            break;
         }
 
         if (rc)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaj-0001tO-FB; Wed, 11 Apr 2012 13:28:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxah-0001rd-UC
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:08 +0000
Received: from [85.158.143.35:58846] by server-1.bemta-4.messagelabs.com id
	55/5F-20925-7E6858F4; Wed, 11 Apr 2012 13:28:07 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!4
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29097 invoked from network); 11 Apr 2012 13:28:05 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:05 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=0slfY2qddbhSUy32r9GSxeem+x3mVX17IRAzvhc5jao=;
	b=tXD8SB0zGWAGy9i8aeIlIHxFYZ+pirZyrFIinh4W3MGu3y5tHZDYib8HeTfMBBFpno
	2zwAPmq69stVsZ/afXgt3B+4MitkbvoFjkPlkkhbd/IArHyHakjwDKfieGdomufqKIkq
	tFIi7bTcEFuxniPdbX2L91KJqUVZP47yFNvpEgzjeVCviWuL407S7zw8L+sQgJH11poy
	BZMNhW7GqFjq3YYw0TpAvM+IUZRenl27rzoh61e+cBWFSChMqhkgFfkOy18suR2hTfM1
	01r07jm4hjja2L2yJ++TRlqRra/VmJ8hgn8nN/XVZl8u+ZjOE/9XiZ7BCCOQ0kbI3/DY
	ddeg==
Received: by 10.14.204.3 with SMTP id g3mr1906073eeo.75.1334150885375;
	Wed, 11 Apr 2012 06:28:05 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.28.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:04 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 31163f014d8a2da9375f7bc02eae0796342e2156
Message-Id: <31163f014d8a2da9375f.1334150275@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:55 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit
 memory-wise placement of guests on nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow the user to ask for automatic placement of a new domain onto
the NUMA nodes of the host. The most important consideration, wrt
to this, definitely is how much free memory we have on the various
nodes vs. how much memory the domain needs, and this is exactly what
is used to drive the algorithm decisions. Some more refinement, e.g.,
adding more factors, like actual load on the CPUs, etc, to the
"equation" can be easily added later.

The placement logic is very simple and it uses the First Fit algorithm.
This basically means the domain is put in the first node (or, perhaps,
set of nodes) with enough free memory. A form of `sanity check' is
performed after the memory-wise placement, to be sure the domain has
at least as much pCPUs available as its vCPUs, and if that is not the
case, more nodes are added to its affinity map.

The user can ask for full automatic placement, in which case the least
possible number of nodes will be used, or provide some hints, such
as how many nodes he wants the domain to be affine to. He can also ask
for a more specific placement (an explicit list of nodes), and the
algorithm will honour that, if possible, or just fail. Finally, if
the user doesn't say anything about node affinity, but the domain has
some vcpu affinity, the algorithm will use that information as a
starting point for placing it.

TODO: * As usual, relationship with cpupools should be better
        both defined and (then) checked.
      * This only takes memory into account, forgetting about how
        busy the CPUs of the various nodes are. Heuristics for
        taking that into account too need to be thought about,
        and proper support for gathering the data they need for
        working (e.g., stats about load on pCPUs?) implemented.
      * This just ignores node distances, as exporting such info
        via libxl would be better when we'll have arrays in the IDL;
        however, spots where such information should be considered
        are clearly identified and marked, so it should be trivial
        to put it in place once we'll have the proper backup.
      * Checking for free memory in `xl' and then allocating it
        to domains in Xen is prone to race conditions. Domain
        creation should be fine, given the current --very coarse--
        locking discipline implemented in `xl' itself, but, for
        instance, nothing protect creation and ballooning from
        running into each other. This affects the present code
        as well (freemem() already checks for free memory in the
        creation process), but can get particularly nasty with
        this changes applied. It needs to be solved somehow...
        Solutions are under consideration.
      * Benchmarks, e.g., something like put a bunch of VM
        on "auto" placement policy and check for some kind of
        aggregate throughput (I'm working on this, in order to
        have it happening by means of the same infrastructure I
        used for producing the results referred to in the #0 mail).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

add-firstfit-automatic-domain-placement.patch

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -122,6 +122,36 @@ vcpus on the cpus of the affine node(s).
 
 A list of nodes should be specified as follows: `nodes=["0", "3"]`
 for the guest to be affine with nodes 0 and 3.
+It is also possible to ask for automatic placement of the guest on
+host nodes by either using `nodes="auto"` or just putting the number
+of nodes the guest should span, e.g., `nodes=2`. In the former case,
+xl will try to make the guest affine with the lowest possible number
+of nodes, in the latter it will try to make it affine to the provided
+number of them.
+
+=item B<nodes_policy="NODE-POLICY">
+
+Allows for better specifying how to automatically set the guest NUMA
+affinity. Available C<NODE-POLICY>-ies are:
+
+=over 4
+
+=item B<auto>
+
+use a not better specified (xl-implementation dependant) algorithm
+to try automatically fitting the guest on the host's NUMA nodes
+
+=item B<ffit>
+
+use the First Fit algorithm to try automatically fitting the
+guest on the host's NUMA nodes
+
+=back
+
+This option interacts with `nodes=` such that, if the number of
+nodes to use is specified there (e.g., `nodes=2`), xl will use
+the specified policy to try  fitting the guest on that exact
+number of NUMA nodes of the host.
 
 =item B<memory=MBYTES>
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -454,6 +454,15 @@ int libxl_map_alloc(libxl_ctx *ctx, stru
     return 0;
 }
 
+static void libxl_map_copy(/*XXX libxl_ctx *ctx, */ struct libxl_map *dptr,
+                          const struct libxl_map *sptr)
+{
+    int sz;
+
+    sz = dptr->size = sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
 int libxl_map_test(struct libxl_map *map, int elem)
 {
     if (elem >= map->size * 8)
@@ -497,6 +506,12 @@ int libxl_nodemap_alloc(libxl_ctx *ctx, 
     return libxl_map_alloc(ctx, nodemap, max_nodes);
 }
 
+void libxl_nodemap_copy(/*XXX libxl_ctx *ctx, */ libxl_nodemap *dst,
+                       const libxl_nodemap *src)
+{
+   libxl_map_copy(/*XXX ctx, */ dst, src);
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -115,6 +115,8 @@ static inline int libxl_cpumap_cpu_valid
                                              if (libxl_cpumap_test(&(m), v))
 
 int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap);
+void libxl_nodemap_copy(/*XXX libxl_ctx *ctx, */ libxl_nodemap *dst,
+                       const libxl_nodemap *src);
 static inline int libxl_nodemap_test(libxl_nodemap *nodemap, int node)
 {
     return libxl_map_test(nodemap, node);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -113,6 +113,55 @@ static const char *action_on_shutdown_na
     [LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART] = "coredump-restart",
 };
 
+/* Automatic placement policies symbols, with the following meaning:
+ *  NONE   : no automatic placement at all;
+ *  STATIC : explicit nodes specification.
+ *  FFIT   : use the First Fit algorithm for automatic placement;
+ *  AUTO   : an not better specified automatic placement, likely
+ *           to be implemented as a short circuit to (one of)
+ *           the above(s);
+ */
+#define NODES_POLICY_NONE    0
+#define NODES_POLICY_STATIC  1
+#define NODES_POLICY_FFIT    2
+#define NODES_POLICY_AUTO    3
+
+/* Default behaviour wrt to automatic domain placement on nodes,
+ * maximum number of attempts made for applying the desired
+ * placement policy and parameters, and of the same for attempts
+ * made for having enough CPUs available to the domain.
+ */
+#define NODES_POLICY_DEFAULT       NODES_POLICY_NONE
+#define NODES_POLICY_FIT_ATTEMPTS  5
+#define NODES_POLICY_VCPU_ATTEMPTS 5
+
+/* Whether, in case it is not possible to fit a domain on
+ * the requested nodes, we should give up (_NO_RETRY), try
+ * to increment (_RETRY_INC), decrement (_RETRY_DEC) or both
+ * (_RETRY_BOTH) the number of nodes.
+ *
+ * XXX Maybe the actual value of _INC and _DEC, as well as
+ *     _DEFAULT and _*_ATTEMPTS above is something we want
+ *     to be configurable, e.g., in xl.conf or alike?
+ */
+#define NODES_POLICY_NO_RETRY   ( 0)
+#define NODES_POLICY_RETRY_INC  (+1)
+#define NODES_POLICY_RETRY_DEC  (-1)
+#define NODES_POLICY_RETRY_BOTH (INT_MAX)
+
+static const char *nodes_policy_names[] = {
+    [NODES_POLICY_NONE]   = "none",
+    [NODES_POLICY_STATIC] = "static",
+    [NODES_POLICY_FFIT]   = "ffit",
+    [NODES_POLICY_AUTO]   = "auto",
+};
+
+/* Store the policy for the domain while parsing */
+static int nodes_policy = NODES_POLICY_DEFAULT;
+
+/* Store the number of nodes to be used while parsing */
+static int num_nodes_policy = 0;
+
 /* Optional data, in order:
  *   4 bytes uint32_t  config file size
  *   n bytes           config file in Unix text file format
@@ -507,6 +556,314 @@ afp_out:
     return rc;
 }
 
+static int nodes_policy_parse(const char *pol, long int *policy)
+{
+    int i;
+    const char *n;
+
+    for (i = 0; i < sizeof(nodes_policy_names) / sizeof(nodes_policy_names[0]); i++) {
+        n = nodes_policy_names[i];
+
+        if (!n) continue;
+
+        if (strcmp(pol, n) == 0) {
+            *policy = i;
+            return 0;
+        }
+    }
+
+    return EINVAL;
+}
+
+static inline void __add_nodes_to_nodemap(libxl_nodemap *nodemap,
+                                          const libxl_numainfo *numa,
+                                          int nr_nodes, int howmany)
+{
+    int i;
+
+    /* XXX Once we have the node-distance information, maybe we can
+     *     use it here in trying to set nodes closer to the ones that
+     *     are already in the map. */ 
+    for (i = 0 ; i < nr_nodes && howmany > 0; i++) {
+        if (!libxl_nodemap_test(nodemap, i) && numa[i].size > 0) {
+            libxl_nodemap_set(nodemap, i);
+            howmany--;
+        }
+    }
+}
+
+/*
+ * First Fit automatic placement. Just scan all the nodes in the
+ * provided map (@nodemap) linearly and pick up the fist @nodes
+ * that fit the memory requirements (@memkb) of the domain.
+ * This also returns the actual number of used nodes (still via
+ * @nodes) and the actual nodes map to be used (still via @nodemap),
+ * as they both can change depending on the retry policy (@retry).
+ */
+static int place_domain_ffit(const libxl_numainfo *numa, uint64_t memb,
+                             int retry, int nr_nodes, int *nodes,
+                             libxl_nodemap *nodemap)
+{
+    uint64_t memb_node;
+    libxl_nodemap suitable_nodes;
+    int attempts = 1, rc = 0;
+    int i, found_nodes;
+
+    /* XXX This is one of the nastiest piece of code I've
+     *     ever written... Mhuahahahah!! */
+    if (retry == NODES_POLICY_RETRY_BOTH) {
+        int dec_nodes;
+        /* Order (_DEC before than _INC) should stay like this,
+         * as NODES_POLICY_RETRY_INC can broaden the node map. */
+        retry = NODES_POLICY_RETRY_INC;
+        dec_nodes = *nodes;
+        if (!place_domain_ffit(numa, memb, NODES_POLICY_RETRY_DEC,
+                               nr_nodes, &dec_nodes, nodemap)) {
+            *nodes = dec_nodes;
+            return 0;
+        }
+    }
+
+    if (libxl_nodemap_alloc(ctx, &suitable_nodes) < 0) {
+        fprintf(stderr, "libxl_nodemap_alloc failed\n");
+        return ENOMEM;
+    }
+
+    do {
+        rc = ENOSPC;
+
+        /* Avoid trying to look for silly number of nodes */
+        if (*nodes <= 0 || *nodes > nr_nodes)
+            break;
+
+        /* Determine how much free memory we want on each of the nodes
+         * that will end up in suitable_nodes. Either adding or ignoring
+         * the modulus of the integer division should be fine (the total
+         * number of nodes should be in the order of tens of them), so
+         * let's add it as it should be more safe.
+         */
+        memb_node = (memb / (*nodes)) + (memb % (*nodes));
+
+        /* Let's see if there are enough (valid!) nodes in the map
+         * with such an amount of memory. */
+        found_nodes = 0;
+        libxl_nodemap_set_none(&suitable_nodes);
+        libxl_for_each_set_node(i, *nodemap) {
+            if (numa[i].size > 0 && numa[i].free >= memb_node) {
+                libxl_nodemap_set(&suitable_nodes, i);
+                if (++found_nodes >= *nodes)
+                    break;
+            }
+        }
+        if (found_nodes == (*nodes)) {
+            /* We're done, let's commit the resulting nodemap */
+            libxl_nodemap_copy(nodemap, &suitable_nodes); 
+            rc = 0;
+            break;
+        }
+
+        /* Apply the asked retry policy for the next round. Notice
+         * that it would be pointless to increase nodes without also
+         * adding some nodes to the map! */
+        *nodes += retry;
+        if (retry == NODES_POLICY_RETRY_INC)
+            __add_nodes_to_nodemap(nodemap, numa, nr_nodes, retry);
+
+        attempts++;
+    } while (retry != NODES_POLICY_NO_RETRY &&
+             attempts < NODES_POLICY_FIT_ATTEMPTS);
+
+    libxl_nodemap_dispose(&suitable_nodes);
+
+    return rc;
+}
+
+/* Try to achieve optimal node-affinity for the domain */
+static int place_domain(libxl_domain_build_info *b_info)
+{
+    uint32_t need_memkb;
+    libxl_numainfo *numa;
+    libxl_cputopology *info;
+    libxl_nodemap new_nodemap;
+    int nr_nodes, nr_cpus;
+    int use_nodes = 0, use_cpus;
+    int attempts = 1, rc = 0;
+    int i, retry_policy;
+
+    if (nodes_policy == NODES_POLICY_NONE ||
+        nodes_policy == NODES_POLICY_STATIC) 
+        /* Nothing to be done: if we're here no policy is being set, either
+         * because domain doesn't want one, or it asked for specific nodes. */
+        return 0;
+
+    rc = libxl_domain_need_memory(ctx, b_info, &need_memkb);
+    if (rc < 0) {
+        fprintf(stderr, "libxl_domain_need_memory failed.\n");
+        goto out;
+    }
+
+    /* We need to know both how much free memory we have on the
+     * nodes, and to what node the various CPUS belong. */
+    numa = libxl_get_numainfo(ctx, &nr_nodes);
+    if (numa == NULL) {
+        fprintf(stderr, "libxl_get_numainfo failed.\n");
+        rc = ENOMEM;
+        goto out;
+    }
+    info = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (info == NULL) {
+        fprintf(stderr, "libxl_get_topologyinfo failed.\n");
+        rc = ENOMEM;
+        goto out_numa;
+    }
+
+    /* In order not to alter the actual b_info->nodemap during the
+     * process (what if something goes wrong in the middle?) use
+     * this copy of it and only commit the result at the end. */
+    if (libxl_nodemap_alloc(ctx, &new_nodemap) < 0) {
+        fprintf(stderr, "libxl_nodemap_alloc failed\n");
+        goto out_topology;;
+    }
+
+    /* If a nodemap has been specified, just comply with that.
+     * OTOH, if there's no nodemap, rely on cpumap (if any), and
+     * fallback to all node if even that is empty. Also consider
+     * all the nodes to be valid if only the number (i.e., _how_
+     * _many_ of them instead of _which_ of them) of nodes the
+     * domain wants is provided.
+     *
+     * Concering retries, if a specific set of nodes is specified,
+     * just try that and give up if we fail. If, instead, a set of
+     * CPUs onto which to pin the domain is specified, try first
+     * the exact nodes those CPUs belongs to, then also try both
+     * a smaller and a bigger number of nodes. The same happens if
+     * we just have the number of nodes to be used. Finally, if
+     * there is no node-affinity, no cpu-pinning, no number of nodes,
+     * start trying with one node and increase at the configured
+     * rate (considering all the nodes to be suitable).
+     *
+     * XXX some sort of libxl_{cpu,node}map_weight can be
+     *     implemented and used here to both speedup and
+     *     restructure this ugly code below!
+     */
+    if (num_nodes_policy != 0) {
+        /* The num. of nodes is all we have */
+        retry_policy = NODES_POLICY_RETRY_BOTH;
+        libxl_nodemap_set_any(&new_nodemap);
+        use_nodes = num_nodes_policy;
+    } else {
+        /* Is a list of suitable nodes there? */
+        retry_policy = NODES_POLICY_NO_RETRY;
+        libxl_for_each_set_node(i, b_info->nodemap) {
+            libxl_nodemap_set(&new_nodemap, i);
+            use_nodes++;
+        }
+        if (use_nodes == 0) {
+            int mask_cpus = 0;
+
+            /* No list of nodes, maybe the domain is pinned somewhere? */
+            retry_policy = NODES_POLICY_RETRY_BOTH;
+            libxl_for_each_set_cpu(i, b_info->cpumap) {
+                mask_cpus++;
+                if (!libxl_nodemap_test(&new_nodemap, info[i].node)) {
+                    libxl_nodemap_set(&new_nodemap, info[i].node);
+                    use_nodes++;
+                }
+            }
+            /* All cpus just means no affinity, so reset nodes anyway */
+            if (mask_cpus == nr_cpus)
+                use_nodes = 0;
+        }
+        if (use_nodes == 0) {
+            /* No hints about placement at all */
+            retry_policy = NODES_POLICY_RETRY_INC;
+            libxl_nodemap_set_any(&new_nodemap);
+            use_nodes = 1;
+        }
+    }
+    do {
+        rc = ESRCH;
+
+        if (use_nodes > nr_nodes)
+            break;
+
+        /* Kick off the chosen placement policy.
+         *
+         * XXX This is blind wrt to what happens on the CPUs
+         *     of the various nodes. Many solutions (most of which
+         *     mainly constituted by some heuristics) can be found,
+         *     but they all require the hyppervisor to provide some
+         *     information on how loaded and busy they are, and
+         *     that will be material for future work. However, if
+         *     there are any thoughts about that, they are welcome
+         *     here. */
+        switch(nodes_policy) {
+        case NODES_POLICY_AUTO:
+        case NODES_POLICY_FFIT:
+            rc = place_domain_ffit(numa, (uint64_t) need_memkb * 1024,
+                                   retry_policy, nr_nodes, &use_nodes,
+                                   &new_nodemap);
+            break;
+        }
+
+        if (rc)
+            goto out_nodemap;
+
+        /* Check whether the (set of) node(s) selected so far is able
+         * to provide the domain with enough CPUs for his VCPUs. In
+         * case it does not respin the whole procedure with one more
+         * node available for it to use.
+         *
+         * XXX This does not work as expected! Point is there are a lot
+         *     of entries in info (as it is returned by libxl_get_cpu_topology
+         *     that does not represent an actual physical CPU, they're
+         *     just free space on the array, as it ranges from 0 up to
+         *     max_cpu_id (nr_cpus here), which is the maximum number of
+         *     supported CPUs. For example, on my testbox, info array has
+         *     64 elements, while I only have 16 CPUs. Moreover, all the
+         *     "empty spots" are filled with 0s, including their node field.
+         *     This means the cycle below will se all of them belonging to
+         *     node #0, which will always have a lot of CPUs (56 here!)
+         *     and will thus always (well, mostly!) be suitable for
+         *     accomodating a guest, which might not be true!
+         *     Of course we can change all this in many ways, I just
+         *     would appreciate some feedback on which of those to
+         *     go for. :-)
+         */
+        use_cpus = 0;
+        libxl_for_each_cpu(i, b_info->cpumap) {
+            /* We only want CPUs belonging to (valid!) nodes in the mask */
+            if (libxl_nodemap_test(&new_nodemap, info[i].node) &&
+                numa[info[i].node].size > 0) {
+                use_cpus++;
+            }
+        }
+
+        if (use_cpus >= b_info->max_vcpus) {
+            rc = 0;
+            break;
+        }
+        /* Add one more node and retry fitting the domain */
+        __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1);
+        use_nodes += 1;
+
+        attempts++;
+    } while (attempts <= NODES_POLICY_VCPU_ATTEMPTS);
+
+    /* Things went fine. Commit the map into domain's build info */
+    if (!rc)
+        libxl_nodemap_copy(&b_info->nodemap, &new_nodemap);
+
+out_nodemap:
+    libxl_nodemap_dispose(&new_nodemap);
+out_topology:
+    libxl_cputopology_list_free(info, nr_cpus);
+out_numa:
+    libxl_numainfo_list_free(numa, nr_nodes);
+out:
+    return rc;
+}
+
 static inline int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
 {
     return affinity_parse(cpu, cpumap, libxl_get_max_cpus(ctx));
@@ -638,7 +995,7 @@ static void parse_config_data(const char
         free(buf2);
     }
 
-    if (!xlu_cfg_get_list (config, "nodes", &nodes, 0, 0)) {
+    if (!xlu_cfg_get_list (config, "nodes", &nodes, 0, 1)) {
         int i, n_nodes = 0;
 
         if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
@@ -646,6 +1003,7 @@ static void parse_config_data(const char
             exit(1);
         }
 
+        nodes_policy = NODES_POLICY_STATIC;
         libxl_nodemap_set_none(&b_info->nodemap);
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             i = atoi(buf);
@@ -660,6 +1018,37 @@ static void parse_config_data(const char
         if (n_nodes == 0)
             fprintf(stderr, "No valid node found: no affinity will be set\n");
     }
+    else if (!xlu_cfg_get_long (config, "nodes", &l, 1)) {
+        if (l <= 0) {
+            fprintf(stderr, "Only strictly positive values for \"nodes\"\n");
+            exit(1);
+        }
+
+        if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+            fprintf(stderr, "Unable to allocate nodemap\n");
+            exit(1);
+        }
+
+        libxl_nodemap_set_none(&b_info->nodemap);
+        nodes_policy = NODES_POLICY_AUTO;
+        num_nodes_policy = l;
+    }
+    else if (!xlu_cfg_get_string (config, "nodes", &buf, 1)) {
+        if (strcmp(buf, "auto")) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"nodes\""
+                    " (only \"auto\" supported here)\n", buf);
+            exit(1);
+        }
+
+        if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+            fprintf(stderr, "Unable to allocate nodemap\n");
+            exit(1);
+        }
+
+        /* Automatic placement will take care */
+        libxl_nodemap_set_none(&b_info->nodemap);
+        nodes_policy = NODES_POLICY_AUTO;
+    }
     else {
         /*
          * XXX What would a sane default be? I think doing nothing
@@ -671,6 +1060,32 @@ static void parse_config_data(const char
          */
     }
 
+    if (!xlu_cfg_get_string (config, "nodes_policy", &buf, 0)) {
+        fprintf(stderr, "got a nodes policy string: \"%s\"\n", buf);
+
+        if (nodes_policy_parse(buf, &l)) {
+            fprintf(stderr, "ERROR: invalid value for \"nodes_policy\"\n");
+            exit(1);
+        }
+        if (l == NODES_POLICY_STATIC || l == NODES_POLICY_NONE) {
+            fprintf(stderr, "ERROR: \"%s\" can't be used here\n", buf);
+            exit(1);
+        }
+
+        /* Actually set the policy. If there is no nodemap, build
+         * a new one for the placement to use. Otherwise, don't touch it,
+         * i.e., tell the policy to try to respect that and act on
+         * those nodes only (if possible). */
+        nodes_policy = l;
+        if (!b_info->nodemap.size) {
+            if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+                fprintf(stderr, "Unable to allocate nodemap\n");
+                exit(1);
+            }
+            libxl_nodemap_set_none(&b_info->nodemap);
+        }
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
@@ -1703,6 +2118,16 @@ start:
         goto error_out;
     }
 
+    ret = place_domain(&d_config.b_info);
+    if (ret == ESRCH || ret == ENOSPC) {
+        fprintf(stderr, "failed to place the domain, fallback to all nodes\n");
+        libxl_nodemap_set_any(&d_config.b_info.nodemap);
+    } else if (ret < 0) {
+        fprintf(stderr, "failed to put the domain on the requested node(s)\n");
+        ret = ERROR_FAIL;
+        goto error_out;
+    }
+
     if ( dom_info->console_autoconnect ) {
         cb = autoconnect_console;
     }else{
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -365,10 +365,11 @@ static void dump_numa(unsigned char key)
 
 	for_each_online_node(i) {
 		paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT;
-		printk("idx%d -> NODE%d start->%lu size->%lu\n",
+		printk("idx%d -> NODE%d start->%lu size->%lu free->%lu\n",
 			  i, NODE_DATA(i)->node_id,
 			  NODE_DATA(i)->node_start_pfn,
-			  NODE_DATA(i)->node_spanned_pages);
+			  NODE_DATA(i)->node_spanned_pages,
+                          avail_node_heap_pages(i));
 		/* sanity check phys_to_nid() */
 		printk("phys_to_nid(%"PRIpaddr") -> %d should be %d\n", pa, phys_to_nid(pa),
 			  NODE_DATA(i)->node_id);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxaj-0001tO-FB; Wed, 11 Apr 2012 13:28:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxah-0001rd-UC
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:08 +0000
Received: from [85.158.143.35:58846] by server-1.bemta-4.messagelabs.com id
	55/5F-20925-7E6858F4; Wed, 11 Apr 2012 13:28:07 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!4
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29097 invoked from network); 11 Apr 2012 13:28:05 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:05 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=0slfY2qddbhSUy32r9GSxeem+x3mVX17IRAzvhc5jao=;
	b=tXD8SB0zGWAGy9i8aeIlIHxFYZ+pirZyrFIinh4W3MGu3y5tHZDYib8HeTfMBBFpno
	2zwAPmq69stVsZ/afXgt3B+4MitkbvoFjkPlkkhbd/IArHyHakjwDKfieGdomufqKIkq
	tFIi7bTcEFuxniPdbX2L91KJqUVZP47yFNvpEgzjeVCviWuL407S7zw8L+sQgJH11poy
	BZMNhW7GqFjq3YYw0TpAvM+IUZRenl27rzoh61e+cBWFSChMqhkgFfkOy18suR2hTfM1
	01r07jm4hjja2L2yJ++TRlqRra/VmJ8hgn8nN/XVZl8u+ZjOE/9XiZ7BCCOQ0kbI3/DY
	ddeg==
Received: by 10.14.204.3 with SMTP id g3mr1906073eeo.75.1334150885375;
	Wed, 11 Apr 2012 06:28:05 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.28.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:04 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 31163f014d8a2da9375f7bc02eae0796342e2156
Message-Id: <31163f014d8a2da9375f.1334150275@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:55 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit
 memory-wise placement of guests on nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow the user to ask for automatic placement of a new domain onto
the NUMA nodes of the host. The most important consideration, wrt
to this, definitely is how much free memory we have on the various
nodes vs. how much memory the domain needs, and this is exactly what
is used to drive the algorithm decisions. Some more refinement, e.g.,
adding more factors, like actual load on the CPUs, etc, to the
"equation" can be easily added later.

The placement logic is very simple and it uses the First Fit algorithm.
This basically means the domain is put in the first node (or, perhaps,
set of nodes) with enough free memory. A form of `sanity check' is
performed after the memory-wise placement, to be sure the domain has
at least as much pCPUs available as its vCPUs, and if that is not the
case, more nodes are added to its affinity map.

The user can ask for full automatic placement, in which case the least
possible number of nodes will be used, or provide some hints, such
as how many nodes he wants the domain to be affine to. He can also ask
for a more specific placement (an explicit list of nodes), and the
algorithm will honour that, if possible, or just fail. Finally, if
the user doesn't say anything about node affinity, but the domain has
some vcpu affinity, the algorithm will use that information as a
starting point for placing it.

TODO: * As usual, relationship with cpupools should be better
        both defined and (then) checked.
      * This only takes memory into account, forgetting about how
        busy the CPUs of the various nodes are. Heuristics for
        taking that into account too need to be thought about,
        and proper support for gathering the data they need for
        working (e.g., stats about load on pCPUs?) implemented.
      * This just ignores node distances, as exporting such info
        via libxl would be better when we'll have arrays in the IDL;
        however, spots where such information should be considered
        are clearly identified and marked, so it should be trivial
        to put it in place once we'll have the proper backup.
      * Checking for free memory in `xl' and then allocating it
        to domains in Xen is prone to race conditions. Domain
        creation should be fine, given the current --very coarse--
        locking discipline implemented in `xl' itself, but, for
        instance, nothing protect creation and ballooning from
        running into each other. This affects the present code
        as well (freemem() already checks for free memory in the
        creation process), but can get particularly nasty with
        this changes applied. It needs to be solved somehow...
        Solutions are under consideration.
      * Benchmarks, e.g., something like put a bunch of VM
        on "auto" placement policy and check for some kind of
        aggregate throughput (I'm working on this, in order to
        have it happening by means of the same infrastructure I
        used for producing the results referred to in the #0 mail).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

add-firstfit-automatic-domain-placement.patch

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -122,6 +122,36 @@ vcpus on the cpus of the affine node(s).
 
 A list of nodes should be specified as follows: `nodes=["0", "3"]`
 for the guest to be affine with nodes 0 and 3.
+It is also possible to ask for automatic placement of the guest on
+host nodes by either using `nodes="auto"` or just putting the number
+of nodes the guest should span, e.g., `nodes=2`. In the former case,
+xl will try to make the guest affine with the lowest possible number
+of nodes, in the latter it will try to make it affine to the provided
+number of them.
+
+=item B<nodes_policy="NODE-POLICY">
+
+Allows for better specifying how to automatically set the guest NUMA
+affinity. Available C<NODE-POLICY>-ies are:
+
+=over 4
+
+=item B<auto>
+
+use a not better specified (xl-implementation dependant) algorithm
+to try automatically fitting the guest on the host's NUMA nodes
+
+=item B<ffit>
+
+use the First Fit algorithm to try automatically fitting the
+guest on the host's NUMA nodes
+
+=back
+
+This option interacts with `nodes=` such that, if the number of
+nodes to use is specified there (e.g., `nodes=2`), xl will use
+the specified policy to try  fitting the guest on that exact
+number of NUMA nodes of the host.
 
 =item B<memory=MBYTES>
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -454,6 +454,15 @@ int libxl_map_alloc(libxl_ctx *ctx, stru
     return 0;
 }
 
+static void libxl_map_copy(/*XXX libxl_ctx *ctx, */ struct libxl_map *dptr,
+                          const struct libxl_map *sptr)
+{
+    int sz;
+
+    sz = dptr->size = sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
 int libxl_map_test(struct libxl_map *map, int elem)
 {
     if (elem >= map->size * 8)
@@ -497,6 +506,12 @@ int libxl_nodemap_alloc(libxl_ctx *ctx, 
     return libxl_map_alloc(ctx, nodemap, max_nodes);
 }
 
+void libxl_nodemap_copy(/*XXX libxl_ctx *ctx, */ libxl_nodemap *dst,
+                       const libxl_nodemap *src)
+{
+   libxl_map_copy(/*XXX ctx, */ dst, src);
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -115,6 +115,8 @@ static inline int libxl_cpumap_cpu_valid
                                              if (libxl_cpumap_test(&(m), v))
 
 int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap);
+void libxl_nodemap_copy(/*XXX libxl_ctx *ctx, */ libxl_nodemap *dst,
+                       const libxl_nodemap *src);
 static inline int libxl_nodemap_test(libxl_nodemap *nodemap, int node)
 {
     return libxl_map_test(nodemap, node);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -113,6 +113,55 @@ static const char *action_on_shutdown_na
     [LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART] = "coredump-restart",
 };
 
+/* Automatic placement policies symbols, with the following meaning:
+ *  NONE   : no automatic placement at all;
+ *  STATIC : explicit nodes specification.
+ *  FFIT   : use the First Fit algorithm for automatic placement;
+ *  AUTO   : an not better specified automatic placement, likely
+ *           to be implemented as a short circuit to (one of)
+ *           the above(s);
+ */
+#define NODES_POLICY_NONE    0
+#define NODES_POLICY_STATIC  1
+#define NODES_POLICY_FFIT    2
+#define NODES_POLICY_AUTO    3
+
+/* Default behaviour wrt to automatic domain placement on nodes,
+ * maximum number of attempts made for applying the desired
+ * placement policy and parameters, and of the same for attempts
+ * made for having enough CPUs available to the domain.
+ */
+#define NODES_POLICY_DEFAULT       NODES_POLICY_NONE
+#define NODES_POLICY_FIT_ATTEMPTS  5
+#define NODES_POLICY_VCPU_ATTEMPTS 5
+
+/* Whether, in case it is not possible to fit a domain on
+ * the requested nodes, we should give up (_NO_RETRY), try
+ * to increment (_RETRY_INC), decrement (_RETRY_DEC) or both
+ * (_RETRY_BOTH) the number of nodes.
+ *
+ * XXX Maybe the actual value of _INC and _DEC, as well as
+ *     _DEFAULT and _*_ATTEMPTS above is something we want
+ *     to be configurable, e.g., in xl.conf or alike?
+ */
+#define NODES_POLICY_NO_RETRY   ( 0)
+#define NODES_POLICY_RETRY_INC  (+1)
+#define NODES_POLICY_RETRY_DEC  (-1)
+#define NODES_POLICY_RETRY_BOTH (INT_MAX)
+
+static const char *nodes_policy_names[] = {
+    [NODES_POLICY_NONE]   = "none",
+    [NODES_POLICY_STATIC] = "static",
+    [NODES_POLICY_FFIT]   = "ffit",
+    [NODES_POLICY_AUTO]   = "auto",
+};
+
+/* Store the policy for the domain while parsing */
+static int nodes_policy = NODES_POLICY_DEFAULT;
+
+/* Store the number of nodes to be used while parsing */
+static int num_nodes_policy = 0;
+
 /* Optional data, in order:
  *   4 bytes uint32_t  config file size
  *   n bytes           config file in Unix text file format
@@ -507,6 +556,314 @@ afp_out:
     return rc;
 }
 
+static int nodes_policy_parse(const char *pol, long int *policy)
+{
+    int i;
+    const char *n;
+
+    for (i = 0; i < sizeof(nodes_policy_names) / sizeof(nodes_policy_names[0]); i++) {
+        n = nodes_policy_names[i];
+
+        if (!n) continue;
+
+        if (strcmp(pol, n) == 0) {
+            *policy = i;
+            return 0;
+        }
+    }
+
+    return EINVAL;
+}
+
+static inline void __add_nodes_to_nodemap(libxl_nodemap *nodemap,
+                                          const libxl_numainfo *numa,
+                                          int nr_nodes, int howmany)
+{
+    int i;
+
+    /* XXX Once we have the node-distance information, maybe we can
+     *     use it here in trying to set nodes closer to the ones that
+     *     are already in the map. */ 
+    for (i = 0 ; i < nr_nodes && howmany > 0; i++) {
+        if (!libxl_nodemap_test(nodemap, i) && numa[i].size > 0) {
+            libxl_nodemap_set(nodemap, i);
+            howmany--;
+        }
+    }
+}
+
+/*
+ * First Fit automatic placement. Just scan all the nodes in the
+ * provided map (@nodemap) linearly and pick up the fist @nodes
+ * that fit the memory requirements (@memkb) of the domain.
+ * This also returns the actual number of used nodes (still via
+ * @nodes) and the actual nodes map to be used (still via @nodemap),
+ * as they both can change depending on the retry policy (@retry).
+ */
+static int place_domain_ffit(const libxl_numainfo *numa, uint64_t memb,
+                             int retry, int nr_nodes, int *nodes,
+                             libxl_nodemap *nodemap)
+{
+    uint64_t memb_node;
+    libxl_nodemap suitable_nodes;
+    int attempts = 1, rc = 0;
+    int i, found_nodes;
+
+    /* XXX This is one of the nastiest piece of code I've
+     *     ever written... Mhuahahahah!! */
+    if (retry == NODES_POLICY_RETRY_BOTH) {
+        int dec_nodes;
+        /* Order (_DEC before than _INC) should stay like this,
+         * as NODES_POLICY_RETRY_INC can broaden the node map. */
+        retry = NODES_POLICY_RETRY_INC;
+        dec_nodes = *nodes;
+        if (!place_domain_ffit(numa, memb, NODES_POLICY_RETRY_DEC,
+                               nr_nodes, &dec_nodes, nodemap)) {
+            *nodes = dec_nodes;
+            return 0;
+        }
+    }
+
+    if (libxl_nodemap_alloc(ctx, &suitable_nodes) < 0) {
+        fprintf(stderr, "libxl_nodemap_alloc failed\n");
+        return ENOMEM;
+    }
+
+    do {
+        rc = ENOSPC;
+
+        /* Avoid trying to look for silly number of nodes */
+        if (*nodes <= 0 || *nodes > nr_nodes)
+            break;
+
+        /* Determine how much free memory we want on each of the nodes
+         * that will end up in suitable_nodes. Either adding or ignoring
+         * the modulus of the integer division should be fine (the total
+         * number of nodes should be in the order of tens of them), so
+         * let's add it as it should be more safe.
+         */
+        memb_node = (memb / (*nodes)) + (memb % (*nodes));
+
+        /* Let's see if there are enough (valid!) nodes in the map
+         * with such an amount of memory. */
+        found_nodes = 0;
+        libxl_nodemap_set_none(&suitable_nodes);
+        libxl_for_each_set_node(i, *nodemap) {
+            if (numa[i].size > 0 && numa[i].free >= memb_node) {
+                libxl_nodemap_set(&suitable_nodes, i);
+                if (++found_nodes >= *nodes)
+                    break;
+            }
+        }
+        if (found_nodes == (*nodes)) {
+            /* We're done, let's commit the resulting nodemap */
+            libxl_nodemap_copy(nodemap, &suitable_nodes); 
+            rc = 0;
+            break;
+        }
+
+        /* Apply the asked retry policy for the next round. Notice
+         * that it would be pointless to increase nodes without also
+         * adding some nodes to the map! */
+        *nodes += retry;
+        if (retry == NODES_POLICY_RETRY_INC)
+            __add_nodes_to_nodemap(nodemap, numa, nr_nodes, retry);
+
+        attempts++;
+    } while (retry != NODES_POLICY_NO_RETRY &&
+             attempts < NODES_POLICY_FIT_ATTEMPTS);
+
+    libxl_nodemap_dispose(&suitable_nodes);
+
+    return rc;
+}
+
+/* Try to achieve optimal node-affinity for the domain */
+static int place_domain(libxl_domain_build_info *b_info)
+{
+    uint32_t need_memkb;
+    libxl_numainfo *numa;
+    libxl_cputopology *info;
+    libxl_nodemap new_nodemap;
+    int nr_nodes, nr_cpus;
+    int use_nodes = 0, use_cpus;
+    int attempts = 1, rc = 0;
+    int i, retry_policy;
+
+    if (nodes_policy == NODES_POLICY_NONE ||
+        nodes_policy == NODES_POLICY_STATIC) 
+        /* Nothing to be done: if we're here no policy is being set, either
+         * because domain doesn't want one, or it asked for specific nodes. */
+        return 0;
+
+    rc = libxl_domain_need_memory(ctx, b_info, &need_memkb);
+    if (rc < 0) {
+        fprintf(stderr, "libxl_domain_need_memory failed.\n");
+        goto out;
+    }
+
+    /* We need to know both how much free memory we have on the
+     * nodes, and to what node the various CPUS belong. */
+    numa = libxl_get_numainfo(ctx, &nr_nodes);
+    if (numa == NULL) {
+        fprintf(stderr, "libxl_get_numainfo failed.\n");
+        rc = ENOMEM;
+        goto out;
+    }
+    info = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (info == NULL) {
+        fprintf(stderr, "libxl_get_topologyinfo failed.\n");
+        rc = ENOMEM;
+        goto out_numa;
+    }
+
+    /* In order not to alter the actual b_info->nodemap during the
+     * process (what if something goes wrong in the middle?) use
+     * this copy of it and only commit the result at the end. */
+    if (libxl_nodemap_alloc(ctx, &new_nodemap) < 0) {
+        fprintf(stderr, "libxl_nodemap_alloc failed\n");
+        goto out_topology;;
+    }
+
+    /* If a nodemap has been specified, just comply with that.
+     * OTOH, if there's no nodemap, rely on cpumap (if any), and
+     * fallback to all node if even that is empty. Also consider
+     * all the nodes to be valid if only the number (i.e., _how_
+     * _many_ of them instead of _which_ of them) of nodes the
+     * domain wants is provided.
+     *
+     * Concering retries, if a specific set of nodes is specified,
+     * just try that and give up if we fail. If, instead, a set of
+     * CPUs onto which to pin the domain is specified, try first
+     * the exact nodes those CPUs belongs to, then also try both
+     * a smaller and a bigger number of nodes. The same happens if
+     * we just have the number of nodes to be used. Finally, if
+     * there is no node-affinity, no cpu-pinning, no number of nodes,
+     * start trying with one node and increase at the configured
+     * rate (considering all the nodes to be suitable).
+     *
+     * XXX some sort of libxl_{cpu,node}map_weight can be
+     *     implemented and used here to both speedup and
+     *     restructure this ugly code below!
+     */
+    if (num_nodes_policy != 0) {
+        /* The num. of nodes is all we have */
+        retry_policy = NODES_POLICY_RETRY_BOTH;
+        libxl_nodemap_set_any(&new_nodemap);
+        use_nodes = num_nodes_policy;
+    } else {
+        /* Is a list of suitable nodes there? */
+        retry_policy = NODES_POLICY_NO_RETRY;
+        libxl_for_each_set_node(i, b_info->nodemap) {
+            libxl_nodemap_set(&new_nodemap, i);
+            use_nodes++;
+        }
+        if (use_nodes == 0) {
+            int mask_cpus = 0;
+
+            /* No list of nodes, maybe the domain is pinned somewhere? */
+            retry_policy = NODES_POLICY_RETRY_BOTH;
+            libxl_for_each_set_cpu(i, b_info->cpumap) {
+                mask_cpus++;
+                if (!libxl_nodemap_test(&new_nodemap, info[i].node)) {
+                    libxl_nodemap_set(&new_nodemap, info[i].node);
+                    use_nodes++;
+                }
+            }
+            /* All cpus just means no affinity, so reset nodes anyway */
+            if (mask_cpus == nr_cpus)
+                use_nodes = 0;
+        }
+        if (use_nodes == 0) {
+            /* No hints about placement at all */
+            retry_policy = NODES_POLICY_RETRY_INC;
+            libxl_nodemap_set_any(&new_nodemap);
+            use_nodes = 1;
+        }
+    }
+    do {
+        rc = ESRCH;
+
+        if (use_nodes > nr_nodes)
+            break;
+
+        /* Kick off the chosen placement policy.
+         *
+         * XXX This is blind wrt to what happens on the CPUs
+         *     of the various nodes. Many solutions (most of which
+         *     mainly constituted by some heuristics) can be found,
+         *     but they all require the hyppervisor to provide some
+         *     information on how loaded and busy they are, and
+         *     that will be material for future work. However, if
+         *     there are any thoughts about that, they are welcome
+         *     here. */
+        switch(nodes_policy) {
+        case NODES_POLICY_AUTO:
+        case NODES_POLICY_FFIT:
+            rc = place_domain_ffit(numa, (uint64_t) need_memkb * 1024,
+                                   retry_policy, nr_nodes, &use_nodes,
+                                   &new_nodemap);
+            break;
+        }
+
+        if (rc)
+            goto out_nodemap;
+
+        /* Check whether the (set of) node(s) selected so far is able
+         * to provide the domain with enough CPUs for his VCPUs. In
+         * case it does not respin the whole procedure with one more
+         * node available for it to use.
+         *
+         * XXX This does not work as expected! Point is there are a lot
+         *     of entries in info (as it is returned by libxl_get_cpu_topology
+         *     that does not represent an actual physical CPU, they're
+         *     just free space on the array, as it ranges from 0 up to
+         *     max_cpu_id (nr_cpus here), which is the maximum number of
+         *     supported CPUs. For example, on my testbox, info array has
+         *     64 elements, while I only have 16 CPUs. Moreover, all the
+         *     "empty spots" are filled with 0s, including their node field.
+         *     This means the cycle below will se all of them belonging to
+         *     node #0, which will always have a lot of CPUs (56 here!)
+         *     and will thus always (well, mostly!) be suitable for
+         *     accomodating a guest, which might not be true!
+         *     Of course we can change all this in many ways, I just
+         *     would appreciate some feedback on which of those to
+         *     go for. :-)
+         */
+        use_cpus = 0;
+        libxl_for_each_cpu(i, b_info->cpumap) {
+            /* We only want CPUs belonging to (valid!) nodes in the mask */
+            if (libxl_nodemap_test(&new_nodemap, info[i].node) &&
+                numa[info[i].node].size > 0) {
+                use_cpus++;
+            }
+        }
+
+        if (use_cpus >= b_info->max_vcpus) {
+            rc = 0;
+            break;
+        }
+        /* Add one more node and retry fitting the domain */
+        __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1);
+        use_nodes += 1;
+
+        attempts++;
+    } while (attempts <= NODES_POLICY_VCPU_ATTEMPTS);
+
+    /* Things went fine. Commit the map into domain's build info */
+    if (!rc)
+        libxl_nodemap_copy(&b_info->nodemap, &new_nodemap);
+
+out_nodemap:
+    libxl_nodemap_dispose(&new_nodemap);
+out_topology:
+    libxl_cputopology_list_free(info, nr_cpus);
+out_numa:
+    libxl_numainfo_list_free(numa, nr_nodes);
+out:
+    return rc;
+}
+
 static inline int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
 {
     return affinity_parse(cpu, cpumap, libxl_get_max_cpus(ctx));
@@ -638,7 +995,7 @@ static void parse_config_data(const char
         free(buf2);
     }
 
-    if (!xlu_cfg_get_list (config, "nodes", &nodes, 0, 0)) {
+    if (!xlu_cfg_get_list (config, "nodes", &nodes, 0, 1)) {
         int i, n_nodes = 0;
 
         if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
@@ -646,6 +1003,7 @@ static void parse_config_data(const char
             exit(1);
         }
 
+        nodes_policy = NODES_POLICY_STATIC;
         libxl_nodemap_set_none(&b_info->nodemap);
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             i = atoi(buf);
@@ -660,6 +1018,37 @@ static void parse_config_data(const char
         if (n_nodes == 0)
             fprintf(stderr, "No valid node found: no affinity will be set\n");
     }
+    else if (!xlu_cfg_get_long (config, "nodes", &l, 1)) {
+        if (l <= 0) {
+            fprintf(stderr, "Only strictly positive values for \"nodes\"\n");
+            exit(1);
+        }
+
+        if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+            fprintf(stderr, "Unable to allocate nodemap\n");
+            exit(1);
+        }
+
+        libxl_nodemap_set_none(&b_info->nodemap);
+        nodes_policy = NODES_POLICY_AUTO;
+        num_nodes_policy = l;
+    }
+    else if (!xlu_cfg_get_string (config, "nodes", &buf, 1)) {
+        if (strcmp(buf, "auto")) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"nodes\""
+                    " (only \"auto\" supported here)\n", buf);
+            exit(1);
+        }
+
+        if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+            fprintf(stderr, "Unable to allocate nodemap\n");
+            exit(1);
+        }
+
+        /* Automatic placement will take care */
+        libxl_nodemap_set_none(&b_info->nodemap);
+        nodes_policy = NODES_POLICY_AUTO;
+    }
     else {
         /*
          * XXX What would a sane default be? I think doing nothing
@@ -671,6 +1060,32 @@ static void parse_config_data(const char
          */
     }
 
+    if (!xlu_cfg_get_string (config, "nodes_policy", &buf, 0)) {
+        fprintf(stderr, "got a nodes policy string: \"%s\"\n", buf);
+
+        if (nodes_policy_parse(buf, &l)) {
+            fprintf(stderr, "ERROR: invalid value for \"nodes_policy\"\n");
+            exit(1);
+        }
+        if (l == NODES_POLICY_STATIC || l == NODES_POLICY_NONE) {
+            fprintf(stderr, "ERROR: \"%s\" can't be used here\n", buf);
+            exit(1);
+        }
+
+        /* Actually set the policy. If there is no nodemap, build
+         * a new one for the placement to use. Otherwise, don't touch it,
+         * i.e., tell the policy to try to respect that and act on
+         * those nodes only (if possible). */
+        nodes_policy = l;
+        if (!b_info->nodemap.size) {
+            if (libxl_nodemap_alloc(ctx, &b_info->nodemap)) {
+                fprintf(stderr, "Unable to allocate nodemap\n");
+                exit(1);
+            }
+            libxl_nodemap_set_none(&b_info->nodemap);
+        }
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
@@ -1703,6 +2118,16 @@ start:
         goto error_out;
     }
 
+    ret = place_domain(&d_config.b_info);
+    if (ret == ESRCH || ret == ENOSPC) {
+        fprintf(stderr, "failed to place the domain, fallback to all nodes\n");
+        libxl_nodemap_set_any(&d_config.b_info.nodemap);
+    } else if (ret < 0) {
+        fprintf(stderr, "failed to put the domain on the requested node(s)\n");
+        ret = ERROR_FAIL;
+        goto error_out;
+    }
+
     if ( dom_info->console_autoconnect ) {
         cb = autoconnect_console;
     }else{
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -365,10 +365,11 @@ static void dump_numa(unsigned char key)
 
 	for_each_online_node(i) {
 		paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT;
-		printk("idx%d -> NODE%d start->%lu size->%lu\n",
+		printk("idx%d -> NODE%d start->%lu size->%lu free->%lu\n",
 			  i, NODE_DATA(i)->node_id,
 			  NODE_DATA(i)->node_start_pfn,
-			  NODE_DATA(i)->node_spanned_pages);
+			  NODE_DATA(i)->node_spanned_pages,
+                          avail_node_heap_pages(i));
 		/* sanity check phys_to_nid() */
 		printk("phys_to_nid(%"PRIpaddr") -> %d should be %d\n", pa, phys_to_nid(pa),
 			  NODE_DATA(i)->node_id);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxav-00023a-FI; Wed, 11 Apr 2012 13:28:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxat-00021F-5O
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:19 +0000
Received: from [85.158.143.35:59678] by server-1.bemta-4.messagelabs.com id
	2E/9F-20925-2F6858F4; Wed, 11 Apr 2012 13:28:18 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!5
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29428 invoked from network); 11 Apr 2012 13:28:10 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:10 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=2ZXyJAeiCa2Hdhw/PQbxtOl89ihTd5KnQToco7nAfTo=;
	b=CTzAKvPisDjCI5JhOpNzypdCe7aaV0aBASecS9hAbizkB5GXo3aH/uMd1McbQTXOlD
	dqvbPSw2/cJJTfaXMrdQ3cG0GYSv0gfkcBo89ibqENodDwhlwCqMgJu7PD/VKg4VSevf
	zzI6jJDkfZoYVC23OJ6ro6SO8suWsRcxREFOnfiEivw5omhaVoCWM1myDegtrNlVh4XR
	bnlKsy842NmNt/f/rshkyHBaIOx5fDlkjCq9tDqH/TV4KIVFGjclFleMzPTTjKBJqXpv
	DsTmPdJ5zJEqKuNW/FsZJF0Dr78/qidbSiB1ebnDiigwvlmOtZB1ZrMG+xTXdWYWjij3
	onjA==
Received: by 10.213.16.148 with SMTP id o20mr957712eba.284.1334150890530;
	Wed, 11 Apr 2012 06:28:10 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.28.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:09 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: ec0abe6e2de3d35d626aa122c159f9c66d1b0461
Message-Id: <ec0abe6e2de3d35d626a.1334150277@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:57 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 10 of 10 [RFC]] xl: Some automatic NUMA
	placement documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add some rationale and usage documentation for the new automatic
NUMA placement feature of xl.

TODO: * Decide whether we want to have things like "Future Steps/Roadmap"
        and/or "Performances/Benchmarks Results" here as well.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/misc/xl-numa-placement.txt b/docs/misc/xl-numa-placement.txt
new file mode 100644
--- /dev/null
+++ b/docs/misc/xl-numa-placement.txt
@@ -0,0 +1,205 @@
+               -------------------------------------
+               NUMA Guest Placement Design and Usage
+               -------------------------------------
+
+Xen deals with Non-Uniform Memory Access (NUMA) machines in many ways. For
+example each domain has its own "node affinity", i.e., a set of NUMA nodes
+of the host from which memory for that domain is allocated. That becomes
+very important as soon as many domains start running memory-intensive
+workloads on a shared host. In fact, accessing non node-local memory
+locations costs much more than node-local ones, to the point that the
+degradation in performance is likely to be noticeable.
+
+It is then quite obvious that, any mechanism that enable the most of the
+memory accesses for the most of the most of the guest domains to stay
+local is something very important to achieve when dealing with NUMA
+platforms.
+
+
+Node Affinity and CPU Affinity
+------------------------------
+
+There is another very popular 'affinity', besides node affinity we are
+discussing here, which is '(v)cpu affinity'. Moreover, to make things
+even worse, the two are different but somehow related things. In fact,
+in both Xen and Linux worlds, 'cpu affinity' is the set of CPUs a domain
+(that would be a task, when talking about Linux) can be scheduled on.
+This seems to have few to do with memory accesses, but it does, as the
+CPU where a domain run is also from where it tries to access its memory,
+i.e., that is one half of what decides whether a memory access is remote
+or local --- the other half being where the location it wants to access
+is stored.
+
+Of course, if a domain is known to only run on a subset of the physical
+CPUs of the host, it is very easy to turn all its memory accesses into
+local ones, by just constructing it's node affinity (in Xen) basing on
+what nodes these CPUs belongs to. Actually, that is exactly what is being
+done by the hypervisor by default, as soon as it finds out a domain (or
+better, the vcpus of a domain, but let's avoid getting into too much
+details here) has a cpu affinity.
+
+This is working quite well, but it requires the user/system administrator
+to explicitly specify such property --- the cpu affinity --- while the
+domain is being created, or Xen won't be able to exploit that for ensuring
+accesses locality.
+
+On the other hand, as node affinity directly affects where domain's memory
+lives, it makes a lot of sense for it to be involved in scheduling decisions,
+as it would be great if the hypervisor would manage in scheduling all the
+vcpus of all the domains on CPUs attached to the various domains' local
+memory. That is why, the node affinity of a domain is treated by the scheduler
+as the set of nodes on which it would be preferable to run it, although
+not at the cost of violating the scheduling algorithm behavior and
+invariants. This means it Xen will check whether a vcpu of a domain can run
+on one of the CPUs belonging to the nodes of the domain's node affinity,
+but will better run it somewhere else --- even on another, remote, CPU ---
+than violating the priority ordering (e.g., by kicking out from there another
+running vcpu with higher priority) it is designed to enforce.
+
+So, last but not least, what if a domain has both vcpu and node affinity, and
+they only partially match or they do not match at all (to understand how that
+can happen, see the following sections)? Well, in such case, all the domain
+memory will be allocated reflecting its node affinity, while scheduling will
+happen according to its vcpu affinities, meaning that it is easy enough to
+construct optimal, sub-optimal, neutral and even bad and awful configurations
+(which is something nice, e.g., for benchmarking purposes). The remainder
+part of this document is explaining how to do so.
+
+
+Specifying Node Affinity
+------------------------
+
+Besides being automatically computed from the vcpu affinities of a domain
+(or also from it being part of a cpupool) within Xen, it might make sense
+for the user to specify the node affinity of its domains by hand, while
+editing their config files, as another form of partitioning the host
+resources. If that is the case, this is where the "nodes" option of the xl
+config file becomes useful. In fact, specifying something like the below
+
+        nodes = [ '0', '1', '3', '4' ]
+
+in a domain configuration file would result in Xen assigning host NUMA nodes
+number 0, 1, 3 and 4 to the domain's node affinity, regardless of any vcpu
+affinity setting for the same domain. The idea is, yes, the to things are
+related, and if only one is present, it makes sense to use the other for
+inferring it, but it is always possible to explicitly specify both of them,
+independently on how good or awful it could end up being.
+
+Therefore, this is what one should expect when using "nodes", perhaps in
+conjunction with "cpus" in a domain configuration file:
+
+ * `cpus = "0, 1"` and no `nodes=` at all
+   (i.e., only vcpu affinity specified):
+     domain's vcpus can and will run only on host CPUs 0 and 1. Also, as
+     domain's node affinity will be computed by Xen and set to whatever
+     nodes host CPUs 0 and 1 belongs, all the domain's memory accesses will
+     be local accesses;
+
+ * `nodes = [ '0', '1' ]` and no `cpus=` at all
+   (i.e., only node affinity present):
+     domain's vcpus can run on any of the host CPUs, but the scheduler (at
+     least if credit is used, as it is the only scheduler supporting this
+     right now) will try running them on the CPUs that are part of host
+     NUMA nodes 0 and 1. Memory-wise, all the domain's memory will be
+     allocated on host NUMA nodes nodes 0 and 1. This means the most of
+     the memory accesses of the domain should be local, but that will
+     depend on the on-line load, behavior and actual scheduling of both
+     the domain in question and all the other domains on the same host;
+
+ * `nodes = [ '0', '1' ]` and `cpus = "0"`, with CPU 0 within node 0:
+   (i.e., cpu affinity subset of node affinity):
+     domain's vcpus can and will only run on host CPU 0. As node affinity
+     is being explicitly set to host NUMA nodes 0 and 1 --- which includes
+     CPU 0 --- all the memory access of the domain will be local;
+
+ * `nodes = [ '0', '1' ]` and `cpus = "0, 4", with CPU 0 in node 0 but
+   CPU 4 in, say, node 2 (i.e., cpu affinity superset of node affinity):
+     domain's vcpus can run on host CPUs 0 and 4, with CPU 4 not being within
+     the node affinity (explicitly set to host NUMA nodes 0 and 1). The
+     (credit) scheduler will try to keep memory accesses local by scheduling
+     the domain's vcpus on CPU 0, but it may not achieve 100% success;
+
+ * `nodes = [ '0', '1' ]` and `cpus = "4"`, with CPU 4 within, say, node 2
+   (i.e., cpu affinity disjointed with node affinity):
+     domain's vcpus can and will run only on host CPU 4, i.e., completely
+     "outside" of the chosen node affinity. That necessarily means all the
+     domain's memory access will be remote.
+
+
+Automatic NUMA Placement
+------------------------
+
+Just in case one does not want to take the burden of manually specifying
+all the node (and, perhaps, CPU) affinities for all its domains, xl implements
+some automatic placement logic. This basically means the user can ask the
+toolstack to try sorting things out in the best possible way for him.
+This is instead of specifying manually a domain's node affinity and can be
+paired or not with any vcpu affinity (in case it is, the relationship between
+vcpu and node affinities just stays as stated above). To serve this purpose,
+a new domain config switch has been introduces, i.e., the "nodes_policy"
+option. As the name suggests, it allows for specifying a policy to be used
+while attempting automatic placement of the new domain. Available policies
+at the time of writing are:
+
+ * "auto": automatic placement by means of a not better specified (xl
+           implementation dependant) algorithm. It is basically for those
+           who do want automatic placement, but have no idea what policy
+           or algorithm would be better... <<Just give me a sane default!>>
+
+ * "ffit": automatic placement via the First Fit algorithm, applied checking
+           the memory requirement of the domain against the amount of free
+           memory in the various host NUMA nodes;
+
+ * "bfit": automatic placement via the Best Fit algorithm, applied checking
+           the memory requirement of the domain against the amount of free
+           memory in the various host NUMA nodes;
+
+ * "wfit": automatic placement via the Worst Fit algorithm, applied checking
+           the memory requirement of the domain against the amount of free
+           memory in the various host NUMA nodes;
+
+The various algorithms have been implemented as they offer different behavior
+and performances (for different performance metrics). For instance, First Fit
+is known to be efficient and quick, and it generally works better than Best
+Fit wrt memory fragmentation, although it tends to occupy "early" nodes more
+than "late" ones. On the other hand, Best Fit aims at optimizing memory usage,
+although it introduces quite a bit of fragmentation, by leaving large amounts
+of small free memory areas. Finally, the idea behind Worst Fit is that it will
+leave big enough free memory chunks to limit the amount of fragmentation, but
+it (as well as Best Fit does) is more expensive in terms of execution time, as
+it needs the "list" of free memory areas to be kept sorted.
+ 
+Therefore, achieving automatic placement actually happens by properly using
+the "nodes" and "nodes_config" configuration options as follows:
+
+ * `nodes="auto` or `nodes_policy="auto"`:
+     xl will try fitting the domain on the host NUMA nodes by using its
+     own default placing algorithm, with default parameters. Most likely,
+     all nodes will be considered suitable for the domain (unless a vcpu
+     affinity is specified, see the last entry of this list;
+
+ * `nodes_policy="ffit"` (or `"bfit"`, `"wfit"`) and no `nodes=` at all:
+     xl will try fitting the domain on the host NUMA nodes by using the
+     requested policy. All nodes will be considered suitable for the
+     domain, and consecutive fitting attempts will be performed while
+     increasing the number of nodes on which to put the domain itself
+     (unless a vcpu affinity is specified, see the last entry of this list);
+
+ * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `nodes=2`:
+     xl will try fitting the domain on the host NUMA nodes by using the
+     requested policy and only the number of nodes specified in `nodes=`
+     (2 in this example). All the nodes will be considered suitable for
+     the domain, and consecutive attempts will be performed while
+     increasing such a value;
+
+ * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `cpus="0-6":
+     xl will try fitting the domain on the host NUMA nodes to which the CPUs
+     specified as vcpu affinity (0 to 6 in this example) belong, by using the
+     requested policy. In case it fails, consecutive fitting attempts will
+     be performed with both a reduced (first) and an increased (next) number
+     of nodes).
+
+Different usage patterns --- like specifying both a policy and a list of nodes
+are accepted, but does not make much sense after all. Therefore, although xl
+will try at its best to interpret user's will, the resulting behavior is
+somehow unspecified.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:28:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxav-00023a-FI; Wed, 11 Apr 2012 13:28:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SHxat-00021F-5O
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:28:19 +0000
Received: from [85.158.143.35:59678] by server-1.bemta-4.messagelabs.com id
	2E/9F-20925-2F6858F4; Wed, 11 Apr 2012 13:28:18 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334150874!4364085!5
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29428 invoked from network); 11 Apr 2012 13:28:10 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:28:10 -0000
Received: by mail-ey0-f173.google.com with SMTP id f11so233986eaa.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 06:28:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=2ZXyJAeiCa2Hdhw/PQbxtOl89ihTd5KnQToco7nAfTo=;
	b=CTzAKvPisDjCI5JhOpNzypdCe7aaV0aBASecS9hAbizkB5GXo3aH/uMd1McbQTXOlD
	dqvbPSw2/cJJTfaXMrdQ3cG0GYSv0gfkcBo89ibqENodDwhlwCqMgJu7PD/VKg4VSevf
	zzI6jJDkfZoYVC23OJ6ro6SO8suWsRcxREFOnfiEivw5omhaVoCWM1myDegtrNlVh4XR
	bnlKsy842NmNt/f/rshkyHBaIOx5fDlkjCq9tDqH/TV4KIVFGjclFleMzPTTjKBJqXpv
	DsTmPdJ5zJEqKuNW/FsZJF0Dr78/qidbSiB1ebnDiigwvlmOtZB1ZrMG+xTXdWYWjij3
	onjA==
Received: by 10.213.16.148 with SMTP id o20mr957712eba.284.1334150890530;
	Wed, 11 Apr 2012 06:28:10 -0700 (PDT)
Received: from [127.0.1.1] (ip-177-101.sn2.eutelia.it. [83.211.177.101])
	by mx.google.com with ESMTPS id p57sm12404673eei.8.2012.04.11.06.28.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Apr 2012 06:28:09 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: ec0abe6e2de3d35d626aa122c159f9c66d1b0461
Message-Id: <ec0abe6e2de3d35d626a.1334150277@Solace>
In-Reply-To: <patchbomb.1334150267@Solace>
References: <patchbomb.1334150267@Solace>
User-Agent: Mercurial-patchbomb/2.1.2
Date: Wed, 11 Apr 2012 15:17:57 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 10 of 10 [RFC]] xl: Some automatic NUMA
	placement documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add some rationale and usage documentation for the new automatic
NUMA placement feature of xl.

TODO: * Decide whether we want to have things like "Future Steps/Roadmap"
        and/or "Performances/Benchmarks Results" here as well.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/misc/xl-numa-placement.txt b/docs/misc/xl-numa-placement.txt
new file mode 100644
--- /dev/null
+++ b/docs/misc/xl-numa-placement.txt
@@ -0,0 +1,205 @@
+               -------------------------------------
+               NUMA Guest Placement Design and Usage
+               -------------------------------------
+
+Xen deals with Non-Uniform Memory Access (NUMA) machines in many ways. For
+example each domain has its own "node affinity", i.e., a set of NUMA nodes
+of the host from which memory for that domain is allocated. That becomes
+very important as soon as many domains start running memory-intensive
+workloads on a shared host. In fact, accessing non node-local memory
+locations costs much more than node-local ones, to the point that the
+degradation in performance is likely to be noticeable.
+
+It is then quite obvious that, any mechanism that enable the most of the
+memory accesses for the most of the most of the guest domains to stay
+local is something very important to achieve when dealing with NUMA
+platforms.
+
+
+Node Affinity and CPU Affinity
+------------------------------
+
+There is another very popular 'affinity', besides node affinity we are
+discussing here, which is '(v)cpu affinity'. Moreover, to make things
+even worse, the two are different but somehow related things. In fact,
+in both Xen and Linux worlds, 'cpu affinity' is the set of CPUs a domain
+(that would be a task, when talking about Linux) can be scheduled on.
+This seems to have few to do with memory accesses, but it does, as the
+CPU where a domain run is also from where it tries to access its memory,
+i.e., that is one half of what decides whether a memory access is remote
+or local --- the other half being where the location it wants to access
+is stored.
+
+Of course, if a domain is known to only run on a subset of the physical
+CPUs of the host, it is very easy to turn all its memory accesses into
+local ones, by just constructing it's node affinity (in Xen) basing on
+what nodes these CPUs belongs to. Actually, that is exactly what is being
+done by the hypervisor by default, as soon as it finds out a domain (or
+better, the vcpus of a domain, but let's avoid getting into too much
+details here) has a cpu affinity.
+
+This is working quite well, but it requires the user/system administrator
+to explicitly specify such property --- the cpu affinity --- while the
+domain is being created, or Xen won't be able to exploit that for ensuring
+accesses locality.
+
+On the other hand, as node affinity directly affects where domain's memory
+lives, it makes a lot of sense for it to be involved in scheduling decisions,
+as it would be great if the hypervisor would manage in scheduling all the
+vcpus of all the domains on CPUs attached to the various domains' local
+memory. That is why, the node affinity of a domain is treated by the scheduler
+as the set of nodes on which it would be preferable to run it, although
+not at the cost of violating the scheduling algorithm behavior and
+invariants. This means it Xen will check whether a vcpu of a domain can run
+on one of the CPUs belonging to the nodes of the domain's node affinity,
+but will better run it somewhere else --- even on another, remote, CPU ---
+than violating the priority ordering (e.g., by kicking out from there another
+running vcpu with higher priority) it is designed to enforce.
+
+So, last but not least, what if a domain has both vcpu and node affinity, and
+they only partially match or they do not match at all (to understand how that
+can happen, see the following sections)? Well, in such case, all the domain
+memory will be allocated reflecting its node affinity, while scheduling will
+happen according to its vcpu affinities, meaning that it is easy enough to
+construct optimal, sub-optimal, neutral and even bad and awful configurations
+(which is something nice, e.g., for benchmarking purposes). The remainder
+part of this document is explaining how to do so.
+
+
+Specifying Node Affinity
+------------------------
+
+Besides being automatically computed from the vcpu affinities of a domain
+(or also from it being part of a cpupool) within Xen, it might make sense
+for the user to specify the node affinity of its domains by hand, while
+editing their config files, as another form of partitioning the host
+resources. If that is the case, this is where the "nodes" option of the xl
+config file becomes useful. In fact, specifying something like the below
+
+        nodes = [ '0', '1', '3', '4' ]
+
+in a domain configuration file would result in Xen assigning host NUMA nodes
+number 0, 1, 3 and 4 to the domain's node affinity, regardless of any vcpu
+affinity setting for the same domain. The idea is, yes, the to things are
+related, and if only one is present, it makes sense to use the other for
+inferring it, but it is always possible to explicitly specify both of them,
+independently on how good or awful it could end up being.
+
+Therefore, this is what one should expect when using "nodes", perhaps in
+conjunction with "cpus" in a domain configuration file:
+
+ * `cpus = "0, 1"` and no `nodes=` at all
+   (i.e., only vcpu affinity specified):
+     domain's vcpus can and will run only on host CPUs 0 and 1. Also, as
+     domain's node affinity will be computed by Xen and set to whatever
+     nodes host CPUs 0 and 1 belongs, all the domain's memory accesses will
+     be local accesses;
+
+ * `nodes = [ '0', '1' ]` and no `cpus=` at all
+   (i.e., only node affinity present):
+     domain's vcpus can run on any of the host CPUs, but the scheduler (at
+     least if credit is used, as it is the only scheduler supporting this
+     right now) will try running them on the CPUs that are part of host
+     NUMA nodes 0 and 1. Memory-wise, all the domain's memory will be
+     allocated on host NUMA nodes nodes 0 and 1. This means the most of
+     the memory accesses of the domain should be local, but that will
+     depend on the on-line load, behavior and actual scheduling of both
+     the domain in question and all the other domains on the same host;
+
+ * `nodes = [ '0', '1' ]` and `cpus = "0"`, with CPU 0 within node 0:
+   (i.e., cpu affinity subset of node affinity):
+     domain's vcpus can and will only run on host CPU 0. As node affinity
+     is being explicitly set to host NUMA nodes 0 and 1 --- which includes
+     CPU 0 --- all the memory access of the domain will be local;
+
+ * `nodes = [ '0', '1' ]` and `cpus = "0, 4", with CPU 0 in node 0 but
+   CPU 4 in, say, node 2 (i.e., cpu affinity superset of node affinity):
+     domain's vcpus can run on host CPUs 0 and 4, with CPU 4 not being within
+     the node affinity (explicitly set to host NUMA nodes 0 and 1). The
+     (credit) scheduler will try to keep memory accesses local by scheduling
+     the domain's vcpus on CPU 0, but it may not achieve 100% success;
+
+ * `nodes = [ '0', '1' ]` and `cpus = "4"`, with CPU 4 within, say, node 2
+   (i.e., cpu affinity disjointed with node affinity):
+     domain's vcpus can and will run only on host CPU 4, i.e., completely
+     "outside" of the chosen node affinity. That necessarily means all the
+     domain's memory access will be remote.
+
+
+Automatic NUMA Placement
+------------------------
+
+Just in case one does not want to take the burden of manually specifying
+all the node (and, perhaps, CPU) affinities for all its domains, xl implements
+some automatic placement logic. This basically means the user can ask the
+toolstack to try sorting things out in the best possible way for him.
+This is instead of specifying manually a domain's node affinity and can be
+paired or not with any vcpu affinity (in case it is, the relationship between
+vcpu and node affinities just stays as stated above). To serve this purpose,
+a new domain config switch has been introduces, i.e., the "nodes_policy"
+option. As the name suggests, it allows for specifying a policy to be used
+while attempting automatic placement of the new domain. Available policies
+at the time of writing are:
+
+ * "auto": automatic placement by means of a not better specified (xl
+           implementation dependant) algorithm. It is basically for those
+           who do want automatic placement, but have no idea what policy
+           or algorithm would be better... <<Just give me a sane default!>>
+
+ * "ffit": automatic placement via the First Fit algorithm, applied checking
+           the memory requirement of the domain against the amount of free
+           memory in the various host NUMA nodes;
+
+ * "bfit": automatic placement via the Best Fit algorithm, applied checking
+           the memory requirement of the domain against the amount of free
+           memory in the various host NUMA nodes;
+
+ * "wfit": automatic placement via the Worst Fit algorithm, applied checking
+           the memory requirement of the domain against the amount of free
+           memory in the various host NUMA nodes;
+
+The various algorithms have been implemented as they offer different behavior
+and performances (for different performance metrics). For instance, First Fit
+is known to be efficient and quick, and it generally works better than Best
+Fit wrt memory fragmentation, although it tends to occupy "early" nodes more
+than "late" ones. On the other hand, Best Fit aims at optimizing memory usage,
+although it introduces quite a bit of fragmentation, by leaving large amounts
+of small free memory areas. Finally, the idea behind Worst Fit is that it will
+leave big enough free memory chunks to limit the amount of fragmentation, but
+it (as well as Best Fit does) is more expensive in terms of execution time, as
+it needs the "list" of free memory areas to be kept sorted.
+ 
+Therefore, achieving automatic placement actually happens by properly using
+the "nodes" and "nodes_config" configuration options as follows:
+
+ * `nodes="auto` or `nodes_policy="auto"`:
+     xl will try fitting the domain on the host NUMA nodes by using its
+     own default placing algorithm, with default parameters. Most likely,
+     all nodes will be considered suitable for the domain (unless a vcpu
+     affinity is specified, see the last entry of this list;
+
+ * `nodes_policy="ffit"` (or `"bfit"`, `"wfit"`) and no `nodes=` at all:
+     xl will try fitting the domain on the host NUMA nodes by using the
+     requested policy. All nodes will be considered suitable for the
+     domain, and consecutive fitting attempts will be performed while
+     increasing the number of nodes on which to put the domain itself
+     (unless a vcpu affinity is specified, see the last entry of this list);
+
+ * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `nodes=2`:
+     xl will try fitting the domain on the host NUMA nodes by using the
+     requested policy and only the number of nodes specified in `nodes=`
+     (2 in this example). All the nodes will be considered suitable for
+     the domain, and consecutive attempts will be performed while
+     increasing such a value;
+
+ * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `cpus="0-6":
+     xl will try fitting the domain on the host NUMA nodes to which the CPUs
+     specified as vcpu affinity (0 to 6 in this example) belong, by using the
+     requested policy. In case it fails, consecutive fitting attempts will
+     be performed with both a reduced (first) and an increased (next) number
+     of nodes).
+
+Different usage patterns --- like specifying both a policy and a list of nodes
+are accepted, but does not make much sense after all. Therefore, although xl
+will try at its best to interpret user's will, the resulting behavior is
+somehow unspecified.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxh3-0003MS-CW; Wed, 11 Apr 2012 13:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHxh2-0003MD-36
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:34:40 +0000
Received: from [85.158.143.35:48535] by server-1.bemta-4.messagelabs.com id
	58/3C-20925-F68858F4; Wed, 11 Apr 2012 13:34:39 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334151277!10862979!1
X-Originating-IP: [82.57.200.103]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13469 invoked from network); 11 Apr 2012 13:34:37 -0000
Received: from smtp207.alice.it (HELO smtp207.alice.it) (82.57.200.103)
	by server-6.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 13:34:37 -0000
Received: from [192.168.178.50] (87.2.83.254) by smtp207.alice.it (8.6.023.02)
	id 4F05A6650B395A79 for xen-devel@lists.xensource.com;
	Wed, 11 Apr 2012 15:34:37 +0200
Message-ID: <4F858868.7040105@tiscali.it>
Date: Wed, 11 Apr 2012 15:34:32 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH v3] Autoconf: add variable for pass arbitrary
 options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============9133804742123389993=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============9133804742123389993==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050104070603080107080909"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms050104070603080107080909
Content-Type: multipart/mixed;
 boundary="------------050205080000060400010304"

This is a multi-part message in MIME format.
--------------050205080000060400010304
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1334149338 -7200
# Node ID b3fcddfb22f269f725d2b81a6c0737bd38a7dd32
# Parent  02996f14cf9af9e3acddabd1a2fa566223dcd44a
autoconf: add variable for pass arbitrary options to qemu upstream v3

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 02996f14cf9a -r b3fcddfb22f2 README
--- a/README    mer apr 11 14:26:12 2012 +0200
+++ b/README    mer apr 11 15:02:18 2012 +0200
@@ -67,6 +67,11 @@
      * Development install of Ocaml (e.g. ocaml-nox and
        ocaml-findlib). Required to build ocaml components which
        includes the alternative ocaml xenstored.
+    * Dev of spice protocol (e.g. libspice-protocol-dev >=3D0.10)
+    * Dev of spice server (e.g. libspice-server-dev >=3D0.10)
+      Required to build Spice for qemu upstream if enabled with configur=
e
+    * Dev of usb redirection (e.g. libusbredir-dev). Required to build u=
sb
+      redirection for qemu upstream if enabled with configure

  Second, you need to acquire a suitable kernel for use in domain 0. If
  possible you should use a kernel provided by your OS distributor. If
diff -r 02996f14cf9a -r b3fcddfb22f2 config/Tools.mk.in
--- a/config/Tools.mk.in    mer apr 11 14:26:12 2012 +0200
+++ b/config/Tools.mk.in    mer apr 11 15:02:18 2012 +0200
@@ -48,3 +48,4 @@
  CONFIG_GCRYPT       :=3D @libgcrypt@
  CONFIG_EXT2FS       :=3D @libext2fs@
  CURSES_LIBS         :=3D @CURSES_LIBS@
+CONFIG_QEMUU_ADD_PAR:=3D @qemuu_add_par@
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/Makefile
--- a/tools/Makefile    mer apr 11 14:26:12 2012 +0200
+++ b/tools/Makefile    mer apr 11 15:02:18 2012 +0200
@@ -157,6 +157,7 @@
          --datadir=3D$(SHAREDIR)/qemu-xen \
          --disable-kvm \
          --python=3D$(PYTHON) \
+        $(CONFIG_QEMUU_ADD_PAR) \
          $(IOEMU_CONFIGURE_CROSS); \
      $(MAKE) install

diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure
--- a/tools/configure    mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure    mer apr 11 15:02:18 2012 +0200
@@ -649,6 +649,7 @@
  APPEND_INCLUDES
  PREPEND_LIB
  PREPEND_INCLUDES
+qemuu_add_par
  debug
  lomount
  miniterm
@@ -726,6 +727,9 @@
  enable_miniterm
  enable_lomount
  enable_debug
+enable_qemuu_spice
+enable_qemuu_usbredir
+enable_qemuu_debug
  '
        ac_precious_vars=3D'build_alias
  host_alias
@@ -1384,6 +1388,9 @@
    --enable-miniterm       Enable miniterm (default is DISABLED)
    --enable-lomount        Enable lomount (default is DISABLED)
    --disable-debug         Disable debug build of tools (default is=20
ENABLED)
+  --enable-qemuu-spice    Enable Spice build on qemu upstream
+  --enable-qemuu-usbredir    Enable usb redirection build on qemu upstre=
am
+  --enable-qemuu-debug    Enable debug build on qemu upstream

  Some influential environment variables:
    CC          C compiler command
@@ -4133,6 +4140,22 @@
  debug=3D$ax_cv_debug


+# Check whether --enable-qemuu-spice was given.
+if test "${enable_qemuu_spice+set}" =3D set; then :
+  enableval=3D$enable_qemuu_spice; qemuu_add_par+=3D" --enable-spice"
+fi
+
+# Check whether --enable-qemuu-usbredir was given.
+if test "${enable_qemuu_usbredir+set}" =3D set; then :
+  enableval=3D$enable_qemuu_usbredir; qemuu_add_par+=3D" --enable-usb-re=
dir"
+fi
+
+# Check whether --enable-qemuu-debug was given.
+if test "${enable_qemuu_debug+set}" =3D set; then :
+  enableval=3D$enable_qemuu_debug; qemuu_add_par+=3D" --enable-debug"
+fi
+
+



diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure.ac
--- a/tools/configure.ac    mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure.ac    mer apr 11 15:02:18 2012 +0200
@@ -44,6 +44,16 @@
  AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
  AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
  AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice    Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir    Enable usb redirection build on qemu=20
upstream],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug    Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)

  AC_ARG_VAR([PREPEND_INCLUDES],
      [List of include folders to prepend to CFLAGS (without -I)])


--------------050205080000060400010304
Content-Type: text/plain; charset=windows-1252;
 name="autoconf_add_arbitrary_options_qemuu_v3.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="autoconf_add_arbitrary_options_qemuu_v3.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1334149338 -7200
# Node ID b3fcddfb22f269f725d2b81a6c0737bd38a7dd32
# Parent  02996f14cf9af9e3acddabd1a2fa566223dcd44a
autoconf: add variable for pass arbitrary options to qemu upstream v3

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 02996f14cf9a -r b3fcddfb22f2 README
--- a/README	mer apr 11 14:26:12 2012 +0200
+++ b/README	mer apr 11 15:02:18 2012 +0200
@@ -67,6 +67,11 @@
     * Development install of Ocaml (e.g. ocaml-nox and
       ocaml-findlib). Required to build ocaml components which
       includes the alternative ocaml xenstored.
+    * Dev of spice protocol (e.g. libspice-protocol-dev >=3D0.10)
+    * Dev of spice server (e.g. libspice-server-dev >=3D0.10)
+      Required to build Spice for qemu upstream if enabled with configur=
e
+    * Dev of usb redirection (e.g. libusbredir-dev). Required to build u=
sb
+      redirection for qemu upstream if enabled with configure
=20
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
diff -r 02996f14cf9a -r b3fcddfb22f2 config/Tools.mk.in
--- a/config/Tools.mk.in	mer apr 11 14:26:12 2012 +0200
+++ b/config/Tools.mk.in	mer apr 11 15:02:18 2012 +0200
@@ -48,3 +48,4 @@
 CONFIG_GCRYPT       :=3D @libgcrypt@
 CONFIG_EXT2FS       :=3D @libext2fs@
 CURSES_LIBS         :=3D @CURSES_LIBS@
+CONFIG_QEMUU_ADD_PAR:=3D @qemuu_add_par@
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/Makefile
--- a/tools/Makefile	mer apr 11 14:26:12 2012 +0200
+++ b/tools/Makefile	mer apr 11 15:02:18 2012 +0200
@@ -157,6 +157,7 @@
 		--datadir=3D$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
 		--python=3D$(PYTHON) \
+		$(CONFIG_QEMUU_ADD_PAR) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install
=20
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure
--- a/tools/configure	mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure	mer apr 11 15:02:18 2012 +0200
@@ -649,6 +649,7 @@
 APPEND_INCLUDES
 PREPEND_LIB
 PREPEND_INCLUDES
+qemuu_add_par
 debug
 lomount
 miniterm
@@ -726,6 +727,9 @@
 enable_miniterm
 enable_lomount
 enable_debug
+enable_qemuu_spice
+enable_qemuu_usbredir
+enable_qemuu_debug
 '
       ac_precious_vars=3D'build_alias
 host_alias
@@ -1384,6 +1388,9 @@
   --enable-miniterm       Enable miniterm (default is DISABLED)
   --enable-lomount        Enable lomount (default is DISABLED)
   --disable-debug         Disable debug build of tools (default is ENABL=
ED)
+  --enable-qemuu-spice	Enable Spice build on qemu upstream
+  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream
+  --enable-qemuu-debug	Enable debug build on qemu upstream
=20
 Some influential environment variables:
   CC          C compiler command
@@ -4133,6 +4140,22 @@
 debug=3D$ax_cv_debug
=20
=20
+# Check whether --enable-qemuu-spice was given.
+if test "${enable_qemuu_spice+set}" =3D set; then :
+  enableval=3D$enable_qemuu_spice; qemuu_add_par+=3D" --enable-spice"
+fi
+
+# Check whether --enable-qemuu-usbredir was given.
+if test "${enable_qemuu_usbredir+set}" =3D set; then :
+  enableval=3D$enable_qemuu_usbredir; qemuu_add_par+=3D" --enable-usb-re=
dir"
+fi
+
+# Check whether --enable-qemuu-debug was given.
+if test "${enable_qemuu_debug+set}" =3D set; then :
+  enableval=3D$enable_qemuu_debug; qemuu_add_par+=3D" --enable-debug"
+fi
+
+
=20
=20
=20
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure.ac
--- a/tools/configure.ac	mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure.ac	mer apr 11 15:02:18 2012 +0200
@@ -44,6 +44,16 @@
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice	Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream=
],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug	Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)
=20
 AC_ARG_VAR([PREPEND_INCLUDES],
     [List of include folders to prepend to CFLAGS (without -I)])

--------------050205080000060400010304--

--------------ms050104070603080107080909
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQxMTEzMzQzMlowIwYJKoZIhvcNAQkEMRYEFGjNUx1M/HYB0xrDuGf/OoKw
I3p0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBBqHgyXxVenoJ1ZiEVZc0NAyEiL0A1a1q402QdMEUe
yoJskx8yEtJwbHWgniAZz06SruPMVDuvE5RyLrGWoZdxocgi0+gKMEaqWMsSf2Qhcsw1+VBd
F3E4sdiJjS1JBRoRnXsx1G4pFQxLlCFFzbjA/D7q+Ph6l9q97ii4EU/lEr1+9L8dPtlrf9lW
Ev+a3JIN4+bnB2dI3CeQ1pPYwIUzy8IcnvfIagWz7sRUIuf/8VmQdEb3IZPxITIY9ryUa/Dj
pdttdRUft9dbdBffYRmiXV8eh+dECL0O8DbmUko6iDT7rBpLjZfWDG74Jw5v6/MhWdi5BRyL
ioVYTsmgQtWkAAAAAAAA
--------------ms050104070603080107080909--


--===============9133804742123389993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9133804742123389993==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 13:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxh3-0003MS-CW; Wed, 11 Apr 2012 13:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SHxh2-0003MD-36
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:34:40 +0000
Received: from [85.158.143.35:48535] by server-1.bemta-4.messagelabs.com id
	58/3C-20925-F68858F4; Wed, 11 Apr 2012 13:34:39 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334151277!10862979!1
X-Originating-IP: [82.57.200.103]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13469 invoked from network); 11 Apr 2012 13:34:37 -0000
Received: from smtp207.alice.it (HELO smtp207.alice.it) (82.57.200.103)
	by server-6.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 13:34:37 -0000
Received: from [192.168.178.50] (87.2.83.254) by smtp207.alice.it (8.6.023.02)
	id 4F05A6650B395A79 for xen-devel@lists.xensource.com;
	Wed, 11 Apr 2012 15:34:37 +0200
Message-ID: <4F858868.7040105@tiscali.it>
Date: Wed, 11 Apr 2012 15:34:32 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH v3] Autoconf: add variable for pass arbitrary
 options to qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============9133804742123389993=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============9133804742123389993==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050104070603080107080909"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms050104070603080107080909
Content-Type: multipart/mixed;
 boundary="------------050205080000060400010304"

This is a multi-part message in MIME format.
--------------050205080000060400010304
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1334149338 -7200
# Node ID b3fcddfb22f269f725d2b81a6c0737bd38a7dd32
# Parent  02996f14cf9af9e3acddabd1a2fa566223dcd44a
autoconf: add variable for pass arbitrary options to qemu upstream v3

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 02996f14cf9a -r b3fcddfb22f2 README
--- a/README    mer apr 11 14:26:12 2012 +0200
+++ b/README    mer apr 11 15:02:18 2012 +0200
@@ -67,6 +67,11 @@
      * Development install of Ocaml (e.g. ocaml-nox and
        ocaml-findlib). Required to build ocaml components which
        includes the alternative ocaml xenstored.
+    * Dev of spice protocol (e.g. libspice-protocol-dev >=3D0.10)
+    * Dev of spice server (e.g. libspice-server-dev >=3D0.10)
+      Required to build Spice for qemu upstream if enabled with configur=
e
+    * Dev of usb redirection (e.g. libusbredir-dev). Required to build u=
sb
+      redirection for qemu upstream if enabled with configure

  Second, you need to acquire a suitable kernel for use in domain 0. If
  possible you should use a kernel provided by your OS distributor. If
diff -r 02996f14cf9a -r b3fcddfb22f2 config/Tools.mk.in
--- a/config/Tools.mk.in    mer apr 11 14:26:12 2012 +0200
+++ b/config/Tools.mk.in    mer apr 11 15:02:18 2012 +0200
@@ -48,3 +48,4 @@
  CONFIG_GCRYPT       :=3D @libgcrypt@
  CONFIG_EXT2FS       :=3D @libext2fs@
  CURSES_LIBS         :=3D @CURSES_LIBS@
+CONFIG_QEMUU_ADD_PAR:=3D @qemuu_add_par@
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/Makefile
--- a/tools/Makefile    mer apr 11 14:26:12 2012 +0200
+++ b/tools/Makefile    mer apr 11 15:02:18 2012 +0200
@@ -157,6 +157,7 @@
          --datadir=3D$(SHAREDIR)/qemu-xen \
          --disable-kvm \
          --python=3D$(PYTHON) \
+        $(CONFIG_QEMUU_ADD_PAR) \
          $(IOEMU_CONFIGURE_CROSS); \
      $(MAKE) install

diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure
--- a/tools/configure    mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure    mer apr 11 15:02:18 2012 +0200
@@ -649,6 +649,7 @@
  APPEND_INCLUDES
  PREPEND_LIB
  PREPEND_INCLUDES
+qemuu_add_par
  debug
  lomount
  miniterm
@@ -726,6 +727,9 @@
  enable_miniterm
  enable_lomount
  enable_debug
+enable_qemuu_spice
+enable_qemuu_usbredir
+enable_qemuu_debug
  '
        ac_precious_vars=3D'build_alias
  host_alias
@@ -1384,6 +1388,9 @@
    --enable-miniterm       Enable miniterm (default is DISABLED)
    --enable-lomount        Enable lomount (default is DISABLED)
    --disable-debug         Disable debug build of tools (default is=20
ENABLED)
+  --enable-qemuu-spice    Enable Spice build on qemu upstream
+  --enable-qemuu-usbredir    Enable usb redirection build on qemu upstre=
am
+  --enable-qemuu-debug    Enable debug build on qemu upstream

  Some influential environment variables:
    CC          C compiler command
@@ -4133,6 +4140,22 @@
  debug=3D$ax_cv_debug


+# Check whether --enable-qemuu-spice was given.
+if test "${enable_qemuu_spice+set}" =3D set; then :
+  enableval=3D$enable_qemuu_spice; qemuu_add_par+=3D" --enable-spice"
+fi
+
+# Check whether --enable-qemuu-usbredir was given.
+if test "${enable_qemuu_usbredir+set}" =3D set; then :
+  enableval=3D$enable_qemuu_usbredir; qemuu_add_par+=3D" --enable-usb-re=
dir"
+fi
+
+# Check whether --enable-qemuu-debug was given.
+if test "${enable_qemuu_debug+set}" =3D set; then :
+  enableval=3D$enable_qemuu_debug; qemuu_add_par+=3D" --enable-debug"
+fi
+
+



diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure.ac
--- a/tools/configure.ac    mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure.ac    mer apr 11 15:02:18 2012 +0200
@@ -44,6 +44,16 @@
  AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
  AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
  AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice    Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir    Enable usb redirection build on qemu=20
upstream],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug    Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)

  AC_ARG_VAR([PREPEND_INCLUDES],
      [List of include folders to prepend to CFLAGS (without -I)])


--------------050205080000060400010304
Content-Type: text/plain; charset=windows-1252;
 name="autoconf_add_arbitrary_options_qemuu_v3.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="autoconf_add_arbitrary_options_qemuu_v3.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1334149338 -7200
# Node ID b3fcddfb22f269f725d2b81a6c0737bd38a7dd32
# Parent  02996f14cf9af9e3acddabd1a2fa566223dcd44a
autoconf: add variable for pass arbitrary options to qemu upstream v3

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 02996f14cf9a -r b3fcddfb22f2 README
--- a/README	mer apr 11 14:26:12 2012 +0200
+++ b/README	mer apr 11 15:02:18 2012 +0200
@@ -67,6 +67,11 @@
     * Development install of Ocaml (e.g. ocaml-nox and
       ocaml-findlib). Required to build ocaml components which
       includes the alternative ocaml xenstored.
+    * Dev of spice protocol (e.g. libspice-protocol-dev >=3D0.10)
+    * Dev of spice server (e.g. libspice-server-dev >=3D0.10)
+      Required to build Spice for qemu upstream if enabled with configur=
e
+    * Dev of usb redirection (e.g. libusbredir-dev). Required to build u=
sb
+      redirection for qemu upstream if enabled with configure
=20
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
diff -r 02996f14cf9a -r b3fcddfb22f2 config/Tools.mk.in
--- a/config/Tools.mk.in	mer apr 11 14:26:12 2012 +0200
+++ b/config/Tools.mk.in	mer apr 11 15:02:18 2012 +0200
@@ -48,3 +48,4 @@
 CONFIG_GCRYPT       :=3D @libgcrypt@
 CONFIG_EXT2FS       :=3D @libext2fs@
 CURSES_LIBS         :=3D @CURSES_LIBS@
+CONFIG_QEMUU_ADD_PAR:=3D @qemuu_add_par@
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/Makefile
--- a/tools/Makefile	mer apr 11 14:26:12 2012 +0200
+++ b/tools/Makefile	mer apr 11 15:02:18 2012 +0200
@@ -157,6 +157,7 @@
 		--datadir=3D$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
 		--python=3D$(PYTHON) \
+		$(CONFIG_QEMUU_ADD_PAR) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install
=20
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure
--- a/tools/configure	mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure	mer apr 11 15:02:18 2012 +0200
@@ -649,6 +649,7 @@
 APPEND_INCLUDES
 PREPEND_LIB
 PREPEND_INCLUDES
+qemuu_add_par
 debug
 lomount
 miniterm
@@ -726,6 +727,9 @@
 enable_miniterm
 enable_lomount
 enable_debug
+enable_qemuu_spice
+enable_qemuu_usbredir
+enable_qemuu_debug
 '
       ac_precious_vars=3D'build_alias
 host_alias
@@ -1384,6 +1388,9 @@
   --enable-miniterm       Enable miniterm (default is DISABLED)
   --enable-lomount        Enable lomount (default is DISABLED)
   --disable-debug         Disable debug build of tools (default is ENABL=
ED)
+  --enable-qemuu-spice	Enable Spice build on qemu upstream
+  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream
+  --enable-qemuu-debug	Enable debug build on qemu upstream
=20
 Some influential environment variables:
   CC          C compiler command
@@ -4133,6 +4140,22 @@
 debug=3D$ax_cv_debug
=20
=20
+# Check whether --enable-qemuu-spice was given.
+if test "${enable_qemuu_spice+set}" =3D set; then :
+  enableval=3D$enable_qemuu_spice; qemuu_add_par+=3D" --enable-spice"
+fi
+
+# Check whether --enable-qemuu-usbredir was given.
+if test "${enable_qemuu_usbredir+set}" =3D set; then :
+  enableval=3D$enable_qemuu_usbredir; qemuu_add_par+=3D" --enable-usb-re=
dir"
+fi
+
+# Check whether --enable-qemuu-debug was given.
+if test "${enable_qemuu_debug+set}" =3D set; then :
+  enableval=3D$enable_qemuu_debug; qemuu_add_par+=3D" --enable-debug"
+fi
+
+
=20
=20
=20
diff -r 02996f14cf9a -r b3fcddfb22f2 tools/configure.ac
--- a/tools/configure.ac	mer apr 11 14:26:12 2012 +0200
+++ b/tools/configure.ac	mer apr 11 15:02:18 2012 +0200
@@ -44,6 +44,16 @@
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
+AC_ARG_ENABLE([qemuu-spice],
+[  --enable-qemuu-spice	Enable Spice build on qemu upstream],
+[qemuu_add_par+=3D" --enable-spice"])
+AC_ARG_ENABLE([qemuu-usbredir],
+[  --enable-qemuu-usbredir	Enable usb redirection build on qemu upstream=
],
+[qemuu_add_par+=3D" --enable-usb-redir"])
+AC_ARG_ENABLE([qemuu-debug],
+[  --enable-qemuu-debug	Enable debug build on qemu upstream],
+[qemuu_add_par+=3D" --enable-debug"])
+AC_SUBST(qemuu_add_par)
=20
 AC_ARG_VAR([PREPEND_INCLUDES],
     [List of include folders to prepend to CFLAGS (without -I)])

--------------050205080000060400010304--

--------------ms050104070603080107080909
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQxMTEzMzQzMlowIwYJKoZIhvcNAQkEMRYEFGjNUx1M/HYB0xrDuGf/OoKw
I3p0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBBqHgyXxVenoJ1ZiEVZc0NAyEiL0A1a1q402QdMEUe
yoJskx8yEtJwbHWgniAZz06SruPMVDuvE5RyLrGWoZdxocgi0+gKMEaqWMsSf2Qhcsw1+VBd
F3E4sdiJjS1JBRoRnXsx1G4pFQxLlCFFzbjA/D7q+Ph6l9q97ii4EU/lEr1+9L8dPtlrf9lW
Ev+a3JIN4+bnB2dI3CeQ1pPYwIUzy8IcnvfIagWz7sRUIuf/8VmQdEb3IZPxITIY9ryUa/Dj
pdttdRUft9dbdBffYRmiXV8eh+dECL0O8DbmUko6iDT7rBpLjZfWDG74Jw5v6/MhWdi5BRyL
ioVYTsmgQtWkAAAAAAAA
--------------ms050104070603080107080909--


--===============9133804742123389993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9133804742123389993==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 13:36:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxiW-0003Tr-2A; Wed, 11 Apr 2012 13:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHxiU-0003Th-Ma
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:36:10 +0000
Received: from [85.158.138.51:25942] by server-5.bemta-3.messagelabs.com id
	39/6F-17113-9C8858F4; Wed, 11 Apr 2012 13:36:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334151369!21659265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1665 invoked from network); 11 Apr 2012 13:36:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11879103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 13:35:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 14:35:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHxiD-0002zX-4m	for xen-devel@lists.xen.org;
	Wed, 11 Apr 2012 13:35:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHxiD-0004Yb-3r	for
	xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:35:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.35001.75490.545688@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 14:35:53 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v5 00/19] libxl: improvements,
	prep for subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("[PATCH v5 00/19] libxl: improvements, prep for subprocess handling"):
> This is the initial portion of my child process series which has been
> acked and which I intend to apply right away.  Changes are exactly
> those discussed on the list since v4; I'm reposting the final version
> for form's sake.

I have now pushed these to xen-unstable.  Thanks to Ian Campbell for
the reviews and to Roger Pau Monne for bug reports and fixes!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:36:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxiW-0003Tr-2A; Wed, 11 Apr 2012 13:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHxiU-0003Th-Ma
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:36:10 +0000
Received: from [85.158.138.51:25942] by server-5.bemta-3.messagelabs.com id
	39/6F-17113-9C8858F4; Wed, 11 Apr 2012 13:36:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334151369!21659265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1665 invoked from network); 11 Apr 2012 13:36:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11879103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 13:35:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 14:35:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHxiD-0002zX-4m	for xen-devel@lists.xen.org;
	Wed, 11 Apr 2012 13:35:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHxiD-0004Yb-3r	for
	xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:35:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.35001.75490.545688@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 14:35:53 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334149181-2834-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v5 00/19] libxl: improvements,
	prep for subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("[PATCH v5 00/19] libxl: improvements, prep for subprocess handling"):
> This is the initial portion of my child process series which has been
> acked and which I intend to apply right away.  Changes are exactly
> those discussed on the list since v4; I'm reposting the final version
> for form's sake.

I have now pushed these to xen-unstable.  Thanks to Ian Campbell for
the reviews and to Roger Pau Monne for bug reports and fixes!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxki-0003eK-VY; Wed, 11 Apr 2012 13:38:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxki-0003dw-2D
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:28 +0000
Received: from [85.158.138.51:25510] by server-1.bemta-3.messagelabs.com id
	11/CA-11491-359858F4; Wed, 11 Apr 2012 13:38:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334151502!21607830!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9602 invoked from network); 11 Apr 2012 13:38:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819688"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:22 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWR-0006xC-1j; Wed, 11 Apr 2012 14:23:43 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:31 +0100
Message-ID: <1334150851-8715-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 6/6] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Spawn a QEMU instance at boot time to handle disk local attach
requests.

- Implement libxl_device_disk_local_attach for QDISKs in terms of a
regular disk attach with the frontend and backend running in the same
domain.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl_internal.c                    |   49 +++++++++++++++++-----
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons
index 6543204..0f3b9ad 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -12,3 +12,6 @@
 
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
+
+# qemu path and log file
+#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 6c72dd8..3b579ae 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -103,6 +103,9 @@ do_start () {
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
 	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting QEMU as disk backend for dom0
+	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 60de726..3ff2e06 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -550,13 +550,31 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
+                xs_transaction_t t;
+                do {
+                    t = xs_transaction_start(ctx->xsh);
+                    /* use 0 as the domid of the toolstack domain for now */
+                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);
+                    if (tmpdisk->vdev == NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl__alloc_vdev failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    if (libxl__device_disk_add_t(gc, 0, t, tmpdisk)) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl_device_disk_add failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    rc = xs_transaction_end(ctx->xsh, t, 0);
+                } while (rc == 0 && errno == EAGAIN);
+                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);
+            } else {
+                dev = tmpdisk->pdev_path;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = tmpdisk->pdev_path;
+                       dev);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
@@ -571,12 +589,21 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+                libxl_device_disk_remove(gc->owner, 0, disk, 0);
+                return libxl_device_disk_destroy(gc->owner, 0, disk);
+            }
+            break;
+        default:
+            /*
+             * Nothing to do for PHYSTYPE_PHY.
+             * For other device types assume that the blktap2 process is
+             * needed by the soon to be started domain and do nothing.
+             */
+            break;
+    }
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxki-0003eK-VY; Wed, 11 Apr 2012 13:38:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxki-0003dw-2D
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:28 +0000
Received: from [85.158.138.51:25510] by server-1.bemta-3.messagelabs.com id
	11/CA-11491-359858F4; Wed, 11 Apr 2012 13:38:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334151502!21607830!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9602 invoked from network); 11 Apr 2012 13:38:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819688"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:22 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWR-0006xC-1j; Wed, 11 Apr 2012 14:23:43 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:31 +0100
Message-ID: <1334150851-8715-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 6/6] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Spawn a QEMU instance at boot time to handle disk local attach
requests.

- Implement libxl_device_disk_local_attach for QDISKs in terms of a
regular disk attach with the frontend and backend running in the same
domain.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl_internal.c                    |   49 +++++++++++++++++-----
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons
index 6543204..0f3b9ad 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -12,3 +12,6 @@
 
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
+
+# qemu path and log file
+#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 6c72dd8..3b579ae 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -103,6 +103,9 @@ do_start () {
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
 	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting QEMU as disk backend for dom0
+	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 60de726..3ff2e06 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -550,13 +550,31 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
+                xs_transaction_t t;
+                do {
+                    t = xs_transaction_start(ctx->xsh);
+                    /* use 0 as the domid of the toolstack domain for now */
+                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);
+                    if (tmpdisk->vdev == NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl__alloc_vdev failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    if (libxl__device_disk_add_t(gc, 0, t, tmpdisk)) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl_device_disk_add failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    rc = xs_transaction_end(ctx->xsh, t, 0);
+                } while (rc == 0 && errno == EAGAIN);
+                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);
+            } else {
+                dev = tmpdisk->pdev_path;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = tmpdisk->pdev_path;
+                       dev);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
@@ -571,12 +589,21 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+                libxl_device_disk_remove(gc->owner, 0, disk, 0);
+                return libxl_device_disk_destroy(gc->owner, 0, disk);
+            }
+            break;
+        default:
+            /*
+             * Nothing to do for PHYSTYPE_PHY.
+             * For other device types assume that the blktap2 process is
+             * needed by the soon to be started domain and do nothing.
+             */
+            break;
+    }
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkj-0003eS-Bd; Wed, 11 Apr 2012 13:38:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxki-0003dz-0J
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:28 +0000
Received: from [85.158.143.35:17553] by server-3.bemta-4.messagelabs.com id
	76/0B-05853-359858F4; Wed, 11 Apr 2012 13:38:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334151504!18128914!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16039 invoked from network); 11 Apr 2012 13:38:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819704"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-OR; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:29 +0100
Message-ID: <1334150851-8715-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 4/6] xl/libxl: add a blkdev_start parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a blkdev_start in xl.conf and pass it to
libxl_domain_create_* and all the way through libxl_run_bootloader and
libxl__device_disk_local_attach.

blkdev_start specifies the first block device to be used for temporary
block device allocations by the toolstack.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/examples/xl.conf         |    3 +++
 tools/libxl/libxl.h            |   10 +++++++---
 tools/libxl/libxl_bootloader.c |    6 ++++--
 tools/libxl/libxl_create.c     |   18 ++++++++++++------
 tools/libxl/libxl_internal.c   |    3 ++-
 tools/libxl/libxl_internal.h   |    3 ++-
 tools/libxl/xl.c               |    3 +++
 tools/libxl/xl.h               |    1 +
 tools/libxl/xl_cmdimpl.c       |    5 +++--
 9 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..ebf057c 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# first block device to be used for temporary VM disk mounts
+#blkdev_start="xvda"
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1e7b1b9..60a775e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -382,8 +382,11 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, char* blkdev_start);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd,
+		char *blkdev_start);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
@@ -411,7 +414,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         char *blkdev_start);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 429253d..fe56615 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -323,7 +323,8 @@ static void parse_bootloader_result(libxl__gc *gc,
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid)
+                         uint32_t domid,
+                         char *blkdev_start)
 {
     GC_INIT(ctx);
     int ret, rc = 0;
@@ -387,7 +388,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk,
+            blkdev_start);
     if (!diskpath) {
         goto out_close;
     }
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index dbff02c..03348d2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -531,7 +531,8 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+                            uint32_t *domid_out, int restore_fd,
+							char* blkdev_start)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
@@ -568,7 +569,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     }
 
     if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+        ret = libxl_run_bootloader(ctx, &d_config->b_info,
+                d_config->num_disks > 0 ? &d_config->disks[0] : NULL,
+                domid, blkdev_start);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
@@ -722,21 +725,24 @@ error_out:
 }
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+							char* blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1, blkdev_start);
     GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv, uint32_t *domid,
+								int restore_fd, char *blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd,
+			blkdev_start);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 43ce31b..a21c9c1 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -482,7 +482,8 @@ out:
 
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk)
+        libxl_device_disk **new_disk,
+        char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 429624d..584f22d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -996,7 +996,8 @@ _hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk);
+        libxl_device_disk **new_disk,
+        char *blkdev_start);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..5352bb2 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -36,6 +36,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+char *blkdev_start = "xvda";
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -92,6 +93,8 @@ static void parse_global_config(const char *configfile,
             fprintf(stderr, "invalid default output format \"%s\"\n", buf);
         }
     }
+    if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0))
+        blkdev_start = strdup(buf);
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 702b208..4a384fb 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -111,6 +111,7 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 extern char *default_bridge;
+extern char *blkdev_start;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 1d59b89..439e9bc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1636,7 +1636,7 @@ start:
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
                                             cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                            &domid, restore_fd, blkdev_start);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1644,7 +1644,8 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                        cb, &child_console_pid, &domid,
+										blkdev_start);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkj-0003eS-Bd; Wed, 11 Apr 2012 13:38:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxki-0003dz-0J
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:28 +0000
Received: from [85.158.143.35:17553] by server-3.bemta-4.messagelabs.com id
	76/0B-05853-359858F4; Wed, 11 Apr 2012 13:38:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334151504!18128914!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA3MDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16039 invoked from network); 11 Apr 2012 13:38:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819704"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-OR; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:29 +0100
Message-ID: <1334150851-8715-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 4/6] xl/libxl: add a blkdev_start parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a blkdev_start in xl.conf and pass it to
libxl_domain_create_* and all the way through libxl_run_bootloader and
libxl__device_disk_local_attach.

blkdev_start specifies the first block device to be used for temporary
block device allocations by the toolstack.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/examples/xl.conf         |    3 +++
 tools/libxl/libxl.h            |   10 +++++++---
 tools/libxl/libxl_bootloader.c |    6 ++++--
 tools/libxl/libxl_create.c     |   18 ++++++++++++------
 tools/libxl/libxl_internal.c   |    3 ++-
 tools/libxl/libxl_internal.h   |    3 ++-
 tools/libxl/xl.c               |    3 +++
 tools/libxl/xl.h               |    1 +
 tools/libxl/xl_cmdimpl.c       |    5 +++--
 9 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..ebf057c 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# first block device to be used for temporary VM disk mounts
+#blkdev_start="xvda"
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1e7b1b9..60a775e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -382,8 +382,11 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, char* blkdev_start);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd,
+		char *blkdev_start);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
@@ -411,7 +414,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         char *blkdev_start);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 429253d..fe56615 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -323,7 +323,8 @@ static void parse_bootloader_result(libxl__gc *gc,
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid)
+                         uint32_t domid,
+                         char *blkdev_start)
 {
     GC_INIT(ctx);
     int ret, rc = 0;
@@ -387,7 +388,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk,
+            blkdev_start);
     if (!diskpath) {
         goto out_close;
     }
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index dbff02c..03348d2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -531,7 +531,8 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+                            uint32_t *domid_out, int restore_fd,
+							char* blkdev_start)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
@@ -568,7 +569,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     }
 
     if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+        ret = libxl_run_bootloader(ctx, &d_config->b_info,
+                d_config->num_disks > 0 ? &d_config->disks[0] : NULL,
+                domid, blkdev_start);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
@@ -722,21 +725,24 @@ error_out:
 }
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+							char* blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1, blkdev_start);
     GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv, uint32_t *domid,
+								int restore_fd, char *blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd,
+			blkdev_start);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 43ce31b..a21c9c1 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -482,7 +482,8 @@ out:
 
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk)
+        libxl_device_disk **new_disk,
+        char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 429624d..584f22d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -996,7 +996,8 @@ _hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk);
+        libxl_device_disk **new_disk,
+        char *blkdev_start);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..5352bb2 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -36,6 +36,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+char *blkdev_start = "xvda";
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -92,6 +93,8 @@ static void parse_global_config(const char *configfile,
             fprintf(stderr, "invalid default output format \"%s\"\n", buf);
         }
     }
+    if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0))
+        blkdev_start = strdup(buf);
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 702b208..4a384fb 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -111,6 +111,7 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 extern char *default_bridge;
+extern char *blkdev_start;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 1d59b89..439e9bc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1636,7 +1636,7 @@ start:
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
                                             cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                            &domid, restore_fd, blkdev_start);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1644,7 +1644,8 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                        cb, &child_console_pid, &domid,
+										blkdev_start);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxki-0003eB-JN; Wed, 11 Apr 2012 13:38:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkg-0003dr-W4
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:27 +0000
Received: from [85.158.138.51:62970] by server-2.bemta-3.messagelabs.com id
	05/50-09269-259858F4; Wed, 11 Apr 2012 13:38:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334151502!21607830!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9493 invoked from network); 11 Apr 2012 13:38:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819670"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:22 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-4F; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:27 +0100
Message-ID: <1334150851-8715-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/6] libxl: add a transaction parameter to
	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
XBT_NULL, allocate a proper one.

Update all the callers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |   10 +++++-----
 tools/libxl/libxl_device.c   |   14 +++++++-------
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_pci.c      |    2 +-
 4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 144cd94..6461f17 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1381,7 +1381,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -1775,7 +1775,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -2053,7 +2053,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
     }
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2124,7 +2124,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2257,7 +2257,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
                           libxl__sprintf(gc, "%d", vfb->backend_domid));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..83abe59 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
-int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *frontend_path, *backend_path;
-    xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    int create_transaction = t == XBT_NULL;
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
@@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].perms = XS_PERM_READ;
 
 retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
+    if (create_transaction)
+        t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
 
     if (fents) {
@@ -101,13 +102,12 @@ retry_transaction:
     }
 
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
-        if (errno == EAGAIN)
+        if (errno == EAGAIN && create_transaction)
             goto retry_transaction;
         else
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
     }
-
-    return 0;
+    return ERROR_FAIL;
 }
 
 typedef struct {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c41db3c..7bc75b8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -665,8 +665,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
-_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4175ac3..6b312a1 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -242,7 +242,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxki-0003eB-JN; Wed, 11 Apr 2012 13:38:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkg-0003dr-W4
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:27 +0000
Received: from [85.158.138.51:62970] by server-2.bemta-3.messagelabs.com id
	05/50-09269-259858F4; Wed, 11 Apr 2012 13:38:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334151502!21607830!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9493 invoked from network); 11 Apr 2012 13:38:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819670"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:22 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-4F; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:27 +0100
Message-ID: <1334150851-8715-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/6] libxl: add a transaction parameter to
	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
XBT_NULL, allocate a proper one.

Update all the callers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |   10 +++++-----
 tools/libxl/libxl_device.c   |   14 +++++++-------
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_pci.c      |    2 +-
 4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 144cd94..6461f17 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1381,7 +1381,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -1775,7 +1775,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -2053,7 +2053,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
     }
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2124,7 +2124,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2257,7 +2257,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
                           libxl__sprintf(gc, "%d", vfb->backend_domid));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..83abe59 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
-int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *frontend_path, *backend_path;
-    xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    int create_transaction = t == XBT_NULL;
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
@@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].perms = XS_PERM_READ;
 
 retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
+    if (create_transaction)
+        t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
 
     if (fents) {
@@ -101,13 +102,12 @@ retry_transaction:
     }
 
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
-        if (errno == EAGAIN)
+        if (errno == EAGAIN && create_transaction)
             goto retry_transaction;
         else
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
     }
-
-    return 0;
+    return ERROR_FAIL;
 }
 
 typedef struct {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c41db3c..7bc75b8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -665,8 +665,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
-_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4175ac3..6b312a1 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -242,7 +242,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkn-0003g7-Ad; Wed, 11 Apr 2012 13:38:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkm-0003fM-B7
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:32 +0000
Received: from [193.109.254.147:32818] by server-9.bemta-14.messagelabs.com id
	6E/ED-05787-759858F4; Wed, 11 Apr 2012 13:38:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334151506!4135172!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14542 invoked from network); 11 Apr 2012 13:38:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819721"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWO-0006xC-JF; Wed, 11 Apr 2012 14:23:41 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:26 +0100
Message-ID: <1334150851-8715-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/6] libxl: libxl__device_disk_local_attach
	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- make libxl_device_disk_local_attach/detach two internal functions;

- pass a gc rather than a ctx to them;

- introduce a new libxl_device_disk** parameter to
libxl__device_disk_local_attach, the parameter is allocated on the gc by
libxl__device_disk_local_attach. It is going to fill it with
informations about the new locally attached disk.  The new
libxl_device_disk should be passed to libxl_device_disk_local_detach
afterwards.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c            |   73 -----------------------------------
 tools/libxl/libxl.h            |    7 ---
 tools/libxl/libxl_bootloader.c |    9 ++--
 tools/libxl/libxl_internal.c   |   82 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   11 +++++
 5 files changed, 97 insertions(+), 85 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 5344366..144cd94 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1644,79 +1644,6 @@ out:
     return ret;
 }
 
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    char *dev = NULL;
-    char *ret = NULL;
-    int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
-    }
-
- out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    GC_FREE;
-    return ret;
-}
-
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
-}
-
 /******************************************************************************/
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6b69030..1e7b1b9 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -536,13 +536,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
  */
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
-
 /* Network Interfaces */
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..429253d 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    libxl_device_disk *tmpdisk = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -386,7 +387,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
     if (!diskpath) {
         goto out_close;
     }
@@ -452,10 +453,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     rc = 0;
 out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
+    if (tmpdisk)
+        libxl__device_disk_local_detach(gc, tmpdisk);
     if (fifo_fd > -1)
         close(fifo_fd);
     if (bootloader_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..5ae0ecf 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,88 @@ out:
     return rc;
 }
 
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk)
+{
+    libxl_ctx *ctx = gc->owner;
+    char *dev = NULL;
+    int rc;
+    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
+    if (tmpdisk == NULL) goto out;
+
+    *new_disk = tmpdisk;
+    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));
+    if (disk->pdev_path != NULL)
+        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
+    if (disk->script != NULL)
+        tmpdisk->script = libxl__strdup(gc, disk->script);
+    tmpdisk->vdev = NULL;
+
+    rc = libxl__device_disk_setdefault(gc, tmpdisk);
+    if (rc) goto out;
+
+    switch (tmpdisk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
+                       tmpdisk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            switch (tmpdisk->format) {
+            case LIBXL_DISK_FORMAT_RAW:
+                /* optimise away the early tapdisk attach in this case */
+                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
+                           " tap disk %s directly (ie without using blktap)",
+                           tmpdisk->pdev_path);
+                dev = tmpdisk->pdev_path;
+                break;
+            case LIBXL_DISK_FORMAT_VHD:
+                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
+                                            tmpdisk->format);
+                break;
+            case LIBXL_DISK_FORMAT_QCOW:
+            case LIBXL_DISK_FORMAT_QCOW2:
+                abort(); /* prevented by libxl__device_disk_set_backend */
+            default:
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unrecognized disk format: %d", tmpdisk->format);
+                break;
+            }
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
+                           " attach a qdisk image if the format is not raw");
+                break;
+            }
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
+                       disk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
+                "type: %d", tmpdisk->backend);
+            break;
+    }
+
+ out:
+    return dev;
+}
+
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk)
+{
+    /* Nothing to do for PHYSTYPE_PHY. */
+
+    /*
+     * For other device types assume that the blktap2 process is
+     * needed by the soon to be started domain and do nothing.
+     */
+
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..c41db3c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -984,6 +984,17 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+/*
+ * Make a disk available in this (the control) domain. Returns path to
+ * a device.
+ */
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk);
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk);
+
+
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkn-0003g7-Ad; Wed, 11 Apr 2012 13:38:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkm-0003fM-B7
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:32 +0000
Received: from [193.109.254.147:32818] by server-9.bemta-14.messagelabs.com id
	6E/ED-05787-759858F4; Wed, 11 Apr 2012 13:38:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334151506!4135172!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14542 invoked from network); 11 Apr 2012 13:38:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819721"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWO-0006xC-JF; Wed, 11 Apr 2012 14:23:41 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:26 +0100
Message-ID: <1334150851-8715-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/6] libxl: libxl__device_disk_local_attach
	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- make libxl_device_disk_local_attach/detach two internal functions;

- pass a gc rather than a ctx to them;

- introduce a new libxl_device_disk** parameter to
libxl__device_disk_local_attach, the parameter is allocated on the gc by
libxl__device_disk_local_attach. It is going to fill it with
informations about the new locally attached disk.  The new
libxl_device_disk should be passed to libxl_device_disk_local_detach
afterwards.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c            |   73 -----------------------------------
 tools/libxl/libxl.h            |    7 ---
 tools/libxl/libxl_bootloader.c |    9 ++--
 tools/libxl/libxl_internal.c   |   82 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   11 +++++
 5 files changed, 97 insertions(+), 85 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 5344366..144cd94 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1644,79 +1644,6 @@ out:
     return ret;
 }
 
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    char *dev = NULL;
-    char *ret = NULL;
-    int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
-    }
-
- out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    GC_FREE;
-    return ret;
-}
-
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
-}
-
 /******************************************************************************/
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6b69030..1e7b1b9 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -536,13 +536,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
  */
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
-
 /* Network Interfaces */
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..429253d 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    libxl_device_disk *tmpdisk = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -386,7 +387,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
     if (!diskpath) {
         goto out_close;
     }
@@ -452,10 +453,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     rc = 0;
 out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
+    if (tmpdisk)
+        libxl__device_disk_local_detach(gc, tmpdisk);
     if (fifo_fd > -1)
         close(fifo_fd);
     if (bootloader_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..5ae0ecf 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,88 @@ out:
     return rc;
 }
 
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk)
+{
+    libxl_ctx *ctx = gc->owner;
+    char *dev = NULL;
+    int rc;
+    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
+    if (tmpdisk == NULL) goto out;
+
+    *new_disk = tmpdisk;
+    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));
+    if (disk->pdev_path != NULL)
+        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
+    if (disk->script != NULL)
+        tmpdisk->script = libxl__strdup(gc, disk->script);
+    tmpdisk->vdev = NULL;
+
+    rc = libxl__device_disk_setdefault(gc, tmpdisk);
+    if (rc) goto out;
+
+    switch (tmpdisk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
+                       tmpdisk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            switch (tmpdisk->format) {
+            case LIBXL_DISK_FORMAT_RAW:
+                /* optimise away the early tapdisk attach in this case */
+                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
+                           " tap disk %s directly (ie without using blktap)",
+                           tmpdisk->pdev_path);
+                dev = tmpdisk->pdev_path;
+                break;
+            case LIBXL_DISK_FORMAT_VHD:
+                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
+                                            tmpdisk->format);
+                break;
+            case LIBXL_DISK_FORMAT_QCOW:
+            case LIBXL_DISK_FORMAT_QCOW2:
+                abort(); /* prevented by libxl__device_disk_set_backend */
+            default:
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unrecognized disk format: %d", tmpdisk->format);
+                break;
+            }
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
+                           " attach a qdisk image if the format is not raw");
+                break;
+            }
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
+                       disk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
+                "type: %d", tmpdisk->backend);
+            break;
+    }
+
+ out:
+    return dev;
+}
+
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk)
+{
+    /* Nothing to do for PHYSTYPE_PHY. */
+
+    /*
+     * For other device types assume that the blktap2 process is
+     * needed by the soon to be started domain and do nothing.
+     */
+
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..c41db3c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -984,6 +984,17 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+/*
+ * Make a disk available in this (the control) domain. Returns path to
+ * a device.
+ */
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk);
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk);
+
+
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkl-0003fN-UF; Wed, 11 Apr 2012 13:38:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkk-0003et-Fi
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:30 +0000
Received: from [193.109.254.147:23635] by server-6.bemta-14.messagelabs.com id
	A9/75-02047-559858F4; Wed, 11 Apr 2012 13:38:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334151506!4135172!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14471 invoked from network); 11 Apr 2012 13:38:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819714"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-TA; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:30 +0100
Message-ID: <1334150851-8715-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__alloc_vdev: find a spare virtual block device in the
domain passed as argument.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   18 ++++++++++++++++++
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_linux.c    |   40 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   |    6 ++++++
 4 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a21c9c1..60de726 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -480,6 +480,24 @@ out:
     return rc;
 }
 
+static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
+        char *blkdev_start, xs_transaction_t t)
+{
+    int devid = 0;
+    char *vdev = libxl__strdup(gc, blkdev_start);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
+
+    do {
+        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
+        if (libxl__xs_read(gc, t,
+                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
+                        dompath, devid)) == NULL)
+            return libxl__devid_to_vdev(gc, devid);
+        vdev[strlen(vdev) - 1]++;
+    } while(vdev[strlen(vdev) - 1] <= 'z');
+    return NULL;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 584f22d..8c889c5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -744,6 +744,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..955a23b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,43 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+#define EXT_SHIFT 28
+#define EXTENDED (1<<EXT_SHIFT)
+#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED))
+#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
+
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+    if (n >= 26)
+        ptr = encode_disk_name(ptr, n / 26 - 1);
+    *ptr = 'a' + n % 26;
+    return ptr + 1;
+}
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    int minor;
+    int offset;
+    int nr_parts;
+    char *ptr = NULL;
+    char *ret = libxl__zalloc(gc, 32);
+
+    if (!VDEV_IS_EXTENDED(devid)) {
+        minor = devid & 0xff;
+        nr_parts = 16;
+    } else {
+        minor = BLKIF_MINOR_EXT(devid);
+        nr_parts = 256;
+    }
+    offset = minor / nr_parts;
+
+    strcpy(ret, "xvd");
+    ptr = encode_disk_name(ret + 3, offset);
+    if (minor % nr_parts == 0)
+        *ptr = 0;
+    else
+        snprintf(ptr, ret + 32 - ptr,
+                "%d", minor & (nr_parts - 1));
+    return ret;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 9e0ed6d..c8977ac 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 0;
 }
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    /* TODO */
+    return NULL;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkl-0003fN-UF; Wed, 11 Apr 2012 13:38:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkk-0003et-Fi
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:30 +0000
Received: from [193.109.254.147:23635] by server-6.bemta-14.messagelabs.com id
	A9/75-02047-559858F4; Wed, 11 Apr 2012 13:38:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334151506!4135172!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14471 invoked from network); 11 Apr 2012 13:38:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819714"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-TA; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:30 +0100
Message-ID: <1334150851-8715-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__alloc_vdev: find a spare virtual block device in the
domain passed as argument.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   18 ++++++++++++++++++
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_linux.c    |   40 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   |    6 ++++++
 4 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a21c9c1..60de726 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -480,6 +480,24 @@ out:
     return rc;
 }
 
+static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
+        char *blkdev_start, xs_transaction_t t)
+{
+    int devid = 0;
+    char *vdev = libxl__strdup(gc, blkdev_start);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
+
+    do {
+        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
+        if (libxl__xs_read(gc, t,
+                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
+                        dompath, devid)) == NULL)
+            return libxl__devid_to_vdev(gc, devid);
+        vdev[strlen(vdev) - 1]++;
+    } while(vdev[strlen(vdev) - 1] <= 'z');
+    return NULL;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 584f22d..8c889c5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -744,6 +744,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..955a23b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,43 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+#define EXT_SHIFT 28
+#define EXTENDED (1<<EXT_SHIFT)
+#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED))
+#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
+
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+    if (n >= 26)
+        ptr = encode_disk_name(ptr, n / 26 - 1);
+    *ptr = 'a' + n % 26;
+    return ptr + 1;
+}
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    int minor;
+    int offset;
+    int nr_parts;
+    char *ptr = NULL;
+    char *ret = libxl__zalloc(gc, 32);
+
+    if (!VDEV_IS_EXTENDED(devid)) {
+        minor = devid & 0xff;
+        nr_parts = 16;
+    } else {
+        minor = BLKIF_MINOR_EXT(devid);
+        nr_parts = 256;
+    }
+    offset = minor / nr_parts;
+
+    strcpy(ret, "xvd");
+    ptr = encode_disk_name(ret + 3, offset);
+    if (minor % nr_parts == 0)
+        *ptr = 0;
+    else
+        snprintf(ptr, ret + 32 - ptr,
+                "%d", minor & (nr_parts - 1));
+    return ret;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 9e0ed6d..c8977ac 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 0;
 }
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    /* TODO */
+    return NULL;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkp-0003gx-NA; Wed, 11 Apr 2012 13:38:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkn-0003gB-QD
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:34 +0000
Received: from [193.109.254.147:27948] by server-10.bemta-14.messagelabs.com
	id EF/7C-05847-959858F4; Wed, 11 Apr 2012 13:38:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334151506!4135172!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14552 invoked from network); 11 Apr 2012 13:38:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819728"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-HF; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:28 +0100
Message-ID: <1334150851-8715-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 3/6] libxl: introduce libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__device_disk_add_t that takes an additional
xs_transaction_t paramter.
Implement libxl_device_disk_add using libxl__device_disk_add_t.
Move libxl__device_from_disk to libxl_internal.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |  151 +----------------------------------------
 tools/libxl/libxl_internal.c |  157 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++
 3 files changed, 164 insertions(+), 150 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6461f17..0cf46bd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1238,159 +1238,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
-    flexarray_t *front;
-    flexarray_t *back;
-    char *dev;
-    libxl__device device;
-    int major, minor, rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
-
-    if (disk->script) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
-                   " not yet supported, sorry");
-        rc = ERROR_INVAL;
-        goto out_free;
-    }
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        goto out_free;
-    }
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            dev = disk->pdev_path;
-    do_backend_phy:
-            libxl__device_physdisk_major_minor(dev, &major, &minor);
-            flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
-
-            flexarray_append(back, "params");
-            flexarray_append(back, dev);
-
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-            if (!dev) {
-                rc = ERROR_FAIL;
-                goto out_free;
-            }
-            flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                libxl__device_disk_string_of_format(disk->format),
-                disk->pdev_path));
-
-            /* now create a phy device to export the device to the guest */
-            goto do_backend_phy;
-        case LIBXL_DISK_BACKEND_QDISK:
-            flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
-            rc = ERROR_INVAL;
-            goto out_free;
-    }
-
-    flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
-    flexarray_append(back, "online");
-    flexarray_append(back, "1");
-    flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
-    flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "dev");
-    flexarray_append(back, disk->vdev);
-    flexarray_append(back, "type");
-    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
-    flexarray_append(back, "mode");
-    flexarray_append(back, disk->readwrite ? "w" : "r");
-    flexarray_append(back, "device-type");
-    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
-
-    flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
-    flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
-    flexarray_append(front, "device-type");
-    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
-
-    libxl__device_generic_add(gc, XBT_NULL, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
-
-    rc = 0;
-
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
-out:
+    int rc = libxl__device_disk_add_t(gc, domid, XBT_NULL, disk);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 5ae0ecf..43ce31b 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,163 @@ out:
     return rc;
 }
 
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    char *dev;
+    libxl__device device;
+    int major, minor, rc;
+    libxl_ctx *ctx = gc->owner;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out_free;
+    }
+
+    if (disk->script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
+                   " not yet supported, sorry");
+        rc = ERROR_INVAL;
+        goto out_free;
+    }
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        goto out_free;
+    }
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            dev = disk->pdev_path;
+    do_backend_phy:
+            libxl__device_physdisk_major_minor(dev, &major, &minor);
+            flexarray_append(back, "physical-device");
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
+
+            flexarray_append(back, "params");
+            flexarray_append(back, dev);
+
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+            if (!dev) {
+                rc = ERROR_FAIL;
+                goto out_free;
+            }
+            flexarray_append(back, "tapdisk-params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                libxl__device_disk_string_of_format(disk->format),
+                disk->pdev_path));
+
+            /* now create a phy device to export the device to the guest */
+            goto do_backend_phy;
+        case LIBXL_DISK_BACKEND_QDISK:
+            flexarray_append(back, "params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
+            rc = ERROR_INVAL;
+            goto out_free;
+    }
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "removable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, "bootable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "dev");
+    flexarray_append(back, disk->vdev);
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
+    flexarray_append(back, "mode");
+    flexarray_append(back, disk->readwrite ? "w" : "r");
+    flexarray_append(back, "device-type");
+    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "virtual-device");
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, "device-type");
+    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
+
+    libxl__device_generic_add(gc, t, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+
+    rc = 0;
+
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    return rc;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7bc75b8..429624d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -984,6 +984,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device);
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk);
 /*
  * Make a disk available in this (the control) domain. Returns path to
  * a device.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxkp-0003gx-NA; Wed, 11 Apr 2012 13:38:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkn-0003gB-QD
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:34 +0000
Received: from [193.109.254.147:27948] by server-10.bemta-14.messagelabs.com
	id EF/7C-05847-959858F4; Wed, 11 Apr 2012 13:38:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334151506!4135172!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14552 invoked from network); 11 Apr 2012 13:38:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189819728"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:33:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:33:11 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxWQ-0006xC-HF; Wed, 11 Apr 2012 14:23:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Apr 2012 14:27:28 +0100
Message-ID: <1334150851-8715-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204111419050.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 3/6] libxl: introduce libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__device_disk_add_t that takes an additional
xs_transaction_t paramter.
Implement libxl_device_disk_add using libxl__device_disk_add_t.
Move libxl__device_from_disk to libxl_internal.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |  151 +----------------------------------------
 tools/libxl/libxl_internal.c |  157 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++
 3 files changed, 164 insertions(+), 150 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6461f17..0cf46bd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1238,159 +1238,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
-    flexarray_t *front;
-    flexarray_t *back;
-    char *dev;
-    libxl__device device;
-    int major, minor, rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
-
-    if (disk->script) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
-                   " not yet supported, sorry");
-        rc = ERROR_INVAL;
-        goto out_free;
-    }
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        goto out_free;
-    }
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            dev = disk->pdev_path;
-    do_backend_phy:
-            libxl__device_physdisk_major_minor(dev, &major, &minor);
-            flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
-
-            flexarray_append(back, "params");
-            flexarray_append(back, dev);
-
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-            if (!dev) {
-                rc = ERROR_FAIL;
-                goto out_free;
-            }
-            flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                libxl__device_disk_string_of_format(disk->format),
-                disk->pdev_path));
-
-            /* now create a phy device to export the device to the guest */
-            goto do_backend_phy;
-        case LIBXL_DISK_BACKEND_QDISK:
-            flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
-            rc = ERROR_INVAL;
-            goto out_free;
-    }
-
-    flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
-    flexarray_append(back, "online");
-    flexarray_append(back, "1");
-    flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
-    flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "dev");
-    flexarray_append(back, disk->vdev);
-    flexarray_append(back, "type");
-    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
-    flexarray_append(back, "mode");
-    flexarray_append(back, disk->readwrite ? "w" : "r");
-    flexarray_append(back, "device-type");
-    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
-
-    flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
-    flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
-    flexarray_append(front, "device-type");
-    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
-
-    libxl__device_generic_add(gc, XBT_NULL, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
-
-    rc = 0;
-
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
-out:
+    int rc = libxl__device_disk_add_t(gc, domid, XBT_NULL, disk);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 5ae0ecf..43ce31b 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,163 @@ out:
     return rc;
 }
 
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    char *dev;
+    libxl__device device;
+    int major, minor, rc;
+    libxl_ctx *ctx = gc->owner;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out_free;
+    }
+
+    if (disk->script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
+                   " not yet supported, sorry");
+        rc = ERROR_INVAL;
+        goto out_free;
+    }
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        goto out_free;
+    }
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            dev = disk->pdev_path;
+    do_backend_phy:
+            libxl__device_physdisk_major_minor(dev, &major, &minor);
+            flexarray_append(back, "physical-device");
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
+
+            flexarray_append(back, "params");
+            flexarray_append(back, dev);
+
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+            if (!dev) {
+                rc = ERROR_FAIL;
+                goto out_free;
+            }
+            flexarray_append(back, "tapdisk-params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                libxl__device_disk_string_of_format(disk->format),
+                disk->pdev_path));
+
+            /* now create a phy device to export the device to the guest */
+            goto do_backend_phy;
+        case LIBXL_DISK_BACKEND_QDISK:
+            flexarray_append(back, "params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
+            rc = ERROR_INVAL;
+            goto out_free;
+    }
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "removable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, "bootable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "dev");
+    flexarray_append(back, disk->vdev);
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
+    flexarray_append(back, "mode");
+    flexarray_append(back, disk->readwrite ? "w" : "r");
+    flexarray_append(back, "device-type");
+    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "virtual-device");
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, "device-type");
+    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
+
+    libxl__device_generic_add(gc, t, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+
+    rc = 0;
+
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    return rc;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7bc75b8..429624d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -984,6 +984,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device);
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk);
 /*
  * Make a disk available in this (the control) domain. Returns path to
  * a device.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxks-0003jD-8m; Wed, 11 Apr 2012 13:38:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkq-0003hZ-QT
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:37 +0000
Received: from [85.158.139.83:39051] by server-11.bemta-5.messagelabs.com id
	0D/E7-12959-C59858F4; Wed, 11 Apr 2012 13:38:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334151514!18755207!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15279 invoked from network); 11 Apr 2012 13:38:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="24056920"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:38:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:38:33 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxkh-0007eG-Ov; Wed, 11 Apr 2012 14:38:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 11 Apr 2012 14:42:19 +0100
Message-ID: <1334151739-10484-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, aliguori@us.ibm.com, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	kraxel@redhat.com, anthony.perard@citrix.com
Subject: [Xen-devel] [PATCH] xen: handle backend deletion from xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_backend.c |   17 +++++++++--------
 hw/xen_disk.c    |    4 ++++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index d876cab..555da41 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -589,7 +589,7 @@ static void xenstore_update_be(char *watch, char *type, int dom,
                                struct XenDevOps *ops)
 {
     struct XenDevice *xendev;
-    char path[XEN_BUFSIZE], *dom0;
+    char path[XEN_BUFSIZE], *dom0, *bepath;
     unsigned int len, dev;
 
     dom0 = xs_get_domain_path(xenstore, 0);
@@ -608,15 +608,16 @@ static void xenstore_update_be(char *watch, char *type, int dom,
         return;
     }
 
-    if (0) {
-        /* FIXME: detect devices being deleted from xenstore ... */
-        xen_be_del_xendev(dom, dev);
-    }
-
     xendev = xen_be_get_xendev(type, dom, dev, ops);
     if (xendev != NULL) {
-        xen_be_backend_changed(xendev, path);
-        xen_be_check_state(xendev);
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+            xen_be_check_state(xendev);
+        }
     }
 }
 
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index e9bbbf7..8217109 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -824,6 +824,10 @@ static int blk_free(struct XenDevice *xendev)
     struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
     struct ioreq *ioreq;
 
+    if (blkdev->bs || blkdev->sring) {
+        blk_disconnect(xendev);
+    }
+
     while (!QLIST_EMPTY(&blkdev->freelist)) {
         ioreq = QLIST_FIRST(&blkdev->freelist);
         QLIST_REMOVE(ioreq, list);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:38:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxks-0003jD-8m; Wed, 11 Apr 2012 13:38:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHxkq-0003hZ-QT
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:38:37 +0000
Received: from [85.158.139.83:39051] by server-11.bemta-5.messagelabs.com id
	0D/E7-12959-C59858F4; Wed, 11 Apr 2012 13:38:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334151514!18755207!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15279 invoked from network); 11 Apr 2012 13:38:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:38:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="24056920"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 09:38:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 09:38:33 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SHxkh-0007eG-Ov; Wed, 11 Apr 2012 14:38:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 11 Apr 2012 14:42:19 +0100
Message-ID: <1334151739-10484-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, aliguori@us.ibm.com, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	kraxel@redhat.com, anthony.perard@citrix.com
Subject: [Xen-devel] [PATCH] xen: handle backend deletion from xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_backend.c |   17 +++++++++--------
 hw/xen_disk.c    |    4 ++++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index d876cab..555da41 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -589,7 +589,7 @@ static void xenstore_update_be(char *watch, char *type, int dom,
                                struct XenDevOps *ops)
 {
     struct XenDevice *xendev;
-    char path[XEN_BUFSIZE], *dom0;
+    char path[XEN_BUFSIZE], *dom0, *bepath;
     unsigned int len, dev;
 
     dom0 = xs_get_domain_path(xenstore, 0);
@@ -608,15 +608,16 @@ static void xenstore_update_be(char *watch, char *type, int dom,
         return;
     }
 
-    if (0) {
-        /* FIXME: detect devices being deleted from xenstore ... */
-        xen_be_del_xendev(dom, dev);
-    }
-
     xendev = xen_be_get_xendev(type, dom, dev, ops);
     if (xendev != NULL) {
-        xen_be_backend_changed(xendev, path);
-        xen_be_check_state(xendev);
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+            xen_be_check_state(xendev);
+        }
     }
 }
 
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index e9bbbf7..8217109 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -824,6 +824,10 @@ static int blk_free(struct XenDevice *xendev)
     struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
     struct ioreq *ioreq;
 
+    if (blkdev->bs || blkdev->sring) {
+        blk_disconnect(xendev);
+    }
+
     while (!QLIST_EMPTY(&blkdev->freelist)) {
         ioreq = QLIST_FIRST(&blkdev->freelist);
         QLIST_REMOVE(ioreq, list);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:43:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxpR-0004jI-6Z; Wed, 11 Apr 2012 13:43:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHxpP-0004j4-Dm
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:43:19 +0000
Received: from [193.109.254.147:31524] by server-10.bemta-14.messagelabs.com
	id 71/A2-05847-67A858F4; Wed, 11 Apr 2012 13:43:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334151796!4128417!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=3.4 required=7.0 tests=INFO_TLD,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10293 invoked from network); 11 Apr 2012 13:43:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 13:43:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BDgWV8021949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 09:42:32 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BDgVKx021947;
	Wed, 11 Apr 2012 09:42:31 -0400
Date: Wed, 11 Apr 2012 09:42:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120411134231.GA21703@andromeda.dapyr.net>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
	<B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
	<1334144952.5394.155.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334144952.5394.155.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Lin Ming <mlin@ss.pku.edu.cn>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
	PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 12:49:12PM +0100, Ian Campbell wrote:
> On Wed, 2012-04-11 at 12:42 +0100, Stefano Stabellini wrote:
> > On Wed, 11 Apr 2012, Zhang, Xiantao wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Wednesday, April 11, 2012 12:21 AM
> > > > To: Lin Ming
> > > > Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> > > > Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> > > > PHYSDEVOP_nr_irqs_gsi
> > > > 
> > > > On Tue, 10 Apr 2012, Lin Ming wrote:
> > > > > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > > > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > > > > This new physdev_op is added for Linux guest kernel to get the
> > > > > > > correct nr_irqs_gsi value.
> > > > > >
> > > > > > I'm not convinced this is really needed - the kernel can work out
> > > > > > the right number without any hypercall afaict.
> > > > >
> > > > > In Linux kernel:
> > > > >
> > > > > mp_register_ioapic(...):
> > > > >
> > > > >         entries = io_apic_get_redir_entries(idx);
> > > > >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> > > > >         gsi_cfg->gsi_base = gsi_base;
> > > > >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> > > > >
> > > > >         /*
> > > > >          * The number of IO-APIC IRQ registers (== #pins):
> > > > >          */
> > > > >         ioapics[idx].nr_registers = entries;
> > > > >
> > > > >         if (gsi_cfg->gsi_end >= gsi_top)
> > > > >                 gsi_top = gsi_cfg->gsi_end + 1;
> > > > >
> > > > > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > > > > value(0xFFFFFFFF) on Xen Dom0 kernel.$

It is actually now 0xfd.

> > > > >
> > > > > How can we get the correct gsi_top value, which is used to set
> > > > > nr_irqs_gsi, without hypercall?

So, why is this important?

> > > > >
> > > > > The problem here is we don't have a Xen version of io_apic_read in
> > > > > Linux kernel.
> > > > 
> > > > Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519
> 
> Why was this patch never seen on xen-devel?

Probably b/c I forgot to put the CC on it. Either way it first
has to go through Ingo's tree for 3.5.

>  
> > > This is not enough, seems fixed value are returned for each read ?
> > 
> > Yes, it looks like we are always returning 0x00170020, that means 24
> > entries that I guess is correct for the vast majority of io_apics.
> > 
> > We could limit ourselves to adding a comment saying "we assume the
> > io_apic has 24 redir entries".
> > 
> > Or we could use PHYSDEVOP_apic_read to do an actual io_apic read for
> > reg 0x1.
> 
> This seems like the obviously right thing to do, compared with
> hardcoding 24...

Could do as well.
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:43:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxpR-0004jI-6Z; Wed, 11 Apr 2012 13:43:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHxpP-0004j4-Dm
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:43:19 +0000
Received: from [193.109.254.147:31524] by server-10.bemta-14.messagelabs.com
	id 71/A2-05847-67A858F4; Wed, 11 Apr 2012 13:43:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334151796!4128417!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=3.4 required=7.0 tests=INFO_TLD,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10293 invoked from network); 11 Apr 2012 13:43:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 13:43:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BDgWV8021949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 09:42:32 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BDgVKx021947;
	Wed, 11 Apr 2012 09:42:31 -0400
Date: Wed, 11 Apr 2012 09:42:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120411134231.GA21703@andromeda.dapyr.net>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
	<alpine.DEB.2.00.1204101720570.15151@kaball-desktop>
	<B6C2EB9186482D47BD0C5A9A483456440C9A82@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.00.1204111219490.15151@kaball-desktop>
	<1334144952.5394.155.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334144952.5394.155.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Lin Ming <mlin@ss.pku.edu.cn>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
	PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 12:49:12PM +0100, Ian Campbell wrote:
> On Wed, 2012-04-11 at 12:42 +0100, Stefano Stabellini wrote:
> > On Wed, 11 Apr 2012, Zhang, Xiantao wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Wednesday, April 11, 2012 12:21 AM
> > > > To: Lin Ming
> > > > Cc: Jan Beulich; Konrad Rzeszutek Wilk; Zhang, Xiantao; xen-devel
> > > > Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
> > > > PHYSDEVOP_nr_irqs_gsi
> > > > 
> > > > On Tue, 10 Apr 2012, Lin Ming wrote:
> > > > > On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
> > > > > > >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > > > > > > This new physdev_op is added for Linux guest kernel to get the
> > > > > > > correct nr_irqs_gsi value.
> > > > > >
> > > > > > I'm not convinced this is really needed - the kernel can work out
> > > > > > the right number without any hypercall afaict.
> > > > >
> > > > > In Linux kernel:
> > > > >
> > > > > mp_register_ioapic(...):
> > > > >
> > > > >         entries = io_apic_get_redir_entries(idx);
> > > > >         gsi_cfg = mp_ioapic_gsi_routing(idx);
> > > > >         gsi_cfg->gsi_base = gsi_base;
> > > > >         gsi_cfg->gsi_end = gsi_base + entries - 1;
> > > > >
> > > > >         /*
> > > > >          * The number of IO-APIC IRQ registers (== #pins):
> > > > >          */
> > > > >         ioapics[idx].nr_registers = entries;
> > > > >
> > > > >         if (gsi_cfg->gsi_end >= gsi_top)
> > > > >                 gsi_top = gsi_cfg->gsi_end + 1;
> > > > >
> > > > > io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> > > > > value(0xFFFFFFFF) on Xen Dom0 kernel.$

It is actually now 0xfd.

> > > > >
> > > > > How can we get the correct gsi_top value, which is used to set
> > > > > nr_irqs_gsi, without hypercall?

So, why is this important?

> > > > >
> > > > > The problem here is we don't have a Xen version of io_apic_read in
> > > > > Linux kernel.
> > > > 
> > > > Actually we do: http://marc.info/?l=linux-kernel&m=133295662314519
> 
> Why was this patch never seen on xen-devel?

Probably b/c I forgot to put the CC on it. Either way it first
has to go through Ingo's tree for 3.5.

>  
> > > This is not enough, seems fixed value are returned for each read ?
> > 
> > Yes, it looks like we are always returning 0x00170020, that means 24
> > entries that I guess is correct for the vast majority of io_apics.
> > 
> > We could limit ourselves to adding a comment saying "we assume the
> > io_apic has 24 redir entries".
> > 
> > Or we could use PHYSDEVOP_apic_read to do an actual io_apic read for
> > reg 0x1.
> 
> This seems like the obviously right thing to do, compared with
> hardcoding 24...

Could do as well.
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:47:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxsw-0004xk-E3; Wed, 11 Apr 2012 13:46:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHxsv-0004xd-Bh
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:46:57 +0000
Received: from [85.158.143.99:32927] by server-2.bemta-4.messagelabs.com id
	DB/7F-17550-05B858F4; Wed, 11 Apr 2012 13:46:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334152014!22289795!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12452 invoked from network); 11 Apr 2012 13:46:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 13:46:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BDkmWt022061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 09:46:48 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BDkmRK022059;
	Wed, 11 Apr 2012 09:46:48 -0400
Date: Wed, 11 Apr 2012 09:46:48 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120411134648.GB21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: wei.huang2@amd.com, xen-devel@lists.xen.org, marcus.granado@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 08, 2012 at 02:48:25PM +0800, Lin Ming wrote:
> On Sat, Apr 7, 2012 at 12:43 AM, Wei Huang <wei.huang2@amd.com> wrote:
> > On 04/06/2012 10:41 AM, Lin Ming wrote:
> >>
> >> Hi list,
> >>
> >> Is anybody working on virtualization of the CPU Performance Monitoring
> >> Unit?
> >>
> >> There are 2 PMU related projects listed on GSoC 2012 page.
> >> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> >>
> >> - Virtualization of the CPU Performance Monitoring Unit
> >> - Perf support for Xen
> >>
> >> I'm interested on these 2 projects.
> >
> > Hi Lin,
> >
> > 1. I don't think Xen was accepted as an organization for 2012 GSOC. See
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> 
> It doesn't matter.
> I just want to find something valuable to do.
> 
> > 2. The PMU project description in the wiki is vague. I know HVM guests
> > support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> > directories. You better ask mentors for details (maybe this is XCP
> > specific?).
> 
> (CC mentors)
> 
> I tested PMU/Perf support with xen-unstable, dom0 3.3 kernel, domU
> 3.4-rc1 kernel.
> Here is the result on an Intel SandyBrige machine.
> 
> - In dom0
> 
> # dmesg |grep -i "Performance Event"
> Performance Events: unsupported p6 CPU model 42 no PMU driver,
> software events only.
> 
> Hardware events are not supported yet in dom0.
> 
> - In domU
> # dmesg |grep -i "Performance Events"
> Performance Events: 16-deep LBR, SandyBridge events, Intel PMU driver.
> 
> Seems domU has support for hardware events.
> But "perf" does not work on domU.

That isn't actually true. If you run it, you will see it working
in the guest - it just that it does not use the performence counters
but instead uses the timer to sample data.

> Run "perf top", but no data was collected.

Hm, I am able to collect data using Fedora Core 16 PV guest.
For dom0 or domU? For dom0 there is a bug somewhere where
the machine crashes after 30 seconds or so - hadn't actually
gotten to the bottom of it. There was an email thread:
https://lkml.org/lkml/2012/2/12/74 about this.

Patches are most welcome!
> 
> # cat /proc/interrupts |grep "PMI"
>  PMI:          0          0   Performance monitoring interrupts
> 
> No PMU interrupts.
> 
> BTW, I also tested KVM-Qemu.
> "perf" works well on KVM-Qemu.
> 
> Thanks,
> Lin Ming
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:47:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxsw-0004xk-E3; Wed, 11 Apr 2012 13:46:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHxsv-0004xd-Bh
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 13:46:57 +0000
Received: from [85.158.143.99:32927] by server-2.bemta-4.messagelabs.com id
	DB/7F-17550-05B858F4; Wed, 11 Apr 2012 13:46:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334152014!22289795!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12452 invoked from network); 11 Apr 2012 13:46:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 13:46:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BDkmWt022061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 09:46:48 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BDkmRK022059;
	Wed, 11 Apr 2012 09:46:48 -0400
Date: Wed, 11 Apr 2012 09:46:48 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120411134648.GB21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: wei.huang2@amd.com, xen-devel@lists.xen.org, marcus.granado@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 08, 2012 at 02:48:25PM +0800, Lin Ming wrote:
> On Sat, Apr 7, 2012 at 12:43 AM, Wei Huang <wei.huang2@amd.com> wrote:
> > On 04/06/2012 10:41 AM, Lin Ming wrote:
> >>
> >> Hi list,
> >>
> >> Is anybody working on virtualization of the CPU Performance Monitoring
> >> Unit?
> >>
> >> There are 2 PMU related projects listed on GSoC 2012 page.
> >> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> >>
> >> - Virtualization of the CPU Performance Monitoring Unit
> >> - Perf support for Xen
> >>
> >> I'm interested on these 2 projects.
> >
> > Hi Lin,
> >
> > 1. I don't think Xen was accepted as an organization for 2012 GSOC. See
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> 
> It doesn't matter.
> I just want to find something valuable to do.
> 
> > 2. The PMU project description in the wiki is vague. I know HVM guests
> > support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> > directories. You better ask mentors for details (maybe this is XCP
> > specific?).
> 
> (CC mentors)
> 
> I tested PMU/Perf support with xen-unstable, dom0 3.3 kernel, domU
> 3.4-rc1 kernel.
> Here is the result on an Intel SandyBrige machine.
> 
> - In dom0
> 
> # dmesg |grep -i "Performance Event"
> Performance Events: unsupported p6 CPU model 42 no PMU driver,
> software events only.
> 
> Hardware events are not supported yet in dom0.
> 
> - In domU
> # dmesg |grep -i "Performance Events"
> Performance Events: 16-deep LBR, SandyBridge events, Intel PMU driver.
> 
> Seems domU has support for hardware events.
> But "perf" does not work on domU.

That isn't actually true. If you run it, you will see it working
in the guest - it just that it does not use the performence counters
but instead uses the timer to sample data.

> Run "perf top", but no data was collected.

Hm, I am able to collect data using Fedora Core 16 PV guest.
For dom0 or domU? For dom0 there is a bug somewhere where
the machine crashes after 30 seconds or so - hadn't actually
gotten to the bottom of it. There was an email thread:
https://lkml.org/lkml/2012/2/12/74 about this.

Patches are most welcome!
> 
> # cat /proc/interrupts |grep "PMI"
>  PMI:          0          0   Performance monitoring interrupts
> 
> No PMU interrupts.
> 
> BTW, I also tested KVM-Qemu.
> "perf" works well on KVM-Qemu.
> 
> Thanks,
> Lin Ming
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxzE-0005Cz-FM; Wed, 11 Apr 2012 13:53:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHxzC-0005Cp-SV
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:53:27 +0000
Received: from [193.109.254.147:23994] by server-11.bemta-14.messagelabs.com
	id 63/59-05858-6DC858F4; Wed, 11 Apr 2012 13:53:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334152403!1654461!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG, SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22293 invoked from network); 11 Apr 2012 13:53:24 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 13:53:24 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BDr4Kl022315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 09:53:04 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BDr40G022313;
	Wed, 11 Apr 2012 09:53:04 -0400
Date: Wed, 11 Apr 2012 09:53:04 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120411135304.GC21703@andromeda.dapyr.net>
References: <1334069838.5865.130.camel@hp6530s>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334069838.5865.130.camel@hp6530s>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [RFC PATCH] xen: get correct nr_irqs_gsi value from
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 10:57:18PM +0800, Lin Ming wrote:
> nr_irqs_gsi is set in probe_nr_irqs_gsi()
> 	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY;
> 
> gsi_top is set in mp_register_ioapic()
> 	gsi_top = gsi_cfg->gsi_end + 1;
> 
> mp_register_ioapic() calls io_apic_read, which don't have a Xen specific
> version. Actually, io_apic_read() always return -1 on Xen Dom0 kernel.
> 
> So currently, nr_irqs_gsi is always wrong on Xen Dom0 kernel.
> 
> This patch gets the correct nr_irqs_gsi value from Xen hypervisor with a
> hypercall.
> 
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> --
>  arch/x86/include/asm/io_apic.h  |    2 ++
>  arch/x86/kernel/apic/io_apic.c  |    2 +-
>  arch/x86/xen/setup.c            |    9 +++++++++
>  include/xen/interface/physdev.h |    6 ++++++
>  4 files changed, 18 insertions(+), 1 deletions(-)
> 
> (I will send xen hypervisor patch in another mail)
> 
> Here comes the detail story.
> 
> Xen Dom0 kernel panics with 3.4-rc1. I took the panics picture at
> http://www.sendspace.com/file/12ob33
> 
> Bisected to below commit.

It is a bummer you went through all this trouble when I had
patches for this (and a workaround) since about three weeks ago.

The v3.4-rc2 should work fine for right now, with a work-around
against Suresh's patch.

Long-term, the two patches in my stable/for-ingo-3.4.v2 would
fix it, and if we use the existing IOAPIc hypercalls we can get
the exact count of GSI.


> 
> commit 73d63d038ee9f769f5e5b46792d227fe20e442c5
> Author: Suresh Siddha <suresh.b.siddha@intel.com>
> Date:   Mon Mar 12 11:36:33 2012 -0700
> 
>     x86/ioapic: Add register level checks to detect bogus io-apic entries
> 
> But this commit itself has no problem.
> This commit just triggers the panic.
> 
> The panic happens at xen_irq_init(..)
> 
> pci_enable_device
> __pci_enable_device_flags
> do_pci_enable_device
> pcibios_enable_device
> acpi_pci_irq_enable
> acpi_register_gsi
> acpi_register_gsi_xen
> xen_register_gsi
> xen_register_pirq
> xen_bind_pirq_gsi_to_irq
> xen_allocate_irq_gsi:
>         irq = irq_alloc_desc_at(gsi, -1);
>         xen_irq_init(irq);
> 
> On my machine, when enable PCI root port, gsi 16 is passed into
> irq_alloc_desc_at, but it returns -17(-EEXIST) because irq 16 was
> already took by xen timer(see below). Then negative value -17 is passed
> into xen_irq_init --> irq_to_desc --> radix_tree_lookup, which causes
> the panic.
> 
> xen timer allocates the irq number "nr_irqs_gsi"
> nr_irqs_gsi is set in probe_nr_irqs_gsi()
> 	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY
> gsi_top is set in mp_register_ioapic()
> 	gsi_top = gsi_cfg->gsi_end + 1;
> 
> In 3.4-rc1 kernel:
> 
> mp_register_ioapic
>   bad_ioapic_register (added in 3.4-rc1)
>     <always return true(bad) on Xen Dom0 kernel>
> 
> So mp_register_ioapic exist and gsi_top was not set up. It is left as
> the initialized value(zero). So nr_irqs_gsi is 16(NR_IRQS_LEGACY).
> That's why Xen timer allocated irq 16.
> 
> 
> Actually, gsi_top was never setup correctly in mp_register_ioapic on Xen
> Dom0 kernel. Because mp_register_ioapic calls io_apic_read, which is not
> implemented with hypercall in Linux kernel. So io_apic_read() always
> return -1 on Xen Dom0 kernel.
> 
> For 3.3 kernel in Xen Dom0, the dmesg shows
> 
> IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255
> ......
> nr_irqs_gsi: 272
> 
> This is obviously wrong, "255" is actually -1(0xFFFF).
> 
> 
> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> index 2c4943d..a8bf3b2 100644
> --- a/arch/x86/include/asm/io_apic.h
> +++ b/arch/x86/include/asm/io_apic.h
> @@ -115,6 +115,8 @@ struct IR_IO_APIC_route_entry {
>   */
>  extern int nr_ioapics;
>  
> +extern int nr_irqs_gsi;
> +
>  extern int mpc_ioapic_id(int ioapic);
>  extern unsigned int mpc_ioapic_addr(int ioapic);
>  extern struct mp_ioapic_gsi *mp_ioapic_gsi_routing(int ioapic);
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index e88300d..8bff292 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -140,7 +140,7 @@ struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
>  int mp_irq_entries;
>  
>  /* GSI interrupts */
> -static int nr_irqs_gsi = NR_IRQS_LEGACY;
> +int nr_irqs_gsi = NR_IRQS_LEGACY;
>  
>  #if defined (CONFIG_MCA) || defined (CONFIG_EISA)
>  int mp_bus_id_to_type[MAX_MP_BUSSES];
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 1ba8dff..9ce82bc 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -389,6 +389,9 @@ void __cpuinit xen_enable_syscall(void)
>  
>  void __init xen_arch_setup(void)
>  {
> +	struct physdev_nr_irqs_gsi irqs_gsi;
> +	int rc;
> +
>  	xen_panic_handler_init();
>  
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
> @@ -424,4 +427,10 @@ void __init xen_arch_setup(void)
>  	disable_cpufreq();
>  	WARN_ON(set_pm_idle_to_default());
>  	fiddle_vdso();
> +
> +	rc = HYPERVISOR_physdev_op(PHYSDEVOP_nr_irqs_gsi, &irqs_gsi);
> +	if (rc)
> +		printk(KERN_ERR "Failed to init nr_irqs_gsi, err_code:%d\n", rc);
> +	else
> +		nr_irqs_gsi = irqs_gsi.nr_irqs_gsi;
>  }
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..180a0a3 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,12 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_nr_irqs_gsi           29
> +struct physdev_nr_irqs_gsi {
> +    /* OUT */
> +    uint32_t nr_irqs_gsi;
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 13:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 13:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHxzE-0005Cz-FM; Wed, 11 Apr 2012 13:53:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHxzC-0005Cp-SV
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:53:27 +0000
Received: from [193.109.254.147:23994] by server-11.bemta-14.messagelabs.com
	id 63/59-05858-6DC858F4; Wed, 11 Apr 2012 13:53:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334152403!1654461!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG, SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22293 invoked from network); 11 Apr 2012 13:53:24 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 13:53:24 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BDr4Kl022315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 09:53:04 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BDr40G022313;
	Wed, 11 Apr 2012 09:53:04 -0400
Date: Wed, 11 Apr 2012 09:53:04 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120411135304.GC21703@andromeda.dapyr.net>
References: <1334069838.5865.130.camel@hp6530s>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334069838.5865.130.camel@hp6530s>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [RFC PATCH] xen: get correct nr_irqs_gsi value from
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 10:57:18PM +0800, Lin Ming wrote:
> nr_irqs_gsi is set in probe_nr_irqs_gsi()
> 	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY;
> 
> gsi_top is set in mp_register_ioapic()
> 	gsi_top = gsi_cfg->gsi_end + 1;
> 
> mp_register_ioapic() calls io_apic_read, which don't have a Xen specific
> version. Actually, io_apic_read() always return -1 on Xen Dom0 kernel.
> 
> So currently, nr_irqs_gsi is always wrong on Xen Dom0 kernel.
> 
> This patch gets the correct nr_irqs_gsi value from Xen hypervisor with a
> hypercall.
> 
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> --
>  arch/x86/include/asm/io_apic.h  |    2 ++
>  arch/x86/kernel/apic/io_apic.c  |    2 +-
>  arch/x86/xen/setup.c            |    9 +++++++++
>  include/xen/interface/physdev.h |    6 ++++++
>  4 files changed, 18 insertions(+), 1 deletions(-)
> 
> (I will send xen hypervisor patch in another mail)
> 
> Here comes the detail story.
> 
> Xen Dom0 kernel panics with 3.4-rc1. I took the panics picture at
> http://www.sendspace.com/file/12ob33
> 
> Bisected to below commit.

It is a bummer you went through all this trouble when I had
patches for this (and a workaround) since about three weeks ago.

The v3.4-rc2 should work fine for right now, with a work-around
against Suresh's patch.

Long-term, the two patches in my stable/for-ingo-3.4.v2 would
fix it, and if we use the existing IOAPIc hypercalls we can get
the exact count of GSI.


> 
> commit 73d63d038ee9f769f5e5b46792d227fe20e442c5
> Author: Suresh Siddha <suresh.b.siddha@intel.com>
> Date:   Mon Mar 12 11:36:33 2012 -0700
> 
>     x86/ioapic: Add register level checks to detect bogus io-apic entries
> 
> But this commit itself has no problem.
> This commit just triggers the panic.
> 
> The panic happens at xen_irq_init(..)
> 
> pci_enable_device
> __pci_enable_device_flags
> do_pci_enable_device
> pcibios_enable_device
> acpi_pci_irq_enable
> acpi_register_gsi
> acpi_register_gsi_xen
> xen_register_gsi
> xen_register_pirq
> xen_bind_pirq_gsi_to_irq
> xen_allocate_irq_gsi:
>         irq = irq_alloc_desc_at(gsi, -1);
>         xen_irq_init(irq);
> 
> On my machine, when enable PCI root port, gsi 16 is passed into
> irq_alloc_desc_at, but it returns -17(-EEXIST) because irq 16 was
> already took by xen timer(see below). Then negative value -17 is passed
> into xen_irq_init --> irq_to_desc --> radix_tree_lookup, which causes
> the panic.
> 
> xen timer allocates the irq number "nr_irqs_gsi"
> nr_irqs_gsi is set in probe_nr_irqs_gsi()
> 	nr_irqs_gsi = gsi_top + NR_IRQS_LEGACY
> gsi_top is set in mp_register_ioapic()
> 	gsi_top = gsi_cfg->gsi_end + 1;
> 
> In 3.4-rc1 kernel:
> 
> mp_register_ioapic
>   bad_ioapic_register (added in 3.4-rc1)
>     <always return true(bad) on Xen Dom0 kernel>
> 
> So mp_register_ioapic exist and gsi_top was not set up. It is left as
> the initialized value(zero). So nr_irqs_gsi is 16(NR_IRQS_LEGACY).
> That's why Xen timer allocated irq 16.
> 
> 
> Actually, gsi_top was never setup correctly in mp_register_ioapic on Xen
> Dom0 kernel. Because mp_register_ioapic calls io_apic_read, which is not
> implemented with hypercall in Linux kernel. So io_apic_read() always
> return -1 on Xen Dom0 kernel.
> 
> For 3.3 kernel in Xen Dom0, the dmesg shows
> 
> IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255
> ......
> nr_irqs_gsi: 272
> 
> This is obviously wrong, "255" is actually -1(0xFFFF).
> 
> 
> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> index 2c4943d..a8bf3b2 100644
> --- a/arch/x86/include/asm/io_apic.h
> +++ b/arch/x86/include/asm/io_apic.h
> @@ -115,6 +115,8 @@ struct IR_IO_APIC_route_entry {
>   */
>  extern int nr_ioapics;
>  
> +extern int nr_irqs_gsi;
> +
>  extern int mpc_ioapic_id(int ioapic);
>  extern unsigned int mpc_ioapic_addr(int ioapic);
>  extern struct mp_ioapic_gsi *mp_ioapic_gsi_routing(int ioapic);
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index e88300d..8bff292 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -140,7 +140,7 @@ struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
>  int mp_irq_entries;
>  
>  /* GSI interrupts */
> -static int nr_irqs_gsi = NR_IRQS_LEGACY;
> +int nr_irqs_gsi = NR_IRQS_LEGACY;
>  
>  #if defined (CONFIG_MCA) || defined (CONFIG_EISA)
>  int mp_bus_id_to_type[MAX_MP_BUSSES];
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 1ba8dff..9ce82bc 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -389,6 +389,9 @@ void __cpuinit xen_enable_syscall(void)
>  
>  void __init xen_arch_setup(void)
>  {
> +	struct physdev_nr_irqs_gsi irqs_gsi;
> +	int rc;
> +
>  	xen_panic_handler_init();
>  
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
> @@ -424,4 +427,10 @@ void __init xen_arch_setup(void)
>  	disable_cpufreq();
>  	WARN_ON(set_pm_idle_to_default());
>  	fiddle_vdso();
> +
> +	rc = HYPERVISOR_physdev_op(PHYSDEVOP_nr_irqs_gsi, &irqs_gsi);
> +	if (rc)
> +		printk(KERN_ERR "Failed to init nr_irqs_gsi, err_code:%d\n", rc);
> +	else
> +		nr_irqs_gsi = irqs_gsi.nr_irqs_gsi;
>  }
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..180a0a3 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,12 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_nr_irqs_gsi           29
> +struct physdev_nr_irqs_gsi {
> +    /* OUT */
> +    uint32_t nr_irqs_gsi;
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:00:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHy5C-0005PH-CV; Wed, 11 Apr 2012 13:59:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHy5B-0005PB-Af
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:59:37 +0000
Received: from [85.158.138.51:29395] by server-9.bemta-3.messagelabs.com id
	02/D2-26691-84E858F4; Wed, 11 Apr 2012 13:59:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334152774!19879867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28961 invoked from network); 11 Apr 2012 13:59:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11879772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 13:59:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 14:59:34 +0100
Message-ID: <1334152772.16387.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 11 Apr 2012 14:59:32 +0100
In-Reply-To: <E1SHy1P-0000Kg-FL@xenbits.xen.org>
References: <E1SHy1P-0000Kg-FL@xenbits.xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [Xen-staging] [qemu-upstream-unstable] xen_disk:
 when using AIO flush after the operation is completed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 14:55 +0100, patchbot@xen.org wrote:
> commit 4db776322827f0930d53b9e162dc1c6600d918d0
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Fri Mar 23 11:37:25 2012 +0000
> 
>     xen_disk: when using AIO flush after the operation is completed
>     
>     If ioreq->postsync call bdrv_flush when the AIO operation is actually
>     completed.

It'd be helpful if the commit message was amended to reference the
original upstream commit when backporting, like we do in the
xen-X.Y-testing trees and like is done in the Linux stable trees etc.

Ian.

>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  hw/xen_disk.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 16c3e66..e9bbbf7 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -398,6 +398,9 @@ static void qemu_aio_complete(void *opaque, int ret)
>      if (ioreq->aio_inflight > 0) {
>          return;
>      }
> +    if (ioreq->postsync) {
> +        bdrv_flush(ioreq->blkdev->bs);
> +    }
>  
>      ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
>      ioreq_unmap(ioreq);
> @@ -444,9 +447,6 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
>          goto err;
>      }
>  
> -    if (ioreq->postsync) {
> -        bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
> -    }
>      qemu_aio_complete(ioreq, 0);
>  
>      return 0;
> --
> generated by git-patchbot for /home/xen/git/staging/qemu-upstream-unstable.git
> 
> _______________________________________________
> Xen-staging mailing list
> Xen-staging@lists.xen.org
> http://lists.xensource.com/xen-staging



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:00:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHy5C-0005PH-CV; Wed, 11 Apr 2012 13:59:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHy5B-0005PB-Af
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 13:59:37 +0000
Received: from [85.158.138.51:29395] by server-9.bemta-3.messagelabs.com id
	02/D2-26691-84E858F4; Wed, 11 Apr 2012 13:59:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334152774!19879867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28961 invoked from network); 11 Apr 2012 13:59:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 13:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11879772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 13:59:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 14:59:34 +0100
Message-ID: <1334152772.16387.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 11 Apr 2012 14:59:32 +0100
In-Reply-To: <E1SHy1P-0000Kg-FL@xenbits.xen.org>
References: <E1SHy1P-0000Kg-FL@xenbits.xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [Xen-staging] [qemu-upstream-unstable] xen_disk:
 when using AIO flush after the operation is completed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 14:55 +0100, patchbot@xen.org wrote:
> commit 4db776322827f0930d53b9e162dc1c6600d918d0
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Fri Mar 23 11:37:25 2012 +0000
> 
>     xen_disk: when using AIO flush after the operation is completed
>     
>     If ioreq->postsync call bdrv_flush when the AIO operation is actually
>     completed.

It'd be helpful if the commit message was amended to reference the
original upstream commit when backporting, like we do in the
xen-X.Y-testing trees and like is done in the Linux stable trees etc.

Ian.

>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  hw/xen_disk.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 16c3e66..e9bbbf7 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -398,6 +398,9 @@ static void qemu_aio_complete(void *opaque, int ret)
>      if (ioreq->aio_inflight > 0) {
>          return;
>      }
> +    if (ioreq->postsync) {
> +        bdrv_flush(ioreq->blkdev->bs);
> +    }
>  
>      ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
>      ioreq_unmap(ioreq);
> @@ -444,9 +447,6 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
>          goto err;
>      }
>  
> -    if (ioreq->postsync) {
> -        bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
> -    }
>      qemu_aio_complete(ioreq, 0);
>  
>      return 0;
> --
> generated by git-patchbot for /home/xen/git/staging/qemu-upstream-unstable.git
> 
> _______________________________________________
> Xen-staging mailing list
> Xen-staging@lists.xen.org
> http://lists.xensource.com/xen-staging



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHy6E-0005WN-Qh; Wed, 11 Apr 2012 14:00:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHy6D-0005WG-Th
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:00:42 +0000
Received: from [85.158.139.83:62923] by server-7.bemta-5.messagelabs.com id
	CA/02-16195-88E858F4; Wed, 11 Apr 2012 14:00:40 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334152838!18758999!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17684 invoked from network); 11 Apr 2012 14:00:39 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 14:00:39 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BE0Vou023482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 10:00:32 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BE0VGc023480;
	Wed, 11 Apr 2012 10:00:31 -0400
Date: Wed, 11 Apr 2012 10:00:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Marcus Granado <marcus.granado@citrix.com>
Message-ID: <20120411140031.GD21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<4F84478A.5010701@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F84478A.5010701@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:45:30PM +0100, Marcus Granado wrote:
> On 08/04/12 07:48, Lin Ming wrote:
> >>2. The PMU project description in the wiki is vague. I know HVM guests
> >>support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> >>directories. You better ask mentors for details (maybe this is XCP
> >>specific?).
> Yes, the description is vague, we should update the page. The idea was 
> to enable users to run hardware profilers in dom0 and in any domU, PV or 
> HVM. This would include implementing what is missing for dom0/PV 
> domains, and to confirm in HVM domains that profilers such as oprofile, 
> hwpmc, intel performance counter monitor at least are running without 
> problems in the existing vPMU implementation. The original idea was to 
> add support to XCP, but please feel free to add support to xen-unstable 
> and the latest linux kernel; XCP will use those at some point.

Hey Marcos,

I think we (you, Lin and me) should talk - if Lin is very interested in this,
it might make sense to focus first on the existing supported 'perf' framework
that Linux has - instead of the oprofile variant.

Lin, Marcos, what day/time would work for an IRC meeting on
irc.freenode.net?

> cheers,
> Marcus
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHy6E-0005WN-Qh; Wed, 11 Apr 2012 14:00:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SHy6D-0005WG-Th
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:00:42 +0000
Received: from [85.158.139.83:62923] by server-7.bemta-5.messagelabs.com id
	CA/02-16195-88E858F4; Wed, 11 Apr 2012 14:00:40 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334152838!18758999!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17684 invoked from network); 11 Apr 2012 14:00:39 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 14:00:39 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q3BE0Vou023482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2012 10:00:32 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q3BE0VGc023480;
	Wed, 11 Apr 2012 10:00:31 -0400
Date: Wed, 11 Apr 2012 10:00:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Marcus Granado <marcus.granado@citrix.com>
Message-ID: <20120411140031.GD21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<4F84478A.5010701@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F84478A.5010701@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 03:45:30PM +0100, Marcus Granado wrote:
> On 08/04/12 07:48, Lin Ming wrote:
> >>2. The PMU project description in the wiki is vague. I know HVM guests
> >>support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> >>directories. You better ask mentors for details (maybe this is XCP
> >>specific?).
> Yes, the description is vague, we should update the page. The idea was 
> to enable users to run hardware profilers in dom0 and in any domU, PV or 
> HVM. This would include implementing what is missing for dom0/PV 
> domains, and to confirm in HVM domains that profilers such as oprofile, 
> hwpmc, intel performance counter monitor at least are running without 
> problems in the existing vPMU implementation. The original idea was to 
> add support to XCP, but please feel free to add support to xen-unstable 
> and the latest linux kernel; XCP will use those at some point.

Hey Marcos,

I think we (you, Lin and me) should talk - if Lin is very interested in this,
it might make sense to focus first on the existing supported 'perf' framework
that Linux has - instead of the oprofile variant.

Lin, Marcos, what day/time would work for an IRC meeting on
irc.freenode.net?

> cheers,
> Marcus
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHyYF-0006CL-RI; Wed, 11 Apr 2012 14:29:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHyYE-0006CG-MN
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 14:29:39 +0000
Received: from [85.158.139.83:44880] by server-10.bemta-5.messagelabs.com id
	9F/0B-08260-255958F4; Wed, 11 Apr 2012 14:29:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334154574!12092672!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19876 invoked from network); 11 Apr 2012 14:29:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 14:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11880627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 14:29:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 15:29:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHyY9-0003T8-Lm;
	Wed, 11 Apr 2012 14:29:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHyY9-00085S-Jj;
	Wed, 11 Apr 2012 15:29:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12636-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 15:29:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12636: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12636 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12636/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHyYF-0006CL-RI; Wed, 11 Apr 2012 14:29:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHyYE-0006CG-MN
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 14:29:39 +0000
Received: from [85.158.139.83:44880] by server-10.bemta-5.messagelabs.com id
	9F/0B-08260-255958F4; Wed, 11 Apr 2012 14:29:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334154574!12092672!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19876 invoked from network); 11 Apr 2012 14:29:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 14:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11880627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 14:29:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 15:29:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SHyY9-0003T8-Lm;
	Wed, 11 Apr 2012 14:29:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SHyY9-00085S-Jj;
	Wed, 11 Apr 2012 15:29:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12636-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 15:29:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12636: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12636 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12636/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHya2-0006HX-At; Wed, 11 Apr 2012 14:31:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHya0-0006HM-JO
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:31:28 +0000
Received: from [85.158.139.83:5867] by server-9.bemta-5.messagelabs.com id
	A7/91-09826-FB5958F4; Wed, 11 Apr 2012 14:31:27 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334154686!23276848!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23955 invoked from network); 11 Apr 2012 14:31:26 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-15.tower-182.messagelabs.com with SMTP;
	11 Apr 2012 14:31:26 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 2F35FDBC0C;
	Wed, 11 Apr 2012 22:31:12 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120411134648.GB21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<20120411134648.GB21703@andromeda.dapyr.net>
Date: Wed, 11 Apr 2012 22:30:29 +0800
Message-ID: <1334154629.3943.4.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: wei.huang2@amd.com, xen-devel@lists.xen.org, marcus.granado@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 09:46 -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 08, 2012 at 02:48:25PM +0800, Lin Ming wrote:
> > On Sat, Apr 7, 2012 at 12:43 AM, Wei Huang <wei.huang2@amd.com> wrote:
> > > On 04/06/2012 10:41 AM, Lin Ming wrote:
> > >>
> > >> Hi list,
> > >>
> > >> Is anybody working on virtualization of the CPU Performance Monitoring
> > >> Unit?
> > >>
> > >> There are 2 PMU related projects listed on GSoC 2012 page.
> > >> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> > >>
> > >> - Virtualization of the CPU Performance Monitoring Unit
> > >> - Perf support for Xen
> > >>
> > >> I'm interested on these 2 projects.
> > >
> > > Hi Lin,
> > >
> > > 1. I don't think Xen was accepted as an organization for 2012 GSOC. See
> > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> > 
> > It doesn't matter.
> > I just want to find something valuable to do.
> > 
> > > 2. The PMU project description in the wiki is vague. I know HVM guests
> > > support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> > > directories. You better ask mentors for details (maybe this is XCP
> > > specific?).
> > 
> > (CC mentors)
> > 
> > I tested PMU/Perf support with xen-unstable, dom0 3.3 kernel, domU
> > 3.4-rc1 kernel.
> > Here is the result on an Intel SandyBrige machine.
> > 
> > - In dom0
> > 
> > # dmesg |grep -i "Performance Event"
> > Performance Events: unsupported p6 CPU model 42 no PMU driver,
> > software events only.
> > 
> > Hardware events are not supported yet in dom0.
> > 
> > - In domU
> > # dmesg |grep -i "Performance Events"
> > Performance Events: 16-deep LBR, SandyBridge events, Intel PMU driver.
> > 
> > Seems domU has support for hardware events.
> > But "perf" does not work on domU.
> 
> That isn't actually true. If you run it, you will see it working
> in the guest - it just that it does not use the performence counters
> but instead uses the timer to sample data.

Right, I mean "hardware event" does not work.

Hardware event, for example, perf top -e cycles, does not work.
Software event, for example, perf top -e cpu-clock, works.

> 
> > Run "perf top", but no data was collected.
> 
> Hm, I am able to collect data using Fedora Core 16 PV guest.
> For dom0 or domU? For dom0 there is a bug somewhere where

For domU HVM guest.
I have problem to run domU PV guest. Still looking at it.

> the machine crashes after 30 seconds or so - hadn't actually
> gotten to the bottom of it. There was an email thread:
> https://lkml.org/lkml/2012/2/12/74 about this.
> 
> Patches are most welcome!

I'll see if I can reproduce this problem on dom0.

Thanks,
Lin Ming


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHya2-0006HX-At; Wed, 11 Apr 2012 14:31:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHya0-0006HM-JO
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:31:28 +0000
Received: from [85.158.139.83:5867] by server-9.bemta-5.messagelabs.com id
	A7/91-09826-FB5958F4; Wed, 11 Apr 2012 14:31:27 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334154686!23276848!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23955 invoked from network); 11 Apr 2012 14:31:26 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-15.tower-182.messagelabs.com with SMTP;
	11 Apr 2012 14:31:26 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 2F35FDBC0C;
	Wed, 11 Apr 2012 22:31:12 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120411134648.GB21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<20120411134648.GB21703@andromeda.dapyr.net>
Date: Wed, 11 Apr 2012 22:30:29 +0800
Message-ID: <1334154629.3943.4.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: wei.huang2@amd.com, xen-devel@lists.xen.org, marcus.granado@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 09:46 -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 08, 2012 at 02:48:25PM +0800, Lin Ming wrote:
> > On Sat, Apr 7, 2012 at 12:43 AM, Wei Huang <wei.huang2@amd.com> wrote:
> > > On 04/06/2012 10:41 AM, Lin Ming wrote:
> > >>
> > >> Hi list,
> > >>
> > >> Is anybody working on virtualization of the CPU Performance Monitoring
> > >> Unit?
> > >>
> > >> There are 2 PMU related projects listed on GSoC 2012 page.
> > >> http://wiki.xen.org/wiki/Archived/GSoC_2012_Ideas
> > >>
> > >> - Virtualization of the CPU Performance Monitoring Unit
> > >> - Perf support for Xen
> > >>
> > >> I'm interested on these 2 projects.
> > >
> > > Hi Lin,
> > >
> > > 1. I don't think Xen was accepted as an organization for 2012 GSOC. See
> > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg02080.html.
> > 
> > It doesn't matter.
> > I just want to find something valuable to do.
> > 
> > > 2. The PMU project description in the wiki is vague. I know HVM guests
> > > support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> > > directories. You better ask mentors for details (maybe this is XCP
> > > specific?).
> > 
> > (CC mentors)
> > 
> > I tested PMU/Perf support with xen-unstable, dom0 3.3 kernel, domU
> > 3.4-rc1 kernel.
> > Here is the result on an Intel SandyBrige machine.
> > 
> > - In dom0
> > 
> > # dmesg |grep -i "Performance Event"
> > Performance Events: unsupported p6 CPU model 42 no PMU driver,
> > software events only.
> > 
> > Hardware events are not supported yet in dom0.
> > 
> > - In domU
> > # dmesg |grep -i "Performance Events"
> > Performance Events: 16-deep LBR, SandyBridge events, Intel PMU driver.
> > 
> > Seems domU has support for hardware events.
> > But "perf" does not work on domU.
> 
> That isn't actually true. If you run it, you will see it working
> in the guest - it just that it does not use the performence counters
> but instead uses the timer to sample data.

Right, I mean "hardware event" does not work.

Hardware event, for example, perf top -e cycles, does not work.
Software event, for example, perf top -e cpu-clock, works.

> 
> > Run "perf top", but no data was collected.
> 
> Hm, I am able to collect data using Fedora Core 16 PV guest.
> For dom0 or domU? For dom0 there is a bug somewhere where

For domU HVM guest.
I have problem to run domU PV guest. Still looking at it.

> the machine crashes after 30 seconds or so - hadn't actually
> gotten to the bottom of it. There was an email thread:
> https://lkml.org/lkml/2012/2/12/74 about this.
> 
> Patches are most welcome!

I'll see if I can reproduce this problem on dom0.

Thanks,
Lin Ming


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:36:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHydy-0006Rg-Vl; Wed, 11 Apr 2012 14:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHydx-0006Ra-0u
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:35:33 +0000
Received: from [85.158.143.35:26197] by server-1.bemta-4.messagelabs.com id
	F8/69-20925-4B6958F4; Wed, 11 Apr 2012 14:35:32 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334154928!11962158!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12270 invoked from network); 11 Apr 2012 14:35:30 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 14:35:30 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 7B465DBC0C;
	Wed, 11 Apr 2012 22:35:15 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120411140031.GD21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<4F84478A.5010701@citrix.com>
	<20120411140031.GD21703@andromeda.dapyr.net>
Date: Wed, 11 Apr 2012 22:34:33 +0800
Message-ID: <1334154873.3943.8.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Marcus Granado <marcus.granado@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 10:00 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 10, 2012 at 03:45:30PM +0100, Marcus Granado wrote:
> > On 08/04/12 07:48, Lin Ming wrote:
> > >>2. The PMU project description in the wiki is vague. I know HVM guests
> > >>support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> > >>directories. You better ask mentors for details (maybe this is XCP
> > >>specific?).
> > Yes, the description is vague, we should update the page. The idea was 
> > to enable users to run hardware profilers in dom0 and in any domU, PV or 
> > HVM. This would include implementing what is missing for dom0/PV 
> > domains, and to confirm in HVM domains that profilers such as oprofile, 
> > hwpmc, intel performance counter monitor at least are running without 
> > problems in the existing vPMU implementation. The original idea was to 
> > add support to XCP, but please feel free to add support to xen-unstable 
> > and the latest linux kernel; XCP will use those at some point.
> 
> Hey Marcos,
> 
> I think we (you, Lin and me) should talk - if Lin is very interested in this,
> it might make sense to focus first on the existing supported 'perf' framework
> that Linux has - instead of the oprofile variant.

Yes, I'm interested.

> 
> Lin, Marcos, what day/time would work for an IRC meeting on
> irc.freenode.net?

I'm on ##xen now with nick name "mlin".

10pm to 12pm(Shanghai, China time) is OK for me.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 14:36:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 14:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHydy-0006Rg-Vl; Wed, 11 Apr 2012 14:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SHydx-0006Ra-0u
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 14:35:33 +0000
Received: from [85.158.143.35:26197] by server-1.bemta-4.messagelabs.com id
	F8/69-20925-4B6958F4; Wed, 11 Apr 2012 14:35:32 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334154928!11962158!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12270 invoked from network); 11 Apr 2012 14:35:30 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 14:35:30 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 7B465DBC0C;
	Wed, 11 Apr 2012 22:35:15 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120411140031.GD21703@andromeda.dapyr.net>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<4F84478A.5010701@citrix.com>
	<20120411140031.GD21703@andromeda.dapyr.net>
Date: Wed, 11 Apr 2012 22:34:33 +0800
Message-ID: <1334154873.3943.8.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: mike McClurg <mike.mcclurg@citrix.com>,
	"wei.huang2@amd.com" <wei.huang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Marcus Granado <marcus.granado@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
 Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 10:00 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 10, 2012 at 03:45:30PM +0100, Marcus Granado wrote:
> > On 08/04/12 07:48, Lin Ming wrote:
> > >>2. The PMU project description in the wiki is vague. I know HVM guests
> > >>support virtualized PMU. Please check vpmu.c files in /hvm, /svm, and /vmx
> > >>directories. You better ask mentors for details (maybe this is XCP
> > >>specific?).
> > Yes, the description is vague, we should update the page. The idea was 
> > to enable users to run hardware profilers in dom0 and in any domU, PV or 
> > HVM. This would include implementing what is missing for dom0/PV 
> > domains, and to confirm in HVM domains that profilers such as oprofile, 
> > hwpmc, intel performance counter monitor at least are running without 
> > problems in the existing vPMU implementation. The original idea was to 
> > add support to XCP, but please feel free to add support to xen-unstable 
> > and the latest linux kernel; XCP will use those at some point.
> 
> Hey Marcos,
> 
> I think we (you, Lin and me) should talk - if Lin is very interested in this,
> it might make sense to focus first on the existing supported 'perf' framework
> that Linux has - instead of the oprofile variant.

Yes, I'm interested.

> 
> Lin, Marcos, what day/time would work for an IRC meeting on
> irc.freenode.net?

I'm on ##xen now with nick name "mlin".

10pm to 12pm(Shanghai, China time) is OK for me.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzEO-0007A3-2k; Wed, 11 Apr 2012 15:13:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SHzEM-00079y-TI
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 15:13:11 +0000
Received: from [85.158.143.99:8758] by server-2.bemta-4.messagelabs.com id
	AC/19-17550-68F958F4; Wed, 11 Apr 2012 15:13:10 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334157187!12019603!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17594 invoked from network); 11 Apr 2012 15:13:08 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-16.tower-216.messagelabs.com with SMTP;
	11 Apr 2012 15:13:08 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q3BFD2r9027040;
	Wed, 11 Apr 2012 10:13:02 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q3BFD2AZ027039;
	Wed, 11 Apr 2012 10:13:02 -0500
Date: Wed, 11 Apr 2012 10:13:02 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204111513.q3BFD2AZ027039@wind.enjellic.com>
In-Reply-To: Ian Campbell <Ian.Campbell@citrix.com>
	"Re: [Xen-devel] Basic blktap2 functionality issues." (Apr 10, 10:04am)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Wed, 11 Apr 2012 10:13:02 -0500 (CDT)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Apr 10, 10:04am, Ian Campbell wrote:
} Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

> On Sat, 2012-04-07 at 16:59 +0100, Dr. Greg Wettstein wrote:
> > On Mar 30, 12:23pm, Ian Campbell wrote:
> > } Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

> > > On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > > > I think an approach worth trying would be to have
> > > > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > > > doing the actual detach. i.e. it would respond with "Yes, I will do
> > > > that" rather than "Yes, I have done that". My speculation is that this
> > > > will allow libxl to continue and hopefully avoid the deadlock.
> > 
> > > This seems to be the case as the following fixes things for
> > > me. Thanks very much for your analysis which lead me to this
> > > solution...
> > 
> > I ported your fix into 4.1.2 but I think we still have a problem, at
> > least in this codebase.
> > 
> > I no longer see the select timeout delay when xl shuts down but upon
> > shutdown the minor number is not freed.  A 'tap-ctl list' shows a
> > steadily increasing set of orphaned minor numbers as VM's are started
> > up and shutdown.
> > 
> > Are you seeing this in your development codebase?

> It turns out that I am, yes. e.g. after starting/stopping a guest 3
> times:
> # tap-ctl list
>        -  0    -          - -
>        -  1    -          - -
>        -  2    -          - -

Yes, that is the same thing I'm seeing and would be expected.

> > The culprit is a failed ioctl call for BLKTAP2_IOCTL_FREE_TAP in
> > tap_ctl_free().  The underlying reason for the ioctl failure is the
> > check in [linuxsrc]:drivers/block/blktap/ring.c:blktap_ring_destroy()

> drivers/*xen*/... right? Or do you have a different blktap to me?

I believe the 'drivers/*xen*' was an old location.

You may have seen the note I sent to Tim Wood yesterday.  We isolated
the blktap2 code from the last GIT tree which Dan Stodden had
available and are carrying it as a standalone patch.  The version we
are testing against is available from the following location:

ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch

Dan had the code in the following location:

	drivers/block/blktap

> > for whether or not the task_struct pointer in the blktap_ring
> > structure has been NULLed.
> > 
> > Which certainly makes sense since there is a race between xl's call to
> > tap_ctl_free() and tapdisk2 getting to the point where it can close
> > its descriptor to the blktap instance and thus invoke the .release
> > method which translates into a call to blktap_ring_release() which
> > NULL's the task_struct pointer.

> Sounds right, but then you would expect both the ioctl and release
> path to cleanup, depending on who loses the race?

The problem is the ioctl path can't clean up properly since it is
blocked from doing so by the check for a valid task_struct pointer.
The tapdisk2 side cleans up properly but with the 'acknowledge the
detach and then detach patch' the xl side is always guaranteed to win
the race.

So the patch moved the failure one ladder step downwards in:

[xensrc]/tools/blktap2/control/tap-ctl-destroy.c:tap_control_destroy()

But the effective result is the same, modulo the elimination of the
'hang' while the select call times out.

> There also seems to be a BLKTAP_SHUTDOWN_REQUESTED bit which looks like
> it is involved somehow...
>
> We've gotten way beyond my understanding of blktap internals though.

That bit is set by the kernel kobject infrastructure as part of the
teardown of the block device and I believe is implicated to the extent
that the xl<->tapdisk2 deadlock is caused by a reference still being
held to the block device when the the detach message is sent to
tapdisk2.

I can now reproduce the deadlock with a tap-ctl recipe which should
help in chasing things down.  CAUTION: *** the following will livelock
your kernel, you will need to have a shell available to force an
unmount of the tapdev device. ***

	1.) Create aio based device with tap-ctl.

	2.) Mount tapdev device.

	3.) Close device with tap-ctl.

	4.) Send detach message with tap-ctl.

	* Livelock *

	5.) Kill tapdisk2 process.

	6.) Unmount tapdev - kernel issues WARNING from fs/buffer.c.

Having this recipe should at least help run down which lock we are
wedging on.

> > Let me know if you are seeing the issues I'm seeing, in the meantime I
> > will keep hunting to see if I can rundown the ultimate cause of the
> > deadlock.  Given the above trace it has to be an issue with xl
> > orchestrating the release of resources which reference the tapdev
> > block device.

> I'm not convinced that the shutdown stuff on the kernel side isn't
> either horribly broken or at best fragile (perhaps xl just tickles
> it differently to xend).

I don't believe its fragile as much as the classic problem of having
the kernel dependent on userspace.

I think the underlying problem is the device release order between
xend and xl.  I believe xend is releasing all references to the tapdev
device before invoking userspace cleanup.

> Please do keep hunting and let us know what you find...

I will wade a bit deeper into xl to see if I can isolate the ordering
problem.

> Thanks,
> Ian

Thanks for the verification from your end on the problem.

Have a good day.

Greg

}-- End of excerpt from Ian Campbell

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Inspite of all evidence to the contrary, the entire universe is
 composed of only two basic substances: magic and bullshit."
                                -- Ian Macdonald

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzEO-0007A3-2k; Wed, 11 Apr 2012 15:13:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SHzEM-00079y-TI
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 15:13:11 +0000
Received: from [85.158.143.99:8758] by server-2.bemta-4.messagelabs.com id
	AC/19-17550-68F958F4; Wed, 11 Apr 2012 15:13:10 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334157187!12019603!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17594 invoked from network); 11 Apr 2012 15:13:08 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-16.tower-216.messagelabs.com with SMTP;
	11 Apr 2012 15:13:08 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q3BFD2r9027040;
	Wed, 11 Apr 2012 10:13:02 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q3BFD2AZ027039;
	Wed, 11 Apr 2012 10:13:02 -0500
Date: Wed, 11 Apr 2012 10:13:02 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204111513.q3BFD2AZ027039@wind.enjellic.com>
In-Reply-To: Ian Campbell <Ian.Campbell@citrix.com>
	"Re: [Xen-devel] Basic blktap2 functionality issues." (Apr 10, 10:04am)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Wed, 11 Apr 2012 10:13:02 -0500 (CDT)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Apr 10, 10:04am, Ian Campbell wrote:
} Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

> On Sat, 2012-04-07 at 16:59 +0100, Dr. Greg Wettstein wrote:
> > On Mar 30, 12:23pm, Ian Campbell wrote:
> > } Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

> > > On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > > > I think an approach worth trying would be to have
> > > > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > > > doing the actual detach. i.e. it would respond with "Yes, I will do
> > > > that" rather than "Yes, I have done that". My speculation is that this
> > > > will allow libxl to continue and hopefully avoid the deadlock.
> > 
> > > This seems to be the case as the following fixes things for
> > > me. Thanks very much for your analysis which lead me to this
> > > solution...
> > 
> > I ported your fix into 4.1.2 but I think we still have a problem, at
> > least in this codebase.
> > 
> > I no longer see the select timeout delay when xl shuts down but upon
> > shutdown the minor number is not freed.  A 'tap-ctl list' shows a
> > steadily increasing set of orphaned minor numbers as VM's are started
> > up and shutdown.
> > 
> > Are you seeing this in your development codebase?

> It turns out that I am, yes. e.g. after starting/stopping a guest 3
> times:
> # tap-ctl list
>        -  0    -          - -
>        -  1    -          - -
>        -  2    -          - -

Yes, that is the same thing I'm seeing and would be expected.

> > The culprit is a failed ioctl call for BLKTAP2_IOCTL_FREE_TAP in
> > tap_ctl_free().  The underlying reason for the ioctl failure is the
> > check in [linuxsrc]:drivers/block/blktap/ring.c:blktap_ring_destroy()

> drivers/*xen*/... right? Or do you have a different blktap to me?

I believe the 'drivers/*xen*' was an old location.

You may have seen the note I sent to Tim Wood yesterday.  We isolated
the blktap2 code from the last GIT tree which Dan Stodden had
available and are carrying it as a standalone patch.  The version we
are testing against is available from the following location:

ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch

Dan had the code in the following location:

	drivers/block/blktap

> > for whether or not the task_struct pointer in the blktap_ring
> > structure has been NULLed.
> > 
> > Which certainly makes sense since there is a race between xl's call to
> > tap_ctl_free() and tapdisk2 getting to the point where it can close
> > its descriptor to the blktap instance and thus invoke the .release
> > method which translates into a call to blktap_ring_release() which
> > NULL's the task_struct pointer.

> Sounds right, but then you would expect both the ioctl and release
> path to cleanup, depending on who loses the race?

The problem is the ioctl path can't clean up properly since it is
blocked from doing so by the check for a valid task_struct pointer.
The tapdisk2 side cleans up properly but with the 'acknowledge the
detach and then detach patch' the xl side is always guaranteed to win
the race.

So the patch moved the failure one ladder step downwards in:

[xensrc]/tools/blktap2/control/tap-ctl-destroy.c:tap_control_destroy()

But the effective result is the same, modulo the elimination of the
'hang' while the select call times out.

> There also seems to be a BLKTAP_SHUTDOWN_REQUESTED bit which looks like
> it is involved somehow...
>
> We've gotten way beyond my understanding of blktap internals though.

That bit is set by the kernel kobject infrastructure as part of the
teardown of the block device and I believe is implicated to the extent
that the xl<->tapdisk2 deadlock is caused by a reference still being
held to the block device when the the detach message is sent to
tapdisk2.

I can now reproduce the deadlock with a tap-ctl recipe which should
help in chasing things down.  CAUTION: *** the following will livelock
your kernel, you will need to have a shell available to force an
unmount of the tapdev device. ***

	1.) Create aio based device with tap-ctl.

	2.) Mount tapdev device.

	3.) Close device with tap-ctl.

	4.) Send detach message with tap-ctl.

	* Livelock *

	5.) Kill tapdisk2 process.

	6.) Unmount tapdev - kernel issues WARNING from fs/buffer.c.

Having this recipe should at least help run down which lock we are
wedging on.

> > Let me know if you are seeing the issues I'm seeing, in the meantime I
> > will keep hunting to see if I can rundown the ultimate cause of the
> > deadlock.  Given the above trace it has to be an issue with xl
> > orchestrating the release of resources which reference the tapdev
> > block device.

> I'm not convinced that the shutdown stuff on the kernel side isn't
> either horribly broken or at best fragile (perhaps xl just tickles
> it differently to xend).

I don't believe its fragile as much as the classic problem of having
the kernel dependent on userspace.

I think the underlying problem is the device release order between
xend and xl.  I believe xend is releasing all references to the tapdev
device before invoking userspace cleanup.

> Please do keep hunting and let us know what you find...

I will wade a bit deeper into xl to see if I can isolate the ordering
problem.

> Thanks,
> Ian

Thanks for the verification from your end on the problem.

Have a good day.

Greg

}-- End of excerpt from Ian Campbell

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Inspite of all evidence to the contrary, the entire universe is
 composed of only two basic substances: magic and bullshit."
                                -- Ian Macdonald

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzWk-0007Vb-1E; Wed, 11 Apr 2012 15:32:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzWi-0007VW-Rr
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:32:08 +0000
Received: from [85.158.139.83:54141] by server-9.bemta-5.messagelabs.com id
	93/79-09826-8F3A58F4; Wed, 11 Apr 2012 15:32:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334158327!22703839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5103 invoked from network); 11 Apr 2012 15:32:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:32:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:32:07 +0100
Date: Wed, 11 Apr 2012 16:35:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334152772.16387.18.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111635470.15151@kaball-desktop>
References: <E1SHy1P-0000Kg-FL@xenbits.xen.org>
	<1334152772.16387.18.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Xen-staging] [qemu-upstream-unstable] xen_disk:
 when using AIO flush after the operation is completed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 11 Apr 2012, Ian Campbell wrote:
> On Wed, 2012-04-11 at 14:55 +0100, patchbot@xen.org wrote:
> > commit 4db776322827f0930d53b9e162dc1c6600d918d0
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date:   Fri Mar 23 11:37:25 2012 +0000
> > 
> >     xen_disk: when using AIO flush after the operation is completed
> >     
> >     If ioreq->postsync call bdrv_flush when the AIO operation is actually
> >     completed.
> 
> It'd be helpful if the commit message was amended to reference the
> original upstream commit when backporting, like we do in the
> xen-X.Y-testing trees and like is done in the Linux stable trees etc.

I'll do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzWk-0007Vb-1E; Wed, 11 Apr 2012 15:32:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzWi-0007VW-Rr
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:32:08 +0000
Received: from [85.158.139.83:54141] by server-9.bemta-5.messagelabs.com id
	93/79-09826-8F3A58F4; Wed, 11 Apr 2012 15:32:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334158327!22703839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5103 invoked from network); 11 Apr 2012 15:32:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:32:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:32:07 +0100
Date: Wed, 11 Apr 2012 16:35:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334152772.16387.18.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111635470.15151@kaball-desktop>
References: <E1SHy1P-0000Kg-FL@xenbits.xen.org>
	<1334152772.16387.18.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Xen-staging] [qemu-upstream-unstable] xen_disk:
 when using AIO flush after the operation is completed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 11 Apr 2012, Ian Campbell wrote:
> On Wed, 2012-04-11 at 14:55 +0100, patchbot@xen.org wrote:
> > commit 4db776322827f0930d53b9e162dc1c6600d918d0
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date:   Fri Mar 23 11:37:25 2012 +0000
> > 
> >     xen_disk: when using AIO flush after the operation is completed
> >     
> >     If ioreq->postsync call bdrv_flush when the AIO operation is actually
> >     completed.
> 
> It'd be helpful if the commit message was amended to reference the
> original upstream commit when backporting, like we do in the
> xen-X.Y-testing trees and like is done in the Linux stable trees etc.

I'll do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:37:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzat-0007i8-P2; Wed, 11 Apr 2012 15:36:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzas-0007i3-K0
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:36:26 +0000
Received: from [193.109.254.147:28575] by server-6.bemta-14.messagelabs.com id
	3C/56-02047-9F4A58F4; Wed, 11 Apr 2012 15:36:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334158571!4168105!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4685 invoked from network); 11 Apr 2012 15:36:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:36:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:35:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:35:44 +0100
Date: Wed, 11 Apr 2012 16:39:32 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.55876.979344.17338@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111636260.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
	<20345.55876.979344.17338@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance
 improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> > Hi all,
> > this small patch series enables the O_DIRECT flag to open disk images
> > for both the IDE and xen_disk interface.
> > Also it includes few fixes for xen_disk.
> > 
> > Stefano Stabellini (3):
> >       qemu-xen-traditional: use O_DIRECT to open disk images for IDE
> >       qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
> >       qemu-xen-traditional: QDISK fixes
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 

Could you please backport these patches to qemu-xen-4.1-testing?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:37:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzat-0007i8-P2; Wed, 11 Apr 2012 15:36:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzas-0007i3-K0
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:36:26 +0000
Received: from [193.109.254.147:28575] by server-6.bemta-14.messagelabs.com id
	3C/56-02047-9F4A58F4; Wed, 11 Apr 2012 15:36:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334158571!4168105!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4685 invoked from network); 11 Apr 2012 15:36:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:36:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:35:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:35:44 +0100
Date: Wed, 11 Apr 2012 16:39:32 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20345.55876.979344.17338@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111636260.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
	<20345.55876.979344.17338@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance
 improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> > Hi all,
> > this small patch series enables the O_DIRECT flag to open disk images
> > for both the IDE and xen_disk interface.
> > Also it includes few fixes for xen_disk.
> > 
> > Stefano Stabellini (3):
> >       qemu-xen-traditional: use O_DIRECT to open disk images for IDE
> >       qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
> >       qemu-xen-traditional: QDISK fixes
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 

Could you please backport these patches to qemu-xen-4.1-testing?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:46:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzkD-00085c-2Q; Wed, 11 Apr 2012 15:46:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzkB-00085X-9H
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:46:03 +0000
Received: from [85.158.138.51:29069] by server-11.bemta-3.messagelabs.com id
	61/D2-18894-A37A58F4; Wed, 11 Apr 2012 15:46:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334159161!21707154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14739 invoked from network); 11 Apr 2012 15:46:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:45:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:45:45 +0100
Date: Wed, 11 Apr 2012 16:49:32 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204101832320.15151@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1204111649010.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
	<20347.2076.974553.319109@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204101832320.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 10 Apr 2012, Stefano Stabellini wrote:
> On Tue, 3 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> > ...
> > > I don't think it is worth adding one more option for something like
> > > this: nobody should be using this option anyway. I am still unconvinced
> > > there is a valid use case for this.
> > 
> > I think it's important.  An additional config option is IMO necessary
> > to allow the admin to impose their vbd allocation strategy.
> 
> It shouldn't be a per-VM paramater (part of libxl_domain_config, for
> example) and I don't think it is a good idea to plumb a new parameter
> through from XL to libxl_create for this purpose.
> 
> What did you have in mind when you thought about having a new paramater
> for this?

In case it wasn't obvious I decided to go for modifying libxl_create,
see the new version of the series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:46:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzkD-00085c-2Q; Wed, 11 Apr 2012 15:46:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzkB-00085X-9H
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:46:03 +0000
Received: from [85.158.138.51:29069] by server-11.bemta-3.messagelabs.com id
	61/D2-18894-A37A58F4; Wed, 11 Apr 2012 15:46:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334159161!21707154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14739 invoked from network); 11 Apr 2012 15:46:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:45:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:45:45 +0100
Date: Wed, 11 Apr 2012 16:49:32 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204101832320.15151@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1204111649010.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203271453390.15151@kaball-desktop>
	<1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20337.63133.683848.208682@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301151120.15151@kaball-desktop>
	<20341.49280.31751.307404@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1203301556100.15151@kaball-desktop>
	<20345.53429.51575.373166@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031303240.15151@kaball-desktop>
	<20346.63616.101912.260089@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204031517090.15151@kaball-desktop>
	<20347.2076.974553.319109@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204101832320.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 10 Apr 2012, Stefano Stabellini wrote:
> On Tue, 3 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"):
> > ...
> > > I don't think it is worth adding one more option for something like
> > > this: nobody should be using this option anyway. I am still unconvinced
> > > there is a valid use case for this.
> > 
> > I think it's important.  An additional config option is IMO necessary
> > to allow the admin to impose their vbd allocation strategy.
> 
> It shouldn't be a per-VM paramater (part of libxl_domain_config, for
> example) and I don't think it is a good idea to plumb a new parameter
> through from XL to libxl_create for this purpose.
> 
> What did you have in mind when you thought about having a new paramater
> for this?

In case it wasn't obvious I decided to go for modifying libxl_create,
see the new version of the series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzmG-0008AL-IF; Wed, 11 Apr 2012 15:48:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHzmF-0008AE-CX
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:48:11 +0000
Received: from [85.158.138.51:42899] by server-12.bemta-3.messagelabs.com id
	BA/69-29760-AB7A58F4; Wed, 11 Apr 2012 15:48:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334159288!21714953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4327 invoked from network); 11 Apr 2012 15:48:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:48:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:48:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 16:48:08 +0100
Message-ID: <1334159286.16387.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 16:48:06 +0100
In-Reply-To: <osstest-12632-mainreport@xen.org>
References: <osstest-12632-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL
 - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 23:23 +0100, xen.org wrote:
> flight 12632 linux-mingo-tip-master real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/
> 
> Failures :-/ but no regressions.
> 
> Tests which did not succeed, but are not blocking:
>  test-i386-i386-xl-win         5 xen-boot                     fail   never pass

At least some of these xen-boot failures (I looked at
http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/test-amd64-amd64-xl-win7-amd64/serial-itch-mite.log) have missing firmware:

Apr 10 13:57:11.884530 [   28.946844] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1b.fw"

That'll be because the new kernel needs something newer than what is
provided by Squeeze's linux-firmware* packages. I usually set
CONFIG_FIRMWARE_IN_KERNEL to avoid this (mostly, sometimes they forget
to even include the firmware update, which happened once recently with
bnx2 IIRC, so watch out for that):

The other option, as noted below, is to run "make firmware_install".

config FIRMWARE_IN_KERNEL
        bool "Include in-kernel firmware blobs in kernel binary"
        depends on FW_LOADER
        default y
        help
          The kernel source tree includes a number of firmware 'blobs'
          that are used by various drivers. The recommended way to
          use these is to run "make firmware_install", which, after
          converting ihex files to binary, copies all of the needed
          binary files in firmware/ to /lib/firmware/ on your system so
          that they can be loaded by userspace helpers on request.

          Enabling this option will build each required firmware blob
          into the kernel directly, where request_firmware() will find
          them without having to call out to userspace. This may be
          useful if your root file system requires a device that uses
          such firmware and do not wish to use an initrd.

          This single option controls the inclusion of firmware for
          every driver that uses request_firmware() and ships its
          firmware in the kernel source tree, which avoids a
          proliferation of 'Include firmware for xxx device' options.


Ian.

>  test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
>  test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
>  test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
>  test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
>  test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
>  test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
>  test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
>  test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
>  test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
>  test-amd64-i386-xl            7 debian-install               fail   never pass
>  test-i386-i386-pv             7 debian-install               fail   never pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-i386-i386-win           16 leak-check/check             fail   never pass
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
>  test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
>  test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
> 
> version targeted for testing:
>  linux                e63089b08140adea85d011da136c7b56d73296ee
> baseline version:
>  linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7
> 
> ------------------------------------------------------------
> People who touched revisions under test:
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass
>  build-i386                                                   pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          pass
>  test-amd64-i386-xl                                           fail
>  test-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 fail
>  test-amd64-i386-qemuu-rhel6hvm-amd                           fail
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail
>  test-amd64-amd64-xl-win7-amd64                               fail
>  test-amd64-i386-xl-win7-amd64                                fail
>  test-amd64-i386-xl-credit2                                   fail
>  test-amd64-amd64-xl-pcipt-intel                              fail
>  test-amd64-i386-rhel6hvm-intel                               fail
>  test-amd64-i386-qemuu-rhel6hvm-intel                         fail
>  test-amd64-i386-xl-multivcpu                                 fail
>  test-amd64-amd64-pair                                        pass
>  test-amd64-i386-pair                                         fail
>  test-i386-i386-pair                                          pass
>  test-amd64-amd64-xl-sedf-pin                                 pass
>  test-amd64-amd64-pv                                          pass
>  test-amd64-i386-pv                                           pass
>  test-i386-i386-pv                                            fail
>  test-amd64-amd64-xl-sedf                                     pass
>  test-amd64-i386-win-vcpus1                                   fail
>  test-amd64-i386-xl-win-vcpus1                                fail
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail
>  test-amd64-amd64-win                                         fail
>  test-amd64-i386-win                                          fail
>  test-i386-i386-win                                           fail
>  test-amd64-amd64-xl-win                                      fail
>  test-i386-i386-xl-win                                        fail
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail
>  test-i386-i386-xl-qemuu-winxpsp3                             fail
>  test-amd64-i386-xend-winxpsp3                                fail
>  test-amd64-amd64-xl-winxpsp3                                 fail
>  test-i386-i386-xl-winxpsp3                                   fail
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Pushing revision :
> 
> + branch=linux-mingo-tip-master
> + revision=e63089b08140adea85d011da136c7b56d73296ee
> + . cri-lock-repos
> ++ . cri-common
> +++ umask 002
> +++ getconfig Repos
> +++ perl -e '
>                 use Osstest;
>                 readconfigonly();
>                 print $c{Repos} or die $!;
>         '
> ++ repos=/export/home/osstest/repos
> ++ repos_lock=/export/home/osstest/repos/lock
> ++ '[' x '!=' x/export/home/osstest/repos/lock ']'
> ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
> ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-mingo-tip-master e63089b08140adea85d011da136c7b56d73296ee
> + branch=linux-mingo-tip-master
> + revision=e63089b08140adea85d011da136c7b56d73296ee
> + . cri-lock-repos
> ++ . cri-common
> +++ umask 002
> +++ getconfig Repos
> +++ perl -e '
>                 use Osstest;
>                 readconfigonly();
>                 print $c{Repos} or die $!;
>         '
> ++ repos=/export/home/osstest/repos
> ++ repos_lock=/export/home/osstest/repos/lock
> ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
> + . cri-common
> ++ umask 002
> + select_xenbranch
> + case "$branch" in
> + tree=linux
> + xenbranch=xen-unstable
> + '[' xlinux = xlinux ']'
> + linuxbranch=linux-mingo-tip-master
> + : master
> + : tested/2.6.39.x
> + : :git/qemu-upstream-unstable.git
> + . ap-common
> ++ : xen@xenbits.xensource.com
> ++ : http://xenbits.xen.org/staging/xen-unstable.hg
> ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
> ++ : git://git.kernel.org
> ++ : git://git.kernel.org/pub/scm/linux/kernel/git
> ++ : git
> ++ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> ++ : master
> ++ : xen@xenbits.xensource.com:git/linux-pvops.git
> ++ : git://xenbits.xen.org/linux-pvops.git
> ++ : master
> ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> ++ : tested/2.6.39.x
> ++ : daily-cron.linux-mingo-tip-master
> ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
> ++ : :git/qemu-upstream-unstable.git
> ++ : daily-cron.linux-mingo-tip-master
> + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
> + info_linux_tree linux-mingo-tip-master
> + case $1 in
> + : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> + : -f
> + : master
> + : git
> + : git
> + : git://xenbits.xen.org/linux-pvops.git
> + : xen@xenbits.xensource.com:git/linux-pvops.git
> + : tested/linux-mingo-tip-master
> + : tested/linux-mingo-tip-master
> + return 0
> + cd /export/home/osstest/repos/linux
> + git push -f xen@xenbits.xensource.com:git/linux-pvops.git e63089b08140adea85d011da136c7b56d73296ee:tested/linux-mingo-tip-master
> Counting objects: 1
> Counting objects: 7
> Counting objects: 10
> Counting objects: 422
> Counting objects: 809
> Counting objects: 3371
> Counting objects: 7557
> Counting objects: 16162
> Counting objects: 31711
> Counting objects: 49542
> Counting objects: 74361
> Counting objects: 102682
> Counting objects: 118617, done.
> Compressing objects:   0% (1/19257)
> Compressing objects:   0% (173/19257)
> Compressing objects:   1% (193/19257)
> Compressing objects:   2% (386/19257)
> Compressing objects:   2% (482/19257)
> Compressing objects:   3% (578/19257)
> Compressing objects:   4% (771/19257)
> Compressing objects:   5% (963/19257)
> Compressing objects:   5% (1108/19257)
> Compressing objects:   6% (1156/19257)
> Compressing objects:   7% (1348/19257)
> Compressing objects:   7% (1400/19257)
> Compressing objects:   8% (1541/19257)
> Compressing objects:   8% (1710/19257)
> Compressing objects:   9% (1734/19257)
> Compressing objects:  10% (1926/19257)
> Compressing objects:  11% (2119/19257)
> Compressing objects:  11% (2195/19257)
> Compressing objects:  12% (2311/19257)
> Compressing objects:  13% (2504/19257)
> Compressing objects:  13% (2566/19257)
> Compressing objects:  14% (2696/19257)
> Compressing objects:  14% (2882/19257)
> Compressing objects:  15% (2889/19257)
> Compressing objects:  16% (3082/19257)
> Compressing objects:  16% (3116/19257)
> Compressing objects:  17% (3274/19257)
> Compressing objects:  18% (3467/19257)
> Compressing objects:  19% (3659/19257)
> Compressing objects:  20% (3852/19257)
> Compressing objects:  21% (4044/19257)
> Compressing objects:  22% (4237/19257)
> Compressing objects:  23% (4430/19257)
> Compressing objects:  24% (4622/19257)
> Compressing objects:  25% (4815/19257)
> Compressing objects:  26% (5007/19257)
> Compressing objects:  27% (5200/19257)
> Compressing objects:  28% (5392/19257)
> Compressing objects:  29% (5585/19257)
> Compressing objects:  30% (5778/19257)
> Compressing objects:  31% (5970/19257)
> Compressing objects:  32% (6163/19257)
> Compressing objects:  33% (6355/19257)
> Compressing objects:  34% (6548/19257)
> Compressing objects:  35% (6740/19257)
> Compressing objects:  36% (6933/19257)
> Compressing objects:  37% (7126/19257)
> Compressing objects:  38% (7318/19257)
> Compressing objects:  39% (7511/19257)
> Compressing objects:  40% (7703/19257)
> Compressing objects:  41% (7896/19257)
> Compressing objects:  42% (8088/19257)
> Compressing objects:  43% (8281/19257)
> Compressing objects:  44% (8474/19257)
> Compressing objects:  45% (8666/19257)
> Compressing objects:  45% (8739/19257)
> Compressing objects:  46% (8859/19257)
> Compressing objects:  47% (9051/19257)
> Compressing objects:  48% (9244/19257)
> Compressing objects:  49% (9436/19257)
> Compressing objects:  50% (9629/19257)
> Compressing objects:  51% (9822/19257)
> Compressing objects:  52% (10014/19257)
> Compressing objects:  53% (10207/19257)
> Compressing objects:  54% (10399/19257)
> Compressing objects:  55% (10592/19257)
> Compressing objects:  56% (10784/19257)
> Compressing objects:  57% (10977/19257)
> Compressing objects:  58% (11170/19257)
> Compressing objects:  59% (11362/19257)
> Compressing objects:  60% (11555/19257)
> Compressing objects:  61% (11747/19257)
> Compressing objects:  62% (11940/19257)
> Compressing objects:  63% (12132/19257)
> Compressing objects:  64% (12325/19257)
> Compressing objects:  65% (12518/19257)
> Compressing objects:  66% (12710/19257)
> Compressing objects:  67% (12903/19257)
> Compressing objects:  68% (13095/19257)
> Compressing objects:  69% (13288/19257)
> Compressing objects:  70% (13480/19257)
> Compressing objects:  71% (13673/19257)
> Compressing objects:  72% (13866/19257)
> Compressing objects:  73% (14058/19257)
> Compressing objects:  74% (14251/19257)
> Compressing objects:  75% (14443/19257)
> Compressing objects:  76% (14636/19257)
> Compressing objects:  77% (14828/19257)
> Compressing objects:  78% (15021/19257)
> Compressing objects:  79% (15214/19257)
> Compressing objects:  80% (15406/19257)
> Compressing objects:  81% (15599/19257)
> Compressing objects:  82% (15791/19257)
> Compressing objects:  83% (15984/19257)
> Compressing objects:  84% (16176/19257)
> Compressing objects:  85% (16369/19257)
> Compressing objects:  86% (16562/19257)
> Compressing objects:  87% (16754/19257)
> Compressing objects:  88% (16947/19257)
> Compressing objects:  89% (17139/19257)
> Compressing objects:  90% (17332/19257)
> Compressing objects:  91% (17524/19257)
> Compressing objects:  92% (17717/19257)
> Compressing objects:  93% (17910/19257)
> Compressing objects:  94% (18102/19257)
> Compressing objects:  95% (18295/19257)
> Compressing objects:  96% (18487/19257)
> Compressing objects:  97% (18680/19257)
> Compressing objects:  98% (18872/19257)
> Compressing objects:  99% (19065/19257)
> Compressing objects: 100% (19257/19257)
> Compressing objects: 100% (19257/19257), done.
> Writing objects:   0% (1/101021)
> Writing objects:   1% (1011/101021)
> Writing objects:   2% (2021/101021)
> Writing objects:   3% (3031/101021)
> Writing objects:   4% (4041/101021)
> Writing objects:   5% (5052/101021)
> Writing objects:   5% (5436/101021), 2.14 MiB | 1466 KiB/s
> Writing objects:   5% (5575/101021), 2.19 MiB | 1062 KiB/s
> Writing objects:   6% (6062/101021), 2.32 MiB | 894 KiB/s
> Writing objects:   7% (7072/101021), 2.32 MiB | 894 KiB/s
> Writing objects:   7% (7213/101021), 2.32 MiB | 894 KiB/s
> Writing objects:   8% (8082/101021), 3.08 MiB | 981 KiB/s
> Writing objects:   9% (9092/101021), 3.08 MiB | 981 KiB/s
> Writing objects:   9% (9555/101021), 3.46 MiB | 906 KiB/s
> Writing objects:  10% (10103/101021), 3.46 MiB | 906 KiB/s
> Writing objects:  10% (11008/101021), 3.84 MiB | 869 KiB/s
> Writing objects:  11% (11113/101021), 3.84 MiB | 869 KiB/s
> Writing objects:  12% (12123/101021), 4.21 MiB | 810 KiB/s
> Writing objects:  12% (12724/101021), 4.58 MiB | 784 KiB/s
> Writing objects:  13% (13133/101021), 4.58 MiB | 784 KiB/s
> Writing objects:  14% (14144/101021), 4.96 MiB | 500 KiB/s
> Writing objects:  14% (14256/101021), 5.21 MiB | 541 KiB/s
> Writing objects:  14% (14782/101021), 5.46 MiB | 558 KiB/s
> Writing objects:  15% (15155/101021), 5.46 MiB | 558 KiB/s
> Writing objects:  15% (15476/101021), 5.71 MiB | 558 KiB/s
> Writing objects:  15% (15903/101021), 5.96 MiB | 458 KiB/s
> Writing objects:  16% (16164/101021), 6.21 MiB | 441 KiB/s
> Writing objects:  16% (16865/101021), 6.58 MiB | 439 KiB/s
> Writing objects:  17% (17174/101021), 6.58 MiB | 439 KiB/s
> Writing objects:  17% (17838/101021), 6.96 MiB | 454 KiB/s
> Writing objects:  18% (18185/101021), 7.33 MiB | 451 KiB/s
> Writing objects:  18% (18916/101021), 7.71 MiB | 452 KiB/s
> Writing objects:  19% (19194/101021), 7.71 MiB | 452 KiB/s
> Writing objects:  20% (20205/101021), 8.08 MiB | 475 KiB/s
> Writing objects:  20% (20221/101021), 8.46 MiB | 511 KiB/s
> Writing objects:  20% (20991/101021), 8.83 MiB | 544 KiB/s
> Writing objects:  21% (21217/101021), 8.83 MiB | 544 KiB/s
> Writing objects:  21% (22219/101021), 9.46 MiB | 594 KiB/s
> Writing objects:  22% (22225/101021), 9.46 MiB | 594 KiB/s
> Writing objects:  23% (23235/101021), 9.83 MiB | 595 KiB/s
> Writing objects:  23% (23246/101021), 10.21 MiB | 589 KiB/s
> Writing objects:  24% (24248/101021), 10.58 MiB | 592 KiB/s
> Writing objects:  24% (24304/101021), 10.58 MiB | 592 KiB/s
> Writing objects:  25% (25256/101021), 10.96 MiB | 593 KiB/s
> Writing objects:  25% (25743/101021), 11.33 MiB | 594 KiB/s
> Writing objects:  26% (26266/101021), 11.33 MiB | 594 KiB/s
> Writing objects:  27% (27276/101021), 11.71 MiB | 595 KiB/s
> Writing objects:  27% (27624/101021), 11.96 MiB | 583 KiB/s
> Writing objects:  28% (28287/101021), 11.96 MiB | 583 KiB/s
> Writing objects:  28% (28747/101021), 12.33 MiB | 592 KiB/s
> Writing objects:  29% (29297/101021), 12.33 MiB | 592 KiB/s
> Writing objects:  30% (30307/101021), 12.71 MiB | 590 KiB/s
> Writing objects:  31% (31317/101021), 12.71 MiB | 590 KiB/s
> Writing objects:  31% (31543/101021), 12.96 MiB | 578 KiB/s
> Writing objects:  32% (32327/101021), 12.96 MiB | 578 KiB/s
> Writing objects:  33% (33337/101021), 12.96 MiB | 578 KiB/s
> Writing objects:  34% (34348/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  35% (35358/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  35% (35825/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  36% (36369/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  37% (37378/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  38% (38388/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  39% (39399/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  40% (40409/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  41% (41420/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  41% (41488/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  42% (42429/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  43% (43440/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  44% (44450/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  45% (45460/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  45% (45852/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  46% (46470/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  47% (47480/101021), 14.83 MiB | 574 KiB/s
> Writing objects:  48% (48492/101021), 14.83 MiB | 574 KiB/s
> Writing objects:  49% (49501/101021), 14.83 MiB | 574 KiB/s
> Writing objects:  50% (50511/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  50% (50758/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  51% (51521/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  52% (52531/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  53% (53542/101021), 15.58 MiB | 583 KiB/s
> Writing objects:  54% (54552/101021), 15.58 MiB | 583 KiB/s
> Writing objects:  55% (55562/101021), 15.58 MiB | 583 KiB/s
> Writing objects:  55% (56373/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  56% (56572/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  57% (57582/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  58% (58594/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  59% (59603/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  60% (60613/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  60% (61041/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  61% (61623/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  62% (62634/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  63% (63644/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  64% (64654/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  65% (65664/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  66% (66674/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  66% (66990/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  67% (67685/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  68% (68695/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  69% (69705/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  70% (70715/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  71% (71726/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  72% (72736/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  72% (73271/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  73% (73746/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  74% (74756/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  75% (75766/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  76% (76776/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  77% (77787/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  77% (78471/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  78% (78799/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  79% (79808/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  80% (80817/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  81% (81828/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  82% (82838/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  83% (83848/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  83% (84657/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  84% (84858/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  85% (85868/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  86% (86879/101021), 18.96 MiB | 603 KiB/s
> Writing objects:  87% (87890/101021), 18.96 MiB | 603 KiB/s
> Writing objects:  88% (88899/101021), 18.96 MiB | 603 KiB/s
> Writing objects:  89% (89909/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  89% (90835/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  90% (90919/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  91% (91930/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  92% (92940/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  93% (93950/101021), 19.71 MiB | 603 KiB/s
> Writing objects:  94% (94960/101021), 19.71 MiB | 603 KiB/s
> Writing objects:  95% (95971/101021), 19.71 MiB | 603 KiB/s
> Writing objects:  95% (96582/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  96% (96981/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  97% (97991/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  98% (99001/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  99% (100011/101021), 20.08 MiB | 596 KiB/s
> Writing objects: 100% (101021/101021), 20.46 MiB | 593 KiB/s
> Writing objects: 100% (101021/101021), 20.51 MiB | 597 KiB/s, done.
> Total 101021 (delta 84244), reused 96025 (delta 79512)
> To xen@xenbits.xensource.com:git/linux-pvops.git
>    c16fa4f..e63089b  e63089b08140adea85d011da136c7b56d73296ee -> tested/linux-mingo-tip-master
> + exit 0
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzmG-0008AL-IF; Wed, 11 Apr 2012 15:48:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SHzmF-0008AE-CX
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:48:11 +0000
Received: from [85.158.138.51:42899] by server-12.bemta-3.messagelabs.com id
	BA/69-29760-AB7A58F4; Wed, 11 Apr 2012 15:48:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334159288!21714953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4327 invoked from network); 11 Apr 2012 15:48:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:48:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11882899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:48:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 16:48:08 +0100
Message-ID: <1334159286.16387.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 16:48:06 +0100
In-Reply-To: <osstest-12632-mainreport@xen.org>
References: <osstest-12632-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL
 - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-10 at 23:23 +0100, xen.org wrote:
> flight 12632 linux-mingo-tip-master real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/
> 
> Failures :-/ but no regressions.
> 
> Tests which did not succeed, but are not blocking:
>  test-i386-i386-xl-win         5 xen-boot                     fail   never pass

At least some of these xen-boot failures (I looked at
http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/test-amd64-amd64-xl-win7-amd64/serial-itch-mite.log) have missing firmware:

Apr 10 13:57:11.884530 [   28.946844] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1b.fw"

That'll be because the new kernel needs something newer than what is
provided by Squeeze's linux-firmware* packages. I usually set
CONFIG_FIRMWARE_IN_KERNEL to avoid this (mostly, sometimes they forget
to even include the firmware update, which happened once recently with
bnx2 IIRC, so watch out for that):

The other option, as noted below, is to run "make firmware_install".

config FIRMWARE_IN_KERNEL
        bool "Include in-kernel firmware blobs in kernel binary"
        depends on FW_LOADER
        default y
        help
          The kernel source tree includes a number of firmware 'blobs'
          that are used by various drivers. The recommended way to
          use these is to run "make firmware_install", which, after
          converting ihex files to binary, copies all of the needed
          binary files in firmware/ to /lib/firmware/ on your system so
          that they can be loaded by userspace helpers on request.

          Enabling this option will build each required firmware blob
          into the kernel directly, where request_firmware() will find
          them without having to call out to userspace. This may be
          useful if your root file system requires a device that uses
          such firmware and do not wish to use an initrd.

          This single option controls the inclusion of firmware for
          every driver that uses request_firmware() and ships its
          firmware in the kernel source tree, which avoids a
          proliferation of 'Include firmware for xxx device' options.


Ian.

>  test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
>  test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
>  test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
>  test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
>  test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
>  test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
>  test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
>  test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
>  test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
>  test-amd64-i386-xl            7 debian-install               fail   never pass
>  test-i386-i386-pv             7 debian-install               fail   never pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-i386-i386-win           16 leak-check/check             fail   never pass
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
>  test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
>  test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
> 
> version targeted for testing:
>  linux                e63089b08140adea85d011da136c7b56d73296ee
> baseline version:
>  linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7
> 
> ------------------------------------------------------------
> People who touched revisions under test:
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass
>  build-i386                                                   pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          pass
>  test-amd64-i386-xl                                           fail
>  test-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 fail
>  test-amd64-i386-qemuu-rhel6hvm-amd                           fail
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail
>  test-amd64-amd64-xl-win7-amd64                               fail
>  test-amd64-i386-xl-win7-amd64                                fail
>  test-amd64-i386-xl-credit2                                   fail
>  test-amd64-amd64-xl-pcipt-intel                              fail
>  test-amd64-i386-rhel6hvm-intel                               fail
>  test-amd64-i386-qemuu-rhel6hvm-intel                         fail
>  test-amd64-i386-xl-multivcpu                                 fail
>  test-amd64-amd64-pair                                        pass
>  test-amd64-i386-pair                                         fail
>  test-i386-i386-pair                                          pass
>  test-amd64-amd64-xl-sedf-pin                                 pass
>  test-amd64-amd64-pv                                          pass
>  test-amd64-i386-pv                                           pass
>  test-i386-i386-pv                                            fail
>  test-amd64-amd64-xl-sedf                                     pass
>  test-amd64-i386-win-vcpus1                                   fail
>  test-amd64-i386-xl-win-vcpus1                                fail
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail
>  test-amd64-amd64-win                                         fail
>  test-amd64-i386-win                                          fail
>  test-i386-i386-win                                           fail
>  test-amd64-amd64-xl-win                                      fail
>  test-i386-i386-xl-win                                        fail
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail
>  test-i386-i386-xl-qemuu-winxpsp3                             fail
>  test-amd64-i386-xend-winxpsp3                                fail
>  test-amd64-amd64-xl-winxpsp3                                 fail
>  test-i386-i386-xl-winxpsp3                                   fail
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Pushing revision :
> 
> + branch=linux-mingo-tip-master
> + revision=e63089b08140adea85d011da136c7b56d73296ee
> + . cri-lock-repos
> ++ . cri-common
> +++ umask 002
> +++ getconfig Repos
> +++ perl -e '
>                 use Osstest;
>                 readconfigonly();
>                 print $c{Repos} or die $!;
>         '
> ++ repos=/export/home/osstest/repos
> ++ repos_lock=/export/home/osstest/repos/lock
> ++ '[' x '!=' x/export/home/osstest/repos/lock ']'
> ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
> ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-mingo-tip-master e63089b08140adea85d011da136c7b56d73296ee
> + branch=linux-mingo-tip-master
> + revision=e63089b08140adea85d011da136c7b56d73296ee
> + . cri-lock-repos
> ++ . cri-common
> +++ umask 002
> +++ getconfig Repos
> +++ perl -e '
>                 use Osstest;
>                 readconfigonly();
>                 print $c{Repos} or die $!;
>         '
> ++ repos=/export/home/osstest/repos
> ++ repos_lock=/export/home/osstest/repos/lock
> ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
> + . cri-common
> ++ umask 002
> + select_xenbranch
> + case "$branch" in
> + tree=linux
> + xenbranch=xen-unstable
> + '[' xlinux = xlinux ']'
> + linuxbranch=linux-mingo-tip-master
> + : master
> + : tested/2.6.39.x
> + : :git/qemu-upstream-unstable.git
> + . ap-common
> ++ : xen@xenbits.xensource.com
> ++ : http://xenbits.xen.org/staging/xen-unstable.hg
> ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
> ++ : git://git.kernel.org
> ++ : git://git.kernel.org/pub/scm/linux/kernel/git
> ++ : git
> ++ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> ++ : master
> ++ : xen@xenbits.xensource.com:git/linux-pvops.git
> ++ : git://xenbits.xen.org/linux-pvops.git
> ++ : master
> ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> ++ : tested/2.6.39.x
> ++ : daily-cron.linux-mingo-tip-master
> ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
> ++ : :git/qemu-upstream-unstable.git
> ++ : daily-cron.linux-mingo-tip-master
> + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
> + info_linux_tree linux-mingo-tip-master
> + case $1 in
> + : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> + : -f
> + : master
> + : git
> + : git
> + : git://xenbits.xen.org/linux-pvops.git
> + : xen@xenbits.xensource.com:git/linux-pvops.git
> + : tested/linux-mingo-tip-master
> + : tested/linux-mingo-tip-master
> + return 0
> + cd /export/home/osstest/repos/linux
> + git push -f xen@xenbits.xensource.com:git/linux-pvops.git e63089b08140adea85d011da136c7b56d73296ee:tested/linux-mingo-tip-master
> Counting objects: 1
> Counting objects: 7
> Counting objects: 10
> Counting objects: 422
> Counting objects: 809
> Counting objects: 3371
> Counting objects: 7557
> Counting objects: 16162
> Counting objects: 31711
> Counting objects: 49542
> Counting objects: 74361
> Counting objects: 102682
> Counting objects: 118617, done.
> Compressing objects:   0% (1/19257)
> Compressing objects:   0% (173/19257)
> Compressing objects:   1% (193/19257)
> Compressing objects:   2% (386/19257)
> Compressing objects:   2% (482/19257)
> Compressing objects:   3% (578/19257)
> Compressing objects:   4% (771/19257)
> Compressing objects:   5% (963/19257)
> Compressing objects:   5% (1108/19257)
> Compressing objects:   6% (1156/19257)
> Compressing objects:   7% (1348/19257)
> Compressing objects:   7% (1400/19257)
> Compressing objects:   8% (1541/19257)
> Compressing objects:   8% (1710/19257)
> Compressing objects:   9% (1734/19257)
> Compressing objects:  10% (1926/19257)
> Compressing objects:  11% (2119/19257)
> Compressing objects:  11% (2195/19257)
> Compressing objects:  12% (2311/19257)
> Compressing objects:  13% (2504/19257)
> Compressing objects:  13% (2566/19257)
> Compressing objects:  14% (2696/19257)
> Compressing objects:  14% (2882/19257)
> Compressing objects:  15% (2889/19257)
> Compressing objects:  16% (3082/19257)
> Compressing objects:  16% (3116/19257)
> Compressing objects:  17% (3274/19257)
> Compressing objects:  18% (3467/19257)
> Compressing objects:  19% (3659/19257)
> Compressing objects:  20% (3852/19257)
> Compressing objects:  21% (4044/19257)
> Compressing objects:  22% (4237/19257)
> Compressing objects:  23% (4430/19257)
> Compressing objects:  24% (4622/19257)
> Compressing objects:  25% (4815/19257)
> Compressing objects:  26% (5007/19257)
> Compressing objects:  27% (5200/19257)
> Compressing objects:  28% (5392/19257)
> Compressing objects:  29% (5585/19257)
> Compressing objects:  30% (5778/19257)
> Compressing objects:  31% (5970/19257)
> Compressing objects:  32% (6163/19257)
> Compressing objects:  33% (6355/19257)
> Compressing objects:  34% (6548/19257)
> Compressing objects:  35% (6740/19257)
> Compressing objects:  36% (6933/19257)
> Compressing objects:  37% (7126/19257)
> Compressing objects:  38% (7318/19257)
> Compressing objects:  39% (7511/19257)
> Compressing objects:  40% (7703/19257)
> Compressing objects:  41% (7896/19257)
> Compressing objects:  42% (8088/19257)
> Compressing objects:  43% (8281/19257)
> Compressing objects:  44% (8474/19257)
> Compressing objects:  45% (8666/19257)
> Compressing objects:  45% (8739/19257)
> Compressing objects:  46% (8859/19257)
> Compressing objects:  47% (9051/19257)
> Compressing objects:  48% (9244/19257)
> Compressing objects:  49% (9436/19257)
> Compressing objects:  50% (9629/19257)
> Compressing objects:  51% (9822/19257)
> Compressing objects:  52% (10014/19257)
> Compressing objects:  53% (10207/19257)
> Compressing objects:  54% (10399/19257)
> Compressing objects:  55% (10592/19257)
> Compressing objects:  56% (10784/19257)
> Compressing objects:  57% (10977/19257)
> Compressing objects:  58% (11170/19257)
> Compressing objects:  59% (11362/19257)
> Compressing objects:  60% (11555/19257)
> Compressing objects:  61% (11747/19257)
> Compressing objects:  62% (11940/19257)
> Compressing objects:  63% (12132/19257)
> Compressing objects:  64% (12325/19257)
> Compressing objects:  65% (12518/19257)
> Compressing objects:  66% (12710/19257)
> Compressing objects:  67% (12903/19257)
> Compressing objects:  68% (13095/19257)
> Compressing objects:  69% (13288/19257)
> Compressing objects:  70% (13480/19257)
> Compressing objects:  71% (13673/19257)
> Compressing objects:  72% (13866/19257)
> Compressing objects:  73% (14058/19257)
> Compressing objects:  74% (14251/19257)
> Compressing objects:  75% (14443/19257)
> Compressing objects:  76% (14636/19257)
> Compressing objects:  77% (14828/19257)
> Compressing objects:  78% (15021/19257)
> Compressing objects:  79% (15214/19257)
> Compressing objects:  80% (15406/19257)
> Compressing objects:  81% (15599/19257)
> Compressing objects:  82% (15791/19257)
> Compressing objects:  83% (15984/19257)
> Compressing objects:  84% (16176/19257)
> Compressing objects:  85% (16369/19257)
> Compressing objects:  86% (16562/19257)
> Compressing objects:  87% (16754/19257)
> Compressing objects:  88% (16947/19257)
> Compressing objects:  89% (17139/19257)
> Compressing objects:  90% (17332/19257)
> Compressing objects:  91% (17524/19257)
> Compressing objects:  92% (17717/19257)
> Compressing objects:  93% (17910/19257)
> Compressing objects:  94% (18102/19257)
> Compressing objects:  95% (18295/19257)
> Compressing objects:  96% (18487/19257)
> Compressing objects:  97% (18680/19257)
> Compressing objects:  98% (18872/19257)
> Compressing objects:  99% (19065/19257)
> Compressing objects: 100% (19257/19257)
> Compressing objects: 100% (19257/19257), done.
> Writing objects:   0% (1/101021)
> Writing objects:   1% (1011/101021)
> Writing objects:   2% (2021/101021)
> Writing objects:   3% (3031/101021)
> Writing objects:   4% (4041/101021)
> Writing objects:   5% (5052/101021)
> Writing objects:   5% (5436/101021), 2.14 MiB | 1466 KiB/s
> Writing objects:   5% (5575/101021), 2.19 MiB | 1062 KiB/s
> Writing objects:   6% (6062/101021), 2.32 MiB | 894 KiB/s
> Writing objects:   7% (7072/101021), 2.32 MiB | 894 KiB/s
> Writing objects:   7% (7213/101021), 2.32 MiB | 894 KiB/s
> Writing objects:   8% (8082/101021), 3.08 MiB | 981 KiB/s
> Writing objects:   9% (9092/101021), 3.08 MiB | 981 KiB/s
> Writing objects:   9% (9555/101021), 3.46 MiB | 906 KiB/s
> Writing objects:  10% (10103/101021), 3.46 MiB | 906 KiB/s
> Writing objects:  10% (11008/101021), 3.84 MiB | 869 KiB/s
> Writing objects:  11% (11113/101021), 3.84 MiB | 869 KiB/s
> Writing objects:  12% (12123/101021), 4.21 MiB | 810 KiB/s
> Writing objects:  12% (12724/101021), 4.58 MiB | 784 KiB/s
> Writing objects:  13% (13133/101021), 4.58 MiB | 784 KiB/s
> Writing objects:  14% (14144/101021), 4.96 MiB | 500 KiB/s
> Writing objects:  14% (14256/101021), 5.21 MiB | 541 KiB/s
> Writing objects:  14% (14782/101021), 5.46 MiB | 558 KiB/s
> Writing objects:  15% (15155/101021), 5.46 MiB | 558 KiB/s
> Writing objects:  15% (15476/101021), 5.71 MiB | 558 KiB/s
> Writing objects:  15% (15903/101021), 5.96 MiB | 458 KiB/s
> Writing objects:  16% (16164/101021), 6.21 MiB | 441 KiB/s
> Writing objects:  16% (16865/101021), 6.58 MiB | 439 KiB/s
> Writing objects:  17% (17174/101021), 6.58 MiB | 439 KiB/s
> Writing objects:  17% (17838/101021), 6.96 MiB | 454 KiB/s
> Writing objects:  18% (18185/101021), 7.33 MiB | 451 KiB/s
> Writing objects:  18% (18916/101021), 7.71 MiB | 452 KiB/s
> Writing objects:  19% (19194/101021), 7.71 MiB | 452 KiB/s
> Writing objects:  20% (20205/101021), 8.08 MiB | 475 KiB/s
> Writing objects:  20% (20221/101021), 8.46 MiB | 511 KiB/s
> Writing objects:  20% (20991/101021), 8.83 MiB | 544 KiB/s
> Writing objects:  21% (21217/101021), 8.83 MiB | 544 KiB/s
> Writing objects:  21% (22219/101021), 9.46 MiB | 594 KiB/s
> Writing objects:  22% (22225/101021), 9.46 MiB | 594 KiB/s
> Writing objects:  23% (23235/101021), 9.83 MiB | 595 KiB/s
> Writing objects:  23% (23246/101021), 10.21 MiB | 589 KiB/s
> Writing objects:  24% (24248/101021), 10.58 MiB | 592 KiB/s
> Writing objects:  24% (24304/101021), 10.58 MiB | 592 KiB/s
> Writing objects:  25% (25256/101021), 10.96 MiB | 593 KiB/s
> Writing objects:  25% (25743/101021), 11.33 MiB | 594 KiB/s
> Writing objects:  26% (26266/101021), 11.33 MiB | 594 KiB/s
> Writing objects:  27% (27276/101021), 11.71 MiB | 595 KiB/s
> Writing objects:  27% (27624/101021), 11.96 MiB | 583 KiB/s
> Writing objects:  28% (28287/101021), 11.96 MiB | 583 KiB/s
> Writing objects:  28% (28747/101021), 12.33 MiB | 592 KiB/s
> Writing objects:  29% (29297/101021), 12.33 MiB | 592 KiB/s
> Writing objects:  30% (30307/101021), 12.71 MiB | 590 KiB/s
> Writing objects:  31% (31317/101021), 12.71 MiB | 590 KiB/s
> Writing objects:  31% (31543/101021), 12.96 MiB | 578 KiB/s
> Writing objects:  32% (32327/101021), 12.96 MiB | 578 KiB/s
> Writing objects:  33% (33337/101021), 12.96 MiB | 578 KiB/s
> Writing objects:  34% (34348/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  35% (35358/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  35% (35825/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  36% (36369/101021), 13.33 MiB | 578 KiB/s
> Writing objects:  37% (37378/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  38% (38388/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  39% (39399/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  40% (40409/101021), 13.71 MiB | 580 KiB/s
> Writing objects:  41% (41420/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  41% (41488/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  42% (42429/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  43% (43440/101021), 14.08 MiB | 580 KiB/s
> Writing objects:  44% (44450/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  45% (45460/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  45% (45852/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  46% (46470/101021), 14.46 MiB | 580 KiB/s
> Writing objects:  47% (47480/101021), 14.83 MiB | 574 KiB/s
> Writing objects:  48% (48492/101021), 14.83 MiB | 574 KiB/s
> Writing objects:  49% (49501/101021), 14.83 MiB | 574 KiB/s
> Writing objects:  50% (50511/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  50% (50758/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  51% (51521/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  52% (52531/101021), 15.21 MiB | 587 KiB/s
> Writing objects:  53% (53542/101021), 15.58 MiB | 583 KiB/s
> Writing objects:  54% (54552/101021), 15.58 MiB | 583 KiB/s
> Writing objects:  55% (55562/101021), 15.58 MiB | 583 KiB/s
> Writing objects:  55% (56373/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  56% (56572/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  57% (57582/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  58% (58594/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  59% (59603/101021), 15.96 MiB | 587 KiB/s
> Writing objects:  60% (60613/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  60% (61041/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  61% (61623/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  62% (62634/101021), 16.33 MiB | 593 KiB/s
> Writing objects:  63% (63644/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  64% (64654/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  65% (65664/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  66% (66674/101021), 16.71 MiB | 597 KiB/s
> Writing objects:  66% (66990/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  67% (67685/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  68% (68695/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  69% (69705/101021), 17.08 MiB | 601 KiB/s
> Writing objects:  70% (70715/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  71% (71726/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  72% (72736/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  72% (73271/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  73% (73746/101021), 17.46 MiB | 596 KiB/s
> Writing objects:  74% (74756/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  75% (75766/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  76% (76776/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  77% (77787/101021), 17.83 MiB | 596 KiB/s
> Writing objects:  77% (78471/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  78% (78799/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  79% (79808/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  80% (80817/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  81% (81828/101021), 18.21 MiB | 598 KiB/s
> Writing objects:  82% (82838/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  83% (83848/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  83% (84657/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  84% (84858/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  85% (85868/101021), 18.58 MiB | 597 KiB/s
> Writing objects:  86% (86879/101021), 18.96 MiB | 603 KiB/s
> Writing objects:  87% (87890/101021), 18.96 MiB | 603 KiB/s
> Writing objects:  88% (88899/101021), 18.96 MiB | 603 KiB/s
> Writing objects:  89% (89909/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  89% (90835/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  90% (90919/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  91% (91930/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  92% (92940/101021), 19.33 MiB | 598 KiB/s
> Writing objects:  93% (93950/101021), 19.71 MiB | 603 KiB/s
> Writing objects:  94% (94960/101021), 19.71 MiB | 603 KiB/s
> Writing objects:  95% (95971/101021), 19.71 MiB | 603 KiB/s
> Writing objects:  95% (96582/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  96% (96981/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  97% (97991/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  98% (99001/101021), 20.08 MiB | 596 KiB/s
> Writing objects:  99% (100011/101021), 20.08 MiB | 596 KiB/s
> Writing objects: 100% (101021/101021), 20.46 MiB | 593 KiB/s
> Writing objects: 100% (101021/101021), 20.51 MiB | 597 KiB/s, done.
> Total 101021 (delta 84244), reused 96025 (delta 79512)
> To xen@xenbits.xensource.com:git/linux-pvops.git
>    c16fa4f..e63089b  e63089b08140adea85d011da136c7b56d73296ee -> tested/linux-mingo-tip-master
> + exit 0
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:56:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHztz-0008W5-Bu; Wed, 11 Apr 2012 15:56:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHztx-0008Vr-3I
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:56:09 +0000
Received: from [85.158.143.35:35374] by server-2.bemta-4.messagelabs.com id
	0C/C5-17550-899A58F4; Wed, 11 Apr 2012 15:56:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334159766!4391370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3870 invoked from network); 11 Apr 2012 15:56:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:55:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHztk-0004IG-Od; Wed, 11 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHztk-0004hf-Nk;
	Wed, 11 Apr 2012 16:55:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.43404.718457.235113@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 16:55:56 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334159286.16387.28.camel@zakaz.uk.xensource.com>
References: <osstest-12632-mainreport@xen.org>
	<1334159286.16387.28.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL
 - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL - PUSHED"):
> At least some of these xen-boot failures (I looked at
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/test-amd64-amd64-xl-win7-amd64/serial-itch-mite.log) have missing firmware:
> 
> Apr 10 13:57:11.884530 [   28.946844] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1b.fw"

Thanks for looking into this.

> That'll be because the new kernel needs something newer than what is
> provided by Squeeze's linux-firmware* packages. I usually set
> CONFIG_FIRMWARE_IN_KERNEL to avoid this (mostly, sometimes they forget
> to even include the firmware update, which happened once recently with
> bnx2 IIRC, so watch out for that):

Hrmf.  At least I guess that'll be a real regression upstream if that
happens.  I have submitted a change to set CONFIG_FIRMWARE_IN_KERNEL.

> The other option, as noted below, is to run "make firmware_install".

That's less appealing because of the need to mess around more with
initrds and build scripts.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:56:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHztz-0008W5-Bu; Wed, 11 Apr 2012 15:56:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SHztx-0008Vr-3I
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:56:09 +0000
Received: from [85.158.143.35:35374] by server-2.bemta-4.messagelabs.com id
	0C/C5-17550-899A58F4; Wed, 11 Apr 2012 15:56:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334159766!4391370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3870 invoked from network); 11 Apr 2012 15:56:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:55:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SHztk-0004IG-Od; Wed, 11 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SHztk-0004hf-Nk;
	Wed, 11 Apr 2012 16:55:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.43404.718457.235113@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 16:55:56 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334159286.16387.28.camel@zakaz.uk.xensource.com>
References: <osstest-12632-mainreport@xen.org>
	<1334159286.16387.28.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL
 - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [linux-mingo-tip-master test] 12632: tolerable FAIL - PUSHED"):
> At least some of these xen-boot failures (I looked at
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12632/test-amd64-amd64-xl-win7-amd64/serial-itch-mite.log) have missing firmware:
> 
> Apr 10 13:57:11.884530 [   28.946844] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1b.fw"

Thanks for looking into this.

> That'll be because the new kernel needs something newer than what is
> provided by Squeeze's linux-firmware* packages. I usually set
> CONFIG_FIRMWARE_IN_KERNEL to avoid this (mostly, sometimes they forget
> to even include the firmware update, which happened once recently with
> bnx2 IIRC, so watch out for that):

Hrmf.  At least I guess that'll be a real regression upstream if that
happens.  I have submitted a change to set CONFIG_FIRMWARE_IN_KERNEL.

> The other option, as noted below, is to run "make firmware_install".

That's less appealing because of the need to mess around more with
initrds and build scripts.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:59:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzx0-0000Ig-Qj; Wed, 11 Apr 2012 15:59:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzwz-0000IV-FG
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:59:17 +0000
Received: from [85.158.139.83:17246] by server-12.bemta-5.messagelabs.com id
	0F/4E-05587-45AA58F4; Wed, 11 Apr 2012 15:59:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334159955!23375495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17133 invoked from network); 11 Apr 2012 15:59:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:59:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:59:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:59:15 +0100
Date: Wed, 11 Apr 2012 17:02:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
In-Reply-To: <1333618505.2513.8.camel@leeds.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111700450.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [PATCH 2/2] Xen: Add xen-apic support and hook it
	up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan, Anthony, any opinions on this patch?
If it is OK for you, I am going to include it in the next Xen pull request.


On Thu, 5 Apr 2012, Wei Liu (Intern) wrote:
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  Makefile.target |    2 +-
>  hw/pc.c         |    8 +++++
>  hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 99 insertions(+), 1 deletions(-)
>  create mode 100644 hw/xen_apic.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index cff15f0..6210bae 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -235,7 +235,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
>  obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
>  obj-$(CONFIG_NO_XEN) += xen-stub.o
>  
> -obj-i386-$(CONFIG_XEN) += xen_platform.o
> +obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/pc.c b/hw/pc.c
> index 83a1b5b..5585cac 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -42,6 +42,7 @@
>  #include "sysbus.h"
>  #include "sysemu.h"
>  #include "kvm.h"
> +#include "xen.h"
>  #include "blockdev.h"
>  #include "ui/qemu-spice.h"
>  #include "memory.h"
> @@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>  
>      if (kvm_irqchip_in_kernel()) {
>          dev = qdev_create(NULL, "kvm-apic");
> +    } else if (xen_enabled()) {
> +        dev = qdev_create(NULL, "xen-apic");
>      } else {
>          dev = qdev_create(NULL, "apic");
>      }
> +
>      qdev_prop_set_uint8(dev, "id", apic_id);
>      qdev_prop_set_ptr(dev, "cpu_env", env);
>      qdev_init_nofail(dev);
> @@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>          msi_supported = true;
>      }
>  
> +    if (xen_enabled()) {
> +        msi_supported = true;
> +    }
> +
>      return dev;
>  }
>  
> diff --git a/hw/xen_apic.c b/hw/xen_apic.c
> new file mode 100644
> index 0000000..b1060b7
> --- /dev/null
> +++ b/hw/xen_apic.c
> @@ -0,0 +1,90 @@
> +/*
> + * Xen basic APIC support
> + *
> + * Copyright (c) 2012 Citrix
> + *
> + * Authors:
> + *  Wei Liu <wei.liu2@citrix.com>
> + *
> + * This work is licensed under the terms of the GNU GPL version 2.
> + * See the COPYING file in the top-level directory.
> + */
> +#include "hw/apic_internal.h"
> +#include "hw/msi.h"
> +#include "xen.h"
> +
> +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
> +                                  unsigned size)
> +{
> +    return -1U;
> +}
> +
> +static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
> +                               uint64_t data, unsigned size)
> +{
> +    if (size != sizeof(uint32_t)) {
> +        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
> +        return;
> +    }
> +
> +    xen_hvm_inject_msi(addr, data);
> +}
> +
> +static const MemoryRegionOps xen_apic_io_ops = {
> +    .read = xen_apic_mem_read,
> +    .write = xen_apic_mem_write,
> +    .endianness = DEVICE_NATIVE_ENDIAN,
> +};
> +
> +static void xen_apic_init(APICCommonState *s)
> +{
> +    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
> +                          MSI_SPACE_SIZE);
> +}
> +
> +static void xen_apic_set_base(APICCommonState *s, uint64_t val)
> +{
> +}
> +
> +static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
> +{
> +}
> +
> +static uint8_t xen_apic_get_tpr(APICCommonState *s)
> +{
> +    return 0;
> +}
> +
> +static void xen_apic_vapic_base_update(APICCommonState *s)
> +{
> +}
> +
> +static void xen_apic_external_nmi(APICCommonState *s)
> +{
> +}
> +
> +static void xen_apic_class_init(ObjectClass *klass, void *data)
> +{
> +    APICCommonClass *k = APIC_COMMON_CLASS(klass);
> +
> +    k->init = xen_apic_init;
> +    k->set_base = xen_apic_set_base;
> +    k->set_tpr = xen_apic_set_tpr;
> +    k->get_tpr = xen_apic_get_tpr;
> +    k->vapic_base_update = xen_apic_vapic_base_update;
> +    k->external_nmi = xen_apic_external_nmi;
> +}
> +
> +static TypeInfo xen_apic_info = {
> +    .name = "xen-apic",
> +    .parent = TYPE_APIC_COMMON,
> +    .instance_size = sizeof(APICCommonState),
> +    .class_init = xen_apic_class_init,
> +};
> +
> +static void xen_apic_register_types(void)
> +{
> +    type_register_static(&xen_apic_info);
> +}
> +
> +type_init(xen_apic_register_types)
> -- 
> 1.7.2.5
> 
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 15:59:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 15:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzx0-0000Ig-Qj; Wed, 11 Apr 2012 15:59:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SHzwz-0000IV-FG
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 15:59:17 +0000
Received: from [85.158.139.83:17246] by server-12.bemta-5.messagelabs.com id
	0F/4E-05587-45AA58F4; Wed, 11 Apr 2012 15:59:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334159955!23375495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17133 invoked from network); 11 Apr 2012 15:59:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 15:59:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 15:59:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 16:59:15 +0100
Date: Wed, 11 Apr 2012 17:02:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
In-Reply-To: <1333618505.2513.8.camel@leeds.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111700450.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [PATCH 2/2] Xen: Add xen-apic support and hook it
	up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan, Anthony, any opinions on this patch?
If it is OK for you, I am going to include it in the next Xen pull request.


On Thu, 5 Apr 2012, Wei Liu (Intern) wrote:
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  Makefile.target |    2 +-
>  hw/pc.c         |    8 +++++
>  hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 99 insertions(+), 1 deletions(-)
>  create mode 100644 hw/xen_apic.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index cff15f0..6210bae 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -235,7 +235,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
>  obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
>  obj-$(CONFIG_NO_XEN) += xen-stub.o
>  
> -obj-i386-$(CONFIG_XEN) += xen_platform.o
> +obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/pc.c b/hw/pc.c
> index 83a1b5b..5585cac 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -42,6 +42,7 @@
>  #include "sysbus.h"
>  #include "sysemu.h"
>  #include "kvm.h"
> +#include "xen.h"
>  #include "blockdev.h"
>  #include "ui/qemu-spice.h"
>  #include "memory.h"
> @@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>  
>      if (kvm_irqchip_in_kernel()) {
>          dev = qdev_create(NULL, "kvm-apic");
> +    } else if (xen_enabled()) {
> +        dev = qdev_create(NULL, "xen-apic");
>      } else {
>          dev = qdev_create(NULL, "apic");
>      }
> +
>      qdev_prop_set_uint8(dev, "id", apic_id);
>      qdev_prop_set_ptr(dev, "cpu_env", env);
>      qdev_init_nofail(dev);
> @@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>          msi_supported = true;
>      }
>  
> +    if (xen_enabled()) {
> +        msi_supported = true;
> +    }
> +
>      return dev;
>  }
>  
> diff --git a/hw/xen_apic.c b/hw/xen_apic.c
> new file mode 100644
> index 0000000..b1060b7
> --- /dev/null
> +++ b/hw/xen_apic.c
> @@ -0,0 +1,90 @@
> +/*
> + * Xen basic APIC support
> + *
> + * Copyright (c) 2012 Citrix
> + *
> + * Authors:
> + *  Wei Liu <wei.liu2@citrix.com>
> + *
> + * This work is licensed under the terms of the GNU GPL version 2.
> + * See the COPYING file in the top-level directory.
> + */
> +#include "hw/apic_internal.h"
> +#include "hw/msi.h"
> +#include "xen.h"
> +
> +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
> +                                  unsigned size)
> +{
> +    return -1U;
> +}
> +
> +static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
> +                               uint64_t data, unsigned size)
> +{
> +    if (size != sizeof(uint32_t)) {
> +        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
> +        return;
> +    }
> +
> +    xen_hvm_inject_msi(addr, data);
> +}
> +
> +static const MemoryRegionOps xen_apic_io_ops = {
> +    .read = xen_apic_mem_read,
> +    .write = xen_apic_mem_write,
> +    .endianness = DEVICE_NATIVE_ENDIAN,
> +};
> +
> +static void xen_apic_init(APICCommonState *s)
> +{
> +    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
> +                          MSI_SPACE_SIZE);
> +}
> +
> +static void xen_apic_set_base(APICCommonState *s, uint64_t val)
> +{
> +}
> +
> +static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
> +{
> +}
> +
> +static uint8_t xen_apic_get_tpr(APICCommonState *s)
> +{
> +    return 0;
> +}
> +
> +static void xen_apic_vapic_base_update(APICCommonState *s)
> +{
> +}
> +
> +static void xen_apic_external_nmi(APICCommonState *s)
> +{
> +}
> +
> +static void xen_apic_class_init(ObjectClass *klass, void *data)
> +{
> +    APICCommonClass *k = APIC_COMMON_CLASS(klass);
> +
> +    k->init = xen_apic_init;
> +    k->set_base = xen_apic_set_base;
> +    k->set_tpr = xen_apic_set_tpr;
> +    k->get_tpr = xen_apic_get_tpr;
> +    k->vapic_base_update = xen_apic_vapic_base_update;
> +    k->external_nmi = xen_apic_external_nmi;
> +}
> +
> +static TypeInfo xen_apic_info = {
> +    .name = "xen-apic",
> +    .parent = TYPE_APIC_COMMON,
> +    .instance_size = sizeof(APICCommonState),
> +    .class_init = xen_apic_class_init,
> +};
> +
> +static void xen_apic_register_types(void)
> +{
> +    type_register_static(&xen_apic_info);
> +}
> +
> +type_init(xen_apic_register_types)
> -- 
> 1.7.2.5
> 
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzzZ-0000yi-2G; Wed, 11 Apr 2012 16:01:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SHzzX-0000yU-P3
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:01:55 +0000
Received: from [85.158.143.99:6044] by server-1.bemta-4.messagelabs.com id
	5D/61-20925-3FAA58F4; Wed, 11 Apr 2012 16:01:55 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334160114!13454985!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDM3MDY0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29642 invoked from network); 11 Apr 2012 16:01:54 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Apr 2012 16:01:54 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q3BG1krI028132;
	Wed, 11 Apr 2012 18:01:47 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q3BG1kWL025522;
	Wed, 11 Apr 2012 18:01:46 +0200
Message-ID: <4F85AAEA.5000301@siemens.com>
Date: Wed, 11 Apr 2012 18:01:46 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<alpine.DEB.2.00.1204111700450.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204111700450.15151@kaball-desktop>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [PATCH 2/2] Xen: Add xen-apic support and hook it
	up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-04-11 18:02, Stefano Stabellini wrote:
> Jan, Anthony, any opinions on this patch?
> If it is OK for you, I am going to include it in the next Xen pull request.
> 

Looks good to me.

Jan

> 
> On Thu, 5 Apr 2012, Wei Liu (Intern) wrote:
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> ---
>>  Makefile.target |    2 +-
>>  hw/pc.c         |    8 +++++
>>  hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 99 insertions(+), 1 deletions(-)
>>  create mode 100644 hw/xen_apic.c
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index cff15f0..6210bae 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -235,7 +235,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
>>  obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
>>  obj-$(CONFIG_NO_XEN) += xen-stub.o
>>  
>> -obj-i386-$(CONFIG_XEN) += xen_platform.o
>> +obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
>>  
>>  # Inter-VM PCI shared memory
>>  CONFIG_IVSHMEM =
>> diff --git a/hw/pc.c b/hw/pc.c
>> index 83a1b5b..5585cac 100644
>> --- a/hw/pc.c
>> +++ b/hw/pc.c
>> @@ -42,6 +42,7 @@
>>  #include "sysbus.h"
>>  #include "sysemu.h"
>>  #include "kvm.h"
>> +#include "xen.h"
>>  #include "blockdev.h"
>>  #include "ui/qemu-spice.h"
>>  #include "memory.h"
>> @@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>>  
>>      if (kvm_irqchip_in_kernel()) {
>>          dev = qdev_create(NULL, "kvm-apic");
>> +    } else if (xen_enabled()) {
>> +        dev = qdev_create(NULL, "xen-apic");
>>      } else {
>>          dev = qdev_create(NULL, "apic");
>>      }
>> +
>>      qdev_prop_set_uint8(dev, "id", apic_id);
>>      qdev_prop_set_ptr(dev, "cpu_env", env);
>>      qdev_init_nofail(dev);
>> @@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>>          msi_supported = true;
>>      }
>>  
>> +    if (xen_enabled()) {
>> +        msi_supported = true;
>> +    }
>> +
>>      return dev;
>>  }
>>  
>> diff --git a/hw/xen_apic.c b/hw/xen_apic.c
>> new file mode 100644
>> index 0000000..b1060b7
>> --- /dev/null
>> +++ b/hw/xen_apic.c
>> @@ -0,0 +1,90 @@
>> +/*
>> + * Xen basic APIC support
>> + *
>> + * Copyright (c) 2012 Citrix
>> + *
>> + * Authors:
>> + *  Wei Liu <wei.liu2@citrix.com>
>> + *
>> + * This work is licensed under the terms of the GNU GPL version 2.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +#include "hw/apic_internal.h"
>> +#include "hw/msi.h"
>> +#include "xen.h"
>> +
>> +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
>> +                                  unsigned size)
>> +{
>> +    return -1U;
>> +}
>> +
>> +static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
>> +                               uint64_t data, unsigned size)
>> +{
>> +    if (size != sizeof(uint32_t)) {
>> +        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
>> +        return;
>> +    }
>> +
>> +    xen_hvm_inject_msi(addr, data);
>> +}
>> +
>> +static const MemoryRegionOps xen_apic_io_ops = {
>> +    .read = xen_apic_mem_read,
>> +    .write = xen_apic_mem_write,
>> +    .endianness = DEVICE_NATIVE_ENDIAN,
>> +};
>> +
>> +static void xen_apic_init(APICCommonState *s)
>> +{
>> +    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
>> +                          MSI_SPACE_SIZE);
>> +}
>> +
>> +static void xen_apic_set_base(APICCommonState *s, uint64_t val)
>> +{
>> +}
>> +
>> +static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
>> +{
>> +}
>> +
>> +static uint8_t xen_apic_get_tpr(APICCommonState *s)
>> +{
>> +    return 0;
>> +}
>> +
>> +static void xen_apic_vapic_base_update(APICCommonState *s)
>> +{
>> +}
>> +
>> +static void xen_apic_external_nmi(APICCommonState *s)
>> +{
>> +}
>> +
>> +static void xen_apic_class_init(ObjectClass *klass, void *data)
>> +{
>> +    APICCommonClass *k = APIC_COMMON_CLASS(klass);
>> +
>> +    k->init = xen_apic_init;
>> +    k->set_base = xen_apic_set_base;
>> +    k->set_tpr = xen_apic_set_tpr;
>> +    k->get_tpr = xen_apic_get_tpr;
>> +    k->vapic_base_update = xen_apic_vapic_base_update;
>> +    k->external_nmi = xen_apic_external_nmi;
>> +}
>> +
>> +static TypeInfo xen_apic_info = {
>> +    .name = "xen-apic",
>> +    .parent = TYPE_APIC_COMMON,
>> +    .instance_size = sizeof(APICCommonState),
>> +    .class_init = xen_apic_class_init,
>> +};
>> +
>> +static void xen_apic_register_types(void)
>> +{
>> +    type_register_static(&xen_apic_info);
>> +}
>> +
>> +type_init(xen_apic_register_types)
>> -- 
>> 1.7.2.5
>>
>>
>>
>>
>>

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SHzzZ-0000yi-2G; Wed, 11 Apr 2012 16:01:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SHzzX-0000yU-P3
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:01:55 +0000
Received: from [85.158.143.99:6044] by server-1.bemta-4.messagelabs.com id
	5D/61-20925-3FAA58F4; Wed, 11 Apr 2012 16:01:55 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334160114!13454985!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDM3MDY0Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29642 invoked from network); 11 Apr 2012 16:01:54 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Apr 2012 16:01:54 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q3BG1krI028132;
	Wed, 11 Apr 2012 18:01:47 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q3BG1kWL025522;
	Wed, 11 Apr 2012 18:01:46 +0200
Message-ID: <4F85AAEA.5000301@siemens.com>
Date: Wed, 11 Apr 2012 18:01:46 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<alpine.DEB.2.00.1204111700450.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204111700450.15151@kaball-desktop>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [PATCH 2/2] Xen: Add xen-apic support and hook it
	up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-04-11 18:02, Stefano Stabellini wrote:
> Jan, Anthony, any opinions on this patch?
> If it is OK for you, I am going to include it in the next Xen pull request.
> 

Looks good to me.

Jan

> 
> On Thu, 5 Apr 2012, Wei Liu (Intern) wrote:
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> ---
>>  Makefile.target |    2 +-
>>  hw/pc.c         |    8 +++++
>>  hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 99 insertions(+), 1 deletions(-)
>>  create mode 100644 hw/xen_apic.c
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index cff15f0..6210bae 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -235,7 +235,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
>>  obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
>>  obj-$(CONFIG_NO_XEN) += xen-stub.o
>>  
>> -obj-i386-$(CONFIG_XEN) += xen_platform.o
>> +obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
>>  
>>  # Inter-VM PCI shared memory
>>  CONFIG_IVSHMEM =
>> diff --git a/hw/pc.c b/hw/pc.c
>> index 83a1b5b..5585cac 100644
>> --- a/hw/pc.c
>> +++ b/hw/pc.c
>> @@ -42,6 +42,7 @@
>>  #include "sysbus.h"
>>  #include "sysemu.h"
>>  #include "kvm.h"
>> +#include "xen.h"
>>  #include "blockdev.h"
>>  #include "ui/qemu-spice.h"
>>  #include "memory.h"
>> @@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>>  
>>      if (kvm_irqchip_in_kernel()) {
>>          dev = qdev_create(NULL, "kvm-apic");
>> +    } else if (xen_enabled()) {
>> +        dev = qdev_create(NULL, "xen-apic");
>>      } else {
>>          dev = qdev_create(NULL, "apic");
>>      }
>> +
>>      qdev_prop_set_uint8(dev, "id", apic_id);
>>      qdev_prop_set_ptr(dev, "cpu_env", env);
>>      qdev_init_nofail(dev);
>> @@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>>          msi_supported = true;
>>      }
>>  
>> +    if (xen_enabled()) {
>> +        msi_supported = true;
>> +    }
>> +
>>      return dev;
>>  }
>>  
>> diff --git a/hw/xen_apic.c b/hw/xen_apic.c
>> new file mode 100644
>> index 0000000..b1060b7
>> --- /dev/null
>> +++ b/hw/xen_apic.c
>> @@ -0,0 +1,90 @@
>> +/*
>> + * Xen basic APIC support
>> + *
>> + * Copyright (c) 2012 Citrix
>> + *
>> + * Authors:
>> + *  Wei Liu <wei.liu2@citrix.com>
>> + *
>> + * This work is licensed under the terms of the GNU GPL version 2.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +#include "hw/apic_internal.h"
>> +#include "hw/msi.h"
>> +#include "xen.h"
>> +
>> +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
>> +                                  unsigned size)
>> +{
>> +    return -1U;
>> +}
>> +
>> +static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
>> +                               uint64_t data, unsigned size)
>> +{
>> +    if (size != sizeof(uint32_t)) {
>> +        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
>> +        return;
>> +    }
>> +
>> +    xen_hvm_inject_msi(addr, data);
>> +}
>> +
>> +static const MemoryRegionOps xen_apic_io_ops = {
>> +    .read = xen_apic_mem_read,
>> +    .write = xen_apic_mem_write,
>> +    .endianness = DEVICE_NATIVE_ENDIAN,
>> +};
>> +
>> +static void xen_apic_init(APICCommonState *s)
>> +{
>> +    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
>> +                          MSI_SPACE_SIZE);
>> +}
>> +
>> +static void xen_apic_set_base(APICCommonState *s, uint64_t val)
>> +{
>> +}
>> +
>> +static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
>> +{
>> +}
>> +
>> +static uint8_t xen_apic_get_tpr(APICCommonState *s)
>> +{
>> +    return 0;
>> +}
>> +
>> +static void xen_apic_vapic_base_update(APICCommonState *s)
>> +{
>> +}
>> +
>> +static void xen_apic_external_nmi(APICCommonState *s)
>> +{
>> +}
>> +
>> +static void xen_apic_class_init(ObjectClass *klass, void *data)
>> +{
>> +    APICCommonClass *k = APIC_COMMON_CLASS(klass);
>> +
>> +    k->init = xen_apic_init;
>> +    k->set_base = xen_apic_set_base;
>> +    k->set_tpr = xen_apic_set_tpr;
>> +    k->get_tpr = xen_apic_get_tpr;
>> +    k->vapic_base_update = xen_apic_vapic_base_update;
>> +    k->external_nmi = xen_apic_external_nmi;
>> +}
>> +
>> +static TypeInfo xen_apic_info = {
>> +    .name = "xen-apic",
>> +    .parent = TYPE_APIC_COMMON,
>> +    .instance_size = sizeof(APICCommonState),
>> +    .class_init = xen_apic_class_init,
>> +};
>> +
>> +static void xen_apic_register_types(void)
>> +{
>> +    type_register_static(&xen_apic_info);
>> +}
>> +
>> +type_init(xen_apic_register_types)
>> -- 
>> 1.7.2.5
>>
>>
>>
>>
>>

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI05F-0001WP-Uu; Wed, 11 Apr 2012 16:07:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SI05E-0001WB-C7
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:07:48 +0000
Received: from [193.109.254.147:27173] by server-9.bemta-14.messagelabs.com id
	10/E2-05787-35CA58F4; Wed, 11 Apr 2012 16:07:47 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334160466!4153864!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26477 invoked from network); 11 Apr 2012 16:07:47 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:07:47 -0000
Received: by ghbz17 with SMTP id z17so642357ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 09:07:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=/4L9PYGCumaPnRA2wr95CSjZL67IBi5JV7y/Nnkfjx4=;
	b=dvUj7nOQiHbHAQ7Rr6p9RKyDrgiQasUb+4uvOBqd+N6RTuk50MhipR54Qo2j6iwocr
	8ciKa4DIgvG3dZbwdSneSkG6ZHcbwUKx3lLThUKQxT/z+8OrgMK3/H/ZvudYH7Z+QLWj
	dfdAm80ej/HI++tLOstpRR/ELavDA/hyhj9r/xJobB93x9F4GolG/xknb5Yr9lwW1VmS
	0tBGcn8oKOrcwI+zWHznMymF0aRrwg+CTCVjR6az2zUUPPs13vFDH/XlcDSzBzQjl+6I
	lvUZnbGrRHnKy7o1KQGINPH+t12OYPFM+L+ZP/K8A3fXSw8w63904dT4cQbLfiwncBNi
	6+JQ==
MIME-Version: 1.0
Received: by 10.50.212.101 with SMTP id nj5mr6339944igc.41.1334160459324; Wed,
	11 Apr 2012 09:07:39 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 11 Apr 2012 09:07:39 -0700 (PDT)
In-Reply-To: <1333618505.2513.8.camel@leeds.uk.xensource.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
Date: Wed, 11 Apr 2012 17:07:39 +0100
Message-ID: <CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Wei Liu <wei.liu2@citrix.com>
X-Gm-Message-State: ALoCoQneHNtrawDqdQlfFkWAwGUZapHWFnF7IOVQg06k7Wl8Q9Xx8tqHhOgqr1WJ5pDq2OxqOY8q
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
	and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gNSBBcHJpbCAyMDEyIDEwOjM1LCBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPiB3cm90
ZToKPgo+IC0tLSAvZGV2L251bGwKPiArKysgYi9ody94ZW5fYXBpYy5jCj4gQEAgLTAsMCArMSw5
MCBAQAo+ICsvKgo+ICsgKiBYZW4gYmFzaWMgQVBJQyBzdXBwb3J0Cj4gKyAqCj4gKyAqIENvcHly
aWdodCAoYykgMjAxMiBDaXRyaXgKPiArICoKPiArICogQXV0aG9yczoKPiArICogwqBXZWkgTGl1
IDx3ZWkubGl1MkBjaXRyaXguY29tPgo+ICsgKgo+ICsgKiBUaGlzIHdvcmsgaXMgbGljZW5zZWQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR1BMIHZlcnNpb24gMi4KPiArICogU2VlIHRoZSBD
T1BZSU5HIGZpbGUgaW4gdGhlIHRvcC1sZXZlbCBkaXJlY3RvcnkuCj4gKyAqLwoKUmVhbGx5IDIt
b25seSwgbm90IDItb3ItbGF0ZXIgPwoKPiArI2luY2x1ZGUgImh3L2FwaWNfaW50ZXJuYWwuaCIK
PiArI2luY2x1ZGUgImh3L21zaS5oIgo+ICsjaW5jbHVkZSAieGVuLmgiCj4gKwo+ICtzdGF0aWMg
dWludDY0X3QgeGVuX2FwaWNfbWVtX3JlYWQodm9pZCAqb3BhcXVlLCB0YXJnZXRfcGh5c19hZGRy
X3QgYWRkciwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgdW5zaWduZWQgc2l6ZSkKPiArewo+ICsgwqAgwqByZXR1cm4gLTFVOwo+ICt9CgpUaGlz
IHNlZW1zIGEgcmF0aGVyIGNvbmZ1c2luZyB3YXkgdG8gd3JpdGUgJ3JldHVybiAweGZmZmZmZmZm
OycKCi0tIFBNTQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI05F-0001WP-Uu; Wed, 11 Apr 2012 16:07:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SI05E-0001WB-C7
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:07:48 +0000
Received: from [193.109.254.147:27173] by server-9.bemta-14.messagelabs.com id
	10/E2-05787-35CA58F4; Wed, 11 Apr 2012 16:07:47 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334160466!4153864!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26477 invoked from network); 11 Apr 2012 16:07:47 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:07:47 -0000
Received: by ghbz17 with SMTP id z17so642357ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 09:07:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=/4L9PYGCumaPnRA2wr95CSjZL67IBi5JV7y/Nnkfjx4=;
	b=dvUj7nOQiHbHAQ7Rr6p9RKyDrgiQasUb+4uvOBqd+N6RTuk50MhipR54Qo2j6iwocr
	8ciKa4DIgvG3dZbwdSneSkG6ZHcbwUKx3lLThUKQxT/z+8OrgMK3/H/ZvudYH7Z+QLWj
	dfdAm80ej/HI++tLOstpRR/ELavDA/hyhj9r/xJobB93x9F4GolG/xknb5Yr9lwW1VmS
	0tBGcn8oKOrcwI+zWHznMymF0aRrwg+CTCVjR6az2zUUPPs13vFDH/XlcDSzBzQjl+6I
	lvUZnbGrRHnKy7o1KQGINPH+t12OYPFM+L+ZP/K8A3fXSw8w63904dT4cQbLfiwncBNi
	6+JQ==
MIME-Version: 1.0
Received: by 10.50.212.101 with SMTP id nj5mr6339944igc.41.1334160459324; Wed,
	11 Apr 2012 09:07:39 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 11 Apr 2012 09:07:39 -0700 (PDT)
In-Reply-To: <1333618505.2513.8.camel@leeds.uk.xensource.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
Date: Wed, 11 Apr 2012 17:07:39 +0100
Message-ID: <CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Wei Liu <wei.liu2@citrix.com>
X-Gm-Message-State: ALoCoQneHNtrawDqdQlfFkWAwGUZapHWFnF7IOVQg06k7Wl8Q9Xx8tqHhOgqr1WJ5pDq2OxqOY8q
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
	and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gNSBBcHJpbCAyMDEyIDEwOjM1LCBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPiB3cm90
ZToKPgo+IC0tLSAvZGV2L251bGwKPiArKysgYi9ody94ZW5fYXBpYy5jCj4gQEAgLTAsMCArMSw5
MCBAQAo+ICsvKgo+ICsgKiBYZW4gYmFzaWMgQVBJQyBzdXBwb3J0Cj4gKyAqCj4gKyAqIENvcHly
aWdodCAoYykgMjAxMiBDaXRyaXgKPiArICoKPiArICogQXV0aG9yczoKPiArICogwqBXZWkgTGl1
IDx3ZWkubGl1MkBjaXRyaXguY29tPgo+ICsgKgo+ICsgKiBUaGlzIHdvcmsgaXMgbGljZW5zZWQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR1BMIHZlcnNpb24gMi4KPiArICogU2VlIHRoZSBD
T1BZSU5HIGZpbGUgaW4gdGhlIHRvcC1sZXZlbCBkaXJlY3RvcnkuCj4gKyAqLwoKUmVhbGx5IDIt
b25seSwgbm90IDItb3ItbGF0ZXIgPwoKPiArI2luY2x1ZGUgImh3L2FwaWNfaW50ZXJuYWwuaCIK
PiArI2luY2x1ZGUgImh3L21zaS5oIgo+ICsjaW5jbHVkZSAieGVuLmgiCj4gKwo+ICtzdGF0aWMg
dWludDY0X3QgeGVuX2FwaWNfbWVtX3JlYWQodm9pZCAqb3BhcXVlLCB0YXJnZXRfcGh5c19hZGRy
X3QgYWRkciwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgdW5zaWduZWQgc2l6ZSkKPiArewo+ICsgwqAgwqByZXR1cm4gLTFVOwo+ICt9CgpUaGlz
IHNlZW1zIGEgcmF0aGVyIGNvbmZ1c2luZyB3YXkgdG8gd3JpdGUgJ3JldHVybiAweGZmZmZmZmZm
OycKCi0tIFBNTQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI06L-0001bu-EI; Wed, 11 Apr 2012 16:08:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SI06K-0001bg-6s
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:08:56 +0000
Received: from [85.158.138.51:59324] by server-4.bemta-3.messagelabs.com id
	99/E3-15341-79CA58F4; Wed, 11 Apr 2012 16:08:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334160532!21686343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7743 invoked from network); 11 Apr 2012 16:08:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="24064843"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:08:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:08:51 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SI06E-0001er-Qp;
	Wed, 11 Apr 2012 17:08:50 +0100
Message-ID: <4F85AC6C.10407@eu.citrix.com>
Date: Wed, 11 Apr 2012 17:08:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<e63c137d9fc551ca941a.1334150268@Solace>
In-Reply-To: <e63c137d9fc551ca941a.1334150268@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize
 xenctl_cpumap to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> In preparation for adding an xc_nodemap_t and its related
> hadling logic. Just add one indirection layer, and try to
> retain the interface as much as possible (although some
> small bits here and there have been affected).
This patch is fine with me on the whole (one comment below), but in this 
kind of a patch I think you need to include exactly what it is patch 
does.  I.e.:

1. Replace xenctl_cpumap with xenctl_map
2. Implement bitmap_to_xenctl_map and the reverse
3. Re-implement cpumask_to_xenctl_map with bitmap_to_xenctl_map and vice 
versa.
4. Other than #3, no functional changes.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.eu.com>
>
> diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
> --- a/tools/libxc/xc_cpupool.c
> +++ b/tools/libxc/xc_cpupool.c
> @@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_
>       sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO;
>       sysctl.u.cpupool_op.cpupool_id = poolid;
>       set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8;
>
>       err = do_sysctl_save(xch,&sysctl);
>
> @@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter
>       sysctl.cmd = XEN_SYSCTL_cpupool_op;
>       sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO;
>       set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8;
>
>       err = do_sysctl_save(xch,&sysctl);
>
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc
>
>       set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
>
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>       ret = do_domctl(xch,&domctl);
>
> @@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc
>       domctl.u.vcpuaffinity.vcpu = vcpu;
>
>       set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>       ret = do_domctl(xch,&domctl);
>
> diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c
> --- a/tools/libxc/xc_tbuf.c
> +++ b/tools/libxc/xc_tbuf.c
> @@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x
>       bitmap_64_to_byte(bytemap,&mask64, sizeof (mask64) * 8);
>
>       set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap);
> -    sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8;
> +    sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8;
>
>       ret = do_sysctl(xch,&sysctl);
>
> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -365,7 +365,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>       {
>           uint32_t cpu;
>           uint64_t idletime, now = NOW();
> -        struct xenctl_cpumap ctlmap;
> +        struct xenctl_map ctlmap;
>           cpumask_var_t cpumap;
>           XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
>           XEN_GUEST_HANDLE(uint64) idletimes;
> @@ -378,7 +378,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>           if ( cpufreq_controller != FREQCTL_dom0_kernel )
>               break;
>
> -        ctlmap.nr_cpus  = op->u.getidletime.cpumap_nr_cpus;
> +        ctlmap.nr_elems  = op->u.getidletime.cpumap_nr_cpus;
>           guest_from_compat_handle(cpumap_bitmap,
>                                    op->u.getidletime.cpumap_bitmap);
>           ctlmap.bitmap.p = cpumap_bitmap.p; /* handle ->  handle_64 conversion */
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -31,28 +31,29 @@
>   static DEFINE_SPINLOCK(domctl_lock);
>   DEFINE_SPINLOCK(vcpu_alloc_lock);
>
> -int cpumask_to_xenctl_cpumap(
> -    struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> +int bitmap_to_xenctl_map(struct xenctl_map *xenctl_map,
> +                         const unsigned long *bitmap,
> +                         unsigned int nbits)
>   {
>       unsigned int guest_bytes, copy_bytes, i;
>       uint8_t zero = 0;
>       int err = 0;
> -    uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8);
>
>       if ( !bytemap )
>           return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
> -    bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids);
> +    bitmap_long_to_byte(bytemap, bitmap, nbits);
>
>       if ( copy_bytes != 0 )
> -        if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) )
> +        if ( copy_to_guest(xenctl_map->bitmap, bytemap, copy_bytes) )
>               err = -EFAULT;
>
>       for ( i = copy_bytes; !err&&  i<  guest_bytes; i++ )
> -        if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i,&zero, 1) )
> +        if ( copy_to_guest_offset(xenctl_map->bitmap, i,&zero, 1) )
>               err = -EFAULT;
>
>       xfree(bytemap);
> @@ -60,36 +61,58 @@ int cpumask_to_xenctl_cpumap(
>       return err;
>   }
>
> -int xenctl_cpumap_to_cpumask(
> -    cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap)
> +int xenctl_map_to_bitmap(unsigned long *bitmap,
> +                         const struct xenctl_map *xenctl_map,
> +                         unsigned int nbits)
>   {
>       unsigned int guest_bytes, copy_bytes;
>       int err = 0;
> -    uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8);
>
>       if ( !bytemap )
>           return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
>       if ( copy_bytes != 0 )
>       {
> -        if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) )
> +        if ( copy_from_guest(bytemap, xenctl_map->bitmap, copy_bytes) )
>               err = -EFAULT;
> -        if ( (xenctl_cpumap->nr_cpus&  7)&&  (guest_bytes<= sizeof(bytemap)) )
> -            bytemap[guest_bytes-1]&= ~(0xff<<  (xenctl_cpumap->nr_cpus&  7));
> +        if ( (xenctl_map->nr_elems&  7)&&  (guest_bytes<= sizeof(bytemap)) )
> +            bytemap[guest_bytes-1]&= ~(0xff<<  (xenctl_map->nr_elems&  7));
>       }
>
> -    if ( err )
> -        /* nothing */;
> -    else if ( alloc_cpumask_var(cpumask) )
> -        bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids);
> +    if ( !err )
> +        bitmap_byte_to_long(bitmap, bytemap, nbits);
> +
> +    xfree(bytemap);
> +
> +    return err;
> +}
> +
> +int cpumask_to_xenctl_cpumap(struct xenctl_map *xenctl_cpumap,
> +                             const cpumask_t *cpumask)
> +{
> +    return bitmap_to_xenctl_map(xenctl_cpumap, cpumask_bits(cpumask),
> +                                nr_cpu_ids);
> +}
> +
> +int xenctl_cpumap_to_cpumask(cpumask_var_t *cpumask,
> +                             const struct xenctl_map *xenctl_cpumap)
> +{
> +    int err = 0;
> +
> +    if ( alloc_cpumask_var(cpumask) ) {
> +        err = xenctl_map_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap,
> +                                   nr_cpu_ids);
> +        /* In case of error, cleanup is up to us, as the caller won't care! */
> +        if ( err )
> +            free_cpumask_var(*cpumask);
> +    }
>       else
>           err = -ENOMEM;
>
> -    xfree(bytemap);
> -
>       return err;
>   }
>
> diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
> --- a/xen/include/public/arch-x86/xen-mca.h
> +++ b/xen/include/public/arch-x86/xen-mca.h
> @@ -414,7 +414,7 @@ struct xen_mc_mceinject {
>
>   struct xen_mc_inject_v2 {
>   	uint32_t flags;
> -	struct xenctl_cpumap cpumap;
> +	struct xenctl_map cpumap;
>   };
>   #endif
>
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -283,7 +283,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc
>   /* XEN_DOMCTL_getvcpuaffinity */
>   struct xen_domctl_vcpuaffinity {
>       uint32_t  vcpu;              /* IN */
> -    struct xenctl_cpumap cpumap; /* IN/OUT */
> +    struct xenctl_map cpumap;    /* IN/OUT */
>   };
>   typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t);
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -71,8 +71,8 @@ struct xen_sysctl_tbuf_op {
>   #define XEN_SYSCTL_TBUFOP_disable      5
>       uint32_t cmd;
>       /* IN/OUT variables */
> -    struct xenctl_cpumap cpu_mask;
> -    uint32_t             evt_mask;
> +    struct xenctl_map cpu_mask;
> +    uint32_t          evt_mask;
>       /* OUT variables */
>       uint64_aligned_t buffer_mfn;
>       uint32_t size;  /* Also an IN variable! */
> @@ -531,7 +531,7 @@ struct xen_sysctl_cpupool_op {
>       uint32_t domid;       /* IN: M              */
>       uint32_t cpu;         /* IN: AR             */
>       uint32_t n_dom;       /*            OUT: I  */
> -    struct xenctl_cpumap cpumap; /*     OUT: IF */
> +    struct xenctl_map cpumap;    /*     OUT: IF */
>   };
>   typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -822,9 +822,9 @@ typedef uint8_t xen_domain_handle_t[16];
>   #endif
>
>   #ifndef __ASSEMBLY__
> -struct xenctl_cpumap {
> +struct xenctl_map {
>       XEN_GUEST_HANDLE_64(uint8) bitmap;
> -    uint32_t nr_cpus;
> +    uint32_t nr_elems;
>   };
>   #endif
>
> diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
>   #define for_each_present_cpu(cpu)  for_each_cpu(cpu,&cpu_present_map)
>
>   /* Copy to/from cpumap provided by control tools. */
> -struct xenctl_cpumap;
> -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *);
> -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *);
> +struct xenctl_map;
> +int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *);
> +int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_map *);
You should probably s/cpumap/map/; in the function names as well.
>
>   #endif /* __XEN_CPUMASK_H */
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -2,7 +2,7 @@
>   # ! - needs translation
>   # ? - needs checking
>   ?	dom0_vga_console_info		xen.h
> -?	xenctl_cpumap			xen.h
> +?	xenctl_map			xen.h
>   ?	mmu_update			xen.h
>   !	mmuext_op			xen.h
>   !	start_info			xen.h


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI06L-0001bu-EI; Wed, 11 Apr 2012 16:08:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SI06K-0001bg-6s
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:08:56 +0000
Received: from [85.158.138.51:59324] by server-4.bemta-3.messagelabs.com id
	99/E3-15341-79CA58F4; Wed, 11 Apr 2012 16:08:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334160532!21686343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7743 invoked from network); 11 Apr 2012 16:08:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="24064843"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:08:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:08:51 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SI06E-0001er-Qp;
	Wed, 11 Apr 2012 17:08:50 +0100
Message-ID: <4F85AC6C.10407@eu.citrix.com>
Date: Wed, 11 Apr 2012 17:08:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<e63c137d9fc551ca941a.1334150268@Solace>
In-Reply-To: <e63c137d9fc551ca941a.1334150268@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize
 xenctl_cpumap to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> In preparation for adding an xc_nodemap_t and its related
> hadling logic. Just add one indirection layer, and try to
> retain the interface as much as possible (although some
> small bits here and there have been affected).
This patch is fine with me on the whole (one comment below), but in this 
kind of a patch I think you need to include exactly what it is patch 
does.  I.e.:

1. Replace xenctl_cpumap with xenctl_map
2. Implement bitmap_to_xenctl_map and the reverse
3. Re-implement cpumask_to_xenctl_map with bitmap_to_xenctl_map and vice 
versa.
4. Other than #3, no functional changes.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.eu.com>
>
> diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
> --- a/tools/libxc/xc_cpupool.c
> +++ b/tools/libxc/xc_cpupool.c
> @@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_
>       sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO;
>       sysctl.u.cpupool_op.cpupool_id = poolid;
>       set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8;
>
>       err = do_sysctl_save(xch,&sysctl);
>
> @@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter
>       sysctl.cmd = XEN_SYSCTL_cpupool_op;
>       sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO;
>       set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8;
>
>       err = do_sysctl_save(xch,&sysctl);
>
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc
>
>       set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
>
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>       ret = do_domctl(xch,&domctl);
>
> @@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc
>       domctl.u.vcpuaffinity.vcpu = vcpu;
>
>       set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>       ret = do_domctl(xch,&domctl);
>
> diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c
> --- a/tools/libxc/xc_tbuf.c
> +++ b/tools/libxc/xc_tbuf.c
> @@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x
>       bitmap_64_to_byte(bytemap,&mask64, sizeof (mask64) * 8);
>
>       set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap);
> -    sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8;
> +    sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8;
>
>       ret = do_sysctl(xch,&sysctl);
>
> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -365,7 +365,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>       {
>           uint32_t cpu;
>           uint64_t idletime, now = NOW();
> -        struct xenctl_cpumap ctlmap;
> +        struct xenctl_map ctlmap;
>           cpumask_var_t cpumap;
>           XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
>           XEN_GUEST_HANDLE(uint64) idletimes;
> @@ -378,7 +378,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>           if ( cpufreq_controller != FREQCTL_dom0_kernel )
>               break;
>
> -        ctlmap.nr_cpus  = op->u.getidletime.cpumap_nr_cpus;
> +        ctlmap.nr_elems  = op->u.getidletime.cpumap_nr_cpus;
>           guest_from_compat_handle(cpumap_bitmap,
>                                    op->u.getidletime.cpumap_bitmap);
>           ctlmap.bitmap.p = cpumap_bitmap.p; /* handle ->  handle_64 conversion */
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -31,28 +31,29 @@
>   static DEFINE_SPINLOCK(domctl_lock);
>   DEFINE_SPINLOCK(vcpu_alloc_lock);
>
> -int cpumask_to_xenctl_cpumap(
> -    struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> +int bitmap_to_xenctl_map(struct xenctl_map *xenctl_map,
> +                         const unsigned long *bitmap,
> +                         unsigned int nbits)
>   {
>       unsigned int guest_bytes, copy_bytes, i;
>       uint8_t zero = 0;
>       int err = 0;
> -    uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8);
>
>       if ( !bytemap )
>           return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
> -    bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids);
> +    bitmap_long_to_byte(bytemap, bitmap, nbits);
>
>       if ( copy_bytes != 0 )
> -        if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) )
> +        if ( copy_to_guest(xenctl_map->bitmap, bytemap, copy_bytes) )
>               err = -EFAULT;
>
>       for ( i = copy_bytes; !err&&  i<  guest_bytes; i++ )
> -        if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i,&zero, 1) )
> +        if ( copy_to_guest_offset(xenctl_map->bitmap, i,&zero, 1) )
>               err = -EFAULT;
>
>       xfree(bytemap);
> @@ -60,36 +61,58 @@ int cpumask_to_xenctl_cpumap(
>       return err;
>   }
>
> -int xenctl_cpumap_to_cpumask(
> -    cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap)
> +int xenctl_map_to_bitmap(unsigned long *bitmap,
> +                         const struct xenctl_map *xenctl_map,
> +                         unsigned int nbits)
>   {
>       unsigned int guest_bytes, copy_bytes;
>       int err = 0;
> -    uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8);
>
>       if ( !bytemap )
>           return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_map->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
>       if ( copy_bytes != 0 )
>       {
> -        if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) )
> +        if ( copy_from_guest(bytemap, xenctl_map->bitmap, copy_bytes) )
>               err = -EFAULT;
> -        if ( (xenctl_cpumap->nr_cpus&  7)&&  (guest_bytes<= sizeof(bytemap)) )
> -            bytemap[guest_bytes-1]&= ~(0xff<<  (xenctl_cpumap->nr_cpus&  7));
> +        if ( (xenctl_map->nr_elems&  7)&&  (guest_bytes<= sizeof(bytemap)) )
> +            bytemap[guest_bytes-1]&= ~(0xff<<  (xenctl_map->nr_elems&  7));
>       }
>
> -    if ( err )
> -        /* nothing */;
> -    else if ( alloc_cpumask_var(cpumask) )
> -        bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids);
> +    if ( !err )
> +        bitmap_byte_to_long(bitmap, bytemap, nbits);
> +
> +    xfree(bytemap);
> +
> +    return err;
> +}
> +
> +int cpumask_to_xenctl_cpumap(struct xenctl_map *xenctl_cpumap,
> +                             const cpumask_t *cpumask)
> +{
> +    return bitmap_to_xenctl_map(xenctl_cpumap, cpumask_bits(cpumask),
> +                                nr_cpu_ids);
> +}
> +
> +int xenctl_cpumap_to_cpumask(cpumask_var_t *cpumask,
> +                             const struct xenctl_map *xenctl_cpumap)
> +{
> +    int err = 0;
> +
> +    if ( alloc_cpumask_var(cpumask) ) {
> +        err = xenctl_map_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap,
> +                                   nr_cpu_ids);
> +        /* In case of error, cleanup is up to us, as the caller won't care! */
> +        if ( err )
> +            free_cpumask_var(*cpumask);
> +    }
>       else
>           err = -ENOMEM;
>
> -    xfree(bytemap);
> -
>       return err;
>   }
>
> diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
> --- a/xen/include/public/arch-x86/xen-mca.h
> +++ b/xen/include/public/arch-x86/xen-mca.h
> @@ -414,7 +414,7 @@ struct xen_mc_mceinject {
>
>   struct xen_mc_inject_v2 {
>   	uint32_t flags;
> -	struct xenctl_cpumap cpumap;
> +	struct xenctl_map cpumap;
>   };
>   #endif
>
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -283,7 +283,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc
>   /* XEN_DOMCTL_getvcpuaffinity */
>   struct xen_domctl_vcpuaffinity {
>       uint32_t  vcpu;              /* IN */
> -    struct xenctl_cpumap cpumap; /* IN/OUT */
> +    struct xenctl_map cpumap;    /* IN/OUT */
>   };
>   typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t);
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -71,8 +71,8 @@ struct xen_sysctl_tbuf_op {
>   #define XEN_SYSCTL_TBUFOP_disable      5
>       uint32_t cmd;
>       /* IN/OUT variables */
> -    struct xenctl_cpumap cpu_mask;
> -    uint32_t             evt_mask;
> +    struct xenctl_map cpu_mask;
> +    uint32_t          evt_mask;
>       /* OUT variables */
>       uint64_aligned_t buffer_mfn;
>       uint32_t size;  /* Also an IN variable! */
> @@ -531,7 +531,7 @@ struct xen_sysctl_cpupool_op {
>       uint32_t domid;       /* IN: M              */
>       uint32_t cpu;         /* IN: AR             */
>       uint32_t n_dom;       /*            OUT: I  */
> -    struct xenctl_cpumap cpumap; /*     OUT: IF */
> +    struct xenctl_map cpumap;    /*     OUT: IF */
>   };
>   typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -822,9 +822,9 @@ typedef uint8_t xen_domain_handle_t[16];
>   #endif
>
>   #ifndef __ASSEMBLY__
> -struct xenctl_cpumap {
> +struct xenctl_map {
>       XEN_GUEST_HANDLE_64(uint8) bitmap;
> -    uint32_t nr_cpus;
> +    uint32_t nr_elems;
>   };
>   #endif
>
> diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
>   #define for_each_present_cpu(cpu)  for_each_cpu(cpu,&cpu_present_map)
>
>   /* Copy to/from cpumap provided by control tools. */
> -struct xenctl_cpumap;
> -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *);
> -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *);
> +struct xenctl_map;
> +int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *);
> +int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_map *);
You should probably s/cpumap/map/; in the function names as well.
>
>   #endif /* __XEN_CPUMASK_H */
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -2,7 +2,7 @@
>   # ! - needs translation
>   # ? - needs checking
>   ?	dom0_vga_console_info		xen.h
> -?	xenctl_cpumap			xen.h
> +?	xenctl_map			xen.h
>   ?	mmu_update			xen.h
>   !	mmuext_op			xen.h
>   !	start_info			xen.h


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:11:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI08d-00023J-Fh; Wed, 11 Apr 2012 16:11:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI08c-000238-2W
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:11:18 +0000
Received: from [193.109.254.147:42661] by server-7.bemta-14.messagelabs.com id
	27/77-01627-52DA58F4; Wed, 11 Apr 2012 16:11:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334160676!4129225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16695 invoked from network); 11 Apr 2012 16:11:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:11:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:11:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SI08a-0004bs-4T; Wed, 11 Apr 2012 16:11:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SI08a-0004ij-22;
	Wed, 11 Apr 2012 17:11:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.44324.27939.514126@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 17:11:16 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
...
> tools, blockers:
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:

I took a look at libxl.h and came up with the comments below.  Firstly
general things I tripped over, and then the list of things which need
converting to the new event system.

Ian.


Other:
======

]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t memory_kb, int wait_secs);
]   /* wait for the memory target of a domain to be reached */
]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid, int wait_secs);

This whole memory interface is a bit of a dog's breakfast.

]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
]   int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type);
]   /* libxl_primary_console_exec finds the domid and console number
]    * corresponding to the primary console of the given vm, then calls
]    * libxl_console_exec with the right arguments (domid might be different
]    * if the guest is using stubdoms).
]    * This function can be called after creating the device model, in
]    * case of HVM guests, and before libxl_run_bootloader in case of PV
]    * guests using pygrub. */
]   int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);

These functions should not exec things for you; they should tell you
the parameters.  Any execing helpers should be in libxlu.

]   /* common paths */
]   const char *libxl_sbindir_path(void);
]   const char *libxl_bindir_path(void);
]   const char *libxl_libexec_path(void);
]   const char *libxl_libdir_path(void);
]   const char *libxl_sharedir_path(void);
]   const char *libxl_private_bindir_path(void);
]   const char *libxl_xenfirmwaredir_path(void);
]   const char *libxl_xen_config_dir_path(void);
]   const char *libxl_xen_script_dir_path(void);
]   const char *libxl_lock_dir_path(void);
]   const char *libxl_run_dir_path(void);
]   const char *libxl_xenpaging_dir_path(void);

Surely these should be private ?


Need to be ao/eventified:
=========================

]   typedef struct {
]   #define XL_SUSPEND_DEBUG 1
]   #define XL_SUSPEND_LIVE 2
]       int flags;
]       int (*suspend_callback)(void *, int);
]   } libxl_domain_suspend_info;
...
]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
]                            uint32_t domid, int fd);

]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);

]   int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
]   int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);

Are these now merely initiations ?

]   int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);

Might become long-running in the future.

]   int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

]   /*
]    * Insert a CD-ROM device. A device corresponding to disk must already
]    * be attached to the guest.
]    */
]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

]   /*
]    * Make a disk available in this (the control) domain. Returns path to
]    * a device.
]    */
]   char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
]   int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);

Does this even need to be public at this stage ?

]   /* Network Interfaces */
]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);

]   /* Keyboard */
]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);

]   /* Framebuffer */
]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);

]   /* PCI Passthrough */
]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);

]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
]
]   libxl_xen_console_reader *
]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
]   int libxl_xen_console_read_line(libxl_ctx *ctx,
]                                   libxl_xen_console_reader *cr,
]                                   char **line_r);
]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
]                                      libxl_xen_console_reader *cr);

]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long);
]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
]                      uint32_t set);
]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char* uuid,
]                              int auth);
]   int libxl_tmem_freeable(libxl_ctx *ctx);

Not sure about the tmem calls.

And from libxl_utils.h:

]   pid_t libxl_fork(libxl_ctx *ctx);

This function is going to have to go away.

-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:11:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI08d-00023J-Fh; Wed, 11 Apr 2012 16:11:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI08c-000238-2W
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:11:18 +0000
Received: from [193.109.254.147:42661] by server-7.bemta-14.messagelabs.com id
	27/77-01627-52DA58F4; Wed, 11 Apr 2012 16:11:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334160676!4129225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16695 invoked from network); 11 Apr 2012 16:11:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:11:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:11:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SI08a-0004bs-4T; Wed, 11 Apr 2012 16:11:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SI08a-0004ij-22;
	Wed, 11 Apr 2012 17:11:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.44324.27939.514126@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 17:11:16 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
...
> tools, blockers:
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:

I took a look at libxl.h and came up with the comments below.  Firstly
general things I tripped over, and then the list of things which need
converting to the new event system.

Ian.


Other:
======

]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t memory_kb, int wait_secs);
]   /* wait for the memory target of a domain to be reached */
]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid, int wait_secs);

This whole memory interface is a bit of a dog's breakfast.

]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
]   int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type);
]   /* libxl_primary_console_exec finds the domid and console number
]    * corresponding to the primary console of the given vm, then calls
]    * libxl_console_exec with the right arguments (domid might be different
]    * if the guest is using stubdoms).
]    * This function can be called after creating the device model, in
]    * case of HVM guests, and before libxl_run_bootloader in case of PV
]    * guests using pygrub. */
]   int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);

These functions should not exec things for you; they should tell you
the parameters.  Any execing helpers should be in libxlu.

]   /* common paths */
]   const char *libxl_sbindir_path(void);
]   const char *libxl_bindir_path(void);
]   const char *libxl_libexec_path(void);
]   const char *libxl_libdir_path(void);
]   const char *libxl_sharedir_path(void);
]   const char *libxl_private_bindir_path(void);
]   const char *libxl_xenfirmwaredir_path(void);
]   const char *libxl_xen_config_dir_path(void);
]   const char *libxl_xen_script_dir_path(void);
]   const char *libxl_lock_dir_path(void);
]   const char *libxl_run_dir_path(void);
]   const char *libxl_xenpaging_dir_path(void);

Surely these should be private ?


Need to be ao/eventified:
=========================

]   typedef struct {
]   #define XL_SUSPEND_DEBUG 1
]   #define XL_SUSPEND_LIVE 2
]       int flags;
]       int (*suspend_callback)(void *, int);
]   } libxl_domain_suspend_info;
...
]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
]                            uint32_t domid, int fd);

]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);

]   int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
]   int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);

Are these now merely initiations ?

]   int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);

Might become long-running in the future.

]   int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

]   /*
]    * Insert a CD-ROM device. A device corresponding to disk must already
]    * be attached to the guest.
]    */
]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

]   /*
]    * Make a disk available in this (the control) domain. Returns path to
]    * a device.
]    */
]   char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
]   int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);

Does this even need to be public at this stage ?

]   /* Network Interfaces */
]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);

]   /* Keyboard */
]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);

]   /* Framebuffer */
]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);

]   /* PCI Passthrough */
]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);

]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
]
]   libxl_xen_console_reader *
]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
]   int libxl_xen_console_read_line(libxl_ctx *ctx,
]                                   libxl_xen_console_reader *cr,
]                                   char **line_r);
]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
]                                      libxl_xen_console_reader *cr);

]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long);
]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
]                      uint32_t set);
]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char* uuid,
]                              int auth);
]   int libxl_tmem_freeable(libxl_ctx *ctx);

Not sure about the tmem calls.

And from libxl_utils.h:

]   pid_t libxl_fork(libxl_ctx *ctx);

This function is going to have to go away.

-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0AT-0002Er-Vp; Wed, 11 Apr 2012 16:13:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SI0AS-0002Eb-De
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:13:12 +0000
Received: from [85.158.139.83:55566] by server-7.bemta-5.messagelabs.com id
	5C/D8-16195-79DA58F4; Wed, 11 Apr 2012 16:13:11 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334160790!18782151!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDM3NzcwMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5313 invoked from network); 11 Apr 2012 16:13:10 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 16:13:10 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q3BGD4wZ032089;
	Wed, 11 Apr 2012 18:13:04 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q3BGD3Q7008063;
	Wed, 11 Apr 2012 18:13:03 +0200
Message-ID: <4F85AD8F.7000004@siemens.com>
Date: Wed, 11 Apr 2012 18:13:03 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Peter Maydell <peter.maydell@linaro.org>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
In-Reply-To: <CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, Wei Liu <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-04-11 18:07, Peter Maydell wrote:
>> +#include "hw/apic_internal.h"
>> +#include "hw/msi.h"
>> +#include "xen.h"
>> +
>> +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
>> +                                  unsigned size)
>> +{
>> +    return -1U;
>> +}
> 
> This seems a rather confusing way to write 'return 0xffffffff;'

You mean 0xffffffffffffffff? :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0AT-0002Er-Vp; Wed, 11 Apr 2012 16:13:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SI0AS-0002Eb-De
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:13:12 +0000
Received: from [85.158.139.83:55566] by server-7.bemta-5.messagelabs.com id
	5C/D8-16195-79DA58F4; Wed, 11 Apr 2012 16:13:11 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334160790!18782151!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDM3NzcwMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5313 invoked from network); 11 Apr 2012 16:13:10 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Apr 2012 16:13:10 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q3BGD4wZ032089;
	Wed, 11 Apr 2012 18:13:04 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q3BGD3Q7008063;
	Wed, 11 Apr 2012 18:13:03 +0200
Message-ID: <4F85AD8F.7000004@siemens.com>
Date: Wed, 11 Apr 2012 18:13:03 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Peter Maydell <peter.maydell@linaro.org>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
In-Reply-To: <CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, Wei Liu <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-04-11 18:07, Peter Maydell wrote:
>> +#include "hw/apic_internal.h"
>> +#include "hw/msi.h"
>> +#include "xen.h"
>> +
>> +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
>> +                                  unsigned size)
>> +{
>> +    return -1U;
>> +}
> 
> This seems a rather confusing way to write 'return 0xffffffff;'

You mean 0xffffffffffffffff? :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Ag-0002Gb-5L; Wed, 11 Apr 2012 16:13:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SI030-0001Pu-MD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:05:30 +0000
Received: from [85.158.143.35:49771] by server-2.bemta-4.messagelabs.com id
	89/C2-17550-9CBA58F4; Wed, 11 Apr 2012 16:05:29 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334160327!4392971!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzMxNzg3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10938 invoked from network); 11 Apr 2012 16:05:29 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 16:05:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 11 Apr 2012 09:05:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="131242873"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by orsmga002.jf.intel.com with ESMTP; 11 Apr 2012 09:05:17 -0700
Message-ID: <4F85ABBD.5000609@intel.com>
Date: Wed, 11 Apr 2012 09:05:17 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
	<1334132428.5300.2685.camel@edumazet-glaptop>
In-Reply-To: <1334132428.5300.2685.camel@edumazet-glaptop>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Wed, 11 Apr 2012 16:13:24 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 01:20 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 12:15 -0700, Alexander Duyck wrote:
>
>> Actually now that I think about it my concerns go much further than the
>> memset.  I'm convinced that this is going to cause a pretty significant
>> performance regression on multiple drivers, especially on non x86_64
>> architecture.  What we have right now on most platforms is a
>> skb_shared_info structure in which everything up to and including frag 0
>> is all in one cache line.  This gives us pretty good performance for igb
>> and ixgbe since that is our common case when jumbo frames are not
>> enabled is to split the head and place the data in a page.
> I dont understand this split thing for MTU=1500 frames.
>
> Even using half a page per fragment, each skb :
>
> needs 2 allocations for sk_buff and skb->head, plus one page alloc /
> reference.
>
> skb->truesize = ksize(skb->head) + sizeof(*skb) + PAGE_SIZE/2 = 512 +
> 256 + 2048 = 2816 bytes
The number you provide for head is currently only available for 128 byte
skb allocations.  Anything larger than that will generate a 1K
allocation.  Also after all of these patches the smallest size you can
allocate will be 1K for anything under 504 bytes.

The size advantage is actually more for smaller frames.  In the case of
igb the behaviour is to place anything less than 512 bytes into just the
header and to skip using the page.  As such we get a much more ideal
allocation for small packets. since the truesize is only 1280 in that case.

In the case of ixgbe the advantage is more of a cache miss advantage. 
Ixgbe only receives the data into pages now.  I can prefetch the first
two cache lines of the page into memory while allocating the skb to
receive it.  As such we essentially cut the number of cache misses in
half versus the old approach which had us generating cache misses on the
sk_buff during allocation, and then generating more cache misses again
once we received the buffer and can fill out the sk_buff fields.  A
similar size advantage exists as well, but only for frames 256 bytes or
smaller.

> With non split you have :
>
> 2 allocations for sk_buff and skb->head.
>
> skb->truesize = ksize(skb->head) + sizeof(*skb) = 2048 + 256 = 2304
> bytes
>
> less overhead and less calls to page allocator...
>
> This only can benefit if GRO is on, since aggregation can use fragments
> and a single sk_buff, instead of a frag_list
There is much more than true size involved here.  My main argument is
that if we are going to align this modified skb_shared_info so that it
is aligned on nr_frags we should do it on all architectures, not just
x86_64.

Thanks,

Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Ag-0002Gb-5L; Wed, 11 Apr 2012 16:13:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SI030-0001Pu-MD
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:05:30 +0000
Received: from [85.158.143.35:49771] by server-2.bemta-4.messagelabs.com id
	89/C2-17550-9CBA58F4; Wed, 11 Apr 2012 16:05:29 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334160327!4392971!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzMxNzg3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10938 invoked from network); 11 Apr 2012 16:05:29 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 16:05:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 11 Apr 2012 09:05:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="131242873"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by orsmga002.jf.intel.com with ESMTP; 11 Apr 2012 09:05:17 -0700
Message-ID: <4F85ABBD.5000609@intel.com>
Date: Wed, 11 Apr 2012 09:05:17 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
	<1334132428.5300.2685.camel@edumazet-glaptop>
In-Reply-To: <1334132428.5300.2685.camel@edumazet-glaptop>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Wed, 11 Apr 2012 16:13:24 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 01:20 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 12:15 -0700, Alexander Duyck wrote:
>
>> Actually now that I think about it my concerns go much further than the
>> memset.  I'm convinced that this is going to cause a pretty significant
>> performance regression on multiple drivers, especially on non x86_64
>> architecture.  What we have right now on most platforms is a
>> skb_shared_info structure in which everything up to and including frag 0
>> is all in one cache line.  This gives us pretty good performance for igb
>> and ixgbe since that is our common case when jumbo frames are not
>> enabled is to split the head and place the data in a page.
> I dont understand this split thing for MTU=1500 frames.
>
> Even using half a page per fragment, each skb :
>
> needs 2 allocations for sk_buff and skb->head, plus one page alloc /
> reference.
>
> skb->truesize = ksize(skb->head) + sizeof(*skb) + PAGE_SIZE/2 = 512 +
> 256 + 2048 = 2816 bytes
The number you provide for head is currently only available for 128 byte
skb allocations.  Anything larger than that will generate a 1K
allocation.  Also after all of these patches the smallest size you can
allocate will be 1K for anything under 504 bytes.

The size advantage is actually more for smaller frames.  In the case of
igb the behaviour is to place anything less than 512 bytes into just the
header and to skip using the page.  As such we get a much more ideal
allocation for small packets. since the truesize is only 1280 in that case.

In the case of ixgbe the advantage is more of a cache miss advantage. 
Ixgbe only receives the data into pages now.  I can prefetch the first
two cache lines of the page into memory while allocating the skb to
receive it.  As such we essentially cut the number of cache misses in
half versus the old approach which had us generating cache misses on the
sk_buff during allocation, and then generating more cache misses again
once we received the buffer and can fill out the sk_buff fields.  A
similar size advantage exists as well, but only for frames 256 bytes or
smaller.

> With non split you have :
>
> 2 allocations for sk_buff and skb->head.
>
> skb->truesize = ksize(skb->head) + sizeof(*skb) = 2048 + 256 = 2304
> bytes
>
> less overhead and less calls to page allocator...
>
> This only can benefit if GRO is on, since aggregation can use fragments
> and a single sk_buff, instead of a frag_list
There is much more than true size involved here.  My main argument is
that if we are going to align this modified skb_shared_info so that it
is aligned on nr_frags we should do it on all architectures, not just
x86_64.

Thanks,

Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Af-0002GC-CM; Wed, 11 Apr 2012 16:13:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SHfsp-0004MX-RM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 18:33:40 +0000
Received: from [193.109.254.147:4731] by server-2.bemta-14.messagelabs.com id
	2A/A4-19409-30D748F4; Tue, 10 Apr 2012 18:33:39 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334082817!1519563!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMjY5MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 10 Apr 2012 18:33:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-27.messagelabs.com with SMTP;
	10 Apr 2012 18:33:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 10 Apr 2012 11:33:29 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="152036458"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by fmsmga002.fm.intel.com with ESMTP; 10 Apr 2012 11:33:29 -0700
Message-ID: <4F847CF9.3090701@intel.com>
Date: Tue, 10 Apr 2012 11:33:29 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Wed, 11 Apr 2012 16:13:24 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/2012 07:26 AM, Ian Campbell wrote:
> As of the previous patch we align the end (rather than the start) of the struct
> to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> increase from the next patch, the first 8 bytes of the struct end up on a
> different cache line to the rest of it so make sure it is something relatively
> unimportant to avoid hitting an extra cache line on hot operations such as
> kfree_skb.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>  include/linux/skbuff.h |   15 ++++++++++-----
>  net/core/skbuff.c      |    5 ++++-
>  2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 0ad6a46..f0ae39c 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -265,6 +265,15 @@ struct ubuf_info {
>   * the end of the header data, ie. at skb->end.
>   */
>  struct skb_shared_info {
> +	/* Intermediate layers must ensure that destructor_arg
> +	 * remains valid until skb destructor */
> +	void		*destructor_arg;
> +
> +	/*
> +	 * Warning: all fields from here until dataref are cleared in
> +	 * __alloc_skb()
> +	 *
> +	 */
>  	unsigned char	nr_frags;
>  	__u8		tx_flags;
>  	unsigned short	gso_size;
> @@ -276,14 +285,10 @@ struct skb_shared_info {
>  	__be32          ip6_frag_id;
>  
>  	/*
> -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> +	 * Warning: all fields before dataref are cleared in __alloc_skb()
>  	 */
>  	atomic_t	dataref;
>  
> -	/* Intermediate layers must ensure that destructor_arg
> -	 * remains valid until skb destructor */
> -	void *		destructor_arg;
> -
>  	/* must be last field, see pskb_expand_head() */
>  	skb_frag_t	frags[MAX_SKB_FRAGS];
>  };
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index d4e139e..b8a41d6 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
>  
>  	/* make sure we initialize shinfo sequentially */
>  	shinfo = skb_shinfo(skb);
> -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> +
> +	memset(&shinfo->nr_frags, 0,
> +	       offsetof(struct skb_shared_info, dataref)
> +	       - offsetof(struct skb_shared_info, nr_frags));
>  	atomic_set(&shinfo->dataref, 1);
>  	kmemcheck_annotate_variable(shinfo->destructor_arg);
>  

Have you checked this for 32 bit as well as 64?  Based on my math your
next patch will still mess up the memset on 32 bit with the structure
being split somewhere just in front of hwtstamps.

Why not just take frags and move it to the start of the structure?  It
is already an unknown value because it can be either 16 or 17 depending
on the value of PAGE_SIZE, and since you are making changes to frags the
changes wouldn't impact the alignment of the other values later on since
you are aligning the end of the structure.  That way you would be
guaranteed that all of the fields that will be memset would be in the
last 64 bytes.

Thanks,

Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Af-0002GC-CM; Wed, 11 Apr 2012 16:13:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SHfsp-0004MX-RM
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 18:33:40 +0000
Received: from [193.109.254.147:4731] by server-2.bemta-14.messagelabs.com id
	2A/A4-19409-30D748F4; Tue, 10 Apr 2012 18:33:39 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334082817!1519563!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMjY5MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 10 Apr 2012 18:33:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-27.messagelabs.com with SMTP;
	10 Apr 2012 18:33:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 10 Apr 2012 11:33:29 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="152036458"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by fmsmga002.fm.intel.com with ESMTP; 10 Apr 2012 11:33:29 -0700
Message-ID: <4F847CF9.3090701@intel.com>
Date: Tue, 10 Apr 2012 11:33:29 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Wed, 11 Apr 2012 16:13:24 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/2012 07:26 AM, Ian Campbell wrote:
> As of the previous patch we align the end (rather than the start) of the struct
> to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> increase from the next patch, the first 8 bytes of the struct end up on a
> different cache line to the rest of it so make sure it is something relatively
> unimportant to avoid hitting an extra cache line on hot operations such as
> kfree_skb.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>  include/linux/skbuff.h |   15 ++++++++++-----
>  net/core/skbuff.c      |    5 ++++-
>  2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 0ad6a46..f0ae39c 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -265,6 +265,15 @@ struct ubuf_info {
>   * the end of the header data, ie. at skb->end.
>   */
>  struct skb_shared_info {
> +	/* Intermediate layers must ensure that destructor_arg
> +	 * remains valid until skb destructor */
> +	void		*destructor_arg;
> +
> +	/*
> +	 * Warning: all fields from here until dataref are cleared in
> +	 * __alloc_skb()
> +	 *
> +	 */
>  	unsigned char	nr_frags;
>  	__u8		tx_flags;
>  	unsigned short	gso_size;
> @@ -276,14 +285,10 @@ struct skb_shared_info {
>  	__be32          ip6_frag_id;
>  
>  	/*
> -	 * Warning : all fields before dataref are cleared in __alloc_skb()
> +	 * Warning: all fields before dataref are cleared in __alloc_skb()
>  	 */
>  	atomic_t	dataref;
>  
> -	/* Intermediate layers must ensure that destructor_arg
> -	 * remains valid until skb destructor */
> -	void *		destructor_arg;
> -
>  	/* must be last field, see pskb_expand_head() */
>  	skb_frag_t	frags[MAX_SKB_FRAGS];
>  };
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index d4e139e..b8a41d6 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
>  
>  	/* make sure we initialize shinfo sequentially */
>  	shinfo = skb_shinfo(skb);
> -	memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> +
> +	memset(&shinfo->nr_frags, 0,
> +	       offsetof(struct skb_shared_info, dataref)
> +	       - offsetof(struct skb_shared_info, nr_frags));
>  	atomic_set(&shinfo->dataref, 1);
>  	kmemcheck_annotate_variable(shinfo->destructor_arg);
>  

Have you checked this for 32 bit as well as 64?  Based on my math your
next patch will still mess up the memset on 32 bit with the structure
being split somewhere just in front of hwtstamps.

Why not just take frags and move it to the start of the structure?  It
is already an unknown value because it can be either 16 or 17 depending
on the value of PAGE_SIZE, and since you are making changes to frags the
changes wouldn't impact the alignment of the other values later on since
you are aligning the end of the structure.  That way you would be
guaranteed that all of the fields that will be memset would be in the
last 64 bytes.

Thanks,

Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Af-0002GL-P8; Wed, 11 Apr 2012 16:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SHgXi-00020E-MI
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:15:54 +0000
Received: from [85.158.138.51:32080] by server-7.bemta-3.messagelabs.com id
	33/F9-03078-9E6848F4; Tue, 10 Apr 2012 19:15:53 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334085352!17368588!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMjY5MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24486 invoked from network); 10 Apr 2012 19:15:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 19:15:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 10 Apr 2012 12:15:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="152052278"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by fmsmga002.fm.intel.com with ESMTP; 10 Apr 2012 12:15:51 -0700
Message-ID: <4F8486E7.5050604@intel.com>
Date: Tue, 10 Apr 2012 12:15:51 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
In-Reply-To: <1334083265.5300.288.camel@edumazet-glaptop>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Wed, 11 Apr 2012 16:13:24 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
>
>> Have you checked this for 32 bit as well as 64?  Based on my math your
>> next patch will still mess up the memset on 32 bit with the structure
>> being split somewhere just in front of hwtstamps.
>>
>> Why not just take frags and move it to the start of the structure?  It
>> is already an unknown value because it can be either 16 or 17 depending
>> on the value of PAGE_SIZE, and since you are making changes to frags the
>> changes wouldn't impact the alignment of the other values later on since
>> you are aligning the end of the structure.  That way you would be
>> guaranteed that all of the fields that will be memset would be in the
>> last 64 bytes.
>>
> Now when a fragmented packet is copied in pskb_expand_head(), you access
> two separate zones of memory to copy the shinfo. But its supposed to be
> slow path.
>
> Problem with this is that the offsets of often used fields will be big
> (instead of being < 127) and code will be bigger on x86.

Actually now that I think about it my concerns go much further than the
memset.  I'm convinced that this is going to cause a pretty significant
performance regression on multiple drivers, especially on non x86_64
architecture.  What we have right now on most platforms is a
skb_shared_info structure in which everything up to and including frag 0
is all in one cache line.  This gives us pretty good performance for igb
and ixgbe since that is our common case when jumbo frames are not
enabled is to split the head and place the data in a page.

However the change being recommend here only resolves the issue for one
specific architecture, and that is what I don't agree with.  What we
need is a solution that also works for 64K pages or 32 bit pointers and
I am fairly certain this current solution does not.

Thanks,

Alex



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Af-0002GL-P8; Wed, 11 Apr 2012 16:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SHgXi-00020E-MI
	for xen-devel@lists.xen.org; Tue, 10 Apr 2012 19:15:54 +0000
Received: from [85.158.138.51:32080] by server-7.bemta-3.messagelabs.com id
	33/F9-03078-9E6848F4; Tue, 10 Apr 2012 19:15:53 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334085352!17368588!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMjY5MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24486 invoked from network); 10 Apr 2012 19:15:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-174.messagelabs.com with SMTP;
	10 Apr 2012 19:15:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 10 Apr 2012 12:15:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="152052278"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by fmsmga002.fm.intel.com with ESMTP; 10 Apr 2012 12:15:51 -0700
Message-ID: <4F8486E7.5050604@intel.com>
Date: Tue, 10 Apr 2012 12:15:51 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
In-Reply-To: <1334083265.5300.288.camel@edumazet-glaptop>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Wed, 11 Apr 2012 16:13:24 +0000
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
>
>> Have you checked this for 32 bit as well as 64?  Based on my math your
>> next patch will still mess up the memset on 32 bit with the structure
>> being split somewhere just in front of hwtstamps.
>>
>> Why not just take frags and move it to the start of the structure?  It
>> is already an unknown value because it can be either 16 or 17 depending
>> on the value of PAGE_SIZE, and since you are making changes to frags the
>> changes wouldn't impact the alignment of the other values later on since
>> you are aligning the end of the structure.  That way you would be
>> guaranteed that all of the fields that will be memset would be in the
>> last 64 bytes.
>>
> Now when a fragmented packet is copied in pskb_expand_head(), you access
> two separate zones of memory to copy the shinfo. But its supposed to be
> slow path.
>
> Problem with this is that the offsets of often used fields will be big
> (instead of being < 127) and code will be bigger on x86.

Actually now that I think about it my concerns go much further than the
memset.  I'm convinced that this is going to cause a pretty significant
performance regression on multiple drivers, especially on non x86_64
architecture.  What we have right now on most platforms is a
skb_shared_info structure in which everything up to and including frag 0
is all in one cache line.  This gives us pretty good performance for igb
and ixgbe since that is our common case when jumbo frames are not
enabled is to split the head and place the data in a page.

However the change being recommend here only resolves the issue for one
specific architecture, and that is what I don't agree with.  What we
need is a solution that also works for 64K pages or 32 bit pointers and
I am fairly certain this current solution does not.

Thanks,

Alex



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Av-0002M1-Im; Wed, 11 Apr 2012 16:13:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SI0At-0002LM-Jt
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:13:39 +0000
Received: from [85.158.139.83:45050] by server-12.bemta-5.messagelabs.com id
	30/A2-05587-2BDA58F4; Wed, 11 Apr 2012 16:13:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334160817!16027669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24981 invoked from network); 11 Apr 2012 16:13:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:13:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:13:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:13:37 +0100
Date: Wed, 11 Apr 2012 17:17:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Peter Maydell <peter.maydell@linaro.org>
In-Reply-To: <CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1457749389-1334161050=:15151"
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-1457749389-1334161050=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Apr 2012, Peter Maydell wrote:
> On 5 April 2012 10:35, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> > --- /dev/null
> > +++ b/hw/xen_apic.c
> > @@ -0,0 +1,90 @@
> > +/*
> > + * Xen basic APIC support
> > + *
> > + * Copyright (c) 2012 Citrix
> > + *
> > + * Authors:
> > + *  Wei Liu <wei.liu2@citrix.com>
> > + *
> > + * This work is licensed under the terms of the GNU GPL version 2.
> > + * See the COPYING file in the top-level directory.
> > + */
> 
> Really 2-only, not 2-or-later ?

I am not a great fun of the 2-or-later clause and it doesn't look like a
requirement from the QEMU project POV. However if it is, I'll change it
to 2-or-later.


> > +#include "hw/apic_internal.h"
> > +#include "hw/msi.h"
> > +#include "xen.h"
> > +
> > +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
> > +                                  unsigned size)
> > +{
> > +    return -1U;
> > +}
> 
> This seems a rather confusing way to write 'return 0xffffffff;'
 
Yep, I'll change it.
--8323329-1457749389-1334161050=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-1457749389-1334161050=:15151--


From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Av-0002M1-Im; Wed, 11 Apr 2012 16:13:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SI0At-0002LM-Jt
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:13:39 +0000
Received: from [85.158.139.83:45050] by server-12.bemta-5.messagelabs.com id
	30/A2-05587-2BDA58F4; Wed, 11 Apr 2012 16:13:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334160817!16027669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24981 invoked from network); 11 Apr 2012 16:13:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:13:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:13:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:13:37 +0100
Date: Wed, 11 Apr 2012 17:17:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Peter Maydell <peter.maydell@linaro.org>
In-Reply-To: <CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1457749389-1334161050=:15151"
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-1457749389-1334161050=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Apr 2012, Peter Maydell wrote:
> On 5 April 2012 10:35, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> > --- /dev/null
> > +++ b/hw/xen_apic.c
> > @@ -0,0 +1,90 @@
> > +/*
> > + * Xen basic APIC support
> > + *
> > + * Copyright (c) 2012 Citrix
> > + *
> > + * Authors:
> > + *  Wei Liu <wei.liu2@citrix.com>
> > + *
> > + * This work is licensed under the terms of the GNU GPL version 2.
> > + * See the COPYING file in the top-level directory.
> > + */
> 
> Really 2-only, not 2-or-later ?

I am not a great fun of the 2-or-later clause and it doesn't look like a
requirement from the QEMU project POV. However if it is, I'll change it
to 2-or-later.


> > +#include "hw/apic_internal.h"
> > +#include "hw/msi.h"
> > +#include "xen.h"
> > +
> > +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
> > +                                  unsigned size)
> > +{
> > +    return -1U;
> > +}
> 
> This seems a rather confusing way to write 'return 0xffffffff;'
 
Yep, I'll change it.
--8323329-1457749389-1334161050=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-1457749389-1334161050=:15151--


From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0B6-0002RI-4R; Wed, 11 Apr 2012 16:13:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI0B4-0002Q1-Jb
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:13:50 +0000
Received: from [85.158.139.83:60141] by server-5.bemta-5.messagelabs.com id
	7D/5E-13566-DBDA58F4; Wed, 11 Apr 2012 16:13:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334160828!23383284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19504 invoked from network); 11 Apr 2012 16:13:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:13:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:13:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:13:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SI0B1-0004ca-W6; Wed, 11 Apr 2012 16:13:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SI0B1-0004jl-V4;
	Wed, 11 Apr 2012 17:13:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.44475.632787.365339@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 17:13:47 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
In-Reply-To: <20357.44324.27939.514126@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: Xen 4.2 Release Plan / TODO"):
> Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> > Plan for a 4.2 release:
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> ...
> > tools, blockers:
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> I took a look at libxl.h and came up with the comments below.  Firstly
> general things I tripped over, and then the list of things which need
> converting to the new event system.

And I should mention that in my event series I have two
as-yet-unposted half-backed patches to rewrite libxl__spawn_* and
libxl_domain_create_*.

It may be that we can add dummy ao_hows to these functions which might
be good enough for now, although particularly for domain creation
(which includes spawning) it might complicate the efforts of users to
use the new API.

Currently any use of subprocesses inside libxl which is not dealt with
by the new event machinery will experience problems if the event loop
is also used, because the event loop will reap the children.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:13:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0B6-0002RI-4R; Wed, 11 Apr 2012 16:13:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI0B4-0002Q1-Jb
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:13:50 +0000
Received: from [85.158.139.83:60141] by server-5.bemta-5.messagelabs.com id
	7D/5E-13566-DBDA58F4; Wed, 11 Apr 2012 16:13:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334160828!23383284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19504 invoked from network); 11 Apr 2012 16:13:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:13:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:13:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:13:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SI0B1-0004ca-W6; Wed, 11 Apr 2012 16:13:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SI0B1-0004jl-V4;
	Wed, 11 Apr 2012 17:13:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20357.44475.632787.365339@mariner.uk.xensource.com>
Date: Wed, 11 Apr 2012 17:13:47 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
In-Reply-To: <20357.44324.27939.514126@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: Xen 4.2 Release Plan / TODO"):
> Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> > Plan for a 4.2 release:
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> ...
> > tools, blockers:
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> I took a look at libxl.h and came up with the comments below.  Firstly
> general things I tripped over, and then the list of things which need
> converting to the new event system.

And I should mention that in my event series I have two
as-yet-unposted half-backed patches to rewrite libxl__spawn_* and
libxl_domain_create_*.

It may be that we can add dummy ao_hows to these functions which might
be good enough for now, although particularly for domain creation
(which includes spawning) it might complicate the efforts of users to
use the new API.

Currently any use of subprocesses inside libxl which is not dealt with
by the new event machinery will experience problems if the event loop
is also used, because the event loop will reap the children.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:16:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0DC-0002yJ-NX; Wed, 11 Apr 2012 16:16:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SI0DB-0002y0-IN
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:16:01 +0000
Received: from [85.158.139.83:15950] by server-7.bemta-5.messagelabs.com id
	B9/2D-16195-04EA58F4; Wed, 11 Apr 2012 16:16:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334160958!22843620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6154 invoked from network); 11 Apr 2012 16:15:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:15:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:15:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:15:31 +0100
Date: Wed, 11 Apr 2012 17:19:09 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1204111718310.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1771022453-1334161164=:15151"
Cc: Peter Maydell <peter.maydell@linaro.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-1771022453-1334161164=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Apr 2012, Stefano Stabellini wrote:
> On Wed, 11 Apr 2012, Peter Maydell wrote:
> > On 5 April 2012 10:35, Wei Liu <wei.liu2@citrix.com> wrote:
> > >
> > > --- /dev/null
> > > +++ b/hw/xen_apic.c
> > > @@ -0,0 +1,90 @@
> > > +/*
> > > + * Xen basic APIC support
> > > + *
> > > + * Copyright (c) 2012 Citrix
> > > + *
> > > + * Authors:
> > > + *  Wei Liu <wei.liu2@citrix.com>
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL version 2.
> > > + * See the COPYING file in the top-level directory.
> > > + */
> > 
> > Really 2-only, not 2-or-later ?
> 
> I am not a great fun of the 2-or-later clause and it doesn't look like a
> requirement from the QEMU project POV. However if it is, I'll change it
> to 2-or-later.
> 
> 
> > > +#include "hw/apic_internal.h"
> > > +#include "hw/msi.h"
> > > +#include "xen.h"
> > > +
> > > +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
> > > +                                  unsigned size)
> > > +{
> > > +    return -1U;
> > > +}
> > 
> > This seems a rather confusing way to write 'return 0xffffffff;'
>  
> Yep, I'll change it.

Actually it is a uint64 so it is a lot of f's
--8323329-1771022453-1334161164=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-1771022453-1334161164=:15151--


From xen-devel-bounces@lists.xen.org Wed Apr 11 16:16:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0DC-0002yJ-NX; Wed, 11 Apr 2012 16:16:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SI0DB-0002y0-IN
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:16:01 +0000
Received: from [85.158.139.83:15950] by server-7.bemta-5.messagelabs.com id
	B9/2D-16195-04EA58F4; Wed, 11 Apr 2012 16:16:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334160958!22843620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6154 invoked from network); 11 Apr 2012 16:15:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:15:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11883542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 16:15:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 17:15:31 +0100
Date: Wed, 11 Apr 2012 17:19:09 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1204111718310.15151@kaball-desktop>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1771022453-1334161164=:15151"
Cc: Peter Maydell <peter.maydell@linaro.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-1771022453-1334161164=:15151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Apr 2012, Stefano Stabellini wrote:
> On Wed, 11 Apr 2012, Peter Maydell wrote:
> > On 5 April 2012 10:35, Wei Liu <wei.liu2@citrix.com> wrote:
> > >
> > > --- /dev/null
> > > +++ b/hw/xen_apic.c
> > > @@ -0,0 +1,90 @@
> > > +/*
> > > + * Xen basic APIC support
> > > + *
> > > + * Copyright (c) 2012 Citrix
> > > + *
> > > + * Authors:
> > > + *  Wei Liu <wei.liu2@citrix.com>
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL version 2.
> > > + * See the COPYING file in the top-level directory.
> > > + */
> > 
> > Really 2-only, not 2-or-later ?
> 
> I am not a great fun of the 2-or-later clause and it doesn't look like a
> requirement from the QEMU project POV. However if it is, I'll change it
> to 2-or-later.
> 
> 
> > > +#include "hw/apic_internal.h"
> > > +#include "hw/msi.h"
> > > +#include "xen.h"
> > > +
> > > +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
> > > +                                  unsigned size)
> > > +{
> > > +    return -1U;
> > > +}
> > 
> > This seems a rather confusing way to write 'return 0xffffffff;'
>  
> Yep, I'll change it.

Actually it is a uint64 so it is a lot of f's
--8323329-1771022453-1334161164=:15151
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-1771022453-1334161164=:15151--


From xen-devel-bounces@lists.xen.org Wed Apr 11 16:23:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:23:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0KD-0003Xm-F9; Wed, 11 Apr 2012 16:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SI0KB-0003XS-I3
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:23:15 +0000
Received: from [85.158.143.99:64820] by server-2.bemta-4.messagelabs.com id
	20/68-17550-2FFA58F4; Wed, 11 Apr 2012 16:23:14 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334161386!22655795!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 985 invoked from network); 11 Apr 2012 16:23:14 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:23:14 -0000
Received: by ggcs5 with SMTP id s5so660068ggc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 09:23:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=YXFKM6fpmWGNi17E8w+zqlQps8F/Kcw457y3TJ6eQkc=;
	b=d7yJBJinKuReyxYgI85/6GcKSpqD6EPGGUcdKs/VobsH/E57A9D1Mi9F8HyLCc+0QG
	B6Oy45p7Zeo1C5sOQNAjF8cqZsLYduqB6sdgJ36M+23a5mYTJAyDgFbbwEM4eEk9Du1n
	TQLJ+klxAbyv70rD3yTZOtXyQGDKS0ZKqj/bFXJBCOu7/IQQzWy+wcRo0uqDfIk7Bpox
	RcUY+loOBFoqVK1yUl+f2u2J25yQj3R0X9AL5H7weRecsCSFSUbquIOLOxDEmdUGiKmL
	d8HOayhitYdwmFdEeyLoEPc1eIUK2OWYm+gnV9jjQN9jnSLa24EkWRVfazP5vf8Tr2Ew
	A2/g==
MIME-Version: 1.0
Received: by 10.50.188.138 with SMTP id ga10mr6399814igc.51.1334161385916;
	Wed, 11 Apr 2012 09:23:05 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 11 Apr 2012 09:23:05 -0700 (PDT)
In-Reply-To: <4F85AD8F.7000004@siemens.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<4F85AD8F.7000004@siemens.com>
Date: Wed, 11 Apr 2012 17:23:05 +0100
Message-ID: <CAFEAcA9Lpo_ejTuDo+snKGOSzSEAWD6D4b_37ur2RTRSZ_euhQ@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
X-Gm-Message-State: ALoCoQlY/XUuDbds7o0G1B/J+qGK84NST2NUmmuhPjxi9MEqEgsYmgfpSIWM4lYPmVA0ZTqb6Cra
Cc: xen-devel <xen-devel@lists.xensource.com>, Wei Liu <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
	and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTEgQXByaWwgMjAxMiAxNzoxMywgSmFuIEtpc3prYSA8amFuLmtpc3prYUBzaWVtZW5zLmNv
bT4gd3JvdGU6Cj4gT24gMjAxMi0wNC0xMSAxODowNywgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPj4+
ICsjaW5jbHVkZSAiaHcvYXBpY19pbnRlcm5hbC5oIgo+Pj4gKyNpbmNsdWRlICJody9tc2kuaCIK
Pj4+ICsjaW5jbHVkZSAieGVuLmgiCj4+PiArCj4+PiArc3RhdGljIHVpbnQ2NF90IHhlbl9hcGlj
X21lbV9yZWFkKHZvaWQgKm9wYXF1ZSwgdGFyZ2V0X3BoeXNfYWRkcl90IGFkZHIsCj4+PiArIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdW5zaWduZWQg
c2l6ZSkKPj4+ICt7Cj4+PiArIMKgIMKgcmV0dXJuIC0xVTsKPj4+ICt9Cj4+Cj4+IFRoaXMgc2Vl
bXMgYSByYXRoZXIgY29uZnVzaW5nIHdheSB0byB3cml0ZSAncmV0dXJuIDB4ZmZmZmZmZmY7Jwo+
Cj4gWW91IG1lYW4gMHhmZmZmZmZmZmZmZmZmZmZmPyA6KQoKTm8sIHRoYXQncyB3aHkgaXQncyBj
b25mdXNpbmcgOi0pCgoxVSBpcyB0aGUgaW50ZWdlciBjb25zdGFudCAxIHdpdGggYSB0eXBlIG9m
ICd1bnNpZ25lZCBpbnQnCihjZiBDOTkgc2VjdGlvbiA2LjQuNC4xKS4gSXQgdGhlbiBoYXMgdGhl
IHVuYXJ5IG5lZ2F0aW9uCm9wZXJhdG9yIGFwcGxpZWQgdG8gaXQsIGdpdmluZyAoZm9yIHRoZSB1
c3VhbCAzMiBiaXQgaW50ZWdlcgpjYXNlKSAweGZmZmZmZmZmLiBUaGlzIGlzIHRoZW4gY2FzdCBm
cm9tICd1bnNpZ25lZCBpbnQnCnRvICd1aW50NjRfdCcgZ2l2aW5nIDB4ZmZmZmZmZmYgYXMgYSA2
NCBiaXQgdW5zaWduZWQgdmFsdWUuCgooSSBoYWQgdG8gd3JpdGUgYSB0ZXN0IHByb2dyYW0gdG8g
KGEpIGNvbmZpcm0gd2hhdCBpdCB3YXMKZ29pbmcgdG8gcmV0dXJuIGFuZCAoYikgdGhhdCBpdCB3
b3VsZCBiZSB0aGUgc2FtZSB0aGluZyBvbgpib3RoIDMyIGFuZCA2NCBiaXQgc3lzdGVtcy4uLikK
CkkgaGF2ZSBubyBvcGluaW9uIG9uIHdoYXQgdGhlIHJldHVybiB2YWx1ZSBhY3R1YWxseSBvdWdo
dAp0byBiZS4KCi0tIFBNTQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:23:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:23:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0KD-0003Xm-F9; Wed, 11 Apr 2012 16:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1SI0KB-0003XS-I3
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:23:15 +0000
Received: from [85.158.143.99:64820] by server-2.bemta-4.messagelabs.com id
	20/68-17550-2FFA58F4; Wed, 11 Apr 2012 16:23:14 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334161386!22655795!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 985 invoked from network); 11 Apr 2012 16:23:14 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:23:14 -0000
Received: by ggcs5 with SMTP id s5so660068ggc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 09:23:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=YXFKM6fpmWGNi17E8w+zqlQps8F/Kcw457y3TJ6eQkc=;
	b=d7yJBJinKuReyxYgI85/6GcKSpqD6EPGGUcdKs/VobsH/E57A9D1Mi9F8HyLCc+0QG
	B6Oy45p7Zeo1C5sOQNAjF8cqZsLYduqB6sdgJ36M+23a5mYTJAyDgFbbwEM4eEk9Du1n
	TQLJ+klxAbyv70rD3yTZOtXyQGDKS0ZKqj/bFXJBCOu7/IQQzWy+wcRo0uqDfIk7Bpox
	RcUY+loOBFoqVK1yUl+f2u2J25yQj3R0X9AL5H7weRecsCSFSUbquIOLOxDEmdUGiKmL
	d8HOayhitYdwmFdEeyLoEPc1eIUK2OWYm+gnV9jjQN9jnSLa24EkWRVfazP5vf8Tr2Ew
	A2/g==
MIME-Version: 1.0
Received: by 10.50.188.138 with SMTP id ga10mr6399814igc.51.1334161385916;
	Wed, 11 Apr 2012 09:23:05 -0700 (PDT)
Received: by 10.50.100.198 with HTTP; Wed, 11 Apr 2012 09:23:05 -0700 (PDT)
In-Reply-To: <4F85AD8F.7000004@siemens.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<4F85AD8F.7000004@siemens.com>
Date: Wed, 11 Apr 2012 17:23:05 +0100
Message-ID: <CAFEAcA9Lpo_ejTuDo+snKGOSzSEAWD6D4b_37ur2RTRSZ_euhQ@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
X-Gm-Message-State: ALoCoQlY/XUuDbds7o0G1B/J+qGK84NST2NUmmuhPjxi9MEqEgsYmgfpSIWM4lYPmVA0ZTqb6Cra
Cc: xen-devel <xen-devel@lists.xensource.com>, Wei Liu <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
	and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTEgQXByaWwgMjAxMiAxNzoxMywgSmFuIEtpc3prYSA8amFuLmtpc3prYUBzaWVtZW5zLmNv
bT4gd3JvdGU6Cj4gT24gMjAxMi0wNC0xMSAxODowNywgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPj4+
ICsjaW5jbHVkZSAiaHcvYXBpY19pbnRlcm5hbC5oIgo+Pj4gKyNpbmNsdWRlICJody9tc2kuaCIK
Pj4+ICsjaW5jbHVkZSAieGVuLmgiCj4+PiArCj4+PiArc3RhdGljIHVpbnQ2NF90IHhlbl9hcGlj
X21lbV9yZWFkKHZvaWQgKm9wYXF1ZSwgdGFyZ2V0X3BoeXNfYWRkcl90IGFkZHIsCj4+PiArIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdW5zaWduZWQg
c2l6ZSkKPj4+ICt7Cj4+PiArIMKgIMKgcmV0dXJuIC0xVTsKPj4+ICt9Cj4+Cj4+IFRoaXMgc2Vl
bXMgYSByYXRoZXIgY29uZnVzaW5nIHdheSB0byB3cml0ZSAncmV0dXJuIDB4ZmZmZmZmZmY7Jwo+
Cj4gWW91IG1lYW4gMHhmZmZmZmZmZmZmZmZmZmZmPyA6KQoKTm8sIHRoYXQncyB3aHkgaXQncyBj
b25mdXNpbmcgOi0pCgoxVSBpcyB0aGUgaW50ZWdlciBjb25zdGFudCAxIHdpdGggYSB0eXBlIG9m
ICd1bnNpZ25lZCBpbnQnCihjZiBDOTkgc2VjdGlvbiA2LjQuNC4xKS4gSXQgdGhlbiBoYXMgdGhl
IHVuYXJ5IG5lZ2F0aW9uCm9wZXJhdG9yIGFwcGxpZWQgdG8gaXQsIGdpdmluZyAoZm9yIHRoZSB1
c3VhbCAzMiBiaXQgaW50ZWdlcgpjYXNlKSAweGZmZmZmZmZmLiBUaGlzIGlzIHRoZW4gY2FzdCBm
cm9tICd1bnNpZ25lZCBpbnQnCnRvICd1aW50NjRfdCcgZ2l2aW5nIDB4ZmZmZmZmZmYgYXMgYSA2
NCBiaXQgdW5zaWduZWQgdmFsdWUuCgooSSBoYWQgdG8gd3JpdGUgYSB0ZXN0IHByb2dyYW0gdG8g
KGEpIGNvbmZpcm0gd2hhdCBpdCB3YXMKZ29pbmcgdG8gcmV0dXJuIGFuZCAoYikgdGhhdCBpdCB3
b3VsZCBiZSB0aGUgc2FtZSB0aGluZyBvbgpib3RoIDMyIGFuZCA2NCBiaXQgc3lzdGVtcy4uLikK
CkkgaGF2ZSBubyBvcGluaW9uIG9uIHdoYXQgdGhlIHJldHVybiB2YWx1ZSBhY3R1YWxseSBvdWdo
dAp0byBiZS4KCi0tIFBNTQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:30:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Qo-00043R-VF; Wed, 11 Apr 2012 16:30:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SI0Qn-00043J-Qg
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:30:06 +0000
Received: from [85.158.138.51:7533] by server-11.bemta-3.messagelabs.com id
	EE/B5-18894-C81B58F4; Wed, 11 Apr 2012 16:30:04 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334161802!10718499!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16948 invoked from network); 11 Apr 2012 16:30:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:30:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="24065732"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:30:02 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 11 Apr 2012
	12:30:02 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 11 Apr 2012 12:29:59 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0Xv1Ezmxk/yHv8QKidfTdxWL79rQAQBiDg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334133870.5394.70.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 11, 2012 4:45 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Tue, 2012-04-10 at 20:04 +0100, Ross Philipson wrote:
> > Not really. I think part of the problem here is my mixing of
> > terminology. For SMBIOS bits I am pulling apart the overall SMBIOS
> > table and just grabbing a desired subset of the SMBIOS structures. The
> > individual structures are the entities that do not have an overall
> > length field
> 
> So, to use the terminology of tools/firmware/hvmloader/smbios_types.h,
> you have entities which are subsets of a structure and so do not start
> with a "struct smbios_structure_header"?
> 
> Ian.
> 

Yea so the entire SMBIOS table begins with the "struct smbios_entry_point" which is not present in what I pass in. I have N structs (possibly some of the same type) that start with a "struct smbios_structure_header". The gotcha is that the "length" field only defines the fixed portion of each of the SMBIOS structs. There can be any number of strings following that struct of varying length. Then entire structure is doubly terminated with "\0\0". What I wanted to avoid is having to put the parsing code in hvmloader to reparse for each struct, which was already done by the tools. A simple approach is to use the <length><blob> scheme.

Thanks
Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:30:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Qo-00043R-VF; Wed, 11 Apr 2012 16:30:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SI0Qn-00043J-Qg
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 16:30:06 +0000
Received: from [85.158.138.51:7533] by server-11.bemta-3.messagelabs.com id
	EE/B5-18894-C81B58F4; Wed, 11 Apr 2012 16:30:04 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334161802!10718499!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16948 invoked from network); 11 Apr 2012 16:30:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:30:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="24065732"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:30:02 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 11 Apr 2012
	12:30:02 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 11 Apr 2012 12:29:59 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0Xv1Ezmxk/yHv8QKidfTdxWL79rQAQBiDg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334133870.5394.70.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: Wednesday, April 11, 2012 4:45 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Tue, 2012-04-10 at 20:04 +0100, Ross Philipson wrote:
> > Not really. I think part of the problem here is my mixing of
> > terminology. For SMBIOS bits I am pulling apart the overall SMBIOS
> > table and just grabbing a desired subset of the SMBIOS structures. The
> > individual structures are the entities that do not have an overall
> > length field
> 
> So, to use the terminology of tools/firmware/hvmloader/smbios_types.h,
> you have entities which are subsets of a structure and so do not start
> with a "struct smbios_structure_header"?
> 
> Ian.
> 

Yea so the entire SMBIOS table begins with the "struct smbios_entry_point" which is not present in what I pass in. I have N structs (possibly some of the same type) that start with a "struct smbios_structure_header". The gotcha is that the "length" field only defines the fixed portion of each of the SMBIOS structs. There can be any number of strings following that struct of varying length. Then entire structure is doubly terminated with "\0\0". What I wanted to avoid is having to put the parsing code in hvmloader to reparse for each struct, which was already done by the tools. A simple approach is to use the <length><blob> scheme.

Thanks
Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:32:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0SX-0004AP-EO; Wed, 11 Apr 2012 16:31:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SI0SV-0004AC-TT
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:31:52 +0000
Received: from [85.158.143.35:58243] by server-2.bemta-4.messagelabs.com id
	1D/22-17550-7F1B58F4; Wed, 11 Apr 2012 16:31:51 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334161909!6630198!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMzAzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3480 invoked from network); 11 Apr 2012 16:31:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 16:31:50 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 11 Apr 2012 09:31:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="152441010"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by fmsmga002.fm.intel.com with ESMTP; 11 Apr 2012 09:31:38 -0700
Message-ID: <4F85B1EA.9000600@intel.com>
Date: Wed, 11 Apr 2012 09:31:38 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
	<1334131241.12209.199.camel@dagon.hellion.org.uk>
In-Reply-To: <1334131241.12209.199.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.3.5
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 01:00 AM, Ian Campbell wrote:
> On Tue, 2012-04-10 at 20:15 +0100, Alexander Duyck wrote:
>> On 04/10/2012 11:41 AM, Eric Dumazet wrote:
>>> On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
>>>
>>>> Have you checked this for 32 bit as well as 64?  Based on my math your
>>>> next patch will still mess up the memset on 32 bit with the structure
>>>> being split somewhere just in front of hwtstamps.
>>>>
>>>> Why not just take frags and move it to the start of the structure?  It
>>>> is already an unknown value because it can be either 16 or 17 depending
>>>> on the value of PAGE_SIZE, and since you are making changes to frags the
>>>> changes wouldn't impact the alignment of the other values later on since
>>>> you are aligning the end of the structure.  That way you would be
>>>> guaranteed that all of the fields that will be memset would be in the
>>>> last 64 bytes.
>>>>
>>> Now when a fragmented packet is copied in pskb_expand_head(), you access
>>> two separate zones of memory to copy the shinfo. But its supposed to be
>>> slow path.
>>>
>>> Problem with this is that the offsets of often used fields will be big
>>> (instead of being < 127) and code will be bigger on x86.
>> Actually now that I think about it my concerns go much further than the
>> memset.  I'm convinced that this is going to cause a pretty significant
>> performance regression on multiple drivers, especially on non x86_64
>> architecture.  What we have right now on most platforms is a
>> skb_shared_info structure in which everything up to and including frag 0
>> is all in one cache line.  This gives us pretty good performance for igb
>> and ixgbe since that is our common case when jumbo frames are not
>> enabled is to split the head and place the data in a page.
> With all the changes in this series it is still possible to fit a
> maximum standard MTU frame and the shinfo on the same 4K page while also
> have the skb_shared_info up to and including frag [0] aligned to the
> same 64 byte cache line. 
>
> The only exception is destructor_arg on 64 bit which is on the preceding
> cache line but that is not a field used in any hot path.
The problem I have is that this is only true on x86_64.  Proper work
hasn't been done to guarantee this on any other architectures.

I think what I would like to see is instead of just setting things up
and hoping it comes out cache aligned on nr_frags why not take steps to
guarantee it?  You could do something like place and size the structure
based on:
SKB_DATA_ALIGN(sizeof(skb_shared_info) - offsetof(struct
skb_shared_info, nr_frags)) + offsetof(struct skb_shared_info, nr_frags)

That way you would have your alignment still guaranteed based off of the
end of the structure, but anything placed before nr_frags would be
placed on the end of the previous cache line.

>> However the change being recommend here only resolves the issue for one
>> specific architecture, and that is what I don't agree with.  What we
>> need is a solution that also works for 64K pages or 32 bit pointers and
>> I am fairly certain this current solution does not.
> I think it does work for 32 bit pointers. What issue to do you see with
> 64K pages?
>
> Ian.
With 64K pages the MAX_SKB_FRAGS value drops from 17 to 16.  That will
undoubtedly mess up the alignment.

Thanks,

Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:32:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0SX-0004AP-EO; Wed, 11 Apr 2012 16:31:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexander.h.duyck@intel.com>) id 1SI0SV-0004AC-TT
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:31:52 +0000
Received: from [85.158.143.35:58243] by server-2.bemta-4.messagelabs.com id
	1D/22-17550-7F1B58F4; Wed, 11 Apr 2012 16:31:51 +0000
X-Env-Sender: alexander.h.duyck@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334161909!6630198!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMzAzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3480 invoked from network); 11 Apr 2012 16:31:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-21.messagelabs.com with SMTP;
	11 Apr 2012 16:31:50 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 11 Apr 2012 09:31:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="152441010"
Received: from unknown (HELO ahduyck-so1.jf.intel.com) ([134.134.3.115])
	by fmsmga002.fm.intel.com with ESMTP; 11 Apr 2012 09:31:38 -0700
Message-ID: <4F85B1EA.9000600@intel.com>
Date: Wed, 11 Apr 2012 09:31:38 -0700
From: Alexander Duyck <alexander.h.duyck@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
	<1334131241.12209.199.camel@dagon.hellion.org.uk>
In-Reply-To: <1334131241.12209.199.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.3.5
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 01:00 AM, Ian Campbell wrote:
> On Tue, 2012-04-10 at 20:15 +0100, Alexander Duyck wrote:
>> On 04/10/2012 11:41 AM, Eric Dumazet wrote:
>>> On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
>>>
>>>> Have you checked this for 32 bit as well as 64?  Based on my math your
>>>> next patch will still mess up the memset on 32 bit with the structure
>>>> being split somewhere just in front of hwtstamps.
>>>>
>>>> Why not just take frags and move it to the start of the structure?  It
>>>> is already an unknown value because it can be either 16 or 17 depending
>>>> on the value of PAGE_SIZE, and since you are making changes to frags the
>>>> changes wouldn't impact the alignment of the other values later on since
>>>> you are aligning the end of the structure.  That way you would be
>>>> guaranteed that all of the fields that will be memset would be in the
>>>> last 64 bytes.
>>>>
>>> Now when a fragmented packet is copied in pskb_expand_head(), you access
>>> two separate zones of memory to copy the shinfo. But its supposed to be
>>> slow path.
>>>
>>> Problem with this is that the offsets of often used fields will be big
>>> (instead of being < 127) and code will be bigger on x86.
>> Actually now that I think about it my concerns go much further than the
>> memset.  I'm convinced that this is going to cause a pretty significant
>> performance regression on multiple drivers, especially on non x86_64
>> architecture.  What we have right now on most platforms is a
>> skb_shared_info structure in which everything up to and including frag 0
>> is all in one cache line.  This gives us pretty good performance for igb
>> and ixgbe since that is our common case when jumbo frames are not
>> enabled is to split the head and place the data in a page.
> With all the changes in this series it is still possible to fit a
> maximum standard MTU frame and the shinfo on the same 4K page while also
> have the skb_shared_info up to and including frag [0] aligned to the
> same 64 byte cache line. 
>
> The only exception is destructor_arg on 64 bit which is on the preceding
> cache line but that is not a field used in any hot path.
The problem I have is that this is only true on x86_64.  Proper work
hasn't been done to guarantee this on any other architectures.

I think what I would like to see is instead of just setting things up
and hoping it comes out cache aligned on nr_frags why not take steps to
guarantee it?  You could do something like place and size the structure
based on:
SKB_DATA_ALIGN(sizeof(skb_shared_info) - offsetof(struct
skb_shared_info, nr_frags)) + offsetof(struct skb_shared_info, nr_frags)

That way you would have your alignment still guaranteed based off of the
end of the structure, but anything placed before nr_frags would be
placed on the end of the previous cache line.

>> However the change being recommend here only resolves the issue for one
>> specific architecture, and that is what I don't agree with.  What we
>> need is a solution that also works for 64K pages or 32 bit pointers and
>> I am fairly certain this current solution does not.
> I think it does work for 32 bit pointers. What issue to do you see with
> 64K pages?
>
> Ian.
With 64K pages the MAX_SKB_FRAGS value drops from 17 to 16.  That will
undoubtedly mess up the alignment.

Thanks,

Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:32:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Se-0004BG-QJ; Wed, 11 Apr 2012 16:32:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SI0Sc-0004Ax-Ut
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:31:59 +0000
Received: from [85.158.143.99:48298] by server-2.bemta-4.messagelabs.com id
	DB/42-17550-EF1B58F4; Wed, 11 Apr 2012 16:31:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334161915!24668735!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24032 invoked from network); 11 Apr 2012 16:31:56 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-216.messagelabs.com with SMTP;
	11 Apr 2012 16:31:56 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77054316; Wed, 11 Apr 2012 18:31:54 +0200
Message-ID: <1334161892.4298.6.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 11 Apr 2012 18:31:32 +0200
In-Reply-To: <4F85AC6C.10407@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<e63c137d9fc551ca941a.1334150268@Solace> <4F85AC6C.10407@eu.citrix.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize
 xenctl_cpumap to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============9153043721192644181=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============9153043721192644181==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Yvo8lG+g664ln3S22pCX"


--=-Yvo8lG+g664ln3S22pCX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 17:08 +0100, George Dunlap wrote:
> On 11/04/12 14:17, Dario Faggioli wrote:
> > In preparation for adding an xc_nodemap_t and its related
> > hadling logic. Just add one indirection layer, and try to
> > retain the interface as much as possible (although some
> > small bits here and there have been affected).
> This patch is fine with me on the whole (one comment below), but in this=
=20
> kind of a patch I think you need to include exactly what it is patch=20
> does.  I.e.:
>=20
> 1. Replace xenctl_cpumap with xenctl_map
> 2. Implement bitmap_to_xenctl_map and the reverse
> 3. Re-implement cpumask_to_xenctl_map with bitmap_to_xenctl_map and vice=
=20
> versa.
> 4. Other than #3, no functional changes.
>
Ok, I can do that when reposting (and for other similar patches as
well).

> > diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> > --- a/xen/include/xen/cpumask.h
> > +++ b/xen/include/xen/cpumask.h
> > @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
> >   #define for_each_present_cpu(cpu)  for_each_cpu(cpu,&cpu_present_map)
> >
> >   /* Copy to/from cpumap provided by control tools. */
> > -struct xenctl_cpumap;
> > -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *=
);
> > -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpum=
ap *);
> > +struct xenctl_map;
> > +int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *);
> > +int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_map =
*);
> You should probably s/cpumap/map/; in the function names as well.
>
Well, I retained the old name as the callers expect to use these
functions as that old name says, i.e., passing a cpumap and wanting a
cpumask back (for the first one). Thus, I was trying to avoid affecting
callers, exploiting the fact that xenctl_cpumap is a typedef to
libxl_map after all.

However, if that is too ugly, I surely can change function names, as
well as provide one more layer of indirection (xenctl_cpumap_to_cpumask
calling xenctl_map_to_cpumask). Just let me know what you prefer. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Yvo8lG+g664ln3S22pCX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+FseQACgkQk4XaBE3IOsRW+QCdG/jSKjPRef3tSgAuJqm+xZNe
vwsAn0pSH+gaD+ITmP8JMKsOj2ANVIrN
=Dl21
-----END PGP SIGNATURE-----

--=-Yvo8lG+g664ln3S22pCX--



--===============9153043721192644181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9153043721192644181==--



From xen-devel-bounces@lists.xen.org Wed Apr 11 16:32:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0Se-0004BG-QJ; Wed, 11 Apr 2012 16:32:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SI0Sc-0004Ax-Ut
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:31:59 +0000
Received: from [85.158.143.99:48298] by server-2.bemta-4.messagelabs.com id
	DB/42-17550-EF1B58F4; Wed, 11 Apr 2012 16:31:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334161915!24668735!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24032 invoked from network); 11 Apr 2012 16:31:56 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-216.messagelabs.com with SMTP;
	11 Apr 2012 16:31:56 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77054316; Wed, 11 Apr 2012 18:31:54 +0200
Message-ID: <1334161892.4298.6.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 11 Apr 2012 18:31:32 +0200
In-Reply-To: <4F85AC6C.10407@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<e63c137d9fc551ca941a.1334150268@Solace> <4F85AC6C.10407@eu.citrix.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize
 xenctl_cpumap to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============9153043721192644181=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============9153043721192644181==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Yvo8lG+g664ln3S22pCX"


--=-Yvo8lG+g664ln3S22pCX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 17:08 +0100, George Dunlap wrote:
> On 11/04/12 14:17, Dario Faggioli wrote:
> > In preparation for adding an xc_nodemap_t and its related
> > hadling logic. Just add one indirection layer, and try to
> > retain the interface as much as possible (although some
> > small bits here and there have been affected).
> This patch is fine with me on the whole (one comment below), but in this=
=20
> kind of a patch I think you need to include exactly what it is patch=20
> does.  I.e.:
>=20
> 1. Replace xenctl_cpumap with xenctl_map
> 2. Implement bitmap_to_xenctl_map and the reverse
> 3. Re-implement cpumask_to_xenctl_map with bitmap_to_xenctl_map and vice=
=20
> versa.
> 4. Other than #3, no functional changes.
>
Ok, I can do that when reposting (and for other similar patches as
well).

> > diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> > --- a/xen/include/xen/cpumask.h
> > +++ b/xen/include/xen/cpumask.h
> > @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
> >   #define for_each_present_cpu(cpu)  for_each_cpu(cpu,&cpu_present_map)
> >
> >   /* Copy to/from cpumap provided by control tools. */
> > -struct xenctl_cpumap;
> > -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *=
);
> > -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpum=
ap *);
> > +struct xenctl_map;
> > +int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *);
> > +int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_map =
*);
> You should probably s/cpumap/map/; in the function names as well.
>
Well, I retained the old name as the callers expect to use these
functions as that old name says, i.e., passing a cpumap and wanting a
cpumask back (for the first one). Thus, I was trying to avoid affecting
callers, exploiting the fact that xenctl_cpumap is a typedef to
libxl_map after all.

However, if that is too ugly, I surely can change function names, as
well as provide one more layer of indirection (xenctl_cpumap_to_cpumask
calling xenctl_map_to_cpumask). Just let me know what you prefer. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Yvo8lG+g664ln3S22pCX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+FseQACgkQk4XaBE3IOsRW+QCdG/jSKjPRef3tSgAuJqm+xZNe
vwsAn0pSH+gaD+ITmP8JMKsOj2ANVIrN
=Dl21
-----END PGP SIGNATURE-----

--=-Yvo8lG+g664ln3S22pCX--



--===============9153043721192644181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9153043721192644181==--



From xen-devel-bounces@lists.xen.org Wed Apr 11 16:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0b2-0004gd-TJ; Wed, 11 Apr 2012 16:40:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SI0b1-0004gY-Jy
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:40:39 +0000
Received: from [85.158.139.83:4112] by server-10.bemta-5.messagelabs.com id
	D7/5E-08260-604B58F4; Wed, 11 Apr 2012 16:40:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334162435!23380169!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6090 invoked from network); 11 Apr 2012 16:40:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:40:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189871426"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:39:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:39:36 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SI0a0-00025y-EZ;
	Wed, 11 Apr 2012 17:39:36 +0100
Message-ID: <4F85B3A1.6030407@eu.citrix.com>
Date: Wed, 11 Apr 2012 17:38:57 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<2077d51764e0ff1e33a9.1334150270@Solace>
In-Reply-To: <2077d51764e0ff1e33a9.1334150270@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10 [RFC]] libxc,
 libxl: Introduce xc_nodemap_t and libxl_nodemap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> Exactly as we have xc_cpumap_t, something similar for representing
> NUMA nodes (i.e., xc_nodemap_t and nodemap_t) could be useful. The
> same applies to libxl_cpumap, which on its turn now has its
> node-related counterpart, libxl_nodemap.
>
> This is all in preparation for making it possible explicit
> specification of the `node affinity` of a guest.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
>
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -35,21 +35,49 @@ int xc_get_max_cpus(xc_interface *xch)
>       return max_cpus;
>   }
>
> +int xc_get_max_nodes(xc_interface *xch)
> +{
> +    static int max_nodes = 0;
> +    xc_physinfo_t physinfo;
> +
> +    if ( max_nodes )
> +        return max_nodes;
> +
> +    if ( !xc_physinfo(xch,&physinfo) )
> +        max_nodes = physinfo.max_node_id + 1;
> +
> +    return max_nodes;
> +}
> +
>   int xc_get_cpumap_size(xc_interface *xch)
>   {
>       return (xc_get_max_cpus(xch) + 7) / 8;
>   }
>
> -xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
> +int xc_get_nodemap_size(xc_interface *xch)
>   {
> -    int sz;
> +    return (xc_get_max_nodes(xch) + 7) / 8;
> +}
>
> -    sz = xc_get_cpumap_size(xch);
> +/* XXX See [*] below ... */
> +static xc_cpumap_t __xc_map_alloc(xc_interface *xch, int sz)
> +{
>       if (sz == 0)
>           return NULL;
>       return calloc(1, sz);
>   }
>
> +xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
> +{
> +    return __xc_map_alloc(xch, xc_get_cpumap_size(xch));
> +}
> +
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
> +{
> +    /* XXX [*] How bad is this? Ideas? */
> +    return (xc_nodemap_t) __xc_map_alloc(xch, xc_get_nodemap_size(xch));
> +}
> +
I don't think it's incredibly terrible if it would buy us something; but 
I don't really see that it does.  Two functions would be a lot more 
readable, IMHO.

Other than that, looks fine.
>   int xc_readconsolering(xc_interface *xch,
>                          char *buffer,
>                          unsigned int *pnr_chars,
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -330,6 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
>   xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
>
>   /*
> + * NODEMAP handling
> + */
> +typedef uint8_t *xc_nodemap_t;
> +
> +/* return maximum number of NUMA nodes the hypervisor supports */
> +int xc_get_max_nodes(xc_interface *xch);
> +
> +/* return array size for nodemap */
> +int xc_get_nodemap_size(xc_interface *xch);
> +
> +/* allocate a nodemap */
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch);
> +
> +/*
>    * DOMAIN DEBUGGING FUNCTIONS
>    */
>
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -486,11 +486,27 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
>       return libxl_map_alloc(ctx, cpumap, max_cpus);
>   }
>
> +int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap)
> +{
> +    int max_nodes;
> +
> +    max_nodes = libxl_get_max_nodes(ctx);
> +    if (max_nodes == 0)
> +        return ERROR_FAIL;
> +
> +    return libxl_map_alloc(ctx, nodemap, max_nodes);
> +}
> +
>   int libxl_get_max_cpus(libxl_ctx *ctx)
>   {
>       return xc_get_max_cpus(ctx->xch);
>   }
>
> +int libxl_get_max_nodes(libxl_ctx *ctx)
> +{
> +    return xc_get_max_nodes(ctx->xch);
> +}
> +
>   int libxl__enum_from_string(const libxl_enum_string_table *t,
>                               const char *s, int *e)
>   {
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -109,6 +109,35 @@ static inline int libxl_cpumap_cpu_valid
>   #define libxl_for_each_set_cpu(v, m) for (v = 0; v<  (m).size * 8; v++) \
>                                                if (libxl_cpumap_test(&(m), v))
>
> +int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap);
> +static inline int libxl_nodemap_test(libxl_nodemap *nodemap, int node)
> +{
> +    return libxl_map_test(nodemap, node);
> +}
> +static inline void libxl_nodemap_set(libxl_nodemap *nodemap, int node)
> +{
> +    libxl_map_set(nodemap, node);
> +}
> +static inline void libxl_nodemap_reset(libxl_nodemap *nodemap, int node)
> +{
> +    libxl_map_reset(nodemap, node);
> +}
> +static inline void libxl_nodemap_set_any(libxl_nodemap *nodemap)
> +{
> +    libxl_map_set_any(nodemap);
> +}
> +static inline void libxl_nodemap_set_none(libxl_nodemap *nodemap)
> +{
> +    libxl_map_set_none(nodemap);
> +}
> +static inline int libxl_nodemap_node_valid(libxl_nodemap *nodemap, int node)
> +{
> +    return libxl_map_elem_valid(nodemap, node);
> +}
> +#define libxl_for_each_node(var, map) for (var = 0; var<  (map).size * 8; var++)
> +#define libxl_for_each_set_node(v, m) for (v = 0; v<  (m).size * 8; v++) \
> +                                              if (libxl_nodemap_test(&(m), v))
> +
>   static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
>       return (s + 1023) / 1024;
>   }
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -116,6 +116,14 @@ int xenctl_cpumap_to_cpumask(cpumask_var
>       return err;
>   }
>
> +int xenctl_nodemap_to_nodemask(nodemask_t *nodemask,
> +                               const struct xenctl_map *xenctl_nodemap)
> +{
> +    return xenctl_map_to_bitmap(nodes_addr(*nodemask),
> +                                xenctl_nodemap,
> +                                MAX_NUMNODES);
> +}
> +
>   static inline int is_free_domid(domid_t dom)
>   {
>       struct domain *d;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0b2-0004gd-TJ; Wed, 11 Apr 2012 16:40:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SI0b1-0004gY-Jy
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:40:39 +0000
Received: from [85.158.139.83:4112] by server-10.bemta-5.messagelabs.com id
	D7/5E-08260-604B58F4; Wed, 11 Apr 2012 16:40:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334162435!23380169!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6090 invoked from network); 11 Apr 2012 16:40:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 16:40:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330923600"; d="scan'208";a="189871426"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 12:39:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 12:39:36 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SI0a0-00025y-EZ;
	Wed, 11 Apr 2012 17:39:36 +0100
Message-ID: <4F85B3A1.6030407@eu.citrix.com>
Date: Wed, 11 Apr 2012 17:38:57 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<2077d51764e0ff1e33a9.1334150270@Solace>
In-Reply-To: <2077d51764e0ff1e33a9.1334150270@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10 [RFC]] libxc,
 libxl: Introduce xc_nodemap_t and libxl_nodemap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> Exactly as we have xc_cpumap_t, something similar for representing
> NUMA nodes (i.e., xc_nodemap_t and nodemap_t) could be useful. The
> same applies to libxl_cpumap, which on its turn now has its
> node-related counterpart, libxl_nodemap.
>
> This is all in preparation for making it possible explicit
> specification of the `node affinity` of a guest.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
>
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -35,21 +35,49 @@ int xc_get_max_cpus(xc_interface *xch)
>       return max_cpus;
>   }
>
> +int xc_get_max_nodes(xc_interface *xch)
> +{
> +    static int max_nodes = 0;
> +    xc_physinfo_t physinfo;
> +
> +    if ( max_nodes )
> +        return max_nodes;
> +
> +    if ( !xc_physinfo(xch,&physinfo) )
> +        max_nodes = physinfo.max_node_id + 1;
> +
> +    return max_nodes;
> +}
> +
>   int xc_get_cpumap_size(xc_interface *xch)
>   {
>       return (xc_get_max_cpus(xch) + 7) / 8;
>   }
>
> -xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
> +int xc_get_nodemap_size(xc_interface *xch)
>   {
> -    int sz;
> +    return (xc_get_max_nodes(xch) + 7) / 8;
> +}
>
> -    sz = xc_get_cpumap_size(xch);
> +/* XXX See [*] below ... */
> +static xc_cpumap_t __xc_map_alloc(xc_interface *xch, int sz)
> +{
>       if (sz == 0)
>           return NULL;
>       return calloc(1, sz);
>   }
>
> +xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
> +{
> +    return __xc_map_alloc(xch, xc_get_cpumap_size(xch));
> +}
> +
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
> +{
> +    /* XXX [*] How bad is this? Ideas? */
> +    return (xc_nodemap_t) __xc_map_alloc(xch, xc_get_nodemap_size(xch));
> +}
> +
I don't think it's incredibly terrible if it would buy us something; but 
I don't really see that it does.  Two functions would be a lot more 
readable, IMHO.

Other than that, looks fine.
>   int xc_readconsolering(xc_interface *xch,
>                          char *buffer,
>                          unsigned int *pnr_chars,
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -330,6 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
>   xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
>
>   /*
> + * NODEMAP handling
> + */
> +typedef uint8_t *xc_nodemap_t;
> +
> +/* return maximum number of NUMA nodes the hypervisor supports */
> +int xc_get_max_nodes(xc_interface *xch);
> +
> +/* return array size for nodemap */
> +int xc_get_nodemap_size(xc_interface *xch);
> +
> +/* allocate a nodemap */
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch);
> +
> +/*
>    * DOMAIN DEBUGGING FUNCTIONS
>    */
>
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -486,11 +486,27 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
>       return libxl_map_alloc(ctx, cpumap, max_cpus);
>   }
>
> +int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap)
> +{
> +    int max_nodes;
> +
> +    max_nodes = libxl_get_max_nodes(ctx);
> +    if (max_nodes == 0)
> +        return ERROR_FAIL;
> +
> +    return libxl_map_alloc(ctx, nodemap, max_nodes);
> +}
> +
>   int libxl_get_max_cpus(libxl_ctx *ctx)
>   {
>       return xc_get_max_cpus(ctx->xch);
>   }
>
> +int libxl_get_max_nodes(libxl_ctx *ctx)
> +{
> +    return xc_get_max_nodes(ctx->xch);
> +}
> +
>   int libxl__enum_from_string(const libxl_enum_string_table *t,
>                               const char *s, int *e)
>   {
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -109,6 +109,35 @@ static inline int libxl_cpumap_cpu_valid
>   #define libxl_for_each_set_cpu(v, m) for (v = 0; v<  (m).size * 8; v++) \
>                                                if (libxl_cpumap_test(&(m), v))
>
> +int libxl_nodemap_alloc(libxl_ctx *ctx, libxl_nodemap *nodemap);
> +static inline int libxl_nodemap_test(libxl_nodemap *nodemap, int node)
> +{
> +    return libxl_map_test(nodemap, node);
> +}
> +static inline void libxl_nodemap_set(libxl_nodemap *nodemap, int node)
> +{
> +    libxl_map_set(nodemap, node);
> +}
> +static inline void libxl_nodemap_reset(libxl_nodemap *nodemap, int node)
> +{
> +    libxl_map_reset(nodemap, node);
> +}
> +static inline void libxl_nodemap_set_any(libxl_nodemap *nodemap)
> +{
> +    libxl_map_set_any(nodemap);
> +}
> +static inline void libxl_nodemap_set_none(libxl_nodemap *nodemap)
> +{
> +    libxl_map_set_none(nodemap);
> +}
> +static inline int libxl_nodemap_node_valid(libxl_nodemap *nodemap, int node)
> +{
> +    return libxl_map_elem_valid(nodemap, node);
> +}
> +#define libxl_for_each_node(var, map) for (var = 0; var<  (map).size * 8; var++)
> +#define libxl_for_each_set_node(v, m) for (v = 0; v<  (m).size * 8; v++) \
> +                                              if (libxl_nodemap_test(&(m), v))
> +
>   static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
>       return (s + 1023) / 1024;
>   }
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -116,6 +116,14 @@ int xenctl_cpumap_to_cpumask(cpumask_var
>       return err;
>   }
>
> +int xenctl_nodemap_to_nodemask(nodemask_t *nodemask,
> +                               const struct xenctl_map *xenctl_nodemap)
> +{
> +    return xenctl_map_to_bitmap(nodes_addr(*nodemask),
> +                                xenctl_nodemap,
> +                                MAX_NUMNODES);
> +}
> +
>   static inline int is_free_domid(domid_t dom)
>   {
>       struct domain *d;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 16:42:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:42:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0cC-0004ml-Hk; Wed, 11 Apr 2012 16:41:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SI0cB-0004mV-26
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:41:51 +0000
Received: from [85.158.139.83:59566] by server-11.bemta-5.messagelabs.com id
	8F/96-12959-E44B58F4; Wed, 11 Apr 2012 16:41:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334162509!23380349!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9486 invoked from network); 11 Apr 2012 16:41:49 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-182.messagelabs.com with SMTP;
	11 Apr 2012 16:41:49 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77054519; Wed, 11 Apr 2012 18:41:48 +0200
Message-ID: <1334162502.4298.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 11 Apr 2012 18:41:42 +0200
In-Reply-To: <1334161892.4298.6.camel@Solace>
References: <patchbomb.1334150267@Solace>
	<e63c137d9fc551ca941a.1334150268@Solace> <4F85AC6C.10407@eu.citrix.com>
	<1334161892.4298.6.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize
 xenctl_cpumap to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6423222687116352340=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6423222687116352340==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-hXcuUwNBz82cyq7ZBdSR"


--=-hXcuUwNBz82cyq7ZBdSR
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 18:31 +0200, Dario Faggioli wrote:
> > >   /* Copy to/from cpumap provided by control tools. */
> > > -struct xenctl_cpumap;
> > > -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t=
 *);
> > > -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cp=
umap *);
> > > +struct xenctl_map;
> > > +int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *)=
;
> > > +int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_ma=
p *);
> > You should probably s/cpumap/map/; in the function names as well.
> >
> Well, I retained the old name as the callers expect to use these
> functions as that old name says, i.e., passing a cpumap and wanting a
> cpumask back (for the first one).=20
I obviously meant for the _second_ one here. :-P

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-hXcuUwNBz82cyq7ZBdSR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+FtEYACgkQk4XaBE3IOsRYIACeIduuBYK3e8mR02PHmccwdW9+
hPkAoKdyXwO0mPcpFFI1hBZA+NNblDiz
=gU0H
-----END PGP SIGNATURE-----

--=-hXcuUwNBz82cyq7ZBdSR--



--===============6423222687116352340==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6423222687116352340==--



From xen-devel-bounces@lists.xen.org Wed Apr 11 16:42:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:42:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0cC-0004ml-Hk; Wed, 11 Apr 2012 16:41:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SI0cB-0004mV-26
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:41:51 +0000
Received: from [85.158.139.83:59566] by server-11.bemta-5.messagelabs.com id
	8F/96-12959-E44B58F4; Wed, 11 Apr 2012 16:41:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334162509!23380349!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9486 invoked from network); 11 Apr 2012 16:41:49 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-182.messagelabs.com with SMTP;
	11 Apr 2012 16:41:49 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77054519; Wed, 11 Apr 2012 18:41:48 +0200
Message-ID: <1334162502.4298.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 11 Apr 2012 18:41:42 +0200
In-Reply-To: <1334161892.4298.6.camel@Solace>
References: <patchbomb.1334150267@Solace>
	<e63c137d9fc551ca941a.1334150268@Solace> <4F85AC6C.10407@eu.citrix.com>
	<1334161892.4298.6.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 01 of 10 [RFC]] libxc: Generalize
 xenctl_cpumap to just xenctl_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6423222687116352340=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6423222687116352340==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-hXcuUwNBz82cyq7ZBdSR"


--=-hXcuUwNBz82cyq7ZBdSR
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 18:31 +0200, Dario Faggioli wrote:
> > >   /* Copy to/from cpumap provided by control tools. */
> > > -struct xenctl_cpumap;
> > > -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t=
 *);
> > > -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cp=
umap *);
> > > +struct xenctl_map;
> > > +int cpumask_to_xenctl_cpumap(struct xenctl_map *, const cpumask_t *)=
;
> > > +int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_ma=
p *);
> > You should probably s/cpumap/map/; in the function names as well.
> >
> Well, I retained the old name as the callers expect to use these
> functions as that old name says, i.e., passing a cpumap and wanting a
> cpumask back (for the first one).=20
I obviously meant for the _second_ one here. :-P

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-hXcuUwNBz82cyq7ZBdSR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+FtEYACgkQk4XaBE3IOsRYIACeIduuBYK3e8mR02PHmccwdW9+
hPkAoKdyXwO0mPcpFFI1hBZA+NNblDiz
=gU0H
-----END PGP SIGNATURE-----

--=-hXcuUwNBz82cyq7ZBdSR--



--===============6423222687116352340==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6423222687116352340==--



From xen-devel-bounces@lists.xen.org Wed Apr 11 16:58:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0rv-0005EA-51; Wed, 11 Apr 2012 16:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SI0rt-0005E5-4l
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:58:05 +0000
Received: from [85.158.138.51:35693] by server-3.bemta-3.messagelabs.com id
	71/E0-04048-C18B58F4; Wed, 11 Apr 2012 16:58:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334163483!19908570!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9879 invoked from network); 11 Apr 2012 16:58:03 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-174.messagelabs.com with SMTP;
	11 Apr 2012 16:58:03 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77055064; Wed, 11 Apr 2012 18:58:02 +0200
Message-ID: <1334163476.4298.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 11 Apr 2012 18:57:56 +0200
In-Reply-To: <4F85B3A1.6030407@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<2077d51764e0ff1e33a9.1334150270@Solace>
	<4F85B3A1.6030407@eu.citrix.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10 [RFC]] libxc,
 libxl: Introduce xc_nodemap_t and libxl_nodemap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4861366389204197605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4861366389204197605==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-wDjTQQhOKGo3CnD563Dr"


--=-wDjTQQhOKGo3CnD563Dr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 17:38 +0100, George Dunlap wrote:
> > -    sz =3D xc_get_cpumap_size(xch);
> > +/* XXX See [*] below ... */
> > +static xc_cpumap_t __xc_map_alloc(xc_interface *xch, int sz)
> > +{
> >       if (sz =3D=3D 0)
> >           return NULL;
> >       return calloc(1, sz);
> >   }
> >
> > +xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
> > +{
> > +    return __xc_map_alloc(xch, xc_get_cpumap_size(xch));
> > +}
> > +
> > +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
> > +{
> > +    /* XXX [*] How bad is this? Ideas? */
> > +    return (xc_nodemap_t) __xc_map_alloc(xch, xc_get_nodemap_size(xch)=
);
> > +}
> > +
> I don't think it's incredibly terrible if it would buy us something; but=
=20
> I don't really see that it does. =20
>
Fine. :-)

> Two functions would be a lot more=20
> readable, IMHO.
>=20
I'm not entirely sure I see what you mean with "two functions". The main
issue here is __xc_map_alloc returning an xc_cpumap_t. BTW, reading your
comment it came to my mind that something like the below (removing
__xc_map_alloc, which after all, is very small!) would be better... Was
it this what you had in mind when talking about two functions?

xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
{
    if (sz =3D=3D 0)
        return NULL;
    return calloc(1, sz);
}

xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
{
    if (sz =3D=3D 0)
        return NULL;
    return calloc(1, sz);
}


> Other than that, looks fine.
>
Thanks for looking into this so quickly! :-P

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-wDjTQQhOKGo3CnD563Dr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+FuBQACgkQk4XaBE3IOsTA/wCgosdXq90saF30WEkd5TguOtiC
6CEAn1GDQDx3ckbuo3bIsEt88t1NNRYT
=w3DM
-----END PGP SIGNATURE-----

--=-wDjTQQhOKGo3CnD563Dr--



--===============4861366389204197605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4861366389204197605==--



From xen-devel-bounces@lists.xen.org Wed Apr 11 16:58:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 16:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0rv-0005EA-51; Wed, 11 Apr 2012 16:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SI0rt-0005E5-4l
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 16:58:05 +0000
Received: from [85.158.138.51:35693] by server-3.bemta-3.messagelabs.com id
	71/E0-04048-C18B58F4; Wed, 11 Apr 2012 16:58:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334163483!19908570!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9879 invoked from network); 11 Apr 2012 16:58:03 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-174.messagelabs.com with SMTP;
	11 Apr 2012 16:58:03 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77055064; Wed, 11 Apr 2012 18:58:02 +0200
Message-ID: <1334163476.4298.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Wed, 11 Apr 2012 18:57:56 +0200
In-Reply-To: <4F85B3A1.6030407@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<2077d51764e0ff1e33a9.1334150270@Solace>
	<4F85B3A1.6030407@eu.citrix.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10 [RFC]] libxc,
 libxl: Introduce xc_nodemap_t and libxl_nodemap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4861366389204197605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4861366389204197605==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-wDjTQQhOKGo3CnD563Dr"


--=-wDjTQQhOKGo3CnD563Dr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 17:38 +0100, George Dunlap wrote:
> > -    sz =3D xc_get_cpumap_size(xch);
> > +/* XXX See [*] below ... */
> > +static xc_cpumap_t __xc_map_alloc(xc_interface *xch, int sz)
> > +{
> >       if (sz =3D=3D 0)
> >           return NULL;
> >       return calloc(1, sz);
> >   }
> >
> > +xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
> > +{
> > +    return __xc_map_alloc(xch, xc_get_cpumap_size(xch));
> > +}
> > +
> > +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
> > +{
> > +    /* XXX [*] How bad is this? Ideas? */
> > +    return (xc_nodemap_t) __xc_map_alloc(xch, xc_get_nodemap_size(xch)=
);
> > +}
> > +
> I don't think it's incredibly terrible if it would buy us something; but=
=20
> I don't really see that it does. =20
>
Fine. :-)

> Two functions would be a lot more=20
> readable, IMHO.
>=20
I'm not entirely sure I see what you mean with "two functions". The main
issue here is __xc_map_alloc returning an xc_cpumap_t. BTW, reading your
comment it came to my mind that something like the below (removing
__xc_map_alloc, which after all, is very small!) would be better... Was
it this what you had in mind when talking about two functions?

xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
{
    if (sz =3D=3D 0)
        return NULL;
    return calloc(1, sz);
}

xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
{
    if (sz =3D=3D 0)
        return NULL;
    return calloc(1, sz);
}


> Other than that, looks fine.
>
Thanks for looking into this so quickly! :-P

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-wDjTQQhOKGo3CnD563Dr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+FuBQACgkQk4XaBE3IOsTA/wCgosdXq90saF30WEkd5TguOtiC
6CEAn1GDQDx3ckbuo3bIsEt88t1NNRYT
=w3DM
-----END PGP SIGNATURE-----

--=-wDjTQQhOKGo3CnD563Dr--



--===============4861366389204197605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4861366389204197605==--



From xen-devel-bounces@lists.xen.org Wed Apr 11 17:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 17:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0uj-0005Ln-Nj; Wed, 11 Apr 2012 17:01:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SI0ui-0005Li-V0
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 17:01:01 +0000
Received: from [85.158.139.83:45908] by server-10.bemta-5.messagelabs.com id
	18/22-08260-CC8B58F4; Wed, 11 Apr 2012 17:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334163658!19116466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6798 invoked from network); 11 Apr 2012 17:00:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 17:00:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11884226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 17:00:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 18:00:57 +0100
Message-ID: <1334163656.16387.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 11 Apr 2012 18:00:56 +0100
In-Reply-To: <4F85B1EA.9000600@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
	<1334131241.12209.199.camel@dagon.hellion.org.uk>
	<4F85B1EA.9000600@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:31 +0100, Alexander Duyck wrote:
> On 04/11/2012 01:00 AM, Ian Campbell wrote:
> > On Tue, 2012-04-10 at 20:15 +0100, Alexander Duyck wrote:
> >> On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> >>> On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
> >>>
> >>>> Have you checked this for 32 bit as well as 64?  Based on my math your
> >>>> next patch will still mess up the memset on 32 bit with the structure
> >>>> being split somewhere just in front of hwtstamps.
> >>>>
> >>>> Why not just take frags and move it to the start of the structure?  It
> >>>> is already an unknown value because it can be either 16 or 17 depending
> >>>> on the value of PAGE_SIZE, and since you are making changes to frags the
> >>>> changes wouldn't impact the alignment of the other values later on since
> >>>> you are aligning the end of the structure.  That way you would be
> >>>> guaranteed that all of the fields that will be memset would be in the
> >>>> last 64 bytes.
> >>>>
> >>> Now when a fragmented packet is copied in pskb_expand_head(), you access
> >>> two separate zones of memory to copy the shinfo. But its supposed to be
> >>> slow path.
> >>>
> >>> Problem with this is that the offsets of often used fields will be big
> >>> (instead of being < 127) and code will be bigger on x86.
> >> Actually now that I think about it my concerns go much further than the
> >> memset.  I'm convinced that this is going to cause a pretty significant
> >> performance regression on multiple drivers, especially on non x86_64
> >> architecture.  What we have right now on most platforms is a
> >> skb_shared_info structure in which everything up to and including frag 0
> >> is all in one cache line.  This gives us pretty good performance for igb
> >> and ixgbe since that is our common case when jumbo frames are not
> >> enabled is to split the head and place the data in a page.
> > With all the changes in this series it is still possible to fit a
> > maximum standard MTU frame and the shinfo on the same 4K page while also
> > have the skb_shared_info up to and including frag [0] aligned to the
> > same 64 byte cache line. 
> >
> > The only exception is destructor_arg on 64 bit which is on the preceding
> > cache line but that is not a field used in any hot path.
> The problem I have is that this is only true on x86_64.  Proper work
> hasn't been done to guarantee this on any other architectures.

FWIW I did also explicitly cover i386 (see
<1334130984.12209.195.camel@dagon.hellion.org.uk>)

> I think what I would like to see is instead of just setting things up
> and hoping it comes out cache aligned on nr_frags why not take steps to
> guarantee it?  You could do something like place and size the structure
> based on:
> SKB_DATA_ALIGN(sizeof(skb_shared_info) - offsetof(struct
> skb_shared_info, nr_frags)) + offsetof(struct skb_shared_info, nr_frags)
> 
> That way you would have your alignment still guaranteed based off of the
> end of the structure, but anything placed before nr_frags would be
> placed on the end of the previous cache line.
> 
> >> However the change being recommend here only resolves the issue for one
> >> specific architecture, and that is what I don't agree with.  What we
> >> need is a solution that also works for 64K pages or 32 bit pointers and
> >> I am fairly certain this current solution does not.
> > I think it does work for 32 bit pointers. What issue to do you see with
> > 64K pages?
> >
> > Ian.
> With 64K pages the MAX_SKB_FRAGS value drops from 17 to 16.  That will
> undoubtedly mess up the alignment.

Oh, I see. Need to think about this some more but your suggestion above
is an interesting one, I'll see what I can do with that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 17:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 17:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI0uj-0005Ln-Nj; Wed, 11 Apr 2012 17:01:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SI0ui-0005Li-V0
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 17:01:01 +0000
Received: from [85.158.139.83:45908] by server-10.bemta-5.messagelabs.com id
	18/22-08260-CC8B58F4; Wed, 11 Apr 2012 17:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334163658!19116466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6798 invoked from network); 11 Apr 2012 17:00:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 17:00:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11884226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 17:00:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 18:00:57 +0100
Message-ID: <1334163656.16387.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 11 Apr 2012 18:00:56 +0100
In-Reply-To: <4F85B1EA.9000600@intel.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
	<4F847CF9.3090701@intel.com>
	<1334083265.5300.288.camel@edumazet-glaptop>
	<4F8486E7.5050604@intel.com>
	<1334131241.12209.199.camel@dagon.hellion.org.uk>
	<4F85B1EA.9000600@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>, "Michael S.
	Tsirkin" <mst@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front
	of sk_buff.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:31 +0100, Alexander Duyck wrote:
> On 04/11/2012 01:00 AM, Ian Campbell wrote:
> > On Tue, 2012-04-10 at 20:15 +0100, Alexander Duyck wrote:
> >> On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> >>> On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
> >>>
> >>>> Have you checked this for 32 bit as well as 64?  Based on my math your
> >>>> next patch will still mess up the memset on 32 bit with the structure
> >>>> being split somewhere just in front of hwtstamps.
> >>>>
> >>>> Why not just take frags and move it to the start of the structure?  It
> >>>> is already an unknown value because it can be either 16 or 17 depending
> >>>> on the value of PAGE_SIZE, and since you are making changes to frags the
> >>>> changes wouldn't impact the alignment of the other values later on since
> >>>> you are aligning the end of the structure.  That way you would be
> >>>> guaranteed that all of the fields that will be memset would be in the
> >>>> last 64 bytes.
> >>>>
> >>> Now when a fragmented packet is copied in pskb_expand_head(), you access
> >>> two separate zones of memory to copy the shinfo. But its supposed to be
> >>> slow path.
> >>>
> >>> Problem with this is that the offsets of often used fields will be big
> >>> (instead of being < 127) and code will be bigger on x86.
> >> Actually now that I think about it my concerns go much further than the
> >> memset.  I'm convinced that this is going to cause a pretty significant
> >> performance regression on multiple drivers, especially on non x86_64
> >> architecture.  What we have right now on most platforms is a
> >> skb_shared_info structure in which everything up to and including frag 0
> >> is all in one cache line.  This gives us pretty good performance for igb
> >> and ixgbe since that is our common case when jumbo frames are not
> >> enabled is to split the head and place the data in a page.
> > With all the changes in this series it is still possible to fit a
> > maximum standard MTU frame and the shinfo on the same 4K page while also
> > have the skb_shared_info up to and including frag [0] aligned to the
> > same 64 byte cache line. 
> >
> > The only exception is destructor_arg on 64 bit which is on the preceding
> > cache line but that is not a field used in any hot path.
> The problem I have is that this is only true on x86_64.  Proper work
> hasn't been done to guarantee this on any other architectures.

FWIW I did also explicitly cover i386 (see
<1334130984.12209.195.camel@dagon.hellion.org.uk>)

> I think what I would like to see is instead of just setting things up
> and hoping it comes out cache aligned on nr_frags why not take steps to
> guarantee it?  You could do something like place and size the structure
> based on:
> SKB_DATA_ALIGN(sizeof(skb_shared_info) - offsetof(struct
> skb_shared_info, nr_frags)) + offsetof(struct skb_shared_info, nr_frags)
> 
> That way you would have your alignment still guaranteed based off of the
> end of the structure, but anything placed before nr_frags would be
> placed on the end of the previous cache line.
> 
> >> However the change being recommend here only resolves the issue for one
> >> specific architecture, and that is what I don't agree with.  What we
> >> need is a solution that also works for 64K pages or 32 bit pointers and
> >> I am fairly certain this current solution does not.
> > I think it does work for 32 bit pointers. What issue to do you see with
> > 64K pages?
> >
> > Ian.
> With 64K pages the MAX_SKB_FRAGS value drops from 17 to 16.  That will
> undoubtedly mess up the alignment.

Oh, I see. Need to think about this some more but your suggestion above
is an interesting one, I'll see what I can do with that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 17:07:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 17:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI10o-0005XQ-Gb; Wed, 11 Apr 2012 17:07:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SI10m-0005XL-UN
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 17:07:17 +0000
Received: from [85.158.143.99:31347] by server-1.bemta-4.messagelabs.com id
	B1/59-20925-44AB58F4; Wed, 11 Apr 2012 17:07:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334164034!23185494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 11 Apr 2012 17:07:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 17:07:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11884328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 17:07:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 18:07:14 +0100
Message-ID: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 11 Apr 2012 18:07:12 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It seems like it has been quite a while since our last stable branch
releases.

Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
deep into the 4.2 release closedown?

Perhaps we could do a first rc of each in the next few weeks?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 17:07:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 17:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI10o-0005XQ-Gb; Wed, 11 Apr 2012 17:07:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SI10m-0005XL-UN
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 17:07:17 +0000
Received: from [85.158.143.99:31347] by server-1.bemta-4.messagelabs.com id
	B1/59-20925-44AB58F4; Wed, 11 Apr 2012 17:07:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334164034!23185494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 11 Apr 2012 17:07:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 17:07:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11884328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 17:07:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 18:07:14 +0100
Message-ID: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 11 Apr 2012 18:07:12 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It seems like it has been quite a while since our last stable branch
releases.

Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
deep into the 4.2 release closedown?

Perhaps we could do a first rc of each in the next few weeks?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 18:15:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 18:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI24L-0006PY-6d; Wed, 11 Apr 2012 18:15:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1SI24K-0006PT-4e
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 18:15:00 +0000
Received: from [193.109.254.147:27872] by server-9.bemta-14.messagelabs.com id
	44/CA-05787-32AC58F4; Wed, 11 Apr 2012 18:14:59 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334168097!4149915!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI0MTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 11 Apr 2012 18:14:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	11 Apr 2012 18:14:57 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3BIEMcW028230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 14:14:51 -0400
Received: from [10.3.113.67] (ovpn-113-67.phx2.redhat.com [10.3.113.67])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3BH2TO2012691; Wed, 11 Apr 2012 13:02:29 -0400
Message-ID: <4F85B925.6090309@redhat.com>
Date: Wed, 11 Apr 2012 11:02:29 -0600
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
X-Enigmail-Version: 1.4
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Peter Maydell <peter.maydell@linaro.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5098293497836524362=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5098293497836524362==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------enig48A3C93D697B15A24490ABE9"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig48A3C93D697B15A24490ABE9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 04/11/2012 10:17 AM, Stefano Stabellini wrote:
> On Wed, 11 Apr 2012, Peter Maydell wrote:
>> On 5 April 2012 10:35, Wei Liu <wei.liu2@citrix.com> wrote:
>>>
>>> --- /dev/null
>>> +++ b/hw/xen_apic.c
>>> @@ -0,0 +1,90 @@
>>> +/*
>>> + * Xen basic APIC support
>>> + *
>>> + * Copyright (c) 2012 Citrix
>>> + *
>>> + * Authors:
>>> + *  Wei Liu <wei.liu2@citrix.com>
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL version 2.
>>> + * See the COPYING file in the top-level directory.
>>> + */
>>
>> Really 2-only, not 2-or-later ?
>=20
> I am not a great fun of the 2-or-later clause and it doesn't look like =
a
> requirement from the QEMU project POV. However if it is, I'll change it=

> to 2-or-later.

Conversely, I am not a great fan of the 2-only clause, as it prevents
reuse of qemu code in other projects.  There's a reason that qemu is now
favoring 2-or-later for new submissions.

http://wiki.qemu.org/Relicensing

--=20
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--------------enig48A3C93D697B15A24490ABE9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJPhbklAAoJEKeha0olJ0NqTaUH/A5Yf1FVOYMrwhWpjlmhB99c
Lxi5urGvgIeG8wFLjqcGdGm3yx3xV99dWNo1Y0of9gH4tBpnmS77WcRjBVp46oQP
XVLH4Wm0D8lDaKA0EHLANLx5uQ6Vh4IzrlQPWjVAS8QezJCq2T920GWHVEkqcI4H
SFXYA0ESXF48xmE1pNe0Z6krv8MjZojw/SEJ/fIRBp1EW0+P/9FYE2CfIDLkfRCe
ttRWEJYra0eDcU2sjdE+GdhiWp+NRbeyvyyjlDmuicSFwD9UQ+Sk86tdXOxJMMlq
QmcTwg9nzHxgW7XE7snjUMXcZJfa0vnoxGM+YFB0LX8aocCANri10OEA+Rdyhg4=
=C5sm
-----END PGP SIGNATURE-----

--------------enig48A3C93D697B15A24490ABE9--


--===============5098293497836524362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5098293497836524362==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 18:15:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 18:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI24L-0006PY-6d; Wed, 11 Apr 2012 18:15:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eblake@redhat.com>) id 1SI24K-0006PT-4e
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 18:15:00 +0000
Received: from [193.109.254.147:27872] by server-9.bemta-14.messagelabs.com id
	44/CA-05787-32AC58F4; Wed, 11 Apr 2012 18:14:59 +0000
X-Env-Sender: eblake@redhat.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334168097!4149915!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI0MTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 11 Apr 2012 18:14:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	11 Apr 2012 18:14:57 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3BIEMcW028230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 14:14:51 -0400
Received: from [10.3.113.67] (ovpn-113-67.phx2.redhat.com [10.3.113.67])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3BH2TO2012691; Wed, 11 Apr 2012 13:02:29 -0400
Message-ID: <4F85B925.6090309@redhat.com>
Date: Wed, 11 Apr 2012 11:02:29 -0600
From: Eric Blake <eblake@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
X-Enigmail-Version: 1.4
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Peter Maydell <peter.maydell@linaro.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"liuw@liuw.name" <liuw@liuw.name>, Jan Kiszka <jan.kiszka@siemens.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
 and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5098293497836524362=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5098293497836524362==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------enig48A3C93D697B15A24490ABE9"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig48A3C93D697B15A24490ABE9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 04/11/2012 10:17 AM, Stefano Stabellini wrote:
> On Wed, 11 Apr 2012, Peter Maydell wrote:
>> On 5 April 2012 10:35, Wei Liu <wei.liu2@citrix.com> wrote:
>>>
>>> --- /dev/null
>>> +++ b/hw/xen_apic.c
>>> @@ -0,0 +1,90 @@
>>> +/*
>>> + * Xen basic APIC support
>>> + *
>>> + * Copyright (c) 2012 Citrix
>>> + *
>>> + * Authors:
>>> + *  Wei Liu <wei.liu2@citrix.com>
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL version 2.
>>> + * See the COPYING file in the top-level directory.
>>> + */
>>
>> Really 2-only, not 2-or-later ?
>=20
> I am not a great fun of the 2-or-later clause and it doesn't look like =
a
> requirement from the QEMU project POV. However if it is, I'll change it=

> to 2-or-later.

Conversely, I am not a great fan of the 2-only clause, as it prevents
reuse of qemu code in other projects.  There's a reason that qemu is now
favoring 2-or-later for new submissions.

http://wiki.qemu.org/Relicensing

--=20
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--------------enig48A3C93D697B15A24490ABE9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJPhbklAAoJEKeha0olJ0NqTaUH/A5Yf1FVOYMrwhWpjlmhB99c
Lxi5urGvgIeG8wFLjqcGdGm3yx3xV99dWNo1Y0of9gH4tBpnmS77WcRjBVp46oQP
XVLH4Wm0D8lDaKA0EHLANLx5uQ6Vh4IzrlQPWjVAS8QezJCq2T920GWHVEkqcI4H
SFXYA0ESXF48xmE1pNe0Z6krv8MjZojw/SEJ/fIRBp1EW0+P/9FYE2CfIDLkfRCe
ttRWEJYra0eDcU2sjdE+GdhiWp+NRbeyvyyjlDmuicSFwD9UQ+Sk86tdXOxJMMlq
QmcTwg9nzHxgW7XE7snjUMXcZJfa0vnoxGM+YFB0LX8aocCANri10OEA+Rdyhg4=
=C5sm
-----END PGP SIGNATURE-----

--------------enig48A3C93D697B15A24490ABE9--


--===============5098293497836524362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5098293497836524362==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 18:42:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 18:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI2UG-0006kK-Fd; Wed, 11 Apr 2012 18:41:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SI2UE-0006kD-J6
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 18:41:46 +0000
Received: from [85.158.143.35:6545] by server-1.bemta-4.messagelabs.com id
	FB/EC-20925-960D58F4; Wed, 11 Apr 2012 18:41:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334169703!12004443!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18215 invoked from network); 11 Apr 2012 18:41:43 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 18:41:43 -0000
Received: by wgbed3 with SMTP id ed3so902547wgb.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 11:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=qUiF11ZcL718dEVLhnLLCg4FHH+qiM6ZBBxcS9YO0I0=;
	b=cGgeO99/7jwrXcJ+4ieCdyw+wYJmALLOctCdGSz+LtxdTwb4ai+XbzAC/ryUyvaLDT
	lHuj2mc1QPxligWvG/nCvXYFtRRIw/UQV1wT0Zi01yiRxl9pGPzxZjLXIIwaXj91ywNH
	qN5bKMJ1vcrvTpaKzvAWqkxiLjK4Jw3lex52KHq0Ey3S4oVtJYzsb6+EF+doCrLndFzg
	2czBKucjajYKK3qzwMvLL6R0r2Wy8TR0Xl1KJOeTojvZeeJE82kzewnDpiK7tbBSopEU
	yrC8liE+J/Bm4tGVlijmuDHYbMDN9wBUdHplu3fRSqu4QWYbmimXhJXvAWI1Lr4xS4wm
	HZBQ==
Received: by 10.180.79.72 with SMTP id h8mr9125927wix.1.1334169703161;
	Wed, 11 Apr 2012 11:41:43 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id ea6sm46669366wib.5.2012.04.11.11.41.41
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 11:41:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Apr 2012 19:41:36 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBAB8EF0.3D982%keir@xen.org>
Thread-Topic: Stable branch releases?
Thread-Index: Ac0YErk+ejfDqSv7Gk2o7S9lXf3ARA==
In-Reply-To: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2012 18:07, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> It seems like it has been quite a while since our last stable branch
> releases.
> 
> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
> deep into the 4.2 release closedown?
> 
> Perhaps we could do a first rc of each in the next few weeks?

Yes, it's about time.

 -- Keir

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 18:42:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 18:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI2UG-0006kK-Fd; Wed, 11 Apr 2012 18:41:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SI2UE-0006kD-J6
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 18:41:46 +0000
Received: from [85.158.143.35:6545] by server-1.bemta-4.messagelabs.com id
	FB/EC-20925-960D58F4; Wed, 11 Apr 2012 18:41:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334169703!12004443!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18215 invoked from network); 11 Apr 2012 18:41:43 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 18:41:43 -0000
Received: by wgbed3 with SMTP id ed3so902547wgb.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 11:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=qUiF11ZcL718dEVLhnLLCg4FHH+qiM6ZBBxcS9YO0I0=;
	b=cGgeO99/7jwrXcJ+4ieCdyw+wYJmALLOctCdGSz+LtxdTwb4ai+XbzAC/ryUyvaLDT
	lHuj2mc1QPxligWvG/nCvXYFtRRIw/UQV1wT0Zi01yiRxl9pGPzxZjLXIIwaXj91ywNH
	qN5bKMJ1vcrvTpaKzvAWqkxiLjK4Jw3lex52KHq0Ey3S4oVtJYzsb6+EF+doCrLndFzg
	2czBKucjajYKK3qzwMvLL6R0r2Wy8TR0Xl1KJOeTojvZeeJE82kzewnDpiK7tbBSopEU
	yrC8liE+J/Bm4tGVlijmuDHYbMDN9wBUdHplu3fRSqu4QWYbmimXhJXvAWI1Lr4xS4wm
	HZBQ==
Received: by 10.180.79.72 with SMTP id h8mr9125927wix.1.1334169703161;
	Wed, 11 Apr 2012 11:41:43 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id ea6sm46669366wib.5.2012.04.11.11.41.41
	(version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 11:41:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Apr 2012 19:41:36 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBAB8EF0.3D982%keir@xen.org>
Thread-Topic: Stable branch releases?
Thread-Index: Ac0YErk+ejfDqSv7Gk2o7S9lXf3ARA==
In-Reply-To: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/2012 18:07, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> It seems like it has been quite a while since our last stable branch
> releases.
> 
> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
> deep into the 4.2 release closedown?
> 
> Perhaps we could do a first rc of each in the next few weeks?

Yes, it's about time.

 -- Keir

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 18:46:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 18:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI2YM-0006rD-5g; Wed, 11 Apr 2012 18:46:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SI2YK-0006r8-Cf
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 18:46:00 +0000
Received: from [193.109.254.147:64606] by server-3.bemta-14.messagelabs.com id
	B4/74-23274-761D58F4; Wed, 11 Apr 2012 18:45:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334169959!1694585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 11 Apr 2012 18:45:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 18:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11885313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 18:45:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 19:45:36 +0100
Date: Wed, 11 Apr 2012 19:49:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
References: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 11 Apr 2012, Ian Campbell wrote:
> It seems like it has been quite a while since our last stable branch
> releases.
> 
> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
> deep into the 4.2 release closedown?
> 
> Perhaps we could do a first rc of each in the next few weeks?

I am keen on having these three patches in 4.1.3:

http://marc.info/?l=xen-devel&m=133251438030441

I asked Ian to backport them in a previous email.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 18:46:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 18:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI2YM-0006rD-5g; Wed, 11 Apr 2012 18:46:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SI2YK-0006r8-Cf
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 18:46:00 +0000
Received: from [193.109.254.147:64606] by server-3.bemta-14.messagelabs.com id
	B4/74-23274-761D58F4; Wed, 11 Apr 2012 18:45:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334169959!1694585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 11 Apr 2012 18:45:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 18:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="11885313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 18:45:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 19:45:36 +0100
Date: Wed, 11 Apr 2012 19:49:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
References: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 11 Apr 2012, Ian Campbell wrote:
> It seems like it has been quite a while since our last stable branch
> releases.
> 
> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
> deep into the 4.2 release closedown?
> 
> Perhaps we could do a first rc of each in the next few weeks?

I am keen on having these three patches in 4.1.3:

http://marc.info/?l=xen-devel&m=133251438030441

I asked Ian to backport them in a previous email.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 19:52:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 19:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI3aQ-0007MV-8x; Wed, 11 Apr 2012 19:52:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <atarutin@orionsbelt.net>) id 1SI3aM-0007MN-KP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 19:52:11 +0000
Received: from [85.158.143.35:40680] by server-3.bemta-4.messagelabs.com id
	1F/B2-05853-9E0E58F4; Wed, 11 Apr 2012 19:52:09 +0000
X-Env-Sender: atarutin@orionsbelt.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334173919!14099362!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10693 invoked from network); 11 Apr 2012 19:52:00 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 19:52:00 -0000
Received: by vbbfs19 with SMTP id fs19so1153605vbb.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 12:51:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=+zzlpDBP9c4CbcIxexmlwbfUNMfvdjAQp0028P+OydA=;
	b=MM1hH5pf3OlIs0bvaG5v6aaCeonjMrqbTwMSAyV/KfPm4XMzVRpPRrASWEVeSwoW5d
	vflfyTyj9BCd2MbKmCkMUd95PfFjKB6eV6mTH1jH0qsRaUHbl/aclOwAUT3KGsQTMkxf
	ogfldClqH3z7TUxxRic2D6wlT9gBfE47csEyLFtOAwvcbzUE7d5PXf449ol7VhP1Br3f
	XtEh0XLuK3D/6hKAd2hUK4jSMyj9BSkNVFtGy6acb7puGf1BCNCtswERDYfooB8U3YPJ
	O3K771WiLayIa6pvPfpt+1/xsDfwAI4UZZ1tjgGzYTNhAcQ1eEW+g3y9afhmLtLZ6plm
	fGwg==
Received: by 10.220.35.73 with SMTP id o9mr9064032vcd.74.1334173919355; Wed,
	11 Apr 2012 12:51:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.108.66 with HTTP; Wed, 11 Apr 2012 12:51:39 -0700 (PDT)
X-Originating-IP: [173.220.219.178]
From: Aleksandr Tarutin <atarutin@orionsbelt.net>
Date: Wed, 11 Apr 2012 15:51:39 -0400
Message-ID: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=485b393aaadf88221704bd6c92bc
X-Gm-Message-State: ALoCoQl+tceWkxUrnzdA5bzfHrzLsvSqNtFhgfh7ZGcW5Ub+IeRBhPEeZ322bE5j7TvbvUU3VlFV
Subject: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--485b393aaadf88221704bd6c92bc
Content-Type: multipart/alternative; boundary=485b393aaadf88220c04bd6c92ba

--485b393aaadf88220c04bd6c92ba
Content-Type: text/plain; charset=ISO-8859-1

Hello.

I tried to setup PCI Passthrough of a SAS controller into a PVHVM domU. The
device was present in the domU but its modules wouldn't load.

The first related thing was the following message in the guest BIOS just
before grub starts:
MPT BIOS Fault 09h encountered at adapter PCI(00h,05h,00h).

I'm attaching the xm dmesg and dmesg from both the host and a guest as well
as lspci -v.

-- 
AT.

--485b393aaadf88220c04bd6c92ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello.<div><br></div><div>I tried to setup PCI Passthrough of a SAS control=
ler into a PVHVM domU. The device was present in the domU but its modules w=
ouldn&#39;t load.</div><div><br></div><div>The first related thing was the =
following message in the guest BIOS just before grub starts:</div>

<div><div>MPT BIOS Fault 09h encountered at adapter=A0PCI(00h,05h,00h).</di=
v><div><br></div><div>I&#39;m attaching the xm dmesg and dmesg from both th=
e host and a guest as well as lspci -v.</div><div><br></div>-- <br><div>
AT.</div>
<br>
</div>

--485b393aaadf88220c04bd6c92ba--
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="dom0_dmesg.txt"
Content-Disposition: attachment; filename="dom0_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6940

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAgMC4w
MDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAwXSBMaW51
eCB2ZXJzaW9uIDMuMi4wLTIwLWdlbmVyaWMgKGJ1aWxkZEBhbGxzcGljZSkgKGdjYyB2ZXJzaW9u
IDQuNi4zIChVYnVudHUvTGluYXJvIDQuNi4zLTF1YnVudHUzKSApICMzMy1VYnVudHUgU01QIFR1
ZSBNYXIgMjcgMTY6NDI6MjYgVVRDIDIwMTIgKFVidW50dSAzLjIuMC0yMC4zMy1nZW5lcmljIDMu
Mi4xMikKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9kZXYv
bWFwcGVyL1ZTeXN0ZW0wMS1sdlhlbjAyIHJvIGVhcmx5cHJpbnRrPXhlbiBpbml0Y2FsbF9kZWJ1
ZyBkZWJ1ZyBsb2dsZXZlbD0xMCBtc2k9MQpbICAgIDAuMDAwMDAwXSBLRVJORUwgc3VwcG9ydGVk
IGNwdXM6ClsgICAgMC4wMDAwMDBdICAgSW50ZWwgR2VudWluZUludGVsClsgICAgMC4wMDAwMDBd
ICAgQU1EIEF1dGhlbnRpY0FNRApbICAgIDAuMDAwMDAwXSAgIENlbnRhdXIgQ2VudGF1ckhhdWxz
ClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgIDhkLTEwMCBwZm4gcmFuZ2U6IDExNSBwYWdlcyBmcmVl
ZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiA4ZC0+MTAwClsgICAgMC4wMDAwMDBdIDEt
MSBtYXBwaW5nIG9uIGJlN2E1LT5iZjRhZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBi
ZjRhZi0+YmY1NzYKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gYmY4MDAtPjEwMDAwMApb
ICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAxMTUgcGFnZXMgb2YgdW51c2VkIG1lbW9yeQpbICAgIDAu
MDAwMDAwXSBTZXQgMjY3ODQyIHBhZ2UocykgdG8gMS0xIG1hcHBpbmcKWyAgICAwLjAwMDAwMF0g
QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAw
MDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA4ZDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAg
WGVuOiAwMDAwMDAwMDAwMDhkMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpClsgICAg
MC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGJlN2E1MDAwICh1c2Fi
bGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYmU3YTUwMDAgLSAwMDAwMDAwMGJlN2Yx
MDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBiZTdmMTAwMCAtIDAw
MDAwMDAwYmU3ZjkwMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBi
ZTdmOTAwMCAtIDAwMDAwMDAwYmY0NzcwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVu
OiAwMDAwMDAwMGJmNDc3MDAwIC0gMDAwMDAwMDBiZjQ3ODAwMCAoQUNQSSBOVlMpClsgICAgMC4w
MDAwMDBdICBYZW46IDAwMDAwMDAwYmY0NzgwMDAgLSAwMDAwMDAwMGJmNDg5MDAwIChyZXNlcnZl
ZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBiZjQ4OTAwMCAtIDAwMDAwMDAwYmY0OGMw
MDAgKEFDUEkgTlZTKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmNDhjMDAwIC0gMDAw
MDAwMDBiZjRhZDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYmY0
YWQwMDAgLSAwMDAwMDAwMGJmNGFmMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAw
MDAwMDAwYmY0YWYwMDAgLSAwMDAwMDAwMGJmNTAzMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAw
MF0gIFhlbjogMDAwMDAwMDBiZjUwMzAwMCAtIDAwMDAwMDAwYmY1MGQwMDAgKEFDUEkgTlZTKQpb
ICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmNTBkMDAwIC0gMDAwMDAwMDBiZjUzMzAwMCAo
cmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYmY1MzMwMDAgLSAwMDAwMDAw
MGJmNTc2MDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBiZjU3NjAw
MCAtIDAwMDAwMDAwYmY4MDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAw
MDBmZWMwMDAwMCAtIDAwMDAwMDAwZmVjMDEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAg
WGVuOiAwMDAwMDAwMGZlZDFjMDAwIC0gMDAwMDAwMDBmZWQ0MDAwMCAocmVzZXJ2ZWQpClsgICAg
MC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNl
cnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZjAwMDAwMCAtIDAwMDAwMDAxMDAw
MDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0g
MDAwMDAwMDMwMTVjZjAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMzAx
NWNmMDAwIC0gMDAwMDAwMDQ0MDAwMDAwMCAodW51c2FibGUpClsgICAgMC4wMDAwMDBdIGJvb3Rj
b25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNh
YmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gRE1JIDIuNyBwcmVzZW50Lgpb
ICAgIDAuMDAwMDAwXSBETUk6IFN1cGVybWljcm8gWDlTQ0wvWDlTQ00vWDlTQ0wvWDlTQ00sIEJJ
T1MgMS4xYSAwOS8yOC8yMDExClsgICAgMC4wMDAwMDBdIGU4MjAgdXBkYXRlIHJhbmdlOiAwMDAw
MDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDAxMDAwMCAodXNhYmxlKSA9PT4gKHJlc2VydmVkKQpb
ICAgIDAuMDAwMDAwXSBlODIwIHJlbW92ZSByYW5nZTogMDAwMDAwMDAwMDBhMDAwMCAtIDAwMDAw
MDAwMDAxMDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZApb
ICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MzAxNWNmIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAw
MDAwClsgICAgMC4wMDAwMDBdIHgyYXBpYyBlbmFibGVkIGJ5IEJJT1MsIHN3aXRjaGluZyB0byB4
MmFwaWMgb3BzClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0gMHhiZjgwMCBtYXhfYXJjaF9wZm4g
PSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4
ODAwMDAwZmNlMDBdIGZjZTAwClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZCA6
IDAgLSAwNDg2NDAwMApbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtm
ZmZmODgwMDAwMDg4MDAwXSA4ODAwMCBzaXplIDIwNDgwClsgICAgMC4wMDAwMDBdIGluaXRfbWVt
b3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDBiZjgwMDAwMApbICAgIDAuMDAw
MDAwXSAgMDAwMDAwMDAwMCAtIDAwYmY4MDAwMDAgcGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJu
ZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIGJmODAwMDAwIEAgYTAwMDAwLTEwMDAwMDAK
WyAgICAwLjAwMDAwMF0geGVuOiBzZXR0aW5nIFJXIHRoZSByYW5nZSBmZDQwMDAgLSAxMDAwMDAw
ClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAxMDAwMDAwMDAtMDAw
MDAwMDMwMTVjZjAwMApbICAgIDAuMDAwMDAwXSAgMDEwMDAwMDAwMCAtIDAzMDE1Y2YwMDAgcGFn
ZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDMw
MTVjZjAwMCBAIDNlN2U3MDAwLTQwMDAwMDAwClsgICAgMC4wMDAwMDBdIHhlbjogc2V0dGluZyBS
VyB0aGUgcmFuZ2UgM2Y3ZmIwMDAgLSA0MDAwMDAwMApbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiAw
MjA2MDAwMCAtIDA0ODY0MDAwClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBm
MDQ1MCAwMDAyNCAodjAyIFNVUEVSTSkKWyAgICAwLjAwMDAwMF0gQUNQSTogWFNEVCAwMDAwMDAw
MGJlN2YxMDgwIDAwMDdDICh2MDEgU1VQRVJNIFNNQ0ktLU1CIDAwMDAwMDAxIEFNSSAgMDAwMTAw
MTMpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgMDAwMDAwMDBiZTdmN2Y0OCAwMDBGNCAodjA0
IFNVUEVSTSBTTUNJLS1NQiAwMDAwMDAwMSBBTUkgIDAwMDEwMDEzKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBEU0RUIDAwMDAwMDAwYmU3ZjExODggMDZEQzAgKHYwMiBTVVBFUk0gU01DSS0tTUIgMDAw
MDAwMDAgSU5UTCAyMDA1MTExNykKWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUyAwMDAwMDAwMGJm
NTBhZjgwIDAwMDQwClsgICAgMC4wMDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBiZTdmODA0MCAw
MDA5MiAodjAzIFNVUEVSTSBTTUNJLS1NQiAwMDAwMDAwMSBBTUkgIDAwMDEwMDEzKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYmU3ZjgwZDggMDAxRDYgKHYwMSBBTUlDUFUgICAg
IFBST0MgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkKWyAgICAwLjAwMDAwMF0gQUNQSTogTUNGRyAw
MDAwMDAwMGJlN2Y4MmIwIDAwMDNDICh2MDEgU1VQRVJNIFNNQ0ktLU1CIDAwMDAwMDAxIE1TRlQg
MDAwMDAwOTcpClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAwMDAwMDBiZTdmODJmMCAwMDAz
OCAodjAxIFNVUEVSTSBTTUNJLS1NQiAwMDAwMDAwMSBBTUkuIDAwMDAwMDA0KQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBTUE1JIDAwMDAwMDAwYmU3ZjgzMjggMDAwNDAgKHYwNSBBIE0gSSAgIE9FTVNQ
TUkgMDAwMDAwMDAgQU1JLiAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogWE1BUiAwMDAw
MDAwMGJlN2Y4MzY4IDAwMEIwICh2MDEgQUxBU0tBICAgIEEgTSBJIDAwMDAwMDAxIElOVEwgMDAw
MDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IEVJTkogMDAwMDAwMDBiZTdmODQxOCAwMDEzMCAo
djAxICAgIEFNSSBBTUkgRUlOSiAwMDAwMDAwMCAgICAgIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBFUlNUIDAwMDAwMDAwYmU3Zjg1NDggMDAyMTAgKHYwMSAgQU1JRVIgQU1JIEVSU1Qg
MDAwMDAwMDAgICAgICAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSEVTVCAwMDAwMDAw
MGJlN2Y4NzU4IDAwMEE4ICh2MDEgICAgQU1JIEFNSSBIRVNUIDAwMDAwMDAwICAgICAgMDAwMDAw
MDApClsgICAgMC4wMDAwMDBdIEFDUEk6IEJFUlQgMDAwMDAwMDBiZTdmODgwMCAwMDAzMCAodjAx
ICAgIEFNSSBBTUkgQkVSVCAwMDAwMDAwMCAgICAgIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAwMDAwXSBTZXR0aW5n
IEFQSUMgcm91dGluZyB0byBjbHVzdGVyIHgyYXBpYy4KWyAgICAwLjAwMDAwMF0gTm8gTlVNQSBj
b25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgMDAwMDAw
MDAwMDAwMDAwMC0wMDAwMDAwMzAxNWNmMDAwClsgICAgMC4wMDAwMDBdIEluaXRtZW0gc2V0dXAg
bm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDMwMTVjZjAwMApbICAgIDAuMDAwMDAwXSAg
IE5PREVfREFUQSBbMDAwMDAwMDAzZmZmYjAwMCAtIDAwMDAwMDAwM2ZmZmZmZmZdClsgICAgMC4w
MDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAwMDAwMF0gICBETUEgICAgICAweDAwMDAw
MDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAweDAwMDAxMDAwIC0+
IDB4MDAxMDAwMDAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgICAweDAwMTAwMDAwIC0+IDB4MDAz
MDE1Y2YKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IFBGTiBmb3IgZWFjaCBub2Rl
ClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzVdIGFjdGl2ZSBQRk4gcmFuZ2VzClsgICAg
MC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwOGQKWyAgICAwLjAwMDAwMF0g
ICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDBiZTdhNQpbICAgIDAuMDAwMDAwXSAgICAgMDogMHgw
MDBiZjRhZCAtPiAweDAwMGJmNGFmClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMGJmNTc2IC0+
IDB4MDAwYmY4MDAKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAxMDAwMDAgLT4gMHgwMDMwMTVj
ZgpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMjg4MzQ1MwpbICAgIDAuMDAw
MDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0g
ICBETUEgem9uZTogMTQ5NyBwYWdlcyByZXNlcnZlZApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25l
OiAyNDA0IHBhZ2VzLCBMSUZPIGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAx
NjMyMCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA3
NjA0MzMgcGFnZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTog
MzI4NTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6
IDIwNjk4NzkgcGFnZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gQUNQSTogUE0tVGlt
ZXIgSU8gUG9ydDogMHg0MDgKWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNz
IDB4ZmVlMDAwMDAKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFw
aWNfaWRbMHgwMF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwM10g
ZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNf
aWRbMHgwNV0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
OF0gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1J
IChhY3BpX2lkWzB4ZmZdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6
IElPQVBJQyAoaWRbMHgwMF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKWyAgICAw
LjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDAsIHZlcnNpb24gMjU1LCBhZGRyZXNzIDB4ZmVj
MDAwMDAsIEdTSSAwLTI1NQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg
YnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRf
U1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJROSB1c2VkIGJ5
IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZp
Z3VyYXRpb24gaW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2
YTcwMSBiYXNlOiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDogQWxsb3dpbmcgOCBDUFVz
LCAwIGhvdHBsdWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogMjcyClsgICAgMC4w
MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOGQwMDAgLSAw
MDAwMDAwMDAwMTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IDAwMDAwMDAwYmU3YTUwMDAgLSAwMDAwMDAwMGJlN2YxMDAwClsgICAgMC4wMDAwMDBdIFBN
OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmU3ZjEwMDAgLSAwMDAwMDAwMGJl
N2Y5MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw
MDAwYmU3ZjkwMDAgLSAwMDAwMDAwMGJmNDc3MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl
cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY0NzcwMDAgLSAwMDAwMDAwMGJmNDc4MDAwClsg
ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY0Nzgw
MDAgLSAwMDAwMDAwMGJmNDg5MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IDAwMDAwMDAwYmY0ODkwMDAgLSAwMDAwMDAwMGJmNDhjMDAwClsgICAgMC4wMDAw
MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY0OGMwMDAgLSAwMDAw
MDAwMGJmNGFkMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IDAwMDAwMDAwYmY0YWYwMDAgLSAwMDAwMDAwMGJmNTAzMDAwClsgICAgMC4wMDAwMDBdIFBNOiBS
ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY1MDMwMDAgLSAwMDAwMDAwMGJmNTBk
MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw
YmY1MGQwMDAgLSAwMDAwMDAwMGJmNTMzMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVk
IG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY1MzMwMDAgLSAwMDAwMDAwMGJmNTc2MDAwClsgICAg
MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY4MDAwMDAg
LSAwMDAwMDAwMGZlYzAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt
ZW1vcnk6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwClsgICAgMC4wMDAwMDBd
IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVjMDEwMDAgLSAwMDAwMDAw
MGZlZDFjMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAw
MDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDQwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdp
c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkNDAwMDAgLSAwMDAwMDAwMGZlZTAwMDAw
ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVl
MDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDEwMDAgLSAwMDAwMDAwMGZmMDAwMDAwClsgICAgMC4w
MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmYwMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBz
dGFydGluZyBhdCBiZjgwMDAwMCAoZ2FwOiBiZjgwMDAwMDozZjQwMDAwMCkKWyAgICAwLjAwMDAw
MF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpbICAgIDAuMDAwMDAwXSBY
ZW4gdmVyc2lvbjogNC4xLjMtcmMxLXByZSAocHJlc2VydmUtQUQpClsgICAgMC4wMDAwMDBdIHNl
dHVwX3BlcmNwdTogTlJfQ1BVUzoyNTYgbnJfY3B1bWFza19iaXRzOjI1NiBucl9jcHVfaWRzOjgg
bnJfbm9kZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2VzL2Nw
dSBAZmZmZjg4MDAzZmVjYTAwMCBzODMwNzIgcjgxOTIgZDIzNDI0IHUxMTQ2ODgKWyAgICAwLjAw
MDAwMF0gcGNwdS1hbGxvYzogczgzMDcyIHI4MTkyIGQyMzQyNCB1MTE0Njg4IGFsbG9jPTI4KjQw
OTYKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogWzBdIDAgWzBdIDEgWzBdIDIgWzBdIDMgWzBd
IDQgWzBdIDUgWzBdIDYgWzBdIDcgClsgICAgMy40MTEzOTFdIEJ1aWx0IDEgem9uZWxpc3RzIGlu
IFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDI4MzI3MTYK
WyAgICAzLjQxMTM5NF0gUG9saWN5IHpvbmU6IE5vcm1hbApbICAgIDMuNDExMzk2XSBLZXJuZWwg
Y29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9kZXYvbWFwcGVyL1ZTeXN0ZW0wMS1sdlhl
bjAyIHJvIGVhcmx5cHJpbnRrPXhlbiBpbml0Y2FsbF9kZWJ1ZyBkZWJ1ZyBsb2dsZXZlbD0xMCBt
c2k9MQpbICAgIDMuNDExODA2XSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjog
MywgMzI3NjggYnl0ZXMpClsgICAgMy40MzEzMzJdIFBsYWNpbmcgNjRNQiBzb2Z0d2FyZSBJTyBU
TEIgYmV0d2VlbiBmZmZmODgwMDJmMDAwMDAwIC0gZmZmZjg4MDAzMzAwMDAwMApbICAgIDMuNDMx
MzM2XSBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDJmMDAwMDAwIC0gMHgzMzAwMDAwMApbICAg
IDMuNDMzNTE4XSBNZW1vcnk6IDcxNjkyNGsvMTI2MDUyNDRrIGF2YWlsYWJsZSAoNjU2NWsga2Vy
bmVsIGNvZGUsIDEwNzE0MzJrIGFic2VudCwgMTA4MTY4ODhrIHJlc2VydmVkLCA2NjM5ayBkYXRh
LCA5MjBrIGluaXQpClsgICAgMy40MzM1ODVdIFNMVUI6IEdlbnNsYWJzPTE1LCBIV2FsaWduPTY0
LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BVcz04LCBOb2Rlcz0xClsgICAgMy40MzM2MDdd
IEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMy40MzM2MDldIAlSQ1UgZHlu
dGljay1pZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5hYmxlZC4KWyAgICAzLjQz
MzYxNl0gTlJfSVJRUzoxNjY0MCBucl9pcnFzOjIwNDggMTYKWyAgICAzLjQzMzY3Ml0geGVuOiBz
Y2kgb3ZlcnJpZGU6IGdsb2JhbF9pcnE9OSB0cmlnZ2VyPTAgcG9sYXJpdHk9MApbICAgIDMuNDMz
Njc1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAwClsgICAg
My40MzM2ODNdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpClsgICAgMy40MzM3MTVd
IHhlbjogYWNwaSBzY2kgOQpbICAgIDMuNDMzNzE4XSB4ZW46IC0tPiBwaXJxPTEgLT4gaXJxPTEg
KGdzaT0xKQpbICAgIDMuNDMzNzIxXSB4ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIgKGdzaT0yKQpb
ICAgIDMuNDMzNzI0XSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQpbICAgIDMuNDMz
NzI3XSB4ZW46IC0tPiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQpbICAgIDMuNDMzNzMwXSB4ZW46
IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQpbICAgIDMuNDMzNzMzXSB4ZW46IC0tPiBwaXJx
PTYgLT4gaXJxPTYgKGdzaT02KQpbICAgIDMuNDMzNzM2XSB4ZW46IC0tPiBwaXJxPTcgLT4gaXJx
PTcgKGdzaT03KQpbICAgIDMuNDMzNzM4XSB4ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04
KQpbICAgIDMuNDMzNzQwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDkgZm9yIGdz
aSA5ClsgICAgMy40MzM3NDJdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpClsgICAg
My40MzM3NDVdIHhlbjogLS0+IHBpcnE9MTAgLT4gaXJxPTEwIChnc2k9MTApClsgICAgMy40MzM3
NDhdIHhlbjogLS0+IHBpcnE9MTEgLT4gaXJxPTExIChnc2k9MTEpClsgICAgMy40MzM3NTFdIHhl
bjogLS0+IHBpcnE9MTIgLT4gaXJxPTEyIChnc2k9MTIpClsgICAgMy40MzM3NTRdIHhlbjogLS0+
IHBpcnE9MTMgLT4gaXJxPTEzIChnc2k9MTMpClsgICAgMy40MzM3NTddIHhlbjogLS0+IHBpcnE9
MTQgLT4gaXJxPTE0IChnc2k9MTQpClsgICAgMy40MzM3NjBdIHhlbjogLS0+IHBpcnE9MTUgLT4g
aXJxPTE1IChnc2k9MTUpClsgICAgMy40MzY2MzRdIENvbnNvbGU6IGNvbG91ciBWR0ErIDgweDI1
ClsgICAgMy40MzY2MzddIGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQsIGJvb3Rjb25zb2xlIGRpc2Fi
bGVkClsgICAgMy40NDcyMDBdIGFsbG9jYXRlZCA5MzMyMzI2NCBieXRlcyBvZiBwYWdlX2Nncm91
cApbICAgIDMuNDQ3Mjg4XSBwbGVhc2UgdHJ5ICdjZ3JvdXBfZGlzYWJsZT1tZW1vcnknIG9wdGlv
biBpZiB5b3UgZG9uJ3Qgd2FudCBtZW1vcnkgY2dyb3VwcwpbICAgIDMuNDQ3NDA4XSBYZW46IHVz
aW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UKWyAgICAzLjQ0NzQ4N10gaW5zdGFsbGluZyBYZW4g
dGltZXIgZm9yIENQVSAwClsgICAgMy40NDc1OTFdIERldGVjdGVkIDMxOTIuODM4IE1IeiBwcm9j
ZXNzb3IuClsgICAgMy40NDc2NzRdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBwZWQpLCB2
YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDYzODUuNjcgQm9nb01JUFMg
KGxwaj0xMjc3MTM1MikKWyAgICAzLjQ0NzgzOV0gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWlu
aW11bTogMzAxClsgICAgMy40NDc5NDNdIFNlY3VyaXR5IEZyYW1ld29yayBpbml0aWFsaXplZApb
ICAgIDMuNDQ4MDI4XSBBcHBBcm1vcjogQXBwQXJtb3IgaW5pdGlhbGl6ZWQKWyAgICAzLjQ0ODEw
NF0gWWFtYTogYmVjb21pbmcgbWluZGZ1bC4KWyAgICAzLjQ1MjQ4M10gRGVudHJ5IGNhY2hlIGhh
c2ggdGFibGUgZW50cmllczogMjA5NzE1MiAob3JkZXI6IDEyLCAxNjc3NzIxNiBieXRlcykKWyAg
ICAzLjQ1Njc3MF0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAxMDQ4NTc2IChvcmRl
cjogMTEsIDgzODg2MDggYnl0ZXMpClsgICAgMy40NTc5MTNdIE1vdW50LWNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogMjU2ClsgICAgMy40NTgxMjddIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lz
IGNwdWFjY3QKWyAgICAzLjQ1ODIxMl0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgbWVtb3J5
ClsgICAgMy40NTgyOTddIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGRldmljZXMKWyAgICAz
LjQ1ODM3OV0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcgpbICAgIDMuNDU4NDYx
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBibGtpbwpbICAgIDMuNDU4NTQ2XSBJbml0aWFs
aXppbmcgY2dyb3VwIHN1YnN5cyBwZXJmX2V2ZW50ClsgICAgMy40NTg2NzldIEVORVJHWV9QRVJG
X0JJQVM6IFNldCB0byAnbm9ybWFsJywgd2FzICdwZXJmb3JtYW5jZScKWyAgICAzLjQ1ODY4MF0g
RU5FUkdZX1BFUkZfQklBUzogVmlldyBhbmQgdXBkYXRlIHdpdGggeDg2X2VuZXJneV9wZXJmX3Bv
bGljeSg4KQpbICAgIDMuNDU4ODgzXSBDUFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMApbICAg
IDMuNDU4OTc4XSBDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAwClsgICAgMy40NjA5OTNdIEFDUEk6
IENvcmUgcmV2aXNpb24gMjAxMTA2MjMKWyAgICAzLjY5MTE5Nl0gZnRyYWNlOiBhbGxvY2F0aW5n
IDI3MDQ5IGVudHJpZXMgaW4gMTA3IHBhZ2VzClsgICAgMy42OTg2MjZdIGNwdSAwIHNwaW5sb2Nr
IGV2ZW50IGlycSAyNzMKWyAgICAzLjY5ODc0OF0gY2FsbGluZyAgdHJhY2VfaW5pdF9mbGFnc19z
eXNfZXhpdCsweDAvMHgxMiBAIDEKWyAgICAzLjY5ODg1MV0gaW5pdGNhbGwgdHJhY2VfaW5pdF9m
bGFnc19zeXNfZXhpdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjY5
ODk3Nl0gY2FsbGluZyAgdHJhY2VfaW5pdF9mbGFnc19zeXNfZW50ZXIrMHgwLzB4MTIgQCAxClsg
ICAgMy42OTkwODBdIGluaXRjYWxsIHRyYWNlX2luaXRfZmxhZ3Nfc3lzX2VudGVyKzB4MC8weDEy
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNjk5MjA1XSBjYWxsaW5nICBpbml0X2h3
X3BlcmZfZXZlbnRzKzB4MC8weDg2IEAgMQpbICAgIDMuNjk5MzA2XSBQZXJmb3JtYW5jZSBFdmVu
dHM6IHVuc3VwcG9ydGVkIHA2IENQVSBtb2RlbCA0MiBubyBQTVUgZHJpdmVyLCBzb2Z0d2FyZSBl
dmVudHMgb25seS4KWyAgICAzLjY5OTU3OV0gaW5pdGNhbGwgaW5pdF9od19wZXJmX2V2ZW50cysw
eDAvMHg4NiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjY5OTY4M10gY2FsbGluZyAg
cmVnaXN0ZXJfdHJpZ2dlcl9hbGxfY3B1X2JhY2t0cmFjZSsweDAvMHgxZiBAIDEKWyAgICAzLjY5
OTc4OV0gaW5pdGNhbGwgcmVnaXN0ZXJfdHJpZ2dlcl9hbGxfY3B1X2JhY2t0cmFjZSsweDAvMHgx
ZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjY5OTkxNV0gY2FsbGluZyAgbnVtYWNo
aXBfc3lzdGVtX2luaXQrMHgwLzB4YTggQCAxClsgICAgMy43MDAwMTldIGluaXRjYWxsIG51bWFj
aGlwX3N5c3RlbV9pbml0KzB4MC8weGE4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
NzAwMTIyXSBjYWxsaW5nICBtaWdyYXRpb25faW5pdCsweDAvMHg2YyBAIDEKWyAgICAzLjcwMDIy
M10gaW5pdGNhbGwgbWlncmF0aW9uX2luaXQrMHgwLzB4NmMgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgMy43MDAzMjddIGNhbGxpbmcgIHNwYXduX2tzb2Z0aXJxZCsweDAvMHg1MyBAIDEK
WyAgICAzLjcwMDQ0M10gaW5pdGNhbGwgc3Bhd25fa3NvZnRpcnFkKzB4MC8weDUzIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAwNTQ3XSBjYWxsaW5nICBpbml0X3dvcmtxdWV1ZXMr
MHgwLzB4MmQ0IEAgMQpbICAgIDMuNzAwNjg5XSBpbml0Y2FsbCBpbml0X3dvcmtxdWV1ZXMrMHgw
LzB4MmQ0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAwNzk1XSBjYWxsaW5nICBj
cHVfc3RvcF9pbml0KzB4MC8weGFkIEAgMQpbICAgIDMuNzAwOTA3XSBpbml0Y2FsbCBjcHVfc3Rv
cF9pbml0KzB4MC8weGFkIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAxMDExXSBj
YWxsaW5nICByY3Vfc2NoZWR1bGVyX3JlYWxseV9zdGFydGVkKzB4MC8weDEyIEAgMQpbICAgIDMu
NzAxMTE0XSBpbml0Y2FsbCByY3Vfc2NoZWR1bGVyX3JlYWxseV9zdGFydGVkKzB4MC8weDEyIHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAxMjQzXSBjYWxsaW5nICByZWxheV9pbml0
KzB4MC8weDE0IEAgMQpbICAgIDMuNzAxMzQ0XSBpbml0Y2FsbCByZWxheV9pbml0KzB4MC8weDE0
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAxNDQ5XSBjYWxsaW5nICB0cmFjZXJf
YWxsb2NfYnVmZmVycysweDAvMHgxY2QgQCAxClsgICAgMy43MDE1NjZdIGluaXRjYWxsIHRyYWNl
cl9hbGxvY19idWZmZXJzKzB4MC8weDFjZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAz
LjcwMTY3Ml0gY2FsbGluZyAgaW5pdF90cmFjZV9wcmludGsrMHgwLzB4MTIgQCAxClsgICAgMy43
MDE3NzFdIGluaXRjYWxsIGluaXRfdHJhY2VfcHJpbnRrKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDMuNzAxODc3XSBjYWxsaW5nICBqdW1wX2xhYmVsX2luaXRfbW9kdWxl
KzB4MC8weDEyIEAgMQpbICAgIDMuNzAxOTc5XSBpbml0Y2FsbCBqdW1wX2xhYmVsX2luaXRfbW9k
dWxlKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAyMDg1XSBOTUkg
d2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTApOiBoYXJkd2FyZSBldmVudHMgbm90IGVuYWJsZWQKWyAg
ICAzLjcwMjI0OF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAxClsgICAgMy43MDIzNTRd
IGNwdSAxIHNwaW5sb2NrIGV2ZW50IGlycSAyNzkKWyAgICAzLjcwMjU1NF0gTk1JIHdhdGNoZG9n
IGRpc2FibGVkIChjcHUxKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBlbmFibGVkClsgICAgMy43MDI2
NzldIEJyb3VnaHQgdXAgMiBDUFVzClsgICAgMy43MDI5NjBdIGRldnRtcGZzOiBpbml0aWFsaXpl
ZApbICAgIDMuNzAzODExXSBjYWxsaW5nICBpcGNfbnNfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAz
LjcwMzkxM10gaW5pdGNhbGwgaXBjX25zX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy43MDQwMTddIGNhbGxpbmcgIGluaXRfbW1hcF9taW5fYWRkcisweDAvMHgx
NiBAIDEKWyAgICAzLjcwNDExOV0gaW5pdGNhbGwgaW5pdF9tbWFwX21pbl9hZGRyKzB4MC8weDE2
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzA0MjIyXSBjYWxsaW5nICBldm1fZGlz
cGxheV9jb25maWcrMHgwLzB4MmYgQCAxClsgICAgMy43MDQzMjNdIEVWTTogc2VjdXJpdHkuc2Vs
aW51eApbICAgIDMuNzA0NDIwXSBFVk06IHNlY3VyaXR5LlNNQUNLNjQKWyAgICAzLjcwNDUxOF0g
RVZNOiBzZWN1cml0eS5jYXBhYmlsaXR5ClsgICAgMy43MDQ2MTldIGluaXRjYWxsIGV2bV9kaXNw
bGF5X2NvbmZpZysweDAvMHgyZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNDcy
NF0gY2FsbGluZyAgaW5pdF9jcHVmcmVxX3RyYW5zaXRpb25fbm90aWZpZXJfbGlzdCsweDAvMHgx
YiBAIDEKWyAgICAzLjcwNDgzMF0gaW5pdGNhbGwgaW5pdF9jcHVmcmVxX3RyYW5zaXRpb25fbm90
aWZpZXJfbGlzdCsweDAvMHgxYiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNDk1
N10gY2FsbGluZyAgbmV0X25zX2luaXQrMHgwLzB4ZTggQCAxClsgICAgMy43MDUwOTFdIGluaXRj
YWxsIG5ldF9uc19pbml0KzB4MC8weGU4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
NzA1MjAwXSBjYWxsaW5nICBlODIwX21hcmtfbnZzX21lbW9yeSsweDAvMHgzZCBAIDEKWyAgICAz
LjcwNTMwMV0gUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBhdCBiZTdhNTAwMCAoMzEx
Mjk2IGJ5dGVzKQpbICAgIDMuNzA1NDA5XSBQTTogUmVnaXN0ZXJpbmcgQUNQSSBOVlMgcmVnaW9u
IGF0IGJmNDc3MDAwICg0MDk2IGJ5dGVzKQpbICAgIDMuNzA1NTEzXSBQTTogUmVnaXN0ZXJpbmcg
QUNQSSBOVlMgcmVnaW9uIGF0IGJmNDg5MDAwICgxMjI4OCBieXRlcykKWyAgICAzLjcwNTYxN10g
UE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBhdCBiZjUwMzAwMCAoNDA5NjAgYnl0ZXMp
ClsgICAgMy43MDU3MThdIFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24gYXQgYmY1MzMw
MDAgKDI3NDQzMiBieXRlcykKWyAgICAzLjcwNTgyN10gaW5pdGNhbGwgZTgyMF9tYXJrX252c19t
ZW1vcnkrMHgwLzB4M2QgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MDU5MzFdIGNh
bGxpbmcgIGNwdWZyZXFfdHNjKzB4MC8weDMwIEAgMQpbICAgIDMuNzA2MDMyXSBpbml0Y2FsbCBj
cHVmcmVxX3RzYysweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNjEz
NV0gY2FsbGluZyAgcGNpX3JlYm9vdF9pbml0KzB4MC8weDE0IEAgMQpbICAgIDMuNzA2MjM4XSBp
bml0Y2FsbCBwY2lfcmVib290X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy43MDYzNDNdIGNhbGxpbmcgIGluaXRfbGFwaWNfc3lzZnMrMHgwLzB4MjAgQCAxClsg
ICAgMy43MDY0NDNdIGluaXRjYWxsIGluaXRfbGFwaWNfc3lzZnMrMHgwLzB4MjAgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MDY1NDldIGNhbGxpbmcgIGluaXRfc21wX2ZsdXNoKzB4
MC8weDNhIEAgMQpbICAgIDMuNzA2NjQ5XSBpbml0Y2FsbCBpbml0X3NtcF9mbHVzaCsweDAvMHgz
YSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNjc1Nl0gY2FsbGluZyAgY3B1X2hv
dHBsdWdfcG1fc3luY19pbml0KzB4MC8weDIwIEAgMQpbICAgIDMuNzA2ODU4XSBpbml0Y2FsbCBj
cHVfaG90cGx1Z19wbV9zeW5jX2luaXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy43MDY5ODNdIGNhbGxpbmcgIGFsbG9jX2Zyb3plbl9jcHVzKzB4MC8weDEwIEAgMQpb
ICAgIDMuNzA3MDg2XSBpbml0Y2FsbCBhbGxvY19mcm96ZW5fY3B1cysweDAvMHgxMCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNzE5Ml0gY2FsbGluZyAgc3lzY3RsX2luaXQrMHgw
LzB4MzIgQCAxClsgICAgMy43MDczMzFdIGluaXRjYWxsIHN5c2N0bF9pbml0KzB4MC8weDMyIHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzA3NDMzXSBjYWxsaW5nICBrc3lzZnNfaW5p
dCsweDAvMHg5MSBAIDEKWyAgICAzLjcwNzUzOV0gaW5pdGNhbGwga3N5c2ZzX2luaXQrMHgwLzB4
OTEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MDc2NDNdIGNhbGxpbmcgIGluaXRf
amlmZmllc19jbG9ja3NvdXJjZSsweDAvMHgxMiBAIDEKWyAgICAzLjcwNzc0N10gaW5pdGNhbGwg
aW5pdF9qaWZmaWVzX2Nsb2Nrc291cmNlKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuNzA3ODcyXSBjYWxsaW5nICBwbV9pbml0KzB4MC8weDZhIEAgMQpbICAgIDMuNzA3
OTc3XSBpbml0Y2FsbCBwbV9pbml0KzB4MC8weDZhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcwpb
ICAgIDMuNzA4MDc4XSBjYWxsaW5nICBwbV9kaXNrX2luaXQrMHgwLzB4MTkgQCAxClsgICAgMy43
MDgxODFdIGluaXRjYWxsIHBtX2Rpc2tfaW5pdCsweDAvMHgxOSByZXR1cm5lZCAwIGFmdGVyIDAg
dXNlY3MKWyAgICAzLjcwODI4M10gY2FsbGluZyAgc3dzdXNwX2hlYWRlcl9pbml0KzB4MC8weDQw
IEAgMQpbICAgIDMuNzA4Mzg3XSBpbml0Y2FsbCBzd3N1c3BfaGVhZGVyX2luaXQrMHgwLzB4NDAg
cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MDg0OTNdIGNhbGxpbmcgIGluaXRfZnRy
YWNlX3N5c2NhbGxzKzB4MC8weDg3IEAgMQpbICAgIDMuNzA5MDE1XSBpbml0Y2FsbCBpbml0X2Z0
cmFjZV9zeXNjYWxscysweDAvMHg4NyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcw
OTExOV0gY2FsbGluZyAgaW5pdF96ZXJvX3BmbisweDAvMHgxZiBAIDEKWyAgICAzLjcwOTIyMV0g
aW5pdGNhbGwgaW5pdF96ZXJvX3BmbisweDAvMHgxZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjcwOTMyNV0gY2FsbGluZyAgbWVtb3J5X2ZhaWx1cmVfaW5pdCsweDAvMHhhMSBAIDEK
WyAgICAzLjcwOTQyNl0gaW5pdGNhbGwgbWVtb3J5X2ZhaWx1cmVfaW5pdCsweDAvMHhhMSByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwOTUzMV0gY2FsbGluZyAgZnNub3RpZnlfaW5p
dCsweDAvMHgyNiBAIDEKWyAgICAzLjcwOTYzM10gaW5pdGNhbGwgZnNub3RpZnlfaW5pdCsweDAv
MHgyNiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwOTczN10gY2FsbGluZyAgZmls
ZWxvY2tfaW5pdCsweDAvMHgyYSBAIDEKWyAgICAzLjcwOTgzOV0gaW5pdGNhbGwgZmlsZWxvY2tf
aW5pdCsweDAvMHgyYSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwOTk0MV0gY2Fs
bGluZyAgaW5pdF9zY3JpcHRfYmluZm10KzB4MC8weDE0IEAgMQpbICAgIDMuNzEwMDQzXSBpbml0
Y2FsbCBpbml0X3NjcmlwdF9iaW5mbXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy43MTAxNDRdIGNhbGxpbmcgIGluaXRfZWxmX2JpbmZtdCsweDAvMHgxNCBAIDEKWyAg
ICAzLjcxMDI0N10gaW5pdGNhbGwgaW5pdF9lbGZfYmluZm10KzB4MC8weDE0IHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEwMzUyXSBjYWxsaW5nICBpbml0X2NvbXBhdF9lbGZfYmlu
Zm10KzB4MC8weDE0IEAgMQpbICAgIDMuNzEwNDU1XSBpbml0Y2FsbCBpbml0X2NvbXBhdF9lbGZf
YmluZm10KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEwNTYyXSBj
YWxsaW5nICBkZWJ1Z2ZzX2luaXQrMHgwLzB4NTcgQCAxClsgICAgMy43MTA2NjVdIGluaXRjYWxs
IGRlYnVnZnNfaW5pdCsweDAvMHg1NyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcx
MDc3MF0gY2FsbGluZyAgc2VjdXJpdHlmc19pbml0KzB4MC8weDRlIEAgMQpbICAgIDMuNzEwODcw
XSBpbml0Y2FsbCBzZWN1cml0eWZzX2luaXQrMHgwLzB4NGUgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgMy43MTA5NzRdIGNhbGxpbmcgIHJhbmRvbTMyX2luaXQrMHgwLzB4ZDYgQCAxClsg
ICAgMy43MTEwNzNdIGluaXRjYWxsIHJhbmRvbTMyX2luaXQrMHgwLzB4ZDYgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy43MTExNzldIGNhbGxpbmcgIHNmaV9zeXNmc19pbml0KzB4MC8w
eGRhIEAgMQpbICAgIDMuNzExMjgzXSBpbml0Y2FsbCBzZmlfc3lzZnNfaW5pdCsweDAvMHhkYSBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcxMTM4N10gY2FsbGluZyAgdmlydGlvX2lu
aXQrMHgwLzB4MzAgQCAxClsgICAgMy43MTE1MDBdIGluaXRjYWxsIHZpcnRpb19pbml0KzB4MC8w
eDMwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzExNjA2XSBjYWxsaW5nICBfX2du
dHRhYl9pbml0KzB4MC8weDIxIEAgMQpbICAgIDMuNzExNzE1XSBHcmFudCB0YWJsZSBpbml0aWFs
aXplZApbICAgIDMuNzExODEyXSBpbml0Y2FsbCBfX2dudHRhYl9pbml0KzB4MC8weDIxIHJldHVy
bmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzExOTE3XSBjYWxsaW5nICByZWd1bGF0b3JfaW5p
dCsweDAvMHhhNiBAIDEKWyAgICAzLjcxMjA1M10gcHJpbnRfY29uc3RyYWludHM6IGR1bW15OiAK
WyAgICAzLjcxMjE1OV0gaW5pdGNhbGwgcmVndWxhdG9yX2luaXQrMHgwLzB4YTYgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MTIyNjVdIGNhbGxpbmcgIGVhcmx5X3Jlc3VtZV9pbml0
KzB4MC8weDIwIEAgMQpbICAgIDMuNzEyNDI3XSBSVEMgdGltZTogMTg6Mjk6MjMsIGRhdGU6IDA0
LzExLzEyClsgICAgMy43MTI1MjddIGluaXRjYWxsIGVhcmx5X3Jlc3VtZV9pbml0KzB4MC8weDIw
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEyNjMzXSBjYWxsaW5nICBjcHVmcmVx
X2NvcmVfaW5pdCsweDAvMHhhOSBAIDEKWyAgICAzLjcxMjczNV0gaW5pdGNhbGwgY3B1ZnJlcV9j
b3JlX2luaXQrMHgwLzB4YTkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTI4NDFd
IGNhbGxpbmcgIGNwdWlkbGVfaW5pdCsweDAvMHgzZCBAIDEKWyAgICAzLjcxMjk0Ml0gaW5pdGNh
bGwgY3B1aWRsZV9pbml0KzB4MC8weDNkIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAg
My43MTMwNDVdIGNhbGxpbmcgIHNvY2tfaW5pdCsweDAvMHg4MCBAIDEKWyAgICAzLjcxMzE2Ml0g
aW5pdGNhbGwgc29ja19pbml0KzB4MC8weDgwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuNzEzMjY2XSBjYWxsaW5nICBuZXRfaW51c2VfaW5pdCsweDAvMHgyNiBAIDEKWyAgICAzLjcx
MzM2OV0gaW5pdGNhbGwgbmV0X2ludXNlX2luaXQrMHgwLzB4MjYgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy43MTM0NzRdIGNhbGxpbmcgIG5ldHBvbGxfaW5pdCsweDAvMHgzMSBAIDEK
WyAgICAzLjcxMzU3NV0gaW5pdGNhbGwgbmV0cG9sbF9pbml0KzB4MC8weDMxIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEzNjgwXSBjYWxsaW5nICBuZXRsaW5rX3Byb3RvX2luaXQr
MHgwLzB4MjUgQCAxClsgICAgMy43MTM3ODRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMTYKWyAgICAzLjcxMzg5MF0gaW5pdGNhbGwgbmV0bGlua19wcm90b19pbml0KzB4MC8weDI1
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEzOTk2XSBjYWxsaW5nICBwb3B1bGF0
ZV9yb290ZnNfZWFybHkrMHgwLzB4M2IgQCAxClsgICAgMy43MTQxMDFdIGluaXRjYWxsIHBvcHVs
YXRlX3Jvb3Rmc19lYXJseSsweDAvMHgzYiByZXR1cm5lZCAxIGFmdGVyIDAgdXNlY3MKWyAgICAz
LjcxNDIwN10gaW5pdGNhbGwgcG9wdWxhdGVfcm9vdGZzX2Vhcmx5KzB4MC8weDNiIHJldHVybmVk
IHdpdGggZXJyb3IgY29kZSAxIApbICAgIDMuNzE0MzMyXSBjYWxsaW5nICBiZGlfY2xhc3NfaW5p
dCsweDAvMHg0OSBAIDEKWyAgICAzLjcxNDQzN10gaW5pdGNhbGwgYmRpX2NsYXNzX2luaXQrMHgw
LzB4NDkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTQ1NDJdIGNhbGxpbmcgIGtv
YmplY3RfdWV2ZW50X2luaXQrMHgwLzB4MjEgQCAxClsgICAgMy43MTQ2NTldIGluaXRjYWxsIGtv
YmplY3RfdWV2ZW50X2luaXQrMHgwLzB4MjEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MTQ2NjZdIGNhbGxpbmcgIDFfYXN5bmNfcG9wdWxhdGVfcm9vdGZzKzB4MC8weDM2IEAgNQpb
ICAgIDMuNzE0Njk1XSBUcnlpbmcgdG8gdW5wYWNrIHJvb3RmcyBpbWFnZSBhcyBpbml0cmFtZnMu
Li4KWyAgICAzLjcxNDk2N10gY2FsbGluZyAgZ3Bpb2xpYl9zeXNmc19pbml0KzB4MC8weDkyIEAg
MQpbICAgIDMuNzE1MDc0XSBpbml0Y2FsbCBncGlvbGliX3N5c2ZzX2luaXQrMHgwLzB4OTIgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTUxNzldIGNhbGxpbmcgIHBjaWJ1c19jbGFz
c19pbml0KzB4MC8weDE5IEAgMQpbICAgIDMuNzE1MjgzXSBpbml0Y2FsbCBwY2lidXNfY2xhc3Nf
aW5pdCsweDAvMHgxOSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcxNTM4NV0gY2Fs
bGluZyAgcGNpX2RyaXZlcl9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuNzE1NDkxXSBpbml0Y2Fs
bCBwY2lfZHJpdmVyX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MTU1OTNdIGNhbGxpbmcgIHJpb19idXNfaW5pdCsweDAvMHgzMCBAIDEKWyAgICAzLjcxNTcx
MV0gaW5pdGNhbGwgcmlvX2J1c19pbml0KzB4MC8weDMwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuNzE1ODE1XSBjYWxsaW5nICBiYWNrbGlnaHRfY2xhc3NfaW5pdCsweDAvMHg1ZCBA
IDEKWyAgICAzLjcxNTkyMF0gaW5pdGNhbGwgYmFja2xpZ2h0X2NsYXNzX2luaXQrMHgwLzB4NWQg
cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTYwMjZdIGNhbGxpbmcgIHhlbmJ1c19p
bml0KzB4MC8weDE5MSBAIDEKWyAgICAzLjcxNjE4NF0gaW5pdGNhbGwgeGVuYnVzX2luaXQrMHgw
LzB4MTkxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzE2Mjg4XSBjYWxsaW5nICB0
dHlfY2xhc3NfaW5pdCsweDAvMHgzNCBAIDEKWyAgICAzLjcxNjM5NV0gaW5pdGNhbGwgdHR5X2Ns
YXNzX2luaXQrMHgwLzB4MzQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTY1MDBd
IGNhbGxpbmcgIHZ0Y29uc29sZV9jbGFzc19pbml0KzB4MC8weGUyIEAgMQpbICAgIDMuNzE2NjE4
XSBpbml0Y2FsbCB2dGNvbnNvbGVfY2xhc3NfaW5pdCsweDAvMHhlMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjcxNjcyMV0gY2FsbGluZyAgd2FrZXVwX3NvdXJjZXNfZGVidWdmc19p
bml0KzB4MC8weDJiIEAgMQpbICAgIDMuNzE2ODI2XSBpbml0Y2FsbCB3YWtldXBfc291cmNlc19k
ZWJ1Z2ZzX2luaXQrMHgwLzB4MmIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTY5
NTJdIGNhbGxpbmcgIHJlZ2lzdGVyX25vZGVfdHlwZSsweDAvMHgyYSBAIDEKWyAgICAzLjcxNzA1
OV0gaW5pdGNhbGwgcmVnaXN0ZXJfbm9kZV90eXBlKzB4MC8weDJhIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuNzE3MTY1XSBjYWxsaW5nICByZWdtYXBfaW5pdGNhbGwrMHgwLzB4ZCBA
IDEKWyAgICAzLjcxNzI2OF0gaW5pdGNhbGwgcmVnbWFwX2luaXRjYWxsKzB4MC8weGQgcmV0dXJu
ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTczNzNdIGNhbGxpbmcgIHNwaV9pbml0KzB4MC8w
eDk1IEAgMQpbICAgIDMuNzE3NDgyXSBpbml0Y2FsbCBzcGlfaW5pdCsweDAvMHg5NSByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcxNzU4N10gY2FsbGluZyAgaTJjX2luaXQrMHgwLzB4
NmYgQCAxClsgICAgMy43MTc3MDFdIGluaXRjYWxsIGkyY19pbml0KzB4MC8weDZmIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzE3ODA2XSBjYWxsaW5nICBhbWRfcG9zdGNvcmVfaW5p
dCsweDAvMHg4MSBAIDEKWyAgICAzLjcxOTYxMl0gaW5pdGNhbGwgYW1kX3Bvc3Rjb3JlX2luaXQr
MHgwLzB4ODEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTk3MjFdIGNhbGxpbmcg
IGFyY2hfa2RlYnVnZnNfaW5pdCsweDAvMHgyNCBAIDEKWyAgICAzLjcxOTgyOV0gaW5pdGNhbGwg
YXJjaF9rZGVidWdmc19pbml0KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuNzE5OTM2XSBjYWxsaW5nICBjb25maWd1cmVfdHJhbXBvbGluZXMrMHgwLzB4MjYgQCAxClsg
ICAgMy43MjAwNDddIGluaXRjYWxsIGNvbmZpZ3VyZV90cmFtcG9saW5lcysweDAvMHgyNiByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyMDE1NV0gY2FsbGluZyAgbXRycl9pZl9pbml0
KzB4MC8weDY0IEAgMQpbICAgIDMuNzIwMjU3XSBpbml0Y2FsbCBtdHJyX2lmX2luaXQrMHgwLzB4
NjQgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyMDM2Ml0gY2FsbGluZyAgZmZo
X2NzdGF0ZV9pbml0KzB4MC8weDJhIEAgMQpbICAgIDMuNzIwNDY1XSBpbml0Y2FsbCBmZmhfY3N0
YXRlX2luaXQrMHgwLzB4MmEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjA1NzFd
IGNhbGxpbmcgIGFjdGl2YXRlX2p1bXBfbGFiZWxzKzB4MC8weDMyIEAgMQpbICAgIDMuNzIwNjc1
XSBpbml0Y2FsbCBhY3RpdmF0ZV9qdW1wX2xhYmVscysweDAvMHgzMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjcyMDc4Ml0gY2FsbGluZyAgYWNwaV9wY2lfaW5pdCsweDAvMHg1YyBA
IDEKWyAgICAzLjcyMDg4M10gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQKWyAgICAzLjcy
MDk4NF0gaW5pdGNhbGwgYWNwaV9wY2lfaW5pdCsweDAvMHg1YyByZXR1cm5lZCAwIGFmdGVyIDAg
dXNlY3MKWyAgICAzLjcyMTA5MV0gY2FsbGluZyAgZG1hX2J1c19pbml0KzB4MC8weDE5IEAgMQpb
ICAgIDMuNzIxMjAyXSBpbml0Y2FsbCBkbWFfYnVzX2luaXQrMHgwLzB4MTkgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy43MjEzMTBdIGNhbGxpbmcgIGRtYV9jaGFubmVsX3RhYmxlX2lu
aXQrMHgwLzB4MTE4IEAgMQpbICAgIDMuNzIxNDI2XSBpbml0Y2FsbCBkbWFfY2hhbm5lbF90YWJs
ZV9pbml0KzB4MC8weDExOCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyMTU1Ml0g
Y2FsbGluZyAgc2V0dXBfdmNwdV9ob3RwbHVnX2V2ZW50KzB4MC8weDIyIEAgMQpbICAgIDMuNzIx
NjU1XSBpbml0Y2FsbCBzZXR1cF92Y3B1X2hvdHBsdWdfZXZlbnQrMHgwLzB4MjIgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MjE3NzddIGNhbGxpbmcgIHJlZ2lzdGVyX3hlbl9wY2lf
bm90aWZpZXIrMHgwLzB4MzEgQCAxClsgICAgMy43MjE4ODBdIGluaXRjYWxsIHJlZ2lzdGVyX3hl
bl9wY2lfbm90aWZpZXIrMHgwLzB4MzEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43
MjIwMDhdIGNhbGxpbmcgIGRtaV9pZF9pbml0KzB4MC8weGNhIEAgMQpbICAgIDMuNzIyMTU3XSBp
bml0Y2FsbCBkbWlfaWRfaW5pdCsweDAvMHhjYSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg
ICAzLjcyMjI2NF0gY2FsbGluZyAgcGNpX2FyY2hfaW5pdCsweDAvMHg2NiBAIDEKWyAgICAzLjcy
MjM5N10gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1cyAwMC1mZl0gYXQgW21lbSAw
eGUwMDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDApClsgICAgMy43MjI1MjZdIFBD
STogbm90IHVzaW5nIE1NQ09ORklHClsgICAgMy43MjI2MjZdIFBDSTogVXNpbmcgY29uZmlndXJh
dGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzClsgICAgMy43MjI3MjldIGluaXRjYWxsIHBjaV9h
cmNoX2luaXQrMHgwLzB4NjYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjI4MzRd
IGNhbGxpbmcgIHRvcG9sb2d5X2luaXQrMHgwLzB4OTYgQCAxClsgICAgMy43MjMwNzRdIGluaXRj
YWxsIHRvcG9sb2d5X2luaXQrMHgwLzB4OTYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MjMxNzldIGNhbGxpbmcgIG10cnJfaW5pdF9maW5pYWxpemUrMHgwLzB4MzYgQCAxClsgICAg
My43MjMyODBdIGluaXRjYWxsIG10cnJfaW5pdF9maW5pYWxpemUrMHgwLzB4MzYgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MjMzODVdIGNhbGxpbmcgIGluaXRfdmRzbysweDAvMHg3
ZSBAIDEKWyAgICAzLjcyMzQ4N10gaW5pdGNhbGwgaW5pdF92ZHNvKzB4MC8weDdlIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzIzNTkxXSBjYWxsaW5nICBzeXNlbnRlcl9zZXR1cCsw
eDAvMHhhYiBAIDEKWyAgICAzLjcyMzY5NF0gaW5pdGNhbGwgc3lzZW50ZXJfc2V0dXArMHgwLzB4
YWIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjM4MDBdIGNhbGxpbmcgIHBhcmFt
X3N5c2ZzX2luaXQrMHgwLzB4NGIgQCAxClsgICAgMy43MjQ0MThdIGluaXRjYWxsIHBhcmFtX3N5
c2ZzX2luaXQrMHgwLzB4NGIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjQ1MjVd
IGNhbGxpbmcgIHBtX3N5c3JxX2luaXQrMHgwLzB4MjAgQCAxClsgICAgMy43MjQ2MjZdIGluaXRj
YWxsIHBtX3N5c3JxX2luaXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MjQ3MjhdIGNhbGxpbmcgIGRlZmF1bHRfYmRpX2luaXQrMHgwLzB4YTUgQCAxClsgICAgMy43
MjQ5MThdIGluaXRjYWxsIGRlZmF1bHRfYmRpX2luaXQrMHgwLzB4YTUgcmV0dXJuZWQgMCBhZnRl
ciAwIHVzZWNzClsgICAgMy43MjUwMjRdIGNhbGxpbmcgIGluaXRfYmlvKzB4MC8weDExYSBAIDEK
WyAgICAzLjcyNTE1NF0gYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKWyAgICAzLjcyNTI1
OF0gaW5pdGNhbGwgaW5pdF9iaW8rMHgwLzB4MTFhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcwpb
ICAgIDMuNzI1MzYzXSBjYWxsaW5nICBmc25vdGlmeV9ub3RpZmljYXRpb25faW5pdCsweDAvMHg4
YiBAIDEKWyAgICAzLjcyNTQ3MV0gaW5pdGNhbGwgZnNub3RpZnlfbm90aWZpY2F0aW9uX2luaXQr
MHgwLzB4OGIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjU1OThdIGNhbGxpbmcg
IGNyeXB0b21ncl9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuNzI1Njk5XSBpbml0Y2FsbCBjcnlw
dG9tZ3JfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNTgw
M10gY2FsbGluZyAgYmxrX3NldHRpbmdzX2luaXQrMHgwLzB4MmEgQCAxClsgICAgMy43MjU5MDVd
IGluaXRjYWxsIGJsa19zZXR0aW5nc19pbml0KzB4MC8weDJhIHJldHVybmVkIDAgYWZ0ZXIgMCB1
c2VjcwpbICAgIDMuNzI2MDEwXSBjYWxsaW5nICBibGtfaW9jX2luaXQrMHgwLzB4MmEgQCAxClsg
ICAgMy43MjYxMTFdIGluaXRjYWxsIGJsa19pb2NfaW5pdCsweDAvMHgyYSByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICAzLjcyNjIxOV0gY2FsbGluZyAgYmxrX3NvZnRpcnFfaW5pdCsweDAv
MHg2ZCBAIDEKWyAgICAzLjcyNjMyM10gaW5pdGNhbGwgYmxrX3NvZnRpcnFfaW5pdCsweDAvMHg2
ZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNjQyOF0gY2FsbGluZyAgYmxrX2lv
cG9sbF9zZXR1cCsweDAvMHg2ZCBAIDEKWyAgICAzLjcyNjUzMF0gaW5pdGNhbGwgYmxrX2lvcG9s
bF9zZXR1cCsweDAvMHg2ZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNjYzNl0g
Y2FsbGluZyAgZ2VuaGRfZGV2aWNlX2luaXQrMHgwLzB4NzggQCAxClsgICAgMy43MjY4MDldIGlu
aXRjYWxsIGdlbmhkX2RldmljZV9pbml0KzB4MC8weDc4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuNzI2OTE0XSBjYWxsaW5nICBibGtfZGV2X2ludGVncml0eV9pbml0KzB4MC8weDJh
IEAgMQpbICAgIDMuNzI3MDE0XSBpbml0Y2FsbCBibGtfZGV2X2ludGVncml0eV9pbml0KzB4MC8w
eDJhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzI3MTE4XSBjYWxsaW5nICBncGlv
bGliX2RlYnVnZnNfaW5pdCsweDAvMHgyNCBAIDEKWyAgICAzLjcyNzIyM10gaW5pdGNhbGwgZ3Bp
b2xpYl9kZWJ1Z2ZzX2luaXQrMHgwLzB4MjQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MjczMjddIGNhbGxpbmcgIHN0bXBlX2dwaW9faW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjcy
NzQzN10gaW5pdGNhbGwgc3RtcGVfZ3Bpb19pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuNzI3NTQxXSBjYWxsaW5nICBzeDE1MHhfaW5pdCsweDAvMHgxNCBAIDEK
WyAgICAzLjcyNzY0N10gaW5pdGNhbGwgc3gxNTB4X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy43Mjc3NTBdIGNhbGxpbmcgIHRjMzU4OXhfZ3Bpb19pbml0KzB4
MC8weDEyIEAgMQpbICAgIDMuNzI3ODU0XSBpbml0Y2FsbCB0YzM1ODl4X2dwaW9faW5pdCsweDAv
MHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNzk2MV0gY2FsbGluZyAgcGNp
X3Nsb3RfaW5pdCsweDAvMHg1MCBAIDEKWyAgICAzLjcyODA2M10gaW5pdGNhbGwgcGNpX3Nsb3Rf
aW5pdCsweDAvMHg1MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyODE2OV0gY2Fs
bGluZyAgZmJtZW1faW5pdCsweDAvMHg5OCBAIDEKWyAgICAzLjcyODI3N10gaW5pdGNhbGwgZmJt
ZW1faW5pdCsweDAvMHg5OCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyODM3OV0g
Y2FsbGluZyAgYWNwaV9pbml0KzB4MC8weGI5IEAgMQpbICAgIDMuNzI4NDg4XSBBQ1BJOiBBZGRl
ZCBfT1NJKE1vZHVsZSBEZXZpY2UpClsgICAgMy43Mjg1ODhdIEFDUEk6IEFkZGVkIF9PU0koUHJv
Y2Vzc29yIERldmljZSkKWyAgICAzLjcyODY5MV0gQUNQSTogQWRkZWQgX09TSSgzLjAgX1NDUCBF
eHRlbnNpb25zKQpbICAgIDMuNzI4NzkyXSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dy
ZWdhdG9yIERldmljZSkKWyAgICAzLjczMDk0MF0gQUNQSTogRUM6IExvb2sgdXAgRUMgaW4gRFNE
VApbICAgIDMuNzMyOTgxXSBBQ1BJOiBFeGVjdXRlZCAxIGJsb2NrcyBvZiBtb2R1bGUtbGV2ZWwg
ZXhlY3V0YWJsZSBBTUwgY29kZQpbICAgIDMuNzM2NDg0XSBBQ1BJOiBTU0RUIDAwMDAwMDAwYmY1
MDQwMTggMDA4NkMgKHYwMSAgICBBTUkgICAgICBJU1QgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkK
WyAgICAzLjczNzMxOV0gQUNQSTogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKWyAgICAzLjczNzU2
NF0gQUNQSTogU1NEVCAgICAgICAgICAgKG51bGwpIDAwODZDICh2MDEgICAgQU1JICAgICAgSVNU
IDAwMDAwMDAxIE1TRlQgMDMwMDAwMDEpClsgICAgMy43Mzc5MjFdIEFDUEk6IFNTRFQgMDAwMDAw
MDBiZjUwNWUxOCAwMDFBNCAodjAxICAgIEFNSSAgICAgIENTVCAwMDAwMDAwMSBNU0ZUIDAzMDAw
MDAxKQpbICAgIDMuNzM4Njg5XSBBQ1BJOiBEeW5hbWljIE9FTSBUYWJsZSBMb2FkOgpbICAgIDMu
NzM4OTM5XSBBQ1BJOiBTU0RUICAgICAgICAgICAobnVsbCkgMDAxQTQgKHYwMSAgICBBTUkgICAg
ICBDU1QgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkKWyAgICAzLjczOTQ1Ml0gQUNQSTogSW50ZXJw
cmV0ZXIgZW5hYmxlZApbICAgIDMuNzM5NTUyXSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzEgUzQgUzUp
ClsgICAgMy43Mzk5NTNdIEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRpbmcK
WyAgICAzLjc0MDA5Ml0gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1cyAwMC1mZl0g
YXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDApClsgICAgMy43
NDAzMTJdIFBDSTogTU1DT05GSUcgYXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIHJlc2Vy
dmVkIGluIEFDUEkgbW90aGVyYm9hcmQgcmVzb3VyY2VzClsgICAgMy43NDcyNjVdIEZyZWVpbmcg
aW5pdHJkIG1lbW9yeTogNDA5NzZrIGZyZWVkClsgICAgMy43NTM3ODhdIGluaXRjYWxsIDFfYXN5
bmNfcG9wdWxhdGVfcm9vdGZzKzB4MC8weDM2IHJldHVybmVkIDAgYWZ0ZXIgMzkwNjQgdXNlY3MK
WyAgICAzLjgxNjEzNV0gW0Zpcm13YXJlIEJ1Z106IEFDUEk6IEJJT1MgX09TSShMaW51eCkgcXVl
cnkgaWdub3JlZApbICAgIDMuODIxNTI0XSBpbml0Y2FsbCBhY3BpX2luaXQrMHgwLzB4YjkgcmV0
dXJuZWQgMCBhZnRlciA4OTg0OSB1c2VjcwpbICAgIDMuODIxNjMwXSBjYWxsaW5nICBkb2NrX2lu
aXQrMHgwLzB4YTUgQCAxClsgICAgMy44MjE4ODBdIEFDUEk6IE5vIGRvY2sgZGV2aWNlcyBmb3Vu
ZC4KWyAgICAzLjgyMTk4MV0gaW5pdGNhbGwgZG9ja19pbml0KzB4MC8weGE1IHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuODIyMDg1XSBjYWxsaW5nICBhY3BpX3BjaV9yb290X2luaXQr
MHgwLzB4MmQgQCAxClsgICAgMy44MjIyMjFdIEhFU1Q6IFRhYmxlIHBhcnNpbmcgaGFzIGJlZW4g
aW5pdGlhbGl6ZWQuClsgICAgMy44MjIzMjRdIFBDSTogVXNpbmcgaG9zdCBicmlkZ2Ugd2luZG93
cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFuZCByZXBvcnQgYSBi
dWcKWyAgICAzLjgyMjcyNV0gQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kwXSAoZG9tYWluIDAw
MDAgW2J1cyAwMC1mZl0pClsgICAgMy44MjMxMDNdIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3Qg
YnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDAzYWZdClsgICAgMy44MjMyMDhdIHBjaV9yb290
IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDNlMC0weDBjZjddClsgICAg
My44MjMzMTBdIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4
MDNiMC0weDAzZGZdClsgICAgMy44MjM0MTZdIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3QgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMy44MjM1MjJdIHBjaV9yb290IFBO
UDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0K
WyAgICAzLjgyMzY0N10gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFtt
ZW0gMHgwMDBjMDAwMC0weDAwMGRmZmZmXQpbICAgIDMuODIzNzcxXSBwY2lfcm9vdCBQTlAwQTA4
OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGYwMDAwMDAwLTB4ZmJmZmZmZmZdClsgICAg
My44MjM5MTFdIHBjaSAwMDAwOjAwOjAwLjA6IFs4MDg2OjAxMDhdIHR5cGUgMCBjbGFzcyAweDAw
MDYwMApbICAgIDMuODI0MDk5XSBwY2kgMDAwMDowMDowMS4wOiBbODA4NjowMTAxXSB0eXBlIDEg
Y2xhc3MgMHgwMDA2MDQKWyAgICAzLjgyNDI4M10gcGNpIDAwMDA6MDA6MDEuMDogUE1FIyBzdXBw
b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAzLjgyNDM5MF0gcGNpIDAwMDA6MDA6MDEu
MDogUE1FIyBkaXNhYmxlZApbICAgIDMuODI0Njc5XSBwY2kgMDAwMDowMDoxOS4wOiBbODA4Njox
NTAyXSB0eXBlIDAgY2xhc3MgMHgwMDAyMDAKWyAgICAzLjgyNDg1Nl0gcGNpIDAwMDA6MDA6MTku
MDogcmVnIDEwOiBbbWVtIDB4ZmJiMDAwMDAtMHhmYmIxZmZmZl0KWyAgICAzLjgyNDk4OV0gcGNp
IDAwMDA6MDA6MTkuMDogcmVnIDE0OiBbbWVtIDB4ZmJiMjQwMDAtMHhmYmIyNGZmZl0KWyAgICAz
LjgyNTEyNV0gcGNpIDAwMDA6MDA6MTkuMDogcmVnIDE4OiBbaW8gIDB4ZjAyMC0weGYwM2ZdClsg
ICAgMy44MjU1MTBdIHBjaSAwMDAwOjAwOjE5LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNo
b3QgRDNjb2xkClsgICAgMy44MjU2MTldIHBjaSAwMDAwOjAwOjE5LjA6IFBNRSMgZGlzYWJsZWQK
WyAgICAzLjgyNTgwM10gcGNpIDAwMDA6MDA6MWEuMDogWzgwODY6MWMyZF0gdHlwZSAwIGNsYXNz
IDB4MDAwYzAzClsgICAgMy44MjU5ODBdIHBjaSAwMDAwOjAwOjFhLjA6IHJlZyAxMDogW21lbSAw
eGZiYjIzMDAwLTB4ZmJiMjMzZmZdClsgICAgMy44MjY0MzZdIHBjaSAwMDAwOjAwOjFhLjA6IFBN
RSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy44MjY1NDldIHBjaSAwMDAw
OjAwOjFhLjA6IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgyNjczM10gcGNpIDAwMDA6MDA6MWMuMDog
WzgwODY6MWMxMF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMy44MjcyMzldIHBjaSAwMDAw
OjAwOjFjLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy44Mjcz
NTVdIHBjaSAwMDAwOjAwOjFjLjA6IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgyNzU3NV0gcGNpIDAw
MDA6MDA6MWMuNDogWzgwODY6MWMxOF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMy44Mjgw
NzBdIHBjaSAwMDAwOjAwOjFjLjQ6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xk
ClsgICAgMy44MjgxODZdIHBjaSAwMDAwOjAwOjFjLjQ6IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgy
ODQwMl0gcGNpIDAwMDA6MDA6MWQuMDogWzgwODY6MWMyNl0gdHlwZSAwIGNsYXNzIDB4MDAwYzAz
ClsgICAgMy44Mjg1ODFdIHBjaSAwMDAwOjAwOjFkLjA6IHJlZyAxMDogW21lbSAweGZiYjIyMDAw
LTB4ZmJiMjIzZmZdClsgICAgMy44MjkwMzldIHBjaSAwMDAwOjAwOjFkLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy44MjkxNTFdIHBjaSAwMDAwOjAwOjFkLjA6
IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgyOTMxM10gcGNpIDAwMDA6MDA6MWUuMDogWzgwODY6MjQ0
ZV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMy44Mjk2OTJdIHBjaSAwMDAwOjAwOjFmLjA6
IFs4MDg2OjFjNTRdIHR5cGUgMCBjbGFzcyAweDAwMDYwMQpbICAgIDMuODMwMjcwXSBwY2kgMDAw
MDowMDoxZi4yOiBbODA4NjoyODIyXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDQKWyAgICAzLjgzMDQ1
M10gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDEwOiBbaW8gIDB4ZjA3MC0weGYwNzddClsgICAgMy44
MzA1ODRdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxNDogW2lvICAweGYwNjAtMHhmMDYzXQpbICAg
IDMuODMwNzE0XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTg6IFtpbyAgMHhmMDUwLTB4ZjA1N10K
WyAgICAzLjgzMDg0Nl0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDFjOiBbaW8gIDB4ZjA0MC0weGYw
NDNdClsgICAgMy44MzA5NzVdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAyMDogW2lvICAweGYwMDAt
MHhmMDFmXQpbICAgIDMuODMxMTA3XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMjQ6IFttZW0gMHhm
YmIyMTAwMC0weGZiYjIxN2ZmXQpbICAgIDMuODMxNDIxXSBwY2kgMDAwMDowMDoxZi4yOiBQTUUj
IHN1cHBvcnRlZCBmcm9tIEQzaG90ClsgICAgMy44MzE1MzFdIHBjaSAwMDAwOjAwOjFmLjI6IFBN
RSMgZGlzYWJsZWQKWyAgICAzLjgzMTY5M10gcGNpIDAwMDA6MDA6MWYuMzogWzgwODY6MWMyMl0g
dHlwZSAwIGNsYXNzIDB4MDAwYzA1ClsgICAgMy44MzE4NTVdIHBjaSAwMDAwOjAwOjFmLjM6IHJl
ZyAxMDogW21lbSAweGZiYjIwMDAwLTB4ZmJiMjAwZmYgNjRiaXRdClsgICAgMy44MzIwNTFdIHBj
aSAwMDAwOjAwOjFmLjM6IHJlZyAyMDogW2lvICAweDExODAtMHgxMTlmXQpbICAgIDMuODMyMzI5
XSBwY2kgMDAwMDowMTowMC4wOiBbMTAwMDowMDcyXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDcKWyAg
ICAzLjgzMjQ0M10gcGNpIDAwMDA6MDE6MDAuMDogcmVnIDEwOiBbaW8gIDB4ZTAwMC0weGUwZmZd
ClsgICAgMy44MzI1NTldIHBjaSAwMDAwOjAxOjAwLjA6IHJlZyAxNDogW21lbSAweGZiYWMwMDAw
LTB4ZmJhYzNmZmYgNjRiaXRdClsgICAgMy44MzI2NzldIHBjaSAwMDAwOjAxOjAwLjA6IHJlZyAx
YzogW21lbSAweGZmYTgwMDAwLTB4ZmZhYmZmZmYgNjRiaXRdClsgICAgMy44MzI4MDJdIHBjaSAw
MDAwOjAxOjAwLjA6IHJlZyAzMDogW21lbSAweGZiYTAwMDAwLTB4ZmJhN2ZmZmYgcHJlZl0KWyAg
ICAzLjgzMjk3MV0gcGNpIDAwMDA6MDE6MDAuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAzLjg0MTc4
N10gcGNpIDAwMDA6MDA6MDEuMDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXQpbICAgIDMuODQx
OTE0XSBwY2kgMDAwMDowMDowMS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZm
XQpbICAgIDMuODQyMDIwXSBwY2kgMDAwMDowMDowMS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw
eGZiYTAwMDAwLTB4ZmJhZmZmZmZdClsgICAgMy44NDIzNDZdIHBjaSAwMDAwOjAwOjFjLjA6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KWyAgICAzLjg0MjgzOV0gcGNpIDAwMDA6MDM6MDAuMDog
WzgwODY6MTBkM10gdHlwZSAwIGNsYXNzIDB4MDAwMjAwClsgICAgMy44NDI5OTVdIHBjaSAwMDAw
OjAzOjAwLjA6IHJlZyAxMDogW21lbSAweGZiOTAwMDAwLTB4ZmI5MWZmZmZdClsgICAgMy44NDMx
NzFdIHBjaSAwMDAwOjAzOjAwLjA6IHJlZyAxODogW2lvICAweGQwMDAtMHhkMDFmXQpbICAgIDMu
ODQzMzA5XSBwY2kgMDAwMDowMzowMC4wOiByZWcgMWM6IFttZW0gMHhmYjkyMDAwMC0weGZiOTIz
ZmZmXQpbICAgIDMuODQzNzU4XSBwY2kgMDAwMDowMzowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9t
IEQwIEQzaG90IEQzY29sZApbICAgIDMuODQzODcwXSBwY2kgMDAwMDowMzowMC4wOiBQTUUjIGRp
c2FibGVkClsgICAgMy44NTQwMjFdIHBjaSAwMDAwOjAwOjFjLjQ6IFBDSSBicmlkZ2UgdG8gW2J1
cyAwMy0wM10KWyAgICAzLjg1NDEzMF0gcGNpIDAwMDA6MDA6MWMuNDogICBicmlkZ2Ugd2luZG93
IFtpbyAgMHhkMDAwLTB4ZGZmZl0KWyAgICAzLjg1NDI0MF0gcGNpIDAwMDA6MDA6MWMuNDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmYjkwMDAwMC0weGZiOWZmZmZmXQpbICAgIDMuODU0NDg5XSBw
Y2kgMDAwMDowNDowMy4wOiBbMTAyYjowNTMyXSB0eXBlIDAgY2xhc3MgMHgwMDAzMDAKWyAgICAz
Ljg1NDY1MF0gcGNpIDAwMDA6MDQ6MDMuMDogcmVnIDEwOiBbbWVtIDB4ZmEwMDAwMDAtMHhmYWZm
ZmZmZiBwcmVmXQpbICAgIDMuODU0NzgyXSBwY2kgMDAwMDowNDowMy4wOiByZWcgMTQ6IFttZW0g
MHhmYjgwMDAwMC0weGZiODAzZmZmXQpbICAgIDMuODU0OTEwXSBwY2kgMDAwMDowNDowMy4wOiBy
ZWcgMTg6IFttZW0gMHhmYjAwMDAwMC0weGZiN2ZmZmZmXQpbICAgIDMuODU1Mzc1XSBwY2kgMDAw
MDowMDoxZS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdIChzdWJ0cmFjdGl2ZSBkZWNvZGUp
ClsgICAgMy44NTU0OTNdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4
ZmIwMDAwMDAtMHhmYjhmZmZmZl0KWyAgICAzLjg1NTYxM10gcGNpIDAwMDA6MDA6MWUuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAwMC0weGZhZmZmZmZmIDY0Yml0IHByZWZdClsgICAg
My44NTU3MzddIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0w
eDAzYWZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMy44NTU4NjBdIHBjaSAwMDAwOjAwOjFl
LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDNlMC0weDBjZjddIChzdWJ0cmFjdGl2ZSBkZWNv
ZGUpClsgICAgMy44NTU5ODJdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g
IDB4MDNiMC0weDAzZGZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMy44NTYxMDZdIHBjaSAw
MDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdIChzdWJ0cmFj
dGl2ZSBkZWNvZGUpClsgICAgMy44NTYyMjhdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0gKHN1YnRyYWN0aXZlIGRlY29kZSkKWyAg
ICAzLjg1NjM1NF0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBj
MDAwMC0weDAwMGRmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDMuODU2NDgxXSBwY2kg
MDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGYwMDAwMDAwLTB4ZmJmZmZmZmZd
IChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMy44NTY2NzVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQg
Um91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5fUFJUXQpbICAgIDMuODU2ODM2XSBBQ1BJOiBQQ0kg
SW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuQlIyMC5fUFJUXQpbICAgIDMuODU2
OTcwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEVYMC5f
UFJUXQpbICAgIDMuODU3MDkyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xf
U0JfLlBDSTAuUEVYNC5fUFJUXQpbICAgIDMuODU3MjE5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJv
dXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUDBQMS5fUFJUXQpbICAgIDMuODU3NDMyXSAgcGNpMDAw
MDowMDogUmVxdWVzdGluZyBBQ1BJIF9PU0MgY29udHJvbCAoMHgxZCkKWyAgICAzLjg1Nzc1OV0g
IHBjaTAwMDA6MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFjKSBncmFudGVkClsgICAgMy44NjA1
NjhdIGluaXRjYWxsIGFjcGlfcGNpX3Jvb3RfaW5pdCsweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVy
IDM5MDY0IHVzZWNzClsgICAgMy44NjA2NzJdIGNhbGxpbmcgIGFjcGlfcGNpX2xpbmtfaW5pdCsw
eDAvMHgzZSBAIDEKWyAgICAzLjg2MDgxMF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktB
XSAoSVJRcyAzIDQgNSA2IDcgMTAgKjExIDEyIDE0IDE1KQpbICAgIDMuODYxODE1XSBBQ1BJOiBQ
Q0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDMgNCAqNSA2IDcgMTAgMTEgMTIgMTQgMTUp
ClsgICAgMy44NjI4MjhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQ10gKElSUXMgMyA0
IDUgNiAxMCAqMTEgMTIgMTQgMTUpClsgICAgMy44NjM3NjRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQg
TGluayBbTE5LRF0gKElSUXMgMyA0IDUgNiAxMCAqMTEgMTIgMTQgMTUpClsgICAgMy44NjQ3MDNd
IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRV0gKElSUXMgMyA0IDUgNiAqNyAxMCAxMSAx
MiAxNCAxNSkKWyAgICAzLjg2NTcyM10gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktGXSAo
SVJRcyAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUpICowClsgICAgMy44NjY4NDNdIEFDUEk6IFBD
SSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1KSAq
MApbICAgIDMuODY3OTU2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFzIDMg
NCAqNSA2IDcgMTAgMTEgMTIgMTQgMTUpClsgICAgMy44Njg5NTVdIGluaXRjYWxsIGFjcGlfcGNp
X2xpbmtfaW5pdCsweDAvMHgzZSByZXR1cm5lZCAwIGFmdGVyIDc4MTIgdXNlY3MKWyAgICAzLjg2
OTA1OV0gY2FsbGluZyAgcG5wX2luaXQrMHgwLzB4MTIgQCAxClsgICAgMy44NjkxNjZdIGluaXRj
YWxsIHBucF9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuODY5
MjcxXSBjYWxsaW5nICB4ZW5fc2V0dXBfc2h1dGRvd25fZXZlbnQrMHgwLzB4MzAgQCAxClsgICAg
My44NjkzNzVdIGluaXRjYWxsIHhlbl9zZXR1cF9zaHV0ZG93bl9ldmVudCsweDAvMHgzMCByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg2OTQ5OV0gY2FsbGluZyAgYmFsbG9vbl9pbml0
KzB4MC8weDE5IEAgMQpbICAgIDMuODY5NjAxXSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJh
bGxvb24gZHJpdmVyLgpbICAgIDMuODkxMjEwXSBpbml0Y2FsbCBiYWxsb29uX2luaXQrMHgwLzB4
MTkgcmV0dXJuZWQgMCBhZnRlciAxOTUzMiB1c2VjcwpbICAgIDMuODkxMzE5XSBjYWxsaW5nICB4
ZW5idXNfcHJvYmVfYmFja2VuZF9pbml0KzB4MC8weDJhIEAgMQpbICAgIDMuODkxNDQzXSBpbml0
Y2FsbCB4ZW5idXNfcHJvYmVfYmFja2VuZF9pbml0KzB4MC8weDJhIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuODkxNTY3XSBjYWxsaW5nICB4ZW5idXNfcHJvYmVfZnJvbnRlbmRfaW5p
dCsweDAvMHgyYiBAIDEKWyAgICAzLjg5MTY3Nl0gaW5pdGNhbGwgeGVuYnVzX3Byb2JlX2Zyb250
ZW5kX2luaXQrMHgwLzB4MmIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTE4MDFd
IGNhbGxpbmcgIGJhbGxvb25faW5pdCsweDAvMHg0MSBAIDEKWyAgICAzLjg5MTkwMV0geGVuLWJh
bGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KWyAgICAzLjg5MjAyMl0gaW5pdGNh
bGwgYmFsbG9vbl9pbml0KzB4MC8weDQxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
ODkyMTI3XSBjYWxsaW5nICB4ZW5fc2VsZmJhbGxvb25faW5pdCsweDAvMHg4MyBAIDEKWyAgICAz
Ljg5MjIzNF0geGVuL2JhbGxvb246IFhlbiBzZWxmYmFsbG9vbmluZyBkcml2ZXIgZGlzYWJsZWQg
Zm9yIGRvbWFpbjAuClsgICAgMy44OTIzMzddIGluaXRjYWxsIHhlbl9zZWxmYmFsbG9vbl9pbml0
KzB4MC8weDgzIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgMy44OTI0NDJdIGNhbGxp
bmcgIHBtODYwN19yZWd1bGF0b3JfaW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjg5MjU1MV0gaW5p
dGNhbGwgcG04NjA3X3JlZ3VsYXRvcl9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1
c2VjcwpbICAgIDMuODkyNjU2XSBjYWxsaW5nICBhYjg1MDBfcmVndWxhdG9yX2luaXQrMHgwLzB4
MmUgQCAxClsgICAgMy44OTI3NjFdIGluaXRjYWxsIGFiODUwMF9yZWd1bGF0b3JfaW5pdCsweDAv
MHgyZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5Mjg2N10gY2FsbGluZyAgbWlz
Y19pbml0KzB4MC8weGI2IEAgMQpbICAgIDMuODkyOTc0XSBpbml0Y2FsbCBtaXNjX2luaXQrMHgw
LzB4YjYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTMwNzhdIGNhbGxpbmcgIHZn
YV9hcmJfZGV2aWNlX2luaXQrMHgwLzB4ZjEgQCAxClsgICAgMy44OTMyNTldIHZnYWFyYjogZGV2
aWNlIGFkZGVkOiBQQ0k6MDAwMDowNDowMy4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVtLGxv
Y2tzPW5vbmUKWyAgICAzLjg5MzM4NV0gdmdhYXJiOiBsb2FkZWQKWyAgICAzLjg5MzQ4MV0gdmdh
YXJiOiBicmlkZ2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA0OjAzLjAKWyAgICAzLjg5MzU4NF0g
aW5pdGNhbGwgdmdhX2FyYl9kZXZpY2VfaW5pdCsweDAvMHhmMSByZXR1cm5lZCAwIGFmdGVyIDAg
dXNlY3MKWyAgICAzLjg5MzY5MV0gY2FsbGluZyAgY25faW5pdCsweDAvMHg5ZSBAIDEKWyAgICAz
Ljg5Mzc5NV0gaW5pdGNhbGwgY25faW5pdCsweDAvMHg5ZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjg5Mzg5OV0gY2FsbGluZyAgcG04NjB4X2kyY19pbml0KzB4MC8weDMwIEAgMQpb
ICAgIDMuODk0MDA2XSBpbml0Y2FsbCBwbTg2MHhfaTJjX2luaXQrMHgwLzB4MzAgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy44OTQxMTBdIGNhbGxpbmcgIHN0bXBlX2luaXQrMHgwLzB4
MTQgQCAxClsgICAgMy44OTQyMTRdIGluaXRjYWxsIHN0bXBlX2luaXQrMHgwLzB4MTQgcmV0dXJu
ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTQzMTddIGNhbGxpbmcgIHRjMzU4OXhfaW5pdCsw
eDAvMHgxNCBAIDEKWyAgICAzLjg5NDQyMF0gaW5pdGNhbGwgdGMzNTg5eF9pbml0KzB4MC8weDE0
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuODk0NTIzXSBjYWxsaW5nICB3bTgzMXhf
aTJjX2luaXQrMHgwLzB4MzAgQCAxClsgICAgMy44OTQ2MjZdIGluaXRjYWxsIHdtODMxeF9pMmNf
aW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5NDczMV0gY2Fs
bGluZyAgd204MzF4X3NwaV9pbml0KzB4MC8weDI4IEAgMQpbICAgIDMuODk0ODM1XSBpbml0Y2Fs
bCB3bTgzMXhfc3BpX2luaXQrMHgwLzB4MjggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My44OTQ5NDBdIGNhbGxpbmcgIHdtODM1MF9pMmNfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAzLjg5
NTA0Nl0gaW5pdGNhbGwgd204MzUwX2kyY19pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuODk1MTUwXSBjYWxsaW5nICB0cHM2NTkxMF9pMmNfaW5pdCsweDAvMHgx
NCBAIDEKWyAgICAzLjg5NTI1N10gaW5pdGNhbGwgdHBzNjU5MTBfaTJjX2luaXQrMHgwLzB4MTQg
cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTUzNjJdIGNhbGxpbmcgIHRwczY1OTEy
X2kyY19pbml0KzB4MC8weDMwIEAgMQpbICAgIDMuODk1NDY2XSBpbml0Y2FsbCB0cHM2NTkxMl9p
MmNfaW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5NTU3MV0g
Y2FsbGluZyAgdHBzNjU5MTJfc3BpX2luaXQrMHgwLzB4MjggQCAxClsgICAgMy44OTU2ODBdIGlu
aXRjYWxsIHRwczY1OTEyX3NwaV9pbml0KzB4MC8weDI4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuODk1Nzg0XSBjYWxsaW5nICBkYTkwM3hfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAz
Ljg5NTg4N10gaW5pdGNhbGwgZGE5MDN4X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy44OTU5OTFdIGNhbGxpbmcgIG1heDg5MjVfaTJjX2luaXQrMHgwLzB4MzAg
QCAxClsgICAgMy44OTYwOTNdIGluaXRjYWxsIG1heDg5MjVfaTJjX2luaXQrMHgwLzB4MzAgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTYxOThdIGNhbGxpbmcgIG1heDg5OTdfaTJj
X2luaXQrMHgwLzB4MTQgQCAxClsgICAgMy44OTYzMDJdIGluaXRjYWxsIG1heDg5OTdfaTJjX2lu
aXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTY0MDZdIGNhbGxp
bmcgIG1heDg5OThfaTJjX2luaXQrMHgwLzB4MTQgQCAxClsgICAgMy44OTY1MTBdIGluaXRjYWxs
IG1heDg5OThfaTJjX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My44OTY2MTNdIGNhbGxpbmcgIGFiMzEwMF9pMmNfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAzLjg5
NjcxOF0gaW5pdGNhbGwgYWIzMTAwX2kyY19pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuODk2ODIzXSBjYWxsaW5nICBhYjg1MDBfc3lzY3RybF9pbml0KzB4MC8w
eDEyIEAgMQpbICAgIDMuODk2OTMyXSBpbml0Y2FsbCBhYjg1MDBfc3lzY3RybF9pbml0KzB4MC8w
eDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuODk3MDM2XSBjYWxsaW5nICBhYjg1
MDBfZGVidWdfaW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjg5NzE0Ml0gaW5pdGNhbGwgYWI4NTAw
X2RlYnVnX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTcy
NDddIGNhbGxpbmcgIHRwczY1ODZ4X2luaXQrMHgwLzB4MTQgQCAxClsgICAgMy44OTczNTJdIGlu
aXRjYWxsIHRwczY1ODZ4X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsg
ICAgMy44OTc0NTNdIGNhbGxpbmcgIGFhdDI4NzBfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAzLjg5
NzU1N10gaTJjLWNvcmU6IGRyaXZlciBbYWF0Mjg3MF0gdXNpbmcgbGVnYWN5IHN1c3BlbmQgbWV0
aG9kClsgICAgMy44OTc2NjBdIGkyYy1jb3JlOiBkcml2ZXIgW2FhdDI4NzBdIHVzaW5nIGxlZ2Fj
eSByZXN1bWUgbWV0aG9kClsgICAgMy44OTc3NjVdIGluaXRjYWxsIGFhdDI4NzBfaW5pdCsweDAv
MHgxNCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5Nzg2OF0gY2FsbGluZyAgaW5p
dF9zY3NpKzB4MC8weDhlIEAgMQpbICAgIDMuODk4MDEyXSBTQ1NJIHN1YnN5c3RlbSBpbml0aWFs
aXplZApbICAgIDMuODk4MTEyXSBpbml0Y2FsbCBpbml0X3Njc2krMHgwLzB4OGUgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy44OTgyMTNdIGNhbGxpbmcgIGF0YV9pbml0KzB4MC8weDVj
IEAgMQpbICAgIDMuODk4MzY3XSBsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4KWyAgICAzLjg5
ODQ2OF0gaW5pdGNhbGwgYXRhX2luaXQrMHgwLzB4NWMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy44OTg1NzFdIGNhbGxpbmcgIHBoeV9pbml0KzB4MC8weDJlIEAgMQpbICAgIDMuODk4
Njg4XSBpbml0Y2FsbCBwaHlfaW5pdCsweDAvMHgyZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjg5ODc5M10gY2FsbGluZyAgdXNiX2luaXQrMHgwLzB4MTVjIEAgMQpbICAgIDMuODk4
OTExXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzClsgICAg
My44OTkwMTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaHViClsg
ICAgMy44OTkxNTRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiClsg
ICAgMy44OTkyNTddIGluaXRjYWxsIHVzYl9pbml0KzB4MC8weDE1YyByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjg5OTM2MV0gY2FsbGluZyAgc2VyaW9faW5pdCsweDAvMHgyZSBAIDEK
WyAgICAzLjg5OTQ2NV0gaW5pdGNhbGwgc2VyaW9faW5pdCsweDAvMHgyZSByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICAzLjg5OTU3MF0gY2FsbGluZyAgaW5wdXRfaW5pdCsweDAvMHgzYyBA
IDEKWyAgICAzLjg5OTY3Nl0gaW5pdGNhbGwgaW5wdXRfaW5pdCsweDAvMHgzYyByZXR1cm5lZCAw
IGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5OTc4M10gY2FsbGluZyAgcnRjX2luaXQrMHgwLzB4NmEg
QCAxClsgICAgMy44OTk4ODZdIGluaXRjYWxsIHJ0Y19pbml0KzB4MC8weDZhIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuODk5OTg4XSBjYWxsaW5nICBwb3dlcl9zdXBwbHlfY2xhc3Nf
aW5pdCsweDAvMHg0MCBAIDEKWyAgICAzLjkwMDA5NF0gaW5pdGNhbGwgcG93ZXJfc3VwcGx5X2Ns
YXNzX2luaXQrMHgwLzB4NDAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45MDAyMThd
IGNhbGxpbmcgIGh3bW9uX2luaXQrMHgwLzB4NDcgQCAxClsgICAgMy45MDAzMjFdIGluaXRjYWxs
IGh3bW9uX2luaXQrMHgwLzB4NDcgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45MDA0
MjNdIGNhbGxpbmcgIG1kX2luaXQrMHgwLzB4MTQwIEAgMQpbICAgIDMuOTAwNTU2XSBpbml0Y2Fs
bCBtZF9pbml0KzB4MC8weDE0MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkwMDY2
MF0gY2FsbGluZyAgbW1jX2luaXQrMHgwLzB4NzEgQCAxClsgICAgMy45MDA3NzVdIGluaXRjYWxs
IG1tY19pbml0KzB4MC8weDcxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTAwODc5
XSBjYWxsaW5nICBsZWRzX2luaXQrMHgwLzB4NDQgQCAxClsgICAgMy45MDA5ODNdIGluaXRjYWxs
IGxlZHNfaW5pdCsweDAvMHg0NCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkwMTA4
Nl0gY2FsbGluZyAgZGV2ZnJlcV9pbml0KzB4MC8weDUxIEAgMQpbICAgIDMuOTAxMTkxXSBpbml0
Y2FsbCBkZXZmcmVxX2luaXQrMHgwLzB4NTEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My45MDEyOTZdIGNhbGxpbmcgIHBjaV9zdWJzeXNfaW5pdCsweDAvMHg0YSBAIDEKWyAgICAzLjkw
MTM5Nl0gUENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwpbICAgIDMuOTMzOTk5XSBQQ0k6
IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzClsgICAgMy45MzQxNTldIHBjaSAw
MDAwOjAxOjAwLjA6IG5vIGNvbXBhdGlibGUgYnJpZGdlIHdpbmRvdyBmb3IgW21lbSAweGZmYTgw
MDAwLTB4ZmZhYmZmZmYgNjRiaXRdClsgICAgMy45MzQ0MjBdIHJlc2VydmUgUkFNIGJ1ZmZlcjog
MDAwMDAwMDAwMDA4ZDAwMCAtIDAwMDAwMDAwMDAwOGZmZmYgClsgICAgMy45MzQ1MDNdIHJlc2Vy
dmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBiZTdhNTAwMCAtIDAwMDAwMDAwYmZmZmZmZmYgClsgICAg
My45MzQ2NzldIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBiZjRhZjAwMCAtIDAwMDAwMDAw
YmZmZmZmZmYgClsgICAgMy45MzQ4NTBdIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBiZjgw
MDAwMCAtIDAwMDAwMDAwYmZmZmZmZmYgClsgICAgMy45MzUwMjBdIHJlc2VydmUgUkFNIGJ1ZmZl
cjogMDAwMDAwMDMwMTVjZjAwMCAtIDAwMDAwMDAzMDNmZmZmZmYgClsgICAgMy45MzUxOTVdIGlu
aXRjYWxsIHBjaV9zdWJzeXNfaW5pdCsweDAvMHg0YSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjkzNTM4NF0gY2FsbGluZyAgcHJvdG9faW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjkz
NTQ4Ml0gaW5pdGNhbGwgcHJvdG9faW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjkzNTU4NF0gY2FsbGluZyAgbmV0X2Rldl9pbml0KzB4MC8weDIzNyBAIDEKWyAg
ICAzLjkzNTc0Nl0gaW5pdGNhbGwgbmV0X2Rldl9pbml0KzB4MC8weDIzNyByZXR1cm5lZCAwIGFm
dGVyIDM5MDYgdXNlY3MKWyAgICAzLjkzNTg0OV0gY2FsbGluZyAgbmVpZ2hfaW5pdCsweDAvMHg4
MCBAIDEKWyAgICAzLjkzNTk0N10gaW5pdGNhbGwgbmVpZ2hfaW5pdCsweDAvMHg4MCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkzNjA0OV0gY2FsbGluZyAgZmliX3J1bGVzX2luaXQr
MHgwLzB4YWMgQCAxClsgICAgMy45MzYxNDhdIGluaXRjYWxsIGZpYl9ydWxlc19pbml0KzB4MC8w
eGFjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTM2MjQ2XSBjYWxsaW5nICBwa3Rz
Y2hlZF9pbml0KzB4MC8weGZjIEAgMQpbICAgIDMuOTM2MzQ2XSBpbml0Y2FsbCBwa3RzY2hlZF9p
bml0KzB4MC8weGZjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTM2NDQ3XSBjYWxs
aW5nICB0Y19maWx0ZXJfaW5pdCsweDAvMHg1NSBAIDEKWyAgICAzLjkzNjU0Nl0gaW5pdGNhbGwg
dGNfZmlsdGVyX2luaXQrMHgwLzB4NTUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45
MzY2NDhdIGNhbGxpbmcgIHRjX2FjdGlvbl9pbml0KzB4MC8weDU1IEAgMQpbICAgIDMuOTM2NzQ5
XSBpbml0Y2FsbCB0Y19hY3Rpb25faW5pdCsweDAvMHg1NSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjkzNjg1MF0gY2FsbGluZyAgZ2VubF9pbml0KzB4MC8weDkxIEAgMQpbICAgIDMu
OTM2OTU5XSBpbml0Y2FsbCBnZW5sX2luaXQrMHgwLzB4OTEgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgMy45MzcwNjFdIGNhbGxpbmcgIGNpcHNvX3Y0X2luaXQrMHgwLzB4NWUgQCAxClsg
ICAgMy45MzcxNjJdIGluaXRjYWxsIGNpcHNvX3Y0X2luaXQrMHgwLzB4NWUgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy45MzcyNjVdIGNhbGxpbmcgIHdpcmVsZXNzX25sZXZlbnRfaW5p
dCsweDAvMHgxMiBAIDEKWyAgICAzLjkzNzM2MV0gaW5pdGNhbGwgd2lyZWxlc3NfbmxldmVudF9p
bml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTM5MTg2XSBjYWxs
aW5nICBuZXRsYmxfaW5pdCsweDAvMHg4MSBAIDEKWyAgICAzLjkzOTI4Nl0gTmV0TGFiZWw6IElu
aXRpYWxpemluZwpbICAgIDMuOTM5Mzg2XSBOZXRMYWJlbDogIGRvbWFpbiBoYXNoIHNpemUgPSAx
MjgKWyAgICAzLjkzOTQ4M10gTmV0TGFiZWw6ICBwcm90b2NvbHMgPSBVTkxBQkVMRUQgQ0lQU092
NApbICAgIDMuOTM5NTkwXSBOZXRMYWJlbDogIHVubGFiZWxlZCB0cmFmZmljIGFsbG93ZWQgYnkg
ZGVmYXVsdApbICAgIDMuOTM5NjkyXSBpbml0Y2FsbCBuZXRsYmxfaW5pdCsweDAvMHg4MSByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkzOTc5Nl0gY2FsbGluZyAgcmZraWxsX2luaXQr
MHgwLzB4OTUgQCAxClsgICAgMy45Mzk5MzNdIGluaXRjYWxsIHJma2lsbF9pbml0KzB4MC8weDk1
IHJldHVybmVkIDAgYWZ0ZXIgMzkwNiB1c2VjcwpbICAgIDMuOTQwMDM4XSBjYWxsaW5nICBzeXNj
dGxfaW5pdCsweDAvMHg0OCBAIDEKWyAgICAzLjk0MDEzN10gaW5pdGNhbGwgc3lzY3RsX2luaXQr
MHgwLzB4NDggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45NDAyNDBdIGNhbGxpbmcg
IGFiODUwMF9ncGFkY19pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTQwMzUxXSBpbml0Y2FsbCBh
Yjg1MDBfZ3BhZGNfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAz
Ljk0MDQ1OF0gY2FsbGluZyAgaHBldF9sYXRlX2luaXQrMHgwLzB4NGEgQCAxClsgICAgMy45NDA1
NTldIGluaXRjYWxsIGhwZXRfbGF0ZV9pbml0KzB4MC8weDRhIHJldHVybmVkIC0xOSBhZnRlciAw
IHVzZWNzClsgICAgMy45NDA2NjNdIGNhbGxpbmcgIGluaXRfYW1kX25icysweDAvMHgzZCBAIDEK
WyAgICAzLjk0MDc3MF0gaW5pdGNhbGwgaW5pdF9hbWRfbmJzKzB4MC8weDNkIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTQwODc1XSBjYWxsaW5nICBjbG9ja3NvdXJjZV9kb25lX2Jv
b3RpbmcrMHgwLzB4NWEgQCAxClsgICAgMy45NDA5NzldIFN3aXRjaGluZyB0byBjbG9ja3NvdXJj
ZSB4ZW4KWyAgICAzLjk0MTA5MF0gaW5pdGNhbGwgY2xvY2tzb3VyY2VfZG9uZV9ib290aW5nKzB4
MC8weDVhIHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDMuOTQxMjE1XSBjYWxsaW5nICBm
dHJhY2VfaW5pdF9kZWJ1Z2ZzKzB4MC8weGQzIEAgMQpbICAgIDMuOTQxMzMwXSBpbml0Y2FsbCBm
dHJhY2VfaW5pdF9kZWJ1Z2ZzKzB4MC8weGQzIHJldHVybmVkIDAgYWZ0ZXIgMTIgdXNlY3MKWyAg
ICAzLjk0MTQzNV0gY2FsbGluZyAgcmJfaW5pdF9kZWJ1Z2ZzKzB4MC8weDJmIEAgMQpbICAgIDMu
OTQxNTM5XSBpbml0Y2FsbCByYl9pbml0X2RlYnVnZnMrMHgwLzB4MmYgcmV0dXJuZWQgMCBhZnRl
ciAwIHVzZWNzClsgICAgMy45NDE2NDRdIGNhbGxpbmcgIHRyYWNlcl9pbml0X2RlYnVnZnMrMHgw
LzB4MmZjIEAgMQpbICAgIDMuOTQxNzk0XSBpbml0Y2FsbCB0cmFjZXJfaW5pdF9kZWJ1Z2ZzKzB4
MC8weDJmYyByZXR1cm5lZCAwIGFmdGVyIDQ2IHVzZWNzClsgICAgMy45NDE5MDBdIGNhbGxpbmcg
IGluaXRfdHJhY2VfcHJpbnRrX2Z1bmN0aW9uX2V4cG9ydCsweDAvMHgyZiBAIDEKWyAgICAzLjk0
MjAwNl0gaW5pdGNhbGwgaW5pdF90cmFjZV9wcmludGtfZnVuY3Rpb25fZXhwb3J0KzB4MC8weDJm
IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAgIDMuOTQyMTI3XSBjYWxsaW5nICBldmVudF90
cmFjZV9pbml0KzB4MC8weDFiNSBAIDEKWyAgICAzLjk0NzEyMl0gaW5pdGNhbGwgZXZlbnRfdHJh
Y2VfaW5pdCsweDAvMHgxYjUgcmV0dXJuZWQgMCBhZnRlciA0Nzc2IHVzZWNzClsgICAgMy45NDcy
MjldIGNhbGxpbmcgIGluaXRfa3Byb2JlX3RyYWNlKzB4MC8weDk0IEAgMQpbICAgIDMuOTQ3MzM1
XSBpbml0Y2FsbCBpbml0X2twcm9iZV90cmFjZSsweDAvMHg5NCByZXR1cm5lZCAwIGFmdGVyIDMg
dXNlY3MKWyAgICAzLjk0NzQ0MV0gY2FsbGluZyAgaW5pdF9waXBlX2ZzKzB4MC8weDRiIEAgMQpb
ICAgIDMuOTQ3NTQ5XSBpbml0Y2FsbCBpbml0X3BpcGVfZnMrMHgwLzB4NGIgcmV0dXJuZWQgMCBh
ZnRlciA4IHVzZWNzClsgICAgMy45NDc2NTRdIGNhbGxpbmcgIGV2ZW50cG9sbF9pbml0KzB4MC8w
eGRhIEAgMQpbICAgIDMuOTQ3NzU2XSBpbml0Y2FsbCBldmVudHBvbGxfaW5pdCsweDAvMHhkYSBy
ZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICAzLjk0Nzg1OF0gY2FsbGluZyAgYW5vbl9pbm9k
ZV9pbml0KzB4MC8weDdkIEAgMQpbICAgIDMuOTQ3OTY1XSBpbml0Y2FsbCBhbm9uX2lub2RlX2lu
aXQrMHgwLzB4N2QgcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzClsgICAgMy45NDgwNzBdIGNhbGxp
bmcgIHRvbW95b19pbml0ZXJmYWNlX2luaXQrMHgwLzB4MjcgQCAxClsgICAgMy45NDgxNjldIGlu
aXRjYWxsIHRvbW95b19pbml0ZXJmYWNlX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy45NDgyNzVdIGNhbGxpbmcgIGFhX2NyZWF0ZV9hYWZzKzB4MC8weDkyIEAg
MQpbICAgIDMuOTQ4NDAzXSBBcHBBcm1vcjogQXBwQXJtb3IgRmlsZXN5c3RlbSBFbmFibGVkClsg
ICAgMy45NDg1MDRdIGluaXRjYWxsIGFhX2NyZWF0ZV9hYWZzKzB4MC8weDkyIHJldHVybmVkIDAg
YWZ0ZXIgMTI0IHVzZWNzClsgICAgMy45NDg2MDddIGNhbGxpbmcgIGJsa19zY3NpX2lvY3RsX2lu
aXQrMHgwLzB4ZCBAIDEKWyAgICAzLjk0ODcwN10gaW5pdGNhbGwgYmxrX3Njc2lfaW9jdGxfaW5p
dCsweDAvMHhkIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTQ4ODEwXSBjYWxsaW5n
ICBhY3BpX2V2ZW50X2luaXQrMHgwLzB4N2QgQCAxClsgICAgMy45NDg5MTddIGluaXRjYWxsIGFj
cGlfZXZlbnRfaW5pdCsweDAvMHg3ZCByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MKWyAgICAzLjk0
OTAyMl0gY2FsbGluZyAgcG5wX3N5c3RlbV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTQ5MTM5
XSBpbml0Y2FsbCBwbnBfc3lzdGVtX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAxMyB1
c2VjcwpbICAgIDMuOTQ5MjQ0XSBjYWxsaW5nICBwbnBhY3BpX2luaXQrMHgwLzB4OGMgQCAxClsg
ICAgMy45NDkzNDVdIHBucDogUG5QIEFDUEkgaW5pdApbICAgIDMuOTQ5NDUzXSBBQ1BJOiBidXMg
dHlwZSBwbnAgcmVnaXN0ZXJlZApbICAgIDMuOTQ5NzIwXSBwbnAgMDA6MDA6IFtidXMgMDAtZmZd
ClsgICAgMy45NDk4MTldIHBucCAwMDowMDogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDMuOTQ5
OTIwXSBwbnAgMDA6MDA6IFtpbyAgMHgwMDAwLTB4MDNhZiB3aW5kb3ddClsgICAgMy45NTAwMjFd
IHBucCAwMDowMDogW2lvICAweDAzZTAtMHgwY2Y3IHdpbmRvd10KWyAgICAzLjk1MDEyMl0gcG5w
IDAwOjAwOiBbaW8gIDB4MDNiMC0weDAzZGYgd2luZG93XQpbICAgIDMuOTUwMjI0XSBwbnAgMDA6
MDA6IFtpbyAgMHgwZDAwLTB4ZmZmZiB3aW5kb3ddClsgICAgMy45NTAzMjZdIHBucCAwMDowMDog
W21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmYgd2luZG93XQpbICAgIDMuOTUwNDI4XSBwbnAgMDA6
MDA6IFttZW0gMHgwMDBjMDAwMC0weDAwMGRmZmZmIHdpbmRvd10KWyAgICAzLjk1MDUyOV0gcG5w
IDAwOjAwOiBbbWVtIDB4ZjAwMDAwMDAtMHhmYmZmZmZmZiB3aW5kb3ddClsgICAgMy45NTA2MzFd
IHBucCAwMDowMDogW21lbSAweDAwMDAwMDAwIHdpbmRvd10KWyAgICAzLjk1MDc4OF0gcG5wIDAw
OjAwOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwOCBQTlAwYTAzIChhY3Rp
dmUpClsgICAgMy45NTA5ODFdIHBucCAwMDowMTogW21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZd
ClsgICAgMy45NTEwODFdIHBucCAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdClsg
ICAgMy45NTExODJdIHBucCAwMDowMTogW21lbSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdClsgICAg
My45NTEyODRdIHBucCAwMDowMTogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdClsgICAgMy45
NTEzODVdIHBucCAwMDowMTogW21lbSAweGZlZTAwMDAwLTB4ZmVlMGZmZmZdClsgICAgMy45NTE1
MTVdIHN5c3RlbSAwMDowMTogW21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZdIGhhcyBiZWVuIHJl
c2VydmVkClsgICAgMy45NTE2MTldIHN5c3RlbSAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZm
ZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy45NTE3MjJdIHN5c3RlbSAwMDowMTogW21l
bSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy45NTE4MjZd
IHN5c3RlbSAwMDowMTogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdIGhhcyBiZWVuIHJlc2Vy
dmVkClsgICAgMy45NTE5MzFdIHN5c3RlbSAwMDowMTogW21lbSAweGZlZTAwMDAwLTB4ZmVlMGZm
ZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDMuOTUyMDM3XSBzeXN0ZW0gMDA6MDE6IFBs
dWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAxIChhY3RpdmUpClsgICAgMy45NTIx
NTNdIHBucCAwMDowMjogW2RtYSA0XQpbICAgIDMuOTUyMjUxXSBwbnAgMDA6MDI6IFtpbyAgMHgw
MDAwLTB4MDAwZl0KWyAgICAzLjk1MjM1MF0gcG5wIDAwOjAyOiBbaW8gIDB4MDA4MS0weDAwODNd
ClsgICAgMy45NTI0NTFdIHBucCAwMDowMjogW2lvICAweDAwODddClsgICAgMy45NTI1NDldIHBu
cCAwMDowMjogW2lvICAweDAwODktMHgwMDhiXQpbICAgIDMuOTUyNjQ4XSBwbnAgMDA6MDI6IFtp
byAgMHgwMDhmXQpbICAgIDMuOTUyNzQ2XSBwbnAgMDA6MDI6IFtpbyAgMHgwMGMwLTB4MDBkZl0K
WyAgICAzLjk1Mjg2NF0gcG5wIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDIwMCAoYWN0aXZlKQpbICAgIDMuOTUyOTc4XSBwbnAgMDA6MDM6IFtpbyAgMHgwMDcwLTB4
MDA3MV0KWyAgICAzLjk1MzA3OF0geGVuOiByZWdpc3RlcmluZyBnc2kgOCB0cmlnZ2VyaW5nIDEg
cG9sYXJpdHkgMApbICAgIDMuOTUzMTg4XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx
IDggZm9yIGdzaSA4ClsgICAgMy45NTMyOTFdIHhlbjogLS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3Np
PTgpClsgICAgMy45NTM0MTldIHBucCAwMDowMzogW2lycSA4XQpbICAgIDMuOTUzNTM0XSBwbnAg
MDA6MDM6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYjAwIChhY3RpdmUpClsg
ICAgMy45NTM2NDRdIHBucCAwMDowNDogW2lvICAweDAwNjFdClsgICAgMy45NTM3NTddIHBucCAw
MDowNDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA4MDAgKGFjdGl2ZSkKWyAg
ICAzLjk1Mzg3OV0gcG5wIDAwOjA1OiBbaW8gIDB4MDAxMC0weDAwMWZdClsgICAgMy45NTM5Nzhd
IHBucCAwMDowNTogW2lvICAweDAwMjItMHgwMDNmXQpbICAgIDMuOTU0MDc3XSBwbnAgMDA6MDU6
IFtpbyAgMHgwMDQ0LTB4MDA1Zl0KWyAgICAzLjk1NDE3N10gcG5wIDAwOjA1OiBbaW8gIDB4MDA2
Mi0weDAwNjNdClsgICAgMy45NTQyNzhdIHBucCAwMDowNTogW2lvICAweDAwNjUtMHgwMDZmXQpb
ICAgIDMuOTU0Mzc2XSBwbnAgMDA6MDU6IFtpbyAgMHgwMDcyLTB4MDA3Zl0KWyAgICAzLjk1NDQ3
NF0gcG5wIDAwOjA1OiBbaW8gIDB4MDA4MF0KWyAgICAzLjk1NDU3Ml0gcG5wIDAwOjA1OiBbaW8g
IDB4MDA4NC0weDAwODZdClsgICAgMy45NTQ2NzJdIHBucCAwMDowNTogW2lvICAweDAwODhdClsg
ICAgMy45NTQ3NjhdIHBucCAwMDowNTogW2lvICAweDAwOGMtMHgwMDhlXQpbICAgIDMuOTU0ODY4
XSBwbnAgMDA6MDU6IFtpbyAgMHgwMDkwLTB4MDA5Zl0KWyAgICAzLjk1NDk2OV0gcG5wIDAwOjA1
OiBbaW8gIDB4MDBhMi0weDAwYmZdClsgICAgMy45NTUwNjhdIHBucCAwMDowNTogW2lvICAweDAw
ZTAtMHgwMGVmXQpbICAgIDMuOTU1MTY4XSBwbnAgMDA6MDU6IFtpbyAgMHgwNGQwLTB4MDRkMV0K
WyAgICAzLjk1NTI5N10gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVu
IHJlc2VydmVkClsgICAgMy45NTU0MDBdIHN5c3RlbSAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJ
IGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAzLjk1NTUxMF0gcG5wIDAwOjA2OiBb
aW8gIDB4MDBmMC0weDAwZmZdClsgICAgMy45NTU2MTBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDEz
IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwClsgICAgMy45NTU3MTJdIHhlbl9tYXBfcGlycV9nc2k6
IHJldHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwpbICAgIDMuOTU1ODEzXSB4ZW46IC0tPiBwaXJx
PTEzIC0+IGlycT0xMyAoZ3NpPTEzKQpbICAgIDMuOTU1OTQyXSBwbnAgMDA6MDY6IFtpcnEgMTNd
ClsgICAgMy45NTYwNTddIHBucCAwMDowNjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDBjMDQgKGFjdGl2ZSkKWyAgICAzLjk1NjI0OV0gcG5wIDAwOjA3OiBbaW8gIDB4MDAwMC0w
eGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NTYzNTNdIHBucCAwMDowNzogW2lv
ICAweDBhMDAtMHgwYTFmXQpbICAgIDMuOTU2NDUxXSBwbnAgMDA6MDc6IFtpbyAgMHgwYTMwLTB4
MGEzZl0KWyAgICAzLjk1NjU1Ml0gcG5wIDAwOjA3OiBbaW8gIDB4MDAwMC0weGZmZmZmZmZmZmZm
ZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NTY2ODNdIHN5c3RlbSAwMDowNzogW2lvICAweDBhMDAt
MHgwYTFmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuOTU2Nzg2XSBzeXN0ZW0gMDA6MDc6IFtp
byAgMHgwYTMwLTB4MGEzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjk1Njg5MF0gc3lzdGVt
IDAwOjA3OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAoYWN0aXZlKQpb
ICAgIDMuOTU3MDEwXSBwbnAgMDA6MDg6IFtpbyAgMHgwMDYwXQpbICAgIDMuOTU3MTExXSBwbnAg
MDA6MDg6IFtpbyAgMHgwMDY0XQpbICAgIDMuOTU3MjA5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwClsgICAgMy45NTczMTRdIHhlbl9tYXBfcGlycV9nc2k6
IHJldHVybmluZyBpcnEgMSBmb3IgZ3NpIDEKWyAgICAzLjk1NzQxNl0geGVuOiAtLT4gcGlycT0x
IC0+IGlycT0xIChnc2k9MSkKWyAgICAzLjk1NzU0NF0gcG5wIDAwOjA4OiBbaXJxIDFdClsgICAg
My45NTc2NjRdIHBucCAwMDowODogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAz
MDMgUE5QMDMwYiAoYWN0aXZlKQpbICAgIDMuOTU3ODEzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
MiB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDMuOTU3OTE1XSB4ZW5fbWFwX3BpcnFfZ3Np
OiByZXR1cm5pbmcgaXJxIDEyIGZvciBnc2kgMTIKWyAgICAzLjk1ODAxN10geGVuOiAtLT4gcGly
cT0xMiAtPiBpcnE9MTIgKGdzaT0xMikKWyAgICAzLjk1ODE0M10gcG5wIDAwOjA5OiBbaXJxIDEy
XQpbICAgIDMuOTU4MjY1XSBwbnAgMDA6MDk6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE
cyBQTlAwZjAzIFBOUDBmMTMgKGFjdGl2ZSkKWyAgICAzLjk1ODY3Nl0gcG5wIDAwOjBhOiBbaW8g
IDB4MDNmOC0weDAzZmZdClsgICAgMy45NTg3NzVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDQgdHJp
Z2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAzLjk1ODg3N10geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSA0IGZvciBnc2kgNApbICAgIDMuOTU4OTc4XSB4ZW46IC0tPiBwaXJxPTQgLT4g
aXJxPTQgKGdzaT00KQpbICAgIDMuOTU5MTA2XSBwbnAgMDA6MGE6IFtpcnEgNF0KWyAgICAzLjk1
OTIwNF0gcG5wIDAwOjBhOiBbZG1hIDAgZGlzYWJsZWRdClsgICAgMy45NTkzNTFdIHBucCAwMDow
YTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEgKGFjdGl2ZSkKWyAgICAz
Ljk1OTczNl0gcG5wIDAwOjBiOiBbaW8gIDB4MDJmOC0weDAyZmZdClsgICAgMy45NTk4MzZdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDMgdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAzLjk1OTkz
OV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAzIGZvciBnc2kgMwpbICAgIDMuOTYw
MDM5XSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQpbICAgIDMuOTYwMTY2XSBwbnAg
MDA6MGI6IFtpcnEgM10KWyAgICAzLjk2MDI2M10gcG5wIDAwOjBiOiBbZG1hIDAgZGlzYWJsZWRd
ClsgICAgMy45NjA0MDVdIHBucCAwMDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDA1MDEgKGFjdGl2ZSkKWyAgICAzLjk2MDYwMl0gcG5wIDAwOjBjOiBbaW8gIDB4MDAwMC0w
eGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NjA3MDZdIHBucCAwMDowYzogW2lv
ICAweDBiMDAtMHgwYjdmXQpbICAgIDMuOTYwODA2XSBwbnAgMDA6MGM6IFtpbyAgMHgwMDAwLTB4
ZmZmZmZmZmZmZmZmZmZmZiBkaXNhYmxlZF0KWyAgICAzLjk2MDkwOF0gcG5wIDAwOjBjOiBbaW8g
IDB4MDAwMC0weGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NjEwMTFdIHBucCAw
MDowYzogW2lvICAweDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZmIGRpc2FibGVkXQpbICAgIDMuOTYx
MTQ4XSBzeXN0ZW0gMDA6MGM6IFtpbyAgMHgwYjAwLTB4MGI3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQK
WyAgICAzLjk2MTI1M10gc3lzdGVtIDAwOjBjOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJ
RHMgUE5QMGMwMiAoYWN0aXZlKQpbICAgIDMuOTYxNTg5XSBwbnAgMDA6MGQ6IFtpbyAgMHgwM2U4
LTB4MDNlZl0KWyAgICAzLjk2MTY5MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTAgdHJpZ2dlcmlu
ZyAxIHBvbGFyaXR5IDAKWyAgICAzLjk2MTc5M10geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n
IGlycSAxMCBmb3IgZ3NpIDEwClsgICAgMy45NjE4OTRdIHhlbjogLS0+IHBpcnE9MTAgLT4gaXJx
PTEwIChnc2k9MTApClsgICAgMy45NjIwMjJdIHBucCAwMDowZDogW2lycSAxMF0KWyAgICAzLjk2
MjEyMV0gcG5wIDAwOjBkOiBbZG1hIDAgZGlzYWJsZWRdClsgICAgMy45NjIyNTldIHBucCAwMDow
ZDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEgKGFjdGl2ZSkKWyAgICAz
Ljk2MjU3MV0gcG5wIDAwOjBlOiBbaW8gIDB4MDQwMC0weDA0NTNdClsgICAgMy45NjI2NzJdIHBu
cCAwMDowZTogW2lvICAweDA0NTgtMHgwNDdmXQpbICAgIDMuOTYyNzczXSBwbnAgMDA6MGU6IFtp
byAgMHgxMTgwLTB4MTE5Zl0KWyAgICAzLjk2Mjg3M10gcG5wIDAwOjBlOiBbaW8gIDB4MDUwMC0w
eDA1N2ZdClsgICAgMy45NjI5NzFdIHBucCAwMDowZTogW21lbSAweGZlZDFjMDAwLTB4ZmVkMWZm
ZmZdClsgICAgMy45NjMwNzJdIHBucCAwMDowZTogW21lbSAweGZlYzAwMDAwLTB4ZmVjZmZmZmZd
ClsgICAgMy45NjMxNzJdIHBucCAwMDowZTogW21lbSAweGZlZDA4MDAwLTB4ZmVkMDhmZmZdClsg
ICAgMy45NjMyNzJdIHBucCAwMDowZTogW21lbSAweGZmMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAg
My45NjM0MDVdIHN5c3RlbSAwMDowZTogW2lvICAweDA0MDAtMHgwNDUzXSBoYXMgYmVlbiByZXNl
cnZlZApbICAgIDMuOTYzNTEwXSBzeXN0ZW0gMDA6MGU6IFtpbyAgMHgwNDU4LTB4MDQ3Zl0gaGFz
IGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjk2MzYxNV0gc3lzdGVtIDAwOjBlOiBbaW8gIDB4MTE4MC0w
eDExOWZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy45NjM3MThdIHN5c3RlbSAwMDowZTogW2lv
ICAweDA1MDAtMHgwNTdmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuOTYzODE3XSBzeXN0ZW0g
MDA6MGU6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg
IDMuOTYzOTIyXSBzeXN0ZW0gMDA6MGU6IFttZW0gMHhmZWMwMDAwMC0weGZlY2ZmZmZmXSBjb3Vs
ZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICAzLjk2NDAyOF0gc3lzdGVtIDAwOjBlOiBbbWVtIDB4ZmVk
MDgwMDAtMHhmZWQwOGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjk2NDEzM10gc3lzdGVt
IDAwOjBlOiBbbWVtIDB4ZmYwMDAwMDAtMHhmZmZmZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAg
ICAzLjk2NDIzNV0gc3lzdGVtIDAwOjBlOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMGMwMSAoYWN0aXZlKQpbICAgIDMuOTY2MDcyXSBwbnAgMDA6MGY6IFtpbyAgMHgwNDU0LTB4
MDQ1N10KWyAgICAzLjk2NjIwMF0gc3lzdGVtIDAwOjBmOiBbaW8gIDB4MDQ1NC0weDA0NTddIGhh
cyBiZWVuIHJlc2VydmVkClsgICAgMy45NjYzMDRdIHN5c3RlbSAwMDowZjogUGx1ZyBhbmQgUGxh
eSBBQ1BJIGRldmljZSwgSURzIElOVDNmMGQgUE5QMGMwMiAoYWN0aXZlKQpbICAgIDMuOTY2NTU1
XSBwbnAgMDA6MTA6IFttZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmXQpbICAgIDMuOTY2NjkyXSBw
bnAgMDA6MTA6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMTAzIChhY3RpdmUp
ClsgICAgMy45NjY5NjVdIHBucDogUG5QIEFDUEk6IGZvdW5kIDE3IGRldmljZXMKWyAgICAzLjk2
NzA2NV0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVkClsgICAgMy45NjcxNjhd
IGluaXRjYWxsIHBucGFjcGlfaW5pdCsweDAvMHg4YyByZXR1cm5lZCAwIGFmdGVyIDE3NDAzIHVz
ZWNzClsgICAgMy45NjcyNzJdIGNhbGxpbmcgIGNocl9kZXZfaW5pdCsweDAvMHgxYiBAIDEKWyAg
ICAzLjk2OTM3NV0gaW5pdGNhbGwgY2hyX2Rldl9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0
ZXIgMTk1NiB1c2VjcwpbICAgIDMuOTY5NDgxXSBjYWxsaW5nICBmaXJtd2FyZV9jbGFzc19pbml0
KzB4MC8weDE5IEAgMQpbICAgIDMuOTY5NTg1XSBpbml0Y2FsbCBmaXJtd2FyZV9jbGFzc19pbml0
KzB4MC8weDE5IHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDMuOTY5NjkxXSBjYWxsaW5n
ICB0aGVybWFsX2luaXQrMHgwLzB4NzIgQCAxClsgICAgMy45Njk3OTZdIGluaXRjYWxsIHRoZXJt
YWxfaW5pdCsweDAvMHg3MiByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MKWyAgICAzLjk2OTg5OV0g
Y2FsbGluZyAgY3B1ZnJlcV9nb3ZfcGVyZm9ybWFuY2VfaW5pdCsweDAvMHgxMiBAIDEKWyAgICAz
Ljk3MDAwM10gaW5pdGNhbGwgY3B1ZnJlcV9nb3ZfcGVyZm9ybWFuY2VfaW5pdCsweDAvMHgxMiBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjk3MDEyOV0gY2FsbGluZyAgaW5pdF9hY3Bp
X3BtX2Nsb2Nrc291cmNlKzB4MC8weGQ5IEAgMQpbICAgIDMuOTczNDg2XSBQTS1UaW1lciBmYWls
ZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4ZmZmZmZmKSAtIGFib3J0aW5nLgpbICAgIDMuOTcz
NTkxXSBpbml0Y2FsbCBpbml0X2FjcGlfcG1fY2xvY2tzb3VyY2UrMHgwLzB4ZDkgcmV0dXJuZWQg
LTE5IGFmdGVyIDMyNzggdXNlY3MKWyAgICAzLjk3MzcxMl0gY2FsbGluZyAgcGNpYmlvc19hc3Np
Z25fcmVzb3VyY2VzKzB4MC8weDc2IEAgMQpbICAgIDMuOTczODIxXSBQQ0k6IG1heCBidXMgZGVw
dGg6IDEgcGNpX3RyeV9udW06IDIKWyAgICAzLjk3NDAzMF0gcGNpIDAwMDA6MDE6MDAuMDogQkFS
IDM6IGFzc2lnbmVkIFttZW0gMHhmYmE4MDAwMC0weGZiYWJmZmZmIDY0Yml0XQpbICAgIDMuOTc0
MTU4XSBwY2kgMDAwMDowMTowMC4wOiBCQVIgMzogc2V0IHRvIFttZW0gMHhmYmE4MDAwMC0weGZi
YWJmZmZmIDY0Yml0XSAoUENJIGFkZHJlc3MgWzB4ZmJhODAwMDAtMHhmYmFiZmZmZl0pClsgICAg
My45NzQyODddIHBjaSAwMDAwOjAwOjAxLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMS0wMV0KWyAg
ICAzLjk3NDM5MF0gcGNpIDAwMDA6MDA6MDEuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAw
LTB4ZWZmZl0KWyAgICAzLjk3NDQ5N10gcGNpIDAwMDA6MDA6MDEuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhmYmEwMDAwMC0weGZiYWZmZmZmXQpbICAgIDMuOTc0NjA4XSBwY2kgMDAwMDowMDox
Yy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdClsgICAgMy45NzQ3NTddIHBjaSAwMDAwOjAw
OjFjLjQ6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMy0wM10KWyAgICAzLjk3NDg2NV0gcGNpIDAwMDA6
MDA6MWMuNDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0KWyAgICAzLjk3NDk4
M10gcGNpIDAwMDA6MDA6MWMuNDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYjkwMDAwMC0weGZi
OWZmZmZmXQpbICAgIDMuOTc1MTIzXSBwY2kgMDAwMDowMDoxZS4wOiBQQ0kgYnJpZGdlIHRvIFti
dXMgMDQtMDRdClsgICAgMy45NzUyMzhdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRv
dyBbbWVtIDB4ZmIwMDAwMDAtMHhmYjhmZmZmZl0KWyAgICAzLjk3NTM1MF0gcGNpIDAwMDA6MDA6
MWUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAwMC0weGZhZmZmZmZmIDY0Yml0IHBy
ZWZdClsgICAgMy45NzU0OTZdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxClsgICAgMy45NzU2MDRdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9
MTYpClsgICAgMy45NzU3MzFdIHBjaSAwMDAwOjAwOjAxLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYg
KGxldmVsLCBsb3cpIC0+IElSUSAxNgpbICAgIDMuOTc1ODM5XSBwY2kgMDAwMDowMDowMS4wOiBz
ZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAzLjk3NTk1NV0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAzLjk3NjA1N10geGVuOiAtLT4g
cGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykKWyAgICAzLjk3NjE4Ml0gcGNpIDAwMDA6MDA6MWMu
MDogUENJIElOVCBBIC0+IEdTSSAxNyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgMy45NzYy
OTddIHBjaSAwMDAwOjAwOjFjLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDMu
OTc2NDE5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpb
ICAgIDMuOTc2NTIwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kg
MTcKWyAgICAzLjk3NjYxOV0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykKWyAg
ICAzLjk3NjcxOV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNwpbICAgIDMuOTc2ODE2XSBwY2kg
MDAwMDowMDoxYy40OiBQQ0kgSU5UIEEgLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJUlEgMTcK
WyAgICAzLjk3NjkzMl0gcGNpIDAwMDA6MDA6MWMuNDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRv
IDY0ClsgICAgMy45NzcwNTJdIHBjaSAwMDAwOjAwOjFlLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1l
ciB0byA2NApbICAgIDMuOTc3MTU5XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDQgW2lvICAw
eDAwMDAtMHgwM2FmXQpbICAgIDMuOTc3MjYwXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDUg
W2lvICAweDAzZTAtMHgwY2Y3XQpbICAgIDMuOTc3MzYzXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291
cmNlIDYgW2lvICAweDAzYjAtMHgwM2RmXQpbICAgIDMuOTc3NDY1XSBwY2lfYnVzIDAwMDA6MDA6
IHJlc291cmNlIDcgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDMuOTc3NTY3XSBwY2lfYnVzIDAw
MDA6MDA6IHJlc291cmNlIDggW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgMy45Nzc2
NzFdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgOSBbbWVtIDB4MDAwYzAwMDAtMHgwMDBkZmZm
Zl0KWyAgICAzLjk3Nzc3NV0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxMCBbbWVtIDB4ZjAw
MDAwMDAtMHhmYmZmZmZmZl0KWyAgICAzLjk3Nzg3N10gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJj
ZSAwIFtpbyAgMHhlMDAwLTB4ZWZmZl0KWyAgICAzLjk3Nzk4MV0gcGNpX2J1cyAwMDAwOjAxOiBy
ZXNvdXJjZSAxIFttZW0gMHhmYmEwMDAwMC0weGZiYWZmZmZmXQpbICAgIDMuOTc4MDgzXSBwY2lf
YnVzIDAwMDA6MDM6IHJlc291cmNlIDAgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDMuOTc4MTg2
XSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDEgW21lbSAweGZiOTAwMDAwLTB4ZmI5ZmZmZmZd
ClsgICAgMy45NzgyODldIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgMSBbbWVtIDB4ZmIwMDAw
MDAtMHhmYjhmZmZmZl0KWyAgICAzLjk3ODM5NF0gcGNpX2J1cyAwMDAwOjA0OiByZXNvdXJjZSAy
IFttZW0gMHhmYTAwMDAwMC0weGZhZmZmZmZmIDY0Yml0IHByZWZdClsgICAgMy45Nzg1MThdIHBj
aV9idXMgMDAwMDowNDogcmVzb3VyY2UgNCBbaW8gIDB4MDAwMC0weDAzYWZdClsgICAgMy45Nzg2
MThdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgNSBbaW8gIDB4MDNlMC0weDBjZjddClsgICAg
My45Nzg3MjBdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgNiBbaW8gIDB4MDNiMC0weDAzZGZd
ClsgICAgMy45Nzg4MjFdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgNyBbaW8gIDB4MGQwMC0w
eGZmZmZdClsgICAgMy45Nzg5MjRdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgOCBbbWVtIDB4
MDAwYTAwMDAtMHgwMDBiZmZmZl0KWyAgICAzLjk3OTAyOF0gcGNpX2J1cyAwMDAwOjA0OiByZXNv
dXJjZSA5IFttZW0gMHgwMDBjMDAwMC0weDAwMGRmZmZmXQpbICAgIDMuOTc5MTMxXSBwY2lfYnVz
IDAwMDA6MDQ6IHJlc291cmNlIDEwIFttZW0gMHhmMDAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDMu
OTc5MjM0XSBpbml0Y2FsbCBwY2liaW9zX2Fzc2lnbl9yZXNvdXJjZXMrMHgwLzB4NzYgcmV0dXJu
ZWQgMCBhZnRlciA1MjkxIHVzZWNzClsgICAgMy45NzkzNTddIGNhbGxpbmcgIHN5c2N0bF9jb3Jl
X2luaXQrMHgwLzB4MzggQCAxClsgICAgMy45Nzk0NjhdIGluaXRjYWxsIHN5c2N0bF9jb3JlX2lu
aXQrMHgwLzB4MzggcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNzClsgICAgMy45Nzk1NzNdIGNhbGxp
bmcgIGluZXRfaW5pdCsweDAvMHgyN2QgQCAxClsgICAgMy45Nzk2ODVdIE5FVDogUmVnaXN0ZXJl
ZCBwcm90b2NvbCBmYW1pbHkgMgpbICAgIDMuOTgwODgxXSBJUCByb3V0ZSBjYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDUyNDI4OCAob3JkZXI6IDEwLCA0MTk0MzA0IGJ5dGVzKQpbICAgIDMuOTgz
MzgzXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MjQyODggKG9yZGVyOiAx
MSwgODM4ODYwOCBieXRlcykKWyAgICAzLjk4NDY3N10gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRy
aWVzOiA2NTUzNiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpClsgICAgMy45ODQ4OTddIFRDUDog
SGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgNTI0Mjg4IGJpbmQgNjU1MzYpClsg
ICAgMy45ODUwMDVdIFRDUCByZW5vIHJlZ2lzdGVyZWQKWyAgICAzLjk4NTE4N10gVURQIGhhc2gg
dGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKWyAgICAzLjk4NTQw
MF0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA4MTkyIChvcmRlcjogNiwgMjYyMTQ0IGJ5
dGVzKQpbICAgIDMuOTg1NTkzXSBpbml0Y2FsbCBpbmV0X2luaXQrMHgwLzB4MjdkIHJldHVybmVk
IDAgYWZ0ZXIgNTc3NSB1c2VjcwpbICAgIDMuOTg1NzAwXSBjYWxsaW5nICBhZl91bml4X2luaXQr
MHgwLzB4NTIgQCAxClsgICAgMy45ODU4MDFdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMQpbICAgIDMuOTg1OTA0XSBpbml0Y2FsbCBhZl91bml4X2luaXQrMHgwLzB4NTIgcmV0dXJu
ZWQgMCBhZnRlciAxMDAgdXNlY3MKWyAgICAzLjk4NjAwOV0gY2FsbGluZyAgcGNpX2FwcGx5X2Zp
bmFsX3F1aXJrcysweDAvMHgxMDUgQCAxClsgICAgMy45ODYxNDNdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgMy45ODYyNDldIHhlbl9tYXBfcGly
cV9nc2k6IHJldHVybmluZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDMuOTg2MzUyXSB4ZW46IC0t
PiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDMuOTg2NDU0XSBBbHJlYWR5IHNldHVw
IHRoZSBHU0kgOjE2ClsgICAgMy45ODY1NTVdIHBjaSAwMDAwOjAwOjFhLjA6IFBDSSBJTlQgQSAt
PiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAxNgpbICAgIDMuOTg2NzA0XSBwY2kgMDAwMDow
MDoxYS4wOiBQQ0kgSU5UIEEgZGlzYWJsZWQKWyAgICAzLjk4NjgzNl0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMjMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAzLjk4Njk0M10geGVuOiAtLT4g
cGlycT0yMyAtPiBpcnE9MjMgKGdzaT0yMykKWyAgICAzLjk4NzA3M10gcGNpIDAwMDA6MDA6MWQu
MDogUENJIElOVCBBIC0+IEdTSSAyMyAobGV2ZWwsIGxvdykgLT4gSVJRIDIzClsgICAgMy45ODcy
MzJdIHBjaSAwMDAwOjAwOjFkLjA6IFBDSSBJTlQgQSBkaXNhYmxlZApbICAgIDMuOTg3NDM5XSBw
Y2kgMDAwMDowNDowMy4wOiBCb290IHZpZGVvIGRldmljZQpbICAgIDMuOTg3NTQwXSBQQ0k6IENM
UyA2NCBieXRlcywgZGVmYXVsdCA2NApbICAgIDMuOTg3NjM4XSBpbml0Y2FsbCBwY2lfYXBwbHlf
ZmluYWxfcXVpcmtzKzB4MC8weDEwNSByZXR1cm5lZCAwIGFmdGVyIDE0ODkgdXNlY3MKWyAgICAz
Ljk4Nzc2M10gY2FsbGluZyAgcG9wdWxhdGVfcm9vdGZzKzB4MC8weDI0IEAgMQpbICAgIDMuOTg3
ODYyXSBpbml0Y2FsbCBwb3B1bGF0ZV9yb290ZnMrMHgwLzB4MjQgcmV0dXJuZWQgMjc0Nzg3NTI2
IGFmdGVyIDAgdXNlY3MKWyAgICAzLjk4Nzk4M10gaW5pdGNhbGwgcG9wdWxhdGVfcm9vdGZzKzB4
MC8weDI0IHJldHVybmVkIHdpdGggZXJyb3IgY29kZSAyNzQ3ODc1MjYgClsgICAgMy45ODgxMDZd
IGNhbGxpbmcgIHBjaV9pb21tdV9pbml0KzB4MC8weDNlIEAgMQpbICAgIDMuOTg4MjA2XSBpbml0
Y2FsbCBwY2lfaW9tbXVfaW5pdCsweDAvMHgzZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg
ICAzLjk4ODMwOF0gY2FsbGluZyAgY2FsZ2FyeV9maXh1cF90Y2Vfc3BhY2VzKzB4MC8weDJiIEAg
MQpbICAgIDMuOTg4NDA4XSBpbml0Y2FsbCBjYWxnYXJ5X2ZpeHVwX3RjZV9zcGFjZXMrMHgwLzB4
MmIgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MKWyAgICAzLjk4ODUzMl0gY2FsbGluZyAgaXJf
ZGV2X3Njb3BlX2luaXQrMHgwLzB4MTYgQCAxClsgICAgMy45ODg2MjldIGluaXRjYWxsIGlyX2Rl
dl9zY29wZV9pbml0KzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTg4
NzMxXSBjYWxsaW5nICBpODI1OUFfaW5pdF9vcHMrMHgwLzB4MjEgQCAxClsgICAgMy45ODg4MzFd
IGluaXRjYWxsIGk4MjU5QV9pbml0X29wcysweDAvMHgyMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjk4ODkzNF0gY2FsbGluZyAgdnN5c2NhbGxfaW5pdCsweDAvMHgyNyBAIDEKWyAg
ICAzLjk4OTAzOV0gaW5pdGNhbGwgdnN5c2NhbGxfaW5pdCsweDAvMHgyNyByZXR1cm5lZCAwIGFm
dGVyIDYgdXNlY3MKWyAgICAzLjk4OTE0Ml0gY2FsbGluZyAgc2JmX2luaXQrMHgwLzB4MTYgQCAx
ClsgICAgMy45ODkyNDJdIGluaXRjYWxsIHNiZl9pbml0KzB4MC8weDE2IHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDMuOTg5MzQ0XSBjYWxsaW5nICBpbml0X3RzY19jbG9ja3NvdXJjZSsw
eDAvMHg1ZiBAIDEKWyAgICAzLjk4OTQ1M10gaW5pdGNhbGwgaW5pdF90c2NfY2xvY2tzb3VyY2Ur
MHgwLzB4NWYgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgMy45ODk1NTRdIGNhbGxpbmcg
IGFkZF9ydGNfY21vcysweDAvMHg5NiBAIDEKWyAgICAzLjk4OTY1N10gaW5pdGNhbGwgYWRkX3J0
Y19jbW9zKzB4MC8weDk2IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAgIDMuOTg5NzU3XSBj
YWxsaW5nICBpODIzN0FfaW5pdF9vcHMrMHgwLzB4MTQgQCAxClsgICAgMy45ODk4NzZdIGluaXRj
YWxsIGk4MjM3QV9pbml0X29wcysweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDE4IHVzZWNzClsg
ICAgMy45ODk5ODJdIGNhbGxpbmcgIGNhY2hlX3N5c2ZzX2luaXQrMHgwLzB4NTkgQCAxClsgICAg
My45OTAxNTZdIGluaXRjYWxsIGNhY2hlX3N5c2ZzX2luaXQrMHgwLzB4NTkgcmV0dXJuZWQgMCBh
ZnRlciA3MyB1c2VjcwpbICAgIDMuOTkwMjU4XSBjYWxsaW5nICBtY2hlY2tfaW5pdF9kZXZpY2Ur
MHgwLzB4MjQgQCAxClsgICAgMy45OTAzNThdIGluaXRjYWxsIG1jaGVja19pbml0X2RldmljZSsw
eDAvMHgyNCByZXR1cm5lZCAtNSBhZnRlciAwIHVzZWNzClsgICAgMy45OTA0NTddIGluaXRjYWxs
IG1jaGVja19pbml0X2RldmljZSsweDAvMHgyNCByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTUg
ClsgICAgMy45OTA1NjBdIGNhbGxpbmcgIHRocmVzaG9sZF9pbml0X2RldmljZSsweDAvMHg1NiBA
IDEKWyAgICAzLjk5MDY2MV0gaW5pdGNhbGwgdGhyZXNob2xkX2luaXRfZGV2aWNlKzB4MC8weDU2
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTkwNzY2XSBjYWxsaW5nICB0aGVybWFs
X3Rocm90dGxlX2luaXRfZGV2aWNlKzB4MC8weDljIEAgMQpbICAgIDMuOTkwODYzXSBpbml0Y2Fs
bCB0aGVybWFsX3Rocm90dGxlX2luaXRfZGV2aWNlKzB4MC8weDljIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuOTkwOTg5XSBjYWxsaW5nICBhbWRfaWJzX2luaXQrMHgwLzB4MTdmIEAg
MQpbICAgIDMuOTkxMDkwXSBpbml0Y2FsbCBhbWRfaWJzX2luaXQrMHgwLzB4MTdmIHJldHVybmVk
IC0xOSBhZnRlciAwIHVzZWNzClsgICAgMy45OTExOTJdIGNhbGxpbmcgIGlvYXBpY19pbml0X29w
cysweDAvMHgxNCBAIDEKWyAgICAzLjk5MTI5MF0gaW5pdGNhbGwgaW9hcGljX2luaXRfb3BzKzB4
MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTkxMzk0XSBjYWxsaW5nICBh
ZGRfcGNzcGtyKzB4MC8weDVlIEAgMQpbICAgIDMuOTkxNTE1XSBpbml0Y2FsbCBhZGRfcGNzcGty
KzB4MC8weDVlIHJldHVybmVkIDAgYWZ0ZXIgMTkgdXNlY3MKWyAgICAzLjk5MTYxOV0gY2FsbGlu
ZyAgc3RhcnRfcGVyaW9kaWNfY2hlY2tfZm9yX2NvcnJ1cHRpb24rMHgwLzB4NTAgQCAxClsgICAg
My45OTE3MjJdIGluaXRjYWxsIHN0YXJ0X3BlcmlvZGljX2NoZWNrX2Zvcl9jb3JydXB0aW9uKzB4
MC8weDUwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTkxODQ2XSBjYWxsaW5nICBh
dWRpdF9jbGFzc2VzX2luaXQrMHgwLzB4YWYgQCAxClsgICAgMy45OTE5NTBdIGluaXRjYWxsIGF1
ZGl0X2NsYXNzZXNfaW5pdCsweDAvMHhhZiByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICAz
Ljk5MjA1NV0gY2FsbGluZyAgY3JjMzJjX2ludGVsX21vZF9pbml0KzB4MC8weDI2IEAgMQpbICAg
IDMuOTkyMjAwXSBpbml0Y2FsbCBjcmMzMmNfaW50ZWxfbW9kX2luaXQrMHgwLzB4MjYgcmV0dXJu
ZWQgMCBhZnRlciA0MSB1c2VjcwpbICAgIDMuOTkyMzA3XSBjYWxsaW5nICBpYTMyX2JpbmZtdF9p
bml0KzB4MC8weDE0IEAgMQpbICAgIDMuOTkyNDExXSBpbml0Y2FsbCBpYTMyX2JpbmZtdF9pbml0
KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDMuOTkyNTE1XSBjYWxsaW5n
ICBpbml0X3NjaGVkX2RlYnVnX3Byb2NmcysweDAvMHgyYyBAIDEKWyAgICAzLjk5MjYyMV0gaW5p
dGNhbGwgaW5pdF9zY2hlZF9kZWJ1Z19wcm9jZnMrMHgwLzB4MmMgcmV0dXJuZWQgMCBhZnRlciAy
IHVzZWNzClsgICAgMy45OTI3NDZdIGNhbGxpbmcgIHByb2Nfc2NoZWRzdGF0X2luaXQrMHgwLzB4
MjIgQCAxClsgICAgMy45OTI4NDldIGluaXRjYWxsIHByb2Nfc2NoZWRzdGF0X2luaXQrMHgwLzB4
MjIgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgMy45OTI5NTVdIGNhbGxpbmcgIHByb2Nf
ZXhlY2RvbWFpbnNfaW5pdCsweDAvMHgyMiBAIDEKWyAgICAzLjk5MzA1N10gaW5pdGNhbGwgcHJv
Y19leGVjZG9tYWluc19pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuOTkzMTY2XSBjYWxsaW5nICBpb3Jlc291cmNlc19pbml0KzB4MC8weDNjIEAgMQpbICAgIDMu
OTkzMjY4XSBpbml0Y2FsbCBpb3Jlc291cmNlc19pbml0KzB4MC8weDNjIHJldHVybmVkIDAgYWZ0
ZXIgMSB1c2VjcwpbICAgIDMuOTkzMzc0XSBjYWxsaW5nICB1aWRfY2FjaGVfaW5pdCsweDAvMHg5
NSBAIDEKWyAgICAzLjk5MzQ4Ml0gaW5pdGNhbGwgdWlkX2NhY2hlX2luaXQrMHgwLzB4OTUgcmV0
dXJuZWQgMCBhZnRlciA2IHVzZWNzClsgICAgMy45OTM1ODZdIGNhbGxpbmcgIGluaXRfcG9zaXhf
dGltZXJzKzB4MC8weDIwMyBAIDEKWyAgICAzLjk5MzY4OV0gaW5pdGNhbGwgaW5pdF9wb3NpeF90
aW1lcnMrMHgwLzB4MjAzIHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAgIDMuOTkzNzk1XSBj
YWxsaW5nICBpbml0X3Bvc2l4X2NwdV90aW1lcnMrMHgwLzB4YzIgQCAxClsgICAgMy45OTM4OTld
IGluaXRjYWxsIGluaXRfcG9zaXhfY3B1X3RpbWVycysweDAvMHhjMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjk5NDAwNl0gY2FsbGluZyAgY3JlYXRlX3Byb2NfcHJvZmlsZSsweDAv
MHg5MCBAIDEKWyAgICAzLjk5NDEwOF0gaW5pdGNhbGwgY3JlYXRlX3Byb2NfcHJvZmlsZSsweDAv
MHg5MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjk5NDIxMV0gY2FsbGluZyAgdGlt
ZWtlZXBpbmdfaW5pdF9vcHMrMHgwLzB4MTQgQCAxClsgICAgMy45OTQzMTJdIGluaXRjYWxsIHRp
bWVrZWVwaW5nX2luaXRfb3BzKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuOTk0NDE1XSBjYWxsaW5nICBpbml0X2Nsb2Nrc291cmNlX3N5c2ZzKzB4MC8weDUwIEAgMQpb
ICAgIDMuOTk0NTI3XSBpbml0Y2FsbCBpbml0X2Nsb2Nrc291cmNlX3N5c2ZzKzB4MC8weDUwIHJl
dHVybmVkIDAgYWZ0ZXIgOSB1c2VjcwpbICAgIDMuOTk0NjMzXSBjYWxsaW5nICBpbml0X3RpbWVy
X2xpc3RfcHJvY2ZzKzB4MC8weDJjIEAgMQpbICAgIDMuOTk2NDMyXSBpbml0Y2FsbCBpbml0X3Rp
bWVyX2xpc3RfcHJvY2ZzKzB4MC8weDJjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
OTk2NTM3XSBjYWxsaW5nICBhbGFybXRpbWVyX2luaXQrMHgwLzB4MTcwIEAgMQpbICAgIDMuOTk2
NjY0XSBpbml0Y2FsbCBhbGFybXRpbWVyX2luaXQrMHgwLzB4MTcwIHJldHVybmVkIDAgYWZ0ZXIg
MjMgdXNlY3MKWyAgICAzLjk5Njc2OF0gY2FsbGluZyAgaW5pdF90c3RhdHNfcHJvY2ZzKzB4MC8w
eDJjIEAgMQpbICAgIDMuOTk2ODcwXSBpbml0Y2FsbCBpbml0X3RzdGF0c19wcm9jZnMrMHgwLzB4
MmMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45OTY5NzZdIGNhbGxpbmcgIGZ1dGV4
X2luaXQrMHgwLzB4NWYgQCAxClsgICAgMy45OTcwODFdIGluaXRjYWxsIGZ1dGV4X2luaXQrMHgw
LzB4NWYgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzClsgICAgMy45OTcxODVdIGNhbGxpbmcgIHBy
b2NfZG1hX2luaXQrMHgwLzB4MjIgQCAxClsgICAgMy45OTcyODVdIGluaXRjYWxsIHByb2NfZG1h
X2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45OTczOTBdIGNh
bGxpbmcgIHByb2NfbW9kdWxlc19pbml0KzB4MC8weDIyIEAgMQpbICAgIDMuOTk3NDkyXSBpbml0
Y2FsbCBwcm9jX21vZHVsZXNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjk5NzU5OF0gY2FsbGluZyAga2FsbHN5bXNfaW5pdCsweDAvMHgyNSBAIDEKWyAgICAz
Ljk5NzcwMF0gaW5pdGNhbGwga2FsbHN5bXNfaW5pdCsweDAvMHgyNSByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjk5NzgwNV0gY2FsbGluZyAgc25hcHNob3RfZGV2aWNlX2luaXQrMHgw
LzB4MTIgQCAxClsgICAgMy45OTc5NDhdIGluaXRjYWxsIHNuYXBzaG90X2RldmljZV9pbml0KzB4
MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgNDEgdXNlY3MKWyAgICAzLjk5ODA1Ml0gY2FsbGluZyAg
Y3Jhc2hfc2F2ZV92bWNvcmVpbmZvX2luaXQrMHgwLzB4NDdjIEAgMQpbICAgIDMuOTk4MTcxXSBp
bml0Y2FsbCBjcmFzaF9zYXZlX3ZtY29yZWluZm9faW5pdCsweDAvMHg0N2MgcmV0dXJuZWQgMCBh
ZnRlciAxMyB1c2VjcwpbICAgIDMuOTk4Mjk0XSBjYWxsaW5nICBjcmFzaF9ub3Rlc19tZW1vcnlf
aW5pdCsweDAvMHgzNyBAIDEKWyAgICAzLjk5ODM5OF0gaW5pdGNhbGwgY3Jhc2hfbm90ZXNfbWVt
b3J5X2luaXQrMHgwLzB4MzcgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgMy45OTg1MjJd
IGNhbGxpbmcgIHVzZXJfbmFtZXNwYWNlc19pbml0KzB4MC8weDJkIEAgMQpbICAgIDMuOTk4NjI3
XSBpbml0Y2FsbCB1c2VyX25hbWVzcGFjZXNfaW5pdCsweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVy
IDMgdXNlY3MKWyAgICAzLjk5ODczM10gY2FsbGluZyAgcGlkX25hbWVzcGFjZXNfaW5pdCsweDAv
MHgyZCBAIDEKWyAgICAzLjk5ODgzN10gaW5pdGNhbGwgcGlkX25hbWVzcGFjZXNfaW5pdCsweDAv
MHgyZCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAgICAzLjk5ODk0Ml0gY2FsbGluZyAgYXVk
aXRfaW5pdCsweDAvMHgxNiBAIDEKWyAgICAzLjk5OTA0Ml0gYXVkaXQ6IGluaXRpYWxpemluZyBu
ZXRsaW5rIHNvY2tldCAoZGlzYWJsZWQpClsgICAgMy45OTkxNTBdIHR5cGU9MjAwMCBhdWRpdCgx
MzM0MTY4OTYzLjczMToxKTogaW5pdGlhbGl6ZWQKWyAgICAzLjk5OTI1M10gaW5pdGNhbGwgYXVk
aXRfaW5pdCsweDAvMHgxNiByZXR1cm5lZCAwIGFmdGVyIDIwNSB1c2VjcwpbICAgIDMuOTk5MzU2
XSBjYWxsaW5nICBhdWRpdF93YXRjaF9pbml0KzB4MC8weDNhIEAgMQpbICAgIDMuOTk5NDU3XSBp
bml0Y2FsbCBhdWRpdF93YXRjaF9pbml0KzB4MC8weDNhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuOTk5NTYzXSBjYWxsaW5nICBhdWRpdF90cmVlX2luaXQrMHgwLzB4NTggQCAxClsg
ICAgMy45OTk2NjJdIGluaXRjYWxsIGF1ZGl0X3RyZWVfaW5pdCsweDAvMHg1OCByZXR1cm5lZCAw
IGFmdGVyIDAgdXNlY3MKWyAgICAzLjk5OTc2N10gY2FsbGluZyAgaW5pdF9rcHJvYmVzKzB4MC8w
eDE4MyBAIDEKWyAgICA0LjAxNTgwM10gaW5pdGNhbGwgaW5pdF9rcHJvYmVzKzB4MC8weDE4MyBy
ZXR1cm5lZCAwIGFmdGVyIDE1NTYxIHVzZWNzClsgICAgNC4wMTU5MDddIGNhbGxpbmcgIGh1bmdf
dGFza19pbml0KzB4MC8weDUzIEAgMQpbICAgIDQuMDE2MDM1XSBpbml0Y2FsbCBodW5nX3Rhc2tf
aW5pdCsweDAvMHg1MyByZXR1cm5lZCAwIGFmdGVyIDI1IHVzZWNzClsgICAgNC4wMTYxNDBdIGNh
bGxpbmcgIGlycV9nY19pbml0X29wcysweDAvMHgxNCBAIDEKWyAgICA0LjAxNjI0Ml0gaW5pdGNh
bGwgaXJxX2djX2luaXRfb3BzKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDQuMDE2MzQ3XSBjYWxsaW5nICBpcnFfcG1faW5pdF9vcHMrMHgwLzB4MTQgQCAxClsgICAgNC4w
MTY0NDldIGluaXRjYWxsIGlycV9wbV9pbml0X29wcysweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICA0LjAxNjU1NF0gY2FsbGluZyAgdXRzbmFtZV9zeXNjdGxfaW5pdCsweDAv
MHgxNCBAIDEKWyAgICA0LjAxNjY2M10gaW5pdGNhbGwgdXRzbmFtZV9zeXNjdGxfaW5pdCsweDAv
MHgxNCByZXR1cm5lZCAwIGFmdGVyIDkgdXNlY3MKWyAgICA0LjAxNjc2Nl0gY2FsbGluZyAgaW5p
dF90cmFjZXBvaW50cysweDAvMHgyMCBAIDEKWyAgICA0LjAxNjg2Nl0gaW5pdGNhbGwgaW5pdF90
cmFjZXBvaW50cysweDAvMHgyMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjAxNjk2
OV0gY2FsbGluZyAgaW5pdF9sc3RhdHNfcHJvY2ZzKzB4MC8weDI1IEAgMQpbICAgIDQuMDE3MDcz
XSBpbml0Y2FsbCBpbml0X2xzdGF0c19wcm9jZnMrMHgwLzB4MjUgcmV0dXJuZWQgMCBhZnRlciAx
IHVzZWNzClsgICAgNC4wMTcxNzhdIGNhbGxpbmcgIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4
MTIgQCAxClsgICAgNC4wMTcyODBdIGluaXRjYWxsIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4
MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMTczODZdIGNhbGxpbmcgIGluaXRf
ZXZlbnRzKzB4MC8weDYwIEAgMQpbICAgIDQuMDE3NDkyXSBpbml0Y2FsbCBpbml0X2V2ZW50cysw
eDAvMHg2MCByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICA0LjAxNzU5N10gY2FsbGluZyAg
aW5pdF9mdW5jdGlvbl90cmFjZSsweDAvMHgzZSBAIDEKWyAgICA0LjAxNzcwMF0gaW5pdGNhbGwg
aW5pdF9mdW5jdGlvbl90cmFjZSsweDAvMHgzZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg
ICA0LjAxNzgwNV0gY2FsbGluZyAgaW5pdF93YWtldXBfdHJhY2VyKzB4MC8weDIyIEAgMQpbICAg
IDQuMDE3OTA4XSBpbml0Y2FsbCBpbml0X3dha2V1cF90cmFjZXIrMHgwLzB4MjIgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgNC4wMTgwMTJdIGNhbGxpbmcgIHN0YWNrX3RyYWNlX2luaXQr
MHgwLzB4NjggQCAxClsgICAgNC4wMTgxMTldIGluaXRjYWxsIHN0YWNrX3RyYWNlX2luaXQrMHgw
LzB4NjggcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzClsgICAgNC4wMTgyMjVdIGNhbGxpbmcgIGlu
aXRfbW1pb190cmFjZSsweDAvMHgxMiBAIDEKWyAgICA0LjAxODMyOF0gaW5pdGNhbGwgaW5pdF9t
bWlvX3RyYWNlKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDE4NDM0
XSBjYWxsaW5nICBpbml0X2dyYXBoX3RyYWNlKzB4MC8weDY1IEAgMQpbICAgIDQuMDE4NTM3XSBp
bml0Y2FsbCBpbml0X2dyYXBoX3RyYWNlKzB4MC8weDY1IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDQuMDE4NjQwXSBjYWxsaW5nICBpbml0X2Jsa190cmFjZXIrMHgwLzB4NWMgQCAxClsg
ICAgNC4wMTg3NDJdIGluaXRjYWxsIGluaXRfYmxrX3RyYWNlcisweDAvMHg1YyByZXR1cm5lZCAw
IGFmdGVyIDAgdXNlY3MKWyAgICA0LjAxODg0OF0gY2FsbGluZyAgcGVyZl9ldmVudF9zeXNmc19p
bml0KzB4MC8weDkzIEAgMQpbICAgIDQuMDE4OTkyXSBpbml0Y2FsbCBwZXJmX2V2ZW50X3N5c2Zz
X2luaXQrMHgwLzB4OTMgcmV0dXJuZWQgMCBhZnRlciAzOSB1c2VjcwpbICAgIDQuMDE5MDk5XSBj
YWxsaW5nICBpbml0X3Blcl96b25lX3dtYXJrX21pbisweDAvMHg4OCBAIDEKWyAgICA0LjAyMDQw
Nl0gaW5pdGNhbGwgaW5pdF9wZXJfem9uZV93bWFya19taW4rMHgwLzB4ODggcmV0dXJuZWQgMCBh
ZnRlciAxMTY5IHVzZWNzClsgICAgNC4wMjA1MzddIGNhbGxpbmcgIGtzd2FwZF9pbml0KzB4MC8w
eDc1IEAgMQpbICAgIDQuMDIwNzAzXSBpbml0Y2FsbCBrc3dhcGRfaW5pdCsweDAvMHg3NSByZXR1
cm5lZCAwIGFmdGVyIDYzIHVzZWNzClsgICAgNC4wMjA4MDldIGNhbGxpbmcgIGV4dGZyYWdfZGVi
dWdfaW5pdCsweDAvMHg3NyBAIDEKWyAgICA0LjAyMDkyMV0gaW5pdGNhbGwgZXh0ZnJhZ19kZWJ1
Z19pbml0KzB4MC8weDc3IHJldHVybmVkIDAgYWZ0ZXIgOCB1c2VjcwpbICAgIDQuMDIxMDI2XSBj
YWxsaW5nICBzZXR1cF92bXN0YXQrMHgwLzB4YzcgQCAxClsgICAgNC4wMjExMzddIGluaXRjYWxs
IHNldHVwX3Ztc3RhdCsweDAvMHhjNyByZXR1cm5lZCAwIGFmdGVyIDggdXNlY3MKWyAgICA0LjAy
MTI0Ml0gY2FsbGluZyAgbW1fc3lzZnNfaW5pdCsweDAvMHgyOSBAIDEKWyAgICA0LjAyMTM0N10g
aW5pdGNhbGwgbW1fc3lzZnNfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MK
WyAgICA0LjAyMTQ1MV0gY2FsbGluZyAgcHJvY192bWFsbG9jX2luaXQrMHgwLzB4MjUgQCAxClsg
ICAgNC4wMjE1NTBdIGluaXRjYWxsIHByb2Nfdm1hbGxvY19pbml0KzB4MC8weDI1IHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDIxNjU1XSBjYWxsaW5nICBwcm9jc3dhcHNfaW5pdCsw
eDAvMHgyMiBAIDEKWyAgICA0LjAyMTc1N10gaW5pdGNhbGwgcHJvY3N3YXBzX2luaXQrMHgwLzB4
MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjE4NjFdIGNhbGxpbmcgIGh1Z2V0
bGJfaW5pdCsweDAvMHgzMmQgQCAxClsgICAgNC4wMjE5NjNdIEh1Z2VUTEIgcmVnaXN0ZXJlZCAy
IE1CIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9jYXRlZCAwIHBhZ2VzClsgICAgNC4wMjIwNzVdIGluaXRj
YWxsIGh1Z2V0bGJfaW5pdCsweDAvMHgzMmQgcmV0dXJuZWQgMCBhZnRlciAxMTAgdXNlY3MKWyAg
ICA0LjAyMjE4MF0gY2FsbGluZyAga3NtX2luaXQrMHgwLzB4ZDAgQCAxClsgICAgNC4wMjIzMjFd
IGluaXRjYWxsIGtzbV9pbml0KzB4MC8weGQwIHJldHVybmVkIDAgYWZ0ZXIgNDAgdXNlY3MKWyAg
ICA0LjAyMjQyNl0gY2FsbGluZyAgc2xhYl9wcm9jX2luaXQrMHgwLzB4MjUgQCAxClsgICAgNC4w
MjI1MjldIGluaXRjYWxsIHNsYWJfcHJvY19pbml0KzB4MC8weDI1IHJldHVybmVkIDAgYWZ0ZXIg
MiB1c2VjcwpbICAgIDQuMDIyNjMzXSBjYWxsaW5nICBzbGFiX3N5c2ZzX2luaXQrMHgwLzB4MTA5
IEAgMQpbICAgIDQuMDIzNjY3XSBpbml0Y2FsbCBzbGFiX3N5c2ZzX2luaXQrMHgwLzB4MTA5IHJl
dHVybmVkIDAgYWZ0ZXIgOTEwIHVzZWNzClsgICAgNC4wMjM3NzNdIGNhbGxpbmcgIGh1Z2VwYWdl
X2luaXQrMHgwLzB4MTQxIEAgMQpbICAgIDQuMDIzODc0XSBpbml0Y2FsbCBodWdlcGFnZV9pbml0
KzB4MC8weDE0MSByZXR1cm5lZCAtMjIgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDIzOTc5XSBpbml0
Y2FsbCBodWdlcGFnZV9pbml0KzB4MC8weDE0MSByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTIy
IApbICAgIDQuMDI0MDg1XSBjYWxsaW5nICBpbml0X2NsZWFuY2FjaGUrMHgwLzB4MWIgQCAxClsg
ICAgNC4wMjQxODddIGluaXRjYWxsIGluaXRfY2xlYW5jYWNoZSsweDAvMHgxYiByZXR1cm5lZCAw
IGFmdGVyIDEgdXNlY3MKWyAgICA0LjAyNDI5Ml0gY2FsbGluZyAgZmNudGxfaW5pdCsweDAvMHgy
YSBAIDEKWyAgICA0LjAyNDM5NV0gaW5pdGNhbGwgZmNudGxfaW5pdCsweDAvMHgyYSByZXR1cm5l
ZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjAyNDQ5OF0gY2FsbGluZyAgcHJvY19maWxlc3lzdGVt
c19pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMDI0NjAzXSBpbml0Y2FsbCBwcm9jX2ZpbGVzeXN0
ZW1zX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4wMjQ3MTBd
IGNhbGxpbmcgIGRpb19pbml0KzB4MC8weDJkIEAgMQpbICAgIDQuMDI0ODI5XSBpbml0Y2FsbCBk
aW9faW5pdCsweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVyIDE3IHVzZWNzClsgICAgNC4wMjQ5MzFd
IGNhbGxpbmcgIGZzbm90aWZ5X21hcmtfaW5pdCsweDAvMHg0MCBAIDEKWyAgICA0LjAyNTA1OV0g
aW5pdGNhbGwgZnNub3RpZnlfbWFya19pbml0KzB4MC8weDQwIHJldHVybmVkIDAgYWZ0ZXIgMjUg
dXNlY3MKWyAgICA0LjAyNTE2OF0gY2FsbGluZyAgZG5vdGlmeV9pbml0KzB4MC8weDdiIEAgMQpb
ICAgIDQuMDI1MzAxXSBpbml0Y2FsbCBkbm90aWZ5X2luaXQrMHgwLzB4N2IgcmV0dXJuZWQgMCBh
ZnRlciAzMCB1c2VjcwpbICAgIDQuMDI1NDA1XSBjYWxsaW5nICBpbm90aWZ5X3VzZXJfc2V0dXAr
MHgwLzB4NzAgQCAxClsgICAgNC4wMjU1MTBdIGluaXRjYWxsIGlub3RpZnlfdXNlcl9zZXR1cCsw
eDAvMHg3MCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAgICA0LjAyNTYxNV0gY2FsbGluZyAg
ZmFub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg1MiBAIDEKWyAgICA0LjAyNTcxOV0gaW5pdGNhbGwg
ZmFub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg1MiByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAg
ICA0LjAyNTgyNF0gY2FsbGluZyAgYWlvX3NldHVwKzB4MC8weDc4IEAgMQpbICAgIDQuMDI1OTMw
XSBpbml0Y2FsbCBhaW9fc2V0dXArMHgwLzB4NzggcmV0dXJuZWQgMCBhZnRlciA2IHVzZWNzClsg
ICAgNC4wMjYwMzJdIGNhbGxpbmcgIHByb2NfbG9ja3NfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0
LjAyNjEzNV0gaW5pdGNhbGwgcHJvY19sb2Nrc19pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0
ZXIgMSB1c2VjcwpbICAgIDQuMDI2MjM5XSBjYWxsaW5nICBpbml0X3N5czMyX2lvY3RsKzB4MC8w
eDI4IEAgMQpbICAgIDQuMDI2Mzk2XSBpbml0Y2FsbCBpbml0X3N5czMyX2lvY3RsKzB4MC8weDI4
IHJldHVybmVkIDAgYWZ0ZXIgNTMgdXNlY3MKWyAgICA0LjAyNjUwMV0gY2FsbGluZyAgaW5pdF9t
YmNhY2hlKzB4MC8weDE0IEAgMQpbICAgIDQuMDI2NjAyXSBpbml0Y2FsbCBpbml0X21iY2FjaGUr
MHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjY3MDZdIGNhbGxpbmcg
IGRxdW90X2luaXQrMHgwLzB4MTFhIEAgMQpbICAgIDQuMDI2ODA2XSBWRlM6IERpc2sgcXVvdGFz
IGRxdW90XzYuNS4yClsgICAgNC4wMjY5NDZdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmll
czogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQpbICAgIDQuMDI3MDUxXSBpbml0Y2FsbCBkcXVv
dF9pbml0KzB4MC8weDExYSByZXR1cm5lZCAwIGFmdGVyIDIzOCB1c2VjcwpbICAgIDQuMDI3MTU1
XSBjYWxsaW5nICBxdW90YV9pbml0KzB4MC8weDI2IEAgMQpbICAgIDQuMDI3MjU5XSBpbml0Y2Fs
bCBxdW90YV9pbml0KzB4MC8weDI2IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDQuMDI3
MzYwXSBjYWxsaW5nICBwcm9jX2NtZGxpbmVfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyNzQ2
Ml0gaW5pdGNhbGwgcHJvY19jbWRsaW5lX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAx
IHVzZWNzClsgICAgNC4wMjc1NjZdIGNhbGxpbmcgIHByb2NfY29uc29sZXNfaW5pdCsweDAvMHgy
MiBAIDEKWyAgICA0LjAyNzY2NV0gaW5pdGNhbGwgcHJvY19jb25zb2xlc19pbml0KzB4MC8weDIy
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI3NzcxXSBjYWxsaW5nICBwcm9jX2Nw
dWluZm9faW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyNzg3NF0gaW5pdGNhbGwgcHJvY19jcHVp
bmZvX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjc5Nzld
IGNhbGxpbmcgIHByb2NfZGV2aWNlc19pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMDI4MDgxXSBp
bml0Y2FsbCBwcm9jX2RldmljZXNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA0LjAyODE4NV0gY2FsbGluZyAgcHJvY19pbnRlcnJ1cHRzX2luaXQrMHgwLzB4MjIg
QCAxClsgICAgNC4wMjgyODhdIGluaXRjYWxsIHByb2NfaW50ZXJydXB0c19pbml0KzB4MC8weDIy
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI4MzkyXSBjYWxsaW5nICBwcm9jX2xv
YWRhdmdfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyODQ5M10gaW5pdGNhbGwgcHJvY19sb2Fk
YXZnX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjg1OThd
IGNhbGxpbmcgIHByb2NfbWVtaW5mb19pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMDI4NzAyXSBp
bml0Y2FsbCBwcm9jX21lbWluZm9faW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA0LjAyODgwN10gY2FsbGluZyAgcHJvY19zdGF0X2luaXQrMHgwLzB4MjIgQCAxClsg
ICAgNC4wMjg5MDhdIGluaXRjYWxsIHByb2Nfc3RhdF9pbml0KzB4MC8weDIyIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI5MDEyXSBjYWxsaW5nICBwcm9jX3VwdGltZV9pbml0KzB4
MC8weDIyIEAgMQpbICAgIDQuMDI5MTE1XSBpbml0Y2FsbCBwcm9jX3VwdGltZV9pbml0KzB4MC8w
eDIyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI5MjIxXSBjYWxsaW5nICBwcm9j
X3ZlcnNpb25faW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyOTMyOV0gaW5pdGNhbGwgcHJvY192
ZXJzaW9uX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgNC4wMjk0
MzJdIGNhbGxpbmcgIHByb2Nfc29mdGlycXNfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyOTUz
Nl0gaW5pdGNhbGwgcHJvY19zb2Z0aXJxc19pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDQuMDI5NjM5XSBjYWxsaW5nICBwcm9jX2tjb3JlX2luaXQrMHgwLzB4YjUg
QCAxClsgICAgNC4wMjk3NDJdIGluaXRjYWxsIHByb2Nfa2NvcmVfaW5pdCsweDAvMHhiNSByZXR1
cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA0LjAyOTg0NV0gY2FsbGluZyAgdm1jb3JlX2luaXQr
MHgwLzB4NzAgQCAxClsgICAgNC4wMjk5NDRdIGluaXRjYWxsIHZtY29yZV9pbml0KzB4MC8weDcw
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDMwMDQ4XSBjYWxsaW5nICBwcm9jX2tt
c2dfaW5pdCsweDAvMHgyNSBAIDEKWyAgICA0LjAzMDE0N10gaW5pdGNhbGwgcHJvY19rbXNnX2lu
aXQrMHgwLzB4MjUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzAyNTBdIGNhbGxp
bmcgIHByb2NfcGFnZV9pbml0KzB4MC8weDQyIEAgMQpbICAgIDQuMDMwMzUzXSBpbml0Y2FsbCBw
cm9jX3BhZ2VfaW5pdCsweDAvMHg0MiByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjAz
MDQ1OV0gY2FsbGluZyAgcHJvY192ZXJzaW9uX3NpZ25hdHVyZV9pbml0KzB4MC8weDIyIEAgMQpb
ICAgIDQuMDMwNTYzXSBpbml0Y2FsbCBwcm9jX3ZlcnNpb25fc2lnbmF0dXJlX2luaXQrMHgwLzB4
MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzA2ODhdIGNhbGxpbmcgIGluaXRf
ZGV2cHRzX2ZzKzB4MC8weDRhIEAgMQpbICAgIDQuMDMwODAxXSBpbml0Y2FsbCBpbml0X2RldnB0
c19mcysweDAvMHg0YSByZXR1cm5lZCAwIGFmdGVyIDEwIHVzZWNzClsgICAgNC4wMzA5MDVdIGNh
bGxpbmcgIGluaXRfZXh0M19mcysweDAvMHg3NiBAIDEKWyAgICA0LjAzMTA0MF0gaW5pdGNhbGwg
aW5pdF9leHQzX2ZzKzB4MC8weDc2IHJldHVybmVkIDAgYWZ0ZXIgMzMgdXNlY3MKWyAgICA0LjAz
MTE0NV0gY2FsbGluZyAgZXh0NF9pbml0X2ZzKzB4MC8weDVjIEAgMQpbICAgIDQuMDMxMzM0XSBp
bml0Y2FsbCBleHQ0X2luaXRfZnMrMHgwLzB4NWMgcmV0dXJuZWQgMCBhZnRlciA4NCB1c2Vjcwpb
ICAgIDQuMDMxNDM5XSBjYWxsaW5nICBqb3VybmFsX2luaXQrMHgwLzB4MWUgQCAxClsgICAgNC4w
MzE1ODldIGluaXRjYWxsIGpvdXJuYWxfaW5pdCsweDAvMHgxZSByZXR1cm5lZCAwIGFmdGVyIDQ3
IHVzZWNzClsgICAgNC4wMzE2OTNdIGNhbGxpbmcgIGpvdXJuYWxfaW5pdCsweDAvMHgzNCBAIDEK
WyAgICA0LjAzMTgwMF0gaW5pdGNhbGwgam91cm5hbF9pbml0KzB4MC8weDM0IHJldHVybmVkIDAg
YWZ0ZXIgNSB1c2VjcwpbICAgIDQuMDMxOTA0XSBjYWxsaW5nICBpbml0X3JhbWZzX2ZzKzB4MC8w
eDEyIEAgMQpbICAgIDQuMDMyMDAzXSBpbml0Y2FsbCBpbml0X3JhbWZzX2ZzKzB4MC8weDEyIHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDMyMTA5XSBjYWxsaW5nICBpbml0X2h1Z2V0
bGJmc19mcysweDAvMHg5NSBAIDEKWyAgICA0LjAzMjI0Ml0gaW5pdGNhbGwgaW5pdF9odWdldGxi
ZnNfZnMrMHgwLzB4OTUgcmV0dXJuZWQgMCBhZnRlciAzMCB1c2VjcwpbICAgIDQuMDMyMzQ2XSBj
YWxsaW5nICBlY3J5cHRmc19pbml0KzB4MC8weDFlNiBAIDEKWyAgICA0LjAzMjU2OV0gaW5pdGNh
bGwgZWNyeXB0ZnNfaW5pdCsweDAvMHgxZTYgcmV0dXJuZWQgMCBhZnRlciAxMTggdXNlY3MKWyAg
ICA0LjAzMjY3NV0gY2FsbGluZyAgZnVzZV9pbml0KzB4MC8weDFiMCBAIDEKWyAgICA0LjAzMjc3
NV0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjE3KQpbICAgIDQuMDMyOTQwXSBpbml0Y2FsbCBm
dXNlX2luaXQrMHgwLzB4MWIwIHJldHVybmVkIDAgYWZ0ZXIgMTU5IHVzZWNzClsgICAgNC4wMzMw
NDVdIGNhbGxpbmcgIGluaXRfcHN0b3JlX2ZzKzB4MC8weDEyIEAgMQpbICAgIDQuMDMzMTQ3XSBp
bml0Y2FsbCBpbml0X3BzdG9yZV9mcysweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjAzMzI1MV0gY2FsbGluZyAgaXBjX2luaXQrMHgwLzB4MmYgQCAxClsgICAgNC4wMzMz
NTNdIG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gMTQ4MApbICAgIDQuMDMzNDUzXSBpbml0Y2FsbCBp
cGNfaW5pdCsweDAvMHgyZiByZXR1cm5lZCAwIGFmdGVyIDk5IHVzZWNzClsgICAgNC4wMzM1NTVd
IGNhbGxpbmcgIGlwY19zeXNjdGxfaW5pdCsweDAvMHgxNCBAIDEKWyAgICA0LjAzNTM2OV0gaW5p
dGNhbGwgaXBjX3N5c2N0bF9pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMTUgdXNlY3MK
WyAgICA0LjAzNTQ3NF0gY2FsbGluZyAgaW5pdF9tcXVldWVfZnMrMHgwLzB4OWYgQCAxClsgICAg
NC4wMzU2MTddIGluaXRjYWxsIGluaXRfbXF1ZXVlX2ZzKzB4MC8weDlmIHJldHVybmVkIDAgYWZ0
ZXIgMzkgdXNlY3MKWyAgICA0LjAzNTcyM10gY2FsbGluZyAga2V5X3Byb2NfaW5pdCsweDAvMHgz
MyBAIDEKWyAgICA0LjAzNTgyN10gaW5pdGNhbGwga2V5X3Byb2NfaW5pdCsweDAvMHgzMyByZXR1
cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjAzNTkzMl0gY2FsbGluZyAgc2VsaW51eF9uZl9p
cF9pbml0KzB4MC8weDY5IEAgMQpbICAgIDQuMDM2MDM1XSBpbml0Y2FsbCBzZWxpbnV4X25mX2lw
X2luaXQrMHgwLzB4NjkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzYxMzldIGNh
bGxpbmcgIGluaXRfc2VsX2ZzKzB4MC8weDliIEAgMQpbICAgIDQuMDM2MjQwXSBpbml0Y2FsbCBp
bml0X3NlbF9mcysweDAvMHg5YiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjAzNjM0
Ml0gY2FsbGluZyAgc2VsbmxfaW5pdCsweDAvMHg0ZCBAIDEKWyAgICA0LjAzNjQ0OF0gaW5pdGNh
bGwgc2VsbmxfaW5pdCsweDAvMHg0ZCByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICA0LjAz
NjU1MV0gY2FsbGluZyAgc2VsX25ldGlmX2luaXQrMHgwLzB4NzMgQCAxClsgICAgNC4wMzY2NTNd
IGluaXRjYWxsIHNlbF9uZXRpZl9pbml0KzB4MC8weDczIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDQuMDM2NzU4XSBjYWxsaW5nICBzZWxfbmV0bm9kZV9pbml0KzB4MC8weDc0IEAgMQpb
ICAgIDQuMDM2ODU5XSBpbml0Y2FsbCBzZWxfbmV0bm9kZV9pbml0KzB4MC8weDc0IHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM2OTY1XSBjYWxsaW5nICBzZWxfbmV0cG9ydF9pbml0
KzB4MC8weDc0IEAgMQpbICAgIDQuMDM3MDY3XSBpbml0Y2FsbCBzZWxfbmV0cG9ydF9pbml0KzB4
MC8weDc0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM3MTczXSBjYWxsaW5nICBh
dXJ1bGVfaW5pdCsweDAvMHgzNyBAIDEKWyAgICA0LjAzNzI3Ml0gaW5pdGNhbGwgYXVydWxlX2lu
aXQrMHgwLzB4MzcgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzczNzZdIGNhbGxp
bmcgIGluaXRfc21rX2ZzKzB4MC8weDIxIEAgMQpbICAgIDQuMDM3NDc2XSBpbml0Y2FsbCBpbml0
X3Nta19mcysweDAvMHgyMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjAzNzU3OV0g
Y2FsbGluZyAgY3J5cHRvX3dxX2luaXQrMHgwLzB4MzEgQCAxClsgICAgNC4wMzc3MDddIGluaXRj
YWxsIGNyeXB0b193cV9pbml0KzB4MC8weDMxIHJldHVybmVkIDAgYWZ0ZXIgMjQgdXNlY3MKWyAg
ICA0LjAzNzgxMF0gY2FsbGluZyAgY3J5cHRvX2FsZ2FwaV9pbml0KzB4MC8weGQgQCAxClsgICAg
NC4wMzc5MTVdIGluaXRjYWxsIGNyeXB0b19hbGdhcGlfaW5pdCsweDAvMHhkIHJldHVybmVkIDAg
YWZ0ZXIgMSB1c2VjcwpbICAgIDQuMDM4MDIwXSBjYWxsaW5nICBza2NpcGhlcl9tb2R1bGVfaW5p
dCsweDAvMHgzNSBAIDEKWyAgICA0LjAzODEyMV0gaW5pdGNhbGwgc2tjaXBoZXJfbW9kdWxlX2lu
aXQrMHgwLzB4MzUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzgyMjhdIGNhbGxp
bmcgIGNoYWluaXZfbW9kdWxlX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wMzgzMjldIGluaXRj
YWxsIGNoYWluaXZfbW9kdWxlX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgNC4wMzg0MzZdIGNhbGxpbmcgIGVzZXFpdl9tb2R1bGVfaW5pdCsweDAvMHgxMiBAIDEK
WyAgICA0LjAzODUzOV0gaW5pdGNhbGwgZXNlcWl2X21vZHVsZV9pbml0KzB4MC8weDEyIHJldHVy
bmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM4NjQ0XSBjYWxsaW5nICBobWFjX21vZHVsZV9p
bml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDM4NzQ2XSBpbml0Y2FsbCBobWFjX21vZHVsZV9pbml0
KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM4ODUxXSBjYWxsaW5n
ICBtZDVfbW9kX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wMzg5ODJdIGluaXRjYWxsIG1kNV9t
b2RfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDI5IHVzZWNzClsgICAgNC4wMzkwODZd
IGNhbGxpbmcgIHNoYTFfZ2VuZXJpY19tb2RfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjAzOTIx
OV0gaW5pdGNhbGwgc2hhMV9nZW5lcmljX21vZF9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0
ZXIgMzEgdXNlY3MKWyAgICA0LjAzOTMyNV0gY2FsbGluZyAgc2hhMjU2X2dlbmVyaWNfbW9kX2lu
aXQrMHgwLzB4M2MgQCAxClsgICAgNC4wMzk0ODRdIGluaXRjYWxsIHNoYTI1Nl9nZW5lcmljX21v
ZF9pbml0KzB4MC8weDNjIHJldHVybmVkIDAgYWZ0ZXIgNTQgdXNlY3MKWyAgICA0LjAzOTYwN10g
Y2FsbGluZyAgY3J5cHRvX2VjYl9tb2R1bGVfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjAzOTcw
N10gaW5pdGNhbGwgY3J5cHRvX2VjYl9tb2R1bGVfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICA0LjAzOTgxM10gY2FsbGluZyAgY3J5cHRvX2NiY19tb2R1bGVfaW5p
dCsweDAvMHgxMiBAIDEKWyAgICA0LjAzOTkxNF0gaW5pdGNhbGwgY3J5cHRvX2NiY19tb2R1bGVf
aW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjA0MDAyMF0gY2Fs
bGluZyAgYWVzX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wNDAxNTRdIGluaXRjYWxsIGFlc19p
bml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMzIgdXNlY3MKWyAgICA0LjA0MDI1OF0gY2Fs
bGluZyAgY3JjMzJjX21vZF9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDQwMzkzXSBpbml0Y2Fs
bCBjcmMzMmNfbW9kX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAzMSB1c2VjcwpbICAg
IDQuMDQwNDk5XSBjYWxsaW5nICBrcm5nX21vZF9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDQw
NjM0XSBpbml0Y2FsbCBrcm5nX21vZF9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMzIg
dXNlY3MKWyAgICA0LjA0MDc0MF0gY2FsbGluZyAgcHJvY19nZW5oZF9pbml0KzB4MC8weDNjIEAg
MQpbICAgIDQuMDQwODQxXSBpbml0Y2FsbCBwcm9jX2dlbmhkX2luaXQrMHgwLzB4M2MgcmV0dXJu
ZWQgMCBhZnRlciAyIHVzZWNzClsgICAgNC4wNDA5NDNdIGNhbGxpbmcgIGJzZ19pbml0KzB4MC8w
eDEyZSBAIDEKWyAgICA0LjA0MTA2N10gQmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRy
aXZlciB2ZXJzaW9uIDAuNCBsb2FkZWQgKG1ham9yIDI1MykKWyAgICA0LjA0MTE5Ml0gaW5pdGNh
bGwgYnNnX2luaXQrMHgwLzB4MTJlIHJldHVybmVkIDAgYWZ0ZXIgMTQ1IHVzZWNzClsgICAgNC4w
NDEyOTddIGNhbGxpbmcgIGluaXRfY2dyb3VwX2Jsa2lvKzB4MC8weDEyIEAgMQpbICAgIDQuMDQx
Mzk5XSBpbml0Y2FsbCBpbml0X2Nncm91cF9ibGtpbysweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICA0LjA0MTUwMV0gY2FsbGluZyAgdGhyb3RsX2luaXQrMHgwLzB4NDQgQCAx
ClsgICAgNC4wNDE2MjldIGluaXRjYWxsIHRocm90bF9pbml0KzB4MC8weDQ0IHJldHVybmVkIDAg
YWZ0ZXIgMjQgdXNlY3MKWyAgICA0LjA0MTczM10gY2FsbGluZyAgbm9vcF9pbml0KzB4MC8weDE0
IEAgMQpbICAgIDQuMDQxODM1XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsgICAgNC4w
NDE5MzVdIGluaXRjYWxsIG5vb3BfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDk3IHVz
ZWNzClsgICAgNC4wNDIwMzddIGNhbGxpbmcgIGRlYWRsaW5lX2luaXQrMHgwLzB4MTQgQCAxClsg
ICAgNC4wNDIxMzddIGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgNC4wNDIy
MzhdIGluaXRjYWxsIGRlYWRsaW5lX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciA5NyB1
c2VjcwpbICAgIDQuMDQyMzQzXSBjYWxsaW5nICBjZnFfaW5pdCsweDAvMHhiMyBAIDEKWyAgICA0
LjA0MjQ2NF0gaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZhdWx0KQpbICAgIDQuMDQy
NTYyXSBpbml0Y2FsbCBjZnFfaW5pdCsweDAvMHhiMyByZXR1cm5lZCAwIGFmdGVyIDExNiB1c2Vj
cwpbICAgIDQuMDQyNjY0XSBjYWxsaW5nICBwZXJjcHVfY291bnRlcl9zdGFydHVwKzB4MC8weDE5
IEAgMQpbICAgIDQuMDQyNzY3XSBpbml0Y2FsbCBwZXJjcHVfY291bnRlcl9zdGFydHVwKzB4MC8w
eDE5IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDQyODcyXSBjYWxsaW5nICBsbndf
Z3Bpb19pbml0KzB4MC8weDQ1IEAgMQpbICAgIDQuMDQyOTkyXSBpbml0Y2FsbCBsbndfZ3Bpb19p
bml0KzB4MC8weDQ1IHJldHVybmVkIDAgYWZ0ZXIgMTggdXNlY3MKWyAgICA0LjA0MzA5Nl0gY2Fs
bGluZyAgdGltYmdwaW9faW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjA0MzIwMl0gaW5pdGNhbGwg
dGltYmdwaW9faW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MKWyAgICA0LjA0
MzMwNl0gY2FsbGluZyAgdWNiMTQwMF9ncGlvX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wNDM0
MTBdIGluaXRjYWxsIHVjYjE0MDBfZ3Bpb19pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIg
MyB1c2VjcwpbICAgIDQuMDQzNTE0XSBjYWxsaW5nICBwY2lfcHJvY19pbml0KzB4MC8weDY5IEAg
MQpbICAgIDQuMDQzNjM5XSBpbml0Y2FsbCBwY2lfcHJvY19pbml0KzB4MC8weDY5IHJldHVybmVk
IDAgYWZ0ZXIgMjQgdXNlY3MKWyAgICA0LjA0Mzc0NF0gY2FsbGluZyAgcGNpZV9wb3J0ZHJ2X2lu
aXQrMHgwLzB4NzcgQCAxClsgICAgNC4wNDM4NjldIHBjaWVwb3J0IDAwMDA6MDA6MDEuMDogc2V0
dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4wNDQxNDRdIHBjaWVwb3J0IDAwMDA6MDA6
MWMuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4wNDQ3MTVdIHBjaWVwb3J0
IDAwMDA6MDA6MWMuNDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4wNDUyNjld
IGluaXRjYWxsIHBjaWVfcG9ydGRydl9pbml0KzB4MC8weDc3IHJldHVybmVkIDAgYWZ0ZXIgMTM5
MCB1c2VjcwpbICAgIDQuMDQ1MzY5XSBjYWxsaW5nICBhZXJfc2VydmljZV9pbml0KzB4MC8weDMx
IEAgMQpbICAgIDQuMDQ1NDczXSBpbml0Y2FsbCBhZXJfc2VydmljZV9pbml0KzB4MC8weDMxIHJl
dHVybmVkIDAgYWZ0ZXIgNCB1c2VjcwpbICAgIDQuMDQ1NTc4XSBjYWxsaW5nICBwY2llX3BtZV9z
ZXJ2aWNlX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wNDU3MDhdIHBjaWVwb3J0IDAwMDA6MDA6
MDEuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuMDQ1
ODEyXSBwY2kgMDAwMDowMTowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50
ZXJydXB0ClsgICAgNC4wNDU5MTddIHBjaWVfcG1lIDAwMDA6MDA6MDEuMDpwY2llMDE6IHNlcnZp
Y2UgZHJpdmVyIHBjaWVfcG1lIGxvYWRlZApbICAgIDQuMDQ2MDc4XSBwY2llcG9ydCAwMDAwOjAw
OjFjLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjA0
NjE5M10gcGNpZV9wbWUgMDAwMDowMDoxYy4wOnBjaWUwMTogc2VydmljZSBkcml2ZXIgcGNpZV9w
bWUgbG9hZGVkClsgICAgNC4wNDYzNTldIHBjaWVwb3J0IDAwMDA6MDA6MWMuNDogU2lnbmFsaW5n
IFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuMDQ2NDY1XSBwY2kgMDAwMDow
MzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC4w
NDY1ODBdIHBjaWVfcG1lIDAwMDA6MDA6MWMuNDpwY2llMDE6IHNlcnZpY2UgZHJpdmVyIHBjaWVf
cG1lIGxvYWRlZApbICAgIDQuMDQ2Njg2XSBpbml0Y2FsbCBwY2llX3BtZV9zZXJ2aWNlX2luaXQr
MHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA5ODEgdXNlY3MKWyAgICA0LjA0NjgwOV0gY2FsbGlu
ZyAgaW9hcGljX2luaXQrMHgwLzB4MWIgQCAxClsgICAgNC4wNDY5MTVdIGluaXRjYWxsIGlvYXBp
Y19pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgNiB1c2VjcwpbICAgIDQuMDQ3MDIwXSBj
YWxsaW5nICBwY2lfaG90cGx1Z19pbml0KzB4MC8weDRiIEAgMQpbICAgIDQuMDQ3MTIxXSBwY2lf
aG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpbICAgIDQuMDQ3MjI0
XSBpbml0Y2FsbCBwY2lfaG90cGx1Z19pbml0KzB4MC8weDRiIHJldHVybmVkIDAgYWZ0ZXIgOTkg
dXNlY3MKWyAgICA0LjA0NzMyOV0gY2FsbGluZyAgcGNpZWRfaW5pdCsweDAvMHhmMCBAIDEKWyAg
ICA0LjA0NzQ0NF0gcGNpZWhwOiBQQ0kgRXhwcmVzcyBIb3QgUGx1ZyBDb250cm9sbGVyIERyaXZl
ciB2ZXJzaW9uOiAwLjQKWyAgICA0LjA0NzU0OF0gaW5pdGNhbGwgcGNpZWRfaW5pdCsweDAvMHhm
MCByZXR1cm5lZCAwIGFmdGVyIDExNCB1c2VjcwpbICAgIDQuMDQ3NjUyXSBjYWxsaW5nICB0c2k3
MjFfaW5pdCsweDAvMHgxYiBAIDEKWyAgICA0LjA0Nzc1OV0gaW5pdGNhbGwgdHNpNzIxX2luaXQr
MHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgNC4wNDc4NjRdIGNhbGxpbmcg
IGZiX2NvbnNvbGVfaW5pdCsweDAvMHgxMWUgQCAxClsgICAgNC4wNDc5NzddIGluaXRjYWxsIGZi
X2NvbnNvbGVfaW5pdCsweDAvMHgxMWUgcmV0dXJuZWQgMCBhZnRlciAxMyB1c2VjcwpbICAgIDQu
MDQ4MDg0XSBjYWxsaW5nICBpbXN0dGZiX2luaXQrMHgwLzB4NGQgQCAxClsgICAgNC4wNDgxOTBd
IGluaXRjYWxsIGltc3R0ZmJfaW5pdCsweDAvMHg0ZCByZXR1cm5lZCAwIGFmdGVyIDYgdXNlY3MK
WyAgICA0LjA0ODI5NV0gY2FsbGluZyAgYXNpbGlhbnRmYl9pbml0KzB4MC8weDM0IEAgMQpbICAg
IDQuMDQ4Mzk5XSBpbml0Y2FsbCBhc2lsaWFudGZiX2luaXQrMHgwLzB4MzQgcmV0dXJuZWQgMCBh
ZnRlciA1IHVzZWNzClsgICAgNC4wNDg1MDRdIGNhbGxpbmcgIGVmaWZiX2luaXQrMHgwLzB4OTIg
QCAxClsgICAgNC4wNDg2MDddIGluaXRjYWxsIGVmaWZiX2luaXQrMHgwLzB4OTIgcmV0dXJuZWQg
LTE5IGFmdGVyIDIgdXNlY3MKWyAgICA0LjA0ODcwOV0gY2FsbGluZyAgaW50ZWxfaWRsZV9pbml0
KzB4MC8weDZlIEAgMQpbICAgIDQuMDQ4ODA5XSBpbml0Y2FsbCBpbnRlbF9pZGxlX2luaXQrMHgw
LzB4NmUgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MKWyAgICA0LjA0ODkxNF0gY2FsbGluZyAg
YWNwaV9yZXNlcnZlX3Jlc291cmNlcysweDAvMHhlYiBAIDEKWyAgICA0LjA0OTAxOV0gaW5pdGNh
bGwgYWNwaV9yZXNlcnZlX3Jlc291cmNlcysweDAvMHhlYiByZXR1cm5lZCAwIGFmdGVyIDIgdXNl
Y3MKWyAgICA0LjA0OTEyNl0gY2FsbGluZyAgaXJxcm91dGVyX2luaXRfb3BzKzB4MC8weDI2IEAg
MQpbICAgIDQuMDQ5MjI4XSBpbml0Y2FsbCBpcnFyb3V0ZXJfaW5pdF9vcHMrMHgwLzB4MjYgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wNDkzMzFdIGNhbGxpbmcgIGFjcGlfYWNfaW5p
dCsweDAvMHg1MCBAIDEKWyAgICA0LjA0OTQ1Nl0gaW5pdGNhbGwgYWNwaV9hY19pbml0KzB4MC8w
eDUwIHJldHVybmVkIDAgYWZ0ZXIgMjQgdXNlY3MKWyAgICA0LjA0OTU2MF0gY2FsbGluZyAgYWNw
aV9idXR0b25faW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjA0OTY5NV0gaW5wdXQ6IFBvd2VyIEJ1
dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9kZXZpY2U6MDAvUE5QMEMwQzowMC9pbnB1dC9p
bnB1dDAKWyAgICA0LjA0OTgyM10gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JCXQpbICAgIDQuMDQ5
OTQ4XSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFBXUkJO
OjAwL2lucHV0L2lucHV0MQpbICAgIDQuMDUwMDcxXSBBQ1BJOiBQb3dlciBCdXR0b24gW1BXUkZd
ClsgICAgNC4wNTAxOTJdIGluaXRjYWxsIGFjcGlfYnV0dG9uX2luaXQrMHgwLzB4MTIgcmV0dXJu
ZWQgMCBhZnRlciA1MTkgdXNlY3MKWyAgICA0LjA1MDI5OF0gY2FsbGluZyAgYWNwaV9mYW5faW5p
dCsweDAvMHgxOCBAIDEKWyAgICA0LjA1MDQxMV0gaW5pdGNhbGwgYWNwaV9mYW5faW5pdCsweDAv
MHgxOCByZXR1cm5lZCAwIGFmdGVyIDExIHVzZWNzClsgICAgNC4wNTA1MTZdIGNhbGxpbmcgIGFj
cGlfcHJvY2Vzc29yX2luaXQrMHgwLzB4ODEgQCAxClsgICAgNC4wNTA4OTVdIGluaXRjYWxsIGFj
cGlfcHJvY2Vzc29yX2luaXQrMHgwLzB4ODEgcmV0dXJuZWQgMCBhZnRlciAyNjcgdXNlY3MKWyAg
ICA0LjA1MDk5OV0gY2FsbGluZyAgYWNwaV9jb250YWluZXJfaW5pdCsweDAvMHg0YSBAIDEKWyAg
ICA0LjA1MjI2N10gaW5pdGNhbGwgYWNwaV9jb250YWluZXJfaW5pdCsweDAvMHg0YSByZXR1cm5l
ZCAwIGFmdGVyIDExMzUgdXNlY3MKWyAgICA0LjA1MjM3M10gY2FsbGluZyAgYWNwaV90aGVybWFs
X2luaXQrMHgwLzB4NDIgQCAxClsgICAgNC4wNTI0ODZdIGluaXRjYWxsIGFjcGlfdGhlcm1hbF9p
bml0KzB4MC8weDQyIHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MKWyAgICA0LjA1MjU5Ml0gY2Fs
bGluZyAgYWNwaV9iYXR0ZXJ5X2luaXQrMHgwLzB4NDggQCAxClsgICAgNC4wNTI3MDldIGluaXRj
YWxsIGFjcGlfYmF0dGVyeV9pbml0KzB4MC8weDQ4IHJldHVybmVkIDAgYWZ0ZXIgMTIgdXNlY3MK
WyAgICA0LjA1MjgxNF0gY2FsbGluZyAgYWNwaV9oZWRfaW5pdCsweDAvMHgyNiBAIDEKWyAgICA0
LjA1MjkyM10gaW5pdGNhbGwgYWNwaV9oZWRfaW5pdCsweDAvMHgyNiByZXR1cm5lZCAwIGFmdGVy
IDEwIHVzZWNzClsgICAgNC4wNTMwMzJdIGNhbGxpbmcgIGVyc3RfaW5pdCsweDAvMHgyYTUgQCAx
ClsgICAgNC4wNTMxNzJdIEFQRUk6IENhbiBub3QgcmVxdWVzdCBpb21lbSByZWdpb24gPDAwMDAw
MDAwYmY0ODkwM2UtMDAwMDAwMDBiZjQ4OTAzZj4gZm9yIEdBUnMuClsgICAgNC4wNTMyOTddIGlu
aXRjYWxsIGVyc3RfaW5pdCsweDAvMHgyYTUgcmV0dXJuZWQgLTIyIGFmdGVyIDE2NCB1c2Vjcwpb
ICAgIDQuMDUzNDAxXSBpbml0Y2FsbCBlcnN0X2luaXQrMHgwLzB4MmE1IHJldHVybmVkIHdpdGgg
ZXJyb3IgY29kZSAtMjIgClsgICAgNC4wNTM1MDVdIGNhbGxpbmcgIGdoZXNfaW5pdCsweDAvMHgx
NzEgQCAxClsgICAgNC4wNTM2NjRdIFtGaXJtd2FyZSBXYXJuXTogR0hFUzogUG9sbCBpbnRlcnZh
bCBpcyAwIGZvciBnZW5lcmljIGhhcmR3YXJlIGVycm9yIHNvdXJjZTogMSwgZGlzYWJsZWQuClsg
ICAgNC4wNTM4NDFdIEdIRVM6IEFQRUkgZmlybXdhcmUgZmlyc3QgbW9kZSBpcyBlbmFibGVkIGJ5
IFdIRUEgX09TQy4KWyAgICA0LjA1Mzk0Nl0gaW5pdGNhbGwgZ2hlc19pbml0KzB4MC8weDE3MSBy
ZXR1cm5lZCAwIGFmdGVyIDMzMiB1c2VjcwpbICAgIDQuMDU0MDQ4XSBjYWxsaW5nICB2aXJ0aW9f
cGNpX2luaXQrMHgwLzB4MWIgQCAxClsgICAgNC4wNTQxNThdIGluaXRjYWxsIHZpcnRpb19wY2lf
aW5pdCsweDAvMHgxYiByZXR1cm5lZCAwIGFmdGVyIDggdXNlY3MKWyAgICA0LjA1NDI2M10gY2Fs
bGluZyAgeGVuYnVzX3Byb2JlX2luaXRjYWxsKzB4MC8weDM5IEAgMQpbICAgIDQuMDU0MzY3XSBp
bml0Y2FsbCB4ZW5idXNfcHJvYmVfaW5pdGNhbGwrMHgwLzB4MzkgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgNC4wNTQ0NzNdIGNhbGxpbmcgIGh5cGVydmlzb3Jfc3Vic3lzX2luaXQrMHgw
LzB4MjUgQCAxClsgICAgNC4wNTQ1NzVdIGluaXRjYWxsIGh5cGVydmlzb3Jfc3Vic3lzX2luaXQr
MHgwLzB4MjUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wNTQ2ODJdIGNhbGxpbmcg
IGh5cGVyX3N5c2ZzX2luaXQrMHgwLzB4MTkgQCAxClsgICAgNC4wNTQ3OTFdIGluaXRjYWxsIGh5
cGVyX3N5c2ZzX2luaXQrMHgwLzB4MTkgcmV0dXJuZWQgMCBhZnRlciA3IHVzZWNzClsgICAgNC4w
NTQ4OTddIGNhbGxpbmcgIHBsYXRmb3JtX3BjaV9tb2R1bGVfaW5pdCsweDAvMHgyOSBAIDEKWyAg
ICA0LjA1NTAwMF0gaW5pdGNhbGwgcGxhdGZvcm1fcGNpX21vZHVsZV9pbml0KzB4MC8weDI5IHJl
dHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgNC4wNTUxMjZdIGNhbGxpbmcgIHhlbl90bWVt
X2luaXQrMHgwLzB4NWMgQCAxClsgICAgNC4wNTUyMjddIGluaXRjYWxsIHhlbl90bWVtX2luaXQr
MHgwLzB4NWMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wNTUzMjhdIGNhbGxpbmcg
IHB0eV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDU1NDY5XSBpbml0Y2FsbCBwdHlfaW5pdCsw
eDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDM5IHVzZWNzClsgICAgNC4wNTU1NzRdIGNhbGxpbmcg
IHN5c3JxX2luaXQrMHgwLzB4NzggQCAxClsgICAgNC4wNTU2NzZdIGluaXRjYWxsIHN5c3JxX2lu
aXQrMHgwLzB4NzggcmV0dXJuZWQgMCBhZnRlciAyIHVzZWNzClsgICAgNC4wNTU3ODJdIGNhbGxp
bmcgIHhlbl9odmNfaW5pdCsweDAvMHgxM2UgQCAxClsgICAgNC4wNTYxMDRdIGluaXRjYWxsIHhl
bl9odmNfaW5pdCsweDAvMHgxM2UgcmV0dXJuZWQgMCBhZnRlciAyMTcgdXNlY3MKWyAgICA0LjA1
NjIxMF0gY2FsbGluZyAgc2VyaWFsODI1MF9pbml0KzB4MC8weDY1IEAgMQpbICAgIDQuMDU2MzEw
XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCAzMiBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxl
ZApbICAgIDQuMDc3NTY3XSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQp
IGlzIGEgMTY1NTBBClsgICAgNC4xMTQzMjRdIHNlcmlhbDgyNTA6IHR0eVMxIGF0IEkvTyAweDJm
OCAoaXJxID0gMykgaXMgYSAxNjU1MEEKWyAgICA0LjE0MjM1Ml0gc2VyaWFsODI1MDogdHR5UzIg
YXQgSS9PIDB4M2U4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQpbICAgIDQuMTQ0MzA4XSBpbml0Y2Fs
bCBzZXJpYWw4MjUwX2luaXQrMHgwLzB4NjUgcmV0dXJuZWQgMCBhZnRlciA4NTkzNCB1c2Vjcwpb
ICAgIDQuMTQ0NDE0XSBjYWxsaW5nICBzZXJpYWw4MjUwX3BucF9pbml0KzB4MC8weDEyIEAgMQpb
ICAgIDQuMTY1NzIzXSAwMDowYTogdHR5UzAgYXQgSS9PIDB4M2Y4IChpcnEgPSA0KSBpcyBhIDE2
NTUwQQpbICAgIDQuMjAyMzY5XSAwMDowYjogdHR5UzEgYXQgSS9PIDB4MmY4IChpcnEgPSAzKSBp
cyBhIDE2NTUwQQpbICAgIDQuMjM0MzY0XSAwMDowZDogdHR5UzIgYXQgSS9PIDB4M2U4IChpcnEg
PSAxMCkgaXMgYSAxNjU1MEEKWyAgICA0LjI0OTE2OF0gaW5pdGNhbGwgc2VyaWFsODI1MF9wbnBf
aW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDEwMjE5NyB1c2VjcwpbICAgIDQuMjQ5MzE1
XSBjYWxsaW5nICBzZXJpYWw4MjUwX3BjaV9pbml0KzB4MC8weDFiIEAgMQpbICAgIDQuMjQ5NDMz
XSBpbml0Y2FsbCBzZXJpYWw4MjUwX3BjaV9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIg
MTUgdXNlY3MKWyAgICA0LjI0OTU0MV0gY2FsbGluZyAgaW5pdF9rZ2Rib2MrMHgwLzB4MTYgQCAx
ClsgICAgNC4yNDk2NDBdIGluaXRjYWxsIGluaXRfa2dkYm9jKzB4MC8weDE2IHJldHVybmVkIDAg
YWZ0ZXIgMSB1c2VjcwpbICAgIDQuMjQ5NzQ0XSBjYWxsaW5nICByYW5kX2luaXRpYWxpemUrMHgw
LzB4NDAgQCAxClsgICAgNC4yNDk4NTVdIGluaXRjYWxsIHJhbmRfaW5pdGlhbGl6ZSsweDAvMHg0
MCByZXR1cm5lZCAwIGFmdGVyIDkgdXNlY3MKWyAgICA0LjI0OTk1OF0gY2FsbGluZyAgdHR5cHJp
bnRrX2luaXQrMHgwLzB4MTUzIEAgMQpbICAgIDQuMjUwMDg4XSBpbml0Y2FsbCB0dHlwcmludGtf
aW5pdCsweDAvMHgxNTMgcmV0dXJuZWQgMCBhZnRlciAyNyB1c2VjcwpbICAgIDQuMjUwMTkyXSBj
YWxsaW5nICBocGV0X2luaXQrMHgwLzB4NjcgQCAxClsgICAgNC4yNTAzNjldIGhwZXRfYWNwaV9h
ZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBpbiBfQ1JTClsgICAgNC4yNTA0NzldIGluaXRjYWxsIGhw
ZXRfaW5pdCsweDAvMHg2NyByZXR1cm5lZCAwIGFmdGVyIDE4MiB1c2VjcwpbICAgIDQuMjUwNTgy
XSBjYWxsaW5nICBhZ3BfaW5pdCsweDAvMHgyNiBAIDEKWyAgICA0LjI1MDY4Ml0gTGludXggYWdw
Z2FydCBpbnRlcmZhY2UgdjAuMTAzClsgICAgNC4yNTA3ODNdIGluaXRjYWxsIGFncF9pbml0KzB4
MC8weDI2IHJldHVybmVkIDAgYWZ0ZXIgOTggdXNlY3MKWyAgICA0LjI1MDg4N10gY2FsbGluZyAg
YWdwX2FtZDY0X21vZF9pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMjUxMDAwXSBpbml0Y2FsbCBh
Z3BfYW1kNjRfbW9kX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgLTE5IGFmdGVyIDEzIHVzZWNzClsg
ICAgNC4yNTExMDVdIGNhbGxpbmcgIGFncF9pbnRlbF9pbml0KzB4MC8weDI5IEAgMQpbICAgIDQu
MjUxMjcxXSBpbml0Y2FsbCBhZ3BfaW50ZWxfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVy
IDYzIHVzZWNzClsgICAgNC4yNTEzNzVdIGNhbGxpbmcgIGFncF92aWFfaW5pdCsweDAvMHgyOSBA
IDEKWyAgICA0LjI1MTQ4MV0gaW5pdGNhbGwgYWdwX3ZpYV9pbml0KzB4MC8weDI5IHJldHVybmVk
IDAgYWZ0ZXIgNiB1c2VjcwpbICAgIDQuMjUxNTg0XSBjYWxsaW5nICBjbl9wcm9jX2luaXQrMHgw
LzB4M2EgQCAxClsgICAgNC4yNTE2ODZdIGluaXRjYWxsIGNuX3Byb2NfaW5pdCsweDAvMHgzYSBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjI1MTc5MF0gY2FsbGluZyAgdG9wb2xvZ3lf
c3lzZnNfaW5pdCsweDAvMHg2NyBAIDEKWyAgICA0LjI1MTkwMV0gaW5pdGNhbGwgdG9wb2xvZ3lf
c3lzZnNfaW5pdCsweDAvMHg2NyByZXR1cm5lZCAwIGFmdGVyIDcgdXNlY3MKWyAgICA0LjI1MjAw
NV0gY2FsbGluZyAgYnJkX2luaXQrMHgwLzB4MWQwIEAgMQpbICAgIDQuMjUzMDc2XSBicmQ6IG1v
ZHVsZSBsb2FkZWQKWyAgICA0LjI1MzE3NV0gaW5pdGNhbGwgYnJkX2luaXQrMHgwLzB4MWQwIHJl
dHVybmVkIDAgYWZ0ZXIgMTA0NSB1c2VjcwpbICAgIDQuMjUzMjgyXSBjYWxsaW5nICBsb29wX2lu
aXQrMHgwLzB4MTJmIEAgMQpbICAgIDQuMjUzOTEwXSBsb29wOiBtb2R1bGUgbG9hZGVkClsgICAg
NC4yNTQwMTFdIGluaXRjYWxsIGxvb3BfaW5pdCsweDAvMHgxMmYgcmV0dXJuZWQgMCBhZnRlciA2
MTMgdXNlY3MKWyAgICA0LjI1NDExNV0gY2FsbGluZyAgaW5pdCsweDAvMHg3YyBAIDEKWyAgICA0
LjI1NDI2MF0gaW5pdGNhbGwgaW5pdCsweDAvMHg3YyByZXR1cm5lZCAwIGFmdGVyIDQ1IHVzZWNz
ClsgICAgNC4yNTQzNjVdIGNhbGxpbmcgIHhsYmxrX2luaXQrMHgwLzB4OTMgQCAxClsgICAgNC4y
NTQ0NzBdIGluaXRjYWxsIHhsYmxrX2luaXQrMHgwLzB4OTMgcmV0dXJuZWQgMCBhZnRlciA0IHVz
ZWNzClsgICAgNC4yNTQ1NzJdIGNhbGxpbmcgIGh0Y3BsZF9jb3JlX2luaXQrMHgwLzB4MmIgQCAx
ClsgICAgNC4yNTQ2ODZdIGluaXRjYWxsIGh0Y3BsZF9jb3JlX2luaXQrMHgwLzB4MmIgcmV0dXJu
ZWQgLTE5IGFmdGVyIDEzIHVzZWNzClsgICAgNC4yNTQ3OTFdIGNhbGxpbmcgIHdtODk5NF9pMmNf
aW5pdCsweDAvMHgzMCBAIDEKWyAgICA0LjI1NDg5N10gaW5pdGNhbGwgd204OTk0X2kyY19pbml0
KzB4MC8weDMwIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMjU1MDAyXSBjYWxsaW5n
ICBhZHA1NTIwX2luaXQrMHgwLzB4MTQgQCAxClsgICAgNC4yNTUxMDldIGluaXRjYWxsIGFkcDU1
MjBfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA0LjI1NTIxM10g
Y2FsbGluZyAgc3BpX3RyYW5zcG9ydF9pbml0KzB4MC8weDdjIEAgMQpbICAgIDQuMjU1MzIwXSBp
bml0Y2FsbCBzcGlfdHJhbnNwb3J0X2luaXQrMHgwLzB4N2MgcmV0dXJuZWQgMCBhZnRlciA2IHVz
ZWNzClsgICAgNC4yNTU0MjVdIGNhbGxpbmcgIHNjc2lfZGhfaW5pdCsweDAvMHg1MyBAIDEKWyAg
ICA0LjI1NTUyNl0gaW5pdGNhbGwgc2NzaV9kaF9pbml0KzB4MC8weDUzIHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDQuMjU1NjMxXSBjYWxsaW5nICBzeW0yX2luaXQrMHgwLzB4NTUgQCAx
ClsgICAgNC4yNTU3MzhdIGluaXRjYWxsIHN5bTJfaW5pdCsweDAvMHg1NSByZXR1cm5lZCAwIGFm
dGVyIDggdXNlY3MKWyAgICA0LjI1NTg0Ml0gY2FsbGluZyAgaW5pdF9zZCsweDAvMHgxMzEgQCAx
ClsgICAgNC4yNTU5NTNdIGluaXRjYWxsIGluaXRfc2QrMHgwLzB4MTMxIHJldHVybmVkIDAgYWZ0
ZXIgMTAgdXNlY3MKWyAgICA0LjI1NjA1N10gY2FsbGluZyAgaW5pdF9zcisweDAvMHg0NiBAIDEK
WyAgICA0LjI1NjE2MV0gaW5pdGNhbGwgaW5pdF9zcisweDAvMHg0NiByZXR1cm5lZCAwIGFmdGVy
IDMgdXNlY3MKWyAgICA0LjI1NjI2NF0gY2FsbGluZyAgaW5pdF9zZysweDAvMHg2MyBAIDEKWyAg
ICA0LjI1NjM3M10gaW5pdGNhbGwgaW5pdF9zZysweDAvMHg2MyByZXR1cm5lZCAwIGFmdGVyIDkg
dXNlY3MKWyAgICA0LjI1NjQ3NV0gY2FsbGluZyAgYWhjaV9pbml0KzB4MC8weDFiIEAgMQpbICAg
IDQuMjU2NTgyXSBhaGNpIDAwMDA6MDA6MWYuMjogdmVyc2lvbiAzLjAKWyAgICA0LjI1NjY5N10g
eGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjI1
NjgwNV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkKWyAgICA0LjI1NjkzNF0g
YWhjaSAwMDAwOjAwOjFmLjI6IFBDSSBJTlQgQiAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElS
USAxOQpbICAgIDQuMjU3MTg1XSBhaGNpIDAwMDA6MDA6MWYuMjogY29udHJvbGxlciBjYW4ndCBk
byBTTlRGLCB0dXJuaW5nIG9mZiBDQVBfU05URgpbICAgIDQuMjczMTk0XSBhaGNpIDAwMDA6MDA6
MWYuMjogQUhDSSAwMDAxLjAzMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFJB
SUQgbW9kZQpbICAgIDQuMjczMzM5XSBhaGNpIDAwMDA6MDA6MWYuMjogZmxhZ3M6IDY0Yml0IG5j
cSBwbSBsZWQgY2xvIHBpbyBzbHVtIHBhcnQgZW1zIGFwc3QgClsgICAgNC4yNzM0NzNdIGFoY2kg
MDAwMDowMDoxZi4yOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjMxMzUzOF0g
c2NzaTAgOiBhaGNpClsgICAgNC4zMTM3MDRdIHNjc2kxIDogYWhjaQpbICAgIDQuMzEzODYwXSBz
Y3NpMiA6IGFoY2kKWyAgICA0LjMxNDAxN10gc2NzaTMgOiBhaGNpClsgICAgNC4zMTQxNzBdIHNj
c2k0IDogYWhjaQpbICAgIDQuMzE0MzI1XSBzY3NpNSA6IGFoY2kKWyAgICA0LjMxNDU1MF0gYXRh
MTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0OEAweGZiYjIxMDAwIHBvcnQgMHhmYmIyMTEw
MCBpcnEgMjg5ClsgICAgNC4zMTQ2NzhdIGF0YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIw
NDhAMHhmYmIyMTAwMCBwb3J0IDB4ZmJiMjExODAgaXJxIDI4OQpbICAgIDQuMzE0ODA1XSBhdGEz
OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4QDB4ZmJiMjEwMDAgcG9ydCAweGZiYjIxMjAw
IGlycSAyODkKWyAgICA0LjMxNDkzMl0gYXRhNDogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0
OEAweGZiYjIxMDAwIHBvcnQgMHhmYmIyMTI4MCBpcnEgMjg5ClsgICAgNC4zMTUwNTldIGF0YTU6
IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmYmIyMTAwMCBwb3J0IDB4ZmJiMjEzMDAg
aXJxIDI4OQpbICAgIDQuMzE1MTg4XSBhdGE2OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4
QDB4ZmJiMjEwMDAgcG9ydCAweGZiYjIxMzgwIGlycSAyODkKWyAgICA0LjMxNTMyNF0gY2FsbGlu
ZyAgMl9hc3luY19wb3J0X3Byb2JlKzB4MC8weDcwIEAgNQpbICAgIDQuMzE1MzI5XSBpbml0Y2Fs
bCBhaGNpX2luaXQrMHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRlciA1NzM3NiB1c2VjcwpbICAgIDQu
MzE1MzMxXSBjYWxsaW5nICBhZG1hX2F0YV9pbml0KzB4MC8weDFiIEAgMQpbICAgIDQuMzE1MzQy
XSBpbml0Y2FsbCBhZG1hX2F0YV9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgOCB1c2Vj
cwpbICAgIDQuMzE1MzQ0XSBjYWxsaW5nICBwaWl4X2luaXQrMHgwLzB4MjkgQCAxClsgICAgNC4z
MTUzNTRdIGluaXRjYWxsIHBpaXhfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVyIDggdXNl
Y3MKWyAgICA0LjMxNTM1Nl0gY2FsbGluZyAgc2lzX2luaXQrMHgwLzB4MWIgQCAxClsgICAgNC4z
MTUzNjVdIGluaXRjYWxsIHNpc19pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgNiB1c2Vj
cwpbICAgIDQuMzE1MzY2XSBjYWxsaW5nICBwYWNwaV9pbml0KzB4MC8weDFiIEAgMQpbICAgIDQu
MzE1Mzc2XSBpbml0Y2FsbCBwYWNwaV9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgNyB1
c2VjcwpbICAgIDQuMzE1Mzc4XSBjYWxsaW5nICBhdGFfZ2VuZXJpY19pbml0KzB4MC8weDFiIEAg
MQpbICAgIDQuMzE1Mzg4XSBpbml0Y2FsbCBhdGFfZ2VuZXJpY19pbml0KzB4MC8weDFiIHJldHVy
bmVkIDAgYWZ0ZXIgNyB1c2VjcwpbICAgIDQuMzE1MzkwXSBjYWxsaW5nICBuZXRfb2xkZGV2c19p
bml0KzB4MC8weDFjIEAgMQpbICAgIDQuMzE1Mzk0XSBpbml0Y2FsbCBuZXRfb2xkZGV2c19pbml0
KzB4MC8weDFjIHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDQuMzE1Mzk2XSBjYWxsaW5n
ICBtYXJ2ZWxsX2luaXQrMHgwLzB4NjQgQCAxClsgICAgNC4zMTU0MjddIGluaXRjYWxsIG1hcnZl
bGxfaW5pdCsweDAvMHg2NCByZXR1cm5lZCAwIGFmdGVyIDI4IHVzZWNzClsgICAgNC4zMTU0Mjld
IGNhbGxpbmcgIGRhdmljb21faW5pdCsweDAvMHg1ZSBAIDEKWyAgICA0LjMxNTQ0MV0gaW5pdGNh
bGwgZGF2aWNvbV9pbml0KzB4MC8weDVlIHJldHVybmVkIDAgYWZ0ZXIgMTAgdXNlY3MKWyAgICA0
LjMxNTQ0M10gY2FsbGluZyAgY2ljYWRhX2luaXQrMHgwLzB4M2MgQCAxClsgICAgNC4zMTU0NTNd
IGluaXRjYWxsIGNpY2FkYV9pbml0KzB4MC8weDNjIHJldHVybmVkIDAgYWZ0ZXIgNyB1c2Vjcwpb
ICAgIDQuMzE1NDU0XSBjYWxsaW5nICBseHRfaW5pdCsweDAvMHg1ZSBAIDEKWyAgICA0LjMxNTQ2
NV0gaW5pdGNhbGwgbHh0X2luaXQrMHgwLzB4NWUgcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNzClsg
ICAgNC4zMTU0NjddIGNhbGxpbmcgIHFzNjYxMl9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMzE1
NDcyXSBpbml0Y2FsbCBxczY2MTJfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDIgdXNl
Y3MKWyAgICA0LjMxNTQ3M10gY2FsbGluZyAgc21zY19pbml0KzB4MC8weGE2IEAgMQpbICAgIDQu
MzE1NDkzXSBpbml0Y2FsbCBzbXNjX2luaXQrMHgwLzB4YTYgcmV0dXJuZWQgMCBhZnRlciAxNyB1
c2VjcwpbICAgIDQuMzE1NDk1XSBjYWxsaW5nICB2c2M4Mnh4X2luaXQrMHgwLzB4M2MgQCAxClsg
ICAgNC4zMTU1MDNdIGluaXRjYWxsIHZzYzgyeHhfaW5pdCsweDAvMHgzYyByZXR1cm5lZCAwIGFm
dGVyIDYgdXNlY3MKWyAgICA0LjMxNTUwNV0gY2FsbGluZyAgYnJvYWRjb21faW5pdCsweDAvMHgx
OGUgQCAxClsgICAgNC4zMTU1NDZdIGluaXRjYWxsIGJyb2FkY29tX2luaXQrMHgwLzB4MThlIHJl
dHVybmVkIDAgYWZ0ZXIgMzggdXNlY3MKWyAgICA0LjMxNTU0OF0gY2FsbGluZyAgaWNwbHVzX2lu
aXQrMHgwLzB4M2YgQCAxClsgICAgNC4zMTU1NjFdIGluaXRjYWxsIGljcGx1c19pbml0KzB4MC8w
eDNmIHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MKWyAgICA0LjMxNTU2M10gY2FsbGluZyAgcmVh
bHRla19pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMzE1NTcwXSBpbml0Y2FsbCByZWFsdGVrX2lu
aXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzClsgICAgNC4zMTU1NzJdIGNhbGxp
bmcgIGV0MTAxMWNfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjMxNTU3N10gaW5pdGNhbGwgZXQx
MDExY19pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMzE1NTc5
XSBjYWxsaW5nICBmaXhlZF9tZGlvX2J1c19pbml0KzB4MC8weDEyNyBAIDEKWyAgICA0LjMxNTYw
Ml0gRml4ZWQgTURJTyBCdXM6IHByb2JlZApbICAgIDQuMzE1NjA0XSBpbml0Y2FsbCBmaXhlZF9t
ZGlvX2J1c19pbml0KzB4MC8weDEyNyByZXR1cm5lZCAwIGFmdGVyIDIyIHVzZWNzClsgICAgNC4z
MTU2MDZdIGNhbGxpbmcgIG5zX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4zMTU2MTJdIGluaXRj
YWxsIG5zX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzClsgICAgNC4zMTU2
MTNdIGNhbGxpbmcgIHN0ZTEwWHBfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjMxNTYyNV0gaW5p
dGNhbGwgc3RlMTBYcF9pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0ZXIgOSB1c2VjcwpbICAg
IDQuMzE1NjI3XSBjYWxsaW5nICB0dW5faW5pdCsweDAvMHg5MCBAIDEKWyAgICA0LjMxNTYyOF0g
dHVuOiBVbml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgICA0LjMxNTYyOV0g
dHVuOiAoQykgMTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29tbS5jb20+Clsg
ICAgNC4zMTU2NThdIGluaXRjYWxsIHR1bl9pbml0KzB4MC8weDkwIHJldHVybmVkIDAgYWZ0ZXIg
MjggdXNlY3MKWyAgICA0LjMxNTY2MF0gY2FsbGluZyAgaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0
LjMxNTY2NV0gaW5pdGNhbGwgaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MK
WyAgICA0LjMxNTY2N10gY2FsbGluZyAgcHBwX2luaXQrMHgwLzB4ZTEgQCAxClsgICAgNC4zMTU2
NjhdIFBQUCBnZW5lcmljIGRyaXZlciB2ZXJzaW9uIDIuNC4yClsgICAgNC4zMTU2OTVdIGluaXRj
YWxsIHBwcF9pbml0KzB4MC8weGUxIHJldHVybmVkIDAgYWZ0ZXIgMjUgdXNlY3MKWyAgICA0LjMx
NTY5N10gY2FsbGluZyAgbmV0aWZfaW5pdCsweDAvMHg2NiBAIDEKWyAgICA0LjMxNTY5OV0gaW5p
dGNhbGwgbmV0aWZfaW5pdCsweDAvMHg2NiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0
LjMxNTcwMV0gY2FsbGluZyAgY2Ryb21faW5pdCsweDAvMHgxNiBAIDEKWyAgICA0LjMxNTcxM10g
aW5pdGNhbGwgY2Ryb21faW5pdCsweDAvMHgxNiByZXR1cm5lZCAwIGFmdGVyIDkgdXNlY3MKWyAg
ICA0LjMxNTcxNV0gY2FsbGluZyAgbW9uX2luaXQrMHgwLzB4MTAwIEAgMQpbICAgIDQuMzE1NzQx
XSBpbml0Y2FsbCBtb25faW5pdCsweDAvMHgxMDAgcmV0dXJuZWQgMCBhZnRlciAyMyB1c2Vjcwpb
ICAgIDQuMzE1NzQ0XSBjYWxsaW5nICBlaGNpX2hjZF9pbml0KzB4MC8weDFkIEAgMQpbICAgIDQu
MzE1NzQ1XSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhD
SSkgRHJpdmVyClsgICAgNC4zMTU3NjFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAgNC4zMTU3NjNdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmlu
ZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuMzE1NzY0XSB4ZW46IC0tPiBwaXJxPTE2IC0+IGly
cT0xNiAoZ3NpPTE2KQpbICAgIDQuMzE1NzY1XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2Clsg
ICAgNC4zMTU3NjddIGVoY2lfaGNkIDAwMDA6MDA6MWEuMDogUENJIElOVCBBIC0+IEdTSSAxNiAo
bGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgNC4zMTU3ODddIGVoY2lfaGNkIDAwMDA6MDA6MWEu
MDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4zMTU3OTJdIGVoY2lfaGNkIDAw
MDA6MDA6MWEuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA0LjMxNTgyMV0gZWhjaV9oY2Qg
MDAwMDowMDoxYS4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVy
IDEKWyAgICA0LjMxNTg3OF0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBkZWJ1ZyBwb3J0IDIKWyAg
ICA0LjMxOTc4OF0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBjYWNoZSBsaW5lIHNpemUgb2YgNjQg
aXMgbm90IHN1cHBvcnRlZApbICAgIDQuMzE5ODYxXSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IGly
cSAxNiwgaW8gbWVtIDB4ZmJiMjMwMDAKWyAgICA0LjMyMDIwNF0gY2FsbGluZyAgM19hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgMTYKWyAgICA0LjMyMDMwM10gY2FsbGluZyAgNF9hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNDkKWyAgICA0LjMyMDM4OV0gY2FsbGluZyAgNV9hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNTAKWyAgICA0LjMyMDQ4OF0gY2FsbGluZyAgNl9hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNTEKWyAgICA0LjMyMDU4NF0gY2FsbGluZyAgN19hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNTIKWyAgICA0LjMzMzE0NV0gZWhjaV9oY2QgMDAwMDowMDox
YS4wOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMApbICAgIDQuMzMzMzgwXSBodWIgMS0wOjEu
MDogVVNCIGh1YiBmb3VuZApbICAgIDQuMzMzNDgyXSBodWIgMS0wOjEuMDogMiBwb3J0cyBkZXRl
Y3RlZApbICAgIDQuMzMzNjQyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQpbICAgIDQuMzMzNzQ1XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx
IDIzIGZvciBnc2kgMjMKWyAgICA0LjMzMzg0OF0geGVuOiAtLT4gcGlycT0yMyAtPiBpcnE9MjMg
KGdzaT0yMykKWyAgICA0LjMzMzk0N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMwpbICAgIDQu
MzM0MDQ3XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IFBDSSBJTlQgQSAtPiBHU0kgMjMgKGxldmVs
LCBsb3cpIC0+IElSUSAyMwpbICAgIDQuMzM0MTc0XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IHNl
dHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMzM0MjgwXSBlaGNpX2hjZCAwMDAwOjAw
OjFkLjA6IEVIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgNC4zMzQ0MThdIGVoY2lfaGNkIDAwMDA6
MDA6MWQuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyClsg
ICAgNC4zMzQ1OTVdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogZGVidWcgcG9ydCAyClsgICAgNC4z
Mzg1ODZdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogY2FjaGUgbGluZSBzaXplIG9mIDY0IGlzIG5v
dCBzdXBwb3J0ZWQKWyAgICA0LjMzODc1MV0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBpcnEgMjMs
IGlvIG1lbSAweGZiYjIyMDAwClsgICAgNC4zNTMxNDhdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDog
VVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKWyAgICA0LjM1MzM2MV0gaHViIDItMDoxLjA6IFVT
QiBodWIgZm91bmQKWyAgICA0LjM1MzQ2MV0gaHViIDItMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQK
WyAgICA0LjM1NTMxNF0gaW5pdGNhbGwgZWhjaV9oY2RfaW5pdCsweDAvMHgxZCByZXR1cm5lZCAw
IGFmdGVyIDM4NjQwIHVzZWNzClsgICAgNC4zNTU0MjBdIGNhbGxpbmcgIG9oY2lfaGNkX21vZF9p
bml0KzB4MC8weDU0IEAgMQpbICAgIDQuMzU1NTIxXSBvaGNpX2hjZDogVVNCIDEuMSAnT3Blbicg
SG9zdCBDb250cm9sbGVyIChPSENJKSBEcml2ZXIKWyAgICA0LjM1NTYzM10gaW5pdGNhbGwgb2hj
aV9oY2RfbW9kX2luaXQrMHgwLzB4NTQgcmV0dXJuZWQgMCBhZnRlciAxMDggdXNlY3MKWyAgICA0
LjM1NTczOV0gY2FsbGluZyAgdWhjaV9oY2RfaW5pdCsweDAvMHgxZCBAIDEKWyAgICA0LjM1NTgz
OV0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250cm9sbGVyIEludGVyZmFjZSBkcml2
ZXIKWyAgICA0LjM1NTk1M10gaW5pdGNhbGwgdWhjaV9oY2RfaW5pdCsweDAvMHgxZCByZXR1cm5l
ZCAwIGFmdGVyIDExMCB1c2VjcwpbICAgIDQuMzU2MDU4XSBjYWxsaW5nICB4aGNpX2hjZF9pbml0
KzB4MC8weDI5IEAgMQpbICAgIDQuMzU2MTY4XSBpbml0Y2FsbCB4aGNpX2hjZF9pbml0KzB4MC8w
eDI5IHJldHVybmVkIDAgYWZ0ZXIgOCB1c2VjcwpbICAgIDQuMzU2MjcyXSBjYWxsaW5nICB1c2Jf
dXN1YWxfaW5pdCsweDAvMHgzYiBAIDEKWyAgICA0LjM1NjM4NF0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBsaWJ1c3VhbApbICAgIDQuMzU2NDg3XSBpbml0Y2FsbCB1
c2JfdXN1YWxfaW5pdCsweDAvMHgzYiByZXR1cm5lZCAwIGFmdGVyIDEwOSB1c2VjcwpbICAgIDQu
MzU2NTkzXSBjYWxsaW5nICBpODA0Ml9pbml0KzB4MC8weDgwIEAgMQpbICAgIDQuMzU2NzE2XSBp
ODA0MjogUE5QOiBQUy8yIENvbnRyb2xsZXIgW1BOUDAzMDM6UFMySyxQTlAwZjAzOlBTMk1dIGF0
IDB4NjAsMHg2NCBpcnEgMSwxMgpbICAgIDQuMzYwMTI3XSBzZXJpbzogaTgwNDIgS0JEIHBvcnQg
YXQgMHg2MCwweDY0IGlycSAxClsgICAgNC4zNjAyMjldIHNlcmlvOiBpODA0MiBBVVggcG9ydCBh
dCAweDYwLDB4NjQgaXJxIDEyClsgICAgNC4zNjAzNzFdIGluaXRjYWxsIGk4MDQyX2luaXQrMHgw
LzB4ODAgcmV0dXJuZWQgMCBhZnRlciAzNTkyIHVzZWNzClsgICAgNC4zNjA0NzddIGNhbGxpbmcg
IG1vdXNlZGV2X2luaXQrMHgwLzB4OGEgQCAxClsgICAgNC4zNjA2MzRdIG1vdXNlZGV2OiBQUy8y
IG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlClsgICAgNC4zNjA3MzldIGluaXRjYWxs
IG1vdXNlZGV2X2luaXQrMHgwLzB4OGEgcmV0dXJuZWQgMCBhZnRlciAxNjAgdXNlY3MKWyAgICA0
LjM2MDg0NF0gY2FsbGluZyAgZXZkZXZfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjM2MDk5OF0g
aW5pdGNhbGwgZXZkZXZfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDUwIHVzZWNzClsg
ICAgNC4zNjExMDBdIGNhbGxpbmcgIGF0a2JkX2luaXQrMHgwLzB4MjcgQCAxClsgICAgNC4zNjEy
MTZdIGluaXRjYWxsIGF0a2JkX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRlciAxNCB1c2Vj
cwpbICAgIDQuMzYxMzE5XSBjYWxsaW5nICB1aW5wdXRfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0
LjM2MTQ2NV0gaW5pdGNhbGwgdWlucHV0X2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA0
MiB1c2VjcwpbICAgIDQuMzYxNTcwXSBjYWxsaW5nICBjbW9zX2luaXQrMHgwLzB4NmEgQCAxClsg
ICAgNC4zNjE3MDVdIHJ0Y19jbW9zIDAwOjAzOiBSVEMgY2FuIHdha2UgZnJvbSBTNApbICAgIDQu
MzYyMDA5XSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJlZ2lzdGVyZWQgcnRjX2Ntb3MgYXMg
cnRjMApbICAgIDQuMzYyMjA5XSBydGMwOiBhbGFybXMgdXAgdG8gb25lIG1vbnRoLCB5M2ssIDEx
NCBieXRlcyBudnJhbQpbICAgIDQuMzYyMzE4XSBpbml0Y2FsbCBjbW9zX2luaXQrMHgwLzB4NmEg
cmV0dXJuZWQgMCBhZnRlciA2MzIgdXNlY3MKWyAgICA0LjM2MjQyMV0gY2FsbGluZyAgZG1faW5p
dCsweDAvMHg0NSBAIDEKWyAgICA0LjM2MjU2Nl0gZGV2aWNlLW1hcHBlcjogdWV2ZW50OiB2ZXJz
aW9uIDEuMC4zClsgICAgNC4zNjI3MTRdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIyLjAtaW9j
dGwgKDIwMTEtMTAtMTkpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsgICAgNC4z
NjI4NDFdIGluaXRjYWxsIGRtX2luaXQrMHgwLzB4NDUgcmV0dXJuZWQgMCBhZnRlciAzMTIgdXNl
Y3MKWyAgICA0LjM2Mjk0NV0gY2FsbGluZyAgY3B1ZnJlcV9zdGF0c19pbml0KzB4MC8weDljIEAg
MQpbICAgIDQuMzYzMDQ2XSBpbml0Y2FsbCBjcHVmcmVxX3N0YXRzX2luaXQrMHgwLzB4OWMgcmV0
dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4zNjMxNTNdIGNhbGxpbmcgIGNwdWZyZXFfZ292
X3Bvd2Vyc2F2ZV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMzYzMjU3XSBpbml0Y2FsbCBjcHVm
cmVxX2dvdl9wb3dlcnNhdmVfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM2MzM4Ml0gY2FsbGluZyAgY3B1ZnJlcV9nb3ZfdXNlcnNwYWNlX2luaXQrMHgwLzB4
MTIgQCAxClsgICAgNC4zNjM0ODRdIGluaXRjYWxsIGNwdWZyZXFfZ292X3VzZXJzcGFjZV9pbml0
KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzYzNjA5XSBjYWxsaW5n
ICBjcHVmcmVxX2dvdl9kYnNfaW5pdCsweDAvMHg1ZSBAIDEKWyAgICA0LjM2MzcxMl0gaW5pdGNh
bGwgY3B1ZnJlcV9nb3ZfZGJzX2luaXQrMHgwLzB4NWUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgNC4zNjM4MTddIGNhbGxpbmcgIGNwdWZyZXFfZ292X2Ric19pbml0KzB4MC8weDEyIEAg
MQpbICAgIDQuMzYzOTIwXSBpbml0Y2FsbCBjcHVmcmVxX2dvdl9kYnNfaW5pdCsweDAvMHgxMiBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM2NDAyNl0gY2FsbGluZyAgaW5pdF9sYWRk
ZXIrMHgwLzB4MTIgQCAxClsgICAgNC4zNjQxMjhdIGluaXRjYWxsIGluaXRfbGFkZGVyKzB4MC8w
eDEyIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgNC4zNjQyMzJdIGNhbGxpbmcgIGlu
aXRfbWVudSsweDAvMHgxMiBAIDEKWyAgICA0LjM2NDMzNF0gaW5pdGNhbGwgaW5pdF9tZW51KzB4
MC8weDEyIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgNC4zNjQ0MzZdIGNhbGxpbmcg
IGVmaXZhcnNfaW5pdCsweDAvMHhmNCBAIDEKWyAgICA0LjM2NDUzNl0gRUZJIFZhcmlhYmxlcyBG
YWNpbGl0eSB2MC4wOCAyMDA0LU1heS0xNwpbICAgIDQuMzY0NjM5XSBpbml0Y2FsbCBlZml2YXJz
X2luaXQrMHgwLzB4ZjQgcmV0dXJuZWQgMCBhZnRlciAxMDAgdXNlY3MKWyAgICA0LjM2NDc0NF0g
Y2FsbGluZyAgc3RhZ2luZ19pbml0KzB4MC8weDggQCAxClsgICAgNC4zNjQ4NDVdIGluaXRjYWxs
IHN0YWdpbmdfaW5pdCsweDAvMHg4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY0
OTUxXSBjYWxsaW5nICBmbG93X2NhY2hlX2luaXRfZ2xvYmFsKzB4MC8weDJkIEAgMQpbICAgIDQu
MzY1MDc2XSBpbml0Y2FsbCBmbG93X2NhY2hlX2luaXRfZ2xvYmFsKzB4MC8weDJkIHJldHVybmVk
IDAgYWZ0ZXIgMjMgdXNlY3MKWyAgICA0LjM2NTIwMF0gY2FsbGluZyAgbGxjX2luaXQrMHgwLzB4
MjAgQCAxClsgICAgNC4zNjUzMDBdIGluaXRjYWxsIGxsY19pbml0KzB4MC8weDIwIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY1NDAzXSBjYWxsaW5nICBzbmFwX2luaXQrMHgwLzB4
MzkgQCAxClsgICAgNC4zNjU1MDRdIGluaXRjYWxsIHNuYXBfaW5pdCsweDAvMHgzOSByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM2NTYwNV0gY2FsbGluZyAgcmlmX2luaXQrMHgwLzB4
ODQgQCAxClsgICAgNC4zNjU3MTFdIGluaXRjYWxsIHJpZl9pbml0KzB4MC8weDg0IHJldHVybmVk
IDAgYWZ0ZXIgNSB1c2VjcwpbICAgIDQuMzY1ODE1XSBjYWxsaW5nICBibGFja2hvbGVfbW9kdWxl
X2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4zNjU5MTddIGluaXRjYWxsIGJsYWNraG9sZV9tb2R1
bGVfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM2NjAyM10g
Y2FsbGluZyAgc3lzY3RsX2lwdjRfaW5pdCsweDAvMHg4NCBAIDEKWyAgICA0LjM2NjI0N10gaW5p
dGNhbGwgc3lzY3RsX2lwdjRfaW5pdCsweDAvMHg4NCByZXR1cm5lZCAwIGFmdGVyIDExOCB1c2Vj
cwpbICAgIDQuMzY2MzUyXSBjYWxsaW5nICBpbml0X3N5bmNvb2tpZXMrMHgwLzB4MTkgQCAxClsg
ICAgNC4zNjY0NjZdIGluaXRjYWxsIGluaXRfc3luY29va2llcysweDAvMHgxOSByZXR1cm5lZCAw
IGFmdGVyIDExIHVzZWNzClsgICAgNC4zNjY1NzNdIGNhbGxpbmcgIGlwdjRfbmV0ZmlsdGVyX2lu
aXQrMHgwLzB4MjAgQCAxClsgICAgNC4zNjY2NzVdIGluaXRjYWxsIGlwdjRfbmV0ZmlsdGVyX2lu
aXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNjY3ODBdIGNhbGxp
bmcgIGN1YmljdGNwX3JlZ2lzdGVyKzB4MC8weDZhIEAgMQpbICAgIDQuMzY2ODgyXSBUQ1AgY3Vi
aWMgcmVnaXN0ZXJlZApbICAgIDQuMzY2OTgxXSBpbml0Y2FsbCBjdWJpY3RjcF9yZWdpc3Rlcisw
eDAvMHg2YSByZXR1cm5lZCAwIGFmdGVyIDk2IHVzZWNzClsgICAgNC4zNjcwODZdIGNhbGxpbmcg
IGluZXQ2X2luaXQrMHgwLzB4NTcgQCAxClsgICAgNC4zNjcyNTldIE5FVDogUmVnaXN0ZXJlZCBw
cm90b2NvbCBmYW1pbHkgMTAKWyAgICA0LjM2NzcxN10gaW5pdGNhbGwgaW5ldDZfaW5pdCsweDAv
MHg1NyByZXR1cm5lZCAwIGFmdGVyIDUxOCB1c2VjcwpbICAgIDQuMzY3ODIyXSBjYWxsaW5nICBw
YWNrZXRfaW5pdCsweDAvMHg0NiBAIDEKWyAgICA0LjM2NzkyMV0gTkVUOiBSZWdpc3RlcmVkIHBy
b3RvY29sIGZhbWlseSAxNwpbICAgIDQuMzY4MDIzXSBpbml0Y2FsbCBwYWNrZXRfaW5pdCsweDAv
MHg0NiByZXR1cm5lZCAwIGFmdGVyIDk5IHVzZWNzClsgICAgNC4zNjgxMjddIGNhbGxpbmcgIGRz
YV9pbml0X21vZHVsZSsweDAvMHgxNCBAIDEKWyAgICA0LjM2ODIyOV0gaW5pdGNhbGwgZHNhX2lu
aXRfbW9kdWxlKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY4MzMx
XSBjYWxsaW5nICBlZHNhX2luaXRfbW9kdWxlKzB4MC8weDE0IEAgMQpbICAgIDQuMzY4NDMyXSBp
bml0Y2FsbCBlZHNhX2luaXRfbW9kdWxlKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDQuMzY4NTM1XSBjYWxsaW5nICB0cmFpbGVyX2luaXRfbW9kdWxlKzB4MC8weDE0IEAg
MQpbICAgIDQuMzY4NjM2XSBpbml0Y2FsbCB0cmFpbGVyX2luaXRfbW9kdWxlKzB4MC8weDE0IHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY4NzQxXSBjYWxsaW5nICBtdjg4ZTYwNjBf
aW5pdCsweDAvMHgxNCBAIDEKWyAgICA0LjM2ODg0M10gaW5pdGNhbGwgbXY4OGU2MDYwX2luaXQr
MHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNjg5NDZdIGNhbGxpbmcg
IG12ODhlNjEyM182MV82NV9pbml0KzB4MC8weDE0IEAgMQpbICAgIDQuMzY5MDQ4XSBpbml0Y2Fs
bCBtdjg4ZTYxMjNfNjFfNjVfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM2OTE1NF0gY2FsbGluZyAgbXY4OGU2MTMxX2luaXQrMHgwLzB4MTQgQCAxClsgICAg
NC4zNjkyNTVdIGluaXRjYWxsIG12ODhlNjEzMV9pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDQuMzY5MzU5XSBjYWxsaW5nICBkc2FfaW5pdF9tb2R1bGUrMHgwLzB4
MTIgQCAxClsgICAgNC4zNjk0NzVdIGluaXRjYWxsIGRzYV9pbml0X21vZHVsZSsweDAvMHgxMiBy
ZXR1cm5lZCAwIGFmdGVyIDEzIHVzZWNzClsgICAgNC4zNjk1NzldIGNhbGxpbmcgIGRjYm5sX2lu
aXQrMHgwLzB4NGQgQCAxClsgICAgNC4zNjk2ODBdIGluaXRjYWxsIGRjYm5sX2luaXQrMHgwLzB4
NGQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNjk3ODRdIGNhbGxpbmcgIGluaXRf
ZG5zX3Jlc29sdmVyKzB4MC8weGZlIEAgMQpbICAgIDQuMzY5ODg0XSBSZWdpc3RlcmluZyB0aGUg
ZG5zX3Jlc29sdmVyIGtleSB0eXBlClsgICAgNC4zNjk5OTFdIGluaXRjYWxsIGluaXRfZG5zX3Jl
c29sdmVyKzB4MC8weGZlIHJldHVybmVkIDAgYWZ0ZXIgMTAzIHVzZWNzClsgICAgNC4zNzAwOTdd
IGNhbGxpbmcgIHJpb19pbml0X21wb3J0cysweDAvMHg1YyBAIDEKWyAgICA0LjM3MDIwMF0gaW5p
dGNhbGwgcmlvX2luaXRfbXBvcnRzKzB4MC8weDVjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcwpb
ICAgIDQuMzcwMzA2XSBjYWxsaW5nICB0Ym9vdF9sYXRlX2luaXQrMHgwLzB4YzIgQCAxClsgICAg
NC4zNzA0MDhdIGluaXRjYWxsIHRib290X2xhdGVfaW5pdCsweDAvMHhjMiByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICA0LjM3MDUxM10gY2FsbGluZyAgbWNoZWNrX2RlYnVnZnNfaW5pdCsw
eDAvMHgzYiBAIDEKWyAgICA0LjM3MDYyMF0gaW5pdGNhbGwgbWNoZWNrX2RlYnVnZnNfaW5pdCsw
eDAvMHgzYiByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICA0LjM3MDcyNV0gY2FsbGluZyAg
c2V2ZXJpdGllc19kZWJ1Z2ZzX2luaXQrMHgwLzB4M2IgQCAxClsgICAgNC4zNzA4MzJdIGluaXRj
YWxsIHNldmVyaXRpZXNfZGVidWdmc19pbml0KzB4MC8weDNiIHJldHVybmVkIDAgYWZ0ZXIgMyB1
c2VjcwpbICAgIDQuMzcwOTU1XSBjYWxsaW5nICBocGV0X2luc2VydF9yZXNvdXJjZSsweDAvMHgy
MyBAIDEKWyAgICA0LjM3MTA1OF0gaW5pdGNhbGwgaHBldF9pbnNlcnRfcmVzb3VyY2UrMHgwLzB4
MjMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzExNjRdIGNhbGxpbmcgIHVwZGF0
ZV9tcF90YWJsZSsweDAvMHgxNiBAIDEKWyAgICA0LjM3MTI2NV0gaW5pdGNhbGwgdXBkYXRlX21w
X3RhYmxlKzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzcxMzcwXSBj
YWxsaW5nICBsYXBpY19pbnNlcnRfcmVzb3VyY2UrMHgwLzB4M2YgQCAxClsgICAgNC4zNzE0NzJd
IGluaXRjYWxsIGxhcGljX2luc2VydF9yZXNvdXJjZSsweDAvMHgzZiByZXR1cm5lZCAtMSBhZnRl
ciAwIHVzZWNzClsgICAgNC4zNzE1NzhdIGluaXRjYWxsIGxhcGljX2luc2VydF9yZXNvdXJjZSsw
eDAvMHgzZiByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTEgClsgICAgNC4zNzE3MDFdIGNhbGxp
bmcgIGlvX2FwaWNfYnVnX2ZpbmFsaXplKzB4MC8weDFiIEAgMQpbICAgIDQuMzcxODAyXSBpbml0
Y2FsbCBpb19hcGljX2J1Z19maW5hbGl6ZSsweDAvMHgxYiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA0LjM3MTkwN10gY2FsbGluZyAgcHJpbnRfSUNzKzB4MC8weDk0IEAgMQpbICAgIDQu
MzcyMDA5XSBpbml0Y2FsbCBwcmludF9JQ3MrMHgwLzB4OTQgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgNC4zNzIxMTRdIGNhbGxpbmcgIGNoZWNrX2Vhcmx5X2lvcmVtYXBfbGVhaysweDAv
MHg1MCBAIDEKWyAgICA0LjM3MjIxN10gaW5pdGNhbGwgY2hlY2tfZWFybHlfaW9yZW1hcF9sZWFr
KzB4MC8weDUwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzcyMzQxXSBjYWxsaW5n
ICBwYXRfbWVtdHlwZV9saXN0X2luaXQrMHgwLzB4MzIgQCAxClsgICAgNC4zNzI0NDZdIGluaXRj
YWxsIHBhdF9tZW10eXBlX2xpc3RfaW5pdCsweDAvMHgzMiByZXR1cm5lZCAwIGFmdGVyIDEgdXNl
Y3MKWyAgICA0LjM3MjU1Ml0gY2FsbGluZyAgc2NoZWRfaW5pdF9kZWJ1ZysweDAvMHgyNCBAIDEK
WyAgICA0LjM3MjY1NF0gaW5pdGNhbGwgc2NoZWRfaW5pdF9kZWJ1ZysweDAvMHgyNCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM3Mjc2MF0gY2FsbGluZyAgaW5pdF9vb3BzX2lkKzB4
MC8weDQwIEAgMQpbICAgIDQuMzcyODYwXSBpbml0Y2FsbCBpbml0X29vcHNfaWQrMHgwLzB4NDAg
cmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4zNzI5NjVdIGNhbGxpbmcgIHByaW50a19s
YXRlX2luaXQrMHgwLzB4NTYgQCAxClsgICAgNC4zNzMwNjldIGluaXRjYWxsIHByaW50a19sYXRl
X2luaXQrMHgwLzB4NTYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzMxNzVdIGNh
bGxpbmcgIHBtX2RlYnVnZnNfaW5pdCsweDAvMHgyNCBAIDEKWyAgICA0LjM3MzI3OF0gaW5pdGNh
bGwgcG1fZGVidWdmc19pbml0KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAg
IDQuMzczMzgyXSBjYWxsaW5nICBwbV9xb3NfcG93ZXJfaW5pdCsweDAvMHhkYyBAIDEKWyAgICA0
LjM3MzU4MF0gaW5pdGNhbGwgcG1fcW9zX3Bvd2VyX2luaXQrMHgwLzB4ZGMgcmV0dXJuZWQgMCBh
ZnRlciA5NCB1c2VjcwpbICAgIDQuMzczNjg1XSBjYWxsaW5nICB0ZXN0X3N1c3BlbmQrMHgwLzB4
YTEgQCAxClsgICAgNC4zNzM3ODZdIGluaXRjYWxsIHRlc3Rfc3VzcGVuZCsweDAvMHhhMSByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM3Mzg5MF0gY2FsbGluZyAgc29mdHdhcmVfcmVz
dW1lKzB4MC8weDMwIEAgMQpbICAgIDQuMzczOTkxXSBQTTogSGliZXJuYXRpb24gaW1hZ2Ugbm90
IHByZXNlbnQgb3IgY291bGQgbm90IGJlIGxvYWRlZC4KWyAgICA0LjM3NDA5Nl0gaW5pdGNhbGwg
c29mdHdhcmVfcmVzdW1lKzB4MC8weDMwIHJldHVybmVkIC0yIGFmdGVyIDEwMSB1c2VjcwpbICAg
IDQuMzc0MjAxXSBpbml0Y2FsbCBzb2Z0d2FyZV9yZXN1bWUrMHgwLzB4MzAgcmV0dXJuZWQgd2l0
aCBlcnJvciBjb2RlIC0yIApbICAgIDQuMzc0MzA4XSBjYWxsaW5nICBkZWJ1Z2ZzX2twcm9iZV9p
bml0KzB4MC8weGEwIEAgMQpbICAgIDQuMzc0NDE0XSBpbml0Y2FsbCBkZWJ1Z2ZzX2twcm9iZV9p
bml0KzB4MC8weGEwIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMzc0NTIxXSBjYWxs
aW5nICB0YXNrc3RhdHNfaW5pdCsweDAvMHg5NSBAIDEKWyAgICA0LjM3NDYyNV0gcmVnaXN0ZXJl
ZCB0YXNrc3RhdHMgdmVyc2lvbiAxClsgICAgNC4zNzQ3MjhdIGluaXRjYWxsIHRhc2tzdGF0c19p
bml0KzB4MC8weDk1IHJldHVybmVkIDAgYWZ0ZXIgMTAxIHVzZWNzClsgICAgNC4zNzQ4MzRdIGNh
bGxpbmcgIGNsZWFyX2Jvb3RfdHJhY2VyKzB4MC8weDJkIEAgMQpbICAgIDQuMzc0OTM2XSBpbml0
Y2FsbCBjbGVhcl9ib290X3RyYWNlcisweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM3NTA0MV0gY2FsbGluZyAga2RiX2Z0cmFjZV9yZWdpc3RlcisweDAvMHgyZiBAIDEK
WyAgICA0LjM3NTE0Nl0gaW5pdGNhbGwga2RiX2Z0cmFjZV9yZWdpc3RlcisweDAvMHgyZiByZXR1
cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjM3NTI1Ml0gY2FsbGluZyAgbWF4X3N3YXBmaWxl
c19jaGVjaysweDAvMHg4IEAgMQpbICAgIDQuMzc1MzU0XSBpbml0Y2FsbCBtYXhfc3dhcGZpbGVz
X2NoZWNrKzB4MC8weDggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzU0NjBdIGNh
bGxpbmcgIHNldF9yZWNvbW1lbmRlZF9taW5fZnJlZV9rYnl0ZXMrMHgwLzB4YTAgQCAxClsgICAg
NC4zNzU1NjNdIGluaXRjYWxsIHNldF9yZWNvbW1lbmRlZF9taW5fZnJlZV9rYnl0ZXMrMHgwLzB4
YTAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzU2ODhdIGNhbGxpbmcgIGluaXRf
dHJ1c3RlZCsweDAvMHhiYiBAIDEKWyAgICA0LjM3NTc5MV0gYXN5bmNfd2FpdGluZyBAIDEKWyAg
ICA0LjM3NTg4OF0gYXN5bmNfY29udGludWluZyBAIDEgYWZ0ZXIgMCB1c2VjClsgICAgNC4zNzcz
MjldIGFzeW5jX3dhaXRpbmcgQCAxClsgICAgNC4zNzc0MzBdIGFzeW5jX2NvbnRpbnVpbmcgQCAx
IGFmdGVyIDAgdXNlYwpbICAgIDQuMzc4NzQ0XSBpbml0Y2FsbCBpbml0X3RydXN0ZWQrMHgwLzB4
YmIgcmV0dXJuZWQgMCBhZnRlciAyODgxIHVzZWNzClsgICAgNC4zNzg4NDldIGNhbGxpbmcgIGlu
aXRfZW5jcnlwdGVkKzB4MC8weDExZiBAIDEKWyAgICA0LjM3ODk1MV0gYXN5bmNfd2FpdGluZyBA
IDEKWyAgICA0LjM3OTA0OV0gYXN5bmNfY29udGludWluZyBAIDEgYWZ0ZXIgMCB1c2VjClsgICAg
NC4zODAzMjhdIGFzeW5jX3dhaXRpbmcgQCAxClsgICAgNC4zODA0MjldIGFzeW5jX2NvbnRpbnVp
bmcgQCAxIGFmdGVyIDAgdXNlYwpbICAgIDQuMzgxNzUwXSBhc3luY193YWl0aW5nIEAgMQpbICAg
IDQuMzgxODQ5XSBhc3luY19jb250aW51aW5nIEAgMSBhZnRlciAwIHVzZWMKWyAgICA0LjM4MzEw
NF0gYXN5bmNfd2FpdGluZyBAIDEKWyAgICA0LjM4MzIwM10gYXN5bmNfY29udGludWluZyBAIDEg
YWZ0ZXIgMCB1c2VjClsgICAgNC4zODQ1MzVdIGluaXRjYWxsIGluaXRfZW5jcnlwdGVkKzB4MC8w
eDExZiByZXR1cm5lZCAwIGFmdGVyIDU0NTEgdXNlY3MKWyAgICA0LjM4NDY0Ml0gY2FsbGluZyAg
aW5pdF9ldm0rMHgwLzB4MjUgQCAxClsgICAgNC4zODQ3NDhdIGluaXRjYWxsIGluaXRfZXZtKzB4
MC8weDI1IHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMzg0ODUyXSBjYWxsaW5nICBy
YW5kb20zMl9yZXNlZWQrMHgwLzB4YTIgQCAxClsgICAgNC4zODQ5NTVdIGluaXRjYWxsIHJhbmRv
bTMyX3Jlc2VlZCsweDAvMHhhMiByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA0LjM4NTA2
MF0gY2FsbGluZyAgcGNpX3Jlc291cmNlX2FsaWdubWVudF9zeXNmc19pbml0KzB4MC8weDE5IEAg
MQpbICAgIDQuMzg2ODYzXSBpbml0Y2FsbCBwY2lfcmVzb3VyY2VfYWxpZ25tZW50X3N5c2ZzX2lu
aXQrMHgwLzB4MTkgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4zODY5ODldIGNhbGxp
bmcgIHBjaV9zeXNmc19pbml0KzB4MC8weDUxIEAgMQpbICAgIDQuMzg3NjUzXSBpbml0Y2FsbCBw
Y2lfc3lzZnNfaW5pdCsweDAvMHg1MSByZXR1cm5lZCAwIGFmdGVyIDU0OCB1c2VjcwpbICAgIDQu
Mzg3NzU1XSBjYWxsaW5nICBib290X3dhaXRfZm9yX2RldmljZXMrMHgwLzB4MzAgQCAxClsgICAg
NC4zODc4NThdIGluaXRjYWxsIGJvb3Rfd2FpdF9mb3JfZGV2aWNlcysweDAvMHgzMCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM4Nzk2M10gY2FsbGluZyAgcmVndWxhdG9yX2luaXRf
Y29tcGxldGUrMHgwLzB4MTM5IEAgMQpbICAgIDQuMzg4MDY3XSBpbml0Y2FsbCByZWd1bGF0b3Jf
aW5pdF9jb21wbGV0ZSsweDAvMHgxMzkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4z
ODgxOTJdIGNhbGxpbmcgIHJhbmRvbV9pbnRfc2VjcmV0X2luaXQrMHgwLzB4MTkgQCAxClsgICAg
NC4zODgzMDFdIGluaXRjYWxsIHJhbmRvbV9pbnRfc2VjcmV0X2luaXQrMHgwLzB4MTkgcmV0dXJu
ZWQgMCBhZnRlciA2IHVzZWNzClsgICAgNC4zODg0MDZdIGNhbGxpbmcgIGxhdGVfcmVzdW1lX2lu
aXQrMHgwLzB4MWIwIEAgMQpbICAgIDQuMzg4NTA1XSAgIE1hZ2ljIG51bWJlcjogODo2NDg6NDkz
ClsgICAgNC4zODg2MjVdIGluaXRjYWxsIGxhdGVfcmVzdW1lX2luaXQrMHgwLzB4MWIwIHJldHVy
bmVkIDAgYWZ0ZXIgMTE2IHVzZWNzClsgICAgNC4zODg3MjhdIGNhbGxpbmcgIHNjc2lfY29tcGxl
dGVfYXN5bmNfc2NhbnMrMHgwLzB4MTYwIEAgMQpbICAgIDQuMzg4ODI3XSBpbml0Y2FsbCBzY3Np
X2NvbXBsZXRlX2FzeW5jX3NjYW5zKzB4MC8weDE2MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM4ODk0OV0gY2FsbGluZyAgcnRjX2hjdG9zeXMrMHgwLzB4MTBmIEAgMQpbICAgIDQu
Mzg5MTEyXSBydGNfY21vcyAwMDowMzogc2V0dGluZyBzeXN0ZW0gY2xvY2sgdG8gMjAxMi0wNC0x
MSAxODoyOToyNCBVVEMgKDEzMzQxNjg5NjQpClsgICAgNC4zODkyMzddIGluaXRjYWxsIHJ0Y19o
Y3Rvc3lzKzB4MC8weDEwZiByZXR1cm5lZCAwIGFmdGVyIDE4NiB1c2VjcwpbICAgIDQuMzg5MzQw
XSBjYWxsaW5nICBwb3dlcm5vd2s4X2luaXQrMHgwLzB4MWJmIEAgMQpbICAgIDQuMzg5NDQ3XSBp
bml0Y2FsbCBwb3dlcm5vd2s4X2luaXQrMHgwLzB4MWJmIHJldHVybmVkIC0xOSBhZnRlciA1IHVz
ZWNzClsgICAgNC4zODk1NDddIGNhbGxpbmcgIGFjcGlfY3B1ZnJlcV9pbml0KzB4MC8weDE2IEAg
MQpbICAgIDQuMzg5ODE4XSBpbml0Y2FsbCBhY3BpX2NwdWZyZXFfaW5pdCsweDAvMHgxNiByZXR1
cm5lZCAwIGFmdGVyIDE2NiB1c2VjcwpbICAgIDQuMzg5OTIyXSBjYWxsaW5nICBjZW50cmlub19p
bml0KzB4MC8weDJlIEAgMQpbICAgIDQuMzkwMDE5XSBpbml0Y2FsbCBjZW50cmlub19pbml0KzB4
MC8weDJlIHJldHVybmVkIC0xNiBhZnRlciAwIHVzZWNzClsgICAgNC4zOTAxMjJdIGluaXRjYWxs
IGNlbnRyaW5vX2luaXQrMHgwLzB4MmUgcmV0dXJuZWQgd2l0aCBlcnJvciBjb2RlIC0xNiAKWyAg
ICA0LjM5MDIyN10gY2FsbGluZyAgZWRkX2luaXQrMHgwLzB4MWEzIEAgMQpbICAgIDQuMzkwMzI0
XSBCSU9TIEVERCBmYWNpbGl0eSB2MC4xNiAyMDA0LUp1bi0yNSwgMCBkZXZpY2VzIGZvdW5kClsg
ICAgNC4zOTA0MjddIEVERCBpbmZvcm1hdGlvbiBub3QgYXZhaWxhYmxlLgpbICAgIDQuMzkwNTIy
XSBpbml0Y2FsbCBlZGRfaW5pdCsweDAvMHgxYTMgcmV0dXJuZWQgLTE5IGFmdGVyIDE5MiB1c2Vj
cwpbICAgIDQuMzkwNjI2XSBjYWxsaW5nICBtZW1tYXBfaW5pdCsweDAvMHgzNSBAIDEKWyAgICA0
LjM5MDc1OV0gaW5pdGNhbGwgbWVtbWFwX2luaXQrMHgwLzB4MzUgcmV0dXJuZWQgMCBhZnRlciAz
NSB1c2VjcwpbICAgIDQuMzkwODYyXSBjYWxsaW5nICBkZXZmcmVxX3N0YXJ0X3BvbGxpbmcrMHgw
LzB4OTAgQCAxClsgICAgNC4zOTA5OTBdIGluaXRjYWxsIGRldmZyZXFfc3RhcnRfcG9sbGluZysw
eDAvMHg5MCByZXR1cm5lZCAwIGFmdGVyIDIzIHVzZWNzClsgICAgNC4zOTEwOThdIGNhbGxpbmcg
IHBjaV9tbWNmZ19sYXRlX2luc2VydF9yZXNvdXJjZXMrMHgwLzB4NTkgQCAxClsgICAgNC4zOTEy
MDJdIGluaXRjYWxsIHBjaV9tbWNmZ19sYXRlX2luc2VydF9yZXNvdXJjZXMrMHgwLzB4NTkgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zOTEzMjZdIGNhbGxpbmcgIG5ldF9zZWNyZXRf
aW5pdCsweDAvMHgxOSBAIDEKWyAgICA0LjM5MTQzM10gaW5pdGNhbGwgbmV0X3NlY3JldF9pbml0
KzB4MC8weDE5IHJldHVybmVkIDAgYWZ0ZXIgNiB1c2VjcwpbICAgIDQuMzkxNTM1XSBjYWxsaW5n
ICB0Y3BfY29uZ2VzdGlvbl9kZWZhdWx0KzB4MC8weDEyIEAgMQpbICAgIDQuMzkxNjM4XSBpbml0
Y2FsbCB0Y3BfY29uZ2VzdGlvbl9kZWZhdWx0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1
c2VjcwpbICAgIDQuMzkxNzQxXSBjYWxsaW5nICBpbml0aWFsaXplX2hhc2hybmQrMHgwLzB4MTkg
QCAxClsgICAgNC4zOTE4NDNdIGluaXRjYWxsIGluaXRpYWxpemVfaGFzaHJuZCsweDAvMHgxOSBy
ZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjM5MTk2Nl0gYXN5bmNfd2FpdGluZyBAIDEK
WyAgICA0LjM5MjA2M10gYXN5bmNfY29udGludWluZyBAIDEgYWZ0ZXIgMCB1c2VjClsgICAgNC4z
OTIxNjddIGFzeW5jX3dhaXRpbmcgQCAxClsgICAgNC42MzcxNjddIGF0YTY6IFNBVEEgbGluayB1
cCAxLjUgR2JwcyAoU1N0YXR1cyAxMTMgU0NvbnRyb2wgMzAwKQpbICAgIDQuNjM3MzE0XSBhdGE0
OiBTQVRBIGxpbmsgdXAgMy4wIEdicHMgKFNTdGF0dXMgMTIzIFNDb250cm9sIDMwMCkKWyAgICA0
LjYzNzgwN10gYXRhNi4wMDogQVRBUEk6IFRTU1Rjb3JwIENERFZEVyBTSC1TMjIzRiwgU0IwMCwg
bWF4IFVETUEvMTAwClsgICAgNC42Mzg2MzJdIGF0YTYuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEv
MTAwClsgICAgNC42MzkwMjRdIGFzeW5jX3dhaXRpbmcgQCA1MgpbICAgIDQuNjM5MTE3XSBhdGE0
LjAwOiBBVEEtODogU1QzMTAwMDM0MEFTLCBTRDFBLCBtYXggVURNQS8xMzMKWyAgICA0LjYzOTEx
OF0gYXRhNC4wMDogMTk1MzUyNTE2OCBzZWN0b3JzLCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0
aCAzMS8zMikKWyAgICA0LjY0MTE1NF0gYXRhMzogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3Rh
dHVzIDEyMyBTQ29udHJvbCAzMDApClsgICAgNC42NDEzMDJdIGF0YTQuMDA6IGNvbmZpZ3VyZWQg
Zm9yIFVETUEvMTMzClsgICAgNC42NDE0MDldIGFzeW5jX3dhaXRpbmcgQCA1MApbICAgIDQuNjQy
MzIyXSBhdGEzLjAwOiBBVEEtODogU1QzMTAwMDUyOEFTLCBDQzM3LCBtYXggVURNQS8xMzMKWyAg
ICA0LjY0MjQ1Ml0gYXRhMy4wMDogMTk1MzUyNTE2OCBzZWN0b3JzLCBtdWx0aSAxNjogTEJBNDgg
TkNRIChkZXB0aCAzMS8zMikKWyAgICA0LjY0Mzc0NF0gYXRhMy4wMDogY29uZmlndXJlZCBmb3Ig
VURNQS8xMzMKWyAgICA0LjY0Mzg3OV0gYXN5bmNfd2FpdGluZyBAIDQ5ClsgICAgNC42NDUxNTVd
IHVzYiAxLTE6IG5ldyBoaWdoLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcgZWhjaV9o
Y2QKWyAgICA0LjY0NTE2Ml0gYXRhMjogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEy
MyBTQ29udHJvbCAzMDApClsgICAgNC42NDY2MjRdIGF0YTIuMDA6IEFUQS04OiBTVDM1MDAzMjBB
UywgU0QxQSwgbWF4IFVETUEvMTMzClsgICAgNC42NDY3MzZdIGF0YTIuMDA6IDk3Njc3MzE2OCBz
ZWN0b3JzLCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0aCAzMS8zMikKWyAgICA0LjY0ODY0MV0g
YXRhMi4wMDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMKWyAgICA0LjY0ODc1OV0gYXN5bmNfd2Fp
dGluZyBAIDE2ClsgICAgNC42NDkxNTNdIGF0YTE6IFNBVEEgbGluayB1cCAzLjAgR2JwcyAoU1N0
YXR1cyAxMjMgU0NvbnRyb2wgMzAwKQpbICAgIDQuNjUwMzQ0XSBhdGExLjAwOiBBVEEtODogU1Qz
NTAwNDE4QVMsIENDNDYsIG1heCBVRE1BLzEzMwpbICAgIDQuNjUwNDU4XSBhdGExLjAwOiA5NzY3
NzMxNjggc2VjdG9ycywgbXVsdGkgMTY6IExCQTQ4IE5DUSAoZGVwdGggMzEvMzIpClsgICAgNC42
NTE3ODZdIGF0YTEuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzClsgICAgNC42NTE5MDRdIGFz
eW5jX3dhaXRpbmcgQCA1ClsgICAgNC42NTE5ODddIGFzeW5jX2NvbnRpbnVpbmcgQCA1IGFmdGVy
IDAgdXNlYwpbICAgIDQuNjUyMTUxXSBzY3NpIDA6MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIEFU
QSAgICAgIFNUMzUwMDQxOEFTICAgICAgQ0M0NiBQUTogMCBBTlNJOiA1ClsgICAgNC42NTIzMjBd
IGNhbGxpbmcgIDhfc2RfcHJvYmVfYXN5bmMrMHgwLzB4MWQwIEAgNTMKWyAgICA0LjY1MjM0OV0g
c2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0eXBlIDAKWyAgICA0LjY1MjM4
NF0gaW5pdGNhbGwgMl9hc3luY19wb3J0X3Byb2JlKzB4MC8weDcwIHJldHVybmVkIDAgYWZ0ZXIg
MzI0NDE3IHVzZWNzClsgICAgNC42NTIzOTJdIGFzeW5jX2NvbnRpbnVpbmcgQCAxNiBhZnRlciAz
NDY4IHVzZWMKWyAgICA0LjY1MjQzOF0gc2NzaSAxOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBB
VEEgICAgICBTVDM1MDAzMjBBUyAgICAgIFNEMUEgUFE6IDAgQU5TSTogNQpbICAgIDQuNjUyNTEz
XSBzZCAxOjA6MDowOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2cxIHR5cGUgMApbICAgIDQuNjUy
NTM4XSBpbml0Y2FsbCAzX2FzeW5jX3BvcnRfcHJvYmUrMHgwLzB4NzAgcmV0dXJuZWQgMCBhZnRl
ciAzMjQ0NzYgdXNlY3MKWyAgICA0LjY1MjU0Ml0gY2FsbGluZyAgOV9zZF9wcm9iZV9hc3luYysw
eDAvMHgxZDAgQCAxNgpbICAgIDQuNjUyNTUwXSBhc3luY19jb250aW51aW5nIEAgNDkgYWZ0ZXIg
ODM3MCB1c2VjClsgICAgNC42NTI1OTldIHNkIDE6MDowOjA6IFtzZGJdIDk3Njc3MzE2OCA1MTIt
Ynl0ZSBsb2dpY2FsIGJsb2NrczogKDUwMCBHQi80NjUgR2lCKQpbICAgIDQuNjUyNjEwXSBzY3Np
IDI6MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIEFUQSAgICAgIFNUMzEwMDA1MjhBUyAgICAgQ0Mz
NyBQUTogMCBBTlNJOiA1ClsgICAgNC42NTI2ODNdIHNkIDI6MDowOjA6IEF0dGFjaGVkIHNjc2kg
Z2VuZXJpYyBzZzIgdHlwZSAwClsgICAgNC42NTI3MDhdIGluaXRjYWxsIDRfYXN5bmNfcG9ydF9w
cm9iZSsweDAvMHg3MCByZXR1cm5lZCAwIGFmdGVyIDMyNDU0NSB1c2VjcwpbICAgIDQuNjUyNzEx
XSBjYWxsaW5nICAxMF9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgQCA0OQpbICAgIDQuNjUyNzQ4
XSBzZCAyOjA6MDowOiBbc2RjXSAxOTUzNTI1MTY4IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAo
MS4wMCBUQi85MzEgR2lCKQpbICAgIDQuNjUyNzkxXSBzZCAxOjA6MDowOiBbc2RiXSBXcml0ZSBQ
cm90ZWN0IGlzIG9mZgpbICAgIDQuNjUyNzkzXSBzZCAxOjA6MDowOiBbc2RiXSBNb2RlIFNlbnNl
OiAwMCAzYSAwMCAwMApbICAgIDQuNjUyODI2XSBzZCAxOjA6MDowOiBbc2RiXSBXcml0ZSBjYWNo
ZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBG
VUEKWyAgICA0LjY1Mjg1NF0gc2QgMjowOjA6MDogW3NkY10gV3JpdGUgUHJvdGVjdCBpcyBvZmYK
WyAgICA0LjY1Mjg1Nl0gc2QgMjowOjA6MDogW3NkY10gTW9kZSBTZW5zZTogMDAgM2EgMDAgMDAK
WyAgICA0LjY1MjkxM10gc2QgMjowOjA6MDogW3NkY10gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJl
YWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qgc3VwcG9ydCBEUE8gb3IgRlVBClsgICAgNC42NTQy
ODNdIGFzeW5jX2NvbnRpbnVpbmcgQCA1MCBhZnRlciAxMjQ3NiB1c2VjClsgICAgNC42NTQzMDBd
IHNkIDA6MDowOjA6IFtzZGFdIDk3Njc3MzE2OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDUw
MCBHQi80NjUgR2lCKQpbICAgIDQuNjU0MzQ0XSBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBQcm90
ZWN0IGlzIG9mZgpbICAgIDQuNjU0MzQ2XSBzZCAwOjA6MDowOiBbc2RhXSBNb2RlIFNlbnNlOiAw
MCAzYSAwMCAwMApbICAgIDQuNjU0MzY1XSBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBjYWNoZTog
ZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUEK
WyAgICA0LjY1NDc5OV0gc2NzaSAzOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBBVEEgICAgICBT
VDMxMDAwMzQwQVMgICAgIFNEMUEgUFE6IDAgQU5TSTogNQpbICAgIDQuNjU0OTYxXSBjYWxsaW5n
ICAxMV9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgQCA1ClsgICAgNC42NTUwOTBdIHNkIDM6MDow
OjA6IFtzZGRdIDE5NTM1MjUxNjggNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICgxLjAwIFRCLzkz
MSBHaUIpClsgICAgNC42NTUwOThdIHNkIDM6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBz
ZzMgdHlwZSAwClsgICAgNC42NTUzMTBdIGluaXRjYWxsIDVfYXN5bmNfcG9ydF9wcm9iZSsweDAv
MHg3MCByZXR1cm5lZCAwIGFmdGVyIDMyNzAwMiB1c2VjcwpbICAgIDQuNjU1MzM0XSBzZCAzOjA6
MDowOiBbc2RkXSBXcml0ZSBQcm90ZWN0IGlzIG9mZgpbICAgIDQuNjU1MzM1XSBzZCAzOjA6MDow
OiBbc2RkXSBNb2RlIFNlbnNlOiAwMCAzYSAwMCAwMApbICAgIDQuNjU1MzU0XSBzZCAzOjA6MDow
OiBbc2RkXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24n
dCBzdXBwb3J0IERQTyBvciBGVUEKWyAgICA0LjY1ODI2OV0gIHNkYTogc2RhMQpbICAgIDQuNjU4
NTQ2XSBzZCAwOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAgICA0LjY1ODY0MV0g
aW5pdGNhbGwgOF9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgcmV0dXJuZWQgMCBhZnRlciA0Mjcy
IHVzZWNzClsgICAgNC42NjIwMzFdICBzZGM6IHNkYzEKWyAgICA0LjY2MjM0Nl0gc2QgMjowOjA6
MDogW3NkY10gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAgNC42NjI0NDBdIGluaXRjYWxsIDEwX3Nk
X3Byb2JlX2FzeW5jKzB4MC8weDFkMCByZXR1cm5lZCAwIGFmdGVyIDk0OTggdXNlY3MKWyAgICA0
LjY2NTE2NV0gIHNkYjogc2RiMQpbICAgIDQuNjY1NDc0XSBzZCAxOjA6MDowOiBbc2RiXSBBdHRh
Y2hlZCBTQ1NJIGRpc2sKWyAgICA0LjY2NTU2Nl0gaW5pdGNhbGwgOV9zZF9wcm9iZV9hc3luYysw
eDAvMHgxZDAgcmV0dXJuZWQgMCBhZnRlciAxMjcxNiB1c2VjcwpbICAgIDQuNjc0OTI3XSAgc2Rk
OiBzZGQxClsgICAgNC42NzUyNDRdIHNkIDM6MDowOjA6IFtzZGRdIEF0dGFjaGVkIFNDU0kgZGlz
awpbICAgIDQuNjc1MzM3XSBpbml0Y2FsbCAxMV9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgcmV0
dXJuZWQgMCBhZnRlciAxOTgwOSB1c2VjcwpbICAgIDQuNzc3ODQzXSBodWIgMS0xOjEuMDogVVNC
IGh1YiBmb3VuZApbICAgIDQuNzc4MDU2XSBodWIgMS0xOjEuMDogNiBwb3J0cyBkZXRlY3RlZApb
ICAgIDQuODg5MTU3XSB1c2IgMi0xOiBuZXcgaGlnaC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAy
IHVzaW5nIGVoY2lfaGNkClsgICAgNS4wMjE4MzJdIGh1YiAyLTE6MS4wOiBVU0IgaHViIGZvdW5k
ClsgICAgNS4wMjIwNDZdIGh1YiAyLTE6MS4wOiA2IHBvcnRzIGRldGVjdGVkClsgICAgNS4wODUx
NTRdIGF0YTU6IFNBVEEgbGluayB1cCAzLjAgR2JwcyAoU1N0YXR1cyAxMjMgU0NvbnRyb2wgMzAw
KQpbICAgIDUuMDkzMjk1XSB1c2IgMS0xLjI6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVt
YmVyIDMgdXNpbmcgZWhjaV9oY2QKWyAgICA1LjEwNTQyMl0gYXRhNS4wMDogSFBBIGRldGVjdGVk
OiBjdXJyZW50IDk3Njc3MTA1NSwgbmF0aXZlIDk3Njc3MzE2OApbICAgIDUuMTA1NjQ2XSBhdGE1
LjAwOiBBVEEtODogV0RDIFdENTAwMEFBS1MtMjJZR0EwLCAxMi4wMUMwMiwgbWF4IFVETUEvMTMz
ClsgICAgNS4xMDU3NTldIGF0YTUuMDA6IDk3Njc3MTA1NSBzZWN0b3JzLCBtdWx0aSAxNjogTEJB
NDggTkNRIChkZXB0aCAzMS8zMiksIEFBClsgICAgNS4xMDY4MjhdIGF0YTUuMDA6IGNvbmZpZ3Vy
ZWQgZm9yIFVETUEvMTMzClsgICAgNS4xMDY5NDZdIGFzeW5jX3dhaXRpbmcgQCA1MQpbICAgIDUu
MTA3MDI2XSBhc3luY19jb250aW51aW5nIEAgNTEgYWZ0ZXIgMCB1c2VjClsgICAgNS4xMDcxNjNd
IHNjc2kgNDowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgV0RDIFdENTAwMEFBS1Mt
MiAxMi4wIFBROiAwIEFOU0k6IDUKWyAgICA1LjEwNzMyNl0gY2FsbGluZyAgMTJfc2RfcHJvYmVf
YXN5bmMrMHgwLzB4MWQwIEAgNQpbICAgIDUuMTA3MzU0XSBzZCA0OjA6MDowOiBBdHRhY2hlZCBz
Y3NpIGdlbmVyaWMgc2c0IHR5cGUgMApbICAgIDUuMTA3Mzc4XSBpbml0Y2FsbCA2X2FzeW5jX3Bv
cnRfcHJvYmUrMHgwLzB4NzAgcmV0dXJuZWQgMCBhZnRlciA3NjgzODAgdXNlY3MKWyAgICA1LjEw
NzM4NF0gYXN5bmNfY29udGludWluZyBAIDUyIGFmdGVyIDQ1NzA3NyB1c2VjClsgICAgNS4xMDc3
MjFdIHNkIDQ6MDowOjA6IFtzZGVdIDk3Njc3MTA1NSA1MTItYnl0ZSBsb2dpY2FsIGJsb2Nrczog
KDUwMCBHQi80NjUgR2lCKQpbICAgIDUuMTA3OTAzXSBzY3NpIDU6MDowOjA6IENELVJPTSAgICAg
ICAgICAgIFRTU1Rjb3JwIENERFZEVyBTSC1TMjIzRiAgU0IwMCBQUTogMCBBTlNJOiA1ClsgICAg
NS4xMDc5MTRdIHNkIDQ6MDowOjA6IFtzZGVdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAgNS4x
MDc5MTVdIHNkIDQ6MDowOjA6IFtzZGVdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAgNS4x
MDc5MzZdIHNkIDQ6MDowOjA6IFtzZGVdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hl
OiBlbmFibGVkLCBkb2Vzbid0IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgIDUuMTEwNDg1XSBzcjA6
IHNjc2kzLW1tYyBkcml2ZTogNDh4LzQ4eCB3cml0ZXIgZHZkLXJhbSBjZC9ydyB4YS9mb3JtMiBj
ZGRhIHRyYXkKWyAgICA1LjExMDYxN10gY2Ryb206IFVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZp
c2lvbjogMy4yMApbICAgIDUuMTEwNzc2XSBzciA1OjA6MDowOiBBdHRhY2hlZCBzY3NpIENELVJP
TSBzcjAKWyAgICA1LjExMDkwNF0gc3IgNTowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNn
NSB0eXBlIDUKWyAgICA1LjExMTAyNF0gaW5pdGNhbGwgN19hc3luY19wb3J0X3Byb2JlKzB4MC8w
eDcwIHJldHVybmVkIDAgYWZ0ZXIgNzcxODQ4IHVzZWNzClsgICAgNS4xMTExNDNdIGFzeW5jX2Nv
bnRpbnVpbmcgQCAxIGFmdGVyIDcwMjAzMSB1c2VjClsgICAgNS4xMTEyMzBdIGFzeW5jX3dhaXRp
bmcgQCAxClsgICAgNS4xMTg3MjddICBzZGU6IHNkZTEKWyAgICA1LjExOTAwMF0gc2QgNDowOjA6
MDogW3NkZV0gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAgNS4xMTkwODddIGluaXRjYWxsIDEyX3Nk
X3Byb2JlX2FzeW5jKzB4MC8weDFkMCByZXR1cm5lZCAwIGFmdGVyIDExMTMzIHVzZWNzClsgICAg
NS4xMTkxNzldIGFzeW5jX2NvbnRpbnVpbmcgQCAxIGFmdGVyIDc2ODMgdXNlYwpbICAgIDUuMTE5
NTEyXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA5MjBrIGZyZWVkClsgICAgNS4xMTk2
ODZdIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTIyODhrClsg
ICAgNS4xMjU0NTRdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE2MDhrIGZyZWVkClsg
ICAgNS4xMjYwMzRdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEyMDBrIGZyZWVkClsg
ICAgNS4xNTQ5OTddIHVkZXZkWzk4XTogc3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgICA1LjE4MjYw
MV0gY2FsbGluZyAgeGVuX3BjaWJrX2luaXQrMHgwLzB4NTAgW3hlbl9wY2liYWNrXSBAIDE0Nwpb
ICAgIDUuMTgyNzI5XSBwY2liYWNrIDAwMDA6MDE6MDAuMDogc2VpemluZyBkZXZpY2UKWyAgICA1
LjE4Mjg4NV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEK
WyAgICA1LjE4Mjk4Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3Np
IDE2ClsgICAgNS4xODMwODhdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsg
ICAgNS4xODMxODRdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICA1LjE4MzI3M10gcGNp
YmFjayAwMDAwOjAxOjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElS
USAxNgpbICAgIDUuMTgzMzc4XSBwY2liYWNrIDAwMDA6MDE6MDAuMDogUENJIElOVCBBIGRpc2Fi
bGVkClsgICAgNS4xODcwNDZdIHhlbi1wY2liYWNrOiBiYWNrZW5kIGlzIHBhc3N0aHJvdWdoClsg
ICAgNS4xODcxNTFdIGluaXRjYWxsIHhlbl9wY2lia19pbml0KzB4MC8weDUwIFt4ZW5fcGNpYmFj
a10gcmV0dXJuZWQgMCBhZnRlciA0MzQ1IHVzZWNzClsgICAgNS4xOTQyMTNdIGNhbGxpbmcgIGxp
bmVhcl9pbml0KzB4MC8weDEwMDAgW2xpbmVhcl0gQCAxNjUKWyAgICA1LjE5NDMwMF0gbWQ6IGxp
bmVhciBwZXJzb25hbGl0eSByZWdpc3RlcmVkIGZvciBsZXZlbCAtMQpbICAgIDUuMTk0Mzg0XSBp
bml0Y2FsbCBsaW5lYXJfaW5pdCsweDAvMHgxMDAwIFtsaW5lYXJdIHJldHVybmVkIDAgYWZ0ZXIg
ODEgdXNlY3MKWyAgICA1LjE5OTU3MV0gY2FsbGluZyAgbXVsdGlwYXRoX2luaXQrMHgwLzB4MTAw
MCBbbXVsdGlwYXRoXSBAIDE2OQpbICAgIDUuMTk5NjU5XSBtZDogbXVsdGlwYXRoIHBlcnNvbmFs
aXR5IHJlZ2lzdGVyZWQgZm9yIGxldmVsIC00ClsgICAgNS4xOTk3NDldIGluaXRjYWxsIG11bHRp
cGF0aF9pbml0KzB4MC8weDEwMDAgW211bHRpcGF0aF0gcmV0dXJuZWQgMCBhZnRlciA4NiB1c2Vj
cwpbICAgIDUuMjAzMjg1XSBjYWxsaW5nICByYWlkMF9pbml0KzB4MC8weDEwMDAgW3JhaWQwXSBA
IDE3MQpbICAgIDUuMjAzMzcyXSBtZDogcmFpZDAgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBmb3Ig
bGV2ZWwgMApbICAgIDUuMjAzNDYyXSBpbml0Y2FsbCByYWlkMF9pbml0KzB4MC8weDEwMDAgW3Jh
aWQwXSByZXR1cm5lZCAwIGFmdGVyIDg3IHVzZWNzClsgICAgNS4yMDk0MjFdIGNhbGxpbmcgIHJh
aWRfaW5pdCsweDAvMHgxMDAwIFtyYWlkMV0gQCAxNzkKWyAgICA1LjIwOTUxMV0gbWQ6IHJhaWQx
IHBlcnNvbmFsaXR5IHJlZ2lzdGVyZWQgZm9yIGxldmVsIDEKWyAgICA1LjIwOTU5OF0gaW5pdGNh
bGwgcmFpZF9pbml0KzB4MC8weDEwMDAgW3JhaWQxXSByZXR1cm5lZCAwIGFmdGVyIDgzIHVzZWNz
ClsgICAgNS4yMTg0MTNdIGNhbGxpbmcgIGFzeW5jX3R4X2luaXQrMHgwLzB4MTAwMCBbYXN5bmNf
dHhdIEAgMTg2ClsgICAgNS4yMTg1MTldIGFzeW5jX3R4OiBhcGkgaW5pdGlhbGl6ZWQgKGFzeW5j
KQpbICAgIDUuMjE4NjEyXSBpbml0Y2FsbCBhc3luY190eF9pbml0KzB4MC8weDEwMDAgW2FzeW5j
X3R4XSByZXR1cm5lZCAwIGFmdGVyIDg5IHVzZWNzClsgICAgNS4yMTkwMzFdIGNhbGxpbmcgIGlu
aXRfbW9kdWxlKzB4MC8weDEwMDAgW3JhaWQ2X3BxXSBAIDE4NgpbICAgIDUuMjU3MjkyXSB1c2Ig
MS0xLjY6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNCB1c2luZyBlaGNpX2hjZApb
ICAgIDUuMjY4NzU5XSBjYWxsaW5nICBlMTAwMF9pbml0X21vZHVsZSsweDAvMHgxMDAwIFtlMTAw
MGVdIEAgMTgxClsgICAgNS4yNjg4NDBdIGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29y
ayBEcml2ZXIgLSAxLjUuMS1rClsgICAgNS4yNjg5MjFdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5
OTkgLSAyMDExIEludGVsIENvcnBvcmF0aW9uLgpbICAgIDUuMjY5MDMwXSB4ZW46IHJlZ2lzdGVy
aW5nIGdzaSAyMCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDUuMjY5MTE3XSB4ZW46IC0t
PiBwaXJxPTIwIC0+IGlycT0yMCAoZ3NpPTIwKQpbICAgIDUuMjY5MjIzXSBlMTAwMGUgMDAwMDow
MDoxOS4wOiBQQ0kgSU5UIEEgLT4gR1NJIDIwIChsZXZlbCwgbG93KSAtPiBJUlEgMjAKWyAgICA1
LjI4NTE0MF0gcmFpZDY6IGludDY0eDEgICAzMDcwIE1CL3MKWyAgICA1LjMxMzI0Nl0gZTEwMDBl
IDAwMDA6MDA6MTkuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNS4zNTMxMzdd
IHJhaWQ2OiBpbnQ2NHgyICAgMzc3NSBNQi9zClsgICAgNS4zODI2NzJdIGNhbGxpbmcgIGhpZF9p
bml0KzB4MC8weDYzIFtoaWRdIEAgMjMzClsgICAgNS4zODI3NTddIGluaXRjYWxsIGhpZF9pbml0
KzB4MC8weDYzIFtoaWRdIHJldHVybmVkIDAgYWZ0ZXIgMTcgdXNlY3MKWyAgICA1LjM4MzIzOV0g
Y2FsbGluZyAgaGlkX2luaXQrMHgwLzB4MTAwMCBbdXNiaGlkXSBAIDIzMwpbICAgIDUuMzg1NjMw
XSBtZGFkbTogc2VuZGluZyBpb2N0bCA4MDBjMDkxMCB0byBhIHBhcnRpdGlvbiEKWyAgICA1LjM4
NTY5MV0gbWRhZG06IHNlbmRpbmcgaW9jdGwgODAwYzA5MTAgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODU4MTldIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODU4NzhdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODYyNjddIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODYzMjhdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODY2MjVdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODY2ODddIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODc1MDZdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODc1NjddIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODc3NzRdIGlucHV0OiBXaW5ib25kIEVsZWN0cm9uaWNzIENvcnAgSGVybW9uIFVTQiBoaWRt
b3VzZSBEZXZpY2UgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjFhLjAvdXNiMS8xLTEv
MS0xLjIvMS0xLjI6MS4wL2lucHV0L2lucHV0MgpbICAgIDUuMzg4MDUxXSBnZW5lcmljLXVzYiAw
MDAzOjA1NTc6MjIyMS4wMDAxOiBpbnB1dCxoaWRyYXcwOiBVU0IgSElEIHYxLjAwIE1vdXNlIFtX
aW5ib25kIEVsZWN0cm9uaWNzIENvcnAgSGVybW9uIFVTQiBoaWRtb3VzZSBEZXZpY2VdIG9uIHVz
Yi0wMDAwOjAwOjFhLjAtMS4yL2lucHV0MApbICAgIDUuMzg5MzQxXSBpbnB1dDogV2luYm9uZCBF
bGVjdHJvbmljcyBDb3JwIEhlcm1vbiBVU0IgaGlkbW91c2UgRGV2aWNlIGFzIC9kZXZpY2VzL3Bj
aTAwMDA6MDAvMDAwMDowMDoxYS4wL3VzYjEvMS0xLzEtMS4yLzEtMS4yOjEuMS9pbnB1dC9pbnB1
dDMKWyAgICA1LjM4OTU4MV0gZ2VuZXJpYy11c2IgMDAwMzowNTU3OjIyMjEuMDAwMjogaW5wdXQs
aGlkcmF3MTogVVNCIEhJRCB2MS4wMCBLZXlib2FyZCBbV2luYm9uZCBFbGVjdHJvbmljcyBDb3Jw
IEhlcm1vbiBVU0IgaGlkbW91c2UgRGV2aWNlXSBvbiB1c2ItMDAwMDowMDoxYS4wLTEuMi9pbnB1
dDEKWyAgICA1LjM4OTgzM10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZl
ciB1c2JoaWQKWyAgICA1LjM4OTg5NV0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyClsgICAg
NS4zODk5NTNdIGluaXRjYWxsIGhpZF9pbml0KzB4MC8weDEwMDAgW3VzYmhpZF0gcmV0dXJuZWQg
MCBhZnRlciA2NDg0IHVzZWNzClsgICAgNS4zOTg4OThdIG1kOiBiaW5kPHNkYjE+ClsgICAgNS40
MjExMzRdIHJhaWQ2OiBpbnQ2NHg0ICAgMzI2NSBNQi9zClsgICAgNS40NjA5NjldIG1kOiBiaW5k
PHNkYzE+ClsgICAgNS40NjUyNjRdIG1kOiBiaW5kPHNkZDE+ClsgICAgNS40NjcwNThdIGJpbzog
Y3JlYXRlIHNsYWIgPGJpby0xPiBhdCAxClsgICAgNS40NjcxNjNdIG1kL3JhaWQxOm1kMDogYWN0
aXZlIHdpdGggMiBvdXQgb2YgMiBtaXJyb3JzClsgICAgNS40NjcyNDJdIG1kMDogZGV0ZWN0ZWQg
Y2FwYWNpdHkgY2hhbmdlIGZyb20gMCB0byAxMDAwMjAyMTc0NDY0ClsgICAgNS40ODMwMDBdICBt
ZDA6IHVua25vd24gcGFydGl0aW9uIHRhYmxlClsgICAgNS40ODkxMzJdIHJhaWQ2OiBpbnQ2NHg4
ICAgMjU5OSBNQi9zClsgICAgNS41MDEyNDddIG1kOiBiaW5kPHNkYTE+ClsgICAgNS41MDMzNTBd
IG1kL3JhaWQxOm1kMTogYWN0aXZlIHdpdGggMiBvdXQgb2YgMiBtaXJyb3JzClsgICAgNS41MDM0
MzNdIG1kMTogZGV0ZWN0ZWQgY2FwYWNpdHkgY2hhbmdlIGZyb20gMCB0byA1MDAxMDU2MjU2MDAK
WyAgICA1LjUyMjE1N10gIG1kMTogdW5rbm93biBwYXJ0aXRpb24gdGFibGUKWyAgICA1LjU1NzEy
OF0gcmFpZDY6IHNzZTJ4MSAgICA4MDgxIE1CL3MKWyAgICA1LjYyMDE3Ml0gZTEwMDBlIDAwMDA6
MDA6MTkuMDogZXRoMDogKFBDSSBFeHByZXNzOjIuNUdUL3M6V2lkdGggeDEpIDAwOjI1OjkwOjU3
OjlkOjVmClsgICAgNS42MjAyNjRdIGUxMDAwZSAwMDAwOjAwOjE5LjA6IGV0aDA6IEludGVsKFIp
IFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbgpbICAgIDUuNjIwMzc5XSBlMTAwMGUgMDAwMDow
MDoxOS4wOiBldGgwOiBNQUM6IDEwLCBQSFk6IDExLCBQQkEgTm86IEZGRkZGRi0wRkYKWyAgICA1
LjYyMDQ1N10gZTEwMDBlIDAwMDA6MDM6MDAuMDogRGlzYWJsaW5nIEFTUE0gTDBzIApbICAgIDUu
NjIwNjEzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpb
ICAgIDUuNjIwNjc2XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kg
MTYKWyAgICA1LjYyMDczNV0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAg
ICA1LjYyMDc5M10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpbICAgIDUuNjIwODQ4XSBlMTAw
MGUgMDAwMDowMzowMC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEg
MTYKWyAgICA1LjYyMDkzM10gZTEwMDBlIDAwMDA6MDM6MDAuMDogc2V0dGluZyBsYXRlbmN5IHRp
bWVyIHRvIDY0ClsgICAgNS42MjUxMzJdIHJhaWQ2OiBzc2UyeDIgICAgOTk1MiBNQi9zClsgICAg
NS42OTMxMzJdIHJhaWQ2OiBzc2UyeDQgICAxMTM4NyBNQi9zClsgICAgNS42OTMyNTldIHJhaWQ2
OiB1c2luZyBhbGdvcml0aG0gc3NlMng0ICgxMTM4NyBNQi9zKQpbICAgIDUuNjkzMzE5XSBpbml0
Y2FsbCBpbml0X21vZHVsZSsweDAvMHgxMDAwIFtyYWlkNl9wcV0gcmV0dXJuZWQgMCBhZnRlciA0
NjMwODggdXNlY3MKWyAgICA1LjY5Mzg2N10gY2FsbGluZyAgY2FsaWJyYXRlX3hvcl9ibG9ja3Mr
MHgwLzB4MTAwMCBbeG9yXSBAIDE4NgpbICAgIDUuNjkzOTI4XSB4b3I6IGF1dG9tYXRpY2FsbHkg
dXNpbmcgYmVzdCBjaGVja3N1bW1pbmcgZnVuY3Rpb246IGdlbmVyaWNfc3NlClsgICAgNS43MTMx
MzFdICAgIGdlbmVyaWNfc3NlOiAgMzYyNS4wMDAgTUIvc2VjClsgICAgNS43MTMxOTZdIHhvcjog
dXNpbmcgZnVuY3Rpb246IGdlbmVyaWNfc3NlICgzNjI1LjAwMCBNQi9zZWMpClsgICAgNS43MTMy
NjJdIGluaXRjYWxsIGNhbGlicmF0ZV94b3JfYmxvY2tzKzB4MC8weDEwMDAgW3hvcl0gcmV0dXJu
ZWQgMCBhZnRlciAxODg4MCB1c2VjcwpbICAgIDUuNzE1MDk4XSBjYWxsaW5nICBhc3luY19wcV9p
bml0KzB4MC8weDEwMDAgW2FzeW5jX3BxXSBAIDE4NgpbICAgIDUuNzE1MTcyXSBpbml0Y2FsbCBh
c3luY19wcV9pbml0KzB4MC8weDEwMDAgW2FzeW5jX3BxXSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA1LjcxNTc1NF0gY2FsbGluZyAgcmFpZDVfaW5pdCsweDAvMHgxMDAwIFtyYWlkNDU2
XSBAIDE4NgpbICAgIDUuNzE1ODI0XSBtZDogcmFpZDYgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBm
b3IgbGV2ZWwgNgpbICAgIDUuNzE1ODg4XSBtZDogcmFpZDUgcGVyc29uYWxpdHkgcmVnaXN0ZXJl
ZCBmb3IgbGV2ZWwgNQpbICAgIDUuNzE1OTU5XSBtZDogcmFpZDQgcGVyc29uYWxpdHkgcmVnaXN0
ZXJlZCBmb3IgbGV2ZWwgNApbICAgIDUuNzE2MDI2XSBpbml0Y2FsbCByYWlkNV9pbml0KzB4MC8w
eDEwMDAgW3JhaWQ0NTZdIHJldHVybmVkIDAgYWZ0ZXIgMTk2IHVzZWNzClsgICAgNS43Mjg2OTFd
IGUxMDAwZSAwMDAwOjAzOjAwLjA6IGV0aDE6IChQQ0kgRXhwcmVzczoyLjVHVC9zOldpZHRoIHgx
KSAwMDoyNTo5MDo1Nzo5ZDo1ZQpbICAgIDUuNzI4NzczXSBlMTAwMGUgMDAwMDowMzowMC4wOiBl
dGgxOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24KWyAgICA1LjcyODkyOF0g
ZTEwMDBlIDAwMDA6MDM6MDAuMDogZXRoMTogTUFDOiAzLCBQSFk6IDgsIFBCQSBObzogRkZGRkZG
LTBGRgpbICAgIDUuNzI5MDA5XSBpbml0Y2FsbCBlMTAwMF9pbml0X21vZHVsZSsweDAvMHgxMDAw
IFtlMTAwMGVdIHJldHVybmVkIDAgYWZ0ZXIgNDQ5Mzc4IHVzZWNzClsgICAgNS43MzMyMTVdIGNh
bGxpbmcgIHJhaWRfaW5pdCsweDAvMHgxMDAwIFtyYWlkMTBdIEAgMjcwClsgICAgNS43MzMyODRd
IG1kOiByYWlkMTAgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBmb3IgbGV2ZWwgMTAKWyAgICA1Ljcz
MzM1NF0gaW5pdGNhbGwgcmFpZF9pbml0KzB4MC8weDEwMDAgW3JhaWQxMF0gcmV0dXJuZWQgMCBh
ZnRlciA2NyB1c2VjcwpbICAgIDYuNjI2MDE2XSBnZW5lcmljLXVzYiAwMDAzOjA1MUQ6MDAwMi4w
MDAzOiBoaWRkZXYwLGhpZHJhdzI6IFVTQiBISUQgdjEuMTAgRGV2aWNlIFtBbWVyaWNhbiBQb3dl
ciBDb252ZXJzaW9uIEJhY2stVVBTIEVTIDc1MCBGVzo4NDEuSTIgLkQgVVNCIEZXOkkyIF0gb24g
dXNiLTAwMDA6MDA6MWEuMC0xLjYvaW5wdXQwClsgICAgNi42OTczMDldIHVzYiAyLTEuMTogbmV3
IGZ1bGwtc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMyB1c2luZyBlaGNpX2hjZApbICAgIDYuNzk4
MjM0XSBpbnB1dDogTWljcm9zb2Z0IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZm
ZmZhZSBOYW5vIFRyYW5zY2VpdmVyIHYyLjAgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAw
OjFkLjAvdXNiMi8yLTEvMi0xLjEvMi0xLjE6MS4wL2lucHV0L2lucHV0NApbICAgIDYuNzk4NDI5
XSBnZW5lcmljLXVzYiAwMDAzOjA0NUU6MDc0NS4wMDA0OiBpbnB1dCxoaWRyYXczOiBVU0IgSElE
IHYxLjExIEtleWJvYXJkIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZjMlx4ZmZmZmZmYWVc
eGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24gdXNiLTAwMDA6MDA6MWQuMC0xLjEv
aW5wdXQwClsgICAgNi44MDM5ODNdIGlucHV0OiBNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZj
Mlx4ZmZmZmZmYWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMCBhcyAvZGV2aWNlcy9w
Y2kwMDAwOjAwLzAwMDA6MDA6MWQuMC91c2IyLzItMS8yLTEuMS8yLTEuMToxLjEvaW5wdXQvaW5w
dXQ1ClsgICAgNi44MDQyNjVdIGdlbmVyaWMtdXNiIDAwMDM6MDQ1RTowNzQ1LjAwMDU6IGlucHV0
LGhpZHJhdzQ6IFVTQiBISUQgdjEuMTEgTW91c2UgW01pY3Jvc29mdCBNaWNyb3NvZnRceGZmZmZm
ZmMyXHhmZmZmZmZhZVx4ZmZmZmZmYWUgTmFubyBUcmFuc2NlaXZlciB2Mi4wXSBvbiB1c2ItMDAw
MDowMDoxZC4wLTEuMS9pbnB1dDEKWyAgICA2LjgxOTc0M10gaW5wdXQ6IE1pY3Jvc29mdCBNaWNy
b3NvZnRceGZmZmZmZmMyXHhmZmZmZmZhZVx4ZmZmZmZmYWUgTmFubyBUcmFuc2NlaXZlciB2Mi4w
IGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxZC4wL3VzYjIvMi0xLzItMS4xLzItMS4x
OjEuMi9pbnB1dC9pbnB1dDYKWyAgICA2LjgyMDAwM10gZ2VuZXJpYy11c2IgMDAwMzowNDVFOjA3
NDUuMDAwNjogaW5wdXQsaGlkZGV2MCxoaWRyYXc1OiBVU0IgSElEIHYxLjExIERldmljZSBbTWlj
cm9zb2Z0IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5z
Y2VpdmVyIHYyLjBdIG9uIHVzYi0wMDAwOjAwOjFkLjAtMS4xL2lucHV0MgpbICAgIDYuODg5MzA3
XSB1c2IgMi0xLjM6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNCB1c2luZyBlaGNp
X2hjZApbICAgIDYuOTkyMjEzXSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZp
Y2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxZC4wL3VzYjIvMi0xLzItMS4zLzItMS4zOjEuMC9pbnB1
dC9pbnB1dDcKWyAgICA2Ljk5MjQzOV0gZ2VuZXJpYy11c2IgMDAwMzowNDZEOkM1MDguMDAwNzog
aW5wdXQsaGlkcmF3NjogVVNCIEhJRCB2MS4xMCBNb3VzZSBbTG9naXRlY2ggVVNCIFJlY2VpdmVy
XSBvbiB1c2ItMDAwMDowMDoxZC4wLTEuMy9pbnB1dDAKWyAgICA3LjA2MTMwMl0gdXNiIDItMS40
OiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDUgdXNpbmcgZWhjaV9oY2QKWyAgICA3
LjE3MjY3NF0gaW5wdXQ6IEhJRCAwNGQ5OjEyMDMgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAw
OjAwOjFkLjAvdXNiMi8yLTEvMi0xLjQvMi0xLjQ6MS4wL2lucHV0L2lucHV0OApbICAgIDcuMTcy
ODY5XSBnZW5lcmljLXVzYiAwMDAzOjA0RDk6MTIwMy4wMDA4OiBpbnB1dCxoaWRyYXc3OiBVU0Ig
SElEIHYxLjExIEtleWJvYXJkIFtISUQgMDRkOToxMjAzXSBvbiB1c2ItMDAwMDowMDoxZC4wLTEu
NC9pbnB1dDAKWyAgICA3LjE4ODEwM10gaW5wdXQ6IEhJRCAwNGQ5OjEyMDMgYXMgL2RldmljZXMv
cGNpMDAwMDowMC8wMDAwOjAwOjFkLjAvdXNiMi8yLTEvMi0xLjQvMi0xLjQ6MS4xL2lucHV0L2lu
cHV0OQpbICAgIDcuMTg4MzA5XSBnZW5lcmljLXVzYiAwMDAzOjA0RDk6MTIwMy4wMDA5OiBpbnB1
dCxoaWRyYXc4OiBVU0IgSElEIHYxLjExIERldmljZSBbSElEIDA0ZDk6MTIwM10gb24gdXNiLTAw
MDA6MDA6MWQuMC0xLjQvaW5wdXQxClsgICAgNy4yNTcyNzBdIHVzYiAyLTEuNTogbmV3IGhpZ2gt
c3BlZWQgVVNCIGRldmljZSBudW1iZXIgNiB1c2luZyBlaGNpX2hjZApbICAgIDcuNTQwNzYwXSBj
YWxsaW5nICB1c2Jfc3Rvcl9pbml0KzB4MC8weDEwMDAgW3VzYl9zdG9yYWdlXSBAIDQ2MwpbICAg
IDcuNTQwODQ4XSBJbml0aWFsaXppbmcgVVNCIE1hc3MgU3RvcmFnZSBkcml2ZXIuLi4KWyAgICA3
LjU0MTAwNV0gc2NzaTYgOiB1c2Itc3RvcmFnZSAyLTEuNToxLjAKWyAgICA3LjU0MTE0NF0gdXNi
Y29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQpbICAgIDcu
NTQxMjI2XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KWyAgICA3LjU0MTMx
MF0gaW5pdGNhbGwgdXNiX3N0b3JfaW5pdCsweDAvMHgxMDAwIFt1c2Jfc3RvcmFnZV0gcmV0dXJu
ZWQgMCBhZnRlciA0NDggdXNlY3MKWyAgICA3LjU0MTQ1NF0gY2FsbGluZyAgdWFzX2luaXQrMHgw
LzB4MzAgW3Vhc10gQCA0NjQKWyAgICA3LjU0MTY5NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciB1YXMKWyAgICA3LjU0MTc4MV0gaW5pdGNhbGwgdWFzX2luaXQrMHgw
LzB4MzAgW3Vhc10gcmV0dXJuZWQgMCBhZnRlciAyMzQgdXNlY3MKWyAgICA4LjA0NjA3OV0gRVhU
NC1mcyAoZG0tMjcpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4g
T3B0czogKG51bGwpClsgICAgOC44OTgzMjBdIHNjc2kgNjowOjA6MDogRGlyZWN0LUFjY2VzcyAg
ICAgR2VuZXJpYyAgQ29tcGFjdCBGbGFzaCAgICAwLjAwIFBROiAwIEFOU0k6IDIKWyAgICA4Ljg5
ODg5N10gc2NzaSA2OjA6MDoxOiBEaXJlY3QtQWNjZXNzICAgICBHZW5lcmljICBTTS94RC1QaWN0
dXJlICAgIDAuMDAgUFE6IDAgQU5TSTogMgpbICAgIDguODk5NDI2XSBzY3NpIDY6MDowOjI6IERp
cmVjdC1BY2Nlc3MgICAgIEdlbmVyaWMgIFNEWEMvTU1DICAgICAgICAgMC4wMCBQUTogMCBBTlNJ
OiAyClsgICAgOC45MDAwNDNdIHNjc2kgNjowOjA6MzogRGlyZWN0LUFjY2VzcyAgICAgR2VuZXJp
YyAgTVMvTVMtUHJvL0hHICAgICAwLjAwIFBROiAwIEFOU0k6IDIKWyAgICA4LjkwMDY3NV0gc2Nz
aSA2OjA6MDo0OiBEaXJlY3QtQWNjZXNzICAgICBHZW5lcmljICBTRC9NTUMvTVMvTVNQUk8gIDAu
MDAgUFE6IDAgQU5TSTogMgpbICAgIDguOTAxMjY0XSBzZCA2OjA6MDowOiBBdHRhY2hlZCBzY3Np
IGdlbmVyaWMgc2c2IHR5cGUgMApbICAgIDguOTAxNzczXSBzZCA2OjA6MDowOiBbc2RmXSA3ODEz
MTIwIDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoNC4wMCBHQi8zLjcyIEdpQikKWyAgICA4Ljkw
MjI3Ml0gc2QgNjowOjA6MDogW3NkZl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgICA4LjkwMjI3
NF0gc2QgNjowOjA6MDogW3NkZl0gTW9kZSBTZW5zZTogMDMgMDAgMDAgMDAKWyAgICA4LjkwMjc3
Nl0gc2QgNjowOjA6MDogW3NkZl0gTm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDgu
OTAyNzc3XSBzZCA2OjA6MDowOiBbc2RmXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhy
b3VnaApbICAgIDguOTAzMzAwXSBzZCA2OjA6MDoxOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2c3
IHR5cGUgMApbICAgIDguOTAzNDc2XSBzZCA2OjA6MDoyOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMg
c2c4IHR5cGUgMApbICAgIDguOTAzNjU1XSBzZCA2OjA6MDozOiBBdHRhY2hlZCBzY3NpIGdlbmVy
aWMgc2c5IHR5cGUgMApbICAgIDguOTAzODMwXSBzZCA2OjA6MDo0OiBBdHRhY2hlZCBzY3NpIGdl
bmVyaWMgc2cxMCB0eXBlIDAKWyAgICA4LjkwOTAzNF0gc2QgNjowOjA6MTogW3NkZ10gQXR0YWNo
ZWQgU0NTSSByZW1vdmFibGUgZGlzawpbICAgIDguOTEwMDMyXSBzZCA2OjA6MDoyOiBbc2RoXSBB
dHRhY2hlZCBTQ1NJIHJlbW92YWJsZSBkaXNrClsgICAgOC45MTA2NjBdIHNkIDY6MDowOjM6IFtz
ZGldIEF0dGFjaGVkIFNDU0kgcmVtb3ZhYmxlIGRpc2sKWyAgICA4LjkxMjU2NF0gc2QgNjowOjA6
NDogW3Nkal0gQXR0YWNoZWQgU0NTSSByZW1vdmFibGUgZGlzawpbICAgIDguOTEzMDM5XSBzZCA2
OjA6MDowOiBbc2RmXSBObyBDYWNoaW5nIG1vZGUgcGFnZSBwcmVzZW50ClsgICAgOC45MTMxMzBd
IHNkIDY6MDowOjA6IFtzZGZdIEFzc3VtaW5nIGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdoClsg
ICAgOC45MTM5MjZdICBzZGY6IHNkZjEKWyAgICA4LjkxNTkxOF0gc2QgNjowOjA6MDogW3NkZl0g
Tm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDguOTE2MDExXSBzZCA2OjA6MDowOiBb
c2RmXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3VnaApbICAgIDguOTE2MDg2XSBz
ZCA2OjA6MDowOiBbc2RmXSBBdHRhY2hlZCBTQ1NJIHJlbW92YWJsZSBkaXNrClsgICAxMS43OTM2
NzRdIEFERFJDT05GKE5FVERFVl9VUCk6IGV0aDA6IGxpbmsgaXMgbm90IHJlYWR5ClsgICAxMS43
OTM2ODJdIEFERFJDT05GKE5FVERFVl9VUCk6IGV0aDE6IGxpbmsgaXMgbm90IHJlYWR5ClsgICAx
MS44MDE2OTFdIHVkZXZkWzcxNV06IHN0YXJ0aW5nIHZlcnNpb24gMTc1ClsgICAxMS44MzE1NTdd
IGNhbGxpbmcgIHBhcnBvcnRfZGVmYXVsdF9wcm9jX3JlZ2lzdGVyKzB4MC8weDEwMDAgW3BhcnBv
cnRdIEAgNzI3ClsgICAxMS44MzE1NzRdIGluaXRjYWxsIHBhcnBvcnRfZGVmYXVsdF9wcm9jX3Jl
Z2lzdGVyKzB4MC8weDEwMDAgW3BhcnBvcnRdIHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MKWyAg
IDExLjgzMTgwMF0gY2FsbGluZyAgbHBfaW5pdF9tb2R1bGUrMHgwLzB4ZTU3IFtscF0gQCA3MjcK
WyAgIDExLjgzODk0MF0gQWRkaW5nIDgzODg2MDRrIHN3YXAgb24gL2Rldi9tYXBwZXIvVlN5c3Rl
bTAxLWx2U3dhcDhHQi4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBhY3Jvc3M6ODM4ODYwNGsgClsg
ICAxMS44NTQ3NzRdIGxwOiBkcml2ZXIgbG9hZGVkIGJ1dCBubyBkZXZpY2VzIGZvdW5kClsgICAx
MS44NTQ3ODBdIGluaXRjYWxsIGxwX2luaXRfbW9kdWxlKzB4MC8weGU1NyBbbHBdIHJldHVybmVk
IDAgYWZ0ZXIgMjI0MzYgdXNlY3MKWyAgIDExLjg1ODE5MF0gY2FsbGluZyAgZXZ0Y2huX2luaXQr
MHgwLzB4MTAwMCBbeGVuX2V2dGNobl0gQCA3NDYKWyAgIDExLjg1ODI1NV0gRXZlbnQtY2hhbm5l
bCBkZXZpY2UgaW5zdGFsbGVkLgpbICAgMTEuODU4MjU5XSBpbml0Y2FsbCBldnRjaG5faW5pdCsw
eDAvMHgxMDAwIFt4ZW5fZXZ0Y2huXSByZXR1cm5lZCAwIGFmdGVyIDYzIHVzZWNzClsgICAxMS44
NTk5ODZdIGNhbGxpbmcgIGdudGRldl9pbml0KzB4MC8weDEwMDAgW3hlbl9nbnRkZXZdIEAgNzQ3
ClsgICAxMS44NjAwMjldIGluaXRjYWxsIGdudGRldl9pbml0KzB4MC8weDEwMDAgW3hlbl9nbnRk
ZXZdIHJldHVybmVkIDAgYWZ0ZXIgMzggdXNlY3MKWyAgIDExLjg2MTg1OV0gY2FsbGluZyAgbmV0
YmFja19pbml0KzB4MC8weDEwMDAgW3hlbl9uZXRiYWNrXSBAIDc0OApbICAgMTEuODY5MTYwXSBp
bml0Y2FsbCBuZXRiYWNrX2luaXQrMHgwLzB4MTAwMCBbeGVuX25ldGJhY2tdIHJldHVybmVkIDAg
YWZ0ZXIgNzEyNCB1c2VjcwpbICAgMTEuODcxMDQyXSBjYWxsaW5nICB4ZW5fYmxraWZfaW5pdCsw
eDAvMHgyM2UgW3hlbl9ibGtiYWNrXSBAIDc1OQpbICAgMTEuODcxMzk3XSBpbml0Y2FsbCB4ZW5f
YmxraWZfaW5pdCsweDAvMHgyM2UgW3hlbl9ibGtiYWNrXSByZXR1cm5lZCAwIGFmdGVyIDM0MiB1
c2VjcwpbICAgMTEuODc0NzI5XSBjYWxsaW5nICB4ZW5mc19pbml0KzB4MC8weDEwMDAgW3hlbmZz
XSBAIDc2MgpbICAgMTEuODc0NzM1XSBpbml0Y2FsbCB4ZW5mc19pbml0KzB4MC8weDEwMDAgW3hl
bmZzXSByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAgIDExLjg4OTg5MV0gY2FsbGluZyAgbWFj
X2hpZF9pbml0KzB4MC8weDEwMDAgW21hY19oaWRdIEAgNzUzClsgICAxMS44ODk5MTFdIGluaXRj
YWxsIG1hY19oaWRfaW5pdCsweDAvMHgxMDAwIFttYWNfaGlkXSByZXR1cm5lZCAwIGFmdGVyIDE0
IHVzZWNzClsgICAxMS44OTg3NDBdIGNhbGxpbmcgIGpveWRldl9pbml0KzB4MC8weDEwMDAgW2pv
eWRldl0gQCA3NzUKWyAgIDExLjg5OTc4N10gaW5pdGNhbGwgam95ZGV2X2luaXQrMHgwLzB4MTAw
MCBbam95ZGV2XSByZXR1cm5lZCAwIGFmdGVyIDEwMTcgdXNlY3MKWyAgIDExLjk3ODMyOF0gdHlw
ZT0xNDAwIGF1ZGl0KDEzMzQxNjg5NzIuMDg3OjIpOiBhcHBhcm1vcj0iU1RBVFVTIiBvcGVyYXRp
b249InByb2ZpbGVfbG9hZCIgbmFtZT0iL3NiaW4vZGhjbGllbnQiIHBpZD04MjAgY29tbT0iYXBw
YXJtb3JfcGFyc2VyIgpbICAgMTEuOTc4NTgyXSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2ODk3Mi4w
ODc6Myk6IGFwcGFybW9yPSJTVEFUVVMiIG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBuYW1lPSIv
dXNyL2xpYi9OZXR3b3JrTWFuYWdlci9ubS1kaGNwLWNsaWVudC5hY3Rpb24iIHBpZD04MjAgY29t
bT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTEuOTc4NzI0XSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2
ODk3Mi4wODc6NCk6IGFwcGFybW9yPSJTVEFUVVMiIG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBu
YW1lPSIvdXNyL2xpYi9jb25ubWFuL3NjcmlwdHMvZGhjbGllbnQtc2NyaXB0IiBwaWQ9ODIwIGNv
bW09ImFwcGFybW9yX3BhcnNlciIKWyAgIDEyLjA0ODg5OF0gY2FsbGluZyAgc2VyaW9fcmF3X2lu
aXQrMHgwLzB4MTAwMCBbc2VyaW9fcmF3XSBAIDg3OApbICAgMTIuMDQ5NDM1XSBpbml0Y2FsbCBz
ZXJpb19yYXdfaW5pdCsweDAvMHgxMDAwIFtzZXJpb19yYXddIHJldHVybmVkIDAgYWZ0ZXIgNTE4
IHVzZWNzClsgICAxMi4wNjk2MjNdIGNhbGxpbmcgIHBzbW91c2VfaW5pdCsweDAvMHg3ZSBbcHNt
b3VzZV0gQCA4NzkKWyAgIDEyLjA3MTc1NF0gaW5pdGNhbGwgcHNtb3VzZV9pbml0KzB4MC8weDdl
IFtwc21vdXNlXSByZXR1cm5lZCAwIGFmdGVyIDIwNzQgdXNlY3MKWyAgIDEyLjE3NjYxNV0gY2Fs
bGluZyAgYnJfaW5pdCsweDAvMHhiZCBbYnJpZGdlXSBAIDk3MApbICAgMTIuMTc2NjU0XSBCcmlk
Z2UgZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZApbICAgMTIuMjA2MjMyXSBBRERSQ09ORihORVRERVZf
VVApOiBldGgwOiBsaW5rIGlzIG5vdCByZWFkeQpbICAgMTIuMjA2NTYwXSBpbml0Y2FsbCBicl9p
bml0KzB4MC8weGJkIFticmlkZ2VdIHJldHVybmVkIDAgYWZ0ZXIgMjkyMzQgdXNlY3MKWyAgIDEy
LjI1MDc3NF0gZGV2aWNlIGV0aDEgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlClsgICAxMi4zODYz
MjFdIHNjc2lfdmVyaWZ5X2Jsa19pb2N0bDogMTAyIGNhbGxiYWNrcyBzdXBwcmVzc2VkClsgICAx
Mi4zODYzMjVdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAx
Mi4zODYzMjldIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAx
Mi4zOTYzOTFdIEFERFJDT05GKE5FVERFVl9VUCk6IGV0aDE6IGxpbmsgaXMgbm90IHJlYWR5Clsg
ICAxMi4zOTgzOTBdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsg
ICAxMi4zOTgzOTNdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsg
ICAxMi40MjQwNDZdIEFERFJDT05GKE5FVERFVl9VUCk6IGJyMDogbGluayBpcyBub3QgcmVhZHkK
WyAgIDE0LjczNzI5NF0gY2FsbGluZyAgdmVzYWZiX2luaXQrMHgwLzB4ODRhIFt2ZXNhZmJdIEAg
MTMzOApbICAgMTQuNzM3MzUzXSBpbml0Y2FsbCB2ZXNhZmJfaW5pdCsweDAvMHg4NGEgW3Zlc2Fm
Yl0gcmV0dXJuZWQgLTE5IGFmdGVyIDUzIHVzZWNzClsgICAxNC43NTM4NDhdIGluaXQ6IHVkZXYt
ZmFsbGJhY2stZ3JhcGhpY3MgbWFpbiBwcm9jZXNzICgxMzM3KSB0ZXJtaW5hdGVkIHdpdGggc3Rh
dHVzIDEKWyAgIDE1LjA5NjU2OF0gRVhUNC1mcyAoZG0tMjcpOiByZS1tb3VudGVkLiBPcHRzOiBl
cnJvcnM9cmVtb3VudC1ybwpbICAgMTUuMTg5NTQ4XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21t
aXQgaW50ZXJ2YWwgNSBzZWNvbmRzClsgICAxNS4yMTUzNjFdIEVYVDMtZnMgKHNkZjEpOiB1c2lu
ZyBpbnRlcm5hbCBqb3VybmFsClsgICAxNS4yMTUzNjhdIEVYVDMtZnMgKHNkZjEpOiBtb3VudGVk
IGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpbICAgMTUuMjY0OTA5XSBpbml0OiBm
bHVzaC1lYXJseS1qb2ItbG9nIG1haW4gcHJvY2VzcyAoMTM4MSkgdGVybWluYXRlZCB3aXRoIHN0
YXR1cyAxClsgICAxNS4yNzI3ODBdIGluaXQ6IGZhaWxzYWZlIG1haW4gcHJvY2VzcyAoMTM3OCkg
a2lsbGVkIGJ5IFRFUk0gc2lnbmFsClsgICAxNS4zNDY5NTRdIHR5cGU9MTQwMCBhdWRpdCgxMzM0
MTY4OTc1LjQ1NTo1KTogYXBwYXJtb3I9IlNUQVRVUyIgb3BlcmF0aW9uPSJwcm9maWxlX2xvYWQi
IG5hbWU9Ii91c3Ivc2Jpbi9uYW1lZCIgcGlkPTE0NDEgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpb
ICAgMTUuMzQ5ODc1XSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2ODk3NS40NTk6Nik6IGFwcGFybW9y
PSJTVEFUVVMiIG9wZXJhdGlvbj0icHJvZmlsZV9yZXBsYWNlIiBuYW1lPSIvc2Jpbi9kaGNsaWVu
dCIgcGlkPTE0NDAgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTUuMzUwMTU0XSB0eXBlPTE0
MDAgYXVkaXQoMTMzNDE2ODk3NS40NTk6Nyk6IGFwcGFybW9yPSJTVEFUVVMiIG9wZXJhdGlvbj0i
cHJvZmlsZV9yZXBsYWNlIiBuYW1lPSIvdXNyL2xpYi9OZXR3b3JrTWFuYWdlci9ubS1kaGNwLWNs
aWVudC5hY3Rpb24iIHBpZD0xNDQwIGNvbW09ImFwcGFybW9yX3BhcnNlciIKWyAgIDE1LjM1MDMw
MF0gdHlwZT0xNDAwIGF1ZGl0KDEzMzQxNjg5NzUuNDU5OjgpOiBhcHBhcm1vcj0iU1RBVFVTIiBv
cGVyYXRpb249InByb2ZpbGVfcmVwbGFjZSIgbmFtZT0iL3Vzci9saWIvY29ubm1hbi9zY3JpcHRz
L2RoY2xpZW50LXNjcmlwdCIgcGlkPTE0NDAgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTUu
MzUzMTc4XSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2ODk3NS40NjM6OSk6IGFwcGFybW9yPSJTVEFU
VVMiIG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBuYW1lPSIvdXNyL3NiaW4vdGNwZHVtcCIgcGlk
PTE0NDMgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTUuNzk5MDY3XSBlMTAwMGU6IGV0aDAg
TklDIExpbmsgaXMgVXAgMTAwMCBNYnBzIEZ1bGwgRHVwbGV4LCBGbG93IENvbnRyb2w6IFJ4L1R4
ClsgICAxNS43OTk4OTddIEFERFJDT05GKE5FVERFVl9DSEFOR0UpOiBldGgwOiBsaW5rIGJlY29t
ZXMgcmVhZHkKWyAgIDE1LjgxMDI0MV0gZTEwMDBlOiBldGgxIE5JQyBMaW5rIGlzIFVwIDEwMDAg
TWJwcyBGdWxsIER1cGxleCwgRmxvdyBDb250cm9sOiBSeC9UeApbICAgMTUuODExMTYzXSBBRERS
Q09ORihORVRERVZfQ0hBTkdFKTogZXRoMTogbGluayBiZWNvbWVzIHJlYWR5ClsgICAxNS44MTEy
ODZdIGJyMDogdG9wb2xvZ3kgY2hhbmdlIGRldGVjdGVkLCBwcm9wYWdhdGluZwpbICAgMTUuODEx
Mjg5XSBicjA6IHBvcnQgMShldGgxKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlClsgICAxNS44
MTEyOTNdIGJyMDogcG9ydCAxKGV0aDEpIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKWyAgIDE1
LjgxMjA3Nl0gQUREUkNPTkYoTkVUREVWX0NIQU5HRSk6IGJyMDogbGluayBiZWNvbWVzIHJlYWR5
ClsgICAxNi4wMzk3OTFdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAxNi4w
Mzk5OTNdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAxOC4zMzc4NjldIGlu
aXQ6IHBseW1vdXRoLXVwc3RhcnQtYnJpZGdlIG1haW4gcHJvY2VzcyAoMTQxMykga2lsbGVkIGJ5
IFRFUk0gc2lnbmFsClsgICAyNi4wNjUxMjddIGJyMDogbm8gSVB2NiByb3V0ZXJzIHByZXNlbnQK
WyAgIDI2LjY0MTEyOV0gZXRoMDogbm8gSVB2NiByb3V0ZXJzIHByZXNlbnQKWyAgMzIyLjkzMjIx
Ml0gZGV2aWNlIHZpZjEuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUKWyAgMzIyLjkzNTA0Ml0g
QUREUkNPTkYoTkVUREVWX1VQKTogdmlmMS4wOiBsaW5rIGlzIG5vdCByZWFkeQpbICAzMjIuOTkx
NTU0XSBjYWxsaW5nICB4dF9pbml0KzB4MC8weDEwMDAgW3hfdGFibGVzXSBAIDI5MDUKWyAgMzIy
Ljk5MTU2MF0gaW5pdGNhbGwgeHRfaW5pdCsweDAvMHgxMDAwIFt4X3RhYmxlc10gcmV0dXJuZWQg
MCBhZnRlciAxIHVzZWNzClsgIDMyMy4wMDA2ODJdIGNhbGxpbmcgIGlwX3RhYmxlc19pbml0KzB4
MC8weDEwMDAgW2lwX3RhYmxlc10gQCAyOTA1ClsgIDMyMy4wMDA2OTFdIGlwX3RhYmxlczogKEMp
IDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClsgIDMyMy4wMDA2OTRdIGluaXRjYWxsIGlw
X3RhYmxlc19pbml0KzB4MC8weDEwMDAgW2lwX3RhYmxlc10gcmV0dXJuZWQgMCBhZnRlciA4IHVz
ZWNzClsgIDMyMy4wMDI5ODNdIGNhbGxpbmcgIGlwdGFibGVfZmlsdGVyX2luaXQrMHgwLzB4MTAw
MCBbaXB0YWJsZV9maWx0ZXJdIEAgMjkyOApbICAzMjMuMDAyOTkzXSBpbml0Y2FsbCBpcHRhYmxl
X2ZpbHRlcl9pbml0KzB4MC8weDEwMDAgW2lwdGFibGVfZmlsdGVyXSByZXR1cm5lZCAwIGFmdGVy
IDUgdXNlY3MKWyAgMzIzLjAzMzc5NV0gY2FsbGluZyAgcGh5c2Rldl9tdF9pbml0KzB4MC8weDEw
MDAgW3h0X3BoeXNkZXZdIEAgMjkzNQpbICAzMjMuMDMzNzk5XSBpbml0Y2FsbCBwaHlzZGV2X210
X2luaXQrMHgwLzB4MTAwMCBbeHRfcGh5c2Rldl0gcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsg
IDMyNC4wMDc3NTFdIGRldmljZSB0YXAxLjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlClsgIDMy
NC4wMDc3NzddIGJyMDogdG9wb2xvZ3kgY2hhbmdlIGRldGVjdGVkLCBwcm9wYWdhdGluZwpbICAz
MjQuMDA3NzgwXSBicjA6IHBvcnQgMyh0YXAxLjApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUK
WyAgMzI0LjAwNzc4M10gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0
YXRlClsgIDMyNC4wNTYwNzRdIGJyMDogcG9ydCAzKHRhcDEuMCkgZW50ZXJpbmcgZm9yd2FyZGlu
ZyBzdGF0ZQpbICAzMjQuMDYyNDE2XSBicjA6IHRvcG9sb2d5IGNoYW5nZSBkZXRlY3RlZCwgcHJv
cGFnYXRpbmcKWyAgMzI0LjA2MjQyMF0gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmluZyBmb3J3
YXJkaW5nIHN0YXRlClsgIDMyNC4wNjI0MjNdIGJyMDogcG9ydCAzKHRhcDEuMCkgZW50ZXJpbmcg
Zm9yd2FyZGluZyBzdGF0ZQpbICAzMzQuODE3MTMyXSB0YXAxLjA6IG5vIElQdjYgcm91dGVycyBw
cmVzZW50ClsgIDg3Mi4xMTgyODFdIHFlbXUtZG06IHNlbmRpbmcgaW9jdGwgMTI2MSB0byBhIHBh
cnRpdGlvbiEKWyAgODcyLjEyMTUzNF0gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmluZyBmb3J3
YXJkaW5nIHN0YXRlClsgIDg3Mi4xMjYyOTRdIGJyMDogcG9ydCAzKHRhcDEuMCkgZW50ZXJpbmcg
ZGlzYWJsZWQgc3RhdGUKWyAgODcyLjEyNjMzOF0gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmlu
ZyBkaXNhYmxlZCBzdGF0ZQpbICA4NzMuNzUzNTEzXSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBl
dmVudC1jaGFubmVsIDUsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpClsgIDkwOC42NDc1MjddIEFE
RFJDT05GKE5FVERFVl9DSEFOR0UpOiB2aWYxLjA6IGxpbmsgYmVjb21lcyByZWFkeQpbICA5MDgu
NjQ3NTU1XSBicjA6IHRvcG9sb2d5IGNoYW5nZSBkZXRlY3RlZCwgcHJvcGFnYXRpbmcKWyAgOTA4
LjY0NzU1OF0gYnIwOiBwb3J0IDIodmlmMS4wKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlClsg
IDkwOC42NDc1NjFdIGJyMDogcG9ydCAyKHZpZjEuMCkgZW50ZXJpbmcgZm9yd2FyZGluZyBzdGF0
ZQpbICA5MTkuMDczMTI4XSB2aWYxLjA6IG5vIElQdjYgcm91dGVycyBwcmVzZW50Cg==
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="dom0_lspci.txt"
Content-Disposition: attachment; filename="dom0_lspci.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6ey1

MDA6MDAuMCBIb3N0IGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gWGVvbiBFMy0xMjAwIFByb2Nl
c3NvciBGYW1pbHkgRFJBTSBDb250cm9sbGVyIChyZXYgMDkpCglTdWJzeXN0ZW06IFN1cGVyIE1p
Y3JvIENvbXB1dGVyIEluYyBEZXZpY2UgMDYyNAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2
c2VsLCBsYXRlbmN5IDAKCUNhcGFiaWxpdGllczogW2UwXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IExlbj0wYyA8Pz4KCjAwOjAxLjAgUENJIGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24g
WGVvbiBFMy0xMjAwLzJuZCBHZW5lcmF0aW9uIENvcmUgUHJvY2Vzc29yIEZhbWlseSBQQ0kgRXhw
cmVzcyBSb290IFBvcnQgKHJldiAwOSkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJRmxh
Z3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2c2VsLCBsYXRlbmN5IDAKCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTAxLCBzdWJvcmRpbmF0ZT0wMSwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBi
cmlkZ2U6IDAwMDBlMDAwLTAwMDBlZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmJhMDAwMDAt
ZmJhZmZmZmYKCUNhcGFiaWxpdGllczogWzg4XSBTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1
dGVyIEluYyBEZXZpY2UgMDYyNAoJQ2FwYWJpbGl0aWVzOiBbODBdIFBvd2VyIE1hbmFnZW1lbnQg
dmVyc2lvbiAzCglDYXBhYmlsaXRpZXM6IFs5MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNr
YWJsZS0gNjRiaXQtCglDYXBhYmlsaXRpZXM6IFthMF0gRXhwcmVzcyBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwCglDYXBhYmlsaXRpZXM6IFsxMDBdIFZpcnR1YWwgQ2hhbm5lbAoJQ2FwYWJpbGl0
aWVzOiBbMTQwXSBSb290IENvbXBsZXggTGluawoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVw
b3J0CglLZXJuZWwgbW9kdWxlczogc2hwY2hwCgowMDoxOS4wIEV0aGVybmV0IGNvbnRyb2xsZXI6
IEludGVsIENvcnBvcmF0aW9uIDgyNTc5TE0gR2lnYWJpdCBOZXR3b3JrIENvbm5lY3Rpb24gKHJl
diAwNSkKCVN1YnN5c3RlbTogU3VwZXIgTWljcm8gQ29tcHV0ZXIgSW5jIERldmljZSAxNTAyCglG
bGFnczogYnVzIG1hc3RlciwgZmFzdCBkZXZzZWwsIGxhdGVuY3kgMCwgSVJRIDI5MAoJTWVtb3J5
IGF0IGZiYjAwMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTEyOEtdCglNZW1v
cnkgYXQgZmJiMjQwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglJL08g
cG9ydHMgYXQgZjAyMCBbc2l6ZT0zMl0KCUNhcGFiaWxpdGllczogW2M4XSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMgoJQ2FwYWJpbGl0aWVzOiBbZDBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEg
TWFza2FibGUtIDY0Yml0KwoJQ2FwYWJpbGl0aWVzOiBbZTBdIFBDSSBBZHZhbmNlZCBGZWF0dXJl
cwoJS2VybmVsIGRyaXZlciBpbiB1c2U6IGUxMDAwZQoJS2VybmVsIG1vZHVsZXM6IGUxMDAwZQoK
MDA6MWEuMCBVU0IgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRpb24gNiBTZXJpZXMvQzIwMCBT
ZXJpZXMgQ2hpcHNldCBGYW1pbHkgVVNCIEVuaGFuY2VkIEhvc3QgQ29udHJvbGxlciAjMiAocmV2
IDA1KSAocHJvZy1pZiAyMCBbRUhDSV0pCglTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1dGVy
IEluYyBEZXZpY2UgMDYyNAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIG1lZGl1bSBkZXZzZWwsIGxhdGVu
Y3kgMCwgSVJRIDE2CglNZW1vcnkgYXQgZmJiMjMwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs
ZSkgW3NpemU9MUtdCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9u
IDIKCUNhcGFiaWxpdGllczogWzU4XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBhMAoJQ2Fw
YWJpbGl0aWVzOiBbOThdIFBDSSBBZHZhbmNlZCBGZWF0dXJlcwoJS2VybmVsIGRyaXZlciBpbiB1
c2U6IGVoY2lfaGNkCgowMDoxYy4wIFBDSSBicmlkZ2U6IEludGVsIENvcnBvcmF0aW9uIDYgU2Vy
aWVzL0MyMDAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IFBDSSBFeHByZXNzIFJvb3QgUG9ydCAxIChy
ZXYgYjUpIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkKCUZsYWdzOiBidXMgbWFzdGVyLCBm
YXN0IGRldnNlbCwgbGF0ZW5jeSAwCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMiwgc3Vi
b3JkaW5hdGU9MDIsIHNlYy1sYXRlbmN5PTAKCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzIFJv
b3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCUNhcGFiaWxpdGllczogWzgwXSBNU0k6IEVuYWJsZSsg
Q291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0KCUNhcGFiaWxpdGllczogWzkwXSBTdWJzeXN0ZW06
IFN1cGVyIE1pY3JvIENvbXB1dGVyIEluYyBEZXZpY2UgMDYyNAoJQ2FwYWJpbGl0aWVzOiBbYTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQKCUtlcm5lbCBtb2R1bGVzOiBzaHBjaHAKCjAwOjFjLjQgUENJIGJyaWRnZTogSW50ZWwgQ29y
cG9yYXRpb24gNiBTZXJpZXMvQzIwMCBTZXJpZXMgQ2hpcHNldCBGYW1pbHkgUENJIEV4cHJlc3Mg
Um9vdCBQb3J0IDUgKHJldiBiNSkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJRmxhZ3M6
IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2c2VsLCBsYXRlbmN5IDAKCUJ1czogcHJpbWFyeT0wMCwgc2Vj
b25kYXJ5PTAzLCBzdWJvcmRpbmF0ZT0wMywgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlk
Z2U6IDAwMDBkMDAwLTAwMDBkZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmI5MDAwMDAtZmI5
ZmZmZmYKCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kg
MDAKCUNhcGFiaWxpdGllczogWzgwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdC0KCUNhcGFiaWxpdGllczogWzkwXSBTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1dGVy
IEluYyBEZXZpY2UgMDYyNAoJQ2FwYWJpbGl0aWVzOiBbYTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAyCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCUtlcm5lbCBtb2R1bGVzOiBz
aHBjaHAKCjAwOjFkLjAgVVNCIGNvbnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDYgU2VyaWVz
L0MyMDAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IFVTQiBFbmhhbmNlZCBIb3N0IENvbnRyb2xsZXIg
IzEgKHJldiAwNSkgKHByb2ctaWYgMjAgW0VIQ0ldKQoJU3Vic3lzdGVtOiBTdXBlciBNaWNybyBD
b21wdXRlciBJbmMgRGV2aWNlIDA2MjQKCUZsYWdzOiBidXMgbWFzdGVyLCBtZWRpdW0gZGV2c2Vs
LCBsYXRlbmN5IDAsIElSUSAyMwoJTWVtb3J5IGF0IGZiYjIyMDAwICgzMi1iaXQsIG5vbi1wcmVm
ZXRjaGFibGUpIFtzaXplPTFLXQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQg
dmVyc2lvbiAyCglDYXBhYmlsaXRpZXM6IFs1OF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAw
YTAKCUNhcGFiaWxpdGllczogWzk4XSBQQ0kgQWR2YW5jZWQgRmVhdHVyZXMKCUtlcm5lbCBkcml2
ZXIgaW4gdXNlOiBlaGNpX2hjZAoKMDA6MWUuMCBQQ0kgYnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlv
biA4MjgwMSBQQ0kgQnJpZGdlIChyZXYgYTUpIChwcm9nLWlmIDAxIFtTdWJ0cmFjdGl2ZSBkZWNv
ZGVdKQoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2c2VsLCBsYXRlbmN5IDAKCUJ1czogcHJp
bWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0ZT0wNCwgc2VjLWxhdGVuY3k9NjQKCU1l
bW9yeSBiZWhpbmQgYnJpZGdlOiBmYjAwMDAwMC1mYjhmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9y
eSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAwMGZhMDAwMDAwLTAwMDAwMDAwZmFmZmZmZmYKCUNhcGFi
aWxpdGllczogWzUwXSBTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1dGVyIEluYyBEZXZpY2Ug
MDYyNAoKMDA6MWYuMCBJU0EgYnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlvbiBDMjA0IENoaXBzZXQg
RmFtaWx5IExQQyBDb250cm9sbGVyIChyZXYgMDUpCglTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENv
bXB1dGVyIEluYyBEZXZpY2UgMDYyNAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIG1lZGl1bSBkZXZzZWws
IGxhdGVuY3kgMAoJQ2FwYWJpbGl0aWVzOiBbZTBdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlv
bjogTGVuPTBjIDw/PgoJS2VybmVsIG1vZHVsZXM6IGlUQ09fd2R0CgowMDoxZi4yIFJBSUQgYnVz
IGNvbnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDgyODAxIFNBVEEgQ29udHJvbGxlciBbUkFJ
RCBtb2RlXSAocmV2IDA1KQoJU3Vic3lzdGVtOiBTdXBlciBNaWNybyBDb21wdXRlciBJbmMgRGV2
aWNlIDA2MjQKCUZsYWdzOiBidXMgbWFzdGVyLCA2Nk1IeiwgbWVkaXVtIGRldnNlbCwgbGF0ZW5j
eSAwLCBJUlEgMjg5CglJL08gcG9ydHMgYXQgZjA3MCBbc2l6ZT04XQoJSS9PIHBvcnRzIGF0IGYw
NjAgW3NpemU9NF0KCUkvTyBwb3J0cyBhdCBmMDUwIFtzaXplPThdCglJL08gcG9ydHMgYXQgZjA0
MCBbc2l6ZT00XQoJSS9PIHBvcnRzIGF0IGYwMDAgW3NpemU9MzJdCglNZW1vcnkgYXQgZmJiMjEw
MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MktdCglDYXBhYmlsaXRpZXM6IFs4
MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCglDYXBhYmlsaXRpZXM6
IFs3MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCUNhcGFiaWxpdGllczogW2E4XSBTQVRB
IEhCQSB2MS4wCglDYXBhYmlsaXRpZXM6IFtiMF0gUENJIEFkdmFuY2VkIEZlYXR1cmVzCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogYWhjaQoKMDA6MWYuMyBTTUJ1czogSW50ZWwgQ29ycG9yYXRpb24g
NiBTZXJpZXMvQzIwMCBTZXJpZXMgQ2hpcHNldCBGYW1pbHkgU01CdXMgQ29udHJvbGxlciAocmV2
IDA1KQoJU3Vic3lzdGVtOiBTdXBlciBNaWNybyBDb21wdXRlciBJbmMgRGV2aWNlIDA2MjQKCUZs
YWdzOiBtZWRpdW0gZGV2c2VsLCBJUlEgMTEKCU1lbW9yeSBhdCBmYmIyMDAwMCAoNjQtYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdCglJL08gcG9ydHMgYXQgMTE4MCBbc2l6ZT0zMl0K
CUtlcm5lbCBtb2R1bGVzOiBpMmMtaTgwMQoKMDE6MDAuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBj
b250cm9sbGVyOiBMU0kgTG9naWMgLyBTeW1iaW9zIExvZ2ljIFNBUzIwMDggUENJLUV4cHJlc3Mg
RnVzaW9uLU1QVCBTQVMtMiBbRmFsY29uXSAocmV2IDAzKQoJU3Vic3lzdGVtOiBMU0kgTG9naWMg
LyBTeW1iaW9zIExvZ2ljIERldmljZSAzMDIwCglGbGFnczogZmFzdCBkZXZzZWwsIElSUSAxNgoJ
SS9PIHBvcnRzIGF0IGUwMDAgW3NpemU9MjU2XQoJTWVtb3J5IGF0IGZiYWMwMDAwICg2NC1iaXQs
IG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2S10KCU1lbW9yeSBhdCBmYmE4MDAwMCAoNjQtYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZLXQoJRXhwYW5zaW9uIFJPTSBhdCBmYmEwMDAw
MCBbZGlzYWJsZWRdIFtzaXplPTUxMktdCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMKCUNhcGFiaWxpdGllczogWzY4XSBFeHByZXNzIEVuZHBvaW50LCBNU0kg
MDAKCUNhcGFiaWxpdGllczogW2QwXSBWaXRhbCBQcm9kdWN0IERhdGEKCUNhcGFiaWxpdGllczog
W2E4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsKCUNhcGFiaWxpdGll
czogW2MwXSBNU0ktWDogRW5hYmxlLSBDb3VudD0xNSBNYXNrZWQtCglDYXBhYmlsaXRpZXM6IFsx
MDBdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJQ2FwYWJpbGl0aWVzOiBbMTM4XSBQb3dlciBC
dWRnZXRpbmcgPD8+CglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoJS2VybmVsIG1vZHVs
ZXM6IG1wdDJzYXMKCjAzOjAwLjAgRXRoZXJuZXQgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRp
b24gODI1NzRMIEdpZ2FiaXQgTmV0d29yayBDb25uZWN0aW9uCglTdWJzeXN0ZW06IFN1cGVyIE1p
Y3JvIENvbXB1dGVyIEluYyBEZXZpY2UgMDAwMAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2
c2VsLCBsYXRlbmN5IDAsIElSUSAxNgoJTWVtb3J5IGF0IGZiOTAwMDAwICgzMi1iaXQsIG5vbi1w
cmVmZXRjaGFibGUpIFtzaXplPTEyOEtdCglJL08gcG9ydHMgYXQgZDAwMCBbc2l6ZT0zMl0KCU1l
bW9yeSBhdCBmYjkyMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdCglD
YXBhYmlsaXRpZXM6IFtjOF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCUNhcGFiaWxpdGll
czogW2QwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsKCUNhcGFiaWxp
dGllczogW2UwXSBFeHByZXNzIEVuZHBvaW50LCBNU0kgMDAKCUNhcGFiaWxpdGllczogW2EwXSBN
U0ktWDogRW5hYmxlKyBDb3VudD01IE1hc2tlZC0KCUNhcGFiaWxpdGllczogWzEwMF0gQWR2YW5j
ZWQgRXJyb3IgUmVwb3J0aW5nCglDYXBhYmlsaXRpZXM6IFsxNDBdIERldmljZSBTZXJpYWwgTnVt
YmVyIDAwLTI1LTkwLWZmLWZmLTU3LTlkLTVlCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZTEwMDBl
CglLZXJuZWwgbW9kdWxlczogZTEwMDBlCgowNDowMy4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xs
ZXI6IE1hdHJveCBHcmFwaGljcywgSW5jLiBNR0EgRzIwMGVXIFdQQ000NTAgKHJldiAwYSkgKHBy
b2ctaWYgMDAgW1ZHQSBjb250cm9sbGVyXSkKCVN1YnN5c3RlbTogU3VwZXIgTWljcm8gQ29tcHV0
ZXIgSW5jIERldmljZSAwNjI0CglGbGFnczogYnVzIG1hc3RlciwgbWVkaXVtIGRldnNlbCwgbGF0
ZW5jeSA2NCwgSVJRIDUKCU1lbW9yeSBhdCBmYTAwMDAwMCAoMzItYml0LCBwcmVmZXRjaGFibGUp
IFtzaXplPTE2TV0KCU1lbW9yeSBhdCBmYjgwMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxl
KSBbc2l6ZT0xNktdCglNZW1vcnkgYXQgZmIwMDAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs
ZSkgW3NpemU9OE1dCglFeHBhbnNpb24gUk9NIGF0IDx1bmFzc2lnbmVkPiBbZGlzYWJsZWRdCglD
YXBhYmlsaXRpZXM6IFtkY10gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDEKCg==
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="pvhvm_dmesg.txt"
Content-Disposition: attachment; filename="pvhvm_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6gl2

SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vi
c3lzIGNwdQpMaW51eCB2ZXJzaW9uIDIuNi4zMi0yMjAuNy4xLmVsNi54ODZfNjQgKG1vY2tidWls
ZEBjNmIxOG4zLmJzeXMuZGV2LmNlbnRvcy5vcmcpIChnY2MgdmVyc2lvbiA0LjQuNiAyMDExMDcz
MSAoUmVkIEhhdCA0LjQuNi0zKSAoR0NDKSApICMxIFNNUCBXZWQgTWFyIDcgMDA6NTI6MDIgR01U
IDIwMTIKQ29tbWFuZCBsaW5lOiBybyByb290PVVVSUQ9ZjNiZTA0MTEtOTA3ZS00OGFlLWI4Njct
ZjIzMjU0Mjg5MDZiIHJkX05PX0xVS1MgcmRfTk9fTFZNIExBTkc9ZW5fVVMuVVRGLTggcmRfTk9f
TUQgU1lTRk9OVD1sYXRhcmN5cmhlYi1zdW4xNiByaGdiIGNyYXNoa2VybmVsPWF1dG8gIEtFWUJP
QVJEVFlQRT1wYyBLRVlUQUJMRT11cyByZF9OT19ETQpLRVJORUwgc3VwcG9ydGVkIGNwdXM6CiAg
SW50ZWwgR2VudWluZUludGVsCiAgQU1EIEF1dGhlbnRpY0FNRAogIENlbnRhdXIgQ2VudGF1ckhh
dWxzCkJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKIEJJT1MtZTgyMDogMDAwMDAwMDAw
MDAwMDAwMCAtIDAwMDAwMDAwMDAwOWUwMDAgKHVzYWJsZSkKIEJJT1MtZTgyMDogMDAwMDAwMDAw
MDA5ZTAwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQogQklPUy1lODIwOiAwMDAwMDAw
MDAwMGUwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCiBCSU9TLWU4MjA6IDAwMDAw
MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2FibGUpCiBCSU9TLWU4MjA6IDAwMDAw
MDAwZmMwMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKRE1JIDIuNCBwcmVzZW50
LgpTTUJJT1MgdmVyc2lvbiAyLjQgQCAweEZCQjgwCkRNSTogWGVuIEhWTSBkb21VLCBCSU9TIDQu
MS4zLXJjMS1wcmUgMDMvMDgvMjAxMgplODIwIHVwZGF0ZSByYW5nZTogMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwMDEwMDAgKHVzYWJsZSkgPT0+IChyZXNlcnZlZCkKZTgyMCByZW1vdmUg
cmFuZ2U6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwICh1c2FibGUpCmxhc3Rf
cGZuID0gMHg4MDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApNVFJSIGRlZmF1bHQgdHlw
ZTogd3JpdGUtYmFjawpNVFJSIGZpeGVkIHJhbmdlcyBlbmFibGVkOgogIDAwMDAwLTlGRkZGIHdy
aXRlLWJhY2sKICBBMDAwMC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKICBDMDAwMC1GRkZGRiB3cml0
ZS1iYWNrCk1UUlIgdmFyaWFibGUgcmFuZ2VzIGVuYWJsZWQ6CiAgMCBiYXNlIDBGMDAwMDAwMCBt
YXNrIEZGODAwMDAwMCB1bmNhY2hhYmxlCiAgMSBiYXNlIDBGODAwMDAwMCBtYXNrIEZGQzAwMDAw
MCB1bmNhY2hhYmxlCiAgMiBkaXNhYmxlZAogIDMgZGlzYWJsZWQKICA0IGRpc2FibGVkCiAgNSBk
aXNhYmxlZAogIDYgZGlzYWJsZWQKICA3IGRpc2FibGVkCng4NiBQQVQgZW5hYmxlZDogY3B1IDAs
IG9sZCAweDcwNDA2MDAwNzA0MDYsIG5ldyAweDcwMTA2MDAwNzAxMDYKaW5pdGlhbCBtZW1vcnkg
bWFwcGVkIDogMCAtIDIwMDAwMDAwCmluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAw
MDAtMDAwMDAwMDA4MDAwMDAwMAogMDAwMDAwMDAwMCAtIDAwODAwMDAwMDAgcGFnZSAyTQprZXJu
ZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDgwMDAwMDAwIEAgODAwMC1iMDAwClJBTURJ
U0s6IDM3MTFjMDAwIC0gMzdmZWY5ODAKQUNQSTogUlNEUCAwMDAwMDAwMDAwMGVhMDIwIDAwMDI0
ICh2MDIgICAgWGVuKQpBQ1BJOiBYU0RUIDAwMDAwMDAwZmMwMTM0YjAgMDAwMzQgKHYwMSAgICBY
ZW4gICAgICBIVk0gMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKQUNQSTogRkFDUCAwMDAwMDAwMGZj
MDEzMmQwIDAwMEY0ICh2MDQgICAgWGVuICAgICAgSFZNIDAwMDAwMDAwIEhWTUwgMDAwMDAwMDAp
CkFDUEk6IERTRFQgMDAwMDAwMDBmYzAwMzQ0MCAwRkUwNSAodjAyICAgIFhlbiAgICAgIEhWTSAw
MDAwMDAwMCBJTlRMIDIwMTAwNTI4KQpBQ1BJOiBGQUNTIDAwMDAwMDAwZmMwMDM0MDAgMDAwNDAK
QUNQSTogQVBJQyAwMDAwMDAwMGZjMDEzM2QwIDAwMEQ4ICh2MDIgICAgWGVuICAgICAgSFZNIDAw
MDAwMDAwIEhWTUwgMDAwMDAwMDApCkFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAw
Ck5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZApGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAw
MDAwMDAtMDAwMDAwMDA4MDAwMDAwMApCb290bWVtIHNldHVwIG5vZGUgMCAwMDAwMDAwMDAwMDAw
MDAwLTAwMDAwMDAwODAwMDAwMDAKICBOT0RFX0RBVEEgWzAwMDAwMDAwMDAwMDkwMDAgLSAwMDAw
MDAwMDAwMDNjZmZmXQogIGJvb3RtYXAgWzAwMDAwMDAwMDAwM2QwMDAgLSAgMDAwMDAwMDAwMDA0
Y2ZmZl0gcGFnZXMgMTAKKDcgZWFybHkgcmVzZXJ2YXRpb25zKSA9PT4gYm9vdG1lbSBbMDAwMDAw
MDAwMCAtIDAwODAwMDAwMDBdCiAgIzAgWzAwMDAwMDAwMDAgLSAwMDAwMDAxMDAwXSAgIEJJT1Mg
ZGF0YSBwYWdlID09PiBbMDAwMDAwMDAwMCAtIDAwMDAwMDEwMDBdCiAgIzEgWzAwMDAwMDYwMDAg
LSAwMDAwMDA4MDAwXSAgICAgICBUUkFNUE9MSU5FID09PiBbMDAwMDAwNjAwMCAtIDAwMDAwMDgw
MDBdCiAgIzIgWzAwMDEwMDAwMDAgLSAwMDAyMDBjODI0XSAgICBURVhUIERBVEEgQlNTID09PiBb
MDAwMTAwMDAwMCAtIDAwMDIwMGM4MjRdCiAgIzMgWzAwMzcxMWMwMDAgLSAwMDM3ZmVmOTgwXSAg
ICAgICAgICBSQU1ESVNLID09PiBbMDAzNzExYzAwMCAtIDAwMzdmZWY5ODBdCiAgIzQgWzAwMDAw
OWUwMDAgLSAwMDAwMTAwMDAwXSAgICBCSU9TIHJlc2VydmVkID09PiBbMDAwMDA5ZTAwMCAtIDAw
MDAxMDAwMDBdCiAgIzUgWzAwMDIwMGQwMDAgLSAwMDAyMDBkMGQ4XSAgICAgICAgICAgICAgQlJL
ID09PiBbMDAwMjAwZDAwMCAtIDAwMDIwMGQwZDhdCiAgIzYgWzAwMDAwMDgwMDAgLSAwMDAwMDA5
MDAwXSAgICAgICAgICBQR1RBQkxFID09PiBbMDAwMDAwODAwMCAtIDAwMDAwMDkwMDBdCmZvdW5k
IFNNUCBNUC10YWJsZSBhdCBbZmZmZjg4MDAwMDBmYmM5MF0gZmJjOTAKIFtmZmZmZWEwMDAwMDAw
MDAwLWZmZmZlYTAwMDFiZmZmZmZdIFBNRCAtPiBbZmZmZjg4MDAwMjYwMDAwMC1mZmZmODgwMDA0
MWZmZmZmXSBvbiBub2RlIDAKWm9uZSBQRk4gcmFuZ2VzOgogIERNQSAgICAgIDB4MDAwMDAwMDEg
LT4gMHgwMDAwMTAwMAogIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgwMDEwMDAwMAogIE5vcm1h
bCAgIDB4MDAxMDAwMDAgLT4gMHgwMDEwMDAwMApNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBl
YWNoIG5vZGUKZWFybHlfbm9kZV9tYXBbMl0gYWN0aXZlIFBGTiByYW5nZXMKICAgIDA6IDB4MDAw
MDAwMDEgLT4gMHgwMDAwMDA5ZQogICAgMDogMHgwMDAwMDEwMCAtPiAweDAwMDgwMDAwCk9uIG5v
ZGUgMCB0b3RhbHBhZ2VzOiA1MjQxODkKICBETUEgem9uZTogNTYgcGFnZXMgdXNlZCBmb3IgbWVt
bWFwCiAgRE1BIHpvbmU6IDEwMiBwYWdlcyByZXNlcnZlZAogIERNQSB6b25lOiAzODM5IHBhZ2Vz
LCBMSUZPIGJhdGNoOjAKICBETUEzMiB6b25lOiA3MTEyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcAog
IERNQTMyIHpvbmU6IDUxMzA4MCBwYWdlcywgTElGTyBiYXRjaDozMQpBQ1BJOiBQTS1UaW1lciBJ
TyBQb3J0OiAweGIwMDgKQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgwMl0gbGFwaWNfaWRbMHgwNF0gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4
MDNdIGxhcGljX2lkWzB4MDZdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBs
YXBpY19pZFsweDA4XSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNf
aWRbMHgwYV0gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4
MGNdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDBlXSBk
aXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHgxMF0gZGlzYWJs
ZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MTJdIGRpc2FibGVkKQpB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDBhXSBsYXBpY19pZFsweDE0XSBkaXNhYmxlZCkKQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwYl0gbGFwaWNfaWRbMHgxNl0gZGlzYWJsZWQpCkFDUEk6IExBUElD
IChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4MThdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDBkXSBsYXBpY19pZFsweDFhXSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwZV0gbGFwaWNfaWRbMHgxY10gZGlzYWJsZWQpCkFDUEk6IElPQVBJQyAoaWRbMHgwMV0gYWRk
cmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKSU9BUElDWzBdOiBhcGljX2lkIDEsIHZlcnNp
b24gMTcsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtNDcKQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgNSBnbG9iYWxfaXJxIDUgbG93IGxldmVsKQpBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAxMCBnbG9iYWxfaXJxIDEwIGxvdyBsZXZlbCkKQUNQSTogSU5UX1NSQ19P
VlIgKGJ1cyAwIGJ1c19pcnEgMTEgZ2xvYmFsX2lycSAxMSBsb3cgbGV2ZWwpCkFDUEk6IElSUTAg
dXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlE1
IHVzZWQgYnkgb3ZlcnJpZGUuCkFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJR
MTAgdXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJRMTEgdXNlZCBieSBvdmVycmlkZS4KVXNpbmcg
QUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uClNNUDogQWxsb3dp
bmcgMTUgQ1BVcywgMTMgaG90cGx1ZyBDUFVzCm5yX2lycXNfZ3NpOiA0OApYZW4gdmVyc2lvbiA0
LjEuClhlbiBQbGF0Zm9ybSBQQ0k6IEkvTyBwcm90b2NvbCB2ZXJzaW9uIDEKTmV0ZnJvbnQgYW5k
IHRoZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGlsZWQgZm9yIHRoaXMg
a2VybmVsOiB1bnBsdWcgZW11bGF0ZWQgTklDcy4KQmxrZnJvbnQgYW5kIHRoZSBYZW4gcGxhdGZv
cm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGlsZWQgZm9yIHRoaXMga2VybmVsOiB1bnBsdWcg
ZW11bGF0ZWQgZGlza3MuCllvdSBtaWdodCBoYXZlIHRvIGNoYW5nZSB0aGUgcm9vdCBkZXZpY2UK
ZnJvbSAvZGV2L2hkW2EtZF0gdG8gL2Rldi94dmRbYS1kXQppbiB5b3VyIHJvb3Q9IGtlcm5lbCBj
b21tYW5kIGxpbmUgb3B0aW9uClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw
MDAwOWUwMDAgLSAwMDAwMDAwMDAwMGEwMDAwClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMGUwMDAwClBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwCkFsbG9jYXRpbmcg
UENJIHJlc291cmNlcyBzdGFydGluZyBhdCA4MDAwMDAwMCAoZ2FwOiA4MDAwMDAwMDo3YzAwMDAw
MCkKQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpOUl9DUFVTOjQwOTYgbnJf
Y3B1bWFza19iaXRzOjE1IG5yX2NwdV9pZHM6MTUgbnJfbm9kZV9pZHM6MQpQRVJDUFU6IEVtYmVk
ZGVkIDMwIHBhZ2VzL2NwdSBAZmZmZjg4MDAwMjIwMDAwMCBzOTI2MzIgcjgxOTIgZDIyMDU2IHUx
MzEwNzIKcGNwdS1hbGxvYzogczkyNjMyIHI4MTkyIGQyMjA1NiB1MTMxMDcyIGFsbG9jPTEqMjA5
NzE1MgpwY3B1LWFsbG9jOiBbMF0gMDAgMDEgMDIgMDMgMDQgMDUgMDYgMDcgMDggMDkgMTAgMTEg
MTIgMTMgMTQgLS0gCkJ1aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdy
b3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDUxNjkxOQpQb2xpY3kgem9uZTogRE1BMzIKS2VybmVs
IGNvbW1hbmQgbGluZTogcm8gcm9vdD1VVUlEPWYzYmUwNDExLTkwN2UtNDhhZS1iODY3LWYyMzI1
NDI4OTA2YiByZF9OT19MVUtTIHJkX05PX0xWTSBMQU5HPWVuX1VTLlVURi04IHJkX05PX01EIFNZ
U0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgcmhnYiAgIEtFWUJPQVJEVFlQRT1wYyBLRVlUQUJMRT11
cyByZF9OT19ETQpQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3Njgg
Ynl0ZXMpCkNoZWNraW5nIGFwZXJ0dXJlLi4uCk5vIEFHUCBicmlkZ2UgZm91bmQKTWVtb3J5OiAy
MDM0MTUyay8yMDk3MTUyayBhdmFpbGFibGUgKDUwODRrIGtlcm5lbCBjb2RlLCAzOTZrIGFic2Vu
dCwgNjI2MDRrIHJlc2VydmVkLCA3MjI5ayBkYXRhLCAxMjQ0ayBpbml0KQpIaWVyYXJjaGljYWwg
UkNVIGltcGxlbWVudGF0aW9uLgpOUl9JUlFTOjMzMDI0IG5yX2lycXM6OTM2ClhlbiBIVk0gY2Fs
bGJhY2sgdmVjdG9yIGZvciBldmVudCBkZWxpdmVyeSBpcyBlbmFibGVkCkNvbnNvbGU6IGNvbG91
ciBWR0ErIDgweDI1CmNvbnNvbGUgW3R0eTBdIGVuYWJsZWQKYWxsb2NhdGVkIDE2Nzc3MjE2IGJ5
dGVzIG9mIHBhZ2VfY2dyb3VwCnBsZWFzZSB0cnkgJ2Nncm91cF9kaXNhYmxlPW1lbW9yeScgb3B0
aW9uIGlmIHlvdSBkb24ndCB3YW50IG1lbW9yeSBjZ3JvdXBzCkZhc3QgVFNDIGNhbGlicmF0aW9u
IHVzaW5nIFBJVApEZXRlY3RlZCAzMTkzLjA1OSBNSHogcHJvY2Vzc29yLgpDYWxpYnJhdGluZyBk
ZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVxdWVu
Y3kuLiA2Mzg2LjExIEJvZ29NSVBTIChscGo9MzE5MzA1OSkKcGlkX21heDogZGVmYXVsdDogMzI3
NjggbWluaW11bTogMzAxClNlY3VyaXR5IEZyYW1ld29yayBpbml0aWFsaXplZApTRUxpbnV4OiAg
SW5pdGlhbGl6aW5nLgpTRUxpbnV4OiAgU3RhcnRpbmcgaW4gcGVybWlzc2l2ZSBtb2RlCkRlbnRy
eSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI2MjE0NCAob3JkZXI6IDksIDIwOTcxNTIgYnl0
ZXMpCklub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogOCwgMTA0
ODU3NiBieXRlcykKTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKSW5pdGlhbGl6
aW5nIGNncm91cCBzdWJzeXMgbnMKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdApJ
bml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1vcnkKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJz
eXMgZGV2aWNlcwpJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyCkluaXRpYWxpemlu
ZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgYmxraW8K
SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgcGVyZl9ldmVudApDUFU6IENQVSBmZWF0dXJlIHJk
dHNjcCBkaXNhYmxlZCBvbiB4ZW4gZ3Vlc3QKQ1BVOiBDUFUgZmVhdHVyZSBjb25zdGFudF90c2Mg
ZGlzYWJsZWQgb24geGVuIGd1ZXN0CkNQVTogVW5zdXBwb3J0ZWQgbnVtYmVyIG9mIHNpYmxpbmdz
IDMyCm1jZTogQ1BVIHN1cHBvcnRzIDkgTUNFIGJhbmtzCmFsdGVybmF0aXZlczogc3dpdGNoaW5n
IHRvIHVuZmFpciBzcGlubG9jawpBQ1BJOiBDb3JlIHJldmlzaW9uIDIwMDkwOTAzCmZ0cmFjZTog
Y29udmVydGluZyBtY291bnQgY2FsbHMgdG8gMGYgMWYgNDQgMDAgMDAKZnRyYWNlOiBhbGxvY2F0
aW5nIDIwNzgyIGVudHJpZXMgaW4gODIgcGFnZXMKeDJhcGljIG5vdCBlbmFibGVkLCBJUlEgcmVt
YXBwaW5nIGluaXQgZmFpbGVkClNldHRpbmcgQVBJQyByb3V0aW5nIHRvIHBoeXNpY2FsIGZsYXQK
Li5USU1FUjogdmVjdG9yPTB4MzAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9MCBwaW4yPTAKQ1BVMDog
SW50ZWwoUikgWGVvbihSKSBDUFUgRTMxMjMwIEAgMy4yMEdIeiBzdGVwcGluZyAwNwpQZXJmb3Jt
YW5jZSBFdmVudHM6IHVuc3VwcG9ydGVkIHA2IENQVSBtb2RlbCA0MiBubyBQTVUgZHJpdmVyLCBz
b2Z0d2FyZSBldmVudHMgb25seS4KTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUwKTogaGFyZHdh
cmUgZXZlbnRzIG5vdCBlbmFibGVkCkJvb3RpbmcgTm9kZSAgIDAsIFByb2Nlc3NvcnMgICMxCkNQ
VTogQ1BVIGZlYXR1cmUgcmR0c2NwIGRpc2FibGVkIG9uIHhlbiBndWVzdApDUFU6IENQVSBmZWF0
dXJlIGNvbnN0YW50X3RzYyBkaXNhYmxlZCBvbiB4ZW4gZ3Vlc3QKQ1BVOiBVbnN1cHBvcnRlZCBu
dW1iZXIgb2Ygc2libGluZ3MgMzIKQnJvdWdodCB1cCAyIENQVXMKVG90YWwgb2YgMiBwcm9jZXNz
b3JzIGFjdGl2YXRlZCAoMTI3NzAuNzkgQm9nb01JUFMpLgpzaXplb2Yodm1hKT0yMDAgYnl0ZXMK
c2l6ZW9mKHBhZ2UpPTU2IGJ5dGVzCnNpemVvZihpbm9kZSk9NTkyIGJ5dGVzCnNpemVvZihkZW50
cnkpPTE5MiBieXRlcwpzaXplb2YoZXh0M2lub2RlKT04MDAgYnl0ZXMKc2l6ZW9mKGJ1ZmZlcl9o
ZWFkKT0xMDQgYnl0ZXMKc2l6ZW9mKHNrYnVmZik9MjMyIGJ5dGVzCnNpemVvZih0YXNrX3N0cnVj
dCk9MjYxNiBieXRlcwpkZXZ0bXBmczogaW5pdGlhbGl6ZWQKcmVndWxhdG9yOiBjb3JlIHZlcnNp
b24gMC41Ck5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKICBhbGxvYyBpcnFfZGVz
YyBmb3IgMTYgb24gbm9kZSAwCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKQUNQSTogYnVz
IHR5cGUgcGNpIHJlZ2lzdGVyZWQKUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3Ig
YmFzZSBhY2Nlc3MKYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKQUNQSTogRUM6IExvb2sg
dXAgRUMgaW4gRFNEVApBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkCkFDUEk6IChzdXBwb3J0cyBT
MCBTMyBTNCBTNSkKQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZwpBQ1BJ
OiBObyBkb2NrIGRldmljZXMgZm91bmQuCkhFU1Q6IFRhYmxlIG5vdCBmb3VuZC4KQUNQSTogUENJ
IFJvb3QgQnJpZGdlIFtQQ0kwXSAoMDAwMDowMCkKcGNpIDAwMDA6MDA6MDEuMTogcmVnIDIwIGlv
IHBvcnQ6IFsweGMyNjAtMHhjMjZmXQpwY2kgMDAwMDowMDowMS4yOiByZWcgMjAgaW8gcG9ydDog
WzB4YzI0MC0weGMyNWZdCiogRm91bmQgUE0tVGltZXIgQnVnIG9uIHRoZSBjaGlwc2V0LiBEdWUg
dG8gd29ya2Fyb3VuZHMgZm9yIGEgYnVnLAoqIHRoaXMgY2xvY2sgc291cmNlIGlzIHNsb3cuIENv
bnNpZGVyIHRyeWluZyBvdGhlciBjbG9jayBzb3VyY2VzCnBjaSAwMDAwOjAwOjAxLjM6IHF1aXJr
OiByZWdpb24gYjAwMC1iMDNmIGNsYWltZWQgYnkgUElJWDQgQUNQSQpwY2kgMDAwMDowMDowMi4w
OiByZWcgMTAgMzJiaXQgbW1pbyBwcmVmOiBbMHhmMDAwMDAwMC0weGYxZmZmZmZmXQpwY2kgMDAw
MDowMDowMi4wOiByZWcgMTQgMzJiaXQgbW1pbzogWzB4ZjMwZTQwMDAtMHhmMzBlNGZmZl0KcGNp
IDAwMDA6MDA6MDMuMDogcmVnIDEwIGlvIHBvcnQ6IFsweGMwMDAtMHhjMGZmXQpwY2kgMDAwMDow
MDowMy4wOiByZWcgMTQgMzJiaXQgbW1pbyBwcmVmOiBbMHhmMjAwMDAwMC0weGYyZmZmZmZmXQpw
Y2kgMDAwMDowMDowNS4wOiByZWcgMTAgaW8gcG9ydDogWzB4YzEwMC0weGMxZmZdCnBjaSAwMDAw
OjAwOjA1LjA6IHJlZyAxNCA2NGJpdCBtbWlvOiBbMHhmMzBlMDAwMC0weGYzMGUzZmZmXQpwY2kg
MDAwMDowMDowNS4wOiByZWcgMWMgNjRiaXQgbW1pbzogWzB4ZjMwODAwMDAtMHhmMzBiZmZmZl0K
cGNpIDAwMDA6MDA6MDUuMDogcmVnIDMwIDMyYml0IG1taW8gcHJlZjogWzB4ZjMwMDAwMDAtMHhm
MzA3ZmZmZl0KcGNpIDAwMDA6MDA6MDUuMDogc3VwcG9ydHMgRDEgRDIKQUNQSTogUENJIEludGVy
cnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLl9QUlRdCkFDUEk6IFBDSSBJbnRlcnJ1cHQg
TGluayBbTE5LQV0gKElSUXMgKjUgMTAgMTEpCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L
Ql0gKElSUXMgNSAqMTAgMTEpCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQ10gKElSUXMg
NSAxMCAqMTEpCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElSUXMgKjUgMTAgMTEp
CnZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6MDAwMDowMDowMi4wLGRlY29kZXM9aW8rbWVtLG93
bnM9aW8rbWVtLGxvY2tzPW5vbmUKdmdhYXJiOiBsb2FkZWQKdmdhYXJiOiBicmlkZ2UgY29udHJv
bCBwb3NzaWJsZSAwMDAwOjAwOjAyLjAKU0NTSSBzdWJzeXN0ZW0gaW5pdGlhbGl6ZWQKbGliYXRh
IHZlcnNpb24gMy4wMCBsb2FkZWQuCnVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgdXNiZnMKdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBodWIK
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2IKUENJOiBVc2luZyBBQ1BJ
IGZvciBJUlEgcm91dGluZwpQQ0k6IG9sZCBjb2RlIHdvdWxkIGhhdmUgc2V0IGNhY2hlbGluZSBz
aXplIHRvIDMyIGJ5dGVzLCBidXQgY2xmbHVzaF9zaXplID0gNjQKUENJOiBwY2lfY2FjaGVfbGlu
ZV9zaXplIHNldCB0byA2NCBieXRlcwpOZXRMYWJlbDogSW5pdGlhbGl6aW5nCk5ldExhYmVsOiAg
ZG9tYWluIGhhc2ggc2l6ZSA9IDEyOApOZXRMYWJlbDogIHByb3RvY29scyA9IFVOTEFCRUxFRCBD
SVBTT3Y0Ck5ldExhYmVsOiAgdW5sYWJlbGVkIHRyYWZmaWMgYWxsb3dlZCBieSBkZWZhdWx0ClN3
aXRjaGluZyB0byBjbG9ja3NvdXJjZSBqaWZmaWVzCnBucDogUG5QIEFDUEkgaW5pdApBQ1BJOiBi
dXMgdHlwZSBwbnAgcmVnaXN0ZXJlZApwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMiBkZXZpY2VzCkFD
UEk6IEFDUEkgYnVzIHR5cGUgcG5wIHVucmVnaXN0ZXJlZApzeXN0ZW0gMDA6MDA6IGlvbWVtIHJh
bmdlIDB4MC0weDlmZmZmIGNvdWxkIG5vdCBiZSByZXNlcnZlZApzeXN0ZW0gMDA6MDI6IGlvcG9y
dCByYW5nZSAweDEwYzAtMHgxMTQxIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowMjogaW9w
b3J0IHJhbmdlIDB4YjA0NC0weGIwNDcgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjAzOiBp
b3BvcnQgcmFuZ2UgMHg4YTAtMHg4YTMgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjAzOiBp
b3BvcnQgcmFuZ2UgMHhjYzAtMHhjY2YgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjAzOiBp
b3BvcnQgcmFuZ2UgMHg0ZDAtMHg0ZDEgaGFzIGJlZW4gcmVzZXJ2ZWQKU3dpdGNoaW5nIHRvIGNs
b2Nrc291cmNlIGFjcGlfcG0KcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAwIGlvOiAgWzB4MDAt
MHhmZmZmXQpwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDEgbWVtOiBbMHgwMDAwMDAtMHhmZmZm
ZmZmZmZmZmZmZmZmXQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDIKSVAgcm91dGUg
Y2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykK
VENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogMTAsIDQx
OTQzMDQgYnl0ZXMpClRDUCBiaW5kIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA4
LCAxMDQ4NTc2IGJ5dGVzKQpUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVk
IDI2MjE0NCBiaW5kIDY1NTM2KQpUQ1AgcmVubyByZWdpc3RlcmVkCk5FVDogUmVnaXN0ZXJlZCBw
cm90b2NvbCBmYW1pbHkgMQpwY2kgMDAwMDowMDowMC4wOiBMaW1pdGluZyBkaXJlY3QgUENJL1BD
SSB0cmFuc2ZlcnMKcGNpIDAwMDA6MDA6MDEuMDogUElJWDM6IEVuYWJsaW5nIFBhc3NpdmUgUmVs
ZWFzZQpwY2kgMDAwMDowMDowMS4wOiBBY3RpdmF0aW5nIElTQSBETUEgaGFuZyB3b3JrYXJvdW5k
cwpwY2kgMDAwMDowMDowMi4wOiBCb290IHZpZGVvIGRldmljZQpUcnlpbmcgdG8gdW5wYWNrIHJv
b3RmcyBpbWFnZSBhcyBpbml0cmFtZnMuLi4KRnJlZWluZyBpbml0cmQgbWVtb3J5OiAxNTE4Mmsg
ZnJlZWQKYXVkaXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHNvY2tldCAoZGlzYWJsZWQpCnR5cGU9
MjAwMCBhdWRpdCgxMzM0MTY5ODMwLjcwMzoxKTogaW5pdGlhbGl6ZWQKSHVnZVRMQiByZWdpc3Rl
cmVkIDIgTUIgcGFnZSBzaXplLCBwcmUtYWxsb2NhdGVkIDAgcGFnZXMKVkZTOiBEaXNrIHF1b3Rh
cyBkcXVvdF82LjUuMgpEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXIg
MCwgNDA5NiBieXRlcykKbXNnbW5pIGhhcyBiZWVuIHNldCB0byA0MDAyClNFTGludXg6ICBSZWdp
c3RlcmluZyBuZXRmaWx0ZXIgaG9va3MKYWxnOiBObyB0ZXN0IGZvciBzdGRybmcgKGtybmcpCmtz
aWduOiBJbnN0YWxsaW5nIHB1YmxpYyBrZXkgZGF0YQpMb2FkaW5nIGtleXJpbmcKLSBBZGRlZCBw
dWJsaWMga2V5IDhBRDIyRUNFNDQxQjcxODAKLSBVc2VyIElEOiBDZW50T1MgKEtlcm5lbCBNb2R1
bGUgR1BHIGtleSkKQmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2ZXJzaW9u
IDAuNCBsb2FkZWQgKG1ham9yIDI1MikKaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZAppbyBz
Y2hlZHVsZXIgYW50aWNpcGF0b3J5IHJlZ2lzdGVyZWQKaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJl
Z2lzdGVyZWQKaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZhdWx0KQpwY2lfaG90cGx1
ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpwY2llaHA6IFBDSSBFeHByZXNz
IEhvdCBQbHVnIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNAphY3BpcGhwOiBBQ1BJIEhv
dCBQbHVnIFBDSSBDb250cm9sbGVyIERyaXZlciB2ZXJzaW9uOiAwLjUKYWNwaXBocDogU2xvdCBb
MF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3Qg
WzJdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xvdCBbM10gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90
IFs0XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzVdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xv
dCBbNl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFs3XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNs
b3QgWzhdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xvdCBbOV0gcmVnaXN0ZXJlZAphY3BpcGhwOiBT
bG90IFsxMF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxMV0gcmVnaXN0ZXJlZAphY3BpcGhw
OiBTbG90IFsxMl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxM10gcmVnaXN0ZXJlZAphY3Bp
cGhwOiBTbG90IFsxNF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxNV0gcmVnaXN0ZXJlZAph
Y3BpcGhwOiBTbG90IFsxNl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxN10gcmVnaXN0ZXJl
ZAphY3BpcGhwOiBTbG90IFsxOF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxOV0gcmVnaXN0
ZXJlZAphY3BpcGhwOiBTbG90IFsyMF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyMV0gcmVn
aXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyMl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyM10g
cmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyNF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsy
NV0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyNl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90
IFsyN10gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyOF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBT
bG90IFsyOV0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFszMF0gcmVnaXN0ZXJlZAphY3BpcGhw
OiBTbG90IFszMV0gcmVnaXN0ZXJlZAppbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xO
WFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0MApBQ1BJOiBQb3dlciBCdXR0b24gW1BX
UkZdCmlucHV0OiBTbGVlcCBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YU0xQQk46
MDAvaW5wdXQvaW5wdXQxCkFDUEk6IFNsZWVwIEJ1dHRvbiBbU0xQRl0KQUNQSTogYWNwaV9pZGxl
IHJlZ2lzdGVyZWQgd2l0aCBjcHVpZGxlCnByb2Nlc3NvciBMTlhDUFU6MDA6IHJlZ2lzdGVyZWQg
YXMgY29vbGluZ19kZXZpY2UwCnByb2Nlc3NvciBMTlhDUFU6MDE6IHJlZ2lzdGVyZWQgYXMgY29v
bGluZ19kZXZpY2UxCkVSU1Q6IFRhYmxlIGlzIG5vdCBmb3VuZCEKR0hFUzogSEVTVCBpcyBub3Qg
ZW5hYmxlZCEKICBhbGxvYyBpcnFfZGVzYyBmb3IgMjggb24gbm9kZSAtMQogIGFsbG9jIGtzdGF0
X2lycXMgb24gbm9kZSAtMQp4ZW4tcGxhdGZvcm0tcGNpIDAwMDA6MDA6MDMuMDogUENJIElOVCBB
IC0+IEdTSSAyOCAobGV2ZWwsIGxvdykgLT4gSVJRIDI4CkdyYW50IHRhYmxlIGluaXRpYWxpemVk
Ck5vbi12b2xhdGlsZSBtZW1vcnkgZHJpdmVyIHYxLjMKTGludXggYWdwZ2FydCBpbnRlcmZhY2Ug
djAuMTAzCmNyYXNoIG1lbW9yeSBkcml2ZXI6IHZlcnNpb24gMS4xClNlcmlhbDogODI1MC8xNjU1
MCBkcml2ZXIsIDQgcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQKc2VyaWFsODI1MDogdHR5UzAg
YXQgSS9PIDB4M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQowMDowYTogdHR5UzAgYXQgSS9PIDB4
M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQpicmQ6IG1vZHVsZSBsb2FkZWQKbG9vcDogbW9kdWxl
IGxvYWRlZAppbnB1dDogTWFjaW50b3NoIG1vdXNlIGJ1dHRvbiBlbXVsYXRpb24gYXMgL2Rldmlj
ZXMvdmlydHVhbC9pbnB1dC9pbnB1dDIKRml4ZWQgTURJTyBCdXM6IHByb2JlZAplaGNpX2hjZDog
VVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJpdmVyCm9oY2lfaGNk
OiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcgp1aGNpX2hjZDog
VVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlIGRyaXZlcgogIGFsbG9jIGly
cV9kZXNjIGZvciAyMyBvbiBub2RlIC0xCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCnVo
Y2lfaGNkIDAwMDA6MDA6MDEuMjogUENJIElOVCBEIC0+IEdTSSAyMyAobGV2ZWwsIGxvdykgLT4g
SVJRIDIzCnVoY2lfaGNkIDAwMDA6MDA6MDEuMjogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0
CnVoY2lfaGNkIDAwMDA6MDA6MDEuMjogVUhDSSBIb3N0IENvbnRyb2xsZXIKdWhjaV9oY2QgMDAw
MDowMDowMS4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEK
dWhjaV9oY2QgMDAwMDowMDowMS4yOiBpcnEgMjMsIGlvIGJhc2UgMHgwMDAwYzI0MAp1c2IgdXNi
MTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxCnVz
YiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxO
dW1iZXI9MQp1c2IgdXNiMTogUHJvZHVjdDogVUhDSSBIb3N0IENvbnRyb2xsZXIKdXNiIHVzYjE6
IE1hbnVmYWN0dXJlcjogTGludXggMi42LjMyLTIyMC43LjEuZWw2Lng4Nl82NCB1aGNpX2hjZAp1
c2IgdXNiMTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjAxLjIKdXNiIHVzYjE6IGNvbmZpZ3VyYXRp
b24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UKaHViIDEtMDoxLjA6IFVTQiBodWIgZm91bmQKaHVi
IDEtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKUE5QOiBQUy8yIENvbnRyb2xsZXIgW1BOUDAzMDM6
UFMySyxQTlAwZjEzOlBTMk1dIGF0IDB4NjAsMHg2NCBpcnEgMSwxMgpzZXJpbzogaTgwNDIgS0JE
IHBvcnQgYXQgMHg2MCwweDY0IGlycSAxCnNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4
NjQgaXJxIDEyCm1pY2U6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKcnRj
X2Ntb3MgMDA6MDU6IHJ0YyBjb3JlOiByZWdpc3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzAKcnRjMDog
YWxhcm1zIHVwIHRvIG9uZSBkYXksIDExNCBieXRlcyBudnJhbQpjcHVpZGxlOiB1c2luZyBnb3Zl
cm5vciBsYWRkZXIKY3B1aWRsZTogdXNpbmcgZ292ZXJub3IgbWVudQppbnB1dDogQVQgVHJhbnNs
YXRlZCBTZXQgMiBrZXlib2FyZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5w
dXQvaW5wdXQzCnVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaGlkZGV2
CnVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkCnVzYmhpZDog
djIuNjpVU0IgSElEIGNvcmUgZHJpdmVyClRDUCBjdWJpYyByZWdpc3RlcmVkCkluaXRpYWxpemlu
ZyBYRlJNIG5ldGxpbmsgc29ja2V0Ck5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcK
cmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAxClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJp
dmVyOiBkZXZpY2UvdmZiLzAKWEVOQlVTOiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS92
YmQvNzY4ClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmJkLzU2MzIKWEVO
QlVTOiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS92aWYvMApYRU5CVVM6IERldmljZSB3
aXRoIG5vIGRyaXZlcjogZGV2aWNlL3BjaS8wClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVy
OiBkZXZpY2UvY29uc29sZS8wCnJ0Y19jbW9zIDAwOjA1OiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0
byAyMDEyLTA0LTExIDE4OjQzOjUxIFVUQyAoMTMzNDE2OTgzMSkKSW5pdGFsaXppbmcgbmV0d29y
ayBkcm9wIG1vbml0b3Igc2VydmljZQpGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMjQ0
ayBmcmVlZApXcml0ZSBwcm90ZWN0aW5nIHRoZSBrZXJuZWwgcmVhZC1vbmx5IGRhdGE6IDEwMjQw
awpGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMDQwayBmcmVlZApGcmVlaW5nIHVudXNl
ZCBrZXJuZWwgbWVtb3J5OiAxNzU2ayBmcmVlZApkcmFjdXQ6IGRyYWN1dC0wMDQtMjU2LmVsNl8y
LjEKZHJhY3V0OiByZF9OT19MVUtTOiByZW1vdmluZyBjcnlwdG9sdWtzIGFjdGl2YXRpb24KZHJh
Y3V0OiByZF9OT19MVk06IHJlbW92aW5nIExWTSBhY3RpdmF0aW9uCmRldmljZS1tYXBwZXI6IHVl
dmVudDogdmVyc2lvbiAxLjAuMwpkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4yMi42LWlvY3RsICgy
MDExLTEwLTE5KSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNvbQp1ZGV2OiBzdGFydGlu
ZyB2ZXJzaW9uIDE0NwpkcmFjdXQ6IFN0YXJ0aW5nIHBseW1vdXRoIGRhZW1vbgpkcmFjdXQ6IHJk
X05PX0RNOiByZW1vdmluZyBETSBSQUlEIGFjdGl2YXRpb24KZHJhY3V0OiByZF9OT19NRDogcmVt
b3ZpbmcgTUQgUkFJRCBhY3RpdmF0aW9uCnhsYmxrX2luaXQ6IHJlZ2lzdGVyX2Jsa2RldiBtYWpv
cjogMjAyIAogIGFsbG9jIGlycV9kZXNjIGZvciAxNyBvbiBub2RlIDAKICBhbGxvYyBrc3RhdF9p
cnFzIG9uIG5vZGUgMAp2YmQgdmJkLTU2MzI6IDE5IHhlbmJ1c19kZXZfcHJvYmUgb24gZGV2aWNl
L3ZiZC81NjMyCmJsa2Zyb250OiB4dmRhOiBiYXJyaWVycyBkaXNhYmxlZAogeHZkYTogeHZkYTEg
eHZkYTIKdXNiIDEtMjogbmV3IGZ1bGwgc3BlZWQgVVNCIGRldmljZSB1c2luZyB1aGNpX2hjZCBh
bmQgYWRkcmVzcyAyCm1wdDJzYXMgdmVyc2lvbiAwOS4xMDEuMDAuMDAgbG9hZGVkCnNjc2kwIDog
RnVzaW9uIE1QVCBTQVMgSG9zdAogIGFsbG9jIGlycV9kZXNjIGZvciAzNiBvbiBub2RlIC0xCiAg
YWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCm1wdDJzYXMgMDAwMDowMDowNS4wOiBQQ0kgSU5U
IEEgLT4gR1NJIDM2IChsZXZlbCwgbG93KSAtPiBJUlEgMzYKbXB0MnNhcyAwMDAwOjAwOjA1LjA6
IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NAptcHQyc2FzMDogMzIgQklUIFBDSSBCVVMgRE1B
IEFERFJFU1NJTkcgU1VQUE9SVEVELCB0b3RhbCBtZW0gKDIwNTMzNzYga0IpCiAgYWxsb2MgaXJx
X2Rlc2MgZm9yIDQ4IG9uIG5vZGUgLTEKICBhbGxvYyBrc3RhdF9pcnFzIG9uIG5vZGUgLTEKbXB0
MnNhcyAwMDAwOjAwOjA1LjA6IGlycSA0OCBmb3IgTVNJL01TSS1YCm1wdDJzYXMwOiBQQ0ktTVNJ
LVggZW5hYmxlZDogSVJRIDQ4Cm1wdDJzYXMwOiBpb21lbSgweDAwMDAwMDAwZjMwZTAwMDApLCBt
YXBwZWQoMHhmZmZmYzkwMDAwOWU4MDAwKSwgc2l6ZSgxNjM4NCkKbXB0MnNhczA6IGlvcG9ydCgw
eDAwMDAwMDAwMDAwMGMxMDApLCBzaXplKDI1NikKaW5wdXQ6IEltRXhQUy8yIEdlbmVyaWMgRXhw
bG9yZXIgTW91c2UgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2VyaW8xL2lucHV0L2lucHV0
NAptcHQyc2FzMDogQWxsb2NhdGVkIHBoeXNpY2FsIG1lbW9yeTogc2l6ZSgyNjg4IGtCKQptcHQy
c2FzMDogQ3VycmVudCBDb250cm9sbGVyIFF1ZXVlIERlcHRoKDE3NTQpLCBNYXggQ29udHJvbGxl
ciBRdWV1ZSBEZXB0aCgyMDE1KQptcHQyc2FzMDogU2NhdHRlciBHYXRoZXIgRWxlbWVudHMgcGVy
IElPKDEyOCkKUmVmaW5lZCBUU0MgY2xvY2tzb3VyY2UgY2FsaWJyYXRpb246IDMxOTIuNzUwIE1I
ei4KU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHRzYwp1c2IgMS0yOiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MDYyNywgaWRQcm9kdWN0PTAwMDEKdXNiIDEtMjogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKdXNiIDEtMjogUHJv
ZHVjdDogUUVNVSBVU0IgVGFibGV0CnVzYiAxLTI6IE1hbnVmYWN0dXJlcjogUUVNVSAwLjEwLjIK
dXNiIDEtMjogU2VyaWFsTnVtYmVyOiAxCnVzYiAxLTI6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2Vu
IGZyb20gMSBjaG9pY2UKaW5wdXQ6IFFFTVUgMC4xMC4yIFFFTVUgVVNCIFRhYmxldCBhcyAvZGV2
aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MDEuMi91c2IxLzEtMi8xLTI6MS4wL2lucHV0L2lucHV0
NQpnZW5lcmljLXVzYiAwMDAzOjA2Mjc6MDAwMS4wMDAxOiBpbnB1dCxoaWRyYXcwOiBVU0IgSElE
IHYwLjAxIFBvaW50ZXIgW1FFTVUgMC4xMC4yIFFFTVUgVVNCIFRhYmxldF0gb24gdXNiLTAwMDA6
MDA6MDEuMi0yL2lucHV0MAptcHQyc2FzMDogX2Jhc2VfZXZlbnRfbm90aWZpY2F0aW9uOiB0aW1l
b3V0Cm1mOgoJMDcwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMGYy
ZjdmZmYgZmZmZmZmZmMgZmZmZmZmZmYgCglmZmZmZmZmZiAwMDAwMDAwMCAwMDAwMDAwMCAKbXB0
MnNhczA6IHNlbmRpbmcgZGlhZyByZXNldCAhIQptcHQyc2FzMDogZGlhZyByZXNldDogU1VDQ0VT
UwptcHQyc2FzIDAwMDA6MDA6MDUuMDogUENJIElOVCBBIGRpc2FibGVkCm1wdDJzYXMwOiBmYWls
dXJlIGF0IGRyaXZlcnMvc2NzaS9tcHQyc2FzL21wdDJzYXNfc2NzaWguYzo3NjI4L19zY3NpaF9w
cm9iZSgpIQphdGFfcGlpeCAwMDAwOjAwOjAxLjE6IHZlcnNpb24gMi4xMwphdGFfcGlpeCAwMDAw
OjAwOjAxLjE6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApzY3NpMSA6IGF0YV9waWl4CnNj
c2kyIDogYXRhX3BpaXgKYXRhMTogUEFUQSBtYXggTVdETUEyIGNtZCAweDFmMCBjdGwgMHgzZjYg
Ym1kbWEgMHhjMjYwIGlycSAxNAphdGEyOiBQQVRBIG1heCBNV0RNQTIgY21kIDB4MTcwIGN0bCAw
eDM3NiBibWRtYSAweGMyNjggaXJxIDE1CmF0YTIuMDE6IE5PREVWIGFmdGVyIHBvbGxpbmcgZGV0
ZWN0aW9uCmF0YTIuMDA6IEFUQVBJOiBRRU1VIERWRC1ST00sIDAuMTAuMiwgbWF4IFVETUEvMTAw
CmF0YTIuMDA6IGNvbmZpZ3VyZWQgZm9yIE1XRE1BMgpzY3NpIDI6MDowOjA6IENELVJPTSAgICAg
ICAgICAgIFFFTVUgICAgIFFFTVUgRFZELVJPTSAgICAgMC4xMCBQUTogMCBBTlNJOiA1CnNyMDog
c2NzaTMtbW1jIGRyaXZlOiA0eC80eCB4YS9mb3JtMiB0cmF5ClVuaWZvcm0gQ0QtUk9NIGRyaXZl
ciBSZXZpc2lvbjogMy4yMApzciAyOjA6MDowOiBBdHRhY2hlZCBzY3NpIENELVJPTSBzcjAKRVhU
NC1mcyAoeHZkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4g
T3B0czogCmRyYWN1dDogTW91bnRlZCByb290IGZpbGVzeXN0ZW0gL2Rldi94dmRhMQpkcmFjdXQ6
IExvYWRpbmcgU0VMaW51eCBwb2xpY3kKdHlwZT0xNDA0IGF1ZGl0KDEzMzQxNjk4NjMuNzQxOjIp
OiBlbmZvcmNpbmc9MSBvbGRfZW5mb3JjaW5nPTAgYXVpZD00Mjk0OTY3Mjk1IHNlcz00Mjk0OTY3
Mjk1ClNFTGludXg6IDIwNDggYXZ0YWIgaGFzaCBzbG90cywgMjI2MDA1IHJ1bGVzLgpTRUxpbnV4
OiAyMDQ4IGF2dGFiIGhhc2ggc2xvdHMsIDIyNjAwNSBydWxlcy4KU0VMaW51eDogIDkgdXNlcnMs
IDEyIHJvbGVzLCAzNTc4IHR5cGVzLCAxNzkgYm9vbHMsIDEgc2VucywgMTAyNCBjYXRzClNFTGlu
dXg6ICA4MSBjbGFzc2VzLCAyMjYwMDUgcnVsZXMKU0VMaW51eDogIENvbXBsZXRpbmcgaW5pdGlh
bGl6YXRpb24uClNFTGludXg6ICBTZXR0aW5nIHVwIGV4aXN0aW5nIHN1cGVyYmxvY2tzLgpTRUxp
bnV4OiBpbml0aWFsaXplZCAoZGV2IHh2ZGExLCB0eXBlIGV4dDQpLCB1c2VzIHhhdHRyClNFTGlu
dXg6IGluaXRpYWxpemVkIChkZXYgdG1wZnMsIHR5cGUgdG1wZnMpLCB1c2VzIHRyYW5zaXRpb24g
U0lEcwpTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IHVzYmZzLCB0eXBlIHVzYmZzKSwgdXNlcyBn
ZW5mc19jb250ZXh0cwpTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IHNlbGludXhmcywgdHlwZSBz
ZWxpbnV4ZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYg
bXF1ZXVlLCB0eXBlIG1xdWV1ZSksIHVzZXMgdHJhbnNpdGlvbiBTSURzClNFTGludXg6IGluaXRp
YWxpemVkIChkZXYgaHVnZXRsYmZzLCB0eXBlIGh1Z2V0bGJmcyksIHVzZXMgdHJhbnNpdGlvbiBT
SURzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgZGV2cHRzLCB0eXBlIGRldnB0cyksIHVzZXMg
dHJhbnNpdGlvbiBTSURzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgaW5vdGlmeWZzLCB0eXBl
IGlub3RpZnlmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRl
diBhbm9uX2lub2RlZnMsIHR5cGUgYW5vbl9pbm9kZWZzKSwgdXNlcyBnZW5mc19jb250ZXh0cwpT
RUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IHBpcGVmcywgdHlwZSBwaXBlZnMpLCB1c2VzIHRhc2sg
U0lEcwpTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGRlYnVnZnMsIHR5cGUgZGVidWdmcyksIHVz
ZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBzb2NrZnMsIHR5cGUg
c29ja2ZzKSwgdXNlcyB0YXNrIFNJRHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBkZXZ0bXBm
cywgdHlwZSBkZXZ0bXBmcyksIHVzZXMgdHJhbnNpdGlvbiBTSURzClNFTGludXg6IGluaXRpYWxp
emVkIChkZXYgdG1wZnMsIHR5cGUgdG1wZnMpLCB1c2VzIHRyYW5zaXRpb24gU0lEcwpTRUxpbnV4
OiBpbml0aWFsaXplZCAoZGV2IHByb2MsIHR5cGUgcHJvYyksIHVzZXMgZ2VuZnNfY29udGV4dHMK
U0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBiZGV2LCB0eXBlIGJkZXYpLCB1c2VzIGdlbmZzX2Nv
bnRleHRzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgcm9vdGZzLCB0eXBlIHJvb3RmcyksIHVz
ZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBzeXNmcywgdHlwZSBz
eXNmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKdHlwZT0xNDAzIGF1ZGl0KDEzMzQxNjk4NjQuMDcz
OjMpOiBwb2xpY3kgbG9hZGVkIGF1aWQ9NDI5NDk2NzI5NSBzZXM9NDI5NDk2NzI5NQpkcmFjdXQ6
IApkcmFjdXQ6IFN3aXRjaGluZyByb290CnJlYWRhaGVhZDogc3RhcnRpbmcKdWRldjogc3RhcnRp
bmcgdmVyc2lvbiAxNDcKc3IgMjowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0eXBl
IDUKcGlpeDRfc21idXMgMDAwMDowMDowMS4zOiBTTUJ1cyBiYXNlIGFkZHJlc3MgdW5pbml0aWFs
aXplZCAtIHVwZ3JhZGUgQklPUyBvciB1c2UgZm9yY2VfYWRkcj0weGFkZHIKSW5pdGlhbGlzaW5n
IFhlbiB2aXJ0dWFsIGV0aGVybmV0IGRyaXZlci4KICBhbGxvYyBpcnFfZGVzYyBmb3IgMTggb24g
bm9kZSAwCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKbWljcm9jb2RlOiBDUFUwIHNpZz0w
eDIwNmE3LCBwZj0weDIsIHJldmlzaW9uPTB4MWIKcGxhdGZvcm0gbWljcm9jb2RlOiBmaXJtd2Fy
ZTogcmVxdWVzdGluZyBpbnRlbC11Y29kZS8wNi0yYS0wNwptaWNyb2NvZGU6IENQVTEgc2lnPTB4
MjA2YTcsIHBmPTB4MiwgcmV2aXNpb249MHgxYgpwbGF0Zm9ybSBtaWNyb2NvZGU6IGZpcm13YXJl
OiByZXF1ZXN0aW5nIGludGVsLXVjb2RlLzA2LTJhLTA3Ck1pY3JvY29kZSBVcGRhdGUgRHJpdmVy
OiB2Mi4wMCA8dGlncmFuQGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmEKcGFycG9y
dF9wYyAwMDowYjogcmVwb3J0ZWQgYnkgUGx1ZyBhbmQgUGxheSBBQ1BJCnBhcnBvcnQwOiBQQy1z
dHlsZSBhdCAweDM3OCwgaXJxIDcgW1BDU1BQLFRSSVNUQVRFXQpwcGRldjogdXNlci1zcGFjZSBw
YXJhbGxlbCBwb3J0IGRyaXZlcgpBZGRpbmcgMTA0NzU0NGsgc3dhcCBvbiAvZGV2L3h2ZGEyLiAg
UHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczoxMDQ3NTQ0ayBTUwpTRUxpbnV4OiBpbml0aWFs
aXplZCAoZGV2IGJpbmZtdF9taXNjLCB0eXBlIGJpbmZtdF9taXNjKSwgdXNlcyBnZW5mc19jb250
ZXh0cwpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEwCmxvOiBEaXNhYmxlZCBQcml2
YWN5IEV4dGVuc2lvbnMKaXA2X3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBU
ZWFtCm5mX2Nvbm50cmFjayB2ZXJzaW9uIDAuNS4wICgxNjM4NCBidWNrZXRzLCA2NTUzNiBtYXgp
CmlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClJQQzogUmVnaXN0
ZXJlZCB1ZHAgdHJhbnNwb3J0IG1vZHVsZS4KUlBDOiBSZWdpc3RlcmVkIHRjcCB0cmFuc3BvcnQg
bW9kdWxlLgpSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNwb3J0
IG1vZHVsZS4KU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBycGNfcGlwZWZzLCB0eXBlIHJwY19w
aXBlZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgYXV0
b2ZzLCB0eXBlIGF1dG9mcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6
ZWQgKGRldiBhdXRvZnMsIHR5cGUgYXV0b2ZzKSwgdXNlcyBnZW5mc19jb250ZXh0cwpTRUxpbnV4
OiBpbml0aWFsaXplZCAoZGV2IGF1dG9mcywgdHlwZSBhdXRvZnMpLCB1c2VzIGdlbmZzX2NvbnRl
eHRzCmV0aDA6IG5vIElQdjYgcm91dGVycyBwcmVzZW50Cg==
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="pvhvm_lspci.txt"
Content-Disposition: attachment; filename="pvhvm_lspci.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6hb3

MDA6MDAuMCBIb3N0IGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gNDQwRlggLSA4MjQ0MUZYIFBN
QyBbTmF0b21hXSAocmV2IDAyKQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFs
IG1hY2hpbmUKCVBoeXNpY2FsIFNsb3Q6IDAKCUZsYWdzOiBidXMgbWFzdGVyLCBmYXN0IGRldnNl
bCwgbGF0ZW5jeSAwCgowMDowMS4wIElTQSBicmlkZ2U6IEludGVsIENvcnBvcmF0aW9uIDgyMzcx
U0IgUElJWDMgSVNBIFtOYXRvbWEvVHJpdG9uIElJXQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMg
UWVtdSB2aXJ0dWFsIG1hY2hpbmUKCUZsYWdzOiBidXMgbWFzdGVyLCBtZWRpdW0gZGV2c2VsLCBs
YXRlbmN5IDAKCjAwOjAxLjEgSURFIGludGVyZmFjZTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFT
QiBQSUlYMyBJREUgW05hdG9tYS9Ucml0b24gSUldIChwcm9nLWlmIDgwIFtNYXN0ZXJdKQoJU3Vi
c3lzdGVtOiBYZW5Tb3VyY2UsIEluYy4gRGV2aWNlIDAwMDEKCUZsYWdzOiBidXMgbWFzdGVyLCBt
ZWRpdW0gZGV2c2VsLCBsYXRlbmN5IDY0CglbdmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMWYwICgz
Mi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThdCglbdmlydHVhbF0gTWVtb3J5IGF0IDAw
MDAwM2YwICh0eXBlIDMsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFdCglbdmlydHVhbF0gTWVt
b3J5IGF0IDAwMDAwMTcwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThdCglbdmly
dHVhbF0gTWVtb3J5IGF0IDAwMDAwMzcwICh0eXBlIDMsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXpl
PTFdCglJL08gcG9ydHMgYXQgYzI2MCBbc2l6ZT0xNl0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBh
dGFfcGlpeAoJS2VybmVsIG1vZHVsZXM6IGF0YV9nZW5lcmljLCBwYXRhX2FjcGksIGF0YV9waWl4
CgowMDowMS4yIFVTQiBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjM3MVNCIFBJSVgz
IFVTQiBbTmF0b21hL1RyaXRvbiBJSV0gKHJldiAwMSkgKHByb2ctaWYgMDAgW1VIQ0ldKQoJU3Vi
c3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFsIG1hY2hpbmUKCUZsYWdzOiBidXMgbWFz
dGVyLCBmYXN0IGRldnNlbCwgbGF0ZW5jeSA2NCwgSVJRIDIzCglJL08gcG9ydHMgYXQgYzI0MCBb
c2l6ZT0zMl0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB1aGNpX2hjZAoKMDA6MDEuMyBCcmlkZ2U6
IEludGVsIENvcnBvcmF0aW9uIDgyMzcxQUIvRUIvTUIgUElJWDQgQUNQSSAocmV2IDAxKQoJU3Vi
c3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFsIG1hY2hpbmUKCVBoeXNpY2FsIFNsb3Q6
IDEKCUZsYWdzOiBidXMgbWFzdGVyLCBmYXN0IGRldnNlbCwgbGF0ZW5jeSAwLCBJUlEgOQoJS2Vy
bmVsIG1vZHVsZXM6IGkyYy1waWl4NAoKMDA6MDIuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVy
OiBDaXJydXMgTG9naWMgR0QgNTQ0NiAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vi
c3lzdGVtOiBYZW5Tb3VyY2UsIEluYy4gRGV2aWNlIDAwMDEKCVBoeXNpY2FsIFNsb3Q6IDIKCUZs
YWdzOiBidXMgbWFzdGVyLCBmYXN0IGRldnNlbCwgbGF0ZW5jeSAwCglNZW1vcnkgYXQgZjAwMDAw
MDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dCglNZW1vcnkgYXQgZjMwZTQwMDAg
KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglFeHBhbnNpb24gUk9NIGF0IDx1
bmFzc2lnbmVkPiBbZGlzYWJsZWRdCglLZXJuZWwgbW9kdWxlczogY2lycnVzZmIKCjAwOjAzLjAg
VW5hc3NpZ25lZCBjbGFzcyBbZmY4MF06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZvcm0gRGV2
aWNlIChyZXYgMDEpCglTdWJzeXN0ZW06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZvcm0gRGV2
aWNlCglQaHlzaWNhbCBTbG90OiAzCglGbGFnczogYnVzIG1hc3RlciwgZmFzdCBkZXZzZWwsIGxh
dGVuY3kgMCwgSVJRIDI4CglJL08gcG9ydHMgYXQgYzAwMCBbc2l6ZT0yNTZdCglNZW1vcnkgYXQg
ZjIwMDAwMDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNk1dCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogeGVuLXBsYXRmb3JtLXBjaQoKMDA6MDUuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBj
b250cm9sbGVyOiBMU0kgTG9naWMgLyBTeW1iaW9zIExvZ2ljIFNBUzIwMDggUENJLUV4cHJlc3Mg
RnVzaW9uLU1QVCBTQVMtMiBbRmFsY29uXSAocmV2IDAzKQoJU3Vic3lzdGVtOiBMU0kgTG9naWMg
LyBTeW1iaW9zIExvZ2ljIERldmljZSAzMDIwCglQaHlzaWNhbCBTbG90OiA1CglGbGFnczogZmFz
dCBkZXZzZWwsIElSUSAzNgoJSS9PIHBvcnRzIGF0IGMxMDAgW3NpemU9MjU2XQoJTWVtb3J5IGF0
IGYzMGUwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2S10KCU1lbW9yeSBh
dCBmMzA4MDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZLXQoJRXhwYW5z
aW9uIFJPTSBhdCBmMzAwMDAwMCBbZGlzYWJsZWRdIFtzaXplPTUxMktdCglDYXBhYmlsaXRpZXM6
IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCUNhcGFiaWxpdGllczogWzY4XSBFeHBy
ZXNzIEVuZHBvaW50LCBNU0kgMDAKCUNhcGFiaWxpdGllczogW2QwXSBWaXRhbCBQcm9kdWN0IERh
dGEKCUNhcGFiaWxpdGllczogW2E4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsKCUNhcGFiaWxpdGllczogW2MwXSBNU0ktWDogRW5hYmxlLSBDb3VudD0xNSBNYXNrZWQt
CglLZXJuZWwgbW9kdWxlczogbXB0MnNhcwoK
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="xm_dmesg.txt"
Content-Disposition: attachment; filename="xm_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6hx4

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgXyAgIF9fX19fICAgICAgICAgICAgIF8gICAgICAg
ICAgICAgICAgICAgCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgLyB8IHxfX18gLyAgICBfIF9f
IF9fXy8gfCAgIF8gX18gIF8gX18gX19fIAogIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxfIHwgfCAg
IHxfIFwgX198ICdfXy8gX198IHxfX3wgJ18gXHwgJ19fLyBfIFwKICAvICBcICBfXy8gfCB8IHwg
fF9fICAgX3x8IHxfIF9fXykgfF9ffCB8IHwgKF9ffCB8X198IHxfKSB8IHwgfCAgX18vCiAvXy9c
X1xfX198X3wgfF98ICAgIHxffChfKV8oXylfX19fLyAgIHxffCAgXF9fX3xffCAgfCAuX18vfF98
ICBcX19ffAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHxffCAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24gNC4xLjMtcmMxLXByZSAoc2Fk
bUApIChnY2MgdmVyc2lvbiA0LjYuMyAoVWJ1bnR1L0xpbmFybyA0LjYuMy0xdWJ1bnR1NCkgKSBX
ZWQgQXByIDExIDAxOjU2OjQ0IEVEVCAyMDEyCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFdlZCBB
cHIgMDQgMTY6MDk6MjUgMjAxMiArMDEwMCAyMzI3Njo2ZjIyNDQzMWVjYTIKKFhFTikgQm9vdGxv
YWRlcjogR1JVQiAxLjk5LTIxdWJ1bnR1MgooWEVOKSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVy
IGRvbTBfbWVtPTEwMjRNIGRvbTBfbWF4X3ZjcHVzPTIgbG9nbHZsPWFsbCBndWVzdF9sb2dsdmw9
YWxsIGlvbW11PTEKKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBt
b2RlIDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJh
bnNmZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3Vu
ZCA3IE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCA2IEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1
cmVzCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAw
MDAwMDAwMDA4ZDAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA4ZDAwMCAtIDAwMDAwMDAw
MDAwYTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAx
MDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwYmU3YTUw
MDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwYmU3YTUwMDAgLSAwMDAwMDAwMGJlN2YxMDAwIChB
Q1BJIE5WUykKKFhFTikgIDAwMDAwMDAwYmU3ZjEwMDAgLSAwMDAwMDAwMGJlN2Y5MDAwIChBQ1BJ
IGRhdGEpCihYRU4pICAwMDAwMDAwMGJlN2Y5MDAwIC0gMDAwMDAwMDBiZjQ3NzAwMCAocmVzZXJ2
ZWQpCihYRU4pICAwMDAwMDAwMGJmNDc3MDAwIC0gMDAwMDAwMDBiZjQ3ODAwMCAoQUNQSSBOVlMp
CihYRU4pICAwMDAwMDAwMGJmNDc4MDAwIC0gMDAwMDAwMDBiZjQ4OTAwMCAocmVzZXJ2ZWQpCihY
RU4pICAwMDAwMDAwMGJmNDg5MDAwIC0gMDAwMDAwMDBiZjQ4YzAwMCAoQUNQSSBOVlMpCihYRU4p
ICAwMDAwMDAwMGJmNDhjMDAwIC0gMDAwMDAwMDBiZjRhZDAwMCAocmVzZXJ2ZWQpCihYRU4pICAw
MDAwMDAwMGJmNGFkMDAwIC0gMDAwMDAwMDBiZjRhZjAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAw
MDBiZjRhZjAwMCAtIDAwMDAwMDAwYmY1MDMwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBi
ZjUwMzAwMCAtIDAwMDAwMDAwYmY1MGQwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBiZjUw
ZDAwMCAtIDAwMDAwMDAwYmY1MzMwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBiZjUzMzAw
MCAtIDAwMDAwMDAwYmY1NzYwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBiZjU3NjAwMCAt
IDAwMDAwMDAwYmY4MDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAw
MDAwMGZlZDQwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmYwMDAwMDAgLSAwMDAwMDAw
MTAwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwNDQw
MDAwMDAwICh1c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRjA0NTAsIDAwMjQgKHIyIFNVUEVS
TSkKKFhFTikgQUNQSTogWFNEVCBCRTdGMTA4MCwgMDA3QyAocjEgU1VQRVJNIFNNQ0ktLU1CICAg
ICAgICAxIEFNSSAgICAgMTAwMTMpCihYRU4pIEFDUEk6IEZBQ1AgQkU3RjdGNDgsIDAwRjQgKHI0
IFNVUEVSTSBTTUNJLS1NQiAgICAgICAgMSBBTUkgICAgIDEwMDEzKQooWEVOKSBBQ1BJOiBEU0RU
IEJFN0YxMTg4LCA2REMwIChyMiBTVVBFUk0gU01DSS0tTUIgICAgICAgIDAgSU5UTCAyMDA1MTEx
NykKKFhFTikgQUNQSTogRkFDUyBCRjUwQUY4MCwgMDA0MAooWEVOKSBBQ1BJOiBBUElDIEJFN0Y4
MDQwLCAwMDkyIChyMyBTVVBFUk0gU01DSS0tTUIgICAgICAgIDEgQU1JICAgICAxMDAxMykKKFhF
TikgQUNQSTogU1NEVCBCRTdGODBEOCwgMDFENiAocjEgQU1JQ1BVICAgICBQUk9DICAgICAgICAx
IE1TRlQgIDMwMDAwMDEpCihYRU4pIEFDUEk6IE1DRkcgQkU3RjgyQjAsIDAwM0MgKHIxIFNVUEVS
TSBTTUNJLS1NQiAgICAgICAgMSBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBIUEVUIEJFN0Y4
MkYwLCAwMDM4IChyMSBTVVBFUk0gU01DSS0tTUIgICAgICAgIDEgQU1JLiAgICAgICAgNCkKKFhF
TikgQUNQSTogU1BNSSBCRTdGODMyOCwgMDA0MCAocjUgQSBNIEkgICBPRU1TUE1JICAgICAgICAw
IEFNSS4gICAgICAgIDApCihYRU4pIEFDUEk6IERNQVIgQkU3RjgzNjgsIDAwQjAgKHIxIEFMQVNL
QSAgICBBIE0gSSAgICAgICAgMSBJTlRMICAgICAgICAxKQooWEVOKSBBQ1BJOiBFSU5KIEJFN0Y4
NDE4LCAwMTMwIChyMSAgICBBTUkgQU1JIEVJTkogICAgICAgIDAgICAgICAgICAgICAgMCkKKFhF
TikgQUNQSTogRVJTVCBCRTdGODU0OCwgMDIxMCAocjEgIEFNSUVSIEFNSSBFUlNUICAgICAgICAw
ICAgICAgICAgICAgIDApCihYRU4pIEFDUEk6IEhFU1QgQkU3Rjg3NTgsIDAwQTggKHIxICAgIEFN
SSBBTUkgSEVTVCAgICAgICAgMCAgICAgICAgICAgICAwKQooWEVOKSBBQ1BJOiBCRVJUIEJFN0Y4
ODAwLCAwMDMwIChyMSAgICBBTUkgQU1JIEJFUlQgICAgICAgIDAgICAgICAgICAgICAgMCkKKFhF
TikgU3lzdGVtIFJBTTogMTYzNjFNQiAoMTY3NTQ0MjRrQikKKFhFTikgTm8gTlVNQSBjb25maWd1
cmF0aW9uIGZvdW5kCihYRU4pIEZha2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAw
MDAwNDQwMDAwMDAwCihYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCihYRU4pIGZvdW5kIFNN
UCBNUC10YWJsZSBhdCAwMDBmY2UwMAooWEVOKSBETUkgMi43IHByZXNlbnQuCihYRU4pIFVzaW5n
IEFQSUMgZHJpdmVyIGRlZmF1bHQKKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgK
KFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs0MDQsMF0sIHBtMXhfZXZ0WzQw
MCwwXQooWEVOKSBBQ1BJOiAzMi82NFggRkFDUyBhZGRyZXNzIG1pc21hdGNoIGluIEZBRFQgLSBi
ZjUwYWY4MC8wMDAwMDAwMDAwMDAwMDAwLCB1c2luZyAzMgooWEVOKSBBQ1BJOiAgICAgICAgICAg
ICAgICAgIHdha2V1cF92ZWNbYmY1MGFmOGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTogTG9j
YWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMwIDY6MTAgQVBJQyB2
ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDJd
IGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMiA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQooWEVOKSBQ
cm9jZXNzb3IgIzQgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgwNF0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICM2IDY6MTAg
QVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lk
WzB4MDFdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMSA2OjEwIEFQSUMgdmVyc2lvbiAyMQoo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQoo
WEVOKSBQcm9jZXNzb3IgIzMgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICM1
IDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxh
cGljX2lkWzB4MDddIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNyA2OjEwIEFQSUMgdmVyc2lv
biAyMQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHhmZl0gaGlnaCBlZGdlIGxpbnRb
MHgxXSkKKFhFTikgQUNQSTogSU9BUElDIChpZFsweDAwXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdz
aV9iYXNlWzBdKQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgMCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMwooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz
IDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQooWEVOKSBBQ1BJOiBJUlEwIHVz
ZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KKFhFTikg
QUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBG
bGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MKKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBi
YXNlOiAweGZlZDAwMDAwCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAw
MDAwMDAgc2VnbWVudCAwIGJ1c2VzIDAgLSAyNTUKKFhFTikgUENJOiBOb3QgdXNpbmcgTU1DT05G
SUcuCihYRU4pIEVSU1QgdGFibGUgaXMgaW52YWxpZAooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBm
b3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KKFhFTikgSVJRIGxpbWl0czogMjQgR1NJ
LCAxNTI4IE1TSS9NU0ktWAooWEVOKSBTd2l0Y2hlZCB0byBBUElDIGRyaXZlciB4MmFwaWNfY2x1
c3Rlci4KKFhFTikgVXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0
KQooWEVOKSBEZXRlY3RlZCAzMTkyLjgzOCBNSHogcHJvY2Vzc29yLgooWEVOKSBJbml0aW5nIG1l
bW9yeSBzaGFyaW5nLgooWEVOKSBtY2VfaW50ZWwuYzoxMTYyOiBNQ0EgQ2FwYWJpbGl0eTogQkNB
U1QgMSBTRVIgMCBDTUNJIDEgZmlyc3RiYW5rIDAgZXh0ZW5kZWQgTUNFIE1TUiAwCihYRU4pIElu
dGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQKKFhFTikgSW50ZWwgVlQtZCBTbm9v
cCBDb250cm9sIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIERvbTAgRE1BIFBhc3N0aHJv
dWdoIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIFF1ZXVlZCBJbnZhbGlkYXRpb24gZW5h
YmxlZC4KKFhFTikgSW50ZWwgVlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuYWJsZWQuCihYRU4p
IEludGVsIFZULWQgU2hhcmVkIEVQVCB0YWJsZXMgbm90IGVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0
dWFsaXNhdGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBFbmFi
bGVkIGRpcmVjdGVkIEVPSSB3aXRoIGlvYXBpY19hY2tfb2xkIG9uIQooWEVOKSBFTkFCTElORyBJ
Ty1BUElDIElSUXMKKFhFTikgIC0+IFVzaW5nIG9sZCBBQ0sgbWV0aG9kCihYRU4pIC4uVElNRVI6
IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9LTEKKFhFTikgVFNDIGRl
YWRsaW5lIHRpbWVyIGVuYWJsZWQKKFhFTikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQ
RVQKKFhFTikgQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFZNWDogU3Vw
cG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSAgLSBBUElDIE1NSU8gYWNjZXNzIHZpcnR1
YWxpc2F0aW9uCihYRU4pICAtIEFQSUMgVFBSIHNoYWRvdwooWEVOKSAgLSBFeHRlbmRlZCBQYWdl
IFRhYmxlcyAoRVBUKQooWEVOKSAgLSBWaXJ0dWFsLVByb2Nlc3NvciBJZGVudGlmaWVycyAoVlBJ
RCkKKFhFTikgIC0gVmlydHVhbCBOTUkKKFhFTikgIC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFw
CihYRU4pICAtIFVucmVzdHJpY3RlZCBHdWVzdAooWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCihY
RU4pIEhWTTogVk1YIGVuYWJsZWQKKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcg
KEhBUCkgZGV0ZWN0ZWQKKFhFTikgSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIKKFhFTikg
QnJvdWdodCB1cCA4IENQVXMKKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgbWNoZWNr
X3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgooWEVOKSAqKiogTE9B
RElORyBET01BSU4gMCAqKioKKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0
MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAg
LT4gMHgyMDYwMDAwCihYRU4pIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERv
bTAgYWxsb2MuOiAgIDAwMDAwMDA0MmMwMDAwMDAtPjAwMDAwMDA0MzAwMDAwMDAgKDIzNTUxNiBw
YWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwNDNkN2Zj
MDAwLT4wMDAwMDAwNDNmZmZmNjAwCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgoo
WEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MjA2MDAwMAoo
WEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MjA2MDAwMC0+ZmZmZmZmZmY4NDg2MzYwMAoo
WEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4NDg2NDAwMC0+ZmZmZmZmZmY4NGE2NDAwMAoo
WEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4NGE2NDAwMC0+ZmZmZmZmZmY4NGE2NDRiNAoo
WEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4NGE2NTAwMC0+ZmZmZmZmZmY4NGE4ZTAwMAoo
WEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NGE4ZTAwMC0+ZmZmZmZmZmY4NGE4ZjAwMAoo
WEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NGMwMDAwMAoo
WEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWNmYzIwMAooWEVOKSBEb20wIGhhcyBtYXhp
bXVtIDIgVkNQVXMKKFhFTikgU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uZG9uZS4KKFhFTikgWGVuIHRyYWNlIGJ1ZmZlcnM6IGRpc2FibGVk
CihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4p
IFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSAqKiogU2VyaWFsIGlucHV0
IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhl
bikKKFhFTikgRnJlZWQgMjE2a0IgaW5pdCBtZW1vcnkuCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAw
OjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDEuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAw
MDoxOS4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjFhLjAKKFhFTikgUENJIGFkZCBkZXZpY2Ug
MDA6MWMuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxYy40CihYRU4pIFBDSSBhZGQgZGV2aWNl
IDAwOjFkLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MWUuMAooWEVOKSBQQ0kgYWRkIGRldmlj
ZSAwMDoxZi4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjFmLjIKKFhFTikgUENJIGFkZCBkZXZp
Y2UgMDA6MWYuMwooWEVOKSBQQ0kgYWRkIGRldmljZSAwMTowMC4wCihYRU4pIFBDSSBhZGQgZGV2
aWNlIDAzOjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDQ6MDMuMAooWEVOKSBwaHlzZGV2LmM6
MTY0OiBkb20wOiB3cm9uZyBtYXBfcGlycSB0eXBlIDMKKFhFTikgSFZNMTogSFZNIExvYWRlcgoo
WEVOKSBIVk0xOiBEZXRlY3RlZCBYZW4gdjQuMS4zLXJjMS1wcmUKKFhFTikgSFZNMTogQ1BVIHNw
ZWVkIGlzIDMxOTMgTUh6CihYRU4pIEhWTTE6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZl
bnQgY2hhbm5lbCAzCihYRU4pIGlycS5jOjI2NDogRG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgMCAt
PiA1CihYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIGlycS5j
OjI2NDogRG9tMSBQQ0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAooWEVOKSBIVk0xOiBQQ0ktSVNB
IGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKKFhFTikgaXJxLmM6MjY0OiBEb20xIFBDSSBsaW5rIDIg
Y2hhbmdlZCAwIC0+IDExCihYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlEx
MQooWEVOKSBpcnEuYzoyNjQ6IERvbTEgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooWEVOKSBI
Vk0xOiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooWEVOKSBIVk0xOiBwY2kgZGV2IDAx
OjIgSU5URC0+SVJRNQooWEVOKSBIVk0xOiBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKKFhFTikg
SFZNMTogcGNpIGRldiAwMzowIElOVEEtPklSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwNDowIElO
VEEtPklSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwNTowIElOVEEtPklSUTEwCihYRU4pIEhWTTE6
IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6ZSAwMjAwMDAwMDogZjAwMDAwMDgKKFhFTikgSFZNMTog
cGNpIGRldiAwMzowIGJhciAxNCBzaXplIDAxMDAwMDAwOiBmMjAwMDAwOAooWEVOKSBIVk0xOiBw
Y2kgZGV2IDA1OjAgYmFyIDMwIHNpemUgMDAwODAwMDA6IGYzMDAwMDAwCihYRU4pIGRvbWN0bC5j
Ojk4NTpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYzMDgwIG1mbj1mYmE4MCBucl9tZm5zPTQwCihY
RU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMWMgc2l6ZSAwMDA0MDAwMDogZjMwODAwMDQKKFhF
TikgSFZNMTogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDIwMDAwOiBmMzBjMDAwMAooWEVO
KSBkb21jdGwuYzo5ODU6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMzBlMCBtZm49ZmJhYzAgbnJf
bWZucz00CihYRU4pIGRvbWN0bC5jOjk5NTpkMCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYzMGUy
IG1mbj1mYmFjMiBucl9tZm5zPTEKKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxNCBzaXpl
IDAwMDA0MDAwOiBmMzBlMDAwNAooWEVOKSBIVk0xOiBwY2kgZGV2IDAyOjAgYmFyIDE0IHNpemUg
MDAwMDEwMDA6IGYzMGU0MDAwCihYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAw
MDAwMDEwMDogMDAwMGMwMDEKKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxMCBzaXplIDAw
MDAwMTAwOiAwMDAwYzEwMQooWEVOKSBkb21jdGwuYzoxMDQxOmQwIGlvcG9ydF9tYXA6YWRkIGZf
Z3BvcnQ9YzEwMCBmX21wb3J0PWUwMDAgbnA9MTAwCihYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBi
YXIgMTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMyMDEKKFhFTikgSFZNMTogcGNpIGRldiAwMToyIGJh
ciAyMCBzaXplIDAwMDAwMDIwOiAwMDAwYzI0MQooWEVOKSBIVk0xOiBwY2kgZGV2IDAxOjEgYmFy
IDIwIHNpemUgMDAwMDAwMTA6IDAwMDBjMjYxCihYRU4pIEhWTTE6IE11bHRpcHJvY2Vzc29yIGlu
aXRpYWxpc2F0aW9uOgooWEVOKSBIVk0xOiAgLSBDUFUwIC4uLiAzNi1iaXQgcGh5cyAuLi4gZml4
ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4KKFhFTikgSFZNMTogIC0gQ1BV
MSAuLi4gMzYtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4u
IGRvbmUuCihYRU4pIEhWTTE6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKFhFTikgSFZNMTog
TG9hZGluZyBST01CSU9TIC4uLgooWEVOKSBIVk0xOiAxMjgyOCBieXRlcyBvZiBST01CSU9TIGhp
Z2gtbWVtb3J5IGV4dGVuc2lvbnM6CihYRU4pIEhWTTE6ICAgUmVsb2NhdGluZyB0byAweGZjMDAw
MDAwLTB4ZmMwMDMyMWMgLi4uIGRvbmUKKFhFTikgSFZNMTogQ3JlYXRpbmcgTVAgdGFibGVzIC4u
LgooWEVOKSBIVk0xOiBMb2FkaW5nIENpcnJ1cyBWR0FCSU9TIC4uLgooWEVOKSBIVk0xOiBMb2Fk
aW5nIFBDSSBPcHRpb24gUk9NIC4uLgooWEVOKSBIVk0xOiAgLSBNYW51ZmFjdHVyZXI6IGh0dHA6
Ly9pcHhlLm9yZwooWEVOKSBIVk0xOiAgLSBQcm9kdWN0IG5hbWU6IGlQWEUKKFhFTikgZG9tY3Rs
LmM6OTg1OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjMwMDAgbWZuPWZiYTAwIG5yX21mbnM9ODAK
KFhFTikgSFZNMTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4KKFhFTikgSFZNMTogIC0gTWFu
dWZhY3R1cmVyOiBMU0kgQ29ycG9yYXRpb24KKFhFTikgSFZNMTogIC0gUHJvZHVjdCBuYW1lOiBM
U0kgTVBJIEJvb3QgU3VwcG9ydAooWEVOKSBkb21jdGwuYzo5OTU6ZDAgbWVtb3J5X21hcDpyZW1v
dmU6IGdmbj1mMzAwMCBtZm49ZmJhMDAgbnJfbWZucz04MAooWEVOKSBIVk0xOiBMb2FkaW5nIEFD
UEkgLi4uCihYRU4pIEhWTTE6ICAtIExvIGRhdGE6IDAwMGVhMDIwLTAwMGVhMDRmCihYRU4pIEhW
TTE6ICAtIEhpIGRhdGE6IGZjMDAzNDAwLWZjMDEzNTFmCihYRU4pIEhWTTE6IHZtODYgVFNTIGF0
IGZjMDEzODAwCihYRU4pIEhWTTE6IEJJT1MgbWFwOgooWEVOKSBIVk0xOiAgYzAwMDAtYzhmZmY6
IFZHQSBCSU9TCihYRU4pIEhWTTE6ICBjOTAwMC1kYTdmZjogRXRoZXJib290IFJPTQooWEVOKSBI
Vk0xOiAgZGE4MDAtZTY3ZmY6IFBDSSBPcHRpb24gUk9NcwooWEVOKSBIVk0xOiAgZWIwMDAtZWIx
ODE6IFNNQklPUyB0YWJsZXMKKFhFTikgSFZNMTogIGYwMDAwLWZmZmZmOiBNYWluIEJJT1MKKFhF
TikgSFZNMTogRTgyMCB0YWJsZToKKFhFTikgSFZNMTogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAw
IC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQooWEVOKSBIVk0xOiAgWzAxXTogMDAwMDAwMDA6MDAw
OWUwMDAgLSAwMDAwMDAwMDowMDA5ZmMwMDogUkVTRVJWRUQKKFhFTikgSFZNMTogIFswMl06IDAw
MDAwMDAwOjAwMDlmYzAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VSVkVECihYRU4pIEhWTTE6
ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUwMDAwCihYRU4pIEhWTTE6
ICBbMDNdOiAwMDAwMDAwMDowMDBlMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRAoo
WEVOKSBIVk0xOiAgWzA0XTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDo4MDAwMDAwMDog
UkFNCihYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDo4MDAwMDAwMCAtIDAwMDAwMDAwOmZjMDAw
MDAwCihYRU4pIEhWTTE6ICBbMDVdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAw
MDAwOiBSRVNFUlZFRAooWEVOKSBIVk0xOiBJbnZva2luZyBST01CSU9TIC4uLgooWEVOKSBIVk0x
OiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAooWEVOKSBz
dGR2Z2EuYzoxNDc6ZDEgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihYRU4pIEhW
TTE6IFZHQUJpb3MgJElkOiB2Z2FiaW9zLmMsdiAxLjY3IDIwMDgvMDEvMjcgMDk6NDQ6MTIgdnJ1
cHBlcnQgRXhwICQKKFhFTikgSFZNMTogQm9jaHMgQklPUyAtIGJ1aWxkOiAwNi8yMy85OQooWEVO
KSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAoo
WEVOKSBIVk0xOiBPcHRpb25zOiBhcG1iaW9zIHBjaWJpb3MgZWx0b3JpdG8gUE1NIAooWEVOKSBI
Vk0xOiAKKFhFTikgSFZNMTogYXRhMC0wOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxi
YSBMQ0hTPTEwMjQvMjU1LzYzCihYRU4pIEhWTTE6IGF0YTAgbWFzdGVyOiBRRU1VIEhBUkRESVNL
IEFUQS03IEhhcmQtRGlzayAoMTAyNDAgTUJ5dGVzKQooWEVOKSBIVk0xOiBJREUgdGltZSBvdXQK
KFhFTikgSFZNMTogYXRhMSBtYXN0ZXI6IFFFTVUgRFZELVJPTSBBVEFQSS00IENELVJvbS9EVkQt
Um9tCihYRU4pIEhWTTE6IElERSB0aW1lIG91dAooWEVOKSBIVk0xOiAKKFhFTikgdHJhcHMuYzo0
NTE6ZDAgVW5oYW5kbGVkIG5taSBmYXVsdC90cmFwIFsjMl0gb24gVkNQVSAwIFtlYz0wMDAwXQoo
WEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA3MCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVO
KSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA3MiBub3QgZm91bmQgYXQgaW5kZXggMQooWEVOKSBI
Vk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA3NCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0x
OiBQQ0kgZGV2aWNlIDEwMDA6MDA3NiBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQ
Q0kgZGV2aWNlIDEwMDA6MDA3NyBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kg
ZGV2aWNlIDEwMDA6MDA2NCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2
aWNlIDEwMDA6MDA2NSBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNl
IDEwMDA6MDA4MCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEw
MDA6MDA4MSBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6
MDA4MiBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4
MyBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NCBu
b3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NSBub3Qg
Zm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NiBub3QgZm91
bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NyBub3QgZm91bmQg
YXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA2ZSBub3QgZm91bmQgYXQg
aW5kZXggMAooWEVOKSBIVk0xOiAKKFhFTikgSFZNMTogCihYRU4pIEhWTTE6IFByZXNzIEYxMiBm
b3IgYm9vdCBtZW51LgooWEVOKSBIVk0xOiAKKFhFTikgSFZNMTogQm9vdGluZyBmcm9tIEhhcmQg
RGlzay4uLgooWEVOKSBIVk0xOiBCb290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIEhWTTE6IGlu
dDEzX2hhcmRkaXNrOiBmdW5jdGlvbiA0MSwgdW5tYXBwZWQgZGV2aWNlIGZvciBFTERMPTgxCihY
RU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBmdW5jdGlvbiAwOCwgdW5tYXBwZWQgZGV2aWNlIGZv
ciBFTERMPTgxCihYRU4pIEhWTTE6ICoqKiBpbnQgMTVoIGZ1bmN0aW9uIEFYPTAwYzAsIEJYPTAw
MDAgbm90IHlldCBzdXBwb3J0ZWQhCihYRU4pIEhWTTE6ICoqKiBpbnQgMTVoIGZ1bmN0aW9uIEFY
PWVjMDAsIEJYPTAwMDIgbm90IHlldCBzdXBwb3J0ZWQhCihYRU4pIEhWTTE6IEtCRDogdW5zdXBw
b3J0ZWQgaW50IDE2aCBmdW5jdGlvbiAwMwooWEVOKSBIVk0xOiAqKiogaW50IDE1aCBmdW5jdGlv
biBBWD1lOTgwLCBCWD0wMDAwIG5vdCB5ZXQgc3VwcG9ydGVkIQooWEVOKSBIVk0xOiBpbnQxM19o
YXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBI
Vk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxE
TD04MQooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRl
dmljZSBmb3IgRUxETD04MgooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIs
IHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MgooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazog
ZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MwooWEVOKSBIVk0xOiBpbnQx
M19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MwooWEVO
KSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3Ig
RUxETD04NAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVk
IGRldmljZSBmb3IgRUxETD04NAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24g
NDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04NQooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlz
azogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04NQooWEVOKSBIVk0xOiBp
bnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04Ngoo
WEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBm
b3IgRUxETD04NgooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFw
cGVkIGRldmljZSBmb3IgRUxETD04NwooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rp
b24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04NwooWEVOKSBIVk0xOiBpbnQxM19oYXJk
ZGlzazogZnVuY3Rpb24gNDEsIEVMREwgb3V0IG9mIHJhbmdlIDg4CihYRU4pIEhWTTE6IGludDEz
X2hhcmRkaXNrOiBmdW5jdGlvbiAwMiwgRUxETCBvdXQgb2YgcmFuZ2UgODgKKFhFTikgSFZNMTog
aW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQxLCBFTERMIG91dCBvZiByYW5nZSA4OQooWEVOKSBI
Vk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIEVMREwgb3V0IG9mIHJhbmdlIDg5CihY
RU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBmdW5jdGlvbiA0MSwgRUxETCBvdXQgb2YgcmFuZ2Ug
OGEKKFhFTikgSFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDAyLCBFTERMIG91dCBvZiBy
YW5nZSA4YQooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIEVMREwgb3V0
IG9mIHJhbmdlIDhiCihYRU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBmdW5jdGlvbiAwMiwgRUxE
TCBvdXQgb2YgcmFuZ2UgOGIKKFhFTikgSFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQx
LCBFTERMIG91dCBvZiByYW5nZSA4YwooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rp
b24gMDIsIEVMREwgb3V0IG9mIHJhbmdlIDhjCihYRU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBm
dW5jdGlvbiA0MSwgRUxETCBvdXQgb2YgcmFuZ2UgOGQKKFhFTikgSFZNMTogaW50MTNfaGFyZGRp
c2s6IGZ1bmN0aW9uIDAyLCBFTERMIG91dCBvZiByYW5nZSA4ZAooWEVOKSBIVk0xOiBpbnQxM19o
YXJkZGlzazogZnVuY3Rpb24gNDEsIEVMREwgb3V0IG9mIHJhbmdlIDhlCihYRU4pIEhWTTE6IGlu
dDEzX2hhcmRkaXNrOiBmdW5jdGlvbiAwMiwgRUxETCBvdXQgb2YgcmFuZ2UgOGUKKFhFTikgSFZN
MTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQxLCBFTERMIG91dCBvZiByYW5nZSA4ZgooWEVO
KSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIEVMREwgb3V0IG9mIHJhbmdlIDhm
CihYRU4pIGlycS5jOjMzMDogRG9tMSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVj
dG9yIDB4ZTkKKFhFTikgZG9tY3RsLmM6MTA2NTpkMCBpb3BvcnRfbWFwOnJlbW92ZSBmX2dwb3J0
PWMxMDAgZl9tcG9ydD1lMDAwIG5wPTEwMAooWEVOKSBkb21jdGwuYzoxMDQxOmQwIGlvcG9ydF9t
YXA6YWRkIGZfZ3BvcnQ9YzEwMCBmX21wb3J0PWUwMDAgbnA9MTAwCihYRU4pIGlycS5jOjI2NDog
RG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIGlycS5jOjI2NDogRG9tMSBQQ0kg
bGluayAxIGNoYW5nZWQgMTAgLT4gMAooWEVOKSBpcnEuYzoyNjQ6IERvbTEgUENJIGxpbmsgMiBj
aGFuZ2VkIDExIC0+IDAKKFhFTikgaXJxLmM6MjY0OiBEb20xIFBDSSBsaW5rIDMgY2hhbmdlZCA1
IC0+IDAK
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--485b393aaadf88221704bd6c92bc--


From xen-devel-bounces@lists.xen.org Wed Apr 11 19:52:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 19:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI3aQ-0007MV-8x; Wed, 11 Apr 2012 19:52:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <atarutin@orionsbelt.net>) id 1SI3aM-0007MN-KP
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 19:52:11 +0000
Received: from [85.158.143.35:40680] by server-3.bemta-4.messagelabs.com id
	1F/B2-05853-9E0E58F4; Wed, 11 Apr 2012 19:52:09 +0000
X-Env-Sender: atarutin@orionsbelt.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334173919!14099362!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10693 invoked from network); 11 Apr 2012 19:52:00 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 19:52:00 -0000
Received: by vbbfs19 with SMTP id fs19so1153605vbb.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 12:51:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=+zzlpDBP9c4CbcIxexmlwbfUNMfvdjAQp0028P+OydA=;
	b=MM1hH5pf3OlIs0bvaG5v6aaCeonjMrqbTwMSAyV/KfPm4XMzVRpPRrASWEVeSwoW5d
	vflfyTyj9BCd2MbKmCkMUd95PfFjKB6eV6mTH1jH0qsRaUHbl/aclOwAUT3KGsQTMkxf
	ogfldClqH3z7TUxxRic2D6wlT9gBfE47csEyLFtOAwvcbzUE7d5PXf449ol7VhP1Br3f
	XtEh0XLuK3D/6hKAd2hUK4jSMyj9BSkNVFtGy6acb7puGf1BCNCtswERDYfooB8U3YPJ
	O3K771WiLayIa6pvPfpt+1/xsDfwAI4UZZ1tjgGzYTNhAcQ1eEW+g3y9afhmLtLZ6plm
	fGwg==
Received: by 10.220.35.73 with SMTP id o9mr9064032vcd.74.1334173919355; Wed,
	11 Apr 2012 12:51:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.108.66 with HTTP; Wed, 11 Apr 2012 12:51:39 -0700 (PDT)
X-Originating-IP: [173.220.219.178]
From: Aleksandr Tarutin <atarutin@orionsbelt.net>
Date: Wed, 11 Apr 2012 15:51:39 -0400
Message-ID: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=485b393aaadf88221704bd6c92bc
X-Gm-Message-State: ALoCoQl+tceWkxUrnzdA5bzfHrzLsvSqNtFhgfh7ZGcW5Ub+IeRBhPEeZ322bE5j7TvbvUU3VlFV
Subject: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--485b393aaadf88221704bd6c92bc
Content-Type: multipart/alternative; boundary=485b393aaadf88220c04bd6c92ba

--485b393aaadf88220c04bd6c92ba
Content-Type: text/plain; charset=ISO-8859-1

Hello.

I tried to setup PCI Passthrough of a SAS controller into a PVHVM domU. The
device was present in the domU but its modules wouldn't load.

The first related thing was the following message in the guest BIOS just
before grub starts:
MPT BIOS Fault 09h encountered at adapter PCI(00h,05h,00h).

I'm attaching the xm dmesg and dmesg from both the host and a guest as well
as lspci -v.

-- 
AT.

--485b393aaadf88220c04bd6c92ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello.<div><br></div><div>I tried to setup PCI Passthrough of a SAS control=
ler into a PVHVM domU. The device was present in the domU but its modules w=
ouldn&#39;t load.</div><div><br></div><div>The first related thing was the =
following message in the guest BIOS just before grub starts:</div>

<div><div>MPT BIOS Fault 09h encountered at adapter=A0PCI(00h,05h,00h).</di=
v><div><br></div><div>I&#39;m attaching the xm dmesg and dmesg from both th=
e host and a guest as well as lspci -v.</div><div><br></div>-- <br><div>
AT.</div>
<br>
</div>

--485b393aaadf88220c04bd6c92ba--
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="dom0_dmesg.txt"
Content-Disposition: attachment; filename="dom0_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6940

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAgMC4w
MDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAwXSBMaW51
eCB2ZXJzaW9uIDMuMi4wLTIwLWdlbmVyaWMgKGJ1aWxkZEBhbGxzcGljZSkgKGdjYyB2ZXJzaW9u
IDQuNi4zIChVYnVudHUvTGluYXJvIDQuNi4zLTF1YnVudHUzKSApICMzMy1VYnVudHUgU01QIFR1
ZSBNYXIgMjcgMTY6NDI6MjYgVVRDIDIwMTIgKFVidW50dSAzLjIuMC0yMC4zMy1nZW5lcmljIDMu
Mi4xMikKWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9kZXYv
bWFwcGVyL1ZTeXN0ZW0wMS1sdlhlbjAyIHJvIGVhcmx5cHJpbnRrPXhlbiBpbml0Y2FsbF9kZWJ1
ZyBkZWJ1ZyBsb2dsZXZlbD0xMCBtc2k9MQpbICAgIDAuMDAwMDAwXSBLRVJORUwgc3VwcG9ydGVk
IGNwdXM6ClsgICAgMC4wMDAwMDBdICAgSW50ZWwgR2VudWluZUludGVsClsgICAgMC4wMDAwMDBd
ICAgQU1EIEF1dGhlbnRpY0FNRApbICAgIDAuMDAwMDAwXSAgIENlbnRhdXIgQ2VudGF1ckhhdWxz
ClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgIDhkLTEwMCBwZm4gcmFuZ2U6IDExNSBwYWdlcyBmcmVl
ZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiA4ZC0+MTAwClsgICAgMC4wMDAwMDBdIDEt
MSBtYXBwaW5nIG9uIGJlN2E1LT5iZjRhZApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBi
ZjRhZi0+YmY1NzYKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gYmY4MDAtPjEwMDAwMApb
ICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAxMTUgcGFnZXMgb2YgdW51c2VkIG1lbW9yeQpbICAgIDAu
MDAwMDAwXSBTZXQgMjY3ODQyIHBhZ2UocykgdG8gMS0xIG1hcHBpbmcKWyAgICAwLjAwMDAwMF0g
QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAw
MDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA4ZDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAg
WGVuOiAwMDAwMDAwMDAwMDhkMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpClsgICAg
MC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGJlN2E1MDAwICh1c2Fi
bGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYmU3YTUwMDAgLSAwMDAwMDAwMGJlN2Yx
MDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBiZTdmMTAwMCAtIDAw
MDAwMDAwYmU3ZjkwMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBi
ZTdmOTAwMCAtIDAwMDAwMDAwYmY0NzcwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVu
OiAwMDAwMDAwMGJmNDc3MDAwIC0gMDAwMDAwMDBiZjQ3ODAwMCAoQUNQSSBOVlMpClsgICAgMC4w
MDAwMDBdICBYZW46IDAwMDAwMDAwYmY0NzgwMDAgLSAwMDAwMDAwMGJmNDg5MDAwIChyZXNlcnZl
ZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBiZjQ4OTAwMCAtIDAwMDAwMDAwYmY0OGMw
MDAgKEFDUEkgTlZTKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmNDhjMDAwIC0gMDAw
MDAwMDBiZjRhZDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYmY0
YWQwMDAgLSAwMDAwMDAwMGJmNGFmMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAw
MDAwMDAwYmY0YWYwMDAgLSAwMDAwMDAwMGJmNTAzMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAw
MF0gIFhlbjogMDAwMDAwMDBiZjUwMzAwMCAtIDAwMDAwMDAwYmY1MGQwMDAgKEFDUEkgTlZTKQpb
ICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmNTBkMDAwIC0gMDAwMDAwMDBiZjUzMzAwMCAo
cmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYmY1MzMwMDAgLSAwMDAwMDAw
MGJmNTc2MDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBiZjU3NjAw
MCAtIDAwMDAwMDAwYmY4MDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAw
MDBmZWMwMDAwMCAtIDAwMDAwMDAwZmVjMDEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAg
WGVuOiAwMDAwMDAwMGZlZDFjMDAwIC0gMDAwMDAwMDBmZWQ0MDAwMCAocmVzZXJ2ZWQpClsgICAg
MC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNl
cnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZjAwMDAwMCAtIDAwMDAwMDAxMDAw
MDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0g
MDAwMDAwMDMwMTVjZjAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMzAx
NWNmMDAwIC0gMDAwMDAwMDQ0MDAwMDAwMCAodW51c2FibGUpClsgICAgMC4wMDAwMDBdIGJvb3Rj
b25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNh
YmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUKWyAgICAwLjAwMDAwMF0gRE1JIDIuNyBwcmVzZW50Lgpb
ICAgIDAuMDAwMDAwXSBETUk6IFN1cGVybWljcm8gWDlTQ0wvWDlTQ00vWDlTQ0wvWDlTQ00sIEJJ
T1MgMS4xYSAwOS8yOC8yMDExClsgICAgMC4wMDAwMDBdIGU4MjAgdXBkYXRlIHJhbmdlOiAwMDAw
MDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDAxMDAwMCAodXNhYmxlKSA9PT4gKHJlc2VydmVkKQpb
ICAgIDAuMDAwMDAwXSBlODIwIHJlbW92ZSByYW5nZTogMDAwMDAwMDAwMDBhMDAwMCAtIDAwMDAw
MDAwMDAxMDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZApb
ICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MzAxNWNmIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAw
MDAwClsgICAgMC4wMDAwMDBdIHgyYXBpYyBlbmFibGVkIGJ5IEJJT1MsIHN3aXRjaGluZyB0byB4
MmFwaWMgb3BzClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0gMHhiZjgwMCBtYXhfYXJjaF9wZm4g
PSAweDQwMDAwMDAwMApbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4
ODAwMDAwZmNlMDBdIGZjZTAwClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZCA6
IDAgLSAwNDg2NDAwMApbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtm
ZmZmODgwMDAwMDg4MDAwXSA4ODAwMCBzaXplIDIwNDgwClsgICAgMC4wMDAwMDBdIGluaXRfbWVt
b3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDBiZjgwMDAwMApbICAgIDAuMDAw
MDAwXSAgMDAwMDAwMDAwMCAtIDAwYmY4MDAwMDAgcGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJu
ZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIGJmODAwMDAwIEAgYTAwMDAwLTEwMDAwMDAK
WyAgICAwLjAwMDAwMF0geGVuOiBzZXR0aW5nIFJXIHRoZSByYW5nZSBmZDQwMDAgLSAxMDAwMDAw
ClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAxMDAwMDAwMDAtMDAw
MDAwMDMwMTVjZjAwMApbICAgIDAuMDAwMDAwXSAgMDEwMDAwMDAwMCAtIDAzMDE1Y2YwMDAgcGFn
ZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDMw
MTVjZjAwMCBAIDNlN2U3MDAwLTQwMDAwMDAwClsgICAgMC4wMDAwMDBdIHhlbjogc2V0dGluZyBS
VyB0aGUgcmFuZ2UgM2Y3ZmIwMDAgLSA0MDAwMDAwMApbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiAw
MjA2MDAwMCAtIDA0ODY0MDAwClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBm
MDQ1MCAwMDAyNCAodjAyIFNVUEVSTSkKWyAgICAwLjAwMDAwMF0gQUNQSTogWFNEVCAwMDAwMDAw
MGJlN2YxMDgwIDAwMDdDICh2MDEgU1VQRVJNIFNNQ0ktLU1CIDAwMDAwMDAxIEFNSSAgMDAwMTAw
MTMpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgMDAwMDAwMDBiZTdmN2Y0OCAwMDBGNCAodjA0
IFNVUEVSTSBTTUNJLS1NQiAwMDAwMDAwMSBBTUkgIDAwMDEwMDEzKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBEU0RUIDAwMDAwMDAwYmU3ZjExODggMDZEQzAgKHYwMiBTVVBFUk0gU01DSS0tTUIgMDAw
MDAwMDAgSU5UTCAyMDA1MTExNykKWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUyAwMDAwMDAwMGJm
NTBhZjgwIDAwMDQwClsgICAgMC4wMDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBiZTdmODA0MCAw
MDA5MiAodjAzIFNVUEVSTSBTTUNJLS1NQiAwMDAwMDAwMSBBTUkgIDAwMDEwMDEzKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYmU3ZjgwZDggMDAxRDYgKHYwMSBBTUlDUFUgICAg
IFBST0MgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkKWyAgICAwLjAwMDAwMF0gQUNQSTogTUNGRyAw
MDAwMDAwMGJlN2Y4MmIwIDAwMDNDICh2MDEgU1VQRVJNIFNNQ0ktLU1CIDAwMDAwMDAxIE1TRlQg
MDAwMDAwOTcpClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAwMDAwMDBiZTdmODJmMCAwMDAz
OCAodjAxIFNVUEVSTSBTTUNJLS1NQiAwMDAwMDAwMSBBTUkuIDAwMDAwMDA0KQpbICAgIDAuMDAw
MDAwXSBBQ1BJOiBTUE1JIDAwMDAwMDAwYmU3ZjgzMjggMDAwNDAgKHYwNSBBIE0gSSAgIE9FTVNQ
TUkgMDAwMDAwMDAgQU1JLiAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogWE1BUiAwMDAw
MDAwMGJlN2Y4MzY4IDAwMEIwICh2MDEgQUxBU0tBICAgIEEgTSBJIDAwMDAwMDAxIElOVEwgMDAw
MDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IEVJTkogMDAwMDAwMDBiZTdmODQxOCAwMDEzMCAo
djAxICAgIEFNSSBBTUkgRUlOSiAwMDAwMDAwMCAgICAgIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBFUlNUIDAwMDAwMDAwYmU3Zjg1NDggMDAyMTAgKHYwMSAgQU1JRVIgQU1JIEVSU1Qg
MDAwMDAwMDAgICAgICAwMDAwMDAwMCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSEVTVCAwMDAwMDAw
MGJlN2Y4NzU4IDAwMEE4ICh2MDEgICAgQU1JIEFNSSBIRVNUIDAwMDAwMDAwICAgICAgMDAwMDAw
MDApClsgICAgMC4wMDAwMDBdIEFDUEk6IEJFUlQgMDAwMDAwMDBiZTdmODgwMCAwMDAzMCAodjAx
ICAgIEFNSSBBTUkgQkVSVCAwMDAwMDAwMCAgICAgIDAwMDAwMDAwKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAwMDAwXSBTZXR0aW5n
IEFQSUMgcm91dGluZyB0byBjbHVzdGVyIHgyYXBpYy4KWyAgICAwLjAwMDAwMF0gTm8gTlVNQSBj
b25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgMDAwMDAw
MDAwMDAwMDAwMC0wMDAwMDAwMzAxNWNmMDAwClsgICAgMC4wMDAwMDBdIEluaXRtZW0gc2V0dXAg
bm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDMwMTVjZjAwMApbICAgIDAuMDAwMDAwXSAg
IE5PREVfREFUQSBbMDAwMDAwMDAzZmZmYjAwMCAtIDAwMDAwMDAwM2ZmZmZmZmZdClsgICAgMC4w
MDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAwMDAwMF0gICBETUEgICAgICAweDAwMDAw
MDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAweDAwMDAxMDAwIC0+
IDB4MDAxMDAwMDAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgICAweDAwMTAwMDAwIC0+IDB4MDAz
MDE1Y2YKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IFBGTiBmb3IgZWFjaCBub2Rl
ClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzVdIGFjdGl2ZSBQRk4gcmFuZ2VzClsgICAg
MC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwOGQKWyAgICAwLjAwMDAwMF0g
ICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDBiZTdhNQpbICAgIDAuMDAwMDAwXSAgICAgMDogMHgw
MDBiZjRhZCAtPiAweDAwMGJmNGFmClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMGJmNTc2IC0+
IDB4MDAwYmY4MDAKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAxMDAwMDAgLT4gMHgwMDMwMTVj
ZgpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMjg4MzQ1MwpbICAgIDAuMDAw
MDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0g
ICBETUEgem9uZTogMTQ5NyBwYWdlcyByZXNlcnZlZApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25l
OiAyNDA0IHBhZ2VzLCBMSUZPIGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAx
NjMyMCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA3
NjA0MzMgcGFnZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTog
MzI4NTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6
IDIwNjk4NzkgcGFnZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gQUNQSTogUE0tVGlt
ZXIgSU8gUG9ydDogMHg0MDgKWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNz
IDB4ZmVlMDAwMDAKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFw
aWNfaWRbMHgwMF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwM10g
ZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNf
aWRbMHgwNV0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
OF0gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1J
IChhY3BpX2lkWzB4ZmZdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6
IElPQVBJQyAoaWRbMHgwMF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKWyAgICAw
LjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDAsIHZlcnNpb24gMjU1LCBhZGRyZXNzIDB4ZmVj
MDAwMDAsIEdTSSAwLTI1NQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg
YnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRf
U1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJROSB1c2VkIGJ5
IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZp
Z3VyYXRpb24gaW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2
YTcwMSBiYXNlOiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDogQWxsb3dpbmcgOCBDUFVz
LCAwIGhvdHBsdWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogMjcyClsgICAgMC4w
MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOGQwMDAgLSAw
MDAwMDAwMDAwMTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IDAwMDAwMDAwYmU3YTUwMDAgLSAwMDAwMDAwMGJlN2YxMDAwClsgICAgMC4wMDAwMDBdIFBN
OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmU3ZjEwMDAgLSAwMDAwMDAwMGJl
N2Y5MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw
MDAwYmU3ZjkwMDAgLSAwMDAwMDAwMGJmNDc3MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl
cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY0NzcwMDAgLSAwMDAwMDAwMGJmNDc4MDAwClsg
ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY0Nzgw
MDAgLSAwMDAwMDAwMGJmNDg5MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IDAwMDAwMDAwYmY0ODkwMDAgLSAwMDAwMDAwMGJmNDhjMDAwClsgICAgMC4wMDAw
MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY0OGMwMDAgLSAwMDAw
MDAwMGJmNGFkMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IDAwMDAwMDAwYmY0YWYwMDAgLSAwMDAwMDAwMGJmNTAzMDAwClsgICAgMC4wMDAwMDBdIFBNOiBS
ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY1MDMwMDAgLSAwMDAwMDAwMGJmNTBk
MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw
YmY1MGQwMDAgLSAwMDAwMDAwMGJmNTMzMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVk
IG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY1MzMwMDAgLSAwMDAwMDAwMGJmNTc2MDAwClsgICAg
MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmY4MDAwMDAg
LSAwMDAwMDAwMGZlYzAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt
ZW1vcnk6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwClsgICAgMC4wMDAwMDBd
IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVjMDEwMDAgLSAwMDAwMDAw
MGZlZDFjMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAw
MDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDQwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdp
c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkNDAwMDAgLSAwMDAwMDAwMGZlZTAwMDAw
ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVl
MDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDEwMDAgLSAwMDAwMDAwMGZmMDAwMDAwClsgICAgMC4w
MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmYwMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBz
dGFydGluZyBhdCBiZjgwMDAwMCAoZ2FwOiBiZjgwMDAwMDozZjQwMDAwMCkKWyAgICAwLjAwMDAw
MF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpbICAgIDAuMDAwMDAwXSBY
ZW4gdmVyc2lvbjogNC4xLjMtcmMxLXByZSAocHJlc2VydmUtQUQpClsgICAgMC4wMDAwMDBdIHNl
dHVwX3BlcmNwdTogTlJfQ1BVUzoyNTYgbnJfY3B1bWFza19iaXRzOjI1NiBucl9jcHVfaWRzOjgg
bnJfbm9kZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2VzL2Nw
dSBAZmZmZjg4MDAzZmVjYTAwMCBzODMwNzIgcjgxOTIgZDIzNDI0IHUxMTQ2ODgKWyAgICAwLjAw
MDAwMF0gcGNwdS1hbGxvYzogczgzMDcyIHI4MTkyIGQyMzQyNCB1MTE0Njg4IGFsbG9jPTI4KjQw
OTYKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogWzBdIDAgWzBdIDEgWzBdIDIgWzBdIDMgWzBd
IDQgWzBdIDUgWzBdIDYgWzBdIDcgClsgICAgMy40MTEzOTFdIEJ1aWx0IDEgem9uZWxpc3RzIGlu
IFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDI4MzI3MTYK
WyAgICAzLjQxMTM5NF0gUG9saWN5IHpvbmU6IE5vcm1hbApbICAgIDMuNDExMzk2XSBLZXJuZWwg
Y29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9kZXYvbWFwcGVyL1ZTeXN0ZW0wMS1sdlhl
bjAyIHJvIGVhcmx5cHJpbnRrPXhlbiBpbml0Y2FsbF9kZWJ1ZyBkZWJ1ZyBsb2dsZXZlbD0xMCBt
c2k9MQpbICAgIDMuNDExODA2XSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjog
MywgMzI3NjggYnl0ZXMpClsgICAgMy40MzEzMzJdIFBsYWNpbmcgNjRNQiBzb2Z0d2FyZSBJTyBU
TEIgYmV0d2VlbiBmZmZmODgwMDJmMDAwMDAwIC0gZmZmZjg4MDAzMzAwMDAwMApbICAgIDMuNDMx
MzM2XSBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDJmMDAwMDAwIC0gMHgzMzAwMDAwMApbICAg
IDMuNDMzNTE4XSBNZW1vcnk6IDcxNjkyNGsvMTI2MDUyNDRrIGF2YWlsYWJsZSAoNjU2NWsga2Vy
bmVsIGNvZGUsIDEwNzE0MzJrIGFic2VudCwgMTA4MTY4ODhrIHJlc2VydmVkLCA2NjM5ayBkYXRh
LCA5MjBrIGluaXQpClsgICAgMy40MzM1ODVdIFNMVUI6IEdlbnNsYWJzPTE1LCBIV2FsaWduPTY0
LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BVcz04LCBOb2Rlcz0xClsgICAgMy40MzM2MDdd
IEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMy40MzM2MDldIAlSQ1UgZHlu
dGljay1pZGxlIGdyYWNlLXBlcmlvZCBhY2NlbGVyYXRpb24gaXMgZW5hYmxlZC4KWyAgICAzLjQz
MzYxNl0gTlJfSVJRUzoxNjY0MCBucl9pcnFzOjIwNDggMTYKWyAgICAzLjQzMzY3Ml0geGVuOiBz
Y2kgb3ZlcnJpZGU6IGdsb2JhbF9pcnE9OSB0cmlnZ2VyPTAgcG9sYXJpdHk9MApbICAgIDMuNDMz
Njc1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAwClsgICAg
My40MzM2ODNdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpClsgICAgMy40MzM3MTVd
IHhlbjogYWNwaSBzY2kgOQpbICAgIDMuNDMzNzE4XSB4ZW46IC0tPiBwaXJxPTEgLT4gaXJxPTEg
KGdzaT0xKQpbICAgIDMuNDMzNzIxXSB4ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIgKGdzaT0yKQpb
ICAgIDMuNDMzNzI0XSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQpbICAgIDMuNDMz
NzI3XSB4ZW46IC0tPiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQpbICAgIDMuNDMzNzMwXSB4ZW46
IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQpbICAgIDMuNDMzNzMzXSB4ZW46IC0tPiBwaXJx
PTYgLT4gaXJxPTYgKGdzaT02KQpbICAgIDMuNDMzNzM2XSB4ZW46IC0tPiBwaXJxPTcgLT4gaXJx
PTcgKGdzaT03KQpbICAgIDMuNDMzNzM4XSB4ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04
KQpbICAgIDMuNDMzNzQwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDkgZm9yIGdz
aSA5ClsgICAgMy40MzM3NDJdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpClsgICAg
My40MzM3NDVdIHhlbjogLS0+IHBpcnE9MTAgLT4gaXJxPTEwIChnc2k9MTApClsgICAgMy40MzM3
NDhdIHhlbjogLS0+IHBpcnE9MTEgLT4gaXJxPTExIChnc2k9MTEpClsgICAgMy40MzM3NTFdIHhl
bjogLS0+IHBpcnE9MTIgLT4gaXJxPTEyIChnc2k9MTIpClsgICAgMy40MzM3NTRdIHhlbjogLS0+
IHBpcnE9MTMgLT4gaXJxPTEzIChnc2k9MTMpClsgICAgMy40MzM3NTddIHhlbjogLS0+IHBpcnE9
MTQgLT4gaXJxPTE0IChnc2k9MTQpClsgICAgMy40MzM3NjBdIHhlbjogLS0+IHBpcnE9MTUgLT4g
aXJxPTE1IChnc2k9MTUpClsgICAgMy40MzY2MzRdIENvbnNvbGU6IGNvbG91ciBWR0ErIDgweDI1
ClsgICAgMy40MzY2MzddIGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQsIGJvb3Rjb25zb2xlIGRpc2Fi
bGVkClsgICAgMy40NDcyMDBdIGFsbG9jYXRlZCA5MzMyMzI2NCBieXRlcyBvZiBwYWdlX2Nncm91
cApbICAgIDMuNDQ3Mjg4XSBwbGVhc2UgdHJ5ICdjZ3JvdXBfZGlzYWJsZT1tZW1vcnknIG9wdGlv
biBpZiB5b3UgZG9uJ3Qgd2FudCBtZW1vcnkgY2dyb3VwcwpbICAgIDMuNDQ3NDA4XSBYZW46IHVz
aW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UKWyAgICAzLjQ0NzQ4N10gaW5zdGFsbGluZyBYZW4g
dGltZXIgZm9yIENQVSAwClsgICAgMy40NDc1OTFdIERldGVjdGVkIDMxOTIuODM4IE1IeiBwcm9j
ZXNzb3IuClsgICAgMy40NDc2NzRdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBwZWQpLCB2
YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDYzODUuNjcgQm9nb01JUFMg
KGxwaj0xMjc3MTM1MikKWyAgICAzLjQ0NzgzOV0gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWlu
aW11bTogMzAxClsgICAgMy40NDc5NDNdIFNlY3VyaXR5IEZyYW1ld29yayBpbml0aWFsaXplZApb
ICAgIDMuNDQ4MDI4XSBBcHBBcm1vcjogQXBwQXJtb3IgaW5pdGlhbGl6ZWQKWyAgICAzLjQ0ODEw
NF0gWWFtYTogYmVjb21pbmcgbWluZGZ1bC4KWyAgICAzLjQ1MjQ4M10gRGVudHJ5IGNhY2hlIGhh
c2ggdGFibGUgZW50cmllczogMjA5NzE1MiAob3JkZXI6IDEyLCAxNjc3NzIxNiBieXRlcykKWyAg
ICAzLjQ1Njc3MF0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAxMDQ4NTc2IChvcmRl
cjogMTEsIDgzODg2MDggYnl0ZXMpClsgICAgMy40NTc5MTNdIE1vdW50LWNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogMjU2ClsgICAgMy40NTgxMjddIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lz
IGNwdWFjY3QKWyAgICAzLjQ1ODIxMl0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgbWVtb3J5
ClsgICAgMy40NTgyOTddIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGRldmljZXMKWyAgICAz
LjQ1ODM3OV0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcgpbICAgIDMuNDU4NDYx
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBibGtpbwpbICAgIDMuNDU4NTQ2XSBJbml0aWFs
aXppbmcgY2dyb3VwIHN1YnN5cyBwZXJmX2V2ZW50ClsgICAgMy40NTg2NzldIEVORVJHWV9QRVJG
X0JJQVM6IFNldCB0byAnbm9ybWFsJywgd2FzICdwZXJmb3JtYW5jZScKWyAgICAzLjQ1ODY4MF0g
RU5FUkdZX1BFUkZfQklBUzogVmlldyBhbmQgdXBkYXRlIHdpdGggeDg2X2VuZXJneV9wZXJmX3Bv
bGljeSg4KQpbICAgIDMuNDU4ODgzXSBDUFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMApbICAg
IDMuNDU4OTc4XSBDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAwClsgICAgMy40NjA5OTNdIEFDUEk6
IENvcmUgcmV2aXNpb24gMjAxMTA2MjMKWyAgICAzLjY5MTE5Nl0gZnRyYWNlOiBhbGxvY2F0aW5n
IDI3MDQ5IGVudHJpZXMgaW4gMTA3IHBhZ2VzClsgICAgMy42OTg2MjZdIGNwdSAwIHNwaW5sb2Nr
IGV2ZW50IGlycSAyNzMKWyAgICAzLjY5ODc0OF0gY2FsbGluZyAgdHJhY2VfaW5pdF9mbGFnc19z
eXNfZXhpdCsweDAvMHgxMiBAIDEKWyAgICAzLjY5ODg1MV0gaW5pdGNhbGwgdHJhY2VfaW5pdF9m
bGFnc19zeXNfZXhpdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjY5
ODk3Nl0gY2FsbGluZyAgdHJhY2VfaW5pdF9mbGFnc19zeXNfZW50ZXIrMHgwLzB4MTIgQCAxClsg
ICAgMy42OTkwODBdIGluaXRjYWxsIHRyYWNlX2luaXRfZmxhZ3Nfc3lzX2VudGVyKzB4MC8weDEy
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNjk5MjA1XSBjYWxsaW5nICBpbml0X2h3
X3BlcmZfZXZlbnRzKzB4MC8weDg2IEAgMQpbICAgIDMuNjk5MzA2XSBQZXJmb3JtYW5jZSBFdmVu
dHM6IHVuc3VwcG9ydGVkIHA2IENQVSBtb2RlbCA0MiBubyBQTVUgZHJpdmVyLCBzb2Z0d2FyZSBl
dmVudHMgb25seS4KWyAgICAzLjY5OTU3OV0gaW5pdGNhbGwgaW5pdF9od19wZXJmX2V2ZW50cysw
eDAvMHg4NiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjY5OTY4M10gY2FsbGluZyAg
cmVnaXN0ZXJfdHJpZ2dlcl9hbGxfY3B1X2JhY2t0cmFjZSsweDAvMHgxZiBAIDEKWyAgICAzLjY5
OTc4OV0gaW5pdGNhbGwgcmVnaXN0ZXJfdHJpZ2dlcl9hbGxfY3B1X2JhY2t0cmFjZSsweDAvMHgx
ZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjY5OTkxNV0gY2FsbGluZyAgbnVtYWNo
aXBfc3lzdGVtX2luaXQrMHgwLzB4YTggQCAxClsgICAgMy43MDAwMTldIGluaXRjYWxsIG51bWFj
aGlwX3N5c3RlbV9pbml0KzB4MC8weGE4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
NzAwMTIyXSBjYWxsaW5nICBtaWdyYXRpb25faW5pdCsweDAvMHg2YyBAIDEKWyAgICAzLjcwMDIy
M10gaW5pdGNhbGwgbWlncmF0aW9uX2luaXQrMHgwLzB4NmMgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgMy43MDAzMjddIGNhbGxpbmcgIHNwYXduX2tzb2Z0aXJxZCsweDAvMHg1MyBAIDEK
WyAgICAzLjcwMDQ0M10gaW5pdGNhbGwgc3Bhd25fa3NvZnRpcnFkKzB4MC8weDUzIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAwNTQ3XSBjYWxsaW5nICBpbml0X3dvcmtxdWV1ZXMr
MHgwLzB4MmQ0IEAgMQpbICAgIDMuNzAwNjg5XSBpbml0Y2FsbCBpbml0X3dvcmtxdWV1ZXMrMHgw
LzB4MmQ0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAwNzk1XSBjYWxsaW5nICBj
cHVfc3RvcF9pbml0KzB4MC8weGFkIEAgMQpbICAgIDMuNzAwOTA3XSBpbml0Y2FsbCBjcHVfc3Rv
cF9pbml0KzB4MC8weGFkIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAxMDExXSBj
YWxsaW5nICByY3Vfc2NoZWR1bGVyX3JlYWxseV9zdGFydGVkKzB4MC8weDEyIEAgMQpbICAgIDMu
NzAxMTE0XSBpbml0Y2FsbCByY3Vfc2NoZWR1bGVyX3JlYWxseV9zdGFydGVkKzB4MC8weDEyIHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAxMjQzXSBjYWxsaW5nICByZWxheV9pbml0
KzB4MC8weDE0IEAgMQpbICAgIDMuNzAxMzQ0XSBpbml0Y2FsbCByZWxheV9pbml0KzB4MC8weDE0
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAxNDQ5XSBjYWxsaW5nICB0cmFjZXJf
YWxsb2NfYnVmZmVycysweDAvMHgxY2QgQCAxClsgICAgMy43MDE1NjZdIGluaXRjYWxsIHRyYWNl
cl9hbGxvY19idWZmZXJzKzB4MC8weDFjZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAz
LjcwMTY3Ml0gY2FsbGluZyAgaW5pdF90cmFjZV9wcmludGsrMHgwLzB4MTIgQCAxClsgICAgMy43
MDE3NzFdIGluaXRjYWxsIGluaXRfdHJhY2VfcHJpbnRrKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDMuNzAxODc3XSBjYWxsaW5nICBqdW1wX2xhYmVsX2luaXRfbW9kdWxl
KzB4MC8weDEyIEAgMQpbICAgIDMuNzAxOTc5XSBpbml0Y2FsbCBqdW1wX2xhYmVsX2luaXRfbW9k
dWxlKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzAyMDg1XSBOTUkg
d2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTApOiBoYXJkd2FyZSBldmVudHMgbm90IGVuYWJsZWQKWyAg
ICAzLjcwMjI0OF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAxClsgICAgMy43MDIzNTRd
IGNwdSAxIHNwaW5sb2NrIGV2ZW50IGlycSAyNzkKWyAgICAzLjcwMjU1NF0gTk1JIHdhdGNoZG9n
IGRpc2FibGVkIChjcHUxKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBlbmFibGVkClsgICAgMy43MDI2
NzldIEJyb3VnaHQgdXAgMiBDUFVzClsgICAgMy43MDI5NjBdIGRldnRtcGZzOiBpbml0aWFsaXpl
ZApbICAgIDMuNzAzODExXSBjYWxsaW5nICBpcGNfbnNfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAz
LjcwMzkxM10gaW5pdGNhbGwgaXBjX25zX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy43MDQwMTddIGNhbGxpbmcgIGluaXRfbW1hcF9taW5fYWRkcisweDAvMHgx
NiBAIDEKWyAgICAzLjcwNDExOV0gaW5pdGNhbGwgaW5pdF9tbWFwX21pbl9hZGRyKzB4MC8weDE2
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzA0MjIyXSBjYWxsaW5nICBldm1fZGlz
cGxheV9jb25maWcrMHgwLzB4MmYgQCAxClsgICAgMy43MDQzMjNdIEVWTTogc2VjdXJpdHkuc2Vs
aW51eApbICAgIDMuNzA0NDIwXSBFVk06IHNlY3VyaXR5LlNNQUNLNjQKWyAgICAzLjcwNDUxOF0g
RVZNOiBzZWN1cml0eS5jYXBhYmlsaXR5ClsgICAgMy43MDQ2MTldIGluaXRjYWxsIGV2bV9kaXNw
bGF5X2NvbmZpZysweDAvMHgyZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNDcy
NF0gY2FsbGluZyAgaW5pdF9jcHVmcmVxX3RyYW5zaXRpb25fbm90aWZpZXJfbGlzdCsweDAvMHgx
YiBAIDEKWyAgICAzLjcwNDgzMF0gaW5pdGNhbGwgaW5pdF9jcHVmcmVxX3RyYW5zaXRpb25fbm90
aWZpZXJfbGlzdCsweDAvMHgxYiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNDk1
N10gY2FsbGluZyAgbmV0X25zX2luaXQrMHgwLzB4ZTggQCAxClsgICAgMy43MDUwOTFdIGluaXRj
YWxsIG5ldF9uc19pbml0KzB4MC8weGU4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
NzA1MjAwXSBjYWxsaW5nICBlODIwX21hcmtfbnZzX21lbW9yeSsweDAvMHgzZCBAIDEKWyAgICAz
LjcwNTMwMV0gUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBhdCBiZTdhNTAwMCAoMzEx
Mjk2IGJ5dGVzKQpbICAgIDMuNzA1NDA5XSBQTTogUmVnaXN0ZXJpbmcgQUNQSSBOVlMgcmVnaW9u
IGF0IGJmNDc3MDAwICg0MDk2IGJ5dGVzKQpbICAgIDMuNzA1NTEzXSBQTTogUmVnaXN0ZXJpbmcg
QUNQSSBOVlMgcmVnaW9uIGF0IGJmNDg5MDAwICgxMjI4OCBieXRlcykKWyAgICAzLjcwNTYxN10g
UE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBhdCBiZjUwMzAwMCAoNDA5NjAgYnl0ZXMp
ClsgICAgMy43MDU3MThdIFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24gYXQgYmY1MzMw
MDAgKDI3NDQzMiBieXRlcykKWyAgICAzLjcwNTgyN10gaW5pdGNhbGwgZTgyMF9tYXJrX252c19t
ZW1vcnkrMHgwLzB4M2QgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MDU5MzFdIGNh
bGxpbmcgIGNwdWZyZXFfdHNjKzB4MC8weDMwIEAgMQpbICAgIDMuNzA2MDMyXSBpbml0Y2FsbCBj
cHVmcmVxX3RzYysweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNjEz
NV0gY2FsbGluZyAgcGNpX3JlYm9vdF9pbml0KzB4MC8weDE0IEAgMQpbICAgIDMuNzA2MjM4XSBp
bml0Y2FsbCBwY2lfcmVib290X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy43MDYzNDNdIGNhbGxpbmcgIGluaXRfbGFwaWNfc3lzZnMrMHgwLzB4MjAgQCAxClsg
ICAgMy43MDY0NDNdIGluaXRjYWxsIGluaXRfbGFwaWNfc3lzZnMrMHgwLzB4MjAgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MDY1NDldIGNhbGxpbmcgIGluaXRfc21wX2ZsdXNoKzB4
MC8weDNhIEAgMQpbICAgIDMuNzA2NjQ5XSBpbml0Y2FsbCBpbml0X3NtcF9mbHVzaCsweDAvMHgz
YSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNjc1Nl0gY2FsbGluZyAgY3B1X2hv
dHBsdWdfcG1fc3luY19pbml0KzB4MC8weDIwIEAgMQpbICAgIDMuNzA2ODU4XSBpbml0Y2FsbCBj
cHVfaG90cGx1Z19wbV9zeW5jX2luaXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy43MDY5ODNdIGNhbGxpbmcgIGFsbG9jX2Zyb3plbl9jcHVzKzB4MC8weDEwIEAgMQpb
ICAgIDMuNzA3MDg2XSBpbml0Y2FsbCBhbGxvY19mcm96ZW5fY3B1cysweDAvMHgxMCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwNzE5Ml0gY2FsbGluZyAgc3lzY3RsX2luaXQrMHgw
LzB4MzIgQCAxClsgICAgMy43MDczMzFdIGluaXRjYWxsIHN5c2N0bF9pbml0KzB4MC8weDMyIHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzA3NDMzXSBjYWxsaW5nICBrc3lzZnNfaW5p
dCsweDAvMHg5MSBAIDEKWyAgICAzLjcwNzUzOV0gaW5pdGNhbGwga3N5c2ZzX2luaXQrMHgwLzB4
OTEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MDc2NDNdIGNhbGxpbmcgIGluaXRf
amlmZmllc19jbG9ja3NvdXJjZSsweDAvMHgxMiBAIDEKWyAgICAzLjcwNzc0N10gaW5pdGNhbGwg
aW5pdF9qaWZmaWVzX2Nsb2Nrc291cmNlKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuNzA3ODcyXSBjYWxsaW5nICBwbV9pbml0KzB4MC8weDZhIEAgMQpbICAgIDMuNzA3
OTc3XSBpbml0Y2FsbCBwbV9pbml0KzB4MC8weDZhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcwpb
ICAgIDMuNzA4MDc4XSBjYWxsaW5nICBwbV9kaXNrX2luaXQrMHgwLzB4MTkgQCAxClsgICAgMy43
MDgxODFdIGluaXRjYWxsIHBtX2Rpc2tfaW5pdCsweDAvMHgxOSByZXR1cm5lZCAwIGFmdGVyIDAg
dXNlY3MKWyAgICAzLjcwODI4M10gY2FsbGluZyAgc3dzdXNwX2hlYWRlcl9pbml0KzB4MC8weDQw
IEAgMQpbICAgIDMuNzA4Mzg3XSBpbml0Y2FsbCBzd3N1c3BfaGVhZGVyX2luaXQrMHgwLzB4NDAg
cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MDg0OTNdIGNhbGxpbmcgIGluaXRfZnRy
YWNlX3N5c2NhbGxzKzB4MC8weDg3IEAgMQpbICAgIDMuNzA5MDE1XSBpbml0Y2FsbCBpbml0X2Z0
cmFjZV9zeXNjYWxscysweDAvMHg4NyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcw
OTExOV0gY2FsbGluZyAgaW5pdF96ZXJvX3BmbisweDAvMHgxZiBAIDEKWyAgICAzLjcwOTIyMV0g
aW5pdGNhbGwgaW5pdF96ZXJvX3BmbisweDAvMHgxZiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjcwOTMyNV0gY2FsbGluZyAgbWVtb3J5X2ZhaWx1cmVfaW5pdCsweDAvMHhhMSBAIDEK
WyAgICAzLjcwOTQyNl0gaW5pdGNhbGwgbWVtb3J5X2ZhaWx1cmVfaW5pdCsweDAvMHhhMSByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwOTUzMV0gY2FsbGluZyAgZnNub3RpZnlfaW5p
dCsweDAvMHgyNiBAIDEKWyAgICAzLjcwOTYzM10gaW5pdGNhbGwgZnNub3RpZnlfaW5pdCsweDAv
MHgyNiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwOTczN10gY2FsbGluZyAgZmls
ZWxvY2tfaW5pdCsweDAvMHgyYSBAIDEKWyAgICAzLjcwOTgzOV0gaW5pdGNhbGwgZmlsZWxvY2tf
aW5pdCsweDAvMHgyYSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcwOTk0MV0gY2Fs
bGluZyAgaW5pdF9zY3JpcHRfYmluZm10KzB4MC8weDE0IEAgMQpbICAgIDMuNzEwMDQzXSBpbml0
Y2FsbCBpbml0X3NjcmlwdF9iaW5mbXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy43MTAxNDRdIGNhbGxpbmcgIGluaXRfZWxmX2JpbmZtdCsweDAvMHgxNCBAIDEKWyAg
ICAzLjcxMDI0N10gaW5pdGNhbGwgaW5pdF9lbGZfYmluZm10KzB4MC8weDE0IHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEwMzUyXSBjYWxsaW5nICBpbml0X2NvbXBhdF9lbGZfYmlu
Zm10KzB4MC8weDE0IEAgMQpbICAgIDMuNzEwNDU1XSBpbml0Y2FsbCBpbml0X2NvbXBhdF9lbGZf
YmluZm10KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEwNTYyXSBj
YWxsaW5nICBkZWJ1Z2ZzX2luaXQrMHgwLzB4NTcgQCAxClsgICAgMy43MTA2NjVdIGluaXRjYWxs
IGRlYnVnZnNfaW5pdCsweDAvMHg1NyByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcx
MDc3MF0gY2FsbGluZyAgc2VjdXJpdHlmc19pbml0KzB4MC8weDRlIEAgMQpbICAgIDMuNzEwODcw
XSBpbml0Y2FsbCBzZWN1cml0eWZzX2luaXQrMHgwLzB4NGUgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgMy43MTA5NzRdIGNhbGxpbmcgIHJhbmRvbTMyX2luaXQrMHgwLzB4ZDYgQCAxClsg
ICAgMy43MTEwNzNdIGluaXRjYWxsIHJhbmRvbTMyX2luaXQrMHgwLzB4ZDYgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy43MTExNzldIGNhbGxpbmcgIHNmaV9zeXNmc19pbml0KzB4MC8w
eGRhIEAgMQpbICAgIDMuNzExMjgzXSBpbml0Y2FsbCBzZmlfc3lzZnNfaW5pdCsweDAvMHhkYSBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcxMTM4N10gY2FsbGluZyAgdmlydGlvX2lu
aXQrMHgwLzB4MzAgQCAxClsgICAgMy43MTE1MDBdIGluaXRjYWxsIHZpcnRpb19pbml0KzB4MC8w
eDMwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzExNjA2XSBjYWxsaW5nICBfX2du
dHRhYl9pbml0KzB4MC8weDIxIEAgMQpbICAgIDMuNzExNzE1XSBHcmFudCB0YWJsZSBpbml0aWFs
aXplZApbICAgIDMuNzExODEyXSBpbml0Y2FsbCBfX2dudHRhYl9pbml0KzB4MC8weDIxIHJldHVy
bmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzExOTE3XSBjYWxsaW5nICByZWd1bGF0b3JfaW5p
dCsweDAvMHhhNiBAIDEKWyAgICAzLjcxMjA1M10gcHJpbnRfY29uc3RyYWludHM6IGR1bW15OiAK
WyAgICAzLjcxMjE1OV0gaW5pdGNhbGwgcmVndWxhdG9yX2luaXQrMHgwLzB4YTYgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MTIyNjVdIGNhbGxpbmcgIGVhcmx5X3Jlc3VtZV9pbml0
KzB4MC8weDIwIEAgMQpbICAgIDMuNzEyNDI3XSBSVEMgdGltZTogMTg6Mjk6MjMsIGRhdGU6IDA0
LzExLzEyClsgICAgMy43MTI1MjddIGluaXRjYWxsIGVhcmx5X3Jlc3VtZV9pbml0KzB4MC8weDIw
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEyNjMzXSBjYWxsaW5nICBjcHVmcmVx
X2NvcmVfaW5pdCsweDAvMHhhOSBAIDEKWyAgICAzLjcxMjczNV0gaW5pdGNhbGwgY3B1ZnJlcV9j
b3JlX2luaXQrMHgwLzB4YTkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTI4NDFd
IGNhbGxpbmcgIGNwdWlkbGVfaW5pdCsweDAvMHgzZCBAIDEKWyAgICAzLjcxMjk0Ml0gaW5pdGNh
bGwgY3B1aWRsZV9pbml0KzB4MC8weDNkIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAg
My43MTMwNDVdIGNhbGxpbmcgIHNvY2tfaW5pdCsweDAvMHg4MCBAIDEKWyAgICAzLjcxMzE2Ml0g
aW5pdGNhbGwgc29ja19pbml0KzB4MC8weDgwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuNzEzMjY2XSBjYWxsaW5nICBuZXRfaW51c2VfaW5pdCsweDAvMHgyNiBAIDEKWyAgICAzLjcx
MzM2OV0gaW5pdGNhbGwgbmV0X2ludXNlX2luaXQrMHgwLzB4MjYgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy43MTM0NzRdIGNhbGxpbmcgIG5ldHBvbGxfaW5pdCsweDAvMHgzMSBAIDEK
WyAgICAzLjcxMzU3NV0gaW5pdGNhbGwgbmV0cG9sbF9pbml0KzB4MC8weDMxIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEzNjgwXSBjYWxsaW5nICBuZXRsaW5rX3Byb3RvX2luaXQr
MHgwLzB4MjUgQCAxClsgICAgMy43MTM3ODRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMTYKWyAgICAzLjcxMzg5MF0gaW5pdGNhbGwgbmV0bGlua19wcm90b19pbml0KzB4MC8weDI1
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzEzOTk2XSBjYWxsaW5nICBwb3B1bGF0
ZV9yb290ZnNfZWFybHkrMHgwLzB4M2IgQCAxClsgICAgMy43MTQxMDFdIGluaXRjYWxsIHBvcHVs
YXRlX3Jvb3Rmc19lYXJseSsweDAvMHgzYiByZXR1cm5lZCAxIGFmdGVyIDAgdXNlY3MKWyAgICAz
LjcxNDIwN10gaW5pdGNhbGwgcG9wdWxhdGVfcm9vdGZzX2Vhcmx5KzB4MC8weDNiIHJldHVybmVk
IHdpdGggZXJyb3IgY29kZSAxIApbICAgIDMuNzE0MzMyXSBjYWxsaW5nICBiZGlfY2xhc3NfaW5p
dCsweDAvMHg0OSBAIDEKWyAgICAzLjcxNDQzN10gaW5pdGNhbGwgYmRpX2NsYXNzX2luaXQrMHgw
LzB4NDkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTQ1NDJdIGNhbGxpbmcgIGtv
YmplY3RfdWV2ZW50X2luaXQrMHgwLzB4MjEgQCAxClsgICAgMy43MTQ2NTldIGluaXRjYWxsIGtv
YmplY3RfdWV2ZW50X2luaXQrMHgwLzB4MjEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MTQ2NjZdIGNhbGxpbmcgIDFfYXN5bmNfcG9wdWxhdGVfcm9vdGZzKzB4MC8weDM2IEAgNQpb
ICAgIDMuNzE0Njk1XSBUcnlpbmcgdG8gdW5wYWNrIHJvb3RmcyBpbWFnZSBhcyBpbml0cmFtZnMu
Li4KWyAgICAzLjcxNDk2N10gY2FsbGluZyAgZ3Bpb2xpYl9zeXNmc19pbml0KzB4MC8weDkyIEAg
MQpbICAgIDMuNzE1MDc0XSBpbml0Y2FsbCBncGlvbGliX3N5c2ZzX2luaXQrMHgwLzB4OTIgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTUxNzldIGNhbGxpbmcgIHBjaWJ1c19jbGFz
c19pbml0KzB4MC8weDE5IEAgMQpbICAgIDMuNzE1MjgzXSBpbml0Y2FsbCBwY2lidXNfY2xhc3Nf
aW5pdCsweDAvMHgxOSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcxNTM4NV0gY2Fs
bGluZyAgcGNpX2RyaXZlcl9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuNzE1NDkxXSBpbml0Y2Fs
bCBwY2lfZHJpdmVyX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MTU1OTNdIGNhbGxpbmcgIHJpb19idXNfaW5pdCsweDAvMHgzMCBAIDEKWyAgICAzLjcxNTcx
MV0gaW5pdGNhbGwgcmlvX2J1c19pbml0KzB4MC8weDMwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuNzE1ODE1XSBjYWxsaW5nICBiYWNrbGlnaHRfY2xhc3NfaW5pdCsweDAvMHg1ZCBA
IDEKWyAgICAzLjcxNTkyMF0gaW5pdGNhbGwgYmFja2xpZ2h0X2NsYXNzX2luaXQrMHgwLzB4NWQg
cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTYwMjZdIGNhbGxpbmcgIHhlbmJ1c19p
bml0KzB4MC8weDE5MSBAIDEKWyAgICAzLjcxNjE4NF0gaW5pdGNhbGwgeGVuYnVzX2luaXQrMHgw
LzB4MTkxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzE2Mjg4XSBjYWxsaW5nICB0
dHlfY2xhc3NfaW5pdCsweDAvMHgzNCBAIDEKWyAgICAzLjcxNjM5NV0gaW5pdGNhbGwgdHR5X2Ns
YXNzX2luaXQrMHgwLzB4MzQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTY1MDBd
IGNhbGxpbmcgIHZ0Y29uc29sZV9jbGFzc19pbml0KzB4MC8weGUyIEAgMQpbICAgIDMuNzE2NjE4
XSBpbml0Y2FsbCB2dGNvbnNvbGVfY2xhc3NfaW5pdCsweDAvMHhlMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjcxNjcyMV0gY2FsbGluZyAgd2FrZXVwX3NvdXJjZXNfZGVidWdmc19p
bml0KzB4MC8weDJiIEAgMQpbICAgIDMuNzE2ODI2XSBpbml0Y2FsbCB3YWtldXBfc291cmNlc19k
ZWJ1Z2ZzX2luaXQrMHgwLzB4MmIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTY5
NTJdIGNhbGxpbmcgIHJlZ2lzdGVyX25vZGVfdHlwZSsweDAvMHgyYSBAIDEKWyAgICAzLjcxNzA1
OV0gaW5pdGNhbGwgcmVnaXN0ZXJfbm9kZV90eXBlKzB4MC8weDJhIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuNzE3MTY1XSBjYWxsaW5nICByZWdtYXBfaW5pdGNhbGwrMHgwLzB4ZCBA
IDEKWyAgICAzLjcxNzI2OF0gaW5pdGNhbGwgcmVnbWFwX2luaXRjYWxsKzB4MC8weGQgcmV0dXJu
ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTczNzNdIGNhbGxpbmcgIHNwaV9pbml0KzB4MC8w
eDk1IEAgMQpbICAgIDMuNzE3NDgyXSBpbml0Y2FsbCBzcGlfaW5pdCsweDAvMHg5NSByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcxNzU4N10gY2FsbGluZyAgaTJjX2luaXQrMHgwLzB4
NmYgQCAxClsgICAgMy43MTc3MDFdIGluaXRjYWxsIGkyY19pbml0KzB4MC8weDZmIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzE3ODA2XSBjYWxsaW5nICBhbWRfcG9zdGNvcmVfaW5p
dCsweDAvMHg4MSBAIDEKWyAgICAzLjcxOTYxMl0gaW5pdGNhbGwgYW1kX3Bvc3Rjb3JlX2luaXQr
MHgwLzB4ODEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MTk3MjFdIGNhbGxpbmcg
IGFyY2hfa2RlYnVnZnNfaW5pdCsweDAvMHgyNCBAIDEKWyAgICAzLjcxOTgyOV0gaW5pdGNhbGwg
YXJjaF9rZGVidWdmc19pbml0KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuNzE5OTM2XSBjYWxsaW5nICBjb25maWd1cmVfdHJhbXBvbGluZXMrMHgwLzB4MjYgQCAxClsg
ICAgMy43MjAwNDddIGluaXRjYWxsIGNvbmZpZ3VyZV90cmFtcG9saW5lcysweDAvMHgyNiByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyMDE1NV0gY2FsbGluZyAgbXRycl9pZl9pbml0
KzB4MC8weDY0IEAgMQpbICAgIDMuNzIwMjU3XSBpbml0Y2FsbCBtdHJyX2lmX2luaXQrMHgwLzB4
NjQgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyMDM2Ml0gY2FsbGluZyAgZmZo
X2NzdGF0ZV9pbml0KzB4MC8weDJhIEAgMQpbICAgIDMuNzIwNDY1XSBpbml0Y2FsbCBmZmhfY3N0
YXRlX2luaXQrMHgwLzB4MmEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjA1NzFd
IGNhbGxpbmcgIGFjdGl2YXRlX2p1bXBfbGFiZWxzKzB4MC8weDMyIEAgMQpbICAgIDMuNzIwNjc1
XSBpbml0Y2FsbCBhY3RpdmF0ZV9qdW1wX2xhYmVscysweDAvMHgzMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjcyMDc4Ml0gY2FsbGluZyAgYWNwaV9wY2lfaW5pdCsweDAvMHg1YyBA
IDEKWyAgICAzLjcyMDg4M10gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQKWyAgICAzLjcy
MDk4NF0gaW5pdGNhbGwgYWNwaV9wY2lfaW5pdCsweDAvMHg1YyByZXR1cm5lZCAwIGFmdGVyIDAg
dXNlY3MKWyAgICAzLjcyMTA5MV0gY2FsbGluZyAgZG1hX2J1c19pbml0KzB4MC8weDE5IEAgMQpb
ICAgIDMuNzIxMjAyXSBpbml0Y2FsbCBkbWFfYnVzX2luaXQrMHgwLzB4MTkgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy43MjEzMTBdIGNhbGxpbmcgIGRtYV9jaGFubmVsX3RhYmxlX2lu
aXQrMHgwLzB4MTE4IEAgMQpbICAgIDMuNzIxNDI2XSBpbml0Y2FsbCBkbWFfY2hhbm5lbF90YWJs
ZV9pbml0KzB4MC8weDExOCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyMTU1Ml0g
Y2FsbGluZyAgc2V0dXBfdmNwdV9ob3RwbHVnX2V2ZW50KzB4MC8weDIyIEAgMQpbICAgIDMuNzIx
NjU1XSBpbml0Y2FsbCBzZXR1cF92Y3B1X2hvdHBsdWdfZXZlbnQrMHgwLzB4MjIgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MjE3NzddIGNhbGxpbmcgIHJlZ2lzdGVyX3hlbl9wY2lf
bm90aWZpZXIrMHgwLzB4MzEgQCAxClsgICAgMy43MjE4ODBdIGluaXRjYWxsIHJlZ2lzdGVyX3hl
bl9wY2lfbm90aWZpZXIrMHgwLzB4MzEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43
MjIwMDhdIGNhbGxpbmcgIGRtaV9pZF9pbml0KzB4MC8weGNhIEAgMQpbICAgIDMuNzIyMTU3XSBp
bml0Y2FsbCBkbWlfaWRfaW5pdCsweDAvMHhjYSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg
ICAzLjcyMjI2NF0gY2FsbGluZyAgcGNpX2FyY2hfaW5pdCsweDAvMHg2NiBAIDEKWyAgICAzLjcy
MjM5N10gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1cyAwMC1mZl0gYXQgW21lbSAw
eGUwMDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDApClsgICAgMy43MjI1MjZdIFBD
STogbm90IHVzaW5nIE1NQ09ORklHClsgICAgMy43MjI2MjZdIFBDSTogVXNpbmcgY29uZmlndXJh
dGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzClsgICAgMy43MjI3MjldIGluaXRjYWxsIHBjaV9h
cmNoX2luaXQrMHgwLzB4NjYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjI4MzRd
IGNhbGxpbmcgIHRvcG9sb2d5X2luaXQrMHgwLzB4OTYgQCAxClsgICAgMy43MjMwNzRdIGluaXRj
YWxsIHRvcG9sb2d5X2luaXQrMHgwLzB4OTYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MjMxNzldIGNhbGxpbmcgIG10cnJfaW5pdF9maW5pYWxpemUrMHgwLzB4MzYgQCAxClsgICAg
My43MjMyODBdIGluaXRjYWxsIG10cnJfaW5pdF9maW5pYWxpemUrMHgwLzB4MzYgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy43MjMzODVdIGNhbGxpbmcgIGluaXRfdmRzbysweDAvMHg3
ZSBAIDEKWyAgICAzLjcyMzQ4N10gaW5pdGNhbGwgaW5pdF92ZHNvKzB4MC8weDdlIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzIzNTkxXSBjYWxsaW5nICBzeXNlbnRlcl9zZXR1cCsw
eDAvMHhhYiBAIDEKWyAgICAzLjcyMzY5NF0gaW5pdGNhbGwgc3lzZW50ZXJfc2V0dXArMHgwLzB4
YWIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjM4MDBdIGNhbGxpbmcgIHBhcmFt
X3N5c2ZzX2luaXQrMHgwLzB4NGIgQCAxClsgICAgMy43MjQ0MThdIGluaXRjYWxsIHBhcmFtX3N5
c2ZzX2luaXQrMHgwLzB4NGIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjQ1MjVd
IGNhbGxpbmcgIHBtX3N5c3JxX2luaXQrMHgwLzB4MjAgQCAxClsgICAgMy43MjQ2MjZdIGluaXRj
YWxsIHBtX3N5c3JxX2luaXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MjQ3MjhdIGNhbGxpbmcgIGRlZmF1bHRfYmRpX2luaXQrMHgwLzB4YTUgQCAxClsgICAgMy43
MjQ5MThdIGluaXRjYWxsIGRlZmF1bHRfYmRpX2luaXQrMHgwLzB4YTUgcmV0dXJuZWQgMCBhZnRl
ciAwIHVzZWNzClsgICAgMy43MjUwMjRdIGNhbGxpbmcgIGluaXRfYmlvKzB4MC8weDExYSBAIDEK
WyAgICAzLjcyNTE1NF0gYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKWyAgICAzLjcyNTI1
OF0gaW5pdGNhbGwgaW5pdF9iaW8rMHgwLzB4MTFhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcwpb
ICAgIDMuNzI1MzYzXSBjYWxsaW5nICBmc25vdGlmeV9ub3RpZmljYXRpb25faW5pdCsweDAvMHg4
YiBAIDEKWyAgICAzLjcyNTQ3MV0gaW5pdGNhbGwgZnNub3RpZnlfbm90aWZpY2F0aW9uX2luaXQr
MHgwLzB4OGIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy43MjU1OThdIGNhbGxpbmcg
IGNyeXB0b21ncl9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuNzI1Njk5XSBpbml0Y2FsbCBjcnlw
dG9tZ3JfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNTgw
M10gY2FsbGluZyAgYmxrX3NldHRpbmdzX2luaXQrMHgwLzB4MmEgQCAxClsgICAgMy43MjU5MDVd
IGluaXRjYWxsIGJsa19zZXR0aW5nc19pbml0KzB4MC8weDJhIHJldHVybmVkIDAgYWZ0ZXIgMCB1
c2VjcwpbICAgIDMuNzI2MDEwXSBjYWxsaW5nICBibGtfaW9jX2luaXQrMHgwLzB4MmEgQCAxClsg
ICAgMy43MjYxMTFdIGluaXRjYWxsIGJsa19pb2NfaW5pdCsweDAvMHgyYSByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICAzLjcyNjIxOV0gY2FsbGluZyAgYmxrX3NvZnRpcnFfaW5pdCsweDAv
MHg2ZCBAIDEKWyAgICAzLjcyNjMyM10gaW5pdGNhbGwgYmxrX3NvZnRpcnFfaW5pdCsweDAvMHg2
ZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNjQyOF0gY2FsbGluZyAgYmxrX2lv
cG9sbF9zZXR1cCsweDAvMHg2ZCBAIDEKWyAgICAzLjcyNjUzMF0gaW5pdGNhbGwgYmxrX2lvcG9s
bF9zZXR1cCsweDAvMHg2ZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNjYzNl0g
Y2FsbGluZyAgZ2VuaGRfZGV2aWNlX2luaXQrMHgwLzB4NzggQCAxClsgICAgMy43MjY4MDldIGlu
aXRjYWxsIGdlbmhkX2RldmljZV9pbml0KzB4MC8weDc4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuNzI2OTE0XSBjYWxsaW5nICBibGtfZGV2X2ludGVncml0eV9pbml0KzB4MC8weDJh
IEAgMQpbICAgIDMuNzI3MDE0XSBpbml0Y2FsbCBibGtfZGV2X2ludGVncml0eV9pbml0KzB4MC8w
eDJhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuNzI3MTE4XSBjYWxsaW5nICBncGlv
bGliX2RlYnVnZnNfaW5pdCsweDAvMHgyNCBAIDEKWyAgICAzLjcyNzIyM10gaW5pdGNhbGwgZ3Bp
b2xpYl9kZWJ1Z2ZzX2luaXQrMHgwLzB4MjQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My43MjczMjddIGNhbGxpbmcgIHN0bXBlX2dwaW9faW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjcy
NzQzN10gaW5pdGNhbGwgc3RtcGVfZ3Bpb19pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuNzI3NTQxXSBjYWxsaW5nICBzeDE1MHhfaW5pdCsweDAvMHgxNCBAIDEK
WyAgICAzLjcyNzY0N10gaW5pdGNhbGwgc3gxNTB4X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy43Mjc3NTBdIGNhbGxpbmcgIHRjMzU4OXhfZ3Bpb19pbml0KzB4
MC8weDEyIEAgMQpbICAgIDMuNzI3ODU0XSBpbml0Y2FsbCB0YzM1ODl4X2dwaW9faW5pdCsweDAv
MHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyNzk2MV0gY2FsbGluZyAgcGNp
X3Nsb3RfaW5pdCsweDAvMHg1MCBAIDEKWyAgICAzLjcyODA2M10gaW5pdGNhbGwgcGNpX3Nsb3Rf
aW5pdCsweDAvMHg1MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyODE2OV0gY2Fs
bGluZyAgZmJtZW1faW5pdCsweDAvMHg5OCBAIDEKWyAgICAzLjcyODI3N10gaW5pdGNhbGwgZmJt
ZW1faW5pdCsweDAvMHg5OCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjcyODM3OV0g
Y2FsbGluZyAgYWNwaV9pbml0KzB4MC8weGI5IEAgMQpbICAgIDMuNzI4NDg4XSBBQ1BJOiBBZGRl
ZCBfT1NJKE1vZHVsZSBEZXZpY2UpClsgICAgMy43Mjg1ODhdIEFDUEk6IEFkZGVkIF9PU0koUHJv
Y2Vzc29yIERldmljZSkKWyAgICAzLjcyODY5MV0gQUNQSTogQWRkZWQgX09TSSgzLjAgX1NDUCBF
eHRlbnNpb25zKQpbICAgIDMuNzI4NzkyXSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dy
ZWdhdG9yIERldmljZSkKWyAgICAzLjczMDk0MF0gQUNQSTogRUM6IExvb2sgdXAgRUMgaW4gRFNE
VApbICAgIDMuNzMyOTgxXSBBQ1BJOiBFeGVjdXRlZCAxIGJsb2NrcyBvZiBtb2R1bGUtbGV2ZWwg
ZXhlY3V0YWJsZSBBTUwgY29kZQpbICAgIDMuNzM2NDg0XSBBQ1BJOiBTU0RUIDAwMDAwMDAwYmY1
MDQwMTggMDA4NkMgKHYwMSAgICBBTUkgICAgICBJU1QgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkK
WyAgICAzLjczNzMxOV0gQUNQSTogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKWyAgICAzLjczNzU2
NF0gQUNQSTogU1NEVCAgICAgICAgICAgKG51bGwpIDAwODZDICh2MDEgICAgQU1JICAgICAgSVNU
IDAwMDAwMDAxIE1TRlQgMDMwMDAwMDEpClsgICAgMy43Mzc5MjFdIEFDUEk6IFNTRFQgMDAwMDAw
MDBiZjUwNWUxOCAwMDFBNCAodjAxICAgIEFNSSAgICAgIENTVCAwMDAwMDAwMSBNU0ZUIDAzMDAw
MDAxKQpbICAgIDMuNzM4Njg5XSBBQ1BJOiBEeW5hbWljIE9FTSBUYWJsZSBMb2FkOgpbICAgIDMu
NzM4OTM5XSBBQ1BJOiBTU0RUICAgICAgICAgICAobnVsbCkgMDAxQTQgKHYwMSAgICBBTUkgICAg
ICBDU1QgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkKWyAgICAzLjczOTQ1Ml0gQUNQSTogSW50ZXJw
cmV0ZXIgZW5hYmxlZApbICAgIDMuNzM5NTUyXSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzEgUzQgUzUp
ClsgICAgMy43Mzk5NTNdIEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRpbmcK
WyAgICAzLjc0MDA5Ml0gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1cyAwMC1mZl0g
YXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDApClsgICAgMy43
NDAzMTJdIFBDSTogTU1DT05GSUcgYXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIHJlc2Vy
dmVkIGluIEFDUEkgbW90aGVyYm9hcmQgcmVzb3VyY2VzClsgICAgMy43NDcyNjVdIEZyZWVpbmcg
aW5pdHJkIG1lbW9yeTogNDA5NzZrIGZyZWVkClsgICAgMy43NTM3ODhdIGluaXRjYWxsIDFfYXN5
bmNfcG9wdWxhdGVfcm9vdGZzKzB4MC8weDM2IHJldHVybmVkIDAgYWZ0ZXIgMzkwNjQgdXNlY3MK
WyAgICAzLjgxNjEzNV0gW0Zpcm13YXJlIEJ1Z106IEFDUEk6IEJJT1MgX09TSShMaW51eCkgcXVl
cnkgaWdub3JlZApbICAgIDMuODIxNTI0XSBpbml0Y2FsbCBhY3BpX2luaXQrMHgwLzB4YjkgcmV0
dXJuZWQgMCBhZnRlciA4OTg0OSB1c2VjcwpbICAgIDMuODIxNjMwXSBjYWxsaW5nICBkb2NrX2lu
aXQrMHgwLzB4YTUgQCAxClsgICAgMy44MjE4ODBdIEFDUEk6IE5vIGRvY2sgZGV2aWNlcyBmb3Vu
ZC4KWyAgICAzLjgyMTk4MV0gaW5pdGNhbGwgZG9ja19pbml0KzB4MC8weGE1IHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuODIyMDg1XSBjYWxsaW5nICBhY3BpX3BjaV9yb290X2luaXQr
MHgwLzB4MmQgQCAxClsgICAgMy44MjIyMjFdIEhFU1Q6IFRhYmxlIHBhcnNpbmcgaGFzIGJlZW4g
aW5pdGlhbGl6ZWQuClsgICAgMy44MjIzMjRdIFBDSTogVXNpbmcgaG9zdCBicmlkZ2Ugd2luZG93
cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFuZCByZXBvcnQgYSBi
dWcKWyAgICAzLjgyMjcyNV0gQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kwXSAoZG9tYWluIDAw
MDAgW2J1cyAwMC1mZl0pClsgICAgMy44MjMxMDNdIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3Qg
YnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDAzYWZdClsgICAgMy44MjMyMDhdIHBjaV9yb290
IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDNlMC0weDBjZjddClsgICAg
My44MjMzMTBdIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4
MDNiMC0weDAzZGZdClsgICAgMy44MjM0MTZdIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3QgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMy44MjM1MjJdIHBjaV9yb290IFBO
UDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0K
WyAgICAzLjgyMzY0N10gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFtt
ZW0gMHgwMDBjMDAwMC0weDAwMGRmZmZmXQpbICAgIDMuODIzNzcxXSBwY2lfcm9vdCBQTlAwQTA4
OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGYwMDAwMDAwLTB4ZmJmZmZmZmZdClsgICAg
My44MjM5MTFdIHBjaSAwMDAwOjAwOjAwLjA6IFs4MDg2OjAxMDhdIHR5cGUgMCBjbGFzcyAweDAw
MDYwMApbICAgIDMuODI0MDk5XSBwY2kgMDAwMDowMDowMS4wOiBbODA4NjowMTAxXSB0eXBlIDEg
Y2xhc3MgMHgwMDA2MDQKWyAgICAzLjgyNDI4M10gcGNpIDAwMDA6MDA6MDEuMDogUE1FIyBzdXBw
b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAzLjgyNDM5MF0gcGNpIDAwMDA6MDA6MDEu
MDogUE1FIyBkaXNhYmxlZApbICAgIDMuODI0Njc5XSBwY2kgMDAwMDowMDoxOS4wOiBbODA4Njox
NTAyXSB0eXBlIDAgY2xhc3MgMHgwMDAyMDAKWyAgICAzLjgyNDg1Nl0gcGNpIDAwMDA6MDA6MTku
MDogcmVnIDEwOiBbbWVtIDB4ZmJiMDAwMDAtMHhmYmIxZmZmZl0KWyAgICAzLjgyNDk4OV0gcGNp
IDAwMDA6MDA6MTkuMDogcmVnIDE0OiBbbWVtIDB4ZmJiMjQwMDAtMHhmYmIyNGZmZl0KWyAgICAz
LjgyNTEyNV0gcGNpIDAwMDA6MDA6MTkuMDogcmVnIDE4OiBbaW8gIDB4ZjAyMC0weGYwM2ZdClsg
ICAgMy44MjU1MTBdIHBjaSAwMDAwOjAwOjE5LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNo
b3QgRDNjb2xkClsgICAgMy44MjU2MTldIHBjaSAwMDAwOjAwOjE5LjA6IFBNRSMgZGlzYWJsZWQK
WyAgICAzLjgyNTgwM10gcGNpIDAwMDA6MDA6MWEuMDogWzgwODY6MWMyZF0gdHlwZSAwIGNsYXNz
IDB4MDAwYzAzClsgICAgMy44MjU5ODBdIHBjaSAwMDAwOjAwOjFhLjA6IHJlZyAxMDogW21lbSAw
eGZiYjIzMDAwLTB4ZmJiMjMzZmZdClsgICAgMy44MjY0MzZdIHBjaSAwMDAwOjAwOjFhLjA6IFBN
RSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy44MjY1NDldIHBjaSAwMDAw
OjAwOjFhLjA6IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgyNjczM10gcGNpIDAwMDA6MDA6MWMuMDog
WzgwODY6MWMxMF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMy44MjcyMzldIHBjaSAwMDAw
OjAwOjFjLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy44Mjcz
NTVdIHBjaSAwMDAwOjAwOjFjLjA6IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgyNzU3NV0gcGNpIDAw
MDA6MDA6MWMuNDogWzgwODY6MWMxOF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMy44Mjgw
NzBdIHBjaSAwMDAwOjAwOjFjLjQ6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xk
ClsgICAgMy44MjgxODZdIHBjaSAwMDAwOjAwOjFjLjQ6IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgy
ODQwMl0gcGNpIDAwMDA6MDA6MWQuMDogWzgwODY6MWMyNl0gdHlwZSAwIGNsYXNzIDB4MDAwYzAz
ClsgICAgMy44Mjg1ODFdIHBjaSAwMDAwOjAwOjFkLjA6IHJlZyAxMDogW21lbSAweGZiYjIyMDAw
LTB4ZmJiMjIzZmZdClsgICAgMy44MjkwMzldIHBjaSAwMDAwOjAwOjFkLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMy44MjkxNTFdIHBjaSAwMDAwOjAwOjFkLjA6
IFBNRSMgZGlzYWJsZWQKWyAgICAzLjgyOTMxM10gcGNpIDAwMDA6MDA6MWUuMDogWzgwODY6MjQ0
ZV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMy44Mjk2OTJdIHBjaSAwMDAwOjAwOjFmLjA6
IFs4MDg2OjFjNTRdIHR5cGUgMCBjbGFzcyAweDAwMDYwMQpbICAgIDMuODMwMjcwXSBwY2kgMDAw
MDowMDoxZi4yOiBbODA4NjoyODIyXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDQKWyAgICAzLjgzMDQ1
M10gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDEwOiBbaW8gIDB4ZjA3MC0weGYwNzddClsgICAgMy44
MzA1ODRdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxNDogW2lvICAweGYwNjAtMHhmMDYzXQpbICAg
IDMuODMwNzE0XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTg6IFtpbyAgMHhmMDUwLTB4ZjA1N10K
WyAgICAzLjgzMDg0Nl0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDFjOiBbaW8gIDB4ZjA0MC0weGYw
NDNdClsgICAgMy44MzA5NzVdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAyMDogW2lvICAweGYwMDAt
MHhmMDFmXQpbICAgIDMuODMxMTA3XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMjQ6IFttZW0gMHhm
YmIyMTAwMC0weGZiYjIxN2ZmXQpbICAgIDMuODMxNDIxXSBwY2kgMDAwMDowMDoxZi4yOiBQTUUj
IHN1cHBvcnRlZCBmcm9tIEQzaG90ClsgICAgMy44MzE1MzFdIHBjaSAwMDAwOjAwOjFmLjI6IFBN
RSMgZGlzYWJsZWQKWyAgICAzLjgzMTY5M10gcGNpIDAwMDA6MDA6MWYuMzogWzgwODY6MWMyMl0g
dHlwZSAwIGNsYXNzIDB4MDAwYzA1ClsgICAgMy44MzE4NTVdIHBjaSAwMDAwOjAwOjFmLjM6IHJl
ZyAxMDogW21lbSAweGZiYjIwMDAwLTB4ZmJiMjAwZmYgNjRiaXRdClsgICAgMy44MzIwNTFdIHBj
aSAwMDAwOjAwOjFmLjM6IHJlZyAyMDogW2lvICAweDExODAtMHgxMTlmXQpbICAgIDMuODMyMzI5
XSBwY2kgMDAwMDowMTowMC4wOiBbMTAwMDowMDcyXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDcKWyAg
ICAzLjgzMjQ0M10gcGNpIDAwMDA6MDE6MDAuMDogcmVnIDEwOiBbaW8gIDB4ZTAwMC0weGUwZmZd
ClsgICAgMy44MzI1NTldIHBjaSAwMDAwOjAxOjAwLjA6IHJlZyAxNDogW21lbSAweGZiYWMwMDAw
LTB4ZmJhYzNmZmYgNjRiaXRdClsgICAgMy44MzI2NzldIHBjaSAwMDAwOjAxOjAwLjA6IHJlZyAx
YzogW21lbSAweGZmYTgwMDAwLTB4ZmZhYmZmZmYgNjRiaXRdClsgICAgMy44MzI4MDJdIHBjaSAw
MDAwOjAxOjAwLjA6IHJlZyAzMDogW21lbSAweGZiYTAwMDAwLTB4ZmJhN2ZmZmYgcHJlZl0KWyAg
ICAzLjgzMjk3MV0gcGNpIDAwMDA6MDE6MDAuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAzLjg0MTc4
N10gcGNpIDAwMDA6MDA6MDEuMDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXQpbICAgIDMuODQx
OTE0XSBwY2kgMDAwMDowMDowMS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZm
XQpbICAgIDMuODQyMDIwXSBwY2kgMDAwMDowMDowMS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw
eGZiYTAwMDAwLTB4ZmJhZmZmZmZdClsgICAgMy44NDIzNDZdIHBjaSAwMDAwOjAwOjFjLjA6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KWyAgICAzLjg0MjgzOV0gcGNpIDAwMDA6MDM6MDAuMDog
WzgwODY6MTBkM10gdHlwZSAwIGNsYXNzIDB4MDAwMjAwClsgICAgMy44NDI5OTVdIHBjaSAwMDAw
OjAzOjAwLjA6IHJlZyAxMDogW21lbSAweGZiOTAwMDAwLTB4ZmI5MWZmZmZdClsgICAgMy44NDMx
NzFdIHBjaSAwMDAwOjAzOjAwLjA6IHJlZyAxODogW2lvICAweGQwMDAtMHhkMDFmXQpbICAgIDMu
ODQzMzA5XSBwY2kgMDAwMDowMzowMC4wOiByZWcgMWM6IFttZW0gMHhmYjkyMDAwMC0weGZiOTIz
ZmZmXQpbICAgIDMuODQzNzU4XSBwY2kgMDAwMDowMzowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9t
IEQwIEQzaG90IEQzY29sZApbICAgIDMuODQzODcwXSBwY2kgMDAwMDowMzowMC4wOiBQTUUjIGRp
c2FibGVkClsgICAgMy44NTQwMjFdIHBjaSAwMDAwOjAwOjFjLjQ6IFBDSSBicmlkZ2UgdG8gW2J1
cyAwMy0wM10KWyAgICAzLjg1NDEzMF0gcGNpIDAwMDA6MDA6MWMuNDogICBicmlkZ2Ugd2luZG93
IFtpbyAgMHhkMDAwLTB4ZGZmZl0KWyAgICAzLjg1NDI0MF0gcGNpIDAwMDA6MDA6MWMuNDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmYjkwMDAwMC0weGZiOWZmZmZmXQpbICAgIDMuODU0NDg5XSBw
Y2kgMDAwMDowNDowMy4wOiBbMTAyYjowNTMyXSB0eXBlIDAgY2xhc3MgMHgwMDAzMDAKWyAgICAz
Ljg1NDY1MF0gcGNpIDAwMDA6MDQ6MDMuMDogcmVnIDEwOiBbbWVtIDB4ZmEwMDAwMDAtMHhmYWZm
ZmZmZiBwcmVmXQpbICAgIDMuODU0NzgyXSBwY2kgMDAwMDowNDowMy4wOiByZWcgMTQ6IFttZW0g
MHhmYjgwMDAwMC0weGZiODAzZmZmXQpbICAgIDMuODU0OTEwXSBwY2kgMDAwMDowNDowMy4wOiBy
ZWcgMTg6IFttZW0gMHhmYjAwMDAwMC0weGZiN2ZmZmZmXQpbICAgIDMuODU1Mzc1XSBwY2kgMDAw
MDowMDoxZS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdIChzdWJ0cmFjdGl2ZSBkZWNvZGUp
ClsgICAgMy44NTU0OTNdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4
ZmIwMDAwMDAtMHhmYjhmZmZmZl0KWyAgICAzLjg1NTYxM10gcGNpIDAwMDA6MDA6MWUuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAwMC0weGZhZmZmZmZmIDY0Yml0IHByZWZdClsgICAg
My44NTU3MzddIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0w
eDAzYWZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMy44NTU4NjBdIHBjaSAwMDAwOjAwOjFl
LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDNlMC0weDBjZjddIChzdWJ0cmFjdGl2ZSBkZWNv
ZGUpClsgICAgMy44NTU5ODJdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g
IDB4MDNiMC0weDAzZGZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMy44NTYxMDZdIHBjaSAw
MDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdIChzdWJ0cmFj
dGl2ZSBkZWNvZGUpClsgICAgMy44NTYyMjhdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0gKHN1YnRyYWN0aXZlIGRlY29kZSkKWyAg
ICAzLjg1NjM1NF0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBj
MDAwMC0weDAwMGRmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDMuODU2NDgxXSBwY2kg
MDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGYwMDAwMDAwLTB4ZmJmZmZmZmZd
IChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMy44NTY2NzVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQg
Um91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5fUFJUXQpbICAgIDMuODU2ODM2XSBBQ1BJOiBQQ0kg
SW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuQlIyMC5fUFJUXQpbICAgIDMuODU2
OTcwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEVYMC5f
UFJUXQpbICAgIDMuODU3MDkyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xf
U0JfLlBDSTAuUEVYNC5fUFJUXQpbICAgIDMuODU3MjE5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJv
dXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUDBQMS5fUFJUXQpbICAgIDMuODU3NDMyXSAgcGNpMDAw
MDowMDogUmVxdWVzdGluZyBBQ1BJIF9PU0MgY29udHJvbCAoMHgxZCkKWyAgICAzLjg1Nzc1OV0g
IHBjaTAwMDA6MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFjKSBncmFudGVkClsgICAgMy44NjA1
NjhdIGluaXRjYWxsIGFjcGlfcGNpX3Jvb3RfaW5pdCsweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVy
IDM5MDY0IHVzZWNzClsgICAgMy44NjA2NzJdIGNhbGxpbmcgIGFjcGlfcGNpX2xpbmtfaW5pdCsw
eDAvMHgzZSBAIDEKWyAgICAzLjg2MDgxMF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktB
XSAoSVJRcyAzIDQgNSA2IDcgMTAgKjExIDEyIDE0IDE1KQpbICAgIDMuODYxODE1XSBBQ1BJOiBQ
Q0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDMgNCAqNSA2IDcgMTAgMTEgMTIgMTQgMTUp
ClsgICAgMy44NjI4MjhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQ10gKElSUXMgMyA0
IDUgNiAxMCAqMTEgMTIgMTQgMTUpClsgICAgMy44NjM3NjRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQg
TGluayBbTE5LRF0gKElSUXMgMyA0IDUgNiAxMCAqMTEgMTIgMTQgMTUpClsgICAgMy44NjQ3MDNd
IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRV0gKElSUXMgMyA0IDUgNiAqNyAxMCAxMSAx
MiAxNCAxNSkKWyAgICAzLjg2NTcyM10gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktGXSAo
SVJRcyAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUpICowClsgICAgMy44NjY4NDNdIEFDUEk6IFBD
SSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1KSAq
MApbICAgIDMuODY3OTU2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFzIDMg
NCAqNSA2IDcgMTAgMTEgMTIgMTQgMTUpClsgICAgMy44Njg5NTVdIGluaXRjYWxsIGFjcGlfcGNp
X2xpbmtfaW5pdCsweDAvMHgzZSByZXR1cm5lZCAwIGFmdGVyIDc4MTIgdXNlY3MKWyAgICAzLjg2
OTA1OV0gY2FsbGluZyAgcG5wX2luaXQrMHgwLzB4MTIgQCAxClsgICAgMy44NjkxNjZdIGluaXRj
YWxsIHBucF9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuODY5
MjcxXSBjYWxsaW5nICB4ZW5fc2V0dXBfc2h1dGRvd25fZXZlbnQrMHgwLzB4MzAgQCAxClsgICAg
My44NjkzNzVdIGluaXRjYWxsIHhlbl9zZXR1cF9zaHV0ZG93bl9ldmVudCsweDAvMHgzMCByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg2OTQ5OV0gY2FsbGluZyAgYmFsbG9vbl9pbml0
KzB4MC8weDE5IEAgMQpbICAgIDMuODY5NjAxXSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJh
bGxvb24gZHJpdmVyLgpbICAgIDMuODkxMjEwXSBpbml0Y2FsbCBiYWxsb29uX2luaXQrMHgwLzB4
MTkgcmV0dXJuZWQgMCBhZnRlciAxOTUzMiB1c2VjcwpbICAgIDMuODkxMzE5XSBjYWxsaW5nICB4
ZW5idXNfcHJvYmVfYmFja2VuZF9pbml0KzB4MC8weDJhIEAgMQpbICAgIDMuODkxNDQzXSBpbml0
Y2FsbCB4ZW5idXNfcHJvYmVfYmFja2VuZF9pbml0KzB4MC8weDJhIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuODkxNTY3XSBjYWxsaW5nICB4ZW5idXNfcHJvYmVfZnJvbnRlbmRfaW5p
dCsweDAvMHgyYiBAIDEKWyAgICAzLjg5MTY3Nl0gaW5pdGNhbGwgeGVuYnVzX3Byb2JlX2Zyb250
ZW5kX2luaXQrMHgwLzB4MmIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTE4MDFd
IGNhbGxpbmcgIGJhbGxvb25faW5pdCsweDAvMHg0MSBAIDEKWyAgICAzLjg5MTkwMV0geGVuLWJh
bGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KWyAgICAzLjg5MjAyMl0gaW5pdGNh
bGwgYmFsbG9vbl9pbml0KzB4MC8weDQxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
ODkyMTI3XSBjYWxsaW5nICB4ZW5fc2VsZmJhbGxvb25faW5pdCsweDAvMHg4MyBAIDEKWyAgICAz
Ljg5MjIzNF0geGVuL2JhbGxvb246IFhlbiBzZWxmYmFsbG9vbmluZyBkcml2ZXIgZGlzYWJsZWQg
Zm9yIGRvbWFpbjAuClsgICAgMy44OTIzMzddIGluaXRjYWxsIHhlbl9zZWxmYmFsbG9vbl9pbml0
KzB4MC8weDgzIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgMy44OTI0NDJdIGNhbGxp
bmcgIHBtODYwN19yZWd1bGF0b3JfaW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjg5MjU1MV0gaW5p
dGNhbGwgcG04NjA3X3JlZ3VsYXRvcl9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1
c2VjcwpbICAgIDMuODkyNjU2XSBjYWxsaW5nICBhYjg1MDBfcmVndWxhdG9yX2luaXQrMHgwLzB4
MmUgQCAxClsgICAgMy44OTI3NjFdIGluaXRjYWxsIGFiODUwMF9yZWd1bGF0b3JfaW5pdCsweDAv
MHgyZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5Mjg2N10gY2FsbGluZyAgbWlz
Y19pbml0KzB4MC8weGI2IEAgMQpbICAgIDMuODkyOTc0XSBpbml0Y2FsbCBtaXNjX2luaXQrMHgw
LzB4YjYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTMwNzhdIGNhbGxpbmcgIHZn
YV9hcmJfZGV2aWNlX2luaXQrMHgwLzB4ZjEgQCAxClsgICAgMy44OTMyNTldIHZnYWFyYjogZGV2
aWNlIGFkZGVkOiBQQ0k6MDAwMDowNDowMy4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVtLGxv
Y2tzPW5vbmUKWyAgICAzLjg5MzM4NV0gdmdhYXJiOiBsb2FkZWQKWyAgICAzLjg5MzQ4MV0gdmdh
YXJiOiBicmlkZ2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA0OjAzLjAKWyAgICAzLjg5MzU4NF0g
aW5pdGNhbGwgdmdhX2FyYl9kZXZpY2VfaW5pdCsweDAvMHhmMSByZXR1cm5lZCAwIGFmdGVyIDAg
dXNlY3MKWyAgICAzLjg5MzY5MV0gY2FsbGluZyAgY25faW5pdCsweDAvMHg5ZSBAIDEKWyAgICAz
Ljg5Mzc5NV0gaW5pdGNhbGwgY25faW5pdCsweDAvMHg5ZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjg5Mzg5OV0gY2FsbGluZyAgcG04NjB4X2kyY19pbml0KzB4MC8weDMwIEAgMQpb
ICAgIDMuODk0MDA2XSBpbml0Y2FsbCBwbTg2MHhfaTJjX2luaXQrMHgwLzB4MzAgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy44OTQxMTBdIGNhbGxpbmcgIHN0bXBlX2luaXQrMHgwLzB4
MTQgQCAxClsgICAgMy44OTQyMTRdIGluaXRjYWxsIHN0bXBlX2luaXQrMHgwLzB4MTQgcmV0dXJu
ZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTQzMTddIGNhbGxpbmcgIHRjMzU4OXhfaW5pdCsw
eDAvMHgxNCBAIDEKWyAgICAzLjg5NDQyMF0gaW5pdGNhbGwgdGMzNTg5eF9pbml0KzB4MC8weDE0
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuODk0NTIzXSBjYWxsaW5nICB3bTgzMXhf
aTJjX2luaXQrMHgwLzB4MzAgQCAxClsgICAgMy44OTQ2MjZdIGluaXRjYWxsIHdtODMxeF9pMmNf
aW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5NDczMV0gY2Fs
bGluZyAgd204MzF4X3NwaV9pbml0KzB4MC8weDI4IEAgMQpbICAgIDMuODk0ODM1XSBpbml0Y2Fs
bCB3bTgzMXhfc3BpX2luaXQrMHgwLzB4MjggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My44OTQ5NDBdIGNhbGxpbmcgIHdtODM1MF9pMmNfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAzLjg5
NTA0Nl0gaW5pdGNhbGwgd204MzUwX2kyY19pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuODk1MTUwXSBjYWxsaW5nICB0cHM2NTkxMF9pMmNfaW5pdCsweDAvMHgx
NCBAIDEKWyAgICAzLjg5NTI1N10gaW5pdGNhbGwgdHBzNjU5MTBfaTJjX2luaXQrMHgwLzB4MTQg
cmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTUzNjJdIGNhbGxpbmcgIHRwczY1OTEy
X2kyY19pbml0KzB4MC8weDMwIEAgMQpbICAgIDMuODk1NDY2XSBpbml0Y2FsbCB0cHM2NTkxMl9p
MmNfaW5pdCsweDAvMHgzMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5NTU3MV0g
Y2FsbGluZyAgdHBzNjU5MTJfc3BpX2luaXQrMHgwLzB4MjggQCAxClsgICAgMy44OTU2ODBdIGlu
aXRjYWxsIHRwczY1OTEyX3NwaV9pbml0KzB4MC8weDI4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuODk1Nzg0XSBjYWxsaW5nICBkYTkwM3hfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAz
Ljg5NTg4N10gaW5pdGNhbGwgZGE5MDN4X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy44OTU5OTFdIGNhbGxpbmcgIG1heDg5MjVfaTJjX2luaXQrMHgwLzB4MzAg
QCAxClsgICAgMy44OTYwOTNdIGluaXRjYWxsIG1heDg5MjVfaTJjX2luaXQrMHgwLzB4MzAgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTYxOThdIGNhbGxpbmcgIG1heDg5OTdfaTJj
X2luaXQrMHgwLzB4MTQgQCAxClsgICAgMy44OTYzMDJdIGluaXRjYWxsIG1heDg5OTdfaTJjX2lu
aXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTY0MDZdIGNhbGxp
bmcgIG1heDg5OThfaTJjX2luaXQrMHgwLzB4MTQgQCAxClsgICAgMy44OTY1MTBdIGluaXRjYWxs
IG1heDg5OThfaTJjX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My44OTY2MTNdIGNhbGxpbmcgIGFiMzEwMF9pMmNfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAzLjg5
NjcxOF0gaW5pdGNhbGwgYWIzMTAwX2kyY19pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuODk2ODIzXSBjYWxsaW5nICBhYjg1MDBfc3lzY3RybF9pbml0KzB4MC8w
eDEyIEAgMQpbICAgIDMuODk2OTMyXSBpbml0Y2FsbCBhYjg1MDBfc3lzY3RybF9pbml0KzB4MC8w
eDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuODk3MDM2XSBjYWxsaW5nICBhYjg1
MDBfZGVidWdfaW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjg5NzE0Ml0gaW5pdGNhbGwgYWI4NTAw
X2RlYnVnX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy44OTcy
NDddIGNhbGxpbmcgIHRwczY1ODZ4X2luaXQrMHgwLzB4MTQgQCAxClsgICAgMy44OTczNTJdIGlu
aXRjYWxsIHRwczY1ODZ4X2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsg
ICAgMy44OTc0NTNdIGNhbGxpbmcgIGFhdDI4NzBfaW5pdCsweDAvMHgxNCBAIDEKWyAgICAzLjg5
NzU1N10gaTJjLWNvcmU6IGRyaXZlciBbYWF0Mjg3MF0gdXNpbmcgbGVnYWN5IHN1c3BlbmQgbWV0
aG9kClsgICAgMy44OTc2NjBdIGkyYy1jb3JlOiBkcml2ZXIgW2FhdDI4NzBdIHVzaW5nIGxlZ2Fj
eSByZXN1bWUgbWV0aG9kClsgICAgMy44OTc3NjVdIGluaXRjYWxsIGFhdDI4NzBfaW5pdCsweDAv
MHgxNCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5Nzg2OF0gY2FsbGluZyAgaW5p
dF9zY3NpKzB4MC8weDhlIEAgMQpbICAgIDMuODk4MDEyXSBTQ1NJIHN1YnN5c3RlbSBpbml0aWFs
aXplZApbICAgIDMuODk4MTEyXSBpbml0Y2FsbCBpbml0X3Njc2krMHgwLzB4OGUgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgMy44OTgyMTNdIGNhbGxpbmcgIGF0YV9pbml0KzB4MC8weDVj
IEAgMQpbICAgIDMuODk4MzY3XSBsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4KWyAgICAzLjg5
ODQ2OF0gaW5pdGNhbGwgYXRhX2luaXQrMHgwLzB4NWMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgMy44OTg1NzFdIGNhbGxpbmcgIHBoeV9pbml0KzB4MC8weDJlIEAgMQpbICAgIDMuODk4
Njg4XSBpbml0Y2FsbCBwaHlfaW5pdCsweDAvMHgyZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjg5ODc5M10gY2FsbGluZyAgdXNiX2luaXQrMHgwLzB4MTVjIEAgMQpbICAgIDMuODk4
OTExXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzClsgICAg
My44OTkwMTldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaHViClsg
ICAgMy44OTkxNTRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiClsg
ICAgMy44OTkyNTddIGluaXRjYWxsIHVzYl9pbml0KzB4MC8weDE1YyByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjg5OTM2MV0gY2FsbGluZyAgc2VyaW9faW5pdCsweDAvMHgyZSBAIDEK
WyAgICAzLjg5OTQ2NV0gaW5pdGNhbGwgc2VyaW9faW5pdCsweDAvMHgyZSByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICAzLjg5OTU3MF0gY2FsbGluZyAgaW5wdXRfaW5pdCsweDAvMHgzYyBA
IDEKWyAgICAzLjg5OTY3Nl0gaW5pdGNhbGwgaW5wdXRfaW5pdCsweDAvMHgzYyByZXR1cm5lZCAw
IGFmdGVyIDAgdXNlY3MKWyAgICAzLjg5OTc4M10gY2FsbGluZyAgcnRjX2luaXQrMHgwLzB4NmEg
QCAxClsgICAgMy44OTk4ODZdIGluaXRjYWxsIHJ0Y19pbml0KzB4MC8weDZhIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuODk5OTg4XSBjYWxsaW5nICBwb3dlcl9zdXBwbHlfY2xhc3Nf
aW5pdCsweDAvMHg0MCBAIDEKWyAgICAzLjkwMDA5NF0gaW5pdGNhbGwgcG93ZXJfc3VwcGx5X2Ns
YXNzX2luaXQrMHgwLzB4NDAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45MDAyMThd
IGNhbGxpbmcgIGh3bW9uX2luaXQrMHgwLzB4NDcgQCAxClsgICAgMy45MDAzMjFdIGluaXRjYWxs
IGh3bW9uX2luaXQrMHgwLzB4NDcgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45MDA0
MjNdIGNhbGxpbmcgIG1kX2luaXQrMHgwLzB4MTQwIEAgMQpbICAgIDMuOTAwNTU2XSBpbml0Y2Fs
bCBtZF9pbml0KzB4MC8weDE0MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkwMDY2
MF0gY2FsbGluZyAgbW1jX2luaXQrMHgwLzB4NzEgQCAxClsgICAgMy45MDA3NzVdIGluaXRjYWxs
IG1tY19pbml0KzB4MC8weDcxIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTAwODc5
XSBjYWxsaW5nICBsZWRzX2luaXQrMHgwLzB4NDQgQCAxClsgICAgMy45MDA5ODNdIGluaXRjYWxs
IGxlZHNfaW5pdCsweDAvMHg0NCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkwMTA4
Nl0gY2FsbGluZyAgZGV2ZnJlcV9pbml0KzB4MC8weDUxIEAgMQpbICAgIDMuOTAxMTkxXSBpbml0
Y2FsbCBkZXZmcmVxX2luaXQrMHgwLzB4NTEgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAg
My45MDEyOTZdIGNhbGxpbmcgIHBjaV9zdWJzeXNfaW5pdCsweDAvMHg0YSBAIDEKWyAgICAzLjkw
MTM5Nl0gUENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwpbICAgIDMuOTMzOTk5XSBQQ0k6
IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzClsgICAgMy45MzQxNTldIHBjaSAw
MDAwOjAxOjAwLjA6IG5vIGNvbXBhdGlibGUgYnJpZGdlIHdpbmRvdyBmb3IgW21lbSAweGZmYTgw
MDAwLTB4ZmZhYmZmZmYgNjRiaXRdClsgICAgMy45MzQ0MjBdIHJlc2VydmUgUkFNIGJ1ZmZlcjog
MDAwMDAwMDAwMDA4ZDAwMCAtIDAwMDAwMDAwMDAwOGZmZmYgClsgICAgMy45MzQ1MDNdIHJlc2Vy
dmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBiZTdhNTAwMCAtIDAwMDAwMDAwYmZmZmZmZmYgClsgICAg
My45MzQ2NzldIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBiZjRhZjAwMCAtIDAwMDAwMDAw
YmZmZmZmZmYgClsgICAgMy45MzQ4NTBdIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBiZjgw
MDAwMCAtIDAwMDAwMDAwYmZmZmZmZmYgClsgICAgMy45MzUwMjBdIHJlc2VydmUgUkFNIGJ1ZmZl
cjogMDAwMDAwMDMwMTVjZjAwMCAtIDAwMDAwMDAzMDNmZmZmZmYgClsgICAgMy45MzUxOTVdIGlu
aXRjYWxsIHBjaV9zdWJzeXNfaW5pdCsweDAvMHg0YSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjkzNTM4NF0gY2FsbGluZyAgcHJvdG9faW5pdCsweDAvMHgxMiBAIDEKWyAgICAzLjkz
NTQ4Ml0gaW5pdGNhbGwgcHJvdG9faW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjkzNTU4NF0gY2FsbGluZyAgbmV0X2Rldl9pbml0KzB4MC8weDIzNyBAIDEKWyAg
ICAzLjkzNTc0Nl0gaW5pdGNhbGwgbmV0X2Rldl9pbml0KzB4MC8weDIzNyByZXR1cm5lZCAwIGFm
dGVyIDM5MDYgdXNlY3MKWyAgICAzLjkzNTg0OV0gY2FsbGluZyAgbmVpZ2hfaW5pdCsweDAvMHg4
MCBAIDEKWyAgICAzLjkzNTk0N10gaW5pdGNhbGwgbmVpZ2hfaW5pdCsweDAvMHg4MCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkzNjA0OV0gY2FsbGluZyAgZmliX3J1bGVzX2luaXQr
MHgwLzB4YWMgQCAxClsgICAgMy45MzYxNDhdIGluaXRjYWxsIGZpYl9ydWxlc19pbml0KzB4MC8w
eGFjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTM2MjQ2XSBjYWxsaW5nICBwa3Rz
Y2hlZF9pbml0KzB4MC8weGZjIEAgMQpbICAgIDMuOTM2MzQ2XSBpbml0Y2FsbCBwa3RzY2hlZF9p
bml0KzB4MC8weGZjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTM2NDQ3XSBjYWxs
aW5nICB0Y19maWx0ZXJfaW5pdCsweDAvMHg1NSBAIDEKWyAgICAzLjkzNjU0Nl0gaW5pdGNhbGwg
dGNfZmlsdGVyX2luaXQrMHgwLzB4NTUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45
MzY2NDhdIGNhbGxpbmcgIHRjX2FjdGlvbl9pbml0KzB4MC8weDU1IEAgMQpbICAgIDMuOTM2NzQ5
XSBpbml0Y2FsbCB0Y19hY3Rpb25faW5pdCsweDAvMHg1NSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjkzNjg1MF0gY2FsbGluZyAgZ2VubF9pbml0KzB4MC8weDkxIEAgMQpbICAgIDMu
OTM2OTU5XSBpbml0Y2FsbCBnZW5sX2luaXQrMHgwLzB4OTEgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgMy45MzcwNjFdIGNhbGxpbmcgIGNpcHNvX3Y0X2luaXQrMHgwLzB4NWUgQCAxClsg
ICAgMy45MzcxNjJdIGluaXRjYWxsIGNpcHNvX3Y0X2luaXQrMHgwLzB4NWUgcmV0dXJuZWQgMCBh
ZnRlciAwIHVzZWNzClsgICAgMy45MzcyNjVdIGNhbGxpbmcgIHdpcmVsZXNzX25sZXZlbnRfaW5p
dCsweDAvMHgxMiBAIDEKWyAgICAzLjkzNzM2MV0gaW5pdGNhbGwgd2lyZWxlc3NfbmxldmVudF9p
bml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTM5MTg2XSBjYWxs
aW5nICBuZXRsYmxfaW5pdCsweDAvMHg4MSBAIDEKWyAgICAzLjkzOTI4Nl0gTmV0TGFiZWw6IElu
aXRpYWxpemluZwpbICAgIDMuOTM5Mzg2XSBOZXRMYWJlbDogIGRvbWFpbiBoYXNoIHNpemUgPSAx
MjgKWyAgICAzLjkzOTQ4M10gTmV0TGFiZWw6ICBwcm90b2NvbHMgPSBVTkxBQkVMRUQgQ0lQU092
NApbICAgIDMuOTM5NTkwXSBOZXRMYWJlbDogIHVubGFiZWxlZCB0cmFmZmljIGFsbG93ZWQgYnkg
ZGVmYXVsdApbICAgIDMuOTM5NjkyXSBpbml0Y2FsbCBuZXRsYmxfaW5pdCsweDAvMHg4MSByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjkzOTc5Nl0gY2FsbGluZyAgcmZraWxsX2luaXQr
MHgwLzB4OTUgQCAxClsgICAgMy45Mzk5MzNdIGluaXRjYWxsIHJma2lsbF9pbml0KzB4MC8weDk1
IHJldHVybmVkIDAgYWZ0ZXIgMzkwNiB1c2VjcwpbICAgIDMuOTQwMDM4XSBjYWxsaW5nICBzeXNj
dGxfaW5pdCsweDAvMHg0OCBAIDEKWyAgICAzLjk0MDEzN10gaW5pdGNhbGwgc3lzY3RsX2luaXQr
MHgwLzB4NDggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45NDAyNDBdIGNhbGxpbmcg
IGFiODUwMF9ncGFkY19pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTQwMzUxXSBpbml0Y2FsbCBh
Yjg1MDBfZ3BhZGNfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAz
Ljk0MDQ1OF0gY2FsbGluZyAgaHBldF9sYXRlX2luaXQrMHgwLzB4NGEgQCAxClsgICAgMy45NDA1
NTldIGluaXRjYWxsIGhwZXRfbGF0ZV9pbml0KzB4MC8weDRhIHJldHVybmVkIC0xOSBhZnRlciAw
IHVzZWNzClsgICAgMy45NDA2NjNdIGNhbGxpbmcgIGluaXRfYW1kX25icysweDAvMHgzZCBAIDEK
WyAgICAzLjk0MDc3MF0gaW5pdGNhbGwgaW5pdF9hbWRfbmJzKzB4MC8weDNkIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTQwODc1XSBjYWxsaW5nICBjbG9ja3NvdXJjZV9kb25lX2Jv
b3RpbmcrMHgwLzB4NWEgQCAxClsgICAgMy45NDA5NzldIFN3aXRjaGluZyB0byBjbG9ja3NvdXJj
ZSB4ZW4KWyAgICAzLjk0MTA5MF0gaW5pdGNhbGwgY2xvY2tzb3VyY2VfZG9uZV9ib290aW5nKzB4
MC8weDVhIHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDMuOTQxMjE1XSBjYWxsaW5nICBm
dHJhY2VfaW5pdF9kZWJ1Z2ZzKzB4MC8weGQzIEAgMQpbICAgIDMuOTQxMzMwXSBpbml0Y2FsbCBm
dHJhY2VfaW5pdF9kZWJ1Z2ZzKzB4MC8weGQzIHJldHVybmVkIDAgYWZ0ZXIgMTIgdXNlY3MKWyAg
ICAzLjk0MTQzNV0gY2FsbGluZyAgcmJfaW5pdF9kZWJ1Z2ZzKzB4MC8weDJmIEAgMQpbICAgIDMu
OTQxNTM5XSBpbml0Y2FsbCByYl9pbml0X2RlYnVnZnMrMHgwLzB4MmYgcmV0dXJuZWQgMCBhZnRl
ciAwIHVzZWNzClsgICAgMy45NDE2NDRdIGNhbGxpbmcgIHRyYWNlcl9pbml0X2RlYnVnZnMrMHgw
LzB4MmZjIEAgMQpbICAgIDMuOTQxNzk0XSBpbml0Y2FsbCB0cmFjZXJfaW5pdF9kZWJ1Z2ZzKzB4
MC8weDJmYyByZXR1cm5lZCAwIGFmdGVyIDQ2IHVzZWNzClsgICAgMy45NDE5MDBdIGNhbGxpbmcg
IGluaXRfdHJhY2VfcHJpbnRrX2Z1bmN0aW9uX2V4cG9ydCsweDAvMHgyZiBAIDEKWyAgICAzLjk0
MjAwNl0gaW5pdGNhbGwgaW5pdF90cmFjZV9wcmludGtfZnVuY3Rpb25fZXhwb3J0KzB4MC8weDJm
IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAgIDMuOTQyMTI3XSBjYWxsaW5nICBldmVudF90
cmFjZV9pbml0KzB4MC8weDFiNSBAIDEKWyAgICAzLjk0NzEyMl0gaW5pdGNhbGwgZXZlbnRfdHJh
Y2VfaW5pdCsweDAvMHgxYjUgcmV0dXJuZWQgMCBhZnRlciA0Nzc2IHVzZWNzClsgICAgMy45NDcy
MjldIGNhbGxpbmcgIGluaXRfa3Byb2JlX3RyYWNlKzB4MC8weDk0IEAgMQpbICAgIDMuOTQ3MzM1
XSBpbml0Y2FsbCBpbml0X2twcm9iZV90cmFjZSsweDAvMHg5NCByZXR1cm5lZCAwIGFmdGVyIDMg
dXNlY3MKWyAgICAzLjk0NzQ0MV0gY2FsbGluZyAgaW5pdF9waXBlX2ZzKzB4MC8weDRiIEAgMQpb
ICAgIDMuOTQ3NTQ5XSBpbml0Y2FsbCBpbml0X3BpcGVfZnMrMHgwLzB4NGIgcmV0dXJuZWQgMCBh
ZnRlciA4IHVzZWNzClsgICAgMy45NDc2NTRdIGNhbGxpbmcgIGV2ZW50cG9sbF9pbml0KzB4MC8w
eGRhIEAgMQpbICAgIDMuOTQ3NzU2XSBpbml0Y2FsbCBldmVudHBvbGxfaW5pdCsweDAvMHhkYSBy
ZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICAzLjk0Nzg1OF0gY2FsbGluZyAgYW5vbl9pbm9k
ZV9pbml0KzB4MC8weDdkIEAgMQpbICAgIDMuOTQ3OTY1XSBpbml0Y2FsbCBhbm9uX2lub2RlX2lu
aXQrMHgwLzB4N2QgcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzClsgICAgMy45NDgwNzBdIGNhbGxp
bmcgIHRvbW95b19pbml0ZXJmYWNlX2luaXQrMHgwLzB4MjcgQCAxClsgICAgMy45NDgxNjldIGlu
aXRjYWxsIHRvbW95b19pbml0ZXJmYWNlX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgMy45NDgyNzVdIGNhbGxpbmcgIGFhX2NyZWF0ZV9hYWZzKzB4MC8weDkyIEAg
MQpbICAgIDMuOTQ4NDAzXSBBcHBBcm1vcjogQXBwQXJtb3IgRmlsZXN5c3RlbSBFbmFibGVkClsg
ICAgMy45NDg1MDRdIGluaXRjYWxsIGFhX2NyZWF0ZV9hYWZzKzB4MC8weDkyIHJldHVybmVkIDAg
YWZ0ZXIgMTI0IHVzZWNzClsgICAgMy45NDg2MDddIGNhbGxpbmcgIGJsa19zY3NpX2lvY3RsX2lu
aXQrMHgwLzB4ZCBAIDEKWyAgICAzLjk0ODcwN10gaW5pdGNhbGwgYmxrX3Njc2lfaW9jdGxfaW5p
dCsweDAvMHhkIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTQ4ODEwXSBjYWxsaW5n
ICBhY3BpX2V2ZW50X2luaXQrMHgwLzB4N2QgQCAxClsgICAgMy45NDg5MTddIGluaXRjYWxsIGFj
cGlfZXZlbnRfaW5pdCsweDAvMHg3ZCByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MKWyAgICAzLjk0
OTAyMl0gY2FsbGluZyAgcG5wX3N5c3RlbV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDMuOTQ5MTM5
XSBpbml0Y2FsbCBwbnBfc3lzdGVtX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAxMyB1
c2VjcwpbICAgIDMuOTQ5MjQ0XSBjYWxsaW5nICBwbnBhY3BpX2luaXQrMHgwLzB4OGMgQCAxClsg
ICAgMy45NDkzNDVdIHBucDogUG5QIEFDUEkgaW5pdApbICAgIDMuOTQ5NDUzXSBBQ1BJOiBidXMg
dHlwZSBwbnAgcmVnaXN0ZXJlZApbICAgIDMuOTQ5NzIwXSBwbnAgMDA6MDA6IFtidXMgMDAtZmZd
ClsgICAgMy45NDk4MTldIHBucCAwMDowMDogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDMuOTQ5
OTIwXSBwbnAgMDA6MDA6IFtpbyAgMHgwMDAwLTB4MDNhZiB3aW5kb3ddClsgICAgMy45NTAwMjFd
IHBucCAwMDowMDogW2lvICAweDAzZTAtMHgwY2Y3IHdpbmRvd10KWyAgICAzLjk1MDEyMl0gcG5w
IDAwOjAwOiBbaW8gIDB4MDNiMC0weDAzZGYgd2luZG93XQpbICAgIDMuOTUwMjI0XSBwbnAgMDA6
MDA6IFtpbyAgMHgwZDAwLTB4ZmZmZiB3aW5kb3ddClsgICAgMy45NTAzMjZdIHBucCAwMDowMDog
W21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmYgd2luZG93XQpbICAgIDMuOTUwNDI4XSBwbnAgMDA6
MDA6IFttZW0gMHgwMDBjMDAwMC0weDAwMGRmZmZmIHdpbmRvd10KWyAgICAzLjk1MDUyOV0gcG5w
IDAwOjAwOiBbbWVtIDB4ZjAwMDAwMDAtMHhmYmZmZmZmZiB3aW5kb3ddClsgICAgMy45NTA2MzFd
IHBucCAwMDowMDogW21lbSAweDAwMDAwMDAwIHdpbmRvd10KWyAgICAzLjk1MDc4OF0gcG5wIDAw
OjAwOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwOCBQTlAwYTAzIChhY3Rp
dmUpClsgICAgMy45NTA5ODFdIHBucCAwMDowMTogW21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZd
ClsgICAgMy45NTEwODFdIHBucCAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdClsg
ICAgMy45NTExODJdIHBucCAwMDowMTogW21lbSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdClsgICAg
My45NTEyODRdIHBucCAwMDowMTogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdClsgICAgMy45
NTEzODVdIHBucCAwMDowMTogW21lbSAweGZlZTAwMDAwLTB4ZmVlMGZmZmZdClsgICAgMy45NTE1
MTVdIHN5c3RlbSAwMDowMTogW21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZdIGhhcyBiZWVuIHJl
c2VydmVkClsgICAgMy45NTE2MTldIHN5c3RlbSAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZm
ZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy45NTE3MjJdIHN5c3RlbSAwMDowMTogW21l
bSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy45NTE4MjZd
IHN5c3RlbSAwMDowMTogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdIGhhcyBiZWVuIHJlc2Vy
dmVkClsgICAgMy45NTE5MzFdIHN5c3RlbSAwMDowMTogW21lbSAweGZlZTAwMDAwLTB4ZmVlMGZm
ZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDMuOTUyMDM3XSBzeXN0ZW0gMDA6MDE6IFBs
dWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAxIChhY3RpdmUpClsgICAgMy45NTIx
NTNdIHBucCAwMDowMjogW2RtYSA0XQpbICAgIDMuOTUyMjUxXSBwbnAgMDA6MDI6IFtpbyAgMHgw
MDAwLTB4MDAwZl0KWyAgICAzLjk1MjM1MF0gcG5wIDAwOjAyOiBbaW8gIDB4MDA4MS0weDAwODNd
ClsgICAgMy45NTI0NTFdIHBucCAwMDowMjogW2lvICAweDAwODddClsgICAgMy45NTI1NDldIHBu
cCAwMDowMjogW2lvICAweDAwODktMHgwMDhiXQpbICAgIDMuOTUyNjQ4XSBwbnAgMDA6MDI6IFtp
byAgMHgwMDhmXQpbICAgIDMuOTUyNzQ2XSBwbnAgMDA6MDI6IFtpbyAgMHgwMGMwLTB4MDBkZl0K
WyAgICAzLjk1Mjg2NF0gcG5wIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDIwMCAoYWN0aXZlKQpbICAgIDMuOTUyOTc4XSBwbnAgMDA6MDM6IFtpbyAgMHgwMDcwLTB4
MDA3MV0KWyAgICAzLjk1MzA3OF0geGVuOiByZWdpc3RlcmluZyBnc2kgOCB0cmlnZ2VyaW5nIDEg
cG9sYXJpdHkgMApbICAgIDMuOTUzMTg4XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx
IDggZm9yIGdzaSA4ClsgICAgMy45NTMyOTFdIHhlbjogLS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3Np
PTgpClsgICAgMy45NTM0MTldIHBucCAwMDowMzogW2lycSA4XQpbICAgIDMuOTUzNTM0XSBwbnAg
MDA6MDM6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYjAwIChhY3RpdmUpClsg
ICAgMy45NTM2NDRdIHBucCAwMDowNDogW2lvICAweDAwNjFdClsgICAgMy45NTM3NTddIHBucCAw
MDowNDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA4MDAgKGFjdGl2ZSkKWyAg
ICAzLjk1Mzg3OV0gcG5wIDAwOjA1OiBbaW8gIDB4MDAxMC0weDAwMWZdClsgICAgMy45NTM5Nzhd
IHBucCAwMDowNTogW2lvICAweDAwMjItMHgwMDNmXQpbICAgIDMuOTU0MDc3XSBwbnAgMDA6MDU6
IFtpbyAgMHgwMDQ0LTB4MDA1Zl0KWyAgICAzLjk1NDE3N10gcG5wIDAwOjA1OiBbaW8gIDB4MDA2
Mi0weDAwNjNdClsgICAgMy45NTQyNzhdIHBucCAwMDowNTogW2lvICAweDAwNjUtMHgwMDZmXQpb
ICAgIDMuOTU0Mzc2XSBwbnAgMDA6MDU6IFtpbyAgMHgwMDcyLTB4MDA3Zl0KWyAgICAzLjk1NDQ3
NF0gcG5wIDAwOjA1OiBbaW8gIDB4MDA4MF0KWyAgICAzLjk1NDU3Ml0gcG5wIDAwOjA1OiBbaW8g
IDB4MDA4NC0weDAwODZdClsgICAgMy45NTQ2NzJdIHBucCAwMDowNTogW2lvICAweDAwODhdClsg
ICAgMy45NTQ3NjhdIHBucCAwMDowNTogW2lvICAweDAwOGMtMHgwMDhlXQpbICAgIDMuOTU0ODY4
XSBwbnAgMDA6MDU6IFtpbyAgMHgwMDkwLTB4MDA5Zl0KWyAgICAzLjk1NDk2OV0gcG5wIDAwOjA1
OiBbaW8gIDB4MDBhMi0weDAwYmZdClsgICAgMy45NTUwNjhdIHBucCAwMDowNTogW2lvICAweDAw
ZTAtMHgwMGVmXQpbICAgIDMuOTU1MTY4XSBwbnAgMDA6MDU6IFtpbyAgMHgwNGQwLTB4MDRkMV0K
WyAgICAzLjk1NTI5N10gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVu
IHJlc2VydmVkClsgICAgMy45NTU0MDBdIHN5c3RlbSAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJ
IGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICAzLjk1NTUxMF0gcG5wIDAwOjA2OiBb
aW8gIDB4MDBmMC0weDAwZmZdClsgICAgMy45NTU2MTBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDEz
IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwClsgICAgMy45NTU3MTJdIHhlbl9tYXBfcGlycV9nc2k6
IHJldHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwpbICAgIDMuOTU1ODEzXSB4ZW46IC0tPiBwaXJx
PTEzIC0+IGlycT0xMyAoZ3NpPTEzKQpbICAgIDMuOTU1OTQyXSBwbnAgMDA6MDY6IFtpcnEgMTNd
ClsgICAgMy45NTYwNTddIHBucCAwMDowNjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDBjMDQgKGFjdGl2ZSkKWyAgICAzLjk1NjI0OV0gcG5wIDAwOjA3OiBbaW8gIDB4MDAwMC0w
eGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NTYzNTNdIHBucCAwMDowNzogW2lv
ICAweDBhMDAtMHgwYTFmXQpbICAgIDMuOTU2NDUxXSBwbnAgMDA6MDc6IFtpbyAgMHgwYTMwLTB4
MGEzZl0KWyAgICAzLjk1NjU1Ml0gcG5wIDAwOjA3OiBbaW8gIDB4MDAwMC0weGZmZmZmZmZmZmZm
ZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NTY2ODNdIHN5c3RlbSAwMDowNzogW2lvICAweDBhMDAt
MHgwYTFmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuOTU2Nzg2XSBzeXN0ZW0gMDA6MDc6IFtp
byAgMHgwYTMwLTB4MGEzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjk1Njg5MF0gc3lzdGVt
IDAwOjA3OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAoYWN0aXZlKQpb
ICAgIDMuOTU3MDEwXSBwbnAgMDA6MDg6IFtpbyAgMHgwMDYwXQpbICAgIDMuOTU3MTExXSBwbnAg
MDA6MDg6IFtpbyAgMHgwMDY0XQpbICAgIDMuOTU3MjA5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwClsgICAgMy45NTczMTRdIHhlbl9tYXBfcGlycV9nc2k6
IHJldHVybmluZyBpcnEgMSBmb3IgZ3NpIDEKWyAgICAzLjk1NzQxNl0geGVuOiAtLT4gcGlycT0x
IC0+IGlycT0xIChnc2k9MSkKWyAgICAzLjk1NzU0NF0gcG5wIDAwOjA4OiBbaXJxIDFdClsgICAg
My45NTc2NjRdIHBucCAwMDowODogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAz
MDMgUE5QMDMwYiAoYWN0aXZlKQpbICAgIDMuOTU3ODEzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
MiB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDMuOTU3OTE1XSB4ZW5fbWFwX3BpcnFfZ3Np
OiByZXR1cm5pbmcgaXJxIDEyIGZvciBnc2kgMTIKWyAgICAzLjk1ODAxN10geGVuOiAtLT4gcGly
cT0xMiAtPiBpcnE9MTIgKGdzaT0xMikKWyAgICAzLjk1ODE0M10gcG5wIDAwOjA5OiBbaXJxIDEy
XQpbICAgIDMuOTU4MjY1XSBwbnAgMDA6MDk6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE
cyBQTlAwZjAzIFBOUDBmMTMgKGFjdGl2ZSkKWyAgICAzLjk1ODY3Nl0gcG5wIDAwOjBhOiBbaW8g
IDB4MDNmOC0weDAzZmZdClsgICAgMy45NTg3NzVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDQgdHJp
Z2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAzLjk1ODg3N10geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSA0IGZvciBnc2kgNApbICAgIDMuOTU4OTc4XSB4ZW46IC0tPiBwaXJxPTQgLT4g
aXJxPTQgKGdzaT00KQpbICAgIDMuOTU5MTA2XSBwbnAgMDA6MGE6IFtpcnEgNF0KWyAgICAzLjk1
OTIwNF0gcG5wIDAwOjBhOiBbZG1hIDAgZGlzYWJsZWRdClsgICAgMy45NTkzNTFdIHBucCAwMDow
YTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEgKGFjdGl2ZSkKWyAgICAz
Ljk1OTczNl0gcG5wIDAwOjBiOiBbaW8gIDB4MDJmOC0weDAyZmZdClsgICAgMy45NTk4MzZdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDMgdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAzLjk1OTkz
OV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAzIGZvciBnc2kgMwpbICAgIDMuOTYw
MDM5XSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQpbICAgIDMuOTYwMTY2XSBwbnAg
MDA6MGI6IFtpcnEgM10KWyAgICAzLjk2MDI2M10gcG5wIDAwOjBiOiBbZG1hIDAgZGlzYWJsZWRd
ClsgICAgMy45NjA0MDVdIHBucCAwMDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDA1MDEgKGFjdGl2ZSkKWyAgICAzLjk2MDYwMl0gcG5wIDAwOjBjOiBbaW8gIDB4MDAwMC0w
eGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NjA3MDZdIHBucCAwMDowYzogW2lv
ICAweDBiMDAtMHgwYjdmXQpbICAgIDMuOTYwODA2XSBwbnAgMDA6MGM6IFtpbyAgMHgwMDAwLTB4
ZmZmZmZmZmZmZmZmZmZmZiBkaXNhYmxlZF0KWyAgICAzLjk2MDkwOF0gcG5wIDAwOjBjOiBbaW8g
IDB4MDAwMC0weGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgMy45NjEwMTFdIHBucCAw
MDowYzogW2lvICAweDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZmIGRpc2FibGVkXQpbICAgIDMuOTYx
MTQ4XSBzeXN0ZW0gMDA6MGM6IFtpbyAgMHgwYjAwLTB4MGI3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQK
WyAgICAzLjk2MTI1M10gc3lzdGVtIDAwOjBjOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJ
RHMgUE5QMGMwMiAoYWN0aXZlKQpbICAgIDMuOTYxNTg5XSBwbnAgMDA6MGQ6IFtpbyAgMHgwM2U4
LTB4MDNlZl0KWyAgICAzLjk2MTY5MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTAgdHJpZ2dlcmlu
ZyAxIHBvbGFyaXR5IDAKWyAgICAzLjk2MTc5M10geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n
IGlycSAxMCBmb3IgZ3NpIDEwClsgICAgMy45NjE4OTRdIHhlbjogLS0+IHBpcnE9MTAgLT4gaXJx
PTEwIChnc2k9MTApClsgICAgMy45NjIwMjJdIHBucCAwMDowZDogW2lycSAxMF0KWyAgICAzLjk2
MjEyMV0gcG5wIDAwOjBkOiBbZG1hIDAgZGlzYWJsZWRdClsgICAgMy45NjIyNTldIHBucCAwMDow
ZDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEgKGFjdGl2ZSkKWyAgICAz
Ljk2MjU3MV0gcG5wIDAwOjBlOiBbaW8gIDB4MDQwMC0weDA0NTNdClsgICAgMy45NjI2NzJdIHBu
cCAwMDowZTogW2lvICAweDA0NTgtMHgwNDdmXQpbICAgIDMuOTYyNzczXSBwbnAgMDA6MGU6IFtp
byAgMHgxMTgwLTB4MTE5Zl0KWyAgICAzLjk2Mjg3M10gcG5wIDAwOjBlOiBbaW8gIDB4MDUwMC0w
eDA1N2ZdClsgICAgMy45NjI5NzFdIHBucCAwMDowZTogW21lbSAweGZlZDFjMDAwLTB4ZmVkMWZm
ZmZdClsgICAgMy45NjMwNzJdIHBucCAwMDowZTogW21lbSAweGZlYzAwMDAwLTB4ZmVjZmZmZmZd
ClsgICAgMy45NjMxNzJdIHBucCAwMDowZTogW21lbSAweGZlZDA4MDAwLTB4ZmVkMDhmZmZdClsg
ICAgMy45NjMyNzJdIHBucCAwMDowZTogW21lbSAweGZmMDAwMDAwLTB4ZmZmZmZmZmZdClsgICAg
My45NjM0MDVdIHN5c3RlbSAwMDowZTogW2lvICAweDA0MDAtMHgwNDUzXSBoYXMgYmVlbiByZXNl
cnZlZApbICAgIDMuOTYzNTEwXSBzeXN0ZW0gMDA6MGU6IFtpbyAgMHgwNDU4LTB4MDQ3Zl0gaGFz
IGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjk2MzYxNV0gc3lzdGVtIDAwOjBlOiBbaW8gIDB4MTE4MC0w
eDExOWZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMy45NjM3MThdIHN5c3RlbSAwMDowZTogW2lv
ICAweDA1MDAtMHgwNTdmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDMuOTYzODE3XSBzeXN0ZW0g
MDA6MGU6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg
IDMuOTYzOTIyXSBzeXN0ZW0gMDA6MGU6IFttZW0gMHhmZWMwMDAwMC0weGZlY2ZmZmZmXSBjb3Vs
ZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICAzLjk2NDAyOF0gc3lzdGVtIDAwOjBlOiBbbWVtIDB4ZmVk
MDgwMDAtMHhmZWQwOGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAzLjk2NDEzM10gc3lzdGVt
IDAwOjBlOiBbbWVtIDB4ZmYwMDAwMDAtMHhmZmZmZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAg
ICAzLjk2NDIzNV0gc3lzdGVtIDAwOjBlOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMGMwMSAoYWN0aXZlKQpbICAgIDMuOTY2MDcyXSBwbnAgMDA6MGY6IFtpbyAgMHgwNDU0LTB4
MDQ1N10KWyAgICAzLjk2NjIwMF0gc3lzdGVtIDAwOjBmOiBbaW8gIDB4MDQ1NC0weDA0NTddIGhh
cyBiZWVuIHJlc2VydmVkClsgICAgMy45NjYzMDRdIHN5c3RlbSAwMDowZjogUGx1ZyBhbmQgUGxh
eSBBQ1BJIGRldmljZSwgSURzIElOVDNmMGQgUE5QMGMwMiAoYWN0aXZlKQpbICAgIDMuOTY2NTU1
XSBwbnAgMDA6MTA6IFttZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmXQpbICAgIDMuOTY2NjkyXSBw
bnAgMDA6MTA6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMTAzIChhY3RpdmUp
ClsgICAgMy45NjY5NjVdIHBucDogUG5QIEFDUEk6IGZvdW5kIDE3IGRldmljZXMKWyAgICAzLjk2
NzA2NV0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVkClsgICAgMy45NjcxNjhd
IGluaXRjYWxsIHBucGFjcGlfaW5pdCsweDAvMHg4YyByZXR1cm5lZCAwIGFmdGVyIDE3NDAzIHVz
ZWNzClsgICAgMy45NjcyNzJdIGNhbGxpbmcgIGNocl9kZXZfaW5pdCsweDAvMHgxYiBAIDEKWyAg
ICAzLjk2OTM3NV0gaW5pdGNhbGwgY2hyX2Rldl9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0
ZXIgMTk1NiB1c2VjcwpbICAgIDMuOTY5NDgxXSBjYWxsaW5nICBmaXJtd2FyZV9jbGFzc19pbml0
KzB4MC8weDE5IEAgMQpbICAgIDMuOTY5NTg1XSBpbml0Y2FsbCBmaXJtd2FyZV9jbGFzc19pbml0
KzB4MC8weDE5IHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDMuOTY5NjkxXSBjYWxsaW5n
ICB0aGVybWFsX2luaXQrMHgwLzB4NzIgQCAxClsgICAgMy45Njk3OTZdIGluaXRjYWxsIHRoZXJt
YWxfaW5pdCsweDAvMHg3MiByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MKWyAgICAzLjk2OTg5OV0g
Y2FsbGluZyAgY3B1ZnJlcV9nb3ZfcGVyZm9ybWFuY2VfaW5pdCsweDAvMHgxMiBAIDEKWyAgICAz
Ljk3MDAwM10gaW5pdGNhbGwgY3B1ZnJlcV9nb3ZfcGVyZm9ybWFuY2VfaW5pdCsweDAvMHgxMiBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjk3MDEyOV0gY2FsbGluZyAgaW5pdF9hY3Bp
X3BtX2Nsb2Nrc291cmNlKzB4MC8weGQ5IEAgMQpbICAgIDMuOTczNDg2XSBQTS1UaW1lciBmYWls
ZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4ZmZmZmZmKSAtIGFib3J0aW5nLgpbICAgIDMuOTcz
NTkxXSBpbml0Y2FsbCBpbml0X2FjcGlfcG1fY2xvY2tzb3VyY2UrMHgwLzB4ZDkgcmV0dXJuZWQg
LTE5IGFmdGVyIDMyNzggdXNlY3MKWyAgICAzLjk3MzcxMl0gY2FsbGluZyAgcGNpYmlvc19hc3Np
Z25fcmVzb3VyY2VzKzB4MC8weDc2IEAgMQpbICAgIDMuOTczODIxXSBQQ0k6IG1heCBidXMgZGVw
dGg6IDEgcGNpX3RyeV9udW06IDIKWyAgICAzLjk3NDAzMF0gcGNpIDAwMDA6MDE6MDAuMDogQkFS
IDM6IGFzc2lnbmVkIFttZW0gMHhmYmE4MDAwMC0weGZiYWJmZmZmIDY0Yml0XQpbICAgIDMuOTc0
MTU4XSBwY2kgMDAwMDowMTowMC4wOiBCQVIgMzogc2V0IHRvIFttZW0gMHhmYmE4MDAwMC0weGZi
YWJmZmZmIDY0Yml0XSAoUENJIGFkZHJlc3MgWzB4ZmJhODAwMDAtMHhmYmFiZmZmZl0pClsgICAg
My45NzQyODddIHBjaSAwMDAwOjAwOjAxLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMS0wMV0KWyAg
ICAzLjk3NDM5MF0gcGNpIDAwMDA6MDA6MDEuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAw
LTB4ZWZmZl0KWyAgICAzLjk3NDQ5N10gcGNpIDAwMDA6MDA6MDEuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhmYmEwMDAwMC0weGZiYWZmZmZmXQpbICAgIDMuOTc0NjA4XSBwY2kgMDAwMDowMDox
Yy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdClsgICAgMy45NzQ3NTddIHBjaSAwMDAwOjAw
OjFjLjQ6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMy0wM10KWyAgICAzLjk3NDg2NV0gcGNpIDAwMDA6
MDA6MWMuNDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0KWyAgICAzLjk3NDk4
M10gcGNpIDAwMDA6MDA6MWMuNDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYjkwMDAwMC0weGZi
OWZmZmZmXQpbICAgIDMuOTc1MTIzXSBwY2kgMDAwMDowMDoxZS4wOiBQQ0kgYnJpZGdlIHRvIFti
dXMgMDQtMDRdClsgICAgMy45NzUyMzhdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRv
dyBbbWVtIDB4ZmIwMDAwMDAtMHhmYjhmZmZmZl0KWyAgICAzLjk3NTM1MF0gcGNpIDAwMDA6MDA6
MWUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAwMC0weGZhZmZmZmZmIDY0Yml0IHBy
ZWZdClsgICAgMy45NzU0OTZdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxClsgICAgMy45NzU2MDRdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9
MTYpClsgICAgMy45NzU3MzFdIHBjaSAwMDAwOjAwOjAxLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYg
KGxldmVsLCBsb3cpIC0+IElSUSAxNgpbICAgIDMuOTc1ODM5XSBwY2kgMDAwMDowMDowMS4wOiBz
ZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAzLjk3NTk1NV0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAzLjk3NjA1N10geGVuOiAtLT4g
cGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykKWyAgICAzLjk3NjE4Ml0gcGNpIDAwMDA6MDA6MWMu
MDogUENJIElOVCBBIC0+IEdTSSAxNyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgMy45NzYy
OTddIHBjaSAwMDAwOjAwOjFjLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDMu
OTc2NDE5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpb
ICAgIDMuOTc2NTIwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kg
MTcKWyAgICAzLjk3NjYxOV0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykKWyAg
ICAzLjk3NjcxOV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNwpbICAgIDMuOTc2ODE2XSBwY2kg
MDAwMDowMDoxYy40OiBQQ0kgSU5UIEEgLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJUlEgMTcK
WyAgICAzLjk3NjkzMl0gcGNpIDAwMDA6MDA6MWMuNDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRv
IDY0ClsgICAgMy45NzcwNTJdIHBjaSAwMDAwOjAwOjFlLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1l
ciB0byA2NApbICAgIDMuOTc3MTU5XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDQgW2lvICAw
eDAwMDAtMHgwM2FmXQpbICAgIDMuOTc3MjYwXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDUg
W2lvICAweDAzZTAtMHgwY2Y3XQpbICAgIDMuOTc3MzYzXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291
cmNlIDYgW2lvICAweDAzYjAtMHgwM2RmXQpbICAgIDMuOTc3NDY1XSBwY2lfYnVzIDAwMDA6MDA6
IHJlc291cmNlIDcgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDMuOTc3NTY3XSBwY2lfYnVzIDAw
MDA6MDA6IHJlc291cmNlIDggW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgMy45Nzc2
NzFdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgOSBbbWVtIDB4MDAwYzAwMDAtMHgwMDBkZmZm
Zl0KWyAgICAzLjk3Nzc3NV0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxMCBbbWVtIDB4ZjAw
MDAwMDAtMHhmYmZmZmZmZl0KWyAgICAzLjk3Nzg3N10gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJj
ZSAwIFtpbyAgMHhlMDAwLTB4ZWZmZl0KWyAgICAzLjk3Nzk4MV0gcGNpX2J1cyAwMDAwOjAxOiBy
ZXNvdXJjZSAxIFttZW0gMHhmYmEwMDAwMC0weGZiYWZmZmZmXQpbICAgIDMuOTc4MDgzXSBwY2lf
YnVzIDAwMDA6MDM6IHJlc291cmNlIDAgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDMuOTc4MTg2
XSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDEgW21lbSAweGZiOTAwMDAwLTB4ZmI5ZmZmZmZd
ClsgICAgMy45NzgyODldIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgMSBbbWVtIDB4ZmIwMDAw
MDAtMHhmYjhmZmZmZl0KWyAgICAzLjk3ODM5NF0gcGNpX2J1cyAwMDAwOjA0OiByZXNvdXJjZSAy
IFttZW0gMHhmYTAwMDAwMC0weGZhZmZmZmZmIDY0Yml0IHByZWZdClsgICAgMy45Nzg1MThdIHBj
aV9idXMgMDAwMDowNDogcmVzb3VyY2UgNCBbaW8gIDB4MDAwMC0weDAzYWZdClsgICAgMy45Nzg2
MThdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgNSBbaW8gIDB4MDNlMC0weDBjZjddClsgICAg
My45Nzg3MjBdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgNiBbaW8gIDB4MDNiMC0weDAzZGZd
ClsgICAgMy45Nzg4MjFdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgNyBbaW8gIDB4MGQwMC0w
eGZmZmZdClsgICAgMy45Nzg5MjRdIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgOCBbbWVtIDB4
MDAwYTAwMDAtMHgwMDBiZmZmZl0KWyAgICAzLjk3OTAyOF0gcGNpX2J1cyAwMDAwOjA0OiByZXNv
dXJjZSA5IFttZW0gMHgwMDBjMDAwMC0weDAwMGRmZmZmXQpbICAgIDMuOTc5MTMxXSBwY2lfYnVz
IDAwMDA6MDQ6IHJlc291cmNlIDEwIFttZW0gMHhmMDAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDMu
OTc5MjM0XSBpbml0Y2FsbCBwY2liaW9zX2Fzc2lnbl9yZXNvdXJjZXMrMHgwLzB4NzYgcmV0dXJu
ZWQgMCBhZnRlciA1MjkxIHVzZWNzClsgICAgMy45NzkzNTddIGNhbGxpbmcgIHN5c2N0bF9jb3Jl
X2luaXQrMHgwLzB4MzggQCAxClsgICAgMy45Nzk0NjhdIGluaXRjYWxsIHN5c2N0bF9jb3JlX2lu
aXQrMHgwLzB4MzggcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNzClsgICAgMy45Nzk1NzNdIGNhbGxp
bmcgIGluZXRfaW5pdCsweDAvMHgyN2QgQCAxClsgICAgMy45Nzk2ODVdIE5FVDogUmVnaXN0ZXJl
ZCBwcm90b2NvbCBmYW1pbHkgMgpbICAgIDMuOTgwODgxXSBJUCByb3V0ZSBjYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDUyNDI4OCAob3JkZXI6IDEwLCA0MTk0MzA0IGJ5dGVzKQpbICAgIDMuOTgz
MzgzXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MjQyODggKG9yZGVyOiAx
MSwgODM4ODYwOCBieXRlcykKWyAgICAzLjk4NDY3N10gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRy
aWVzOiA2NTUzNiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpClsgICAgMy45ODQ4OTddIFRDUDog
SGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgNTI0Mjg4IGJpbmQgNjU1MzYpClsg
ICAgMy45ODUwMDVdIFRDUCByZW5vIHJlZ2lzdGVyZWQKWyAgICAzLjk4NTE4N10gVURQIGhhc2gg
dGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKWyAgICAzLjk4NTQw
MF0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA4MTkyIChvcmRlcjogNiwgMjYyMTQ0IGJ5
dGVzKQpbICAgIDMuOTg1NTkzXSBpbml0Y2FsbCBpbmV0X2luaXQrMHgwLzB4MjdkIHJldHVybmVk
IDAgYWZ0ZXIgNTc3NSB1c2VjcwpbICAgIDMuOTg1NzAwXSBjYWxsaW5nICBhZl91bml4X2luaXQr
MHgwLzB4NTIgQCAxClsgICAgMy45ODU4MDFdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMQpbICAgIDMuOTg1OTA0XSBpbml0Y2FsbCBhZl91bml4X2luaXQrMHgwLzB4NTIgcmV0dXJu
ZWQgMCBhZnRlciAxMDAgdXNlY3MKWyAgICAzLjk4NjAwOV0gY2FsbGluZyAgcGNpX2FwcGx5X2Zp
bmFsX3F1aXJrcysweDAvMHgxMDUgQCAxClsgICAgMy45ODYxNDNdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgMy45ODYyNDldIHhlbl9tYXBfcGly
cV9nc2k6IHJldHVybmluZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDMuOTg2MzUyXSB4ZW46IC0t
PiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDMuOTg2NDU0XSBBbHJlYWR5IHNldHVw
IHRoZSBHU0kgOjE2ClsgICAgMy45ODY1NTVdIHBjaSAwMDAwOjAwOjFhLjA6IFBDSSBJTlQgQSAt
PiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAxNgpbICAgIDMuOTg2NzA0XSBwY2kgMDAwMDow
MDoxYS4wOiBQQ0kgSU5UIEEgZGlzYWJsZWQKWyAgICAzLjk4NjgzNl0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMjMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAzLjk4Njk0M10geGVuOiAtLT4g
cGlycT0yMyAtPiBpcnE9MjMgKGdzaT0yMykKWyAgICAzLjk4NzA3M10gcGNpIDAwMDA6MDA6MWQu
MDogUENJIElOVCBBIC0+IEdTSSAyMyAobGV2ZWwsIGxvdykgLT4gSVJRIDIzClsgICAgMy45ODcy
MzJdIHBjaSAwMDAwOjAwOjFkLjA6IFBDSSBJTlQgQSBkaXNhYmxlZApbICAgIDMuOTg3NDM5XSBw
Y2kgMDAwMDowNDowMy4wOiBCb290IHZpZGVvIGRldmljZQpbICAgIDMuOTg3NTQwXSBQQ0k6IENM
UyA2NCBieXRlcywgZGVmYXVsdCA2NApbICAgIDMuOTg3NjM4XSBpbml0Y2FsbCBwY2lfYXBwbHlf
ZmluYWxfcXVpcmtzKzB4MC8weDEwNSByZXR1cm5lZCAwIGFmdGVyIDE0ODkgdXNlY3MKWyAgICAz
Ljk4Nzc2M10gY2FsbGluZyAgcG9wdWxhdGVfcm9vdGZzKzB4MC8weDI0IEAgMQpbICAgIDMuOTg3
ODYyXSBpbml0Y2FsbCBwb3B1bGF0ZV9yb290ZnMrMHgwLzB4MjQgcmV0dXJuZWQgMjc0Nzg3NTI2
IGFmdGVyIDAgdXNlY3MKWyAgICAzLjk4Nzk4M10gaW5pdGNhbGwgcG9wdWxhdGVfcm9vdGZzKzB4
MC8weDI0IHJldHVybmVkIHdpdGggZXJyb3IgY29kZSAyNzQ3ODc1MjYgClsgICAgMy45ODgxMDZd
IGNhbGxpbmcgIHBjaV9pb21tdV9pbml0KzB4MC8weDNlIEAgMQpbICAgIDMuOTg4MjA2XSBpbml0
Y2FsbCBwY2lfaW9tbXVfaW5pdCsweDAvMHgzZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg
ICAzLjk4ODMwOF0gY2FsbGluZyAgY2FsZ2FyeV9maXh1cF90Y2Vfc3BhY2VzKzB4MC8weDJiIEAg
MQpbICAgIDMuOTg4NDA4XSBpbml0Y2FsbCBjYWxnYXJ5X2ZpeHVwX3RjZV9zcGFjZXMrMHgwLzB4
MmIgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MKWyAgICAzLjk4ODUzMl0gY2FsbGluZyAgaXJf
ZGV2X3Njb3BlX2luaXQrMHgwLzB4MTYgQCAxClsgICAgMy45ODg2MjldIGluaXRjYWxsIGlyX2Rl
dl9zY29wZV9pbml0KzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTg4
NzMxXSBjYWxsaW5nICBpODI1OUFfaW5pdF9vcHMrMHgwLzB4MjEgQCAxClsgICAgMy45ODg4MzFd
IGluaXRjYWxsIGk4MjU5QV9pbml0X29wcysweDAvMHgyMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICAzLjk4ODkzNF0gY2FsbGluZyAgdnN5c2NhbGxfaW5pdCsweDAvMHgyNyBAIDEKWyAg
ICAzLjk4OTAzOV0gaW5pdGNhbGwgdnN5c2NhbGxfaW5pdCsweDAvMHgyNyByZXR1cm5lZCAwIGFm
dGVyIDYgdXNlY3MKWyAgICAzLjk4OTE0Ml0gY2FsbGluZyAgc2JmX2luaXQrMHgwLzB4MTYgQCAx
ClsgICAgMy45ODkyNDJdIGluaXRjYWxsIHNiZl9pbml0KzB4MC8weDE2IHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDMuOTg5MzQ0XSBjYWxsaW5nICBpbml0X3RzY19jbG9ja3NvdXJjZSsw
eDAvMHg1ZiBAIDEKWyAgICAzLjk4OTQ1M10gaW5pdGNhbGwgaW5pdF90c2NfY2xvY2tzb3VyY2Ur
MHgwLzB4NWYgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgMy45ODk1NTRdIGNhbGxpbmcg
IGFkZF9ydGNfY21vcysweDAvMHg5NiBAIDEKWyAgICAzLjk4OTY1N10gaW5pdGNhbGwgYWRkX3J0
Y19jbW9zKzB4MC8weDk2IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAgIDMuOTg5NzU3XSBj
YWxsaW5nICBpODIzN0FfaW5pdF9vcHMrMHgwLzB4MTQgQCAxClsgICAgMy45ODk4NzZdIGluaXRj
YWxsIGk4MjM3QV9pbml0X29wcysweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDE4IHVzZWNzClsg
ICAgMy45ODk5ODJdIGNhbGxpbmcgIGNhY2hlX3N5c2ZzX2luaXQrMHgwLzB4NTkgQCAxClsgICAg
My45OTAxNTZdIGluaXRjYWxsIGNhY2hlX3N5c2ZzX2luaXQrMHgwLzB4NTkgcmV0dXJuZWQgMCBh
ZnRlciA3MyB1c2VjcwpbICAgIDMuOTkwMjU4XSBjYWxsaW5nICBtY2hlY2tfaW5pdF9kZXZpY2Ur
MHgwLzB4MjQgQCAxClsgICAgMy45OTAzNThdIGluaXRjYWxsIG1jaGVja19pbml0X2RldmljZSsw
eDAvMHgyNCByZXR1cm5lZCAtNSBhZnRlciAwIHVzZWNzClsgICAgMy45OTA0NTddIGluaXRjYWxs
IG1jaGVja19pbml0X2RldmljZSsweDAvMHgyNCByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTUg
ClsgICAgMy45OTA1NjBdIGNhbGxpbmcgIHRocmVzaG9sZF9pbml0X2RldmljZSsweDAvMHg1NiBA
IDEKWyAgICAzLjk5MDY2MV0gaW5pdGNhbGwgdGhyZXNob2xkX2luaXRfZGV2aWNlKzB4MC8weDU2
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTkwNzY2XSBjYWxsaW5nICB0aGVybWFs
X3Rocm90dGxlX2luaXRfZGV2aWNlKzB4MC8weDljIEAgMQpbICAgIDMuOTkwODYzXSBpbml0Y2Fs
bCB0aGVybWFsX3Rocm90dGxlX2luaXRfZGV2aWNlKzB4MC8weDljIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDMuOTkwOTg5XSBjYWxsaW5nICBhbWRfaWJzX2luaXQrMHgwLzB4MTdmIEAg
MQpbICAgIDMuOTkxMDkwXSBpbml0Y2FsbCBhbWRfaWJzX2luaXQrMHgwLzB4MTdmIHJldHVybmVk
IC0xOSBhZnRlciAwIHVzZWNzClsgICAgMy45OTExOTJdIGNhbGxpbmcgIGlvYXBpY19pbml0X29w
cysweDAvMHgxNCBAIDEKWyAgICAzLjk5MTI5MF0gaW5pdGNhbGwgaW9hcGljX2luaXRfb3BzKzB4
MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTkxMzk0XSBjYWxsaW5nICBh
ZGRfcGNzcGtyKzB4MC8weDVlIEAgMQpbICAgIDMuOTkxNTE1XSBpbml0Y2FsbCBhZGRfcGNzcGty
KzB4MC8weDVlIHJldHVybmVkIDAgYWZ0ZXIgMTkgdXNlY3MKWyAgICAzLjk5MTYxOV0gY2FsbGlu
ZyAgc3RhcnRfcGVyaW9kaWNfY2hlY2tfZm9yX2NvcnJ1cHRpb24rMHgwLzB4NTAgQCAxClsgICAg
My45OTE3MjJdIGluaXRjYWxsIHN0YXJ0X3BlcmlvZGljX2NoZWNrX2Zvcl9jb3JydXB0aW9uKzB4
MC8weDUwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMuOTkxODQ2XSBjYWxsaW5nICBh
dWRpdF9jbGFzc2VzX2luaXQrMHgwLzB4YWYgQCAxClsgICAgMy45OTE5NTBdIGluaXRjYWxsIGF1
ZGl0X2NsYXNzZXNfaW5pdCsweDAvMHhhZiByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICAz
Ljk5MjA1NV0gY2FsbGluZyAgY3JjMzJjX2ludGVsX21vZF9pbml0KzB4MC8weDI2IEAgMQpbICAg
IDMuOTkyMjAwXSBpbml0Y2FsbCBjcmMzMmNfaW50ZWxfbW9kX2luaXQrMHgwLzB4MjYgcmV0dXJu
ZWQgMCBhZnRlciA0MSB1c2VjcwpbICAgIDMuOTkyMzA3XSBjYWxsaW5nICBpYTMyX2JpbmZtdF9p
bml0KzB4MC8weDE0IEAgMQpbICAgIDMuOTkyNDExXSBpbml0Y2FsbCBpYTMyX2JpbmZtdF9pbml0
KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDMuOTkyNTE1XSBjYWxsaW5n
ICBpbml0X3NjaGVkX2RlYnVnX3Byb2NmcysweDAvMHgyYyBAIDEKWyAgICAzLjk5MjYyMV0gaW5p
dGNhbGwgaW5pdF9zY2hlZF9kZWJ1Z19wcm9jZnMrMHgwLzB4MmMgcmV0dXJuZWQgMCBhZnRlciAy
IHVzZWNzClsgICAgMy45OTI3NDZdIGNhbGxpbmcgIHByb2Nfc2NoZWRzdGF0X2luaXQrMHgwLzB4
MjIgQCAxClsgICAgMy45OTI4NDldIGluaXRjYWxsIHByb2Nfc2NoZWRzdGF0X2luaXQrMHgwLzB4
MjIgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgMy45OTI5NTVdIGNhbGxpbmcgIHByb2Nf
ZXhlY2RvbWFpbnNfaW5pdCsweDAvMHgyMiBAIDEKWyAgICAzLjk5MzA1N10gaW5pdGNhbGwgcHJv
Y19leGVjZG9tYWluc19pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuOTkzMTY2XSBjYWxsaW5nICBpb3Jlc291cmNlc19pbml0KzB4MC8weDNjIEAgMQpbICAgIDMu
OTkzMjY4XSBpbml0Y2FsbCBpb3Jlc291cmNlc19pbml0KzB4MC8weDNjIHJldHVybmVkIDAgYWZ0
ZXIgMSB1c2VjcwpbICAgIDMuOTkzMzc0XSBjYWxsaW5nICB1aWRfY2FjaGVfaW5pdCsweDAvMHg5
NSBAIDEKWyAgICAzLjk5MzQ4Ml0gaW5pdGNhbGwgdWlkX2NhY2hlX2luaXQrMHgwLzB4OTUgcmV0
dXJuZWQgMCBhZnRlciA2IHVzZWNzClsgICAgMy45OTM1ODZdIGNhbGxpbmcgIGluaXRfcG9zaXhf
dGltZXJzKzB4MC8weDIwMyBAIDEKWyAgICAzLjk5MzY4OV0gaW5pdGNhbGwgaW5pdF9wb3NpeF90
aW1lcnMrMHgwLzB4MjAzIHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAgIDMuOTkzNzk1XSBj
YWxsaW5nICBpbml0X3Bvc2l4X2NwdV90aW1lcnMrMHgwLzB4YzIgQCAxClsgICAgMy45OTM4OTld
IGluaXRjYWxsIGluaXRfcG9zaXhfY3B1X3RpbWVycysweDAvMHhjMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjk5NDAwNl0gY2FsbGluZyAgY3JlYXRlX3Byb2NfcHJvZmlsZSsweDAv
MHg5MCBAIDEKWyAgICAzLjk5NDEwOF0gaW5pdGNhbGwgY3JlYXRlX3Byb2NfcHJvZmlsZSsweDAv
MHg5MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICAzLjk5NDIxMV0gY2FsbGluZyAgdGlt
ZWtlZXBpbmdfaW5pdF9vcHMrMHgwLzB4MTQgQCAxClsgICAgMy45OTQzMTJdIGluaXRjYWxsIHRp
bWVrZWVwaW5nX2luaXRfb3BzKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDMuOTk0NDE1XSBjYWxsaW5nICBpbml0X2Nsb2Nrc291cmNlX3N5c2ZzKzB4MC8weDUwIEAgMQpb
ICAgIDMuOTk0NTI3XSBpbml0Y2FsbCBpbml0X2Nsb2Nrc291cmNlX3N5c2ZzKzB4MC8weDUwIHJl
dHVybmVkIDAgYWZ0ZXIgOSB1c2VjcwpbICAgIDMuOTk0NjMzXSBjYWxsaW5nICBpbml0X3RpbWVy
X2xpc3RfcHJvY2ZzKzB4MC8weDJjIEAgMQpbICAgIDMuOTk2NDMyXSBpbml0Y2FsbCBpbml0X3Rp
bWVyX2xpc3RfcHJvY2ZzKzB4MC8weDJjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDMu
OTk2NTM3XSBjYWxsaW5nICBhbGFybXRpbWVyX2luaXQrMHgwLzB4MTcwIEAgMQpbICAgIDMuOTk2
NjY0XSBpbml0Y2FsbCBhbGFybXRpbWVyX2luaXQrMHgwLzB4MTcwIHJldHVybmVkIDAgYWZ0ZXIg
MjMgdXNlY3MKWyAgICAzLjk5Njc2OF0gY2FsbGluZyAgaW5pdF90c3RhdHNfcHJvY2ZzKzB4MC8w
eDJjIEAgMQpbICAgIDMuOTk2ODcwXSBpbml0Y2FsbCBpbml0X3RzdGF0c19wcm9jZnMrMHgwLzB4
MmMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45OTY5NzZdIGNhbGxpbmcgIGZ1dGV4
X2luaXQrMHgwLzB4NWYgQCAxClsgICAgMy45OTcwODFdIGluaXRjYWxsIGZ1dGV4X2luaXQrMHgw
LzB4NWYgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzClsgICAgMy45OTcxODVdIGNhbGxpbmcgIHBy
b2NfZG1hX2luaXQrMHgwLzB4MjIgQCAxClsgICAgMy45OTcyODVdIGluaXRjYWxsIHByb2NfZG1h
X2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgMy45OTczOTBdIGNh
bGxpbmcgIHByb2NfbW9kdWxlc19pbml0KzB4MC8weDIyIEAgMQpbICAgIDMuOTk3NDkyXSBpbml0
Y2FsbCBwcm9jX21vZHVsZXNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICAzLjk5NzU5OF0gY2FsbGluZyAga2FsbHN5bXNfaW5pdCsweDAvMHgyNSBAIDEKWyAgICAz
Ljk5NzcwMF0gaW5pdGNhbGwga2FsbHN5bXNfaW5pdCsweDAvMHgyNSByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICAzLjk5NzgwNV0gY2FsbGluZyAgc25hcHNob3RfZGV2aWNlX2luaXQrMHgw
LzB4MTIgQCAxClsgICAgMy45OTc5NDhdIGluaXRjYWxsIHNuYXBzaG90X2RldmljZV9pbml0KzB4
MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgNDEgdXNlY3MKWyAgICAzLjk5ODA1Ml0gY2FsbGluZyAg
Y3Jhc2hfc2F2ZV92bWNvcmVpbmZvX2luaXQrMHgwLzB4NDdjIEAgMQpbICAgIDMuOTk4MTcxXSBp
bml0Y2FsbCBjcmFzaF9zYXZlX3ZtY29yZWluZm9faW5pdCsweDAvMHg0N2MgcmV0dXJuZWQgMCBh
ZnRlciAxMyB1c2VjcwpbICAgIDMuOTk4Mjk0XSBjYWxsaW5nICBjcmFzaF9ub3Rlc19tZW1vcnlf
aW5pdCsweDAvMHgzNyBAIDEKWyAgICAzLjk5ODM5OF0gaW5pdGNhbGwgY3Jhc2hfbm90ZXNfbWVt
b3J5X2luaXQrMHgwLzB4MzcgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgMy45OTg1MjJd
IGNhbGxpbmcgIHVzZXJfbmFtZXNwYWNlc19pbml0KzB4MC8weDJkIEAgMQpbICAgIDMuOTk4NjI3
XSBpbml0Y2FsbCB1c2VyX25hbWVzcGFjZXNfaW5pdCsweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVy
IDMgdXNlY3MKWyAgICAzLjk5ODczM10gY2FsbGluZyAgcGlkX25hbWVzcGFjZXNfaW5pdCsweDAv
MHgyZCBAIDEKWyAgICAzLjk5ODgzN10gaW5pdGNhbGwgcGlkX25hbWVzcGFjZXNfaW5pdCsweDAv
MHgyZCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAgICAzLjk5ODk0Ml0gY2FsbGluZyAgYXVk
aXRfaW5pdCsweDAvMHgxNiBAIDEKWyAgICAzLjk5OTA0Ml0gYXVkaXQ6IGluaXRpYWxpemluZyBu
ZXRsaW5rIHNvY2tldCAoZGlzYWJsZWQpClsgICAgMy45OTkxNTBdIHR5cGU9MjAwMCBhdWRpdCgx
MzM0MTY4OTYzLjczMToxKTogaW5pdGlhbGl6ZWQKWyAgICAzLjk5OTI1M10gaW5pdGNhbGwgYXVk
aXRfaW5pdCsweDAvMHgxNiByZXR1cm5lZCAwIGFmdGVyIDIwNSB1c2VjcwpbICAgIDMuOTk5MzU2
XSBjYWxsaW5nICBhdWRpdF93YXRjaF9pbml0KzB4MC8weDNhIEAgMQpbICAgIDMuOTk5NDU3XSBp
bml0Y2FsbCBhdWRpdF93YXRjaF9pbml0KzB4MC8weDNhIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDMuOTk5NTYzXSBjYWxsaW5nICBhdWRpdF90cmVlX2luaXQrMHgwLzB4NTggQCAxClsg
ICAgMy45OTk2NjJdIGluaXRjYWxsIGF1ZGl0X3RyZWVfaW5pdCsweDAvMHg1OCByZXR1cm5lZCAw
IGFmdGVyIDAgdXNlY3MKWyAgICAzLjk5OTc2N10gY2FsbGluZyAgaW5pdF9rcHJvYmVzKzB4MC8w
eDE4MyBAIDEKWyAgICA0LjAxNTgwM10gaW5pdGNhbGwgaW5pdF9rcHJvYmVzKzB4MC8weDE4MyBy
ZXR1cm5lZCAwIGFmdGVyIDE1NTYxIHVzZWNzClsgICAgNC4wMTU5MDddIGNhbGxpbmcgIGh1bmdf
dGFza19pbml0KzB4MC8weDUzIEAgMQpbICAgIDQuMDE2MDM1XSBpbml0Y2FsbCBodW5nX3Rhc2tf
aW5pdCsweDAvMHg1MyByZXR1cm5lZCAwIGFmdGVyIDI1IHVzZWNzClsgICAgNC4wMTYxNDBdIGNh
bGxpbmcgIGlycV9nY19pbml0X29wcysweDAvMHgxNCBAIDEKWyAgICA0LjAxNjI0Ml0gaW5pdGNh
bGwgaXJxX2djX2luaXRfb3BzKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAg
IDQuMDE2MzQ3XSBjYWxsaW5nICBpcnFfcG1faW5pdF9vcHMrMHgwLzB4MTQgQCAxClsgICAgNC4w
MTY0NDldIGluaXRjYWxsIGlycV9wbV9pbml0X29wcysweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICA0LjAxNjU1NF0gY2FsbGluZyAgdXRzbmFtZV9zeXNjdGxfaW5pdCsweDAv
MHgxNCBAIDEKWyAgICA0LjAxNjY2M10gaW5pdGNhbGwgdXRzbmFtZV9zeXNjdGxfaW5pdCsweDAv
MHgxNCByZXR1cm5lZCAwIGFmdGVyIDkgdXNlY3MKWyAgICA0LjAxNjc2Nl0gY2FsbGluZyAgaW5p
dF90cmFjZXBvaW50cysweDAvMHgyMCBAIDEKWyAgICA0LjAxNjg2Nl0gaW5pdGNhbGwgaW5pdF90
cmFjZXBvaW50cysweDAvMHgyMCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjAxNjk2
OV0gY2FsbGluZyAgaW5pdF9sc3RhdHNfcHJvY2ZzKzB4MC8weDI1IEAgMQpbICAgIDQuMDE3MDcz
XSBpbml0Y2FsbCBpbml0X2xzdGF0c19wcm9jZnMrMHgwLzB4MjUgcmV0dXJuZWQgMCBhZnRlciAx
IHVzZWNzClsgICAgNC4wMTcxNzhdIGNhbGxpbmcgIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4
MTIgQCAxClsgICAgNC4wMTcyODBdIGluaXRjYWxsIGZ0cmFjZV9tb2RfY21kX2luaXQrMHgwLzB4
MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMTczODZdIGNhbGxpbmcgIGluaXRf
ZXZlbnRzKzB4MC8weDYwIEAgMQpbICAgIDQuMDE3NDkyXSBpbml0Y2FsbCBpbml0X2V2ZW50cysw
eDAvMHg2MCByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICA0LjAxNzU5N10gY2FsbGluZyAg
aW5pdF9mdW5jdGlvbl90cmFjZSsweDAvMHgzZSBAIDEKWyAgICA0LjAxNzcwMF0gaW5pdGNhbGwg
aW5pdF9mdW5jdGlvbl90cmFjZSsweDAvMHgzZSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAg
ICA0LjAxNzgwNV0gY2FsbGluZyAgaW5pdF93YWtldXBfdHJhY2VyKzB4MC8weDIyIEAgMQpbICAg
IDQuMDE3OTA4XSBpbml0Y2FsbCBpbml0X3dha2V1cF90cmFjZXIrMHgwLzB4MjIgcmV0dXJuZWQg
MCBhZnRlciAwIHVzZWNzClsgICAgNC4wMTgwMTJdIGNhbGxpbmcgIHN0YWNrX3RyYWNlX2luaXQr
MHgwLzB4NjggQCAxClsgICAgNC4wMTgxMTldIGluaXRjYWxsIHN0YWNrX3RyYWNlX2luaXQrMHgw
LzB4NjggcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzClsgICAgNC4wMTgyMjVdIGNhbGxpbmcgIGlu
aXRfbW1pb190cmFjZSsweDAvMHgxMiBAIDEKWyAgICA0LjAxODMyOF0gaW5pdGNhbGwgaW5pdF9t
bWlvX3RyYWNlKzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDE4NDM0
XSBjYWxsaW5nICBpbml0X2dyYXBoX3RyYWNlKzB4MC8weDY1IEAgMQpbICAgIDQuMDE4NTM3XSBp
bml0Y2FsbCBpbml0X2dyYXBoX3RyYWNlKzB4MC8weDY1IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDQuMDE4NjQwXSBjYWxsaW5nICBpbml0X2Jsa190cmFjZXIrMHgwLzB4NWMgQCAxClsg
ICAgNC4wMTg3NDJdIGluaXRjYWxsIGluaXRfYmxrX3RyYWNlcisweDAvMHg1YyByZXR1cm5lZCAw
IGFmdGVyIDAgdXNlY3MKWyAgICA0LjAxODg0OF0gY2FsbGluZyAgcGVyZl9ldmVudF9zeXNmc19p
bml0KzB4MC8weDkzIEAgMQpbICAgIDQuMDE4OTkyXSBpbml0Y2FsbCBwZXJmX2V2ZW50X3N5c2Zz
X2luaXQrMHgwLzB4OTMgcmV0dXJuZWQgMCBhZnRlciAzOSB1c2VjcwpbICAgIDQuMDE5MDk5XSBj
YWxsaW5nICBpbml0X3Blcl96b25lX3dtYXJrX21pbisweDAvMHg4OCBAIDEKWyAgICA0LjAyMDQw
Nl0gaW5pdGNhbGwgaW5pdF9wZXJfem9uZV93bWFya19taW4rMHgwLzB4ODggcmV0dXJuZWQgMCBh
ZnRlciAxMTY5IHVzZWNzClsgICAgNC4wMjA1MzddIGNhbGxpbmcgIGtzd2FwZF9pbml0KzB4MC8w
eDc1IEAgMQpbICAgIDQuMDIwNzAzXSBpbml0Y2FsbCBrc3dhcGRfaW5pdCsweDAvMHg3NSByZXR1
cm5lZCAwIGFmdGVyIDYzIHVzZWNzClsgICAgNC4wMjA4MDldIGNhbGxpbmcgIGV4dGZyYWdfZGVi
dWdfaW5pdCsweDAvMHg3NyBAIDEKWyAgICA0LjAyMDkyMV0gaW5pdGNhbGwgZXh0ZnJhZ19kZWJ1
Z19pbml0KzB4MC8weDc3IHJldHVybmVkIDAgYWZ0ZXIgOCB1c2VjcwpbICAgIDQuMDIxMDI2XSBj
YWxsaW5nICBzZXR1cF92bXN0YXQrMHgwLzB4YzcgQCAxClsgICAgNC4wMjExMzddIGluaXRjYWxs
IHNldHVwX3Ztc3RhdCsweDAvMHhjNyByZXR1cm5lZCAwIGFmdGVyIDggdXNlY3MKWyAgICA0LjAy
MTI0Ml0gY2FsbGluZyAgbW1fc3lzZnNfaW5pdCsweDAvMHgyOSBAIDEKWyAgICA0LjAyMTM0N10g
aW5pdGNhbGwgbW1fc3lzZnNfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MK
WyAgICA0LjAyMTQ1MV0gY2FsbGluZyAgcHJvY192bWFsbG9jX2luaXQrMHgwLzB4MjUgQCAxClsg
ICAgNC4wMjE1NTBdIGluaXRjYWxsIHByb2Nfdm1hbGxvY19pbml0KzB4MC8weDI1IHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDIxNjU1XSBjYWxsaW5nICBwcm9jc3dhcHNfaW5pdCsw
eDAvMHgyMiBAIDEKWyAgICA0LjAyMTc1N10gaW5pdGNhbGwgcHJvY3N3YXBzX2luaXQrMHgwLzB4
MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjE4NjFdIGNhbGxpbmcgIGh1Z2V0
bGJfaW5pdCsweDAvMHgzMmQgQCAxClsgICAgNC4wMjE5NjNdIEh1Z2VUTEIgcmVnaXN0ZXJlZCAy
IE1CIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9jYXRlZCAwIHBhZ2VzClsgICAgNC4wMjIwNzVdIGluaXRj
YWxsIGh1Z2V0bGJfaW5pdCsweDAvMHgzMmQgcmV0dXJuZWQgMCBhZnRlciAxMTAgdXNlY3MKWyAg
ICA0LjAyMjE4MF0gY2FsbGluZyAga3NtX2luaXQrMHgwLzB4ZDAgQCAxClsgICAgNC4wMjIzMjFd
IGluaXRjYWxsIGtzbV9pbml0KzB4MC8weGQwIHJldHVybmVkIDAgYWZ0ZXIgNDAgdXNlY3MKWyAg
ICA0LjAyMjQyNl0gY2FsbGluZyAgc2xhYl9wcm9jX2luaXQrMHgwLzB4MjUgQCAxClsgICAgNC4w
MjI1MjldIGluaXRjYWxsIHNsYWJfcHJvY19pbml0KzB4MC8weDI1IHJldHVybmVkIDAgYWZ0ZXIg
MiB1c2VjcwpbICAgIDQuMDIyNjMzXSBjYWxsaW5nICBzbGFiX3N5c2ZzX2luaXQrMHgwLzB4MTA5
IEAgMQpbICAgIDQuMDIzNjY3XSBpbml0Y2FsbCBzbGFiX3N5c2ZzX2luaXQrMHgwLzB4MTA5IHJl
dHVybmVkIDAgYWZ0ZXIgOTEwIHVzZWNzClsgICAgNC4wMjM3NzNdIGNhbGxpbmcgIGh1Z2VwYWdl
X2luaXQrMHgwLzB4MTQxIEAgMQpbICAgIDQuMDIzODc0XSBpbml0Y2FsbCBodWdlcGFnZV9pbml0
KzB4MC8weDE0MSByZXR1cm5lZCAtMjIgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDIzOTc5XSBpbml0
Y2FsbCBodWdlcGFnZV9pbml0KzB4MC8weDE0MSByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTIy
IApbICAgIDQuMDI0MDg1XSBjYWxsaW5nICBpbml0X2NsZWFuY2FjaGUrMHgwLzB4MWIgQCAxClsg
ICAgNC4wMjQxODddIGluaXRjYWxsIGluaXRfY2xlYW5jYWNoZSsweDAvMHgxYiByZXR1cm5lZCAw
IGFmdGVyIDEgdXNlY3MKWyAgICA0LjAyNDI5Ml0gY2FsbGluZyAgZmNudGxfaW5pdCsweDAvMHgy
YSBAIDEKWyAgICA0LjAyNDM5NV0gaW5pdGNhbGwgZmNudGxfaW5pdCsweDAvMHgyYSByZXR1cm5l
ZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjAyNDQ5OF0gY2FsbGluZyAgcHJvY19maWxlc3lzdGVt
c19pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMDI0NjAzXSBpbml0Y2FsbCBwcm9jX2ZpbGVzeXN0
ZW1zX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4wMjQ3MTBd
IGNhbGxpbmcgIGRpb19pbml0KzB4MC8weDJkIEAgMQpbICAgIDQuMDI0ODI5XSBpbml0Y2FsbCBk
aW9faW5pdCsweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVyIDE3IHVzZWNzClsgICAgNC4wMjQ5MzFd
IGNhbGxpbmcgIGZzbm90aWZ5X21hcmtfaW5pdCsweDAvMHg0MCBAIDEKWyAgICA0LjAyNTA1OV0g
aW5pdGNhbGwgZnNub3RpZnlfbWFya19pbml0KzB4MC8weDQwIHJldHVybmVkIDAgYWZ0ZXIgMjUg
dXNlY3MKWyAgICA0LjAyNTE2OF0gY2FsbGluZyAgZG5vdGlmeV9pbml0KzB4MC8weDdiIEAgMQpb
ICAgIDQuMDI1MzAxXSBpbml0Y2FsbCBkbm90aWZ5X2luaXQrMHgwLzB4N2IgcmV0dXJuZWQgMCBh
ZnRlciAzMCB1c2VjcwpbICAgIDQuMDI1NDA1XSBjYWxsaW5nICBpbm90aWZ5X3VzZXJfc2V0dXAr
MHgwLzB4NzAgQCAxClsgICAgNC4wMjU1MTBdIGluaXRjYWxsIGlub3RpZnlfdXNlcl9zZXR1cCsw
eDAvMHg3MCByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAgICA0LjAyNTYxNV0gY2FsbGluZyAg
ZmFub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg1MiBAIDEKWyAgICA0LjAyNTcxOV0gaW5pdGNhbGwg
ZmFub3RpZnlfdXNlcl9zZXR1cCsweDAvMHg1MiByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAg
ICA0LjAyNTgyNF0gY2FsbGluZyAgYWlvX3NldHVwKzB4MC8weDc4IEAgMQpbICAgIDQuMDI1OTMw
XSBpbml0Y2FsbCBhaW9fc2V0dXArMHgwLzB4NzggcmV0dXJuZWQgMCBhZnRlciA2IHVzZWNzClsg
ICAgNC4wMjYwMzJdIGNhbGxpbmcgIHByb2NfbG9ja3NfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0
LjAyNjEzNV0gaW5pdGNhbGwgcHJvY19sb2Nrc19pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0
ZXIgMSB1c2VjcwpbICAgIDQuMDI2MjM5XSBjYWxsaW5nICBpbml0X3N5czMyX2lvY3RsKzB4MC8w
eDI4IEAgMQpbICAgIDQuMDI2Mzk2XSBpbml0Y2FsbCBpbml0X3N5czMyX2lvY3RsKzB4MC8weDI4
IHJldHVybmVkIDAgYWZ0ZXIgNTMgdXNlY3MKWyAgICA0LjAyNjUwMV0gY2FsbGluZyAgaW5pdF9t
YmNhY2hlKzB4MC8weDE0IEAgMQpbICAgIDQuMDI2NjAyXSBpbml0Y2FsbCBpbml0X21iY2FjaGUr
MHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjY3MDZdIGNhbGxpbmcg
IGRxdW90X2luaXQrMHgwLzB4MTFhIEAgMQpbICAgIDQuMDI2ODA2XSBWRlM6IERpc2sgcXVvdGFz
IGRxdW90XzYuNS4yClsgICAgNC4wMjY5NDZdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmll
czogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQpbICAgIDQuMDI3MDUxXSBpbml0Y2FsbCBkcXVv
dF9pbml0KzB4MC8weDExYSByZXR1cm5lZCAwIGFmdGVyIDIzOCB1c2VjcwpbICAgIDQuMDI3MTU1
XSBjYWxsaW5nICBxdW90YV9pbml0KzB4MC8weDI2IEAgMQpbICAgIDQuMDI3MjU5XSBpbml0Y2Fs
bCBxdW90YV9pbml0KzB4MC8weDI2IHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDQuMDI3
MzYwXSBjYWxsaW5nICBwcm9jX2NtZGxpbmVfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyNzQ2
Ml0gaW5pdGNhbGwgcHJvY19jbWRsaW5lX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAx
IHVzZWNzClsgICAgNC4wMjc1NjZdIGNhbGxpbmcgIHByb2NfY29uc29sZXNfaW5pdCsweDAvMHgy
MiBAIDEKWyAgICA0LjAyNzY2NV0gaW5pdGNhbGwgcHJvY19jb25zb2xlc19pbml0KzB4MC8weDIy
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI3NzcxXSBjYWxsaW5nICBwcm9jX2Nw
dWluZm9faW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyNzg3NF0gaW5pdGNhbGwgcHJvY19jcHVp
bmZvX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjc5Nzld
IGNhbGxpbmcgIHByb2NfZGV2aWNlc19pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMDI4MDgxXSBp
bml0Y2FsbCBwcm9jX2RldmljZXNfaW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA0LjAyODE4NV0gY2FsbGluZyAgcHJvY19pbnRlcnJ1cHRzX2luaXQrMHgwLzB4MjIg
QCAxClsgICAgNC4wMjgyODhdIGluaXRjYWxsIHByb2NfaW50ZXJydXB0c19pbml0KzB4MC8weDIy
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI4MzkyXSBjYWxsaW5nICBwcm9jX2xv
YWRhdmdfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyODQ5M10gaW5pdGNhbGwgcHJvY19sb2Fk
YXZnX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMjg1OThd
IGNhbGxpbmcgIHByb2NfbWVtaW5mb19pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMDI4NzAyXSBp
bml0Y2FsbCBwcm9jX21lbWluZm9faW5pdCsweDAvMHgyMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA0LjAyODgwN10gY2FsbGluZyAgcHJvY19zdGF0X2luaXQrMHgwLzB4MjIgQCAxClsg
ICAgNC4wMjg5MDhdIGluaXRjYWxsIHByb2Nfc3RhdF9pbml0KzB4MC8weDIyIHJldHVybmVkIDAg
YWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI5MDEyXSBjYWxsaW5nICBwcm9jX3VwdGltZV9pbml0KzB4
MC8weDIyIEAgMQpbICAgIDQuMDI5MTE1XSBpbml0Y2FsbCBwcm9jX3VwdGltZV9pbml0KzB4MC8w
eDIyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDI5MjIxXSBjYWxsaW5nICBwcm9j
X3ZlcnNpb25faW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyOTMyOV0gaW5pdGNhbGwgcHJvY192
ZXJzaW9uX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgNC4wMjk0
MzJdIGNhbGxpbmcgIHByb2Nfc29mdGlycXNfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjAyOTUz
Nl0gaW5pdGNhbGwgcHJvY19zb2Z0aXJxc19pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0ZXIg
MCB1c2VjcwpbICAgIDQuMDI5NjM5XSBjYWxsaW5nICBwcm9jX2tjb3JlX2luaXQrMHgwLzB4YjUg
QCAxClsgICAgNC4wMjk3NDJdIGluaXRjYWxsIHByb2Nfa2NvcmVfaW5pdCsweDAvMHhiNSByZXR1
cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA0LjAyOTg0NV0gY2FsbGluZyAgdm1jb3JlX2luaXQr
MHgwLzB4NzAgQCAxClsgICAgNC4wMjk5NDRdIGluaXRjYWxsIHZtY29yZV9pbml0KzB4MC8weDcw
IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDMwMDQ4XSBjYWxsaW5nICBwcm9jX2tt
c2dfaW5pdCsweDAvMHgyNSBAIDEKWyAgICA0LjAzMDE0N10gaW5pdGNhbGwgcHJvY19rbXNnX2lu
aXQrMHgwLzB4MjUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzAyNTBdIGNhbGxp
bmcgIHByb2NfcGFnZV9pbml0KzB4MC8weDQyIEAgMQpbICAgIDQuMDMwMzUzXSBpbml0Y2FsbCBw
cm9jX3BhZ2VfaW5pdCsweDAvMHg0MiByZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjAz
MDQ1OV0gY2FsbGluZyAgcHJvY192ZXJzaW9uX3NpZ25hdHVyZV9pbml0KzB4MC8weDIyIEAgMQpb
ICAgIDQuMDMwNTYzXSBpbml0Y2FsbCBwcm9jX3ZlcnNpb25fc2lnbmF0dXJlX2luaXQrMHgwLzB4
MjIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzA2ODhdIGNhbGxpbmcgIGluaXRf
ZGV2cHRzX2ZzKzB4MC8weDRhIEAgMQpbICAgIDQuMDMwODAxXSBpbml0Y2FsbCBpbml0X2RldnB0
c19mcysweDAvMHg0YSByZXR1cm5lZCAwIGFmdGVyIDEwIHVzZWNzClsgICAgNC4wMzA5MDVdIGNh
bGxpbmcgIGluaXRfZXh0M19mcysweDAvMHg3NiBAIDEKWyAgICA0LjAzMTA0MF0gaW5pdGNhbGwg
aW5pdF9leHQzX2ZzKzB4MC8weDc2IHJldHVybmVkIDAgYWZ0ZXIgMzMgdXNlY3MKWyAgICA0LjAz
MTE0NV0gY2FsbGluZyAgZXh0NF9pbml0X2ZzKzB4MC8weDVjIEAgMQpbICAgIDQuMDMxMzM0XSBp
bml0Y2FsbCBleHQ0X2luaXRfZnMrMHgwLzB4NWMgcmV0dXJuZWQgMCBhZnRlciA4NCB1c2Vjcwpb
ICAgIDQuMDMxNDM5XSBjYWxsaW5nICBqb3VybmFsX2luaXQrMHgwLzB4MWUgQCAxClsgICAgNC4w
MzE1ODldIGluaXRjYWxsIGpvdXJuYWxfaW5pdCsweDAvMHgxZSByZXR1cm5lZCAwIGFmdGVyIDQ3
IHVzZWNzClsgICAgNC4wMzE2OTNdIGNhbGxpbmcgIGpvdXJuYWxfaW5pdCsweDAvMHgzNCBAIDEK
WyAgICA0LjAzMTgwMF0gaW5pdGNhbGwgam91cm5hbF9pbml0KzB4MC8weDM0IHJldHVybmVkIDAg
YWZ0ZXIgNSB1c2VjcwpbICAgIDQuMDMxOTA0XSBjYWxsaW5nICBpbml0X3JhbWZzX2ZzKzB4MC8w
eDEyIEAgMQpbICAgIDQuMDMyMDAzXSBpbml0Y2FsbCBpbml0X3JhbWZzX2ZzKzB4MC8weDEyIHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDMyMTA5XSBjYWxsaW5nICBpbml0X2h1Z2V0
bGJmc19mcysweDAvMHg5NSBAIDEKWyAgICA0LjAzMjI0Ml0gaW5pdGNhbGwgaW5pdF9odWdldGxi
ZnNfZnMrMHgwLzB4OTUgcmV0dXJuZWQgMCBhZnRlciAzMCB1c2VjcwpbICAgIDQuMDMyMzQ2XSBj
YWxsaW5nICBlY3J5cHRmc19pbml0KzB4MC8weDFlNiBAIDEKWyAgICA0LjAzMjU2OV0gaW5pdGNh
bGwgZWNyeXB0ZnNfaW5pdCsweDAvMHgxZTYgcmV0dXJuZWQgMCBhZnRlciAxMTggdXNlY3MKWyAg
ICA0LjAzMjY3NV0gY2FsbGluZyAgZnVzZV9pbml0KzB4MC8weDFiMCBAIDEKWyAgICA0LjAzMjc3
NV0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjE3KQpbICAgIDQuMDMyOTQwXSBpbml0Y2FsbCBm
dXNlX2luaXQrMHgwLzB4MWIwIHJldHVybmVkIDAgYWZ0ZXIgMTU5IHVzZWNzClsgICAgNC4wMzMw
NDVdIGNhbGxpbmcgIGluaXRfcHN0b3JlX2ZzKzB4MC8weDEyIEAgMQpbICAgIDQuMDMzMTQ3XSBp
bml0Y2FsbCBpbml0X3BzdG9yZV9mcysweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjAzMzI1MV0gY2FsbGluZyAgaXBjX2luaXQrMHgwLzB4MmYgQCAxClsgICAgNC4wMzMz
NTNdIG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gMTQ4MApbICAgIDQuMDMzNDUzXSBpbml0Y2FsbCBp
cGNfaW5pdCsweDAvMHgyZiByZXR1cm5lZCAwIGFmdGVyIDk5IHVzZWNzClsgICAgNC4wMzM1NTVd
IGNhbGxpbmcgIGlwY19zeXNjdGxfaW5pdCsweDAvMHgxNCBAIDEKWyAgICA0LjAzNTM2OV0gaW5p
dGNhbGwgaXBjX3N5c2N0bF9pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMTUgdXNlY3MK
WyAgICA0LjAzNTQ3NF0gY2FsbGluZyAgaW5pdF9tcXVldWVfZnMrMHgwLzB4OWYgQCAxClsgICAg
NC4wMzU2MTddIGluaXRjYWxsIGluaXRfbXF1ZXVlX2ZzKzB4MC8weDlmIHJldHVybmVkIDAgYWZ0
ZXIgMzkgdXNlY3MKWyAgICA0LjAzNTcyM10gY2FsbGluZyAga2V5X3Byb2NfaW5pdCsweDAvMHgz
MyBAIDEKWyAgICA0LjAzNTgyN10gaW5pdGNhbGwga2V5X3Byb2NfaW5pdCsweDAvMHgzMyByZXR1
cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjAzNTkzMl0gY2FsbGluZyAgc2VsaW51eF9uZl9p
cF9pbml0KzB4MC8weDY5IEAgMQpbICAgIDQuMDM2MDM1XSBpbml0Y2FsbCBzZWxpbnV4X25mX2lw
X2luaXQrMHgwLzB4NjkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzYxMzldIGNh
bGxpbmcgIGluaXRfc2VsX2ZzKzB4MC8weDliIEAgMQpbICAgIDQuMDM2MjQwXSBpbml0Y2FsbCBp
bml0X3NlbF9mcysweDAvMHg5YiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjAzNjM0
Ml0gY2FsbGluZyAgc2VsbmxfaW5pdCsweDAvMHg0ZCBAIDEKWyAgICA0LjAzNjQ0OF0gaW5pdGNh
bGwgc2VsbmxfaW5pdCsweDAvMHg0ZCByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICA0LjAz
NjU1MV0gY2FsbGluZyAgc2VsX25ldGlmX2luaXQrMHgwLzB4NzMgQCAxClsgICAgNC4wMzY2NTNd
IGluaXRjYWxsIHNlbF9uZXRpZl9pbml0KzB4MC8weDczIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDQuMDM2NzU4XSBjYWxsaW5nICBzZWxfbmV0bm9kZV9pbml0KzB4MC8weDc0IEAgMQpb
ICAgIDQuMDM2ODU5XSBpbml0Y2FsbCBzZWxfbmV0bm9kZV9pbml0KzB4MC8weDc0IHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM2OTY1XSBjYWxsaW5nICBzZWxfbmV0cG9ydF9pbml0
KzB4MC8weDc0IEAgMQpbICAgIDQuMDM3MDY3XSBpbml0Y2FsbCBzZWxfbmV0cG9ydF9pbml0KzB4
MC8weDc0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM3MTczXSBjYWxsaW5nICBh
dXJ1bGVfaW5pdCsweDAvMHgzNyBAIDEKWyAgICA0LjAzNzI3Ml0gaW5pdGNhbGwgYXVydWxlX2lu
aXQrMHgwLzB4MzcgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzczNzZdIGNhbGxp
bmcgIGluaXRfc21rX2ZzKzB4MC8weDIxIEAgMQpbICAgIDQuMDM3NDc2XSBpbml0Y2FsbCBpbml0
X3Nta19mcysweDAvMHgyMSByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjAzNzU3OV0g
Y2FsbGluZyAgY3J5cHRvX3dxX2luaXQrMHgwLzB4MzEgQCAxClsgICAgNC4wMzc3MDddIGluaXRj
YWxsIGNyeXB0b193cV9pbml0KzB4MC8weDMxIHJldHVybmVkIDAgYWZ0ZXIgMjQgdXNlY3MKWyAg
ICA0LjAzNzgxMF0gY2FsbGluZyAgY3J5cHRvX2FsZ2FwaV9pbml0KzB4MC8weGQgQCAxClsgICAg
NC4wMzc5MTVdIGluaXRjYWxsIGNyeXB0b19hbGdhcGlfaW5pdCsweDAvMHhkIHJldHVybmVkIDAg
YWZ0ZXIgMSB1c2VjcwpbICAgIDQuMDM4MDIwXSBjYWxsaW5nICBza2NpcGhlcl9tb2R1bGVfaW5p
dCsweDAvMHgzNSBAIDEKWyAgICA0LjAzODEyMV0gaW5pdGNhbGwgc2tjaXBoZXJfbW9kdWxlX2lu
aXQrMHgwLzB4MzUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wMzgyMjhdIGNhbGxp
bmcgIGNoYWluaXZfbW9kdWxlX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wMzgzMjldIGluaXRj
YWxsIGNoYWluaXZfbW9kdWxlX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgNC4wMzg0MzZdIGNhbGxpbmcgIGVzZXFpdl9tb2R1bGVfaW5pdCsweDAvMHgxMiBAIDEK
WyAgICA0LjAzODUzOV0gaW5pdGNhbGwgZXNlcWl2X21vZHVsZV9pbml0KzB4MC8weDEyIHJldHVy
bmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM4NjQ0XSBjYWxsaW5nICBobWFjX21vZHVsZV9p
bml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDM4NzQ2XSBpbml0Y2FsbCBobWFjX21vZHVsZV9pbml0
KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDM4ODUxXSBjYWxsaW5n
ICBtZDVfbW9kX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wMzg5ODJdIGluaXRjYWxsIG1kNV9t
b2RfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDI5IHVzZWNzClsgICAgNC4wMzkwODZd
IGNhbGxpbmcgIHNoYTFfZ2VuZXJpY19tb2RfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjAzOTIx
OV0gaW5pdGNhbGwgc2hhMV9nZW5lcmljX21vZF9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0
ZXIgMzEgdXNlY3MKWyAgICA0LjAzOTMyNV0gY2FsbGluZyAgc2hhMjU2X2dlbmVyaWNfbW9kX2lu
aXQrMHgwLzB4M2MgQCAxClsgICAgNC4wMzk0ODRdIGluaXRjYWxsIHNoYTI1Nl9nZW5lcmljX21v
ZF9pbml0KzB4MC8weDNjIHJldHVybmVkIDAgYWZ0ZXIgNTQgdXNlY3MKWyAgICA0LjAzOTYwN10g
Y2FsbGluZyAgY3J5cHRvX2VjYl9tb2R1bGVfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjAzOTcw
N10gaW5pdGNhbGwgY3J5cHRvX2VjYl9tb2R1bGVfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICA0LjAzOTgxM10gY2FsbGluZyAgY3J5cHRvX2NiY19tb2R1bGVfaW5p
dCsweDAvMHgxMiBAIDEKWyAgICA0LjAzOTkxNF0gaW5pdGNhbGwgY3J5cHRvX2NiY19tb2R1bGVf
aW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjA0MDAyMF0gY2Fs
bGluZyAgYWVzX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wNDAxNTRdIGluaXRjYWxsIGFlc19p
bml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMzIgdXNlY3MKWyAgICA0LjA0MDI1OF0gY2Fs
bGluZyAgY3JjMzJjX21vZF9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDQwMzkzXSBpbml0Y2Fs
bCBjcmMzMmNfbW9kX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAzMSB1c2VjcwpbICAg
IDQuMDQwNDk5XSBjYWxsaW5nICBrcm5nX21vZF9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDQw
NjM0XSBpbml0Y2FsbCBrcm5nX21vZF9pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMzIg
dXNlY3MKWyAgICA0LjA0MDc0MF0gY2FsbGluZyAgcHJvY19nZW5oZF9pbml0KzB4MC8weDNjIEAg
MQpbICAgIDQuMDQwODQxXSBpbml0Y2FsbCBwcm9jX2dlbmhkX2luaXQrMHgwLzB4M2MgcmV0dXJu
ZWQgMCBhZnRlciAyIHVzZWNzClsgICAgNC4wNDA5NDNdIGNhbGxpbmcgIGJzZ19pbml0KzB4MC8w
eDEyZSBAIDEKWyAgICA0LjA0MTA2N10gQmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRy
aXZlciB2ZXJzaW9uIDAuNCBsb2FkZWQgKG1ham9yIDI1MykKWyAgICA0LjA0MTE5Ml0gaW5pdGNh
bGwgYnNnX2luaXQrMHgwLzB4MTJlIHJldHVybmVkIDAgYWZ0ZXIgMTQ1IHVzZWNzClsgICAgNC4w
NDEyOTddIGNhbGxpbmcgIGluaXRfY2dyb3VwX2Jsa2lvKzB4MC8weDEyIEAgMQpbICAgIDQuMDQx
Mzk5XSBpbml0Y2FsbCBpbml0X2Nncm91cF9ibGtpbysweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVy
IDAgdXNlY3MKWyAgICA0LjA0MTUwMV0gY2FsbGluZyAgdGhyb3RsX2luaXQrMHgwLzB4NDQgQCAx
ClsgICAgNC4wNDE2MjldIGluaXRjYWxsIHRocm90bF9pbml0KzB4MC8weDQ0IHJldHVybmVkIDAg
YWZ0ZXIgMjQgdXNlY3MKWyAgICA0LjA0MTczM10gY2FsbGluZyAgbm9vcF9pbml0KzB4MC8weDE0
IEAgMQpbICAgIDQuMDQxODM1XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsgICAgNC4w
NDE5MzVdIGluaXRjYWxsIG5vb3BfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDk3IHVz
ZWNzClsgICAgNC4wNDIwMzddIGNhbGxpbmcgIGRlYWRsaW5lX2luaXQrMHgwLzB4MTQgQCAxClsg
ICAgNC4wNDIxMzddIGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgNC4wNDIy
MzhdIGluaXRjYWxsIGRlYWRsaW5lX2luaXQrMHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciA5NyB1
c2VjcwpbICAgIDQuMDQyMzQzXSBjYWxsaW5nICBjZnFfaW5pdCsweDAvMHhiMyBAIDEKWyAgICA0
LjA0MjQ2NF0gaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZhdWx0KQpbICAgIDQuMDQy
NTYyXSBpbml0Y2FsbCBjZnFfaW5pdCsweDAvMHhiMyByZXR1cm5lZCAwIGFmdGVyIDExNiB1c2Vj
cwpbICAgIDQuMDQyNjY0XSBjYWxsaW5nICBwZXJjcHVfY291bnRlcl9zdGFydHVwKzB4MC8weDE5
IEAgMQpbICAgIDQuMDQyNzY3XSBpbml0Y2FsbCBwZXJjcHVfY291bnRlcl9zdGFydHVwKzB4MC8w
eDE5IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMDQyODcyXSBjYWxsaW5nICBsbndf
Z3Bpb19pbml0KzB4MC8weDQ1IEAgMQpbICAgIDQuMDQyOTkyXSBpbml0Y2FsbCBsbndfZ3Bpb19p
bml0KzB4MC8weDQ1IHJldHVybmVkIDAgYWZ0ZXIgMTggdXNlY3MKWyAgICA0LjA0MzA5Nl0gY2Fs
bGluZyAgdGltYmdwaW9faW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjA0MzIwMl0gaW5pdGNhbGwg
dGltYmdwaW9faW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDUgdXNlY3MKWyAgICA0LjA0
MzMwNl0gY2FsbGluZyAgdWNiMTQwMF9ncGlvX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wNDM0
MTBdIGluaXRjYWxsIHVjYjE0MDBfZ3Bpb19pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIg
MyB1c2VjcwpbICAgIDQuMDQzNTE0XSBjYWxsaW5nICBwY2lfcHJvY19pbml0KzB4MC8weDY5IEAg
MQpbICAgIDQuMDQzNjM5XSBpbml0Y2FsbCBwY2lfcHJvY19pbml0KzB4MC8weDY5IHJldHVybmVk
IDAgYWZ0ZXIgMjQgdXNlY3MKWyAgICA0LjA0Mzc0NF0gY2FsbGluZyAgcGNpZV9wb3J0ZHJ2X2lu
aXQrMHgwLzB4NzcgQCAxClsgICAgNC4wNDM4NjldIHBjaWVwb3J0IDAwMDA6MDA6MDEuMDogc2V0
dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4wNDQxNDRdIHBjaWVwb3J0IDAwMDA6MDA6
MWMuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4wNDQ3MTVdIHBjaWVwb3J0
IDAwMDA6MDA6MWMuNDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4wNDUyNjld
IGluaXRjYWxsIHBjaWVfcG9ydGRydl9pbml0KzB4MC8weDc3IHJldHVybmVkIDAgYWZ0ZXIgMTM5
MCB1c2VjcwpbICAgIDQuMDQ1MzY5XSBjYWxsaW5nICBhZXJfc2VydmljZV9pbml0KzB4MC8weDMx
IEAgMQpbICAgIDQuMDQ1NDczXSBpbml0Y2FsbCBhZXJfc2VydmljZV9pbml0KzB4MC8weDMxIHJl
dHVybmVkIDAgYWZ0ZXIgNCB1c2VjcwpbICAgIDQuMDQ1NTc4XSBjYWxsaW5nICBwY2llX3BtZV9z
ZXJ2aWNlX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4wNDU3MDhdIHBjaWVwb3J0IDAwMDA6MDA6
MDEuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuMDQ1
ODEyXSBwY2kgMDAwMDowMTowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50
ZXJydXB0ClsgICAgNC4wNDU5MTddIHBjaWVfcG1lIDAwMDA6MDA6MDEuMDpwY2llMDE6IHNlcnZp
Y2UgZHJpdmVyIHBjaWVfcG1lIGxvYWRlZApbICAgIDQuMDQ2MDc4XSBwY2llcG9ydCAwMDAwOjAw
OjFjLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjA0
NjE5M10gcGNpZV9wbWUgMDAwMDowMDoxYy4wOnBjaWUwMTogc2VydmljZSBkcml2ZXIgcGNpZV9w
bWUgbG9hZGVkClsgICAgNC4wNDYzNTldIHBjaWVwb3J0IDAwMDA6MDA6MWMuNDogU2lnbmFsaW5n
IFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuMDQ2NDY1XSBwY2kgMDAwMDow
MzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC4w
NDY1ODBdIHBjaWVfcG1lIDAwMDA6MDA6MWMuNDpwY2llMDE6IHNlcnZpY2UgZHJpdmVyIHBjaWVf
cG1lIGxvYWRlZApbICAgIDQuMDQ2Njg2XSBpbml0Y2FsbCBwY2llX3BtZV9zZXJ2aWNlX2luaXQr
MHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA5ODEgdXNlY3MKWyAgICA0LjA0NjgwOV0gY2FsbGlu
ZyAgaW9hcGljX2luaXQrMHgwLzB4MWIgQCAxClsgICAgNC4wNDY5MTVdIGluaXRjYWxsIGlvYXBp
Y19pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgNiB1c2VjcwpbICAgIDQuMDQ3MDIwXSBj
YWxsaW5nICBwY2lfaG90cGx1Z19pbml0KzB4MC8weDRiIEAgMQpbICAgIDQuMDQ3MTIxXSBwY2lf
aG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpbICAgIDQuMDQ3MjI0
XSBpbml0Y2FsbCBwY2lfaG90cGx1Z19pbml0KzB4MC8weDRiIHJldHVybmVkIDAgYWZ0ZXIgOTkg
dXNlY3MKWyAgICA0LjA0NzMyOV0gY2FsbGluZyAgcGNpZWRfaW5pdCsweDAvMHhmMCBAIDEKWyAg
ICA0LjA0NzQ0NF0gcGNpZWhwOiBQQ0kgRXhwcmVzcyBIb3QgUGx1ZyBDb250cm9sbGVyIERyaXZl
ciB2ZXJzaW9uOiAwLjQKWyAgICA0LjA0NzU0OF0gaW5pdGNhbGwgcGNpZWRfaW5pdCsweDAvMHhm
MCByZXR1cm5lZCAwIGFmdGVyIDExNCB1c2VjcwpbICAgIDQuMDQ3NjUyXSBjYWxsaW5nICB0c2k3
MjFfaW5pdCsweDAvMHgxYiBAIDEKWyAgICA0LjA0Nzc1OV0gaW5pdGNhbGwgdHNpNzIxX2luaXQr
MHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRlciA1IHVzZWNzClsgICAgNC4wNDc4NjRdIGNhbGxpbmcg
IGZiX2NvbnNvbGVfaW5pdCsweDAvMHgxMWUgQCAxClsgICAgNC4wNDc5NzddIGluaXRjYWxsIGZi
X2NvbnNvbGVfaW5pdCsweDAvMHgxMWUgcmV0dXJuZWQgMCBhZnRlciAxMyB1c2VjcwpbICAgIDQu
MDQ4MDg0XSBjYWxsaW5nICBpbXN0dGZiX2luaXQrMHgwLzB4NGQgQCAxClsgICAgNC4wNDgxOTBd
IGluaXRjYWxsIGltc3R0ZmJfaW5pdCsweDAvMHg0ZCByZXR1cm5lZCAwIGFmdGVyIDYgdXNlY3MK
WyAgICA0LjA0ODI5NV0gY2FsbGluZyAgYXNpbGlhbnRmYl9pbml0KzB4MC8weDM0IEAgMQpbICAg
IDQuMDQ4Mzk5XSBpbml0Y2FsbCBhc2lsaWFudGZiX2luaXQrMHgwLzB4MzQgcmV0dXJuZWQgMCBh
ZnRlciA1IHVzZWNzClsgICAgNC4wNDg1MDRdIGNhbGxpbmcgIGVmaWZiX2luaXQrMHgwLzB4OTIg
QCAxClsgICAgNC4wNDg2MDddIGluaXRjYWxsIGVmaWZiX2luaXQrMHgwLzB4OTIgcmV0dXJuZWQg
LTE5IGFmdGVyIDIgdXNlY3MKWyAgICA0LjA0ODcwOV0gY2FsbGluZyAgaW50ZWxfaWRsZV9pbml0
KzB4MC8weDZlIEAgMQpbICAgIDQuMDQ4ODA5XSBpbml0Y2FsbCBpbnRlbF9pZGxlX2luaXQrMHgw
LzB4NmUgcmV0dXJuZWQgLTE5IGFmdGVyIDAgdXNlY3MKWyAgICA0LjA0ODkxNF0gY2FsbGluZyAg
YWNwaV9yZXNlcnZlX3Jlc291cmNlcysweDAvMHhlYiBAIDEKWyAgICA0LjA0OTAxOV0gaW5pdGNh
bGwgYWNwaV9yZXNlcnZlX3Jlc291cmNlcysweDAvMHhlYiByZXR1cm5lZCAwIGFmdGVyIDIgdXNl
Y3MKWyAgICA0LjA0OTEyNl0gY2FsbGluZyAgaXJxcm91dGVyX2luaXRfb3BzKzB4MC8weDI2IEAg
MQpbICAgIDQuMDQ5MjI4XSBpbml0Y2FsbCBpcnFyb3V0ZXJfaW5pdF9vcHMrMHgwLzB4MjYgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wNDkzMzFdIGNhbGxpbmcgIGFjcGlfYWNfaW5p
dCsweDAvMHg1MCBAIDEKWyAgICA0LjA0OTQ1Nl0gaW5pdGNhbGwgYWNwaV9hY19pbml0KzB4MC8w
eDUwIHJldHVybmVkIDAgYWZ0ZXIgMjQgdXNlY3MKWyAgICA0LjA0OTU2MF0gY2FsbGluZyAgYWNw
aV9idXR0b25faW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjA0OTY5NV0gaW5wdXQ6IFBvd2VyIEJ1
dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9kZXZpY2U6MDAvUE5QMEMwQzowMC9pbnB1dC9p
bnB1dDAKWyAgICA0LjA0OTgyM10gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JCXQpbICAgIDQuMDQ5
OTQ4XSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFBXUkJO
OjAwL2lucHV0L2lucHV0MQpbICAgIDQuMDUwMDcxXSBBQ1BJOiBQb3dlciBCdXR0b24gW1BXUkZd
ClsgICAgNC4wNTAxOTJdIGluaXRjYWxsIGFjcGlfYnV0dG9uX2luaXQrMHgwLzB4MTIgcmV0dXJu
ZWQgMCBhZnRlciA1MTkgdXNlY3MKWyAgICA0LjA1MDI5OF0gY2FsbGluZyAgYWNwaV9mYW5faW5p
dCsweDAvMHgxOCBAIDEKWyAgICA0LjA1MDQxMV0gaW5pdGNhbGwgYWNwaV9mYW5faW5pdCsweDAv
MHgxOCByZXR1cm5lZCAwIGFmdGVyIDExIHVzZWNzClsgICAgNC4wNTA1MTZdIGNhbGxpbmcgIGFj
cGlfcHJvY2Vzc29yX2luaXQrMHgwLzB4ODEgQCAxClsgICAgNC4wNTA4OTVdIGluaXRjYWxsIGFj
cGlfcHJvY2Vzc29yX2luaXQrMHgwLzB4ODEgcmV0dXJuZWQgMCBhZnRlciAyNjcgdXNlY3MKWyAg
ICA0LjA1MDk5OV0gY2FsbGluZyAgYWNwaV9jb250YWluZXJfaW5pdCsweDAvMHg0YSBAIDEKWyAg
ICA0LjA1MjI2N10gaW5pdGNhbGwgYWNwaV9jb250YWluZXJfaW5pdCsweDAvMHg0YSByZXR1cm5l
ZCAwIGFmdGVyIDExMzUgdXNlY3MKWyAgICA0LjA1MjM3M10gY2FsbGluZyAgYWNwaV90aGVybWFs
X2luaXQrMHgwLzB4NDIgQCAxClsgICAgNC4wNTI0ODZdIGluaXRjYWxsIGFjcGlfdGhlcm1hbF9p
bml0KzB4MC8weDQyIHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MKWyAgICA0LjA1MjU5Ml0gY2Fs
bGluZyAgYWNwaV9iYXR0ZXJ5X2luaXQrMHgwLzB4NDggQCAxClsgICAgNC4wNTI3MDldIGluaXRj
YWxsIGFjcGlfYmF0dGVyeV9pbml0KzB4MC8weDQ4IHJldHVybmVkIDAgYWZ0ZXIgMTIgdXNlY3MK
WyAgICA0LjA1MjgxNF0gY2FsbGluZyAgYWNwaV9oZWRfaW5pdCsweDAvMHgyNiBAIDEKWyAgICA0
LjA1MjkyM10gaW5pdGNhbGwgYWNwaV9oZWRfaW5pdCsweDAvMHgyNiByZXR1cm5lZCAwIGFmdGVy
IDEwIHVzZWNzClsgICAgNC4wNTMwMzJdIGNhbGxpbmcgIGVyc3RfaW5pdCsweDAvMHgyYTUgQCAx
ClsgICAgNC4wNTMxNzJdIEFQRUk6IENhbiBub3QgcmVxdWVzdCBpb21lbSByZWdpb24gPDAwMDAw
MDAwYmY0ODkwM2UtMDAwMDAwMDBiZjQ4OTAzZj4gZm9yIEdBUnMuClsgICAgNC4wNTMyOTddIGlu
aXRjYWxsIGVyc3RfaW5pdCsweDAvMHgyYTUgcmV0dXJuZWQgLTIyIGFmdGVyIDE2NCB1c2Vjcwpb
ICAgIDQuMDUzNDAxXSBpbml0Y2FsbCBlcnN0X2luaXQrMHgwLzB4MmE1IHJldHVybmVkIHdpdGgg
ZXJyb3IgY29kZSAtMjIgClsgICAgNC4wNTM1MDVdIGNhbGxpbmcgIGdoZXNfaW5pdCsweDAvMHgx
NzEgQCAxClsgICAgNC4wNTM2NjRdIFtGaXJtd2FyZSBXYXJuXTogR0hFUzogUG9sbCBpbnRlcnZh
bCBpcyAwIGZvciBnZW5lcmljIGhhcmR3YXJlIGVycm9yIHNvdXJjZTogMSwgZGlzYWJsZWQuClsg
ICAgNC4wNTM4NDFdIEdIRVM6IEFQRUkgZmlybXdhcmUgZmlyc3QgbW9kZSBpcyBlbmFibGVkIGJ5
IFdIRUEgX09TQy4KWyAgICA0LjA1Mzk0Nl0gaW5pdGNhbGwgZ2hlc19pbml0KzB4MC8weDE3MSBy
ZXR1cm5lZCAwIGFmdGVyIDMzMiB1c2VjcwpbICAgIDQuMDU0MDQ4XSBjYWxsaW5nICB2aXJ0aW9f
cGNpX2luaXQrMHgwLzB4MWIgQCAxClsgICAgNC4wNTQxNThdIGluaXRjYWxsIHZpcnRpb19wY2lf
aW5pdCsweDAvMHgxYiByZXR1cm5lZCAwIGFmdGVyIDggdXNlY3MKWyAgICA0LjA1NDI2M10gY2Fs
bGluZyAgeGVuYnVzX3Byb2JlX2luaXRjYWxsKzB4MC8weDM5IEAgMQpbICAgIDQuMDU0MzY3XSBp
bml0Y2FsbCB4ZW5idXNfcHJvYmVfaW5pdGNhbGwrMHgwLzB4MzkgcmV0dXJuZWQgMCBhZnRlciAw
IHVzZWNzClsgICAgNC4wNTQ0NzNdIGNhbGxpbmcgIGh5cGVydmlzb3Jfc3Vic3lzX2luaXQrMHgw
LzB4MjUgQCAxClsgICAgNC4wNTQ1NzVdIGluaXRjYWxsIGh5cGVydmlzb3Jfc3Vic3lzX2luaXQr
MHgwLzB4MjUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wNTQ2ODJdIGNhbGxpbmcg
IGh5cGVyX3N5c2ZzX2luaXQrMHgwLzB4MTkgQCAxClsgICAgNC4wNTQ3OTFdIGluaXRjYWxsIGh5
cGVyX3N5c2ZzX2luaXQrMHgwLzB4MTkgcmV0dXJuZWQgMCBhZnRlciA3IHVzZWNzClsgICAgNC4w
NTQ4OTddIGNhbGxpbmcgIHBsYXRmb3JtX3BjaV9tb2R1bGVfaW5pdCsweDAvMHgyOSBAIDEKWyAg
ICA0LjA1NTAwMF0gaW5pdGNhbGwgcGxhdGZvcm1fcGNpX21vZHVsZV9pbml0KzB4MC8weDI5IHJl
dHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgNC4wNTUxMjZdIGNhbGxpbmcgIHhlbl90bWVt
X2luaXQrMHgwLzB4NWMgQCAxClsgICAgNC4wNTUyMjddIGluaXRjYWxsIHhlbl90bWVtX2luaXQr
MHgwLzB4NWMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4wNTUzMjhdIGNhbGxpbmcg
IHB0eV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMDU1NDY5XSBpbml0Y2FsbCBwdHlfaW5pdCsw
eDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDM5IHVzZWNzClsgICAgNC4wNTU1NzRdIGNhbGxpbmcg
IHN5c3JxX2luaXQrMHgwLzB4NzggQCAxClsgICAgNC4wNTU2NzZdIGluaXRjYWxsIHN5c3JxX2lu
aXQrMHgwLzB4NzggcmV0dXJuZWQgMCBhZnRlciAyIHVzZWNzClsgICAgNC4wNTU3ODJdIGNhbGxp
bmcgIHhlbl9odmNfaW5pdCsweDAvMHgxM2UgQCAxClsgICAgNC4wNTYxMDRdIGluaXRjYWxsIHhl
bl9odmNfaW5pdCsweDAvMHgxM2UgcmV0dXJuZWQgMCBhZnRlciAyMTcgdXNlY3MKWyAgICA0LjA1
NjIxMF0gY2FsbGluZyAgc2VyaWFsODI1MF9pbml0KzB4MC8weDY1IEAgMQpbICAgIDQuMDU2MzEw
XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCAzMiBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxl
ZApbICAgIDQuMDc3NTY3XSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQp
IGlzIGEgMTY1NTBBClsgICAgNC4xMTQzMjRdIHNlcmlhbDgyNTA6IHR0eVMxIGF0IEkvTyAweDJm
OCAoaXJxID0gMykgaXMgYSAxNjU1MEEKWyAgICA0LjE0MjM1Ml0gc2VyaWFsODI1MDogdHR5UzIg
YXQgSS9PIDB4M2U4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQpbICAgIDQuMTQ0MzA4XSBpbml0Y2Fs
bCBzZXJpYWw4MjUwX2luaXQrMHgwLzB4NjUgcmV0dXJuZWQgMCBhZnRlciA4NTkzNCB1c2Vjcwpb
ICAgIDQuMTQ0NDE0XSBjYWxsaW5nICBzZXJpYWw4MjUwX3BucF9pbml0KzB4MC8weDEyIEAgMQpb
ICAgIDQuMTY1NzIzXSAwMDowYTogdHR5UzAgYXQgSS9PIDB4M2Y4IChpcnEgPSA0KSBpcyBhIDE2
NTUwQQpbICAgIDQuMjAyMzY5XSAwMDowYjogdHR5UzEgYXQgSS9PIDB4MmY4IChpcnEgPSAzKSBp
cyBhIDE2NTUwQQpbICAgIDQuMjM0MzY0XSAwMDowZDogdHR5UzIgYXQgSS9PIDB4M2U4IChpcnEg
PSAxMCkgaXMgYSAxNjU1MEEKWyAgICA0LjI0OTE2OF0gaW5pdGNhbGwgc2VyaWFsODI1MF9wbnBf
aW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDEwMjE5NyB1c2VjcwpbICAgIDQuMjQ5MzE1
XSBjYWxsaW5nICBzZXJpYWw4MjUwX3BjaV9pbml0KzB4MC8weDFiIEAgMQpbICAgIDQuMjQ5NDMz
XSBpbml0Y2FsbCBzZXJpYWw4MjUwX3BjaV9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIg
MTUgdXNlY3MKWyAgICA0LjI0OTU0MV0gY2FsbGluZyAgaW5pdF9rZ2Rib2MrMHgwLzB4MTYgQCAx
ClsgICAgNC4yNDk2NDBdIGluaXRjYWxsIGluaXRfa2dkYm9jKzB4MC8weDE2IHJldHVybmVkIDAg
YWZ0ZXIgMSB1c2VjcwpbICAgIDQuMjQ5NzQ0XSBjYWxsaW5nICByYW5kX2luaXRpYWxpemUrMHgw
LzB4NDAgQCAxClsgICAgNC4yNDk4NTVdIGluaXRjYWxsIHJhbmRfaW5pdGlhbGl6ZSsweDAvMHg0
MCByZXR1cm5lZCAwIGFmdGVyIDkgdXNlY3MKWyAgICA0LjI0OTk1OF0gY2FsbGluZyAgdHR5cHJp
bnRrX2luaXQrMHgwLzB4MTUzIEAgMQpbICAgIDQuMjUwMDg4XSBpbml0Y2FsbCB0dHlwcmludGtf
aW5pdCsweDAvMHgxNTMgcmV0dXJuZWQgMCBhZnRlciAyNyB1c2VjcwpbICAgIDQuMjUwMTkyXSBj
YWxsaW5nICBocGV0X2luaXQrMHgwLzB4NjcgQCAxClsgICAgNC4yNTAzNjldIGhwZXRfYWNwaV9h
ZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBpbiBfQ1JTClsgICAgNC4yNTA0NzldIGluaXRjYWxsIGhw
ZXRfaW5pdCsweDAvMHg2NyByZXR1cm5lZCAwIGFmdGVyIDE4MiB1c2VjcwpbICAgIDQuMjUwNTgy
XSBjYWxsaW5nICBhZ3BfaW5pdCsweDAvMHgyNiBAIDEKWyAgICA0LjI1MDY4Ml0gTGludXggYWdw
Z2FydCBpbnRlcmZhY2UgdjAuMTAzClsgICAgNC4yNTA3ODNdIGluaXRjYWxsIGFncF9pbml0KzB4
MC8weDI2IHJldHVybmVkIDAgYWZ0ZXIgOTggdXNlY3MKWyAgICA0LjI1MDg4N10gY2FsbGluZyAg
YWdwX2FtZDY0X21vZF9pbml0KzB4MC8weDIyIEAgMQpbICAgIDQuMjUxMDAwXSBpbml0Y2FsbCBh
Z3BfYW1kNjRfbW9kX2luaXQrMHgwLzB4MjIgcmV0dXJuZWQgLTE5IGFmdGVyIDEzIHVzZWNzClsg
ICAgNC4yNTExMDVdIGNhbGxpbmcgIGFncF9pbnRlbF9pbml0KzB4MC8weDI5IEAgMQpbICAgIDQu
MjUxMjcxXSBpbml0Y2FsbCBhZ3BfaW50ZWxfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVy
IDYzIHVzZWNzClsgICAgNC4yNTEzNzVdIGNhbGxpbmcgIGFncF92aWFfaW5pdCsweDAvMHgyOSBA
IDEKWyAgICA0LjI1MTQ4MV0gaW5pdGNhbGwgYWdwX3ZpYV9pbml0KzB4MC8weDI5IHJldHVybmVk
IDAgYWZ0ZXIgNiB1c2VjcwpbICAgIDQuMjUxNTg0XSBjYWxsaW5nICBjbl9wcm9jX2luaXQrMHgw
LzB4M2EgQCAxClsgICAgNC4yNTE2ODZdIGluaXRjYWxsIGNuX3Byb2NfaW5pdCsweDAvMHgzYSBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjI1MTc5MF0gY2FsbGluZyAgdG9wb2xvZ3lf
c3lzZnNfaW5pdCsweDAvMHg2NyBAIDEKWyAgICA0LjI1MTkwMV0gaW5pdGNhbGwgdG9wb2xvZ3lf
c3lzZnNfaW5pdCsweDAvMHg2NyByZXR1cm5lZCAwIGFmdGVyIDcgdXNlY3MKWyAgICA0LjI1MjAw
NV0gY2FsbGluZyAgYnJkX2luaXQrMHgwLzB4MWQwIEAgMQpbICAgIDQuMjUzMDc2XSBicmQ6IG1v
ZHVsZSBsb2FkZWQKWyAgICA0LjI1MzE3NV0gaW5pdGNhbGwgYnJkX2luaXQrMHgwLzB4MWQwIHJl
dHVybmVkIDAgYWZ0ZXIgMTA0NSB1c2VjcwpbICAgIDQuMjUzMjgyXSBjYWxsaW5nICBsb29wX2lu
aXQrMHgwLzB4MTJmIEAgMQpbICAgIDQuMjUzOTEwXSBsb29wOiBtb2R1bGUgbG9hZGVkClsgICAg
NC4yNTQwMTFdIGluaXRjYWxsIGxvb3BfaW5pdCsweDAvMHgxMmYgcmV0dXJuZWQgMCBhZnRlciA2
MTMgdXNlY3MKWyAgICA0LjI1NDExNV0gY2FsbGluZyAgaW5pdCsweDAvMHg3YyBAIDEKWyAgICA0
LjI1NDI2MF0gaW5pdGNhbGwgaW5pdCsweDAvMHg3YyByZXR1cm5lZCAwIGFmdGVyIDQ1IHVzZWNz
ClsgICAgNC4yNTQzNjVdIGNhbGxpbmcgIHhsYmxrX2luaXQrMHgwLzB4OTMgQCAxClsgICAgNC4y
NTQ0NzBdIGluaXRjYWxsIHhsYmxrX2luaXQrMHgwLzB4OTMgcmV0dXJuZWQgMCBhZnRlciA0IHVz
ZWNzClsgICAgNC4yNTQ1NzJdIGNhbGxpbmcgIGh0Y3BsZF9jb3JlX2luaXQrMHgwLzB4MmIgQCAx
ClsgICAgNC4yNTQ2ODZdIGluaXRjYWxsIGh0Y3BsZF9jb3JlX2luaXQrMHgwLzB4MmIgcmV0dXJu
ZWQgLTE5IGFmdGVyIDEzIHVzZWNzClsgICAgNC4yNTQ3OTFdIGNhbGxpbmcgIHdtODk5NF9pMmNf
aW5pdCsweDAvMHgzMCBAIDEKWyAgICA0LjI1NDg5N10gaW5pdGNhbGwgd204OTk0X2kyY19pbml0
KzB4MC8weDMwIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMjU1MDAyXSBjYWxsaW5n
ICBhZHA1NTIwX2luaXQrMHgwLzB4MTQgQCAxClsgICAgNC4yNTUxMDldIGluaXRjYWxsIGFkcDU1
MjBfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA0LjI1NTIxM10g
Y2FsbGluZyAgc3BpX3RyYW5zcG9ydF9pbml0KzB4MC8weDdjIEAgMQpbICAgIDQuMjU1MzIwXSBp
bml0Y2FsbCBzcGlfdHJhbnNwb3J0X2luaXQrMHgwLzB4N2MgcmV0dXJuZWQgMCBhZnRlciA2IHVz
ZWNzClsgICAgNC4yNTU0MjVdIGNhbGxpbmcgIHNjc2lfZGhfaW5pdCsweDAvMHg1MyBAIDEKWyAg
ICA0LjI1NTUyNl0gaW5pdGNhbGwgc2NzaV9kaF9pbml0KzB4MC8weDUzIHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDQuMjU1NjMxXSBjYWxsaW5nICBzeW0yX2luaXQrMHgwLzB4NTUgQCAx
ClsgICAgNC4yNTU3MzhdIGluaXRjYWxsIHN5bTJfaW5pdCsweDAvMHg1NSByZXR1cm5lZCAwIGFm
dGVyIDggdXNlY3MKWyAgICA0LjI1NTg0Ml0gY2FsbGluZyAgaW5pdF9zZCsweDAvMHgxMzEgQCAx
ClsgICAgNC4yNTU5NTNdIGluaXRjYWxsIGluaXRfc2QrMHgwLzB4MTMxIHJldHVybmVkIDAgYWZ0
ZXIgMTAgdXNlY3MKWyAgICA0LjI1NjA1N10gY2FsbGluZyAgaW5pdF9zcisweDAvMHg0NiBAIDEK
WyAgICA0LjI1NjE2MV0gaW5pdGNhbGwgaW5pdF9zcisweDAvMHg0NiByZXR1cm5lZCAwIGFmdGVy
IDMgdXNlY3MKWyAgICA0LjI1NjI2NF0gY2FsbGluZyAgaW5pdF9zZysweDAvMHg2MyBAIDEKWyAg
ICA0LjI1NjM3M10gaW5pdGNhbGwgaW5pdF9zZysweDAvMHg2MyByZXR1cm5lZCAwIGFmdGVyIDkg
dXNlY3MKWyAgICA0LjI1NjQ3NV0gY2FsbGluZyAgYWhjaV9pbml0KzB4MC8weDFiIEAgMQpbICAg
IDQuMjU2NTgyXSBhaGNpIDAwMDA6MDA6MWYuMjogdmVyc2lvbiAzLjAKWyAgICA0LjI1NjY5N10g
eGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjI1
NjgwNV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkKWyAgICA0LjI1NjkzNF0g
YWhjaSAwMDAwOjAwOjFmLjI6IFBDSSBJTlQgQiAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElS
USAxOQpbICAgIDQuMjU3MTg1XSBhaGNpIDAwMDA6MDA6MWYuMjogY29udHJvbGxlciBjYW4ndCBk
byBTTlRGLCB0dXJuaW5nIG9mZiBDQVBfU05URgpbICAgIDQuMjczMTk0XSBhaGNpIDAwMDA6MDA6
MWYuMjogQUhDSSAwMDAxLjAzMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFJB
SUQgbW9kZQpbICAgIDQuMjczMzM5XSBhaGNpIDAwMDA6MDA6MWYuMjogZmxhZ3M6IDY0Yml0IG5j
cSBwbSBsZWQgY2xvIHBpbyBzbHVtIHBhcnQgZW1zIGFwc3QgClsgICAgNC4yNzM0NzNdIGFoY2kg
MDAwMDowMDoxZi4yOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjMxMzUzOF0g
c2NzaTAgOiBhaGNpClsgICAgNC4zMTM3MDRdIHNjc2kxIDogYWhjaQpbICAgIDQuMzEzODYwXSBz
Y3NpMiA6IGFoY2kKWyAgICA0LjMxNDAxN10gc2NzaTMgOiBhaGNpClsgICAgNC4zMTQxNzBdIHNj
c2k0IDogYWhjaQpbICAgIDQuMzE0MzI1XSBzY3NpNSA6IGFoY2kKWyAgICA0LjMxNDU1MF0gYXRh
MTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0OEAweGZiYjIxMDAwIHBvcnQgMHhmYmIyMTEw
MCBpcnEgMjg5ClsgICAgNC4zMTQ2NzhdIGF0YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIw
NDhAMHhmYmIyMTAwMCBwb3J0IDB4ZmJiMjExODAgaXJxIDI4OQpbICAgIDQuMzE0ODA1XSBhdGEz
OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4QDB4ZmJiMjEwMDAgcG9ydCAweGZiYjIxMjAw
IGlycSAyODkKWyAgICA0LjMxNDkzMl0gYXRhNDogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0
OEAweGZiYjIxMDAwIHBvcnQgMHhmYmIyMTI4MCBpcnEgMjg5ClsgICAgNC4zMTUwNTldIGF0YTU6
IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmYmIyMTAwMCBwb3J0IDB4ZmJiMjEzMDAg
aXJxIDI4OQpbICAgIDQuMzE1MTg4XSBhdGE2OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4
QDB4ZmJiMjEwMDAgcG9ydCAweGZiYjIxMzgwIGlycSAyODkKWyAgICA0LjMxNTMyNF0gY2FsbGlu
ZyAgMl9hc3luY19wb3J0X3Byb2JlKzB4MC8weDcwIEAgNQpbICAgIDQuMzE1MzI5XSBpbml0Y2Fs
bCBhaGNpX2luaXQrMHgwLzB4MWIgcmV0dXJuZWQgMCBhZnRlciA1NzM3NiB1c2VjcwpbICAgIDQu
MzE1MzMxXSBjYWxsaW5nICBhZG1hX2F0YV9pbml0KzB4MC8weDFiIEAgMQpbICAgIDQuMzE1MzQy
XSBpbml0Y2FsbCBhZG1hX2F0YV9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgOCB1c2Vj
cwpbICAgIDQuMzE1MzQ0XSBjYWxsaW5nICBwaWl4X2luaXQrMHgwLzB4MjkgQCAxClsgICAgNC4z
MTUzNTRdIGluaXRjYWxsIHBpaXhfaW5pdCsweDAvMHgyOSByZXR1cm5lZCAwIGFmdGVyIDggdXNl
Y3MKWyAgICA0LjMxNTM1Nl0gY2FsbGluZyAgc2lzX2luaXQrMHgwLzB4MWIgQCAxClsgICAgNC4z
MTUzNjVdIGluaXRjYWxsIHNpc19pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgNiB1c2Vj
cwpbICAgIDQuMzE1MzY2XSBjYWxsaW5nICBwYWNwaV9pbml0KzB4MC8weDFiIEAgMQpbICAgIDQu
MzE1Mzc2XSBpbml0Y2FsbCBwYWNwaV9pbml0KzB4MC8weDFiIHJldHVybmVkIDAgYWZ0ZXIgNyB1
c2VjcwpbICAgIDQuMzE1Mzc4XSBjYWxsaW5nICBhdGFfZ2VuZXJpY19pbml0KzB4MC8weDFiIEAg
MQpbICAgIDQuMzE1Mzg4XSBpbml0Y2FsbCBhdGFfZ2VuZXJpY19pbml0KzB4MC8weDFiIHJldHVy
bmVkIDAgYWZ0ZXIgNyB1c2VjcwpbICAgIDQuMzE1MzkwXSBjYWxsaW5nICBuZXRfb2xkZGV2c19p
bml0KzB4MC8weDFjIEAgMQpbICAgIDQuMzE1Mzk0XSBpbml0Y2FsbCBuZXRfb2xkZGV2c19pbml0
KzB4MC8weDFjIHJldHVybmVkIDAgYWZ0ZXIgMiB1c2VjcwpbICAgIDQuMzE1Mzk2XSBjYWxsaW5n
ICBtYXJ2ZWxsX2luaXQrMHgwLzB4NjQgQCAxClsgICAgNC4zMTU0MjddIGluaXRjYWxsIG1hcnZl
bGxfaW5pdCsweDAvMHg2NCByZXR1cm5lZCAwIGFmdGVyIDI4IHVzZWNzClsgICAgNC4zMTU0Mjld
IGNhbGxpbmcgIGRhdmljb21faW5pdCsweDAvMHg1ZSBAIDEKWyAgICA0LjMxNTQ0MV0gaW5pdGNh
bGwgZGF2aWNvbV9pbml0KzB4MC8weDVlIHJldHVybmVkIDAgYWZ0ZXIgMTAgdXNlY3MKWyAgICA0
LjMxNTQ0M10gY2FsbGluZyAgY2ljYWRhX2luaXQrMHgwLzB4M2MgQCAxClsgICAgNC4zMTU0NTNd
IGluaXRjYWxsIGNpY2FkYV9pbml0KzB4MC8weDNjIHJldHVybmVkIDAgYWZ0ZXIgNyB1c2Vjcwpb
ICAgIDQuMzE1NDU0XSBjYWxsaW5nICBseHRfaW5pdCsweDAvMHg1ZSBAIDEKWyAgICA0LjMxNTQ2
NV0gaW5pdGNhbGwgbHh0X2luaXQrMHgwLzB4NWUgcmV0dXJuZWQgMCBhZnRlciA4IHVzZWNzClsg
ICAgNC4zMTU0NjddIGNhbGxpbmcgIHFzNjYxMl9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMzE1
NDcyXSBpbml0Y2FsbCBxczY2MTJfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDIgdXNl
Y3MKWyAgICA0LjMxNTQ3M10gY2FsbGluZyAgc21zY19pbml0KzB4MC8weGE2IEAgMQpbICAgIDQu
MzE1NDkzXSBpbml0Y2FsbCBzbXNjX2luaXQrMHgwLzB4YTYgcmV0dXJuZWQgMCBhZnRlciAxNyB1
c2VjcwpbICAgIDQuMzE1NDk1XSBjYWxsaW5nICB2c2M4Mnh4X2luaXQrMHgwLzB4M2MgQCAxClsg
ICAgNC4zMTU1MDNdIGluaXRjYWxsIHZzYzgyeHhfaW5pdCsweDAvMHgzYyByZXR1cm5lZCAwIGFm
dGVyIDYgdXNlY3MKWyAgICA0LjMxNTUwNV0gY2FsbGluZyAgYnJvYWRjb21faW5pdCsweDAvMHgx
OGUgQCAxClsgICAgNC4zMTU1NDZdIGluaXRjYWxsIGJyb2FkY29tX2luaXQrMHgwLzB4MThlIHJl
dHVybmVkIDAgYWZ0ZXIgMzggdXNlY3MKWyAgICA0LjMxNTU0OF0gY2FsbGluZyAgaWNwbHVzX2lu
aXQrMHgwLzB4M2YgQCAxClsgICAgNC4zMTU1NjFdIGluaXRjYWxsIGljcGx1c19pbml0KzB4MC8w
eDNmIHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MKWyAgICA0LjMxNTU2M10gY2FsbGluZyAgcmVh
bHRla19pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMzE1NTcwXSBpbml0Y2FsbCByZWFsdGVrX2lu
aXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA0IHVzZWNzClsgICAgNC4zMTU1NzJdIGNhbGxp
bmcgIGV0MTAxMWNfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjMxNTU3N10gaW5pdGNhbGwgZXQx
MDExY19pbml0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMzE1NTc5
XSBjYWxsaW5nICBmaXhlZF9tZGlvX2J1c19pbml0KzB4MC8weDEyNyBAIDEKWyAgICA0LjMxNTYw
Ml0gRml4ZWQgTURJTyBCdXM6IHByb2JlZApbICAgIDQuMzE1NjA0XSBpbml0Y2FsbCBmaXhlZF9t
ZGlvX2J1c19pbml0KzB4MC8weDEyNyByZXR1cm5lZCAwIGFmdGVyIDIyIHVzZWNzClsgICAgNC4z
MTU2MDZdIGNhbGxpbmcgIG5zX2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4zMTU2MTJdIGluaXRj
YWxsIG5zX2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciAzIHVzZWNzClsgICAgNC4zMTU2
MTNdIGNhbGxpbmcgIHN0ZTEwWHBfaW5pdCsweDAvMHgyMiBAIDEKWyAgICA0LjMxNTYyNV0gaW5p
dGNhbGwgc3RlMTBYcF9pbml0KzB4MC8weDIyIHJldHVybmVkIDAgYWZ0ZXIgOSB1c2VjcwpbICAg
IDQuMzE1NjI3XSBjYWxsaW5nICB0dW5faW5pdCsweDAvMHg5MCBAIDEKWyAgICA0LjMxNTYyOF0g
dHVuOiBVbml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgICA0LjMxNTYyOV0g
dHVuOiAoQykgMTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29tbS5jb20+Clsg
ICAgNC4zMTU2NThdIGluaXRjYWxsIHR1bl9pbml0KzB4MC8weDkwIHJldHVybmVkIDAgYWZ0ZXIg
MjggdXNlY3MKWyAgICA0LjMxNTY2MF0gY2FsbGluZyAgaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0
LjMxNTY2NV0gaW5pdGNhbGwgaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MK
WyAgICA0LjMxNTY2N10gY2FsbGluZyAgcHBwX2luaXQrMHgwLzB4ZTEgQCAxClsgICAgNC4zMTU2
NjhdIFBQUCBnZW5lcmljIGRyaXZlciB2ZXJzaW9uIDIuNC4yClsgICAgNC4zMTU2OTVdIGluaXRj
YWxsIHBwcF9pbml0KzB4MC8weGUxIHJldHVybmVkIDAgYWZ0ZXIgMjUgdXNlY3MKWyAgICA0LjMx
NTY5N10gY2FsbGluZyAgbmV0aWZfaW5pdCsweDAvMHg2NiBAIDEKWyAgICA0LjMxNTY5OV0gaW5p
dGNhbGwgbmV0aWZfaW5pdCsweDAvMHg2NiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0
LjMxNTcwMV0gY2FsbGluZyAgY2Ryb21faW5pdCsweDAvMHgxNiBAIDEKWyAgICA0LjMxNTcxM10g
aW5pdGNhbGwgY2Ryb21faW5pdCsweDAvMHgxNiByZXR1cm5lZCAwIGFmdGVyIDkgdXNlY3MKWyAg
ICA0LjMxNTcxNV0gY2FsbGluZyAgbW9uX2luaXQrMHgwLzB4MTAwIEAgMQpbICAgIDQuMzE1NzQx
XSBpbml0Y2FsbCBtb25faW5pdCsweDAvMHgxMDAgcmV0dXJuZWQgMCBhZnRlciAyMyB1c2Vjcwpb
ICAgIDQuMzE1NzQ0XSBjYWxsaW5nICBlaGNpX2hjZF9pbml0KzB4MC8weDFkIEAgMQpbICAgIDQu
MzE1NzQ1XSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhD
SSkgRHJpdmVyClsgICAgNC4zMTU3NjFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAgNC4zMTU3NjNdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmlu
ZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuMzE1NzY0XSB4ZW46IC0tPiBwaXJxPTE2IC0+IGly
cT0xNiAoZ3NpPTE2KQpbICAgIDQuMzE1NzY1XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2Clsg
ICAgNC4zMTU3NjddIGVoY2lfaGNkIDAwMDA6MDA6MWEuMDogUENJIElOVCBBIC0+IEdTSSAxNiAo
bGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgNC4zMTU3ODddIGVoY2lfaGNkIDAwMDA6MDA6MWEu
MDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4zMTU3OTJdIGVoY2lfaGNkIDAw
MDA6MDA6MWEuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA0LjMxNTgyMV0gZWhjaV9oY2Qg
MDAwMDowMDoxYS4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVy
IDEKWyAgICA0LjMxNTg3OF0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBkZWJ1ZyBwb3J0IDIKWyAg
ICA0LjMxOTc4OF0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBjYWNoZSBsaW5lIHNpemUgb2YgNjQg
aXMgbm90IHN1cHBvcnRlZApbICAgIDQuMzE5ODYxXSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IGly
cSAxNiwgaW8gbWVtIDB4ZmJiMjMwMDAKWyAgICA0LjMyMDIwNF0gY2FsbGluZyAgM19hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgMTYKWyAgICA0LjMyMDMwM10gY2FsbGluZyAgNF9hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNDkKWyAgICA0LjMyMDM4OV0gY2FsbGluZyAgNV9hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNTAKWyAgICA0LjMyMDQ4OF0gY2FsbGluZyAgNl9hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNTEKWyAgICA0LjMyMDU4NF0gY2FsbGluZyAgN19hc3luY19w
b3J0X3Byb2JlKzB4MC8weDcwIEAgNTIKWyAgICA0LjMzMzE0NV0gZWhjaV9oY2QgMDAwMDowMDox
YS4wOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMApbICAgIDQuMzMzMzgwXSBodWIgMS0wOjEu
MDogVVNCIGh1YiBmb3VuZApbICAgIDQuMzMzNDgyXSBodWIgMS0wOjEuMDogMiBwb3J0cyBkZXRl
Y3RlZApbICAgIDQuMzMzNjQyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQpbICAgIDQuMzMzNzQ1XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx
IDIzIGZvciBnc2kgMjMKWyAgICA0LjMzMzg0OF0geGVuOiAtLT4gcGlycT0yMyAtPiBpcnE9MjMg
KGdzaT0yMykKWyAgICA0LjMzMzk0N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMwpbICAgIDQu
MzM0MDQ3XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IFBDSSBJTlQgQSAtPiBHU0kgMjMgKGxldmVs
LCBsb3cpIC0+IElSUSAyMwpbICAgIDQuMzM0MTc0XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IHNl
dHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMzM0MjgwXSBlaGNpX2hjZCAwMDAwOjAw
OjFkLjA6IEVIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgNC4zMzQ0MThdIGVoY2lfaGNkIDAwMDA6
MDA6MWQuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyClsg
ICAgNC4zMzQ1OTVdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogZGVidWcgcG9ydCAyClsgICAgNC4z
Mzg1ODZdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogY2FjaGUgbGluZSBzaXplIG9mIDY0IGlzIG5v
dCBzdXBwb3J0ZWQKWyAgICA0LjMzODc1MV0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBpcnEgMjMs
IGlvIG1lbSAweGZiYjIyMDAwClsgICAgNC4zNTMxNDhdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDog
VVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKWyAgICA0LjM1MzM2MV0gaHViIDItMDoxLjA6IFVT
QiBodWIgZm91bmQKWyAgICA0LjM1MzQ2MV0gaHViIDItMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQK
WyAgICA0LjM1NTMxNF0gaW5pdGNhbGwgZWhjaV9oY2RfaW5pdCsweDAvMHgxZCByZXR1cm5lZCAw
IGFmdGVyIDM4NjQwIHVzZWNzClsgICAgNC4zNTU0MjBdIGNhbGxpbmcgIG9oY2lfaGNkX21vZF9p
bml0KzB4MC8weDU0IEAgMQpbICAgIDQuMzU1NTIxXSBvaGNpX2hjZDogVVNCIDEuMSAnT3Blbicg
SG9zdCBDb250cm9sbGVyIChPSENJKSBEcml2ZXIKWyAgICA0LjM1NTYzM10gaW5pdGNhbGwgb2hj
aV9oY2RfbW9kX2luaXQrMHgwLzB4NTQgcmV0dXJuZWQgMCBhZnRlciAxMDggdXNlY3MKWyAgICA0
LjM1NTczOV0gY2FsbGluZyAgdWhjaV9oY2RfaW5pdCsweDAvMHgxZCBAIDEKWyAgICA0LjM1NTgz
OV0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250cm9sbGVyIEludGVyZmFjZSBkcml2
ZXIKWyAgICA0LjM1NTk1M10gaW5pdGNhbGwgdWhjaV9oY2RfaW5pdCsweDAvMHgxZCByZXR1cm5l
ZCAwIGFmdGVyIDExMCB1c2VjcwpbICAgIDQuMzU2MDU4XSBjYWxsaW5nICB4aGNpX2hjZF9pbml0
KzB4MC8weDI5IEAgMQpbICAgIDQuMzU2MTY4XSBpbml0Y2FsbCB4aGNpX2hjZF9pbml0KzB4MC8w
eDI5IHJldHVybmVkIDAgYWZ0ZXIgOCB1c2VjcwpbICAgIDQuMzU2MjcyXSBjYWxsaW5nICB1c2Jf
dXN1YWxfaW5pdCsweDAvMHgzYiBAIDEKWyAgICA0LjM1NjM4NF0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBsaWJ1c3VhbApbICAgIDQuMzU2NDg3XSBpbml0Y2FsbCB1
c2JfdXN1YWxfaW5pdCsweDAvMHgzYiByZXR1cm5lZCAwIGFmdGVyIDEwOSB1c2VjcwpbICAgIDQu
MzU2NTkzXSBjYWxsaW5nICBpODA0Ml9pbml0KzB4MC8weDgwIEAgMQpbICAgIDQuMzU2NzE2XSBp
ODA0MjogUE5QOiBQUy8yIENvbnRyb2xsZXIgW1BOUDAzMDM6UFMySyxQTlAwZjAzOlBTMk1dIGF0
IDB4NjAsMHg2NCBpcnEgMSwxMgpbICAgIDQuMzYwMTI3XSBzZXJpbzogaTgwNDIgS0JEIHBvcnQg
YXQgMHg2MCwweDY0IGlycSAxClsgICAgNC4zNjAyMjldIHNlcmlvOiBpODA0MiBBVVggcG9ydCBh
dCAweDYwLDB4NjQgaXJxIDEyClsgICAgNC4zNjAzNzFdIGluaXRjYWxsIGk4MDQyX2luaXQrMHgw
LzB4ODAgcmV0dXJuZWQgMCBhZnRlciAzNTkyIHVzZWNzClsgICAgNC4zNjA0NzddIGNhbGxpbmcg
IG1vdXNlZGV2X2luaXQrMHgwLzB4OGEgQCAxClsgICAgNC4zNjA2MzRdIG1vdXNlZGV2OiBQUy8y
IG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlClsgICAgNC4zNjA3MzldIGluaXRjYWxs
IG1vdXNlZGV2X2luaXQrMHgwLzB4OGEgcmV0dXJuZWQgMCBhZnRlciAxNjAgdXNlY3MKWyAgICA0
LjM2MDg0NF0gY2FsbGluZyAgZXZkZXZfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0LjM2MDk5OF0g
aW5pdGNhbGwgZXZkZXZfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDUwIHVzZWNzClsg
ICAgNC4zNjExMDBdIGNhbGxpbmcgIGF0a2JkX2luaXQrMHgwLzB4MjcgQCAxClsgICAgNC4zNjEy
MTZdIGluaXRjYWxsIGF0a2JkX2luaXQrMHgwLzB4MjcgcmV0dXJuZWQgMCBhZnRlciAxNCB1c2Vj
cwpbICAgIDQuMzYxMzE5XSBjYWxsaW5nICB1aW5wdXRfaW5pdCsweDAvMHgxMiBAIDEKWyAgICA0
LjM2MTQ2NV0gaW5pdGNhbGwgdWlucHV0X2luaXQrMHgwLzB4MTIgcmV0dXJuZWQgMCBhZnRlciA0
MiB1c2VjcwpbICAgIDQuMzYxNTcwXSBjYWxsaW5nICBjbW9zX2luaXQrMHgwLzB4NmEgQCAxClsg
ICAgNC4zNjE3MDVdIHJ0Y19jbW9zIDAwOjAzOiBSVEMgY2FuIHdha2UgZnJvbSBTNApbICAgIDQu
MzYyMDA5XSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJlZ2lzdGVyZWQgcnRjX2Ntb3MgYXMg
cnRjMApbICAgIDQuMzYyMjA5XSBydGMwOiBhbGFybXMgdXAgdG8gb25lIG1vbnRoLCB5M2ssIDEx
NCBieXRlcyBudnJhbQpbICAgIDQuMzYyMzE4XSBpbml0Y2FsbCBjbW9zX2luaXQrMHgwLzB4NmEg
cmV0dXJuZWQgMCBhZnRlciA2MzIgdXNlY3MKWyAgICA0LjM2MjQyMV0gY2FsbGluZyAgZG1faW5p
dCsweDAvMHg0NSBAIDEKWyAgICA0LjM2MjU2Nl0gZGV2aWNlLW1hcHBlcjogdWV2ZW50OiB2ZXJz
aW9uIDEuMC4zClsgICAgNC4zNjI3MTRdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIyLjAtaW9j
dGwgKDIwMTEtMTAtMTkpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsgICAgNC4z
NjI4NDFdIGluaXRjYWxsIGRtX2luaXQrMHgwLzB4NDUgcmV0dXJuZWQgMCBhZnRlciAzMTIgdXNl
Y3MKWyAgICA0LjM2Mjk0NV0gY2FsbGluZyAgY3B1ZnJlcV9zdGF0c19pbml0KzB4MC8weDljIEAg
MQpbICAgIDQuMzYzMDQ2XSBpbml0Y2FsbCBjcHVmcmVxX3N0YXRzX2luaXQrMHgwLzB4OWMgcmV0
dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4zNjMxNTNdIGNhbGxpbmcgIGNwdWZyZXFfZ292
X3Bvd2Vyc2F2ZV9pbml0KzB4MC8weDEyIEAgMQpbICAgIDQuMzYzMjU3XSBpbml0Y2FsbCBjcHVm
cmVxX2dvdl9wb3dlcnNhdmVfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM2MzM4Ml0gY2FsbGluZyAgY3B1ZnJlcV9nb3ZfdXNlcnNwYWNlX2luaXQrMHgwLzB4
MTIgQCAxClsgICAgNC4zNjM0ODRdIGluaXRjYWxsIGNwdWZyZXFfZ292X3VzZXJzcGFjZV9pbml0
KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzYzNjA5XSBjYWxsaW5n
ICBjcHVmcmVxX2dvdl9kYnNfaW5pdCsweDAvMHg1ZSBAIDEKWyAgICA0LjM2MzcxMl0gaW5pdGNh
bGwgY3B1ZnJlcV9nb3ZfZGJzX2luaXQrMHgwLzB4NWUgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNz
ClsgICAgNC4zNjM4MTddIGNhbGxpbmcgIGNwdWZyZXFfZ292X2Ric19pbml0KzB4MC8weDEyIEAg
MQpbICAgIDQuMzYzOTIwXSBpbml0Y2FsbCBjcHVmcmVxX2dvdl9kYnNfaW5pdCsweDAvMHgxMiBy
ZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM2NDAyNl0gY2FsbGluZyAgaW5pdF9sYWRk
ZXIrMHgwLzB4MTIgQCAxClsgICAgNC4zNjQxMjhdIGluaXRjYWxsIGluaXRfbGFkZGVyKzB4MC8w
eDEyIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgNC4zNjQyMzJdIGNhbGxpbmcgIGlu
aXRfbWVudSsweDAvMHgxMiBAIDEKWyAgICA0LjM2NDMzNF0gaW5pdGNhbGwgaW5pdF9tZW51KzB4
MC8weDEyIHJldHVybmVkIC0xOSBhZnRlciAwIHVzZWNzClsgICAgNC4zNjQ0MzZdIGNhbGxpbmcg
IGVmaXZhcnNfaW5pdCsweDAvMHhmNCBAIDEKWyAgICA0LjM2NDUzNl0gRUZJIFZhcmlhYmxlcyBG
YWNpbGl0eSB2MC4wOCAyMDA0LU1heS0xNwpbICAgIDQuMzY0NjM5XSBpbml0Y2FsbCBlZml2YXJz
X2luaXQrMHgwLzB4ZjQgcmV0dXJuZWQgMCBhZnRlciAxMDAgdXNlY3MKWyAgICA0LjM2NDc0NF0g
Y2FsbGluZyAgc3RhZ2luZ19pbml0KzB4MC8weDggQCAxClsgICAgNC4zNjQ4NDVdIGluaXRjYWxs
IHN0YWdpbmdfaW5pdCsweDAvMHg4IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY0
OTUxXSBjYWxsaW5nICBmbG93X2NhY2hlX2luaXRfZ2xvYmFsKzB4MC8weDJkIEAgMQpbICAgIDQu
MzY1MDc2XSBpbml0Y2FsbCBmbG93X2NhY2hlX2luaXRfZ2xvYmFsKzB4MC8weDJkIHJldHVybmVk
IDAgYWZ0ZXIgMjMgdXNlY3MKWyAgICA0LjM2NTIwMF0gY2FsbGluZyAgbGxjX2luaXQrMHgwLzB4
MjAgQCAxClsgICAgNC4zNjUzMDBdIGluaXRjYWxsIGxsY19pbml0KzB4MC8weDIwIHJldHVybmVk
IDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY1NDAzXSBjYWxsaW5nICBzbmFwX2luaXQrMHgwLzB4
MzkgQCAxClsgICAgNC4zNjU1MDRdIGluaXRjYWxsIHNuYXBfaW5pdCsweDAvMHgzOSByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM2NTYwNV0gY2FsbGluZyAgcmlmX2luaXQrMHgwLzB4
ODQgQCAxClsgICAgNC4zNjU3MTFdIGluaXRjYWxsIHJpZl9pbml0KzB4MC8weDg0IHJldHVybmVk
IDAgYWZ0ZXIgNSB1c2VjcwpbICAgIDQuMzY1ODE1XSBjYWxsaW5nICBibGFja2hvbGVfbW9kdWxl
X2luaXQrMHgwLzB4MTIgQCAxClsgICAgNC4zNjU5MTddIGluaXRjYWxsIGJsYWNraG9sZV9tb2R1
bGVfaW5pdCsweDAvMHgxMiByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM2NjAyM10g
Y2FsbGluZyAgc3lzY3RsX2lwdjRfaW5pdCsweDAvMHg4NCBAIDEKWyAgICA0LjM2NjI0N10gaW5p
dGNhbGwgc3lzY3RsX2lwdjRfaW5pdCsweDAvMHg4NCByZXR1cm5lZCAwIGFmdGVyIDExOCB1c2Vj
cwpbICAgIDQuMzY2MzUyXSBjYWxsaW5nICBpbml0X3N5bmNvb2tpZXMrMHgwLzB4MTkgQCAxClsg
ICAgNC4zNjY0NjZdIGluaXRjYWxsIGluaXRfc3luY29va2llcysweDAvMHgxOSByZXR1cm5lZCAw
IGFmdGVyIDExIHVzZWNzClsgICAgNC4zNjY1NzNdIGNhbGxpbmcgIGlwdjRfbmV0ZmlsdGVyX2lu
aXQrMHgwLzB4MjAgQCAxClsgICAgNC4zNjY2NzVdIGluaXRjYWxsIGlwdjRfbmV0ZmlsdGVyX2lu
aXQrMHgwLzB4MjAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNjY3ODBdIGNhbGxp
bmcgIGN1YmljdGNwX3JlZ2lzdGVyKzB4MC8weDZhIEAgMQpbICAgIDQuMzY2ODgyXSBUQ1AgY3Vi
aWMgcmVnaXN0ZXJlZApbICAgIDQuMzY2OTgxXSBpbml0Y2FsbCBjdWJpY3RjcF9yZWdpc3Rlcisw
eDAvMHg2YSByZXR1cm5lZCAwIGFmdGVyIDk2IHVzZWNzClsgICAgNC4zNjcwODZdIGNhbGxpbmcg
IGluZXQ2X2luaXQrMHgwLzB4NTcgQCAxClsgICAgNC4zNjcyNTldIE5FVDogUmVnaXN0ZXJlZCBw
cm90b2NvbCBmYW1pbHkgMTAKWyAgICA0LjM2NzcxN10gaW5pdGNhbGwgaW5ldDZfaW5pdCsweDAv
MHg1NyByZXR1cm5lZCAwIGFmdGVyIDUxOCB1c2VjcwpbICAgIDQuMzY3ODIyXSBjYWxsaW5nICBw
YWNrZXRfaW5pdCsweDAvMHg0NiBAIDEKWyAgICA0LjM2NzkyMV0gTkVUOiBSZWdpc3RlcmVkIHBy
b3RvY29sIGZhbWlseSAxNwpbICAgIDQuMzY4MDIzXSBpbml0Y2FsbCBwYWNrZXRfaW5pdCsweDAv
MHg0NiByZXR1cm5lZCAwIGFmdGVyIDk5IHVzZWNzClsgICAgNC4zNjgxMjddIGNhbGxpbmcgIGRz
YV9pbml0X21vZHVsZSsweDAvMHgxNCBAIDEKWyAgICA0LjM2ODIyOV0gaW5pdGNhbGwgZHNhX2lu
aXRfbW9kdWxlKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY4MzMx
XSBjYWxsaW5nICBlZHNhX2luaXRfbW9kdWxlKzB4MC8weDE0IEAgMQpbICAgIDQuMzY4NDMyXSBp
bml0Y2FsbCBlZHNhX2luaXRfbW9kdWxlKzB4MC8weDE0IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vj
cwpbICAgIDQuMzY4NTM1XSBjYWxsaW5nICB0cmFpbGVyX2luaXRfbW9kdWxlKzB4MC8weDE0IEAg
MQpbICAgIDQuMzY4NjM2XSBpbml0Y2FsbCB0cmFpbGVyX2luaXRfbW9kdWxlKzB4MC8weDE0IHJl
dHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzY4NzQxXSBjYWxsaW5nICBtdjg4ZTYwNjBf
aW5pdCsweDAvMHgxNCBAIDEKWyAgICA0LjM2ODg0M10gaW5pdGNhbGwgbXY4OGU2MDYwX2luaXQr
MHgwLzB4MTQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNjg5NDZdIGNhbGxpbmcg
IG12ODhlNjEyM182MV82NV9pbml0KzB4MC8weDE0IEAgMQpbICAgIDQuMzY5MDQ4XSBpbml0Y2Fs
bCBtdjg4ZTYxMjNfNjFfNjVfaW5pdCsweDAvMHgxNCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM2OTE1NF0gY2FsbGluZyAgbXY4OGU2MTMxX2luaXQrMHgwLzB4MTQgQCAxClsgICAg
NC4zNjkyNTVdIGluaXRjYWxsIG12ODhlNjEzMV9pbml0KzB4MC8weDE0IHJldHVybmVkIDAgYWZ0
ZXIgMCB1c2VjcwpbICAgIDQuMzY5MzU5XSBjYWxsaW5nICBkc2FfaW5pdF9tb2R1bGUrMHgwLzB4
MTIgQCAxClsgICAgNC4zNjk0NzVdIGluaXRjYWxsIGRzYV9pbml0X21vZHVsZSsweDAvMHgxMiBy
ZXR1cm5lZCAwIGFmdGVyIDEzIHVzZWNzClsgICAgNC4zNjk1NzldIGNhbGxpbmcgIGRjYm5sX2lu
aXQrMHgwLzB4NGQgQCAxClsgICAgNC4zNjk2ODBdIGluaXRjYWxsIGRjYm5sX2luaXQrMHgwLzB4
NGQgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNjk3ODRdIGNhbGxpbmcgIGluaXRf
ZG5zX3Jlc29sdmVyKzB4MC8weGZlIEAgMQpbICAgIDQuMzY5ODg0XSBSZWdpc3RlcmluZyB0aGUg
ZG5zX3Jlc29sdmVyIGtleSB0eXBlClsgICAgNC4zNjk5OTFdIGluaXRjYWxsIGluaXRfZG5zX3Jl
c29sdmVyKzB4MC8weGZlIHJldHVybmVkIDAgYWZ0ZXIgMTAzIHVzZWNzClsgICAgNC4zNzAwOTdd
IGNhbGxpbmcgIHJpb19pbml0X21wb3J0cysweDAvMHg1YyBAIDEKWyAgICA0LjM3MDIwMF0gaW5p
dGNhbGwgcmlvX2luaXRfbXBvcnRzKzB4MC8weDVjIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2Vjcwpb
ICAgIDQuMzcwMzA2XSBjYWxsaW5nICB0Ym9vdF9sYXRlX2luaXQrMHgwLzB4YzIgQCAxClsgICAg
NC4zNzA0MDhdIGluaXRjYWxsIHRib290X2xhdGVfaW5pdCsweDAvMHhjMiByZXR1cm5lZCAwIGFm
dGVyIDAgdXNlY3MKWyAgICA0LjM3MDUxM10gY2FsbGluZyAgbWNoZWNrX2RlYnVnZnNfaW5pdCsw
eDAvMHgzYiBAIDEKWyAgICA0LjM3MDYyMF0gaW5pdGNhbGwgbWNoZWNrX2RlYnVnZnNfaW5pdCsw
eDAvMHgzYiByZXR1cm5lZCAwIGFmdGVyIDMgdXNlY3MKWyAgICA0LjM3MDcyNV0gY2FsbGluZyAg
c2V2ZXJpdGllc19kZWJ1Z2ZzX2luaXQrMHgwLzB4M2IgQCAxClsgICAgNC4zNzA4MzJdIGluaXRj
YWxsIHNldmVyaXRpZXNfZGVidWdmc19pbml0KzB4MC8weDNiIHJldHVybmVkIDAgYWZ0ZXIgMyB1
c2VjcwpbICAgIDQuMzcwOTU1XSBjYWxsaW5nICBocGV0X2luc2VydF9yZXNvdXJjZSsweDAvMHgy
MyBAIDEKWyAgICA0LjM3MTA1OF0gaW5pdGNhbGwgaHBldF9pbnNlcnRfcmVzb3VyY2UrMHgwLzB4
MjMgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzExNjRdIGNhbGxpbmcgIHVwZGF0
ZV9tcF90YWJsZSsweDAvMHgxNiBAIDEKWyAgICA0LjM3MTI2NV0gaW5pdGNhbGwgdXBkYXRlX21w
X3RhYmxlKzB4MC8weDE2IHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzcxMzcwXSBj
YWxsaW5nICBsYXBpY19pbnNlcnRfcmVzb3VyY2UrMHgwLzB4M2YgQCAxClsgICAgNC4zNzE0NzJd
IGluaXRjYWxsIGxhcGljX2luc2VydF9yZXNvdXJjZSsweDAvMHgzZiByZXR1cm5lZCAtMSBhZnRl
ciAwIHVzZWNzClsgICAgNC4zNzE1NzhdIGluaXRjYWxsIGxhcGljX2luc2VydF9yZXNvdXJjZSsw
eDAvMHgzZiByZXR1cm5lZCB3aXRoIGVycm9yIGNvZGUgLTEgClsgICAgNC4zNzE3MDFdIGNhbGxp
bmcgIGlvX2FwaWNfYnVnX2ZpbmFsaXplKzB4MC8weDFiIEAgMQpbICAgIDQuMzcxODAyXSBpbml0
Y2FsbCBpb19hcGljX2J1Z19maW5hbGl6ZSsweDAvMHgxYiByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA0LjM3MTkwN10gY2FsbGluZyAgcHJpbnRfSUNzKzB4MC8weDk0IEAgMQpbICAgIDQu
MzcyMDA5XSBpbml0Y2FsbCBwcmludF9JQ3MrMHgwLzB4OTQgcmV0dXJuZWQgMCBhZnRlciAwIHVz
ZWNzClsgICAgNC4zNzIxMTRdIGNhbGxpbmcgIGNoZWNrX2Vhcmx5X2lvcmVtYXBfbGVhaysweDAv
MHg1MCBAIDEKWyAgICA0LjM3MjIxN10gaW5pdGNhbGwgY2hlY2tfZWFybHlfaW9yZW1hcF9sZWFr
KzB4MC8weDUwIHJldHVybmVkIDAgYWZ0ZXIgMCB1c2VjcwpbICAgIDQuMzcyMzQxXSBjYWxsaW5n
ICBwYXRfbWVtdHlwZV9saXN0X2luaXQrMHgwLzB4MzIgQCAxClsgICAgNC4zNzI0NDZdIGluaXRj
YWxsIHBhdF9tZW10eXBlX2xpc3RfaW5pdCsweDAvMHgzMiByZXR1cm5lZCAwIGFmdGVyIDEgdXNl
Y3MKWyAgICA0LjM3MjU1Ml0gY2FsbGluZyAgc2NoZWRfaW5pdF9kZWJ1ZysweDAvMHgyNCBAIDEK
WyAgICA0LjM3MjY1NF0gaW5pdGNhbGwgc2NoZWRfaW5pdF9kZWJ1ZysweDAvMHgyNCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM3Mjc2MF0gY2FsbGluZyAgaW5pdF9vb3BzX2lkKzB4
MC8weDQwIEAgMQpbICAgIDQuMzcyODYwXSBpbml0Y2FsbCBpbml0X29vcHNfaWQrMHgwLzB4NDAg
cmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4zNzI5NjVdIGNhbGxpbmcgIHByaW50a19s
YXRlX2luaXQrMHgwLzB4NTYgQCAxClsgICAgNC4zNzMwNjldIGluaXRjYWxsIHByaW50a19sYXRl
X2luaXQrMHgwLzB4NTYgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzMxNzVdIGNh
bGxpbmcgIHBtX2RlYnVnZnNfaW5pdCsweDAvMHgyNCBAIDEKWyAgICA0LjM3MzI3OF0gaW5pdGNh
bGwgcG1fZGVidWdmc19pbml0KzB4MC8weDI0IHJldHVybmVkIDAgYWZ0ZXIgMSB1c2VjcwpbICAg
IDQuMzczMzgyXSBjYWxsaW5nICBwbV9xb3NfcG93ZXJfaW5pdCsweDAvMHhkYyBAIDEKWyAgICA0
LjM3MzU4MF0gaW5pdGNhbGwgcG1fcW9zX3Bvd2VyX2luaXQrMHgwLzB4ZGMgcmV0dXJuZWQgMCBh
ZnRlciA5NCB1c2VjcwpbICAgIDQuMzczNjg1XSBjYWxsaW5nICB0ZXN0X3N1c3BlbmQrMHgwLzB4
YTEgQCAxClsgICAgNC4zNzM3ODZdIGluaXRjYWxsIHRlc3Rfc3VzcGVuZCsweDAvMHhhMSByZXR1
cm5lZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM3Mzg5MF0gY2FsbGluZyAgc29mdHdhcmVfcmVz
dW1lKzB4MC8weDMwIEAgMQpbICAgIDQuMzczOTkxXSBQTTogSGliZXJuYXRpb24gaW1hZ2Ugbm90
IHByZXNlbnQgb3IgY291bGQgbm90IGJlIGxvYWRlZC4KWyAgICA0LjM3NDA5Nl0gaW5pdGNhbGwg
c29mdHdhcmVfcmVzdW1lKzB4MC8weDMwIHJldHVybmVkIC0yIGFmdGVyIDEwMSB1c2VjcwpbICAg
IDQuMzc0MjAxXSBpbml0Y2FsbCBzb2Z0d2FyZV9yZXN1bWUrMHgwLzB4MzAgcmV0dXJuZWQgd2l0
aCBlcnJvciBjb2RlIC0yIApbICAgIDQuMzc0MzA4XSBjYWxsaW5nICBkZWJ1Z2ZzX2twcm9iZV9p
bml0KzB4MC8weGEwIEAgMQpbICAgIDQuMzc0NDE0XSBpbml0Y2FsbCBkZWJ1Z2ZzX2twcm9iZV9p
bml0KzB4MC8weGEwIHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMzc0NTIxXSBjYWxs
aW5nICB0YXNrc3RhdHNfaW5pdCsweDAvMHg5NSBAIDEKWyAgICA0LjM3NDYyNV0gcmVnaXN0ZXJl
ZCB0YXNrc3RhdHMgdmVyc2lvbiAxClsgICAgNC4zNzQ3MjhdIGluaXRjYWxsIHRhc2tzdGF0c19p
bml0KzB4MC8weDk1IHJldHVybmVkIDAgYWZ0ZXIgMTAxIHVzZWNzClsgICAgNC4zNzQ4MzRdIGNh
bGxpbmcgIGNsZWFyX2Jvb3RfdHJhY2VyKzB4MC8weDJkIEAgMQpbICAgIDQuMzc0OTM2XSBpbml0
Y2FsbCBjbGVhcl9ib290X3RyYWNlcisweDAvMHgyZCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM3NTA0MV0gY2FsbGluZyAga2RiX2Z0cmFjZV9yZWdpc3RlcisweDAvMHgyZiBAIDEK
WyAgICA0LjM3NTE0Nl0gaW5pdGNhbGwga2RiX2Z0cmFjZV9yZWdpc3RlcisweDAvMHgyZiByZXR1
cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjM3NTI1Ml0gY2FsbGluZyAgbWF4X3N3YXBmaWxl
c19jaGVjaysweDAvMHg4IEAgMQpbICAgIDQuMzc1MzU0XSBpbml0Y2FsbCBtYXhfc3dhcGZpbGVz
X2NoZWNrKzB4MC8weDggcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzU0NjBdIGNh
bGxpbmcgIHNldF9yZWNvbW1lbmRlZF9taW5fZnJlZV9rYnl0ZXMrMHgwLzB4YTAgQCAxClsgICAg
NC4zNzU1NjNdIGluaXRjYWxsIHNldF9yZWNvbW1lbmRlZF9taW5fZnJlZV9rYnl0ZXMrMHgwLzB4
YTAgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zNzU2ODhdIGNhbGxpbmcgIGluaXRf
dHJ1c3RlZCsweDAvMHhiYiBAIDEKWyAgICA0LjM3NTc5MV0gYXN5bmNfd2FpdGluZyBAIDEKWyAg
ICA0LjM3NTg4OF0gYXN5bmNfY29udGludWluZyBAIDEgYWZ0ZXIgMCB1c2VjClsgICAgNC4zNzcz
MjldIGFzeW5jX3dhaXRpbmcgQCAxClsgICAgNC4zNzc0MzBdIGFzeW5jX2NvbnRpbnVpbmcgQCAx
IGFmdGVyIDAgdXNlYwpbICAgIDQuMzc4NzQ0XSBpbml0Y2FsbCBpbml0X3RydXN0ZWQrMHgwLzB4
YmIgcmV0dXJuZWQgMCBhZnRlciAyODgxIHVzZWNzClsgICAgNC4zNzg4NDldIGNhbGxpbmcgIGlu
aXRfZW5jcnlwdGVkKzB4MC8weDExZiBAIDEKWyAgICA0LjM3ODk1MV0gYXN5bmNfd2FpdGluZyBA
IDEKWyAgICA0LjM3OTA0OV0gYXN5bmNfY29udGludWluZyBAIDEgYWZ0ZXIgMCB1c2VjClsgICAg
NC4zODAzMjhdIGFzeW5jX3dhaXRpbmcgQCAxClsgICAgNC4zODA0MjldIGFzeW5jX2NvbnRpbnVp
bmcgQCAxIGFmdGVyIDAgdXNlYwpbICAgIDQuMzgxNzUwXSBhc3luY193YWl0aW5nIEAgMQpbICAg
IDQuMzgxODQ5XSBhc3luY19jb250aW51aW5nIEAgMSBhZnRlciAwIHVzZWMKWyAgICA0LjM4MzEw
NF0gYXN5bmNfd2FpdGluZyBAIDEKWyAgICA0LjM4MzIwM10gYXN5bmNfY29udGludWluZyBAIDEg
YWZ0ZXIgMCB1c2VjClsgICAgNC4zODQ1MzVdIGluaXRjYWxsIGluaXRfZW5jcnlwdGVkKzB4MC8w
eDExZiByZXR1cm5lZCAwIGFmdGVyIDU0NTEgdXNlY3MKWyAgICA0LjM4NDY0Ml0gY2FsbGluZyAg
aW5pdF9ldm0rMHgwLzB4MjUgQCAxClsgICAgNC4zODQ3NDhdIGluaXRjYWxsIGluaXRfZXZtKzB4
MC8weDI1IHJldHVybmVkIDAgYWZ0ZXIgMyB1c2VjcwpbICAgIDQuMzg0ODUyXSBjYWxsaW5nICBy
YW5kb20zMl9yZXNlZWQrMHgwLzB4YTIgQCAxClsgICAgNC4zODQ5NTVdIGluaXRjYWxsIHJhbmRv
bTMyX3Jlc2VlZCsweDAvMHhhMiByZXR1cm5lZCAwIGFmdGVyIDQgdXNlY3MKWyAgICA0LjM4NTA2
MF0gY2FsbGluZyAgcGNpX3Jlc291cmNlX2FsaWdubWVudF9zeXNmc19pbml0KzB4MC8weDE5IEAg
MQpbICAgIDQuMzg2ODYzXSBpbml0Y2FsbCBwY2lfcmVzb3VyY2VfYWxpZ25tZW50X3N5c2ZzX2lu
aXQrMHgwLzB4MTkgcmV0dXJuZWQgMCBhZnRlciAxIHVzZWNzClsgICAgNC4zODY5ODldIGNhbGxp
bmcgIHBjaV9zeXNmc19pbml0KzB4MC8weDUxIEAgMQpbICAgIDQuMzg3NjUzXSBpbml0Y2FsbCBw
Y2lfc3lzZnNfaW5pdCsweDAvMHg1MSByZXR1cm5lZCAwIGFmdGVyIDU0OCB1c2VjcwpbICAgIDQu
Mzg3NzU1XSBjYWxsaW5nICBib290X3dhaXRfZm9yX2RldmljZXMrMHgwLzB4MzAgQCAxClsgICAg
NC4zODc4NThdIGluaXRjYWxsIGJvb3Rfd2FpdF9mb3JfZGV2aWNlcysweDAvMHgzMCByZXR1cm5l
ZCAwIGFmdGVyIDAgdXNlY3MKWyAgICA0LjM4Nzk2M10gY2FsbGluZyAgcmVndWxhdG9yX2luaXRf
Y29tcGxldGUrMHgwLzB4MTM5IEAgMQpbICAgIDQuMzg4MDY3XSBpbml0Y2FsbCByZWd1bGF0b3Jf
aW5pdF9jb21wbGV0ZSsweDAvMHgxMzkgcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4z
ODgxOTJdIGNhbGxpbmcgIHJhbmRvbV9pbnRfc2VjcmV0X2luaXQrMHgwLzB4MTkgQCAxClsgICAg
NC4zODgzMDFdIGluaXRjYWxsIHJhbmRvbV9pbnRfc2VjcmV0X2luaXQrMHgwLzB4MTkgcmV0dXJu
ZWQgMCBhZnRlciA2IHVzZWNzClsgICAgNC4zODg0MDZdIGNhbGxpbmcgIGxhdGVfcmVzdW1lX2lu
aXQrMHgwLzB4MWIwIEAgMQpbICAgIDQuMzg4NTA1XSAgIE1hZ2ljIG51bWJlcjogODo2NDg6NDkz
ClsgICAgNC4zODg2MjVdIGluaXRjYWxsIGxhdGVfcmVzdW1lX2luaXQrMHgwLzB4MWIwIHJldHVy
bmVkIDAgYWZ0ZXIgMTE2IHVzZWNzClsgICAgNC4zODg3MjhdIGNhbGxpbmcgIHNjc2lfY29tcGxl
dGVfYXN5bmNfc2NhbnMrMHgwLzB4MTYwIEAgMQpbICAgIDQuMzg4ODI3XSBpbml0Y2FsbCBzY3Np
X2NvbXBsZXRlX2FzeW5jX3NjYW5zKzB4MC8weDE2MCByZXR1cm5lZCAwIGFmdGVyIDAgdXNlY3MK
WyAgICA0LjM4ODk0OV0gY2FsbGluZyAgcnRjX2hjdG9zeXMrMHgwLzB4MTBmIEAgMQpbICAgIDQu
Mzg5MTEyXSBydGNfY21vcyAwMDowMzogc2V0dGluZyBzeXN0ZW0gY2xvY2sgdG8gMjAxMi0wNC0x
MSAxODoyOToyNCBVVEMgKDEzMzQxNjg5NjQpClsgICAgNC4zODkyMzddIGluaXRjYWxsIHJ0Y19o
Y3Rvc3lzKzB4MC8weDEwZiByZXR1cm5lZCAwIGFmdGVyIDE4NiB1c2VjcwpbICAgIDQuMzg5MzQw
XSBjYWxsaW5nICBwb3dlcm5vd2s4X2luaXQrMHgwLzB4MWJmIEAgMQpbICAgIDQuMzg5NDQ3XSBp
bml0Y2FsbCBwb3dlcm5vd2s4X2luaXQrMHgwLzB4MWJmIHJldHVybmVkIC0xOSBhZnRlciA1IHVz
ZWNzClsgICAgNC4zODk1NDddIGNhbGxpbmcgIGFjcGlfY3B1ZnJlcV9pbml0KzB4MC8weDE2IEAg
MQpbICAgIDQuMzg5ODE4XSBpbml0Y2FsbCBhY3BpX2NwdWZyZXFfaW5pdCsweDAvMHgxNiByZXR1
cm5lZCAwIGFmdGVyIDE2NiB1c2VjcwpbICAgIDQuMzg5OTIyXSBjYWxsaW5nICBjZW50cmlub19p
bml0KzB4MC8weDJlIEAgMQpbICAgIDQuMzkwMDE5XSBpbml0Y2FsbCBjZW50cmlub19pbml0KzB4
MC8weDJlIHJldHVybmVkIC0xNiBhZnRlciAwIHVzZWNzClsgICAgNC4zOTAxMjJdIGluaXRjYWxs
IGNlbnRyaW5vX2luaXQrMHgwLzB4MmUgcmV0dXJuZWQgd2l0aCBlcnJvciBjb2RlIC0xNiAKWyAg
ICA0LjM5MDIyN10gY2FsbGluZyAgZWRkX2luaXQrMHgwLzB4MWEzIEAgMQpbICAgIDQuMzkwMzI0
XSBCSU9TIEVERCBmYWNpbGl0eSB2MC4xNiAyMDA0LUp1bi0yNSwgMCBkZXZpY2VzIGZvdW5kClsg
ICAgNC4zOTA0MjddIEVERCBpbmZvcm1hdGlvbiBub3QgYXZhaWxhYmxlLgpbICAgIDQuMzkwNTIy
XSBpbml0Y2FsbCBlZGRfaW5pdCsweDAvMHgxYTMgcmV0dXJuZWQgLTE5IGFmdGVyIDE5MiB1c2Vj
cwpbICAgIDQuMzkwNjI2XSBjYWxsaW5nICBtZW1tYXBfaW5pdCsweDAvMHgzNSBAIDEKWyAgICA0
LjM5MDc1OV0gaW5pdGNhbGwgbWVtbWFwX2luaXQrMHgwLzB4MzUgcmV0dXJuZWQgMCBhZnRlciAz
NSB1c2VjcwpbICAgIDQuMzkwODYyXSBjYWxsaW5nICBkZXZmcmVxX3N0YXJ0X3BvbGxpbmcrMHgw
LzB4OTAgQCAxClsgICAgNC4zOTA5OTBdIGluaXRjYWxsIGRldmZyZXFfc3RhcnRfcG9sbGluZysw
eDAvMHg5MCByZXR1cm5lZCAwIGFmdGVyIDIzIHVzZWNzClsgICAgNC4zOTEwOThdIGNhbGxpbmcg
IHBjaV9tbWNmZ19sYXRlX2luc2VydF9yZXNvdXJjZXMrMHgwLzB4NTkgQCAxClsgICAgNC4zOTEy
MDJdIGluaXRjYWxsIHBjaV9tbWNmZ19sYXRlX2luc2VydF9yZXNvdXJjZXMrMHgwLzB4NTkgcmV0
dXJuZWQgMCBhZnRlciAwIHVzZWNzClsgICAgNC4zOTEzMjZdIGNhbGxpbmcgIG5ldF9zZWNyZXRf
aW5pdCsweDAvMHgxOSBAIDEKWyAgICA0LjM5MTQzM10gaW5pdGNhbGwgbmV0X3NlY3JldF9pbml0
KzB4MC8weDE5IHJldHVybmVkIDAgYWZ0ZXIgNiB1c2VjcwpbICAgIDQuMzkxNTM1XSBjYWxsaW5n
ICB0Y3BfY29uZ2VzdGlvbl9kZWZhdWx0KzB4MC8weDEyIEAgMQpbICAgIDQuMzkxNjM4XSBpbml0
Y2FsbCB0Y3BfY29uZ2VzdGlvbl9kZWZhdWx0KzB4MC8weDEyIHJldHVybmVkIDAgYWZ0ZXIgMCB1
c2VjcwpbICAgIDQuMzkxNzQxXSBjYWxsaW5nICBpbml0aWFsaXplX2hhc2hybmQrMHgwLzB4MTkg
QCAxClsgICAgNC4zOTE4NDNdIGluaXRjYWxsIGluaXRpYWxpemVfaGFzaHJuZCsweDAvMHgxOSBy
ZXR1cm5lZCAwIGFmdGVyIDEgdXNlY3MKWyAgICA0LjM5MTk2Nl0gYXN5bmNfd2FpdGluZyBAIDEK
WyAgICA0LjM5MjA2M10gYXN5bmNfY29udGludWluZyBAIDEgYWZ0ZXIgMCB1c2VjClsgICAgNC4z
OTIxNjddIGFzeW5jX3dhaXRpbmcgQCAxClsgICAgNC42MzcxNjddIGF0YTY6IFNBVEEgbGluayB1
cCAxLjUgR2JwcyAoU1N0YXR1cyAxMTMgU0NvbnRyb2wgMzAwKQpbICAgIDQuNjM3MzE0XSBhdGE0
OiBTQVRBIGxpbmsgdXAgMy4wIEdicHMgKFNTdGF0dXMgMTIzIFNDb250cm9sIDMwMCkKWyAgICA0
LjYzNzgwN10gYXRhNi4wMDogQVRBUEk6IFRTU1Rjb3JwIENERFZEVyBTSC1TMjIzRiwgU0IwMCwg
bWF4IFVETUEvMTAwClsgICAgNC42Mzg2MzJdIGF0YTYuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEv
MTAwClsgICAgNC42MzkwMjRdIGFzeW5jX3dhaXRpbmcgQCA1MgpbICAgIDQuNjM5MTE3XSBhdGE0
LjAwOiBBVEEtODogU1QzMTAwMDM0MEFTLCBTRDFBLCBtYXggVURNQS8xMzMKWyAgICA0LjYzOTEx
OF0gYXRhNC4wMDogMTk1MzUyNTE2OCBzZWN0b3JzLCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0
aCAzMS8zMikKWyAgICA0LjY0MTE1NF0gYXRhMzogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3Rh
dHVzIDEyMyBTQ29udHJvbCAzMDApClsgICAgNC42NDEzMDJdIGF0YTQuMDA6IGNvbmZpZ3VyZWQg
Zm9yIFVETUEvMTMzClsgICAgNC42NDE0MDldIGFzeW5jX3dhaXRpbmcgQCA1MApbICAgIDQuNjQy
MzIyXSBhdGEzLjAwOiBBVEEtODogU1QzMTAwMDUyOEFTLCBDQzM3LCBtYXggVURNQS8xMzMKWyAg
ICA0LjY0MjQ1Ml0gYXRhMy4wMDogMTk1MzUyNTE2OCBzZWN0b3JzLCBtdWx0aSAxNjogTEJBNDgg
TkNRIChkZXB0aCAzMS8zMikKWyAgICA0LjY0Mzc0NF0gYXRhMy4wMDogY29uZmlndXJlZCBmb3Ig
VURNQS8xMzMKWyAgICA0LjY0Mzg3OV0gYXN5bmNfd2FpdGluZyBAIDQ5ClsgICAgNC42NDUxNTVd
IHVzYiAxLTE6IG5ldyBoaWdoLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcgZWhjaV9o
Y2QKWyAgICA0LjY0NTE2Ml0gYXRhMjogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEy
MyBTQ29udHJvbCAzMDApClsgICAgNC42NDY2MjRdIGF0YTIuMDA6IEFUQS04OiBTVDM1MDAzMjBB
UywgU0QxQSwgbWF4IFVETUEvMTMzClsgICAgNC42NDY3MzZdIGF0YTIuMDA6IDk3Njc3MzE2OCBz
ZWN0b3JzLCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0aCAzMS8zMikKWyAgICA0LjY0ODY0MV0g
YXRhMi4wMDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMKWyAgICA0LjY0ODc1OV0gYXN5bmNfd2Fp
dGluZyBAIDE2ClsgICAgNC42NDkxNTNdIGF0YTE6IFNBVEEgbGluayB1cCAzLjAgR2JwcyAoU1N0
YXR1cyAxMjMgU0NvbnRyb2wgMzAwKQpbICAgIDQuNjUwMzQ0XSBhdGExLjAwOiBBVEEtODogU1Qz
NTAwNDE4QVMsIENDNDYsIG1heCBVRE1BLzEzMwpbICAgIDQuNjUwNDU4XSBhdGExLjAwOiA5NzY3
NzMxNjggc2VjdG9ycywgbXVsdGkgMTY6IExCQTQ4IE5DUSAoZGVwdGggMzEvMzIpClsgICAgNC42
NTE3ODZdIGF0YTEuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzClsgICAgNC42NTE5MDRdIGFz
eW5jX3dhaXRpbmcgQCA1ClsgICAgNC42NTE5ODddIGFzeW5jX2NvbnRpbnVpbmcgQCA1IGFmdGVy
IDAgdXNlYwpbICAgIDQuNjUyMTUxXSBzY3NpIDA6MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIEFU
QSAgICAgIFNUMzUwMDQxOEFTICAgICAgQ0M0NiBQUTogMCBBTlNJOiA1ClsgICAgNC42NTIzMjBd
IGNhbGxpbmcgIDhfc2RfcHJvYmVfYXN5bmMrMHgwLzB4MWQwIEAgNTMKWyAgICA0LjY1MjM0OV0g
c2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0eXBlIDAKWyAgICA0LjY1MjM4
NF0gaW5pdGNhbGwgMl9hc3luY19wb3J0X3Byb2JlKzB4MC8weDcwIHJldHVybmVkIDAgYWZ0ZXIg
MzI0NDE3IHVzZWNzClsgICAgNC42NTIzOTJdIGFzeW5jX2NvbnRpbnVpbmcgQCAxNiBhZnRlciAz
NDY4IHVzZWMKWyAgICA0LjY1MjQzOF0gc2NzaSAxOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBB
VEEgICAgICBTVDM1MDAzMjBBUyAgICAgIFNEMUEgUFE6IDAgQU5TSTogNQpbICAgIDQuNjUyNTEz
XSBzZCAxOjA6MDowOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2cxIHR5cGUgMApbICAgIDQuNjUy
NTM4XSBpbml0Y2FsbCAzX2FzeW5jX3BvcnRfcHJvYmUrMHgwLzB4NzAgcmV0dXJuZWQgMCBhZnRl
ciAzMjQ0NzYgdXNlY3MKWyAgICA0LjY1MjU0Ml0gY2FsbGluZyAgOV9zZF9wcm9iZV9hc3luYysw
eDAvMHgxZDAgQCAxNgpbICAgIDQuNjUyNTUwXSBhc3luY19jb250aW51aW5nIEAgNDkgYWZ0ZXIg
ODM3MCB1c2VjClsgICAgNC42NTI1OTldIHNkIDE6MDowOjA6IFtzZGJdIDk3Njc3MzE2OCA1MTIt
Ynl0ZSBsb2dpY2FsIGJsb2NrczogKDUwMCBHQi80NjUgR2lCKQpbICAgIDQuNjUyNjEwXSBzY3Np
IDI6MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIEFUQSAgICAgIFNUMzEwMDA1MjhBUyAgICAgQ0Mz
NyBQUTogMCBBTlNJOiA1ClsgICAgNC42NTI2ODNdIHNkIDI6MDowOjA6IEF0dGFjaGVkIHNjc2kg
Z2VuZXJpYyBzZzIgdHlwZSAwClsgICAgNC42NTI3MDhdIGluaXRjYWxsIDRfYXN5bmNfcG9ydF9w
cm9iZSsweDAvMHg3MCByZXR1cm5lZCAwIGFmdGVyIDMyNDU0NSB1c2VjcwpbICAgIDQuNjUyNzEx
XSBjYWxsaW5nICAxMF9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgQCA0OQpbICAgIDQuNjUyNzQ4
XSBzZCAyOjA6MDowOiBbc2RjXSAxOTUzNTI1MTY4IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAo
MS4wMCBUQi85MzEgR2lCKQpbICAgIDQuNjUyNzkxXSBzZCAxOjA6MDowOiBbc2RiXSBXcml0ZSBQ
cm90ZWN0IGlzIG9mZgpbICAgIDQuNjUyNzkzXSBzZCAxOjA6MDowOiBbc2RiXSBNb2RlIFNlbnNl
OiAwMCAzYSAwMCAwMApbICAgIDQuNjUyODI2XSBzZCAxOjA6MDowOiBbc2RiXSBXcml0ZSBjYWNo
ZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBG
VUEKWyAgICA0LjY1Mjg1NF0gc2QgMjowOjA6MDogW3NkY10gV3JpdGUgUHJvdGVjdCBpcyBvZmYK
WyAgICA0LjY1Mjg1Nl0gc2QgMjowOjA6MDogW3NkY10gTW9kZSBTZW5zZTogMDAgM2EgMDAgMDAK
WyAgICA0LjY1MjkxM10gc2QgMjowOjA6MDogW3NkY10gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJl
YWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qgc3VwcG9ydCBEUE8gb3IgRlVBClsgICAgNC42NTQy
ODNdIGFzeW5jX2NvbnRpbnVpbmcgQCA1MCBhZnRlciAxMjQ3NiB1c2VjClsgICAgNC42NTQzMDBd
IHNkIDA6MDowOjA6IFtzZGFdIDk3Njc3MzE2OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDUw
MCBHQi80NjUgR2lCKQpbICAgIDQuNjU0MzQ0XSBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBQcm90
ZWN0IGlzIG9mZgpbICAgIDQuNjU0MzQ2XSBzZCAwOjA6MDowOiBbc2RhXSBNb2RlIFNlbnNlOiAw
MCAzYSAwMCAwMApbICAgIDQuNjU0MzY1XSBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBjYWNoZTog
ZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUEK
WyAgICA0LjY1NDc5OV0gc2NzaSAzOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBBVEEgICAgICBT
VDMxMDAwMzQwQVMgICAgIFNEMUEgUFE6IDAgQU5TSTogNQpbICAgIDQuNjU0OTYxXSBjYWxsaW5n
ICAxMV9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgQCA1ClsgICAgNC42NTUwOTBdIHNkIDM6MDow
OjA6IFtzZGRdIDE5NTM1MjUxNjggNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICgxLjAwIFRCLzkz
MSBHaUIpClsgICAgNC42NTUwOThdIHNkIDM6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBz
ZzMgdHlwZSAwClsgICAgNC42NTUzMTBdIGluaXRjYWxsIDVfYXN5bmNfcG9ydF9wcm9iZSsweDAv
MHg3MCByZXR1cm5lZCAwIGFmdGVyIDMyNzAwMiB1c2VjcwpbICAgIDQuNjU1MzM0XSBzZCAzOjA6
MDowOiBbc2RkXSBXcml0ZSBQcm90ZWN0IGlzIG9mZgpbICAgIDQuNjU1MzM1XSBzZCAzOjA6MDow
OiBbc2RkXSBNb2RlIFNlbnNlOiAwMCAzYSAwMCAwMApbICAgIDQuNjU1MzU0XSBzZCAzOjA6MDow
OiBbc2RkXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24n
dCBzdXBwb3J0IERQTyBvciBGVUEKWyAgICA0LjY1ODI2OV0gIHNkYTogc2RhMQpbICAgIDQuNjU4
NTQ2XSBzZCAwOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAgICA0LjY1ODY0MV0g
aW5pdGNhbGwgOF9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgcmV0dXJuZWQgMCBhZnRlciA0Mjcy
IHVzZWNzClsgICAgNC42NjIwMzFdICBzZGM6IHNkYzEKWyAgICA0LjY2MjM0Nl0gc2QgMjowOjA6
MDogW3NkY10gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAgNC42NjI0NDBdIGluaXRjYWxsIDEwX3Nk
X3Byb2JlX2FzeW5jKzB4MC8weDFkMCByZXR1cm5lZCAwIGFmdGVyIDk0OTggdXNlY3MKWyAgICA0
LjY2NTE2NV0gIHNkYjogc2RiMQpbICAgIDQuNjY1NDc0XSBzZCAxOjA6MDowOiBbc2RiXSBBdHRh
Y2hlZCBTQ1NJIGRpc2sKWyAgICA0LjY2NTU2Nl0gaW5pdGNhbGwgOV9zZF9wcm9iZV9hc3luYysw
eDAvMHgxZDAgcmV0dXJuZWQgMCBhZnRlciAxMjcxNiB1c2VjcwpbICAgIDQuNjc0OTI3XSAgc2Rk
OiBzZGQxClsgICAgNC42NzUyNDRdIHNkIDM6MDowOjA6IFtzZGRdIEF0dGFjaGVkIFNDU0kgZGlz
awpbICAgIDQuNjc1MzM3XSBpbml0Y2FsbCAxMV9zZF9wcm9iZV9hc3luYysweDAvMHgxZDAgcmV0
dXJuZWQgMCBhZnRlciAxOTgwOSB1c2VjcwpbICAgIDQuNzc3ODQzXSBodWIgMS0xOjEuMDogVVNC
IGh1YiBmb3VuZApbICAgIDQuNzc4MDU2XSBodWIgMS0xOjEuMDogNiBwb3J0cyBkZXRlY3RlZApb
ICAgIDQuODg5MTU3XSB1c2IgMi0xOiBuZXcgaGlnaC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAy
IHVzaW5nIGVoY2lfaGNkClsgICAgNS4wMjE4MzJdIGh1YiAyLTE6MS4wOiBVU0IgaHViIGZvdW5k
ClsgICAgNS4wMjIwNDZdIGh1YiAyLTE6MS4wOiA2IHBvcnRzIGRldGVjdGVkClsgICAgNS4wODUx
NTRdIGF0YTU6IFNBVEEgbGluayB1cCAzLjAgR2JwcyAoU1N0YXR1cyAxMjMgU0NvbnRyb2wgMzAw
KQpbICAgIDUuMDkzMjk1XSB1c2IgMS0xLjI6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVt
YmVyIDMgdXNpbmcgZWhjaV9oY2QKWyAgICA1LjEwNTQyMl0gYXRhNS4wMDogSFBBIGRldGVjdGVk
OiBjdXJyZW50IDk3Njc3MTA1NSwgbmF0aXZlIDk3Njc3MzE2OApbICAgIDUuMTA1NjQ2XSBhdGE1
LjAwOiBBVEEtODogV0RDIFdENTAwMEFBS1MtMjJZR0EwLCAxMi4wMUMwMiwgbWF4IFVETUEvMTMz
ClsgICAgNS4xMDU3NTldIGF0YTUuMDA6IDk3Njc3MTA1NSBzZWN0b3JzLCBtdWx0aSAxNjogTEJB
NDggTkNRIChkZXB0aCAzMS8zMiksIEFBClsgICAgNS4xMDY4MjhdIGF0YTUuMDA6IGNvbmZpZ3Vy
ZWQgZm9yIFVETUEvMTMzClsgICAgNS4xMDY5NDZdIGFzeW5jX3dhaXRpbmcgQCA1MQpbICAgIDUu
MTA3MDI2XSBhc3luY19jb250aW51aW5nIEAgNTEgYWZ0ZXIgMCB1c2VjClsgICAgNS4xMDcxNjNd
IHNjc2kgNDowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgV0RDIFdENTAwMEFBS1Mt
MiAxMi4wIFBROiAwIEFOU0k6IDUKWyAgICA1LjEwNzMyNl0gY2FsbGluZyAgMTJfc2RfcHJvYmVf
YXN5bmMrMHgwLzB4MWQwIEAgNQpbICAgIDUuMTA3MzU0XSBzZCA0OjA6MDowOiBBdHRhY2hlZCBz
Y3NpIGdlbmVyaWMgc2c0IHR5cGUgMApbICAgIDUuMTA3Mzc4XSBpbml0Y2FsbCA2X2FzeW5jX3Bv
cnRfcHJvYmUrMHgwLzB4NzAgcmV0dXJuZWQgMCBhZnRlciA3NjgzODAgdXNlY3MKWyAgICA1LjEw
NzM4NF0gYXN5bmNfY29udGludWluZyBAIDUyIGFmdGVyIDQ1NzA3NyB1c2VjClsgICAgNS4xMDc3
MjFdIHNkIDQ6MDowOjA6IFtzZGVdIDk3Njc3MTA1NSA1MTItYnl0ZSBsb2dpY2FsIGJsb2Nrczog
KDUwMCBHQi80NjUgR2lCKQpbICAgIDUuMTA3OTAzXSBzY3NpIDU6MDowOjA6IENELVJPTSAgICAg
ICAgICAgIFRTU1Rjb3JwIENERFZEVyBTSC1TMjIzRiAgU0IwMCBQUTogMCBBTlNJOiA1ClsgICAg
NS4xMDc5MTRdIHNkIDQ6MDowOjA6IFtzZGVdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAgNS4x
MDc5MTVdIHNkIDQ6MDowOjA6IFtzZGVdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAgNS4x
MDc5MzZdIHNkIDQ6MDowOjA6IFtzZGVdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hl
OiBlbmFibGVkLCBkb2Vzbid0IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgIDUuMTEwNDg1XSBzcjA6
IHNjc2kzLW1tYyBkcml2ZTogNDh4LzQ4eCB3cml0ZXIgZHZkLXJhbSBjZC9ydyB4YS9mb3JtMiBj
ZGRhIHRyYXkKWyAgICA1LjExMDYxN10gY2Ryb206IFVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZp
c2lvbjogMy4yMApbICAgIDUuMTEwNzc2XSBzciA1OjA6MDowOiBBdHRhY2hlZCBzY3NpIENELVJP
TSBzcjAKWyAgICA1LjExMDkwNF0gc3IgNTowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNn
NSB0eXBlIDUKWyAgICA1LjExMTAyNF0gaW5pdGNhbGwgN19hc3luY19wb3J0X3Byb2JlKzB4MC8w
eDcwIHJldHVybmVkIDAgYWZ0ZXIgNzcxODQ4IHVzZWNzClsgICAgNS4xMTExNDNdIGFzeW5jX2Nv
bnRpbnVpbmcgQCAxIGFmdGVyIDcwMjAzMSB1c2VjClsgICAgNS4xMTEyMzBdIGFzeW5jX3dhaXRp
bmcgQCAxClsgICAgNS4xMTg3MjddICBzZGU6IHNkZTEKWyAgICA1LjExOTAwMF0gc2QgNDowOjA6
MDogW3NkZV0gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAgNS4xMTkwODddIGluaXRjYWxsIDEyX3Nk
X3Byb2JlX2FzeW5jKzB4MC8weDFkMCByZXR1cm5lZCAwIGFmdGVyIDExMTMzIHVzZWNzClsgICAg
NS4xMTkxNzldIGFzeW5jX2NvbnRpbnVpbmcgQCAxIGFmdGVyIDc2ODMgdXNlYwpbICAgIDUuMTE5
NTEyXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA5MjBrIGZyZWVkClsgICAgNS4xMTk2
ODZdIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTIyODhrClsg
ICAgNS4xMjU0NTRdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE2MDhrIGZyZWVkClsg
ICAgNS4xMjYwMzRdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEyMDBrIGZyZWVkClsg
ICAgNS4xNTQ5OTddIHVkZXZkWzk4XTogc3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgICA1LjE4MjYw
MV0gY2FsbGluZyAgeGVuX3BjaWJrX2luaXQrMHgwLzB4NTAgW3hlbl9wY2liYWNrXSBAIDE0Nwpb
ICAgIDUuMTgyNzI5XSBwY2liYWNrIDAwMDA6MDE6MDAuMDogc2VpemluZyBkZXZpY2UKWyAgICA1
LjE4Mjg4NV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEK
WyAgICA1LjE4Mjk4Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3Np
IDE2ClsgICAgNS4xODMwODhdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsg
ICAgNS4xODMxODRdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICA1LjE4MzI3M10gcGNp
YmFjayAwMDAwOjAxOjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElS
USAxNgpbICAgIDUuMTgzMzc4XSBwY2liYWNrIDAwMDA6MDE6MDAuMDogUENJIElOVCBBIGRpc2Fi
bGVkClsgICAgNS4xODcwNDZdIHhlbi1wY2liYWNrOiBiYWNrZW5kIGlzIHBhc3N0aHJvdWdoClsg
ICAgNS4xODcxNTFdIGluaXRjYWxsIHhlbl9wY2lia19pbml0KzB4MC8weDUwIFt4ZW5fcGNpYmFj
a10gcmV0dXJuZWQgMCBhZnRlciA0MzQ1IHVzZWNzClsgICAgNS4xOTQyMTNdIGNhbGxpbmcgIGxp
bmVhcl9pbml0KzB4MC8weDEwMDAgW2xpbmVhcl0gQCAxNjUKWyAgICA1LjE5NDMwMF0gbWQ6IGxp
bmVhciBwZXJzb25hbGl0eSByZWdpc3RlcmVkIGZvciBsZXZlbCAtMQpbICAgIDUuMTk0Mzg0XSBp
bml0Y2FsbCBsaW5lYXJfaW5pdCsweDAvMHgxMDAwIFtsaW5lYXJdIHJldHVybmVkIDAgYWZ0ZXIg
ODEgdXNlY3MKWyAgICA1LjE5OTU3MV0gY2FsbGluZyAgbXVsdGlwYXRoX2luaXQrMHgwLzB4MTAw
MCBbbXVsdGlwYXRoXSBAIDE2OQpbICAgIDUuMTk5NjU5XSBtZDogbXVsdGlwYXRoIHBlcnNvbmFs
aXR5IHJlZ2lzdGVyZWQgZm9yIGxldmVsIC00ClsgICAgNS4xOTk3NDldIGluaXRjYWxsIG11bHRp
cGF0aF9pbml0KzB4MC8weDEwMDAgW211bHRpcGF0aF0gcmV0dXJuZWQgMCBhZnRlciA4NiB1c2Vj
cwpbICAgIDUuMjAzMjg1XSBjYWxsaW5nICByYWlkMF9pbml0KzB4MC8weDEwMDAgW3JhaWQwXSBA
IDE3MQpbICAgIDUuMjAzMzcyXSBtZDogcmFpZDAgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBmb3Ig
bGV2ZWwgMApbICAgIDUuMjAzNDYyXSBpbml0Y2FsbCByYWlkMF9pbml0KzB4MC8weDEwMDAgW3Jh
aWQwXSByZXR1cm5lZCAwIGFmdGVyIDg3IHVzZWNzClsgICAgNS4yMDk0MjFdIGNhbGxpbmcgIHJh
aWRfaW5pdCsweDAvMHgxMDAwIFtyYWlkMV0gQCAxNzkKWyAgICA1LjIwOTUxMV0gbWQ6IHJhaWQx
IHBlcnNvbmFsaXR5IHJlZ2lzdGVyZWQgZm9yIGxldmVsIDEKWyAgICA1LjIwOTU5OF0gaW5pdGNh
bGwgcmFpZF9pbml0KzB4MC8weDEwMDAgW3JhaWQxXSByZXR1cm5lZCAwIGFmdGVyIDgzIHVzZWNz
ClsgICAgNS4yMTg0MTNdIGNhbGxpbmcgIGFzeW5jX3R4X2luaXQrMHgwLzB4MTAwMCBbYXN5bmNf
dHhdIEAgMTg2ClsgICAgNS4yMTg1MTldIGFzeW5jX3R4OiBhcGkgaW5pdGlhbGl6ZWQgKGFzeW5j
KQpbICAgIDUuMjE4NjEyXSBpbml0Y2FsbCBhc3luY190eF9pbml0KzB4MC8weDEwMDAgW2FzeW5j
X3R4XSByZXR1cm5lZCAwIGFmdGVyIDg5IHVzZWNzClsgICAgNS4yMTkwMzFdIGNhbGxpbmcgIGlu
aXRfbW9kdWxlKzB4MC8weDEwMDAgW3JhaWQ2X3BxXSBAIDE4NgpbICAgIDUuMjU3MjkyXSB1c2Ig
MS0xLjY6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNCB1c2luZyBlaGNpX2hjZApb
ICAgIDUuMjY4NzU5XSBjYWxsaW5nICBlMTAwMF9pbml0X21vZHVsZSsweDAvMHgxMDAwIFtlMTAw
MGVdIEAgMTgxClsgICAgNS4yNjg4NDBdIGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29y
ayBEcml2ZXIgLSAxLjUuMS1rClsgICAgNS4yNjg5MjFdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5
OTkgLSAyMDExIEludGVsIENvcnBvcmF0aW9uLgpbICAgIDUuMjY5MDMwXSB4ZW46IHJlZ2lzdGVy
aW5nIGdzaSAyMCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDUuMjY5MTE3XSB4ZW46IC0t
PiBwaXJxPTIwIC0+IGlycT0yMCAoZ3NpPTIwKQpbICAgIDUuMjY5MjIzXSBlMTAwMGUgMDAwMDow
MDoxOS4wOiBQQ0kgSU5UIEEgLT4gR1NJIDIwIChsZXZlbCwgbG93KSAtPiBJUlEgMjAKWyAgICA1
LjI4NTE0MF0gcmFpZDY6IGludDY0eDEgICAzMDcwIE1CL3MKWyAgICA1LjMxMzI0Nl0gZTEwMDBl
IDAwMDA6MDA6MTkuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNS4zNTMxMzdd
IHJhaWQ2OiBpbnQ2NHgyICAgMzc3NSBNQi9zClsgICAgNS4zODI2NzJdIGNhbGxpbmcgIGhpZF9p
bml0KzB4MC8weDYzIFtoaWRdIEAgMjMzClsgICAgNS4zODI3NTddIGluaXRjYWxsIGhpZF9pbml0
KzB4MC8weDYzIFtoaWRdIHJldHVybmVkIDAgYWZ0ZXIgMTcgdXNlY3MKWyAgICA1LjM4MzIzOV0g
Y2FsbGluZyAgaGlkX2luaXQrMHgwLzB4MTAwMCBbdXNiaGlkXSBAIDIzMwpbICAgIDUuMzg1NjMw
XSBtZGFkbTogc2VuZGluZyBpb2N0bCA4MDBjMDkxMCB0byBhIHBhcnRpdGlvbiEKWyAgICA1LjM4
NTY5MV0gbWRhZG06IHNlbmRpbmcgaW9jdGwgODAwYzA5MTAgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODU4MTldIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODU4NzhdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODYyNjddIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODYzMjhdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODY2MjVdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODY2ODddIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODc1MDZdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODc1NjddIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAg
NS4zODc3NzRdIGlucHV0OiBXaW5ib25kIEVsZWN0cm9uaWNzIENvcnAgSGVybW9uIFVTQiBoaWRt
b3VzZSBEZXZpY2UgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAwOjFhLjAvdXNiMS8xLTEv
MS0xLjIvMS0xLjI6MS4wL2lucHV0L2lucHV0MgpbICAgIDUuMzg4MDUxXSBnZW5lcmljLXVzYiAw
MDAzOjA1NTc6MjIyMS4wMDAxOiBpbnB1dCxoaWRyYXcwOiBVU0IgSElEIHYxLjAwIE1vdXNlIFtX
aW5ib25kIEVsZWN0cm9uaWNzIENvcnAgSGVybW9uIFVTQiBoaWRtb3VzZSBEZXZpY2VdIG9uIHVz
Yi0wMDAwOjAwOjFhLjAtMS4yL2lucHV0MApbICAgIDUuMzg5MzQxXSBpbnB1dDogV2luYm9uZCBF
bGVjdHJvbmljcyBDb3JwIEhlcm1vbiBVU0IgaGlkbW91c2UgRGV2aWNlIGFzIC9kZXZpY2VzL3Bj
aTAwMDA6MDAvMDAwMDowMDoxYS4wL3VzYjEvMS0xLzEtMS4yLzEtMS4yOjEuMS9pbnB1dC9pbnB1
dDMKWyAgICA1LjM4OTU4MV0gZ2VuZXJpYy11c2IgMDAwMzowNTU3OjIyMjEuMDAwMjogaW5wdXQs
aGlkcmF3MTogVVNCIEhJRCB2MS4wMCBLZXlib2FyZCBbV2luYm9uZCBFbGVjdHJvbmljcyBDb3Jw
IEhlcm1vbiBVU0IgaGlkbW91c2UgRGV2aWNlXSBvbiB1c2ItMDAwMDowMDoxYS4wLTEuMi9pbnB1
dDEKWyAgICA1LjM4OTgzM10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZl
ciB1c2JoaWQKWyAgICA1LjM4OTg5NV0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyClsgICAg
NS4zODk5NTNdIGluaXRjYWxsIGhpZF9pbml0KzB4MC8weDEwMDAgW3VzYmhpZF0gcmV0dXJuZWQg
MCBhZnRlciA2NDg0IHVzZWNzClsgICAgNS4zOTg4OThdIG1kOiBiaW5kPHNkYjE+ClsgICAgNS40
MjExMzRdIHJhaWQ2OiBpbnQ2NHg0ICAgMzI2NSBNQi9zClsgICAgNS40NjA5NjldIG1kOiBiaW5k
PHNkYzE+ClsgICAgNS40NjUyNjRdIG1kOiBiaW5kPHNkZDE+ClsgICAgNS40NjcwNThdIGJpbzog
Y3JlYXRlIHNsYWIgPGJpby0xPiBhdCAxClsgICAgNS40NjcxNjNdIG1kL3JhaWQxOm1kMDogYWN0
aXZlIHdpdGggMiBvdXQgb2YgMiBtaXJyb3JzClsgICAgNS40NjcyNDJdIG1kMDogZGV0ZWN0ZWQg
Y2FwYWNpdHkgY2hhbmdlIGZyb20gMCB0byAxMDAwMjAyMTc0NDY0ClsgICAgNS40ODMwMDBdICBt
ZDA6IHVua25vd24gcGFydGl0aW9uIHRhYmxlClsgICAgNS40ODkxMzJdIHJhaWQ2OiBpbnQ2NHg4
ICAgMjU5OSBNQi9zClsgICAgNS41MDEyNDddIG1kOiBiaW5kPHNkYTE+ClsgICAgNS41MDMzNTBd
IG1kL3JhaWQxOm1kMTogYWN0aXZlIHdpdGggMiBvdXQgb2YgMiBtaXJyb3JzClsgICAgNS41MDM0
MzNdIG1kMTogZGV0ZWN0ZWQgY2FwYWNpdHkgY2hhbmdlIGZyb20gMCB0byA1MDAxMDU2MjU2MDAK
WyAgICA1LjUyMjE1N10gIG1kMTogdW5rbm93biBwYXJ0aXRpb24gdGFibGUKWyAgICA1LjU1NzEy
OF0gcmFpZDY6IHNzZTJ4MSAgICA4MDgxIE1CL3MKWyAgICA1LjYyMDE3Ml0gZTEwMDBlIDAwMDA6
MDA6MTkuMDogZXRoMDogKFBDSSBFeHByZXNzOjIuNUdUL3M6V2lkdGggeDEpIDAwOjI1OjkwOjU3
OjlkOjVmClsgICAgNS42MjAyNjRdIGUxMDAwZSAwMDAwOjAwOjE5LjA6IGV0aDA6IEludGVsKFIp
IFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbgpbICAgIDUuNjIwMzc5XSBlMTAwMGUgMDAwMDow
MDoxOS4wOiBldGgwOiBNQUM6IDEwLCBQSFk6IDExLCBQQkEgTm86IEZGRkZGRi0wRkYKWyAgICA1
LjYyMDQ1N10gZTEwMDBlIDAwMDA6MDM6MDAuMDogRGlzYWJsaW5nIEFTUE0gTDBzIApbICAgIDUu
NjIwNjEzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpb
ICAgIDUuNjIwNjc2XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kg
MTYKWyAgICA1LjYyMDczNV0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAg
ICA1LjYyMDc5M10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpbICAgIDUuNjIwODQ4XSBlMTAw
MGUgMDAwMDowMzowMC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEg
MTYKWyAgICA1LjYyMDkzM10gZTEwMDBlIDAwMDA6MDM6MDAuMDogc2V0dGluZyBsYXRlbmN5IHRp
bWVyIHRvIDY0ClsgICAgNS42MjUxMzJdIHJhaWQ2OiBzc2UyeDIgICAgOTk1MiBNQi9zClsgICAg
NS42OTMxMzJdIHJhaWQ2OiBzc2UyeDQgICAxMTM4NyBNQi9zClsgICAgNS42OTMyNTldIHJhaWQ2
OiB1c2luZyBhbGdvcml0aG0gc3NlMng0ICgxMTM4NyBNQi9zKQpbICAgIDUuNjkzMzE5XSBpbml0
Y2FsbCBpbml0X21vZHVsZSsweDAvMHgxMDAwIFtyYWlkNl9wcV0gcmV0dXJuZWQgMCBhZnRlciA0
NjMwODggdXNlY3MKWyAgICA1LjY5Mzg2N10gY2FsbGluZyAgY2FsaWJyYXRlX3hvcl9ibG9ja3Mr
MHgwLzB4MTAwMCBbeG9yXSBAIDE4NgpbICAgIDUuNjkzOTI4XSB4b3I6IGF1dG9tYXRpY2FsbHkg
dXNpbmcgYmVzdCBjaGVja3N1bW1pbmcgZnVuY3Rpb246IGdlbmVyaWNfc3NlClsgICAgNS43MTMx
MzFdICAgIGdlbmVyaWNfc3NlOiAgMzYyNS4wMDAgTUIvc2VjClsgICAgNS43MTMxOTZdIHhvcjog
dXNpbmcgZnVuY3Rpb246IGdlbmVyaWNfc3NlICgzNjI1LjAwMCBNQi9zZWMpClsgICAgNS43MTMy
NjJdIGluaXRjYWxsIGNhbGlicmF0ZV94b3JfYmxvY2tzKzB4MC8weDEwMDAgW3hvcl0gcmV0dXJu
ZWQgMCBhZnRlciAxODg4MCB1c2VjcwpbICAgIDUuNzE1MDk4XSBjYWxsaW5nICBhc3luY19wcV9p
bml0KzB4MC8weDEwMDAgW2FzeW5jX3BxXSBAIDE4NgpbICAgIDUuNzE1MTcyXSBpbml0Y2FsbCBh
c3luY19wcV9pbml0KzB4MC8weDEwMDAgW2FzeW5jX3BxXSByZXR1cm5lZCAwIGFmdGVyIDAgdXNl
Y3MKWyAgICA1LjcxNTc1NF0gY2FsbGluZyAgcmFpZDVfaW5pdCsweDAvMHgxMDAwIFtyYWlkNDU2
XSBAIDE4NgpbICAgIDUuNzE1ODI0XSBtZDogcmFpZDYgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBm
b3IgbGV2ZWwgNgpbICAgIDUuNzE1ODg4XSBtZDogcmFpZDUgcGVyc29uYWxpdHkgcmVnaXN0ZXJl
ZCBmb3IgbGV2ZWwgNQpbICAgIDUuNzE1OTU5XSBtZDogcmFpZDQgcGVyc29uYWxpdHkgcmVnaXN0
ZXJlZCBmb3IgbGV2ZWwgNApbICAgIDUuNzE2MDI2XSBpbml0Y2FsbCByYWlkNV9pbml0KzB4MC8w
eDEwMDAgW3JhaWQ0NTZdIHJldHVybmVkIDAgYWZ0ZXIgMTk2IHVzZWNzClsgICAgNS43Mjg2OTFd
IGUxMDAwZSAwMDAwOjAzOjAwLjA6IGV0aDE6IChQQ0kgRXhwcmVzczoyLjVHVC9zOldpZHRoIHgx
KSAwMDoyNTo5MDo1Nzo5ZDo1ZQpbICAgIDUuNzI4NzczXSBlMTAwMGUgMDAwMDowMzowMC4wOiBl
dGgxOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24KWyAgICA1LjcyODkyOF0g
ZTEwMDBlIDAwMDA6MDM6MDAuMDogZXRoMTogTUFDOiAzLCBQSFk6IDgsIFBCQSBObzogRkZGRkZG
LTBGRgpbICAgIDUuNzI5MDA5XSBpbml0Y2FsbCBlMTAwMF9pbml0X21vZHVsZSsweDAvMHgxMDAw
IFtlMTAwMGVdIHJldHVybmVkIDAgYWZ0ZXIgNDQ5Mzc4IHVzZWNzClsgICAgNS43MzMyMTVdIGNh
bGxpbmcgIHJhaWRfaW5pdCsweDAvMHgxMDAwIFtyYWlkMTBdIEAgMjcwClsgICAgNS43MzMyODRd
IG1kOiByYWlkMTAgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBmb3IgbGV2ZWwgMTAKWyAgICA1Ljcz
MzM1NF0gaW5pdGNhbGwgcmFpZF9pbml0KzB4MC8weDEwMDAgW3JhaWQxMF0gcmV0dXJuZWQgMCBh
ZnRlciA2NyB1c2VjcwpbICAgIDYuNjI2MDE2XSBnZW5lcmljLXVzYiAwMDAzOjA1MUQ6MDAwMi4w
MDAzOiBoaWRkZXYwLGhpZHJhdzI6IFVTQiBISUQgdjEuMTAgRGV2aWNlIFtBbWVyaWNhbiBQb3dl
ciBDb252ZXJzaW9uIEJhY2stVVBTIEVTIDc1MCBGVzo4NDEuSTIgLkQgVVNCIEZXOkkyIF0gb24g
dXNiLTAwMDA6MDA6MWEuMC0xLjYvaW5wdXQwClsgICAgNi42OTczMDldIHVzYiAyLTEuMTogbmV3
IGZ1bGwtc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMyB1c2luZyBlaGNpX2hjZApbICAgIDYuNzk4
MjM0XSBpbnB1dDogTWljcm9zb2Z0IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZm
ZmZhZSBOYW5vIFRyYW5zY2VpdmVyIHYyLjAgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAwOjAw
OjFkLjAvdXNiMi8yLTEvMi0xLjEvMi0xLjE6MS4wL2lucHV0L2lucHV0NApbICAgIDYuNzk4NDI5
XSBnZW5lcmljLXVzYiAwMDAzOjA0NUU6MDc0NS4wMDA0OiBpbnB1dCxoaWRyYXczOiBVU0IgSElE
IHYxLjExIEtleWJvYXJkIFtNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZjMlx4ZmZmZmZmYWVc
eGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMF0gb24gdXNiLTAwMDA6MDA6MWQuMC0xLjEv
aW5wdXQwClsgICAgNi44MDM5ODNdIGlucHV0OiBNaWNyb3NvZnQgTWljcm9zb2Z0XHhmZmZmZmZj
Mlx4ZmZmZmZmYWVceGZmZmZmZmFlIE5hbm8gVHJhbnNjZWl2ZXIgdjIuMCBhcyAvZGV2aWNlcy9w
Y2kwMDAwOjAwLzAwMDA6MDA6MWQuMC91c2IyLzItMS8yLTEuMS8yLTEuMToxLjEvaW5wdXQvaW5w
dXQ1ClsgICAgNi44MDQyNjVdIGdlbmVyaWMtdXNiIDAwMDM6MDQ1RTowNzQ1LjAwMDU6IGlucHV0
LGhpZHJhdzQ6IFVTQiBISUQgdjEuMTEgTW91c2UgW01pY3Jvc29mdCBNaWNyb3NvZnRceGZmZmZm
ZmMyXHhmZmZmZmZhZVx4ZmZmZmZmYWUgTmFubyBUcmFuc2NlaXZlciB2Mi4wXSBvbiB1c2ItMDAw
MDowMDoxZC4wLTEuMS9pbnB1dDEKWyAgICA2LjgxOTc0M10gaW5wdXQ6IE1pY3Jvc29mdCBNaWNy
b3NvZnRceGZmZmZmZmMyXHhmZmZmZmZhZVx4ZmZmZmZmYWUgTmFubyBUcmFuc2NlaXZlciB2Mi4w
IGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxZC4wL3VzYjIvMi0xLzItMS4xLzItMS4x
OjEuMi9pbnB1dC9pbnB1dDYKWyAgICA2LjgyMDAwM10gZ2VuZXJpYy11c2IgMDAwMzowNDVFOjA3
NDUuMDAwNjogaW5wdXQsaGlkZGV2MCxoaWRyYXc1OiBVU0IgSElEIHYxLjExIERldmljZSBbTWlj
cm9zb2Z0IE1pY3Jvc29mdFx4ZmZmZmZmYzJceGZmZmZmZmFlXHhmZmZmZmZhZSBOYW5vIFRyYW5z
Y2VpdmVyIHYyLjBdIG9uIHVzYi0wMDAwOjAwOjFkLjAtMS4xL2lucHV0MgpbICAgIDYuODg5MzA3
XSB1c2IgMi0xLjM6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNCB1c2luZyBlaGNp
X2hjZApbICAgIDYuOTkyMjEzXSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZp
Y2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxZC4wL3VzYjIvMi0xLzItMS4zLzItMS4zOjEuMC9pbnB1
dC9pbnB1dDcKWyAgICA2Ljk5MjQzOV0gZ2VuZXJpYy11c2IgMDAwMzowNDZEOkM1MDguMDAwNzog
aW5wdXQsaGlkcmF3NjogVVNCIEhJRCB2MS4xMCBNb3VzZSBbTG9naXRlY2ggVVNCIFJlY2VpdmVy
XSBvbiB1c2ItMDAwMDowMDoxZC4wLTEuMy9pbnB1dDAKWyAgICA3LjA2MTMwMl0gdXNiIDItMS40
OiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDUgdXNpbmcgZWhjaV9oY2QKWyAgICA3
LjE3MjY3NF0gaW5wdXQ6IEhJRCAwNGQ5OjEyMDMgYXMgL2RldmljZXMvcGNpMDAwMDowMC8wMDAw
OjAwOjFkLjAvdXNiMi8yLTEvMi0xLjQvMi0xLjQ6MS4wL2lucHV0L2lucHV0OApbICAgIDcuMTcy
ODY5XSBnZW5lcmljLXVzYiAwMDAzOjA0RDk6MTIwMy4wMDA4OiBpbnB1dCxoaWRyYXc3OiBVU0Ig
SElEIHYxLjExIEtleWJvYXJkIFtISUQgMDRkOToxMjAzXSBvbiB1c2ItMDAwMDowMDoxZC4wLTEu
NC9pbnB1dDAKWyAgICA3LjE4ODEwM10gaW5wdXQ6IEhJRCAwNGQ5OjEyMDMgYXMgL2RldmljZXMv
cGNpMDAwMDowMC8wMDAwOjAwOjFkLjAvdXNiMi8yLTEvMi0xLjQvMi0xLjQ6MS4xL2lucHV0L2lu
cHV0OQpbICAgIDcuMTg4MzA5XSBnZW5lcmljLXVzYiAwMDAzOjA0RDk6MTIwMy4wMDA5OiBpbnB1
dCxoaWRyYXc4OiBVU0IgSElEIHYxLjExIERldmljZSBbSElEIDA0ZDk6MTIwM10gb24gdXNiLTAw
MDA6MDA6MWQuMC0xLjQvaW5wdXQxClsgICAgNy4yNTcyNzBdIHVzYiAyLTEuNTogbmV3IGhpZ2gt
c3BlZWQgVVNCIGRldmljZSBudW1iZXIgNiB1c2luZyBlaGNpX2hjZApbICAgIDcuNTQwNzYwXSBj
YWxsaW5nICB1c2Jfc3Rvcl9pbml0KzB4MC8weDEwMDAgW3VzYl9zdG9yYWdlXSBAIDQ2MwpbICAg
IDcuNTQwODQ4XSBJbml0aWFsaXppbmcgVVNCIE1hc3MgU3RvcmFnZSBkcml2ZXIuLi4KWyAgICA3
LjU0MTAwNV0gc2NzaTYgOiB1c2Itc3RvcmFnZSAyLTEuNToxLjAKWyAgICA3LjU0MTE0NF0gdXNi
Y29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQpbICAgIDcu
NTQxMjI2XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KWyAgICA3LjU0MTMx
MF0gaW5pdGNhbGwgdXNiX3N0b3JfaW5pdCsweDAvMHgxMDAwIFt1c2Jfc3RvcmFnZV0gcmV0dXJu
ZWQgMCBhZnRlciA0NDggdXNlY3MKWyAgICA3LjU0MTQ1NF0gY2FsbGluZyAgdWFzX2luaXQrMHgw
LzB4MzAgW3Vhc10gQCA0NjQKWyAgICA3LjU0MTY5NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciB1YXMKWyAgICA3LjU0MTc4MV0gaW5pdGNhbGwgdWFzX2luaXQrMHgw
LzB4MzAgW3Vhc10gcmV0dXJuZWQgMCBhZnRlciAyMzQgdXNlY3MKWyAgICA4LjA0NjA3OV0gRVhU
NC1mcyAoZG0tMjcpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4g
T3B0czogKG51bGwpClsgICAgOC44OTgzMjBdIHNjc2kgNjowOjA6MDogRGlyZWN0LUFjY2VzcyAg
ICAgR2VuZXJpYyAgQ29tcGFjdCBGbGFzaCAgICAwLjAwIFBROiAwIEFOU0k6IDIKWyAgICA4Ljg5
ODg5N10gc2NzaSA2OjA6MDoxOiBEaXJlY3QtQWNjZXNzICAgICBHZW5lcmljICBTTS94RC1QaWN0
dXJlICAgIDAuMDAgUFE6IDAgQU5TSTogMgpbICAgIDguODk5NDI2XSBzY3NpIDY6MDowOjI6IERp
cmVjdC1BY2Nlc3MgICAgIEdlbmVyaWMgIFNEWEMvTU1DICAgICAgICAgMC4wMCBQUTogMCBBTlNJ
OiAyClsgICAgOC45MDAwNDNdIHNjc2kgNjowOjA6MzogRGlyZWN0LUFjY2VzcyAgICAgR2VuZXJp
YyAgTVMvTVMtUHJvL0hHICAgICAwLjAwIFBROiAwIEFOU0k6IDIKWyAgICA4LjkwMDY3NV0gc2Nz
aSA2OjA6MDo0OiBEaXJlY3QtQWNjZXNzICAgICBHZW5lcmljICBTRC9NTUMvTVMvTVNQUk8gIDAu
MDAgUFE6IDAgQU5TSTogMgpbICAgIDguOTAxMjY0XSBzZCA2OjA6MDowOiBBdHRhY2hlZCBzY3Np
IGdlbmVyaWMgc2c2IHR5cGUgMApbICAgIDguOTAxNzczXSBzZCA2OjA6MDowOiBbc2RmXSA3ODEz
MTIwIDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoNC4wMCBHQi8zLjcyIEdpQikKWyAgICA4Ljkw
MjI3Ml0gc2QgNjowOjA6MDogW3NkZl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgICA4LjkwMjI3
NF0gc2QgNjowOjA6MDogW3NkZl0gTW9kZSBTZW5zZTogMDMgMDAgMDAgMDAKWyAgICA4LjkwMjc3
Nl0gc2QgNjowOjA6MDogW3NkZl0gTm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDgu
OTAyNzc3XSBzZCA2OjA6MDowOiBbc2RmXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhy
b3VnaApbICAgIDguOTAzMzAwXSBzZCA2OjA6MDoxOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2c3
IHR5cGUgMApbICAgIDguOTAzNDc2XSBzZCA2OjA6MDoyOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMg
c2c4IHR5cGUgMApbICAgIDguOTAzNjU1XSBzZCA2OjA6MDozOiBBdHRhY2hlZCBzY3NpIGdlbmVy
aWMgc2c5IHR5cGUgMApbICAgIDguOTAzODMwXSBzZCA2OjA6MDo0OiBBdHRhY2hlZCBzY3NpIGdl
bmVyaWMgc2cxMCB0eXBlIDAKWyAgICA4LjkwOTAzNF0gc2QgNjowOjA6MTogW3NkZ10gQXR0YWNo
ZWQgU0NTSSByZW1vdmFibGUgZGlzawpbICAgIDguOTEwMDMyXSBzZCA2OjA6MDoyOiBbc2RoXSBB
dHRhY2hlZCBTQ1NJIHJlbW92YWJsZSBkaXNrClsgICAgOC45MTA2NjBdIHNkIDY6MDowOjM6IFtz
ZGldIEF0dGFjaGVkIFNDU0kgcmVtb3ZhYmxlIGRpc2sKWyAgICA4LjkxMjU2NF0gc2QgNjowOjA6
NDogW3Nkal0gQXR0YWNoZWQgU0NTSSByZW1vdmFibGUgZGlzawpbICAgIDguOTEzMDM5XSBzZCA2
OjA6MDowOiBbc2RmXSBObyBDYWNoaW5nIG1vZGUgcGFnZSBwcmVzZW50ClsgICAgOC45MTMxMzBd
IHNkIDY6MDowOjA6IFtzZGZdIEFzc3VtaW5nIGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdoClsg
ICAgOC45MTM5MjZdICBzZGY6IHNkZjEKWyAgICA4LjkxNTkxOF0gc2QgNjowOjA6MDogW3NkZl0g
Tm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDguOTE2MDExXSBzZCA2OjA6MDowOiBb
c2RmXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3VnaApbICAgIDguOTE2MDg2XSBz
ZCA2OjA6MDowOiBbc2RmXSBBdHRhY2hlZCBTQ1NJIHJlbW92YWJsZSBkaXNrClsgICAxMS43OTM2
NzRdIEFERFJDT05GKE5FVERFVl9VUCk6IGV0aDA6IGxpbmsgaXMgbm90IHJlYWR5ClsgICAxMS43
OTM2ODJdIEFERFJDT05GKE5FVERFVl9VUCk6IGV0aDE6IGxpbmsgaXMgbm90IHJlYWR5ClsgICAx
MS44MDE2OTFdIHVkZXZkWzcxNV06IHN0YXJ0aW5nIHZlcnNpb24gMTc1ClsgICAxMS44MzE1NTdd
IGNhbGxpbmcgIHBhcnBvcnRfZGVmYXVsdF9wcm9jX3JlZ2lzdGVyKzB4MC8weDEwMDAgW3BhcnBv
cnRdIEAgNzI3ClsgICAxMS44MzE1NzRdIGluaXRjYWxsIHBhcnBvcnRfZGVmYXVsdF9wcm9jX3Jl
Z2lzdGVyKzB4MC8weDEwMDAgW3BhcnBvcnRdIHJldHVybmVkIDAgYWZ0ZXIgMTEgdXNlY3MKWyAg
IDExLjgzMTgwMF0gY2FsbGluZyAgbHBfaW5pdF9tb2R1bGUrMHgwLzB4ZTU3IFtscF0gQCA3MjcK
WyAgIDExLjgzODk0MF0gQWRkaW5nIDgzODg2MDRrIHN3YXAgb24gL2Rldi9tYXBwZXIvVlN5c3Rl
bTAxLWx2U3dhcDhHQi4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBhY3Jvc3M6ODM4ODYwNGsgClsg
ICAxMS44NTQ3NzRdIGxwOiBkcml2ZXIgbG9hZGVkIGJ1dCBubyBkZXZpY2VzIGZvdW5kClsgICAx
MS44NTQ3ODBdIGluaXRjYWxsIGxwX2luaXRfbW9kdWxlKzB4MC8weGU1NyBbbHBdIHJldHVybmVk
IDAgYWZ0ZXIgMjI0MzYgdXNlY3MKWyAgIDExLjg1ODE5MF0gY2FsbGluZyAgZXZ0Y2huX2luaXQr
MHgwLzB4MTAwMCBbeGVuX2V2dGNobl0gQCA3NDYKWyAgIDExLjg1ODI1NV0gRXZlbnQtY2hhbm5l
bCBkZXZpY2UgaW5zdGFsbGVkLgpbICAgMTEuODU4MjU5XSBpbml0Y2FsbCBldnRjaG5faW5pdCsw
eDAvMHgxMDAwIFt4ZW5fZXZ0Y2huXSByZXR1cm5lZCAwIGFmdGVyIDYzIHVzZWNzClsgICAxMS44
NTk5ODZdIGNhbGxpbmcgIGdudGRldl9pbml0KzB4MC8weDEwMDAgW3hlbl9nbnRkZXZdIEAgNzQ3
ClsgICAxMS44NjAwMjldIGluaXRjYWxsIGdudGRldl9pbml0KzB4MC8weDEwMDAgW3hlbl9nbnRk
ZXZdIHJldHVybmVkIDAgYWZ0ZXIgMzggdXNlY3MKWyAgIDExLjg2MTg1OV0gY2FsbGluZyAgbmV0
YmFja19pbml0KzB4MC8weDEwMDAgW3hlbl9uZXRiYWNrXSBAIDc0OApbICAgMTEuODY5MTYwXSBp
bml0Y2FsbCBuZXRiYWNrX2luaXQrMHgwLzB4MTAwMCBbeGVuX25ldGJhY2tdIHJldHVybmVkIDAg
YWZ0ZXIgNzEyNCB1c2VjcwpbICAgMTEuODcxMDQyXSBjYWxsaW5nICB4ZW5fYmxraWZfaW5pdCsw
eDAvMHgyM2UgW3hlbl9ibGtiYWNrXSBAIDc1OQpbICAgMTEuODcxMzk3XSBpbml0Y2FsbCB4ZW5f
YmxraWZfaW5pdCsweDAvMHgyM2UgW3hlbl9ibGtiYWNrXSByZXR1cm5lZCAwIGFmdGVyIDM0MiB1
c2VjcwpbICAgMTEuODc0NzI5XSBjYWxsaW5nICB4ZW5mc19pbml0KzB4MC8weDEwMDAgW3hlbmZz
XSBAIDc2MgpbICAgMTEuODc0NzM1XSBpbml0Y2FsbCB4ZW5mc19pbml0KzB4MC8weDEwMDAgW3hl
bmZzXSByZXR1cm5lZCAwIGFmdGVyIDIgdXNlY3MKWyAgIDExLjg4OTg5MV0gY2FsbGluZyAgbWFj
X2hpZF9pbml0KzB4MC8weDEwMDAgW21hY19oaWRdIEAgNzUzClsgICAxMS44ODk5MTFdIGluaXRj
YWxsIG1hY19oaWRfaW5pdCsweDAvMHgxMDAwIFttYWNfaGlkXSByZXR1cm5lZCAwIGFmdGVyIDE0
IHVzZWNzClsgICAxMS44OTg3NDBdIGNhbGxpbmcgIGpveWRldl9pbml0KzB4MC8weDEwMDAgW2pv
eWRldl0gQCA3NzUKWyAgIDExLjg5OTc4N10gaW5pdGNhbGwgam95ZGV2X2luaXQrMHgwLzB4MTAw
MCBbam95ZGV2XSByZXR1cm5lZCAwIGFmdGVyIDEwMTcgdXNlY3MKWyAgIDExLjk3ODMyOF0gdHlw
ZT0xNDAwIGF1ZGl0KDEzMzQxNjg5NzIuMDg3OjIpOiBhcHBhcm1vcj0iU1RBVFVTIiBvcGVyYXRp
b249InByb2ZpbGVfbG9hZCIgbmFtZT0iL3NiaW4vZGhjbGllbnQiIHBpZD04MjAgY29tbT0iYXBw
YXJtb3JfcGFyc2VyIgpbICAgMTEuOTc4NTgyXSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2ODk3Mi4w
ODc6Myk6IGFwcGFybW9yPSJTVEFUVVMiIG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBuYW1lPSIv
dXNyL2xpYi9OZXR3b3JrTWFuYWdlci9ubS1kaGNwLWNsaWVudC5hY3Rpb24iIHBpZD04MjAgY29t
bT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTEuOTc4NzI0XSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2
ODk3Mi4wODc6NCk6IGFwcGFybW9yPSJTVEFUVVMiIG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBu
YW1lPSIvdXNyL2xpYi9jb25ubWFuL3NjcmlwdHMvZGhjbGllbnQtc2NyaXB0IiBwaWQ9ODIwIGNv
bW09ImFwcGFybW9yX3BhcnNlciIKWyAgIDEyLjA0ODg5OF0gY2FsbGluZyAgc2VyaW9fcmF3X2lu
aXQrMHgwLzB4MTAwMCBbc2VyaW9fcmF3XSBAIDg3OApbICAgMTIuMDQ5NDM1XSBpbml0Y2FsbCBz
ZXJpb19yYXdfaW5pdCsweDAvMHgxMDAwIFtzZXJpb19yYXddIHJldHVybmVkIDAgYWZ0ZXIgNTE4
IHVzZWNzClsgICAxMi4wNjk2MjNdIGNhbGxpbmcgIHBzbW91c2VfaW5pdCsweDAvMHg3ZSBbcHNt
b3VzZV0gQCA4NzkKWyAgIDEyLjA3MTc1NF0gaW5pdGNhbGwgcHNtb3VzZV9pbml0KzB4MC8weDdl
IFtwc21vdXNlXSByZXR1cm5lZCAwIGFmdGVyIDIwNzQgdXNlY3MKWyAgIDEyLjE3NjYxNV0gY2Fs
bGluZyAgYnJfaW5pdCsweDAvMHhiZCBbYnJpZGdlXSBAIDk3MApbICAgMTIuMTc2NjU0XSBCcmlk
Z2UgZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZApbICAgMTIuMjA2MjMyXSBBRERSQ09ORihORVRERVZf
VVApOiBldGgwOiBsaW5rIGlzIG5vdCByZWFkeQpbICAgMTIuMjA2NTYwXSBpbml0Y2FsbCBicl9p
bml0KzB4MC8weGJkIFticmlkZ2VdIHJldHVybmVkIDAgYWZ0ZXIgMjkyMzQgdXNlY3MKWyAgIDEy
LjI1MDc3NF0gZGV2aWNlIGV0aDEgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlClsgICAxMi4zODYz
MjFdIHNjc2lfdmVyaWZ5X2Jsa19pb2N0bDogMTAyIGNhbGxiYWNrcyBzdXBwcmVzc2VkClsgICAx
Mi4zODYzMjVdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAx
Mi4zODYzMjldIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsgICAx
Mi4zOTYzOTFdIEFERFJDT05GKE5FVERFVl9VUCk6IGV0aDE6IGxpbmsgaXMgbm90IHJlYWR5Clsg
ICAxMi4zOTgzOTBdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsg
ICAxMi4zOTgzOTNdIG1kYWRtOiBzZW5kaW5nIGlvY3RsIDEyNjEgdG8gYSBwYXJ0aXRpb24hClsg
ICAxMi40MjQwNDZdIEFERFJDT05GKE5FVERFVl9VUCk6IGJyMDogbGluayBpcyBub3QgcmVhZHkK
WyAgIDE0LjczNzI5NF0gY2FsbGluZyAgdmVzYWZiX2luaXQrMHgwLzB4ODRhIFt2ZXNhZmJdIEAg
MTMzOApbICAgMTQuNzM3MzUzXSBpbml0Y2FsbCB2ZXNhZmJfaW5pdCsweDAvMHg4NGEgW3Zlc2Fm
Yl0gcmV0dXJuZWQgLTE5IGFmdGVyIDUzIHVzZWNzClsgICAxNC43NTM4NDhdIGluaXQ6IHVkZXYt
ZmFsbGJhY2stZ3JhcGhpY3MgbWFpbiBwcm9jZXNzICgxMzM3KSB0ZXJtaW5hdGVkIHdpdGggc3Rh
dHVzIDEKWyAgIDE1LjA5NjU2OF0gRVhUNC1mcyAoZG0tMjcpOiByZS1tb3VudGVkLiBPcHRzOiBl
cnJvcnM9cmVtb3VudC1ybwpbICAgMTUuMTg5NTQ4XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21t
aXQgaW50ZXJ2YWwgNSBzZWNvbmRzClsgICAxNS4yMTUzNjFdIEVYVDMtZnMgKHNkZjEpOiB1c2lu
ZyBpbnRlcm5hbCBqb3VybmFsClsgICAxNS4yMTUzNjhdIEVYVDMtZnMgKHNkZjEpOiBtb3VudGVk
IGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpbICAgMTUuMjY0OTA5XSBpbml0OiBm
bHVzaC1lYXJseS1qb2ItbG9nIG1haW4gcHJvY2VzcyAoMTM4MSkgdGVybWluYXRlZCB3aXRoIHN0
YXR1cyAxClsgICAxNS4yNzI3ODBdIGluaXQ6IGZhaWxzYWZlIG1haW4gcHJvY2VzcyAoMTM3OCkg
a2lsbGVkIGJ5IFRFUk0gc2lnbmFsClsgICAxNS4zNDY5NTRdIHR5cGU9MTQwMCBhdWRpdCgxMzM0
MTY4OTc1LjQ1NTo1KTogYXBwYXJtb3I9IlNUQVRVUyIgb3BlcmF0aW9uPSJwcm9maWxlX2xvYWQi
IG5hbWU9Ii91c3Ivc2Jpbi9uYW1lZCIgcGlkPTE0NDEgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpb
ICAgMTUuMzQ5ODc1XSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2ODk3NS40NTk6Nik6IGFwcGFybW9y
PSJTVEFUVVMiIG9wZXJhdGlvbj0icHJvZmlsZV9yZXBsYWNlIiBuYW1lPSIvc2Jpbi9kaGNsaWVu
dCIgcGlkPTE0NDAgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTUuMzUwMTU0XSB0eXBlPTE0
MDAgYXVkaXQoMTMzNDE2ODk3NS40NTk6Nyk6IGFwcGFybW9yPSJTVEFUVVMiIG9wZXJhdGlvbj0i
cHJvZmlsZV9yZXBsYWNlIiBuYW1lPSIvdXNyL2xpYi9OZXR3b3JrTWFuYWdlci9ubS1kaGNwLWNs
aWVudC5hY3Rpb24iIHBpZD0xNDQwIGNvbW09ImFwcGFybW9yX3BhcnNlciIKWyAgIDE1LjM1MDMw
MF0gdHlwZT0xNDAwIGF1ZGl0KDEzMzQxNjg5NzUuNDU5OjgpOiBhcHBhcm1vcj0iU1RBVFVTIiBv
cGVyYXRpb249InByb2ZpbGVfcmVwbGFjZSIgbmFtZT0iL3Vzci9saWIvY29ubm1hbi9zY3JpcHRz
L2RoY2xpZW50LXNjcmlwdCIgcGlkPTE0NDAgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTUu
MzUzMTc4XSB0eXBlPTE0MDAgYXVkaXQoMTMzNDE2ODk3NS40NjM6OSk6IGFwcGFybW9yPSJTVEFU
VVMiIG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBuYW1lPSIvdXNyL3NiaW4vdGNwZHVtcCIgcGlk
PTE0NDMgY29tbT0iYXBwYXJtb3JfcGFyc2VyIgpbICAgMTUuNzk5MDY3XSBlMTAwMGU6IGV0aDAg
TklDIExpbmsgaXMgVXAgMTAwMCBNYnBzIEZ1bGwgRHVwbGV4LCBGbG93IENvbnRyb2w6IFJ4L1R4
ClsgICAxNS43OTk4OTddIEFERFJDT05GKE5FVERFVl9DSEFOR0UpOiBldGgwOiBsaW5rIGJlY29t
ZXMgcmVhZHkKWyAgIDE1LjgxMDI0MV0gZTEwMDBlOiBldGgxIE5JQyBMaW5rIGlzIFVwIDEwMDAg
TWJwcyBGdWxsIER1cGxleCwgRmxvdyBDb250cm9sOiBSeC9UeApbICAgMTUuODExMTYzXSBBRERS
Q09ORihORVRERVZfQ0hBTkdFKTogZXRoMTogbGluayBiZWNvbWVzIHJlYWR5ClsgICAxNS44MTEy
ODZdIGJyMDogdG9wb2xvZ3kgY2hhbmdlIGRldGVjdGVkLCBwcm9wYWdhdGluZwpbICAgMTUuODEx
Mjg5XSBicjA6IHBvcnQgMShldGgxKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlClsgICAxNS44
MTEyOTNdIGJyMDogcG9ydCAxKGV0aDEpIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKWyAgIDE1
LjgxMjA3Nl0gQUREUkNPTkYoTkVUREVWX0NIQU5HRSk6IGJyMDogbGluayBiZWNvbWVzIHJlYWR5
ClsgICAxNi4wMzk3OTFdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAxNi4w
Mzk5OTNdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAxOC4zMzc4NjldIGlu
aXQ6IHBseW1vdXRoLXVwc3RhcnQtYnJpZGdlIG1haW4gcHJvY2VzcyAoMTQxMykga2lsbGVkIGJ5
IFRFUk0gc2lnbmFsClsgICAyNi4wNjUxMjddIGJyMDogbm8gSVB2NiByb3V0ZXJzIHByZXNlbnQK
WyAgIDI2LjY0MTEyOV0gZXRoMDogbm8gSVB2NiByb3V0ZXJzIHByZXNlbnQKWyAgMzIyLjkzMjIx
Ml0gZGV2aWNlIHZpZjEuMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUKWyAgMzIyLjkzNTA0Ml0g
QUREUkNPTkYoTkVUREVWX1VQKTogdmlmMS4wOiBsaW5rIGlzIG5vdCByZWFkeQpbICAzMjIuOTkx
NTU0XSBjYWxsaW5nICB4dF9pbml0KzB4MC8weDEwMDAgW3hfdGFibGVzXSBAIDI5MDUKWyAgMzIy
Ljk5MTU2MF0gaW5pdGNhbGwgeHRfaW5pdCsweDAvMHgxMDAwIFt4X3RhYmxlc10gcmV0dXJuZWQg
MCBhZnRlciAxIHVzZWNzClsgIDMyMy4wMDA2ODJdIGNhbGxpbmcgIGlwX3RhYmxlc19pbml0KzB4
MC8weDEwMDAgW2lwX3RhYmxlc10gQCAyOTA1ClsgIDMyMy4wMDA2OTFdIGlwX3RhYmxlczogKEMp
IDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClsgIDMyMy4wMDA2OTRdIGluaXRjYWxsIGlw
X3RhYmxlc19pbml0KzB4MC8weDEwMDAgW2lwX3RhYmxlc10gcmV0dXJuZWQgMCBhZnRlciA4IHVz
ZWNzClsgIDMyMy4wMDI5ODNdIGNhbGxpbmcgIGlwdGFibGVfZmlsdGVyX2luaXQrMHgwLzB4MTAw
MCBbaXB0YWJsZV9maWx0ZXJdIEAgMjkyOApbICAzMjMuMDAyOTkzXSBpbml0Y2FsbCBpcHRhYmxl
X2ZpbHRlcl9pbml0KzB4MC8weDEwMDAgW2lwdGFibGVfZmlsdGVyXSByZXR1cm5lZCAwIGFmdGVy
IDUgdXNlY3MKWyAgMzIzLjAzMzc5NV0gY2FsbGluZyAgcGh5c2Rldl9tdF9pbml0KzB4MC8weDEw
MDAgW3h0X3BoeXNkZXZdIEAgMjkzNQpbICAzMjMuMDMzNzk5XSBpbml0Y2FsbCBwaHlzZGV2X210
X2luaXQrMHgwLzB4MTAwMCBbeHRfcGh5c2Rldl0gcmV0dXJuZWQgMCBhZnRlciAwIHVzZWNzClsg
IDMyNC4wMDc3NTFdIGRldmljZSB0YXAxLjAgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlClsgIDMy
NC4wMDc3NzddIGJyMDogdG9wb2xvZ3kgY2hhbmdlIGRldGVjdGVkLCBwcm9wYWdhdGluZwpbICAz
MjQuMDA3NzgwXSBicjA6IHBvcnQgMyh0YXAxLjApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUK
WyAgMzI0LjAwNzc4M10gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0
YXRlClsgIDMyNC4wNTYwNzRdIGJyMDogcG9ydCAzKHRhcDEuMCkgZW50ZXJpbmcgZm9yd2FyZGlu
ZyBzdGF0ZQpbICAzMjQuMDYyNDE2XSBicjA6IHRvcG9sb2d5IGNoYW5nZSBkZXRlY3RlZCwgcHJv
cGFnYXRpbmcKWyAgMzI0LjA2MjQyMF0gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmluZyBmb3J3
YXJkaW5nIHN0YXRlClsgIDMyNC4wNjI0MjNdIGJyMDogcG9ydCAzKHRhcDEuMCkgZW50ZXJpbmcg
Zm9yd2FyZGluZyBzdGF0ZQpbICAzMzQuODE3MTMyXSB0YXAxLjA6IG5vIElQdjYgcm91dGVycyBw
cmVzZW50ClsgIDg3Mi4xMTgyODFdIHFlbXUtZG06IHNlbmRpbmcgaW9jdGwgMTI2MSB0byBhIHBh
cnRpdGlvbiEKWyAgODcyLjEyMTUzNF0gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmluZyBmb3J3
YXJkaW5nIHN0YXRlClsgIDg3Mi4xMjYyOTRdIGJyMDogcG9ydCAzKHRhcDEuMCkgZW50ZXJpbmcg
ZGlzYWJsZWQgc3RhdGUKWyAgODcyLjEyNjMzOF0gYnIwOiBwb3J0IDModGFwMS4wKSBlbnRlcmlu
ZyBkaXNhYmxlZCBzdGF0ZQpbICA4NzMuNzUzNTEzXSB4ZW4tYmxrYmFjazpyaW5nLXJlZiA4LCBl
dmVudC1jaGFubmVsIDUsIHByb3RvY29sIDEgKHg4Nl82NC1hYmkpClsgIDkwOC42NDc1MjddIEFE
RFJDT05GKE5FVERFVl9DSEFOR0UpOiB2aWYxLjA6IGxpbmsgYmVjb21lcyByZWFkeQpbICA5MDgu
NjQ3NTU1XSBicjA6IHRvcG9sb2d5IGNoYW5nZSBkZXRlY3RlZCwgcHJvcGFnYXRpbmcKWyAgOTA4
LjY0NzU1OF0gYnIwOiBwb3J0IDIodmlmMS4wKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlClsg
IDkwOC42NDc1NjFdIGJyMDogcG9ydCAyKHZpZjEuMCkgZW50ZXJpbmcgZm9yd2FyZGluZyBzdGF0
ZQpbICA5MTkuMDczMTI4XSB2aWYxLjA6IG5vIElQdjYgcm91dGVycyBwcmVzZW50Cg==
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="dom0_lspci.txt"
Content-Disposition: attachment; filename="dom0_lspci.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6ey1

MDA6MDAuMCBIb3N0IGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gWGVvbiBFMy0xMjAwIFByb2Nl
c3NvciBGYW1pbHkgRFJBTSBDb250cm9sbGVyIChyZXYgMDkpCglTdWJzeXN0ZW06IFN1cGVyIE1p
Y3JvIENvbXB1dGVyIEluYyBEZXZpY2UgMDYyNAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2
c2VsLCBsYXRlbmN5IDAKCUNhcGFiaWxpdGllczogW2UwXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IExlbj0wYyA8Pz4KCjAwOjAxLjAgUENJIGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24g
WGVvbiBFMy0xMjAwLzJuZCBHZW5lcmF0aW9uIENvcmUgUHJvY2Vzc29yIEZhbWlseSBQQ0kgRXhw
cmVzcyBSb290IFBvcnQgKHJldiAwOSkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJRmxh
Z3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2c2VsLCBsYXRlbmN5IDAKCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTAxLCBzdWJvcmRpbmF0ZT0wMSwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBi
cmlkZ2U6IDAwMDBlMDAwLTAwMDBlZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmJhMDAwMDAt
ZmJhZmZmZmYKCUNhcGFiaWxpdGllczogWzg4XSBTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1
dGVyIEluYyBEZXZpY2UgMDYyNAoJQ2FwYWJpbGl0aWVzOiBbODBdIFBvd2VyIE1hbmFnZW1lbnQg
dmVyc2lvbiAzCglDYXBhYmlsaXRpZXM6IFs5MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNr
YWJsZS0gNjRiaXQtCglDYXBhYmlsaXRpZXM6IFthMF0gRXhwcmVzcyBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwCglDYXBhYmlsaXRpZXM6IFsxMDBdIFZpcnR1YWwgQ2hhbm5lbAoJQ2FwYWJpbGl0
aWVzOiBbMTQwXSBSb290IENvbXBsZXggTGluawoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVw
b3J0CglLZXJuZWwgbW9kdWxlczogc2hwY2hwCgowMDoxOS4wIEV0aGVybmV0IGNvbnRyb2xsZXI6
IEludGVsIENvcnBvcmF0aW9uIDgyNTc5TE0gR2lnYWJpdCBOZXR3b3JrIENvbm5lY3Rpb24gKHJl
diAwNSkKCVN1YnN5c3RlbTogU3VwZXIgTWljcm8gQ29tcHV0ZXIgSW5jIERldmljZSAxNTAyCglG
bGFnczogYnVzIG1hc3RlciwgZmFzdCBkZXZzZWwsIGxhdGVuY3kgMCwgSVJRIDI5MAoJTWVtb3J5
IGF0IGZiYjAwMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTEyOEtdCglNZW1v
cnkgYXQgZmJiMjQwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglJL08g
cG9ydHMgYXQgZjAyMCBbc2l6ZT0zMl0KCUNhcGFiaWxpdGllczogW2M4XSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMgoJQ2FwYWJpbGl0aWVzOiBbZDBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEg
TWFza2FibGUtIDY0Yml0KwoJQ2FwYWJpbGl0aWVzOiBbZTBdIFBDSSBBZHZhbmNlZCBGZWF0dXJl
cwoJS2VybmVsIGRyaXZlciBpbiB1c2U6IGUxMDAwZQoJS2VybmVsIG1vZHVsZXM6IGUxMDAwZQoK
MDA6MWEuMCBVU0IgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRpb24gNiBTZXJpZXMvQzIwMCBT
ZXJpZXMgQ2hpcHNldCBGYW1pbHkgVVNCIEVuaGFuY2VkIEhvc3QgQ29udHJvbGxlciAjMiAocmV2
IDA1KSAocHJvZy1pZiAyMCBbRUhDSV0pCglTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1dGVy
IEluYyBEZXZpY2UgMDYyNAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIG1lZGl1bSBkZXZzZWwsIGxhdGVu
Y3kgMCwgSVJRIDE2CglNZW1vcnkgYXQgZmJiMjMwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs
ZSkgW3NpemU9MUtdCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9u
IDIKCUNhcGFiaWxpdGllczogWzU4XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBhMAoJQ2Fw
YWJpbGl0aWVzOiBbOThdIFBDSSBBZHZhbmNlZCBGZWF0dXJlcwoJS2VybmVsIGRyaXZlciBpbiB1
c2U6IGVoY2lfaGNkCgowMDoxYy4wIFBDSSBicmlkZ2U6IEludGVsIENvcnBvcmF0aW9uIDYgU2Vy
aWVzL0MyMDAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IFBDSSBFeHByZXNzIFJvb3QgUG9ydCAxIChy
ZXYgYjUpIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkKCUZsYWdzOiBidXMgbWFzdGVyLCBm
YXN0IGRldnNlbCwgbGF0ZW5jeSAwCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMiwgc3Vi
b3JkaW5hdGU9MDIsIHNlYy1sYXRlbmN5PTAKCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzIFJv
b3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCUNhcGFiaWxpdGllczogWzgwXSBNU0k6IEVuYWJsZSsg
Q291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0KCUNhcGFiaWxpdGllczogWzkwXSBTdWJzeXN0ZW06
IFN1cGVyIE1pY3JvIENvbXB1dGVyIEluYyBEZXZpY2UgMDYyNAoJQ2FwYWJpbGl0aWVzOiBbYTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQKCUtlcm5lbCBtb2R1bGVzOiBzaHBjaHAKCjAwOjFjLjQgUENJIGJyaWRnZTogSW50ZWwgQ29y
cG9yYXRpb24gNiBTZXJpZXMvQzIwMCBTZXJpZXMgQ2hpcHNldCBGYW1pbHkgUENJIEV4cHJlc3Mg
Um9vdCBQb3J0IDUgKHJldiBiNSkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJRmxhZ3M6
IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2c2VsLCBsYXRlbmN5IDAKCUJ1czogcHJpbWFyeT0wMCwgc2Vj
b25kYXJ5PTAzLCBzdWJvcmRpbmF0ZT0wMywgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlk
Z2U6IDAwMDBkMDAwLTAwMDBkZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmI5MDAwMDAtZmI5
ZmZmZmYKCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kg
MDAKCUNhcGFiaWxpdGllczogWzgwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdC0KCUNhcGFiaWxpdGllczogWzkwXSBTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1dGVy
IEluYyBEZXZpY2UgMDYyNAoJQ2FwYWJpbGl0aWVzOiBbYTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAyCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCUtlcm5lbCBtb2R1bGVzOiBz
aHBjaHAKCjAwOjFkLjAgVVNCIGNvbnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDYgU2VyaWVz
L0MyMDAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IFVTQiBFbmhhbmNlZCBIb3N0IENvbnRyb2xsZXIg
IzEgKHJldiAwNSkgKHByb2ctaWYgMjAgW0VIQ0ldKQoJU3Vic3lzdGVtOiBTdXBlciBNaWNybyBD
b21wdXRlciBJbmMgRGV2aWNlIDA2MjQKCUZsYWdzOiBidXMgbWFzdGVyLCBtZWRpdW0gZGV2c2Vs
LCBsYXRlbmN5IDAsIElSUSAyMwoJTWVtb3J5IGF0IGZiYjIyMDAwICgzMi1iaXQsIG5vbi1wcmVm
ZXRjaGFibGUpIFtzaXplPTFLXQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQg
dmVyc2lvbiAyCglDYXBhYmlsaXRpZXM6IFs1OF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAw
YTAKCUNhcGFiaWxpdGllczogWzk4XSBQQ0kgQWR2YW5jZWQgRmVhdHVyZXMKCUtlcm5lbCBkcml2
ZXIgaW4gdXNlOiBlaGNpX2hjZAoKMDA6MWUuMCBQQ0kgYnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlv
biA4MjgwMSBQQ0kgQnJpZGdlIChyZXYgYTUpIChwcm9nLWlmIDAxIFtTdWJ0cmFjdGl2ZSBkZWNv
ZGVdKQoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2c2VsLCBsYXRlbmN5IDAKCUJ1czogcHJp
bWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0ZT0wNCwgc2VjLWxhdGVuY3k9NjQKCU1l
bW9yeSBiZWhpbmQgYnJpZGdlOiBmYjAwMDAwMC1mYjhmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9y
eSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAwMGZhMDAwMDAwLTAwMDAwMDAwZmFmZmZmZmYKCUNhcGFi
aWxpdGllczogWzUwXSBTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENvbXB1dGVyIEluYyBEZXZpY2Ug
MDYyNAoKMDA6MWYuMCBJU0EgYnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlvbiBDMjA0IENoaXBzZXQg
RmFtaWx5IExQQyBDb250cm9sbGVyIChyZXYgMDUpCglTdWJzeXN0ZW06IFN1cGVyIE1pY3JvIENv
bXB1dGVyIEluYyBEZXZpY2UgMDYyNAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIG1lZGl1bSBkZXZzZWws
IGxhdGVuY3kgMAoJQ2FwYWJpbGl0aWVzOiBbZTBdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlv
bjogTGVuPTBjIDw/PgoJS2VybmVsIG1vZHVsZXM6IGlUQ09fd2R0CgowMDoxZi4yIFJBSUQgYnVz
IGNvbnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDgyODAxIFNBVEEgQ29udHJvbGxlciBbUkFJ
RCBtb2RlXSAocmV2IDA1KQoJU3Vic3lzdGVtOiBTdXBlciBNaWNybyBDb21wdXRlciBJbmMgRGV2
aWNlIDA2MjQKCUZsYWdzOiBidXMgbWFzdGVyLCA2Nk1IeiwgbWVkaXVtIGRldnNlbCwgbGF0ZW5j
eSAwLCBJUlEgMjg5CglJL08gcG9ydHMgYXQgZjA3MCBbc2l6ZT04XQoJSS9PIHBvcnRzIGF0IGYw
NjAgW3NpemU9NF0KCUkvTyBwb3J0cyBhdCBmMDUwIFtzaXplPThdCglJL08gcG9ydHMgYXQgZjA0
MCBbc2l6ZT00XQoJSS9PIHBvcnRzIGF0IGYwMDAgW3NpemU9MzJdCglNZW1vcnkgYXQgZmJiMjEw
MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MktdCglDYXBhYmlsaXRpZXM6IFs4
MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCglDYXBhYmlsaXRpZXM6
IFs3MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCUNhcGFiaWxpdGllczogW2E4XSBTQVRB
IEhCQSB2MS4wCglDYXBhYmlsaXRpZXM6IFtiMF0gUENJIEFkdmFuY2VkIEZlYXR1cmVzCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogYWhjaQoKMDA6MWYuMyBTTUJ1czogSW50ZWwgQ29ycG9yYXRpb24g
NiBTZXJpZXMvQzIwMCBTZXJpZXMgQ2hpcHNldCBGYW1pbHkgU01CdXMgQ29udHJvbGxlciAocmV2
IDA1KQoJU3Vic3lzdGVtOiBTdXBlciBNaWNybyBDb21wdXRlciBJbmMgRGV2aWNlIDA2MjQKCUZs
YWdzOiBtZWRpdW0gZGV2c2VsLCBJUlEgMTEKCU1lbW9yeSBhdCBmYmIyMDAwMCAoNjQtYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdCglJL08gcG9ydHMgYXQgMTE4MCBbc2l6ZT0zMl0K
CUtlcm5lbCBtb2R1bGVzOiBpMmMtaTgwMQoKMDE6MDAuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBj
b250cm9sbGVyOiBMU0kgTG9naWMgLyBTeW1iaW9zIExvZ2ljIFNBUzIwMDggUENJLUV4cHJlc3Mg
RnVzaW9uLU1QVCBTQVMtMiBbRmFsY29uXSAocmV2IDAzKQoJU3Vic3lzdGVtOiBMU0kgTG9naWMg
LyBTeW1iaW9zIExvZ2ljIERldmljZSAzMDIwCglGbGFnczogZmFzdCBkZXZzZWwsIElSUSAxNgoJ
SS9PIHBvcnRzIGF0IGUwMDAgW3NpemU9MjU2XQoJTWVtb3J5IGF0IGZiYWMwMDAwICg2NC1iaXQs
IG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2S10KCU1lbW9yeSBhdCBmYmE4MDAwMCAoNjQtYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZLXQoJRXhwYW5zaW9uIFJPTSBhdCBmYmEwMDAw
MCBbZGlzYWJsZWRdIFtzaXplPTUxMktdCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMKCUNhcGFiaWxpdGllczogWzY4XSBFeHByZXNzIEVuZHBvaW50LCBNU0kg
MDAKCUNhcGFiaWxpdGllczogW2QwXSBWaXRhbCBQcm9kdWN0IERhdGEKCUNhcGFiaWxpdGllczog
W2E4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsKCUNhcGFiaWxpdGll
czogW2MwXSBNU0ktWDogRW5hYmxlLSBDb3VudD0xNSBNYXNrZWQtCglDYXBhYmlsaXRpZXM6IFsx
MDBdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJQ2FwYWJpbGl0aWVzOiBbMTM4XSBQb3dlciBC
dWRnZXRpbmcgPD8+CglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoJS2VybmVsIG1vZHVs
ZXM6IG1wdDJzYXMKCjAzOjAwLjAgRXRoZXJuZXQgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRp
b24gODI1NzRMIEdpZ2FiaXQgTmV0d29yayBDb25uZWN0aW9uCglTdWJzeXN0ZW06IFN1cGVyIE1p
Y3JvIENvbXB1dGVyIEluYyBEZXZpY2UgMDAwMAoJRmxhZ3M6IGJ1cyBtYXN0ZXIsIGZhc3QgZGV2
c2VsLCBsYXRlbmN5IDAsIElSUSAxNgoJTWVtb3J5IGF0IGZiOTAwMDAwICgzMi1iaXQsIG5vbi1w
cmVmZXRjaGFibGUpIFtzaXplPTEyOEtdCglJL08gcG9ydHMgYXQgZDAwMCBbc2l6ZT0zMl0KCU1l
bW9yeSBhdCBmYjkyMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdCglD
YXBhYmlsaXRpZXM6IFtjOF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCUNhcGFiaWxpdGll
czogW2QwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsKCUNhcGFiaWxp
dGllczogW2UwXSBFeHByZXNzIEVuZHBvaW50LCBNU0kgMDAKCUNhcGFiaWxpdGllczogW2EwXSBN
U0ktWDogRW5hYmxlKyBDb3VudD01IE1hc2tlZC0KCUNhcGFiaWxpdGllczogWzEwMF0gQWR2YW5j
ZWQgRXJyb3IgUmVwb3J0aW5nCglDYXBhYmlsaXRpZXM6IFsxNDBdIERldmljZSBTZXJpYWwgTnVt
YmVyIDAwLTI1LTkwLWZmLWZmLTU3LTlkLTVlCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZTEwMDBl
CglLZXJuZWwgbW9kdWxlczogZTEwMDBlCgowNDowMy4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xs
ZXI6IE1hdHJveCBHcmFwaGljcywgSW5jLiBNR0EgRzIwMGVXIFdQQ000NTAgKHJldiAwYSkgKHBy
b2ctaWYgMDAgW1ZHQSBjb250cm9sbGVyXSkKCVN1YnN5c3RlbTogU3VwZXIgTWljcm8gQ29tcHV0
ZXIgSW5jIERldmljZSAwNjI0CglGbGFnczogYnVzIG1hc3RlciwgbWVkaXVtIGRldnNlbCwgbGF0
ZW5jeSA2NCwgSVJRIDUKCU1lbW9yeSBhdCBmYTAwMDAwMCAoMzItYml0LCBwcmVmZXRjaGFibGUp
IFtzaXplPTE2TV0KCU1lbW9yeSBhdCBmYjgwMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxl
KSBbc2l6ZT0xNktdCglNZW1vcnkgYXQgZmIwMDAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs
ZSkgW3NpemU9OE1dCglFeHBhbnNpb24gUk9NIGF0IDx1bmFzc2lnbmVkPiBbZGlzYWJsZWRdCglD
YXBhYmlsaXRpZXM6IFtkY10gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDEKCg==
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="pvhvm_dmesg.txt"
Content-Disposition: attachment; filename="pvhvm_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6gl2

SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vi
c3lzIGNwdQpMaW51eCB2ZXJzaW9uIDIuNi4zMi0yMjAuNy4xLmVsNi54ODZfNjQgKG1vY2tidWls
ZEBjNmIxOG4zLmJzeXMuZGV2LmNlbnRvcy5vcmcpIChnY2MgdmVyc2lvbiA0LjQuNiAyMDExMDcz
MSAoUmVkIEhhdCA0LjQuNi0zKSAoR0NDKSApICMxIFNNUCBXZWQgTWFyIDcgMDA6NTI6MDIgR01U
IDIwMTIKQ29tbWFuZCBsaW5lOiBybyByb290PVVVSUQ9ZjNiZTA0MTEtOTA3ZS00OGFlLWI4Njct
ZjIzMjU0Mjg5MDZiIHJkX05PX0xVS1MgcmRfTk9fTFZNIExBTkc9ZW5fVVMuVVRGLTggcmRfTk9f
TUQgU1lTRk9OVD1sYXRhcmN5cmhlYi1zdW4xNiByaGdiIGNyYXNoa2VybmVsPWF1dG8gIEtFWUJP
QVJEVFlQRT1wYyBLRVlUQUJMRT11cyByZF9OT19ETQpLRVJORUwgc3VwcG9ydGVkIGNwdXM6CiAg
SW50ZWwgR2VudWluZUludGVsCiAgQU1EIEF1dGhlbnRpY0FNRAogIENlbnRhdXIgQ2VudGF1ckhh
dWxzCkJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKIEJJT1MtZTgyMDogMDAwMDAwMDAw
MDAwMDAwMCAtIDAwMDAwMDAwMDAwOWUwMDAgKHVzYWJsZSkKIEJJT1MtZTgyMDogMDAwMDAwMDAw
MDA5ZTAwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQogQklPUy1lODIwOiAwMDAwMDAw
MDAwMGUwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCiBCSU9TLWU4MjA6IDAwMDAw
MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2FibGUpCiBCSU9TLWU4MjA6IDAwMDAw
MDAwZmMwMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKRE1JIDIuNCBwcmVzZW50
LgpTTUJJT1MgdmVyc2lvbiAyLjQgQCAweEZCQjgwCkRNSTogWGVuIEhWTSBkb21VLCBCSU9TIDQu
MS4zLXJjMS1wcmUgMDMvMDgvMjAxMgplODIwIHVwZGF0ZSByYW5nZTogMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwMDEwMDAgKHVzYWJsZSkgPT0+IChyZXNlcnZlZCkKZTgyMCByZW1vdmUg
cmFuZ2U6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwICh1c2FibGUpCmxhc3Rf
cGZuID0gMHg4MDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApNVFJSIGRlZmF1bHQgdHlw
ZTogd3JpdGUtYmFjawpNVFJSIGZpeGVkIHJhbmdlcyBlbmFibGVkOgogIDAwMDAwLTlGRkZGIHdy
aXRlLWJhY2sKICBBMDAwMC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKICBDMDAwMC1GRkZGRiB3cml0
ZS1iYWNrCk1UUlIgdmFyaWFibGUgcmFuZ2VzIGVuYWJsZWQ6CiAgMCBiYXNlIDBGMDAwMDAwMCBt
YXNrIEZGODAwMDAwMCB1bmNhY2hhYmxlCiAgMSBiYXNlIDBGODAwMDAwMCBtYXNrIEZGQzAwMDAw
MCB1bmNhY2hhYmxlCiAgMiBkaXNhYmxlZAogIDMgZGlzYWJsZWQKICA0IGRpc2FibGVkCiAgNSBk
aXNhYmxlZAogIDYgZGlzYWJsZWQKICA3IGRpc2FibGVkCng4NiBQQVQgZW5hYmxlZDogY3B1IDAs
IG9sZCAweDcwNDA2MDAwNzA0MDYsIG5ldyAweDcwMTA2MDAwNzAxMDYKaW5pdGlhbCBtZW1vcnkg
bWFwcGVkIDogMCAtIDIwMDAwMDAwCmluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAw
MDAtMDAwMDAwMDA4MDAwMDAwMAogMDAwMDAwMDAwMCAtIDAwODAwMDAwMDAgcGFnZSAyTQprZXJu
ZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDgwMDAwMDAwIEAgODAwMC1iMDAwClJBTURJ
U0s6IDM3MTFjMDAwIC0gMzdmZWY5ODAKQUNQSTogUlNEUCAwMDAwMDAwMDAwMGVhMDIwIDAwMDI0
ICh2MDIgICAgWGVuKQpBQ1BJOiBYU0RUIDAwMDAwMDAwZmMwMTM0YjAgMDAwMzQgKHYwMSAgICBY
ZW4gICAgICBIVk0gMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKQUNQSTogRkFDUCAwMDAwMDAwMGZj
MDEzMmQwIDAwMEY0ICh2MDQgICAgWGVuICAgICAgSFZNIDAwMDAwMDAwIEhWTUwgMDAwMDAwMDAp
CkFDUEk6IERTRFQgMDAwMDAwMDBmYzAwMzQ0MCAwRkUwNSAodjAyICAgIFhlbiAgICAgIEhWTSAw
MDAwMDAwMCBJTlRMIDIwMTAwNTI4KQpBQ1BJOiBGQUNTIDAwMDAwMDAwZmMwMDM0MDAgMDAwNDAK
QUNQSTogQVBJQyAwMDAwMDAwMGZjMDEzM2QwIDAwMEQ4ICh2MDIgICAgWGVuICAgICAgSFZNIDAw
MDAwMDAwIEhWTUwgMDAwMDAwMDApCkFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAw
Ck5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZApGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAw
MDAwMDAtMDAwMDAwMDA4MDAwMDAwMApCb290bWVtIHNldHVwIG5vZGUgMCAwMDAwMDAwMDAwMDAw
MDAwLTAwMDAwMDAwODAwMDAwMDAKICBOT0RFX0RBVEEgWzAwMDAwMDAwMDAwMDkwMDAgLSAwMDAw
MDAwMDAwMDNjZmZmXQogIGJvb3RtYXAgWzAwMDAwMDAwMDAwM2QwMDAgLSAgMDAwMDAwMDAwMDA0
Y2ZmZl0gcGFnZXMgMTAKKDcgZWFybHkgcmVzZXJ2YXRpb25zKSA9PT4gYm9vdG1lbSBbMDAwMDAw
MDAwMCAtIDAwODAwMDAwMDBdCiAgIzAgWzAwMDAwMDAwMDAgLSAwMDAwMDAxMDAwXSAgIEJJT1Mg
ZGF0YSBwYWdlID09PiBbMDAwMDAwMDAwMCAtIDAwMDAwMDEwMDBdCiAgIzEgWzAwMDAwMDYwMDAg
LSAwMDAwMDA4MDAwXSAgICAgICBUUkFNUE9MSU5FID09PiBbMDAwMDAwNjAwMCAtIDAwMDAwMDgw
MDBdCiAgIzIgWzAwMDEwMDAwMDAgLSAwMDAyMDBjODI0XSAgICBURVhUIERBVEEgQlNTID09PiBb
MDAwMTAwMDAwMCAtIDAwMDIwMGM4MjRdCiAgIzMgWzAwMzcxMWMwMDAgLSAwMDM3ZmVmOTgwXSAg
ICAgICAgICBSQU1ESVNLID09PiBbMDAzNzExYzAwMCAtIDAwMzdmZWY5ODBdCiAgIzQgWzAwMDAw
OWUwMDAgLSAwMDAwMTAwMDAwXSAgICBCSU9TIHJlc2VydmVkID09PiBbMDAwMDA5ZTAwMCAtIDAw
MDAxMDAwMDBdCiAgIzUgWzAwMDIwMGQwMDAgLSAwMDAyMDBkMGQ4XSAgICAgICAgICAgICAgQlJL
ID09PiBbMDAwMjAwZDAwMCAtIDAwMDIwMGQwZDhdCiAgIzYgWzAwMDAwMDgwMDAgLSAwMDAwMDA5
MDAwXSAgICAgICAgICBQR1RBQkxFID09PiBbMDAwMDAwODAwMCAtIDAwMDAwMDkwMDBdCmZvdW5k
IFNNUCBNUC10YWJsZSBhdCBbZmZmZjg4MDAwMDBmYmM5MF0gZmJjOTAKIFtmZmZmZWEwMDAwMDAw
MDAwLWZmZmZlYTAwMDFiZmZmZmZdIFBNRCAtPiBbZmZmZjg4MDAwMjYwMDAwMC1mZmZmODgwMDA0
MWZmZmZmXSBvbiBub2RlIDAKWm9uZSBQRk4gcmFuZ2VzOgogIERNQSAgICAgIDB4MDAwMDAwMDEg
LT4gMHgwMDAwMTAwMAogIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgwMDEwMDAwMAogIE5vcm1h
bCAgIDB4MDAxMDAwMDAgLT4gMHgwMDEwMDAwMApNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBl
YWNoIG5vZGUKZWFybHlfbm9kZV9tYXBbMl0gYWN0aXZlIFBGTiByYW5nZXMKICAgIDA6IDB4MDAw
MDAwMDEgLT4gMHgwMDAwMDA5ZQogICAgMDogMHgwMDAwMDEwMCAtPiAweDAwMDgwMDAwCk9uIG5v
ZGUgMCB0b3RhbHBhZ2VzOiA1MjQxODkKICBETUEgem9uZTogNTYgcGFnZXMgdXNlZCBmb3IgbWVt
bWFwCiAgRE1BIHpvbmU6IDEwMiBwYWdlcyByZXNlcnZlZAogIERNQSB6b25lOiAzODM5IHBhZ2Vz
LCBMSUZPIGJhdGNoOjAKICBETUEzMiB6b25lOiA3MTEyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcAog
IERNQTMyIHpvbmU6IDUxMzA4MCBwYWdlcywgTElGTyBiYXRjaDozMQpBQ1BJOiBQTS1UaW1lciBJ
TyBQb3J0OiAweGIwMDgKQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgwMl0gbGFwaWNfaWRbMHgwNF0gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4
MDNdIGxhcGljX2lkWzB4MDZdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBs
YXBpY19pZFsweDA4XSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNf
aWRbMHgwYV0gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4
MGNdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDBlXSBk
aXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHgxMF0gZGlzYWJs
ZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MTJdIGRpc2FibGVkKQpB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDBhXSBsYXBpY19pZFsweDE0XSBkaXNhYmxlZCkKQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwYl0gbGFwaWNfaWRbMHgxNl0gZGlzYWJsZWQpCkFDUEk6IExBUElD
IChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4MThdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDBkXSBsYXBpY19pZFsweDFhXSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwZV0gbGFwaWNfaWRbMHgxY10gZGlzYWJsZWQpCkFDUEk6IElPQVBJQyAoaWRbMHgwMV0gYWRk
cmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKSU9BUElDWzBdOiBhcGljX2lkIDEsIHZlcnNp
b24gMTcsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtNDcKQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgNSBnbG9iYWxfaXJxIDUgbG93IGxldmVsKQpBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAxMCBnbG9iYWxfaXJxIDEwIGxvdyBsZXZlbCkKQUNQSTogSU5UX1NSQ19P
VlIgKGJ1cyAwIGJ1c19pcnEgMTEgZ2xvYmFsX2lycSAxMSBsb3cgbGV2ZWwpCkFDUEk6IElSUTAg
dXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlE1
IHVzZWQgYnkgb3ZlcnJpZGUuCkFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJR
MTAgdXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJRMTEgdXNlZCBieSBvdmVycmlkZS4KVXNpbmcg
QUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uClNNUDogQWxsb3dp
bmcgMTUgQ1BVcywgMTMgaG90cGx1ZyBDUFVzCm5yX2lycXNfZ3NpOiA0OApYZW4gdmVyc2lvbiA0
LjEuClhlbiBQbGF0Zm9ybSBQQ0k6IEkvTyBwcm90b2NvbCB2ZXJzaW9uIDEKTmV0ZnJvbnQgYW5k
IHRoZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGlsZWQgZm9yIHRoaXMg
a2VybmVsOiB1bnBsdWcgZW11bGF0ZWQgTklDcy4KQmxrZnJvbnQgYW5kIHRoZSBYZW4gcGxhdGZv
cm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGlsZWQgZm9yIHRoaXMga2VybmVsOiB1bnBsdWcg
ZW11bGF0ZWQgZGlza3MuCllvdSBtaWdodCBoYXZlIHRvIGNoYW5nZSB0aGUgcm9vdCBkZXZpY2UK
ZnJvbSAvZGV2L2hkW2EtZF0gdG8gL2Rldi94dmRbYS1kXQppbiB5b3VyIHJvb3Q9IGtlcm5lbCBj
b21tYW5kIGxpbmUgb3B0aW9uClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw
MDAwOWUwMDAgLSAwMDAwMDAwMDAwMGEwMDAwClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMGUwMDAwClBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwCkFsbG9jYXRpbmcg
UENJIHJlc291cmNlcyBzdGFydGluZyBhdCA4MDAwMDAwMCAoZ2FwOiA4MDAwMDAwMDo3YzAwMDAw
MCkKQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpOUl9DUFVTOjQwOTYgbnJf
Y3B1bWFza19iaXRzOjE1IG5yX2NwdV9pZHM6MTUgbnJfbm9kZV9pZHM6MQpQRVJDUFU6IEVtYmVk
ZGVkIDMwIHBhZ2VzL2NwdSBAZmZmZjg4MDAwMjIwMDAwMCBzOTI2MzIgcjgxOTIgZDIyMDU2IHUx
MzEwNzIKcGNwdS1hbGxvYzogczkyNjMyIHI4MTkyIGQyMjA1NiB1MTMxMDcyIGFsbG9jPTEqMjA5
NzE1MgpwY3B1LWFsbG9jOiBbMF0gMDAgMDEgMDIgMDMgMDQgMDUgMDYgMDcgMDggMDkgMTAgMTEg
MTIgMTMgMTQgLS0gCkJ1aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdy
b3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDUxNjkxOQpQb2xpY3kgem9uZTogRE1BMzIKS2VybmVs
IGNvbW1hbmQgbGluZTogcm8gcm9vdD1VVUlEPWYzYmUwNDExLTkwN2UtNDhhZS1iODY3LWYyMzI1
NDI4OTA2YiByZF9OT19MVUtTIHJkX05PX0xWTSBMQU5HPWVuX1VTLlVURi04IHJkX05PX01EIFNZ
U0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgcmhnYiAgIEtFWUJPQVJEVFlQRT1wYyBLRVlUQUJMRT11
cyByZF9OT19ETQpQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3Njgg
Ynl0ZXMpCkNoZWNraW5nIGFwZXJ0dXJlLi4uCk5vIEFHUCBicmlkZ2UgZm91bmQKTWVtb3J5OiAy
MDM0MTUyay8yMDk3MTUyayBhdmFpbGFibGUgKDUwODRrIGtlcm5lbCBjb2RlLCAzOTZrIGFic2Vu
dCwgNjI2MDRrIHJlc2VydmVkLCA3MjI5ayBkYXRhLCAxMjQ0ayBpbml0KQpIaWVyYXJjaGljYWwg
UkNVIGltcGxlbWVudGF0aW9uLgpOUl9JUlFTOjMzMDI0IG5yX2lycXM6OTM2ClhlbiBIVk0gY2Fs
bGJhY2sgdmVjdG9yIGZvciBldmVudCBkZWxpdmVyeSBpcyBlbmFibGVkCkNvbnNvbGU6IGNvbG91
ciBWR0ErIDgweDI1CmNvbnNvbGUgW3R0eTBdIGVuYWJsZWQKYWxsb2NhdGVkIDE2Nzc3MjE2IGJ5
dGVzIG9mIHBhZ2VfY2dyb3VwCnBsZWFzZSB0cnkgJ2Nncm91cF9kaXNhYmxlPW1lbW9yeScgb3B0
aW9uIGlmIHlvdSBkb24ndCB3YW50IG1lbW9yeSBjZ3JvdXBzCkZhc3QgVFNDIGNhbGlicmF0aW9u
IHVzaW5nIFBJVApEZXRlY3RlZCAzMTkzLjA1OSBNSHogcHJvY2Vzc29yLgpDYWxpYnJhdGluZyBk
ZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVxdWVu
Y3kuLiA2Mzg2LjExIEJvZ29NSVBTIChscGo9MzE5MzA1OSkKcGlkX21heDogZGVmYXVsdDogMzI3
NjggbWluaW11bTogMzAxClNlY3VyaXR5IEZyYW1ld29yayBpbml0aWFsaXplZApTRUxpbnV4OiAg
SW5pdGlhbGl6aW5nLgpTRUxpbnV4OiAgU3RhcnRpbmcgaW4gcGVybWlzc2l2ZSBtb2RlCkRlbnRy
eSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI2MjE0NCAob3JkZXI6IDksIDIwOTcxNTIgYnl0
ZXMpCklub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogOCwgMTA0
ODU3NiBieXRlcykKTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKSW5pdGlhbGl6
aW5nIGNncm91cCBzdWJzeXMgbnMKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdApJ
bml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1vcnkKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJz
eXMgZGV2aWNlcwpJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyCkluaXRpYWxpemlu
ZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgYmxraW8K
SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgcGVyZl9ldmVudApDUFU6IENQVSBmZWF0dXJlIHJk
dHNjcCBkaXNhYmxlZCBvbiB4ZW4gZ3Vlc3QKQ1BVOiBDUFUgZmVhdHVyZSBjb25zdGFudF90c2Mg
ZGlzYWJsZWQgb24geGVuIGd1ZXN0CkNQVTogVW5zdXBwb3J0ZWQgbnVtYmVyIG9mIHNpYmxpbmdz
IDMyCm1jZTogQ1BVIHN1cHBvcnRzIDkgTUNFIGJhbmtzCmFsdGVybmF0aXZlczogc3dpdGNoaW5n
IHRvIHVuZmFpciBzcGlubG9jawpBQ1BJOiBDb3JlIHJldmlzaW9uIDIwMDkwOTAzCmZ0cmFjZTog
Y29udmVydGluZyBtY291bnQgY2FsbHMgdG8gMGYgMWYgNDQgMDAgMDAKZnRyYWNlOiBhbGxvY2F0
aW5nIDIwNzgyIGVudHJpZXMgaW4gODIgcGFnZXMKeDJhcGljIG5vdCBlbmFibGVkLCBJUlEgcmVt
YXBwaW5nIGluaXQgZmFpbGVkClNldHRpbmcgQVBJQyByb3V0aW5nIHRvIHBoeXNpY2FsIGZsYXQK
Li5USU1FUjogdmVjdG9yPTB4MzAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9MCBwaW4yPTAKQ1BVMDog
SW50ZWwoUikgWGVvbihSKSBDUFUgRTMxMjMwIEAgMy4yMEdIeiBzdGVwcGluZyAwNwpQZXJmb3Jt
YW5jZSBFdmVudHM6IHVuc3VwcG9ydGVkIHA2IENQVSBtb2RlbCA0MiBubyBQTVUgZHJpdmVyLCBz
b2Z0d2FyZSBldmVudHMgb25seS4KTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUwKTogaGFyZHdh
cmUgZXZlbnRzIG5vdCBlbmFibGVkCkJvb3RpbmcgTm9kZSAgIDAsIFByb2Nlc3NvcnMgICMxCkNQ
VTogQ1BVIGZlYXR1cmUgcmR0c2NwIGRpc2FibGVkIG9uIHhlbiBndWVzdApDUFU6IENQVSBmZWF0
dXJlIGNvbnN0YW50X3RzYyBkaXNhYmxlZCBvbiB4ZW4gZ3Vlc3QKQ1BVOiBVbnN1cHBvcnRlZCBu
dW1iZXIgb2Ygc2libGluZ3MgMzIKQnJvdWdodCB1cCAyIENQVXMKVG90YWwgb2YgMiBwcm9jZXNz
b3JzIGFjdGl2YXRlZCAoMTI3NzAuNzkgQm9nb01JUFMpLgpzaXplb2Yodm1hKT0yMDAgYnl0ZXMK
c2l6ZW9mKHBhZ2UpPTU2IGJ5dGVzCnNpemVvZihpbm9kZSk9NTkyIGJ5dGVzCnNpemVvZihkZW50
cnkpPTE5MiBieXRlcwpzaXplb2YoZXh0M2lub2RlKT04MDAgYnl0ZXMKc2l6ZW9mKGJ1ZmZlcl9o
ZWFkKT0xMDQgYnl0ZXMKc2l6ZW9mKHNrYnVmZik9MjMyIGJ5dGVzCnNpemVvZih0YXNrX3N0cnVj
dCk9MjYxNiBieXRlcwpkZXZ0bXBmczogaW5pdGlhbGl6ZWQKcmVndWxhdG9yOiBjb3JlIHZlcnNp
b24gMC41Ck5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKICBhbGxvYyBpcnFfZGVz
YyBmb3IgMTYgb24gbm9kZSAwCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKQUNQSTogYnVz
IHR5cGUgcGNpIHJlZ2lzdGVyZWQKUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3Ig
YmFzZSBhY2Nlc3MKYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKQUNQSTogRUM6IExvb2sg
dXAgRUMgaW4gRFNEVApBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkCkFDUEk6IChzdXBwb3J0cyBT
MCBTMyBTNCBTNSkKQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZwpBQ1BJ
OiBObyBkb2NrIGRldmljZXMgZm91bmQuCkhFU1Q6IFRhYmxlIG5vdCBmb3VuZC4KQUNQSTogUENJ
IFJvb3QgQnJpZGdlIFtQQ0kwXSAoMDAwMDowMCkKcGNpIDAwMDA6MDA6MDEuMTogcmVnIDIwIGlv
IHBvcnQ6IFsweGMyNjAtMHhjMjZmXQpwY2kgMDAwMDowMDowMS4yOiByZWcgMjAgaW8gcG9ydDog
WzB4YzI0MC0weGMyNWZdCiogRm91bmQgUE0tVGltZXIgQnVnIG9uIHRoZSBjaGlwc2V0LiBEdWUg
dG8gd29ya2Fyb3VuZHMgZm9yIGEgYnVnLAoqIHRoaXMgY2xvY2sgc291cmNlIGlzIHNsb3cuIENv
bnNpZGVyIHRyeWluZyBvdGhlciBjbG9jayBzb3VyY2VzCnBjaSAwMDAwOjAwOjAxLjM6IHF1aXJr
OiByZWdpb24gYjAwMC1iMDNmIGNsYWltZWQgYnkgUElJWDQgQUNQSQpwY2kgMDAwMDowMDowMi4w
OiByZWcgMTAgMzJiaXQgbW1pbyBwcmVmOiBbMHhmMDAwMDAwMC0weGYxZmZmZmZmXQpwY2kgMDAw
MDowMDowMi4wOiByZWcgMTQgMzJiaXQgbW1pbzogWzB4ZjMwZTQwMDAtMHhmMzBlNGZmZl0KcGNp
IDAwMDA6MDA6MDMuMDogcmVnIDEwIGlvIHBvcnQ6IFsweGMwMDAtMHhjMGZmXQpwY2kgMDAwMDow
MDowMy4wOiByZWcgMTQgMzJiaXQgbW1pbyBwcmVmOiBbMHhmMjAwMDAwMC0weGYyZmZmZmZmXQpw
Y2kgMDAwMDowMDowNS4wOiByZWcgMTAgaW8gcG9ydDogWzB4YzEwMC0weGMxZmZdCnBjaSAwMDAw
OjAwOjA1LjA6IHJlZyAxNCA2NGJpdCBtbWlvOiBbMHhmMzBlMDAwMC0weGYzMGUzZmZmXQpwY2kg
MDAwMDowMDowNS4wOiByZWcgMWMgNjRiaXQgbW1pbzogWzB4ZjMwODAwMDAtMHhmMzBiZmZmZl0K
cGNpIDAwMDA6MDA6MDUuMDogcmVnIDMwIDMyYml0IG1taW8gcHJlZjogWzB4ZjMwMDAwMDAtMHhm
MzA3ZmZmZl0KcGNpIDAwMDA6MDA6MDUuMDogc3VwcG9ydHMgRDEgRDIKQUNQSTogUENJIEludGVy
cnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLl9QUlRdCkFDUEk6IFBDSSBJbnRlcnJ1cHQg
TGluayBbTE5LQV0gKElSUXMgKjUgMTAgMTEpCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L
Ql0gKElSUXMgNSAqMTAgMTEpCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQ10gKElSUXMg
NSAxMCAqMTEpCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElSUXMgKjUgMTAgMTEp
CnZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6MDAwMDowMDowMi4wLGRlY29kZXM9aW8rbWVtLG93
bnM9aW8rbWVtLGxvY2tzPW5vbmUKdmdhYXJiOiBsb2FkZWQKdmdhYXJiOiBicmlkZ2UgY29udHJv
bCBwb3NzaWJsZSAwMDAwOjAwOjAyLjAKU0NTSSBzdWJzeXN0ZW0gaW5pdGlhbGl6ZWQKbGliYXRh
IHZlcnNpb24gMy4wMCBsb2FkZWQuCnVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgdXNiZnMKdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBodWIK
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2IKUENJOiBVc2luZyBBQ1BJ
IGZvciBJUlEgcm91dGluZwpQQ0k6IG9sZCBjb2RlIHdvdWxkIGhhdmUgc2V0IGNhY2hlbGluZSBz
aXplIHRvIDMyIGJ5dGVzLCBidXQgY2xmbHVzaF9zaXplID0gNjQKUENJOiBwY2lfY2FjaGVfbGlu
ZV9zaXplIHNldCB0byA2NCBieXRlcwpOZXRMYWJlbDogSW5pdGlhbGl6aW5nCk5ldExhYmVsOiAg
ZG9tYWluIGhhc2ggc2l6ZSA9IDEyOApOZXRMYWJlbDogIHByb3RvY29scyA9IFVOTEFCRUxFRCBD
SVBTT3Y0Ck5ldExhYmVsOiAgdW5sYWJlbGVkIHRyYWZmaWMgYWxsb3dlZCBieSBkZWZhdWx0ClN3
aXRjaGluZyB0byBjbG9ja3NvdXJjZSBqaWZmaWVzCnBucDogUG5QIEFDUEkgaW5pdApBQ1BJOiBi
dXMgdHlwZSBwbnAgcmVnaXN0ZXJlZApwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMiBkZXZpY2VzCkFD
UEk6IEFDUEkgYnVzIHR5cGUgcG5wIHVucmVnaXN0ZXJlZApzeXN0ZW0gMDA6MDA6IGlvbWVtIHJh
bmdlIDB4MC0weDlmZmZmIGNvdWxkIG5vdCBiZSByZXNlcnZlZApzeXN0ZW0gMDA6MDI6IGlvcG9y
dCByYW5nZSAweDEwYzAtMHgxMTQxIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowMjogaW9w
b3J0IHJhbmdlIDB4YjA0NC0weGIwNDcgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjAzOiBp
b3BvcnQgcmFuZ2UgMHg4YTAtMHg4YTMgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjAzOiBp
b3BvcnQgcmFuZ2UgMHhjYzAtMHhjY2YgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjAzOiBp
b3BvcnQgcmFuZ2UgMHg0ZDAtMHg0ZDEgaGFzIGJlZW4gcmVzZXJ2ZWQKU3dpdGNoaW5nIHRvIGNs
b2Nrc291cmNlIGFjcGlfcG0KcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAwIGlvOiAgWzB4MDAt
MHhmZmZmXQpwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDEgbWVtOiBbMHgwMDAwMDAtMHhmZmZm
ZmZmZmZmZmZmZmZmXQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDIKSVAgcm91dGUg
Y2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykK
VENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogMTAsIDQx
OTQzMDQgYnl0ZXMpClRDUCBiaW5kIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA4
LCAxMDQ4NTc2IGJ5dGVzKQpUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVk
IDI2MjE0NCBiaW5kIDY1NTM2KQpUQ1AgcmVubyByZWdpc3RlcmVkCk5FVDogUmVnaXN0ZXJlZCBw
cm90b2NvbCBmYW1pbHkgMQpwY2kgMDAwMDowMDowMC4wOiBMaW1pdGluZyBkaXJlY3QgUENJL1BD
SSB0cmFuc2ZlcnMKcGNpIDAwMDA6MDA6MDEuMDogUElJWDM6IEVuYWJsaW5nIFBhc3NpdmUgUmVs
ZWFzZQpwY2kgMDAwMDowMDowMS4wOiBBY3RpdmF0aW5nIElTQSBETUEgaGFuZyB3b3JrYXJvdW5k
cwpwY2kgMDAwMDowMDowMi4wOiBCb290IHZpZGVvIGRldmljZQpUcnlpbmcgdG8gdW5wYWNrIHJv
b3RmcyBpbWFnZSBhcyBpbml0cmFtZnMuLi4KRnJlZWluZyBpbml0cmQgbWVtb3J5OiAxNTE4Mmsg
ZnJlZWQKYXVkaXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHNvY2tldCAoZGlzYWJsZWQpCnR5cGU9
MjAwMCBhdWRpdCgxMzM0MTY5ODMwLjcwMzoxKTogaW5pdGlhbGl6ZWQKSHVnZVRMQiByZWdpc3Rl
cmVkIDIgTUIgcGFnZSBzaXplLCBwcmUtYWxsb2NhdGVkIDAgcGFnZXMKVkZTOiBEaXNrIHF1b3Rh
cyBkcXVvdF82LjUuMgpEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXIg
MCwgNDA5NiBieXRlcykKbXNnbW5pIGhhcyBiZWVuIHNldCB0byA0MDAyClNFTGludXg6ICBSZWdp
c3RlcmluZyBuZXRmaWx0ZXIgaG9va3MKYWxnOiBObyB0ZXN0IGZvciBzdGRybmcgKGtybmcpCmtz
aWduOiBJbnN0YWxsaW5nIHB1YmxpYyBrZXkgZGF0YQpMb2FkaW5nIGtleXJpbmcKLSBBZGRlZCBw
dWJsaWMga2V5IDhBRDIyRUNFNDQxQjcxODAKLSBVc2VyIElEOiBDZW50T1MgKEtlcm5lbCBNb2R1
bGUgR1BHIGtleSkKQmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2ZXJzaW9u
IDAuNCBsb2FkZWQgKG1ham9yIDI1MikKaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZAppbyBz
Y2hlZHVsZXIgYW50aWNpcGF0b3J5IHJlZ2lzdGVyZWQKaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJl
Z2lzdGVyZWQKaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZhdWx0KQpwY2lfaG90cGx1
ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpwY2llaHA6IFBDSSBFeHByZXNz
IEhvdCBQbHVnIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNAphY3BpcGhwOiBBQ1BJIEhv
dCBQbHVnIFBDSSBDb250cm9sbGVyIERyaXZlciB2ZXJzaW9uOiAwLjUKYWNwaXBocDogU2xvdCBb
MF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3Qg
WzJdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xvdCBbM10gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90
IFs0XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzVdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xv
dCBbNl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFs3XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNs
b3QgWzhdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xvdCBbOV0gcmVnaXN0ZXJlZAphY3BpcGhwOiBT
bG90IFsxMF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxMV0gcmVnaXN0ZXJlZAphY3BpcGhw
OiBTbG90IFsxMl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxM10gcmVnaXN0ZXJlZAphY3Bp
cGhwOiBTbG90IFsxNF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxNV0gcmVnaXN0ZXJlZAph
Y3BpcGhwOiBTbG90IFsxNl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxN10gcmVnaXN0ZXJl
ZAphY3BpcGhwOiBTbG90IFsxOF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsxOV0gcmVnaXN0
ZXJlZAphY3BpcGhwOiBTbG90IFsyMF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyMV0gcmVn
aXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyMl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyM10g
cmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyNF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsy
NV0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyNl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90
IFsyN10gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFsyOF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBT
bG90IFsyOV0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFszMF0gcmVnaXN0ZXJlZAphY3BpcGhw
OiBTbG90IFszMV0gcmVnaXN0ZXJlZAppbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xO
WFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0MApBQ1BJOiBQb3dlciBCdXR0b24gW1BX
UkZdCmlucHV0OiBTbGVlcCBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YU0xQQk46
MDAvaW5wdXQvaW5wdXQxCkFDUEk6IFNsZWVwIEJ1dHRvbiBbU0xQRl0KQUNQSTogYWNwaV9pZGxl
IHJlZ2lzdGVyZWQgd2l0aCBjcHVpZGxlCnByb2Nlc3NvciBMTlhDUFU6MDA6IHJlZ2lzdGVyZWQg
YXMgY29vbGluZ19kZXZpY2UwCnByb2Nlc3NvciBMTlhDUFU6MDE6IHJlZ2lzdGVyZWQgYXMgY29v
bGluZ19kZXZpY2UxCkVSU1Q6IFRhYmxlIGlzIG5vdCBmb3VuZCEKR0hFUzogSEVTVCBpcyBub3Qg
ZW5hYmxlZCEKICBhbGxvYyBpcnFfZGVzYyBmb3IgMjggb24gbm9kZSAtMQogIGFsbG9jIGtzdGF0
X2lycXMgb24gbm9kZSAtMQp4ZW4tcGxhdGZvcm0tcGNpIDAwMDA6MDA6MDMuMDogUENJIElOVCBB
IC0+IEdTSSAyOCAobGV2ZWwsIGxvdykgLT4gSVJRIDI4CkdyYW50IHRhYmxlIGluaXRpYWxpemVk
Ck5vbi12b2xhdGlsZSBtZW1vcnkgZHJpdmVyIHYxLjMKTGludXggYWdwZ2FydCBpbnRlcmZhY2Ug
djAuMTAzCmNyYXNoIG1lbW9yeSBkcml2ZXI6IHZlcnNpb24gMS4xClNlcmlhbDogODI1MC8xNjU1
MCBkcml2ZXIsIDQgcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQKc2VyaWFsODI1MDogdHR5UzAg
YXQgSS9PIDB4M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQowMDowYTogdHR5UzAgYXQgSS9PIDB4
M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQpicmQ6IG1vZHVsZSBsb2FkZWQKbG9vcDogbW9kdWxl
IGxvYWRlZAppbnB1dDogTWFjaW50b3NoIG1vdXNlIGJ1dHRvbiBlbXVsYXRpb24gYXMgL2Rldmlj
ZXMvdmlydHVhbC9pbnB1dC9pbnB1dDIKRml4ZWQgTURJTyBCdXM6IHByb2JlZAplaGNpX2hjZDog
VVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJpdmVyCm9oY2lfaGNk
OiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcgp1aGNpX2hjZDog
VVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlIGRyaXZlcgogIGFsbG9jIGly
cV9kZXNjIGZvciAyMyBvbiBub2RlIC0xCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCnVo
Y2lfaGNkIDAwMDA6MDA6MDEuMjogUENJIElOVCBEIC0+IEdTSSAyMyAobGV2ZWwsIGxvdykgLT4g
SVJRIDIzCnVoY2lfaGNkIDAwMDA6MDA6MDEuMjogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0
CnVoY2lfaGNkIDAwMDA6MDA6MDEuMjogVUhDSSBIb3N0IENvbnRyb2xsZXIKdWhjaV9oY2QgMDAw
MDowMDowMS4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEK
dWhjaV9oY2QgMDAwMDowMDowMS4yOiBpcnEgMjMsIGlvIGJhc2UgMHgwMDAwYzI0MAp1c2IgdXNi
MTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxCnVz
YiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxO
dW1iZXI9MQp1c2IgdXNiMTogUHJvZHVjdDogVUhDSSBIb3N0IENvbnRyb2xsZXIKdXNiIHVzYjE6
IE1hbnVmYWN0dXJlcjogTGludXggMi42LjMyLTIyMC43LjEuZWw2Lng4Nl82NCB1aGNpX2hjZAp1
c2IgdXNiMTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjAxLjIKdXNiIHVzYjE6IGNvbmZpZ3VyYXRp
b24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UKaHViIDEtMDoxLjA6IFVTQiBodWIgZm91bmQKaHVi
IDEtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKUE5QOiBQUy8yIENvbnRyb2xsZXIgW1BOUDAzMDM6
UFMySyxQTlAwZjEzOlBTMk1dIGF0IDB4NjAsMHg2NCBpcnEgMSwxMgpzZXJpbzogaTgwNDIgS0JE
IHBvcnQgYXQgMHg2MCwweDY0IGlycSAxCnNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4
NjQgaXJxIDEyCm1pY2U6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKcnRj
X2Ntb3MgMDA6MDU6IHJ0YyBjb3JlOiByZWdpc3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzAKcnRjMDog
YWxhcm1zIHVwIHRvIG9uZSBkYXksIDExNCBieXRlcyBudnJhbQpjcHVpZGxlOiB1c2luZyBnb3Zl
cm5vciBsYWRkZXIKY3B1aWRsZTogdXNpbmcgZ292ZXJub3IgbWVudQppbnB1dDogQVQgVHJhbnNs
YXRlZCBTZXQgMiBrZXlib2FyZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5w
dXQvaW5wdXQzCnVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaGlkZGV2
CnVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkCnVzYmhpZDog
djIuNjpVU0IgSElEIGNvcmUgZHJpdmVyClRDUCBjdWJpYyByZWdpc3RlcmVkCkluaXRpYWxpemlu
ZyBYRlJNIG5ldGxpbmsgc29ja2V0Ck5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcK
cmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAxClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJp
dmVyOiBkZXZpY2UvdmZiLzAKWEVOQlVTOiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS92
YmQvNzY4ClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmJkLzU2MzIKWEVO
QlVTOiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS92aWYvMApYRU5CVVM6IERldmljZSB3
aXRoIG5vIGRyaXZlcjogZGV2aWNlL3BjaS8wClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVy
OiBkZXZpY2UvY29uc29sZS8wCnJ0Y19jbW9zIDAwOjA1OiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0
byAyMDEyLTA0LTExIDE4OjQzOjUxIFVUQyAoMTMzNDE2OTgzMSkKSW5pdGFsaXppbmcgbmV0d29y
ayBkcm9wIG1vbml0b3Igc2VydmljZQpGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMjQ0
ayBmcmVlZApXcml0ZSBwcm90ZWN0aW5nIHRoZSBrZXJuZWwgcmVhZC1vbmx5IGRhdGE6IDEwMjQw
awpGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMDQwayBmcmVlZApGcmVlaW5nIHVudXNl
ZCBrZXJuZWwgbWVtb3J5OiAxNzU2ayBmcmVlZApkcmFjdXQ6IGRyYWN1dC0wMDQtMjU2LmVsNl8y
LjEKZHJhY3V0OiByZF9OT19MVUtTOiByZW1vdmluZyBjcnlwdG9sdWtzIGFjdGl2YXRpb24KZHJh
Y3V0OiByZF9OT19MVk06IHJlbW92aW5nIExWTSBhY3RpdmF0aW9uCmRldmljZS1tYXBwZXI6IHVl
dmVudDogdmVyc2lvbiAxLjAuMwpkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4yMi42LWlvY3RsICgy
MDExLTEwLTE5KSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNvbQp1ZGV2OiBzdGFydGlu
ZyB2ZXJzaW9uIDE0NwpkcmFjdXQ6IFN0YXJ0aW5nIHBseW1vdXRoIGRhZW1vbgpkcmFjdXQ6IHJk
X05PX0RNOiByZW1vdmluZyBETSBSQUlEIGFjdGl2YXRpb24KZHJhY3V0OiByZF9OT19NRDogcmVt
b3ZpbmcgTUQgUkFJRCBhY3RpdmF0aW9uCnhsYmxrX2luaXQ6IHJlZ2lzdGVyX2Jsa2RldiBtYWpv
cjogMjAyIAogIGFsbG9jIGlycV9kZXNjIGZvciAxNyBvbiBub2RlIDAKICBhbGxvYyBrc3RhdF9p
cnFzIG9uIG5vZGUgMAp2YmQgdmJkLTU2MzI6IDE5IHhlbmJ1c19kZXZfcHJvYmUgb24gZGV2aWNl
L3ZiZC81NjMyCmJsa2Zyb250OiB4dmRhOiBiYXJyaWVycyBkaXNhYmxlZAogeHZkYTogeHZkYTEg
eHZkYTIKdXNiIDEtMjogbmV3IGZ1bGwgc3BlZWQgVVNCIGRldmljZSB1c2luZyB1aGNpX2hjZCBh
bmQgYWRkcmVzcyAyCm1wdDJzYXMgdmVyc2lvbiAwOS4xMDEuMDAuMDAgbG9hZGVkCnNjc2kwIDog
RnVzaW9uIE1QVCBTQVMgSG9zdAogIGFsbG9jIGlycV9kZXNjIGZvciAzNiBvbiBub2RlIC0xCiAg
YWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCm1wdDJzYXMgMDAwMDowMDowNS4wOiBQQ0kgSU5U
IEEgLT4gR1NJIDM2IChsZXZlbCwgbG93KSAtPiBJUlEgMzYKbXB0MnNhcyAwMDAwOjAwOjA1LjA6
IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NAptcHQyc2FzMDogMzIgQklUIFBDSSBCVVMgRE1B
IEFERFJFU1NJTkcgU1VQUE9SVEVELCB0b3RhbCBtZW0gKDIwNTMzNzYga0IpCiAgYWxsb2MgaXJx
X2Rlc2MgZm9yIDQ4IG9uIG5vZGUgLTEKICBhbGxvYyBrc3RhdF9pcnFzIG9uIG5vZGUgLTEKbXB0
MnNhcyAwMDAwOjAwOjA1LjA6IGlycSA0OCBmb3IgTVNJL01TSS1YCm1wdDJzYXMwOiBQQ0ktTVNJ
LVggZW5hYmxlZDogSVJRIDQ4Cm1wdDJzYXMwOiBpb21lbSgweDAwMDAwMDAwZjMwZTAwMDApLCBt
YXBwZWQoMHhmZmZmYzkwMDAwOWU4MDAwKSwgc2l6ZSgxNjM4NCkKbXB0MnNhczA6IGlvcG9ydCgw
eDAwMDAwMDAwMDAwMGMxMDApLCBzaXplKDI1NikKaW5wdXQ6IEltRXhQUy8yIEdlbmVyaWMgRXhw
bG9yZXIgTW91c2UgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2VyaW8xL2lucHV0L2lucHV0
NAptcHQyc2FzMDogQWxsb2NhdGVkIHBoeXNpY2FsIG1lbW9yeTogc2l6ZSgyNjg4IGtCKQptcHQy
c2FzMDogQ3VycmVudCBDb250cm9sbGVyIFF1ZXVlIERlcHRoKDE3NTQpLCBNYXggQ29udHJvbGxl
ciBRdWV1ZSBEZXB0aCgyMDE1KQptcHQyc2FzMDogU2NhdHRlciBHYXRoZXIgRWxlbWVudHMgcGVy
IElPKDEyOCkKUmVmaW5lZCBUU0MgY2xvY2tzb3VyY2UgY2FsaWJyYXRpb246IDMxOTIuNzUwIE1I
ei4KU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHRzYwp1c2IgMS0yOiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MDYyNywgaWRQcm9kdWN0PTAwMDEKdXNiIDEtMjogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKdXNiIDEtMjogUHJv
ZHVjdDogUUVNVSBVU0IgVGFibGV0CnVzYiAxLTI6IE1hbnVmYWN0dXJlcjogUUVNVSAwLjEwLjIK
dXNiIDEtMjogU2VyaWFsTnVtYmVyOiAxCnVzYiAxLTI6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2Vu
IGZyb20gMSBjaG9pY2UKaW5wdXQ6IFFFTVUgMC4xMC4yIFFFTVUgVVNCIFRhYmxldCBhcyAvZGV2
aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MDEuMi91c2IxLzEtMi8xLTI6MS4wL2lucHV0L2lucHV0
NQpnZW5lcmljLXVzYiAwMDAzOjA2Mjc6MDAwMS4wMDAxOiBpbnB1dCxoaWRyYXcwOiBVU0IgSElE
IHYwLjAxIFBvaW50ZXIgW1FFTVUgMC4xMC4yIFFFTVUgVVNCIFRhYmxldF0gb24gdXNiLTAwMDA6
MDA6MDEuMi0yL2lucHV0MAptcHQyc2FzMDogX2Jhc2VfZXZlbnRfbm90aWZpY2F0aW9uOiB0aW1l
b3V0Cm1mOgoJMDcwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMGYy
ZjdmZmYgZmZmZmZmZmMgZmZmZmZmZmYgCglmZmZmZmZmZiAwMDAwMDAwMCAwMDAwMDAwMCAKbXB0
MnNhczA6IHNlbmRpbmcgZGlhZyByZXNldCAhIQptcHQyc2FzMDogZGlhZyByZXNldDogU1VDQ0VT
UwptcHQyc2FzIDAwMDA6MDA6MDUuMDogUENJIElOVCBBIGRpc2FibGVkCm1wdDJzYXMwOiBmYWls
dXJlIGF0IGRyaXZlcnMvc2NzaS9tcHQyc2FzL21wdDJzYXNfc2NzaWguYzo3NjI4L19zY3NpaF9w
cm9iZSgpIQphdGFfcGlpeCAwMDAwOjAwOjAxLjE6IHZlcnNpb24gMi4xMwphdGFfcGlpeCAwMDAw
OjAwOjAxLjE6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApzY3NpMSA6IGF0YV9waWl4CnNj
c2kyIDogYXRhX3BpaXgKYXRhMTogUEFUQSBtYXggTVdETUEyIGNtZCAweDFmMCBjdGwgMHgzZjYg
Ym1kbWEgMHhjMjYwIGlycSAxNAphdGEyOiBQQVRBIG1heCBNV0RNQTIgY21kIDB4MTcwIGN0bCAw
eDM3NiBibWRtYSAweGMyNjggaXJxIDE1CmF0YTIuMDE6IE5PREVWIGFmdGVyIHBvbGxpbmcgZGV0
ZWN0aW9uCmF0YTIuMDA6IEFUQVBJOiBRRU1VIERWRC1ST00sIDAuMTAuMiwgbWF4IFVETUEvMTAw
CmF0YTIuMDA6IGNvbmZpZ3VyZWQgZm9yIE1XRE1BMgpzY3NpIDI6MDowOjA6IENELVJPTSAgICAg
ICAgICAgIFFFTVUgICAgIFFFTVUgRFZELVJPTSAgICAgMC4xMCBQUTogMCBBTlNJOiA1CnNyMDog
c2NzaTMtbW1jIGRyaXZlOiA0eC80eCB4YS9mb3JtMiB0cmF5ClVuaWZvcm0gQ0QtUk9NIGRyaXZl
ciBSZXZpc2lvbjogMy4yMApzciAyOjA6MDowOiBBdHRhY2hlZCBzY3NpIENELVJPTSBzcjAKRVhU
NC1mcyAoeHZkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4g
T3B0czogCmRyYWN1dDogTW91bnRlZCByb290IGZpbGVzeXN0ZW0gL2Rldi94dmRhMQpkcmFjdXQ6
IExvYWRpbmcgU0VMaW51eCBwb2xpY3kKdHlwZT0xNDA0IGF1ZGl0KDEzMzQxNjk4NjMuNzQxOjIp
OiBlbmZvcmNpbmc9MSBvbGRfZW5mb3JjaW5nPTAgYXVpZD00Mjk0OTY3Mjk1IHNlcz00Mjk0OTY3
Mjk1ClNFTGludXg6IDIwNDggYXZ0YWIgaGFzaCBzbG90cywgMjI2MDA1IHJ1bGVzLgpTRUxpbnV4
OiAyMDQ4IGF2dGFiIGhhc2ggc2xvdHMsIDIyNjAwNSBydWxlcy4KU0VMaW51eDogIDkgdXNlcnMs
IDEyIHJvbGVzLCAzNTc4IHR5cGVzLCAxNzkgYm9vbHMsIDEgc2VucywgMTAyNCBjYXRzClNFTGlu
dXg6ICA4MSBjbGFzc2VzLCAyMjYwMDUgcnVsZXMKU0VMaW51eDogIENvbXBsZXRpbmcgaW5pdGlh
bGl6YXRpb24uClNFTGludXg6ICBTZXR0aW5nIHVwIGV4aXN0aW5nIHN1cGVyYmxvY2tzLgpTRUxp
bnV4OiBpbml0aWFsaXplZCAoZGV2IHh2ZGExLCB0eXBlIGV4dDQpLCB1c2VzIHhhdHRyClNFTGlu
dXg6IGluaXRpYWxpemVkIChkZXYgdG1wZnMsIHR5cGUgdG1wZnMpLCB1c2VzIHRyYW5zaXRpb24g
U0lEcwpTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IHVzYmZzLCB0eXBlIHVzYmZzKSwgdXNlcyBn
ZW5mc19jb250ZXh0cwpTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IHNlbGludXhmcywgdHlwZSBz
ZWxpbnV4ZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYg
bXF1ZXVlLCB0eXBlIG1xdWV1ZSksIHVzZXMgdHJhbnNpdGlvbiBTSURzClNFTGludXg6IGluaXRp
YWxpemVkIChkZXYgaHVnZXRsYmZzLCB0eXBlIGh1Z2V0bGJmcyksIHVzZXMgdHJhbnNpdGlvbiBT
SURzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgZGV2cHRzLCB0eXBlIGRldnB0cyksIHVzZXMg
dHJhbnNpdGlvbiBTSURzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgaW5vdGlmeWZzLCB0eXBl
IGlub3RpZnlmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRl
diBhbm9uX2lub2RlZnMsIHR5cGUgYW5vbl9pbm9kZWZzKSwgdXNlcyBnZW5mc19jb250ZXh0cwpT
RUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IHBpcGVmcywgdHlwZSBwaXBlZnMpLCB1c2VzIHRhc2sg
U0lEcwpTRUxpbnV4OiBpbml0aWFsaXplZCAoZGV2IGRlYnVnZnMsIHR5cGUgZGVidWdmcyksIHVz
ZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBzb2NrZnMsIHR5cGUg
c29ja2ZzKSwgdXNlcyB0YXNrIFNJRHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBkZXZ0bXBm
cywgdHlwZSBkZXZ0bXBmcyksIHVzZXMgdHJhbnNpdGlvbiBTSURzClNFTGludXg6IGluaXRpYWxp
emVkIChkZXYgdG1wZnMsIHR5cGUgdG1wZnMpLCB1c2VzIHRyYW5zaXRpb24gU0lEcwpTRUxpbnV4
OiBpbml0aWFsaXplZCAoZGV2IHByb2MsIHR5cGUgcHJvYyksIHVzZXMgZ2VuZnNfY29udGV4dHMK
U0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBiZGV2LCB0eXBlIGJkZXYpLCB1c2VzIGdlbmZzX2Nv
bnRleHRzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgcm9vdGZzLCB0eXBlIHJvb3RmcyksIHVz
ZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBzeXNmcywgdHlwZSBz
eXNmcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKdHlwZT0xNDAzIGF1ZGl0KDEzMzQxNjk4NjQuMDcz
OjMpOiBwb2xpY3kgbG9hZGVkIGF1aWQ9NDI5NDk2NzI5NSBzZXM9NDI5NDk2NzI5NQpkcmFjdXQ6
IApkcmFjdXQ6IFN3aXRjaGluZyByb290CnJlYWRhaGVhZDogc3RhcnRpbmcKdWRldjogc3RhcnRp
bmcgdmVyc2lvbiAxNDcKc3IgMjowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0eXBl
IDUKcGlpeDRfc21idXMgMDAwMDowMDowMS4zOiBTTUJ1cyBiYXNlIGFkZHJlc3MgdW5pbml0aWFs
aXplZCAtIHVwZ3JhZGUgQklPUyBvciB1c2UgZm9yY2VfYWRkcj0weGFkZHIKSW5pdGlhbGlzaW5n
IFhlbiB2aXJ0dWFsIGV0aGVybmV0IGRyaXZlci4KICBhbGxvYyBpcnFfZGVzYyBmb3IgMTggb24g
bm9kZSAwCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKbWljcm9jb2RlOiBDUFUwIHNpZz0w
eDIwNmE3LCBwZj0weDIsIHJldmlzaW9uPTB4MWIKcGxhdGZvcm0gbWljcm9jb2RlOiBmaXJtd2Fy
ZTogcmVxdWVzdGluZyBpbnRlbC11Y29kZS8wNi0yYS0wNwptaWNyb2NvZGU6IENQVTEgc2lnPTB4
MjA2YTcsIHBmPTB4MiwgcmV2aXNpb249MHgxYgpwbGF0Zm9ybSBtaWNyb2NvZGU6IGZpcm13YXJl
OiByZXF1ZXN0aW5nIGludGVsLXVjb2RlLzA2LTJhLTA3Ck1pY3JvY29kZSBVcGRhdGUgRHJpdmVy
OiB2Mi4wMCA8dGlncmFuQGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmEKcGFycG9y
dF9wYyAwMDowYjogcmVwb3J0ZWQgYnkgUGx1ZyBhbmQgUGxheSBBQ1BJCnBhcnBvcnQwOiBQQy1z
dHlsZSBhdCAweDM3OCwgaXJxIDcgW1BDU1BQLFRSSVNUQVRFXQpwcGRldjogdXNlci1zcGFjZSBw
YXJhbGxlbCBwb3J0IGRyaXZlcgpBZGRpbmcgMTA0NzU0NGsgc3dhcCBvbiAvZGV2L3h2ZGEyLiAg
UHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczoxMDQ3NTQ0ayBTUwpTRUxpbnV4OiBpbml0aWFs
aXplZCAoZGV2IGJpbmZtdF9taXNjLCB0eXBlIGJpbmZtdF9taXNjKSwgdXNlcyBnZW5mc19jb250
ZXh0cwpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEwCmxvOiBEaXNhYmxlZCBQcml2
YWN5IEV4dGVuc2lvbnMKaXA2X3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBU
ZWFtCm5mX2Nvbm50cmFjayB2ZXJzaW9uIDAuNS4wICgxNjM4NCBidWNrZXRzLCA2NTUzNiBtYXgp
CmlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClJQQzogUmVnaXN0
ZXJlZCB1ZHAgdHJhbnNwb3J0IG1vZHVsZS4KUlBDOiBSZWdpc3RlcmVkIHRjcCB0cmFuc3BvcnQg
bW9kdWxlLgpSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNwb3J0
IG1vZHVsZS4KU0VMaW51eDogaW5pdGlhbGl6ZWQgKGRldiBycGNfcGlwZWZzLCB0eXBlIHJwY19w
aXBlZnMpLCB1c2VzIGdlbmZzX2NvbnRleHRzClNFTGludXg6IGluaXRpYWxpemVkIChkZXYgYXV0
b2ZzLCB0eXBlIGF1dG9mcyksIHVzZXMgZ2VuZnNfY29udGV4dHMKU0VMaW51eDogaW5pdGlhbGl6
ZWQgKGRldiBhdXRvZnMsIHR5cGUgYXV0b2ZzKSwgdXNlcyBnZW5mc19jb250ZXh0cwpTRUxpbnV4
OiBpbml0aWFsaXplZCAoZGV2IGF1dG9mcywgdHlwZSBhdXRvZnMpLCB1c2VzIGdlbmZzX2NvbnRl
eHRzCmV0aDA6IG5vIElQdjYgcm91dGVycyBwcmVzZW50Cg==
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="pvhvm_lspci.txt"
Content-Disposition: attachment; filename="pvhvm_lspci.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6hb3

MDA6MDAuMCBIb3N0IGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gNDQwRlggLSA4MjQ0MUZYIFBN
QyBbTmF0b21hXSAocmV2IDAyKQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFs
IG1hY2hpbmUKCVBoeXNpY2FsIFNsb3Q6IDAKCUZsYWdzOiBidXMgbWFzdGVyLCBmYXN0IGRldnNl
bCwgbGF0ZW5jeSAwCgowMDowMS4wIElTQSBicmlkZ2U6IEludGVsIENvcnBvcmF0aW9uIDgyMzcx
U0IgUElJWDMgSVNBIFtOYXRvbWEvVHJpdG9uIElJXQoJU3Vic3lzdGVtOiBSZWQgSGF0LCBJbmMg
UWVtdSB2aXJ0dWFsIG1hY2hpbmUKCUZsYWdzOiBidXMgbWFzdGVyLCBtZWRpdW0gZGV2c2VsLCBs
YXRlbmN5IDAKCjAwOjAxLjEgSURFIGludGVyZmFjZTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFT
QiBQSUlYMyBJREUgW05hdG9tYS9Ucml0b24gSUldIChwcm9nLWlmIDgwIFtNYXN0ZXJdKQoJU3Vi
c3lzdGVtOiBYZW5Tb3VyY2UsIEluYy4gRGV2aWNlIDAwMDEKCUZsYWdzOiBidXMgbWFzdGVyLCBt
ZWRpdW0gZGV2c2VsLCBsYXRlbmN5IDY0CglbdmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMWYwICgz
Mi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThdCglbdmlydHVhbF0gTWVtb3J5IGF0IDAw
MDAwM2YwICh0eXBlIDMsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFdCglbdmlydHVhbF0gTWVt
b3J5IGF0IDAwMDAwMTcwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThdCglbdmly
dHVhbF0gTWVtb3J5IGF0IDAwMDAwMzcwICh0eXBlIDMsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXpl
PTFdCglJL08gcG9ydHMgYXQgYzI2MCBbc2l6ZT0xNl0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBh
dGFfcGlpeAoJS2VybmVsIG1vZHVsZXM6IGF0YV9nZW5lcmljLCBwYXRhX2FjcGksIGF0YV9waWl4
CgowMDowMS4yIFVTQiBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjM3MVNCIFBJSVgz
IFVTQiBbTmF0b21hL1RyaXRvbiBJSV0gKHJldiAwMSkgKHByb2ctaWYgMDAgW1VIQ0ldKQoJU3Vi
c3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFsIG1hY2hpbmUKCUZsYWdzOiBidXMgbWFz
dGVyLCBmYXN0IGRldnNlbCwgbGF0ZW5jeSA2NCwgSVJRIDIzCglJL08gcG9ydHMgYXQgYzI0MCBb
c2l6ZT0zMl0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB1aGNpX2hjZAoKMDA6MDEuMyBCcmlkZ2U6
IEludGVsIENvcnBvcmF0aW9uIDgyMzcxQUIvRUIvTUIgUElJWDQgQUNQSSAocmV2IDAxKQoJU3Vi
c3lzdGVtOiBSZWQgSGF0LCBJbmMgUWVtdSB2aXJ0dWFsIG1hY2hpbmUKCVBoeXNpY2FsIFNsb3Q6
IDEKCUZsYWdzOiBidXMgbWFzdGVyLCBmYXN0IGRldnNlbCwgbGF0ZW5jeSAwLCBJUlEgOQoJS2Vy
bmVsIG1vZHVsZXM6IGkyYy1waWl4NAoKMDA6MDIuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVy
OiBDaXJydXMgTG9naWMgR0QgNTQ0NiAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vi
c3lzdGVtOiBYZW5Tb3VyY2UsIEluYy4gRGV2aWNlIDAwMDEKCVBoeXNpY2FsIFNsb3Q6IDIKCUZs
YWdzOiBidXMgbWFzdGVyLCBmYXN0IGRldnNlbCwgbGF0ZW5jeSAwCglNZW1vcnkgYXQgZjAwMDAw
MDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dCglNZW1vcnkgYXQgZjMwZTQwMDAg
KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglFeHBhbnNpb24gUk9NIGF0IDx1
bmFzc2lnbmVkPiBbZGlzYWJsZWRdCglLZXJuZWwgbW9kdWxlczogY2lycnVzZmIKCjAwOjAzLjAg
VW5hc3NpZ25lZCBjbGFzcyBbZmY4MF06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZvcm0gRGV2
aWNlIChyZXYgMDEpCglTdWJzeXN0ZW06IFhlblNvdXJjZSwgSW5jLiBYZW4gUGxhdGZvcm0gRGV2
aWNlCglQaHlzaWNhbCBTbG90OiAzCglGbGFnczogYnVzIG1hc3RlciwgZmFzdCBkZXZzZWwsIGxh
dGVuY3kgMCwgSVJRIDI4CglJL08gcG9ydHMgYXQgYzAwMCBbc2l6ZT0yNTZdCglNZW1vcnkgYXQg
ZjIwMDAwMDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNk1dCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogeGVuLXBsYXRmb3JtLXBjaQoKMDA6MDUuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBj
b250cm9sbGVyOiBMU0kgTG9naWMgLyBTeW1iaW9zIExvZ2ljIFNBUzIwMDggUENJLUV4cHJlc3Mg
RnVzaW9uLU1QVCBTQVMtMiBbRmFsY29uXSAocmV2IDAzKQoJU3Vic3lzdGVtOiBMU0kgTG9naWMg
LyBTeW1iaW9zIExvZ2ljIERldmljZSAzMDIwCglQaHlzaWNhbCBTbG90OiA1CglGbGFnczogZmFz
dCBkZXZzZWwsIElSUSAzNgoJSS9PIHBvcnRzIGF0IGMxMDAgW3NpemU9MjU2XQoJTWVtb3J5IGF0
IGYzMGUwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2S10KCU1lbW9yeSBh
dCBmMzA4MDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZLXQoJRXhwYW5z
aW9uIFJPTSBhdCBmMzAwMDAwMCBbZGlzYWJsZWRdIFtzaXplPTUxMktdCglDYXBhYmlsaXRpZXM6
IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCUNhcGFiaWxpdGllczogWzY4XSBFeHBy
ZXNzIEVuZHBvaW50LCBNU0kgMDAKCUNhcGFiaWxpdGllczogW2QwXSBWaXRhbCBQcm9kdWN0IERh
dGEKCUNhcGFiaWxpdGllczogW2E4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsKCUNhcGFiaWxpdGllczogW2MwXSBNU0ktWDogRW5hYmxlLSBDb3VudD0xNSBNYXNrZWQt
CglLZXJuZWwgbW9kdWxlczogbXB0MnNhcwoK
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset=US-ASCII; name="xm_dmesg.txt"
Content-Disposition: attachment; filename="xm_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wso6hx4

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgXyAgIF9fX19fICAgICAgICAgICAgIF8gICAgICAg
ICAgICAgICAgICAgCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgLyB8IHxfX18gLyAgICBfIF9f
IF9fXy8gfCAgIF8gX18gIF8gX18gX19fIAogIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxfIHwgfCAg
IHxfIFwgX198ICdfXy8gX198IHxfX3wgJ18gXHwgJ19fLyBfIFwKICAvICBcICBfXy8gfCB8IHwg
fF9fICAgX3x8IHxfIF9fXykgfF9ffCB8IHwgKF9ffCB8X198IHxfKSB8IHwgfCAgX18vCiAvXy9c
X1xfX198X3wgfF98ICAgIHxffChfKV8oXylfX19fLyAgIHxffCAgXF9fX3xffCAgfCAuX18vfF98
ICBcX19ffAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHxffCAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24gNC4xLjMtcmMxLXByZSAoc2Fk
bUApIChnY2MgdmVyc2lvbiA0LjYuMyAoVWJ1bnR1L0xpbmFybyA0LjYuMy0xdWJ1bnR1NCkgKSBX
ZWQgQXByIDExIDAxOjU2OjQ0IEVEVCAyMDEyCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFdlZCBB
cHIgMDQgMTY6MDk6MjUgMjAxMiArMDEwMCAyMzI3Njo2ZjIyNDQzMWVjYTIKKFhFTikgQm9vdGxv
YWRlcjogR1JVQiAxLjk5LTIxdWJ1bnR1MgooWEVOKSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVy
IGRvbTBfbWVtPTEwMjRNIGRvbTBfbWF4X3ZjcHVzPTIgbG9nbHZsPWFsbCBndWVzdF9sb2dsdmw9
YWxsIGlvbW11PTEKKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBt
b2RlIDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJh
bnNmZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3Vu
ZCA3IE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCA2IEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1
cmVzCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAw
MDAwMDAwMDA4ZDAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA4ZDAwMCAtIDAwMDAwMDAw
MDAwYTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAx
MDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwYmU3YTUw
MDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwYmU3YTUwMDAgLSAwMDAwMDAwMGJlN2YxMDAwIChB
Q1BJIE5WUykKKFhFTikgIDAwMDAwMDAwYmU3ZjEwMDAgLSAwMDAwMDAwMGJlN2Y5MDAwIChBQ1BJ
IGRhdGEpCihYRU4pICAwMDAwMDAwMGJlN2Y5MDAwIC0gMDAwMDAwMDBiZjQ3NzAwMCAocmVzZXJ2
ZWQpCihYRU4pICAwMDAwMDAwMGJmNDc3MDAwIC0gMDAwMDAwMDBiZjQ3ODAwMCAoQUNQSSBOVlMp
CihYRU4pICAwMDAwMDAwMGJmNDc4MDAwIC0gMDAwMDAwMDBiZjQ4OTAwMCAocmVzZXJ2ZWQpCihY
RU4pICAwMDAwMDAwMGJmNDg5MDAwIC0gMDAwMDAwMDBiZjQ4YzAwMCAoQUNQSSBOVlMpCihYRU4p
ICAwMDAwMDAwMGJmNDhjMDAwIC0gMDAwMDAwMDBiZjRhZDAwMCAocmVzZXJ2ZWQpCihYRU4pICAw
MDAwMDAwMGJmNGFkMDAwIC0gMDAwMDAwMDBiZjRhZjAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAw
MDBiZjRhZjAwMCAtIDAwMDAwMDAwYmY1MDMwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBi
ZjUwMzAwMCAtIDAwMDAwMDAwYmY1MGQwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBiZjUw
ZDAwMCAtIDAwMDAwMDAwYmY1MzMwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBiZjUzMzAw
MCAtIDAwMDAwMDAwYmY1NzYwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBiZjU3NjAwMCAt
IDAwMDAwMDAwYmY4MDAwMDAgKHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAw
MDAwMGZlZDQwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmYwMDAwMDAgLSAwMDAwMDAw
MTAwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwNDQw
MDAwMDAwICh1c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRjA0NTAsIDAwMjQgKHIyIFNVUEVS
TSkKKFhFTikgQUNQSTogWFNEVCBCRTdGMTA4MCwgMDA3QyAocjEgU1VQRVJNIFNNQ0ktLU1CICAg
ICAgICAxIEFNSSAgICAgMTAwMTMpCihYRU4pIEFDUEk6IEZBQ1AgQkU3RjdGNDgsIDAwRjQgKHI0
IFNVUEVSTSBTTUNJLS1NQiAgICAgICAgMSBBTUkgICAgIDEwMDEzKQooWEVOKSBBQ1BJOiBEU0RU
IEJFN0YxMTg4LCA2REMwIChyMiBTVVBFUk0gU01DSS0tTUIgICAgICAgIDAgSU5UTCAyMDA1MTEx
NykKKFhFTikgQUNQSTogRkFDUyBCRjUwQUY4MCwgMDA0MAooWEVOKSBBQ1BJOiBBUElDIEJFN0Y4
MDQwLCAwMDkyIChyMyBTVVBFUk0gU01DSS0tTUIgICAgICAgIDEgQU1JICAgICAxMDAxMykKKFhF
TikgQUNQSTogU1NEVCBCRTdGODBEOCwgMDFENiAocjEgQU1JQ1BVICAgICBQUk9DICAgICAgICAx
IE1TRlQgIDMwMDAwMDEpCihYRU4pIEFDUEk6IE1DRkcgQkU3RjgyQjAsIDAwM0MgKHIxIFNVUEVS
TSBTTUNJLS1NQiAgICAgICAgMSBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBIUEVUIEJFN0Y4
MkYwLCAwMDM4IChyMSBTVVBFUk0gU01DSS0tTUIgICAgICAgIDEgQU1JLiAgICAgICAgNCkKKFhF
TikgQUNQSTogU1BNSSBCRTdGODMyOCwgMDA0MCAocjUgQSBNIEkgICBPRU1TUE1JICAgICAgICAw
IEFNSS4gICAgICAgIDApCihYRU4pIEFDUEk6IERNQVIgQkU3RjgzNjgsIDAwQjAgKHIxIEFMQVNL
QSAgICBBIE0gSSAgICAgICAgMSBJTlRMICAgICAgICAxKQooWEVOKSBBQ1BJOiBFSU5KIEJFN0Y4
NDE4LCAwMTMwIChyMSAgICBBTUkgQU1JIEVJTkogICAgICAgIDAgICAgICAgICAgICAgMCkKKFhF
TikgQUNQSTogRVJTVCBCRTdGODU0OCwgMDIxMCAocjEgIEFNSUVSIEFNSSBFUlNUICAgICAgICAw
ICAgICAgICAgICAgIDApCihYRU4pIEFDUEk6IEhFU1QgQkU3Rjg3NTgsIDAwQTggKHIxICAgIEFN
SSBBTUkgSEVTVCAgICAgICAgMCAgICAgICAgICAgICAwKQooWEVOKSBBQ1BJOiBCRVJUIEJFN0Y4
ODAwLCAwMDMwIChyMSAgICBBTUkgQU1JIEJFUlQgICAgICAgIDAgICAgICAgICAgICAgMCkKKFhF
TikgU3lzdGVtIFJBTTogMTYzNjFNQiAoMTY3NTQ0MjRrQikKKFhFTikgTm8gTlVNQSBjb25maWd1
cmF0aW9uIGZvdW5kCihYRU4pIEZha2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAw
MDAwNDQwMDAwMDAwCihYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCihYRU4pIGZvdW5kIFNN
UCBNUC10YWJsZSBhdCAwMDBmY2UwMAooWEVOKSBETUkgMi43IHByZXNlbnQuCihYRU4pIFVzaW5n
IEFQSUMgZHJpdmVyIGRlZmF1bHQKKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgK
KFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs0MDQsMF0sIHBtMXhfZXZ0WzQw
MCwwXQooWEVOKSBBQ1BJOiAzMi82NFggRkFDUyBhZGRyZXNzIG1pc21hdGNoIGluIEZBRFQgLSBi
ZjUwYWY4MC8wMDAwMDAwMDAwMDAwMDAwLCB1c2luZyAzMgooWEVOKSBBQ1BJOiAgICAgICAgICAg
ICAgICAgIHdha2V1cF92ZWNbYmY1MGFmOGNdLCB2ZWNfc2l6ZVsyMF0KKFhFTikgQUNQSTogTG9j
YWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMwIDY6MTAgQVBJQyB2
ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDJd
IGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMiA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQooWEVOKSBQ
cm9jZXNzb3IgIzQgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgwNF0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICM2IDY6MTAg
QVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lk
WzB4MDFdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMSA2OjEwIEFQSUMgdmVyc2lvbiAyMQoo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQoo
WEVOKSBQcm9jZXNzb3IgIzMgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICM1
IDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxh
cGljX2lkWzB4MDddIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNyA2OjEwIEFQSUMgdmVyc2lv
biAyMQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHhmZl0gaGlnaCBlZGdlIGxpbnRb
MHgxXSkKKFhFTikgQUNQSTogSU9BUElDIChpZFsweDAwXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdz
aV9iYXNlWzBdKQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgMCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMwooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVz
IDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQooWEVOKSBBQ1BJOiBJUlEwIHVz
ZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KKFhFTikg
QUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBG
bGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MKKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBi
YXNlOiAweGZlZDAwMDAwCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAw
MDAwMDAgc2VnbWVudCAwIGJ1c2VzIDAgLSAyNTUKKFhFTikgUENJOiBOb3QgdXNpbmcgTU1DT05G
SUcuCihYRU4pIEVSU1QgdGFibGUgaXMgaW52YWxpZAooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBm
b3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KKFhFTikgSVJRIGxpbWl0czogMjQgR1NJ
LCAxNTI4IE1TSS9NU0ktWAooWEVOKSBTd2l0Y2hlZCB0byBBUElDIGRyaXZlciB4MmFwaWNfY2x1
c3Rlci4KKFhFTikgVXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0
KQooWEVOKSBEZXRlY3RlZCAzMTkyLjgzOCBNSHogcHJvY2Vzc29yLgooWEVOKSBJbml0aW5nIG1l
bW9yeSBzaGFyaW5nLgooWEVOKSBtY2VfaW50ZWwuYzoxMTYyOiBNQ0EgQ2FwYWJpbGl0eTogQkNB
U1QgMSBTRVIgMCBDTUNJIDEgZmlyc3RiYW5rIDAgZXh0ZW5kZWQgTUNFIE1TUiAwCihYRU4pIElu
dGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQKKFhFTikgSW50ZWwgVlQtZCBTbm9v
cCBDb250cm9sIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIERvbTAgRE1BIFBhc3N0aHJv
dWdoIG5vdCBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIFF1ZXVlZCBJbnZhbGlkYXRpb24gZW5h
YmxlZC4KKFhFTikgSW50ZWwgVlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuYWJsZWQuCihYRU4p
IEludGVsIFZULWQgU2hhcmVkIEVQVCB0YWJsZXMgbm90IGVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0
dWFsaXNhdGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBFbmFi
bGVkIGRpcmVjdGVkIEVPSSB3aXRoIGlvYXBpY19hY2tfb2xkIG9uIQooWEVOKSBFTkFCTElORyBJ
Ty1BUElDIElSUXMKKFhFTikgIC0+IFVzaW5nIG9sZCBBQ0sgbWV0aG9kCihYRU4pIC4uVElNRVI6
IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9LTEKKFhFTikgVFNDIGRl
YWRsaW5lIHRpbWVyIGVuYWJsZWQKKFhFTikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQ
RVQKKFhFTikgQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFZNWDogU3Vw
cG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSAgLSBBUElDIE1NSU8gYWNjZXNzIHZpcnR1
YWxpc2F0aW9uCihYRU4pICAtIEFQSUMgVFBSIHNoYWRvdwooWEVOKSAgLSBFeHRlbmRlZCBQYWdl
IFRhYmxlcyAoRVBUKQooWEVOKSAgLSBWaXJ0dWFsLVByb2Nlc3NvciBJZGVudGlmaWVycyAoVlBJ
RCkKKFhFTikgIC0gVmlydHVhbCBOTUkKKFhFTikgIC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFw
CihYRU4pICAtIFVucmVzdHJpY3RlZCBHdWVzdAooWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCihY
RU4pIEhWTTogVk1YIGVuYWJsZWQKKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcg
KEhBUCkgZGV0ZWN0ZWQKKFhFTikgSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIKKFhFTikg
QnJvdWdodCB1cCA4IENQVXMKKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgbWNoZWNr
X3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgooWEVOKSAqKiogTE9B
RElORyBET01BSU4gMCAqKioKKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0
MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAg
LT4gMHgyMDYwMDAwCihYRU4pIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERv
bTAgYWxsb2MuOiAgIDAwMDAwMDA0MmMwMDAwMDAtPjAwMDAwMDA0MzAwMDAwMDAgKDIzNTUxNiBw
YWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwNDNkN2Zj
MDAwLT4wMDAwMDAwNDNmZmZmNjAwCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgoo
WEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MjA2MDAwMAoo
WEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MjA2MDAwMC0+ZmZmZmZmZmY4NDg2MzYwMAoo
WEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4NDg2NDAwMC0+ZmZmZmZmZmY4NGE2NDAwMAoo
WEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4NGE2NDAwMC0+ZmZmZmZmZmY4NGE2NDRiNAoo
WEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4NGE2NTAwMC0+ZmZmZmZmZmY4NGE4ZTAwMAoo
WEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NGE4ZTAwMC0+ZmZmZmZmZmY4NGE4ZjAwMAoo
WEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NGMwMDAwMAoo
WEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWNmYzIwMAooWEVOKSBEb20wIGhhcyBtYXhp
bXVtIDIgVkNQVXMKKFhFTikgU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uZG9uZS4KKFhFTikgWGVuIHRyYWNlIGJ1ZmZlcnM6IGRpc2FibGVk
CihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4p
IFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSAqKiogU2VyaWFsIGlucHV0
IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhl
bikKKFhFTikgRnJlZWQgMjE2a0IgaW5pdCBtZW1vcnkuCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAw
OjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDEuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAw
MDoxOS4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjFhLjAKKFhFTikgUENJIGFkZCBkZXZpY2Ug
MDA6MWMuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxYy40CihYRU4pIFBDSSBhZGQgZGV2aWNl
IDAwOjFkLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MWUuMAooWEVOKSBQQ0kgYWRkIGRldmlj
ZSAwMDoxZi4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjFmLjIKKFhFTikgUENJIGFkZCBkZXZp
Y2UgMDA6MWYuMwooWEVOKSBQQ0kgYWRkIGRldmljZSAwMTowMC4wCihYRU4pIFBDSSBhZGQgZGV2
aWNlIDAzOjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDQ6MDMuMAooWEVOKSBwaHlzZGV2LmM6
MTY0OiBkb20wOiB3cm9uZyBtYXBfcGlycSB0eXBlIDMKKFhFTikgSFZNMTogSFZNIExvYWRlcgoo
WEVOKSBIVk0xOiBEZXRlY3RlZCBYZW4gdjQuMS4zLXJjMS1wcmUKKFhFTikgSFZNMTogQ1BVIHNw
ZWVkIGlzIDMxOTMgTUh6CihYRU4pIEhWTTE6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZl
bnQgY2hhbm5lbCAzCihYRU4pIGlycS5jOjI2NDogRG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgMCAt
PiA1CihYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIGlycS5j
OjI2NDogRG9tMSBQQ0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAooWEVOKSBIVk0xOiBQQ0ktSVNB
IGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKKFhFTikgaXJxLmM6MjY0OiBEb20xIFBDSSBsaW5rIDIg
Y2hhbmdlZCAwIC0+IDExCihYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlEx
MQooWEVOKSBpcnEuYzoyNjQ6IERvbTEgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQooWEVOKSBI
Vk0xOiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQooWEVOKSBIVk0xOiBwY2kgZGV2IDAx
OjIgSU5URC0+SVJRNQooWEVOKSBIVk0xOiBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKKFhFTikg
SFZNMTogcGNpIGRldiAwMzowIElOVEEtPklSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwNDowIElO
VEEtPklSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwNTowIElOVEEtPklSUTEwCihYRU4pIEhWTTE6
IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6ZSAwMjAwMDAwMDogZjAwMDAwMDgKKFhFTikgSFZNMTog
cGNpIGRldiAwMzowIGJhciAxNCBzaXplIDAxMDAwMDAwOiBmMjAwMDAwOAooWEVOKSBIVk0xOiBw
Y2kgZGV2IDA1OjAgYmFyIDMwIHNpemUgMDAwODAwMDA6IGYzMDAwMDAwCihYRU4pIGRvbWN0bC5j
Ojk4NTpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYzMDgwIG1mbj1mYmE4MCBucl9tZm5zPTQwCihY
RU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMWMgc2l6ZSAwMDA0MDAwMDogZjMwODAwMDQKKFhF
TikgSFZNMTogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDIwMDAwOiBmMzBjMDAwMAooWEVO
KSBkb21jdGwuYzo5ODU6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMzBlMCBtZm49ZmJhYzAgbnJf
bWZucz00CihYRU4pIGRvbWN0bC5jOjk5NTpkMCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYzMGUy
IG1mbj1mYmFjMiBucl9tZm5zPTEKKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxNCBzaXpl
IDAwMDA0MDAwOiBmMzBlMDAwNAooWEVOKSBIVk0xOiBwY2kgZGV2IDAyOjAgYmFyIDE0IHNpemUg
MDAwMDEwMDA6IGYzMGU0MDAwCihYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAw
MDAwMDEwMDogMDAwMGMwMDEKKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxMCBzaXplIDAw
MDAwMTAwOiAwMDAwYzEwMQooWEVOKSBkb21jdGwuYzoxMDQxOmQwIGlvcG9ydF9tYXA6YWRkIGZf
Z3BvcnQ9YzEwMCBmX21wb3J0PWUwMDAgbnA9MTAwCihYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBi
YXIgMTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMyMDEKKFhFTikgSFZNMTogcGNpIGRldiAwMToyIGJh
ciAyMCBzaXplIDAwMDAwMDIwOiAwMDAwYzI0MQooWEVOKSBIVk0xOiBwY2kgZGV2IDAxOjEgYmFy
IDIwIHNpemUgMDAwMDAwMTA6IDAwMDBjMjYxCihYRU4pIEhWTTE6IE11bHRpcHJvY2Vzc29yIGlu
aXRpYWxpc2F0aW9uOgooWEVOKSBIVk0xOiAgLSBDUFUwIC4uLiAzNi1iaXQgcGh5cyAuLi4gZml4
ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4KKFhFTikgSFZNMTogIC0gQ1BV
MSAuLi4gMzYtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4u
IGRvbmUuCihYRU4pIEhWTTE6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKFhFTikgSFZNMTog
TG9hZGluZyBST01CSU9TIC4uLgooWEVOKSBIVk0xOiAxMjgyOCBieXRlcyBvZiBST01CSU9TIGhp
Z2gtbWVtb3J5IGV4dGVuc2lvbnM6CihYRU4pIEhWTTE6ICAgUmVsb2NhdGluZyB0byAweGZjMDAw
MDAwLTB4ZmMwMDMyMWMgLi4uIGRvbmUKKFhFTikgSFZNMTogQ3JlYXRpbmcgTVAgdGFibGVzIC4u
LgooWEVOKSBIVk0xOiBMb2FkaW5nIENpcnJ1cyBWR0FCSU9TIC4uLgooWEVOKSBIVk0xOiBMb2Fk
aW5nIFBDSSBPcHRpb24gUk9NIC4uLgooWEVOKSBIVk0xOiAgLSBNYW51ZmFjdHVyZXI6IGh0dHA6
Ly9pcHhlLm9yZwooWEVOKSBIVk0xOiAgLSBQcm9kdWN0IG5hbWU6IGlQWEUKKFhFTikgZG9tY3Rs
LmM6OTg1OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjMwMDAgbWZuPWZiYTAwIG5yX21mbnM9ODAK
KFhFTikgSFZNMTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4KKFhFTikgSFZNMTogIC0gTWFu
dWZhY3R1cmVyOiBMU0kgQ29ycG9yYXRpb24KKFhFTikgSFZNMTogIC0gUHJvZHVjdCBuYW1lOiBM
U0kgTVBJIEJvb3QgU3VwcG9ydAooWEVOKSBkb21jdGwuYzo5OTU6ZDAgbWVtb3J5X21hcDpyZW1v
dmU6IGdmbj1mMzAwMCBtZm49ZmJhMDAgbnJfbWZucz04MAooWEVOKSBIVk0xOiBMb2FkaW5nIEFD
UEkgLi4uCihYRU4pIEhWTTE6ICAtIExvIGRhdGE6IDAwMGVhMDIwLTAwMGVhMDRmCihYRU4pIEhW
TTE6ICAtIEhpIGRhdGE6IGZjMDAzNDAwLWZjMDEzNTFmCihYRU4pIEhWTTE6IHZtODYgVFNTIGF0
IGZjMDEzODAwCihYRU4pIEhWTTE6IEJJT1MgbWFwOgooWEVOKSBIVk0xOiAgYzAwMDAtYzhmZmY6
IFZHQSBCSU9TCihYRU4pIEhWTTE6ICBjOTAwMC1kYTdmZjogRXRoZXJib290IFJPTQooWEVOKSBI
Vk0xOiAgZGE4MDAtZTY3ZmY6IFBDSSBPcHRpb24gUk9NcwooWEVOKSBIVk0xOiAgZWIwMDAtZWIx
ODE6IFNNQklPUyB0YWJsZXMKKFhFTikgSFZNMTogIGYwMDAwLWZmZmZmOiBNYWluIEJJT1MKKFhF
TikgSFZNMTogRTgyMCB0YWJsZToKKFhFTikgSFZNMTogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAw
IC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQooWEVOKSBIVk0xOiAgWzAxXTogMDAwMDAwMDA6MDAw
OWUwMDAgLSAwMDAwMDAwMDowMDA5ZmMwMDogUkVTRVJWRUQKKFhFTikgSFZNMTogIFswMl06IDAw
MDAwMDAwOjAwMDlmYzAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VSVkVECihYRU4pIEhWTTE6
ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUwMDAwCihYRU4pIEhWTTE6
ICBbMDNdOiAwMDAwMDAwMDowMDBlMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRAoo
WEVOKSBIVk0xOiAgWzA0XTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDo4MDAwMDAwMDog
UkFNCihYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDo4MDAwMDAwMCAtIDAwMDAwMDAwOmZjMDAw
MDAwCihYRU4pIEhWTTE6ICBbMDVdOiAwMDAwMDAwMDpmYzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAw
MDAwOiBSRVNFUlZFRAooWEVOKSBIVk0xOiBJbnZva2luZyBST01CSU9TIC4uLgooWEVOKSBIVk0x
OiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAooWEVOKSBz
dGR2Z2EuYzoxNDc6ZDEgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzCihYRU4pIEhW
TTE6IFZHQUJpb3MgJElkOiB2Z2FiaW9zLmMsdiAxLjY3IDIwMDgvMDEvMjcgMDk6NDQ6MTIgdnJ1
cHBlcnQgRXhwICQKKFhFTikgSFZNMTogQm9jaHMgQklPUyAtIGJ1aWxkOiAwNi8yMy85OQooWEVO
KSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAoo
WEVOKSBIVk0xOiBPcHRpb25zOiBhcG1iaW9zIHBjaWJpb3MgZWx0b3JpdG8gUE1NIAooWEVOKSBI
Vk0xOiAKKFhFTikgSFZNMTogYXRhMC0wOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxi
YSBMQ0hTPTEwMjQvMjU1LzYzCihYRU4pIEhWTTE6IGF0YTAgbWFzdGVyOiBRRU1VIEhBUkRESVNL
IEFUQS03IEhhcmQtRGlzayAoMTAyNDAgTUJ5dGVzKQooWEVOKSBIVk0xOiBJREUgdGltZSBvdXQK
KFhFTikgSFZNMTogYXRhMSBtYXN0ZXI6IFFFTVUgRFZELVJPTSBBVEFQSS00IENELVJvbS9EVkQt
Um9tCihYRU4pIEhWTTE6IElERSB0aW1lIG91dAooWEVOKSBIVk0xOiAKKFhFTikgdHJhcHMuYzo0
NTE6ZDAgVW5oYW5kbGVkIG5taSBmYXVsdC90cmFwIFsjMl0gb24gVkNQVSAwIFtlYz0wMDAwXQoo
WEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA3MCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVO
KSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA3MiBub3QgZm91bmQgYXQgaW5kZXggMQooWEVOKSBI
Vk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA3NCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0x
OiBQQ0kgZGV2aWNlIDEwMDA6MDA3NiBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQ
Q0kgZGV2aWNlIDEwMDA6MDA3NyBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kg
ZGV2aWNlIDEwMDA6MDA2NCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2
aWNlIDEwMDA6MDA2NSBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNl
IDEwMDA6MDA4MCBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEw
MDA6MDA4MSBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6
MDA4MiBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4
MyBub3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NCBu
b3QgZm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NSBub3Qg
Zm91bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NiBub3QgZm91
bmQgYXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA4NyBub3QgZm91bmQg
YXQgaW5kZXggMAooWEVOKSBIVk0xOiBQQ0kgZGV2aWNlIDEwMDA6MDA2ZSBub3QgZm91bmQgYXQg
aW5kZXggMAooWEVOKSBIVk0xOiAKKFhFTikgSFZNMTogCihYRU4pIEhWTTE6IFByZXNzIEYxMiBm
b3IgYm9vdCBtZW51LgooWEVOKSBIVk0xOiAKKFhFTikgSFZNMTogQm9vdGluZyBmcm9tIEhhcmQg
RGlzay4uLgooWEVOKSBIVk0xOiBCb290aW5nIGZyb20gMDAwMDo3YzAwCihYRU4pIEhWTTE6IGlu
dDEzX2hhcmRkaXNrOiBmdW5jdGlvbiA0MSwgdW5tYXBwZWQgZGV2aWNlIGZvciBFTERMPTgxCihY
RU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBmdW5jdGlvbiAwOCwgdW5tYXBwZWQgZGV2aWNlIGZv
ciBFTERMPTgxCihYRU4pIEhWTTE6ICoqKiBpbnQgMTVoIGZ1bmN0aW9uIEFYPTAwYzAsIEJYPTAw
MDAgbm90IHlldCBzdXBwb3J0ZWQhCihYRU4pIEhWTTE6ICoqKiBpbnQgMTVoIGZ1bmN0aW9uIEFY
PWVjMDAsIEJYPTAwMDIgbm90IHlldCBzdXBwb3J0ZWQhCihYRU4pIEhWTTE6IEtCRDogdW5zdXBw
b3J0ZWQgaW50IDE2aCBmdW5jdGlvbiAwMwooWEVOKSBIVk0xOiAqKiogaW50IDE1aCBmdW5jdGlv
biBBWD1lOTgwLCBCWD0wMDAwIG5vdCB5ZXQgc3VwcG9ydGVkIQooWEVOKSBIVk0xOiBpbnQxM19o
YXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBI
Vk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxE
TD04MQooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRl
dmljZSBmb3IgRUxETD04MgooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIs
IHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MgooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazog
ZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MwooWEVOKSBIVk0xOiBpbnQx
M19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MwooWEVO
KSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3Ig
RUxETD04NAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVk
IGRldmljZSBmb3IgRUxETD04NAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24g
NDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04NQooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlz
azogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04NQooWEVOKSBIVk0xOiBp
bnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04Ngoo
WEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIHVubWFwcGVkIGRldmljZSBm
b3IgRUxETD04NgooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIHVubWFw
cGVkIGRldmljZSBmb3IgRUxETD04NwooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rp
b24gMDIsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04NwooWEVOKSBIVk0xOiBpbnQxM19oYXJk
ZGlzazogZnVuY3Rpb24gNDEsIEVMREwgb3V0IG9mIHJhbmdlIDg4CihYRU4pIEhWTTE6IGludDEz
X2hhcmRkaXNrOiBmdW5jdGlvbiAwMiwgRUxETCBvdXQgb2YgcmFuZ2UgODgKKFhFTikgSFZNMTog
aW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQxLCBFTERMIG91dCBvZiByYW5nZSA4OQooWEVOKSBI
Vk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIEVMREwgb3V0IG9mIHJhbmdlIDg5CihY
RU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBmdW5jdGlvbiA0MSwgRUxETCBvdXQgb2YgcmFuZ2Ug
OGEKKFhFTikgSFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDAyLCBFTERMIG91dCBvZiBy
YW5nZSA4YQooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gNDEsIEVMREwgb3V0
IG9mIHJhbmdlIDhiCihYRU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBmdW5jdGlvbiAwMiwgRUxE
TCBvdXQgb2YgcmFuZ2UgOGIKKFhFTikgSFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQx
LCBFTERMIG91dCBvZiByYW5nZSA4YwooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rp
b24gMDIsIEVMREwgb3V0IG9mIHJhbmdlIDhjCihYRU4pIEhWTTE6IGludDEzX2hhcmRkaXNrOiBm
dW5jdGlvbiA0MSwgRUxETCBvdXQgb2YgcmFuZ2UgOGQKKFhFTikgSFZNMTogaW50MTNfaGFyZGRp
c2s6IGZ1bmN0aW9uIDAyLCBFTERMIG91dCBvZiByYW5nZSA4ZAooWEVOKSBIVk0xOiBpbnQxM19o
YXJkZGlzazogZnVuY3Rpb24gNDEsIEVMREwgb3V0IG9mIHJhbmdlIDhlCihYRU4pIEhWTTE6IGlu
dDEzX2hhcmRkaXNrOiBmdW5jdGlvbiAwMiwgRUxETCBvdXQgb2YgcmFuZ2UgOGUKKFhFTikgSFZN
MTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQxLCBFTERMIG91dCBvZiByYW5nZSA4ZgooWEVO
KSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMDIsIEVMREwgb3V0IG9mIHJhbmdlIDhm
CihYRU4pIGlycS5jOjMzMDogRG9tMSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVj
dG9yIDB4ZTkKKFhFTikgZG9tY3RsLmM6MTA2NTpkMCBpb3BvcnRfbWFwOnJlbW92ZSBmX2dwb3J0
PWMxMDAgZl9tcG9ydD1lMDAwIG5wPTEwMAooWEVOKSBkb21jdGwuYzoxMDQxOmQwIGlvcG9ydF9t
YXA6YWRkIGZfZ3BvcnQ9YzEwMCBmX21wb3J0PWUwMDAgbnA9MTAwCihYRU4pIGlycS5jOjI2NDog
RG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCihYRU4pIGlycS5jOjI2NDogRG9tMSBQQ0kg
bGluayAxIGNoYW5nZWQgMTAgLT4gMAooWEVOKSBpcnEuYzoyNjQ6IERvbTEgUENJIGxpbmsgMiBj
aGFuZ2VkIDExIC0+IDAKKFhFTikgaXJxLmM6MjY0OiBEb20xIFBDSSBsaW5rIDMgY2hhbmdlZCA1
IC0+IDAK
--485b393aaadf88221704bd6c92bc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--485b393aaadf88221704bd6c92bc--


From xen-devel-bounces@lists.xen.org Wed Apr 11 20:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4D5-0007ji-77; Wed, 11 Apr 2012 20:32:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <atarutin@orionsbelt.net>) id 1SI4D4-0007ja-8Q
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 20:32:10 +0000
Received: from [85.158.143.99:2485] by server-2.bemta-4.messagelabs.com id
	4B/DD-17550-94AE58F4; Wed, 11 Apr 2012 20:32:09 +0000
X-Env-Sender: atarutin@orionsbelt.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334176327!18005752!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27983 invoked from network); 11 Apr 2012 20:32:08 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 20:32:08 -0000
Received: by vbbfs19 with SMTP id fs19so1187396vbb.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 13:32:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=rUrpO+aRxWEKBrPKmA9cFjaFBWS/957hyIn31lMmn7I=;
	b=gYDpv+Nr7z/PmKEc9z7HjdZuEn4NgDppX8C+dIujPD1ocb3N/NUeP06OucH2qOmLKE
	O+ABX+eE0PPxIddHzpJ0ryX9ifecTX+ai5IHDyfeToUF+vFH5nKRsHBmImAhTYIXMXGL
	WaP/E3pf7qn3/DAQ2OVxeNe4hYv1JiI3/xE3ztYeuN7v2poUKKrzU/39KSn1IqdBeod5
	OIjiUgWkqLGGciPN5tMHLCs6hQFyL+6dJnd+gCG6zFjuFJzVwq2MVa3kygqgJtZiahbu
	bjIicc7aP0cJHIsTJE+giITtEiSqQnd2uSsSHzcnJcBp1R6J3LAVlu92xeLNrZ3KfnYj
	Egpg==
Received: by 10.52.17.82 with SMTP id m18mr6792368vdd.89.1334176327092; Wed,
	11 Apr 2012 13:32:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.108.66 with HTTP; Wed, 11 Apr 2012 13:31:46 -0700 (PDT)
X-Originating-IP: [173.220.219.178]
From: Aleksandr Tarutin <atarutin@orionsbelt.net>
Date: Wed, 11 Apr 2012 16:31:46 -0400
Message-ID: <CAO9X3ShgT-GhsfQd8Py937-+0YdOy+Bv5+VyjoecMhD2AUfzNw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQlR16YG/dZi/8vkcK/qzcf6tFGnqwaiRQI9jTZ57sfVvq1zvZDE9L+TmYPJ+n1k5F+asjV0
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4720744176008379218=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4720744176008379218==
Content-Type: multipart/alternative; boundary=bcaec50405d60b48c604bd6d2202

--bcaec50405d60b48c604bd6d2202
Content-Type: text/plain; charset=ISO-8859-1

New findings!

Passthrough worked for a PV domU!

*And*... It worked if i pci-attach the controller to the same PVHVM!

Any suggestions?

-- 
AT.

--bcaec50405d60b48c604bd6d2202
Content-Type: text/html; charset=ISO-8859-1

New findings!<div><br></div><div>Passthrough worked for a PV domU!</div><div><br></div><div>*And*... It worked if i pci-attach the controller to the same PVHVM!</div><div><br></div><div>Any suggestions?</div><div><div><br>

</div>-- <br><div>AT.</div><br>
</div>

--bcaec50405d60b48c604bd6d2202--


--===============4720744176008379218==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4720744176008379218==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 20:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4D5-0007ji-77; Wed, 11 Apr 2012 20:32:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <atarutin@orionsbelt.net>) id 1SI4D4-0007ja-8Q
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 20:32:10 +0000
Received: from [85.158.143.99:2485] by server-2.bemta-4.messagelabs.com id
	4B/DD-17550-94AE58F4; Wed, 11 Apr 2012 20:32:09 +0000
X-Env-Sender: atarutin@orionsbelt.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334176327!18005752!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27983 invoked from network); 11 Apr 2012 20:32:08 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 20:32:08 -0000
Received: by vbbfs19 with SMTP id fs19so1187396vbb.32
	for <xen-devel@lists.xen.org>; Wed, 11 Apr 2012 13:32:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=rUrpO+aRxWEKBrPKmA9cFjaFBWS/957hyIn31lMmn7I=;
	b=gYDpv+Nr7z/PmKEc9z7HjdZuEn4NgDppX8C+dIujPD1ocb3N/NUeP06OucH2qOmLKE
	O+ABX+eE0PPxIddHzpJ0ryX9ifecTX+ai5IHDyfeToUF+vFH5nKRsHBmImAhTYIXMXGL
	WaP/E3pf7qn3/DAQ2OVxeNe4hYv1JiI3/xE3ztYeuN7v2poUKKrzU/39KSn1IqdBeod5
	OIjiUgWkqLGGciPN5tMHLCs6hQFyL+6dJnd+gCG6zFjuFJzVwq2MVa3kygqgJtZiahbu
	bjIicc7aP0cJHIsTJE+giITtEiSqQnd2uSsSHzcnJcBp1R6J3LAVlu92xeLNrZ3KfnYj
	Egpg==
Received: by 10.52.17.82 with SMTP id m18mr6792368vdd.89.1334176327092; Wed,
	11 Apr 2012 13:32:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.108.66 with HTTP; Wed, 11 Apr 2012 13:31:46 -0700 (PDT)
X-Originating-IP: [173.220.219.178]
From: Aleksandr Tarutin <atarutin@orionsbelt.net>
Date: Wed, 11 Apr 2012 16:31:46 -0400
Message-ID: <CAO9X3ShgT-GhsfQd8Py937-+0YdOy+Bv5+VyjoecMhD2AUfzNw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQlR16YG/dZi/8vkcK/qzcf6tFGnqwaiRQI9jTZ57sfVvq1zvZDE9L+TmYPJ+n1k5F+asjV0
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4720744176008379218=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4720744176008379218==
Content-Type: multipart/alternative; boundary=bcaec50405d60b48c604bd6d2202

--bcaec50405d60b48c604bd6d2202
Content-Type: text/plain; charset=ISO-8859-1

New findings!

Passthrough worked for a PV domU!

*And*... It worked if i pci-attach the controller to the same PVHVM!

Any suggestions?

-- 
AT.

--bcaec50405d60b48c604bd6d2202
Content-Type: text/html; charset=ISO-8859-1

New findings!<div><br></div><div>Passthrough worked for a PV domU!</div><div><br></div><div>*And*... It worked if i pci-attach the controller to the same PVHVM!</div><div><br></div><div>Any suggestions?</div><div><div><br>

</div>-- <br><div>AT.</div><br>
</div>

--bcaec50405d60b48c604bd6d2202--


--===============4720744176008379218==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4720744176008379218==--


From xen-devel-bounces@lists.xen.org Wed Apr 11 20:33:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4Dn-0007ln-Ku; Wed, 11 Apr 2012 20:32:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI4Dl-0007lZ-KT
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 20:32:53 +0000
Received: from [85.158.143.35:21178] by server-3.bemta-4.messagelabs.com id
	43/C6-05853-57AE58F4; Wed, 11 Apr 2012 20:32:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334176372!8411808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22223 invoked from network); 11 Apr 2012 20:32:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 20:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,407,1330905600"; d="scan'208";a="11886977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 20:32:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 21:32:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SI4Di-0006cx-Ua;
	Wed, 11 Apr 2012 20:32:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SI4Di-0001BX-CZ;
	Wed, 11 Apr 2012 21:32:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12640-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 21:32:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12640: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12640 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12640/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2    fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
Counting objects: 1   
Counting objects: 2   
Counting objects: 8   
Counting objects: 21   
Counting objects: 43, done.
Compressing objects:  12% (1/8)   
Compressing objects:  25% (2/8)   
Compressing objects:  37% (3/8)   
Compressing objects:  50% (4/8)   
Compressing objects:  62% (5/8)   
Compressing objects:  75% (6/8)   
Compressing objects:  87% (7/8)   
Compressing objects: 100% (8/8)   
Compressing objects: 100% (8/8), done.
Writing objects:   6% (2/31)   
Writing objects:   9% (3/31)   
Writing objects:  12% (4/31)   
Writing objects:  16% (5/31)   
Writing objects:  19% (6/31)   
Writing objects:  22% (7/31)   
Writing objects:  25% (8/31)   
Writing objects:  29% (9/31)   
Writing objects:  32% (10/31)   
Writing objects:  35% (11/31)   
Writing objects:  38% (12/31)   
Writing objects:  41% (13/31)   
Writing objects:  45% (14/31)   
Writing objects:  48% (15/31)   
Writing objects:  51% (16/31)   
Writing objects:  54% (17/31)   
Writing objects:  58% (18/31)   
Writing objects:  61% (19/31)   
Writing objects:  64% (20/31)   
Writing objects:  67% (21/31)   
Writing objects:  70% (22/31)   
Writing objects:  74% (23/31)   
Writing objects:  77% (24/31)   
Writing objects:  80% (25/31)   
Writing objects:  83% (26/31)   
Writing objects:  87% (27/31)   
Writing objects:  90% (28/31)   
Writing objects:  93% (29/31)   
Writing objects:  96% (30/31)   
Writing objects: 100% (31/31)   
Writing objects: 100% (31/31), 6.78 KiB, done.
Total 31 (delta 21), reused 31 (delta 21)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   86a8d63..e161598  e1615984e765751b430f86be679c0b74b5d5cd15 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 20:33:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4Dn-0007ln-Ku; Wed, 11 Apr 2012 20:32:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI4Dl-0007lZ-KT
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 20:32:53 +0000
Received: from [85.158.143.35:21178] by server-3.bemta-4.messagelabs.com id
	43/C6-05853-57AE58F4; Wed, 11 Apr 2012 20:32:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334176372!8411808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22223 invoked from network); 11 Apr 2012 20:32:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 20:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,407,1330905600"; d="scan'208";a="11886977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 20:32:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 21:32:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SI4Di-0006cx-Ua;
	Wed, 11 Apr 2012 20:32:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SI4Di-0001BX-CZ;
	Wed, 11 Apr 2012 21:32:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12640-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 21:32:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12640: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12640 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12640/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2      fail blocked in 11890
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2    fail blocked in 11890

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass

version targeted for testing:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15
baseline version:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable e1615984e765751b430f86be679c0b74b5d5cd15
+ branch=qemu-upstream-unstable
+ revision=e1615984e765751b430f86be679c0b74b5d5cd15
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git e1615984e765751b430f86be679c0b74b5d5cd15:master
Counting objects: 1   
Counting objects: 2   
Counting objects: 8   
Counting objects: 21   
Counting objects: 43, done.
Compressing objects:  12% (1/8)   
Compressing objects:  25% (2/8)   
Compressing objects:  37% (3/8)   
Compressing objects:  50% (4/8)   
Compressing objects:  62% (5/8)   
Compressing objects:  75% (6/8)   
Compressing objects:  87% (7/8)   
Compressing objects: 100% (8/8)   
Compressing objects: 100% (8/8), done.
Writing objects:   6% (2/31)   
Writing objects:   9% (3/31)   
Writing objects:  12% (4/31)   
Writing objects:  16% (5/31)   
Writing objects:  19% (6/31)   
Writing objects:  22% (7/31)   
Writing objects:  25% (8/31)   
Writing objects:  29% (9/31)   
Writing objects:  32% (10/31)   
Writing objects:  35% (11/31)   
Writing objects:  38% (12/31)   
Writing objects:  41% (13/31)   
Writing objects:  45% (14/31)   
Writing objects:  48% (15/31)   
Writing objects:  51% (16/31)   
Writing objects:  54% (17/31)   
Writing objects:  58% (18/31)   
Writing objects:  61% (19/31)   
Writing objects:  64% (20/31)   
Writing objects:  67% (21/31)   
Writing objects:  70% (22/31)   
Writing objects:  74% (23/31)   
Writing objects:  77% (24/31)   
Writing objects:  80% (25/31)   
Writing objects:  83% (26/31)   
Writing objects:  87% (27/31)   
Writing objects:  90% (28/31)   
Writing objects:  93% (29/31)   
Writing objects:  96% (30/31)   
Writing objects: 100% (31/31)   
Writing objects: 100% (31/31), 6.78 KiB, done.
Total 31 (delta 21), reused 31 (delta 21)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   86a8d63..e161598  e1615984e765751b430f86be679c0b74b5d5cd15 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 20:42:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:42:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4MN-0008H9-CA; Wed, 11 Apr 2012 20:41:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI4ML-0008H1-IB
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 20:41:45 +0000
Received: from [85.158.143.35:41896] by server-1.bemta-4.messagelabs.com id
	3B/E8-20925-88CE58F4; Wed, 11 Apr 2012 20:41:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334176903!18183825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 975 invoked from network); 11 Apr 2012 20:41:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 20:41:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,407,1330905600"; d="scan'208";a="11887165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 20:41:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 21:41:43 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SI4MJ-0006fk-9u;
	Wed, 11 Apr 2012 20:41:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SI4MJ-0006DE-7R;
	Wed, 11 Apr 2012 21:41:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12639-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 21:41:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12639: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12639 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12639/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12635
 test-i386-i386-xl             9 guest-start        fail in 12635 pass in 12639

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12627

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5bbda657a016
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=5bbda657a016
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 5bbda657a016
+ branch=xen-unstable
+ revision=5bbda657a016
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 5bbda657a016 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 20:42:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:42:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4MN-0008H9-CA; Wed, 11 Apr 2012 20:41:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI4ML-0008H1-IB
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 20:41:45 +0000
Received: from [85.158.143.35:41896] by server-1.bemta-4.messagelabs.com id
	3B/E8-20925-88CE58F4; Wed, 11 Apr 2012 20:41:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334176903!18183825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 975 invoked from network); 11 Apr 2012 20:41:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 20:41:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,407,1330905600"; d="scan'208";a="11887165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Apr 2012 20:41:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Apr 2012 21:41:43 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SI4MJ-0006fk-9u;
	Wed, 11 Apr 2012 20:41:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SI4MJ-0006DE-7R;
	Wed, 11 Apr 2012 21:41:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12639-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 11 Apr 2012 21:41:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12639: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12639 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12639/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12635
 test-i386-i386-xl             9 guest-start        fail in 12635 pass in 12639

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12627

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5bbda657a016
baseline version:
 xen                  d690c7e896a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=5bbda657a016
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 5bbda657a016
+ branch=xen-unstable
+ revision=5bbda657a016
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 5bbda657a016 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 20:48:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4SO-000071-Hh; Wed, 11 Apr 2012 20:48:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SI4SM-00006v-Po
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 20:47:59 +0000
Received: from [85.158.139.83:26576] by server-2.bemta-5.messagelabs.com id
	3D/9F-17016-DFDE58F4; Wed, 11 Apr 2012 20:47:57 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334177276!23403559!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTM2MDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26599 invoked from network); 11 Apr 2012 20:47:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Apr 2012 20:47:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3E056267D;
	Wed, 11 Apr 2012 23:47:54 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A85D8200F0; Wed, 11 Apr 2012 23:47:54 +0300 (EEST)
Date: Wed, 11 Apr 2012 23:47:54 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Aleksandr Tarutin <atarutin@orionsbelt.net>
Message-ID: <20120411204754.GH12984@reaktio.net>
References: <CAO9X3ShgT-GhsfQd8Py937-+0YdOy+Bv5+VyjoecMhD2AUfzNw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO9X3ShgT-GhsfQd8Py937-+0YdOy+Bv5+VyjoecMhD2AUfzNw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 04:31:46PM -0400, Aleksandr Tarutin wrote:
>    New findings!
>    Passthrough worked for a PV domU!
>    *And*... It worked if i pci-attach the controller to the same PVHVM!
>    Any suggestions?
>

The difference is that when you use a PV domU or pci-attach with PVHVM guest
the LSI Boot/Option ROM is not executed at all. 

PV domUs don't execute Option ROMS, because they don't have a BIOS.
Also when you pci-attach to a running HVM guest, the LSI BIOS/ROM is not executed.

However when you do a full boot of HVM guest with PCI passthru the 
LSI MPT Boot/Option ROM gets executed by Xen HVM ROMBIOS,
and that seems to fail for some reason, so I assume the LSI HBA
is left in some weird semi-initialized or broken state,
and thus the mpt2sas driver fails to work..

I picked the interesting entries from your logs:


Error on the HVM guest VNC console during boot (before grub is executed):
MPT BIOS Fault 09h encountered at adapter PCI(00h,05h,00h)

Xen dmesg:
Xen version 4.1.3-rc1-pre
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: Loading PCI Option ROM ...
(XEN) HVM1:  - Manufacturer: LSI Corporation
(XEN) HVM1:  - Product name: LSI MPI Boot Support
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3000 mfn=fba00 nr_mfns=80
(XEN) HVM1: Invoking ROMBIOS ...

dunno if this is related?:
(XEN) traps.c:451:d0 Unhandled nmi fault/trap [#2] on VCPU 0 [ec=0000]


dom0 lspci:
01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
        Subsystem: LSI Logic / Symbios Logic Device 3020
        Flags: fast devsel, IRQ 16
        I/O ports at e000 [size=256]
        Memory at fbac0000 (64-bit, non-prefetchable) [size=16K]
        Memory at fba80000 (64-bit, non-prefetchable) [size=256K]
        Expansion ROM at fba00000 [disabled] [size=512K]
        Capabilities: [50] Power Management version 3
        Capabilities: [68] Express Endpoint, MSI 00
        Capabilities: [d0] Vital Product Data
        Capabilities: [a8] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [c0] MSI-X: Enable- Count=15 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [138] Power Budgeting <?>
        Kernel driver in use: pciback
        Kernel modules: mpt2sas


HVM guest kernel dmesg:

mpt2sas version 09.101.00.00 loaded
scsi0 : Fusion MPT SAS Host
  alloc irq_desc for 36 on node -1
  alloc kstat_irqs on node -1
mpt2sas 0000:00:05.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36
mpt2sas 0000:00:05.0: setting latency timer to 64
mpt2sas0: 32 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (2053376 kB)
  alloc irq_desc for 48 on node -1
  alloc kstat_irqs on node -1
mpt2sas 0000:00:05.0: irq 48 for MSI/MSI-X
mpt2sas0: PCI-MSI-X enabled: IRQ 48
mpt2sas0: iomem(0x00000000f30e0000), mapped(0xffffc900009e8000), size(16384)
mpt2sas0: ioport(0x000000000000c100), size(256)
mpt2sas0: Allocated physical memory: size(2688 kB)
mpt2sas0: Current Controller Queue Depth(1754), Max Controller Queue Depth(2015)
mpt2sas0: Scatter Gather Elements per IO(128)
mpt2sas0: _base_event_notification: timeout
mf:
        07000000 00000000 00000000 00000000 00000000 0f2f7fff fffffffc ffffffff
        ffffffff 00000000 00000000
mpt2sas0: sending diag reset !!
mpt2sas0: diag reset: SUCCESS
mpt2sas 0000:00:05.0: PCI INT A disabled
mpt2sas0: failure at drivers/scsi/mpt2sas/mpt2sas_scsih.c:7628/_scsih_probe()!



Hopefully someone has more ideas about why the LSI MPT Boot/Option ROM fails..


-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 20:48:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 20:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI4SO-000071-Hh; Wed, 11 Apr 2012 20:48:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SI4SM-00006v-Po
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 20:47:59 +0000
Received: from [85.158.139.83:26576] by server-2.bemta-5.messagelabs.com id
	3D/9F-17016-DFDE58F4; Wed, 11 Apr 2012 20:47:57 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334177276!23403559!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTM2MDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26599 invoked from network); 11 Apr 2012 20:47:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Apr 2012 20:47:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3E056267D;
	Wed, 11 Apr 2012 23:47:54 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A85D8200F0; Wed, 11 Apr 2012 23:47:54 +0300 (EEST)
Date: Wed, 11 Apr 2012 23:47:54 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Aleksandr Tarutin <atarutin@orionsbelt.net>
Message-ID: <20120411204754.GH12984@reaktio.net>
References: <CAO9X3ShgT-GhsfQd8Py937-+0YdOy+Bv5+VyjoecMhD2AUfzNw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO9X3ShgT-GhsfQd8Py937-+0YdOy+Bv5+VyjoecMhD2AUfzNw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 04:31:46PM -0400, Aleksandr Tarutin wrote:
>    New findings!
>    Passthrough worked for a PV domU!
>    *And*... It worked if i pci-attach the controller to the same PVHVM!
>    Any suggestions?
>

The difference is that when you use a PV domU or pci-attach with PVHVM guest
the LSI Boot/Option ROM is not executed at all. 

PV domUs don't execute Option ROMS, because they don't have a BIOS.
Also when you pci-attach to a running HVM guest, the LSI BIOS/ROM is not executed.

However when you do a full boot of HVM guest with PCI passthru the 
LSI MPT Boot/Option ROM gets executed by Xen HVM ROMBIOS,
and that seems to fail for some reason, so I assume the LSI HBA
is left in some weird semi-initialized or broken state,
and thus the mpt2sas driver fails to work..

I picked the interesting entries from your logs:


Error on the HVM guest VNC console during boot (before grub is executed):
MPT BIOS Fault 09h encountered at adapter PCI(00h,05h,00h)

Xen dmesg:
Xen version 4.1.3-rc1-pre
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: Loading PCI Option ROM ...
(XEN) HVM1:  - Manufacturer: LSI Corporation
(XEN) HVM1:  - Product name: LSI MPI Boot Support
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3000 mfn=fba00 nr_mfns=80
(XEN) HVM1: Invoking ROMBIOS ...

dunno if this is related?:
(XEN) traps.c:451:d0 Unhandled nmi fault/trap [#2] on VCPU 0 [ec=0000]


dom0 lspci:
01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
        Subsystem: LSI Logic / Symbios Logic Device 3020
        Flags: fast devsel, IRQ 16
        I/O ports at e000 [size=256]
        Memory at fbac0000 (64-bit, non-prefetchable) [size=16K]
        Memory at fba80000 (64-bit, non-prefetchable) [size=256K]
        Expansion ROM at fba00000 [disabled] [size=512K]
        Capabilities: [50] Power Management version 3
        Capabilities: [68] Express Endpoint, MSI 00
        Capabilities: [d0] Vital Product Data
        Capabilities: [a8] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [c0] MSI-X: Enable- Count=15 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [138] Power Budgeting <?>
        Kernel driver in use: pciback
        Kernel modules: mpt2sas


HVM guest kernel dmesg:

mpt2sas version 09.101.00.00 loaded
scsi0 : Fusion MPT SAS Host
  alloc irq_desc for 36 on node -1
  alloc kstat_irqs on node -1
mpt2sas 0000:00:05.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36
mpt2sas 0000:00:05.0: setting latency timer to 64
mpt2sas0: 32 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (2053376 kB)
  alloc irq_desc for 48 on node -1
  alloc kstat_irqs on node -1
mpt2sas 0000:00:05.0: irq 48 for MSI/MSI-X
mpt2sas0: PCI-MSI-X enabled: IRQ 48
mpt2sas0: iomem(0x00000000f30e0000), mapped(0xffffc900009e8000), size(16384)
mpt2sas0: ioport(0x000000000000c100), size(256)
mpt2sas0: Allocated physical memory: size(2688 kB)
mpt2sas0: Current Controller Queue Depth(1754), Max Controller Queue Depth(2015)
mpt2sas0: Scatter Gather Elements per IO(128)
mpt2sas0: _base_event_notification: timeout
mf:
        07000000 00000000 00000000 00000000 00000000 0f2f7fff fffffffc ffffffff
        ffffffff 00000000 00000000
mpt2sas0: sending diag reset !!
mpt2sas0: diag reset: SUCCESS
mpt2sas 0000:00:05.0: PCI INT A disabled
mpt2sas0: failure at drivers/scsi/mpt2sas/mpt2sas_scsih.c:7628/_scsih_probe()!



Hopefully someone has more ideas about why the LSI MPT Boot/Option ROM fails..


-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 21:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 21:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI50T-0000j4-31; Wed, 11 Apr 2012 21:23:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SI50R-0000iz-L9
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 21:23:11 +0000
Received: from [85.158.143.35:64059] by server-2.bemta-4.messagelabs.com id
	19/23-17550-E36F58F4; Wed, 11 Apr 2012 21:23:10 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334179388!12277325!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1495 invoked from network); 11 Apr 2012 21:23:10 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 21:23:10 -0000
Received: by dadp12 with SMTP id p12so2117895dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 14:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=0qPS4erbKYZHpfh1Lw2nbQaKC/JpFM982MogYg6+zIY=;
	b=MF6CU6XR9mREew5Gj+L8n/X3ir/lU0DZn2J0XW3/kRmDMVwAQO7bP07xpEJa3meGrJ
	ETolY91QxHLnVTrh3NIwWTvY1ET2yAxsgu0wWjscbO2594bAXrsrIf+Q9SpKtkDQNOgz
	cepsM3mJyVC7dcmZO550UMWE+obignuqZ6iAXlZnf5EZ94D6xcX6+z5YFcURnuDYoPsk
	u3BCa9odrApZNnO5RZyuZD540S5x2e3yQFK1r891MPDiwezyWeg9XBVm5Oge5wKSUYle
	2i/sAmOfdgdk/znem/74dfnn5xnsF5zKZKPBP779H/X1rTDEu4NlY20RJGtNOM1lTxEw
	sCPA==
MIME-Version: 1.0
Received: by 10.68.235.5 with SMTP id ui5mr765771pbc.159.1334179387331; Wed,
	11 Apr 2012 14:23:07 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 11 Apr 2012 14:23:07 -0700 (PDT)
Date: Thu, 12 Apr 2012 05:23:07 +0800
Message-ID: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This is just my experience about issues I encountered when upgrade
from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
changeset 25191:a95fc7decc83.

1. Immediately after upgrade, xl list show such error:

# xl list
libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
Permission denied
libxl_domain_infolist failed.

After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
there are running domUs... this might cause issues to shutdown?  I
will downgrade and repeat such test to confirm.  Might be worth a note
in upgrading note about this if this is intended?

2. localtime setting not working.  Set to localtime=1 doesn't seems to
work whereby setting rtc_timeoffset works.  Any idea?

3. xl trigger hvmdomain power still never remove those related
iptables forward rules.  This is the same problem when I test in
xen-4.1-testing.  Refer to
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00771.html
about past report.  When test in xen-4.1-testing, one funny behaviour
is if I start hvmdomain using xm then use xl trigger hvmdomain power
does remove those iptables related rule chain.

I shall do more testing when time permit and sorry if this report is
useless to anyone.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 21:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 21:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI50T-0000j4-31; Wed, 11 Apr 2012 21:23:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SI50R-0000iz-L9
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 21:23:11 +0000
Received: from [85.158.143.35:64059] by server-2.bemta-4.messagelabs.com id
	19/23-17550-E36F58F4; Wed, 11 Apr 2012 21:23:10 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334179388!12277325!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1495 invoked from network); 11 Apr 2012 21:23:10 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 21:23:10 -0000
Received: by dadp12 with SMTP id p12so2117895dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 14:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=0qPS4erbKYZHpfh1Lw2nbQaKC/JpFM982MogYg6+zIY=;
	b=MF6CU6XR9mREew5Gj+L8n/X3ir/lU0DZn2J0XW3/kRmDMVwAQO7bP07xpEJa3meGrJ
	ETolY91QxHLnVTrh3NIwWTvY1ET2yAxsgu0wWjscbO2594bAXrsrIf+Q9SpKtkDQNOgz
	cepsM3mJyVC7dcmZO550UMWE+obignuqZ6iAXlZnf5EZ94D6xcX6+z5YFcURnuDYoPsk
	u3BCa9odrApZNnO5RZyuZD540S5x2e3yQFK1r891MPDiwezyWeg9XBVm5Oge5wKSUYle
	2i/sAmOfdgdk/znem/74dfnn5xnsF5zKZKPBP779H/X1rTDEu4NlY20RJGtNOM1lTxEw
	sCPA==
MIME-Version: 1.0
Received: by 10.68.235.5 with SMTP id ui5mr765771pbc.159.1334179387331; Wed,
	11 Apr 2012 14:23:07 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 11 Apr 2012 14:23:07 -0700 (PDT)
Date: Thu, 12 Apr 2012 05:23:07 +0800
Message-ID: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This is just my experience about issues I encountered when upgrade
from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
changeset 25191:a95fc7decc83.

1. Immediately after upgrade, xl list show such error:

# xl list
libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
Permission denied
libxl_domain_infolist failed.

After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
there are running domUs... this might cause issues to shutdown?  I
will downgrade and repeat such test to confirm.  Might be worth a note
in upgrading note about this if this is intended?

2. localtime setting not working.  Set to localtime=1 doesn't seems to
work whereby setting rtc_timeoffset works.  Any idea?

3. xl trigger hvmdomain power still never remove those related
iptables forward rules.  This is the same problem when I test in
xen-4.1-testing.  Refer to
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00771.html
about past report.  When test in xen-4.1-testing, one funny behaviour
is if I start hvmdomain using xm then use xl trigger hvmdomain power
does remove those iptables related rule chain.

I shall do more testing when time permit and sorry if this report is
useless to anyone.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 23:04:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 23:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI6a6-0001Gz-B4; Wed, 11 Apr 2012 23:04:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SI6a5-0001Gu-65
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 23:04:05 +0000
Received: from [85.158.138.51:64003] by server-10.bemta-3.messagelabs.com id
	A2/CC-29478-4ED068F4; Wed, 11 Apr 2012 23:04:04 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334185443!19938728!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1647 invoked from network); 11 Apr 2012 23:04:03 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 23:04:03 -0000
Received: by werm1 with SMTP id m1so1052375wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 16:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=cWPovlnmP20B08TfjKa2EEqAaHJbQoxWY+Kx1yseanU=;
	b=OVe38ZL93gfWvohE08IKAXxEbgWiDOVMaYf2wNxmLk7fMN7QRI96VVPImFuXdqxLOo
	CeYtpwFmMOuLgkeM1RknloBtlkEUit36xK0/80cP+ooEnQUQZkU7Fo9kf302JW1ulJSa
	sm4jwu00vkxR72iKBlV/nPzFZbafFGKKQDaonk0qgZIHgOc+UZvvWxgUxKFW6DAHb2uq
	4UK1aZFcciWqNtLkZf0iB9wtCmjJukc0b2HtCtlHM2OmD5aLcED2G8oWTBIfQtqzANnJ
	fTIKbvGzMWysq0bQyhek53s3oZ3s3+gleWOsrnUFXF6g7fJrlI7PntAYzoBS7bMg2rt6
	hbqw==
MIME-Version: 1.0
Received: by 10.180.103.35 with SMTP id ft3mr590612wib.0.1334185443085; Wed,
	11 Apr 2012 16:04:03 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Wed, 11 Apr 2012 16:04:02 -0700 (PDT)
Date: Wed, 11 Apr 2012 16:04:02 -0700
Message-ID: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=f46d043bd7e8664e7c04bd6f41dc
Cc: Gianluca Guida <gianluca.guida@citrix.com>
Subject: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
	paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--f46d043bd7e8664e7c04bd6f41dc
Content-Type: text/plain; charset=ISO-8859-1

Hello,

HAP paging mode guests use direct MSR read/write into the VMCS/VMCB
for the guest PAT table, while the current  save/restore code was
accessing only the pat_cr field in hvm_vcpu, used when intercepting
the MSR mostly in shadow mode (the Intel scenario is a bit more
complicated).
This patch fixes this issue creating a new couple of hvm_funcs,
get/set_guest_pat, that access the right PAT table based on the paging
mode and guest configuration.

As a major caveat, I haven't tested this patch on AMD, for lack of hardware.

Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>

--f46d043bd7e8664e7c04bd6f41dc
Content-Type: application/octet-stream; name="save-pat-hap.patch"
Content-Disposition: attachment; filename="save-pat-hap.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0w9m8dn0

ZGlmZiAtciA1YmJkYTY1N2EwMTYgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJj
aC94ODYvaHZtL2h2bS5jCVR1ZSBBcHIgMTAgMTA6NDI6MzUgMjAxMiArMDEwMAorKysgYi94ZW4v
YXJjaC94ODYvaHZtL2h2bS5jCVdlZCBBcHIgMTEgMDM6MDM6NTAgMjAxMiAtMDcwMApAQCAtMjE2
LDYgKzIxNiwzMSBAQAogICAgICAgICBodm1fZnVuY3Muc2V0X3JkdHNjX2V4aXRpbmcodiwgZW5h
YmxlKTsKIH0KIAordm9pZCBodm1fZ2V0X2d1ZXN0X3BhdChzdHJ1Y3QgdmNwdSAqdiwgdTY0ICpn
dWVzdF9wYXQpCit7CisgICAgaWYgKCAhaHZtX2Z1bmNzLmdldF9ndWVzdF9wYXQodiwgZ3Vlc3Rf
cGF0KSApCisgICAgICAgICpndWVzdF9wYXQgPSB2LT5hcmNoLmh2bV92Y3B1LnBhdF9jcjsKK30K
KworaW50IGh2bV9zZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3Vlc3RfcGF0KQor
eworICAgIGludCBpOworICAgIHVpbnQ4X3QgKnZhbHVlID0gKHVpbnQ4X3QgKikmZ3Vlc3RfcGF0
OworCisgICAgZm9yICggaSA9IDA7IGkgPCA4OyBpKysgKQorICAgICAgICBpZiAoIHVubGlrZWx5
KCEodmFsdWVbaV0gPT0gMCB8fCB2YWx1ZVtpXSA9PSAxIHx8CisgICAgICAgICAgICAgICAgICAg
ICAgICB2YWx1ZVtpXSA9PSA0IHx8IHZhbHVlW2ldID09IDUgfHwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIHZhbHVlW2ldID09IDYgfHwgdmFsdWVbaV0gPT0gNykpICkgeworICAgICAgICAgICAg
SFZNX0RCR19MT0coREJHX0xFVkVMX01TUiwgImludmFsaWQgZ3Vlc3QgUEFUOiAlIlBSSXg2NCJc
biIsCisgICAgICAgICAgICAgICAgICAgICAgICBndWVzdF9wYXQpOyAKKyAgICAgICAgICAgIHJl
dHVybiAwOworICAgICAgICB9CisKKyAgICBpZiAoICFodm1fZnVuY3Muc2V0X2d1ZXN0X3BhdCh2
LCBndWVzdF9wYXQpICkKKyAgICAgICAgdi0+YXJjaC5odm1fdmNwdS5wYXRfY3IgPSBndWVzdF9w
YXQ7CisgICAgcmV0dXJuIDE7Cit9CisKIHZvaWQgaHZtX3NldF9ndWVzdF90c2Moc3RydWN0IHZj
cHUgKnYsIHU2NCBndWVzdF90c2MpCiB7CiAgICAgdWludDY0X3QgdHNjOwpAQCAtMjc5Niw3ICsy
ODIxLDcgQEAKICAgICAgICAgYnJlYWs7CiAKICAgICBjYXNlIE1TUl9JQTMyX0NSX1BBVDoKLSAg
ICAgICAgKm1zcl9jb250ZW50ID0gdi0+YXJjaC5odm1fdmNwdS5wYXRfY3I7CisgICAgICAgIGh2
bV9nZXRfZ3Vlc3RfcGF0KHYsIG1zcl9jb250ZW50KTsKICAgICAgICAgYnJlYWs7CiAKICAgICBj
YXNlIE1TUl9NVFJSY2FwOgpAQCAtMjkxMiw3ICsyOTM3LDcgQEAKICAgICAgICAgYnJlYWs7CiAK
ICAgICBjYXNlIE1TUl9JQTMyX0NSX1BBVDoKLSAgICAgICAgaWYgKCAhcGF0X21zcl9zZXQoJnYt
PmFyY2guaHZtX3ZjcHUucGF0X2NyLCBtc3JfY29udGVudCkgKQorICAgICAgICBpZiAoICFodm1f
c2V0X2d1ZXN0X3BhdCh2LCBtc3JfY29udGVudCkgKQogICAgICAgICAgICBnb3RvIGdwX2ZhdWx0
OwogICAgICAgICBicmVhazsKIApkaWZmIC1yIDViYmRhNjU3YTAxNiB4ZW4vYXJjaC94ODYvaHZt
L210cnIuYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL210cnIuYwlUdWUgQXByIDEwIDEwOjQyOjM1
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L2h2bS9tdHJyLmMJV2VkIEFwciAxMSAwMzow
Mzo1MCAyMDEyIC0wNzAwCkBAIC00MDMsMjYgKzQwMyw2IEBACiAgICAgcmV0dXJuIHBhdF90eXBl
XzJfcHRlX2ZsYWdzKHBhdF9lbnRyeV92YWx1ZSk7CiB9CiAKLS8qIEhlbHBlciBmdW50aW9ucyBm
b3Igc2V0aW5nIG10cnIvcGF0ICovCi1ib29sX3QgcGF0X21zcl9zZXQodWludDY0X3QgKnBhdCwg
dWludDY0X3QgbXNyX2NvbnRlbnQpCi17Ci0gICAgdWludDhfdCAqdmFsdWUgPSAodWludDhfdCop
Jm1zcl9jb250ZW50OwotICAgIGludDMyX3QgaTsKLQotICAgIGlmICggKnBhdCAhPSBtc3JfY29u
dGVudCApCi0gICAgewotICAgICAgICBmb3IgKCBpID0gMDsgaSA8IDg7IGkrKyApCi0gICAgICAg
ICAgICBpZiAoIHVubGlrZWx5KCEodmFsdWVbaV0gPT0gMCB8fCB2YWx1ZVtpXSA9PSAxIHx8Ci0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWVbaV0gPT0gNCB8fCB2YWx1ZVtpXSA9PSA1
IHx8Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWVbaV0gPT0gNiB8fCB2YWx1ZVtp
XSA9PSA3KSkgKQotICAgICAgICAgICAgICAgIHJldHVybiAwOwotCi0gICAgICAgICpwYXQgPSBt
c3JfY29udGVudDsKLSAgICB9Ci0KLSAgICByZXR1cm4gMTsKLX0KLQogYm9vbF90IG10cnJfZGVm
X3R5cGVfbXNyX3NldChzdHJ1Y3QgbXRycl9zdGF0ZSAqbSwgdWludDY0X3QgbXNyX2NvbnRlbnQp
CiB7CiAgICAgdWludDhfdCBkZWZfdHlwZSA9IG1zcl9jb250ZW50ICYgMHhmZjsKQEAgLTYzMSw3
ICs2MTEsNyBAQAogICAgIHsKICAgICAgICAgbXRycl9zdGF0ZSA9ICZ2LT5hcmNoLmh2bV92Y3B1
Lm10cnI7CiAKLSAgICAgICAgaHdfbXRyci5tc3JfcGF0X2NyID0gdi0+YXJjaC5odm1fdmNwdS5w
YXRfY3I7CisgICAgICAgIGh2bV9nZXRfZ3Vlc3RfcGF0KHYsICZod19tdHJyLm1zcl9wYXRfY3Ip
OwogCiAgICAgICAgIGh3X210cnIubXNyX210cnJfZGVmX3R5cGUgPSBtdHJyX3N0YXRlLT5kZWZf
dHlwZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IChtdHJyX3N0YXRlLT5lbmFi
bGVkIDw8IDEwKTsKQEAgLTY3Nyw3ICs2NTcsNyBAQAogCiAgICAgbXRycl9zdGF0ZSA9ICZ2LT5h
cmNoLmh2bV92Y3B1Lm10cnI7CiAKLSAgICBwYXRfbXNyX3NldCgmdi0+YXJjaC5odm1fdmNwdS5w
YXRfY3IsIGh3X210cnIubXNyX3BhdF9jcik7CisgICAgaHZtX3NldF9ndWVzdF9wYXQodiwgaHdf
bXRyci5tc3JfcGF0X2NyKTsKIAogICAgIG10cnJfc3RhdGUtPm10cnJfY2FwID0gaHdfbXRyci5t
c3JfbXRycl9jYXA7CiAKZGlmZiAtciA1YmJkYTY1N2EwMTYgeGVuL2FyY2gveDg2L2h2bS9zdm0v
c3ZtLmMKLS0tIGEveGVuL2FyY2gveDg2L2h2bS9zdm0vc3ZtLmMJVHVlIEFwciAxMCAxMDo0Mjoz
NSAyMDEyICswMTAwCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL3N2bS5jCVdlZCBBcHIgMTEg
MDM6MDM6NTAgMjAxMiAtMDcwMApAQCAtNjQ1LDYgKzY0NSwyOCBAQAogICAgICAgICBzdm1fdm1s
b2FkKHZtY2IpOwogfQogCitzdGF0aWMgaW50IHN2bV9zZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1
ICp2LCB1NjQgZ3BhdCkKK3sKKyAgICBzdHJ1Y3Qgdm1jYl9zdHJ1Y3QgKnZtY2IgPSB2LT5hcmNo
Lmh2bV9zdm0udm1jYjsKKworICAgIGlmICggIXBhZ2luZ19tb2RlX2hhcCh2LT5kb21haW4pICkK
KyAgICAgICAgcmV0dXJuIDA7CisKKyAgICB2bWNiX3NldF9nX3BhdCh2bWNiLCBncGF0KTsKKyAg
ICByZXR1cm4gMTsKK30KKworc3RhdGljIGludCBzdm1fZ2V0X2d1ZXN0X3BhdChzdHJ1Y3QgdmNw
dSAqdiwgdTY0ICpncGF0KQoreworICAgIHN0cnVjdCB2bWNiX3N0cnVjdCAqdm1jYiA9IHYtPmFy
Y2guaHZtX3N2bS52bWNiOworCisgICAgaWYgKCAhcGFnaW5nX21vZGVfaGFwKHYtPmRvbWFpbikg
KQorICAgICAgICByZXR1cm4gMDsKKworICAgICpncGF0ID0gdm1jYl9nZXRfZ19wYXQodm1jYik7
CisgICAgcmV0dXJuIDE7Cit9CisKIHN0YXRpYyB1aW50NjRfdCBzdm1fZ2V0X3RzY19vZmZzZXQo
dWludDY0X3QgaG9zdF90c2MsIHVpbnQ2NF90IGd1ZXN0X3RzYywKICAgICB1aW50NjRfdCByYXRp
bykKIHsKQEAgLTE5NjQsNiArMTk4Niw4IEBACiAgICAgLnVwZGF0ZV9ob3N0X2NyMyAgICAgID0g
c3ZtX3VwZGF0ZV9ob3N0X2NyMywKICAgICAudXBkYXRlX2d1ZXN0X2NyICAgICAgPSBzdm1fdXBk
YXRlX2d1ZXN0X2NyLAogICAgIC51cGRhdGVfZ3Vlc3RfZWZlciAgICA9IHN2bV91cGRhdGVfZ3Vl
c3RfZWZlciwKKyAgICAuc2V0X2d1ZXN0X3BhdCAgICAgICAgPSBzdm1fc2V0X2d1ZXN0X3BhdCwK
KyAgICAuZ2V0X2d1ZXN0X3BhdCAgICAgICAgPSBzdm1fZ2V0X2d1ZXN0X3BhdCwKICAgICAuc2V0
X3RzY19vZmZzZXQgICAgICAgPSBzdm1fc2V0X3RzY19vZmZzZXQsCiAgICAgLmluamVjdF9leGNl
cHRpb24gICAgID0gc3ZtX2luamVjdF9leGNlcHRpb24sCiAgICAgLmluaXRfaHlwZXJjYWxsX3Bh
Z2UgID0gc3ZtX2luaXRfaHlwZXJjYWxsX3BhZ2UsCmRpZmYgLXIgNWJiZGE2NTdhMDE2IHhlbi9h
cmNoL3g4Ni9odm0vdm14L3ZteC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jCVR1
ZSBBcHIgMTAgMTA6NDI6MzUgMjAxMiArMDEwMAorKysgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC92
bXguYwlXZWQgQXByIDExIDAzOjAzOjUwIDIwMTIgLTA3MDAKQEAgLTk0Miw2ICs5NDIsMzQgQEAK
ICAgICB2bXhfdm1jc19leGl0KHYpOwogfQogCitzdGF0aWMgaW50IHZteF9zZXRfZ3Vlc3RfcGF0
KHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3BhdCkKK3sKKyAgICBpZiAoICFjcHVfaGFzX3ZteF9wYXQg
fHwgIXBhZ2luZ19tb2RlX2hhcCh2LT5kb21haW4pICkKKyAgICAgICAgcmV0dXJuIDA7CisKKyAg
ICB2bXhfdm1jc19lbnRlcih2KTsKKyAgICBfX3Ztd3JpdGUoR1VFU1RfUEFULCBncGF0KTsKKyNp
ZmRlZiBfX2kzODZfXworICAgIF9fdm13cml0ZShHVUVTVF9QQVRfSElHSCwgZ3BhdCA+PiAzMik7
CisjZW5kaWYKKyAgICB2bXhfdm1jc19leGl0KHYpOworICAgIHJldHVybiAxOworfQorCitzdGF0
aWMgaW50IHZteF9nZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1ICp2LCB1NjQgKmdwYXQpCit7Cisg
ICAgaWYgKCAhY3B1X2hhc192bXhfcGF0IHx8ICFwYWdpbmdfbW9kZV9oYXAodi0+ZG9tYWluKSAp
CisgICAgICAgIHJldHVybiAwOworCisgICAgdm14X3ZtY3NfZW50ZXIodik7CisgICAgKmdwYXQg
PSBfX3ZtcmVhZChHVUVTVF9QQVQpOworI2lmZGVmIF9faTM4Nl9fCisgICAgKmdwYXQgfD0gKHU2
NClfX3ZtcmVhZChHVUVTVF9QQVRfSElHSCkgPDwgMzI7CisjZW5kaWYKKyAgICB2bXhfdm1jc19l
eGl0KHYpOworICAgIHJldHVybiAxOworfQorCiBzdGF0aWMgdm9pZCB2bXhfc2V0X3RzY19vZmZz
ZXQoc3RydWN0IHZjcHUgKnYsIHU2NCBvZmZzZXQpCiB7CiAgICAgdm14X3ZtY3NfZW50ZXIodik7
CkBAIC0xNDg2LDYgKzE1MTQsOCBAQAogICAgIC51cGRhdGVfaG9zdF9jcjMgICAgICA9IHZteF91
cGRhdGVfaG9zdF9jcjMsCiAgICAgLnVwZGF0ZV9ndWVzdF9jciAgICAgID0gdm14X3VwZGF0ZV9n
dWVzdF9jciwKICAgICAudXBkYXRlX2d1ZXN0X2VmZXIgICAgPSB2bXhfdXBkYXRlX2d1ZXN0X2Vm
ZXIsCisgICAgLnNldF9ndWVzdF9wYXQgICAgICAgID0gdm14X3NldF9ndWVzdF9wYXQsCisgICAg
LmdldF9ndWVzdF9wYXQgICAgICAgID0gdm14X2dldF9ndWVzdF9wYXQsCiAgICAgLnNldF90c2Nf
b2Zmc2V0ICAgICAgID0gdm14X3NldF90c2Nfb2Zmc2V0LAogICAgIC5pbmplY3RfZXhjZXB0aW9u
ICAgICA9IHZteF9pbmplY3RfZXhjZXB0aW9uLAogICAgIC5pbml0X2h5cGVyY2FsbF9wYWdlICA9
IHZteF9pbml0X2h5cGVyY2FsbF9wYWdlLApkaWZmIC1yIDViYmRhNjU3YTAxNiB4ZW4vaW5jbHVk
ZS9hc20teDg2L2h2bS9odm0uaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9odm0uaAlU
dWUgQXByIDEwIDEwOjQyOjM1IDIwMTIgKzAxMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9o
dm0vaHZtLmgJV2VkIEFwciAxMSAwMzowMzo1MCAyMDEyIC0wNzAwCkBAIC0xMTgsNiArMTE4LDkg
QEAKICAgICB2b2lkICgqdXBkYXRlX2d1ZXN0X2NyKShzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQg
aW50IGNyKTsKICAgICB2b2lkICgqdXBkYXRlX2d1ZXN0X2VmZXIpKHN0cnVjdCB2Y3B1ICp2KTsK
IAorICAgIGludCAgKCpnZXRfZ3Vlc3RfcGF0KShzdHJ1Y3QgdmNwdSAqdiwgdTY0ICopOworICAg
IGludCAgKCpzZXRfZ3Vlc3RfcGF0KShzdHJ1Y3QgdmNwdSAqdiwgdTY0KTsKKwogICAgIHZvaWQg
KCpzZXRfdHNjX29mZnNldCkoc3RydWN0IHZjcHUgKnYsIHU2NCBvZmZzZXQpOwogCiAgICAgdm9p
ZCAoKmluamVjdF9leGNlcHRpb24pKHVuc2lnbmVkIGludCB0cmFwbnIsIGludCBlcnJjb2RlLApA
QCAtMjAwLDYgKzIwMyw5IEBACiAKIGJvb2xfdCBodm1fc2VuZF9hc3Npc3RfcmVxKHN0cnVjdCB2
Y3B1ICp2KTsKIAordm9pZCBodm1fZ2V0X2d1ZXN0X3BhdChzdHJ1Y3QgdmNwdSAqdiwgdTY0ICpn
dWVzdF9wYXQpOworaW50IGh2bV9zZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3Vl
c3RfcGF0KTsKKwogdm9pZCBodm1fc2V0X2d1ZXN0X3RzYyhzdHJ1Y3QgdmNwdSAqdiwgdTY0IGd1
ZXN0X3RzYyk7CiB1NjQgaHZtX2dldF9ndWVzdF90c2Moc3RydWN0IHZjcHUgKnYpOwogCg==
--f46d043bd7e8664e7c04bd6f41dc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d043bd7e8664e7c04bd6f41dc--


From xen-devel-bounces@lists.xen.org Wed Apr 11 23:04:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 23:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI6a6-0001Gz-B4; Wed, 11 Apr 2012 23:04:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SI6a5-0001Gu-65
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 23:04:05 +0000
Received: from [85.158.138.51:64003] by server-10.bemta-3.messagelabs.com id
	A2/CC-29478-4ED068F4; Wed, 11 Apr 2012 23:04:04 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334185443!19938728!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1647 invoked from network); 11 Apr 2012 23:04:03 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Apr 2012 23:04:03 -0000
Received: by werm1 with SMTP id m1so1052375wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 16:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=cWPovlnmP20B08TfjKa2EEqAaHJbQoxWY+Kx1yseanU=;
	b=OVe38ZL93gfWvohE08IKAXxEbgWiDOVMaYf2wNxmLk7fMN7QRI96VVPImFuXdqxLOo
	CeYtpwFmMOuLgkeM1RknloBtlkEUit36xK0/80cP+ooEnQUQZkU7Fo9kf302JW1ulJSa
	sm4jwu00vkxR72iKBlV/nPzFZbafFGKKQDaonk0qgZIHgOc+UZvvWxgUxKFW6DAHb2uq
	4UK1aZFcciWqNtLkZf0iB9wtCmjJukc0b2HtCtlHM2OmD5aLcED2G8oWTBIfQtqzANnJ
	fTIKbvGzMWysq0bQyhek53s3oZ3s3+gleWOsrnUFXF6g7fJrlI7PntAYzoBS7bMg2rt6
	hbqw==
MIME-Version: 1.0
Received: by 10.180.103.35 with SMTP id ft3mr590612wib.0.1334185443085; Wed,
	11 Apr 2012 16:04:03 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Wed, 11 Apr 2012 16:04:02 -0700 (PDT)
Date: Wed, 11 Apr 2012 16:04:02 -0700
Message-ID: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=f46d043bd7e8664e7c04bd6f41dc
Cc: Gianluca Guida <gianluca.guida@citrix.com>
Subject: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
	paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--f46d043bd7e8664e7c04bd6f41dc
Content-Type: text/plain; charset=ISO-8859-1

Hello,

HAP paging mode guests use direct MSR read/write into the VMCS/VMCB
for the guest PAT table, while the current  save/restore code was
accessing only the pat_cr field in hvm_vcpu, used when intercepting
the MSR mostly in shadow mode (the Intel scenario is a bit more
complicated).
This patch fixes this issue creating a new couple of hvm_funcs,
get/set_guest_pat, that access the right PAT table based on the paging
mode and guest configuration.

As a major caveat, I haven't tested this patch on AMD, for lack of hardware.

Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>

--f46d043bd7e8664e7c04bd6f41dc
Content-Type: application/octet-stream; name="save-pat-hap.patch"
Content-Disposition: attachment; filename="save-pat-hap.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0w9m8dn0

ZGlmZiAtciA1YmJkYTY1N2EwMTYgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJj
aC94ODYvaHZtL2h2bS5jCVR1ZSBBcHIgMTAgMTA6NDI6MzUgMjAxMiArMDEwMAorKysgYi94ZW4v
YXJjaC94ODYvaHZtL2h2bS5jCVdlZCBBcHIgMTEgMDM6MDM6NTAgMjAxMiAtMDcwMApAQCAtMjE2
LDYgKzIxNiwzMSBAQAogICAgICAgICBodm1fZnVuY3Muc2V0X3JkdHNjX2V4aXRpbmcodiwgZW5h
YmxlKTsKIH0KIAordm9pZCBodm1fZ2V0X2d1ZXN0X3BhdChzdHJ1Y3QgdmNwdSAqdiwgdTY0ICpn
dWVzdF9wYXQpCit7CisgICAgaWYgKCAhaHZtX2Z1bmNzLmdldF9ndWVzdF9wYXQodiwgZ3Vlc3Rf
cGF0KSApCisgICAgICAgICpndWVzdF9wYXQgPSB2LT5hcmNoLmh2bV92Y3B1LnBhdF9jcjsKK30K
KworaW50IGh2bV9zZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3Vlc3RfcGF0KQor
eworICAgIGludCBpOworICAgIHVpbnQ4X3QgKnZhbHVlID0gKHVpbnQ4X3QgKikmZ3Vlc3RfcGF0
OworCisgICAgZm9yICggaSA9IDA7IGkgPCA4OyBpKysgKQorICAgICAgICBpZiAoIHVubGlrZWx5
KCEodmFsdWVbaV0gPT0gMCB8fCB2YWx1ZVtpXSA9PSAxIHx8CisgICAgICAgICAgICAgICAgICAg
ICAgICB2YWx1ZVtpXSA9PSA0IHx8IHZhbHVlW2ldID09IDUgfHwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIHZhbHVlW2ldID09IDYgfHwgdmFsdWVbaV0gPT0gNykpICkgeworICAgICAgICAgICAg
SFZNX0RCR19MT0coREJHX0xFVkVMX01TUiwgImludmFsaWQgZ3Vlc3QgUEFUOiAlIlBSSXg2NCJc
biIsCisgICAgICAgICAgICAgICAgICAgICAgICBndWVzdF9wYXQpOyAKKyAgICAgICAgICAgIHJl
dHVybiAwOworICAgICAgICB9CisKKyAgICBpZiAoICFodm1fZnVuY3Muc2V0X2d1ZXN0X3BhdCh2
LCBndWVzdF9wYXQpICkKKyAgICAgICAgdi0+YXJjaC5odm1fdmNwdS5wYXRfY3IgPSBndWVzdF9w
YXQ7CisgICAgcmV0dXJuIDE7Cit9CisKIHZvaWQgaHZtX3NldF9ndWVzdF90c2Moc3RydWN0IHZj
cHUgKnYsIHU2NCBndWVzdF90c2MpCiB7CiAgICAgdWludDY0X3QgdHNjOwpAQCAtMjc5Niw3ICsy
ODIxLDcgQEAKICAgICAgICAgYnJlYWs7CiAKICAgICBjYXNlIE1TUl9JQTMyX0NSX1BBVDoKLSAg
ICAgICAgKm1zcl9jb250ZW50ID0gdi0+YXJjaC5odm1fdmNwdS5wYXRfY3I7CisgICAgICAgIGh2
bV9nZXRfZ3Vlc3RfcGF0KHYsIG1zcl9jb250ZW50KTsKICAgICAgICAgYnJlYWs7CiAKICAgICBj
YXNlIE1TUl9NVFJSY2FwOgpAQCAtMjkxMiw3ICsyOTM3LDcgQEAKICAgICAgICAgYnJlYWs7CiAK
ICAgICBjYXNlIE1TUl9JQTMyX0NSX1BBVDoKLSAgICAgICAgaWYgKCAhcGF0X21zcl9zZXQoJnYt
PmFyY2guaHZtX3ZjcHUucGF0X2NyLCBtc3JfY29udGVudCkgKQorICAgICAgICBpZiAoICFodm1f
c2V0X2d1ZXN0X3BhdCh2LCBtc3JfY29udGVudCkgKQogICAgICAgICAgICBnb3RvIGdwX2ZhdWx0
OwogICAgICAgICBicmVhazsKIApkaWZmIC1yIDViYmRhNjU3YTAxNiB4ZW4vYXJjaC94ODYvaHZt
L210cnIuYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL210cnIuYwlUdWUgQXByIDEwIDEwOjQyOjM1
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L2h2bS9tdHJyLmMJV2VkIEFwciAxMSAwMzow
Mzo1MCAyMDEyIC0wNzAwCkBAIC00MDMsMjYgKzQwMyw2IEBACiAgICAgcmV0dXJuIHBhdF90eXBl
XzJfcHRlX2ZsYWdzKHBhdF9lbnRyeV92YWx1ZSk7CiB9CiAKLS8qIEhlbHBlciBmdW50aW9ucyBm
b3Igc2V0aW5nIG10cnIvcGF0ICovCi1ib29sX3QgcGF0X21zcl9zZXQodWludDY0X3QgKnBhdCwg
dWludDY0X3QgbXNyX2NvbnRlbnQpCi17Ci0gICAgdWludDhfdCAqdmFsdWUgPSAodWludDhfdCop
Jm1zcl9jb250ZW50OwotICAgIGludDMyX3QgaTsKLQotICAgIGlmICggKnBhdCAhPSBtc3JfY29u
dGVudCApCi0gICAgewotICAgICAgICBmb3IgKCBpID0gMDsgaSA8IDg7IGkrKyApCi0gICAgICAg
ICAgICBpZiAoIHVubGlrZWx5KCEodmFsdWVbaV0gPT0gMCB8fCB2YWx1ZVtpXSA9PSAxIHx8Ci0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWVbaV0gPT0gNCB8fCB2YWx1ZVtpXSA9PSA1
IHx8Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWVbaV0gPT0gNiB8fCB2YWx1ZVtp
XSA9PSA3KSkgKQotICAgICAgICAgICAgICAgIHJldHVybiAwOwotCi0gICAgICAgICpwYXQgPSBt
c3JfY29udGVudDsKLSAgICB9Ci0KLSAgICByZXR1cm4gMTsKLX0KLQogYm9vbF90IG10cnJfZGVm
X3R5cGVfbXNyX3NldChzdHJ1Y3QgbXRycl9zdGF0ZSAqbSwgdWludDY0X3QgbXNyX2NvbnRlbnQp
CiB7CiAgICAgdWludDhfdCBkZWZfdHlwZSA9IG1zcl9jb250ZW50ICYgMHhmZjsKQEAgLTYzMSw3
ICs2MTEsNyBAQAogICAgIHsKICAgICAgICAgbXRycl9zdGF0ZSA9ICZ2LT5hcmNoLmh2bV92Y3B1
Lm10cnI7CiAKLSAgICAgICAgaHdfbXRyci5tc3JfcGF0X2NyID0gdi0+YXJjaC5odm1fdmNwdS5w
YXRfY3I7CisgICAgICAgIGh2bV9nZXRfZ3Vlc3RfcGF0KHYsICZod19tdHJyLm1zcl9wYXRfY3Ip
OwogCiAgICAgICAgIGh3X210cnIubXNyX210cnJfZGVmX3R5cGUgPSBtdHJyX3N0YXRlLT5kZWZf
dHlwZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IChtdHJyX3N0YXRlLT5lbmFi
bGVkIDw8IDEwKTsKQEAgLTY3Nyw3ICs2NTcsNyBAQAogCiAgICAgbXRycl9zdGF0ZSA9ICZ2LT5h
cmNoLmh2bV92Y3B1Lm10cnI7CiAKLSAgICBwYXRfbXNyX3NldCgmdi0+YXJjaC5odm1fdmNwdS5w
YXRfY3IsIGh3X210cnIubXNyX3BhdF9jcik7CisgICAgaHZtX3NldF9ndWVzdF9wYXQodiwgaHdf
bXRyci5tc3JfcGF0X2NyKTsKIAogICAgIG10cnJfc3RhdGUtPm10cnJfY2FwID0gaHdfbXRyci5t
c3JfbXRycl9jYXA7CiAKZGlmZiAtciA1YmJkYTY1N2EwMTYgeGVuL2FyY2gveDg2L2h2bS9zdm0v
c3ZtLmMKLS0tIGEveGVuL2FyY2gveDg2L2h2bS9zdm0vc3ZtLmMJVHVlIEFwciAxMCAxMDo0Mjoz
NSAyMDEyICswMTAwCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL3N2bS5jCVdlZCBBcHIgMTEg
MDM6MDM6NTAgMjAxMiAtMDcwMApAQCAtNjQ1LDYgKzY0NSwyOCBAQAogICAgICAgICBzdm1fdm1s
b2FkKHZtY2IpOwogfQogCitzdGF0aWMgaW50IHN2bV9zZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1
ICp2LCB1NjQgZ3BhdCkKK3sKKyAgICBzdHJ1Y3Qgdm1jYl9zdHJ1Y3QgKnZtY2IgPSB2LT5hcmNo
Lmh2bV9zdm0udm1jYjsKKworICAgIGlmICggIXBhZ2luZ19tb2RlX2hhcCh2LT5kb21haW4pICkK
KyAgICAgICAgcmV0dXJuIDA7CisKKyAgICB2bWNiX3NldF9nX3BhdCh2bWNiLCBncGF0KTsKKyAg
ICByZXR1cm4gMTsKK30KKworc3RhdGljIGludCBzdm1fZ2V0X2d1ZXN0X3BhdChzdHJ1Y3QgdmNw
dSAqdiwgdTY0ICpncGF0KQoreworICAgIHN0cnVjdCB2bWNiX3N0cnVjdCAqdm1jYiA9IHYtPmFy
Y2guaHZtX3N2bS52bWNiOworCisgICAgaWYgKCAhcGFnaW5nX21vZGVfaGFwKHYtPmRvbWFpbikg
KQorICAgICAgICByZXR1cm4gMDsKKworICAgICpncGF0ID0gdm1jYl9nZXRfZ19wYXQodm1jYik7
CisgICAgcmV0dXJuIDE7Cit9CisKIHN0YXRpYyB1aW50NjRfdCBzdm1fZ2V0X3RzY19vZmZzZXQo
dWludDY0X3QgaG9zdF90c2MsIHVpbnQ2NF90IGd1ZXN0X3RzYywKICAgICB1aW50NjRfdCByYXRp
bykKIHsKQEAgLTE5NjQsNiArMTk4Niw4IEBACiAgICAgLnVwZGF0ZV9ob3N0X2NyMyAgICAgID0g
c3ZtX3VwZGF0ZV9ob3N0X2NyMywKICAgICAudXBkYXRlX2d1ZXN0X2NyICAgICAgPSBzdm1fdXBk
YXRlX2d1ZXN0X2NyLAogICAgIC51cGRhdGVfZ3Vlc3RfZWZlciAgICA9IHN2bV91cGRhdGVfZ3Vl
c3RfZWZlciwKKyAgICAuc2V0X2d1ZXN0X3BhdCAgICAgICAgPSBzdm1fc2V0X2d1ZXN0X3BhdCwK
KyAgICAuZ2V0X2d1ZXN0X3BhdCAgICAgICAgPSBzdm1fZ2V0X2d1ZXN0X3BhdCwKICAgICAuc2V0
X3RzY19vZmZzZXQgICAgICAgPSBzdm1fc2V0X3RzY19vZmZzZXQsCiAgICAgLmluamVjdF9leGNl
cHRpb24gICAgID0gc3ZtX2luamVjdF9leGNlcHRpb24sCiAgICAgLmluaXRfaHlwZXJjYWxsX3Bh
Z2UgID0gc3ZtX2luaXRfaHlwZXJjYWxsX3BhZ2UsCmRpZmYgLXIgNWJiZGE2NTdhMDE2IHhlbi9h
cmNoL3g4Ni9odm0vdm14L3ZteC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jCVR1
ZSBBcHIgMTAgMTA6NDI6MzUgMjAxMiArMDEwMAorKysgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC92
bXguYwlXZWQgQXByIDExIDAzOjAzOjUwIDIwMTIgLTA3MDAKQEAgLTk0Miw2ICs5NDIsMzQgQEAK
ICAgICB2bXhfdm1jc19leGl0KHYpOwogfQogCitzdGF0aWMgaW50IHZteF9zZXRfZ3Vlc3RfcGF0
KHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3BhdCkKK3sKKyAgICBpZiAoICFjcHVfaGFzX3ZteF9wYXQg
fHwgIXBhZ2luZ19tb2RlX2hhcCh2LT5kb21haW4pICkKKyAgICAgICAgcmV0dXJuIDA7CisKKyAg
ICB2bXhfdm1jc19lbnRlcih2KTsKKyAgICBfX3Ztd3JpdGUoR1VFU1RfUEFULCBncGF0KTsKKyNp
ZmRlZiBfX2kzODZfXworICAgIF9fdm13cml0ZShHVUVTVF9QQVRfSElHSCwgZ3BhdCA+PiAzMik7
CisjZW5kaWYKKyAgICB2bXhfdm1jc19leGl0KHYpOworICAgIHJldHVybiAxOworfQorCitzdGF0
aWMgaW50IHZteF9nZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1ICp2LCB1NjQgKmdwYXQpCit7Cisg
ICAgaWYgKCAhY3B1X2hhc192bXhfcGF0IHx8ICFwYWdpbmdfbW9kZV9oYXAodi0+ZG9tYWluKSAp
CisgICAgICAgIHJldHVybiAwOworCisgICAgdm14X3ZtY3NfZW50ZXIodik7CisgICAgKmdwYXQg
PSBfX3ZtcmVhZChHVUVTVF9QQVQpOworI2lmZGVmIF9faTM4Nl9fCisgICAgKmdwYXQgfD0gKHU2
NClfX3ZtcmVhZChHVUVTVF9QQVRfSElHSCkgPDwgMzI7CisjZW5kaWYKKyAgICB2bXhfdm1jc19l
eGl0KHYpOworICAgIHJldHVybiAxOworfQorCiBzdGF0aWMgdm9pZCB2bXhfc2V0X3RzY19vZmZz
ZXQoc3RydWN0IHZjcHUgKnYsIHU2NCBvZmZzZXQpCiB7CiAgICAgdm14X3ZtY3NfZW50ZXIodik7
CkBAIC0xNDg2LDYgKzE1MTQsOCBAQAogICAgIC51cGRhdGVfaG9zdF9jcjMgICAgICA9IHZteF91
cGRhdGVfaG9zdF9jcjMsCiAgICAgLnVwZGF0ZV9ndWVzdF9jciAgICAgID0gdm14X3VwZGF0ZV9n
dWVzdF9jciwKICAgICAudXBkYXRlX2d1ZXN0X2VmZXIgICAgPSB2bXhfdXBkYXRlX2d1ZXN0X2Vm
ZXIsCisgICAgLnNldF9ndWVzdF9wYXQgICAgICAgID0gdm14X3NldF9ndWVzdF9wYXQsCisgICAg
LmdldF9ndWVzdF9wYXQgICAgICAgID0gdm14X2dldF9ndWVzdF9wYXQsCiAgICAgLnNldF90c2Nf
b2Zmc2V0ICAgICAgID0gdm14X3NldF90c2Nfb2Zmc2V0LAogICAgIC5pbmplY3RfZXhjZXB0aW9u
ICAgICA9IHZteF9pbmplY3RfZXhjZXB0aW9uLAogICAgIC5pbml0X2h5cGVyY2FsbF9wYWdlICA9
IHZteF9pbml0X2h5cGVyY2FsbF9wYWdlLApkaWZmIC1yIDViYmRhNjU3YTAxNiB4ZW4vaW5jbHVk
ZS9hc20teDg2L2h2bS9odm0uaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9odm0uaAlU
dWUgQXByIDEwIDEwOjQyOjM1IDIwMTIgKzAxMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9o
dm0vaHZtLmgJV2VkIEFwciAxMSAwMzowMzo1MCAyMDEyIC0wNzAwCkBAIC0xMTgsNiArMTE4LDkg
QEAKICAgICB2b2lkICgqdXBkYXRlX2d1ZXN0X2NyKShzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQg
aW50IGNyKTsKICAgICB2b2lkICgqdXBkYXRlX2d1ZXN0X2VmZXIpKHN0cnVjdCB2Y3B1ICp2KTsK
IAorICAgIGludCAgKCpnZXRfZ3Vlc3RfcGF0KShzdHJ1Y3QgdmNwdSAqdiwgdTY0ICopOworICAg
IGludCAgKCpzZXRfZ3Vlc3RfcGF0KShzdHJ1Y3QgdmNwdSAqdiwgdTY0KTsKKwogICAgIHZvaWQg
KCpzZXRfdHNjX29mZnNldCkoc3RydWN0IHZjcHUgKnYsIHU2NCBvZmZzZXQpOwogCiAgICAgdm9p
ZCAoKmluamVjdF9leGNlcHRpb24pKHVuc2lnbmVkIGludCB0cmFwbnIsIGludCBlcnJjb2RlLApA
QCAtMjAwLDYgKzIwMyw5IEBACiAKIGJvb2xfdCBodm1fc2VuZF9hc3Npc3RfcmVxKHN0cnVjdCB2
Y3B1ICp2KTsKIAordm9pZCBodm1fZ2V0X2d1ZXN0X3BhdChzdHJ1Y3QgdmNwdSAqdiwgdTY0ICpn
dWVzdF9wYXQpOworaW50IGh2bV9zZXRfZ3Vlc3RfcGF0KHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3Vl
c3RfcGF0KTsKKwogdm9pZCBodm1fc2V0X2d1ZXN0X3RzYyhzdHJ1Y3QgdmNwdSAqdiwgdTY0IGd1
ZXN0X3RzYyk7CiB1NjQgaHZtX2dldF9ndWVzdF90c2Moc3RydWN0IHZjcHUgKnYpOwogCg==
--f46d043bd7e8664e7c04bd6f41dc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d043bd7e8664e7c04bd6f41dc--


From xen-devel-bounces@lists.xen.org Wed Apr 11 23:11:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 23:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI6h4-0001S4-7d; Wed, 11 Apr 2012 23:11:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SI6h2-0001Rx-FM
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 23:11:16 +0000
Received: from [193.109.254.147:14060] by server-1.bemta-14.messagelabs.com id
	B3/F4-29372-39F068F4; Wed, 11 Apr 2012 23:11:15 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334185873!4198911!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28616 invoked from network); 11 Apr 2012 23:11:14 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Apr 2012 23:11:14 -0000
Received: from mail118-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Apr 2012 23:11:13 +0000
Received: from mail118-ch1 (localhost [127.0.0.1])	by
	mail118-ch1-R.bigfish.com (Postfix) with ESMTP id 1C7A21C02F3;
	Wed, 11 Apr 2012 23:11:13 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail118-ch1 (localhost.localdomain [127.0.0.1]) by mail118-ch1
	(MessageSwitch) id 1334185871407048_11581;
	Wed, 11 Apr 2012 23:11:11 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.244])	by mail118-ch1.bigfish.com (Postfix) with ESMTP id
	5F07E2E0054;	Wed, 11 Apr 2012 23:11:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Apr 2012 23:11:11 +0000
X-WSS-ID: 0M2C8EL-01-95R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29ADE1028098;	Wed, 11 Apr 2012 18:11:09 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 11 Apr 2012 18:11:22 -0500
Received: from [10.236.66.88] (10.236.66.88) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 18:11:08 -0500
Message-ID: <4F860F8D.7090903@amd.com>
Date: Wed, 11 Apr 2012 18:11:09 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CBAB8EF0.3D982%keir@xen.org>
In-Reply-To: <CBAB8EF0.3D982%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 01:41 PM, Keir Fraser wrote:
> On 11/04/2012 18:07, "Ian Campbell"<Ian.Campbell@citrix.com>  wrote:
>
>> It seems like it has been quite a while since our last stable branch
>> releases.
>>
>> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
>> deep into the 4.2 release closedown?
>>
>> Perhaps we could do a first rc of each in the next few weeks?
> Yes, it's about time.
Before tagging 4.1.3, may I request the following changesets backported 
from xen-unstable? Will you consider them?

-Wei

==== SVM Decode Assist ====
changeset 23233:1276926e3795
changeset 23234:bf7afd48339a
changeset 23235:2c8ad607ece1
changeset 23236:e324c4d1dd6e
changeset 23237:381ab77db71a
changeset 23238:60f5df2afcbb

==== SVM TSC Scaling ====
changeset 23437:d7c755c25bb9

==== Performance Monitor Counters ====
changeset 23304:8981b582be3e
changeset 23305:014ee4e09644
changeset 23306:e787d4f2e5ac



>
>   -- Keir
>
>> Ian.
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 11 23:11:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Apr 2012 23:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI6h4-0001S4-7d; Wed, 11 Apr 2012 23:11:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SI6h2-0001Rx-FM
	for xen-devel@lists.xen.org; Wed, 11 Apr 2012 23:11:16 +0000
Received: from [193.109.254.147:14060] by server-1.bemta-14.messagelabs.com id
	B3/F4-29372-39F068F4; Wed, 11 Apr 2012 23:11:15 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334185873!4198911!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28616 invoked from network); 11 Apr 2012 23:11:14 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Apr 2012 23:11:14 -0000
Received: from mail118-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Apr 2012 23:11:13 +0000
Received: from mail118-ch1 (localhost [127.0.0.1])	by
	mail118-ch1-R.bigfish.com (Postfix) with ESMTP id 1C7A21C02F3;
	Wed, 11 Apr 2012 23:11:13 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail118-ch1 (localhost.localdomain [127.0.0.1]) by mail118-ch1
	(MessageSwitch) id 1334185871407048_11581;
	Wed, 11 Apr 2012 23:11:11 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.244])	by mail118-ch1.bigfish.com (Postfix) with ESMTP id
	5F07E2E0054;	Wed, 11 Apr 2012 23:11:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Apr 2012 23:11:11 +0000
X-WSS-ID: 0M2C8EL-01-95R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29ADE1028098;	Wed, 11 Apr 2012 18:11:09 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 11 Apr 2012 18:11:22 -0500
Received: from [10.236.66.88] (10.236.66.88) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Apr 2012 18:11:08 -0500
Message-ID: <4F860F8D.7090903@amd.com>
Date: Wed, 11 Apr 2012 18:11:09 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CBAB8EF0.3D982%keir@xen.org>
In-Reply-To: <CBAB8EF0.3D982%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 01:41 PM, Keir Fraser wrote:
> On 11/04/2012 18:07, "Ian Campbell"<Ian.Campbell@citrix.com>  wrote:
>
>> It seems like it has been quite a while since our last stable branch
>> releases.
>>
>> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
>> deep into the 4.2 release closedown?
>>
>> Perhaps we could do a first rc of each in the next few weeks?
> Yes, it's about time.
Before tagging 4.1.3, may I request the following changesets backported 
from xen-unstable? Will you consider them?

-Wei

==== SVM Decode Assist ====
changeset 23233:1276926e3795
changeset 23234:bf7afd48339a
changeset 23235:2c8ad607ece1
changeset 23236:e324c4d1dd6e
changeset 23237:381ab77db71a
changeset 23238:60f5df2afcbb

==== SVM TSC Scaling ====
changeset 23437:d7c755c25bb9

==== Performance Monitor Counters ====
changeset 23304:8981b582be3e
changeset 23305:014ee4e09644
changeset 23306:e787d4f2e5ac



>
>   -- Keir
>
>> Ian.
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:20:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7ky-0002ME-Q5; Thu, 12 Apr 2012 00:19:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7kx-0002M9-R8
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:19:24 +0000
Received: from [193.109.254.147:59193] by server-4.bemta-14.messagelabs.com id
	8E/63-11570-B8F168F4; Thu, 12 Apr 2012 00:19:23 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334189961!1091810!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22783 invoked from network); 12 Apr 2012 00:19:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 00:19:22 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0J7Tx006845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:19:07 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0J3ak031087; Wed, 11 Apr 2012 20:19:04 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 157C37A018;
	Wed, 11 Apr 2012 21:15:23 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C0FHTF001226;
	Wed, 11 Apr 2012 21:15:17 -0300
Date: Wed, 11 Apr 2012 21:15:17 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412001517.GB32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080723.14568.23068.sendpatchset@codeblue>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120323080723.14568.23068.sendpatchset@codeblue>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 3/6] kvm : Add unhalt msr to aid
	(live) migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 01:37:26PM +0530, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> 
> Currently guest does not need to know pv_unhalt state and intended to be
> used via GET/SET_MSR ioctls  during migration.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 9234f13..46f9751 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -40,6 +40,7 @@
>  #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
>  #define MSR_KVM_ASYNC_PF_EN 0x4b564d02
>  #define MSR_KVM_STEAL_TIME  0x4b564d03
> +#define MSR_KVM_PV_UNHALT   0x4b564d04
>  
>  struct kvm_steal_time {
>  	__u64 steal;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bd5ef91..38e6c47 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -784,12 +784,13 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
>   * kvm-specific. Those are put in the beginning of the list.
>   */
>  
> -#define KVM_SAVE_MSRS_BEGIN	9
> +#define KVM_SAVE_MSRS_BEGIN	10
>  static u32 msrs_to_save[] = {
>  	MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
>  	MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
>  	HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
>  	HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
> +	MSR_KVM_PV_UNHALT,
>  	MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
>  	MSR_STAR,
>  #ifdef CONFIG_X86_64
> @@ -1606,7 +1607,9 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>  		kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
>  
>  		break;
> -
> +	case MSR_KVM_PV_UNHALT:
> +		vcpu->pv_unhalted = (u32) data;
> +		break;
>  	case MSR_IA32_MCG_CTL:
>  	case MSR_IA32_MCG_STATUS:
>  	case MSR_IA32_MC0_CTL ... MSR_IA32_MC0_CTL + 4 * KVM_MAX_MCE_BANKS - 1:
> @@ -1917,6 +1920,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
>  	case MSR_KVM_STEAL_TIME:
>  		data = vcpu->arch.st.msr_val;
>  		break;
> +	case MSR_KVM_PV_UNHALT:
> +		data = (u64)vcpu->pv_unhalted;
> +		break;
>  	case MSR_IA32_P5_MC_ADDR:
>  	case MSR_IA32_P5_MC_TYPE:
>  	case MSR_IA32_MCG_CAP:

Unless there is a reason to use an MSR, should use a normal ioctl
such as KVM_{GET,SET}_MP_STATE.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:20:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7ky-0002ME-Q5; Thu, 12 Apr 2012 00:19:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7kx-0002M9-R8
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:19:24 +0000
Received: from [193.109.254.147:59193] by server-4.bemta-14.messagelabs.com id
	8E/63-11570-B8F168F4; Thu, 12 Apr 2012 00:19:23 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334189961!1091810!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22783 invoked from network); 12 Apr 2012 00:19:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 00:19:22 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0J7Tx006845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:19:07 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0J3ak031087; Wed, 11 Apr 2012 20:19:04 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 157C37A018;
	Wed, 11 Apr 2012 21:15:23 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C0FHTF001226;
	Wed, 11 Apr 2012 21:15:17 -0300
Date: Wed, 11 Apr 2012 21:15:17 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412001517.GB32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080723.14568.23068.sendpatchset@codeblue>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120323080723.14568.23068.sendpatchset@codeblue>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 3/6] kvm : Add unhalt msr to aid
	(live) migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 01:37:26PM +0530, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> 
> Currently guest does not need to know pv_unhalt state and intended to be
> used via GET/SET_MSR ioctls  during migration.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 9234f13..46f9751 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -40,6 +40,7 @@
>  #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
>  #define MSR_KVM_ASYNC_PF_EN 0x4b564d02
>  #define MSR_KVM_STEAL_TIME  0x4b564d03
> +#define MSR_KVM_PV_UNHALT   0x4b564d04
>  
>  struct kvm_steal_time {
>  	__u64 steal;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bd5ef91..38e6c47 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -784,12 +784,13 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
>   * kvm-specific. Those are put in the beginning of the list.
>   */
>  
> -#define KVM_SAVE_MSRS_BEGIN	9
> +#define KVM_SAVE_MSRS_BEGIN	10
>  static u32 msrs_to_save[] = {
>  	MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
>  	MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
>  	HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
>  	HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
> +	MSR_KVM_PV_UNHALT,
>  	MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
>  	MSR_STAR,
>  #ifdef CONFIG_X86_64
> @@ -1606,7 +1607,9 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>  		kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
>  
>  		break;
> -
> +	case MSR_KVM_PV_UNHALT:
> +		vcpu->pv_unhalted = (u32) data;
> +		break;
>  	case MSR_IA32_MCG_CTL:
>  	case MSR_IA32_MCG_STATUS:
>  	case MSR_IA32_MC0_CTL ... MSR_IA32_MC0_CTL + 4 * KVM_MAX_MCE_BANKS - 1:
> @@ -1917,6 +1920,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
>  	case MSR_KVM_STEAL_TIME:
>  		data = vcpu->arch.st.msr_val;
>  		break;
> +	case MSR_KVM_PV_UNHALT:
> +		data = (u64)vcpu->pv_unhalted;
> +		break;
>  	case MSR_IA32_P5_MC_ADDR:
>  	case MSR_IA32_P5_MC_TYPE:
>  	case MSR_IA32_MCG_CAP:

Unless there is a reason to use an MSR, should use a normal ioctl
such as KVM_{GET,SET}_MP_STATE.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:20:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7kw-0002M2-EN; Thu, 12 Apr 2012 00:19:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7ku-0002Lx-N8
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:19:21 +0000
Received: from [85.158.139.83:37158] by server-1.bemta-5.messagelabs.com id
	C0/D3-28458-78F168F4; Thu, 12 Apr 2012 00:19:19 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334189958!23423551!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27302 invoked from network); 12 Apr 2012 00:19:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 00:19:18 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0J7F7030546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:19:07 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0J38c024030; Wed, 11 Apr 2012 20:19:04 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 554B27A012;
	Wed, 11 Apr 2012 21:06:40 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C06UG6001106;
	Wed, 11 Apr 2012 21:06:30 -0300
Date: Wed, 11 Apr 2012 21:06:29 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412000629.GA32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120323080701.14568.97779.sendpatchset@codeblue>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> 
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..9234f13 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
>  #define KVM_FEATURE_CLOCKSOURCE		0
>  #define KVM_FEATURE_NOP_IO_DELAY	1
>  #define KVM_FEATURE_MMU_OP		2
> +
>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_PV_UNHALT		6
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> @@ -32,6 +34,7 @@
>  #define MSR_KVM_SYSTEM_TIME 0x12
>  
>  #define KVM_MSR_ENABLED 1
> +
>  /* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
>  #define MSR_KVM_WALL_CLOCK_NEW  0x4b564d00
>  #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 89b02bf..61388b9 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
>  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
>  			     (1 << KVM_FEATURE_ASYNC_PF) |
> -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> +			     (1 << KVM_FEATURE_PV_UNHALT);
>  
>  		if (sched_info_on())
>  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 9cbfc06..bd5ef91 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2079,6 +2079,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_XSAVE:
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
> +	case KVM_CAP_PV_UNHALT:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:
> @@ -4913,6 +4914,30 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>  	return 1;
>  }
>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		vcpu->pv_unhalted = 1;
> +		smp_mb();
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +
>  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  {
>  	unsigned long nr, a0, a1, a2, a3, ret;
> @@ -4946,6 +4971,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  	case KVM_HC_VAPIC_POLL_IRQ:
>  		ret = 0;
>  		break;
> +	case KVM_HC_KICK_CPU:
> +		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
> +		ret = 0;
> +		break;
>  	default:
>  		ret = -KVM_ENOSYS;
>  		break;
> @@ -6174,6 +6203,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>  		!vcpu->arch.apf.halted)
>  		|| !list_empty_careful(&vcpu->async_pf.done)
>  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| vcpu->pv_unhalted
>  		|| atomic_read(&vcpu->arch.nmi_queued) ||
>  		(kvm_arch_interrupt_allowed(vcpu) &&
>  		 kvm_cpu_has_interrupt(vcpu));
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index 68e67e5..e822d96 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
>  #define KVM_CAP_PPC_PAPR 68
>  #define KVM_CAP_S390_GMAP 71
>  #define KVM_CAP_TSC_DEADLINE_TIMER 72
> +#define KVM_CAP_PV_UNHALT 73
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 900c763..433ae97 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -158,6 +158,7 @@ struct kvm_vcpu {
>  #endif
>  
>  	struct kvm_vcpu_arch arch;
> +	int pv_unhalted;
>  };
>  
>  static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> index ff476dd..38226e1 100644
> --- a/include/linux/kvm_para.h
> +++ b/include/linux/kvm_para.h
> @@ -19,6 +19,7 @@
>  #define KVM_HC_MMU_OP			2
>  #define KVM_HC_FEATURES			3
>  #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
> +#define KVM_HC_KICK_CPU			5
>  
>  /*
>   * hypercalls use architecture specific
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index a91f980..d3b98b1 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
>  	vcpu->kvm = kvm;
>  	vcpu->vcpu_id = id;
>  	vcpu->pid = NULL;
> +	vcpu->pv_unhalted = 0;
>  	init_waitqueue_head(&vcpu->wq);
>  	kvm_async_pf_vcpu_init(vcpu);
>  
> @@ -1567,6 +1568,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>  
>  		if (kvm_arch_vcpu_runnable(vcpu)) {
> +			vcpu->pv_unhalted = 0;
> +			/* preventing reordering should be enough here */
> +			barrier();

Is it always OK to erase the notification, even in case an unrelated
event such as interrupt was the source of wakeup?

It would be easier to verify that notifications are not lost with atomic

test_and_clear(pv_unhalted).

Also x86 specific code should remain in arch/x86/kvm/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:20:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7kw-0002M2-EN; Thu, 12 Apr 2012 00:19:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7ku-0002Lx-N8
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:19:21 +0000
Received: from [85.158.139.83:37158] by server-1.bemta-5.messagelabs.com id
	C0/D3-28458-78F168F4; Thu, 12 Apr 2012 00:19:19 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334189958!23423551!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27302 invoked from network); 12 Apr 2012 00:19:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 00:19:18 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0J7F7030546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:19:07 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0J38c024030; Wed, 11 Apr 2012 20:19:04 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 554B27A012;
	Wed, 11 Apr 2012 21:06:40 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C06UG6001106;
	Wed, 11 Apr 2012 21:06:30 -0300
Date: Wed, 11 Apr 2012 21:06:29 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412000629.GA32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120323080701.14568.97779.sendpatchset@codeblue>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> 
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..9234f13 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
>  #define KVM_FEATURE_CLOCKSOURCE		0
>  #define KVM_FEATURE_NOP_IO_DELAY	1
>  #define KVM_FEATURE_MMU_OP		2
> +
>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_PV_UNHALT		6
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> @@ -32,6 +34,7 @@
>  #define MSR_KVM_SYSTEM_TIME 0x12
>  
>  #define KVM_MSR_ENABLED 1
> +
>  /* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
>  #define MSR_KVM_WALL_CLOCK_NEW  0x4b564d00
>  #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 89b02bf..61388b9 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
>  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
>  			     (1 << KVM_FEATURE_ASYNC_PF) |
> -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> +			     (1 << KVM_FEATURE_PV_UNHALT);
>  
>  		if (sched_info_on())
>  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 9cbfc06..bd5ef91 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2079,6 +2079,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_XSAVE:
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
> +	case KVM_CAP_PV_UNHALT:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:
> @@ -4913,6 +4914,30 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>  	return 1;
>  }
>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		vcpu->pv_unhalted = 1;
> +		smp_mb();
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +
>  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  {
>  	unsigned long nr, a0, a1, a2, a3, ret;
> @@ -4946,6 +4971,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  	case KVM_HC_VAPIC_POLL_IRQ:
>  		ret = 0;
>  		break;
> +	case KVM_HC_KICK_CPU:
> +		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
> +		ret = 0;
> +		break;
>  	default:
>  		ret = -KVM_ENOSYS;
>  		break;
> @@ -6174,6 +6203,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>  		!vcpu->arch.apf.halted)
>  		|| !list_empty_careful(&vcpu->async_pf.done)
>  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| vcpu->pv_unhalted
>  		|| atomic_read(&vcpu->arch.nmi_queued) ||
>  		(kvm_arch_interrupt_allowed(vcpu) &&
>  		 kvm_cpu_has_interrupt(vcpu));
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index 68e67e5..e822d96 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
>  #define KVM_CAP_PPC_PAPR 68
>  #define KVM_CAP_S390_GMAP 71
>  #define KVM_CAP_TSC_DEADLINE_TIMER 72
> +#define KVM_CAP_PV_UNHALT 73
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 900c763..433ae97 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -158,6 +158,7 @@ struct kvm_vcpu {
>  #endif
>  
>  	struct kvm_vcpu_arch arch;
> +	int pv_unhalted;
>  };
>  
>  static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> index ff476dd..38226e1 100644
> --- a/include/linux/kvm_para.h
> +++ b/include/linux/kvm_para.h
> @@ -19,6 +19,7 @@
>  #define KVM_HC_MMU_OP			2
>  #define KVM_HC_FEATURES			3
>  #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
> +#define KVM_HC_KICK_CPU			5
>  
>  /*
>   * hypercalls use architecture specific
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index a91f980..d3b98b1 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
>  	vcpu->kvm = kvm;
>  	vcpu->vcpu_id = id;
>  	vcpu->pid = NULL;
> +	vcpu->pv_unhalted = 0;
>  	init_waitqueue_head(&vcpu->wq);
>  	kvm_async_pf_vcpu_init(vcpu);
>  
> @@ -1567,6 +1568,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>  
>  		if (kvm_arch_vcpu_runnable(vcpu)) {
> +			vcpu->pv_unhalted = 0;
> +			/* preventing reordering should be enough here */
> +			barrier();

Is it always OK to erase the notification, even in case an unrelated
event such as interrupt was the source of wakeup?

It would be easier to verify that notifications are not lost with atomic

test_and_clear(pv_unhalted).

Also x86 specific code should remain in arch/x86/kvm/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:31:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7w4-0002fS-66; Thu, 12 Apr 2012 00:30:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7w2-0002fN-Ff
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:30:50 +0000
Received: from [85.158.143.99:23998] by server-2.bemta-4.messagelabs.com id
	E6/03-17550-932268F4; Thu, 12 Apr 2012 00:30:49 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334190648!17985451!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23306 invoked from network); 12 Apr 2012 00:30:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 00:30:49 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0UfVH027495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:30:41 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0UdTf027072; Wed, 11 Apr 2012 20:30:40 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 1AE0C7A012;
	Wed, 11 Apr 2012 21:26:53 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C0Ql0O001335;
	Wed, 11 Apr 2012 21:26:47 -0300
Date: Wed, 11 Apr 2012 21:26:46 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412002646.GC32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<4F73593D.5020305@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F73593D.5020305@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 0/6] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Mar 29, 2012 at 12:02:29AM +0530, Raghavendra K T wrote:
> On 03/23/2012 01:35 PM, Raghavendra K T wrote:
> >The 6-patch series to follow this email extends KVM-hypervisor and Linux guest
> >running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's
> >implementation.
> >
> >One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick
> >another vcpu out of halt state.
> >The blocking of vcpu is done using halt() in (lock_spinning) slowpath.
> >one MSR is added to aid live migration.
> >
> >Changes in V5:
> >- rebased to 3.3-rc6
> >- added PV_UNHALT_MSR that would help in live migration (Avi)
> >- removed PV_LOCK_KICK vcpu request and pv_unhalt flag (re)added.
> 
> Sorry for pinging
> I know it is busy time. But I hope to get response on these patches
> in your free time, so that I can target next merge window for this.
> (whether it has reached some good state or it is heading in reverse
> direction!). it would really boost my morale.
> especially MSR stuff and dropping vcpu request bit for PV unhalt.
> 
> - Raghu

Looks good. Only the MSR appears an abuse, since there is no need
to expose the info to the guest.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:31:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7w4-0002fS-66; Thu, 12 Apr 2012 00:30:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7w2-0002fN-Ff
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:30:50 +0000
Received: from [85.158.143.99:23998] by server-2.bemta-4.messagelabs.com id
	E6/03-17550-932268F4; Thu, 12 Apr 2012 00:30:49 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334190648!17985451!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23306 invoked from network); 12 Apr 2012 00:30:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 00:30:49 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0UfVH027495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:30:41 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0UdTf027072; Wed, 11 Apr 2012 20:30:40 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 1AE0C7A012;
	Wed, 11 Apr 2012 21:26:53 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C0Ql0O001335;
	Wed, 11 Apr 2012 21:26:47 -0300
Date: Wed, 11 Apr 2012 21:26:46 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412002646.GC32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<4F73593D.5020305@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F73593D.5020305@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 0/6] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Mar 29, 2012 at 12:02:29AM +0530, Raghavendra K T wrote:
> On 03/23/2012 01:35 PM, Raghavendra K T wrote:
> >The 6-patch series to follow this email extends KVM-hypervisor and Linux guest
> >running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's
> >implementation.
> >
> >One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick
> >another vcpu out of halt state.
> >The blocking of vcpu is done using halt() in (lock_spinning) slowpath.
> >one MSR is added to aid live migration.
> >
> >Changes in V5:
> >- rebased to 3.3-rc6
> >- added PV_UNHALT_MSR that would help in live migration (Avi)
> >- removed PV_LOCK_KICK vcpu request and pv_unhalt flag (re)added.
> 
> Sorry for pinging
> I know it is busy time. But I hope to get response on these patches
> in your free time, so that I can target next merge window for this.
> (whether it has reached some good state or it is heading in reverse
> direction!). it would really boost my morale.
> especially MSR stuff and dropping vcpu request bit for PV unhalt.
> 
> - Raghu

Looks good. Only the MSR appears an abuse, since there is no need
to expose the info to the guest.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:33:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7yF-0002jy-N5; Thu, 12 Apr 2012 00:33:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7yE-0002jq-1Y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:33:06 +0000
Received: from [193.109.254.147:19057] by server-6.bemta-14.messagelabs.com id
	44/E3-02047-1C2268F4; Thu, 12 Apr 2012 00:33:05 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334190783!4205672!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10669 invoked from network); 12 Apr 2012 00:33:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 00:33:04 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0Wv0K010227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:32:57 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0WtnY027850; Wed, 11 Apr 2012 20:32:56 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 997367A012;
	Wed, 11 Apr 2012 21:29:15 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C0TAGl001379;
	Wed, 11 Apr 2012 21:29:10 -0300
Date: Wed, 11 Apr 2012 21:29:09 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412002909.GD32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
	<20120412000629.GA32051@amt.cnet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120412000629.GA32051@amt.cnet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 09:06:29PM -0300, Marcelo Tosatti wrote:
> On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
> > From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > 
> > KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
> >     
> > The presence of these hypercalls is indicated to guest via
> > KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> > 
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> > ---
> > diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> > index 734c376..9234f13 100644
> > --- a/arch/x86/include/asm/kvm_para.h
> > +++ b/arch/x86/include/asm/kvm_para.h
> > @@ -16,12 +16,14 @@
> >  #define KVM_FEATURE_CLOCKSOURCE		0
> >  #define KVM_FEATURE_NOP_IO_DELAY	1
> >  #define KVM_FEATURE_MMU_OP		2
> > +
> >  /* This indicates that the new set of kvmclock msrs
> >   * are available. The use of 0x11 and 0x12 is deprecated
> >   */
> >  #define KVM_FEATURE_CLOCKSOURCE2        3
> >  #define KVM_FEATURE_ASYNC_PF		4
> >  #define KVM_FEATURE_STEAL_TIME		5
> > +#define KVM_FEATURE_PV_UNHALT		6
> >  
> >  /* The last 8 bits are used to indicate how to interpret the flags field
> >   * in pvclock structure. If no bits are set, all flags are ignored.
> > @@ -32,6 +34,7 @@
> >  #define MSR_KVM_SYSTEM_TIME 0x12
> >  
> >  #define KVM_MSR_ENABLED 1
> > +
> >  /* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
> >  #define MSR_KVM_WALL_CLOCK_NEW  0x4b564d00
> >  #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > index 89b02bf..61388b9 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
> >  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
> >  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
> >  			     (1 << KVM_FEATURE_ASYNC_PF) |
> > -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> > +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> > +			     (1 << KVM_FEATURE_PV_UNHALT);
> >  
> >  		if (sched_info_on())
> >  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 9cbfc06..bd5ef91 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -2079,6 +2079,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> >  	case KVM_CAP_XSAVE:
> >  	case KVM_CAP_ASYNC_PF:
> >  	case KVM_CAP_GET_TSC_KHZ:
> > +	case KVM_CAP_PV_UNHALT:
> >  		r = 1;
> >  		break;
> >  	case KVM_CAP_COALESCED_MMIO:
> > @@ -4913,6 +4914,30 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> >  	return 1;
> >  }
> >  
> > +/*
> > + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> > + *
> > + * @apicid - apicid of vcpu to be kicked.
> > + */
> > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> > +{
> > +	struct kvm_vcpu *vcpu = NULL;
> > +	int i;
> > +
> > +	kvm_for_each_vcpu(i, vcpu, kvm) {
> > +		if (!kvm_apic_present(vcpu))
> > +			continue;
> > +
> > +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> > +			break;
> > +	}
> > +	if (vcpu) {
> > +		vcpu->pv_unhalted = 1;
> > +		smp_mb();
> > +		kvm_vcpu_kick(vcpu);
> > +	}
> > +}
> > +
> >  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> >  {
> >  	unsigned long nr, a0, a1, a2, a3, ret;
> > @@ -4946,6 +4971,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> >  	case KVM_HC_VAPIC_POLL_IRQ:
> >  		ret = 0;
> >  		break;
> > +	case KVM_HC_KICK_CPU:
> > +		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
> > +		ret = 0;
> > +		break;
> >  	default:
> >  		ret = -KVM_ENOSYS;
> >  		break;
> > @@ -6174,6 +6203,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> >  		!vcpu->arch.apf.halted)
> >  		|| !list_empty_careful(&vcpu->async_pf.done)
> >  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> > +		|| vcpu->pv_unhalted
> >  		|| atomic_read(&vcpu->arch.nmi_queued) ||
> >  		(kvm_arch_interrupt_allowed(vcpu) &&
> >  		 kvm_cpu_has_interrupt(vcpu));
> > diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> > index 68e67e5..e822d96 100644
> > --- a/include/linux/kvm.h
> > +++ b/include/linux/kvm.h
> > @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
> >  #define KVM_CAP_PPC_PAPR 68
> >  #define KVM_CAP_S390_GMAP 71
> >  #define KVM_CAP_TSC_DEADLINE_TIMER 72
> > +#define KVM_CAP_PV_UNHALT 73
> >  
> >  #ifdef KVM_CAP_IRQ_ROUTING
> >  
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 900c763..433ae97 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -158,6 +158,7 @@ struct kvm_vcpu {
> >  #endif
> >  
> >  	struct kvm_vcpu_arch arch;
> > +	int pv_unhalted;
> >  };
> >  
> >  static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> > diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> > index ff476dd..38226e1 100644
> > --- a/include/linux/kvm_para.h
> > +++ b/include/linux/kvm_para.h
> > @@ -19,6 +19,7 @@
> >  #define KVM_HC_MMU_OP			2
> >  #define KVM_HC_FEATURES			3
> >  #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
> > +#define KVM_HC_KICK_CPU			5
> >  
> >  /*
> >   * hypercalls use architecture specific
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index a91f980..d3b98b1 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
> >  	vcpu->kvm = kvm;
> >  	vcpu->vcpu_id = id;
> >  	vcpu->pid = NULL;
> > +	vcpu->pv_unhalted = 0;
> >  	init_waitqueue_head(&vcpu->wq);
> >  	kvm_async_pf_vcpu_init(vcpu);
> >  
> > @@ -1567,6 +1568,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> >  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
> >  
> >  		if (kvm_arch_vcpu_runnable(vcpu)) {
> > +			vcpu->pv_unhalted = 0;
> > +			/* preventing reordering should be enough here */
> > +			barrier();
> 
> Is it always OK to erase the notification, even in case an unrelated
> event such as interrupt was the source of wakeup?

Note i am only asking whether it is OK to lose a notification, not 
requesting a change to atomic test-and-clear.

It would be nice to have a comment explaining it.

> 
> It would be easier to verify that notifications are not lost with atomic
> test_and_clear(pv_unhalted).
> 
> Also x86 specific code should remain in arch/x86/kvm/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 00:33:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 00:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI7yF-0002jy-N5; Thu, 12 Apr 2012 00:33:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1SI7yE-0002jq-1Y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 00:33:06 +0000
Received: from [193.109.254.147:19057] by server-6.bemta-14.messagelabs.com id
	44/E3-02047-1C2268F4; Thu, 12 Apr 2012 00:33:05 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334190783!4205672!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MDk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10669 invoked from network); 12 Apr 2012 00:33:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 00:33:04 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3C0Wv0K010227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Apr 2012 20:32:57 -0400
Received: from amt.cnet (vpn-9-16.rdu.redhat.com [10.11.9.16])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3C0WtnY027850; Wed, 11 Apr 2012 20:32:56 -0400
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 997367A012;
	Wed, 11 Apr 2012 21:29:15 -0300 (BRT)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q3C0TAGl001379;
	Wed, 11 Apr 2012 21:29:10 -0300
Date: Wed, 11 Apr 2012 21:29:09 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120412002909.GD32051@amt.cnet>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
	<20120412000629.GA32051@amt.cnet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120412000629.GA32051@amt.cnet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 09:06:29PM -0300, Marcelo Tosatti wrote:
> On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
> > From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > 
> > KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
> >     
> > The presence of these hypercalls is indicated to guest via
> > KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> > 
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> > ---
> > diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> > index 734c376..9234f13 100644
> > --- a/arch/x86/include/asm/kvm_para.h
> > +++ b/arch/x86/include/asm/kvm_para.h
> > @@ -16,12 +16,14 @@
> >  #define KVM_FEATURE_CLOCKSOURCE		0
> >  #define KVM_FEATURE_NOP_IO_DELAY	1
> >  #define KVM_FEATURE_MMU_OP		2
> > +
> >  /* This indicates that the new set of kvmclock msrs
> >   * are available. The use of 0x11 and 0x12 is deprecated
> >   */
> >  #define KVM_FEATURE_CLOCKSOURCE2        3
> >  #define KVM_FEATURE_ASYNC_PF		4
> >  #define KVM_FEATURE_STEAL_TIME		5
> > +#define KVM_FEATURE_PV_UNHALT		6
> >  
> >  /* The last 8 bits are used to indicate how to interpret the flags field
> >   * in pvclock structure. If no bits are set, all flags are ignored.
> > @@ -32,6 +34,7 @@
> >  #define MSR_KVM_SYSTEM_TIME 0x12
> >  
> >  #define KVM_MSR_ENABLED 1
> > +
> >  /* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
> >  #define MSR_KVM_WALL_CLOCK_NEW  0x4b564d00
> >  #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > index 89b02bf..61388b9 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
> >  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
> >  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
> >  			     (1 << KVM_FEATURE_ASYNC_PF) |
> > -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> > +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> > +			     (1 << KVM_FEATURE_PV_UNHALT);
> >  
> >  		if (sched_info_on())
> >  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 9cbfc06..bd5ef91 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -2079,6 +2079,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> >  	case KVM_CAP_XSAVE:
> >  	case KVM_CAP_ASYNC_PF:
> >  	case KVM_CAP_GET_TSC_KHZ:
> > +	case KVM_CAP_PV_UNHALT:
> >  		r = 1;
> >  		break;
> >  	case KVM_CAP_COALESCED_MMIO:
> > @@ -4913,6 +4914,30 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> >  	return 1;
> >  }
> >  
> > +/*
> > + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> > + *
> > + * @apicid - apicid of vcpu to be kicked.
> > + */
> > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> > +{
> > +	struct kvm_vcpu *vcpu = NULL;
> > +	int i;
> > +
> > +	kvm_for_each_vcpu(i, vcpu, kvm) {
> > +		if (!kvm_apic_present(vcpu))
> > +			continue;
> > +
> > +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> > +			break;
> > +	}
> > +	if (vcpu) {
> > +		vcpu->pv_unhalted = 1;
> > +		smp_mb();
> > +		kvm_vcpu_kick(vcpu);
> > +	}
> > +}
> > +
> >  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> >  {
> >  	unsigned long nr, a0, a1, a2, a3, ret;
> > @@ -4946,6 +4971,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> >  	case KVM_HC_VAPIC_POLL_IRQ:
> >  		ret = 0;
> >  		break;
> > +	case KVM_HC_KICK_CPU:
> > +		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
> > +		ret = 0;
> > +		break;
> >  	default:
> >  		ret = -KVM_ENOSYS;
> >  		break;
> > @@ -6174,6 +6203,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> >  		!vcpu->arch.apf.halted)
> >  		|| !list_empty_careful(&vcpu->async_pf.done)
> >  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> > +		|| vcpu->pv_unhalted
> >  		|| atomic_read(&vcpu->arch.nmi_queued) ||
> >  		(kvm_arch_interrupt_allowed(vcpu) &&
> >  		 kvm_cpu_has_interrupt(vcpu));
> > diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> > index 68e67e5..e822d96 100644
> > --- a/include/linux/kvm.h
> > +++ b/include/linux/kvm.h
> > @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
> >  #define KVM_CAP_PPC_PAPR 68
> >  #define KVM_CAP_S390_GMAP 71
> >  #define KVM_CAP_TSC_DEADLINE_TIMER 72
> > +#define KVM_CAP_PV_UNHALT 73
> >  
> >  #ifdef KVM_CAP_IRQ_ROUTING
> >  
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 900c763..433ae97 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -158,6 +158,7 @@ struct kvm_vcpu {
> >  #endif
> >  
> >  	struct kvm_vcpu_arch arch;
> > +	int pv_unhalted;
> >  };
> >  
> >  static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> > diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> > index ff476dd..38226e1 100644
> > --- a/include/linux/kvm_para.h
> > +++ b/include/linux/kvm_para.h
> > @@ -19,6 +19,7 @@
> >  #define KVM_HC_MMU_OP			2
> >  #define KVM_HC_FEATURES			3
> >  #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
> > +#define KVM_HC_KICK_CPU			5
> >  
> >  /*
> >   * hypercalls use architecture specific
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index a91f980..d3b98b1 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
> >  	vcpu->kvm = kvm;
> >  	vcpu->vcpu_id = id;
> >  	vcpu->pid = NULL;
> > +	vcpu->pv_unhalted = 0;
> >  	init_waitqueue_head(&vcpu->wq);
> >  	kvm_async_pf_vcpu_init(vcpu);
> >  
> > @@ -1567,6 +1568,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> >  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
> >  
> >  		if (kvm_arch_vcpu_runnable(vcpu)) {
> > +			vcpu->pv_unhalted = 0;
> > +			/* preventing reordering should be enough here */
> > +			barrier();
> 
> Is it always OK to erase the notification, even in case an unrelated
> event such as interrupt was the source of wakeup?

Note i am only asking whether it is OK to lose a notification, not 
requesting a change to atomic test-and-clear.

It would be nice to have a comment explaining it.

> 
> It would be easier to verify that notifications are not lost with atomic
> test_and_clear(pv_unhalted).
> 
> Also x86 specific code should remain in arch/x86/kvm/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 01:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 01:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI8sj-0006uj-Hf; Thu, 12 Apr 2012 01:31:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI8si-0006ue-4U
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 01:31:28 +0000
Received: from [85.158.138.51:50038] by server-8.bemta-3.messagelabs.com id
	CB/6A-24428-F60368F4; Thu, 12 Apr 2012 01:31:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334194286!21800772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28318 invoked from network); 12 Apr 2012 01:31:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 01:31:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,408,1330905600"; d="scan'208";a="11888989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 01:31:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 02:31:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SI8se-0000BV-Hs;
	Thu, 12 Apr 2012 01:31:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SI8se-0003B0-EH;
	Thu, 12 Apr 2012 02:31:24 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 02:31:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12644: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12644 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12644/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                923e9a1399b620d063cd88537c64561bc3d5f905
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 01:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 01:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SI8sj-0006uj-Hf; Thu, 12 Apr 2012 01:31:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SI8si-0006ue-4U
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 01:31:28 +0000
Received: from [85.158.138.51:50038] by server-8.bemta-3.messagelabs.com id
	CB/6A-24428-F60368F4; Thu, 12 Apr 2012 01:31:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334194286!21800772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28318 invoked from network); 12 Apr 2012 01:31:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 01:31:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,408,1330905600"; d="scan'208";a="11888989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 01:31:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 02:31:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SI8se-0000BV-Hs;
	Thu, 12 Apr 2012 01:31:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SI8se-0003B0-EH;
	Thu, 12 Apr 2012 02:31:24 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 02:31:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12644: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12644 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12644/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                923e9a1399b620d063cd88537c64561bc3d5f905
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 03:24:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 03:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIAdU-0007lI-52; Thu, 12 Apr 2012 03:23:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1SIAdT-0007lD-Gn
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 03:23:51 +0000
Received: from [85.158.143.99:34290] by server-3.bemta-4.messagelabs.com id
	E5/FD-05853-6CA468F4; Thu, 12 Apr 2012 03:23:50 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334201028!24715954!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31838 invoked from network); 12 Apr 2012 03:23:49 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 03:23:49 -0000
Received: by yenl11 with SMTP id l11so1031693yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 20:23:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=98t8ymiZfUxjyDucSG0w9S9kJJkfLy824lKscPNKgxs=;
	b=QBm6Xbq7G38q1MEFygLoZJbSKp7N0A/uNZa7e6vo5tmwpEHZZP5CE634IjhfsP99uk
	Zei6m+kzt0n/7JhiDEuZS+6A0RQx8d8r5axPCj2rWTZ6At5sQhS8YkILeCLVUltMRW4l
	A0gVqr70RSKUcBg5OgJMLTNLo+1voGRikFLFHxN7EbXXc9auSs/azDR88j+uroTxUq0G
	wlmF28KP8b9kUDmVgi19nf3N7T8dsotSKj1ek8lGvibmRDdyRpBroV08nwEotyrmgalh
	wMqrH9I8oajLQp1912f4edoQijkHT09QMExZQARuLIrrKzxfx8APY88p1k9zc4+bmR7R
	DSkg==
Received: by 10.50.45.138 with SMTP id n10mr227807igm.70.1334201027483; Wed,
	11 Apr 2012 20:23:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.42.9 with HTTP; Wed, 11 Apr 2012 20:23:17 -0700 (PDT)
In-Reply-To: <4F85B925.6090309@redhat.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
	<4F85B925.6090309@redhat.com>
From: Wei Liu <liuw@liuw.name>
Date: Thu, 12 Apr 2012 11:23:17 +0800
Message-ID: <CAOsiSVVjxpZAW4GOMto9qoEMgGQUgfTD9b1SDT2uqH+Oa8O0SQ@mail.gmail.com>
To: Eric Blake <eblake@redhat.com>
X-Gm-Message-State: ALoCoQk0EvZ/OgKfWfFvFBl5b82/MuvcSwQS1MZYNMA3Gh8RaYbwlZnBO7Hi+93Qtwne7cwFmnGZ
Cc: Peter Maydell <peter.maydell@linaro.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
	and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCBBcHIgMTIsIDIwMTIgYXQgMTowMiBBTSwgRXJpYyBCbGFrZSA8ZWJsYWtlQHJlZGhh
dC5jb20+IHdyb3RlOgo+IE9uIDA0LzExLzIwMTIgMTA6MTcgQU0sIFN0ZWZhbm8gU3RhYmVsbGlu
aSB3cm90ZToKPj4gT24gV2VkLCAxMSBBcHIgMjAxMiwgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPj4+
IE9uIDUgQXByaWwgMjAxMiAxMDozNSwgV2VpIExpdSA8d2VpLmxpdTJAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4+Pj4KPj4+PiAtLS0gL2Rldi9udWxsCj4+Pj4gKysrIGIvaHcveGVuX2FwaWMuYwo+Pj4+
IEBAIC0wLDAgKzEsOTAgQEAKPj4+PiArLyoKPj4+PiArICogWGVuIGJhc2ljIEFQSUMgc3VwcG9y
dAo+Pj4+ICsgKgo+Pj4+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMTIgQ2l0cml4Cj4+Pj4gKyAqCj4+
Pj4gKyAqIEF1dGhvcnM6Cj4+Pj4gKyAqIMKgV2VpIExpdSA8d2VpLmxpdTJAY2l0cml4LmNvbT4K
Pj4+PiArICoKPj4+PiArICogVGhpcyB3b3JrIGlzIGxpY2Vuc2VkIHVuZGVyIHRoZSB0ZXJtcyBv
ZiB0aGUgR05VIEdQTCB2ZXJzaW9uIDIuCj4+Pj4gKyAqIFNlZSB0aGUgQ09QWUlORyBmaWxlIGlu
IHRoZSB0b3AtbGV2ZWwgZGlyZWN0b3J5Lgo+Pj4+ICsgKi8KPj4+Cj4+PiBSZWFsbHkgMi1vbmx5
LCBub3QgMi1vci1sYXRlciA/Cj4+Cj4+IEkgYW0gbm90IGEgZ3JlYXQgZnVuIG9mIHRoZSAyLW9y
LWxhdGVyIGNsYXVzZSBhbmQgaXQgZG9lc24ndCBsb29rIGxpa2UgYQo+PiByZXF1aXJlbWVudCBm
cm9tIHRoZSBRRU1VIHByb2plY3QgUE9WLiBIb3dldmVyIGlmIGl0IGlzLCBJJ2xsIGNoYW5nZSBp
dAo+PiB0byAyLW9yLWxhdGVyLgo+Cj4gQ29udmVyc2VseSwgSSBhbSBub3QgYSBncmVhdCBmYW4g
b2YgdGhlIDItb25seSBjbGF1c2UsIGFzIGl0IHByZXZlbnRzCj4gcmV1c2Ugb2YgcWVtdSBjb2Rl
IGluIG90aGVyIHByb2plY3RzLiDCoFRoZXJlJ3MgYSByZWFzb24gdGhhdCBxZW11IGlzIG5vdwo+
IGZhdm9yaW5nIDItb3ItbGF0ZXIgZm9yIG5ldyBzdWJtaXNzaW9ucy4KPgo+IGh0dHA6Ly93aWtp
LnFlbXUub3JnL1JlbGljZW5zaW5nCj4KCkkgZG9uJ3QgbWluZCBjaGFuZ2luZyB0aGUgbGljZW5z
aW5nIHRvIDItb3ItbGF0ZXIgZm9yIGdyZWF0ZXIgYmVuZWZpdC4KClN0ZWZhbm8sIHBsZWFzZSBk
byB3aGF0ZXZlciB5b3UgbmVlZCB0by4KCgpXZWkuCgo+IC0tCj4gRXJpYyBCbGFrZSDCoCBlYmxh
a2VAcmVkaGF0LmNvbSDCoCDCoCsxLTkxOS0zMDEtMzI2Ngo+IExpYnZpcnQgdmlydHVhbGl6YXRp
b24gbGlicmFyeSBodHRwOi8vbGlidmlydC5vcmcKPgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Apr 12 03:24:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 03:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIAdU-0007lI-52; Thu, 12 Apr 2012 03:23:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1SIAdT-0007lD-Gn
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 03:23:51 +0000
Received: from [85.158.143.99:34290] by server-3.bemta-4.messagelabs.com id
	E5/FD-05853-6CA468F4; Thu, 12 Apr 2012 03:23:50 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334201028!24715954!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31838 invoked from network); 12 Apr 2012 03:23:49 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 03:23:49 -0000
Received: by yenl11 with SMTP id l11so1031693yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Apr 2012 20:23:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=98t8ymiZfUxjyDucSG0w9S9kJJkfLy824lKscPNKgxs=;
	b=QBm6Xbq7G38q1MEFygLoZJbSKp7N0A/uNZa7e6vo5tmwpEHZZP5CE634IjhfsP99uk
	Zei6m+kzt0n/7JhiDEuZS+6A0RQx8d8r5axPCj2rWTZ6At5sQhS8YkILeCLVUltMRW4l
	A0gVqr70RSKUcBg5OgJMLTNLo+1voGRikFLFHxN7EbXXc9auSs/azDR88j+uroTxUq0G
	wlmF28KP8b9kUDmVgi19nf3N7T8dsotSKj1ek8lGvibmRDdyRpBroV08nwEotyrmgalh
	wMqrH9I8oajLQp1912f4edoQijkHT09QMExZQARuLIrrKzxfx8APY88p1k9zc4+bmR7R
	DSkg==
Received: by 10.50.45.138 with SMTP id n10mr227807igm.70.1334201027483; Wed,
	11 Apr 2012 20:23:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.42.9 with HTTP; Wed, 11 Apr 2012 20:23:17 -0700 (PDT)
In-Reply-To: <4F85B925.6090309@redhat.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<alpine.DEB.2.00.1204111716030.15151@kaball-desktop>
	<4F85B925.6090309@redhat.com>
From: Wei Liu <liuw@liuw.name>
Date: Thu, 12 Apr 2012 11:23:17 +0800
Message-ID: <CAOsiSVVjxpZAW4GOMto9qoEMgGQUgfTD9b1SDT2uqH+Oa8O0SQ@mail.gmail.com>
To: Eric Blake <eblake@redhat.com>
X-Gm-Message-State: ALoCoQk0EvZ/OgKfWfFvFBl5b82/MuvcSwQS1MZYNMA3Gh8RaYbwlZnBO7Hi+93Qtwne7cwFmnGZ
Cc: Peter Maydell <peter.maydell@linaro.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] Xen: Add xen-apic support
	and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCBBcHIgMTIsIDIwMTIgYXQgMTowMiBBTSwgRXJpYyBCbGFrZSA8ZWJsYWtlQHJlZGhh
dC5jb20+IHdyb3RlOgo+IE9uIDA0LzExLzIwMTIgMTA6MTcgQU0sIFN0ZWZhbm8gU3RhYmVsbGlu
aSB3cm90ZToKPj4gT24gV2VkLCAxMSBBcHIgMjAxMiwgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPj4+
IE9uIDUgQXByaWwgMjAxMiAxMDozNSwgV2VpIExpdSA8d2VpLmxpdTJAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4+Pj4KPj4+PiAtLS0gL2Rldi9udWxsCj4+Pj4gKysrIGIvaHcveGVuX2FwaWMuYwo+Pj4+
IEBAIC0wLDAgKzEsOTAgQEAKPj4+PiArLyoKPj4+PiArICogWGVuIGJhc2ljIEFQSUMgc3VwcG9y
dAo+Pj4+ICsgKgo+Pj4+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMTIgQ2l0cml4Cj4+Pj4gKyAqCj4+
Pj4gKyAqIEF1dGhvcnM6Cj4+Pj4gKyAqIMKgV2VpIExpdSA8d2VpLmxpdTJAY2l0cml4LmNvbT4K
Pj4+PiArICoKPj4+PiArICogVGhpcyB3b3JrIGlzIGxpY2Vuc2VkIHVuZGVyIHRoZSB0ZXJtcyBv
ZiB0aGUgR05VIEdQTCB2ZXJzaW9uIDIuCj4+Pj4gKyAqIFNlZSB0aGUgQ09QWUlORyBmaWxlIGlu
IHRoZSB0b3AtbGV2ZWwgZGlyZWN0b3J5Lgo+Pj4+ICsgKi8KPj4+Cj4+PiBSZWFsbHkgMi1vbmx5
LCBub3QgMi1vci1sYXRlciA/Cj4+Cj4+IEkgYW0gbm90IGEgZ3JlYXQgZnVuIG9mIHRoZSAyLW9y
LWxhdGVyIGNsYXVzZSBhbmQgaXQgZG9lc24ndCBsb29rIGxpa2UgYQo+PiByZXF1aXJlbWVudCBm
cm9tIHRoZSBRRU1VIHByb2plY3QgUE9WLiBIb3dldmVyIGlmIGl0IGlzLCBJJ2xsIGNoYW5nZSBp
dAo+PiB0byAyLW9yLWxhdGVyLgo+Cj4gQ29udmVyc2VseSwgSSBhbSBub3QgYSBncmVhdCBmYW4g
b2YgdGhlIDItb25seSBjbGF1c2UsIGFzIGl0IHByZXZlbnRzCj4gcmV1c2Ugb2YgcWVtdSBjb2Rl
IGluIG90aGVyIHByb2plY3RzLiDCoFRoZXJlJ3MgYSByZWFzb24gdGhhdCBxZW11IGlzIG5vdwo+
IGZhdm9yaW5nIDItb3ItbGF0ZXIgZm9yIG5ldyBzdWJtaXNzaW9ucy4KPgo+IGh0dHA6Ly93aWtp
LnFlbXUub3JnL1JlbGljZW5zaW5nCj4KCkkgZG9uJ3QgbWluZCBjaGFuZ2luZyB0aGUgbGljZW5z
aW5nIHRvIDItb3ItbGF0ZXIgZm9yIGdyZWF0ZXIgYmVuZWZpdC4KClN0ZWZhbm8sIHBsZWFzZSBk
byB3aGF0ZXZlciB5b3UgbmVlZCB0by4KCgpXZWkuCgo+IC0tCj4gRXJpYyBCbGFrZSDCoCBlYmxh
a2VAcmVkaGF0LmNvbSDCoCDCoCsxLTkxOS0zMDEtMzI2Ngo+IExpYnZpcnQgdmlydHVhbGl6YXRp
b24gbGlicmFyeSBodHRwOi8vbGlidmlydC5vcmcKPgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Apr 12 04:37:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 04:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIBlm-0000Lb-UG; Thu, 12 Apr 2012 04:36:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIBll-0000LR-3R
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 04:36:29 +0000
Received: from [85.158.138.51:20967] by server-12.bemta-3.messagelabs.com id
	AF/D0-29760-CCB568F4; Thu, 12 Apr 2012 04:36:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334205387!21768442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 12 Apr 2012 04:36:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 04:36:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,409,1330905600"; d="scan'208";a="11890752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 04:36:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 05:36:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIBli-0001Cq-L5;
	Thu, 12 Apr 2012 04:36:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIBli-0004Z0-KQ;
	Thu, 12 Apr 2012 05:36:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12646-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 05:36:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12646: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12646 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12646/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 04:37:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 04:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIBlm-0000Lb-UG; Thu, 12 Apr 2012 04:36:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIBll-0000LR-3R
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 04:36:29 +0000
Received: from [85.158.138.51:20967] by server-12.bemta-3.messagelabs.com id
	AF/D0-29760-CCB568F4; Thu, 12 Apr 2012 04:36:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334205387!21768442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 12 Apr 2012 04:36:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 04:36:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,409,1330905600"; d="scan'208";a="11890752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 04:36:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 05:36:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIBli-0001Cq-L5;
	Thu, 12 Apr 2012 04:36:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIBli-0004Z0-KQ;
	Thu, 12 Apr 2012 05:36:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12646-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 05:36:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12646: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12646 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12646/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 06:16:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 06:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIDJU-0001Tw-O4; Thu, 12 Apr 2012 06:15:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIDJT-0001Tr-AC
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 06:15:23 +0000
Received: from [85.158.139.83:65489] by server-10.bemta-5.messagelabs.com id
	D9/CA-08260-AF2768F4; Thu, 12 Apr 2012 06:15:22 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334211320!19566545!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13331 invoked from network); 12 Apr 2012 06:15:21 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Apr 2012 06:15:21 -0000
Received: from mail133-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 06:15:19 +0000
Received: from mail133-ch1 (localhost [127.0.0.1])	by
	mail133-ch1-R.bigfish.com (Postfix) with ESMTP id 99DFC1C0429;
	Thu, 12 Apr 2012 06:15:19 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail133-ch1 (localhost.localdomain [127.0.0.1]) by mail133-ch1
	(MessageSwitch) id 1334211303304180_16869;
	Thu, 12 Apr 2012 06:15:03 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.230])	by mail133-ch1.bigfish.com (Postfix) with ESMTP id
	481183001CC;	Thu, 12 Apr 2012 06:15:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 06:15:01 +0000
X-WSS-ID: 0M2CS0Z-01-0IO-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A9451028098;	Thu, 12 Apr 2012 01:14:59 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 12 Apr 2012 01:15:14 -0500
Received: from [10.224.11.185] (10.224.11.185) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 01:14:59 -0500
Message-ID: <4F8672E3.80302@amd.com>
Date: Thu, 12 Apr 2012 01:14:59 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Gianluca Guida <glguida@gmail.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
In-Reply-To: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 06:04 PM, Gianluca Guida wrote:
> Hello,
>
> HAP paging mode guests use direct MSR read/write into the VMCS/VMCB
> for the guest PAT table, while the current  save/restore code was
> accessing only the pat_cr field in hvm_vcpu, used when intercepting
> the MSR mostly in shadow mode (the Intel scenario is a bit more
> complicated).
> This patch fixes this issue creating a new couple of hvm_funcs,
> get/set_guest_pat, that access the right PAT table based on the paging
> mode and guest configuration.
>
> As a major caveat, I haven't tested this patch on AMD, for lack of hardware.
I can test it on my AMD box tomorrow. BTW from my understanding, this 
patch doesn't have performance implication for nested paging mode, does it?

-Wei
>
> Signed-off-by: Gianluca Guida<gianluca.guida@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 06:16:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 06:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIDJU-0001Tw-O4; Thu, 12 Apr 2012 06:15:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIDJT-0001Tr-AC
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 06:15:23 +0000
Received: from [85.158.139.83:65489] by server-10.bemta-5.messagelabs.com id
	D9/CA-08260-AF2768F4; Thu, 12 Apr 2012 06:15:22 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334211320!19566545!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13331 invoked from network); 12 Apr 2012 06:15:21 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Apr 2012 06:15:21 -0000
Received: from mail133-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 06:15:19 +0000
Received: from mail133-ch1 (localhost [127.0.0.1])	by
	mail133-ch1-R.bigfish.com (Postfix) with ESMTP id 99DFC1C0429;
	Thu, 12 Apr 2012 06:15:19 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail133-ch1 (localhost.localdomain [127.0.0.1]) by mail133-ch1
	(MessageSwitch) id 1334211303304180_16869;
	Thu, 12 Apr 2012 06:15:03 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.230])	by mail133-ch1.bigfish.com (Postfix) with ESMTP id
	481183001CC;	Thu, 12 Apr 2012 06:15:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 06:15:01 +0000
X-WSS-ID: 0M2CS0Z-01-0IO-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A9451028098;	Thu, 12 Apr 2012 01:14:59 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 12 Apr 2012 01:15:14 -0500
Received: from [10.224.11.185] (10.224.11.185) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 01:14:59 -0500
Message-ID: <4F8672E3.80302@amd.com>
Date: Thu, 12 Apr 2012 01:14:59 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Gianluca Guida <glguida@gmail.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
In-Reply-To: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/2012 06:04 PM, Gianluca Guida wrote:
> Hello,
>
> HAP paging mode guests use direct MSR read/write into the VMCS/VMCB
> for the guest PAT table, while the current  save/restore code was
> accessing only the pat_cr field in hvm_vcpu, used when intercepting
> the MSR mostly in shadow mode (the Intel scenario is a bit more
> complicated).
> This patch fixes this issue creating a new couple of hvm_funcs,
> get/set_guest_pat, that access the right PAT table based on the paging
> mode and guest configuration.
>
> As a major caveat, I haven't tested this patch on AMD, for lack of hardware.
I can test it on my AMD box tomorrow. BTW from my understanding, this 
patch doesn't have performance implication for nested paging mode, does it?

-Wei
>
> Signed-off-by: Gianluca Guida<gianluca.guida@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 06:50:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 06:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIDr3-0001j7-IG; Thu, 12 Apr 2012 06:50:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SIDr1-0001j2-Pc
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 06:50:03 +0000
Received: from [85.158.139.83:40366] by server-2.bemta-5.messagelabs.com id
	3A/51-17016-A1B768F4; Thu, 12 Apr 2012 06:50:02 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334213401!23452158!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYyMjI4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13725 invoked from network); 12 Apr 2012 06:50:02 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 06:50:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 11 Apr 2012 23:50:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88141635"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 11 Apr 2012 23:50:00 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 11 Apr 2012 23:50:00 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 12 Apr 2012 14:49:58 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Aleksandr Tarutin <atarutin@orionsbelt.net>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] PCI Passthrough of SAS controller not working
Thread-Index: AQHNGB0OmjQWv9+wh0Okad3l+SO6LZaWvnTQ
Date: Thu, 12 Apr 2012 06:49:57 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10071533@SHSMSX101.ccr.corp.intel.com>
References: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
In-Reply-To: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can you also attach your config file for creating the PVHVM guest ?
And the output of 'xm info' or 'xl info' ?
BTW, if using Xen 4.x, 'xl/libxl' toolstack is recommended instead of 'xm/x=
end'.

Best Regards,
     Yongjie (Jay)

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Aleksandr Tarutin
Sent: Thursday, April 12, 2012 3:52 AM
To: xen-devel@lists.xen.org
Subject: [Xen-devel] PCI Passthrough of SAS controller not working

Hello.

I tried to setup PCI Passthrough of a SAS controller into a PVHVM domU. The=
 device was present in the domU but its modules wouldn't load.

The first related thing was the following message in the guest BIOS just be=
fore grub starts:
MPT BIOS Fault 09h encountered at adapter=A0PCI(00h,05h,00h).

I'm attaching the xm dmesg and dmesg from both the host and a guest as well=
 as lspci -v.

-- =

AT.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 06:50:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 06:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIDr3-0001j7-IG; Thu, 12 Apr 2012 06:50:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SIDr1-0001j2-Pc
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 06:50:03 +0000
Received: from [85.158.139.83:40366] by server-2.bemta-5.messagelabs.com id
	3A/51-17016-A1B768F4; Thu, 12 Apr 2012 06:50:02 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334213401!23452158!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYyMjI4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13725 invoked from network); 12 Apr 2012 06:50:02 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 06:50:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 11 Apr 2012 23:50:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88141635"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 11 Apr 2012 23:50:00 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 11 Apr 2012 23:50:00 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 12 Apr 2012 14:49:58 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Aleksandr Tarutin <atarutin@orionsbelt.net>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] PCI Passthrough of SAS controller not working
Thread-Index: AQHNGB0OmjQWv9+wh0Okad3l+SO6LZaWvnTQ
Date: Thu, 12 Apr 2012 06:49:57 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10071533@SHSMSX101.ccr.corp.intel.com>
References: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
In-Reply-To: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can you also attach your config file for creating the PVHVM guest ?
And the output of 'xm info' or 'xl info' ?
BTW, if using Xen 4.x, 'xl/libxl' toolstack is recommended instead of 'xm/x=
end'.

Best Regards,
     Yongjie (Jay)

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Aleksandr Tarutin
Sent: Thursday, April 12, 2012 3:52 AM
To: xen-devel@lists.xen.org
Subject: [Xen-devel] PCI Passthrough of SAS controller not working

Hello.

I tried to setup PCI Passthrough of a SAS controller into a PVHVM domU. The=
 device was present in the domU but its modules wouldn't load.

The first related thing was the following message in the guest BIOS just be=
fore grub starts:
MPT BIOS Fault 09h encountered at adapter=A0PCI(00h,05h,00h).

I'm attaching the xm dmesg and dmesg from both the host and a guest as well=
 as lspci -v.

-- =

AT.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 06:53:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 06:53:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIDu6-0001oP-4d; Thu, 12 Apr 2012 06:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIDu4-0001oJ-NN
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 06:53:12 +0000
Received: from [85.158.138.51:8171] by server-9.bemta-3.messagelabs.com id
	87/D6-26691-7DB768F4; Thu, 12 Apr 2012 06:53:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334213591!21752702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29825 invoked from network); 12 Apr 2012 06:53:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 06:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11891727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:53:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 07:53:11 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIDu2-0002Ta-Tz;
	Thu, 12 Apr 2012 06:53:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIDu2-0006d1-Qn;
	Thu, 12 Apr 2012 07:53:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12649-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 07:53:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12649: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12649 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12649/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12640
 build-amd64                   4 xen-build                 fail REGR. vs. 12640
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12640

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 06:53:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 06:53:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIDu6-0001oP-4d; Thu, 12 Apr 2012 06:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIDu4-0001oJ-NN
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 06:53:12 +0000
Received: from [85.158.138.51:8171] by server-9.bemta-3.messagelabs.com id
	87/D6-26691-7DB768F4; Thu, 12 Apr 2012 06:53:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334213591!21752702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29825 invoked from network); 12 Apr 2012 06:53:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 06:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11891727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:53:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 07:53:11 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIDu2-0002Ta-Tz;
	Thu, 12 Apr 2012 06:53:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIDu2-0006d1-Qn;
	Thu, 12 Apr 2012 07:53:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12649-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 07:53:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12649: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12649 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12649/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12640
 build-amd64                   4 xen-build                 fail REGR. vs. 12640
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12640

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:09:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIE9P-0002Cg-Ll; Thu, 12 Apr 2012 07:09:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIE9N-0002Cb-Uv
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:09:02 +0000
Received: from [193.109.254.147:22135] by server-4.bemta-14.messagelabs.com id
	20/C5-11570-D8F768F4; Thu, 12 Apr 2012 07:09:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334214540!1752622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11464 invoked from network); 12 Apr 2012 07:09:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:09:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11891962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:09:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:09:00 +0100
Message-ID: <1334214539.12209.219.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Thu, 12 Apr 2012 07:08:59 +0000
In-Reply-To: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> Hi,
> 
> This is just my experience about issues I encountered when upgrade
> from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> changeset 25191:a95fc7decc83.
> 
> 1. Immediately after upgrade, xl list show such error:
> 
> # xl list
> libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> Permission denied
> libxl_domain_infolist failed.
> 
> After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> there are running domUs... this might cause issues to shutdown?  I
> will downgrade and repeat such test to confirm.  Might be worth a note
> in upgrading note about this if this is intended?

The tools and the hypervisor are a matched pair so you would need to
reboot the system in order to use the new tools. This has always been
the case with Xen upgrades.

> 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> work whereby setting rtc_timeoffset works.  Any idea?

I've CC'd Lin Ming who implemented both of those.

> 3. xl trigger hvmdomain power still never remove those related
> iptables forward rules.  This is the same problem when I test in
> xen-4.1-testing.  Refer to
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00771.html
> about past report.  When test in xen-4.1-testing, one funny behaviour
> is if I start hvmdomain using xm then use xl trigger hvmdomain power
> does remove those iptables related rule chain.

I think this is an issue with the hotplug scripts not being run at the
right time. There are some improvements to this in the pipeline which I
hope will help here.

> I shall do more testing when time permit and sorry if this report is
> useless to anyone.

On the contrary it is always useful to hear about these things, thank
you.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:09:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIE9P-0002Cg-Ll; Thu, 12 Apr 2012 07:09:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIE9N-0002Cb-Uv
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:09:02 +0000
Received: from [193.109.254.147:22135] by server-4.bemta-14.messagelabs.com id
	20/C5-11570-D8F768F4; Thu, 12 Apr 2012 07:09:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334214540!1752622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11464 invoked from network); 12 Apr 2012 07:09:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:09:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11891962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:09:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:09:00 +0100
Message-ID: <1334214539.12209.219.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Thu, 12 Apr 2012 07:08:59 +0000
In-Reply-To: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> Hi,
> 
> This is just my experience about issues I encountered when upgrade
> from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> changeset 25191:a95fc7decc83.
> 
> 1. Immediately after upgrade, xl list show such error:
> 
> # xl list
> libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> Permission denied
> libxl_domain_infolist failed.
> 
> After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> there are running domUs... this might cause issues to shutdown?  I
> will downgrade and repeat such test to confirm.  Might be worth a note
> in upgrading note about this if this is intended?

The tools and the hypervisor are a matched pair so you would need to
reboot the system in order to use the new tools. This has always been
the case with Xen upgrades.

> 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> work whereby setting rtc_timeoffset works.  Any idea?

I've CC'd Lin Ming who implemented both of those.

> 3. xl trigger hvmdomain power still never remove those related
> iptables forward rules.  This is the same problem when I test in
> xen-4.1-testing.  Refer to
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00771.html
> about past report.  When test in xen-4.1-testing, one funny behaviour
> is if I start hvmdomain using xm then use xl trigger hvmdomain power
> does remove those iptables related rule chain.

I think this is an issue with the hotplug scripts not being run at the
right time. There are some improvements to this in the pipeline which I
hope will help here.

> I shall do more testing when time permit and sorry if this report is
> useless to anyone.

On the contrary it is always useful to hear about these things, thank
you.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:23:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:23:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEMX-0002dv-Jg; Thu, 12 Apr 2012 07:22:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SIEMV-0002dj-Iy
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:22:35 +0000
Received: from [193.109.254.147:41639] by server-5.bemta-14.messagelabs.com id
	0A/D2-30733-AB2868F4; Thu, 12 Apr 2012 07:22:34 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334215353!1754639!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23368 invoked from network); 12 Apr 2012 07:22:34 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:22:34 -0000
Received: by vcbfl15 with SMTP id fl15so1359227vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 00:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=rBWp7gRQnP3Xw48VibWQIry9VpkLh7WL9QDHL/i8+UA=;
	b=r95nEhPjx2KfZf2Qk9+qxbkj/35uAkxK0URe7NGi3CMdgQ9d2u5Y9fHUr4xtjTxY1x
	f+7Pc2fYsAhI3JgTBwcH0tdcYvYcB+X2g3D3bFY7OEKL+cifRfbS3vculkvFUNmV8zrG
	WCeFnAhHEBE7Eg1nQG7lBhcYLbJW3OkmsGXXJDaH4TROneisduKMjWa9ArQALEHUtWgr
	+RMIoj0oNAkRBSlX5uBr+qZGK0GsKzLV338aPFP0yIsVGU8xpYT4h0j4hMP4N4F8Lev1
	wRW8rPe8+yTNuKog15ze/Az8mlfYYdkh4Q81zeB+cPerOGyCqIGsY1NzXYvRb1Js6zvR
	x2Og==
MIME-Version: 1.0
Received: by 10.220.141.79 with SMTP id l15mr791571vcu.48.1334215352617; Thu,
	12 Apr 2012 00:22:32 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Thu, 12 Apr 2012 00:22:32 -0700 (PDT)
In-Reply-To: <CBAB3B56.3D923%keir@xen.org>
References: <CAP2B859XfBRU+APY_2M_-rDRaaarLw_BSKK3gDfbipeVAHzjtQ@mail.gmail.com>
	<CBAB3B56.3D923%keir@xen.org>
Date: Thu, 12 Apr 2012 16:22:32 +0900
Message-ID: <CAP2B859uCHxzk+CU7LY8T9cu0sZ27=H4s62gOWCs+boYbB1AdA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Keir Fraser <keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 9:44 PM, Keir Fraser <keir@xen.org> wrote:
> On 11/04/2012 13:24, "Daniel Castro" <evil.dani@gmail.com> wrote:
>
>>> It's looking likely that you'll have to go to 32 bit mode to do all of
>>> the actual I/O associated with the PV devices. That ought to simplify a
>>> bunch of stuff WRT handling the rings etc too.
>>
>> What are my choices?
>> 1. Add support for 16bit hypercalls on Xen.
>> 2. Jump to 32 bit
>
> I think this is best. Compile the 32-bit drivers as 32-bit code, then use
> stubs to transfer between 16-bit and 32-bit execution modes at run time. =
Our
> old rombios has code you could borrow for this, if seabios doesn't already
> have such functionality.

SeaBIOS allows me to call a function wrapped in 32 bit.
Also I found that I can not write the ring indexes in 16BIT mode
because the memory is marked read-only. So jumping to 32 bit is my
only option.

>
> =A0-- Keir
>
>> 3. make a 16bit "special" hypercall on SeaBIOS
>> 4. Any other choice?
>>
>> Thanks to all the comments.
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:23:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:23:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEMX-0002dv-Jg; Thu, 12 Apr 2012 07:22:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1SIEMV-0002dj-Iy
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:22:35 +0000
Received: from [193.109.254.147:41639] by server-5.bemta-14.messagelabs.com id
	0A/D2-30733-AB2868F4; Thu, 12 Apr 2012 07:22:34 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334215353!1754639!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23368 invoked from network); 12 Apr 2012 07:22:34 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:22:34 -0000
Received: by vcbfl15 with SMTP id fl15so1359227vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 00:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=rBWp7gRQnP3Xw48VibWQIry9VpkLh7WL9QDHL/i8+UA=;
	b=r95nEhPjx2KfZf2Qk9+qxbkj/35uAkxK0URe7NGi3CMdgQ9d2u5Y9fHUr4xtjTxY1x
	f+7Pc2fYsAhI3JgTBwcH0tdcYvYcB+X2g3D3bFY7OEKL+cifRfbS3vculkvFUNmV8zrG
	WCeFnAhHEBE7Eg1nQG7lBhcYLbJW3OkmsGXXJDaH4TROneisduKMjWa9ArQALEHUtWgr
	+RMIoj0oNAkRBSlX5uBr+qZGK0GsKzLV338aPFP0yIsVGU8xpYT4h0j4hMP4N4F8Lev1
	wRW8rPe8+yTNuKog15ze/Az8mlfYYdkh4Q81zeB+cPerOGyCqIGsY1NzXYvRb1Js6zvR
	x2Og==
MIME-Version: 1.0
Received: by 10.220.141.79 with SMTP id l15mr791571vcu.48.1334215352617; Thu,
	12 Apr 2012 00:22:32 -0700 (PDT)
Received: by 10.220.7.80 with HTTP; Thu, 12 Apr 2012 00:22:32 -0700 (PDT)
In-Reply-To: <CBAB3B56.3D923%keir@xen.org>
References: <CAP2B859XfBRU+APY_2M_-rDRaaarLw_BSKK3gDfbipeVAHzjtQ@mail.gmail.com>
	<CBAB3B56.3D923%keir@xen.org>
Date: Thu, 12 Apr 2012 16:22:32 +0900
Message-ID: <CAP2B859uCHxzk+CU7LY8T9cu0sZ27=H4s62gOWCs+boYbB1AdA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Keir Fraser <keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] hvm crash on hypercall event channel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 9:44 PM, Keir Fraser <keir@xen.org> wrote:
> On 11/04/2012 13:24, "Daniel Castro" <evil.dani@gmail.com> wrote:
>
>>> It's looking likely that you'll have to go to 32 bit mode to do all of
>>> the actual I/O associated with the PV devices. That ought to simplify a
>>> bunch of stuff WRT handling the rings etc too.
>>
>> What are my choices?
>> 1. Add support for 16bit hypercalls on Xen.
>> 2. Jump to 32 bit
>
> I think this is best. Compile the 32-bit drivers as 32-bit code, then use
> stubs to transfer between 16-bit and 32-bit execution modes at run time. =
Our
> old rombios has code you could borrow for this, if seabios doesn't already
> have such functionality.

SeaBIOS allows me to call a function wrapped in 32 bit.
Also I found that I can not write the ring indexes in 16BIT mode
because the memory is marked read-only. So jumping to 32 bit is my
only option.

>
> =A0-- Keir
>
>> 3. make a 16bit "special" hypercall on SeaBIOS
>> 4. Any other choice?
>>
>> Thanks to all the comments.
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEW3-0002sN-MJ; Thu, 12 Apr 2012 07:32:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SIEW2-0002sI-9I
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:32:26 +0000
Received: from [85.158.143.35:25421] by server-2.bemta-4.messagelabs.com id
	C9/4E-17550-905868F4; Thu, 12 Apr 2012 07:32:25 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334215944!8466588!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1742 invoked from network); 12 Apr 2012 07:32:24 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:32:24 -0000
Received: by wgbdr12 with SMTP id dr12so1385455wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 00:32:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9JesgUTCu0YKUK3ZdUhnodAYs/DcwRFxhg7C0Ieh0cs=;
	b=a+q09OiLnzv9GoDl8MPYqBqJpMRIoL+sZux4ggDRacB93qzw33/eN6qhGy/xUg3VCG
	1MttT2TqsdxTmbO61pM4GNbZu80cYV+aHmmUcAtuwUWHg+GC4W+nkmLNvsdy3OrINd8Y
	nfhWQrTfucT12A17jI0uPuS0fAT7wUrhTS+zAEHIJCERScaii8UmX0qH/NLVCn48mulv
	Wyggjpbbkw8VQ8kQT2SidUgR415iH9Hj8EqegV6j//rgOPiZBD6+9jp5BWyK/lhFPq3E
	PUs3AXpFHvTQfsfgvz66qO4doqiJoS7Lcf/a3Qxu/ODyMHYpugaurD7WL+ucdQNCcKjL
	VA2w==
MIME-Version: 1.0
Received: by 10.180.81.166 with SMTP id b6mr13288211wiy.0.1334215944534; Thu,
	12 Apr 2012 00:32:24 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Thu, 12 Apr 2012 00:32:24 -0700 (PDT)
In-Reply-To: <4F8672E3.80302@amd.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
Date: Thu, 12 Apr 2012 00:32:24 -0700
Message-ID: <CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: Wei Huang <wei.huang2@amd.com>
Cc: xen-devel@lists.xensource.com, Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 11:14 PM, Wei Huang <wei.huang2@amd.com> wrote:
> On 04/11/2012 06:04 PM, Gianluca Guida wrote:
>> As a major caveat, I haven't tested this patch on AMD, for lack of
>> hardware.
>
> I can test it on my AMD box tomorrow. BTW from my understanding, this patch
> doesn't have performance implication for nested paging mode, does it?

Thank you! A good but not perfect way is to check that xen-hvmctx
doesn't return on HAP the reset PAT table after a linux/windows guest
has been running. And that its value is actually preserved across
save/restore.

As for the performances in nested mode, as far as I could see, I think
not -- but I haven't looked at eventually hidden details of the nested
vm implementation.

Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEW3-0002sN-MJ; Thu, 12 Apr 2012 07:32:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SIEW2-0002sI-9I
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:32:26 +0000
Received: from [85.158.143.35:25421] by server-2.bemta-4.messagelabs.com id
	C9/4E-17550-905868F4; Thu, 12 Apr 2012 07:32:25 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334215944!8466588!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1742 invoked from network); 12 Apr 2012 07:32:24 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:32:24 -0000
Received: by wgbdr12 with SMTP id dr12so1385455wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 00:32:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9JesgUTCu0YKUK3ZdUhnodAYs/DcwRFxhg7C0Ieh0cs=;
	b=a+q09OiLnzv9GoDl8MPYqBqJpMRIoL+sZux4ggDRacB93qzw33/eN6qhGy/xUg3VCG
	1MttT2TqsdxTmbO61pM4GNbZu80cYV+aHmmUcAtuwUWHg+GC4W+nkmLNvsdy3OrINd8Y
	nfhWQrTfucT12A17jI0uPuS0fAT7wUrhTS+zAEHIJCERScaii8UmX0qH/NLVCn48mulv
	Wyggjpbbkw8VQ8kQT2SidUgR415iH9Hj8EqegV6j//rgOPiZBD6+9jp5BWyK/lhFPq3E
	PUs3AXpFHvTQfsfgvz66qO4doqiJoS7Lcf/a3Qxu/ODyMHYpugaurD7WL+ucdQNCcKjL
	VA2w==
MIME-Version: 1.0
Received: by 10.180.81.166 with SMTP id b6mr13288211wiy.0.1334215944534; Thu,
	12 Apr 2012 00:32:24 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Thu, 12 Apr 2012 00:32:24 -0700 (PDT)
In-Reply-To: <4F8672E3.80302@amd.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
Date: Thu, 12 Apr 2012 00:32:24 -0700
Message-ID: <CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: Wei Huang <wei.huang2@amd.com>
Cc: xen-devel@lists.xensource.com, Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 11:14 PM, Wei Huang <wei.huang2@amd.com> wrote:
> On 04/11/2012 06:04 PM, Gianluca Guida wrote:
>> As a major caveat, I haven't tested this patch on AMD, for lack of
>> hardware.
>
> I can test it on my AMD box tomorrow. BTW from my understanding, this patch
> doesn't have performance implication for nested paging mode, does it?

Thank you! A good but not perfect way is to check that xen-hvmctx
doesn't return on HAP the reset PAT table after a linux/windows guest
has been running. And that its value is actually preserved across
save/restore.

As for the performances in nested mode, as far as I could see, I think
not -- but I haven't looked at eventually hidden details of the nested
vm implementation.

Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:37:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEaY-00035B-3s; Thu, 12 Apr 2012 07:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIEaW-00034v-AH
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 07:37:04 +0000
Received: from [85.158.143.99:27179] by server-3.bemta-4.messagelabs.com id
	49/E9-05853-E16868F4; Thu, 12 Apr 2012 07:37:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334216221!13656091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15241 invoked from network); 12 Apr 2012 07:37:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:37:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11892460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:35:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:35:42 +0100
Message-ID: <1334216141.12209.236.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 07:35:41 +0000
In-Reply-To: <20357.44324.27939.514126@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:11 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> > Plan for a 4.2 release:
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> ...
> > tools, blockers:
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> I took a look at libxl.h and came up with the comments below.  Firstly
> general things I tripped over, and then the list of things which need
> converting to the new event system.

A slightly worrying list at this stage in the game.

> 
> Ian.
> 
> 
> Other:
> ======
> 
> ]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t memory_kb, int wait_secs);
> ]   /* wait for the memory target of a domain to be reached */
> ]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid, int wait_secs);
> 
> This whole memory interface is a bit of a dog's breakfast.

I think we can defer this to 4.3? The existing interface may be pants
but at least the name is pretty explicit that it will block. I think
this should then be easy enough to sort out in a backward compatible
manner in 4.3 since I expect the name of the function would change and
we could retain the old name in terms of the new for compat.

> ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> ]   int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type);
> ]   /* libxl_primary_console_exec finds the domid and console number
> ]    * corresponding to the primary console of the given vm, then calls
> ]    * libxl_console_exec with the right arguments (domid might be different
> ]    * if the guest is using stubdoms).
> ]    * This function can be called after creating the device model, in
> ]    * case of HVM guests, and before libxl_run_bootloader in case of PV
> ]    * guests using pygrub. */
> ]   int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
> 
> These functions should not exec things for you; they should tell you
> the parameters.  Any execing helpers should be in libxlu.

It's not enough for them to just use libxl__exec?

It'd be reasonably easy to make this return a libxl_string_list or
similar and to write a libxlu function which takes one of those.

> ]   /* common paths */
> ]   const char *libxl_sbindir_path(void);
> ]   const char *libxl_bindir_path(void);
> ]   const char *libxl_libexec_path(void);
> ]   const char *libxl_libdir_path(void);
> ]   const char *libxl_sharedir_path(void);
> ]   const char *libxl_private_bindir_path(void);
> ]   const char *libxl_xenfirmwaredir_path(void);
> ]   const char *libxl_xen_config_dir_path(void);
> ]   const char *libxl_xen_script_dir_path(void);
> ]   const char *libxl_lock_dir_path(void);
> ]   const char *libxl_run_dir_path(void);
> ]   const char *libxl_xenpaging_dir_path(void);
> 
> Surely these should be private ?

As far as I can grep, yes.

> Need to be ao/eventified:
> =========================
> 
> ]   typedef struct {
> ]   #define XL_SUSPEND_DEBUG 1
> ]   #define XL_SUSPEND_LIVE 2
> ]       int flags;
> ]       int (*suspend_callback)(void *, int);
> ]   } libxl_domain_suspend_info;
> ...
> ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> ]                            uint32_t domid, int fd);
> 
> ]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> ]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> ]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);

You are on the case with these?

> ]   int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> 
> Are these now merely initiations ?

I think so yes.

Does a non-transaction write make a function "slow"? That's all these
actually do. If they are currently "fast" then we could likely get away
with a dummy ao_how. (I think it is valid for a function which is "fast"
to take an ao_how and always run sync?)

> ]   int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
> 
> Might become long-running in the future.

But is currently fast? Dummy ao_how?

> ]   int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

Roger makes this async in his hotplug series.

> ]   /*
> ]    * Insert a CD-ROM device. A device corresponding to disk must already
> ]    * be attached to the guest.
> ]    */
> ]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

Were you looking at this one? I know you mentioned it at one point.

> ]   /*
> ]    * Make a disk available in this (the control) domain. Returns path to
> ]    * a device.
> ]    */
> ]   char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
> ]   int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
> 
> Does this even need to be public at this stage ?

I think Stefano internalises them in his qdisk/dom0-attach series.

> ]   /* Network Interfaces */
> ]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
> 
> ]   /* Keyboard */
> ]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
> 
> ]   /* Framebuffer */
> ]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);

These ought to be pretty trivial conversions?

> ]   /* PCI Passthrough */
> ]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
> ]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);

I'm less confident that this one will be trivial to make async :-(

> ]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
> ]
> ]   libxl_xen_console_reader *
> ]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
> ]   int libxl_xen_console_read_line(libxl_ctx *ctx,
> ]                                   libxl_xen_console_reader *cr,
> ]                                   char **line_r);
> ]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
> ]                                      libxl_xen_console_reader *cr);

This is basically "xl dmesg". I'm not sure what interface makes sense
here, really it is just dumping the current ring, so each call is
"fast".

I'm not sure there is a need for an event driven "new-line-in-log"
callback style thing, i.e. a need to implement a "tail -f" style thing. 
Firstly I'm not sure that Xen actually produces an event which would
allow this to be implemented without polling and secondly if you want
that you can configure xenconsoled to log the hypervisor output and then
tail the logfile.

Perhaps this interface is OK?

> ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long);
> ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> ]                      uint32_t set);
> ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char* uuid,
> ]                              int auth);
> ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> 
> Not sure about the tmem calls.

Me neither.

> And from libxl_utils.h:
> 
> ]   pid_t libxl_fork(libxl_ctx *ctx);
> 
> This function is going to have to go away.

Great.

Maybe things aren't as bad as I feared.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:37:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEaY-00035B-3s; Thu, 12 Apr 2012 07:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIEaW-00034v-AH
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 07:37:04 +0000
Received: from [85.158.143.99:27179] by server-3.bemta-4.messagelabs.com id
	49/E9-05853-E16868F4; Thu, 12 Apr 2012 07:37:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334216221!13656091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15241 invoked from network); 12 Apr 2012 07:37:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:37:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11892460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:35:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:35:42 +0100
Message-ID: <1334216141.12209.236.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 07:35:41 +0000
In-Reply-To: <20357.44324.27939.514126@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:11 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> > Plan for a 4.2 release:
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> ...
> > tools, blockers:
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> I took a look at libxl.h and came up with the comments below.  Firstly
> general things I tripped over, and then the list of things which need
> converting to the new event system.

A slightly worrying list at this stage in the game.

> 
> Ian.
> 
> 
> Other:
> ======
> 
> ]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t memory_kb, int wait_secs);
> ]   /* wait for the memory target of a domain to be reached */
> ]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid, int wait_secs);
> 
> This whole memory interface is a bit of a dog's breakfast.

I think we can defer this to 4.3? The existing interface may be pants
but at least the name is pretty explicit that it will block. I think
this should then be easy enough to sort out in a backward compatible
manner in 4.3 since I expect the name of the function would change and
we could retain the old name in terms of the new for compat.

> ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> ]   int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type);
> ]   /* libxl_primary_console_exec finds the domid and console number
> ]    * corresponding to the primary console of the given vm, then calls
> ]    * libxl_console_exec with the right arguments (domid might be different
> ]    * if the guest is using stubdoms).
> ]    * This function can be called after creating the device model, in
> ]    * case of HVM guests, and before libxl_run_bootloader in case of PV
> ]    * guests using pygrub. */
> ]   int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
> 
> These functions should not exec things for you; they should tell you
> the parameters.  Any execing helpers should be in libxlu.

It's not enough for them to just use libxl__exec?

It'd be reasonably easy to make this return a libxl_string_list or
similar and to write a libxlu function which takes one of those.

> ]   /* common paths */
> ]   const char *libxl_sbindir_path(void);
> ]   const char *libxl_bindir_path(void);
> ]   const char *libxl_libexec_path(void);
> ]   const char *libxl_libdir_path(void);
> ]   const char *libxl_sharedir_path(void);
> ]   const char *libxl_private_bindir_path(void);
> ]   const char *libxl_xenfirmwaredir_path(void);
> ]   const char *libxl_xen_config_dir_path(void);
> ]   const char *libxl_xen_script_dir_path(void);
> ]   const char *libxl_lock_dir_path(void);
> ]   const char *libxl_run_dir_path(void);
> ]   const char *libxl_xenpaging_dir_path(void);
> 
> Surely these should be private ?

As far as I can grep, yes.

> Need to be ao/eventified:
> =========================
> 
> ]   typedef struct {
> ]   #define XL_SUSPEND_DEBUG 1
> ]   #define XL_SUSPEND_LIVE 2
> ]       int flags;
> ]       int (*suspend_callback)(void *, int);
> ]   } libxl_domain_suspend_info;
> ...
> ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> ]                            uint32_t domid, int fd);
> 
> ]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> ]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> ]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);

You are on the case with these?

> ]   int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> 
> Are these now merely initiations ?

I think so yes.

Does a non-transaction write make a function "slow"? That's all these
actually do. If they are currently "fast" then we could likely get away
with a dummy ao_how. (I think it is valid for a function which is "fast"
to take an ao_how and always run sync?)

> ]   int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
> 
> Might become long-running in the future.

But is currently fast? Dummy ao_how?

> ]   int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

Roger makes this async in his hotplug series.

> ]   /*
> ]    * Insert a CD-ROM device. A device corresponding to disk must already
> ]    * be attached to the guest.
> ]    */
> ]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);

Were you looking at this one? I know you mentioned it at one point.

> ]   /*
> ]    * Make a disk available in this (the control) domain. Returns path to
> ]    * a device.
> ]    */
> ]   char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
> ]   int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
> 
> Does this even need to be public at this stage ?

I think Stefano internalises them in his qdisk/dom0-attach series.

> ]   /* Network Interfaces */
> ]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
> 
> ]   /* Keyboard */
> ]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
> 
> ]   /* Framebuffer */
> ]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);

These ought to be pretty trivial conversions?

> ]   /* PCI Passthrough */
> ]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
> ]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);

I'm less confident that this one will be trivial to make async :-(

> ]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
> ]
> ]   libxl_xen_console_reader *
> ]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
> ]   int libxl_xen_console_read_line(libxl_ctx *ctx,
> ]                                   libxl_xen_console_reader *cr,
> ]                                   char **line_r);
> ]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
> ]                                      libxl_xen_console_reader *cr);

This is basically "xl dmesg". I'm not sure what interface makes sense
here, really it is just dumping the current ring, so each call is
"fast".

I'm not sure there is a need for an event driven "new-line-in-log"
callback style thing, i.e. a need to implement a "tail -f" style thing. 
Firstly I'm not sure that Xen actually produces an event which would
allow this to be implemented without polling and secondly if you want
that you can configure xenconsoled to log the hypervisor output and then
tail the logfile.

Perhaps this interface is OK?

> ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long);
> ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> ]                      uint32_t set);
> ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char* uuid,
> ]                              int auth);
> ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> 
> Not sure about the tmem calls.

Me neither.

> And from libxl_utils.h:
> 
> ]   pid_t libxl_fork(libxl_ctx *ctx);
> 
> This function is going to have to go away.

Great.

Maybe things aren't as bad as I feared.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:42:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:42:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEfu-0003W7-QR; Thu, 12 Apr 2012 07:42:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIEfs-0003Vn-Ug
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 07:42:37 +0000
Received: from [85.158.143.99:41041] by server-1.bemta-4.messagelabs.com id
	AA/84-20925-C67868F4; Thu, 12 Apr 2012 07:42:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334216555!12102023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16821 invoked from network); 12 Apr 2012 07:42:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:42:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11892580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:42:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:42:35 +0100
Message-ID: <1334216554.12209.239.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 07:42:34 +0000
In-Reply-To: <20357.44475.632787.365339@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:13 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Xen 4.2 Release Plan / TODO"):
> > Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> > > Plan for a 4.2 release:
> > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> > ...
> > > tools, blockers:
> > >       * libxl stable API -- we would like 4.2 to define a stable API
> > >         which downstream's can start to rely on not changing. Aspects of
> > >         this are:
> > 
> > I took a look at libxl.h and came up with the comments below.  Firstly
> > general things I tripped over, and then the list of things which need
> > converting to the new event system.
> 
> And I should mention that in my event series I have two
> as-yet-unposted half-backed patches to rewrite libxl__spawn_* and
> libxl_domain_create_*.
> 
> It may be that we can add dummy ao_hows to these functions which might
> be good enough for now, although particularly for domain creation
> (which includes spawning) it might complicate the efforts of users to
> use the new API.

How close is your half baked series to do it properly?

> Currently any use of subprocesses inside libxl which is not dealt with
> by the new event machinery will experience problems if the event loop
> is also used, because the event loop will reap the children.

You've covered the bootloader one in existing patches and mentioned the
libxl_$CONSOLE_exec style ones in your last mail. The only other one is
the DM fork which is covered by your rewrite of libxl__spawn?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:42:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:42:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEfu-0003W7-QR; Thu, 12 Apr 2012 07:42:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIEfs-0003Vn-Ug
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 07:42:37 +0000
Received: from [85.158.143.99:41041] by server-1.bemta-4.messagelabs.com id
	AA/84-20925-C67868F4; Thu, 12 Apr 2012 07:42:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334216555!12102023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16821 invoked from network); 12 Apr 2012 07:42:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:42:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11892580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:42:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:42:35 +0100
Message-ID: <1334216554.12209.239.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 07:42:34 +0000
In-Reply-To: <20357.44475.632787.365339@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:13 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Xen 4.2 Release Plan / TODO"):
> > Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> > > Plan for a 4.2 release:
> > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> > ...
> > > tools, blockers:
> > >       * libxl stable API -- we would like 4.2 to define a stable API
> > >         which downstream's can start to rely on not changing. Aspects of
> > >         this are:
> > 
> > I took a look at libxl.h and came up with the comments below.  Firstly
> > general things I tripped over, and then the list of things which need
> > converting to the new event system.
> 
> And I should mention that in my event series I have two
> as-yet-unposted half-backed patches to rewrite libxl__spawn_* and
> libxl_domain_create_*.
> 
> It may be that we can add dummy ao_hows to these functions which might
> be good enough for now, although particularly for domain creation
> (which includes spawning) it might complicate the efforts of users to
> use the new API.

How close is your half baked series to do it properly?

> Currently any use of subprocesses inside libxl which is not dealt with
> by the new event machinery will experience problems if the event loop
> is also used, because the event loop will reap the children.

You've covered the bootloader one in existing patches and mentioned the
libxl_$CONSOLE_exec style ones in your last mail. The only other one is
the DM fork which is covered by your rewrite of libxl__spawn?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:59:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEwE-0004Bn-0v; Thu, 12 Apr 2012 07:59:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIEwC-0004Ba-7c
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 07:59:28 +0000
Received: from [85.158.138.51:60983] by server-10.bemta-3.messagelabs.com id
	76/8A-29478-F5B868F4; Thu, 12 Apr 2012 07:59:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334217565!19982739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5198 invoked from network); 12 Apr 2012 07:59:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:59:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11892997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:59:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:59:25 +0100
Message-ID: <1334217564.12209.250.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Dan Magenheimer
	<dan.magenheimer@oracle.com>
Date: Thu, 12 Apr 2012 07:59:24 +0000
In-Reply-To: <1334216141.12209.236.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> 
> > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> use_long);
> > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > ]                      uint32_t set);
> > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> uuid,
> > ]                              int auth);
> > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > 
> > Not sure about the tmem calls.
> 
> Me neither. 

Dan,

We want to declare the libxl 4.2 API as "stable" so we are trying to
determine whether any of these functions need to be made potentially
asynchronous or not, i.e. if they may be "slow" per the definition under
the comment "Machinery for asynchronous operations ("ao")" in
tools/libxl/libxl_internal.h, effectively if they may block for extended
periods.

If they were then we would possibly want to change the API to take an
"ao_how" as described under "Some libxl operations can take a long time"
in tools/libxl/libxl.h

If they are "fast" today but could potentially be slow in the future
then we may be able to make the trivial API change but keep the
synchronous implementation (depending on the specifics). It's quite late
in the day so if the functions are "slow" then this would be the
preferred option at this stage.

Otherwise the alternative is that we have to maintain these interfaces
going forward (for compat) and perhaps be forced introduce a new
parallel async interface in the future. Annoying but not the end of the
world.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 07:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 07:59:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEwE-0004Bn-0v; Thu, 12 Apr 2012 07:59:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIEwC-0004Ba-7c
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 07:59:28 +0000
Received: from [85.158.138.51:60983] by server-10.bemta-3.messagelabs.com id
	76/8A-29478-F5B868F4; Thu, 12 Apr 2012 07:59:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334217565!19982739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5198 invoked from network); 12 Apr 2012 07:59:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 07:59:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11892997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:59:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 08:59:25 +0100
Message-ID: <1334217564.12209.250.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Dan Magenheimer
	<dan.magenheimer@oracle.com>
Date: Thu, 12 Apr 2012 07:59:24 +0000
In-Reply-To: <1334216141.12209.236.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> 
> > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> use_long);
> > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > ]                      uint32_t set);
> > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> uuid,
> > ]                              int auth);
> > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > 
> > Not sure about the tmem calls.
> 
> Me neither. 

Dan,

We want to declare the libxl 4.2 API as "stable" so we are trying to
determine whether any of these functions need to be made potentially
asynchronous or not, i.e. if they may be "slow" per the definition under
the comment "Machinery for asynchronous operations ("ao")" in
tools/libxl/libxl_internal.h, effectively if they may block for extended
periods.

If they were then we would possibly want to change the API to take an
"ao_how" as described under "Some libxl operations can take a long time"
in tools/libxl/libxl.h

If they are "fast" today but could potentially be slow in the future
then we may be able to make the trivial API change but keep the
synchronous implementation (depending on the specifics). It's quite late
in the day so if the functions are "slow" then this would be the
preferred option at this stage.

Otherwise the alternative is that we have to maintain these interfaces
going forward (for compat) and perhaps be forced introduce a new
parallel async interface in the future. Annoying but not the end of the
world.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEyp-0004ow-7X; Thu, 12 Apr 2012 08:02:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIEyo-0004on-Lf
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:02:10 +0000
Received: from [193.109.254.147:39262] by server-12.bemta-14.messagelabs.com
	id 18/DF-05898-10C868F4; Thu, 12 Apr 2012 08:02:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334217728!4212151!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22428 invoked from network); 12 Apr 2012 08:02:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Apr 2012 08:02:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIEyk-0007ya-RM; Thu, 12 Apr 2012 08:02:06 +0000
Date: Thu, 12 Apr 2012 09:02:06 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Message-ID: <20120412080206.GA30588@ocelot.phlegethon.org>
References: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

At 11:25 +0100 on 05 Apr (1333625143), Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333621466 -3600
> # Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
> # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> tools/blktap2: fix 'make clean'
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r d690c7e896a2 -r 4b6bf18b6790 tools/blktap2/lvm/Makefile
> --- a/tools/blktap2/lvm/Makefile	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/blktap2/lvm/Makefile	Thu Apr 05 11:24:26 2012 +0100
> @@ -27,7 +27,7 @@ lvm-util: lvm-util.o
>  	$(CC) -DLVM_UTIL $(LDFLAGS) -o lvm-util lvm-util.c
>  
>  clean:
> -	rm -rf *.o *~ $(DEPS) $(IBIN)
> +	rm -rf *.o *.opic *~ $(DEPS) $(IBIN)
>  
>  .PHONY: all build clean install lvm-util
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEyp-0004ow-7X; Thu, 12 Apr 2012 08:02:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIEyo-0004on-Lf
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:02:10 +0000
Received: from [193.109.254.147:39262] by server-12.bemta-14.messagelabs.com
	id 18/DF-05898-10C868F4; Thu, 12 Apr 2012 08:02:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334217728!4212151!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22428 invoked from network); 12 Apr 2012 08:02:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Apr 2012 08:02:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIEyk-0007ya-RM; Thu, 12 Apr 2012 08:02:06 +0000
Date: Thu, 12 Apr 2012 09:02:06 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Message-ID: <20120412080206.GA30588@ocelot.phlegethon.org>
References: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

At 11:25 +0100 on 05 Apr (1333625143), Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1333621466 -3600
> # Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
> # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> tools/blktap2: fix 'make clean'
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r d690c7e896a2 -r 4b6bf18b6790 tools/blktap2/lvm/Makefile
> --- a/tools/blktap2/lvm/Makefile	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/blktap2/lvm/Makefile	Thu Apr 05 11:24:26 2012 +0100
> @@ -27,7 +27,7 @@ lvm-util: lvm-util.o
>  	$(CC) -DLVM_UTIL $(LDFLAGS) -o lvm-util lvm-util.c
>  
>  clean:
> -	rm -rf *.o *~ $(DEPS) $(IBIN)
> +	rm -rf *.o *.opic *~ $(DEPS) $(IBIN)
>  
>  .PHONY: all build clean install lvm-util
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:02:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEz6-0004qU-KF; Thu, 12 Apr 2012 08:02:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIEz5-0004qN-IE
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 08:02:27 +0000
Received: from [85.158.143.35:48401] by server-2.bemta-4.messagelabs.com id
	C3/6A-17550-21C868F4; Thu, 12 Apr 2012 08:02:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334217745!18242111!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 344 invoked from network); 12 Apr 2012 08:02:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Apr 2012 08:02:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIEz2-0007yv-Ax; Thu, 12 Apr 2012 08:02:24 +0000
Date: Thu, 12 Apr 2012 09:02:24 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120412080224.GB30588@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
	<20345.48953.952902.407000@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.48953.952902.407000@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 +0100 on 02 Apr (1333382473), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> > tools: Fix FPU save area definition in xen-hvmctx
> > 
> > Reported-by: Olaf Hering <olaf@aepfle.de>
> > Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Urgh.  This seems plausible.  (The repetition of the constant "16" is
> unfortunate but we don't have ARRAY_SIZE Here...)
> 
> I intend to apply Tim's patch unless anyone objects.

Ping?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:02:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIEz6-0004qU-KF; Thu, 12 Apr 2012 08:02:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIEz5-0004qN-IE
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 08:02:27 +0000
Received: from [85.158.143.35:48401] by server-2.bemta-4.messagelabs.com id
	C3/6A-17550-21C868F4; Thu, 12 Apr 2012 08:02:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334217745!18242111!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 344 invoked from network); 12 Apr 2012 08:02:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Apr 2012 08:02:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIEz2-0007yv-Ax; Thu, 12 Apr 2012 08:02:24 +0000
Date: Thu, 12 Apr 2012 09:02:24 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120412080224.GB30588@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
	<20345.48953.952902.407000@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20345.48953.952902.407000@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 +0100 on 02 Apr (1333382473), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> > tools: Fix FPU save area definition in xen-hvmctx
> > 
> > Reported-by: Olaf Hering <olaf@aepfle.de>
> > Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Urgh.  This seems plausible.  (The repetition of the constant "16" is
> unfortunate but we don't have ARRAY_SIZE Here...)
> 
> I intend to apply Tim's patch unless anyone objects.

Ping?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFAH-0005Kq-Sm; Thu, 12 Apr 2012 08:14:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SIFAG-0005Kl-8X
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:14:00 +0000
Received: from [85.158.143.99:16616] by server-2.bemta-4.messagelabs.com id
	9F/DC-17550-7CE868F4; Thu, 12 Apr 2012 08:13:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334218435!22763482!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28123 invoked from network); 12 Apr 2012 08:13:56 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:13:56 -0000
Received: by bkcjg9 with SMTP id jg9so1611677bkc.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 01:13:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=4OTNDgJa1FBw5fRfzp+3BlPfOY4qbWtdsL16vfpjZCs=;
	b=WxutYaAAdaaB1XurTlUMILCHXvbD7/ho0MP1TUse4TesNGXzwMG3LJQtZNsWd1Dnob
	EIpF1+r1AMGAtrftVTXHqhXojqmlX5AowBS3YYAsTAdVDaoo1tD3S9zCeow5G5QlP5jD
	uB2mkzwPBpvaOVl6DEVW4wYzKnJbIJhjBRzSHBqJhFI6re4mOEBW+r3AWthZQUtVuIbe
	cWTfQ6sEhZreHMC9YYuZ0zrymNrcBVhqqxMFW698eMmWThS/v3PPLbsq2xL5ig1uAee/
	eIDTwtjC5cqdKYLRlAy0w2LnIIM5Gmadq1lm88w44yN7Satdl5sNAF66y/sUk4aJFB0t
	HnPg==
Received: by 10.204.151.89 with SMTP id b25mr441676bkw.18.1334218435447;
	Thu, 12 Apr 2012 01:13:55 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id cy11sm9257050bkb.7.2012.04.12.01.13.53
	(version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 01:13:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Apr 2012 09:13:45 +0100
From: Keir Fraser <keir@xen.org>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <CBAC4D49.3D9AF%keir@xen.org>
Thread-Topic: [Xen-devel] Stable branch releases?
Thread-Index: Ac0YhC3+7cjFUQw73E+1oa3ovFQZAQ==
In-Reply-To: <4F860F8D.7090903@amd.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/2012 00:11, "Wei Huang" <wei.huang2@amd.com> wrote:

> On 04/11/2012 01:41 PM, Keir Fraser wrote:
>> On 11/04/2012 18:07, "Ian Campbell"<Ian.Campbell@citrix.com>  wrote:
>> 
>>> It seems like it has been quite a while since our last stable branch
>>> releases.
>>> 
>>> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
>>> deep into the 4.2 release closedown?
>>> 
>>> Perhaps we could do a first rc of each in the next few weeks?
>> Yes, it's about time.
> Before tagging 4.1.3, may I request the following changesets backported
> from xen-unstable? Will you consider them?

Done.

 -- Keir

> -Wei
> 
> ==== SVM Decode Assist ====
> changeset 23233:1276926e3795
> changeset 23234:bf7afd48339a
> changeset 23235:2c8ad607ece1
> changeset 23236:e324c4d1dd6e
> changeset 23237:381ab77db71a
> changeset 23238:60f5df2afcbb
> 
> ==== SVM TSC Scaling ====
> changeset 23437:d7c755c25bb9
> 
> ==== Performance Monitor Counters ====
> changeset 23304:8981b582be3e
> changeset 23305:014ee4e09644
> changeset 23306:e787d4f2e5ac
> 
> 
> 
>> 
>>   -- Keir
>> 
>>> Ian.
>>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFAH-0005Kq-Sm; Thu, 12 Apr 2012 08:14:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SIFAG-0005Kl-8X
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:14:00 +0000
Received: from [85.158.143.99:16616] by server-2.bemta-4.messagelabs.com id
	9F/DC-17550-7CE868F4; Thu, 12 Apr 2012 08:13:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334218435!22763482!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28123 invoked from network); 12 Apr 2012 08:13:56 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:13:56 -0000
Received: by bkcjg9 with SMTP id jg9so1611677bkc.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 01:13:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=4OTNDgJa1FBw5fRfzp+3BlPfOY4qbWtdsL16vfpjZCs=;
	b=WxutYaAAdaaB1XurTlUMILCHXvbD7/ho0MP1TUse4TesNGXzwMG3LJQtZNsWd1Dnob
	EIpF1+r1AMGAtrftVTXHqhXojqmlX5AowBS3YYAsTAdVDaoo1tD3S9zCeow5G5QlP5jD
	uB2mkzwPBpvaOVl6DEVW4wYzKnJbIJhjBRzSHBqJhFI6re4mOEBW+r3AWthZQUtVuIbe
	cWTfQ6sEhZreHMC9YYuZ0zrymNrcBVhqqxMFW698eMmWThS/v3PPLbsq2xL5ig1uAee/
	eIDTwtjC5cqdKYLRlAy0w2LnIIM5Gmadq1lm88w44yN7Satdl5sNAF66y/sUk4aJFB0t
	HnPg==
Received: by 10.204.151.89 with SMTP id b25mr441676bkw.18.1334218435447;
	Thu, 12 Apr 2012 01:13:55 -0700 (PDT)
Received: from [192.168.1.3] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id cy11sm9257050bkb.7.2012.04.12.01.13.53
	(version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 01:13:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Apr 2012 09:13:45 +0100
From: Keir Fraser <keir@xen.org>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <CBAC4D49.3D9AF%keir@xen.org>
Thread-Topic: [Xen-devel] Stable branch releases?
Thread-Index: Ac0YhC3+7cjFUQw73E+1oa3ovFQZAQ==
In-Reply-To: <4F860F8D.7090903@amd.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/2012 00:11, "Wei Huang" <wei.huang2@amd.com> wrote:

> On 04/11/2012 01:41 PM, Keir Fraser wrote:
>> On 11/04/2012 18:07, "Ian Campbell"<Ian.Campbell@citrix.com>  wrote:
>> 
>>> It seems like it has been quite a while since our last stable branch
>>> releases.
>>> 
>>> Shall we try and get 4.0.4 and 4.1.3 out of the way before we get too
>>> deep into the 4.2 release closedown?
>>> 
>>> Perhaps we could do a first rc of each in the next few weeks?
>> Yes, it's about time.
> Before tagging 4.1.3, may I request the following changesets backported
> from xen-unstable? Will you consider them?

Done.

 -- Keir

> -Wei
> 
> ==== SVM Decode Assist ====
> changeset 23233:1276926e3795
> changeset 23234:bf7afd48339a
> changeset 23235:2c8ad607ece1
> changeset 23236:e324c4d1dd6e
> changeset 23237:381ab77db71a
> changeset 23238:60f5df2afcbb
> 
> ==== SVM TSC Scaling ====
> changeset 23437:d7c755c25bb9
> 
> ==== Performance Monitor Counters ====
> changeset 23304:8981b582be3e
> changeset 23305:014ee4e09644
> changeset 23306:e787d4f2e5ac
> 
> 
> 
>> 
>>   -- Keir
>> 
>>> Ian.
>>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFBZ-0005P0-Bk; Thu, 12 Apr 2012 08:15:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIFBX-0005Oo-4q
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:15:19 +0000
Received: from [85.158.143.99:24617] by server-1.bemta-4.messagelabs.com id
	AC/77-20925-61F868F4; Thu, 12 Apr 2012 08:15:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334218511!12108567!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30965 invoked from network); 12 Apr 2012 08:15:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Apr 2012 08:15:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 17:04:53 +0100
Message-Id: <4F847642020000780007D13C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 17:04:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
In-Reply-To: <1334073008.9703.6.camel@hp6530s>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 17:50, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
>> >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
>> > This new physdev_op is added for Linux guest kernel to get the correct
>> > nr_irqs_gsi value.
>> 
>> I'm not convinced this is really needed - the kernel can work out the
>> right number without any hypercall afaict.
> 
> In Linux kernel:
> 
> mp_register_ioapic(...):
> 
>         entries = io_apic_get_redir_entries(idx);
>         gsi_cfg = mp_ioapic_gsi_routing(idx);
>         gsi_cfg->gsi_base = gsi_base;
>         gsi_cfg->gsi_end = gsi_base + entries - 1;
> 
>         /*
>          * The number of IO-APIC IRQ registers (== #pins):
>          */
>         ioapics[idx].nr_registers = entries;
> 
>         if (gsi_cfg->gsi_end >= gsi_top)
>                 gsi_top = gsi_cfg->gsi_end + 1;
> 
> io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> value(0xFFFFFFFF) on Xen Dom0 kernel.

I understand all of the above.

> How can we get the correct gsi_top value, which is used to set
> nr_irqs_gsi, without hypercall?
> 
> The problem here is we don't have a Xen version of io_apic_read in Linux
> kernel.

Meaning you need to craft one if you need one, the more that
struct io_apic_ops already exists. The traditional kernel was able
to do so quite fine, and hence didn't need any hypercall.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFBZ-0005P0-Bk; Thu, 12 Apr 2012 08:15:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIFBX-0005Oo-4q
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:15:19 +0000
Received: from [85.158.143.99:24617] by server-1.bemta-4.messagelabs.com id
	AC/77-20925-61F868F4; Thu, 12 Apr 2012 08:15:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334218511!12108567!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30965 invoked from network); 12 Apr 2012 08:15:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Apr 2012 08:15:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Apr 2012 17:04:53 +0100
Message-Id: <4F847642020000780007D13C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Apr 2012 17:04:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334070786.5865.133.camel@hp6530s>
	<4F846EE3020000780007D0F7@nat28.tlf.novell.com>
	<1334073008.9703.6.camel@hp6530s>
In-Reply-To: <1334073008.9703.6.camel@hp6530s>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] x86: Add a new physdev_op
 PHYSDEVOP_nr_irqs_gsi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.04.12 at 17:50, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> On Tue, 2012-04-10 at 16:33 +0100, Jan Beulich wrote:
>> >>> On 10.04.12 at 17:13, Lin Ming <mlin@ss.pku.edu.cn> wrote:
>> > This new physdev_op is added for Linux guest kernel to get the correct
>> > nr_irqs_gsi value.
>> 
>> I'm not convinced this is really needed - the kernel can work out the
>> right number without any hypercall afaict.
> 
> In Linux kernel:
> 
> mp_register_ioapic(...):
> 
>         entries = io_apic_get_redir_entries(idx);
>         gsi_cfg = mp_ioapic_gsi_routing(idx);
>         gsi_cfg->gsi_base = gsi_base;
>         gsi_cfg->gsi_end = gsi_base + entries - 1;
> 
>         /*
>          * The number of IO-APIC IRQ registers (== #pins):
>          */
>         ioapics[idx].nr_registers = entries;
> 
>         if (gsi_cfg->gsi_end >= gsi_top)
>                 gsi_top = gsi_cfg->gsi_end + 1;
> 
> io_apic_get_redir_entries calls io_apic_read(), which returns wrong
> value(0xFFFFFFFF) on Xen Dom0 kernel.

I understand all of the above.

> How can we get the correct gsi_top value, which is used to set
> nr_irqs_gsi, without hypercall?
> 
> The problem here is we don't have a Xen version of io_apic_read in Linux
> kernel.

Meaning you need to craft one if you need one, the more that
struct io_apic_ops already exists. The traditional kernel was able
to do so quite fine, and hence didn't need any hypercall.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFCK-0005UK-Pw; Thu, 12 Apr 2012 08:16:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIFCI-0005U4-U1
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:16:07 +0000
Received: from [85.158.143.35:29019] by server-1.bemta-4.messagelabs.com id
	90/09-20925-64F868F4; Thu, 12 Apr 2012 08:16:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334218565!18244411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11043 invoked from network); 12 Apr 2012 08:16:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:16:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11893490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 08:16:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 09:16:02 +0100
Message-ID: <1334218561.12209.253.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 08:16:01 +0000
In-Reply-To: <1334216141.12209.236.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> > ]   /* common paths */
> > ]   const char *libxl_sbindir_path(void);
> > ]   const char *libxl_bindir_path(void);
> > ]   const char *libxl_libexec_path(void);
> > ]   const char *libxl_libdir_path(void);
> > ]   const char *libxl_sharedir_path(void);
> > ]   const char *libxl_private_bindir_path(void);
> > ]   const char *libxl_xenfirmwaredir_path(void);
> > ]   const char *libxl_xen_config_dir_path(void);
> > ]   const char *libxl_xen_script_dir_path(void);
> > ]   const char *libxl_lock_dir_path(void);
> > ]   const char *libxl_run_dir_path(void);
> > ]   const char *libxl_xenpaging_dir_path(void);
> > 
> > Surely these should be private ?
> 
> As far as I can grep, yes. 

All but two it turns out. Not sure about those. The following patch
moves the rest.

libxl_lock_dir_path seems like it ought to be part of xl not libxl, or
at a stretch libxlu.

config_dir_path is only actually used by xl but an argument could be
made that it is more generally useful?

8<-----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334218378 -3600
# Node ID 14cac8170e122115ef090cb390775b8c356ae643
# Parent  86b4ff3e201dc81c76ac91f8a9f134669294b3ba
libxl: make most libxl_FOO_path() functions internal.

Only libxl_xen_config_dir_path and libxl_lock_dir_path are used outside the
library. Also bindir, sbindir, sharedir and xenpagingdir appeared to be
completely unused so nuke them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Apr 12 09:12:58 2012 +0100
@@ -1126,7 +1126,7 @@ out:
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
 {
     GC_INIT(ctx);
-    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
+    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
     char *domid_s = libxl__sprintf(gc, "%d", domid);
     char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
     char *cons_type_s;
@@ -1767,7 +1767,7 @@ int libxl__device_nic_setdefault(libxl__
         if (!nic->bridge) return ERROR_NOMEM;
     }
     if ( !nic->script && asprintf(&nic->script, "%s/vif-bridge",
-                                  libxl_xen_script_dir_path()) < 0 )
+                                  libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
         nic->nictype = LIBXL_NIC_TYPE_IOEMU;
@@ -1837,7 +1837,7 @@ int libxl_device_nic_add(libxl_ctx *ctx,
         flexarray_append(back, "script");
         flexarray_append(back, nic->script[0]=='/' ? nic->script
                          : libxl__sprintf(gc, "%s/%s",
-                                          libxl_xen_script_dir_path(),
+                                          libxl__xen_script_dir_path(),
                                           nic->script));
     }
 
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Apr 12 09:12:58 2012 +0100
@@ -787,18 +787,8 @@ int libxl_flask_setenforce(libxl_ctx *ct
 int libxl_flask_loadpolicy(libxl_ctx *ctx, void *policy, uint32_t size);
 
 /* common paths */
-const char *libxl_sbindir_path(void);
-const char *libxl_bindir_path(void);
-const char *libxl_libexec_path(void);
-const char *libxl_libdir_path(void);
-const char *libxl_sharedir_path(void);
-const char *libxl_private_bindir_path(void);
-const char *libxl_xenfirmwaredir_path(void);
 const char *libxl_xen_config_dir_path(void);
-const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
-const char *libxl_run_dir_path(void);
-const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
 
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Apr 12 09:12:58 2012 +0100
@@ -24,7 +24,7 @@ static const char *libxl_tapif_script(li
 #ifdef __linux__
     return libxl__strdup(gc, "no");
 #else
-    return libxl__sprintf(gc, "%s/qemu-ifup", libxl_xen_script_dir_path());
+    return libxl__sprintf(gc, "%s/qemu-ifup", libxl__xen_script_dir_path());
 #endif
 }
 
@@ -47,10 +47,10 @@ const char *libxl__domain_device_model(l
     } else {
         switch (info->device_model_version) {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
+            dm = libxl__abs_path(gc, "qemu-dm", libxl__libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__abs_path(gc, "qemu-system-i386", libxl_libexec_path());
+            dm = libxl__abs_path(gc, "qemu-system-i386", libxl__libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -337,7 +337,7 @@ static char ** libxl__build_device_model
     flexarray_append(dm_args,
                      libxl__sprintf(gc, "socket,id=libxl-cmd,"
                                     "path=%s/qmp-libxl-%d,server,nowait",
-                                    libxl_run_dir_path(), guest_domid));
+                                    libxl__run_dir_path(), guest_domid));
 
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
@@ -708,7 +708,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
+                                              libxl__xenfirmwaredir_path());
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Thu Apr 12 09:12:58 2012 +0100
@@ -349,7 +349,7 @@ static const char *libxl__domain_firmwar
             break;
         }
     }
-    return libxl__abs_path(gc, firmware, libxl_xenfirmwaredir_path());
+    return libxl__abs_path(gc, firmware, libxl__xenfirmwaredir_path());
 }
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Apr 12 09:12:58 2012 +0100
@@ -1374,6 +1374,14 @@ int libxl__carefd_close(libxl__carefd*);
 /* You may pass NULL in which case the answer is -1. */
 int libxl__carefd_fd(const libxl__carefd*);
 
+/* common paths */
+_hidden const char *libxl__libexec_path(void);
+_hidden const char *libxl__private_bindir_path(void);
+_hidden const char *libxl__xenfirmwaredir_path(void);
+_hidden const char *libxl__xen_config_dir_path(void);
+_hidden const char *libxl__xen_script_dir_path(void);
+_hidden const char *libxl__lock_dir_path(void);
+_hidden const char *libxl__run_dir_path(void);
 
 /*
  * Convenience macros.
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_paths.c
--- a/tools/libxl/libxl_paths.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_paths.c	Thu Apr 12 09:12:58 2012 +0100
@@ -15,37 +15,17 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
 
-const char *libxl_sbindir_path(void)
-{
-    return SBINDIR;
-}
-
-const char *libxl_bindir_path(void)
-{
-    return BINDIR;
-}
-
-const char *libxl_libexec_path(void)
+const char *libxl__libexec_path(void)
 {
     return LIBEXEC;
 }
 
-const char *libxl_libdir_path(void)
-{
-    return LIBDIR;
-}
-
-const char *libxl_sharedir_path(void)
-{
-    return SHAREDIR;
-}
-
-const char *libxl_private_bindir_path(void)
+const char *libxl__private_bindir_path(void)
 {
     return PRIVATE_BINDIR;
 }
 
-const char *libxl_xenfirmwaredir_path(void)
+const char *libxl__xenfirmwaredir_path(void)
 {
     return XENFIRMWAREDIR;
 }
@@ -55,7 +35,7 @@ const char *libxl_xen_config_dir_path(vo
     return XEN_CONFIG_DIR;
 }
 
-const char *libxl_xen_script_dir_path(void)
+const char *libxl__xen_script_dir_path(void)
 {
     return XEN_SCRIPT_DIR;
 }
@@ -65,16 +45,11 @@ const char *libxl_lock_dir_path(void)
     return XEN_LOCK_DIR;
 }
 
-const char *libxl_run_dir_path(void)
+const char *libxl__run_dir_path(void)
 {
     return XEN_RUN_DIR;
 }
 
-const char *libxl_xenpaging_dir_path(void)
-{
-    return XEN_PAGING_DIR;
-}
-
 /*
  * Local variables:
  * mode: C
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Thu Apr 12 09:12:58 2012 +0100
@@ -633,7 +633,7 @@ libxl__qmp_handler *libxl__qmp_initializ
     qmp = qmp_init_handler(gc, domid);
 
     qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
-                                libxl_run_dir_path(), domid);
+                                libxl__run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
         LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Connection error");
         qmp_free_handler(qmp);
@@ -671,7 +671,7 @@ void libxl__qmp_cleanup(libxl__gc *gc, u
     char *qmp_socket;
 
     qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
-                                libxl_run_dir_path(), domid);
+                                libxl__run_dir_path(), domid);
     if (unlink(qmp_socket) == -1) {
         if (errno != ENOENT) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFCK-0005UK-Pw; Thu, 12 Apr 2012 08:16:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIFCI-0005U4-U1
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:16:07 +0000
Received: from [85.158.143.35:29019] by server-1.bemta-4.messagelabs.com id
	90/09-20925-64F868F4; Thu, 12 Apr 2012 08:16:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334218565!18244411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11043 invoked from network); 12 Apr 2012 08:16:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:16:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11893490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 08:16:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 09:16:02 +0100
Message-ID: <1334218561.12209.253.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 08:16:01 +0000
In-Reply-To: <1334216141.12209.236.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> > ]   /* common paths */
> > ]   const char *libxl_sbindir_path(void);
> > ]   const char *libxl_bindir_path(void);
> > ]   const char *libxl_libexec_path(void);
> > ]   const char *libxl_libdir_path(void);
> > ]   const char *libxl_sharedir_path(void);
> > ]   const char *libxl_private_bindir_path(void);
> > ]   const char *libxl_xenfirmwaredir_path(void);
> > ]   const char *libxl_xen_config_dir_path(void);
> > ]   const char *libxl_xen_script_dir_path(void);
> > ]   const char *libxl_lock_dir_path(void);
> > ]   const char *libxl_run_dir_path(void);
> > ]   const char *libxl_xenpaging_dir_path(void);
> > 
> > Surely these should be private ?
> 
> As far as I can grep, yes. 

All but two it turns out. Not sure about those. The following patch
moves the rest.

libxl_lock_dir_path seems like it ought to be part of xl not libxl, or
at a stretch libxlu.

config_dir_path is only actually used by xl but an argument could be
made that it is more generally useful?

8<-----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334218378 -3600
# Node ID 14cac8170e122115ef090cb390775b8c356ae643
# Parent  86b4ff3e201dc81c76ac91f8a9f134669294b3ba
libxl: make most libxl_FOO_path() functions internal.

Only libxl_xen_config_dir_path and libxl_lock_dir_path are used outside the
library. Also bindir, sbindir, sharedir and xenpagingdir appeared to be
completely unused so nuke them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Apr 12 09:12:58 2012 +0100
@@ -1126,7 +1126,7 @@ out:
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
 {
     GC_INIT(ctx);
-    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
+    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
     char *domid_s = libxl__sprintf(gc, "%d", domid);
     char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
     char *cons_type_s;
@@ -1767,7 +1767,7 @@ int libxl__device_nic_setdefault(libxl__
         if (!nic->bridge) return ERROR_NOMEM;
     }
     if ( !nic->script && asprintf(&nic->script, "%s/vif-bridge",
-                                  libxl_xen_script_dir_path()) < 0 )
+                                  libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
         nic->nictype = LIBXL_NIC_TYPE_IOEMU;
@@ -1837,7 +1837,7 @@ int libxl_device_nic_add(libxl_ctx *ctx,
         flexarray_append(back, "script");
         flexarray_append(back, nic->script[0]=='/' ? nic->script
                          : libxl__sprintf(gc, "%s/%s",
-                                          libxl_xen_script_dir_path(),
+                                          libxl__xen_script_dir_path(),
                                           nic->script));
     }
 
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Apr 12 09:12:58 2012 +0100
@@ -787,18 +787,8 @@ int libxl_flask_setenforce(libxl_ctx *ct
 int libxl_flask_loadpolicy(libxl_ctx *ctx, void *policy, uint32_t size);
 
 /* common paths */
-const char *libxl_sbindir_path(void);
-const char *libxl_bindir_path(void);
-const char *libxl_libexec_path(void);
-const char *libxl_libdir_path(void);
-const char *libxl_sharedir_path(void);
-const char *libxl_private_bindir_path(void);
-const char *libxl_xenfirmwaredir_path(void);
 const char *libxl_xen_config_dir_path(void);
-const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
-const char *libxl_run_dir_path(void);
-const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
 
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Apr 12 09:12:58 2012 +0100
@@ -24,7 +24,7 @@ static const char *libxl_tapif_script(li
 #ifdef __linux__
     return libxl__strdup(gc, "no");
 #else
-    return libxl__sprintf(gc, "%s/qemu-ifup", libxl_xen_script_dir_path());
+    return libxl__sprintf(gc, "%s/qemu-ifup", libxl__xen_script_dir_path());
 #endif
 }
 
@@ -47,10 +47,10 @@ const char *libxl__domain_device_model(l
     } else {
         switch (info->device_model_version) {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
+            dm = libxl__abs_path(gc, "qemu-dm", libxl__libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__abs_path(gc, "qemu-system-i386", libxl_libexec_path());
+            dm = libxl__abs_path(gc, "qemu-system-i386", libxl__libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -337,7 +337,7 @@ static char ** libxl__build_device_model
     flexarray_append(dm_args,
                      libxl__sprintf(gc, "socket,id=libxl-cmd,"
                                     "path=%s/qmp-libxl-%d,server,nowait",
-                                    libxl_run_dir_path(), guest_domid));
+                                    libxl__run_dir_path(), guest_domid));
 
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
@@ -708,7 +708,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
+                                              libxl__xenfirmwaredir_path());
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Thu Apr 12 09:12:58 2012 +0100
@@ -349,7 +349,7 @@ static const char *libxl__domain_firmwar
             break;
         }
     }
-    return libxl__abs_path(gc, firmware, libxl_xenfirmwaredir_path());
+    return libxl__abs_path(gc, firmware, libxl__xenfirmwaredir_path());
 }
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Apr 12 09:12:58 2012 +0100
@@ -1374,6 +1374,14 @@ int libxl__carefd_close(libxl__carefd*);
 /* You may pass NULL in which case the answer is -1. */
 int libxl__carefd_fd(const libxl__carefd*);
 
+/* common paths */
+_hidden const char *libxl__libexec_path(void);
+_hidden const char *libxl__private_bindir_path(void);
+_hidden const char *libxl__xenfirmwaredir_path(void);
+_hidden const char *libxl__xen_config_dir_path(void);
+_hidden const char *libxl__xen_script_dir_path(void);
+_hidden const char *libxl__lock_dir_path(void);
+_hidden const char *libxl__run_dir_path(void);
 
 /*
  * Convenience macros.
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_paths.c
--- a/tools/libxl/libxl_paths.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_paths.c	Thu Apr 12 09:12:58 2012 +0100
@@ -15,37 +15,17 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
 
-const char *libxl_sbindir_path(void)
-{
-    return SBINDIR;
-}
-
-const char *libxl_bindir_path(void)
-{
-    return BINDIR;
-}
-
-const char *libxl_libexec_path(void)
+const char *libxl__libexec_path(void)
 {
     return LIBEXEC;
 }
 
-const char *libxl_libdir_path(void)
-{
-    return LIBDIR;
-}
-
-const char *libxl_sharedir_path(void)
-{
-    return SHAREDIR;
-}
-
-const char *libxl_private_bindir_path(void)
+const char *libxl__private_bindir_path(void)
 {
     return PRIVATE_BINDIR;
 }
 
-const char *libxl_xenfirmwaredir_path(void)
+const char *libxl__xenfirmwaredir_path(void)
 {
     return XENFIRMWAREDIR;
 }
@@ -55,7 +35,7 @@ const char *libxl_xen_config_dir_path(vo
     return XEN_CONFIG_DIR;
 }
 
-const char *libxl_xen_script_dir_path(void)
+const char *libxl__xen_script_dir_path(void)
 {
     return XEN_SCRIPT_DIR;
 }
@@ -65,16 +45,11 @@ const char *libxl_lock_dir_path(void)
     return XEN_LOCK_DIR;
 }
 
-const char *libxl_run_dir_path(void)
+const char *libxl__run_dir_path(void)
 {
     return XEN_RUN_DIR;
 }
 
-const char *libxl_xenpaging_dir_path(void)
-{
-    return XEN_PAGING_DIR;
-}
-
 /*
  * Local variables:
  * mode: C
diff -r 86b4ff3e201d -r 14cac8170e12 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Thu Apr 12 09:02:05 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Thu Apr 12 09:12:58 2012 +0100
@@ -633,7 +633,7 @@ libxl__qmp_handler *libxl__qmp_initializ
     qmp = qmp_init_handler(gc, domid);
 
     qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
-                                libxl_run_dir_path(), domid);
+                                libxl__run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
         LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Connection error");
         qmp_free_handler(qmp);
@@ -671,7 +671,7 @@ void libxl__qmp_cleanup(libxl__gc *gc, u
     char *qmp_socket;
 
     qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
-                                libxl_run_dir_path(), domid);
+                                libxl__run_dir_path(), domid);
     if (unlink(qmp_socket) == -1) {
         if (errno != ENOENT) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:30:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFQ6-0006h5-5n; Thu, 12 Apr 2012 08:30:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIFQ4-0006gs-Tu
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:30:21 +0000
Received: from [85.158.138.51:51106] by server-12.bemta-3.messagelabs.com id
	0B/ED-29760-A92968F4; Thu, 12 Apr 2012 08:30:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334219416!19988526!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMwODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15812 invoked from network); 12 Apr 2012 08:30:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="189989775"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 04:30:15 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 04:30:15 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SIFPy-0006hG-Qd;
	Thu, 12 Apr 2012 09:30:14 +0100
MIME-Version: 1.0
X-Mercurial-Node: ce1c73db77fb1264de40a9253371158e9c9ae71c
Message-ID: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 12 Apr 2012 09:30:14 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334219369 -3600
# Node ID ce1c73db77fb1264de40a9253371158e9c9ae71c
# Parent  14cac8170e122115ef090cb390775b8c356ae643
libxl: mark internal functions hidden

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/gentypes.py	Thu Apr 12 09:29:29 2012 +0100
@@ -280,22 +280,22 @@ if __name__ == '__main__':
     for ty in types:
         f.write(libxl_C_type_define(ty) + ";\n")
         if ty.dispose_fn is not None:
-            f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
+            f.write("%svoid %s(%s);\n" % (ty.hidden(), ty.dispose_fn, ty.make_arg("p")))
         if ty.init_fn is not None:
-            f.write("void %s(%s);\n" % (ty.init_fn, ty.make_arg("p")))
+            f.write("%svoid %s(%s);\n" % (ty.hidden(), ty.init_fn, ty.make_arg("p")))
             for field in libxl_init_members(ty):
                 if not isinstance(field.type, idl.KeyedUnion):
                     raise Exception("Only KeyedUnion is supported for member init")
                 ku = field.type
-                f.write("void %s(%s, %s);\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                f.write("%svoid %s(%s, %s);\n" % (ty.hidden(), ty.init_fn + "_" + ku.keyvar.name,
                                                ty.make_arg("p"),
                                                ku.keyvar.type.make_arg(ku.keyvar.name)))
         if ty.json_fn is not None:
-            f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
+            f.write("%schar *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p")))
         if isinstance(ty, idl.Enumeration):
-            f.write("const char *%s_to_string(%s);\n" % (ty.typename, ty.make_arg("p")))
-            f.write("int %s_from_string(const char *s, %s);\n" % (ty.typename, ty.make_arg("e", passby=idl.PASS_BY_REFERENCE)))
-            f.write("extern libxl_enum_string_table %s_string_table[];\n" % (ty.typename))
+            f.write("%sconst char *%s_to_string(%s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p")))
+            f.write("%sint %s_from_string(const char *s, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("e", passby=idl.PASS_BY_REFERENCE)))
+            f.write("%sextern libxl_enum_string_table %s_string_table[];\n" % (ty.hidden(), ty.typename))
         f.write("\n")
 
     f.write("""#endif /* %s */\n""" % (header_define))
@@ -319,7 +319,7 @@ if __name__ == '__main__':
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
     for ty in [ty for ty in types if ty.json_fn is not None]:
-        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
+        f.write("%syajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
     f.write("""#endif /* %s */\n""" % header_json_define)
diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/idl.py
--- a/tools/libxl/idl.py	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/idl.py	Thu Apr 12 09:29:29 2012 +0100
@@ -19,11 +19,20 @@ def _get_default_namespace():
     global _default_namespace
     return _default_namespace
 
+_default_hidden = False
+def hidden(b):
+    global _default_hidden
+    _default_hidden = b
+
+def _get_default_hidden():
+    global _default_hidden
+    return _default_hidden
 
 class Type(object):
     def __init__(self, typename, **kwargs):
         self.namespace = kwargs.setdefault('namespace',
                 _get_default_namespace())
+        self._hidden = kwargs.setdefault('hidden', _get_default_hidden())
         self.dir = kwargs.setdefault('dir', DIR_BOTH)
         if self.dir not in [DIR_NONE, DIR_IN, DIR_OUT, DIR_BOTH]:
             raise ValueError
@@ -67,6 +76,12 @@ class Type(object):
     def marshal_out(self):
         return self.dir in [DIR_OUT, DIR_BOTH]
 
+    def hidden(self):
+        if self._hidden:
+            return "_hidden "
+        else:
+            return ""
+
     def make_arg(self, n, passby=None):
         if passby is None: passby = self.passby
 
@@ -289,7 +304,7 @@ def parse(f):
             globs[n] = t
         elif n in ['PASS_BY_REFERENCE', 'PASS_BY_VALUE',
                    'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH',
-                   'namespace']:
+                   'namespace', 'hidden']:
             globs[n] = t
 
     try:
diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Apr 12 09:29:29 2012 +0100
@@ -118,7 +118,7 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
-void libxl__alloc_failed(libxl_ctx *, const char *func,
+_hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
   /* func, size and nmemb are used only in the log message.
    * You may pass size==0 if size and nmemb are not meaningful
@@ -184,7 +184,8 @@ typedef struct libxl__ev_watch_slot {
     LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
 } libxl__ev_watch_slot;
     
-libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+_hidden libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc,
+                                                      int slotnum);
 
 
 /*
@@ -597,21 +598,21 @@ _hidden void libxl__event_disaster(libxl
 
 /* Fills in, or disposes of, the resources held by, a poller whose
  * space the caller has allocated.  ctx must be locked. */
-int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
-void libxl__poller_dispose(libxl__poller *p);
+_hidden int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+_hidden void libxl__poller_dispose(libxl__poller *p);
 
 /* Obtain a fresh poller from malloc or the idle list, and put it
  * away again afterwards.  _get can fail, returning NULL.
  * ctx must be locked. */
-libxl__poller *libxl__poller_get(libxl_ctx *ctx);
-void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+_hidden libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+_hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 
 /* Notifies whoever is polling using p that they should wake up.
  * ctx must be locked. */
-void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+_hidden void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
-int libxl__atfork_init(libxl_ctx *ctx);
+_hidden int libxl__atfork_init(libxl_ctx *ctx);
 
 
 /* from xl_dom */
@@ -1356,23 +1357,23 @@ _hidden void libxl__ao__destroy(libxl_ct
  */
 typedef struct libxl__carefd libxl__carefd;
 
-void libxl__carefd_begin(void);
-void libxl__carefd_unlock(void);
+_hidden void libxl__carefd_begin(void);
+_hidden void libxl__carefd_unlock(void);
 
 /* fd may be -1, in which case this returns a dummy libxl__fd_record
  * on which it _carefd_close is a no-op.  Cannot fail. */
-libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+_hidden libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
 
 /* Combines _record and _unlock in a single call.  If fd==-1,
  * still does the unlock, but returns 0.  Cannot fail. */
-libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+_hidden libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
 
 /* Works just like close(2).  You may pass NULL, in which case it's
  * a successful no-op. */
-int libxl__carefd_close(libxl__carefd*);
+_hidden int libxl__carefd_close(libxl__carefd*);
 
 /* You may pass NULL in which case the answer is -1. */
-int libxl__carefd_fd(const libxl__carefd*);
+_hidden int libxl__carefd_fd(const libxl__carefd*);
 
 /* common paths */
 _hidden const char *libxl__libexec_path(void);
diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/libxl_types_internal.idl	Thu Apr 12 09:29:29 2012 +0100
@@ -1,4 +1,5 @@
 namespace("libxl__")
+hidden(True)
 
 libxl_domid = Builtin("domid", namespace="libxl_", json_fn = "yajl_gen_integer")
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:30:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFQ6-0006h5-5n; Thu, 12 Apr 2012 08:30:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIFQ4-0006gs-Tu
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:30:21 +0000
Received: from [85.158.138.51:51106] by server-12.bemta-3.messagelabs.com id
	0B/ED-29760-A92968F4; Thu, 12 Apr 2012 08:30:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334219416!19988526!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMwODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15812 invoked from network); 12 Apr 2012 08:30:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="189989775"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 04:30:15 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 04:30:15 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SIFPy-0006hG-Qd;
	Thu, 12 Apr 2012 09:30:14 +0100
MIME-Version: 1.0
X-Mercurial-Node: ce1c73db77fb1264de40a9253371158e9c9ae71c
Message-ID: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 12 Apr 2012 09:30:14 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334219369 -3600
# Node ID ce1c73db77fb1264de40a9253371158e9c9ae71c
# Parent  14cac8170e122115ef090cb390775b8c356ae643
libxl: mark internal functions hidden

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/gentypes.py	Thu Apr 12 09:29:29 2012 +0100
@@ -280,22 +280,22 @@ if __name__ == '__main__':
     for ty in types:
         f.write(libxl_C_type_define(ty) + ";\n")
         if ty.dispose_fn is not None:
-            f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
+            f.write("%svoid %s(%s);\n" % (ty.hidden(), ty.dispose_fn, ty.make_arg("p")))
         if ty.init_fn is not None:
-            f.write("void %s(%s);\n" % (ty.init_fn, ty.make_arg("p")))
+            f.write("%svoid %s(%s);\n" % (ty.hidden(), ty.init_fn, ty.make_arg("p")))
             for field in libxl_init_members(ty):
                 if not isinstance(field.type, idl.KeyedUnion):
                     raise Exception("Only KeyedUnion is supported for member init")
                 ku = field.type
-                f.write("void %s(%s, %s);\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                f.write("%svoid %s(%s, %s);\n" % (ty.hidden(), ty.init_fn + "_" + ku.keyvar.name,
                                                ty.make_arg("p"),
                                                ku.keyvar.type.make_arg(ku.keyvar.name)))
         if ty.json_fn is not None:
-            f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
+            f.write("%schar *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p")))
         if isinstance(ty, idl.Enumeration):
-            f.write("const char *%s_to_string(%s);\n" % (ty.typename, ty.make_arg("p")))
-            f.write("int %s_from_string(const char *s, %s);\n" % (ty.typename, ty.make_arg("e", passby=idl.PASS_BY_REFERENCE)))
-            f.write("extern libxl_enum_string_table %s_string_table[];\n" % (ty.typename))
+            f.write("%sconst char *%s_to_string(%s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p")))
+            f.write("%sint %s_from_string(const char *s, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("e", passby=idl.PASS_BY_REFERENCE)))
+            f.write("%sextern libxl_enum_string_table %s_string_table[];\n" % (ty.hidden(), ty.typename))
         f.write("\n")
 
     f.write("""#endif /* %s */\n""" % (header_define))
@@ -319,7 +319,7 @@ if __name__ == '__main__':
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
     for ty in [ty for ty in types if ty.json_fn is not None]:
-        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
+        f.write("%syajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
     f.write("""#endif /* %s */\n""" % header_json_define)
diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/idl.py
--- a/tools/libxl/idl.py	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/idl.py	Thu Apr 12 09:29:29 2012 +0100
@@ -19,11 +19,20 @@ def _get_default_namespace():
     global _default_namespace
     return _default_namespace
 
+_default_hidden = False
+def hidden(b):
+    global _default_hidden
+    _default_hidden = b
+
+def _get_default_hidden():
+    global _default_hidden
+    return _default_hidden
 
 class Type(object):
     def __init__(self, typename, **kwargs):
         self.namespace = kwargs.setdefault('namespace',
                 _get_default_namespace())
+        self._hidden = kwargs.setdefault('hidden', _get_default_hidden())
         self.dir = kwargs.setdefault('dir', DIR_BOTH)
         if self.dir not in [DIR_NONE, DIR_IN, DIR_OUT, DIR_BOTH]:
             raise ValueError
@@ -67,6 +76,12 @@ class Type(object):
     def marshal_out(self):
         return self.dir in [DIR_OUT, DIR_BOTH]
 
+    def hidden(self):
+        if self._hidden:
+            return "_hidden "
+        else:
+            return ""
+
     def make_arg(self, n, passby=None):
         if passby is None: passby = self.passby
 
@@ -289,7 +304,7 @@ def parse(f):
             globs[n] = t
         elif n in ['PASS_BY_REFERENCE', 'PASS_BY_VALUE',
                    'DIR_NONE', 'DIR_IN', 'DIR_OUT', 'DIR_BOTH',
-                   'namespace']:
+                   'namespace', 'hidden']:
             globs[n] = t
 
     try:
diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Apr 12 09:29:29 2012 +0100
@@ -118,7 +118,7 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
-void libxl__alloc_failed(libxl_ctx *, const char *func,
+_hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
   /* func, size and nmemb are used only in the log message.
    * You may pass size==0 if size and nmemb are not meaningful
@@ -184,7 +184,8 @@ typedef struct libxl__ev_watch_slot {
     LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
 } libxl__ev_watch_slot;
     
-libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+_hidden libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc,
+                                                      int slotnum);
 
 
 /*
@@ -597,21 +598,21 @@ _hidden void libxl__event_disaster(libxl
 
 /* Fills in, or disposes of, the resources held by, a poller whose
  * space the caller has allocated.  ctx must be locked. */
-int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
-void libxl__poller_dispose(libxl__poller *p);
+_hidden int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+_hidden void libxl__poller_dispose(libxl__poller *p);
 
 /* Obtain a fresh poller from malloc or the idle list, and put it
  * away again afterwards.  _get can fail, returning NULL.
  * ctx must be locked. */
-libxl__poller *libxl__poller_get(libxl_ctx *ctx);
-void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+_hidden libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+_hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 
 /* Notifies whoever is polling using p that they should wake up.
  * ctx must be locked. */
-void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+_hidden void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
-int libxl__atfork_init(libxl_ctx *ctx);
+_hidden int libxl__atfork_init(libxl_ctx *ctx);
 
 
 /* from xl_dom */
@@ -1356,23 +1357,23 @@ _hidden void libxl__ao__destroy(libxl_ct
  */
 typedef struct libxl__carefd libxl__carefd;
 
-void libxl__carefd_begin(void);
-void libxl__carefd_unlock(void);
+_hidden void libxl__carefd_begin(void);
+_hidden void libxl__carefd_unlock(void);
 
 /* fd may be -1, in which case this returns a dummy libxl__fd_record
  * on which it _carefd_close is a no-op.  Cannot fail. */
-libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+_hidden libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
 
 /* Combines _record and _unlock in a single call.  If fd==-1,
  * still does the unlock, but returns 0.  Cannot fail. */
-libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+_hidden libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
 
 /* Works just like close(2).  You may pass NULL, in which case it's
  * a successful no-op. */
-int libxl__carefd_close(libxl__carefd*);
+_hidden int libxl__carefd_close(libxl__carefd*);
 
 /* You may pass NULL in which case the answer is -1. */
-int libxl__carefd_fd(const libxl__carefd*);
+_hidden int libxl__carefd_fd(const libxl__carefd*);
 
 /* common paths */
 _hidden const char *libxl__libexec_path(void);
diff -r 14cac8170e12 -r ce1c73db77fb tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Thu Apr 12 09:12:58 2012 +0100
+++ b/tools/libxl/libxl_types_internal.idl	Thu Apr 12 09:29:29 2012 +0100
@@ -1,4 +1,5 @@
 namespace("libxl__")
+hidden(True)
 
 libxl_domid = Builtin("domid", namespace="libxl_", json_fn = "yajl_gen_integer")
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:36:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFVy-0006xH-1y; Thu, 12 Apr 2012 08:36:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIFVw-0006x9-7F
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:36:24 +0000
Received: from [85.158.143.99:55343] by server-1.bemta-4.messagelabs.com id
	77/1B-20925-704968F4; Thu, 12 Apr 2012 08:36:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334219782!16939201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15525 invoked from network); 12 Apr 2012 08:36:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:36:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11894008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 08:36:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 09:36:22 +0100
Message-ID: <1334219781.12209.256.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 12 Apr 2012 08:36:21 +0000
In-Reply-To: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
References: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 09:30 +0100, Ian Campbell wrote:
> @@ -597,21 +598,21 @@ _hidden void libxl__event_disaster(libxl
>  
>  /* Fills in, or disposes of, the resources held by, a poller whose
>   * space the caller has allocated.  ctx must be locked. */
> -int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
> -void libxl__poller_dispose(libxl__poller *p);
> +_hidden int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
> +_hidden void libxl__poller_dispose(libxl__poller *p);

BTW, I noticed a bunch of libxl__ functions which take a ctx instead of
a gc while doing this.

$ grep libxl_ctx tools/libxl/libxl_internal.h
_hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
_hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
_hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
[...]
_hidden int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
_hidden libxl__poller *libxl__poller_get(libxl_ctx *ctx);
_hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
_hidden int libxl__atfork_init(libxl_ctx *ctx);
_hidden char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
[...]
_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
_hidden libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
_hidden libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
static inline void libxl__ctx_lock(libxl_ctx *ctx) {
static inline void libxl__ctx_unlock(libxl_ctx *ctx) {

libxl__log*, libxl__alloc_failed and libxl__ctx_{un}lock are probably
fine, libxl__object_to_json probably is too, but the others ought to
take a gc? Something to be left for 4.3 IMHO but I thought I'd mention
it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 08:36:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 08:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIFVy-0006xH-1y; Thu, 12 Apr 2012 08:36:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIFVw-0006x9-7F
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 08:36:24 +0000
Received: from [85.158.143.99:55343] by server-1.bemta-4.messagelabs.com id
	77/1B-20925-704968F4; Thu, 12 Apr 2012 08:36:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334219782!16939201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzgzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15525 invoked from network); 12 Apr 2012 08:36:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 08:36:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11894008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 08:36:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 09:36:22 +0100
Message-ID: <1334219781.12209.256.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 12 Apr 2012 08:36:21 +0000
In-Reply-To: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
References: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 09:30 +0100, Ian Campbell wrote:
> @@ -597,21 +598,21 @@ _hidden void libxl__event_disaster(libxl
>  
>  /* Fills in, or disposes of, the resources held by, a poller whose
>   * space the caller has allocated.  ctx must be locked. */
> -int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
> -void libxl__poller_dispose(libxl__poller *p);
> +_hidden int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
> +_hidden void libxl__poller_dispose(libxl__poller *p);

BTW, I noticed a bunch of libxl__ functions which take a ctx instead of
a gc while doing this.

$ grep libxl_ctx tools/libxl/libxl_internal.h
_hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
_hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
_hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
[...]
_hidden int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
_hidden libxl__poller *libxl__poller_get(libxl_ctx *ctx);
_hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
_hidden int libxl__atfork_init(libxl_ctx *ctx);
_hidden char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
[...]
_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
_hidden libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
_hidden libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
static inline void libxl__ctx_lock(libxl_ctx *ctx) {
static inline void libxl__ctx_unlock(libxl_ctx *ctx) {

libxl__log*, libxl__alloc_failed and libxl__ctx_{un}lock are probably
fine, libxl__object_to_json probably is too, but the others ought to
take a gc? Something to be left for 4.3 IMHO but I thought I'd mention
it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:12:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIG4B-0007T7-Ml; Thu, 12 Apr 2012 09:11:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIG4A-0007Sv-NE
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 09:11:47 +0000
Received: from [85.158.139.83:7984] by server-12.bemta-5.messagelabs.com id
	84/8E-05587-15C968F4; Thu, 12 Apr 2012 09:11:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334221904!22941181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27897 invoked from network); 12 Apr 2012 09:11:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11895009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 09:11:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 10:11:44 +0100
Message-ID: <1334221902.16387.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Apr 2012 10:11:42 +0100
In-Reply-To: <ec0abe6e2de3d35d626a.1334150277@Solace>
References: <patchbomb.1334150267@Solace>
	<ec0abe6e2de3d35d626a.1334150277@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10 [RFC]] xl: Some automatic NUMA
 placement documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 14:17 +0100, Dario Faggioli wrote:
> Add some rationale and usage documentation for the new automatic
> NUMA placement feature of xl.
> 
> TODO: * Decide whether we want to have things like "Future Steps/Roadmap"
>         and/or "Performances/Benchmarks Results" here as well.

I think these would be better in the list archives and on the wiki
respectively.

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff --git a/docs/misc/xl-numa-placement.txt b/docs/misc/xl-numa-placement.txt
> new file mode 100644
> --- /dev/null
> +++ b/docs/misc/xl-numa-placement.txt

It looks like you are using something approximating markdown syntax
here, so you might as well name this xl-numa-placement.markdown and get
a .html version etc almost for free.

> @@ -0,0 +1,205 @@
> +               -------------------------------------
> +               NUMA Guest Placement Design and Usage
> +               -------------------------------------
> +
> +Xen deals with Non-Uniform Memory Access (NUMA) machines in many ways. For
> +example each domain has its own "node affinity", i.e., a set of NUMA nodes
> +of the host from which memory for that domain is allocated. That becomes
> +very important as soon as many domains start running memory-intensive
> +workloads on a shared host. In fact, accessing non node-local memory
> +locations costs much more than node-local ones, to the point that the
> +degradation in performance is likely to be noticeable.
> +
> +It is then quite obvious that, any mechanism that enable the most of the
> +memory accesses for the most of the most of the guest domains to stay
> +local is something very important to achieve when dealing with NUMA
> +platforms.
> +
> +
> +Node Affinity and CPU Affinity
> +------------------------------
> +
> +There is another very popular 'affinity', besides node affinity we are
> +discussing here, which is '(v)cpu affinity'. Moreover, to make things
> +even worse, the two are different but somehow related things. In fact,
> +in both Xen and Linux worlds, 'cpu affinity' is the set of CPUs a domain
> +(that would be a task, when talking about Linux) can be scheduled on.
> +This seems to have few to do with memory accesses, but it does, as the

                      ^little

> +CPU where a domain run is also from where it tries to access its memory,
> +i.e., that is one half of what decides whether a memory access is remote
> +or local --- the other half being where the location it wants to access
> +is stored.
> +
> +Of course, if a domain is known to only run on a subset of the physical
> +CPUs of the host, it is very easy to turn all its memory accesses into
> +local ones, by just constructing it's node affinity (in Xen) basing on

                                                                ^based

> +what nodes these CPUs belongs to. Actually, that is exactly what is being
> +done by the hypervisor by default, as soon as it finds out a domain (or
> +better, the vcpus of a domain, but let's avoid getting into too much
> +details here) has a cpu affinity.
> +
> +This is working quite well, but it requires the user/system administrator
> +to explicitly specify such property --- the cpu affinity --- while the
> +domain is being created, or Xen won't be able to exploit that for ensuring
> +accesses locality.
> +
> +On the other hand, as node affinity directly affects where domain's memory
> +lives, it makes a lot of sense for it to be involved in scheduling decisions,
> +as it would be great if the hypervisor would manage in scheduling all the
> +vcpus of all the domains on CPUs attached to the various domains' local
> +memory. That is why, the node affinity of a domain is treated by the scheduler
> +as the set of nodes on which it would be preferable to run it, although
> +not at the cost of violating the scheduling algorithm behavior and
> +invariants. This means it Xen will check whether a vcpu of a domain can run
> +on one of the CPUs belonging to the nodes of the domain's node affinity,
> +but will better run it somewhere else --- even on another, remote, CPU ---
> +than violating the priority ordering (e.g., by kicking out from there another
> +running vcpu with higher priority) it is designed to enforce.
> +
> +So, last but not least, what if a domain has both vcpu and node affinity, and
> +they only partially match or they do not match at all (to understand how that
> +can happen, see the following sections)? Well, in such case, all the domain
> +memory will be allocated reflecting its node affinity, while scheduling will
> +happen according to its vcpu affinities, meaning that it is easy enough to
> +construct optimal, sub-optimal, neutral and even bad and awful configurations
> +(which is something nice, e.g., for benchmarking purposes). The remainder
> +part of this document is explaining how to do so.
> +
> +
> +Specifying Node Affinity
> +------------------------
> +
> +Besides being automatically computed from the vcpu affinities of a domain
> +(or also from it being part of a cpupool) within Xen, it might make sense
> +for the user to specify the node affinity of its domains by hand, while
> +editing their config files, as another form of partitioning the host
> +resources. If that is the case, this is where the "nodes" option of the xl
> +config file becomes useful. In fact, specifying something like the below
> +
> +        nodes = [ '0', '1', '3', '4' ]
> +
> +in a domain configuration file would result in Xen assigning host NUMA nodes
> +number 0, 1, 3 and 4 to the domain's node affinity, regardless of any vcpu
> +affinity setting for the same domain. The idea is, yes, the to things are

                                                               two

> +related, and if only one is present, it makes sense to use the other for
> +inferring it, but it is always possible to explicitly specify both of them,
> +independently on how good or awful it could end up being.
> +
> +Therefore, this is what one should expect when using "nodes", perhaps in
> +conjunction with "cpus" in a domain configuration file:
> +
> + * `cpus = "0, 1"` and no `nodes=` at all
> +   (i.e., only vcpu affinity specified):
> +     domain's vcpus can and will run only on host CPUs 0 and 1. Also, as
> +     domain's node affinity will be computed by Xen and set to whatever
> +     nodes host CPUs 0 and 1 belongs, all the domain's memory accesses will
> +     be local accesses;
> +
> + * `nodes = [ '0', '1' ]` and no `cpus=` at all
> +   (i.e., only node affinity present):
> +     domain's vcpus can run on any of the host CPUs, but the scheduler (at
> +     least if credit is used, as it is the only scheduler supporting this
> +     right now) will try running them on the CPUs that are part of host
> +     NUMA nodes 0 and 1. Memory-wise, all the domain's memory will be
> +     allocated on host NUMA nodes nodes 0 and 1. This means the most of
> +     the memory accesses of the domain should be local, but that will
> +     depend on the on-line load, behavior and actual scheduling of both
> +     the domain in question and all the other domains on the same host;
> +
> + * `nodes = [ '0', '1' ]` and `cpus = "0"`, with CPU 0 within node 0:
> +   (i.e., cpu affinity subset of node affinity):
> +     domain's vcpus can and will only run on host CPU 0. As node affinity
> +     is being explicitly set to host NUMA nodes 0 and 1 --- which includes
> +     CPU 0 --- all the memory access of the domain will be local;

In this case won't some of (half?) the memory come from node 1 and
therefore be non-local to cpu 0?

> +
> + * `nodes = [ '0', '1' ]` and `cpus = "0, 4", with CPU 0 in node 0 but
> +   CPU 4 in, say, node 2 (i.e., cpu affinity superset of node affinity):
> +     domain's vcpus can run on host CPUs 0 and 4, with CPU 4 not being within
> +     the node affinity (explicitly set to host NUMA nodes 0 and 1). The
> +     (credit) scheduler will try to keep memory accesses local by scheduling
> +     the domain's vcpus on CPU 0, but it may not achieve 100% success;
> +
> + * `nodes = [ '0', '1' ]` and `cpus = "4"`, with CPU 4 within, say, node 2

These examples might be a little clearer if you defined up front what
the nodes and cpus were and then used that for all of them?

> +   (i.e., cpu affinity disjointed with node affinity):
> +     domain's vcpus can and will run only on host CPU 4, i.e., completely
> +     "outside" of the chosen node affinity. That necessarily means all the
> +     domain's memory access will be remote.
> +
> +
> +Automatic NUMA Placement
> +------------------------
> +
> +Just in case one does not want to take the burden of manually specifying
> +all the node (and, perhaps, CPU) affinities for all its domains, xl implements
> +some automatic placement logic. This basically means the user can ask the
> +toolstack to try sorting things out in the best possible way for him.
> +This is instead of specifying manually a domain's node affinity and can be
> +paired or not with any vcpu affinity (in case it is, the relationship between
> +vcpu and node affinities just stays as stated above). To serve this purpose,
> +a new domain config switch has been introduces, i.e., the "nodes_policy"
> +option. As the name suggests, it allows for specifying a policy to be used
> +while attempting automatic placement of the new domain. Available policies
> +at the time of writing are:

A bunch of what follows would be good to have in the xl or xl.cfg man
pages too/instead. (I started with this docs patch so I haven't actually
looked at the earlier ones yet, perhaps this is already the case)

> +
> + * "auto": automatic placement by means of a not better specified (xl
> +           implementation dependant) algorithm. It is basically for those
> +           who do want automatic placement, but have no idea what policy
> +           or algorithm would be better... <<Just give me a sane default!>>
> +
> + * "ffit": automatic placement via the First Fit algorithm, applied checking
> +           the memory requirement of the domain against the amount of free
> +           memory in the various host NUMA nodes;
> +
> + * "bfit": automatic placement via the Best Fit algorithm, applied checking
> +           the memory requirement of the domain against the amount of free
> +           memory in the various host NUMA nodes;
> +
> + * "wfit": automatic placement via the Worst Fit algorithm, applied checking
> +           the memory requirement of the domain against the amount of free
> +           memory in the various host NUMA nodes;
> +
> +The various algorithms have been implemented as they offer different behavior
> +and performances (for different performance metrics). For instance, First Fit
> +is known to be efficient and quick, and it generally works better than Best
> +Fit wrt memory fragmentation, although it tends to occupy "early" nodes more
> +than "late" ones. On the other hand, Best Fit aims at optimizing memory usage,
> +although it introduces quite a bit of fragmentation, by leaving large amounts
> +of small free memory areas. Finally, the idea behind Worst Fit is that it will
> +leave big enough free memory chunks to limit the amount of fragmentation, but
> +it (as well as Best Fit does) is more expensive in terms of execution time, as
> +it needs the "list" of free memory areas to be kept sorted.
> +
> +Therefore, achieving automatic placement actually happens by properly using
> +the "nodes" and "nodes_config" configuration options as follows:
> +
> + * `nodes="auto` or `nodes_policy="auto"`:
> +     xl will try fitting the domain on the host NUMA nodes by using its
> +     own default placing algorithm, with default parameters. Most likely,
> +     all nodes will be considered suitable for the domain (unless a vcpu
> +     affinity is specified, see the last entry of this list;
> +
> + * `nodes_policy="ffit"` (or `"bfit"`, `"wfit"`) and no `nodes=` at all:
> +     xl will try fitting the domain on the host NUMA nodes by using the
> +     requested policy. All nodes will be considered suitable for the
> +     domain, and consecutive fitting attempts will be performed while
> +     increasing the number of nodes on which to put the domain itself
> +     (unless a vcpu affinity is specified, see the last entry of this list);
> +
> + * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `nodes=2`:
> +     xl will try fitting the domain on the host NUMA nodes by using the
> +     requested policy and only the number of nodes specified in `nodes=`
> +     (2 in this example).

Number of nodes rather than specifically node 2? This is different to
the examples in the preceding section?

>  All the nodes will be considered suitable for
> +     the domain, and consecutive attempts will be performed while
> +     increasing such a value;
> +
> + * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `cpus="0-6":
> +     xl will try fitting the domain on the host NUMA nodes to which the CPUs
> +     specified as vcpu affinity (0 to 6 in this example) belong, by using the
> +     requested policy. In case it fails, consecutive fitting attempts will
> +     be performed with both a reduced (first) and an increased (next) number
> +     of nodes).
> +
> +Different usage patterns --- like specifying both a policy and a list of nodes
> +are accepted, but does not make much sense after all. Therefore, although xl
> +will try at its best to interpret user's will, the resulting behavior is
> +somehow unspecified.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:12:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIG4B-0007T7-Ml; Thu, 12 Apr 2012 09:11:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIG4A-0007Sv-NE
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 09:11:47 +0000
Received: from [85.158.139.83:7984] by server-12.bemta-5.messagelabs.com id
	84/8E-05587-15C968F4; Thu, 12 Apr 2012 09:11:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334221904!22941181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27897 invoked from network); 12 Apr 2012 09:11:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11895009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 09:11:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 10:11:44 +0100
Message-ID: <1334221902.16387.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Apr 2012 10:11:42 +0100
In-Reply-To: <ec0abe6e2de3d35d626a.1334150277@Solace>
References: <patchbomb.1334150267@Solace>
	<ec0abe6e2de3d35d626a.1334150277@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10 [RFC]] xl: Some automatic NUMA
 placement documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 14:17 +0100, Dario Faggioli wrote:
> Add some rationale and usage documentation for the new automatic
> NUMA placement feature of xl.
> 
> TODO: * Decide whether we want to have things like "Future Steps/Roadmap"
>         and/or "Performances/Benchmarks Results" here as well.

I think these would be better in the list archives and on the wiki
respectively.

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff --git a/docs/misc/xl-numa-placement.txt b/docs/misc/xl-numa-placement.txt
> new file mode 100644
> --- /dev/null
> +++ b/docs/misc/xl-numa-placement.txt

It looks like you are using something approximating markdown syntax
here, so you might as well name this xl-numa-placement.markdown and get
a .html version etc almost for free.

> @@ -0,0 +1,205 @@
> +               -------------------------------------
> +               NUMA Guest Placement Design and Usage
> +               -------------------------------------
> +
> +Xen deals with Non-Uniform Memory Access (NUMA) machines in many ways. For
> +example each domain has its own "node affinity", i.e., a set of NUMA nodes
> +of the host from which memory for that domain is allocated. That becomes
> +very important as soon as many domains start running memory-intensive
> +workloads on a shared host. In fact, accessing non node-local memory
> +locations costs much more than node-local ones, to the point that the
> +degradation in performance is likely to be noticeable.
> +
> +It is then quite obvious that, any mechanism that enable the most of the
> +memory accesses for the most of the most of the guest domains to stay
> +local is something very important to achieve when dealing with NUMA
> +platforms.
> +
> +
> +Node Affinity and CPU Affinity
> +------------------------------
> +
> +There is another very popular 'affinity', besides node affinity we are
> +discussing here, which is '(v)cpu affinity'. Moreover, to make things
> +even worse, the two are different but somehow related things. In fact,
> +in both Xen and Linux worlds, 'cpu affinity' is the set of CPUs a domain
> +(that would be a task, when talking about Linux) can be scheduled on.
> +This seems to have few to do with memory accesses, but it does, as the

                      ^little

> +CPU where a domain run is also from where it tries to access its memory,
> +i.e., that is one half of what decides whether a memory access is remote
> +or local --- the other half being where the location it wants to access
> +is stored.
> +
> +Of course, if a domain is known to only run on a subset of the physical
> +CPUs of the host, it is very easy to turn all its memory accesses into
> +local ones, by just constructing it's node affinity (in Xen) basing on

                                                                ^based

> +what nodes these CPUs belongs to. Actually, that is exactly what is being
> +done by the hypervisor by default, as soon as it finds out a domain (or
> +better, the vcpus of a domain, but let's avoid getting into too much
> +details here) has a cpu affinity.
> +
> +This is working quite well, but it requires the user/system administrator
> +to explicitly specify such property --- the cpu affinity --- while the
> +domain is being created, or Xen won't be able to exploit that for ensuring
> +accesses locality.
> +
> +On the other hand, as node affinity directly affects where domain's memory
> +lives, it makes a lot of sense for it to be involved in scheduling decisions,
> +as it would be great if the hypervisor would manage in scheduling all the
> +vcpus of all the domains on CPUs attached to the various domains' local
> +memory. That is why, the node affinity of a domain is treated by the scheduler
> +as the set of nodes on which it would be preferable to run it, although
> +not at the cost of violating the scheduling algorithm behavior and
> +invariants. This means it Xen will check whether a vcpu of a domain can run
> +on one of the CPUs belonging to the nodes of the domain's node affinity,
> +but will better run it somewhere else --- even on another, remote, CPU ---
> +than violating the priority ordering (e.g., by kicking out from there another
> +running vcpu with higher priority) it is designed to enforce.
> +
> +So, last but not least, what if a domain has both vcpu and node affinity, and
> +they only partially match or they do not match at all (to understand how that
> +can happen, see the following sections)? Well, in such case, all the domain
> +memory will be allocated reflecting its node affinity, while scheduling will
> +happen according to its vcpu affinities, meaning that it is easy enough to
> +construct optimal, sub-optimal, neutral and even bad and awful configurations
> +(which is something nice, e.g., for benchmarking purposes). The remainder
> +part of this document is explaining how to do so.
> +
> +
> +Specifying Node Affinity
> +------------------------
> +
> +Besides being automatically computed from the vcpu affinities of a domain
> +(or also from it being part of a cpupool) within Xen, it might make sense
> +for the user to specify the node affinity of its domains by hand, while
> +editing their config files, as another form of partitioning the host
> +resources. If that is the case, this is where the "nodes" option of the xl
> +config file becomes useful. In fact, specifying something like the below
> +
> +        nodes = [ '0', '1', '3', '4' ]
> +
> +in a domain configuration file would result in Xen assigning host NUMA nodes
> +number 0, 1, 3 and 4 to the domain's node affinity, regardless of any vcpu
> +affinity setting for the same domain. The idea is, yes, the to things are

                                                               two

> +related, and if only one is present, it makes sense to use the other for
> +inferring it, but it is always possible to explicitly specify both of them,
> +independently on how good or awful it could end up being.
> +
> +Therefore, this is what one should expect when using "nodes", perhaps in
> +conjunction with "cpus" in a domain configuration file:
> +
> + * `cpus = "0, 1"` and no `nodes=` at all
> +   (i.e., only vcpu affinity specified):
> +     domain's vcpus can and will run only on host CPUs 0 and 1. Also, as
> +     domain's node affinity will be computed by Xen and set to whatever
> +     nodes host CPUs 0 and 1 belongs, all the domain's memory accesses will
> +     be local accesses;
> +
> + * `nodes = [ '0', '1' ]` and no `cpus=` at all
> +   (i.e., only node affinity present):
> +     domain's vcpus can run on any of the host CPUs, but the scheduler (at
> +     least if credit is used, as it is the only scheduler supporting this
> +     right now) will try running them on the CPUs that are part of host
> +     NUMA nodes 0 and 1. Memory-wise, all the domain's memory will be
> +     allocated on host NUMA nodes nodes 0 and 1. This means the most of
> +     the memory accesses of the domain should be local, but that will
> +     depend on the on-line load, behavior and actual scheduling of both
> +     the domain in question and all the other domains on the same host;
> +
> + * `nodes = [ '0', '1' ]` and `cpus = "0"`, with CPU 0 within node 0:
> +   (i.e., cpu affinity subset of node affinity):
> +     domain's vcpus can and will only run on host CPU 0. As node affinity
> +     is being explicitly set to host NUMA nodes 0 and 1 --- which includes
> +     CPU 0 --- all the memory access of the domain will be local;

In this case won't some of (half?) the memory come from node 1 and
therefore be non-local to cpu 0?

> +
> + * `nodes = [ '0', '1' ]` and `cpus = "0, 4", with CPU 0 in node 0 but
> +   CPU 4 in, say, node 2 (i.e., cpu affinity superset of node affinity):
> +     domain's vcpus can run on host CPUs 0 and 4, with CPU 4 not being within
> +     the node affinity (explicitly set to host NUMA nodes 0 and 1). The
> +     (credit) scheduler will try to keep memory accesses local by scheduling
> +     the domain's vcpus on CPU 0, but it may not achieve 100% success;
> +
> + * `nodes = [ '0', '1' ]` and `cpus = "4"`, with CPU 4 within, say, node 2

These examples might be a little clearer if you defined up front what
the nodes and cpus were and then used that for all of them?

> +   (i.e., cpu affinity disjointed with node affinity):
> +     domain's vcpus can and will run only on host CPU 4, i.e., completely
> +     "outside" of the chosen node affinity. That necessarily means all the
> +     domain's memory access will be remote.
> +
> +
> +Automatic NUMA Placement
> +------------------------
> +
> +Just in case one does not want to take the burden of manually specifying
> +all the node (and, perhaps, CPU) affinities for all its domains, xl implements
> +some automatic placement logic. This basically means the user can ask the
> +toolstack to try sorting things out in the best possible way for him.
> +This is instead of specifying manually a domain's node affinity and can be
> +paired or not with any vcpu affinity (in case it is, the relationship between
> +vcpu and node affinities just stays as stated above). To serve this purpose,
> +a new domain config switch has been introduces, i.e., the "nodes_policy"
> +option. As the name suggests, it allows for specifying a policy to be used
> +while attempting automatic placement of the new domain. Available policies
> +at the time of writing are:

A bunch of what follows would be good to have in the xl or xl.cfg man
pages too/instead. (I started with this docs patch so I haven't actually
looked at the earlier ones yet, perhaps this is already the case)

> +
> + * "auto": automatic placement by means of a not better specified (xl
> +           implementation dependant) algorithm. It is basically for those
> +           who do want automatic placement, but have no idea what policy
> +           or algorithm would be better... <<Just give me a sane default!>>
> +
> + * "ffit": automatic placement via the First Fit algorithm, applied checking
> +           the memory requirement of the domain against the amount of free
> +           memory in the various host NUMA nodes;
> +
> + * "bfit": automatic placement via the Best Fit algorithm, applied checking
> +           the memory requirement of the domain against the amount of free
> +           memory in the various host NUMA nodes;
> +
> + * "wfit": automatic placement via the Worst Fit algorithm, applied checking
> +           the memory requirement of the domain against the amount of free
> +           memory in the various host NUMA nodes;
> +
> +The various algorithms have been implemented as they offer different behavior
> +and performances (for different performance metrics). For instance, First Fit
> +is known to be efficient and quick, and it generally works better than Best
> +Fit wrt memory fragmentation, although it tends to occupy "early" nodes more
> +than "late" ones. On the other hand, Best Fit aims at optimizing memory usage,
> +although it introduces quite a bit of fragmentation, by leaving large amounts
> +of small free memory areas. Finally, the idea behind Worst Fit is that it will
> +leave big enough free memory chunks to limit the amount of fragmentation, but
> +it (as well as Best Fit does) is more expensive in terms of execution time, as
> +it needs the "list" of free memory areas to be kept sorted.
> +
> +Therefore, achieving automatic placement actually happens by properly using
> +the "nodes" and "nodes_config" configuration options as follows:
> +
> + * `nodes="auto` or `nodes_policy="auto"`:
> +     xl will try fitting the domain on the host NUMA nodes by using its
> +     own default placing algorithm, with default parameters. Most likely,
> +     all nodes will be considered suitable for the domain (unless a vcpu
> +     affinity is specified, see the last entry of this list;
> +
> + * `nodes_policy="ffit"` (or `"bfit"`, `"wfit"`) and no `nodes=` at all:
> +     xl will try fitting the domain on the host NUMA nodes by using the
> +     requested policy. All nodes will be considered suitable for the
> +     domain, and consecutive fitting attempts will be performed while
> +     increasing the number of nodes on which to put the domain itself
> +     (unless a vcpu affinity is specified, see the last entry of this list);
> +
> + * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `nodes=2`:
> +     xl will try fitting the domain on the host NUMA nodes by using the
> +     requested policy and only the number of nodes specified in `nodes=`
> +     (2 in this example).

Number of nodes rather than specifically node 2? This is different to
the examples in the preceding section?

>  All the nodes will be considered suitable for
> +     the domain, and consecutive attempts will be performed while
> +     increasing such a value;
> +
> + * `nodes_policy="auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `cpus="0-6":
> +     xl will try fitting the domain on the host NUMA nodes to which the CPUs
> +     specified as vcpu affinity (0 to 6 in this example) belong, by using the
> +     requested policy. In case it fails, consecutive fitting attempts will
> +     be performed with both a reduced (first) and an increased (next) number
> +     of nodes).
> +
> +Different usage patterns --- like specifying both a policy and a list of nodes
> +are accepted, but does not make much sense after all. Therefore, although xl
> +will try at its best to interpret user's will, the resulting behavior is
> +somehow unspecified.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:33:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIGPA-00086s-Pi; Thu, 12 Apr 2012 09:33:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SIGP8-00086h-Fl
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 09:33:26 +0000
Received: from [193.109.254.147:39726] by server-7.bemta-14.messagelabs.com id
	1C/6E-01627-561A68F4; Thu, 12 Apr 2012 09:33:25 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334223203!4238229!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 12 Apr 2012 09:33:24 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:33:24 -0000
Received: by qcsc20 with SMTP id c20so1401659qcs.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 02:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=B/3yOdQfmH8hwxSWdl51tDID6jBWYJZb7rrKlE23mQA=;
	b=UBikDvZy4CMTysJEE2HMXtr9RuIl1xunS/bWWWVUrE6AigvSlxB4Pq74l9kpsv09Mt
	aByDniuGK3q76s5KBbOtNdqATugEal47hHqINkyJqYr6J5J9EB6AbmBtTfTbmJ/DwJO/
	RHayA53shBLHpMRMXDgvEMnmCJABooXWinQkxuYtjljQ+IXsVqizOFyiuK4GJHwcgFqo
	Wh0bsrvSvY3HGioIwGR30R8fpdvHaL4xdPEqYNM5KwZYzexq2dx87jn7NPFK8ljSfN62
	iPcHlRCKQ13c1+r/MrK5SdxxbU8nTWMzFW+K2nnWgR3JGCt8ql1mc7NGw87slwebNxLM
	0PpQ==
MIME-Version: 1.0
Received: by 10.224.221.75 with SMTP id ib11mr2915114qab.21.1334223203216;
	Thu, 12 Apr 2012 02:33:23 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 12 Apr 2012 02:33:23 -0700 (PDT)
In-Reply-To: <20348.27879.297617.171564@mariner.uk.xensource.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 10:33:23 +0100
X-Google-Sender-Auth: Hju6rOwuNsb_lnJKN3O7J0tprb4
Message-ID: <CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wro=
te:
> During some discussions and handwaving, including discussions with
> some experts on the Xenserver/XCP storage architecture, we came up
> with what we think might be a plausible proposal for an architecture
> for communication between toolstack and driver domain, for storage at
> least.
>
> I offered to write it up. =A0The abstract proposal is as I understand
> the consensus from our conversation. =A0The concrete protocol is my own
> invention.
>
> Please comments. =A0After a round of review here we should consider
> whether some of the assumptions need review from the communities
> involved in "other" backends (particularly, the BSDs).
>
> (FAOD the implementation of something like this is not 4.3 material,
> but it may inform some API decisions etc. we take in 4.2.)
>
> Ian.
>
>
> Components
>
> =A0toolstack
>
> =A0guest
> =A0 =A0Might be the toolstack domain, or an (intended) guest vm.
>
> =A0driver domain
> =A0 =A0Responsible for providing the disk service to guests.
> =A0 =A0Consists, internally, of (at least):
> =A0 =A0 =A0 control plane
> =A0 =A0 =A0 backend
> =A0 =A0but we avoid exposing this internal implementation detail.
>
> =A0 =A0We permit different driver domains on a single host, serving
> =A0 =A0different guests or the same guests.
>
> =A0 =A0The toolstack is expected to know the domid of the driver domain.
>
> =A0driver domain kind
> =A0 =A0We permit different "kinds" of driver domain, perhaps implemented
> =A0 =A0by completely different code, which support different facilities.
>
> =A0 =A0Each driver domain kind needs to document what targets (see
> =A0 =A0below) are valid and how they are specified, and what preparatory
> =A0 =A0steps may need to be taken eg at system boot.
>
> =A0 =A0Driver domain kinds do not have a formal presence in the API.
>
> Objects
>
> =A0target
> =A0 =A0 A kind of name.
>
> =A0 =A0 Combination of a physical location and data format plus all other
> =A0 =A0 information needed by the underlying mechanisms, or relating to
> =A0 =A0 the data format, needed to access it.
>
> =A0 =A0 These names are assigned by the driver domain kind; the names may
> =A0 =A0 be an open class; no facility provided via this API to enumerate
> =A0 =A0 these.
>
> =A0 =A0 Syntactically, these are key/value pairs, mapping short string
> =A0 =A0 keys to shortish string values, suitable for storage in a
> =A0 =A0 xenstore directory.
>
> =A0vdi
> =A0 =A0 This host's intent to access a specific target.
> =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
> =A0 =A0 Possible states: inactive/active.
> =A0 =A0 Abstract operations: prepare, activate, deactivate, unprepare.

VDI as used by XenServer seems to mean "virtual disk instance", and as
such is actually persistent.  I don't quite understand what it's
supposed to mean here, and how it differs from VBD (which in XenServer
terminology means "virtual block device").

 -George

>
> =A0 =A0 (We call the "create" operation for this object "prepare" to
> =A0 =A0 avoid confusion with other kinds of "create".)
>
> =A0 =A0 The toolstack promises that no two vdis for the same target
> =A0 =A0 will simultaneously be active, even if the two vdis are on
> =A0 =A0 different hosts.
>
> =A0vbd
> =A0 =A0 Provision of a facility for a guest to access a particular target
> =A0 =A0 via a particular vdi. =A0There may be zero or more of these at any
> =A0 =A0 point for a particular vdi.
>
> =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
> =A0 =A0 Abstract operations: plug, unplug.
>
> =A0 =A0 (We call the "create" operation for this object "plug" to avoid
> =A0 =A0 confusion with other kinds of "create".)
>
> =A0 =A0 vbds may be created/destroyed, and the underlying vdi
> =A0 =A0 activated/deactivated, in any other. =A0However IO is only possib=
le
> =A0 =A0 to a vbd when the corresponding vdi is active. =A0The reason for
> =A0 =A0 requiring activation as a separate step is to allow as much of
> =A0 =A0 the setup for an incoming migration domain's storage to be done
> =A0 =A0 before committing to the migration and entering the "domain is
> =A0 =A0 down" stage, during which access is switched from the old to the
> =A0 =A0 new host.
>
> =A0 =A0 We will consider here the case of a vbd which provides
> =A0 =A0 service as a Xen vbd backend. =A0Other cases (eg, the driver doma=
in
> =A0 =A0 is the same as the toolstack domain and the vbd provides a block
> =A0 =A0 device in the toolstack domain) can be regarded as
> =A0 =A0 optimisations/shortcuts.
>
> Concrete protocol
>
> =A0The toolstack gives instructions to the driver domain, and receives
> =A0results, via xenstore, in the path:
> =A0 /local/domain/<driverdomid>/backendctrl/vdi
> =A0Both driver domain and toolstack have write access to the whole of
> =A0this area.
>
> =A0Each vdi which has been requested and/or exists, corresponds to a
> =A0path .../backendctrl/vdi/<vdi> where <vdi> is a string (of
> =A0alphanumerics, hyphens and underscores) chosen by the toolstack.
> =A0Inside this, there are the following nodes:
>
> =A0/local/domain/<driverdomid>/backendctrl/vdi/<vdi>/
> =A0 state =A0 =A0 =A0 The current state. =A0Values are "inactive", "activ=
e",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 or ENOENT meaning the vdi does not exist.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Set by the driver domain in response to reque=
sts.
>
> =A0 request =A0 =A0 Operation requested by the toolstack and currently
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 being performed. =A0Created by the toolstack,=
 but may
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 then not be modified by the toolstack. =A0Del=
eted
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 by the driver domain when the operation has c=
ompleted.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The values of "request" are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 prepare
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 activate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 deactivate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unprepare
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 plug <vbd>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unplug <vbd>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 <vbd> is an id chosen by the toolstack like <=
vdi>
>
> =A0 result =A0 =A0 =A0errno value (in decimal, Xen error number) best
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 describing the results of the most recently c=
ompleted
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 operation; 0 means success. =A0Created or set=
 by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain in the same transaction as it d=
eletes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 request. =A0The toolstack may delete this.
>
> =A0 result_msg =A0Optional UTF-8 string explaining any error; does not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 exist when result is "0". =A0Created or delet=
ed by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain whenever the driver domain sets=
 result.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The toolstack may delete this.
>
> =A0 t/* =A0 =A0 =A0 =A0 The target name. =A0Must be written by the toolst=
ack.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 But may not be removed or changed while eithe=
r of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 state or request exist.
>
> =A0 vbd/<vbd>/state
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The state of a vbd, "ok" or ENOENT.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Set or deleted by the driver domain in respon=
se to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 requests.
>
> =A0 vbd/<vbd>/frontend
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The frontend path (complete path in xenstore)=
 which the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen vbd should be servicing. =A0Set by the to=
olstack
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 with the plug request and not modified until =
after
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 completion of unplug.
>
> =A0 vbd/<vbd>/backend
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The backend path (complete path in xenstore) =
which the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain has chosen for the vbd. =A0Set =
by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain in response to a plug request.
>
> =A0 vbd/<vbd>/b-copy/*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The driver domain may request, in response to=
 plug,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 that the toolstack copy these values to the s=
pecified
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 backend directory, in the same transaction as=
 it
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 creates the frontend. =A0Set by the driver do=
main in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 response to a plug request; may be deleted by=
 the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 toolstack. =A0DEPRECATED, see below.
>
> The operations:
>
> =A0prepare
> =A0 =A0 =A0 =A0Creates a vdi from a target.
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request (xenstore writes by toolstack):
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "prepare"
> =A0 =A0 =A0 =A0 =A0 =A0t/* as appropriate
> =A0 =A0 =A0 =A0Results on success (xenstore writes by driver domain):
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT =A0 =A0} applies to success from al=
l operations,
> =A0 =A0 =A0 =A0 =A0 =A0result =3D "0" =A0 =A0 =A0} =A0will not be restate=
d below
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "inactive"
> =A0 =A0 =A0 =A0Results on error (applies to all operations): =A0}
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 } =A0applies
> =A0 =A0 =A0 =A0 =A0 =A0result =3D some decimal integer errno value =A0} =
=A0 to all
> =A0 =A0 =A0 =A0 =A0 =A0result_msg =3D ENOENT or a string =A0 =A0 =A0 =A0 =
=A0 =A0} =A0 =A0failures
>
> =A0activate
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "inactive"
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "activate"
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "active"
>
> =A0deactivate
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "active"
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "deactivate"
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "inactive"
>
> =A0unprepare
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state !=3D ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "unprepare"
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D ENOENT
>
> =A0removal, modification, etc. of an unprepared vdi:
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0any changes to <vdi> directory which do
> =A0 =A0 =A0 =A0 =A0 =A0 not create "state" or "request"
> =A0 =A0 =A0 =A0Results:
> =A0 =A0 =A0 =A0 =A0 =A0ignored - no response from driver domain
>
> =A0plug <vbd>
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0<frontend> ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "plug <vbd>"
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/frontend =3D <frontend> ("/local/domain/=
<guest>/...")
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state =3D "ok"
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/backend =3D <rel-backend>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(<rel-backend> is the backend path relativ=
e to the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain's home directory in xenstor=
e)
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/b-copy/* =A0may be created =A0 =A0} at l=
east one of these
> =A0 =A0 =A0 =A0 =A0 =A0<backend>/* =A0may come into existence =A0} =A0mus=
t happen
> =A0 =A0 =A0 =A0Next step (xenstore write) by toolstack:
> =A0 =A0 =A0 =A0 =A0 =A0<frontend> =A0created and populated, specifically
> =A0 =A0 =A0 =A0 =A0 =A0<frontend>/backend =3D <backend>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("/local/domain/<driverdomid>/<rel-backend=
>")
> =A0 =A0 =A0 =A0 =A0 =A0<backend> =A0 =A0created if necessary
> =A0 =A0 =A0 =A0 =A0 =A0<backend>/* =A0copied from =A0vbd/<vbd>/b-copy/* =
=A0if any
> =A0 =A0 =A0 =A0 =A0 =A0<backend>/frontend =3D <frontend> =A0unless alread=
y set
>
> =A0unplug <vbd>
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state "ok"
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "unplug <vbd>"
> =A0 =A0 =A0 =A0 =A0 =A0<frontend> ENOENT
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0<backend> ENOENT
>
> =A0The toolstack and driver domains should not store state of their own,
> =A0not required for these communication purposes, in the backendctrl/
> =A0directory in xenstore. =A0If the driver domain wishes to make records
> =A0for its own use in xenstore, it should do so in a different directory
> =A0of its choice (eg, /local/domain/<driverdomid>/private/<something>.
>
>
> Notes regarding driver domains whose block backend implementation is
> controlled from the actual xenstore backend directory:
>
> =A0The b-copy/* feature exists for compatibility with some of these. =A0If
> =A0such a backend cannot cope with the backend directory coming into
> =A0existence before the corresponding frontend directory, then it is
> =A0necessary to create and populate the backend in the same xenstore
> =A0transaction as the creation of the frontend. =A0However, such backends
> =A0should be fixed; the b-copy/* feature is deprecated and will be
> =A0withdrawn at some point.
>
> =A0Note that a vbd may be created with the vdi inactive. =A0In this case
> =A0the frontend and backend directories will exist, but the information
> =A0needed to start up the backend properly may be lacking until the vdi
> =A0is activated. =A0For example, if the existence of a suitable block
> =A0device in the driver domain depends on vdi activation, the block
> =A0device id cannot be made known to the backend until after the backend
> =A0directory has already been created and perhaps has existed for some
> =A0time. =A0It is believed that existing backends cope with this, because
> =A0they use a "hotplug script" approach - where the backend directory is
> =A0created without specifying the device node, and this backend directory
> =A0creation causes the invocation of machinery which establishes the
> =A0device node, which is subsequently written to xenstore.
>
>
> Question
>
> =A0What about network interfaces and other kinds of backend ?
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:33:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIGPA-00086s-Pi; Thu, 12 Apr 2012 09:33:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SIGP8-00086h-Fl
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 09:33:26 +0000
Received: from [193.109.254.147:39726] by server-7.bemta-14.messagelabs.com id
	1C/6E-01627-561A68F4; Thu, 12 Apr 2012 09:33:25 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334223203!4238229!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 12 Apr 2012 09:33:24 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:33:24 -0000
Received: by qcsc20 with SMTP id c20so1401659qcs.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 02:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=B/3yOdQfmH8hwxSWdl51tDID6jBWYJZb7rrKlE23mQA=;
	b=UBikDvZy4CMTysJEE2HMXtr9RuIl1xunS/bWWWVUrE6AigvSlxB4Pq74l9kpsv09Mt
	aByDniuGK3q76s5KBbOtNdqATugEal47hHqINkyJqYr6J5J9EB6AbmBtTfTbmJ/DwJO/
	RHayA53shBLHpMRMXDgvEMnmCJABooXWinQkxuYtjljQ+IXsVqizOFyiuK4GJHwcgFqo
	Wh0bsrvSvY3HGioIwGR30R8fpdvHaL4xdPEqYNM5KwZYzexq2dx87jn7NPFK8ljSfN62
	iPcHlRCKQ13c1+r/MrK5SdxxbU8nTWMzFW+K2nnWgR3JGCt8ql1mc7NGw87slwebNxLM
	0PpQ==
MIME-Version: 1.0
Received: by 10.224.221.75 with SMTP id ib11mr2915114qab.21.1334223203216;
	Thu, 12 Apr 2012 02:33:23 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 12 Apr 2012 02:33:23 -0700 (PDT)
In-Reply-To: <20348.27879.297617.171564@mariner.uk.xensource.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 10:33:23 +0100
X-Google-Sender-Auth: Hju6rOwuNsb_lnJKN3O7J0tprb4
Message-ID: <CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wro=
te:
> During some discussions and handwaving, including discussions with
> some experts on the Xenserver/XCP storage architecture, we came up
> with what we think might be a plausible proposal for an architecture
> for communication between toolstack and driver domain, for storage at
> least.
>
> I offered to write it up. =A0The abstract proposal is as I understand
> the consensus from our conversation. =A0The concrete protocol is my own
> invention.
>
> Please comments. =A0After a round of review here we should consider
> whether some of the assumptions need review from the communities
> involved in "other" backends (particularly, the BSDs).
>
> (FAOD the implementation of something like this is not 4.3 material,
> but it may inform some API decisions etc. we take in 4.2.)
>
> Ian.
>
>
> Components
>
> =A0toolstack
>
> =A0guest
> =A0 =A0Might be the toolstack domain, or an (intended) guest vm.
>
> =A0driver domain
> =A0 =A0Responsible for providing the disk service to guests.
> =A0 =A0Consists, internally, of (at least):
> =A0 =A0 =A0 control plane
> =A0 =A0 =A0 backend
> =A0 =A0but we avoid exposing this internal implementation detail.
>
> =A0 =A0We permit different driver domains on a single host, serving
> =A0 =A0different guests or the same guests.
>
> =A0 =A0The toolstack is expected to know the domid of the driver domain.
>
> =A0driver domain kind
> =A0 =A0We permit different "kinds" of driver domain, perhaps implemented
> =A0 =A0by completely different code, which support different facilities.
>
> =A0 =A0Each driver domain kind needs to document what targets (see
> =A0 =A0below) are valid and how they are specified, and what preparatory
> =A0 =A0steps may need to be taken eg at system boot.
>
> =A0 =A0Driver domain kinds do not have a formal presence in the API.
>
> Objects
>
> =A0target
> =A0 =A0 A kind of name.
>
> =A0 =A0 Combination of a physical location and data format plus all other
> =A0 =A0 information needed by the underlying mechanisms, or relating to
> =A0 =A0 the data format, needed to access it.
>
> =A0 =A0 These names are assigned by the driver domain kind; the names may
> =A0 =A0 be an open class; no facility provided via this API to enumerate
> =A0 =A0 these.
>
> =A0 =A0 Syntactically, these are key/value pairs, mapping short string
> =A0 =A0 keys to shortish string values, suitable for storage in a
> =A0 =A0 xenstore directory.
>
> =A0vdi
> =A0 =A0 This host's intent to access a specific target.
> =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
> =A0 =A0 Possible states: inactive/active.
> =A0 =A0 Abstract operations: prepare, activate, deactivate, unprepare.

VDI as used by XenServer seems to mean "virtual disk instance", and as
such is actually persistent.  I don't quite understand what it's
supposed to mean here, and how it differs from VBD (which in XenServer
terminology means "virtual block device").

 -George

>
> =A0 =A0 (We call the "create" operation for this object "prepare" to
> =A0 =A0 avoid confusion with other kinds of "create".)
>
> =A0 =A0 The toolstack promises that no two vdis for the same target
> =A0 =A0 will simultaneously be active, even if the two vdis are on
> =A0 =A0 different hosts.
>
> =A0vbd
> =A0 =A0 Provision of a facility for a guest to access a particular target
> =A0 =A0 via a particular vdi. =A0There may be zero or more of these at any
> =A0 =A0 point for a particular vdi.
>
> =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
> =A0 =A0 Abstract operations: plug, unplug.
>
> =A0 =A0 (We call the "create" operation for this object "plug" to avoid
> =A0 =A0 confusion with other kinds of "create".)
>
> =A0 =A0 vbds may be created/destroyed, and the underlying vdi
> =A0 =A0 activated/deactivated, in any other. =A0However IO is only possib=
le
> =A0 =A0 to a vbd when the corresponding vdi is active. =A0The reason for
> =A0 =A0 requiring activation as a separate step is to allow as much of
> =A0 =A0 the setup for an incoming migration domain's storage to be done
> =A0 =A0 before committing to the migration and entering the "domain is
> =A0 =A0 down" stage, during which access is switched from the old to the
> =A0 =A0 new host.
>
> =A0 =A0 We will consider here the case of a vbd which provides
> =A0 =A0 service as a Xen vbd backend. =A0Other cases (eg, the driver doma=
in
> =A0 =A0 is the same as the toolstack domain and the vbd provides a block
> =A0 =A0 device in the toolstack domain) can be regarded as
> =A0 =A0 optimisations/shortcuts.
>
> Concrete protocol
>
> =A0The toolstack gives instructions to the driver domain, and receives
> =A0results, via xenstore, in the path:
> =A0 /local/domain/<driverdomid>/backendctrl/vdi
> =A0Both driver domain and toolstack have write access to the whole of
> =A0this area.
>
> =A0Each vdi which has been requested and/or exists, corresponds to a
> =A0path .../backendctrl/vdi/<vdi> where <vdi> is a string (of
> =A0alphanumerics, hyphens and underscores) chosen by the toolstack.
> =A0Inside this, there are the following nodes:
>
> =A0/local/domain/<driverdomid>/backendctrl/vdi/<vdi>/
> =A0 state =A0 =A0 =A0 The current state. =A0Values are "inactive", "activ=
e",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 or ENOENT meaning the vdi does not exist.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Set by the driver domain in response to reque=
sts.
>
> =A0 request =A0 =A0 Operation requested by the toolstack and currently
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 being performed. =A0Created by the toolstack,=
 but may
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 then not be modified by the toolstack. =A0Del=
eted
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 by the driver domain when the operation has c=
ompleted.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The values of "request" are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 prepare
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 activate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 deactivate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unprepare
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 plug <vbd>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unplug <vbd>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 <vbd> is an id chosen by the toolstack like <=
vdi>
>
> =A0 result =A0 =A0 =A0errno value (in decimal, Xen error number) best
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 describing the results of the most recently c=
ompleted
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 operation; 0 means success. =A0Created or set=
 by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain in the same transaction as it d=
eletes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 request. =A0The toolstack may delete this.
>
> =A0 result_msg =A0Optional UTF-8 string explaining any error; does not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 exist when result is "0". =A0Created or delet=
ed by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain whenever the driver domain sets=
 result.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The toolstack may delete this.
>
> =A0 t/* =A0 =A0 =A0 =A0 The target name. =A0Must be written by the toolst=
ack.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 But may not be removed or changed while eithe=
r of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 state or request exist.
>
> =A0 vbd/<vbd>/state
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The state of a vbd, "ok" or ENOENT.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Set or deleted by the driver domain in respon=
se to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 requests.
>
> =A0 vbd/<vbd>/frontend
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The frontend path (complete path in xenstore)=
 which the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen vbd should be servicing. =A0Set by the to=
olstack
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 with the plug request and not modified until =
after
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 completion of unplug.
>
> =A0 vbd/<vbd>/backend
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The backend path (complete path in xenstore) =
which the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain has chosen for the vbd. =A0Set =
by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain in response to a plug request.
>
> =A0 vbd/<vbd>/b-copy/*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 The driver domain may request, in response to=
 plug,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 that the toolstack copy these values to the s=
pecified
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 backend directory, in the same transaction as=
 it
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 creates the frontend. =A0Set by the driver do=
main in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 response to a plug request; may be deleted by=
 the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 toolstack. =A0DEPRECATED, see below.
>
> The operations:
>
> =A0prepare
> =A0 =A0 =A0 =A0Creates a vdi from a target.
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request (xenstore writes by toolstack):
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "prepare"
> =A0 =A0 =A0 =A0 =A0 =A0t/* as appropriate
> =A0 =A0 =A0 =A0Results on success (xenstore writes by driver domain):
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT =A0 =A0} applies to success from al=
l operations,
> =A0 =A0 =A0 =A0 =A0 =A0result =3D "0" =A0 =A0 =A0} =A0will not be restate=
d below
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "inactive"
> =A0 =A0 =A0 =A0Results on error (applies to all operations): =A0}
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 } =A0applies
> =A0 =A0 =A0 =A0 =A0 =A0result =3D some decimal integer errno value =A0} =
=A0 to all
> =A0 =A0 =A0 =A0 =A0 =A0result_msg =3D ENOENT or a string =A0 =A0 =A0 =A0 =
=A0 =A0} =A0 =A0failures
>
> =A0activate
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "inactive"
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "activate"
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "active"
>
> =A0deactivate
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "active"
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "deactivate"
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D "inactive"
>
> =A0unprepare
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state !=3D ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "unprepare"
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0state =3D ENOENT
>
> =A0removal, modification, etc. of an unprepared vdi:
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0any changes to <vdi> directory which do
> =A0 =A0 =A0 =A0 =A0 =A0 not create "state" or "request"
> =A0 =A0 =A0 =A0Results:
> =A0 =A0 =A0 =A0 =A0 =A0ignored - no response from driver domain
>
> =A0plug <vbd>
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0<frontend> ENOENT
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "plug <vbd>"
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/frontend =3D <frontend> ("/local/domain/=
<guest>/...")
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state =3D "ok"
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/backend =3D <rel-backend>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(<rel-backend> is the backend path relativ=
e to the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 driver domain's home directory in xenstor=
e)
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/b-copy/* =A0may be created =A0 =A0} at l=
east one of these
> =A0 =A0 =A0 =A0 =A0 =A0<backend>/* =A0may come into existence =A0} =A0mus=
t happen
> =A0 =A0 =A0 =A0Next step (xenstore write) by toolstack:
> =A0 =A0 =A0 =A0 =A0 =A0<frontend> =A0created and populated, specifically
> =A0 =A0 =A0 =A0 =A0 =A0<frontend>/backend =3D <backend>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("/local/domain/<driverdomid>/<rel-backend=
>")
> =A0 =A0 =A0 =A0 =A0 =A0<backend> =A0 =A0created if necessary
> =A0 =A0 =A0 =A0 =A0 =A0<backend>/* =A0copied from =A0vbd/<vbd>/b-copy/* =
=A0if any
> =A0 =A0 =A0 =A0 =A0 =A0<backend>/frontend =3D <frontend> =A0unless alread=
y set
>
> =A0unplug <vbd>
> =A0 =A0 =A0 =A0Preconditions:
> =A0 =A0 =A0 =A0 =A0 =A0state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0request ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state "ok"
> =A0 =A0 =A0 =A0Request:
> =A0 =A0 =A0 =A0 =A0 =A0request =3D "unplug <vbd>"
> =A0 =A0 =A0 =A0 =A0 =A0<frontend> ENOENT
> =A0 =A0 =A0 =A0Results on success:
> =A0 =A0 =A0 =A0 =A0 =A0vbd/<vbd>/state ENOENT
> =A0 =A0 =A0 =A0 =A0 =A0<backend> ENOENT
>
> =A0The toolstack and driver domains should not store state of their own,
> =A0not required for these communication purposes, in the backendctrl/
> =A0directory in xenstore. =A0If the driver domain wishes to make records
> =A0for its own use in xenstore, it should do so in a different directory
> =A0of its choice (eg, /local/domain/<driverdomid>/private/<something>.
>
>
> Notes regarding driver domains whose block backend implementation is
> controlled from the actual xenstore backend directory:
>
> =A0The b-copy/* feature exists for compatibility with some of these. =A0If
> =A0such a backend cannot cope with the backend directory coming into
> =A0existence before the corresponding frontend directory, then it is
> =A0necessary to create and populate the backend in the same xenstore
> =A0transaction as the creation of the frontend. =A0However, such backends
> =A0should be fixed; the b-copy/* feature is deprecated and will be
> =A0withdrawn at some point.
>
> =A0Note that a vbd may be created with the vdi inactive. =A0In this case
> =A0the frontend and backend directories will exist, but the information
> =A0needed to start up the backend properly may be lacking until the vdi
> =A0is activated. =A0For example, if the existence of a suitable block
> =A0device in the driver domain depends on vdi activation, the block
> =A0device id cannot be made known to the backend until after the backend
> =A0directory has already been created and perhaps has existed for some
> =A0time. =A0It is believed that existing backends cope with this, because
> =A0they use a "hotplug script" approach - where the backend directory is
> =A0created without specifying the device node, and this backend directory
> =A0creation causes the invocation of machinery which establishes the
> =A0device node, which is subsequently written to xenstore.
>
>
> Question
>
> =A0What about network interfaces and other kinds of backend ?
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:37:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIGSe-0008QV-1G; Thu, 12 Apr 2012 09:37:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIGSb-0008Q9-RF
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 09:37:02 +0000
Received: from [193.109.254.147:39530] by server-6.bemta-14.messagelabs.com id
	B1/9B-02047-D32A68F4; Thu, 12 Apr 2012 09:37:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334223420!4285989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2792 invoked from network); 12 Apr 2012 09:37:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11895842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 09:37:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 10:37:00 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIGQ0-000409-Sk;
	Thu, 12 Apr 2012 09:34:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIGQ0-0003El-NR;
	Thu, 12 Apr 2012 10:34:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12648-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 10:34:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12648: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12648 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12648/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12578
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12578
 build-amd64                   4 xen-build                 fail REGR. vs. 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  80130491806f
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:37:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIGSe-0008QV-1G; Thu, 12 Apr 2012 09:37:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIGSb-0008Q9-RF
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 09:37:02 +0000
Received: from [193.109.254.147:39530] by server-6.bemta-14.messagelabs.com id
	B1/9B-02047-D32A68F4; Thu, 12 Apr 2012 09:37:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334223420!4285989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2792 invoked from network); 12 Apr 2012 09:37:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11895842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 09:37:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 10:37:00 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIGQ0-000409-Sk;
	Thu, 12 Apr 2012 09:34:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIGQ0-0003El-NR;
	Thu, 12 Apr 2012 10:34:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12648-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 10:34:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12648: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12648 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12648/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12578
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12578
 build-amd64                   4 xen-build                 fail REGR. vs. 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  80130491806f
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIGla-0000rp-OJ; Thu, 12 Apr 2012 09:56:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SIGlZ-0000rk-Ki
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 09:56:37 +0000
Received: from [193.109.254.147:48154] by server-6.bemta-14.messagelabs.com id
	D9/FA-02047-4D6A68F4; Thu, 12 Apr 2012 09:56:36 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334224594!4261918!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12996 invoked from network); 12 Apr 2012 09:56:35 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:56:35 -0000
Received: by qabg40 with SMTP id g40so1541966qab.11
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 02:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=dGsZpHGhLa/wAI2ZhOaCIBgGM/BcmJzFG8NbnzcwJG0=;
	b=exo/1ld0+VWM/i7bZC9DG4OMYHLOcFP7YWy62Ln2miQisS1GmfEhEZ9pR/pZbNo/Jj
	3mQq0/wiGT9LeGzc2aegnEA/mGpqFQTDirtq5JsC8YUTqpFBOPXAJiIy92rJnBMDfsKN
	TdUii4OlK8atQko1yf9ygBmya9wEgnN3ujzZx4E6Ex8sZ2t6DJWhzLNNzl9lTmfu/tKB
	a8mxNMhJ0OzTeUhng/7a4RMeBhl8mRtqpX1e5a6EKUnazpMPcIvrzVaY11idZSI2Mble
	QNw+S+V5+alKCaY1hky4Oe45aDCWviQMSsSDw0LMPxlLiPdwsd6Dir0uxe2f/Jzz5yYP
	nnLg==
MIME-Version: 1.0
Received: by 10.224.101.197 with SMTP id d5mr3053293qao.8.1334224594100; Thu,
	12 Apr 2012 02:56:34 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 12 Apr 2012 02:56:34 -0700 (PDT)
In-Reply-To: <1334053490.12209.176.camel@dagon.hellion.org.uk>
References: <1334053490.12209.176.camel@dagon.hellion.org.uk>
Date: Thu, 12 Apr 2012 10:56:34 +0100
X-Google-Sender-Auth: v_3KCZ6B6tMMb9ZkxbQt-noJpQ0
Message-ID: <CAFLBxZZ61JvHcNrPnsDWcfp58rWQoKsxdKR=d-2CNsF8pGLQHw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 11:24 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March =A0 =A0 =A0 =A0-- TODO list locked down
> 2 April =A0 =A0 =A0 =A0 -- Feature Freeze
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 << WE ARE HERE
> Mid/Late April =A0-- First release candidate
> Weekly =A0 =A0 =A0 =A0 =A0-- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> Lots more DONE this week, still a few big ticket items or items with no
> progress (that I've noticed) please let me know if the status of
> anything has changed.
>
> From next week I think I will start also tracking bugs on these lists.
> Please let me know if you have something which you feel should be listed
> here, as well as your justification for it being a blocker rather than
> "nice to fix".

Here are bugs I've found:

* Zombie driver domains.  There's a bug where PV guests with devices
passed through with xl hang around as "zombies", with one outstanding
page reference.  I think this should really be a blocker.  I'm working
on this at the moment.

* Manually ballooning dom0.  xl mem-set 0 [foo] fails with "libxl:
error: libxl.c:2569:libxl_set_memory_target: cannot get memory info
from /local/domain/0/memory/static-max: No such file or directory".
I'd make this a blocker just because it should be easy to fix and it's
pretty embarassing.  This might be suitable for an enthusiastic
on-looker.

Also, since there have been other situations / reports of zombie
domains, it would be good if we could get a zombie domain detector
into the testing system to see how widespread they are.

 -George

>
> hypervisor, blockers:
> =A0 =A0 =A0* NONE?
>
> tools, blockers:
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. Involves AP=
I changes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* locking/serialization, e.g., for domain crea=
tion. As of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0now, =A0nothing is provided for this purpo=
se, and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstream toolstacks have to put their ow=
n mechanisms
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in place. E.g., xl uses a fcntl() lock aro=
und the whole
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0process of domain creation. It should OTOH=
 be libxl job
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to offer a proper set of hooks --placed at=
 the proper
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spots during the domain creation process--=
 for the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstreams to fill with the proper callba=
cks. (Dario
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Faggioli)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Thinking to defer this until=
 4.3?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* agree & document compatibility guarantees + =
associated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0technical measures (Ian C, DONE)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* feature parity wrt driver domain support (Ge=
orge Dunlap,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for "rtc_timeoffset" and "localti=
me" (Lin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ming, DONE)
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
> =A0 =A0 =A0* Domain 0 block attach & general hotplug when using qdisk bac=
kend
> =A0 =A0 =A0 =A0(need to start qemu as necessary etc) (Stefano S, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* file:// backend performance. qemu-xen-tradition's qdisk is q=
uite
> =A0 =A0 =A0 =A0slow & blktap2 not available in upstream kernels. Need to
> =A0 =A0 =A0 =A0consider our options:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen's qdisk is thought to be well perfo=
rming but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0qemu-xen is not yet the default. Complexit=
y arising from
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0splitting qemu-for-qdisk out from qemu-for=
-dm and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0running N qemu's.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* potentially fully userspace blktap could be =
ready for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04.2 (unlikely to be available in 4.2)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* use /dev/loop+blkback. This requires loop dr=
iver AIO and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O_DIRECT patches which are not (AFAIK) yet=
 upstream.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Leverage XCP's blktap2 DKMS work. (Useful fa=
llback for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some usecases
> =A0 =A0 =A0 =A0Stefano has done a lot of work here and has proposed some
> =A0 =A0 =A0 =A0performance improvements for qdisk in both qemu-xen and
> =A0 =A0 =A0 =A0qemu-xen-traditional which make them a plausible alternati=
ve for
> =A0 =A0 =A0 =A0Xen 4.2. This is likely the route we will now take. Need to
> =A0 =A0 =A0 =A0mention in release notes?
> =A0 =A0 =A0* Improved Hotplug script support (Roger Pau Monn=E9, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
>
> hypervisor, nice to have:
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "The last patch to use a waitqueue in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__get_gfn_type_access() from Tim works. =
=A0However, there
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are a few users who call __get_gfn_type_ac=
cess with the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_lock held. This part needs to be ad=
dressed in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some way."
> =A0 =A0 =A0* Sharing support for AMD (Tim, Andres).
> =A0 =A0 =A0* PoD performance improvements (George Dunlap)
>
> tools, nice to have:
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring, lots of
> =A0 =A0 =A0 =A0discussion around interface, general consensus reached on =
what
> =A0 =A0 =A0 =A0it should look like. Olaf has let me know that he is proba=
bly
> =A0 =A0 =A0 =A0not going to have time to do this for 4.2, will likely sli=
p to
> =A0 =A0 =A0 =A04.3 unless someone else want to pick up that work)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, qemu patches applied, waiting =
for libxl etc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0side which has been recently reposted)
> =A0 =A0 =A0* Nested-virtualisation. Currently "experimental". Likely to
> =A0 =A0 =A0 =A0release that way.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested SVM. Tested in a variety of configura=
tions but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still some issues with the most important =
use case (w7
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XP mode) [0] =A0(Christoph Egger)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested VMX. Needs nested EPT to be genuinely=
 useful.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Need more data on testedness etc (Intel)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, patches reposted recently, was blocked behind qe=
mu
> =A0 =A0 =A0 =A0save restore patches which are now in)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for autospawning vncviewer (vncvi=
ewer=3D1 or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise) (Goncalo Gomes, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga=
gn=E9, patches
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor=
ge Dunlap)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 09:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 09:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIGla-0000rp-OJ; Thu, 12 Apr 2012 09:56:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SIGlZ-0000rk-Ki
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 09:56:37 +0000
Received: from [193.109.254.147:48154] by server-6.bemta-14.messagelabs.com id
	D9/FA-02047-4D6A68F4; Thu, 12 Apr 2012 09:56:36 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334224594!4261918!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12996 invoked from network); 12 Apr 2012 09:56:35 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 09:56:35 -0000
Received: by qabg40 with SMTP id g40so1541966qab.11
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 02:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=dGsZpHGhLa/wAI2ZhOaCIBgGM/BcmJzFG8NbnzcwJG0=;
	b=exo/1ld0+VWM/i7bZC9DG4OMYHLOcFP7YWy62Ln2miQisS1GmfEhEZ9pR/pZbNo/Jj
	3mQq0/wiGT9LeGzc2aegnEA/mGpqFQTDirtq5JsC8YUTqpFBOPXAJiIy92rJnBMDfsKN
	TdUii4OlK8atQko1yf9ygBmya9wEgnN3ujzZx4E6Ex8sZ2t6DJWhzLNNzl9lTmfu/tKB
	a8mxNMhJ0OzTeUhng/7a4RMeBhl8mRtqpX1e5a6EKUnazpMPcIvrzVaY11idZSI2Mble
	QNw+S+V5+alKCaY1hky4Oe45aDCWviQMSsSDw0LMPxlLiPdwsd6Dir0uxe2f/Jzz5yYP
	nnLg==
MIME-Version: 1.0
Received: by 10.224.101.197 with SMTP id d5mr3053293qao.8.1334224594100; Thu,
	12 Apr 2012 02:56:34 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 12 Apr 2012 02:56:34 -0700 (PDT)
In-Reply-To: <1334053490.12209.176.camel@dagon.hellion.org.uk>
References: <1334053490.12209.176.camel@dagon.hellion.org.uk>
Date: Thu, 12 Apr 2012 10:56:34 +0100
X-Google-Sender-Auth: v_3KCZ6B6tMMb9ZkxbQt-noJpQ0
Message-ID: <CAFLBxZZ61JvHcNrPnsDWcfp58rWQoKsxdKR=d-2CNsF8pGLQHw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 11:24 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March =A0 =A0 =A0 =A0-- TODO list locked down
> 2 April =A0 =A0 =A0 =A0 -- Feature Freeze
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 << WE ARE HERE
> Mid/Late April =A0-- First release candidate
> Weekly =A0 =A0 =A0 =A0 =A0-- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> Lots more DONE this week, still a few big ticket items or items with no
> progress (that I've noticed) please let me know if the status of
> anything has changed.
>
> From next week I think I will start also tracking bugs on these lists.
> Please let me know if you have something which you feel should be listed
> here, as well as your justification for it being a blocker rather than
> "nice to fix".

Here are bugs I've found:

* Zombie driver domains.  There's a bug where PV guests with devices
passed through with xl hang around as "zombies", with one outstanding
page reference.  I think this should really be a blocker.  I'm working
on this at the moment.

* Manually ballooning dom0.  xl mem-set 0 [foo] fails with "libxl:
error: libxl.c:2569:libxl_set_memory_target: cannot get memory info
from /local/domain/0/memory/static-max: No such file or directory".
I'd make this a blocker just because it should be easy to fix and it's
pretty embarassing.  This might be suitable for an enthusiastic
on-looker.

Also, since there have been other situations / reports of zombie
domains, it would be good if we could get a zombie domain detector
into the testing system to see how widespread they are.

 -George

>
> hypervisor, blockers:
> =A0 =A0 =A0* NONE?
>
> tools, blockers:
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. Involves AP=
I changes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* locking/serialization, e.g., for domain crea=
tion. As of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0now, =A0nothing is provided for this purpo=
se, and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstream toolstacks have to put their ow=
n mechanisms
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in place. E.g., xl uses a fcntl() lock aro=
und the whole
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0process of domain creation. It should OTOH=
 be libxl job
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to offer a proper set of hooks --placed at=
 the proper
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spots during the domain creation process--=
 for the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstreams to fill with the proper callba=
cks. (Dario
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Faggioli)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Thinking to defer this until=
 4.3?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* agree & document compatibility guarantees + =
associated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0technical measures (Ian C, DONE)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* feature parity wrt driver domain support (Ge=
orge Dunlap,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for "rtc_timeoffset" and "localti=
me" (Lin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ming, DONE)
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
> =A0 =A0 =A0* Domain 0 block attach & general hotplug when using qdisk bac=
kend
> =A0 =A0 =A0 =A0(need to start qemu as necessary etc) (Stefano S, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* file:// backend performance. qemu-xen-tradition's qdisk is q=
uite
> =A0 =A0 =A0 =A0slow & blktap2 not available in upstream kernels. Need to
> =A0 =A0 =A0 =A0consider our options:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen's qdisk is thought to be well perfo=
rming but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0qemu-xen is not yet the default. Complexit=
y arising from
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0splitting qemu-for-qdisk out from qemu-for=
-dm and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0running N qemu's.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* potentially fully userspace blktap could be =
ready for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04.2 (unlikely to be available in 4.2)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* use /dev/loop+blkback. This requires loop dr=
iver AIO and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O_DIRECT patches which are not (AFAIK) yet=
 upstream.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Leverage XCP's blktap2 DKMS work. (Useful fa=
llback for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some usecases
> =A0 =A0 =A0 =A0Stefano has done a lot of work here and has proposed some
> =A0 =A0 =A0 =A0performance improvements for qdisk in both qemu-xen and
> =A0 =A0 =A0 =A0qemu-xen-traditional which make them a plausible alternati=
ve for
> =A0 =A0 =A0 =A0Xen 4.2. This is likely the route we will now take. Need to
> =A0 =A0 =A0 =A0mention in release notes?
> =A0 =A0 =A0* Improved Hotplug script support (Roger Pau Monn=E9, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
>
> hypervisor, nice to have:
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "The last patch to use a waitqueue in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__get_gfn_type_access() from Tim works. =
=A0However, there
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are a few users who call __get_gfn_type_ac=
cess with the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_lock held. This part needs to be ad=
dressed in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some way."
> =A0 =A0 =A0* Sharing support for AMD (Tim, Andres).
> =A0 =A0 =A0* PoD performance improvements (George Dunlap)
>
> tools, nice to have:
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring, lots of
> =A0 =A0 =A0 =A0discussion around interface, general consensus reached on =
what
> =A0 =A0 =A0 =A0it should look like. Olaf has let me know that he is proba=
bly
> =A0 =A0 =A0 =A0not going to have time to do this for 4.2, will likely sli=
p to
> =A0 =A0 =A0 =A04.3 unless someone else want to pick up that work)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, qemu patches applied, waiting =
for libxl etc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0side which has been recently reposted)
> =A0 =A0 =A0* Nested-virtualisation. Currently "experimental". Likely to
> =A0 =A0 =A0 =A0release that way.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested SVM. Tested in a variety of configura=
tions but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still some issues with the most important =
use case (w7
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XP mode) [0] =A0(Christoph Egger)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested VMX. Needs nested EPT to be genuinely=
 useful.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Need more data on testedness etc (Intel)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, patches reposted recently, was blocked behind qe=
mu
> =A0 =A0 =A0 =A0save restore patches which are now in)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for autospawning vncviewer (vncvi=
ewer=3D1 or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise) (Goncalo Gomes, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga=
gn=E9, patches
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor=
ge Dunlap)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:17:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIH4v-0001Rt-Ku; Thu, 12 Apr 2012 10:16:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIH4u-0001Ri-4y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:16:36 +0000
Received: from [85.158.143.35:51271] by server-2.bemta-4.messagelabs.com id
	12/7C-17550-38BA68F4; Thu, 12 Apr 2012 10:16:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334225794!6742228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18276 invoked from network); 12 Apr 2012 10:16:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:16:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11897076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:16:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:16:34 +0100
Date: Thu, 12 Apr 2012 11:20:19 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: QEMU-devel <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v2 0/2] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series by Wei Liu implements a simple Xen APIC module and use
it to deliver MSI/MSIX for Xen HVM guests.

The second version of this series includes the "or later" copyright
clause for xen_apic.c and a fix to the return value of xen_apic_mem_read
(thanks Peter for finding it out).

Stefano Stabellini (2):
      Xen: basic HVM MSI injection support.
      Xen: Add xen-apic support and hook it up.

 Makefile.target |    2 +-
 hw/pc.c         |    8 +++++
 hw/xen.h        |    1 +
 hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 xen-all.c       |    5 +++
 xen-stub.c      |    4 ++
 6 files changed, 109 insertions(+), 1 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:17:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIH4v-0001Rt-Ku; Thu, 12 Apr 2012 10:16:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIH4u-0001Ri-4y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:16:36 +0000
Received: from [85.158.143.35:51271] by server-2.bemta-4.messagelabs.com id
	12/7C-17550-38BA68F4; Thu, 12 Apr 2012 10:16:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334225794!6742228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18276 invoked from network); 12 Apr 2012 10:16:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:16:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11897076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:16:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:16:34 +0100
Date: Thu, 12 Apr 2012 11:20:19 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: QEMU-devel <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "liuw@liuw.name" <liuw@liuw.name>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v2 0/2] MSI/MSIX injection for Xen HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series by Wei Liu implements a simple Xen APIC module and use
it to deliver MSI/MSIX for Xen HVM guests.

The second version of this series includes the "or later" copyright
clause for xen_apic.c and a fix to the return value of xen_apic_mem_read
(thanks Peter for finding it out).

Stefano Stabellini (2):
      Xen: basic HVM MSI injection support.
      Xen: Add xen-apic support and hook it up.

 Makefile.target |    2 +-
 hw/pc.c         |    8 +++++
 hw/xen.h        |    1 +
 hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 xen-all.c       |    5 +++
 xen-stub.c      |    4 ++
 6 files changed, 109 insertions(+), 1 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:18:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIH62-0001XE-2o; Thu, 12 Apr 2012 10:17:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIH60-0001Ww-52
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:17:44 +0000
Received: from [85.158.143.35:36676] by server-3.bemta-4.messagelabs.com id
	9A/7D-05853-7CBA68F4; Thu, 12 Apr 2012 10:17:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334225860!14191338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17863 invoked from network); 12 Apr 2012 10:17:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:17:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="24089731"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:17:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:17:39 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIH5q-0008Da-DI; Thu, 12 Apr 2012 11:17:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 12 Apr 2012 11:21:33 +0100
Message-ID: <1334226094-27602-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, wei.liu2@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, liuw@liuw.name, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v2 1/2] Xen: basic HVM MSI injection support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "Wei Liu" <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen.h   |    1 +
 xen-all.c  |    5 +++++
 xen-stub.c |    4 ++++
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index b46879c..e5926b7 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -34,6 +34,7 @@ static inline int xen_enabled(void)
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level);
 
 qemu_irq *xen_interrupt_controller_init(void);
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..abd2b2d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -122,6 +122,11 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+}
+
 static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
diff --git a/xen-stub.c b/xen-stub.c
index 9ea02d4..8ff2b79 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -29,6 +29,10 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 {
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+}
+
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:18:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIH62-0001XE-2o; Thu, 12 Apr 2012 10:17:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIH60-0001Ww-52
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:17:44 +0000
Received: from [85.158.143.35:36676] by server-3.bemta-4.messagelabs.com id
	9A/7D-05853-7CBA68F4; Thu, 12 Apr 2012 10:17:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334225860!14191338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17863 invoked from network); 12 Apr 2012 10:17:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:17:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="24089731"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:17:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:17:39 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIH5q-0008Da-DI; Thu, 12 Apr 2012 11:17:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 12 Apr 2012 11:21:33 +0100
Message-ID: <1334226094-27602-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, wei.liu2@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, liuw@liuw.name, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v2 1/2] Xen: basic HVM MSI injection support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "Wei Liu" <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen.h   |    1 +
 xen-all.c  |    5 +++++
 xen-stub.c |    4 ++++
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index b46879c..e5926b7 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -34,6 +34,7 @@ static inline int xen_enabled(void)
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level);
 
 qemu_irq *xen_interrupt_controller_init(void);
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..abd2b2d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -122,6 +122,11 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+}
+
 static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
diff --git a/xen-stub.c b/xen-stub.c
index 9ea02d4..8ff2b79 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -29,6 +29,10 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 {
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+}
+
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:18:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIH6F-0001Yo-Fi; Thu, 12 Apr 2012 10:17:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIH6D-0001YP-UC
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:17:58 +0000
Received: from [85.158.138.51:21048] by server-10.bemta-3.messagelabs.com id
	61/8D-29478-3DBA68F4; Thu, 12 Apr 2012 10:17:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334225871!21789654!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6574 invoked from network); 12 Apr 2012 10:17:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:17:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190003144"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:17:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:17:39 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIH5q-0008Da-Dr; Thu, 12 Apr 2012 11:17:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 12 Apr 2012 11:21:34 +0100
Message-ID: <1334226094-27602-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>, xen-devel@lists.xensource.com,
	wei.liu2@citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, liuw@liuw.name, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v2 2/2] Xen: Add xen-apic support and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "Wei Liu" <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
CC: Jan Kiszka <jan.kiszka@siemens.com>
CC: Peter Maydell <peter.maydell@linaro.org>
---
 Makefile.target |    2 +-
 hw/pc.c         |    8 +++++
 hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 99 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_apic.c

diff --git a/Makefile.target b/Makefile.target
index 14c8fa1..0c2d865 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -236,7 +236,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
 obj-$(CONFIG_NO_XEN) += xen-stub.o
 
-obj-i386-$(CONFIG_XEN) += xen_platform.o
+obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/pc.c b/hw/pc.c
index 67f0479..1f5aacb 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -42,6 +42,7 @@
 #include "sysbus.h"
 #include "sysemu.h"
 #include "kvm.h"
+#include "xen.h"
 #include "blockdev.h"
 #include "ui/qemu-spice.h"
 #include "memory.h"
@@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
 
     if (kvm_irqchip_in_kernel()) {
         dev = qdev_create(NULL, "kvm-apic");
+    } else if (xen_enabled()) {
+        dev = qdev_create(NULL, "xen-apic");
     } else {
         dev = qdev_create(NULL, "apic");
     }
+
     qdev_prop_set_uint8(dev, "id", apic_id);
     qdev_prop_set_ptr(dev, "cpu_env", env);
     qdev_init_nofail(dev);
@@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
         msi_supported = true;
     }
 
+    if (xen_enabled()) {
+        msi_supported = true;
+    }
+
     return dev;
 }
 
diff --git a/hw/xen_apic.c b/hw/xen_apic.c
new file mode 100644
index 0000000..1725ff6
--- /dev/null
+++ b/hw/xen_apic.c
@@ -0,0 +1,90 @@
+/*
+ * Xen basic APIC support
+ *
+ * Copyright (c) 2012 Citrix
+ *
+ * Authors:
+ *  Wei Liu <wei.liu2@citrix.com>
+ *
+ * This work is licensed under the terms of the GNU GPL version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+#include "hw/apic_internal.h"
+#include "hw/msi.h"
+#include "xen.h"
+
+static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
+                                  unsigned size)
+{
+    return ~(uint64_t)0;
+}
+
+static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
+                               uint64_t data, unsigned size)
+{
+    if (size != sizeof(uint32_t)) {
+        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
+        return;
+    }
+
+    xen_hvm_inject_msi(addr, data);
+}
+
+static const MemoryRegionOps xen_apic_io_ops = {
+    .read = xen_apic_mem_read,
+    .write = xen_apic_mem_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void xen_apic_init(APICCommonState *s)
+{
+    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
+                          MSI_SPACE_SIZE);
+}
+
+static void xen_apic_set_base(APICCommonState *s, uint64_t val)
+{
+}
+
+static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
+{
+}
+
+static uint8_t xen_apic_get_tpr(APICCommonState *s)
+{
+    return 0;
+}
+
+static void xen_apic_vapic_base_update(APICCommonState *s)
+{
+}
+
+static void xen_apic_external_nmi(APICCommonState *s)
+{
+}
+
+static void xen_apic_class_init(ObjectClass *klass, void *data)
+{
+    APICCommonClass *k = APIC_COMMON_CLASS(klass);
+
+    k->init = xen_apic_init;
+    k->set_base = xen_apic_set_base;
+    k->set_tpr = xen_apic_set_tpr;
+    k->get_tpr = xen_apic_get_tpr;
+    k->vapic_base_update = xen_apic_vapic_base_update;
+    k->external_nmi = xen_apic_external_nmi;
+}
+
+static TypeInfo xen_apic_info = {
+    .name = "xen-apic",
+    .parent = TYPE_APIC_COMMON,
+    .instance_size = sizeof(APICCommonState),
+    .class_init = xen_apic_class_init,
+};
+
+static void xen_apic_register_types(void)
+{
+    type_register_static(&xen_apic_info);
+}
+
+type_init(xen_apic_register_types)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:18:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIH6F-0001Yo-Fi; Thu, 12 Apr 2012 10:17:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIH6D-0001YP-UC
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:17:58 +0000
Received: from [85.158.138.51:21048] by server-10.bemta-3.messagelabs.com id
	61/8D-29478-3DBA68F4; Thu, 12 Apr 2012 10:17:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334225871!21789654!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6574 invoked from network); 12 Apr 2012 10:17:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:17:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190003144"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:17:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:17:39 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIH5q-0008Da-Dr; Thu, 12 Apr 2012 11:17:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 12 Apr 2012 11:21:34 +0100
Message-ID: <1334226094-27602-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121116170.15151@kaball-desktop>
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>, xen-devel@lists.xensource.com,
	wei.liu2@citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, liuw@liuw.name, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v2 2/2] Xen: Add xen-apic support and hook it up.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: "Wei Liu" <wei.liu2@citrix.com>

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
CC: Jan Kiszka <jan.kiszka@siemens.com>
CC: Peter Maydell <peter.maydell@linaro.org>
---
 Makefile.target |    2 +-
 hw/pc.c         |    8 +++++
 hw/xen_apic.c   |   90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 99 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_apic.c

diff --git a/Makefile.target b/Makefile.target
index 14c8fa1..0c2d865 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -236,7 +236,7 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
 obj-$(CONFIG_NO_XEN) += xen-stub.o
 
-obj-i386-$(CONFIG_XEN) += xen_platform.o
+obj-i386-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/pc.c b/hw/pc.c
index 67f0479..1f5aacb 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -42,6 +42,7 @@
 #include "sysbus.h"
 #include "sysemu.h"
 #include "kvm.h"
+#include "xen.h"
 #include "blockdev.h"
 #include "ui/qemu-spice.h"
 #include "memory.h"
@@ -891,9 +892,12 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
 
     if (kvm_irqchip_in_kernel()) {
         dev = qdev_create(NULL, "kvm-apic");
+    } else if (xen_enabled()) {
+        dev = qdev_create(NULL, "xen-apic");
     } else {
         dev = qdev_create(NULL, "apic");
     }
+
     qdev_prop_set_uint8(dev, "id", apic_id);
     qdev_prop_set_ptr(dev, "cpu_env", env);
     qdev_init_nofail(dev);
@@ -912,6 +916,10 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
         msi_supported = true;
     }
 
+    if (xen_enabled()) {
+        msi_supported = true;
+    }
+
     return dev;
 }
 
diff --git a/hw/xen_apic.c b/hw/xen_apic.c
new file mode 100644
index 0000000..1725ff6
--- /dev/null
+++ b/hw/xen_apic.c
@@ -0,0 +1,90 @@
+/*
+ * Xen basic APIC support
+ *
+ * Copyright (c) 2012 Citrix
+ *
+ * Authors:
+ *  Wei Liu <wei.liu2@citrix.com>
+ *
+ * This work is licensed under the terms of the GNU GPL version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+#include "hw/apic_internal.h"
+#include "hw/msi.h"
+#include "xen.h"
+
+static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t addr,
+                                  unsigned size)
+{
+    return ~(uint64_t)0;
+}
+
+static void xen_apic_mem_write(void *opaque, target_phys_addr_t addr,
+                               uint64_t data, unsigned size)
+{
+    if (size != sizeof(uint32_t)) {
+        fprintf(stderr, "Xen: APIC write data size = %d, invalid\n", size);
+        return;
+    }
+
+    xen_hvm_inject_msi(addr, data);
+}
+
+static const MemoryRegionOps xen_apic_io_ops = {
+    .read = xen_apic_mem_read,
+    .write = xen_apic_mem_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void xen_apic_init(APICCommonState *s)
+{
+    memory_region_init_io(&s->io_memory, &xen_apic_io_ops, s, "xen-apic-msi",
+                          MSI_SPACE_SIZE);
+}
+
+static void xen_apic_set_base(APICCommonState *s, uint64_t val)
+{
+}
+
+static void xen_apic_set_tpr(APICCommonState *s, uint8_t val)
+{
+}
+
+static uint8_t xen_apic_get_tpr(APICCommonState *s)
+{
+    return 0;
+}
+
+static void xen_apic_vapic_base_update(APICCommonState *s)
+{
+}
+
+static void xen_apic_external_nmi(APICCommonState *s)
+{
+}
+
+static void xen_apic_class_init(ObjectClass *klass, void *data)
+{
+    APICCommonClass *k = APIC_COMMON_CLASS(klass);
+
+    k->init = xen_apic_init;
+    k->set_base = xen_apic_set_base;
+    k->set_tpr = xen_apic_set_tpr;
+    k->get_tpr = xen_apic_get_tpr;
+    k->vapic_base_update = xen_apic_vapic_base_update;
+    k->external_nmi = xen_apic_external_nmi;
+}
+
+static TypeInfo xen_apic_info = {
+    .name = "xen-apic",
+    .parent = TYPE_APIC_COMMON,
+    .instance_size = sizeof(APICCommonState),
+    .class_init = xen_apic_class_init,
+};
+
+static void xen_apic_register_types(void)
+{
+    type_register_static(&xen_apic_info);
+}
+
+type_init(xen_apic_register_types)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:24:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHCX-0002BK-CR; Thu, 12 Apr 2012 10:24:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIHCW-0002BD-8x
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:24:28 +0000
Received: from [85.158.143.35:27846] by server-2.bemta-4.messagelabs.com id
	1A/8A-17550-B5DA68F4; Thu, 12 Apr 2012 10:24:27 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334226265!11704471!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7585 invoked from network); 12 Apr 2012 10:24:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-21.messagelabs.com with SMTP;
	12 Apr 2012 10:24:26 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77074377; Thu, 12 Apr 2012 12:24:25 +0200
Message-ID: <1334226256.22289.0.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Apr 2012 12:24:16 +0200
In-Reply-To: <1334053490.12209.176.camel@dagon.hellion.org.uk>
References: <1334053490.12209.176.camel@dagon.hellion.org.uk>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2384065376346378331=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2384065376346378331==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-n5LjIGad91JqeUfaXutf"


--=-n5LjIGad91JqeUfaXutf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-04-10 at 10:24 +0000, Ian Campbell wrote:=20
> Lots more DONE this week, still a few big ticket items or items with no
> progress (that I've noticed) please let me know if the status of
> anything has changed.
>
Here I am. :-)

> tools, blockers:
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * Safe fork vs. fd handling hooks. Involves API changes
>                 (Ian J, patches posted)
>               * locking/serialization, e.g., for domain creation. As of
>                 now,  nothing is provided for this purpose, and
>                 downstream toolstacks have to put their own mechanisms
>                 in place. E.g., xl uses a fcntl() lock around the whole
>                 process of domain creation. It should OTOH be libxl job
>                 to offer a proper set of hooks --placed at the proper
>                 spots during the domain creation process-- for the
>                 downstreams to fill with the proper callbacks. (Dario
>                 Faggioli)
>                       * Thinking to defer this until 4.3?
>
Here's the point. This was raised for the following main reasons:
1. xl holds a lock during domain creation for way too long
2. checking for free memory in xl when it is Xen that will actually=20
    allocate it after a while is prone to races (the classical TOCTTOU=20
    condition)

We thought both these things to be addressable by messing around with
locks, but a more careful analysis revealed we can't solve 2. in a sane
enough way by just doing that (i.e., messing with lock, moving it
around, etc.).

That being the case, yes, I think we can move this forward toward 4.3
without much problems, and I propose doing so. Thoughts?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)




--=-n5LjIGad91JqeUfaXutf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+GrVAACgkQk4XaBE3IOsSrbwCfei/qn2hNzgHm0QWSTBWCNwkD
X4QAn3BU3o+xxp1WwIgOcaHRg8b5lGBp
=jYl3
-----END PGP SIGNATURE-----

--=-n5LjIGad91JqeUfaXutf--



--===============2384065376346378331==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2384065376346378331==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 10:24:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHCX-0002BK-CR; Thu, 12 Apr 2012 10:24:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIHCW-0002BD-8x
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:24:28 +0000
Received: from [85.158.143.35:27846] by server-2.bemta-4.messagelabs.com id
	1A/8A-17550-B5DA68F4; Thu, 12 Apr 2012 10:24:27 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334226265!11704471!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7585 invoked from network); 12 Apr 2012 10:24:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-21.messagelabs.com with SMTP;
	12 Apr 2012 10:24:26 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77074377; Thu, 12 Apr 2012 12:24:25 +0200
Message-ID: <1334226256.22289.0.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Apr 2012 12:24:16 +0200
In-Reply-To: <1334053490.12209.176.camel@dagon.hellion.org.uk>
References: <1334053490.12209.176.camel@dagon.hellion.org.uk>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2384065376346378331=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2384065376346378331==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-n5LjIGad91JqeUfaXutf"


--=-n5LjIGad91JqeUfaXutf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-04-10 at 10:24 +0000, Ian Campbell wrote:=20
> Lots more DONE this week, still a few big ticket items or items with no
> progress (that I've noticed) please let me know if the status of
> anything has changed.
>
Here I am. :-)

> tools, blockers:
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * Safe fork vs. fd handling hooks. Involves API changes
>                 (Ian J, patches posted)
>               * locking/serialization, e.g., for domain creation. As of
>                 now,  nothing is provided for this purpose, and
>                 downstream toolstacks have to put their own mechanisms
>                 in place. E.g., xl uses a fcntl() lock around the whole
>                 process of domain creation. It should OTOH be libxl job
>                 to offer a proper set of hooks --placed at the proper
>                 spots during the domain creation process-- for the
>                 downstreams to fill with the proper callbacks. (Dario
>                 Faggioli)
>                       * Thinking to defer this until 4.3?
>
Here's the point. This was raised for the following main reasons:
1. xl holds a lock during domain creation for way too long
2. checking for free memory in xl when it is Xen that will actually=20
    allocate it after a while is prone to races (the classical TOCTTOU=20
    condition)

We thought both these things to be addressable by messing around with
locks, but a more careful analysis revealed we can't solve 2. in a sane
enough way by just doing that (i.e., messing with lock, moving it
around, etc.).

That being the case, yes, I think we can move this forward toward 4.3
without much problems, and I propose doing so. Thoughts?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)




--=-n5LjIGad91JqeUfaXutf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+GrVAACgkQk4XaBE3IOsSrbwCfei/qn2hNzgHm0QWSTBWCNwkD
X4QAn3BU3o+xxp1WwIgOcaHRg8b5lGBp
=jYl3
-----END PGP SIGNATURE-----

--=-n5LjIGad91JqeUfaXutf--



--===============2384065376346378331==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2384065376346378331==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 10:25:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHDZ-0002Fb-Qz; Thu, 12 Apr 2012 10:25:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIHDY-0002FR-43
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:25:32 +0000
Received: from [85.158.143.99:18875] by server-1.bemta-4.messagelabs.com id
	36/54-20925-B9DA68F4; Thu, 12 Apr 2012 10:25:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334226327!23319927!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19283 invoked from network); 12 Apr 2012 10:25:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:25:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190004003"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:25:27 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:25:26 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIHDS-0008Kc-18;
	Thu, 12 Apr 2012 11:25:26 +0100
Message-ID: <4F86AD6E.3050705@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:24:46 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
In-Reply-To: <7e76233448b02810f0ae.1334150272@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> Let the user specify the NUMA node affinity of a guest via the
> 'nodes=' config switch. Explicitly listing the intended target host
> nodes is required as of now.
>
> A valid setting will directly impact the node_affinity mask
> of the guest, i.e., it will change the behaviour of the low level
> memory allocator. On the other hand, this commit does not affect
> by any means how the guest's vCPUs are scheduled on the host's
> pCPUs.
I would probably break this into three separate patches, starting with 
the hypervisor, then libxc, then libxl, especially since they tend to 
have different maintainers and committers.
>
> TODO: * Better investigate and test interactions with cpupools.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -112,6 +112,15 @@ List of which cpus the guest is allowed
>   (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
>   will run on cpus 2 and 3).
>
> +=item B<nodes=[ NODE, NODE, ...]>
> +
> +List of the NUMA nodes of the host the guest should be considered
> +`affine` with. Being affine to a (set of) NUMA node(s) mainly means
> +the guest's memory is going to be allocated on those node(s).
> +
> +A list of nodes should be specified as follows: `nodes=["0", "3"]`
> +for the guest to be affine with nodes 0 and 3.
> +
Hmm, I think that using "affine" here is technically correct, and is 
what one would use if writing a research paper; but it's unusual to hear 
the word in more common English; it would be more common to hear someone 
describe a VM as "having affinity with".  How about something like this:

"The list of NUMA nodes the domain is considered to have affinity with.  
Memory from the guest will be allocated from these nodes."

(Technically you're also not supposed to end a sentence with a 
preposition, but I think "...with which the domain is considered to have 
affinity" is just to awkward.)

Also, is there a way to specify that the affinity to be to all nodes 
and/or based on the vcpu mask of the vcpus?
>   =item B<memory=MBYTES>
>
>   Start the guest with MBYTES megabytes of RAM.
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -110,6 +110,44 @@ int xc_domain_shutdown(xc_interface *xch
>   }
>
>
> +int xc_domain_node_affinity(xc_interface *xch,
> +                            uint32_t domid,
> +                            xc_nodemap_t node_affinity)
> +{
> +    DECLARE_DOMCTL;
> +    DECLARE_HYPERCALL_BUFFER(uint8_t, local);
> +    int ret = -1;
> +    int nodesize;
> +
> +    nodesize = xc_get_nodemap_size(xch);
> +    if (!nodesize)
> +    {
> +        PERROR("Could not get number of nodes");
> +        goto out;
> +    }
> +
> +    local = xc_hypercall_buffer_alloc(xch, local, nodesize);
> +    if ( local == NULL )
> +    {
> +        PERROR("Could not allocate memory for domain_node_affinity domctl hypercall");
> +        goto out;
> +    }
> +
> +    domctl.cmd = XEN_DOMCTL_node_affinity;
> +    domctl.domain = (domid_t)domid;
> +
> +    memcpy(local, node_affinity, nodesize);
> +    set_xen_guest_handle(domctl.u.node_affinity.nodemap.bitmap, local);
> +    domctl.u.node_affinity.nodemap.nr_elems = nodesize * 8;
> +
> +    ret = do_domctl(xch,&domctl);
> +
> +    xc_hypercall_buffer_free(xch, local);
> +
> + out:
> +    return ret;
> +}
> +
>   int xc_vcpu_setaffinity(xc_interface *xch,
>                           uint32_t domid,
>                           int vcpu,
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -520,6 +520,19 @@ int xc_watchdog(xc_interface *xch,
>                  uint32_t id,
>                  uint32_t timeout);
>
> +/**
> + * This function explicitly sets the affinity of a domain with the
> + * host NUMA nodes.
> + *
> + * @parm xch a handle to an open hypervisor interface.
> + * @parm domid the domain id in which vcpus are to be created.
> + * @parm node_affinity the map of the affine nodes.
> + * @return 0 on success, -1 on failure.
> + */
> +int xc_domain_node_affinity(xc_interface *xch,
> +                            uint32_t domind,
> +                            xc_nodemap_t node_affinity);
> +
Seems like it would be useful to have both a get and a set.
>   int xc_vcpu_setaffinity(xc_interface *xch,
>                           uint32_t domid,
>                           int vcpu,
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -20,7 +20,7 @@ def randomize_case(s):
>   def randomize_enum(e):
>       return random.choice([v.name for v in e.values])
>
> -handcoded = ["libxl_cpumap", "libxl_key_value_list",
> +handcoded = ["libxl_cpumap", "libxl_nodemap", "libxl_key_value_list",
>                "libxl_cpuid_policy_list", "libxl_file_reference",
>                "libxl_string_list"]
>
> @@ -119,6 +119,19 @@ static void libxl_cpumap_rand_init(libxl
>       }
>   }
>
> +static void libxl_nodemap_rand_init(libxl_nodemap *nodemap)
> +{
> +    int i;
> +    nodemap->size = rand() % 16;
> +    nodemap->map = calloc(nodemap->size, sizeof(*nodemap->map));
> +    libxl_for_each_node(i, *nodemap) {
> +        if (rand() % 2)
> +            libxl_nodemap_set(nodemap, i);
> +        else
> +            libxl_nodemap_reset(nodemap, i);
> +    }
> +}
> +
>   static void libxl_key_value_list_rand_init(libxl_key_value_list *pkvl)
>   {
>       int i, nr_kvp = rand() % 16;
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3082,6 +3082,16 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
>       return rc;
>   }
>
> +int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
> +                            libxl_nodemap *nodemap)
> +{
> +    if (xc_domain_node_affinity(ctx->xch, domid, nodemap->map)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
>   int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>   {
>       GC_INIT(ctx);
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -727,6 +727,8 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>                              libxl_cpumap *cpumap);
>   int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
>                                  unsigned int max_vcpus, libxl_cpumap *cpumap);
> +int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
> +                            libxl_nodemap *nodemap);
Hmm -- is there really no libxl_get_vcpuaffinity()?  That seems to be a 
missing component...
>   int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
>
>   libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -121,6 +121,12 @@ int libxl__domain_build_info_setdefault(
>           libxl_cpumap_set_any(&b_info->cpumap);
>       }
>
> +    if (!b_info->nodemap.size) {
> +        if (libxl_nodemap_alloc(CTX,&b_info->nodemap))
> +            return ERROR_NOMEM;
> +        libxl_nodemap_set_none(&b_info->nodemap);
> +    }
> +
>       if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
>           b_info->max_memkb = 32 * 1024;
>       if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -67,6 +67,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>       char *xs_domid, *con_domid;
>       xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>       libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,&info->cpumap);
> +    libxl_set_node_affinity(ctx, domid,&info->nodemap);
>       xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>       if (info->type == LIBXL_DOMAIN_TYPE_PV)
>           xc_domain_set_memmap_limit(ctx->xch, domid,
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -119,6 +119,26 @@ out:
>       return s;
>   }
>
> +yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand,
> +                                       libxl_nodemap *nodemap)
> +{
> +    yajl_gen_status s;
> +    int i;
> +
> +    s = yajl_gen_array_open(hand);
> +    if (s != yajl_gen_status_ok) goto out;
> +
> +    libxl_for_each_node(i, *nodemap) {
> +        if (libxl_nodemap_test(nodemap, i)) {
> +            s = yajl_gen_integer(hand, i);
> +            if (s != yajl_gen_status_ok) goto out;
> +        }
> +    }
> +    s = yajl_gen_array_close(hand);
> +out:
> +    return s;
> +}
> +
>   yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
>                                                 libxl_key_value_list *pkvl)
>   {
> diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h
> +++ b/tools/libxl/libxl_json.h
> @@ -27,6 +27,7 @@ yajl_gen_status libxl_domid_gen_json(yaj
>   yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
>   yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
>   yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
> +yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand, libxl_nodemap *p);
>   yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>                                                    libxl_cpuid_policy_list *p);
>   yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -11,6 +11,7 @@ libxl_domid = Builtin("domid", json_fn =
>   libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
>   libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
>   libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
> +libxl_nodemap = Builtin("nodemap", dispose_fn="libxl_nodemap_dispose", passby=PASS_BY_REFERENCE)
>   libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
>
>   libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
> @@ -233,6 +234,7 @@ libxl_domain_build_info = Struct("domain
>       ("max_vcpus",       integer),
>       ("cur_vcpus",       integer),
>       ("cpumap",          libxl_cpumap),
> +    ("nodemap",         libxl_nodemap),
>       ("tsc_mode",        libxl_tsc_mode),
>       ("max_memkb",       MemKB),
>       ("target_memkb",    MemKB),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -515,7 +515,7 @@ static void parse_config_data(const char
>       const char *buf;
>       long l;
>       XLU_Config *config;
> -    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> +    XLU_ConfigList *cpus, *nodes, *vbds, *nics, *pcis, *cvfbs, *cpuids;
>       int pci_power_mgmt = 0;
>       int pci_msitranslate = 1;
>       int pci_permissive = 0;
> @@ -628,6 +628,39 @@ static void parse_config_data(const char
>           free(buf2);
>       }
>
> +    if (!xlu_cfg_get_list (config, "nodes",&nodes, 0, 0)) {
> +        int i, n_nodes = 0;
> +
> +        if (libxl_nodemap_alloc(ctx,&b_info->nodemap)) {
> +            fprintf(stderr, "Unable to allocate nodemap\n");
> +            exit(1);
> +        }
> +
> +        libxl_nodemap_set_none(&b_info->nodemap);
> +        while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
> +            i = atoi(buf);
> +            if (!libxl_nodemap_node_valid(&b_info->nodemap, i)) {
> +                fprintf(stderr, "node %d illegal\n", i);
> +                exit(1);
> +            }
> +            libxl_nodemap_set(&b_info->nodemap, i);
> +            n_nodes++;
> +        }
> +
> +        if (n_nodes == 0)
> +            fprintf(stderr, "No valid node found: no affinity will be set\n");
> +    }
> +    else {
> +        /*
> +         * XXX What would a sane default be? I think doing nothing
> +         *     (i.e., relying on cpu-affinity/cpupool ==>  the current
> +         *     behavior) should be just fine.
> +         *     That would mean we're saying to the user "if you want us
> +         *     to take care of NUMA, please tell us, maybe just putting
> +         *     'nodes=auto', but tell us... otherwise we do as usual".
> +         */
I think that for this patch, doing nothing is fine (which means removing 
the whole else clause).  But once we have the auto placement, I think 
that "nodes=auto" should be the default.
> +    }
> +
>       if (!xlu_cfg_get_long (config, "memory",&l, 0)) {
>           b_info->max_memkb = l * 1024;
>           b_info->target_memkb = b_info->max_memkb;
> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -243,6 +243,18 @@ int attrib__libxl_cpumap_set(PyObject *v
>       return 0;
>   }
>
> +int attrib__libxl_nodemap_set(PyObject *v, libxl_nodemap *pptr)
> +{
> +    int i;
> +    long node;
> +
> +    for (i = 0; i<  PyList_Size(v); i++) {
> +        node = PyInt_AsLong(PyList_GetItem(v, i));
> +        libxl_nodemap_set(pptr, node);
> +    }
> +    return 0;
> +}
> +
>   int attrib__libxl_file_reference_set(PyObject *v, libxl_file_reference *pptr)
>   {
>       return genwrap__string_set(v,&pptr->path);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -222,6 +222,7 @@ struct domain *domain_create(
>
>       spin_lock_init(&d->node_affinity_lock);
>       d->node_affinity = NODE_MASK_ALL;
> +    d->has_node_affinity = 0;
>
>       spin_lock_init(&d->shutdown_lock);
>       d->shutdown_code = -1;
> @@ -337,7 +338,7 @@ void domain_update_node_affinity(struct
>   {
>       cpumask_var_t cpumask;
>       cpumask_var_t online_affinity;
> -    const cpumask_t *online;
> +    const cpumask_t *online = cpupool_online_cpumask(d->cpupool);
>       nodemask_t nodemask = NODE_MASK_NONE;
>       struct vcpu *v;
>       unsigned int node;
> @@ -350,9 +351,22 @@ void domain_update_node_affinity(struct
>           return;
>       }
>
> -    online = cpupool_online_cpumask(d->cpupool);
> +    spin_lock(&d->node_affinity_lock);
>
> -    spin_lock(&d->node_affinity_lock);
> +    /*
> +     * If someone explicitly told us our NUMA affinity, avoid messing
> +     * that up. Notice, however, that vcpu affinity is still what
> +     * drives all scheduling decisions.
> +     *
> +     * XXX I'm quite sure this is fine wrt to the various v->cpu_affinity
> +     *     (at least, that was the intended design!). Could it be useful
> +     *     to cross-check d->node_affinity against `online`? The basic
> +     *     idea here is "Hey, if you shoot yourself in the foot... You've
> +     *     shot in the foot!", but, you know...
> +     */
> +    if ( d->has_node_affinity )
> +        goto out;
> +
>
>       for_each_vcpu ( d, v )
>       {
> @@ -365,6 +379,8 @@ void domain_update_node_affinity(struct
>               node_set(node, nodemask);
>
>       d->node_affinity = nodemask;
> +
> +out:
>       spin_unlock(&d->node_affinity_lock);
>
>       free_cpumask_var(online_affinity);
> @@ -372,6 +388,31 @@ void domain_update_node_affinity(struct
>   }
>
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
> +{
> +    spin_lock(&d->node_affinity_lock);
> +
> +    /*
> +     * Being/becoming affine to _no_ nodes is not going to work,
> +     * let's take it as the `reset node affinity` command.
> +     */
> +    if ( nodes_empty(*affinity) )
> +    {
> +        d->has_node_affinity = 0;
> +        spin_unlock(&d->node_affinity_lock);
> +        domain_update_node_affinity(d);
> +        return 0;
> +    }
> +
> +    d->has_node_affinity = 1;
> +    d->node_affinity = *affinity;
> +
> +    spin_unlock(&d->node_affinity_lock);
> +
> +    return 0;
> +}
> +
> +
>   struct domain *get_domain_by_id(domid_t dom)
>   {
>       struct domain *d;
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -621,6 +621,27 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>       }
>       break;
>
> +    case XEN_DOMCTL_node_affinity:
> +    {
> +        domid_t dom = op->domain;
> +        struct domain *d = rcu_lock_domain_by_id(dom);
> +        nodemask_t new_affinity;
> +
> +        ret = -ESRCH;
> +        if ( d == NULL )
> +            break;
> +
> +        /* XXX We need an xsm_* for this I guess, right? */
Yes. :-)
> +
> +        ret = xenctl_nodemap_to_nodemask(&new_affinity,
> +&op->u.node_affinity.nodemap);
> +        if ( !ret )
> +            ret = domain_set_node_affinity(d,&new_affinity);
> +
> +        rcu_unlock_domain(d);
> +    }
> +    break;
> +
>       case XEN_DOMCTL_setvcpuaffinity:
>       case XEN_DOMCTL_getvcpuaffinity:
>       {
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -217,6 +217,14 @@ static void cpuset_print(char *set, int
>       *set++ = '\0';
>   }
>
> +static void nodeset_print(char *set, int size, const nodemask_t *mask)
> +{
> +    *set++ = '[';
> +    set += nodelist_scnprintf(set, size-2, mask);
> +    *set++ = ']';
> +    *set++ = '\0';
> +}
> +
>   static void periodic_timer_print(char *str, int size, uint64_t period)
>   {
>       if ( period == 0 )
> @@ -272,6 +280,9 @@ static void dump_domains(unsigned char k
>
>           dump_pageframe_info(d);
>
> +        nodeset_print(tmpstr, sizeof(tmpstr),&d->node_affinity);
> +        printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr);
> +
>           printk("VCPU information and callbacks for domain %u:\n",
>                  d->domain_id);
>           for_each_vcpu ( d, v )
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -278,6 +278,15 @@ typedef struct xen_domctl_getvcpuinfo xe
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
>
>
> +/* Set the NUMA node(s) with which the guest is `affine`. */
> +/* XEN_DOMCTL_node_affinity */
> +struct xen_domctl_node_affinity {
> +    struct xenctl_map nodemap;   /* IN */
> +};
> +typedef struct xen_domctl_node_affinity xen_domctl_node_affinity_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_node_affinity_t);
> +
> +
>   /* Get/set which physical cpus a vcpu can execute on. */
>   /* XEN_DOMCTL_setvcpuaffinity */
>   /* XEN_DOMCTL_getvcpuaffinity */
> @@ -914,6 +923,7 @@ struct xen_domctl {
>   #define XEN_DOMCTL_set_access_required           64
>   #define XEN_DOMCTL_audit_p2m                     65
>   #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_node_affinity                 67
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -927,6 +937,7 @@ struct xen_domctl {
>           struct xen_domctl_getpageframeinfo  getpageframeinfo;
>           struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
>           struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
> +        struct xen_domctl_node_affinity     node_affinity;
>           struct xen_domctl_vcpuaffinity      vcpuaffinity;
>           struct xen_domctl_shadow_op         shadow_op;
>           struct xen_domctl_max_mem           max_mem;
> diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
> --- a/xen/include/xen/nodemask.h
> +++ b/xen/include/xen/nodemask.h
> @@ -8,8 +8,9 @@
>    * See detailed comments in the file linux/bitmap.h describing the
>    * data type on which these nodemasks are based.
>    *
> - * For details of nodemask_scnprintf() and nodemask_parse(),
> - * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c.
> + * For details of nodemask_scnprintf(), nodelist_scnpintf() and
> + * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse()
> + * in lib/bitmap.c.
>    *
>    * The available nodemask operations are:
>    *
> @@ -48,6 +49,7 @@
>    * unsigned long *nodes_addr(mask)     Array of unsigned long's in mask
>    *
>    * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
> + * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing
>    * int nodemask_parse(ubuf, ulen, mask)        Parse ascii string as nodemask
>    *
>    * for_each_node_mask(node, mask)      for-loop node over mask
> @@ -280,6 +282,14 @@ static inline int __first_unset_node(con
>
>   #define nodes_addr(src) ((src).bits)
>
> +#define nodelist_scnprintf(buf, len, src) \
> +                       __nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES)
> +static inline int __nodelist_scnprintf(char *buf, int len,
> +                                       const nodemask_t *srcp, int nbits)
> +{
> +       return bitmap_scnlistprintf(buf, len, srcp->bits, nbits);
> +}
> +
>   #if 0
>   #define nodemask_scnprintf(buf, len, src) \
>                          __nodemask_scnprintf((buf), (len),&(src), MAX_NUMNODES)
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -346,8 +346,12 @@ struct domain
>       /* Various mem_events */
>       struct mem_event_per_domain *mem_event;
>
> -    /* Currently computed from union of all vcpu cpu-affinity masks. */
> +    /*
> +     * Can be specified by the user. If that is not the case, it is
> +     * computed from the union of all the vcpu cpu-affinity masks.
> +     */
>       nodemask_t node_affinity;
> +    int has_node_affinity;
There's something that seems a bit clunky about this; but I can't really 
think of a better way.  At every least I'd change the name of the 
element here to something more descriptive; perhaps "auto_node_affinity" 
(which would invert the meaning)?
>       unsigned int last_alloc_node;
>       spinlock_t node_affinity_lock;
>   };
> @@ -416,6 +420,7 @@ static inline void get_knownalive_domain
>       ASSERT(!(atomic_read(&d->refcnt)&  DOMAIN_DESTROYED));
>   }
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
>   void domain_update_node_affinity(struct domain *d);
>
>   struct domain *domain_create(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:25:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHDZ-0002Fb-Qz; Thu, 12 Apr 2012 10:25:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIHDY-0002FR-43
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:25:32 +0000
Received: from [85.158.143.99:18875] by server-1.bemta-4.messagelabs.com id
	36/54-20925-B9DA68F4; Thu, 12 Apr 2012 10:25:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334226327!23319927!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19283 invoked from network); 12 Apr 2012 10:25:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:25:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190004003"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:25:27 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:25:26 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIHDS-0008Kc-18;
	Thu, 12 Apr 2012 11:25:26 +0100
Message-ID: <4F86AD6E.3050705@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:24:46 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
In-Reply-To: <7e76233448b02810f0ae.1334150272@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> Let the user specify the NUMA node affinity of a guest via the
> 'nodes=' config switch. Explicitly listing the intended target host
> nodes is required as of now.
>
> A valid setting will directly impact the node_affinity mask
> of the guest, i.e., it will change the behaviour of the low level
> memory allocator. On the other hand, this commit does not affect
> by any means how the guest's vCPUs are scheduled on the host's
> pCPUs.
I would probably break this into three separate patches, starting with 
the hypervisor, then libxc, then libxl, especially since they tend to 
have different maintainers and committers.
>
> TODO: * Better investigate and test interactions with cpupools.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -112,6 +112,15 @@ List of which cpus the guest is allowed
>   (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
>   will run on cpus 2 and 3).
>
> +=item B<nodes=[ NODE, NODE, ...]>
> +
> +List of the NUMA nodes of the host the guest should be considered
> +`affine` with. Being affine to a (set of) NUMA node(s) mainly means
> +the guest's memory is going to be allocated on those node(s).
> +
> +A list of nodes should be specified as follows: `nodes=["0", "3"]`
> +for the guest to be affine with nodes 0 and 3.
> +
Hmm, I think that using "affine" here is technically correct, and is 
what one would use if writing a research paper; but it's unusual to hear 
the word in more common English; it would be more common to hear someone 
describe a VM as "having affinity with".  How about something like this:

"The list of NUMA nodes the domain is considered to have affinity with.  
Memory from the guest will be allocated from these nodes."

(Technically you're also not supposed to end a sentence with a 
preposition, but I think "...with which the domain is considered to have 
affinity" is just to awkward.)

Also, is there a way to specify that the affinity to be to all nodes 
and/or based on the vcpu mask of the vcpus?
>   =item B<memory=MBYTES>
>
>   Start the guest with MBYTES megabytes of RAM.
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -110,6 +110,44 @@ int xc_domain_shutdown(xc_interface *xch
>   }
>
>
> +int xc_domain_node_affinity(xc_interface *xch,
> +                            uint32_t domid,
> +                            xc_nodemap_t node_affinity)
> +{
> +    DECLARE_DOMCTL;
> +    DECLARE_HYPERCALL_BUFFER(uint8_t, local);
> +    int ret = -1;
> +    int nodesize;
> +
> +    nodesize = xc_get_nodemap_size(xch);
> +    if (!nodesize)
> +    {
> +        PERROR("Could not get number of nodes");
> +        goto out;
> +    }
> +
> +    local = xc_hypercall_buffer_alloc(xch, local, nodesize);
> +    if ( local == NULL )
> +    {
> +        PERROR("Could not allocate memory for domain_node_affinity domctl hypercall");
> +        goto out;
> +    }
> +
> +    domctl.cmd = XEN_DOMCTL_node_affinity;
> +    domctl.domain = (domid_t)domid;
> +
> +    memcpy(local, node_affinity, nodesize);
> +    set_xen_guest_handle(domctl.u.node_affinity.nodemap.bitmap, local);
> +    domctl.u.node_affinity.nodemap.nr_elems = nodesize * 8;
> +
> +    ret = do_domctl(xch,&domctl);
> +
> +    xc_hypercall_buffer_free(xch, local);
> +
> + out:
> +    return ret;
> +}
> +
>   int xc_vcpu_setaffinity(xc_interface *xch,
>                           uint32_t domid,
>                           int vcpu,
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -520,6 +520,19 @@ int xc_watchdog(xc_interface *xch,
>                  uint32_t id,
>                  uint32_t timeout);
>
> +/**
> + * This function explicitly sets the affinity of a domain with the
> + * host NUMA nodes.
> + *
> + * @parm xch a handle to an open hypervisor interface.
> + * @parm domid the domain id in which vcpus are to be created.
> + * @parm node_affinity the map of the affine nodes.
> + * @return 0 on success, -1 on failure.
> + */
> +int xc_domain_node_affinity(xc_interface *xch,
> +                            uint32_t domind,
> +                            xc_nodemap_t node_affinity);
> +
Seems like it would be useful to have both a get and a set.
>   int xc_vcpu_setaffinity(xc_interface *xch,
>                           uint32_t domid,
>                           int vcpu,
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -20,7 +20,7 @@ def randomize_case(s):
>   def randomize_enum(e):
>       return random.choice([v.name for v in e.values])
>
> -handcoded = ["libxl_cpumap", "libxl_key_value_list",
> +handcoded = ["libxl_cpumap", "libxl_nodemap", "libxl_key_value_list",
>                "libxl_cpuid_policy_list", "libxl_file_reference",
>                "libxl_string_list"]
>
> @@ -119,6 +119,19 @@ static void libxl_cpumap_rand_init(libxl
>       }
>   }
>
> +static void libxl_nodemap_rand_init(libxl_nodemap *nodemap)
> +{
> +    int i;
> +    nodemap->size = rand() % 16;
> +    nodemap->map = calloc(nodemap->size, sizeof(*nodemap->map));
> +    libxl_for_each_node(i, *nodemap) {
> +        if (rand() % 2)
> +            libxl_nodemap_set(nodemap, i);
> +        else
> +            libxl_nodemap_reset(nodemap, i);
> +    }
> +}
> +
>   static void libxl_key_value_list_rand_init(libxl_key_value_list *pkvl)
>   {
>       int i, nr_kvp = rand() % 16;
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3082,6 +3082,16 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
>       return rc;
>   }
>
> +int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
> +                            libxl_nodemap *nodemap)
> +{
> +    if (xc_domain_node_affinity(ctx->xch, domid, nodemap->map)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
>   int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>   {
>       GC_INIT(ctx);
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -727,6 +727,8 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>                              libxl_cpumap *cpumap);
>   int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
>                                  unsigned int max_vcpus, libxl_cpumap *cpumap);
> +int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
> +                            libxl_nodemap *nodemap);
Hmm -- is there really no libxl_get_vcpuaffinity()?  That seems to be a 
missing component...
>   int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
>
>   libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -121,6 +121,12 @@ int libxl__domain_build_info_setdefault(
>           libxl_cpumap_set_any(&b_info->cpumap);
>       }
>
> +    if (!b_info->nodemap.size) {
> +        if (libxl_nodemap_alloc(CTX,&b_info->nodemap))
> +            return ERROR_NOMEM;
> +        libxl_nodemap_set_none(&b_info->nodemap);
> +    }
> +
>       if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
>           b_info->max_memkb = 32 * 1024;
>       if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -67,6 +67,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>       char *xs_domid, *con_domid;
>       xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>       libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,&info->cpumap);
> +    libxl_set_node_affinity(ctx, domid,&info->nodemap);
>       xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>       if (info->type == LIBXL_DOMAIN_TYPE_PV)
>           xc_domain_set_memmap_limit(ctx->xch, domid,
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -119,6 +119,26 @@ out:
>       return s;
>   }
>
> +yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand,
> +                                       libxl_nodemap *nodemap)
> +{
> +    yajl_gen_status s;
> +    int i;
> +
> +    s = yajl_gen_array_open(hand);
> +    if (s != yajl_gen_status_ok) goto out;
> +
> +    libxl_for_each_node(i, *nodemap) {
> +        if (libxl_nodemap_test(nodemap, i)) {
> +            s = yajl_gen_integer(hand, i);
> +            if (s != yajl_gen_status_ok) goto out;
> +        }
> +    }
> +    s = yajl_gen_array_close(hand);
> +out:
> +    return s;
> +}
> +
>   yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
>                                                 libxl_key_value_list *pkvl)
>   {
> diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h
> +++ b/tools/libxl/libxl_json.h
> @@ -27,6 +27,7 @@ yajl_gen_status libxl_domid_gen_json(yaj
>   yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
>   yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
>   yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
> +yajl_gen_status libxl_nodemap_gen_json(yajl_gen hand, libxl_nodemap *p);
>   yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>                                                    libxl_cpuid_policy_list *p);
>   yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -11,6 +11,7 @@ libxl_domid = Builtin("domid", json_fn =
>   libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
>   libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
>   libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
> +libxl_nodemap = Builtin("nodemap", dispose_fn="libxl_nodemap_dispose", passby=PASS_BY_REFERENCE)
>   libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
>
>   libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
> @@ -233,6 +234,7 @@ libxl_domain_build_info = Struct("domain
>       ("max_vcpus",       integer),
>       ("cur_vcpus",       integer),
>       ("cpumap",          libxl_cpumap),
> +    ("nodemap",         libxl_nodemap),
>       ("tsc_mode",        libxl_tsc_mode),
>       ("max_memkb",       MemKB),
>       ("target_memkb",    MemKB),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -515,7 +515,7 @@ static void parse_config_data(const char
>       const char *buf;
>       long l;
>       XLU_Config *config;
> -    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> +    XLU_ConfigList *cpus, *nodes, *vbds, *nics, *pcis, *cvfbs, *cpuids;
>       int pci_power_mgmt = 0;
>       int pci_msitranslate = 1;
>       int pci_permissive = 0;
> @@ -628,6 +628,39 @@ static void parse_config_data(const char
>           free(buf2);
>       }
>
> +    if (!xlu_cfg_get_list (config, "nodes",&nodes, 0, 0)) {
> +        int i, n_nodes = 0;
> +
> +        if (libxl_nodemap_alloc(ctx,&b_info->nodemap)) {
> +            fprintf(stderr, "Unable to allocate nodemap\n");
> +            exit(1);
> +        }
> +
> +        libxl_nodemap_set_none(&b_info->nodemap);
> +        while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
> +            i = atoi(buf);
> +            if (!libxl_nodemap_node_valid(&b_info->nodemap, i)) {
> +                fprintf(stderr, "node %d illegal\n", i);
> +                exit(1);
> +            }
> +            libxl_nodemap_set(&b_info->nodemap, i);
> +            n_nodes++;
> +        }
> +
> +        if (n_nodes == 0)
> +            fprintf(stderr, "No valid node found: no affinity will be set\n");
> +    }
> +    else {
> +        /*
> +         * XXX What would a sane default be? I think doing nothing
> +         *     (i.e., relying on cpu-affinity/cpupool ==>  the current
> +         *     behavior) should be just fine.
> +         *     That would mean we're saying to the user "if you want us
> +         *     to take care of NUMA, please tell us, maybe just putting
> +         *     'nodes=auto', but tell us... otherwise we do as usual".
> +         */
I think that for this patch, doing nothing is fine (which means removing 
the whole else clause).  But once we have the auto placement, I think 
that "nodes=auto" should be the default.
> +    }
> +
>       if (!xlu_cfg_get_long (config, "memory",&l, 0)) {
>           b_info->max_memkb = l * 1024;
>           b_info->target_memkb = b_info->max_memkb;
> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -243,6 +243,18 @@ int attrib__libxl_cpumap_set(PyObject *v
>       return 0;
>   }
>
> +int attrib__libxl_nodemap_set(PyObject *v, libxl_nodemap *pptr)
> +{
> +    int i;
> +    long node;
> +
> +    for (i = 0; i<  PyList_Size(v); i++) {
> +        node = PyInt_AsLong(PyList_GetItem(v, i));
> +        libxl_nodemap_set(pptr, node);
> +    }
> +    return 0;
> +}
> +
>   int attrib__libxl_file_reference_set(PyObject *v, libxl_file_reference *pptr)
>   {
>       return genwrap__string_set(v,&pptr->path);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -222,6 +222,7 @@ struct domain *domain_create(
>
>       spin_lock_init(&d->node_affinity_lock);
>       d->node_affinity = NODE_MASK_ALL;
> +    d->has_node_affinity = 0;
>
>       spin_lock_init(&d->shutdown_lock);
>       d->shutdown_code = -1;
> @@ -337,7 +338,7 @@ void domain_update_node_affinity(struct
>   {
>       cpumask_var_t cpumask;
>       cpumask_var_t online_affinity;
> -    const cpumask_t *online;
> +    const cpumask_t *online = cpupool_online_cpumask(d->cpupool);
>       nodemask_t nodemask = NODE_MASK_NONE;
>       struct vcpu *v;
>       unsigned int node;
> @@ -350,9 +351,22 @@ void domain_update_node_affinity(struct
>           return;
>       }
>
> -    online = cpupool_online_cpumask(d->cpupool);
> +    spin_lock(&d->node_affinity_lock);
>
> -    spin_lock(&d->node_affinity_lock);
> +    /*
> +     * If someone explicitly told us our NUMA affinity, avoid messing
> +     * that up. Notice, however, that vcpu affinity is still what
> +     * drives all scheduling decisions.
> +     *
> +     * XXX I'm quite sure this is fine wrt to the various v->cpu_affinity
> +     *     (at least, that was the intended design!). Could it be useful
> +     *     to cross-check d->node_affinity against `online`? The basic
> +     *     idea here is "Hey, if you shoot yourself in the foot... You've
> +     *     shot in the foot!", but, you know...
> +     */
> +    if ( d->has_node_affinity )
> +        goto out;
> +
>
>       for_each_vcpu ( d, v )
>       {
> @@ -365,6 +379,8 @@ void domain_update_node_affinity(struct
>               node_set(node, nodemask);
>
>       d->node_affinity = nodemask;
> +
> +out:
>       spin_unlock(&d->node_affinity_lock);
>
>       free_cpumask_var(online_affinity);
> @@ -372,6 +388,31 @@ void domain_update_node_affinity(struct
>   }
>
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
> +{
> +    spin_lock(&d->node_affinity_lock);
> +
> +    /*
> +     * Being/becoming affine to _no_ nodes is not going to work,
> +     * let's take it as the `reset node affinity` command.
> +     */
> +    if ( nodes_empty(*affinity) )
> +    {
> +        d->has_node_affinity = 0;
> +        spin_unlock(&d->node_affinity_lock);
> +        domain_update_node_affinity(d);
> +        return 0;
> +    }
> +
> +    d->has_node_affinity = 1;
> +    d->node_affinity = *affinity;
> +
> +    spin_unlock(&d->node_affinity_lock);
> +
> +    return 0;
> +}
> +
> +
>   struct domain *get_domain_by_id(domid_t dom)
>   {
>       struct domain *d;
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -621,6 +621,27 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>       }
>       break;
>
> +    case XEN_DOMCTL_node_affinity:
> +    {
> +        domid_t dom = op->domain;
> +        struct domain *d = rcu_lock_domain_by_id(dom);
> +        nodemask_t new_affinity;
> +
> +        ret = -ESRCH;
> +        if ( d == NULL )
> +            break;
> +
> +        /* XXX We need an xsm_* for this I guess, right? */
Yes. :-)
> +
> +        ret = xenctl_nodemap_to_nodemask(&new_affinity,
> +&op->u.node_affinity.nodemap);
> +        if ( !ret )
> +            ret = domain_set_node_affinity(d,&new_affinity);
> +
> +        rcu_unlock_domain(d);
> +    }
> +    break;
> +
>       case XEN_DOMCTL_setvcpuaffinity:
>       case XEN_DOMCTL_getvcpuaffinity:
>       {
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -217,6 +217,14 @@ static void cpuset_print(char *set, int
>       *set++ = '\0';
>   }
>
> +static void nodeset_print(char *set, int size, const nodemask_t *mask)
> +{
> +    *set++ = '[';
> +    set += nodelist_scnprintf(set, size-2, mask);
> +    *set++ = ']';
> +    *set++ = '\0';
> +}
> +
>   static void periodic_timer_print(char *str, int size, uint64_t period)
>   {
>       if ( period == 0 )
> @@ -272,6 +280,9 @@ static void dump_domains(unsigned char k
>
>           dump_pageframe_info(d);
>
> +        nodeset_print(tmpstr, sizeof(tmpstr),&d->node_affinity);
> +        printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr);
> +
>           printk("VCPU information and callbacks for domain %u:\n",
>                  d->domain_id);
>           for_each_vcpu ( d, v )
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -278,6 +278,15 @@ typedef struct xen_domctl_getvcpuinfo xe
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
>
>
> +/* Set the NUMA node(s) with which the guest is `affine`. */
> +/* XEN_DOMCTL_node_affinity */
> +struct xen_domctl_node_affinity {
> +    struct xenctl_map nodemap;   /* IN */
> +};
> +typedef struct xen_domctl_node_affinity xen_domctl_node_affinity_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_node_affinity_t);
> +
> +
>   /* Get/set which physical cpus a vcpu can execute on. */
>   /* XEN_DOMCTL_setvcpuaffinity */
>   /* XEN_DOMCTL_getvcpuaffinity */
> @@ -914,6 +923,7 @@ struct xen_domctl {
>   #define XEN_DOMCTL_set_access_required           64
>   #define XEN_DOMCTL_audit_p2m                     65
>   #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_node_affinity                 67
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -927,6 +937,7 @@ struct xen_domctl {
>           struct xen_domctl_getpageframeinfo  getpageframeinfo;
>           struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
>           struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
> +        struct xen_domctl_node_affinity     node_affinity;
>           struct xen_domctl_vcpuaffinity      vcpuaffinity;
>           struct xen_domctl_shadow_op         shadow_op;
>           struct xen_domctl_max_mem           max_mem;
> diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
> --- a/xen/include/xen/nodemask.h
> +++ b/xen/include/xen/nodemask.h
> @@ -8,8 +8,9 @@
>    * See detailed comments in the file linux/bitmap.h describing the
>    * data type on which these nodemasks are based.
>    *
> - * For details of nodemask_scnprintf() and nodemask_parse(),
> - * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c.
> + * For details of nodemask_scnprintf(), nodelist_scnpintf() and
> + * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse()
> + * in lib/bitmap.c.
>    *
>    * The available nodemask operations are:
>    *
> @@ -48,6 +49,7 @@
>    * unsigned long *nodes_addr(mask)     Array of unsigned long's in mask
>    *
>    * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
> + * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing
>    * int nodemask_parse(ubuf, ulen, mask)        Parse ascii string as nodemask
>    *
>    * for_each_node_mask(node, mask)      for-loop node over mask
> @@ -280,6 +282,14 @@ static inline int __first_unset_node(con
>
>   #define nodes_addr(src) ((src).bits)
>
> +#define nodelist_scnprintf(buf, len, src) \
> +                       __nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES)
> +static inline int __nodelist_scnprintf(char *buf, int len,
> +                                       const nodemask_t *srcp, int nbits)
> +{
> +       return bitmap_scnlistprintf(buf, len, srcp->bits, nbits);
> +}
> +
>   #if 0
>   #define nodemask_scnprintf(buf, len, src) \
>                          __nodemask_scnprintf((buf), (len),&(src), MAX_NUMNODES)
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -346,8 +346,12 @@ struct domain
>       /* Various mem_events */
>       struct mem_event_per_domain *mem_event;
>
> -    /* Currently computed from union of all vcpu cpu-affinity masks. */
> +    /*
> +     * Can be specified by the user. If that is not the case, it is
> +     * computed from the union of all the vcpu cpu-affinity masks.
> +     */
>       nodemask_t node_affinity;
> +    int has_node_affinity;
There's something that seems a bit clunky about this; but I can't really 
think of a better way.  At every least I'd change the name of the 
element here to something more descriptive; perhaps "auto_node_affinity" 
(which would invert the meaning)?
>       unsigned int last_alloc_node;
>       spinlock_t node_affinity_lock;
>   };
> @@ -416,6 +420,7 @@ static inline void get_knownalive_domain
>       ASSERT(!(atomic_read(&d->refcnt)&  DOMAIN_DESTROYED));
>   }
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
>   void domain_update_node_affinity(struct domain *d);
>
>   struct domain *domain_create(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:30:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHI7-0002Xx-PO; Thu, 12 Apr 2012 10:30:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIHI5-0002Xn-BS
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:30:13 +0000
Received: from [85.158.143.35:26905] by server-2.bemta-4.messagelabs.com id
	A5/E4-17550-4BEA68F4; Thu, 12 Apr 2012 10:30:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334226609!12092865!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28078 invoked from network); 12 Apr 2012 10:30:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="24090118"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:30:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:30:09 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIHI0-0008Oo-LB;
	Thu, 12 Apr 2012 11:30:08 +0100
Message-ID: <4F86AE89.7020801@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:29:29 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<64547b45cb112a35d3a2.1334150273@Solace>
In-Reply-To: <64547b45cb112a35d3a2.1334150273@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10 [RFC]] xl: Allow user to set or
 change node affinity on-line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> For feature parity with vcpu affinity, allow for specifying
> node affinity not only at domain creation time, but at run-time
> too.
>
> Of course this is not going to be equally effective, as it will
> only affect future memory allocations without touching what's
> already there. However, in future we might want to change this,
> and use this as an interface for sort-of manual "domain node
> migration".
I think this is a good idea.

I think if you take my suggestion to rework the previous patch into 
hypervisor, libxc, and libxl components, you should also move the xl 
stuff out of that patch and into this one (so that the xl and libxl 
changes relating to node affinity are each in their own patches).
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
>
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -556,6 +556,26 @@ different run state is appropriate.  Pin
>   this, by ensuring certain VCPUs can only run on certain physical
>   CPUs.
>
> +=item B<node-affinity>  I<domain-id>  I<nodes>
> +
> +Set the NUMA node affinity for the domain, i.e., the set of NUMA
> +nodes of the host from which the memory of the domain will be
> +allocated. More specificallly, the domain's memory will be split
> +in equal (well, as equal as possible) parts among all the nodes
> +it is affine with, The keyword B<all>  can be used to have the
> +domain affine to all NUMA nodes in the host.
> +
> +Normally NUMA node affinity of a domain is automatically computed
> +from its VCPU affinity. The default behaviour is to have it equal
> +to all the nodes the PCPUs onto which the VCPUs of the domain are
> +pinned belong to. Manually specifying it can be used to restrict
> +this to a specific subset of the host NUMA nodes, for improved
> +locality of memory accesses by the domain. Notice, however, that
> +this will not affect the memory that has already been allocated.
> +For having the full amount of memory allocated on specific node(s)
> +at domain creation time, the domain's configuration file is what
> +should be used.
> +
>   =item B<vncviewer>  [I<OPTIONS>] I<domain-id>
>
>   Attach to domain's VNC server, forking a vncviewer process.
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -442,7 +442,7 @@ void libxl_map_dispose(struct libxl_map
>       free(map->map);
>   }
>
> -static int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
> +int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
>   {
>       int sz;
>
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -64,6 +64,7 @@ int libxl_devid_to_device_nic(libxl_ctx
>   int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
>                                  libxl_device_disk *disk);
>
> +int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems);
>   int libxl_map_test(struct libxl_map *map, int elem);
>   void libxl_map_set(struct libxl_map *map, int elem);
>   void libxl_map_reset(struct libxl_map *map, int elem);
> @@ -79,6 +80,10 @@ static inline int libxl_map_elem_valid(s
>   {
>       return elem>= 0&&  elem<  (map->size * 8);
>   }
> +#define libxl_for_each_elem(v, m) for (v = 0; v<  (m).size * 8; v++)
> +#define libxl_for_each_set_elem(v, m) for (v = 0; v<  (m).size * 8; v++) \
> +                                              if (libxl_map_test(&(m), v))
> +
>
>   int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
>   static inline int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
> diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
> --- a/tools/libxl/xl.h
> +++ b/tools/libxl/xl.h
> @@ -54,6 +54,7 @@ int main_config_update(int argc, char **
>   int main_button_press(int argc, char **argv);
>   int main_vcpupin(int argc, char **argv);
>   int main_vcpuset(int argc, char **argv);
> +int main_nodeaffinity(int argc, char **argv);
>   int main_memmax(int argc, char **argv);
>   int main_memset(int argc, char **argv);
>   int main_sched_credit(int argc, char **argv);
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -448,65 +448,75 @@ static void split_string_into_string_lis
>       free(s);
>   }
>
> -static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +static int affinity_parse(char *str, struct libxl_map *map, int n_elems)
>   {
> -    libxl_cpumap exclude_cpumap;
> -    uint32_t cpuida, cpuidb;
> +    struct libxl_map exclude_map;
> +    uint32_t stra, strb;
>       char *endptr, *toka, *tokb, *saveptr = NULL;
> -    int i, rc = 0, rmcpu;
> -
> -    if (!strcmp(cpu, "all")) {
> -        libxl_cpumap_set_any(cpumap);
> +    int i, rc = 0, rmelem;
> +
> +    if (!strcmp(str, "all")) {
> +        libxl_map_set_any(map);
>           return 0;
>       }
>
> -    if (libxl_cpumap_alloc(ctx,&exclude_cpumap)) {
> -        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> +    if (libxl_map_alloc(ctx,&exclude_map, n_elems)) {
> +        fprintf(stderr, "Error: Failed to allocate libxl_map.\n");
>           return ENOMEM;
>       }
>
> -    for (toka = strtok_r(cpu, ",",&saveptr); toka;
> +    for (toka = strtok_r(str, ",",&saveptr); toka;
>            toka = strtok_r(NULL, ",",&saveptr)) {
> -        rmcpu = 0;
> +        rmelem = 0;
>           if (*toka == '^') {
>               /* This (These) Cpu(s) will be removed from the map */
>               toka++;
> -            rmcpu = 1;
> +            rmelem = 1;
>           }
>           /* Extract a valid (range of) cpu(s) */
> -        cpuida = cpuidb = strtoul(toka,&endptr, 10);
> +        stra = strb = strtoul(toka,&endptr, 10);
>           if (endptr == toka) {
>               fprintf(stderr, "Error: Invalid argument.\n");
>               rc = EINVAL;
> -            goto vcpp_out;
> +            goto afp_out;
>           }
>           if (*endptr == '-') {
>               tokb = endptr + 1;
> -            cpuidb = strtoul(tokb,&endptr, 10);
> -            if (endptr == tokb || cpuida>  cpuidb) {
> +            strb = strtoul(tokb,&endptr, 10);
> +            if (endptr == tokb || stra>  strb) {
>                   fprintf(stderr, "Error: Invalid argument.\n");
>                   rc = EINVAL;
> -                goto vcpp_out;
> +                goto afp_out;
>               }
>           }
> -        while (cpuida<= cpuidb) {
> -            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
> -                         libxl_cpumap_set(&exclude_cpumap, cpuida);
> -            cpuida++;
> +        while (stra<= strb) {
> +            rmelem == 0 ? libxl_map_set(map, stra) :
> +                          libxl_map_set(&exclude_map, stra);
> +            stra++;
>           }
>       }
>
>       /* Clear all the cpus from the removal list */
> -    libxl_for_each_set_cpu(i, exclude_cpumap) {
> -        libxl_cpumap_reset(cpumap, i);
> -    }
> -
> -vcpp_out:
> -    libxl_cpumap_dispose(&exclude_cpumap);
> +    libxl_for_each_set_elem(i, exclude_map) {
> +        libxl_map_reset(map, i);
> +    }
> +
> +afp_out:
> +    libxl_map_dispose(&exclude_map);
>
>       return rc;
>   }
>
> +static inline int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +{
> +    return affinity_parse(cpu, cpumap, libxl_get_max_cpus(ctx));
> +}
> +
> +static inline int nodeaffinity_parse(char *nodes, libxl_nodemap *nodemap)
> +{
> +    return affinity_parse(nodes, nodemap, libxl_get_max_nodes(ctx));
> +}
> +
>   static void parse_config_data(const char *configfile_filename_report,
>                                 const char *configfile_data,
>                                 int configfile_len,
> @@ -3873,6 +3883,40 @@ int main_vcpuset(int argc, char **argv)
>       return 0;
>   }
>
> +static void nodeaffinity(const char *d, char *nodes)
> +{
> +    libxl_nodemap nodemap;
> +
> +    find_domain(d);
> +
> +    if (libxl_nodemap_alloc(ctx,&nodemap))
> +        goto nodeaffinity_out;
> +
> +    if (!strcmp(nodes, "all"))
> +        libxl_nodemap_set_any(&nodemap);
> +    else if (nodeaffinity_parse(nodes,&nodemap))
> +        goto nodeaffinity_out1;
> +
> +    if (libxl_set_node_affinity(ctx, domid,&nodemap) == -1)
> +        fprintf(stderr, "Could not set node affinity for dom `%d'.\n", domid);
> +
> +  nodeaffinity_out1:
> +    libxl_nodemap_dispose(&nodemap);
> +  nodeaffinity_out:
> +    ;
> +}
> +
> +int main_nodeaffinity(int argc, char **argv)
> +{
> +    int opt;
> +
> +    if ((opt = def_getopt(argc, argv, "", "node-affinity", 2)) != -1)
> +        return opt;
> +
> +    nodeaffinity(argv[optind], argv[optind+1]);
> +    return 0;
> +}
> +
>   static void output_xeninfo(void)
>   {
>       const libxl_version_info *info;
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -195,6 +195,11 @@ struct cmd_spec cmd_table[] = {
>         "Set the number of active VCPUs allowed for the domain",
>         "<Domain>  <vCPUs>",
>       },
> +    { "node-affinity",
> +&main_nodeaffinity, 0,
> +      "Set the NUMA node affinity for the domain",
> +      "<Domain>  <Nodes|all>",
> +    },
>       { "list-vm",
>         &main_list_vm, 0,
>         "List the VMs,without DOM0",


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:30:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHI7-0002Xx-PO; Thu, 12 Apr 2012 10:30:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIHI5-0002Xn-BS
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:30:13 +0000
Received: from [85.158.143.35:26905] by server-2.bemta-4.messagelabs.com id
	A5/E4-17550-4BEA68F4; Thu, 12 Apr 2012 10:30:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334226609!12092865!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28078 invoked from network); 12 Apr 2012 10:30:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="24090118"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:30:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 06:30:09 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIHI0-0008Oo-LB;
	Thu, 12 Apr 2012 11:30:08 +0100
Message-ID: <4F86AE89.7020801@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:29:29 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<64547b45cb112a35d3a2.1334150273@Solace>
In-Reply-To: <64547b45cb112a35d3a2.1334150273@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10 [RFC]] xl: Allow user to set or
 change node affinity on-line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> For feature parity with vcpu affinity, allow for specifying
> node affinity not only at domain creation time, but at run-time
> too.
>
> Of course this is not going to be equally effective, as it will
> only affect future memory allocations without touching what's
> already there. However, in future we might want to change this,
> and use this as an interface for sort-of manual "domain node
> migration".
I think this is a good idea.

I think if you take my suggestion to rework the previous patch into 
hypervisor, libxc, and libxl components, you should also move the xl 
stuff out of that patch and into this one (so that the xl and libxl 
changes relating to node affinity are each in their own patches).
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
>
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -556,6 +556,26 @@ different run state is appropriate.  Pin
>   this, by ensuring certain VCPUs can only run on certain physical
>   CPUs.
>
> +=item B<node-affinity>  I<domain-id>  I<nodes>
> +
> +Set the NUMA node affinity for the domain, i.e., the set of NUMA
> +nodes of the host from which the memory of the domain will be
> +allocated. More specificallly, the domain's memory will be split
> +in equal (well, as equal as possible) parts among all the nodes
> +it is affine with, The keyword B<all>  can be used to have the
> +domain affine to all NUMA nodes in the host.
> +
> +Normally NUMA node affinity of a domain is automatically computed
> +from its VCPU affinity. The default behaviour is to have it equal
> +to all the nodes the PCPUs onto which the VCPUs of the domain are
> +pinned belong to. Manually specifying it can be used to restrict
> +this to a specific subset of the host NUMA nodes, for improved
> +locality of memory accesses by the domain. Notice, however, that
> +this will not affect the memory that has already been allocated.
> +For having the full amount of memory allocated on specific node(s)
> +at domain creation time, the domain's configuration file is what
> +should be used.
> +
>   =item B<vncviewer>  [I<OPTIONS>] I<domain-id>
>
>   Attach to domain's VNC server, forking a vncviewer process.
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -442,7 +442,7 @@ void libxl_map_dispose(struct libxl_map
>       free(map->map);
>   }
>
> -static int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
> +int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems)
>   {
>       int sz;
>
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -64,6 +64,7 @@ int libxl_devid_to_device_nic(libxl_ctx
>   int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
>                                  libxl_device_disk *disk);
>
> +int libxl_map_alloc(libxl_ctx *ctx, struct libxl_map *map, int n_elems);
>   int libxl_map_test(struct libxl_map *map, int elem);
>   void libxl_map_set(struct libxl_map *map, int elem);
>   void libxl_map_reset(struct libxl_map *map, int elem);
> @@ -79,6 +80,10 @@ static inline int libxl_map_elem_valid(s
>   {
>       return elem>= 0&&  elem<  (map->size * 8);
>   }
> +#define libxl_for_each_elem(v, m) for (v = 0; v<  (m).size * 8; v++)
> +#define libxl_for_each_set_elem(v, m) for (v = 0; v<  (m).size * 8; v++) \
> +                                              if (libxl_map_test(&(m), v))
> +
>
>   int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
>   static inline int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
> diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
> --- a/tools/libxl/xl.h
> +++ b/tools/libxl/xl.h
> @@ -54,6 +54,7 @@ int main_config_update(int argc, char **
>   int main_button_press(int argc, char **argv);
>   int main_vcpupin(int argc, char **argv);
>   int main_vcpuset(int argc, char **argv);
> +int main_nodeaffinity(int argc, char **argv);
>   int main_memmax(int argc, char **argv);
>   int main_memset(int argc, char **argv);
>   int main_sched_credit(int argc, char **argv);
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -448,65 +448,75 @@ static void split_string_into_string_lis
>       free(s);
>   }
>
> -static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +static int affinity_parse(char *str, struct libxl_map *map, int n_elems)
>   {
> -    libxl_cpumap exclude_cpumap;
> -    uint32_t cpuida, cpuidb;
> +    struct libxl_map exclude_map;
> +    uint32_t stra, strb;
>       char *endptr, *toka, *tokb, *saveptr = NULL;
> -    int i, rc = 0, rmcpu;
> -
> -    if (!strcmp(cpu, "all")) {
> -        libxl_cpumap_set_any(cpumap);
> +    int i, rc = 0, rmelem;
> +
> +    if (!strcmp(str, "all")) {
> +        libxl_map_set_any(map);
>           return 0;
>       }
>
> -    if (libxl_cpumap_alloc(ctx,&exclude_cpumap)) {
> -        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> +    if (libxl_map_alloc(ctx,&exclude_map, n_elems)) {
> +        fprintf(stderr, "Error: Failed to allocate libxl_map.\n");
>           return ENOMEM;
>       }
>
> -    for (toka = strtok_r(cpu, ",",&saveptr); toka;
> +    for (toka = strtok_r(str, ",",&saveptr); toka;
>            toka = strtok_r(NULL, ",",&saveptr)) {
> -        rmcpu = 0;
> +        rmelem = 0;
>           if (*toka == '^') {
>               /* This (These) Cpu(s) will be removed from the map */
>               toka++;
> -            rmcpu = 1;
> +            rmelem = 1;
>           }
>           /* Extract a valid (range of) cpu(s) */
> -        cpuida = cpuidb = strtoul(toka,&endptr, 10);
> +        stra = strb = strtoul(toka,&endptr, 10);
>           if (endptr == toka) {
>               fprintf(stderr, "Error: Invalid argument.\n");
>               rc = EINVAL;
> -            goto vcpp_out;
> +            goto afp_out;
>           }
>           if (*endptr == '-') {
>               tokb = endptr + 1;
> -            cpuidb = strtoul(tokb,&endptr, 10);
> -            if (endptr == tokb || cpuida>  cpuidb) {
> +            strb = strtoul(tokb,&endptr, 10);
> +            if (endptr == tokb || stra>  strb) {
>                   fprintf(stderr, "Error: Invalid argument.\n");
>                   rc = EINVAL;
> -                goto vcpp_out;
> +                goto afp_out;
>               }
>           }
> -        while (cpuida<= cpuidb) {
> -            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
> -                         libxl_cpumap_set(&exclude_cpumap, cpuida);
> -            cpuida++;
> +        while (stra<= strb) {
> +            rmelem == 0 ? libxl_map_set(map, stra) :
> +                          libxl_map_set(&exclude_map, stra);
> +            stra++;
>           }
>       }
>
>       /* Clear all the cpus from the removal list */
> -    libxl_for_each_set_cpu(i, exclude_cpumap) {
> -        libxl_cpumap_reset(cpumap, i);
> -    }
> -
> -vcpp_out:
> -    libxl_cpumap_dispose(&exclude_cpumap);
> +    libxl_for_each_set_elem(i, exclude_map) {
> +        libxl_map_reset(map, i);
> +    }
> +
> +afp_out:
> +    libxl_map_dispose(&exclude_map);
>
>       return rc;
>   }
>
> +static inline int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +{
> +    return affinity_parse(cpu, cpumap, libxl_get_max_cpus(ctx));
> +}
> +
> +static inline int nodeaffinity_parse(char *nodes, libxl_nodemap *nodemap)
> +{
> +    return affinity_parse(nodes, nodemap, libxl_get_max_nodes(ctx));
> +}
> +
>   static void parse_config_data(const char *configfile_filename_report,
>                                 const char *configfile_data,
>                                 int configfile_len,
> @@ -3873,6 +3883,40 @@ int main_vcpuset(int argc, char **argv)
>       return 0;
>   }
>
> +static void nodeaffinity(const char *d, char *nodes)
> +{
> +    libxl_nodemap nodemap;
> +
> +    find_domain(d);
> +
> +    if (libxl_nodemap_alloc(ctx,&nodemap))
> +        goto nodeaffinity_out;
> +
> +    if (!strcmp(nodes, "all"))
> +        libxl_nodemap_set_any(&nodemap);
> +    else if (nodeaffinity_parse(nodes,&nodemap))
> +        goto nodeaffinity_out1;
> +
> +    if (libxl_set_node_affinity(ctx, domid,&nodemap) == -1)
> +        fprintf(stderr, "Could not set node affinity for dom `%d'.\n", domid);
> +
> +  nodeaffinity_out1:
> +    libxl_nodemap_dispose(&nodemap);
> +  nodeaffinity_out:
> +    ;
> +}
> +
> +int main_nodeaffinity(int argc, char **argv)
> +{
> +    int opt;
> +
> +    if ((opt = def_getopt(argc, argv, "", "node-affinity", 2)) != -1)
> +        return opt;
> +
> +    nodeaffinity(argv[optind], argv[optind+1]);
> +    return 0;
> +}
> +
>   static void output_xeninfo(void)
>   {
>       const libxl_version_info *info;
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -195,6 +195,11 @@ struct cmd_spec cmd_table[] = {
>         "Set the number of active VCPUs allowed for the domain",
>         "<Domain>  <vCPUs>",
>       },
> +    { "node-affinity",
> +&main_nodeaffinity, 0,
> +      "Set the NUMA node affinity for the domain",
> +      "<Domain>  <Nodes|all>",
> +    },
>       { "list-vm",
>         &main_list_vm, 0,
>         "List the VMs,without DOM0",


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:31:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHJG-0002dQ-7f; Thu, 12 Apr 2012 10:31:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIHJF-0002dI-Fy
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:31:25 +0000
Received: from [85.158.143.35:19080] by server-1.bemta-4.messagelabs.com id
	E3/0F-20925-CFEA68F4; Thu, 12 Apr 2012 10:31:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334226683!9630250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29581 invoked from network); 12 Apr 2012 10:31:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:31:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11897614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:31:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:31:23 +0100
Date: Thu, 12 Apr 2012 11:35:08 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.41.542788.706794@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > Introduce a new save_id to save/restore toolstack specific extra
> > information.
> 
> This looks plausible.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Although I do have one comment: are you sure it's appropriate that the
> "toolstack data" is silently thrown away if the restore caller doesn't
> supply the relevant callback ?

We should print a warning in that case and try to continue

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:31:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHJG-0002dQ-7f; Thu, 12 Apr 2012 10:31:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIHJF-0002dI-Fy
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:31:25 +0000
Received: from [85.158.143.35:19080] by server-1.bemta-4.messagelabs.com id
	E3/0F-20925-CFEA68F4; Thu, 12 Apr 2012 10:31:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334226683!9630250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29581 invoked from network); 12 Apr 2012 10:31:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:31:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11897614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:31:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:31:23 +0100
Date: Thu, 12 Apr 2012 11:35:08 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.41.542788.706794@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > Introduce a new save_id to save/restore toolstack specific extra
> > information.
> 
> This looks plausible.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Although I do have one comment: are you sure it's appropriate that the
> "toolstack data" is silently thrown away if the restore caller doesn't
> supply the relevant callback ?

We should print a warning in that case and try to continue

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHKI-0002j8-M0; Thu, 12 Apr 2012 10:32:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIHKH-0002j0-Ez
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:32:29 +0000
Received: from [85.158.139.83:39813] by server-5.bemta-5.messagelabs.com id
	A4/C2-13566-C3FA68F4; Thu, 12 Apr 2012 10:32:28 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334226746!19614169!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10406 invoked from network); 12 Apr 2012 10:32:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 10:32:26 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77074611; Thu, 12 Apr 2012 12:32:24 +0200
Message-ID: <1334226729.28329.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Apr 2012 12:32:09 +0200
In-Reply-To: <1334221902.16387.45.camel@zakaz.uk.xensource.com>
References: <patchbomb.1334150267@Solace>
	<ec0abe6e2de3d35d626a.1334150277@Solace>
	<1334221902.16387.45.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10 [RFC]] xl: Some automatic NUMA
 placement documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3090533462319172796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3090533462319172796==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-NYPfdHDeX24zCS4Xzj1G"


--=-NYPfdHDeX24zCS4Xzj1G
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 10:11 +0100, Ian Campbell wrote:
> On Wed, 2012-04-11 at 14:17 +0100, Dario Faggioli wrote:
> > Add some rationale and usage documentation for the new automatic
> > NUMA placement feature of xl.
> >=20
> > TODO: * Decide whether we want to have things like "Future Steps/Roadma=
p"
> >         and/or "Performances/Benchmarks Results" here as well.
>=20
> I think these would be better in the list archives and on the wiki
> respectively.
>=20
Ok, fine. I already posted the link in this thread and will continue to
do so, as I'll put together a blog post and a wiki page about
benchmarks.

As for future steps/roadmap, let's first see what comes out from this
series... :-)

> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >=20
> > diff --git a/docs/misc/xl-numa-placement.txt b/docs/misc/xl-numa-placem=
ent.txt
> > new file mode 100644
> > --- /dev/null
> > +++ b/docs/misc/xl-numa-placement.txt
>=20
> It looks like you are using something approximating markdown syntax
> here, so you might as well name this xl-numa-placement.markdown and get
> a .html version etc almost for free.
>=20
Actually, that was another question I had and forgot to ask, i.e., what
format should this file come with. I sort of took inspiration from
xl-disk-configuration.txt and went for a plain text file, but I of
course can go for a full-fledged markdown syntax. Thanks.

> > +Of course, if a domain is known to only run on a subset of the physica=
l
> > +CPUs of the host, it is very easy to turn all its memory accesses into
> > +local ones, by just constructing it's node affinity (in Xen) basing on
>=20
>                                                                 ^based
>=20
Ok, to this ans to all typos/english howlers as well. Thanks a lot for
looking into this! :-)

> > + * `nodes =3D [ '0', '1' ]` and `cpus =3D "0"`, with CPU 0 within node=
 0:
> > +   (i.e., cpu affinity subset of node affinity):
> > +     domain's vcpus can and will only run on host CPU 0. As node affin=
ity
> > +     is being explicitly set to host NUMA nodes 0 and 1 --- which incl=
udes
> > +     CPU 0 --- all the memory access of the domain will be local;
>=20
> In this case won't some of (half?) the memory come from node 1 and
> therefore be non-local to cpu 0?
>=20
Oops, yep, you're right, that's not what I meant to write!

> > +
> > + * `nodes =3D [ '0', '1' ]` and `cpus =3D "0, 4", with CPU 0 in node 0=
 but
> > +   CPU 4 in, say, node 2 (i.e., cpu affinity superset of node affinity=
):
> > +     domain's vcpus can run on host CPUs 0 and 4, with CPU 4 not being=
 within
> > +     the node affinity (explicitly set to host NUMA nodes 0 and 1). Th=
e
> > +     (credit) scheduler will try to keep memory accesses local by sche=
duling
> > +     the domain's vcpus on CPU 0, but it may not achieve 100% success;
> > +
> > + * `nodes =3D [ '0', '1' ]` and `cpus =3D "4"`, with CPU 4 within, say=
, node 2
>=20
> These examples might be a little clearer if you defined up front what
> the nodes and cpus were and then used that for all of them?
>=20
Good, idea, I will do that.

> A bunch of what follows would be good to have in the xl or xl.cfg man
> pages too/instead. (I started with this docs patch so I haven't actually
> looked at the earlier ones yet, perhaps this is already the case)
>=20
Single patches that introduces the various features tries to document
them as well, but not with this level of details. I'm fine with putting
there whatever you think it could fit, just le me know, perhaps on the
comments on those patches, or whatever you like.=20

> > +
> > + * "auto": automatic placement by means of a not better specified (xl
> > +           implementation dependant) algorithm. It is basically for th=
ose
> > +           who do want automatic placement, but have no idea what poli=
cy
> > +           or algorithm would be better... <<Just give me a sane defau=
lt!>>
> > +
> > + * "ffit": automatic placement via the First Fit algorithm, applied ch=
ecking
> > +           the memory requirement of the domain against the amount of =
free
> > +           memory in the various host NUMA nodes;
> > +
> > + * "bfit": automatic placement via the Best Fit algorithm, applied che=
cking
> > +           the memory requirement of the domain against the amount of =
free
> > +           memory in the various host NUMA nodes;
> > +
> > + * "wfit": automatic placement via the Worst Fit algorithm, applied ch=
ecking
> > +           the memory requirement of the domain against the amount of =
free
> > +           memory in the various host NUMA nodes;
> >
> > <snip>
> >
> > + * `nodes_policy=3D"auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `node=
s=3D2`:
> > +     xl will try fitting the domain on the host NUMA nodes by using th=
e
> > +     requested policy and only the number of nodes specified in `nodes=
=3D`
> > +     (2 in this example).
>=20
> Number of nodes rather than specifically node 2? This is different to
> the examples in the preceding section?
>=20
It is. I'll try to clarify things as per your suggestion. However,
talking about syntax, here's what the series allows "nodes" and
"nodes_policy" to be:

 * "nodes=3D": - a list (`[ '0', '3' ]`), and in this case the elements=20
               of the list are specific nodes you want to use;
             - an integer (`2`), and in this case that is the _number_=20
               of nodes you want to use, with the algorithm free to
               arbitrary decide which ones to pick;
             - the string `"auto"`, and in this case you tell the=20
               algorithm: <<please, do whatever you like and make me =20
               happy>> :-)

 * "nodes_policy=3D" - the string `"auto"`, the same as above
                   - the strings `"ffit"`, `"bfit"` and `"wfit"`, with=20
                     the meaning reported by the doc in he patch.

There is some overlapping but I wanted to make it possible for one to
write just things like:

nodes =3D [ '0', '3' ]

or:=20

nodes =3D "auto"

or:

nodes_policy =3D "wfit"
nodes =3D 2

without introducing too much different options. On the down side, this
could obviously lead to awkward or nonsensical combinations... I tried
to intercept the worst of them during config file parsing, and can
surely push this farther.

So the important question here is, besides from the fact I'll try to
clarify things better, do you think the interface is both comprehensive
and clear enough? Or should we think to something different?

Thanks a lot again and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-NYPfdHDeX24zCS4Xzj1G
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+GrykACgkQk4XaBE3IOsQizgCgm3Npz/1CVS10MPi78xIrWWJg
qpQAoIPD1r+QrY1oC0nel5jKF5gjSt6v
=FplK
-----END PGP SIGNATURE-----

--=-NYPfdHDeX24zCS4Xzj1G--



--===============3090533462319172796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3090533462319172796==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 10:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHKI-0002j8-M0; Thu, 12 Apr 2012 10:32:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIHKH-0002j0-Ez
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:32:29 +0000
Received: from [85.158.139.83:39813] by server-5.bemta-5.messagelabs.com id
	A4/C2-13566-C3FA68F4; Thu, 12 Apr 2012 10:32:28 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334226746!19614169!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10406 invoked from network); 12 Apr 2012 10:32:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 10:32:26 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77074611; Thu, 12 Apr 2012 12:32:24 +0200
Message-ID: <1334226729.28329.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Apr 2012 12:32:09 +0200
In-Reply-To: <1334221902.16387.45.camel@zakaz.uk.xensource.com>
References: <patchbomb.1334150267@Solace>
	<ec0abe6e2de3d35d626a.1334150277@Solace>
	<1334221902.16387.45.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10 [RFC]] xl: Some automatic NUMA
 placement documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3090533462319172796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3090533462319172796==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-NYPfdHDeX24zCS4Xzj1G"


--=-NYPfdHDeX24zCS4Xzj1G
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 10:11 +0100, Ian Campbell wrote:
> On Wed, 2012-04-11 at 14:17 +0100, Dario Faggioli wrote:
> > Add some rationale and usage documentation for the new automatic
> > NUMA placement feature of xl.
> >=20
> > TODO: * Decide whether we want to have things like "Future Steps/Roadma=
p"
> >         and/or "Performances/Benchmarks Results" here as well.
>=20
> I think these would be better in the list archives and on the wiki
> respectively.
>=20
Ok, fine. I already posted the link in this thread and will continue to
do so, as I'll put together a blog post and a wiki page about
benchmarks.

As for future steps/roadmap, let's first see what comes out from this
series... :-)

> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >=20
> > diff --git a/docs/misc/xl-numa-placement.txt b/docs/misc/xl-numa-placem=
ent.txt
> > new file mode 100644
> > --- /dev/null
> > +++ b/docs/misc/xl-numa-placement.txt
>=20
> It looks like you are using something approximating markdown syntax
> here, so you might as well name this xl-numa-placement.markdown and get
> a .html version etc almost for free.
>=20
Actually, that was another question I had and forgot to ask, i.e., what
format should this file come with. I sort of took inspiration from
xl-disk-configuration.txt and went for a plain text file, but I of
course can go for a full-fledged markdown syntax. Thanks.

> > +Of course, if a domain is known to only run on a subset of the physica=
l
> > +CPUs of the host, it is very easy to turn all its memory accesses into
> > +local ones, by just constructing it's node affinity (in Xen) basing on
>=20
>                                                                 ^based
>=20
Ok, to this ans to all typos/english howlers as well. Thanks a lot for
looking into this! :-)

> > + * `nodes =3D [ '0', '1' ]` and `cpus =3D "0"`, with CPU 0 within node=
 0:
> > +   (i.e., cpu affinity subset of node affinity):
> > +     domain's vcpus can and will only run on host CPU 0. As node affin=
ity
> > +     is being explicitly set to host NUMA nodes 0 and 1 --- which incl=
udes
> > +     CPU 0 --- all the memory access of the domain will be local;
>=20
> In this case won't some of (half?) the memory come from node 1 and
> therefore be non-local to cpu 0?
>=20
Oops, yep, you're right, that's not what I meant to write!

> > +
> > + * `nodes =3D [ '0', '1' ]` and `cpus =3D "0, 4", with CPU 0 in node 0=
 but
> > +   CPU 4 in, say, node 2 (i.e., cpu affinity superset of node affinity=
):
> > +     domain's vcpus can run on host CPUs 0 and 4, with CPU 4 not being=
 within
> > +     the node affinity (explicitly set to host NUMA nodes 0 and 1). Th=
e
> > +     (credit) scheduler will try to keep memory accesses local by sche=
duling
> > +     the domain's vcpus on CPU 0, but it may not achieve 100% success;
> > +
> > + * `nodes =3D [ '0', '1' ]` and `cpus =3D "4"`, with CPU 4 within, say=
, node 2
>=20
> These examples might be a little clearer if you defined up front what
> the nodes and cpus were and then used that for all of them?
>=20
Good, idea, I will do that.

> A bunch of what follows would be good to have in the xl or xl.cfg man
> pages too/instead. (I started with this docs patch so I haven't actually
> looked at the earlier ones yet, perhaps this is already the case)
>=20
Single patches that introduces the various features tries to document
them as well, but not with this level of details. I'm fine with putting
there whatever you think it could fit, just le me know, perhaps on the
comments on those patches, or whatever you like.=20

> > +
> > + * "auto": automatic placement by means of a not better specified (xl
> > +           implementation dependant) algorithm. It is basically for th=
ose
> > +           who do want automatic placement, but have no idea what poli=
cy
> > +           or algorithm would be better... <<Just give me a sane defau=
lt!>>
> > +
> > + * "ffit": automatic placement via the First Fit algorithm, applied ch=
ecking
> > +           the memory requirement of the domain against the amount of =
free
> > +           memory in the various host NUMA nodes;
> > +
> > + * "bfit": automatic placement via the Best Fit algorithm, applied che=
cking
> > +           the memory requirement of the domain against the amount of =
free
> > +           memory in the various host NUMA nodes;
> > +
> > + * "wfit": automatic placement via the Worst Fit algorithm, applied ch=
ecking
> > +           the memory requirement of the domain against the amount of =
free
> > +           memory in the various host NUMA nodes;
> >
> > <snip>
> >
> > + * `nodes_policy=3D"auto"` (or `"ffit"`, `"bfit"`, `"wfit"`) and `node=
s=3D2`:
> > +     xl will try fitting the domain on the host NUMA nodes by using th=
e
> > +     requested policy and only the number of nodes specified in `nodes=
=3D`
> > +     (2 in this example).
>=20
> Number of nodes rather than specifically node 2? This is different to
> the examples in the preceding section?
>=20
It is. I'll try to clarify things as per your suggestion. However,
talking about syntax, here's what the series allows "nodes" and
"nodes_policy" to be:

 * "nodes=3D": - a list (`[ '0', '3' ]`), and in this case the elements=20
               of the list are specific nodes you want to use;
             - an integer (`2`), and in this case that is the _number_=20
               of nodes you want to use, with the algorithm free to
               arbitrary decide which ones to pick;
             - the string `"auto"`, and in this case you tell the=20
               algorithm: <<please, do whatever you like and make me =20
               happy>> :-)

 * "nodes_policy=3D" - the string `"auto"`, the same as above
                   - the strings `"ffit"`, `"bfit"` and `"wfit"`, with=20
                     the meaning reported by the doc in he patch.

There is some overlapping but I wanted to make it possible for one to
write just things like:

nodes =3D [ '0', '3' ]

or:=20

nodes =3D "auto"

or:

nodes_policy =3D "wfit"
nodes =3D 2

without introducing too much different options. On the down side, this
could obviously lead to awkward or nonsensical combinations... I tried
to intercept the worst of them during config file parsing, and can
surely push this farther.

So the important question here is, besides from the fact I'll try to
clarify things better, do you think the interface is both comprehensive
and clear enough? Or should we think to something different?

Thanks a lot again and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-NYPfdHDeX24zCS4Xzj1G
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+GrykACgkQk4XaBE3IOsQizgCgm3Npz/1CVS10MPi78xIrWWJg
qpQAoIPD1r+QrY1oC0nel5jKF5gjSt6v
=FplK
-----END PGP SIGNATURE-----

--=-NYPfdHDeX24zCS4Xzj1G--



--===============3090533462319172796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3090533462319172796==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 10:47:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:47:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHYQ-0003N0-RX; Thu, 12 Apr 2012 10:47:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHYP-0003Mr-JN
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:47:05 +0000
Received: from [85.158.138.51:31377] by server-10.bemta-3.messagelabs.com id
	51/CD-29478-8A2B68F4; Thu, 12 Apr 2012 10:47:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334227623!21747333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 690 invoked from network); 12 Apr 2012 10:47:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:47:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:47:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:47:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIHYM-0004e4-OM; Thu, 12 Apr 2012 10:47:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIHYM-0005Te-NS;
	Thu, 12 Apr 2012 11:47:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.45734.708851.953377@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 11:47:02 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
References: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
> I am keen on having these three patches in 4.1.3:
> http://marc.info/?l=xen-devel&m=133251438030441
> 
> I asked Ian to backport them in a previous email.

Right.

The first step in making a stable branch release should be to send a
message to xen-devel asking for people to resend any outstanding
backport requests, and setting a deadline for responses.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:47:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:47:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHYQ-0003N0-RX; Thu, 12 Apr 2012 10:47:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHYP-0003Mr-JN
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:47:05 +0000
Received: from [85.158.138.51:31377] by server-10.bemta-3.messagelabs.com id
	51/CD-29478-8A2B68F4; Thu, 12 Apr 2012 10:47:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334227623!21747333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 690 invoked from network); 12 Apr 2012 10:47:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:47:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:47:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:47:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIHYM-0004e4-OM; Thu, 12 Apr 2012 10:47:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIHYM-0005Te-NS;
	Thu, 12 Apr 2012 11:47:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.45734.708851.953377@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 11:47:02 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
References: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
> I am keen on having these three patches in 4.1.3:
> http://marc.info/?l=xen-devel&m=133251438030441
> 
> I asked Ian to backport them in a previous email.

Right.

The first step in making a stable branch release should be to send a
message to xen-devel asking for people to resend any outstanding
backport requests, and setting a deadline for responses.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:48:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHZR-0003Qv-BO; Thu, 12 Apr 2012 10:48:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIHZP-0003Qi-FE
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:48:07 +0000
Received: from [85.158.143.99:54324] by server-2.bemta-4.messagelabs.com id
	4B/73-17550-6E2B68F4; Thu, 12 Apr 2012 10:48:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334227685!23290205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6007 invoked from network); 12 Apr 2012 10:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:48:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:48:05 +0100
Date: Thu, 12 Apr 2012 11:51:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.690.289938.138564@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121150440.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.690.289938.138564@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> > +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
> > +        if (ret)
> > +            return -1;
> > +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> > +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> > +                    domid, pi->phys_offset), "%"PRIx64, pi->size);
> 
> This whole thing contains a lot of repetitive code.  Can you perhaps
> break the xs_write into a helper function and then you'd make the
> repetition more explicit by writing something like:
> 
>            helper(gc, domid, "start_addr", "%"PRIx64, pi->start_addr);
>            helper(gc, domid, "name",       "%"PRIx64, pi->size);
>            if (pi->namelen)
>                 helper(gc, domid, "name",       "%s",      pi->name);

I'll try to make the code more readable.


> > +static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> > +        uint32_t *len, void *data)
> > +{
> ...
> > +    *buf = calloc(1, *len);
> 
> Surely this should come from the gc.

Nope: libxc frees it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:48:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHZR-0003Qv-BO; Thu, 12 Apr 2012 10:48:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIHZP-0003Qi-FE
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:48:07 +0000
Received: from [85.158.143.99:54324] by server-2.bemta-4.messagelabs.com id
	4B/73-17550-6E2B68F4; Thu, 12 Apr 2012 10:48:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334227685!23290205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6007 invoked from network); 12 Apr 2012 10:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:48:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:48:05 +0100
Date: Thu, 12 Apr 2012 11:51:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20347.690.289938.138564@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121150440.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.690.289938.138564@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 3 Apr 2012, Ian Jackson wrote:
> > +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
> > +        if (ret)
> > +            return -1;
> > +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> > +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> > +                    domid, pi->phys_offset), "%"PRIx64, pi->size);
> 
> This whole thing contains a lot of repetitive code.  Can you perhaps
> break the xs_write into a helper function and then you'd make the
> repetition more explicit by writing something like:
> 
>            helper(gc, domid, "start_addr", "%"PRIx64, pi->start_addr);
>            helper(gc, domid, "name",       "%"PRIx64, pi->size);
>            if (pi->namelen)
>                 helper(gc, domid, "name",       "%s",      pi->name);

I'll try to make the code more readable.


> > +static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> > +        uint32_t *len, void *data)
> > +{
> ...
> > +    *buf = calloc(1, *len);
> 
> Surely this should come from the gc.

Nope: libxc frees it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:49:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHaO-0003XS-UD; Thu, 12 Apr 2012 10:49:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIHaN-0003XI-J5
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:49:07 +0000
Received: from [193.109.254.147:31504] by server-12.bemta-14.messagelabs.com
	id 94/F1-05898-223B68F4; Thu, 12 Apr 2012 10:49:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334227734!4264043!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7394 invoked from network); 12 Apr 2012 10:48:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:48:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190006395"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:48:54 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Apr 2012
	06:48:54 -0400
Message-ID: <4F86B313.5010708@citrix.com>
Date: Thu, 12 Apr 2012 11:48:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1334150267@Solace>	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com>
In-Reply-To: <4F86AD6E.3050705@eu.citrix.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/12 11:24, George Dunlap wrote:
> On 11/04/12 14:17, Dario Faggioli wrote:
>> 
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -112,6 +112,15 @@ List of which cpus the guest is allowed
>>   (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
>>   will run on cpus 2 and 3).
>>
>> +=item B<nodes=[ NODE, NODE, ...]>
>> +
>> +List of the NUMA nodes of the host the guest should be considered
>> +`affine` with. Being affine to a (set of) NUMA node(s) mainly means
>> +the guest's memory is going to be allocated on those node(s).
>> +
>> +A list of nodes should be specified as follows: `nodes=["0", "3"]`
>> +for the guest to be affine with nodes 0 and 3.
>> +
> Hmm, I think that using "affine" here is technically correct, and is
> what one would use if writing a research paper; but it's unusual to hear
> the word in more common English; it would be more common to hear someone
> describe a VM as "having affinity with".  How about something like this:
> 
> "The list of NUMA nodes the domain is considered to have affinity with. 
> Memory from the guest will be allocated from these nodes."

That's clunky sentence, the "considered" doesn't add anything.  Or perhaps:

"The NUMA nodes preferred by the guest.  Memory for the guest will be
allocated on these nodes."

The need for quotes around the node numbers is odd.  Can that
requirement be removed?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:49:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHaO-0003XS-UD; Thu, 12 Apr 2012 10:49:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIHaN-0003XI-J5
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 10:49:07 +0000
Received: from [193.109.254.147:31504] by server-12.bemta-14.messagelabs.com
	id 94/F1-05898-223B68F4; Thu, 12 Apr 2012 10:49:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334227734!4264043!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7394 invoked from network); 12 Apr 2012 10:48:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:48:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190006395"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 06:48:54 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Apr 2012
	06:48:54 -0400
Message-ID: <4F86B313.5010708@citrix.com>
Date: Thu, 12 Apr 2012 11:48:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1334150267@Solace>	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com>
In-Reply-To: <4F86AD6E.3050705@eu.citrix.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/12 11:24, George Dunlap wrote:
> On 11/04/12 14:17, Dario Faggioli wrote:
>> 
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -112,6 +112,15 @@ List of which cpus the guest is allowed
>>   (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
>>   will run on cpus 2 and 3).
>>
>> +=item B<nodes=[ NODE, NODE, ...]>
>> +
>> +List of the NUMA nodes of the host the guest should be considered
>> +`affine` with. Being affine to a (set of) NUMA node(s) mainly means
>> +the guest's memory is going to be allocated on those node(s).
>> +
>> +A list of nodes should be specified as follows: `nodes=["0", "3"]`
>> +for the guest to be affine with nodes 0 and 3.
>> +
> Hmm, I think that using "affine" here is technically correct, and is
> what one would use if writing a research paper; but it's unusual to hear
> the word in more common English; it would be more common to hear someone
> describe a VM as "having affinity with".  How about something like this:
> 
> "The list of NUMA nodes the domain is considered to have affinity with. 
> Memory from the guest will be allocated from these nodes."

That's clunky sentence, the "considered" doesn't add anything.  Or perhaps:

"The NUMA nodes preferred by the guest.  Memory for the guest will be
allocated on these nodes."

The need for quotes around the node numbers is odd.  Can that
requirement be removed?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:57:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHhr-0003u0-RP; Thu, 12 Apr 2012 10:56:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHhq-0003tv-SR
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:56:51 +0000
Received: from [85.158.143.35:24771] by server-3.bemta-4.messagelabs.com id
	FA/44-05853-2F4B68F4; Thu, 12 Apr 2012 10:56:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334228208!6749539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24192 invoked from network); 12 Apr 2012 10:56:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:56:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:56:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIHho-0004o8-1s;
	Thu, 12 Apr 2012 10:56:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIHhn-0003eY-VZ;
	Thu, 12 Apr 2012 11:56:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12653-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:56:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12653: regressions - trouble:
	blocked/fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12653 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12653/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12557
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12557
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12557
 build-amd64                   4 xen-build                 fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                f549e088b806f44b6ab6eeef0cb71ced1d2488dd
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:57:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHhr-0003u0-RP; Thu, 12 Apr 2012 10:56:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHhq-0003tv-SR
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:56:51 +0000
Received: from [85.158.143.35:24771] by server-3.bemta-4.messagelabs.com id
	FA/44-05853-2F4B68F4; Thu, 12 Apr 2012 10:56:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334228208!6749539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24192 invoked from network); 12 Apr 2012 10:56:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:56:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:56:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIHho-0004o8-1s;
	Thu, 12 Apr 2012 10:56:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIHhn-0003eY-VZ;
	Thu, 12 Apr 2012 11:56:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12653-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:56:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12653: regressions - trouble:
	blocked/fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12653 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12653/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12557
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12557
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12557
 build-amd64                   4 xen-build                 fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                f549e088b806f44b6ab6eeef0cb71ced1d2488dd
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:58:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHjA-0003xu-AC; Thu, 12 Apr 2012 10:58:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHj8-0003xi-Pi
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:58:11 +0000
Received: from [85.158.143.35:44927] by server-3.bemta-4.messagelabs.com id
	97/B6-05853-245B68F4; Thu, 12 Apr 2012 10:58:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334228288!11711440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10528 invoked from network); 12 Apr 2012 10:58:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:58:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:58:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:58:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIHj5-0004oY-F4;
	Thu, 12 Apr 2012 10:58:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIHj5-0003kn-CR;
	Thu, 12 Apr 2012 11:58:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12654-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:58:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12654: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12654 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12654/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12578
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 12578
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12578
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12578
 build-amd64                   4 xen-build                 fail REGR. vs. 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 10:58:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 10:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHjA-0003xu-AC; Thu, 12 Apr 2012 10:58:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHj8-0003xi-Pi
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 10:58:11 +0000
Received: from [85.158.143.35:44927] by server-3.bemta-4.messagelabs.com id
	97/B6-05853-245B68F4; Thu, 12 Apr 2012 10:58:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334228288!11711440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10528 invoked from network); 12 Apr 2012 10:58:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 10:58:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 10:58:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 11:58:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIHj5-0004oY-F4;
	Thu, 12 Apr 2012 10:58:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIHj5-0003kn-CR;
	Thu, 12 Apr 2012 11:58:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12654-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 11:58:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12654: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12654 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12654/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12578
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 12578
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12578
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12578
 build-amd64                   4 xen-build                 fail REGR. vs. 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHly-00049f-ST; Thu, 12 Apr 2012 11:01:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIHlw-00049W-Q0
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:01:05 +0000
Received: from [85.158.143.99:8961] by server-3.bemta-4.messagelabs.com id
	A5/1C-05853-0F5B68F4; Thu, 12 Apr 2012 11:01:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334228463!23326583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17920 invoked from network); 12 Apr 2012 11:01:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:01:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:00:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 12:00:50 +0100
Message-ID: <1334228448.16387.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Apr 2012 12:00:48 +0100
In-Reply-To: <1334226256.22289.0.camel@Abyss>
References: <1334053490.12209.176.camel@dagon.hellion.org.uk>
	<1334226256.22289.0.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 11:24 +0100, Dario Faggioli wrote:
> On Tue, 2012-04-10 at 10:24 +0000, Ian Campbell wrote: 
> > Lots more DONE this week, still a few big ticket items or items with no
> > progress (that I've noticed) please let me know if the status of
> > anything has changed.
> >
> Here I am. :-)
> 
> > tools, blockers:
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> >               * Safe fork vs. fd handling hooks. Involves API changes
> >                 (Ian J, patches posted)
> >               * locking/serialization, e.g., for domain creation. As of
> >                 now,  nothing is provided for this purpose, and
> >                 downstream toolstacks have to put their own mechanisms
> >                 in place. E.g., xl uses a fcntl() lock around the whole
> >                 process of domain creation. It should OTOH be libxl job
> >                 to offer a proper set of hooks --placed at the proper
> >                 spots during the domain creation process-- for the
> >                 downstreams to fill with the proper callbacks. (Dario
> >                 Faggioli)
> >                       * Thinking to defer this until 4.3?
> >
> Here's the point. This was raised for the following main reasons:
> 1. xl holds a lock during domain creation for way too long
> 2. checking for free memory in xl when it is Xen that will actually 
>     allocate it after a while is prone to races (the classical TOCTTOU 
>     condition)
> 
> We thought both these things to be addressable by messing around with
> locks, but a more careful analysis revealed we can't solve 2. in a sane
> enough way by just doing that (i.e., messing with lock, moving it
> around, etc.).
> 
> That being the case, yes, I think we can move this forward toward 4.3
> without much problems, and I propose doing so. Thoughts?

I think this is OK, it will effectively be a new API in 4.3 so it should
be reasonably easy to do in a compatible manner.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHly-00049f-ST; Thu, 12 Apr 2012 11:01:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIHlw-00049W-Q0
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:01:05 +0000
Received: from [85.158.143.99:8961] by server-3.bemta-4.messagelabs.com id
	A5/1C-05853-0F5B68F4; Thu, 12 Apr 2012 11:01:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334228463!23326583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17920 invoked from network); 12 Apr 2012 11:01:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:01:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11898860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:00:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 12:00:50 +0100
Message-ID: <1334228448.16387.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Apr 2012 12:00:48 +0100
In-Reply-To: <1334226256.22289.0.camel@Abyss>
References: <1334053490.12209.176.camel@dagon.hellion.org.uk>
	<1334226256.22289.0.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 11:24 +0100, Dario Faggioli wrote:
> On Tue, 2012-04-10 at 10:24 +0000, Ian Campbell wrote: 
> > Lots more DONE this week, still a few big ticket items or items with no
> > progress (that I've noticed) please let me know if the status of
> > anything has changed.
> >
> Here I am. :-)
> 
> > tools, blockers:
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> >               * Safe fork vs. fd handling hooks. Involves API changes
> >                 (Ian J, patches posted)
> >               * locking/serialization, e.g., for domain creation. As of
> >                 now,  nothing is provided for this purpose, and
> >                 downstream toolstacks have to put their own mechanisms
> >                 in place. E.g., xl uses a fcntl() lock around the whole
> >                 process of domain creation. It should OTOH be libxl job
> >                 to offer a proper set of hooks --placed at the proper
> >                 spots during the domain creation process-- for the
> >                 downstreams to fill with the proper callbacks. (Dario
> >                 Faggioli)
> >                       * Thinking to defer this until 4.3?
> >
> Here's the point. This was raised for the following main reasons:
> 1. xl holds a lock during domain creation for way too long
> 2. checking for free memory in xl when it is Xen that will actually 
>     allocate it after a while is prone to races (the classical TOCTTOU 
>     condition)
> 
> We thought both these things to be addressable by messing around with
> locks, but a more careful analysis revealed we can't solve 2. in a sane
> enough way by just doing that (i.e., messing with lock, moving it
> around, etc.).
> 
> That being the case, yes, I think we can move this forward toward 4.3
> without much problems, and I propose doing so. Thoughts?

I think this is OK, it will effectively be a new API in 4.3 so it should
be reasonably easy to do in a compatible manner.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:11:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHvi-0004W4-3T; Thu, 12 Apr 2012 11:11:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHvf-0004Vz-LB
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:11:07 +0000
Received: from [85.158.143.99:5122] by server-1.bemta-4.messagelabs.com id
	71/E5-20925-A48B68F4; Thu, 12 Apr 2012 11:11:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334229062!18062573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11577 invoked from network); 12 Apr 2012 11:11:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:10:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:10:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIHv6-00053W-1R; Thu, 12 Apr 2012 11:10:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIHv6-0005WL-0X;
	Thu, 12 Apr 2012 12:10:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.47143.994639.76453@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:10:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334216141.12209.236.camel@dagon.hellion.org.uk>,
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> On Wed, 2012-04-11 at 17:13 +0100, Ian Jackson wrote:
> > It may be that we can add dummy ao_hows to these functions which might
> > be good enough for now, although particularly for domain creation
> > (which includes spawning) it might complicate the efforts of users to
> > use the new API.
> 
> How close is your half baked series to do it properly?

Another weeks or two maybe, if I don't get too badly sucked into doing
anything else.

> > Currently any use of subprocesses inside libxl which is not dealt with
> > by the new event machinery will experience problems if the event loop
> > is also used, because the event loop will reap the children.
> 
> You've covered the bootloader one in existing patches and mentioned the
> libxl_$CONSOLE_exec style ones in your last mail. The only other one is
> the DM fork which is covered by your rewrite of libxl__spawn?

Yes, I think so.  That's why I've been targeting those.


Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> On Wed, 2012-04-11 at 17:11 +0100, Ian Jackson wrote:
> > I took a look at libxl.h and came up with the comments below.  Firstly
> > general things I tripped over, and then the list of things which need
> > converting to the new event system.
> 
> A slightly worrying list at this stage in the game.

Yes.

> > Other:
> > ======
> > 
> > ]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, 
> > ]   /* wait for the memory target of a domain to be reached */
> > ]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid
> > 
> > This whole memory interface is a bit of a dog's breakfast.
> 
> I think we can defer this to 4.3? The existing interface may be pants
> but at least the name is pretty explicit that it will block. I think
> this should then be easy enough to sort out in a backward compatible
> manner in 4.3 since I expect the name of the function would change and
> we could retain the old name in terms of the new for compat.

The problem isn't just that it blocks but also that the semantics are
wrong.  This is all related to the problems of allocating memory.  We
had a recent conversation where we concluded that we needed hypervisor
changes to do memory assignment in a race-free way.  This is not 4.3
material.

I suggest that the right answer is to make a note that this interface
is considered substandard and not to rely on it too heavily; we expect
to replace it in the future and at that point we will provide an
emulation which we intend will works by and large well enough for
existing callers.

> > ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
...
> > These functions should not exec things for you; they should tell you
> > the parameters.  Any execing helpers should be in libxlu.
> 
> It's not enough for them to just use libxl__exec?
> 
> It'd be reasonably easy to make this return a libxl_string_list or
> similar and to write a libxlu function which takes one of those.

But what if your vnc viewer doesn't have the command line options
these functions expect ?  libxl_vncviewer_* should give you an idl
struct containing the ip address (or perhaps the domain name), port
number, and password.

The command lines should be built in xlu.

> > Need to be ao/eventified:
> > =========================
...
> > ]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domi
> > ]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config 
> > ]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_con
> 
> You are on the case with these?

Yes for the creation.

> > ]   typedef struct {
> > ]   #define XL_SUSPEND_DEBUG 1
> > ]   #define XL_SUSPEND_LIVE 2
> > ]       int flags;
> > ]       int (*suspend_callback)(void *, int);
> > ]   } libxl_domain_suspend_info;
> > ...
> > ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_i
> > ]                            uint32_t domid, int fd);

No for these, which I haven't looked at at all.

> > ]   int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> > 
> > Are these now merely initiations ?
> 
> I think so yes.
> 
> Does a non-transaction write make a function "slow"? That's all these
> actually do. If they are currently "fast" then we could likely get away
> with a dummy ao_how. (I think it is valid for a function which is "fast"
> to take an ao_how and always run sync?)

All xenstore operations apart from waiting for watches are fast, even
transactional read/modify/writes.  So these are OK.

> > ]   int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
> > 
> > Might become long-running in the future.
> 
> But is currently fast? Dummy ao_how?

That's probably correct, yes.

> > ]   int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl
> 
> Roger makes this async in his hotplug series.

Yes.

> > ]   /*
> > ]    * Insert a CD-ROM device. A device corresponding to disk must already
> > ]    * be attached to the guest.
> > ]    */
> > ]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_de
> 
> Were you looking at this one? I know you mentioned it at one point.

No, I haven't, but it shouldn't be too hard.

> > ]   /*
> > ]    * Make a disk available in this (the control) domain. Returns path to
> > ]    * a device.
> > ]    */
> > ]   char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_dev
> > ]   int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device
> > 
> > Does this even need to be public at this stage ?
> 
> I think Stefano internalises them in his qdisk/dom0-attach series.

Oh good.

> > ]   /* Network Interfaces */
> > ]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > 
> > ]   /* Keyboard */
> > ]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > 
> > ]   /* Framebuffer */
> > ]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> 
> These ought to be pretty trivial conversions?

Yes.  For the NICs I expect Roger will end up adding an ao_how for
hotplug script invocation.

> > ]   /* PCI Passthrough */
> > ]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_de
> > ]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl
> 
> I'm less confident that this one will be trivial to make async :-(

It's not trivial but it doesn't seem to contain any significant
difficulties.  It's all just xenstore stuff.  You split something like
do_pci_remove into a setup and a callback.

> > ]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
> > ]
> > ]   libxl_xen_console_reader *
> > ]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
> > ]   int libxl_xen_console_read_line(libxl_ctx *ctx,
> > ]                                   libxl_xen_console_reader *cr,
> > ]                                   char **line_r);
> > ]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
> > ]                                      libxl_xen_console_reader *cr);
> 
> This is basically "xl dmesg". I'm not sure what interface makes sense
> here, really it is just dumping the current ring, so each call is
> "fast".

OK, good.

Is it possible to wait for more input ?

> I'm not sure there is a need for an event driven "new-line-in-log"
> callback style thing, i.e. a need to implement a "tail -f" style thing. 
> Firstly I'm not sure that Xen actually produces an event which would
> allow this to be implemented without polling and secondly if you want
> that you can configure xenconsoled to log the hypervisor output and then
> tail the logfile.

Right.

> Perhaps this interface is OK?

I think I'm sold on it being supportable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:11:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHvi-0004W4-3T; Thu, 12 Apr 2012 11:11:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHvf-0004Vz-LB
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:11:07 +0000
Received: from [85.158.143.99:5122] by server-1.bemta-4.messagelabs.com id
	71/E5-20925-A48B68F4; Thu, 12 Apr 2012 11:11:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334229062!18062573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11577 invoked from network); 12 Apr 2012 11:11:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:10:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:10:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIHv6-00053W-1R; Thu, 12 Apr 2012 11:10:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIHv6-0005WL-0X;
	Thu, 12 Apr 2012 12:10:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.47143.994639.76453@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:10:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334216141.12209.236.camel@dagon.hellion.org.uk>,
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> On Wed, 2012-04-11 at 17:13 +0100, Ian Jackson wrote:
> > It may be that we can add dummy ao_hows to these functions which might
> > be good enough for now, although particularly for domain creation
> > (which includes spawning) it might complicate the efforts of users to
> > use the new API.
> 
> How close is your half baked series to do it properly?

Another weeks or two maybe, if I don't get too badly sucked into doing
anything else.

> > Currently any use of subprocesses inside libxl which is not dealt with
> > by the new event machinery will experience problems if the event loop
> > is also used, because the event loop will reap the children.
> 
> You've covered the bootloader one in existing patches and mentioned the
> libxl_$CONSOLE_exec style ones in your last mail. The only other one is
> the DM fork which is covered by your rewrite of libxl__spawn?

Yes, I think so.  That's why I've been targeting those.


Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> On Wed, 2012-04-11 at 17:11 +0100, Ian Jackson wrote:
> > I took a look at libxl.h and came up with the comments below.  Firstly
> > general things I tripped over, and then the list of things which need
> > converting to the new event system.
> 
> A slightly worrying list at this stage in the game.

Yes.

> > Other:
> > ======
> > 
> > ]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, 
> > ]   /* wait for the memory target of a domain to be reached */
> > ]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid
> > 
> > This whole memory interface is a bit of a dog's breakfast.
> 
> I think we can defer this to 4.3? The existing interface may be pants
> but at least the name is pretty explicit that it will block. I think
> this should then be easy enough to sort out in a backward compatible
> manner in 4.3 since I expect the name of the function would change and
> we could retain the old name in terms of the new for compat.

The problem isn't just that it blocks but also that the semantics are
wrong.  This is all related to the problems of allocating memory.  We
had a recent conversation where we concluded that we needed hypervisor
changes to do memory assignment in a race-free way.  This is not 4.3
material.

I suggest that the right answer is to make a note that this interface
is considered substandard and not to rely on it too heavily; we expect
to replace it in the future and at that point we will provide an
emulation which we intend will works by and large well enough for
existing callers.

> > ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
...
> > These functions should not exec things for you; they should tell you
> > the parameters.  Any execing helpers should be in libxlu.
> 
> It's not enough for them to just use libxl__exec?
> 
> It'd be reasonably easy to make this return a libxl_string_list or
> similar and to write a libxlu function which takes one of those.

But what if your vnc viewer doesn't have the command line options
these functions expect ?  libxl_vncviewer_* should give you an idl
struct containing the ip address (or perhaps the domain name), port
number, and password.

The command lines should be built in xlu.

> > Need to be ao/eventified:
> > =========================
...
> > ]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domi
> > ]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config 
> > ]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_con
> 
> You are on the case with these?

Yes for the creation.

> > ]   typedef struct {
> > ]   #define XL_SUSPEND_DEBUG 1
> > ]   #define XL_SUSPEND_LIVE 2
> > ]       int flags;
> > ]       int (*suspend_callback)(void *, int);
> > ]   } libxl_domain_suspend_info;
> > ...
> > ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_i
> > ]                            uint32_t domid, int fd);

No for these, which I haven't looked at at all.

> > ]   int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> > 
> > Are these now merely initiations ?
> 
> I think so yes.
> 
> Does a non-transaction write make a function "slow"? That's all these
> actually do. If they are currently "fast" then we could likely get away
> with a dummy ao_how. (I think it is valid for a function which is "fast"
> to take an ao_how and always run sync?)

All xenstore operations apart from waiting for watches are fast, even
transactional read/modify/writes.  So these are OK.

> > ]   int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
> > 
> > Might become long-running in the future.
> 
> But is currently fast? Dummy ao_how?

That's probably correct, yes.

> > ]   int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl
> 
> Roger makes this async in his hotplug series.

Yes.

> > ]   /*
> > ]    * Insert a CD-ROM device. A device corresponding to disk must already
> > ]    * be attached to the guest.
> > ]    */
> > ]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_de
> 
> Were you looking at this one? I know you mentioned it at one point.

No, I haven't, but it shouldn't be too hard.

> > ]   /*
> > ]    * Make a disk available in this (the control) domain. Returns path to
> > ]    * a device.
> > ]    */
> > ]   char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_dev
> > ]   int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device
> > 
> > Does this even need to be public at this stage ?
> 
> I think Stefano internalises them in his qdisk/dom0-attach series.

Oh good.

> > ]   /* Network Interfaces */
> > ]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > 
> > ]   /* Keyboard */
> > ]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > 
> > ]   /* Framebuffer */
> > ]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> 
> These ought to be pretty trivial conversions?

Yes.  For the NICs I expect Roger will end up adding an ao_how for
hotplug script invocation.

> > ]   /* PCI Passthrough */
> > ]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_de
> > ]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl
> 
> I'm less confident that this one will be trivial to make async :-(

It's not trivial but it doesn't seem to contain any significant
difficulties.  It's all just xenstore stuff.  You split something like
do_pci_remove into a setup and a callback.

> > ]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
> > ]
> > ]   libxl_xen_console_reader *
> > ]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
> > ]   int libxl_xen_console_read_line(libxl_ctx *ctx,
> > ]                                   libxl_xen_console_reader *cr,
> > ]                                   char **line_r);
> > ]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
> > ]                                      libxl_xen_console_reader *cr);
> 
> This is basically "xl dmesg". I'm not sure what interface makes sense
> here, really it is just dumping the current ring, so each call is
> "fast".

OK, good.

Is it possible to wait for more input ?

> I'm not sure there is a need for an event driven "new-line-in-log"
> callback style thing, i.e. a need to implement a "tail -f" style thing. 
> Firstly I'm not sure that Xen actually produces an event which would
> allow this to be implemented without polling and secondly if you want
> that you can configure xenconsoled to log the hypervisor output and then
> tail the logfile.

Right.

> Perhaps this interface is OK?

I think I'm sold on it being supportable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:12:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHxE-0004bz-Oe; Thu, 12 Apr 2012 11:12:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SIHxD-0004bn-0M
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:12:43 +0000
Received: from [85.158.138.51:30016] by server-10.bemta-3.messagelabs.com id
	61/49-29478-AA8B68F4; Thu, 12 Apr 2012 11:12:42 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334229160!21826849!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32307 invoked from network); 12 Apr 2012 11:12:41 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:12:41 -0000
Received: by qcsc20 with SMTP id c20so1453419qcs.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 04:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=gPXRNokZAYkx57cqQG20TOWBxb50OTDUrKodfdLZQrQ=;
	b=G3FU+AU+TXg5m1D/V0t34eFluIOSdKQUBK4U+tEKsMKZzbH10SsPdPa6I5BtUnBlWq
	ycFOSapXSq2vx32ISFLhghhOnSDefipp1ekhpkizybvpHmyfJDSMLDRCdPCKGTXHTubH
	V+Di0kzU2XETPMDlpcrxGEU2wrupIlINdFjGdRJBSxhJO9DszmQr97vDcV7IJNTcFVtS
	QrvlZUFVIcYhZhGrzntdQJkO45VMVduvoTHCYVQNbnmlgjwraURnCTq42DhYEFA/cM/u
	leIiXQ6KMiUloJnjuoFYAAm0nH0l2PHzwkED21/Dn151O624l+Jx1nJ9C5ziOr2NWZ4u
	NHlA==
MIME-Version: 1.0
Received: by 10.229.115.5 with SMTP id g5mr800412qcq.23.1334229159963; Thu, 12
	Apr 2012 04:12:39 -0700 (PDT)
Received: by 10.224.58.204 with HTTP; Thu, 12 Apr 2012 04:12:39 -0700 (PDT)
Date: Thu, 12 Apr 2012 19:12:39 +0800
Message-ID: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
From: zhihao wang <accept.acm@gmail.com>
To: xen-devel@lists.xen.org
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6056161867552999244=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6056161867552999244==
Content-Type: multipart/alternative; boundary=00235429d05020ee0e04bd796f4c

--00235429d05020ee0e04bd796f4c
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64, Mac
pro. After running ./configure and make. I got the following fatal error:

*libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
directory compilation terminated.*

So the original libxlu_cfg_l.h is deleted when making, and should be
regenerated but it is not.  I find the path of flex and bison is not set.
When I add the correct path of flex and bison in tools.mk manually, This
error is fixed.

So, Is there anything in build scripts to modify to avoid this error ?

Regards

Wangzhihao

--00235429d05020ee0e04bd796f4c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<br><br>I try to build xen 4.2( revision number: 	25161)


=09
=09
=09
	on Ubuntu 11.10_amd64, Mac pro. After running ./configure and make. I got =
the following fatal error:<br><br><div style=3D"text-align:center"><i>libxl=
u_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or directory com=
pilation terminated.</i><br>
</div><br>So the original libxlu_cfg_l.h is deleted when making, and should=
 be regenerated but it is not.=A0 I find the path of flex and bison is not =
set.=A0 When I add the correct path of flex and bison in <a href=3D"http://=
tools.mk" target=3D"_blank">tools.mk</a> manually, This error is fixed. <br=
>
<br>So, Is there anything in build scripts to modify to avoid this error ? =
<br><br>Regards<br><br>Wangzhihao<br><br><br><br><p style=3D"margin-bottom:=
0in"><br>
</p>


--00235429d05020ee0e04bd796f4c--


--===============6056161867552999244==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6056161867552999244==--


From xen-devel-bounces@lists.xen.org Thu Apr 12 11:12:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHxE-0004bz-Oe; Thu, 12 Apr 2012 11:12:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SIHxD-0004bn-0M
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:12:43 +0000
Received: from [85.158.138.51:30016] by server-10.bemta-3.messagelabs.com id
	61/49-29478-AA8B68F4; Thu, 12 Apr 2012 11:12:42 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334229160!21826849!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32307 invoked from network); 12 Apr 2012 11:12:41 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:12:41 -0000
Received: by qcsc20 with SMTP id c20so1453419qcs.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 04:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=gPXRNokZAYkx57cqQG20TOWBxb50OTDUrKodfdLZQrQ=;
	b=G3FU+AU+TXg5m1D/V0t34eFluIOSdKQUBK4U+tEKsMKZzbH10SsPdPa6I5BtUnBlWq
	ycFOSapXSq2vx32ISFLhghhOnSDefipp1ekhpkizybvpHmyfJDSMLDRCdPCKGTXHTubH
	V+Di0kzU2XETPMDlpcrxGEU2wrupIlINdFjGdRJBSxhJO9DszmQr97vDcV7IJNTcFVtS
	QrvlZUFVIcYhZhGrzntdQJkO45VMVduvoTHCYVQNbnmlgjwraURnCTq42DhYEFA/cM/u
	leIiXQ6KMiUloJnjuoFYAAm0nH0l2PHzwkED21/Dn151O624l+Jx1nJ9C5ziOr2NWZ4u
	NHlA==
MIME-Version: 1.0
Received: by 10.229.115.5 with SMTP id g5mr800412qcq.23.1334229159963; Thu, 12
	Apr 2012 04:12:39 -0700 (PDT)
Received: by 10.224.58.204 with HTTP; Thu, 12 Apr 2012 04:12:39 -0700 (PDT)
Date: Thu, 12 Apr 2012 19:12:39 +0800
Message-ID: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
From: zhihao wang <accept.acm@gmail.com>
To: xen-devel@lists.xen.org
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6056161867552999244=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6056161867552999244==
Content-Type: multipart/alternative; boundary=00235429d05020ee0e04bd796f4c

--00235429d05020ee0e04bd796f4c
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64, Mac
pro. After running ./configure and make. I got the following fatal error:

*libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
directory compilation terminated.*

So the original libxlu_cfg_l.h is deleted when making, and should be
regenerated but it is not.  I find the path of flex and bison is not set.
When I add the correct path of flex and bison in tools.mk manually, This
error is fixed.

So, Is there anything in build scripts to modify to avoid this error ?

Regards

Wangzhihao

--00235429d05020ee0e04bd796f4c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<br><br>I try to build xen 4.2( revision number: 	25161)


=09
=09
=09
	on Ubuntu 11.10_amd64, Mac pro. After running ./configure and make. I got =
the following fatal error:<br><br><div style=3D"text-align:center"><i>libxl=
u_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or directory com=
pilation terminated.</i><br>
</div><br>So the original libxlu_cfg_l.h is deleted when making, and should=
 be regenerated but it is not.=A0 I find the path of flex and bison is not =
set.=A0 When I add the correct path of flex and bison in <a href=3D"http://=
tools.mk" target=3D"_blank">tools.mk</a> manually, This error is fixed. <br=
>
<br>So, Is there anything in build scripts to modify to avoid this error ? =
<br><br>Regards<br><br>Wangzhihao<br><br><br><br><p style=3D"margin-bottom:=
0in"><br>
</p>


--00235429d05020ee0e04bd796f4c--


--===============6056161867552999244==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6056161867552999244==--


From xen-devel-bounces@lists.xen.org Thu Apr 12 11:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHye-0004hr-7n; Thu, 12 Apr 2012 11:14:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHyc-0004hi-7Y
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:14:10 +0000
Received: from [85.158.143.35:57114] by server-1.bemta-4.messagelabs.com id
	B2/7B-20925-109B68F4; Thu, 12 Apr 2012 11:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334229247!4519158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25364 invoked from network); 12 Apr 2012 11:14:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:14:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:14:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:14:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIHyY-00054l-LQ; Thu, 12 Apr 2012 11:14:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIHyY-0005Wz-KR;
	Thu, 12 Apr 2012 12:14:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.47358.603023.867865@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:14:06 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333622430.937.79.camel@zakaz.uk.xensource.com>
References: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
	<1333622430.937.79.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'"):
> On Thu, 2012-04-05 at 11:25 +0100, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1333621466 -3600
> > # Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
> > # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> > tools/blktap2: fix 'make clean'
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Somebody reported a build error which looked very much like a symptom of
> something not getting cleaned up like this a couple of days ago --
> unfortunately I can't remember who or where or I'd cc them.
> 
> Anyway: 
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I have applied this.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIHye-0004hr-7n; Thu, 12 Apr 2012 11:14:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIHyc-0004hi-7Y
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:14:10 +0000
Received: from [85.158.143.35:57114] by server-1.bemta-4.messagelabs.com id
	B2/7B-20925-109B68F4; Thu, 12 Apr 2012 11:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334229247!4519158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25364 invoked from network); 12 Apr 2012 11:14:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:14:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:14:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:14:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIHyY-00054l-LQ; Thu, 12 Apr 2012 11:14:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIHyY-0005Wz-KR;
	Thu, 12 Apr 2012 12:14:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.47358.603023.867865@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:14:06 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1333622430.937.79.camel@zakaz.uk.xensource.com>
References: <4b6bf18b6790e3713ddc.1333621543@whitby.uk.xensource.com>
	<1333622430.937.79.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/blktap2: fix 'make clean'"):
> On Thu, 2012-04-05 at 11:25 +0100, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1333621466 -3600
> > # Node ID 4b6bf18b6790e3713ddc4fdc1d63e54b4635c57b
> > # Parent  d690c7e896a26c54a5ab85458824059de72d5cba
> > tools/blktap2: fix 'make clean'
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Somebody reported a build error which looked very much like a symptom of
> something not getting cleaned up like this a couple of days ago --
> unfortunately I can't remember who or where or I'd cc them.
> 
> Anyway: 
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I have applied this.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3E-0004ws-TS; Thu, 12 Apr 2012 11:18:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3D-0004wh-O5
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:18:55 +0000
Received: from [85.158.143.99:41988] by server-3.bemta-4.messagelabs.com id
	5D/9F-05853-F1AB68F4; Thu, 12 Apr 2012 11:18:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334229534!23021773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27561 invoked from network); 12 Apr 2012 11:18:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:18:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:18:54 +0100
Date: Thu, 12 Apr 2012 12:22:40 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

The QEMU side of this patch series has been accepted, so it is now safe
to commit it to xen-unstable.


Changes in v7:
- log error messages on error paths;

- make the toolstack save/restore functions more readable.


Changes in v6:

- rebased on "kexec: Fix printing of paddr_t in 32bit mode.";

- use the command "xen-save-devices-state" to save the QEMU devices
state.



Changes in v5:

- rebased on "arm: lr register in hyp mode is really LR_usr.".



Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_domain_restore.c |   47 ++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++
 tools/libxc/xenguest.h          |   23 +++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  174 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +------------------
 tools/xcutils/xc_restore.c      |    2 +-
 8 files changed, 254 insertions(+), 94 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3E-0004ws-TS; Thu, 12 Apr 2012 11:18:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3D-0004wh-O5
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:18:55 +0000
Received: from [85.158.143.99:41988] by server-3.bemta-4.messagelabs.com id
	5D/9F-05853-F1AB68F4; Thu, 12 Apr 2012 11:18:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334229534!23021773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27561 invoked from network); 12 Apr 2012 11:18:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:18:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:18:54 +0100
Date: Thu, 12 Apr 2012 12:22:40 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

The QEMU side of this patch series has been accepted, so it is now safe
to commit it to xen-unstable.


Changes in v7:
- log error messages on error paths;

- make the toolstack save/restore functions more readable.


Changes in v6:

- rebased on "kexec: Fix printing of paddr_t in 32bit mode.";

- use the command "xen-save-devices-state" to save the QEMU devices
state.



Changes in v5:

- rebased on "arm: lr register in hyp mode is really LR_usr.".



Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_domain_restore.c |   47 ++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++
 tools/libxc/xenguest.h          |   23 +++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  174 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +------------------
 tools/xcutils/xc_restore.c      |    2 +-
 8 files changed, 254 insertions(+), 94 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3F-0004wz-9K; Thu, 12 Apr 2012 11:18:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SII3D-0004wi-Qa
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:18:56 +0000
Received: from [85.158.143.35:11428] by server-2.bemta-4.messagelabs.com id
	A3/CB-17550-F1AB68F4; Thu, 12 Apr 2012 11:18:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334229531!4618475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25851 invoked from network); 12 Apr 2012 11:18:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:18:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:18:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SII38-00059c-Pf; Thu, 12 Apr 2012 11:18:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SII38-0005XT-Oj;
	Thu, 12 Apr 2012 12:18:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.47642.750789.96463@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:18:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334219781.12209.256.camel@dagon.hellion.org.uk>
References: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
	<1334219781.12209.256.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden"):
> BTW, I noticed a bunch of libxl__ functions which take a ctx instead of
> a gc while doing this.

Yes, there are a few.

In some cases this is to make it easier to call them from
infrastructure or macros which doesn't necessarily have a gc, eg the
logging functions, and the way that libxl__ao_create obviously is
_creating_ the gc (as well as the ao) for its caller.

In other cases it's just to avoid needlessly pratting about with
GC_INIT.  (Note that in the past, that pratting about was considerably
more verbose.)

It isn't in general a bug to have nested calls to GC_INIT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3F-0004wz-9K; Thu, 12 Apr 2012 11:18:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SII3D-0004wi-Qa
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:18:56 +0000
Received: from [85.158.143.35:11428] by server-2.bemta-4.messagelabs.com id
	A3/CB-17550-F1AB68F4; Thu, 12 Apr 2012 11:18:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334229531!4618475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25851 invoked from network); 12 Apr 2012 11:18:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:18:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:18:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SII38-00059c-Pf; Thu, 12 Apr 2012 11:18:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SII38-0005XT-Oj;
	Thu, 12 Apr 2012 12:18:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.47642.750789.96463@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:18:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334219781.12209.256.camel@dagon.hellion.org.uk>
References: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
	<1334219781.12209.256.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden"):
> BTW, I noticed a bunch of libxl__ functions which take a ctx instead of
> a gc while doing this.

Yes, there are a few.

In some cases this is to make it easier to call them from
infrastructure or macros which doesn't necessarily have a gc, eg the
logging functions, and the way that libxl__ao_create obviously is
_creating_ the gc (as well as the ao) for its caller.

In other cases it's just to avoid needlessly pratting about with
GC_INIT.  (Note that in the past, that pratting about was considerably
more verbose.)

It isn't in general a bug to have nested calls to GC_INIT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3n-00052G-Fg; Thu, 12 Apr 2012 11:19:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3l-00051d-OQ
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:19:30 +0000
Received: from [85.158.138.51:30595] by server-9.bemta-3.messagelabs.com id
	24/23-26691-04AB68F4; Thu, 12 Apr 2012 11:19:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334229564!21800965!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6663 invoked from network); 12 Apr 2012 11:19:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:19:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190010410"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:19:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:19:23 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SII3a-0000eB-9K; Thu, 12 Apr 2012 12:19:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Apr 2012 12:23:19 +0100
Message-ID: <1334229799-28530-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "xen-save-devices-state" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "xen-save-devices-state".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1eb328b..b209262 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -845,18 +845,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b5cce17 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1028,7 +1028,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..9a6ecb6 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -538,52 +538,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -817,34 +771,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -854,23 +782,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3n-00052G-Fg; Thu, 12 Apr 2012 11:19:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3l-00051d-OQ
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:19:30 +0000
Received: from [85.158.138.51:30595] by server-9.bemta-3.messagelabs.com id
	24/23-26691-04AB68F4; Thu, 12 Apr 2012 11:19:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334229564!21800965!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6663 invoked from network); 12 Apr 2012 11:19:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:19:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190010410"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:19:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:19:23 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SII3a-0000eB-9K; Thu, 12 Apr 2012 12:19:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Apr 2012 12:23:19 +0100
Message-ID: <1334229799-28530-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "xen-save-devices-state" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "xen-save-devices-state".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1eb328b..b209262 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -845,18 +845,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b5cce17 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1028,7 +1028,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..9a6ecb6 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -538,52 +538,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -817,34 +771,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -854,23 +782,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3l-00051j-NA; Thu, 12 Apr 2012 11:19:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3k-00051N-9J
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:19:28 +0000
Received: from [85.158.138.51:30427] by server-10.bemta-3.messagelabs.com id
	08/3A-29478-F3AB68F4; Thu, 12 Apr 2012 11:19:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334229564!21800965!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6554 invoked from network); 12 Apr 2012 11:19:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190010408"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:19:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:19:23 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SII3a-0000eB-8k; Thu, 12 Apr 2012 12:19:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Apr 2012 12:23:18 +0100
Message-ID: <1334229799-28530-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  163 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 162 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7f140b4..1eb328b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -394,6 +394,79 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
+        uint64_t phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    libxl_ctx *ctx = gc->owner;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+    char *xs_path;
+
+    if (size < sizeof(version) + sizeof(count)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong version");
+        return -1;
+    }
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info))) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "start_addr");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "size");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            xs_path = restore_helper(gc, domid, pi->phys_offset, "name");
+            ret = libxl__xs_write(gc, 0, xs_path, "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -403,6 +476,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -410,6 +484,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -425,7 +501,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -580,6 +656,90 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+        char *phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%s/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    libxl_ctx *ctx = gc->owner;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        char *xs_path;
+        phys_offset = entries[i];
+        if (phys_offset == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        start_addr = libxl__xs_read(gc, 0, xs_path);
+        if (start_addr == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "size");
+        size = libxl__xs_read(gc, 0, xs_path);
+        if (size == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "name");
+        name = libxl__xs_read(gc, 0, xs_path);
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -642,6 +802,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3l-00051j-NA; Thu, 12 Apr 2012 11:19:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3k-00051N-9J
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:19:28 +0000
Received: from [85.158.138.51:30427] by server-10.bemta-3.messagelabs.com id
	08/3A-29478-F3AB68F4; Thu, 12 Apr 2012 11:19:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334229564!21800965!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6554 invoked from network); 12 Apr 2012 11:19:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190010408"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:19:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:19:23 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SII3a-0000eB-8k; Thu, 12 Apr 2012 12:19:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Apr 2012 12:23:18 +0100
Message-ID: <1334229799-28530-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  163 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 162 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7f140b4..1eb328b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -394,6 +394,79 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
+        uint64_t phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    libxl_ctx *ctx = gc->owner;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+    char *xs_path;
+
+    if (size < sizeof(version) + sizeof(count)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong version");
+        return -1;
+    }
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info))) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "start_addr");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "size");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            xs_path = restore_helper(gc, domid, pi->phys_offset, "name");
+            ret = libxl__xs_write(gc, 0, xs_path, "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -403,6 +476,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -410,6 +484,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -425,7 +501,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -580,6 +656,90 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+        char *phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%s/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    libxl_ctx *ctx = gc->owner;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        char *xs_path;
+        phys_offset = entries[i];
+        if (phys_offset == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        start_addr = libxl__xs_read(gc, 0, xs_path);
+        if (start_addr == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "size");
+        size = libxl__xs_read(gc, 0, xs_path);
+        if (size == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "name");
+        name = libxl__xs_read(gc, 0, xs_path);
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -642,6 +802,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3n-000524-48; Thu, 12 Apr 2012 11:19:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3k-00051W-UH
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:19:29 +0000
Received: from [85.158.138.51:26490] by server-12.bemta-3.messagelabs.com id
	14/41-29760-04AB68F4; Thu, 12 Apr 2012 11:19:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334229564!21800965!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6602 invoked from network); 12 Apr 2012 11:19:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:19:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190010409"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:19:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:19:23 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SII3a-0000eB-82; Thu, 12 Apr 2012 12:19:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Apr 2012 12:23:17 +0100
Message-ID: <1334229799-28530-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   47 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 88 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3e4d518..5ad41b6 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -685,6 +690,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -695,6 +702,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -863,6 +874,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1299,7 +1323,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1347,6 +1372,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1359,6 +1385,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1624,6 +1651,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2074,6 +2105,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    } else if ( tdata.data != NULL )
+        ERROR("toolstack data available but no toolstack callback provided\n");
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a9216dd..fcc7718 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1723,6 +1723,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 8d885d3..6435f65 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -83,7 +103,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 89f3504..04e7892 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -258,6 +258,7 @@
 #define XC_SAVE_ID_HVM_PAGING_RING_PFN  -15
 #define XC_SAVE_ID_HVM_ACCESS_RING_PFN  -16
 #define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
+#define XC_SAVE_ID_TOOLSTACK          -18 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..7f140b4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -425,7 +425,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index e41a133..0235579 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
                             console_evtchn, &console_mfn, 0, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:19:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII3n-000524-48; Thu, 12 Apr 2012 11:19:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SII3k-00051W-UH
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:19:29 +0000
Received: from [85.158.138.51:26490] by server-12.bemta-3.messagelabs.com id
	14/41-29760-04AB68F4; Thu, 12 Apr 2012 11:19:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334229564!21800965!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6602 invoked from network); 12 Apr 2012 11:19:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:19:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190010409"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:19:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:19:23 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SII3a-0000eB-82; Thu, 12 Apr 2012 12:19:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Apr 2012 12:23:17 +0100
Message-ID: <1334229799-28530-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204121201500.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   47 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 88 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3e4d518..5ad41b6 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -685,6 +690,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -695,6 +702,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -863,6 +874,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1299,7 +1323,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1347,6 +1372,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1359,6 +1385,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1624,6 +1651,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2074,6 +2105,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    } else if ( tdata.data != NULL )
+        ERROR("toolstack data available but no toolstack callback provided\n");
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a9216dd..fcc7718 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1723,6 +1723,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 8d885d3..6435f65 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -83,7 +103,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 89f3504..04e7892 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -258,6 +258,7 @@
 #define XC_SAVE_ID_HVM_PAGING_RING_PFN  -15
 #define XC_SAVE_ID_HVM_ACCESS_RING_PFN  -16
 #define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
+#define XC_SAVE_ID_TOOLSTACK          -18 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..7f140b4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -425,7 +425,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index e41a133..0235579 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
                             console_evtchn, &console_mfn, 0, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:24:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII8i-0005r7-3u; Thu, 12 Apr 2012 11:24:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SII8h-0005qn-06
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:24:35 +0000
Received: from [193.109.254.147:65306] by server-8.bemta-14.messagelabs.com id
	D6/56-23244-27BB68F4; Thu, 12 Apr 2012 11:24:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334229873!4270721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9681 invoked from network); 12 Apr 2012 11:24:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899783"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:24:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 12:24:33 +0100
Message-ID: <1334229871.16387.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: zhihao wang <accept.acm@gmail.com>
Date: Thu, 12 Apr 2012 12:24:31 +0100
In-Reply-To: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
> Hi all,
> 
> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
> Mac pro. After running ./configure and make. I got the following fatal
> error:
> 
> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
> directory compilation terminated.
> 
> 
> So the original libxlu_cfg_l.h is deleted when making, and should be
> regenerated but it is not.

Actually it should never have been deleted in the first place, unless
you have been modifying the flex source.

Please can you enumerate the exact steps you took, starting from the
initial clone of the repo, which caused the file to be deleted?

> I find the path of flex and bison is not set.  When I add the correct
> path of flex and bison in tools.mk manually, This error is fixed. 

Those tools should be optional since the generated files are checked in.
However perhaps configure should detect and provide the paths but behave
in a non-fatal manner if they aren't available? Roger, what do you
think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:24:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SII8i-0005r7-3u; Thu, 12 Apr 2012 11:24:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SII8h-0005qn-06
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:24:35 +0000
Received: from [193.109.254.147:65306] by server-8.bemta-14.messagelabs.com id
	D6/56-23244-27BB68F4; Thu, 12 Apr 2012 11:24:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334229873!4270721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9681 invoked from network); 12 Apr 2012 11:24:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11899783"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:24:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 12:24:33 +0100
Message-ID: <1334229871.16387.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: zhihao wang <accept.acm@gmail.com>
Date: Thu, 12 Apr 2012 12:24:31 +0100
In-Reply-To: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
> Hi all,
> 
> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
> Mac pro. After running ./configure and make. I got the following fatal
> error:
> 
> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
> directory compilation terminated.
> 
> 
> So the original libxlu_cfg_l.h is deleted when making, and should be
> regenerated but it is not.

Actually it should never have been deleted in the first place, unless
you have been modifying the flex source.

Please can you enumerate the exact steps you took, starting from the
initial clone of the repo, which caused the file to be deleted?

> I find the path of flex and bison is not set.  When I add the correct
> path of flex and bison in tools.mk manually, This error is fixed. 

Those tools should be optional since the generated files are checked in.
However perhaps configure should detect and provide the paths but behave
in a non-fatal manner if they aren't available? Roger, what do you
think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:28:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIICf-00065k-PS; Thu, 12 Apr 2012 11:28:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIICe-00065d-5K
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:28:40 +0000
Received: from [85.158.143.99:21388] by server-3.bemta-4.messagelabs.com id
	34/C0-05853-76CB68F4; Thu, 12 Apr 2012 11:28:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334230117!24785028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10464 invoked from network); 12 Apr 2012 11:28:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:28:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190011585"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:28:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:28:36 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIICa-0000lU-LN;
	Thu, 12 Apr 2012 12:28:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: f89c5bdf26a18b49741e0e843a5cc614b6ac4f95
Message-ID: <f89c5bdf26a18b49741e.1334230018@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 12 Apr 2012 12:26:58 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen: Fix failure paths for xentrace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Problems this addresses:
* After the allocation of t_info fails, the path the code takes tries to
free t_info.  Jump past that part instead.
* The failure code assumes that unused data is zero; but the structure
is never initialized.  Zero the structure before using it.
* The t_info pages are shared with dom0 before we know that the whole
operation will succeed, and not un-shared afterwards.  Don't share the
pages until we know the whole thing will succeed.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 08ae34c0c162 -r f89c5bdf26a1 xen/common/trace.c
--- a/xen/common/trace.c	Wed Apr 11 11:36:43 2012 +0100
+++ b/xen/common/trace.c	Thu Apr 12 12:26:29 2012 +0100
@@ -187,14 +187,12 @@ static int alloc_trace_bufs(unsigned int
 
     t_info = alloc_xenheap_pages(get_order_from_pages(t_info_pages), 0);
     if ( t_info == NULL )
-        goto out_dealloc_t_info;
+        goto out_fail;
+
+    memset(t_info, 0, t_info_pages*PAGE_SIZE);
 
     t_info_mfn_list = (uint32_t *)t_info;
 
-    for(i = 0; i < t_info_pages; i++)
-        share_xen_page_with_privileged_guests(
-            virt_to_page(t_info) + i, XENSHARE_readonly);
-
     t_info->tbuf_size = pages;
 
     /*
@@ -247,6 +245,11 @@ static int alloc_trace_bufs(unsigned int
         }
     }
 
+    /* Finally, share the t_info page */
+    for(i = 0; i < t_info_pages; i++)
+        share_xen_page_with_privileged_guests(
+            virt_to_page(t_info) + i, XENSHARE_readonly);
+
     data_size  = (pages * PAGE_SIZE - sizeof(struct t_buf));
     t_buf_highwater = data_size >> 1; /* 50% high water */
     opt_tbuf_size = pages;
@@ -272,9 +275,9 @@ out_dealloc:
             free_xenheap_pages(mfn_to_virt(mfn), 0);
         }
     }
-out_dealloc_t_info:
     free_xenheap_pages(t_info, get_order_from_pages(t_info_pages));
     t_info = NULL;
+out_fail:
     printk(XENLOG_WARNING "xentrace: allocation failed! Tracing disabled.\n");
     return -ENOMEM;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:28:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIICf-00065k-PS; Thu, 12 Apr 2012 11:28:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIICe-00065d-5K
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:28:40 +0000
Received: from [85.158.143.99:21388] by server-3.bemta-4.messagelabs.com id
	34/C0-05853-76CB68F4; Thu, 12 Apr 2012 11:28:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334230117!24785028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10464 invoked from network); 12 Apr 2012 11:28:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:28:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="190011585"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:28:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:28:36 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIICa-0000lU-LN;
	Thu, 12 Apr 2012 12:28:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: f89c5bdf26a18b49741e0e843a5cc614b6ac4f95
Message-ID: <f89c5bdf26a18b49741e.1334230018@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 12 Apr 2012 12:26:58 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen: Fix failure paths for xentrace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Problems this addresses:
* After the allocation of t_info fails, the path the code takes tries to
free t_info.  Jump past that part instead.
* The failure code assumes that unused data is zero; but the structure
is never initialized.  Zero the structure before using it.
* The t_info pages are shared with dom0 before we know that the whole
operation will succeed, and not un-shared afterwards.  Don't share the
pages until we know the whole thing will succeed.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 08ae34c0c162 -r f89c5bdf26a1 xen/common/trace.c
--- a/xen/common/trace.c	Wed Apr 11 11:36:43 2012 +0100
+++ b/xen/common/trace.c	Thu Apr 12 12:26:29 2012 +0100
@@ -187,14 +187,12 @@ static int alloc_trace_bufs(unsigned int
 
     t_info = alloc_xenheap_pages(get_order_from_pages(t_info_pages), 0);
     if ( t_info == NULL )
-        goto out_dealloc_t_info;
+        goto out_fail;
+
+    memset(t_info, 0, t_info_pages*PAGE_SIZE);
 
     t_info_mfn_list = (uint32_t *)t_info;
 
-    for(i = 0; i < t_info_pages; i++)
-        share_xen_page_with_privileged_guests(
-            virt_to_page(t_info) + i, XENSHARE_readonly);
-
     t_info->tbuf_size = pages;
 
     /*
@@ -247,6 +245,11 @@ static int alloc_trace_bufs(unsigned int
         }
     }
 
+    /* Finally, share the t_info page */
+    for(i = 0; i < t_info_pages; i++)
+        share_xen_page_with_privileged_guests(
+            virt_to_page(t_info) + i, XENSHARE_readonly);
+
     data_size  = (pages * PAGE_SIZE - sizeof(struct t_buf));
     t_buf_highwater = data_size >> 1; /* 50% high water */
     opt_tbuf_size = pages;
@@ -272,9 +275,9 @@ out_dealloc:
             free_xenheap_pages(mfn_to_virt(mfn), 0);
         }
     }
-out_dealloc_t_info:
     free_xenheap_pages(t_info, get_order_from_pages(t_info_pages));
     t_info = NULL;
+out_fail:
     printk(XENLOG_WARNING "xentrace: allocation failed! Tracing disabled.\n");
     return -ENOMEM;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:29:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:29:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIID9-00068J-68; Thu, 12 Apr 2012 11:29:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1SIID7-000684-DZ
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:29:09 +0000
Received: from [193.109.254.147:3709] by server-11.bemta-14.messagelabs.com id
	75/4C-05858-48CB68F4; Thu, 12 Apr 2012 11:29:08 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334230147!4302447!1
X-Originating-IP: [77.238.189.66]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31520 invoked from network); 12 Apr 2012 11:29:07 -0000
Received: from nm13.bullet.mail.ird.yahoo.com (HELO
	nm13.bullet.mail.ird.yahoo.com) (77.238.189.66)
	by server-13.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 11:29:07 -0000
Received: from [77.238.189.48] by nm13.bullet.mail.ird.yahoo.com with NNFMP;
	12 Apr 2012 11:29:07 -0000
Received: from [212.82.108.243] by tm1.bullet.mail.ird.yahoo.com with NNFMP;
	12 Apr 2012 11:29:07 -0000
Received: from [127.0.0.1] by omp1008.mail.ird.yahoo.com with NNFMP;
	12 Apr 2012 11:29:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 677004.58564.bm@omp1008.mail.ird.yahoo.com
Received: (qmail 30015 invoked by uid 60001); 12 Apr 2012 11:29:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1334230147; bh=8I+79AuEyU2yFqMJO1QBBWNb+fWLVrPiXN9A4IKt4yE=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=PVpC8vEvBEvhMiywQbcso0px0QPqZTjJB6AGNxILK/Ss5rtWl/BLSKsuLVhCUX9Pvvfpv9NKSxbSTZkIOdrxh7SSkupmJSzaGsZDeXR//NHMCWnM4n3Ikgc9MTvsfVXukGzfM3Z5D8fHRiFbBHdrp3KfHeDc5H8p3J2FYa0OVjs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=p+XDn8SRflpYBuUUymIkNd5gGsW6WF904MZrrKfaK07LDjj30N1Awlxajc6m0ulNuBH7iWTSnAf5Vj85Cl02Q8HAtn/AJxIG/1TBh4g3NJe8Srx+cCvevIq9skkafBxsiX1vADVleOporwceIqja2ejcRJciYR1qbiX0mg8WNMc=;
X-YMail-OSG: 7NZCQaYVM1k9GWT3pWdaO_AR73t5uYYiHHpPY4hNSgnqECl
	bHVIKinGpwcRfoJNH6uA7SRfVvVxXg94LFxjn9w2y1k_Kf.UOnpX87cNjnkB
	R6WbxLHyBHFvmPaAC7aVsimvPSOgViMnllVE9qLvwoqn_pZneY.oClNQ4.lw
	JSVf4oQlh1TsOmn7.pOdBY6.aSwZpDxzcFvsfnEoNNkvDn5HMWRRVQpSOGrs
	2cz_clRnoF_JCEhlFmQ6KlgI62PMaRgjDMlOM0vsK2BN32AG0fdwKHUzc54e
	mzbZBhKc1_qPOC03SDSHueFYTgGAEwygw3LR6hTQ5zJ0xjn1Y0SkxVVO_GPm
	TQXsjs4VVRQPg_gShI7PO2ArXKx_OT17ey_wTY_n1Si.qSMQAx5PoVCtwFhb
	DJo6PzpUOFdL7nf37cUzhHvLt4Oz.EfEO9FxJbkEyJq0PSiI1CHvvymLWXU_
	kdy40eFcY6ftIqS5iNPPzgnE6J9g-
Received: from [195.167.237.98] by web29805.mail.ird.yahoo.com via HTTP;
	Thu, 12 Apr 2012 12:29:07 BST
X-Mailer: YahooMailWebService/0.8.117.340979
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
Message-ID: <1334230147.25009.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Thu, 12 Apr 2012 12:29:07 +0100 (BST)
From: David TECHER <davidtecher@yahoo.fr>
To: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
MIME-Version: 1.0
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Re :  fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0432555564010299714=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0432555564010299714==
Content-Type: multipart/alternative; boundary="62747910-797829268-1334230147=:25009"

--62747910-797829268-1334230147=:25009
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

BISON=3D$(which bison) FLEX=3D$(which flex) CURL=3D$(which curl-config) XML=
=3D$(which xml2-config) ./configure=0A=0A=0A_______________________________=
_=0A De=A0: zhihao wang <accept.acm@gmail.com>=0A=C0=A0: xen-devel@lists.xe=
n.org =0ACc=A0: Ian.Campbell@citrix.com =0AEnvoy=E9 le : Jeudi 12 avril 201=
2 13h12=0AObjet=A0: [Xen-devel] fatal error if Flex and Bison is not config=
ured=0A =0A=0AHi all,=0A=0AI try to build xen 4.2( revision number: =092516=
1)=0A=0A=0A=09=0A=09=0A=09=0A=09on Ubuntu 11.10_amd64, Mac pro. After runni=
ng ./configure and make. I got the following fatal error:=0A=0A=0Alibxlu_cf=
g_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or directory compila=
tion terminated.=0A=0ASo the original libxlu_cfg_l.h is deleted when making=
, and should be regenerated but it is not.=A0 I find the path of flex and b=
ison is not set.=A0 When I add the correct path of flex and bison in tools.=
mk manually, This error is fixed. =0A=0ASo, Is there anything in build scri=
pts to modify to avoid this error ? =0A=0ARegards=0A=0AWangzhihao=0A=0A=0A=
=0A=0A=0A_______________________________________________=0AXen-devel mailin=
g list=0AXen-devel@lists.xen.org=0Ahttp://lists.xen.org/xen-devel
--62747910-797829268-1334230147=:25009
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><pre>BISON=3D$(which =
bison) FLEX=3D$(which flex) CURL=3D$(which curl-config) XML=3D$(which xml2-=
config) ./configure</pre><div><br></div>  <div style=3D"font-family: times =
new roman, new york, times, serif; font-size: 12pt;"> <div style=3D"font-fa=
mily: times new roman, new york, times, serif; font-size: 12pt;"> <div dir=
=3D"ltr"> <font face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=
=3D"font-weight:bold;">De&nbsp;:</span></b> zhihao wang &lt;accept.acm@gmai=
l.com&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</span></b> x=
en-devel@lists.xen.org <br><b><span style=3D"font-weight: bold;">Cc&nbsp;:<=
/span></b> Ian.Campbell@citrix.com <br> <b><span style=3D"font-weight: bold=
;">Envoy=E9 le :</span></b> Jeudi 12 avril 2012 13h12<br> <b><span style=3D=
"font-weight: bold;">Objet&nbsp;:</span></b> [Xen-devel] fatal error if Fle=
x and Bison is not
 configured<br> </font> </div> <br><div id=3D"yiv577803322">Hi all,<br><br>=
I try to build xen 4.2( revision number: =0925161)=0A=0A=0A=09=0A=09=0A=09=
=0A=09on Ubuntu 11.10_amd64, Mac pro. After running ./configure and make. I=
 got the following fatal error:<br><br><div style=3D"text-align:center;"><i=
>libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or directo=
ry compilation terminated.</i><br>=0A</div><br>So the original libxlu_cfg_l=
.h is deleted when making, and should be regenerated but it is not.&nbsp; I=
 find the path of flex and bison is not set.&nbsp; When I add the correct p=
ath of flex and bison in <a rel=3D"nofollow" target=3D"_blank" href=3D"http=
://tools.mk">tools.mk</a> manually, This error is fixed. <br>=0A<br>So, Is =
there anything in build scripts to modify to avoid this error ? <br><br>Reg=
ards<br><br>Wangzhihao<br><br><br><br><div style=3D"margin-bottom:0in;"><br=
>=0A</div>=0A=0A</div><br>_______________________________________________<b=
r>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xen.org" h=
ref=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br><a hr=
ef=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xen.or=
g/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--62747910-797829268-1334230147=:25009--


--===============0432555564010299714==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0432555564010299714==--


From xen-devel-bounces@lists.xen.org Thu Apr 12 11:29:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:29:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIID9-00068J-68; Thu, 12 Apr 2012 11:29:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1SIID7-000684-DZ
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:29:09 +0000
Received: from [193.109.254.147:3709] by server-11.bemta-14.messagelabs.com id
	75/4C-05858-48CB68F4; Thu, 12 Apr 2012 11:29:08 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334230147!4302447!1
X-Originating-IP: [77.238.189.66]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31520 invoked from network); 12 Apr 2012 11:29:07 -0000
Received: from nm13.bullet.mail.ird.yahoo.com (HELO
	nm13.bullet.mail.ird.yahoo.com) (77.238.189.66)
	by server-13.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 11:29:07 -0000
Received: from [77.238.189.48] by nm13.bullet.mail.ird.yahoo.com with NNFMP;
	12 Apr 2012 11:29:07 -0000
Received: from [212.82.108.243] by tm1.bullet.mail.ird.yahoo.com with NNFMP;
	12 Apr 2012 11:29:07 -0000
Received: from [127.0.0.1] by omp1008.mail.ird.yahoo.com with NNFMP;
	12 Apr 2012 11:29:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 677004.58564.bm@omp1008.mail.ird.yahoo.com
Received: (qmail 30015 invoked by uid 60001); 12 Apr 2012 11:29:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1334230147; bh=8I+79AuEyU2yFqMJO1QBBWNb+fWLVrPiXN9A4IKt4yE=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=PVpC8vEvBEvhMiywQbcso0px0QPqZTjJB6AGNxILK/Ss5rtWl/BLSKsuLVhCUX9Pvvfpv9NKSxbSTZkIOdrxh7SSkupmJSzaGsZDeXR//NHMCWnM4n3Ikgc9MTvsfVXukGzfM3Z5D8fHRiFbBHdrp3KfHeDc5H8p3J2FYa0OVjs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=p+XDn8SRflpYBuUUymIkNd5gGsW6WF904MZrrKfaK07LDjj30N1Awlxajc6m0ulNuBH7iWTSnAf5Vj85Cl02Q8HAtn/AJxIG/1TBh4g3NJe8Srx+cCvevIq9skkafBxsiX1vADVleOporwceIqja2ejcRJciYR1qbiX0mg8WNMc=;
X-YMail-OSG: 7NZCQaYVM1k9GWT3pWdaO_AR73t5uYYiHHpPY4hNSgnqECl
	bHVIKinGpwcRfoJNH6uA7SRfVvVxXg94LFxjn9w2y1k_Kf.UOnpX87cNjnkB
	R6WbxLHyBHFvmPaAC7aVsimvPSOgViMnllVE9qLvwoqn_pZneY.oClNQ4.lw
	JSVf4oQlh1TsOmn7.pOdBY6.aSwZpDxzcFvsfnEoNNkvDn5HMWRRVQpSOGrs
	2cz_clRnoF_JCEhlFmQ6KlgI62PMaRgjDMlOM0vsK2BN32AG0fdwKHUzc54e
	mzbZBhKc1_qPOC03SDSHueFYTgGAEwygw3LR6hTQ5zJ0xjn1Y0SkxVVO_GPm
	TQXsjs4VVRQPg_gShI7PO2ArXKx_OT17ey_wTY_n1Si.qSMQAx5PoVCtwFhb
	DJo6PzpUOFdL7nf37cUzhHvLt4Oz.EfEO9FxJbkEyJq0PSiI1CHvvymLWXU_
	kdy40eFcY6ftIqS5iNPPzgnE6J9g-
Received: from [195.167.237.98] by web29805.mail.ird.yahoo.com via HTTP;
	Thu, 12 Apr 2012 12:29:07 BST
X-Mailer: YahooMailWebService/0.8.117.340979
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
Message-ID: <1334230147.25009.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Thu, 12 Apr 2012 12:29:07 +0100 (BST)
From: David TECHER <davidtecher@yahoo.fr>
To: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
MIME-Version: 1.0
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Re :  fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0432555564010299714=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0432555564010299714==
Content-Type: multipart/alternative; boundary="62747910-797829268-1334230147=:25009"

--62747910-797829268-1334230147=:25009
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

BISON=3D$(which bison) FLEX=3D$(which flex) CURL=3D$(which curl-config) XML=
=3D$(which xml2-config) ./configure=0A=0A=0A_______________________________=
_=0A De=A0: zhihao wang <accept.acm@gmail.com>=0A=C0=A0: xen-devel@lists.xe=
n.org =0ACc=A0: Ian.Campbell@citrix.com =0AEnvoy=E9 le : Jeudi 12 avril 201=
2 13h12=0AObjet=A0: [Xen-devel] fatal error if Flex and Bison is not config=
ured=0A =0A=0AHi all,=0A=0AI try to build xen 4.2( revision number: =092516=
1)=0A=0A=0A=09=0A=09=0A=09=0A=09on Ubuntu 11.10_amd64, Mac pro. After runni=
ng ./configure and make. I got the following fatal error:=0A=0A=0Alibxlu_cf=
g_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or directory compila=
tion terminated.=0A=0ASo the original libxlu_cfg_l.h is deleted when making=
, and should be regenerated but it is not.=A0 I find the path of flex and b=
ison is not set.=A0 When I add the correct path of flex and bison in tools.=
mk manually, This error is fixed. =0A=0ASo, Is there anything in build scri=
pts to modify to avoid this error ? =0A=0ARegards=0A=0AWangzhihao=0A=0A=0A=
=0A=0A=0A_______________________________________________=0AXen-devel mailin=
g list=0AXen-devel@lists.xen.org=0Ahttp://lists.xen.org/xen-devel
--62747910-797829268-1334230147=:25009
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><pre>BISON=3D$(which =
bison) FLEX=3D$(which flex) CURL=3D$(which curl-config) XML=3D$(which xml2-=
config) ./configure</pre><div><br></div>  <div style=3D"font-family: times =
new roman, new york, times, serif; font-size: 12pt;"> <div style=3D"font-fa=
mily: times new roman, new york, times, serif; font-size: 12pt;"> <div dir=
=3D"ltr"> <font face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=
=3D"font-weight:bold;">De&nbsp;:</span></b> zhihao wang &lt;accept.acm@gmai=
l.com&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</span></b> x=
en-devel@lists.xen.org <br><b><span style=3D"font-weight: bold;">Cc&nbsp;:<=
/span></b> Ian.Campbell@citrix.com <br> <b><span style=3D"font-weight: bold=
;">Envoy=E9 le :</span></b> Jeudi 12 avril 2012 13h12<br> <b><span style=3D=
"font-weight: bold;">Objet&nbsp;:</span></b> [Xen-devel] fatal error if Fle=
x and Bison is not
 configured<br> </font> </div> <br><div id=3D"yiv577803322">Hi all,<br><br>=
I try to build xen 4.2( revision number: =0925161)=0A=0A=0A=09=0A=09=0A=09=
=0A=09on Ubuntu 11.10_amd64, Mac pro. After running ./configure and make. I=
 got the following fatal error:<br><br><div style=3D"text-align:center;"><i=
>libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or directo=
ry compilation terminated.</i><br>=0A</div><br>So the original libxlu_cfg_l=
.h is deleted when making, and should be regenerated but it is not.&nbsp; I=
 find the path of flex and bison is not set.&nbsp; When I add the correct p=
ath of flex and bison in <a rel=3D"nofollow" target=3D"_blank" href=3D"http=
://tools.mk">tools.mk</a> manually, This error is fixed. <br>=0A<br>So, Is =
there anything in build scripts to modify to avoid this error ? <br><br>Reg=
ards<br><br>Wangzhihao<br><br><br><br><div style=3D"margin-bottom:0in;"><br=
>=0A</div>=0A=0A</div><br>_______________________________________________<b=
r>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xen.org" h=
ref=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br><a hr=
ef=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xen.or=
g/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--62747910-797829268-1334230147=:25009--


--===============0432555564010299714==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0432555564010299714==--


From xen-devel-bounces@lists.xen.org Thu Apr 12 11:32:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIGR-0006Nf-Q7; Thu, 12 Apr 2012 11:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIIGP-0006NT-H5
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:32:33 +0000
Received: from [85.158.143.35:47735] by server-1.bemta-4.messagelabs.com id
	C9/6B-20925-05DB68F4; Thu, 12 Apr 2012 11:32:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334230351!18286256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2821 invoked from network); 12 Apr 2012 11:32:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:32:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:32:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:32:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIIGM-0005Lt-M5; Thu, 12 Apr 2012 11:32:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIIGM-0005Yv-LA;
	Thu, 12 Apr 2012 12:32:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.48462.638395.960649@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:32:30 +0100
To: <xen-devel@lists.xen.org>
In-Reply-To: <4F86AD6E.3050705@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Formatting of emails which are comments on patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Someone wrote:
) On 11/04/12 14:17, Dario Faggioli wrote:
) ) [9 lines of quoted prose]
) [3 lines of replying prose]
) )
) ) [1 line of quoted prose]
) )
) ) Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com)
) )
) ) [16 lines of diff, quoted without any elision]
) [4 lines of prose]
) 
) [2 lines of prose]
) 
) [3 lines of prose]
) 
) [2 lines of prose]
) ) [71 lines of diff, quoted without any elision]
) [1 line of prose]
) ) [64 lines of diff, quoted without any elision]

etc.  (I have replaced ">" with ")" to try to subvert email programs
which do something special with quoted text so that you can see what
it looks like to me.)

This is unnecessarily hard to read.  What it looks like on my screen
can be seen here:
  http://www.chiark.greenend.org.uk/~ijackson/2012/email-formatting.png

Can I ask people to:

 * Trim diffs when replying to patches.  There is no need to quote the
   whole patch.  Just quote the parts which are needed to understand
   your comments.

 * Leave a blank line between quoted text of any kind and your own 
   added text.

That will help your comments stand out, and be read.  This is
particularly important if the quoted patches come to more than 80
columns, because then there are lots of breaks in the ">" down the
left hand side due to wrap damage and they are hard to tell from
interspersed comments.

Thanks and sorry to be picky.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:32:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIGR-0006Nf-Q7; Thu, 12 Apr 2012 11:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIIGP-0006NT-H5
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:32:33 +0000
Received: from [85.158.143.35:47735] by server-1.bemta-4.messagelabs.com id
	C9/6B-20925-05DB68F4; Thu, 12 Apr 2012 11:32:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334230351!18286256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2821 invoked from network); 12 Apr 2012 11:32:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:32:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:32:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:32:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIIGM-0005Lt-M5; Thu, 12 Apr 2012 11:32:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIIGM-0005Yv-LA;
	Thu, 12 Apr 2012 12:32:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.48462.638395.960649@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:32:30 +0100
To: <xen-devel@lists.xen.org>
In-Reply-To: <4F86AD6E.3050705@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Formatting of emails which are comments on patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Someone wrote:
) On 11/04/12 14:17, Dario Faggioli wrote:
) ) [9 lines of quoted prose]
) [3 lines of replying prose]
) )
) ) [1 line of quoted prose]
) )
) ) Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com)
) )
) ) [16 lines of diff, quoted without any elision]
) [4 lines of prose]
) 
) [2 lines of prose]
) 
) [3 lines of prose]
) 
) [2 lines of prose]
) ) [71 lines of diff, quoted without any elision]
) [1 line of prose]
) ) [64 lines of diff, quoted without any elision]

etc.  (I have replaced ">" with ")" to try to subvert email programs
which do something special with quoted text so that you can see what
it looks like to me.)

This is unnecessarily hard to read.  What it looks like on my screen
can be seen here:
  http://www.chiark.greenend.org.uk/~ijackson/2012/email-formatting.png

Can I ask people to:

 * Trim diffs when replying to patches.  There is no need to quote the
   whole patch.  Just quote the parts which are needed to understand
   your comments.

 * Leave a blank line between quoted text of any kind and your own 
   added text.

That will help your comments stand out, and be read.  This is
particularly important if the quoted patches come to more than 80
columns, because then there are lots of breaks in the ">" down the
left hand side due to wrap damage and they are hard to tell from
interspersed comments.

Thanks and sorry to be picky.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIHR-0006UA-9Q; Thu, 12 Apr 2012 11:33:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIIHP-0006Tv-92
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:33:35 +0000
Received: from [85.158.143.35:26471] by server-1.bemta-4.messagelabs.com id
	A2/1D-20925-E8DB68F4; Thu, 12 Apr 2012 11:33:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334230413!11021363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11138 invoked from network); 12 Apr 2012 11:33:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:33:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:33:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIIHN-0005MW-Hh; Thu, 12 Apr 2012 11:33:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIIHN-0005Z8-GD;
	Thu, 12 Apr 2012 12:33:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.48525.485169.857777@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:33:33 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> On Tue, 3 Apr 2012, Ian Jackson wrote:
...
> > Although I do have one comment: are you sure it's appropriate that the
> > "toolstack data" is silently thrown away if the restore caller doesn't
> > supply the relevant callback ?
> 
> We should print a warning in that case and try to continue

Why is it not appropriate to bomb out ?  I am not a fan of warnings
(which end up dumped to some ignored logfile) for things which might
be critical problems.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIHR-0006UA-9Q; Thu, 12 Apr 2012 11:33:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIIHP-0006Tv-92
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:33:35 +0000
Received: from [85.158.143.35:26471] by server-1.bemta-4.messagelabs.com id
	A2/1D-20925-E8DB68F4; Thu, 12 Apr 2012 11:33:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334230413!11021363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11138 invoked from network); 12 Apr 2012 11:33:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:33:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:33:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIIHN-0005MW-Hh; Thu, 12 Apr 2012 11:33:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIIHN-0005Z8-GD;
	Thu, 12 Apr 2012 12:33:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.48525.485169.857777@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 12:33:33 +0100
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> On Tue, 3 Apr 2012, Ian Jackson wrote:
...
> > Although I do have one comment: are you sure it's appropriate that the
> > "toolstack data" is silently thrown away if the restore caller doesn't
> > supply the relevant callback ?
> 
> We should print a warning in that case and try to continue

Why is it not appropriate to bomb out ?  I am not a fan of warnings
(which end up dumped to some ignored logfile) for things which might
be critical problems.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIQL-0006pf-Ic; Thu, 12 Apr 2012 11:42:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIIQJ-0006pV-9p
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:42:47 +0000
Received: from [85.158.143.99:28233] by server-3.bemta-4.messagelabs.com id
	39/19-05853-6BFB68F4; Thu, 12 Apr 2012 11:42:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334230964!22437374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5659 invoked from network); 12 Apr 2012 11:42:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:42:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="24093143"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:42:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:42:44 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIIQF-0000xh-Vm;
	Thu, 12 Apr 2012 12:42:43 +0100
Message-ID: <4F86BF8C.6030700@eu.citrix.com>
Date: Thu, 12 Apr 2012 12:42:04 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>	<4F86AD6E.3050705@eu.citrix.com>
	<20358.48462.638395.960649@mariner.uk.xensource.com>
In-Reply-To: <20358.48462.638395.960649@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Formatting of emails which are comments on patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/12 12:32, Ian Jackson wrote:
> Can I ask people to:
>
>   * Trim diffs when replying to patches.  There is no need to quote the
>     whole patch.  Just quote the parts which are needed to understand
>     your comments.
>
>   * Leave a blank line between quoted text of any kind and your own
>     added text.
>
> That will help your comments stand out, and be read.  This is
> particularly important if the quoted patches come to more than 80
> columns, because then there are lots of breaks in the ">" down the
> left hand side due to wrap damage and they are hard to tell from
> interspersed comments.
>
> Thanks and sorry to be picky.
No problem -- sorry for not doing my own trimming; gmail does a good job 
trimming stuff automatically, so I forget what it looks like.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIQL-0006pf-Ic; Thu, 12 Apr 2012 11:42:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIIQJ-0006pV-9p
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:42:47 +0000
Received: from [85.158.143.99:28233] by server-3.bemta-4.messagelabs.com id
	39/19-05853-6BFB68F4; Thu, 12 Apr 2012 11:42:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334230964!22437374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5659 invoked from network); 12 Apr 2012 11:42:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:42:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="24093143"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 07:42:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 07:42:44 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIIQF-0000xh-Vm;
	Thu, 12 Apr 2012 12:42:43 +0100
Message-ID: <4F86BF8C.6030700@eu.citrix.com>
Date: Thu, 12 Apr 2012 12:42:04 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>	<4F86AD6E.3050705@eu.citrix.com>
	<20358.48462.638395.960649@mariner.uk.xensource.com>
In-Reply-To: <20358.48462.638395.960649@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Formatting of emails which are comments on patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/12 12:32, Ian Jackson wrote:
> Can I ask people to:
>
>   * Trim diffs when replying to patches.  There is no need to quote the
>     whole patch.  Just quote the parts which are needed to understand
>     your comments.
>
>   * Leave a blank line between quoted text of any kind and your own
>     added text.
>
> That will help your comments stand out, and be read.  This is
> particularly important if the quoted patches come to more than 80
> columns, because then there are lots of breaks in the ">" down the
> left hand side due to wrap damage and they are hard to tell from
> interspersed comments.
>
> Thanks and sorry to be picky.
No problem -- sorry for not doing my own trimming; gmail does a good job 
trimming stuff automatically, so I forget what it looks like.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIS5-0006vw-29; Thu, 12 Apr 2012 11:44:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SIIS4-0006vp-2E
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:44:36 +0000
Received: from [85.158.143.35:20186] by server-1.bemta-4.messagelabs.com id
	C2/4E-20925-320C68F4; Thu, 12 Apr 2012 11:44:35 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334231072!11023292!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27743 invoked from network); 12 Apr 2012 11:44:34 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:44:34 -0000
Received: by dadp12 with SMTP id p12so2942618dad.7
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 04:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=r7JVTBSgZe2tEdNJSrsB94TXb/fUnGNR0S+0uw1umdA=;
	b=w763ZLO3CkROqNNPm+kI8QbRNbn47miNr9T1VYJZCj7ZvQF6rMK88r/2xZRhng20wz
	iosdLhjKtSPVRd/r8IXcqtXsVAnBZzyMuJym99bbt1qOMQsu+hTAns2agO35to5b0dSh
	H1EPtszCKr96xXD7vIha2f0SCLBDZ4YwAdg/N2fmGhxKP0Y0qm4vssP8+JhMFACE6V9G
	je/B+xNQUbPXMmfdN1qAdRWpxV4txlxxw0z9HAcaHwrgTfR08djSGB3yazNaoIJMiPxE
	yNJcZWS2wKPND8u7nwJY34Hf/lyg+0i0KVG77or3i4ewQO+fQYYR0HdGuZjC4yjevsHD
	WL+A==
MIME-Version: 1.0
Received: by 10.68.235.5 with SMTP id ui5mr2494863pbc.159.1334231071438; Thu,
	12 Apr 2012 04:44:31 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Thu, 12 Apr 2012 04:44:31 -0700 (PDT)
In-Reply-To: <1334214539.12209.219.camel@dagon.hellion.org.uk>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
Date: Thu, 12 Apr 2012 12:44:31 +0100
Message-ID: <CAEwRVpP2F327cE-acG4+Hd=uqf=ZP6g=4hCwMv99WqcMDTouzA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 8:08 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
>> Hi,
>>
>> This is just my experience about issues I encountered when upgrade
>> from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
>> changeset 25191:a95fc7decc83.
>>
>> 1. Immediately after upgrade, xl list show such error:
>>
>> # xl list
>> libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
>> Permission denied
>> libxl_domain_infolist failed.
>>
>> After a reboot, it is fine. =A0Any idea why such behaviour? =A0Imagine if
>> there are running domUs... this might cause issues to shutdown? =A0I
>> will downgrade and repeat such test to confirm. =A0Might be worth a note
>> in upgrading note about this if this is intended?
>
> The tools and the hypervisor are a matched pair so you would need to
> reboot the system in order to use the new tools. This has always been
> the case with Xen upgrades.

I think you mean minor version upgrade is fine but not for major
version upgrade which I can understand ;)

>
>> 2. localtime setting not working. =A0Set to localtime=3D1 doesn't seems =
to
>> work whereby setting rtc_timeoffset works. =A0Any idea?
>
> I've CC'd Lin Ming who implemented both of those.

Thanks.  I know Lin Ming implemented this.

>
>> 3. xl trigger hvmdomain power still never remove those related
>> iptables forward rules. =A0This is the same problem when I test in
>> xen-4.1-testing. =A0Refer to
>> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00771.html
>> about past report. =A0When test in xen-4.1-testing, one funny behaviour
>> is if I start hvmdomain using xm then use xl trigger hvmdomain power
>> does remove those iptables related rule chain.
>
> I think this is an issue with the hotplug scripts not being run at the
> right time. There are some improvements to this in the pipeline which I
> hope will help here.

Hope so :)  Anyway, same problem if hvmdomain shutdown itself.

>
>> I shall do more testing when time permit and sorry if this report is
>> useless to anyone.
>
> On the contrary it is always useful to hear about these things, thank
> you.

My main frequent testing and production rely on xen-4.1-testing not
xen-unstable but I will try my best to do such testing in xen-unstable
once in a while until xen v4.2.0 officially released.

>
> Ian.
>

Thanks Ian for taking time to response ;)

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIS5-0006vw-29; Thu, 12 Apr 2012 11:44:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SIIS4-0006vp-2E
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:44:36 +0000
Received: from [85.158.143.35:20186] by server-1.bemta-4.messagelabs.com id
	C2/4E-20925-320C68F4; Thu, 12 Apr 2012 11:44:35 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334231072!11023292!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27743 invoked from network); 12 Apr 2012 11:44:34 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:44:34 -0000
Received: by dadp12 with SMTP id p12so2942618dad.7
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 04:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=r7JVTBSgZe2tEdNJSrsB94TXb/fUnGNR0S+0uw1umdA=;
	b=w763ZLO3CkROqNNPm+kI8QbRNbn47miNr9T1VYJZCj7ZvQF6rMK88r/2xZRhng20wz
	iosdLhjKtSPVRd/r8IXcqtXsVAnBZzyMuJym99bbt1qOMQsu+hTAns2agO35to5b0dSh
	H1EPtszCKr96xXD7vIha2f0SCLBDZ4YwAdg/N2fmGhxKP0Y0qm4vssP8+JhMFACE6V9G
	je/B+xNQUbPXMmfdN1qAdRWpxV4txlxxw0z9HAcaHwrgTfR08djSGB3yazNaoIJMiPxE
	yNJcZWS2wKPND8u7nwJY34Hf/lyg+0i0KVG77or3i4ewQO+fQYYR0HdGuZjC4yjevsHD
	WL+A==
MIME-Version: 1.0
Received: by 10.68.235.5 with SMTP id ui5mr2494863pbc.159.1334231071438; Thu,
	12 Apr 2012 04:44:31 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Thu, 12 Apr 2012 04:44:31 -0700 (PDT)
In-Reply-To: <1334214539.12209.219.camel@dagon.hellion.org.uk>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
Date: Thu, 12 Apr 2012 12:44:31 +0100
Message-ID: <CAEwRVpP2F327cE-acG4+Hd=uqf=ZP6g=4hCwMv99WqcMDTouzA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 8:08 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
>> Hi,
>>
>> This is just my experience about issues I encountered when upgrade
>> from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
>> changeset 25191:a95fc7decc83.
>>
>> 1. Immediately after upgrade, xl list show such error:
>>
>> # xl list
>> libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
>> Permission denied
>> libxl_domain_infolist failed.
>>
>> After a reboot, it is fine. =A0Any idea why such behaviour? =A0Imagine if
>> there are running domUs... this might cause issues to shutdown? =A0I
>> will downgrade and repeat such test to confirm. =A0Might be worth a note
>> in upgrading note about this if this is intended?
>
> The tools and the hypervisor are a matched pair so you would need to
> reboot the system in order to use the new tools. This has always been
> the case with Xen upgrades.

I think you mean minor version upgrade is fine but not for major
version upgrade which I can understand ;)

>
>> 2. localtime setting not working. =A0Set to localtime=3D1 doesn't seems =
to
>> work whereby setting rtc_timeoffset works. =A0Any idea?
>
> I've CC'd Lin Ming who implemented both of those.

Thanks.  I know Lin Ming implemented this.

>
>> 3. xl trigger hvmdomain power still never remove those related
>> iptables forward rules. =A0This is the same problem when I test in
>> xen-4.1-testing. =A0Refer to
>> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00771.html
>> about past report. =A0When test in xen-4.1-testing, one funny behaviour
>> is if I start hvmdomain using xm then use xl trigger hvmdomain power
>> does remove those iptables related rule chain.
>
> I think this is an issue with the hotplug scripts not being run at the
> right time. There are some improvements to this in the pipeline which I
> hope will help here.

Hope so :)  Anyway, same problem if hvmdomain shutdown itself.

>
>> I shall do more testing when time permit and sorry if this report is
>> useless to anyone.
>
> On the contrary it is always useful to hear about these things, thank
> you.

My main frequent testing and production rely on xen-4.1-testing not
xen-unstable but I will try my best to do such testing in xen-unstable
once in a while until xen v4.2.0 officially released.

>
> Ian.
>

Thanks Ian for taking time to response ;)

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:45:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIISf-0006zQ-Fl; Thu, 12 Apr 2012 11:45:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIISd-0006zC-T5
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:45:12 +0000
Received: from [85.158.139.83:7838] by server-8.bemta-5.messagelabs.com id
	C3/75-26964-640C68F4; Thu, 12 Apr 2012 11:45:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334231109!23535695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15512 invoked from network); 12 Apr 2012 11:45:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:45:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900535"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:45:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:45:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIISa-0005TM-As;
	Thu, 12 Apr 2012 11:45:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIISa-0005qH-8G;
	Thu, 12 Apr 2012 12:45:08 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12650-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 12:45:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12650: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12650 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12650/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12639
 build-amd64                   4 xen-build                 fail REGR. vs. 12639
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a95fc7decc83
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:45:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIISf-0006zQ-Fl; Thu, 12 Apr 2012 11:45:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIISd-0006zC-T5
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:45:12 +0000
Received: from [85.158.139.83:7838] by server-8.bemta-5.messagelabs.com id
	C3/75-26964-640C68F4; Thu, 12 Apr 2012 11:45:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334231109!23535695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15512 invoked from network); 12 Apr 2012 11:45:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:45:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900535"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:45:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:45:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIISa-0005TM-As;
	Thu, 12 Apr 2012 11:45:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIISa-0005qH-8G;
	Thu, 12 Apr 2012 12:45:08 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12650-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 12:45:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12650: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12650 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12650/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12639
 build-amd64                   4 xen-build                 fail REGR. vs. 12639
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a95fc7decc83
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:53:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIa7-0007Nc-Jr; Thu, 12 Apr 2012 11:52:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIIa5-0007NX-Vv
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:52:54 +0000
Received: from [193.109.254.147:63702] by server-8.bemta-14.messagelabs.com id
	17/CA-23244-512C68F4; Thu, 12 Apr 2012 11:52:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334231572!4306826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7633 invoked from network); 12 Apr 2012 11:52:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:52:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:52:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 12:52:52 +0100
Message-ID: <1334231571.16387.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 12:52:51 +0100
In-Reply-To: <20358.47143.994639.76453@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> > On Wed, 2012-04-11 at 17:13 +0100, Ian Jackson wrote:
> > > It may be that we can add dummy ao_hows to these functions which might
> > > be good enough for now, although particularly for domain creation
> > > (which includes spawning) it might complicate the efforts of users to
> > > use the new API.
> > 
> > How close is your half baked series to do it properly?
> 
> Another weeks or two maybe, if I don't get too badly sucked into doing
> anything else.

OK, great.

> Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> > On Wed, 2012-04-11 at 17:11 +0100, Ian Jackson wrote:
> > > I took a look at libxl.h and came up with the comments below.  Firstly
> > > general things I tripped over, and then the list of things which need
> > > converting to the new event system.
> > 
> > A slightly worrying list at this stage in the game.
> 
> Yes.
> 
> > > Other:
> > > ======
> > > 
> > > ]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, 
> > > ]   /* wait for the memory target of a domain to be reached */
> > > ]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid
> > > 
> > > This whole memory interface is a bit of a dog's breakfast.
> > 
> > I think we can defer this to 4.3? The existing interface may be pants
> > but at least the name is pretty explicit that it will block. I think
> > this should then be easy enough to sort out in a backward compatible
> > manner in 4.3 since I expect the name of the function would change and
> > we could retain the old name in terms of the new for compat.
> 
> The problem isn't just that it blocks but also that the semantics are
> wrong.  This is all related to the problems of allocating memory.  We
> had a recent conversation where we concluded that we needed hypervisor
> changes to do memory assignment in a race-free way.  This is not 4.3
> material.
> 
> I suggest that the right answer is to make a note that this interface
> is considered substandard and not to rely on it too heavily; we expect
> to replace it in the future and at that point we will provide an
> emulation which we intend will works by and large well enough for
> existing callers.

That sounds fine, do you want to propose text which you are happy with
as a patch adding a comment?

> 
> > > ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> ...
> > > These functions should not exec things for you; they should tell you
> > > the parameters.  Any execing helpers should be in libxlu.
> > 
> > It's not enough for them to just use libxl__exec?
> > 
> > It'd be reasonably easy to make this return a libxl_string_list or
> > similar and to write a libxlu function which takes one of those.
> 
> But what if your vnc viewer doesn't have the command line options
> these functions expect ?  libxl_vncviewer_* should give you an idl
> struct containing the ip address (or perhaps the domain name), port
> number, and password.
> 
> The command lines should be built in xlu.

Hrm, this seems like 4.3 material at this stage.

I'd expect that the functions which behaved this way would not be
called ..._exec (perhaps ..._get_params or so) so implementing the
proper interface in 4.3 won't cause a compat issue.

> > > Need to be ao/eventified:
> > > =========================
> ...
> > > ]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domi
> > > ]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config 
> > > ]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_con
> > 
> > You are on the case with these?
> 
> Yes for the creation.
> 
> > > ]   typedef struct {
> > > ]   #define XL_SUSPEND_DEBUG 1
> > > ]   #define XL_SUSPEND_LIVE 2
> > > ]       int flags;
> > > ]       int (*suspend_callback)(void *, int);
> > > ]   } libxl_domain_suspend_info;
> > > ...
> > > ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_i
> > > ]                            uint32_t domid, int fd);
> 
> No for these, which I haven't looked at at all.

Any volunteers for this one? I suspect that a dummy ao_how isn't going
to cut it in this case.

What's the pattern for handling long running things which actually
happen in our process? I suppose libxl needs to start a thread or fork
or something?

> > > ]   /*
> > > ]    * Insert a CD-ROM device. A device corresponding to disk must already
> > > ]    * be attached to the guest.
> > > ]    */
> > > ]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_de
> > 
> > Were you looking at this one? I know you mentioned it at one point.
> 
> No, I haven't, but it shouldn't be too hard.

I'll leave this to you then.

> > > ]   /* Network Interfaces */
> > > ]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > > 
> > > ]   /* Keyboard */
> > > ]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > > 
> > > ]   /* Framebuffer */
> > > ]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > 
> > These ought to be pretty trivial conversions?
> 
> Yes.  For the NICs I expect Roger will end up adding an ao_how for
> hotplug script invocation.

He also adds libxl__device_add_initiate (or so) which makes the others
look pretty trivial to convert also.

> > > ]   /* PCI Passthrough */
> > > ]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_de
> > > ]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl
> > 
> > I'm less confident that this one will be trivial to make async :-(
> 
> It's not trivial but it doesn't seem to contain any significant
> difficulties.  It's all just xenstore stuff.  You split something like
> do_pci_remove into a setup and a callback.

I'll have a poke at this then I think.

> > > ]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
> > > ]
> > > ]   libxl_xen_console_reader *
> > > ]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
> > > ]   int libxl_xen_console_read_line(libxl_ctx *ctx,
> > > ]                                   libxl_xen_console_reader *cr,
> > > ]                                   char **line_r);
> > > ]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
> > > ]                                      libxl_xen_console_reader *cr);
> > 
> > This is basically "xl dmesg". I'm not sure what interface makes sense
> > here, really it is just dumping the current ring, so each call is
> > "fast".
> 
> OK, good.
> 
> Is it possible to wait for more input ?

I don't believe so.
> 
> > I'm not sure there is a need for an event driven "new-line-in-log"
> > callback style thing, i.e. a need to implement a "tail -f" style thing. 
> > Firstly I'm not sure that Xen actually produces an event which would
> > allow this to be implemented without polling and secondly if you want
> > that you can configure xenconsoled to log the hypervisor output and then
> > tail the logfile.
> 
> Right.
> 
> > Perhaps this interface is OK?
> 
> I think I'm sold on it being supportable.

Phew!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:53:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIa7-0007Nc-Jr; Thu, 12 Apr 2012 11:52:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIIa5-0007NX-Vv
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 11:52:54 +0000
Received: from [193.109.254.147:63702] by server-8.bemta-14.messagelabs.com id
	17/CA-23244-512C68F4; Thu, 12 Apr 2012 11:52:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334231572!4306826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7633 invoked from network); 12 Apr 2012 11:52:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:52:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:52:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 12:52:52 +0100
Message-ID: <1334231571.16387.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 12:52:51 +0100
In-Reply-To: <20358.47143.994639.76453@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> > On Wed, 2012-04-11 at 17:13 +0100, Ian Jackson wrote:
> > > It may be that we can add dummy ao_hows to these functions which might
> > > be good enough for now, although particularly for domain creation
> > > (which includes spawning) it might complicate the efforts of users to
> > > use the new API.
> > 
> > How close is your half baked series to do it properly?
> 
> Another weeks or two maybe, if I don't get too badly sucked into doing
> anything else.

OK, great.

> Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO"):
> > On Wed, 2012-04-11 at 17:11 +0100, Ian Jackson wrote:
> > > I took a look at libxl.h and came up with the comments below.  Firstly
> > > general things I tripped over, and then the list of things which need
> > > converting to the new event system.
> > 
> > A slightly worrying list at this stage in the game.
> 
> Yes.
> 
> > > Other:
> > > ======
> > > 
> > > ]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, 
> > > ]   /* wait for the memory target of a domain to be reached */
> > > ]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid
> > > 
> > > This whole memory interface is a bit of a dog's breakfast.
> > 
> > I think we can defer this to 4.3? The existing interface may be pants
> > but at least the name is pretty explicit that it will block. I think
> > this should then be easy enough to sort out in a backward compatible
> > manner in 4.3 since I expect the name of the function would change and
> > we could retain the old name in terms of the new for compat.
> 
> The problem isn't just that it blocks but also that the semantics are
> wrong.  This is all related to the problems of allocating memory.  We
> had a recent conversation where we concluded that we needed hypervisor
> changes to do memory assignment in a race-free way.  This is not 4.3
> material.
> 
> I suggest that the right answer is to make a note that this interface
> is considered substandard and not to rely on it too heavily; we expect
> to replace it in the future and at that point we will provide an
> emulation which we intend will works by and large well enough for
> existing callers.

That sounds fine, do you want to propose text which you are happy with
as a patch adding a comment?

> 
> > > ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> ...
> > > These functions should not exec things for you; they should tell you
> > > the parameters.  Any execing helpers should be in libxlu.
> > 
> > It's not enough for them to just use libxl__exec?
> > 
> > It'd be reasonably easy to make this return a libxl_string_list or
> > similar and to write a libxlu function which takes one of those.
> 
> But what if your vnc viewer doesn't have the command line options
> these functions expect ?  libxl_vncviewer_* should give you an idl
> struct containing the ip address (or perhaps the domain name), port
> number, and password.
> 
> The command lines should be built in xlu.

Hrm, this seems like 4.3 material at this stage.

I'd expect that the functions which behaved this way would not be
called ..._exec (perhaps ..._get_params or so) so implementing the
proper interface in 4.3 won't cause a compat issue.

> > > Need to be ao/eventified:
> > > =========================
> ...
> > > ]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domi
> > > ]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config 
> > > ]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_con
> > 
> > You are on the case with these?
> 
> Yes for the creation.
> 
> > > ]   typedef struct {
> > > ]   #define XL_SUSPEND_DEBUG 1
> > > ]   #define XL_SUSPEND_LIVE 2
> > > ]       int flags;
> > > ]       int (*suspend_callback)(void *, int);
> > > ]   } libxl_domain_suspend_info;
> > > ...
> > > ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_i
> > > ]                            uint32_t domid, int fd);
> 
> No for these, which I haven't looked at at all.

Any volunteers for this one? I suspect that a dummy ao_how isn't going
to cut it in this case.

What's the pattern for handling long running things which actually
happen in our process? I suppose libxl needs to start a thread or fork
or something?

> > > ]   /*
> > > ]    * Insert a CD-ROM device. A device corresponding to disk must already
> > > ]    * be attached to the guest.
> > > ]    */
> > > ]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_de
> > 
> > Were you looking at this one? I know you mentioned it at one point.
> 
> No, I haven't, but it shouldn't be too hard.

I'll leave this to you then.

> > > ]   /* Network Interfaces */
> > > ]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > > 
> > > ]   /* Keyboard */
> > > ]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > > 
> > > ]   /* Framebuffer */
> > > ]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_
> > 
> > These ought to be pretty trivial conversions?
> 
> Yes.  For the NICs I expect Roger will end up adding an ao_how for
> hotplug script invocation.

He also adds libxl__device_add_initiate (or so) which makes the others
look pretty trivial to convert also.

> > > ]   /* PCI Passthrough */
> > > ]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_de
> > > ]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl
> > 
> > I'm less confident that this one will be trivial to make async :-(
> 
> It's not trivial but it doesn't seem to contain any significant
> difficulties.  It's all just xenstore stuff.  You split something like
> do_pci_remove into a setup and a callback.

I'll have a poke at this then I think.

> > > ]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
> > > ]
> > > ]   libxl_xen_console_reader *
> > > ]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
> > > ]   int libxl_xen_console_read_line(libxl_ctx *ctx,
> > > ]                                   libxl_xen_console_reader *cr,
> > > ]                                   char **line_r);
> > > ]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
> > > ]                                      libxl_xen_console_reader *cr);
> > 
> > This is basically "xl dmesg". I'm not sure what interface makes sense
> > here, really it is just dumping the current ring, so each call is
> > "fast".
> 
> OK, good.
> 
> Is it possible to wait for more input ?

I don't believe so.
> 
> > I'm not sure there is a need for an event driven "new-line-in-log"
> > callback style thing, i.e. a need to implement a "tail -f" style thing. 
> > Firstly I'm not sure that Xen actually produces an event which would
> > allow this to be implemented without polling and secondly if you want
> > that you can configure xenconsoled to log the hypervisor output and then
> > tail the logfile.
> 
> Right.
> 
> > Perhaps this interface is OK?
> 
> I think I'm sold on it being supportable.

Phew!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:54:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:54:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIbT-0007RZ-2P; Thu, 12 Apr 2012 11:54:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIIbR-0007RP-EG
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:54:17 +0000
Received: from [193.109.254.147:25694] by server-9.bemta-14.messagelabs.com id
	51/C1-05787-862C68F4; Thu, 12 Apr 2012 11:54:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334231656!1182172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24392 invoked from network); 12 Apr 2012 11:54:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:54:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:54:16 +0100
Date: Thu, 12 Apr 2012 12:58:02 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20358.48525.485169.857777@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
	<20358.48525.485169.857777@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 12 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > On Tue, 3 Apr 2012, Ian Jackson wrote:
> ...
> > > Although I do have one comment: are you sure it's appropriate that the
> > > "toolstack data" is silently thrown away if the restore caller doesn't
> > > supply the relevant callback ?
> > 
> > We should print a warning in that case and try to continue
> 
> Why is it not appropriate to bomb out ?  I am not a fan of warnings
> (which end up dumped to some ignored logfile) for things which might
> be critical problems.
 
because there is a significant chance that the guest will resume
correctly anyway (it depends on the guest status and the VM config)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 11:54:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 11:54:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIbT-0007RZ-2P; Thu, 12 Apr 2012 11:54:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIIbR-0007RP-EG
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 11:54:17 +0000
Received: from [193.109.254.147:25694] by server-9.bemta-14.messagelabs.com id
	51/C1-05787-862C68F4; Thu, 12 Apr 2012 11:54:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334231656!1182172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24392 invoked from network); 12 Apr 2012 11:54:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 11:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 11:54:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 12:54:16 +0100
Date: Thu, 12 Apr 2012 12:58:02 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20358.48525.485169.857777@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
	<20358.48525.485169.857777@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 12 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > On Tue, 3 Apr 2012, Ian Jackson wrote:
> ...
> > > Although I do have one comment: are you sure it's appropriate that the
> > > "toolstack data" is silently thrown away if the restore caller doesn't
> > > supply the relevant callback ?
> > 
> > We should print a warning in that case and try to continue
> 
> Why is it not appropriate to bomb out ?  I am not a fan of warnings
> (which end up dumped to some ignored logfile) for things which might
> be critical problems.
 
because there is a significant chance that the guest will resume
correctly anyway (it depends on the guest status and the VM config)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:02:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIik-0007mH-6z; Thu, 12 Apr 2012 12:01:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIIii-0007mC-QH
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 12:01:49 +0000
Received: from [193.109.254.147:17163] by server-7.bemta-14.messagelabs.com id
	07/C0-01627-C24C68F4; Thu, 12 Apr 2012 12:01:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334232106!4261906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5660 invoked from network); 12 Apr 2012 12:01:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 12:01:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 12:01:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 13:01:46 +0100
Message-ID: <1334232105.16387.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 12 Apr 2012 13:01:45 +0100
In-Reply-To: <alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
	<20358.48525.485169.857777@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 12:58 +0100, Stefano Stabellini wrote:
> On Thu, 12 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > > On Tue, 3 Apr 2012, Ian Jackson wrote:
> > ...
> > > > Although I do have one comment: are you sure it's appropriate that the
> > > > "toolstack data" is silently thrown away if the restore caller doesn't
> > > > supply the relevant callback ?
> > > 
> > > We should print a warning in that case and try to continue
> > 
> > Why is it not appropriate to bomb out ?  I am not a fan of warnings
> > (which end up dumped to some ignored logfile) for things which might
> > be critical problems.
>  
> because there is a significant chance that the guest will resume
> correctly anyway (it depends on the guest status and the VM config)

But there is some non-zero chance that it won't, in which case we've
just silently killed the destination VM and told the source machine that
everything is OK, so it won't resume the original. That's not good. I
think we should propagate the error here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:02:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIik-0007mH-6z; Thu, 12 Apr 2012 12:01:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIIii-0007mC-QH
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 12:01:49 +0000
Received: from [193.109.254.147:17163] by server-7.bemta-14.messagelabs.com id
	07/C0-01627-C24C68F4; Thu, 12 Apr 2012 12:01:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334232106!4261906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5660 invoked from network); 12 Apr 2012 12:01:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 12:01:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11900915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 12:01:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 13:01:46 +0100
Message-ID: <1334232105.16387.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 12 Apr 2012 13:01:45 +0100
In-Reply-To: <alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop>
	<20358.48525.485169.857777@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 12:58 +0100, Stefano Stabellini wrote:
> On Thu, 12 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > > On Tue, 3 Apr 2012, Ian Jackson wrote:
> > ...
> > > > Although I do have one comment: are you sure it's appropriate that the
> > > > "toolstack data" is silently thrown away if the restore caller doesn't
> > > > supply the relevant callback ?
> > > 
> > > We should print a warning in that case and try to continue
> > 
> > Why is it not appropriate to bomb out ?  I am not a fan of warnings
> > (which end up dumped to some ignored logfile) for things which might
> > be critical problems.
>  
> because there is a significant chance that the guest will resume
> correctly anyway (it depends on the guest status and the VM config)

But there is some non-zero chance that it won't, in which case we've
just silently killed the destination VM and told the source machine that
everything is OK, so it won't resume the original. That's not good. I
think we should propagate the error here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIsc-00087h-B6; Thu, 12 Apr 2012 12:12:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIIsb-00087c-D7
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 12:12:01 +0000
Received: from [193.109.254.147:55194] by server-2.bemta-14.messagelabs.com id
	0A/02-19409-096C68F4; Thu, 12 Apr 2012 12:12:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334232710!1813488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12412 invoked from network); 12 Apr 2012 12:11:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 12:11:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11901197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 12:11:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 13:11:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIIsP-0005oF-KW; Thu, 12 Apr 2012 12:11:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIIsP-0005bw-Jc;
	Thu, 12 Apr 2012 13:11:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.50821.590731.438539@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 13:11:49 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334231571.16387.100.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334231571.16387.100.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO [and 1 more messages]"):
> > > > ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_i
> > > > ]                            uint32_t domid, int fd);
> > 
> > No for these, which I haven't looked at at all.
> 
> Any volunteers for this one? I suspect that a dummy ao_how isn't going
> to cut it in this case.
> 
> What's the pattern for handling long running things which actually
> happen in our process? I suppose libxl needs to start a thread or fork
> or something?

The intended pattern in the new libxl event universe is to use event
callbacks.  So for example for outgoing migration you'd have an fd
writeable event which called into xc.  But that's not really doable in
this case because the libxc function is entirely monolithic and
synchronous.

The options for libxl are to fork, or to start a thread.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIIsc-00087h-B6; Thu, 12 Apr 2012 12:12:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIIsb-00087c-D7
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 12:12:01 +0000
Received: from [193.109.254.147:55194] by server-2.bemta-14.messagelabs.com id
	0A/02-19409-096C68F4; Thu, 12 Apr 2012 12:12:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334232710!1813488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12412 invoked from network); 12 Apr 2012 12:11:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 12:11:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="11901197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 12:11:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 13:11:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIIsP-0005oF-KW; Thu, 12 Apr 2012 12:11:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIIsP-0005bw-Jc;
	Thu, 12 Apr 2012 13:11:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.50821.590731.438539@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 13:11:49 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334231571.16387.100.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334231571.16387.100.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: Xen 4.2 Release Plan / TODO [and 1 more messages]"):
> > > > ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_i
> > > > ]                            uint32_t domid, int fd);
> > 
> > No for these, which I haven't looked at at all.
> 
> Any volunteers for this one? I suspect that a dummy ao_how isn't going
> to cut it in this case.
> 
> What's the pattern for handling long running things which actually
> happen in our process? I suppose libxl needs to start a thread or fork
> or something?

The intended pattern in the new libxl event universe is to use event
callbacks.  So for example for outgoing migration you'd have an fd
writeable event which called into xc.  But that's not really doable in
this case because the libxc function is entirely monolithic and
synchronous.

The options for libxl are to fork, or to start a thread.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:52:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIJUy-0000mD-Gt; Thu, 12 Apr 2012 12:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SIJUx-0000m5-Cs
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 12:51:39 +0000
Received: from [85.158.138.51:29681] by server-6.bemta-3.messagelabs.com id
	4D/E8-05145-ADFC68F4; Thu, 12 Apr 2012 12:51:38 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334235095!21822619!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10042 invoked from network); 12 Apr 2012 12:51:36 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 12:51:36 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 26889DBC74;
	Thu, 12 Apr 2012 20:51:21 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334214539.12209.219.camel@dagon.hellion.org.uk>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
Date: Thu, 12 Apr 2012 20:50:37 +0800
Message-ID: <1334235037.4001.3.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > Hi,
> > 
> > This is just my experience about issues I encountered when upgrade
> > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > changeset 25191:a95fc7decc83.
> > 
> > 1. Immediately after upgrade, xl list show such error:
> > 
> > # xl list
> > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > Permission denied
> > libxl_domain_infolist failed.
> > 
> > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > there are running domUs... this might cause issues to shutdown?  I
> > will downgrade and repeat such test to confirm.  Might be worth a note
> > in upgrading note about this if this is intended?
> 
> The tools and the hypervisor are a matched pair so you would need to
> reboot the system in order to use the new tools. This has always been
> the case with Xen upgrades.
> 
> > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > work whereby setting rtc_timeoffset works.  Any idea?
> 
> I've CC'd Lin Ming who implemented both of those.

Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
was called 3 times. So below statement was executed 3 times too.

b_info->rtc_timeoffset += tm->tm_gmtoff;

Will look at this issue later.

(gdb) bt
#0  libxl__domain_build_info_setdefault (gc=0x7fffffffdc40, b_info=0x7fffffffdd90) at libxl_create.c:70
#1  0x00007ffff7991fd4 in libxl_domain_need_memory (ctx=0x626050, b_info=0x7fffffffdd90, need_memkb=0x7fffffffdc84) at libxl.c:2696
#2  0x000000000040b0ca in freemem (b_info=0x7fffffffdd90) at xl_cmdimpl.c:1399
#3  0x000000000040bd6d in create_domain (dom_info=0x7fffffffe040) at xl_cmdimpl.c:1656
#4  0x000000000041142c in main_create (argc=1, argv=0x7fffffffe638) at xl_cmdimpl.c:3446
#5  0x00000000004069d8 in main (argc=2, argv=0x7fffffffe630) at xl.c:165
(gdb) 

(gdb) bt
#0  libxl__domain_build_info_setdefault (gc=0x7fffffffdc70, b_info=0x7fffffffdd90) at libxl_create.c:70
#1  0x00007ffff799739c in do_domain_create (gc=0x7fffffffdc70, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid_out=0x625dc8, restore_fd=-1)
    at libxl_create.c:571
#2  0x00007ffff7997cdd in libxl_domain_create_new (ctx=0x626050, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid=0x625dc8) at libxl_create.c:738
#3  0x000000000040be4a in create_domain (dom_info=0x7fffffffe040) at xl_cmdimpl.c:1679
#4  0x000000000041142c in main_create (argc=1, argv=0x7fffffffe638) at xl_cmdimpl.c:3446
#5  0x00000000004069d8 in main (argc=2, argv=0x7fffffffe630) at xl.c:165
(gdb)

(gdb) bt
#0  libxl__domain_build_info_setdefault (gc=0x7fffffffdaa0, b_info=0x7fffffffdd90) at libxl_create.c:70
#1  0x00007ffff79b2146 in libxl_run_bootloader (ctx=0x626050, info=0x7fffffffdd90, disk=0x626b20, domid=9) at libxl_bootloader.c:349
#2  0x00007ffff7997464 in do_domain_create (gc=0x7fffffffdc70, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid_out=0x625dc8, restore_fd=-1)
    at libxl_create.c:580
#3  0x00007ffff7997cdd in libxl_domain_create_new (ctx=0x626050, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid=0x625dc8) at libxl_create.c:738
#4  0x000000000040be4a in create_domain (dom_info=0x7fffffffe040) at xl_cmdimpl.c:1679
#5  0x000000000041142c in main_create (argc=1, argv=0x7fffffffe638) at xl_cmdimpl.c:3446
#6  0x00000000004069d8 in main (argc=2, argv=0x7fffffffe630) at xl.c:165
(gdb) 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:52:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIJUy-0000mD-Gt; Thu, 12 Apr 2012 12:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SIJUx-0000m5-Cs
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 12:51:39 +0000
Received: from [85.158.138.51:29681] by server-6.bemta-3.messagelabs.com id
	4D/E8-05145-ADFC68F4; Thu, 12 Apr 2012 12:51:38 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334235095!21822619!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10042 invoked from network); 12 Apr 2012 12:51:36 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 12:51:36 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 26889DBC74;
	Thu, 12 Apr 2012 20:51:21 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334214539.12209.219.camel@dagon.hellion.org.uk>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
Date: Thu, 12 Apr 2012 20:50:37 +0800
Message-ID: <1334235037.4001.3.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > Hi,
> > 
> > This is just my experience about issues I encountered when upgrade
> > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > changeset 25191:a95fc7decc83.
> > 
> > 1. Immediately after upgrade, xl list show such error:
> > 
> > # xl list
> > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > Permission denied
> > libxl_domain_infolist failed.
> > 
> > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > there are running domUs... this might cause issues to shutdown?  I
> > will downgrade and repeat such test to confirm.  Might be worth a note
> > in upgrading note about this if this is intended?
> 
> The tools and the hypervisor are a matched pair so you would need to
> reboot the system in order to use the new tools. This has always been
> the case with Xen upgrades.
> 
> > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > work whereby setting rtc_timeoffset works.  Any idea?
> 
> I've CC'd Lin Ming who implemented both of those.

Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
was called 3 times. So below statement was executed 3 times too.

b_info->rtc_timeoffset += tm->tm_gmtoff;

Will look at this issue later.

(gdb) bt
#0  libxl__domain_build_info_setdefault (gc=0x7fffffffdc40, b_info=0x7fffffffdd90) at libxl_create.c:70
#1  0x00007ffff7991fd4 in libxl_domain_need_memory (ctx=0x626050, b_info=0x7fffffffdd90, need_memkb=0x7fffffffdc84) at libxl.c:2696
#2  0x000000000040b0ca in freemem (b_info=0x7fffffffdd90) at xl_cmdimpl.c:1399
#3  0x000000000040bd6d in create_domain (dom_info=0x7fffffffe040) at xl_cmdimpl.c:1656
#4  0x000000000041142c in main_create (argc=1, argv=0x7fffffffe638) at xl_cmdimpl.c:3446
#5  0x00000000004069d8 in main (argc=2, argv=0x7fffffffe630) at xl.c:165
(gdb) 

(gdb) bt
#0  libxl__domain_build_info_setdefault (gc=0x7fffffffdc70, b_info=0x7fffffffdd90) at libxl_create.c:70
#1  0x00007ffff799739c in do_domain_create (gc=0x7fffffffdc70, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid_out=0x625dc8, restore_fd=-1)
    at libxl_create.c:571
#2  0x00007ffff7997cdd in libxl_domain_create_new (ctx=0x626050, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid=0x625dc8) at libxl_create.c:738
#3  0x000000000040be4a in create_domain (dom_info=0x7fffffffe040) at xl_cmdimpl.c:1679
#4  0x000000000041142c in main_create (argc=1, argv=0x7fffffffe638) at xl_cmdimpl.c:3446
#5  0x00000000004069d8 in main (argc=2, argv=0x7fffffffe630) at xl.c:165
(gdb)

(gdb) bt
#0  libxl__domain_build_info_setdefault (gc=0x7fffffffdaa0, b_info=0x7fffffffdd90) at libxl_create.c:70
#1  0x00007ffff79b2146 in libxl_run_bootloader (ctx=0x626050, info=0x7fffffffdd90, disk=0x626b20, domid=9) at libxl_bootloader.c:349
#2  0x00007ffff7997464 in do_domain_create (gc=0x7fffffffdc70, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid_out=0x625dc8, restore_fd=-1)
    at libxl_create.c:580
#3  0x00007ffff7997cdd in libxl_domain_create_new (ctx=0x626050, d_config=0x7fffffffdd50, cb=0, priv=0x7fffffffdd34, domid=0x625dc8) at libxl_create.c:738
#4  0x000000000040be4a in create_domain (dom_info=0x7fffffffe040) at xl_cmdimpl.c:1679
#5  0x000000000041142c in main_create (argc=1, argv=0x7fffffffe638) at xl_cmdimpl.c:3446
#6  0x00000000004069d8 in main (argc=2, argv=0x7fffffffe630) at xl.c:165
(gdb) 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:56:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIJZL-0000zf-6v; Thu, 12 Apr 2012 12:56:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIJZK-0000zX-9T
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 12:56:10 +0000
Received: from [193.109.254.147:53682] by server-7.bemta-14.messagelabs.com id
	1E/99-01627-8E0D68F4; Thu, 12 Apr 2012 12:56:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334235366!4310920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17149 invoked from network); 12 Apr 2012 12:56:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 12:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11902710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 12:55:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 13:55:46 +0100
Date: Thu, 12 Apr 2012 13:59:33 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334232105.16387.102.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121359160.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop> 
	<20358.48525.485169.857777@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
	<1334232105.16387.102.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 12 Apr 2012, Ian Campbell wrote:
> On Thu, 2012-04-12 at 12:58 +0100, Stefano Stabellini wrote:
> > On Thu, 12 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > > > On Tue, 3 Apr 2012, Ian Jackson wrote:
> > > ...
> > > > > Although I do have one comment: are you sure it's appropriate that the
> > > > > "toolstack data" is silently thrown away if the restore caller doesn't
> > > > > supply the relevant callback ?
> > > > 
> > > > We should print a warning in that case and try to continue
> > > 
> > > Why is it not appropriate to bomb out ?  I am not a fan of warnings
> > > (which end up dumped to some ignored logfile) for things which might
> > > be critical problems.
> >  
> > because there is a significant chance that the guest will resume
> > correctly anyway (it depends on the guest status and the VM config)
> 
> But there is some non-zero chance that it won't, in which case we've
> just silently killed the destination VM and told the source machine that
> everything is OK, so it won't resume the original. That's not good. I
> think we should propagate the error here.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 12:56:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 12:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIJZL-0000zf-6v; Thu, 12 Apr 2012 12:56:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIJZK-0000zX-9T
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 12:56:10 +0000
Received: from [193.109.254.147:53682] by server-7.bemta-14.messagelabs.com id
	1E/99-01627-8E0D68F4; Thu, 12 Apr 2012 12:56:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334235366!4310920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17149 invoked from network); 12 Apr 2012 12:56:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 12:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11902710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 12:55:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 13:55:46 +0100
Date: Thu, 12 Apr 2012 13:59:33 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334232105.16387.102.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204121359160.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203201211320.923@kaball-desktop>
	<1332246275-13648-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20347.41.542788.706794@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121133430.15151@kaball-desktop> 
	<20358.48525.485169.857777@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204121257240.15151@kaball-desktop>
	<1334232105.16387.102.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 12 Apr 2012, Ian Campbell wrote:
> On Thu, 2012-04-12 at 12:58 +0100, Stefano Stabellini wrote:
> > On Thu, 12 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK"):
> > > > On Tue, 3 Apr 2012, Ian Jackson wrote:
> > > ...
> > > > > Although I do have one comment: are you sure it's appropriate that the
> > > > > "toolstack data" is silently thrown away if the restore caller doesn't
> > > > > supply the relevant callback ?
> > > > 
> > > > We should print a warning in that case and try to continue
> > > 
> > > Why is it not appropriate to bomb out ?  I am not a fan of warnings
> > > (which end up dumped to some ignored logfile) for things which might
> > > be critical problems.
> >  
> > because there is a significant chance that the guest will resume
> > correctly anyway (it depends on the guest status and the VM config)
> 
> But there is some non-zero chance that it won't, in which case we've
> just silently killed the destination VM and told the source machine that
> everything is OK, so it won't resume the original. That's not good. I
> think we should propagate the error here.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 13:06:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 13:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIJjG-0001Gf-9Z; Thu, 12 Apr 2012 13:06:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SIJjE-0001Ga-Fh
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 13:06:24 +0000
Received: from [85.158.138.51:38837] by server-11.bemta-3.messagelabs.com id
	CD/0A-18894-F43D68F4; Thu, 12 Apr 2012 13:06:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334235981!21825534!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19977 invoked from network); 12 Apr 2012 13:06:22 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Apr 2012 13:06:22 -0000
Received: from mail48-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 13:06:20 +0000
Received: from mail48-va3 (localhost [127.0.0.1])	by mail48-va3-R.bigfish.com
	(Postfix) with ESMTP id A9BB8160209;
	Thu, 12 Apr 2012 13:06:19 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zz4015Izz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail48-va3 (localhost.localdomain [127.0.0.1]) by mail48-va3
	(MessageSwitch) id 1334235976990565_13902;
	Thu, 12 Apr 2012 13:06:16 +0000 (UTC)
Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.244])	by
	mail48-va3.bigfish.com (Postfix) with ESMTP id 9E33D1804B7;
	Thu, 12 Apr 2012 13:06:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 13:06:14 +0000
X-WSS-ID: 0M2DB2C-01-1IU-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24006102810B;	Thu, 12 Apr 2012 08:06:12 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 12 Apr 2012 08:06:27 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 12 Apr 2012 08:06:12 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Apr 2012
	09:06:11 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 88D6749C58B; Thu, 12 Apr 2012
	14:06:10 +0100 (BST)
Message-ID: <4F86D464.4080601@amd.com>
Date: Thu, 12 Apr 2012 15:11:00 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: yang.z.zhang@intel.com, Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Huang <wei.huang2@amd.com>, "Ostrovsky,
	Boris" <Boris.Ostrovsky@amd.com>
Subject: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,
This is a revised fix from my last post[1]. We found that the 
performance issue[2] is actually caused by an unnecessary cache flush 
when fall-through happens. According to acpi spec, c2 has cache 
consistency, we don't need cache flush if cx->type != ACPI_STATE_C3.
This fix improves performance of some OEM systems significantly. I would 
suggest to back port it to 4.1, 4.0 and even 3.4.

Thanks,
We

[1]
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00395.html
[2]
http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0

# HG changeset patch
# Parent 6efb9f934bfb4c46af375612fb01e65d15518380
# User Wei Wang <wei.wang2@amd.com>
acpi: do not flush cache if cx->type != ACPI_STATE_C3

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 6efb9f934bfb -r 85775fd04cf4 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 05 11:24:26 2012 +0100
+++ b/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 12 14:15:09 2012 +0200
@@ -509,7 +509,8 @@ static void acpi_processor_idle(void)
          else if ( !power->flags.bm_check )
          {
              /* SMP with no shared cache... Invalidate cache  */
-            ACPI_FLUSH_CPU_CACHE();
+            if ( cx->type == ACPI_STATE_C3 )
+                ACPI_FLUSH_CPU_CACHE();
          }

          /* Invoke C3 */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 13:06:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 13:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIJjG-0001Gf-9Z; Thu, 12 Apr 2012 13:06:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SIJjE-0001Ga-Fh
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 13:06:24 +0000
Received: from [85.158.138.51:38837] by server-11.bemta-3.messagelabs.com id
	CD/0A-18894-F43D68F4; Thu, 12 Apr 2012 13:06:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334235981!21825534!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19977 invoked from network); 12 Apr 2012 13:06:22 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Apr 2012 13:06:22 -0000
Received: from mail48-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 13:06:20 +0000
Received: from mail48-va3 (localhost [127.0.0.1])	by mail48-va3-R.bigfish.com
	(Postfix) with ESMTP id A9BB8160209;
	Thu, 12 Apr 2012 13:06:19 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zz4015Izz1202hzz8275bh8275dhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail48-va3 (localhost.localdomain [127.0.0.1]) by mail48-va3
	(MessageSwitch) id 1334235976990565_13902;
	Thu, 12 Apr 2012 13:06:16 +0000 (UTC)
Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.244])	by
	mail48-va3.bigfish.com (Postfix) with ESMTP id 9E33D1804B7;
	Thu, 12 Apr 2012 13:06:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 13:06:14 +0000
X-WSS-ID: 0M2DB2C-01-1IU-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24006102810B;	Thu, 12 Apr 2012 08:06:12 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 12 Apr 2012 08:06:27 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 12 Apr 2012 08:06:12 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Apr 2012
	09:06:11 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 88D6749C58B; Thu, 12 Apr 2012
	14:06:10 +0100 (BST)
Message-ID: <4F86D464.4080601@amd.com>
Date: Thu, 12 Apr 2012 15:11:00 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: yang.z.zhang@intel.com, Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Huang <wei.huang2@amd.com>, "Ostrovsky,
	Boris" <Boris.Ostrovsky@amd.com>
Subject: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,
This is a revised fix from my last post[1]. We found that the 
performance issue[2] is actually caused by an unnecessary cache flush 
when fall-through happens. According to acpi spec, c2 has cache 
consistency, we don't need cache flush if cx->type != ACPI_STATE_C3.
This fix improves performance of some OEM systems significantly. I would 
suggest to back port it to 4.1, 4.0 and even 3.4.

Thanks,
We

[1]
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00395.html
[2]
http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0

# HG changeset patch
# Parent 6efb9f934bfb4c46af375612fb01e65d15518380
# User Wei Wang <wei.wang2@amd.com>
acpi: do not flush cache if cx->type != ACPI_STATE_C3

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 6efb9f934bfb -r 85775fd04cf4 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 05 11:24:26 2012 +0100
+++ b/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 12 14:15:09 2012 +0200
@@ -509,7 +509,8 @@ static void acpi_processor_idle(void)
          else if ( !power->flags.bm_check )
          {
              /* SMP with no shared cache... Invalidate cache  */
-            ACPI_FLUSH_CPU_CACHE();
+            if ( cx->type == ACPI_STATE_C3 )
+                ACPI_FLUSH_CPU_CACHE();
          }

          /* Invoke C3 */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 13:28:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 13:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIK4U-0001wP-QG; Thu, 12 Apr 2012 13:28:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SIK4T-0001wE-7x
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 13:28:21 +0000
Received: from [85.158.143.99:35255] by server-1.bemta-4.messagelabs.com id
	10/D8-20925-478D68F4; Thu, 12 Apr 2012 13:28:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334237298!22824754!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12338 invoked from network); 12 Apr 2012 13:28:19 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 13:28:19 -0000
Received: by qabg40 with SMTP id g40so1667962qab.11
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 06:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=7vZhS5nxnmQuf18MDR48+2xHyf7EDk2l+EOxbFDfWyM=;
	b=sceaC5np8jperk5jbvwjy5DlKH7Spc9hsI8q4iaZYCbtXeO7P85fJcEs7ah0ILWGgv
	49yxsqg2l8qtyJLpubExxi5U7ESul4JSZwtYJGVOHst08sgrYWw67tdvu3+LH5wxVQ2M
	lrcszlxKvNz5vnwvm5ir88xEccPG9Ovi/diLj0pfZZustGMoPgcD2VRHRvDx9qPg6GC6
	eDuzJYO3orVw6BE4dj6eMcn+fmIijgX5mvPfeWqyXCtU1YVIm2X/ZQ1fHG1ssoi11aRE
	eCIHSav3qE5XrnH2/rmivp2EwHVvEnF/IfxFViM9DmxNCIY6Au5jsV3U1h5e/25tofbK
	LPOg==
MIME-Version: 1.0
Received: by 10.224.210.10 with SMTP id gi10mr3916933qab.47.1334237298072;
	Thu, 12 Apr 2012 06:28:18 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 12 Apr 2012 06:28:18 -0700 (PDT)
In-Reply-To: <1334229871.16387.81.camel@zakaz.uk.xensource.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
Date: Thu, 12 Apr 2012 14:28:18 +0100
X-Google-Sender-Auth: -c9o5r6JJPK0j5gv5edhB7qi71U
Message-ID: <CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 12:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
>> Hi all,
>>
>> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
>> Mac pro. After running ./configure and make. I got the following fatal
>> error:
>>
>> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
>> directory compilation terminated.
>>
>>
>> So the original libxlu_cfg_l.h is deleted when making, and should be
>> regenerated but it is not.
>
> Actually it should never have been deleted in the first place, unless
> you have been modifying the flex source.
>
> Please can you enumerate the exact steps you took, starting from the
> initial clone of the repo, which caused the file to be deleted?
>
>> I find the path of flex and bison is not set. =A0When I add the correct
>> path of flex and bison in tools.mk manually, This error is fixed.
>
> Those tools should be optional since the generated files are checked in.
> However perhaps configure should detect and provide the paths but behave
> in a non-fatal manner if they aren't available? Roger, what do you
> think?

FWIW, I managed to get into a state where I ran into this error too;
after a sequence of fairly random steps, it went away, and I wasn't
able to reproduce it again.  I have no idea what I did to get there in
the first place, nor what I did to fix it.

Zhihao: I think if you make a clean copy of the repo and run
./configure again, the problem will probably go away.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 13:28:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 13:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIK4U-0001wP-QG; Thu, 12 Apr 2012 13:28:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SIK4T-0001wE-7x
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 13:28:21 +0000
Received: from [85.158.143.99:35255] by server-1.bemta-4.messagelabs.com id
	10/D8-20925-478D68F4; Thu, 12 Apr 2012 13:28:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334237298!22824754!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12338 invoked from network); 12 Apr 2012 13:28:19 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 13:28:19 -0000
Received: by qabg40 with SMTP id g40so1667962qab.11
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 06:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=7vZhS5nxnmQuf18MDR48+2xHyf7EDk2l+EOxbFDfWyM=;
	b=sceaC5np8jperk5jbvwjy5DlKH7Spc9hsI8q4iaZYCbtXeO7P85fJcEs7ah0ILWGgv
	49yxsqg2l8qtyJLpubExxi5U7ESul4JSZwtYJGVOHst08sgrYWw67tdvu3+LH5wxVQ2M
	lrcszlxKvNz5vnwvm5ir88xEccPG9Ovi/diLj0pfZZustGMoPgcD2VRHRvDx9qPg6GC6
	eDuzJYO3orVw6BE4dj6eMcn+fmIijgX5mvPfeWqyXCtU1YVIm2X/ZQ1fHG1ssoi11aRE
	eCIHSav3qE5XrnH2/rmivp2EwHVvEnF/IfxFViM9DmxNCIY6Au5jsV3U1h5e/25tofbK
	LPOg==
MIME-Version: 1.0
Received: by 10.224.210.10 with SMTP id gi10mr3916933qab.47.1334237298072;
	Thu, 12 Apr 2012 06:28:18 -0700 (PDT)
Received: by 10.229.21.202 with HTTP; Thu, 12 Apr 2012 06:28:18 -0700 (PDT)
In-Reply-To: <1334229871.16387.81.camel@zakaz.uk.xensource.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
Date: Thu, 12 Apr 2012 14:28:18 +0100
X-Google-Sender-Auth: -c9o5r6JJPK0j5gv5edhB7qi71U
Message-ID: <CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 12:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
>> Hi all,
>>
>> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
>> Mac pro. After running ./configure and make. I got the following fatal
>> error:
>>
>> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
>> directory compilation terminated.
>>
>>
>> So the original libxlu_cfg_l.h is deleted when making, and should be
>> regenerated but it is not.
>
> Actually it should never have been deleted in the first place, unless
> you have been modifying the flex source.
>
> Please can you enumerate the exact steps you took, starting from the
> initial clone of the repo, which caused the file to be deleted?
>
>> I find the path of flex and bison is not set. =A0When I add the correct
>> path of flex and bison in tools.mk manually, This error is fixed.
>
> Those tools should be optional since the generated files are checked in.
> However perhaps configure should detect and provide the paths but behave
> in a non-fatal manner if they aren't available? Roger, what do you
> think?

FWIW, I managed to get into a state where I ran into this error too;
after a sequence of fairly random steps, it went away, and I wasn't
able to reproduce it again.  I have no idea what I did to get there in
the first place, nor what I did to fix it.

Zhihao: I think if you make a clean copy of the repo and run
./configure again, the problem will probably go away.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 13:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 13:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKW5-0004By-As; Thu, 12 Apr 2012 13:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIKW3-0004Bh-5y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 13:56:51 +0000
Received: from [85.158.143.35:41037] by server-2.bemta-4.messagelabs.com id
	B5/92-17550-22FD68F4; Thu, 12 Apr 2012 13:56:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334239008!11048879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14539 invoked from network); 12 Apr 2012 13:56:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 13:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11904816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 13:56:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 14:56:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIKVz-0007CP-T2;
	Thu, 12 Apr 2012 13:56:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIKVz-0002m5-Ro;
	Thu, 12 Apr 2012 14:56:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12652-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 14:56:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12652: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12652 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12652/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12640
 build-amd64                   4 xen-build                 fail REGR. vs. 12640
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12640

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 13:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 13:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKW5-0004By-As; Thu, 12 Apr 2012 13:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIKW3-0004Bh-5y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 13:56:51 +0000
Received: from [85.158.143.35:41037] by server-2.bemta-4.messagelabs.com id
	B5/92-17550-22FD68F4; Thu, 12 Apr 2012 13:56:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334239008!11048879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14539 invoked from network); 12 Apr 2012 13:56:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 13:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11904816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 13:56:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 14:56:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIKVz-0007CP-T2;
	Thu, 12 Apr 2012 13:56:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIKVz-0002m5-Ro;
	Thu, 12 Apr 2012 14:56:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12652-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 14:56:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12652: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12652 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12652/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12640
 build-amd64                   4 xen-build                 fail REGR. vs. 12640
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 12640

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:02:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKas-0004YB-97; Thu, 12 Apr 2012 14:01:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKaq-0004Y4-N7
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:01:49 +0000
Received: from [193.109.254.147:61480] by server-10.bemta-14.messagelabs.com
	id CD/4E-05847-A40E68F4; Thu, 12 Apr 2012 14:01:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334239305!4317884!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTc5NTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18511 invoked from network); 12 Apr 2012 14:01:46 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 14:01:46 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 333BA76C076;
	Thu, 12 Apr 2012 07:01:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=XU1S5JqacYBmFwV7T4TnEL
	DBbfZaxNnHBE0chtxg3zRpUpeWSUo51yYGZZ7n1h4Zp/FMFH2gbFKH9a30/XcZQ7
	5mDUggg7xFq/kJ5BiaVoKmcwawUrLPkeGHAlOiopMYQTEq2Mp0glAxQBsBDtwvTk
	qiqjkFFYuqXb5z4QLhJeQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=ZYovqVeW0CWN
	Qpw4ZM60xEDgPEw=; b=MLdb//42Ese0KG3ZwF3KL9AcC9DagI3Nubjo0SPyNwa0
	RPkXw+TxuXjxK6fY7F+V598DB1PQ8IQf9sJAzOfPtVwM8aBi5QtYcYdoXkrwnGgb
	uBTfYcHhsqnZAh6LvoAejLxizejcsyqaTAYIOXr8XV/e6JwRmDgh/ScpqvvgAYs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 8D2D476C069; 
	Thu, 12 Apr 2012 07:01:44 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: c74fe64aafebebb025b5d6db1d59ae55c1980933
Message-Id: <c74fe64aafebebb025b5.1334239602@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:06:42 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mem_event: Fix foregin domain flag in
	grab_slot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_event.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 84c3a14dc28a -r c74fe64aafeb xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -415,7 +415,7 @@ int __mem_event_claim_slot(struct domain
     if ( (current->domain == d) && allow_sleep )
         return mem_event_wait_slot(med);
     else
-        return mem_event_grab_slot(med, 1);
+        return mem_event_grab_slot(med, (current->domain != d));
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:02:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKas-0004YB-97; Thu, 12 Apr 2012 14:01:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKaq-0004Y4-N7
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:01:49 +0000
Received: from [193.109.254.147:61480] by server-10.bemta-14.messagelabs.com
	id CD/4E-05847-A40E68F4; Thu, 12 Apr 2012 14:01:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334239305!4317884!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTc5NTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18511 invoked from network); 12 Apr 2012 14:01:46 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 14:01:46 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 333BA76C076;
	Thu, 12 Apr 2012 07:01:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=XU1S5JqacYBmFwV7T4TnEL
	DBbfZaxNnHBE0chtxg3zRpUpeWSUo51yYGZZ7n1h4Zp/FMFH2gbFKH9a30/XcZQ7
	5mDUggg7xFq/kJ5BiaVoKmcwawUrLPkeGHAlOiopMYQTEq2Mp0glAxQBsBDtwvTk
	qiqjkFFYuqXb5z4QLhJeQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=ZYovqVeW0CWN
	Qpw4ZM60xEDgPEw=; b=MLdb//42Ese0KG3ZwF3KL9AcC9DagI3Nubjo0SPyNwa0
	RPkXw+TxuXjxK6fY7F+V598DB1PQ8IQf9sJAzOfPtVwM8aBi5QtYcYdoXkrwnGgb
	uBTfYcHhsqnZAh6LvoAejLxizejcsyqaTAYIOXr8XV/e6JwRmDgh/ScpqvvgAYs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 8D2D476C069; 
	Thu, 12 Apr 2012 07:01:44 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: c74fe64aafebebb025b5d6db1d59ae55c1980933
Message-Id: <c74fe64aafebebb025b5.1334239602@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:06:42 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mem_event: Fix foregin domain flag in
	grab_slot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_event.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 84c3a14dc28a -r c74fe64aafeb xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -415,7 +415,7 @@ int __mem_event_claim_slot(struct domain
     if ( (current->domain == d) && allow_sleep )
         return mem_event_wait_slot(med);
     else
-        return mem_event_grab_slot(med, 1);
+        return mem_event_grab_slot(med, (current->domain != d));
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKc5-0004e3-NM; Thu, 12 Apr 2012 14:03:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIKc4-0004dt-91
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:03:04 +0000
Received: from [85.158.143.35:28544] by server-2.bemta-4.messagelabs.com id
	86/4E-17550-790E68F4; Thu, 12 Apr 2012 14:03:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334239382!4652255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22342 invoked from network); 12 Apr 2012 14:03:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11905017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:03:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:03:02 +0100
Message-ID: <1334239381.16387.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Thu, 12 Apr 2012 15:03:01 +0100
In-Reply-To: <1334235037.4001.3.camel@hp6530s>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
> On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > > Hi,
> > > 
> > > This is just my experience about issues I encountered when upgrade
> > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > > changeset 25191:a95fc7decc83.
> > > 
> > > 1. Immediately after upgrade, xl list show such error:
> > > 
> > > # xl list
> > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > > Permission denied
> > > libxl_domain_infolist failed.
> > > 
> > > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > > there are running domUs... this might cause issues to shutdown?  I
> > > will downgrade and repeat such test to confirm.  Might be worth a note
> > > in upgrading note about this if this is intended?
> > 
> > The tools and the hypervisor are a matched pair so you would need to
> > reboot the system in order to use the new tools. This has always been
> > the case with Xen upgrades.
> > 
> > > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > > work whereby setting rtc_timeoffset works.  Any idea?
> > 
> > I've CC'd Lin Ming who implemented both of those.
> 
> Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
> was called 3 times. So below statement was executed 3 times too.
> 
> b_info->rtc_timeoffset += tm->tm_gmtoff;

Oh, that sounds like the problem. The setdefault functions are supposed
to be idempotent, IOW calling it two or more times should give the same
result as calling it just once.

I think you need to move this logic from setdefault
    if (libxl_defbool_val(b_info->localtime)) {
        time_t t;
        struct tm *tm;

        t = time(NULL);
        tm = localtime(&t);

        b_info->rtc_timeoffset += tm->tm_gmtoff;
    }

into libxl__build_pre and do that calculation on a temporary variable
whjich you pass to xc_domain_set_time_offset rather than modifying
b_info.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKc5-0004e3-NM; Thu, 12 Apr 2012 14:03:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIKc4-0004dt-91
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:03:04 +0000
Received: from [85.158.143.35:28544] by server-2.bemta-4.messagelabs.com id
	86/4E-17550-790E68F4; Thu, 12 Apr 2012 14:03:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334239382!4652255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22342 invoked from network); 12 Apr 2012 14:03:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11905017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:03:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:03:02 +0100
Message-ID: <1334239381.16387.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Thu, 12 Apr 2012 15:03:01 +0100
In-Reply-To: <1334235037.4001.3.camel@hp6530s>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
> On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > > Hi,
> > > 
> > > This is just my experience about issues I encountered when upgrade
> > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > > changeset 25191:a95fc7decc83.
> > > 
> > > 1. Immediately after upgrade, xl list show such error:
> > > 
> > > # xl list
> > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > > Permission denied
> > > libxl_domain_infolist failed.
> > > 
> > > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > > there are running domUs... this might cause issues to shutdown?  I
> > > will downgrade and repeat such test to confirm.  Might be worth a note
> > > in upgrading note about this if this is intended?
> > 
> > The tools and the hypervisor are a matched pair so you would need to
> > reboot the system in order to use the new tools. This has always been
> > the case with Xen upgrades.
> > 
> > > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > > work whereby setting rtc_timeoffset works.  Any idea?
> > 
> > I've CC'd Lin Ming who implemented both of those.
> 
> Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
> was called 3 times. So below statement was executed 3 times too.
> 
> b_info->rtc_timeoffset += tm->tm_gmtoff;

Oh, that sounds like the problem. The setdefault functions are supposed
to be idempotent, IOW calling it two or more times should give the same
result as calling it just once.

I think you need to move this logic from setdefault
    if (libxl_defbool_val(b_info->localtime)) {
        time_t t;
        struct tm *tm;

        t = time(NULL);
        tm = localtime(&t);

        b_info->rtc_timeoffset += tm->tm_gmtoff;
    }

into libxl__build_pre and do that calculation on a temporary variable
whjich you pass to xc_domain_set_time_offset rather than modifying
b_info.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKf4-0004p3-9d; Thu, 12 Apr 2012 14:06:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIKf3-0004oy-Mk
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:06:09 +0000
Received: from [85.158.143.35:52397] by server-2.bemta-4.messagelabs.com id
	A0/04-17550-151E68F4; Thu, 12 Apr 2012 14:06:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334239563!12135765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22763 invoked from network); 12 Apr 2012 14:06:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11905098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:05:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:05:47 +0100
Message-ID: <1334239545.16387.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <dunlapg@umich.edu>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 15:05:45 +0100
In-Reply-To: <CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
	<CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 14:28 +0100, George Dunlap wrote:
> On Thu, Apr 12, 2012 at 12:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
> >> Hi all,
> >>
> >> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
> >> Mac pro. After running ./configure and make. I got the following fatal
> >> error:
> >>
> >> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
> >> directory compilation terminated.
> >>
> >>
> >> So the original libxlu_cfg_l.h is deleted when making, and should be
> >> regenerated but it is not.
> >
> > Actually it should never have been deleted in the first place, unless
> > you have been modifying the flex source.
> >
> > Please can you enumerate the exact steps you took, starting from the
> > initial clone of the repo, which caused the file to be deleted?
> >
> >> I find the path of flex and bison is not set.  When I add the correct
> >> path of flex and bison in tools.mk manually, This error is fixed.
> >
> > Those tools should be optional since the generated files are checked in.
> > However perhaps configure should detect and provide the paths but behave
> > in a non-fatal manner if they aren't available? Roger, what do you
> > think?
> 
> FWIW, I managed to get into a state where I ran into this error too;
> after a sequence of fairly random steps, it went away, and I wasn't
> able to reproduce it again.  I have no idea what I did to get there in
> the first place, nor what I did to fix it.

I wonder if this is to do with timestamp skew or something like that
cause false reruns of bison? Those would then fail (no bison) which in
turn would cause make to delete the target.

Perhaps we need to disable the flex and bison rules unless some magic
flag is set (by those who are modifying the relevant sources)?

CCing IanJ on the assumption he knows what's going on here..

> Zhihao: I think if you make a clean copy of the repo and run
> ./configure again, the problem will probably go away.

"hg revert <paths>" would probably do the job too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKf4-0004p3-9d; Thu, 12 Apr 2012 14:06:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIKf3-0004oy-Mk
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:06:09 +0000
Received: from [85.158.143.35:52397] by server-2.bemta-4.messagelabs.com id
	A0/04-17550-151E68F4; Thu, 12 Apr 2012 14:06:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334239563!12135765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22763 invoked from network); 12 Apr 2012 14:06:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11905098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:05:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:05:47 +0100
Message-ID: <1334239545.16387.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <dunlapg@umich.edu>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 15:05:45 +0100
In-Reply-To: <CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
	<CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 14:28 +0100, George Dunlap wrote:
> On Thu, Apr 12, 2012 at 12:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
> >> Hi all,
> >>
> >> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
> >> Mac pro. After running ./configure and make. I got the following fatal
> >> error:
> >>
> >> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
> >> directory compilation terminated.
> >>
> >>
> >> So the original libxlu_cfg_l.h is deleted when making, and should be
> >> regenerated but it is not.
> >
> > Actually it should never have been deleted in the first place, unless
> > you have been modifying the flex source.
> >
> > Please can you enumerate the exact steps you took, starting from the
> > initial clone of the repo, which caused the file to be deleted?
> >
> >> I find the path of flex and bison is not set.  When I add the correct
> >> path of flex and bison in tools.mk manually, This error is fixed.
> >
> > Those tools should be optional since the generated files are checked in.
> > However perhaps configure should detect and provide the paths but behave
> > in a non-fatal manner if they aren't available? Roger, what do you
> > think?
> 
> FWIW, I managed to get into a state where I ran into this error too;
> after a sequence of fairly random steps, it went away, and I wasn't
> able to reproduce it again.  I have no idea what I did to get there in
> the first place, nor what I did to fix it.

I wonder if this is to do with timestamp skew or something like that
cause false reruns of bison? Those would then fail (no bison) which in
turn would cause make to delete the target.

Perhaps we need to disable the flex and bison rules unless some magic
flag is set (by those who are modifying the relevant sources)?

CCing IanJ on the assumption he knows what's going on here..

> Zhihao: I think if you make a clean copy of the repo and run
> ./configure again, the problem will probably go away.

"hg revert <paths>" would probably do the job too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKju-0005BF-MA; Thu, 12 Apr 2012 14:11:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIKjt-0005Ay-7k
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:11:09 +0000
Received: from [193.109.254.147:16707] by server-3.bemta-14.messagelabs.com id
	6F/12-23274-C72E68F4; Thu, 12 Apr 2012 14:11:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334239865!4287831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22779 invoked from network); 12 Apr 2012 14:11:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11905216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 15:10:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIKjE-0007Kh-QG; Thu, 12 Apr 2012 14:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIKjE-0007ft-Ni;
	Thu, 12 Apr 2012 15:10:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.57940.702696.586660@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 15:10:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334239545.16387.108.camel@zakaz.uk.xensource.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
	<CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
	<1334239545.16387.108.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: zhihao wang <accept.acm@gmail.com>, George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] fatal error if Flex and Bison is not configured"):
> I wonder if this is to do with timestamp skew or something like that
> cause false reruns of bison? Those would then fail (no bison) which in
> turn would cause make to delete the target.

Timestamp skew could certainly cause this.

Is NFS involved ?  Does the computer you're using have a stable,
synchronised, clock ?  Are you copying working trees about ?  Are you
using a tree actually cloned with hg ?

It's also possible, I guess, that hg takes no special care with
mtimes, in which case just "hg pull" might, if you were unlucky,
update the files in different seconds and in the wrong order.

> Perhaps we need to disable the flex and bison rules unless some magic
> flag is set (by those who are modifying the relevant sources)?

Well, we have configure now.  We could enable those rules iff
(suitably recent[1]) bison and flex were found.

[1] The original reason why we checked these files into the tree was
that shipped versions of Centos and RHEL had truly prehistoric
versions which didn't support making properly reentrant
scanners/parsers.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKju-0005BF-MA; Thu, 12 Apr 2012 14:11:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIKjt-0005Ay-7k
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:11:09 +0000
Received: from [193.109.254.147:16707] by server-3.bemta-14.messagelabs.com id
	6F/12-23274-C72E68F4; Thu, 12 Apr 2012 14:11:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334239865!4287831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22779 invoked from network); 12 Apr 2012 14:11:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11905216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 15:10:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIKjE-0007Kh-QG; Thu, 12 Apr 2012 14:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIKjE-0007ft-Ni;
	Thu, 12 Apr 2012 15:10:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20358.57940.702696.586660@mariner.uk.xensource.com>
Date: Thu, 12 Apr 2012 15:10:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334239545.16387.108.camel@zakaz.uk.xensource.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
	<CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
	<1334239545.16387.108.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: zhihao wang <accept.acm@gmail.com>, George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] fatal error if Flex and Bison is not configured"):
> I wonder if this is to do with timestamp skew or something like that
> cause false reruns of bison? Those would then fail (no bison) which in
> turn would cause make to delete the target.

Timestamp skew could certainly cause this.

Is NFS involved ?  Does the computer you're using have a stable,
synchronised, clock ?  Are you copying working trees about ?  Are you
using a tree actually cloned with hg ?

It's also possible, I guess, that hg takes no special care with
mtimes, in which case just "hg pull" might, if you were unlucky,
update the files in different seconds and in the wrong order.

> Perhaps we need to disable the flex and bison rules unless some magic
> flag is set (by those who are modifying the relevant sources)?

Well, we have configure now.  We could enable those rules iff
(suitably recent[1]) bison and flex were found.

[1] The original reason why we checked these files into the tree was
that shipped versions of Centos and RHEL had truly prehistoric
versions which didn't support making properly reentrant
scanners/parsers.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlL-0005Na-63; Thu, 12 Apr 2012 14:12:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlJ-0005NM-I1
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:37 +0000
Received: from [85.158.139.83:16163] by server-4.bemta-5.messagelabs.com id
	24/E2-10788-4D2E68F4; Thu, 12 Apr 2012 14:12:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334239955!19267549!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTcxMzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25813 invoked from network); 12 Apr 2012 14:12:35 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-14.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 14:12:35 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 736BB300072;
	Thu, 12 Apr 2012 07:12:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=SVBdtdaBvtVljsQapW7hBW
	a98zzVIHSCXjhj0say4xA+lqxJY85YsvBbbUzn3cmUnyHKISB46SCT5VY+TnUk21
	BhyMfbCGXsyfxHPD9r6XMHUy+yoYC7+MRv+3hwMX11oXsheLERVsjmU1mZh5/Hiu
	FCyCbWkQpRW7Aoh44RZes=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=Ub35vr1ykOoV
	A6/lOvAcNDfoyPY=; b=tacW41ccnzdEhktQcSI434HYIKFIhTzTbNK8WPQLxE6U
	braxktgl7CrN78Hx2DqKWzeqZbp+gDyAKXOq5/nNSYMNjE2elocUA06s4c+xCaTn
	JTFoSnfHW6kiv8zIm6jeQTjEfiCmqmK7M3u+3GFVdnkahmQ3nyRImwR5MoxlAHs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 6234730006C; 
	Thu, 12 Apr 2012 07:12:32 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:11 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] RFC: x86 memory sharing performance
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an RFC series. I haven't fully tested it yet, but I want the concept to
be known as I intend this to be merged prior to the closing of the 4.2 window.

The sharing subsystem does not scale elegantly with high degrees of page
sharing. The culprit is a reverse map that each shared frame maintains,
resolving to all domain pages pointing to the shared frame. Because the rmap is
implemented with a O(n) search linked-list, CoW unsharing can result in
prolonged search times.

The place where this becomes most obvious is during domain destruction, during
which all shared p2m entries need to be unshared. Destroying a domain with a
lot of sharing could result in minutes of hypervisor freeze-up!

Solutions proposed:
- Make the p2m clean up of shared entries part of the preemptible, synchronous,
domain_kill domctl (as opposed to executing monolithically in the finalize
destruction RCU callback)
- When a shared frame exceeds an arbitrary ref count, mutate the rmap from a
linked list to a hash table.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/domain.c             |   16 +++-
 xen/arch/x86/mm/mem_sharing.c     |   45 ++++++++++
 xen/arch/x86/mm/p2m.c             |    4 +
 xen/include/asm-arm/mm.h          |    4 +
 xen/include/asm-x86/domain.h      |    1 +
 xen/include/asm-x86/mem_sharing.h |   10 ++
 xen/include/asm-x86/p2m.h         |    4 +
 xen/arch/x86/mm/mem_sharing.c     |  142 +++++++++++++++++++++++--------
 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 10 files changed, 354 insertions(+), 55 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlL-0005Na-63; Thu, 12 Apr 2012 14:12:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlJ-0005NM-I1
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:37 +0000
Received: from [85.158.139.83:16163] by server-4.bemta-5.messagelabs.com id
	24/E2-10788-4D2E68F4; Thu, 12 Apr 2012 14:12:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334239955!19267549!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTcxMzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25813 invoked from network); 12 Apr 2012 14:12:35 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-14.tower-182.messagelabs.com with SMTP;
	12 Apr 2012 14:12:35 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 736BB300072;
	Thu, 12 Apr 2012 07:12:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=SVBdtdaBvtVljsQapW7hBW
	a98zzVIHSCXjhj0say4xA+lqxJY85YsvBbbUzn3cmUnyHKISB46SCT5VY+TnUk21
	BhyMfbCGXsyfxHPD9r6XMHUy+yoYC7+MRv+3hwMX11oXsheLERVsjmU1mZh5/Hiu
	FCyCbWkQpRW7Aoh44RZes=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=Ub35vr1ykOoV
	A6/lOvAcNDfoyPY=; b=tacW41ccnzdEhktQcSI434HYIKFIhTzTbNK8WPQLxE6U
	braxktgl7CrN78Hx2DqKWzeqZbp+gDyAKXOq5/nNSYMNjE2elocUA06s4c+xCaTn
	JTFoSnfHW6kiv8zIm6jeQTjEfiCmqmK7M3u+3GFVdnkahmQ3nyRImwR5MoxlAHs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 6234730006C; 
	Thu, 12 Apr 2012 07:12:32 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:11 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] RFC: x86 memory sharing performance
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an RFC series. I haven't fully tested it yet, but I want the concept to
be known as I intend this to be merged prior to the closing of the 4.2 window.

The sharing subsystem does not scale elegantly with high degrees of page
sharing. The culprit is a reverse map that each shared frame maintains,
resolving to all domain pages pointing to the shared frame. Because the rmap is
implemented with a O(n) search linked-list, CoW unsharing can result in
prolonged search times.

The place where this becomes most obvious is during domain destruction, during
which all shared p2m entries need to be unshared. Destroying a domain with a
lot of sharing could result in minutes of hypervisor freeze-up!

Solutions proposed:
- Make the p2m clean up of shared entries part of the preemptible, synchronous,
domain_kill domctl (as opposed to executing monolithically in the finalize
destruction RCU callback)
- When a shared frame exceeds an arbitrary ref count, mutate the rmap from a
linked list to a hash table.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/domain.c             |   16 +++-
 xen/arch/x86/mm/mem_sharing.c     |   45 ++++++++++
 xen/arch/x86/mm/p2m.c             |    4 +
 xen/include/asm-arm/mm.h          |    4 +
 xen/include/asm-x86/domain.h      |    1 +
 xen/include/asm-x86/mem_sharing.h |   10 ++
 xen/include/asm-x86/p2m.h         |    4 +
 xen/arch/x86/mm/mem_sharing.c     |  142 +++++++++++++++++++++++--------
 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 10 files changed, 354 insertions(+), 55 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlL-0005Nj-Hj; Thu, 12 Apr 2012 14:12:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlK-0005NT-CJ
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:38 +0000
Received: from [85.158.143.35:37372] by server-1.bemta-4.messagelabs.com id
	02/F6-20925-5D2E68F4; Thu, 12 Apr 2012 14:12:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334239956!4552203!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24484 invoked from network); 12 Apr 2012 14:12:36 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-21.messagelabs.com with SMTP;
	12 Apr 2012 14:12:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 8C3B330007B;
	Thu, 12 Apr 2012 07:12:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=kmzsKtL2vLjskyhA9exXRFfz8E/ZmH8jgFzXxIsjLlMD
	fTS9+GTNYkQl7gfuWmhYRrT0aPC/+tJik61hgBJDQx7osS6B010vZhvXBZjm+c86
	QTz0lwKnSIvcpD2+i9sI5qE70nv+nCcMP1HjyKFHYePuMYWdELHOkBFMrL5Ep/w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=86cEsIPGl9pGguJZ7E1VjIGPA2M=; b=ueRMw58V8fK
	FzWUiYEbYw1E5bTOeQn2zY6qOfoNd0NDxU7X70JkzjKoYgPg9/jWbE0M5qhbP7DI
	cyzuu2cSae2xNb4/N+O2bTMh6BFDvRCqUFBNejFoBGG/kGcA+EiyxgB8nhK1laAf
	a+O9NKAn556H9rl6h6U0LG+ggZGldNLs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id B251E30006C; 
	Thu, 12 Apr 2012 07:12:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 9cbdf6b230dc6d2d2964317d1db186cb2a7e0e18
Message-Id: <9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334240171@xdev.gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:12 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] x86/mm/sharing: Clean ups for
 relinquishing shared pages on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/domain.c             |  16 ++++++++++++-
 xen/arch/x86/mm/mem_sharing.c     |  45 +++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m.c             |   4 +++
 xen/include/asm-arm/mm.h          |   4 +++
 xen/include/asm-x86/domain.h      |   1 +
 xen/include/asm-x86/mem_sharing.h |  10 ++++++++
 xen/include/asm-x86/p2m.h         |   4 +++
 7 files changed, 82 insertions(+), 2 deletions(-)


When a domain is destroyed, its pages are freed in relinquish_resources in a
preemptible mode, in the context of a synchronous domctl.

P2m entries pointing to shared pages are, however, released during p2m cleanup
in an RCU callback, and in non-preemptible mode.

This is an O(n) operation for a very large n, which may include actually
freeing shared pages for which the domain is the last holder.

To improve responsiveness, move this operation to the preemtible portion of
domain destruction, during the synchronous domain_kill hypercall. And remove
the bulk of the work from the RCU callback.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c74fe64aafeb -r 9cbdf6b230dc xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2132,10 +2132,22 @@ int domain_relinquish_resources(struct d
             }
         }
 
-        d->arch.relmem = RELMEM_xen;
+        d->arch.relmem = RELMEM_shared;
         /* fallthrough */
 
-        /* Relinquish every page of memory. */
+    case RELMEM_shared:
+
+        if ( is_hvm_domain(d) )
+        {
+            /* If the domain has shared pages, relinquish them allowing
+             * for preemption. */
+            ret = relinquish_shared_pages(d);
+            if ( ret )
+                return ret;
+        }
+
+        d->arch.relmem = RELMEM_xen;
+        /* Fallthrough. Relinquish every page of memory. */
     case RELMEM_xen:
         ret = relinquish_memory(d, &d->xenpage_list, ~0UL);
         if ( ret )
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -33,6 +33,7 @@
 #include <asm/mem_event.h>
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
+#include <asm/event.h>
 
 #include "mm-locks.h"
 
@@ -1034,6 +1035,50 @@ private_page_found:
     return 0;
 }
 
+int relinquish_shared_pages(struct domain *d)
+{
+    int rc = 0;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    unsigned long gfn, count = 0;
+
+    if ( p2m == NULL )
+        return 0;
+
+    p2m_lock(p2m);
+    for (gfn = p2m->next_shared_gfn_to_relinquish; 
+         gfn < p2m->max_mapped_pfn; gfn++ )
+    {
+        p2m_access_t a;
+        p2m_type_t t;
+        mfn_t mfn;
+        if ( atomic_read(&d->shr_pages) == 0 )
+            break;
+        mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
+        if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
+        {
+            /* Does not fail with ENOMEM given the DESTROY flag */
+            BUG_ON(__mem_sharing_unshare_page(d, gfn, 
+                    MEM_SHARING_DESTROY_GFN));
+            /* Clear out the p2m entry so no one else may try to 
+             * unshare */
+            p2m->set_entry(p2m, gfn, _mfn(0), PAGE_ORDER_4K,
+                            p2m_invalid, p2m_access_rwx);
+            count++;
+        }
+
+        /* Preempt every 2MiB. Arbitrary */
+        if ( (count == 512) && hypercall_preempt_check() )
+        {
+            p2m->next_shared_gfn_to_relinquish = gfn + 1;
+            rc = -EAGAIN;
+            break;
+        }
+    }
+
+    p2m_unlock(p2m);
+    return rc;
+}
+
 int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
     int rc = 0;
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -371,9 +371,13 @@ void p2m_teardown(struct p2m_domain *p2m
     p2m_lock(p2m);
 
 #ifdef __x86_64__
+    /* Try to unshare any remaining shared p2m entries. Safeguard
+     * Since relinquish_shared_pages should have done the work. */ 
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
         p2m_access_t a;
+        if ( atomic_read(&d->shr_pages) == 0 )
+            break;
         mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
         {
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-arm/mm.h
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -251,6 +251,10 @@ int  get_page(struct page_info *page, st
 
 static inline void put_gfn(struct domain *d, unsigned long gfn) {}
 static inline void mem_event_cleanup(struct domain *d) {}
+static inline int relinquish_shared_pages(struct domain *d)
+{
+    return 0;
+}
 
 #define INVALID_MFN             (~0UL)
 
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -296,6 +296,7 @@ struct arch_domain
     /* Continuable domain_relinquish_resources(). */
     enum {
         RELMEM_not_started,
+        RELMEM_shared,
         RELMEM_xen,
         RELMEM_l4,
         RELMEM_l3,
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -89,9 +89,19 @@ int mem_sharing_domctl(struct domain *d,
 int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
+/* Scans the p2m and relinquishes any shared pages, destroying 
+ * those for which this domain holds the final reference.
+ * Preemptible.
+ */
+int relinquish_shared_pages(struct domain *d);
+
 #else 
 
 #define mem_sharing_init()  do { } while (0)
+static inline int relinquish_shared_pages(struct domain *d)
+{
+    return 0;
+}
 
 #endif /* __x86_64__ */
 
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -260,6 +260,10 @@ struct p2m_domain {
     /* Highest guest frame that's ever been mapped in the p2m */
     unsigned long max_mapped_pfn;
 
+    /* When releasing shared gfn's in a preemptible manner, recall where
+     * to resume the search */
+    unsigned long next_shared_gfn_to_relinquish;
+
     /* Populate-on-demand variables
      * All variables are protected with the pod lock. We cannot rely on
      * the p2m lock if it's turned into a fine-grained lock.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlL-0005Nj-Hj; Thu, 12 Apr 2012 14:12:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlK-0005NT-CJ
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:38 +0000
Received: from [85.158.143.35:37372] by server-1.bemta-4.messagelabs.com id
	02/F6-20925-5D2E68F4; Thu, 12 Apr 2012 14:12:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334239956!4552203!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24484 invoked from network); 12 Apr 2012 14:12:36 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-21.messagelabs.com with SMTP;
	12 Apr 2012 14:12:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 8C3B330007B;
	Thu, 12 Apr 2012 07:12:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=kmzsKtL2vLjskyhA9exXRFfz8E/ZmH8jgFzXxIsjLlMD
	fTS9+GTNYkQl7gfuWmhYRrT0aPC/+tJik61hgBJDQx7osS6B010vZhvXBZjm+c86
	QTz0lwKnSIvcpD2+i9sI5qE70nv+nCcMP1HjyKFHYePuMYWdELHOkBFMrL5Ep/w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=86cEsIPGl9pGguJZ7E1VjIGPA2M=; b=ueRMw58V8fK
	FzWUiYEbYw1E5bTOeQn2zY6qOfoNd0NDxU7X70JkzjKoYgPg9/jWbE0M5qhbP7DI
	cyzuu2cSae2xNb4/N+O2bTMh6BFDvRCqUFBNejFoBGG/kGcA+EiyxgB8nhK1laAf
	a+O9NKAn556H9rl6h6U0LG+ggZGldNLs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id B251E30006C; 
	Thu, 12 Apr 2012 07:12:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 9cbdf6b230dc6d2d2964317d1db186cb2a7e0e18
Message-Id: <9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334240171@xdev.gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:12 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] x86/mm/sharing: Clean ups for
 relinquishing shared pages on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/domain.c             |  16 ++++++++++++-
 xen/arch/x86/mm/mem_sharing.c     |  45 +++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m.c             |   4 +++
 xen/include/asm-arm/mm.h          |   4 +++
 xen/include/asm-x86/domain.h      |   1 +
 xen/include/asm-x86/mem_sharing.h |  10 ++++++++
 xen/include/asm-x86/p2m.h         |   4 +++
 7 files changed, 82 insertions(+), 2 deletions(-)


When a domain is destroyed, its pages are freed in relinquish_resources in a
preemptible mode, in the context of a synchronous domctl.

P2m entries pointing to shared pages are, however, released during p2m cleanup
in an RCU callback, and in non-preemptible mode.

This is an O(n) operation for a very large n, which may include actually
freeing shared pages for which the domain is the last holder.

To improve responsiveness, move this operation to the preemtible portion of
domain destruction, during the synchronous domain_kill hypercall. And remove
the bulk of the work from the RCU callback.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c74fe64aafeb -r 9cbdf6b230dc xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2132,10 +2132,22 @@ int domain_relinquish_resources(struct d
             }
         }
 
-        d->arch.relmem = RELMEM_xen;
+        d->arch.relmem = RELMEM_shared;
         /* fallthrough */
 
-        /* Relinquish every page of memory. */
+    case RELMEM_shared:
+
+        if ( is_hvm_domain(d) )
+        {
+            /* If the domain has shared pages, relinquish them allowing
+             * for preemption. */
+            ret = relinquish_shared_pages(d);
+            if ( ret )
+                return ret;
+        }
+
+        d->arch.relmem = RELMEM_xen;
+        /* Fallthrough. Relinquish every page of memory. */
     case RELMEM_xen:
         ret = relinquish_memory(d, &d->xenpage_list, ~0UL);
         if ( ret )
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -33,6 +33,7 @@
 #include <asm/mem_event.h>
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
+#include <asm/event.h>
 
 #include "mm-locks.h"
 
@@ -1034,6 +1035,50 @@ private_page_found:
     return 0;
 }
 
+int relinquish_shared_pages(struct domain *d)
+{
+    int rc = 0;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    unsigned long gfn, count = 0;
+
+    if ( p2m == NULL )
+        return 0;
+
+    p2m_lock(p2m);
+    for (gfn = p2m->next_shared_gfn_to_relinquish; 
+         gfn < p2m->max_mapped_pfn; gfn++ )
+    {
+        p2m_access_t a;
+        p2m_type_t t;
+        mfn_t mfn;
+        if ( atomic_read(&d->shr_pages) == 0 )
+            break;
+        mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
+        if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
+        {
+            /* Does not fail with ENOMEM given the DESTROY flag */
+            BUG_ON(__mem_sharing_unshare_page(d, gfn, 
+                    MEM_SHARING_DESTROY_GFN));
+            /* Clear out the p2m entry so no one else may try to 
+             * unshare */
+            p2m->set_entry(p2m, gfn, _mfn(0), PAGE_ORDER_4K,
+                            p2m_invalid, p2m_access_rwx);
+            count++;
+        }
+
+        /* Preempt every 2MiB. Arbitrary */
+        if ( (count == 512) && hypercall_preempt_check() )
+        {
+            p2m->next_shared_gfn_to_relinquish = gfn + 1;
+            rc = -EAGAIN;
+            break;
+        }
+    }
+
+    p2m_unlock(p2m);
+    return rc;
+}
+
 int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
     int rc = 0;
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -371,9 +371,13 @@ void p2m_teardown(struct p2m_domain *p2m
     p2m_lock(p2m);
 
 #ifdef __x86_64__
+    /* Try to unshare any remaining shared p2m entries. Safeguard
+     * Since relinquish_shared_pages should have done the work. */ 
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
         p2m_access_t a;
+        if ( atomic_read(&d->shr_pages) == 0 )
+            break;
         mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
         {
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-arm/mm.h
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -251,6 +251,10 @@ int  get_page(struct page_info *page, st
 
 static inline void put_gfn(struct domain *d, unsigned long gfn) {}
 static inline void mem_event_cleanup(struct domain *d) {}
+static inline int relinquish_shared_pages(struct domain *d)
+{
+    return 0;
+}
 
 #define INVALID_MFN             (~0UL)
 
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -296,6 +296,7 @@ struct arch_domain
     /* Continuable domain_relinquish_resources(). */
     enum {
         RELMEM_not_started,
+        RELMEM_shared,
         RELMEM_xen,
         RELMEM_l4,
         RELMEM_l3,
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -89,9 +89,19 @@ int mem_sharing_domctl(struct domain *d,
 int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
+/* Scans the p2m and relinquishes any shared pages, destroying 
+ * those for which this domain holds the final reference.
+ * Preemptible.
+ */
+int relinquish_shared_pages(struct domain *d);
+
 #else 
 
 #define mem_sharing_init()  do { } while (0)
+static inline int relinquish_shared_pages(struct domain *d)
+{
+    return 0;
+}
 
 #endif /* __x86_64__ */
 
diff -r c74fe64aafeb -r 9cbdf6b230dc xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -260,6 +260,10 @@ struct p2m_domain {
     /* Highest guest frame that's ever been mapped in the p2m */
     unsigned long max_mapped_pfn;
 
+    /* When releasing shared gfn's in a preemptible manner, recall where
+     * to resume the search */
+    unsigned long next_shared_gfn_to_relinquish;
+
     /* Populate-on-demand variables
      * All variables are protected with the pod lock. We cannot rely on
      * the p2m lock if it's turned into a fine-grained lock.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlR-0005P1-47; Thu, 12 Apr 2012 14:12:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlP-0005NT-3n
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:43 +0000
Received: from [85.158.143.99:57578] by server-1.bemta-4.messagelabs.com id
	CB/07-20925-AD2E68F4; Thu, 12 Apr 2012 14:12:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334239958!24814989!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTcxMzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13035 invoked from network); 12 Apr 2012 14:12:39 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-2.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 14:12:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 99F8C300072;
	Thu, 12 Apr 2012 07:12:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=b3X+lv/dUE71OqkUIzE6/mgUf6SDTIF56eKJ3yJ2BPt/
	Qg0bwLv2NdrlEm9rooUriE51c78K6GkPo5QCRfw/s5rVtvmX/LygzrveMQ6OijvU
	aS6Y/CTN4omVynk6A+Sez9rqgURziWNws6LyKcGz1UL/cRLZpOVyTMNpK2GbnEA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=SP+3DpAihcT0TiSVK4GnM53F0uI=; b=Do76tMNzCiF
	ZYu10WYpQrdojzuvGktE7A7JU33JjC+je78QX8KbxDvljJlChFtdOGrTk0iFJG6c
	uRakyoGgnb/A83LfViVuFRtG9DJHpZ1MVNj9AM1tHEGNck20Pzq2GzkratidWk5f
	DUADQnTFn8b9J2NTQysl6NelsaC+iISU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id C196E30006C; 
	Thu, 12 Apr 2012 07:12:35 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1730bff8fccfb08cee3f7539669cae6af5b24208
Message-Id: <1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334240171@xdev.gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:13 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse map
 for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  142 ++++++++++++++++++++++++++++++-----------
 1 files changed, 103 insertions(+), 39 deletions(-)


Each shared frame maintains a reverse map of <domain, gfn> tuples, so we know
which tuples this shared frame is backing. This is useful for auditing and
sanity-checking, and necessary to update all relevant p2m entries when sharing.

The reverse map is maintained as a doubly linked list, but the interface is
open-coded throughout the mem_sharing.c subsystem. Bury it inside a level of
abstraction, so it can later support different (more scalable) rmap
implementations.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9cbdf6b230dc -r 1730bff8fccf xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -69,7 +69,8 @@ static inline void audit_add_list(struct
     spin_unlock(&shr_audit_lock);
 }
 
-static inline void audit_del_list(struct page_info *page)
+/* Removes from the audit list and cleans up the page sharing metadata. */
+static inline void page_sharing_dispose(struct page_info *page)
 {
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
@@ -86,7 +87,7 @@ int mem_sharing_audit(void)
 }
 
 #define audit_add_list(p)  ((void)0)
-static inline void audit_del_list(struct page_info *page)
+static inline void page_sharing_dispose(struct page_info *page)
 {
     xfree(page->sharing);
 }
@@ -143,6 +144,7 @@ static inline shr_handle_t get_next_hand
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
+/** Reverse map **/
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -150,15 +152,77 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-/* Returns true if list has only one entry. O(1) complexity. */
-static inline int list_has_one_entry(struct list_head *head)
+static inline void
+rmap_init(struct page_info *page)
 {
+    INIT_LIST_HEAD(&page->sharing->gfns);
+}
+
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+{
+    list_del(&gfn_info->list);
+}
+
+static inline void
+rmap_add(gfn_info_t *gfn_info, struct page_info *page)
+{
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->sharing->gfns);
+}
+
+static inline gfn_info_t *
+rmap_retrieve(uint16_t domain_id, unsigned long gfn, 
+                            struct page_info *page)
+{
+    gfn_info_t *gfn_info;
+    struct list_head *le;
+    list_for_each(le, &page->sharing->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
+            return gfn_info;
+    }
+    return NULL;
+}
+
+/* Returns true if the rmap has only one entry. O(1) complexity. */
+static inline int rmap_has_one_entry(struct page_info *page)
+{
+    struct list_head *head = &page->sharing->gfns;
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline gfn_info_t *gfn_get_info(struct list_head *list)
+/* Returns true if the rmap has any entries. O(1) complexity. */
+static inline int rmap_has_entries(struct page_info *page)
 {
-    return list_entry(list->next, gfn_info_t, list);
+    return (!list_empty(&page->sharing->gfns));
+}
+
+/* The iterator hides the details of how the rmap is implemented. This
+ * involves splitting the list_for_each_safe macro into two steps. */
+struct rmap_iterator {
+    struct list_head *curr;
+    struct list_head *next;
+};
+
+static inline void
+rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
+{
+    ri->curr = &page->sharing->gfns;
+    ri->next = ri->curr->next; 
+}
+
+static inline gfn_info_t *
+rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
+{
+    if ( ri->next == &page->sharing->gfns)
+        return NULL;
+
+    ri->curr = ri->next;
+    ri->next = ri->curr->next;
+
+    return list_entry(ri->curr, gfn_info_t, list);
 }
 
 static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
@@ -172,8 +236,8 @@ static inline gfn_info_t *mem_sharing_gf
 
     gfn_info->gfn = gfn;
     gfn_info->domain = d->domain_id;
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+
+    rmap_add(gfn_info, page);
 
     /* Increment our number of shared pges. */
     atomic_inc(&d->shr_pages);
@@ -181,14 +245,15 @@ static inline gfn_info_t *mem_sharing_gf
     return gfn_info;
 }
 
-static inline void mem_sharing_gfn_destroy(struct domain *d,
+static inline void mem_sharing_gfn_destroy(struct page_info *page,
+                                           struct domain *d,
                                            gfn_info_t *gfn_info)
 {
     /* Decrement the number of pages. */
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    list_del(&gfn_info->list);
+    rmap_del(gfn_info, page);
     xfree(gfn_info);
 }
 
@@ -230,8 +295,9 @@ int mem_sharing_audit(void)
         struct page_sharing_info *pg_shared_info;
         unsigned long nr_gfns = 0;
         struct page_info *pg;
-        struct list_head *le;
         mfn_t mfn;
+        gfn_info_t *g;
+        struct rmap_iterator ri;
 
         pg_shared_info = list_entry(ae, struct page_sharing_info, entry);
         pg = pg_shared_info->pg;
@@ -272,7 +338,7 @@ int mem_sharing_audit(void)
         }
 
         /* Check we have a list */
-        if ( (!pg->sharing) || (list_empty(&pg->sharing->gfns)) )
+        if ( (!pg->sharing) || !rmap_has_entries(pg) )
         {
            MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
                              mfn_x(mfn));
@@ -284,14 +350,13 @@ int mem_sharing_audit(void)
         count_found++;
 
         /* Check if all GFNs map to the MFN, and the p2m types */
-        list_for_each(le, &pg->sharing->gfns)
+        rmap_seed_iterator(pg, &ri);
+        while ( (g = rmap_iterate(pg, &ri)) != NULL )
         {
             struct domain *d;
             p2m_type_t t;
             mfn_t o_mfn;
-            gfn_info_t *g;
 
-            g = list_entry(le, gfn_info_t, list);
             d = get_domain_by_id(g->domain);
             if ( d == NULL )
             {
@@ -677,7 +742,7 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
     page->sharing->pg = page;
-    INIT_LIST_HEAD(&page->sharing->gfns);
+    rmap_init(page);
 
     /* Create the handle */
     page->sharing->handle = get_next_handle();  
@@ -698,7 +763,7 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
-        mem_sharing_gfn_destroy(d, gfn_info);
+        mem_sharing_gfn_destroy(page, d, gfn_info);
         xfree(page->sharing);
         page->sharing = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
@@ -726,13 +791,13 @@ int mem_sharing_share_pages(struct domai
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
     struct page_info *spage, *cpage, *firstpg, *secondpg;
-    struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
     struct two_gfns tg;
+    struct rmap_iterator ri;
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, NULL, &cmfn,
@@ -799,15 +864,15 @@ int mem_sharing_share_pages(struct domai
     }
 
     /* Merge the lists together */
-    list_for_each_safe(le, te, &cpage->sharing->gfns)
+    rmap_seed_iterator(cpage, &ri);
+    while ( (gfn = rmap_iterate(cpage, &ri)) != NULL)
     {
-        gfn = list_entry(le, gfn_info_t, list);
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
         /* Move the gfn_info from client list to source list */
-        list_del(&gfn->list);
-        list_add(&gfn->list, &spage->sharing->gfns);
+        rmap_del(gfn, cpage);
+        rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
@@ -817,7 +882,7 @@ int mem_sharing_share_pages(struct domai
     ASSERT(list_empty(&cpage->sharing->gfns));
 
     /* Clear the rest of the shared state */
-    audit_del_list(cpage);
+    page_sharing_dispose(cpage);
     cpage->sharing = NULL;
 
     mem_sharing_page_unlock(secondpg);
@@ -887,7 +952,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( !ret )
     {
         ret = -ENOENT;
-        mem_sharing_gfn_destroy(cd, gfn_info);
+        mem_sharing_gfn_destroy(spage, cd, gfn_info);
         put_page_and_type(spage);
     } else {
         ret = 0;
@@ -929,7 +994,6 @@ int __mem_sharing_unshare_page(struct do
     void *s, *t;
     int last_gfn;
     gfn_info_t *gfn_info = NULL;
-    struct list_head *le;
    
     mfn = get_gfn(d, gfn, &p2mt);
     
@@ -947,34 +1011,35 @@ int __mem_sharing_unshare_page(struct do
         BUG();
     }
 
-    list_for_each(le, &page->sharing->gfns)
+    gfn_info = rmap_retrieve(d->domain_id, gfn, page);
+    if ( unlikely(gfn_info == NULL) )
     {
-        gfn_info = list_entry(le, gfn_info_t, list);
-        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
-            goto gfn_found;
+        gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                                "%lx\n", gfn);
+        BUG();
     }
-    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
-                            "%lx\n", gfn);
-    BUG();
 
-gfn_found:
     /* Do the accounting first. If anything fails below, we have bigger
      * bigger fish to fry. First, remove the gfn from the list. */ 
-    last_gfn = list_has_one_entry(&page->sharing->gfns);
+    last_gfn = rmap_has_one_entry(page);
     if ( last_gfn )
     {
-        /* Clean up shared state */
-        audit_del_list(page);
+        /* Clean up shared state. Get rid of the <domid, gfn> tuple
+         * before destroying the rmap. */
+        mem_sharing_gfn_destroy(page, d, gfn_info);
+        page_sharing_dispose(page);
         page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
+
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
+        if ( !last_gfn )
+            mem_sharing_gfn_destroy(page, d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -987,7 +1052,6 @@ gfn_found:
  
     if ( last_gfn )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
@@ -1011,7 +1075,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
-    mem_sharing_gfn_destroy(d, gfn_info);
+    mem_sharing_gfn_destroy(old_page, d, gfn_info);
     mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlR-0005P1-47; Thu, 12 Apr 2012 14:12:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlP-0005NT-3n
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:43 +0000
Received: from [85.158.143.99:57578] by server-1.bemta-4.messagelabs.com id
	CB/07-20925-AD2E68F4; Thu, 12 Apr 2012 14:12:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334239958!24814989!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTcxMzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13035 invoked from network); 12 Apr 2012 14:12:39 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-2.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 14:12:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 99F8C300072;
	Thu, 12 Apr 2012 07:12:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=b3X+lv/dUE71OqkUIzE6/mgUf6SDTIF56eKJ3yJ2BPt/
	Qg0bwLv2NdrlEm9rooUriE51c78K6GkPo5QCRfw/s5rVtvmX/LygzrveMQ6OijvU
	aS6Y/CTN4omVynk6A+Sez9rqgURziWNws6LyKcGz1UL/cRLZpOVyTMNpK2GbnEA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=SP+3DpAihcT0TiSVK4GnM53F0uI=; b=Do76tMNzCiF
	ZYu10WYpQrdojzuvGktE7A7JU33JjC+je78QX8KbxDvljJlChFtdOGrTk0iFJG6c
	uRakyoGgnb/A83LfViVuFRtG9DJHpZ1MVNj9AM1tHEGNck20Pzq2GzkratidWk5f
	DUADQnTFn8b9J2NTQysl6NelsaC+iISU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id C196E30006C; 
	Thu, 12 Apr 2012 07:12:35 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1730bff8fccfb08cee3f7539669cae6af5b24208
Message-Id: <1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334240171@xdev.gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:13 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse map
 for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  142 ++++++++++++++++++++++++++++++-----------
 1 files changed, 103 insertions(+), 39 deletions(-)


Each shared frame maintains a reverse map of <domain, gfn> tuples, so we know
which tuples this shared frame is backing. This is useful for auditing and
sanity-checking, and necessary to update all relevant p2m entries when sharing.

The reverse map is maintained as a doubly linked list, but the interface is
open-coded throughout the mem_sharing.c subsystem. Bury it inside a level of
abstraction, so it can later support different (more scalable) rmap
implementations.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9cbdf6b230dc -r 1730bff8fccf xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -69,7 +69,8 @@ static inline void audit_add_list(struct
     spin_unlock(&shr_audit_lock);
 }
 
-static inline void audit_del_list(struct page_info *page)
+/* Removes from the audit list and cleans up the page sharing metadata. */
+static inline void page_sharing_dispose(struct page_info *page)
 {
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
@@ -86,7 +87,7 @@ int mem_sharing_audit(void)
 }
 
 #define audit_add_list(p)  ((void)0)
-static inline void audit_del_list(struct page_info *page)
+static inline void page_sharing_dispose(struct page_info *page)
 {
     xfree(page->sharing);
 }
@@ -143,6 +144,7 @@ static inline shr_handle_t get_next_hand
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
+/** Reverse map **/
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -150,15 +152,77 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-/* Returns true if list has only one entry. O(1) complexity. */
-static inline int list_has_one_entry(struct list_head *head)
+static inline void
+rmap_init(struct page_info *page)
 {
+    INIT_LIST_HEAD(&page->sharing->gfns);
+}
+
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+{
+    list_del(&gfn_info->list);
+}
+
+static inline void
+rmap_add(gfn_info_t *gfn_info, struct page_info *page)
+{
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->sharing->gfns);
+}
+
+static inline gfn_info_t *
+rmap_retrieve(uint16_t domain_id, unsigned long gfn, 
+                            struct page_info *page)
+{
+    gfn_info_t *gfn_info;
+    struct list_head *le;
+    list_for_each(le, &page->sharing->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
+            return gfn_info;
+    }
+    return NULL;
+}
+
+/* Returns true if the rmap has only one entry. O(1) complexity. */
+static inline int rmap_has_one_entry(struct page_info *page)
+{
+    struct list_head *head = &page->sharing->gfns;
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline gfn_info_t *gfn_get_info(struct list_head *list)
+/* Returns true if the rmap has any entries. O(1) complexity. */
+static inline int rmap_has_entries(struct page_info *page)
 {
-    return list_entry(list->next, gfn_info_t, list);
+    return (!list_empty(&page->sharing->gfns));
+}
+
+/* The iterator hides the details of how the rmap is implemented. This
+ * involves splitting the list_for_each_safe macro into two steps. */
+struct rmap_iterator {
+    struct list_head *curr;
+    struct list_head *next;
+};
+
+static inline void
+rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
+{
+    ri->curr = &page->sharing->gfns;
+    ri->next = ri->curr->next; 
+}
+
+static inline gfn_info_t *
+rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
+{
+    if ( ri->next == &page->sharing->gfns)
+        return NULL;
+
+    ri->curr = ri->next;
+    ri->next = ri->curr->next;
+
+    return list_entry(ri->curr, gfn_info_t, list);
 }
 
 static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
@@ -172,8 +236,8 @@ static inline gfn_info_t *mem_sharing_gf
 
     gfn_info->gfn = gfn;
     gfn_info->domain = d->domain_id;
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+
+    rmap_add(gfn_info, page);
 
     /* Increment our number of shared pges. */
     atomic_inc(&d->shr_pages);
@@ -181,14 +245,15 @@ static inline gfn_info_t *mem_sharing_gf
     return gfn_info;
 }
 
-static inline void mem_sharing_gfn_destroy(struct domain *d,
+static inline void mem_sharing_gfn_destroy(struct page_info *page,
+                                           struct domain *d,
                                            gfn_info_t *gfn_info)
 {
     /* Decrement the number of pages. */
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    list_del(&gfn_info->list);
+    rmap_del(gfn_info, page);
     xfree(gfn_info);
 }
 
@@ -230,8 +295,9 @@ int mem_sharing_audit(void)
         struct page_sharing_info *pg_shared_info;
         unsigned long nr_gfns = 0;
         struct page_info *pg;
-        struct list_head *le;
         mfn_t mfn;
+        gfn_info_t *g;
+        struct rmap_iterator ri;
 
         pg_shared_info = list_entry(ae, struct page_sharing_info, entry);
         pg = pg_shared_info->pg;
@@ -272,7 +338,7 @@ int mem_sharing_audit(void)
         }
 
         /* Check we have a list */
-        if ( (!pg->sharing) || (list_empty(&pg->sharing->gfns)) )
+        if ( (!pg->sharing) || !rmap_has_entries(pg) )
         {
            MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
                              mfn_x(mfn));
@@ -284,14 +350,13 @@ int mem_sharing_audit(void)
         count_found++;
 
         /* Check if all GFNs map to the MFN, and the p2m types */
-        list_for_each(le, &pg->sharing->gfns)
+        rmap_seed_iterator(pg, &ri);
+        while ( (g = rmap_iterate(pg, &ri)) != NULL )
         {
             struct domain *d;
             p2m_type_t t;
             mfn_t o_mfn;
-            gfn_info_t *g;
 
-            g = list_entry(le, gfn_info_t, list);
             d = get_domain_by_id(g->domain);
             if ( d == NULL )
             {
@@ -677,7 +742,7 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
     page->sharing->pg = page;
-    INIT_LIST_HEAD(&page->sharing->gfns);
+    rmap_init(page);
 
     /* Create the handle */
     page->sharing->handle = get_next_handle();  
@@ -698,7 +763,7 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
-        mem_sharing_gfn_destroy(d, gfn_info);
+        mem_sharing_gfn_destroy(page, d, gfn_info);
         xfree(page->sharing);
         page->sharing = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
@@ -726,13 +791,13 @@ int mem_sharing_share_pages(struct domai
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
     struct page_info *spage, *cpage, *firstpg, *secondpg;
-    struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
     struct two_gfns tg;
+    struct rmap_iterator ri;
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, NULL, &cmfn,
@@ -799,15 +864,15 @@ int mem_sharing_share_pages(struct domai
     }
 
     /* Merge the lists together */
-    list_for_each_safe(le, te, &cpage->sharing->gfns)
+    rmap_seed_iterator(cpage, &ri);
+    while ( (gfn = rmap_iterate(cpage, &ri)) != NULL)
     {
-        gfn = list_entry(le, gfn_info_t, list);
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
         /* Move the gfn_info from client list to source list */
-        list_del(&gfn->list);
-        list_add(&gfn->list, &spage->sharing->gfns);
+        rmap_del(gfn, cpage);
+        rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
@@ -817,7 +882,7 @@ int mem_sharing_share_pages(struct domai
     ASSERT(list_empty(&cpage->sharing->gfns));
 
     /* Clear the rest of the shared state */
-    audit_del_list(cpage);
+    page_sharing_dispose(cpage);
     cpage->sharing = NULL;
 
     mem_sharing_page_unlock(secondpg);
@@ -887,7 +952,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( !ret )
     {
         ret = -ENOENT;
-        mem_sharing_gfn_destroy(cd, gfn_info);
+        mem_sharing_gfn_destroy(spage, cd, gfn_info);
         put_page_and_type(spage);
     } else {
         ret = 0;
@@ -929,7 +994,6 @@ int __mem_sharing_unshare_page(struct do
     void *s, *t;
     int last_gfn;
     gfn_info_t *gfn_info = NULL;
-    struct list_head *le;
    
     mfn = get_gfn(d, gfn, &p2mt);
     
@@ -947,34 +1011,35 @@ int __mem_sharing_unshare_page(struct do
         BUG();
     }
 
-    list_for_each(le, &page->sharing->gfns)
+    gfn_info = rmap_retrieve(d->domain_id, gfn, page);
+    if ( unlikely(gfn_info == NULL) )
     {
-        gfn_info = list_entry(le, gfn_info_t, list);
-        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
-            goto gfn_found;
+        gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                                "%lx\n", gfn);
+        BUG();
     }
-    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
-                            "%lx\n", gfn);
-    BUG();
 
-gfn_found:
     /* Do the accounting first. If anything fails below, we have bigger
      * bigger fish to fry. First, remove the gfn from the list. */ 
-    last_gfn = list_has_one_entry(&page->sharing->gfns);
+    last_gfn = rmap_has_one_entry(page);
     if ( last_gfn )
     {
-        /* Clean up shared state */
-        audit_del_list(page);
+        /* Clean up shared state. Get rid of the <domid, gfn> tuple
+         * before destroying the rmap. */
+        mem_sharing_gfn_destroy(page, d, gfn_info);
+        page_sharing_dispose(page);
         page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
+
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
+        if ( !last_gfn )
+            mem_sharing_gfn_destroy(page, d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -987,7 +1052,6 @@ gfn_found:
  
     if ( last_gfn )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
@@ -1011,7 +1075,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
-    mem_sharing_gfn_destroy(d, gfn_info);
+    mem_sharing_gfn_destroy(old_page, d, gfn_info);
     mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlR-0005PG-GM; Thu, 12 Apr 2012 14:12:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlP-0005Nw-CQ
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:43 +0000
Received: from [85.158.138.51:44822] by server-4.bemta-3.messagelabs.com id
	A0/C1-15341-8D2E68F4; Thu, 12 Apr 2012 14:12:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334239958!21833947!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY3NDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15993 invoked from network); 12 Apr 2012 14:12:39 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-11.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 14:12:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id CF19430006C;
	Thu, 12 Apr 2012 07:12:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=p+P0Fwdo7vbEjBnK+t8JcREQbPqYq1afszUefLySV9Ya
	WcPv/S+gx0MNbSlTrvG5ewUFPybHPj5gE835v3hum0d6cMcaYL7Lh2k20nEPrpBG
	8ivd8PjAgthm80yLPSSChb/eyEd4l7xSciponNw+j6m7krC4zzAQR/Y0EuFRsco=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=0dTDHpZIKGaqn+gkEKGyhvOsoFw=; b=uYxFG1Leo4/
	TEHQ3hYipcWWf9eLxAPC6p/2e89WldIZQunwdLPOdRxkK2QC7ADxHkJoEh7OqUUZ
	yDg0wbWCN6Uh51fA76dlNUmHzxD3KBYnPfTUuaGMc99WOr2WFbahi3WHq32TagBN
	B5XjYd2u3GYjMjP1oySM9eU4xPc9KPAE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id DF00B300079; 
	Thu, 12 Apr 2012 07:12:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 7b606c043208d98d218b4e08f68398073aa2b1f2
Message-Id: <7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334240171@xdev.gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:14 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages with
 many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 2 files changed, 169 insertions(+), 14 deletions(-)


For shared frames that have many references, the doubly-linked list used to
store the rmap results in costly scans during unshare operations. To alleviate
the overhead, replace the linked list by a hash table. However, hash tables are
space-intensive, so only use them for pages that have "many" (arbitrary
threshold) references.

Unsharing is heaviliy exercised during domain destroy. In experimental testing,
for a domain that points over 100 thousand pages to the same shared frame,
domain destruction dropped from over 7 minutes(!) to less than two seconds.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1730bff8fccf -r 7b606c043208 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -49,6 +49,17 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
+/* Reverse map defines */
+#define RMAP_HASHTAB_ORDER  0
+#define RMAP_HASHTAB_SIZE   \
+        ((PAGE_SIZE << RMAP_HASHTAB_ORDER) / sizeof(struct list_head))
+#define RMAP_USES_HASHTAB(page) \
+        ((page)->sharing->hash_table.flag == NULL)
+#define RMAP_HEAVY_SHARED_PAGE   RMAP_HASHTAB_SIZE
+/* A bit of hysteresis. We don't want to be mutating between list and hash
+ * table constantly. */
+#define RMAP_LIGHT_SHARED_PAGE   (RMAP_HEAVY_SHARED_PAGE >> 2)
+
 #if MEM_SHARING_AUDIT
 
 static struct list_head shr_audit_list;
@@ -72,6 +83,11 @@ static inline void audit_add_list(struct
 /* Removes from the audit list and cleans up the page sharing metadata. */
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
+
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
     spin_unlock(&shr_audit_lock);
@@ -89,6 +105,10 @@ int mem_sharing_audit(void)
 #define audit_add_list(p)  ((void)0)
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
     xfree(page->sharing);
 }
 
@@ -145,6 +165,11 @@ static atomic_t nr_saved_mfns   = ATOMIC
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 /** Reverse map **/
+/* Every shared frame keeps a reverse map (rmap) of <domain, gfn> tuples that
+ * this shared frame backs. For pages with a low degree of sharing, a O(n)
+ * search linked list is good enough. For pages with higher degree of sharing,
+ * we use a hash table instead. */
+
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -155,20 +180,109 @@ typedef struct gfn_info
 static inline void
 rmap_init(struct page_info *page)
 {
+    /* We always start off as a doubly linked list. */
     INIT_LIST_HEAD(&page->sharing->gfns);
 }
 
+/* Exceedingly simple "hash function" */
+#define HASH(domain, gfn)       \
+    (((gfn) + (domain)) % RMAP_HASHTAB_SIZE)
+
+/* Conversions. Tuned by the thresholds. Should only happen twice 
+ * (once each) during the lifetime of a shared page */
+static inline int
+rmap_list_to_hash_table(struct page_info *page)
+{
+    unsigned int i;
+    struct list_head *pos, *tmp, *b =
+        alloc_xenheap_pages(RMAP_HASHTAB_ORDER, 0);
+
+    if ( b == NULL )
+        return -ENOMEM;
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+        INIT_LIST_HEAD(b + i);
+
+    list_for_each_safe(pos, tmp, &page->sharing->gfns)
+    {
+        gfn_info_t *gfn_info = list_entry(pos, gfn_info_t, list);
+        struct list_head *bucket = b + HASH(gfn_info->domain, gfn_info->gfn);
+        list_del(pos);
+        list_add(pos, bucket);
+    }
+
+    page->sharing->hash_table.bucket = b;
+    page->sharing->hash_table.flag   = NULL;
+
+    return 0;
+}
+
 static inline void
-rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+rmap_hash_table_to_list(struct page_info *page)
 {
+    unsigned int i;
+    struct list_head *bucket = page->sharing->hash_table.bucket;
+
+    INIT_LIST_HEAD(&page->sharing->gfns);
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+    {
+        struct list_head *pos, *tmp, *head = bucket + i;
+        list_for_each_safe(pos, tmp, head)
+        {
+            list_del(pos);
+            list_add(pos, &page->sharing->gfns);
+        }
+    }
+
+    free_xenheap_pages(bucket, RMAP_HASHTAB_ORDER);
+}
+
+/* Generic accessors to the rmap */
+static inline unsigned long
+rmap_count(struct page_info *pg)
+{
+    unsigned long count;
+    unsigned long t = read_atomic(&pg->u.inuse.type_info);
+    count = t & PGT_count_mask;
+    if ( t & PGT_locked )
+        count--;
+    return count;
+}
+
+/* The page type count is always decreased after removing from the rmap.
+ * Use a convert flag to avoid mutating the rmap if in the middle of an 
+ * iterator, or if the page will be soon destroyed anyways. */
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page, int convert)
+{
+    if ( RMAP_USES_HASHTAB(page) && convert &&
+         (rmap_count(page) <= RMAP_LIGHT_SHARED_PAGE) )
+        rmap_hash_table_to_list(page);
+
+    /* Regardless of rmap type, same removal operation */
     list_del(&gfn_info->list);
 }
 
+/* The page type count is always increased before adding to the rmap. */
 static inline void
 rmap_add(gfn_info_t *gfn_info, struct page_info *page)
 {
+    struct list_head *head;
+
+    if ( !RMAP_USES_HASHTAB(page) &&
+         (rmap_count(page) >= RMAP_HEAVY_SHARED_PAGE) )
+        /* The conversion may fail with ENOMEM. We'll be less efficient,
+         * but no reason to panic. */
+        (void)rmap_list_to_hash_table(page);
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + 
+                            HASH(gfn_info->domain, gfn_info->gfn) :
+        &page->sharing->gfns;
+
     INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+    list_add(&gfn_info->list, head);
 }
 
 static inline gfn_info_t *
@@ -176,27 +290,33 @@ rmap_retrieve(uint16_t domain_id, unsign
                             struct page_info *page)
 {
     gfn_info_t *gfn_info;
-    struct list_head *le;
-    list_for_each(le, &page->sharing->gfns)
+    struct list_head *le, *head;
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + HASH(domain_id, gfn) :
+        &page->sharing->gfns;
+
+    list_for_each(le, head)
     {
         gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
             return gfn_info;
     }
+
+    /* Nothing was found */
     return NULL;
 }
 
 /* Returns true if the rmap has only one entry. O(1) complexity. */
 static inline int rmap_has_one_entry(struct page_info *page)
 {
-    struct list_head *head = &page->sharing->gfns;
-    return (head->next != head) && (head->next->next == head);
+    return (rmap_count(page) == 1);
 }
 
 /* Returns true if the rmap has any entries. O(1) complexity. */
 static inline int rmap_has_entries(struct page_info *page)
 {
-    return (!list_empty(&page->sharing->gfns));
+    return (rmap_count(page) != 0);
 }
 
 /* The iterator hides the details of how the rmap is implemented. This
@@ -204,20 +324,43 @@ static inline int rmap_has_entries(struc
 struct rmap_iterator {
     struct list_head *curr;
     struct list_head *next;
+    unsigned int bucket;
 };
 
 static inline void
 rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
 {
-    ri->curr = &page->sharing->gfns;
+    ri->curr = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket :
+                &page->sharing->gfns;
     ri->next = ri->curr->next; 
+    ri->bucket = 0;
 }
 
 static inline gfn_info_t *
 rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
 {
-    if ( ri->next == &page->sharing->gfns)
-        return NULL;
+    struct list_head *head = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket + ri->bucket :
+                &page->sharing->gfns;
+
+retry:
+    if ( ri->next == head)
+    {
+        if ( RMAP_USES_HASHTAB(page) )
+        {
+            ri->bucket++;
+            if ( ri->bucket >= RMAP_HASHTAB_SIZE )
+                /* No more hash table buckets */
+                return NULL;
+            head = page->sharing->hash_table.bucket + ri->bucket;
+            ri->curr = head;
+            ri->next = ri->curr->next;
+            goto retry;
+        } else
+            /* List exhausted */
+            return NULL;
+    }
 
     ri->curr = ri->next;
     ri->next = ri->curr->next;
@@ -253,7 +396,7 @@ static inline void mem_sharing_gfn_destr
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    rmap_del(gfn_info, page);
+    rmap_del(gfn_info, page, 1);
     xfree(gfn_info);
 }
 
@@ -870,8 +1013,9 @@ int mem_sharing_share_pages(struct domai
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from client list to source list */
-        rmap_del(gfn, cpage);
+        /* Move the gfn_info from client list to source list.
+         * Don't change the type of rmap for the client page. */
+        rmap_del(gfn, cpage, 0);
         rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
diff -r 1730bff8fccf -r 7b606c043208 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -30,6 +30,13 @@
 
 typedef uint64_t shr_handle_t; 
 
+typedef struct rmap_hashtab {
+    struct list_head *bucket;
+    /* Overlaps with prev pointer of list_head in union below.
+     * Unlike the prev pointer, this can be NULL. */
+    void *flag;
+} rmap_hashtab_t;
+
 struct page_sharing_info
 {
     struct page_info *pg;   /* Back pointer to the page. */
@@ -38,7 +45,11 @@ struct page_sharing_info
     struct list_head entry; /* List of all shared pages (entry). */
     struct rcu_head rcu_head; /* List of all shared pages (entry). */
 #endif
-    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+    /* Reverse map of <domain,gfn> tuples for this shared frame. */
+    union {
+        struct list_head    gfns;
+        rmap_hashtab_t      hash_table;
+    };
 };
 
 #ifdef __x86_64__

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKlR-0005PG-GM; Thu, 12 Apr 2012 14:12:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKlP-0005Nw-CQ
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:12:43 +0000
Received: from [85.158.138.51:44822] by server-4.bemta-3.messagelabs.com id
	A0/C1-15341-8D2E68F4; Thu, 12 Apr 2012 14:12:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334239958!21833947!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY3NDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15993 invoked from network); 12 Apr 2012 14:12:39 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-11.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 14:12:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id CF19430006C;
	Thu, 12 Apr 2012 07:12:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=p+P0Fwdo7vbEjBnK+t8JcREQbPqYq1afszUefLySV9Ya
	WcPv/S+gx0MNbSlTrvG5ewUFPybHPj5gE835v3hum0d6cMcaYL7Lh2k20nEPrpBG
	8ivd8PjAgthm80yLPSSChb/eyEd4l7xSciponNw+j6m7krC4zzAQR/Y0EuFRsco=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=0dTDHpZIKGaqn+gkEKGyhvOsoFw=; b=uYxFG1Leo4/
	TEHQ3hYipcWWf9eLxAPC6p/2e89WldIZQunwdLPOdRxkK2QC7ADxHkJoEh7OqUUZ
	yDg0wbWCN6Uh51fA76dlNUmHzxD3KBYnPfTUuaGMc99WOr2WFbahi3WHq32TagBN
	B5XjYd2u3GYjMjP1oySM9eU4xPc9KPAE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id DF00B300079; 
	Thu, 12 Apr 2012 07:12:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 7b606c043208d98d218b4e08f68398073aa2b1f2
Message-Id: <7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334240171@xdev.gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Apr 2012 10:16:14 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages with
 many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 2 files changed, 169 insertions(+), 14 deletions(-)


For shared frames that have many references, the doubly-linked list used to
store the rmap results in costly scans during unshare operations. To alleviate
the overhead, replace the linked list by a hash table. However, hash tables are
space-intensive, so only use them for pages that have "many" (arbitrary
threshold) references.

Unsharing is heaviliy exercised during domain destroy. In experimental testing,
for a domain that points over 100 thousand pages to the same shared frame,
domain destruction dropped from over 7 minutes(!) to less than two seconds.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1730bff8fccf -r 7b606c043208 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -49,6 +49,17 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
+/* Reverse map defines */
+#define RMAP_HASHTAB_ORDER  0
+#define RMAP_HASHTAB_SIZE   \
+        ((PAGE_SIZE << RMAP_HASHTAB_ORDER) / sizeof(struct list_head))
+#define RMAP_USES_HASHTAB(page) \
+        ((page)->sharing->hash_table.flag == NULL)
+#define RMAP_HEAVY_SHARED_PAGE   RMAP_HASHTAB_SIZE
+/* A bit of hysteresis. We don't want to be mutating between list and hash
+ * table constantly. */
+#define RMAP_LIGHT_SHARED_PAGE   (RMAP_HEAVY_SHARED_PAGE >> 2)
+
 #if MEM_SHARING_AUDIT
 
 static struct list_head shr_audit_list;
@@ -72,6 +83,11 @@ static inline void audit_add_list(struct
 /* Removes from the audit list and cleans up the page sharing metadata. */
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
+
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
     spin_unlock(&shr_audit_lock);
@@ -89,6 +105,10 @@ int mem_sharing_audit(void)
 #define audit_add_list(p)  ((void)0)
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
     xfree(page->sharing);
 }
 
@@ -145,6 +165,11 @@ static atomic_t nr_saved_mfns   = ATOMIC
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 /** Reverse map **/
+/* Every shared frame keeps a reverse map (rmap) of <domain, gfn> tuples that
+ * this shared frame backs. For pages with a low degree of sharing, a O(n)
+ * search linked list is good enough. For pages with higher degree of sharing,
+ * we use a hash table instead. */
+
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -155,20 +180,109 @@ typedef struct gfn_info
 static inline void
 rmap_init(struct page_info *page)
 {
+    /* We always start off as a doubly linked list. */
     INIT_LIST_HEAD(&page->sharing->gfns);
 }
 
+/* Exceedingly simple "hash function" */
+#define HASH(domain, gfn)       \
+    (((gfn) + (domain)) % RMAP_HASHTAB_SIZE)
+
+/* Conversions. Tuned by the thresholds. Should only happen twice 
+ * (once each) during the lifetime of a shared page */
+static inline int
+rmap_list_to_hash_table(struct page_info *page)
+{
+    unsigned int i;
+    struct list_head *pos, *tmp, *b =
+        alloc_xenheap_pages(RMAP_HASHTAB_ORDER, 0);
+
+    if ( b == NULL )
+        return -ENOMEM;
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+        INIT_LIST_HEAD(b + i);
+
+    list_for_each_safe(pos, tmp, &page->sharing->gfns)
+    {
+        gfn_info_t *gfn_info = list_entry(pos, gfn_info_t, list);
+        struct list_head *bucket = b + HASH(gfn_info->domain, gfn_info->gfn);
+        list_del(pos);
+        list_add(pos, bucket);
+    }
+
+    page->sharing->hash_table.bucket = b;
+    page->sharing->hash_table.flag   = NULL;
+
+    return 0;
+}
+
 static inline void
-rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+rmap_hash_table_to_list(struct page_info *page)
 {
+    unsigned int i;
+    struct list_head *bucket = page->sharing->hash_table.bucket;
+
+    INIT_LIST_HEAD(&page->sharing->gfns);
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+    {
+        struct list_head *pos, *tmp, *head = bucket + i;
+        list_for_each_safe(pos, tmp, head)
+        {
+            list_del(pos);
+            list_add(pos, &page->sharing->gfns);
+        }
+    }
+
+    free_xenheap_pages(bucket, RMAP_HASHTAB_ORDER);
+}
+
+/* Generic accessors to the rmap */
+static inline unsigned long
+rmap_count(struct page_info *pg)
+{
+    unsigned long count;
+    unsigned long t = read_atomic(&pg->u.inuse.type_info);
+    count = t & PGT_count_mask;
+    if ( t & PGT_locked )
+        count--;
+    return count;
+}
+
+/* The page type count is always decreased after removing from the rmap.
+ * Use a convert flag to avoid mutating the rmap if in the middle of an 
+ * iterator, or if the page will be soon destroyed anyways. */
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page, int convert)
+{
+    if ( RMAP_USES_HASHTAB(page) && convert &&
+         (rmap_count(page) <= RMAP_LIGHT_SHARED_PAGE) )
+        rmap_hash_table_to_list(page);
+
+    /* Regardless of rmap type, same removal operation */
     list_del(&gfn_info->list);
 }
 
+/* The page type count is always increased before adding to the rmap. */
 static inline void
 rmap_add(gfn_info_t *gfn_info, struct page_info *page)
 {
+    struct list_head *head;
+
+    if ( !RMAP_USES_HASHTAB(page) &&
+         (rmap_count(page) >= RMAP_HEAVY_SHARED_PAGE) )
+        /* The conversion may fail with ENOMEM. We'll be less efficient,
+         * but no reason to panic. */
+        (void)rmap_list_to_hash_table(page);
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + 
+                            HASH(gfn_info->domain, gfn_info->gfn) :
+        &page->sharing->gfns;
+
     INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+    list_add(&gfn_info->list, head);
 }
 
 static inline gfn_info_t *
@@ -176,27 +290,33 @@ rmap_retrieve(uint16_t domain_id, unsign
                             struct page_info *page)
 {
     gfn_info_t *gfn_info;
-    struct list_head *le;
-    list_for_each(le, &page->sharing->gfns)
+    struct list_head *le, *head;
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + HASH(domain_id, gfn) :
+        &page->sharing->gfns;
+
+    list_for_each(le, head)
     {
         gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
             return gfn_info;
     }
+
+    /* Nothing was found */
     return NULL;
 }
 
 /* Returns true if the rmap has only one entry. O(1) complexity. */
 static inline int rmap_has_one_entry(struct page_info *page)
 {
-    struct list_head *head = &page->sharing->gfns;
-    return (head->next != head) && (head->next->next == head);
+    return (rmap_count(page) == 1);
 }
 
 /* Returns true if the rmap has any entries. O(1) complexity. */
 static inline int rmap_has_entries(struct page_info *page)
 {
-    return (!list_empty(&page->sharing->gfns));
+    return (rmap_count(page) != 0);
 }
 
 /* The iterator hides the details of how the rmap is implemented. This
@@ -204,20 +324,43 @@ static inline int rmap_has_entries(struc
 struct rmap_iterator {
     struct list_head *curr;
     struct list_head *next;
+    unsigned int bucket;
 };
 
 static inline void
 rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
 {
-    ri->curr = &page->sharing->gfns;
+    ri->curr = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket :
+                &page->sharing->gfns;
     ri->next = ri->curr->next; 
+    ri->bucket = 0;
 }
 
 static inline gfn_info_t *
 rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
 {
-    if ( ri->next == &page->sharing->gfns)
-        return NULL;
+    struct list_head *head = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket + ri->bucket :
+                &page->sharing->gfns;
+
+retry:
+    if ( ri->next == head)
+    {
+        if ( RMAP_USES_HASHTAB(page) )
+        {
+            ri->bucket++;
+            if ( ri->bucket >= RMAP_HASHTAB_SIZE )
+                /* No more hash table buckets */
+                return NULL;
+            head = page->sharing->hash_table.bucket + ri->bucket;
+            ri->curr = head;
+            ri->next = ri->curr->next;
+            goto retry;
+        } else
+            /* List exhausted */
+            return NULL;
+    }
 
     ri->curr = ri->next;
     ri->next = ri->curr->next;
@@ -253,7 +396,7 @@ static inline void mem_sharing_gfn_destr
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    rmap_del(gfn_info, page);
+    rmap_del(gfn_info, page, 1);
     xfree(gfn_info);
 }
 
@@ -870,8 +1013,9 @@ int mem_sharing_share_pages(struct domai
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from client list to source list */
-        rmap_del(gfn, cpage);
+        /* Move the gfn_info from client list to source list.
+         * Don't change the type of rmap for the client page. */
+        rmap_del(gfn, cpage, 0);
         rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
diff -r 1730bff8fccf -r 7b606c043208 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -30,6 +30,13 @@
 
 typedef uint64_t shr_handle_t; 
 
+typedef struct rmap_hashtab {
+    struct list_head *bucket;
+    /* Overlaps with prev pointer of list_head in union below.
+     * Unlike the prev pointer, this can be NULL. */
+    void *flag;
+} rmap_hashtab_t;
+
 struct page_sharing_info
 {
     struct page_info *pg;   /* Back pointer to the page. */
@@ -38,7 +45,11 @@ struct page_sharing_info
     struct list_head entry; /* List of all shared pages (entry). */
     struct rcu_head rcu_head; /* List of all shared pages (entry). */
 #endif
-    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+    /* Reverse map of <domain,gfn> tuples for this shared frame. */
+    union {
+        struct list_head    gfns;
+        rmap_hashtab_t      hash_table;
+    };
 };
 
 #ifdef __x86_64__

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKo9-0005u0-OS; Thu, 12 Apr 2012 14:15:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIKo8-0005tX-85
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:15:32 +0000
Received: from [85.158.138.51:15797] by server-4.bemta-3.messagelabs.com id
	86/37-15341-383E68F4; Thu, 12 Apr 2012 14:15:31 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334240130!21691007!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 12 Apr 2012 14:15:30 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 14:15:30 -0000
Received: from [84.223.50.88] (account d.faggioli@sssup.it HELO
	[192.168.1.119]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77082885; Thu, 12 Apr 2012 16:15:29 +0200
Message-ID: <1334240118.3866.1.camel@Abyss.lan>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <dunlapg@umich.edu>
Date: Thu, 12 Apr 2012 16:15:18 +0200
In-Reply-To: <CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
	<CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: zhihao wang <accept.acm@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5691538777540145147=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5691538777540145147==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-6KnqePJShaoZ/qnBjRNA"


--=-6KnqePJShaoZ/qnBjRNA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 14:28 +0100, George Dunlap wrote:=20
> > Those tools should be optional since the generated files are checked in=
.
> > However perhaps configure should detect and provide the paths but behav=
e
> > in a non-fatal manner if they aren't available? Roger, what do you
> > think?
>=20
> FWIW, I managed to get into a state where I ran into this error too;
> after a sequence of fairly random steps, it went away, and I wasn't
> able to reproduce it again. =20
>
Same here, it occurred to me last week or something like that.

> I have no idea what I did to get there in
> the first place, nor what I did to fix it.
>=20
Me neither... AFAICR (as I was on an `hg clone'-ed repo) I checked out
the original files that went missing by hand. :-(

Sorry of not being able to help more.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-6KnqePJShaoZ/qnBjRNA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+G43cACgkQk4XaBE3IOsSdNwCglwGHI84OizUJSFcujnHuCqon
UPIAnjKGcQ/FPWgD6RwwaQTtKiQ+65sa
=4HVc
-----END PGP SIGNATURE-----

--=-6KnqePJShaoZ/qnBjRNA--



--===============5691538777540145147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5691538777540145147==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 14:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKo9-0005u0-OS; Thu, 12 Apr 2012 14:15:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIKo8-0005tX-85
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:15:32 +0000
Received: from [85.158.138.51:15797] by server-4.bemta-3.messagelabs.com id
	86/37-15341-383E68F4; Thu, 12 Apr 2012 14:15:31 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334240130!21691007!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 12 Apr 2012 14:15:30 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 14:15:30 -0000
Received: from [84.223.50.88] (account d.faggioli@sssup.it HELO
	[192.168.1.119]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77082885; Thu, 12 Apr 2012 16:15:29 +0200
Message-ID: <1334240118.3866.1.camel@Abyss.lan>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <dunlapg@umich.edu>
Date: Thu, 12 Apr 2012 16:15:18 +0200
In-Reply-To: <CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
	<CAFLBxZYFPuFGAVOXJRgHvu2rqq8hL7PQFPoj_Bi26WfM_fYYRQ@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: zhihao wang <accept.acm@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5691538777540145147=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5691538777540145147==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-6KnqePJShaoZ/qnBjRNA"


--=-6KnqePJShaoZ/qnBjRNA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 14:28 +0100, George Dunlap wrote:=20
> > Those tools should be optional since the generated files are checked in=
.
> > However perhaps configure should detect and provide the paths but behav=
e
> > in a non-fatal manner if they aren't available? Roger, what do you
> > think?
>=20
> FWIW, I managed to get into a state where I ran into this error too;
> after a sequence of fairly random steps, it went away, and I wasn't
> able to reproduce it again. =20
>
Same here, it occurred to me last week or something like that.

> I have no idea what I did to get there in
> the first place, nor what I did to fix it.
>=20
Me neither... AFAICR (as I was on an `hg clone'-ed repo) I checked out
the original files that went missing by hand. :-(

Sorry of not being able to help more.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-6KnqePJShaoZ/qnBjRNA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+G43cACgkQk4XaBE3IOsSdNwCglwGHI84OizUJSFcujnHuCqon
UPIAnjKGcQ/FPWgD6RwwaQTtKiQ+65sa
=4HVc
-----END PGP SIGNATURE-----

--=-6KnqePJShaoZ/qnBjRNA--



--===============5691538777540145147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5691538777540145147==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 14:18:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKqv-0006SF-CR; Thu, 12 Apr 2012 14:18:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKqt-0006RW-7l
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:18:23 +0000
Received: from [193.109.254.147:16003] by server-2.bemta-14.messagelabs.com id
	ED/04-19409-E24E68F4; Thu, 12 Apr 2012 14:18:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334240298!4305464!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NjA5\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NjA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17941 invoked from network); 12 Apr 2012 14:18:18 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.81) by server-9.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 14:18:18 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 68401300074;
	Thu, 12 Apr 2012 07:18:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fHVaEoQB8V5O1QfisG+CPlRlZ7ZPjL4AME0vPbHb/hP1
	+sJeC6NSfISixvTKJCp8Z5syyHpkLyLELhVeqkRV7jiJ0/SSbOP+aRrkJN5sBe2T
	LrCQ20vwxTL1sTa1EXjslzHNa4UmcsCVo0IXrKcEYg42eurFJJDy5kDXuSgbbqg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=a/dpsgG/cbM0bURv8l+31fj0lPc=; b=Ott0qQAV
	2dZ2iKT6eq7nO4aH/rBZRRTHth/+LWQ9VvVu5WS+jYAz7XNVlS880OjArvZKbLsz
	lyTAkk1uYAtLq95NoZonhuRoSPZ6sePrYErFDIX1pyIoKmgB5JDWUFtAqJCpKbTj
	DBhxtXg6K/xwv3oAH911xuKj8CHMuT5aUMQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 738A5300059; 
	Thu, 12 Apr 2012 07:18:16 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 12 Apr 2012 07:18:17 -0700
Message-ID: <11cfdcc14635fc08a5fc012de2fbcc0e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120405101544.GD14774@ocelot.phlegethon.org>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
	<20120405101544.GD14774@ocelot.phlegethon.org>
Date: Thu, 12 Apr 2012 07:18:17 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, adin@gridcentric.ca,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
>> Document the sharing libxc interface, including failure conditions,
>> meaning of
>> stats, and internal semantics/behavior.
>>
>> Also remove a stale debug call.
>>
>> Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits.
>> Both
>> patches touch the tools. Patch #2 is entirely documentation comments.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Tim Deegan <tim@xen.org>

Ping? Ian & Ian?
Thanks,
Andres

>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:18:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIKqv-0006SF-CR; Thu, 12 Apr 2012 14:18:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIKqt-0006RW-7l
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:18:23 +0000
Received: from [193.109.254.147:16003] by server-2.bemta-14.messagelabs.com id
	ED/04-19409-E24E68F4; Thu, 12 Apr 2012 14:18:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334240298!4305464!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NjA5\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NjA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17941 invoked from network); 12 Apr 2012 14:18:18 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.81) by server-9.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 14:18:18 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 68401300074;
	Thu, 12 Apr 2012 07:18:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fHVaEoQB8V5O1QfisG+CPlRlZ7ZPjL4AME0vPbHb/hP1
	+sJeC6NSfISixvTKJCp8Z5syyHpkLyLELhVeqkRV7jiJ0/SSbOP+aRrkJN5sBe2T
	LrCQ20vwxTL1sTa1EXjslzHNa4UmcsCVo0IXrKcEYg42eurFJJDy5kDXuSgbbqg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=a/dpsgG/cbM0bURv8l+31fj0lPc=; b=Ott0qQAV
	2dZ2iKT6eq7nO4aH/rBZRRTHth/+LWQ9VvVu5WS+jYAz7XNVlS880OjArvZKbLsz
	lyTAkk1uYAtLq95NoZonhuRoSPZ6sePrYErFDIX1pyIoKmgB5JDWUFtAqJCpKbTj
	DBhxtXg6K/xwv3oAH911xuKj8CHMuT5aUMQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 738A5300059; 
	Thu, 12 Apr 2012 07:18:16 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 12 Apr 2012 07:18:17 -0700
Message-ID: <11cfdcc14635fc08a5fc012de2fbcc0e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120405101544.GD14774@ocelot.phlegethon.org>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
	<20120405101544.GD14774@ocelot.phlegethon.org>
Date: Thu, 12 Apr 2012 07:18:17 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, adin@gridcentric.ca,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
>> Document the sharing libxc interface, including failure conditions,
>> meaning of
>> stats, and internal semantics/behavior.
>>
>> Also remove a stale debug call.
>>
>> Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits.
>> Both
>> patches touch the tools. Patch #2 is entirely documentation comments.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Tim Deegan <tim@xen.org>

Ping? Ian & Ian?
Thanks,
Andres

>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:44:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILFb-000879-JC; Thu, 12 Apr 2012 14:43:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SILFZ-00086y-TW
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:43:54 +0000
Received: from [85.158.143.99:15521] by server-2.bemta-4.messagelabs.com id
	D5/04-17550-92AE68F4; Thu, 12 Apr 2012 14:43:53 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334241830!22810086!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15178 invoked from network); 12 Apr 2012 14:43:51 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 14:43:51 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id BD277DF901;
	Thu, 12 Apr 2012 22:43:36 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334239381.16387.106.camel@zakaz.uk.xensource.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
Date: Thu, 12 Apr 2012 22:42:53 +0800
Message-ID: <1334241773.4001.5.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
> On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
> > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > > > Hi,
> > > > 
> > > > This is just my experience about issues I encountered when upgrade
> > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > > > changeset 25191:a95fc7decc83.
> > > > 
> > > > 1. Immediately after upgrade, xl list show such error:
> > > > 
> > > > # xl list
> > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > > > Permission denied
> > > > libxl_domain_infolist failed.
> > > > 
> > > > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > > > there are running domUs... this might cause issues to shutdown?  I
> > > > will downgrade and repeat such test to confirm.  Might be worth a note
> > > > in upgrading note about this if this is intended?
> > > 
> > > The tools and the hypervisor are a matched pair so you would need to
> > > reboot the system in order to use the new tools. This has always been
> > > the case with Xen upgrades.
> > > 
> > > > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > > > work whereby setting rtc_timeoffset works.  Any idea?
> > > 
> > > I've CC'd Lin Ming who implemented both of those.
> > 
> > Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
> > was called 3 times. So below statement was executed 3 times too.
> > 
> > b_info->rtc_timeoffset += tm->tm_gmtoff;
> 
> Oh, that sounds like the problem. The setdefault functions are supposed
> to be idempotent, IOW calling it two or more times should give the same
> result as calling it just once.
> 
> I think you need to move this logic from setdefault
>     if (libxl_defbool_val(b_info->localtime)) {
>         time_t t;
>         struct tm *tm;
> 
>         t = time(NULL);
>         tm = localtime(&t);
> 
>         b_info->rtc_timeoffset += tm->tm_gmtoff;
>     }
> 
> into libxl__build_pre and do that calculation on a temporary variable
> whjich you pass to xc_domain_set_time_offset rather than modifying
> b_info.

How about below patch?

>From e06589cb5f1efd885f9589405d0f4ecc97427ad6 Mon Sep 17 00:00:00 2001
From: Lin Ming <mlin@ss.pku.edu.cn>
Date: Thu, 12 Apr 2012 22:36:24 +0800
Subject: [PATCH] libxl: fix rtc_timeoffset setting

libxl__domain_build_info_setdefault may be called several times, so
rtc_timeoffset can't be set in it.

Move rtc_timeoffset setting logic to libxl__build_pre.

Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 tools/libxl/libxl_create.c |    9 ---------
 tools/libxl/libxl_dom.c    |   17 +++++++++++++++--
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..e706124 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->target_memkb = b_info->max_memkb;
 
     libxl_defbool_setdefault(&b_info->localtime, false);
-    if (libxl_defbool_val(b_info->localtime)) {
-        time_t t;
-        struct tm *tm;
-
-        t = time(NULL);
-        tm = localtime(&t);
-
-        b_info->rtc_timeoffset += tm->tm_gmtoff;
-    }
 
     libxl_defbool_setdefault(&b_info->disable_migrate, false);
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..91c4bd8 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
     char *xs_domid, *con_domid;
+    uint32_t rtc_timeoffset;
+
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
@@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
-    if (info->rtc_timeoffset)
-        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
+    rtc_timeoffset = info->rtc_timeoffset;
+    if (libxl_defbool_val(info->localtime)) {
+        time_t t;
+        struct tm *tm;
+
+        t = time(NULL);
+        tm = localtime(&t);
+
+        rtc_timeoffset += tm->tm_gmtoff;
+    }
+
+    if (rtc_timeoffset)
+        xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffset);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         unsigned long shadow;
-- 
1.7.2.5



> 
> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:44:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILFb-000879-JC; Thu, 12 Apr 2012 14:43:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SILFZ-00086y-TW
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:43:54 +0000
Received: from [85.158.143.99:15521] by server-2.bemta-4.messagelabs.com id
	D5/04-17550-92AE68F4; Thu, 12 Apr 2012 14:43:53 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334241830!22810086!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15178 invoked from network); 12 Apr 2012 14:43:51 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 14:43:51 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id BD277DF901;
	Thu, 12 Apr 2012 22:43:36 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334239381.16387.106.camel@zakaz.uk.xensource.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
Date: Thu, 12 Apr 2012 22:42:53 +0800
Message-ID: <1334241773.4001.5.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
> On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
> > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > > > Hi,
> > > > 
> > > > This is just my experience about issues I encountered when upgrade
> > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > > > changeset 25191:a95fc7decc83.
> > > > 
> > > > 1. Immediately after upgrade, xl list show such error:
> > > > 
> > > > # xl list
> > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > > > Permission denied
> > > > libxl_domain_infolist failed.
> > > > 
> > > > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > > > there are running domUs... this might cause issues to shutdown?  I
> > > > will downgrade and repeat such test to confirm.  Might be worth a note
> > > > in upgrading note about this if this is intended?
> > > 
> > > The tools and the hypervisor are a matched pair so you would need to
> > > reboot the system in order to use the new tools. This has always been
> > > the case with Xen upgrades.
> > > 
> > > > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > > > work whereby setting rtc_timeoffset works.  Any idea?
> > > 
> > > I've CC'd Lin Ming who implemented both of those.
> > 
> > Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
> > was called 3 times. So below statement was executed 3 times too.
> > 
> > b_info->rtc_timeoffset += tm->tm_gmtoff;
> 
> Oh, that sounds like the problem. The setdefault functions are supposed
> to be idempotent, IOW calling it two or more times should give the same
> result as calling it just once.
> 
> I think you need to move this logic from setdefault
>     if (libxl_defbool_val(b_info->localtime)) {
>         time_t t;
>         struct tm *tm;
> 
>         t = time(NULL);
>         tm = localtime(&t);
> 
>         b_info->rtc_timeoffset += tm->tm_gmtoff;
>     }
> 
> into libxl__build_pre and do that calculation on a temporary variable
> whjich you pass to xc_domain_set_time_offset rather than modifying
> b_info.

How about below patch?

>From e06589cb5f1efd885f9589405d0f4ecc97427ad6 Mon Sep 17 00:00:00 2001
From: Lin Ming <mlin@ss.pku.edu.cn>
Date: Thu, 12 Apr 2012 22:36:24 +0800
Subject: [PATCH] libxl: fix rtc_timeoffset setting

libxl__domain_build_info_setdefault may be called several times, so
rtc_timeoffset can't be set in it.

Move rtc_timeoffset setting logic to libxl__build_pre.

Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 tools/libxl/libxl_create.c |    9 ---------
 tools/libxl/libxl_dom.c    |   17 +++++++++++++++--
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..e706124 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->target_memkb = b_info->max_memkb;
 
     libxl_defbool_setdefault(&b_info->localtime, false);
-    if (libxl_defbool_val(b_info->localtime)) {
-        time_t t;
-        struct tm *tm;
-
-        t = time(NULL);
-        tm = localtime(&t);
-
-        b_info->rtc_timeoffset += tm->tm_gmtoff;
-    }
 
     libxl_defbool_setdefault(&b_info->disable_migrate, false);
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..91c4bd8 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
     char *xs_domid, *con_domid;
+    uint32_t rtc_timeoffset;
+
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
@@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
-    if (info->rtc_timeoffset)
-        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
+    rtc_timeoffset = info->rtc_timeoffset;
+    if (libxl_defbool_val(info->localtime)) {
+        time_t t;
+        struct tm *tm;
+
+        t = time(NULL);
+        tm = localtime(&t);
+
+        rtc_timeoffset += tm->tm_gmtoff;
+    }
+
+    if (rtc_timeoffset)
+        xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffset);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         unsigned long shadow;
-- 
1.7.2.5



> 
> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:46:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILIG-0008IK-8u; Thu, 12 Apr 2012 14:46:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1SILIC-0008I7-Je
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:46:38 +0000
Received: from [85.158.143.99:47392] by server-1.bemta-4.messagelabs.com id
	CF/60-20925-BCAE68F4; Thu, 12 Apr 2012 14:46:35 +0000
X-Env-Sender: wang_nets@163.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334241993!22810316!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20869 invoked from network); 12 Apr 2012 14:46:35 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Apr 2012 14:46:35 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1SILI9-0005iV-04
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:46:33 -0700
Date: Thu, 12 Apr 2012 07:46:32 -0700 (PDT)
From: SuperWong <wang_nets@163.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334241992994-5635895.post@n5.nabble.com>
In-Reply-To: <CAFLBxZa7fha+Hh2v7gY0Cgn8eGmnKhWQ2TCdBtp8wSb8v4kOCg@mail.gmail.com>
References: <1333199711583-5608788.post@n5.nabble.com>
	<CAFLBxZa7fha+Hh2v7gY0Cgn8eGmnKhWQ2TCdBtp8wSb8v4kOCg@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] I have used printk in some hypercall.But Dom0 can't
	be booted.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ckdlb3JnZSBEdW5sYXAtNCB3cm90ZQo+IAo+IE9uIFNhdCwgTWFyIDMxLCAyMDEyIGF0IDI6MTUg
UE0sIFN1cGVyV29uZyAmbHQ7d2FuZ19uZXRzQCZndDsgd3JvdGU6Cj4+IEhpIGFsbDoKPj4gwqAg
wqBJIHdhbnRlZCB0byByZWNvcmQgc29tZSBpbmZvcm1hdGlvbiBhYm91dCBzb21lIGh5cGVyY2Fs
bHMgYW5kIHRyYWNlCj4+IHRoZQo+PiBoeXBlcmNhbGxzLlNvIEkgaGF2ZSB0cmllZCB0byBhZGQg
cHJpbnRrIGluIHRoZSBoeXBlcmNhbGwuQnV0IHRoZSBEb20wCj4+IGNhbid0Cj4+IGJlICpib290
ZWQqLkZvciBleGFtcGxlLCBJIGFkZCBwcmludGsgYXQgdGhlIGJlZ2lubmluZyBvZgo+PiBkb19z
ZXRfdHJhcF90YWJsZS4KPj4gcHJpbnRrKCI8MT4iIkhZUEVSQ0FMTDpkb19zZXRfdHJhcF90YWJs
ZSIpOwo+PiBXaHkgSSBjYW4ndCBhZGQgcHJpbnRrIGluIGh5cGVyY2FsbD8KPj4gRG9lcyBhbnlv
bmUga25vdyB0aGUgcmVhc29uIGFuZCB0aGUgc29sdXRpb24/VGhhbmtzLgo+IAo+IFRoZXJlJ3Mg
bm8gd2F5IHdlIGNhbiBhbnN3ZXIgdGhpcyBxdWVzdGlvbiB3aXRob3V0IHRoZSBvdXRwdXQgb2Yg
dGhlCj4gZG9tMCBzYXlpbmcgd2h5IGl0IGZhaWxlZC4KPiAKPiBUaGUgYmVzdCB3YXkgdG8gZG8g
dGhpcyBpcyB0byBzZXQgdXAgYSBzZXJpYWwgY29uc29sZToKPiAgaHR0cDovL3dpa2kueGVuLm9y
Zy93aWtpL1hlbl9TZXJpYWxfQ29uc29sZQo+IAo+ICAtR2VvcmdlCj4gCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Cj4gWGVuLWRldmVsQC54ZW4KPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAK
VGhhbmtzIHNvIG11Y2guSSBoYXZlIHNldCB1cCBhIHNlcmlhbCBjb25zb2xlLlRoZW4sSSBmb3Vu
ZCB0aGVyZSB3ZXJlIGZ1bGwKb2YgbXkgcHJpbnRrIG91dHB1dC5JdCdzIGxpa2VseSB0aGF0IHdy
aXRpbmcgYSBwcmludGsgaW4gYSBoeXBlcmNhbGwgaXNuJ3QKZmVhc2libGUuSSB3YW50IHRvIHJl
Y29yZCB3aGljaCBoeXBlcmNhbGwgaXMgaXNzdWVkIHdoZW4gSSBpbnB1dCBpbnNtb2QuSG93CnNo
b3VsZCBJIGRvIGl0PwoKLS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hl
bi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vSS1oYXZlLXVzZWQtcHJpbnRrLWluLXNvbWUtaHlwZXJj
YWxsLUJ1dC1Eb20wLWNhbi10LWJlLWJvb3RlZC10cDU2MDg3ODhwNTYzNTg5NS5odG1sClNlbnQg
ZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:46:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILIG-0008IK-8u; Thu, 12 Apr 2012 14:46:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1SILIC-0008I7-Je
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:46:38 +0000
Received: from [85.158.143.99:47392] by server-1.bemta-4.messagelabs.com id
	CF/60-20925-BCAE68F4; Thu, 12 Apr 2012 14:46:35 +0000
X-Env-Sender: wang_nets@163.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334241993!22810316!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20869 invoked from network); 12 Apr 2012 14:46:35 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Apr 2012 14:46:35 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1SILI9-0005iV-04
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 07:46:33 -0700
Date: Thu, 12 Apr 2012 07:46:32 -0700 (PDT)
From: SuperWong <wang_nets@163.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334241992994-5635895.post@n5.nabble.com>
In-Reply-To: <CAFLBxZa7fha+Hh2v7gY0Cgn8eGmnKhWQ2TCdBtp8wSb8v4kOCg@mail.gmail.com>
References: <1333199711583-5608788.post@n5.nabble.com>
	<CAFLBxZa7fha+Hh2v7gY0Cgn8eGmnKhWQ2TCdBtp8wSb8v4kOCg@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] I have used printk in some hypercall.But Dom0 can't
	be booted.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ckdlb3JnZSBEdW5sYXAtNCB3cm90ZQo+IAo+IE9uIFNhdCwgTWFyIDMxLCAyMDEyIGF0IDI6MTUg
UE0sIFN1cGVyV29uZyAmbHQ7d2FuZ19uZXRzQCZndDsgd3JvdGU6Cj4+IEhpIGFsbDoKPj4gwqAg
wqBJIHdhbnRlZCB0byByZWNvcmQgc29tZSBpbmZvcm1hdGlvbiBhYm91dCBzb21lIGh5cGVyY2Fs
bHMgYW5kIHRyYWNlCj4+IHRoZQo+PiBoeXBlcmNhbGxzLlNvIEkgaGF2ZSB0cmllZCB0byBhZGQg
cHJpbnRrIGluIHRoZSBoeXBlcmNhbGwuQnV0IHRoZSBEb20wCj4+IGNhbid0Cj4+IGJlICpib290
ZWQqLkZvciBleGFtcGxlLCBJIGFkZCBwcmludGsgYXQgdGhlIGJlZ2lubmluZyBvZgo+PiBkb19z
ZXRfdHJhcF90YWJsZS4KPj4gcHJpbnRrKCI8MT4iIkhZUEVSQ0FMTDpkb19zZXRfdHJhcF90YWJs
ZSIpOwo+PiBXaHkgSSBjYW4ndCBhZGQgcHJpbnRrIGluIGh5cGVyY2FsbD8KPj4gRG9lcyBhbnlv
bmUga25vdyB0aGUgcmVhc29uIGFuZCB0aGUgc29sdXRpb24/VGhhbmtzLgo+IAo+IFRoZXJlJ3Mg
bm8gd2F5IHdlIGNhbiBhbnN3ZXIgdGhpcyBxdWVzdGlvbiB3aXRob3V0IHRoZSBvdXRwdXQgb2Yg
dGhlCj4gZG9tMCBzYXlpbmcgd2h5IGl0IGZhaWxlZC4KPiAKPiBUaGUgYmVzdCB3YXkgdG8gZG8g
dGhpcyBpcyB0byBzZXQgdXAgYSBzZXJpYWwgY29uc29sZToKPiAgaHR0cDovL3dpa2kueGVuLm9y
Zy93aWtpL1hlbl9TZXJpYWxfQ29uc29sZQo+IAo+ICAtR2VvcmdlCj4gCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Cj4gWGVuLWRldmVsQC54ZW4KPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAK
VGhhbmtzIHNvIG11Y2guSSBoYXZlIHNldCB1cCBhIHNlcmlhbCBjb25zb2xlLlRoZW4sSSBmb3Vu
ZCB0aGVyZSB3ZXJlIGZ1bGwKb2YgbXkgcHJpbnRrIG91dHB1dC5JdCdzIGxpa2VseSB0aGF0IHdy
aXRpbmcgYSBwcmludGsgaW4gYSBoeXBlcmNhbGwgaXNuJ3QKZmVhc2libGUuSSB3YW50IHRvIHJl
Y29yZCB3aGljaCBoeXBlcmNhbGwgaXMgaXNzdWVkIHdoZW4gSSBpbnB1dCBpbnNtb2QuSG93CnNo
b3VsZCBJIGRvIGl0PwoKLS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hl
bi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vSS1oYXZlLXVzZWQtcHJpbnRrLWluLXNvbWUtaHlwZXJj
YWxsLUJ1dC1Eb20wLWNhbi10LWJlLWJvb3RlZC10cDU2MDg3ODhwNTYzNTg5NS5odG1sClNlbnQg
ZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:51:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILMm-00008b-VB; Thu, 12 Apr 2012 14:51:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SILMl-00008U-MM
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:51:19 +0000
Received: from [193.109.254.147:35297] by server-3.bemta-14.messagelabs.com id
	C1/A0-23274-6EBE68F4; Thu, 12 Apr 2012 14:51:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334242277!1216622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9832 invoked from network); 12 Apr 2012 14:51:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:51:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11906831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:50:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:50:53 +0100
Message-ID: <1334242251.16387.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 15:50:51 +0100
In-Reply-To: <1334241773.4001.5.camel@hp6530s>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
	<1334241773.4001.5.camel@hp6530s>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 15:42 +0100, Lin Ming wrote:
> On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
> > On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
> > > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> > > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > > > > Hi,
> > > > > 
> > > > > This is just my experience about issues I encountered when upgrade
> > > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > > > > changeset 25191:a95fc7decc83.
> > > > > 
> > > > > 1. Immediately after upgrade, xl list show such error:
> > > > > 
> > > > > # xl list
> > > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > > > > Permission denied
> > > > > libxl_domain_infolist failed.
> > > > > 
> > > > > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > > > > there are running domUs... this might cause issues to shutdown?  I
> > > > > will downgrade and repeat such test to confirm.  Might be worth a note
> > > > > in upgrading note about this if this is intended?
> > > > 
> > > > The tools and the hypervisor are a matched pair so you would need to
> > > > reboot the system in order to use the new tools. This has always been
> > > > the case with Xen upgrades.
> > > > 
> > > > > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > > > > work whereby setting rtc_timeoffset works.  Any idea?
> > > > 
> > > > I've CC'd Lin Ming who implemented both of those.
> > > 
> > > Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
> > > was called 3 times. So below statement was executed 3 times too.
> > > 
> > > b_info->rtc_timeoffset += tm->tm_gmtoff;
> > 
> > Oh, that sounds like the problem. The setdefault functions are supposed
> > to be idempotent, IOW calling it two or more times should give the same
> > result as calling it just once.
> > 
> > I think you need to move this logic from setdefault
> >     if (libxl_defbool_val(b_info->localtime)) {
> >         time_t t;
> >         struct tm *tm;
> > 
> >         t = time(NULL);
> >         tm = localtime(&t);
> > 
> >         b_info->rtc_timeoffset += tm->tm_gmtoff;
> >     }
> > 
> > into libxl__build_pre and do that calculation on a temporary variable
> > whjich you pass to xc_domain_set_time_offset rather than modifying
> > b_info.
> 
> How about below patch?
> 
> From e06589cb5f1efd885f9589405d0f4ecc97427ad6 Mon Sep 17 00:00:00 2001
> From: Lin Ming <mlin@ss.pku.edu.cn>
> Date: Thu, 12 Apr 2012 22:36:24 +0800
> Subject: [PATCH] libxl: fix rtc_timeoffset setting
> 
> libxl__domain_build_info_setdefault may be called several times, so
> rtc_timeoffset can't be set in it.
> 
> Move rtc_timeoffset setting logic to libxl__build_pre.
> 
> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>

Looks good to me.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_create.c |    9 ---------
>  tools/libxl/libxl_dom.c    |   17 +++++++++++++++--
>  2 files changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..e706124 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>          b_info->target_memkb = b_info->max_memkb;
>  
>      libxl_defbool_setdefault(&b_info->localtime, false);
> -    if (libxl_defbool_val(b_info->localtime)) {
> -        time_t t;
> -        struct tm *tm;
> -
> -        t = time(NULL);
> -        tm = localtime(&t);
> -
> -        b_info->rtc_timeoffset += tm->tm_gmtoff;
> -    }
>  
>      libxl_defbool_setdefault(&b_info->disable_migrate, false);
>  
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..91c4bd8 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
>      char *xs_domid, *con_domid;
> +    uint32_t rtc_timeoffset;
> +
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
> @@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>      if (libxl_defbool_val(info->disable_migrate))
>          xc_domain_disable_migrate(ctx->xch, domid);
>  
> -    if (info->rtc_timeoffset)
> -        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
> +    rtc_timeoffset = info->rtc_timeoffset;
> +    if (libxl_defbool_val(info->localtime)) {
> +        time_t t;
> +        struct tm *tm;
> +
> +        t = time(NULL);
> +        tm = localtime(&t);
> +
> +        rtc_timeoffset += tm->tm_gmtoff;
> +    }
> +
> +    if (rtc_timeoffset)
> +        xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffset);
>  
>      if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          unsigned long shadow;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 14:51:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 14:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILMm-00008b-VB; Thu, 12 Apr 2012 14:51:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SILMl-00008U-MM
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 14:51:19 +0000
Received: from [193.109.254.147:35297] by server-3.bemta-14.messagelabs.com id
	C1/A0-23274-6EBE68F4; Thu, 12 Apr 2012 14:51:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334242277!1216622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9832 invoked from network); 12 Apr 2012 14:51:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:51:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11906831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:50:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:50:53 +0100
Message-ID: <1334242251.16387.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 15:50:51 +0100
In-Reply-To: <1334241773.4001.5.camel@hp6530s>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
	<1334241773.4001.5.camel@hp6530s>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 15:42 +0100, Lin Ming wrote:
> On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
> > On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
> > > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
> > > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
> > > > > Hi,
> > > > > 
> > > > > This is just my experience about issues I encountered when upgrade
> > > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
> > > > > changeset 25191:a95fc7decc83.
> > > > > 
> > > > > 1. Immediately after upgrade, xl list show such error:
> > > > > 
> > > > > # xl list
> > > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info list:
> > > > > Permission denied
> > > > > libxl_domain_infolist failed.
> > > > > 
> > > > > After a reboot, it is fine.  Any idea why such behaviour?  Imagine if
> > > > > there are running domUs... this might cause issues to shutdown?  I
> > > > > will downgrade and repeat such test to confirm.  Might be worth a note
> > > > > in upgrading note about this if this is intended?
> > > > 
> > > > The tools and the hypervisor are a matched pair so you would need to
> > > > reboot the system in order to use the new tools. This has always been
> > > > the case with Xen upgrades.
> > > > 
> > > > > 2. localtime setting not working.  Set to localtime=1 doesn't seems to
> > > > > work whereby setting rtc_timeoffset works.  Any idea?
> > > > 
> > > > I've CC'd Lin Ming who implemented both of those.
> > > 
> > > Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
> > > was called 3 times. So below statement was executed 3 times too.
> > > 
> > > b_info->rtc_timeoffset += tm->tm_gmtoff;
> > 
> > Oh, that sounds like the problem. The setdefault functions are supposed
> > to be idempotent, IOW calling it two or more times should give the same
> > result as calling it just once.
> > 
> > I think you need to move this logic from setdefault
> >     if (libxl_defbool_val(b_info->localtime)) {
> >         time_t t;
> >         struct tm *tm;
> > 
> >         t = time(NULL);
> >         tm = localtime(&t);
> > 
> >         b_info->rtc_timeoffset += tm->tm_gmtoff;
> >     }
> > 
> > into libxl__build_pre and do that calculation on a temporary variable
> > whjich you pass to xc_domain_set_time_offset rather than modifying
> > b_info.
> 
> How about below patch?
> 
> From e06589cb5f1efd885f9589405d0f4ecc97427ad6 Mon Sep 17 00:00:00 2001
> From: Lin Ming <mlin@ss.pku.edu.cn>
> Date: Thu, 12 Apr 2012 22:36:24 +0800
> Subject: [PATCH] libxl: fix rtc_timeoffset setting
> 
> libxl__domain_build_info_setdefault may be called several times, so
> rtc_timeoffset can't be set in it.
> 
> Move rtc_timeoffset setting logic to libxl__build_pre.
> 
> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>

Looks good to me.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_create.c |    9 ---------
>  tools/libxl/libxl_dom.c    |   17 +++++++++++++++--
>  2 files changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..e706124 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>          b_info->target_memkb = b_info->max_memkb;
>  
>      libxl_defbool_setdefault(&b_info->localtime, false);
> -    if (libxl_defbool_val(b_info->localtime)) {
> -        time_t t;
> -        struct tm *tm;
> -
> -        t = time(NULL);
> -        tm = localtime(&t);
> -
> -        b_info->rtc_timeoffset += tm->tm_gmtoff;
> -    }
>  
>      libxl_defbool_setdefault(&b_info->disable_migrate, false);
>  
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..91c4bd8 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
>      char *xs_domid, *con_domid;
> +    uint32_t rtc_timeoffset;
> +
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
> @@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>      if (libxl_defbool_val(info->disable_migrate))
>          xc_domain_disable_migrate(ctx->xch, domid);
>  
> -    if (info->rtc_timeoffset)
> -        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
> +    rtc_timeoffset = info->rtc_timeoffset;
> +    if (libxl_defbool_val(info->localtime)) {
> +        time_t t;
> +        struct tm *tm;
> +
> +        t = time(NULL);
> +        tm = localtime(&t);
> +
> +        rtc_timeoffset += tm->tm_gmtoff;
> +    }
> +
> +    if (rtc_timeoffset)
> +        xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffset);
>  
>      if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          unsigned long shadow;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 15:00:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 15:00:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILVA-0000SD-Jb; Thu, 12 Apr 2012 15:00:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SILV8-0000Ry-JR
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:59:58 +0000
Received: from [85.158.143.35:64177] by server-2.bemta-4.messagelabs.com id
	AB/9C-17550-DEDE68F4; Thu, 12 Apr 2012 14:59:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334242797!12156429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8855 invoked from network); 12 Apr 2012 14:59:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11907086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:59:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:59:56 +0100
Message-ID: <1334242794.16387.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 15:59:54 +0100
In-Reply-To: <20358.45734.708851.953377@mariner.uk.xensource.com>
References: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
	<20358.45734.708851.953377@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 11:47 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
> > I am keen on having these three patches in 4.1.3:
> > http://marc.info/?l=xen-devel&m=133251438030441
> > 
> > I asked Ian to backport them in a previous email.
> 
> Right.
> 
> The first step in making a stable branch release should be to send a
> message to xen-devel asking for people to resend any outstanding
> backport requests, and setting a deadline for responses.

Shall we say a deadline of a week tomorrow (Friday 20th)?

Does this thread suffice as the request?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 15:00:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 15:00:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILVA-0000SD-Jb; Thu, 12 Apr 2012 15:00:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SILV8-0000Ry-JR
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 14:59:58 +0000
Received: from [85.158.143.35:64177] by server-2.bemta-4.messagelabs.com id
	AB/9C-17550-DEDE68F4; Thu, 12 Apr 2012 14:59:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334242797!12156429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8855 invoked from network); 12 Apr 2012 14:59:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 14:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11907086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 14:59:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 15:59:56 +0100
Message-ID: <1334242794.16387.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 15:59:54 +0100
In-Reply-To: <20358.45734.708851.953377@mariner.uk.xensource.com>
References: <1334164032.16387.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204111947550.15151@kaball-desktop>
	<20358.45734.708851.953377@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 11:47 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
> > I am keen on having these three patches in 4.1.3:
> > http://marc.info/?l=xen-devel&m=133251438030441
> > 
> > I asked Ian to backport them in a previous email.
> 
> Right.
> 
> The first step in making a stable branch release should be to send a
> message to xen-devel asking for people to resend any outstanding
> backport requests, and setting a deadline for responses.

Shall we say a deadline of a week tomorrow (Friday 20th)?

Does this thread suffice as the request?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 15:25:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 15:25:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILts-00016t-RM; Thu, 12 Apr 2012 15:25:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SILtr-00016o-KI
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 15:25:31 +0000
Received: from [193.109.254.147:17494] by server-12.bemta-14.messagelabs.com
	id B5/1A-05898-AE3F68F4; Thu, 12 Apr 2012 15:25:30 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334244319!4307386!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8378 invoked from network); 12 Apr 2012 15:25:20 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 15:25:20 -0000
Received: by dadp12 with SMTP id p12so3258312dad.7
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 08:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Zm7xUsfZjvlW4DrkIFRX7vOpvnTvrYT2gYHl9aW3RzE=;
	b=zH/wjnm24VhdK33ZR9ubHbrkGC5auciHE/usinObtBP1c764ehcPL1uQRZGFEvASQb
	S/lRBjXvWygGfyCsdZ6IpY29uyI35Hx22l9G0v0KjVeHSyH+bERK4HZR9/yHX+TPjsCb
	T6SZbqFT8x51eWe2V4+9MUreT7fa/MqoFYJtjzzQLNOMeuCUcHuiKgk4OeBKGXT2/6QY
	iIe0gjatCmDAfRWtOKRvfL1wDuEPlF6zC9GeoySwil3G9KU4e7Qagt4C6ZlDacxGjilk
	dTJG4oI3IzW4cngknvOSGOzXBChwPp/im4OXG65uiZvIzq57uEMqt5CLQP8NZzYRwqUt
	4/PA==
MIME-Version: 1.0
Received: by 10.68.225.195 with SMTP id rm3mr3474938pbc.96.1334244318607; Thu,
	12 Apr 2012 08:25:18 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Thu, 12 Apr 2012 08:25:18 -0700 (PDT)
In-Reply-To: <1334242251.16387.119.camel@zakaz.uk.xensource.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
	<1334241773.4001.5.camel@hp6530s>
	<1334242251.16387.119.camel@zakaz.uk.xensource.com>
Date: Thu, 12 Apr 2012 23:25:18 +0800
Message-ID: <CAEwRVpO7f5yLpZkWQiTh68tAQ9OL4Qo24otBdvjPBfPMFe29Yg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 10:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Thu, 2012-04-12 at 15:42 +0100, Lin Ming wrote:
>> On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
>> > On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
>> > > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
>> > > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
>> > > > > Hi,
>> > > > >
>> > > > > This is just my experience about issues I encountered when upgra=
de
>> > > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
>> > > > > changeset 25191:a95fc7decc83.
>> > > > >
>> > > > > 1. Immediately after upgrade, xl list show such error:
>> > > > >
>> > > > > # xl list
>> > > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info =
list:
>> > > > > Permission denied
>> > > > > libxl_domain_infolist failed.
>> > > > >
>> > > > > After a reboot, it is fine. =A0Any idea why such behaviour? =A0I=
magine if
>> > > > > there are running domUs... this might cause issues to shutdown? =
=A0I
>> > > > > will downgrade and repeat such test to confirm. =A0Might be wort=
h a note
>> > > > > in upgrading note about this if this is intended?
>> > > >
>> > > > The tools and the hypervisor are a matched pair so you would need =
to
>> > > > reboot the system in order to use the new tools. This has always b=
een
>> > > > the case with Xen upgrades.
>> > > >
>> > > > > 2. localtime setting not working. =A0Set to localtime=3D1 doesn'=
t seems to
>> > > > > work whereby setting rtc_timeoffset works. =A0Any idea?
>> > > >
>> > > > I've CC'd Lin Ming who implemented both of those.
>> > >
>> > > Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
>> > > was called 3 times. So below statement was executed 3 times too.
>> > >
>> > > b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>> >
>> > Oh, that sounds like the problem. The setdefault functions are supposed
>> > to be idempotent, IOW calling it two or more times should give the same
>> > result as calling it just once.
>> >
>> > I think you need to move this logic from setdefault
>> > =A0 =A0 if (libxl_defbool_val(b_info->localtime)) {
>> > =A0 =A0 =A0 =A0 time_t t;
>> > =A0 =A0 =A0 =A0 struct tm *tm;
>> >
>> > =A0 =A0 =A0 =A0 t =3D time(NULL);
>> > =A0 =A0 =A0 =A0 tm =3D localtime(&t);
>> >
>> > =A0 =A0 =A0 =A0 b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>> > =A0 =A0 }
>> >
>> > into libxl__build_pre and do that calculation on a temporary variable
>> > whjich you pass to xc_domain_set_time_offset rather than modifying
>> > b_info.
>>
>> How about below patch?

I am currently compiling xen-unstable changeset 25193:c6bde42c8845
with this patch.  Will test then report back.

Thanks.

Kindest regards,
Giam Teck Choon

>>
>> From e06589cb5f1efd885f9589405d0f4ecc97427ad6 Mon Sep 17 00:00:00 2001
>> From: Lin Ming <mlin@ss.pku.edu.cn>
>> Date: Thu, 12 Apr 2012 22:36:24 +0800
>> Subject: [PATCH] libxl: fix rtc_timeoffset setting
>>
>> libxl__domain_build_info_setdefault may be called several times, so
>> rtc_timeoffset can't be set in it.
>>
>> Move rtc_timeoffset setting logic to libxl__build_pre.
>>
>> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
>> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>
> Looks good to me.
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
>> ---
>> =A0tools/libxl/libxl_create.c | =A0 =A09 ---------
>> =A0tools/libxl/libxl_dom.c =A0 =A0| =A0 17 +++++++++++++++--
>> =A02 files changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index e63c7bd..e706124 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *=
gc,
>> =A0 =A0 =A0 =A0 =A0b_info->target_memkb =3D b_info->max_memkb;
>>
>> =A0 =A0 =A0libxl_defbool_setdefault(&b_info->localtime, false);
>> - =A0 =A0if (libxl_defbool_val(b_info->localtime)) {
>> - =A0 =A0 =A0 =A0time_t t;
>> - =A0 =A0 =A0 =A0struct tm *tm;
>> -
>> - =A0 =A0 =A0 =A0t =3D time(NULL);
>> - =A0 =A0 =A0 =A0tm =3D localtime(&t);
>> -
>> - =A0 =A0 =A0 =A0b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>> - =A0 =A0}
>>
>> =A0 =A0 =A0libxl_defbool_setdefault(&b_info->disable_migrate, false);
>>
>> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> index 0bdd654..91c4bd8 100644
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
>> @@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>> =A0 =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);
>> =A0 =A0 =A0int tsc_mode;
>> =A0 =A0 =A0char *xs_domid, *con_domid;
>> + =A0 =A0uint32_t rtc_timeoffset;
>> +
>> =A0 =A0 =A0xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>> =A0 =A0 =A0libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info=
->cpumap);
>> =A0 =A0 =A0xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIB=
XL_MAXMEM_CONSTANT);
>> @@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>> =A0 =A0 =A0if (libxl_defbool_val(info->disable_migrate))
>> =A0 =A0 =A0 =A0 =A0xc_domain_disable_migrate(ctx->xch, domid);
>>
>> - =A0 =A0if (info->rtc_timeoffset)
>> - =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, info->rtc_ti=
meoffset);
>> + =A0 =A0rtc_timeoffset =3D info->rtc_timeoffset;
>> + =A0 =A0if (libxl_defbool_val(info->localtime)) {
>> + =A0 =A0 =A0 =A0time_t t;
>> + =A0 =A0 =A0 =A0struct tm *tm;
>> +
>> + =A0 =A0 =A0 =A0t =3D time(NULL);
>> + =A0 =A0 =A0 =A0tm =3D localtime(&t);
>> +
>> + =A0 =A0 =A0 =A0rtc_timeoffset +=3D tm->tm_gmtoff;
>> + =A0 =A0}
>> +
>> + =A0 =A0if (rtc_timeoffset)
>> + =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffs=
et);
>>
>> =A0 =A0 =A0if (info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> =A0 =A0 =A0 =A0 =A0unsigned long shadow;
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 15:25:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 15:25:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SILts-00016t-RM; Thu, 12 Apr 2012 15:25:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SILtr-00016o-KI
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 15:25:31 +0000
Received: from [193.109.254.147:17494] by server-12.bemta-14.messagelabs.com
	id B5/1A-05898-AE3F68F4; Thu, 12 Apr 2012 15:25:30 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334244319!4307386!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8378 invoked from network); 12 Apr 2012 15:25:20 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 15:25:20 -0000
Received: by dadp12 with SMTP id p12so3258312dad.7
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 08:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Zm7xUsfZjvlW4DrkIFRX7vOpvnTvrYT2gYHl9aW3RzE=;
	b=zH/wjnm24VhdK33ZR9ubHbrkGC5auciHE/usinObtBP1c764ehcPL1uQRZGFEvASQb
	S/lRBjXvWygGfyCsdZ6IpY29uyI35Hx22l9G0v0KjVeHSyH+bERK4HZR9/yHX+TPjsCb
	T6SZbqFT8x51eWe2V4+9MUreT7fa/MqoFYJtjzzQLNOMeuCUcHuiKgk4OeBKGXT2/6QY
	iIe0gjatCmDAfRWtOKRvfL1wDuEPlF6zC9GeoySwil3G9KU4e7Qagt4C6ZlDacxGjilk
	dTJG4oI3IzW4cngknvOSGOzXBChwPp/im4OXG65uiZvIzq57uEMqt5CLQP8NZzYRwqUt
	4/PA==
MIME-Version: 1.0
Received: by 10.68.225.195 with SMTP id rm3mr3474938pbc.96.1334244318607; Thu,
	12 Apr 2012 08:25:18 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Thu, 12 Apr 2012 08:25:18 -0700 (PDT)
In-Reply-To: <1334242251.16387.119.camel@zakaz.uk.xensource.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
	<1334241773.4001.5.camel@hp6530s>
	<1334242251.16387.119.camel@zakaz.uk.xensource.com>
Date: Thu, 12 Apr 2012 23:25:18 +0800
Message-ID: <CAEwRVpO7f5yLpZkWQiTh68tAQ9OL4Qo24otBdvjPBfPMFe29Yg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 10:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Thu, 2012-04-12 at 15:42 +0100, Lin Ming wrote:
>> On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
>> > On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
>> > > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
>> > > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
>> > > > > Hi,
>> > > > >
>> > > > > This is just my experience about issues I encountered when upgra=
de
>> > > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstable
>> > > > > changeset 25191:a95fc7decc83.
>> > > > >
>> > > > > 1. Immediately after upgrade, xl list show such error:
>> > > > >
>> > > > > # xl list
>> > > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info =
list:
>> > > > > Permission denied
>> > > > > libxl_domain_infolist failed.
>> > > > >
>> > > > > After a reboot, it is fine. =A0Any idea why such behaviour? =A0I=
magine if
>> > > > > there are running domUs... this might cause issues to shutdown? =
=A0I
>> > > > > will downgrade and repeat such test to confirm. =A0Might be wort=
h a note
>> > > > > in upgrading note about this if this is intended?
>> > > >
>> > > > The tools and the hypervisor are a matched pair so you would need =
to
>> > > > reboot the system in order to use the new tools. This has always b=
een
>> > > > the case with Xen upgrades.
>> > > >
>> > > > > 2. localtime setting not working. =A0Set to localtime=3D1 doesn'=
t seems to
>> > > > > work whereby setting rtc_timeoffset works. =A0Any idea?
>> > > >
>> > > > I've CC'd Lin Ming who implemented both of those.
>> > >
>> > > Just did a quick gdb debug, seems libxl__domain_build_info_setdefault
>> > > was called 3 times. So below statement was executed 3 times too.
>> > >
>> > > b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>> >
>> > Oh, that sounds like the problem. The setdefault functions are supposed
>> > to be idempotent, IOW calling it two or more times should give the same
>> > result as calling it just once.
>> >
>> > I think you need to move this logic from setdefault
>> > =A0 =A0 if (libxl_defbool_val(b_info->localtime)) {
>> > =A0 =A0 =A0 =A0 time_t t;
>> > =A0 =A0 =A0 =A0 struct tm *tm;
>> >
>> > =A0 =A0 =A0 =A0 t =3D time(NULL);
>> > =A0 =A0 =A0 =A0 tm =3D localtime(&t);
>> >
>> > =A0 =A0 =A0 =A0 b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>> > =A0 =A0 }
>> >
>> > into libxl__build_pre and do that calculation on a temporary variable
>> > whjich you pass to xc_domain_set_time_offset rather than modifying
>> > b_info.
>>
>> How about below patch?

I am currently compiling xen-unstable changeset 25193:c6bde42c8845
with this patch.  Will test then report back.

Thanks.

Kindest regards,
Giam Teck Choon

>>
>> From e06589cb5f1efd885f9589405d0f4ecc97427ad6 Mon Sep 17 00:00:00 2001
>> From: Lin Ming <mlin@ss.pku.edu.cn>
>> Date: Thu, 12 Apr 2012 22:36:24 +0800
>> Subject: [PATCH] libxl: fix rtc_timeoffset setting
>>
>> libxl__domain_build_info_setdefault may be called several times, so
>> rtc_timeoffset can't be set in it.
>>
>> Move rtc_timeoffset setting logic to libxl__build_pre.
>>
>> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
>> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>
> Looks good to me.
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
>> ---
>> =A0tools/libxl/libxl_create.c | =A0 =A09 ---------
>> =A0tools/libxl/libxl_dom.c =A0 =A0| =A0 17 +++++++++++++++--
>> =A02 files changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index e63c7bd..e706124 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *=
gc,
>> =A0 =A0 =A0 =A0 =A0b_info->target_memkb =3D b_info->max_memkb;
>>
>> =A0 =A0 =A0libxl_defbool_setdefault(&b_info->localtime, false);
>> - =A0 =A0if (libxl_defbool_val(b_info->localtime)) {
>> - =A0 =A0 =A0 =A0time_t t;
>> - =A0 =A0 =A0 =A0struct tm *tm;
>> -
>> - =A0 =A0 =A0 =A0t =3D time(NULL);
>> - =A0 =A0 =A0 =A0tm =3D localtime(&t);
>> -
>> - =A0 =A0 =A0 =A0b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>> - =A0 =A0}
>>
>> =A0 =A0 =A0libxl_defbool_setdefault(&b_info->disable_migrate, false);
>>
>> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> index 0bdd654..91c4bd8 100644
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
>> @@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>> =A0 =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);
>> =A0 =A0 =A0int tsc_mode;
>> =A0 =A0 =A0char *xs_domid, *con_domid;
>> + =A0 =A0uint32_t rtc_timeoffset;
>> +
>> =A0 =A0 =A0xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>> =A0 =A0 =A0libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info=
->cpumap);
>> =A0 =A0 =A0xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIB=
XL_MAXMEM_CONSTANT);
>> @@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>> =A0 =A0 =A0if (libxl_defbool_val(info->disable_migrate))
>> =A0 =A0 =A0 =A0 =A0xc_domain_disable_migrate(ctx->xch, domid);
>>
>> - =A0 =A0if (info->rtc_timeoffset)
>> - =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, info->rtc_ti=
meoffset);
>> + =A0 =A0rtc_timeoffset =3D info->rtc_timeoffset;
>> + =A0 =A0if (libxl_defbool_val(info->localtime)) {
>> + =A0 =A0 =A0 =A0time_t t;
>> + =A0 =A0 =A0 =A0struct tm *tm;
>> +
>> + =A0 =A0 =A0 =A0t =3D time(NULL);
>> + =A0 =A0 =A0 =A0tm =3D localtime(&t);
>> +
>> + =A0 =A0 =A0 =A0rtc_timeoffset +=3D tm->tm_gmtoff;
>> + =A0 =A0}
>> +
>> + =A0 =A0if (rtc_timeoffset)
>> + =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffs=
et);
>>
>> =A0 =A0 =A0if (info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> =A0 =A0 =A0 =A0 =A0unsigned long shadow;
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:05:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMVZ-0001v7-E2; Thu, 12 Apr 2012 16:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SIMVX-0001v2-EX
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:04:27 +0000
Received: from [85.158.138.51:21311] by server-12.bemta-3.messagelabs.com id
	22/44-29760-A0DF68F4; Thu, 12 Apr 2012 16:04:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334246665!21858492!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18546 invoked from network); 12 Apr 2012 16:04:25 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:04:25 -0000
Received: by eaaf11 with SMTP id f11so589960eaa.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 09:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Kzesh4fyIgtXm5Xb4gtrU7O2+ATQlHkPIKxi576qeO4=;
	b=VxrnpTKz8YPYvsXuOYXlsFV05GgsAJ02xvNIWi7SoLR1G1s+RMDIXe1D9zmyBJxIzY
	v5+70cAmJ0onmQKdDwhUltVBKhw/9ivYju7a4pEeNFHsQtSod4WfxyX4S7/8kj49U/ZI
	K2H8tTeMZJuvXpYkpEm/OmAkidE4UmhuTqpJQc/p/siR6WMb87xTkFSq6GqEJUUFAsuS
	cN20/VnKi1Eb1M0y1bVYWsY5m2NzAfRw9uAYUMT6SDlFvPL+8EOKCT/coat/OfF2kLzs
	ptRrFUCy4tRGspkHOxidCGprCGaesenNf0Q9GgEVnJdunqy/FqnW/Muesylz9OTrz/Vj
	jmEw==
Received: by 10.14.48.4 with SMTP id u4mr455093eeb.63.1334246665422;
	Thu, 12 Apr 2012 09:04:25 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id x4sm29634225eef.10.2012.04.12.09.04.23
	(version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 09:04:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Apr 2012 17:04:21 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CBACBB95.307CA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Stable branch releases?
Thread-Index: Ac0Yxev1Q6kFqyBe1kq5ZExrlcD09g==
In-Reply-To: <1334242794.16387.122.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/2012 15:59, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-04-12 at 11:47 +0100, Ian Jackson wrote:
>> Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
>>> I am keen on having these three patches in 4.1.3:
>>> http://marc.info/?l=xen-devel&m=133251438030441
>>> 
>>> I asked Ian to backport them in a previous email.
>> 
>> Right.
>> 
>> The first step in making a stable branch release should be to send a
>> message to xen-devel asking for people to resend any outstanding
>> backport requests, and setting a deadline for responses.
> 
> Shall we say a deadline of a week tomorrow (Friday 20th)?
> 
> Does this thread suffice as the request?

Make a new thread with a very explicit subject line, with [ANNOUNCE] or
similar in it.

 -- Keir

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:05:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMVZ-0001v7-E2; Thu, 12 Apr 2012 16:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SIMVX-0001v2-EX
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:04:27 +0000
Received: from [85.158.138.51:21311] by server-12.bemta-3.messagelabs.com id
	22/44-29760-A0DF68F4; Thu, 12 Apr 2012 16:04:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334246665!21858492!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18546 invoked from network); 12 Apr 2012 16:04:25 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:04:25 -0000
Received: by eaaf11 with SMTP id f11so589960eaa.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 09:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Kzesh4fyIgtXm5Xb4gtrU7O2+ATQlHkPIKxi576qeO4=;
	b=VxrnpTKz8YPYvsXuOYXlsFV05GgsAJ02xvNIWi7SoLR1G1s+RMDIXe1D9zmyBJxIzY
	v5+70cAmJ0onmQKdDwhUltVBKhw/9ivYju7a4pEeNFHsQtSod4WfxyX4S7/8kj49U/ZI
	K2H8tTeMZJuvXpYkpEm/OmAkidE4UmhuTqpJQc/p/siR6WMb87xTkFSq6GqEJUUFAsuS
	cN20/VnKi1Eb1M0y1bVYWsY5m2NzAfRw9uAYUMT6SDlFvPL+8EOKCT/coat/OfF2kLzs
	ptRrFUCy4tRGspkHOxidCGprCGaesenNf0Q9GgEVnJdunqy/FqnW/Muesylz9OTrz/Vj
	jmEw==
Received: by 10.14.48.4 with SMTP id u4mr455093eeb.63.1334246665422;
	Thu, 12 Apr 2012 09:04:25 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id x4sm29634225eef.10.2012.04.12.09.04.23
	(version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 09:04:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Apr 2012 17:04:21 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CBACBB95.307CA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Stable branch releases?
Thread-Index: Ac0Yxev1Q6kFqyBe1kq5ZExrlcD09g==
In-Reply-To: <1334242794.16387.122.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/2012 15:59, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-04-12 at 11:47 +0100, Ian Jackson wrote:
>> Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
>>> I am keen on having these three patches in 4.1.3:
>>> http://marc.info/?l=xen-devel&m=133251438030441
>>> 
>>> I asked Ian to backport them in a previous email.
>> 
>> Right.
>> 
>> The first step in making a stable branch release should be to send a
>> message to xen-devel asking for people to resend any outstanding
>> backport requests, and setting a deadline for responses.
> 
> Shall we say a deadline of a week tomorrow (Friday 20th)?
> 
> Does this thread suffice as the request?

Make a new thread with a very explicit subject line, with [ANNOUNCE] or
similar in it.

 -- Keir

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMs8-0002Ar-E7; Thu, 12 Apr 2012 16:27:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SIMs7-0002Al-M1
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 16:27:47 +0000
Received: from [85.158.143.99:26380] by server-2.bemta-4.messagelabs.com id
	A0/93-17550-382078F4; Thu, 12 Apr 2012 16:27:47 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334248064!17023142!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24224 invoked from network); 12 Apr 2012 16:27:46 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:27:46 -0000
Received: by dadp12 with SMTP id p12so3351784dad.7
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 09:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=h/LKtht98OLlmGhA8IwxRbfeoQsX7IOX6s6Cq322efA=;
	b=wKU7XQwUzg/tJ4/XNOaEKHurEhjtt2NAOX8GCmgVh9W2kYHGUlLQrXBJiF15XNVV0y
	72ramAA8eJE24PH/JwGthqmjZO1Oq8sQFlKci2jZRcKUUpKU1L2DIVuQg0O135MTFgIG
	a1t/AknKa63XeRV3e6x7ukII1i8tW79cILlVO/xgkHjm1WghInONs5OoYbqhF6wfwota
	1QNIuQnWyrdoFUxH7n9JZgzhajKyKydFFa/P3WTAZNN9qOEg0r88nq5mVrB+Zdj3ZSdo
	azG41z7xNyxnFGmT2dR0zWwG3BqNC6ymo0a6QcqDaayNyN+/ABSa5efiY1BWO5FcQ6bn
	dUtg==
MIME-Version: 1.0
Received: by 10.68.225.195 with SMTP id rm3mr3835792pbc.96.1334248063619; Thu,
	12 Apr 2012 09:27:43 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Thu, 12 Apr 2012 09:27:43 -0700 (PDT)
In-Reply-To: <CAEwRVpO7f5yLpZkWQiTh68tAQ9OL4Qo24otBdvjPBfPMFe29Yg@mail.gmail.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
	<1334241773.4001.5.camel@hp6530s>
	<1334242251.16387.119.camel@zakaz.uk.xensource.com>
	<CAEwRVpO7f5yLpZkWQiTh68tAQ9OL4Qo24otBdvjPBfPMFe29Yg@mail.gmail.com>
Date: Fri, 13 Apr 2012 00:27:43 +0800
Message-ID: <CAEwRVpNvyH4dZg3vh9GRxU_qxVqADB_v5wRpnqagSmR32TA9Ug@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 11:25 PM, Teck Choon Giam
<giamteckchoon@gmail.com> wrote:
> On Thu, Apr 12, 2012 at 10:50 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> On Thu, 2012-04-12 at 15:42 +0100, Lin Ming wrote:
>>> On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
>>> > On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
>>> > > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
>>> > > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
>>> > > > > Hi,
>>> > > > >
>>> > > > > This is just my experience about issues I encountered when upgr=
ade
>>> > > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstab=
le
>>> > > > > changeset 25191:a95fc7decc83.
>>> > > > >
>>> > > > > 1. Immediately after upgrade, xl list show such error:
>>> > > > >
>>> > > > > # xl list
>>> > > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info=
 list:
>>> > > > > Permission denied
>>> > > > > libxl_domain_infolist failed.
>>> > > > >
>>> > > > > After a reboot, it is fine. =A0Any idea why such behaviour? =A0=
Imagine if
>>> > > > > there are running domUs... this might cause issues to shutdown?=
 =A0I
>>> > > > > will downgrade and repeat such test to confirm. =A0Might be wor=
th a note
>>> > > > > in upgrading note about this if this is intended?
>>> > > >
>>> > > > The tools and the hypervisor are a matched pair so you would need=
 to
>>> > > > reboot the system in order to use the new tools. This has always =
been
>>> > > > the case with Xen upgrades.
>>> > > >
>>> > > > > 2. localtime setting not working. =A0Set to localtime=3D1 doesn=
't seems to
>>> > > > > work whereby setting rtc_timeoffset works. =A0Any idea?
>>> > > >
>>> > > > I've CC'd Lin Ming who implemented both of those.
>>> > >
>>> > > Just did a quick gdb debug, seems libxl__domain_build_info_setdefau=
lt
>>> > > was called 3 times. So below statement was executed 3 times too.
>>> > >
>>> > > b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>>> >
>>> > Oh, that sounds like the problem. The setdefault functions are suppos=
ed
>>> > to be idempotent, IOW calling it two or more times should give the sa=
me
>>> > result as calling it just once.
>>> >
>>> > I think you need to move this logic from setdefault
>>> > =A0 =A0 if (libxl_defbool_val(b_info->localtime)) {
>>> > =A0 =A0 =A0 =A0 time_t t;
>>> > =A0 =A0 =A0 =A0 struct tm *tm;
>>> >
>>> > =A0 =A0 =A0 =A0 t =3D time(NULL);
>>> > =A0 =A0 =A0 =A0 tm =3D localtime(&t);
>>> >
>>> > =A0 =A0 =A0 =A0 b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>>> > =A0 =A0 }
>>> >
>>> > into libxl__build_pre and do that calculation on a temporary variable
>>> > whjich you pass to xc_domain_set_time_offset rather than modifying
>>> > b_info.
>>>
>>> How about below patch?
>
> I am currently compiling xen-unstable changeset 25193:c6bde42c8845
> with this patch. =A0Will test then report back.

Tested and it works!

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMs8-0002Ar-E7; Thu, 12 Apr 2012 16:27:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SIMs7-0002Al-M1
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 16:27:47 +0000
Received: from [85.158.143.99:26380] by server-2.bemta-4.messagelabs.com id
	A0/93-17550-382078F4; Thu, 12 Apr 2012 16:27:47 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334248064!17023142!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24224 invoked from network); 12 Apr 2012 16:27:46 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:27:46 -0000
Received: by dadp12 with SMTP id p12so3351784dad.7
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 09:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=h/LKtht98OLlmGhA8IwxRbfeoQsX7IOX6s6Cq322efA=;
	b=wKU7XQwUzg/tJ4/XNOaEKHurEhjtt2NAOX8GCmgVh9W2kYHGUlLQrXBJiF15XNVV0y
	72ramAA8eJE24PH/JwGthqmjZO1Oq8sQFlKci2jZRcKUUpKU1L2DIVuQg0O135MTFgIG
	a1t/AknKa63XeRV3e6x7ukII1i8tW79cILlVO/xgkHjm1WghInONs5OoYbqhF6wfwota
	1QNIuQnWyrdoFUxH7n9JZgzhajKyKydFFa/P3WTAZNN9qOEg0r88nq5mVrB+Zdj3ZSdo
	azG41z7xNyxnFGmT2dR0zWwG3BqNC6ymo0a6QcqDaayNyN+/ABSa5efiY1BWO5FcQ6bn
	dUtg==
MIME-Version: 1.0
Received: by 10.68.225.195 with SMTP id rm3mr3835792pbc.96.1334248063619; Thu,
	12 Apr 2012 09:27:43 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Thu, 12 Apr 2012 09:27:43 -0700 (PDT)
In-Reply-To: <CAEwRVpO7f5yLpZkWQiTh68tAQ9OL4Qo24otBdvjPBfPMFe29Yg@mail.gmail.com>
References: <CAEwRVpM20XwC54SoyM44Ya=_MS_uNkLLnwOTT0rOoxhBX+yvbA@mail.gmail.com>
	<1334214539.12209.219.camel@dagon.hellion.org.uk>
	<1334235037.4001.3.camel@hp6530s>
	<1334239381.16387.106.camel@zakaz.uk.xensource.com>
	<1334241773.4001.5.camel@hp6530s>
	<1334242251.16387.119.camel@zakaz.uk.xensource.com>
	<CAEwRVpO7f5yLpZkWQiTh68tAQ9OL4Qo24otBdvjPBfPMFe29Yg@mail.gmail.com>
Date: Fri, 13 Apr 2012 00:27:43 +0800
Message-ID: <CAEwRVpNvyH4dZg3vh9GRxU_qxVqADB_v5wRpnqagSmR32TA9Ug@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] Upgrade from xen-4.1-testing to xen-unstable report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 12, 2012 at 11:25 PM, Teck Choon Giam
<giamteckchoon@gmail.com> wrote:
> On Thu, Apr 12, 2012 at 10:50 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> On Thu, 2012-04-12 at 15:42 +0100, Lin Ming wrote:
>>> On Thu, 2012-04-12 at 15:03 +0100, Ian Campbell wrote:
>>> > On Thu, 2012-04-12 at 13:50 +0100, Lin Ming wrote:
>>> > > On Thu, 2012-04-12 at 07:08 +0000, Ian Campbell wrote:
>>> > > > On Wed, 2012-04-11 at 22:23 +0100, Teck Choon Giam wrote:
>>> > > > > Hi,
>>> > > > >
>>> > > > > This is just my experience about issues I encountered when upgr=
ade
>>> > > > > from xen-4.1-testing changeset 23277:80130491806f to xen-unstab=
le
>>> > > > > changeset 25191:a95fc7decc83.
>>> > > > >
>>> > > > > 1. Immediately after upgrade, xl list show such error:
>>> > > > >
>>> > > > > # xl list
>>> > > > > libxl: error: libxl.c:506:libxl_list_domain: geting domain info=
 list:
>>> > > > > Permission denied
>>> > > > > libxl_domain_infolist failed.
>>> > > > >
>>> > > > > After a reboot, it is fine. =A0Any idea why such behaviour? =A0=
Imagine if
>>> > > > > there are running domUs... this might cause issues to shutdown?=
 =A0I
>>> > > > > will downgrade and repeat such test to confirm. =A0Might be wor=
th a note
>>> > > > > in upgrading note about this if this is intended?
>>> > > >
>>> > > > The tools and the hypervisor are a matched pair so you would need=
 to
>>> > > > reboot the system in order to use the new tools. This has always =
been
>>> > > > the case with Xen upgrades.
>>> > > >
>>> > > > > 2. localtime setting not working. =A0Set to localtime=3D1 doesn=
't seems to
>>> > > > > work whereby setting rtc_timeoffset works. =A0Any idea?
>>> > > >
>>> > > > I've CC'd Lin Ming who implemented both of those.
>>> > >
>>> > > Just did a quick gdb debug, seems libxl__domain_build_info_setdefau=
lt
>>> > > was called 3 times. So below statement was executed 3 times too.
>>> > >
>>> > > b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>>> >
>>> > Oh, that sounds like the problem. The setdefault functions are suppos=
ed
>>> > to be idempotent, IOW calling it two or more times should give the sa=
me
>>> > result as calling it just once.
>>> >
>>> > I think you need to move this logic from setdefault
>>> > =A0 =A0 if (libxl_defbool_val(b_info->localtime)) {
>>> > =A0 =A0 =A0 =A0 time_t t;
>>> > =A0 =A0 =A0 =A0 struct tm *tm;
>>> >
>>> > =A0 =A0 =A0 =A0 t =3D time(NULL);
>>> > =A0 =A0 =A0 =A0 tm =3D localtime(&t);
>>> >
>>> > =A0 =A0 =A0 =A0 b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
>>> > =A0 =A0 }
>>> >
>>> > into libxl__build_pre and do that calculation on a temporary variable
>>> > whjich you pass to xc_domain_set_time_offset rather than modifying
>>> > b_info.
>>>
>>> How about below patch?
>
> I am currently compiling xen-unstable changeset 25193:c6bde42c8845
> with this patch. =A0Will test then report back.

Tested and it works!

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMv4-0002GX-Bc; Thu, 12 Apr 2012 16:30:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIMv2-0002GM-Dz
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:30:48 +0000
Received: from [85.158.139.83:8871] by server-1.bemta-5.messagelabs.com id
	DE/C1-28458-733078F4; Thu, 12 Apr 2012 16:30:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334248246!23558124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19066 invoked from network); 12 Apr 2012 16:30:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:30:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11909291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 16:30:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 17:30:46 +0100
Message-ID: <1334248244.16387.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 12 Apr 2012 17:30:44 +0100
In-Reply-To: <CBACBB95.307CA%keir.xen@gmail.com>
References: <CBACBB95.307CA%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 17:04 +0100, Keir Fraser wrote:
> On 12/04/2012 15:59, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-04-12 at 11:47 +0100, Ian Jackson wrote:
> >> Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
> >>> I am keen on having these three patches in 4.1.3:
> >>> http://marc.info/?l=xen-devel&m=133251438030441
> >>> 
> >>> I asked Ian to backport them in a previous email.
> >> 
> >> Right.
> >> 
> >> The first step in making a stable branch release should be to send a
> >> message to xen-devel asking for people to resend any outstanding
> >> backport requests, and setting a deadline for responses.
> > 
> > Shall we say a deadline of a week tomorrow (Friday 20th)?
> > 
> > Does this thread suffice as the request?
> 
> Make a new thread with a very explicit subject line, with [ANNOUNCE] or
> similar in it.

Done.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMv4-0002GX-Bc; Thu, 12 Apr 2012 16:30:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIMv2-0002GM-Dz
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:30:48 +0000
Received: from [85.158.139.83:8871] by server-1.bemta-5.messagelabs.com id
	DE/C1-28458-733078F4; Thu, 12 Apr 2012 16:30:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334248246!23558124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19066 invoked from network); 12 Apr 2012 16:30:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:30:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11909291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 16:30:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 17:30:46 +0100
Message-ID: <1334248244.16387.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 12 Apr 2012 17:30:44 +0100
In-Reply-To: <CBACBB95.307CA%keir.xen@gmail.com>
References: <CBACBB95.307CA%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Stable branch releases?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 17:04 +0100, Keir Fraser wrote:
> On 12/04/2012 15:59, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-04-12 at 11:47 +0100, Ian Jackson wrote:
> >> Stefano Stabellini writes ("Re: [Xen-devel] Stable branch releases?"):
> >>> I am keen on having these three patches in 4.1.3:
> >>> http://marc.info/?l=xen-devel&m=133251438030441
> >>> 
> >>> I asked Ian to backport them in a previous email.
> >> 
> >> Right.
> >> 
> >> The first step in making a stable branch release should be to send a
> >> message to xen-devel asking for people to resend any outstanding
> >> backport requests, and setting a deadline for responses.
> > 
> > Shall we say a deadline of a week tomorrow (Friday 20th)?
> > 
> > Does this thread suffice as the request?
> 
> Make a new thread with a very explicit subject line, with [ANNOUNCE] or
> similar in it.

Done.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMut-0002Fq-WC; Thu, 12 Apr 2012 16:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIMut-0002Fl-47
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:30:39 +0000
Received: from [193.109.254.147:26221] by server-3.bemta-14.messagelabs.com id
	79/84-23274-E23078F4; Thu, 12 Apr 2012 16:30:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334248236!4345396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23247 invoked from network); 12 Apr 2012 16:30:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:30:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11909284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 16:30:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 17:30:36 +0100
Message-ID: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 12 Apr 2012 17:30:35 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The time has come for another round of stable releases.

Please send (or resend) any outstanding backport requests for 4.0.4 and
4.1.3 before Friday 20 April.

Note that 4.0.4 will likely be the last release in the 4.0.x branch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIMut-0002Fq-WC; Thu, 12 Apr 2012 16:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIMut-0002Fl-47
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:30:39 +0000
Received: from [193.109.254.147:26221] by server-3.bemta-14.messagelabs.com id
	79/84-23274-E23078F4; Thu, 12 Apr 2012 16:30:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334248236!4345396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23247 invoked from network); 12 Apr 2012 16:30:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:30:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="11909284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 16:30:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 17:30:36 +0100
Message-ID: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 12 Apr 2012 17:30:35 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The time has come for another round of stable releases.

Please send (or resend) any outstanding backport requests for 4.0.4 and
4.1.3 before Friday 20 April.

Note that 4.0.4 will likely be the last release in the 4.0.x branch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIN1s-0002av-72; Thu, 12 Apr 2012 16:37:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SIN1q-0002aq-Ob
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:37:50 +0000
Received: from [85.158.143.35:44001] by server-2.bemta-4.messagelabs.com id
	4E/4E-17550-ED4078F4; Thu, 12 Apr 2012 16:37:50 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334248665!6812162!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2Njk5Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28141 invoked from network); 12 Apr 2012 16:37:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Apr 2012 16:37:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3CGbeuS013321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Apr 2012 16:37:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3CGbd49019111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Apr 2012 16:37:40 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3CGbdUF023506; Thu, 12 Apr 2012 11:37:39 -0500
MIME-Version: 1.0
Message-ID: <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
Date: Thu, 12 Apr 2012 09:37:34 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
In-Reply-To: <1334217564.12209.250.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F8704D5.00E5,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Thursday, April 12, 2012 1:59 AM
> To: Ian Jackson; Dan Magenheimer
> Cc: xen-devel
> Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
> 
> On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> >
> > > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> > use_long);
> > > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > > ]                      uint32_t set);
> > > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> > uuid,
> > > ]                              int auth);
> > > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > >
> > > Not sure about the tmem calls.
> >
> > Me neither.
> 
> Dan,
> 
> We want to declare the libxl 4.2 API as "stable" so we are trying to
> determine whether any of these functions need to be made potentially
> asynchronous or not, i.e. if they may be "slow" per the definition under
> the comment "Machinery for asynchronous operations ("ao")" in
> tools/libxl/libxl_internal.h, effectively if they may block for extended
> periods.
> 
> If they were then we would possibly want to change the API to take an
> "ao_how" as described under "Some libxl operations can take a long time"
> in tools/libxl/libxl.h
> 
> If they are "fast" today but could potentially be slow in the future
> then we may be able to make the trivial API change but keep the
> synchronous implementation (depending on the specifics). It's quite late
> in the day so if the functions are "slow" then this would be the
> preferred option at this stage.
> 
> Otherwise the alternative is that we have to maintain these interfaces
> going forward (for compat) and perhaps be forced introduce a new
> parallel async interface in the future. Annoying but not the end of the
> world.

Hi Ian(s) --

After reading libxl.h, I'm not absolutely positive I understand
all the conditions that would cause you to label a function as
"slow" but I believe all the libxl_tmem_* functions are "fast".
All of them are strictly "call the hypervisor, wait for it to
return" and none of the hypercalls (actually which are variations of
the one tmem hypercall) require a callback to dom0 or to the
calling guest... they all complete entirely inside the hypervisor.

Libxl_tmem_destroy may take a long time as it has to walk
through and free some potentially very large data structures,
but it is only used at domain destruction.

Libxl_tmem_list does allocate some memory in userland that the
hypercall fills synchronously (with ascii-formatted statistics/counters
maintained entirely by the tmem code in the hypervisor).

If any of the above raises any alarms/concerns, let me know,
else no need to asynchronizify any of the tmem functions in libxl.

(Zhigang cc'ed since he's more familiar with the libxl layer than I.)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIN1s-0002av-72; Thu, 12 Apr 2012 16:37:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SIN1q-0002aq-Ob
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:37:50 +0000
Received: from [85.158.143.35:44001] by server-2.bemta-4.messagelabs.com id
	4E/4E-17550-ED4078F4; Thu, 12 Apr 2012 16:37:50 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334248665!6812162!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2Njk5Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28141 invoked from network); 12 Apr 2012 16:37:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Apr 2012 16:37:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3CGbeuS013321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Apr 2012 16:37:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3CGbd49019111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Apr 2012 16:37:40 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3CGbdUF023506; Thu, 12 Apr 2012 11:37:39 -0500
MIME-Version: 1.0
Message-ID: <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
Date: Thu, 12 Apr 2012 09:37:34 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
In-Reply-To: <1334217564.12209.250.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F8704D5.00E5,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Thursday, April 12, 2012 1:59 AM
> To: Ian Jackson; Dan Magenheimer
> Cc: xen-devel
> Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
> 
> On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> >
> > > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> > use_long);
> > > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > > ]                      uint32_t set);
> > > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> > uuid,
> > > ]                              int auth);
> > > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > >
> > > Not sure about the tmem calls.
> >
> > Me neither.
> 
> Dan,
> 
> We want to declare the libxl 4.2 API as "stable" so we are trying to
> determine whether any of these functions need to be made potentially
> asynchronous or not, i.e. if they may be "slow" per the definition under
> the comment "Machinery for asynchronous operations ("ao")" in
> tools/libxl/libxl_internal.h, effectively if they may block for extended
> periods.
> 
> If they were then we would possibly want to change the API to take an
> "ao_how" as described under "Some libxl operations can take a long time"
> in tools/libxl/libxl.h
> 
> If they are "fast" today but could potentially be slow in the future
> then we may be able to make the trivial API change but keep the
> synchronous implementation (depending on the specifics). It's quite late
> in the day so if the functions are "slow" then this would be the
> preferred option at this stage.
> 
> Otherwise the alternative is that we have to maintain these interfaces
> going forward (for compat) and perhaps be forced introduce a new
> parallel async interface in the future. Annoying but not the end of the
> world.

Hi Ian(s) --

After reading libxl.h, I'm not absolutely positive I understand
all the conditions that would cause you to label a function as
"slow" but I believe all the libxl_tmem_* functions are "fast".
All of them are strictly "call the hypervisor, wait for it to
return" and none of the hypercalls (actually which are variations of
the one tmem hypercall) require a callback to dom0 or to the
calling guest... they all complete entirely inside the hypervisor.

Libxl_tmem_destroy may take a long time as it has to walk
through and free some potentially very large data structures,
but it is only used at domain destruction.

Libxl_tmem_list does allocate some memory in userland that the
hypercall fills synchronously (with ascii-formatted statistics/counters
maintained entirely by the tmem code in the hypervisor).

If any of the above raises any alarms/concerns, let me know,
else no need to asynchronizify any of the tmem functions in libxl.

(Zhigang cc'ed since he's more familiar with the libxl layer than I.)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:46:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIN9p-0002qf-9T; Thu, 12 Apr 2012 16:46:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIN9n-0002qa-LH
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:46:03 +0000
Received: from [85.158.143.99:30176] by server-2.bemta-4.messagelabs.com id
	48/A6-17550-AC6078F4; Thu, 12 Apr 2012 16:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334249160!20017888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 12 Apr 2012 16:46:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330905600"; d="scan'208";a="11909532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 16:45:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 17:45:33 +0100
Message-ID: <1334249132.16387.147.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Date: Thu, 12 Apr 2012 17:45:32 +0100
In-Reply-To: <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 17:37 +0100, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Thursday, April 12, 2012 1:59 AM
> > To: Ian Jackson; Dan Magenheimer
> > Cc: xen-devel
> > Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
> > 
> > On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> > >
> > > > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> > > use_long);
> > > > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > > > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > > > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > > > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > > > ]                      uint32_t set);
> > > > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> > > uuid,
> > > > ]                              int auth);
> > > > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > > >
> > > > Not sure about the tmem calls.
> > >
> > > Me neither.
> > 
> > Dan,
> > 
> > We want to declare the libxl 4.2 API as "stable" so we are trying to
> > determine whether any of these functions need to be made potentially
> > asynchronous or not, i.e. if they may be "slow" per the definition under
> > the comment "Machinery for asynchronous operations ("ao")" in
> > tools/libxl/libxl_internal.h, effectively if they may block for extended
> > periods.
> > 
> > If they were then we would possibly want to change the API to take an
> > "ao_how" as described under "Some libxl operations can take a long time"
> > in tools/libxl/libxl.h
> > 
> > If they are "fast" today but could potentially be slow in the future
> > then we may be able to make the trivial API change but keep the
> > synchronous implementation (depending on the specifics). It's quite late
> > in the day so if the functions are "slow" then this would be the
> > preferred option at this stage.
> > 
> > Otherwise the alternative is that we have to maintain these interfaces
> > going forward (for compat) and perhaps be forced introduce a new
> > parallel async interface in the future. Annoying but not the end of the
> > world.
> 
> Hi Ian(s) --
> 
> After reading libxl.h, I'm not absolutely positive I understand
> all the conditions that would cause you to label a function as
> "slow" but I believe all the libxl_tmem_* functions are "fast".
> All of them are strictly "call the hypervisor, wait for it to
> return" and none of the hypercalls (actually which are variations of
> the one tmem hypercall) require a callback to dom0 or to the
> calling guest... they all complete entirely inside the hypervisor.

OK, this sounds good, thanks.

> Libxl_tmem_destroy may take a long time as it has to walk
> through and free some potentially very large data structures,
> but it is only used at domain destruction.

Should libxl_tmem_destroy be a public function or should it solely be
called from libxl_domain_destroy? I notice that there is an xl
tmem-destroy so I presume the former?

We might consider adding a dummy ao_how to this one I suppose.

> Libxl_tmem_list does allocate some memory in userland that the
> hypercall fills synchronously (with ascii-formatted statistics/counters
> maintained entirely by the tmem code in the hypervisor).
> 
> If any of the above raises any alarms/concerns, let me know,
> else no need to asynchronizify any of the tmem functions in libxl.

It all sounds fine, I more curious about tmem_destroy than worried.

Ian.

> 
> (Zhigang cc'ed since he's more familiar with the libxl layer than I.)
> 
> Dan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 16:46:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 16:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIN9p-0002qf-9T; Thu, 12 Apr 2012 16:46:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIN9n-0002qa-LH
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 16:46:03 +0000
Received: from [85.158.143.99:30176] by server-2.bemta-4.messagelabs.com id
	48/A6-17550-AC6078F4; Thu, 12 Apr 2012 16:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334249160!20017888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 12 Apr 2012 16:46:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 16:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330905600"; d="scan'208";a="11909532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 16:45:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Apr 2012 17:45:33 +0100
Message-ID: <1334249132.16387.147.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Date: Thu, 12 Apr 2012 17:45:32 +0100
In-Reply-To: <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 17:37 +0100, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Thursday, April 12, 2012 1:59 AM
> > To: Ian Jackson; Dan Magenheimer
> > Cc: xen-devel
> > Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
> > 
> > On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> > >
> > > > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> > > use_long);
> > > > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > > > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > > > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > > > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > > > ]                      uint32_t set);
> > > > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> > > uuid,
> > > > ]                              int auth);
> > > > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > > >
> > > > Not sure about the tmem calls.
> > >
> > > Me neither.
> > 
> > Dan,
> > 
> > We want to declare the libxl 4.2 API as "stable" so we are trying to
> > determine whether any of these functions need to be made potentially
> > asynchronous or not, i.e. if they may be "slow" per the definition under
> > the comment "Machinery for asynchronous operations ("ao")" in
> > tools/libxl/libxl_internal.h, effectively if they may block for extended
> > periods.
> > 
> > If they were then we would possibly want to change the API to take an
> > "ao_how" as described under "Some libxl operations can take a long time"
> > in tools/libxl/libxl.h
> > 
> > If they are "fast" today but could potentially be slow in the future
> > then we may be able to make the trivial API change but keep the
> > synchronous implementation (depending on the specifics). It's quite late
> > in the day so if the functions are "slow" then this would be the
> > preferred option at this stage.
> > 
> > Otherwise the alternative is that we have to maintain these interfaces
> > going forward (for compat) and perhaps be forced introduce a new
> > parallel async interface in the future. Annoying but not the end of the
> > world.
> 
> Hi Ian(s) --
> 
> After reading libxl.h, I'm not absolutely positive I understand
> all the conditions that would cause you to label a function as
> "slow" but I believe all the libxl_tmem_* functions are "fast".
> All of them are strictly "call the hypervisor, wait for it to
> return" and none of the hypercalls (actually which are variations of
> the one tmem hypercall) require a callback to dom0 or to the
> calling guest... they all complete entirely inside the hypervisor.

OK, this sounds good, thanks.

> Libxl_tmem_destroy may take a long time as it has to walk
> through and free some potentially very large data structures,
> but it is only used at domain destruction.

Should libxl_tmem_destroy be a public function or should it solely be
called from libxl_domain_destroy? I notice that there is an xl
tmem-destroy so I presume the former?

We might consider adding a dummy ao_how to this one I suppose.

> Libxl_tmem_list does allocate some memory in userland that the
> hypercall fills synchronously (with ascii-formatted statistics/counters
> maintained entirely by the tmem code in the hypervisor).
> 
> If any of the above raises any alarms/concerns, let me know,
> else no need to asynchronizify any of the tmem functions in libxl.

It all sounds fine, I more curious about tmem_destroy than worried.

Ian.

> 
> (Zhigang cc'ed since he's more familiar with the libxl layer than I.)
> 
> Dan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 17:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 17:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SINSY-0003HC-KO; Thu, 12 Apr 2012 17:05:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1SINSW-0003H7-9N
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 17:05:24 +0000
Received: from [85.158.138.51:42533] by server-11.bemta-3.messagelabs.com id
	F2/6E-18894-35B078F4; Thu, 12 Apr 2012 17:05:23 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334250322!10892980!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27128 invoked from network); 12 Apr 2012 17:05:22 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 17:05:22 -0000
Received: by wibhj13 with SMTP id hj13so4957144wib.6
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 10:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=pWwtonKfgGL/Q7aVD1wr12lPZF5fC4RuFDytVGjGaZs=;
	b=lX47CZlTCmw3oN9vGg+b5+zdch7LaXjfopPqQhRU4P8o0IdJKHfDONhc9nPxAA3Di+
	SEyizs9FdMslPy1/J79oh6pUoj0TUJ5j/hTnv7lOHxqNi95NppXBelDgBeQ431czyG6b
	Rd2vuLlZqjJwTho16ynPAkGQeBi4XHnfaosFpUeB3/0lG2Q0lZYYNs0PKI9k2LQr1xSl
	MpqP3YXeiJe621/anFHvQha+ENFlflB3jn7gDIyX928bK5DtwMlBMRzqIt2F5g+Ebt2O
	a5arxWwxfyTAIFrEUXxnMakiWkG3iHXwZ0rotjeY54k1EiVRxhlEgspkaf1roJBpX+1r
	03uw==
MIME-Version: 1.0
Received: by 10.180.80.70 with SMTP id p6mr17455752wix.21.1334250322235; Thu,
	12 Apr 2012 10:05:22 -0700 (PDT)
Received: by 10.180.85.103 with HTTP; Thu, 12 Apr 2012 10:05:22 -0700 (PDT)
In-Reply-To: <4F86D464.4080601@amd.com>
References: <4F86D464.4080601@amd.com>
Date: Thu, 12 Apr 2012 13:05:22 -0400
Message-ID: <CAMTrTqUfiBPZ9bPYpCnuD=DSTEvG4oACMfAPBHGvja-JD_MnFw@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: Wei Wang <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Wei,
I have read you slides in xen summit 2007 about NPT in AMD, "AMD
Barcelona and Nested Paging Support in Xen".
However, I have some question regarding the nested page walk in your slide 8.

In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
I assume that it use the [47:39] bit of gVA.
However, in another AMD white paper, "AMD-VTM Nested Paging".
http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
In its figure 4, I saw that the first step is to translate gCR3 using
nested page walk and then combine with the gVA[47:39] to read the
table entry.

These two documents look having different order of reading the guest
page table. In the slides, it first get_PML4. But in the white paper,
it first does nested page walk.
I am wondering which one is true. Thanks.

- ha

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 17:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 17:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SINSY-0003HC-KO; Thu, 12 Apr 2012 17:05:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1SINSW-0003H7-9N
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 17:05:24 +0000
Received: from [85.158.138.51:42533] by server-11.bemta-3.messagelabs.com id
	F2/6E-18894-35B078F4; Thu, 12 Apr 2012 17:05:23 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334250322!10892980!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27128 invoked from network); 12 Apr 2012 17:05:22 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 17:05:22 -0000
Received: by wibhj13 with SMTP id hj13so4957144wib.6
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 10:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=pWwtonKfgGL/Q7aVD1wr12lPZF5fC4RuFDytVGjGaZs=;
	b=lX47CZlTCmw3oN9vGg+b5+zdch7LaXjfopPqQhRU4P8o0IdJKHfDONhc9nPxAA3Di+
	SEyizs9FdMslPy1/J79oh6pUoj0TUJ5j/hTnv7lOHxqNi95NppXBelDgBeQ431czyG6b
	Rd2vuLlZqjJwTho16ynPAkGQeBi4XHnfaosFpUeB3/0lG2Q0lZYYNs0PKI9k2LQr1xSl
	MpqP3YXeiJe621/anFHvQha+ENFlflB3jn7gDIyX928bK5DtwMlBMRzqIt2F5g+Ebt2O
	a5arxWwxfyTAIFrEUXxnMakiWkG3iHXwZ0rotjeY54k1EiVRxhlEgspkaf1roJBpX+1r
	03uw==
MIME-Version: 1.0
Received: by 10.180.80.70 with SMTP id p6mr17455752wix.21.1334250322235; Thu,
	12 Apr 2012 10:05:22 -0700 (PDT)
Received: by 10.180.85.103 with HTTP; Thu, 12 Apr 2012 10:05:22 -0700 (PDT)
In-Reply-To: <4F86D464.4080601@amd.com>
References: <4F86D464.4080601@amd.com>
Date: Thu, 12 Apr 2012 13:05:22 -0400
Message-ID: <CAMTrTqUfiBPZ9bPYpCnuD=DSTEvG4oACMfAPBHGvja-JD_MnFw@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: Wei Wang <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Wei,
I have read you slides in xen summit 2007 about NPT in AMD, "AMD
Barcelona and Nested Paging Support in Xen".
However, I have some question regarding the nested page walk in your slide 8.

In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
I assume that it use the [47:39] bit of gVA.
However, in another AMD white paper, "AMD-VTM Nested Paging".
http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
In its figure 4, I saw that the first step is to translate gCR3 using
nested page walk and then combine with the gVA[47:39] to read the
table entry.

These two documents look having different order of reading the guest
page table. In the slides, it first get_PML4. But in the white paper,
it first does nested page walk.
I am wondering which one is true. Thanks.

- ha

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 17:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 17:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SINTV-0003LN-6g; Thu, 12 Apr 2012 17:06:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1SINTU-0003LD-Ae
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 17:06:24 +0000
Received: from [85.158.143.99:6915] by server-2.bemta-4.messagelabs.com id
	77/19-17550-F8B078F4; Thu, 12 Apr 2012 17:06:23 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334250382!23354667!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19022 invoked from network); 12 Apr 2012 17:06:22 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 17:06:22 -0000
Received: by wibhj13 with SMTP id hj13so1951539wib.6
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 10:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=pWwtonKfgGL/Q7aVD1wr12lPZF5fC4RuFDytVGjGaZs=;
	b=kYZwZ64GypeqpAm5tmWaJuHUCMSh0s3XIl2BBjA9WDotRQaI4eqYSkcJ7FkqP/6mRt
	n4JT2B8p6qHnLp8A4v72HDzE8wBl43t+S4xC/a1nSTOGMPbKzMoGzKTS89+DtKcN3bPu
	o2bbanIM2UTfjWWcNDvPeDg1f/3Wpo52B1YqzUeCfmlYx8h4TrxQJYPZn/vuFM5nP8t1
	Sci84/8HveJNFABdVo6+Mz/EZQsYCmjkLqZziPS3Toy5VNer0vByUdMWDOb3CvceoxwA
	QWUPIe5SwJ+7ih+OPeu3XbnPSa5Hz8WCzLKlJqeerdzjDaFV1YFXwZHIa8hd6oaxcCHr
	WhgA==
MIME-Version: 1.0
Received: by 10.216.132.202 with SMTP id o52mr1956262wei.106.1334250382327;
	Thu, 12 Apr 2012 10:06:22 -0700 (PDT)
Received: by 10.180.85.103 with HTTP; Thu, 12 Apr 2012 10:06:22 -0700 (PDT)
Date: Thu, 12 Apr 2012 13:06:22 -0400
Message-ID: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: Wei Wang <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: [Xen-devel] Understanding AMD NPT in xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Wei,
I have read you slides in xen summit 2007 about NPT in AMD, "AMD
Barcelona and Nested Paging Support in Xen".
However, I have some question regarding the nested page walk in your slide 8.

In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
I assume that it use the [47:39] bit of gVA.
However, in another AMD white paper, "AMD-VTM Nested Paging".
http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
In its figure 4, I saw that the first step is to translate gCR3 using
nested page walk and then combine with the gVA[47:39] to read the
table entry.

These two documents look having different order of reading the guest
page table. In the slides, it first get_PML4. But in the white paper,
it first does nested page walk.
I am wondering which one is true. Thanks.

- ha

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 17:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 17:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SINTV-0003LN-6g; Thu, 12 Apr 2012 17:06:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1SINTU-0003LD-Ae
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 17:06:24 +0000
Received: from [85.158.143.99:6915] by server-2.bemta-4.messagelabs.com id
	77/19-17550-F8B078F4; Thu, 12 Apr 2012 17:06:23 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334250382!23354667!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19022 invoked from network); 12 Apr 2012 17:06:22 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 17:06:22 -0000
Received: by wibhj13 with SMTP id hj13so1951539wib.6
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 10:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=pWwtonKfgGL/Q7aVD1wr12lPZF5fC4RuFDytVGjGaZs=;
	b=kYZwZ64GypeqpAm5tmWaJuHUCMSh0s3XIl2BBjA9WDotRQaI4eqYSkcJ7FkqP/6mRt
	n4JT2B8p6qHnLp8A4v72HDzE8wBl43t+S4xC/a1nSTOGMPbKzMoGzKTS89+DtKcN3bPu
	o2bbanIM2UTfjWWcNDvPeDg1f/3Wpo52B1YqzUeCfmlYx8h4TrxQJYPZn/vuFM5nP8t1
	Sci84/8HveJNFABdVo6+Mz/EZQsYCmjkLqZziPS3Toy5VNer0vByUdMWDOb3CvceoxwA
	QWUPIe5SwJ+7ih+OPeu3XbnPSa5Hz8WCzLKlJqeerdzjDaFV1YFXwZHIa8hd6oaxcCHr
	WhgA==
MIME-Version: 1.0
Received: by 10.216.132.202 with SMTP id o52mr1956262wei.106.1334250382327;
	Thu, 12 Apr 2012 10:06:22 -0700 (PDT)
Received: by 10.180.85.103 with HTTP; Thu, 12 Apr 2012 10:06:22 -0700 (PDT)
Date: Thu, 12 Apr 2012 13:06:22 -0400
Message-ID: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: Wei Wang <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: [Xen-devel] Understanding AMD NPT in xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Wei,
I have read you slides in xen summit 2007 about NPT in AMD, "AMD
Barcelona and Nested Paging Support in Xen".
However, I have some question regarding the nested page walk in your slide 8.

In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
I assume that it use the [47:39] bit of gVA.
However, in another AMD white paper, "AMD-VTM Nested Paging".
http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
In its figure 4, I saw that the first step is to translate gCR3 using
nested page walk and then combine with the gVA[47:39] to read the
table entry.

These two documents look having different order of reading the guest
page table. In the slides, it first get_PML4. But in the white paper,
it first does nested page walk.
I am wondering which one is true. Thanks.

- ha

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 18:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 18:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIOok-0004l4-G2; Thu, 12 Apr 2012 18:32:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIOoi-0004kz-Up
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 18:32:25 +0000
Received: from [85.158.139.83:20665] by server-1.bemta-5.messagelabs.com id
	03/56-28458-7BF178F4; Thu, 12 Apr 2012 18:32:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334255542!23487194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27617 invoked from network); 12 Apr 2012 18:32:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 18:32:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330905600"; d="scan'208";a="11910710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 18:32:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 19:32:22 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIOof-00010u-Od;
	Thu, 12 Apr 2012 18:32:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIOof-0001RL-LM;
	Thu, 12 Apr 2012 19:32:21 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12655-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 19:32:21 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12655: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12655 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12655/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12632
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12632

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857
baseline version:
 linux                e63089b08140adea85d011da136c7b56d73296ee

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit d935d0f77650fea53986811ca8a2f8c726fd9857
Merge: 5b0f440... d48fc63...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Thu Apr 12 08:22:38 2012 +0200

    Merge branch 'timers/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 18:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 18:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIOok-0004l4-G2; Thu, 12 Apr 2012 18:32:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIOoi-0004kz-Up
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 18:32:25 +0000
Received: from [85.158.139.83:20665] by server-1.bemta-5.messagelabs.com id
	03/56-28458-7BF178F4; Thu, 12 Apr 2012 18:32:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334255542!23487194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27617 invoked from network); 12 Apr 2012 18:32:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 18:32:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330905600"; d="scan'208";a="11910710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 18:32:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 19:32:22 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIOof-00010u-Od;
	Thu, 12 Apr 2012 18:32:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIOof-0001RL-LM;
	Thu, 12 Apr 2012 19:32:21 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12655-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 19:32:21 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12655: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12655 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12655/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12632
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12632

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857
baseline version:
 linux                e63089b08140adea85d011da136c7b56d73296ee

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit d935d0f77650fea53986811ca8a2f8c726fd9857
Merge: 5b0f440... d48fc63...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Thu Apr 12 08:22:38 2012 +0200

    Merge branch 'timers/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 19:23:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 19:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIPbH-00058w-Cx; Thu, 12 Apr 2012 19:22:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIPbF-00058r-Io
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 19:22:34 +0000
Received: from [85.158.143.99:24017] by server-3.bemta-4.messagelabs.com id
	03/42-05853-87B278F4; Thu, 12 Apr 2012 19:22:32 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334258551!13772629!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_60_70,HTML_MESSAGE,MIME_BASE64_TEXT,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9237 invoked from network); 12 Apr 2012 19:22:31 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 19:22:31 -0000
Received: by bkcjg9 with SMTP id jg9so2236114bkc.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 12:22:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:content-type:x-gm-message-state;
	bh=MPfHWlmMDQJ0jVNqKgBWrMiipbYsuebPcguGk/jdKFM=;
	b=ZpxlHAcjaLuFxG+BDM3BXqlqvsiQwBH5x5DyXKOxB1i7jyeSR4Q3GEU1HnYXSgWD3H
	yn4dTlcu6MOggcT03LRq2/cZRCydzfZAcURTnM7BJD92Hfh9idflcVDPKbmBHAgYlFiW
	bKkCY8G1QMS2w9VhAlTWTyIydZ+JuIz4fov7lAjChMBBYNQSooeQctp+z3KyK9m8XrWL
	uUgbX4woYBfoH0KXVg20RclM1cvdpta25PTjZKDopSQyrfmMQ07f4Ou+G0zoaD+o/npa
	yYYjlL81wIhH4WTHxBygOtrVVIxP3pJjboBtuzAEvN9TxnLn/E3CAlN2yUN2TD0LsJRW
	RECg==
MIME-Version: 1.0
Received: by 10.204.149.204 with SMTP id u12mr1139246bkv.45.1334258550925;
	Thu, 12 Apr 2012 12:22:30 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Thu, 12 Apr 2012 12:22:30 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
Date: Thu, 12 Apr 2012 12:22:30 -0700
Message-ID: <CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: xen-devel@lists.xen.org, keir@xen.org, jeremy@goop.org
Content-Type: multipart/mixed; boundary=0015175dd944f76aa804bd80469c
X-Gm-Message-State: ALoCoQkUu2sUQXQvWM4CB33H8+jra3BFrP0meUnxLhOjyiia+bNGYDKiAOH9lFuNEMlZNIgTiUvy
Subject: [Xen-devel] Debian stable kernel got timer issue when running as PV
	guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--0015175dd944f76aa804bd80469c
Content-Type: multipart/alternative; boundary=0015175dd944f76aa304bd80469a

--0015175dd944f76aa304bd80469a
Content-Type: text/plain; charset=ISO-8859-1

(Sorry for duplicate mail, got a typo in the mailing list address...)

Hi,

Recently we got some reports of Debian(2.6.32-41 package) migration hang on
some certain machines. I've identified one issue in Xen, but I think there
is probably another issue in the kernel.

Here is the case.

[    0.000000] Booting paravirtualized kernel on Xen



[    0.000000] Xen version: 3.4.2 (preserve-AD)



[    0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1 nr_node_ids:1



[    0.000000] PERCPU: Embedded 15 pages/cpu @c1608000 s37656 r0 d23784
u65536


[    0.000000] pcpu-alloc: s37656 r0 d23784 u65536 alloc=16*4096



[    0.000000] pcpu-alloc: [0] 0



[508119.807590] trying to map vcpu_info 0 at c1609010, mfn 992cac, offset
16


[508119.807593] cpu 0 using vcpu_info at c1609010



[508119.807594] Xen: using vcpu_info placement



[508119.807598] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 32416

Dmesg show that when booting, timestamp of printk jumped from 0 to a big
number([508119.807590] in this case) immediately.

And when migrating:

[509508.914333] suspending xenstore...



[516212.055921] trying to map vcpu_info 0 at c1609010, mfn 895fd7, offset
16


[516212.055930] cpu 0 using vcpu_info at c1609010

Timestamp jumped again. We can reproduce above issues on our Sandy Bridge
machines.

After this, call trace and guest hang maybe observed on some machines:

[516383.019499] INFO: task xenwatch:12 blocked for more than 120 seconds.



[516383.019566] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.


[516383.019578] xenwatch      D c1610e20     0    12      2 0x00000000



[516383.019591]  c781eec0 00000246 c1610e58 c1610e20 c781f300 c1441e20
c1441e20 001cf000


[516383.019605]  c781f07c c1610e20 00000000 00000001 c1441e20 c62e01c0
c1610e20 c62e01c0


[516383.019617]  c127e18e c781f07c c7830020 c7830020 c1441e20 c1441e20
c127f2f1 c781f080


[516383.019629] Call Trace:



[516383.019640]  [<c127e18e>] ? schedule+0x78f/0x7dc



[516383.019645]  [<c127f2f1>] ? _spin_unlock_irqrestore+0xd/0xf



[516383.019649]  [<c127e4a1>] ? schedule_timeout+0x20/0xb0



[516383.019656]  [<c100573c>] ? xen_force_evtchn_callback+0xc/0x10



[516383.019660]  [<c127e3aa>] ? wait_for_common+0xa4/0x100



[516383.019665]  [<c1033315>] ? default_wake_function+0x0/0x8



[516383.019671]  [<c104a144>] ? kthread_stop+0x4f/0x8e



[516383.019675]  [<c1047883>] ? cleanup_workqueue_thread+0x3a/0x45



[516383.019679]  [<c1047903>] ? destroy_workqueue+0x56/0x85



[516383.019684]  [<c106a395>] ? stop_machine_destroy+0x23/0x37



[516383.019690]  [<c11962d8>] ? shutdown_handler+0x200/0x22f



[516383.019694]  [<c1197439>] ? xenwatch_thread+0xdc/0x103



[516383.019698]  [<c104a322>] ? autoremove_wake_function+0x0/0x2d



[516383.019701]  [<c119735d>] ? xenwatch_thread+0x0/0x103



[516383.019705]  [<c104a0f0>] ? kthread+0x61/0x66



[516383.019709]  [<c104a08f>] ? kthread+0x0/0x66



[516383.019714]  [<c1008d87>] ? kernel_thread_helper+0x7/0x10

But I cannot reproduce it call trace and hang on our Sandy Bridge.

I've spent some time to identify the timestamp jump issue, and
finally found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
called non-stop TSC). The present of the feature would enable a parameter
in the kernel named: sched_clock_stable. Seems this parameter is unable to
work with Xen's pvclock. If sched_clock_stable() is set, value returned by
xen_clocksource_read() would be returned as sched_clock_cpu() directly, but
CMIIW the value returned by xen_clocksource_read() is based on host(vcpu)
uptime rather than this VM's uptime, then result in the timestamp jump.

I've compiled a kernel, force sched_clock_stable=0, then it solved the
timestamp jump issue as expected. Luckily, seems it also solved the call
trace and guest hang issue as well.

Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I think
the issue can be easily reproduced using a Westmere or SandyBridge
machine(my old colleagues at Intel said the feature likely existed after
Nehalem) running newer version of PV guest, check the guest cpuinfo you
would see nonstop_tsc, and you would notice the abnormal timestamp of
printk.

Sorry I don't have a Xen unstable environment by hand now. But I think this
should be the case we saw.

BTW: the original environment is xen-3.4.2, but I found the feature remain
unmasked by latest xen-unstable tree.

--
regards
Yang, Sheng




-- 
--
regards
Yang, Sheng

--0015175dd944f76aa304bd80469a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPihTb3JyeSBmb3IgZHVwbGljYXRlIG1haWwsIGdvdCBh
IHR5cG8gaW4gdGhlIG1haWxpbmcgbGlzdCBhZGRyZXNzLi4uKTxicj48YnI+SGksPGRpdj48YnI+
PC9kaXY+PGRpdj5SZWNlbnRseSB3ZSBnb3Qgc29tZSByZXBvcnRzIG9mIERlYmlhbigyLjYuMzIt
NDEgcGFja2FnZSkgbWlncmF0aW9uIGhhbmcgb24gc29tZSBjZXJ0YWluIG1hY2hpbmVzLiBJJiMz
OTt2ZaBpZGVudGlmaWVkoG9uZSBpc3N1ZSBpbiBYZW4sIGJ1dCBJIHRoaW5rIHRoZXJlIGlzIHBy
b2JhYmx5IGFub3RoZXIgaXNzdWUgaW4gdGhlIGtlcm5lbC48L2Rpdj4KCjxkaXY+PGJyPjwvZGl2
PjxkaXY+SGVyZSBpcyB0aGUgY2FzZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+WyCg
IKAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbiCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2PlsgoCCgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uOiAzLjQu
MiAocHJlc2VydmUtQUQpIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bIKAg
oDAuMDAwMDAwXSBOUl9DUFVTOjMyIG5yX2NwdW1hc2tfYml0czozMiBucl9jcHVfaWRzOjEgbnJf
bm9kZV9pZHM6MSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKA8L2Rpdj4KCjxkaXY+WyCgIKAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAx
NSBwYWdlcy9jcHUgQGMxNjA4MDAwIHMzNzY1NiByMCBkMjM3ODQgdTY1NTM2IKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2PlsgoCCg
MC4wMDAwMDBdIHBjcHUtYWxsb2M6IHMzNzY1NiByMCBkMjM3ODQgdTY1NTM2IGFsbG9jPTE2KjQw
OTYgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgoDwvZGl2PgoKPGRpdj5bIKAgoDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUwODEx
OS44MDc1OTBdIHRyeWluZyB0byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkwMTAsIG1mbiA5OTJj
YWMsIG9mZnNldCAxNiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MDgxMTkuODA3NTkzXSBjcHUgMCB1c2luZyB2Y3B1X2lu
Zm8gYXQgYzE2MDkwMTAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTA4MTE5
LjgwNzU5NF0gWGVuOiB1c2luZyB2Y3B1X2luZm8gcGxhY2VtZW50IKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUwODExOS44MDc1OThdIEJ1aWx0IDEgem9uZWxpc3RzIGlu
IFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiCgVG90YWwgcGFnZXM6IDMyNDE2IKCg
PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5EbWVzZyBzaG93IHRoYXQgd2hlbiBib290
aW5nLCB0aW1lc3RhbXAgb2YgcHJpbnRrIGp1bXBlZCBmcm9tIDAgdG8gYSBiaWcgbnVtYmVyKFs1
MDgxMTkuODA3NTkwXSBpbiB0aGlzIGNhc2UpIGltbWVkaWF0ZWx5LqA8L2Rpdj4KCjxkaXY+PGJy
PjwvZGl2PjxkaXY+QW5kIHdoZW4gbWlncmF0aW5nOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+
PGRpdj5bNTA5NTA4LjkxNDMzM10gc3VzcGVuZGluZyB4ZW5zdG9yZS4uLiCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjIxMi4wNTU5MjFdIHRyeWluZyB0
byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkwMTAsIG1mbiA4OTVmZDcsIG9mZnNldCAxNiCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8
ZGl2Pls1MTYyMTIuMDU1OTMwXSBjcHUgMCB1c2luZyB2Y3B1X2luZm8gYXQgYzE2MDkwMTA8L2Rp
dj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRpbWVzdGFtcCBqdW1wZWQgYWdhaW4uIFdlIGNh
biByZXByb2R1Y2UgYWJvdmUgaXNzdWVzIG9uIG91ciBTYW5keSBCcmlkZ2UgbWFjaGluZXMuPC9k
aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BZnRlciB0aGlzLCBjYWxsIHRyYWNlIGFuZCBndWVzdCBo
YW5nIG1heWJlIG9ic2VydmVkIG9uIHNvbWUgbWFjaGluZXM6PC9kaXY+Cgo8ZGl2Pjxicj48L2Rp
dj48ZGl2PjxkaXY+WzUxNjM4My4wMTk0OTldIElORk86IHRhc2sgeGVud2F0Y2g6MTIgYmxvY2tl
ZCBmb3IgbW9yZSB0aGFuIDEyMCBzZWNvbmRzLiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5NTY2XSAm
cXVvdDtlY2hvIDAgJmd0OyAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3Mm
cXVvdDsgZGlzYWJsZXMgdGhpcyBtZXNzYWdlLiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk1NzhdIHhlbndhdGNoIKAgoCCgRCBj
MTYxMGUyMCCgIKAgMCCgIKAxMiCgIKAgoDIgMHgwMDAwMDAwMCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYz
ODMuMDE5NTkxXSCgYzc4MWVlYzAgMDAwMDAyNDYgYzE2MTBlNTggYzE2MTBlMjAgYzc4MWYzMDAg
YzE0NDFlMjAgYzE0NDFlMjAgMDAxY2YwMDAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTYwNV0goGM3ODFmMDdjIGMxNjEwZTIw
IDAwMDAwMDAwIDAwMDAwMDAxIGMxNDQxZTIwIGM2MmUwMWMwIGMxNjEwZTIwIGM2MmUwMWMwIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4
My4wMTk2MTddIKBjMTI3ZTE4ZSBjNzgxZjA3YyBjNzgzMDAyMCBjNzgzMDAyMCBjMTQ0MWUyMCBj
MTQ0MWUyMCBjMTI3ZjJmMSBjNzgxZjA4MCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5NjI5XSBDYWxsIFRyYWNlOiCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTE2Mzgz
LjAxOTY0MF0goFsmbHQ7YzEyN2UxOGUmZ3Q7XSA/IHNjaGVkdWxlKzB4NzhmLzB4N2RjIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk2NDVdIKBbJmx0O2MxMjdmMmYx
Jmd0O10gPyBfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSsweGQvMHhmIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+Cgo8
ZGl2Pls1MTYzODMuMDE5NjQ5XSCgWyZsdDtjMTI3ZTRhMSZndDtdID8gc2NoZWR1bGVfdGltZW91
dCsweDIwLzB4YjAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTY1Nl0goFsm
bHQ7YzEwMDU3M2MmZ3Q7XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhjLzB4MTAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk2NjBdIKBbJmx0O2MxMjdlM2FhJmd0O10gPyB3YWl0
X2Zvcl9jb21tb24rMHhhNC8weDEwMCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMu
MDE5NjY1XSCgWyZsdDtjMTAzMzMxNSZndDtdID8gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8w
eDggoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTY3MV0goFsmbHQ7YzEwNGExNDQm
Z3Q7XSA/IGt0aHJlYWRfc3RvcCsweDRmLzB4OGUgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxk
aXY+WzUxNjM4My4wMTk2NzVdIKBbJmx0O2MxMDQ3ODgzJmd0O10gPyBjbGVhbnVwX3dvcmtxdWV1
ZV90aHJlYWQrMHgzYS8weDQ1IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5Njc5XSCgWyZs
dDtjMTA0NzkwMyZndDtdID8gZGVzdHJveV93b3JrcXVldWUrMHg1Ni8weDg1IKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTY4NF0goFsmbHQ7YzEwNmEzOTUmZ3Q7XSA/IHN0b3Bf
bWFjaGluZV9kZXN0cm95KzB4MjMvMHgzNyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4w
MTk2OTBdIKBbJmx0O2MxMTk2MmQ4Jmd0O10gPyBzaHV0ZG93bl9oYW5kbGVyKzB4MjAwLzB4MjJm
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5Njk0XSCgWyZsdDtjMTE5NzQzOSZn
dDtdID8geGVud2F0Y2hfdGhyZWFkKzB4ZGMvMHgxMDMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2PgoKPGRp
dj5bNTE2MzgzLjAxOTY5OF0goFsmbHQ7YzEwNGEzMjImZ3Q7XSA/IGF1dG9yZW1vdmVfd2FrZV9m
dW5jdGlvbisweDAvMHgyZCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk3MDFdIKBbJmx0
O2MxMTk3MzVkJmd0O10gPyB4ZW53YXRjaF90aHJlYWQrMHgwLzB4MTAzIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
PC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5NzA1XSCgWyZsdDtjMTA0YTBmMCZndDtdID8ga3RocmVh
ZCsweDYxLzB4NjYgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAx
OTcwOV0goFsmbHQ7YzEwNGEwOGYmZ3Q7XSA/IGt0aHJlYWQrMHgwLzB4NjYgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk3MTRdIKBbJmx0O2MxMDA4ZDg3Jmd0
O10gPyBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDcvMHgxMCCgPC9kaXY+PC9kaXY+PGRpdj48YnI+
PC9kaXY+PGRpdj5CdXQgSSBjYW5ub3QgcmVwcm9kdWNlIGl0IGNhbGwgdHJhY2UgYW5kIGhhbmcg
b24gb3VyIFNhbmR5IEJyaWRnZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkmIzM5O3ZlIHNw
ZW50IHNvbWUgdGltZSB0byBpZGVudGlmeSB0aGUgdGltZXN0YW1wIGp1bXAgaXNzdWUsIGFuZCBm
aW5hbGx5oGZvdW5kIGl0JiMzOTtzIGR1ZSB0byBJbnZhcmllbnQgVFNDIChDUFVJRCBMZWFmIDB4
ODAwMDAwMDegRURYOjgsIGFsc28gY2FsbGVkIG5vbi1zdG9wIFRTQykuIFRoZSBwcmVzZW50IG9m
IHRoZSBmZWF0dXJlIHdvdWxkIGVuYWJsZSBhoHBhcmFtZXRlciBpbiB0aGUga2VybmVsIG5hbWVk
OiBzY2hlZF9jbG9ja19zdGFibGUuoFNlZW1zIHRoaXMgcGFyYW1ldGVyIGlzoHVuYWJsZSB0byB3
b3JrIHdpdGggWGVuJiMzOTtzIHB2Y2xvY2suIElmIHNjaGVkX2Nsb2NrX3N0YWJsZSgpIGlzIHNl
dCwgdmFsdWUgcmV0dXJuZWQgYnkgeGVuX2Nsb2Nrc291cmNlX3JlYWQoKSB3b3VsZCBiZSByZXR1
cm5lZCBhcyBzY2hlZF9jbG9ja19jcHUoKSBkaXJlY3RseSwgYnV0IENNSUlXIHRoZSB2YWx1ZSBy
ZXR1cm5lZCBieSB4ZW5fY2xvY2tzb3VyY2VfcmVhZCgpIGlzIGJhc2VkIG9uIGhvc3QodmNwdSkg
dXB0aW1lIHJhdGhlciB0aGFuIHRoaXMgVk0mIzM5O3MgdXB0aW1lLCB0aGVuIHJlc3VsdCBpbiB0
aGUgdGltZXN0YW1wIGp1bXAuPC9kaXY+Cgo8ZGl2Pjxicj48L2Rpdj48ZGl2PkkmIzM5O3ZlIGNv
bXBpbGVkIGEga2VybmVsLKBmb3JjZSBzY2hlZF9jbG9ja19zdGFibGU9MCwgdGhlbiBpdCBzb2x2
ZWQgdGhlIHRpbWVzdGFtcCBqdW1wIGlzc3VlIGFzIGV4cGVjdGVkLiBMdWNraWx5LCBzZWVtcyBp
dCBhbHNvIHNvbHZlZCB0aGUgY2FsbCB0cmFjZSBhbmQgZ3Vlc3QgaGFuZyBpc3N1ZSBhcyB3ZWxs
LjwvZGl2PjxkaXY+PGJyPjwvZGl2PgoKPGRpdj5BdHRhY2htZW50IGlzIGEgKHVudGVzdGVkKSBw
YXRjaCB0byBtYXNrIHRoZSBDUFVJRCBsZWFmIDB4ODAwMDAwMDcuIEkgdGhpbmsgdGhlIGlzc3Vl
IGNhbiBiZSBlYXNpbHkgcmVwcm9kdWNlZCB1c2luZyBhIFdlc3RtZXJlIG9yIFNhbmR5QnJpZGdl
IG1hY2hpbmUobXkgb2xkIGNvbGxlYWd1ZXMgYXQgSW50ZWwgc2FpZCB0aGUgZmVhdHVyZSBsaWtl
bHkgZXhpc3RlZCBhZnRlciBOZWhhbGVtKSBydW5uaW5nIG5ld2VyIHZlcnNpb24gb2YgUFYgZ3Vl
c3QsIGNoZWNrIHRoZSBndWVzdCBjcHVpbmZvIHlvdSB3b3VsZCBzZWUgbm9uc3RvcF90c2MsIGFu
ZCB5b3Ugd291bGQgbm90aWNlIHRoZSBhYm5vcm1hbCB0aW1lc3RhbXAgb2YgcHJpbnRrLjwvZGl2
PgoKPGRpdj48YnI+PC9kaXY+PGRpdj5Tb3JyeSBJIGRvbiYjMzk7dCBoYXZlIGEgWGVuIHVuc3Rh
YmxlIGVudmlyb25tZW50IGJ5IGhhbmQgbm93LiBCdXQgSSB0aGluayB0aGlzIHNob3VsZCBiZSB0
aGUgY2FzZSB3ZSBzYXcuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CVFc6IHRoZSBvcmlnaW5h
bCBlbnZpcm9ubWVudCBpcyB4ZW4tMy40LjIsIGJ1dCBJIGZvdW5kIHRoZSBmZWF0dXJlIHJlbWFp
biB1bm1hc2tlZCBieSBsYXRlc3QgeGVuLXVuc3RhYmxlIHRyZWUuPC9kaXY+Cgo8ZGl2PjxkaXY+
PGJyPjwvZGl2Pi0tPGRpdj5yZWdhcmRzPC9kaXY+PHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQg
Y29sb3I9IiM4ODg4ODgiPjxkaXY+WWFuZywgU2hlbmc8L2Rpdj48YnI+CjwvZm9udD48L3NwYW4+
PC9kaXY+CjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGRpdj48YnI+PC9kaXY+LS0gPGJyPi0t
PGRpdj5yZWdhcmRzPC9kaXY+PGRpdj5ZYW5nLCBTaGVuZzwvZGl2Pjxicj4K
--0015175dd944f76aa304bd80469a--
--0015175dd944f76aa804bd80469c
Content-Type: application/octet-stream; 
	name="0001-libxc-disable-invarient-TSC-for-PV-guest.patch"
Content-Disposition: attachment; 
	filename="0001-libxc-disable-invarient-TSC-for-PV-guest.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0y6smvf0

RnJvbSBhODAwMDg5YmM3YzA1MDgxYTRkMmYwOWVhODZlYWU1MmVjYTVhYjdlIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBTaGVuZyBZYW5nIDxzaGVuZy55YW5nQGNpdHJpeC5jb20+CkRh
dGU6IFdlZCwgMTEgQXByIDIwMTIgMTU6NDc6MjQgLTA3MDAKU3ViamVjdDogW1BBVENIXSBsaWJ4
YzogZGlzYWJsZSBpbnZhcmllbnQgVFNDIGZvciBQViBndWVzdAoKV2UgZ290IHRoZSBmb2xsb3dp
bmcgZG1lc2cgaW4gdGhlIERlYmlhbiA2LjAncyBsYXRlc3Qga2VybmVscyhkZWJpYW4gcGFja2Fn
ZQoyLjYuMzItNDEsIGFuZCAzLjIuMC0yKSwgcnVubmluZyBhcyBQViBndWVzdCBvbiBpbnZhcmll
bnQobm9uLXN0b3ApIFRTQyBjYXBhYmxlCm1hY2hpbmUuCgpCb290aW5nOgoKWyAgICAwLjAwMDAw
MF0gWGVuIHZlcnNpb246IDMuNC4yIChwcmVzZXJ2ZS1BRCkKWyAgICAwLjAwMDAwMF0gTlJfQ1BV
UzozMiBucl9jcHVtYXNrX2JpdHM6MzIgbnJfY3B1X2lkczoxIG5yX25vZGVfaWRzOjEKWyAgICAw
LjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAxNSBwYWdlcy9jcHUgQGMxNjA4MDAwIHMzNzY1NiBy
MCBkMjM3ODQgdTY1NTM2ClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IHMzNzY1NiByMCBkMjM3
ODQgdTY1NTM2IGFsbG9jPTE2KjQwOTYKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogWzBdIDAK
WzUwODExOS44MDc1OTBdIHRyeWluZyB0byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkwMTAsIG1m
biA5OTJjYWMsIG9mZnNldCAxNgpbNTA4MTE5LjgwNzU5M10gY3B1IDAgdXNpbmcgdmNwdV9pbmZv
IGF0IGMxNjA5MDEwCls1MDgxMTkuODA3NTk0XSBYZW46IHVzaW5nIHZjcHVfaW5mbyBwbGFjZW1l
bnQKWzUwODExOS44MDc1OThdIEJ1aWx0IDEgem9uZWxpc3RzIGluIFpvbmUgb3JkZXIsIG1vYmls
aXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDMyNDE2CgpUaW1lIGp1bXBlZCBmcm9tIFsw
LjAwMDAwMF0gdG8gWzUwODExOS44MDc1OTBdLgoKTWlncmF0aW9uOgoKWzUwODEyNS4xNDEzMDBd
IGlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCls1MDgxMzUuMzg1
ODU0XSBldGgwOiBubyBJUHY2IHJvdXRlcnMgcHJlc2VudApbNTA4MTM1Ljc0NTg2M10gZXRoMTog
bm8gSVB2NiByb3V0ZXJzIHByZXNlbnQKWzUwOTUwOC45MTQzMzNdIHN1c3BlbmRpbmcgeGVuc3Rv
cmUuLi4KWzUxNjIxMi4wNTU5MjFdIHRyeWluZyB0byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkw
MTAsIG1mbiA4OTVmZDcsIG9mZnNldCAxNgpbNTE2MjEyLjA1NTkzMF0gY3B1IDAgdXNpbmcgdmNw
dV9pbmZvIGF0IGMxNjA5MDEwCgpUaW1lIGp1bXBlZCBmcm9tIFs1MDk1MDguOTE0MzMzXShiZWZv
cmUgbWlncmF0aW9uKSB0byBbNTE2MjEyLjA1NTkyMV0oYWZ0ZXIKbWlncmF0aW9uKS4KClRoZSBh
Ym92ZSBpc3N1ZSBjYW4gYmUgcmVwcm9kdWNlZCB1c2luZyBvdXIgU2FuZHlCcmlkZ2UgbWFjaGlu
ZS4KCkFmdGVyIGludmVzdGlnYXRpb24sIEkgZm91bmQgaXQncyBkdWUgdG8gSW52YXJpZW50IFRT
QyAoQ1BVSUQgTGVhZiAweDgwMDAwMDA3CkVEWDo4LCBhbHNvIGNhbGxlZCBub24tc3RvcCBUU0Mp
LiBUaGUgcHJlc2VudCBvZiB0aGUgZmVhdHVyZSB3b3VsZCBlbmFibGUgYQpwYXJhbWV0ZXIgaW4g
dGhlIGtlcm5lbCBuYW1lZDogc2NoZWRfY2xvY2tfc3RhYmxlLiAgU2VlbXMgdGhpcyBwYXJhbWV0
ZXIgaXMKdW5hYmxlIHRvIHdvcmsgd2l0aCBYZW4ncyBwdmNsb2NrLgoKVGhlIHBhdGNoIHdvdWxk
IGRpc2FibGUgbm9uLXN0b3AgVFNDIGZvciBQViBndWVzdCwgdGh1cyBmaXggdGhpcyB0aW1lc3Rh
bXAKaXNzdWUuCgpUaGlzIGlzc3VlIHBvdGVudGlhbGx5IGNhdXNlZCBndWVzdCBoYW5nIHdoZW4g
cnVubmluZyB3aXRoIGRlYmlhbiBrZXJuZWwKMi42LjMyLTQxLCBidXQgd2UgY2Fubm90IHJlcHJv
ZHVjZSB0aGUgaGFuZyBpbiBvdXIgZW52aXJvbm1lbnQuIFRoZXJlIGFyZSBtYXliZQpvdGhlciBr
ZXJuZWwgYnVncyB0aGVyZS4KClNpZ25lZC1vZmYtYnk6IFNoZW5nIFlhbmcgPHNoZW5nLnlhbmdA
Y2l0cml4LmNvbT4KLS0tCiB0b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYyB8ICAgIDEgKwogMSBm
aWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMgYi90b29scy9saWJ4Yy94Y19jcHVpZF94ODYu
YwppbmRleCAwODgyY2U2Li5hMDI4NDA3IDEwMDY0NAotLS0gYS90b29scy9saWJ4Yy94Y19jcHVp
ZF94ODYuYworKysgYi90b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYwpAQCAtNTQxLDYgKzU0MSw3
IEBAIHN0YXRpYyB2b2lkIHhjX2NwdWlkX3B2X3BvbGljeSgKICAgICBjYXNlIDB4MDAwMDAwMDU6
IC8qIE1PTklUT1IvTVdBSVQgKi8KICAgICBjYXNlIDB4MDAwMDAwMGE6IC8qIEFyY2hpdGVjdHVy
YWwgUGVyZm9ybWFuY2UgTW9uaXRvciBGZWF0dXJlcyAqLwogICAgIGNhc2UgMHgwMDAwMDAwYjog
LyogRXh0ZW5kZWQgVG9wb2xvZ3kgRW51bWVyYXRpb24gKi8KKyAgICBjYXNlIDB4ODAwMDAwMDc6
IC8qIEludmFyaWFudCBUU0MgKi8KICAgICBjYXNlIDB4ODAwMDAwMGE6IC8qIFNWTSByZXZpc2lv
biBhbmQgZmVhdHVyZXMgKi8KICAgICBjYXNlIDB4ODAwMDAwMWI6IC8qIEluc3RydWN0aW9uIEJh
c2VkIFNhbXBsaW5nICovCiAgICAgY2FzZSAweDgwMDAwMDFjOiAvKiBMaWdodCBXZWlnaHQgUHJv
ZmlsaW5nICovCi0tIAoxLjcuNS40Cgo=
--0015175dd944f76aa804bd80469c
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--0015175dd944f76aa804bd80469c--


From xen-devel-bounces@lists.xen.org Thu Apr 12 19:23:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 19:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIPbH-00058w-Cx; Thu, 12 Apr 2012 19:22:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIPbF-00058r-Io
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 19:22:34 +0000
Received: from [85.158.143.99:24017] by server-3.bemta-4.messagelabs.com id
	03/42-05853-87B278F4; Thu, 12 Apr 2012 19:22:32 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334258551!13772629!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_60_70,HTML_MESSAGE,MIME_BASE64_TEXT,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9237 invoked from network); 12 Apr 2012 19:22:31 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 19:22:31 -0000
Received: by bkcjg9 with SMTP id jg9so2236114bkc.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 12:22:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:content-type:x-gm-message-state;
	bh=MPfHWlmMDQJ0jVNqKgBWrMiipbYsuebPcguGk/jdKFM=;
	b=ZpxlHAcjaLuFxG+BDM3BXqlqvsiQwBH5x5DyXKOxB1i7jyeSR4Q3GEU1HnYXSgWD3H
	yn4dTlcu6MOggcT03LRq2/cZRCydzfZAcURTnM7BJD92Hfh9idflcVDPKbmBHAgYlFiW
	bKkCY8G1QMS2w9VhAlTWTyIydZ+JuIz4fov7lAjChMBBYNQSooeQctp+z3KyK9m8XrWL
	uUgbX4woYBfoH0KXVg20RclM1cvdpta25PTjZKDopSQyrfmMQ07f4Ou+G0zoaD+o/npa
	yYYjlL81wIhH4WTHxBygOtrVVIxP3pJjboBtuzAEvN9TxnLn/E3CAlN2yUN2TD0LsJRW
	RECg==
MIME-Version: 1.0
Received: by 10.204.149.204 with SMTP id u12mr1139246bkv.45.1334258550925;
	Thu, 12 Apr 2012 12:22:30 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Thu, 12 Apr 2012 12:22:30 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
Date: Thu, 12 Apr 2012 12:22:30 -0700
Message-ID: <CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: xen-devel@lists.xen.org, keir@xen.org, jeremy@goop.org
Content-Type: multipart/mixed; boundary=0015175dd944f76aa804bd80469c
X-Gm-Message-State: ALoCoQkUu2sUQXQvWM4CB33H8+jra3BFrP0meUnxLhOjyiia+bNGYDKiAOH9lFuNEMlZNIgTiUvy
Subject: [Xen-devel] Debian stable kernel got timer issue when running as PV
	guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--0015175dd944f76aa804bd80469c
Content-Type: multipart/alternative; boundary=0015175dd944f76aa304bd80469a

--0015175dd944f76aa304bd80469a
Content-Type: text/plain; charset=ISO-8859-1

(Sorry for duplicate mail, got a typo in the mailing list address...)

Hi,

Recently we got some reports of Debian(2.6.32-41 package) migration hang on
some certain machines. I've identified one issue in Xen, but I think there
is probably another issue in the kernel.

Here is the case.

[    0.000000] Booting paravirtualized kernel on Xen



[    0.000000] Xen version: 3.4.2 (preserve-AD)



[    0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1 nr_node_ids:1



[    0.000000] PERCPU: Embedded 15 pages/cpu @c1608000 s37656 r0 d23784
u65536


[    0.000000] pcpu-alloc: s37656 r0 d23784 u65536 alloc=16*4096



[    0.000000] pcpu-alloc: [0] 0



[508119.807590] trying to map vcpu_info 0 at c1609010, mfn 992cac, offset
16


[508119.807593] cpu 0 using vcpu_info at c1609010



[508119.807594] Xen: using vcpu_info placement



[508119.807598] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 32416

Dmesg show that when booting, timestamp of printk jumped from 0 to a big
number([508119.807590] in this case) immediately.

And when migrating:

[509508.914333] suspending xenstore...



[516212.055921] trying to map vcpu_info 0 at c1609010, mfn 895fd7, offset
16


[516212.055930] cpu 0 using vcpu_info at c1609010

Timestamp jumped again. We can reproduce above issues on our Sandy Bridge
machines.

After this, call trace and guest hang maybe observed on some machines:

[516383.019499] INFO: task xenwatch:12 blocked for more than 120 seconds.



[516383.019566] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.


[516383.019578] xenwatch      D c1610e20     0    12      2 0x00000000



[516383.019591]  c781eec0 00000246 c1610e58 c1610e20 c781f300 c1441e20
c1441e20 001cf000


[516383.019605]  c781f07c c1610e20 00000000 00000001 c1441e20 c62e01c0
c1610e20 c62e01c0


[516383.019617]  c127e18e c781f07c c7830020 c7830020 c1441e20 c1441e20
c127f2f1 c781f080


[516383.019629] Call Trace:



[516383.019640]  [<c127e18e>] ? schedule+0x78f/0x7dc



[516383.019645]  [<c127f2f1>] ? _spin_unlock_irqrestore+0xd/0xf



[516383.019649]  [<c127e4a1>] ? schedule_timeout+0x20/0xb0



[516383.019656]  [<c100573c>] ? xen_force_evtchn_callback+0xc/0x10



[516383.019660]  [<c127e3aa>] ? wait_for_common+0xa4/0x100



[516383.019665]  [<c1033315>] ? default_wake_function+0x0/0x8



[516383.019671]  [<c104a144>] ? kthread_stop+0x4f/0x8e



[516383.019675]  [<c1047883>] ? cleanup_workqueue_thread+0x3a/0x45



[516383.019679]  [<c1047903>] ? destroy_workqueue+0x56/0x85



[516383.019684]  [<c106a395>] ? stop_machine_destroy+0x23/0x37



[516383.019690]  [<c11962d8>] ? shutdown_handler+0x200/0x22f



[516383.019694]  [<c1197439>] ? xenwatch_thread+0xdc/0x103



[516383.019698]  [<c104a322>] ? autoremove_wake_function+0x0/0x2d



[516383.019701]  [<c119735d>] ? xenwatch_thread+0x0/0x103



[516383.019705]  [<c104a0f0>] ? kthread+0x61/0x66



[516383.019709]  [<c104a08f>] ? kthread+0x0/0x66



[516383.019714]  [<c1008d87>] ? kernel_thread_helper+0x7/0x10

But I cannot reproduce it call trace and hang on our Sandy Bridge.

I've spent some time to identify the timestamp jump issue, and
finally found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
called non-stop TSC). The present of the feature would enable a parameter
in the kernel named: sched_clock_stable. Seems this parameter is unable to
work with Xen's pvclock. If sched_clock_stable() is set, value returned by
xen_clocksource_read() would be returned as sched_clock_cpu() directly, but
CMIIW the value returned by xen_clocksource_read() is based on host(vcpu)
uptime rather than this VM's uptime, then result in the timestamp jump.

I've compiled a kernel, force sched_clock_stable=0, then it solved the
timestamp jump issue as expected. Luckily, seems it also solved the call
trace and guest hang issue as well.

Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I think
the issue can be easily reproduced using a Westmere or SandyBridge
machine(my old colleagues at Intel said the feature likely existed after
Nehalem) running newer version of PV guest, check the guest cpuinfo you
would see nonstop_tsc, and you would notice the abnormal timestamp of
printk.

Sorry I don't have a Xen unstable environment by hand now. But I think this
should be the case we saw.

BTW: the original environment is xen-3.4.2, but I found the feature remain
unmasked by latest xen-unstable tree.

--
regards
Yang, Sheng




-- 
--
regards
Yang, Sheng

--0015175dd944f76aa304bd80469a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPihTb3JyeSBmb3IgZHVwbGljYXRlIG1haWwsIGdvdCBh
IHR5cG8gaW4gdGhlIG1haWxpbmcgbGlzdCBhZGRyZXNzLi4uKTxicj48YnI+SGksPGRpdj48YnI+
PC9kaXY+PGRpdj5SZWNlbnRseSB3ZSBnb3Qgc29tZSByZXBvcnRzIG9mIERlYmlhbigyLjYuMzIt
NDEgcGFja2FnZSkgbWlncmF0aW9uIGhhbmcgb24gc29tZSBjZXJ0YWluIG1hY2hpbmVzLiBJJiMz
OTt2ZaBpZGVudGlmaWVkoG9uZSBpc3N1ZSBpbiBYZW4sIGJ1dCBJIHRoaW5rIHRoZXJlIGlzIHBy
b2JhYmx5IGFub3RoZXIgaXNzdWUgaW4gdGhlIGtlcm5lbC48L2Rpdj4KCjxkaXY+PGJyPjwvZGl2
PjxkaXY+SGVyZSBpcyB0aGUgY2FzZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+WyCg
IKAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbiCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2PlsgoCCgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uOiAzLjQu
MiAocHJlc2VydmUtQUQpIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bIKAg
oDAuMDAwMDAwXSBOUl9DUFVTOjMyIG5yX2NwdW1hc2tfYml0czozMiBucl9jcHVfaWRzOjEgbnJf
bm9kZV9pZHM6MSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKA8L2Rpdj4KCjxkaXY+WyCgIKAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAx
NSBwYWdlcy9jcHUgQGMxNjA4MDAwIHMzNzY1NiByMCBkMjM3ODQgdTY1NTM2IKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2PlsgoCCg
MC4wMDAwMDBdIHBjcHUtYWxsb2M6IHMzNzY1NiByMCBkMjM3ODQgdTY1NTM2IGFsbG9jPTE2KjQw
OTYgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgoDwvZGl2PgoKPGRpdj5bIKAgoDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUwODEx
OS44MDc1OTBdIHRyeWluZyB0byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkwMTAsIG1mbiA5OTJj
YWMsIG9mZnNldCAxNiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MDgxMTkuODA3NTkzXSBjcHUgMCB1c2luZyB2Y3B1X2lu
Zm8gYXQgYzE2MDkwMTAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTA4MTE5
LjgwNzU5NF0gWGVuOiB1c2luZyB2Y3B1X2luZm8gcGxhY2VtZW50IKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUwODExOS44MDc1OThdIEJ1aWx0IDEgem9uZWxpc3RzIGlu
IFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiCgVG90YWwgcGFnZXM6IDMyNDE2IKCg
PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5EbWVzZyBzaG93IHRoYXQgd2hlbiBib290
aW5nLCB0aW1lc3RhbXAgb2YgcHJpbnRrIGp1bXBlZCBmcm9tIDAgdG8gYSBiaWcgbnVtYmVyKFs1
MDgxMTkuODA3NTkwXSBpbiB0aGlzIGNhc2UpIGltbWVkaWF0ZWx5LqA8L2Rpdj4KCjxkaXY+PGJy
PjwvZGl2PjxkaXY+QW5kIHdoZW4gbWlncmF0aW5nOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+
PGRpdj5bNTA5NTA4LjkxNDMzM10gc3VzcGVuZGluZyB4ZW5zdG9yZS4uLiCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjIxMi4wNTU5MjFdIHRyeWluZyB0
byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkwMTAsIG1mbiA4OTVmZDcsIG9mZnNldCAxNiCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8
ZGl2Pls1MTYyMTIuMDU1OTMwXSBjcHUgMCB1c2luZyB2Y3B1X2luZm8gYXQgYzE2MDkwMTA8L2Rp
dj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRpbWVzdGFtcCBqdW1wZWQgYWdhaW4uIFdlIGNh
biByZXByb2R1Y2UgYWJvdmUgaXNzdWVzIG9uIG91ciBTYW5keSBCcmlkZ2UgbWFjaGluZXMuPC9k
aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BZnRlciB0aGlzLCBjYWxsIHRyYWNlIGFuZCBndWVzdCBo
YW5nIG1heWJlIG9ic2VydmVkIG9uIHNvbWUgbWFjaGluZXM6PC9kaXY+Cgo8ZGl2Pjxicj48L2Rp
dj48ZGl2PjxkaXY+WzUxNjM4My4wMTk0OTldIElORk86IHRhc2sgeGVud2F0Y2g6MTIgYmxvY2tl
ZCBmb3IgbW9yZSB0aGFuIDEyMCBzZWNvbmRzLiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5NTY2XSAm
cXVvdDtlY2hvIDAgJmd0OyAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3Mm
cXVvdDsgZGlzYWJsZXMgdGhpcyBtZXNzYWdlLiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk1NzhdIHhlbndhdGNoIKAgoCCgRCBj
MTYxMGUyMCCgIKAgMCCgIKAxMiCgIKAgoDIgMHgwMDAwMDAwMCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYz
ODMuMDE5NTkxXSCgYzc4MWVlYzAgMDAwMDAyNDYgYzE2MTBlNTggYzE2MTBlMjAgYzc4MWYzMDAg
YzE0NDFlMjAgYzE0NDFlMjAgMDAxY2YwMDAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTYwNV0goGM3ODFmMDdjIGMxNjEwZTIw
IDAwMDAwMDAwIDAwMDAwMDAxIGMxNDQxZTIwIGM2MmUwMWMwIGMxNjEwZTIwIGM2MmUwMWMwIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4
My4wMTk2MTddIKBjMTI3ZTE4ZSBjNzgxZjA3YyBjNzgzMDAyMCBjNzgzMDAyMCBjMTQ0MWUyMCBj
MTQ0MWUyMCBjMTI3ZjJmMSBjNzgxZjA4MCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5NjI5XSBDYWxsIFRyYWNlOiCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTE2Mzgz
LjAxOTY0MF0goFsmbHQ7YzEyN2UxOGUmZ3Q7XSA/IHNjaGVkdWxlKzB4NzhmLzB4N2RjIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk2NDVdIKBbJmx0O2MxMjdmMmYx
Jmd0O10gPyBfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSsweGQvMHhmIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+Cgo8
ZGl2Pls1MTYzODMuMDE5NjQ5XSCgWyZsdDtjMTI3ZTRhMSZndDtdID8gc2NoZWR1bGVfdGltZW91
dCsweDIwLzB4YjAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTY1Nl0goFsm
bHQ7YzEwMDU3M2MmZ3Q7XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhjLzB4MTAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk2NjBdIKBbJmx0O2MxMjdlM2FhJmd0O10gPyB3YWl0
X2Zvcl9jb21tb24rMHhhNC8weDEwMCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMu
MDE5NjY1XSCgWyZsdDtjMTAzMzMxNSZndDtdID8gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8w
eDggoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTY3MV0goFsmbHQ7YzEwNGExNDQm
Z3Q7XSA/IGt0aHJlYWRfc3RvcCsweDRmLzB4OGUgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxk
aXY+WzUxNjM4My4wMTk2NzVdIKBbJmx0O2MxMDQ3ODgzJmd0O10gPyBjbGVhbnVwX3dvcmtxdWV1
ZV90aHJlYWQrMHgzYS8weDQ1IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5Njc5XSCgWyZs
dDtjMTA0NzkwMyZndDtdID8gZGVzdHJveV93b3JrcXVldWUrMHg1Ni8weDg1IKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAxOTY4NF0goFsmbHQ7YzEwNmEzOTUmZ3Q7XSA/IHN0b3Bf
bWFjaGluZV9kZXN0cm95KzB4MjMvMHgzNyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4w
MTk2OTBdIKBbJmx0O2MxMTk2MmQ4Jmd0O10gPyBzaHV0ZG93bl9oYW5kbGVyKzB4MjAwLzB4MjJm
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKCgPC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5Njk0XSCgWyZsdDtjMTE5NzQzOSZn
dDtdID8geGVud2F0Y2hfdGhyZWFkKzB4ZGMvMHgxMDMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2PgoKPGRp
dj5bNTE2MzgzLjAxOTY5OF0goFsmbHQ7YzEwNGEzMjImZ3Q7XSA/IGF1dG9yZW1vdmVfd2FrZV9m
dW5jdGlvbisweDAvMHgyZCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk3MDFdIKBbJmx0
O2MxMTk3MzVkJmd0O10gPyB4ZW53YXRjaF90aHJlYWQrMHgwLzB4MTAzIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
PC9kaXY+Cgo8ZGl2Pls1MTYzODMuMDE5NzA1XSCgWyZsdDtjMTA0YTBmMCZndDtdID8ga3RocmVh
ZCsweDYxLzB4NjYgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2PgoKPGRpdj5bNTE2MzgzLjAx
OTcwOV0goFsmbHQ7YzEwNGEwOGYmZ3Q7XSA/IGt0aHJlYWQrMHgwLzB4NjYgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoKA8L2Rpdj4KCjxkaXY+WzUxNjM4My4wMTk3MTRdIKBbJmx0O2MxMDA4ZDg3Jmd0
O10gPyBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDcvMHgxMCCgPC9kaXY+PC9kaXY+PGRpdj48YnI+
PC9kaXY+PGRpdj5CdXQgSSBjYW5ub3QgcmVwcm9kdWNlIGl0IGNhbGwgdHJhY2UgYW5kIGhhbmcg
b24gb3VyIFNhbmR5IEJyaWRnZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkmIzM5O3ZlIHNw
ZW50IHNvbWUgdGltZSB0byBpZGVudGlmeSB0aGUgdGltZXN0YW1wIGp1bXAgaXNzdWUsIGFuZCBm
aW5hbGx5oGZvdW5kIGl0JiMzOTtzIGR1ZSB0byBJbnZhcmllbnQgVFNDIChDUFVJRCBMZWFmIDB4
ODAwMDAwMDegRURYOjgsIGFsc28gY2FsbGVkIG5vbi1zdG9wIFRTQykuIFRoZSBwcmVzZW50IG9m
IHRoZSBmZWF0dXJlIHdvdWxkIGVuYWJsZSBhoHBhcmFtZXRlciBpbiB0aGUga2VybmVsIG5hbWVk
OiBzY2hlZF9jbG9ja19zdGFibGUuoFNlZW1zIHRoaXMgcGFyYW1ldGVyIGlzoHVuYWJsZSB0byB3
b3JrIHdpdGggWGVuJiMzOTtzIHB2Y2xvY2suIElmIHNjaGVkX2Nsb2NrX3N0YWJsZSgpIGlzIHNl
dCwgdmFsdWUgcmV0dXJuZWQgYnkgeGVuX2Nsb2Nrc291cmNlX3JlYWQoKSB3b3VsZCBiZSByZXR1
cm5lZCBhcyBzY2hlZF9jbG9ja19jcHUoKSBkaXJlY3RseSwgYnV0IENNSUlXIHRoZSB2YWx1ZSBy
ZXR1cm5lZCBieSB4ZW5fY2xvY2tzb3VyY2VfcmVhZCgpIGlzIGJhc2VkIG9uIGhvc3QodmNwdSkg
dXB0aW1lIHJhdGhlciB0aGFuIHRoaXMgVk0mIzM5O3MgdXB0aW1lLCB0aGVuIHJlc3VsdCBpbiB0
aGUgdGltZXN0YW1wIGp1bXAuPC9kaXY+Cgo8ZGl2Pjxicj48L2Rpdj48ZGl2PkkmIzM5O3ZlIGNv
bXBpbGVkIGEga2VybmVsLKBmb3JjZSBzY2hlZF9jbG9ja19zdGFibGU9MCwgdGhlbiBpdCBzb2x2
ZWQgdGhlIHRpbWVzdGFtcCBqdW1wIGlzc3VlIGFzIGV4cGVjdGVkLiBMdWNraWx5LCBzZWVtcyBp
dCBhbHNvIHNvbHZlZCB0aGUgY2FsbCB0cmFjZSBhbmQgZ3Vlc3QgaGFuZyBpc3N1ZSBhcyB3ZWxs
LjwvZGl2PjxkaXY+PGJyPjwvZGl2PgoKPGRpdj5BdHRhY2htZW50IGlzIGEgKHVudGVzdGVkKSBw
YXRjaCB0byBtYXNrIHRoZSBDUFVJRCBsZWFmIDB4ODAwMDAwMDcuIEkgdGhpbmsgdGhlIGlzc3Vl
IGNhbiBiZSBlYXNpbHkgcmVwcm9kdWNlZCB1c2luZyBhIFdlc3RtZXJlIG9yIFNhbmR5QnJpZGdl
IG1hY2hpbmUobXkgb2xkIGNvbGxlYWd1ZXMgYXQgSW50ZWwgc2FpZCB0aGUgZmVhdHVyZSBsaWtl
bHkgZXhpc3RlZCBhZnRlciBOZWhhbGVtKSBydW5uaW5nIG5ld2VyIHZlcnNpb24gb2YgUFYgZ3Vl
c3QsIGNoZWNrIHRoZSBndWVzdCBjcHVpbmZvIHlvdSB3b3VsZCBzZWUgbm9uc3RvcF90c2MsIGFu
ZCB5b3Ugd291bGQgbm90aWNlIHRoZSBhYm5vcm1hbCB0aW1lc3RhbXAgb2YgcHJpbnRrLjwvZGl2
PgoKPGRpdj48YnI+PC9kaXY+PGRpdj5Tb3JyeSBJIGRvbiYjMzk7dCBoYXZlIGEgWGVuIHVuc3Rh
YmxlIGVudmlyb25tZW50IGJ5IGhhbmQgbm93LiBCdXQgSSB0aGluayB0aGlzIHNob3VsZCBiZSB0
aGUgY2FzZSB3ZSBzYXcuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CVFc6IHRoZSBvcmlnaW5h
bCBlbnZpcm9ubWVudCBpcyB4ZW4tMy40LjIsIGJ1dCBJIGZvdW5kIHRoZSBmZWF0dXJlIHJlbWFp
biB1bm1hc2tlZCBieSBsYXRlc3QgeGVuLXVuc3RhYmxlIHRyZWUuPC9kaXY+Cgo8ZGl2PjxkaXY+
PGJyPjwvZGl2Pi0tPGRpdj5yZWdhcmRzPC9kaXY+PHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQg
Y29sb3I9IiM4ODg4ODgiPjxkaXY+WWFuZywgU2hlbmc8L2Rpdj48YnI+CjwvZm9udD48L3NwYW4+
PC9kaXY+CjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGRpdj48YnI+PC9kaXY+LS0gPGJyPi0t
PGRpdj5yZWdhcmRzPC9kaXY+PGRpdj5ZYW5nLCBTaGVuZzwvZGl2Pjxicj4K
--0015175dd944f76aa304bd80469a--
--0015175dd944f76aa804bd80469c
Content-Type: application/octet-stream; 
	name="0001-libxc-disable-invarient-TSC-for-PV-guest.patch"
Content-Disposition: attachment; 
	filename="0001-libxc-disable-invarient-TSC-for-PV-guest.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0y6smvf0

RnJvbSBhODAwMDg5YmM3YzA1MDgxYTRkMmYwOWVhODZlYWU1MmVjYTVhYjdlIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBTaGVuZyBZYW5nIDxzaGVuZy55YW5nQGNpdHJpeC5jb20+CkRh
dGU6IFdlZCwgMTEgQXByIDIwMTIgMTU6NDc6MjQgLTA3MDAKU3ViamVjdDogW1BBVENIXSBsaWJ4
YzogZGlzYWJsZSBpbnZhcmllbnQgVFNDIGZvciBQViBndWVzdAoKV2UgZ290IHRoZSBmb2xsb3dp
bmcgZG1lc2cgaW4gdGhlIERlYmlhbiA2LjAncyBsYXRlc3Qga2VybmVscyhkZWJpYW4gcGFja2Fn
ZQoyLjYuMzItNDEsIGFuZCAzLjIuMC0yKSwgcnVubmluZyBhcyBQViBndWVzdCBvbiBpbnZhcmll
bnQobm9uLXN0b3ApIFRTQyBjYXBhYmxlCm1hY2hpbmUuCgpCb290aW5nOgoKWyAgICAwLjAwMDAw
MF0gWGVuIHZlcnNpb246IDMuNC4yIChwcmVzZXJ2ZS1BRCkKWyAgICAwLjAwMDAwMF0gTlJfQ1BV
UzozMiBucl9jcHVtYXNrX2JpdHM6MzIgbnJfY3B1X2lkczoxIG5yX25vZGVfaWRzOjEKWyAgICAw
LjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAxNSBwYWdlcy9jcHUgQGMxNjA4MDAwIHMzNzY1NiBy
MCBkMjM3ODQgdTY1NTM2ClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IHMzNzY1NiByMCBkMjM3
ODQgdTY1NTM2IGFsbG9jPTE2KjQwOTYKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogWzBdIDAK
WzUwODExOS44MDc1OTBdIHRyeWluZyB0byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkwMTAsIG1m
biA5OTJjYWMsIG9mZnNldCAxNgpbNTA4MTE5LjgwNzU5M10gY3B1IDAgdXNpbmcgdmNwdV9pbmZv
IGF0IGMxNjA5MDEwCls1MDgxMTkuODA3NTk0XSBYZW46IHVzaW5nIHZjcHVfaW5mbyBwbGFjZW1l
bnQKWzUwODExOS44MDc1OThdIEJ1aWx0IDEgem9uZWxpc3RzIGluIFpvbmUgb3JkZXIsIG1vYmls
aXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDMyNDE2CgpUaW1lIGp1bXBlZCBmcm9tIFsw
LjAwMDAwMF0gdG8gWzUwODExOS44MDc1OTBdLgoKTWlncmF0aW9uOgoKWzUwODEyNS4xNDEzMDBd
IGlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCls1MDgxMzUuMzg1
ODU0XSBldGgwOiBubyBJUHY2IHJvdXRlcnMgcHJlc2VudApbNTA4MTM1Ljc0NTg2M10gZXRoMTog
bm8gSVB2NiByb3V0ZXJzIHByZXNlbnQKWzUwOTUwOC45MTQzMzNdIHN1c3BlbmRpbmcgeGVuc3Rv
cmUuLi4KWzUxNjIxMi4wNTU5MjFdIHRyeWluZyB0byBtYXAgdmNwdV9pbmZvIDAgYXQgYzE2MDkw
MTAsIG1mbiA4OTVmZDcsIG9mZnNldCAxNgpbNTE2MjEyLjA1NTkzMF0gY3B1IDAgdXNpbmcgdmNw
dV9pbmZvIGF0IGMxNjA5MDEwCgpUaW1lIGp1bXBlZCBmcm9tIFs1MDk1MDguOTE0MzMzXShiZWZv
cmUgbWlncmF0aW9uKSB0byBbNTE2MjEyLjA1NTkyMV0oYWZ0ZXIKbWlncmF0aW9uKS4KClRoZSBh
Ym92ZSBpc3N1ZSBjYW4gYmUgcmVwcm9kdWNlZCB1c2luZyBvdXIgU2FuZHlCcmlkZ2UgbWFjaGlu
ZS4KCkFmdGVyIGludmVzdGlnYXRpb24sIEkgZm91bmQgaXQncyBkdWUgdG8gSW52YXJpZW50IFRT
QyAoQ1BVSUQgTGVhZiAweDgwMDAwMDA3CkVEWDo4LCBhbHNvIGNhbGxlZCBub24tc3RvcCBUU0Mp
LiBUaGUgcHJlc2VudCBvZiB0aGUgZmVhdHVyZSB3b3VsZCBlbmFibGUgYQpwYXJhbWV0ZXIgaW4g
dGhlIGtlcm5lbCBuYW1lZDogc2NoZWRfY2xvY2tfc3RhYmxlLiAgU2VlbXMgdGhpcyBwYXJhbWV0
ZXIgaXMKdW5hYmxlIHRvIHdvcmsgd2l0aCBYZW4ncyBwdmNsb2NrLgoKVGhlIHBhdGNoIHdvdWxk
IGRpc2FibGUgbm9uLXN0b3AgVFNDIGZvciBQViBndWVzdCwgdGh1cyBmaXggdGhpcyB0aW1lc3Rh
bXAKaXNzdWUuCgpUaGlzIGlzc3VlIHBvdGVudGlhbGx5IGNhdXNlZCBndWVzdCBoYW5nIHdoZW4g
cnVubmluZyB3aXRoIGRlYmlhbiBrZXJuZWwKMi42LjMyLTQxLCBidXQgd2UgY2Fubm90IHJlcHJv
ZHVjZSB0aGUgaGFuZyBpbiBvdXIgZW52aXJvbm1lbnQuIFRoZXJlIGFyZSBtYXliZQpvdGhlciBr
ZXJuZWwgYnVncyB0aGVyZS4KClNpZ25lZC1vZmYtYnk6IFNoZW5nIFlhbmcgPHNoZW5nLnlhbmdA
Y2l0cml4LmNvbT4KLS0tCiB0b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYyB8ICAgIDEgKwogMSBm
aWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMgYi90b29scy9saWJ4Yy94Y19jcHVpZF94ODYu
YwppbmRleCAwODgyY2U2Li5hMDI4NDA3IDEwMDY0NAotLS0gYS90b29scy9saWJ4Yy94Y19jcHVp
ZF94ODYuYworKysgYi90b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYwpAQCAtNTQxLDYgKzU0MSw3
IEBAIHN0YXRpYyB2b2lkIHhjX2NwdWlkX3B2X3BvbGljeSgKICAgICBjYXNlIDB4MDAwMDAwMDU6
IC8qIE1PTklUT1IvTVdBSVQgKi8KICAgICBjYXNlIDB4MDAwMDAwMGE6IC8qIEFyY2hpdGVjdHVy
YWwgUGVyZm9ybWFuY2UgTW9uaXRvciBGZWF0dXJlcyAqLwogICAgIGNhc2UgMHgwMDAwMDAwYjog
LyogRXh0ZW5kZWQgVG9wb2xvZ3kgRW51bWVyYXRpb24gKi8KKyAgICBjYXNlIDB4ODAwMDAwMDc6
IC8qIEludmFyaWFudCBUU0MgKi8KICAgICBjYXNlIDB4ODAwMDAwMGE6IC8qIFNWTSByZXZpc2lv
biBhbmQgZmVhdHVyZXMgKi8KICAgICBjYXNlIDB4ODAwMDAwMWI6IC8qIEluc3RydWN0aW9uIEJh
c2VkIFNhbXBsaW5nICovCiAgICAgY2FzZSAweDgwMDAwMDFjOiAvKiBMaWdodCBXZWlnaHQgUHJv
ZmlsaW5nICovCi0tIAoxLjcuNS40Cgo=
--0015175dd944f76aa804bd80469c
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--0015175dd944f76aa804bd80469c--


From xen-devel-bounces@lists.xen.org Thu Apr 12 19:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 19:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIPmU-0005K6-Ow; Thu, 12 Apr 2012 19:34:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1SIPmS-0005K1-UZ
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 19:34:09 +0000
Received: from [85.158.143.99:7814] by server-3.bemta-4.messagelabs.com id
	FC/78-05853-03E278F4; Thu, 12 Apr 2012 19:34:08 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334259246!23430008!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9225 invoked from network); 12 Apr 2012 19:34:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 19:34:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330923600"; d="scan'208";a="190117351"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 15:33:36 -0400
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Apr 2012
	15:33:33 -0400
Message-ID: <4F872E05.8090808@citrix.com>
Date: Thu, 12 Apr 2012 20:33:25 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120320 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>	
	<2187e535bf91f5f650401a4e08e0e795003ad2aa.1332430810.git.julien.grall@citrix.com>
	<1332502403.30916.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1332502403.30916.23.camel@zakaz.uk.xensource.com>
Cc: Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface to
 support multiple ioreq server
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/23/2012 11:33 AM, Ian Campbell wrote:
> On Thu, 2012-03-22 at 15:59 +0000, Julien Grall wrote:
>    
>> Add structure to handle ioreq server. It's server which can
>> handle a range of IO (MMIO and/or PIO) and emulate a PCI.
>> Each server as its own shared page to receive ioreq. So
>> we have introduced to HVM PARAM to set/get the first and
>> the last shared used for ioreq.
>> With it's id, the server knows which page it must use.
>>      
> So id is always the page offset with the range? Why not just call it
> iobuf_offset then? Is the additional layer of abstraction from calling
> it "id" useful if we are just going to peek around it?
>    
Indeed, but this parameter is also used to register bdf/io range.
So can we call it server_id or server_offset ?

>> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
>> index 6a78f75..1e0e27b 100644
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -24,6 +24,8 @@
>>   #include "../xen.h"
>>   #include "../trace.h"
>>
>> +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
>>      
> You don't appear to use HVM_MAX_VCPUS anywhere in your additions?
>
>    
I use it in xen-all.c in QEMU. It permits to check that smp_cpus is lower
that the maximum of vpcus. It avoids page overflow.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 19:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 19:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIPmU-0005K6-Ow; Thu, 12 Apr 2012 19:34:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1SIPmS-0005K1-UZ
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 19:34:09 +0000
Received: from [85.158.143.99:7814] by server-3.bemta-4.messagelabs.com id
	FC/78-05853-03E278F4; Thu, 12 Apr 2012 19:34:08 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334259246!23430008!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9225 invoked from network); 12 Apr 2012 19:34:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 19:34:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330923600"; d="scan'208";a="190117351"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 15:33:36 -0400
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Apr 2012
	15:33:33 -0400
Message-ID: <4F872E05.8090808@citrix.com>
Date: Thu, 12 Apr 2012 20:33:25 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120320 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>	
	<2187e535bf91f5f650401a4e08e0e795003ad2aa.1332430810.git.julien.grall@citrix.com>
	<1332502403.30916.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1332502403.30916.23.camel@zakaz.uk.xensource.com>
Cc: Julian Pidancet <julian.pidancet@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface to
 support multiple ioreq server
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/23/2012 11:33 AM, Ian Campbell wrote:
> On Thu, 2012-03-22 at 15:59 +0000, Julien Grall wrote:
>    
>> Add structure to handle ioreq server. It's server which can
>> handle a range of IO (MMIO and/or PIO) and emulate a PCI.
>> Each server as its own shared page to receive ioreq. So
>> we have introduced to HVM PARAM to set/get the first and
>> the last shared used for ioreq.
>> With it's id, the server knows which page it must use.
>>      
> So id is always the page offset with the range? Why not just call it
> iobuf_offset then? Is the additional layer of abstraction from calling
> it "id" useful if we are just going to peek around it?
>    
Indeed, but this parameter is also used to register bdf/io range.
So can we call it server_id or server_offset ?

>> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
>> index 6a78f75..1e0e27b 100644
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -24,6 +24,8 @@
>>   #include "../xen.h"
>>   #include "../trace.h"
>>
>> +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
>>      
> You don't appear to use HVM_MAX_VCPUS anywhere in your additions?
>
>    
I use it in xen-all.c in QEMU. It permits to check that smp_cpus is lower
that the maximum of vpcus. It avoids page overflow.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 20:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 20:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIQDo-0005eD-CQ; Thu, 12 Apr 2012 20:02:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIQDm-0005e8-Lv
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 20:02:22 +0000
Received: from [85.158.143.99:5456] by server-1.bemta-4.messagelabs.com id
	B7/A3-20925-DC4378F4; Thu, 12 Apr 2012 20:02:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334260941!22845117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11009 invoked from network); 12 Apr 2012 20:02:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 20:02:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330905600"; d="scan'208";a="11911785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 20:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 21:02:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIQDk-0001Yf-W0;
	Thu, 12 Apr 2012 20:02:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIQDh-00079V-RF;
	Thu, 12 Apr 2012 21:02:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12656-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 21:02:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12656: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12656 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12656/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12578
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 12578
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 12578

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 20:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 20:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIQDo-0005eD-CQ; Thu, 12 Apr 2012 20:02:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIQDm-0005e8-Lv
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 20:02:22 +0000
Received: from [85.158.143.99:5456] by server-1.bemta-4.messagelabs.com id
	B7/A3-20925-DC4378F4; Thu, 12 Apr 2012 20:02:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334260941!22845117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11009 invoked from network); 12 Apr 2012 20:02:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 20:02:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,412,1330905600"; d="scan'208";a="11911785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 20:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 21:02:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIQDk-0001Yf-W0;
	Thu, 12 Apr 2012 20:02:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIQDh-00079V-RF;
	Thu, 12 Apr 2012 21:02:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12656-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 21:02:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12656: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12656 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12656/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12578
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 12578
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 12578

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:04:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRBf-0006MS-N7; Thu, 12 Apr 2012 21:04:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SIRBd-0006MN-O8
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 21:04:14 +0000
Received: from [85.158.138.51:14101] by server-6.bemta-3.messagelabs.com id
	A8/EB-05145-C43478F4; Thu, 12 Apr 2012 21:04:12 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334264650!20102810!1
X-Originating-IP: [98.138.90.78]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26636 invoked from network); 12 Apr 2012 21:04:11 -0000
Received: from nm15.bullet.mail.ne1.yahoo.com (HELO
	nm15.bullet.mail.ne1.yahoo.com) (98.138.90.78)
	by server-15.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 21:04:11 -0000
Received: from [98.138.90.57] by nm15.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Apr 2012 21:04:10 -0000
Received: from [98.138.89.165] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Apr 2012 21:04:10 -0000
Received: from [127.0.0.1] by omp1021.mail.ne1.yahoo.com with NNFMP;
	12 Apr 2012 21:04:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 636155.59102.bm@omp1021.mail.ne1.yahoo.com
Received: (qmail 12176 invoked by uid 60001); 12 Apr 2012 21:04:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334264650; bh=yMa83B1k8rb2dMqLKarptmurWq2DK52u9huYj2fnjvk=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=mFS8AhG+u4YpjcWYjkXHfKxhaY+S8+b032zhYlgTG4R34sUazeoEIq4hVvpwSQvpA4vLBU+6emBXWjwlLt1XXKsckfPOX76hpxsbnzvAbshtc5gFPpjnFs6RtHLk/xfv/QWw2rJvdt6rSiP946RqNDA6GLyTvTmKnG8gGKb8zyU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=50SgAWjWRqZkdX0/b2xfIf2XekpR5MPUlN753OluwpzNU7N+h12cracnxmGC47vglusmLXDiizZkGv335k0/H0t3t7gp+/pkUxQUS2DM0ERGKesCQo9WuxUlJMatBc2bnsXHNlnZOImtL8qTRmcb+8AS+oOyuYtN458RJgspedo=;
X-YMail-OSG: eIo5dxEVM1nTHWHMdL6Hgv03zmjovicq6vXaj6oelz56jBY
	h5UG4Z2MYKYLGhwew0W9kOJbUi94HbK.JqK9R8BdTN4yIIpPBqMGirL0XHE0
	JElhYyl0cN3BFjsGbDhF7JQEzTl2GuOpXPcgfDuI5FJKmTNDBU2eDOS85eLG
	AxyZfQoWG9_Appz9XfrvwXRps3JIbYHNCA1ESrakb4ti9KZNlG7sIPVP3MFh
	AKfTGIkBfphBIsR0xawpfb3cRg6hjYzrgojEIBBryiNhzvtWX3.2DBUFPV1s
	t8X1qLkOGOFKSdcLAWYkhRszfaLmdiFbq_0XdLTrMFk3dzcv0t0pC1wOjHaN
	hbAzs4NHRdn1740BtzpeatJGa4T9Mvr7Zi.vuIQFv1Mh98oul9QunqKC8Pk3
	qUglrxiDKuQT7OCdH_AtlYyBDwWalAmXyQghaYXDEpqji52G3SXDfgo2gBeJ
	Nmq13PSFfBANOXPM0D2y4IzZpavpL95MVJg--
Received: from [128.173.237.43] by web124505.mail.ne1.yahoo.com via HTTP;
	Thu, 12 Apr 2012 14:04:10 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1334006386.85318.YahooMailNeo@web124506.mail.ne1.yahoo.com>
	<CBA9A1D5.3042B%keir.xen@gmail.com>
Message-ID: <1334264650.7897.YahooMailNeo@web124505.mail.ne1.yahoo.com>
Date: Thu, 12 Apr 2012 14:04:10 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA9A1D5.3042B%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir,

I have a question regarding xen interrupt affinity mask. Is there some way =
to disable xen (virtual) interrupts on a particular cpu? I mean, like irq_d=
efault_affinity in Linux kernel (which is for normal SMP interrupts).

If there is no easy way to change the mask, do you know what functions I ne=
ed to look at?

Thank you!

Ruslan



----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <x=
en-devel@lists.xen.org>
Cc: =

Sent: Tuesday, April 10, 2012 3:37 AM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

Not sure. Did you snip some lines from the call trace that might explain why
the call trace is being generated (e.g., watchdog timeout, page fault, ...)?
>From the lines you provide, we can't even tell which vcpu it is that is
dumping the call trace.

-- Keir

On 09/04/2012 22:19, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> Thanks again! When I used the scheme I have described, I periodically rec=
eive
> kernel errors as shown below. Notice that I use HVM domain and also 'isol=
cpus'
> as a Linux kernel option to prevent a dedicated VCPU from being normally =
used.
> A hypercall is being made from a special kernel thread (which is bind to =
the
> dedicated VCPU before the call).
> =

> What could be the reason of these messages? Looks like it is something re=
lated
> to a timer.
> =

> =

> [ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>]
> default_send_IPI_mask_sequence_phys+0x95/0xce
> [ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
> [ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX:
> 0000000000000020
> [ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI:
> 0000000000000300
> [ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09:
> ffffffff8163eb20
> [ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12:
> 000000000000d602
> [ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15:
> ffffffff8163eb20
> [ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000)
> knlGS:0000000000000000
> [ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4:
> 00000000000006a0
> [ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, ta=
sk
> ffff88007c4f1650)
> [ 1039.319957] Stack:
> [ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88
> 0000000000002710
> [ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001
> ffffffff8161a4c0
> [ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98
> ffffffff8101bb81
> [ 1039.319957] Call Trace:
> [ 1039.319957]=A0 <IRQ>
> [ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
> [ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x4=
b/0x6e
> [ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
> [ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
> [ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
> [ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
> [ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
> [ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
> [ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
> [ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
> [ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
> [ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
> [ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
> [ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
> [ 1039.319957]=A0 <EOI>
> [ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
> [ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
> [ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
> [ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
> [ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1
> =

> =

> =

> Thanks,
> Ruslan
> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Monday, April 9, 2012 8:58 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> It means the vcpu has an interrupt pending (in the pv case, that means an
> event channel has a pending event).
> =

> =

> On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Keir,
>> =

>> Thanks for your replies! Just one more question about
>> local_event_need_delivery(). Under what (common) conditions I would expe=
ct to
>> have local events that need delivery?
>> =

>> Ruslan
>> =

>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 8:09 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Thanks for the reply.
>>> =

>>> Since it can take arbitrarily long for an event to arrive (e.g., it is
>>> coming
>>> from a different guest on a user request), how do I need to handle this
>>> case?Does it mean that I only need to make sure that nothings get sched=
uled
>>> on
>>> this VCPU in the guest?
>> =

>> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
>> sleep within wait_event within the hypercall context. Hence you must not
>> hold any hypervisor spinlocks either, for example.
>> =

>>> Also, it is not exactly clear to me how wait_event avoids the need for
>>> hypercall continuation. What about local_events_need_delivery() or
>>> softirq_pending()? Are they going to be handled by wait_event internall=
y?
>> =

>> Your VCPU gets descheduled. Hence softirq_pending() is not your concern =
for
>> the duration that you're descheduled. And if local_event_need_delivery(),
>> that's too bad, they have to wait for the vcpu to wake up on the event.
>> =

>> -- Keir
>> =

>>> Ruslan
>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>> ----- Original Message -----
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>>> <xen-devel@lists.xen.org>
>>> Cc: =

>>> Sent: Monday, April 9, 2012 6:54 PM
>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>> =

>>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>> =

>>>> Hi
>>>> =

>>>> I am curious how I can properly support hypercall continuation and
>>>> wait_event.
>>>> I have a dedicated VCPU in a domain which makes a special hypercall, a=
nd
>>>> the
>>>> hypercall waits for certain event to arrive. I am using queues availab=
le in
>>>> Xen, so wait_event will be invoked in the hypercall once its ready to
>>>> accept
>>>> events. However, my understanding that even though I have a dedicated =
VCPU
>>>> for
>>>> this hypercall, I still may need to support hypercall continuation
>>>> properly.
>>>> (Is this the case?) So, my question is how exactly the need for hyperc=
all
>>> =

>>> No it's not the case, the old hypercall_create_continuation() mechanism=
 does
>>> not need to be used with wait_event().
>>> =

>>> -- Keir
>>> =

>>>> preemption may affect wait_event() and wait() operations, and where wo=
uld I
>>>> need to do hypercall_preempt_check()?
>>>> =

>>>> Thank you!
>>>> Ruslan
>>>> =

>>>> =

>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:04:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRBf-0006MS-N7; Thu, 12 Apr 2012 21:04:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SIRBd-0006MN-O8
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 21:04:14 +0000
Received: from [85.158.138.51:14101] by server-6.bemta-3.messagelabs.com id
	A8/EB-05145-C43478F4; Thu, 12 Apr 2012 21:04:12 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334264650!20102810!1
X-Originating-IP: [98.138.90.78]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26636 invoked from network); 12 Apr 2012 21:04:11 -0000
Received: from nm15.bullet.mail.ne1.yahoo.com (HELO
	nm15.bullet.mail.ne1.yahoo.com) (98.138.90.78)
	by server-15.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 21:04:11 -0000
Received: from [98.138.90.57] by nm15.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Apr 2012 21:04:10 -0000
Received: from [98.138.89.165] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Apr 2012 21:04:10 -0000
Received: from [127.0.0.1] by omp1021.mail.ne1.yahoo.com with NNFMP;
	12 Apr 2012 21:04:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 636155.59102.bm@omp1021.mail.ne1.yahoo.com
Received: (qmail 12176 invoked by uid 60001); 12 Apr 2012 21:04:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334264650; bh=yMa83B1k8rb2dMqLKarptmurWq2DK52u9huYj2fnjvk=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=mFS8AhG+u4YpjcWYjkXHfKxhaY+S8+b032zhYlgTG4R34sUazeoEIq4hVvpwSQvpA4vLBU+6emBXWjwlLt1XXKsckfPOX76hpxsbnzvAbshtc5gFPpjnFs6RtHLk/xfv/QWw2rJvdt6rSiP946RqNDA6GLyTvTmKnG8gGKb8zyU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=50SgAWjWRqZkdX0/b2xfIf2XekpR5MPUlN753OluwpzNU7N+h12cracnxmGC47vglusmLXDiizZkGv335k0/H0t3t7gp+/pkUxQUS2DM0ERGKesCQo9WuxUlJMatBc2bnsXHNlnZOImtL8qTRmcb+8AS+oOyuYtN458RJgspedo=;
X-YMail-OSG: eIo5dxEVM1nTHWHMdL6Hgv03zmjovicq6vXaj6oelz56jBY
	h5UG4Z2MYKYLGhwew0W9kOJbUi94HbK.JqK9R8BdTN4yIIpPBqMGirL0XHE0
	JElhYyl0cN3BFjsGbDhF7JQEzTl2GuOpXPcgfDuI5FJKmTNDBU2eDOS85eLG
	AxyZfQoWG9_Appz9XfrvwXRps3JIbYHNCA1ESrakb4ti9KZNlG7sIPVP3MFh
	AKfTGIkBfphBIsR0xawpfb3cRg6hjYzrgojEIBBryiNhzvtWX3.2DBUFPV1s
	t8X1qLkOGOFKSdcLAWYkhRszfaLmdiFbq_0XdLTrMFk3dzcv0t0pC1wOjHaN
	hbAzs4NHRdn1740BtzpeatJGa4T9Mvr7Zi.vuIQFv1Mh98oul9QunqKC8Pk3
	qUglrxiDKuQT7OCdH_AtlYyBDwWalAmXyQghaYXDEpqji52G3SXDfgo2gBeJ
	Nmq13PSFfBANOXPM0D2y4IzZpavpL95MVJg--
Received: from [128.173.237.43] by web124505.mail.ne1.yahoo.com via HTTP;
	Thu, 12 Apr 2012 14:04:10 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1334006386.85318.YahooMailNeo@web124506.mail.ne1.yahoo.com>
	<CBA9A1D5.3042B%keir.xen@gmail.com>
Message-ID: <1334264650.7897.YahooMailNeo@web124505.mail.ne1.yahoo.com>
Date: Thu, 12 Apr 2012 14:04:10 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <CBA9A1D5.3042B%keir.xen@gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir,

I have a question regarding xen interrupt affinity mask. Is there some way =
to disable xen (virtual) interrupts on a particular cpu? I mean, like irq_d=
efault_affinity in Linux kernel (which is for normal SMP interrupts).

If there is no easy way to change the mask, do you know what functions I ne=
ed to look at?

Thank you!

Ruslan



----- Original Message -----
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org" <x=
en-devel@lists.xen.org>
Cc: =

Sent: Tuesday, April 10, 2012 3:37 AM
Subject: Re: [Xen-devel] Hypercall continuation and wait_event

Not sure. Did you snip some lines from the call trace that might explain why
the call trace is being generated (e.g., watchdog timeout, page fault, ...)?
>From the lines you provide, we can't even tell which vcpu it is that is
dumping the call trace.

-- Keir

On 09/04/2012 22:19, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> Thanks again! When I used the scheme I have described, I periodically rec=
eive
> kernel errors as shown below. Notice that I use HVM domain and also 'isol=
cpus'
> as a Linux kernel option to prevent a dedicated VCPU from being normally =
used.
> A hypercall is being made from a special kernel thread (which is bind to =
the
> dedicated VCPU before the call).
> =

> What could be the reason of these messages? Looks like it is something re=
lated
> to a timer.
> =

> =

> [ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>]
> default_send_IPI_mask_sequence_phys+0x95/0xce
> [ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
> [ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX:
> 0000000000000020
> [ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI:
> 0000000000000300
> [ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09:
> ffffffff8163eb20
> [ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12:
> 000000000000d602
> [ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15:
> ffffffff8163eb20
> [ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000)
> knlGS:0000000000000000
> [ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4:
> 00000000000006a0
> [ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, ta=
sk
> ffff88007c4f1650)
> [ 1039.319957] Stack:
> [ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88
> 0000000000002710
> [ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001
> ffffffff8161a4c0
> [ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98
> ffffffff8101bb81
> [ 1039.319957] Call Trace:
> [ 1039.319957]=A0 <IRQ>
> [ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
> [ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x4=
b/0x6e
> [ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
> [ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
> [ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
> [ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
> [ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
> [ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
> [ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0x=
b4
> [ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
> [ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
> [ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
> [ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
> [ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
> [ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
> [ 1039.319957]=A0 <EOI>
> [ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
> [ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
> [ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
> [ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
> [ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1
> =

> =

> =

> Thanks,
> Ruslan
> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Monday, April 9, 2012 8:58 PM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> It means the vcpu has an interrupt pending (in the pv case, that means an
> event channel has a pending event).
> =

> =

> On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Keir,
>> =

>> Thanks for your replies! Just one more question about
>> local_event_need_delivery(). Under what (common) conditions I would expe=
ct to
>> have local events that need delivery?
>> =

>> Ruslan
>> =

>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 8:09 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Thanks for the reply.
>>> =

>>> Since it can take arbitrarily long for an event to arrive (e.g., it is
>>> coming
>>> from a different guest on a user request), how do I need to handle this
>>> case?Does it mean that I only need to make sure that nothings get sched=
uled
>>> on
>>> this VCPU in the guest?
>> =

>> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU will
>> sleep within wait_event within the hypercall context. Hence you must not
>> hold any hypervisor spinlocks either, for example.
>> =

>>> Also, it is not exactly clear to me how wait_event avoids the need for
>>> hypercall continuation. What about local_events_need_delivery() or
>>> softirq_pending()? Are they going to be handled by wait_event internall=
y?
>> =

>> Your VCPU gets descheduled. Hence softirq_pending() is not your concern =
for
>> the duration that you're descheduled. And if local_event_need_delivery(),
>> that's too bad, they have to wait for the vcpu to wake up on the event.
>> =

>> -- Keir
>> =

>>> Ruslan
>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>> ----- Original Message -----
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>>> <xen-devel@lists.xen.org>
>>> Cc: =

>>> Sent: Monday, April 9, 2012 6:54 PM
>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>> =

>>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>> =

>>>> Hi
>>>> =

>>>> I am curious how I can properly support hypercall continuation and
>>>> wait_event.
>>>> I have a dedicated VCPU in a domain which makes a special hypercall, a=
nd
>>>> the
>>>> hypercall waits for certain event to arrive. I am using queues availab=
le in
>>>> Xen, so wait_event will be invoked in the hypercall once its ready to
>>>> accept
>>>> events. However, my understanding that even though I have a dedicated =
VCPU
>>>> for
>>>> this hypercall, I still may need to support hypercall continuation
>>>> properly.
>>>> (Is this the case?) So, my question is how exactly the need for hyperc=
all
>>> =

>>> No it's not the case, the old hypercall_create_continuation() mechanism=
 does
>>> not need to be used with wait_event().
>>> =

>>> -- Keir
>>> =

>>>> preemption may affect wait_event() and wait() operations, and where wo=
uld I
>>>> need to do hypercall_preempt_check()?
>>>> =

>>>> Thank you!
>>>> Ruslan
>>>> =

>>>> =

>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRd0-0006r1-NP; Thu, 12 Apr 2012 21:32:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIRcy-0006qv-Vb
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 21:32:29 +0000
Received: from [85.158.143.99:7491] by server-1.bemta-4.messagelabs.com id
	33/8B-20925-CE9478F4; Thu, 12 Apr 2012 21:32:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334266347!18145238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23599 invoked from network); 12 Apr 2012 21:32:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 21:32:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,413,1330905600"; d="scan'208";a="11912675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 21:32:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 22:32:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIRcx-00021h-AL;
	Thu, 12 Apr 2012 21:32:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIRcw-0004b7-Vz;
	Thu, 12 Apr 2012 22:32:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12657-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 22:32:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12657: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12657 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12657/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 12646 REGR. vs. 12592

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 12646

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRd0-0006r1-NP; Thu, 12 Apr 2012 21:32:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIRcy-0006qv-Vb
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 21:32:29 +0000
Received: from [85.158.143.99:7491] by server-1.bemta-4.messagelabs.com id
	33/8B-20925-CE9478F4; Thu, 12 Apr 2012 21:32:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334266347!18145238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23599 invoked from network); 12 Apr 2012 21:32:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 21:32:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,413,1330905600"; d="scan'208";a="11912675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 21:32:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 22:32:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIRcx-00021h-AL;
	Thu, 12 Apr 2012 21:32:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIRcw-0004b7-Vz;
	Thu, 12 Apr 2012 22:32:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12657-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 22:32:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12657: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12657 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12657/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 12646 REGR. vs. 12592

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 12646

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:35:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRfk-000706-EM; Thu, 12 Apr 2012 21:35:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIRfj-0006zw-1P
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 21:35:19 +0000
Received: from [85.158.138.51:30907] by server-9.bemta-3.messagelabs.com id
	9F/D9-26691-69A478F4; Thu, 12 Apr 2012 21:35:18 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334266516!21890180!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2805 invoked from network); 12 Apr 2012 21:35:17 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Apr 2012 21:35:17 -0000
Received: from mail199-ch1-R.bigfish.com (10.43.68.226) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 21:35:15 +0000
Received: from mail199-ch1 (localhost [127.0.0.1])	by
	mail199-ch1-R.bigfish.com (Postfix) with ESMTP id 7678822005C;
	Thu, 12 Apr 2012 21:35:15 +0000 (UTC)
X-SpamScore: -6
X-BigFish: VPS-6(zz9371I542Mzz1202hzz8275bh8275dh5eeeKz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail199-ch1 (localhost.localdomain [127.0.0.1]) by mail199-ch1
	(MessageSwitch) id 1334266512607128_5769;
	Thu, 12 Apr 2012 21:35:12 +0000 (UTC)
Received: from CH1EHSMHS009.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.231])	by mail199-ch1.bigfish.com (Postfix) with ESMTP id
	86E2C3000C1;	Thu, 12 Apr 2012 21:35:12 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 21:35:08 +0000
X-WSS-ID: 0M2DYME-02-ASM-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D574C8150;	Thu, 12 Apr 2012 16:35:01 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 12 Apr 2012 16:35:22 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag04.amd.com ([fe80::9143:6575:e649:e862%21]) with mapi id
	14.01.0323.003; Thu, 12 Apr 2012 16:35:06 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: Steven <wangwangkang@gmail.com>, "Wang2, Wei" <Wei.Wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Understanding AMD NPT in xen
Thread-Index: AQHNGM7ev+rWwPe8X0Gxf9DC4fqlS5aXsXlQ
Date: Thu, 12 Apr 2012 21:35:05 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090BCDA7@sausexdag02.amd.com>
References: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
In-Reply-To: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.236.71.218]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] Understanding AMD NPT in xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

White page info is more accurate. The slides was a bit vague. Here are the steps, assuming that CPU doesn't have TLB:

1. To find out gPML4E
* Traverse nested page table using gCR3 to locate guest level-4 page (PML4 table)
* Use PML4 offset (bit 47:39) to get the value of gPML4E
2. To find out gPDPE
* Traverse nested page table using gPML4E to locate guest level-3 page (PDP table)
* Use PDP offset (bit 38:30) to get the value of gPDPE
3. To find out gPDE
* Traverse nested page table using gPDPE to locate guest level-2 page (PD table)
* Use PD offset (bit 29:21) to get the value of gPDE
4. To find out gPTE
* Traverse nested page table using gPDE to locate guest level-1 page (PT table)
* Use PT offset (bit 20:12) to get the value of gPTE
5. To find out gData
* Traverse nested page table using gPTE to locate guest data page
* Use physical page offset (bit 11:0) to get the data value

TLB will accelerate this walking significantly. 

-Wei

-----Original Message-----
From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Steven
Sent: Thursday, April 12, 2012 12:06 PM
To: Wang2, Wei; xen-devel@lists.xensource.com
Subject: [Xen-devel] Understanding AMD NPT in xen

Hi, Wei,
I have read you slides in xen summit 2007 about NPT in AMD, "AMD
Barcelona and Nested Paging Support in Xen".
However, I have some question regarding the nested page walk in your slide 8.

In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
I assume that it use the [47:39] bit of gVA.
However, in another AMD white paper, "AMD-VTM Nested Paging".
http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
In its figure 4, I saw that the first step is to translate gCR3 using
nested page walk and then combine with the gVA[47:39] to read the
table entry.

These two documents look having different order of reading the guest
page table. In the slides, it first get_PML4. But in the white paper,
it first does nested page walk.
I am wondering which one is true. Thanks.

- ha

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:35:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRfk-000706-EM; Thu, 12 Apr 2012 21:35:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIRfj-0006zw-1P
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 21:35:19 +0000
Received: from [85.158.138.51:30907] by server-9.bemta-3.messagelabs.com id
	9F/D9-26691-69A478F4; Thu, 12 Apr 2012 21:35:18 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334266516!21890180!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2805 invoked from network); 12 Apr 2012 21:35:17 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Apr 2012 21:35:17 -0000
Received: from mail199-ch1-R.bigfish.com (10.43.68.226) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 21:35:15 +0000
Received: from mail199-ch1 (localhost [127.0.0.1])	by
	mail199-ch1-R.bigfish.com (Postfix) with ESMTP id 7678822005C;
	Thu, 12 Apr 2012 21:35:15 +0000 (UTC)
X-SpamScore: -6
X-BigFish: VPS-6(zz9371I542Mzz1202hzz8275bh8275dh5eeeKz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail199-ch1 (localhost.localdomain [127.0.0.1]) by mail199-ch1
	(MessageSwitch) id 1334266512607128_5769;
	Thu, 12 Apr 2012 21:35:12 +0000 (UTC)
Received: from CH1EHSMHS009.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.231])	by mail199-ch1.bigfish.com (Postfix) with ESMTP id
	86E2C3000C1;	Thu, 12 Apr 2012 21:35:12 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Apr 2012 21:35:08 +0000
X-WSS-ID: 0M2DYME-02-ASM-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D574C8150;	Thu, 12 Apr 2012 16:35:01 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 12 Apr 2012 16:35:22 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag04.amd.com ([fe80::9143:6575:e649:e862%21]) with mapi id
	14.01.0323.003; Thu, 12 Apr 2012 16:35:06 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: Steven <wangwangkang@gmail.com>, "Wang2, Wei" <Wei.Wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Understanding AMD NPT in xen
Thread-Index: AQHNGM7ev+rWwPe8X0Gxf9DC4fqlS5aXsXlQ
Date: Thu, 12 Apr 2012 21:35:05 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090BCDA7@sausexdag02.amd.com>
References: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
In-Reply-To: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.236.71.218]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] Understanding AMD NPT in xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

White page info is more accurate. The slides was a bit vague. Here are the steps, assuming that CPU doesn't have TLB:

1. To find out gPML4E
* Traverse nested page table using gCR3 to locate guest level-4 page (PML4 table)
* Use PML4 offset (bit 47:39) to get the value of gPML4E
2. To find out gPDPE
* Traverse nested page table using gPML4E to locate guest level-3 page (PDP table)
* Use PDP offset (bit 38:30) to get the value of gPDPE
3. To find out gPDE
* Traverse nested page table using gPDPE to locate guest level-2 page (PD table)
* Use PD offset (bit 29:21) to get the value of gPDE
4. To find out gPTE
* Traverse nested page table using gPDE to locate guest level-1 page (PT table)
* Use PT offset (bit 20:12) to get the value of gPTE
5. To find out gData
* Traverse nested page table using gPTE to locate guest data page
* Use physical page offset (bit 11:0) to get the data value

TLB will accelerate this walking significantly. 

-Wei

-----Original Message-----
From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Steven
Sent: Thursday, April 12, 2012 12:06 PM
To: Wang2, Wei; xen-devel@lists.xensource.com
Subject: [Xen-devel] Understanding AMD NPT in xen

Hi, Wei,
I have read you slides in xen summit 2007 about NPT in AMD, "AMD
Barcelona and Nested Paging Support in Xen".
However, I have some question regarding the nested page walk in your slide 8.

In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
I assume that it use the [47:39] bit of gVA.
However, in another AMD white paper, "AMD-VTM Nested Paging".
http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
In its figure 4, I saw that the first step is to translate gCR3 using
nested page walk and then combine with the gVA[47:39] to read the
table entry.

These two documents look having different order of reading the guest
page table. In the slides, it first get_PML4. But in the white paper,
it first does nested page walk.
I am wondering which one is true. Thanks.

- ha

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRsv-0007Zc-DJ; Thu, 12 Apr 2012 21:48:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIRst-0007ZW-V2
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 21:48:56 +0000
Received: from [193.109.254.147:44952] by server-12.bemta-14.messagelabs.com
	id 5F/4E-05898-7CD478F4; Thu, 12 Apr 2012 21:48:55 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334267334!4369301!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9267 invoked from network); 12 Apr 2012 21:48:54 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 21:48:54 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77093302; Thu, 12 Apr 2012 23:48:53 +0200
Message-ID: <1334267323.2417.3.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 23:48:43 +0200
In-Reply-To: <20358.47143.994639.76453@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2851872401064207056=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2851872401064207056==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-P1ICXe+U+C0FLVkq+lOc"


--=-P1ICXe+U+C0FLVkq+lOc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote:=20
> > I think we can defer this to 4.3? The existing interface may be pants
> > but at least the name is pretty explicit that it will block. I think
> > this should then be easy enough to sort out in a backward compatible
> > manner in 4.3 since I expect the name of the function would change and
> > we could retain the old name in terms of the new for compat.
>=20
> The problem isn't just that it blocks but also that the semantics are
> wrong.  This is all related to the problems of allocating memory.  We
> had a recent conversation where we concluded that we needed hypervisor
> changes to do memory assignment in a race-free way. =20
>
I remember that. :-)

This is basically the reason why I said, earlier in this thread, that
warning too much about moving/reworking the locking in xl is not that
important, as it we won't be able to solve _this_ issue anyway just
playing with it.

> This is not 4.3
> material.
>
Just to be sure I get it, you think we need to have the
creation-vs-ballooning potential race solved *before* 4.2 ?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-P1ICXe+U+C0FLVkq+lOc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HTbwACgkQk4XaBE3IOsTkpgCcDQEJXkzY9t0LSH06dISyrydz
OC4AoKAJR6lfxrka+gHe3CrJ7y9BqlZc
=EwTe
-----END PGP SIGNATURE-----

--=-P1ICXe+U+C0FLVkq+lOc--



--===============2851872401064207056==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2851872401064207056==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 21:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRsv-0007Zc-DJ; Thu, 12 Apr 2012 21:48:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIRst-0007ZW-V2
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 21:48:56 +0000
Received: from [193.109.254.147:44952] by server-12.bemta-14.messagelabs.com
	id 5F/4E-05898-7CD478F4; Thu, 12 Apr 2012 21:48:55 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334267334!4369301!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9267 invoked from network); 12 Apr 2012 21:48:54 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	12 Apr 2012 21:48:54 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77093302; Thu, 12 Apr 2012 23:48:53 +0200
Message-ID: <1334267323.2417.3.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 23:48:43 +0200
In-Reply-To: <20358.47143.994639.76453@mariner.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2851872401064207056=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2851872401064207056==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-P1ICXe+U+C0FLVkq+lOc"


--=-P1ICXe+U+C0FLVkq+lOc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote:=20
> > I think we can defer this to 4.3? The existing interface may be pants
> > but at least the name is pretty explicit that it will block. I think
> > this should then be easy enough to sort out in a backward compatible
> > manner in 4.3 since I expect the name of the function would change and
> > we could retain the old name in terms of the new for compat.
>=20
> The problem isn't just that it blocks but also that the semantics are
> wrong.  This is all related to the problems of allocating memory.  We
> had a recent conversation where we concluded that we needed hypervisor
> changes to do memory assignment in a race-free way. =20
>
I remember that. :-)

This is basically the reason why I said, earlier in this thread, that
warning too much about moving/reworking the locking in xl is not that
important, as it we won't be able to solve _this_ issue anyway just
playing with it.

> This is not 4.3
> material.
>
Just to be sure I get it, you think we need to have the
creation-vs-ballooning potential race solved *before* 4.2 ?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-P1ICXe+U+C0FLVkq+lOc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HTbwACgkQk4XaBE3IOsTkpgCcDQEJXkzY9t0LSH06dISyrydz
OC4AoKAJR6lfxrka+gHe3CrJ7y9BqlZc
=EwTe
-----END PGP SIGNATURE-----

--=-P1ICXe+U+C0FLVkq+lOc--



--===============2851872401064207056==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2851872401064207056==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 21:55:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRz0-0007m9-7J; Thu, 12 Apr 2012 21:55:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIRyy-0007m1-HD
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 21:55:12 +0000
Received: from [85.158.139.83:49877] by server-8.bemta-5.messagelabs.com id
	4C/51-26964-F3F478F4; Thu, 12 Apr 2012 21:55:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334267710!23592843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2673 invoked from network); 12 Apr 2012 21:55:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 21:55:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,413,1330905600"; d="scan'208";a="11912852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 21:55:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 22:55:09 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIRyv-00028p-Qv;
	Thu, 12 Apr 2012 21:55:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIRyv-0000fF-QL;
	Thu, 12 Apr 2012 22:55:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12658-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 22:55:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12658: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12658 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12658/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6efb9f934bfb
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:55:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIRz0-0007m9-7J; Thu, 12 Apr 2012 21:55:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIRyy-0007m1-HD
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 21:55:12 +0000
Received: from [85.158.139.83:49877] by server-8.bemta-5.messagelabs.com id
	4C/51-26964-F3F478F4; Thu, 12 Apr 2012 21:55:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334267710!23592843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2673 invoked from network); 12 Apr 2012 21:55:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 21:55:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,413,1330905600"; d="scan'208";a="11912852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Apr 2012 21:55:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Apr 2012 22:55:09 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIRyv-00028p-Qv;
	Thu, 12 Apr 2012 21:55:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIRyv-0000fF-QL;
	Thu, 12 Apr 2012 22:55:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12658-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 12 Apr 2012 22:55:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12658: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12658 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12658/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6efb9f934bfb
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 21:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIS1H-0007sA-1w; Thu, 12 Apr 2012 21:57:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIS1F-0007s2-IV
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 21:57:33 +0000
Received: from [85.158.143.99:5324] by server-3.bemta-4.messagelabs.com id
	57/99-05853-CCF478F4; Thu, 12 Apr 2012 21:57:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334267851!13783794!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17500 invoked from network); 12 Apr 2012 21:57:31 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 21:57:31 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77093465; Thu, 12 Apr 2012 23:57:30 +0200
Message-ID: <1334267843.2417.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 12 Apr 2012 23:57:23 +0200
In-Reply-To: <4F86AE89.7020801@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<64547b45cb112a35d3a2.1334150273@Solace>
	<4F86AE89.7020801@eu.citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10 [RFC]] xl: Allow user to set or
 change node affinity on-line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6839869417137713039=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6839869417137713039==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-wu2aRXSvlm9yoLeuhH9n"


--=-wu2aRXSvlm9yoLeuhH9n
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 11:29 +0100, George Dunlap wrote:=20
> > Of course this is not going to be equally effective, as it will
> > only affect future memory allocations without touching what's
> > already there. However, in future we might want to change this,
> > and use this as an interface for sort-of manual "domain node
> > migration".
> I think this is a good idea.
>=20
That is always something nice to hear. :-)

> I think if you take my suggestion to rework the previous patch into=20
> hypervisor, libxc, and libxl components, you should also move the xl=20
> stuff out of that patch and into this one (so that the xl and libxl=20
> changes relating to node affinity are each in their own patches).
>
Sounds reasonable, I sure will do that.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-wu2aRXSvlm9yoLeuhH9n
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HT8MACgkQk4XaBE3IOsSuBgCfTBWw+hGj5pHC0Ql8k9jzV8gK
cO0An2p59Rhm7FKvsNFfI7gnBHmgXGAp
=15W/
-----END PGP SIGNATURE-----

--=-wu2aRXSvlm9yoLeuhH9n--



--===============6839869417137713039==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6839869417137713039==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 21:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 21:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIS1H-0007sA-1w; Thu, 12 Apr 2012 21:57:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIS1F-0007s2-IV
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 21:57:33 +0000
Received: from [85.158.143.99:5324] by server-3.bemta-4.messagelabs.com id
	57/99-05853-CCF478F4; Thu, 12 Apr 2012 21:57:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334267851!13783794!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17500 invoked from network); 12 Apr 2012 21:57:31 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 21:57:31 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77093465; Thu, 12 Apr 2012 23:57:30 +0200
Message-ID: <1334267843.2417.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 12 Apr 2012 23:57:23 +0200
In-Reply-To: <4F86AE89.7020801@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<64547b45cb112a35d3a2.1334150273@Solace>
	<4F86AE89.7020801@eu.citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10 [RFC]] xl: Allow user to set or
 change node affinity on-line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6839869417137713039=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6839869417137713039==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-wu2aRXSvlm9yoLeuhH9n"


--=-wu2aRXSvlm9yoLeuhH9n
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 11:29 +0100, George Dunlap wrote:=20
> > Of course this is not going to be equally effective, as it will
> > only affect future memory allocations without touching what's
> > already there. However, in future we might want to change this,
> > and use this as an interface for sort-of manual "domain node
> > migration".
> I think this is a good idea.
>=20
That is always something nice to hear. :-)

> I think if you take my suggestion to rework the previous patch into=20
> hypervisor, libxc, and libxl components, you should also move the xl=20
> stuff out of that patch and into this one (so that the xl and libxl=20
> changes relating to node affinity are each in their own patches).
>
Sounds reasonable, I sure will do that.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-wu2aRXSvlm9yoLeuhH9n
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HT8MACgkQk4XaBE3IOsSuBgCfTBWw+hGj5pHC0Ql8k9jzV8gK
cO0An2p59Rhm7FKvsNFfI7gnBHmgXGAp
=15W/
-----END PGP SIGNATURE-----

--=-wu2aRXSvlm9yoLeuhH9n--



--===============6839869417137713039==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6839869417137713039==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 22:17:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 22:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SISK8-0008EX-9p; Thu, 12 Apr 2012 22:17:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SISK6-0008ES-Jz
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 22:17:03 +0000
Received: from [85.158.138.51:59466] by server-1.bemta-3.messagelabs.com id
	12/C6-11491-D54578F4; Thu, 12 Apr 2012 22:17:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334269019!21745303!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18039 invoked from network); 12 Apr 2012 22:16:59 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 22:16:59 -0000
Received: by werp12 with SMTP id p12so1980134wer.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 15:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DZ8BKgRaMpOQWCSA2xTQH39/makdMZwNoulkuTWYw2g=;
	b=FWTyQpH6N8+zurKdAn1Vp1zUU7LnfnbYOx7lYaDlN4xKxpe3nq0906r8c0g9B7+H4W
	1wb2AgQcmSTDZySsi1f6BHkjNusDjIfiTecOVcael6reCDMcr3PnhYkxzH3J4Kznxkjp
	WNBIbiz+xWLOcEREBXCpm0hygIiapBl1a4jtVbCeM9z5HnGPQNBFCB2iTfVFUMc8KE+4
	F/iaarAsRA52eYaoeQxYDm1ID7NCK6QAoHmpCok0kJbALqkzpd3PChyLzd28aKLP+iHR
	olPCilX3l5MQ+LB8B8xjfk79E7STpE6Qh6ckNXQ2N1Bmp4twB6I68VLCCAaYSygkeaOx
	4N/A==
Received: by 10.216.228.165 with SMTP id f37mr2445648weq.83.1334269018289;
	Thu, 12 Apr 2012 15:16:58 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id gd4sm606837wib.6.2012.04.12.15.16.56
	(version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 15:16:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Apr 2012 23:16:51 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBAD12E3.307F6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0Y+fWZAAZRrpn7BEaxYR/oQSBkiA==
In-Reply-To: <1334264650.7897.YahooMailNeo@web124505.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PV interrupts or HVM emulated interrupts? For the latter you do it in the
same way you would for native guest. For the former, it might depend on the
Linux kernel version, but possibly the same.

 -- Keir


On 12/04/2012 22:04, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> I have a question regarding xen interrupt affinity mask. Is there some wa=
y to
> disable xen (virtual) interrupts on a particular cpu? I mean, like
> irq_default_affinity in Linux kernel (which is for normal SMP interrupts).
> =

> If there is no easy way to change the mask, do you know what functions I =
need
> to look at?
> =

> Thank you!
> =

> Ruslan
> =

> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Tuesday, April 10, 2012 3:37 AM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> Not sure. Did you snip some lines from the call trace that might explain =
why
> the call trace is being generated (e.g., watchdog timeout, page fault, ..=
.)?
> From the lines you provide, we can't even tell which vcpu it is that is
> dumping the call trace.
> =

> -- Keir
> =

> On 09/04/2012 22:19, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Keir,
>> =

>> Thanks again! When I used the scheme I have described, I periodically re=
ceive
>> kernel errors as shown below. Notice that I use HVM domain and also
>> 'isolcpus'
>> as a Linux kernel option to prevent a dedicated VCPU from being normally
>> used.
>> A hypercall is being made from a special kernel thread (which is bind to=
 the
>> dedicated VCPU before the call).
>> =

>> What could be the reason of these messages? Looks like it is something
>> related
>> to a timer.
>> =

>> =

>> [ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>]
>> default_send_IPI_mask_sequence_phys+0x95/0xce
>> [ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
>> [ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX:
>> 0000000000000020
>> [ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI:
>> 0000000000000300
>> [ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09:
>> ffffffff8163eb20
>> [ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12:
>> 000000000000d602
>> [ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15:
>> ffffffff8163eb20
>> [ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000)
>> knlGS:0000000000000000
>> [ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4:
>> 00000000000006a0
>> [ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>> 0000000000000000
>> [ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>> 0000000000000400
>> [ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, t=
ask
>> ffff88007c4f1650)
>> [ 1039.319957] Stack:
>> [ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88
>> 0000000000002710
>> [ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001
>> ffffffff8161a4c0
>> [ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98
>> ffffffff8101bb81
>> [ 1039.319957] Call Trace:
>> [ 1039.319957]=A0 <IRQ>
>> [ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
>> [ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x=
4b/0x6e
>> [ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
>> [ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
>> [ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
>> [ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
>> [ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
>> [ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
>> [ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
>> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0=
xb4
>> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0=
xb4
>> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0=
xb4
>> [ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
>> [ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
>> [ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
>> [ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
>> [ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
>> [ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
>> [ 1039.319957]=A0 <EOI>
>> [ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
>> [ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
>> [ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
>> [ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
>> [ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1
>> =

>> =

>> =

>> Thanks,
>> Ruslan
>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 8:58 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> It means the vcpu has an interrupt pending (in the pv case, that means an
>> event channel has a pending event).
>> =

>> =

>> On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Keir,
>>> =

>>> Thanks for your replies! Just one more question about
>>> local_event_need_delivery(). Under what (common) conditions I would exp=
ect
>>> to
>>> have local events that need delivery?
>>> =

>>> Ruslan
>>> =

>>> =

>>> =

>>> ----- Original Message -----
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>>> <xen-devel@lists.xen.org>
>>> Cc: =

>>> Sent: Monday, April 9, 2012 8:09 PM
>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>> =

>>> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>> =

>>>> Thanks for the reply.
>>>> =

>>>> Since it can take arbitrarily long for an event to arrive (e.g., it is
>>>> coming
>>>> from a different guest on a user request), how do I need to handle this
>>>> case?Does it mean that I only need to make sure that nothings get sche=
duled
>>>> on
>>>> this VCPU in the guest?
>>> =

>>> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU wi=
ll
>>> sleep within wait_event within the hypercall context. Hence you must not
>>> hold any hypervisor spinlocks either, for example.
>>> =

>>>> Also, it is not exactly clear to me how wait_event avoids the need for
>>>> hypercall continuation. What about local_events_need_delivery() or
>>>> softirq_pending()? Are they going to be handled by wait_event internal=
ly?
>>> =

>>> Your VCPU gets descheduled. Hence softirq_pending() is not your concern=
 for
>>> the duration that you're descheduled. And if local_event_need_delivery(=
),
>>> that's too bad, they have to wait for the vcpu to wake up on the event.
>>> =

>>> -- Keir
>>> =

>>>> Ruslan
>>>> =

>>>> =

>>>> =

>>>> =

>>>> =

>>>> =

>>>> ----- Original Message -----
>>>> From: Keir Fraser <keir.xen@gmail.com>
>>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.or=
g"
>>>> <xen-devel@lists.xen.org>
>>>> Cc: =

>>>> Sent: Monday, April 9, 2012 6:54 PM
>>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>>> =

>>>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>>> =

>>>>> Hi
>>>>> =

>>>>> I am curious how I can properly support hypercall continuation and
>>>>> wait_event.
>>>>> I have a dedicated VCPU in a domain which makes a special hypercall, =
and
>>>>> the
>>>>> hypercall waits for certain event to arrive. I am using queues availa=
ble
>>>>> in
>>>>> Xen, so wait_event will be invoked in the hypercall once its ready to
>>>>> accept
>>>>> events. However, my understanding that even though I have a dedicated=
 VCPU
>>>>> for
>>>>> this hypercall, I still may need to support hypercall continuation
>>>>> properly.
>>>>> (Is this the case?) So, my question is how exactly the need for hyper=
call
>>>> =

>>>> No it's not the case, the old hypercall_create_continuation() mechanism
>>>> does
>>>> not need to be used with wait_event().
>>>> =

>>>> -- Keir
>>>> =

>>>>> preemption may affect wait_event() and wait() operations, and where w=
ould
>>>>> I
>>>>> need to do hypercall_preempt_check()?
>>>>> =

>>>>> Thank you!
>>>>> Ruslan
>>>>> =

>>>>> =

>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>> =

>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>> =

>>> =

>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>> =

>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 22:17:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 22:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SISK8-0008EX-9p; Thu, 12 Apr 2012 22:17:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SISK6-0008ES-Jz
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 22:17:03 +0000
Received: from [85.158.138.51:59466] by server-1.bemta-3.messagelabs.com id
	12/C6-11491-D54578F4; Thu, 12 Apr 2012 22:17:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334269019!21745303!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18039 invoked from network); 12 Apr 2012 22:16:59 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Apr 2012 22:16:59 -0000
Received: by werp12 with SMTP id p12so1980134wer.32
	for <xen-devel@lists.xen.org>; Thu, 12 Apr 2012 15:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DZ8BKgRaMpOQWCSA2xTQH39/makdMZwNoulkuTWYw2g=;
	b=FWTyQpH6N8+zurKdAn1Vp1zUU7LnfnbYOx7lYaDlN4xKxpe3nq0906r8c0g9B7+H4W
	1wb2AgQcmSTDZySsi1f6BHkjNusDjIfiTecOVcael6reCDMcr3PnhYkxzH3J4Kznxkjp
	WNBIbiz+xWLOcEREBXCpm0hygIiapBl1a4jtVbCeM9z5HnGPQNBFCB2iTfVFUMc8KE+4
	F/iaarAsRA52eYaoeQxYDm1ID7NCK6QAoHmpCok0kJbALqkzpd3PChyLzd28aKLP+iHR
	olPCilX3l5MQ+LB8B8xjfk79E7STpE6Qh6ckNXQ2N1Bmp4twB6I68VLCCAaYSygkeaOx
	4N/A==
Received: by 10.216.228.165 with SMTP id f37mr2445648weq.83.1334269018289;
	Thu, 12 Apr 2012 15:16:58 -0700 (PDT)
Received: from [192.168.1.84] (host86-131-215-60.range86-131.btcentralplus.com.
	[86.131.215.60])
	by mx.google.com with ESMTPS id gd4sm606837wib.6.2012.04.12.15.16.56
	(version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 15:16:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Apr 2012 23:16:51 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CBAD12E3.307F6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Hypercall continuation and wait_event
Thread-Index: Ac0Y+fWZAAZRrpn7BEaxYR/oQSBkiA==
In-Reply-To: <1334264650.7897.YahooMailNeo@web124505.mail.ne1.yahoo.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypercall continuation and wait_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PV interrupts or HVM emulated interrupts? For the latter you do it in the
same way you would for native guest. For the former, it might depend on the
Linux kernel version, but possibly the same.

 -- Keir


On 12/04/2012 22:04, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:

> Keir,
> =

> I have a question regarding xen interrupt affinity mask. Is there some wa=
y to
> disable xen (virtual) interrupts on a particular cpu? I mean, like
> irq_default_affinity in Linux kernel (which is for normal SMP interrupts).
> =

> If there is no easy way to change the mask, do you know what functions I =
need
> to look at?
> =

> Thank you!
> =

> Ruslan
> =

> =

> =

> ----- Original Message -----
> From: Keir Fraser <keir.xen@gmail.com>
> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
> <xen-devel@lists.xen.org>
> Cc: =

> Sent: Tuesday, April 10, 2012 3:37 AM
> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
> =

> Not sure. Did you snip some lines from the call trace that might explain =
why
> the call trace is being generated (e.g., watchdog timeout, page fault, ..=
.)?
> From the lines you provide, we can't even tell which vcpu it is that is
> dumping the call trace.
> =

> -- Keir
> =

> On 09/04/2012 22:19, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
> =

>> Keir,
>> =

>> Thanks again! When I used the scheme I have described, I periodically re=
ceive
>> kernel errors as shown below. Notice that I use HVM domain and also
>> 'isolcpus'
>> as a Linux kernel option to prevent a dedicated VCPU from being normally
>> used.
>> A hypercall is being made from a special kernel thread (which is bind to=
 the
>> dedicated VCPU before the call).
>> =

>> What could be the reason of these messages? Looks like it is something
>> related
>> to a timer.
>> =

>> =

>> [ 1039.319957] RIP: 0010:[<ffffffff8101ba09>]=A0 [<ffffffff8101ba09>]
>> default_send_IPI_mask_sequence_phys+0x95/0xce
>> [ 1039.319957] RSP: 0018:ffff88007f043c28=A0 EFLAGS: 00000046
>> [ 1039.319957] RAX: 0000000000000400 RBX: 0000000000000096 RCX:
>> 0000000000000020
>> [ 1039.319957] RDX: 0000000000000002 RSI: 0000000000000020 RDI:
>> 0000000000000300
>> [ 1039.319957] RBP: ffff88007f043c68 R08: 0000000000000000 R09:
>> ffffffff8163eb20
>> [ 1039.319957] R10: ffff8800ff043bad R11: 0000000000000000 R12:
>> 000000000000d602
>> [ 1039.319957] R13: 0000000000000002 R14: 0000000000000400 R15:
>> ffffffff8163eb20
>> [ 1039.319957] FS:=A0 0000000000000000(0000) GS:ffff88007f040000(0000)
>> knlGS:0000000000000000
>> [ 1039.319957] CS:=A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 1039.319957] CR2: 00007f74195d29be CR3: 000000007af4d000 CR4:
>> 00000000000006a0
>> [ 1039.319957] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>> 0000000000000000
>> [ 1039.319957] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>> 0000000000000400
>> [ 1039.319957] Process swapper/2 (pid: 0, threadinfo ffff88007c4ec000, t=
ask
>> ffff88007c4f1650)
>> [ 1039.319957] Stack:
>> [ 1039.319957]=A0 0000000000000002 0000000400000008 ffff88007f043c88
>> 0000000000002710
>> [ 1039.319957]=A0 ffffffff8161a280 ffffffff8161a340 0000000000000001
>> ffffffff8161a4c0
>> [ 1039.319957]=A0 ffff88007f043c78 ffffffff8101ecc6 ffff88007f043c98
>> ffffffff8101bb81
>> [ 1039.319957] Call Trace:
>> [ 1039.319957]=A0 <IRQ>
>> [ 1039.319957]=A0 [<ffffffff8101ecc6>] physflat_send_IPI_all+0x12/0x14
>> [ 1039.319957]=A0 [<ffffffff8101bb81>] arch_trigger_all_cpu_backtrace+0x=
4b/0x6e
>> [ 1039.319957]=A0 [<ffffffff8107a25a>] __rcu_pending+0x224/0x347
>> [ 1039.319957]=A0 [<ffffffff8107aa13>] rcu_check_callbacks+0xa2/0xb4
>> [ 1039.319957]=A0 [<ffffffff810469fd>] update_process_times+0x3a/0x70
>> [ 1039.319957]=A0 [<ffffffff8105f815>] tick_sched_timer+0x70/0x9a
>> [ 1039.319957]=A0 [<ffffffff810557c0>] __run_hrtimer.isra.26+0x75/0xce
>> [ 1039.319957]=A0 [<ffffffff81055ded>] hrtimer_interrupt+0xd7/0x193
>> [ 1039.319957]=A0 [<ffffffff81005f0a>] xen_timer_interrupt+0x2f/0x155
>> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0=
xb4
>> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0=
xb4
>> [ 1039.319957]=A0 [<ffffffff81021945>] ? pvclock_clocksource_read+0x48/0=
xb4
>> [ 1039.319957]=A0 [<ffffffff8107542d>] handle_irq_event_percpu+0x29/0x126
>> [ 1039.319957]=A0 [<ffffffff8119064a>] ? info_for_irq+0x9/0x19
>> [ 1039.319957]=A0 [<ffffffff81077b70>] handle_percpu_irq+0x39/0x4d
>> [ 1039.319957]=A0 [<ffffffff81190510>] __xen_evtchn_do_upcall+0x147/0x1df
>> [ 1039.319957]=A0 [<ffffffff81191eae>] xen_evtchn_do_upcall+0x27/0x39
>> [ 1039.319957]=A0 [<ffffffff812987ee>] xen_hvm_callback_vector+0x6e/0x80
>> [ 1039.319957]=A0 <EOI>
>> [ 1039.319957]=A0 [<ffffffff8107ab83>] ? rcu_needs_cpu+0x110/0x1c1
>> [ 1039.319957]=A0 [<ffffffff81020ff0>] ? native_safe_halt+0x6/0x8
>> [ 1039.319957]=A0 [<ffffffff8100e8bf>] default_idle+0x27/0x44
>> [ 1039.319957]=A0 [<ffffffff81007704>] cpu_idle+0x66/0xa4
>> [ 1039.319957]=A0 [<ffffffff81286605>] start_secondary+0x1ac/0x1b1
>> =

>> =

>> =

>> Thanks,
>> Ruslan
>> =

>> =

>> ----- Original Message -----
>> From: Keir Fraser <keir.xen@gmail.com>
>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>> <xen-devel@lists.xen.org>
>> Cc: =

>> Sent: Monday, April 9, 2012 8:58 PM
>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>> =

>> It means the vcpu has an interrupt pending (in the pv case, that means an
>> event channel has a pending event).
>> =

>> =

>> On 09/04/2012 21:16, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>> =

>>> Keir,
>>> =

>>> Thanks for your replies! Just one more question about
>>> local_event_need_delivery(). Under what (common) conditions I would exp=
ect
>>> to
>>> have local events that need delivery?
>>> =

>>> Ruslan
>>> =

>>> =

>>> =

>>> ----- Original Message -----
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.org"
>>> <xen-devel@lists.xen.org>
>>> Cc: =

>>> Sent: Monday, April 9, 2012 8:09 PM
>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>> =

>>> On 09/04/2012 20:18, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>> =

>>>> Thanks for the reply.
>>>> =

>>>> Since it can take arbitrarily long for an event to arrive (e.g., it is
>>>> coming
>>>> from a different guest on a user request), how do I need to handle this
>>>> case?Does it mean that I only need to make sure that nothings get sche=
duled
>>>> on
>>>> this VCPU in the guest?
>>> =

>>> Nothing else *can* get scheduled on this VCPU in the guest. The VCPU wi=
ll
>>> sleep within wait_event within the hypercall context. Hence you must not
>>> hold any hypervisor spinlocks either, for example.
>>> =

>>>> Also, it is not exactly clear to me how wait_event avoids the need for
>>>> hypercall continuation. What about local_events_need_delivery() or
>>>> softirq_pending()? Are they going to be handled by wait_event internal=
ly?
>>> =

>>> Your VCPU gets descheduled. Hence softirq_pending() is not your concern=
 for
>>> the duration that you're descheduled. And if local_event_need_delivery(=
),
>>> that's too bad, they have to wait for the vcpu to wake up on the event.
>>> =

>>> -- Keir
>>> =

>>>> Ruslan
>>>> =

>>>> =

>>>> =

>>>> =

>>>> =

>>>> =

>>>> ----- Original Message -----
>>>> From: Keir Fraser <keir.xen@gmail.com>
>>>> To: Ruslan Nikolaev <nruslan_devel@yahoo.com>; "xen-devel@lists.xen.or=
g"
>>>> <xen-devel@lists.xen.org>
>>>> Cc: =

>>>> Sent: Monday, April 9, 2012 6:54 PM
>>>> Subject: Re: [Xen-devel] Hypercall continuation and wait_event
>>>> =

>>>> On 09/04/2012 18:51, "Ruslan Nikolaev" <nruslan_devel@yahoo.com> wrote:
>>>> =

>>>>> Hi
>>>>> =

>>>>> I am curious how I can properly support hypercall continuation and
>>>>> wait_event.
>>>>> I have a dedicated VCPU in a domain which makes a special hypercall, =
and
>>>>> the
>>>>> hypercall waits for certain event to arrive. I am using queues availa=
ble
>>>>> in
>>>>> Xen, so wait_event will be invoked in the hypercall once its ready to
>>>>> accept
>>>>> events. However, my understanding that even though I have a dedicated=
 VCPU
>>>>> for
>>>>> this hypercall, I still may need to support hypercall continuation
>>>>> properly.
>>>>> (Is this the case?) So, my question is how exactly the need for hyper=
call
>>>> =

>>>> No it's not the case, the old hypercall_create_continuation() mechanism
>>>> does
>>>> not need to be used with wait_event().
>>>> =

>>>> -- Keir
>>>> =

>>>>> preemption may affect wait_event() and wait() operations, and where w=
ould
>>>>> I
>>>>> need to do hypercall_preempt_check()?
>>>>> =

>>>>> Thank you!
>>>>> Ruslan
>>>>> =

>>>>> =

>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>> =

>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>> =

>>> =

>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>> =

>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 12 22:22:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 22:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SISOe-0008Lv-0Z; Thu, 12 Apr 2012 22:21:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SISOc-0008Lp-B7
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 22:21:42 +0000
Received: from [85.158.143.99:3120] by server-1.bemta-4.messagelabs.com id
	B2/2D-20925-575578F4; Thu, 12 Apr 2012 22:21:41 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334269299!22516037!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15782 invoked from network); 12 Apr 2012 22:21:40 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 22:21:40 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77094164; Fri, 13 Apr 2012 00:21:38 +0200
Message-ID: <1334269297.2417.23.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 13 Apr 2012 00:21:37 +0200
In-Reply-To: <4F86AD6E.3050705@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5653723866298172454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5653723866298172454==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-LZ8ELMCpHrrBBTavRHqM"


--=-LZ8ELMCpHrrBBTavRHqM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 11:24 +0100, George Dunlap wrote:=20
> > A valid setting will directly impact the node_affinity mask
> > of the guest, i.e., it will change the behaviour of the low level
> > memory allocator. On the other hand, this commit does not affect
> > by any means how the guest's vCPUs are scheduled on the host's
> > pCPUs.
> I would probably break this into three separate patches, starting with=
=20
> the hypervisor, then libxc, then libxl, especially since they tend to=20
> have different maintainers and committers.
>
That's fine.

> > +A list of nodes should be specified as follows: `nodes=3D["0", "3"]`
> > +for the guest to be affine with nodes 0 and 3.
> > +
> Hmm, I think that using "affine" here is technically correct, and is=20
> what one would use if writing a research paper; but it's unusual to hear=
=20
> the word in more common English; it would be more common to hear someone=
=20
> describe a VM as "having affinity with".
>
I see...

> How about something like this:
>=20
> "The list of NUMA nodes the domain is considered to have affinity with. =
=20
> Memory from the guest will be allocated from these nodes."
>=20
Sounds good, I'll go for it. Thanks for looking at these stuff too, I
really need and enjoy some good English training! :-P

> Also, is there a way to specify that the affinity to be to all nodes=20
> and/or based on the vcpu mask of the vcpus?
>
Well, yes but no. :-) Actually, if you do not specify any affinity, the
default is right now 'all nodes'. As we might want to change that, I'll
add something like `nodes=3D"all"`. Similarly, if you don't specify any
"nodes=3D", and you have some vcpu-affinity, this patch won't call any
node_affinity setting routine, so that the default behavior of building
it up upon vcpu-affinity will be retained. Actually, even with the
following patches that introduces automatic placement, if no
node-affinity is specified, while a vcpu-affinity is, the algorithm will
try to place the domain where vcpu-affinity is saying.

So, summarizing, I'll add some means of saying "all nodes", while I
don't think anything is needed to say "do what vcpu-affinity wants", but
I'm more than open to suggestions and alternatives if you think this is
not good/clear enough.

> > +/**
> > + * This function explicitly sets the affinity of a domain with the
> > + * host NUMA nodes.
> > + *
> > + * @parm xch a handle to an open hypervisor interface.
> > + * @parm domid the domain id in which vcpus are to be created.
> > + * @parm node_affinity the map of the affine nodes.
> > + * @return 0 on success, -1 on failure.
> > + */
> > +int xc_domain_node_affinity(xc_interface *xch,
> > +                            uint32_t domind,
> > +                            xc_nodemap_t node_affinity);
> > +
> Seems like it would be useful to have both a get and a set.
>
Ok. Not right now, but I agree it would make it a more sane interface.
Will add a *_get_affinity (and change this to *_set_affinity)

> >   int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap=
 *cpumap)
> >   {
> >       GC_INIT(ctx);
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -727,6 +727,8 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
> >                              libxl_cpumap *cpumap);
> >   int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> >                                  unsigned int max_vcpus, libxl_cpumap *=
cpumap);
> > +int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
> > +                            libxl_nodemap *nodemap);
> Hmm -- is there really no libxl_get_vcpuaffinity()?  That seems to be a=
=20
> missing component...
>
Apparently not, seems like `xl vcpu-list' reaches out print_vcpuinfo()
(xl.c:4268 here) which figures out thing by its own with something like
this:

    /* CPU AFFINITY */
    print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout);

Should we change this?

> > +    }
> > +    else {
> > +        /*
> > +         * XXX What would a sane default be? I think doing nothing
> > +         *     (i.e., relying on cpu-affinity/cpupool =3D=3D>  the cur=
rent
> > +         *     behavior) should be just fine.
> > +         *     That would mean we're saying to the user "if you want u=
s
> > +         *     to take care of NUMA, please tell us, maybe just puttin=
g
> > +         *     'nodes=3Dauto', but tell us... otherwise we do as usual=
".
> > +         */
> I think that for this patch, doing nothing is fine (which means removing=
=20
> the whole else clause).  But once we have the auto placement, I think=20
> that "nodes=3Dauto" should be the default.
>
Ok, that makes sense. I'm running benchmarks comparing the three
different policies I've implemented so far (see patches 8 and 9), to
understand if they make any sense at all and, if they do, which one
would be better suited for being used as the default policy. Will post
the results as soon as they finish.

> > +    case XEN_DOMCTL_node_affinity:
> > +    {
> > +        domid_t dom =3D op->domain;
> > +        struct domain *d =3D rcu_lock_domain_by_id(dom);
> > +        nodemask_t new_affinity;
> > +
> > +        ret =3D -ESRCH;
> > +        if ( d =3D=3D NULL )
> > +            break;
> > +
> > +        /* XXX We need an xsm_* for this I guess, right? */
> Yes. :-)
>
Ok, I'll look into it and put it together for the next release of this
series. I'm planning to take great inspiration from the one in
*_vcpu_affinity, do you think that could be the right thing?

> > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -346,8 +346,12 @@ struct domain
> >       /* Various mem_events */
> >       struct mem_event_per_domain *mem_event;
> >
> > -    /* Currently computed from union of all vcpu cpu-affinity masks. *=
/
> > +    /*
> > +     * Can be specified by the user. If that is not the case, it is
> > +     * computed from the union of all the vcpu cpu-affinity masks.
> > +     */
> >       nodemask_t node_affinity;
> > +    int has_node_affinity;
> There's something that seems a bit clunky about this; but I can't really=
=20
> think of a better way.  At every least I'd change the name of the=20
> element here to something more descriptive; perhaps "auto_node_affinity"=
=20
> (which would invert the meaning)?
>
You know what, I really don't like this either, but I need something
that tells me whether I should compute the node affinity from
vcpu-affinity/cpupool or the user has set that to something I shouldn't
touch, and did not find any other way of doing such than adding this
"flag". I kind of took inspiration from d->is_pinned although, yes, I
know, that is used for different purposes.

Any suggestion is welcome, in the meanwhile, I'll change the name and
the semantic to what you're suggesting.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-LZ8ELMCpHrrBBTavRHqM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HVXEACgkQk4XaBE3IOsQzegCfbYTISuIT137BeUoVJTPy6uh8
aksAoKVWPyk0XPiY+3Cimw3u3/invBQc
=nwxO
-----END PGP SIGNATURE-----

--=-LZ8ELMCpHrrBBTavRHqM--



--===============5653723866298172454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5653723866298172454==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 22:22:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 22:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SISOe-0008Lv-0Z; Thu, 12 Apr 2012 22:21:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SISOc-0008Lp-B7
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 22:21:42 +0000
Received: from [85.158.143.99:3120] by server-1.bemta-4.messagelabs.com id
	B2/2D-20925-575578F4; Thu, 12 Apr 2012 22:21:41 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334269299!22516037!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15782 invoked from network); 12 Apr 2012 22:21:40 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-216.messagelabs.com with SMTP;
	12 Apr 2012 22:21:40 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77094164; Fri, 13 Apr 2012 00:21:38 +0200
Message-ID: <1334269297.2417.23.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 13 Apr 2012 00:21:37 +0200
In-Reply-To: <4F86AD6E.3050705@eu.citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5653723866298172454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5653723866298172454==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-LZ8ELMCpHrrBBTavRHqM"


--=-LZ8ELMCpHrrBBTavRHqM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 11:24 +0100, George Dunlap wrote:=20
> > A valid setting will directly impact the node_affinity mask
> > of the guest, i.e., it will change the behaviour of the low level
> > memory allocator. On the other hand, this commit does not affect
> > by any means how the guest's vCPUs are scheduled on the host's
> > pCPUs.
> I would probably break this into three separate patches, starting with=
=20
> the hypervisor, then libxc, then libxl, especially since they tend to=20
> have different maintainers and committers.
>
That's fine.

> > +A list of nodes should be specified as follows: `nodes=3D["0", "3"]`
> > +for the guest to be affine with nodes 0 and 3.
> > +
> Hmm, I think that using "affine" here is technically correct, and is=20
> what one would use if writing a research paper; but it's unusual to hear=
=20
> the word in more common English; it would be more common to hear someone=
=20
> describe a VM as "having affinity with".
>
I see...

> How about something like this:
>=20
> "The list of NUMA nodes the domain is considered to have affinity with. =
=20
> Memory from the guest will be allocated from these nodes."
>=20
Sounds good, I'll go for it. Thanks for looking at these stuff too, I
really need and enjoy some good English training! :-P

> Also, is there a way to specify that the affinity to be to all nodes=20
> and/or based on the vcpu mask of the vcpus?
>
Well, yes but no. :-) Actually, if you do not specify any affinity, the
default is right now 'all nodes'. As we might want to change that, I'll
add something like `nodes=3D"all"`. Similarly, if you don't specify any
"nodes=3D", and you have some vcpu-affinity, this patch won't call any
node_affinity setting routine, so that the default behavior of building
it up upon vcpu-affinity will be retained. Actually, even with the
following patches that introduces automatic placement, if no
node-affinity is specified, while a vcpu-affinity is, the algorithm will
try to place the domain where vcpu-affinity is saying.

So, summarizing, I'll add some means of saying "all nodes", while I
don't think anything is needed to say "do what vcpu-affinity wants", but
I'm more than open to suggestions and alternatives if you think this is
not good/clear enough.

> > +/**
> > + * This function explicitly sets the affinity of a domain with the
> > + * host NUMA nodes.
> > + *
> > + * @parm xch a handle to an open hypervisor interface.
> > + * @parm domid the domain id in which vcpus are to be created.
> > + * @parm node_affinity the map of the affine nodes.
> > + * @return 0 on success, -1 on failure.
> > + */
> > +int xc_domain_node_affinity(xc_interface *xch,
> > +                            uint32_t domind,
> > +                            xc_nodemap_t node_affinity);
> > +
> Seems like it would be useful to have both a get and a set.
>
Ok. Not right now, but I agree it would make it a more sane interface.
Will add a *_get_affinity (and change this to *_set_affinity)

> >   int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap=
 *cpumap)
> >   {
> >       GC_INIT(ctx);
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -727,6 +727,8 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
> >                              libxl_cpumap *cpumap);
> >   int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> >                                  unsigned int max_vcpus, libxl_cpumap *=
cpumap);
> > +int libxl_set_node_affinity(libxl_ctx *ctx, uint32_t domid,
> > +                            libxl_nodemap *nodemap);
> Hmm -- is there really no libxl_get_vcpuaffinity()?  That seems to be a=
=20
> missing component...
>
Apparently not, seems like `xl vcpu-list' reaches out print_vcpuinfo()
(xl.c:4268 here) which figures out thing by its own with something like
this:

    /* CPU AFFINITY */
    print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout);

Should we change this?

> > +    }
> > +    else {
> > +        /*
> > +         * XXX What would a sane default be? I think doing nothing
> > +         *     (i.e., relying on cpu-affinity/cpupool =3D=3D>  the cur=
rent
> > +         *     behavior) should be just fine.
> > +         *     That would mean we're saying to the user "if you want u=
s
> > +         *     to take care of NUMA, please tell us, maybe just puttin=
g
> > +         *     'nodes=3Dauto', but tell us... otherwise we do as usual=
".
> > +         */
> I think that for this patch, doing nothing is fine (which means removing=
=20
> the whole else clause).  But once we have the auto placement, I think=20
> that "nodes=3Dauto" should be the default.
>
Ok, that makes sense. I'm running benchmarks comparing the three
different policies I've implemented so far (see patches 8 and 9), to
understand if they make any sense at all and, if they do, which one
would be better suited for being used as the default policy. Will post
the results as soon as they finish.

> > +    case XEN_DOMCTL_node_affinity:
> > +    {
> > +        domid_t dom =3D op->domain;
> > +        struct domain *d =3D rcu_lock_domain_by_id(dom);
> > +        nodemask_t new_affinity;
> > +
> > +        ret =3D -ESRCH;
> > +        if ( d =3D=3D NULL )
> > +            break;
> > +
> > +        /* XXX We need an xsm_* for this I guess, right? */
> Yes. :-)
>
Ok, I'll look into it and put it together for the next release of this
series. I'm planning to take great inspiration from the one in
*_vcpu_affinity, do you think that could be the right thing?

> > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -346,8 +346,12 @@ struct domain
> >       /* Various mem_events */
> >       struct mem_event_per_domain *mem_event;
> >
> > -    /* Currently computed from union of all vcpu cpu-affinity masks. *=
/
> > +    /*
> > +     * Can be specified by the user. If that is not the case, it is
> > +     * computed from the union of all the vcpu cpu-affinity masks.
> > +     */
> >       nodemask_t node_affinity;
> > +    int has_node_affinity;
> There's something that seems a bit clunky about this; but I can't really=
=20
> think of a better way.  At every least I'd change the name of the=20
> element here to something more descriptive; perhaps "auto_node_affinity"=
=20
> (which would invert the meaning)?
>
You know what, I really don't like this either, but I need something
that tells me whether I should compute the node affinity from
vcpu-affinity/cpupool or the user has set that to something I shouldn't
touch, and did not find any other way of doing such than adding this
"flag". I kind of took inspiration from d->is_pinned although, yes, I
know, that is used for different purposes.

Any suggestion is welcome, in the meanwhile, I'll change the name and
the semantic to what you're suggesting.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-LZ8ELMCpHrrBBTavRHqM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HVXEACgkQk4XaBE3IOsQzegCfbYTISuIT137BeUoVJTPy6uh8
aksAoKVWPyk0XPiY+3Cimw3u3/invBQc
=nwxO
-----END PGP SIGNATURE-----

--=-LZ8ELMCpHrrBBTavRHqM--



--===============5653723866298172454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5653723866298172454==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 22:25:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 22:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SISSG-0008Vf-Qp; Thu, 12 Apr 2012 22:25:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SISSF-0008VX-6d
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 22:25:27 +0000
Received: from [85.158.143.35:18267] by server-1.bemta-4.messagelabs.com id
	68/3E-20925-656578F4; Thu, 12 Apr 2012 22:25:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334269525!4607793!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4393 invoked from network); 12 Apr 2012 22:25:25 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	12 Apr 2012 22:25:25 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77094475; Fri, 13 Apr 2012 00:25:24 +0200
Message-ID: <1334269523.2417.26.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 13 Apr 2012 00:25:23 +0200
In-Reply-To: <4F86B313.5010708@citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com> <4F86B313.5010708@citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6842765824549127613=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6842765824549127613==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ixuquBtDMt2N8+2FSNqx"


--=-ixuquBtDMt2N8+2FSNqx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 11:48 +0100, David Vrabel wrote:=20
> > Hmm, I think that using "affine" here is technically correct, and is
> > what one would use if writing a research paper; but it's unusual to hea=
r
> > the word in more common English; it would be more common to hear someon=
e
> > describe a VM as "having affinity with".  How about something like this=
:
> >=20
> > "The list of NUMA nodes the domain is considered to have affinity with.=
=20
> > Memory from the guest will be allocated from these nodes."
>=20
> That's clunky sentence, the "considered" doesn't add anything.  Or perhap=
s:
>=20
> "The NUMA nodes preferred by the guest.  Memory for the guest will be
> allocated on these nodes."
>=20
Wow, that is even cooler, thanks! :-)

> The need for quotes around the node numbers is odd.  Can that
> requirement be removed?
>=20
I'm not sure I ever checked/tried doing that. It's the plain libxl
parser for lists, which I've always seen taking strings in all the
examples I found, but I haven't ever looked at the actual code... I'll
figure that out and, if possible, get rid of them. I agree they're
disturbing.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ixuquBtDMt2N8+2FSNqx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HVlMACgkQk4XaBE3IOsRCCwCfcqA+lbuMOUp50er3gSYVSmq8
fcAAnjjgPb682W3ZLccGWfLaTJnV4nT7
=fSDC
-----END PGP SIGNATURE-----

--=-ixuquBtDMt2N8+2FSNqx--



--===============6842765824549127613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6842765824549127613==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 22:25:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 22:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SISSG-0008Vf-Qp; Thu, 12 Apr 2012 22:25:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SISSF-0008VX-6d
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 22:25:27 +0000
Received: from [85.158.143.35:18267] by server-1.bemta-4.messagelabs.com id
	68/3E-20925-656578F4; Thu, 12 Apr 2012 22:25:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334269525!4607793!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4393 invoked from network); 12 Apr 2012 22:25:25 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	12 Apr 2012 22:25:25 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77094475; Fri, 13 Apr 2012 00:25:24 +0200
Message-ID: <1334269523.2417.26.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 13 Apr 2012 00:25:23 +0200
In-Reply-To: <4F86B313.5010708@citrix.com>
References: <patchbomb.1334150267@Solace>
	<7e76233448b02810f0ae.1334150272@Solace>
	<4F86AD6E.3050705@eu.citrix.com> <4F86B313.5010708@citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10 [RFC]] xl: Explicit node affinity
 specification for guests via config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6842765824549127613=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6842765824549127613==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ixuquBtDMt2N8+2FSNqx"


--=-ixuquBtDMt2N8+2FSNqx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-04-12 at 11:48 +0100, David Vrabel wrote:=20
> > Hmm, I think that using "affine" here is technically correct, and is
> > what one would use if writing a research paper; but it's unusual to hea=
r
> > the word in more common English; it would be more common to hear someon=
e
> > describe a VM as "having affinity with".  How about something like this=
:
> >=20
> > "The list of NUMA nodes the domain is considered to have affinity with.=
=20
> > Memory from the guest will be allocated from these nodes."
>=20
> That's clunky sentence, the "considered" doesn't add anything.  Or perhap=
s:
>=20
> "The NUMA nodes preferred by the guest.  Memory for the guest will be
> allocated on these nodes."
>=20
Wow, that is even cooler, thanks! :-)

> The need for quotes around the node numbers is odd.  Can that
> requirement be removed?
>=20
I'm not sure I ever checked/tried doing that. It's the plain libxl
parser for lists, which I've always seen taking strings in all the
examples I found, but I haven't ever looked at the actual code... I'll
figure that out and, if possible, get rid of them. I agree they're
disturbing.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ixuquBtDMt2N8+2FSNqx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HVlMACgkQk4XaBE3IOsRCCwCfcqA+lbuMOUp50er3gSYVSmq8
fcAAnjjgPb682W3ZLccGWfLaTJnV4nT7
=fSDC
-----END PGP SIGNATURE-----

--=-ixuquBtDMt2N8+2FSNqx--



--===============6842765824549127613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6842765824549127613==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 23:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 23:07:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIT6G-0000Pr-82; Thu, 12 Apr 2012 23:06:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIT6E-0000Pk-Ba
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 23:06:46 +0000
Received: from [85.158.138.51:58430] by server-2.bemta-3.messagelabs.com id
	5A/84-09269-400678F4; Thu, 12 Apr 2012 23:06:44 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334272002!17735310!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18072 invoked from network); 12 Apr 2012 23:06:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 23:06:42 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77095017; Fri, 13 Apr 2012 01:06:42 +0200
Message-ID: <1334271995.2417.49.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Date: Fri, 13 Apr 2012 01:06:35 +0200
In-Reply-To: <1f4b55806de9e7109ff6.1334150274@Solace>
References: <patchbomb.1334150267@Solace>
	<1f4b55806de9e7109ff6.1334150274@Solace>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the
 scheduler know about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4242401788805767873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4242401788805767873==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-LM2ZLqsghGK+GGRy7bn+"


--=-LM2ZLqsghGK+GGRy7bn+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 15:17 +0200, Dario Faggioli wrote:=20
> Basic idea is: cpu-affinity tells where a vcpu can run,
> while node-affinity tells where (in terms of on what NUMA nodes,
> but that of course imply a set of CPUs) all the vcpus of the
> domain should/prefer to run... Problems starts when you have
> both of them speaking at the same time!
>
> <snip>
>=20
> XXX I'm benchmarking this just right now, and peeking at the results
>     they don't seem too bad. Numbers are mostly close to the case where
>     the VM is already pinned to a node when created. I'll post the
>     results as soon as I can, and I'll be happy to investigate any issue,
>     if you feel like the approach could be the right one.
>=20
Some of them are ready, and here they come:

  http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa/index.ht=
ml

Look, for example, at this one here:

 http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa/kernbench=
_avgstd.png

Where the red line is the default Xen behavior (no pinning, no affinity,
nothing!), the dark blue line is the best case (domain pinned at
creation =3D=3D> all memory accesses are local) and the light blue line is
this one patch in action, i.e., domain _with_affinity_ to node #0 and no
pinning at all.

It's very nice (at least for me! :-D) to see it almost always does
better than default, and it manage in getting quite close to the best
case scenario when load increases.
Still on the "nice things" side, there doesn't appear to be
significative regressions introduced by this patch, if the new
node-affinity feature is not stressed, as it shows by comparing the
"before" and "after" the patch graphs (looking at matching curves):

(before) http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005/kernbe=
nch_avgstd.png
 (after)  http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa/=
kernbench_avgstd.png

Unfortunately, there seems to be at least some issues with the cases
where load is not so high. In fact, given VMs have 4 vcpus and host has
16 pcpus, there are less vcpus than pcpus up to the run involving 4 VMs,
which is actually where things starts to work well, while before they're
near or even worst than default! :-O

Any thoughts?

Again, if you think the approach taken here could be a sensible one,
I'll start digging what's going on (by some tracing etc.), and I'm sure
I can work out the low-load cases and "persuade" them to behave
better. :-D

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-LM2ZLqsghGK+GGRy7bn+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HX/sACgkQk4XaBE3IOsRZ3ACeI3HRaMCTj1thjVBvqYr60fte
fIYAnAxk/qKzo8bOaoY99B0GTDcGY0Q5
=Kbxl
-----END PGP SIGNATURE-----

--=-LM2ZLqsghGK+GGRy7bn+--



--===============4242401788805767873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4242401788805767873==--



From xen-devel-bounces@lists.xen.org Thu Apr 12 23:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Apr 2012 23:07:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIT6G-0000Pr-82; Thu, 12 Apr 2012 23:06:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIT6E-0000Pk-Ba
	for xen-devel@lists.xen.org; Thu, 12 Apr 2012 23:06:46 +0000
Received: from [85.158.138.51:58430] by server-2.bemta-3.messagelabs.com id
	5A/84-09269-400678F4; Thu, 12 Apr 2012 23:06:44 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334272002!17735310!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18072 invoked from network); 12 Apr 2012 23:06:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-174.messagelabs.com with SMTP;
	12 Apr 2012 23:06:42 -0000
Received: from [83.211.177.101] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77095017; Fri, 13 Apr 2012 01:06:42 +0200
Message-ID: <1334271995.2417.49.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Date: Fri, 13 Apr 2012 01:06:35 +0200
In-Reply-To: <1f4b55806de9e7109ff6.1334150274@Solace>
References: <patchbomb.1334150267@Solace>
	<1f4b55806de9e7109ff6.1334150274@Solace>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the
 scheduler know about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4242401788805767873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4242401788805767873==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-LM2ZLqsghGK+GGRy7bn+"


--=-LM2ZLqsghGK+GGRy7bn+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 15:17 +0200, Dario Faggioli wrote:=20
> Basic idea is: cpu-affinity tells where a vcpu can run,
> while node-affinity tells where (in terms of on what NUMA nodes,
> but that of course imply a set of CPUs) all the vcpus of the
> domain should/prefer to run... Problems starts when you have
> both of them speaking at the same time!
>
> <snip>
>=20
> XXX I'm benchmarking this just right now, and peeking at the results
>     they don't seem too bad. Numbers are mostly close to the case where
>     the VM is already pinned to a node when created. I'll post the
>     results as soon as I can, and I'll be happy to investigate any issue,
>     if you feel like the approach could be the right one.
>=20
Some of them are ready, and here they come:

  http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa/index.ht=
ml

Look, for example, at this one here:

 http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa/kernbench=
_avgstd.png

Where the red line is the default Xen behavior (no pinning, no affinity,
nothing!), the dark blue line is the best case (domain pinned at
creation =3D=3D> all memory accesses are local) and the light blue line is
this one patch in action, i.e., domain _with_affinity_ to node #0 and no
pinning at all.

It's very nice (at least for me! :-D) to see it almost always does
better than default, and it manage in getting quite close to the best
case scenario when load increases.
Still on the "nice things" side, there doesn't appear to be
significative regressions introduced by this patch, if the new
node-affinity feature is not stressed, as it shows by comparing the
"before" and "after" the patch graphs (looking at matching curves):

(before) http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005/kernbe=
nch_avgstd.png
 (after)  http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa/=
kernbench_avgstd.png

Unfortunately, there seems to be at least some issues with the cases
where load is not so high. In fact, given VMs have 4 vcpus and host has
16 pcpus, there are less vcpus than pcpus up to the run involving 4 VMs,
which is actually where things starts to work well, while before they're
near or even worst than default! :-O

Any thoughts?

Again, if you think the approach taken here could be a sensible one,
I'll start digging what's going on (by some tracing etc.), and I'm sure
I can work out the low-load cases and "persuade" them to behave
better. :-D

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-LM2ZLqsghGK+GGRy7bn+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+HX/sACgkQk4XaBE3IOsRZ3ACeI3HRaMCTj1thjVBvqYr60fte
fIYAnAxk/qKzo8bOaoY99B0GTDcGY0Q5
=Kbxl
-----END PGP SIGNATURE-----

--=-LM2ZLqsghGK+GGRy7bn+--



--===============4242401788805767873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4242401788805767873==--



From xen-devel-bounces@lists.xen.org Fri Apr 13 00:04:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 00:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SITzK-0001XV-5v; Fri, 13 Apr 2012 00:03:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SITzJ-0001XQ-I8
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 00:03:41 +0000
Received: from [85.158.143.35:25116] by server-3.bemta-4.messagelabs.com id
	55/D1-05853-C5D678F4; Fri, 13 Apr 2012 00:03:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334275420!4718099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20824 invoked from network); 13 Apr 2012 00:03:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 00:03:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,414,1330905600"; d="scan'208";a="11913930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 00:03:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 01:03:39 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SITzH-0002qJ-BS;
	Fri, 13 Apr 2012 00:03:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SITzH-0001Zj-4d;
	Fri, 13 Apr 2012 01:03:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12663-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 01:03:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12663: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12663 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12663/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 12640
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 12640
 test-amd64-i386-xend-qemuu-winxpsp3  3 host-install(3)  broken REGR. vs. 12640

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12640

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 00:04:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 00:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SITzK-0001XV-5v; Fri, 13 Apr 2012 00:03:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SITzJ-0001XQ-I8
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 00:03:41 +0000
Received: from [85.158.143.35:25116] by server-3.bemta-4.messagelabs.com id
	55/D1-05853-C5D678F4; Fri, 13 Apr 2012 00:03:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334275420!4718099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20824 invoked from network); 13 Apr 2012 00:03:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 00:03:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,414,1330905600"; d="scan'208";a="11913930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 00:03:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 01:03:39 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SITzH-0002qJ-BS;
	Fri, 13 Apr 2012 00:03:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SITzH-0001Zj-4d;
	Fri, 13 Apr 2012 01:03:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12663-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 01:03:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12663: regressions -
	trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12663 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12663/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 12640
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 12640
 test-amd64-i386-xend-qemuu-winxpsp3  3 host-install(3)  broken REGR. vs. 12640

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12640

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 02:15:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 02:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIW2G-0006Pq-RX; Fri, 13 Apr 2012 02:14:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SIW2F-0006Pl-3p
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 02:14:51 +0000
Received: from [193.109.254.147:61730] by server-5.bemta-14.messagelabs.com id
	A4/F4-30733-A1C878F4; Fri, 13 Apr 2012 02:14:50 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334283289!4398298!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYzMTMw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11481 invoked from network); 13 Apr 2012 02:14:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-27.messagelabs.com with SMTP;
	13 Apr 2012 02:14:49 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 12 Apr 2012 19:14:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88541505"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 12 Apr 2012 19:14:47 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 12 Apr 2012 19:14:47 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.125]) with mapi id
	14.01.0355.002; Fri, 13 Apr 2012 10:14:42 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>, Keir Fraser
	<keir@xen.org>
Thread-Topic: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
Thread-Index: AQHNGK0SValDuNDgj0mS7aEFU/pTFpaX+1HA
Date: Fri, 13 Apr 2012 02:14:42 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
References: <4F86D464.4080601@amd.com>
In-Reply-To: <4F86D464.4080601@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Huang <wei.huang2@amd.com>, "Ostrovsky,
	Boris" <Boris.Ostrovsky@amd.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should not be enough. No need to check bm when going to C2.
How about the following patch:
diff -r d35a117afa2f xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c      Tue Mar 27 15:25:07 2012 +0200
+++ b/xen/arch/x86/acpi/cpu_idle.c      Fri Apr 13 10:10:31 2012 +0800
@@ -493,7 +493,8 @@ static void acpi_processor_idle(void)
          * not set. In that case we cannot do much, we enter C3
          * without doing anything.
          */
-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) && power->flags.bm_check
+                                          && power->flags.bm_control )
         {
             spin_lock(&c3_cpu_status.lock);
             if ( ++c3_cpu_status.count == num_online_cpus() )
@@ -509,13 +510,14 @@ static void acpi_processor_idle(void)
         else if ( !power->flags.bm_check )
         {
             /* SMP with no shared cache... Invalidate cache  */
-            ACPI_FLUSH_CPU_CACHE();
+            if ( cx->type == ACPI_STATE_C3 )
+                ACPI_FLUSH_CPU_CACHE();
         }
-
         /* Invoke C3 */
         acpi_idle_do_entry(cx);

-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) && power->flags.bm_check
+                                        && power->flags.bm_control )
         {
             /* Enable bus master arbitration */
             spin_lock(&c3_cpu_status.lock);

best regards
yang


> -----Original Message-----
> From: Wei Wang [mailto:wei.wang2@amd.com]
> Sent: Thursday, April 12, 2012 9:11 PM
> To: Jan Beulich; Keir Fraser
> Cc: Zhang, Yang Z; xen-devel@lists.xensource.com; Andre Przywara; Ostrovsky,
> Boris; Wei Huang
> Subject: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> Hi Jan,
> This is a revised fix from my last post[1]. We found that the performance
> issue[2] is actually caused by an unnecessary cache flush when fall-through
> happens. According to acpi spec, c2 has cache consistency, we don't need
> cache flush if cx->type != ACPI_STATE_C3.
> This fix improves performance of some OEM systems significantly. I would
> suggest to back port it to 4.1, 4.0 and even 3.4.
> 
> Thanks,
> We
> 
> [1]
> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00395.html
> [2]
> http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0
> 
> # HG changeset patch
> # Parent 6efb9f934bfb4c46af375612fb01e65d15518380
> # User Wei Wang <wei.wang2@amd.com>
> acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 6efb9f934bfb -r 85775fd04cf4 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 05 11:24:26 2012 +0100
> +++ b/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 12 14:15:09 2012 +0200
> @@ -509,7 +509,8 @@ static void acpi_processor_idle(void)
>           else if ( !power->flags.bm_check )
>           {
>               /* SMP with no shared cache... Invalidate cache  */
> -            ACPI_FLUSH_CPU_CACHE();
> +            if ( cx->type == ACPI_STATE_C3 )
> +                ACPI_FLUSH_CPU_CACHE();
>           }
> 
>           /* Invoke C3 */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 02:15:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 02:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIW2G-0006Pq-RX; Fri, 13 Apr 2012 02:14:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SIW2F-0006Pl-3p
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 02:14:51 +0000
Received: from [193.109.254.147:61730] by server-5.bemta-14.messagelabs.com id
	A4/F4-30733-A1C878F4; Fri, 13 Apr 2012 02:14:50 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334283289!4398298!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYzMTMw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11481 invoked from network); 13 Apr 2012 02:14:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-27.messagelabs.com with SMTP;
	13 Apr 2012 02:14:49 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 12 Apr 2012 19:14:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88541505"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 12 Apr 2012 19:14:47 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 12 Apr 2012 19:14:47 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.125]) with mapi id
	14.01.0355.002; Fri, 13 Apr 2012 10:14:42 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>, Keir Fraser
	<keir@xen.org>
Thread-Topic: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
Thread-Index: AQHNGK0SValDuNDgj0mS7aEFU/pTFpaX+1HA
Date: Fri, 13 Apr 2012 02:14:42 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
References: <4F86D464.4080601@amd.com>
In-Reply-To: <4F86D464.4080601@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Huang <wei.huang2@amd.com>, "Ostrovsky,
	Boris" <Boris.Ostrovsky@amd.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should not be enough. No need to check bm when going to C2.
How about the following patch:
diff -r d35a117afa2f xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c      Tue Mar 27 15:25:07 2012 +0200
+++ b/xen/arch/x86/acpi/cpu_idle.c      Fri Apr 13 10:10:31 2012 +0800
@@ -493,7 +493,8 @@ static void acpi_processor_idle(void)
          * not set. In that case we cannot do much, we enter C3
          * without doing anything.
          */
-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) && power->flags.bm_check
+                                          && power->flags.bm_control )
         {
             spin_lock(&c3_cpu_status.lock);
             if ( ++c3_cpu_status.count == num_online_cpus() )
@@ -509,13 +510,14 @@ static void acpi_processor_idle(void)
         else if ( !power->flags.bm_check )
         {
             /* SMP with no shared cache... Invalidate cache  */
-            ACPI_FLUSH_CPU_CACHE();
+            if ( cx->type == ACPI_STATE_C3 )
+                ACPI_FLUSH_CPU_CACHE();
         }
-
         /* Invoke C3 */
         acpi_idle_do_entry(cx);

-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) && power->flags.bm_check
+                                        && power->flags.bm_control )
         {
             /* Enable bus master arbitration */
             spin_lock(&c3_cpu_status.lock);

best regards
yang


> -----Original Message-----
> From: Wei Wang [mailto:wei.wang2@amd.com]
> Sent: Thursday, April 12, 2012 9:11 PM
> To: Jan Beulich; Keir Fraser
> Cc: Zhang, Yang Z; xen-devel@lists.xensource.com; Andre Przywara; Ostrovsky,
> Boris; Wei Huang
> Subject: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> Hi Jan,
> This is a revised fix from my last post[1]. We found that the performance
> issue[2] is actually caused by an unnecessary cache flush when fall-through
> happens. According to acpi spec, c2 has cache consistency, we don't need
> cache flush if cx->type != ACPI_STATE_C3.
> This fix improves performance of some OEM systems significantly. I would
> suggest to back port it to 4.1, 4.0 and even 3.4.
> 
> Thanks,
> We
> 
> [1]
> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00395.html
> [2]
> http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0
> 
> # HG changeset patch
> # Parent 6efb9f934bfb4c46af375612fb01e65d15518380
> # User Wei Wang <wei.wang2@amd.com>
> acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 6efb9f934bfb -r 85775fd04cf4 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 05 11:24:26 2012 +0100
> +++ b/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 12 14:15:09 2012 +0200
> @@ -509,7 +509,8 @@ static void acpi_processor_idle(void)
>           else if ( !power->flags.bm_check )
>           {
>               /* SMP with no shared cache... Invalidate cache  */
> -            ACPI_FLUSH_CPU_CACHE();
> +            if ( cx->type == ACPI_STATE_C3 )
> +                ACPI_FLUSH_CPU_CACHE();
>           }
> 
>           /* Invoke C3 */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 02:29:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 02:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWG3-0006Za-8x; Fri, 13 Apr 2012 02:29:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1SIWG1-0006ZV-2F
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 02:29:05 +0000
Received: from [85.158.138.51:37399] by server-8.bemta-3.messagelabs.com id
	20/89-24428-07F878F4; Fri, 13 Apr 2012 02:29:04 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334284143!21976175!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11871 invoked from network); 13 Apr 2012 02:29:03 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 02:29:03 -0000
Received: by wgbdr12 with SMTP id dr12so2159269wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 19:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=4S3kX47RbPO2QNkO8Eit3jn/1+uif0MNXTc8gjfFwU0=;
	b=I+s0rl9RxZqEat7v4DzL8l3S8vFcYNJSfkrrUQ8HeEftLAzykGuttkQoFwtCvkaPMP
	jbNRsaehzWMv4/h74UFwnufGOVGZGW5a4HaKkUNshcY6fmQeBJb74PBdHvxxQE+Im9et
	qaQtZyd7CBU/v4XphIYu7l/g+X2wOPbMYKP6lDsFvdcW9gFbLciRsnL9KHA0TkkhYnux
	fduIFKw+fQeo+VxNP3I3B1xnKODs14ta6I0dQ3V+ylMyFfUSv6GOpIPpdK19moWmtc2i
	ula/qLxov2sjZ/HB2gBHjpsggKGE9O39x8JHB8QcKnuCl+FDWR1VablYUa57ulrO0QEM
	581Q==
MIME-Version: 1.0
Received: by 10.180.97.4 with SMTP id dw4mr721128wib.18.1334284142624; Thu, 12
	Apr 2012 19:29:02 -0700 (PDT)
Received: by 10.180.85.103 with HTTP; Thu, 12 Apr 2012 19:29:02 -0700 (PDT)
In-Reply-To: <4400B41FB768044EA720935D0808176C090BCDDC@sausexdag02.amd.com>
References: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BCDA7@sausexdag02.amd.com>
	<4400B41FB768044EA720935D0808176C090BCDDC@sausexdag02.amd.com>
Date: Thu, 12 Apr 2012 22:29:02 -0400
Message-ID: <CAMTrTqVd1kax4bCQCSmM2sWcQWv=y9SofkJFSa2dD_Qb-Su43g@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: "Huang2, Wei" <Wei.Huang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Understanding AMD NPT in xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This clarifies everything. Thanks.

- Hui

On Thu, Apr 12, 2012 at 5:50 PM, Huang2, Wei <Wei.Huang2@amd.com> wrote:
> Reformat:
>
> 1. To find out gPML4E
> * Traverse nested page table using gCR3 to locate guest level-4 page (PML4 table)
> * Use PML4 offset (bit 47:39) to get the value of gPML4E
>
> 2. To find out gPDPE
> * Traverse nested page table using gPML4E to locate guest level-3 page (PDP table)
> * Use PDP offset (bit 38:30) to get the value of gPDPE
>
> 3. To find out gPDE
> * Traverse nested page table using gPDPE to locate guest level-2 page (PD table)
> * Use PD offset (bit 29:21) to get the value of gPDE
>
> 4. To find out gPTE
> * Traverse nested page table using gPDE to locate guest level-1 page (PT table)
> * Use PT offset (bit 20:12) to get the value of gPTE
>
> 5. To find out gData
> * Traverse nested page table using gPTE to locate guest data page
> * Use physical page offset (bit 11:0) to get the data value
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Huang2, Wei
> Sent: Thursday, April 12, 2012 4:35 PM
> To: Steven; Wang2, Wei; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Understanding AMD NPT in xen
>
> White page info is more accurate. The slides was a bit vague. Here are the steps, assuming that CPU doesn't have TLB:
>
> 1. To find out gPML4E
> * Traverse nested page table using gCR3 to locate guest level-4 page (PML4 table)
> * Use PML4 offset (bit 47:39) to get the value of gPML4E
> 2. To find out gPDPE
> * Traverse nested page table using gPML4E to locate guest level-3 page (PDP table)
> * Use PDP offset (bit 38:30) to get the value of gPDPE
> 3. To find out gPDE
> * Traverse nested page table using gPDPE to locate guest level-2 page (PD table)
> * Use PD offset (bit 29:21) to get the value of gPDE
> 4. To find out gPTE
> * Traverse nested page table using gPDE to locate guest level-1 page (PT table)
> * Use PT offset (bit 20:12) to get the value of gPTE
> 5. To find out gData
> * Traverse nested page table using gPTE to locate guest data page
> * Use physical page offset (bit 11:0) to get the data value
>
> TLB will accelerate this walking significantly.
>
> -Wei
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Steven
> Sent: Thursday, April 12, 2012 12:06 PM
> To: Wang2, Wei; xen-devel@lists.xensource.com
> Subject: [Xen-devel] Understanding AMD NPT in xen
>
> Hi, Wei,
> I have read you slides in xen summit 2007 about NPT in AMD, "AMD
> Barcelona and Nested Paging Support in Xen".
> However, I have some question regarding the nested page walk in your slide 8.
>
> In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
> I assume that it use the [47:39] bit of gVA.
> However, in another AMD white paper, "AMD-VTM Nested Paging".
> http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
> In its figure 4, I saw that the first step is to translate gCR3 using
> nested page walk and then combine with the gVA[47:39] to read the
> table entry.
>
> These two documents look having different order of reading the guest
> page table. In the slides, it first get_PML4. But in the white paper,
> it first does nested page walk.
> I am wondering which one is true. Thanks.
>
> - ha
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 02:29:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 02:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWG3-0006Za-8x; Fri, 13 Apr 2012 02:29:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1SIWG1-0006ZV-2F
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 02:29:05 +0000
Received: from [85.158.138.51:37399] by server-8.bemta-3.messagelabs.com id
	20/89-24428-07F878F4; Fri, 13 Apr 2012 02:29:04 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334284143!21976175!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11871 invoked from network); 13 Apr 2012 02:29:03 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 02:29:03 -0000
Received: by wgbdr12 with SMTP id dr12so2159269wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Apr 2012 19:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=4S3kX47RbPO2QNkO8Eit3jn/1+uif0MNXTc8gjfFwU0=;
	b=I+s0rl9RxZqEat7v4DzL8l3S8vFcYNJSfkrrUQ8HeEftLAzykGuttkQoFwtCvkaPMP
	jbNRsaehzWMv4/h74UFwnufGOVGZGW5a4HaKkUNshcY6fmQeBJb74PBdHvxxQE+Im9et
	qaQtZyd7CBU/v4XphIYu7l/g+X2wOPbMYKP6lDsFvdcW9gFbLciRsnL9KHA0TkkhYnux
	fduIFKw+fQeo+VxNP3I3B1xnKODs14ta6I0dQ3V+ylMyFfUSv6GOpIPpdK19moWmtc2i
	ula/qLxov2sjZ/HB2gBHjpsggKGE9O39x8JHB8QcKnuCl+FDWR1VablYUa57ulrO0QEM
	581Q==
MIME-Version: 1.0
Received: by 10.180.97.4 with SMTP id dw4mr721128wib.18.1334284142624; Thu, 12
	Apr 2012 19:29:02 -0700 (PDT)
Received: by 10.180.85.103 with HTTP; Thu, 12 Apr 2012 19:29:02 -0700 (PDT)
In-Reply-To: <4400B41FB768044EA720935D0808176C090BCDDC@sausexdag02.amd.com>
References: <CAMTrTqUDFhgQhNDbTmDDWDkhdb3bhMfVHj+whxxG6MQ5ApiC=A@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BCDA7@sausexdag02.amd.com>
	<4400B41FB768044EA720935D0808176C090BCDDC@sausexdag02.amd.com>
Date: Thu, 12 Apr 2012 22:29:02 -0400
Message-ID: <CAMTrTqVd1kax4bCQCSmM2sWcQWv=y9SofkJFSa2dD_Qb-Su43g@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: "Huang2, Wei" <Wei.Huang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Understanding AMD NPT in xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This clarifies everything. Thanks.

- Hui

On Thu, Apr 12, 2012 at 5:50 PM, Huang2, Wei <Wei.Huang2@amd.com> wrote:
> Reformat:
>
> 1. To find out gPML4E
> * Traverse nested page table using gCR3 to locate guest level-4 page (PML4 table)
> * Use PML4 offset (bit 47:39) to get the value of gPML4E
>
> 2. To find out gPDPE
> * Traverse nested page table using gPML4E to locate guest level-3 page (PDP table)
> * Use PDP offset (bit 38:30) to get the value of gPDPE
>
> 3. To find out gPDE
> * Traverse nested page table using gPDPE to locate guest level-2 page (PD table)
> * Use PD offset (bit 29:21) to get the value of gPDE
>
> 4. To find out gPTE
> * Traverse nested page table using gPDE to locate guest level-1 page (PT table)
> * Use PT offset (bit 20:12) to get the value of gPTE
>
> 5. To find out gData
> * Traverse nested page table using gPTE to locate guest data page
> * Use physical page offset (bit 11:0) to get the data value
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Huang2, Wei
> Sent: Thursday, April 12, 2012 4:35 PM
> To: Steven; Wang2, Wei; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Understanding AMD NPT in xen
>
> White page info is more accurate. The slides was a bit vague. Here are the steps, assuming that CPU doesn't have TLB:
>
> 1. To find out gPML4E
> * Traverse nested page table using gCR3 to locate guest level-4 page (PML4 table)
> * Use PML4 offset (bit 47:39) to get the value of gPML4E
> 2. To find out gPDPE
> * Traverse nested page table using gPML4E to locate guest level-3 page (PDP table)
> * Use PDP offset (bit 38:30) to get the value of gPDPE
> 3. To find out gPDE
> * Traverse nested page table using gPDPE to locate guest level-2 page (PD table)
> * Use PD offset (bit 29:21) to get the value of gPDE
> 4. To find out gPTE
> * Traverse nested page table using gPDE to locate guest level-1 page (PT table)
> * Use PT offset (bit 20:12) to get the value of gPTE
> 5. To find out gData
> * Traverse nested page table using gPTE to locate guest data page
> * Use physical page offset (bit 11:0) to get the data value
>
> TLB will accelerate this walking significantly.
>
> -Wei
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Steven
> Sent: Thursday, April 12, 2012 12:06 PM
> To: Wang2, Wei; xen-devel@lists.xensource.com
> Subject: [Xen-devel] Understanding AMD NPT in xen
>
> Hi, Wei,
> I have read you slides in xen summit 2007 about NPT in AMD, "AMD
> Barcelona and Nested Paging Support in Xen".
> However, I have some question regarding the nested page walk in your slide 8.
>
> In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
> I assume that it use the [47:39] bit of gVA.
> However, in another AMD white paper, "AMD-VTM Nested Paging".
> http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf
> In its figure 4, I saw that the first step is to translate gCR3 using
> nested page walk and then combine with the gVA[47:39] to read the
> table entry.
>
> These two documents look having different order of reading the guest
> page table. In the slides, it first get_PML4. But in the white paper,
> it first does nested page walk.
> I am wondering which one is true. Thanks.
>
> - ha
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 02:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 02:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWgA-0006pL-MH; Fri, 13 Apr 2012 02:56:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIWg9-0006pG-Dv
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 02:56:05 +0000
Received: from [85.158.138.51:26463] by server-3.bemta-3.messagelabs.com id
	5B/14-04048-4C5978F4; Fri, 13 Apr 2012 02:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334285763!21953936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17640 invoked from network); 13 Apr 2012 02:56:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 02:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,414,1330905600"; d="scan'208";a="11914486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 02:55:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 03:55:50 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIWfu-0003ln-Ea;
	Fri, 13 Apr 2012 02:55:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIWft-0003YP-TS;
	Fri, 13 Apr 2012 03:55:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12667-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 03:55:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12667: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12667 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12667/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 12578

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 02:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 02:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWgA-0006pL-MH; Fri, 13 Apr 2012 02:56:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIWg9-0006pG-Dv
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 02:56:05 +0000
Received: from [85.158.138.51:26463] by server-3.bemta-3.messagelabs.com id
	5B/14-04048-4C5978F4; Fri, 13 Apr 2012 02:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334285763!21953936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17640 invoked from network); 13 Apr 2012 02:56:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 02:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,414,1330905600"; d="scan'208";a="11914486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 02:55:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 03:55:50 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIWfu-0003ln-Ea;
	Fri, 13 Apr 2012 02:55:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIWft-0003YP-TS;
	Fri, 13 Apr 2012 03:55:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12667-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 03:55:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12667: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12667 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12667/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 12578

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmW-00071f-Kn; Fri, 13 Apr 2012 03:02:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SHtbY-00042b-Lk
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 09:12:44 +0000
Received: from [85.158.138.51:34359] by server-6.bemta-3.messagelabs.com id
	8F/DF-05145-B0B458F4; Wed, 11 Apr 2012 09:12:43 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334135561!21555497!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNDk5OTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 11 Apr 2012 09:12:43 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 09:12:43 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 05:12:40 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 04:12:32 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Wed, 11 Apr 2012 14:41:48 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334135513@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Apr 2012 17:11:53 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041105124005501
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmW-00071f-Kn; Fri, 13 Apr 2012 03:02:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SHtbY-00042b-Lk
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 09:12:44 +0000
Received: from [85.158.138.51:34359] by server-6.bemta-3.messagelabs.com id
	8F/DF-05145-B0B458F4; Wed, 11 Apr 2012 09:12:43 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334135561!21555497!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNDk5OTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 11 Apr 2012 09:12:43 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 09:12:43 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 05:12:40 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 04:12:32 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Wed, 11 Apr 2012 14:41:48 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334135513@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Apr 2012 17:11:53 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041105124005501
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmW-00071m-Vu; Fri, 13 Apr 2012 03:02:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SHu7a-0005Ie-JF
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 09:45:50 +0000
Received: from [85.158.138.51:15286] by server-4.bemta-3.messagelabs.com id
	D2/63-15341-DC2558F4; Wed, 11 Apr 2012 09:45:49 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334137547!21682699!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNDk5OTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26360 invoked from network); 11 Apr 2012 09:45:48 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 09:45:48 -0000
Received: from HCAZUSCH2.hitachiconsulting.net (63.148.190.199
	[63.148.190.199]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 05:45:46 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 04:45:43 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Wed, 11 Apr 2012 15:13:38 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334137422@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Apr 2012 17:43:42 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041105454603001
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmW-00071m-Vu; Fri, 13 Apr 2012 03:02:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SHu7a-0005Ie-JF
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 09:45:50 +0000
Received: from [85.158.138.51:15286] by server-4.bemta-3.messagelabs.com id
	D2/63-15341-DC2558F4; Wed, 11 Apr 2012 09:45:49 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334137547!21682699!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNDk5OTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26360 invoked from network); 11 Apr 2012 09:45:48 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 09:45:48 -0000
Received: from HCAZUSCH2.hitachiconsulting.net (63.148.190.199
	[63.148.190.199]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 05:45:46 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 04:45:43 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Wed, 11 Apr 2012 15:13:38 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334137422@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Apr 2012 17:43:42 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041105454603001
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmX-000724-N2; Fri, 13 Apr 2012 03:02:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SI8zW-00072y-2Y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 01:38:30 +0000
Received: from [85.158.139.83:49973] by server-12.bemta-5.messagelabs.com id
	4B/11-05587-512368F4; Thu, 12 Apr 2012 01:38:29 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334194707!19155336!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTAyMTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21336 invoked from network); 12 Apr 2012 01:38:28 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-14.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Apr 2012 01:38:28 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 21:38:26 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 20:38:20 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 12 Apr 2012 07:08:17 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 12 Apr 2012 09:38:26 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041121382601201
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: xuesen.guo@hitachiconsulting.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmX-000724-N2; Fri, 13 Apr 2012 03:02:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SI8zW-00072y-2Y
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 01:38:30 +0000
Received: from [85.158.139.83:49973] by server-12.bemta-5.messagelabs.com id
	4B/11-05587-512368F4; Thu, 12 Apr 2012 01:38:29 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334194707!19155336!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTAyMTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21336 invoked from network); 12 Apr 2012 01:38:28 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-14.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Apr 2012 01:38:28 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 21:38:26 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 20:38:20 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 12 Apr 2012 07:08:17 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 12 Apr 2012 09:38:26 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041121382601201
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: xuesen.guo@hitachiconsulting.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmX-00071u-BS; Fri, 13 Apr 2012 03:02:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SHu7p-0005J7-1n
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 09:46:05 +0000
Received: from [85.158.139.83:13271] by server-1.bemta-5.messagelabs.com id
	F6/E1-28458-CD2558F4; Wed, 11 Apr 2012 09:46:04 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334137562!20601362!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNDk5OTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23757 invoked from network); 11 Apr 2012 09:46:03 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 09:46:03 -0000
Received: from HCAZUSCH2.hitachiconsulting.net (63.148.190.199
	[63.148.190.199]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 05:46:01 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 04:45:51 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Wed, 11 Apr 2012 15:14:26 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334137470@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Apr 2012 17:44:30 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041105460102501
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWmX-00071u-BS; Fri, 13 Apr 2012 03:02:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SHu7p-0005J7-1n
	for xen-devel@lists.xensource.com; Wed, 11 Apr 2012 09:46:05 +0000
Received: from [85.158.139.83:13271] by server-1.bemta-5.messagelabs.com id
	F6/E1-28458-CD2558F4; Wed, 11 Apr 2012 09:46:04 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334137562!20601362!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNDk5OTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23757 invoked from network); 11 Apr 2012 09:46:03 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Apr 2012 09:46:03 -0000
Received: from HCAZUSCH2.hitachiconsulting.net (63.148.190.199
	[63.148.190.199]) (Using TLS) by service55-us.mimecast.com; Wed, 11 Apr
	2012 05:46:01 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 11 Apr 2012 04:45:51 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Wed, 11 Apr 2012 15:14:26 +0530
MIME-Version: 1.0
X-Mercurial-Node: e640d59ff132c7bccea9c936080d3e180f358340
Message-ID: <e640d59ff132c7bccea9.1334137470@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Apr 2012 17:44:30 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112041105460102501
X-Mailman-Approved-At: Fri, 13 Apr 2012 03:02:38 +0000
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <xuesen.guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r e640d59ff132 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Wed Apr 11 15:31:26 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return -EINVAL;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWrt-0007bn-Mg; Fri, 13 Apr 2012 03:08:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1SIWrs-0007bd-8z
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 03:08:12 +0000
Received: from [85.158.143.35:40170] by server-1.bemta-4.messagelabs.com id
	D8/17-20925-B98978F4; Fri, 13 Apr 2012 03:08:11 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334286489!14315909!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32465 invoked from network); 13 Apr 2012 03:08:10 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Apr 2012 03:08:10 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1SIWrp-0008KW-6V
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 20:08:09 -0700
Date: Thu, 12 Apr 2012 20:08:09 -0700 (PDT)
From: feisky <feiskyer@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334286489193-5637265.post@n5.nabble.com>
In-Reply-To: <20110929230931.GA12858@phenom.oracle.com>
References: <20110929230931.GA12858@phenom.oracle.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xm list vs xl list (Fedora Core 16, Xen 4.1.1)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Encounter  the same problem on Xen-4.1.2, has someone got some explanations? 

--
View this message in context: http://xen.1045712.n5.nabble.com/xm-list-vs-xl-list-Fedora-Core-16-Xen-4-1-1-tp4855029p5637265.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 03:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 03:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIWrt-0007bn-Mg; Fri, 13 Apr 2012 03:08:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1SIWrs-0007bd-8z
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 03:08:12 +0000
Received: from [85.158.143.35:40170] by server-1.bemta-4.messagelabs.com id
	D8/17-20925-B98978F4; Fri, 13 Apr 2012 03:08:11 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334286489!14315909!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32465 invoked from network); 13 Apr 2012 03:08:10 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Apr 2012 03:08:10 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1SIWrp-0008KW-6V
	for xen-devel@lists.xensource.com; Thu, 12 Apr 2012 20:08:09 -0700
Date: Thu, 12 Apr 2012 20:08:09 -0700 (PDT)
From: feisky <feiskyer@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334286489193-5637265.post@n5.nabble.com>
In-Reply-To: <20110929230931.GA12858@phenom.oracle.com>
References: <20110929230931.GA12858@phenom.oracle.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xm list vs xl list (Fedora Core 16, Xen 4.1.1)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Encounter  the same problem on Xen-4.1.2, has someone got some explanations? 

--
View this message in context: http://xen.1045712.n5.nabble.com/xm-list-vs-xl-list-Fedora-Core-16-Xen-4-1-1-tp4855029p5637265.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIarU-0001QY-FZ; Fri, 13 Apr 2012 07:24:04 +0000
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 1SIarS-0001QT-NN
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 07:24:02 +0000
Received: from [193.109.254.147:51485] by server-11.bemta-14.messagelabs.com
	id 89/A9-05858-294D78F4; Fri, 13 Apr 2012 07:24:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334301841!4416397!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28207 invoked from network); 13 Apr 2012 07:24:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 07:24:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 08:24:00 +0100
Message-Id: <4F87F0AE020000780007DB14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 08:23:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steven" <wangwangkang@gmail.com>
References: <4F86D464.4080601@amd.com>
	<CAMTrTqUfiBPZ9bPYpCnuD=DSTEvG4oACMfAPBHGvja-JD_MnFw@mail.gmail.com>
In-Reply-To: <CAMTrTqUfiBPZ9bPYpCnuD=DSTEvG4oACMfAPBHGvja-JD_MnFw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
 ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.04.12 at 19:05, Steven <wangwangkang@gmail.com> wrote:
> Hi, Wei,
> I have read you slides in xen summit 2007 about NPT in AMD, "AMD
> Barcelona and Nested Paging Support in Xen".
> However, I have some question regarding the nested page walk in your slide 
> 8.

Please do not hijack threads for unrelated topics; create new ones
instead.

Jan

> In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
> I assume that it use the [47:39] bit of gVA.
> However, in another AMD white paper, "AMD-VTM Nested Paging".
> http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf 
> In its figure 4, I saw that the first step is to translate gCR3 using
> nested page walk and then combine with the gVA[47:39] to read the
> table entry.
> 
> These two documents look having different order of reading the guest
> page table. In the slides, it first get_PML4. But in the white paper,
> it first does nested page walk.
> I am wondering which one is true. Thanks.
> 
> - ha
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIarU-0001QY-FZ; Fri, 13 Apr 2012 07:24:04 +0000
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 1SIarS-0001QT-NN
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 07:24:02 +0000
Received: from [193.109.254.147:51485] by server-11.bemta-14.messagelabs.com
	id 89/A9-05858-294D78F4; Fri, 13 Apr 2012 07:24:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334301841!4416397!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28207 invoked from network); 13 Apr 2012 07:24:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 07:24:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 08:24:00 +0100
Message-Id: <4F87F0AE020000780007DB14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 08:23:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steven" <wangwangkang@gmail.com>
References: <4F86D464.4080601@amd.com>
	<CAMTrTqUfiBPZ9bPYpCnuD=DSTEvG4oACMfAPBHGvja-JD_MnFw@mail.gmail.com>
In-Reply-To: <CAMTrTqUfiBPZ9bPYpCnuD=DSTEvG4oACMfAPBHGvja-JD_MnFw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
 ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.04.12 at 19:05, Steven <wangwangkang@gmail.com> wrote:
> Hi, Wei,
> I have read you slides in xen summit 2007 about NPT in AMD, "AMD
> Barcelona and Nested Paging Support in Xen".
> However, I have some question regarding the nested page walk in your slide 
> 8.

Please do not hijack threads for unrelated topics; create new ones
instead.

Jan

> In your slide 8, the first step is to get gPA from get_PML4(gCR3,gVA).
> I assume that it use the [47:39] bit of gVA.
> However, in another AMD white paper, "AMD-VTM Nested Paging".
> http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf 
> In its figure 4, I saw that the first step is to translate gCR3 using
> nested page walk and then combine with the gVA[47:39] to read the
> table entry.
> 
> These two documents look having different order of reading the guest
> page table. In the slides, it first get_PML4. But in the white paper,
> it first does nested page walk.
> I am wondering which one is true. Thanks.
> 
> - ha
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:26:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIasn-0001TO-To; Fri, 13 Apr 2012 07:25:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIasn-0001TG-0y
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:25:25 +0000
Received: from [85.158.143.35:43719] by server-3.bemta-4.messagelabs.com id
	81/A9-05853-4E4D78F4; Fri, 13 Apr 2012 07:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334301923!18416038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11480 invoked from network); 13 Apr 2012 07:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 07:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11916353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:25:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 08:25:22 +0100
Message-ID: <1334301921.3989.0.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 13 Apr 2012 08:25:21 +0100
In-Reply-To: <1334267323.2417.3.camel@Abyss>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334267323.2417.3.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 22:48 +0100, Dario Faggioli wrote:
> On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote: 

> > This is not 4.3
> > material.
> >
> Just to be sure I get it, you think we need to have the
> creation-vs-ballooning potential race solved *before* 4.2 ?

I initially misread it as "This is not 4.2 material", which I agreed
with...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:26:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIasn-0001TO-To; Fri, 13 Apr 2012 07:25:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIasn-0001TG-0y
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:25:25 +0000
Received: from [85.158.143.35:43719] by server-3.bemta-4.messagelabs.com id
	81/A9-05853-4E4D78F4; Fri, 13 Apr 2012 07:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334301923!18416038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11480 invoked from network); 13 Apr 2012 07:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 07:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11916353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:25:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 08:25:22 +0100
Message-ID: <1334301921.3989.0.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 13 Apr 2012 08:25:21 +0100
In-Reply-To: <1334267323.2417.3.camel@Abyss>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334267323.2417.3.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 22:48 +0100, Dario Faggioli wrote:
> On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote: 

> > This is not 4.3
> > material.
> >
> Just to be sure I get it, you think we need to have the
> creation-vs-ballooning potential race solved *before* 4.2 ?

I initially misread it as "This is not 4.2 material", which I agreed
with...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:34:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:34:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIb0j-0001i1-RC; Fri, 13 Apr 2012 07:33:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIb0i-0001hw-29
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 07:33:36 +0000
Received: from [85.158.143.35:57131] by server-3.bemta-4.messagelabs.com id
	47/B3-05853-FC6D78F4; Fri, 13 Apr 2012 07:33:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334302414!14340056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 13 Apr 2012 07:33:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 07:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11916611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:33:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 08:33:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIb0f-0005ai-O9;
	Fri, 13 Apr 2012 07:33:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIb0f-0007He-KX;
	Fri, 13 Apr 2012 08:33:33 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12668-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 08:33:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12668: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12668 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12668/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           9 guest-start               fail REGR. vs. 12639

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12639
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c6bde42c8845
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:34:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:34:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIb0j-0001i1-RC; Fri, 13 Apr 2012 07:33:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIb0i-0001hw-29
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 07:33:36 +0000
Received: from [85.158.143.35:57131] by server-3.bemta-4.messagelabs.com id
	47/B3-05853-FC6D78F4; Fri, 13 Apr 2012 07:33:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334302414!14340056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 13 Apr 2012 07:33:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 07:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11916611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:33:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 08:33:33 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIb0f-0005ai-O9;
	Fri, 13 Apr 2012 07:33:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIb0f-0007He-KX;
	Fri, 13 Apr 2012 08:33:33 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12668-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 08:33:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12668: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12668 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12668/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           9 guest-start               fail REGR. vs. 12639

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12639
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c6bde42c8845
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:38:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIb4b-0001o5-GY; Fri, 13 Apr 2012 07:37:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIb4Z-0001ny-8d
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:37:35 +0000
Received: from [85.158.143.99:59867] by server-2.bemta-4.messagelabs.com id
	F0/A4-17550-EB7D78F4; Fri, 13 Apr 2012 07:37:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334302653!22556657!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5889 invoked from network); 13 Apr 2012 07:37:33 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 07:37:33 -0000
Received: from [84.223.50.88] (account d.faggioli@sssup.it HELO
	[192.168.1.119]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77100584; Fri, 13 Apr 2012 09:37:32 +0200
Message-ID: <1334302643.2860.2.camel@Abyss.lan>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 13 Apr 2012 09:37:23 +0200
In-Reply-To: <1334301921.3989.0.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334267323.2417.3.camel@Abyss>
	<1334301921.3989.0.camel@dagon.hellion.org.uk>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2744217702126309362=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2744217702126309362==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-91MsCO75tAaBR3lKS8hF"


--=-91MsCO75tAaBR3lKS8hF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-13 at 08:25 +0100, Ian Campbell wrote:=20
> On Thu, 2012-04-12 at 22:48 +0100, Dario Faggioli wrote:
> > On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote:=20
>=20
> > > This is not 4.3
> > > material.
> > >
> > Just to be sure I get it, you think we need to have the
> > creation-vs-ballooning potential race solved *before* 4.2 ?
>=20
> I initially misread it as "This is not 4.2 material", which I agreed
> with...
>=20
Yeah, I was under that impression to, and given what follows that is
probably the case, but the possibility of a typo didn't come to my
mind... Sorry for *not* misreading this. :-P

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-91MsCO75tAaBR3lKS8hF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+H17MACgkQk4XaBE3IOsTzZgCaArLn8/baxcdbBw/Hfcduy3W4
zDQAn1SCXNoz5oQbvSaUOiuwjKPldjC3
=+KCS
-----END PGP SIGNATURE-----

--=-91MsCO75tAaBR3lKS8hF--



--===============2744217702126309362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2744217702126309362==--



From xen-devel-bounces@lists.xen.org Fri Apr 13 07:38:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIb4b-0001o5-GY; Fri, 13 Apr 2012 07:37:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIb4Z-0001ny-8d
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:37:35 +0000
Received: from [85.158.143.99:59867] by server-2.bemta-4.messagelabs.com id
	F0/A4-17550-EB7D78F4; Fri, 13 Apr 2012 07:37:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334302653!22556657!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5889 invoked from network); 13 Apr 2012 07:37:33 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 07:37:33 -0000
Received: from [84.223.50.88] (account d.faggioli@sssup.it HELO
	[192.168.1.119]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77100584; Fri, 13 Apr 2012 09:37:32 +0200
Message-ID: <1334302643.2860.2.camel@Abyss.lan>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 13 Apr 2012 09:37:23 +0200
In-Reply-To: <1334301921.3989.0.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334267323.2417.3.camel@Abyss>
	<1334301921.3989.0.camel@dagon.hellion.org.uk>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2744217702126309362=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2744217702126309362==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-91MsCO75tAaBR3lKS8hF"


--=-91MsCO75tAaBR3lKS8hF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-13 at 08:25 +0100, Ian Campbell wrote:=20
> On Thu, 2012-04-12 at 22:48 +0100, Dario Faggioli wrote:
> > On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote:=20
>=20
> > > This is not 4.3
> > > material.
> > >
> > Just to be sure I get it, you think we need to have the
> > creation-vs-ballooning potential race solved *before* 4.2 ?
>=20
> I initially misread it as "This is not 4.2 material", which I agreed
> with...
>=20
Yeah, I was under that impression to, and given what follows that is
probably the case, but the possibility of a typo didn't come to my
mind... Sorry for *not* misreading this. :-P

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-91MsCO75tAaBR3lKS8hF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+H17MACgkQk4XaBE3IOsTzZgCaArLn8/baxcdbBw/Hfcduy3W4
zDQAn1SCXNoz5oQbvSaUOiuwjKPldjC3
=+KCS
-----END PGP SIGNATURE-----

--=-91MsCO75tAaBR3lKS8hF--



--===============2744217702126309362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2744217702126309362==--



From xen-devel-bounces@lists.xen.org Fri Apr 13 07:49:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbG9-00027f-H2; Fri, 13 Apr 2012 07:49:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIbG8-00027N-2J
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 07:49:32 +0000
Received: from [85.158.143.99:16040] by server-3.bemta-4.messagelabs.com id
	CB/88-05853-A8AD78F4; Fri, 13 Apr 2012 07:49:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334303369!18225567!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7143 invoked from network); 13 Apr 2012 07:49:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 07:49:29 -0000
Received: from [84.223.50.88] (account d.faggioli@sssup.it HELO
	[192.168.1.119]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77101013; Fri, 13 Apr 2012 09:49:28 +0200
Message-ID: <1334303366.2860.4.camel@Abyss.lan>
From: Dario Faggioli <raistlin@linux.it>
To: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 13 Apr 2012 09:49:26 +0200
In-Reply-To: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
References: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>,
	xen-users mailing list <Xen-users@lists.xensource.com>,
	Fedora Xen List <fedora-xen@redhat.com>
Subject: Re: [Xen-devel] [Xen-users] Calling all Fedora Xen users, testers,
 and developers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2294979471784194615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2294979471784194615==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Og8Jgu0Zg2KnDLoNJwSu"


--=-Og8Jgu0Zg2KnDLoNJwSu
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-06 at 13:16 -0400, Todd Deshane wrote:=20
> The Fedora community is holding a virtualization test day [1] next
> week (Thursday) and it would be great if we could help them on the Xen
> side of things
>=20
I really agree on this... Even ex-post... :-/

> Let me know if you are interested in helping out and I'll coordinated
> the Xen efforts.
>=20
Anyway, by being on the deputed IRC channel yesterday I got the
impression that they/we are planning another Fedora-Xen test day, is
that the case? If yes, please follow up on us on when it will be... I'm
not sure I can, but I'd be glad to help!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Og8Jgu0Zg2KnDLoNJwSu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+H2oYACgkQk4XaBE3IOsRpDwCeKp5esXb33KiM0lfs2g8SaTjQ
W7UAnjm39igI74DsulrI0Mir+Zw0VGWt
=yd1I
-----END PGP SIGNATURE-----

--=-Og8Jgu0Zg2KnDLoNJwSu--



--===============2294979471784194615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2294979471784194615==--



From xen-devel-bounces@lists.xen.org Fri Apr 13 07:49:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbG9-00027f-H2; Fri, 13 Apr 2012 07:49:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SIbG8-00027N-2J
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 07:49:32 +0000
Received: from [85.158.143.99:16040] by server-3.bemta-4.messagelabs.com id
	CB/88-05853-A8AD78F4; Fri, 13 Apr 2012 07:49:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334303369!18225567!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7143 invoked from network); 13 Apr 2012 07:49:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 07:49:29 -0000
Received: from [84.223.50.88] (account d.faggioli@sssup.it HELO
	[192.168.1.119]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77101013; Fri, 13 Apr 2012 09:49:28 +0200
Message-ID: <1334303366.2860.4.camel@Abyss.lan>
From: Dario Faggioli <raistlin@linux.it>
To: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 13 Apr 2012 09:49:26 +0200
In-Reply-To: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
References: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>,
	xen-users mailing list <Xen-users@lists.xensource.com>,
	Fedora Xen List <fedora-xen@redhat.com>
Subject: Re: [Xen-devel] [Xen-users] Calling all Fedora Xen users, testers,
 and developers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2294979471784194615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2294979471784194615==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Og8Jgu0Zg2KnDLoNJwSu"


--=-Og8Jgu0Zg2KnDLoNJwSu
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-06 at 13:16 -0400, Todd Deshane wrote:=20
> The Fedora community is holding a virtualization test day [1] next
> week (Thursday) and it would be great if we could help them on the Xen
> side of things
>=20
I really agree on this... Even ex-post... :-/

> Let me know if you are interested in helping out and I'll coordinated
> the Xen efforts.
>=20
Anyway, by being on the deputed IRC channel yesterday I got the
impression that they/we are planning another Fedora-Xen test day, is
that the case? If yes, please follow up on us on when it will be... I'm
not sure I can, but I'd be glad to help!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Og8Jgu0Zg2KnDLoNJwSu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+H2oYACgkQk4XaBE3IOsRpDwCeKp5esXb33KiM0lfs2g8SaTjQ
W7UAnjm39igI74DsulrI0Mir+Zw0VGWt
=yd1I
-----END PGP SIGNATURE-----

--=-Og8Jgu0Zg2KnDLoNJwSu--



--===============2294979471784194615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2294979471784194615==--



From xen-devel-bounces@lists.xen.org Fri Apr 13 07:50:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:50:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbH7-0002CH-VK; Fri, 13 Apr 2012 07:50:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIbH6-0002Bv-2I
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:50:32 +0000
Received: from [85.158.143.99:22179] by server-3.bemta-4.messagelabs.com id
	96/F9-05853-6CAD78F4; Fri, 13 Apr 2012 07:50:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334303428!18225751!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14084 invoked from network); 13 Apr 2012 07:50:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 07:50:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 08:50:28 +0100
Message-Id: <4F87F6E4020000780007DB47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 08:50:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA9876CD3.0__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA9876CD3.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
>=20
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

4.1:
24996:396801f25e92

4.1 and 4.0:
25098:2e45b26bc412 + 25099:4bd752a4cdf3
25101:f06ff3dfde08

4.1 backports attached (apply with some offsets, since they're taken
directly form our SLE11 SP2 tree).

Jan


--=__PartA9876CD3.0__=
Content-Type: text/plain; name="24996-x86-cpuidle-array-overrun.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="24996-x86-cpuidle-array-overrun.patch"

# HG changeset patch=0A# User Eric Chanudet <eric.chanudet@eu.citrix.com>=
=0A# Date 1331222672 -3600=0A# Node ID 396801f25e922bdf1db5fd644435f4640758=
6524=0A# Parent  66de4220113e937811529b12ea7f6427c0848630=0AXENPF_set_proce=
ssor_pminfo XEN_PM_CX overflows states array=0A=0ACalling XENPF_set_process=
or_pminfo with XEN_PM_CX could cause states=0Aarray in "struct acpi_process=
or_power" to exceed its limit.=0A=0AThe array used to be reset (by =
function cpuidle_init_cpu()) for each=0Ahypercall. The patch puts it back =
that way and adds an assertion to=0Amake it clear in case that happens =
again.=0A=0ASigned-off-by: Eric Chanudet <eric.chanudet@eu.citrix.com>=0A=
=0A- convert assertion to printk() & bail=0A- eliminate struct acpi_process=
or_cx's valid member (not read anymore)=0A- further adjustments to =
one-time-only vs each-time operations in=0A  cpuidle_init_cpu()=0A- don't =
use ACPI_STATE_Cn as array index anymore=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0AAcked-by: Keir Fraser <keir@xen.org>=0A=0A--- =
a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=0A@@ =
-70,10 +70,8 @@ static void lapic_timer_nop(void) { }=0A static void =
(*lapic_timer_off)(void);=0A static void (*lapic_timer_on)(void);=0A =
=0A-static uint64_t (*get_tick)(void);=0A-static uint64_t (*ticks_elapsed)(=
uint64_t t1, uint64_t t2);=0A-static uint64_t (*tick_to_ns)(uint64_t =
ticks);=0A-static uint64_t (*ns_to_tick)(uint64_t ticks);=0A+static =
uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_ns;=0A+s=
tatic uint64_t (*__read_mostly ns_to_tick)(uint64_t) =3D ns_to_acpi_pm_tick=
;=0A =0A extern void (*pm_idle) (void);=0A extern void (*dead_idle) =
(void);=0A@@ -224,6 +222,10 @@ static uint64_t acpi_pm_ticks_elapsed(ui=0A =
        return ((0xFFFFFFFF - t1) + t2 +1);=0A }=0A =0A+static uint64_t =
(*__read_mostly get_tick)(void) =3D get_acpi_pm_tick;=0A+static uint64_t =
(*__read_mostly ticks_elapsed)(uint64_t, uint64_t)=0A+    =3D acpi_pm_ticks=
_elapsed;=0A+=0A #define MWAIT_ECX_INTERRUPT_BREAK   (0x1)=0A =0A /*=0A@@ =
-609,7 +611,16 @@ static int cpuidle_init_cpu(int cpu)=0A     acpi_power =
=3D processor_powers[cpu];=0A     if ( !acpi_power )=0A     {=0A-        =
int i;=0A+        unsigned int i;=0A+=0A+        if ( cpu =3D=3D 0 && =
boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )=0A+        {=0A+            =
get_tick =3D get_stime_tick;=0A+            ticks_elapsed =3D stime_ticks_e=
lapsed;=0A+            tick_to_ns =3D stime_tick_to_ns;=0A+            =
ns_to_tick =3D ns_to_stime_tick;=0A+        }=0A+=0A         acpi_power =
=3D xmalloc(struct acpi_processor_power);=0A         if ( !acpi_power )=0A =
            return -ENOMEM;=0A@@ -617,36 +628,15 @@ static int cpuidle_init=
_cpu(int cpu)=0A =0A         for ( i =3D 0; i < ACPI_PROCESSOR_MAX_POWER; =
i++ )=0A             acpi_power->states[i].idx =3D i;=0A-     =0A-        =
acpi_power->states[ACPI_STATE_C1].type =3D ACPI_STATE_C1;=0A-        =
acpi_power->states[ACPI_STATE_C1].entry_method =3D ACPI_CSTATE_EM_HALT;=0A-=
     =0A-        acpi_power->states[ACPI_STATE_C0].valid =3D 1;=0A-        =
acpi_power->states[ACPI_STATE_C1].valid =3D 1;=0A-     =0A-        =
acpi_power->count =3D 2;=0A-        acpi_power->safe_state =3D &acpi_power-=
>states[ACPI_STATE_C1];=0A+=0A         acpi_power->cpu =3D cpu;=0A         =
processor_powers[cpu] =3D acpi_power;=0A     }=0A =0A-    if ( cpu =3D=3D =
0 )=0A-    {=0A-        if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )=0A-   =
     {=0A-            get_tick =3D get_stime_tick;=0A-            =
ticks_elapsed =3D stime_ticks_elapsed;=0A-            tick_to_ns =3D =
stime_tick_to_ns;=0A-            ns_to_tick =3D ns_to_stime_tick;=0A-      =
  }=0A-        else=0A-        {=0A-            get_tick =3D get_acpi_pm_ti=
ck;=0A-            ticks_elapsed =3D acpi_pm_ticks_elapsed;=0A-            =
tick_to_ns =3D acpi_pm_tick_to_ns;=0A-            ns_to_tick =3D ns_to_acpi=
_pm_tick;=0A-        }=0A-    }=0A+    acpi_power->count =3D 2;=0A+    =
acpi_power->states[1].type =3D ACPI_STATE_C1;=0A+    acpi_power->states[1].=
entry_method =3D ACPI_CSTATE_EM_HALT;=0A+    acpi_power->safe_state =3D =
&acpi_power->states[1];=0A =0A     return 0;=0A }=0A@@ -863,17 +853,25 @@ =
static void set_cx(=0A     if ( check_cx(acpi_power, xen_cx) !=3D 0 )=0A   =
      return;=0A =0A-    if ( xen_cx->type =3D=3D ACPI_STATE_C1 )=0A+    =
switch ( xen_cx->type )=0A+    {=0A+    case ACPI_STATE_C1:=0A         cx =
=3D &acpi_power->states[1];=0A-    else=0A-        cx =3D &acpi_power->stat=
es[acpi_power->count];=0A-=0A-    if ( !cx->valid )=0A-        acpi_power->=
count++;=0A+        break;=0A+    default:=0A+        if ( acpi_power->coun=
t >=3D ACPI_PROCESSOR_MAX_POWER )=0A+        {=0A+    case ACPI_STATE_C0:=
=0A+            printk(XENLOG_WARNING "CPU%u: C%d data ignored\n",=0A+     =
              acpi_power->cpu, xen_cx->type);=0A+            return;=0A+   =
     }=0A+        cx =3D &acpi_power->states[acpi_power->count++];=0A+     =
   cx->type =3D xen_cx->type;=0A+        break;=0A+    }=0A =0A-    =
cx->valid    =3D 1;=0A-    cx->type     =3D xen_cx->type;=0A-    cx->addres=
s  =3D xen_cx->reg.address;=0A+    cx->address =3D xen_cx->reg.address;=0A =
=0A     switch ( xen_cx->reg.space_id )=0A     {=0A--- a/xen/include/xen/cp=
uidle.h=0A+++ b/xen/include/xen/cpuidle.h=0A@@ -40,7 +40,6 @@=0A struct =
acpi_processor_cx=0A {=0A     u8 idx;=0A-    u8 valid;=0A     u8 type;=0A  =
   u32 address;=0A     u8 entry_method; /* ACPI_CSTATE_EM_xxx */=0A
--=__PartA9876CD3.0__=
Content-Type: text/plain; name="25098-x86-emul-lock-UD.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="25098-x86-emul-lock-UD.patch"

# HG changeset patch=0A# User Andrew Cooper <andrew.cooper3@citrix.com>=0A#=
 Date 1332535516 0=0A# Node ID 2e45b26bc412099a2b8f009bcf111e4b6c23847b=0A#=
 Parent  2ca43b65718fbe2d3f9ea36132e139ef774d9a11=0Ax86_emulate: raise #UD =
rather than #GP on invalid use of LOCK prefix=0A=0AFrom: Andrew Cooper =
<andrew.cooper3@citrix.com>=0ASigned-off-by: Keir Fraser <keir@xen.org>=0AC=
ommitted-by: Keir Fraser <keir@xen.org>=0A=0A# HG changeset patch=0A# User =
Keir Fraser <keir@xen.org>=0A# Date 1332535908 0=0A# Node ID 4bd752a4cdf323=
c41c50f8cd6286f566d67adeae=0A# Parent  2e45b26bc412099a2b8f009bcf111e4b6c23=
847b=0Ax86_emulate: Do not push an error code onto a #UD exception =
stack=0A=0ASigned-off-by: Keir Fraser <keir@xen.org>=0A=0A--- a/xen/arch/x8=
6/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=
=0A@@ -1353,7 +1353,7 @@ x86_emulate(=0A     }=0A =0A     /* Lock prefix =
is allowed only on RMW instructions. */=0A-    generate_exception_if((d & =
Mov) && lock_prefix, EXC_GP, 0);=0A+    generate_exception_if((d & Mov) && =
lock_prefix, EXC_UD, -1);=0A =0A     /* ModRM and SIB bytes. */=0A     if =
( d & ModRM )=0A@@ -1572,12 +1572,12 @@ x86_emulate(=0A             =
lock_prefix &&=0A             ((b < 0x20) || (b > 0x23)) && /* MOV CRn/DRn =
*/=0A             (b !=3D 0xc7),                  /* CMPXCHG{8,16}B */=0A- =
           EXC_GP, 0);=0A+            EXC_UD, -1);=0A         dst.type =3D =
OP_NONE;=0A         break;=0A =0A     case DstReg:=0A-        generate_exce=
ption_if(lock_prefix, EXC_GP, 0);=0A+        generate_exception_if(lock_pre=
fix, EXC_UD, -1);=0A         dst.type =3D OP_REG;=0A         if ( d & =
ByteOp )=0A         {=0A@@ -1633,7 +1633,7 @@ x86_emulate(=0A         dst =
=3D ea;=0A         if ( dst.type =3D=3D OP_REG )=0A         {=0A-          =
  generate_exception_if(lock_prefix, EXC_GP, 0);=0A+            generate_ex=
ception_if(lock_prefix, EXC_UD, -1);=0A             switch ( dst.bytes =
)=0A             {=0A             case 1: dst.val =3D *(uint8_t  *)dst.reg;=
 break;=0A@@ -3645,14 +3645,14 @@ x86_emulate(=0A         struct segment_re=
gister cs =3D { 0 }, ss =3D { 0 };=0A         int rc;=0A =0A-        =
generate_exception_if(in_realmode(ctxt, ops), EXC_UD, 0);=0A-        =
generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, 0);=0A+        =
generate_exception_if(in_realmode(ctxt, ops), EXC_UD, -1);=0A+        =
generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);=0A =0A         =
/* Inject #UD if syscall/sysret are disabled. */=0A         fail_if(ops->re=
ad_msr =3D=3D NULL);=0A         if ( (rc =3D ops->read_msr(MSR_EFER, =
&msr_content, ctxt)) !=3D 0 )=0A             goto done;=0A-        =
generate_exception_if((msr_content & EFER_SCE) =3D=3D 0, EXC_UD, 0);=0A+   =
     generate_exception_if((msr_content & EFER_SCE) =3D=3D 0, EXC_UD, =
-1);=0A =0A         if ( (rc =3D ops->read_msr(MSR_STAR, &msr_content, =
ctxt)) !=3D 0 )=0A             goto done;=0A
--=__PartA9876CD3.0__=
Content-Type: text/plain; name="25101-x86-hpet-disable.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="25101-x86-hpet-disable.patch"

References: bnc#748896=0A=0A# HG changeset patch=0A# User Jan Beulich =
<jbeulich@suse.com>=0A# Date 1332854423 -7200=0A# Node ID f06ff3dfde08ee563=
970cffba502742249ff5820=0A# Parent  ed48258053aea953afd28b746b53af7b8b30531=
b=0Ax86/hpet: disable before reboot or kexec=0A=0ALinux up to now is not =
smart enough to properly clear the HPET when it=0Aboots, which is =
particularly a problem when a kdump attempt from=0Arunning under Xen is =
being made. Linux itself added code to work around=0Athis to its shutdown =
paths quite some time ago, so let's do something=0Asimilar in Xen: Save =
the configuration register settings during boot,=0Aand restore them during =
shutdown. This should cover the majority of=0Acases where the secondary =
kernel might not come up because timer=0Ainterrupts don't work.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Keir Fraser <keir@xen.=
org>=0A=0A--- a/xen/arch/x86/crash.c=0A+++ b/xen/arch/x86/crash.c=0A@@ =
-94,6 +94,7 @@ static void nmi_shootdown_cpus(void)=0A     x2apic_enabled =
=3D (current_local_apic_mode() =3D=3D APIC_MODE_X2APIC);=0A =0A     =
disable_IO_APIC();=0A+    hpet_disable();=0A }=0A =0A void machine_crash_sh=
utdown(void)=0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ =
-721,12 +721,14 @@ int hpet_legacy_irq_tick(void)=0A     return 1;=0A }=0A =
=0A+static u32 *hpet_boot_cfg;=0A+=0A u64 hpet_setup(void)=0A {=0A     =
static u64 hpet_rate;=0A     static u32 system_reset_latch;=0A     u32 =
hpet_id, hpet_period, cfg;=0A-    int i;=0A+    unsigned int i, last;=0A =
=0A     if ( system_reset_latch =3D=3D system_reset_counter )=0A         =
return hpet_rate;=0A@@ -752,13 +754,20 @@ u64 hpet_setup(void)=0A         =
return 0;=0A     }=0A =0A+    last =3D (hpet_id & HPET_ID_NUMBER) >> =
HPET_ID_NUMBER_SHIFT;=0A+    hpet_boot_cfg =3D xmalloc_array(u32, 2 + =
last);=0A+=0A     cfg =3D hpet_read32(HPET_CFG);=0A+    if ( hpet_boot_cfg =
)=0A+        *hpet_boot_cfg =3D cfg;=0A     cfg &=3D ~(HPET_CFG_ENABLE | =
HPET_CFG_LEGACY);=0A     hpet_write32(cfg, HPET_CFG);=0A =0A-    for ( i =
=3D 0; i <=3D ((hpet_id >> 8) & 31); i++ )=0A+    for ( i =3D 0; i <=3D =
last; ++i )=0A     {=0A         cfg =3D hpet_read32(HPET_Tn_CFG(i));=0A+   =
     if ( hpet_boot_cfg )=0A+            hpet_boot_cfg[i + 1] =3D cfg;=0A  =
       cfg &=3D ~HPET_TN_ENABLE;=0A         hpet_write32(cfg, HPET_Tn_CFG(i=
));=0A     }=0A@@ -772,3 +781,21 @@ u64 hpet_setup(void)=0A =0A     return =
hpet_rate;=0A }=0A+=0A+void hpet_disable(void)=0A+{=0A+    unsigned int =
i;=0A+    u32 id;=0A+=0A+    if ( !hpet_boot_cfg )=0A+        return;=0A+=
=0A+    hpet_write32(*hpet_boot_cfg & ~HPET_CFG_ENABLE, HPET_CFG);=0A+=0A+ =
   id =3D hpet_read32(HPET_ID);=0A+    for ( i =3D 0; i <=3D ((id & =
HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT); ++i )=0A+        hpet_write32(hpe=
t_boot_cfg[i + 1], HPET_Tn_CFG(i));=0A+=0A+    if ( *hpet_boot_cfg & =
HPET_CFG_ENABLE )=0A+        hpet_write32(*hpet_boot_cfg, HPET_CFG);=0A+}=
=0A--- a/xen/arch/x86/smp.c=0A+++ b/xen/arch/x86/smp.c=0A@@ -19,6 +19,7 =
@@=0A #include <asm/mc146818rtc.h>=0A #include <asm/flushtlb.h>=0A =
#include <asm/hardirq.h>=0A+#include <asm/hpet.h>=0A #include <asm/hvm/supp=
ort.h>=0A #include <mach_apic.h>=0A =0A@@ -373,6 +374,7 @@ void smp_send_st=
op(void)=0A     local_irq_disable();=0A     __stop_this_cpu();=0A     =
disable_IO_APIC();=0A+    hpet_disable();=0A     local_irq_enable();=0A =
}=0A =0A--- a/xen/include/asm-x86/hpet.h=0A+++ b/xen/include/asm-x86/hpet.h=
=0A@@ -68,6 +68,11 @@ extern unsigned long hpet_address;=0A u64 hpet_setup(=
void);=0A =0A /*=0A+ * Disable HPET hardware: restore it to boot time =
state.=0A+ */=0A+void hpet_disable(void);=0A+=0A+/*=0A  * Callback from =
legacy timer (PIT channel 0) IRQ handler.=0A  * Returns 1 if tick =
originated from HPET; else 0.=0A  */=0A
--=__PartA9876CD3.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartA9876CD3.0__=--


From xen-devel-bounces@lists.xen.org Fri Apr 13 07:50:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:50:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbH7-0002CH-VK; Fri, 13 Apr 2012 07:50:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIbH6-0002Bv-2I
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:50:32 +0000
Received: from [85.158.143.99:22179] by server-3.bemta-4.messagelabs.com id
	96/F9-05853-6CAD78F4; Fri, 13 Apr 2012 07:50:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334303428!18225751!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14084 invoked from network); 13 Apr 2012 07:50:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 07:50:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 08:50:28 +0100
Message-Id: <4F87F6E4020000780007DB47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 08:50:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA9876CD3.0__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA9876CD3.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
>=20
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

4.1:
24996:396801f25e92

4.1 and 4.0:
25098:2e45b26bc412 + 25099:4bd752a4cdf3
25101:f06ff3dfde08

4.1 backports attached (apply with some offsets, since they're taken
directly form our SLE11 SP2 tree).

Jan


--=__PartA9876CD3.0__=
Content-Type: text/plain; name="24996-x86-cpuidle-array-overrun.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="24996-x86-cpuidle-array-overrun.patch"

# HG changeset patch=0A# User Eric Chanudet <eric.chanudet@eu.citrix.com>=
=0A# Date 1331222672 -3600=0A# Node ID 396801f25e922bdf1db5fd644435f4640758=
6524=0A# Parent  66de4220113e937811529b12ea7f6427c0848630=0AXENPF_set_proce=
ssor_pminfo XEN_PM_CX overflows states array=0A=0ACalling XENPF_set_process=
or_pminfo with XEN_PM_CX could cause states=0Aarray in "struct acpi_process=
or_power" to exceed its limit.=0A=0AThe array used to be reset (by =
function cpuidle_init_cpu()) for each=0Ahypercall. The patch puts it back =
that way and adds an assertion to=0Amake it clear in case that happens =
again.=0A=0ASigned-off-by: Eric Chanudet <eric.chanudet@eu.citrix.com>=0A=
=0A- convert assertion to printk() & bail=0A- eliminate struct acpi_process=
or_cx's valid member (not read anymore)=0A- further adjustments to =
one-time-only vs each-time operations in=0A  cpuidle_init_cpu()=0A- don't =
use ACPI_STATE_Cn as array index anymore=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0AAcked-by: Keir Fraser <keir@xen.org>=0A=0A--- =
a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=0A@@ =
-70,10 +70,8 @@ static void lapic_timer_nop(void) { }=0A static void =
(*lapic_timer_off)(void);=0A static void (*lapic_timer_on)(void);=0A =
=0A-static uint64_t (*get_tick)(void);=0A-static uint64_t (*ticks_elapsed)(=
uint64_t t1, uint64_t t2);=0A-static uint64_t (*tick_to_ns)(uint64_t =
ticks);=0A-static uint64_t (*ns_to_tick)(uint64_t ticks);=0A+static =
uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_ns;=0A+s=
tatic uint64_t (*__read_mostly ns_to_tick)(uint64_t) =3D ns_to_acpi_pm_tick=
;=0A =0A extern void (*pm_idle) (void);=0A extern void (*dead_idle) =
(void);=0A@@ -224,6 +222,10 @@ static uint64_t acpi_pm_ticks_elapsed(ui=0A =
        return ((0xFFFFFFFF - t1) + t2 +1);=0A }=0A =0A+static uint64_t =
(*__read_mostly get_tick)(void) =3D get_acpi_pm_tick;=0A+static uint64_t =
(*__read_mostly ticks_elapsed)(uint64_t, uint64_t)=0A+    =3D acpi_pm_ticks=
_elapsed;=0A+=0A #define MWAIT_ECX_INTERRUPT_BREAK   (0x1)=0A =0A /*=0A@@ =
-609,7 +611,16 @@ static int cpuidle_init_cpu(int cpu)=0A     acpi_power =
=3D processor_powers[cpu];=0A     if ( !acpi_power )=0A     {=0A-        =
int i;=0A+        unsigned int i;=0A+=0A+        if ( cpu =3D=3D 0 && =
boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )=0A+        {=0A+            =
get_tick =3D get_stime_tick;=0A+            ticks_elapsed =3D stime_ticks_e=
lapsed;=0A+            tick_to_ns =3D stime_tick_to_ns;=0A+            =
ns_to_tick =3D ns_to_stime_tick;=0A+        }=0A+=0A         acpi_power =
=3D xmalloc(struct acpi_processor_power);=0A         if ( !acpi_power )=0A =
            return -ENOMEM;=0A@@ -617,36 +628,15 @@ static int cpuidle_init=
_cpu(int cpu)=0A =0A         for ( i =3D 0; i < ACPI_PROCESSOR_MAX_POWER; =
i++ )=0A             acpi_power->states[i].idx =3D i;=0A-     =0A-        =
acpi_power->states[ACPI_STATE_C1].type =3D ACPI_STATE_C1;=0A-        =
acpi_power->states[ACPI_STATE_C1].entry_method =3D ACPI_CSTATE_EM_HALT;=0A-=
     =0A-        acpi_power->states[ACPI_STATE_C0].valid =3D 1;=0A-        =
acpi_power->states[ACPI_STATE_C1].valid =3D 1;=0A-     =0A-        =
acpi_power->count =3D 2;=0A-        acpi_power->safe_state =3D &acpi_power-=
>states[ACPI_STATE_C1];=0A+=0A         acpi_power->cpu =3D cpu;=0A         =
processor_powers[cpu] =3D acpi_power;=0A     }=0A =0A-    if ( cpu =3D=3D =
0 )=0A-    {=0A-        if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )=0A-   =
     {=0A-            get_tick =3D get_stime_tick;=0A-            =
ticks_elapsed =3D stime_ticks_elapsed;=0A-            tick_to_ns =3D =
stime_tick_to_ns;=0A-            ns_to_tick =3D ns_to_stime_tick;=0A-      =
  }=0A-        else=0A-        {=0A-            get_tick =3D get_acpi_pm_ti=
ck;=0A-            ticks_elapsed =3D acpi_pm_ticks_elapsed;=0A-            =
tick_to_ns =3D acpi_pm_tick_to_ns;=0A-            ns_to_tick =3D ns_to_acpi=
_pm_tick;=0A-        }=0A-    }=0A+    acpi_power->count =3D 2;=0A+    =
acpi_power->states[1].type =3D ACPI_STATE_C1;=0A+    acpi_power->states[1].=
entry_method =3D ACPI_CSTATE_EM_HALT;=0A+    acpi_power->safe_state =3D =
&acpi_power->states[1];=0A =0A     return 0;=0A }=0A@@ -863,17 +853,25 @@ =
static void set_cx(=0A     if ( check_cx(acpi_power, xen_cx) !=3D 0 )=0A   =
      return;=0A =0A-    if ( xen_cx->type =3D=3D ACPI_STATE_C1 )=0A+    =
switch ( xen_cx->type )=0A+    {=0A+    case ACPI_STATE_C1:=0A         cx =
=3D &acpi_power->states[1];=0A-    else=0A-        cx =3D &acpi_power->stat=
es[acpi_power->count];=0A-=0A-    if ( !cx->valid )=0A-        acpi_power->=
count++;=0A+        break;=0A+    default:=0A+        if ( acpi_power->coun=
t >=3D ACPI_PROCESSOR_MAX_POWER )=0A+        {=0A+    case ACPI_STATE_C0:=
=0A+            printk(XENLOG_WARNING "CPU%u: C%d data ignored\n",=0A+     =
              acpi_power->cpu, xen_cx->type);=0A+            return;=0A+   =
     }=0A+        cx =3D &acpi_power->states[acpi_power->count++];=0A+     =
   cx->type =3D xen_cx->type;=0A+        break;=0A+    }=0A =0A-    =
cx->valid    =3D 1;=0A-    cx->type     =3D xen_cx->type;=0A-    cx->addres=
s  =3D xen_cx->reg.address;=0A+    cx->address =3D xen_cx->reg.address;=0A =
=0A     switch ( xen_cx->reg.space_id )=0A     {=0A--- a/xen/include/xen/cp=
uidle.h=0A+++ b/xen/include/xen/cpuidle.h=0A@@ -40,7 +40,6 @@=0A struct =
acpi_processor_cx=0A {=0A     u8 idx;=0A-    u8 valid;=0A     u8 type;=0A  =
   u32 address;=0A     u8 entry_method; /* ACPI_CSTATE_EM_xxx */=0A
--=__PartA9876CD3.0__=
Content-Type: text/plain; name="25098-x86-emul-lock-UD.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="25098-x86-emul-lock-UD.patch"

# HG changeset patch=0A# User Andrew Cooper <andrew.cooper3@citrix.com>=0A#=
 Date 1332535516 0=0A# Node ID 2e45b26bc412099a2b8f009bcf111e4b6c23847b=0A#=
 Parent  2ca43b65718fbe2d3f9ea36132e139ef774d9a11=0Ax86_emulate: raise #UD =
rather than #GP on invalid use of LOCK prefix=0A=0AFrom: Andrew Cooper =
<andrew.cooper3@citrix.com>=0ASigned-off-by: Keir Fraser <keir@xen.org>=0AC=
ommitted-by: Keir Fraser <keir@xen.org>=0A=0A# HG changeset patch=0A# User =
Keir Fraser <keir@xen.org>=0A# Date 1332535908 0=0A# Node ID 4bd752a4cdf323=
c41c50f8cd6286f566d67adeae=0A# Parent  2e45b26bc412099a2b8f009bcf111e4b6c23=
847b=0Ax86_emulate: Do not push an error code onto a #UD exception =
stack=0A=0ASigned-off-by: Keir Fraser <keir@xen.org>=0A=0A--- a/xen/arch/x8=
6/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=
=0A@@ -1353,7 +1353,7 @@ x86_emulate(=0A     }=0A =0A     /* Lock prefix =
is allowed only on RMW instructions. */=0A-    generate_exception_if((d & =
Mov) && lock_prefix, EXC_GP, 0);=0A+    generate_exception_if((d & Mov) && =
lock_prefix, EXC_UD, -1);=0A =0A     /* ModRM and SIB bytes. */=0A     if =
( d & ModRM )=0A@@ -1572,12 +1572,12 @@ x86_emulate(=0A             =
lock_prefix &&=0A             ((b < 0x20) || (b > 0x23)) && /* MOV CRn/DRn =
*/=0A             (b !=3D 0xc7),                  /* CMPXCHG{8,16}B */=0A- =
           EXC_GP, 0);=0A+            EXC_UD, -1);=0A         dst.type =3D =
OP_NONE;=0A         break;=0A =0A     case DstReg:=0A-        generate_exce=
ption_if(lock_prefix, EXC_GP, 0);=0A+        generate_exception_if(lock_pre=
fix, EXC_UD, -1);=0A         dst.type =3D OP_REG;=0A         if ( d & =
ByteOp )=0A         {=0A@@ -1633,7 +1633,7 @@ x86_emulate(=0A         dst =
=3D ea;=0A         if ( dst.type =3D=3D OP_REG )=0A         {=0A-          =
  generate_exception_if(lock_prefix, EXC_GP, 0);=0A+            generate_ex=
ception_if(lock_prefix, EXC_UD, -1);=0A             switch ( dst.bytes =
)=0A             {=0A             case 1: dst.val =3D *(uint8_t  *)dst.reg;=
 break;=0A@@ -3645,14 +3645,14 @@ x86_emulate(=0A         struct segment_re=
gister cs =3D { 0 }, ss =3D { 0 };=0A         int rc;=0A =0A-        =
generate_exception_if(in_realmode(ctxt, ops), EXC_UD, 0);=0A-        =
generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, 0);=0A+        =
generate_exception_if(in_realmode(ctxt, ops), EXC_UD, -1);=0A+        =
generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);=0A =0A         =
/* Inject #UD if syscall/sysret are disabled. */=0A         fail_if(ops->re=
ad_msr =3D=3D NULL);=0A         if ( (rc =3D ops->read_msr(MSR_EFER, =
&msr_content, ctxt)) !=3D 0 )=0A             goto done;=0A-        =
generate_exception_if((msr_content & EFER_SCE) =3D=3D 0, EXC_UD, 0);=0A+   =
     generate_exception_if((msr_content & EFER_SCE) =3D=3D 0, EXC_UD, =
-1);=0A =0A         if ( (rc =3D ops->read_msr(MSR_STAR, &msr_content, =
ctxt)) !=3D 0 )=0A             goto done;=0A
--=__PartA9876CD3.0__=
Content-Type: text/plain; name="25101-x86-hpet-disable.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="25101-x86-hpet-disable.patch"

References: bnc#748896=0A=0A# HG changeset patch=0A# User Jan Beulich =
<jbeulich@suse.com>=0A# Date 1332854423 -7200=0A# Node ID f06ff3dfde08ee563=
970cffba502742249ff5820=0A# Parent  ed48258053aea953afd28b746b53af7b8b30531=
b=0Ax86/hpet: disable before reboot or kexec=0A=0ALinux up to now is not =
smart enough to properly clear the HPET when it=0Aboots, which is =
particularly a problem when a kdump attempt from=0Arunning under Xen is =
being made. Linux itself added code to work around=0Athis to its shutdown =
paths quite some time ago, so let's do something=0Asimilar in Xen: Save =
the configuration register settings during boot,=0Aand restore them during =
shutdown. This should cover the majority of=0Acases where the secondary =
kernel might not come up because timer=0Ainterrupts don't work.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Keir Fraser <keir@xen.=
org>=0A=0A--- a/xen/arch/x86/crash.c=0A+++ b/xen/arch/x86/crash.c=0A@@ =
-94,6 +94,7 @@ static void nmi_shootdown_cpus(void)=0A     x2apic_enabled =
=3D (current_local_apic_mode() =3D=3D APIC_MODE_X2APIC);=0A =0A     =
disable_IO_APIC();=0A+    hpet_disable();=0A }=0A =0A void machine_crash_sh=
utdown(void)=0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ =
-721,12 +721,14 @@ int hpet_legacy_irq_tick(void)=0A     return 1;=0A }=0A =
=0A+static u32 *hpet_boot_cfg;=0A+=0A u64 hpet_setup(void)=0A {=0A     =
static u64 hpet_rate;=0A     static u32 system_reset_latch;=0A     u32 =
hpet_id, hpet_period, cfg;=0A-    int i;=0A+    unsigned int i, last;=0A =
=0A     if ( system_reset_latch =3D=3D system_reset_counter )=0A         =
return hpet_rate;=0A@@ -752,13 +754,20 @@ u64 hpet_setup(void)=0A         =
return 0;=0A     }=0A =0A+    last =3D (hpet_id & HPET_ID_NUMBER) >> =
HPET_ID_NUMBER_SHIFT;=0A+    hpet_boot_cfg =3D xmalloc_array(u32, 2 + =
last);=0A+=0A     cfg =3D hpet_read32(HPET_CFG);=0A+    if ( hpet_boot_cfg =
)=0A+        *hpet_boot_cfg =3D cfg;=0A     cfg &=3D ~(HPET_CFG_ENABLE | =
HPET_CFG_LEGACY);=0A     hpet_write32(cfg, HPET_CFG);=0A =0A-    for ( i =
=3D 0; i <=3D ((hpet_id >> 8) & 31); i++ )=0A+    for ( i =3D 0; i <=3D =
last; ++i )=0A     {=0A         cfg =3D hpet_read32(HPET_Tn_CFG(i));=0A+   =
     if ( hpet_boot_cfg )=0A+            hpet_boot_cfg[i + 1] =3D cfg;=0A  =
       cfg &=3D ~HPET_TN_ENABLE;=0A         hpet_write32(cfg, HPET_Tn_CFG(i=
));=0A     }=0A@@ -772,3 +781,21 @@ u64 hpet_setup(void)=0A =0A     return =
hpet_rate;=0A }=0A+=0A+void hpet_disable(void)=0A+{=0A+    unsigned int =
i;=0A+    u32 id;=0A+=0A+    if ( !hpet_boot_cfg )=0A+        return;=0A+=
=0A+    hpet_write32(*hpet_boot_cfg & ~HPET_CFG_ENABLE, HPET_CFG);=0A+=0A+ =
   id =3D hpet_read32(HPET_ID);=0A+    for ( i =3D 0; i <=3D ((id & =
HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT); ++i )=0A+        hpet_write32(hpe=
t_boot_cfg[i + 1], HPET_Tn_CFG(i));=0A+=0A+    if ( *hpet_boot_cfg & =
HPET_CFG_ENABLE )=0A+        hpet_write32(*hpet_boot_cfg, HPET_CFG);=0A+}=
=0A--- a/xen/arch/x86/smp.c=0A+++ b/xen/arch/x86/smp.c=0A@@ -19,6 +19,7 =
@@=0A #include <asm/mc146818rtc.h>=0A #include <asm/flushtlb.h>=0A =
#include <asm/hardirq.h>=0A+#include <asm/hpet.h>=0A #include <asm/hvm/supp=
ort.h>=0A #include <mach_apic.h>=0A =0A@@ -373,6 +374,7 @@ void smp_send_st=
op(void)=0A     local_irq_disable();=0A     __stop_this_cpu();=0A     =
disable_IO_APIC();=0A+    hpet_disable();=0A     local_irq_enable();=0A =
}=0A =0A--- a/xen/include/asm-x86/hpet.h=0A+++ b/xen/include/asm-x86/hpet.h=
=0A@@ -68,6 +68,11 @@ extern unsigned long hpet_address;=0A u64 hpet_setup(=
void);=0A =0A /*=0A+ * Disable HPET hardware: restore it to boot time =
state.=0A+ */=0A+void hpet_disable(void);=0A+=0A+/*=0A  * Callback from =
legacy timer (PIT channel 0) IRQ handler.=0A  * Returns 1 if tick =
originated from HPET; else 0.=0A  */=0A
--=__PartA9876CD3.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartA9876CD3.0__=--


From xen-devel-bounces@lists.xen.org Fri Apr 13 07:56:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:56:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbMu-0002bX-QL; Fri, 13 Apr 2012 07:56:32 +0000
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 1SIbMt-0002bR-P7
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:56:31 +0000
Received: from [193.109.254.147:39811] by server-9.bemta-14.messagelabs.com id
	0C/BF-05787-E2CD78F4; Fri, 13 Apr 2012 07:56:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334303789!4422877!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9450 invoked from network); 13 Apr 2012 07:56:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 07:56:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 08:56:28 +0100
Message-Id: <4F87F84B020000780007DB52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 08:56:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sheng Yang" <sheng@yasker.org>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
In-Reply-To: <CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
> I've compiled a kernel, force sched_clock_stable=0, then it solved the
> timestamp jump issue as expected. Luckily, seems it also solved the call
> trace and guest hang issue as well.

And this is also how it should be fixed.

> Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I think
> the issue can be easily reproduced using a Westmere or SandyBridge
> machine(my old colleagues at Intel said the feature likely existed after
> Nehalem) running newer version of PV guest, check the guest cpuinfo you
> would see nonstop_tsc, and you would notice the abnormal timestamp of
> printk.

Masking the entire leaf is certainly out of question. And even masking
the individual bit is questionable - a PV kernel simply shouldn't look at
it imo (for other than possibly reporting to user mode purposes).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 07:56:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 07:56:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbMu-0002bX-QL; Fri, 13 Apr 2012 07:56:32 +0000
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 1SIbMt-0002bR-P7
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 07:56:31 +0000
Received: from [193.109.254.147:39811] by server-9.bemta-14.messagelabs.com id
	0C/BF-05787-E2CD78F4; Fri, 13 Apr 2012 07:56:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334303789!4422877!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9450 invoked from network); 13 Apr 2012 07:56:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 07:56:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 08:56:28 +0100
Message-Id: <4F87F84B020000780007DB52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 08:56:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sheng Yang" <sheng@yasker.org>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
In-Reply-To: <CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
> I've compiled a kernel, force sched_clock_stable=0, then it solved the
> timestamp jump issue as expected. Luckily, seems it also solved the call
> trace and guest hang issue as well.

And this is also how it should be fixed.

> Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I think
> the issue can be easily reproduced using a Westmere or SandyBridge
> machine(my old colleagues at Intel said the feature likely existed after
> Nehalem) running newer version of PV guest, check the guest cpuinfo you
> would see nonstop_tsc, and you would notice the abnormal timestamp of
> printk.

Masking the entire leaf is certainly out of question. And even masking
the individual bit is questionable - a PV kernel simply shouldn't look at
it imo (for other than possibly reporting to user mode purposes).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 08:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 08:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbQa-0003LA-55; Fri, 13 Apr 2012 08:00:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIbQY-0003Kk-Ra
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 08:00:19 +0000
Received: from [85.158.139.83:25094] by server-3.bemta-5.messagelabs.com id
	43/E9-25237-21DD78F4; Fri, 13 Apr 2012 08:00:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334304015!23633022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 13 Apr 2012 08:00:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 08:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11917336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 08:00:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 09:00:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIbQU-0005mL-N5;
	Fri, 13 Apr 2012 08:00:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIbQU-00049V-MU;
	Fri, 13 Apr 2012 09:00:14 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12669-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 09:00:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12669: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12669 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12669/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12640
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail like 12640

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=4db776322827f0930d53b9e162dc1c6600d918d0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable 4db776322827f0930d53b9e162dc1c6600d918d0
+ branch=qemu-upstream-unstable
+ revision=4db776322827f0930d53b9e162dc1c6600d918d0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git 4db776322827f0930d53b9e162dc1c6600d918d0:master
Counting objects: 10   
Counting objects: 20, done.
Compressing objects:  25% (1/4)   
Compressing objects:  50% (2/4)   
Compressing objects:  75% (3/4)   
Compressing objects: 100% (4/4)   
Compressing objects: 100% (4/4), done.
Writing objects:   6% (1/16)   
Writing objects:  12% (2/16)   
Writing objects:  18% (3/16)   
Writing objects:  25% (4/16)   
Writing objects:  31% (5/16)   
Writing objects:  37% (6/16)   
Writing objects:  43% (7/16)   
Writing objects:  56% (9/16)   
Writing objects:  62% (10/16)   
Writing objects:  68% (11/16)   
Writing objects:  75% (12/16)   
Writing objects:  81% (13/16)   
Writing objects:  87% (14/16)   
Writing objects:  93% (15/16)   
Writing objects: 100% (16/16)   
Writing objects: 100% (16/16), 2.00 KiB, done.
Total 16 (delta 12), reused 16 (delta 12)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   e161598..4db7763  4db776322827f0930d53b9e162dc1c6600d918d0 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 08:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 08:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbQa-0003LA-55; Fri, 13 Apr 2012 08:00:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIbQY-0003Kk-Ra
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 08:00:19 +0000
Received: from [85.158.139.83:25094] by server-3.bemta-5.messagelabs.com id
	43/E9-25237-21DD78F4; Fri, 13 Apr 2012 08:00:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334304015!23633022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 13 Apr 2012 08:00:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 08:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11917336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 08:00:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 09:00:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIbQU-0005mL-N5;
	Fri, 13 Apr 2012 08:00:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIbQU-00049V-MU;
	Fri, 13 Apr 2012 09:00:14 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12669-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 09:00:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12669: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12669 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12669/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12640
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail like 12640

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-qemuu-win   7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  7 windows-install    fail never pass

version targeted for testing:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0
baseline version:
 qemuu                e1615984e765751b430f86be679c0b74b5d5cd15

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=4db776322827f0930d53b9e162dc1c6600d918d0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable 4db776322827f0930d53b9e162dc1c6600d918d0
+ branch=qemu-upstream-unstable
+ revision=4db776322827f0930d53b9e162dc1c6600d918d0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git 4db776322827f0930d53b9e162dc1c6600d918d0:master
Counting objects: 10   
Counting objects: 20, done.
Compressing objects:  25% (1/4)   
Compressing objects:  50% (2/4)   
Compressing objects:  75% (3/4)   
Compressing objects: 100% (4/4)   
Compressing objects: 100% (4/4), done.
Writing objects:   6% (1/16)   
Writing objects:  12% (2/16)   
Writing objects:  18% (3/16)   
Writing objects:  25% (4/16)   
Writing objects:  31% (5/16)   
Writing objects:  37% (6/16)   
Writing objects:  43% (7/16)   
Writing objects:  56% (9/16)   
Writing objects:  62% (10/16)   
Writing objects:  68% (11/16)   
Writing objects:  75% (12/16)   
Writing objects:  81% (13/16)   
Writing objects:  87% (14/16)   
Writing objects:  93% (15/16)   
Writing objects: 100% (16/16)   
Writing objects: 100% (16/16), 2.00 KiB, done.
Total 16 (delta 12), reused 16 (delta 12)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   e161598..4db7763  4db776322827f0930d53b9e162dc1c6600d918d0 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 08:30:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 08:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbtS-0004Hr-N6; Fri, 13 Apr 2012 08:30:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIbtQ-0004Hk-WC
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 08:30:09 +0000
Received: from [85.158.143.35:45664] by server-2.bemta-4.messagelabs.com id
	D9/80-17550-014E78F4; Fri, 13 Apr 2012 08:30:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334305806!11159578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7741 invoked from network); 13 Apr 2012 08:30:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 08:30:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 09:30:05 +0100
Message-Id: <4F88002D020000780007DB8D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 09:30:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>,
 "Yang Z Zhang" <yang.z.zhang@intel.com>
References: <4F86D464.4080601@amd.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: AndrePrzywara <andre.przywara@amd.com>, Wei Huang <wei.huang2@amd.com>,
	Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
 ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 04:14, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> This should not be enough. No need to check bm when going to C2.
> How about the following patch:

That looks right, but I'd prefer to simplify it a little:

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -493,7 +493,9 @@ static void acpi_processor_idle(void)
          * not set. In that case we cannot do much, we enter C3
          * without doing anything.
          */
-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( cx->type != ACPI_STATE_C3 )
+            /* nothing to be done here */;
+        else if ( power->flags.bm_check && power->flags.bm_control )
         {
             spin_lock(&c3_cpu_status.lock);
             if ( ++c3_cpu_status.count == num_online_cpus() )
@@ -515,7 +517,8 @@ static void acpi_processor_idle(void)
         /* Invoke C3 */
         acpi_idle_do_entry(cx);
 
-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) &&
+             power->flags.bm_check && power->flags.bm_control )
         {
             /* Enable bus master arbitration */
             spin_lock(&c3_cpu_status.lock);

Also, Yang, you didn't provide a S-o-b - are you okay with me adding
it?

If you're both okay with above patch, I'll see that I get it committed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 08:30:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 08:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIbtS-0004Hr-N6; Fri, 13 Apr 2012 08:30:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIbtQ-0004Hk-WC
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 08:30:09 +0000
Received: from [85.158.143.35:45664] by server-2.bemta-4.messagelabs.com id
	D9/80-17550-014E78F4; Fri, 13 Apr 2012 08:30:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334305806!11159578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7741 invoked from network); 13 Apr 2012 08:30:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 08:30:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 09:30:05 +0100
Message-Id: <4F88002D020000780007DB8D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 09:30:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>,
 "Yang Z Zhang" <yang.z.zhang@intel.com>
References: <4F86D464.4080601@amd.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: AndrePrzywara <andre.przywara@amd.com>, Wei Huang <wei.huang2@amd.com>,
	Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
 ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 04:14, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> This should not be enough. No need to check bm when going to C2.
> How about the following patch:

That looks right, but I'd prefer to simplify it a little:

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -493,7 +493,9 @@ static void acpi_processor_idle(void)
          * not set. In that case we cannot do much, we enter C3
          * without doing anything.
          */
-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( cx->type != ACPI_STATE_C3 )
+            /* nothing to be done here */;
+        else if ( power->flags.bm_check && power->flags.bm_control )
         {
             spin_lock(&c3_cpu_status.lock);
             if ( ++c3_cpu_status.count == num_online_cpus() )
@@ -515,7 +517,8 @@ static void acpi_processor_idle(void)
         /* Invoke C3 */
         acpi_idle_do_entry(cx);
 
-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) &&
+             power->flags.bm_check && power->flags.bm_control )
         {
             /* Enable bus master arbitration */
             spin_lock(&c3_cpu_status.lock);

Also, Yang, you didn't provide a S-o-b - are you okay with me adding
it?

If you're both okay with above patch, I'll see that I get it committed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:03:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcOt-0004iw-E6; Fri, 13 Apr 2012 09:02:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SIcOs-0004ir-8b
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 09:02:38 +0000
Received: from [85.158.143.99:8726] by server-1.bemta-4.messagelabs.com id
	33/71-20925-DABE78F4; Fri, 13 Apr 2012 09:02:37 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334307754!22940534!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8058 invoked from network); 13 Apr 2012 09:02:36 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 09:02:36 -0000
Received: from mail180-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 09:02:34 +0000
Received: from mail180-ch1 (localhost [127.0.0.1])	by
	mail180-ch1-R.bigfish.com (Postfix) with ESMTP id 09CAB2A051A;
	Fri, 13 Apr 2012 09:02:34 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1
	(MessageSwitch) id 1334307752682945_28006;
	Fri, 13 Apr 2012 09:02:32 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.228])	by mail180-ch1.bigfish.com (Postfix) with ESMTP id
	96FBB140091;	Fri, 13 Apr 2012 09:02:32 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 09:02:32 +0000
X-WSS-ID: 0M2EUG2-02-00R-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DB64FCC024;	Fri, 13 Apr 2012 04:01:51 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 04:02:11 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 13 Apr 2012 04:01:53 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	05:01:23 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8648649C1F5; Fri, 13 Apr 2012
	10:01:22 +0100 (BST)
Message-ID: <4F87EC89.6080206@amd.com>
Date: Fri, 13 Apr 2012 11:06:17 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F86D464.4080601@amd.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
	<4F88002D020000780007DB8D@nat28.tlf.novell.com>
In-Reply-To: <4F88002D020000780007DB8D@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: AndrePrzywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Boris Ostrovsky <Boris.Ostrovsky@amd.com>,
	Wei Huang <wei.huang2@amd.com>, Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/13/2012 10:30 AM, Jan Beulich wrote:
>>>> On 13.04.12 at 04:14, "Zhang, Yang Z"<yang.z.zhang@intel.com>  wrote:
>> This should not be enough. No need to check bm when going to C2.
>> How about the following patch:
>
> That looks right, but I'd prefer to simplify it a little:
>
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -493,7 +493,9 @@ static void acpi_processor_idle(void)
>            * not set. In that case we cannot do much, we enter C3
>            * without doing anything.
>            */
> -        if ( power->flags.bm_check&&  power->flags.bm_control )
> +        if ( cx->type != ACPI_STATE_C3 )
> +            /* nothing to be done here */;
> +        else if ( power->flags.bm_check&&  power->flags.bm_control )
>           {
>               spin_lock(&c3_cpu_status.lock);
>               if ( ++c3_cpu_status.count == num_online_cpus() )
> @@ -515,7 +517,8 @@ static void acpi_processor_idle(void)
>           /* Invoke C3 */
>           acpi_idle_do_entry(cx);
>
> -        if ( power->flags.bm_check&&  power->flags.bm_control )
> +        if ( (cx->type == ACPI_STATE_C3)&&
> +             power->flags.bm_check&&  power->flags.bm_control )
>           {
>               /* Enable bus master arbitration */
>               spin_lock(&c3_cpu_status.lock);
>
> Also, Yang, you didn't provide a S-o-b - are you okay with me adding
> it?
>
> If you're both okay with above patch, I'll see that I get it committed.
>
> Jan
>
>

This looks good to me. Thanks
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:03:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcOt-0004iw-E6; Fri, 13 Apr 2012 09:02:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SIcOs-0004ir-8b
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 09:02:38 +0000
Received: from [85.158.143.99:8726] by server-1.bemta-4.messagelabs.com id
	33/71-20925-DABE78F4; Fri, 13 Apr 2012 09:02:37 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334307754!22940534!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8058 invoked from network); 13 Apr 2012 09:02:36 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 09:02:36 -0000
Received: from mail180-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 09:02:34 +0000
Received: from mail180-ch1 (localhost [127.0.0.1])	by
	mail180-ch1-R.bigfish.com (Postfix) with ESMTP id 09CAB2A051A;
	Fri, 13 Apr 2012 09:02:34 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1
	(MessageSwitch) id 1334307752682945_28006;
	Fri, 13 Apr 2012 09:02:32 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.228])	by mail180-ch1.bigfish.com (Postfix) with ESMTP id
	96FBB140091;	Fri, 13 Apr 2012 09:02:32 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 09:02:32 +0000
X-WSS-ID: 0M2EUG2-02-00R-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DB64FCC024;	Fri, 13 Apr 2012 04:01:51 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 04:02:11 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 13 Apr 2012 04:01:53 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	05:01:23 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8648649C1F5; Fri, 13 Apr 2012
	10:01:22 +0100 (BST)
Message-ID: <4F87EC89.6080206@amd.com>
Date: Fri, 13 Apr 2012 11:06:17 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F86D464.4080601@amd.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
	<4F88002D020000780007DB8D@nat28.tlf.novell.com>
In-Reply-To: <4F88002D020000780007DB8D@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: AndrePrzywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Boris Ostrovsky <Boris.Ostrovsky@amd.com>,
	Wei Huang <wei.huang2@amd.com>, Yang Z Zhang <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/13/2012 10:30 AM, Jan Beulich wrote:
>>>> On 13.04.12 at 04:14, "Zhang, Yang Z"<yang.z.zhang@intel.com>  wrote:
>> This should not be enough. No need to check bm when going to C2.
>> How about the following patch:
>
> That looks right, but I'd prefer to simplify it a little:
>
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -493,7 +493,9 @@ static void acpi_processor_idle(void)
>            * not set. In that case we cannot do much, we enter C3
>            * without doing anything.
>            */
> -        if ( power->flags.bm_check&&  power->flags.bm_control )
> +        if ( cx->type != ACPI_STATE_C3 )
> +            /* nothing to be done here */;
> +        else if ( power->flags.bm_check&&  power->flags.bm_control )
>           {
>               spin_lock(&c3_cpu_status.lock);
>               if ( ++c3_cpu_status.count == num_online_cpus() )
> @@ -515,7 +517,8 @@ static void acpi_processor_idle(void)
>           /* Invoke C3 */
>           acpi_idle_do_entry(cx);
>
> -        if ( power->flags.bm_check&&  power->flags.bm_control )
> +        if ( (cx->type == ACPI_STATE_C3)&&
> +             power->flags.bm_check&&  power->flags.bm_control )
>           {
>               /* Enable bus master arbitration */
>               spin_lock(&c3_cpu_status.lock);
>
> Also, Yang, you didn't provide a S-o-b - are you okay with me adding
> it?
>
> If you're both okay with above patch, I'll see that I get it committed.
>
> Jan
>
>

This looks good to me. Thanks
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcVI-0004tT-BW; Fri, 13 Apr 2012 09:09:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SIcVG-0004tM-RM
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 09:09:15 +0000
Received: from [85.158.139.83:47069] by server-3.bemta-5.messagelabs.com id
	6F/35-25237-A3DE78F4; Fri, 13 Apr 2012 09:09:14 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334308152!19050680!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15450 invoked from network); 13 Apr 2012 09:09:13 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 09:09:13 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 8EEEBDBC74;
	Fri, 13 Apr 2012 17:08:57 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 17:08:12 +0800
Message-ID: <1334308092.2538.2.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__domain_build_info_setdefault may be called several times,
so rtc_timeoffset can't be setted in it.

Move rtc_timeoffset setting logic to libxl__build_pre.

Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 tools/libxl/libxl_create.c |    9 ---------
 tools/libxl/libxl_dom.c    |   17 +++++++++++++++--
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..e706124 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->target_memkb = b_info->max_memkb;
 
     libxl_defbool_setdefault(&b_info->localtime, false);
-    if (libxl_defbool_val(b_info->localtime)) {
-        time_t t;
-        struct tm *tm;
-
-        t = time(NULL);
-        tm = localtime(&t);
-
-        b_info->rtc_timeoffset += tm->tm_gmtoff;
-    }
 
     libxl_defbool_setdefault(&b_info->disable_migrate, false);
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..91c4bd8 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
     char *xs_domid, *con_domid;
+    uint32_t rtc_timeoffset;
+
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
@@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
-    if (info->rtc_timeoffset)
-        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
+    rtc_timeoffset = info->rtc_timeoffset;
+    if (libxl_defbool_val(info->localtime)) {
+        time_t t;
+        struct tm *tm;
+
+        t = time(NULL);
+        tm = localtime(&t);
+
+        rtc_timeoffset += tm->tm_gmtoff;
+    }
+
+    if (rtc_timeoffset)
+        xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffset);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         unsigned long shadow;
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcVI-0004tT-BW; Fri, 13 Apr 2012 09:09:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SIcVG-0004tM-RM
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 09:09:15 +0000
Received: from [85.158.139.83:47069] by server-3.bemta-5.messagelabs.com id
	6F/35-25237-A3DE78F4; Fri, 13 Apr 2012 09:09:14 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334308152!19050680!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15450 invoked from network); 13 Apr 2012 09:09:13 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 09:09:13 -0000
Received: from [192.168.1.200] (unknown [116.237.134.146])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 8EEEBDBC74;
	Fri, 13 Apr 2012 17:08:57 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 17:08:12 +0800
Message-ID: <1334308092.2538.2.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__domain_build_info_setdefault may be called several times,
so rtc_timeoffset can't be setted in it.

Move rtc_timeoffset setting logic to libxl__build_pre.

Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 tools/libxl/libxl_create.c |    9 ---------
 tools/libxl/libxl_dom.c    |   17 +++++++++++++++--
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..e706124 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->target_memkb = b_info->max_memkb;
 
     libxl_defbool_setdefault(&b_info->localtime, false);
-    if (libxl_defbool_val(b_info->localtime)) {
-        time_t t;
-        struct tm *tm;
-
-        t = time(NULL);
-        tm = localtime(&t);
-
-        b_info->rtc_timeoffset += tm->tm_gmtoff;
-    }
 
     libxl_defbool_setdefault(&b_info->disable_migrate, false);
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..91c4bd8 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
     char *xs_domid, *con_domid;
+    uint32_t rtc_timeoffset;
+
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
@@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
-    if (info->rtc_timeoffset)
-        xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset);
+    rtc_timeoffset = info->rtc_timeoffset;
+    if (libxl_defbool_val(info->localtime)) {
+        time_t t;
+        struct tm *tm;
+
+        t = time(NULL);
+        tm = localtime(&t);
+
+        rtc_timeoffset += tm->tm_gmtoff;
+    }
+
+    if (rtc_timeoffset)
+        xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffset);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         unsigned long shadow;
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:17:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcce-00058S-9D; Fri, 13 Apr 2012 09:16:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIccd-00058N-1e
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 09:16:51 +0000
Received: from [85.158.138.51:11046] by server-2.bemta-3.messagelabs.com id
	98/F2-09269-20FE78F4; Fri, 13 Apr 2012 09:16:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334308609!10981495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17630 invoked from network); 13 Apr 2012 09:16:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 09:16:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11919844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 09:16:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 10:16:49 +0100
Message-ID: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 10:16:47 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] autoconf: --enable-githttp doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is because the toplevel Config.mk does not include config/Tools.mk
and therefore GIT_HTTP is not defined.

I'm not sure what the best fix here is, we don't really want to include
config/Tools.mk in the top-level Config.mk since that would mean you had
to run configure to build the hypervisor, which we want to avoid.

Perhaps a bunch of the tools-level config stuff from Config.mk should go
into config/Tools.mk.in? It looks like most of the content of Config.mk
from the definition of QEMU_REMOTE onwards could/should be moved but
I've not actually tried it.

Or perhaps some stuff should become actual configure options,
CONFIG_{OVMF,ROMBIOS,SEABIOS} and ETHERBOOT_NICS seem like good
candidates for that. Perhaps --qemu-upstream-url=URL etc make sense too?
I'm less sure there.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:17:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcce-00058S-9D; Fri, 13 Apr 2012 09:16:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIccd-00058N-1e
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 09:16:51 +0000
Received: from [85.158.138.51:11046] by server-2.bemta-3.messagelabs.com id
	98/F2-09269-20FE78F4; Fri, 13 Apr 2012 09:16:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334308609!10981495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17630 invoked from network); 13 Apr 2012 09:16:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 09:16:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11919844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 09:16:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 10:16:49 +0100
Message-ID: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 10:16:47 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] autoconf: --enable-githttp doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is because the toplevel Config.mk does not include config/Tools.mk
and therefore GIT_HTTP is not defined.

I'm not sure what the best fix here is, we don't really want to include
config/Tools.mk in the top-level Config.mk since that would mean you had
to run configure to build the hypervisor, which we want to avoid.

Perhaps a bunch of the tools-level config stuff from Config.mk should go
into config/Tools.mk.in? It looks like most of the content of Config.mk
from the definition of QEMU_REMOTE onwards could/should be moved but
I've not actually tried it.

Or perhaps some stuff should become actual configure options,
CONFIG_{OVMF,ROMBIOS,SEABIOS} and ETHERBOOT_NICS seem like good
candidates for that. Perhaps --qemu-upstream-url=URL etc make sense too?
I'm less sure there.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcxB-0005K7-5P; Fri, 13 Apr 2012 09:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIcx9-0005K2-9p
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 09:38:03 +0000
Received: from [85.158.143.99:10948] by server-1.bemta-4.messagelabs.com id
	DA/BD-20925-AF3F78F4; Fri, 13 Apr 2012 09:38:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334309881!23165482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18971 invoked from network); 13 Apr 2012 09:38:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 09:38:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11920470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 09:38:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 10:38:01 +0100
Message-ID: <1334309880.14560.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Fri, 13 Apr 2012 10:38:00 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:29 +0100, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: Wednesday, April 11, 2012 4:45 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > On Tue, 2012-04-10 at 20:04 +0100, Ross Philipson wrote:
> > > Not really. I think part of the problem here is my mixing of
> > > terminology. For SMBIOS bits I am pulling apart the overall SMBIOS
> > > table and just grabbing a desired subset of the SMBIOS structures. The
> > > individual structures are the entities that do not have an overall
> > > length field
> > 
> > So, to use the terminology of tools/firmware/hvmloader/smbios_types.h,
> > you have entities which are subsets of a structure and so do not start
> > with a "struct smbios_structure_header"?
> > 
> > Ian.
> > 
> 
> Yea so the entire SMBIOS table begins with the "struct
> smbios_entry_point" which is not present in what I pass in. I have N
> structs (possibly some of the same type) that start with a "struct
> smbios_structure_header". The gotcha is that the "length" field only
> defines the fixed portion of each of the SMBIOS structs. There can be
> any number of strings following that struct of varying length.

Ah, that's the bit I had forgotten...

>  Then entire structure is doubly terminated with "\0\0". What I wanted
> to avoid is having to put the parsing code in hvmloader to reparse for
> each struct, which was already done by the tools. A simple approach is
> to use the <length><blob> scheme.

Yes, I see now why this is necessary, thanks for plugging away at my
understanding ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 09:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 09:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIcxB-0005K7-5P; Fri, 13 Apr 2012 09:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIcx9-0005K2-9p
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 09:38:03 +0000
Received: from [85.158.143.99:10948] by server-1.bemta-4.messagelabs.com id
	DA/BD-20925-AF3F78F4; Fri, 13 Apr 2012 09:38:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334309881!23165482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDA5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18971 invoked from network); 13 Apr 2012 09:38:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 09:38:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11920470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 09:38:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 10:38:01 +0100
Message-ID: <1334309880.14560.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Fri, 13 Apr 2012 10:38:00 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-11 at 17:29 +0100, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: Wednesday, April 11, 2012 4:45 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > On Tue, 2012-04-10 at 20:04 +0100, Ross Philipson wrote:
> > > Not really. I think part of the problem here is my mixing of
> > > terminology. For SMBIOS bits I am pulling apart the overall SMBIOS
> > > table and just grabbing a desired subset of the SMBIOS structures. The
> > > individual structures are the entities that do not have an overall
> > > length field
> > 
> > So, to use the terminology of tools/firmware/hvmloader/smbios_types.h,
> > you have entities which are subsets of a structure and so do not start
> > with a "struct smbios_structure_header"?
> > 
> > Ian.
> > 
> 
> Yea so the entire SMBIOS table begins with the "struct
> smbios_entry_point" which is not present in what I pass in. I have N
> structs (possibly some of the same type) that start with a "struct
> smbios_structure_header". The gotcha is that the "length" field only
> defines the fixed portion of each of the SMBIOS structs. There can be
> any number of strings following that struct of varying length.

Ah, that's the bit I had forgotten...

>  Then entire structure is doubly terminated with "\0\0". What I wanted
> to avoid is having to put the parsing code in hvmloader to reparse for
> each struct, which was already done by the tools. A simple approach is
> to use the <length><blob> scheme.

Yes, I see now why this is necessary, thanks for plugging away at my
understanding ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:03:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdLC-0005fg-7f; Fri, 13 Apr 2012 10:02:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIdLA-0005fb-Lo
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:02:52 +0000
Received: from [85.158.139.83:53741] by server-8.bemta-5.messagelabs.com id
	22/AF-26964-BC9F78F4; Fri, 13 Apr 2012 10:02:51 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334311368!23123033!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4963 invoked from network); 13 Apr 2012 10:02:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330923600"; d="scan'208";a="24130673"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 06:02:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 06:02:47 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIdL5-0003ib-3v;
	Fri, 13 Apr 2012 11:02:47 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 13 Apr 2012 11:02:40 +0100
Message-ID: <1334311360-32847-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: zhihao wang <accept.acm@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl/build: print a pretty message if
	flex/bison are needed but not found
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patchs adds better support for both Flex and Bison, which might be needed
to compile libxl. Now configure script sets BISON and FLEX Makefile vars if
bison and flex are found, but doesn't complain if they are not found.

Also, added some Makefile soccery to print a nice error message if Bison or Flex
are needed but not found.

Please run autogen after applying this patch.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: zhihao wang <accept.acm@gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/configure.ac   |    2 ++
 tools/libxl/Makefile |   16 ++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 3da0c82..8ccdc92 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -75,6 +75,8 @@ AC_PROG_CC
 AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
+AC_PATH_PROG([BISON], [bison])
+AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index ac8b810..e8ec8e9 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -48,6 +48,18 @@ please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
 endif
 endif
 
+ifeq ($(FLEX),)
+%.c %.h:: %.l
+	$(error Flex is needed to compile libxl, please install it and rerun \
+	configure)
+endif
+
+ifeq ($(BISON),)
+%.c %.h:: %.y
+	$(error Bison is needed to compile libxl, please install it an rerun \
+	configure)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
@@ -83,11 +95,11 @@ all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
-%.c %.h: %.y
+%.c %.h:: %.y
 	@rm -f $*.[ch]
 	$(BISON) --output=$*.c $<
 
-%.c %.h: %.l
+%.c %.h:: %.l
 	@rm -f $*.[ch]
 	$(FLEX) --header-file=$*.h --outfile=$*.c $<
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:03:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdLC-0005fg-7f; Fri, 13 Apr 2012 10:02:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIdLA-0005fb-Lo
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:02:52 +0000
Received: from [85.158.139.83:53741] by server-8.bemta-5.messagelabs.com id
	22/AF-26964-BC9F78F4; Fri, 13 Apr 2012 10:02:51 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334311368!23123033!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4963 invoked from network); 13 Apr 2012 10:02:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330923600"; d="scan'208";a="24130673"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 06:02:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 06:02:47 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIdL5-0003ib-3v;
	Fri, 13 Apr 2012 11:02:47 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 13 Apr 2012 11:02:40 +0100
Message-ID: <1334311360-32847-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: zhihao wang <accept.acm@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl/build: print a pretty message if
	flex/bison are needed but not found
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patchs adds better support for both Flex and Bison, which might be needed
to compile libxl. Now configure script sets BISON and FLEX Makefile vars if
bison and flex are found, but doesn't complain if they are not found.

Also, added some Makefile soccery to print a nice error message if Bison or Flex
are needed but not found.

Please run autogen after applying this patch.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: zhihao wang <accept.acm@gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/configure.ac   |    2 ++
 tools/libxl/Makefile |   16 ++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 3da0c82..8ccdc92 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -75,6 +75,8 @@ AC_PROG_CC
 AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
+AC_PATH_PROG([BISON], [bison])
+AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index ac8b810..e8ec8e9 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -48,6 +48,18 @@ please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
 endif
 endif
 
+ifeq ($(FLEX),)
+%.c %.h:: %.l
+	$(error Flex is needed to compile libxl, please install it and rerun \
+	configure)
+endif
+
+ifeq ($(BISON),)
+%.c %.h:: %.y
+	$(error Bison is needed to compile libxl, please install it an rerun \
+	configure)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
@@ -83,11 +95,11 @@ all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
-%.c %.h: %.y
+%.c %.h:: %.y
 	@rm -f $*.[ch]
 	$(BISON) --output=$*.c $<
 
-%.c %.h: %.l
+%.c %.h:: %.l
 	@rm -f $*.[ch]
 	$(FLEX) --header-file=$*.h --outfile=$*.c $<
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:04:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:04:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdMj-0005ir-Ml; Fri, 13 Apr 2012 10:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIdMi-0005im-KA
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:04:28 +0000
Received: from [85.158.138.51:26490] by server-5.bemta-3.messagelabs.com id
	51/05-17113-B2AF78F4; Fri, 13 Apr 2012 10:04:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334311465!22028283!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9455 invoked from network); 13 Apr 2012 10:04:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:04:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330923600"; d="scan'208";a="24130714"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 06:04:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 06:04:25 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIdMe-0003kH-Qk;
	Fri, 13 Apr 2012 11:04:24 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334229871.16387.81.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:04:25 +0100
Message-ID: <4356F40F-0962-4F75-B29A-88A67F00A7CB@citrix.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 12/04/2012, a las 12:24, Ian Campbell escribi=F3:
> On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
>> Hi all,
>> =

>> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
>> Mac pro. After running ./configure and make. I got the following fatal
>> error:
>> =

>> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
>> directory compilation terminated.
>> =

>> =

>> So the original libxlu_cfg_l.h is deleted when making, and should be
>> regenerated but it is not.
> =

> Actually it should never have been deleted in the first place, unless
> you have been modifying the flex source.
> =

> Please can you enumerate the exact steps you took, starting from the
> initial clone of the repo, which caused the file to be deleted?
> =

>> I find the path of flex and bison is not set.  When I add the correct
>> path of flex and bison in tools.mk manually, This error is fixed. =

> =

> Those tools should be optional since the generated files are checked in.
> However perhaps configure should detect and provide the paths but behave
> in a non-fatal manner if they aren't available? Roger, what do you
> think?


We stopped checking for bison and flex, but we left the variables, so if th=
e user sets BISON and FLEX in their environment everything should be ok. Si=
nce this seems to be a common problem one possible solution is to check for=
 BISON and FLEX on the libxl Makefile when needed (and in configure in a no=
n fatal manner), and if not found, print an error message telling the user =
to rerun configure, instead of just failing ungracefully. I've just send a =
patch that I think fixes this issue.

> =

> Ian.
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:04:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:04:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdMj-0005ir-Ml; Fri, 13 Apr 2012 10:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIdMi-0005im-KA
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:04:28 +0000
Received: from [85.158.138.51:26490] by server-5.bemta-3.messagelabs.com id
	51/05-17113-B2AF78F4; Fri, 13 Apr 2012 10:04:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334311465!22028283!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9455 invoked from network); 13 Apr 2012 10:04:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:04:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330923600"; d="scan'208";a="24130714"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 06:04:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 06:04:25 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIdMe-0003kH-Qk;
	Fri, 13 Apr 2012 11:04:24 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334229871.16387.81.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:04:25 +0100
Message-ID: <4356F40F-0962-4F75-B29A-88A67F00A7CB@citrix.com>
References: <CABqS+pQs+09mn3yYbppOWOE8cK=zs9r2j+hh+zmtP3skjTp4oA@mail.gmail.com>
	<1334229871.16387.81.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: zhihao wang <accept.acm@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fatal error if Flex and Bison is not configured
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 12/04/2012, a las 12:24, Ian Campbell escribi=F3:
> On Thu, 2012-04-12 at 12:12 +0100, zhihao wang wrote:
>> Hi all,
>> =

>> I try to build xen 4.2( revision number: 25161) on Ubuntu 11.10_amd64,
>> Mac pro. After running ./configure and make. I got the following fatal
>> error:
>> =

>> libxlu_cfg_y.y:22:26: fatal error: libxlu_cfg_l.h: No such file or
>> directory compilation terminated.
>> =

>> =

>> So the original libxlu_cfg_l.h is deleted when making, and should be
>> regenerated but it is not.
> =

> Actually it should never have been deleted in the first place, unless
> you have been modifying the flex source.
> =

> Please can you enumerate the exact steps you took, starting from the
> initial clone of the repo, which caused the file to be deleted?
> =

>> I find the path of flex and bison is not set.  When I add the correct
>> path of flex and bison in tools.mk manually, This error is fixed. =

> =

> Those tools should be optional since the generated files are checked in.
> However perhaps configure should detect and provide the paths but behave
> in a non-fatal manner if they aren't available? Roger, what do you
> think?


We stopped checking for bison and flex, but we left the variables, so if th=
e user sets BISON and FLEX in their environment everything should be ok. Si=
nce this seems to be a common problem one possible solution is to check for=
 BISON and FLEX on the libxl Makefile when needed (and in configure in a no=
n fatal manner), and if not found, print an error message telling the user =
to rerun configure, instead of just failing ungracefully. I've just send a =
patch that I think fixes this issue.

> =

> Ian.
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdR0-0005xN-Gf; Fri, 13 Apr 2012 10:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIdQy-0005xE-QP
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 10:08:53 +0000
Received: from [85.158.143.99:21432] by server-3.bemta-4.messagelabs.com id
	A7/00-05853-43BF78F4; Fri, 13 Apr 2012 10:08:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334311731!12297440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10436 invoked from network); 13 Apr 2012 10:08:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:08:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11921479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:08:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 11:08:51 +0100
Message-ID: <1334311730.14560.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Date: Fri, 13 Apr 2012 11:08:50 +0100
In-Reply-To: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
References: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 02:38 +0100, Xuesen Guo wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels

Thanks, a single small nit inline below.

> @@ -159,6 +204,27 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return -EINVAL;

Should be return 1 in this context.

Thanks,
Ian.

> +		}
> +
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;
> +
> +		image = image + payload_offset;
> +		st.st_size = payload_length;
> +	}
> +	
>  	size = st.st_size;
>  
>  	usize = xc_dom_check_gzip(xch, image, st.st_size);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdR0-0005xN-Gf; Fri, 13 Apr 2012 10:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIdQy-0005xE-QP
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 10:08:53 +0000
Received: from [85.158.143.99:21432] by server-3.bemta-4.messagelabs.com id
	A7/00-05853-43BF78F4; Fri, 13 Apr 2012 10:08:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334311731!12297440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10436 invoked from network); 13 Apr 2012 10:08:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:08:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11921479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:08:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 11:08:51 +0100
Message-ID: <1334311730.14560.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Date: Fri, 13 Apr 2012 11:08:50 +0100
In-Reply-To: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
References: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-12 at 02:38 +0100, Xuesen Guo wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels

Thanks, a single small nit inline below.

> @@ -159,6 +204,27 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return -EINVAL;

Should be return 1 in this context.

Thanks,
Ian.

> +		}
> +
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;
> +
> +		image = image + payload_offset;
> +		st.st_size = payload_length;
> +	}
> +	
>  	size = st.st_size;
>  
>  	usize = xc_dom_check_gzip(xch, image, st.st_size);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdYI-0006Eu-D6; Fri, 13 Apr 2012 10:16:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIdYH-0006Ep-3w
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:16:25 +0000
Received: from [85.158.138.51:9750] by server-4.bemta-3.messagelabs.com id
	DD/BF-15341-8FCF78F4; Fri, 13 Apr 2012 10:16:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334312181!20178325!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30860 invoked from network); 13 Apr 2012 10:16:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330923600"; d="scan'208";a="190199760"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 06:16:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 06:16:19 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIdYB-0003vN-2s;
	Fri, 13 Apr 2012 11:16:19 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:16:19 +0100
Message-ID: <772B7F0A-F672-4ACF-8DED-728E9978AC54@citrix.com>
References: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] autoconf: --enable-githttp doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 13/04/2012, a las 10:16, Ian Campbell escribi=F3:
> This is because the toplevel Config.mk does not include config/Tools.mk
> and therefore GIT_HTTP is not defined.

Yes, sorry, this is a leftover from when I though that the output from conf=
igure would be used by the top level Config.mk file.

> =

> I'm not sure what the best fix here is, we don't really want to include
> config/Tools.mk in the top-level Config.mk since that would mean you had
> to run configure to build the hypervisor, which we want to avoid.
> =

> Perhaps a bunch of the tools-level config stuff from Config.mk should go
> into config/Tools.mk.in? It looks like most of the content of Config.mk
> from the definition of QEMU_REMOTE onwards could/should be moved but
> I've not actually tried it.

Probably, I don't think any of this are used by the hypervisor.

> =

> Or perhaps some stuff should become actual configure options,
> CONFIG_{OVMF,ROMBIOS,SEABIOS} and ETHERBOOT_NICS seem like good
> candidates for that. Perhaps --qemu-upstream-url=3DURL etc make sense too?

I'm quite confident this:

CONFIG_OVMF ?=3D n
CONFIG_ROMBIOS ?=3D y
CONFIG_SEABIOS ?=3D y

should become configure options, if (as I think) they have no relation with=
 the hypervisor. I'm not really confident that letting the user set it's ow=
n qemu/seabios=85 repository so easily is a good idea.

> I'm less sure there.
> =

> Ian.
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdYI-0006Eu-D6; Fri, 13 Apr 2012 10:16:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIdYH-0006Ep-3w
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:16:25 +0000
Received: from [85.158.138.51:9750] by server-4.bemta-3.messagelabs.com id
	DD/BF-15341-8FCF78F4; Fri, 13 Apr 2012 10:16:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334312181!20178325!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30860 invoked from network); 13 Apr 2012 10:16:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330923600"; d="scan'208";a="190199760"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 06:16:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 06:16:19 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIdYB-0003vN-2s;
	Fri, 13 Apr 2012 11:16:19 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:16:19 +0100
Message-ID: <772B7F0A-F672-4ACF-8DED-728E9978AC54@citrix.com>
References: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] autoconf: --enable-githttp doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 13/04/2012, a las 10:16, Ian Campbell escribi=F3:
> This is because the toplevel Config.mk does not include config/Tools.mk
> and therefore GIT_HTTP is not defined.

Yes, sorry, this is a leftover from when I though that the output from conf=
igure would be used by the top level Config.mk file.

> =

> I'm not sure what the best fix here is, we don't really want to include
> config/Tools.mk in the top-level Config.mk since that would mean you had
> to run configure to build the hypervisor, which we want to avoid.
> =

> Perhaps a bunch of the tools-level config stuff from Config.mk should go
> into config/Tools.mk.in? It looks like most of the content of Config.mk
> from the definition of QEMU_REMOTE onwards could/should be moved but
> I've not actually tried it.

Probably, I don't think any of this are used by the hypervisor.

> =

> Or perhaps some stuff should become actual configure options,
> CONFIG_{OVMF,ROMBIOS,SEABIOS} and ETHERBOOT_NICS seem like good
> candidates for that. Perhaps --qemu-upstream-url=3DURL etc make sense too?

I'm quite confident this:

CONFIG_OVMF ?=3D n
CONFIG_ROMBIOS ?=3D y
CONFIG_SEABIOS ?=3D y

should become configure options, if (as I think) they have no relation with=
 the hypervisor. I'm not really confident that letting the user set it's ow=
n qemu/seabios=85 repository so easily is a good idea.

> I'm less sure there.
> =

> Ian.
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdbW-0006LG-1C; Fri, 13 Apr 2012 10:19:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIdbU-0006L9-RI
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:19:44 +0000
Received: from [85.158.143.99:20895] by server-3.bemta-4.messagelabs.com id
	58/62-05853-0CDF78F4; Fri, 13 Apr 2012 10:19:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334312383!13726689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2699 invoked from network); 13 Apr 2012 10:19:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11921925"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:19:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 11:19:42 +0100
Message-ID: <1334312380.14560.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 13 Apr 2012 11:19:40 +0100
In-Reply-To: <772B7F0A-F672-4ACF-8DED-728E9978AC54@citrix.com>
References: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
	<772B7F0A-F672-4ACF-8DED-728E9978AC54@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] autoconf: --enable-githttp doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA0LTEzIGF0IDExOjE2ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSSdtIHF1aXRlIGNvbmZpZGVudCB0aGlzOgo+IAo+IENPTkZJR19PVk1GID89IG4KPiBDT05G
SUdfUk9NQklPUyA/PSB5Cj4gQ09ORklHX1NFQUJJT1MgPz0geQo+IAo+IHNob3VsZCBiZWNvbWUg
Y29uZmlndXJlIG9wdGlvbnMsIGlmIChhcyBJIHRoaW5rKSB0aGV5IGhhdmUgbm8gcmVsYXRpb24K
PiB3aXRoIHRoZSBoeXBlcnZpc29yLgoKSSdtIHByZXR0eSBzdXJlIHRoZXkgaGF2ZSBubyByZWxh
dGlvbiB3aXRoIHRoZSBoeXBlcnZpc29yLgoKPiBJJ20gbm90IHJlYWxseSBjb25maWRlbnQgdGhh
dCBsZXR0aW5nIHRoZSB1c2VyIHNldCBpdCdzIG93bgo+IHFlbXUvc2VhYmlvc+KApiByZXBvc2l0
b3J5IHNvIGVhc2lseSBpcyBhIGdvb2QgaWRlYS4KCkxldHMganVzdCBtb3ZlIHRob3NlIHRvIFRv
b2xzLm1rLmluIHRoZW4sIGlmIHRoZXJlJ3MgZGVtYW5kIGZvciBhbgpvcHRpb24gbGF0ZXIgd2Ug
Y2FuIGFsd2F5cyBkbyBpdCB0aGVuLgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdbW-0006LG-1C; Fri, 13 Apr 2012 10:19:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIdbU-0006L9-RI
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:19:44 +0000
Received: from [85.158.143.99:20895] by server-3.bemta-4.messagelabs.com id
	58/62-05853-0CDF78F4; Fri, 13 Apr 2012 10:19:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334312383!13726689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2699 invoked from network); 13 Apr 2012 10:19:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11921925"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:19:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 11:19:42 +0100
Message-ID: <1334312380.14560.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 13 Apr 2012 11:19:40 +0100
In-Reply-To: <772B7F0A-F672-4ACF-8DED-728E9978AC54@citrix.com>
References: <1334308607.14560.12.camel@zakaz.uk.xensource.com>
	<772B7F0A-F672-4ACF-8DED-728E9978AC54@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] autoconf: --enable-githttp doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA0LTEzIGF0IDExOjE2ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSSdtIHF1aXRlIGNvbmZpZGVudCB0aGlzOgo+IAo+IENPTkZJR19PVk1GID89IG4KPiBDT05G
SUdfUk9NQklPUyA/PSB5Cj4gQ09ORklHX1NFQUJJT1MgPz0geQo+IAo+IHNob3VsZCBiZWNvbWUg
Y29uZmlndXJlIG9wdGlvbnMsIGlmIChhcyBJIHRoaW5rKSB0aGV5IGhhdmUgbm8gcmVsYXRpb24K
PiB3aXRoIHRoZSBoeXBlcnZpc29yLgoKSSdtIHByZXR0eSBzdXJlIHRoZXkgaGF2ZSBubyByZWxh
dGlvbiB3aXRoIHRoZSBoeXBlcnZpc29yLgoKPiBJJ20gbm90IHJlYWxseSBjb25maWRlbnQgdGhh
dCBsZXR0aW5nIHRoZSB1c2VyIHNldCBpdCdzIG93bgo+IHFlbXUvc2VhYmlvc+KApiByZXBvc2l0
b3J5IHNvIGVhc2lseSBpcyBhIGdvb2QgaWRlYS4KCkxldHMganVzdCBtb3ZlIHRob3NlIHRvIFRv
b2xzLm1rLmluIHRoZW4sIGlmIHRoZXJlJ3MgZGVtYW5kIGZvciBhbgpvcHRpb24gbGF0ZXIgd2Ug
Y2FuIGFsd2F5cyBkbyBpdCB0aGVuLgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:30:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdl7-0006a8-6z; Fri, 13 Apr 2012 10:29:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIdl5-0006a3-Vj
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:29:40 +0000
Received: from [85.158.143.35:43466] by server-1.bemta-4.messagelabs.com id
	21/70-20925-310088F4; Fri, 13 Apr 2012 10:29:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334312978!11181488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14956 invoked from network); 13 Apr 2012 10:29:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11922186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:29:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:29:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIdl3-0006wt-TW; Fri, 13 Apr 2012 10:29:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIdl3-0003qf-Se;
	Fri, 13 Apr 2012 11:29:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.15.43342.127302@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:29:35 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1334267323.2417.3.camel@Abyss>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334267323.2417.3.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]"):
> On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote: 
> > This is not 4.3
> > material.
> 
> Just to be sure I get it, you think we need to have the
> creation-vs-ballooning potential race solved *before* 4.2 ?

No, I meant the opposite.  Half time I say 4.2 I mean 4.3 and vice
versa :-/.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:30:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdl7-0006a8-6z; Fri, 13 Apr 2012 10:29:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIdl5-0006a3-Vj
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:29:40 +0000
Received: from [85.158.143.35:43466] by server-1.bemta-4.messagelabs.com id
	21/70-20925-310088F4; Fri, 13 Apr 2012 10:29:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334312978!11181488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14956 invoked from network); 13 Apr 2012 10:29:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11922186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:29:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:29:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIdl3-0006wt-TW; Fri, 13 Apr 2012 10:29:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIdl3-0003qf-Se;
	Fri, 13 Apr 2012 11:29:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.15.43342.127302@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:29:35 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1334267323.2417.3.camel@Abyss>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334267323.2417.3.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]"):
> On Thu, 2012-04-12 at 12:10 +0100, Ian Jackson wrote: 
> > This is not 4.3
> > material.
> 
> Just to be sure I get it, you think we need to have the
> creation-vs-ballooning potential race solved *before* 4.2 ?

No, I meant the opposite.  Half time I say 4.2 I mean 4.3 and vice
versa :-/.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:37:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdsd-0006k7-3e; Fri, 13 Apr 2012 10:37:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1SIdsc-0006k2-2L
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:37:26 +0000
Received: from [85.158.139.83:44191] by server-6.bemta-5.messagelabs.com id
	41/AD-13222-5E1088F4; Fri, 13 Apr 2012 10:37:25 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334313443!12397581!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15922 invoked from network); 13 Apr 2012 10:37:24 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:37:24 -0000
Received: by yhoo21 with SMTP id o21so1804648yho.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 03:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=Zga6bh+Is+AL+7/5arUZe4TC202aqSDEY2Z6Y9YWJmo=;
	b=AqkrNkeMdGIDrMpTcGzLeaxSGSCpNshOzCT+/O2+zLAOrjTNfj2m1ljSd8RKrTLzPV
	zCEYvKbHfZqxVUU8TeAN+3yBpWJI1k2MOhsROzhZhLshaES5mlue2QkqCU7VNLYYkTfC
	gaf3ByxKA5B5bINvnNpYzis4EPEzoZjMstJuz8ez9WFMnpAclqCpdMeOBgu0BFdBb2cw
	U1kkxf/5Q16ztKQMZxhlhYzkBA5lJXLW2umBvN9nqZ3zvIryL5EWOl6lZL2LAXZDGMJx
	AIMlO5LcNcTrj6TFqrVPQ/5FnZnLvEod5vOeqsUEzilrwuoxKSc9ZekZZgSKxRbYIm22
	S3Hg==
Received: by 10.236.76.226 with SMTP id b62mr1130122yhe.13.1334313442876;
	Fri, 13 Apr 2012 03:37:22 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id e1sm34506446yhi.9.2012.04.13.03.37.18
	(version=SSLv3 cipher=OTHER); Fri, 13 Apr 2012 03:37:21 -0700 (PDT)
Message-ID: <4F8801DD.4030004@cantab.net>
Date: Fri, 13 Apr 2012 11:37:17 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
In-Reply-To: <4F87F84B020000780007DB52@nat28.tlf.novell.com>
Cc: Sheng Yang <sheng@yasker.org>, jeremy@goop.org, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 08:56, Jan Beulich wrote:
>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
>> timestamp jump issue as expected. Luckily, seems it also solved the call
>> trace and guest hang issue as well.
> 
> And this is also how it should be fixed.

Something like this?  I've not tested it yet as I need to track down
some of the problem hardware and get it set up.

8<---------------
xen: always set the sched clock as unstable

It's not clear to me if the Xen clock source can be used as a stable
sched clock. Also, even if the guest is started on a system whose
underying TSC is stable it may be migrated to one where it's not. So
never mark the sched clock as stable.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/time.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 0296a95..b22cd9c 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -473,6 +473,9 @@ static void __init xen_time_init(void)
 	do_settimeofday(&tp);

 	setup_force_cpu_cap(X86_FEATURE_TSC);
+	setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
+	setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
+	sched_clock_stable = 0;

 	xen_setup_runstate_info(cpu);
 	xen_setup_timer(cpu);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:37:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIdsd-0006k7-3e; Fri, 13 Apr 2012 10:37:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1SIdsc-0006k2-2L
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:37:26 +0000
Received: from [85.158.139.83:44191] by server-6.bemta-5.messagelabs.com id
	41/AD-13222-5E1088F4; Fri, 13 Apr 2012 10:37:25 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334313443!12397581!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15922 invoked from network); 13 Apr 2012 10:37:24 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:37:24 -0000
Received: by yhoo21 with SMTP id o21so1804648yho.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 03:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=Zga6bh+Is+AL+7/5arUZe4TC202aqSDEY2Z6Y9YWJmo=;
	b=AqkrNkeMdGIDrMpTcGzLeaxSGSCpNshOzCT+/O2+zLAOrjTNfj2m1ljSd8RKrTLzPV
	zCEYvKbHfZqxVUU8TeAN+3yBpWJI1k2MOhsROzhZhLshaES5mlue2QkqCU7VNLYYkTfC
	gaf3ByxKA5B5bINvnNpYzis4EPEzoZjMstJuz8ez9WFMnpAclqCpdMeOBgu0BFdBb2cw
	U1kkxf/5Q16ztKQMZxhlhYzkBA5lJXLW2umBvN9nqZ3zvIryL5EWOl6lZL2LAXZDGMJx
	AIMlO5LcNcTrj6TFqrVPQ/5FnZnLvEod5vOeqsUEzilrwuoxKSc9ZekZZgSKxRbYIm22
	S3Hg==
Received: by 10.236.76.226 with SMTP id b62mr1130122yhe.13.1334313442876;
	Fri, 13 Apr 2012 03:37:22 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id e1sm34506446yhi.9.2012.04.13.03.37.18
	(version=SSLv3 cipher=OTHER); Fri, 13 Apr 2012 03:37:21 -0700 (PDT)
Message-ID: <4F8801DD.4030004@cantab.net>
Date: Fri, 13 Apr 2012 11:37:17 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
In-Reply-To: <4F87F84B020000780007DB52@nat28.tlf.novell.com>
Cc: Sheng Yang <sheng@yasker.org>, jeremy@goop.org, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 08:56, Jan Beulich wrote:
>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
>> timestamp jump issue as expected. Luckily, seems it also solved the call
>> trace and guest hang issue as well.
> 
> And this is also how it should be fixed.

Something like this?  I've not tested it yet as I need to track down
some of the problem hardware and get it set up.

8<---------------
xen: always set the sched clock as unstable

It's not clear to me if the Xen clock source can be used as a stable
sched clock. Also, even if the guest is started on a system whose
underying TSC is stable it may be migrated to one where it's not. So
never mark the sched clock as stable.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/time.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 0296a95..b22cd9c 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -473,6 +473,9 @@ static void __init xen_time_init(void)
 	do_settimeofday(&tp);

 	setup_force_cpu_cap(X86_FEATURE_TSC);
+	setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
+	setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
+	sched_clock_stable = 0;

 	xen_setup_runstate_info(cpu);
 	xen_setup_timer(cpu);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:40:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIduh-0006pX-LH; Fri, 13 Apr 2012 10:39:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIdug-0006pF-Jb
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 10:39:34 +0000
Received: from [85.158.138.51:49059] by server-10.bemta-3.messagelabs.com id
	6A/0C-29478-562088F4; Fri, 13 Apr 2012 10:39:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334313573!20182006!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31902 invoked from network); 13 Apr 2012 10:39:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:39:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11922420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:39:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:39:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIdue-00071y-NB; Fri, 13 Apr 2012 10:39:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIdue-0003rN-M9;
	Fri, 13 Apr 2012 11:39:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.612.655445.406660@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:39:32 +0100
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
In-Reply-To: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
References: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xuesen Guo writes ("[PATCH] readnote: Add bzImage kernel support"):
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels

Thanks for this.  Technically we are in feature freeze but we should
probably make an exception for this.

However, this code will need a thorough line-by-line review as it
is privileged code dealing with potentially hostile kernels, and this
kind of data format unpicking has in the past been the source of bugs
including security vulnerabilities.

So please bear with us while we find time to do that review.

I emphasise that it's no reflection on you or the quality of your
code: any submission which solved this same problem ought to be
carefully scrutinised.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:40:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIduh-0006pX-LH; Fri, 13 Apr 2012 10:39:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIdug-0006pF-Jb
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 10:39:34 +0000
Received: from [85.158.138.51:49059] by server-10.bemta-3.messagelabs.com id
	6A/0C-29478-562088F4; Fri, 13 Apr 2012 10:39:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334313573!20182006!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31902 invoked from network); 13 Apr 2012 10:39:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:39:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11922420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:39:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:39:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIdue-00071y-NB; Fri, 13 Apr 2012 10:39:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIdue-0003rN-M9;
	Fri, 13 Apr 2012 11:39:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.612.655445.406660@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:39:32 +0100
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
In-Reply-To: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
References: <e640d59ff132c7bccea9.1334194706@localhost6.localdomain6>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xuesen Guo writes ("[PATCH] readnote: Add bzImage kernel support"):
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels

Thanks for this.  Technically we are in feature freeze but we should
probably make an exception for this.

However, this code will need a thorough line-by-line review as it
is privileged code dealing with potentially hostile kernels, and this
kind of data format unpicking has in the past been the source of bugs
including security vulnerabilities.

So please bear with us while we find time to do that review.

I emphasise that it's no reflection on you or the quality of your
code: any submission which solved this same problem ought to be
carefully scrutinised.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIe0L-000790-EN; Fri, 13 Apr 2012 10:45:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIe0J-00078u-S1
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:45:24 +0000
Received: from [85.158.138.51:39495] by server-7.bemta-3.messagelabs.com id
	81/5D-03078-2C3088F4; Fri, 13 Apr 2012 10:45:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334313922!21864127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22832 invoked from network); 13 Apr 2012 10:45:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11922549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:45:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:45:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIe0H-000744-FM; Fri, 13 Apr 2012 10:45:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIe0H-0003rv-EL;
	Fri, 13 Apr 2012 11:45:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.961.392060.587905@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:45:21 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan Magenheimer writes ("RE: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> After reading libxl.h, I'm not absolutely positive I understand
> all the conditions that would cause you to label a function as
> "slow" but I believe all the libxl_tmem_* functions are "fast".

Thanks for your reply.

There are a few operations that make a function necessarily have to be
slow in the libxl api sense.  These are: xenstore watches; spawning
subprocesses; anything with a timeout.

More broadly any function which is sufficiently slow that a caller
might reasonably want to initiate it, and then carry on doing
something else while the function completes.  So this includes any
operation which a toolstack might want to parallelise.

> All of them are strictly "call the hypervisor, wait for it to
> return" and none of the hypercalls (actually which are variations of
> the one tmem hypercall) require a callback to dom0 or to the
> calling guest... they all complete entirely inside the hypervisor.

Right, that sounds good.  I guess you also mean that this will always
be the case.

> Libxl_tmem_destroy may take a long time as it has to walk
> through and free some potentially very large data structures,
> but it is only used at domain destruction.

How long a time are we talking about ?  Would it be a scalability or
performance problem if an entire host's management toolstack had to
block, and no other management operations could be performed on any
domain for any reason, while the tmem destroy takes place ?

> Libxl_tmem_list does allocate some memory in userland that the
> hypercall fills synchronously (with ascii-formatted statistics/counters
> maintained entirely by the tmem code in the hypervisor).

Memory allocation in userland is fine.  I guess we're not talking
about megabytes here.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIe0L-000790-EN; Fri, 13 Apr 2012 10:45:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIe0J-00078u-S1
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 10:45:24 +0000
Received: from [85.158.138.51:39495] by server-7.bemta-3.messagelabs.com id
	81/5D-03078-2C3088F4; Fri, 13 Apr 2012 10:45:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334313922!21864127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22832 invoked from network); 13 Apr 2012 10:45:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,416,1330905600"; d="scan'208";a="11922549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:45:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:45:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIe0H-000744-FM; Fri, 13 Apr 2012 10:45:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIe0H-0003rv-EL;
	Fri, 13 Apr 2012 11:45:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.961.392060.587905@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 11:45:21 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan Magenheimer writes ("RE: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> After reading libxl.h, I'm not absolutely positive I understand
> all the conditions that would cause you to label a function as
> "slow" but I believe all the libxl_tmem_* functions are "fast".

Thanks for your reply.

There are a few operations that make a function necessarily have to be
slow in the libxl api sense.  These are: xenstore watches; spawning
subprocesses; anything with a timeout.

More broadly any function which is sufficiently slow that a caller
might reasonably want to initiate it, and then carry on doing
something else while the function completes.  So this includes any
operation which a toolstack might want to parallelise.

> All of them are strictly "call the hypervisor, wait for it to
> return" and none of the hypercalls (actually which are variations of
> the one tmem hypercall) require a callback to dom0 or to the
> calling guest... they all complete entirely inside the hypervisor.

Right, that sounds good.  I guess you also mean that this will always
be the case.

> Libxl_tmem_destroy may take a long time as it has to walk
> through and free some potentially very large data structures,
> but it is only used at domain destruction.

How long a time are we talking about ?  Would it be a scalability or
performance problem if an entire host's management toolstack had to
block, and no other management operations could be performed on any
domain for any reason, while the tmem destroy takes place ?

> Libxl_tmem_list does allocate some memory in userland that the
> hypercall fills synchronously (with ascii-formatted statistics/counters
> maintained entirely by the tmem code in the hypervisor).

Memory allocation in userland is fine.  I guess we're not talking
about megabytes here.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:58:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:58:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIeCR-0007Ih-LT; Fri, 13 Apr 2012 10:57:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIeCP-0007Ic-Nk
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 10:57:54 +0000
Received: from [85.158.138.51:33570] by server-4.bemta-3.messagelabs.com id
	04/97-15341-0B6088F4; Fri, 13 Apr 2012 10:57:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334314671!20185415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21789 invoked from network); 13 Apr 2012 10:57:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11923034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:57:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:57:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIeCN-0007EV-6C;
	Fri, 13 Apr 2012 10:57:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIeCK-0001ew-1c;
	Fri, 13 Apr 2012 11:57:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12670-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 11:57:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12670: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12670 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12670/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=4ad262a48a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 4ad262a48a71
+ branch=xen-4.1-testing
+ revision=4ad262a48a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 4ad262a48a71 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 23 changes to 19 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 10:58:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 10:58:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIeCR-0007Ih-LT; Fri, 13 Apr 2012 10:57:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIeCP-0007Ic-Nk
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 10:57:54 +0000
Received: from [85.158.138.51:33570] by server-4.bemta-3.messagelabs.com id
	04/97-15341-0B6088F4; Fri, 13 Apr 2012 10:57:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334314671!20185415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21789 invoked from network); 13 Apr 2012 10:57:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 10:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11923034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 10:57:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 11:57:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIeCN-0007EV-6C;
	Fri, 13 Apr 2012 10:57:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIeCK-0001ew-1c;
	Fri, 13 Apr 2012 11:57:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12670-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 11:57:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12670: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12670 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12670/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12578

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  4ad262a48a71
baseline version:
 xen                  6f224431eca2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=4ad262a48a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 4ad262a48a71
+ branch=xen-4.1-testing
+ revision=4ad262a48a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 4ad262a48a71 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 23 changes to 19 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:01:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIeFJ-0007Xg-Pv; Fri, 13 Apr 2012 11:00:53 +0000
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 1SIeFI-0007XT-KC
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 11:00:52 +0000
Received: from [193.109.254.147:35924] by server-12.bemta-14.messagelabs.com
	id D2/6D-05898-467088F4; Fri, 13 Apr 2012 11:00:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334314849!4470688!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1309 invoked from network); 13 Apr 2012 11:00:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 11:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 12:00:49 +0100
Message-Id: <4F882381020000780007DC4C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 12:00:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <dvrabel@cantab.net>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
	<4F8801DD.4030004@cantab.net>
In-Reply-To: <4F8801DD.4030004@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sheng Yang <sheng@yasker.org>, jeremy@goop.org, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 12:37, David Vrabel <dvrabel@cantab.net> wrote:
> On 13/04/12 08:56, Jan Beulich wrote:
>>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
>>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
>>> timestamp jump issue as expected. Luckily, seems it also solved the call
>>> trace and guest hang issue as well.
>> 
>> And this is also how it should be fixed.
> 
> Something like this?  I've not tested it yet as I need to track down
> some of the problem hardware and get it set up.

Yeah, except that I'm not sure you really need to clear the feature
flags. Just making sure sched_clock_stable never gets set should be
enough; playing with the feature flags always implies that users will
see bigger differences in /proc/cpuinfo between native and Xen
kernels...

Jjan

> 8<---------------
> xen: always set the sched clock as unstable
> 
> It's not clear to me if the Xen clock source can be used as a stable
> sched clock. Also, even if the guest is started on a system whose
> underying TSC is stable it may be migrated to one where it's not. So
> never mark the sched clock as stable.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..b22cd9c 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,9 @@ static void __init xen_time_init(void)
>  	do_settimeofday(&tp);
> 
>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> +	setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
> +	setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
> +	sched_clock_stable = 0;
> 
>  	xen_setup_runstate_info(cpu);
>  	xen_setup_timer(cpu);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:01:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIeFJ-0007Xg-Pv; Fri, 13 Apr 2012 11:00:53 +0000
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 1SIeFI-0007XT-KC
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 11:00:52 +0000
Received: from [193.109.254.147:35924] by server-12.bemta-14.messagelabs.com
	id D2/6D-05898-467088F4; Fri, 13 Apr 2012 11:00:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334314849!4470688!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1309 invoked from network); 13 Apr 2012 11:00:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 11:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 12:00:49 +0100
Message-Id: <4F882381020000780007DC4C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 12:00:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <dvrabel@cantab.net>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
	<4F8801DD.4030004@cantab.net>
In-Reply-To: <4F8801DD.4030004@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sheng Yang <sheng@yasker.org>, jeremy@goop.org, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 12:37, David Vrabel <dvrabel@cantab.net> wrote:
> On 13/04/12 08:56, Jan Beulich wrote:
>>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
>>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
>>> timestamp jump issue as expected. Luckily, seems it also solved the call
>>> trace and guest hang issue as well.
>> 
>> And this is also how it should be fixed.
> 
> Something like this?  I've not tested it yet as I need to track down
> some of the problem hardware and get it set up.

Yeah, except that I'm not sure you really need to clear the feature
flags. Just making sure sched_clock_stable never gets set should be
enough; playing with the feature flags always implies that users will
see bigger differences in /proc/cpuinfo between native and Xen
kernels...

Jjan

> 8<---------------
> xen: always set the sched clock as unstable
> 
> It's not clear to me if the Xen clock source can be used as a stable
> sched clock. Also, even if the guest is started on a system whose
> underying TSC is stable it may be migrated to one where it's not. So
> never mark the sched clock as stable.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..b22cd9c 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,9 @@ static void __init xen_time_init(void)
>  	do_settimeofday(&tp);
> 
>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> +	setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
> +	setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
> +	sched_clock_stable = 0;
> 
>  	xen_setup_runstate_info(cpu);
>  	xen_setup_timer(cpu);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:04:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIeIl-0007jn-E0; Fri, 13 Apr 2012 11:04:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIeIj-0007jg-GW
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 11:04:25 +0000
Received: from [193.109.254.147:57438] by server-2.bemta-14.messagelabs.com id
	17/DE-19409-838088F4; Fri, 13 Apr 2012 11:04:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334315057!4397429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13634 invoked from network); 13 Apr 2012 11:04:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:04:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11923302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 11:04:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 12:04:17 +0100
Date: Fri, 13 Apr 2012 12:08:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204131207250.15151@kaball-desktop>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 12 Apr 2012, Ian Campbell wrote:
> The time has come for another round of stable releases.
> 
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
> 
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.

For 4.1.x:

289eb8848224efb649dc42a9bb3c086553cc2922 qemu-xen-traditional: QDISK fixes
f8d95ca183c7d6072c2871588bde1fef7c601e22 qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
bbe85879171f78463f777c1e47273de24d8a64ce qemu-xen-traditional: use O_DIRECT to open disk images for IDE

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:04:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIeIl-0007jn-E0; Fri, 13 Apr 2012 11:04:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIeIj-0007jg-GW
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 11:04:25 +0000
Received: from [193.109.254.147:57438] by server-2.bemta-14.messagelabs.com id
	17/DE-19409-838088F4; Fri, 13 Apr 2012 11:04:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334315057!4397429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13634 invoked from network); 13 Apr 2012 11:04:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:04:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11923302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 11:04:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 12:04:17 +0100
Date: Fri, 13 Apr 2012 12:08:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204131207250.15151@kaball-desktop>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 12 Apr 2012, Ian Campbell wrote:
> The time has come for another round of stable releases.
> 
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
> 
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.

For 4.1.x:

289eb8848224efb649dc42a9bb3c086553cc2922 qemu-xen-traditional: QDISK fixes
f8d95ca183c7d6072c2871588bde1fef7c601e22 qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
bbe85879171f78463f777c1e47273de24d8a64ce qemu-xen-traditional: use O_DIRECT to open disk images for IDE

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIenn-00087I-1s; Fri, 13 Apr 2012 11:36:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIenl-00087D-UB
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:36:30 +0000
Received: from [85.158.143.35:21980] by server-2.bemta-4.messagelabs.com id
	C9/19-17550-DBF088F4; Fri, 13 Apr 2012 11:36:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334316988!11193807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25086 invoked from network); 13 Apr 2012 11:36:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:36:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11924464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 11:36:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 12:36:28 +0100
Date: Fri, 13 Apr 2012 12:40:25 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

The QEMU side of this patch series has been accepted, so it is now safe
to commit it to xen-unstable.


Changes in v8:
- return an error on restore if toolstack data is available but no
toolstack callback has been provided.


Changes in v7:
- log error messages on error paths;

- make the toolstack save/restore functions more readable.


Changes in v6:

- rebased on "kexec: Fix printing of paddr_t in 32bit mode.";

- use the command "xen-save-devices-state" to save the QEMU devices
state.



Changes in v5:

- rebased on "arm: lr register in hyp mode is really LR_usr.".



Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_domain_restore.c |   53 ++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++
 tools/libxc/xenguest.h          |   23 +++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  174 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +------------------
 tools/xcutils/xc_restore.c      |    2 +-
 8 files changed, 260 insertions(+), 94 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIenn-00087I-1s; Fri, 13 Apr 2012 11:36:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIenl-00087D-UB
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:36:30 +0000
Received: from [85.158.143.35:21980] by server-2.bemta-4.messagelabs.com id
	C9/19-17550-DBF088F4; Fri, 13 Apr 2012 11:36:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334316988!11193807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25086 invoked from network); 13 Apr 2012 11:36:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:36:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11924464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 11:36:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 12:36:28 +0100
Date: Fri, 13 Apr 2012 12:40:25 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

The QEMU side of this patch series has been accepted, so it is now safe
to commit it to xen-unstable.


Changes in v8:
- return an error on restore if toolstack data is available but no
toolstack callback has been provided.


Changes in v7:
- log error messages on error paths;

- make the toolstack save/restore functions more readable.


Changes in v6:

- rebased on "kexec: Fix printing of paddr_t in 32bit mode.";

- use the command "xen-save-devices-state" to save the QEMU devices
state.



Changes in v5:

- rebased on "arm: lr register in hyp mode is really LR_usr.".



Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_domain_restore.c |   53 ++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++
 tools/libxc/xenguest.h          |   23 +++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  174 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +------------------
 tools/xcutils/xc_restore.c      |    2 +-
 8 files changed, 260 insertions(+), 94 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIepK-0008B9-HK; Fri, 13 Apr 2012 11:38:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIepI-0008B3-Vi
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:38:05 +0000
Received: from [85.158.138.51:25587] by server-2.bemta-3.messagelabs.com id
	B4/72-09269-C10188F4; Fri, 13 Apr 2012 11:38:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334317081!21828740!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24275 invoked from network); 13 Apr 2012 11:38:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190208143"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:37:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 07:37:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIep7-0005IS-GI; Fri, 13 Apr 2012 12:37:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 12:42:03 +0100
Message-ID: <1334317324-18422-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  163 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 162 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7f140b4..1eb328b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -394,6 +394,79 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
+        uint64_t phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    libxl_ctx *ctx = gc->owner;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+    char *xs_path;
+
+    if (size < sizeof(version) + sizeof(count)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong version");
+        return -1;
+    }
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info))) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "start_addr");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "size");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            xs_path = restore_helper(gc, domid, pi->phys_offset, "name");
+            ret = libxl__xs_write(gc, 0, xs_path, "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -403,6 +476,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -410,6 +484,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -425,7 +501,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -580,6 +656,90 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+        char *phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%s/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    libxl_ctx *ctx = gc->owner;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        char *xs_path;
+        phys_offset = entries[i];
+        if (phys_offset == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        start_addr = libxl__xs_read(gc, 0, xs_path);
+        if (start_addr == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "size");
+        size = libxl__xs_read(gc, 0, xs_path);
+        if (size == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "name");
+        name = libxl__xs_read(gc, 0, xs_path);
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -642,6 +802,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIepK-0008B9-HK; Fri, 13 Apr 2012 11:38:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIepI-0008B3-Vi
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:38:05 +0000
Received: from [85.158.138.51:25587] by server-2.bemta-3.messagelabs.com id
	B4/72-09269-C10188F4; Fri, 13 Apr 2012 11:38:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334317081!21828740!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24275 invoked from network); 13 Apr 2012 11:38:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190208143"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:37:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 07:37:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIep7-0005IS-GI; Fri, 13 Apr 2012 12:37:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 12:42:03 +0100
Message-ID: <1334317324-18422-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  163 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 162 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7f140b4..1eb328b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -394,6 +394,79 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
+        uint64_t phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    libxl_ctx *ctx = gc->owner;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+    char *xs_path;
+
+    if (size < sizeof(version) + sizeof(count)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong version");
+        return -1;
+    }
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info))) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        return -1;
+    }
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "start_addr");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        xs_path = restore_helper(gc, domid, pi->phys_offset, "size");
+        ret = libxl__xs_write(gc, 0, xs_path, "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            xs_path = restore_helper(gc, domid, pi->phys_offset, "name");
+            ret = libxl__xs_write(gc, 0, xs_path, "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -403,6 +476,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -410,6 +484,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -425,7 +501,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -580,6 +656,90 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+        char *phys_offset, char *node)
+{
+    return libxl__sprintf(gc,
+            "/local/domain/0/device-model/%d/physmap/%s/%s",
+            domid, phys_offset, node);
+}
+
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    libxl_ctx *ctx = gc->owner;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        char *xs_path;
+        phys_offset = entries[i];
+        if (phys_offset == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        start_addr = libxl__xs_read(gc, 0, xs_path);
+        if (start_addr == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "size");
+        size = libxl__xs_read(gc, 0, xs_path);
+        if (size == NULL) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            return -1;
+        }
+
+        xs_path = save_helper(gc, domid, phys_offset, "name");
+        name = libxl__xs_read(gc, 0, xs_path);
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -642,6 +802,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIepR-0008C7-EY; Fri, 13 Apr 2012 11:38:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIepQ-0008Bd-4L
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:38:12 +0000
Received: from [85.158.138.51:33311] by server-6.bemta-3.messagelabs.com id
	3A/58-05145-320188F4; Fri, 13 Apr 2012 11:38:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334317081!21828740!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24666 invoked from network); 13 Apr 2012 11:38:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:38:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190208146"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:37:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 07:37:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIep7-0005IS-Ff; Fri, 13 Apr 2012 12:37:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 12:42:02 +0100
Message-ID: <1334317324-18422-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   53 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3e4d518..6227d43 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -685,6 +690,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -695,6 +702,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -863,6 +874,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1299,7 +1323,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1347,6 +1372,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1359,6 +1385,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1624,6 +1651,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2074,6 +2105,26 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( tdata.data != NULL )
+    {
+        if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+        {
+            rc = callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                        callbacks->data);
+            free(tdata.data);
+            if ( rc < 0 )
+            {
+                PERROR("error calling toolstack_restore");
+                goto out;
+            }
+        } else {
+            rc = -1;
+            ERROR("toolstack data available but no callback provided\n");
+            free(tdata.data);
+            goto out;
+        }
+    }
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a9216dd..fcc7718 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1723,6 +1723,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 8d885d3..6435f65 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -83,7 +103,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 89f3504..04e7892 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -258,6 +258,7 @@
 #define XC_SAVE_ID_HVM_PAGING_RING_PFN  -15
 #define XC_SAVE_ID_HVM_ACCESS_RING_PFN  -16
 #define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
+#define XC_SAVE_ID_TOOLSTACK          -18 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..7f140b4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -425,7 +425,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index e41a133..0235579 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
                             console_evtchn, &console_mfn, 0, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIepR-0008C7-EY; Fri, 13 Apr 2012 11:38:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIepQ-0008Bd-4L
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:38:12 +0000
Received: from [85.158.138.51:33311] by server-6.bemta-3.messagelabs.com id
	3A/58-05145-320188F4; Fri, 13 Apr 2012 11:38:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334317081!21828740!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24666 invoked from network); 13 Apr 2012 11:38:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:38:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190208146"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:37:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 07:37:58 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIep7-0005IS-Ff; Fri, 13 Apr 2012 12:37:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 12:42:02 +0100
Message-ID: <1334317324-18422-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   53 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3e4d518..6227d43 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -685,6 +690,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -695,6 +702,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -863,6 +874,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1299,7 +1323,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1347,6 +1372,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1359,6 +1385,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1624,6 +1651,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2074,6 +2105,26 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( tdata.data != NULL )
+    {
+        if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+        {
+            rc = callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                        callbacks->data);
+            free(tdata.data);
+            if ( rc < 0 )
+            {
+                PERROR("error calling toolstack_restore");
+                goto out;
+            }
+        } else {
+            rc = -1;
+            ERROR("toolstack data available but no callback provided\n");
+            free(tdata.data);
+            goto out;
+        }
+    }
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a9216dd..fcc7718 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1723,6 +1723,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 8d885d3..6435f65 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -83,7 +103,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 89f3504..04e7892 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -258,6 +258,7 @@
 #define XC_SAVE_ID_HVM_PAGING_RING_PFN  -15
 #define XC_SAVE_ID_HVM_ACCESS_RING_PFN  -16
 #define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
+#define XC_SAVE_ID_TOOLSTACK          -18 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..7f140b4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -425,7 +425,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index e41a133..0235579 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
                             console_evtchn, &console_mfn, 0, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIepP-0008Be-TI; Fri, 13 Apr 2012 11:38:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIepO-0008BN-3e
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:38:10 +0000
Received: from [85.158.138.51:33122] by server-1.bemta-3.messagelabs.com id
	E9/D5-11491-120188F4; Fri, 13 Apr 2012 11:38:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334317081!21828740!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24589 invoked from network); 13 Apr 2012 11:38:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:38:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190208144"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:37:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 07:37:59 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIep7-0005IS-Gq; Fri, 13 Apr 2012 12:37:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 12:42:04 +0100
Message-ID: <1334317324-18422-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "xen-save-devices-state" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "xen-save-devices-state".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1eb328b..b209262 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -845,18 +845,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b5cce17 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1028,7 +1028,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..9a6ecb6 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -538,52 +538,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -817,34 +771,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -854,23 +782,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIepP-0008Be-TI; Fri, 13 Apr 2012 11:38:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIepO-0008BN-3e
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 11:38:10 +0000
Received: from [85.158.138.51:33122] by server-1.bemta-3.messagelabs.com id
	E9/D5-11491-120188F4; Fri, 13 Apr 2012 11:38:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334317081!21828740!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24589 invoked from network); 13 Apr 2012 11:38:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 11:38:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190208144"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 07:37:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 07:37:59 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIep7-0005IS-Gq; Fri, 13 Apr 2012 12:37:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 12:42:04 +0100
Message-ID: <1334317324-18422-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v8 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "xen-save-devices-state" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "xen-save-devices-state".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1eb328b..b209262 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -845,18 +845,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..b5cce17 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1028,7 +1028,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..9a6ecb6 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -538,52 +538,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -817,34 +771,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -854,23 +782,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:48:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIezF-0000Od-IC; Fri, 13 Apr 2012 11:48:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIezE-0000OY-1y
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 11:48:20 +0000
Received: from [85.158.143.99:60358] by server-2.bemta-4.messagelabs.com id
	0F/EA-17550-382188F4; Fri, 13 Apr 2012 11:48:19 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334317698!23528365!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAzMTUz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6546 invoked from network); 13 Apr 2012 11:48:18 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 11:48:18 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIezC-0006r1-D8
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:48:18 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Fri, 13 Apr 2012
	12:47:56 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 12:47:56 +0100
Thread-Topic: help finding privcmd hypercall handler
Thread-Index: AQHNGWtEykg/ImgQHka7U4GN70YgxA==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Subject: [Xen-devel] help finding privcmd hypercall handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everyone,

I am having some trouble finding the hypercall responsible 
for handling calls to privcmd operations by a user-level applcation.
Can anyone give me a pointer?

Right now, I know the user-level applications communicate 
with the hypervisor through the privcmd driver that is already 
part of the kernel source. From there they use the hypercall 
page table to trap to the hypervisor, is this correct?

Thank you for your time. cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 11:48:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 11:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIezF-0000Od-IC; Fri, 13 Apr 2012 11:48:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIezE-0000OY-1y
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 11:48:20 +0000
Received: from [85.158.143.99:60358] by server-2.bemta-4.messagelabs.com id
	0F/EA-17550-382188F4; Fri, 13 Apr 2012 11:48:19 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334317698!23528365!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAzMTUz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6546 invoked from network); 13 Apr 2012 11:48:18 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 11:48:18 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIezC-0006r1-D8
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:48:18 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Fri, 13 Apr 2012
	12:47:56 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 12:47:56 +0100
Thread-Topic: help finding privcmd hypercall handler
Thread-Index: AQHNGWtEykg/ImgQHka7U4GN70YgxA==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Subject: [Xen-devel] help finding privcmd hypercall handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everyone,

I am having some trouble finding the hypercall responsible 
for handling calls to privcmd operations by a user-level applcation.
Can anyone give me a pointer?

Right now, I know the user-level applications communicate 
with the hypervisor through the privcmd driver that is already 
part of the kernel source. From there they use the hypercall 
page table to trap to the hypervisor, is this correct?

Thank you for your time. cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:09:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIfIt-0000jp-59; Fri, 13 Apr 2012 12:08:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIfIs-0000jk-2Q
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 12:08:38 +0000
Received: from [85.158.143.99:4368] by server-3.bemta-4.messagelabs.com id
	E2/6D-05853-547188F4; Fri, 13 Apr 2012 12:08:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334318916!20134762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17569 invoked from network); 13 Apr 2012 12:08:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 12:08:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11925560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 12:08:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 13:08:36 +0100
Received: from spare.cam.xci-test.com ([10.80.2.76]
	helo=qabil.uk.xensource.com)	by norwich.cam.xci-test.com with esmtp
	(Exim
	4.72)	(envelope-from <david.vrabel@citrix.com>)	id 1SIfIq-0007qR-2A;
	Fri, 13 Apr 2012 12:08:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Apr 2012 13:08:35 +0100
Message-ID: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
	configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

The accessing PCI configuration space with the PCI BIOS service does
not work in PV guests.

This fixes boot on systems without MMCONFIG or where the BIOS hasn't
marked the MMCONFIG region as reserved in the e820 map.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: stable@kernel.org
---
 arch/x86/xen/enlighten.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b132ade..dbb5bb7 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -63,6 +63,7 @@
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
 #include <asm/mwait.h>
+#include <asm/pci_x86.h>
 
 #ifdef CONFIG_ACPI
 #include <linux/acpi.h>
@@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
 		/* Make sure ACS will be enabled */
 		pci_request_acs();
 	}
-		
+
+	/* PCI BIOS service won't work from a PV guest. */
+	pci_probe &= ~PCI_PROBE_BIOS;
 
 	xen_raw_console_write("about to get started...\n");
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:09:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIfIt-0000jp-59; Fri, 13 Apr 2012 12:08:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIfIs-0000jk-2Q
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 12:08:38 +0000
Received: from [85.158.143.99:4368] by server-3.bemta-4.messagelabs.com id
	E2/6D-05853-547188F4; Fri, 13 Apr 2012 12:08:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334318916!20134762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17569 invoked from network); 13 Apr 2012 12:08:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 12:08:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11925560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 12:08:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 13:08:36 +0100
Received: from spare.cam.xci-test.com ([10.80.2.76]
	helo=qabil.uk.xensource.com)	by norwich.cam.xci-test.com with esmtp
	(Exim
	4.72)	(envelope-from <david.vrabel@citrix.com>)	id 1SIfIq-0007qR-2A;
	Fri, 13 Apr 2012 12:08:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Apr 2012 13:08:35 +0100
Message-ID: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
	configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

The accessing PCI configuration space with the PCI BIOS service does
not work in PV guests.

This fixes boot on systems without MMCONFIG or where the BIOS hasn't
marked the MMCONFIG region as reserved in the e820 map.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: stable@kernel.org
---
 arch/x86/xen/enlighten.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b132ade..dbb5bb7 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -63,6 +63,7 @@
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
 #include <asm/mwait.h>
+#include <asm/pci_x86.h>
 
 #ifdef CONFIG_ACPI
 #include <linux/acpi.h>
@@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
 		/* Make sure ACS will be enabled */
 		pci_request_acs();
 	}
-		
+
+	/* PCI BIOS service won't work from a PV guest. */
+	pci_probe &= ~PCI_PROBE_BIOS;
 
 	xen_raw_console_write("about to get started...\n");
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIfd7-00014O-2p; Fri, 13 Apr 2012 12:29:33 +0000
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 1SIfd5-00014J-Tl
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:29:32 +0000
Received: from [193.109.254.147:42597] by server-2.bemta-14.messagelabs.com id
	96/16-19409-B2C188F4; Fri, 13 Apr 2012 12:29:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334320170!4471403!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11124 invoked from network); 13 Apr 2012 12:29:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 12:29:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 13:29:29 +0100
Message-Id: <4F883848020000780007DCD2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 13:29:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> The accessing PCI configuration space with the PCI BIOS service does
> not work in PV guests.
> 
> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
> marked the MMCONFIG region as reserved in the e820 map.

... and where "direct" access doesn't work either? Are there really
machines where Xen works on but this doesn't work? (Or, in case
this is disabled in your config, is it really useful to have
CONFIG_PCI_DIRECT disabled?)

That's just a comment on the description, the patch itself is fine
nevertheless (but should probably be sent to the x86 and/or PCI
maintainers).

Jan

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> Cc: stable@kernel.org 
> ---
>  arch/x86/xen/enlighten.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index b132ade..dbb5bb7 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -63,6 +63,7 @@
>  #include <asm/stackprotector.h>
>  #include <asm/hypervisor.h>
>  #include <asm/mwait.h>
> +#include <asm/pci_x86.h>
>  
>  #ifdef CONFIG_ACPI
>  #include <linux/acpi.h>
> @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
>  		/* Make sure ACS will be enabled */
>  		pci_request_acs();
>  	}
> -		
> +
> +	/* PCI BIOS service won't work from a PV guest. */
> +	pci_probe &= ~PCI_PROBE_BIOS;
>  
>  	xen_raw_console_write("about to get started...\n");
>  
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIfd7-00014O-2p; Fri, 13 Apr 2012 12:29:33 +0000
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 1SIfd5-00014J-Tl
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:29:32 +0000
Received: from [193.109.254.147:42597] by server-2.bemta-14.messagelabs.com id
	96/16-19409-B2C188F4; Fri, 13 Apr 2012 12:29:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334320170!4471403!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11124 invoked from network); 13 Apr 2012 12:29:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 12:29:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 13:29:29 +0100
Message-Id: <4F883848020000780007DCD2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 13:29:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> The accessing PCI configuration space with the PCI BIOS service does
> not work in PV guests.
> 
> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
> marked the MMCONFIG region as reserved in the e820 map.

... and where "direct" access doesn't work either? Are there really
machines where Xen works on but this doesn't work? (Or, in case
this is disabled in your config, is it really useful to have
CONFIG_PCI_DIRECT disabled?)

That's just a comment on the description, the patch itself is fine
nevertheless (but should probably be sent to the x86 and/or PCI
maintainers).

Jan

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> Cc: stable@kernel.org 
> ---
>  arch/x86/xen/enlighten.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index b132ade..dbb5bb7 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -63,6 +63,7 @@
>  #include <asm/stackprotector.h>
>  #include <asm/hypervisor.h>
>  #include <asm/mwait.h>
> +#include <asm/pci_x86.h>
>  
>  #ifdef CONFIG_ACPI
>  #include <linux/acpi.h>
> @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
>  		/* Make sure ACS will be enabled */
>  		pci_request_acs();
>  	}
> -		
> +
> +	/* PCI BIOS service won't work from a PV guest. */
> +	pci_probe &= ~PCI_PROBE_BIOS;
>  
>  	xen_raw_console_write("about to get started...\n");
>  
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIfhd-0001CY-WC; Fri, 13 Apr 2012 12:34:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIfhc-0001CR-Kl
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:34:12 +0000
Received: from [85.158.143.99:2433] by server-3.bemta-4.messagelabs.com id
	54/F1-05853-34D188F4; Fri, 13 Apr 2012 12:34:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334320451!12321299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26662 invoked from network); 13 Apr 2012 12:34:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 12:34:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11926130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 12:34:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 13:34:11 +0100
Message-ID: <1334320449.14560.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Fri, 13 Apr 2012 13:34:09 +0100
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] help finding privcmd hypercall handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 12:47 +0100, Francisco Rocha wrote:
> Hi everyone,
> 
> I am having some trouble finding the hypercall responsible 
> for handling calls to privcmd operations by a user-level applcation.
> Can anyone give me a pointer?

The is no "privcmd hypercall handler". One of the members of the
argument struct to IOCTL_PRIVCMD_HYPERCALL is the hypercall number
("op") to call, e.g. __HYPERVISOR_*. The pricvmd driver will make this
hypercall on behalf of userspace and it enters at the usual hypercall
entry point.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIfhd-0001CY-WC; Fri, 13 Apr 2012 12:34:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SIfhc-0001CR-Kl
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:34:12 +0000
Received: from [85.158.143.99:2433] by server-3.bemta-4.messagelabs.com id
	54/F1-05853-34D188F4; Fri, 13 Apr 2012 12:34:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334320451!12321299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26662 invoked from network); 13 Apr 2012 12:34:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 12:34:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="11926130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 12:34:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 13:34:11 +0100
Message-ID: <1334320449.14560.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Fri, 13 Apr 2012 13:34:09 +0100
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] help finding privcmd hypercall handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 12:47 +0100, Francisco Rocha wrote:
> Hi everyone,
> 
> I am having some trouble finding the hypercall responsible 
> for handling calls to privcmd operations by a user-level applcation.
> Can anyone give me a pointer?

The is no "privcmd hypercall handler". One of the members of the
argument struct to IOCTL_PRIVCMD_HYPERCALL is the hypercall number
("op") to call, e.g. __HYPERVISOR_*. The pricvmd driver will make this
hypercall on behalf of userspace and it enters at the usual hypercall
entry point.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIg2k-0001lX-Fj; Fri, 13 Apr 2012 12:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIg2i-0001lP-JZ
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:56:00 +0000
Received: from [85.158.138.51:22848] by server-12.bemta-3.messagelabs.com id
	8A/30-29760-F52288F4; Fri, 13 Apr 2012 12:55:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334321755!14118270!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26490 invoked from network); 13 Apr 2012 12:55:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 12:55:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190220451"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 08:55:13 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	08:55:13 -0400
Message-ID: <4F88222F.7050703@citrix.com>
Date: Fri, 13 Apr 2012 13:55:11 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
In-Reply-To: <4F883848020000780007DCD2@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 13:29, Jan Beulich wrote:
>>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> The accessing PCI configuration space with the PCI BIOS service does
>> not work in PV guests.
>>
>> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
>> marked the MMCONFIG region as reserved in the e820 map.
> 
> ... and where "direct" access doesn't work either? Are there really
> machines where Xen works on but this doesn't work? (Or, in case
> this is disabled in your config, is it really useful to have
> CONFIG_PCI_DIRECT disabled?)

If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
direct.  So this change makes it skip BIOS and fall back to direct.

On the system I had saw the problem, the first call into the BIOS
service would hang the system.

> That's just a comment on the description, the patch itself is fine
> nevertheless (but should probably be sent to the x86 and/or PCI
> maintainers).

I was expecting Konrad to pick it up and forward it to the relevant
maintainer as appropriate.  Konrad, would you prefer if I sent to direct?

>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
>> Cc: stable@kernel.org 
>> ---
>>  arch/x86/xen/enlighten.c |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index b132ade..dbb5bb7 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -63,6 +63,7 @@
>>  #include <asm/stackprotector.h>
>>  #include <asm/hypervisor.h>
>>  #include <asm/mwait.h>
>> +#include <asm/pci_x86.h>
>>  
>>  #ifdef CONFIG_ACPI
>>  #include <linux/acpi.h>
>> @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
>>  		/* Make sure ACS will be enabled */
>>  		pci_request_acs();
>>  	}
>> -		
>> +
>> +	/* PCI BIOS service won't work from a PV guest. */
>> +	pci_probe &= ~PCI_PROBE_BIOS;
>>  
>>  	xen_raw_console_write("about to get started...\n");
>>  
>> -- 
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 12:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 12:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIg2k-0001lX-Fj; Fri, 13 Apr 2012 12:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIg2i-0001lP-JZ
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 12:56:00 +0000
Received: from [85.158.138.51:22848] by server-12.bemta-3.messagelabs.com id
	8A/30-29760-F52288F4; Fri, 13 Apr 2012 12:55:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334321755!14118270!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26490 invoked from network); 13 Apr 2012 12:55:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 12:55:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190220451"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 08:55:13 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	08:55:13 -0400
Message-ID: <4F88222F.7050703@citrix.com>
Date: Fri, 13 Apr 2012 13:55:11 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
In-Reply-To: <4F883848020000780007DCD2@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 13:29, Jan Beulich wrote:
>>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> The accessing PCI configuration space with the PCI BIOS service does
>> not work in PV guests.
>>
>> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
>> marked the MMCONFIG region as reserved in the e820 map.
> 
> ... and where "direct" access doesn't work either? Are there really
> machines where Xen works on but this doesn't work? (Or, in case
> this is disabled in your config, is it really useful to have
> CONFIG_PCI_DIRECT disabled?)

If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
direct.  So this change makes it skip BIOS and fall back to direct.

On the system I had saw the problem, the first call into the BIOS
service would hang the system.

> That's just a comment on the description, the patch itself is fine
> nevertheless (but should probably be sent to the x86 and/or PCI
> maintainers).

I was expecting Konrad to pick it up and forward it to the relevant
maintainer as appropriate.  Konrad, would you prefer if I sent to direct?

>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
>> Cc: stable@kernel.org 
>> ---
>>  arch/x86/xen/enlighten.c |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index b132ade..dbb5bb7 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -63,6 +63,7 @@
>>  #include <asm/stackprotector.h>
>>  #include <asm/hypervisor.h>
>>  #include <asm/mwait.h>
>> +#include <asm/pci_x86.h>
>>  
>>  #ifdef CONFIG_ACPI
>>  #include <linux/acpi.h>
>> @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
>>  		/* Make sure ACS will be enabled */
>>  		pci_request_acs();
>>  	}
>> -		
>> +
>> +	/* PCI BIOS service won't work from a PV guest. */
>> +	pci_probe &= ~PCI_PROBE_BIOS;
>>  
>>  	xen_raw_console_write("about to get started...\n");
>>  
>> -- 
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 13:20:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 13:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIgQ4-0002C5-HA; Fri, 13 Apr 2012 13:20:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SIgQ2-0002C0-Cd
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 13:20:06 +0000
Received: from [85.158.139.83:11601] by server-1.bemta-5.messagelabs.com id
	B3/3D-28458-508288F4; Fri, 13 Apr 2012 13:20:05 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334323204!19092878!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYzNTc4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31526 invoked from network); 13 Apr 2012 13:20:04 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 13:20:04 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 13 Apr 2012 06:20:03 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88709913"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Apr 2012 06:20:03 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 13 Apr 2012 06:20:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Fri, 13 Apr 2012 21:20:01 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
Thread-Index: AQHNGK0SValDuNDgj0mS7aEFU/pTFpaX+1HAgAB7rQ+AAEeAcA==
Date: Fri, 13 Apr 2012 13:20:00 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D37D9@SHSMSX101.ccr.corp.intel.com>
References: <4F86D464.4080601@amd.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
	<4F88002D020000780007DB8D@nat28.tlf.novell.com>
	<4F87EC89.6080206@amd.com>
In-Reply-To: <4F87EC89.6080206@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: AndrePrzywara <andre.przywara@amd.com>, Wei Huang <wei.huang2@amd.com>,
	Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Me too.

best regards
yang


> -----Original Message-----
> From: Wei Wang [mailto:wei.wang2@amd.com]
> Sent: Friday, April 13, 2012 5:06 PM
> To: Jan Beulich
> Cc: Zhang, Yang Z; AndrePrzywara; Boris Ostrovsky; Wei Huang;
> xen-devel@lists.xensource.com; Keir Fraser
> Subject: Re: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> On 04/13/2012 10:30 AM, Jan Beulich wrote:
> >>>> On 13.04.12 at 04:14, "Zhang, Yang Z"<yang.z.zhang@intel.com>
> wrote:
> >> This should not be enough. No need to check bm when going to C2.
> >> How about the following patch:
> >
> > That looks right, but I'd prefer to simplify it a little:
> >
> > --- a/xen/arch/x86/acpi/cpu_idle.c
> > +++ b/xen/arch/x86/acpi/cpu_idle.c
> > @@ -493,7 +493,9 @@ static void acpi_processor_idle(void)
> >            * not set. In that case we cannot do much, we enter C3
> >            * without doing anything.
> >            */
> > -        if ( power->flags.bm_check&&  power->flags.bm_control )
> > +        if ( cx->type != ACPI_STATE_C3 )
> > +            /* nothing to be done here */;
> > +        else if ( power->flags.bm_check&&  power->flags.bm_control )
> >           {
> >               spin_lock(&c3_cpu_status.lock);
> >               if ( ++c3_cpu_status.count == num_online_cpus() ) @@
> > -515,7 +517,8 @@ static void acpi_processor_idle(void)
> >           /* Invoke C3 */
> >           acpi_idle_do_entry(cx);
> >
> > -        if ( power->flags.bm_check&&  power->flags.bm_control )
> > +        if ( (cx->type == ACPI_STATE_C3)&&
> > +             power->flags.bm_check&&  power->flags.bm_control )
> >           {
> >               /* Enable bus master arbitration */
> >               spin_lock(&c3_cpu_status.lock);
> >
> > Also, Yang, you didn't provide a S-o-b - are you okay with me adding
> > it?
> >
> > If you're both okay with above patch, I'll see that I get it committed.
> >
> > Jan
> >
> >
> 
> This looks good to me. Thanks
> Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 13:20:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 13:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIgQ4-0002C5-HA; Fri, 13 Apr 2012 13:20:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SIgQ2-0002C0-Cd
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 13:20:06 +0000
Received: from [85.158.139.83:11601] by server-1.bemta-5.messagelabs.com id
	B3/3D-28458-508288F4; Fri, 13 Apr 2012 13:20:05 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334323204!19092878!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYzNTc4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31526 invoked from network); 13 Apr 2012 13:20:04 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 13:20:04 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 13 Apr 2012 06:20:03 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88709913"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Apr 2012 06:20:03 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 13 Apr 2012 06:20:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Fri, 13 Apr 2012 21:20:01 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
Thread-Index: AQHNGK0SValDuNDgj0mS7aEFU/pTFpaX+1HAgAB7rQ+AAEeAcA==
Date: Fri, 13 Apr 2012 13:20:00 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D37D9@SHSMSX101.ccr.corp.intel.com>
References: <4F86D464.4080601@amd.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0D1CBE@SHSMSX101.ccr.corp.intel.com>
	<4F88002D020000780007DB8D@nat28.tlf.novell.com>
	<4F87EC89.6080206@amd.com>
In-Reply-To: <4F87EC89.6080206@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: AndrePrzywara <andre.przywara@amd.com>, Wei Huang <wei.huang2@amd.com>,
	Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Subject: Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type !=
	ACPI_STATE_C3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Me too.

best regards
yang


> -----Original Message-----
> From: Wei Wang [mailto:wei.wang2@amd.com]
> Sent: Friday, April 13, 2012 5:06 PM
> To: Jan Beulich
> Cc: Zhang, Yang Z; AndrePrzywara; Boris Ostrovsky; Wei Huang;
> xen-devel@lists.xensource.com; Keir Fraser
> Subject: Re: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> On 04/13/2012 10:30 AM, Jan Beulich wrote:
> >>>> On 13.04.12 at 04:14, "Zhang, Yang Z"<yang.z.zhang@intel.com>
> wrote:
> >> This should not be enough. No need to check bm when going to C2.
> >> How about the following patch:
> >
> > That looks right, but I'd prefer to simplify it a little:
> >
> > --- a/xen/arch/x86/acpi/cpu_idle.c
> > +++ b/xen/arch/x86/acpi/cpu_idle.c
> > @@ -493,7 +493,9 @@ static void acpi_processor_idle(void)
> >            * not set. In that case we cannot do much, we enter C3
> >            * without doing anything.
> >            */
> > -        if ( power->flags.bm_check&&  power->flags.bm_control )
> > +        if ( cx->type != ACPI_STATE_C3 )
> > +            /* nothing to be done here */;
> > +        else if ( power->flags.bm_check&&  power->flags.bm_control )
> >           {
> >               spin_lock(&c3_cpu_status.lock);
> >               if ( ++c3_cpu_status.count == num_online_cpus() ) @@
> > -515,7 +517,8 @@ static void acpi_processor_idle(void)
> >           /* Invoke C3 */
> >           acpi_idle_do_entry(cx);
> >
> > -        if ( power->flags.bm_check&&  power->flags.bm_control )
> > +        if ( (cx->type == ACPI_STATE_C3)&&
> > +             power->flags.bm_check&&  power->flags.bm_control )
> >           {
> >               /* Enable bus master arbitration */
> >               spin_lock(&c3_cpu_status.lock);
> >
> > Also, Yang, you didn't provide a S-o-b - are you okay with me adding
> > it?
> >
> > If you're both okay with above patch, I'll see that I get it committed.
> >
> > Jan
> >
> >
> 
> This looks good to me. Thanks
> Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 13:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 13:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIgTn-0002IQ-5O; Fri, 13 Apr 2012 13:23:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIgTm-0002IL-FB
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 13:23:58 +0000
Received: from [193.109.254.147:32806] by server-2.bemta-14.messagelabs.com id
	EC/4A-19409-DE8288F4; Fri, 13 Apr 2012 13:23:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334323434!4448820!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6185 invoked from network); 13 Apr 2012 13:23:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 13:23:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190226238"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 09:23:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 09:23:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIgTA-0006qg-O3;
	Fri, 13 Apr 2012 14:23:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 686ba604624db0796ce76b1f42b0106e98723846
Message-ID: <686ba604624db0796ce7.1334323301@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 13 Apr 2012 14:21:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] Revert c/s 25150:b490ef93bad7 tools/libfsimage:
 include Rules.mk first
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

tools/libfsimage/Rules.mk relies on having certain variables set already; if
they're not set, the definitions dont' work right.  The result was a bunch
of empty files and pygrub failing with an uninformative error message.

It's likely that this didn't cause anyone problems becasue changing the
Makefiles didn't cause a re-build; building from a fresh repo results in
completely empty filesystem plugin binaries.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/ext2fs-lib/Makefile
--- a/tools/libfsimage/ext2fs-lib/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/ext2fs-lib/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = ext2fs-lib.c
 
@@ -12,3 +11,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/ext2fs/Makefile
--- a/tools/libfsimage/ext2fs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/ext2fs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_ext2fs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/fat/Makefile
--- a/tools/libfsimage/fat/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/fat/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_fat.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/iso9660/Makefile
--- a/tools/libfsimage/iso9660/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/iso9660/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_iso9660.c
 
@@ -12,3 +11,5 @@ all: fs-all
 install: fs-install
 
 fsys_iso9660.c: iso9660.h
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/reiserfs/Makefile
--- a/tools/libfsimage/reiserfs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/reiserfs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_reiserfs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/ufs/Makefile
--- a/tools/libfsimage/ufs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/ufs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_ufs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/xfs/Makefile
--- a/tools/libfsimage/xfs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/xfs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_xfs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/zfs/Makefile
--- a/tools/libfsimage/zfs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/zfs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -23,7 +23,6 @@
 #
 
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 CFLAGS += -DFSYS_ZFS -DFSIMAGE -I$(XEN_ROOT)/tools/libfsimage/zfs
 LIB_SRCS-y = zfs_lzjb.c zfs_sha256.c zfs_fletcher.c fsi_zfs.c fsys_zfs.c
@@ -35,3 +34,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 13:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 13:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIgTn-0002IQ-5O; Fri, 13 Apr 2012 13:23:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SIgTm-0002IL-FB
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 13:23:58 +0000
Received: from [193.109.254.147:32806] by server-2.bemta-14.messagelabs.com id
	EC/4A-19409-DE8288F4; Fri, 13 Apr 2012 13:23:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334323434!4448820!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6185 invoked from network); 13 Apr 2012 13:23:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 13:23:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,417,1330923600"; d="scan'208";a="190226238"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 09:23:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 09:23:21 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SIgTA-0006qg-O3;
	Fri, 13 Apr 2012 14:23:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 686ba604624db0796ce76b1f42b0106e98723846
Message-ID: <686ba604624db0796ce7.1334323301@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 13 Apr 2012 14:21:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] Revert c/s 25150:b490ef93bad7 tools/libfsimage:
 include Rules.mk first
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

tools/libfsimage/Rules.mk relies on having certain variables set already; if
they're not set, the definitions dont' work right.  The result was a bunch
of empty files and pygrub failing with an uninformative error message.

It's likely that this didn't cause anyone problems becasue changing the
Makefiles didn't cause a re-build; building from a fresh repo results in
completely empty filesystem plugin binaries.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/ext2fs-lib/Makefile
--- a/tools/libfsimage/ext2fs-lib/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/ext2fs-lib/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = ext2fs-lib.c
 
@@ -12,3 +11,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/ext2fs/Makefile
--- a/tools/libfsimage/ext2fs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/ext2fs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_ext2fs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/fat/Makefile
--- a/tools/libfsimage/fat/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/fat/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_fat.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/iso9660/Makefile
--- a/tools/libfsimage/iso9660/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/iso9660/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_iso9660.c
 
@@ -12,3 +11,5 @@ all: fs-all
 install: fs-install
 
 fsys_iso9660.c: iso9660.h
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/reiserfs/Makefile
--- a/tools/libfsimage/reiserfs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/reiserfs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_reiserfs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/ufs/Makefile
--- a/tools/libfsimage/ufs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/ufs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_ufs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/xfs/Makefile
--- a/tools/libfsimage/xfs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/xfs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -1,5 +1,4 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 LIB_SRCS-y = fsys_xfs.c
 
@@ -10,3 +9,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
diff -r cbd10b2ee64f -r 686ba604624d tools/libfsimage/zfs/Makefile
--- a/tools/libfsimage/zfs/Makefile	Fri Apr 13 13:35:25 2012 +0100
+++ b/tools/libfsimage/zfs/Makefile	Fri Apr 13 14:21:25 2012 +0100
@@ -23,7 +23,6 @@
 #
 
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 CFLAGS += -DFSYS_ZFS -DFSIMAGE -I$(XEN_ROOT)/tools/libfsimage/zfs
 LIB_SRCS-y = zfs_lzjb.c zfs_sha256.c zfs_fletcher.c fsi_zfs.c fsys_zfs.c
@@ -35,3 +34,5 @@ all: fs-all
 
 .PHONY: install
 install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 13:40:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 13:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIgjJ-0003fQ-Ah; Fri, 13 Apr 2012 13:40:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIgjH-0003fB-B8
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 13:39:59 +0000
Received: from [85.158.138.51:41979] by server-10.bemta-3.messagelabs.com id
	7A/72-29478-EAC288F4; Fri, 13 Apr 2012 13:39:58 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334324397!21993812!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAyOTg3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23030 invoked from network); 13 Apr 2012 13:39:58 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 13:39:58 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIgjF-0005x8-Bh; Fri, 13 Apr 2012 14:39:57 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Fri, 13 Apr 2012
	14:39:39 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 13 Apr 2012 14:39:40 +0100
Thread-Topic: [Xen-devel] help finding privcmd hypercall handler
Thread-Index: Ac0ZccAuFmLOkqG/Qg+CnFqtdUi2XwABOJmA
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A8@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>,
	<1334320449.14560.28.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334320449.14560.28.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] help finding privcmd hypercall handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: 13 April 2012 13:34
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] help finding privcmd hypercall handler

On Fri, 2012-04-13 at 12:47 +0100, Francisco Rocha wrote:
> Hi everyone,
>
> I am having some trouble finding the hypercall responsible
> for handling calls to privcmd operations by a user-level applcation.
> Can anyone give me a pointer?

The is no "privcmd hypercall handler". One of the members of the
argument struct to IOCTL_PRIVCMD_HYPERCALL is the hypercall number
("op") to call, e.g. __HYPERVISOR_*. The pricvmd driver will make this
hypercall on behalf of userspace and it enters at the usual hypercall
entry point.

Ian.

I was a bit confused because I was focusing on Xen code.
I have been exploring the Linux kernel code and I think now I understand it.

Thank you Ian,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 13:40:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 13:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIgjJ-0003fQ-Ah; Fri, 13 Apr 2012 13:40:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIgjH-0003fB-B8
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 13:39:59 +0000
Received: from [85.158.138.51:41979] by server-10.bemta-3.messagelabs.com id
	7A/72-29478-EAC288F4; Fri, 13 Apr 2012 13:39:58 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334324397!21993812!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTAyOTg3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23030 invoked from network); 13 Apr 2012 13:39:58 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 13:39:58 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SIgjF-0005x8-Bh; Fri, 13 Apr 2012 14:39:57 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Fri, 13 Apr 2012
	14:39:39 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 13 Apr 2012 14:39:40 +0100
Thread-Topic: [Xen-devel] help finding privcmd hypercall handler
Thread-Index: Ac0ZccAuFmLOkqG/Qg+CnFqtdUi2XwABOJmA
Message-ID: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A8@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A7@EXCCR03.campus.ncl.ac.uk>,
	<1334320449.14560.28.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334320449.14560.28.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] help finding privcmd hypercall handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: 13 April 2012 13:34
To: Francisco Rocha
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] help finding privcmd hypercall handler

On Fri, 2012-04-13 at 12:47 +0100, Francisco Rocha wrote:
> Hi everyone,
>
> I am having some trouble finding the hypercall responsible
> for handling calls to privcmd operations by a user-level applcation.
> Can anyone give me a pointer?

The is no "privcmd hypercall handler". One of the members of the
argument struct to IOCTL_PRIVCMD_HYPERCALL is the hypercall number
("op") to call, e.g. __HYPERVISOR_*. The pricvmd driver will make this
hypercall on behalf of userspace and it enters at the usual hypercall
entry point.

Ian.

I was a bit confused because I was focusing on Xen code.
I have been exploring the Linux kernel code and I think now I understand it.

Thank you Ian,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 14:08:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhA5-00047D-R3; Fri, 13 Apr 2012 14:07:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SIhA4-000478-HU
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 14:07:40 +0000
Received: from [85.158.143.99:25298] by server-2.bemta-4.messagelabs.com id
	AB/68-17550-B23388F4; Fri, 13 Apr 2012 14:07:39 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334326058!22964674!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjExODQ4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5758 invoked from network); 13 Apr 2012 14:07:39 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 14:07:39 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 13 Apr 2012 07:07:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88722895"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Apr 2012 07:07:37 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 13 Apr 2012 07:07:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Fri, 13 Apr 2012 22:07:35 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] fix build error when enabling lock profile
Thread-Index: Ac0ZfsYO/qYxGg5JQz6aeBCX08aM+A==
Date: Fri, 13 Apr 2012 14:07:34 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D388D@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] fix build error when enabling lock profile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When enabling lock profile, it fail to finish build. I have no idea why this will be called in setting lock profiling.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r c6bde42c8845 xen/common/sysctl.c
--- a/xen/common/sysctl.c   Thu Apr 12 14:01:27 2012 +0100
+++ b/xen/common/sysctl.c   Fri Apr 13 22:05:15 2012 +0800
@@ -156,7 +156,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
         if ( ret )
             break;

-        ret = perfc_control(&op->u.perfc_op);
         ret = spinlock_profile_control(&op->u.lockprof_op);
         if ( copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 14:08:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhA5-00047D-R3; Fri, 13 Apr 2012 14:07:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SIhA4-000478-HU
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 14:07:40 +0000
Received: from [85.158.143.99:25298] by server-2.bemta-4.messagelabs.com id
	AB/68-17550-B23388F4; Fri, 13 Apr 2012 14:07:39 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334326058!22964674!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjExODQ4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5758 invoked from network); 13 Apr 2012 14:07:39 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 14:07:39 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 13 Apr 2012 07:07:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88722895"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Apr 2012 07:07:37 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 13 Apr 2012 07:07:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Fri, 13 Apr 2012 22:07:35 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] fix build error when enabling lock profile
Thread-Index: Ac0ZfsYO/qYxGg5JQz6aeBCX08aM+A==
Date: Fri, 13 Apr 2012 14:07:34 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D388D@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] fix build error when enabling lock profile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When enabling lock profile, it fail to finish build. I have no idea why this will be called in setting lock profiling.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r c6bde42c8845 xen/common/sysctl.c
--- a/xen/common/sysctl.c   Thu Apr 12 14:01:27 2012 +0100
+++ b/xen/common/sysctl.c   Fri Apr 13 22:05:15 2012 +0800
@@ -156,7 +156,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
         if ( ret )
             break;

-        ret = perfc_control(&op->u.perfc_op);
         ret = spinlock_profile_control(&op->u.lockprof_op);
         if ( copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 14:15:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhHf-0004MO-Pi; Fri, 13 Apr 2012 14:15:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIhHe-0004MJ-UA
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 14:15:31 +0000
Received: from [85.158.143.99:3756] by server-2.bemta-4.messagelabs.com id
	26/53-17550-205388F4; Fri, 13 Apr 2012 14:15:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334326528!13766160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21204 invoked from network); 13 Apr 2012 14:15:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 14:15:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 15:15:27 +0100
Message-Id: <4F885120020000780007DD18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 15:15:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
In-Reply-To: <4F88222F.7050703@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 14:55, David Vrabel <david.vrabel@citrix.com> wrote:
> On 13/04/12 13:29, Jan Beulich wrote:
>>>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
>>> From: David Vrabel <david.vrabel@citrix.com>
>>>
>>> The accessing PCI configuration space with the PCI BIOS service does
>>> not work in PV guests.
>>>
>>> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
>>> marked the MMCONFIG region as reserved in the e820 map.
>> 
>> ... and where "direct" access doesn't work either? Are there really
>> machines where Xen works on but this doesn't work? (Or, in case
>> this is disabled in your config, is it really useful to have
>> CONFIG_PCI_DIRECT disabled?)
> 
> If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
> direct.  So this change makes it skip BIOS and fall back to direct.

How is that? When I look at pci_arch_init(), I see pci_direct_probe()
being called first.

> On the system I had saw the problem, the first call into the BIOS
> service would hang the system.

Sure.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 14:15:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhHf-0004MO-Pi; Fri, 13 Apr 2012 14:15:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SIhHe-0004MJ-UA
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 14:15:31 +0000
Received: from [85.158.143.99:3756] by server-2.bemta-4.messagelabs.com id
	26/53-17550-205388F4; Fri, 13 Apr 2012 14:15:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334326528!13766160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21204 invoked from network); 13 Apr 2012 14:15:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 14:15:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Apr 2012 15:15:27 +0100
Message-Id: <4F885120020000780007DD18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Apr 2012 15:15:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
In-Reply-To: <4F88222F.7050703@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 14:55, David Vrabel <david.vrabel@citrix.com> wrote:
> On 13/04/12 13:29, Jan Beulich wrote:
>>>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
>>> From: David Vrabel <david.vrabel@citrix.com>
>>>
>>> The accessing PCI configuration space with the PCI BIOS service does
>>> not work in PV guests.
>>>
>>> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
>>> marked the MMCONFIG region as reserved in the e820 map.
>> 
>> ... and where "direct" access doesn't work either? Are there really
>> machines where Xen works on but this doesn't work? (Or, in case
>> this is disabled in your config, is it really useful to have
>> CONFIG_PCI_DIRECT disabled?)
> 
> If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
> direct.  So this change makes it skip BIOS and fall back to direct.

How is that? When I look at pci_arch_init(), I see pci_direct_probe()
being called first.

> On the system I had saw the problem, the first call into the BIOS
> service would hang the system.

Sure.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 14:23:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhPD-0004VT-Mf; Fri, 13 Apr 2012 14:23:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SIhPC-0004VO-4P
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 14:23:18 +0000
Received: from [85.158.139.83:57119] by server-5.bemta-5.messagelabs.com id
	87/E9-13566-5D6388F4; Fri, 13 Apr 2012 14:23:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334326995!23619840!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32755 invoked from network); 13 Apr 2012 14:23:16 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 14:23:16 -0000
Received: from mail146-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:23:14 +0000
Received: from mail146-va3 (localhost [127.0.0.1])	by
	mail146-va3-R.bigfish.com (Postfix) with ESMTP id 4DF4D1203A8	for
	<xen-devel@lists.xen.org>; Fri, 13 Apr 2012 14:23:14 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail146-va3 (localhost.localdomain [127.0.0.1]) by mail146-va3
	(MessageSwitch) id 1334326992602366_19603;
	Fri, 13 Apr 2012 14:23:12 +0000 (UTC)
Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.240])	by
	mail146-va3.bigfish.com (Postfix) with ESMTP id 89DCB360257	for
	<xen-devel@lists.xen.org>; Fri, 13 Apr 2012 14:23:12 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:23:09 +0000
X-WSS-ID: 0M2F9AK-01-1XM-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 24523102810B	for <xen-devel@lists.xen.org>;
	Fri, 13 Apr 2012 09:23:07 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 09:23:26 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 13 Apr 2012 09:23:07 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	10:23:06 -0400
Message-ID: <4F8836C9.9080502@amd.com>
Date: Fri, 13 Apr 2012 16:23:05 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------020300070809000102090609"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------020300070809000102090609
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Pass PYTHON down to seabios, so seabios will
use same python binary as whole xen tree does.
Fixes build error on NetBSD.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

--------------020300070809000102090609
Content-Type: text/plain; charset="us-ascii"; name="xen_build_seabios.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_build_seabios.diff"
Content-Description: xen_build_seabios.diff

diff -r ab552da976a3 tools/firmware/Makefile
--- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
+++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
@@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
 	false ; \
 	fi
 endif
-	$(MAKE) subdirs-$@
+	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
 
 
 .PHONY: install

--------------020300070809000102090609
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020300070809000102090609--


From xen-devel-bounces@lists.xen.org Fri Apr 13 14:23:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhPD-0004VT-Mf; Fri, 13 Apr 2012 14:23:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SIhPC-0004VO-4P
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 14:23:18 +0000
Received: from [85.158.139.83:57119] by server-5.bemta-5.messagelabs.com id
	87/E9-13566-5D6388F4; Fri, 13 Apr 2012 14:23:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334326995!23619840!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32755 invoked from network); 13 Apr 2012 14:23:16 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 14:23:16 -0000
Received: from mail146-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:23:14 +0000
Received: from mail146-va3 (localhost [127.0.0.1])	by
	mail146-va3-R.bigfish.com (Postfix) with ESMTP id 4DF4D1203A8	for
	<xen-devel@lists.xen.org>; Fri, 13 Apr 2012 14:23:14 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail146-va3 (localhost.localdomain [127.0.0.1]) by mail146-va3
	(MessageSwitch) id 1334326992602366_19603;
	Fri, 13 Apr 2012 14:23:12 +0000 (UTC)
Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.240])	by
	mail146-va3.bigfish.com (Postfix) with ESMTP id 89DCB360257	for
	<xen-devel@lists.xen.org>; Fri, 13 Apr 2012 14:23:12 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:23:09 +0000
X-WSS-ID: 0M2F9AK-01-1XM-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 24523102810B	for <xen-devel@lists.xen.org>;
	Fri, 13 Apr 2012 09:23:07 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 09:23:26 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 13 Apr 2012 09:23:07 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	10:23:06 -0400
Message-ID: <4F8836C9.9080502@amd.com>
Date: Fri, 13 Apr 2012 16:23:05 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------020300070809000102090609"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------020300070809000102090609
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Pass PYTHON down to seabios, so seabios will
use same python binary as whole xen tree does.
Fixes build error on NetBSD.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

--------------020300070809000102090609
Content-Type: text/plain; charset="us-ascii"; name="xen_build_seabios.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_build_seabios.diff"
Content-Description: xen_build_seabios.diff

diff -r ab552da976a3 tools/firmware/Makefile
--- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
+++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
@@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
 	false ; \
 	fi
 endif
-	$(MAKE) subdirs-$@
+	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
 
 
 .PHONY: install

--------------020300070809000102090609
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020300070809000102090609--


From xen-devel-bounces@lists.xen.org Fri Apr 13 14:25:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhR2-0004Ze-6b; Fri, 13 Apr 2012 14:25:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SIhR0-0004ZS-Rg
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 14:25:11 +0000
Received: from [193.109.254.147:16042] by server-2.bemta-14.messagelabs.com id
	4B/18-19409-647388F4; Fri, 13 Apr 2012 14:25:10 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334327108!4489580!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29536 invoked from network); 13 Apr 2012 14:25:09 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 14:25:09 -0000
Received: from mail152-ch1-R.bigfish.com (10.43.68.233) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:25:07 +0000
Received: from mail152-ch1 (localhost [127.0.0.1])	by
	mail152-ch1-R.bigfish.com (Postfix) with ESMTP id B5643E02CA	for
	<xen-devel@lists.xen.org>; Fri, 13 Apr 2012 14:25:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail152-ch1 (localhost.localdomain [127.0.0.1]) by mail152-ch1
	(MessageSwitch) id 1334327106371980_24142;
	Fri, 13 Apr 2012 14:25:06 +0000 (UTC)
Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.244])	by mail152-ch1.bigfish.com (Postfix) with ESMTP id
	552BA3E08D8	for <xen-devel@lists.xen.org>;
	Fri, 13 Apr 2012 14:25:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:25:05 +0000
X-WSS-ID: 0M2F9DR-01-21W-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2C9EC102810B	for <xen-devel@lists.xen.org>;
	Fri, 13 Apr 2012 09:25:02 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 09:25:21 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 13 Apr 2012 09:25:02 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	10:25:01 -0400
Message-ID: <4F88373C.6050007@amd.com>
Date: Fri, 13 Apr 2012 16:25:00 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------010401020302050809040906"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] fix build error w/o MEMSHR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------010401020302050809040906
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Do not include memshr.h when MEMSHR is not defined.
Fixes build error when MEMSHR is disabled.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

--------------010401020302050809040906
Content-Type: text/plain; charset="us-ascii";
	name="xen_tools_blktapctrl.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_blktapctrl.diff"
Content-Description: xen_tools_blktapctrl.diff

diff -r ab552da976a3 tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c	Wed Apr 11 18:28:33 2012 +0200
+++ b/tools/blktap/drivers/blktapctrl.c	Fri Apr 13 16:21:11 2012 +0200
@@ -50,7 +50,9 @@
 #include <xs.h>
 #include <sys/time.h>
 #include <syslog.h>
+#ifdef MEMSHR
 #include <memshr.h>
+#endif
 #include <sys/stat.h>
                                                                      
 #include "blktaplib.h"

--------------010401020302050809040906
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010401020302050809040906--


From xen-devel-bounces@lists.xen.org Fri Apr 13 14:25:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 14:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIhR2-0004Ze-6b; Fri, 13 Apr 2012 14:25:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SIhR0-0004ZS-Rg
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 14:25:11 +0000
Received: from [193.109.254.147:16042] by server-2.bemta-14.messagelabs.com id
	4B/18-19409-647388F4; Fri, 13 Apr 2012 14:25:10 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334327108!4489580!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29536 invoked from network); 13 Apr 2012 14:25:09 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 14:25:09 -0000
Received: from mail152-ch1-R.bigfish.com (10.43.68.233) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:25:07 +0000
Received: from mail152-ch1 (localhost [127.0.0.1])	by
	mail152-ch1-R.bigfish.com (Postfix) with ESMTP id B5643E02CA	for
	<xen-devel@lists.xen.org>; Fri, 13 Apr 2012 14:25:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail152-ch1 (localhost.localdomain [127.0.0.1]) by mail152-ch1
	(MessageSwitch) id 1334327106371980_24142;
	Fri, 13 Apr 2012 14:25:06 +0000 (UTC)
Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.244])	by mail152-ch1.bigfish.com (Postfix) with ESMTP id
	552BA3E08D8	for <xen-devel@lists.xen.org>;
	Fri, 13 Apr 2012 14:25:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 14:25:05 +0000
X-WSS-ID: 0M2F9DR-01-21W-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2C9EC102810B	for <xen-devel@lists.xen.org>;
	Fri, 13 Apr 2012 09:25:02 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 09:25:21 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 13 Apr 2012 09:25:02 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	10:25:01 -0400
Message-ID: <4F88373C.6050007@amd.com>
Date: Fri, 13 Apr 2012 16:25:00 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------010401020302050809040906"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] fix build error w/o MEMSHR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--------------010401020302050809040906
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Do not include memshr.h when MEMSHR is not defined.
Fixes build error when MEMSHR is disabled.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

--------------010401020302050809040906
Content-Type: text/plain; charset="us-ascii";
	name="xen_tools_blktapctrl.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_blktapctrl.diff"
Content-Description: xen_tools_blktapctrl.diff

diff -r ab552da976a3 tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c	Wed Apr 11 18:28:33 2012 +0200
+++ b/tools/blktap/drivers/blktapctrl.c	Fri Apr 13 16:21:11 2012 +0200
@@ -50,7 +50,9 @@
 #include <xs.h>
 #include <sys/time.h>
 #include <syslog.h>
+#ifdef MEMSHR
 #include <memshr.h>
+#endif
 #include <sys/stat.h>
                                                                      
 #include "blktaplib.h"

--------------010401020302050809040906
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010401020302050809040906--


From xen-devel-bounces@lists.xen.org Fri Apr 13 15:25:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 15:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIiNE-000561-SI; Fri, 13 Apr 2012 15:25:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIiND-00055w-Ap
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 15:25:19 +0000
Received: from [85.158.143.35:46587] by server-3.bemta-4.messagelabs.com id
	0A/6E-05853-E55488F4; Fri, 13 Apr 2012 15:25:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334330716!11231307!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10428 invoked from network); 13 Apr 2012 15:25:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 15:25:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24141493"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 11:25:15 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	11:25:15 -0400
Message-ID: <4F884559.5000800@citrix.com>
Date: Fri, 13 Apr 2012 16:25:13 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
	<4F885120020000780007DD18@nat28.tlf.novell.com>
In-Reply-To: <4F885120020000780007DD18@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 15:15, Jan Beulich wrote:
>>>> On 13.04.12 at 14:55, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 13/04/12 13:29, Jan Beulich wrote:
>>>>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>
>>>> The accessing PCI configuration space with the PCI BIOS service does
>>>> not work in PV guests.
>>>>
>>>> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
>>>> marked the MMCONFIG region as reserved in the e820 map.
>>>
>>> ... and where "direct" access doesn't work either? Are there really
>>> machines where Xen works on but this doesn't work? (Or, in case
>>> this is disabled in your config, is it really useful to have
>>> CONFIG_PCI_DIRECT disabled?)
>>
>> If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
>> direct.  So this change makes it skip BIOS and fall back to direct.
> 
> How is that? When I look at pci_arch_init(), I see pci_direct_probe()
> being called first.

Hmm. Direct /is/ preferred over BIOS.  But the BIOS is initialized even
if direct is eventually used and it's the init of the BIOS that dies.

I'll fixup the description to make this clearer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 15:25:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 15:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIiNE-000561-SI; Fri, 13 Apr 2012 15:25:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIiND-00055w-Ap
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 15:25:19 +0000
Received: from [85.158.143.35:46587] by server-3.bemta-4.messagelabs.com id
	0A/6E-05853-E55488F4; Fri, 13 Apr 2012 15:25:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334330716!11231307!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10428 invoked from network); 13 Apr 2012 15:25:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 15:25:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24141493"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 11:25:15 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	11:25:15 -0400
Message-ID: <4F884559.5000800@citrix.com>
Date: Fri, 13 Apr 2012 16:25:13 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
	<4F885120020000780007DD18@nat28.tlf.novell.com>
In-Reply-To: <4F885120020000780007DD18@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 15:15, Jan Beulich wrote:
>>>> On 13.04.12 at 14:55, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 13/04/12 13:29, Jan Beulich wrote:
>>>>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>
>>>> The accessing PCI configuration space with the PCI BIOS service does
>>>> not work in PV guests.
>>>>
>>>> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
>>>> marked the MMCONFIG region as reserved in the e820 map.
>>>
>>> ... and where "direct" access doesn't work either? Are there really
>>> machines where Xen works on but this doesn't work? (Or, in case
>>> this is disabled in your config, is it really useful to have
>>> CONFIG_PCI_DIRECT disabled?)
>>
>> If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
>> direct.  So this change makes it skip BIOS and fall back to direct.
> 
> How is that? When I look at pci_arch_init(), I see pci_direct_probe()
> being called first.

Hmm. Direct /is/ preferred over BIOS.  But the BIOS is initialized even
if direct is eventually used and it's the init of the BIOS that dies.

I'll fixup the description to make this clearer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 15:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 15:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIiQP-0005BS-F3; Fri, 13 Apr 2012 15:28:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SIiQO-0005BN-C3
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 15:28:36 +0000
Received: from [85.158.139.83:22349] by server-9.bemta-5.messagelabs.com id
	51/6F-09826-326488F4; Fri, 13 Apr 2012 15:28:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334330912!23042297!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY3ODA1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10953 invoked from network); 13 Apr 2012 15:28:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Apr 2012 15:28:34 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3DFSQfD024466
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Apr 2012 15:28:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3DFSP1U000445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Apr 2012 15:28:26 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3DFSPRs029775; Fri, 13 Apr 2012 10:28:25 -0500
MIME-Version: 1.0
Message-ID: <4c2f7fca-dda2-4598-aaab-3a6a3fe532cd@default>
Date: Fri, 13 Apr 2012 08:28:19 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
	<1334249132.16387.147.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334249132.16387.147.camel@zakaz.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F88461B.00AF,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > >
> 
> > Libxl_tmem_destroy may take a long time as it has to walk
> > through and free some potentially very large data structures,
> > but it is only used at domain destruction.
> 
> Should libxl_tmem_destroy be a public function or should it solely be
> called from libxl_domain_destroy? I notice that there is an xl
> tmem-destroy so I presume the former?
> 
> We might consider adding a dummy ao_how to this one I suppose.

Bearing in mind that I haven't poked around in this
code for over 2 years, I *think* the only reason tmem_destroy
needs to exist at all is if tmem is broken.  The normal domain
termination process destroys any persistent tmem pools and
any ephemeral tmem pools will eventually "age out" as the
last of the pools' pages fall off the end of the LRU.

I think the tmem_destroy functionality pre-dates the
existence of tmem "freeable" memory* and was a way for
a toolset to force the hypervisor to free up the hypervisor
memory used by some or all ephemeral tmem pools.  Once the
tmem allocation/free process was directly linked into
alloc_heap_pages() in the hypervisor (see call to
tmem_relinquish_pages()), this forcing function was
no longer needed.

So, bottom line, I *think* it can be ripped out, or at least
for now removed from the definition of the stable xl API/UI.
The libxl.c routine libxl_tmem_destroy() could also be
removed if you like, but I guess I'd prefer to leave the
lower level droppings in xc.c and in the hypervisor in case
I am misremembering.

* http://xenbits.xensource.com/hg/xen-unstable.hg/rev/03063e309356

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 15:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 15:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIiQP-0005BS-F3; Fri, 13 Apr 2012 15:28:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SIiQO-0005BN-C3
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 15:28:36 +0000
Received: from [85.158.139.83:22349] by server-9.bemta-5.messagelabs.com id
	51/6F-09826-326488F4; Fri, 13 Apr 2012 15:28:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334330912!23042297!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY3ODA1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10953 invoked from network); 13 Apr 2012 15:28:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Apr 2012 15:28:34 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3DFSQfD024466
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Apr 2012 15:28:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3DFSP1U000445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Apr 2012 15:28:26 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3DFSPRs029775; Fri, 13 Apr 2012 10:28:25 -0500
MIME-Version: 1.0
Message-ID: <4c2f7fca-dda2-4598-aaab-3a6a3fe532cd@default>
Date: Fri, 13 Apr 2012 08:28:19 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
	<1334249132.16387.147.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334249132.16387.147.camel@zakaz.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F88461B.00AF,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > >
> 
> > Libxl_tmem_destroy may take a long time as it has to walk
> > through and free some potentially very large data structures,
> > but it is only used at domain destruction.
> 
> Should libxl_tmem_destroy be a public function or should it solely be
> called from libxl_domain_destroy? I notice that there is an xl
> tmem-destroy so I presume the former?
> 
> We might consider adding a dummy ao_how to this one I suppose.

Bearing in mind that I haven't poked around in this
code for over 2 years, I *think* the only reason tmem_destroy
needs to exist at all is if tmem is broken.  The normal domain
termination process destroys any persistent tmem pools and
any ephemeral tmem pools will eventually "age out" as the
last of the pools' pages fall off the end of the LRU.

I think the tmem_destroy functionality pre-dates the
existence of tmem "freeable" memory* and was a way for
a toolset to force the hypervisor to free up the hypervisor
memory used by some or all ephemeral tmem pools.  Once the
tmem allocation/free process was directly linked into
alloc_heap_pages() in the hypervisor (see call to
tmem_relinquish_pages()), this forcing function was
no longer needed.

So, bottom line, I *think* it can be ripped out, or at least
for now removed from the definition of the stable xl API/UI.
The libxl.c routine libxl_tmem_destroy() could also be
removed if you like, but I guess I'd prefer to leave the
lower level droppings in xc.c and in the hypervisor in case
I am misremembering.

* http://xenbits.xensource.com/hg/xen-unstable.hg/rev/03063e309356

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 15:37:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 15:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIiYd-0005OG-1C; Fri, 13 Apr 2012 15:37:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1SIiYb-0005Ny-Dy
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 15:37:05 +0000
Received: from [85.158.143.99:43291] by server-2.bemta-4.messagelabs.com id
	46/AD-17550-028488F4; Fri, 13 Apr 2012 15:37:04 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334331420!23007128!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7230 invoked from network); 13 Apr 2012 15:37:01 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 15:37:01 -0000
Received: by ghbz17 with SMTP id z17so2041571ghb.30
	for <multiple recipients>; Fri, 13 Apr 2012 08:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=BIGFoCoOI+OIjdgAGg3EMAc7vdul3OFL5O4aXjAkigQ=;
	b=T6xAXkdUGlYPpM4RAww+wcO9Qs9rssfSfxCpcGZ3XBs5C3zhZ3WVQF/2MtMJWCjEnN
	d14n+E0L0sfy9PgxuIJOM2CflaaZpbs3hBSmzhhqSPQVErOicefJ3LyxSzpyJrsIm3uX
	mxmxqRFtbhIdRbbVJxlRABdWdY8kZ1or/GBNzRdtHCQ8Xqu+yVVjneXDSJ7Wbi8DBf9N
	0Tb3EmsSoWJJDCudI/348ecDmTna6ysHDgGvwi9cSRmICVmSsNCGcGgktwnWQdKF03ud
	2Sn7tGMoCUud+KJGBIOWw29A5Q5S7wyeUeUnUN3kyRKN6Ezrkuq3S9bSfBD0NMPoQWhQ
	LRSg==
Received: by 10.50.89.233 with SMTP id br9mr2028526igb.48.1334331418830; Fri,
	13 Apr 2012 08:36:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.103.70 with HTTP; Fri, 13 Apr 2012 08:36:38 -0700 (PDT)
In-Reply-To: <1334303366.2860.4.camel@Abyss.lan>
References: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
	<1334303366.2860.4.camel@Abyss.lan>
From: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 13 Apr 2012 11:36:38 -0400
X-Google-Sender-Auth: SdwPWjlPRoKtgtNsIQCB2UXslmU
Message-ID: <CAMrPLWLg8ZTaFrqN+Gp+Qb6XEczteE+wXRuRjvBJ996gNWD=8w@mail.gmail.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: virt@lists.fedoraproject.org,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	xen-users mailing list <Xen-users@lists.xensource.com>,
	Fedora Xen List <fedora-xen@redhat.com>
Subject: Re: [Xen-devel] [Xen-users] Calling all Fedora Xen users, testers,
	and developers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 3:49 AM, Dario Faggioli <raistlin@linux.it> wrote:
> On Fri, 2012-04-06 at 13:16 -0400, Todd Deshane wrote:
>> The Fedora community is holding a virtualization test day [1] next
>> week (Thursday) and it would be great if we could help them on the Xen
>> side of things
>>
> I really agree on this... Even ex-post... :-/
>
>> Let me know if you are interested in helping out and I'll coordinated
>> the Xen efforts.
>>
> Anyway, by being on the deputed IRC channel yesterday I got the
> impression that they/we are planning another Fedora-Xen test day, is
> that the case? If yes, please follow up on us on when it will be... I'm
> not sure I can, but I'd be glad to help!

Yes, we had some testers that were unable to be available or had
troubles getting Fedora 17 itself installed, so we are hoping to get
those issues resolved and try again soon.

As soon as I hear back that the Fedora 17 install issue is resolved we
plan to try again. I'll write back to these lists and announce a new
Fedora Xen test day.

Thanks,
Todd


-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 15:37:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 15:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIiYd-0005OG-1C; Fri, 13 Apr 2012 15:37:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1SIiYb-0005Ny-Dy
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 15:37:05 +0000
Received: from [85.158.143.99:43291] by server-2.bemta-4.messagelabs.com id
	46/AD-17550-028488F4; Fri, 13 Apr 2012 15:37:04 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334331420!23007128!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7230 invoked from network); 13 Apr 2012 15:37:01 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 15:37:01 -0000
Received: by ghbz17 with SMTP id z17so2041571ghb.30
	for <multiple recipients>; Fri, 13 Apr 2012 08:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=BIGFoCoOI+OIjdgAGg3EMAc7vdul3OFL5O4aXjAkigQ=;
	b=T6xAXkdUGlYPpM4RAww+wcO9Qs9rssfSfxCpcGZ3XBs5C3zhZ3WVQF/2MtMJWCjEnN
	d14n+E0L0sfy9PgxuIJOM2CflaaZpbs3hBSmzhhqSPQVErOicefJ3LyxSzpyJrsIm3uX
	mxmxqRFtbhIdRbbVJxlRABdWdY8kZ1or/GBNzRdtHCQ8Xqu+yVVjneXDSJ7Wbi8DBf9N
	0Tb3EmsSoWJJDCudI/348ecDmTna6ysHDgGvwi9cSRmICVmSsNCGcGgktwnWQdKF03ud
	2Sn7tGMoCUud+KJGBIOWw29A5Q5S7wyeUeUnUN3kyRKN6Ezrkuq3S9bSfBD0NMPoQWhQ
	LRSg==
Received: by 10.50.89.233 with SMTP id br9mr2028526igb.48.1334331418830; Fri,
	13 Apr 2012 08:36:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.103.70 with HTTP; Fri, 13 Apr 2012 08:36:38 -0700 (PDT)
In-Reply-To: <1334303366.2860.4.camel@Abyss.lan>
References: <CAMrPLWJ2U7mVRY57EMVtY0xYxXYWmx5RVYyi9cfZ0oH3H=2NHA@mail.gmail.com>
	<1334303366.2860.4.camel@Abyss.lan>
From: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 13 Apr 2012 11:36:38 -0400
X-Google-Sender-Auth: SdwPWjlPRoKtgtNsIQCB2UXslmU
Message-ID: <CAMrPLWLg8ZTaFrqN+Gp+Qb6XEczteE+wXRuRjvBJ996gNWD=8w@mail.gmail.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: virt@lists.fedoraproject.org,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	xen-users mailing list <Xen-users@lists.xensource.com>,
	Fedora Xen List <fedora-xen@redhat.com>
Subject: Re: [Xen-devel] [Xen-users] Calling all Fedora Xen users, testers,
	and developers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 3:49 AM, Dario Faggioli <raistlin@linux.it> wrote:
> On Fri, 2012-04-06 at 13:16 -0400, Todd Deshane wrote:
>> The Fedora community is holding a virtualization test day [1] next
>> week (Thursday) and it would be great if we could help them on the Xen
>> side of things
>>
> I really agree on this... Even ex-post... :-/
>
>> Let me know if you are interested in helping out and I'll coordinated
>> the Xen efforts.
>>
> Anyway, by being on the deputed IRC channel yesterday I got the
> impression that they/we are planning another Fedora-Xen test day, is
> that the case? If yes, please follow up on us on when it will be... I'm
> not sure I can, but I'd be glad to help!

Yes, we had some testers that were unable to be available or had
troubles getting Fedora 17 itself installed, so we are hoping to get
those issues resolved and try again soon.

As soon as I hear back that the Fedora 17 install issue is resolved we
plan to try again. I'll write back to these lists and announce a new
Fedora Xen test day.

Thanks,
Todd


-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIj5K-0006br-Qx; Fri, 13 Apr 2012 16:10:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIj5I-0006bm-Tu
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:10:53 +0000
Received: from [193.109.254.147:3789] by server-8.bemta-14.messagelabs.com id
	98/5F-23244-C00588F4; Fri, 13 Apr 2012 16:10:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334333447!4505790!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23466 invoked from network); 13 Apr 2012 16:10:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 16:10:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190262862"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 12:10:46 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	12:10:46 -0400
Message-ID: <4F885005.7090605@citrix.com>
Date: Fri, 13 Apr 2012 17:10:45 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
	<4F8801DD.4030004@cantab.net>
	<4F882381020000780007DC4C@nat28.tlf.novell.com>
In-Reply-To: <4F882381020000780007DC4C@nat28.tlf.novell.com>
Cc: Sheng Yang <sheng@yasker.org>, jeremy@goop.org, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 12:00, Jan Beulich wrote:
>>>> On 13.04.12 at 12:37, David Vrabel <dvrabel@cantab.net> wrote:
>> On 13/04/12 08:56, Jan Beulich wrote:
>>>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
>>>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
>>>> timestamp jump issue as expected. Luckily, seems it also solved the call
>>>> trace and guest hang issue as well.
>>>
>>> And this is also how it should be fixed.
>>
>> Something like this?  I've not tested it yet as I need to track down
>> some of the problem hardware and get it set up.
> 
> Yeah, except that I'm not sure you really need to clear the feature
> flags. Just making sure sched_clock_stable never gets set should be
> enough; playing with the feature flags always implies that users will
> see bigger differences in /proc/cpuinfo between native and Xen
> kernels...

I have a system with both NONSTOP_TSC and CONSTANT_TSC so
sched_clock_stable should be true.  VMs start and migrate fine with no
unexpected jumps in time.  I think more digging is required here to find
out why time is screwy on this particular system.

David

>> 8<---------------
>> xen: always set the sched clock as unstable
>>
>> It's not clear to me if the Xen clock source can be used as a stable
>> sched clock. Also, even if the guest is started on a system whose
>> underying TSC is stable it may be migrated to one where it's not. So
>> never mark the sched clock as stable.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  arch/x86/xen/time.c |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 0296a95..b22cd9c 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -473,6 +473,9 @@ static void __init xen_time_init(void)
>>  	do_settimeofday(&tp);
>>
>>  	setup_force_cpu_cap(X86_FEATURE_TSC);
>> +	setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
>> +	setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
>> +	sched_clock_stable = 0;
>>
>>  	xen_setup_runstate_info(cpu);
>>  	xen_setup_timer(cpu);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIj5K-0006br-Qx; Fri, 13 Apr 2012 16:10:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIj5I-0006bm-Tu
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:10:53 +0000
Received: from [193.109.254.147:3789] by server-8.bemta-14.messagelabs.com id
	98/5F-23244-C00588F4; Fri, 13 Apr 2012 16:10:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334333447!4505790!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23466 invoked from network); 13 Apr 2012 16:10:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 16:10:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190262862"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 12:10:46 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	12:10:46 -0400
Message-ID: <4F885005.7090605@citrix.com>
Date: Fri, 13 Apr 2012 17:10:45 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
	<4F8801DD.4030004@cantab.net>
	<4F882381020000780007DC4C@nat28.tlf.novell.com>
In-Reply-To: <4F882381020000780007DC4C@nat28.tlf.novell.com>
Cc: Sheng Yang <sheng@yasker.org>, jeremy@goop.org, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 12:00, Jan Beulich wrote:
>>>> On 13.04.12 at 12:37, David Vrabel <dvrabel@cantab.net> wrote:
>> On 13/04/12 08:56, Jan Beulich wrote:
>>>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
>>>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
>>>> timestamp jump issue as expected. Luckily, seems it also solved the call
>>>> trace and guest hang issue as well.
>>>
>>> And this is also how it should be fixed.
>>
>> Something like this?  I've not tested it yet as I need to track down
>> some of the problem hardware and get it set up.
> 
> Yeah, except that I'm not sure you really need to clear the feature
> flags. Just making sure sched_clock_stable never gets set should be
> enough; playing with the feature flags always implies that users will
> see bigger differences in /proc/cpuinfo between native and Xen
> kernels...

I have a system with both NONSTOP_TSC and CONSTANT_TSC so
sched_clock_stable should be true.  VMs start and migrate fine with no
unexpected jumps in time.  I think more digging is required here to find
out why time is screwy on this particular system.

David

>> 8<---------------
>> xen: always set the sched clock as unstable
>>
>> It's not clear to me if the Xen clock source can be used as a stable
>> sched clock. Also, even if the guest is started on a system whose
>> underying TSC is stable it may be migrated to one where it's not. So
>> never mark the sched clock as stable.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  arch/x86/xen/time.c |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 0296a95..b22cd9c 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -473,6 +473,9 @@ static void __init xen_time_init(void)
>>  	do_settimeofday(&tp);
>>
>>  	setup_force_cpu_cap(X86_FEATURE_TSC);
>> +	setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
>> +	setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
>> +	sched_clock_stable = 0;
>>
>>  	xen_setup_runstate_info(cpu);
>>  	xen_setup_timer(cpu);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:12:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIj6e-0006gY-El; Fri, 13 Apr 2012 16:12:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIj6c-0006gK-7m
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:12:14 +0000
Received: from [85.158.143.99:36465] by server-1.bemta-4.messagelabs.com id
	9A/5E-20925-D50588F4; Fri, 13 Apr 2012 16:12:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334333532!23536984!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODQ4\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODQ4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16286 invoked from network); 13 Apr 2012 16:12:12 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 16:12:12 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id AE59F4B008F;
	Fri, 13 Apr 2012 09:11:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=CwxLnfcL
	ZLIYd1/GJ0cSpNDBKvPR22yXnlxsziJSBm3wWcLJ+loRqpvw5USvszYEQeI8ALfx
	07Z7zZdvFv5GCQVRSVN2vIUzeeBhzsMtYPq5tcOgf6l2J1GyTB4U5u3L8c8g5xhR
	pnxACYHHi5ZX8Vz9F/0bJU6tEJ7Se/qiBMU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	ahzh5OogQDgCyLi23qXmLOeae7c=; b=iyqps+uMaz6lpWReCf/1AiSGQSPgkML4
	kzdMk/aAd1SFYMVjDu+EoGd2yReZGxiLJQOE1Xa/ykc1Pg99qnoindJooOMbGpoX
	8t0PRoRvvLgxGyp8d7pLuoxN1bNPRDNIGr1o6CsnfWeGEd5414HceWSV3FmZRtit
	OkYscm2QsFM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 9AD694B0062; 
	Fri, 13 Apr 2012 09:11:46 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 09:11:46 -0700
Message-ID: <697daeafdd55160711d03e0c8da33359.squirrel@webmail.lagarcavilla.org>
Date: Fri, 13 Apr 2012 09:11:46 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Keir Fraser <keir.xen@gmail.com>, Tim <tim@xen.org>,
	Adin Scannell <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 0 of 3] RFC: x86 memory sharing performance
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please scratch the RFC tag. I'm done testing this and now I'm asking for
inclusion in the tree.

Thanks,
Andres

-----------------------------------------------------------------------

This is an RFC series. I haven't fully tested it yet, but I want the
concept to
be known as I intend this to be merged prior to the closing of the 4.2
window.

The sharing subsystem does not scale elegantly with high degrees of page
sharing. The culprit is a reverse map that each shared frame maintains,
resolving to all domain pages pointing to the shared frame. Because the
rmap is
implemented with a O(n) search linked-list, CoW unsharing can result in
prolonged search times.

The place where this becomes most obvious is during domain destruction,
during
which all shared p2m entries need to be unshared. Destroying a domain with a
lot of sharing could result in minutes of hypervisor freeze-up!

Solutions proposed:
- Make the p2m clean up of shared entries part of the preemptible,
synchronous,
domain_kill domctl (as opposed to executing monolithically in the finalize
destruction RCU callback)
- When a shared frame exceeds an arbitrary ref count, mutate the rmap from a
linked list to a hash table.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

xen/arch/x86/domain.c             |   16 +++-
xen/arch/x86/mm/mem_sharing.c     |   45 ++++++++++
xen/arch/x86/mm/p2m.c             |    4 +
xen/include/asm-arm/mm.h          |    4 +
xen/include/asm-x86/domain.h      |    1 +
xen/include/asm-x86/mem_sharing.h |   10 ++
xen/include/asm-x86/p2m.h         |    4 +
xen/arch/x86/mm/mem_sharing.c     |  142 +++++++++++++++++++++++--------
xen/arch/x86/mm/mem_sharing.c     |  170
+++++++++++++++++++++++++++++++++++--
xen/include/asm-x86/mem_sharing.h |   13 ++-
10 files changed, 354 insertions(+), 55 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:12:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIj6e-0006gY-El; Fri, 13 Apr 2012 16:12:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIj6c-0006gK-7m
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:12:14 +0000
Received: from [85.158.143.99:36465] by server-1.bemta-4.messagelabs.com id
	9A/5E-20925-D50588F4; Fri, 13 Apr 2012 16:12:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334333532!23536984!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODQ4\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODQ4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16286 invoked from network); 13 Apr 2012 16:12:12 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 16:12:12 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id AE59F4B008F;
	Fri, 13 Apr 2012 09:11:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=CwxLnfcL
	ZLIYd1/GJ0cSpNDBKvPR22yXnlxsziJSBm3wWcLJ+loRqpvw5USvszYEQeI8ALfx
	07Z7zZdvFv5GCQVRSVN2vIUzeeBhzsMtYPq5tcOgf6l2J1GyTB4U5u3L8c8g5xhR
	pnxACYHHi5ZX8Vz9F/0bJU6tEJ7Se/qiBMU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	ahzh5OogQDgCyLi23qXmLOeae7c=; b=iyqps+uMaz6lpWReCf/1AiSGQSPgkML4
	kzdMk/aAd1SFYMVjDu+EoGd2yReZGxiLJQOE1Xa/ykc1Pg99qnoindJooOMbGpoX
	8t0PRoRvvLgxGyp8d7pLuoxN1bNPRDNIGr1o6CsnfWeGEd5414HceWSV3FmZRtit
	OkYscm2QsFM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 9AD694B0062; 
	Fri, 13 Apr 2012 09:11:46 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 09:11:46 -0700
Message-ID: <697daeafdd55160711d03e0c8da33359.squirrel@webmail.lagarcavilla.org>
Date: Fri, 13 Apr 2012 09:11:46 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Keir Fraser <keir.xen@gmail.com>, Tim <tim@xen.org>,
	Adin Scannell <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 0 of 3] RFC: x86 memory sharing performance
	improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please scratch the RFC tag. I'm done testing this and now I'm asking for
inclusion in the tree.

Thanks,
Andres

-----------------------------------------------------------------------

This is an RFC series. I haven't fully tested it yet, but I want the
concept to
be known as I intend this to be merged prior to the closing of the 4.2
window.

The sharing subsystem does not scale elegantly with high degrees of page
sharing. The culprit is a reverse map that each shared frame maintains,
resolving to all domain pages pointing to the shared frame. Because the
rmap is
implemented with a O(n) search linked-list, CoW unsharing can result in
prolonged search times.

The place where this becomes most obvious is during domain destruction,
during
which all shared p2m entries need to be unshared. Destroying a domain with a
lot of sharing could result in minutes of hypervisor freeze-up!

Solutions proposed:
- Make the p2m clean up of shared entries part of the preemptible,
synchronous,
domain_kill domctl (as opposed to executing monolithically in the finalize
destruction RCU callback)
- When a shared frame exceeds an arbitrary ref count, mutate the rmap from a
linked list to a hash table.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

xen/arch/x86/domain.c             |   16 +++-
xen/arch/x86/mm/mem_sharing.c     |   45 ++++++++++
xen/arch/x86/mm/p2m.c             |    4 +
xen/include/asm-arm/mm.h          |    4 +
xen/include/asm-x86/domain.h      |    1 +
xen/include/asm-x86/mem_sharing.h |   10 ++
xen/include/asm-x86/p2m.h         |    4 +
xen/arch/x86/mm/mem_sharing.c     |  142 +++++++++++++++++++++++--------
xen/arch/x86/mm/mem_sharing.c     |  170
+++++++++++++++++++++++++++++++++++--
xen/include/asm-x86/mem_sharing.h |   13 ++-
10 files changed, 354 insertions(+), 55 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:15:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIj9x-0006wx-PA; Fri, 13 Apr 2012 16:15:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIj9w-0006wi-EV
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:15:40 +0000
Received: from [85.158.139.83:20501] by server-5.bemta-5.messagelabs.com id
	32/2C-13566-B21588F4; Fri, 13 Apr 2012 16:15:39 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334333738!23722092!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28504 invoked from network); 13 Apr 2012 16:15:38 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 16:15:38 -0000
Received: by bkcjg9 with SMTP id jg9so3027924bkc.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 09:15:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=KuLc2vCQyZh0eo6NG/IoSTH9nZZlfia7ibjw6qQBQFs=;
	b=e5KmUtZWkYPGMLLdtA5ttVyAz688pej77vmvfKzNxqmz4ig6Y6SsqFCVkOmsmrZaXN
	DeTd5zxjQ6Bj52O/7YSQWNPpuSSH/tgm2+mX+spwqNY6qZn9ncLdIk5lrNCVkPZlzw0O
	Y2KFZnLWr4XtBUPLWiMxAQ+6W2SwGTSB6Pb+76d+6IHaahxiWEHmfGT58kqOpiVHLThJ
	2QhYhsTFOp8UrVoAZgs7aLqfchvThUdRRruFqyhkVabNVbGXRecyXqMLq1/SsjYvGctu
	DIfHM+kcI4P4vAobD6T8u+Uh50IpboyTJNZTsMZ4qjhXnmesZ4qYASm0ESqeeZj2zT2x
	AOtA==
MIME-Version: 1.0
Received: by 10.204.154.66 with SMTP id n2mr685633bkw.77.1334333737621; Fri,
	13 Apr 2012 09:15:37 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 09:15:37 -0700 (PDT)
X-Originating-IP: [99.65.177.143]
In-Reply-To: <4F885005.7090605@citrix.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
	<4F8801DD.4030004@cantab.net>
	<4F882381020000780007DC4C@nat28.tlf.novell.com>
	<4F885005.7090605@citrix.com>
Date: Fri, 13 Apr 2012 09:15:37 -0700
Message-ID: <CA+2rt40=h3PijZ+7qmXoTtmFyd9pwWbmwNo70mcpgOJZZ50iEQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQkBucB0/HEBTGNiYCaPmXKAvCH/QPYNpxKk7Z6GSWenbE35tq78xIEFi8RF03Cm5Wy1UGmd
Cc: jeremy@goop.org, keir@xen.org, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5468194139544025516=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5468194139544025516==
Content-Type: multipart/alternative; boundary=0015175cfd887159f304bd91c81d

--0015175cfd887159f304bd91c81d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 9:10 AM, David Vrabel <david.vrabel@citrix.com>wrote:

> On 13/04/12 12:00, Jan Beulich wrote:
> >>>> On 13.04.12 at 12:37, David Vrabel <dvrabel@cantab.net> wrote:
> >> On 13/04/12 08:56, Jan Beulich wrote:
> >>>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
> >>>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
> >>>> timestamp jump issue as expected. Luckily, seems it also solved the
> call
> >>>> trace and guest hang issue as well.
> >>>
> >>> And this is also how it should be fixed.
> >>
> >> Something like this?  I've not tested it yet as I need to track down
> >> some of the problem hardware and get it set up.
> >
> > Yeah, except that I'm not sure you really need to clear the feature
> > flags. Just making sure sched_clock_stable never gets set should be
> > enough; playing with the feature flags always implies that users will
> > see bigger differences in /proc/cpuinfo between native and Xen
> > kernels...
>
> I have a system with both NONSTOP_TSC and CONSTANT_TSC so
> sched_clock_stable should be true.  VMs start and migrate fine with no
> unexpected jumps in time.  I think more digging is required here to find
> out why time is screwy on this particular system.
>

That's the reason I said there should be another (kernel) bug, triggered by
this. In the original mail, I've already said on our Sandy Bridge machine,
I can only reproduce the timestamp of printk jump issue, but not the
migration hang.

Did you see the timestamp jump on the PV guest?

--
regards
Yang, Sheng


> David
>
> >> 8<---------------
> >> xen: always set the sched clock as unstable
> >>
> >> It's not clear to me if the Xen clock source can be used as a stable
> >> sched clock. Also, even if the guest is started on a system whose
> >> underying TSC is stable it may be migrated to one where it's not. So
> >> never mark the sched clock as stable.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  arch/x86/xen/time.c |    3 +++
> >>  1 files changed, 3 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> >> index 0296a95..b22cd9c 100644
> >> --- a/arch/x86/xen/time.c
> >> +++ b/arch/x86/xen/time.c
> >> @@ -473,6 +473,9 @@ static void __init xen_time_init(void)
> >>      do_settimeofday(&tp);
> >>
> >>      setup_force_cpu_cap(X86_FEATURE_TSC);
> >> +    setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
> >> +    setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
> >> +    sched_clock_stable = 0;
> >>
> >>      xen_setup_runstate_info(cpu);
> >>      xen_setup_timer(cpu);
>

--0015175cfd887159f304bd91c81d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 9:10 AM, David Vrabel <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:david.vrabel@citrix.com">david.vrabel=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On 13/04/12 12:00, Jan Beulich wrote:<br>
&gt;&gt;&gt;&gt; On 13.04.12 at 12:37, David Vrabel &lt;<a href=3D"mailto:d=
vrabel@cantab.net">dvrabel@cantab.net</a>&gt; wrote:<br>
&gt;&gt; On 13/04/12 08:56, Jan Beulich wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt; On 12.04.12 at 21:22, Sheng Yang &lt;<a href=3D"ma=
ilto:sheng@yasker.org">sheng@yasker.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; I&#39;ve compiled a kernel, force sched_clock_stable=3D0, =
then it solved the<br>
&gt;&gt;&gt;&gt; timestamp jump issue as expected. Luckily, seems it also s=
olved the call<br>
&gt;&gt;&gt;&gt; trace and guest hang issue as well.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; And this is also how it should be fixed.<br>
&gt;&gt;<br>
&gt;&gt; Something like this? =A0I&#39;ve not tested it yet as I need to tr=
ack down<br>
&gt;&gt; some of the problem hardware and get it set up.<br>
&gt;<br>
&gt; Yeah, except that I&#39;m not sure you really need to clear the featur=
e<br>
&gt; flags. Just making sure sched_clock_stable never gets set should be<br=
>
&gt; enough; playing with the feature flags always implies that users will<=
br>
&gt; see bigger differences in /proc/cpuinfo between native and Xen<br>
&gt; kernels...<br>
<br>
</div>I have a system with both NONSTOP_TSC and CONSTANT_TSC so<br>
sched_clock_stable should be true. =A0VMs start and migrate fine with no<br=
>
unexpected jumps in time. =A0I think more digging is required here to find<=
br>
out why time is screwy on this particular system.<br></blockquote><div><br>=
</div><div>That&#39;s the reason I said there should be another (kernel) bu=
g, triggered by this. In the original mail, I&#39;ve already said on our Sa=
ndy Bridge machine, I can only reproduce the timestamp of printk jump issue=
, but not the migration hang.</div>
<div><br></div><div>Did you see the timestamp jump on the PV guest?</div><b=
r>--<div>regards</div><div>Yang, Sheng</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
David<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;&gt; 8&lt;---------------<br>
&gt;&gt; xen: always set the sched clock as unstable<br>
&gt;&gt;<br>
&gt;&gt; It&#39;s not clear to me if the Xen clock source can be used as a =
stable<br>
&gt;&gt; sched clock. Also, even if the guest is started on a system whose<=
br>
&gt;&gt; underying TSC is stable it may be migrated to one where it&#39;s n=
ot. So<br>
&gt;&gt; never mark the sched clock as stable.<br>
&gt;&gt;<br>
&gt;&gt; Signed-off-by: David Vrabel &lt;<a href=3D"mailto:david.vrabel@cit=
rix.com">david.vrabel@citrix.com</a>&gt;<br>
&gt;&gt; ---<br>
&gt;&gt; =A0arch/x86/xen/time.c | =A0 =A03 +++<br>
&gt;&gt; =A01 files changed, 3 insertions(+), 0 deletions(-)<br>
&gt;&gt;<br>
&gt;&gt; diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c<br>
&gt;&gt; index 0296a95..b22cd9c 100644<br>
&gt;&gt; --- a/arch/x86/xen/time.c<br>
&gt;&gt; +++ b/arch/x86/xen/time.c<br>
&gt;&gt; @@ -473,6 +473,9 @@ static void __init xen_time_init(void)<br>
&gt;&gt; =A0 =A0 =A0do_settimeofday(&amp;tp);<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0setup_force_cpu_cap(X86_FEATURE_TSC);<br>
&gt;&gt; + =A0 =A0setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);<br>
&gt;&gt; + =A0 =A0setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);<br>
&gt;&gt; + =A0 =A0sched_clock_stable =3D 0;<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0xen_setup_runstate_info(cpu);<br>
&gt;&gt; =A0 =A0 =A0xen_setup_timer(cpu);<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div><br>

--0015175cfd887159f304bd91c81d--


--===============5468194139544025516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5468194139544025516==--


From xen-devel-bounces@lists.xen.org Fri Apr 13 16:15:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIj9x-0006wx-PA; Fri, 13 Apr 2012 16:15:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIj9w-0006wi-EV
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:15:40 +0000
Received: from [85.158.139.83:20501] by server-5.bemta-5.messagelabs.com id
	32/2C-13566-B21588F4; Fri, 13 Apr 2012 16:15:39 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334333738!23722092!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28504 invoked from network); 13 Apr 2012 16:15:38 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 16:15:38 -0000
Received: by bkcjg9 with SMTP id jg9so3027924bkc.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 09:15:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=KuLc2vCQyZh0eo6NG/IoSTH9nZZlfia7ibjw6qQBQFs=;
	b=e5KmUtZWkYPGMLLdtA5ttVyAz688pej77vmvfKzNxqmz4ig6Y6SsqFCVkOmsmrZaXN
	DeTd5zxjQ6Bj52O/7YSQWNPpuSSH/tgm2+mX+spwqNY6qZn9ncLdIk5lrNCVkPZlzw0O
	Y2KFZnLWr4XtBUPLWiMxAQ+6W2SwGTSB6Pb+76d+6IHaahxiWEHmfGT58kqOpiVHLThJ
	2QhYhsTFOp8UrVoAZgs7aLqfchvThUdRRruFqyhkVabNVbGXRecyXqMLq1/SsjYvGctu
	DIfHM+kcI4P4vAobD6T8u+Uh50IpboyTJNZTsMZ4qjhXnmesZ4qYASm0ESqeeZj2zT2x
	AOtA==
MIME-Version: 1.0
Received: by 10.204.154.66 with SMTP id n2mr685633bkw.77.1334333737621; Fri,
	13 Apr 2012 09:15:37 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 09:15:37 -0700 (PDT)
X-Originating-IP: [99.65.177.143]
In-Reply-To: <4F885005.7090605@citrix.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
	<4F8801DD.4030004@cantab.net>
	<4F882381020000780007DC4C@nat28.tlf.novell.com>
	<4F885005.7090605@citrix.com>
Date: Fri, 13 Apr 2012 09:15:37 -0700
Message-ID: <CA+2rt40=h3PijZ+7qmXoTtmFyd9pwWbmwNo70mcpgOJZZ50iEQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQkBucB0/HEBTGNiYCaPmXKAvCH/QPYNpxKk7Z6GSWenbE35tq78xIEFi8RF03Cm5Wy1UGmd
Cc: jeremy@goop.org, keir@xen.org, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5468194139544025516=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5468194139544025516==
Content-Type: multipart/alternative; boundary=0015175cfd887159f304bd91c81d

--0015175cfd887159f304bd91c81d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 9:10 AM, David Vrabel <david.vrabel@citrix.com>wrote:

> On 13/04/12 12:00, Jan Beulich wrote:
> >>>> On 13.04.12 at 12:37, David Vrabel <dvrabel@cantab.net> wrote:
> >> On 13/04/12 08:56, Jan Beulich wrote:
> >>>>>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
> >>>> I've compiled a kernel, force sched_clock_stable=0, then it solved the
> >>>> timestamp jump issue as expected. Luckily, seems it also solved the
> call
> >>>> trace and guest hang issue as well.
> >>>
> >>> And this is also how it should be fixed.
> >>
> >> Something like this?  I've not tested it yet as I need to track down
> >> some of the problem hardware and get it set up.
> >
> > Yeah, except that I'm not sure you really need to clear the feature
> > flags. Just making sure sched_clock_stable never gets set should be
> > enough; playing with the feature flags always implies that users will
> > see bigger differences in /proc/cpuinfo between native and Xen
> > kernels...
>
> I have a system with both NONSTOP_TSC and CONSTANT_TSC so
> sched_clock_stable should be true.  VMs start and migrate fine with no
> unexpected jumps in time.  I think more digging is required here to find
> out why time is screwy on this particular system.
>

That's the reason I said there should be another (kernel) bug, triggered by
this. In the original mail, I've already said on our Sandy Bridge machine,
I can only reproduce the timestamp of printk jump issue, but not the
migration hang.

Did you see the timestamp jump on the PV guest?

--
regards
Yang, Sheng


> David
>
> >> 8<---------------
> >> xen: always set the sched clock as unstable
> >>
> >> It's not clear to me if the Xen clock source can be used as a stable
> >> sched clock. Also, even if the guest is started on a system whose
> >> underying TSC is stable it may be migrated to one where it's not. So
> >> never mark the sched clock as stable.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  arch/x86/xen/time.c |    3 +++
> >>  1 files changed, 3 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> >> index 0296a95..b22cd9c 100644
> >> --- a/arch/x86/xen/time.c
> >> +++ b/arch/x86/xen/time.c
> >> @@ -473,6 +473,9 @@ static void __init xen_time_init(void)
> >>      do_settimeofday(&tp);
> >>
> >>      setup_force_cpu_cap(X86_FEATURE_TSC);
> >> +    setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);
> >> +    setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);
> >> +    sched_clock_stable = 0;
> >>
> >>      xen_setup_runstate_info(cpu);
> >>      xen_setup_timer(cpu);
>

--0015175cfd887159f304bd91c81d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 9:10 AM, David Vrabel <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:david.vrabel@citrix.com">david.vrabel=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On 13/04/12 12:00, Jan Beulich wrote:<br>
&gt;&gt;&gt;&gt; On 13.04.12 at 12:37, David Vrabel &lt;<a href=3D"mailto:d=
vrabel@cantab.net">dvrabel@cantab.net</a>&gt; wrote:<br>
&gt;&gt; On 13/04/12 08:56, Jan Beulich wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt; On 12.04.12 at 21:22, Sheng Yang &lt;<a href=3D"ma=
ilto:sheng@yasker.org">sheng@yasker.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; I&#39;ve compiled a kernel, force sched_clock_stable=3D0, =
then it solved the<br>
&gt;&gt;&gt;&gt; timestamp jump issue as expected. Luckily, seems it also s=
olved the call<br>
&gt;&gt;&gt;&gt; trace and guest hang issue as well.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; And this is also how it should be fixed.<br>
&gt;&gt;<br>
&gt;&gt; Something like this? =A0I&#39;ve not tested it yet as I need to tr=
ack down<br>
&gt;&gt; some of the problem hardware and get it set up.<br>
&gt;<br>
&gt; Yeah, except that I&#39;m not sure you really need to clear the featur=
e<br>
&gt; flags. Just making sure sched_clock_stable never gets set should be<br=
>
&gt; enough; playing with the feature flags always implies that users will<=
br>
&gt; see bigger differences in /proc/cpuinfo between native and Xen<br>
&gt; kernels...<br>
<br>
</div>I have a system with both NONSTOP_TSC and CONSTANT_TSC so<br>
sched_clock_stable should be true. =A0VMs start and migrate fine with no<br=
>
unexpected jumps in time. =A0I think more digging is required here to find<=
br>
out why time is screwy on this particular system.<br></blockquote><div><br>=
</div><div>That&#39;s the reason I said there should be another (kernel) bu=
g, triggered by this. In the original mail, I&#39;ve already said on our Sa=
ndy Bridge machine, I can only reproduce the timestamp of printk jump issue=
, but not the migration hang.</div>
<div><br></div><div>Did you see the timestamp jump on the PV guest?</div><b=
r>--<div>regards</div><div>Yang, Sheng</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
David<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;&gt; 8&lt;---------------<br>
&gt;&gt; xen: always set the sched clock as unstable<br>
&gt;&gt;<br>
&gt;&gt; It&#39;s not clear to me if the Xen clock source can be used as a =
stable<br>
&gt;&gt; sched clock. Also, even if the guest is started on a system whose<=
br>
&gt;&gt; underying TSC is stable it may be migrated to one where it&#39;s n=
ot. So<br>
&gt;&gt; never mark the sched clock as stable.<br>
&gt;&gt;<br>
&gt;&gt; Signed-off-by: David Vrabel &lt;<a href=3D"mailto:david.vrabel@cit=
rix.com">david.vrabel@citrix.com</a>&gt;<br>
&gt;&gt; ---<br>
&gt;&gt; =A0arch/x86/xen/time.c | =A0 =A03 +++<br>
&gt;&gt; =A01 files changed, 3 insertions(+), 0 deletions(-)<br>
&gt;&gt;<br>
&gt;&gt; diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c<br>
&gt;&gt; index 0296a95..b22cd9c 100644<br>
&gt;&gt; --- a/arch/x86/xen/time.c<br>
&gt;&gt; +++ b/arch/x86/xen/time.c<br>
&gt;&gt; @@ -473,6 +473,9 @@ static void __init xen_time_init(void)<br>
&gt;&gt; =A0 =A0 =A0do_settimeofday(&amp;tp);<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0setup_force_cpu_cap(X86_FEATURE_TSC);<br>
&gt;&gt; + =A0 =A0setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC);<br>
&gt;&gt; + =A0 =A0setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC);<br>
&gt;&gt; + =A0 =A0sched_clock_stable =3D 0;<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0xen_setup_runstate_info(cpu);<br>
&gt;&gt; =A0 =A0 =A0xen_setup_timer(cpu);<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div><br>

--0015175cfd887159f304bd91c81d--


--===============5468194139544025516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5468194139544025516==--


From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBw-0007Ab-9c; Fri, 13 Apr 2012 16:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBv-0007AN-8J
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:43 +0000
Received: from [85.158.143.35:25713] by server-1.bemta-4.messagelabs.com id
	A8/C3-20925-6A1588F4; Fri, 13 Apr 2012 16:17:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334333861!18508911!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0MTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30610 invoked from network); 13 Apr 2012 16:17:42 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-15.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 706C77EC064;
	Fri, 13 Apr 2012 09:17:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=WdQYl3lgvMNOc4kzSMG2g6
	TFydg3uNzx9e0HkneBKKR01XvOTS3nNRjb6+JBF14WTrmSYJEoV3V8v23AmFAwV6
	wqJeo6hoCBh0N/IPCoiYRCBgChDWvxLtKJaVEU2FssbhijEznn4BU+DgsOK7IerS
	6C0Cl4qeV8Z8HsRcB4QM0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=isGv8R3USz8+
	Lyim4HyyEQ+ts7A=; b=YPl7XY20w18be+tTHBFaNTa9O1SnC+EiUdBHAbV2qfuv
	OV8AG1ssSeT+Yp848XJdwPAccFGj1JLgVAvFhk9XE8D3/rtZhd+ihb3NqtMEgsuD
	cwk5grxxzvLyAgQPXw2lhK64khLwQ+G4oo5cxnXlANgwFttjWtABEFMgKOjBG4M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 01DEE7EC065; 
	Fri, 13 Apr 2012 09:17:39 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:18 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 6] x86/mm/shadow: fixes and synchronized
	p2m lookups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow shadow page tables to take advantage of synchronized p2m lookups. This
required a number of deadlock fixes building up to enabling of this feature.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mm-locks.h      |   3 +++
 xen/arch/x86/mm/shadow/multi.c  |   3 ++-
 xen/arch/x86/mm/shadow/multi.c  |  25 +++++++++++++++++++++++++
 xen/arch/x86/mm/shadow/common.c |   4 ++++
 xen/arch/x86/mm/shadow/multi.c  |  13 +++++++++++--
 xen/arch/x86/mm/p2m.c           |   5 ++---
 6 files changed, 47 insertions(+), 6 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBw-0007Ab-9c; Fri, 13 Apr 2012 16:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBv-0007AN-8J
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:43 +0000
Received: from [85.158.143.35:25713] by server-1.bemta-4.messagelabs.com id
	A8/C3-20925-6A1588F4; Fri, 13 Apr 2012 16:17:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334333861!18508911!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0MTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30610 invoked from network); 13 Apr 2012 16:17:42 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-15.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 706C77EC064;
	Fri, 13 Apr 2012 09:17:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=WdQYl3lgvMNOc4kzSMG2g6
	TFydg3uNzx9e0HkneBKKR01XvOTS3nNRjb6+JBF14WTrmSYJEoV3V8v23AmFAwV6
	wqJeo6hoCBh0N/IPCoiYRCBgChDWvxLtKJaVEU2FssbhijEznn4BU+DgsOK7IerS
	6C0Cl4qeV8Z8HsRcB4QM0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=isGv8R3USz8+
	Lyim4HyyEQ+ts7A=; b=YPl7XY20w18be+tTHBFaNTa9O1SnC+EiUdBHAbV2qfuv
	OV8AG1ssSeT+Yp848XJdwPAccFGj1JLgVAvFhk9XE8D3/rtZhd+ihb3NqtMEgsuD
	cwk5grxxzvLyAgQPXw2lhK64khLwQ+G4oo5cxnXlANgwFttjWtABEFMgKOjBG4M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 01DEE7EC065; 
	Fri, 13 Apr 2012 09:17:39 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:18 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 6] x86/mm/shadow: fixes and synchronized
	p2m lookups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow shadow page tables to take advantage of synchronized p2m lookups. This
required a number of deadlock fixes building up to enabling of this feature.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mm-locks.h      |   3 +++
 xen/arch/x86/mm/shadow/multi.c  |   3 ++-
 xen/arch/x86/mm/shadow/multi.c  |  25 +++++++++++++++++++++++++
 xen/arch/x86/mm/shadow/common.c |   4 ++++
 xen/arch/x86/mm/shadow/multi.c  |  13 +++++++++++--
 xen/arch/x86/mm/p2m.c           |   5 ++---
 6 files changed, 47 insertions(+), 6 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBz-0007C0-QZ; Fri, 13 Apr 2012 16:17:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBx-0007AP-O0
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:45 +0000
Received: from [85.158.143.35:27853] by server-2.bemta-4.messagelabs.com id
	02/38-17550-9A1588F4; Fri, 13 Apr 2012 16:17:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334333862!8740690!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjUxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31517 invoked from network); 13 Apr 2012 16:17:44 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-16.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:44 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 37BD77EC07B;
	Fri, 13 Apr 2012 09:17:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=eT0cFlk8E3GzoEqmR4Epucb8bg0yrCjVQXhnLuLHpK0v
	wnfx6Dy3pK9QvBvXGtmtoEM3NjETb3DE2sGiWZ+jUn9tNeB6bTPmieLjdASpjBaZ
	DtphSR/JamzI1jWJKxw6eZpny5YleZKLyNudpYUp/sOSRxrvrOcyLaIYJpd/D+o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6C0QEk6FP2wRupFuY+JvMrQvOpI=; b=minaH3tJ8Lg
	v7/LnNGvw6lvAu3vNYotg5Ceyp2QmqfPyz9Nip3aa5hxwCZ3YSMSe4S/+C4KmoEL
	92UHG+kvq1t5g9Md7ZU5hj5SAEFolKDzHIjCPuEG/LVHExD5tzAw8lT0uwX8qa7h
	JmCAtJtuRDdFjncLkk7rrc4/15reCS4s=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id BE2257EC064; 
	Fri, 13 Apr 2012 09:17:43 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1d8566a0564208e64bb2cbd50255b285d48e8d34
Message-Id: <1d8566a0564208e64bb2.1334334143@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:23 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 5 of 6] x86/mm/shadow: fix p2m/paging deadlock
 when updating shadow cr3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/multi.c |  13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a7ca6ae73992 -r 1d8566a05642 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4190,7 +4190,12 @@ sh_update_cr3(struct vcpu *v, int do_loc
         return;
     }
 
-    if ( do_locking ) paging_lock(v->domain);
+    if ( do_locking ) 
+    {
+        /* See comment in shadow_update_paging_modes. */
+        p2m_lock(p2m_get_hostp2m(v->domain));
+        paging_lock(v->domain);
+    }
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     /* Need to resync all the shadow entries on a TLB flush.  Resync
@@ -4434,7 +4439,11 @@ sh_update_cr3(struct vcpu *v, int do_loc
 #endif
 
     /* Release the lock, if we took it (otherwise it's the caller's problem) */
-    if ( do_locking ) paging_unlock(v->domain);
+    if ( do_locking )
+    {
+        paging_unlock(v->domain);
+        p2m_unlock(p2m_get_hostp2m(v->domain));
+    }
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBz-0007C0-QZ; Fri, 13 Apr 2012 16:17:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBx-0007AP-O0
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:45 +0000
Received: from [85.158.143.35:27853] by server-2.bemta-4.messagelabs.com id
	02/38-17550-9A1588F4; Fri, 13 Apr 2012 16:17:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334333862!8740690!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjUxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31517 invoked from network); 13 Apr 2012 16:17:44 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-16.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:44 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 37BD77EC07B;
	Fri, 13 Apr 2012 09:17:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=eT0cFlk8E3GzoEqmR4Epucb8bg0yrCjVQXhnLuLHpK0v
	wnfx6Dy3pK9QvBvXGtmtoEM3NjETb3DE2sGiWZ+jUn9tNeB6bTPmieLjdASpjBaZ
	DtphSR/JamzI1jWJKxw6eZpny5YleZKLyNudpYUp/sOSRxrvrOcyLaIYJpd/D+o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6C0QEk6FP2wRupFuY+JvMrQvOpI=; b=minaH3tJ8Lg
	v7/LnNGvw6lvAu3vNYotg5Ceyp2QmqfPyz9Nip3aa5hxwCZ3YSMSe4S/+C4KmoEL
	92UHG+kvq1t5g9Md7ZU5hj5SAEFolKDzHIjCPuEG/LVHExD5tzAw8lT0uwX8qa7h
	JmCAtJtuRDdFjncLkk7rrc4/15reCS4s=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id BE2257EC064; 
	Fri, 13 Apr 2012 09:17:43 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1d8566a0564208e64bb2cbd50255b285d48e8d34
Message-Id: <1d8566a0564208e64bb2.1334334143@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:23 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 5 of 6] x86/mm/shadow: fix p2m/paging deadlock
 when updating shadow cr3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/multi.c |  13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a7ca6ae73992 -r 1d8566a05642 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4190,7 +4190,12 @@ sh_update_cr3(struct vcpu *v, int do_loc
         return;
     }
 
-    if ( do_locking ) paging_lock(v->domain);
+    if ( do_locking ) 
+    {
+        /* See comment in shadow_update_paging_modes. */
+        p2m_lock(p2m_get_hostp2m(v->domain));
+        paging_lock(v->domain);
+    }
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     /* Need to resync all the shadow entries on a TLB flush.  Resync
@@ -4434,7 +4439,11 @@ sh_update_cr3(struct vcpu *v, int do_loc
 #endif
 
     /* Release the lock, if we took it (otherwise it's the caller's problem) */
-    if ( do_locking ) paging_unlock(v->domain);
+    if ( do_locking )
+    {
+        paging_unlock(v->domain);
+        p2m_unlock(p2m_get_hostp2m(v->domain));
+    }
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBz-0007Bm-Ej; Fri, 13 Apr 2012 16:17:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBx-0007B2-Hk
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:45 +0000
Received: from [85.158.139.83:28266] by server-7.bemta-5.messagelabs.com id
	9E/25-16195-8A1588F4; Fri, 13 Apr 2012 16:17:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334333863!19844402!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2MjA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16822 invoked from network); 13 Apr 2012 16:17:43 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-6.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 16:17:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D4D007EC076;
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Jxo3iHsPntXYcFvJfSEgWncu9VqtvKWny0A7TRSkVO59
	tyLGH6Lt7PHBL/zXsp8msQOdBWtnqUNg0H6M+PdjZvAvY33BxC5/MVqDzZ4FM1Ls
	GKyUggWFsHHE4hxxXiZtOOzz5QJ5DXh3IIQczBTvx8orKvxHyVnG5B+hWxQP6vA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=cd8d48Kiw7TBfLdFlnaTDYYTi4I=; b=cXX3jrWZ7re
	d74MVvHp4dqBUIkFX0kykjFsBK0ytAI2SH6/7AqiQIThEY/14FCppEd3oMbQo0cC
	OuZReO10MKj+9LrMbpafrRykJCHAqZPN+wCzl2I+fucQc06+W321W/f2IM6F0G6S
	7KsuTj9c9bTPQgP/q+96gvYByqHjhmnk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 6A8577EC064; 
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 964c6cbad92639029f4a439b754f0eb8e6ee45e7
Message-Id: <964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential p2m/paging
 deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/multi.c |  25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f8fd4a4239a8 -r 964c6cbad926 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -5033,9 +5033,21 @@ sh_x86_emulate_write(struct vcpu *v, uns
     if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
         return X86EMUL_UNHANDLEABLE;
 
+    /* To prevent a shadow mode deadlock, we need to hold the p2m from here
+     * onwards. emulate_unmap_dest may need to verify the pte that is being
+     * written to here, and thus get_gfn on the gfn contained in the payload
+     * that is being written here. p2m_lock is recursive, so all is well on
+     * that regard. Further, holding the p2m lock ensures the page table gfn
+     * being written to won't go away (although that could be achieved with
+     * a page reference, as done elsewhere).
+     */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
     if ( emulate_map_dest_failed(addr) )
+    {
+        p2m_unlock(p2m_get_hostp2m(v->domain));
         return (long)addr;
+    }
 
     paging_lock(v->domain);
     memcpy(addr, src, bytes);
@@ -5059,6 +5071,7 @@ sh_x86_emulate_write(struct vcpu *v, uns
     emulate_unmap_dest(v, addr, bytes, sh_ctxt);
     shadow_audit_tables(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
     return X86EMUL_OKAY;
 }
 
@@ -5075,9 +5088,14 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
     if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
         return X86EMUL_UNHANDLEABLE;
 
+    /* see comment in sh_x86_emulate_write. */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
     if ( emulate_map_dest_failed(addr) )
+    {
+        p2m_unlock(p2m_get_hostp2m(v->domain));
         return (long)addr;
+    }
 
     paging_lock(v->domain);
     switch ( bytes )
@@ -5101,6 +5119,7 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
     emulate_unmap_dest(v, addr, bytes, sh_ctxt);
     shadow_audit_tables(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
     return rv;
 }
 
@@ -5119,9 +5138,14 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
     if ( (vaddr & 7) && !is_hvm_vcpu(v) )
         return X86EMUL_UNHANDLEABLE;
 
+    /* see comment in sh_x86_emulate_write. */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     addr = emulate_map_dest(v, vaddr, 8, sh_ctxt);
     if ( emulate_map_dest_failed(addr) )
+    {
+        p2m_unlock(p2m_get_hostp2m(v->domain));
         return (long)addr;
+    }
 
     old = (((u64) old_hi) << 32) | (u64) old_lo;
     new = (((u64) new_hi) << 32) | (u64) new_lo;
@@ -5135,6 +5159,7 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
     emulate_unmap_dest(v, addr, 8, sh_ctxt);
     shadow_audit_tables(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
     return rv;
 }
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBz-0007Bm-Ej; Fri, 13 Apr 2012 16:17:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBx-0007B2-Hk
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:45 +0000
Received: from [85.158.139.83:28266] by server-7.bemta-5.messagelabs.com id
	9E/25-16195-8A1588F4; Fri, 13 Apr 2012 16:17:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334333863!19844402!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2MjA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16822 invoked from network); 13 Apr 2012 16:17:43 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-6.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 16:17:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D4D007EC076;
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Jxo3iHsPntXYcFvJfSEgWncu9VqtvKWny0A7TRSkVO59
	tyLGH6Lt7PHBL/zXsp8msQOdBWtnqUNg0H6M+PdjZvAvY33BxC5/MVqDzZ4FM1Ls
	GKyUggWFsHHE4hxxXiZtOOzz5QJ5DXh3IIQczBTvx8orKvxHyVnG5B+hWxQP6vA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=cd8d48Kiw7TBfLdFlnaTDYYTi4I=; b=cXX3jrWZ7re
	d74MVvHp4dqBUIkFX0kykjFsBK0ytAI2SH6/7AqiQIThEY/14FCppEd3oMbQo0cC
	OuZReO10MKj+9LrMbpafrRykJCHAqZPN+wCzl2I+fucQc06+W321W/f2IM6F0G6S
	7KsuTj9c9bTPQgP/q+96gvYByqHjhmnk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 6A8577EC064; 
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 964c6cbad92639029f4a439b754f0eb8e6ee45e7
Message-Id: <964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential p2m/paging
 deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/multi.c |  25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f8fd4a4239a8 -r 964c6cbad926 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -5033,9 +5033,21 @@ sh_x86_emulate_write(struct vcpu *v, uns
     if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
         return X86EMUL_UNHANDLEABLE;
 
+    /* To prevent a shadow mode deadlock, we need to hold the p2m from here
+     * onwards. emulate_unmap_dest may need to verify the pte that is being
+     * written to here, and thus get_gfn on the gfn contained in the payload
+     * that is being written here. p2m_lock is recursive, so all is well on
+     * that regard. Further, holding the p2m lock ensures the page table gfn
+     * being written to won't go away (although that could be achieved with
+     * a page reference, as done elsewhere).
+     */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
     if ( emulate_map_dest_failed(addr) )
+    {
+        p2m_unlock(p2m_get_hostp2m(v->domain));
         return (long)addr;
+    }
 
     paging_lock(v->domain);
     memcpy(addr, src, bytes);
@@ -5059,6 +5071,7 @@ sh_x86_emulate_write(struct vcpu *v, uns
     emulate_unmap_dest(v, addr, bytes, sh_ctxt);
     shadow_audit_tables(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
     return X86EMUL_OKAY;
 }
 
@@ -5075,9 +5088,14 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
     if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
         return X86EMUL_UNHANDLEABLE;
 
+    /* see comment in sh_x86_emulate_write. */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
     if ( emulate_map_dest_failed(addr) )
+    {
+        p2m_unlock(p2m_get_hostp2m(v->domain));
         return (long)addr;
+    }
 
     paging_lock(v->domain);
     switch ( bytes )
@@ -5101,6 +5119,7 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
     emulate_unmap_dest(v, addr, bytes, sh_ctxt);
     shadow_audit_tables(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
     return rv;
 }
 
@@ -5119,9 +5138,14 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
     if ( (vaddr & 7) && !is_hvm_vcpu(v) )
         return X86EMUL_UNHANDLEABLE;
 
+    /* see comment in sh_x86_emulate_write. */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     addr = emulate_map_dest(v, vaddr, 8, sh_ctxt);
     if ( emulate_map_dest_failed(addr) )
+    {
+        p2m_unlock(p2m_get_hostp2m(v->domain));
         return (long)addr;
+    }
 
     old = (((u64) old_hi) << 32) | (u64) old_lo;
     new = (((u64) new_hi) << 32) | (u64) new_lo;
@@ -5135,6 +5159,7 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
     emulate_unmap_dest(v, addr, 8, sh_ctxt);
     shadow_audit_tables(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
     return rv;
 }
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjC0-0007Cc-Pv; Fri, 13 Apr 2012 16:17:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBz-0007Bb-3x
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:47 +0000
Received: from [85.158.143.99:61489] by server-3.bemta-4.messagelabs.com id
	5E/39-05853-AA1588F4; Fri, 13 Apr 2012 16:17:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334333865!13912672!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODEzNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30965 invoked from network); 13 Apr 2012 16:17:45 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-14.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 16:17:45 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id F2D577EC078;
	Fri, 13 Apr 2012 09:17:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=BJF+aogYCLjEFMP1i7fqwx0ENVAuOuJlFa1xM1wYItUz
	UBQBYJvjAAIL5XH7JW0R1mJ/92Pr/KQV9D46NDy8AMkaFBBWD6ILc2yAm9ERdXbO
	m2KRlo3y9IJwTtucBYeyZTijXif6lKWDgCoedLwhVeI3nTEv9ee+nZdRYQAxHHI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=RKkb/R9FJvHw9ppbb8nFZ/ppI2Q=; b=VQd4JsWvTQJ
	nkHsFWM7z/BKM4Y1aLz2XjOk+Fm57bZsZy5J6dQhdQpPv+zpuv/e0zV6+X2dP6dY
	1dDIm5LuEGB6tVYEqtMUsswQorM+3tnRn2HTiMU6Wu5P/X07ASxFNHGFX4yyyYce
	LyNrhk4N+y2Ggjw8R2RqRLibRBDwIjvs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 72CAA7EC076; 
	Fri, 13 Apr 2012 09:17:44 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8ec52231c03d91842d6bf4005d9ba099d2a8e761
Message-Id: <8ec52231c03d91842d6b.1334334144@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:24 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 6 of 6] x86/mm: Locking p2m lookups in shadow
	mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/p2m.c |  5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)


Fully synchronized p2m lookups have been added to hap already. Enable that for
shadow mode as well.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1d8566a05642 -r 8ec52231c03d xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -164,7 +164,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     }
 
     /* For now only perform locking on hap domains */
-    if ( locked && (hap_enabled(p2m->domain)) )
+    if ( locked )
         /* Grab the lock here, don't release until put_gfn */
         gfn_lock(p2m, gfn, 0);
 
@@ -197,8 +197,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
 
 void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
 {
-    if ( !p2m || !paging_mode_translate(p2m->domain) 
-              || !hap_enabled(p2m->domain) )
+    if ( !p2m || !paging_mode_translate(p2m->domain) )
         /* Nothing to do in this case */
         return;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBy-0007BF-1r; Fri, 13 Apr 2012 16:17:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBw-0007AN-Jx
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:44 +0000
Received: from [85.158.143.35:25809] by server-1.bemta-4.messagelabs.com id
	5E/C3-20925-8A1588F4; Fri, 13 Apr 2012 16:17:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334333862!8740690!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjUxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31410 invoked from network); 13 Apr 2012 16:17:43 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-16.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 252327EC07B;
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vSJ5z4jDjLaOdK6YF6LIj7HGydappNH8xduPj33CJ46U
	IsjA3JvdGZAlNI+CFWKIAkD8Tbn9/JI1EY62iRERVZAKLlXHorHc8vgD/ZpByGJV
	GMq+Pvxm4SzABFC1DrsgC5sV67LgDkTDLdEgBVSuOvnLLfYBEwGYR9zbt7z71EA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=07o5/ITyEt3HEz+UaLUPTBpamVY=; b=cGJTn6kv/gW
	Gyz7z4n8rp78s452MgpXbGxzC1BadH8T9xtQCZO69xAVbVQNHRb7bxIg1n0QtJdE
	/Jg0QB8tPjm6LqvY288ngZAE88H8Fty3p2j+UVWPfEEoUXFc0roQoZVuQPc1Q3NQ
	TOq1tC1VKwOXtuubWLSXscoaKGnLebeI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 67FB97EC076; 
	Fri, 13 Apr 2012 09:17:41 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f8fd4a4239a8aa7e25e5a91fd5485bf7844f09cc
Message-Id: <f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 6] x86/mm/shadow: enclose an OOS function
 in the proper conditional ifdef
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/multi.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


Otherwise compilation fails if the feature is disabled.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r aa4ef559da60 -r f8fd4a4239a8 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -248,6 +248,7 @@ shadow_check_gwalk(struct vcpu *v, unsig
     return !mismatch;
 }
 
+#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 static int
 shadow_check_gl1e(struct vcpu *v, walk_t *gw)
 {
@@ -263,7 +264,7 @@ shadow_check_gl1e(struct vcpu *v, walk_t
 
     return gw->l1e.l1 != nl1e.l1;
 }
-
+#endif
 
 /* Remove write access permissions from a gwalk_t in a batch, and
  * return OR-ed result for TLB flush hint and need to rewalk the guest

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjC0-0007Cc-Pv; Fri, 13 Apr 2012 16:17:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBz-0007Bb-3x
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:47 +0000
Received: from [85.158.143.99:61489] by server-3.bemta-4.messagelabs.com id
	5E/39-05853-AA1588F4; Fri, 13 Apr 2012 16:17:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334333865!13912672!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODEzNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30965 invoked from network); 13 Apr 2012 16:17:45 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-14.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 16:17:45 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id F2D577EC078;
	Fri, 13 Apr 2012 09:17:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=BJF+aogYCLjEFMP1i7fqwx0ENVAuOuJlFa1xM1wYItUz
	UBQBYJvjAAIL5XH7JW0R1mJ/92Pr/KQV9D46NDy8AMkaFBBWD6ILc2yAm9ERdXbO
	m2KRlo3y9IJwTtucBYeyZTijXif6lKWDgCoedLwhVeI3nTEv9ee+nZdRYQAxHHI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=RKkb/R9FJvHw9ppbb8nFZ/ppI2Q=; b=VQd4JsWvTQJ
	nkHsFWM7z/BKM4Y1aLz2XjOk+Fm57bZsZy5J6dQhdQpPv+zpuv/e0zV6+X2dP6dY
	1dDIm5LuEGB6tVYEqtMUsswQorM+3tnRn2HTiMU6Wu5P/X07ASxFNHGFX4yyyYce
	LyNrhk4N+y2Ggjw8R2RqRLibRBDwIjvs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 72CAA7EC076; 
	Fri, 13 Apr 2012 09:17:44 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8ec52231c03d91842d6bf4005d9ba099d2a8e761
Message-Id: <8ec52231c03d91842d6b.1334334144@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:24 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 6 of 6] x86/mm: Locking p2m lookups in shadow
	mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/p2m.c |  5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)


Fully synchronized p2m lookups have been added to hap already. Enable that for
shadow mode as well.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1d8566a05642 -r 8ec52231c03d xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -164,7 +164,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     }
 
     /* For now only perform locking on hap domains */
-    if ( locked && (hap_enabled(p2m->domain)) )
+    if ( locked )
         /* Grab the lock here, don't release until put_gfn */
         gfn_lock(p2m, gfn, 0);
 
@@ -197,8 +197,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
 
 void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
 {
-    if ( !p2m || !paging_mode_translate(p2m->domain) 
-              || !hap_enabled(p2m->domain) )
+    if ( !p2m || !paging_mode_translate(p2m->domain) )
         /* Nothing to do in this case */
         return;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBy-0007BF-1r; Fri, 13 Apr 2012 16:17:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBw-0007AN-Jx
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:44 +0000
Received: from [85.158.143.35:25809] by server-1.bemta-4.messagelabs.com id
	5E/C3-20925-8A1588F4; Fri, 13 Apr 2012 16:17:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334333862!8740690!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjUxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31410 invoked from network); 13 Apr 2012 16:17:43 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-16.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 252327EC07B;
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vSJ5z4jDjLaOdK6YF6LIj7HGydappNH8xduPj33CJ46U
	IsjA3JvdGZAlNI+CFWKIAkD8Tbn9/JI1EY62iRERVZAKLlXHorHc8vgD/ZpByGJV
	GMq+Pvxm4SzABFC1DrsgC5sV67LgDkTDLdEgBVSuOvnLLfYBEwGYR9zbt7z71EA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=07o5/ITyEt3HEz+UaLUPTBpamVY=; b=cGJTn6kv/gW
	Gyz7z4n8rp78s452MgpXbGxzC1BadH8T9xtQCZO69xAVbVQNHRb7bxIg1n0QtJdE
	/Jg0QB8tPjm6LqvY288ngZAE88H8Fty3p2j+UVWPfEEoUXFc0roQoZVuQPc1Q3NQ
	TOq1tC1VKwOXtuubWLSXscoaKGnLebeI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 67FB97EC076; 
	Fri, 13 Apr 2012 09:17:41 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f8fd4a4239a8aa7e25e5a91fd5485bf7844f09cc
Message-Id: <f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 6] x86/mm/shadow: enclose an OOS function
 in the proper conditional ifdef
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/multi.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


Otherwise compilation fails if the feature is disabled.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r aa4ef559da60 -r f8fd4a4239a8 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -248,6 +248,7 @@ shadow_check_gwalk(struct vcpu *v, unsig
     return !mismatch;
 }
 
+#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 static int
 shadow_check_gl1e(struct vcpu *v, walk_t *gw)
 {
@@ -263,7 +264,7 @@ shadow_check_gl1e(struct vcpu *v, walk_t
 
     return gw->l1e.l1 != nl1e.l1;
 }
-
+#endif
 
 /* Remove write access permissions from a gwalk_t in a batch, and
  * return OR-ed result for TLB flush hint and need to rewalk the guest

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBw-0007An-Lr; Fri, 13 Apr 2012 16:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBv-0007AP-Jx
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:43 +0000
Received: from [85.158.143.35:8287] by server-2.bemta-4.messagelabs.com id
	66/28-17550-6A1588F4; Fri, 13 Apr 2012 16:17:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334333861!9870889!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0OTA1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18636 invoked from network); 13 Apr 2012 16:17:42 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-2.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 3D9A67EC065;
	Fri, 13 Apr 2012 09:17:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tJTLx8wroBluszGoJG1vn76P6fqI3bzA5yQzpAx/SIzI
	T+L6t4ePsFGf07MLrYqNcOZIPeHJsQ32ZJbeeWhgVmToFdo8vDkVmKL9vqQ5RjuM
	vyEvAVLyYVkqPeZYhY7nVAZ+xdoSuHDb2VFV/3KJuwuzDCxMc0j7qDWDe2Lb4wY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=19MnzPBGQmlfTL4jVPpMJgFBBcs=; b=O0OQDr9KABR
	a6ar91/JnAvR1RhXPqD6Cp4W2MprLXfEyscyQsFxjxYL9G8sOD+e8fKPThjjbcS4
	np6jI/MkBGDW20bQVxQG6UD35mgYulul4tZk5Utsnw78vfgUxb1EX1Z4ErQ089I4
	0W85p4LYJPm4NCYYmnxP7tYxWCqQx1Rs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id ABC1B7EC076; 
	Fri, 13 Apr 2012 09:17:40 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: aa4ef559da60be600833fadfccc63952c068b3a6
Message-Id: <aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:19 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 6] x86/mm: Print stack trace on a an
 mm-locks deadlock panic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mm-locks.h |  3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7b606c043208 -r aa4ef559da60 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -50,8 +50,11 @@ static inline int mm_locked_by_me(mm_loc
 #define __check_lock_level(l)                           \
 do {                                                    \
     if ( unlikely(__get_lock_level()) > (l) )           \
+    {                                                   \
+        WARN();                                         \
         panic("mm locking order violation: %i > %i\n",  \
               __get_lock_level(), (l));                 \
+    }                                                   \
 } while(0)
 
 #define __set_lock_level(l)         \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjBw-0007An-Lr; Fri, 13 Apr 2012 16:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBv-0007AP-Jx
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:43 +0000
Received: from [85.158.143.35:8287] by server-2.bemta-4.messagelabs.com id
	66/28-17550-6A1588F4; Fri, 13 Apr 2012 16:17:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334333861!9870889!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0OTA1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18636 invoked from network); 13 Apr 2012 16:17:42 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-2.tower-21.messagelabs.com with SMTP;
	13 Apr 2012 16:17:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 3D9A67EC065;
	Fri, 13 Apr 2012 09:17:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tJTLx8wroBluszGoJG1vn76P6fqI3bzA5yQzpAx/SIzI
	T+L6t4ePsFGf07MLrYqNcOZIPeHJsQ32ZJbeeWhgVmToFdo8vDkVmKL9vqQ5RjuM
	vyEvAVLyYVkqPeZYhY7nVAZ+xdoSuHDb2VFV/3KJuwuzDCxMc0j7qDWDe2Lb4wY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=19MnzPBGQmlfTL4jVPpMJgFBBcs=; b=O0OQDr9KABR
	a6ar91/JnAvR1RhXPqD6Cp4W2MprLXfEyscyQsFxjxYL9G8sOD+e8fKPThjjbcS4
	np6jI/MkBGDW20bQVxQG6UD35mgYulul4tZk5Utsnw78vfgUxb1EX1Z4ErQ089I4
	0W85p4LYJPm4NCYYmnxP7tYxWCqQx1Rs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id ABC1B7EC076; 
	Fri, 13 Apr 2012 09:17:40 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: aa4ef559da60be600833fadfccc63952c068b3a6
Message-Id: <aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:19 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 6] x86/mm: Print stack trace on a an
 mm-locks deadlock panic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mm-locks.h |  3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7b606c043208 -r aa4ef559da60 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -50,8 +50,11 @@ static inline int mm_locked_by_me(mm_loc
 #define __check_lock_level(l)                           \
 do {                                                    \
     if ( unlikely(__get_lock_level()) > (l) )           \
+    {                                                   \
+        WARN();                                         \
         panic("mm locking order violation: %i > %i\n",  \
               __get_lock_level(), (l));                 \
+    }                                                   \
 } while(0)
 
 #define __set_lock_level(l)         \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjC0-0007CE-7d; Fri, 13 Apr 2012 16:17:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBx-0007B3-Pb
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:46 +0000
Received: from [85.158.138.51:54747] by server-10.bemta-3.messagelabs.com id
	7D/BF-29478-9A1588F4; Fri, 13 Apr 2012 16:17:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334333864!21873418!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc2NzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19868 invoked from network); 13 Apr 2012 16:17:44 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.177) by server-14.tower-174.messagelabs.com with SMTP;
	13 Apr 2012 16:17:44 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 836007EC078;
	Fri, 13 Apr 2012 09:17:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=lJ1bRywv1M5D24QFRFKIQRIUoMmzP6XY35ZhixIVGk4D
	3sdQheY/INOUmF2NCHSY4asZNmai9J7K8R3L34L2IFtMIh7MjzouUDxvAqccQr3F
	iRa48jNRaxQoDvOVeXmGEgbIfT6UytUwKo0qZl+tU9TER7LumbDPGdwRKXxX0Ec=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=P6MYEoW5tQMn5PHwoeCKXf1qe64=; b=qJIUJ2h+j8+
	eZUWIu0vVwgIJKM9uGOuWqXqRlHDToxwD9Gcf+TNog1jNMXrEc2I2w80+2Xuy4G4
	1gLLeq81m4T1rY+iAvq+xFWeROcI/j8t0KDLoBALN7P/pq97G0HvpQfLFxFViq56
	ak3ryFlhevTrzIuGOK31u9TtbKmEkghs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 133A37EC064; 
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a7ca6ae7399224c08ebab4cbe66cdb188d1060f2
Message-Id: <a7ca6ae7399224c08eba.1334334142@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:22 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 4 of 6] x86/mm/shadow: fix p2m/paging deadlock
 when updating shadow mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/common.c |  4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 964c6cbad926 -r a7ca6ae73992 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2997,9 +2997,13 @@ static void sh_update_paging_modes(struc
 
 void shadow_update_paging_modes(struct vcpu *v)
 {
+    /* Avoid deadlock in shadow mode. When updating, we might need to resync an
+     * l1 and thus get_gfn on all the gfn's pointed to by the guest l1e pte's. */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     paging_lock(v->domain);
     sh_update_paging_modes(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
 }
 
 /**************************************************************************/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjC0-0007CE-7d; Fri, 13 Apr 2012 16:17:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjBx-0007B3-Pb
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:17:46 +0000
Received: from [85.158.138.51:54747] by server-10.bemta-3.messagelabs.com id
	7D/BF-29478-9A1588F4; Fri, 13 Apr 2012 16:17:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334333864!21873418!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc2NzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19868 invoked from network); 13 Apr 2012 16:17:44 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.177) by server-14.tower-174.messagelabs.com with SMTP;
	13 Apr 2012 16:17:44 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 836007EC078;
	Fri, 13 Apr 2012 09:17:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=lJ1bRywv1M5D24QFRFKIQRIUoMmzP6XY35ZhixIVGk4D
	3sdQheY/INOUmF2NCHSY4asZNmai9J7K8R3L34L2IFtMIh7MjzouUDxvAqccQr3F
	iRa48jNRaxQoDvOVeXmGEgbIfT6UytUwKo0qZl+tU9TER7LumbDPGdwRKXxX0Ec=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=P6MYEoW5tQMn5PHwoeCKXf1qe64=; b=qJIUJ2h+j8+
	eZUWIu0vVwgIJKM9uGOuWqXqRlHDToxwD9Gcf+TNog1jNMXrEc2I2w80+2Xuy4G4
	1gLLeq81m4T1rY+iAvq+xFWeROcI/j8t0KDLoBALN7P/pq97G0HvpQfLFxFViq56
	ak3ryFlhevTrzIuGOK31u9TtbKmEkghs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 133A37EC064; 
	Fri, 13 Apr 2012 09:17:42 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a7ca6ae7399224c08ebab4cbe66cdb188d1060f2
Message-Id: <a7ca6ae7399224c08eba.1334334142@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 12:22:22 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 4 of 6] x86/mm/shadow: fix p2m/paging deadlock
 when updating shadow mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/shadow/common.c |  4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 964c6cbad926 -r a7ca6ae73992 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2997,9 +2997,13 @@ static void sh_update_paging_modes(struc
 
 void shadow_update_paging_modes(struct vcpu *v)
 {
+    /* Avoid deadlock in shadow mode. When updating, we might need to resync an
+     * l1 and thus get_gfn on all the gfn's pointed to by the guest l1e pte's. */
+    p2m_lock(p2m_get_hostp2m(v->domain));
     paging_lock(v->domain);
     sh_update_paging_modes(v);
     paging_unlock(v->domain);
+    p2m_unlock(p2m_get_hostp2m(v->domain));
 }
 
 /**************************************************************************/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjDm-0007u1-0R; Fri, 13 Apr 2012 16:19:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjDk-0007sh-1C
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:19:36 +0000
Received: from [85.158.143.99:2847] by server-1.bemta-4.messagelabs.com id
	AA/95-20925-512588F4; Fri, 13 Apr 2012 16:19:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334333972!23568446!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODEzNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25935 invoked from network); 13 Apr 2012 16:19:33 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-9.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 16:19:33 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4F43345807B;
	Fri, 13 Apr 2012 09:19:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=keoLbb/T
	C0kUC8r7PvHGtSGJiUTGM7nWrH1TjT+Q+YGtH9BTaEC7wurq6ydrG8YYcvLr74mm
	y8bJ85ZV0n++WGENiPxRnemejHAAPb1mNksL5MhYL+VI6zNdxthCuXhQUss3NS91
	vtyQDMB2IvHh0sJXkqpcirLLIKEz3Ir7AVM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	2Iw4k/OEiOn48au6HrK13SrUtgQ=; b=bnEDqqPHjlBw5iMh9IBC9xImUwiMo6AS
	yK7iD1ixfLzBuFoB4TPlbUFMMYJcP0CR5DghpmBmt0IJkOGjvRpCpw8tOucg2POa
	dbVjwM5lyWnCRxgaFUyYwOoXGRmSWC6oXknfckinSuRZxSzixHE2n1vD6C8UPpkn
	jgtM5mjYvo0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 4533C458079; 
	Fri, 13 Apr 2012 09:19:32 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 09:19:32 -0700
Message-ID: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
Date: Fri, 13 Apr 2012 09:19:32 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Gianluca Guida <glguida@gmail.com>, tim@xen.org
Subject: [Xen-devel] Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After a hvm+shadow domain dies (either clean shutdown or merciless
destroy), the domain is left in a zombie state with 1 (one) page left
dangling with a single reference.

(XEN) General information for domain 1:
(XEN)     refcnt=1 dying=2 pause_count=1
(XEN)     nr_pages=1 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=524544
(XEN)     handle=deadbeef-dead-beef-dead-beef00000001 vm_assist=00000000
(XEN)     paging assistance: shadow refcounts translate external
(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage 000000000010698e: caf=00000001, taf=7400000000000000
(XEN)     PoD entries=0 cachesize=0
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00
dirty_cpus={} cpu_affinity={0-3}
(XEN)     pause_count=1 pause_flags=0
(XEN)     paging assistance: shadowed 4-on-4
(XEN)     No periodic timer

If add a considerable amount of synchronous printk's, sometimes the domain
is not left zombie. There seems to be a race going on here. Due to the
type
information of the page, I believe this is a page that has been shadowed
with a writable map.

I verified the page is not any of the helper rings (qemu, buffered qemu,
store, console) that may get external writeable references.

This happens on win7 guest with or without pv drivers. It happens with or
without shadow optimizations (SHOPT defines). It happens with or without
synchronized p2m lookups (patches just posted).

Hopefully the shadow masters have a better understanding on how to proceed
from here on.

Thanks,
Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjDm-0007u1-0R; Fri, 13 Apr 2012 16:19:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIjDk-0007sh-1C
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 16:19:36 +0000
Received: from [85.158.143.99:2847] by server-1.bemta-4.messagelabs.com id
	AA/95-20925-512588F4; Fri, 13 Apr 2012 16:19:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334333972!23568446!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODEzNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25935 invoked from network); 13 Apr 2012 16:19:33 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-9.tower-216.messagelabs.com with SMTP;
	13 Apr 2012 16:19:33 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4F43345807B;
	Fri, 13 Apr 2012 09:19:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=keoLbb/T
	C0kUC8r7PvHGtSGJiUTGM7nWrH1TjT+Q+YGtH9BTaEC7wurq6ydrG8YYcvLr74mm
	y8bJ85ZV0n++WGENiPxRnemejHAAPb1mNksL5MhYL+VI6zNdxthCuXhQUss3NS91
	vtyQDMB2IvHh0sJXkqpcirLLIKEz3Ir7AVM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	2Iw4k/OEiOn48au6HrK13SrUtgQ=; b=bnEDqqPHjlBw5iMh9IBC9xImUwiMo6AS
	yK7iD1ixfLzBuFoB4TPlbUFMMYJcP0CR5DghpmBmt0IJkOGjvRpCpw8tOucg2POa
	dbVjwM5lyWnCRxgaFUyYwOoXGRmSWC6oXknfckinSuRZxSzixHE2n1vD6C8UPpkn
	jgtM5mjYvo0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 4533C458079; 
	Fri, 13 Apr 2012 09:19:32 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 09:19:32 -0700
Message-ID: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
Date: Fri, 13 Apr 2012 09:19:32 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Gianluca Guida <glguida@gmail.com>, tim@xen.org
Subject: [Xen-devel] Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After a hvm+shadow domain dies (either clean shutdown or merciless
destroy), the domain is left in a zombie state with 1 (one) page left
dangling with a single reference.

(XEN) General information for domain 1:
(XEN)     refcnt=1 dying=2 pause_count=1
(XEN)     nr_pages=1 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=524544
(XEN)     handle=deadbeef-dead-beef-dead-beef00000001 vm_assist=00000000
(XEN)     paging assistance: shadow refcounts translate external
(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage 000000000010698e: caf=00000001, taf=7400000000000000
(XEN)     PoD entries=0 cachesize=0
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00
dirty_cpus={} cpu_affinity={0-3}
(XEN)     pause_count=1 pause_flags=0
(XEN)     paging assistance: shadowed 4-on-4
(XEN)     No periodic timer

If add a considerable amount of synchronous printk's, sometimes the domain
is not left zombie. There seems to be a race going on here. Due to the
type
information of the page, I believe this is a page that has been shadowed
with a writable map.

I verified the page is not any of the helper rings (qemu, buffered qemu,
store, console) that may get external writeable references.

This happens on win7 guest with or without pv drivers. It happens with or
without shadow optimizations (SHOPT defines). It happens with or without
synchronized p2m lookups (patches just posted).

Hopefully the shadow masters have a better understanding on how to proceed
from here on.

Thanks,
Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:26:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjJz-0000GK-VW; Fri, 13 Apr 2012 16:26:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIjJz-0000GF-8l
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 16:26:03 +0000
Received: from [85.158.139.83:10862] by server-8.bemta-5.messagelabs.com id
	36/71-26964-A93588F4; Fri, 13 Apr 2012 16:26:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334334360!23717700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22846 invoked from network); 13 Apr 2012 16:26:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 16:26:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11931355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 16:25:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 17:25:47 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIjJj-0001Mc-N3;
	Fri, 13 Apr 2012 16:25:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIjJj-0006bg-E0;
	Fri, 13 Apr 2012 17:25:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12671-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 17:25:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12671: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12671 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12671/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12668
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12668
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 12668
 test-i386-i386-xl-win         7 windows-install             fail pass in 12668
 test-amd64-amd64-pv           9 guest-start        fail in 12668 pass in 12671

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12668 like 12639
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12668 like 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12668 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12668 never pass

version targeted for testing:
 xen                  c6bde42c8845
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c6bde42c8845
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c6bde42c8845
+ branch=xen-unstable
+ revision=c6bde42c8845
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c6bde42c8845 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 29 changesets with 68 changes to 45 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:26:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjJz-0000GK-VW; Fri, 13 Apr 2012 16:26:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIjJz-0000GF-8l
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 16:26:03 +0000
Received: from [85.158.139.83:10862] by server-8.bemta-5.messagelabs.com id
	36/71-26964-A93588F4; Fri, 13 Apr 2012 16:26:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334334360!23717700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22846 invoked from network); 13 Apr 2012 16:26:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 16:26:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11931355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 16:25:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 17:25:47 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIjJj-0001Mc-N3;
	Fri, 13 Apr 2012 16:25:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIjJj-0006bg-E0;
	Fri, 13 Apr 2012 17:25:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12671-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 17:25:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12671: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12671 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12671/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12668
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12668
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 12668
 test-i386-i386-xl-win         7 windows-install             fail pass in 12668
 test-amd64-amd64-pv           9 guest-start        fail in 12668 pass in 12671

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12668 like 12639
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12668 like 12639

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12668 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12668 never pass

version targeted for testing:
 xen                  c6bde42c8845
baseline version:
 xen                  5bbda657a016

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c6bde42c8845
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c6bde42c8845
+ branch=xen-unstable
+ revision=c6bde42c8845
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c6bde42c8845 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 29 changesets with 68 changes to 45 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:30:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjNb-0000SN-K5; Fri, 13 Apr 2012 16:29:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIjNa-0000SG-Ap
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 16:29:46 +0000
Received: from [193.109.254.147:63402] by server-9.bemta-14.messagelabs.com id
	26/8D-05787-974588F4; Fri, 13 Apr 2012 16:29:45 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334334583!4502316!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5651 invoked from network); 13 Apr 2012 16:29:44 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 16:29:44 -0000
Received: from mail75-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 16:29:43 +0000
Received: from mail75-tx2 (localhost [127.0.0.1])	by mail75-tx2-R.bigfish.com
	(Postfix) with ESMTP id D3CCAE0357;
	Fri, 13 Apr 2012 16:29:42 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI9371I542M1432N98dKzz1202hzz8275bhz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2
	(MessageSwitch) id 1334334581278508_32331;
	Fri, 13 Apr 2012 16:29:41 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.246])	by
	mail75-tx2.bigfish.com (Postfix) with ESMTP id 3E1684A02BA;
	Fri, 13 Apr 2012 16:29:41 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 16:29:38 +0000
X-WSS-ID: 0M2FF59-02-ATE-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CA08C8151;	Fri, 13 Apr 2012 11:29:33 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 11:29:56 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag01.amd.com ([fe80::3103:1d40:fa1c:a1d1%23]) with mapi id
	14.01.0323.003; Fri, 13 Apr 2012 11:29:36 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: Gianluca Guida <glguida@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
	paging mode.
Thread-Index: AQHNGHOXjXDHjjy2Ok2wEPnlJKi4gZaXH7gAgAHREVA=
Date: Fri, 13 Apr 2012 16:29:29 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
In-Reply-To: <CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.236.71.218]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.

-Wei

-----Original Message-----
From: Gianluca Guida [mailto:glguida@gmail.com] 
Sent: Thursday, April 12, 2012 2:32 AM
To: Huang2, Wei
Cc: xen-devel@lists.xensource.com; Gianluca Guida
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP paging mode.

On Wed, Apr 11, 2012 at 11:14 PM, Wei Huang <wei.huang2@amd.com> wrote:
> On 04/11/2012 06:04 PM, Gianluca Guida wrote:
>> As a major caveat, I haven't tested this patch on AMD, for lack of
>> hardware.
>
> I can test it on my AMD box tomorrow. BTW from my understanding, this patch
> doesn't have performance implication for nested paging mode, does it?

Thank you! A good but not perfect way is to check that xen-hvmctx
doesn't return on HAP the reset PAT table after a linux/windows guest
has been running. And that its value is actually preserved across
save/restore.

As for the performances in nested mode, as far as I could see, I think
not -- but I haven't looked at eventually hidden details of the nested
vm implementation.

Gianluca



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 16:30:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 16:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjNb-0000SN-K5; Fri, 13 Apr 2012 16:29:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIjNa-0000SG-Ap
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 16:29:46 +0000
Received: from [193.109.254.147:63402] by server-9.bemta-14.messagelabs.com id
	26/8D-05787-974588F4; Fri, 13 Apr 2012 16:29:45 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334334583!4502316!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5651 invoked from network); 13 Apr 2012 16:29:44 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 16:29:44 -0000
Received: from mail75-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 16:29:43 +0000
Received: from mail75-tx2 (localhost [127.0.0.1])	by mail75-tx2-R.bigfish.com
	(Postfix) with ESMTP id D3CCAE0357;
	Fri, 13 Apr 2012 16:29:42 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI9371I542M1432N98dKzz1202hzz8275bhz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2
	(MessageSwitch) id 1334334581278508_32331;
	Fri, 13 Apr 2012 16:29:41 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.246])	by
	mail75-tx2.bigfish.com (Postfix) with ESMTP id 3E1684A02BA;
	Fri, 13 Apr 2012 16:29:41 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 16:29:38 +0000
X-WSS-ID: 0M2FF59-02-ATE-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CA08C8151;	Fri, 13 Apr 2012 11:29:33 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 11:29:56 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag01.amd.com ([fe80::3103:1d40:fa1c:a1d1%23]) with mapi id
	14.01.0323.003; Fri, 13 Apr 2012 11:29:36 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: Gianluca Guida <glguida@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
	paging mode.
Thread-Index: AQHNGHOXjXDHjjy2Ok2wEPnlJKi4gZaXH7gAgAHREVA=
Date: Fri, 13 Apr 2012 16:29:29 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
In-Reply-To: <CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.236.71.218]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.

-Wei

-----Original Message-----
From: Gianluca Guida [mailto:glguida@gmail.com] 
Sent: Thursday, April 12, 2012 2:32 AM
To: Huang2, Wei
Cc: xen-devel@lists.xensource.com; Gianluca Guida
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP paging mode.

On Wed, Apr 11, 2012 at 11:14 PM, Wei Huang <wei.huang2@amd.com> wrote:
> On 04/11/2012 06:04 PM, Gianluca Guida wrote:
>> As a major caveat, I haven't tested this patch on AMD, for lack of
>> hardware.
>
> I can test it on my AMD box tomorrow. BTW from my understanding, this patch
> doesn't have performance implication for nested paging mode, does it?

Thank you! A good but not perfect way is to check that xen-hvmctx
doesn't return on HAP the reset PAT table after a linux/windows guest
has been running. And that its value is actually preserved across
save/restore.

As for the performances in nested mode, as far as I could see, I think
not -- but I haven't looked at eventually hidden details of the nested
vm implementation.

Gianluca



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:08:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjyu-0002EP-Gs; Fri, 13 Apr 2012 17:08:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SIjyt-0002EK-Gd
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:08:19 +0000
Received: from [85.158.143.99:30536] by server-3.bemta-4.messagelabs.com id
	96/51-05853-28D588F4; Fri, 13 Apr 2012 17:08:18 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334336897!17185982!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13456 invoked from network); 13 Apr 2012 17:08:18 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:08:18 -0000
Received: by wibhj13 with SMTP id hj13so2886070wib.6
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 10:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=v724xVGHJ4zaXUIIEdZrwEiwWX6k+nEjw88u3JYfz9w=;
	b=zB3PC7AKvhvWPeH7zYmkO5AtSaJbNdV7UI+e1nWuyu9Zp8N1ICACxYI5+c8zZn+yyq
	evmzS4s9SRM0htg1uDDh30uSGEIvYPrddhYmn4kJ+sThZ0ACYTS/6R8tQaZULkXQJL2r
	LjgsrPCBiTtZ0wW/5pDTwIhwqmDJOYMaDGpoJr6CLPvdFNymY7mksYeYIUlkzbznvLiP
	nt+gRzFvnC6e4pSsGP7KPM1aaVA6wSXguGvFlaMdjUo8Shz1K7fNEPBrJyFquT/HFBfe
	HwdtER5yE3l8M1a0Jip3fGV6f8faXvmMFs7hT7moxcp29QdmE2DsRt4l4zI2ijyqk5dy
	mUSQ==
MIME-Version: 1.0
Received: by 10.180.103.35 with SMTP id ft3mr6472246wib.0.1334336897255; Fri,
	13 Apr 2012 10:08:17 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Fri, 13 Apr 2012 10:08:17 -0700 (PDT)
In-Reply-To: <4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
Date: Fri, 13 Apr 2012 10:08:17 -0700
Message-ID: <CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: "Huang2, Wei" <Wei.Huang2@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 9:29 AM, Huang2, Wei <Wei.Huang2@amd.com> wrote:
> I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.

Yes, that is exactly what I expected to see (WC enabled). Thanks again.

Any change to get this checked in?
Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:08:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIjyu-0002EP-Gs; Fri, 13 Apr 2012 17:08:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SIjyt-0002EK-Gd
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:08:19 +0000
Received: from [85.158.143.99:30536] by server-3.bemta-4.messagelabs.com id
	96/51-05853-28D588F4; Fri, 13 Apr 2012 17:08:18 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334336897!17185982!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13456 invoked from network); 13 Apr 2012 17:08:18 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:08:18 -0000
Received: by wibhj13 with SMTP id hj13so2886070wib.6
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 10:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=v724xVGHJ4zaXUIIEdZrwEiwWX6k+nEjw88u3JYfz9w=;
	b=zB3PC7AKvhvWPeH7zYmkO5AtSaJbNdV7UI+e1nWuyu9Zp8N1ICACxYI5+c8zZn+yyq
	evmzS4s9SRM0htg1uDDh30uSGEIvYPrddhYmn4kJ+sThZ0ACYTS/6R8tQaZULkXQJL2r
	LjgsrPCBiTtZ0wW/5pDTwIhwqmDJOYMaDGpoJr6CLPvdFNymY7mksYeYIUlkzbznvLiP
	nt+gRzFvnC6e4pSsGP7KPM1aaVA6wSXguGvFlaMdjUo8Shz1K7fNEPBrJyFquT/HFBfe
	HwdtER5yE3l8M1a0Jip3fGV6f8faXvmMFs7hT7moxcp29QdmE2DsRt4l4zI2ijyqk5dy
	mUSQ==
MIME-Version: 1.0
Received: by 10.180.103.35 with SMTP id ft3mr6472246wib.0.1334336897255; Fri,
	13 Apr 2012 10:08:17 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Fri, 13 Apr 2012 10:08:17 -0700 (PDT)
In-Reply-To: <4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
Date: Fri, 13 Apr 2012 10:08:17 -0700
Message-ID: <CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: "Huang2, Wei" <Wei.Huang2@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 9:29 AM, Huang2, Wei <Wei.Huang2@amd.com> wrote:
> I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.

Yes, that is exactly what I expected to see (WC enabled). Thanks again.

Any change to get this checked in?
Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:22:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkCb-0002Rh-3k; Fri, 13 Apr 2012 17:22:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1SIkCZ-0002RQ-I7
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:22:27 +0000
Received: from [85.158.143.35:19310] by server-3.bemta-4.messagelabs.com id
	5A/51-05853-2D0688F4; Fri, 13 Apr 2012 17:22:26 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334337744!9877692!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2116 invoked from network); 13 Apr 2012 17:22:25 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:22:25 -0000
Received: by iadj38 with SMTP id j38so5550324iad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 10:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=Qys2LArHvhxYXRyjE9EuRqdo/VNDCZh2jWPoYOIXEss=;
	b=qVfT5aMCriZqA0WrPW2oPI7sNeg72juP0SR0sTSQ0zdrOp+rtNRLiLRxtvqcMMytCQ
	uCT1mtjtOX6bvh3JFXwhcnAJepolN8BPH1GVqSa82T/La7FZ/KZfNthbyesZORXJw3zc
	B1okJ5uxnVDaVs3SIYZ6gj6NyEFogkXboUY4osMfjTJcWcxzywU/jNNB5MvP3dmKxw2j
	PTgSLNU9f7nd7RYgWRW6EQKMhGY8I4B+mA3SzUC7rN3Q0Yj49NuWEkXH8NfYOzBBjI3q
	zGgmwcuqAjCNcjgXPaPewkrgo5J3qpe44HCAxvmfa4a8DDvziCtdjkv25kMO/NAoaDkv
	/FRQ==
Received: by 10.50.181.194 with SMTP id dy2mr2377402igc.48.1334337743746; Fri,
	13 Apr 2012 10:22:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.103.70 with HTTP; Fri, 13 Apr 2012 10:22:02 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
From: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 13 Apr 2012 13:22:02 -0400
X-Google-Sender-Auth: tvobciF_JhPbSnoFFIyYd7O_s4o
Message-ID: <CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
To: Remi Gacogne <rgacogne-xen@valombre.net>
Cc: Lloyd Dizon <thecarrionkind@gmail.com>, xen-users@lists.xen.org,
	xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding Xen-devel.

What are the current timekeeping best practices now?

Thanks,
Todd

---------- Forwarded message ----------
From: Remi Gacogne <rgacogne-xen@valombre.net>
Date: Fri, Apr 13, 2012 at 12:31 PM
Subject: Re: [Xen-users] Xen timekeeping best practices
To: Todd Deshane <todd.deshane@xen.org>
Cc: Lloyd Dizon <thecarrionkind@gmail.com>, xen-users@lists.xen.org



> Does this help at all:
> http://wiki.xensource.com/wiki/Xen_FAQ_DomU#How_can_i_synchronize_a_dom0_clock.3F


Well, thank you but independent_wallclock doesn't exist anymore on
pvops kernel, and the link to blogspot seems broken so, no, not very
much :)

--

Regards,

Remi Gacogne



-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:22:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkCb-0002Rh-3k; Fri, 13 Apr 2012 17:22:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1SIkCZ-0002RQ-I7
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:22:27 +0000
Received: from [85.158.143.35:19310] by server-3.bemta-4.messagelabs.com id
	5A/51-05853-2D0688F4; Fri, 13 Apr 2012 17:22:26 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334337744!9877692!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2116 invoked from network); 13 Apr 2012 17:22:25 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:22:25 -0000
Received: by iadj38 with SMTP id j38so5550324iad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 10:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=Qys2LArHvhxYXRyjE9EuRqdo/VNDCZh2jWPoYOIXEss=;
	b=qVfT5aMCriZqA0WrPW2oPI7sNeg72juP0SR0sTSQ0zdrOp+rtNRLiLRxtvqcMMytCQ
	uCT1mtjtOX6bvh3JFXwhcnAJepolN8BPH1GVqSa82T/La7FZ/KZfNthbyesZORXJw3zc
	B1okJ5uxnVDaVs3SIYZ6gj6NyEFogkXboUY4osMfjTJcWcxzywU/jNNB5MvP3dmKxw2j
	PTgSLNU9f7nd7RYgWRW6EQKMhGY8I4B+mA3SzUC7rN3Q0Yj49NuWEkXH8NfYOzBBjI3q
	zGgmwcuqAjCNcjgXPaPewkrgo5J3qpe44HCAxvmfa4a8DDvziCtdjkv25kMO/NAoaDkv
	/FRQ==
Received: by 10.50.181.194 with SMTP id dy2mr2377402igc.48.1334337743746; Fri,
	13 Apr 2012 10:22:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.103.70 with HTTP; Fri, 13 Apr 2012 10:22:02 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
From: Todd Deshane <todd.deshane@xen.org>
Date: Fri, 13 Apr 2012 13:22:02 -0400
X-Google-Sender-Auth: tvobciF_JhPbSnoFFIyYd7O_s4o
Message-ID: <CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
To: Remi Gacogne <rgacogne-xen@valombre.net>
Cc: Lloyd Dizon <thecarrionkind@gmail.com>, xen-users@lists.xen.org,
	xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding Xen-devel.

What are the current timekeeping best practices now?

Thanks,
Todd

---------- Forwarded message ----------
From: Remi Gacogne <rgacogne-xen@valombre.net>
Date: Fri, Apr 13, 2012 at 12:31 PM
Subject: Re: [Xen-users] Xen timekeeping best practices
To: Todd Deshane <todd.deshane@xen.org>
Cc: Lloyd Dizon <thecarrionkind@gmail.com>, xen-users@lists.xen.org



> Does this help at all:
> http://wiki.xensource.com/wiki/Xen_FAQ_DomU#How_can_i_synchronize_a_dom0_clock.3F


Well, thank you but independent_wallclock doesn't exist anymore on
pvops kernel, and the link to blogspot seems broken so, no, not very
much :)

--

Regards,

Remi Gacogne



-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:27:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:27:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkHW-0002zN-Ri; Fri, 13 Apr 2012 17:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIkHU-0002z7-KK
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:27:32 +0000
Received: from [85.158.138.51:38369] by server-7.bemta-3.messagelabs.com id
	5C/27-03078-302688F4; Fri, 13 Apr 2012 17:27:31 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334338049!22096034!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 13 Apr 2012 17:27:30 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:27:30 -0000
Received: by bkcjg9 with SMTP id jg9so3083592bkc.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 10:27:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=1607c774SzH2UxXbw4yDvZSs0L0Yzx+OBzRga+R5qHg=;
	b=HqgS2QQvGemHiDeOeUuaKik29rpUAoYj0EBYtwb8YWKUYZW8T11YPi5jIE8LYx+uik
	/Hpnv7jrFB1qFWnx5RcZyM4HlEbAFvrckygSVEJ1fwJ2vVvWWvq4NRCJCeJGBbu14WdQ
	4AsaGwx6UaVjcxX1rbSVboLZmA7zd4Z60O+YcqUIZgM5bhl0stUYtMGUhx9lIq6QcnTv
	cGTM8hJhVQCdTyjAZTYTU+xx/eH61O7zecz7cB9y5t5UWokTjXqSVzS5Op12mBJh/ZuW
	oa0bnbhdzlysn3/cB7uI5I9WSE1S3hI3sqnLHjNzddNgLlS258YyzSLH7GG1KaYhv4Sf
	16/A==
MIME-Version: 1.0
Received: by 10.205.136.20 with SMTP id ii20mr697333bkc.97.1334338048956; Fri,
	13 Apr 2012 10:27:28 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 10:27:28 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <4F87F84B020000780007DB52@nat28.tlf.novell.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
Date: Fri, 13 Apr 2012 10:27:28 -0700
Message-ID: <CA+2rt43hL4An=1wkrCRpEZd8Jxg5aivF4wmr9AY=TrfaZ+hCrQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQnjr0XHH4HAZxEYpOi7mjdEH6/UEUYoQ6FCoinfMx/Sab5r5FWfuk/WyxSoaBRVw6FEPxCA
Cc: jeremy@goop.org, keir@xen.org, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6858794764507927403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6858794764507927403==
Content-Type: multipart/alternative; boundary=000e0cdffa666b1a0d04bd92c9cd

--000e0cdffa666b1a0d04bd92c9cd
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 12:56 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
> > I've compiled a kernel, force sched_clock_stable=0, then it solved the
> > timestamp jump issue as expected. Luckily, seems it also solved the call
> > trace and guest hang issue as well.
>
> And this is also how it should be fixed.
>
> > Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I
> think
> > the issue can be easily reproduced using a Westmere or SandyBridge
> > machine(my old colleagues at Intel said the feature likely existed after
> > Nehalem) running newer version of PV guest, check the guest cpuinfo you
> > would see nonstop_tsc, and you would notice the abnormal timestamp of
> > printk.
>
> Masking the entire leaf is certainly out of question. And even masking
> the individual bit is questionable - a PV kernel simply shouldn't look at
> it imo (for other than possibly reporting to user mode purposes).
>
> Jan
>
>
The CPUID detection part in the kernel is handled by CPU vendor, not Xen.
And the way how Xen control it is through CPUID it present to the guest.

1. We can only mask one bit of it. But currently this leaf got only this
feature. I don't think it would be a big problem of mask the whole leaf. I
think it's already a problem that Xen handle PV guest a blacklist of cpu
feature rather than a white list, so when some new feature slipped in(like
this time), nobody would know what would happen. I am really thinking of
some thing like:

switch ( input[0] )
case...
case...

+default:
        regs[0] = regs[1] = regs[2] = regs[3] = 0;

Maybe there are some reason that we didn't set a default value for pv cpuid
policy, but I can't see why.

2. If we want to present the cpu feature to the guest and disable that
feature in the guest, then what's the point? I don't think it is a good
idea. What if there are something else interactive with this cpuid feature
but we failed to disable(e.g. something other than sched_clock_stable)?
Just don't show it would be a better/cleaner way to do it, as long as we
agreed this feature is useless even troublesome for PV guest.

--
regards
Yang, Sheng

--000e0cdffa666b1a0d04bd92c9cd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 12:56 AM, Jan Beulich <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 12.04.12 at 21:22, Sheng Yang &lt;<a href=
=3D"mailto:sheng@yasker.org">sheng@yasker.org</a>&gt; wrote:<br>
&gt; I&#39;ve compiled a kernel, force sched_clock_stable=3D0, then it solv=
ed the<br>
&gt; timestamp jump issue as expected. Luckily, seems it also solved the ca=
ll<br>
&gt; trace and guest hang issue as well.<br>
<br>
</div>And this is also how it should be fixed.<br>
<div class=3D"im"><br>
&gt; Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I =
think<br>
&gt; the issue can be easily reproduced using a Westmere or SandyBridge<br>
&gt; machine(my old colleagues at Intel said the feature likely existed aft=
er<br>
&gt; Nehalem) running newer version of PV guest, check the guest cpuinfo yo=
u<br>
&gt; would see nonstop_tsc, and you would notice the abnormal timestamp of<=
br>
&gt; printk.<br>
<br>
</div>Masking the entire leaf is certainly out of question. And even maskin=
g<br>
the individual bit is questionable - a PV kernel simply shouldn&#39;t look =
at<br>
it imo (for other than possibly reporting to user mode purposes).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><div><br></div><div>The CPUID detection pa=
rt in the kernel is handled by CPU vendor, not Xen. And the way how Xen con=
trol it is through CPUID it present to the guest.</div><br><div>1. We can o=
nly mask one bit of it. But currently this leaf got only this feature. I do=
n&#39;t think it would be a big problem of mask the whole leaf. I think it&=
#39;s already a problem that Xen handle PV guest a blacklist of cpu feature=
 rather than a white list, so when some new feature slipped in(like this ti=
me), nobody would know what would happen. I am really thinking of some thin=
g like:</div>
<div><br></div><div><div>switch ( input[0] )</div><div>case...</div><div>ca=
se...</div><div><br></div><div>+default:=A0</div><div>=A0 =A0 =A0 =A0 regs[=
0] =3D regs[1] =3D regs[2] =3D regs[3] =3D 0;</div><div><br></div><div>Mayb=
e there are some reason that we didn&#39;t set a default value for pv cpuid=
 policy, but I can&#39;t see why.</div>
<div><br></div><div>2. If we want to=A0present the cpu feature to the guest=
 and=A0disable that feature in the guest, then what&#39;s the point? I don&=
#39;t think it is a good idea. What if there are something else interactive=
 with this cpuid feature but we failed to disable(e.g. something other than=
 sched_clock_stable)? Just don&#39;t show it would be a better/cleaner way =
to do it, as long as we agreed this feature is useless even troublesome for=
 PV guest.</div>
<div>=A0</div>--<div>regards</div><div>Yang, Sheng</div><br>
</div>

--000e0cdffa666b1a0d04bd92c9cd--


--===============6858794764507927403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6858794764507927403==--


From xen-devel-bounces@lists.xen.org Fri Apr 13 17:27:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:27:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkHW-0002zN-Ri; Fri, 13 Apr 2012 17:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIkHU-0002z7-KK
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:27:32 +0000
Received: from [85.158.138.51:38369] by server-7.bemta-3.messagelabs.com id
	5C/27-03078-302688F4; Fri, 13 Apr 2012 17:27:31 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334338049!22096034!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 13 Apr 2012 17:27:30 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:27:30 -0000
Received: by bkcjg9 with SMTP id jg9so3083592bkc.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 10:27:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=1607c774SzH2UxXbw4yDvZSs0L0Yzx+OBzRga+R5qHg=;
	b=HqgS2QQvGemHiDeOeUuaKik29rpUAoYj0EBYtwb8YWKUYZW8T11YPi5jIE8LYx+uik
	/Hpnv7jrFB1qFWnx5RcZyM4HlEbAFvrckygSVEJ1fwJ2vVvWWvq4NRCJCeJGBbu14WdQ
	4AsaGwx6UaVjcxX1rbSVboLZmA7zd4Z60O+YcqUIZgM5bhl0stUYtMGUhx9lIq6QcnTv
	cGTM8hJhVQCdTyjAZTYTU+xx/eH61O7zecz7cB9y5t5UWokTjXqSVzS5Op12mBJh/ZuW
	oa0bnbhdzlysn3/cB7uI5I9WSE1S3hI3sqnLHjNzddNgLlS258YyzSLH7GG1KaYhv4Sf
	16/A==
MIME-Version: 1.0
Received: by 10.205.136.20 with SMTP id ii20mr697333bkc.97.1334338048956; Fri,
	13 Apr 2012 10:27:28 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 10:27:28 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <4F87F84B020000780007DB52@nat28.tlf.novell.com>
References: <CA+2rt42Z+8Bg9wh=LPphQKBOV6Rxgpm7D8LdKOOq7_X6GVOKxw@mail.gmail.com>
	<CA+2rt42-KhN7G_P6hKuqc5n3mc8ZKer1Pgr5HT1GXOf440tRYA@mail.gmail.com>
	<4F87F84B020000780007DB52@nat28.tlf.novell.com>
Date: Fri, 13 Apr 2012 10:27:28 -0700
Message-ID: <CA+2rt43hL4An=1wkrCRpEZd8Jxg5aivF4wmr9AY=TrfaZ+hCrQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQnjr0XHH4HAZxEYpOi7mjdEH6/UEUYoQ6FCoinfMx/Sab5r5FWfuk/WyxSoaBRVw6FEPxCA
Cc: jeremy@goop.org, keir@xen.org, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Debian stable kernel got timer issue when running
 as PV guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6858794764507927403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6858794764507927403==
Content-Type: multipart/alternative; boundary=000e0cdffa666b1a0d04bd92c9cd

--000e0cdffa666b1a0d04bd92c9cd
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 12:56 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 12.04.12 at 21:22, Sheng Yang <sheng@yasker.org> wrote:
> > I've compiled a kernel, force sched_clock_stable=0, then it solved the
> > timestamp jump issue as expected. Luckily, seems it also solved the call
> > trace and guest hang issue as well.
>
> And this is also how it should be fixed.
>
> > Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I
> think
> > the issue can be easily reproduced using a Westmere or SandyBridge
> > machine(my old colleagues at Intel said the feature likely existed after
> > Nehalem) running newer version of PV guest, check the guest cpuinfo you
> > would see nonstop_tsc, and you would notice the abnormal timestamp of
> > printk.
>
> Masking the entire leaf is certainly out of question. And even masking
> the individual bit is questionable - a PV kernel simply shouldn't look at
> it imo (for other than possibly reporting to user mode purposes).
>
> Jan
>
>
The CPUID detection part in the kernel is handled by CPU vendor, not Xen.
And the way how Xen control it is through CPUID it present to the guest.

1. We can only mask one bit of it. But currently this leaf got only this
feature. I don't think it would be a big problem of mask the whole leaf. I
think it's already a problem that Xen handle PV guest a blacklist of cpu
feature rather than a white list, so when some new feature slipped in(like
this time), nobody would know what would happen. I am really thinking of
some thing like:

switch ( input[0] )
case...
case...

+default:
        regs[0] = regs[1] = regs[2] = regs[3] = 0;

Maybe there are some reason that we didn't set a default value for pv cpuid
policy, but I can't see why.

2. If we want to present the cpu feature to the guest and disable that
feature in the guest, then what's the point? I don't think it is a good
idea. What if there are something else interactive with this cpuid feature
but we failed to disable(e.g. something other than sched_clock_stable)?
Just don't show it would be a better/cleaner way to do it, as long as we
agreed this feature is useless even troublesome for PV guest.

--
regards
Yang, Sheng

--000e0cdffa666b1a0d04bd92c9cd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 12:56 AM, Jan Beulich <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 12.04.12 at 21:22, Sheng Yang &lt;<a href=
=3D"mailto:sheng@yasker.org">sheng@yasker.org</a>&gt; wrote:<br>
&gt; I&#39;ve compiled a kernel, force sched_clock_stable=3D0, then it solv=
ed the<br>
&gt; timestamp jump issue as expected. Luckily, seems it also solved the ca=
ll<br>
&gt; trace and guest hang issue as well.<br>
<br>
</div>And this is also how it should be fixed.<br>
<div class=3D"im"><br>
&gt; Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I =
think<br>
&gt; the issue can be easily reproduced using a Westmere or SandyBridge<br>
&gt; machine(my old colleagues at Intel said the feature likely existed aft=
er<br>
&gt; Nehalem) running newer version of PV guest, check the guest cpuinfo yo=
u<br>
&gt; would see nonstop_tsc, and you would notice the abnormal timestamp of<=
br>
&gt; printk.<br>
<br>
</div>Masking the entire leaf is certainly out of question. And even maskin=
g<br>
the individual bit is questionable - a PV kernel simply shouldn&#39;t look =
at<br>
it imo (for other than possibly reporting to user mode purposes).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><div><br></div><div>The CPUID detection pa=
rt in the kernel is handled by CPU vendor, not Xen. And the way how Xen con=
trol it is through CPUID it present to the guest.</div><br><div>1. We can o=
nly mask one bit of it. But currently this leaf got only this feature. I do=
n&#39;t think it would be a big problem of mask the whole leaf. I think it&=
#39;s already a problem that Xen handle PV guest a blacklist of cpu feature=
 rather than a white list, so when some new feature slipped in(like this ti=
me), nobody would know what would happen. I am really thinking of some thin=
g like:</div>
<div><br></div><div><div>switch ( input[0] )</div><div>case...</div><div>ca=
se...</div><div><br></div><div>+default:=A0</div><div>=A0 =A0 =A0 =A0 regs[=
0] =3D regs[1] =3D regs[2] =3D regs[3] =3D 0;</div><div><br></div><div>Mayb=
e there are some reason that we didn&#39;t set a default value for pv cpuid=
 policy, but I can&#39;t see why.</div>
<div><br></div><div>2. If we want to=A0present the cpu feature to the guest=
 and=A0disable that feature in the guest, then what&#39;s the point? I don&=
#39;t think it is a good idea. What if there are something else interactive=
 with this cpuid feature but we failed to disable(e.g. something other than=
 sched_clock_stable)? Just don&#39;t show it would be a better/cleaner way =
to do it, as long as we agreed this feature is useless even troublesome for=
 PV guest.</div>
<div>=A0</div>--<div>regards</div><div>Yang, Sheng</div><br>
</div>

--000e0cdffa666b1a0d04bd92c9cd--


--===============6858794764507927403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6858794764507927403==--


From xen-devel-bounces@lists.xen.org Fri Apr 13 17:35:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkP6-0003Iv-Ps; Fri, 13 Apr 2012 17:35:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIkP4-0003Io-T5
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:35:23 +0000
Received: from [85.158.139.83:36147] by server-2.bemta-5.messagelabs.com id
	0A/76-17016-AD3688F4; Fri, 13 Apr 2012 17:35:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334338521!23195312!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14891 invoked from network); 13 Apr 2012 17:35:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 17:35:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIkOz-000E4m-HN; Fri, 13 Apr 2012 17:35:17 +0000
Date: Fri, 13 Apr 2012 18:35:17 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120413173517.GA52993@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 6] x86/mm/shadow: fixes and
	synchronized p2m lookups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:22 -0400 on 13 Apr (1334319738), Andres Lagar-Cavilla wrote:
> Allow shadow page tables to take advantage of synchronized p2m lookups. This
> required a number of deadlock fixes building up to enabling of this feature.

Thanks for this.  I'm on holiday this week but I'll look at this (and
your other MM patches) next week.  I think the other patches are
bugfixes and should be OK for 4.2; not sure yet whether this series
will make it past the feature freeze.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:35:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkP6-0003Iv-Ps; Fri, 13 Apr 2012 17:35:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIkP4-0003Io-T5
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:35:23 +0000
Received: from [85.158.139.83:36147] by server-2.bemta-5.messagelabs.com id
	0A/76-17016-AD3688F4; Fri, 13 Apr 2012 17:35:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334338521!23195312!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14891 invoked from network); 13 Apr 2012 17:35:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 17:35:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIkOz-000E4m-HN; Fri, 13 Apr 2012 17:35:17 +0000
Date: Fri, 13 Apr 2012 18:35:17 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120413173517.GA52993@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1334334138@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 6] x86/mm/shadow: fixes and
	synchronized p2m lookups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:22 -0400 on 13 Apr (1334319738), Andres Lagar-Cavilla wrote:
> Allow shadow page tables to take advantage of synchronized p2m lookups. This
> required a number of deadlock fixes building up to enabling of this feature.

Thanks for this.  I'm on holiday this week but I'll look at this (and
your other MM patches) next week.  I think the other patches are
bugfixes and should be OK for 4.2; not sure yet whether this series
will make it past the feature freeze.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:36:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkPU-0003Kr-6F; Fri, 13 Apr 2012 17:35:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SIkPT-0003KP-3x
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:35:47 +0000
Received: from [85.158.143.99:51130] by server-3.bemta-4.messagelabs.com id
	F6/D9-05853-2F3688F4; Fri, 13 Apr 2012 17:35:46 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334338545!23576380!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7177 invoked from network); 13 Apr 2012 17:35:46 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:35:46 -0000
Received: by werp12 with SMTP id p12so2641481wer.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 10:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=MLPAthFnud4McxQN2GV3KF++xuXhtLbtNZnGh2YEDpg=;
	b=EPxgsVJkWEQOVDebF68hlrBaJwIDpwwTGrGCtKbfBdYR1z6jVKK4G4fi/GsGCDbpC1
	jSsTj1fkDyjUxf4fAo1llhG/5Xw7iQpQ2eV30zYF92yAIQbtFB3NiLhlLSlVkWwulGtT
	P4hYmuN7ycsyd2qaoNhAmwute3N5H/Q4GqVu4lhHGD8AimwKtYpWNuqaLoM489SsnFzR
	sBC4pfEdNKznxI3nYvZ9U4wvLZa2RFDduJdLib4gtV2b73HMEy/cFOQ0UbLrCDtughre
	ueX2VxTcouqpgS7kxAmkEIo6x3BcqSbDyheDnTSfsJgjaoyr4axC9kh/yThtDVcatuSR
	qTfg==
MIME-Version: 1.0
Received: by 10.180.95.197 with SMTP id dm5mr6590032wib.20.1334338545683; Fri,
	13 Apr 2012 10:35:45 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Fri, 13 Apr 2012 10:35:45 -0700 (PDT)
In-Reply-To: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
Date: Fri, 13 Apr 2012 10:35:45 -0700
Message-ID: <CAKpvNa1YakP8-kRbfuKCszfR4g0e6Wku1n2=UEc+eexNuDwB3A@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: andres@lagarcavilla.org
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 9:19 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> After a hvm+shadow domain dies (either clean shutdown or merciless
> destroy), the domain is left in a zombie state with 1 (one) page left
> dangling with a single reference.

[...]

> (XEN) =A0 =A0 paging assistance: shadowed 4-on-4

[...]

> This happens on win7 guest with or without pv drivers. It happens with or
> without shadow optimizations (SHOPT defines). It happens with or without
> synchronized p2m lookups (patches just posted).

Does it happens only in 64bit guests?

Thanks,
Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:36:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkPU-0003Kr-6F; Fri, 13 Apr 2012 17:35:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SIkPT-0003KP-3x
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:35:47 +0000
Received: from [85.158.143.99:51130] by server-3.bemta-4.messagelabs.com id
	F6/D9-05853-2F3688F4; Fri, 13 Apr 2012 17:35:46 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334338545!23576380!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7177 invoked from network); 13 Apr 2012 17:35:46 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:35:46 -0000
Received: by werp12 with SMTP id p12so2641481wer.32
	for <xen-devel@lists.xen.org>; Fri, 13 Apr 2012 10:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=MLPAthFnud4McxQN2GV3KF++xuXhtLbtNZnGh2YEDpg=;
	b=EPxgsVJkWEQOVDebF68hlrBaJwIDpwwTGrGCtKbfBdYR1z6jVKK4G4fi/GsGCDbpC1
	jSsTj1fkDyjUxf4fAo1llhG/5Xw7iQpQ2eV30zYF92yAIQbtFB3NiLhlLSlVkWwulGtT
	P4hYmuN7ycsyd2qaoNhAmwute3N5H/Q4GqVu4lhHGD8AimwKtYpWNuqaLoM489SsnFzR
	sBC4pfEdNKznxI3nYvZ9U4wvLZa2RFDduJdLib4gtV2b73HMEy/cFOQ0UbLrCDtughre
	ueX2VxTcouqpgS7kxAmkEIo6x3BcqSbDyheDnTSfsJgjaoyr4axC9kh/yThtDVcatuSR
	qTfg==
MIME-Version: 1.0
Received: by 10.180.95.197 with SMTP id dm5mr6590032wib.20.1334338545683; Fri,
	13 Apr 2012 10:35:45 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Fri, 13 Apr 2012 10:35:45 -0700 (PDT)
In-Reply-To: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
Date: Fri, 13 Apr 2012 10:35:45 -0700
Message-ID: <CAKpvNa1YakP8-kRbfuKCszfR4g0e6Wku1n2=UEc+eexNuDwB3A@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: andres@lagarcavilla.org
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 9:19 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> After a hvm+shadow domain dies (either clean shutdown or merciless
> destroy), the domain is left in a zombie state with 1 (one) page left
> dangling with a single reference.

[...]

> (XEN) =A0 =A0 paging assistance: shadowed 4-on-4

[...]

> This happens on win7 guest with or without pv drivers. It happens with or
> without shadow optimizations (SHOPT defines). It happens with or without
> synchronized p2m lookups (patches just posted).

Does it happens only in 64bit guests?

Thanks,
Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:38:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkRQ-0003Vz-NQ; Fri, 13 Apr 2012 17:37:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIkRP-0003Vs-P0
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:37:47 +0000
Received: from [193.109.254.147:56547] by server-3.bemta-14.messagelabs.com id
	07/32-23274-B64688F4; Fri, 13 Apr 2012 17:37:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334338666!2041005!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTgzMTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10046 invoked from network); 13 Apr 2012 17:37:46 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-5.tower-27.messagelabs.com with SMTP;
	13 Apr 2012 17:37:46 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 2B56D604099;
	Fri, 13 Apr 2012 10:37:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=K0QYlbyqE7SiLPm0Doh2CvGjza+tuHQhzquE0a4F/h0v
	tvNK+V/EHo/Y21pGqQgcUkSlLaSS1RWj6LK9WOUWmcTj/xqEmIMgXwjwQRg3nBuz
	1ktVbaRbnM9fWe43WmJjFsyrk2vtLtkSt3F+vM+keXoEKfOBOYlXfGel5fKN22c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=g5fanc1mPjQZIpPZJPz+LZ36mlg=; b=kvZBIU75
	Zy37Fwnb1EcWLyLaqnWujoqxKgSDgv5QAM3v8k+3ITtm3zDZdl5AtRh+6P7sKwjv
	1lCXGOxncJbE9u/ZSoXsVsZr0dHWmRsP9QvzCjccSZmDDdIupAaIT9oSG9yAyQWV
	DRnRyRc+8K+7ao0wUyXsKxp9rEgMctM1oRE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 89D76604095; 
	Fri, 13 Apr 2012 10:37:44 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 10:37:44 -0700
Message-ID: <dfce70b21d891c0f01f1906c96ad00ab.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120413173517.GA52993@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<20120413173517.GA52993@ocelot.phlegethon.org>
Date: Fri, 13 Apr 2012 10:37:44 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 6] x86/mm/shadow: fixes and
 synchronized p2m lookups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 12:22 -0400 on 13 Apr (1334319738), Andres Lagar-Cavilla wrote:
>> Allow shadow page tables to take advantage of synchronized p2m lookups.
>> This
>> required a number of deadlock fixes building up to enabling of this
>> feature.
>
> Thanks for this.  I'm on holiday this week but I'll look at this (and
> your other MM patches) next week.  I think the other patches are
> bugfixes and should be OK for 4.2; not sure yet whether this series
> will make it past the feature freeze.

In terms of priority I rank much higher the sharing scalability patches.

Thanks and enjoy the vacation time
Andres
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:38:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkRQ-0003Vz-NQ; Fri, 13 Apr 2012 17:37:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIkRP-0003Vs-P0
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:37:47 +0000
Received: from [193.109.254.147:56547] by server-3.bemta-14.messagelabs.com id
	07/32-23274-B64688F4; Fri, 13 Apr 2012 17:37:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334338666!2041005!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTgzMTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10046 invoked from network); 13 Apr 2012 17:37:46 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-5.tower-27.messagelabs.com with SMTP;
	13 Apr 2012 17:37:46 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 2B56D604099;
	Fri, 13 Apr 2012 10:37:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=K0QYlbyqE7SiLPm0Doh2CvGjza+tuHQhzquE0a4F/h0v
	tvNK+V/EHo/Y21pGqQgcUkSlLaSS1RWj6LK9WOUWmcTj/xqEmIMgXwjwQRg3nBuz
	1ktVbaRbnM9fWe43WmJjFsyrk2vtLtkSt3F+vM+keXoEKfOBOYlXfGel5fKN22c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=g5fanc1mPjQZIpPZJPz+LZ36mlg=; b=kvZBIU75
	Zy37Fwnb1EcWLyLaqnWujoqxKgSDgv5QAM3v8k+3ITtm3zDZdl5AtRh+6P7sKwjv
	1lCXGOxncJbE9u/ZSoXsVsZr0dHWmRsP9QvzCjccSZmDDdIupAaIT9oSG9yAyQWV
	DRnRyRc+8K+7ao0wUyXsKxp9rEgMctM1oRE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 89D76604095; 
	Fri, 13 Apr 2012 10:37:44 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 10:37:44 -0700
Message-ID: <dfce70b21d891c0f01f1906c96ad00ab.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120413173517.GA52993@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<20120413173517.GA52993@ocelot.phlegethon.org>
Date: Fri, 13 Apr 2012 10:37:44 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 6] x86/mm/shadow: fixes and
 synchronized p2m lookups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 12:22 -0400 on 13 Apr (1334319738), Andres Lagar-Cavilla wrote:
>> Allow shadow page tables to take advantage of synchronized p2m lookups.
>> This
>> required a number of deadlock fixes building up to enabling of this
>> feature.
>
> Thanks for this.  I'm on holiday this week but I'll look at this (and
> your other MM patches) next week.  I think the other patches are
> bugfixes and should be OK for 4.2; not sure yet whether this series
> will make it past the feature freeze.

In terms of priority I rank much higher the sharing scalability patches.

Thanks and enjoy the vacation time
Andres
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkSQ-0003bo-5g; Fri, 13 Apr 2012 17:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIkSO-0003bc-Ua
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:38:49 +0000
Received: from [85.158.138.51:48040] by server-12.bemta-3.messagelabs.com id
	B0/35-29760-8A4688F4; Fri, 13 Apr 2012 17:38:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334338727!22097093!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2MjA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25843 invoked from network); 13 Apr 2012 17:38:47 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	13 Apr 2012 17:38:47 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B3C6C5EC072;
	Fri, 13 Apr 2012 10:38:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=nd3yiGO2GyaTRU3YXypUFxLSonfR2xYEbp0UnFqvrPQr
	5IUc8oTWR8lP7dRKQngaRuB90Kj7CiIQwe9fbZo1uEygaOCMzQ9TiYlKMeeZrv5h
	UZsqZDWgHIX/qs8Vr9NtDKskQj2z5/LrWnvNgILA9B8Mb225G/gHtofo3SbHxFo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Mp3SLlRur5pjLc07Npt1UxV67ns=; b=ANxARjZp
	4tWlU6uuJxaH/BW97dvdNz12DnyJpwyf2wMHw8VmhW/UjB7kLPJ3YRtyuUC9Ve7W
	ARB3JXB/VlsBy5/1aR3p/JGVd6S9rIVaYHIc4K91E9feWviXlTISNH1mjyeQlfMW
	aHndxxUMjobjMu/Cc3UNB6lyX/R+r7jxLZo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id F1C0A5EC082; 
	Fri, 13 Apr 2012 10:38:45 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 10:38:46 -0700
Message-ID: <3107e613227a6cd7aa3ec256e1f8b7d5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAKpvNa1YakP8-kRbfuKCszfR4g0e6Wku1n2=UEc+eexNuDwB3A@mail.gmail.com>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<CAKpvNa1YakP8-kRbfuKCszfR4g0e6Wku1n2=UEc+eexNuDwB3A@mail.gmail.com>
Date: Fri, 13 Apr 2012 10:38:46 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Gianluca Guida" <glguida@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, Apr 13, 2012 at 9:19 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>> After a hvm+shadow domain dies (either clean shutdown or merciless
>> destroy), the domain is left in a zombie state with 1 (one) page left
>> dangling with a single reference.
>
> [...]
>
>> (XEN) =A0 =A0 paging assistance: shadowed 4-on-4
>
> [...]
>
>> This happens on win7 guest with or without pv drivers. It happens with
>> or
>> without shadow optimizations (SHOPT defines). It happens with or without
>> synchronized p2m lookups (patches just posted).
>
> Does it happens only in 64bit guests?
Haven't tried 32 bit (w/ wo/ PAE) guests.
Andres

>
> Thanks,
> Gianluca
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkSQ-0003bo-5g; Fri, 13 Apr 2012 17:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SIkSO-0003bc-Ua
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 17:38:49 +0000
Received: from [85.158.138.51:48040] by server-12.bemta-3.messagelabs.com id
	B0/35-29760-8A4688F4; Fri, 13 Apr 2012 17:38:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334338727!22097093!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2MjA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25843 invoked from network); 13 Apr 2012 17:38:47 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	13 Apr 2012 17:38:47 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B3C6C5EC072;
	Fri, 13 Apr 2012 10:38:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=nd3yiGO2GyaTRU3YXypUFxLSonfR2xYEbp0UnFqvrPQr
	5IUc8oTWR8lP7dRKQngaRuB90Kj7CiIQwe9fbZo1uEygaOCMzQ9TiYlKMeeZrv5h
	UZsqZDWgHIX/qs8Vr9NtDKskQj2z5/LrWnvNgILA9B8Mb225G/gHtofo3SbHxFo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Mp3SLlRur5pjLc07Npt1UxV67ns=; b=ANxARjZp
	4tWlU6uuJxaH/BW97dvdNz12DnyJpwyf2wMHw8VmhW/UjB7kLPJ3YRtyuUC9Ve7W
	ARB3JXB/VlsBy5/1aR3p/JGVd6S9rIVaYHIc4K91E9feWviXlTISNH1mjyeQlfMW
	aHndxxUMjobjMu/Cc3UNB6lyX/R+r7jxLZo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id F1C0A5EC082; 
	Fri, 13 Apr 2012 10:38:45 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Apr 2012 10:38:46 -0700
Message-ID: <3107e613227a6cd7aa3ec256e1f8b7d5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAKpvNa1YakP8-kRbfuKCszfR4g0e6Wku1n2=UEc+eexNuDwB3A@mail.gmail.com>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<CAKpvNa1YakP8-kRbfuKCszfR4g0e6Wku1n2=UEc+eexNuDwB3A@mail.gmail.com>
Date: Fri, 13 Apr 2012 10:38:46 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Gianluca Guida" <glguida@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, Apr 13, 2012 at 9:19 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>> After a hvm+shadow domain dies (either clean shutdown or merciless
>> destroy), the domain is left in a zombie state with 1 (one) page left
>> dangling with a single reference.
>
> [...]
>
>> (XEN) =A0 =A0 paging assistance: shadowed 4-on-4
>
> [...]
>
>> This happens on win7 guest with or without pv drivers. It happens with
>> or
>> without shadow optimizations (SHOPT defines). It happens with or without
>> synchronized p2m lookups (patches just posted).
>
> Does it happens only in 64bit guests?
Haven't tried 32 bit (w/ wo/ PAE) guests.
Andres

>
> Thanks,
> Gianluca
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:51:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkej-0003zO-JA; Fri, 13 Apr 2012 17:51:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIkei-0003zJ-UR
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:51:33 +0000
Received: from [85.158.143.99:16092] by server-1.bemta-4.messagelabs.com id
	11/6E-20925-4A7688F4; Fri, 13 Apr 2012 17:51:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334339491!23239370!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8820 invoked from network); 13 Apr 2012 17:51:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 17:51:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIked-000E8Z-WD; Fri, 13 Apr 2012 17:51:28 +0000
Date: Fri, 13 Apr 2012 18:51:27 +0100
From: Tim Deegan <tim@xen.org>
To: Gianluca Guida <glguida@gmail.com>
Message-ID: <20120413175127.GB52993@ocelot.phlegethon.org>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
	<CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Huang2, Wei" <Wei.Huang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
	paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:08 -0700 on 13 Apr (1334311697), Gianluca Guida wrote:
> On Fri, Apr 13, 2012 at 9:29 AM, Huang2, Wei <Wei.Huang2@amd.com> wrote:
> > I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.
> 
> Yes, that is exactly what I expected to see (WC enabled). Thanks again.
> 
> Any change to get this checked in?

FWIW, Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:51:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkej-0003zO-JA; Fri, 13 Apr 2012 17:51:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SIkei-0003zJ-UR
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:51:33 +0000
Received: from [85.158.143.99:16092] by server-1.bemta-4.messagelabs.com id
	11/6E-20925-4A7688F4; Fri, 13 Apr 2012 17:51:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334339491!23239370!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8820 invoked from network); 13 Apr 2012 17:51:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Apr 2012 17:51:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SIked-000E8Z-WD; Fri, 13 Apr 2012 17:51:28 +0000
Date: Fri, 13 Apr 2012 18:51:27 +0100
From: Tim Deegan <tim@xen.org>
To: Gianluca Guida <glguida@gmail.com>
Message-ID: <20120413175127.GB52993@ocelot.phlegethon.org>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
	<CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Huang2, Wei" <Wei.Huang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
	paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:08 -0700 on 13 Apr (1334311697), Gianluca Guida wrote:
> On Fri, Apr 13, 2012 at 9:29 AM, Huang2, Wei <Wei.Huang2@amd.com> wrote:
> > I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.
> 
> Yes, that is exactly what I expected to see (WC enabled). Thanks again.
> 
> Any change to get this checked in?

FWIW, Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:57:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkke-00049a-H2; Fri, 13 Apr 2012 17:57:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIkkd-00049T-Hs
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:57:39 +0000
Received: from [193.109.254.147:13528] by server-12.bemta-14.messagelabs.com
	id 07/A3-05898-219688F4; Fri, 13 Apr 2012 17:57:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334339858!4486934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8560 invoked from network); 13 Apr 2012 17:57:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:57:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 17:57:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 18:57:37 +0100
Date: Fri, 13 Apr 2012 19:01:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1204131840110.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL] Xen MSI, mapcache, xen_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Anthony,
please pull the following branch:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_anthony


It includes two mapcache fixes, one xen_disk fix, two patches to allow
MSI injection into HVM guests and finally a patch to receive
notification from Xen for buffered io events:


Anthony PERARD (1):
      Xen, mapcache: Fix the compute of the size of bucket.

Julien Grall (1):
      xen-mapcache: don't unmap locked entry during mapcache invalidation

Stefano Stabellini (2):
      xen: handle backend deletion from xenstore
      xen: introduce an event channel for buffered io event notifications

Wei Liu (2):
      Xen: basic HVM MSI injection support.
      Xen: Add xen-apic support and hook it up.


 Makefile.target  |    2 +-
 hw/pc.c          |    8 +++++
 hw/xen.h         |    1 +
 hw/xen_apic.c    |   90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_backend.c |   17 +++++-----
 hw/xen_disk.c    |    4 ++
 xen-all.c        |   50 ++++++++++++++++++++++++++---
 xen-mapcache.c   |   15 ++++++---
 xen-stub.c       |    4 ++
 9 files changed, 171 insertions(+), 20 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 17:57:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 17:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIkke-00049a-H2; Fri, 13 Apr 2012 17:57:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIkkd-00049T-Hs
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 17:57:39 +0000
Received: from [193.109.254.147:13528] by server-12.bemta-14.messagelabs.com
	id 07/A3-05898-219688F4; Fri, 13 Apr 2012 17:57:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334339858!4486934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8560 invoked from network); 13 Apr 2012 17:57:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 17:57:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 17:57:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 18:57:37 +0100
Date: Fri, 13 Apr 2012 19:01:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1204131840110.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL] Xen MSI, mapcache, xen_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Anthony,
please pull the following branch:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_anthony


It includes two mapcache fixes, one xen_disk fix, two patches to allow
MSI injection into HVM guests and finally a patch to receive
notification from Xen for buffered io events:


Anthony PERARD (1):
      Xen, mapcache: Fix the compute of the size of bucket.

Julien Grall (1):
      xen-mapcache: don't unmap locked entry during mapcache invalidation

Stefano Stabellini (2):
      xen: handle backend deletion from xenstore
      xen: introduce an event channel for buffered io event notifications

Wei Liu (2):
      Xen: basic HVM MSI injection support.
      Xen: Add xen-apic support and hook it up.


 Makefile.target  |    2 +-
 hw/pc.c          |    8 +++++
 hw/xen.h         |    1 +
 hw/xen_apic.c    |   90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_backend.c |   17 +++++-----
 hw/xen_disk.c    |    4 ++
 xen-all.c        |   50 ++++++++++++++++++++++++++---
 xen-mapcache.c   |   15 ++++++---
 xen-stub.c       |    4 ++
 9 files changed, 171 insertions(+), 20 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:14:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIl0h-0004Qt-5Z; Fri, 13 Apr 2012 18:14:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIl0f-0004Qo-R5
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:14:14 +0000
Received: from [193.109.254.147:59872] by server-2.bemta-14.messagelabs.com id
	1B/C7-19409-5FC688F4; Fri, 13 Apr 2012 18:14:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334340851!2044164!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5808 invoked from network); 13 Apr 2012 18:14:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24147221"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:14:10 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:14:10 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIl0c-0002sp-3c;
	Fri, 13 Apr 2012 19:14:10 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 13 Apr 2012 19:14:05 +0100
Message-ID: <1334340845-43621-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] tools/build: fix distclean
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

distclean removed config/Tools.mk which was needed by tools/Rules.mk, thus
preventing distclean from running properly in the tools directory. This patch
only enforces config/Tools.mk presence when not performing a clean/distclean
target

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/Rules.mk |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 202c0dd..a2a1a58 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -4,7 +4,7 @@
 all:
 
 include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/config/Tools.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 export _INSTALL := $(INSTALL)
 INSTALL = $(XEN_ROOT)/tools/cross-install
@@ -109,6 +109,7 @@ subdir-all-% subdir-clean-% subdir-install-%: .phony
 subdir-distclean-%: .phony
 	$(MAKE) -C $* clean
 
+ifeq (,$(findstring clean,$(MAKECMDGOALS)))
 $(XEN_ROOT)/config/Tools.mk:
-	@echo "You have to run ./configure before building or installing the tools"
-	@exit 1
+	$(error You have to run ./configure before building or installing the tools)
+endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:14:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIl0h-0004Qt-5Z; Fri, 13 Apr 2012 18:14:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SIl0f-0004Qo-R5
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:14:14 +0000
Received: from [193.109.254.147:59872] by server-2.bemta-14.messagelabs.com id
	1B/C7-19409-5FC688F4; Fri, 13 Apr 2012 18:14:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334340851!2044164!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5808 invoked from network); 13 Apr 2012 18:14:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24147221"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:14:10 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:14:10 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SIl0c-0002sp-3c;
	Fri, 13 Apr 2012 19:14:10 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 13 Apr 2012 19:14:05 +0100
Message-ID: <1334340845-43621-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] tools/build: fix distclean
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

distclean removed config/Tools.mk which was needed by tools/Rules.mk, thus
preventing distclean from running properly in the tools directory. This patch
only enforces config/Tools.mk presence when not performing a clean/distclean
target

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/Rules.mk |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 202c0dd..a2a1a58 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -4,7 +4,7 @@
 all:
 
 include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/config/Tools.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 export _INSTALL := $(INSTALL)
 INSTALL = $(XEN_ROOT)/tools/cross-install
@@ -109,6 +109,7 @@ subdir-all-% subdir-clean-% subdir-install-%: .phony
 subdir-distclean-%: .phony
 	$(MAKE) -C $* clean
 
+ifeq (,$(findstring clean,$(MAKECMDGOALS)))
 $(XEN_ROOT)/config/Tools.mk:
-	@echo "You have to run ./configure before building or installing the tools"
-	@exit 1
+	$(error You have to run ./configure before building or installing the tools)
+endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:21:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIl7O-0004Zu-25; Fri, 13 Apr 2012 18:21:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIl7M-0004Zn-Ta
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:21:09 +0000
Received: from [85.158.139.83:41271] by server-3.bemta-5.messagelabs.com id
	97/14-25237-49E688F4; Fri, 13 Apr 2012 18:21:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334341267!23728417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12003 invoked from network); 13 Apr 2012 18:21:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:21:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:21:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:21:04 +0100
Received: from spare.cam.xci-test.com ([10.80.2.76]
	helo=qabil.uk.xensource.com)	by norwich.cam.xci-test.com with esmtp
	(Exim
	4.72)	(envelope-from <david.vrabel@citrix.com>)	id 1SIl7I-0002Fg-KC;
	Fri, 13 Apr 2012 18:21:04 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Apr 2012 19:20:55 +0100
Message-ID: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Tim Deegan <tim@xen.org>,
	linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

The sched clock was considered stable based on the capabilities of the
underlying hardware.  This does not make sense for Xen PV guests as:
a) the hardware TSC is not used directly as the clock source; and b)
guests may migrate to hosts with different hardware capabilities.

It is not clear to me whether the Xen clock source is supposed to be
stable and whether it should be stable across migration.  For a clock
source to be stable it must be: a) monotonic; c) synchronized across
CPUs; and c) constant rate.

There have also been reports of systems with apparently unstable
clocks where clearing sched_clock_stable has fixed problems with
migrated VMs hanging.

So, always set the sched clock as unstable when using the Xen clock
source.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/time.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 0296a95..8469b5a 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -473,6 +473,7 @@ static void __init xen_time_init(void)
 	do_settimeofday(&tp);
 
 	setup_force_cpu_cap(X86_FEATURE_TSC);
+	sched_clock_stable = 0;
 
 	xen_setup_runstate_info(cpu);
 	xen_setup_timer(cpu);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:21:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIl7O-0004Zu-25; Fri, 13 Apr 2012 18:21:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIl7M-0004Zn-Ta
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:21:09 +0000
Received: from [85.158.139.83:41271] by server-3.bemta-5.messagelabs.com id
	97/14-25237-49E688F4; Fri, 13 Apr 2012 18:21:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334341267!23728417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12003 invoked from network); 13 Apr 2012 18:21:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:21:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:21:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:21:04 +0100
Received: from spare.cam.xci-test.com ([10.80.2.76]
	helo=qabil.uk.xensource.com)	by norwich.cam.xci-test.com with esmtp
	(Exim
	4.72)	(envelope-from <david.vrabel@citrix.com>)	id 1SIl7I-0002Fg-KC;
	Fri, 13 Apr 2012 18:21:04 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Apr 2012 19:20:55 +0100
Message-ID: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Tim Deegan <tim@xen.org>,
	linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

The sched clock was considered stable based on the capabilities of the
underlying hardware.  This does not make sense for Xen PV guests as:
a) the hardware TSC is not used directly as the clock source; and b)
guests may migrate to hosts with different hardware capabilities.

It is not clear to me whether the Xen clock source is supposed to be
stable and whether it should be stable across migration.  For a clock
source to be stable it must be: a) monotonic; c) synchronized across
CPUs; and c) constant rate.

There have also been reports of systems with apparently unstable
clocks where clearing sched_clock_stable has fixed problems with
migrated VMs hanging.

So, always set the sched clock as unstable when using the Xen clock
source.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/time.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 0296a95..8469b5a 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -473,6 +473,7 @@ static void __init xen_time_init(void)
 	do_settimeofday(&tp);
 
 	setup_force_cpu_cap(X86_FEATURE_TSC);
+	sched_clock_stable = 0;
 
 	xen_setup_runstate_info(cpu);
 	xen_setup_timer(cpu);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:27:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlDV-0004ie-SH; Fri, 13 Apr 2012 18:27:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlDU-0004iZ-CU
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:27:28 +0000
Received: from [85.158.143.99:19757] by server-2.bemta-4.messagelabs.com id
	14/69-17550-F00788F4; Fri, 13 Apr 2012 18:27:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334341647!18288398!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22274 invoked from network); 13 Apr 2012 18:27:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:27:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:27:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlDS-0002Hj-UD; Fri, 13 Apr 2012 18:27:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlDS-0008JI-Qv;
	Fri, 13 Apr 2012 19:27:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.28686.774821.253615@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 19:27:26 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <686ba604624db0796ce7.1334323301@kodo2>
References: <686ba604624db0796ce7.1334323301@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Revert c/s 25150:b490ef93bad7
 tools/libfsimage: include Rules.mk first
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] Revert c/s 25150:b490ef93bad7 tools/libfsimage: include Rules.mk first"):
> tools/libfsimage/Rules.mk relies on having certain variables set already; if
> they're not set, the definitions dont' work right.  The result was a bunch
> of empty files and pygrub failing with an uninformative error message.
> 
> It's likely that this didn't cause anyone problems becasue changing the
> Makefiles didn't cause a re-build; building from a fresh repo results in
> completely empty filesystem plugin binaries.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

CCing Olaf, as he's the author of 25150.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:27:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlDV-0004ie-SH; Fri, 13 Apr 2012 18:27:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlDU-0004iZ-CU
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:27:28 +0000
Received: from [85.158.143.99:19757] by server-2.bemta-4.messagelabs.com id
	14/69-17550-F00788F4; Fri, 13 Apr 2012 18:27:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334341647!18288398!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22274 invoked from network); 13 Apr 2012 18:27:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:27:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:27:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlDS-0002Hj-UD; Fri, 13 Apr 2012 18:27:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlDS-0008JI-Qv;
	Fri, 13 Apr 2012 19:27:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20360.28686.774821.253615@mariner.uk.xensource.com>
Date: Fri, 13 Apr 2012 19:27:26 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <686ba604624db0796ce7.1334323301@kodo2>
References: <686ba604624db0796ce7.1334323301@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Revert c/s 25150:b490ef93bad7
 tools/libfsimage: include Rules.mk first
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] Revert c/s 25150:b490ef93bad7 tools/libfsimage: include Rules.mk first"):
> tools/libfsimage/Rules.mk relies on having certain variables set already; if
> they're not set, the definitions dont' work right.  The result was a bunch
> of empty files and pygrub failing with an uninformative error message.
> 
> It's likely that this didn't cause anyone problems becasue changing the
> Makefiles didn't cause a re-build; building from a fresh repo results in
> completely empty filesystem plugin binaries.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

CCing Olaf, as he's the author of 25150.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlFm-0004oC-D1; Fri, 13 Apr 2012 18:29:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlFk-0004o2-QX
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:29:49 +0000
Received: from [85.158.138.51:25364] by server-2.bemta-3.messagelabs.com id
	38/0C-09269-B90788F4; Fri, 13 Apr 2012 18:29:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334341787!17875802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25554 invoked from network); 13 Apr 2012 18:29:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:29:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:29:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:29:47 +0100
Date: Fri, 13 Apr 2012 19:33:47 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v6 0/5] prevent QEMU from waking up needlessly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this small patch series prevents QEMU from waking up needlessly on Xen
several times a second in order to check some timers.



The first patch stops QEMU from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fourth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch makes main_loop_wait wait indefinitely on select
unless we actually need a timeout.



Changes in v6:

- rebase on 7672725d41d1a04195affc1a7bd5676ba6314b14;

- dropped the buffered IO patch, that has been handled separately from
this series.


Changes in v5:

- remove the last patch to increase the timeout to 1h, replace it with a
patch to wait indefinitely on select unless we need a timeout.


Changes in v4:

- do not initialize pcspk on xen;

- disable rtc_clock only when it points to the host_clock (the default);

- make sure it compiles on older xen versions.


Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.



Shortlog and diffstat follow:

Stefano Stabellini (5):
      xen: do not initialize the interval timer and PCSPK emulator
      xen: disable rtc_clock
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      main_loop_wait: block indefinitely

 async.c          |    2 +-
 hw/pc.c          |    9 ++++++---
 main-loop.c      |   23 ++++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |   33 +++++++++++++++++----------------
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 xen-all.c        |    4 ++++
 10 files changed, 55 insertions(+), 31 deletions(-)


A git tree, based on 7672725d41d1a04195affc1a7bd5676ba6314b14, is available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-6

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlFm-0004oC-D1; Fri, 13 Apr 2012 18:29:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlFk-0004o2-QX
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:29:49 +0000
Received: from [85.158.138.51:25364] by server-2.bemta-3.messagelabs.com id
	38/0C-09269-B90788F4; Fri, 13 Apr 2012 18:29:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334341787!17875802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25554 invoked from network); 13 Apr 2012 18:29:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:29:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:29:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:29:47 +0100
Date: Fri, 13 Apr 2012 19:33:47 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v6 0/5] prevent QEMU from waking up needlessly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this small patch series prevents QEMU from waking up needlessly on Xen
several times a second in order to check some timers.



The first patch stops QEMU from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fourth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch makes main_loop_wait wait indefinitely on select
unless we actually need a timeout.



Changes in v6:

- rebase on 7672725d41d1a04195affc1a7bd5676ba6314b14;

- dropped the buffered IO patch, that has been handled separately from
this series.


Changes in v5:

- remove the last patch to increase the timeout to 1h, replace it with a
patch to wait indefinitely on select unless we need a timeout.


Changes in v4:

- do not initialize pcspk on xen;

- disable rtc_clock only when it points to the host_clock (the default);

- make sure it compiles on older xen versions.


Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.



Shortlog and diffstat follow:

Stefano Stabellini (5):
      xen: do not initialize the interval timer and PCSPK emulator
      xen: disable rtc_clock
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      main_loop_wait: block indefinitely

 async.c          |    2 +-
 hw/pc.c          |    9 ++++++---
 main-loop.c      |   23 ++++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |   33 +++++++++++++++++----------------
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 xen-all.c        |    4 ++++
 10 files changed, 55 insertions(+), 31 deletions(-)


A git tree, based on 7672725d41d1a04195affc1a7bd5676ba6314b14, is available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-6

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGw-0004uF-7G; Fri, 13 Apr 2012 18:31:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGu-0004te-DN
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:00 +0000
Received: from [85.158.143.99:34065] by server-2.bemta-4.messagelabs.com id
	7A/2B-17550-4E0788F4; Fri, 13 Apr 2012 18:31:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334341856!23024222!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10809 invoked from network); 13 Apr 2012 18:30:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286922"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-QU; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:03 +0100
Message-ID: <1334342104-30546-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 4/5] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index fe4cd6f..1166beb 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGw-0004uF-7G; Fri, 13 Apr 2012 18:31:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGu-0004te-DN
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:00 +0000
Received: from [85.158.143.99:34065] by server-2.bemta-4.messagelabs.com id
	7A/2B-17550-4E0788F4; Fri, 13 Apr 2012 18:31:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334341856!23024222!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10809 invoked from network); 13 Apr 2012 18:30:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286922"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-QU; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:03 +0100
Message-ID: <1334342104-30546-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 4/5] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index fe4cd6f..1166beb 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGu-0004tz-RG; Fri, 13 Apr 2012 18:31:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGt-0004te-5a
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:30:59 +0000
Received: from [85.158.143.99:34014] by server-2.bemta-4.messagelabs.com id
	17/2B-17550-2E0788F4; Fri, 13 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334341856!23024222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10778 invoked from network); 13 Apr 2012 18:30:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286921"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-My; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:01 +0100
Message-ID: <1334342104-30546-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 3e6de41..d1c4e72 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -593,6 +593,10 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    /* if rtc_clock is left to default (host_clock), disable it */
+    if (rtc_clock == host_clock) {
+        qemu_clock_enable(rtc_clock, false);
+    }
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGu-0004tz-RG; Fri, 13 Apr 2012 18:31:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGt-0004te-5a
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:30:59 +0000
Received: from [85.158.143.99:34014] by server-2.bemta-4.messagelabs.com id
	17/2B-17550-2E0788F4; Fri, 13 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334341856!23024222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10778 invoked from network); 13 Apr 2012 18:30:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286921"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-My; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:01 +0100
Message-ID: <1334342104-30546-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 3e6de41..d1c4e72 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -593,6 +593,10 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    /* if rtc_clock is left to default (host_clock), disable it */
+    if (rtc_clock == host_clock) {
+        qemu_clock_enable(rtc_clock, false);
+    }
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGx-0004uf-Jo; Fri, 13 Apr 2012 18:31:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGw-0004uD-Gt
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:02 +0000
Received: from [85.158.138.51:30683] by server-2.bemta-3.messagelabs.com id
	6D/0D-09269-5E0788F4; Fri, 13 Apr 2012 18:31:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334341858!22102137!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4452 invoked from network); 13 Apr 2012 18:31:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286925"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-R2; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:04 +0100
Message-ID: <1334342104-30546-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 5/5] main_loop_wait: block indefinitely
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- remove qemu_calculate_timeout;

- explicitly size timeout to uint32_t;

- introduce slirp_update_timeout;

- pass NULL as timeout argument to select in case timeout is the maximum
value;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paul Brook <paul@codesourcery.com>
---
 async.c          |    2 +-
 main-loop.c      |   23 ++++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |    5 -----
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 8 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index 1ebdc4b..f363748 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -226,7 +226,7 @@ static int max_priority;
 
 #ifndef _WIN32
 static void glib_select_fill(int *max_fd, fd_set *rfds, fd_set *wfds,
-                             fd_set *xfds, int *cur_timeout)
+                             fd_set *xfds, uint32_t *cur_timeout)
 {
     GMainContext *context = g_main_context_default();
     int i;
@@ -288,20 +288,24 @@ static void glib_select_poll(fd_set *rfds, fd_set *wfds, fd_set *xfds,
     }
 }
 
-static int os_host_main_loop_wait(int timeout)
+static int os_host_main_loop_wait(uint32_t timeout)
 {
-    struct timeval tv;
+    struct timeval tv, *tvarg = NULL;
     int ret;
 
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &timeout);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
@@ -400,7 +404,7 @@ void qemu_fd_register(int fd)
                    FD_CONNECT | FD_WRITE | FD_OOB);
 }
 
-static int os_host_main_loop_wait(int timeout)
+static int os_host_main_loop_wait(uint32_t timeout)
 {
     GMainContext *context = g_main_context_default();
     int ret, i;
@@ -463,12 +467,12 @@ static int os_host_main_loop_wait(int timeout)
 
 int main_loop_wait(int nonblocking)
 {
-    int ret, timeout;
+    int ret;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
@@ -480,6 +484,7 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
diff --git a/main-loop.h b/main-loop.h
index e743aa0..c06b8bc 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -365,6 +365,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index 1166beb..887babf 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index 661bbe7..094e730 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -63,7 +63,6 @@ void qemu_run_timers(QEMUClock *clock);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/qemu-tool.c b/qemu-tool.c
index edb84f5..a0544d7 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -91,6 +91,10 @@ int qemu_init_main_loop(void)
     return main_loop_init();
 }
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+}
+
 void slirp_select_fill(int *pnfds, fd_set *readfds,
                        fd_set *writefds, fd_set *xfds)
 {
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..77527ad 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -15,6 +15,7 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
                   struct in_addr vnameserver, void *opaque);
 void slirp_cleanup(Slirp *slirp);
 
+void slirp_update_timeout(uint32_t *timeout);
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds);
 
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 1502830..90473eb 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -258,6 +258,13 @@ void slirp_cleanup(Slirp *slirp)
 #define CONN_CANFRCV(so) (((so)->so_state & (SS_FCANTRCVMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
 #define UPD_NFDS(x) if (nfds < (x)) nfds = (x)
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+    if (!QTAILQ_EMPTY(&slirp_instances)) {
+        *timeout = MIN(1000, *timeout);
+    }
+}
+
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGx-0004uf-Jo; Fri, 13 Apr 2012 18:31:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGw-0004uD-Gt
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:02 +0000
Received: from [85.158.138.51:30683] by server-2.bemta-3.messagelabs.com id
	6D/0D-09269-5E0788F4; Fri, 13 Apr 2012 18:31:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334341858!22102137!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4452 invoked from network); 13 Apr 2012 18:31:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286925"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-R2; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:04 +0100
Message-ID: <1334342104-30546-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 5/5] main_loop_wait: block indefinitely
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- remove qemu_calculate_timeout;

- explicitly size timeout to uint32_t;

- introduce slirp_update_timeout;

- pass NULL as timeout argument to select in case timeout is the maximum
value;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paul Brook <paul@codesourcery.com>
---
 async.c          |    2 +-
 main-loop.c      |   23 ++++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |    5 -----
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 8 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index 1ebdc4b..f363748 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -226,7 +226,7 @@ static int max_priority;
 
 #ifndef _WIN32
 static void glib_select_fill(int *max_fd, fd_set *rfds, fd_set *wfds,
-                             fd_set *xfds, int *cur_timeout)
+                             fd_set *xfds, uint32_t *cur_timeout)
 {
     GMainContext *context = g_main_context_default();
     int i;
@@ -288,20 +288,24 @@ static void glib_select_poll(fd_set *rfds, fd_set *wfds, fd_set *xfds,
     }
 }
 
-static int os_host_main_loop_wait(int timeout)
+static int os_host_main_loop_wait(uint32_t timeout)
 {
-    struct timeval tv;
+    struct timeval tv, *tvarg = NULL;
     int ret;
 
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &timeout);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
@@ -400,7 +404,7 @@ void qemu_fd_register(int fd)
                    FD_CONNECT | FD_WRITE | FD_OOB);
 }
 
-static int os_host_main_loop_wait(int timeout)
+static int os_host_main_loop_wait(uint32_t timeout)
 {
     GMainContext *context = g_main_context_default();
     int ret, i;
@@ -463,12 +467,12 @@ static int os_host_main_loop_wait(int timeout)
 
 int main_loop_wait(int nonblocking)
 {
-    int ret, timeout;
+    int ret;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
@@ -480,6 +484,7 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
diff --git a/main-loop.h b/main-loop.h
index e743aa0..c06b8bc 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -365,6 +365,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index 1166beb..887babf 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index 661bbe7..094e730 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -63,7 +63,6 @@ void qemu_run_timers(QEMUClock *clock);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/qemu-tool.c b/qemu-tool.c
index edb84f5..a0544d7 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -91,6 +91,10 @@ int qemu_init_main_loop(void)
     return main_loop_init();
 }
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+}
+
 void slirp_select_fill(int *pnfds, fd_set *readfds,
                        fd_set *writefds, fd_set *xfds)
 {
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..77527ad 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -15,6 +15,7 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
                   struct in_addr vnameserver, void *opaque);
 void slirp_cleanup(Slirp *slirp);
 
+void slirp_update_timeout(uint32_t *timeout);
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds);
 
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 1502830..90473eb 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -258,6 +258,13 @@ void slirp_cleanup(Slirp *slirp)
 #define CONN_CANFRCV(so) (((so)->so_state & (SS_FCANTRCVMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
 #define UPD_NFDS(x) if (nfds < (x)) nfds = (x)
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+    if (!QTAILQ_EMPTY(&slirp_instances)) {
+        *timeout = MIN(1000, *timeout);
+    }
+}
+
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGy-0004us-0t; Fri, 13 Apr 2012 18:31:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGw-0004te-OX
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:02 +0000
Received: from [85.158.143.99:34171] by server-2.bemta-4.messagelabs.com id
	3F/2B-17550-6E0788F4; Fri, 13 Apr 2012 18:31:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334341856!23024222!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10838 invoked from network); 13 Apr 2012 18:31:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286924"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-MH; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:00 +0100
Message-ID: <1334342104-30546-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 1/5] xen: do not initialize the interval
	timer and PCSPK emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PIT and PCSPK are emulated by the hypervisor so we don't need to emulate
them in Qemu: this patch prevents Qemu from waking up needlessly at
PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 67f0479..08c69e9 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -46,6 +46,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1089,7 +1090,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     qemu_irq pit_alt_irq = NULL;
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1120,14 +1121,16 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     if (kvm_irqchip_in_kernel()) {
         pit = kvm_pit_init(isa_bus, 0x40);
-    } else {
+    } else if (!xen_available()) {
         pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq);
     }
     if (hpet) {
         /* connect PIT to output control line of the HPET */
         qdev_connect_gpio_out(hpet, 0, qdev_get_gpio_in(&pit->qdev, 0));
     }
-    pcspk_init(isa_bus, pit);
+    if (!xen_available()) {
+        pcspk_init(isa_bus, pit);
+    }
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
         if (serial_hds[i]) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlGy-0004us-0t; Fri, 13 Apr 2012 18:31:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlGw-0004te-OX
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:02 +0000
Received: from [85.158.143.99:34171] by server-2.bemta-4.messagelabs.com id
	3F/2B-17550-6E0788F4; Fri, 13 Apr 2012 18:31:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334341856!23024222!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10838 invoked from network); 13 Apr 2012 18:31:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="190286924"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-MH; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:00 +0100
Message-ID: <1334342104-30546-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 1/5] xen: do not initialize the interval
	timer and PCSPK emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PIT and PCSPK are emulated by the hypervisor so we don't need to emulate
them in Qemu: this patch prevents Qemu from waking up needlessly at
PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 67f0479..08c69e9 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -46,6 +46,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1089,7 +1090,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     qemu_irq pit_alt_irq = NULL;
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1120,14 +1121,16 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     if (kvm_irqchip_in_kernel()) {
         pit = kvm_pit_init(isa_bus, 0x40);
-    } else {
+    } else if (!xen_available()) {
         pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq);
     }
     if (hpet) {
         /* connect PIT to output control line of the HPET */
         qdev_connect_gpio_out(hpet, 0, qdev_get_gpio_in(&pit->qdev, 0));
     }
-    pcspk_init(isa_bus, pit);
+    if (!xen_available()) {
+        pcspk_init(isa_bus, pit);
+    }
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
         if (serial_hds[i]) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlHC-0004zN-Kc; Fri, 13 Apr 2012 18:31:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlHA-0004yF-OQ
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:16 +0000
Received: from [85.158.143.99:34684] by server-2.bemta-4.messagelabs.com id
	7F/4B-17550-3F0788F4; Fri, 13 Apr 2012 18:31:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334341874!22654405!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21584 invoked from network); 13 Apr 2012 18:31:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24147810"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-Oi; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:02 +0100
Message-ID: <1334342104-30546-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 3/5] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 80bcc56..fe4cd6f 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -696,13 +696,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -757,16 +761,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlHC-0004zN-Kc; Fri, 13 Apr 2012 18:31:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlHA-0004yF-OQ
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:16 +0000
Received: from [85.158.143.99:34684] by server-2.bemta-4.messagelabs.com id
	7F/4B-17550-3F0788F4; Fri, 13 Apr 2012 18:31:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334341874!22654405!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21584 invoked from network); 13 Apr 2012 18:31:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24147810"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:30:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:30:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlGk-0003Dp-Oi; Fri, 13 Apr 2012 19:30:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 13 Apr 2012 19:35:02 +0100
Message-ID: <1334342104-30546-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204131918380.26786@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, jan.kiszka@siemens.com,
	avi@redhat.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v6 3/5] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 80bcc56..fe4cd6f 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -696,13 +696,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -757,16 +761,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlHP-000556-2n; Fri, 13 Apr 2012 18:31:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIlHO-00054T-6R
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:30 +0000
Received: from [193.109.254.147:36183] by server-9.bemta-14.messagelabs.com id
	45/28-05787-101788F4; Fri, 13 Apr 2012 18:31:29 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334341888!2045550!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5159 invoked from network); 13 Apr 2012 18:31:28 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:28 -0000
Received: by bkwj5 with SMTP id j5so2958583bkw.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 11:31:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=4o5+Lczg/1J1AcMLTIxJMobAfmgOAbdR4vc3L4jydMQ=;
	b=LKpFU02klSBmWez5Ko3n8GdWXNG65RVckQP7wq6t6JbvN8SOmpDRwkakOK94VDzqEx
	8AQopBrvmttampDF+/posmox+x5Lw9k2eL4TuZ2EqyteCRXMOU7mbqmrXdBtfuyq69En
	m+t4NTjT2OIsWkahDKmFI/+ko0I0gFBCcsD/aqwFeXVBt3XC78G/zkutl/V4r2fT0nwv
	xXoihVdpgGcTRBX45ion/kLzEDwrNRtN4h1r7vcC2pBe9DkG1VL/e5XXNNbsTqD/fBKY
	k+nQHpGMCdrXnb9EAsdtzFoUOPIbLjF6K19pOFSF0qPvmLukocT7gAdOeUbL+IdDmkFA
	vgaw==
MIME-Version: 1.0
Received: by 10.204.131.81 with SMTP id w17mr140579bks.45.1334341887716; Fri,
	13 Apr 2012 11:31:27 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 11:31:27 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
Date: Fri, 13 Apr 2012 11:31:27 -0700
Message-ID: <CA+2rt41ctpU-vhR7=u_r45=o8djpq0-5YE5jcj_4FR2bWYu5pQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQlmQf5OaHXOlI1x2I1bEOzT4qka6j+ZH2jG/EtSTfqm8oi3Kl7DqQFoWFxEJAyazboQWcZs
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <jbeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6198059413667109237=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6198059413667109237==
Content-Type: multipart/alternative; boundary=00151747bdc639eed604bd93aee2

--00151747bdc639eed604bd93aee2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <david.vrabel@citrix.com>wrote:

> From: David Vrabel <david.vrabel@citrix.com>
>
> The sched clock was considered stable based on the capabilities of the
> underlying hardware.  This does not make sense for Xen PV guests as:
> a) the hardware TSC is not used directly as the clock source; and b)
> guests may migrate to hosts with different hardware capabilities.
>
> It is not clear to me whether the Xen clock source is supposed to be
> stable and whether it should be stable across migration.  For a clock
> source to be stable it must be: a) monotonic; c) synchronized across
> CPUs; and c) constant rate.
>
> There have also been reports of systems with apparently unstable
> clocks where clearing sched_clock_stable has fixed problems with
> migrated VMs hanging.
>
> So, always set the sched clock as unstable when using the Xen clock
> source.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..8469b5a 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>        do_settimeofday(&tp);
>
>        setup_force_cpu_cap(X86_FEATURE_TSC);
> +       sched_clock_stable = 0;
>
>        xen_setup_runstate_info(cpu);
>        xen_setup_timer(cpu);
> --
> 1.7.2.5
>
>
I really prefer to hide nonstop tsc feature from Xen side, rather than let
Linux kernel to have a condition that "Nonstop TSC feature existed, but
sched_clock_stable=0".

For the other context, please refer to the discussion at xen-devel.

http://lists.xen.org/archives/html/xen-devel/2012-04/msg00888.html
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.html

-- 
regards
Yang, Sheng

--00151747bdc639eed604bd93aee2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <=
span dir=3D"ltr">&lt;<a href=3D"mailto:david.vrabel@citrix.com">david.vrabe=
l@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: David Vrabel &lt;<a href=3D"mailto:david.vrabel@citrix.com">david.vra=
bel@citrix.com</a>&gt;<br>
<br>
The sched clock was considered stable based on the capabilities of the<br>
underlying hardware. =A0This does not make sense for Xen PV guests as:<br>
a) the hardware TSC is not used directly as the clock source; and b)<br>
guests may migrate to hosts with different hardware capabilities.<br>
<br>
It is not clear to me whether the Xen clock source is supposed to be<br>
stable and whether it should be stable across migration. =A0For a clock<br>
source to be stable it must be: a) monotonic; c) synchronized across<br>
CPUs; and c) constant rate.<br>
<br>
There have also been reports of systems with apparently unstable<br>
clocks where clearing sched_clock_stable has fixed problems with<br>
migrated VMs hanging.<br>
<br>
So, always set the sched clock as unstable when using the Xen clock<br>
source.<br>
<br>
Signed-off-by: David Vrabel &lt;<a href=3D"mailto:david.vrabel@citrix.com">=
david.vrabel@citrix.com</a>&gt;<br>
---<br>
=A0arch/x86/xen/time.c | =A0 =A01 +<br>
=A01 files changed, 1 insertions(+), 0 deletions(-)<br>
<br>
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c<br>
index 0296a95..8469b5a 100644<br>
--- a/arch/x86/xen/time.c<br>
+++ b/arch/x86/xen/time.c<br>
@@ -473,6 +473,7 @@ static void __init xen_time_init(void)<br>
 =A0 =A0 =A0 =A0do_settimeofday(&amp;tp);<br>
<br>
 =A0 =A0 =A0 =A0setup_force_cpu_cap(X86_FEATURE_TSC);<br>
+ =A0 =A0 =A0 sched_clock_stable =3D 0;<br>
<br>
 =A0 =A0 =A0 =A0xen_setup_runstate_info(cpu);<br>
 =A0 =A0 =A0 =A0xen_setup_timer(cpu);<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
1.7.2.5<br>
<br></font></span></blockquote><div><br></div><div>I really prefer to hide =
nonstop tsc feature from Xen side, rather than let Linux kernel to have a c=
ondition that &quot;Nonstop TSC feature existed, but sched_clock_stable=3D0=
&quot;.</div>
<div>=A0</div><div>For the other context, please refer to the discussion at=
 xen-devel.</div><div><br></div></div><a href=3D"http://lists.xen.org/archi=
ves/html/xen-devel/2012-04/msg00888.html">http://lists.xen.org/archives/htm=
l/xen-devel/2012-04/msg00888.html</a><br>
<a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.ht=
ml">http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.html</a><=
br clear=3D"all"><div><br></div>-- <br><div>regards</div><div>Yang, Sheng</=
div>
<br>

--00151747bdc639eed604bd93aee2--


--===============6198059413667109237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6198059413667109237==--


From xen-devel-bounces@lists.xen.org Fri Apr 13 18:31:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlHP-000556-2n; Fri, 13 Apr 2012 18:31:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIlHO-00054T-6R
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:31:30 +0000
Received: from [193.109.254.147:36183] by server-9.bemta-14.messagelabs.com id
	45/28-05787-101788F4; Fri, 13 Apr 2012 18:31:29 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334341888!2045550!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5159 invoked from network); 13 Apr 2012 18:31:28 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:31:28 -0000
Received: by bkwj5 with SMTP id j5so2958583bkw.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 11:31:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=4o5+Lczg/1J1AcMLTIxJMobAfmgOAbdR4vc3L4jydMQ=;
	b=LKpFU02klSBmWez5Ko3n8GdWXNG65RVckQP7wq6t6JbvN8SOmpDRwkakOK94VDzqEx
	8AQopBrvmttampDF+/posmox+x5Lw9k2eL4TuZ2EqyteCRXMOU7mbqmrXdBtfuyq69En
	m+t4NTjT2OIsWkahDKmFI/+ko0I0gFBCcsD/aqwFeXVBt3XC78G/zkutl/V4r2fT0nwv
	xXoihVdpgGcTRBX45ion/kLzEDwrNRtN4h1r7vcC2pBe9DkG1VL/e5XXNNbsTqD/fBKY
	k+nQHpGMCdrXnb9EAsdtzFoUOPIbLjF6K19pOFSF0qPvmLukocT7gAdOeUbL+IdDmkFA
	vgaw==
MIME-Version: 1.0
Received: by 10.204.131.81 with SMTP id w17mr140579bks.45.1334341887716; Fri,
	13 Apr 2012 11:31:27 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 11:31:27 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
Date: Fri, 13 Apr 2012 11:31:27 -0700
Message-ID: <CA+2rt41ctpU-vhR7=u_r45=o8djpq0-5YE5jcj_4FR2bWYu5pQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQlmQf5OaHXOlI1x2I1bEOzT4qka6j+ZH2jG/EtSTfqm8oi3Kl7DqQFoWFxEJAyazboQWcZs
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <jbeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6198059413667109237=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6198059413667109237==
Content-Type: multipart/alternative; boundary=00151747bdc639eed604bd93aee2

--00151747bdc639eed604bd93aee2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <david.vrabel@citrix.com>wrote:

> From: David Vrabel <david.vrabel@citrix.com>
>
> The sched clock was considered stable based on the capabilities of the
> underlying hardware.  This does not make sense for Xen PV guests as:
> a) the hardware TSC is not used directly as the clock source; and b)
> guests may migrate to hosts with different hardware capabilities.
>
> It is not clear to me whether the Xen clock source is supposed to be
> stable and whether it should be stable across migration.  For a clock
> source to be stable it must be: a) monotonic; c) synchronized across
> CPUs; and c) constant rate.
>
> There have also been reports of systems with apparently unstable
> clocks where clearing sched_clock_stable has fixed problems with
> migrated VMs hanging.
>
> So, always set the sched clock as unstable when using the Xen clock
> source.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..8469b5a 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>        do_settimeofday(&tp);
>
>        setup_force_cpu_cap(X86_FEATURE_TSC);
> +       sched_clock_stable = 0;
>
>        xen_setup_runstate_info(cpu);
>        xen_setup_timer(cpu);
> --
> 1.7.2.5
>
>
I really prefer to hide nonstop tsc feature from Xen side, rather than let
Linux kernel to have a condition that "Nonstop TSC feature existed, but
sched_clock_stable=0".

For the other context, please refer to the discussion at xen-devel.

http://lists.xen.org/archives/html/xen-devel/2012-04/msg00888.html
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.html

-- 
regards
Yang, Sheng

--00151747bdc639eed604bd93aee2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <=
span dir=3D"ltr">&lt;<a href=3D"mailto:david.vrabel@citrix.com">david.vrabe=
l@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: David Vrabel &lt;<a href=3D"mailto:david.vrabel@citrix.com">david.vra=
bel@citrix.com</a>&gt;<br>
<br>
The sched clock was considered stable based on the capabilities of the<br>
underlying hardware. =A0This does not make sense for Xen PV guests as:<br>
a) the hardware TSC is not used directly as the clock source; and b)<br>
guests may migrate to hosts with different hardware capabilities.<br>
<br>
It is not clear to me whether the Xen clock source is supposed to be<br>
stable and whether it should be stable across migration. =A0For a clock<br>
source to be stable it must be: a) monotonic; c) synchronized across<br>
CPUs; and c) constant rate.<br>
<br>
There have also been reports of systems with apparently unstable<br>
clocks where clearing sched_clock_stable has fixed problems with<br>
migrated VMs hanging.<br>
<br>
So, always set the sched clock as unstable when using the Xen clock<br>
source.<br>
<br>
Signed-off-by: David Vrabel &lt;<a href=3D"mailto:david.vrabel@citrix.com">=
david.vrabel@citrix.com</a>&gt;<br>
---<br>
=A0arch/x86/xen/time.c | =A0 =A01 +<br>
=A01 files changed, 1 insertions(+), 0 deletions(-)<br>
<br>
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c<br>
index 0296a95..8469b5a 100644<br>
--- a/arch/x86/xen/time.c<br>
+++ b/arch/x86/xen/time.c<br>
@@ -473,6 +473,7 @@ static void __init xen_time_init(void)<br>
 =A0 =A0 =A0 =A0do_settimeofday(&amp;tp);<br>
<br>
 =A0 =A0 =A0 =A0setup_force_cpu_cap(X86_FEATURE_TSC);<br>
+ =A0 =A0 =A0 sched_clock_stable =3D 0;<br>
<br>
 =A0 =A0 =A0 =A0xen_setup_runstate_info(cpu);<br>
 =A0 =A0 =A0 =A0xen_setup_timer(cpu);<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
1.7.2.5<br>
<br></font></span></blockquote><div><br></div><div>I really prefer to hide =
nonstop tsc feature from Xen side, rather than let Linux kernel to have a c=
ondition that &quot;Nonstop TSC feature existed, but sched_clock_stable=3D0=
&quot;.</div>
<div>=A0</div><div>For the other context, please refer to the discussion at=
 xen-devel.</div><div><br></div></div><a href=3D"http://lists.xen.org/archi=
ves/html/xen-devel/2012-04/msg00888.html">http://lists.xen.org/archives/htm=
l/xen-devel/2012-04/msg00888.html</a><br>
<a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.ht=
ml">http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.html</a><=
br clear=3D"all"><div><br></div>-- <br><div>regards</div><div>Yang, Sheng</=
div>
<br>

--00151747bdc639eed604bd93aee2--


--===============6198059413667109237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6198059413667109237==--


From xen-devel-bounces@lists.xen.org Fri Apr 13 18:33:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlJL-0005YW-Mm; Fri, 13 Apr 2012 18:33:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIlJJ-0005Y9-TR
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:33:30 +0000
Received: from [85.158.139.83:28680] by server-6.bemta-5.messagelabs.com id
	CF/44-13222-971788F4; Fri, 13 Apr 2012 18:33:29 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334342008!19789018!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16105 invoked from network); 13 Apr 2012 18:33:28 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:33:28 -0000
Received: by bkwj5 with SMTP id j5so2959867bkw.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 11:33:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=r4u6G0WsBIpPDA/jbzqWnpV4dhO+NLIqthT9SHnZpvQ=;
	b=VHTp8moPF/beS0NCYKTnNklot9s30/0bQmz6TJNtqN9aUmvT+3MvNI2SJM02DJqS/V
	C3d+1jfxxRugB2q7mmWxXEcB7RRzqdngY9BUv9NHtuR6ng1AhwPbJuNvTv3B8wJiOVrU
	Tmufm/gyDD1XaTAEKnBuWT9XkJbUUn1ZavK3OLClyyHIj48o7Puywe7X9Yjpv6dIQg4q
	uwSfG9fZGjfkDweihXPCuhRFCX+mYnNKxDItr1LbHw0oQSiHYaOLJWC7cgfIE8Kyq+0R
	awvoP5+fujlbCtRiM37xv13Obww0Rflv2+BLgJCjkzvUcBUTCtg7C6ScjQXXq6CKCX8T
	6w+A==
MIME-Version: 1.0
Received: by 10.204.154.66 with SMTP id n2mr822325bkw.77.1334342008085; Fri,
	13 Apr 2012 11:33:28 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 11:33:28 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
Date: Fri, 13 Apr 2012 11:33:28 -0700
Message-ID: <CA+2rt42FmLZ4OK4ZGdpeOHBnK1msxHkxZjJx6Lzz5cRO_rwmtQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQl4ngcceO9ltQT/ZIuWMISHl9ozdSxw+MyIIU4QNUcQPytlrM6vMZuqJHIOzIGRrDinYoqC
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <jbeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <david.vrabel@citrix.com> wr=
ote:
>
> From: David Vrabel <david.vrabel@citrix.com>
>
> The sched clock was considered stable based on the capabilities of the
> underlying hardware. =A0This does not make sense for Xen PV guests as:
> a) the hardware TSC is not used directly as the clock source; and b)
> guests may migrate to hosts with different hardware capabilities.
>
> It is not clear to me whether the Xen clock source is supposed to be
> stable and whether it should be stable across migration. =A0For a clock
> source to be stable it must be: a) monotonic; c) synchronized across
> CPUs; and c) constant rate.
>
> There have also been reports of systems with apparently unstable
> clocks where clearing sched_clock_stable has fixed problems with
> migrated VMs hanging.
>
> So, always set the sched clock as unstable when using the Xen clock
> source.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> =A0arch/x86/xen/time.c | =A0 =A01 +
> =A01 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..8469b5a 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> =A0 =A0 =A0 =A0do_settimeofday(&tp);
>
> =A0 =A0 =A0 =A0setup_force_cpu_cap(X86_FEATURE_TSC);
> + =A0 =A0 =A0 sched_clock_stable =3D 0;
>
> =A0 =A0 =A0 =A0xen_setup_runstate_info(cpu);
> =A0 =A0 =A0 =A0xen_setup_timer(cpu);
> --
> 1.7.2.5
>

(Sorry for duplicate posts, gmail is really not a ideal client for
lkml - though exchange is worse...)

I really prefer to hide nonstop tsc feature from Xen side, rather than
let Linux kernel to have a condition that "Nonstop TSC feature
existed, but sched_clock_stable=3D0".

For the other context, please refer to the discussion at xen-devel.

http://lists.xen.org/archives/html/xen-devel/2012-04/msg00888.html
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.html

--
regards
Yang, Sheng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:33:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlJL-0005YW-Mm; Fri, 13 Apr 2012 18:33:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SIlJJ-0005Y9-TR
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:33:30 +0000
Received: from [85.158.139.83:28680] by server-6.bemta-5.messagelabs.com id
	CF/44-13222-971788F4; Fri, 13 Apr 2012 18:33:29 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334342008!19789018!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16105 invoked from network); 13 Apr 2012 18:33:28 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:33:28 -0000
Received: by bkwj5 with SMTP id j5so2959867bkw.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Apr 2012 11:33:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=r4u6G0WsBIpPDA/jbzqWnpV4dhO+NLIqthT9SHnZpvQ=;
	b=VHTp8moPF/beS0NCYKTnNklot9s30/0bQmz6TJNtqN9aUmvT+3MvNI2SJM02DJqS/V
	C3d+1jfxxRugB2q7mmWxXEcB7RRzqdngY9BUv9NHtuR6ng1AhwPbJuNvTv3B8wJiOVrU
	Tmufm/gyDD1XaTAEKnBuWT9XkJbUUn1ZavK3OLClyyHIj48o7Puywe7X9Yjpv6dIQg4q
	uwSfG9fZGjfkDweihXPCuhRFCX+mYnNKxDItr1LbHw0oQSiHYaOLJWC7cgfIE8Kyq+0R
	awvoP5+fujlbCtRiM37xv13Obww0Rflv2+BLgJCjkzvUcBUTCtg7C6ScjQXXq6CKCX8T
	6w+A==
MIME-Version: 1.0
Received: by 10.204.154.66 with SMTP id n2mr822325bkw.77.1334342008085; Fri,
	13 Apr 2012 11:33:28 -0700 (PDT)
Received: by 10.204.42.24 with HTTP; Fri, 13 Apr 2012 11:33:28 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
Date: Fri, 13 Apr 2012 11:33:28 -0700
Message-ID: <CA+2rt42FmLZ4OK4ZGdpeOHBnK1msxHkxZjJx6Lzz5cRO_rwmtQ@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQl4ngcceO9ltQT/ZIuWMISHl9ozdSxw+MyIIU4QNUcQPytlrM6vMZuqJHIOzIGRrDinYoqC
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <jbeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <david.vrabel@citrix.com> wr=
ote:
>
> From: David Vrabel <david.vrabel@citrix.com>
>
> The sched clock was considered stable based on the capabilities of the
> underlying hardware. =A0This does not make sense for Xen PV guests as:
> a) the hardware TSC is not used directly as the clock source; and b)
> guests may migrate to hosts with different hardware capabilities.
>
> It is not clear to me whether the Xen clock source is supposed to be
> stable and whether it should be stable across migration. =A0For a clock
> source to be stable it must be: a) monotonic; c) synchronized across
> CPUs; and c) constant rate.
>
> There have also been reports of systems with apparently unstable
> clocks where clearing sched_clock_stable has fixed problems with
> migrated VMs hanging.
>
> So, always set the sched clock as unstable when using the Xen clock
> source.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> =A0arch/x86/xen/time.c | =A0 =A01 +
> =A01 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..8469b5a 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> =A0 =A0 =A0 =A0do_settimeofday(&tp);
>
> =A0 =A0 =A0 =A0setup_force_cpu_cap(X86_FEATURE_TSC);
> + =A0 =A0 =A0 sched_clock_stable =3D 0;
>
> =A0 =A0 =A0 =A0xen_setup_runstate_info(cpu);
> =A0 =A0 =A0 =A0xen_setup_timer(cpu);
> --
> 1.7.2.5
>

(Sorry for duplicate posts, gmail is really not a ideal client for
lkml - though exchange is worse...)

I really prefer to hide nonstop tsc feature from Xen side, rather than
let Linux kernel to have a condition that "Nonstop TSC feature
existed, but sched_clock_stable=3D0".

For the other context, please refer to the discussion at xen-devel.

http://lists.xen.org/archives/html/xen-devel/2012-04/msg00888.html
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00969.html

--
regards
Yang, Sheng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:39:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlP4-0005zT-G3; Fri, 13 Apr 2012 18:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIlP2-0005zO-BS
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:39:24 +0000
Received: from [85.158.139.83:49165] by server-12.bemta-5.messagelabs.com id
	42/C0-05587-BD2788F4; Fri, 13 Apr 2012 18:39:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334342361!19856725!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31456 invoked from network); 13 Apr 2012 18:39:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24148042"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:39:21 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	14:39:21 -0400
Message-ID: <4F8872D7.7050507@citrix.com>
Date: Fri, 13 Apr 2012 19:39:19 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Sheng Yang <sheng@yasker.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<CA+2rt41ctpU-vhR7=u_r45=o8djpq0-5YE5jcj_4FR2bWYu5pQ@mail.gmail.com>
In-Reply-To: <CA+2rt41ctpU-vhR7=u_r45=o8djpq0-5YE5jcj_4FR2bWYu5pQ@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <jbeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 19:31, Sheng Yang wrote:
> On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <david.vrabel@citrix.com
> <mailto:david.vrabel@citrix.com>> wrote:
> 
>     From: David Vrabel <david.vrabel@citrix.com
>     <mailto:david.vrabel@citrix.com>>
> 
>     The sched clock was considered stable based on the capabilities of the
>     underlying hardware.  This does not make sense for Xen PV guests as:
>     a) the hardware TSC is not used directly as the clock source; and b)
>     guests may migrate to hosts with different hardware capabilities.
> 
>     It is not clear to me whether the Xen clock source is supposed to be
>     stable and whether it should be stable across migration.  For a clock
>     source to be stable it must be: a) monotonic; c) synchronized across
>     CPUs; and c) constant rate.
> 
>     There have also been reports of systems with apparently unstable
>     clocks where clearing sched_clock_stable has fixed problems with
>     migrated VMs hanging.
> 
>     So, always set the sched clock as unstable when using the Xen clock
>     source.
> 
>     Signed-off-by: David Vrabel <david.vrabel@citrix.com
>     <mailto:david.vrabel@citrix.com>>
>     ---
>      arch/x86/xen/time.c |    1 +
>      1 files changed, 1 insertions(+), 0 deletions(-)
> 
>     diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>     index 0296a95..8469b5a 100644
>     --- a/arch/x86/xen/time.c
>     +++ b/arch/x86/xen/time.c
>     @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>            do_settimeofday(&tp);
> 
>            setup_force_cpu_cap(X86_FEATURE_TSC);
>     +       sched_clock_stable = 0;
> 
>            xen_setup_runstate_info(cpu);
>            xen_setup_timer(cpu);
>     --
>     1.7.2.5
> 
> 
> I really prefer to hide nonstop tsc feature from Xen side, rather than
> let Linux kernel to have a condition that "Nonstop TSC feature existed,
> but sched_clock_stable=0".

I disagree.  The decision on whether the clock is stable or not should
be in the Xen clock source code.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:39:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlP4-0005zT-G3; Fri, 13 Apr 2012 18:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SIlP2-0005zO-BS
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:39:24 +0000
Received: from [85.158.139.83:49165] by server-12.bemta-5.messagelabs.com id
	42/C0-05587-BD2788F4; Fri, 13 Apr 2012 18:39:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334342361!19856725!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31456 invoked from network); 13 Apr 2012 18:39:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24148042"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:39:21 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012
	14:39:21 -0400
Message-ID: <4F8872D7.7050507@citrix.com>
Date: Fri, 13 Apr 2012 19:39:19 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Sheng Yang <sheng@yasker.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<CA+2rt41ctpU-vhR7=u_r45=o8djpq0-5YE5jcj_4FR2bWYu5pQ@mail.gmail.com>
In-Reply-To: <CA+2rt41ctpU-vhR7=u_r45=o8djpq0-5YE5jcj_4FR2bWYu5pQ@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <jbeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/04/12 19:31, Sheng Yang wrote:
> On Fri, Apr 13, 2012 at 11:20 AM, David Vrabel <david.vrabel@citrix.com
> <mailto:david.vrabel@citrix.com>> wrote:
> 
>     From: David Vrabel <david.vrabel@citrix.com
>     <mailto:david.vrabel@citrix.com>>
> 
>     The sched clock was considered stable based on the capabilities of the
>     underlying hardware.  This does not make sense for Xen PV guests as:
>     a) the hardware TSC is not used directly as the clock source; and b)
>     guests may migrate to hosts with different hardware capabilities.
> 
>     It is not clear to me whether the Xen clock source is supposed to be
>     stable and whether it should be stable across migration.  For a clock
>     source to be stable it must be: a) monotonic; c) synchronized across
>     CPUs; and c) constant rate.
> 
>     There have also been reports of systems with apparently unstable
>     clocks where clearing sched_clock_stable has fixed problems with
>     migrated VMs hanging.
> 
>     So, always set the sched clock as unstable when using the Xen clock
>     source.
> 
>     Signed-off-by: David Vrabel <david.vrabel@citrix.com
>     <mailto:david.vrabel@citrix.com>>
>     ---
>      arch/x86/xen/time.c |    1 +
>      1 files changed, 1 insertions(+), 0 deletions(-)
> 
>     diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>     index 0296a95..8469b5a 100644
>     --- a/arch/x86/xen/time.c
>     +++ b/arch/x86/xen/time.c
>     @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>            do_settimeofday(&tp);
> 
>            setup_force_cpu_cap(X86_FEATURE_TSC);
>     +       sched_clock_stable = 0;
> 
>            xen_setup_runstate_info(cpu);
>            xen_setup_timer(cpu);
>     --
>     1.7.2.5
> 
> 
> I really prefer to hide nonstop tsc feature from Xen side, rather than
> let Linux kernel to have a condition that "Nonstop TSC feature existed,
> but sched_clock_stable=0".

I disagree.  The decision on whether the clock is stable or not should
be in the Xen clock source code.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ6-000683-6T; Fri, 13 Apr 2012 18:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-000632-CV
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:65413] by server-2.bemta-4.messagelabs.com id
	A2/7F-17550-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7280 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qa-Ji; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iS-HM;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:04 +0100
Message-ID: <1334342414-10289-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/20] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  708 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 415 insertions(+), 342 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..54f3813 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 03e71f6..477b72a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -494,7 +494,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..6cccb6c 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl->ao);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,215 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
+
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
 
-    return pid;
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl->ao);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
-        }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
-
-    libxl__ptr_add(gc, output);
-    return output;
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-out_err:
-    free(output);
-    return NULL;
-}
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    bl->diskpath = NULL;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    libxl__datacopier_init(&bl->keystrokes);
+    libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl->ao);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl->ao);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        bl->callback(egc, bl, 0);
+        rc = 0;
         goto out;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl->ao);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +330,187 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
 
-        goto out_close;
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
+
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (bl->child.pid >= 0) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status) {
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl->ao);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..dbc3cf0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -572,8 +572,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9af99ec..b3f84ba 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -449,6 +450,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1534,6 +1536,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ6-000683-6T; Fri, 13 Apr 2012 18:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-000632-CV
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:65413] by server-2.bemta-4.messagelabs.com id
	A2/7F-17550-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7280 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qa-Ji; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iS-HM;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:04 +0100
Message-ID: <1334342414-10289-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/20] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  708 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 415 insertions(+), 342 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..54f3813 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 03e71f6..477b72a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -494,7 +494,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..6cccb6c 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl->ao);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,215 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
+
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
 
-    return pid;
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl->ao);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
-        }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
-
-    libxl__ptr_add(gc, output);
-    return output;
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-out_err:
-    free(output);
-    return NULL;
-}
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    bl->diskpath = NULL;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    libxl__datacopier_init(&bl->keystrokes);
+    libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl->ao);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl->ao);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        bl->callback(egc, bl, 0);
+        rc = 0;
         goto out;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl->ao);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +330,187 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
 
-        goto out_close;
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
+
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (bl->child.pid >= 0) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status) {
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl->ao);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..dbc3cf0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -572,8 +572,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9af99ec..b3f84ba 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -449,6 +450,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1534,6 +1536,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ6-00068s-Oe; Fri, 13 Apr 2012 18:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062q-QB
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:65453] by server-3.bemta-4.messagelabs.com id
	59/D2-05853-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7320 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPy-0002Qx-3C; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPy-0002j2-0U;
	Fri, 13 Apr 2012 19:40:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:13 +0100
Message-ID: <1334342414-10289-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/20] libxl: remove malloc failure handling
	from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to use libxl__zalloc, where allocation failure is fatal.

Also remove a spurious semicolon from the helper macro.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    2 --
 tools/libxl/libxl_event.c    |    8 +-------
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 54f3813..b7f665a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -779,7 +779,6 @@ static void domain_death_occurred(libxl__egc *egc,
     *evg_upd = evg_next;
 
     libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
-    if (!ev) return;
 
     libxl__event_occurred(egc, ev);
 
@@ -866,7 +865,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                if (!ev) goto out;
                 
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index f355e3d..7600aa4 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -980,13 +980,7 @@ libxl_event *libxl__event_new(libxl__egc *egc,
 {
     libxl_event *ev;
 
-    ev = malloc(sizeof(*ev));
-    if (!ev) {
-        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
-        return NULL;
-    }
-
-    memset(ev, 0, sizeof(*ev));
+    ev = libxl__zalloc(0,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e97f5e..977db2a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -641,10 +641,10 @@ _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
                                       uint32_t domid);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
-   * If allocation fails, calls _disaster, and returns NULL. */
+   * Cannot fail. */
 
 #define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
     /* Convenience macro. */
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ6-00068s-Oe; Fri, 13 Apr 2012 18:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062q-QB
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:65453] by server-3.bemta-4.messagelabs.com id
	59/D2-05853-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7320 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPy-0002Qx-3C; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPy-0002j2-0U;
	Fri, 13 Apr 2012 19:40:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:13 +0100
Message-ID: <1334342414-10289-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/20] libxl: remove malloc failure handling
	from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to use libxl__zalloc, where allocation failure is fatal.

Also remove a spurious semicolon from the helper macro.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    2 --
 tools/libxl/libxl_event.c    |    8 +-------
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 54f3813..b7f665a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -779,7 +779,6 @@ static void domain_death_occurred(libxl__egc *egc,
     *evg_upd = evg_next;
 
     libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
-    if (!ev) return;
 
     libxl__event_occurred(egc, ev);
 
@@ -866,7 +865,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                if (!ev) goto out;
                 
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index f355e3d..7600aa4 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -980,13 +980,7 @@ libxl_event *libxl__event_new(libxl__egc *egc,
 {
     libxl_event *ev;
 
-    ev = malloc(sizeof(*ev));
-    if (!ev) {
-        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
-        return NULL;
-    }
-
-    memset(ev, 0, sizeof(*ev));
+    ev = libxl__zalloc(0,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e97f5e..977db2a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -641,10 +641,10 @@ _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
                                       uint32_t domid);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
-   * If allocation fails, calls _disaster, and returns NULL. */
+   * Cannot fail. */
 
 #define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
     /* Convenience macro. */
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ7-0006AW-TQ; Fri, 13 Apr 2012 18:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-000642-Si
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:26 +0000
Received: from [85.158.138.51:7855] by server-10.bemta-3.messagelabs.com id
	F7/98-29478-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20381 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QN-At; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002i4-7v;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:58 +0100
Message-ID: <1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/Tools.mk.in             |    2 +
 tools/configure                |   51 ++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac             |    2 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 +++
 tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
 6 files changed, 84 insertions(+), 1 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 912d021..eb879dd 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 86618f5..eeaf901 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,7 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -3947,6 +3948,8 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -7315,6 +7318,54 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        ax_cv_ptyfuncs_libs=-lutil
+
+    saved_LIBS="$LIBS"
+
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
 if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..b4f72e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -132,6 +133,7 @@ AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
+AX_CHECK_PTYFUNCS
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..5ba144f 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..2846a6d
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,24 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        ax_cv_ptyfuncs_libs=-lutil
+        AX_SAVEVAR_SAVE(LIBS)
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+])
+        AX_SAVEVAR_RESTORE(LIBS)],
+    [],[
+        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ7-0006AW-TQ; Fri, 13 Apr 2012 18:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-000642-Si
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:26 +0000
Received: from [85.158.138.51:7855] by server-10.bemta-3.messagelabs.com id
	F7/98-29478-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20381 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QN-At; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002i4-7v;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:58 +0100
Message-ID: <1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/Tools.mk.in             |    2 +
 tools/configure                |   51 ++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac             |    2 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 +++
 tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
 6 files changed, 84 insertions(+), 1 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 912d021..eb879dd 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure b/tools/configure
index 86618f5..eeaf901 100755
--- a/tools/configure
+++ b/tools/configure
@@ -602,6 +602,7 @@ POW_LIB
 LIBOBJS
 ALLOCA
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -3947,6 +3948,8 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -7315,6 +7318,54 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        ax_cv_ptyfuncs_libs=-lutil
+
+    saved_LIBS="$LIBS"
+
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
 if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..b4f72e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -132,6 +133,7 @@ AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
+AX_CHECK_PTYFUNCS
 AC_CHECK_LIB([rt], [clock_gettime])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..5ba144f 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..2846a6d
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,24 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        ax_cv_ptyfuncs_libs=-lutil
+        AX_SAVEVAR_SAVE(LIBS)
+        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+        AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+])
+        AX_SAVEVAR_RESTORE(LIBS)],
+    [],[
+        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ3-00065w-Q0; Fri, 13 Apr 2012 18:40:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062q-IT
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.143.99:65404] by server-3.bemta-4.messagelabs.com id
	07/D2-05853-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7275 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QZ-Hi; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iO-FD;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:03 +0100
Message-ID: <1334342414-10289-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/20] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 774fa03..023de6e 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -186,3 +186,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op->ao);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op->ao);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 20c95db..9af99ec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1498,6 +1498,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ3-00065w-Q0; Fri, 13 Apr 2012 18:40:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062q-IT
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.143.99:65404] by server-3.bemta-4.messagelabs.com id
	07/D2-05853-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7275 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QZ-Hi; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iO-FD;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:03 +0100
Message-ID: <1334342414-10289-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/20] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 774fa03..023de6e 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -186,3 +186,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op->ao);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op->ao);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 20c95db..9af99ec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1498,6 +1498,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ4-00066d-N7; Fri, 13 Apr 2012 18:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062q-1X
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:65421] by server-3.bemta-4.messagelabs.com id
	97/D2-05853-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qk-Qv; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002ii-Ox;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:08 +0100
Message-ID: <1334342414-10289-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/20] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove this obsolete hook.  Callers inside libxl which create and reap
children should use the mechanisms provided by the event system.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   12 +++---------
 tools/libxl/libxl_internal.h |    3 ---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..2ee2154 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -19,11 +19,6 @@
 
 #include "libxl_internal.h"
 
-static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
-{
-    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
-}
-
 static void check_open_fds(const char *what)
 {
     const char *env_debug;
@@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
 
     if (!for_spawn) _exit(0); /* just detach then */
 
-    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
+    got = waitpid(child, &status, 0);
     assert(got == child);
 
     rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
@@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
                          (unsigned long)for_spawn->intermediate);
             abort(); /* things are very wrong */
         }
-        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
+        got = waitpid(for_spawn->intermediate, &status, 0);
         assert(got == for_spawn->intermediate);
         if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
             report_spawn_intermediate_status(gc, for_spawn, status);
@@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
 
 int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     pid_t got;
     int status;
 
     if (!for_spawn) return 0;
 
     assert(for_spawn->intermediate);
-    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
+    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
     if (!got) return 0;
 
     assert(got == for_spawn->intermediate);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 74dc2c5..ae71f70 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -334,9 +334,6 @@ struct libxl__ctx {
     int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
     LIBXL_LIST_HEAD(, libxl__ev_child) children;
 
-    /* This is obsolete and must be removed: */
-    int (*waitpid_instead)(pid_t pid, int *status, int flags);
-
     libxl_version_info version_info;
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ4-00066d-N7; Fri, 13 Apr 2012 18:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062q-1X
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:65421] by server-3.bemta-4.messagelabs.com id
	97/D2-05853-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qk-Qv; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002ii-Ox;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:08 +0100
Message-ID: <1334342414-10289-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/20] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove this obsolete hook.  Callers inside libxl which create and reap
children should use the mechanisms provided by the event system.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   12 +++---------
 tools/libxl/libxl_internal.h |    3 ---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..2ee2154 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -19,11 +19,6 @@
 
 #include "libxl_internal.h"
 
-static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
-{
-    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
-}
-
 static void check_open_fds(const char *what)
 {
     const char *env_debug;
@@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
 
     if (!for_spawn) _exit(0); /* just detach then */
 
-    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
+    got = waitpid(child, &status, 0);
     assert(got == child);
 
     rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
@@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
                          (unsigned long)for_spawn->intermediate);
             abort(); /* things are very wrong */
         }
-        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
+        got = waitpid(for_spawn->intermediate, &status, 0);
         assert(got == for_spawn->intermediate);
         if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
             report_spawn_intermediate_status(gc, for_spawn, status);
@@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
 
 int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     pid_t got;
     int status;
 
     if (!for_spawn) return 0;
 
     assert(for_spawn->intermediate);
-    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
+    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
     if (!got) return 0;
 
     assert(got == for_spawn->intermediate);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 74dc2c5..ae71f70 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -334,9 +334,6 @@ struct libxl__ctx {
     int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
     LIBXL_LIST_HEAD(, libxl__ev_child) children;
 
-    /* This is obsolete and must be removed: */
-    int (*waitpid_instead)(pid_t pid, int *status, int flags);
-
     libxl_version_info version_info;
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ3-00065b-D9; Fri, 13 Apr 2012 18:40:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062Z-Df
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.138.51:7899] by server-3.bemta-3.messagelabs.com id
	3D/F9-04048-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20446 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QS-EL; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iC-Ck;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:00 +0100
Message-ID: <1334342414-10289-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/20] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3996824..6ceb362 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1128,6 +1128,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..83c22b3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1a4874c..19b4615 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ3-00065b-D9; Fri, 13 Apr 2012 18:40:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062Z-Df
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.138.51:7899] by server-3.bemta-3.messagelabs.com id
	3D/F9-04048-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20446 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QS-EL; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iC-Ck;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:00 +0100
Message-ID: <1334342414-10289-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/20] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3996824..6ceb362 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1128,6 +1128,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..83c22b3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1a4874c..19b4615 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ5-00067i-Pe; Fri, 13 Apr 2012 18:40:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00063Q-AT
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.138.51:31947] by server-7.bemta-3.messagelabs.com id
	62/D2-03078-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20708 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QU-Fc; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iJ-Dq;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:02 +0100
Message-ID: <1334342414-10289-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/20] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  188 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 230 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5ba144f..6e253b1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..774fa03
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        datacopier_callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc->ao);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6ceb362..20c95db 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -833,6 +833,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1458,6 +1459,45 @@ int libxl__carefd_close(libxl__carefd*);
 int libxl__carefd_fd(const libxl__carefd*);
 
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errnoval is valid
+ * onwrite==0 means failure happened when reading
+ *     errnoval==0 means we got eof and all data was written
+ *     errnoval!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ5-00067i-Pe; Fri, 13 Apr 2012 18:40:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00063Q-AT
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.138.51:31947] by server-7.bemta-3.messagelabs.com id
	62/D2-03078-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20708 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QU-Fc; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iJ-Dq;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:02 +0100
Message-ID: <1334342414-10289-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/20] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  188 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 230 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5ba144f..6e253b1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..774fa03
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        datacopier_callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc->ao);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6ceb362..20c95db 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -833,6 +833,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1458,6 +1459,45 @@ int libxl__carefd_close(libxl__carefd*);
 int libxl__carefd_fd(const libxl__carefd*);
 
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errnoval is valid
+ * onwrite==0 means failure happened when reading
+ *     errnoval==0 means we got eof and all data was written
+ *     errnoval!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ3-00065K-03; Fri, 13 Apr 2012 18:40:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-000632-GM
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.143.99:65391] by server-2.bemta-4.messagelabs.com id
	61/7F-17550-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7240 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qf-LU; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iW-Iy;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:05 +0100
Message-ID: <1334342414-10289-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/20] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 19b4615..f0d94c6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ3-00065K-03; Fri, 13 Apr 2012 18:40:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-000632-GM
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.143.99:65391] by server-2.bemta-4.messagelabs.com id
	61/7F-17550-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7240 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qf-LU; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iW-Iy;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:05 +0100
Message-ID: <1334342414-10289-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/20] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 19b4615..f0d94c6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ7-00069y-HK; Fri, 13 Apr 2012 18:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062c-Om
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:26 +0000
Received: from [85.158.138.51:31975] by server-6.bemta-3.messagelabs.com id
	C5/00-05145-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20774 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qn-T9; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002im-QQ;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:09 +0100
Message-ID: <1334342414-10289-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/20] libxl: change some structures to unit
	arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch these variables will turn into actual pointers.

To clarify that patch, prepare the ground by changing these variables
from "struct foo var" to "struct foo var[1]".  This enables accesses
to them and their members to be made as if they were pointers.

No functional change.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   18 +++++-----
 tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index dbc3cf0..8408c26 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -543,7 +543,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state;
+    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
@@ -585,12 +585,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(&state, 0, sizeof(state));
+    memset(state, 0, sizeof(*state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
     }
 
     if (ret) {
@@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
@@ -636,7 +636,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
-                                         &state, &dm_starting);
+                                         state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -665,11 +665,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (need_qemu)
              console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
         }
         break;
     }
@@ -683,7 +683,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 7bf653a..3921e2a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config;
+    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state;
+    libxl__domain_build_state stubdom_state[1];
     uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
@@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
-    libxl_domain_create_info_init(&dm_config.c_info);
-    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+    libxl_domain_create_info_init(&dm_config->c_info);
+    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
-    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
+    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
-    libxl_uuid_generate(&dm_config.c_info.uuid);
+    libxl_uuid_generate(&dm_config->c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info);
-    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
+    libxl_domain_build_info_init(&dm_config->b_info);
+    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
 
-    dm_config.b_info.max_vcpus = 1;
-    dm_config.b_info.max_memkb = 32 * 1024;
-    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+    dm_config->b_info.max_vcpus = 1;
+    dm_config->b_info.max_memkb = 32 * 1024;
+    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
-    dm_config.b_info.u.pv.ramdisk.path = "";
-    dm_config.b_info.u.pv.features = "";
+    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
+    dm_config->b_info.u.pv.ramdisk.path = "";
+    dm_config->b_info.u.pv.features = "";
 
-    dm_config.b_info.device_model_version =
+    dm_config->b_info.device_model_version =
         guest_config->b_info.device_model_version;
-    dm_config.b_info.device_model =
+    dm_config->b_info.device_model =
         guest_config->b_info.device_model;
-    dm_config.b_info.extra = guest_config->b_info.extra;
-    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
-    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+    dm_config->b_info.extra = guest_config->b_info.extra;
+    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
 
-    dm_config.disks = guest_config->disks;
-    dm_config.num_disks = guest_config->num_disks;
+    dm_config->disks = guest_config->disks;
+    dm_config->num_disks = guest_config->num_disks;
 
-    dm_config.vifs = guest_config->vifs;
-    dm_config.num_vifs = guest_config->num_vifs;
+    dm_config->vifs = guest_config->vifs;
+    dm_config->num_vifs = guest_config->num_vifs;
 
-    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
     if (ret) goto out;
-    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
     if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
-    dm_config.vfbs = &vfb;
-    dm_config.num_vfbs = 1;
-    dm_config.vkbs = &vkb;
-    dm_config.num_vkbs = 1;
+    dm_config->vfbs = &vfb;
+    dm_config->num_vfbs = 1;
+    dm_config->vkbs = &vkb;
+    dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
     dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
 
@@ -788,20 +788,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+    for (i = 0; i < dm_config->num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+    for (i = 0; i < dm_config->num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -845,14 +845,14 @@ retry_transaction:
                 break;
         }
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
-                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
     if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 &dm_config,
-                                 &stubdom_state,
+                                 dm_config,
+                                 stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ7-00069y-HK; Fri, 13 Apr 2012 18:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062c-Om
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:26 +0000
Received: from [85.158.138.51:31975] by server-6.bemta-3.messagelabs.com id
	C5/00-05145-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20774 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qn-T9; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002im-QQ;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:09 +0100
Message-ID: <1334342414-10289-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/20] libxl: change some structures to unit
	arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch these variables will turn into actual pointers.

To clarify that patch, prepare the ground by changing these variables
from "struct foo var" to "struct foo var[1]".  This enables accesses
to them and their members to be made as if they were pointers.

No functional change.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   18 +++++-----
 tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index dbc3cf0..8408c26 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -543,7 +543,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state;
+    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
@@ -585,12 +585,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(&state, 0, sizeof(state));
+    memset(state, 0, sizeof(*state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
     }
 
     if (ret) {
@@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
@@ -636,7 +636,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
-                                         &state, &dm_starting);
+                                         state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -665,11 +665,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (need_qemu)
              console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
         }
         break;
     }
@@ -683,7 +683,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 7bf653a..3921e2a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config;
+    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state;
+    libxl__domain_build_state stubdom_state[1];
     uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
@@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
-    libxl_domain_create_info_init(&dm_config.c_info);
-    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+    libxl_domain_create_info_init(&dm_config->c_info);
+    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
-    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
+    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
-    libxl_uuid_generate(&dm_config.c_info.uuid);
+    libxl_uuid_generate(&dm_config->c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info);
-    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
+    libxl_domain_build_info_init(&dm_config->b_info);
+    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
 
-    dm_config.b_info.max_vcpus = 1;
-    dm_config.b_info.max_memkb = 32 * 1024;
-    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+    dm_config->b_info.max_vcpus = 1;
+    dm_config->b_info.max_memkb = 32 * 1024;
+    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
-    dm_config.b_info.u.pv.ramdisk.path = "";
-    dm_config.b_info.u.pv.features = "";
+    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
+    dm_config->b_info.u.pv.ramdisk.path = "";
+    dm_config->b_info.u.pv.features = "";
 
-    dm_config.b_info.device_model_version =
+    dm_config->b_info.device_model_version =
         guest_config->b_info.device_model_version;
-    dm_config.b_info.device_model =
+    dm_config->b_info.device_model =
         guest_config->b_info.device_model;
-    dm_config.b_info.extra = guest_config->b_info.extra;
-    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
-    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+    dm_config->b_info.extra = guest_config->b_info.extra;
+    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
 
-    dm_config.disks = guest_config->disks;
-    dm_config.num_disks = guest_config->num_disks;
+    dm_config->disks = guest_config->disks;
+    dm_config->num_disks = guest_config->num_disks;
 
-    dm_config.vifs = guest_config->vifs;
-    dm_config.num_vifs = guest_config->num_vifs;
+    dm_config->vifs = guest_config->vifs;
+    dm_config->num_vifs = guest_config->num_vifs;
 
-    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
     if (ret) goto out;
-    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
     if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
-    dm_config.vfbs = &vfb;
-    dm_config.num_vfbs = 1;
-    dm_config.vkbs = &vkb;
-    dm_config.num_vkbs = 1;
+    dm_config->vfbs = &vfb;
+    dm_config->num_vfbs = 1;
+    dm_config->vkbs = &vkb;
+    dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
     dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
 
@@ -788,20 +788,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+    for (i = 0; i < dm_config->num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+    for (i = 0; i < dm_config->num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -845,14 +845,14 @@ retry_transaction:
                 break;
         }
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
-                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
     if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 &dm_config,
-                                 &stubdom_state,
+                                 dm_config,
+                                 stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ2-00064z-L9; Fri, 13 Apr 2012 18:40:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062g-4g
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.138.51:31879] by server-9.bemta-3.messagelabs.com id
	DE/1F-26691-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20372 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QK-8b; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002i0-6A;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:57 +0100
Message-ID: <1334342414-10289-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/20] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   62 ++++++++++-
 6 files changed, 515 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..42ac89f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..03e71f6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 672e3fe..1b7495a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index dce88ad..35c8bdd 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ce4bb5..abc38fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -315,10 +328,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -566,6 +583,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon.  The child may not
+ * make any further calls to libxl infrastructure, except for memory
+ * allocation and logging.  If the child needs to use xenstore it
+ * must open its own xs handle and use it directly, rather than via
+ * the libxl event machinery.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -619,6 +666,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ2-00064z-L9; Fri, 13 Apr 2012 18:40:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062g-4g
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.138.51:31879] by server-9.bemta-3.messagelabs.com id
	DE/1F-26691-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20372 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QK-8b; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002i0-6A;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:57 +0100
Message-ID: <1334342414-10289-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/20] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   62 ++++++++++-
 6 files changed, 515 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..42ac89f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..03e71f6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 672e3fe..1b7495a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index dce88ad..35c8bdd 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ce4bb5..abc38fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -315,10 +328,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -566,6 +583,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon.  The child may not
+ * make any further calls to libxl infrastructure, except for memory
+ * allocation and logging.  If the child needs to use xenstore it
+ * must open its own xs handle and use it directly, rather than via
+ * the libxl event machinery.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -619,6 +666,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ0-00063A-AN; Fri, 13 Apr 2012 18:40:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlPz-00062c-4R
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:23 +0000
Received: from [85.158.138.51:7803] by server-6.bemta-3.messagelabs.com id
	CA/FF-05145-613788F4; Fri, 13 Apr 2012 18:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20347 invoked from network); 13 Apr 2012 18:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QI-5q; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002hu-4S;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:55 +0100
Message-ID: <1334342414-10289-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/20] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..af631fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ0-00063A-AN; Fri, 13 Apr 2012 18:40:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlPz-00062c-4R
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:23 +0000
Received: from [85.158.138.51:7803] by server-6.bemta-3.messagelabs.com id
	CA/FF-05145-613788F4; Fri, 13 Apr 2012 18:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20347 invoked from network); 13 Apr 2012 18:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QI-5q; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002hu-4S;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:55 +0100
Message-ID: <1334342414-10289-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/20] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..af631fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ5-00066y-32; Fri, 13 Apr 2012 18:40:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062q-Dq
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:44001] by server-3.bemta-4.messagelabs.com id
	D8/D2-05853-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7305 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qi-PN; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002ie-MX;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:07 +0100
Message-ID: <1334342414-10289-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/20] libxl: Allow AO_GC and EGC_GC even if not
	used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mark the gc produced by AO_GC and EGC_GC with the gcc feature
__attribute__((unused)).  This allows the use of EGC_INIT and
STATE_AO_GC by functions which do actually use the gc.

This is convenient because those functions might want to use the ao or
egc, rather than the gc; and also because it means that functions
which morally ought to be fishing any gc they use out of an egc or
state structure can be written do so regardless of whether the gc is
actually used right then.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4cfb8d5..74dc2c5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1280,7 +1280,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 /* useful for all functions which take an egc: */
 
 #define EGC_GC                                  \
-    libxl__gc *const gc = &egc->gc
+    libxl__gc *const gc __attribute__((unused)) = &egc->gc
 
 /* egc initialisation and destruction: */
 
@@ -1383,7 +1383,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     })
 
 #define AO_GC                                   \
-    libxl__gc *const gc = &ao->gc
+    libxl__gc *const gc __attribute__((unused)) = &ao->gc
 
 #define STATE_AO_GC(op_ao)                      \
     libxl__ao *const ao = (op_ao);              \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ5-00066y-32; Fri, 13 Apr 2012 18:40:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00062q-Dq
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:44001] by server-3.bemta-4.messagelabs.com id
	D8/D2-05853-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7305 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qi-PN; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002ie-MX;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:07 +0100
Message-ID: <1334342414-10289-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/20] libxl: Allow AO_GC and EGC_GC even if not
	used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mark the gc produced by AO_GC and EGC_GC with the gcc feature
__attribute__((unused)).  This allows the use of EGC_INIT and
STATE_AO_GC by functions which do actually use the gc.

This is convenient because those functions might want to use the ao or
egc, rather than the gc; and also because it means that functions
which morally ought to be fishing any gc they use out of an egc or
state structure can be written do so regardless of whether the gc is
actually used right then.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4cfb8d5..74dc2c5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1280,7 +1280,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 /* useful for all functions which take an egc: */
 
 #define EGC_GC                                  \
-    libxl__gc *const gc = &egc->gc
+    libxl__gc *const gc __attribute__((unused)) = &egc->gc
 
 /* egc initialisation and destruction: */
 
@@ -1383,7 +1383,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     })
 
 #define AO_GC                                   \
-    libxl__gc *const gc = &ao->gc
+    libxl__gc *const gc __attribute__((unused)) = &ao->gc
 
 #define STATE_AO_GC(op_ao)                      \
     libxl__ao *const ao = (op_ao);              \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ4-00066K-6k; Fri, 13 Apr 2012 18:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-000632-0I
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:43957] by server-2.bemta-4.messagelabs.com id
	71/7F-17550-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7257 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932733"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QT-EQ; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iG-DM;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:01 +0100
Message-ID: <1334342414-10289-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/20] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..3675afe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ4-00066K-6k; Fri, 13 Apr 2012 18:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-000632-0I
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.143.99:43957] by server-2.bemta-4.messagelabs.com id
	71/7F-17550-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7257 invoked from network); 13 Apr 2012 18:40:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932733"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QT-EQ; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iG-DM;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:01 +0100
Message-ID: <1334342414-10289-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/20] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..3675afe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ1-00064I-SX; Fri, 13 Apr 2012 18:40:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlPz-00062g-Fz
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:23 +0000
Received: from [85.158.138.51:7826] by server-9.bemta-3.messagelabs.com id
	EC/1F-26691-613788F4; Fri, 13 Apr 2012 18:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QJ-6a; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002hw-5I;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:56 +0100
Message-ID: <1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..672e3fe 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each elemebnt in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index af631fb..2ce4bb5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -257,8 +261,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ1-00064I-SX; Fri, 13 Apr 2012 18:40:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlPz-00062g-Fz
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:23 +0000
Received: from [85.158.138.51:7826] by server-9.bemta-3.messagelabs.com id
	EC/1F-26691-613788F4; Fri, 13 Apr 2012 18:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QJ-6a; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002hw-5I;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:56 +0100
Message-ID: <1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..672e3fe 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each elemebnt in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index af631fb..2ce4bb5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -257,8 +261,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ8-0006BP-Ol; Fri, 13 Apr 2012 18:40:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ3-00064D-1Q
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:27 +0000
Received: from [85.158.139.83:54043] by server-9.bemta-5.messagelabs.com id
	A9/3E-09826-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334342424!23649508!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1977 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qr-V7; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iu-UB;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:11 +0100
Message-ID: <1334342414-10289-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/20] libxl: make libxl_create run bootloader
	via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change initiate_domain_create to properly use libxl__bootloader_run
rather than improperly calling libxl_run_bootloader with NULL ao_how.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_create.c   |   53 +++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 09a03a7..156c5c7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,6 +550,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int rc);
 
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
@@ -570,6 +573,7 @@ static void initiate_domain_create(libxl__egc *egc,
     int restore_fd = dcs->restore_fd;
     libxl_console_ready cb = dcs->console_cb;
     void *priv = dcs->console_cb_priv;
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
 
@@ -602,18 +606,40 @@ static void initiate_domain_create(libxl__egc *egc,
     libxl_device_disk *bootdisk =
         d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
 
-    if (restore_fd < 0 && bootdisk) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
-                                   0 /* fixme-ao */);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to run bootloader: %d", ret);
-            goto error_out;
-        }
+    if (restore_fd < 0 && dcs->bl.disk) {
+        dcs->bl.ao = ao;
+        dcs->bl.disk = bootdisk;
+        dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.info = &d_config->b_info,
+            
+        libxl__bootloader_run(egc, &dcs->bl);
+    } else {
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     }
+    return;
 
-    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    int i;
+
+    /* convenience aliases */
+    uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *state = &dcs->build_state;
+    libxl_ctx *ctx = CTX;
+
+    if (ret) goto error_out;
+
     dcs->dmss.spawn.ao = ao;
     dcs->dmss.guest_config = dcs->guest_config;
     dcs->dmss.build_state = &dcs->build_state;
@@ -764,12 +790,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
+        ret = libxl__e820_alloc(gc, domid, d_config);
+        if (ret) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
+                      ret, errno);
+            goto error_out;
+        }
     }
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5bab4d6..56c3eec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1669,6 +1669,7 @@ struct libxl__domain_create_state {
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
+    libxl__bootloader_state bl;
     union {
         libxl__dm_spawn_state dmss;
         libxl__stubdom_spawn_state sdss;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ8-0006BP-Ol; Fri, 13 Apr 2012 18:40:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ3-00064D-1Q
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:27 +0000
Received: from [85.158.139.83:54043] by server-9.bemta-5.messagelabs.com id
	A9/3E-09826-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334342424!23649508!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1977 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qr-V7; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iu-UB;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:11 +0100
Message-ID: <1334342414-10289-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/20] libxl: make libxl_create run bootloader
	via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change initiate_domain_create to properly use libxl__bootloader_run
rather than improperly calling libxl_run_bootloader with NULL ao_how.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_create.c   |   53 +++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 09a03a7..156c5c7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,6 +550,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int rc);
 
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
@@ -570,6 +573,7 @@ static void initiate_domain_create(libxl__egc *egc,
     int restore_fd = dcs->restore_fd;
     libxl_console_ready cb = dcs->console_cb;
     void *priv = dcs->console_cb_priv;
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
 
@@ -602,18 +606,40 @@ static void initiate_domain_create(libxl__egc *egc,
     libxl_device_disk *bootdisk =
         d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
 
-    if (restore_fd < 0 && bootdisk) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
-                                   0 /* fixme-ao */);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to run bootloader: %d", ret);
-            goto error_out;
-        }
+    if (restore_fd < 0 && dcs->bl.disk) {
+        dcs->bl.ao = ao;
+        dcs->bl.disk = bootdisk;
+        dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.info = &d_config->b_info,
+            
+        libxl__bootloader_run(egc, &dcs->bl);
+    } else {
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     }
+    return;
 
-    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    int i;
+
+    /* convenience aliases */
+    uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *state = &dcs->build_state;
+    libxl_ctx *ctx = CTX;
+
+    if (ret) goto error_out;
+
     dcs->dmss.spawn.ao = ao;
     dcs->dmss.guest_config = dcs->guest_config;
     dcs->dmss.build_state = &dcs->build_state;
@@ -764,12 +790,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
+        ret = libxl__e820_alloc(gc, domid, d_config);
+        if (ret) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
+                      ret, errno);
+            goto error_out;
+        }
     }
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5bab4d6..56c3eec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1669,6 +1669,7 @@ struct libxl__domain_create_state {
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
+    libxl__bootloader_state bl;
     union {
         libxl__dm_spawn_state dmss;
         libxl__stubdom_spawn_state sdss;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ9-0006CI-BD; Fri, 13 Apr 2012 18:40:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ3-000651-4G
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:27 +0000
Received: from [85.158.139.83:54051] by server-4.bemta-5.messagelabs.com id
	28/9D-10788-A13788F4; Fri, 13 Apr 2012 18:40:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334342424!23649508!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2002 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPy-0002Qz-59; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPy-0002j6-2p;
	Fri, 13 Apr 2012 19:40:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:14 +0100
Message-ID: <1334342414-10289-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/20] libxl: convert console callback to
	libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the old console callback.  (Its reentrancy properties were
troublesome: in principle, the event loop might be reentered during
the callback, and the libxl__domain_create_state swept out from under
the feet of the domain creation.)

As a side effect of the new code arrangements, the console callback
for non-bootloader-using PV guests now occurs near the end of domain
creation, in the same place as for HVM guests, rather than near the
start.

The new arrangements should in principle mean that by the time the
console is described as ready by the callback, the xenstore key is
indeed ready.  So in the future the timeout might be removed from
the console client.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.h            |   17 ++++++-----
 tools/libxl/libxl_bootloader.c |    3 ++
 tools/libxl/libxl_create.c     |   59 +++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h   |    6 +++-
 tools/libxl/libxl_types.idl    |    2 +
 tools/libxl/xl_cmdimpl.c       |   25 ++++++++++-------
 6 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bfe684..de8d1872 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
-typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
-   * properties need to be documented but they may turn out to be too
-   * awkward */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            const libxl_asyncop_how *ao_how);
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how);
+                                const libxl_asyncop_how *ao_how,
+                                const libxl_asyncprogress_how *aop_console_how);
+  /* A progress report will be made via ao_console_how, of type
+   * domain_create_console_available, when the domain's primary
+   * console is available and can be connected to.
+   */
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index eaec46a..3f6f129 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -375,6 +375,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    if (bl->console_available)
+        bl->console_available(egc, bl);
+
     int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
     int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 156c5c7..a457e09 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,10 +550,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl);
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -571,8 +576,6 @@ static void initiate_domain_create(libxl__egc *egc,
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
     int restore_fd = dcs->restore_fd;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
@@ -590,11 +593,6 @@ static void initiate_domain_create(libxl__egc *egc,
     dcs->guest_domid = domid;
     dcs->dmss.guest_domid = 0; /* means we haven't spawned */
 
-    if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
-
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
@@ -610,6 +608,7 @@ static void initiate_domain_create(libxl__egc *egc,
         dcs->bl.ao = ao;
         dcs->bl.disk = bootdisk;
         dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.console_available = domcreate_bootloader_console_available;
         dcs->bl.info = &d_config->b_info,
             
         libxl__bootloader_run(egc, &dcs->bl);
@@ -623,6 +622,21 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    domcreate_console_available(egc, dcs);
+}
+
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs) {
+    libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
+                              NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
+                                        dcs->guest_domid));
+}
+
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int ret)
@@ -759,8 +773,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
 
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -798,12 +810,7 @@ static void domcreate_devmodel_started(libxl__egc *egc,
             goto error_out;
         }
     }
-    if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
-                (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-                 d_config->b_info.u.pv.bootloader ))) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
+    domcreate_console_available(egc, dcs);
 
     domcreate_complete(egc, dcs, 0);
     return;
@@ -842,8 +849,9 @@ static void domain_create_cb(libxl__egc *egc,
                              int rc, uint32_t domid);
 
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            int restore_fd, const libxl_asyncop_how *ao_how)
+                            uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
     AO_CREATE(ctx, 0, ao_how);
     libxl__app_domain_create_state *cdcs;
@@ -852,9 +860,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
     cdcs->dcs.restore_fd = restore_fd;
-    cdcs->dcs.console_cb = cb;
-    cdcs->dcs.console_cb_priv = priv;
     cdcs->dcs.callback = domain_create_cb;
+    libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
     cdcs->domid_out = domid;
 
     initiate_domain_create(egc, &cdcs->dcs);
@@ -876,19 +883,21 @@ static void domain_create_cb(libxl__egc *egc,
 }
     
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
                             uint32_t *domid,
-                            const libxl_asyncop_how *ao_how)
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
+    return do_domain_create(ctx, d_config, domid, -1,
+                            ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how)
+                                const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
+    return do_domain_create(ctx, d_config, domid, restore_fd,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 977db2a..b2eefd6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1651,11 +1651,14 @@ int libxl__openptys(libxl__openpty_state *op,
 typedef struct libxl__bootloader_state libxl__bootloader_state;
 typedef void libxl__run_bootloader_callback(libxl__egc*,
                                 libxl__bootloader_state*, int rc);
+typedef void libxl__bootloader_console_callback(libxl__egc*,
+                                libxl__bootloader_state*);
 
 struct libxl__bootloader_state {
     /* caller must fill these in, and they must all remain valid */
     libxl__ao *ao;
     libxl__run_bootloader_callback *callback;
+    libxl__bootloader_console_callback *console_available;
     libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
     libxl_device_disk *disk;
     uint32_t domid;
@@ -1691,8 +1694,7 @@ struct libxl__domain_create_state {
     libxl__ao *ao;
     libxl_domain_config *guest_config;
     int restore_fd;
-    libxl_console_ready console_cb;
-    void *console_cb_priv;
+    libxl_asyncprogress_how aop_console_how;
     libxl__domain_create_cb *callback;
     /* private to domain_create */
     int guest_domid;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..f28d785 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -444,6 +444,7 @@ libxl_event_type = Enumeration("event_type", [
     (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
+    (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -469,4 +470,5 @@ libxl_event = Struct("event",[
            ("operation_complete", Struct(None, [
                                         ("rc", integer),
                                  ])),
+           ("domain_create_console_available", Struct(None, [])),
            ]))])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9e66536..ce52599 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1430,16 +1430,18 @@ static int freemem(libxl_domain_build_info *b_info)
     return ERROR_NOMEM;
 }
 
-static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
+static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv)
 {
     pid_t *pid = priv;
 
+    libxl_event_free(ctx, ev);
+
     *pid = fork();
     if (*pid < 0) {
         perror("unable to fork xenconsole");
-        return ERROR_FAIL;
+        return;
     } else if (*pid > 0)
-        return 0;
+        return;
 
     postfork();
 
@@ -1506,7 +1508,7 @@ static int create_domain(struct domain_create *dom_info)
     int config_len = 0;
     int restore_fd = -1;
     int status = 0;
-    libxl_console_ready cb;
+    const libxl_asyncprogress_how *autoconnect_console_how;
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
@@ -1660,24 +1662,27 @@ start:
         goto error_out;
     }
 
+    libxl_asyncprogress_how autoconnect_console_how_buf;
     if ( dom_info->console_autoconnect ) {
-        cb = autoconnect_console;
+        autoconnect_console_how_buf.callback = autoconnect_console;
+        autoconnect_console_how_buf.for_callback = &child_console_pid;
+        autoconnect_console_how = &autoconnect_console_how_buf;
     }else{
-        cb = NULL;
+        autoconnect_console_how = 0;
     }
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                          cb, &child_console_pid,
-                                          &domid, restore_fd, 0);
+                                          &domid, restore_fd,
+                                          0, autoconnect_console_how);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
          */
         restore_file = NULL;
     }else{
-        ret = libxl_domain_create_new(ctx, &d_config,
-                                      cb, &child_console_pid, &domid, 0);
+        ret = libxl_domain_create_new(ctx, &d_config, &domid,
+                                      0, autoconnect_console_how);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ9-0006Cp-P3; Fri, 13 Apr 2012 18:40:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ3-00062q-6p
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:27 +0000
Received: from [85.158.143.35:33607] by server-3.bemta-4.messagelabs.com id
	1C/D2-05853-A13788F4; Fri, 13 Apr 2012 18:40:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334342425!13171902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23871 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qq-Ug; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iq-Sm;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:10 +0100
Message-ID: <1334342414-10289-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/20] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn becomes a callback-style asynchronous function.
The implementation is now in terms of libxl__ev_* including
libxl_ev_child.

All the callers need to be updated.  This includes the device model
spawning functions libxl__create_device_model and
libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
abolished; instead the dm spawner calls back.

(The choice of which kind of device model to create is lifted out of
what used to be libxl__create_device_model, because that function was
indirectly recursive.  Recursive callback-style operations are clumsy
because they require a pointer indirection for the nested states.)

Waiting for proper device model startup it is no longer notionally
optional.  Previously the code appeared to tolerate this by passing
NULL for various libxl__spawner_starting* parameters to device model
spawners.  However, this was not used anywhere.

Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
no longer supported.  It remains as an unused formal parameter to
avoid updating, in this patch, all the call sites which pass NULL.
libxl__wait_for_offspring is in any case itself an obsolete function,
so this wrinkle will go away when its callers are updated to use the
event system.  Consequently libxl__spawn_check is also abolished.

The "console ready" callback also remains unchanged in this patch.
The API for this needs to be reviewed in the context of the event
series and its reentrancy restrictions documented.

Thus their callers need to be updated.  These are the domain creation
functions libxl_domain_create_new and _restore.  These functions now
take ao_hows, and have a private state structure.

However domain creation remains not completely converted to the event
mechanism; in particular it runs the outward-facing function
libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
happens in the current code this is not a bug because none of the rest
of the functionality surrounding the bootloader call will mind if the
event loop is reentered in the middle of its execution.

The file-scope function libxl__set_fd_flag which was used by the
previous spawn arrangements becomes unused and is removed; other
places in libxl can use libxl_fd_set_nonblock and
libxl_fd_set_cloexec, which of course remain.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   14 ++-
 tools/libxl/libxl_create.c   |  198 +++++++++++++++++++-----
 tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
 tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
 tools/libxl/xl_cmdimpl.c     |    6 +-
 6 files changed, 677 insertions(+), 400 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 477b72a..6f59364 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
+   * properties need to be documented but they may turn out to be too
+   * awkward */
+
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            const libxl_asyncop_how *ao_how);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how);
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8408c26..09a03a7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -537,16 +537,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
-static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+/*----- main domain creation -----*/
+
+/* We have a linear control flow; only one event callback is
+ * outstanding at any time.  Each initiation and callback function
+ * arranges for the next to be called, as the very last thing it
+ * does.  (If that particular sub-operation is not needed, a
+ * function will call the next event callback directly.)
+ */
+
+/* Event callbacks, in this order: */
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+/* Our own function to clean up and call the user's callback.
+ * The final call in the sequence. */
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc);
+
+static void initiate_domain_create(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs)
 {
+    STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
     domid = 0;
 
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
@@ -559,9 +583,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
+    dcs->guest_domid = domid;
+    dcs->dmss.guest_domid = 0; /* means we haven't spawned */
+
     if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
@@ -585,7 +612,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(state, 0, sizeof(*state));
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+    libxl__domain_build_state *state = &dcs->build_state;
+    dcs->dmss.spawn.ao = ao;
+    dcs->dmss.guest_config = dcs->guest_config;
+    dcs->dmss.build_state = &dcs->build_state;
+    dcs->dmss.callback = domcreate_devmodel_started;
 
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
@@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        ret = libxl__create_device_model(gc, domid, d_config,
-                                         state, &dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to create device model: %d", ret);
-            goto error_out;
-        }
+        dcs->dmss.guest_domid = domid;
+        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
+            libxl__spawn_stubdom(egc, &dcs->sdss);
+        else
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+        return;
+
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
@@ -669,7 +701,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
+            dcs->dmss.guest_domid = domid;
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+            return;
         }
         break;
     }
@@ -678,17 +712,41 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
-    if (dm_starting) {
+    assert(!dcs->dmss.guest_domid);
+    domcreate_devmodel_started(egc, &dcs->dmss, 0);
+    return;
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss);
+    STATE_AO_GC(dmss->spawn.ao);
+    int i;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
+    if (ret) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "device model did not start: %d", ret);
+        goto error_out;
+    }
+
+    if (dcs->dmss.guest_domid) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "device model did not start: %d", ret);
-            goto error_out;
-        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
@@ -716,38 +774,94 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
-    *domid_out = domid;
-    return 0;
+    domcreate_complete(egc, dcs, 0);
+    return;
 
 error_out:
-    if (domid)
-        libxl_domain_destroy(ctx, domid);
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
 
-    return ret;
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc) {
+    STATE_AO_GC(dcs->ao);
+
+    if (rc) {
+        if (dcs->guest_domid) {
+            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
+            if (rc2)
+                LOG(ERROR, "unable to destroy domain %d following"
+                    " failed creation", dcs->guest_domid);
+        }
+        dcs->guest_domid = -1;
+    }
+    dcs->callback(egc, dcs, rc, dcs->guest_domid);
+}
+
+/*----- application-facing domain creation interface -----*/
+
+typedef struct {
+    libxl__domain_create_state dcs;
+    uint32_t *domid_out;
+} libxl__app_domain_create_state;
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid);
+
+static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, 0, ao_how);
+    libxl__app_domain_create_state *cdcs;
+
+    GCNEW(cdcs);
+    cdcs->dcs.ao = ao;
+    cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.console_cb = cb;
+    cdcs->dcs.console_cb_priv = priv;
+    cdcs->dcs.callback = domain_create_cb;
+    cdcs->domid_out = domid;
+
+    initiate_domain_create(egc, &cdcs->dcs);
+
+    return AO_INPROGRESS;
 }
 
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid)
+{
+    libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs);
+    STATE_AO_GC(cdcs->dcs.ao);
+
+    if (!rc)
+        *cdcs->domid_out = domid;
+
+    libxl__ao_complete(egc, ao, rc);
+}
+    
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv,
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3921e2a..15472a8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -667,24 +667,28 @@ retry_transaction:
     return 0;
 }
 
-static int libxl__create_stubdom(libxl__gc *gc,
-                                 int guest_domid,
-                                 libxl_domain_config *guest_config,
-                                 libxl__domain_build_state *d_state,
-                                 libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc);
+
+void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state *sdss)
 {
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state[1];
-    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
-    libxl__spawner_starting *dm_starting = 0;
+
+    /* convenience aliases */
+    libxl_domain_config *dm_config = &sdss->stubdom_config;
+    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
+    int guest_domid = sdss->stubdom.guest_domid;
+    libxl__domain_build_state *d_state = sdss->stubdom.build_state;
+    libxl__domain_build_state *stubdom_state = &sdss->stubdom_state;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -692,6 +696,8 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
+    sdss->pvqemu.guest_domid = 0;
+
     libxl_domain_create_info_init(&dm_config->c_info);
     dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
@@ -739,10 +745,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
     if (ret)
         goto out;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
     ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
@@ -850,42 +856,67 @@ retry_transaction:
             goto out_free;
     }
 
-    if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 dm_config,
-                                 stubdom_state,
-                                 &dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-
-    libxl_domain_unpause(ctx, dm_domid);
+    sdss->pvqemu.guest_domid = dm_domid;
+    sdss->pvqemu.guest_config = &sdss->stubdom_config;
+    sdss->pvqemu.build_state = &sdss->stubdom_state;
+    sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
-    if (starting_r) {
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = guest_domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
-        (*starting_r)->for_spawn = NULL;
-    }
+    libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    ret = 0;
+    free(args);
+    return;
 
 out_free:
     free(args);
 out:
-    return ret;
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
 }
 
-int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__stubdom_spawn_state *sdss =
+        CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) goto out;
+
+    rc = libxl_domain_unpause(CTX, dm_domid);
+    if (rc) goto out;
+
+ out:
+    if (rc) {
+        if (dm_domid)
+            libxl_domain_destroy(CTX, dm_domid);
+    }
+    sdss->callback(egc, &sdss->stubdom, rc);
+}
+
+/* callbacks passed to libxl__spawn_spawn */
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata);
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn);
+
+/* our "next step" function, called from those callbacks and elsewhere */
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
+{
+    /* convenience aliases */
+    int domid = dmss->guest_domid;
+    libxl__domain_build_state *state = dmss->build_state;
+    libxl__spawn_state *spawn = &dmss->spawn;
+
+    STATE_AO_GC(dmss->spawn.ao);
+
+    libxl_ctx *ctx = CTX;
+    libxl_domain_config *guest_config = dmss->guest_config;
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
@@ -893,15 +924,13 @@ int libxl__create_device_model(libxl__gc *gc,
     int logfile_w, null;
     int rc;
     char **args, **arg;
-    libxl__spawner_starting buf_starting, *p;
     xs_transaction_t t;
     char *vm_path;
     char **pass_stuff;
     const char *dm;
 
     if (libxl_defbool_val(b_info->device_model_stubdomain)) {
-        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
-        goto out;
+        abort();
     }
 
     dm = libxl__domain_device_model(gc, b_info);
@@ -945,25 +974,8 @@ int libxl__create_device_model(libxl__gc *gc,
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
-    if (starting_r) {
-        rc = ERROR_NOMEM;
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        if (!*starting_r)
-            goto out_close;
-        p = *starting_r;
-        p->for_spawn = calloc(1, sizeof(libxl__spawn_starting));
-    } else {
-        p = &buf_starting;
-        p->for_spawn = NULL;
-    }
-
-    p->domid = domid;
-    p->dom_path = libxl__xs_get_dompath(gc, domid);
-    p->pid_path = "image/device-model-pid";
-    if (!p->dom_path) {
-        rc = ERROR_FAIL;
-        goto out_close;
-    }
+    const char *dom_path = libxl__xs_get_dompath(gc, domid);
+    spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid");
 
     if (vnc && vnc->passwd) {
         /* This xenstore key will only be used by qemu-xen-traditionnal.
@@ -971,7 +983,7 @@ int libxl__create_device_model(libxl__gc *gc,
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
-        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path));
+        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path));
         if (vm_path) {
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
@@ -988,8 +1000,15 @@ retry_transaction:
     for (arg = args; *arg; arg++)
         LIBXL__LOG(CTX, XTL_DEBUG, "  %s", *arg);
 
-    rc = libxl__spawn_spawn(gc, p->for_spawn, "device model",
-                            libxl_spawner_record_pid, p);
+    spawn->what = GCSPRINTF("domain %d device model", domid);
+    spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid);
+    spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+    spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
+    spawn->midproc_cb = libxl__spawn_record_pid;
+    spawn->confirm_cb = device_model_confirm;
+    spawn->failure_cb = device_model_startup_failed;
+
+    rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
     if (!rc) { /* inner child */
@@ -1004,30 +1023,61 @@ out_close:
     close(logfile_w);
     free(args);
 out:
-    return rc;
+    if (rc)
+        device_model_spawn_outcome(egc, dmss, rc);
+}
+
+
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    STATE_AO_GC(spawn->ao);
+
+    if (!xsdata)
+        return;
+
+    if (strcmp(xsdata, "running"))
+        return;
+
+    libxl__spawn_detach(gc, spawn);
+
+    device_model_spawn_outcome(egc, dmss, 0);
 }
 
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
+}
 
-int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl__domain_build_state *state,
-                                libxl__spawner_starting *starting)
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc)
 {
-    char *path;
-    int domid = starting->domid;
-    int ret, ret2;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    ret = libxl__spawn_confirm_offspring_startup(gc,
-                                     LIBXL_DEVICE_MODEL_START_TIMEOUT,
-                                     "Device Model", path, "running", starting);
+    STATE_AO_GC(dmss->spawn.ao);
+    int ret2;
+
+    if (rc)
+        LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc);
+
+    libxl__domain_build_state *state = dmss->build_state;
+
     if (state->saved_state) {
         ret2 = unlink(state->saved_state);
-        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
-                                   "failed to remove device-model state %s\n",
-                                   state->saved_state);
-        /* Do not clobber spawn_confirm error code with unlink error code. */
-        if (!ret) ret = ret2;
+        if (ret2) {
+            LOGE(ERROR, "%s: failed to remove device-model state %s",
+                 dmss->spawn.what, state->saved_state);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
-    return ret;
+
+    rc = 0;
+
+ out:
+    dmss->callback(egc, dmss, rc);
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
@@ -1123,15 +1173,6 @@ out:
     return ret;
 }
 
-int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                             libxl_domain_config *guest_config,
-                             libxl__domain_build_state *state,
-                             libxl__spawner_starting **starting_r)
-{
-    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 2ee2154..d44b702 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
+                            pid_t innerchild)
 {
-    libxl__spawner_starting *starting = for_spawn;
-    struct xs_handle *xsh;
-    char *path = NULL, *pid = NULL;
-    int len;
-
-    if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0)
-        goto out;
+    struct xs_handle *xsh = NULL;
+    const char *pid = NULL;
+    int rc, xsok;
 
-    len = asprintf(&pid, "%d", innerchild);
-    if (len < 0)
-        goto out;
+    pid = GCSPRINTF("%d", innerchild);
 
     /* we mustn't use the parent's handle in the child */
     xsh = xs_daemon_open();
+    if (!xsh) {
+        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
+             spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
 
-    xs_write(xsh, XBT_NULL, path, pid, len);
+    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
+    if (!xsok) {
+        LOGE(ERROR,
+             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    rc = 0;
 
-    xs_daemon_close(xsh);
 out:
-    free(path);
-    free(pid);
+    if (xsh) xs_daemon_close(xsh);
+    return rc ? SIGTERM : 0;
 }
 
 int libxl__wait_for_offspring(libxl__gc *gc,
@@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc,
     tv.tv_sec = timeout;
     tv.tv_usec = 0;
     nfds = xs_fileno(xsh) + 1;
-    if (spawning && spawning->fd > xs_fileno(xsh))
-        nfds = spawning->fd + 1;
+    assert(!spawning);
 
     while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        if ( spawning ) {
-            rc = libxl__spawn_check(gc, spawning);
-            if ( rc ) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "%s died during startup", what);
-                rc = -1;
-                goto err_died;
-            }
-        }
         p = xs_read(xsh, XBT_NULL, path, &len);
         if ( NULL == p )
             goto again;
@@ -218,8 +214,6 @@ again:
         free(p);
         FD_ZERO(&rfds);
         FD_SET(xs_fileno(xsh), &rfds);
-        if (spawning)
-            FD_SET(spawning->fd, &rfds);
         rc = select(nfds, &rfds, NULL, NULL, &tv);
         if (rc > 0) {
             if (FD_ISSET(xs_fileno(xsh), &rfds)) {
@@ -229,207 +223,215 @@ again:
                 else
                     goto again;
             }
-            if (spawning && FD_ISSET(spawning->fd, &rfds)) {
-                unsigned char dummy;
-                if (read(spawning->fd, &dummy, sizeof(dummy)) != 1)
-                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG,
-                                     "failed to read spawn status pipe");
-            }
         }
     }
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what);
-err_died:
+
     xs_unwatch(xsh, path, path);
     xs_daemon_close(xsh);
 err:
     return -1;
 }
 
-static int detach_offspring(libxl__gc *gc,
-                               libxl__spawner_starting *starting)
-{
-    int rc;
-    rc = libxl__spawn_detach(gc, starting->for_spawn);
-    if (starting->for_spawn)
-        free(starting->for_spawn);
-    free(starting);
-    return rc;
-}
 
-int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting)
-{
-    int detach;
-    int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what,
-                                               path, state,
-                                               starting->for_spawn, NULL, NULL);
-    detach = detach_offspring(gc, starting);
-    return problem ? problem : detach;
-}
+/*----- spawn implementation -----*/
 
-static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag)
-{
-    int flags;
+/*
+ * Full set of possible states of a libxl__spawn_state and its _detachable:
+ *
+ *               ss->        ss->        ss->    | ssd->       ssd->
+ *               timeout     xswatch     ssd     |  mid         ss
+ *  - Undefined   undef       undef       no     |  -           -
+ *  - Idle        Idle        Idle        no     |  -           -
+ *  - Active      Active      Active      yes    |  Active      yes
+ *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
+ *  - Detached    -           -           -      |  Active      no
+ *
+ * When in state Detached, the middle process has been sent a SIGKILL.
+ */
 
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1)
-        return ERROR_FAIL;
+/* Event callbacks. */
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path);
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs);
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status);
 
-    flags |= flag;
+/* Precondition: Partial.  Results: Detached. */
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-    if (fcntl(fd, F_SETFL, flags) == -1)
-        return ERROR_FAIL;
+/* Precondition: Partial; caller has logged failure reason.
+ * Results: Caller notified of failure;
+ *  after return, ss may be completely invalid as caller may reuse it */
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
 
-    return 0;
+void libxl__spawn_init(libxl__spawn_state *ss)
+{
+    libxl__ev_time_init(&ss->timeout);
+    libxl__ev_xswatch_init(&ss->xswatch);
+    ss->ssd = 0;
 }
 
-int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn,
-                                                pid_t innerchild),
-                      void *hook_data)
+int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    pid_t child, got;
+    STATE_AO_GC(ss->ao);
+    int r;
+    pid_t child;
     int status, rc;
-    pid_t intermediate;
-    int pipes[2];
-    unsigned char dummy = 0;
-
-    if (for_spawn) {
-        for_spawn->what = strdup(what);
-        if (!for_spawn->what) return ERROR_NOMEM;
-
-        if (libxl_pipe(ctx, pipes) < 0)
-            goto err_parent;
-        if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 ||
-            libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0)
-            goto err_parent_pipes;
-    }
 
-    intermediate = libxl_fork(ctx);
-    if (intermediate ==-1)
-        goto err_parent_pipes;
+    libxl__spawn_init(ss);
+    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    libxl__ev_child_init(&ss->ssd->mid);
+
+    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
+                                     spawn_timeout, ss->timeout_ms);
+    if (rc) goto out_err;
 
-    if (intermediate) {
+    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
+                                    spawn_watch_event, ss->xspath);
+    if (rc) goto out_err;
+
+    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
+
+    if (middle) {
         /* parent */
-        if (for_spawn) {
-            for_spawn->intermediate = intermediate;
-            for_spawn->fd = pipes[0];
-            close(pipes[1]);
-        }
         return 1;
     }
 
-    /* we are now the intermediate process */
-    if (for_spawn) close(pipes[0]);
+    /* we are now the middle process */
 
     child = fork();
     if (child == -1)
         exit(255);
     if (!child) {
-        if (for_spawn) close(pipes[1]);
         return 0; /* caller runs child code */
     }
 
-    intermediate_hook(hook_data, child);
-
-    if (!for_spawn) _exit(0); /* just detach then */
-
-    got = waitpid(child, &status, 0);
-    assert(got == child);
-
-    rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
-          WIFSIGNALED(status) && WTERMSIG(status) < 127
-          ? WTERMSIG(status)+128 : -1);
-    if (for_spawn) {
-        if (write(pipes[1], &dummy, sizeof(dummy)) != 1)
-            perror("libxl__spawn_spawn: unable to signal child exit to parent");
+    int failsig = ss->midproc_cb(gc, ss, middle);
+    if (failsig) {
+        kill(child, failsig);
+        _exit(127);
     }
-    _exit(rc);
 
- err_parent_pipes:
-    if (for_spawn) {
-        close(pipes[0]);
-        close(pipes[1]);
+    for (;;) {
+        pid_t got = waitpid(child, &status, 0);
+        if (got == -1) {
+            assert(errno == EINTR);
+            continue;
+        }
+        assert(got == child);
+        break;
     }
 
- err_parent:
-    if (for_spawn) free(for_spawn->what);
+    r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) :
+         WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 :
+         -1);
+    _exit(r);
 
-    return ERROR_FAIL;
+ out_err:
+    spawn_cleanup(gc, ss);
+    return rc;
 }
 
-static void report_spawn_intermediate_status(libxl__gc *gc,
-                                             libxl__spawn_starting *for_spawn,
-                                             int status)
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
-    if (!WIFEXITED(status)) {
-        libxl_ctx *ctx = libxl__gc_owner(gc);
-        char *intermediate_what;
-        /* intermediate process did the logging itself if it exited */
-        if ( asprintf(&intermediate_what,
-                 "%s intermediate process (startup monitor)",
-                 for_spawn->what) < 0 )
-            intermediate_what = "intermediate process (startup monitor)";
-        libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what,
-                                      for_spawn->intermediate, status);
+    int r;
+
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+
+    libxl__spawn_state_detachable *ssd = ss->ssd;
+    if (ssd) {
+        if (libxl__ev_child_inuse(&ssd->mid)) {
+            pid_t child = ssd->mid.pid;
+            r = kill(child, SIGKILL);
+            if (r && errno != ESRCH)
+                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+                     ss->what, (unsigned long)child);
+        }
+
+        /* disconnect the ss and ssd from each other */
+        ssd->ss = 0;
+        ss->ssd = 0;
     }
 }
 
-int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn)
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int r, status;
-    pid_t got;
-    int rc = 0;
+    EGC_GC;
+    spawn_cleanup(gc, ss);
+    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+}
 
-    if (!for_spawn) return 0;
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs)
+{
+    /* Before event, was Active; is now Partial. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
+    LOG(ERROR, "%s: startup timed out", ss->what);
+    spawn_failed(egc, ss); /* must be last */
+}
 
-    if (for_spawn->intermediate) {
-        r = kill(for_spawn->intermediate, SIGKILL);
-        if (r) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                         "could not kill %s intermediate process [%ld]",
-                         for_spawn->what,
-                         (unsigned long)for_spawn->intermediate);
-            abort(); /* things are very wrong */
-        }
-        got = waitpid(for_spawn->intermediate, &status, 0);
-        assert(got == for_spawn->intermediate);
-        if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
-            report_spawn_intermediate_status(gc, for_spawn, status);
-            rc = ERROR_FAIL;
-        }
-        for_spawn->intermediate = 0;
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path)
+{
+    /* On entry, is Active. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
+    char *p = libxl__xs_read(gc, 0, ss->xspath);
+    if (!p && errno != ENOENT) {
+        LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
+        spawn_failed(egc, ss); /* must be last */
+        return;
     }
-
-    free(for_spawn->what);
-    for_spawn->what = 0;
-
-    return rc;
+    ss->confirm_cb(egc, ss, p); /* must be last */
 }
 
-int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status)
+    /* Before event, was Active or Detached;
+     * is now Active or Detached except that ssd->mid is Idle */
 {
-    pid_t got;
-    int status;
-
-    if (!for_spawn) return 0;
+    EGC_GC;
+    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
+    libxl__spawn_state *ss = ssd->ss;
 
-    assert(for_spawn->intermediate);
-    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
-    if (!got) return 0;
-
-    assert(got == for_spawn->intermediate);
-    report_spawn_intermediate_status(gc, for_spawn, status);
+    if (!WIFEXITED(status)) {
+        const char *what =
+            GCSPRINTF("%s intermediate process (startup monitor)",
+                      ss ? ss->what : "(detached)");
+        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+        libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
+    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        if (!status)
+            LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
+                " when we were waiting for it to confirm startup",
+                ss->what, (unsigned long)pid);
+        else if (status <= 127)
+            LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d",
+                ss->what, (unsigned long)pid, status);
+        else if (status < 255) {
+            int sig = status - 128;
+            const char *str = strsignal(sig);
+            if (str)
+                LOG(ERROR, "%s [%ld]: died during startup due to fatal"
+                    " signal %s", ss->what, (unsigned long)pid, str);
+            else
+                LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
+                    " signal number %d", ss->what, (unsigned long)pid, sig);
+        }
+        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
+        spawn_failed(egc, ss); /* must be last use of ss */
+    }
+    free(ssd);
+}
 
-    for_spawn->intermediate = 0;
-    return ERROR_FAIL;
+void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    spawn_cleanup(gc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ae71f70..5bab4d6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -840,75 +840,197 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                                       libxl_device_pci *pcidev, int num);
 _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
 
-/* xl_exec */
+/*
+ *----- spawn -----
+ *
+ * Higher-level double-fork and separate detach eg as for device models
+ *
+ * Each libxl__spawn_state is in one of the conventional states
+ *    Undefined, Idle, Active
+ */
 
- /* higher-level double-fork and separate detach eg as for device models */
+typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
+/* this type is never defined, so no objects of this type exist
+ * fixme-ao  This should go away completely.  */
 
-typedef struct {
-    /* put this in your own status structure as returned to application */
-    /* all fields are private to libxl_spawn_... */
-    pid_t intermediate;
-    int fd;
-    char *what; /* malloc'd in spawn_spawn */
-} libxl__spawn_starting;
+typedef struct libxl__spawn_state libxl__spawn_state;
 
-typedef struct {
-    char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */
-    const char *pid_path; /* only for libxl_spawner_record_pid */
-    int domid;
-    libxl__spawn_starting *for_spawn;
-} libxl__spawner_starting;
+/* Clears out a spawn state; idempotent. */
+_hidden void libxl__spawn_init(libxl__spawn_state*);
 
 /*
- * libxl__spawn_spawn - Create a new process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * what: string describing the spawned process
- * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
- * hook_data: data to pass to the hook function
+ * libxl__spawn_spawn - Create a new process which will become daemonic
+ * Forks twice, to allow the child to detach entirely from the parent.
+ *
+ * We call the two generated processes the "middle child" (result of
+ * the first fork) and the "inner child" (result of the second fork
+ * which takes place in the middle child).
+ *
+ * The inner child must soon exit or exec.  If must also soon exit or
+ * notify the parent of its successful startup by writing to the
+ * xenstore path xspath (or by other means).  xspath may be 0 to
+ * indicate that only other means are being used.
+ *
+ * The user (in the parent) will be called back (confirm_cb) every
+ * time that xenstore path is modified.
+ *
+ * In both children, the ctx is not fully useable: gc and logging
+ * operations are OK, but operations on Xen and xenstore are not.
+ * (The restrictions are the same as those which apply to children
+ * made with libxl__ev_child_fork.)
+ *
+ * midproc_cb will be called in the middle child, with the pid of the
+ * inner child; this could for example record the pid.  midproc_cb
+ * should be fast, and should return.  It will be called (reentrantly)
+ * within libxl__spawn_init.
+ *
+ * failure_cb will be called in the parent on failure of the
+ * intermediate or final child; an error message will have been
+ * logged.
+ *
+ * confirm_cb and failure_cb will not be called reentrantly from
+ * within libxl__spawn_spawn.
+ *
+ * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
- *  < 0   error, for_spawn need not be detached
- *   +1   caller is the parent, must call detach on *for_spawn eventually
+ *  < 0   error, *spawn is now Idle and need not be detached
+ *   +1   caller is the parent, *spawn is Active and must eventually be detached
  *    0   caller is now the inner child, should probably call libxl__exec
- * Caller, may pass 0 for for_spawn, in which case no need to detach.
+ *
+ * The spawn state must be Undefined or Idle on entry.
  */
-_hidden int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
-                      void *hook_data);
+_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl_spawner_record_pid - Record given pid in xenstore
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * innerchild: pid of the child
+ * libxl__spawn_detach - Detaches the daemonic child.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, failures of either child are no
+ * longer repaorted via failure_cb.
+ *
+ * If called before the inner child has been created, this may prevent
+ * it from running at all.  Thus this should be called only when the
+ * inner child has notified that it is ready.  Normally it will be
+ * called from within confirm_cb.
  *
- * This function is passed as intermediate_hook to libxl__spawn_spawn.
+ * Logs errors.
+ *
+ * The spawn state must be Active or Idle on entry and will be Idle
+ * on return.
  */
-_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild);
+_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
- * libxl__spawn_confirm_offspring_startup - Wait for child state
- * gc: allocation pool
- * timeout: how many seconds to wait for the child
- * what: string describing the spawned process
- * path: path to the state file in xenstore
- * state: expected string to wait for in path (optional)
- * starting: malloc'd pointer to libxl__spawner_starting
+ * If successful, this should return 0.
  *
- * Returns 0 on success, and < 0 on error.
+ * Otherwise it should return a signal number, which will be
+ * sent to the inner child; the overall spawn will then fail.
+ */
+typedef int /* signal number */
+libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner);
+
+/*
+ * Called if the spawn failed.  The reason will have been logged.
+ * The spawn state will be Idle on entry to the callback (and
+ * it may be reused immediately if desired).
+ */
+typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
+
+/*
+ * Called when the xspath watch triggers.  xspath will have been read
+ * and the result placed in xsdata; if that failed because the key
+ * didn't exist, xspath==0.  (If it failed for some other reason,
+ * the spawn machinery calls failure_cb instead.)
  *
- * This function waits the given timeout for the given path to appear
- * in xenstore, and optionally for state in path.
- * The intermediate process created in libxl__spawn_spawn is killed.
- * The memory referenced by starting->for_spawn and starting is free'd.
+ * If the child has indicated its successful startup, or a failure
+ * has occurred, this should call libxl__spawn_detach.
+ *
+ * If the child is still starting up, should simply return, doing
+ * nothing.
+ *
+ * The spawn state will be Active on entry to the callback; there
+ * are no restrictions on the state on return; it may even have
+ * been detached and reused.
+ */
+typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
+                                     const char *xsdata);
+
+typedef struct {
+    /* Private to the spawn implementation.
+     */
+    /* This separate struct, from malloc, allows us to "detach"
+     * the child and reap it later, when our user has gone
+     * away and freed its libxl__spawn_state */
+    struct libxl__spawn_state *ss;
+    libxl__ev_child mid;
+} libxl__spawn_state_detachable;
+
+struct libxl__spawn_state {
+    /* must be filled in by user and remain valid */
+    libxl__ao *ao;
+    const char *what;
+    const char *xspath;
+    const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */
+    int timeout_ms; /* -1 means forever */
+    libxl__spawn_midproc_cb *midproc_cb;
+    libxl__spawn_failure_cb *failure_cb;
+    libxl__spawn_confirm_cb *confirm_cb;
+
+    /* remaining fields are private to libxl_spawn_... */
+    libxl__ev_time timeout;
+    libxl__ev_xswatch xswatch;
+    libxl__spawn_state_detachable *ssd;
+};
+
+static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
+    { return !!ss->ssd; }
+
+/*
+ * libxl_spawner_record_pid - Record given pid in xenstore
+ *
+ * This function can be passed directly as an intermediate_hook to
+ * libxl__spawn_spawn.  On failure, returns the value SIGTERM.
  */
-_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting);
+_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
+                                    pid_t innerchild);
+
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdoms. */
+
+typedef struct {
+    /* mixed - user must fill in public parts only: */
+    libxl__dm_spawn_state stubdom; /* will always remain the first member */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->stubdom,) */
+    /* private to libxl__spawn_stubdom: */
+    libxl_domain_config stubdom_config;
+    libxl__domain_build_state stubdom_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stubdom_spawn_state;
+
+_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
+
 
 /*
  * libxl__wait_for_offspring - Wait for child state
@@ -941,31 +1063,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
                                                        void *userdata),
                                  void *check_callback_userdata);
 
-/*
- * libxl__spawn_detach - Kill intermediate process from spawn_spawn
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors.  Idempotent, but only permitted after successful
- * call to libxl__spawn_spawn, and no point calling it again if it fails.
- */
-_hidden int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
-
-/*
- * libxl__spawn_check - Check intermediate child process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors but also returns them.
- * Caller must still call detach.
- */
-_hidden int libxl__spawn_check(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
@@ -984,15 +1081,6 @@ _hidden int libxl__domain_build(libxl__gc *gc,
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
-_hidden int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
-_hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1000,10 +1088,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
   /* Caller must either: pass starting_r==0, or on successful
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
-_hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting *starting);
-_hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,
                                 uint32_t domid, char *state,
                                 libxl__spawn_starting *spawning,
@@ -1566,6 +1650,32 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
 
+/*----- Domain creation -----*/
+
+typedef struct libxl__domain_create_state libxl__domain_create_state;
+
+typedef void libxl__domain_create_cb(libxl__egc *egc,
+                                     libxl__domain_create_state*,
+                                     int rc, uint32_t domid);
+
+struct libxl__domain_create_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl_domain_config *guest_config;
+    int restore_fd;
+    libxl_console_ready console_cb;
+    void *console_cb_priv;
+    libxl__domain_create_cb *callback;
+    /* private to domain_create */
+    int guest_domid;
+    libxl__domain_build_state build_state;
+    union {
+        libxl__dm_spawn_state dmss;
+        libxl__stubdom_spawn_state sdss;
+    };
+};
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..9e66536 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1668,8 +1668,8 @@ start:
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                            cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                          cb, &child_console_pid,
+                                          &domid, restore_fd, 0);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1677,7 +1677,7 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                      cb, &child_console_pid, &domid, 0);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ9-0006CI-BD; Fri, 13 Apr 2012 18:40:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ3-000651-4G
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:27 +0000
Received: from [85.158.139.83:54051] by server-4.bemta-5.messagelabs.com id
	28/9D-10788-A13788F4; Fri, 13 Apr 2012 18:40:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334342424!23649508!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2002 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPy-0002Qz-59; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPy-0002j6-2p;
	Fri, 13 Apr 2012 19:40:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:14 +0100
Message-ID: <1334342414-10289-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/20] libxl: convert console callback to
	libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the old console callback.  (Its reentrancy properties were
troublesome: in principle, the event loop might be reentered during
the callback, and the libxl__domain_create_state swept out from under
the feet of the domain creation.)

As a side effect of the new code arrangements, the console callback
for non-bootloader-using PV guests now occurs near the end of domain
creation, in the same place as for HVM guests, rather than near the
start.

The new arrangements should in principle mean that by the time the
console is described as ready by the callback, the xenstore key is
indeed ready.  So in the future the timeout might be removed from
the console client.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.h            |   17 ++++++-----
 tools/libxl/libxl_bootloader.c |    3 ++
 tools/libxl/libxl_create.c     |   59 +++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h   |    6 +++-
 tools/libxl/libxl_types.idl    |    2 +
 tools/libxl/xl_cmdimpl.c       |   25 ++++++++++-------
 6 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bfe684..de8d1872 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
-typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
-   * properties need to be documented but they may turn out to be too
-   * awkward */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            const libxl_asyncop_how *ao_how);
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how);
+                                const libxl_asyncop_how *ao_how,
+                                const libxl_asyncprogress_how *aop_console_how);
+  /* A progress report will be made via ao_console_how, of type
+   * domain_create_console_available, when the domain's primary
+   * console is available and can be connected to.
+   */
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index eaec46a..3f6f129 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -375,6 +375,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    if (bl->console_available)
+        bl->console_available(egc, bl);
+
     int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
     int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 156c5c7..a457e09 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,10 +550,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl);
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -571,8 +576,6 @@ static void initiate_domain_create(libxl__egc *egc,
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
     int restore_fd = dcs->restore_fd;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
@@ -590,11 +593,6 @@ static void initiate_domain_create(libxl__egc *egc,
     dcs->guest_domid = domid;
     dcs->dmss.guest_domid = 0; /* means we haven't spawned */
 
-    if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
-
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
@@ -610,6 +608,7 @@ static void initiate_domain_create(libxl__egc *egc,
         dcs->bl.ao = ao;
         dcs->bl.disk = bootdisk;
         dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.console_available = domcreate_bootloader_console_available;
         dcs->bl.info = &d_config->b_info,
             
         libxl__bootloader_run(egc, &dcs->bl);
@@ -623,6 +622,21 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    domcreate_console_available(egc, dcs);
+}
+
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs) {
+    libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
+                              NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
+                                        dcs->guest_domid));
+}
+
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int ret)
@@ -759,8 +773,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
 
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -798,12 +810,7 @@ static void domcreate_devmodel_started(libxl__egc *egc,
             goto error_out;
         }
     }
-    if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
-                (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-                 d_config->b_info.u.pv.bootloader ))) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
+    domcreate_console_available(egc, dcs);
 
     domcreate_complete(egc, dcs, 0);
     return;
@@ -842,8 +849,9 @@ static void domain_create_cb(libxl__egc *egc,
                              int rc, uint32_t domid);
 
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            int restore_fd, const libxl_asyncop_how *ao_how)
+                            uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
     AO_CREATE(ctx, 0, ao_how);
     libxl__app_domain_create_state *cdcs;
@@ -852,9 +860,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
     cdcs->dcs.restore_fd = restore_fd;
-    cdcs->dcs.console_cb = cb;
-    cdcs->dcs.console_cb_priv = priv;
     cdcs->dcs.callback = domain_create_cb;
+    libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
     cdcs->domid_out = domid;
 
     initiate_domain_create(egc, &cdcs->dcs);
@@ -876,19 +883,21 @@ static void domain_create_cb(libxl__egc *egc,
 }
     
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
                             uint32_t *domid,
-                            const libxl_asyncop_how *ao_how)
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
+    return do_domain_create(ctx, d_config, domid, -1,
+                            ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how)
+                                const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
+    return do_domain_create(ctx, d_config, domid, restore_fd,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 977db2a..b2eefd6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1651,11 +1651,14 @@ int libxl__openptys(libxl__openpty_state *op,
 typedef struct libxl__bootloader_state libxl__bootloader_state;
 typedef void libxl__run_bootloader_callback(libxl__egc*,
                                 libxl__bootloader_state*, int rc);
+typedef void libxl__bootloader_console_callback(libxl__egc*,
+                                libxl__bootloader_state*);
 
 struct libxl__bootloader_state {
     /* caller must fill these in, and they must all remain valid */
     libxl__ao *ao;
     libxl__run_bootloader_callback *callback;
+    libxl__bootloader_console_callback *console_available;
     libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
     libxl_device_disk *disk;
     uint32_t domid;
@@ -1691,8 +1694,7 @@ struct libxl__domain_create_state {
     libxl__ao *ao;
     libxl_domain_config *guest_config;
     int restore_fd;
-    libxl_console_ready console_cb;
-    void *console_cb_priv;
+    libxl_asyncprogress_how aop_console_how;
     libxl__domain_create_cb *callback;
     /* private to domain_create */
     int guest_domid;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..f28d785 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -444,6 +444,7 @@ libxl_event_type = Enumeration("event_type", [
     (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
+    (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -469,4 +470,5 @@ libxl_event = Struct("event",[
            ("operation_complete", Struct(None, [
                                         ("rc", integer),
                                  ])),
+           ("domain_create_console_available", Struct(None, [])),
            ]))])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9e66536..ce52599 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1430,16 +1430,18 @@ static int freemem(libxl_domain_build_info *b_info)
     return ERROR_NOMEM;
 }
 
-static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
+static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv)
 {
     pid_t *pid = priv;
 
+    libxl_event_free(ctx, ev);
+
     *pid = fork();
     if (*pid < 0) {
         perror("unable to fork xenconsole");
-        return ERROR_FAIL;
+        return;
     } else if (*pid > 0)
-        return 0;
+        return;
 
     postfork();
 
@@ -1506,7 +1508,7 @@ static int create_domain(struct domain_create *dom_info)
     int config_len = 0;
     int restore_fd = -1;
     int status = 0;
-    libxl_console_ready cb;
+    const libxl_asyncprogress_how *autoconnect_console_how;
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
@@ -1660,24 +1662,27 @@ start:
         goto error_out;
     }
 
+    libxl_asyncprogress_how autoconnect_console_how_buf;
     if ( dom_info->console_autoconnect ) {
-        cb = autoconnect_console;
+        autoconnect_console_how_buf.callback = autoconnect_console;
+        autoconnect_console_how_buf.for_callback = &child_console_pid;
+        autoconnect_console_how = &autoconnect_console_how_buf;
     }else{
-        cb = NULL;
+        autoconnect_console_how = 0;
     }
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                          cb, &child_console_pid,
-                                          &domid, restore_fd, 0);
+                                          &domid, restore_fd,
+                                          0, autoconnect_console_how);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
          */
         restore_file = NULL;
     }else{
-        ret = libxl_domain_create_new(ctx, &d_config,
-                                      cb, &child_console_pid, &domid, 0);
+        ret = libxl_domain_create_new(ctx, &d_config, &domid,
+                                      0, autoconnect_console_how);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ9-0006Cp-P3; Fri, 13 Apr 2012 18:40:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ3-00062q-6p
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:27 +0000
Received: from [85.158.143.35:33607] by server-3.bemta-4.messagelabs.com id
	1C/D2-05853-A13788F4; Fri, 13 Apr 2012 18:40:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334342425!13171902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23871 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qq-Ug; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iq-Sm;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:10 +0100
Message-ID: <1334342414-10289-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/20] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn becomes a callback-style asynchronous function.
The implementation is now in terms of libxl__ev_* including
libxl_ev_child.

All the callers need to be updated.  This includes the device model
spawning functions libxl__create_device_model and
libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
abolished; instead the dm spawner calls back.

(The choice of which kind of device model to create is lifted out of
what used to be libxl__create_device_model, because that function was
indirectly recursive.  Recursive callback-style operations are clumsy
because they require a pointer indirection for the nested states.)

Waiting for proper device model startup it is no longer notionally
optional.  Previously the code appeared to tolerate this by passing
NULL for various libxl__spawner_starting* parameters to device model
spawners.  However, this was not used anywhere.

Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
no longer supported.  It remains as an unused formal parameter to
avoid updating, in this patch, all the call sites which pass NULL.
libxl__wait_for_offspring is in any case itself an obsolete function,
so this wrinkle will go away when its callers are updated to use the
event system.  Consequently libxl__spawn_check is also abolished.

The "console ready" callback also remains unchanged in this patch.
The API for this needs to be reviewed in the context of the event
series and its reentrancy restrictions documented.

Thus their callers need to be updated.  These are the domain creation
functions libxl_domain_create_new and _restore.  These functions now
take ao_hows, and have a private state structure.

However domain creation remains not completely converted to the event
mechanism; in particular it runs the outward-facing function
libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
happens in the current code this is not a bug because none of the rest
of the functionality surrounding the bootloader call will mind if the
event loop is reentered in the middle of its execution.

The file-scope function libxl__set_fd_flag which was used by the
previous spawn arrangements becomes unused and is removed; other
places in libxl can use libxl_fd_set_nonblock and
libxl_fd_set_cloexec, which of course remain.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   14 ++-
 tools/libxl/libxl_create.c   |  198 +++++++++++++++++++-----
 tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
 tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
 tools/libxl/xl_cmdimpl.c     |    6 +-
 6 files changed, 677 insertions(+), 400 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 477b72a..6f59364 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
+   * properties need to be documented but they may turn out to be too
+   * awkward */
+
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            const libxl_asyncop_how *ao_how);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how);
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8408c26..09a03a7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -537,16 +537,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
-static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+/*----- main domain creation -----*/
+
+/* We have a linear control flow; only one event callback is
+ * outstanding at any time.  Each initiation and callback function
+ * arranges for the next to be called, as the very last thing it
+ * does.  (If that particular sub-operation is not needed, a
+ * function will call the next event callback directly.)
+ */
+
+/* Event callbacks, in this order: */
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+/* Our own function to clean up and call the user's callback.
+ * The final call in the sequence. */
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc);
+
+static void initiate_domain_create(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs)
 {
+    STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
     domid = 0;
 
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
@@ -559,9 +583,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
+    dcs->guest_domid = domid;
+    dcs->dmss.guest_domid = 0; /* means we haven't spawned */
+
     if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
@@ -585,7 +612,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(state, 0, sizeof(*state));
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+    libxl__domain_build_state *state = &dcs->build_state;
+    dcs->dmss.spawn.ao = ao;
+    dcs->dmss.guest_config = dcs->guest_config;
+    dcs->dmss.build_state = &dcs->build_state;
+    dcs->dmss.callback = domcreate_devmodel_started;
 
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
@@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        ret = libxl__create_device_model(gc, domid, d_config,
-                                         state, &dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to create device model: %d", ret);
-            goto error_out;
-        }
+        dcs->dmss.guest_domid = domid;
+        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
+            libxl__spawn_stubdom(egc, &dcs->sdss);
+        else
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+        return;
+
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
@@ -669,7 +701,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
+            dcs->dmss.guest_domid = domid;
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+            return;
         }
         break;
     }
@@ -678,17 +712,41 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
-    if (dm_starting) {
+    assert(!dcs->dmss.guest_domid);
+    domcreate_devmodel_started(egc, &dcs->dmss, 0);
+    return;
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss);
+    STATE_AO_GC(dmss->spawn.ao);
+    int i;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
+    if (ret) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "device model did not start: %d", ret);
+        goto error_out;
+    }
+
+    if (dcs->dmss.guest_domid) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "device model did not start: %d", ret);
-            goto error_out;
-        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
@@ -716,38 +774,94 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
-    *domid_out = domid;
-    return 0;
+    domcreate_complete(egc, dcs, 0);
+    return;
 
 error_out:
-    if (domid)
-        libxl_domain_destroy(ctx, domid);
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
 
-    return ret;
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc) {
+    STATE_AO_GC(dcs->ao);
+
+    if (rc) {
+        if (dcs->guest_domid) {
+            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
+            if (rc2)
+                LOG(ERROR, "unable to destroy domain %d following"
+                    " failed creation", dcs->guest_domid);
+        }
+        dcs->guest_domid = -1;
+    }
+    dcs->callback(egc, dcs, rc, dcs->guest_domid);
+}
+
+/*----- application-facing domain creation interface -----*/
+
+typedef struct {
+    libxl__domain_create_state dcs;
+    uint32_t *domid_out;
+} libxl__app_domain_create_state;
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid);
+
+static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, 0, ao_how);
+    libxl__app_domain_create_state *cdcs;
+
+    GCNEW(cdcs);
+    cdcs->dcs.ao = ao;
+    cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.console_cb = cb;
+    cdcs->dcs.console_cb_priv = priv;
+    cdcs->dcs.callback = domain_create_cb;
+    cdcs->domid_out = domid;
+
+    initiate_domain_create(egc, &cdcs->dcs);
+
+    return AO_INPROGRESS;
 }
 
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid)
+{
+    libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs);
+    STATE_AO_GC(cdcs->dcs.ao);
+
+    if (!rc)
+        *cdcs->domid_out = domid;
+
+    libxl__ao_complete(egc, ao, rc);
+}
+    
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv,
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3921e2a..15472a8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -667,24 +667,28 @@ retry_transaction:
     return 0;
 }
 
-static int libxl__create_stubdom(libxl__gc *gc,
-                                 int guest_domid,
-                                 libxl_domain_config *guest_config,
-                                 libxl__domain_build_state *d_state,
-                                 libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc);
+
+void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state *sdss)
 {
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state[1];
-    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
-    libxl__spawner_starting *dm_starting = 0;
+
+    /* convenience aliases */
+    libxl_domain_config *dm_config = &sdss->stubdom_config;
+    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
+    int guest_domid = sdss->stubdom.guest_domid;
+    libxl__domain_build_state *d_state = sdss->stubdom.build_state;
+    libxl__domain_build_state *stubdom_state = &sdss->stubdom_state;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -692,6 +696,8 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
+    sdss->pvqemu.guest_domid = 0;
+
     libxl_domain_create_info_init(&dm_config->c_info);
     dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
@@ -739,10 +745,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
     if (ret)
         goto out;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
     ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
@@ -850,42 +856,67 @@ retry_transaction:
             goto out_free;
     }
 
-    if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 dm_config,
-                                 stubdom_state,
-                                 &dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-
-    libxl_domain_unpause(ctx, dm_domid);
+    sdss->pvqemu.guest_domid = dm_domid;
+    sdss->pvqemu.guest_config = &sdss->stubdom_config;
+    sdss->pvqemu.build_state = &sdss->stubdom_state;
+    sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
-    if (starting_r) {
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = guest_domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
-        (*starting_r)->for_spawn = NULL;
-    }
+    libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    ret = 0;
+    free(args);
+    return;
 
 out_free:
     free(args);
 out:
-    return ret;
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
 }
 
-int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__stubdom_spawn_state *sdss =
+        CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) goto out;
+
+    rc = libxl_domain_unpause(CTX, dm_domid);
+    if (rc) goto out;
+
+ out:
+    if (rc) {
+        if (dm_domid)
+            libxl_domain_destroy(CTX, dm_domid);
+    }
+    sdss->callback(egc, &sdss->stubdom, rc);
+}
+
+/* callbacks passed to libxl__spawn_spawn */
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata);
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn);
+
+/* our "next step" function, called from those callbacks and elsewhere */
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
+{
+    /* convenience aliases */
+    int domid = dmss->guest_domid;
+    libxl__domain_build_state *state = dmss->build_state;
+    libxl__spawn_state *spawn = &dmss->spawn;
+
+    STATE_AO_GC(dmss->spawn.ao);
+
+    libxl_ctx *ctx = CTX;
+    libxl_domain_config *guest_config = dmss->guest_config;
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
@@ -893,15 +924,13 @@ int libxl__create_device_model(libxl__gc *gc,
     int logfile_w, null;
     int rc;
     char **args, **arg;
-    libxl__spawner_starting buf_starting, *p;
     xs_transaction_t t;
     char *vm_path;
     char **pass_stuff;
     const char *dm;
 
     if (libxl_defbool_val(b_info->device_model_stubdomain)) {
-        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
-        goto out;
+        abort();
     }
 
     dm = libxl__domain_device_model(gc, b_info);
@@ -945,25 +974,8 @@ int libxl__create_device_model(libxl__gc *gc,
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
-    if (starting_r) {
-        rc = ERROR_NOMEM;
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        if (!*starting_r)
-            goto out_close;
-        p = *starting_r;
-        p->for_spawn = calloc(1, sizeof(libxl__spawn_starting));
-    } else {
-        p = &buf_starting;
-        p->for_spawn = NULL;
-    }
-
-    p->domid = domid;
-    p->dom_path = libxl__xs_get_dompath(gc, domid);
-    p->pid_path = "image/device-model-pid";
-    if (!p->dom_path) {
-        rc = ERROR_FAIL;
-        goto out_close;
-    }
+    const char *dom_path = libxl__xs_get_dompath(gc, domid);
+    spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid");
 
     if (vnc && vnc->passwd) {
         /* This xenstore key will only be used by qemu-xen-traditionnal.
@@ -971,7 +983,7 @@ int libxl__create_device_model(libxl__gc *gc,
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
-        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path));
+        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path));
         if (vm_path) {
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
@@ -988,8 +1000,15 @@ retry_transaction:
     for (arg = args; *arg; arg++)
         LIBXL__LOG(CTX, XTL_DEBUG, "  %s", *arg);
 
-    rc = libxl__spawn_spawn(gc, p->for_spawn, "device model",
-                            libxl_spawner_record_pid, p);
+    spawn->what = GCSPRINTF("domain %d device model", domid);
+    spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid);
+    spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+    spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
+    spawn->midproc_cb = libxl__spawn_record_pid;
+    spawn->confirm_cb = device_model_confirm;
+    spawn->failure_cb = device_model_startup_failed;
+
+    rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
     if (!rc) { /* inner child */
@@ -1004,30 +1023,61 @@ out_close:
     close(logfile_w);
     free(args);
 out:
-    return rc;
+    if (rc)
+        device_model_spawn_outcome(egc, dmss, rc);
+}
+
+
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    STATE_AO_GC(spawn->ao);
+
+    if (!xsdata)
+        return;
+
+    if (strcmp(xsdata, "running"))
+        return;
+
+    libxl__spawn_detach(gc, spawn);
+
+    device_model_spawn_outcome(egc, dmss, 0);
 }
 
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
+}
 
-int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl__domain_build_state *state,
-                                libxl__spawner_starting *starting)
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc)
 {
-    char *path;
-    int domid = starting->domid;
-    int ret, ret2;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    ret = libxl__spawn_confirm_offspring_startup(gc,
-                                     LIBXL_DEVICE_MODEL_START_TIMEOUT,
-                                     "Device Model", path, "running", starting);
+    STATE_AO_GC(dmss->spawn.ao);
+    int ret2;
+
+    if (rc)
+        LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc);
+
+    libxl__domain_build_state *state = dmss->build_state;
+
     if (state->saved_state) {
         ret2 = unlink(state->saved_state);
-        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
-                                   "failed to remove device-model state %s\n",
-                                   state->saved_state);
-        /* Do not clobber spawn_confirm error code with unlink error code. */
-        if (!ret) ret = ret2;
+        if (ret2) {
+            LOGE(ERROR, "%s: failed to remove device-model state %s",
+                 dmss->spawn.what, state->saved_state);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
-    return ret;
+
+    rc = 0;
+
+ out:
+    dmss->callback(egc, dmss, rc);
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
@@ -1123,15 +1173,6 @@ out:
     return ret;
 }
 
-int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                             libxl_domain_config *guest_config,
-                             libxl__domain_build_state *state,
-                             libxl__spawner_starting **starting_r)
-{
-    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 2ee2154..d44b702 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
+                            pid_t innerchild)
 {
-    libxl__spawner_starting *starting = for_spawn;
-    struct xs_handle *xsh;
-    char *path = NULL, *pid = NULL;
-    int len;
-
-    if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0)
-        goto out;
+    struct xs_handle *xsh = NULL;
+    const char *pid = NULL;
+    int rc, xsok;
 
-    len = asprintf(&pid, "%d", innerchild);
-    if (len < 0)
-        goto out;
+    pid = GCSPRINTF("%d", innerchild);
 
     /* we mustn't use the parent's handle in the child */
     xsh = xs_daemon_open();
+    if (!xsh) {
+        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
+             spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
 
-    xs_write(xsh, XBT_NULL, path, pid, len);
+    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
+    if (!xsok) {
+        LOGE(ERROR,
+             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    rc = 0;
 
-    xs_daemon_close(xsh);
 out:
-    free(path);
-    free(pid);
+    if (xsh) xs_daemon_close(xsh);
+    return rc ? SIGTERM : 0;
 }
 
 int libxl__wait_for_offspring(libxl__gc *gc,
@@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc,
     tv.tv_sec = timeout;
     tv.tv_usec = 0;
     nfds = xs_fileno(xsh) + 1;
-    if (spawning && spawning->fd > xs_fileno(xsh))
-        nfds = spawning->fd + 1;
+    assert(!spawning);
 
     while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        if ( spawning ) {
-            rc = libxl__spawn_check(gc, spawning);
-            if ( rc ) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "%s died during startup", what);
-                rc = -1;
-                goto err_died;
-            }
-        }
         p = xs_read(xsh, XBT_NULL, path, &len);
         if ( NULL == p )
             goto again;
@@ -218,8 +214,6 @@ again:
         free(p);
         FD_ZERO(&rfds);
         FD_SET(xs_fileno(xsh), &rfds);
-        if (spawning)
-            FD_SET(spawning->fd, &rfds);
         rc = select(nfds, &rfds, NULL, NULL, &tv);
         if (rc > 0) {
             if (FD_ISSET(xs_fileno(xsh), &rfds)) {
@@ -229,207 +223,215 @@ again:
                 else
                     goto again;
             }
-            if (spawning && FD_ISSET(spawning->fd, &rfds)) {
-                unsigned char dummy;
-                if (read(spawning->fd, &dummy, sizeof(dummy)) != 1)
-                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG,
-                                     "failed to read spawn status pipe");
-            }
         }
     }
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what);
-err_died:
+
     xs_unwatch(xsh, path, path);
     xs_daemon_close(xsh);
 err:
     return -1;
 }
 
-static int detach_offspring(libxl__gc *gc,
-                               libxl__spawner_starting *starting)
-{
-    int rc;
-    rc = libxl__spawn_detach(gc, starting->for_spawn);
-    if (starting->for_spawn)
-        free(starting->for_spawn);
-    free(starting);
-    return rc;
-}
 
-int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting)
-{
-    int detach;
-    int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what,
-                                               path, state,
-                                               starting->for_spawn, NULL, NULL);
-    detach = detach_offspring(gc, starting);
-    return problem ? problem : detach;
-}
+/*----- spawn implementation -----*/
 
-static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag)
-{
-    int flags;
+/*
+ * Full set of possible states of a libxl__spawn_state and its _detachable:
+ *
+ *               ss->        ss->        ss->    | ssd->       ssd->
+ *               timeout     xswatch     ssd     |  mid         ss
+ *  - Undefined   undef       undef       no     |  -           -
+ *  - Idle        Idle        Idle        no     |  -           -
+ *  - Active      Active      Active      yes    |  Active      yes
+ *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
+ *  - Detached    -           -           -      |  Active      no
+ *
+ * When in state Detached, the middle process has been sent a SIGKILL.
+ */
 
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1)
-        return ERROR_FAIL;
+/* Event callbacks. */
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path);
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs);
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status);
 
-    flags |= flag;
+/* Precondition: Partial.  Results: Detached. */
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-    if (fcntl(fd, F_SETFL, flags) == -1)
-        return ERROR_FAIL;
+/* Precondition: Partial; caller has logged failure reason.
+ * Results: Caller notified of failure;
+ *  after return, ss may be completely invalid as caller may reuse it */
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
 
-    return 0;
+void libxl__spawn_init(libxl__spawn_state *ss)
+{
+    libxl__ev_time_init(&ss->timeout);
+    libxl__ev_xswatch_init(&ss->xswatch);
+    ss->ssd = 0;
 }
 
-int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn,
-                                                pid_t innerchild),
-                      void *hook_data)
+int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    pid_t child, got;
+    STATE_AO_GC(ss->ao);
+    int r;
+    pid_t child;
     int status, rc;
-    pid_t intermediate;
-    int pipes[2];
-    unsigned char dummy = 0;
-
-    if (for_spawn) {
-        for_spawn->what = strdup(what);
-        if (!for_spawn->what) return ERROR_NOMEM;
-
-        if (libxl_pipe(ctx, pipes) < 0)
-            goto err_parent;
-        if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 ||
-            libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0)
-            goto err_parent_pipes;
-    }
 
-    intermediate = libxl_fork(ctx);
-    if (intermediate ==-1)
-        goto err_parent_pipes;
+    libxl__spawn_init(ss);
+    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    libxl__ev_child_init(&ss->ssd->mid);
+
+    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
+                                     spawn_timeout, ss->timeout_ms);
+    if (rc) goto out_err;
 
-    if (intermediate) {
+    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
+                                    spawn_watch_event, ss->xspath);
+    if (rc) goto out_err;
+
+    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
+
+    if (middle) {
         /* parent */
-        if (for_spawn) {
-            for_spawn->intermediate = intermediate;
-            for_spawn->fd = pipes[0];
-            close(pipes[1]);
-        }
         return 1;
     }
 
-    /* we are now the intermediate process */
-    if (for_spawn) close(pipes[0]);
+    /* we are now the middle process */
 
     child = fork();
     if (child == -1)
         exit(255);
     if (!child) {
-        if (for_spawn) close(pipes[1]);
         return 0; /* caller runs child code */
     }
 
-    intermediate_hook(hook_data, child);
-
-    if (!for_spawn) _exit(0); /* just detach then */
-
-    got = waitpid(child, &status, 0);
-    assert(got == child);
-
-    rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
-          WIFSIGNALED(status) && WTERMSIG(status) < 127
-          ? WTERMSIG(status)+128 : -1);
-    if (for_spawn) {
-        if (write(pipes[1], &dummy, sizeof(dummy)) != 1)
-            perror("libxl__spawn_spawn: unable to signal child exit to parent");
+    int failsig = ss->midproc_cb(gc, ss, middle);
+    if (failsig) {
+        kill(child, failsig);
+        _exit(127);
     }
-    _exit(rc);
 
- err_parent_pipes:
-    if (for_spawn) {
-        close(pipes[0]);
-        close(pipes[1]);
+    for (;;) {
+        pid_t got = waitpid(child, &status, 0);
+        if (got == -1) {
+            assert(errno == EINTR);
+            continue;
+        }
+        assert(got == child);
+        break;
     }
 
- err_parent:
-    if (for_spawn) free(for_spawn->what);
+    r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) :
+         WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 :
+         -1);
+    _exit(r);
 
-    return ERROR_FAIL;
+ out_err:
+    spawn_cleanup(gc, ss);
+    return rc;
 }
 
-static void report_spawn_intermediate_status(libxl__gc *gc,
-                                             libxl__spawn_starting *for_spawn,
-                                             int status)
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
-    if (!WIFEXITED(status)) {
-        libxl_ctx *ctx = libxl__gc_owner(gc);
-        char *intermediate_what;
-        /* intermediate process did the logging itself if it exited */
-        if ( asprintf(&intermediate_what,
-                 "%s intermediate process (startup monitor)",
-                 for_spawn->what) < 0 )
-            intermediate_what = "intermediate process (startup monitor)";
-        libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what,
-                                      for_spawn->intermediate, status);
+    int r;
+
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+
+    libxl__spawn_state_detachable *ssd = ss->ssd;
+    if (ssd) {
+        if (libxl__ev_child_inuse(&ssd->mid)) {
+            pid_t child = ssd->mid.pid;
+            r = kill(child, SIGKILL);
+            if (r && errno != ESRCH)
+                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+                     ss->what, (unsigned long)child);
+        }
+
+        /* disconnect the ss and ssd from each other */
+        ssd->ss = 0;
+        ss->ssd = 0;
     }
 }
 
-int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn)
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int r, status;
-    pid_t got;
-    int rc = 0;
+    EGC_GC;
+    spawn_cleanup(gc, ss);
+    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+}
 
-    if (!for_spawn) return 0;
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs)
+{
+    /* Before event, was Active; is now Partial. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
+    LOG(ERROR, "%s: startup timed out", ss->what);
+    spawn_failed(egc, ss); /* must be last */
+}
 
-    if (for_spawn->intermediate) {
-        r = kill(for_spawn->intermediate, SIGKILL);
-        if (r) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                         "could not kill %s intermediate process [%ld]",
-                         for_spawn->what,
-                         (unsigned long)for_spawn->intermediate);
-            abort(); /* things are very wrong */
-        }
-        got = waitpid(for_spawn->intermediate, &status, 0);
-        assert(got == for_spawn->intermediate);
-        if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
-            report_spawn_intermediate_status(gc, for_spawn, status);
-            rc = ERROR_FAIL;
-        }
-        for_spawn->intermediate = 0;
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path)
+{
+    /* On entry, is Active. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
+    char *p = libxl__xs_read(gc, 0, ss->xspath);
+    if (!p && errno != ENOENT) {
+        LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
+        spawn_failed(egc, ss); /* must be last */
+        return;
     }
-
-    free(for_spawn->what);
-    for_spawn->what = 0;
-
-    return rc;
+    ss->confirm_cb(egc, ss, p); /* must be last */
 }
 
-int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status)
+    /* Before event, was Active or Detached;
+     * is now Active or Detached except that ssd->mid is Idle */
 {
-    pid_t got;
-    int status;
-
-    if (!for_spawn) return 0;
+    EGC_GC;
+    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
+    libxl__spawn_state *ss = ssd->ss;
 
-    assert(for_spawn->intermediate);
-    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
-    if (!got) return 0;
-
-    assert(got == for_spawn->intermediate);
-    report_spawn_intermediate_status(gc, for_spawn, status);
+    if (!WIFEXITED(status)) {
+        const char *what =
+            GCSPRINTF("%s intermediate process (startup monitor)",
+                      ss ? ss->what : "(detached)");
+        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+        libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
+    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        if (!status)
+            LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
+                " when we were waiting for it to confirm startup",
+                ss->what, (unsigned long)pid);
+        else if (status <= 127)
+            LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d",
+                ss->what, (unsigned long)pid, status);
+        else if (status < 255) {
+            int sig = status - 128;
+            const char *str = strsignal(sig);
+            if (str)
+                LOG(ERROR, "%s [%ld]: died during startup due to fatal"
+                    " signal %s", ss->what, (unsigned long)pid, str);
+            else
+                LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
+                    " signal number %d", ss->what, (unsigned long)pid, sig);
+        }
+        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
+        spawn_failed(egc, ss); /* must be last use of ss */
+    }
+    free(ssd);
+}
 
-    for_spawn->intermediate = 0;
-    return ERROR_FAIL;
+void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    spawn_cleanup(gc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ae71f70..5bab4d6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -840,75 +840,197 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                                       libxl_device_pci *pcidev, int num);
 _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
 
-/* xl_exec */
+/*
+ *----- spawn -----
+ *
+ * Higher-level double-fork and separate detach eg as for device models
+ *
+ * Each libxl__spawn_state is in one of the conventional states
+ *    Undefined, Idle, Active
+ */
 
- /* higher-level double-fork and separate detach eg as for device models */
+typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
+/* this type is never defined, so no objects of this type exist
+ * fixme-ao  This should go away completely.  */
 
-typedef struct {
-    /* put this in your own status structure as returned to application */
-    /* all fields are private to libxl_spawn_... */
-    pid_t intermediate;
-    int fd;
-    char *what; /* malloc'd in spawn_spawn */
-} libxl__spawn_starting;
+typedef struct libxl__spawn_state libxl__spawn_state;
 
-typedef struct {
-    char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */
-    const char *pid_path; /* only for libxl_spawner_record_pid */
-    int domid;
-    libxl__spawn_starting *for_spawn;
-} libxl__spawner_starting;
+/* Clears out a spawn state; idempotent. */
+_hidden void libxl__spawn_init(libxl__spawn_state*);
 
 /*
- * libxl__spawn_spawn - Create a new process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * what: string describing the spawned process
- * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
- * hook_data: data to pass to the hook function
+ * libxl__spawn_spawn - Create a new process which will become daemonic
+ * Forks twice, to allow the child to detach entirely from the parent.
+ *
+ * We call the two generated processes the "middle child" (result of
+ * the first fork) and the "inner child" (result of the second fork
+ * which takes place in the middle child).
+ *
+ * The inner child must soon exit or exec.  If must also soon exit or
+ * notify the parent of its successful startup by writing to the
+ * xenstore path xspath (or by other means).  xspath may be 0 to
+ * indicate that only other means are being used.
+ *
+ * The user (in the parent) will be called back (confirm_cb) every
+ * time that xenstore path is modified.
+ *
+ * In both children, the ctx is not fully useable: gc and logging
+ * operations are OK, but operations on Xen and xenstore are not.
+ * (The restrictions are the same as those which apply to children
+ * made with libxl__ev_child_fork.)
+ *
+ * midproc_cb will be called in the middle child, with the pid of the
+ * inner child; this could for example record the pid.  midproc_cb
+ * should be fast, and should return.  It will be called (reentrantly)
+ * within libxl__spawn_init.
+ *
+ * failure_cb will be called in the parent on failure of the
+ * intermediate or final child; an error message will have been
+ * logged.
+ *
+ * confirm_cb and failure_cb will not be called reentrantly from
+ * within libxl__spawn_spawn.
+ *
+ * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
- *  < 0   error, for_spawn need not be detached
- *   +1   caller is the parent, must call detach on *for_spawn eventually
+ *  < 0   error, *spawn is now Idle and need not be detached
+ *   +1   caller is the parent, *spawn is Active and must eventually be detached
  *    0   caller is now the inner child, should probably call libxl__exec
- * Caller, may pass 0 for for_spawn, in which case no need to detach.
+ *
+ * The spawn state must be Undefined or Idle on entry.
  */
-_hidden int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
-                      void *hook_data);
+_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl_spawner_record_pid - Record given pid in xenstore
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * innerchild: pid of the child
+ * libxl__spawn_detach - Detaches the daemonic child.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, failures of either child are no
+ * longer repaorted via failure_cb.
+ *
+ * If called before the inner child has been created, this may prevent
+ * it from running at all.  Thus this should be called only when the
+ * inner child has notified that it is ready.  Normally it will be
+ * called from within confirm_cb.
  *
- * This function is passed as intermediate_hook to libxl__spawn_spawn.
+ * Logs errors.
+ *
+ * The spawn state must be Active or Idle on entry and will be Idle
+ * on return.
  */
-_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild);
+_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
- * libxl__spawn_confirm_offspring_startup - Wait for child state
- * gc: allocation pool
- * timeout: how many seconds to wait for the child
- * what: string describing the spawned process
- * path: path to the state file in xenstore
- * state: expected string to wait for in path (optional)
- * starting: malloc'd pointer to libxl__spawner_starting
+ * If successful, this should return 0.
  *
- * Returns 0 on success, and < 0 on error.
+ * Otherwise it should return a signal number, which will be
+ * sent to the inner child; the overall spawn will then fail.
+ */
+typedef int /* signal number */
+libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner);
+
+/*
+ * Called if the spawn failed.  The reason will have been logged.
+ * The spawn state will be Idle on entry to the callback (and
+ * it may be reused immediately if desired).
+ */
+typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
+
+/*
+ * Called when the xspath watch triggers.  xspath will have been read
+ * and the result placed in xsdata; if that failed because the key
+ * didn't exist, xspath==0.  (If it failed for some other reason,
+ * the spawn machinery calls failure_cb instead.)
  *
- * This function waits the given timeout for the given path to appear
- * in xenstore, and optionally for state in path.
- * The intermediate process created in libxl__spawn_spawn is killed.
- * The memory referenced by starting->for_spawn and starting is free'd.
+ * If the child has indicated its successful startup, or a failure
+ * has occurred, this should call libxl__spawn_detach.
+ *
+ * If the child is still starting up, should simply return, doing
+ * nothing.
+ *
+ * The spawn state will be Active on entry to the callback; there
+ * are no restrictions on the state on return; it may even have
+ * been detached and reused.
+ */
+typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
+                                     const char *xsdata);
+
+typedef struct {
+    /* Private to the spawn implementation.
+     */
+    /* This separate struct, from malloc, allows us to "detach"
+     * the child and reap it later, when our user has gone
+     * away and freed its libxl__spawn_state */
+    struct libxl__spawn_state *ss;
+    libxl__ev_child mid;
+} libxl__spawn_state_detachable;
+
+struct libxl__spawn_state {
+    /* must be filled in by user and remain valid */
+    libxl__ao *ao;
+    const char *what;
+    const char *xspath;
+    const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */
+    int timeout_ms; /* -1 means forever */
+    libxl__spawn_midproc_cb *midproc_cb;
+    libxl__spawn_failure_cb *failure_cb;
+    libxl__spawn_confirm_cb *confirm_cb;
+
+    /* remaining fields are private to libxl_spawn_... */
+    libxl__ev_time timeout;
+    libxl__ev_xswatch xswatch;
+    libxl__spawn_state_detachable *ssd;
+};
+
+static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
+    { return !!ss->ssd; }
+
+/*
+ * libxl_spawner_record_pid - Record given pid in xenstore
+ *
+ * This function can be passed directly as an intermediate_hook to
+ * libxl__spawn_spawn.  On failure, returns the value SIGTERM.
  */
-_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting);
+_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
+                                    pid_t innerchild);
+
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdoms. */
+
+typedef struct {
+    /* mixed - user must fill in public parts only: */
+    libxl__dm_spawn_state stubdom; /* will always remain the first member */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->stubdom,) */
+    /* private to libxl__spawn_stubdom: */
+    libxl_domain_config stubdom_config;
+    libxl__domain_build_state stubdom_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stubdom_spawn_state;
+
+_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
+
 
 /*
  * libxl__wait_for_offspring - Wait for child state
@@ -941,31 +1063,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
                                                        void *userdata),
                                  void *check_callback_userdata);
 
-/*
- * libxl__spawn_detach - Kill intermediate process from spawn_spawn
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors.  Idempotent, but only permitted after successful
- * call to libxl__spawn_spawn, and no point calling it again if it fails.
- */
-_hidden int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
-
-/*
- * libxl__spawn_check - Check intermediate child process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors but also returns them.
- * Caller must still call detach.
- */
-_hidden int libxl__spawn_check(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
@@ -984,15 +1081,6 @@ _hidden int libxl__domain_build(libxl__gc *gc,
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
-_hidden int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
-_hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1000,10 +1088,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
   /* Caller must either: pass starting_r==0, or on successful
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
-_hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting *starting);
-_hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,
                                 uint32_t domid, char *state,
                                 libxl__spawn_starting *spawning,
@@ -1566,6 +1650,32 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
 
+/*----- Domain creation -----*/
+
+typedef struct libxl__domain_create_state libxl__domain_create_state;
+
+typedef void libxl__domain_create_cb(libxl__egc *egc,
+                                     libxl__domain_create_state*,
+                                     int rc, uint32_t domid);
+
+struct libxl__domain_create_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl_domain_config *guest_config;
+    int restore_fd;
+    libxl_console_ready console_cb;
+    void *console_cb_priv;
+    libxl__domain_create_cb *callback;
+    /* private to domain_create */
+    int guest_domid;
+    libxl__domain_build_state build_state;
+    union {
+        libxl__dm_spawn_state dmss;
+        libxl__stubdom_spawn_state sdss;
+    };
+};
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..9e66536 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1668,8 +1668,8 @@ start:
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                            cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                          cb, &child_console_pid,
+                                          &domid, restore_fd, 0);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1677,7 +1677,7 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                      cb, &child_console_pid, &domid, 0);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ2-00064j-8O; Fri, 13 Apr 2012 18:40:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062q-0A
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.143.99:65374] by server-3.bemta-4.messagelabs.com id
	45/D2-05853-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QQ-DD; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002i8-AY;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:59 +0100
Message-ID: <1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index abc38fb..3996824 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..1a4874c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) goto out;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ2-00064j-8O; Fri, 13 Apr 2012 18:40:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ0-00062q-0A
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:24 +0000
Received: from [85.158.143.99:65374] by server-3.bemta-4.messagelabs.com id
	45/D2-05853-713788F4; Fri, 13 Apr 2012 18:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334342422!12368429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 13 Apr 2012 18:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002QQ-DD; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002i8-AY;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:59 +0100
Message-ID: <1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index abc38fb..3996824 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..1a4874c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) goto out;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ8-0006Au-A5; Fri, 13 Apr 2012 18:40:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ2-00064D-Cv
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:26 +0000
Received: from [85.158.139.83:54024] by server-9.bemta-5.messagelabs.com id
	D7/3E-09826-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334342424!23649508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1968 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPy-0002Qv-0o; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iy-Ui;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:12 +0100
Message-ID: <1334342414-10289-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/20] libxl: provide progress reporting for
	long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used for reporting, during domain creation, that the
console is ready.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   45 +++++++++++++++
 tools/libxl/libxl_event.c    |  122 ++++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |   28 ++++++++++
 3 files changed, 167 insertions(+), 28 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6f59364..1bfe684 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -435,6 +435,51 @@ typedef struct {
     } u;
 } libxl_asyncop_how;
 
+/*
+ * Some more complex asynchronous operations can report intermediate
+ * progress.  How this is to be reported is controlled, for each
+ * function, by a parameter
+ *    libxl_asyncprogress_how *aop_FOO_how;
+ * for each kind of progress FOO supported by that function.  Each
+ * such kind of progress is associated with an event type.
+ *
+ * The function description will document whether, when, and how
+ * many times, the intermediate progress will be reported, and
+ * what the corresponding event type(s) are.
+ *
+ * If aop_FOO_how==NULL, intermediate progress reports are discarded.
+ *
+ * If aop_FOO_how->callback==NULL, intermediate progress reports
+ * generate libxl events which can be obtained from libxl_event_wait
+ * or libxl_event_check.
+ *
+ * If aop_FOO_how->callback!=NULL, libxl will report intermediate
+ * progress by calling callback(ctx, &event, for_callback).
+ *
+ * The rules for these events are otherwise the same as those for
+ * ordinary events.  The reentrancy and threading rules for the
+ * callback are the same as those for ao completion callbacks.
+ *
+ * Note that the callback, if provided, is responsible for freeing
+ * the event.
+ *
+ * If callbacks are requested, they will be made, and returned, before
+ * the long-running libxl operation is considered finished (so if the
+ * long-running libxl operation was invoked with ao_how==NULL then any
+ * callbacks will occur strictly before the long-running operation
+ * returns).  However, the callbacks may occur on any thread.
+ *
+ * In general, otherwise, no promises are made about the relative
+ * order of callbacks in a multithreaded program.  In particular
+ * different callbacks relating to the same long-running operation may
+ * be delivered out of order.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback);
+    libxl_ev_user for_event; /* always used */
+    void *for_callback; /* passed to callback */
+} libxl_asyncprogress_how;
 
 #define LIBXL_VERSION 0
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 1b7495a..f355e3d 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+    libxl__aop_occurred *aop, *aop_tmp;
 
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
 
+    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
+        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
+
+        CTX_LOCK;
+        aop->ao->progress_reports_outstanding--;
+        libxl__ao_complete_check_progress_reports(egc, aop->ao);
+        CTX_UNLOCK;
+
+        free(aop);
+    }
+
     libxl__ao *ao, *ao_tmp;
     LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
                              entry_for_callback, ao_tmp) {
@@ -1285,6 +1298,7 @@ void libxl__ao_abort(libxl__ao *ao)
     assert(ao->magic == LIBXL__AO_MAGIC);
     assert(ao->in_initiator);
     assert(!ao->complete);
+    assert(!ao->progress_reports_outstanding);
     libxl__ao__destroy(CTX, ao);
 }
 
@@ -1295,6 +1309,23 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
     ao->complete = 1;
     ao->rc = rc;
 
+    libxl__ao_complete_check_progress_reports(egc, ao);
+}
+
+void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+{
+    /* We don't consider an ao complete if it has any outstanding
+     * callbacks.  These callbacks might be outstanding on other
+     * threads, queued up in the other threads' egc's.  Those threads
+     * will, after making the callback, take out the lock again,
+     * decrememt progress_reports_outstanding, and call us again.
+     */
+
+    assert(ao->progress_reports_outstanding >= 0);
+
+    if (!ao->complete || ao->progress_reports_outstanding)
+        return;
+
     if (ao->poller) {
         assert(ao->in_initiator);
         if (!ao->constructing)
@@ -1316,34 +1347,6 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
         libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
 }
 
-libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
-                            const libxl_asyncop_how *how)
-{
-    libxl__ao *ao;
-
-    ao = calloc(1, sizeof(*ao));
-    if (!ao) goto out;
-
-    ao->magic = LIBXL__AO_MAGIC;
-    ao->constructing = 1;
-    ao->in_initiator = 1;
-    ao->poller = 0;
-    ao->domid = domid;
-    LIBXL_INIT_GC(ao->gc, ctx);
-
-    if (how) {
-        ao->how = *how;
-    } else {
-        ao->poller = libxl__poller_get(ctx);
-        if (!ao->poller) goto out;
-    }
-    return ao;
-
- out:
-    if (ao) libxl__ao__destroy(ctx, ao);
-    return NULL;
-}
-
 int libxl__ao_inprogress(libxl__ao *ao)
 {
     AO_GC;
@@ -1401,6 +1404,69 @@ int libxl__ao_inprogress(libxl__ao *ao)
 }
 
 
+/* progress reporting */
+
+/* The application indicates a desire to ignore events by passing NULL
+ * for how.  But we want to copy *how.  So we have this dummy function
+ * whose address is stored in callback if the app passed how==NULL. */
+static void dummy_asyncprogress_callback_ignore
+  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
+
+void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                               const libxl_asyncprogress_how *from_app) {
+    if (from_app)
+        *in_state = *from_app;
+    else
+        in_state->callback = dummy_asyncprogress_callback_ignore;
+}
+
+void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+        const libxl_asyncprogress_how *how, libxl_event *ev)
+{
+    ev->for_user = how->for_event;
+    if (how->callback == dummy_asyncprogress_callback_ignore) {
+        /* ignore */
+    } else if (how->callback) {
+        libxl__aop_occurred *aop = libxl__zalloc(0, sizeof(*aop));
+        ao->progress_reports_outstanding++;
+        aop->ao = ao;
+        aop->ev = ev;
+        aop->how = how;
+    } else {
+        libxl__event_occurred(egc, ev);
+    }
+}
+
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how)
+{
+    libxl__ao *ao;
+
+    ao = calloc(1, sizeof(*ao));
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 56c3eec..4e97f5e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -118,6 +118,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
+typedef struct libxl__aop_occurred libxl__aop_occurred;
 
 void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
@@ -372,6 +373,14 @@ struct libxl__egc {
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback;
+};
+
+struct libxl__aop_occurred {
+    LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry;
+    libxl__ao *ao;
+    libxl_event *ev;
+    const libxl_asyncprogress_how *how;
 };
 
 #define LIBXL__AO_MAGIC              0xA0FACE00ul
@@ -380,6 +389,7 @@ struct libxl__egc {
 struct libxl__ao {
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
+    int progress_reports_outstanding;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1369,6 +1379,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
         LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
+        LIBXL_TAILQ_INIT(&(egc).aops_for_callback);     \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1415,6 +1426,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *        pointer to the internal event generation request routines
  *        libxl__evgen_FOO, so that at some point a CALLBACK will be
  *        made when the operation is complete.
+ *      - if the operation provides progress reports, the aop_how(s)
+ *        must be copied into the per-operation structure using
+ *        libxl__ao_progress_gethow.
  *
  * - If initiation is successful, the initiating function needs
  *   to run libxl__ao_inprogress right before unlocking and
@@ -1424,6 +1438,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   call libxl__ao_abort before unlocking and returning whatever
  *   error code is appropriate (AO_ABORT macro).
  *
+ * - If the operation supports progress reports, it may generate
+ *   suitable events with NEW_EVENT and report them with
+ *   libxl__ao_progress_report (with the ctx locked).
+ *
  * - Later, some callback function, whose callback has been requested
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
@@ -1479,8 +1497,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
+/* Can be called at any time.  Use is essential for any aop user. */
+_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                                       const libxl_asyncprogress_how *from_app);
+
+/* Must be called with the ctx locked.  Will fill in ev->for_user,
+ * so caller need not do that. */
+_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+   const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */);
+
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*);
 
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ8-0006Au-A5; Fri, 13 Apr 2012 18:40:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ2-00064D-Cv
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:26 +0000
Received: from [85.158.139.83:54024] by server-9.bemta-5.messagelabs.com id
	D7/3E-09826-913788F4; Fri, 13 Apr 2012 18:40:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334342424!23649508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1968 invoked from network); 13 Apr 2012 18:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPy-0002Qv-0o; Fri, 13 Apr 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002iy-Ui;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:12 +0100
Message-ID: <1334342414-10289-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/20] libxl: provide progress reporting for
	long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used for reporting, during domain creation, that the
console is ready.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   45 +++++++++++++++
 tools/libxl/libxl_event.c    |  122 ++++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |   28 ++++++++++
 3 files changed, 167 insertions(+), 28 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6f59364..1bfe684 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -435,6 +435,51 @@ typedef struct {
     } u;
 } libxl_asyncop_how;
 
+/*
+ * Some more complex asynchronous operations can report intermediate
+ * progress.  How this is to be reported is controlled, for each
+ * function, by a parameter
+ *    libxl_asyncprogress_how *aop_FOO_how;
+ * for each kind of progress FOO supported by that function.  Each
+ * such kind of progress is associated with an event type.
+ *
+ * The function description will document whether, when, and how
+ * many times, the intermediate progress will be reported, and
+ * what the corresponding event type(s) are.
+ *
+ * If aop_FOO_how==NULL, intermediate progress reports are discarded.
+ *
+ * If aop_FOO_how->callback==NULL, intermediate progress reports
+ * generate libxl events which can be obtained from libxl_event_wait
+ * or libxl_event_check.
+ *
+ * If aop_FOO_how->callback!=NULL, libxl will report intermediate
+ * progress by calling callback(ctx, &event, for_callback).
+ *
+ * The rules for these events are otherwise the same as those for
+ * ordinary events.  The reentrancy and threading rules for the
+ * callback are the same as those for ao completion callbacks.
+ *
+ * Note that the callback, if provided, is responsible for freeing
+ * the event.
+ *
+ * If callbacks are requested, they will be made, and returned, before
+ * the long-running libxl operation is considered finished (so if the
+ * long-running libxl operation was invoked with ao_how==NULL then any
+ * callbacks will occur strictly before the long-running operation
+ * returns).  However, the callbacks may occur on any thread.
+ *
+ * In general, otherwise, no promises are made about the relative
+ * order of callbacks in a multithreaded program.  In particular
+ * different callbacks relating to the same long-running operation may
+ * be delivered out of order.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback);
+    libxl_ev_user for_event; /* always used */
+    void *for_callback; /* passed to callback */
+} libxl_asyncprogress_how;
 
 #define LIBXL_VERSION 0
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 1b7495a..f355e3d 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+    libxl__aop_occurred *aop, *aop_tmp;
 
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
 
+    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
+        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
+
+        CTX_LOCK;
+        aop->ao->progress_reports_outstanding--;
+        libxl__ao_complete_check_progress_reports(egc, aop->ao);
+        CTX_UNLOCK;
+
+        free(aop);
+    }
+
     libxl__ao *ao, *ao_tmp;
     LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
                              entry_for_callback, ao_tmp) {
@@ -1285,6 +1298,7 @@ void libxl__ao_abort(libxl__ao *ao)
     assert(ao->magic == LIBXL__AO_MAGIC);
     assert(ao->in_initiator);
     assert(!ao->complete);
+    assert(!ao->progress_reports_outstanding);
     libxl__ao__destroy(CTX, ao);
 }
 
@@ -1295,6 +1309,23 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
     ao->complete = 1;
     ao->rc = rc;
 
+    libxl__ao_complete_check_progress_reports(egc, ao);
+}
+
+void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+{
+    /* We don't consider an ao complete if it has any outstanding
+     * callbacks.  These callbacks might be outstanding on other
+     * threads, queued up in the other threads' egc's.  Those threads
+     * will, after making the callback, take out the lock again,
+     * decrememt progress_reports_outstanding, and call us again.
+     */
+
+    assert(ao->progress_reports_outstanding >= 0);
+
+    if (!ao->complete || ao->progress_reports_outstanding)
+        return;
+
     if (ao->poller) {
         assert(ao->in_initiator);
         if (!ao->constructing)
@@ -1316,34 +1347,6 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
         libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
 }
 
-libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
-                            const libxl_asyncop_how *how)
-{
-    libxl__ao *ao;
-
-    ao = calloc(1, sizeof(*ao));
-    if (!ao) goto out;
-
-    ao->magic = LIBXL__AO_MAGIC;
-    ao->constructing = 1;
-    ao->in_initiator = 1;
-    ao->poller = 0;
-    ao->domid = domid;
-    LIBXL_INIT_GC(ao->gc, ctx);
-
-    if (how) {
-        ao->how = *how;
-    } else {
-        ao->poller = libxl__poller_get(ctx);
-        if (!ao->poller) goto out;
-    }
-    return ao;
-
- out:
-    if (ao) libxl__ao__destroy(ctx, ao);
-    return NULL;
-}
-
 int libxl__ao_inprogress(libxl__ao *ao)
 {
     AO_GC;
@@ -1401,6 +1404,69 @@ int libxl__ao_inprogress(libxl__ao *ao)
 }
 
 
+/* progress reporting */
+
+/* The application indicates a desire to ignore events by passing NULL
+ * for how.  But we want to copy *how.  So we have this dummy function
+ * whose address is stored in callback if the app passed how==NULL. */
+static void dummy_asyncprogress_callback_ignore
+  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
+
+void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                               const libxl_asyncprogress_how *from_app) {
+    if (from_app)
+        *in_state = *from_app;
+    else
+        in_state->callback = dummy_asyncprogress_callback_ignore;
+}
+
+void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+        const libxl_asyncprogress_how *how, libxl_event *ev)
+{
+    ev->for_user = how->for_event;
+    if (how->callback == dummy_asyncprogress_callback_ignore) {
+        /* ignore */
+    } else if (how->callback) {
+        libxl__aop_occurred *aop = libxl__zalloc(0, sizeof(*aop));
+        ao->progress_reports_outstanding++;
+        aop->ao = ao;
+        aop->ev = ev;
+        aop->how = how;
+    } else {
+        libxl__event_occurred(egc, ev);
+    }
+}
+
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how)
+{
+    libxl__ao *ao;
+
+    ao = calloc(1, sizeof(*ao));
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 56c3eec..4e97f5e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -118,6 +118,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
+typedef struct libxl__aop_occurred libxl__aop_occurred;
 
 void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
@@ -372,6 +373,14 @@ struct libxl__egc {
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback;
+};
+
+struct libxl__aop_occurred {
+    LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry;
+    libxl__ao *ao;
+    libxl_event *ev;
+    const libxl_asyncprogress_how *how;
 };
 
 #define LIBXL__AO_MAGIC              0xA0FACE00ul
@@ -380,6 +389,7 @@ struct libxl__egc {
 struct libxl__ao {
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
+    int progress_reports_outstanding;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1369,6 +1379,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
         LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
+        LIBXL_TAILQ_INIT(&(egc).aops_for_callback);     \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1415,6 +1426,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *        pointer to the internal event generation request routines
  *        libxl__evgen_FOO, so that at some point a CALLBACK will be
  *        made when the operation is complete.
+ *      - if the operation provides progress reports, the aop_how(s)
+ *        must be copied into the per-operation structure using
+ *        libxl__ao_progress_gethow.
  *
  * - If initiation is successful, the initiating function needs
  *   to run libxl__ao_inprogress right before unlocking and
@@ -1424,6 +1438,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   call libxl__ao_abort before unlocking and returning whatever
  *   error code is appropriate (AO_ABORT macro).
  *
+ * - If the operation supports progress reports, it may generate
+ *   suitable events with NEW_EVENT and report them with
+ *   libxl__ao_progress_report (with the ctx locked).
+ *
  * - Later, some callback function, whose callback has been requested
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
@@ -1479,8 +1497,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
+/* Can be called at any time.  Use is essential for any aop user. */
+_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                                       const libxl_asyncprogress_how *from_app);
+
+/* Must be called with the ctx locked.  Will fill in ev->for_user,
+ * so caller need not do that. */
+_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+   const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */);
+
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*);
 
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ7-00069F-4X; Fri, 13 Apr 2012 18:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00063o-NR
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.138.51:7936] by server-12.bemta-3.messagelabs.com id
	AA/EE-29760-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20756 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qg-Mz; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002ia-L5;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:06 +0100
Message-ID: <1334342414-10289-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/20] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 023de6e..9b30544 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -117,6 +117,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 6cccb6c..eaec46a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -234,6 +234,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -256,6 +260,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -268,6 +274,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -305,6 +327,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
     return;
 
  out:
+    free(logfile_tmp);
     assert(rc);
     bootloader_callback(egc, bl, rc);
 }
@@ -462,6 +485,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b3f84ba..4cfb8d5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1488,6 +1488,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1550,7 +1551,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQ7-00069F-4X; Fri, 13 Apr 2012 18:40:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlQ1-00063o-NR
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:25 +0000
Received: from [85.158.138.51:7936] by server-12.bemta-3.messagelabs.com id
	AA/EE-29760-813788F4; Fri, 13 Apr 2012 18:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20756 invoked from network); 13 Apr 2012 18:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPx-0002Qg-Mz; Fri, 13 Apr 2012 18:40:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPx-0002ia-L5;
	Fri, 13 Apr 2012 19:40:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:40:06 +0100
Message-ID: <1334342414-10289-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/20] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 023de6e..9b30544 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -117,6 +117,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 6cccb6c..eaec46a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -234,6 +234,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -256,6 +260,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -268,6 +274,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -305,6 +327,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
     return;
 
  out:
+    free(logfile_tmp);
     assert(rc);
     bootloader_callback(egc, bl, rc);
 }
@@ -462,6 +485,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b3f84ba..4cfb8d5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1488,6 +1488,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1550,7 +1551,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlPz-00062y-Tn; Fri, 13 Apr 2012 18:40:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlPy-00062Z-Qd
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:23 +0000
Received: from [85.158.138.51:7774] by server-3.bemta-3.messagelabs.com id
	B7/F9-04048-613788F4; Fri, 13 Apr 2012 18:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20336 invoked from network); 13 Apr 2012 18:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPw-0002Q5-Iw; Fri, 13 Apr 2012 18:40:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPw-0002hk-Hr;
	Fri, 13 Apr 2012 19:40:20 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:54 +0100
Message-ID: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v6 00/20] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have not tested the tip of this series.  Up to 12/20 have been
tested, in an earlier version.

Changes since v4 include:
 - all comments addressed as described in emails on the list
 - new patches to convert device model spawning, domain
   creation, and console connect callback, to use event model
 - possibly, some bugfixes

At the end of this series I think there are no more impermissible
users of fork (or libxl_fork) in libxl.  xl stilll uses libxl_fork,
about which something should be done.

Tested and previously-posted (these were 20-31/31 from v4):
 01/20 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
 02/20 libxl: support multiple libxl__ev_fds for the same fd
 03/20 libxl: event API: new facilities for waiting for subprocesses
 04/20 autoconf: New test for openpty et al.
 05/20 libxl: provide libxl__remove_file et al.
 06/20 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
 07/20 libxl: Clean up setdefault in do_domain_create
 08/20 libxl: provide libxl__datacopier_*
 09/20 libxl: provide libxl__openpty_*
 10/20 libxl: ao: Convert libxl_run_bootloader
 11/20 libxl: make libxl_create_logfile const-correct
 12/20 libxl: log bootloader output

Preparatory work (new in this version of the series):
 13/20 libxl: Allow AO_GC and EGC_GC even if not used
 14/20 libxl: remove ctx->waitpid_instead
 15/20 libxl: change some structures to unit arrays
 19/20 libxl: remove malloc failure handling from NEW_EVENT

Heavy lifting in domain creation (new in this version of the series):
 16/20 libxl: ao: convert libxl__spawn_*
 17/20 libxl: make libxl_create run bootloader via callback
 18/20 libxl: provide progress reporting for long-running operations
 20/20 libxl: convert console callback to libxl_asyncprogress_how


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlPz-00062y-Tn; Fri, 13 Apr 2012 18:40:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIlPy-00062Z-Qd
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 18:40:23 +0000
Received: from [85.158.138.51:7774] by server-3.bemta-3.messagelabs.com id
	B7/F9-04048-613788F4; Fri, 13 Apr 2012 18:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334342421!14162378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20336 invoked from network); 13 Apr 2012 18:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="11932724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 18:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 19:40:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SIlPw-0002Q5-Iw; Fri, 13 Apr 2012 18:40:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SIlPw-0002hk-Hr;
	Fri, 13 Apr 2012 19:40:20 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 13 Apr 2012 19:39:54 +0100
Message-ID: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v6 00/20] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have not tested the tip of this series.  Up to 12/20 have been
tested, in an earlier version.

Changes since v4 include:
 - all comments addressed as described in emails on the list
 - new patches to convert device model spawning, domain
   creation, and console connect callback, to use event model
 - possibly, some bugfixes

At the end of this series I think there are no more impermissible
users of fork (or libxl_fork) in libxl.  xl stilll uses libxl_fork,
about which something should be done.

Tested and previously-posted (these were 20-31/31 from v4):
 01/20 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
 02/20 libxl: support multiple libxl__ev_fds for the same fd
 03/20 libxl: event API: new facilities for waiting for subprocesses
 04/20 autoconf: New test for openpty et al.
 05/20 libxl: provide libxl__remove_file et al.
 06/20 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
 07/20 libxl: Clean up setdefault in do_domain_create
 08/20 libxl: provide libxl__datacopier_*
 09/20 libxl: provide libxl__openpty_*
 10/20 libxl: ao: Convert libxl_run_bootloader
 11/20 libxl: make libxl_create_logfile const-correct
 12/20 libxl: log bootloader output

Preparatory work (new in this version of the series):
 13/20 libxl: Allow AO_GC and EGC_GC even if not used
 14/20 libxl: remove ctx->waitpid_instead
 15/20 libxl: change some structures to unit arrays
 19/20 libxl: remove malloc failure handling from NEW_EVENT

Heavy lifting in domain creation (new in this version of the series):
 16/20 libxl: ao: convert libxl__spawn_*
 17/20 libxl: make libxl_create run bootloader via callback
 18/20 libxl: provide progress reporting for long-running operations
 20/20 libxl: convert console callback to libxl_asyncprogress_how


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQt-0007FH-Qh; Fri, 13 Apr 2012 18:41:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlQs-0007Cv-74
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:41:18 +0000
Received: from [85.158.139.83:57955] by server-2.bemta-5.messagelabs.com id
	AE/1D-17016-D43788F4; Fri, 13 Apr 2012 18:41:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334342475!23061079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15438 invoked from network); 13 Apr 2012 18:41:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:41:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24148090"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:40:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:40:59 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlQU-0003Mn-1B; Fri, 13 Apr 2012 19:40:54 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 19:45:08 +0100
Message-ID: <1334342708-30987-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen_disk: use bdrv_aio_flush instead of
	bdrv_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |   13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 84ca76e..3e4a47b 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -324,9 +324,6 @@ static void qemu_aio_complete(void *opaque, int ret)
     if (ioreq->aio_inflight > 0) {
         return;
     }
-    if (ioreq->postsync) {
-        bdrv_flush(ioreq->blkdev->bs);
-    }
 
     ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
     ioreq_unmap(ioreq);
@@ -343,9 +340,9 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
         goto err_no_map;
     }
 
-    ioreq->aio_inflight++;
     if (ioreq->presync) {
-        bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
     }
 
     switch (ioreq->req.operation) {
@@ -372,8 +369,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
         /* unknown operation (shouldn't happen -- parse catches this) */
         goto err;
     }
-
-    qemu_aio_complete(ioreq, 0);
+    if (ioreq->postsync) {
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+    }
 
     return 0;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlQt-0007FH-Qh; Fri, 13 Apr 2012 18:41:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SIlQs-0007Cv-74
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:41:18 +0000
Received: from [85.158.139.83:57955] by server-2.bemta-5.messagelabs.com id
	AE/1D-17016-D43788F4; Fri, 13 Apr 2012 18:41:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334342475!23061079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYzNTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15438 invoked from network); 13 Apr 2012 18:41:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 18:41:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,418,1330923600"; d="scan'208";a="24148090"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 14:40:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 14:40:59 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SIlQU-0003Mn-1B; Fri, 13 Apr 2012 19:40:54 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Apr 2012 19:45:08 +0100
Message-ID: <1334342708-30987-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen_disk: use bdrv_aio_flush instead of
	bdrv_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |   13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 84ca76e..3e4a47b 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -324,9 +324,6 @@ static void qemu_aio_complete(void *opaque, int ret)
     if (ioreq->aio_inflight > 0) {
         return;
     }
-    if (ioreq->postsync) {
-        bdrv_flush(ioreq->blkdev->bs);
-    }
 
     ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
     ioreq_unmap(ioreq);
@@ -343,9 +340,9 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
         goto err_no_map;
     }
 
-    ioreq->aio_inflight++;
     if (ioreq->presync) {
-        bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
     }
 
     switch (ioreq->req.operation) {
@@ -372,8 +369,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
         /* unknown operation (shouldn't happen -- parse catches this) */
         goto err;
     }
-
-    qemu_aio_complete(ioreq, 0);
+    if (ioreq->postsync) {
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+    }
 
     return 0;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:50:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:50:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlZN-0000uM-Ts; Fri, 13 Apr 2012 18:50:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIlZM-0000uH-D3
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:50:04 +0000
Received: from [85.158.143.35:63872] by server-2.bemta-4.messagelabs.com id
	9C/94-17550-B55788F4; Fri, 13 Apr 2012 18:50:03 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334343002!13172545!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11546 invoked from network); 13 Apr 2012 18:50:03 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 18:50:03 -0000
Received: from mail57-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 18:50:01 +0000
Received: from mail57-va3 (localhost [127.0.0.1])	by mail57-va3-R.bigfish.com
	(Postfix) with ESMTP id BAE234A05DA;
	Fri, 13 Apr 2012 18:50:01 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dI9371I1432N98dK111aIzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail57-va3 (localhost.localdomain [127.0.0.1]) by mail57-va3
	(MessageSwitch) id 1334342999276453_2582;
	Fri, 13 Apr 2012 18:49:59 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.246])	by
	mail57-va3.bigfish.com (Postfix) with ESMTP id 3D5851A00DA;
	Fri, 13 Apr 2012 18:49:59 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 18:49:58 +0000
X-WSS-ID: 0M2FLN8-01-JT5-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AC66102810B;	Fri, 13 Apr 2012 13:49:55 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 13:50:15 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 13:49:55 -0500
Message-ID: <4F887387.6090005@amd.com>
Date: Fri, 13 Apr 2012 13:42:15 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Gianluca Guida <glguida@gmail.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
	<CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
In-Reply-To: <CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

You can treat my experiments as an ack. But other folks need to ack it too.

-Wei

On 04/13/2012 12:08 PM, Gianluca Guida wrote:
> On Fri, Apr 13, 2012 at 9:29 AM, Huang2, Wei<Wei.Huang2@amd.com>  wrote:
>> I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.
> Yes, that is exactly what I expected to see (WC enabled). Thanks again.
>
> Any change to get this checked in?
> Gianluca
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 18:50:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 18:50:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIlZN-0000uM-Ts; Fri, 13 Apr 2012 18:50:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SIlZM-0000uH-D3
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 18:50:04 +0000
Received: from [85.158.143.35:63872] by server-2.bemta-4.messagelabs.com id
	9C/94-17550-B55788F4; Fri, 13 Apr 2012 18:50:03 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334343002!13172545!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11546 invoked from network); 13 Apr 2012 18:50:03 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Apr 2012 18:50:03 -0000
Received: from mail57-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 18:50:01 +0000
Received: from mail57-va3 (localhost [127.0.0.1])	by mail57-va3-R.bigfish.com
	(Postfix) with ESMTP id BAE234A05DA;
	Fri, 13 Apr 2012 18:50:01 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dI9371I1432N98dK111aIzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail57-va3 (localhost.localdomain [127.0.0.1]) by mail57-va3
	(MessageSwitch) id 1334342999276453_2582;
	Fri, 13 Apr 2012 18:49:59 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.246])	by
	mail57-va3.bigfish.com (Postfix) with ESMTP id 3D5851A00DA;
	Fri, 13 Apr 2012 18:49:59 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.23; Fri, 13 Apr 2012 18:49:58 +0000
X-WSS-ID: 0M2FLN8-01-JT5-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AC66102810B;	Fri, 13 Apr 2012 13:49:55 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 13 Apr 2012 13:50:15 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Apr 2012 13:49:55 -0500
Message-ID: <4F887387.6090005@amd.com>
Date: Fri, 13 Apr 2012 13:42:15 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Gianluca Guida <glguida@gmail.com>
References: <CAKpvNa2wr3WUTEYuX9f5nKXGAEbxFxH1fgScS3z9iaCZ4Jdovg@mail.gmail.com>
	<4F8672E3.80302@amd.com>
	<CAKpvNa2XqnzGW=8y3G0q5GewVJQdmAYzrh_0TmEuN3eNOUYdsA@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD84D@sausexdag02.amd.com>
	<CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
In-Reply-To: <CAKpvNa0ULcPgu1+=kXU1Y7HQbiHjn1Hf4kJvXRx2jbCU1M9z+Q@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore of guest PAT table in HAP
 paging mode.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

You can treat my experiments as an ack. But other folks need to ack it too.

-Wei

On 04/13/2012 12:08 PM, Gianluca Guida wrote:
> On Fri, Apr 13, 2012 at 9:29 AM, Huang2, Wei<Wei.Huang2@amd.com>  wrote:
>> I tested it with SLES11 SP1 and Windows 7 guest VM. With nested paging enabled, I saw XEN saved 0x0007010600070106ULL, instead of default 0x0007040600070406ULL, to guest disk files. So it behaved as expected.
> Yes, that is exactly what I expected to see (WC enabled). Thanks again.
>
> Any change to get this checked in?
> Gianluca
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 19:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 19:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SImRd-00021i-UW; Fri, 13 Apr 2012 19:46:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SImRb-00021a-SA
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 19:46:08 +0000
Received: from [85.158.143.35:45488] by server-3.bemta-4.messagelabs.com id
	51/99-05853-F72888F4; Fri, 13 Apr 2012 19:46:07 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334346364!16042937!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0OTI4Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25928 invoked from network); 13 Apr 2012 19:46:06 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Apr 2012 19:46:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3DJjRL3020942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Apr 2012 19:45:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3DJjQEH022783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Apr 2012 19:45:27 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3DJjQXq031631; Fri, 13 Apr 2012 14:45:26 -0500
MIME-Version: 1.0
Message-ID: <7bd96bdf-f7ab-450e-98e6-85fa273a5d28@default>
Date: Fri, 13 Apr 2012 12:45:20 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
	<20360.961.392060.587905@mariner.uk.xensource.com>
In-Reply-To: <20360.961.392060.587905@mariner.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F888259.0053,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Subject: RE: [Xen-devel] Xen 4.2 Release Plan / TODO
> 
> Dan Magenheimer writes ("RE: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> > After reading libxl.h, I'm not absolutely positive I understand
> > all the conditions that would cause you to label a function as
> > "slow" but I believe all the libxl_tmem_* functions are "fast".
> 
> There are a few operations that make a function necessarily have to be
> slow in the libxl api sense.  These are: xenstore watches; spawning
> subprocesses; anything with a timeout.
> 
> More broadly any function which is sufficiently slow that a caller
> might reasonably want to initiate it, and then carry on doing
> something else while the function completes.  So this includes any
> operation which a toolstack might want to parallelise.

Got it.  Thanks.  This is a bit clearer than the comment in libxl.h.

> > All of them are strictly "call the hypervisor, wait for it to
> > return" and none of the hypercalls (actually which are variations of
> > the one tmem hypercall) require a callback to dom0 or to the
> > calling guest... they all complete entirely inside the hypervisor.
> 
> Right, that sounds good.  I guess you also mean that this will always
> be the case.

Yes AFAICT.

> > Libxl_tmem_destroy may take a long time as it has to walk
> > through and free some potentially very large data structures,
> > but it is only used at domain destruction.
> 
> How long a time are we talking about ?  Would it be a scalability or
> performance problem if an entire host's management toolstack had to
> block, and no other management operations could be performed on any
> domain for any reason, while the tmem destroy takes place ?

See previous reply to IanC... this is moot since (I think)
tmem_destroy will go away.

> > Libxl_tmem_list does allocate some memory in userland that the
> > hypercall fills synchronously (with ascii-formatted statistics/counters
> > maintained entirely by the tmem code in the hypervisor).
> 
> Memory allocation in userland is fine.  I guess we're not talking
> about megabytes here.

A reasonable bound would be on the order of 1K per tmem-enabled guest.
The current code in pyxc_tmem_control enforces a 32K buffer limit.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 19:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 19:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SImRd-00021i-UW; Fri, 13 Apr 2012 19:46:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SImRb-00021a-SA
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 19:46:08 +0000
Received: from [85.158.143.35:45488] by server-3.bemta-4.messagelabs.com id
	51/99-05853-F72888F4; Fri, 13 Apr 2012 19:46:07 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334346364!16042937!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0OTI4Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25928 invoked from network); 13 Apr 2012 19:46:06 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Apr 2012 19:46:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3DJjRL3020942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Apr 2012 19:45:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3DJjQEH022783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Apr 2012 19:45:27 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3DJjQXq031631; Fri, 13 Apr 2012 14:45:26 -0500
MIME-Version: 1.0
Message-ID: <7bd96bdf-f7ab-450e-98e6-85fa273a5d28@default>
Date: Fri, 13 Apr 2012 12:45:20 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
	<20360.961.392060.587905@mariner.uk.xensource.com>
In-Reply-To: <20360.961.392060.587905@mariner.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F888259.0053,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Subject: RE: [Xen-devel] Xen 4.2 Release Plan / TODO
> 
> Dan Magenheimer writes ("RE: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> > After reading libxl.h, I'm not absolutely positive I understand
> > all the conditions that would cause you to label a function as
> > "slow" but I believe all the libxl_tmem_* functions are "fast".
> 
> There are a few operations that make a function necessarily have to be
> slow in the libxl api sense.  These are: xenstore watches; spawning
> subprocesses; anything with a timeout.
> 
> More broadly any function which is sufficiently slow that a caller
> might reasonably want to initiate it, and then carry on doing
> something else while the function completes.  So this includes any
> operation which a toolstack might want to parallelise.

Got it.  Thanks.  This is a bit clearer than the comment in libxl.h.

> > All of them are strictly "call the hypervisor, wait for it to
> > return" and none of the hypercalls (actually which are variations of
> > the one tmem hypercall) require a callback to dom0 or to the
> > calling guest... they all complete entirely inside the hypervisor.
> 
> Right, that sounds good.  I guess you also mean that this will always
> be the case.

Yes AFAICT.

> > Libxl_tmem_destroy may take a long time as it has to walk
> > through and free some potentially very large data structures,
> > but it is only used at domain destruction.
> 
> How long a time are we talking about ?  Would it be a scalability or
> performance problem if an entire host's management toolstack had to
> block, and no other management operations could be performed on any
> domain for any reason, while the tmem destroy takes place ?

See previous reply to IanC... this is moot since (I think)
tmem_destroy will go away.

> > Libxl_tmem_list does allocate some memory in userland that the
> > hypercall fills synchronously (with ascii-formatted statistics/counters
> > maintained entirely by the tmem code in the hypervisor).
> 
> Memory allocation in userland is fine.  I guess we're not talking
> about megabytes here.

A reasonable bound would be on the order of 1K per tmem-enabled guest.
The current code in pyxc_tmem_control enforces a 32K buffer limit.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 20:13:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 20:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SImrw-0002rX-Qy; Fri, 13 Apr 2012 20:13:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SImrv-0002rS-EL
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 20:13:19 +0000
Received: from [85.158.143.99:60522] by server-3.bemta-4.messagelabs.com id
	F6/94-05853-ED8888F4; Fri, 13 Apr 2012 20:13:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334347997!13932175!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10153 invoked from network); 13 Apr 2012 20:13:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 20:13:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,419,1330905600"; d="scan'208";a="11933275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 20:13:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 21:13:16 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SImrs-000356-2z;
	Fri, 13 Apr 2012 20:13:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SImrr-0006ol-Uf;
	Fri, 13 Apr 2012 21:13:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12677-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 21:13:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12677: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12677 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12677/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                4166fb64593514ad920b7dbd290e0a934b37d24a
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 20:13:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 20:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SImrw-0002rX-Qy; Fri, 13 Apr 2012 20:13:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SImrv-0002rS-EL
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 20:13:19 +0000
Received: from [85.158.143.99:60522] by server-3.bemta-4.messagelabs.com id
	F6/94-05853-ED8888F4; Fri, 13 Apr 2012 20:13:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334347997!13932175!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10153 invoked from network); 13 Apr 2012 20:13:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 20:13:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,419,1330905600"; d="scan'208";a="11933275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 20:13:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Apr 2012 21:13:16 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SImrs-000356-2z;
	Fri, 13 Apr 2012 20:13:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SImrr-0006ol-Uf;
	Fri, 13 Apr 2012 21:13:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12677-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Apr 2012 21:13:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12677: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12677 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12677/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                4166fb64593514ad920b7dbd290e0a934b37d24a
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 21:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 21:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SInno-0003Ct-Bu; Fri, 13 Apr 2012 21:13:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SInnm-0003Co-OP
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 21:13:07 +0000
Received: from [85.158.139.83:21654] by server-8.bemta-5.messagelabs.com id
	3C/36-26964-1E6988F4; Fri, 13 Apr 2012 21:13:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334351584!23751403!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjUxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23881 invoked from network); 13 Apr 2012 21:13:05 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 21:13:05 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id CB4CF5EC07E;
	Fri, 13 Apr 2012 14:13:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=mJ93mKUKQMr+f5UjkI2P7g
	5Tj1spQpFWCiMKitoYvac7T9et8DRN6KhwsniEWBzQEIKf/21ELWCH2S2GDnb5vL
	872Iyhs1np6oAnsr4RYtCIPKuIaezV4Pyb1IuJkBPGrT/y1ejCs+cfjLUFDUcYd3
	HxG1MZN2xD7v1TXU0PHzg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=E3F9UTr5wc7e
	Mg6UHWNq/Djm8C4=; b=nBIQlTQP51FJ4Tln1GlON1gxcBOjG4IEz8KrYYwb3D7f
	b7oxXkEuqD4X3PlOZ/lcqhRUUOHIGoXcFteaOMus0Twj8o342E2wkDKaIhjfAiX7
	n1aiVmH+uAum7E12abb1O1LJ9OBwnadeQfBnuw8/++eacU790OLfGbqctodFCXg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 597515EC07C; 
	Fri, 13 Apr 2012 14:13:03 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 15a3c740419f53702b0c869dc298ad0fd429af9c
Message-Id: <15a3c740419f53702b0c.1334351886@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 17:18:06 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Fix locking on hap enable failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/hap/hap.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


If enabling hap fails due to out of memory, the locking on the clean up path is
broken.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8ec52231c03d -r 15a3c740419f xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -585,13 +585,14 @@ int hap_enable(struct domain *d, u32 mod
         unsigned int r;
         paging_lock(d);
         r = hap_set_allocation(d, 256, NULL);
-        paging_unlock(d);
         if ( r != 0 )
         {
             hap_set_allocation(d, 0, NULL);
+            paging_unlock(d);
             rv = -ENOMEM;
             goto out;
         }
+        paging_unlock(d);
     }
 
     /* Allow p2m and log-dirty code to borrow our memory */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 21:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 21:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SInno-0003Ct-Bu; Fri, 13 Apr 2012 21:13:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SInnm-0003Co-OP
	for xen-devel@lists.xen.org; Fri, 13 Apr 2012 21:13:07 +0000
Received: from [85.158.139.83:21654] by server-8.bemta-5.messagelabs.com id
	3C/36-26964-1E6988F4; Fri, 13 Apr 2012 21:13:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334351584!23751403!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjUxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23881 invoked from network); 13 Apr 2012 21:13:05 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-182.messagelabs.com with SMTP;
	13 Apr 2012 21:13:05 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id CB4CF5EC07E;
	Fri, 13 Apr 2012 14:13:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=mJ93mKUKQMr+f5UjkI2P7g
	5Tj1spQpFWCiMKitoYvac7T9et8DRN6KhwsniEWBzQEIKf/21ELWCH2S2GDnb5vL
	872Iyhs1np6oAnsr4RYtCIPKuIaezV4Pyb1IuJkBPGrT/y1ejCs+cfjLUFDUcYd3
	HxG1MZN2xD7v1TXU0PHzg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=E3F9UTr5wc7e
	Mg6UHWNq/Djm8C4=; b=nBIQlTQP51FJ4Tln1GlON1gxcBOjG4IEz8KrYYwb3D7f
	b7oxXkEuqD4X3PlOZ/lcqhRUUOHIGoXcFteaOMus0Twj8o342E2wkDKaIhjfAiX7
	n1aiVmH+uAum7E12abb1O1LJ9OBwnadeQfBnuw8/++eacU790OLfGbqctodFCXg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 597515EC07C; 
	Fri, 13 Apr 2012 14:13:03 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 15a3c740419f53702b0c869dc298ad0fd429af9c
Message-Id: <15a3c740419f53702b0c.1334351886@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Apr 2012 17:18:06 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Fix locking on hap enable failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/hap/hap.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


If enabling hap fails due to out of memory, the locking on the clean up path is
broken.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8ec52231c03d -r 15a3c740419f xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -585,13 +585,14 @@ int hap_enable(struct domain *d, u32 mod
         unsigned int r;
         paging_lock(d);
         r = hap_set_allocation(d, 256, NULL);
-        paging_unlock(d);
         if ( r != 0 )
         {
             hap_set_allocation(d, 0, NULL);
+            paging_unlock(d);
             rv = -ENOMEM;
             goto out;
         }
+        paging_unlock(d);
     }
 
     /* Allow p2m and log-dirty code to borrow our memory */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 23:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 23:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIqFo-0003pJ-0q; Fri, 13 Apr 2012 23:50:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIqFl-0003pE-Dr
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 23:50:09 +0000
Received: from [85.158.139.83:10295] by server-12.bemta-5.messagelabs.com id
	67/D9-05587-0BBB88F4; Fri, 13 Apr 2012 23:50:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334361007!23079915!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31210 invoked from network); 13 Apr 2012 23:50:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 23:50:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,420,1330905600"; d="scan'208";a="11934272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 23:50:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 00:50:06 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIqFi-0004Uz-A3;
	Fri, 13 Apr 2012 23:50:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIqFi-0003GT-6k;
	Sat, 14 Apr 2012 00:50:06 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12678-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 00:50:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12678: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12678 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12678/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857
baseline version:
 linux                e63089b08140adea85d011da136c7b56d73296ee

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-mingo-tip-master
+ revision=d935d0f77650fea53986811ca8a2f8c726fd9857
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-mingo-tip-master d935d0f77650fea53986811ca8a2f8c726fd9857
+ branch=linux-mingo-tip-master
+ revision=d935d0f77650fea53986811ca8a2f8c726fd9857
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-mingo-tip-master
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-mingo-tip-master
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-mingo-tip-master
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-mingo-tip-master
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
+ : -f
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-mingo-tip-master
+ : tested/linux-mingo-tip-master
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push -f xen@xenbits.xensource.com:git/linux-pvops.git d935d0f77650fea53986811ca8a2f8c726fd9857:tested/linux-mingo-tip-master
Counting objects: 1   
Counting objects: 306   
Counting objects: 399, done.
Compressing objects:   1% (1/57)   
Compressing objects:   3% (2/57)   
Compressing objects:   5% (3/57)   
Compressing objects:   7% (4/57)   
Compressing objects:   8% (5/57)   
Compressing objects:  10% (6/57)   
Compressing objects:  12% (7/57)   
Compressing objects:  14% (8/57)   
Compressing objects:  15% (9/57)   
Compressing objects:  17% (10/57)   
Compressing objects:  19% (11/57)   
Compressing objects:  21% (12/57)   
Compressing objects:  22% (13/57)   
Compressing objects:  24% (14/57)   
Compressing objects:  26% (15/57)   
Compressing objects:  28% (16/57)   
Compressing objects:  29% (17/57)   
Compressing objects:  31% (18/57)   
Compressing objects:  33% (19/57)   
Compressing objects:  35% (20/57)   
Compressing objects:  36% (21/57)   
Compressing objects:  38% (22/57)   
Compressing objects:  40% (23/57)   
Compressing objects:  42% (24/57)   
Compressing objects:  43% (25/57)   
Compressing objects:  45% (26/57)   
Compressing objects:  47% (27/57)   
Compressing objects:  49% (28/57)   
Compressing objects:  50% (29/57)   
Compressing objects:  52% (30/57)   
Compressing objects:  54% (31/57)   
Compressing objects:  56% (32/57)   
Compressing objects:  57% (33/57)   
Compressing objects:  59% (34/57)   
Compressing objects:  61% (35/57)   
Compressing objects:  63% (36/57)   
Compressing objects:  64% (37/57)   
Compressing objects:  66% (38/57)   
Compressing objects:  68% (39/57)   
Compressing objects:  70% (40/57)   
Compressing objects:  71% (41/57)   
Compressing objects:  73% (42/57)   
Compressing objects:  75% (43/57)   
Compressing objects:  77% (44/57)   
Compressing objects:  78% (45/57)   
Compressing objects:  80% (46/57)   
Compressing objects:  82% (47/57)   
Compressing objects:  84% (48/57)   
Compressing objects:  85% (49/57)   
Compressing objects:  87% (50/57)   
Compressing objects:  89% (51/57)   
Compressing objects:  91% (52/57)   
Compressing objects:  92% (53/57)   
Compressing objects:  94% (54/57)   
Compressing objects:  96% (55/57)   
Compressing objects:  98% (56/57)   
Compressing objects: 100% (57/57)   
Compressing objects: 100% (57/57), done.
Writing objects:   0% (1/208)   
Writing objects:   1% (3/208)   
Writing objects:   2% (5/208)   
Writing objects:   3% (7/208)   
Writing objects:   4% (9/208)   
Writing objects:   5% (11/208)   
Writing objects:   6% (13/208)   
Writing objects:   7% (15/208)   
Writing objects:   8% (17/208)   
Writing objects:   9% (19/208)   
Writing objects:  10% (21/208)   
Writing objects:  11% (23/208)   
Writing objects:  12% (25/208)   
Writing objects:  13% (28/208)   
Writing objects:  14% (30/208)   
Writing objects:  15% (32/208)   
Writing objects:  16% (34/208)   
Writing objects:  17% (36/208)   
Writing objects:  18% (38/208)   
Writing objects:  19% (40/208)   
Writing objects:  20% (42/208)   
Writing objects:  21% (44/208)   
Writing objects:  22% (46/208)   
Writing objects:  23% (48/208)   
Writing objects:  24% (50/208)   
Writing objects:  25% (52/208)   
Writing objects:  26% (55/208)   
Writing objects:  27% (57/208)   
Writing objects:  28% (59/208)   
Writing objects:  29% (61/208)   
Writing objects:  30% (63/208)   
Writing objects:  31% (65/208)   
Writing objects:  32% (67/208)   
Writing objects:  33% (69/208)   
Writing objects:  34% (71/208)   
Writing objects:  35% (73/208)   
Writing objects:  36% (75/208)   
Writing objects:  37% (77/208)   
Writing objects:  38% (80/208)   
Writing objects:  39% (82/208)   
Writing objects:  40% (84/208)   
Writing objects:  41% (86/208)   
Writing objects:  42% (88/208)   
Writing objects:  43% (90/208)   
Writing objects:  44% (92/208)   
Writing objects:  45% (94/208)   
Writing objects:  46% (96/208)   
Writing objects:  47% (98/208)   
Writing objects:  48% (100/208)   
Writing objects:  49% (102/208)   
Writing objects:  50% (104/208)   
Writing objects:  51% (107/208)   
Writing objects:  52% (109/208)   
Writing objects:  53% (111/208)   
Writing objects:  54% (113/208)   
Writing objects:  55% (115/208)   
Writing objects:  56% (117/208)   
Writing objects:  57% (119/208)   
Writing objects:  58% (121/208)   
Writing objects:  59% (123/208)   
Writing objects:  60% (125/208)   
Writing objects:  61% (127/208)   
Writing objects:  62% (130/208)   
Writing objects:  63% (132/208)   
Writing objects:  64% (134/208)   
Writing objects:  65% (136/208)   
Writing objects:  66% (138/208)   
Writing objects:  67% (140/208)   
Writing objects:  68% (142/208)   
Writing objects:  69% (144/208)   
Writing objects:  70% (146/208)   
Writing objects:  71% (148/208)   
Writing objects:  72% (150/208)   
Writing objects:  73% (152/208)   
Writing objects:  74% (154/208)   
Writing objects:  75% (156/208)   
Writing objects:  76% (159/208)   
Writing objects:  77% (161/208)   
Writing objects:  78% (163/208)   
Writing objects:  79% (165/208)   
Writing objects:  80% (167/208)   
Writing objects:  81% (169/208)   
Writing objects:  82% (171/208)   
Writing objects:  83% (173/208)   
Writing objects:  84% (175/208)   
Writing objects:  85% (177/208)   
Writing objects:  86% (179/208)   
Writing objects:  87% (181/208)   
Writing objects:  88% (184/208)   
Writing objects:  89% (186/208)   
Writing objects:  90% (188/208)   
Writing objects:  91% (190/208)   
Writing objects:  92% (192/208)   
Writing objects:  93% (194/208)   
Writing objects:  94% (196/208)   
Writing objects:  95% (198/208)   
Writing objects:  96% (200/208)   
Writing objects:  97% (202/208)   
Writing objects:  98% (204/208)   
Writing objects:  99% (206/208)   
Writing objects: 100% (208/208)   
Writing objects: 100% (208/208), 34.08 KiB, done.
Total 208 (delta 171), reused 188 (delta 151)
To xen@xenbits.xensource.com:git/linux-pvops.git
   e63089b..d935d0f  d935d0f77650fea53986811ca8a2f8c726fd9857 -> tested/linux-mingo-tip-master
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 13 23:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Apr 2012 23:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIqFo-0003pJ-0q; Fri, 13 Apr 2012 23:50:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIqFl-0003pE-Dr
	for xen-devel@lists.xensource.com; Fri, 13 Apr 2012 23:50:09 +0000
Received: from [85.158.139.83:10295] by server-12.bemta-5.messagelabs.com id
	67/D9-05587-0BBB88F4; Fri, 13 Apr 2012 23:50:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334361007!23079915!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31210 invoked from network); 13 Apr 2012 23:50:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Apr 2012 23:50:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,420,1330905600"; d="scan'208";a="11934272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Apr 2012 23:50:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 00:50:06 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIqFi-0004Uz-A3;
	Fri, 13 Apr 2012 23:50:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIqFi-0003GT-6k;
	Sat, 14 Apr 2012 00:50:06 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12678-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 00:50:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12678: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12678 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12678/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857
baseline version:
 linux                e63089b08140adea85d011da136c7b56d73296ee

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-mingo-tip-master
+ revision=d935d0f77650fea53986811ca8a2f8c726fd9857
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-mingo-tip-master d935d0f77650fea53986811ca8a2f8c726fd9857
+ branch=linux-mingo-tip-master
+ revision=d935d0f77650fea53986811ca8a2f8c726fd9857
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-mingo-tip-master
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-mingo-tip-master
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-mingo-tip-master
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-mingo-tip-master
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
+ : -f
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-mingo-tip-master
+ : tested/linux-mingo-tip-master
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push -f xen@xenbits.xensource.com:git/linux-pvops.git d935d0f77650fea53986811ca8a2f8c726fd9857:tested/linux-mingo-tip-master
Counting objects: 1   
Counting objects: 306   
Counting objects: 399, done.
Compressing objects:   1% (1/57)   
Compressing objects:   3% (2/57)   
Compressing objects:   5% (3/57)   
Compressing objects:   7% (4/57)   
Compressing objects:   8% (5/57)   
Compressing objects:  10% (6/57)   
Compressing objects:  12% (7/57)   
Compressing objects:  14% (8/57)   
Compressing objects:  15% (9/57)   
Compressing objects:  17% (10/57)   
Compressing objects:  19% (11/57)   
Compressing objects:  21% (12/57)   
Compressing objects:  22% (13/57)   
Compressing objects:  24% (14/57)   
Compressing objects:  26% (15/57)   
Compressing objects:  28% (16/57)   
Compressing objects:  29% (17/57)   
Compressing objects:  31% (18/57)   
Compressing objects:  33% (19/57)   
Compressing objects:  35% (20/57)   
Compressing objects:  36% (21/57)   
Compressing objects:  38% (22/57)   
Compressing objects:  40% (23/57)   
Compressing objects:  42% (24/57)   
Compressing objects:  43% (25/57)   
Compressing objects:  45% (26/57)   
Compressing objects:  47% (27/57)   
Compressing objects:  49% (28/57)   
Compressing objects:  50% (29/57)   
Compressing objects:  52% (30/57)   
Compressing objects:  54% (31/57)   
Compressing objects:  56% (32/57)   
Compressing objects:  57% (33/57)   
Compressing objects:  59% (34/57)   
Compressing objects:  61% (35/57)   
Compressing objects:  63% (36/57)   
Compressing objects:  64% (37/57)   
Compressing objects:  66% (38/57)   
Compressing objects:  68% (39/57)   
Compressing objects:  70% (40/57)   
Compressing objects:  71% (41/57)   
Compressing objects:  73% (42/57)   
Compressing objects:  75% (43/57)   
Compressing objects:  77% (44/57)   
Compressing objects:  78% (45/57)   
Compressing objects:  80% (46/57)   
Compressing objects:  82% (47/57)   
Compressing objects:  84% (48/57)   
Compressing objects:  85% (49/57)   
Compressing objects:  87% (50/57)   
Compressing objects:  89% (51/57)   
Compressing objects:  91% (52/57)   
Compressing objects:  92% (53/57)   
Compressing objects:  94% (54/57)   
Compressing objects:  96% (55/57)   
Compressing objects:  98% (56/57)   
Compressing objects: 100% (57/57)   
Compressing objects: 100% (57/57), done.
Writing objects:   0% (1/208)   
Writing objects:   1% (3/208)   
Writing objects:   2% (5/208)   
Writing objects:   3% (7/208)   
Writing objects:   4% (9/208)   
Writing objects:   5% (11/208)   
Writing objects:   6% (13/208)   
Writing objects:   7% (15/208)   
Writing objects:   8% (17/208)   
Writing objects:   9% (19/208)   
Writing objects:  10% (21/208)   
Writing objects:  11% (23/208)   
Writing objects:  12% (25/208)   
Writing objects:  13% (28/208)   
Writing objects:  14% (30/208)   
Writing objects:  15% (32/208)   
Writing objects:  16% (34/208)   
Writing objects:  17% (36/208)   
Writing objects:  18% (38/208)   
Writing objects:  19% (40/208)   
Writing objects:  20% (42/208)   
Writing objects:  21% (44/208)   
Writing objects:  22% (46/208)   
Writing objects:  23% (48/208)   
Writing objects:  24% (50/208)   
Writing objects:  25% (52/208)   
Writing objects:  26% (55/208)   
Writing objects:  27% (57/208)   
Writing objects:  28% (59/208)   
Writing objects:  29% (61/208)   
Writing objects:  30% (63/208)   
Writing objects:  31% (65/208)   
Writing objects:  32% (67/208)   
Writing objects:  33% (69/208)   
Writing objects:  34% (71/208)   
Writing objects:  35% (73/208)   
Writing objects:  36% (75/208)   
Writing objects:  37% (77/208)   
Writing objects:  38% (80/208)   
Writing objects:  39% (82/208)   
Writing objects:  40% (84/208)   
Writing objects:  41% (86/208)   
Writing objects:  42% (88/208)   
Writing objects:  43% (90/208)   
Writing objects:  44% (92/208)   
Writing objects:  45% (94/208)   
Writing objects:  46% (96/208)   
Writing objects:  47% (98/208)   
Writing objects:  48% (100/208)   
Writing objects:  49% (102/208)   
Writing objects:  50% (104/208)   
Writing objects:  51% (107/208)   
Writing objects:  52% (109/208)   
Writing objects:  53% (111/208)   
Writing objects:  54% (113/208)   
Writing objects:  55% (115/208)   
Writing objects:  56% (117/208)   
Writing objects:  57% (119/208)   
Writing objects:  58% (121/208)   
Writing objects:  59% (123/208)   
Writing objects:  60% (125/208)   
Writing objects:  61% (127/208)   
Writing objects:  62% (130/208)   
Writing objects:  63% (132/208)   
Writing objects:  64% (134/208)   
Writing objects:  65% (136/208)   
Writing objects:  66% (138/208)   
Writing objects:  67% (140/208)   
Writing objects:  68% (142/208)   
Writing objects:  69% (144/208)   
Writing objects:  70% (146/208)   
Writing objects:  71% (148/208)   
Writing objects:  72% (150/208)   
Writing objects:  73% (152/208)   
Writing objects:  74% (154/208)   
Writing objects:  75% (156/208)   
Writing objects:  76% (159/208)   
Writing objects:  77% (161/208)   
Writing objects:  78% (163/208)   
Writing objects:  79% (165/208)   
Writing objects:  80% (167/208)   
Writing objects:  81% (169/208)   
Writing objects:  82% (171/208)   
Writing objects:  83% (173/208)   
Writing objects:  84% (175/208)   
Writing objects:  85% (177/208)   
Writing objects:  86% (179/208)   
Writing objects:  87% (181/208)   
Writing objects:  88% (184/208)   
Writing objects:  89% (186/208)   
Writing objects:  90% (188/208)   
Writing objects:  91% (190/208)   
Writing objects:  92% (192/208)   
Writing objects:  93% (194/208)   
Writing objects:  94% (196/208)   
Writing objects:  95% (198/208)   
Writing objects:  96% (200/208)   
Writing objects:  97% (202/208)   
Writing objects:  98% (204/208)   
Writing objects:  99% (206/208)   
Writing objects: 100% (208/208)   
Writing objects: 100% (208/208), 34.08 KiB, done.
Total 208 (delta 171), reused 188 (delta 151)
To xen@xenbits.xensource.com:git/linux-pvops.git
   e63089b..d935d0f  d935d0f77650fea53986811ca8a2f8c726fd9857 -> tested/linux-mingo-tip-master
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 01:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 01:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIrfv-0008U8-39; Sat, 14 Apr 2012 01:21:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIrft-0008U3-8Y
	for xen-devel@lists.xensource.com; Sat, 14 Apr 2012 01:21:13 +0000
Received: from [193.109.254.147:12115] by server-3.bemta-14.messagelabs.com id
	FE/36-23274-801D88F4; Sat, 14 Apr 2012 01:21:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334366471!4487322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDM1Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7005 invoked from network); 14 Apr 2012 01:21:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 01:21:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,420,1330905600"; d="scan'208";a="11934656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Apr 2012 01:20:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 02:20:38 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIrfK-0005BQ-RQ;
	Sat, 14 Apr 2012 01:20:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIrfK-0005dw-LI;
	Sat, 14 Apr 2012 02:20:38 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12679-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 02:20:38 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12679: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12679 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12679/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 01:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 01:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIrfv-0008U8-39; Sat, 14 Apr 2012 01:21:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SIrft-0008U3-8Y
	for xen-devel@lists.xensource.com; Sat, 14 Apr 2012 01:21:13 +0000
Received: from [193.109.254.147:12115] by server-3.bemta-14.messagelabs.com id
	FE/36-23274-801D88F4; Sat, 14 Apr 2012 01:21:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334366471!4487322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDM1Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7005 invoked from network); 14 Apr 2012 01:21:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 01:21:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,420,1330905600"; d="scan'208";a="11934656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Apr 2012 01:20:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 02:20:38 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SIrfK-0005BQ-RQ;
	Sat, 14 Apr 2012 01:20:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SIrfK-0005dw-LI;
	Sat, 14 Apr 2012 02:20:38 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12679-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 02:20:38 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12679: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12679 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12679/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 12592
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 12592
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-pair           8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-win           5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12592
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12592
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 12592
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 12592
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12592
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12592
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12592

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12592
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 12592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12592

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xend-winxpsp3  5 xen-boot                     fail  never pass
 test-i386-i386-win            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-amd64-xl           5 xen-boot                     fail   never pass

version targeted for testing:
 linux                8aa122f38398503c72a83f15c815e84e6e6e6890
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 01:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 01:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIron-0000Bd-35; Sat, 14 Apr 2012 01:30:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SIrol-0000BY-GL
	for Xen-devel@lists.xensource.com; Sat, 14 Apr 2012 01:30:23 +0000
Received: from [85.158.138.51:26901] by server-12.bemta-3.messagelabs.com id
	74/45-29760-E23D88F4; Sat, 14 Apr 2012 01:30:22 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334367020!20273701!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4OTk4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10284 invoked from network); 14 Apr 2012 01:30:21 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Apr 2012 01:30:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3E1UD4R005801
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 14 Apr 2012 01:30:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3E1UC7L017842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 14 Apr 2012 01:30:12 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3E1UBJN011697; Fri, 13 Apr 2012 20:30:11 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Apr 2012 18:30:11 -0700
Date: Fri, 13 Apr 2012 18:29:52 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120413182952.504e2775@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F88D326.004C,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
can please look at it and give any comments. I tested it and seems to work
ok.

Basically, the library, xl running in hybrid dom0, needs to map domU pages
during guest creation. I tried using existing add to physmap, mmu_update,
but nothing was feasible. So wrote this. Its called from
privcmd_ioctl_mmap_batch().

thanks,
Mukesh


/* add frames from foreign domain to current domain physmap. Similar to 
 * XENMEM_add_to_physmap but the mfn frame is foreign, is being mapped into 
 * current privileged domain, and is not removed from foreign domain. 
 * Usage: libxl when creating guest in hybrid dom0 doing privcmd_ioctl_mmap
 * Return: 0 success
 */
static long _add_foreign_to_pmap_batch(XEN_GUEST_HANDLE(void) arg)
{
    struct xen_add_to_foreign_pmap_batch pmapb;
    unsigned long rc=0, i, prev_mfn, mfn = 0;
    struct domain *fdom, *currd = current->domain;
    p2m_type_t p2mt;

    if ( copy_from_guest(&pmapb, arg, 1) )
        return -EFAULT;

    fdom = get_pg_owner(pmapb.foreign_domid);

    if ( fdom== NULL ) {
        put_pg_owner(fdom);
        return -EPERM;
    }

    for (i=0; (rc == 0) && (i < pmapb.count); i++) {
        unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
        mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));
	if ( !p2m_is_valid(p2mt) )
            rc = -EINVAL;

        if ( !rc && !get_page_from_pagenr(mfn, fdom) )
            rc = -EPERM;

        if (!rc) 
            put_page(mfn_to_page(mfn));
        else 
            break;

        /* Remove previously mapped page if it was present. */
        prev_mfn = gmfn_to_mfn(currd, gpfn);
        if ( mfn_valid(prev_mfn) )
        {
            if ( is_xen_heap_mfn(prev_mfn) )
                /* Xen heap frames are simply unhooked from this phys slot */
                guest_physmap_remove_page(currd, gpfn, prev_mfn, 0);
            else
                /* Normal domain memory is freed, to avoid leaking memory. */
                guest_remove_page(currd, gpfn);
        }
        /* Map at new location. */
	/* Can't use guest_physmap_add_page() because it will update the m2p
	 * table so mfn ---> gpfn in dom0 and not gpfn of domU.
	 */
        /* rc = guest_physmap_add_page(currd, gpfn, mfn, 0); */

	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);
        if (rc==0) {
            printk("guest_physmap_add_page failed.gpfn:%lx mfn:%lx fgmfn:%lx\n",
                   gpfn, mfn, fgmfn);
            rc == -EINVAL;
        } else 
            rc = 0;
    }

    pmapb.count = i;
    copy_to_guest(arg, &pmapb, 1);
    put_pg_owner(fdom);
    return rc;
}

static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void) arg)
{
    xen_pfn_t gmfn;
    struct xen_rem_foreign_pmap_batch pmapb;
    p2m_type_t p2mt;
    int i, rc=0;
    struct domain *currd = current->domain;

    if ( copy_from_guest(&pmapb, arg, 1) )
        return -EFAULT;

    for ( gmfn=pmapb.s_gpfn, i=0;  i < pmapb.count;  i++, gmfn++ ) {

        mfn_t mfn = mfn_x(gfn_to_mfn(p2m_get_hostp2m(currd), gmfn, &p2mt));
        if ( unlikely(!mfn_valid(mfn)) )
        {
            gdprintk(XENLOG_INFO, "%s: Domain:%u gmfn:%lx invalid\n",
                     __FUNCTION__, currd->domain_id, gmfn);
            rc = -EINVAL;
            break;
        }
        /* guest_physmap_remove_page(currd, gmfn, mfn, 0); */
	clear_mmio_p2m_entry(p2m_get_hostp2m(currd), gmfn);
    }
    pmapb.count = i;
    copy_to_guest(arg, &pmapb, 1);
    return rc;
}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 01:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 01:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIron-0000Bd-35; Sat, 14 Apr 2012 01:30:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SIrol-0000BY-GL
	for Xen-devel@lists.xensource.com; Sat, 14 Apr 2012 01:30:23 +0000
Received: from [85.158.138.51:26901] by server-12.bemta-3.messagelabs.com id
	74/45-29760-E23D88F4; Sat, 14 Apr 2012 01:30:22 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334367020!20273701!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4OTk4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10284 invoked from network); 14 Apr 2012 01:30:21 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Apr 2012 01:30:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3E1UD4R005801
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 14 Apr 2012 01:30:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3E1UC7L017842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 14 Apr 2012 01:30:12 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3E1UBJN011697; Fri, 13 Apr 2012 20:30:11 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Apr 2012 18:30:11 -0700
Date: Fri, 13 Apr 2012 18:29:52 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120413182952.504e2775@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F88D326.004C,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
can please look at it and give any comments. I tested it and seems to work
ok.

Basically, the library, xl running in hybrid dom0, needs to map domU pages
during guest creation. I tried using existing add to physmap, mmu_update,
but nothing was feasible. So wrote this. Its called from
privcmd_ioctl_mmap_batch().

thanks,
Mukesh


/* add frames from foreign domain to current domain physmap. Similar to 
 * XENMEM_add_to_physmap but the mfn frame is foreign, is being mapped into 
 * current privileged domain, and is not removed from foreign domain. 
 * Usage: libxl when creating guest in hybrid dom0 doing privcmd_ioctl_mmap
 * Return: 0 success
 */
static long _add_foreign_to_pmap_batch(XEN_GUEST_HANDLE(void) arg)
{
    struct xen_add_to_foreign_pmap_batch pmapb;
    unsigned long rc=0, i, prev_mfn, mfn = 0;
    struct domain *fdom, *currd = current->domain;
    p2m_type_t p2mt;

    if ( copy_from_guest(&pmapb, arg, 1) )
        return -EFAULT;

    fdom = get_pg_owner(pmapb.foreign_domid);

    if ( fdom== NULL ) {
        put_pg_owner(fdom);
        return -EPERM;
    }

    for (i=0; (rc == 0) && (i < pmapb.count); i++) {
        unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
        mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));
	if ( !p2m_is_valid(p2mt) )
            rc = -EINVAL;

        if ( !rc && !get_page_from_pagenr(mfn, fdom) )
            rc = -EPERM;

        if (!rc) 
            put_page(mfn_to_page(mfn));
        else 
            break;

        /* Remove previously mapped page if it was present. */
        prev_mfn = gmfn_to_mfn(currd, gpfn);
        if ( mfn_valid(prev_mfn) )
        {
            if ( is_xen_heap_mfn(prev_mfn) )
                /* Xen heap frames are simply unhooked from this phys slot */
                guest_physmap_remove_page(currd, gpfn, prev_mfn, 0);
            else
                /* Normal domain memory is freed, to avoid leaking memory. */
                guest_remove_page(currd, gpfn);
        }
        /* Map at new location. */
	/* Can't use guest_physmap_add_page() because it will update the m2p
	 * table so mfn ---> gpfn in dom0 and not gpfn of domU.
	 */
        /* rc = guest_physmap_add_page(currd, gpfn, mfn, 0); */

	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);
        if (rc==0) {
            printk("guest_physmap_add_page failed.gpfn:%lx mfn:%lx fgmfn:%lx\n",
                   gpfn, mfn, fgmfn);
            rc == -EINVAL;
        } else 
            rc = 0;
    }

    pmapb.count = i;
    copy_to_guest(arg, &pmapb, 1);
    put_pg_owner(fdom);
    return rc;
}

static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void) arg)
{
    xen_pfn_t gmfn;
    struct xen_rem_foreign_pmap_batch pmapb;
    p2m_type_t p2mt;
    int i, rc=0;
    struct domain *currd = current->domain;

    if ( copy_from_guest(&pmapb, arg, 1) )
        return -EFAULT;

    for ( gmfn=pmapb.s_gpfn, i=0;  i < pmapb.count;  i++, gmfn++ ) {

        mfn_t mfn = mfn_x(gfn_to_mfn(p2m_get_hostp2m(currd), gmfn, &p2mt));
        if ( unlikely(!mfn_valid(mfn)) )
        {
            gdprintk(XENLOG_INFO, "%s: Domain:%u gmfn:%lx invalid\n",
                     __FUNCTION__, currd->domain_id, gmfn);
            rc = -EINVAL;
            break;
        }
        /* guest_physmap_remove_page(currd, gmfn, mfn, 0); */
	clear_mmio_p2m_entry(p2m_get_hostp2m(currd), gmfn);
    }
    pmapb.count = i;
    copy_to_guest(arg, &pmapb, 1);
    return rc;
}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 01:48:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 01:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIs5N-0000Nw-Kt; Sat, 14 Apr 2012 01:47:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SIs5M-0000Nr-N7
	for Xen-devel@lists.xensource.com; Sat, 14 Apr 2012 01:47:32 +0000
Received: from [85.158.139.83:61133] by server-1.bemta-5.messagelabs.com id
	70/4E-28458-337D88F4; Sat, 14 Apr 2012 01:47:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334368049!23761440!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4OTk4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13940 invoked from network); 14 Apr 2012 01:47:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Apr 2012 01:47:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3E1lPfP013205
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 14 Apr 2012 01:47:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3E1lOQF002737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 14 Apr 2012 01:47:25 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3E1lOMo018448; Fri, 13 Apr 2012 20:47:24 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Apr 2012 18:47:23 -0700
Date: Fri, 13 Apr 2012 18:47:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120413184705.77b4d316@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4F88D72E.0040,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 26 Mar 2012 11:37:46 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> I think that we should explicitly allocate these pages/addresses and
> not rely on the fact that they are at a specific location that we deem
> safe for now.
> So if we explicitly introduce a new region at the end of the e820 that
> we mark as reserved and we use it for this, I would be OK with that.
> However we need to be careful because editing the e820 has proved to
> be challenging in the past.
> Also we would need to figure out a way to tell Linux that these
> reserved addresses are actually OK to be used. Maybe we need a new
> command line or hypercall for that.

That sounds like reasonable approach. Lets do it as part of phase II.
I wanna get some basic code in.

So, to give an update of where I am, good news, I've got guests 
finally booting using hybrid dom0. So, that means I am almost there 
now!!!! Yeay...

But, the pfn space management for privcmd mapping is still a hack. 
Running into many issues. Basially, it is forcing me to write a slab
allocator for the resvd pfn space, that I am trying to avoid. During
guest creation, xl process maps about 10k foreign pgs, and xenstored 1.

I was thinking of just dividing my pfn space into say 10 chunks, each
with 10k pages, so 10 guest creations can happen simultaneously. But,
then xl is not the only process doing the mapping I found out. xenstored
also needs to map domU frames. Otherwise, I could just do one chunk
per process. Also, I am breaking mmap semantics somewhat by hooking
via privcmd_mmap, because the unmaps don't follow any order. So my last
unmap frees the entire 10k chunk it's using. 

In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
for privcmd without writing a slab allocator. I think using mmap makes
it harder, can't we just use ioctl to get the VA? Then, I could nicely
do something like:
  xl: 
    - open(privcmd file)
    - ioctl(get rsvd/e820 pfn handle)
    - ioctl(get VA using above handle) /* alternate to mmap */
    - ioctl(get VA1 using above handle) /* alternate to mmap */
    ...
    - ioctl(release handle)
    - ioctl(release VA)
    - close file

Is that an option (to change mmap to ioctl)? 

Hope that makes sense,

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 01:48:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 01:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SIs5N-0000Nw-Kt; Sat, 14 Apr 2012 01:47:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SIs5M-0000Nr-N7
	for Xen-devel@lists.xensource.com; Sat, 14 Apr 2012 01:47:32 +0000
Received: from [85.158.139.83:61133] by server-1.bemta-5.messagelabs.com id
	70/4E-28458-337D88F4; Sat, 14 Apr 2012 01:47:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334368049!23761440!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4OTk4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13940 invoked from network); 14 Apr 2012 01:47:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Apr 2012 01:47:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3E1lPfP013205
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 14 Apr 2012 01:47:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3E1lOQF002737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 14 Apr 2012 01:47:25 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3E1lOMo018448; Fri, 13 Apr 2012 20:47:24 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Apr 2012 18:47:23 -0700
Date: Fri, 13 Apr 2012 18:47:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120413184705.77b4d316@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4F88D72E.0040,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 26 Mar 2012 11:37:46 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> I think that we should explicitly allocate these pages/addresses and
> not rely on the fact that they are at a specific location that we deem
> safe for now.
> So if we explicitly introduce a new region at the end of the e820 that
> we mark as reserved and we use it for this, I would be OK with that.
> However we need to be careful because editing the e820 has proved to
> be challenging in the past.
> Also we would need to figure out a way to tell Linux that these
> reserved addresses are actually OK to be used. Maybe we need a new
> command line or hypercall for that.

That sounds like reasonable approach. Lets do it as part of phase II.
I wanna get some basic code in.

So, to give an update of where I am, good news, I've got guests 
finally booting using hybrid dom0. So, that means I am almost there 
now!!!! Yeay...

But, the pfn space management for privcmd mapping is still a hack. 
Running into many issues. Basially, it is forcing me to write a slab
allocator for the resvd pfn space, that I am trying to avoid. During
guest creation, xl process maps about 10k foreign pgs, and xenstored 1.

I was thinking of just dividing my pfn space into say 10 chunks, each
with 10k pages, so 10 guest creations can happen simultaneously. But,
then xl is not the only process doing the mapping I found out. xenstored
also needs to map domU frames. Otherwise, I could just do one chunk
per process. Also, I am breaking mmap semantics somewhat by hooking
via privcmd_mmap, because the unmaps don't follow any order. So my last
unmap frees the entire 10k chunk it's using. 

In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
for privcmd without writing a slab allocator. I think using mmap makes
it harder, can't we just use ioctl to get the VA? Then, I could nicely
do something like:
  xl: 
    - open(privcmd file)
    - ioctl(get rsvd/e820 pfn handle)
    - ioctl(get VA using above handle) /* alternate to mmap */
    - ioctl(get VA1 using above handle) /* alternate to mmap */
    ...
    - ioctl(release handle)
    - ioctl(release VA)
    - close file

Is that an option (to change mmap to ioctl)? 

Hope that makes sense,

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 14:08:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 14:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ3e1-0001QK-1k; Sat, 14 Apr 2012 14:08:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SJ3dz-0001QF-67
	for xen-devel@lists.xen.org; Sat, 14 Apr 2012 14:08:03 +0000
Received: from [85.158.138.51:11515] by server-9.bemta-3.messagelabs.com id
	6F/FD-26691-2C4898F4; Sat, 14 Apr 2012 14:08:02 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334412481!22164597!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8679 invoked from network); 14 Apr 2012 14:08:01 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 14:08:01 -0000
Received: by werp12 with SMTP id p12so3118827wer.32
	for <xen-devel@lists.xen.org>; Sat, 14 Apr 2012 07:08:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=2jgFd19UQbHnXCuV95RD5Gjnfft7bpKEN+0jL1YWK10=;
	b=xKH41Oj2wN8j/J2RAlB/yQY2TituEG9b7x3r/ZF4qxFHFl8AF/kZxodT7pri10F74s
	9UnRLm7sefJrEYQzcZoxvmhi2BV0EayQULgkJk97GD+QqQ3uzjrDBac0HCHTCU2l2OwW
	Uksam2za78SxqrrmHF7WPUViSLCwpnkHosbdP/61JN8353US0MLC0DdLzsOFpe8mlQra
	tzUKBcsvqSajBLHju8byG7ofsFgF1DrovJkne1WeKfFq7DrIw1pbEaVg3NM9B15xpXQy
	xfGku9gq2NjXLHeRB/Jp2bVa7ekk4dsv5LcerEx8u+I7kQUqSS/0gRj5UejpmFgjBLT9
	iXNQ==
MIME-Version: 1.0
Received: by 10.216.137.226 with SMTP id y76mr2883275wei.96.1334412480855;
	Sat, 14 Apr 2012 07:08:00 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Sat, 14 Apr 2012 07:08:00 -0700 (PDT)
In-Reply-To: <f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
Date: Sat, 14 Apr 2012 07:08:00 -0700
Message-ID: <CAKpvNa1Hp_R5enyzjQuNxDf_WF0qH96hOaXx2RGpuJG+t=AhPQ@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: andres@gridcentric.ca, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86/mm/shadow: enclose an OOS
 function in the proper conditional ifdef
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 9:22 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> =A0xen/arch/x86/mm/shadow/multi.c | =A03 ++-
> =A01 files changed, 2 insertions(+), 1 deletions(-)
>
>
> Otherwise compilation fails if the feature is disabled.

Oh yes, my fault. This has been around for quite a few years in my
disks with the promise to "Send It Next Time" (TM). Thanks for fixing
this.

Acked-By: Gianluca Guida <gianluca.guida@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 14:08:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 14:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ3e1-0001QK-1k; Sat, 14 Apr 2012 14:08:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1SJ3dz-0001QF-67
	for xen-devel@lists.xen.org; Sat, 14 Apr 2012 14:08:03 +0000
Received: from [85.158.138.51:11515] by server-9.bemta-3.messagelabs.com id
	6F/FD-26691-2C4898F4; Sat, 14 Apr 2012 14:08:02 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334412481!22164597!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8679 invoked from network); 14 Apr 2012 14:08:01 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 14:08:01 -0000
Received: by werp12 with SMTP id p12so3118827wer.32
	for <xen-devel@lists.xen.org>; Sat, 14 Apr 2012 07:08:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=2jgFd19UQbHnXCuV95RD5Gjnfft7bpKEN+0jL1YWK10=;
	b=xKH41Oj2wN8j/J2RAlB/yQY2TituEG9b7x3r/ZF4qxFHFl8AF/kZxodT7pri10F74s
	9UnRLm7sefJrEYQzcZoxvmhi2BV0EayQULgkJk97GD+QqQ3uzjrDBac0HCHTCU2l2OwW
	Uksam2za78SxqrrmHF7WPUViSLCwpnkHosbdP/61JN8353US0MLC0DdLzsOFpe8mlQra
	tzUKBcsvqSajBLHju8byG7ofsFgF1DrovJkne1WeKfFq7DrIw1pbEaVg3NM9B15xpXQy
	xfGku9gq2NjXLHeRB/Jp2bVa7ekk4dsv5LcerEx8u+I7kQUqSS/0gRj5UejpmFgjBLT9
	iXNQ==
MIME-Version: 1.0
Received: by 10.216.137.226 with SMTP id y76mr2883275wei.96.1334412480855;
	Sat, 14 Apr 2012 07:08:00 -0700 (PDT)
Received: by 10.216.216.214 with HTTP; Sat, 14 Apr 2012 07:08:00 -0700 (PDT)
In-Reply-To: <f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
Date: Sat, 14 Apr 2012 07:08:00 -0700
Message-ID: <CAKpvNa1Hp_R5enyzjQuNxDf_WF0qH96hOaXx2RGpuJG+t=AhPQ@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: andres@gridcentric.ca, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86/mm/shadow: enclose an OOS
 function in the proper conditional ifdef
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 9:22 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> =A0xen/arch/x86/mm/shadow/multi.c | =A03 ++-
> =A01 files changed, 2 insertions(+), 1 deletions(-)
>
>
> Otherwise compilation fails if the feature is disabled.

Oh yes, my fault. This has been around for quite a few years in my
disks with the promise to "Send It Next Time" (TM). Thanks for fixing
this.

Acked-By: Gianluca Guida <gianluca.guida@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 18:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 18:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ7cY-0003gF-Cw; Sat, 14 Apr 2012 18:22:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJ7cW-0003fz-3j
	for xen-devel@lists.xensource.com; Sat, 14 Apr 2012 18:22:48 +0000
Received: from [85.158.143.35:54755] by server-2.bemta-4.messagelabs.com id
	EF/B8-17550-770C98F4; Sat, 14 Apr 2012 18:22:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334427766!11342999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16586 invoked from network); 14 Apr 2012 18:22:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 18:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="11938262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Apr 2012 18:22:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 19:22:46 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJ7cT-0002XP-Iv;
	Sat, 14 Apr 2012 18:22:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJ7cT-0000jY-Bp;
	Sat, 14 Apr 2012 19:22:45 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12692-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 19:22:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12692: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12692 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12692/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                afd74d2e82028e8dfdd48ae3fb429c9fda02c51c
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit afd74d2e82028e8dfdd48ae3fb429c9fda02c51c
Merge: 99850fd... a385ec4...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 13 09:57:51 2012 +0200

    Merge branch 'perf/core'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 18:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 18:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ7cY-0003gF-Cw; Sat, 14 Apr 2012 18:22:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJ7cW-0003fz-3j
	for xen-devel@lists.xensource.com; Sat, 14 Apr 2012 18:22:48 +0000
Received: from [85.158.143.35:54755] by server-2.bemta-4.messagelabs.com id
	EF/B8-17550-770C98F4; Sat, 14 Apr 2012 18:22:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334427766!11342999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16586 invoked from network); 14 Apr 2012 18:22:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 18:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="11938262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Apr 2012 18:22:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 19:22:46 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJ7cT-0002XP-Iv;
	Sat, 14 Apr 2012 18:22:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJ7cT-0000jY-Bp;
	Sat, 14 Apr 2012 19:22:45 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12692-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 19:22:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12692: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12692 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12692/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                afd74d2e82028e8dfdd48ae3fb429c9fda02c51c
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit afd74d2e82028e8dfdd48ae3fb429c9fda02c51c
Merge: 99850fd... a385ec4...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Fri Apr 13 09:57:51 2012 +0200

    Merge branch 'perf/core'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 20:11:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 20:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ9JR-00067S-Ea; Sat, 14 Apr 2012 20:11:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1SJ9JP-00067J-HV
	for xen-devel@lists.xen.org; Sat, 14 Apr 2012 20:11:12 +0000
Received: from [85.158.143.99:53966] by server-3.bemta-4.messagelabs.com id
	A8/D8-05853-ED9D98F4; Sat, 14 Apr 2012 20:11:10 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334434267!25101215!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22427 invoked from network); 14 Apr 2012 20:11:07 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 20:11:07 -0000
Received: by werp12 with SMTP id p12so3256531wer.32
	for <xen-devel@lists.xen.org>; Sat, 14 Apr 2012 13:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=SotwHRcl8Uo/rBDuk2CGrtgUhO8nowHmEO5u8Ec3cSA=;
	b=BDbq9oFaqTFvKVi1IdoxQjjmappSUGruKSvPjuGDBZARuATg7OBljjgr6WzR/RuI+q
	kyMEDkO70hMya+Akf9yj3G2Tr1dKrN/10T/nC+s2XKcaim7Rx/rW71Q3FFa4qbATw+yu
	2+AJATUIe1q3Paa2mVlKmjMKX1KU4xrgPrp+0/MSBv047aHomrvAuI0wJUkIwlpDgFcT
	ESUIDrNkB9dFjsfRd2uvhbT8Qo2QMs3EeoOMvvHHd/CYtRU2idltytnsf/zH4BdD4EZ2
	fYd0/VMtOAlmTldHfrpXdCGsAJCF/WUHMM9qvzhwOumjtVVW214Lkb0zlDw5zNDayuxM
	VbTw==
MIME-Version: 1.0
Received: by 10.216.134.24 with SMTP id r24mr3494099wei.84.1334434266875; Sat,
	14 Apr 2012 13:11:06 -0700 (PDT)
Received: by 10.223.123.138 with HTTP; Sat, 14 Apr 2012 13:11:06 -0700 (PDT)
Date: Sun, 15 Apr 2012 04:11:06 +0800
Message-ID: <CAEQjb-SGFkWu6cCMNyeAF8YqA3Hua_9s99OeuO2MsiKysKYkHg@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Error: disagrees about version of symbol
	HYPERVISOR_shared_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7701379240379758479=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7701379240379758479==
Content-Type: multipart/alternative; boundary=0016e6d77d7f7406d904bda9308d

--0016e6d77d7f7406d904bda9308d
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi All,

I want to shared a variable between Dom0 and Xen. I add the variable
into *struct
shared_info* in code file xen/include/public/xen.h and
linux-2.6.18-xen.hg/include/xen/interface/xeb.h.
In Dom0, I use *shared_info_t *s =3D HYPERVISOR_shared_info* to get the val=
ue
of the shared variable.

However, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot into
Dom0. The error from serial port debug is logged as the following.

Could anyone help me figure out the problem? Any suggestion is appreciated.
Thanks a lot.




=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D PuTTY log 2012.04.15 03:37:=
03
=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D
Restarting system.
(XEN) Domain 0 shutdown: rebooting machine.
 __  __            _  _    _   ____
 \ \/ /___ _ __   | || |  / | |___ \
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/
 /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20=
070925 (Red Hat
4.1.2-33)) Sun Apr 15 03:24:23 CST 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009a800 (usable)
(XEN)  00000000000f0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cd9ffc00 (usable)
(XEN)  00000000cd9ffc00 - 00000000cda53c00 (ACPI NVS)
(XEN)  00000000cda53c00 - 00000000cda55c00 (ACPI data)
(XEN)  00000000cda55c00 - 00000000d0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fed00400 (reserved)
(XEN)  00000000fed20000 - 00000000feda0000 (reserved)
(XEN)  00000000fee00000 - 00000000fef00000 (reserved)
(XEN)  00000000ffb00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000128000000 (usable)
(XEN) System RAM: 3929MB (4023908kB)
(XEN) ACPI: RSDP 000FEC00, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000FC7CB, 009C (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL    B10K          15 ASL        61)
(XEN) ACPI: DSDT FFE9CFF8, 54AD (r1   DELL    dt_ex     1000 INTL 20050624)
(XEN) ACPI: FACS CD9FFC00, 0040
(XEN) ACPI: SSDT FFEA25C4, 00AA (r1   DELL    st_ex     1000 INTL 20050624)
(XEN) ACPI: APIC 000FC9EF, 0092 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: ASF! 000FCAA9, 0096 (r32 DELL    B10K          15 ASL        61=
)
(XEN) ACPI: MCFG 000FCB3F, 003E (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: TCPA 000FCDD9, 0032 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: DMAR 000FCE0B, 0120 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm  Cpu0Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm  Cpu1Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm  Cpu2Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA0085B, 01B7 (r1 DpgPmm  Cpu3Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA00C64, 0190 (r1 DpgPmm    CpuPm       10 INTL 20050624)
(XEN) Xen heap: 9MB (9768kB)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) Processor #2 7:7 APIC version 20
(XEN) Processor #3 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2660.080 MHz processor.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 32-bit, PAE, lsb
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc0100000 -> 0xc04c923c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000124000000->0000000125000000 (953327 pages to
be allocated)
(XEN)  Init. ramdisk: 00000001278fe000->0000000127fff400
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: c0100000->c04c923c
(XEN)  Init. ramdisk: c04ca000->c0bcb400
(XEN)  Phys-Mach map: c0bcc000->c0f74bc4
(XEN)  Start info:    c0f75000->c0f7547c
(XEN)  Page tables:   c0f76000->c0f85000
(XEN)  Boot stack:    c0f85000->c0f86000
(XEN)  TOTAL:         c0000000->c1400000
(XEN)  ENTRY ADDRESS: c0100000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault
addr ffffff000, iommu reg =3D fff16000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 184kB init memory.
Linux version 2.6.18.8-xen (root@localhost.localdomain) (gcc =E7=89=88=E6=
=9C=AC 4.1.2
20070925 (Red Hat 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000eaaf1000 (usable)
3026MB HIGHMEM available.
727MB LOWMEM available.
NX (Execute Disable) protection: active
On node 0 totalpages: 961265
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 182270 pages, LIFO batch:31
  HighMem zone: 774899 pages, LIFO batch:31
found SMP MP-table at 000fe710
DMI 2.5 present.
ACPI: RSDP (v002 DELL                                  ) @ 0x000fec00
ACPI: XSDT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc7cb
ACPI: FADT (v003 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc8fb
ACPI: SSDT (v001   DELL    st_ex 0x00001000 INTL 0x20050624) @ 0xffea25c4
ACPI: MADT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc9ef
ACPI: BOOT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fca81
ACPI: ASF! (v032 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcaa9
ACPI: MCFG (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb3f
ACPI: HPET (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb7d
ACPI: TCPA (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcdd9
  >>> ERROR: Invalid checksum
ACPI: DMAR (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fce0b
ACPI: SLIC (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcbb5
ACPI: SSDT (v001 DpgPmm  Cpu0Ist 0x00000011 INTL 0x20050624) @ 0xcd9ffc40
ACPI: SSDT (v001 DpgPmm  Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049
ACPI: SSDT (v001 DpgPmm  Cpu2Ist 0x00000011 INTL 0x20050624) @ 0xcda00452
ACPI: SSDT (v001 DpgPmm  Cpu3Ist 0x00000011 INTL 0x20050624) @ 0xcda0085b
ACPI: SSDT (v001 DpgPmm    CpuPm 0x00000010 INTL 0x20050624) @ 0xcda00c64
ACPI: DSDT (v001   DELL    dt_ex 0x00001000 INTL 0x20050624) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at d1000000 (gap: d0000000:10000000)
Detected 2660.681 MHz processor.
Built 1 zonelists.  Total pages: 961265
Kernel command line: ro root=3D/dev/sda11 console=3Dhvc0 console=3Dtty0
console=3DttyS0,115200n8 debug selinux=3D0
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Xen reported: 2660.080 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Software IO TLB enabled:
 Aperture:     64 megabytes
 Kernel range: c31fd000 - c71fd000
 Address size: 27 bits
vmalloc area: ee000000-f51fe000, maxmem 2d7fe000
Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,
908k data, 204k init, 3099596k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok=
.
Calibrating delay using timer specific routine.. 5347.97 BogoMIPS
(lpj=3D26739870)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
ACPI: Core revision 20060707
ENABLING IO-APIC IRQs
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
Brought up 4 CPUs
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000<6>Initializing CPU#3

CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000
CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000
migration_cost=3D12
checking if image is initramfs... it is
Freeing initrd memory: 7173k freed
PM: Adding info for No Bus:platform
NET: Registered protocol family 16
PM: Adding info for No Bus:xen
PM: Adding info for No Bus:xen-backend
ACPI: bus type pci registered
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
PCI: MCFG area at e0000000 reserved in E820
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
PM: Adding info for acpi:acpi
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PM: Adding info for No Bus:pci0000:00
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:00:02.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
PM: Adding info for pci:0000:00:00.0
PM: Adding info for pci:0000:00:01.0
PM: Adding info for pci:0000:00:02.0
PM: Adding info for pci:0000:00:02.1
PM: Adding info for pci:0000:00:03.0
PM: Adding info for pci:0000:00:03.2
PM: Adding info for pci:0000:00:03.3
PM: Adding info for pci:0000:00:19.0
PM: Adding info for pci:0000:00:1a.0
PM: Adding info for pci:0000:00:1a.1
PM: Adding info for pci:0000:00:1a.2
PM: Adding info for pci:0000:00:1a.7
PM: Adding info for pci:0000:00:1b.0
PM: Adding info for pci:0000:00:1c.0
PM: Adding info for pci:0000:00:1c.1
PM: Adding info for pci:0000:00:1d.0
PM: Adding info for pci:0000:00:1d.1
PM: Adding info for pci:0000:00:1d.2
PM: Adding info for pci:0000:00:1d.7
PM: Adding info for pci:0000:00:1e.0
PM: Adding info for pci:0000:00:1f.0
PM: Adding info for pci:0000:00:1f.2
PM: Adding info for pci:0000:00:1f.3
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled=
.
ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
PM: Adding info for No Bus:pnp0
PM: Adding info for pnp:00:00
PM: Adding info for pnp:00:01
PM: Adding info for pnp:00:02
PM: Adding info for pnp:00:03
PM: Adding info for pnp:00:04
PM: Adding info for pnp:00:05
PM: Adding info for pnp:00:06
(XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4
(XEN) ioapic_guest_write: new_entry=3D000109f1
(XEN) ioapic_guest_write: old_entry=3D000009f1 pirq=3D4
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
PM: Adding info for pnp:00:07
PM: Adding info for pnp:00:08
pnp: PnP ACPI: found 9 devices
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=3Drouteirq".  If it helps, post a
report
pnp: 00:01: ioport range 0x800-0x85f could not be reserved
pnp: 00:01: ioport range 0xc00-0xc7f has been reserved
pnp: 00:01: ioport range 0x860-0x8ff has been reserved
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: fe500000-fe5fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: fe400000-fe4fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: disabled.
  MEM window: fe300000-fe3fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
PM: Adding info for platform:pcspkr
Simple Boot Flag at 0x7a set to 0x1
IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1334461010.944:1): initialized
highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
PM: Adding info for platform:vesafb.0
Floppy drive(s): fd0 is 1.44M
floppy0: Unable to grab DMA2 for the floppy driver
floppy0: no floppy controllers found
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k4
e1000e: Copyright (c) 1999-2008 Intel Corporation.
ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 21 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:19.0 to 64
(XEN) physdev.c:155: dom0: wrong map_pirq type 3
eth0: (PCI Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54
eth0: Intel(R) PRO/1000 Network Connection
eth0: MAC: 7, PHY: 8, PBA No: 2021ff-0ff
Intel(R) Gigabit Ethernet Network Driver - version 1.2.45-k2
Copyright (c) 2008 Intel Corporation.
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version
1.3.56.5-NAPI
Copyright (c) 1999-2008 Intel Corporation.
Xen virtual console successfully installed as xvc0
Event-channel device installed.
blktap_device_init: blktap device major 254
blktap_ring_init: blktap ring major: 253
netfront: Initialising virtual ethernet driver.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=3D=
xx
PNP: No PS/2 controller found. Probing ports directly.
PM: Adding info for platform:i8042
serio: i8042 AUX port at 0x60,0x64 irq 12
PM: Adding info for serio:serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
PM: Adding info for serio:serio1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
md: bitmap version 4.39
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
PCI IO multiplexer device installed.
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 204k freed
*usbcore: disagrees about version of symbol HYPERVISOR_shared_info*
usbcore: Unknown symbol HYPERVISOR_shared_info
ehci_hcd: Unknown symbol usb_hcd_pci_suspend
ehci_hcd: Unknown symbol usb_free_urb
ehci_hcd: Unknown symbol usb_hub_tt_clear_buffer
ehci_hcd: Unknown symbol usb_hcd_resume_root_hub
ehci_hcd: Unknown symbol usb_hcd_pci_probe
ehci_hcd: Unknown symbol usb_calc_bus_time
ehci_hcd: Unknown symbol usb_hcd_pci_resume
ehci_hcd: Unknown symbol usb_get_urb
ehci_hcd: Unknown symbol usb_hcd_giveback_urb
ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
ehci_hcd: Unknown symbol HYPERVISOR_shared_info
ehci_hcd: Unknown symbol usb_hcd_pci_remove
ehci_hcd: Unknown symbol usb_root_hub_lost_power
ohci_hcd: Unknown symbol usb_hcd_pci_suspend
ohci_hcd: Unknown symbol usb_hcd_resume_root_hub
ohci_hcd: Unknown symbol usb_hcd_pci_probe
ohci_hcd: Unknown symbol usb_disabled
ohci_hcd: Unknown symbol usb_calc_bus_time
ohci_hcd: Unknown symbol usb_hcd_pci_resume
ohci_hcd: Unknown symbol usb_hcd_giveback_urb
ohci_hcd: Unknown symbol usb_hcd_suspend_root_hub
ohci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
ohci_hcd: Unknown symbol HYPERVISOR_shared_info
ohci_hcd: Unknown symbol usb_hcd_pci_remove
ohci_hcd: Unknown symbol usb_root_hub_lost_power
uhci_hcd: Unknown symbol usb_hcd_pci_suspend
uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
uhci_hcd: Unknown symbol usb_hcd_pci_probe
uhci_hcd: Unknown symbol usb_check_bandwidth
uhci_hcd: Unknown symbol usb_disabled
uhci_hcd: Unknown symbol usb_release_bandwidth
uhci_hcd: Unknown symbol usb_claim_bandwidth
uhci_hcd: Unknown symbol usb_hcd_pci_resume
uhci_hcd: Unknown symbol usb_hcd_giveback_urb
uhci_hcd: Unknown symbol usb_hcd_poll_rh_status
uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
uhci_hcd: Unknown symbol HYPERVISOR_shared_info
uhci_hcd: Unknown symbol usb_hcd_pci_remove
uhci_hcd: Unknown symbol usb_root_hub_lost_power
scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info
scsi_mod: Unknown symbol HYPERVISOR_shared_info
sd_mod: Unknown symbol scsi_print_sense_hdr
sd_mod: Unknown symbol scsi_mode_sense
sd_mod: Unknown symbol scsi_device_get
sd_mod: Unknown symbol scsi_get_sense_info_fld
sd_mod: Unknown symbol scsicam_bios_param
sd_mod: Unknown symbol scsi_command_normalize_sense
sd_mod: Unknown symbol scsi_test_unit_ready
sd_mod: Unknown symbol scsi_block_when_processing_errors
sd_mod: Unknown symbol scsi_register_driver
sd_mod: Unknown symbol scsi_ioctl
sd_mod: Unknown symbol scsi_nonblockable_ioctl
sd_mod: Unknown symbol scsi_device_put
sd_mod: Unknown symbol scsi_logging_level
sd_mod: Unknown symbol scsi_execute_req
sd_mod: Unknown symbol scsi_mode_select
sd_mod: Unknown symbol scsi_print_sense
sd_mod: Unknown symbol scsi_io_completion
sd_mod: Unknown symbol scsi_set_medium_removal
libata: Unknown symbol scsi_device_get
libata: Unknown symbol scsi_remove_host
libata: Unknown symbol scsi_schedule_eh
libata: Unknown symbol scsi_device_set_state
libata: Unknown symbol scsi_eh_finish_cmd
libata: Unknown symbol scsi_device_put
libata: Unknown symbol scsi_eh_flush_done_q
libata: Unknown symbol scsi_host_put
libata: Unknown symbol scsi_add_host
libata: Unknown symbol scsi_rescan_device
libata: Unknown symbol scsi_adjust_queue_depth
libata: Unknown symbol scsi_execute_req
libata: Unknown symbol scsi_req_abort_cmd
libata: disagrees about version of symbol HYPERVISOR_shared_info
libata: Unknown symbol HYPERVISOR_shared_info
libata: Unknown symbol scsi_remove_device
libata: Unknown symbol scsi_host_alloc
libata: Unknown symbol __scsi_add_device
ahci: Unknown symbol ata_scsi_ioctl
ahci: Unknown symbol ata_port_abort
ahci: Unknown symbol ata_std_bios_param
ahci: Unknown symbol ata_std_postreset
ahci: Unknown symbol ata_scsi_device_resume
ahci: Unknown symbol ata_scsi_device_suspend
ahci: Unknown symbol ata_tf_from_fis
ahci: Unknown symbol ata_qc_complete_multiple
ahci: Unknown symbol ata_noop_dev_select
ahci: Unknown symbol ata_tf_to_fis
ahci: Unknown symbol ata_pci_device_do_resume
ahci: Unknown symbol ata_dev_classify
ahci: Unknown symbol ata_scsi_release
ahci: Unknown symbol ata_port_offline
ahci: Unknown symbol ata_scsi_change_queue_depth
ahci: Unknown symbol sata_std_hardreset
ahci: Unknown symbol ata_pci_device_suspend
ahci: Unknown symbol scsi_host_put
ahci: Unknown symbol ata_port_online
ahci: Unknown symbol ata_wait_register
ahci: Unknown symbol ata_busy_sleep
ahci: Unknown symbol ata_scsi_slave_config
ahci: Unknown symbol ata_port_detach
ahci: Unknown symbol ata_port_disable
ahci: Unknown symbol ata_scsi_queuecmd
ahci: Unknown symbol ata_scsi_slave_destroy
ahci: Unknown symbol ata_ratelimit
ahci: Unknown symbol ata_host_set_resume
ahci: Unknown symbol ata_do_eh
ahci: Unknown symbol ata_port_freeze
ahci: Unknown symbol ata_std_prereset
ahci: Unknown symbol ata_device_add



--=20
Best Regards,
Bei Guan

--0016e6d77d7f7406d904bda9308d
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div>Hi All,</div><div><br></div><div>I want to shared a variable between D=
om0 and Xen. I add the variable into <b>struct shared_info</b> in code file=
 xen/include/public/xen.h and linux-2.6.18-xen.hg/include/xen/interface/xeb=
.h.</div>
<div>In Dom0, I use <b>shared_info_t *s =3D HYPERVISOR_shared_info</b> to g=
et the value of the shared variable.&nbsp;</div><div><br></div><div>However=
, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot into Dom0.&=
nbsp;The error from serial port debug is logged as the following.</div>
<div><br></div><div>Could anyone help me figure out the problem? Any sugges=
tion is appreciated. Thanks a lot.</div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div>=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=
=3D PuTTY log 2012.04.15 03:37:03 =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=
=3D~=3D</div>
<div>Restarting system.</div><div>(XEN) Domain 0 shutdown: rebooting machin=
e.</div><div>&nbsp;__ &nbsp;__ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;_ &=
nbsp;_ &nbsp; &nbsp;_ &nbsp; ____ &nbsp;</div><div>&nbsp;\ \/ /___ _ __ &nb=
sp; | || | &nbsp;/ | |___ \&nbsp;</div><div>&nbsp; \ &nbsp;// _ \ &#39;_ \ =
&nbsp;| || |_ | | &nbsp; __) |</div>
<div>&nbsp; / &nbsp;\ &nbsp;__/ | | | |__ &nbsp; _|| |_ / __/&nbsp;</div><d=
iv>&nbsp;/_/\_\___|_| |_| &nbsp; &nbsp;|_|(_)_(_)_____|</div><div>&nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</div><div>(XEN) Xen versio=
n 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red Hat =
4.1.2-33)) Sun Apr 15 03:24:23 CST 2012</div>
<div>(XEN) Latest ChangeSet: unavailable</div><div>(XEN) Bootloader: GNU GR=
UB 0.97</div><div>(XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1<=
/div><div>(XEN) Video information:</div><div>(XEN) &nbsp;VGA is text mode 8=
0x25, font 8x16</div>
<div>(XEN) &nbsp;VBE/DDC methods: V2; EDID transfer time: 1 seconds</div><d=
iv>(XEN) Disc information:</div><div>(XEN) &nbsp;Found 1 MBR signatures</di=
v><div>(XEN) &nbsp;Found 1 EDD information structures</div><div>(XEN) Xen-e=
820 RAM map:</div>
<div>(XEN) &nbsp;0000000000000000 - 000000000009a800 (usable)</div><div>(XE=
N) &nbsp;00000000000f0000 - 0000000000100000 (reserved)</div><div>(XEN) &nb=
sp;0000000000100000 - 00000000cd9ffc00 (usable)</div><div>(XEN) &nbsp;00000=
000cd9ffc00 - 00000000cda53c00 (ACPI NVS)</div>
<div>(XEN) &nbsp;00000000cda53c00 - 00000000cda55c00 (ACPI data)</div><div>=
(XEN) &nbsp;00000000cda55c00 - 00000000d0000000 (reserved)</div><div>(XEN) =
&nbsp;00000000e0000000 - 00000000f0000000 (reserved)</div><div>(XEN) &nbsp;=
00000000fec00000 - 00000000fed00400 (reserved)</div>
<div>(XEN) &nbsp;00000000fed20000 - 00000000feda0000 (reserved)</div><div>(=
XEN) &nbsp;00000000fee00000 - 00000000fef00000 (reserved)</div><div>(XEN) &=
nbsp;00000000ffb00000 - 0000000100000000 (reserved)</div><div>(XEN) &nbsp;0=
000000100000000 - 0000000128000000 (usable)</div>
<div>(XEN) System RAM: 3929MB (4023908kB)</div><div>(XEN) ACPI: RSDP 000FEC=
00, 0024 (r2 DELL &nbsp;)</div><div>(XEN) ACPI: XSDT 000FC7CB, 009C (r1 DEL=
L &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; =
&nbsp; &nbsp;61)</div><div>(XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL &nbsp; =
&nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &n=
bsp;61)</div>
<div>(XEN) ACPI: DSDT FFE9CFF8, 54AD (r1 &nbsp; DELL &nbsp; &nbsp;dt_ex &nb=
sp; &nbsp; 1000 INTL 20050624)</div><div>(XEN) ACPI: FACS CD9FFC00, 0040</d=
iv><div>(XEN) ACPI: SSDT FFEA25C4, 00AA (r1 &nbsp; DELL &nbsp; &nbsp;st_ex =
&nbsp; &nbsp; 1000 INTL 20050624)</div><div>(XEN) ACPI: APIC 000FC9EF, 0092=
 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 ASL &nbsp;=
 &nbsp; &nbsp; &nbsp;61)</div>
<div>(XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN=
) ACPI: ASF! 000FCAA9, 0096 (r32 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN) ACPI: =
MCFG 000FCB3F, 003E (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div>
<div>(XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN=
) ACPI: TCPA 000FCDD9, 0032 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN) ACPI: D=
MAR 000FCE0B, 0120 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div>
<div>(XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN=
) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm &nbsp;Cpu0Ist &nbsp; &nbsp; &nbsp; 1=
1 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm &nbsp=
;Cpu1Ist &nbsp; &nbsp; &nbsp; 11 INTL 20050624)</div>
<div>(XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm &nbsp;Cpu2Ist &nbsp; &nbsp;=
 &nbsp; 11 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA0085B, 01B7 (r1 Dpg=
Pmm &nbsp;Cpu3Ist &nbsp; &nbsp; &nbsp; 11 INTL 20050624)</div><div>(XEN) AC=
PI: SSDT CDA00C64, 0190 (r1 DpgPmm &nbsp; &nbsp;CpuPm &nbsp; &nbsp; &nbsp; =
10 INTL 20050624)</div>
<div>(XEN) Xen heap: 9MB (9768kB)</div><div>(XEN) Domain heap initialised</=
div><div>(XEN) Processor #0 7:7 APIC version 20</div><div>(XEN) Processor #=
1 7:7 APIC version 20</div><div>(XEN) Processor #2 7:7 APIC version 20</div=
>
<div>(XEN) Processor #3 7:7 APIC version 20</div><div>(XEN) IOAPIC[0]: apic=
_id 8, version 32, address 0xfec00000, GSI 0-23</div><div>(XEN) Enabling AP=
IC mode: &nbsp;Flat. &nbsp;Using 1 I/O APICs</div><div>(XEN) Table is not f=
ound!</div>
<div>(XEN) Using scheduler: SMP Credit Scheduler (credit)</div><div>(XEN) D=
etected 2660.080 MHz processor.</div><div>(XEN) Intel VT-d Snoop Control no=
t enabled.</div><div>(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.</di=
v>
<div>(XEN) Intel VT-d Queued Invalidation not enabled.</div><div>(XEN) Inte=
l VT-d Interrupt Remapping not enabled.</div><div>(XEN) Intel VT-d Shared E=
PT tables not enabled.</div><div>(XEN) I/O virtualisation enabled</div>
<div>(XEN) &nbsp;- Dom0 mode: Relaxed</div><div>(XEN) ENABLING IO-APIC IRQs=
</div><div>(XEN) &nbsp;-&gt; Using new ACK method</div><div>(XEN) Platform =
timer is 14.318MHz HPET</div><div>=FF(XEN) Allocated console ring of 16 KiB=
.</div><div>
(XEN) VMX: Supported advanced features:</div><div>(XEN) &nbsp;- APIC MMIO a=
ccess virtualisation</div><div>(XEN) &nbsp;- APIC TPR shadow</div><div>(XEN=
) &nbsp;- Virtual NMI</div><div>(XEN) &nbsp;- MSR direct-access bitmap</div=
><div>(XEN) HVM: ASIDs disabled.</div>
<div>(XEN) HVM: VMX enabled</div><div>(XEN) Brought up 4 CPUs</div><div>(XE=
N) *** LOADING DOMAIN 0 ***</div><div>(XEN) &nbsp;Xen &nbsp;kernel: 32-bit,=
 PAE, lsb</div><div>(XEN) &nbsp;Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc010=
0000 -&gt; 0xc04c923c</div>
<div>(XEN) PHYSICAL MEMORY ARRANGEMENT:</div><div>(XEN) &nbsp;Dom0 alloc.: =
&nbsp; 0000000124000000-&gt;0000000125000000 (953327 pages to be allocated)=
</div><div>(XEN) &nbsp;Init. ramdisk: 00000001278fe000-&gt;0000000127fff400=
</div><div>
(XEN) VIRTUAL MEMORY ARRANGEMENT:</div><div>(XEN) &nbsp;Loaded kernel: c010=
0000-&gt;c04c923c</div><div>(XEN) &nbsp;Init. ramdisk: c04ca000-&gt;c0bcb40=
0</div><div>(XEN) &nbsp;Phys-Mach map: c0bcc000-&gt;c0f74bc4</div><div>(XEN=
) &nbsp;Start info: &nbsp; &nbsp;c0f75000-&gt;c0f7547c</div>
<div>(XEN) &nbsp;Page tables: &nbsp; c0f76000-&gt;c0f85000</div><div>(XEN) =
&nbsp;Boot stack: &nbsp; &nbsp;c0f85000-&gt;c0f86000</div><div>(XEN) &nbsp;=
TOTAL: &nbsp; &nbsp; &nbsp; &nbsp; c0000000-&gt;c1400000</div><div>(XEN) &n=
bsp;ENTRY ADDRESS: c0100000</div><div>(XEN) Dom0 has maximum 4 VCPUs</div>
<div>(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow</div><div>=
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault</div><di=
v>(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault =
addr ffffff000, iommu reg =3D fff16000</div>
<div>(XEN) DMAR:[fault reason 05h] PTE Write access is not set</div><div>(X=
EN) Scrubbing Free RAM: .done.</div><div>(XEN) Xen trace buffers: disabled<=
/div><div>(XEN) Std. Loglevel: Errors and warnings</div><div>(XEN) Guest Lo=
glevel: Nothing (Rate-limited: Errors and warnings)</div>
<div>(XEN) Xen is relinquishing VGA console.</div><div>(XEN) *** Serial inp=
ut -&gt; DOM0 (type &#39;CTRL-a&#39; three times to switch input to Xen)</d=
iv><div>(XEN) Freed 184kB init memory.</div><div>Linux version 2.6.18.8-xen=
 (root@localhost.localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red H=
at 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012</div>
<div>BIOS-provided physical RAM map:</div><div>&nbsp;Xen: 0000000000000000 =
- 00000000eaaf1000 (usable)</div><div>3026MB HIGHMEM available.</div><div>7=
27MB LOWMEM available.</div><div>NX (Execute Disable) protection: active</d=
iv>
<div>On node 0 totalpages: 961265</div><div>&nbsp; DMA zone: 4096 pages, LI=
FO batch:0</div><div>&nbsp; Normal zone: 182270 pages, LIFO batch:31</div><=
div>&nbsp; HighMem zone: 774899 pages, LIFO batch:31</div><div>found SMP MP=
-table at 000fe710</div>
<div>DMI 2.5 present.</div><div>ACPI: RSDP (v002 DELL &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;) @ 0x000fec00</div><div>ACPI: XSDT (v001 DELL &nbsp;=
 &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x00000061) @ 0x000fc7cb</div=
><div>ACPI: FADT (v003 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &=
nbsp;0x00000061) @ 0x000fc8fb</div>
<div>ACPI: SSDT (v001 &nbsp; DELL &nbsp; &nbsp;st_ex 0x00001000 INTL 0x2005=
0624) @ 0xffea25c4</div><div>ACPI: MADT (v001 DELL &nbsp; &nbsp;B10K &nbsp;=
 &nbsp;0x00000015 ASL &nbsp;0x00000061) @ 0x000fc9ef</div><div>ACPI: BOOT (=
v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x00000061) @=
 0x000fca81</div>
<div>ACPI: ASF! (v032 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &n=
bsp;0x00000061) @ 0x000fcaa9</div><div>ACPI: MCFG (v001 DELL &nbsp; &nbsp;B=
10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x00000061) @ 0x000fcb3f</div><div>AC=
PI: HPET (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x0=
0000061) @ 0x000fcb7d</div>
<div>ACPI: TCPA (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &n=
bsp;0x00000061) @ 0x000fcdd9</div><div>&nbsp; &gt;&gt;&gt; ERROR: Invalid c=
hecksum</div><div>ACPI: DMAR (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00=
000015 ASL &nbsp;0x00000061) @ 0x000fce0b</div><div>
ACPI: SLIC (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0=
x00000061) @ 0x000fcbb5</div><div>ACPI: SSDT (v001 DpgPmm &nbsp;Cpu0Ist 0x0=
0000011 INTL 0x20050624) @ 0xcd9ffc40</div><div>ACPI: SSDT (v001 DpgPmm &nb=
sp;Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049</div>
<div>ACPI: SSDT (v001 DpgPmm &nbsp;Cpu2Ist 0x00000011 INTL 0x20050624) @ 0x=
cda00452</div><div>ACPI: SSDT (v001 DpgPmm &nbsp;Cpu3Ist 0x00000011 INTL 0x=
20050624) @ 0xcda0085b</div><div>ACPI: SSDT (v001 DpgPmm &nbsp; &nbsp;CpuPm=
 0x00000010 INTL 0x20050624) @ 0xcda00c64</div>
<div>ACPI: DSDT (v001 &nbsp; DELL &nbsp; &nbsp;dt_ex 0x00001000 INTL 0x2005=
0624) @ 0x00000000</div><div>ACPI: Local APIC address 0xfee00000</div><div>=
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)</div><div>ACPI: LAPIC (a=
cpi_id[0x02] lapic_id[0x01] enabled)</div>
<div>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)</div><div>ACPI: LAP=
IC (acpi_id[0x04] lapic_id[0x03] enabled)</div><div>ACPI: LAPIC (acpi_id[0x=
05] lapic_id[0x00] disabled)</div><div>ACPI: LAPIC (acpi_id[0x06] lapic_id[=
0x01] disabled)</div>
<div>ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)</div><div>ACPI: LA=
PIC (acpi_id[0x08] lapic_id[0x03] disabled)</div><div>ACPI: LAPIC_NMI (acpi=
_id[0xff] high level lint[0x1])</div><div>ACPI: IOAPIC (id[0x08] address[0x=
fec00000] gsi_base[0])</div>
<div>IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23</div><d=
iv>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)</div><div>ACPI:=
 INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)</div><div>ACPI: IRQ0=
 used by override.</div>
<div>ACPI: IRQ2 used by override.</div><div>ACPI: IRQ9 used by override.</d=
iv><div>Enabling APIC mode: &nbsp;Flat. &nbsp;Using 1 I/O APICs</div><div>U=
sing ACPI (MADT) for SMP configuration information</div><div>Allocating PCI=
 resources starting at d1000000 (gap: d0000000:10000000)</div>
<div>Detected 2660.681 MHz processor.</div><div>Built 1 zonelists. &nbsp;To=
tal pages: 961265</div><div>Kernel command line: ro root=3D/dev/sda11 conso=
le=3Dhvc0 console=3Dtty0 console=3DttyS0,115200n8 debug selinux=3D0</div><d=
iv>Enabling fast FPU save and restore... done.</div>
<div>Enabling unmasked SIMD FPU exception support... done.</div><div>Initia=
lizing CPU#0</div><div>PID hash table entries: 4096 (order: 12, 16384 bytes=
)</div><div>Xen reported: 2660.080 MHz processor.</div><div>Console: colour=
 VGA+ 80x25</div>
<div>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)</div>=
<div>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)</div><d=
iv>Software IO TLB enabled:&nbsp;</div><div>&nbsp;Aperture: &nbsp; &nbsp; 6=
4 megabytes</div>
<div>&nbsp;Kernel range: c31fd000 - c71fd000</div><div>&nbsp;Address size: =
27 bits</div><div>vmalloc area: ee000000-f51fe000, maxmem 2d7fe000</div><di=
v>Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,=
 908k data, 204k init, 3099596k highmem)</div>
<div>Checking if this processor honours the WP bit even in supervisor mode.=
.. Ok.</div><div>Calibrating delay using timer specific routine.. 5347.97 B=
ogoMIPS (lpj=3D26739870)</div><div>Security Framework v1.0.0 initialized</d=
iv>
<div>Capability LSM initialized</div><div>Mount-cache hash table entries: 5=
12</div><div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 =
00000000 80080281 00000000 00000000</div><div>CPU: After vendor identify, c=
aps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div>
<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000</div><div>Checking &#39;hlt&#39; instruction... OK=
.</div>
<div>SMP alternatives: switching to UP code</div><div>ACPI: Core revision 2=
0060707</div><div>ENABLING IO-APIC IRQs</div><div>SMP alternatives: switchi=
ng to SMP code</div><div>Initializing CPU#1</div><div>Initializing CPU#2</d=
iv>
<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>Broug=
ht up 4 CPUs</div>
<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000&lt;6&gt;Initializing CPU#3</div><div><br></div>
<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>CPU: =
L1 I cache: 32K, L1 D cache: 32K</div>
<div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3f5 00=
100000 00000000 00000140 80080281 00000000 00000000</div><div>CPU: After ge=
neric identify, caps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000=
 00000000</div>
<div>CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000 =
80080281 00000000 00000000</div><div>CPU: L1 I cache: 32K, L1 D cache: 32K<=
/div><div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3=
f5 00100000 00000000 00000140 80080281 00000000 00000000</div>
<div>migration_cost=3D12</div><div>checking if image is initramfs... it is<=
/div><div>Freeing initrd memory: 7173k freed</div><div>PM: Adding info for =
No Bus:platform</div><div>NET: Registered protocol family 16</div><div>PM: =
Adding info for No Bus:xen</div>
<div>PM: Adding info for No Bus:xen-backend</div><div>ACPI: bus type pci re=
gistered</div><div>PCI: MCFG configuration 0: base e0000000 segment 0 buses=
 0 - 255</div><div>PCI: MCFG area at e0000000 reserved in E820</div><div>
PCI: Using MMCONFIG</div><div>Setting up standard PCI resources</div><div>A=
CPI: Interpreter enabled</div><div>ACPI: Using IOAPIC for interrupt routing=
</div><div>PM: Adding info for acpi:acpi</div><div>ACPI: PCI Root Bridge [P=
CI0] (0000:00)</div>
<div>PCI: Probing PCI hardware (bus 00)</div><div>PM: Adding info for No Bu=
s:pci0000:00</div><div>ACPI: Assume root bridge [\_SB_.PCI0] bus is 0</div>=
<div>Boot video device is 0000:00:02.0</div><div>PCI: Transparent bridge - =
0000:00:1e.0</div>
<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]</div><div>PM: Addi=
ng info for pci:0000:00:00.0</div><div>PM: Adding info for pci:0000:00:01.0=
</div><div>PM: Adding info for pci:0000:00:02.0</div><div>PM: Adding info f=
or pci:0000:00:02.1</div>
<div>PM: Adding info for pci:0000:00:03.0</div><div>PM: Adding info for pci=
:0000:00:03.2</div><div>PM: Adding info for pci:0000:00:03.3</div><div>PM: =
Adding info for pci:0000:00:19.0</div><div>PM: Adding info for pci:0000:00:=
1a.0</div>
<div>PM: Adding info for pci:0000:00:1a.1</div><div>PM: Adding info for pci=
:0000:00:1a.2</div><div>PM: Adding info for pci:0000:00:1a.7</div><div>PM: =
Adding info for pci:0000:00:1b.0</div><div>PM: Adding info for pci:0000:00:=
1c.0</div>
<div>PM: Adding info for pci:0000:00:1c.1</div><div>PM: Adding info for pci=
:0000:00:1d.0</div><div>PM: Adding info for pci:0000:00:1d.1</div><div>PM: =
Adding info for pci:0000:00:1d.2</div><div>PM: Adding info for pci:0000:00:=
1d.7</div>
<div>PM: Adding info for pci:0000:00:1e.0</div><div>PM: Adding info for pci=
:0000:00:1f.0</div><div>PM: Adding info for pci:0000:00:1f.2</div><div>PM: =
Adding info for pci:0000:00:1f.3</div><div>ACPI: PCI Interrupt Routing Tabl=
e [\_SB_.PCI0.PCI4._PRT]</div>
<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]</div><div>ACP=
I: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]</div><div>ACPI: PCI I=
nterrupt Routing Table [\_SB_.PCI0.PCI1._PRT]</div><div>ACPI: PCI Interrupt=
 Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 15)</div><=
div>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15)</div><d=
iv>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, dis=
abled.</div><div>ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 1=
2 15)</div><div>ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12=
 15)</div>
<div>ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div><=
div>Linux Plug and Play Support v0.97 (c) Adam Belay</div><div>pnp: PnP ACP=
I init</div><div>PM: Adding info for No Bus:pnp0</div><div>PM: Adding info =
for pnp:00:00</div>
<div>PM: Adding info for pnp:00:01</div><div>PM: Adding info for pnp:00:02<=
/div><div>PM: Adding info for pnp:00:03</div><div>PM: Adding info for pnp:0=
0:04</div><div>PM: Adding info for pnp:00:05</div><div>PM: Adding info for =
pnp:00:06</div>
<div>(XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4</div><div>(XEN) i=
oapic_guest_write: new_entry=3D000109f1</div><div>(XEN) ioapic_guest_write:=
 old_entry=3D000009f1 pirq=3D4</div><div>(XEN) ioapic_guest_write: Attempt =
to modify IO-APIC pin for in-use IRQ!</div>
<div>PM: Adding info for pnp:00:07</div><div>PM: Adding info for pnp:00:08<=
/div><div>pnp: PnP ACPI: found 9 devices</div><div>xen_mem: Initialising ba=
lloon driver.</div><div>PCI: Using ACPI for IRQ routing</div><div>PCI: If a=
 device doesn&#39;t work, try &quot;pci=3Drouteirq&quot;. &nbsp;If it helps=
, post a report</div>
<div>pnp: 00:01: ioport range 0x800-0x85f could not be reserved</div><div>p=
np: 00:01: ioport range 0xc00-0xc7f has been reserved</div><div>pnp: 00:01:=
 ioport range 0x860-0x8ff has been reserved</div><div>PCI: Ignore bogus res=
ource 6 [0:0] of 0000:00:02.0</div>
<div>PCI: Bridge: 0000:00:01.0</div><div>&nbsp; IO window: disabled.</div><=
div>&nbsp; MEM window: fe500000-fe5fffff</div><div>&nbsp; PREFETCH window: =
disabled.</div><div>PCI: Bridge: 0000:00:1c.0</div><div>&nbsp; IO window: d=
isabled.</div><div>
&nbsp; MEM window: fe400000-fe4fffff</div><div>&nbsp; PREFETCH window: disa=
bled.</div><div>PCI: Bridge: 0000:00:1c.1</div><div>&nbsp; IO window: disab=
led.</div><div>&nbsp; MEM window: fe300000-fe3fffff</div><div>&nbsp; PREFET=
CH window: disabled.</div>
<div>PCI: Bridge: 0000:00:1e.0</div><div>&nbsp; IO window: disabled.</div><=
div>&nbsp; MEM window: disabled.</div><div>&nbsp; PREFETCH window: disabled=
.</div><div>ACPI: PCI Interrupt 0000:00:01.0[A] -&gt; GSI 16 (level, low) -=
&gt; IRQ 16</div>
<div>PCI: Setting latency timer of device 0000:00:01.0 to 64</div><div>ACPI=
: PCI Interrupt 0000:00:1c.0[A] -&gt; GSI 16 (level, low) -&gt; IRQ 16</div=
><div>PCI: Setting latency timer of device 0000:00:1c.0 to 64</div><div>
ACPI: PCI Interrupt 0000:00:1c.1[B] -&gt; GSI 17 (level, low) -&gt; IRQ 17<=
/div><div>PCI: Setting latency timer of device 0000:00:1c.1 to 64</div><div=
>PCI: Setting latency timer of device 0000:00:1e.0 to 64</div><div>NET: Reg=
istered protocol family 2</div>
<div>IP route cache hash table entries: 32768 (order: 5, 131072 bytes)</div=
><div>TCP established hash table entries: 131072 (order: 8, 1048576 bytes)<=
/div><div>TCP bind hash table entries: 65536 (order: 7, 524288 bytes)</div>
<div>TCP: Hash tables configured (established 131072 bind 65536)</div><div>=
TCP reno registered</div><div>PM: Adding info for platform:pcspkr</div><div=
>Simple Boot Flag at 0x7a set to 0x1</div><div>IA-32 Microcode Update Drive=
r: v1.14a-xen &lt;<a href=3D"mailto:tigran@veritas.com">tigran@veritas.com<=
/a>&gt;</div>
<div>audit: initializing netlink socket (disabled)</div><div>audit(13344610=
10.944:1): initialized</div><div>highmem bounce pool size: 64 pages</div><d=
iv>VFS: Disk quotas dquot_6.5.1</div><div>Dquot-cache hash table entries: 1=
024 (order 0, 4096 bytes)</div>
<div>Initializing Cryptographic API</div><div>io scheduler noop registered<=
/div><div>io scheduler anticipatory registered</div><div>io scheduler deadl=
ine registered</div><div>io scheduler cfq registered (default)</div><div>
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001</div><div>PM: =
Adding info for platform:vesafb.0</div><div>Floppy drive(s): fd0 is 1.44M</=
div><div>floppy0: Unable to grab DMA2 for the floppy driver</div><div>flopp=
y0: no floppy controllers found</div>
<div>RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize=
</div><div>loop: loaded (max 8 devices)</div><div>e1000e: Intel(R) PRO/1000=
 Network Driver - 0.3.3.3-k4</div><div>e1000e: Copyright (c) 1999-2008 Inte=
l Corporation.</div>
<div>ACPI: PCI Interrupt 0000:00:19.0[A] -&gt; GSI 21 (level, low) -&gt; IR=
Q 18</div><div>PCI: Setting latency timer of device 0000:00:19.0 to 64</div=
><div>(XEN) physdev.c:155: dom0: wrong map_pirq type 3</div><div>eth0: (PCI=
 Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54</div>
<div>eth0: Intel(R) PRO/1000 Network Connection</div><div>eth0: MAC: 7, PHY=
: 8, PBA No: 2021ff-0ff</div><div>Intel(R) Gigabit Ethernet Network Driver =
- version 1.2.45-k2</div><div>Copyright (c) 2008 Intel Corporation.</div>
<div>ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 1.3.56=
.5-NAPI</div><div>Copyright (c) 1999-2008 Intel Corporation.</div><div>Xen =
virtual console successfully installed as xvc0</div><div>Event-channel devi=
ce installed.</div>
<div>blktap_device_init: blktap device major 254</div><div>blktap_ring_init=
: blktap ring major: 253</div><div>netfront: Initialising virtual ethernet =
driver.</div><div>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2<=
/div>
<div>ide: Assuming 33MHz system bus speed for PIO modes; override with ideb=
us=3Dxx</div><div>PNP: No PS/2 controller found. Probing ports directly.</d=
iv><div>PM: Adding info for platform:i8042</div><div>serio: i8042 AUX port =
at 0x60,0x64 irq 12</div>
<div>PM: Adding info for serio:serio0</div><div>serio: i8042 KBD port at 0x=
60,0x64 irq 1</div><div>PM: Adding info for serio:serio1</div><div>mice: PS=
/2 mouse device common for all mice</div><div>md: md driver 0.90.3 MAX_MD_D=
EVS=3D256, MD_SB_DISKS=3D27</div>
<div>md: bitmap version 4.39</div><div>NET: Registered protocol family 1</d=
iv><div>NET: Registered protocol family 17</div><div>Using IPI No-Shortcut =
mode</div><div>PCI IO multiplexer device installed.</div><div>ACPI: (suppor=
ts S0 S1 S3 S4 S5)</div>
<div>BIOS EDD facility v0.16 2004-Jun-25, 1 devices found</div><div>Freeing=
 unused kernel memory: 204k freed</div><div><b>usbcore: disagrees about ver=
sion of symbol HYPERVISOR_shared_info</b></div><div>usbcore: Unknown symbol=
 HYPERVISOR_shared_info</div>
<div>ehci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ehci_hcd: Unkno=
wn symbol usb_free_urb</div><div>ehci_hcd: Unknown symbol usb_hub_tt_clear_=
buffer</div><div>ehci_hcd: Unknown symbol usb_hcd_resume_root_hub</div>
<div>ehci_hcd: Unknown symbol usb_hcd_pci_probe</div><div>ehci_hcd: Unknown=
 symbol usb_calc_bus_time</div><div>ehci_hcd: Unknown symbol usb_hcd_pci_re=
sume</div><div>ehci_hcd: Unknown symbol usb_get_urb</div><div>ehci_hcd: Unk=
nown symbol usb_hcd_giveback_urb</div>
<div>ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>ehci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ehci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>ehci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>
<div>ohci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ohci_hcd: Unkno=
wn symbol usb_hcd_resume_root_hub</div><div>ohci_hcd: Unknown symbol usb_hc=
d_pci_probe</div><div>ohci_hcd: Unknown symbol usb_disabled</div><div>ohci_=
hcd: Unknown symbol usb_calc_bus_time</div>
<div>ohci_hcd: Unknown symbol usb_hcd_pci_resume</div><div>ohci_hcd: Unknow=
n symbol usb_hcd_giveback_urb</div><div>ohci_hcd: Unknown symbol usb_hcd_su=
spend_root_hub</div><div>ohci_hcd: disagrees about version of symbol HYPERV=
ISOR_shared_info</div>
<div>ohci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ohci_hcd: Un=
known symbol usb_hcd_pci_remove</div><div>ohci_hcd: Unknown symbol usb_root=
_hub_lost_power</div><div>uhci_hcd: Unknown symbol usb_hcd_pci_suspend</div=
>
<div>uhci_hcd: Unknown symbol usb_hcd_resume_root_hub</div><div>uhci_hcd: U=
nknown symbol usb_hcd_pci_probe</div><div>uhci_hcd: Unknown symbol usb_chec=
k_bandwidth</div><div>uhci_hcd: Unknown symbol usb_disabled</div><div>uhci_=
hcd: Unknown symbol usb_release_bandwidth</div>
<div>uhci_hcd: Unknown symbol usb_claim_bandwidth</div><div>uhci_hcd: Unkno=
wn symbol usb_hcd_pci_resume</div><div>uhci_hcd: Unknown symbol usb_hcd_giv=
eback_urb</div><div>uhci_hcd: Unknown symbol usb_hcd_poll_rh_status</div>
<div>uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>uhci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>uhci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>uhci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>
<div>scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>scsi_mod: Unknown symbol HYPERVISOR_shared_info</div><div>sd_mod: Un=
known symbol scsi_print_sense_hdr</div><div>sd_mod: Unknown symbol scsi_mod=
e_sense</div>
<div>sd_mod: Unknown symbol scsi_device_get</div><div>sd_mod: Unknown symbo=
l scsi_get_sense_info_fld</div><div>sd_mod: Unknown symbol scsicam_bios_par=
am</div><div>sd_mod: Unknown symbol scsi_command_normalize_sense</div><div>
sd_mod: Unknown symbol scsi_test_unit_ready</div><div>sd_mod: Unknown symbo=
l scsi_block_when_processing_errors</div><div>sd_mod: Unknown symbol scsi_r=
egister_driver</div><div>sd_mod: Unknown symbol scsi_ioctl</div><div>sd_mod=
: Unknown symbol scsi_nonblockable_ioctl</div>
<div>sd_mod: Unknown symbol scsi_device_put</div><div>sd_mod: Unknown symbo=
l scsi_logging_level</div><div>sd_mod: Unknown symbol scsi_execute_req</div=
><div>sd_mod: Unknown symbol scsi_mode_select</div><div>sd_mod: Unknown sym=
bol scsi_print_sense</div>
<div>sd_mod: Unknown symbol scsi_io_completion</div><div>sd_mod: Unknown sy=
mbol scsi_set_medium_removal</div><div>libata: Unknown symbol scsi_device_g=
et</div><div>libata: Unknown symbol scsi_remove_host</div><div>libata: Unkn=
own symbol scsi_schedule_eh</div>
<div>libata: Unknown symbol scsi_device_set_state</div><div>libata: Unknown=
 symbol scsi_eh_finish_cmd</div><div>libata: Unknown symbol scsi_device_put=
</div><div>libata: Unknown symbol scsi_eh_flush_done_q</div><div>libata: Un=
known symbol scsi_host_put</div>
<div>libata: Unknown symbol scsi_add_host</div><div>libata: Unknown symbol =
scsi_rescan_device</div><div>libata: Unknown symbol scsi_adjust_queue_depth=
</div><div>libata: Unknown symbol scsi_execute_req</div><div>libata: Unknow=
n symbol scsi_req_abort_cmd</div>
<div>libata: disagrees about version of symbol HYPERVISOR_shared_info</div>=
<div>libata: Unknown symbol HYPERVISOR_shared_info</div><div>libata: Unknow=
n symbol scsi_remove_device</div><div>libata: Unknown symbol scsi_host_allo=
c</div>
<div>libata: Unknown symbol __scsi_add_device</div><div>ahci: Unknown symbo=
l ata_scsi_ioctl</div><div>ahci: Unknown symbol ata_port_abort</div><div>ah=
ci: Unknown symbol ata_std_bios_param</div><div>ahci: Unknown symbol ata_st=
d_postreset</div>
<div>ahci: Unknown symbol ata_scsi_device_resume</div><div>ahci: Unknown sy=
mbol ata_scsi_device_suspend</div><div>ahci: Unknown symbol ata_tf_from_fis=
</div><div>ahci: Unknown symbol ata_qc_complete_multiple</div><div>ahci: Un=
known symbol ata_noop_dev_select</div>
<div>ahci: Unknown symbol ata_tf_to_fis</div><div>ahci: Unknown symbol ata_=
pci_device_do_resume</div><div>ahci: Unknown symbol ata_dev_classify</div><=
div>ahci: Unknown symbol ata_scsi_release</div><div>ahci: Unknown symbol at=
a_port_offline</div>
<div>ahci: Unknown symbol ata_scsi_change_queue_depth</div><div>ahci: Unkno=
wn symbol sata_std_hardreset</div><div>ahci: Unknown symbol ata_pci_device_=
suspend</div><div>ahci: Unknown symbol scsi_host_put</div><div>ahci: Unknow=
n symbol ata_port_online</div>
<div>ahci: Unknown symbol ata_wait_register</div><div>ahci: Unknown symbol =
ata_busy_sleep</div><div>ahci: Unknown symbol ata_scsi_slave_config</div><d=
iv>ahci: Unknown symbol ata_port_detach</div><div>ahci: Unknown symbol ata_=
port_disable</div>
<div>ahci: Unknown symbol ata_scsi_queuecmd</div><div>ahci: Unknown symbol =
ata_scsi_slave_destroy</div><div>ahci: Unknown symbol ata_ratelimit</div><d=
iv>ahci: Unknown symbol ata_host_set_resume</div><div>ahci: Unknown symbol =
ata_do_eh</div>
<div>ahci: Unknown symbol ata_port_freeze</div><div>ahci: Unknown symbol at=
a_std_prereset</div><div>ahci: Unknown symbol ata_device_add</div><div>&nbs=
p; &nbsp; &nbsp;</div><div><br></div><div><br></div>-- <br>Best Regards,<di=
v>Bei Guan</div>
<br>

--0016e6d77d7f7406d904bda9308d--


--===============7701379240379758479==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7701379240379758479==--


From xen-devel-bounces@lists.xen.org Sat Apr 14 20:11:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 20:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ9JR-00067S-Ea; Sat, 14 Apr 2012 20:11:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1SJ9JP-00067J-HV
	for xen-devel@lists.xen.org; Sat, 14 Apr 2012 20:11:12 +0000
Received: from [85.158.143.99:53966] by server-3.bemta-4.messagelabs.com id
	A8/D8-05853-ED9D98F4; Sat, 14 Apr 2012 20:11:10 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334434267!25101215!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22427 invoked from network); 14 Apr 2012 20:11:07 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 20:11:07 -0000
Received: by werp12 with SMTP id p12so3256531wer.32
	for <xen-devel@lists.xen.org>; Sat, 14 Apr 2012 13:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=SotwHRcl8Uo/rBDuk2CGrtgUhO8nowHmEO5u8Ec3cSA=;
	b=BDbq9oFaqTFvKVi1IdoxQjjmappSUGruKSvPjuGDBZARuATg7OBljjgr6WzR/RuI+q
	kyMEDkO70hMya+Akf9yj3G2Tr1dKrN/10T/nC+s2XKcaim7Rx/rW71Q3FFa4qbATw+yu
	2+AJATUIe1q3Paa2mVlKmjMKX1KU4xrgPrp+0/MSBv047aHomrvAuI0wJUkIwlpDgFcT
	ESUIDrNkB9dFjsfRd2uvhbT8Qo2QMs3EeoOMvvHHd/CYtRU2idltytnsf/zH4BdD4EZ2
	fYd0/VMtOAlmTldHfrpXdCGsAJCF/WUHMM9qvzhwOumjtVVW214Lkb0zlDw5zNDayuxM
	VbTw==
MIME-Version: 1.0
Received: by 10.216.134.24 with SMTP id r24mr3494099wei.84.1334434266875; Sat,
	14 Apr 2012 13:11:06 -0700 (PDT)
Received: by 10.223.123.138 with HTTP; Sat, 14 Apr 2012 13:11:06 -0700 (PDT)
Date: Sun, 15 Apr 2012 04:11:06 +0800
Message-ID: <CAEQjb-SGFkWu6cCMNyeAF8YqA3Hua_9s99OeuO2MsiKysKYkHg@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Error: disagrees about version of symbol
	HYPERVISOR_shared_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7701379240379758479=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7701379240379758479==
Content-Type: multipart/alternative; boundary=0016e6d77d7f7406d904bda9308d

--0016e6d77d7f7406d904bda9308d
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi All,

I want to shared a variable between Dom0 and Xen. I add the variable
into *struct
shared_info* in code file xen/include/public/xen.h and
linux-2.6.18-xen.hg/include/xen/interface/xeb.h.
In Dom0, I use *shared_info_t *s =3D HYPERVISOR_shared_info* to get the val=
ue
of the shared variable.

However, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot into
Dom0. The error from serial port debug is logged as the following.

Could anyone help me figure out the problem? Any suggestion is appreciated.
Thanks a lot.




=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D PuTTY log 2012.04.15 03:37:=
03
=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D
Restarting system.
(XEN) Domain 0 shutdown: rebooting machine.
 __  __            _  _    _   ____
 \ \/ /___ _ __   | || |  / | |___ \
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/
 /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20=
070925 (Red Hat
4.1.2-33)) Sun Apr 15 03:24:23 CST 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009a800 (usable)
(XEN)  00000000000f0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cd9ffc00 (usable)
(XEN)  00000000cd9ffc00 - 00000000cda53c00 (ACPI NVS)
(XEN)  00000000cda53c00 - 00000000cda55c00 (ACPI data)
(XEN)  00000000cda55c00 - 00000000d0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fed00400 (reserved)
(XEN)  00000000fed20000 - 00000000feda0000 (reserved)
(XEN)  00000000fee00000 - 00000000fef00000 (reserved)
(XEN)  00000000ffb00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000128000000 (usable)
(XEN) System RAM: 3929MB (4023908kB)
(XEN) ACPI: RSDP 000FEC00, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000FC7CB, 009C (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL    B10K          15 ASL        61)
(XEN) ACPI: DSDT FFE9CFF8, 54AD (r1   DELL    dt_ex     1000 INTL 20050624)
(XEN) ACPI: FACS CD9FFC00, 0040
(XEN) ACPI: SSDT FFEA25C4, 00AA (r1   DELL    st_ex     1000 INTL 20050624)
(XEN) ACPI: APIC 000FC9EF, 0092 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: ASF! 000FCAA9, 0096 (r32 DELL    B10K          15 ASL        61=
)
(XEN) ACPI: MCFG 000FCB3F, 003E (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: TCPA 000FCDD9, 0032 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: DMAR 000FCE0B, 0120 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL    B10K          15 ASL        61)
(XEN) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm  Cpu0Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm  Cpu1Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm  Cpu2Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA0085B, 01B7 (r1 DpgPmm  Cpu3Ist       11 INTL 20050624)
(XEN) ACPI: SSDT CDA00C64, 0190 (r1 DpgPmm    CpuPm       10 INTL 20050624)
(XEN) Xen heap: 9MB (9768kB)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) Processor #2 7:7 APIC version 20
(XEN) Processor #3 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2660.080 MHz processor.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 32-bit, PAE, lsb
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc0100000 -> 0xc04c923c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000124000000->0000000125000000 (953327 pages to
be allocated)
(XEN)  Init. ramdisk: 00000001278fe000->0000000127fff400
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: c0100000->c04c923c
(XEN)  Init. ramdisk: c04ca000->c0bcb400
(XEN)  Phys-Mach map: c0bcc000->c0f74bc4
(XEN)  Start info:    c0f75000->c0f7547c
(XEN)  Page tables:   c0f76000->c0f85000
(XEN)  Boot stack:    c0f85000->c0f86000
(XEN)  TOTAL:         c0000000->c1400000
(XEN)  ENTRY ADDRESS: c0100000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault
addr ffffff000, iommu reg =3D fff16000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 184kB init memory.
Linux version 2.6.18.8-xen (root@localhost.localdomain) (gcc =E7=89=88=E6=
=9C=AC 4.1.2
20070925 (Red Hat 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000eaaf1000 (usable)
3026MB HIGHMEM available.
727MB LOWMEM available.
NX (Execute Disable) protection: active
On node 0 totalpages: 961265
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 182270 pages, LIFO batch:31
  HighMem zone: 774899 pages, LIFO batch:31
found SMP MP-table at 000fe710
DMI 2.5 present.
ACPI: RSDP (v002 DELL                                  ) @ 0x000fec00
ACPI: XSDT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc7cb
ACPI: FADT (v003 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc8fb
ACPI: SSDT (v001   DELL    st_ex 0x00001000 INTL 0x20050624) @ 0xffea25c4
ACPI: MADT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc9ef
ACPI: BOOT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fca81
ACPI: ASF! (v032 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcaa9
ACPI: MCFG (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb3f
ACPI: HPET (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb7d
ACPI: TCPA (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcdd9
  >>> ERROR: Invalid checksum
ACPI: DMAR (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fce0b
ACPI: SLIC (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcbb5
ACPI: SSDT (v001 DpgPmm  Cpu0Ist 0x00000011 INTL 0x20050624) @ 0xcd9ffc40
ACPI: SSDT (v001 DpgPmm  Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049
ACPI: SSDT (v001 DpgPmm  Cpu2Ist 0x00000011 INTL 0x20050624) @ 0xcda00452
ACPI: SSDT (v001 DpgPmm  Cpu3Ist 0x00000011 INTL 0x20050624) @ 0xcda0085b
ACPI: SSDT (v001 DpgPmm    CpuPm 0x00000010 INTL 0x20050624) @ 0xcda00c64
ACPI: DSDT (v001   DELL    dt_ex 0x00001000 INTL 0x20050624) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at d1000000 (gap: d0000000:10000000)
Detected 2660.681 MHz processor.
Built 1 zonelists.  Total pages: 961265
Kernel command line: ro root=3D/dev/sda11 console=3Dhvc0 console=3Dtty0
console=3DttyS0,115200n8 debug selinux=3D0
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Xen reported: 2660.080 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Software IO TLB enabled:
 Aperture:     64 megabytes
 Kernel range: c31fd000 - c71fd000
 Address size: 27 bits
vmalloc area: ee000000-f51fe000, maxmem 2d7fe000
Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,
908k data, 204k init, 3099596k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok=
.
Calibrating delay using timer specific routine.. 5347.97 BogoMIPS
(lpj=3D26739870)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
ACPI: Core revision 20060707
ENABLING IO-APIC IRQs
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
Brought up 4 CPUs
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000<6>Initializing CPU#3

CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000
CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
80080281 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
00000000 00000000
migration_cost=3D12
checking if image is initramfs... it is
Freeing initrd memory: 7173k freed
PM: Adding info for No Bus:platform
NET: Registered protocol family 16
PM: Adding info for No Bus:xen
PM: Adding info for No Bus:xen-backend
ACPI: bus type pci registered
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
PCI: MCFG area at e0000000 reserved in E820
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
PM: Adding info for acpi:acpi
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PM: Adding info for No Bus:pci0000:00
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:00:02.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
PM: Adding info for pci:0000:00:00.0
PM: Adding info for pci:0000:00:01.0
PM: Adding info for pci:0000:00:02.0
PM: Adding info for pci:0000:00:02.1
PM: Adding info for pci:0000:00:03.0
PM: Adding info for pci:0000:00:03.2
PM: Adding info for pci:0000:00:03.3
PM: Adding info for pci:0000:00:19.0
PM: Adding info for pci:0000:00:1a.0
PM: Adding info for pci:0000:00:1a.1
PM: Adding info for pci:0000:00:1a.2
PM: Adding info for pci:0000:00:1a.7
PM: Adding info for pci:0000:00:1b.0
PM: Adding info for pci:0000:00:1c.0
PM: Adding info for pci:0000:00:1c.1
PM: Adding info for pci:0000:00:1d.0
PM: Adding info for pci:0000:00:1d.1
PM: Adding info for pci:0000:00:1d.2
PM: Adding info for pci:0000:00:1d.7
PM: Adding info for pci:0000:00:1e.0
PM: Adding info for pci:0000:00:1f.0
PM: Adding info for pci:0000:00:1f.2
PM: Adding info for pci:0000:00:1f.3
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled=
.
ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
PM: Adding info for No Bus:pnp0
PM: Adding info for pnp:00:00
PM: Adding info for pnp:00:01
PM: Adding info for pnp:00:02
PM: Adding info for pnp:00:03
PM: Adding info for pnp:00:04
PM: Adding info for pnp:00:05
PM: Adding info for pnp:00:06
(XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4
(XEN) ioapic_guest_write: new_entry=3D000109f1
(XEN) ioapic_guest_write: old_entry=3D000009f1 pirq=3D4
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
PM: Adding info for pnp:00:07
PM: Adding info for pnp:00:08
pnp: PnP ACPI: found 9 devices
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=3Drouteirq".  If it helps, post a
report
pnp: 00:01: ioport range 0x800-0x85f could not be reserved
pnp: 00:01: ioport range 0xc00-0xc7f has been reserved
pnp: 00:01: ioport range 0x860-0x8ff has been reserved
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: fe500000-fe5fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: fe400000-fe4fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: disabled.
  MEM window: fe300000-fe3fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
PM: Adding info for platform:pcspkr
Simple Boot Flag at 0x7a set to 0x1
IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1334461010.944:1): initialized
highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
PM: Adding info for platform:vesafb.0
Floppy drive(s): fd0 is 1.44M
floppy0: Unable to grab DMA2 for the floppy driver
floppy0: no floppy controllers found
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k4
e1000e: Copyright (c) 1999-2008 Intel Corporation.
ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 21 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:19.0 to 64
(XEN) physdev.c:155: dom0: wrong map_pirq type 3
eth0: (PCI Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54
eth0: Intel(R) PRO/1000 Network Connection
eth0: MAC: 7, PHY: 8, PBA No: 2021ff-0ff
Intel(R) Gigabit Ethernet Network Driver - version 1.2.45-k2
Copyright (c) 2008 Intel Corporation.
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version
1.3.56.5-NAPI
Copyright (c) 1999-2008 Intel Corporation.
Xen virtual console successfully installed as xvc0
Event-channel device installed.
blktap_device_init: blktap device major 254
blktap_ring_init: blktap ring major: 253
netfront: Initialising virtual ethernet driver.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=3D=
xx
PNP: No PS/2 controller found. Probing ports directly.
PM: Adding info for platform:i8042
serio: i8042 AUX port at 0x60,0x64 irq 12
PM: Adding info for serio:serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
PM: Adding info for serio:serio1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
md: bitmap version 4.39
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
PCI IO multiplexer device installed.
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 204k freed
*usbcore: disagrees about version of symbol HYPERVISOR_shared_info*
usbcore: Unknown symbol HYPERVISOR_shared_info
ehci_hcd: Unknown symbol usb_hcd_pci_suspend
ehci_hcd: Unknown symbol usb_free_urb
ehci_hcd: Unknown symbol usb_hub_tt_clear_buffer
ehci_hcd: Unknown symbol usb_hcd_resume_root_hub
ehci_hcd: Unknown symbol usb_hcd_pci_probe
ehci_hcd: Unknown symbol usb_calc_bus_time
ehci_hcd: Unknown symbol usb_hcd_pci_resume
ehci_hcd: Unknown symbol usb_get_urb
ehci_hcd: Unknown symbol usb_hcd_giveback_urb
ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
ehci_hcd: Unknown symbol HYPERVISOR_shared_info
ehci_hcd: Unknown symbol usb_hcd_pci_remove
ehci_hcd: Unknown symbol usb_root_hub_lost_power
ohci_hcd: Unknown symbol usb_hcd_pci_suspend
ohci_hcd: Unknown symbol usb_hcd_resume_root_hub
ohci_hcd: Unknown symbol usb_hcd_pci_probe
ohci_hcd: Unknown symbol usb_disabled
ohci_hcd: Unknown symbol usb_calc_bus_time
ohci_hcd: Unknown symbol usb_hcd_pci_resume
ohci_hcd: Unknown symbol usb_hcd_giveback_urb
ohci_hcd: Unknown symbol usb_hcd_suspend_root_hub
ohci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
ohci_hcd: Unknown symbol HYPERVISOR_shared_info
ohci_hcd: Unknown symbol usb_hcd_pci_remove
ohci_hcd: Unknown symbol usb_root_hub_lost_power
uhci_hcd: Unknown symbol usb_hcd_pci_suspend
uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
uhci_hcd: Unknown symbol usb_hcd_pci_probe
uhci_hcd: Unknown symbol usb_check_bandwidth
uhci_hcd: Unknown symbol usb_disabled
uhci_hcd: Unknown symbol usb_release_bandwidth
uhci_hcd: Unknown symbol usb_claim_bandwidth
uhci_hcd: Unknown symbol usb_hcd_pci_resume
uhci_hcd: Unknown symbol usb_hcd_giveback_urb
uhci_hcd: Unknown symbol usb_hcd_poll_rh_status
uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
uhci_hcd: Unknown symbol HYPERVISOR_shared_info
uhci_hcd: Unknown symbol usb_hcd_pci_remove
uhci_hcd: Unknown symbol usb_root_hub_lost_power
scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info
scsi_mod: Unknown symbol HYPERVISOR_shared_info
sd_mod: Unknown symbol scsi_print_sense_hdr
sd_mod: Unknown symbol scsi_mode_sense
sd_mod: Unknown symbol scsi_device_get
sd_mod: Unknown symbol scsi_get_sense_info_fld
sd_mod: Unknown symbol scsicam_bios_param
sd_mod: Unknown symbol scsi_command_normalize_sense
sd_mod: Unknown symbol scsi_test_unit_ready
sd_mod: Unknown symbol scsi_block_when_processing_errors
sd_mod: Unknown symbol scsi_register_driver
sd_mod: Unknown symbol scsi_ioctl
sd_mod: Unknown symbol scsi_nonblockable_ioctl
sd_mod: Unknown symbol scsi_device_put
sd_mod: Unknown symbol scsi_logging_level
sd_mod: Unknown symbol scsi_execute_req
sd_mod: Unknown symbol scsi_mode_select
sd_mod: Unknown symbol scsi_print_sense
sd_mod: Unknown symbol scsi_io_completion
sd_mod: Unknown symbol scsi_set_medium_removal
libata: Unknown symbol scsi_device_get
libata: Unknown symbol scsi_remove_host
libata: Unknown symbol scsi_schedule_eh
libata: Unknown symbol scsi_device_set_state
libata: Unknown symbol scsi_eh_finish_cmd
libata: Unknown symbol scsi_device_put
libata: Unknown symbol scsi_eh_flush_done_q
libata: Unknown symbol scsi_host_put
libata: Unknown symbol scsi_add_host
libata: Unknown symbol scsi_rescan_device
libata: Unknown symbol scsi_adjust_queue_depth
libata: Unknown symbol scsi_execute_req
libata: Unknown symbol scsi_req_abort_cmd
libata: disagrees about version of symbol HYPERVISOR_shared_info
libata: Unknown symbol HYPERVISOR_shared_info
libata: Unknown symbol scsi_remove_device
libata: Unknown symbol scsi_host_alloc
libata: Unknown symbol __scsi_add_device
ahci: Unknown symbol ata_scsi_ioctl
ahci: Unknown symbol ata_port_abort
ahci: Unknown symbol ata_std_bios_param
ahci: Unknown symbol ata_std_postreset
ahci: Unknown symbol ata_scsi_device_resume
ahci: Unknown symbol ata_scsi_device_suspend
ahci: Unknown symbol ata_tf_from_fis
ahci: Unknown symbol ata_qc_complete_multiple
ahci: Unknown symbol ata_noop_dev_select
ahci: Unknown symbol ata_tf_to_fis
ahci: Unknown symbol ata_pci_device_do_resume
ahci: Unknown symbol ata_dev_classify
ahci: Unknown symbol ata_scsi_release
ahci: Unknown symbol ata_port_offline
ahci: Unknown symbol ata_scsi_change_queue_depth
ahci: Unknown symbol sata_std_hardreset
ahci: Unknown symbol ata_pci_device_suspend
ahci: Unknown symbol scsi_host_put
ahci: Unknown symbol ata_port_online
ahci: Unknown symbol ata_wait_register
ahci: Unknown symbol ata_busy_sleep
ahci: Unknown symbol ata_scsi_slave_config
ahci: Unknown symbol ata_port_detach
ahci: Unknown symbol ata_port_disable
ahci: Unknown symbol ata_scsi_queuecmd
ahci: Unknown symbol ata_scsi_slave_destroy
ahci: Unknown symbol ata_ratelimit
ahci: Unknown symbol ata_host_set_resume
ahci: Unknown symbol ata_do_eh
ahci: Unknown symbol ata_port_freeze
ahci: Unknown symbol ata_std_prereset
ahci: Unknown symbol ata_device_add



--=20
Best Regards,
Bei Guan

--0016e6d77d7f7406d904bda9308d
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div>Hi All,</div><div><br></div><div>I want to shared a variable between D=
om0 and Xen. I add the variable into <b>struct shared_info</b> in code file=
 xen/include/public/xen.h and linux-2.6.18-xen.hg/include/xen/interface/xeb=
.h.</div>
<div>In Dom0, I use <b>shared_info_t *s =3D HYPERVISOR_shared_info</b> to g=
et the value of the shared variable.&nbsp;</div><div><br></div><div>However=
, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot into Dom0.&=
nbsp;The error from serial port debug is logged as the following.</div>
<div><br></div><div>Could anyone help me figure out the problem? Any sugges=
tion is appreciated. Thanks a lot.</div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div>=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=
=3D PuTTY log 2012.04.15 03:37:03 =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=
=3D~=3D</div>
<div>Restarting system.</div><div>(XEN) Domain 0 shutdown: rebooting machin=
e.</div><div>&nbsp;__ &nbsp;__ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;_ &=
nbsp;_ &nbsp; &nbsp;_ &nbsp; ____ &nbsp;</div><div>&nbsp;\ \/ /___ _ __ &nb=
sp; | || | &nbsp;/ | |___ \&nbsp;</div><div>&nbsp; \ &nbsp;// _ \ &#39;_ \ =
&nbsp;| || |_ | | &nbsp; __) |</div>
<div>&nbsp; / &nbsp;\ &nbsp;__/ | | | |__ &nbsp; _|| |_ / __/&nbsp;</div><d=
iv>&nbsp;/_/\_\___|_| |_| &nbsp; &nbsp;|_|(_)_(_)_____|</div><div>&nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</div><div>(XEN) Xen versio=
n 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red Hat =
4.1.2-33)) Sun Apr 15 03:24:23 CST 2012</div>
<div>(XEN) Latest ChangeSet: unavailable</div><div>(XEN) Bootloader: GNU GR=
UB 0.97</div><div>(XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1<=
/div><div>(XEN) Video information:</div><div>(XEN) &nbsp;VGA is text mode 8=
0x25, font 8x16</div>
<div>(XEN) &nbsp;VBE/DDC methods: V2; EDID transfer time: 1 seconds</div><d=
iv>(XEN) Disc information:</div><div>(XEN) &nbsp;Found 1 MBR signatures</di=
v><div>(XEN) &nbsp;Found 1 EDD information structures</div><div>(XEN) Xen-e=
820 RAM map:</div>
<div>(XEN) &nbsp;0000000000000000 - 000000000009a800 (usable)</div><div>(XE=
N) &nbsp;00000000000f0000 - 0000000000100000 (reserved)</div><div>(XEN) &nb=
sp;0000000000100000 - 00000000cd9ffc00 (usable)</div><div>(XEN) &nbsp;00000=
000cd9ffc00 - 00000000cda53c00 (ACPI NVS)</div>
<div>(XEN) &nbsp;00000000cda53c00 - 00000000cda55c00 (ACPI data)</div><div>=
(XEN) &nbsp;00000000cda55c00 - 00000000d0000000 (reserved)</div><div>(XEN) =
&nbsp;00000000e0000000 - 00000000f0000000 (reserved)</div><div>(XEN) &nbsp;=
00000000fec00000 - 00000000fed00400 (reserved)</div>
<div>(XEN) &nbsp;00000000fed20000 - 00000000feda0000 (reserved)</div><div>(=
XEN) &nbsp;00000000fee00000 - 00000000fef00000 (reserved)</div><div>(XEN) &=
nbsp;00000000ffb00000 - 0000000100000000 (reserved)</div><div>(XEN) &nbsp;0=
000000100000000 - 0000000128000000 (usable)</div>
<div>(XEN) System RAM: 3929MB (4023908kB)</div><div>(XEN) ACPI: RSDP 000FEC=
00, 0024 (r2 DELL &nbsp;)</div><div>(XEN) ACPI: XSDT 000FC7CB, 009C (r1 DEL=
L &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; =
&nbsp; &nbsp;61)</div><div>(XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL &nbsp; =
&nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &n=
bsp;61)</div>
<div>(XEN) ACPI: DSDT FFE9CFF8, 54AD (r1 &nbsp; DELL &nbsp; &nbsp;dt_ex &nb=
sp; &nbsp; 1000 INTL 20050624)</div><div>(XEN) ACPI: FACS CD9FFC00, 0040</d=
iv><div>(XEN) ACPI: SSDT FFEA25C4, 00AA (r1 &nbsp; DELL &nbsp; &nbsp;st_ex =
&nbsp; &nbsp; 1000 INTL 20050624)</div><div>(XEN) ACPI: APIC 000FC9EF, 0092=
 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 ASL &nbsp;=
 &nbsp; &nbsp; &nbsp;61)</div>
<div>(XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN=
) ACPI: ASF! 000FCAA9, 0096 (r32 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN) ACPI: =
MCFG 000FCB3F, 003E (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div>
<div>(XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN=
) ACPI: TCPA 000FCDD9, 0032 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN) ACPI: D=
MAR 000FCE0B, 0120 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div>
<div>(XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL &nbsp; &nbsp;B10K &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;15 ASL &nbsp; &nbsp; &nbsp; &nbsp;61)</div><div>(XEN=
) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm &nbsp;Cpu0Ist &nbsp; &nbsp; &nbsp; 1=
1 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm &nbsp=
;Cpu1Ist &nbsp; &nbsp; &nbsp; 11 INTL 20050624)</div>
<div>(XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm &nbsp;Cpu2Ist &nbsp; &nbsp;=
 &nbsp; 11 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA0085B, 01B7 (r1 Dpg=
Pmm &nbsp;Cpu3Ist &nbsp; &nbsp; &nbsp; 11 INTL 20050624)</div><div>(XEN) AC=
PI: SSDT CDA00C64, 0190 (r1 DpgPmm &nbsp; &nbsp;CpuPm &nbsp; &nbsp; &nbsp; =
10 INTL 20050624)</div>
<div>(XEN) Xen heap: 9MB (9768kB)</div><div>(XEN) Domain heap initialised</=
div><div>(XEN) Processor #0 7:7 APIC version 20</div><div>(XEN) Processor #=
1 7:7 APIC version 20</div><div>(XEN) Processor #2 7:7 APIC version 20</div=
>
<div>(XEN) Processor #3 7:7 APIC version 20</div><div>(XEN) IOAPIC[0]: apic=
_id 8, version 32, address 0xfec00000, GSI 0-23</div><div>(XEN) Enabling AP=
IC mode: &nbsp;Flat. &nbsp;Using 1 I/O APICs</div><div>(XEN) Table is not f=
ound!</div>
<div>(XEN) Using scheduler: SMP Credit Scheduler (credit)</div><div>(XEN) D=
etected 2660.080 MHz processor.</div><div>(XEN) Intel VT-d Snoop Control no=
t enabled.</div><div>(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.</di=
v>
<div>(XEN) Intel VT-d Queued Invalidation not enabled.</div><div>(XEN) Inte=
l VT-d Interrupt Remapping not enabled.</div><div>(XEN) Intel VT-d Shared E=
PT tables not enabled.</div><div>(XEN) I/O virtualisation enabled</div>
<div>(XEN) &nbsp;- Dom0 mode: Relaxed</div><div>(XEN) ENABLING IO-APIC IRQs=
</div><div>(XEN) &nbsp;-&gt; Using new ACK method</div><div>(XEN) Platform =
timer is 14.318MHz HPET</div><div>=FF(XEN) Allocated console ring of 16 KiB=
.</div><div>
(XEN) VMX: Supported advanced features:</div><div>(XEN) &nbsp;- APIC MMIO a=
ccess virtualisation</div><div>(XEN) &nbsp;- APIC TPR shadow</div><div>(XEN=
) &nbsp;- Virtual NMI</div><div>(XEN) &nbsp;- MSR direct-access bitmap</div=
><div>(XEN) HVM: ASIDs disabled.</div>
<div>(XEN) HVM: VMX enabled</div><div>(XEN) Brought up 4 CPUs</div><div>(XE=
N) *** LOADING DOMAIN 0 ***</div><div>(XEN) &nbsp;Xen &nbsp;kernel: 32-bit,=
 PAE, lsb</div><div>(XEN) &nbsp;Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc010=
0000 -&gt; 0xc04c923c</div>
<div>(XEN) PHYSICAL MEMORY ARRANGEMENT:</div><div>(XEN) &nbsp;Dom0 alloc.: =
&nbsp; 0000000124000000-&gt;0000000125000000 (953327 pages to be allocated)=
</div><div>(XEN) &nbsp;Init. ramdisk: 00000001278fe000-&gt;0000000127fff400=
</div><div>
(XEN) VIRTUAL MEMORY ARRANGEMENT:</div><div>(XEN) &nbsp;Loaded kernel: c010=
0000-&gt;c04c923c</div><div>(XEN) &nbsp;Init. ramdisk: c04ca000-&gt;c0bcb40=
0</div><div>(XEN) &nbsp;Phys-Mach map: c0bcc000-&gt;c0f74bc4</div><div>(XEN=
) &nbsp;Start info: &nbsp; &nbsp;c0f75000-&gt;c0f7547c</div>
<div>(XEN) &nbsp;Page tables: &nbsp; c0f76000-&gt;c0f85000</div><div>(XEN) =
&nbsp;Boot stack: &nbsp; &nbsp;c0f85000-&gt;c0f86000</div><div>(XEN) &nbsp;=
TOTAL: &nbsp; &nbsp; &nbsp; &nbsp; c0000000-&gt;c1400000</div><div>(XEN) &n=
bsp;ENTRY ADDRESS: c0100000</div><div>(XEN) Dom0 has maximum 4 VCPUs</div>
<div>(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow</div><div>=
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault</div><di=
v>(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault =
addr ffffff000, iommu reg =3D fff16000</div>
<div>(XEN) DMAR:[fault reason 05h] PTE Write access is not set</div><div>(X=
EN) Scrubbing Free RAM: .done.</div><div>(XEN) Xen trace buffers: disabled<=
/div><div>(XEN) Std. Loglevel: Errors and warnings</div><div>(XEN) Guest Lo=
glevel: Nothing (Rate-limited: Errors and warnings)</div>
<div>(XEN) Xen is relinquishing VGA console.</div><div>(XEN) *** Serial inp=
ut -&gt; DOM0 (type &#39;CTRL-a&#39; three times to switch input to Xen)</d=
iv><div>(XEN) Freed 184kB init memory.</div><div>Linux version 2.6.18.8-xen=
 (root@localhost.localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red H=
at 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012</div>
<div>BIOS-provided physical RAM map:</div><div>&nbsp;Xen: 0000000000000000 =
- 00000000eaaf1000 (usable)</div><div>3026MB HIGHMEM available.</div><div>7=
27MB LOWMEM available.</div><div>NX (Execute Disable) protection: active</d=
iv>
<div>On node 0 totalpages: 961265</div><div>&nbsp; DMA zone: 4096 pages, LI=
FO batch:0</div><div>&nbsp; Normal zone: 182270 pages, LIFO batch:31</div><=
div>&nbsp; HighMem zone: 774899 pages, LIFO batch:31</div><div>found SMP MP=
-table at 000fe710</div>
<div>DMI 2.5 present.</div><div>ACPI: RSDP (v002 DELL &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;) @ 0x000fec00</div><div>ACPI: XSDT (v001 DELL &nbsp;=
 &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x00000061) @ 0x000fc7cb</div=
><div>ACPI: FADT (v003 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &=
nbsp;0x00000061) @ 0x000fc8fb</div>
<div>ACPI: SSDT (v001 &nbsp; DELL &nbsp; &nbsp;st_ex 0x00001000 INTL 0x2005=
0624) @ 0xffea25c4</div><div>ACPI: MADT (v001 DELL &nbsp; &nbsp;B10K &nbsp;=
 &nbsp;0x00000015 ASL &nbsp;0x00000061) @ 0x000fc9ef</div><div>ACPI: BOOT (=
v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x00000061) @=
 0x000fca81</div>
<div>ACPI: ASF! (v032 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &n=
bsp;0x00000061) @ 0x000fcaa9</div><div>ACPI: MCFG (v001 DELL &nbsp; &nbsp;B=
10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x00000061) @ 0x000fcb3f</div><div>AC=
PI: HPET (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0x0=
0000061) @ 0x000fcb7d</div>
<div>ACPI: TCPA (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &n=
bsp;0x00000061) @ 0x000fcdd9</div><div>&nbsp; &gt;&gt;&gt; ERROR: Invalid c=
hecksum</div><div>ACPI: DMAR (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00=
000015 ASL &nbsp;0x00000061) @ 0x000fce0b</div><div>
ACPI: SLIC (v001 DELL &nbsp; &nbsp;B10K &nbsp; &nbsp;0x00000015 ASL &nbsp;0=
x00000061) @ 0x000fcbb5</div><div>ACPI: SSDT (v001 DpgPmm &nbsp;Cpu0Ist 0x0=
0000011 INTL 0x20050624) @ 0xcd9ffc40</div><div>ACPI: SSDT (v001 DpgPmm &nb=
sp;Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049</div>
<div>ACPI: SSDT (v001 DpgPmm &nbsp;Cpu2Ist 0x00000011 INTL 0x20050624) @ 0x=
cda00452</div><div>ACPI: SSDT (v001 DpgPmm &nbsp;Cpu3Ist 0x00000011 INTL 0x=
20050624) @ 0xcda0085b</div><div>ACPI: SSDT (v001 DpgPmm &nbsp; &nbsp;CpuPm=
 0x00000010 INTL 0x20050624) @ 0xcda00c64</div>
<div>ACPI: DSDT (v001 &nbsp; DELL &nbsp; &nbsp;dt_ex 0x00001000 INTL 0x2005=
0624) @ 0x00000000</div><div>ACPI: Local APIC address 0xfee00000</div><div>=
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)</div><div>ACPI: LAPIC (a=
cpi_id[0x02] lapic_id[0x01] enabled)</div>
<div>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)</div><div>ACPI: LAP=
IC (acpi_id[0x04] lapic_id[0x03] enabled)</div><div>ACPI: LAPIC (acpi_id[0x=
05] lapic_id[0x00] disabled)</div><div>ACPI: LAPIC (acpi_id[0x06] lapic_id[=
0x01] disabled)</div>
<div>ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)</div><div>ACPI: LA=
PIC (acpi_id[0x08] lapic_id[0x03] disabled)</div><div>ACPI: LAPIC_NMI (acpi=
_id[0xff] high level lint[0x1])</div><div>ACPI: IOAPIC (id[0x08] address[0x=
fec00000] gsi_base[0])</div>
<div>IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23</div><d=
iv>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)</div><div>ACPI:=
 INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)</div><div>ACPI: IRQ0=
 used by override.</div>
<div>ACPI: IRQ2 used by override.</div><div>ACPI: IRQ9 used by override.</d=
iv><div>Enabling APIC mode: &nbsp;Flat. &nbsp;Using 1 I/O APICs</div><div>U=
sing ACPI (MADT) for SMP configuration information</div><div>Allocating PCI=
 resources starting at d1000000 (gap: d0000000:10000000)</div>
<div>Detected 2660.681 MHz processor.</div><div>Built 1 zonelists. &nbsp;To=
tal pages: 961265</div><div>Kernel command line: ro root=3D/dev/sda11 conso=
le=3Dhvc0 console=3Dtty0 console=3DttyS0,115200n8 debug selinux=3D0</div><d=
iv>Enabling fast FPU save and restore... done.</div>
<div>Enabling unmasked SIMD FPU exception support... done.</div><div>Initia=
lizing CPU#0</div><div>PID hash table entries: 4096 (order: 12, 16384 bytes=
)</div><div>Xen reported: 2660.080 MHz processor.</div><div>Console: colour=
 VGA+ 80x25</div>
<div>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)</div>=
<div>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)</div><d=
iv>Software IO TLB enabled:&nbsp;</div><div>&nbsp;Aperture: &nbsp; &nbsp; 6=
4 megabytes</div>
<div>&nbsp;Kernel range: c31fd000 - c71fd000</div><div>&nbsp;Address size: =
27 bits</div><div>vmalloc area: ee000000-f51fe000, maxmem 2d7fe000</div><di=
v>Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,=
 908k data, 204k init, 3099596k highmem)</div>
<div>Checking if this processor honours the WP bit even in supervisor mode.=
.. Ok.</div><div>Calibrating delay using timer specific routine.. 5347.97 B=
ogoMIPS (lpj=3D26739870)</div><div>Security Framework v1.0.0 initialized</d=
iv>
<div>Capability LSM initialized</div><div>Mount-cache hash table entries: 5=
12</div><div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 =
00000000 80080281 00000000 00000000</div><div>CPU: After vendor identify, c=
aps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div>
<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000</div><div>Checking &#39;hlt&#39; instruction... OK=
.</div>
<div>SMP alternatives: switching to UP code</div><div>ACPI: Core revision 2=
0060707</div><div>ENABLING IO-APIC IRQs</div><div>SMP alternatives: switchi=
ng to SMP code</div><div>Initializing CPU#1</div><div>Initializing CPU#2</d=
iv>
<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>Broug=
ht up 4 CPUs</div>
<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000&lt;6&gt;Initializing CPU#3</div><div><br></div>
<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>CPU: =
L1 I cache: 32K, L1 D cache: 32K</div>
<div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3f5 00=
100000 00000000 00000140 80080281 00000000 00000000</div><div>CPU: After ge=
neric identify, caps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000=
 00000000</div>
<div>CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000 =
80080281 00000000 00000000</div><div>CPU: L1 I cache: 32K, L1 D cache: 32K<=
/div><div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3=
f5 00100000 00000000 00000140 80080281 00000000 00000000</div>
<div>migration_cost=3D12</div><div>checking if image is initramfs... it is<=
/div><div>Freeing initrd memory: 7173k freed</div><div>PM: Adding info for =
No Bus:platform</div><div>NET: Registered protocol family 16</div><div>PM: =
Adding info for No Bus:xen</div>
<div>PM: Adding info for No Bus:xen-backend</div><div>ACPI: bus type pci re=
gistered</div><div>PCI: MCFG configuration 0: base e0000000 segment 0 buses=
 0 - 255</div><div>PCI: MCFG area at e0000000 reserved in E820</div><div>
PCI: Using MMCONFIG</div><div>Setting up standard PCI resources</div><div>A=
CPI: Interpreter enabled</div><div>ACPI: Using IOAPIC for interrupt routing=
</div><div>PM: Adding info for acpi:acpi</div><div>ACPI: PCI Root Bridge [P=
CI0] (0000:00)</div>
<div>PCI: Probing PCI hardware (bus 00)</div><div>PM: Adding info for No Bu=
s:pci0000:00</div><div>ACPI: Assume root bridge [\_SB_.PCI0] bus is 0</div>=
<div>Boot video device is 0000:00:02.0</div><div>PCI: Transparent bridge - =
0000:00:1e.0</div>
<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]</div><div>PM: Addi=
ng info for pci:0000:00:00.0</div><div>PM: Adding info for pci:0000:00:01.0=
</div><div>PM: Adding info for pci:0000:00:02.0</div><div>PM: Adding info f=
or pci:0000:00:02.1</div>
<div>PM: Adding info for pci:0000:00:03.0</div><div>PM: Adding info for pci=
:0000:00:03.2</div><div>PM: Adding info for pci:0000:00:03.3</div><div>PM: =
Adding info for pci:0000:00:19.0</div><div>PM: Adding info for pci:0000:00:=
1a.0</div>
<div>PM: Adding info for pci:0000:00:1a.1</div><div>PM: Adding info for pci=
:0000:00:1a.2</div><div>PM: Adding info for pci:0000:00:1a.7</div><div>PM: =
Adding info for pci:0000:00:1b.0</div><div>PM: Adding info for pci:0000:00:=
1c.0</div>
<div>PM: Adding info for pci:0000:00:1c.1</div><div>PM: Adding info for pci=
:0000:00:1d.0</div><div>PM: Adding info for pci:0000:00:1d.1</div><div>PM: =
Adding info for pci:0000:00:1d.2</div><div>PM: Adding info for pci:0000:00:=
1d.7</div>
<div>PM: Adding info for pci:0000:00:1e.0</div><div>PM: Adding info for pci=
:0000:00:1f.0</div><div>PM: Adding info for pci:0000:00:1f.2</div><div>PM: =
Adding info for pci:0000:00:1f.3</div><div>ACPI: PCI Interrupt Routing Tabl=
e [\_SB_.PCI0.PCI4._PRT]</div>
<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]</div><div>ACP=
I: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]</div><div>ACPI: PCI I=
nterrupt Routing Table [\_SB_.PCI0.PCI1._PRT]</div><div>ACPI: PCI Interrupt=
 Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 15)</div><=
div>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15)</div><d=
iv>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, dis=
abled.</div><div>ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 1=
2 15)</div><div>ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12=
 15)</div>
<div>ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div><=
div>Linux Plug and Play Support v0.97 (c) Adam Belay</div><div>pnp: PnP ACP=
I init</div><div>PM: Adding info for No Bus:pnp0</div><div>PM: Adding info =
for pnp:00:00</div>
<div>PM: Adding info for pnp:00:01</div><div>PM: Adding info for pnp:00:02<=
/div><div>PM: Adding info for pnp:00:03</div><div>PM: Adding info for pnp:0=
0:04</div><div>PM: Adding info for pnp:00:05</div><div>PM: Adding info for =
pnp:00:06</div>
<div>(XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4</div><div>(XEN) i=
oapic_guest_write: new_entry=3D000109f1</div><div>(XEN) ioapic_guest_write:=
 old_entry=3D000009f1 pirq=3D4</div><div>(XEN) ioapic_guest_write: Attempt =
to modify IO-APIC pin for in-use IRQ!</div>
<div>PM: Adding info for pnp:00:07</div><div>PM: Adding info for pnp:00:08<=
/div><div>pnp: PnP ACPI: found 9 devices</div><div>xen_mem: Initialising ba=
lloon driver.</div><div>PCI: Using ACPI for IRQ routing</div><div>PCI: If a=
 device doesn&#39;t work, try &quot;pci=3Drouteirq&quot;. &nbsp;If it helps=
, post a report</div>
<div>pnp: 00:01: ioport range 0x800-0x85f could not be reserved</div><div>p=
np: 00:01: ioport range 0xc00-0xc7f has been reserved</div><div>pnp: 00:01:=
 ioport range 0x860-0x8ff has been reserved</div><div>PCI: Ignore bogus res=
ource 6 [0:0] of 0000:00:02.0</div>
<div>PCI: Bridge: 0000:00:01.0</div><div>&nbsp; IO window: disabled.</div><=
div>&nbsp; MEM window: fe500000-fe5fffff</div><div>&nbsp; PREFETCH window: =
disabled.</div><div>PCI: Bridge: 0000:00:1c.0</div><div>&nbsp; IO window: d=
isabled.</div><div>
&nbsp; MEM window: fe400000-fe4fffff</div><div>&nbsp; PREFETCH window: disa=
bled.</div><div>PCI: Bridge: 0000:00:1c.1</div><div>&nbsp; IO window: disab=
led.</div><div>&nbsp; MEM window: fe300000-fe3fffff</div><div>&nbsp; PREFET=
CH window: disabled.</div>
<div>PCI: Bridge: 0000:00:1e.0</div><div>&nbsp; IO window: disabled.</div><=
div>&nbsp; MEM window: disabled.</div><div>&nbsp; PREFETCH window: disabled=
.</div><div>ACPI: PCI Interrupt 0000:00:01.0[A] -&gt; GSI 16 (level, low) -=
&gt; IRQ 16</div>
<div>PCI: Setting latency timer of device 0000:00:01.0 to 64</div><div>ACPI=
: PCI Interrupt 0000:00:1c.0[A] -&gt; GSI 16 (level, low) -&gt; IRQ 16</div=
><div>PCI: Setting latency timer of device 0000:00:1c.0 to 64</div><div>
ACPI: PCI Interrupt 0000:00:1c.1[B] -&gt; GSI 17 (level, low) -&gt; IRQ 17<=
/div><div>PCI: Setting latency timer of device 0000:00:1c.1 to 64</div><div=
>PCI: Setting latency timer of device 0000:00:1e.0 to 64</div><div>NET: Reg=
istered protocol family 2</div>
<div>IP route cache hash table entries: 32768 (order: 5, 131072 bytes)</div=
><div>TCP established hash table entries: 131072 (order: 8, 1048576 bytes)<=
/div><div>TCP bind hash table entries: 65536 (order: 7, 524288 bytes)</div>
<div>TCP: Hash tables configured (established 131072 bind 65536)</div><div>=
TCP reno registered</div><div>PM: Adding info for platform:pcspkr</div><div=
>Simple Boot Flag at 0x7a set to 0x1</div><div>IA-32 Microcode Update Drive=
r: v1.14a-xen &lt;<a href=3D"mailto:tigran@veritas.com">tigran@veritas.com<=
/a>&gt;</div>
<div>audit: initializing netlink socket (disabled)</div><div>audit(13344610=
10.944:1): initialized</div><div>highmem bounce pool size: 64 pages</div><d=
iv>VFS: Disk quotas dquot_6.5.1</div><div>Dquot-cache hash table entries: 1=
024 (order 0, 4096 bytes)</div>
<div>Initializing Cryptographic API</div><div>io scheduler noop registered<=
/div><div>io scheduler anticipatory registered</div><div>io scheduler deadl=
ine registered</div><div>io scheduler cfq registered (default)</div><div>
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001</div><div>PM: =
Adding info for platform:vesafb.0</div><div>Floppy drive(s): fd0 is 1.44M</=
div><div>floppy0: Unable to grab DMA2 for the floppy driver</div><div>flopp=
y0: no floppy controllers found</div>
<div>RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize=
</div><div>loop: loaded (max 8 devices)</div><div>e1000e: Intel(R) PRO/1000=
 Network Driver - 0.3.3.3-k4</div><div>e1000e: Copyright (c) 1999-2008 Inte=
l Corporation.</div>
<div>ACPI: PCI Interrupt 0000:00:19.0[A] -&gt; GSI 21 (level, low) -&gt; IR=
Q 18</div><div>PCI: Setting latency timer of device 0000:00:19.0 to 64</div=
><div>(XEN) physdev.c:155: dom0: wrong map_pirq type 3</div><div>eth0: (PCI=
 Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54</div>
<div>eth0: Intel(R) PRO/1000 Network Connection</div><div>eth0: MAC: 7, PHY=
: 8, PBA No: 2021ff-0ff</div><div>Intel(R) Gigabit Ethernet Network Driver =
- version 1.2.45-k2</div><div>Copyright (c) 2008 Intel Corporation.</div>
<div>ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 1.3.56=
.5-NAPI</div><div>Copyright (c) 1999-2008 Intel Corporation.</div><div>Xen =
virtual console successfully installed as xvc0</div><div>Event-channel devi=
ce installed.</div>
<div>blktap_device_init: blktap device major 254</div><div>blktap_ring_init=
: blktap ring major: 253</div><div>netfront: Initialising virtual ethernet =
driver.</div><div>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2<=
/div>
<div>ide: Assuming 33MHz system bus speed for PIO modes; override with ideb=
us=3Dxx</div><div>PNP: No PS/2 controller found. Probing ports directly.</d=
iv><div>PM: Adding info for platform:i8042</div><div>serio: i8042 AUX port =
at 0x60,0x64 irq 12</div>
<div>PM: Adding info for serio:serio0</div><div>serio: i8042 KBD port at 0x=
60,0x64 irq 1</div><div>PM: Adding info for serio:serio1</div><div>mice: PS=
/2 mouse device common for all mice</div><div>md: md driver 0.90.3 MAX_MD_D=
EVS=3D256, MD_SB_DISKS=3D27</div>
<div>md: bitmap version 4.39</div><div>NET: Registered protocol family 1</d=
iv><div>NET: Registered protocol family 17</div><div>Using IPI No-Shortcut =
mode</div><div>PCI IO multiplexer device installed.</div><div>ACPI: (suppor=
ts S0 S1 S3 S4 S5)</div>
<div>BIOS EDD facility v0.16 2004-Jun-25, 1 devices found</div><div>Freeing=
 unused kernel memory: 204k freed</div><div><b>usbcore: disagrees about ver=
sion of symbol HYPERVISOR_shared_info</b></div><div>usbcore: Unknown symbol=
 HYPERVISOR_shared_info</div>
<div>ehci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ehci_hcd: Unkno=
wn symbol usb_free_urb</div><div>ehci_hcd: Unknown symbol usb_hub_tt_clear_=
buffer</div><div>ehci_hcd: Unknown symbol usb_hcd_resume_root_hub</div>
<div>ehci_hcd: Unknown symbol usb_hcd_pci_probe</div><div>ehci_hcd: Unknown=
 symbol usb_calc_bus_time</div><div>ehci_hcd: Unknown symbol usb_hcd_pci_re=
sume</div><div>ehci_hcd: Unknown symbol usb_get_urb</div><div>ehci_hcd: Unk=
nown symbol usb_hcd_giveback_urb</div>
<div>ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>ehci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ehci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>ehci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>
<div>ohci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ohci_hcd: Unkno=
wn symbol usb_hcd_resume_root_hub</div><div>ohci_hcd: Unknown symbol usb_hc=
d_pci_probe</div><div>ohci_hcd: Unknown symbol usb_disabled</div><div>ohci_=
hcd: Unknown symbol usb_calc_bus_time</div>
<div>ohci_hcd: Unknown symbol usb_hcd_pci_resume</div><div>ohci_hcd: Unknow=
n symbol usb_hcd_giveback_urb</div><div>ohci_hcd: Unknown symbol usb_hcd_su=
spend_root_hub</div><div>ohci_hcd: disagrees about version of symbol HYPERV=
ISOR_shared_info</div>
<div>ohci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ohci_hcd: Un=
known symbol usb_hcd_pci_remove</div><div>ohci_hcd: Unknown symbol usb_root=
_hub_lost_power</div><div>uhci_hcd: Unknown symbol usb_hcd_pci_suspend</div=
>
<div>uhci_hcd: Unknown symbol usb_hcd_resume_root_hub</div><div>uhci_hcd: U=
nknown symbol usb_hcd_pci_probe</div><div>uhci_hcd: Unknown symbol usb_chec=
k_bandwidth</div><div>uhci_hcd: Unknown symbol usb_disabled</div><div>uhci_=
hcd: Unknown symbol usb_release_bandwidth</div>
<div>uhci_hcd: Unknown symbol usb_claim_bandwidth</div><div>uhci_hcd: Unkno=
wn symbol usb_hcd_pci_resume</div><div>uhci_hcd: Unknown symbol usb_hcd_giv=
eback_urb</div><div>uhci_hcd: Unknown symbol usb_hcd_poll_rh_status</div>
<div>uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>uhci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>uhci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>uhci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>
<div>scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>scsi_mod: Unknown symbol HYPERVISOR_shared_info</div><div>sd_mod: Un=
known symbol scsi_print_sense_hdr</div><div>sd_mod: Unknown symbol scsi_mod=
e_sense</div>
<div>sd_mod: Unknown symbol scsi_device_get</div><div>sd_mod: Unknown symbo=
l scsi_get_sense_info_fld</div><div>sd_mod: Unknown symbol scsicam_bios_par=
am</div><div>sd_mod: Unknown symbol scsi_command_normalize_sense</div><div>
sd_mod: Unknown symbol scsi_test_unit_ready</div><div>sd_mod: Unknown symbo=
l scsi_block_when_processing_errors</div><div>sd_mod: Unknown symbol scsi_r=
egister_driver</div><div>sd_mod: Unknown symbol scsi_ioctl</div><div>sd_mod=
: Unknown symbol scsi_nonblockable_ioctl</div>
<div>sd_mod: Unknown symbol scsi_device_put</div><div>sd_mod: Unknown symbo=
l scsi_logging_level</div><div>sd_mod: Unknown symbol scsi_execute_req</div=
><div>sd_mod: Unknown symbol scsi_mode_select</div><div>sd_mod: Unknown sym=
bol scsi_print_sense</div>
<div>sd_mod: Unknown symbol scsi_io_completion</div><div>sd_mod: Unknown sy=
mbol scsi_set_medium_removal</div><div>libata: Unknown symbol scsi_device_g=
et</div><div>libata: Unknown symbol scsi_remove_host</div><div>libata: Unkn=
own symbol scsi_schedule_eh</div>
<div>libata: Unknown symbol scsi_device_set_state</div><div>libata: Unknown=
 symbol scsi_eh_finish_cmd</div><div>libata: Unknown symbol scsi_device_put=
</div><div>libata: Unknown symbol scsi_eh_flush_done_q</div><div>libata: Un=
known symbol scsi_host_put</div>
<div>libata: Unknown symbol scsi_add_host</div><div>libata: Unknown symbol =
scsi_rescan_device</div><div>libata: Unknown symbol scsi_adjust_queue_depth=
</div><div>libata: Unknown symbol scsi_execute_req</div><div>libata: Unknow=
n symbol scsi_req_abort_cmd</div>
<div>libata: disagrees about version of symbol HYPERVISOR_shared_info</div>=
<div>libata: Unknown symbol HYPERVISOR_shared_info</div><div>libata: Unknow=
n symbol scsi_remove_device</div><div>libata: Unknown symbol scsi_host_allo=
c</div>
<div>libata: Unknown symbol __scsi_add_device</div><div>ahci: Unknown symbo=
l ata_scsi_ioctl</div><div>ahci: Unknown symbol ata_port_abort</div><div>ah=
ci: Unknown symbol ata_std_bios_param</div><div>ahci: Unknown symbol ata_st=
d_postreset</div>
<div>ahci: Unknown symbol ata_scsi_device_resume</div><div>ahci: Unknown sy=
mbol ata_scsi_device_suspend</div><div>ahci: Unknown symbol ata_tf_from_fis=
</div><div>ahci: Unknown symbol ata_qc_complete_multiple</div><div>ahci: Un=
known symbol ata_noop_dev_select</div>
<div>ahci: Unknown symbol ata_tf_to_fis</div><div>ahci: Unknown symbol ata_=
pci_device_do_resume</div><div>ahci: Unknown symbol ata_dev_classify</div><=
div>ahci: Unknown symbol ata_scsi_release</div><div>ahci: Unknown symbol at=
a_port_offline</div>
<div>ahci: Unknown symbol ata_scsi_change_queue_depth</div><div>ahci: Unkno=
wn symbol sata_std_hardreset</div><div>ahci: Unknown symbol ata_pci_device_=
suspend</div><div>ahci: Unknown symbol scsi_host_put</div><div>ahci: Unknow=
n symbol ata_port_online</div>
<div>ahci: Unknown symbol ata_wait_register</div><div>ahci: Unknown symbol =
ata_busy_sleep</div><div>ahci: Unknown symbol ata_scsi_slave_config</div><d=
iv>ahci: Unknown symbol ata_port_detach</div><div>ahci: Unknown symbol ata_=
port_disable</div>
<div>ahci: Unknown symbol ata_scsi_queuecmd</div><div>ahci: Unknown symbol =
ata_scsi_slave_destroy</div><div>ahci: Unknown symbol ata_ratelimit</div><d=
iv>ahci: Unknown symbol ata_host_set_resume</div><div>ahci: Unknown symbol =
ata_do_eh</div>
<div>ahci: Unknown symbol ata_port_freeze</div><div>ahci: Unknown symbol at=
a_std_prereset</div><div>ahci: Unknown symbol ata_device_add</div><div>&nbs=
p; &nbsp; &nbsp;</div><div><br></div><div><br></div>-- <br>Best Regards,<di=
v>Bei Guan</div>
<br>

--0016e6d77d7f7406d904bda9308d--


--===============7701379240379758479==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7701379240379758479==--


From xen-devel-bounces@lists.xen.org Sat Apr 14 20:36:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 20:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ9hb-0006Oe-Qy; Sat, 14 Apr 2012 20:36:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJ9ha-0006OW-5N
	for xen-devel@lists.xensource.com; Sat, 14 Apr 2012 20:36:10 +0000
Received: from [85.158.143.99:62008] by server-2.bemta-4.messagelabs.com id
	DE/A0-17550-9BFD98F4; Sat, 14 Apr 2012 20:36:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334435767!14018625!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29611 invoked from network); 14 Apr 2012 20:36:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 20:36:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="11938602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Apr 2012 20:35:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 21:35:44 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJ9hA-0003Fz-GE;
	Sat, 14 Apr 2012 20:35:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJ9hA-00070G-F9;
	Sat, 14 Apr 2012 21:35:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12693-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 21:35:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12693: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12693 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12693/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12685

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6b72eb3b40cf
baseline version:
 xen                  c6bde42c8845

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=6b72eb3b40cf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 6b72eb3b40cf
+ branch=xen-unstable
+ revision=6b72eb3b40cf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6b72eb3b40cf ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 8 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 14 20:36:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Apr 2012 20:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJ9hb-0006Oe-Qy; Sat, 14 Apr 2012 20:36:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJ9ha-0006OW-5N
	for xen-devel@lists.xensource.com; Sat, 14 Apr 2012 20:36:10 +0000
Received: from [85.158.143.99:62008] by server-2.bemta-4.messagelabs.com id
	DE/A0-17550-9BFD98F4; Sat, 14 Apr 2012 20:36:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334435767!14018625!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29611 invoked from network); 14 Apr 2012 20:36:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Apr 2012 20:36:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="11938602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Apr 2012 20:35:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Apr 2012 21:35:44 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJ9hA-0003Fz-GE;
	Sat, 14 Apr 2012 20:35:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJ9hA-00070G-F9;
	Sat, 14 Apr 2012 21:35:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12693-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Apr 2012 21:35:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12693: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12693 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12693/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12685

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6b72eb3b40cf
baseline version:
 xen                  c6bde42c8845

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=6b72eb3b40cf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 6b72eb3b40cf
+ branch=xen-unstable
+ revision=6b72eb3b40cf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6b72eb3b40cf ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 8 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 01:53:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 01:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJEdc-00046j-Lr; Sun, 15 Apr 2012 01:52:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJEdb-00046e-5E
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 01:52:23 +0000
Received: from [85.158.143.99:56575] by server-2.bemta-4.messagelabs.com id
	CA/B6-17550-6D92A8F4; Sun, 15 Apr 2012 01:52:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334454740!20294386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31597 invoked from network); 15 Apr 2012 01:52:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 01:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208";a="11939397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 01:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 02:52:20 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJEdX-0004vF-RC;
	Sun, 15 Apr 2012 01:52:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJEdX-0005Z8-J9;
	Sun, 15 Apr 2012 02:52:19 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12694-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 02:52:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12694: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12694 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12694/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=0527fde0639955203ad48a9fd83bd6fc35e82e07
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 0527fde0639955203ad48a9fd83bd6fc35e82e07
+ branch=linux-3.0
+ revision=0527fde0639955203ad48a9fd83bd6fc35e82e07
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 0527fde0639955203ad48a9fd83bd6fc35e82e07:tested/linux-3.0
Counting objects: 1   
Counting objects: 123   
Counting objects: 3942   
Counting objects: 12600, done.
Compressing objects:   0% (1/2022)   
Compressing objects:   1% (21/2022)   
Compressing objects:   2% (41/2022)   
Compressing objects:   3% (61/2022)   
Compressing objects:   4% (81/2022)   
Compressing objects:   5% (102/2022)   
Compressing objects:   6% (122/2022)   
Compressing objects:   7% (142/2022)   
Compressing objects:   8% (162/2022)   
Compressing objects:   9% (182/2022)   
Compressing objects:  10% (203/2022)   
Compressing objects:  11% (223/2022)   
Compressing objects:  12% (243/2022)   
Compressing objects:  13% (263/2022)   
Compressing objects:  14% (284/2022)   
Compressing objects:  15% (304/2022)   
Compressing objects:  16% (324/2022)   
Compressing objects:  17% (344/2022)   
Compressing objects:  18% (364/2022)   
Compressing objects:  19% (385/2022)   
Compressing objects:  20% (405/2022)   
Compressing objects:  21% (425/2022)   
Compressing objects:  22% (445/2022)   
Compressing objects:  23% (466/2022)   
Compressing objects:  24% (486/2022)   
Compressing objects:  25% (506/2022)   
Compressing objects:  26% (526/2022)   
Compressing objects:  27% (546/2022)   
Compressing objects:  28% (567/2022)   
Compressing objects:  29% (587/2022)   
Compressing objects:  30% (607/2022)   
Compressing objects:  31% (627/2022)   
Compressing objects:  32% (648/2022)   
Compressing objects:  33% (668/2022)   
Compressing objects:  34% (688/2022)   
Compressing objects:  35% (708/2022)   
Compressing objects:  36% (728/2022)   
Compressing objects:  37% (749/2022)   
Compressing objects:  38% (769/2022)   
Compressing objects:  39% (789/2022)   
Compressing objects:  40% (809/2022)   
Compressing objects:  41% (830/2022)   
Compressing objects:  42% (850/2022)   
Compressing objects:  43% (870/2022)   
Compressing objects:  44% (890/2022)   
Compressing objects:  45% (910/2022)   
Compressing objects:  46% (931/2022)   
Compressing objects:  47% (951/2022)   
Compressing objects:  48% (971/2022)   
Compressing objects:  49% (991/2022)   
Compressing objects:  50% (1011/2022)   
Compressing objects:  51% (1032/2022)   
Compressing objects:  52% (1052/2022)   
Compressing objects:  53% (1072/2022)   
Compressing objects:  54% (1092/2022)   
Compressing objects:  55% (1113/2022)   
Compressing objects:  56% (1133/2022)   
Compressing objects:  57% (1153/2022)   
Compressing objects:  58% (1173/2022)   
Compressing objects:  59% (1193/2022)   
Compressing objects:  60% (1214/2022)   
Compressing objects:  61% (1234/2022)   
Compressing objects:  62% (1254/2022)   
Compressing objects:  63% (1274/2022)   
Compressing objects:  64% (1295/2022)   
Compressing objects:  65% (1315/2022)   
Compressing objects:  66% (1335/2022)   
Compressing objects:  67% (1355/2022)   
Compressing objects:  68% (1375/2022)   
Compressing objects:  69% (1396/2022)   
Compressing objects:  70% (1416/2022)   
Compressing objects:  71% (1436/2022)   
Compressing objects:  72% (1456/2022)   
Compressing objects:  73% (1477/2022)   
Compressing objects:  74% (1497/2022)   
Compressing objects:  75% (1517/2022)   
Compressing objects:  76% (1537/2022)   
Compressing objects:  77% (1557/2022)   
Compressing objects:  78% (1578/2022)   
Compressing objects:  79% (1598/2022)   
Compressing objects:  80% (1618/2022)   
Compressing objects:  81% (1638/2022)   
Compressing objects:  82% (1659/2022)   
Compressing objects:  83% (1679/2022)   
Compressing objects:  84% (1699/2022)   
Compressing objects:  85% (1719/2022)   
Compressing objects:  86% (1739/2022)   
Compressing objects:  87% (1760/2022)   
Compressing objects:  88% (1780/2022)   
Compressing objects:  89% (1800/2022)   
Compressing objects:  90% (1820/2022)   
Compressing objects:  91% (1841/2022)   
Compressing objects:  92% (1861/2022)   
Compressing objects:  93% (1881/2022)   
Compressing objects:  94% (1901/2022)   
Compressing objects:  95% (1921/2022)   
Compressing objects:  96% (1942/2022)   
Compressing objects:  97% (1962/2022)   
Compressing objects:  98% (1982/2022)   
Compressing objects:  99% (2002/2022)   
Compressing objects: 100% (2022/2022)   
Compressing objects: 100% (2022/2022), done.
Writing objects:   0% (1/10720)   
Writing objects:   1% (108/10720)   
Writing objects:   2% (215/10720)   
Writing objects:   3% (322/10720)   
Writing objects:   4% (429/10720)   
Writing objects:   5% (536/10720)   
Writing objects:   6% (644/10720)   
Writing objects:   7% (751/10720)   
Writing objects:   8% (858/10720)   
Writing objects:   9% (965/10720)   
Writing objects:  10% (1072/10720)   
Writing objects:  11% (1180/10720)   
Writing objects:  12% (1287/10720)   
Writing objects:  13% (1394/10720)   
Writing objects:  14% (1501/10720)   
Writing objects:  15% (1608/10720)   
Writing objects:  16% (1717/10720)   
Writing objects:  17% (1823/10720)   
Writing objects:  18% (1930/10720)   
Writing objects:  19% (2037/10720)   
Writing objects:  20% (2144/10720)   
Writing objects:  21% (2252/10720)   
Writing objects:  22% (2359/10720)   
Writing objects:  23% (2466/10720)   
Writing objects:  24% (2573/10720)   
Writing objects:  25% (2680/10720)   
Writing objects:  26% (2788/10720)   
Writing objects:  27% (2896/10720)   
Writing objects:  28% (3002/10720)   
Writing objects:  29% (3109/10720)   
Writing objects:  30% (3216/10720)   
Writing objects:  31% (3324/10720)   
Writing objects:  32% (3431/10720)   
Writing objects:  33% (3538/10720)   
Writing objects:  34% (3646/10720)   
Writing objects:  35% (3752/10720)   
Writing objects:  36% (3860/10720)   
Writing objects:  37% (3969/10720)   
Writing objects:  38% (4074/10720)   
Writing objects:  39% (4181/10720)   
Writing objects:  40% (4288/10720)   
Writing objects:  41% (4396/10720)   
Writing objects:  42% (4503/10720)   
Writing objects:  43% (4610/10720)   
Writing objects:  44% (4718/10720)   
Writing objects:  45% (4824/10720)   
Writing objects:  46% (4932/10720)   
Writing objects:  47% (5039/10720)   
Writing objects:  48% (5146/10720)   
Writing objects:  49% (5253/10720)   
Writing objects:  50% (5360/10720)   
Writing objects:  51% (5468/10720)   
Writing objects:  52% (5575/10720)   
Writing objects:  53% (5682/10720)   
Writing objects:  54% (5789/10720)   
Writing objects:  55% (5896/10720)   
Writing objects:  56% (6004/10720)   
Writing objects:  57% (6111/10720)   
Writing objects:  58% (6218/10720)   
Writing objects:  59% (6326/10720)   
Writing objects:  60% (6432/10720)   
Writing objects:  61% (6540/10720)   
Writing objects:  62% (6647/10720)   
Writing objects:  63% (6754/10720)   
Writing objects:  64% (6861/10720)   
Writing objects:  65% (6968/10720)   
Writing objects:  66% (7076/10720)   
Writing objects:  67% (7184/10720)   
Writing objects:  68% (7290/10720)   
Writing objects:  69% (7397/10720)   
Writing objects:  70% (7504/10720)   
Writing objects:  71% (7612/10720)   
Writing objects:  72% (7719/10720)   
Writing objects:  73% (7826/10720)   
Writing objects:  74% (7933/10720)   
Writing objects:  75% (8040/10720)   
Writing objects:  76% (8148/10720)   
Writing objects:  77% (8255/10720)   
Writing objects:  78% (8362/10720)   
Writing objects:  79% (8469/10720)   
Writing objects:  80% (8576/10720)   
Writing objects:  81% (8684/10720)   
Writing objects:  82% (8791/10720)   
Writing objects:  83% (8898/10720)   
Writing objects:  84% (9005/10720)   
Writing objects:  85% (9112/10720)   
Writing objects:  86% (9220/10720)   
Writing objects:  87% (9327/10720)   
Writing objects:  88% (9434/10720)   
Writing objects:  89% (9541/10720)   
Writing objects:  90% (9648/10720)   
Writing objects:  91% (9756/10720)   
Writing objects:  92% (9864/10720)   
Writing objects:  93% (9970/10720)   
Writing objects:  94% (10077/10720)   
Writing objects:  95% (10184/10720)   
Writing objects:  96% (10292/10720)   
Writing objects:  97% (10399/10720)   
Writing objects:  98% (10506/10720)   
Writing objects:  99% (10613/10720)   
Writing objects: 100% (10720/10720)   
Writing objects: 100% (10720/10720), 1.94 MiB, done.
Total 10720 (delta 8815), reused 10549 (delta 8644)
To xen@xenbits.xensource.com:git/linux-pvops.git
   02f8c6a..0527fde  0527fde0639955203ad48a9fd83bd6fc35e82e07 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 01:53:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 01:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJEdc-00046j-Lr; Sun, 15 Apr 2012 01:52:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJEdb-00046e-5E
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 01:52:23 +0000
Received: from [85.158.143.99:56575] by server-2.bemta-4.messagelabs.com id
	CA/B6-17550-6D92A8F4; Sun, 15 Apr 2012 01:52:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334454740!20294386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31597 invoked from network); 15 Apr 2012 01:52:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 01:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208";a="11939397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 01:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 02:52:20 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJEdX-0004vF-RC;
	Sun, 15 Apr 2012 01:52:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJEdX-0005Z8-J9;
	Sun, 15 Apr 2012 02:52:19 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12694-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 02:52:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12694: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12694 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12694/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07
baseline version:
 linux                02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=0527fde0639955203ad48a9fd83bd6fc35e82e07
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 0527fde0639955203ad48a9fd83bd6fc35e82e07
+ branch=linux-3.0
+ revision=0527fde0639955203ad48a9fd83bd6fc35e82e07
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 0527fde0639955203ad48a9fd83bd6fc35e82e07:tested/linux-3.0
Counting objects: 1   
Counting objects: 123   
Counting objects: 3942   
Counting objects: 12600, done.
Compressing objects:   0% (1/2022)   
Compressing objects:   1% (21/2022)   
Compressing objects:   2% (41/2022)   
Compressing objects:   3% (61/2022)   
Compressing objects:   4% (81/2022)   
Compressing objects:   5% (102/2022)   
Compressing objects:   6% (122/2022)   
Compressing objects:   7% (142/2022)   
Compressing objects:   8% (162/2022)   
Compressing objects:   9% (182/2022)   
Compressing objects:  10% (203/2022)   
Compressing objects:  11% (223/2022)   
Compressing objects:  12% (243/2022)   
Compressing objects:  13% (263/2022)   
Compressing objects:  14% (284/2022)   
Compressing objects:  15% (304/2022)   
Compressing objects:  16% (324/2022)   
Compressing objects:  17% (344/2022)   
Compressing objects:  18% (364/2022)   
Compressing objects:  19% (385/2022)   
Compressing objects:  20% (405/2022)   
Compressing objects:  21% (425/2022)   
Compressing objects:  22% (445/2022)   
Compressing objects:  23% (466/2022)   
Compressing objects:  24% (486/2022)   
Compressing objects:  25% (506/2022)   
Compressing objects:  26% (526/2022)   
Compressing objects:  27% (546/2022)   
Compressing objects:  28% (567/2022)   
Compressing objects:  29% (587/2022)   
Compressing objects:  30% (607/2022)   
Compressing objects:  31% (627/2022)   
Compressing objects:  32% (648/2022)   
Compressing objects:  33% (668/2022)   
Compressing objects:  34% (688/2022)   
Compressing objects:  35% (708/2022)   
Compressing objects:  36% (728/2022)   
Compressing objects:  37% (749/2022)   
Compressing objects:  38% (769/2022)   
Compressing objects:  39% (789/2022)   
Compressing objects:  40% (809/2022)   
Compressing objects:  41% (830/2022)   
Compressing objects:  42% (850/2022)   
Compressing objects:  43% (870/2022)   
Compressing objects:  44% (890/2022)   
Compressing objects:  45% (910/2022)   
Compressing objects:  46% (931/2022)   
Compressing objects:  47% (951/2022)   
Compressing objects:  48% (971/2022)   
Compressing objects:  49% (991/2022)   
Compressing objects:  50% (1011/2022)   
Compressing objects:  51% (1032/2022)   
Compressing objects:  52% (1052/2022)   
Compressing objects:  53% (1072/2022)   
Compressing objects:  54% (1092/2022)   
Compressing objects:  55% (1113/2022)   
Compressing objects:  56% (1133/2022)   
Compressing objects:  57% (1153/2022)   
Compressing objects:  58% (1173/2022)   
Compressing objects:  59% (1193/2022)   
Compressing objects:  60% (1214/2022)   
Compressing objects:  61% (1234/2022)   
Compressing objects:  62% (1254/2022)   
Compressing objects:  63% (1274/2022)   
Compressing objects:  64% (1295/2022)   
Compressing objects:  65% (1315/2022)   
Compressing objects:  66% (1335/2022)   
Compressing objects:  67% (1355/2022)   
Compressing objects:  68% (1375/2022)   
Compressing objects:  69% (1396/2022)   
Compressing objects:  70% (1416/2022)   
Compressing objects:  71% (1436/2022)   
Compressing objects:  72% (1456/2022)   
Compressing objects:  73% (1477/2022)   
Compressing objects:  74% (1497/2022)   
Compressing objects:  75% (1517/2022)   
Compressing objects:  76% (1537/2022)   
Compressing objects:  77% (1557/2022)   
Compressing objects:  78% (1578/2022)   
Compressing objects:  79% (1598/2022)   
Compressing objects:  80% (1618/2022)   
Compressing objects:  81% (1638/2022)   
Compressing objects:  82% (1659/2022)   
Compressing objects:  83% (1679/2022)   
Compressing objects:  84% (1699/2022)   
Compressing objects:  85% (1719/2022)   
Compressing objects:  86% (1739/2022)   
Compressing objects:  87% (1760/2022)   
Compressing objects:  88% (1780/2022)   
Compressing objects:  89% (1800/2022)   
Compressing objects:  90% (1820/2022)   
Compressing objects:  91% (1841/2022)   
Compressing objects:  92% (1861/2022)   
Compressing objects:  93% (1881/2022)   
Compressing objects:  94% (1901/2022)   
Compressing objects:  95% (1921/2022)   
Compressing objects:  96% (1942/2022)   
Compressing objects:  97% (1962/2022)   
Compressing objects:  98% (1982/2022)   
Compressing objects:  99% (2002/2022)   
Compressing objects: 100% (2022/2022)   
Compressing objects: 100% (2022/2022), done.
Writing objects:   0% (1/10720)   
Writing objects:   1% (108/10720)   
Writing objects:   2% (215/10720)   
Writing objects:   3% (322/10720)   
Writing objects:   4% (429/10720)   
Writing objects:   5% (536/10720)   
Writing objects:   6% (644/10720)   
Writing objects:   7% (751/10720)   
Writing objects:   8% (858/10720)   
Writing objects:   9% (965/10720)   
Writing objects:  10% (1072/10720)   
Writing objects:  11% (1180/10720)   
Writing objects:  12% (1287/10720)   
Writing objects:  13% (1394/10720)   
Writing objects:  14% (1501/10720)   
Writing objects:  15% (1608/10720)   
Writing objects:  16% (1717/10720)   
Writing objects:  17% (1823/10720)   
Writing objects:  18% (1930/10720)   
Writing objects:  19% (2037/10720)   
Writing objects:  20% (2144/10720)   
Writing objects:  21% (2252/10720)   
Writing objects:  22% (2359/10720)   
Writing objects:  23% (2466/10720)   
Writing objects:  24% (2573/10720)   
Writing objects:  25% (2680/10720)   
Writing objects:  26% (2788/10720)   
Writing objects:  27% (2896/10720)   
Writing objects:  28% (3002/10720)   
Writing objects:  29% (3109/10720)   
Writing objects:  30% (3216/10720)   
Writing objects:  31% (3324/10720)   
Writing objects:  32% (3431/10720)   
Writing objects:  33% (3538/10720)   
Writing objects:  34% (3646/10720)   
Writing objects:  35% (3752/10720)   
Writing objects:  36% (3860/10720)   
Writing objects:  37% (3969/10720)   
Writing objects:  38% (4074/10720)   
Writing objects:  39% (4181/10720)   
Writing objects:  40% (4288/10720)   
Writing objects:  41% (4396/10720)   
Writing objects:  42% (4503/10720)   
Writing objects:  43% (4610/10720)   
Writing objects:  44% (4718/10720)   
Writing objects:  45% (4824/10720)   
Writing objects:  46% (4932/10720)   
Writing objects:  47% (5039/10720)   
Writing objects:  48% (5146/10720)   
Writing objects:  49% (5253/10720)   
Writing objects:  50% (5360/10720)   
Writing objects:  51% (5468/10720)   
Writing objects:  52% (5575/10720)   
Writing objects:  53% (5682/10720)   
Writing objects:  54% (5789/10720)   
Writing objects:  55% (5896/10720)   
Writing objects:  56% (6004/10720)   
Writing objects:  57% (6111/10720)   
Writing objects:  58% (6218/10720)   
Writing objects:  59% (6326/10720)   
Writing objects:  60% (6432/10720)   
Writing objects:  61% (6540/10720)   
Writing objects:  62% (6647/10720)   
Writing objects:  63% (6754/10720)   
Writing objects:  64% (6861/10720)   
Writing objects:  65% (6968/10720)   
Writing objects:  66% (7076/10720)   
Writing objects:  67% (7184/10720)   
Writing objects:  68% (7290/10720)   
Writing objects:  69% (7397/10720)   
Writing objects:  70% (7504/10720)   
Writing objects:  71% (7612/10720)   
Writing objects:  72% (7719/10720)   
Writing objects:  73% (7826/10720)   
Writing objects:  74% (7933/10720)   
Writing objects:  75% (8040/10720)   
Writing objects:  76% (8148/10720)   
Writing objects:  77% (8255/10720)   
Writing objects:  78% (8362/10720)   
Writing objects:  79% (8469/10720)   
Writing objects:  80% (8576/10720)   
Writing objects:  81% (8684/10720)   
Writing objects:  82% (8791/10720)   
Writing objects:  83% (8898/10720)   
Writing objects:  84% (9005/10720)   
Writing objects:  85% (9112/10720)   
Writing objects:  86% (9220/10720)   
Writing objects:  87% (9327/10720)   
Writing objects:  88% (9434/10720)   
Writing objects:  89% (9541/10720)   
Writing objects:  90% (9648/10720)   
Writing objects:  91% (9756/10720)   
Writing objects:  92% (9864/10720)   
Writing objects:  93% (9970/10720)   
Writing objects:  94% (10077/10720)   
Writing objects:  95% (10184/10720)   
Writing objects:  96% (10292/10720)   
Writing objects:  97% (10399/10720)   
Writing objects:  98% (10506/10720)   
Writing objects:  99% (10613/10720)   
Writing objects: 100% (10720/10720)   
Writing objects: 100% (10720/10720), 1.94 MiB, done.
Total 10720 (delta 8815), reused 10549 (delta 8644)
To xen@xenbits.xensource.com:git/linux-pvops.git
   02f8c6a..0527fde  0527fde0639955203ad48a9fd83bd6fc35e82e07 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIdv-0006Lk-Bu; Sun, 15 Apr 2012 06:08:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIds-0006LA-Ph
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:08:57 +0000
Received: from [85.158.138.51:52227] by server-5.bemta-3.messagelabs.com id
	5C/90-17113-8F56A8F4; Sun, 15 Apr 2012 06:08:56 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334470134!20369122!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=1.0 required=7.0 tests=MISSING_SUBJECT
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4521 invoked from network); 15 Apr 2012 06:08:54 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-15.tower-174.messagelabs.com with SMTP;
	15 Apr 2012 06:08:54 -0000
Received: from chief-river.localdomain (unknown [180.158.120.132])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id F348FDF903;
	Sun, 15 Apr 2012 14:08:38 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Sun, 15 Apr 2012 14:09:30 +0800
Message-Id: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

These 2 patches try to fix the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506

I tested it with 3.4-rc2 and "perf top" works well now.

Steven,
Could you please help to test it too?

The soft lockup code path is:

__irq_work_queue
  arch_irq_work_raise
    apic->send_IPI_self(IRQ_WORK_VECTOR);
      apic_send_IPI_self
        __default_send_IPI_shortcut
          __xapic_wait_icr_idle

static inline void __xapic_wait_icr_idle(void)
{
        while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
                cpu_relax();
}

The lockup happens at above while looop.
                                                                
The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.

So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.

Ben Guthro (1):
      xen: implement apic ipi interface

Lin Ming (1):
      xen: implement IRQ_WORK_VECTOR handler

 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/enlighten.c          |    7 ++
 arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
 arch/x86/xen/smp.h                |   12 ++++
 4 files changed, 127 insertions(+), 4 deletions(-)

Any comment is appreciated.
Lin Ming


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIdt-0006LJ-FK; Sun, 15 Apr 2012 06:08:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIdr-0006L4-N0
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:08:55 +0000
Received: from [85.158.143.35:37781] by server-2.bemta-4.messagelabs.com id
	91/23-17550-6F56A8F4; Sun, 15 Apr 2012 06:08:54 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334470132!4883595!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18913 invoked from network); 15 Apr 2012 06:08:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-21.messagelabs.com with SMTP;
	15 Apr 2012 06:08:53 -0000
Received: from chief-river.localdomain (unknown [180.158.120.132])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 6544EDF905;
	Sun, 15 Apr 2012 14:08:39 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Sun, 15 Apr 2012 14:09:31 +0800
Message-Id: <1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ben Guthro <ben@guthro.net>

Map native ipi vector to xen vector.
Implement apic ipi interface with xen_send_IPI_one.

Signed-off-by: Ben Guthro <ben@guthro.net>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---

Ben,

This patch was taken from part of your patch at:
https://lkml.org/lkml/2012/2/10/681

Is it OK that I added your SOB?

I did some change to map native ipi vector to xen vector.
Could you please review?

Thanks.

 arch/x86/xen/enlighten.c |    7 ++++
 arch/x86/xen/smp.c       |   81 +++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/smp.h       |   12 +++++++
 3 files changed, 96 insertions(+), 4 deletions(-)
 create mode 100644 arch/x86/xen/smp.h

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..be7dbc8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -74,6 +74,7 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
+#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -849,6 +850,12 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..2dc6628 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -465,8 +465,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+static void __xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
 {
 	unsigned cpu;
 
@@ -478,7 +478,7 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 {
 	int cpu;
 
-	xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
+	__xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
 
 	/* Make sure other vcpus get a chance to run if they need to. */
 	for_each_cpu(cpu, mask) {
@@ -491,10 +491,83 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 
 static void xen_smp_send_call_function_single_ipi(int cpu)
 {
-	xen_send_IPI_mask(cpumask_of(cpu),
+	__xen_send_IPI_mask(cpumask_of(cpu),
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
+static inline int xen_map_vector(int vector)
+{
+	int xen_vector;
+
+	switch (vector) {
+	case RESCHEDULE_VECTOR:
+		xen_vector = XEN_RESCHEDULE_VECTOR;
+		break;
+	case CALL_FUNCTION_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_VECTOR;
+		break;
+	case CALL_FUNCTION_SINGLE_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
+		break;
+	default:
+		xen_vector = -1;
+		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
+			vector);
+	}
+
+	return xen_vector;
+}
+
+void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(mask, xen_vector);
+}
+
+void xen_send_IPI_all(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(cpu_online_mask, xen_vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_one(smp_processor_id(), xen_vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+
+	if (!(num_online_cpus() > 1))
+		return;
+
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
+}
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8981a76
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIdt-0006LJ-FK; Sun, 15 Apr 2012 06:08:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIdr-0006L4-N0
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:08:55 +0000
Received: from [85.158.143.35:37781] by server-2.bemta-4.messagelabs.com id
	91/23-17550-6F56A8F4; Sun, 15 Apr 2012 06:08:54 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334470132!4883595!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18913 invoked from network); 15 Apr 2012 06:08:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-21.messagelabs.com with SMTP;
	15 Apr 2012 06:08:53 -0000
Received: from chief-river.localdomain (unknown [180.158.120.132])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 6544EDF905;
	Sun, 15 Apr 2012 14:08:39 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Sun, 15 Apr 2012 14:09:31 +0800
Message-Id: <1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ben Guthro <ben@guthro.net>

Map native ipi vector to xen vector.
Implement apic ipi interface with xen_send_IPI_one.

Signed-off-by: Ben Guthro <ben@guthro.net>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---

Ben,

This patch was taken from part of your patch at:
https://lkml.org/lkml/2012/2/10/681

Is it OK that I added your SOB?

I did some change to map native ipi vector to xen vector.
Could you please review?

Thanks.

 arch/x86/xen/enlighten.c |    7 ++++
 arch/x86/xen/smp.c       |   81 +++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/smp.h       |   12 +++++++
 3 files changed, 96 insertions(+), 4 deletions(-)
 create mode 100644 arch/x86/xen/smp.h

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..be7dbc8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -74,6 +74,7 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
+#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -849,6 +850,12 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..2dc6628 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -465,8 +465,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+static void __xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
 {
 	unsigned cpu;
 
@@ -478,7 +478,7 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 {
 	int cpu;
 
-	xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
+	__xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
 
 	/* Make sure other vcpus get a chance to run if they need to. */
 	for_each_cpu(cpu, mask) {
@@ -491,10 +491,83 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 
 static void xen_smp_send_call_function_single_ipi(int cpu)
 {
-	xen_send_IPI_mask(cpumask_of(cpu),
+	__xen_send_IPI_mask(cpumask_of(cpu),
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
+static inline int xen_map_vector(int vector)
+{
+	int xen_vector;
+
+	switch (vector) {
+	case RESCHEDULE_VECTOR:
+		xen_vector = XEN_RESCHEDULE_VECTOR;
+		break;
+	case CALL_FUNCTION_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_VECTOR;
+		break;
+	case CALL_FUNCTION_SINGLE_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
+		break;
+	default:
+		xen_vector = -1;
+		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
+			vector);
+	}
+
+	return xen_vector;
+}
+
+void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(mask, xen_vector);
+}
+
+void xen_send_IPI_all(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(cpu_online_mask, xen_vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_one(smp_processor_id(), xen_vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+
+	if (!(num_online_cpus() > 1))
+		return;
+
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
+}
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8981a76
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIdv-0006Lk-Bu; Sun, 15 Apr 2012 06:08:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIds-0006LA-Ph
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:08:57 +0000
Received: from [85.158.138.51:52227] by server-5.bemta-3.messagelabs.com id
	5C/90-17113-8F56A8F4; Sun, 15 Apr 2012 06:08:56 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334470134!20369122!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=1.0 required=7.0 tests=MISSING_SUBJECT
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4521 invoked from network); 15 Apr 2012 06:08:54 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-15.tower-174.messagelabs.com with SMTP;
	15 Apr 2012 06:08:54 -0000
Received: from chief-river.localdomain (unknown [180.158.120.132])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id F348FDF903;
	Sun, 15 Apr 2012 14:08:38 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Sun, 15 Apr 2012 14:09:30 +0800
Message-Id: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

These 2 patches try to fix the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506

I tested it with 3.4-rc2 and "perf top" works well now.

Steven,
Could you please help to test it too?

The soft lockup code path is:

__irq_work_queue
  arch_irq_work_raise
    apic->send_IPI_self(IRQ_WORK_VECTOR);
      apic_send_IPI_self
        __default_send_IPI_shortcut
          __xapic_wait_icr_idle

static inline void __xapic_wait_icr_idle(void)
{
        while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
                cpu_relax();
}

The lockup happens at above while looop.
                                                                
The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.

So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.

Ben Guthro (1):
      xen: implement apic ipi interface

Lin Ming (1):
      xen: implement IRQ_WORK_VECTOR handler

 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/enlighten.c          |    7 ++
 arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
 arch/x86/xen/smp.h                |   12 ++++
 4 files changed, 127 insertions(+), 4 deletions(-)

Any comment is appreciated.
Lin Ming


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:09:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIdv-0006Lc-0Z; Sun, 15 Apr 2012 06:08:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIds-0006L9-LU
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:08:56 +0000
Received: from [85.158.143.99:45691] by server-3.bemta-4.messagelabs.com id
	FD/81-05853-8F56A8F4; Sun, 15 Apr 2012 06:08:56 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334470133!18443159!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5015 invoked from network); 15 Apr 2012 06:08:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-12.tower-216.messagelabs.com with SMTP;
	15 Apr 2012 06:08:53 -0000
Received: from chief-river.localdomain (unknown [180.158.120.132])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id C9E7CDF907;
	Sun, 15 Apr 2012 14:08:39 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Sun, 15 Apr 2012 14:09:32 +0800
Message-Id: <1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/smp.c                |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index 1df3541..cc146d5 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -6,6 +6,7 @@ enum ipi_vector {
 	XEN_CALL_FUNCTION_VECTOR,
 	XEN_CALL_FUNCTION_SINGLE_VECTOR,
 	XEN_SPIN_UNLOCK_VECTOR,
+	XEN_IRQ_WORK_VECTOR,
 
 	XEN_NR_IPIS,
 };
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2dc6628..92ad12d 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
+#include <linux/irq_work.h>
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
@@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
 static DEFINE_PER_CPU(int, xen_resched_irq);
 static DEFINE_PER_CPU(int, xen_callfunc_irq);
 static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
+static DEFINE_PER_CPU(int, xen_irq_work);
 static DEFINE_PER_CPU(int, xen_debug_irq) = -1;
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
  * Reschedule call back.
@@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
 		goto fail;
 	per_cpu(xen_callfuncsingle_irq, cpu) = rc;
 
+	callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
+	rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
+				    cpu,
+				    xen_irq_work_interrupt,
+				    IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
+				    callfunc_name,
+				    NULL);
+	if (rc < 0)
+		goto fail;
+	per_cpu(xen_irq_work, cpu) = rc;
+
 	return 0;
 
  fail:
@@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
 	if (per_cpu(xen_callfuncsingle_irq, cpu) >= 0)
 		unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),
 				       NULL);
+	if (per_cpu(xen_irq_work, cpu) >= 0)
+		unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 
 	return rc;
 }
@@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
 	case CALL_FUNCTION_SINGLE_VECTOR:
 		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
 		break;
+	case IRQ_WORK_VECTOR:
+		xen_vector = XEN_IRQ_WORK_VECTOR;
+		break;
 	default:
 		xen_vector = -1;
 		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
@@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
+{
+	irq_enter();
+	inc_irq_stat(apic_irq_work_irqs);
+	irq_work_run();
+	irq_exit();
+
+	return IRQ_HANDLED;
+}
+
 static const struct smp_ops xen_smp_ops __initconst = {
 	.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
 	.smp_prepare_cpus = xen_smp_prepare_cpus,
@@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
 	unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu), NULL);
+	unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 	native_cpu_die(cpu);
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:09:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIdv-0006Lc-0Z; Sun, 15 Apr 2012 06:08:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIds-0006L9-LU
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:08:56 +0000
Received: from [85.158.143.99:45691] by server-3.bemta-4.messagelabs.com id
	FD/81-05853-8F56A8F4; Sun, 15 Apr 2012 06:08:56 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334470133!18443159!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5015 invoked from network); 15 Apr 2012 06:08:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-12.tower-216.messagelabs.com with SMTP;
	15 Apr 2012 06:08:53 -0000
Received: from chief-river.localdomain (unknown [180.158.120.132])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id C9E7CDF907;
	Sun, 15 Apr 2012 14:08:39 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Date: Sun, 15 Apr 2012 14:09:32 +0800
Message-Id: <1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/smp.c                |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index 1df3541..cc146d5 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -6,6 +6,7 @@ enum ipi_vector {
 	XEN_CALL_FUNCTION_VECTOR,
 	XEN_CALL_FUNCTION_SINGLE_VECTOR,
 	XEN_SPIN_UNLOCK_VECTOR,
+	XEN_IRQ_WORK_VECTOR,
 
 	XEN_NR_IPIS,
 };
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2dc6628..92ad12d 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
+#include <linux/irq_work.h>
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
@@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
 static DEFINE_PER_CPU(int, xen_resched_irq);
 static DEFINE_PER_CPU(int, xen_callfunc_irq);
 static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
+static DEFINE_PER_CPU(int, xen_irq_work);
 static DEFINE_PER_CPU(int, xen_debug_irq) = -1;
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
  * Reschedule call back.
@@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
 		goto fail;
 	per_cpu(xen_callfuncsingle_irq, cpu) = rc;
 
+	callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
+	rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
+				    cpu,
+				    xen_irq_work_interrupt,
+				    IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
+				    callfunc_name,
+				    NULL);
+	if (rc < 0)
+		goto fail;
+	per_cpu(xen_irq_work, cpu) = rc;
+
 	return 0;
 
  fail:
@@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
 	if (per_cpu(xen_callfuncsingle_irq, cpu) >= 0)
 		unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),
 				       NULL);
+	if (per_cpu(xen_irq_work, cpu) >= 0)
+		unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 
 	return rc;
 }
@@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
 	case CALL_FUNCTION_SINGLE_VECTOR:
 		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
 		break;
+	case IRQ_WORK_VECTOR:
+		xen_vector = XEN_IRQ_WORK_VECTOR;
+		break;
 	default:
 		xen_vector = -1;
 		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
@@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
+{
+	irq_enter();
+	inc_irq_stat(apic_irq_work_irqs);
+	irq_work_run();
+	irq_exit();
+
+	return IRQ_HANDLED;
+}
+
 static const struct smp_ops xen_smp_ops __initconst = {
 	.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
 	.smp_prepare_cpus = xen_smp_prepare_cpus,
@@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
 	unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu), NULL);
+	unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 	native_cpu_die(cpu);
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:16:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIkB-0006lu-6K; Sun, 15 Apr 2012 06:15:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIk9-0006ln-P3
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:15:25 +0000
Received: from [85.158.139.83:9712] by server-4.bemta-5.messagelabs.com id
	A0/D8-10788-C776A8F4; Sun, 15 Apr 2012 06:15:24 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334470522!23770949!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13863 invoked from network); 15 Apr 2012 06:15:23 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-15.tower-182.messagelabs.com with SMTP;
	15 Apr 2012 06:15:23 -0000
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com
	[209.85.216.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 28120DBCB0
	for <xen-devel@lists.xen.org>; Sun, 15 Apr 2012 14:15:07 +0800 (CST)
Received: by qadb15 with SMTP id b15so6719354qad.16
	for <xen-devel@lists.xen.org>; Sat, 14 Apr 2012 23:14:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.136.131 with SMTP id r3mr2897434qct.129.1334470497480;
	Sat, 14 Apr 2012 23:14:57 -0700 (PDT)
Received: by 10.229.181.206 with HTTP; Sat, 14 Apr 2012 23:14:57 -0700 (PDT)
Date: Sun, 15 Apr 2012 14:14:57 +0800
Message-ID: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Forgot mail subject, add it)

On Sun, Apr 15, 2012 at 2:09 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> Hi all,
>
> These 2 patches try to fix the "perf top" soft lockups under Xen
> reported by Steven at: https://lkml.org/lkml/2012/2/9/506
>
> I tested it with 3.4-rc2 and "perf top" works well now.
>
> Steven,
> Could you please help to test it too?
>
> The soft lockup code path is:
>
> __irq_work_queue
> =A0arch_irq_work_raise
> =A0 =A0apic->send_IPI_self(IRQ_WORK_VECTOR);
> =A0 =A0 =A0apic_send_IPI_self
> =A0 =A0 =A0 =A0__default_send_IPI_shortcut
> =A0 =A0 =A0 =A0 =A0__xapic_wait_icr_idle
>
> static inline void __xapic_wait_icr_idle(void)
> {
> =A0 =A0 =A0 =A0while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpu_relax();
> }
>
> The lockup happens at above while looop.
>
> The cause is that Xen has not implemented the APIC IPI interface yet.
> Xen has IPI interface: xen_send_IPI_one, but it's only used in
> xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
> xen_smp_send_call_function_single_ipi, etc.
>
> So we need to implement Xen's APIC IPI interface as Ben's patch does.
> And implement Xen's IRQ_WORK_VECTOR handler.
>
> Ben Guthro (1):
> =A0 =A0 =A0xen: implement apic ipi interface
>
> Lin Ming (1):
> =A0 =A0 =A0xen: implement IRQ_WORK_VECTOR handler
>
> =A0arch/x86/include/asm/xen/events.h | =A0 =A01 +
> =A0arch/x86/xen/enlighten.c =A0 =A0 =A0 =A0 =A0| =A0 =A07 ++
> =A0arch/x86/xen/smp.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0111 +++++++++++=
++++++++++++++++++++++++-
> =A0arch/x86/xen/smp.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 12 ++++
> =A04 files changed, 127 insertions(+), 4 deletions(-)
>
> Any comment is appreciated.
> Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 06:16:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 06:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJIkB-0006lu-6K; Sun, 15 Apr 2012 06:15:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJIk9-0006ln-P3
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 06:15:25 +0000
Received: from [85.158.139.83:9712] by server-4.bemta-5.messagelabs.com id
	A0/D8-10788-C776A8F4; Sun, 15 Apr 2012 06:15:24 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334470522!23770949!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13863 invoked from network); 15 Apr 2012 06:15:23 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-15.tower-182.messagelabs.com with SMTP;
	15 Apr 2012 06:15:23 -0000
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com
	[209.85.216.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 28120DBCB0
	for <xen-devel@lists.xen.org>; Sun, 15 Apr 2012 14:15:07 +0800 (CST)
Received: by qadb15 with SMTP id b15so6719354qad.16
	for <xen-devel@lists.xen.org>; Sat, 14 Apr 2012 23:14:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.136.131 with SMTP id r3mr2897434qct.129.1334470497480;
	Sat, 14 Apr 2012 23:14:57 -0700 (PDT)
Received: by 10.229.181.206 with HTTP; Sat, 14 Apr 2012 23:14:57 -0700 (PDT)
Date: Sun, 15 Apr 2012 14:14:57 +0800
Message-ID: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: linux-kernel@vger.kernel.org
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Steven Noonan <steven@uplinklabs.net>,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(Forgot mail subject, add it)

On Sun, Apr 15, 2012 at 2:09 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> Hi all,
>
> These 2 patches try to fix the "perf top" soft lockups under Xen
> reported by Steven at: https://lkml.org/lkml/2012/2/9/506
>
> I tested it with 3.4-rc2 and "perf top" works well now.
>
> Steven,
> Could you please help to test it too?
>
> The soft lockup code path is:
>
> __irq_work_queue
> =A0arch_irq_work_raise
> =A0 =A0apic->send_IPI_self(IRQ_WORK_VECTOR);
> =A0 =A0 =A0apic_send_IPI_self
> =A0 =A0 =A0 =A0__default_send_IPI_shortcut
> =A0 =A0 =A0 =A0 =A0__xapic_wait_icr_idle
>
> static inline void __xapic_wait_icr_idle(void)
> {
> =A0 =A0 =A0 =A0while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpu_relax();
> }
>
> The lockup happens at above while looop.
>
> The cause is that Xen has not implemented the APIC IPI interface yet.
> Xen has IPI interface: xen_send_IPI_one, but it's only used in
> xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
> xen_smp_send_call_function_single_ipi, etc.
>
> So we need to implement Xen's APIC IPI interface as Ben's patch does.
> And implement Xen's IRQ_WORK_VECTOR handler.
>
> Ben Guthro (1):
> =A0 =A0 =A0xen: implement apic ipi interface
>
> Lin Ming (1):
> =A0 =A0 =A0xen: implement IRQ_WORK_VECTOR handler
>
> =A0arch/x86/include/asm/xen/events.h | =A0 =A01 +
> =A0arch/x86/xen/enlighten.c =A0 =A0 =A0 =A0 =A0| =A0 =A07 ++
> =A0arch/x86/xen/smp.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0111 +++++++++++=
++++++++++++++++++++++++-
> =A0arch/x86/xen/smp.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 12 ++++
> =A04 files changed, 127 insertions(+), 4 deletions(-)
>
> Any comment is appreciated.
> Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 07:54:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 07:54:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJKGr-0007Qr-WC; Sun, 15 Apr 2012 07:53:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJKGq-0007Qm-I1
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 07:53:16 +0000
Received: from [85.158.143.99:34861] by server-3.bemta-4.messagelabs.com id
	F7/4B-05853-B6E7A8F4; Sun, 15 Apr 2012 07:53:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334476395!17318640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13110 invoked from network); 15 Apr 2012 07:53:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 07:53:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208";a="11940255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 07:53:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 08:53:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJKGo-0007Ws-0r;
	Sun, 15 Apr 2012 07:53:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJKGo-0006IY-0D;
	Sun, 15 Apr 2012 08:53:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12695-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 08:53:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12695: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12695 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12695/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12693

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6b72eb3b40cf
baseline version:
 xen                  6b72eb3b40cf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 07:54:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 07:54:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJKGr-0007Qr-WC; Sun, 15 Apr 2012 07:53:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJKGq-0007Qm-I1
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 07:53:16 +0000
Received: from [85.158.143.99:34861] by server-3.bemta-4.messagelabs.com id
	F7/4B-05853-B6E7A8F4; Sun, 15 Apr 2012 07:53:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334476395!17318640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13110 invoked from network); 15 Apr 2012 07:53:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 07:53:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208";a="11940255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 07:53:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 08:53:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJKGo-0007Ws-0r;
	Sun, 15 Apr 2012 07:53:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJKGo-0006IY-0D;
	Sun, 15 Apr 2012 08:53:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12695-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 08:53:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12695: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12695 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12695/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12693

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6b72eb3b40cf
baseline version:
 xen                  6b72eb3b40cf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 08:52:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 08:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJLBM-0008B8-7S; Sun, 15 Apr 2012 08:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SJLBL-0008B3-0Y
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 08:51:39 +0000
Received: from [85.158.138.51:22971] by server-1.bemta-3.messagelabs.com id
	39/71-11491-A1C8A8F4; Sun, 15 Apr 2012 08:51:38 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334479894!22016705!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26432 invoked from network); 15 Apr 2012 08:51:36 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Apr 2012 08:51:36 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q3F8pVHc007435
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Sun, 15 Apr 2012 01:51:32 -0700
Received: by bkwj5 with SMTP id j5so3634063bkw.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Apr 2012 01:51:29 -0700 (PDT)
Received: by 10.204.156.12 with SMTP id u12mr2356827bkw.33.1334479889677; Sun,
	15 Apr 2012 01:51:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.97.203 with HTTP; Sun, 15 Apr 2012 01:50:49 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Sun, 15 Apr 2012 01:50:49 -0700
Message-ID: <CAP8mzPPW6wUDZKiBW1tWi--DyvN7kaE+i3++SpcasfzgEN+zaQ@mail.gmail.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3547828704705537458=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3547828704705537458==
Content-Type: multipart/alternative; boundary=0015175cd2b4c8bc1d04bdb3cf5d

--0015175cd2b4c8bc1d04bdb3cf5d
Content-Type: text/plain; charset=ISO-8859-1

I ll wait until this series gets in before respinning my patch series (if
need be). :)


shriram

On Fri, Apr 13, 2012 at 4:40 AM, Stefano Stabellini <
Stefano.Stabellini@eu.citrix.com> wrote:

> Hi all,
> this patch series introduces a new xc_save_id called
> XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
> Libxl is going to use the new save_id to save and restore qemu's
> physmap.
>
> The QEMU side of this patch series has been accepted, so it is now safe
> to commit it to xen-unstable.
>
>
> Changes in v8:
> - return an error on restore if toolstack data is available but no
> toolstack callback has been provided.
>
>
> Changes in v7:
> - log error messages on error paths;
>
> - make the toolstack save/restore functions more readable.
>
>
> Changes in v6:
>
> - rebased on "kexec: Fix printing of paddr_t in 32bit mode.";
>
> - use the command "xen-save-devices-state" to save the QEMU devices
> state.
>
>
>
> Changes in v5:
>
> - rebased on "arm: lr register in hyp mode is really LR_usr.".
>
>
>
> Changes in v4:
>
> - addressed Shriram's comments about the first patch: saving/restoring
> toolstack extra information should work we Remus too now;
>
> - added a new patch to use QMP "save_devices" command rather than
> "migrate" to save QEMU's device state.
>
>
>
> Changes in v3:
>
> - rebased the series;
>
> - xc_domain_restore: read the toolstack data in pagebuf_get_one, call
> the callback at finish_hvm;
>
>
>
> Changes in v2:
>
> - xc_domain_save frees the buffer allocated by the callback;
>
> - introduce a version number in the libxl save record;
>
> - define libxl__physmap_info and use it to read/store information to the
> buffer.
>
>
> Stefano Stabellini (3):
>      libxc: introduce XC_SAVE_ID_TOOLSTACK
>      libxl: save/restore qemu's physmap
>      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save
>
>  tools/libxc/xc_domain_restore.c |   53 ++++++++++++-
>  tools/libxc/xc_domain_save.c    |   17 ++++
>  tools/libxc/xenguest.h          |   23 +++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |  174
> ++++++++++++++++++++++++++++++++++++---
>  tools/libxl/libxl_internal.h    |    2 +-
>  tools/libxl/libxl_qmp.c         |   82 +------------------
>  tools/xcutils/xc_restore.c      |    2 +-
>  8 files changed, 260 insertions(+), 94 deletions(-)
>
>
> Cheers,
>
> Stefano
>
>

--0015175cd2b4c8bc1d04bdb3cf5d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I ll wait until this series gets in before respinning my patch series =
(if need be). :)</div><div>=A0</div><div>=A0</div><div>shriram<br><br></div=
><div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 4:40 AM, Stefano Stabel=
lini <span dir=3D"ltr">&lt;<a href=3D"mailto:Stefano.Stabellini@eu.citrix.c=
om">Stefano.Stabellini@eu.citrix.com</a>&gt;</span> wrote:<br>

<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class=
=3D"gmail_quote">Hi all,<br>
this patch series introduces a new xc_save_id called<br>
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.<br>
Libxl is going to use the new save_id to save and restore qemu&#39;s<br>
physmap.<br>
<br>
The QEMU side of this patch series has been accepted, so it is now safe<br>
to commit it to xen-unstable.<br>
<br>
<br>
Changes in v8:<br>
- return an error on restore if toolstack data is available but no<br>
toolstack callback has been provided.<br>
<br>
<br>
Changes in v7:<br>
- log error messages on error paths;<br>
<br>
- make the toolstack save/restore functions more readable.<br>
<br>
<br>
Changes in v6:<br>
<br>
- rebased on &quot;kexec: Fix printing of paddr_t in 32bit mode.&quot;;<br>
<br>
- use the command &quot;xen-save-devices-state&quot; to save the QEMU devic=
es<br>
state.<br>
<br>
<br>
<br>
Changes in v5:<br>
<br>
- rebased on &quot;arm: lr register in hyp mode is really LR_usr.&quot;.<br=
>
<br>
<br>
<br>
Changes in v4:<br>
<br>
- addressed Shriram&#39;s comments about the first patch: saving/restoring<=
br>
toolstack extra information should work we Remus too now;<br>
<br>
- added a new patch to use QMP &quot;save_devices&quot; command rather than=
<br>
&quot;migrate&quot; to save QEMU&#39;s device state.<br>
<br>
<br>
<br>
Changes in v3:<br>
<br>
- rebased the series;<br>
<br>
- xc_domain_restore: read the toolstack data in pagebuf_get_one, call<br>
the callback at finish_hvm;<br>
<br>
<br>
<br>
Changes in v2:<br>
<br>
- xc_domain_save frees the buffer allocated by the callback;<br>
<br>
- introduce a version number in the libxl save record;<br>
<br>
- define libxl__physmap_info and use it to read/store information to the<br=
>
buffer.<br>
<br>
<br>
Stefano Stabellini (3):<br>
 =A0 =A0 =A0libxc: introduce XC_SAVE_ID_TOOLSTACK<br>
 =A0 =A0 =A0libxl: save/restore qemu&#39;s physmap<br>
 =A0 =A0 =A0libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save=
<br>
<br>
=A0tools/libxc/xc_domain_restore.c | =A0 53 ++++++++++++-<br>
=A0tools/libxc/xc_domain_save.c =A0 =A0| =A0 17 ++++<br>
=A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0| =A0 23 +++++-<br>
=A0tools/libxc/xg_save_restore.h =A0 | =A0 =A01 +<br>
=A0tools/libxl/libxl_dom.c =A0 =A0 =A0 =A0 | =A0174 +++++++++++++++++++++++=
+++++++++++++---<br>
=A0tools/libxl/libxl_internal.h =A0 =A0| =A0 =A02 +-<br>
=A0tools/libxl/libxl_qmp.c =A0 =A0 =A0 =A0 | =A0 82 +------------------<br>
=A0tools/xcutils/xc_restore.c =A0 =A0 =A0| =A0 =A02 +-<br>
=A08 files changed, 260 insertions(+), 94 deletions(-)<br>
<br>
<br>
Cheers,<br>
<br>
Stefano<br>
<br>
</blockquote></div><br>

--0015175cd2b4c8bc1d04bdb3cf5d--


--===============3547828704705537458==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3547828704705537458==--


From xen-devel-bounces@lists.xen.org Sun Apr 15 08:52:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 08:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJLBM-0008B8-7S; Sun, 15 Apr 2012 08:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SJLBL-0008B3-0Y
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 08:51:39 +0000
Received: from [85.158.138.51:22971] by server-1.bemta-3.messagelabs.com id
	39/71-11491-A1C8A8F4; Sun, 15 Apr 2012 08:51:38 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334479894!22016705!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26432 invoked from network); 15 Apr 2012 08:51:36 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Apr 2012 08:51:36 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q3F8pVHc007435
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Sun, 15 Apr 2012 01:51:32 -0700
Received: by bkwj5 with SMTP id j5so3634063bkw.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Apr 2012 01:51:29 -0700 (PDT)
Received: by 10.204.156.12 with SMTP id u12mr2356827bkw.33.1334479889677; Sun,
	15 Apr 2012 01:51:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.97.203 with HTTP; Sun, 15 Apr 2012 01:50:49 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Sun, 15 Apr 2012 01:50:49 -0700
Message-ID: <CAP8mzPPW6wUDZKiBW1tWi--DyvN7kaE+i3++SpcasfzgEN+zaQ@mail.gmail.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3547828704705537458=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3547828704705537458==
Content-Type: multipart/alternative; boundary=0015175cd2b4c8bc1d04bdb3cf5d

--0015175cd2b4c8bc1d04bdb3cf5d
Content-Type: text/plain; charset=ISO-8859-1

I ll wait until this series gets in before respinning my patch series (if
need be). :)


shriram

On Fri, Apr 13, 2012 at 4:40 AM, Stefano Stabellini <
Stefano.Stabellini@eu.citrix.com> wrote:

> Hi all,
> this patch series introduces a new xc_save_id called
> XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
> Libxl is going to use the new save_id to save and restore qemu's
> physmap.
>
> The QEMU side of this patch series has been accepted, so it is now safe
> to commit it to xen-unstable.
>
>
> Changes in v8:
> - return an error on restore if toolstack data is available but no
> toolstack callback has been provided.
>
>
> Changes in v7:
> - log error messages on error paths;
>
> - make the toolstack save/restore functions more readable.
>
>
> Changes in v6:
>
> - rebased on "kexec: Fix printing of paddr_t in 32bit mode.";
>
> - use the command "xen-save-devices-state" to save the QEMU devices
> state.
>
>
>
> Changes in v5:
>
> - rebased on "arm: lr register in hyp mode is really LR_usr.".
>
>
>
> Changes in v4:
>
> - addressed Shriram's comments about the first patch: saving/restoring
> toolstack extra information should work we Remus too now;
>
> - added a new patch to use QMP "save_devices" command rather than
> "migrate" to save QEMU's device state.
>
>
>
> Changes in v3:
>
> - rebased the series;
>
> - xc_domain_restore: read the toolstack data in pagebuf_get_one, call
> the callback at finish_hvm;
>
>
>
> Changes in v2:
>
> - xc_domain_save frees the buffer allocated by the callback;
>
> - introduce a version number in the libxl save record;
>
> - define libxl__physmap_info and use it to read/store information to the
> buffer.
>
>
> Stefano Stabellini (3):
>      libxc: introduce XC_SAVE_ID_TOOLSTACK
>      libxl: save/restore qemu's physmap
>      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save
>
>  tools/libxc/xc_domain_restore.c |   53 ++++++++++++-
>  tools/libxc/xc_domain_save.c    |   17 ++++
>  tools/libxc/xenguest.h          |   23 +++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |  174
> ++++++++++++++++++++++++++++++++++++---
>  tools/libxl/libxl_internal.h    |    2 +-
>  tools/libxl/libxl_qmp.c         |   82 +------------------
>  tools/xcutils/xc_restore.c      |    2 +-
>  8 files changed, 260 insertions(+), 94 deletions(-)
>
>
> Cheers,
>
> Stefano
>
>

--0015175cd2b4c8bc1d04bdb3cf5d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I ll wait until this series gets in before respinning my patch series =
(if need be). :)</div><div>=A0</div><div>=A0</div><div>shriram<br><br></div=
><div class=3D"gmail_quote">On Fri, Apr 13, 2012 at 4:40 AM, Stefano Stabel=
lini <span dir=3D"ltr">&lt;<a href=3D"mailto:Stefano.Stabellini@eu.citrix.c=
om">Stefano.Stabellini@eu.citrix.com</a>&gt;</span> wrote:<br>

<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class=
=3D"gmail_quote">Hi all,<br>
this patch series introduces a new xc_save_id called<br>
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.<br>
Libxl is going to use the new save_id to save and restore qemu&#39;s<br>
physmap.<br>
<br>
The QEMU side of this patch series has been accepted, so it is now safe<br>
to commit it to xen-unstable.<br>
<br>
<br>
Changes in v8:<br>
- return an error on restore if toolstack data is available but no<br>
toolstack callback has been provided.<br>
<br>
<br>
Changes in v7:<br>
- log error messages on error paths;<br>
<br>
- make the toolstack save/restore functions more readable.<br>
<br>
<br>
Changes in v6:<br>
<br>
- rebased on &quot;kexec: Fix printing of paddr_t in 32bit mode.&quot;;<br>
<br>
- use the command &quot;xen-save-devices-state&quot; to save the QEMU devic=
es<br>
state.<br>
<br>
<br>
<br>
Changes in v5:<br>
<br>
- rebased on &quot;arm: lr register in hyp mode is really LR_usr.&quot;.<br=
>
<br>
<br>
<br>
Changes in v4:<br>
<br>
- addressed Shriram&#39;s comments about the first patch: saving/restoring<=
br>
toolstack extra information should work we Remus too now;<br>
<br>
- added a new patch to use QMP &quot;save_devices&quot; command rather than=
<br>
&quot;migrate&quot; to save QEMU&#39;s device state.<br>
<br>
<br>
<br>
Changes in v3:<br>
<br>
- rebased the series;<br>
<br>
- xc_domain_restore: read the toolstack data in pagebuf_get_one, call<br>
the callback at finish_hvm;<br>
<br>
<br>
<br>
Changes in v2:<br>
<br>
- xc_domain_save frees the buffer allocated by the callback;<br>
<br>
- introduce a version number in the libxl save record;<br>
<br>
- define libxl__physmap_info and use it to read/store information to the<br=
>
buffer.<br>
<br>
<br>
Stefano Stabellini (3):<br>
 =A0 =A0 =A0libxc: introduce XC_SAVE_ID_TOOLSTACK<br>
 =A0 =A0 =A0libxl: save/restore qemu&#39;s physmap<br>
 =A0 =A0 =A0libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save=
<br>
<br>
=A0tools/libxc/xc_domain_restore.c | =A0 53 ++++++++++++-<br>
=A0tools/libxc/xc_domain_save.c =A0 =A0| =A0 17 ++++<br>
=A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0| =A0 23 +++++-<br>
=A0tools/libxc/xg_save_restore.h =A0 | =A0 =A01 +<br>
=A0tools/libxl/libxl_dom.c =A0 =A0 =A0 =A0 | =A0174 +++++++++++++++++++++++=
+++++++++++++---<br>
=A0tools/libxl/libxl_internal.h =A0 =A0| =A0 =A02 +-<br>
=A0tools/libxl/libxl_qmp.c =A0 =A0 =A0 =A0 | =A0 82 +------------------<br>
=A0tools/xcutils/xc_restore.c =A0 =A0 =A0| =A0 =A02 +-<br>
=A08 files changed, 260 insertions(+), 94 deletions(-)<br>
<br>
<br>
Cheers,<br>
<br>
Stefano<br>
<br>
</blockquote></div><br>

--0015175cd2b4c8bc1d04bdb3cf5d--


--===============3547828704705537458==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3547828704705537458==--


From xen-devel-bounces@lists.xen.org Sun Apr 15 08:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 08:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJLE7-0008GI-QC; Sun, 15 Apr 2012 08:54:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1SJLE6-0008GB-7E
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 08:54:30 +0000
Received: from [193.109.254.147:12343] by server-9.bemta-14.messagelabs.com id
	36/FF-05787-5CC8A8F4; Sun, 15 Apr 2012 08:54:29 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334480066!4657513!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6116 invoked from network); 15 Apr 2012 08:54:26 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 08:54:26 -0000
Received: by wibhn6 with SMTP id hn6so3556152wib.14
	for <xen-devel@lists.xen.org>; Sun, 15 Apr 2012 01:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=ZfAkAuV4YBIB0A7UZS3F1Cmj3UVbwUABvNfqQTM5tEQ=;
	b=dcTBBkfPnwTWkrqSRV7Fd72uoQ4G3dhI9aYTfJbUp5ouwnAFlpJGyRRf+s8Vtbs79w
	AvShDqANPjZLPPh9HzQoGmC2yy+GmSkFKBk9wkqN71wc35KYkr3Qqck3yUQwEoYw33C0
	TZJQE4T8QabkfF6E+heDKC0te29qDu14U/tKeZgZYFtSx8xNK8ztcHgtWi+MkU0Z1cYe
	aHXiFZQSlvEipDTIw1abZ68u3oR3edLaaOVCSUEKTLAeovoZfaRKczCQOQQxiyqT+Wo4
	1m8+aCJjUlacQRe/fTJc8I7ksfe53UesCHbfcx08XVbMOdjo9U9veNkD2SzhyyhqWrR6
	kccQ==
MIME-Version: 1.0
Received: by 10.180.100.230 with SMTP id fb6mr6486355wib.3.1334480065796; Sun,
	15 Apr 2012 01:54:25 -0700 (PDT)
Received: by 10.223.123.138 with HTTP; Sun, 15 Apr 2012 01:54:25 -0700 (PDT)
In-Reply-To: <CAEQjb-SGFkWu6cCMNyeAF8YqA3Hua_9s99OeuO2MsiKysKYkHg@mail.gmail.com>
References: <CAEQjb-SGFkWu6cCMNyeAF8YqA3Hua_9s99OeuO2MsiKysKYkHg@mail.gmail.com>
Date: Sun, 15 Apr 2012 16:54:25 +0800
Message-ID: <CAEQjb-RriwgVQ4uNindutLKTxqk2g_5r=aDQLNQyYy7FnG+U_Q@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Error: disagrees about version of symbol
	HYPERVISOR_shared_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2998025191639309644=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2998025191639309644==
Content-Type: multipart/alternative; boundary=f46d041824ee481a8104bdb3daa3

--f46d041824ee481a8104bdb3daa3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi All,

I think this problem has been solved.
What I have done is that make clean the xen and tools, and remove the
build-linux-2.6.18-xen_x86_32 directory. Then, I re-compile the xen, tools,
kernels, and reboot. It works fine.

Thank you all the same.



=E5=9C=A8 2012=E5=B9=B44=E6=9C=8815=E6=97=A5 =E4=B8=8A=E5=8D=884:11=EF=BC=
=8CBei Guan <gbtju85@gmail.com>=E5=86=99=E9=81=93=EF=BC=9A

> Hi All,
>
> I want to shared a variable between Dom0 and Xen. I add the variable into
> *struct shared_info* in code file xen/include/public/xen.h and
> linux-2.6.18-xen.hg/include/xen/interface/xeb.h.
> In Dom0, I use *shared_info_t *s =3D HYPERVISOR_shared_info* to get the
> value of the shared variable.
>
> However, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot
> into Dom0. The error from serial port debug is logged as the following.
>
> Could anyone help me figure out the problem? Any suggestion is
> appreciated. Thanks a lot.
>
>
>
>
> =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D PuTTY log 2012.04.15 03:3=
7:03
> =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D
> Restarting system.
> (XEN) Domain 0 shutdown: rebooting machine.
>  __  __            _  _    _   ____
>  \ \/ /___ _ __   | || |  / | |___ \
>   \  // _ \ '_ \  | || |_ | |   __) |
>   /  \  __/ | | | |__   _|| |_ / __/
>  /_/\_\___|_| |_|    |_|(_)_(_)_____|
>
> (XEN) Xen version 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 =
20070925 (Red
> Hat 4.1.2-33)) Sun Apr 15 03:24:23 CST 2012
> (XEN) Latest ChangeSet: unavailable
> (XEN) Bootloader: GNU GRUB 0.97
> (XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009a800 (usable)
> (XEN)  00000000000f0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000cd9ffc00 (usable)
> (XEN)  00000000cd9ffc00 - 00000000cda53c00 (ACPI NVS)
> (XEN)  00000000cda53c00 - 00000000cda55c00 (ACPI data)
> (XEN)  00000000cda55c00 - 00000000d0000000 (reserved)
> (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fed00400 (reserved)
> (XEN)  00000000fed20000 - 00000000feda0000 (reserved)
> (XEN)  00000000fee00000 - 00000000fef00000 (reserved)
> (XEN)  00000000ffb00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000128000000 (usable)
> (XEN) System RAM: 3929MB (4023908kB)
> (XEN) ACPI: RSDP 000FEC00, 0024 (r2 DELL  )
> (XEN) ACPI: XSDT 000FC7CB, 009C (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: DSDT FFE9CFF8, 54AD (r1   DELL    dt_ex     1000 INTL 2005062=
4)
> (XEN) ACPI: FACS CD9FFC00, 0040
> (XEN) ACPI: SSDT FFEA25C4, 00AA (r1   DELL    st_ex     1000 INTL 2005062=
4)
> (XEN) ACPI: APIC 000FC9EF, 0092 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: ASF! 000FCAA9, 0096 (r32 DELL    B10K          15 ASL
>  61)
> (XEN) ACPI: MCFG 000FCB3F, 003E (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: TCPA 000FCDD9, 0032 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: DMAR 000FCE0B, 0120 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm  Cpu0Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm  Cpu1Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm  Cpu2Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA0085B, 01B7 (r1 DpgPmm  Cpu3Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA00C64, 0190 (r1 DpgPmm    CpuPm       10 INTL 2005062=
4)
> (XEN) Xen heap: 9MB (9768kB)
> (XEN) Domain heap initialised
> (XEN) Processor #0 7:7 APIC version 20
> (XEN) Processor #1 7:7 APIC version 20
> (XEN) Processor #2 7:7 APIC version 20
> (XEN) Processor #3 7:7 APIC version 20
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) Table is not found!
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2660.080 MHz processor.
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation not enabled.
> (XEN) Intel VT-d Interrupt Remapping not enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.
> (XEN) I/O virtualisation enabled
> (XEN)  - Dom0 mode: Relaxed
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using new ACK method
> (XEN) Platform timer is 14.318MHz HPET
> =C3=BF(XEN) Allocated console ring of 16 KiB.
> (XEN) VMX: Supported advanced features:
> (XEN)  - APIC MMIO access virtualisation
> (XEN)  - APIC TPR shadow
> (XEN)  - Virtual NMI
> (XEN)  - MSR direct-access bitmap
> (XEN) HVM: ASIDs disabled.
> (XEN) HVM: VMX enabled
> (XEN) Brought up 4 CPUs
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN)  Xen  kernel: 32-bit, PAE, lsb
> (XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc0100000 -> 0xc04c923c
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000124000000->0000000125000000 (953327 pages to
> be allocated)
> (XEN)  Init. ramdisk: 00000001278fe000->0000000127fff400
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: c0100000->c04c923c
> (XEN)  Init. ramdisk: c04ca000->c0bcb400
> (XEN)  Phys-Mach map: c0bcc000->c0f74bc4
> (XEN)  Start info:    c0f75000->c0f7547c
> (XEN)  Page tables:   c0f76000->c0f85000
> (XEN)  Boot stack:    c0f85000->c0f86000
> (XEN)  TOTAL:         c0000000->c1400000
> (XEN)  ENTRY ADDRESS: c0100000
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault
> addr ffffff000, iommu reg =3D fff16000
> (XEN) DMAR:[fault reason 05h] PTE Write access is not set
> (XEN) Scrubbing Free RAM: .done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
> to Xen)
> (XEN) Freed 184kB init memory.
> Linux version 2.6.18.8-xen (root@localhost.localdomain) (gcc =E7=89=88=E6=
=9C=AC 4.1.2
> 20070925 (Red Hat 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 00000000eaaf1000 (usable)
> 3026MB HIGHMEM available.
> 727MB LOWMEM available.
> NX (Execute Disable) protection: active
> On node 0 totalpages: 961265
>   DMA zone: 4096 pages, LIFO batch:0
>   Normal zone: 182270 pages, LIFO batch:31
>   HighMem zone: 774899 pages, LIFO batch:31
> found SMP MP-table at 000fe710
> DMI 2.5 present.
> ACPI: RSDP (v002 DELL                                  ) @ 0x000fec00
> ACPI: XSDT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc7cb
> ACPI: FADT (v003 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc8fb
> ACPI: SSDT (v001   DELL    st_ex 0x00001000 INTL 0x20050624) @ 0xffea25c4
> ACPI: MADT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc9ef
> ACPI: BOOT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fca81
> ACPI: ASF! (v032 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcaa9
> ACPI: MCFG (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb3f
> ACPI: HPET (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb7d
> ACPI: TCPA (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcdd9
>   >>> ERROR: Invalid checksum
> ACPI: DMAR (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fce0b
> ACPI: SLIC (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcbb5
> ACPI: SSDT (v001 DpgPmm  Cpu0Ist 0x00000011 INTL 0x20050624) @ 0xcd9ffc40
> ACPI: SSDT (v001 DpgPmm  Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049
> ACPI: SSDT (v001 DpgPmm  Cpu2Ist 0x00000011 INTL 0x20050624) @ 0xcda00452
> ACPI: SSDT (v001 DpgPmm  Cpu3Ist 0x00000011 INTL 0x20050624) @ 0xcda0085b
> ACPI: SSDT (v001 DpgPmm    CpuPm 0x00000010 INTL 0x20050624) @ 0xcda00c64
> ACPI: DSDT (v001   DELL    dt_ex 0x00001000 INTL 0x20050624) @ 0x00000000
> ACPI: Local APIC address 0xfee00000
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
> ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
> ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
> ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
> ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
> ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> ACPI: IRQ0 used by override.
> ACPI: IRQ2 used by override.
> ACPI: IRQ9 used by override.
> Enabling APIC mode:  Flat.  Using 1 I/O APICs
> Using ACPI (MADT) for SMP configuration information
> Allocating PCI resources starting at d1000000 (gap: d0000000:10000000)
> Detected 2660.681 MHz processor.
> Built 1 zonelists.  Total pages: 961265
> Kernel command line: ro root=3D/dev/sda11 console=3Dhvc0 console=3Dtty0
> console=3DttyS0,115200n8 debug selinux=3D0
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Initializing CPU#0
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> Xen reported: 2660.080 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Software IO TLB enabled:
>  Aperture:     64 megabytes
>  Kernel range: c31fd000 - c71fd000
>  Address size: 27 bits
> vmalloc area: ee000000-f51fe000, maxmem 2d7fe000
> Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,
> 908k data, 204k init, 3099596k highmem)
> Checking if this processor honours the WP bit even in supervisor mode...
> Ok.
> Calibrating delay using timer specific routine.. 5347.97 BogoMIPS
> (lpj=3D26739870)
> Security Framework v1.0.0 initialized
> Capability LSM initialized
> Mount-cache hash table entries: 512
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000
> Checking 'hlt' instruction... OK.
> SMP alternatives: switching to UP code
> ACPI: Core revision 20060707
> ENABLING IO-APIC IRQs
> SMP alternatives: switching to SMP code
> Initializing CPU#1
> Initializing CPU#2
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> Brought up 4 CPUs
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000<6>Initializing CPU#3
>
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000
> migration_cost=3D12
> checking if image is initramfs... it is
> Freeing initrd memory: 7173k freed
> PM: Adding info for No Bus:platform
> NET: Registered protocol family 16
> PM: Adding info for No Bus:xen
> PM: Adding info for No Bus:xen-backend
> ACPI: bus type pci registered
> PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> PCI: MCFG area at e0000000 reserved in E820
> PCI: Using MMCONFIG
> Setting up standard PCI resources
> ACPI: Interpreter enabled
> ACPI: Using IOAPIC for interrupt routing
> PM: Adding info for acpi:acpi
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> PCI: Probing PCI hardware (bus 00)
> PM: Adding info for No Bus:pci0000:00
> ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
> Boot video device is 0000:00:02.0
> PCI: Transparent bridge - 0000:00:1e.0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> PM: Adding info for pci:0000:00:00.0
> PM: Adding info for pci:0000:00:01.0
> PM: Adding info for pci:0000:00:02.0
> PM: Adding info for pci:0000:00:02.1
> PM: Adding info for pci:0000:00:03.0
> PM: Adding info for pci:0000:00:03.2
> PM: Adding info for pci:0000:00:03.3
> PM: Adding info for pci:0000:00:19.0
> PM: Adding info for pci:0000:00:1a.0
> PM: Adding info for pci:0000:00:1a.1
> PM: Adding info for pci:0000:00:1a.2
> PM: Adding info for pci:0000:00:1a.7
> PM: Adding info for pci:0000:00:1b.0
> PM: Adding info for pci:0000:00:1c.0
> PM: Adding info for pci:0000:00:1c.1
> PM: Adding info for pci:0000:00:1d.0
> PM: Adding info for pci:0000:00:1d.1
> PM: Adding info for pci:0000:00:1d.2
> PM: Adding info for pci:0000:00:1d.7
> PM: Adding info for pci:0000:00:1e.0
> PM: Adding info for pci:0000:00:1f.0
> PM: Adding info for pci:0000:00:1f.2
> PM: Adding info for pci:0000:00:1f.3
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI4._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0,
> disabled.
> ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)
> Linux Plug and Play Support v0.97 (c) Adam Belay
> pnp: PnP ACPI init
> PM: Adding info for No Bus:pnp0
> PM: Adding info for pnp:00:00
> PM: Adding info for pnp:00:01
> PM: Adding info for pnp:00:02
> PM: Adding info for pnp:00:03
> PM: Adding info for pnp:00:04
> PM: Adding info for pnp:00:05
> PM: Adding info for pnp:00:06
> (XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4
> (XEN) ioapic_guest_write: new_entry=3D000109f1
> (XEN) ioapic_guest_write: old_entry=3D000009f1 pirq=3D4
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> PM: Adding info for pnp:00:07
> PM: Adding info for pnp:00:08
> pnp: PnP ACPI: found 9 devices
> xen_mem: Initialising balloon driver.
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=3Drouteirq".  If it helps, post a
> report
> pnp: 00:01: ioport range 0x800-0x85f could not be reserved
> pnp: 00:01: ioport range 0xc00-0xc7f has been reserved
> pnp: 00:01: ioport range 0x860-0x8ff has been reserved
> PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
> PCI: Bridge: 0000:00:01.0
>   IO window: disabled.
>   MEM window: fe500000-fe5fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1c.0
>   IO window: disabled.
>   MEM window: fe400000-fe4fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1c.1
>   IO window: disabled.
>   MEM window: fe300000-fe3fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1e.0
>   IO window: disabled.
>   MEM window: disabled.
>   PREFETCH window: disabled.
> ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:01.0 to 64
> ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1c.0 to 64
> ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
> PCI: Setting latency timer of device 0000:00:1c.1 to 64
> PCI: Setting latency timer of device 0000:00:1e.0 to 64
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> PM: Adding info for platform:pcspkr
> Simple Boot Flag at 0x7a set to 0x1
> IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
> audit: initializing netlink socket (disabled)
> audit(1334461010.944:1): initialized
> highmem bounce pool size: 64 pages
> VFS: Disk quotas dquot_6.5.1
> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> Initializing Cryptographic API
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> 0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
> PM: Adding info for platform:vesafb.0
> Floppy drive(s): fd0 is 1.44M
> floppy0: Unable to grab DMA2 for the floppy driver
> floppy0: no floppy controllers found
> RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
> loop: loaded (max 8 devices)
> e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k4
> e1000e: Copyright (c) 1999-2008 Intel Corporation.
> ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 21 (level, low) -> IRQ 18
> PCI: Setting latency timer of device 0000:00:19.0 to 64
> (XEN) physdev.c:155: dom0: wrong map_pirq type 3
> eth0: (PCI Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54
> eth0: Intel(R) PRO/1000 Network Connection
> eth0: MAC: 7, PHY: 8, PBA No: 2021ff-0ff
> Intel(R) Gigabit Ethernet Network Driver - version 1.2.45-k2
> Copyright (c) 2008 Intel Corporation.
> ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version
> 1.3.56.5-NAPI
> Copyright (c) 1999-2008 Intel Corporation.
> Xen virtual console successfully installed as xvc0
> Event-channel device installed.
> blktap_device_init: blktap device major 254
> blktap_ring_init: blktap ring major: 253
> netfront: Initialising virtual ethernet driver.
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=
=3Dxx
> PNP: No PS/2 controller found. Probing ports directly.
> PM: Adding info for platform:i8042
> serio: i8042 AUX port at 0x60,0x64 irq 12
> PM: Adding info for serio:serio0
> serio: i8042 KBD port at 0x60,0x64 irq 1
> PM: Adding info for serio:serio1
> mice: PS/2 mouse device common for all mice
> md: md driver 0.90.3 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
> md: bitmap version 4.39
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Using IPI No-Shortcut mode
> PCI IO multiplexer device installed.
> ACPI: (supports S0 S1 S3 S4 S5)
> BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
> Freeing unused kernel memory: 204k freed
> *usbcore: disagrees about version of symbol HYPERVISOR_shared_info*
> usbcore: Unknown symbol HYPERVISOR_shared_info
> ehci_hcd: Unknown symbol usb_hcd_pci_suspend
> ehci_hcd: Unknown symbol usb_free_urb
> ehci_hcd: Unknown symbol usb_hub_tt_clear_buffer
> ehci_hcd: Unknown symbol usb_hcd_resume_root_hub
> ehci_hcd: Unknown symbol usb_hcd_pci_probe
> ehci_hcd: Unknown symbol usb_calc_bus_time
> ehci_hcd: Unknown symbol usb_hcd_pci_resume
> ehci_hcd: Unknown symbol usb_get_urb
> ehci_hcd: Unknown symbol usb_hcd_giveback_urb
> ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
> ehci_hcd: Unknown symbol HYPERVISOR_shared_info
> ehci_hcd: Unknown symbol usb_hcd_pci_remove
> ehci_hcd: Unknown symbol usb_root_hub_lost_power
> ohci_hcd: Unknown symbol usb_hcd_pci_suspend
> ohci_hcd: Unknown symbol usb_hcd_resume_root_hub
> ohci_hcd: Unknown symbol usb_hcd_pci_probe
> ohci_hcd: Unknown symbol usb_disabled
> ohci_hcd: Unknown symbol usb_calc_bus_time
> ohci_hcd: Unknown symbol usb_hcd_pci_resume
> ohci_hcd: Unknown symbol usb_hcd_giveback_urb
> ohci_hcd: Unknown symbol usb_hcd_suspend_root_hub
> ohci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
> ohci_hcd: Unknown symbol HYPERVISOR_shared_info
> ohci_hcd: Unknown symbol usb_hcd_pci_remove
> ohci_hcd: Unknown symbol usb_root_hub_lost_power
> uhci_hcd: Unknown symbol usb_hcd_pci_suspend
> uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
> uhci_hcd: Unknown symbol usb_hcd_pci_probe
> uhci_hcd: Unknown symbol usb_check_bandwidth
> uhci_hcd: Unknown symbol usb_disabled
> uhci_hcd: Unknown symbol usb_release_bandwidth
> uhci_hcd: Unknown symbol usb_claim_bandwidth
> uhci_hcd: Unknown symbol usb_hcd_pci_resume
> uhci_hcd: Unknown symbol usb_hcd_giveback_urb
> uhci_hcd: Unknown symbol usb_hcd_poll_rh_status
> uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
> uhci_hcd: Unknown symbol HYPERVISOR_shared_info
> uhci_hcd: Unknown symbol usb_hcd_pci_remove
> uhci_hcd: Unknown symbol usb_root_hub_lost_power
> scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info
> scsi_mod: Unknown symbol HYPERVISOR_shared_info
> sd_mod: Unknown symbol scsi_print_sense_hdr
> sd_mod: Unknown symbol scsi_mode_sense
> sd_mod: Unknown symbol scsi_device_get
> sd_mod: Unknown symbol scsi_get_sense_info_fld
> sd_mod: Unknown symbol scsicam_bios_param
> sd_mod: Unknown symbol scsi_command_normalize_sense
> sd_mod: Unknown symbol scsi_test_unit_ready
> sd_mod: Unknown symbol scsi_block_when_processing_errors
> sd_mod: Unknown symbol scsi_register_driver
> sd_mod: Unknown symbol scsi_ioctl
> sd_mod: Unknown symbol scsi_nonblockable_ioctl
> sd_mod: Unknown symbol scsi_device_put
> sd_mod: Unknown symbol scsi_logging_level
> sd_mod: Unknown symbol scsi_execute_req
> sd_mod: Unknown symbol scsi_mode_select
> sd_mod: Unknown symbol scsi_print_sense
> sd_mod: Unknown symbol scsi_io_completion
> sd_mod: Unknown symbol scsi_set_medium_removal
> libata: Unknown symbol scsi_device_get
> libata: Unknown symbol scsi_remove_host
> libata: Unknown symbol scsi_schedule_eh
> libata: Unknown symbol scsi_device_set_state
> libata: Unknown symbol scsi_eh_finish_cmd
> libata: Unknown symbol scsi_device_put
> libata: Unknown symbol scsi_eh_flush_done_q
> libata: Unknown symbol scsi_host_put
> libata: Unknown symbol scsi_add_host
> libata: Unknown symbol scsi_rescan_device
> libata: Unknown symbol scsi_adjust_queue_depth
> libata: Unknown symbol scsi_execute_req
> libata: Unknown symbol scsi_req_abort_cmd
> libata: disagrees about version of symbol HYPERVISOR_shared_info
> libata: Unknown symbol HYPERVISOR_shared_info
> libata: Unknown symbol scsi_remove_device
> libata: Unknown symbol scsi_host_alloc
> libata: Unknown symbol __scsi_add_device
> ahci: Unknown symbol ata_scsi_ioctl
> ahci: Unknown symbol ata_port_abort
> ahci: Unknown symbol ata_std_bios_param
> ahci: Unknown symbol ata_std_postreset
> ahci: Unknown symbol ata_scsi_device_resume
> ahci: Unknown symbol ata_scsi_device_suspend
> ahci: Unknown symbol ata_tf_from_fis
> ahci: Unknown symbol ata_qc_complete_multiple
> ahci: Unknown symbol ata_noop_dev_select
> ahci: Unknown symbol ata_tf_to_fis
> ahci: Unknown symbol ata_pci_device_do_resume
> ahci: Unknown symbol ata_dev_classify
> ahci: Unknown symbol ata_scsi_release
> ahci: Unknown symbol ata_port_offline
> ahci: Unknown symbol ata_scsi_change_queue_depth
> ahci: Unknown symbol sata_std_hardreset
> ahci: Unknown symbol ata_pci_device_suspend
> ahci: Unknown symbol scsi_host_put
> ahci: Unknown symbol ata_port_online
> ahci: Unknown symbol ata_wait_register
> ahci: Unknown symbol ata_busy_sleep
> ahci: Unknown symbol ata_scsi_slave_config
> ahci: Unknown symbol ata_port_detach
> ahci: Unknown symbol ata_port_disable
> ahci: Unknown symbol ata_scsi_queuecmd
> ahci: Unknown symbol ata_scsi_slave_destroy
> ahci: Unknown symbol ata_ratelimit
> ahci: Unknown symbol ata_host_set_resume
> ahci: Unknown symbol ata_do_eh
> ahci: Unknown symbol ata_port_freeze
> ahci: Unknown symbol ata_std_prereset
> ahci: Unknown symbol ata_device_add
>
>
>
> --
> Best Regards,
> Bei Guan
>
>


--=20
Best Regards,
Bei Guan

--f46d041824ee481a8104bdb3daa3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Hi All,</div><div><br></div><div>I think this problem has been solved.=
</div><div>What I have done is that make clean the xen and tools, and remov=
e the build-linux-2.6.18-xen_x86_32 directory. Then, I re-compile the xen, =
tools, kernels, and reboot. It works fine.</div>
<div><br></div><div>Thank you all the same.</div><div><br></div><br><br><di=
v class=3D"gmail_quote">=E5=9C=A8 2012=E5=B9=B44=E6=9C=8815=E6=97=A5 =E4=B8=
=8A=E5=8D=884:11=EF=BC=8CBei Guan <span dir=3D"ltr">&lt;<a href=3D"mailto:g=
btju85@gmail.com">gbtju85@gmail.com</a>&gt;</span>=E5=86=99=E9=81=93=EF=BC=
=9A<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div>Hi All,</div><div><br></div><div>I want to shared a variable between D=
om0 and Xen. I add the variable into <b>struct shared_info</b> in code file=
 xen/include/public/xen.h and linux-2.6.18-xen.hg/include/xen/interface/xeb=
.h.</div>

<div>In Dom0, I use <b>shared_info_t *s =3D HYPERVISOR_shared_info</b> to g=
et the value of the shared variable.=C2=A0</div><div><br></div><div>However=
, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot into Dom0.=
=C2=A0The error from serial port debug is logged as the following.</div>

<div><br></div><div>Could anyone help me figure out the problem? Any sugges=
tion is appreciated. Thanks a lot.</div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div>=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=
=3D PuTTY log <a href=3D"tel:2012.04.15%2003" value=3D"+12012041503" target=
=3D"_blank">2012.04.15 03</a>:37:03 =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D=
~=3D~=3D</div>

<div>Restarting system.</div><div>(XEN) Domain 0 shutdown: rebooting machin=
e.</div><div>=C2=A0__ =C2=A0__ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_ =
=C2=A0_ =C2=A0 =C2=A0_ =C2=A0 ____ =C2=A0</div><div>=C2=A0\ \/ /___ _ __ =
=C2=A0 | || | =C2=A0/ | |___ \=C2=A0</div><div>=C2=A0 \ =C2=A0// _ \ &#39;_=
 \ =C2=A0| || |_ | | =C2=A0 __) |</div>

<div>=C2=A0 / =C2=A0\ =C2=A0__/ | | | |__ =C2=A0 _|| |_ / __/=C2=A0</div><d=
iv>=C2=A0/_/\_\___|_| |_| =C2=A0 =C2=A0|_|(_)_(_)_____|</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>(XEN) Xen ve=
rsion 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red =
Hat 4.1.2-33)) Sun Apr 15 03:24:23 CST 2012</div>

<div>(XEN) Latest ChangeSet: unavailable</div><div>(XEN) Bootloader: GNU GR=
UB 0.97</div><div>(XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1<=
/div><div>(XEN) Video information:</div><div>(XEN) =C2=A0VGA is text mode 8=
0x25, font 8x16</div>

<div>(XEN) =C2=A0VBE/DDC methods: V2; EDID transfer time: 1 seconds</div><d=
iv>(XEN) Disc information:</div><div>(XEN) =C2=A0Found 1 MBR signatures</di=
v><div>(XEN) =C2=A0Found 1 EDD information structures</div><div>(XEN) Xen-e=
820 RAM map:</div>

<div>(XEN) =C2=A00000000000000000 - 000000000009a800 (usable)</div><div>(XE=
N) =C2=A000000000000f0000 - 0000000000100000 (reserved)</div><div>(XEN) =C2=
=A00000000000100000 - 00000000cd9ffc00 (usable)</div><div>(XEN) =C2=A000000=
000cd9ffc00 - 00000000cda53c00 (ACPI NVS)</div>

<div>(XEN) =C2=A000000000cda53c00 - 00000000cda55c00 (ACPI data)</div><div>=
(XEN) =C2=A000000000cda55c00 - 00000000d0000000 (reserved)</div><div>(XEN) =
=C2=A000000000e0000000 - 00000000f0000000 (reserved)</div><div>(XEN) =C2=A0=
00000000fec00000 - 00000000fed00400 (reserved)</div>

<div>(XEN) =C2=A000000000fed20000 - 00000000feda0000 (reserved)</div><div>(=
XEN) =C2=A000000000fee00000 - 00000000fef00000 (reserved)</div><div>(XEN) =
=C2=A000000000ffb00000 - 0000000100000000 (reserved)</div><div>(XEN) =C2=A0=
0000000100000000 - 0000000128000000 (usable)</div>

<div>(XEN) System RAM: 3929MB (4023908kB)</div><div>(XEN) ACPI: RSDP 000FEC=
00, 0024 (r2 DELL =C2=A0)</div><div>(XEN) ACPI: XSDT 000FC7CB, 009C (r1 DEL=
L =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =
=C2=A0 =C2=A061)</div><div>(XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL =C2=A0 =
=C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =
=C2=A061)</div>

<div>(XEN) ACPI: DSDT FFE9CFF8, 54AD (r1 =C2=A0 DELL =C2=A0 =C2=A0dt_ex =C2=
=A0 =C2=A0 1000 INTL 20050624)</div><div>(XEN) ACPI: FACS CD9FFC00, 0040</d=
iv><div>(XEN) ACPI: SSDT FFEA25C4, 00AA (r1 =C2=A0 DELL =C2=A0 =C2=A0st_ex =
=C2=A0 =C2=A0 1000 INTL 20050624)</div><div>(XEN) ACPI: APIC 000FC9EF, 0092=
 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0=
 =C2=A0 =C2=A0 =C2=A061)</div>

<div>(XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XE=
N) ACPI: ASF! 000FCAA9, 0096 (r32 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XEN) ACPI=
: MCFG 000FCB3F, 003E (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div>

<div>(XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XE=
N) ACPI: TCPA 000FCDD9, 0032 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XEN) ACPI=
: DMAR 000FCE0B, 0120 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div>

<div>(XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XE=
N) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm =C2=A0Cpu0Ist =C2=A0 =C2=A0 =C2=A0 =
11 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm =C2=
=A0Cpu1Ist =C2=A0 =C2=A0 =C2=A0 11 INTL 20050624)</div>

<div>(XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm =C2=A0Cpu2Ist =C2=A0 =C2=A0=
 =C2=A0 11 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA0085B, 01B7 (r1 Dpg=
Pmm =C2=A0Cpu3Ist =C2=A0 =C2=A0 =C2=A0 11 INTL 20050624)</div><div>(XEN) AC=
PI: SSDT CDA00C64, 0190 (r1 DpgPmm =C2=A0 =C2=A0CpuPm =C2=A0 =C2=A0 =C2=A0 =
10 INTL 20050624)</div>

<div>(XEN) Xen heap: 9MB (9768kB)</div><div>(XEN) Domain heap initialised</=
div><div>(XEN) Processor #0 7:7 APIC version 20</div><div>(XEN) Processor #=
1 7:7 APIC version 20</div><div>(XEN) Processor #2 7:7 APIC version 20</div=
>

<div>(XEN) Processor #3 7:7 APIC version 20</div><div>(XEN) IOAPIC[0]: apic=
_id 8, version 32, address 0xfec00000, GSI 0-23</div><div>(XEN) Enabling AP=
IC mode: =C2=A0Flat. =C2=A0Using 1 I/O APICs</div><div>(XEN) Table is not f=
ound!</div>

<div>(XEN) Using scheduler: SMP Credit Scheduler (credit)</div><div>(XEN) D=
etected 2660.080 MHz processor.</div><div>(XEN) Intel VT-d Snoop Control no=
t enabled.</div><div>(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.</di=
v>

<div>(XEN) Intel VT-d Queued Invalidation not enabled.</div><div>(XEN) Inte=
l VT-d Interrupt Remapping not enabled.</div><div>(XEN) Intel VT-d Shared E=
PT tables not enabled.</div><div>(XEN) I/O virtualisation enabled</div>

<div>(XEN) =C2=A0- Dom0 mode: Relaxed</div><div>(XEN) ENABLING IO-APIC IRQs=
</div><div>(XEN) =C2=A0-&gt; Using new ACK method</div><div>(XEN) Platform =
timer is 14.318MHz HPET</div><div>=C3=BF(XEN) Allocated console ring of 16 =
KiB.</div>
<div>
(XEN) VMX: Supported advanced features:</div><div>(XEN) =C2=A0- APIC MMIO a=
ccess virtualisation</div><div>(XEN) =C2=A0- APIC TPR shadow</div><div>(XEN=
) =C2=A0- Virtual NMI</div><div>(XEN) =C2=A0- MSR direct-access bitmap</div=
><div>(XEN) HVM: ASIDs disabled.</div>

<div>(XEN) HVM: VMX enabled</div><div>(XEN) Brought up 4 CPUs</div><div>(XE=
N) *** LOADING DOMAIN 0 ***</div><div>(XEN) =C2=A0Xen =C2=A0kernel: 32-bit,=
 PAE, lsb</div><div>(XEN) =C2=A0Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc010=
0000 -&gt; 0xc04c923c</div>

<div>(XEN) PHYSICAL MEMORY ARRANGEMENT:</div><div>(XEN) =C2=A0Dom0 alloc.: =
=C2=A0 0000000124000000-&gt;0000000125000000 (953327 pages to be allocated)=
</div><div>(XEN) =C2=A0Init. ramdisk: 00000001278fe000-&gt;0000000127fff400=
</div><div>

(XEN) VIRTUAL MEMORY ARRANGEMENT:</div><div>(XEN) =C2=A0Loaded kernel: c010=
0000-&gt;c04c923c</div><div>(XEN) =C2=A0Init. ramdisk: c04ca000-&gt;c0bcb40=
0</div><div>(XEN) =C2=A0Phys-Mach map: c0bcc000-&gt;c0f74bc4</div><div>(XEN=
) =C2=A0Start info: =C2=A0 =C2=A0c0f75000-&gt;c0f7547c</div>

<div>(XEN) =C2=A0Page tables: =C2=A0 c0f76000-&gt;c0f85000</div><div>(XEN) =
=C2=A0Boot stack: =C2=A0 =C2=A0c0f85000-&gt;c0f86000</div><div>(XEN) =C2=A0=
TOTAL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 c0000000-&gt;c1400000</div><div>(XEN) =
=C2=A0ENTRY ADDRESS: c0100000</div><div>(XEN) Dom0 has maximum 4 VCPUs</div=
>

<div>(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow</div><div>=
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault</div><di=
v>(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault =
addr ffffff000, iommu reg =3D fff16000</div>

<div>(XEN) DMAR:[fault reason 05h] PTE Write access is not set</div><div>(X=
EN) Scrubbing Free RAM: .done.</div><div>(XEN) Xen trace buffers: disabled<=
/div><div>(XEN) Std. Loglevel: Errors and warnings</div><div>(XEN) Guest Lo=
glevel: Nothing (Rate-limited: Errors and warnings)</div>

<div>(XEN) Xen is relinquishing VGA console.</div><div>(XEN) *** Serial inp=
ut -&gt; DOM0 (type &#39;CTRL-a&#39; three times to switch input to Xen)</d=
iv><div>(XEN) Freed 184kB init memory.</div><div>Linux version 2.6.18.8-xen=
 (root@localhost.localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red H=
at 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012</div>

<div>BIOS-provided physical RAM map:</div><div>=C2=A0Xen: 0000000000000000 =
- 00000000eaaf1000 (usable)</div><div>3026MB HIGHMEM available.</div><div>7=
27MB LOWMEM available.</div><div>NX (Execute Disable) protection: active</d=
iv>

<div>On node 0 totalpages: 961265</div><div>=C2=A0 DMA zone: 4096 pages, LI=
FO batch:0</div><div>=C2=A0 Normal zone: 182270 pages, LIFO batch:31</div><=
div>=C2=A0 HighMem zone: 774899 pages, LIFO batch:31</div><div>found SMP MP=
-table at 000fe710</div>

<div>DMI 2.5 present.</div><div>ACPI: RSDP (v002 DELL =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0) @ 0x000fec00</div><div>ACPI: XSDT (v001 DELL =C2=
=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00x00000061) @ 0x000fc7cb</=
div><div>ACPI: FADT (v003 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 AS=
L =C2=A00x00000061) @ 0x000fc8fb</div>

<div>ACPI: SSDT (v001 =C2=A0 DELL =C2=A0 =C2=A0st_ex 0x00001000 INTL 0x2005=
0624) @ 0xffea25c4</div><div>ACPI: MADT (v001 DELL =C2=A0 =C2=A0B10K =C2=A0=
 =C2=A00x00000015 ASL =C2=A00x00000061) @ 0x000fc9ef</div><div>ACPI: BOOT (=
v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00x00000061) @=
 0x000fca81</div>

<div>ACPI: ASF! (v032 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =
=C2=A00x00000061) @ 0x000fcaa9</div><div>ACPI: MCFG (v001 DELL =C2=A0 =C2=
=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00x00000061) @ 0x000fcb3f</div><di=
v>ACPI: HPET (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=
=A00x00000061) @ 0x000fcb7d</div>

<div>ACPI: TCPA (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =
=C2=A00x00000061) @ 0x000fcdd9</div><div>=C2=A0 &gt;&gt;&gt; ERROR: Invalid=
 checksum</div><div>ACPI: DMAR (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x=
00000015 ASL =C2=A00x00000061) @ 0x000fce0b</div><div>

ACPI: SLIC (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00=
x00000061) @ 0x000fcbb5</div><div>ACPI: SSDT (v001 DpgPmm =C2=A0Cpu0Ist 0x0=
0000011 INTL 0x20050624) @ 0xcd9ffc40</div><div>ACPI: SSDT (v001 DpgPmm =C2=
=A0Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049</div>

<div>ACPI: SSDT (v001 DpgPmm =C2=A0Cpu2Ist 0x00000011 INTL 0x20050624) @ 0x=
cda00452</div><div>ACPI: SSDT (v001 DpgPmm =C2=A0Cpu3Ist 0x00000011 INTL 0x=
20050624) @ 0xcda0085b</div><div>ACPI: SSDT (v001 DpgPmm =C2=A0 =C2=A0CpuPm=
 0x00000010 INTL 0x20050624) @ 0xcda00c64</div>

<div>ACPI: DSDT (v001 =C2=A0 DELL =C2=A0 =C2=A0dt_ex 0x00001000 INTL 0x2005=
0624) @ 0x00000000</div><div>ACPI: Local APIC address 0xfee00000</div><div>=
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)</div><div>ACPI: LAPIC (a=
cpi_id[0x02] lapic_id[0x01] enabled)</div>

<div>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)</div><div>ACPI: LAP=
IC (acpi_id[0x04] lapic_id[0x03] enabled)</div><div>ACPI: LAPIC (acpi_id[0x=
05] lapic_id[0x00] disabled)</div><div>ACPI: LAPIC (acpi_id[0x06] lapic_id[=
0x01] disabled)</div>

<div>ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)</div><div>ACPI: LA=
PIC (acpi_id[0x08] lapic_id[0x03] disabled)</div><div>ACPI: LAPIC_NMI (acpi=
_id[0xff] high level lint[0x1])</div><div>ACPI: IOAPIC (id[0x08] address[0x=
fec00000] gsi_base[0])</div>

<div>IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23</div><d=
iv>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)</div><div>ACPI:=
 INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)</div><div>ACPI: IRQ0=
 used by override.</div>

<div>ACPI: IRQ2 used by override.</div><div>ACPI: IRQ9 used by override.</d=
iv><div>Enabling APIC mode: =C2=A0Flat. =C2=A0Using 1 I/O APICs</div><div>U=
sing ACPI (MADT) for SMP configuration information</div><div>Allocating PCI=
 resources starting at d1000000 (gap: d0000000:10000000)</div>

<div>Detected 2660.681 MHz processor.</div><div>Built 1 zonelists. =C2=A0To=
tal pages: 961265</div><div>Kernel command line: ro root=3D/dev/sda11 conso=
le=3Dhvc0 console=3Dtty0 console=3DttyS0,115200n8 debug selinux=3D0</div><d=
iv>Enabling fast FPU save and restore... done.</div>

<div>Enabling unmasked SIMD FPU exception support... done.</div><div>Initia=
lizing CPU#0</div><div>PID hash table entries: 4096 (order: 12, 16384 bytes=
)</div><div>Xen reported: 2660.080 MHz processor.</div><div>Console: colour=
 VGA+ 80x25</div>

<div>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)</div>=
<div>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)</div><d=
iv>Software IO TLB enabled:=C2=A0</div><div>=C2=A0Aperture: =C2=A0 =C2=A0 6=
4 megabytes</div>

<div>=C2=A0Kernel range: c31fd000 - c71fd000</div><div>=C2=A0Address size: =
27 bits</div><div>vmalloc area: ee000000-f51fe000, maxmem 2d7fe000</div><di=
v>Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,=
 908k data, 204k init, 3099596k highmem)</div>

<div>Checking if this processor honours the WP bit even in supervisor mode.=
.. Ok.</div><div>Calibrating delay using timer specific routine.. 5347.97 B=
ogoMIPS (lpj=3D26739870)</div><div>Security Framework v1.0.0 initialized</d=
iv>

<div>Capability LSM initialized</div><div>Mount-cache hash table entries: 5=
12</div><div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 =
00000000 80080281 00000000 00000000</div><div>CPU: After vendor identify, c=
aps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div>

<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000</div><div>Checking &#39;hlt&#39; instruction... OK=
.</div>

<div>SMP alternatives: switching to UP code</div><div>ACPI: Core revision 2=
0060707</div><div>ENABLING IO-APIC IRQs</div><div>SMP alternatives: switchi=
ng to SMP code</div><div>Initializing CPU#1</div><div>Initializing CPU#2</d=
iv>

<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>
Brought up 4 CPUs</div>
<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000&lt;6&gt;Initializing CPU#3</div><div><br></div>

<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>
CPU: L1 I cache: 32K, L1 D cache: 32K</div>
<div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3f5 00=
100000 00000000 00000140 80080281 00000000 00000000</div><div>CPU: After ge=
neric identify, caps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000=
 00000000</div>

<div>CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000 =
80080281 00000000 00000000</div><div>CPU: L1 I cache: 32K, L1 D cache: 32K<=
/div><div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3=
f5 00100000 00000000 00000140 80080281 00000000 00000000</div>

<div>migration_cost=3D12</div><div>checking if image is initramfs... it is<=
/div><div>Freeing initrd memory: 7173k freed</div><div>PM: Adding info for =
No Bus:platform</div><div>NET: Registered protocol family 16</div><div>PM: =
Adding info for No Bus:xen</div>

<div>PM: Adding info for No Bus:xen-backend</div><div>ACPI: bus type pci re=
gistered</div><div>PCI: MCFG configuration 0: base e0000000 segment 0 buses=
 0 - 255</div><div>PCI: MCFG area at e0000000 reserved in E820</div><div>

PCI: Using MMCONFIG</div><div>Setting up standard PCI resources</div><div>A=
CPI: Interpreter enabled</div><div>ACPI: Using IOAPIC for interrupt routing=
</div><div>PM: Adding info for acpi:acpi</div><div>ACPI: PCI Root Bridge [P=
CI0] (0000:00)</div>

<div>PCI: Probing PCI hardware (bus 00)</div><div>PM: Adding info for No Bu=
s:pci0000:00</div><div>ACPI: Assume root bridge [\_SB_.PCI0] bus is 0</div>=
<div>Boot video device is 0000:00:02.0</div><div>PCI: Transparent bridge - =
0000:00:1e.0</div>

<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]</div><div>PM: Addi=
ng info for pci:0000:00:00.0</div><div>PM: Adding info for pci:0000:00:01.0=
</div><div>PM: Adding info for pci:0000:00:02.0</div><div>PM: Adding info f=
or pci:0000:00:02.1</div>

<div>PM: Adding info for pci:0000:00:03.0</div><div>PM: Adding info for pci=
:0000:00:03.2</div><div>PM: Adding info for pci:0000:00:03.3</div><div>PM: =
Adding info for pci:0000:00:19.0</div><div>PM: Adding info for pci:0000:00:=
1a.0</div>

<div>PM: Adding info for pci:0000:00:1a.1</div><div>PM: Adding info for pci=
:0000:00:1a.2</div><div>PM: Adding info for pci:0000:00:1a.7</div><div>PM: =
Adding info for pci:0000:00:1b.0</div><div>PM: Adding info for pci:0000:00:=
1c.0</div>

<div>PM: Adding info for pci:0000:00:1c.1</div><div>PM: Adding info for pci=
:0000:00:1d.0</div><div>PM: Adding info for pci:0000:00:1d.1</div><div>PM: =
Adding info for pci:0000:00:1d.2</div><div>PM: Adding info for pci:0000:00:=
1d.7</div>

<div>PM: Adding info for pci:0000:00:1e.0</div><div>PM: Adding info for pci=
:0000:00:1f.0</div><div>PM: Adding info for pci:0000:00:1f.2</div><div>PM: =
Adding info for pci:0000:00:1f.3</div><div>ACPI: PCI Interrupt Routing Tabl=
e [\_SB_.PCI0.PCI4._PRT]</div>

<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]</div><div>ACP=
I: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]</div><div>ACPI: PCI I=
nterrupt Routing Table [\_SB_.PCI0.PCI1._PRT]</div><div>ACPI: PCI Interrupt=
 Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)</div>

<div>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *<a href=3D"tel:5%206%207%20=
9%2010%2011%2012" value=3D"+15679101112" target=3D"_blank">5 6 7 9 10 11 12=
</a> 15)</div><div>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11=
 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, dis=
abled.</div><div>ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 1=
2 15)</div><div>ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *<a href=3D"tel:5=
%206%207%209%2010%2011%2012" value=3D"+15679101112" target=3D"_blank">5 6 7=
 9 10 11 12</a> 15)</div>

<div>ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div><=
div>Linux Plug and Play Support v0.97 (c) Adam Belay</div><div>pnp: PnP ACP=
I init</div><div>PM: Adding info for No Bus:pnp0</div><div>PM: Adding info =
for pnp:00:00</div>

<div>PM: Adding info for pnp:00:01</div><div>PM: Adding info for pnp:00:02<=
/div><div>PM: Adding info for pnp:00:03</div><div>PM: Adding info for pnp:0=
0:04</div><div>PM: Adding info for pnp:00:05</div><div>PM: Adding info for =
pnp:00:06</div>

<div>(XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4</div><div>(XEN) i=
oapic_guest_write: new_entry=3D000109f1</div><div>(XEN) ioapic_guest_write:=
 old_entry=3D000009f1 pirq=3D4</div><div>(XEN) ioapic_guest_write: Attempt =
to modify IO-APIC pin for in-use IRQ!</div>

<div>PM: Adding info for pnp:00:07</div><div>PM: Adding info for pnp:00:08<=
/div><div>pnp: PnP ACPI: found 9 devices</div><div>xen_mem: Initialising ba=
lloon driver.</div><div>PCI: Using ACPI for IRQ routing</div><div>PCI: If a=
 device doesn&#39;t work, try &quot;pci=3Drouteirq&quot;. =C2=A0If it helps=
, post a report</div>

<div>pnp: 00:01: ioport range 0x800-0x85f could not be reserved</div><div>p=
np: 00:01: ioport range 0xc00-0xc7f has been reserved</div><div>pnp: 00:01:=
 ioport range 0x860-0x8ff has been reserved</div><div>PCI: Ignore bogus res=
ource 6 [0:0] of 0000:00:02.0</div>

<div>PCI: Bridge: 0000:00:01.0</div><div>=C2=A0 IO window: disabled.</div><=
div>=C2=A0 MEM window: fe500000-fe5fffff</div><div>=C2=A0 PREFETCH window: =
disabled.</div><div>PCI: Bridge: 0000:00:1c.0</div><div>=C2=A0 IO window: d=
isabled.</div><div>

=C2=A0 MEM window: fe400000-fe4fffff</div><div>=C2=A0 PREFETCH window: disa=
bled.</div><div>PCI: Bridge: 0000:00:1c.1</div><div>=C2=A0 IO window: disab=
led.</div><div>=C2=A0 MEM window: fe300000-fe3fffff</div><div>=C2=A0 PREFET=
CH window: disabled.</div>

<div>PCI: Bridge: 0000:00:1e.0</div><div>=C2=A0 IO window: disabled.</div><=
div>=C2=A0 MEM window: disabled.</div><div>=C2=A0 PREFETCH window: disabled=
.</div><div>ACPI: PCI Interrupt 0000:00:01.0[A] -&gt; GSI 16 (level, low) -=
&gt; IRQ 16</div>

<div>PCI: Setting latency timer of device 0000:00:01.0 to 64</div><div>ACPI=
: PCI Interrupt 0000:00:1c.0[A] -&gt; GSI 16 (level, low) -&gt; IRQ 16</div=
><div>PCI: Setting latency timer of device 0000:00:1c.0 to 64</div><div>

ACPI: PCI Interrupt 0000:00:1c.1[B] -&gt; GSI 17 (level, low) -&gt; IRQ 17<=
/div><div>PCI: Setting latency timer of device 0000:00:1c.1 to 64</div><div=
>PCI: Setting latency timer of device 0000:00:1e.0 to 64</div><div>NET: Reg=
istered protocol family 2</div>

<div>IP route cache hash table entries: 32768 (order: 5, 131072 bytes)</div=
><div>TCP established hash table entries: 131072 (order: 8, 1048576 bytes)<=
/div><div>TCP bind hash table entries: 65536 (order: 7, 524288 bytes)</div>

<div>TCP: Hash tables configured (established 131072 bind 65536)</div><div>=
TCP reno registered</div><div>PM: Adding info for platform:pcspkr</div><div=
>Simple Boot Flag at 0x7a set to 0x1</div><div>IA-32 Microcode Update Drive=
r: v1.14a-xen &lt;<a href=3D"mailto:tigran@veritas.com" target=3D"_blank">t=
igran@veritas.com</a>&gt;</div>

<div>audit: initializing netlink socket (disabled)</div><div>audit(13344610=
10.944:1): initialized</div><div>highmem bounce pool size: 64 pages</div><d=
iv>VFS: Disk quotas dquot_6.5.1</div><div>Dquot-cache hash table entries: 1=
024 (order 0, 4096 bytes)</div>

<div>Initializing Cryptographic API</div><div>io scheduler noop registered<=
/div><div>io scheduler anticipatory registered</div><div>io scheduler deadl=
ine registered</div><div>io scheduler cfq registered (default)</div><div>

0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001</div><div>PM: =
Adding info for platform:vesafb.0</div><div>Floppy drive(s): fd0 is 1.44M</=
div><div>floppy0: Unable to grab DMA2 for the floppy driver</div><div>
floppy0: no floppy controllers found</div>
<div>RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize=
</div><div>loop: loaded (max 8 devices)</div><div>e1000e: Intel(R) PRO/1000=
 Network Driver - 0.3.3.3-k4</div><div>e1000e: Copyright (c) 1999-2008 Inte=
l Corporation.</div>

<div>ACPI: PCI Interrupt 0000:00:19.0[A] -&gt; GSI 21 (level, low) -&gt; IR=
Q 18</div><div>PCI: Setting latency timer of device 0000:00:19.0 to 64</div=
><div>(XEN) physdev.c:155: dom0: wrong map_pirq type 3</div><div>eth0: (PCI=
 Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54</div>

<div>eth0: Intel(R) PRO/1000 Network Connection</div><div>eth0: MAC: 7, PHY=
: 8, PBA No: 2021ff-0ff</div><div>Intel(R) Gigabit Ethernet Network Driver =
- version 1.2.45-k2</div><div>Copyright (c) 2008 Intel Corporation.</div>

<div>ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 1.3.56=
.5-NAPI</div><div>Copyright (c) 1999-2008 Intel Corporation.</div><div>Xen =
virtual console successfully installed as xvc0</div><div>Event-channel devi=
ce installed.</div>

<div>blktap_device_init: blktap device major 254</div><div>blktap_ring_init=
: blktap ring major: 253</div><div>netfront: Initialising virtual ethernet =
driver.</div><div>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2<=
/div>

<div>ide: Assuming 33MHz system bus speed for PIO modes; override with ideb=
us=3Dxx</div><div>PNP: No PS/2 controller found. Probing ports directly.</d=
iv><div>PM: Adding info for platform:i8042</div><div>serio: i8042 AUX port =
at 0x60,0x64 irq 12</div>

<div>PM: Adding info for serio:serio0</div><div>serio: i8042 KBD port at 0x=
60,0x64 irq 1</div><div>PM: Adding info for serio:serio1</div><div>mice: PS=
/2 mouse device common for all mice</div><div>md: md driver 0.90.3 MAX_MD_D=
EVS=3D256, MD_SB_DISKS=3D27</div>

<div>md: bitmap version 4.39</div><div>NET: Registered protocol family 1</d=
iv><div>NET: Registered protocol family 17</div><div>Using IPI No-Shortcut =
mode</div><div>PCI IO multiplexer device installed.</div><div>ACPI: (suppor=
ts S0 S1 S3 S4 S5)</div>

<div>BIOS EDD facility v0.16 2004-Jun-25, 1 devices found</div><div>Freeing=
 unused kernel memory: 204k freed</div><div><b>usbcore: disagrees about ver=
sion of symbol HYPERVISOR_shared_info</b></div><div>usbcore: Unknown symbol=
 HYPERVISOR_shared_info</div>

<div>ehci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ehci_hcd: Unkno=
wn symbol usb_free_urb</div><div>ehci_hcd: Unknown symbol usb_hub_tt_clear_=
buffer</div><div>ehci_hcd: Unknown symbol usb_hcd_resume_root_hub</div>

<div>ehci_hcd: Unknown symbol usb_hcd_pci_probe</div><div>ehci_hcd: Unknown=
 symbol usb_calc_bus_time</div><div>ehci_hcd: Unknown symbol usb_hcd_pci_re=
sume</div><div>ehci_hcd: Unknown symbol usb_get_urb</div><div>ehci_hcd: Unk=
nown symbol usb_hcd_giveback_urb</div>

<div>ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>ehci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ehci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>ehci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>

<div>ohci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ohci_hcd: Unkno=
wn symbol usb_hcd_resume_root_hub</div><div>ohci_hcd: Unknown symbol usb_hc=
d_pci_probe</div><div>ohci_hcd: Unknown symbol usb_disabled</div><div>
ohci_hcd: Unknown symbol usb_calc_bus_time</div>
<div>ohci_hcd: Unknown symbol usb_hcd_pci_resume</div><div>ohci_hcd: Unknow=
n symbol usb_hcd_giveback_urb</div><div>ohci_hcd: Unknown symbol usb_hcd_su=
spend_root_hub</div><div>ohci_hcd: disagrees about version of symbol HYPERV=
ISOR_shared_info</div>

<div>ohci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ohci_hcd: Un=
known symbol usb_hcd_pci_remove</div><div>ohci_hcd: Unknown symbol usb_root=
_hub_lost_power</div><div>uhci_hcd: Unknown symbol usb_hcd_pci_suspend</div=
>

<div>uhci_hcd: Unknown symbol usb_hcd_resume_root_hub</div><div>uhci_hcd: U=
nknown symbol usb_hcd_pci_probe</div><div>uhci_hcd: Unknown symbol usb_chec=
k_bandwidth</div><div>uhci_hcd: Unknown symbol usb_disabled</div><div>
uhci_hcd: Unknown symbol usb_release_bandwidth</div>
<div>uhci_hcd: Unknown symbol usb_claim_bandwidth</div><div>uhci_hcd: Unkno=
wn symbol usb_hcd_pci_resume</div><div>uhci_hcd: Unknown symbol usb_hcd_giv=
eback_urb</div><div>uhci_hcd: Unknown symbol usb_hcd_poll_rh_status</div>

<div>uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>uhci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>uhci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>uhci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>

<div>scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>scsi_mod: Unknown symbol HYPERVISOR_shared_info</div><div>sd_mod: Un=
known symbol scsi_print_sense_hdr</div><div>sd_mod: Unknown symbol scsi_mod=
e_sense</div>

<div>sd_mod: Unknown symbol scsi_device_get</div><div>sd_mod: Unknown symbo=
l scsi_get_sense_info_fld</div><div>sd_mod: Unknown symbol scsicam_bios_par=
am</div><div>sd_mod: Unknown symbol scsi_command_normalize_sense</div>
<div>
sd_mod: Unknown symbol scsi_test_unit_ready</div><div>sd_mod: Unknown symbo=
l scsi_block_when_processing_errors</div><div>sd_mod: Unknown symbol scsi_r=
egister_driver</div><div>sd_mod: Unknown symbol scsi_ioctl</div><div>sd_mod=
: Unknown symbol scsi_nonblockable_ioctl</div>

<div>sd_mod: Unknown symbol scsi_device_put</div><div>sd_mod: Unknown symbo=
l scsi_logging_level</div><div>sd_mod: Unknown symbol scsi_execute_req</div=
><div>sd_mod: Unknown symbol scsi_mode_select</div><div>sd_mod: Unknown sym=
bol scsi_print_sense</div>

<div>sd_mod: Unknown symbol scsi_io_completion</div><div>sd_mod: Unknown sy=
mbol scsi_set_medium_removal</div><div>libata: Unknown symbol scsi_device_g=
et</div><div>libata: Unknown symbol scsi_remove_host</div><div>libata: Unkn=
own symbol scsi_schedule_eh</div>

<div>libata: Unknown symbol scsi_device_set_state</div><div>libata: Unknown=
 symbol scsi_eh_finish_cmd</div><div>libata: Unknown symbol scsi_device_put=
</div><div>libata: Unknown symbol scsi_eh_flush_done_q</div><div>libata: Un=
known symbol scsi_host_put</div>

<div>libata: Unknown symbol scsi_add_host</div><div>libata: Unknown symbol =
scsi_rescan_device</div><div>libata: Unknown symbol scsi_adjust_queue_depth=
</div><div>libata: Unknown symbol scsi_execute_req</div><div>libata: Unknow=
n symbol scsi_req_abort_cmd</div>

<div>libata: disagrees about version of symbol HYPERVISOR_shared_info</div>=
<div>libata: Unknown symbol HYPERVISOR_shared_info</div><div>libata: Unknow=
n symbol scsi_remove_device</div><div>libata: Unknown symbol scsi_host_allo=
c</div>

<div>libata: Unknown symbol __scsi_add_device</div><div>ahci: Unknown symbo=
l ata_scsi_ioctl</div><div>ahci: Unknown symbol ata_port_abort</div><div>ah=
ci: Unknown symbol ata_std_bios_param</div><div>ahci: Unknown symbol ata_st=
d_postreset</div>

<div>ahci: Unknown symbol ata_scsi_device_resume</div><div>ahci: Unknown sy=
mbol ata_scsi_device_suspend</div><div>ahci: Unknown symbol ata_tf_from_fis=
</div><div>ahci: Unknown symbol ata_qc_complete_multiple</div><div>ahci: Un=
known symbol ata_noop_dev_select</div>

<div>ahci: Unknown symbol ata_tf_to_fis</div><div>ahci: Unknown symbol ata_=
pci_device_do_resume</div><div>ahci: Unknown symbol ata_dev_classify</div><=
div>ahci: Unknown symbol ata_scsi_release</div><div>ahci: Unknown symbol at=
a_port_offline</div>

<div>ahci: Unknown symbol ata_scsi_change_queue_depth</div><div>ahci: Unkno=
wn symbol sata_std_hardreset</div><div>ahci: Unknown symbol ata_pci_device_=
suspend</div><div>ahci: Unknown symbol scsi_host_put</div><div>ahci: Unknow=
n symbol ata_port_online</div>

<div>ahci: Unknown symbol ata_wait_register</div><div>ahci: Unknown symbol =
ata_busy_sleep</div><div>ahci: Unknown symbol ata_scsi_slave_config</div><d=
iv>ahci: Unknown symbol ata_port_detach</div><div>ahci: Unknown symbol ata_=
port_disable</div>

<div>ahci: Unknown symbol ata_scsi_queuecmd</div><div>ahci: Unknown symbol =
ata_scsi_slave_destroy</div><div>ahci: Unknown symbol ata_ratelimit</div><d=
iv>ahci: Unknown symbol ata_host_set_resume</div><div>ahci: Unknown symbol =
ata_do_eh</div>

<div>ahci: Unknown symbol ata_port_freeze</div><div>ahci: Unknown symbol at=
a_std_prereset</div><div>ahci: Unknown symbol ata_device_add</div><span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><div>=C2=A0 =C2=A0 =C2=A0</div><div><=
br></div><div>
<br></div>-- <br>Best Regards,<div>Bei Guan</div>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Best Regards,<div>Bei Guan</div><br>

--f46d041824ee481a8104bdb3daa3--


--===============2998025191639309644==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2998025191639309644==--


From xen-devel-bounces@lists.xen.org Sun Apr 15 08:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 08:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJLE7-0008GI-QC; Sun, 15 Apr 2012 08:54:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1SJLE6-0008GB-7E
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 08:54:30 +0000
Received: from [193.109.254.147:12343] by server-9.bemta-14.messagelabs.com id
	36/FF-05787-5CC8A8F4; Sun, 15 Apr 2012 08:54:29 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334480066!4657513!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6116 invoked from network); 15 Apr 2012 08:54:26 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 08:54:26 -0000
Received: by wibhn6 with SMTP id hn6so3556152wib.14
	for <xen-devel@lists.xen.org>; Sun, 15 Apr 2012 01:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=ZfAkAuV4YBIB0A7UZS3F1Cmj3UVbwUABvNfqQTM5tEQ=;
	b=dcTBBkfPnwTWkrqSRV7Fd72uoQ4G3dhI9aYTfJbUp5ouwnAFlpJGyRRf+s8Vtbs79w
	AvShDqANPjZLPPh9HzQoGmC2yy+GmSkFKBk9wkqN71wc35KYkr3Qqck3yUQwEoYw33C0
	TZJQE4T8QabkfF6E+heDKC0te29qDu14U/tKeZgZYFtSx8xNK8ztcHgtWi+MkU0Z1cYe
	aHXiFZQSlvEipDTIw1abZ68u3oR3edLaaOVCSUEKTLAeovoZfaRKczCQOQQxiyqT+Wo4
	1m8+aCJjUlacQRe/fTJc8I7ksfe53UesCHbfcx08XVbMOdjo9U9veNkD2SzhyyhqWrR6
	kccQ==
MIME-Version: 1.0
Received: by 10.180.100.230 with SMTP id fb6mr6486355wib.3.1334480065796; Sun,
	15 Apr 2012 01:54:25 -0700 (PDT)
Received: by 10.223.123.138 with HTTP; Sun, 15 Apr 2012 01:54:25 -0700 (PDT)
In-Reply-To: <CAEQjb-SGFkWu6cCMNyeAF8YqA3Hua_9s99OeuO2MsiKysKYkHg@mail.gmail.com>
References: <CAEQjb-SGFkWu6cCMNyeAF8YqA3Hua_9s99OeuO2MsiKysKYkHg@mail.gmail.com>
Date: Sun, 15 Apr 2012 16:54:25 +0800
Message-ID: <CAEQjb-RriwgVQ4uNindutLKTxqk2g_5r=aDQLNQyYy7FnG+U_Q@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Error: disagrees about version of symbol
	HYPERVISOR_shared_info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2998025191639309644=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2998025191639309644==
Content-Type: multipart/alternative; boundary=f46d041824ee481a8104bdb3daa3

--f46d041824ee481a8104bdb3daa3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi All,

I think this problem has been solved.
What I have done is that make clean the xen and tools, and remove the
build-linux-2.6.18-xen_x86_32 directory. Then, I re-compile the xen, tools,
kernels, and reboot. It works fine.

Thank you all the same.



=E5=9C=A8 2012=E5=B9=B44=E6=9C=8815=E6=97=A5 =E4=B8=8A=E5=8D=884:11=EF=BC=
=8CBei Guan <gbtju85@gmail.com>=E5=86=99=E9=81=93=EF=BC=9A

> Hi All,
>
> I want to shared a variable between Dom0 and Xen. I add the variable into
> *struct shared_info* in code file xen/include/public/xen.h and
> linux-2.6.18-xen.hg/include/xen/interface/xeb.h.
> In Dom0, I use *shared_info_t *s =3D HYPERVISOR_shared_info* to get the
> value of the shared variable.
>
> However, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot
> into Dom0. The error from serial port debug is logged as the following.
>
> Could anyone help me figure out the problem? Any suggestion is
> appreciated. Thanks a lot.
>
>
>
>
> =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D PuTTY log 2012.04.15 03:3=
7:03
> =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D
> Restarting system.
> (XEN) Domain 0 shutdown: rebooting machine.
>  __  __            _  _    _   ____
>  \ \/ /___ _ __   | || |  / | |___ \
>   \  // _ \ '_ \  | || |_ | |   __) |
>   /  \  __/ | | | |__   _|| |_ / __/
>  /_/\_\___|_| |_|    |_|(_)_(_)_____|
>
> (XEN) Xen version 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 =
20070925 (Red
> Hat 4.1.2-33)) Sun Apr 15 03:24:23 CST 2012
> (XEN) Latest ChangeSet: unavailable
> (XEN) Bootloader: GNU GRUB 0.97
> (XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009a800 (usable)
> (XEN)  00000000000f0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000cd9ffc00 (usable)
> (XEN)  00000000cd9ffc00 - 00000000cda53c00 (ACPI NVS)
> (XEN)  00000000cda53c00 - 00000000cda55c00 (ACPI data)
> (XEN)  00000000cda55c00 - 00000000d0000000 (reserved)
> (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fed00400 (reserved)
> (XEN)  00000000fed20000 - 00000000feda0000 (reserved)
> (XEN)  00000000fee00000 - 00000000fef00000 (reserved)
> (XEN)  00000000ffb00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000128000000 (usable)
> (XEN) System RAM: 3929MB (4023908kB)
> (XEN) ACPI: RSDP 000FEC00, 0024 (r2 DELL  )
> (XEN) ACPI: XSDT 000FC7CB, 009C (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: DSDT FFE9CFF8, 54AD (r1   DELL    dt_ex     1000 INTL 2005062=
4)
> (XEN) ACPI: FACS CD9FFC00, 0040
> (XEN) ACPI: SSDT FFEA25C4, 00AA (r1   DELL    st_ex     1000 INTL 2005062=
4)
> (XEN) ACPI: APIC 000FC9EF, 0092 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: ASF! 000FCAA9, 0096 (r32 DELL    B10K          15 ASL
>  61)
> (XEN) ACPI: MCFG 000FCB3F, 003E (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: TCPA 000FCDD9, 0032 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: DMAR 000FCE0B, 0120 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL    B10K          15 ASL        6=
1)
> (XEN) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm  Cpu0Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm  Cpu1Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm  Cpu2Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA0085B, 01B7 (r1 DpgPmm  Cpu3Ist       11 INTL 2005062=
4)
> (XEN) ACPI: SSDT CDA00C64, 0190 (r1 DpgPmm    CpuPm       10 INTL 2005062=
4)
> (XEN) Xen heap: 9MB (9768kB)
> (XEN) Domain heap initialised
> (XEN) Processor #0 7:7 APIC version 20
> (XEN) Processor #1 7:7 APIC version 20
> (XEN) Processor #2 7:7 APIC version 20
> (XEN) Processor #3 7:7 APIC version 20
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) Table is not found!
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2660.080 MHz processor.
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation not enabled.
> (XEN) Intel VT-d Interrupt Remapping not enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.
> (XEN) I/O virtualisation enabled
> (XEN)  - Dom0 mode: Relaxed
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using new ACK method
> (XEN) Platform timer is 14.318MHz HPET
> =C3=BF(XEN) Allocated console ring of 16 KiB.
> (XEN) VMX: Supported advanced features:
> (XEN)  - APIC MMIO access virtualisation
> (XEN)  - APIC TPR shadow
> (XEN)  - Virtual NMI
> (XEN)  - MSR direct-access bitmap
> (XEN) HVM: ASIDs disabled.
> (XEN) HVM: VMX enabled
> (XEN) Brought up 4 CPUs
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN)  Xen  kernel: 32-bit, PAE, lsb
> (XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc0100000 -> 0xc04c923c
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000124000000->0000000125000000 (953327 pages to
> be allocated)
> (XEN)  Init. ramdisk: 00000001278fe000->0000000127fff400
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: c0100000->c04c923c
> (XEN)  Init. ramdisk: c04ca000->c0bcb400
> (XEN)  Phys-Mach map: c0bcc000->c0f74bc4
> (XEN)  Start info:    c0f75000->c0f7547c
> (XEN)  Page tables:   c0f76000->c0f85000
> (XEN)  Boot stack:    c0f85000->c0f86000
> (XEN)  TOTAL:         c0000000->c1400000
> (XEN)  ENTRY ADDRESS: c0100000
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault
> addr ffffff000, iommu reg =3D fff16000
> (XEN) DMAR:[fault reason 05h] PTE Write access is not set
> (XEN) Scrubbing Free RAM: .done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
> to Xen)
> (XEN) Freed 184kB init memory.
> Linux version 2.6.18.8-xen (root@localhost.localdomain) (gcc =E7=89=88=E6=
=9C=AC 4.1.2
> 20070925 (Red Hat 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 00000000eaaf1000 (usable)
> 3026MB HIGHMEM available.
> 727MB LOWMEM available.
> NX (Execute Disable) protection: active
> On node 0 totalpages: 961265
>   DMA zone: 4096 pages, LIFO batch:0
>   Normal zone: 182270 pages, LIFO batch:31
>   HighMem zone: 774899 pages, LIFO batch:31
> found SMP MP-table at 000fe710
> DMI 2.5 present.
> ACPI: RSDP (v002 DELL                                  ) @ 0x000fec00
> ACPI: XSDT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc7cb
> ACPI: FADT (v003 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc8fb
> ACPI: SSDT (v001   DELL    st_ex 0x00001000 INTL 0x20050624) @ 0xffea25c4
> ACPI: MADT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fc9ef
> ACPI: BOOT (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fca81
> ACPI: ASF! (v032 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcaa9
> ACPI: MCFG (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb3f
> ACPI: HPET (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcb7d
> ACPI: TCPA (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcdd9
>   >>> ERROR: Invalid checksum
> ACPI: DMAR (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fce0b
> ACPI: SLIC (v001 DELL    B10K    0x00000015 ASL  0x00000061) @ 0x000fcbb5
> ACPI: SSDT (v001 DpgPmm  Cpu0Ist 0x00000011 INTL 0x20050624) @ 0xcd9ffc40
> ACPI: SSDT (v001 DpgPmm  Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049
> ACPI: SSDT (v001 DpgPmm  Cpu2Ist 0x00000011 INTL 0x20050624) @ 0xcda00452
> ACPI: SSDT (v001 DpgPmm  Cpu3Ist 0x00000011 INTL 0x20050624) @ 0xcda0085b
> ACPI: SSDT (v001 DpgPmm    CpuPm 0x00000010 INTL 0x20050624) @ 0xcda00c64
> ACPI: DSDT (v001   DELL    dt_ex 0x00001000 INTL 0x20050624) @ 0x00000000
> ACPI: Local APIC address 0xfee00000
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
> ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
> ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
> ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
> ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
> ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> ACPI: IRQ0 used by override.
> ACPI: IRQ2 used by override.
> ACPI: IRQ9 used by override.
> Enabling APIC mode:  Flat.  Using 1 I/O APICs
> Using ACPI (MADT) for SMP configuration information
> Allocating PCI resources starting at d1000000 (gap: d0000000:10000000)
> Detected 2660.681 MHz processor.
> Built 1 zonelists.  Total pages: 961265
> Kernel command line: ro root=3D/dev/sda11 console=3Dhvc0 console=3Dtty0
> console=3DttyS0,115200n8 debug selinux=3D0
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Initializing CPU#0
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> Xen reported: 2660.080 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Software IO TLB enabled:
>  Aperture:     64 megabytes
>  Kernel range: c31fd000 - c71fd000
>  Address size: 27 bits
> vmalloc area: ee000000-f51fe000, maxmem 2d7fe000
> Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,
> 908k data, 204k init, 3099596k highmem)
> Checking if this processor honours the WP bit even in supervisor mode...
> Ok.
> Calibrating delay using timer specific routine.. 5347.97 BogoMIPS
> (lpj=3D26739870)
> Security Framework v1.0.0 initialized
> Capability LSM initialized
> Mount-cache hash table entries: 512
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000
> Checking 'hlt' instruction... OK.
> SMP alternatives: switching to UP code
> ACPI: Core revision 20060707
> ENABLING IO-APIC IRQs
> SMP alternatives: switching to SMP code
> Initializing CPU#1
> Initializing CPU#2
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> Brought up 4 CPUs
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000<6>Initializing CPU#3
>
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000
> CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000
> 80080281 00000000 00000000
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 3072K
> CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80080281
> 00000000 00000000
> migration_cost=3D12
> checking if image is initramfs... it is
> Freeing initrd memory: 7173k freed
> PM: Adding info for No Bus:platform
> NET: Registered protocol family 16
> PM: Adding info for No Bus:xen
> PM: Adding info for No Bus:xen-backend
> ACPI: bus type pci registered
> PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> PCI: MCFG area at e0000000 reserved in E820
> PCI: Using MMCONFIG
> Setting up standard PCI resources
> ACPI: Interpreter enabled
> ACPI: Using IOAPIC for interrupt routing
> PM: Adding info for acpi:acpi
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> PCI: Probing PCI hardware (bus 00)
> PM: Adding info for No Bus:pci0000:00
> ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
> Boot video device is 0000:00:02.0
> PCI: Transparent bridge - 0000:00:1e.0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> PM: Adding info for pci:0000:00:00.0
> PM: Adding info for pci:0000:00:01.0
> PM: Adding info for pci:0000:00:02.0
> PM: Adding info for pci:0000:00:02.1
> PM: Adding info for pci:0000:00:03.0
> PM: Adding info for pci:0000:00:03.2
> PM: Adding info for pci:0000:00:03.3
> PM: Adding info for pci:0000:00:19.0
> PM: Adding info for pci:0000:00:1a.0
> PM: Adding info for pci:0000:00:1a.1
> PM: Adding info for pci:0000:00:1a.2
> PM: Adding info for pci:0000:00:1a.7
> PM: Adding info for pci:0000:00:1b.0
> PM: Adding info for pci:0000:00:1c.0
> PM: Adding info for pci:0000:00:1c.1
> PM: Adding info for pci:0000:00:1d.0
> PM: Adding info for pci:0000:00:1d.1
> PM: Adding info for pci:0000:00:1d.2
> PM: Adding info for pci:0000:00:1d.7
> PM: Adding info for pci:0000:00:1e.0
> PM: Adding info for pci:0000:00:1f.0
> PM: Adding info for pci:0000:00:1f.2
> PM: Adding info for pci:0000:00:1f.3
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI4._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0,
> disabled.
> ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12 15)
> ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)
> Linux Plug and Play Support v0.97 (c) Adam Belay
> pnp: PnP ACPI init
> PM: Adding info for No Bus:pnp0
> PM: Adding info for pnp:00:00
> PM: Adding info for pnp:00:01
> PM: Adding info for pnp:00:02
> PM: Adding info for pnp:00:03
> PM: Adding info for pnp:00:04
> PM: Adding info for pnp:00:05
> PM: Adding info for pnp:00:06
> (XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4
> (XEN) ioapic_guest_write: new_entry=3D000109f1
> (XEN) ioapic_guest_write: old_entry=3D000009f1 pirq=3D4
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> PM: Adding info for pnp:00:07
> PM: Adding info for pnp:00:08
> pnp: PnP ACPI: found 9 devices
> xen_mem: Initialising balloon driver.
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=3Drouteirq".  If it helps, post a
> report
> pnp: 00:01: ioport range 0x800-0x85f could not be reserved
> pnp: 00:01: ioport range 0xc00-0xc7f has been reserved
> pnp: 00:01: ioport range 0x860-0x8ff has been reserved
> PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
> PCI: Bridge: 0000:00:01.0
>   IO window: disabled.
>   MEM window: fe500000-fe5fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1c.0
>   IO window: disabled.
>   MEM window: fe400000-fe4fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1c.1
>   IO window: disabled.
>   MEM window: fe300000-fe3fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1e.0
>   IO window: disabled.
>   MEM window: disabled.
>   PREFETCH window: disabled.
> ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:01.0 to 64
> ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1c.0 to 64
> ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
> PCI: Setting latency timer of device 0000:00:1c.1 to 64
> PCI: Setting latency timer of device 0000:00:1e.0 to 64
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> PM: Adding info for platform:pcspkr
> Simple Boot Flag at 0x7a set to 0x1
> IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
> audit: initializing netlink socket (disabled)
> audit(1334461010.944:1): initialized
> highmem bounce pool size: 64 pages
> VFS: Disk quotas dquot_6.5.1
> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> Initializing Cryptographic API
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> 0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
> PM: Adding info for platform:vesafb.0
> Floppy drive(s): fd0 is 1.44M
> floppy0: Unable to grab DMA2 for the floppy driver
> floppy0: no floppy controllers found
> RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
> loop: loaded (max 8 devices)
> e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k4
> e1000e: Copyright (c) 1999-2008 Intel Corporation.
> ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 21 (level, low) -> IRQ 18
> PCI: Setting latency timer of device 0000:00:19.0 to 64
> (XEN) physdev.c:155: dom0: wrong map_pirq type 3
> eth0: (PCI Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54
> eth0: Intel(R) PRO/1000 Network Connection
> eth0: MAC: 7, PHY: 8, PBA No: 2021ff-0ff
> Intel(R) Gigabit Ethernet Network Driver - version 1.2.45-k2
> Copyright (c) 2008 Intel Corporation.
> ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version
> 1.3.56.5-NAPI
> Copyright (c) 1999-2008 Intel Corporation.
> Xen virtual console successfully installed as xvc0
> Event-channel device installed.
> blktap_device_init: blktap device major 254
> blktap_ring_init: blktap ring major: 253
> netfront: Initialising virtual ethernet driver.
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=
=3Dxx
> PNP: No PS/2 controller found. Probing ports directly.
> PM: Adding info for platform:i8042
> serio: i8042 AUX port at 0x60,0x64 irq 12
> PM: Adding info for serio:serio0
> serio: i8042 KBD port at 0x60,0x64 irq 1
> PM: Adding info for serio:serio1
> mice: PS/2 mouse device common for all mice
> md: md driver 0.90.3 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
> md: bitmap version 4.39
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Using IPI No-Shortcut mode
> PCI IO multiplexer device installed.
> ACPI: (supports S0 S1 S3 S4 S5)
> BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
> Freeing unused kernel memory: 204k freed
> *usbcore: disagrees about version of symbol HYPERVISOR_shared_info*
> usbcore: Unknown symbol HYPERVISOR_shared_info
> ehci_hcd: Unknown symbol usb_hcd_pci_suspend
> ehci_hcd: Unknown symbol usb_free_urb
> ehci_hcd: Unknown symbol usb_hub_tt_clear_buffer
> ehci_hcd: Unknown symbol usb_hcd_resume_root_hub
> ehci_hcd: Unknown symbol usb_hcd_pci_probe
> ehci_hcd: Unknown symbol usb_calc_bus_time
> ehci_hcd: Unknown symbol usb_hcd_pci_resume
> ehci_hcd: Unknown symbol usb_get_urb
> ehci_hcd: Unknown symbol usb_hcd_giveback_urb
> ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
> ehci_hcd: Unknown symbol HYPERVISOR_shared_info
> ehci_hcd: Unknown symbol usb_hcd_pci_remove
> ehci_hcd: Unknown symbol usb_root_hub_lost_power
> ohci_hcd: Unknown symbol usb_hcd_pci_suspend
> ohci_hcd: Unknown symbol usb_hcd_resume_root_hub
> ohci_hcd: Unknown symbol usb_hcd_pci_probe
> ohci_hcd: Unknown symbol usb_disabled
> ohci_hcd: Unknown symbol usb_calc_bus_time
> ohci_hcd: Unknown symbol usb_hcd_pci_resume
> ohci_hcd: Unknown symbol usb_hcd_giveback_urb
> ohci_hcd: Unknown symbol usb_hcd_suspend_root_hub
> ohci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
> ohci_hcd: Unknown symbol HYPERVISOR_shared_info
> ohci_hcd: Unknown symbol usb_hcd_pci_remove
> ohci_hcd: Unknown symbol usb_root_hub_lost_power
> uhci_hcd: Unknown symbol usb_hcd_pci_suspend
> uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
> uhci_hcd: Unknown symbol usb_hcd_pci_probe
> uhci_hcd: Unknown symbol usb_check_bandwidth
> uhci_hcd: Unknown symbol usb_disabled
> uhci_hcd: Unknown symbol usb_release_bandwidth
> uhci_hcd: Unknown symbol usb_claim_bandwidth
> uhci_hcd: Unknown symbol usb_hcd_pci_resume
> uhci_hcd: Unknown symbol usb_hcd_giveback_urb
> uhci_hcd: Unknown symbol usb_hcd_poll_rh_status
> uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info
> uhci_hcd: Unknown symbol HYPERVISOR_shared_info
> uhci_hcd: Unknown symbol usb_hcd_pci_remove
> uhci_hcd: Unknown symbol usb_root_hub_lost_power
> scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info
> scsi_mod: Unknown symbol HYPERVISOR_shared_info
> sd_mod: Unknown symbol scsi_print_sense_hdr
> sd_mod: Unknown symbol scsi_mode_sense
> sd_mod: Unknown symbol scsi_device_get
> sd_mod: Unknown symbol scsi_get_sense_info_fld
> sd_mod: Unknown symbol scsicam_bios_param
> sd_mod: Unknown symbol scsi_command_normalize_sense
> sd_mod: Unknown symbol scsi_test_unit_ready
> sd_mod: Unknown symbol scsi_block_when_processing_errors
> sd_mod: Unknown symbol scsi_register_driver
> sd_mod: Unknown symbol scsi_ioctl
> sd_mod: Unknown symbol scsi_nonblockable_ioctl
> sd_mod: Unknown symbol scsi_device_put
> sd_mod: Unknown symbol scsi_logging_level
> sd_mod: Unknown symbol scsi_execute_req
> sd_mod: Unknown symbol scsi_mode_select
> sd_mod: Unknown symbol scsi_print_sense
> sd_mod: Unknown symbol scsi_io_completion
> sd_mod: Unknown symbol scsi_set_medium_removal
> libata: Unknown symbol scsi_device_get
> libata: Unknown symbol scsi_remove_host
> libata: Unknown symbol scsi_schedule_eh
> libata: Unknown symbol scsi_device_set_state
> libata: Unknown symbol scsi_eh_finish_cmd
> libata: Unknown symbol scsi_device_put
> libata: Unknown symbol scsi_eh_flush_done_q
> libata: Unknown symbol scsi_host_put
> libata: Unknown symbol scsi_add_host
> libata: Unknown symbol scsi_rescan_device
> libata: Unknown symbol scsi_adjust_queue_depth
> libata: Unknown symbol scsi_execute_req
> libata: Unknown symbol scsi_req_abort_cmd
> libata: disagrees about version of symbol HYPERVISOR_shared_info
> libata: Unknown symbol HYPERVISOR_shared_info
> libata: Unknown symbol scsi_remove_device
> libata: Unknown symbol scsi_host_alloc
> libata: Unknown symbol __scsi_add_device
> ahci: Unknown symbol ata_scsi_ioctl
> ahci: Unknown symbol ata_port_abort
> ahci: Unknown symbol ata_std_bios_param
> ahci: Unknown symbol ata_std_postreset
> ahci: Unknown symbol ata_scsi_device_resume
> ahci: Unknown symbol ata_scsi_device_suspend
> ahci: Unknown symbol ata_tf_from_fis
> ahci: Unknown symbol ata_qc_complete_multiple
> ahci: Unknown symbol ata_noop_dev_select
> ahci: Unknown symbol ata_tf_to_fis
> ahci: Unknown symbol ata_pci_device_do_resume
> ahci: Unknown symbol ata_dev_classify
> ahci: Unknown symbol ata_scsi_release
> ahci: Unknown symbol ata_port_offline
> ahci: Unknown symbol ata_scsi_change_queue_depth
> ahci: Unknown symbol sata_std_hardreset
> ahci: Unknown symbol ata_pci_device_suspend
> ahci: Unknown symbol scsi_host_put
> ahci: Unknown symbol ata_port_online
> ahci: Unknown symbol ata_wait_register
> ahci: Unknown symbol ata_busy_sleep
> ahci: Unknown symbol ata_scsi_slave_config
> ahci: Unknown symbol ata_port_detach
> ahci: Unknown symbol ata_port_disable
> ahci: Unknown symbol ata_scsi_queuecmd
> ahci: Unknown symbol ata_scsi_slave_destroy
> ahci: Unknown symbol ata_ratelimit
> ahci: Unknown symbol ata_host_set_resume
> ahci: Unknown symbol ata_do_eh
> ahci: Unknown symbol ata_port_freeze
> ahci: Unknown symbol ata_std_prereset
> ahci: Unknown symbol ata_device_add
>
>
>
> --
> Best Regards,
> Bei Guan
>
>


--=20
Best Regards,
Bei Guan

--f46d041824ee481a8104bdb3daa3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Hi All,</div><div><br></div><div>I think this problem has been solved.=
</div><div>What I have done is that make clean the xen and tools, and remov=
e the build-linux-2.6.18-xen_x86_32 directory. Then, I re-compile the xen, =
tools, kernels, and reboot. It works fine.</div>
<div><br></div><div>Thank you all the same.</div><div><br></div><br><br><di=
v class=3D"gmail_quote">=E5=9C=A8 2012=E5=B9=B44=E6=9C=8815=E6=97=A5 =E4=B8=
=8A=E5=8D=884:11=EF=BC=8CBei Guan <span dir=3D"ltr">&lt;<a href=3D"mailto:g=
btju85@gmail.com">gbtju85@gmail.com</a>&gt;</span>=E5=86=99=E9=81=93=EF=BC=
=9A<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div>Hi All,</div><div><br></div><div>I want to shared a variable between D=
om0 and Xen. I add the variable into <b>struct shared_info</b> in code file=
 xen/include/public/xen.h and linux-2.6.18-xen.hg/include/xen/interface/xeb=
.h.</div>

<div>In Dom0, I use <b>shared_info_t *s =3D HYPERVISOR_shared_info</b> to g=
et the value of the shared variable.=C2=A0</div><div><br></div><div>However=
, when I compile Xen, xen-tools and Dom0 kernel. It cannot boot into Dom0.=
=C2=A0The error from serial port debug is logged as the following.</div>

<div><br></div><div>Could anyone help me figure out the problem? Any sugges=
tion is appreciated. Thanks a lot.</div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div>=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=
=3D PuTTY log <a href=3D"tel:2012.04.15%2003" value=3D"+12012041503" target=
=3D"_blank">2012.04.15 03</a>:37:03 =3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D~=3D=
~=3D~=3D</div>

<div>Restarting system.</div><div>(XEN) Domain 0 shutdown: rebooting machin=
e.</div><div>=C2=A0__ =C2=A0__ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_ =
=C2=A0_ =C2=A0 =C2=A0_ =C2=A0 ____ =C2=A0</div><div>=C2=A0\ \/ /___ _ __ =
=C2=A0 | || | =C2=A0/ | |___ \=C2=A0</div><div>=C2=A0 \ =C2=A0// _ \ &#39;_=
 \ =C2=A0| || |_ | | =C2=A0 __) |</div>

<div>=C2=A0 / =C2=A0\ =C2=A0__/ | | | |__ =C2=A0 _|| |_ / __/=C2=A0</div><d=
iv>=C2=A0/_/\_\___|_| |_| =C2=A0 =C2=A0|_|(_)_(_)_____|</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>(XEN) Xen ve=
rsion 4.1.2 (root@localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red =
Hat 4.1.2-33)) Sun Apr 15 03:24:23 CST 2012</div>

<div>(XEN) Latest ChangeSet: unavailable</div><div>(XEN) Bootloader: GNU GR=
UB 0.97</div><div>(XEN) Command line: console=3Dcom1,vga com1=3D115200,8n1<=
/div><div>(XEN) Video information:</div><div>(XEN) =C2=A0VGA is text mode 8=
0x25, font 8x16</div>

<div>(XEN) =C2=A0VBE/DDC methods: V2; EDID transfer time: 1 seconds</div><d=
iv>(XEN) Disc information:</div><div>(XEN) =C2=A0Found 1 MBR signatures</di=
v><div>(XEN) =C2=A0Found 1 EDD information structures</div><div>(XEN) Xen-e=
820 RAM map:</div>

<div>(XEN) =C2=A00000000000000000 - 000000000009a800 (usable)</div><div>(XE=
N) =C2=A000000000000f0000 - 0000000000100000 (reserved)</div><div>(XEN) =C2=
=A00000000000100000 - 00000000cd9ffc00 (usable)</div><div>(XEN) =C2=A000000=
000cd9ffc00 - 00000000cda53c00 (ACPI NVS)</div>

<div>(XEN) =C2=A000000000cda53c00 - 00000000cda55c00 (ACPI data)</div><div>=
(XEN) =C2=A000000000cda55c00 - 00000000d0000000 (reserved)</div><div>(XEN) =
=C2=A000000000e0000000 - 00000000f0000000 (reserved)</div><div>(XEN) =C2=A0=
00000000fec00000 - 00000000fed00400 (reserved)</div>

<div>(XEN) =C2=A000000000fed20000 - 00000000feda0000 (reserved)</div><div>(=
XEN) =C2=A000000000fee00000 - 00000000fef00000 (reserved)</div><div>(XEN) =
=C2=A000000000ffb00000 - 0000000100000000 (reserved)</div><div>(XEN) =C2=A0=
0000000100000000 - 0000000128000000 (usable)</div>

<div>(XEN) System RAM: 3929MB (4023908kB)</div><div>(XEN) ACPI: RSDP 000FEC=
00, 0024 (r2 DELL =C2=A0)</div><div>(XEN) ACPI: XSDT 000FC7CB, 009C (r1 DEL=
L =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =
=C2=A0 =C2=A061)</div><div>(XEN) ACPI: FACP 000FC8FB, 00F4 (r3 DELL =C2=A0 =
=C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =
=C2=A061)</div>

<div>(XEN) ACPI: DSDT FFE9CFF8, 54AD (r1 =C2=A0 DELL =C2=A0 =C2=A0dt_ex =C2=
=A0 =C2=A0 1000 INTL 20050624)</div><div>(XEN) ACPI: FACS CD9FFC00, 0040</d=
iv><div>(XEN) ACPI: SSDT FFEA25C4, 00AA (r1 =C2=A0 DELL =C2=A0 =C2=A0st_ex =
=C2=A0 =C2=A0 1000 INTL 20050624)</div><div>(XEN) ACPI: APIC 000FC9EF, 0092=
 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0=
 =C2=A0 =C2=A0 =C2=A061)</div>

<div>(XEN) ACPI: BOOT 000FCA81, 0028 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XE=
N) ACPI: ASF! 000FCAA9, 0096 (r32 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XEN) ACPI=
: MCFG 000FCB3F, 003E (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div>

<div>(XEN) ACPI: HPET 000FCB7D, 0038 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XE=
N) ACPI: TCPA 000FCDD9, 0032 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XEN) ACPI=
: DMAR 000FCE0B, 0120 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div>

<div>(XEN) ACPI: SLIC 000FCBB5, 0176 (r1 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A015 ASL =C2=A0 =C2=A0 =C2=A0 =C2=A061)</div><div>(XE=
N) ACPI: SSDT CD9FFC40, 01B7 (r1 DpgPmm =C2=A0Cpu0Ist =C2=A0 =C2=A0 =C2=A0 =
11 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA00049, 01B7 (r1 DpgPmm =C2=
=A0Cpu1Ist =C2=A0 =C2=A0 =C2=A0 11 INTL 20050624)</div>

<div>(XEN) ACPI: SSDT CDA00452, 01B7 (r1 DpgPmm =C2=A0Cpu2Ist =C2=A0 =C2=A0=
 =C2=A0 11 INTL 20050624)</div><div>(XEN) ACPI: SSDT CDA0085B, 01B7 (r1 Dpg=
Pmm =C2=A0Cpu3Ist =C2=A0 =C2=A0 =C2=A0 11 INTL 20050624)</div><div>(XEN) AC=
PI: SSDT CDA00C64, 0190 (r1 DpgPmm =C2=A0 =C2=A0CpuPm =C2=A0 =C2=A0 =C2=A0 =
10 INTL 20050624)</div>

<div>(XEN) Xen heap: 9MB (9768kB)</div><div>(XEN) Domain heap initialised</=
div><div>(XEN) Processor #0 7:7 APIC version 20</div><div>(XEN) Processor #=
1 7:7 APIC version 20</div><div>(XEN) Processor #2 7:7 APIC version 20</div=
>

<div>(XEN) Processor #3 7:7 APIC version 20</div><div>(XEN) IOAPIC[0]: apic=
_id 8, version 32, address 0xfec00000, GSI 0-23</div><div>(XEN) Enabling AP=
IC mode: =C2=A0Flat. =C2=A0Using 1 I/O APICs</div><div>(XEN) Table is not f=
ound!</div>

<div>(XEN) Using scheduler: SMP Credit Scheduler (credit)</div><div>(XEN) D=
etected 2660.080 MHz processor.</div><div>(XEN) Intel VT-d Snoop Control no=
t enabled.</div><div>(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.</di=
v>

<div>(XEN) Intel VT-d Queued Invalidation not enabled.</div><div>(XEN) Inte=
l VT-d Interrupt Remapping not enabled.</div><div>(XEN) Intel VT-d Shared E=
PT tables not enabled.</div><div>(XEN) I/O virtualisation enabled</div>

<div>(XEN) =C2=A0- Dom0 mode: Relaxed</div><div>(XEN) ENABLING IO-APIC IRQs=
</div><div>(XEN) =C2=A0-&gt; Using new ACK method</div><div>(XEN) Platform =
timer is 14.318MHz HPET</div><div>=C3=BF(XEN) Allocated console ring of 16 =
KiB.</div>
<div>
(XEN) VMX: Supported advanced features:</div><div>(XEN) =C2=A0- APIC MMIO a=
ccess virtualisation</div><div>(XEN) =C2=A0- APIC TPR shadow</div><div>(XEN=
) =C2=A0- Virtual NMI</div><div>(XEN) =C2=A0- MSR direct-access bitmap</div=
><div>(XEN) HVM: ASIDs disabled.</div>

<div>(XEN) HVM: VMX enabled</div><div>(XEN) Brought up 4 CPUs</div><div>(XE=
N) *** LOADING DOMAIN 0 ***</div><div>(XEN) =C2=A0Xen =C2=A0kernel: 32-bit,=
 PAE, lsb</div><div>(XEN) =C2=A0Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc010=
0000 -&gt; 0xc04c923c</div>

<div>(XEN) PHYSICAL MEMORY ARRANGEMENT:</div><div>(XEN) =C2=A0Dom0 alloc.: =
=C2=A0 0000000124000000-&gt;0000000125000000 (953327 pages to be allocated)=
</div><div>(XEN) =C2=A0Init. ramdisk: 00000001278fe000-&gt;0000000127fff400=
</div><div>

(XEN) VIRTUAL MEMORY ARRANGEMENT:</div><div>(XEN) =C2=A0Loaded kernel: c010=
0000-&gt;c04c923c</div><div>(XEN) =C2=A0Init. ramdisk: c04ca000-&gt;c0bcb40=
0</div><div>(XEN) =C2=A0Phys-Mach map: c0bcc000-&gt;c0f74bc4</div><div>(XEN=
) =C2=A0Start info: =C2=A0 =C2=A0c0f75000-&gt;c0f7547c</div>

<div>(XEN) =C2=A0Page tables: =C2=A0 c0f76000-&gt;c0f85000</div><div>(XEN) =
=C2=A0Boot stack: =C2=A0 =C2=A0c0f85000-&gt;c0f86000</div><div>(XEN) =C2=A0=
TOTAL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 c0000000-&gt;c1400000</div><div>(XEN) =
=C2=A0ENTRY ADDRESS: c0100000</div><div>(XEN) Dom0 has maximum 4 VCPUs</div=
>

<div>(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow</div><div>=
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault</div><di=
v>(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault =
addr ffffff000, iommu reg =3D fff16000</div>

<div>(XEN) DMAR:[fault reason 05h] PTE Write access is not set</div><div>(X=
EN) Scrubbing Free RAM: .done.</div><div>(XEN) Xen trace buffers: disabled<=
/div><div>(XEN) Std. Loglevel: Errors and warnings</div><div>(XEN) Guest Lo=
glevel: Nothing (Rate-limited: Errors and warnings)</div>

<div>(XEN) Xen is relinquishing VGA console.</div><div>(XEN) *** Serial inp=
ut -&gt; DOM0 (type &#39;CTRL-a&#39; three times to switch input to Xen)</d=
iv><div>(XEN) Freed 184kB init memory.</div><div>Linux version 2.6.18.8-xen=
 (root@localhost.localdomain) (gcc =E7=89=88=E6=9C=AC 4.1.2 20070925 (Red H=
at 4.1.2-33)) #29 SMP Sun Apr 15 03:35:12 CST 2012</div>

<div>BIOS-provided physical RAM map:</div><div>=C2=A0Xen: 0000000000000000 =
- 00000000eaaf1000 (usable)</div><div>3026MB HIGHMEM available.</div><div>7=
27MB LOWMEM available.</div><div>NX (Execute Disable) protection: active</d=
iv>

<div>On node 0 totalpages: 961265</div><div>=C2=A0 DMA zone: 4096 pages, LI=
FO batch:0</div><div>=C2=A0 Normal zone: 182270 pages, LIFO batch:31</div><=
div>=C2=A0 HighMem zone: 774899 pages, LIFO batch:31</div><div>found SMP MP=
-table at 000fe710</div>

<div>DMI 2.5 present.</div><div>ACPI: RSDP (v002 DELL =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0) @ 0x000fec00</div><div>ACPI: XSDT (v001 DELL =C2=
=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00x00000061) @ 0x000fc7cb</=
div><div>ACPI: FADT (v003 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 AS=
L =C2=A00x00000061) @ 0x000fc8fb</div>

<div>ACPI: SSDT (v001 =C2=A0 DELL =C2=A0 =C2=A0st_ex 0x00001000 INTL 0x2005=
0624) @ 0xffea25c4</div><div>ACPI: MADT (v001 DELL =C2=A0 =C2=A0B10K =C2=A0=
 =C2=A00x00000015 ASL =C2=A00x00000061) @ 0x000fc9ef</div><div>ACPI: BOOT (=
v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00x00000061) @=
 0x000fca81</div>

<div>ACPI: ASF! (v032 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =
=C2=A00x00000061) @ 0x000fcaa9</div><div>ACPI: MCFG (v001 DELL =C2=A0 =C2=
=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00x00000061) @ 0x000fcb3f</div><di=
v>ACPI: HPET (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=
=A00x00000061) @ 0x000fcb7d</div>

<div>ACPI: TCPA (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =
=C2=A00x00000061) @ 0x000fcdd9</div><div>=C2=A0 &gt;&gt;&gt; ERROR: Invalid=
 checksum</div><div>ACPI: DMAR (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x=
00000015 ASL =C2=A00x00000061) @ 0x000fce0b</div><div>

ACPI: SLIC (v001 DELL =C2=A0 =C2=A0B10K =C2=A0 =C2=A00x00000015 ASL =C2=A00=
x00000061) @ 0x000fcbb5</div><div>ACPI: SSDT (v001 DpgPmm =C2=A0Cpu0Ist 0x0=
0000011 INTL 0x20050624) @ 0xcd9ffc40</div><div>ACPI: SSDT (v001 DpgPmm =C2=
=A0Cpu1Ist 0x00000011 INTL 0x20050624) @ 0xcda00049</div>

<div>ACPI: SSDT (v001 DpgPmm =C2=A0Cpu2Ist 0x00000011 INTL 0x20050624) @ 0x=
cda00452</div><div>ACPI: SSDT (v001 DpgPmm =C2=A0Cpu3Ist 0x00000011 INTL 0x=
20050624) @ 0xcda0085b</div><div>ACPI: SSDT (v001 DpgPmm =C2=A0 =C2=A0CpuPm=
 0x00000010 INTL 0x20050624) @ 0xcda00c64</div>

<div>ACPI: DSDT (v001 =C2=A0 DELL =C2=A0 =C2=A0dt_ex 0x00001000 INTL 0x2005=
0624) @ 0x00000000</div><div>ACPI: Local APIC address 0xfee00000</div><div>=
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)</div><div>ACPI: LAPIC (a=
cpi_id[0x02] lapic_id[0x01] enabled)</div>

<div>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)</div><div>ACPI: LAP=
IC (acpi_id[0x04] lapic_id[0x03] enabled)</div><div>ACPI: LAPIC (acpi_id[0x=
05] lapic_id[0x00] disabled)</div><div>ACPI: LAPIC (acpi_id[0x06] lapic_id[=
0x01] disabled)</div>

<div>ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)</div><div>ACPI: LA=
PIC (acpi_id[0x08] lapic_id[0x03] disabled)</div><div>ACPI: LAPIC_NMI (acpi=
_id[0xff] high level lint[0x1])</div><div>ACPI: IOAPIC (id[0x08] address[0x=
fec00000] gsi_base[0])</div>

<div>IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23</div><d=
iv>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)</div><div>ACPI:=
 INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)</div><div>ACPI: IRQ0=
 used by override.</div>

<div>ACPI: IRQ2 used by override.</div><div>ACPI: IRQ9 used by override.</d=
iv><div>Enabling APIC mode: =C2=A0Flat. =C2=A0Using 1 I/O APICs</div><div>U=
sing ACPI (MADT) for SMP configuration information</div><div>Allocating PCI=
 resources starting at d1000000 (gap: d0000000:10000000)</div>

<div>Detected 2660.681 MHz processor.</div><div>Built 1 zonelists. =C2=A0To=
tal pages: 961265</div><div>Kernel command line: ro root=3D/dev/sda11 conso=
le=3Dhvc0 console=3Dtty0 console=3DttyS0,115200n8 debug selinux=3D0</div><d=
iv>Enabling fast FPU save and restore... done.</div>

<div>Enabling unmasked SIMD FPU exception support... done.</div><div>Initia=
lizing CPU#0</div><div>PID hash table entries: 4096 (order: 12, 16384 bytes=
)</div><div>Xen reported: 2660.080 MHz processor.</div><div>Console: colour=
 VGA+ 80x25</div>

<div>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)</div>=
<div>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)</div><d=
iv>Software IO TLB enabled:=C2=A0</div><div>=C2=A0Aperture: =C2=A0 =C2=A0 6=
4 megabytes</div>

<div>=C2=A0Kernel range: c31fd000 - c71fd000</div><div>=C2=A0Address size: =
27 bits</div><div>vmalloc area: ee000000-f51fe000, maxmem 2d7fe000</div><di=
v>Memory: 3722620k/3845060k available (2322k kernel code, 113316k reserved,=
 908k data, 204k init, 3099596k highmem)</div>

<div>Checking if this processor honours the WP bit even in supervisor mode.=
.. Ok.</div><div>Calibrating delay using timer specific routine.. 5347.97 B=
ogoMIPS (lpj=3D26739870)</div><div>Security Framework v1.0.0 initialized</d=
iv>

<div>Capability LSM initialized</div><div>Mount-cache hash table entries: 5=
12</div><div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 =
00000000 80080281 00000000 00000000</div><div>CPU: After vendor identify, c=
aps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div>

<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000</div><div>Checking &#39;hlt&#39; instruction... OK=
.</div>

<div>SMP alternatives: switching to UP code</div><div>ACPI: Core revision 2=
0060707</div><div>ENABLING IO-APIC IRQs</div><div>SMP alternatives: switchi=
ng to SMP code</div><div>Initializing CPU#1</div><div>Initializing CPU#2</d=
iv>

<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>
Brought up 4 CPUs</div>
<div>CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>CPU: L2 cache: 3072K</=
div><div>CPU: After all inits, caps: 1fc9d3f5 00100000 00000000 00000140 80=
080281 00000000 00000000&lt;6&gt;Initializing CPU#3</div><div><br></div>

<div>CPU: After generic identify, caps: 1fc9d3f5 00100000 00000000 00000000=
 80080281 00000000 00000000</div><div>CPU: After vendor identify, caps: 1fc=
9d3f5 00100000 00000000 00000000 80080281 00000000 00000000</div><div>
CPU: L1 I cache: 32K, L1 D cache: 32K</div>
<div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3f5 00=
100000 00000000 00000140 80080281 00000000 00000000</div><div>CPU: After ge=
neric identify, caps: 1fc9d3f5 00100000 00000000 00000000 80080281 00000000=
 00000000</div>

<div>CPU: After vendor identify, caps: 1fc9d3f5 00100000 00000000 00000000 =
80080281 00000000 00000000</div><div>CPU: L1 I cache: 32K, L1 D cache: 32K<=
/div><div>CPU: L2 cache: 3072K</div><div>CPU: After all inits, caps: 1fc9d3=
f5 00100000 00000000 00000140 80080281 00000000 00000000</div>

<div>migration_cost=3D12</div><div>checking if image is initramfs... it is<=
/div><div>Freeing initrd memory: 7173k freed</div><div>PM: Adding info for =
No Bus:platform</div><div>NET: Registered protocol family 16</div><div>PM: =
Adding info for No Bus:xen</div>

<div>PM: Adding info for No Bus:xen-backend</div><div>ACPI: bus type pci re=
gistered</div><div>PCI: MCFG configuration 0: base e0000000 segment 0 buses=
 0 - 255</div><div>PCI: MCFG area at e0000000 reserved in E820</div><div>

PCI: Using MMCONFIG</div><div>Setting up standard PCI resources</div><div>A=
CPI: Interpreter enabled</div><div>ACPI: Using IOAPIC for interrupt routing=
</div><div>PM: Adding info for acpi:acpi</div><div>ACPI: PCI Root Bridge [P=
CI0] (0000:00)</div>

<div>PCI: Probing PCI hardware (bus 00)</div><div>PM: Adding info for No Bu=
s:pci0000:00</div><div>ACPI: Assume root bridge [\_SB_.PCI0] bus is 0</div>=
<div>Boot video device is 0000:00:02.0</div><div>PCI: Transparent bridge - =
0000:00:1e.0</div>

<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]</div><div>PM: Addi=
ng info for pci:0000:00:00.0</div><div>PM: Adding info for pci:0000:00:01.0=
</div><div>PM: Adding info for pci:0000:00:02.0</div><div>PM: Adding info f=
or pci:0000:00:02.1</div>

<div>PM: Adding info for pci:0000:00:03.0</div><div>PM: Adding info for pci=
:0000:00:03.2</div><div>PM: Adding info for pci:0000:00:03.3</div><div>PM: =
Adding info for pci:0000:00:19.0</div><div>PM: Adding info for pci:0000:00:=
1a.0</div>

<div>PM: Adding info for pci:0000:00:1a.1</div><div>PM: Adding info for pci=
:0000:00:1a.2</div><div>PM: Adding info for pci:0000:00:1a.7</div><div>PM: =
Adding info for pci:0000:00:1b.0</div><div>PM: Adding info for pci:0000:00:=
1c.0</div>

<div>PM: Adding info for pci:0000:00:1c.1</div><div>PM: Adding info for pci=
:0000:00:1d.0</div><div>PM: Adding info for pci:0000:00:1d.1</div><div>PM: =
Adding info for pci:0000:00:1d.2</div><div>PM: Adding info for pci:0000:00:=
1d.7</div>

<div>PM: Adding info for pci:0000:00:1e.0</div><div>PM: Adding info for pci=
:0000:00:1f.0</div><div>PM: Adding info for pci:0000:00:1f.2</div><div>PM: =
Adding info for pci:0000:00:1f.3</div><div>ACPI: PCI Interrupt Routing Tabl=
e [\_SB_.PCI0.PCI4._PRT]</div>

<div>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]</div><div>ACP=
I: PCI Interrupt Routing Table [\_SB_.PCI0.PCI3._PRT]</div><div>ACPI: PCI I=
nterrupt Routing Table [\_SB_.PCI0.PCI1._PRT]</div><div>ACPI: PCI Interrupt=
 Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)</div>

<div>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *<a href=3D"tel:5%206%207%20=
9%2010%2011%2012" value=3D"+15679101112" target=3D"_blank">5 6 7 9 10 11 12=
</a> 15)</div><div>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11=
 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div>
<div>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, dis=
abled.</div><div>ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 1=
2 15)</div><div>ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *<a href=3D"tel:5=
%206%207%209%2010%2011%2012" value=3D"+15679101112" target=3D"_blank">5 6 7=
 9 10 11 12</a> 15)</div>

<div>ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15)</div><=
div>Linux Plug and Play Support v0.97 (c) Adam Belay</div><div>pnp: PnP ACP=
I init</div><div>PM: Adding info for No Bus:pnp0</div><div>PM: Adding info =
for pnp:00:00</div>

<div>PM: Adding info for pnp:00:01</div><div>PM: Adding info for pnp:00:02<=
/div><div>PM: Adding info for pnp:00:03</div><div>PM: Adding info for pnp:0=
0:04</div><div>PM: Adding info for pnp:00:05</div><div>PM: Adding info for =
pnp:00:06</div>

<div>(XEN) ioapic_guest_write: apic=3D0, pin=3D4, irq=3D4</div><div>(XEN) i=
oapic_guest_write: new_entry=3D000109f1</div><div>(XEN) ioapic_guest_write:=
 old_entry=3D000009f1 pirq=3D4</div><div>(XEN) ioapic_guest_write: Attempt =
to modify IO-APIC pin for in-use IRQ!</div>

<div>PM: Adding info for pnp:00:07</div><div>PM: Adding info for pnp:00:08<=
/div><div>pnp: PnP ACPI: found 9 devices</div><div>xen_mem: Initialising ba=
lloon driver.</div><div>PCI: Using ACPI for IRQ routing</div><div>PCI: If a=
 device doesn&#39;t work, try &quot;pci=3Drouteirq&quot;. =C2=A0If it helps=
, post a report</div>

<div>pnp: 00:01: ioport range 0x800-0x85f could not be reserved</div><div>p=
np: 00:01: ioport range 0xc00-0xc7f has been reserved</div><div>pnp: 00:01:=
 ioport range 0x860-0x8ff has been reserved</div><div>PCI: Ignore bogus res=
ource 6 [0:0] of 0000:00:02.0</div>

<div>PCI: Bridge: 0000:00:01.0</div><div>=C2=A0 IO window: disabled.</div><=
div>=C2=A0 MEM window: fe500000-fe5fffff</div><div>=C2=A0 PREFETCH window: =
disabled.</div><div>PCI: Bridge: 0000:00:1c.0</div><div>=C2=A0 IO window: d=
isabled.</div><div>

=C2=A0 MEM window: fe400000-fe4fffff</div><div>=C2=A0 PREFETCH window: disa=
bled.</div><div>PCI: Bridge: 0000:00:1c.1</div><div>=C2=A0 IO window: disab=
led.</div><div>=C2=A0 MEM window: fe300000-fe3fffff</div><div>=C2=A0 PREFET=
CH window: disabled.</div>

<div>PCI: Bridge: 0000:00:1e.0</div><div>=C2=A0 IO window: disabled.</div><=
div>=C2=A0 MEM window: disabled.</div><div>=C2=A0 PREFETCH window: disabled=
.</div><div>ACPI: PCI Interrupt 0000:00:01.0[A] -&gt; GSI 16 (level, low) -=
&gt; IRQ 16</div>

<div>PCI: Setting latency timer of device 0000:00:01.0 to 64</div><div>ACPI=
: PCI Interrupt 0000:00:1c.0[A] -&gt; GSI 16 (level, low) -&gt; IRQ 16</div=
><div>PCI: Setting latency timer of device 0000:00:1c.0 to 64</div><div>

ACPI: PCI Interrupt 0000:00:1c.1[B] -&gt; GSI 17 (level, low) -&gt; IRQ 17<=
/div><div>PCI: Setting latency timer of device 0000:00:1c.1 to 64</div><div=
>PCI: Setting latency timer of device 0000:00:1e.0 to 64</div><div>NET: Reg=
istered protocol family 2</div>

<div>IP route cache hash table entries: 32768 (order: 5, 131072 bytes)</div=
><div>TCP established hash table entries: 131072 (order: 8, 1048576 bytes)<=
/div><div>TCP bind hash table entries: 65536 (order: 7, 524288 bytes)</div>

<div>TCP: Hash tables configured (established 131072 bind 65536)</div><div>=
TCP reno registered</div><div>PM: Adding info for platform:pcspkr</div><div=
>Simple Boot Flag at 0x7a set to 0x1</div><div>IA-32 Microcode Update Drive=
r: v1.14a-xen &lt;<a href=3D"mailto:tigran@veritas.com" target=3D"_blank">t=
igran@veritas.com</a>&gt;</div>

<div>audit: initializing netlink socket (disabled)</div><div>audit(13344610=
10.944:1): initialized</div><div>highmem bounce pool size: 64 pages</div><d=
iv>VFS: Disk quotas dquot_6.5.1</div><div>Dquot-cache hash table entries: 1=
024 (order 0, 4096 bytes)</div>

<div>Initializing Cryptographic API</div><div>io scheduler noop registered<=
/div><div>io scheduler anticipatory registered</div><div>io scheduler deadl=
ine registered</div><div>io scheduler cfq registered (default)</div><div>

0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001</div><div>PM: =
Adding info for platform:vesafb.0</div><div>Floppy drive(s): fd0 is 1.44M</=
div><div>floppy0: Unable to grab DMA2 for the floppy driver</div><div>
floppy0: no floppy controllers found</div>
<div>RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize=
</div><div>loop: loaded (max 8 devices)</div><div>e1000e: Intel(R) PRO/1000=
 Network Driver - 0.3.3.3-k4</div><div>e1000e: Copyright (c) 1999-2008 Inte=
l Corporation.</div>

<div>ACPI: PCI Interrupt 0000:00:19.0[A] -&gt; GSI 21 (level, low) -&gt; IR=
Q 18</div><div>PCI: Setting latency timer of device 0000:00:19.0 to 64</div=
><div>(XEN) physdev.c:155: dom0: wrong map_pirq type 3</div><div>eth0: (PCI=
 Express:2.5GB/s:Width x1) 00:24:e8:39:fa:54</div>

<div>eth0: Intel(R) PRO/1000 Network Connection</div><div>eth0: MAC: 7, PHY=
: 8, PBA No: 2021ff-0ff</div><div>Intel(R) Gigabit Ethernet Network Driver =
- version 1.2.45-k2</div><div>Copyright (c) 2008 Intel Corporation.</div>

<div>ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 1.3.56=
.5-NAPI</div><div>Copyright (c) 1999-2008 Intel Corporation.</div><div>Xen =
virtual console successfully installed as xvc0</div><div>Event-channel devi=
ce installed.</div>

<div>blktap_device_init: blktap device major 254</div><div>blktap_ring_init=
: blktap ring major: 253</div><div>netfront: Initialising virtual ethernet =
driver.</div><div>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2<=
/div>

<div>ide: Assuming 33MHz system bus speed for PIO modes; override with ideb=
us=3Dxx</div><div>PNP: No PS/2 controller found. Probing ports directly.</d=
iv><div>PM: Adding info for platform:i8042</div><div>serio: i8042 AUX port =
at 0x60,0x64 irq 12</div>

<div>PM: Adding info for serio:serio0</div><div>serio: i8042 KBD port at 0x=
60,0x64 irq 1</div><div>PM: Adding info for serio:serio1</div><div>mice: PS=
/2 mouse device common for all mice</div><div>md: md driver 0.90.3 MAX_MD_D=
EVS=3D256, MD_SB_DISKS=3D27</div>

<div>md: bitmap version 4.39</div><div>NET: Registered protocol family 1</d=
iv><div>NET: Registered protocol family 17</div><div>Using IPI No-Shortcut =
mode</div><div>PCI IO multiplexer device installed.</div><div>ACPI: (suppor=
ts S0 S1 S3 S4 S5)</div>

<div>BIOS EDD facility v0.16 2004-Jun-25, 1 devices found</div><div>Freeing=
 unused kernel memory: 204k freed</div><div><b>usbcore: disagrees about ver=
sion of symbol HYPERVISOR_shared_info</b></div><div>usbcore: Unknown symbol=
 HYPERVISOR_shared_info</div>

<div>ehci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ehci_hcd: Unkno=
wn symbol usb_free_urb</div><div>ehci_hcd: Unknown symbol usb_hub_tt_clear_=
buffer</div><div>ehci_hcd: Unknown symbol usb_hcd_resume_root_hub</div>

<div>ehci_hcd: Unknown symbol usb_hcd_pci_probe</div><div>ehci_hcd: Unknown=
 symbol usb_calc_bus_time</div><div>ehci_hcd: Unknown symbol usb_hcd_pci_re=
sume</div><div>ehci_hcd: Unknown symbol usb_get_urb</div><div>ehci_hcd: Unk=
nown symbol usb_hcd_giveback_urb</div>

<div>ehci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>ehci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ehci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>ehci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>

<div>ohci_hcd: Unknown symbol usb_hcd_pci_suspend</div><div>ohci_hcd: Unkno=
wn symbol usb_hcd_resume_root_hub</div><div>ohci_hcd: Unknown symbol usb_hc=
d_pci_probe</div><div>ohci_hcd: Unknown symbol usb_disabled</div><div>
ohci_hcd: Unknown symbol usb_calc_bus_time</div>
<div>ohci_hcd: Unknown symbol usb_hcd_pci_resume</div><div>ohci_hcd: Unknow=
n symbol usb_hcd_giveback_urb</div><div>ohci_hcd: Unknown symbol usb_hcd_su=
spend_root_hub</div><div>ohci_hcd: disagrees about version of symbol HYPERV=
ISOR_shared_info</div>

<div>ohci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>ohci_hcd: Un=
known symbol usb_hcd_pci_remove</div><div>ohci_hcd: Unknown symbol usb_root=
_hub_lost_power</div><div>uhci_hcd: Unknown symbol usb_hcd_pci_suspend</div=
>

<div>uhci_hcd: Unknown symbol usb_hcd_resume_root_hub</div><div>uhci_hcd: U=
nknown symbol usb_hcd_pci_probe</div><div>uhci_hcd: Unknown symbol usb_chec=
k_bandwidth</div><div>uhci_hcd: Unknown symbol usb_disabled</div><div>
uhci_hcd: Unknown symbol usb_release_bandwidth</div>
<div>uhci_hcd: Unknown symbol usb_claim_bandwidth</div><div>uhci_hcd: Unkno=
wn symbol usb_hcd_pci_resume</div><div>uhci_hcd: Unknown symbol usb_hcd_giv=
eback_urb</div><div>uhci_hcd: Unknown symbol usb_hcd_poll_rh_status</div>

<div>uhci_hcd: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>uhci_hcd: Unknown symbol HYPERVISOR_shared_info</div><div>uhci_hcd: =
Unknown symbol usb_hcd_pci_remove</div><div>uhci_hcd: Unknown symbol usb_ro=
ot_hub_lost_power</div>

<div>scsi_mod: disagrees about version of symbol HYPERVISOR_shared_info</di=
v><div>scsi_mod: Unknown symbol HYPERVISOR_shared_info</div><div>sd_mod: Un=
known symbol scsi_print_sense_hdr</div><div>sd_mod: Unknown symbol scsi_mod=
e_sense</div>

<div>sd_mod: Unknown symbol scsi_device_get</div><div>sd_mod: Unknown symbo=
l scsi_get_sense_info_fld</div><div>sd_mod: Unknown symbol scsicam_bios_par=
am</div><div>sd_mod: Unknown symbol scsi_command_normalize_sense</div>
<div>
sd_mod: Unknown symbol scsi_test_unit_ready</div><div>sd_mod: Unknown symbo=
l scsi_block_when_processing_errors</div><div>sd_mod: Unknown symbol scsi_r=
egister_driver</div><div>sd_mod: Unknown symbol scsi_ioctl</div><div>sd_mod=
: Unknown symbol scsi_nonblockable_ioctl</div>

<div>sd_mod: Unknown symbol scsi_device_put</div><div>sd_mod: Unknown symbo=
l scsi_logging_level</div><div>sd_mod: Unknown symbol scsi_execute_req</div=
><div>sd_mod: Unknown symbol scsi_mode_select</div><div>sd_mod: Unknown sym=
bol scsi_print_sense</div>

<div>sd_mod: Unknown symbol scsi_io_completion</div><div>sd_mod: Unknown sy=
mbol scsi_set_medium_removal</div><div>libata: Unknown symbol scsi_device_g=
et</div><div>libata: Unknown symbol scsi_remove_host</div><div>libata: Unkn=
own symbol scsi_schedule_eh</div>

<div>libata: Unknown symbol scsi_device_set_state</div><div>libata: Unknown=
 symbol scsi_eh_finish_cmd</div><div>libata: Unknown symbol scsi_device_put=
</div><div>libata: Unknown symbol scsi_eh_flush_done_q</div><div>libata: Un=
known symbol scsi_host_put</div>

<div>libata: Unknown symbol scsi_add_host</div><div>libata: Unknown symbol =
scsi_rescan_device</div><div>libata: Unknown symbol scsi_adjust_queue_depth=
</div><div>libata: Unknown symbol scsi_execute_req</div><div>libata: Unknow=
n symbol scsi_req_abort_cmd</div>

<div>libata: disagrees about version of symbol HYPERVISOR_shared_info</div>=
<div>libata: Unknown symbol HYPERVISOR_shared_info</div><div>libata: Unknow=
n symbol scsi_remove_device</div><div>libata: Unknown symbol scsi_host_allo=
c</div>

<div>libata: Unknown symbol __scsi_add_device</div><div>ahci: Unknown symbo=
l ata_scsi_ioctl</div><div>ahci: Unknown symbol ata_port_abort</div><div>ah=
ci: Unknown symbol ata_std_bios_param</div><div>ahci: Unknown symbol ata_st=
d_postreset</div>

<div>ahci: Unknown symbol ata_scsi_device_resume</div><div>ahci: Unknown sy=
mbol ata_scsi_device_suspend</div><div>ahci: Unknown symbol ata_tf_from_fis=
</div><div>ahci: Unknown symbol ata_qc_complete_multiple</div><div>ahci: Un=
known symbol ata_noop_dev_select</div>

<div>ahci: Unknown symbol ata_tf_to_fis</div><div>ahci: Unknown symbol ata_=
pci_device_do_resume</div><div>ahci: Unknown symbol ata_dev_classify</div><=
div>ahci: Unknown symbol ata_scsi_release</div><div>ahci: Unknown symbol at=
a_port_offline</div>

<div>ahci: Unknown symbol ata_scsi_change_queue_depth</div><div>ahci: Unkno=
wn symbol sata_std_hardreset</div><div>ahci: Unknown symbol ata_pci_device_=
suspend</div><div>ahci: Unknown symbol scsi_host_put</div><div>ahci: Unknow=
n symbol ata_port_online</div>

<div>ahci: Unknown symbol ata_wait_register</div><div>ahci: Unknown symbol =
ata_busy_sleep</div><div>ahci: Unknown symbol ata_scsi_slave_config</div><d=
iv>ahci: Unknown symbol ata_port_detach</div><div>ahci: Unknown symbol ata_=
port_disable</div>

<div>ahci: Unknown symbol ata_scsi_queuecmd</div><div>ahci: Unknown symbol =
ata_scsi_slave_destroy</div><div>ahci: Unknown symbol ata_ratelimit</div><d=
iv>ahci: Unknown symbol ata_host_set_resume</div><div>ahci: Unknown symbol =
ata_do_eh</div>

<div>ahci: Unknown symbol ata_port_freeze</div><div>ahci: Unknown symbol at=
a_std_prereset</div><div>ahci: Unknown symbol ata_device_add</div><span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><div>=C2=A0 =C2=A0 =C2=A0</div><div><=
br></div><div>
<br></div>-- <br>Best Regards,<div>Bei Guan</div>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Best Regards,<div>Bei Guan</div><br>

--f46d041824ee481a8104bdb3daa3--


--===============2998025191639309644==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2998025191639309644==--


From xen-devel-bounces@lists.xen.org Sun Apr 15 08:58:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 08:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJLHZ-0008QF-LR; Sun, 15 Apr 2012 08:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <summerxyt@gmail.com>) id 1SJLHX-0008Q7-QP
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 08:58:04 +0000
Received: from [85.158.143.35:19984] by server-2.bemta-4.messagelabs.com id
	19/5F-17550-A9D8A8F4; Sun, 15 Apr 2012 08:58:02 +0000
X-Env-Sender: summerxyt@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334480281!4894617!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MIME_BASE64_TEXT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31120 invoked from network); 15 Apr 2012 08:58:02 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 08:58:02 -0000
Received: by lahe6 with SMTP id e6so3870030lah.32
	for <xen-devel@lists.xen.org>; Sun, 15 Apr 2012 01:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Q7EdHrN/1UKp2EIUCi/UbzlNfbSx06NYv4tSWjo64Ho=;
	b=dJ18odDiqwWVL6Ct7TCfGmgTNrVulIXYDoVMq8g0+77wp5pSWOFYly6pO96e1SDTob
	jLM+II4mZD3PC3eJ8ASHHCLVtZ9bIDaBd1qUPbozhAvcQ9iaO+OMbVuRskhHoVnHQZyt
	qWdlI8qvg7F8w02r2/ms/P4+s+9ISBVb1PvHGWlvKxi+dJ3icxODHH3WyLFrvj9W83FB
	Ps/qh/NhbZGOkVd5jejYl0aOT+f6PnPR5YnE+JqFoObmdysoN6/7vWEMvPACkBMDX4c4
	txZec5A/MUAH03+LOCOZ5sGv3Sijanz5a7OK7Tuja0nJtuAp8M5TgilexqtDN1dlZxUH
	IkZA==
MIME-Version: 1.0
Received: by 10.152.104.80 with SMTP id gc16mr6659112lab.46.1334480281186;
	Sun, 15 Apr 2012 01:58:01 -0700 (PDT)
Received: by 10.112.28.169 with HTTP; Sun, 15 Apr 2012 01:58:00 -0700 (PDT)
Date: Sun, 15 Apr 2012 16:58:00 +0800
Message-ID: <CAMjnu2e4DL_MKHPEJcSWwBUkCTSQ9kha5D-TzkPu4PWUb4nu6Q@mail.gmail.com>
From: =?GB2312?B?z8TStczt?= <summerxyt@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Problem about DOMID_SELF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8758101159331745418=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8758101159331745418==
Content-Type: multipart/alternative; boundary=f46d040714d51eb09f04bdb3e712

--f46d040714d51eb09f04bdb3e712
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,

I'm new on this field. The comment of source code says that "DOMID_SELF is
used in certain contexts to refer to oneself." Is this id the micro returns
the same as the id which i can get by xm list?

This is the result of my xm list:
[xyt@localhost xen_onoff]$ sudo xm list
Name                                        ID   Mem VCPUs      State
Time(s)
Domain-0                                   0    1974     2     r-----
30180.0
reciever                                             512
1               0.0
sender                                       2      512     1     -b----
76.1

But if I use  printk(KERN_EMERG"this dom:%d\n",DOMID_SELF) on Dom0, the
result is 32752 instead of 0.

Could someone tell me why this happens? Thanks!

--f46d040714d51eb09f04bdb3e712
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsPGJyPjxicj5JJiMzOTttIG5ldyBvbiB0aGlzIGZpZWxkLiBUaGUgY29tbWVu
dCBvZiBzb3VyY2UgY29kZSBzYXlzIHRoYXQ8c3BhbiBjbGFzcz0iY29tbWVudCI+ICZxdW90O0RP
TUlEX1NFTEYgaXMgdXNlZCBpbiBjZXJ0YWluIGNvbnRleHRzIHRvIHJlZmVyIHRvIG9uZXNlbGYu
JnF1b3Q7IElzIHRoaXMgaWQgdGhlIG1pY3JvIHJldHVybnMgdGhlIHNhbWUgYXMgdGhlIGlkIHdo
aWNoIGkgY2FuIGdldCBieSB4bSBsaXN0Pzxicj4KPGJyPlRoaXMgaXMgdGhlIHJlc3VsdCBvZiBt
eSB4bSBsaXN0Ojxicj5beHl0QGxvY2FsaG9zdCB4ZW5fb25vZmZdJCBzdWRvIHhtIGxpc3Q8YnI+
TmFtZaCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBJRKCgIE1lbSBWQ1BV
c6CgoKCgIFN0YXRloKAgVGltZShzKTxicj5Eb21haW4tMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKAgMKCgoCAxOTc0oKCgoCAyoKCgoCByLS0tLS2goKAgMzAxODAuMDxicj4KcmVj
aWV2ZXKgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA1MTKgoKCg
oCAxoKCgoKCgoKCgoKCgoKAgMC4wPGJyPnNlbmRlcqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgIDKgIKAgoCA1MTKgoKCgIDGgoKCgIC1iLS0tLaCgoCA3Ni4xPGJyPjxicj5C
dXQgaWYgSSB1c2WgIHByaW50ayhLRVJOX0VNRVJHJnF1b3Q7dGhpcyBkb206JWRcbiZxdW90OyxE
T01JRF9TRUxGKSBvbiBEb20wLCB0aGUgcmVzdWx0IGlzIDMyNzUyIGluc3RlYWQgb2YgMC48YnI+
Cjxicj5Db3VsZCBzb21lb25lIHRlbGwgbWUgd2h5IHRoaXMgaGFwcGVucz8gVGhhbmtzITxicj48
YnI+PC9zcGFuPgo=
--f46d040714d51eb09f04bdb3e712--


--===============8758101159331745418==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8758101159331745418==--


From xen-devel-bounces@lists.xen.org Sun Apr 15 08:58:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 08:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJLHZ-0008QF-LR; Sun, 15 Apr 2012 08:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <summerxyt@gmail.com>) id 1SJLHX-0008Q7-QP
	for xen-devel@lists.xen.org; Sun, 15 Apr 2012 08:58:04 +0000
Received: from [85.158.143.35:19984] by server-2.bemta-4.messagelabs.com id
	19/5F-17550-A9D8A8F4; Sun, 15 Apr 2012 08:58:02 +0000
X-Env-Sender: summerxyt@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334480281!4894617!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MIME_BASE64_TEXT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31120 invoked from network); 15 Apr 2012 08:58:02 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 08:58:02 -0000
Received: by lahe6 with SMTP id e6so3870030lah.32
	for <xen-devel@lists.xen.org>; Sun, 15 Apr 2012 01:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Q7EdHrN/1UKp2EIUCi/UbzlNfbSx06NYv4tSWjo64Ho=;
	b=dJ18odDiqwWVL6Ct7TCfGmgTNrVulIXYDoVMq8g0+77wp5pSWOFYly6pO96e1SDTob
	jLM+II4mZD3PC3eJ8ASHHCLVtZ9bIDaBd1qUPbozhAvcQ9iaO+OMbVuRskhHoVnHQZyt
	qWdlI8qvg7F8w02r2/ms/P4+s+9ISBVb1PvHGWlvKxi+dJ3icxODHH3WyLFrvj9W83FB
	Ps/qh/NhbZGOkVd5jejYl0aOT+f6PnPR5YnE+JqFoObmdysoN6/7vWEMvPACkBMDX4c4
	txZec5A/MUAH03+LOCOZ5sGv3Sijanz5a7OK7Tuja0nJtuAp8M5TgilexqtDN1dlZxUH
	IkZA==
MIME-Version: 1.0
Received: by 10.152.104.80 with SMTP id gc16mr6659112lab.46.1334480281186;
	Sun, 15 Apr 2012 01:58:01 -0700 (PDT)
Received: by 10.112.28.169 with HTTP; Sun, 15 Apr 2012 01:58:00 -0700 (PDT)
Date: Sun, 15 Apr 2012 16:58:00 +0800
Message-ID: <CAMjnu2e4DL_MKHPEJcSWwBUkCTSQ9kha5D-TzkPu4PWUb4nu6Q@mail.gmail.com>
From: =?GB2312?B?z8TStczt?= <summerxyt@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Problem about DOMID_SELF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8758101159331745418=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8758101159331745418==
Content-Type: multipart/alternative; boundary=f46d040714d51eb09f04bdb3e712

--f46d040714d51eb09f04bdb3e712
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,

I'm new on this field. The comment of source code says that "DOMID_SELF is
used in certain contexts to refer to oneself." Is this id the micro returns
the same as the id which i can get by xm list?

This is the result of my xm list:
[xyt@localhost xen_onoff]$ sudo xm list
Name                                        ID   Mem VCPUs      State
Time(s)
Domain-0                                   0    1974     2     r-----
30180.0
reciever                                             512
1               0.0
sender                                       2      512     1     -b----
76.1

But if I use  printk(KERN_EMERG"this dom:%d\n",DOMID_SELF) on Dom0, the
result is 32752 instead of 0.

Could someone tell me why this happens? Thanks!

--f46d040714d51eb09f04bdb3e712
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsPGJyPjxicj5JJiMzOTttIG5ldyBvbiB0aGlzIGZpZWxkLiBUaGUgY29tbWVu
dCBvZiBzb3VyY2UgY29kZSBzYXlzIHRoYXQ8c3BhbiBjbGFzcz0iY29tbWVudCI+ICZxdW90O0RP
TUlEX1NFTEYgaXMgdXNlZCBpbiBjZXJ0YWluIGNvbnRleHRzIHRvIHJlZmVyIHRvIG9uZXNlbGYu
JnF1b3Q7IElzIHRoaXMgaWQgdGhlIG1pY3JvIHJldHVybnMgdGhlIHNhbWUgYXMgdGhlIGlkIHdo
aWNoIGkgY2FuIGdldCBieSB4bSBsaXN0Pzxicj4KPGJyPlRoaXMgaXMgdGhlIHJlc3VsdCBvZiBt
eSB4bSBsaXN0Ojxicj5beHl0QGxvY2FsaG9zdCB4ZW5fb25vZmZdJCBzdWRvIHhtIGxpc3Q8YnI+
TmFtZaCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBJRKCgIE1lbSBWQ1BV
c6CgoKCgIFN0YXRloKAgVGltZShzKTxicj5Eb21haW4tMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKAgMKCgoCAxOTc0oKCgoCAyoKCgoCByLS0tLS2goKAgMzAxODAuMDxicj4KcmVj
aWV2ZXKgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA1MTKgoKCg
oCAxoKCgoKCgoKCgoKCgoKAgMC4wPGJyPnNlbmRlcqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgIDKgIKAgoCA1MTKgoKCgIDGgoKCgIC1iLS0tLaCgoCA3Ni4xPGJyPjxicj5C
dXQgaWYgSSB1c2WgIHByaW50ayhLRVJOX0VNRVJHJnF1b3Q7dGhpcyBkb206JWRcbiZxdW90OyxE
T01JRF9TRUxGKSBvbiBEb20wLCB0aGUgcmVzdWx0IGlzIDMyNzUyIGluc3RlYWQgb2YgMC48YnI+
Cjxicj5Db3VsZCBzb21lb25lIHRlbGwgbWUgd2h5IHRoaXMgaGFwcGVucz8gVGhhbmtzITxicj48
YnI+PC9zcGFuPgo=
--f46d040714d51eb09f04bdb3e712--


--===============8758101159331745418==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8758101159331745418==--


From xen-devel-bounces@lists.xen.org Sun Apr 15 14:07:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 14:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJQ6C-0001um-1Q; Sun, 15 Apr 2012 14:06:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1SJQ6A-0001uh-Sg
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 14:06:39 +0000
Received: from [85.158.143.99:27973] by server-2.bemta-4.messagelabs.com id
	3C/57-17550-EE5DA8F4; Sun, 15 Apr 2012 14:06:38 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334498795!20338469!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9369 invoked from network); 15 Apr 2012 14:06:37 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 14:06:37 -0000
Received: by iadj38 with SMTP id j38so7733687iad.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Apr 2012 07:06:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Rb4VNpQt4ax6atmPKytgng+Lc3uUWTP5rB7O+iEVieo=;
	b=ufVDGqHiq/6puYCVcv/F4Ax4IUz3K9IHeFfqRybcaJ3vfJ9Us0qKK7hoevN0BsMPir
	4Laemd50QbAiHYyRD1LKjMaVZU1W1N+jcWtlWlEKqfUoHc6FJ99qRYHk8mYkkpFz0onu
	aNxu247Tg65BkYYu+f0wBYIxZ/YlLmiQ6rfsiecBsyBrntLB25KcbfcuAchQVbQRxkBR
	osOEgaNILlv6EtVgFURSAbTasXFHTYCKC58M5Km55iYhzIbzGeNRBW2Dtfi3COqoZZ8e
	Mpy3BenLFF5Ja/e6jOvcoVKCR5ACyvtfKirMVL8BwYC5DnDl4Ez2AhtJzCDXaE48xDQs
	79Nw==
Received: by 10.50.154.132 with SMTP id vo4mr3165462igb.27.1334498795263;
	Sun, 15 Apr 2012 07:06:35 -0700 (PDT)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id de2sm6496259igc.4.2012.04.15.07.06.33
	(version=SSLv3 cipher=OTHER); Sun, 15 Apr 2012 07:06:34 -0700 (PDT)
Date: Sun, 15 Apr 2012 09:06:28 -0500
From: Jonathan Nieder <jrnieder@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120415140628.GA4536@burratino>
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<20110829041532.GA22087@elie.gateway.2wire.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20110829041532.GA22087@elie.gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Robert Scott <bugs@humanleg.org.uk>,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Quick summary and update.

> Lars Boegild Thomsen writes[1]:

>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up after 
>> sleep.
[...]
>> 983bbf1af0664b78689612b247acb514300f62c7 is the first bad commit

983bbf1af06 is "x86: Don't unmask disabled irqs when migrating them",
2011-05-06, and looks like this:

>> --- a/arch/x86/kernel/irq.c
>> +++ b/arch/x86/kernel/irq.c
>> @@ -276,7 +276,8 @@ void fixup_irqs(void)
>>  		else if (!(warned++))
>>  			set_affinity = 0;
>>  
>> -		if (!irqd_can_move_in_process_context(data) && chip->irq_unmask)
>> +		if (!irqd_can_move_in_process_context(data) &&
>> +		    !irqd_irq_disabled(data) && chip->irq_unmask)
>>  			chip->irq_unmask(data);

Robert Scott found[1], using 3.2.12:

> I'm getting the same behaviour on my Lenovo Ideapad S10-3

An anonymous contributor[2] also reports the same problem in v3.3.

Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
semantics in fixup_irqs()") will fix this.

Liu Chuansheng et al: do you think that commit would be a good
candidate for inclusion in -stable kernels?

Thanks and hope that helps,
Jonathan

> [1] http://bugs.debian.org/635575
[2] https://bugzilla.kernel.org/show_bug.cgi?id=41932

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 14:07:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 14:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJQ6C-0001um-1Q; Sun, 15 Apr 2012 14:06:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1SJQ6A-0001uh-Sg
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 14:06:39 +0000
Received: from [85.158.143.99:27973] by server-2.bemta-4.messagelabs.com id
	3C/57-17550-EE5DA8F4; Sun, 15 Apr 2012 14:06:38 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334498795!20338469!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9369 invoked from network); 15 Apr 2012 14:06:37 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 14:06:37 -0000
Received: by iadj38 with SMTP id j38so7733687iad.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Apr 2012 07:06:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Rb4VNpQt4ax6atmPKytgng+Lc3uUWTP5rB7O+iEVieo=;
	b=ufVDGqHiq/6puYCVcv/F4Ax4IUz3K9IHeFfqRybcaJ3vfJ9Us0qKK7hoevN0BsMPir
	4Laemd50QbAiHYyRD1LKjMaVZU1W1N+jcWtlWlEKqfUoHc6FJ99qRYHk8mYkkpFz0onu
	aNxu247Tg65BkYYu+f0wBYIxZ/YlLmiQ6rfsiecBsyBrntLB25KcbfcuAchQVbQRxkBR
	osOEgaNILlv6EtVgFURSAbTasXFHTYCKC58M5Km55iYhzIbzGeNRBW2Dtfi3COqoZZ8e
	Mpy3BenLFF5Ja/e6jOvcoVKCR5ACyvtfKirMVL8BwYC5DnDl4Ez2AhtJzCDXaE48xDQs
	79Nw==
Received: by 10.50.154.132 with SMTP id vo4mr3165462igb.27.1334498795263;
	Sun, 15 Apr 2012 07:06:35 -0700 (PDT)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id de2sm6496259igc.4.2012.04.15.07.06.33
	(version=SSLv3 cipher=OTHER); Sun, 15 Apr 2012 07:06:34 -0700 (PDT)
Date: Sun, 15 Apr 2012 09:06:28 -0500
From: Jonathan Nieder <jrnieder@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120415140628.GA4536@burratino>
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<20110829041532.GA22087@elie.gateway.2wire.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20110829041532.GA22087@elie.gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Robert Scott <bugs@humanleg.org.uk>,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Quick summary and update.

> Lars Boegild Thomsen writes[1]:

>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up after 
>> sleep.
[...]
>> 983bbf1af0664b78689612b247acb514300f62c7 is the first bad commit

983bbf1af06 is "x86: Don't unmask disabled irqs when migrating them",
2011-05-06, and looks like this:

>> --- a/arch/x86/kernel/irq.c
>> +++ b/arch/x86/kernel/irq.c
>> @@ -276,7 +276,8 @@ void fixup_irqs(void)
>>  		else if (!(warned++))
>>  			set_affinity = 0;
>>  
>> -		if (!irqd_can_move_in_process_context(data) && chip->irq_unmask)
>> +		if (!irqd_can_move_in_process_context(data) &&
>> +		    !irqd_irq_disabled(data) && chip->irq_unmask)
>>  			chip->irq_unmask(data);

Robert Scott found[1], using 3.2.12:

> I'm getting the same behaviour on my Lenovo Ideapad S10-3

An anonymous contributor[2] also reports the same problem in v3.3.

Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
semantics in fixup_irqs()") will fix this.

Liu Chuansheng et al: do you think that commit would be a good
candidate for inclusion in -stable kernels?

Thanks and hope that helps,
Jonathan

> [1] http://bugs.debian.org/635575
[2] https://bugzilla.kernel.org/show_bug.cgi?id=41932

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 14:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 14:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJQe3-0002F6-1g; Sun, 15 Apr 2012 14:41:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJQe1-0002F1-EL
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 14:41:37 +0000
Received: from [85.158.143.99:52288] by server-1.bemta-4.messagelabs.com id
	5B/1A-20925-02EDA8F4; Sun, 15 Apr 2012 14:41:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334500896!25162466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14671 invoked from network); 15 Apr 2012 14:41:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 14:41:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,425,1330905600"; d="scan'208";a="11942036"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 14:41:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 15:41:35 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJQdz-0001X2-5e;
	Sun, 15 Apr 2012 14:41:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJQdy-0003KK-VF;
	Sun, 15 Apr 2012 15:41:35 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12696-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 15:41:35 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12696: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12696 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12696/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                bfecc60d8f6715ec6b38aa29c4f5a3570415dae0
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 14:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 14:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJQe3-0002F6-1g; Sun, 15 Apr 2012 14:41:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJQe1-0002F1-EL
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 14:41:37 +0000
Received: from [85.158.143.99:52288] by server-1.bemta-4.messagelabs.com id
	5B/1A-20925-02EDA8F4; Sun, 15 Apr 2012 14:41:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334500896!25162466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14671 invoked from network); 15 Apr 2012 14:41:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 14:41:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,425,1330905600"; d="scan'208";a="11942036"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 14:41:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 15:41:35 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJQdz-0001X2-5e;
	Sun, 15 Apr 2012 14:41:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJQdy-0003KK-VF;
	Sun, 15 Apr 2012 15:41:35 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12696-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 15:41:35 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12696: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12696 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12696/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                bfecc60d8f6715ec6b38aa29c4f5a3570415dae0
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 18:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 18:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJUPy-0003uG-AP; Sun, 15 Apr 2012 18:43:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SJUPw-0003uB-LJ
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 18:43:21 +0000
Received: from [193.109.254.147:44040] by server-11.bemta-14.messagelabs.com
	id 3A/6C-05858-7C61B8F4; Sun, 15 Apr 2012 18:43:19 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334515395!4685665!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24458 invoked from network); 15 Apr 2012 18:43:15 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 18:43:15 -0000
Received: by wibhm17 with SMTP id hm17so6743634wib.0
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Apr 2012 11:43:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=7BuRHr87m8tOhk9EBnDijl6/YURrWsogP/aXQZ7cbP0=;
	b=hyhAmUrb7OSHnG73zPCn6Ceh9gwStA5mmpLiTFzJcOQscdkTT9cy6iqgjbDToqZvd4
	4kt/ktqfevZNbn3ZM77ncLJIxhqgFOSBHxd5iUS/HR6Y1zA9PySyzw5Ns8ErOG4Lz7PN
	hng9J6xNsoiM+TiBOiX5AsUkcgTEWS6rjNvVXeVcNFBROgf844C1LVC0QnwCYZeWrok0
	96rFVDc8OoGUAO4KTckVGFcslUOGrm522F9iIwXrxW/Vn+pQzrS3I4EvoY3d/SYqRim+
	3PNTC0ZXWak6mCDC/gwTpKY8HQAeLhqbMpFKe1JLUC4oKkF58Htus23+U0lj/lnwsl//
	wMyA==
Received: by 10.216.132.8 with SMTP id n8mr5036004wei.36.1334515395427;
	Sun, 15 Apr 2012 11:43:15 -0700 (PDT)
Received: from debian (cpc2-cmbg15-2-0-cust282.5-4.cable.virginmedia.com.
	[86.26.13.27])
	by mx.google.com with ESMTPS id l5sm14091147wia.11.2012.04.15.11.43.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 15 Apr 2012 11:43:14 -0700 (PDT)
Received: from xen by debian with local (Exim 4.77)
	(envelope-from <jean.guyader@gmail.com>)
	id 1SJUPo-0007nT-31; Sun, 15 Apr 2012 11:43:12 -0700
From: Jean Guyader <jean.guyader@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sun, 15 Apr 2012 11:43:10 -0700
Message-Id: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Jean Guyader <jean.guyader@gmail.com>
Subject: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl require the command flex to be present.
Verify in the configure script that the flex
command exsits.

Signed-off-by: Jean Guyader <jean.guyader@gmail.com>
---
 tools/configure    |  633 +++++++++++++++++++++++++++++-----------------------
 tools/configure.ac |    1 +
 2 files changed, 350 insertions(+), 284 deletions(-)

diff --git a/tools/configure b/tools/configure
index 86618f5..071adf7 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
 #
 # Report bugs to <xen-devel@lists.xensource.com>.
 #
@@ -91,6 +91,7 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
+as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -216,11 +217,18 @@ IFS=$as_save_IFS
   # We cannot yet assume a decent shell, so we have to provide a
 	# neutralization value for shells without unset; and this also
 	# works around shells that cannot unset nonexistent variables.
+	# Preserve -v and -x to the replacement shell.
 	BASH_ENV=/dev/null
 	ENV=/dev/null
 	(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
 	export CONFIG_SHELL
-	exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
+	case $- in # ((((
+	  *v*x* | *x*v* ) as_opts=-vx ;;
+	  *v* ) as_opts=-v ;;
+	  *x* ) as_opts=-x ;;
+	  * ) as_opts= ;;
+	esac
+	exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
 fi
 
     if test x$as_have_required = xno; then :
@@ -1164,7 +1172,7 @@ Try \`$0 --help' for more information"
     $as_echo "$as_me: WARNING: you should use --build, --host, --target" >&2
     expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
       $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
-    : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}
+    : "${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}"
     ;;
 
   esac
@@ -1490,7 +1498,7 @@ test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
 Xen Hypervisor configure 4.2
-generated by GNU Autoconf 2.67
+generated by GNU Autoconf 2.68
 
 Copyright (C) 2010 Free Software Foundation, Inc.
 This configure script is free software; the Free Software Foundation
@@ -1536,7 +1544,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
 	ac_retval=1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_compile
@@ -1573,7 +1581,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
     ac_retval=1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_cpp
@@ -1586,10 +1594,10 @@ fi
 ac_fn_c_check_header_mongrel ()
 {
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  if eval "test \"\${$3+set}\"" = set; then :
+  if eval \${$3+:} false; then :
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 fi
 eval ac_res=\$$3
@@ -1656,7 +1664,7 @@ $as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
 esac
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=\$ac_header_compiler"
@@ -1665,7 +1673,7 @@ eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_header_mongrel
 
@@ -1706,7 +1714,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
        ac_retval=$ac_status
 fi
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_run
@@ -1720,7 +1728,7 @@ ac_fn_c_check_header_compile ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1738,7 +1746,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_header_compile
 
@@ -1783,11 +1791,65 @@ fi
   # interfere with the next link command; also delete a directory that is
   # left behind by Apple's compiler.  We do this before executing the actions.
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_link
 
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# -------------------------------------------
+# Tests whether TYPE exists after having included INCLUDES, setting cache
+# variable VAR accordingly.
+ac_fn_c_check_type ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval \${$3+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  eval "$3=no"
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof ($2))
+	 return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof (($2)))
+	    return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+
+else
+  eval "$3=yes"
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+eval ac_res=\$$3
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+
+} # ac_fn_c_check_type
+
 # ac_fn_c_check_func LINENO FUNC VAR
 # ----------------------------------
 # Tests whether FUNC exists, setting the cache variable VAR accordingly
@@ -1796,7 +1858,7 @@ ac_fn_c_check_func ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1851,64 +1913,10 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_func
 
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# -------------------------------------------
-# Tests whether TYPE exists after having included INCLUDES, setting cache
-# variable VAR accordingly.
-ac_fn_c_check_type ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
-  $as_echo_n "(cached) " >&6
-else
-  eval "$3=no"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof ($2))
-	 return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof (($2)))
-	    return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  eval "$3=yes"
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-eval ac_res=\$$3
-	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
-
-} # ac_fn_c_check_type
-
 # ac_fn_c_find_intX_t LINENO BITS VAR
 # -----------------------------------
 # Finds a signed integer type with width BITS, setting cache variable VAR
@@ -1918,7 +1926,7 @@ ac_fn_c_find_intX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
 $as_echo_n "checking for int$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -1979,7 +1987,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_find_intX_t
 
@@ -1992,7 +2000,7 @@ ac_fn_c_check_member ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
 $as_echo_n "checking for $2.$3... " >&6; }
-if eval "test \"\${$4+set}\"" = set; then :
+if eval \${$4+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -2036,7 +2044,7 @@ fi
 eval ac_res=\$$4
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_member
 
@@ -2049,7 +2057,7 @@ ac_fn_c_find_uintX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
 $as_echo_n "checking for uint$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -2089,7 +2097,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_find_uintX_t
 cat >config.log <<_ACEOF
@@ -2097,7 +2105,7 @@ This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
 It was created by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
 
   $ $0 $@
 
@@ -2355,7 +2363,7 @@ $as_echo "$as_me: loading site script $ac_site_file" >&6;}
       || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "failed to load site script $ac_site_file
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
   fi
 done
 
@@ -2508,7 +2516,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2548,7 +2556,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2601,7 +2609,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2641,7 +2649,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2700,7 +2708,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2744,7 +2752,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2799,7 +2807,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -2914,7 +2922,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error 77 "C compiler cannot create executables
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
@@ -2957,7 +2965,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of executables: cannot compile and link
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest conftest$ac_cv_exeext
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
@@ -3016,7 +3024,7 @@ $as_echo "$ac_try_echo"; } >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
     fi
   fi
 fi
@@ -3027,7 +3035,7 @@ rm -f conftest.$ac_ext conftest$ac_cv_exeext conftest.out
 ac_clean_files=$ac_clean_files_save
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
 $as_echo_n "checking for suffix of object files... " >&6; }
-if test "${ac_cv_objext+set}" = set; then :
+if ${ac_cv_objext+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3068,7 +3076,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of object files: cannot compile
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest.$ac_cv_objext conftest.$ac_ext
 fi
@@ -3078,7 +3086,7 @@ OBJEXT=$ac_cv_objext
 ac_objext=$OBJEXT
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if test "${ac_cv_c_compiler_gnu+set}" = set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3115,7 +3123,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" = set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -3193,7 +3201,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" = set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -3301,7 +3309,7 @@ if test -n "$CPP" && test -d "$CPP"; then
   CPP=
 fi
 if test -z "$CPP"; then
-  if test "${ac_cv_prog_CPP+set}" = set; then :
+  if ${ac_cv_prog_CPP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
       # Double quotes because CPP needs to be expanded
@@ -3417,7 +3425,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 
 ac_ext=c
@@ -3429,7 +3437,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles long lines and -e" >&5
 $as_echo_n "checking for grep that handles long lines and -e... " >&6; }
-if test "${ac_cv_path_GREP+set}" = set; then :
+if ${ac_cv_path_GREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -z "$GREP"; then
@@ -3492,7 +3500,7 @@ $as_echo "$ac_cv_path_GREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
 $as_echo_n "checking for egrep... " >&6; }
-if test "${ac_cv_path_EGREP+set}" = set; then :
+if ${ac_cv_path_EGREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
@@ -3559,7 +3567,7 @@ $as_echo "$ac_cv_path_EGREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header files" >&5
 $as_echo_n "checking for ANSI C header files... " >&6; }
-if test "${ac_cv_header_stdc+set}" = set; then :
+if ${ac_cv_header_stdc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3688,7 +3696,7 @@ done
 
 
   ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_minix_config_h" "$ac_includes_default"
-if test "x$ac_cv_header_minix_config_h" = x""yes; then :
+if test "x$ac_cv_header_minix_config_h" = xyes; then :
   MINIX=yes
 else
   MINIX=
@@ -3710,7 +3718,7 @@ $as_echo "#define _MINIX 1" >>confdefs.h
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe to define __EXTENSIONS__" >&5
 $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&6; }
-if test "${ac_cv_safe_to_define___extensions__+set}" = set; then :
+if ${ac_cv_safe_to_define___extensions__+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3753,7 +3761,7 @@ $SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
 $as_echo_n "checking build system type... " >&6; }
-if test "${ac_cv_build+set}" = set; then :
+if ${ac_cv_build+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_build_alias=$build_alias
@@ -3769,7 +3777,7 @@ fi
 $as_echo "$ac_cv_build" >&6; }
 case $ac_cv_build in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
 esac
 build=$ac_cv_build
 ac_save_IFS=$IFS; IFS='-'
@@ -3787,7 +3795,7 @@ case $build_os in *\ *) build_os=`echo "$build_os" | sed 's/ /-/g'`;; esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
 $as_echo_n "checking host system type... " >&6; }
-if test "${ac_cv_host+set}" = set; then :
+if ${ac_cv_host+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "x$host_alias" = x; then
@@ -3802,7 +3810,7 @@ fi
 $as_echo "$ac_cv_host" >&6; }
 case $ac_cv_host in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
 esac
 host=$ac_cv_host
 ac_save_IFS=$IFS; IFS='-'
@@ -4196,7 +4204,7 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
-if test "${ac_cv_path_SED+set}" = set; then :
+if ${ac_cv_path_SED+:} false; then :
   $as_echo_n "(cached) " >&6
 else
             ac_script=s/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/
@@ -4273,7 +4281,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4313,7 +4321,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4366,7 +4374,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4406,7 +4414,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4465,7 +4473,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4509,7 +4517,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4564,7 +4572,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -4593,7 +4601,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if test "${ac_cv_c_compiler_gnu+set}" = set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -4630,7 +4638,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" = set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -4708,7 +4716,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" = set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -4818,7 +4826,7 @@ fi
 $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
 set x ${MAKE-make}
 ac_make=`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
-if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" = set; then :
+if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat >conftest.make <<\_ACEOF
@@ -4862,7 +4870,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible install" >&5
 $as_echo_n "checking for a BSD-compatible install... " >&6; }
 if test -z "$INSTALL"; then
-if test "${ac_cv_path_install+set}" = set; then :
+if ${ac_cv_path_install+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -4942,7 +4950,7 @@ test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 set dummy perl; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PERL+set}" = set; then :
+if ${ac_cv_path_PERL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PERL in
@@ -4989,7 +4997,7 @@ if test "x$xapi" = "xy"; then :
 set dummy curl-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_CURL+set}" = set; then :
+if ${ac_cv_path_CURL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $CURL in
@@ -5034,7 +5042,7 @@ fi
 set dummy xml2-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XML+set}" = set; then :
+if ${ac_cv_path_XML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XML in
@@ -5085,7 +5093,7 @@ if test "x$ocamltools" = "xy"; then :
 set dummy ${ac_tool_prefix}ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLC+set}" = set; then :
+if ${ac_cv_prog_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLC"; then
@@ -5125,7 +5133,7 @@ if test -z "$ac_cv_prog_OCAMLC"; then
 set dummy ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLC"; then
@@ -5196,7 +5204,7 @@ $as_echo "OCaml library path is $OCAMLLIB" >&6; }
 set dummy ${ac_tool_prefix}ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPT+set}" = set; then :
+if ${ac_cv_prog_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPT"; then
@@ -5236,7 +5244,7 @@ if test -z "$ac_cv_prog_OCAMLOPT"; then
 set dummy ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPT"; then
@@ -5306,7 +5314,7 @@ $as_echo "versions differs from ocamlc; ocamlopt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLCDOTOPT+set}" = set; then :
+if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLCDOTOPT"; then
@@ -5346,7 +5354,7 @@ if test -z "$ac_cv_prog_OCAMLCDOTOPT"; then
 set dummy ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLCDOTOPT"; then
@@ -5410,7 +5418,7 @@ $as_echo "versions differs from ocamlc; ocamlc.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" = set; then :
+if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPTDOTOPT"; then
@@ -5450,7 +5458,7 @@ if test -z "$ac_cv_prog_OCAMLOPTDOTOPT"; then
 set dummy ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
@@ -5519,7 +5527,7 @@ $as_echo "version differs from ocamlc; ocamlopt.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAML+set}" = set; then :
+if ${ac_cv_prog_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAML"; then
@@ -5559,7 +5567,7 @@ if test -z "$ac_cv_prog_OCAML"; then
 set dummy ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAML+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAML"; then
@@ -5613,7 +5621,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDEP+set}" = set; then :
+if ${ac_cv_prog_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDEP"; then
@@ -5653,7 +5661,7 @@ if test -z "$ac_cv_prog_OCAMLDEP"; then
 set dummy ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDEP"; then
@@ -5707,7 +5715,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKTOP+set}" = set; then :
+if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKTOP"; then
@@ -5747,7 +5755,7 @@ if test -z "$ac_cv_prog_OCAMLMKTOP"; then
 set dummy ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKTOP"; then
@@ -5801,7 +5809,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKLIB+set}" = set; then :
+if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKLIB"; then
@@ -5841,7 +5849,7 @@ if test -z "$ac_cv_prog_OCAMLMKLIB"; then
 set dummy ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKLIB"; then
@@ -5895,7 +5903,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDOC+set}" = set; then :
+if ${ac_cv_prog_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDOC"; then
@@ -5935,7 +5943,7 @@ if test -z "$ac_cv_prog_OCAMLDOC"; then
 set dummy ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDOC"; then
@@ -5989,7 +5997,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLBUILD+set}" = set; then :
+if ${ac_cv_prog_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLBUILD"; then
@@ -6029,7 +6037,7 @@ if test -z "$ac_cv_prog_OCAMLBUILD"; then
 set dummy ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLBUILD"; then
@@ -6092,7 +6100,7 @@ fi
 set dummy bash; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BASH+set}" = set; then :
+if ${ac_cv_path_BASH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $BASH in
@@ -6149,7 +6157,7 @@ fi
 set dummy $PYTHON; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PYTHONPATH+set}" = set; then :
+if ${ac_cv_path_PYTHONPATH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PYTHONPATH in
@@ -6225,7 +6233,7 @@ LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
     print distutils.sysconfig.get_config_var("LDFLAGS")'`"
 
 ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h" "$ac_includes_default"
-if test "x$ac_cv_header_Python_h" = x""yes; then :
+if test "x$ac_cv_header_Python_h" = xyes; then :
 
 else
   as_fn_error $? "Unable to find Python development headers" "$LINENO" 5
@@ -6235,7 +6243,7 @@ fi
 as_ac_Lib=`$as_echo "ac_cv_lib_python$ac_python_version''_PyArg_ParseTuple" | $as_tr_sh`
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PyArg_ParseTuple in -lpython$ac_python_version" >&5
 $as_echo_n "checking for PyArg_ParseTuple in -lpython$ac_python_version... " >&6; }
-if eval "test \"\${$as_ac_Lib+set}\"" = set; then :
+if eval \${$as_ac_Lib+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6290,7 +6298,7 @@ fi
 set dummy xgettext; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XGETTEXT+set}" = set; then :
+if ${ac_cv_path_XGETTEXT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XGETTEXT in
@@ -6335,7 +6343,7 @@ fi
 set dummy as86; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_AS86+set}" = set; then :
+if ${ac_cv_path_AS86+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $AS86 in
@@ -6380,7 +6388,7 @@ fi
 set dummy ld86; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_LD86+set}" = set; then :
+if ${ac_cv_path_LD86+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $LD86 in
@@ -6425,7 +6433,7 @@ fi
 set dummy bcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BCC+set}" = set; then :
+if ${ac_cv_path_BCC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $BCC in
@@ -6470,7 +6478,7 @@ fi
 set dummy iasl; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_IASL+set}" = set; then :
+if ${ac_cv_path_IASL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $IASL in
@@ -6511,13 +6519,58 @@ if test x"${IASL}" == x"no"
 then
     as_fn_error $? "Unable to find iasl, please install iasl" "$LINENO" 5
 fi
+# Extract the first word of "flex", so it can be a program name with args.
+set dummy flex; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_FLEX+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  case $FLEX in
+  [\\/]* | ?:[\\/]*)
+  ac_cv_path_FLEX="$FLEX" # Let the user override the test with a path.
+  ;;
+  *)
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+    for ac_exec_ext in '' $ac_executable_extensions; do
+  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
+    ac_cv_path_FLEX="$as_dir/$ac_word$ac_exec_ext"
+    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+  test -z "$ac_cv_path_FLEX" && ac_cv_path_FLEX="no"
+  ;;
+esac
+fi
+FLEX=$ac_cv_path_FLEX
+if test -n "$FLEX"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $FLEX" >&5
+$as_echo "$FLEX" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+if test x"${FLEX}" == x"no"
+then
+    as_fn_error $? "Unable to find flex, please install flex" "$LINENO" 5
+fi
 
 ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_uuid_h" = x""yes; then :
+if test "x$ac_cv_header_uuid_uuid_h" = xyes; then :
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
-if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
+if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6551,7 +6604,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_clear" >&5
 $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
-if test "x$ac_cv_lib_uuid_uuid_clear" = x""yes; then :
+if test "x$ac_cv_lib_uuid_uuid_clear" = xyes; then :
   libuuid="y"
 fi
 
@@ -6560,7 +6613,7 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_h" = x""yes; then :
+if test "x$ac_cv_header_uuid_h" = xyes; then :
   libuuid="y"
 fi
 
@@ -6573,11 +6626,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h" "$ac_includes_default"
-if test "x$ac_cv_header_curses_h" = x""yes; then :
+if test "x$ac_cv_header_curses_h" = xyes; then :
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcurses" >&5
 $as_echo_n "checking for clear in -lcurses... " >&6; }
-if test "${ac_cv_lib_curses_clear+set}" = set; then :
+if ${ac_cv_lib_curses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6611,7 +6664,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear" >&5
 $as_echo "$ac_cv_lib_curses_clear" >&6; }
-if test "x$ac_cv_lib_curses_clear" = x""yes; then :
+if test "x$ac_cv_lib_curses_clear" = xyes; then :
   curses="y"
 else
   curses="n"
@@ -6624,11 +6677,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses_h" "$ac_includes_default"
-if test "x$ac_cv_header_ncurses_h" = x""yes; then :
+if test "x$ac_cv_header_ncurses_h" = xyes; then :
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncurses" >&5
 $as_echo_n "checking for clear in -lncurses... " >&6; }
-if test "${ac_cv_lib_ncurses_clear+set}" = set; then :
+if ${ac_cv_lib_ncurses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6662,7 +6715,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clear" >&5
 $as_echo "$ac_cv_lib_ncurses_clear" >&6; }
-if test "x$ac_cv_lib_ncurses_clear" = x""yes; then :
+if test "x$ac_cv_lib_ncurses_clear" = xyes; then :
   ncurses="y"
 else
   ncurses="n"
@@ -6709,7 +6762,7 @@ if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
 set dummy ${ac_tool_prefix}pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PKG_CONFIG+set}" = set; then :
+if ${ac_cv_path_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PKG_CONFIG in
@@ -6752,7 +6805,7 @@ if test -z "$ac_cv_path_PKG_CONFIG"; then
 set dummy pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" = set; then :
+if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $ac_pt_PKG_CONFIG in
@@ -6897,7 +6950,7 @@ and glib_LIBS to avoid the need to call pkg-config.
 See the pkg-config man page for more details.
 
 To get pkg-config, see <http://pkg-config.freedesktop.org/>.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
 	glib_CFLAGS=$pkg_cv_glib_CFLAGS
 	glib_LIBS=$pkg_cv_glib_LIBS
@@ -6933,11 +6986,11 @@ fi
 
 # Checks for libraries.
 ac_fn_c_check_header_mongrel "$LINENO" "bzlib.h" "ac_cv_header_bzlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_bzlib_h" = x""yes; then :
+if test "x$ac_cv_header_bzlib_h" = xyes; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for BZ2_bzDecompressInit in -lbz2" >&5
 $as_echo_n "checking for BZ2_bzDecompressInit in -lbz2... " >&6; }
-if test "${ac_cv_lib_bz2_BZ2_bzDecompressInit+set}" = set; then :
+if ${ac_cv_lib_bz2_BZ2_bzDecompressInit+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6971,7 +7024,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_bz2_BZ2_bzDecompressInit" >&5
 $as_echo "$ac_cv_lib_bz2_BZ2_bzDecompressInit" >&6; }
-if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" = x""yes; then :
+if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" = xyes; then :
   zlib="$zlib -DHAVE_BZLIB -lbz2"
 fi
 
@@ -6980,11 +7033,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "lzma.h" "ac_cv_header_lzma_h" "$ac_includes_default"
-if test "x$ac_cv_header_lzma_h" = x""yes; then :
+if test "x$ac_cv_header_lzma_h" = xyes; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzma_stream_decoder in -llzma" >&5
 $as_echo_n "checking for lzma_stream_decoder in -llzma... " >&6; }
-if test "${ac_cv_lib_lzma_lzma_stream_decoder+set}" = set; then :
+if ${ac_cv_lib_lzma_lzma_stream_decoder+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7018,7 +7071,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzma_lzma_stream_decoder" >&5
 $as_echo "$ac_cv_lib_lzma_lzma_stream_decoder" >&6; }
-if test "x$ac_cv_lib_lzma_lzma_stream_decoder" = x""yes; then :
+if test "x$ac_cv_lib_lzma_lzma_stream_decoder" = xyes; then :
   zlib="$zlib -DHAVE_LZMA -llzma"
 fi
 
@@ -7027,11 +7080,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "lzo/lzo1x.h" "ac_cv_header_lzo_lzo1x_h" "$ac_includes_default"
-if test "x$ac_cv_header_lzo_lzo1x_h" = x""yes; then :
+if test "x$ac_cv_header_lzo_lzo1x_h" = xyes; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzo1x_decompress in -llzo2" >&5
 $as_echo_n "checking for lzo1x_decompress in -llzo2... " >&6; }
-if test "${ac_cv_lib_lzo2_lzo1x_decompress+set}" = set; then :
+if ${ac_cv_lib_lzo2_lzo1x_decompress+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7065,7 +7118,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzo2_lzo1x_decompress" >&5
 $as_echo "$ac_cv_lib_lzo2_lzo1x_decompress" >&6; }
-if test "x$ac_cv_lib_lzo2_lzo1x_decompress" = x""yes; then :
+if test "x$ac_cv_lib_lzo2_lzo1x_decompress" = xyes; then :
   zlib="$zlib -DHAVE_LZO1X -llzo2"
 fi
 
@@ -7076,7 +7129,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio" >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
-if test "${ac_cv_lib_aio_io_setup+set}" = set; then :
+if ${ac_cv_lib_aio_io_setup+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7110,7 +7163,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup" >&5
 $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
-if test "x$ac_cv_lib_aio_io_setup" = x""yes; then :
+if test "x$ac_cv_lib_aio_io_setup" = xyes; then :
   system_aio="y"
 else
   system_aio="n"
@@ -7119,7 +7172,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >&5
 $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
-if test "${ac_cv_lib_crypto_MD5+set}" = set; then :
+if ${ac_cv_lib_crypto_MD5+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7153,7 +7206,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" >&5
 $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
-if test "x$ac_cv_lib_crypto_MD5" = x""yes; then :
+if test "x$ac_cv_lib_crypto_MD5" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBCRYPTO 1
 _ACEOF
@@ -7166,7 +7219,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -lext2fs" >&5
 $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
-if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" = set; then :
+if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7200,7 +7253,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2fs_open2" >&5
 $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
-if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = x""yes; then :
+if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = xyes; then :
   libext2fs="y"
 else
   libext2fs="n"
@@ -7209,7 +7262,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffer in -lgcrypt" >&5
 $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" = set; then :
+if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7243,7 +7296,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&5
 $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = x""yes; then :
+if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = xyes; then :
   libgcrypt="y"
 else
   libgcrypt="n"
@@ -7253,7 +7306,7 @@ fi
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
 $as_echo_n "checking for pthread flag... " >&6; }
-if test "${ax_cv_pthread_flags+set}" = set; then :
+if ${ax_cv_pthread_flags+:} false; then :
   $as_echo_n "(cached) " >&6
 else
 
@@ -7317,7 +7370,7 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
-if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
+if ${ac_cv_lib_rt_clock_gettime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7351,7 +7404,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_gettime" >&5
 $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
-if test "x$ac_cv_lib_rt_clock_gettime" = x""yes; then :
+if test "x$ac_cv_lib_rt_clock_gettime" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBRT 1
 _ACEOF
@@ -7362,7 +7415,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
-if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
+if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7396,7 +7449,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_alloc" >&5
 $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
-if test "x$ac_cv_lib_yajl_yajl_alloc" = x""yes; then :
+if test "x$ac_cv_lib_yajl_yajl_alloc" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBYAJL 1
 _ACEOF
@@ -7409,7 +7462,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz" >&5
 $as_echo_n "checking for deflateCopy in -lz... " >&6; }
-if test "${ac_cv_lib_z_deflateCopy+set}" = set; then :
+if ${ac_cv_lib_z_deflateCopy+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7443,7 +7496,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCopy" >&5
 $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
-if test "x$ac_cv_lib_z_deflateCopy" = x""yes; then :
+if test "x$ac_cv_lib_z_deflateCopy" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBZ 1
 _ACEOF
@@ -7456,7 +7509,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -liconv" >&5
 $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
-if test "${ac_cv_lib_iconv_libiconv_open+set}" = set; then :
+if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7490,7 +7543,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libiconv_open" >&5
 $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
-if test "x$ac_cv_lib_iconv_libiconv_open" = x""yes; then :
+if test "x$ac_cv_lib_iconv_libiconv_open" = xyes; then :
   libiconv="y"
 else
   libiconv="n"
@@ -7499,11 +7552,22 @@ fi
 
 
 # Checks for header files.
+ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
+if test "x$ac_cv_type_size_t" = xyes; then :
+
+else
+
+cat >>confdefs.h <<_ACEOF
+#define size_t unsigned int
+_ACEOF
+
+fi
+
 # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
 # for constant arguments.  Useless!
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" >&5
 $as_echo_n "checking for working alloca.h... " >&6; }
-if test "${ac_cv_working_alloca_h+set}" = set; then :
+if ${ac_cv_working_alloca_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7536,7 +7600,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
 $as_echo_n "checking for alloca... " >&6; }
-if test "${ac_cv_func_alloca_works+set}" = set; then :
+if ${ac_cv_func_alloca_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7555,7 +7619,7 @@ else
  #pragma alloca
 #   else
 #    ifndef alloca /* predefined by HP cc +Olibcalls */
-char *alloca ();
+void *alloca (size_t);
 #    endif
 #   endif
 #  endif
@@ -7599,7 +7663,7 @@ $as_echo "#define C_ALLOCA 1" >>confdefs.h
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' needs Cray hooks" >&5
 $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
-if test "${ac_cv_os_cray+set}" = set; then :
+if ${ac_cv_os_cray+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7640,7 +7704,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C alloca" >&5
 $as_echo_n "checking stack direction for C alloca... " >&6; }
-if test "${ac_cv_c_stack_direction+set}" = set; then :
+if ${ac_cv_c_stack_direction+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7711,7 +7775,7 @@ done
 # Checks for typedefs, structures, and compiler characteristics.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that conforms to C99" >&5
 $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
-if test "${ac_cv_header_stdbool_h+set}" = set; then :
+if ${ac_cv_header_stdbool_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7743,7 +7807,7 @@ else
 	char b[false == 0 ? 1 : -1];
 	char c[__bool_true_false_are_defined == 1 ? 1 : -1];
 	char d[(bool) 0.5 == true ? 1 : -1];
-	bool e = &s;
+	/* See body of main program for 'e'.  */
 	char f[(_Bool) 0.0 == false ? 1 : -1];
 	char g[true];
 	char h[sizeof (_Bool)];
@@ -7754,25 +7818,6 @@ else
 	_Bool n[m];
 	char o[sizeof n == m * sizeof n[0] ? 1 : -1];
 	char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
-#	if defined __xlc__ || defined __GNUC__
-	 /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
-	    reported by James Lemley on 2005-10-05; see
-	    http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
-	    This test is not quite right, since xlc is allowed to
-	    reject this program, as the initializer for xlcbug is
-	    not one of the forms that C requires support for.
-	    However, doing the test right would require a runtime
-	    test, and that would make cross-compilation harder.
-	    Let us hope that IBM fixes the xlc bug, and also adds
-	    support for this kind of constant expression.  In the
-	    meantime, this test will reject xlc, which is OK, since
-	    our stdbool.h substitute should suffice.  We also test
-	    this with GCC, where it should work, to detect more
-	    quickly whether someone messes up the test in the
-	    future.  */
-	 char digs[] = "0123456789";
-	 int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
-#	endif
 	/* Catch a bug in an HP-UX C compiler.  See
 	   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
 	   http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
@@ -7784,6 +7829,7 @@ int
 main ()
 {
 
+	bool e = &s;
 	*pq |= q;
 	*pq |= ! q;
 	/* Refer to every declared value, to avoid compiler optimizations.  */
@@ -7804,7 +7850,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h" >&5
 $as_echo "$ac_cv_header_stdbool_h" >&6; }
 ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_default"
-if test "x$ac_cv_type__Bool" = x""yes; then :
+if test "x$ac_cv_type__Bool" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE__BOOL 1
@@ -7821,7 +7867,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types.h" >&5
 $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
-if test "${ac_cv_type_uid_t+set}" = set; then :
+if ${ac_cv_type_uid_t+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7851,7 +7897,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
 $as_echo_n "checking for inline... " >&6; }
-if test "${ac_cv_c_inline+set}" = set; then :
+if ${ac_cv_c_inline+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_inline=no
@@ -7936,7 +7982,7 @@ _ACEOF
 esac
 
 ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_default"
-if test "x$ac_cv_type_mode_t" = x""yes; then :
+if test "x$ac_cv_type_mode_t" = xyes; then :
 
 else
 
@@ -7947,7 +7993,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_default"
-if test "x$ac_cv_type_off_t" = x""yes; then :
+if test "x$ac_cv_type_off_t" = xyes; then :
 
 else
 
@@ -7958,7 +8004,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_default"
-if test "x$ac_cv_type_pid_t" = x""yes; then :
+if test "x$ac_cv_type_pid_t" = xyes; then :
 
 else
 
@@ -7970,7 +8016,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict keyword" >&5
 $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
-if test "${ac_cv_c_restrict+set}" = set; then :
+if ${ac_cv_c_restrict+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_restrict=no
@@ -8015,7 +8061,7 @@ _ACEOF
  esac
 
 ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
-if test "x$ac_cv_type_size_t" = x""yes; then :
+if test "x$ac_cv_type_size_t" = xyes; then :
 
 else
 
@@ -8026,7 +8072,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_includes_default"
-if test "x$ac_cv_type_ssize_t" = x""yes; then :
+if test "x$ac_cv_type_ssize_t" = xyes; then :
 
 else
 
@@ -8037,7 +8083,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_struct_stat_st_blksize" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blksize" = x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blksize" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
@@ -8047,7 +8093,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_struct_stat_st_blocks" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blocks" = x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blocks" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLOCKS 1
@@ -8067,7 +8113,7 @@ fi
 
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_struct_stat_st_rdev" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_rdev" = x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_rdev" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_RDEV 1
@@ -8131,7 +8177,7 @@ _ACEOF
   esac
 
 ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_includes_default"
-if test "x$ac_cv_type_ptrdiff_t" = x""yes; then :
+if test "x$ac_cv_type_ptrdiff_t" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_PTRDIFF_T 1
@@ -8144,7 +8190,7 @@ fi
 # Checks for library functions.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5
 $as_echo_n "checking for error_at_line... " >&6; }
-if test "${ac_cv_lib_error_at_line+set}" = set; then :
+if ${ac_cv_lib_error_at_line+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8180,7 +8226,7 @@ fi
 for ac_header in vfork.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h" "$ac_includes_default"
-if test "x$ac_cv_header_vfork_h" = x""yes; then :
+if test "x$ac_cv_header_vfork_h" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_VFORK_H 1
 _ACEOF
@@ -8204,7 +8250,7 @@ done
 if test "x$ac_cv_func_fork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&5
 $as_echo_n "checking for working fork... " >&6; }
-if test "${ac_cv_func_fork_works+set}" = set; then :
+if ${ac_cv_func_fork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8257,7 +8303,7 @@ ac_cv_func_vfork_works=$ac_cv_func_vfork
 if test "x$ac_cv_func_vfork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >&5
 $as_echo_n "checking for working vfork... " >&6; }
-if test "${ac_cv_func_vfork_works+set}" = set; then :
+if ${ac_cv_func_vfork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8392,7 +8438,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE value needed for large files" >&5
 $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files... " >&6; }
-if test "${ac_cv_sys_largefile_source+set}" = set; then :
+if ${ac_cv_sys_largefile_source+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   while :; do
@@ -8460,7 +8506,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctly handles trailing slash" >&5
 $as_echo_n "checking whether lstat correctly handles trailing slash... " >&6; }
-if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" = set; then :
+if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   rm -f conftest.sym conftest.file
@@ -8522,7 +8568,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h defines makedev" >&5
 $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
-if test "${ac_cv_header_sys_types_h_makedev+set}" = set; then :
+if ${ac_cv_header_sys_types_h_makedev+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8550,7 +8596,7 @@ $as_echo "$ac_cv_header_sys_types_h_makedev" >&6; }
 
 if test $ac_cv_header_sys_types_h_makedev = no; then
 ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_mkdev_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_mkdev_h" = x""yes; then :
+if test "x$ac_cv_header_sys_mkdev_h" = xyes; then :
 
 $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
 
@@ -8560,7 +8606,7 @@ fi
 
   if test $ac_cv_header_sys_mkdev_h = no; then
     ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_header_sys_sysmacros_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_sysmacros_h" = x""yes; then :
+if test "x$ac_cv_header_sys_sysmacros_h" = xyes; then :
 
 $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
 
@@ -8573,7 +8619,7 @@ fi
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = x""yes; then :
+if test "x$ac_cv_header_stdlib_h" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8584,7 +8630,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible malloc" >&5
 $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
-if test "${ac_cv_func_malloc_0_nonnull+set}" = set; then :
+if ${ac_cv_func_malloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8639,7 +8685,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys/time.h may both be included" >&5
 $as_echo_n "checking whether time.h and sys/time.h may both be included... " >&6; }
-if test "${ac_cv_header_time+set}" = set; then :
+if ${ac_cv_header_time+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8714,7 +8760,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&5
 $as_echo_n "checking for working mktime... " >&6; }
-if test "${ac_cv_func_working_mktime+set}" = set; then :
+if ${ac_cv_func_working_mktime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8943,7 +8989,7 @@ fi
 for ac_func in getpagesize
 do :
   ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
-if test "x$ac_cv_func_getpagesize" = x""yes; then :
+if test "x$ac_cv_func_getpagesize" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_GETPAGESIZE 1
 _ACEOF
@@ -8953,7 +8999,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
 $as_echo_n "checking for working mmap... " >&6; }
-if test "${ac_cv_func_mmap_fixed_mapped+set}" = set; then :
+if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -9120,7 +9166,7 @@ rm -f conftest.mmap conftest.txt
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = x""yes; then :
+if test "x$ac_cv_header_stdlib_h" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -9131,7 +9177,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible realloc" >&5
 $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
-if test "${ac_cv_func_realloc_0_nonnull+set}" = set; then :
+if ${ac_cv_func_realloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -9184,13 +9230,17 @@ $as_echo "#define realloc rpl_realloc" >>confdefs.h
 fi
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
 $as_echo_n "checking for working strnlen... " >&6; }
-if test "${ac_cv_func_strnlen_working+set}" = set; then :
+if ${ac_cv_func_strnlen_working+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
-  ac_cv_func_strnlen_working=no
+  # Guess no on AIX systems, yes otherwise.
+		case "$host_os" in
+		  aix*) ac_cv_func_strnlen_working=no;;
+		  *)    ac_cv_func_strnlen_working=yes;;
+		esac
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -9239,7 +9289,7 @@ esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&5
 $as_echo_n "checking for working strtod... " >&6; }
-if test "${ac_cv_func_strtod+set}" = set; then :
+if ${ac_cv_func_strtod+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -9298,14 +9348,14 @@ if test $ac_cv_func_strtod = no; then
 esac
 
 ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
-if test "x$ac_cv_func_pow" = x""yes; then :
+if test "x$ac_cv_func_pow" = xyes; then :
 
 fi
 
 if test $ac_cv_func_pow = no; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
 $as_echo_n "checking for pow in -lm... " >&6; }
-if test "${ac_cv_lib_m_pow+set}" = set; then :
+if ${ac_cv_lib_m_pow+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -9339,7 +9389,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
 $as_echo "$ac_cv_lib_m_pow" >&6; }
-if test "x$ac_cv_lib_m_pow" = x""yes; then :
+if test "x$ac_cv_lib_m_pow" = xyes; then :
   POW_LIB=-lm
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library containing definition of pow" >&5
@@ -9435,10 +9485,21 @@ $as_echo "$as_me: WARNING: cache variable $ac_var contains a newline" >&2;} ;;
      :end' >>confcache
 if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
   if test -w "$cache_file"; then
-    test "x$cache_file" != "x/dev/null" &&
+    if test "x$cache_file" != "x/dev/null"; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_file" >&5
 $as_echo "$as_me: updating cache $cache_file" >&6;}
-    cat confcache >$cache_file
+      if test ! -f "$cache_file" || test -h "$cache_file"; then
+	cat confcache >"$cache_file"
+      else
+        case $cache_file in #(
+        */* | ?:*)
+	  mv -f confcache "$cache_file"$$ &&
+	  mv -f "$cache_file"$$ "$cache_file" ;; #(
+        *)
+	  mv -f confcache "$cache_file" ;;
+	esac
+      fi
+    fi
   else
     { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cache $cache_file" >&5
 $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
@@ -9470,7 +9531,7 @@ LTLIBOBJS=$ac_ltlibobjs
 
 
 
-: ${CONFIG_STATUS=./config.status}
+: "${CONFIG_STATUS=./config.status}"
 ac_write_fail=0
 ac_clean_files_save=$ac_clean_files
 ac_clean_files="$ac_clean_files $CONFIG_STATUS"
@@ -9571,6 +9632,7 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
+as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -9878,7 +9940,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # values after options handling.
 ac_log="
 This file was extended by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
 
   CONFIG_FILES    = $CONFIG_FILES
   CONFIG_HEADERS  = $CONFIG_HEADERS
@@ -9940,7 +10002,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
 ac_cs_version="\\
 Xen Hypervisor config.status 4.2
-configured by $0, generated by GNU Autoconf 2.67,
+configured by $0, generated by GNU Autoconf 2.68,
   with options \\"\$ac_cs_config\\"
 
 Copyright (C) 2010 Free Software Foundation, Inc.
@@ -10064,7 +10126,7 @@ do
     "../config/Tools.mk") CONFIG_FILES="$CONFIG_FILES ../config/Tools.mk" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
-  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5 ;;
+  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
 done
 
@@ -10086,9 +10148,10 @@ fi
 # after its creation but before its name has been assigned to `$tmp'.
 $debug ||
 {
-  tmp=
+  tmp= ac_tmp=
   trap 'exit_status=$?
-  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit_status
+  : "${ac_tmp:=$tmp}"
+  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
 ' 0
   trap 'as_fn_exit 1' 1 2 13 15
 }
@@ -10096,12 +10159,13 @@ $debug ||
 
 {
   tmp=`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
-  test -n "$tmp" && test -d "$tmp"
+  test -d "$tmp"
 }  ||
 {
   tmp=./conf$$-$RANDOM
   (umask 077 && mkdir "$tmp")
 } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO" 5
+ac_tmp=$tmp
 
 # Set up the scripts for CONFIG_FILES section.
 # No need to generate them if there are no CONFIG_FILES.
@@ -10123,7 +10187,7 @@ else
   ac_cs_awk_cr=$ac_cr
 fi
 
-echo 'BEGIN {' >"$tmp/subs1.awk" &&
+echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
 _ACEOF
 
 
@@ -10151,7 +10215,7 @@ done
 rm -f conf$$subs.sh
 
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
-cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
 _ACEOF
 sed -n '
 h
@@ -10199,7 +10263,7 @@ t delim
 rm -f conf$$subs.awk
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 _ACAWK
-cat >>"\$tmp/subs1.awk" <<_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
   for (key in S) S_is_set[key] = 1
   FS = ""
 
@@ -10231,7 +10295,7 @@ if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then
   sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
 else
   cat
-fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
+fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
   || as_fn_error $? "could not setup config files machinery" "$LINENO" 5
 _ACEOF
 
@@ -10265,7 +10329,7 @@ fi # test -n "$CONFIG_FILES"
 # No need to generate them if there are no CONFIG_HEADERS.
 # This happens for instance with `./config.status Makefile'.
 if test -n "$CONFIG_HEADERS"; then
-cat >"$tmp/defines.awk" <<\_ACAWK ||
+cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
 BEGIN {
 _ACEOF
 
@@ -10277,8 +10341,8 @@ _ACEOF
 # handling of long lines.
 ac_delim='%!_!# '
 for ac_last_try in false false :; do
-  ac_t=`sed -n "/$ac_delim/p" confdefs.h`
-  if test -z "$ac_t"; then
+  ac_tt=`sed -n "/$ac_delim/p" confdefs.h`
+  if test -z "$ac_tt"; then
     break
   elif $ac_last_try; then
     as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
@@ -10379,7 +10443,7 @@ do
   esac
   case $ac_mode$ac_tag in
   :[FHL]*:*);;
-  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
+  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
   :[FH]-) ac_tag=-:-;;
   :[FH]*) ac_tag=$ac_tag:$ac_tag.in;;
   esac
@@ -10398,7 +10462,7 @@ do
     for ac_f
     do
       case $ac_f in
-      -) ac_f="$tmp/stdin";;
+      -) ac_f="$ac_tmp/stdin";;
       *) # Look for the file first in the build tree, then in the source tree
 	 # (if the path is not absolute).  The absolute path cannot be DOS-style,
 	 # because $ac_f cannot contain `:'.
@@ -10407,7 +10471,7 @@ do
 	   [\\/$]*) false;;
 	   *) test -f "$srcdir/$ac_f" && ac_f="$srcdir/$ac_f";;
 	   esac ||
-	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
+	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
       esac
       case $ac_f in *\'*) ac_f=`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\''/g"`;; esac
       as_fn_append ac_file_inputs " '$ac_f'"
@@ -10433,8 +10497,8 @@ $as_echo "$as_me: creating $ac_file" >&6;}
     esac
 
     case $ac_tag in
-    *:-:* | *:-) cat >"$tmp/stdin" \
-      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
+    *:-:* | *:-) cat >"$ac_tmp/stdin" \
+      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
     esac
     ;;
   esac
@@ -10564,21 +10628,22 @@ s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
 s&@INSTALL@&$ac_INSTALL&;t t
 $ac_datarootdir_hack
 "
-eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" >$tmp/out \
-  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
+eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.awk" \
+  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5
 
 test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
-  { ac_out=`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"; } &&
-  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' "$tmp/out"`; test -z "$ac_out"; } &&
+  { ac_out=`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_out"; } &&
+  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' \
+      "$ac_tmp/out"`; test -z "$ac_out"; } &&
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&5
 $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&2;}
 
-  rm -f "$tmp/stdin"
+  rm -f "$ac_tmp/stdin"
   case $ac_file in
-  -) cat "$tmp/out" && rm -f "$tmp/out";;
-  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
+  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
+  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
   esac \
   || as_fn_error $? "could not create $ac_file" "$LINENO" 5
  ;;
@@ -10589,20 +10654,20 @@ which seems to be undefined.  Please make sure it is defined" >&2;}
   if test x"$ac_file" != x-; then
     {
       $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
-    } >"$tmp/config.h" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
+    } >"$ac_tmp/config.h" \
       || as_fn_error $? "could not create $ac_file" "$LINENO" 5
-    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
+    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&5
 $as_echo "$as_me: $ac_file is unchanged" >&6;}
     else
       rm -f "$ac_file"
-      mv "$tmp/config.h" "$ac_file" \
+      mv "$ac_tmp/config.h" "$ac_file" \
 	|| as_fn_error $? "could not create $ac_file" "$LINENO" 5
     fi
   else
     $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
       || as_fn_error $? "could not create -" "$LINENO" 5
   fi
  ;;
diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..ddabfef 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -106,6 +106,7 @@ AX_PATH_PROG_OR_FAIL([AS86], [as86])
 AX_PATH_PROG_OR_FAIL([LD86], [ld86])
 AX_PATH_PROG_OR_FAIL([BCC], [bcc])
 AX_PATH_PROG_OR_FAIL([IASL], [iasl])
+AX_PATH_PROG_OR_FAIL([FLEX], [flex])
 AX_CHECK_UUID
 AX_CHECK_CURSES
 PKG_CHECK_MODULES(glib, glib-2.0)
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 18:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 18:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJUPy-0003uG-AP; Sun, 15 Apr 2012 18:43:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SJUPw-0003uB-LJ
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 18:43:21 +0000
Received: from [193.109.254.147:44040] by server-11.bemta-14.messagelabs.com
	id 3A/6C-05858-7C61B8F4; Sun, 15 Apr 2012 18:43:19 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334515395!4685665!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24458 invoked from network); 15 Apr 2012 18:43:15 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 18:43:15 -0000
Received: by wibhm17 with SMTP id hm17so6743634wib.0
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Apr 2012 11:43:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=7BuRHr87m8tOhk9EBnDijl6/YURrWsogP/aXQZ7cbP0=;
	b=hyhAmUrb7OSHnG73zPCn6Ceh9gwStA5mmpLiTFzJcOQscdkTT9cy6iqgjbDToqZvd4
	4kt/ktqfevZNbn3ZM77ncLJIxhqgFOSBHxd5iUS/HR6Y1zA9PySyzw5Ns8ErOG4Lz7PN
	hng9J6xNsoiM+TiBOiX5AsUkcgTEWS6rjNvVXeVcNFBROgf844C1LVC0QnwCYZeWrok0
	96rFVDc8OoGUAO4KTckVGFcslUOGrm522F9iIwXrxW/Vn+pQzrS3I4EvoY3d/SYqRim+
	3PNTC0ZXWak6mCDC/gwTpKY8HQAeLhqbMpFKe1JLUC4oKkF58Htus23+U0lj/lnwsl//
	wMyA==
Received: by 10.216.132.8 with SMTP id n8mr5036004wei.36.1334515395427;
	Sun, 15 Apr 2012 11:43:15 -0700 (PDT)
Received: from debian (cpc2-cmbg15-2-0-cust282.5-4.cable.virginmedia.com.
	[86.26.13.27])
	by mx.google.com with ESMTPS id l5sm14091147wia.11.2012.04.15.11.43.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 15 Apr 2012 11:43:14 -0700 (PDT)
Received: from xen by debian with local (Exim 4.77)
	(envelope-from <jean.guyader@gmail.com>)
	id 1SJUPo-0007nT-31; Sun, 15 Apr 2012 11:43:12 -0700
From: Jean Guyader <jean.guyader@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sun, 15 Apr 2012 11:43:10 -0700
Message-Id: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Jean Guyader <jean.guyader@gmail.com>
Subject: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl require the command flex to be present.
Verify in the configure script that the flex
command exsits.

Signed-off-by: Jean Guyader <jean.guyader@gmail.com>
---
 tools/configure    |  633 +++++++++++++++++++++++++++++-----------------------
 tools/configure.ac |    1 +
 2 files changed, 350 insertions(+), 284 deletions(-)

diff --git a/tools/configure b/tools/configure
index 86618f5..071adf7 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
 #
 # Report bugs to <xen-devel@lists.xensource.com>.
 #
@@ -91,6 +91,7 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
+as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -216,11 +217,18 @@ IFS=$as_save_IFS
   # We cannot yet assume a decent shell, so we have to provide a
 	# neutralization value for shells without unset; and this also
 	# works around shells that cannot unset nonexistent variables.
+	# Preserve -v and -x to the replacement shell.
 	BASH_ENV=/dev/null
 	ENV=/dev/null
 	(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
 	export CONFIG_SHELL
-	exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
+	case $- in # ((((
+	  *v*x* | *x*v* ) as_opts=-vx ;;
+	  *v* ) as_opts=-v ;;
+	  *x* ) as_opts=-x ;;
+	  * ) as_opts= ;;
+	esac
+	exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
 fi
 
     if test x$as_have_required = xno; then :
@@ -1164,7 +1172,7 @@ Try \`$0 --help' for more information"
     $as_echo "$as_me: WARNING: you should use --build, --host, --target" >&2
     expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
       $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
-    : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}
+    : "${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}"
     ;;
 
   esac
@@ -1490,7 +1498,7 @@ test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
 Xen Hypervisor configure 4.2
-generated by GNU Autoconf 2.67
+generated by GNU Autoconf 2.68
 
 Copyright (C) 2010 Free Software Foundation, Inc.
 This configure script is free software; the Free Software Foundation
@@ -1536,7 +1544,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
 	ac_retval=1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_compile
@@ -1573,7 +1581,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
     ac_retval=1
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_cpp
@@ -1586,10 +1594,10 @@ fi
 ac_fn_c_check_header_mongrel ()
 {
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  if eval "test \"\${$3+set}\"" = set; then :
+  if eval \${$3+:} false; then :
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 fi
 eval ac_res=\$$3
@@ -1656,7 +1664,7 @@ $as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
 esac
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=\$ac_header_compiler"
@@ -1665,7 +1673,7 @@ eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
 fi
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_header_mongrel
 
@@ -1706,7 +1714,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
        ac_retval=$ac_status
 fi
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_run
@@ -1720,7 +1728,7 @@ ac_fn_c_check_header_compile ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1738,7 +1746,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_header_compile
 
@@ -1783,11 +1791,65 @@ fi
   # interfere with the next link command; also delete a directory that is
   # left behind by Apple's compiler.  We do this before executing the actions.
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_link
 
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# -------------------------------------------
+# Tests whether TYPE exists after having included INCLUDES, setting cache
+# variable VAR accordingly.
+ac_fn_c_check_type ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval \${$3+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  eval "$3=no"
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof ($2))
+	 return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof (($2)))
+	    return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+
+else
+  eval "$3=yes"
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+eval ac_res=\$$3
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+
+} # ac_fn_c_check_type
+
 # ac_fn_c_check_func LINENO FUNC VAR
 # ----------------------------------
 # Tests whether FUNC exists, setting the cache variable VAR accordingly
@@ -1796,7 +1858,7 @@ ac_fn_c_check_func ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1851,64 +1913,10 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_func
 
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# -------------------------------------------
-# Tests whether TYPE exists after having included INCLUDES, setting cache
-# variable VAR accordingly.
-ac_fn_c_check_type ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
-  $as_echo_n "(cached) " >&6
-else
-  eval "$3=no"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof ($2))
-	 return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof (($2)))
-	    return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  eval "$3=yes"
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-eval ac_res=\$$3
-	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
-
-} # ac_fn_c_check_type
-
 # ac_fn_c_find_intX_t LINENO BITS VAR
 # -----------------------------------
 # Finds a signed integer type with width BITS, setting cache variable VAR
@@ -1918,7 +1926,7 @@ ac_fn_c_find_intX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
 $as_echo_n "checking for int$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -1979,7 +1987,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_find_intX_t
 
@@ -1992,7 +2000,7 @@ ac_fn_c_check_member ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
 $as_echo_n "checking for $2.$3... " >&6; }
-if eval "test \"\${$4+set}\"" = set; then :
+if eval \${$4+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -2036,7 +2044,7 @@ fi
 eval ac_res=\$$4
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_member
 
@@ -2049,7 +2057,7 @@ ac_fn_c_find_uintX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
 $as_echo_n "checking for uint$2_t... " >&6; }
-if eval "test \"\${$3+set}\"" = set; then :
+if eval \${$3+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -2089,7 +2097,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_find_uintX_t
 cat >config.log <<_ACEOF
@@ -2097,7 +2105,7 @@ This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
 It was created by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
 
   $ $0 $@
 
@@ -2355,7 +2363,7 @@ $as_echo "$as_me: loading site script $ac_site_file" >&6;}
       || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "failed to load site script $ac_site_file
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
   fi
 done
 
@@ -2508,7 +2516,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2548,7 +2556,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2601,7 +2609,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2641,7 +2649,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2700,7 +2708,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2744,7 +2752,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2799,7 +2807,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -2914,7 +2922,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error 77 "C compiler cannot create executables
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
@@ -2957,7 +2965,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of executables: cannot compile and link
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest conftest$ac_cv_exeext
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
@@ -3016,7 +3024,7 @@ $as_echo "$ac_try_echo"; } >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
     fi
   fi
 fi
@@ -3027,7 +3035,7 @@ rm -f conftest.$ac_ext conftest$ac_cv_exeext conftest.out
 ac_clean_files=$ac_clean_files_save
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
 $as_echo_n "checking for suffix of object files... " >&6; }
-if test "${ac_cv_objext+set}" = set; then :
+if ${ac_cv_objext+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3068,7 +3076,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of object files: cannot compile
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 rm -f conftest.$ac_cv_objext conftest.$ac_ext
 fi
@@ -3078,7 +3086,7 @@ OBJEXT=$ac_cv_objext
 ac_objext=$OBJEXT
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if test "${ac_cv_c_compiler_gnu+set}" = set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3115,7 +3123,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" = set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -3193,7 +3201,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" = set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -3301,7 +3309,7 @@ if test -n "$CPP" && test -d "$CPP"; then
   CPP=
 fi
 if test -z "$CPP"; then
-  if test "${ac_cv_prog_CPP+set}" = set; then :
+  if ${ac_cv_prog_CPP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
       # Double quotes because CPP needs to be expanded
@@ -3417,7 +3425,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 fi
 
 ac_ext=c
@@ -3429,7 +3437,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles long lines and -e" >&5
 $as_echo_n "checking for grep that handles long lines and -e... " >&6; }
-if test "${ac_cv_path_GREP+set}" = set; then :
+if ${ac_cv_path_GREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -z "$GREP"; then
@@ -3492,7 +3500,7 @@ $as_echo "$ac_cv_path_GREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
 $as_echo_n "checking for egrep... " >&6; }
-if test "${ac_cv_path_EGREP+set}" = set; then :
+if ${ac_cv_path_EGREP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
@@ -3559,7 +3567,7 @@ $as_echo "$ac_cv_path_EGREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header files" >&5
 $as_echo_n "checking for ANSI C header files... " >&6; }
-if test "${ac_cv_header_stdc+set}" = set; then :
+if ${ac_cv_header_stdc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3688,7 +3696,7 @@ done
 
 
   ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_minix_config_h" "$ac_includes_default"
-if test "x$ac_cv_header_minix_config_h" = x""yes; then :
+if test "x$ac_cv_header_minix_config_h" = xyes; then :
   MINIX=yes
 else
   MINIX=
@@ -3710,7 +3718,7 @@ $as_echo "#define _MINIX 1" >>confdefs.h
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe to define __EXTENSIONS__" >&5
 $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&6; }
-if test "${ac_cv_safe_to_define___extensions__+set}" = set; then :
+if ${ac_cv_safe_to_define___extensions__+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3753,7 +3761,7 @@ $SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
 $as_echo_n "checking build system type... " >&6; }
-if test "${ac_cv_build+set}" = set; then :
+if ${ac_cv_build+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_build_alias=$build_alias
@@ -3769,7 +3777,7 @@ fi
 $as_echo "$ac_cv_build" >&6; }
 case $ac_cv_build in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
 esac
 build=$ac_cv_build
 ac_save_IFS=$IFS; IFS='-'
@@ -3787,7 +3795,7 @@ case $build_os in *\ *) build_os=`echo "$build_os" | sed 's/ /-/g'`;; esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
 $as_echo_n "checking host system type... " >&6; }
-if test "${ac_cv_host+set}" = set; then :
+if ${ac_cv_host+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "x$host_alias" = x; then
@@ -3802,7 +3810,7 @@ fi
 $as_echo "$ac_cv_host" >&6; }
 case $ac_cv_host in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
+*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
 esac
 host=$ac_cv_host
 ac_save_IFS=$IFS; IFS='-'
@@ -4196,7 +4204,7 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
-if test "${ac_cv_path_SED+set}" = set; then :
+if ${ac_cv_path_SED+:} false; then :
   $as_echo_n "(cached) " >&6
 else
             ac_script=s/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/
@@ -4273,7 +4281,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4313,7 +4321,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4366,7 +4374,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4406,7 +4414,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4465,7 +4473,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_CC+set}" = set; then :
+if ${ac_cv_prog_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4509,7 +4517,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_CC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4564,7 +4572,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -4593,7 +4601,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if test "${ac_cv_c_compiler_gnu+set}" = set; then :
+if ${ac_cv_c_compiler_gnu+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -4630,7 +4638,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if test "${ac_cv_prog_cc_g+set}" = set; then :
+if ${ac_cv_prog_cc_g+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -4708,7 +4716,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if test "${ac_cv_prog_cc_c89+set}" = set; then :
+if ${ac_cv_prog_cc_c89+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -4818,7 +4826,7 @@ fi
 $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
 set x ${MAKE-make}
 ac_make=`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
-if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" = set; then :
+if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat >conftest.make <<\_ACEOF
@@ -4862,7 +4870,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible install" >&5
 $as_echo_n "checking for a BSD-compatible install... " >&6; }
 if test -z "$INSTALL"; then
-if test "${ac_cv_path_install+set}" = set; then :
+if ${ac_cv_path_install+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -4942,7 +4950,7 @@ test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 set dummy perl; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PERL+set}" = set; then :
+if ${ac_cv_path_PERL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PERL in
@@ -4989,7 +4997,7 @@ if test "x$xapi" = "xy"; then :
 set dummy curl-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_CURL+set}" = set; then :
+if ${ac_cv_path_CURL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $CURL in
@@ -5034,7 +5042,7 @@ fi
 set dummy xml2-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XML+set}" = set; then :
+if ${ac_cv_path_XML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XML in
@@ -5085,7 +5093,7 @@ if test "x$ocamltools" = "xy"; then :
 set dummy ${ac_tool_prefix}ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLC+set}" = set; then :
+if ${ac_cv_prog_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLC"; then
@@ -5125,7 +5133,7 @@ if test -z "$ac_cv_prog_OCAMLC"; then
 set dummy ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLC"; then
@@ -5196,7 +5204,7 @@ $as_echo "OCaml library path is $OCAMLLIB" >&6; }
 set dummy ${ac_tool_prefix}ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPT+set}" = set; then :
+if ${ac_cv_prog_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPT"; then
@@ -5236,7 +5244,7 @@ if test -z "$ac_cv_prog_OCAMLOPT"; then
 set dummy ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPT"; then
@@ -5306,7 +5314,7 @@ $as_echo "versions differs from ocamlc; ocamlopt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLCDOTOPT+set}" = set; then :
+if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLCDOTOPT"; then
@@ -5346,7 +5354,7 @@ if test -z "$ac_cv_prog_OCAMLCDOTOPT"; then
 set dummy ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLCDOTOPT"; then
@@ -5410,7 +5418,7 @@ $as_echo "versions differs from ocamlc; ocamlc.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" = set; then :
+if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPTDOTOPT"; then
@@ -5450,7 +5458,7 @@ if test -z "$ac_cv_prog_OCAMLOPTDOTOPT"; then
 set dummy ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
@@ -5519,7 +5527,7 @@ $as_echo "version differs from ocamlc; ocamlopt.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAML+set}" = set; then :
+if ${ac_cv_prog_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAML"; then
@@ -5559,7 +5567,7 @@ if test -z "$ac_cv_prog_OCAML"; then
 set dummy ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAML+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAML"; then
@@ -5613,7 +5621,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDEP+set}" = set; then :
+if ${ac_cv_prog_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDEP"; then
@@ -5653,7 +5661,7 @@ if test -z "$ac_cv_prog_OCAMLDEP"; then
 set dummy ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDEP"; then
@@ -5707,7 +5715,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKTOP+set}" = set; then :
+if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKTOP"; then
@@ -5747,7 +5755,7 @@ if test -z "$ac_cv_prog_OCAMLMKTOP"; then
 set dummy ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKTOP"; then
@@ -5801,7 +5809,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLMKLIB+set}" = set; then :
+if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKLIB"; then
@@ -5841,7 +5849,7 @@ if test -z "$ac_cv_prog_OCAMLMKLIB"; then
 set dummy ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKLIB"; then
@@ -5895,7 +5903,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLDOC+set}" = set; then :
+if ${ac_cv_prog_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDOC"; then
@@ -5935,7 +5943,7 @@ if test -z "$ac_cv_prog_OCAMLDOC"; then
 set dummy ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDOC"; then
@@ -5989,7 +5997,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_OCAMLBUILD+set}" = set; then :
+if ${ac_cv_prog_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLBUILD"; then
@@ -6029,7 +6037,7 @@ if test -z "$ac_cv_prog_OCAMLBUILD"; then
 set dummy ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" = set; then :
+if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLBUILD"; then
@@ -6092,7 +6100,7 @@ fi
 set dummy bash; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BASH+set}" = set; then :
+if ${ac_cv_path_BASH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $BASH in
@@ -6149,7 +6157,7 @@ fi
 set dummy $PYTHON; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PYTHONPATH+set}" = set; then :
+if ${ac_cv_path_PYTHONPATH+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PYTHONPATH in
@@ -6225,7 +6233,7 @@ LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
     print distutils.sysconfig.get_config_var("LDFLAGS")'`"
 
 ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h" "$ac_includes_default"
-if test "x$ac_cv_header_Python_h" = x""yes; then :
+if test "x$ac_cv_header_Python_h" = xyes; then :
 
 else
   as_fn_error $? "Unable to find Python development headers" "$LINENO" 5
@@ -6235,7 +6243,7 @@ fi
 as_ac_Lib=`$as_echo "ac_cv_lib_python$ac_python_version''_PyArg_ParseTuple" | $as_tr_sh`
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PyArg_ParseTuple in -lpython$ac_python_version" >&5
 $as_echo_n "checking for PyArg_ParseTuple in -lpython$ac_python_version... " >&6; }
-if eval "test \"\${$as_ac_Lib+set}\"" = set; then :
+if eval \${$as_ac_Lib+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6290,7 +6298,7 @@ fi
 set dummy xgettext; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_XGETTEXT+set}" = set; then :
+if ${ac_cv_path_XGETTEXT+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $XGETTEXT in
@@ -6335,7 +6343,7 @@ fi
 set dummy as86; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_AS86+set}" = set; then :
+if ${ac_cv_path_AS86+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $AS86 in
@@ -6380,7 +6388,7 @@ fi
 set dummy ld86; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_LD86+set}" = set; then :
+if ${ac_cv_path_LD86+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $LD86 in
@@ -6425,7 +6433,7 @@ fi
 set dummy bcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BCC+set}" = set; then :
+if ${ac_cv_path_BCC+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $BCC in
@@ -6470,7 +6478,7 @@ fi
 set dummy iasl; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_IASL+set}" = set; then :
+if ${ac_cv_path_IASL+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $IASL in
@@ -6511,13 +6519,58 @@ if test x"${IASL}" == x"no"
 then
     as_fn_error $? "Unable to find iasl, please install iasl" "$LINENO" 5
 fi
+# Extract the first word of "flex", so it can be a program name with args.
+set dummy flex; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_FLEX+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  case $FLEX in
+  [\\/]* | ?:[\\/]*)
+  ac_cv_path_FLEX="$FLEX" # Let the user override the test with a path.
+  ;;
+  *)
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+    for ac_exec_ext in '' $ac_executable_extensions; do
+  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
+    ac_cv_path_FLEX="$as_dir/$ac_word$ac_exec_ext"
+    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+  test -z "$ac_cv_path_FLEX" && ac_cv_path_FLEX="no"
+  ;;
+esac
+fi
+FLEX=$ac_cv_path_FLEX
+if test -n "$FLEX"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $FLEX" >&5
+$as_echo "$FLEX" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+if test x"${FLEX}" == x"no"
+then
+    as_fn_error $? "Unable to find flex, please install flex" "$LINENO" 5
+fi
 
 ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_uuid_h" = x""yes; then :
+if test "x$ac_cv_header_uuid_uuid_h" = xyes; then :
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
-if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
+if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6551,7 +6604,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_clear" >&5
 $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
-if test "x$ac_cv_lib_uuid_uuid_clear" = x""yes; then :
+if test "x$ac_cv_lib_uuid_uuid_clear" = xyes; then :
   libuuid="y"
 fi
 
@@ -6560,7 +6613,7 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_h" = x""yes; then :
+if test "x$ac_cv_header_uuid_h" = xyes; then :
   libuuid="y"
 fi
 
@@ -6573,11 +6626,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h" "$ac_includes_default"
-if test "x$ac_cv_header_curses_h" = x""yes; then :
+if test "x$ac_cv_header_curses_h" = xyes; then :
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcurses" >&5
 $as_echo_n "checking for clear in -lcurses... " >&6; }
-if test "${ac_cv_lib_curses_clear+set}" = set; then :
+if ${ac_cv_lib_curses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6611,7 +6664,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear" >&5
 $as_echo "$ac_cv_lib_curses_clear" >&6; }
-if test "x$ac_cv_lib_curses_clear" = x""yes; then :
+if test "x$ac_cv_lib_curses_clear" = xyes; then :
   curses="y"
 else
   curses="n"
@@ -6624,11 +6677,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses_h" "$ac_includes_default"
-if test "x$ac_cv_header_ncurses_h" = x""yes; then :
+if test "x$ac_cv_header_ncurses_h" = xyes; then :
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncurses" >&5
 $as_echo_n "checking for clear in -lncurses... " >&6; }
-if test "${ac_cv_lib_ncurses_clear+set}" = set; then :
+if ${ac_cv_lib_ncurses_clear+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6662,7 +6715,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clear" >&5
 $as_echo "$ac_cv_lib_ncurses_clear" >&6; }
-if test "x$ac_cv_lib_ncurses_clear" = x""yes; then :
+if test "x$ac_cv_lib_ncurses_clear" = xyes; then :
   ncurses="y"
 else
   ncurses="n"
@@ -6709,7 +6762,7 @@ if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
 set dummy ${ac_tool_prefix}pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_PKG_CONFIG+set}" = set; then :
+if ${ac_cv_path_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $PKG_CONFIG in
@@ -6752,7 +6805,7 @@ if test -z "$ac_cv_path_PKG_CONFIG"; then
 set dummy pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" = set; then :
+if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   case $ac_pt_PKG_CONFIG in
@@ -6897,7 +6950,7 @@ and glib_LIBS to avoid the need to call pkg-config.
 See the pkg-config man page for more details.
 
 To get pkg-config, see <http://pkg-config.freedesktop.org/>.
-See \`config.log' for more details" "$LINENO" 5 ; }
+See \`config.log' for more details" "$LINENO" 5; }
 else
 	glib_CFLAGS=$pkg_cv_glib_CFLAGS
 	glib_LIBS=$pkg_cv_glib_LIBS
@@ -6933,11 +6986,11 @@ fi
 
 # Checks for libraries.
 ac_fn_c_check_header_mongrel "$LINENO" "bzlib.h" "ac_cv_header_bzlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_bzlib_h" = x""yes; then :
+if test "x$ac_cv_header_bzlib_h" = xyes; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for BZ2_bzDecompressInit in -lbz2" >&5
 $as_echo_n "checking for BZ2_bzDecompressInit in -lbz2... " >&6; }
-if test "${ac_cv_lib_bz2_BZ2_bzDecompressInit+set}" = set; then :
+if ${ac_cv_lib_bz2_BZ2_bzDecompressInit+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6971,7 +7024,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_bz2_BZ2_bzDecompressInit" >&5
 $as_echo "$ac_cv_lib_bz2_BZ2_bzDecompressInit" >&6; }
-if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" = x""yes; then :
+if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" = xyes; then :
   zlib="$zlib -DHAVE_BZLIB -lbz2"
 fi
 
@@ -6980,11 +7033,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "lzma.h" "ac_cv_header_lzma_h" "$ac_includes_default"
-if test "x$ac_cv_header_lzma_h" = x""yes; then :
+if test "x$ac_cv_header_lzma_h" = xyes; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzma_stream_decoder in -llzma" >&5
 $as_echo_n "checking for lzma_stream_decoder in -llzma... " >&6; }
-if test "${ac_cv_lib_lzma_lzma_stream_decoder+set}" = set; then :
+if ${ac_cv_lib_lzma_lzma_stream_decoder+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7018,7 +7071,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzma_lzma_stream_decoder" >&5
 $as_echo "$ac_cv_lib_lzma_lzma_stream_decoder" >&6; }
-if test "x$ac_cv_lib_lzma_lzma_stream_decoder" = x""yes; then :
+if test "x$ac_cv_lib_lzma_lzma_stream_decoder" = xyes; then :
   zlib="$zlib -DHAVE_LZMA -llzma"
 fi
 
@@ -7027,11 +7080,11 @@ fi
 
 
 ac_fn_c_check_header_mongrel "$LINENO" "lzo/lzo1x.h" "ac_cv_header_lzo_lzo1x_h" "$ac_includes_default"
-if test "x$ac_cv_header_lzo_lzo1x_h" = x""yes; then :
+if test "x$ac_cv_header_lzo_lzo1x_h" = xyes; then :
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzo1x_decompress in -llzo2" >&5
 $as_echo_n "checking for lzo1x_decompress in -llzo2... " >&6; }
-if test "${ac_cv_lib_lzo2_lzo1x_decompress+set}" = set; then :
+if ${ac_cv_lib_lzo2_lzo1x_decompress+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7065,7 +7118,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzo2_lzo1x_decompress" >&5
 $as_echo "$ac_cv_lib_lzo2_lzo1x_decompress" >&6; }
-if test "x$ac_cv_lib_lzo2_lzo1x_decompress" = x""yes; then :
+if test "x$ac_cv_lib_lzo2_lzo1x_decompress" = xyes; then :
   zlib="$zlib -DHAVE_LZO1X -llzo2"
 fi
 
@@ -7076,7 +7129,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio" >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
-if test "${ac_cv_lib_aio_io_setup+set}" = set; then :
+if ${ac_cv_lib_aio_io_setup+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7110,7 +7163,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup" >&5
 $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
-if test "x$ac_cv_lib_aio_io_setup" = x""yes; then :
+if test "x$ac_cv_lib_aio_io_setup" = xyes; then :
   system_aio="y"
 else
   system_aio="n"
@@ -7119,7 +7172,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >&5
 $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
-if test "${ac_cv_lib_crypto_MD5+set}" = set; then :
+if ${ac_cv_lib_crypto_MD5+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7153,7 +7206,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" >&5
 $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
-if test "x$ac_cv_lib_crypto_MD5" = x""yes; then :
+if test "x$ac_cv_lib_crypto_MD5" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBCRYPTO 1
 _ACEOF
@@ -7166,7 +7219,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -lext2fs" >&5
 $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
-if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" = set; then :
+if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7200,7 +7253,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2fs_open2" >&5
 $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
-if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = x""yes; then :
+if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = xyes; then :
   libext2fs="y"
 else
   libext2fs="n"
@@ -7209,7 +7262,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffer in -lgcrypt" >&5
 $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" = set; then :
+if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7243,7 +7296,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&5
 $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = x""yes; then :
+if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = xyes; then :
   libgcrypt="y"
 else
   libgcrypt="n"
@@ -7253,7 +7306,7 @@ fi
 
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
 $as_echo_n "checking for pthread flag... " >&6; }
-if test "${ax_cv_pthread_flags+set}" = set; then :
+if ${ax_cv_pthread_flags+:} false; then :
   $as_echo_n "(cached) " >&6
 else
 
@@ -7317,7 +7370,7 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
-if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
+if ${ac_cv_lib_rt_clock_gettime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7351,7 +7404,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_gettime" >&5
 $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
-if test "x$ac_cv_lib_rt_clock_gettime" = x""yes; then :
+if test "x$ac_cv_lib_rt_clock_gettime" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBRT 1
 _ACEOF
@@ -7362,7 +7415,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
-if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
+if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7396,7 +7449,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_alloc" >&5
 $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
-if test "x$ac_cv_lib_yajl_yajl_alloc" = x""yes; then :
+if test "x$ac_cv_lib_yajl_yajl_alloc" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBYAJL 1
 _ACEOF
@@ -7409,7 +7462,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz" >&5
 $as_echo_n "checking for deflateCopy in -lz... " >&6; }
-if test "${ac_cv_lib_z_deflateCopy+set}" = set; then :
+if ${ac_cv_lib_z_deflateCopy+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7443,7 +7496,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCopy" >&5
 $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
-if test "x$ac_cv_lib_z_deflateCopy" = x""yes; then :
+if test "x$ac_cv_lib_z_deflateCopy" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBZ 1
 _ACEOF
@@ -7456,7 +7509,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -liconv" >&5
 $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
-if test "${ac_cv_lib_iconv_libiconv_open+set}" = set; then :
+if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7490,7 +7543,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libiconv_open" >&5
 $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
-if test "x$ac_cv_lib_iconv_libiconv_open" = x""yes; then :
+if test "x$ac_cv_lib_iconv_libiconv_open" = xyes; then :
   libiconv="y"
 else
   libiconv="n"
@@ -7499,11 +7552,22 @@ fi
 
 
 # Checks for header files.
+ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
+if test "x$ac_cv_type_size_t" = xyes; then :
+
+else
+
+cat >>confdefs.h <<_ACEOF
+#define size_t unsigned int
+_ACEOF
+
+fi
+
 # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
 # for constant arguments.  Useless!
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" >&5
 $as_echo_n "checking for working alloca.h... " >&6; }
-if test "${ac_cv_working_alloca_h+set}" = set; then :
+if ${ac_cv_working_alloca_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7536,7 +7600,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
 $as_echo_n "checking for alloca... " >&6; }
-if test "${ac_cv_func_alloca_works+set}" = set; then :
+if ${ac_cv_func_alloca_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7555,7 +7619,7 @@ else
  #pragma alloca
 #   else
 #    ifndef alloca /* predefined by HP cc +Olibcalls */
-char *alloca ();
+void *alloca (size_t);
 #    endif
 #   endif
 #  endif
@@ -7599,7 +7663,7 @@ $as_echo "#define C_ALLOCA 1" >>confdefs.h
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' needs Cray hooks" >&5
 $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
-if test "${ac_cv_os_cray+set}" = set; then :
+if ${ac_cv_os_cray+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7640,7 +7704,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C alloca" >&5
 $as_echo_n "checking stack direction for C alloca... " >&6; }
-if test "${ac_cv_c_stack_direction+set}" = set; then :
+if ${ac_cv_c_stack_direction+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7711,7 +7775,7 @@ done
 # Checks for typedefs, structures, and compiler characteristics.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that conforms to C99" >&5
 $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
-if test "${ac_cv_header_stdbool_h+set}" = set; then :
+if ${ac_cv_header_stdbool_h+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7743,7 +7807,7 @@ else
 	char b[false == 0 ? 1 : -1];
 	char c[__bool_true_false_are_defined == 1 ? 1 : -1];
 	char d[(bool) 0.5 == true ? 1 : -1];
-	bool e = &s;
+	/* See body of main program for 'e'.  */
 	char f[(_Bool) 0.0 == false ? 1 : -1];
 	char g[true];
 	char h[sizeof (_Bool)];
@@ -7754,25 +7818,6 @@ else
 	_Bool n[m];
 	char o[sizeof n == m * sizeof n[0] ? 1 : -1];
 	char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
-#	if defined __xlc__ || defined __GNUC__
-	 /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
-	    reported by James Lemley on 2005-10-05; see
-	    http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
-	    This test is not quite right, since xlc is allowed to
-	    reject this program, as the initializer for xlcbug is
-	    not one of the forms that C requires support for.
-	    However, doing the test right would require a runtime
-	    test, and that would make cross-compilation harder.
-	    Let us hope that IBM fixes the xlc bug, and also adds
-	    support for this kind of constant expression.  In the
-	    meantime, this test will reject xlc, which is OK, since
-	    our stdbool.h substitute should suffice.  We also test
-	    this with GCC, where it should work, to detect more
-	    quickly whether someone messes up the test in the
-	    future.  */
-	 char digs[] = "0123456789";
-	 int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
-#	endif
 	/* Catch a bug in an HP-UX C compiler.  See
 	   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
 	   http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
@@ -7784,6 +7829,7 @@ int
 main ()
 {
 
+	bool e = &s;
 	*pq |= q;
 	*pq |= ! q;
 	/* Refer to every declared value, to avoid compiler optimizations.  */
@@ -7804,7 +7850,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h" >&5
 $as_echo "$ac_cv_header_stdbool_h" >&6; }
 ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_default"
-if test "x$ac_cv_type__Bool" = x""yes; then :
+if test "x$ac_cv_type__Bool" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE__BOOL 1
@@ -7821,7 +7867,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types.h" >&5
 $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
-if test "${ac_cv_type_uid_t+set}" = set; then :
+if ${ac_cv_type_uid_t+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7851,7 +7897,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
 $as_echo_n "checking for inline... " >&6; }
-if test "${ac_cv_c_inline+set}" = set; then :
+if ${ac_cv_c_inline+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_inline=no
@@ -7936,7 +7982,7 @@ _ACEOF
 esac
 
 ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_default"
-if test "x$ac_cv_type_mode_t" = x""yes; then :
+if test "x$ac_cv_type_mode_t" = xyes; then :
 
 else
 
@@ -7947,7 +7993,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_default"
-if test "x$ac_cv_type_off_t" = x""yes; then :
+if test "x$ac_cv_type_off_t" = xyes; then :
 
 else
 
@@ -7958,7 +8004,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_default"
-if test "x$ac_cv_type_pid_t" = x""yes; then :
+if test "x$ac_cv_type_pid_t" = xyes; then :
 
 else
 
@@ -7970,7 +8016,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict keyword" >&5
 $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
-if test "${ac_cv_c_restrict+set}" = set; then :
+if ${ac_cv_c_restrict+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_restrict=no
@@ -8015,7 +8061,7 @@ _ACEOF
  esac
 
 ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
-if test "x$ac_cv_type_size_t" = x""yes; then :
+if test "x$ac_cv_type_size_t" = xyes; then :
 
 else
 
@@ -8026,7 +8072,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_includes_default"
-if test "x$ac_cv_type_ssize_t" = x""yes; then :
+if test "x$ac_cv_type_ssize_t" = xyes; then :
 
 else
 
@@ -8037,7 +8083,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_struct_stat_st_blksize" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blksize" = x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blksize" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
@@ -8047,7 +8093,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_struct_stat_st_blocks" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blocks" = x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_blocks" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLOCKS 1
@@ -8067,7 +8113,7 @@ fi
 
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_struct_stat_st_rdev" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_rdev" = x""yes; then :
+if test "x$ac_cv_member_struct_stat_st_rdev" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_RDEV 1
@@ -8131,7 +8177,7 @@ _ACEOF
   esac
 
 ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_includes_default"
-if test "x$ac_cv_type_ptrdiff_t" = x""yes; then :
+if test "x$ac_cv_type_ptrdiff_t" = xyes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_PTRDIFF_T 1
@@ -8144,7 +8190,7 @@ fi
 # Checks for library functions.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5
 $as_echo_n "checking for error_at_line... " >&6; }
-if test "${ac_cv_lib_error_at_line+set}" = set; then :
+if ${ac_cv_lib_error_at_line+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8180,7 +8226,7 @@ fi
 for ac_header in vfork.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h" "$ac_includes_default"
-if test "x$ac_cv_header_vfork_h" = x""yes; then :
+if test "x$ac_cv_header_vfork_h" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_VFORK_H 1
 _ACEOF
@@ -8204,7 +8250,7 @@ done
 if test "x$ac_cv_func_fork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&5
 $as_echo_n "checking for working fork... " >&6; }
-if test "${ac_cv_func_fork_works+set}" = set; then :
+if ${ac_cv_func_fork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8257,7 +8303,7 @@ ac_cv_func_vfork_works=$ac_cv_func_vfork
 if test "x$ac_cv_func_vfork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >&5
 $as_echo_n "checking for working vfork... " >&6; }
-if test "${ac_cv_func_vfork_works+set}" = set; then :
+if ${ac_cv_func_vfork_works+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8392,7 +8438,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE value needed for large files" >&5
 $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files... " >&6; }
-if test "${ac_cv_sys_largefile_source+set}" = set; then :
+if ${ac_cv_sys_largefile_source+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   while :; do
@@ -8460,7 +8506,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctly handles trailing slash" >&5
 $as_echo_n "checking whether lstat correctly handles trailing slash... " >&6; }
-if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" = set; then :
+if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   rm -f conftest.sym conftest.file
@@ -8522,7 +8568,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h defines makedev" >&5
 $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
-if test "${ac_cv_header_sys_types_h_makedev+set}" = set; then :
+if ${ac_cv_header_sys_types_h_makedev+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8550,7 +8596,7 @@ $as_echo "$ac_cv_header_sys_types_h_makedev" >&6; }
 
 if test $ac_cv_header_sys_types_h_makedev = no; then
 ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_mkdev_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_mkdev_h" = x""yes; then :
+if test "x$ac_cv_header_sys_mkdev_h" = xyes; then :
 
 $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
 
@@ -8560,7 +8606,7 @@ fi
 
   if test $ac_cv_header_sys_mkdev_h = no; then
     ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_header_sys_sysmacros_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_sysmacros_h" = x""yes; then :
+if test "x$ac_cv_header_sys_sysmacros_h" = xyes; then :
 
 $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
 
@@ -8573,7 +8619,7 @@ fi
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = x""yes; then :
+if test "x$ac_cv_header_stdlib_h" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8584,7 +8630,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible malloc" >&5
 $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
-if test "${ac_cv_func_malloc_0_nonnull+set}" = set; then :
+if ${ac_cv_func_malloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8639,7 +8685,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys/time.h may both be included" >&5
 $as_echo_n "checking whether time.h and sys/time.h may both be included... " >&6; }
-if test "${ac_cv_header_time+set}" = set; then :
+if ${ac_cv_header_time+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8714,7 +8760,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&5
 $as_echo_n "checking for working mktime... " >&6; }
-if test "${ac_cv_func_working_mktime+set}" = set; then :
+if ${ac_cv_func_working_mktime+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8943,7 +8989,7 @@ fi
 for ac_func in getpagesize
 do :
   ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
-if test "x$ac_cv_func_getpagesize" = x""yes; then :
+if test "x$ac_cv_func_getpagesize" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_GETPAGESIZE 1
 _ACEOF
@@ -8953,7 +8999,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
 $as_echo_n "checking for working mmap... " >&6; }
-if test "${ac_cv_func_mmap_fixed_mapped+set}" = set; then :
+if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -9120,7 +9166,7 @@ rm -f conftest.mmap conftest.txt
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = x""yes; then :
+if test "x$ac_cv_header_stdlib_h" = xyes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -9131,7 +9177,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible realloc" >&5
 $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
-if test "${ac_cv_func_realloc_0_nonnull+set}" = set; then :
+if ${ac_cv_func_realloc_0_nonnull+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -9184,13 +9230,17 @@ $as_echo "#define realloc rpl_realloc" >>confdefs.h
 fi
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
 $as_echo_n "checking for working strnlen... " >&6; }
-if test "${ac_cv_func_strnlen_working+set}" = set; then :
+if ${ac_cv_func_strnlen_working+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
-  ac_cv_func_strnlen_working=no
+  # Guess no on AIX systems, yes otherwise.
+		case "$host_os" in
+		  aix*) ac_cv_func_strnlen_working=no;;
+		  *)    ac_cv_func_strnlen_working=yes;;
+		esac
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -9239,7 +9289,7 @@ esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&5
 $as_echo_n "checking for working strtod... " >&6; }
-if test "${ac_cv_func_strtod+set}" = set; then :
+if ${ac_cv_func_strtod+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -9298,14 +9348,14 @@ if test $ac_cv_func_strtod = no; then
 esac
 
 ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
-if test "x$ac_cv_func_pow" = x""yes; then :
+if test "x$ac_cv_func_pow" = xyes; then :
 
 fi
 
 if test $ac_cv_func_pow = no; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
 $as_echo_n "checking for pow in -lm... " >&6; }
-if test "${ac_cv_lib_m_pow+set}" = set; then :
+if ${ac_cv_lib_m_pow+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -9339,7 +9389,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
 $as_echo "$ac_cv_lib_m_pow" >&6; }
-if test "x$ac_cv_lib_m_pow" = x""yes; then :
+if test "x$ac_cv_lib_m_pow" = xyes; then :
   POW_LIB=-lm
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library containing definition of pow" >&5
@@ -9435,10 +9485,21 @@ $as_echo "$as_me: WARNING: cache variable $ac_var contains a newline" >&2;} ;;
      :end' >>confcache
 if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
   if test -w "$cache_file"; then
-    test "x$cache_file" != "x/dev/null" &&
+    if test "x$cache_file" != "x/dev/null"; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_file" >&5
 $as_echo "$as_me: updating cache $cache_file" >&6;}
-    cat confcache >$cache_file
+      if test ! -f "$cache_file" || test -h "$cache_file"; then
+	cat confcache >"$cache_file"
+      else
+        case $cache_file in #(
+        */* | ?:*)
+	  mv -f confcache "$cache_file"$$ &&
+	  mv -f "$cache_file"$$ "$cache_file" ;; #(
+        *)
+	  mv -f confcache "$cache_file" ;;
+	esac
+      fi
+    fi
   else
     { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cache $cache_file" >&5
 $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
@@ -9470,7 +9531,7 @@ LTLIBOBJS=$ac_ltlibobjs
 
 
 
-: ${CONFIG_STATUS=./config.status}
+: "${CONFIG_STATUS=./config.status}"
 ac_write_fail=0
 ac_clean_files_save=$ac_clean_files
 ac_clean_files="$ac_clean_files $CONFIG_STATUS"
@@ -9571,6 +9632,7 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
+as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -9878,7 +9940,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # values after options handling.
 ac_log="
 This file was extended by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.67.  Invocation command line was
+generated by GNU Autoconf 2.68.  Invocation command line was
 
   CONFIG_FILES    = $CONFIG_FILES
   CONFIG_HEADERS  = $CONFIG_HEADERS
@@ -9940,7 +10002,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
 ac_cs_version="\\
 Xen Hypervisor config.status 4.2
-configured by $0, generated by GNU Autoconf 2.67,
+configured by $0, generated by GNU Autoconf 2.68,
   with options \\"\$ac_cs_config\\"
 
 Copyright (C) 2010 Free Software Foundation, Inc.
@@ -10064,7 +10126,7 @@ do
     "../config/Tools.mk") CONFIG_FILES="$CONFIG_FILES ../config/Tools.mk" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
-  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5 ;;
+  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
 done
 
@@ -10086,9 +10148,10 @@ fi
 # after its creation but before its name has been assigned to `$tmp'.
 $debug ||
 {
-  tmp=
+  tmp= ac_tmp=
   trap 'exit_status=$?
-  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit_status
+  : "${ac_tmp:=$tmp}"
+  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
 ' 0
   trap 'as_fn_exit 1' 1 2 13 15
 }
@@ -10096,12 +10159,13 @@ $debug ||
 
 {
   tmp=`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
-  test -n "$tmp" && test -d "$tmp"
+  test -d "$tmp"
 }  ||
 {
   tmp=./conf$$-$RANDOM
   (umask 077 && mkdir "$tmp")
 } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO" 5
+ac_tmp=$tmp
 
 # Set up the scripts for CONFIG_FILES section.
 # No need to generate them if there are no CONFIG_FILES.
@@ -10123,7 +10187,7 @@ else
   ac_cs_awk_cr=$ac_cr
 fi
 
-echo 'BEGIN {' >"$tmp/subs1.awk" &&
+echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
 _ACEOF
 
 
@@ -10151,7 +10215,7 @@ done
 rm -f conf$$subs.sh
 
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
-cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
 _ACEOF
 sed -n '
 h
@@ -10199,7 +10263,7 @@ t delim
 rm -f conf$$subs.awk
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 _ACAWK
-cat >>"\$tmp/subs1.awk" <<_ACAWK &&
+cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
   for (key in S) S_is_set[key] = 1
   FS = ""
 
@@ -10231,7 +10295,7 @@ if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then
   sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
 else
   cat
-fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
+fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
   || as_fn_error $? "could not setup config files machinery" "$LINENO" 5
 _ACEOF
 
@@ -10265,7 +10329,7 @@ fi # test -n "$CONFIG_FILES"
 # No need to generate them if there are no CONFIG_HEADERS.
 # This happens for instance with `./config.status Makefile'.
 if test -n "$CONFIG_HEADERS"; then
-cat >"$tmp/defines.awk" <<\_ACAWK ||
+cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
 BEGIN {
 _ACEOF
 
@@ -10277,8 +10341,8 @@ _ACEOF
 # handling of long lines.
 ac_delim='%!_!# '
 for ac_last_try in false false :; do
-  ac_t=`sed -n "/$ac_delim/p" confdefs.h`
-  if test -z "$ac_t"; then
+  ac_tt=`sed -n "/$ac_delim/p" confdefs.h`
+  if test -z "$ac_tt"; then
     break
   elif $ac_last_try; then
     as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
@@ -10379,7 +10443,7 @@ do
   esac
   case $ac_mode$ac_tag in
   :[FHL]*:*);;
-  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
+  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
   :[FH]-) ac_tag=-:-;;
   :[FH]*) ac_tag=$ac_tag:$ac_tag.in;;
   esac
@@ -10398,7 +10462,7 @@ do
     for ac_f
     do
       case $ac_f in
-      -) ac_f="$tmp/stdin";;
+      -) ac_f="$ac_tmp/stdin";;
       *) # Look for the file first in the build tree, then in the source tree
 	 # (if the path is not absolute).  The absolute path cannot be DOS-style,
 	 # because $ac_f cannot contain `:'.
@@ -10407,7 +10471,7 @@ do
 	   [\\/$]*) false;;
 	   *) test -f "$srcdir/$ac_f" && ac_f="$srcdir/$ac_f";;
 	   esac ||
-	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
+	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
       esac
       case $ac_f in *\'*) ac_f=`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\''/g"`;; esac
       as_fn_append ac_file_inputs " '$ac_f'"
@@ -10433,8 +10497,8 @@ $as_echo "$as_me: creating $ac_file" >&6;}
     esac
 
     case $ac_tag in
-    *:-:* | *:-) cat >"$tmp/stdin" \
-      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
+    *:-:* | *:-) cat >"$ac_tmp/stdin" \
+      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
     esac
     ;;
   esac
@@ -10564,21 +10628,22 @@ s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
 s&@INSTALL@&$ac_INSTALL&;t t
 $ac_datarootdir_hack
 "
-eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" >$tmp/out \
-  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
+eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.awk" \
+  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5
 
 test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
-  { ac_out=`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"; } &&
-  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' "$tmp/out"`; test -z "$ac_out"; } &&
+  { ac_out=`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_out"; } &&
+  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' \
+      "$ac_tmp/out"`; test -z "$ac_out"; } &&
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&5
 $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&2;}
 
-  rm -f "$tmp/stdin"
+  rm -f "$ac_tmp/stdin"
   case $ac_file in
-  -) cat "$tmp/out" && rm -f "$tmp/out";;
-  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
+  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
+  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
   esac \
   || as_fn_error $? "could not create $ac_file" "$LINENO" 5
  ;;
@@ -10589,20 +10654,20 @@ which seems to be undefined.  Please make sure it is defined" >&2;}
   if test x"$ac_file" != x-; then
     {
       $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
-    } >"$tmp/config.h" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
+    } >"$ac_tmp/config.h" \
       || as_fn_error $? "could not create $ac_file" "$LINENO" 5
-    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
+    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&5
 $as_echo "$as_me: $ac_file is unchanged" >&6;}
     else
       rm -f "$ac_file"
-      mv "$tmp/config.h" "$ac_file" \
+      mv "$ac_tmp/config.h" "$ac_file" \
 	|| as_fn_error $? "could not create $ac_file" "$LINENO" 5
     fi
   else
     $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
+      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
       || as_fn_error $? "could not create -" "$LINENO" 5
   fi
  ;;
diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..ddabfef 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -106,6 +106,7 @@ AX_PATH_PROG_OR_FAIL([AS86], [as86])
 AX_PATH_PROG_OR_FAIL([LD86], [ld86])
 AX_PATH_PROG_OR_FAIL([BCC], [bcc])
 AX_PATH_PROG_OR_FAIL([IASL], [iasl])
+AX_PATH_PROG_OR_FAIL([FLEX], [flex])
 AX_CHECK_UUID
 AX_CHECK_CURSES
 PKG_CHECK_MODULES(glib, glib-2.0)
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 21:03:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 21:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJWaj-0005Um-Ts; Sun, 15 Apr 2012 21:02:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJWai-0005Ue-7l
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 21:02:36 +0000
Received: from [85.158.143.99:14800] by server-2.bemta-4.messagelabs.com id
	B4/C4-17550-B673B8F4; Sun, 15 Apr 2012 21:02:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334523754!23417042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3140 invoked from network); 15 Apr 2012 21:02:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 21:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,426,1330905600"; d="scan'208";a="11943372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 21:02:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 22:02:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJWaf-0003Wv-OK;
	Sun, 15 Apr 2012 21:02:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJWad-0000SY-SD;
	Sun, 15 Apr 2012 22:02:33 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12697-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 22:02:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12697: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12697 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12697/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678
 test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                e1710819abfe86d360f19769ee9d6b1a949f8ea6
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit e1710819abfe86d360f19769ee9d6b1a949f8ea6
Merge: 48b5421... 7ea6411...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Sun Apr 15 08:05:02 2012 +0200

    Merge branch 'perf/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 15 21:03:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Apr 2012 21:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJWaj-0005Um-Ts; Sun, 15 Apr 2012 21:02:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJWai-0005Ue-7l
	for xen-devel@lists.xensource.com; Sun, 15 Apr 2012 21:02:36 +0000
Received: from [85.158.143.99:14800] by server-2.bemta-4.messagelabs.com id
	B4/C4-17550-B673B8F4; Sun, 15 Apr 2012 21:02:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334523754!23417042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3140 invoked from network); 15 Apr 2012 21:02:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Apr 2012 21:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,426,1330905600"; d="scan'208";a="11943372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Apr 2012 21:02:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 15 Apr 2012 22:02:34 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJWaf-0003Wv-OK;
	Sun, 15 Apr 2012 21:02:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJWad-0000SY-SD;
	Sun, 15 Apr 2012 22:02:33 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12697-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Apr 2012 22:02:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12697: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12697 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12697/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678
 test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                e1710819abfe86d360f19769ee9d6b1a949f8ea6
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit e1710819abfe86d360f19769ee9d6b1a949f8ea6
Merge: 48b5421... 7ea6411...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Sun Apr 15 08:05:02 2012 +0200

    Merge branch 'perf/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 01:06:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 01:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJaON-0002KA-A2; Mon, 16 Apr 2012 01:06:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SJaOL-0002K5-Ew
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 01:06:05 +0000
Received: from [85.158.143.35:21859] by server-1.bemta-4.messagelabs.com id
	42/52-20925-C707B8F4; Mon, 16 Apr 2012 01:06:04 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334538360!13369746!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0NDMx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 574 invoked from network); 16 Apr 2012 01:06:01 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-21.messagelabs.com with SMTP;
	16 Apr 2012 01:06:01 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 15 Apr 2012 18:05:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="131240617"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 15 Apr 2012 18:05:59 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 15 Apr 2012 18:05:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Mon, 16 Apr 2012 09:05:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 1/2] Add mcelog support for xen platform
Thread-Index: Ac0bbRNQOwwDTGvoRgyQnQsEo/DLwA==
Date: Mon, 16 Apr 2012 01:05:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335146A62@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/2] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0ee0651756eb6255bc81da8a7b6313bab4b80d1e Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Sun, 15 Apr 2012 22:58:34 +0800
Subject: [PATCH 1/2] Add mcelog support for xen platform

When MCA error occurs, it would be handled by xen hypervisor first,
and then the error information would be sent to dom0 for logging.

This patch gets error information from xen hypervisor and convert
xen format error into linux format mcelog. This logic is basically
self-contained, not much touching other kernel components.

So under xen platform when MCA error occurs, the error information
would be sent to dom0 and converted into native linux mcelog format.
By using tools like mcelog tool users could read specific error information=
,
like what they did under native linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    4 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  201 ++++++++++++++++++++
 include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 555 insertions(+), 3 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..15628d4 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 9424313..f45f923 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
           module will be called xen_acpi_processor  If you do not know wha=
t to choose,
           select M here. If the CPUFREQ drivers are built in, select Y her=
e.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default n
+	help
+	  Allow kernel fetching mce log from xen platform and
+	  converting it into linux mcelog format for mcelog tools
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9adc5be..1d3e763 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..e9f86b8
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,201 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Driver for receiving and transferring machine check error infomation
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Author: Ke, Liping <liping.ke@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <asm/xen/hypercall.h>
+#include <asm/mce.h>
+#include <xen/xen.h>
+
+static struct mc_info g_mi;
+static struct mcinfo_logical_cpu *g_physinfo;
+static uint32_t ncpus;
+
+static DEFINE_SPINLOCK(mcelog_lock);
+
+static void convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	int i;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	if (unlikely(!mic))
+		return;
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+
+	for (i =3D 0; i < ncpus; i++)
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid)
+			break;
+	if (unlikely(i =3D=3D ncpus))
+		return;
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+
+	do {
+		if ((!mic) || (mic->size =3D=3D 0) ||
+		    (mic->type !=3D MC_TYPE_GLOBAL   &&
+		     mic->type !=3D MC_TYPE_BANK     &&
+		     mic->type !=3D MC_TYPE_EXTENDED &&
+		     mic->type !=3D MC_TYPE_RECOVERY))
+			break;
+
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+}
+
+static void mc_queue_handle(uint32_t flags)
+{
+	struct xen_mc mc_op;
+	int ret =3D 0;
+	unsigned long tmp;
+
+	spin_lock_irqsave(&mcelog_lock, tmp);
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
+	do {
+		mc_op.u.mc_fetch.flags =3D flags;
+		ret =3D HYPERVISOR_mca(&mc_op);
+		if (ret || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+			break;
+		else {
+			convert_log(&g_mi);
+			mc_op.u.mc_fetch.flags =3D flags | XEN_MC_ACK;
+			ret =3D HYPERVISOR_mca(&mc_op);
+			if (ret)
+				break;
+		}
+	} while (1);
+
+	spin_unlock_irqrestore(&mcelog_lock, tmp);
+
+	return;
+}
+
+/* virq handler for machine check error info*/
+static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
+{
+	/* urgent mc_info */
+	mc_queue_handle(XEN_MC_URGENT);
+
+	/* nonurgent mc_info */
+	mc_queue_handle(XEN_MC_NONURGENT);
+
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	struct xen_mc mc_op;
+
+	memset(&mc_op, 0, sizeof(struct xen_mc));
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_LOG: Failed to get CPU numbers\n");
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kzalloc(sizeof(struct mcinfo_logical_cpu) * ncpus,
+			     GFP_KERNEL);
+	if (!g_physinfo)
+		return -ENOMEM;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_LOG: Failed to get CPU info\n");
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+				       mce_dom_interrupt, 0, "mce", NULL);
+	if (ret < 0) {
+		printk(KERN_ERR "MCE_LOG: Failed to bind virq\n");
+		kfree(g_physinfo);
+	}
+
+	return ret;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return -ENODEV;
+}
+late_initcall(mcelog_init);
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f2561db
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,336 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Updated by Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/or
+ * sell copies of the Software, and to permit persons to whom the Software=
 is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT	0x1
+/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT		0x2
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK		0x4
+
+/* OUT: All is ok */
+#define XEN_MC_OK		0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED	0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA		0x2
+
+#ifndef __ASSEMBLY__
+/* vIRQ injected to Dom0 */
+#define VIRQ_MCA VIRQ_ARCH_0
+
+/*
+ * mc_info entry types
+ * mca machine check info are recorded in mc_info entries.
+ * when fetch mca info, it can use MC_TYPE_... to distinguish
+ * different mca info.
+ */
+#define MC_TYPE_GLOBAL		0
+#define MC_TYPE_BANK		1
+#define MC_TYPE_EXTENDED	2
+#define MC_TYPE_RECOVERY	3
+
+struct mcinfo_common {
+	uint16_t type; /* structure type */
+	uint16_t size; /* size of this struct in bytes */
+};
+
+#define MC_FLAG_CORRECTABLE	(1 << 0)
+#define MC_FLAG_UNCORRECTABLE	(1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+
+/* contains x86 global mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	uint16_t mc_domid; /* running domain at the time in error */
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains x86 bank mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr; /* bank address */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+struct mcinfo_msr {
+	uint64_t reg; /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/*
+ * Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/*
+ * Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ */
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	uint8_t action_flags;
+	uint8_t action_types;
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_MAXSIZE 768
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t flags;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_MSR_MCGCAP 0
+#define __MC_NMSRS 1
+#define MC_NCAPS 7
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	uint32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	uint32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+/*
+ * Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+	((_mi)->mi_nentries)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+	((struct mcinfo_common *)(_mi)->mi_data)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/*
+ * Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
+				     struct mc_info *mi, uint16_t type)
+{
+	uint32_t i;
+	struct mcinfo_common *mic;
+	bool found =3D 0;
+
+	if (!ret || !mi)
+		return;
+
+	mic =3D x86_mcinfo_first(mi);
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+
+/*
+ * Fetch machine check data from hypervisor.
+ */
+#define XEN_MC_fetch		1
+struct xen_mc_fetch {
+	/*
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
+	 */
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/*
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain	2
+struct xen_mc_notifydomain {
+	/* IN variables */
+	uint16_t mc_domid; /* The unprivileged domain to notify */
+	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
+
+	/* IN/OUT variables */
+	uint32_t flags;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo	3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject	4
+#define MC_MSRINJ_MAXMSRS	8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr; /* target processor id */
+	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE	0x1
+
+#define XEN_MC_mceinject	5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr; /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-for-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-for-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-for-xen-platform.patch"; size=19856;
	creation-date="Mon, 16 Apr 2012 00:42:43 GMT";
	modification-date="Mon, 16 Apr 2012 08:25:54 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZWUwNjUxNzU2ZWI2MjU1YmM4MWRhOGE3YjYzMTNiYWI0YjgwZDFlIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU3VuLCAxNSBBcHIgMjAxMiAyMjo1ODozNCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZm9yIHhlbiBwbGF0Zm9ybQoKV2hlbiBNQ0EgZXJyb3Igb2Nj
dXJzLCBpdCB3b3VsZCBiZSBoYW5kbGVkIGJ5IHhlbiBoeXBlcnZpc29yIGZpcnN0LAphbmQgdGhl
biB0aGUgZXJyb3IgaW5mb3JtYXRpb24gd291bGQgYmUgc2VudCB0byBkb20wIGZvciBsb2dnaW5n
LgoKVGhpcyBwYXRjaCBnZXRzIGVycm9yIGluZm9ybWF0aW9uIGZyb20geGVuIGh5cGVydmlzb3Ig
YW5kIGNvbnZlcnQKeGVuIGZvcm1hdCBlcnJvciBpbnRvIGxpbnV4IGZvcm1hdCBtY2Vsb2cuIFRo
aXMgbG9naWMgaXMgYmFzaWNhbGx5CnNlbGYtY29udGFpbmVkLCBub3QgbXVjaCB0b3VjaGluZyBv
dGhlciBrZXJuZWwgY29tcG9uZW50cy4KClNvIHVuZGVyIHhlbiBwbGF0Zm9ybSB3aGVuIE1DQSBl
cnJvciBvY2N1cnMsIHRoZSBlcnJvciBpbmZvcm1hdGlvbgp3b3VsZCBiZSBzZW50IHRvIGRvbTAg
YW5kIGNvbnZlcnRlZCBpbnRvIG5hdGl2ZSBsaW51eCBtY2Vsb2cgZm9ybWF0LgpCeSB1c2luZyB0
b29scyBsaWtlIG1jZWxvZyB0b29sIHVzZXJzIGNvdWxkIHJlYWQgc3BlY2lmaWMgZXJyb3IgaW5m
b3JtYXRpb24sCmxpa2Ugd2hhdCB0aGV5IGRpZCB1bmRlciBuYXRpdmUgbGludXguCgpTaWduZWQt
b2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1i
eTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcs
IFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkg
Rml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogYXJjaC94
ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIHwgICAgOCArCiBhcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMgICAgICAgICAgICAgfCAgICA0ICstCiBkcml2ZXJzL3hlbi9LY29uZmlnICAgICAg
ICAgICAgICAgICAgfCAgICA4ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgICAg
ICB8ICAgIDEgKwogZHJpdmVycy94ZW4vbWNlbG9nLmMgICAgICAgICAgICAgICAgIHwgIDIwMSAr
KysrKysrKysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCAgICAg
IHwgIDMzNiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiA2IGZpbGVzIGNoYW5n
ZWQsIDU1NSBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0
IGRyaXZlcnMveGVuL21jZWxvZy5jCiBjcmVhdGUgbW9kZSAxMDA2NDQgaW5jbHVkZS94ZW4vaW50
ZXJmYWNlL3hlbi1tY2EuaAoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9o
eXBlcmNhbGwuaCBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAppbmRleCA1
NzI4ODUyLi41OWMyMjZkIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaHlw
ZXJjYWxsLmgKKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oCkBAIC00
OCw2ICs0OCw3IEBACiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9zY2hlZC5oPgogI2luY2x1ZGUg
PHhlbi9pbnRlcmZhY2UvcGh5c2Rldi5oPgogI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaD4KIAogLyoKICAqIFRoZSBo
eXBlcmNhbGwgYXNtcyBoYXZlIHRvIG1lZXQgc2V2ZXJhbCBjb25zdHJhaW50czoKQEAgLTMwMiw2
ICszMDMsMTMgQEAgSFlQRVJWSVNPUl9zZXRfdGltZXJfb3AodTY0IHRpbWVvdXQpCiB9CiAKIHN0
YXRpYyBpbmxpbmUgaW50CitIWVBFUlZJU09SX21jYShzdHJ1Y3QgeGVuX21jICptY19vcCkKK3sK
KwltY19vcC0+aW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVSRkFDRV9WRVJTSU9OOwor
CXJldHVybiBfaHlwZXJjYWxsMShpbnQsIG1jYSwgbWNfb3ApOworfQorCitzdGF0aWMgaW5saW5l
IGludAogSFlQRVJWSVNPUl9kb20wX29wKHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgKnBsYXRmb3Jt
X29wKQogewogCXBsYXRmb3JtX29wLT5pbnRlcmZhY2VfdmVyc2lvbiA9IFhFTlBGX0lOVEVSRkFD
RV9WRVJTSU9OOwpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIGIvYXJjaC94
ODYveGVuL2VubGlnaHRlbi5jCmluZGV4IDRmNTFiZWIuLjE1NjI4ZDQgMTAwNjQ0Ci0tLSBhL2Fy
Y2gveDg2L3hlbi9lbmxpZ2h0ZW4uYworKysgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKQEAg
LTMyOSw5ICszMjksNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgeGVuX2luaXRfY3B1aWRfbWFzayh2
b2lkKQogCXVuc2lnbmVkIGludCB4c2F2ZV9tYXNrOwogCiAJY3B1aWRfbGVhZjFfZWR4X21hc2sg
PQotCQl+KCgxIDw8IFg4Nl9GRUFUVVJFX01DRSkgIHwgIC8qIGRpc2FibGUgTUNFICovCi0JCSAg
KDEgPDwgWDg2X0ZFQVRVUkVfTUNBKSAgfCAgLyogZGlzYWJsZSBNQ0EgKi8KLQkJICAoMSA8PCBY
ODZfRkVBVFVSRV9NVFJSKSB8ICAvKiBkaXNhYmxlIE1UUlIgKi8KKwkJfigoMSA8PCBYODZfRkVB
VFVSRV9NVFJSKSB8ICAvKiBkaXNhYmxlIE1UUlIgKi8KIAkJICAoMSA8PCBYODZfRkVBVFVSRV9B
Q0MpKTsgICAvKiB0aGVybWFsIG1vbml0b3JpbmcgKi8KIAogCWlmICgheGVuX2luaXRpYWxfZG9t
YWluKCkpCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9LY29uZmlnIGIvZHJpdmVycy94ZW4vS2Nv
bmZpZwppbmRleCA5NDI0MzEzLi5mNDVmOTIzIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9LY29u
ZmlnCisrKyBiL2RyaXZlcnMveGVuL0tjb25maWcKQEAgLTE5NCw0ICsxOTQsMTIgQEAgY29uZmln
IFhFTl9BQ1BJX1BST0NFU1NPUgogICAgICAgICAgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCB4ZW5f
YWNwaV9wcm9jZXNzb3IgIElmIHlvdSBkbyBub3Qga25vdyB3aGF0IHRvIGNob29zZSwKICAgICAg
ICAgICBzZWxlY3QgTSBoZXJlLiBJZiB0aGUgQ1BVRlJFUSBkcml2ZXJzIGFyZSBidWlsdCBpbiwg
c2VsZWN0IFkgaGVyZS4KIAorY29uZmlnIFhFTl9NQ0VfTE9HCisJYm9vbCAiWGVuIHBsYXRmb3Jt
IG1jZWxvZyIKKwlkZXBlbmRzIG9uIFhFTl9ET00wICYmIFg4Nl82NCAmJiBYODZfTUNFCisJZGVm
YXVsdCBuCisJaGVscAorCSAgQWxsb3cga2VybmVsIGZldGNoaW5nIG1jZSBsb2cgZnJvbSB4ZW4g
cGxhdGZvcm0gYW5kCisJICBjb252ZXJ0aW5nIGl0IGludG8gbGludXggbWNlbG9nIGZvcm1hdCBm
b3IgbWNlbG9nIHRvb2xzCisKIGVuZG1lbnUKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggOWFkYzViZS4uMWQzZTc2MyAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTE0LDYgKzE0LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9HTlRERVYpCQkrPSB4ZW4tZ250ZGV2Lm8K
IG9iai0kKENPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DKQkrPSB4ZW4tZ250YWxsb2Mubwogb2Jq
LSQoQ09ORklHX1hFTkZTKQkJCSs9IHhlbmZzLwogb2JqLSQoQ09ORklHX1hFTl9TWVNfSFlQRVJW
SVNPUikJKz0gc3lzLWh5cGVydmlzb3Iubworb2JqLSQoQ09ORklHX1hFTl9NQ0VfTE9HKQkJKz0g
bWNlbG9nLm8KIG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNpLm8KIG9i
ai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hF
TikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIv
ZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ZTlmODZiOAotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC0wLDAg
KzEsMjAxIEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICogRHJpdmVy
IGZvciByZWNlaXZpbmcgYW5kIHRyYW5zZmVycmluZyBtYWNoaW5lIGNoZWNrIGVycm9yIGluZm9t
YXRpb24KKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24KKyAqIEF1
dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKiBBdXRob3I6IEpp
YW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KKyAqIEF1dGhvcjogS2UsIExp
cGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkgaXQgdW5k
ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIK
KyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBvciwgd2hl
biBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwgb3IgaW5j
b3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0IHRvIHRo
ZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBncmFudGVk
LCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0
aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNvZnR3YXJl
IHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0aW9uIHRo
ZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwgZGlzdHJp
YnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwKKyAq
IGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJuaXNoZWQg
dG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKKyAqCisg
KiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBz
aGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBwb3J0aW9u
cyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJ
UyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElNUExJRUQs
IElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB
QklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5PTklORlJJ
TkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlSSUdIVCBI
T0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisgKiBMSUFC
SUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9USEVSV0lT
RSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBUSEUgU09G
VFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRXQVJFLgor
ICovCisKKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9pbml0Lmg+
CisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwuaD4KKyNp
bmNsdWRlIDxsaW51eC9zbGFiLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS94ZW4uaD4KKyNp
bmNsdWRlIDxhc20veGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+Cisj
aW5jbHVkZSA8eGVuL2ludGVyZmFjZS92Y3B1Lmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNh
bGwuaD4KKyNpbmNsdWRlIDxhc20vbWNlLmg+CisjaW5jbHVkZSA8eGVuL3hlbi5oPgorCitzdGF0
aWMgc3RydWN0IG1jX2luZm8gZ19taTsKK3N0YXRpYyBzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1
ICpnX3BoeXNpbmZvOworc3RhdGljIHVpbnQzMl90IG5jcHVzOworCitzdGF0aWMgREVGSU5FX1NQ
SU5MT0NLKG1jZWxvZ19sb2NrKTsKKworc3RhdGljIHZvaWQgY29udmVydF9sb2coc3RydWN0IG1j
X2luZm8gKm1pKQoreworCXN0cnVjdCBtY2luZm9fY29tbW9uICptaWM7CisJc3RydWN0IG1jaW5m
b19nbG9iYWwgKm1jX2dsb2JhbDsKKwlzdHJ1Y3QgbWNpbmZvX2JhbmsgKm1jX2Jhbms7CisJc3Ry
dWN0IG1jZSBtOworCWludCBpOworCisJbWljID0gTlVMTDsKKwl4ODZfbWNpbmZvX2xvb2t1cCgm
bWljLCBtaSwgTUNfVFlQRV9HTE9CQUwpOworCWlmICh1bmxpa2VseSghbWljKSkKKwkJcmV0dXJu
OworCisJbWNlX3NldHVwKCZtKTsKKwltY19nbG9iYWwgPSAoc3RydWN0IG1jaW5mb19nbG9iYWwg
KiltaWM7CisJbS5tY2dzdGF0dXMgPSBtY19nbG9iYWwtPm1jX2dzdGF0dXM7CisJbS5hcGljaWQg
PSBtY19nbG9iYWwtPm1jX2FwaWNpZDsKKworCWZvciAoaSA9IDA7IGkgPCBuY3B1czsgaSsrKQor
CQlpZiAoZ19waHlzaW5mb1tpXS5tY19hcGljaWQgPT0gbS5hcGljaWQpCisJCQlicmVhazsKKwlp
ZiAodW5saWtlbHkoaSA9PSBuY3B1cykpCisJCXJldHVybjsKKworCW0uc29ja2V0aWQgPSBnX3Bo
eXNpbmZvW2ldLm1jX2NoaXBpZDsKKwltLmNwdSA9IG0uZXh0Y3B1ID0gZ19waHlzaW5mb1tpXS5t
Y19jcHVucjsKKwltLmNwdXZlbmRvciA9IChfX3U4KWdfcGh5c2luZm9baV0ubWNfdmVuZG9yOwor
CW0ubWNnY2FwID0gZ19waHlzaW5mb1tpXS5tY19tc3J2YWx1ZXNbX19NQ19NU1JfTUNHQ0FQXS52
YWx1ZTsKKworCW1pYyA9IE5VTEw7CisJeDg2X21jaW5mb19sb29rdXAoJm1pYywgbWksIE1DX1RZ
UEVfQkFOSyk7CisKKwlkbyB7CisJCWlmICgoIW1pYykgfHwgKG1pYy0+c2l6ZSA9PSAwKSB8fAor
CQkgICAgKG1pYy0+dHlwZSAhPSBNQ19UWVBFX0dMT0JBTCAgICYmCisJCSAgICAgbWljLT50eXBl
ICE9IE1DX1RZUEVfQkFOSyAgICAgJiYKKwkJICAgICBtaWMtPnR5cGUgIT0gTUNfVFlQRV9FWFRF
TkRFRCAmJgorCQkgICAgIG1pYy0+dHlwZSAhPSBNQ19UWVBFX1JFQ09WRVJZKSkKKwkJCWJyZWFr
OworCisJCWlmIChtaWMtPnR5cGUgPT0gTUNfVFlQRV9CQU5LKSB7CisJCQltY19iYW5rID0gKHN0
cnVjdCBtY2luZm9fYmFuayAqKW1pYzsKKwkJCW0ubWlzYyA9IG1jX2JhbmstPm1jX21pc2M7CisJ
CQltLnN0YXR1cyA9IG1jX2JhbmstPm1jX3N0YXR1czsKKwkJCW0uYWRkciA9IG1jX2JhbmstPm1j
X2FkZHI7CisJCQltLnRzYyA9IG1jX2JhbmstPm1jX3RzYzsKKwkJCW0uYmFuayA9IG1jX2Jhbmst
Pm1jX2Jhbms7CisJCQltLmZpbmlzaGVkID0gMTsKKwkJCS8qbG9nIHRoaXMgcmVjb3JkKi8KKwkJ
CW1jZV9sb2coJm0pOworCQl9CisJCW1pYyA9IHg4Nl9tY2luZm9fbmV4dChtaWMpOworCX0gd2hp
bGUgKDEpOworfQorCitzdGF0aWMgdm9pZCBtY19xdWV1ZV9oYW5kbGUodWludDMyX3QgZmxhZ3Mp
Cit7CisJc3RydWN0IHhlbl9tYyBtY19vcDsKKwlpbnQgcmV0ID0gMDsKKwl1bnNpZ25lZCBsb25n
IHRtcDsKKworCXNwaW5fbG9ja19pcnFzYXZlKCZtY2Vsb2dfbG9jaywgdG1wKTsKKworCW1jX29w
LmNtZCA9IFhFTl9NQ19mZXRjaDsKKwltY19vcC5pbnRlcmZhY2VfdmVyc2lvbiA9IFhFTl9NQ0Ff
SU5URVJGQUNFX1ZFUlNJT047CisJc2V0X3hlbl9ndWVzdF9oYW5kbGUobWNfb3AudS5tY19mZXRj
aC5kYXRhLCAmZ19taSk7CisJZG8geworCQltY19vcC51Lm1jX2ZldGNoLmZsYWdzID0gZmxhZ3M7
CisJCXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJCWlmIChyZXQgfHwgbWNfb3AudS5t
Y19mZXRjaC5mbGFncyAmIFhFTl9NQ19OT0RBVEEgfHwKKwkJICAgIG1jX29wLnUubWNfZmV0Y2gu
ZmxhZ3MgJiBYRU5fTUNfRkVUQ0hGQUlMRUQpCisJCQlicmVhazsKKwkJZWxzZSB7CisJCQljb252
ZXJ0X2xvZygmZ19taSk7CisJCQltY19vcC51Lm1jX2ZldGNoLmZsYWdzID0gZmxhZ3MgfCBYRU5f
TUNfQUNLOworCQkJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwkJCWlmIChyZXQpCisJ
CQkJYnJlYWs7CisJCX0KKwl9IHdoaWxlICgxKTsKKworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUo
Jm1jZWxvZ19sb2NrLCB0bXApOworCisJcmV0dXJuOworfQorCisvKiB2aXJxIGhhbmRsZXIgZm9y
IG1hY2hpbmUgY2hlY2sgZXJyb3IgaW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgbWNlX2RvbV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCS8qIHVyZ2VudCBtY19pbmZvICov
CisJbWNfcXVldWVfaGFuZGxlKFhFTl9NQ19VUkdFTlQpOworCisJLyogbm9udXJnZW50IG1jX2lu
Zm8gKi8KKwltY19xdWV1ZV9oYW5kbGUoWEVOX01DX05PTlVSR0VOVCk7CisKKwlyZXR1cm4gSVJR
X0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgYmluZF92aXJxX2Zvcl9tY2Uodm9pZCkKK3sKKwlp
bnQgcmV0OworCXN0cnVjdCB4ZW5fbWMgbWNfb3A7CisKKwltZW1zZXQoJm1jX29wLCAwLCBzaXpl
b2Yoc3RydWN0IHhlbl9tYykpOworCisJLyogRmV0Y2ggcGh5c2ljYWwgQ1BVIE51bWJlcnMgKi8K
KwltY19vcC5jbWQgPSBYRU5fTUNfcGh5c2NwdWluZm87CisJbWNfb3AuaW50ZXJmYWNlX3ZlcnNp
b24gPSBYRU5fTUNBX0lOVEVSRkFDRV9WRVJTSU9OOworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG1j
X29wLnUubWNfcGh5c2NwdWluZm8uaW5mbywgZ19waHlzaW5mbyk7CisJcmV0ID0gSFlQRVJWSVNP
Ul9tY2EoJm1jX29wKTsKKwlpZiAocmV0KSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0xPRzog
RmFpbGVkIHRvIGdldCBDUFUgbnVtYmVyc1xuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJLyog
RmV0Y2ggZWFjaCBDUFUgUGh5c2ljYWwgSW5mbyBmb3IgbGF0ZXIgcmVmZXJlbmNlKi8KKwluY3B1
cyA9IG1jX29wLnUubWNfcGh5c2NwdWluZm8ubmNwdXM7CisJZ19waHlzaW5mbyA9IGt6YWxsb2Mo
c2l6ZW9mKHN0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUpICogbmNwdXMsCisJCQkgICAgIEdGUF9L
RVJORUwpOworCWlmICghZ19waHlzaW5mbykKKwkJcmV0dXJuIC1FTk9NRU07CisJc2V0X3hlbl9n
dWVzdF9oYW5kbGUobWNfb3AudS5tY19waHlzY3B1aW5mby5pbmZvLCBnX3BoeXNpbmZvKTsKKwly
ZXQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOworCWlmIChyZXQpIHsKKwkJcHJpbnRrKEtFUk5f
RVJSICJNQ0VfTE9HOiBGYWlsZWQgdG8gZ2V0IENQVSBpbmZvXG4iKTsKKwkJa2ZyZWUoZ19waHlz
aW5mbyk7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0ICA9IGJpbmRfdmlycV90b19pcnFoYW5k
bGVyKFZJUlFfTUNBLCAwLAorCQkJCSAgICAgICBtY2VfZG9tX2ludGVycnVwdCwgMCwgIm1jZSIs
IE5VTEwpOworCWlmIChyZXQgPCAwKSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0xPRzogRmFp
bGVkIHRvIGJpbmQgdmlycVxuIik7CisJCWtmcmVlKGdfcGh5c2luZm8pOworCX0KKworCXJldHVy
biByZXQ7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IG1jZWxvZ19pbml0KHZvaWQpCit7CisJLyog
T25seSBET00wIGlzIHJlc3BvbnNpYmxlIGZvciBNQ0UgbG9nZ2luZyAqLworCWlmICh4ZW5faW5p
dGlhbF9kb21haW4oKSkKKwkJcmV0dXJuIGJpbmRfdmlycV9mb3JfbWNlKCk7CisKKwlyZXR1cm4g
LUVOT0RFVjsKK30KK2xhdGVfaW5pdGNhbGwobWNlbG9nX2luaXQpOwpkaWZmIC0tZ2l0IGEvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4t
bWNhLmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uZjI1NjFkYgotLS0gL2Rl
di9udWxsCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNhLmgKQEAgLTAsMCArMSwz
MzYgQEAKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIGFyY2gteDg2L21jYS5oCisgKiBHdWVz
dCBPUyBtYWNoaW5lIGNoZWNrIGludGVyZmFjZSB0byB4ODYgWGVuLgorICoKKyAqIENvbnRyaWJ1
dGVkIGJ5IEFkdmFuY2VkIE1pY3JvIERldmljZXMsIEluYy4KKyAqIEF1dGhvcjogQ2hyaXN0b3Bo
IEVnZ2VyIDxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT4KKyAqCisgKiBVcGRhdGVkIGJ5IEludGVs
IENvcnBvcmF0aW9uCisgKiBBdXRob3I6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwu
Y29tPgorICoKKyAqIFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdl
LCB0byBhbnkgcGVyc29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc29mdHdhcmUgYW5k
IGFzc29jaWF0ZWQgZG9jdW1lbnRhdGlvbiBmaWxlcyAodGhlICJTb2Z0d2FyZSIpLCB0bworICog
ZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dCByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhv
dXQgbGltaXRhdGlvbiB0aGUKKyAqIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlmeSwgbWVyZ2Us
IHB1Ymxpc2gsIGRpc3RyaWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vcgorICogc2VsbCBjb3BpZXMg
b2YgdGhlIFNvZnR3YXJlLCBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdh
cmUgaXMKKyAqIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0byB0aGUgZm9sbG93aW5nIGNv
bmRpdGlvbnM6CisgKgorICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVy
bWlzc2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vi
c3RhbnRpYWwgcG9ydGlvbnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJ
UyBQUk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNT
IE9SCisgKiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5U
SUVTIE9GIE1FUkNIQU5UQUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFIEFORCBOT05JTkZSSU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9S
UyBPUiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBP
UiBPVEhFUgorICogTElBQklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwg
VE9SVCBPUiBPVEhFUldJU0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNU
SU9OIFdJVEggVEhFIFNPRlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIKKyAqIERFQUxJTkdTIElO
IFRIRSBTT0ZUV0FSRS4KKyAqLworCisjaWZuZGVmIF9fWEVOX1BVQkxJQ19BUkNIX1g4Nl9NQ0Ff
SF9fCisjZGVmaW5lIF9fWEVOX1BVQkxJQ19BUkNIX1g4Nl9NQ0FfSF9fCisKKy8qIEh5cGVyY2Fs
bCAqLworI2RlZmluZSBfX0hZUEVSVklTT1JfbWNhIF9fSFlQRVJWSVNPUl9hcmNoXzAKKworI2Rl
ZmluZSBYRU5fTUNBX0lOVEVSRkFDRV9WRVJTSU9OCTB4MDFlY2MwMDMKKworLyogSU46IERvbTAg
Y2FsbHMgaHlwZXJjYWxsIHRvIHJldHJpZXZlIG5vbnVyZ2VudCBlcnJvciBsb2cgZW50cnkgKi8K
KyNkZWZpbmUgWEVOX01DX05PTlVSR0VOVAkweDEKKy8qIElOOiBEb20wIGNhbGxzIGh5cGVyY2Fs
bCB0byByZXRyaWV2ZSB1cmdlbnQgZXJyb3IgbG9nIGVudHJ5ICovCisjZGVmaW5lIFhFTl9NQ19V
UkdFTlQJCTB4MgorLyogSU46IERvbTAgYWNrbm93bGVkZ2VzIHByZXZpb3NseS1mZXRjaGVkIGVy
cm9yIGxvZyBlbnRyeSAqLworI2RlZmluZSBYRU5fTUNfQUNLCQkweDQKKworLyogT1VUOiBBbGwg
aXMgb2sgKi8KKyNkZWZpbmUgWEVOX01DX09LCQkweDAKKy8qIE9VVDogRG9tYWluIGNvdWxkIG5v
dCBmZXRjaCBkYXRhLiAqLworI2RlZmluZSBYRU5fTUNfRkVUQ0hGQUlMRUQJMHgxCisvKiBPVVQ6
IFRoZXJlIHdhcyBubyBtYWNoaW5lIGNoZWNrIGRhdGEgdG8gZmV0Y2guICovCisjZGVmaW5lIFhF
Tl9NQ19OT0RBVEEJCTB4MgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworLyogdklSUSBpbmplY3Rl
ZCB0byBEb20wICovCisjZGVmaW5lIFZJUlFfTUNBIFZJUlFfQVJDSF8wCisKKy8qCisgKiBtY19p
bmZvIGVudHJ5IHR5cGVzCisgKiBtY2EgbWFjaGluZSBjaGVjayBpbmZvIGFyZSByZWNvcmRlZCBp
biBtY19pbmZvIGVudHJpZXMuCisgKiB3aGVuIGZldGNoIG1jYSBpbmZvLCBpdCBjYW4gdXNlIE1D
X1RZUEVfLi4uIHRvIGRpc3Rpbmd1aXNoCisgKiBkaWZmZXJlbnQgbWNhIGluZm8uCisgKi8KKyNk
ZWZpbmUgTUNfVFlQRV9HTE9CQUwJCTAKKyNkZWZpbmUgTUNfVFlQRV9CQU5LCQkxCisjZGVmaW5l
IE1DX1RZUEVfRVhURU5ERUQJMgorI2RlZmluZSBNQ19UWVBFX1JFQ09WRVJZCTMKKworc3RydWN0
IG1jaW5mb19jb21tb24geworCXVpbnQxNl90IHR5cGU7IC8qIHN0cnVjdHVyZSB0eXBlICovCisJ
dWludDE2X3Qgc2l6ZTsgLyogc2l6ZSBvZiB0aGlzIHN0cnVjdCBpbiBieXRlcyAqLworfTsKKwor
I2RlZmluZSBNQ19GTEFHX0NPUlJFQ1RBQkxFCSgxIDw8IDApCisjZGVmaW5lIE1DX0ZMQUdfVU5D
T1JSRUNUQUJMRQkoMSA8PCAxKQorI2RlZmluZSBNQ19GTEFHX1JFQ09WRVJBQkxFCSgxIDw8IDIp
CisjZGVmaW5lIE1DX0ZMQUdfUE9MTEVECQkoMSA8PCAzKQorI2RlZmluZSBNQ19GTEFHX1JFU0VU
CQkoMSA8PCA0KQorI2RlZmluZSBNQ19GTEFHX0NNQ0kJCSgxIDw8IDUpCisjZGVmaW5lIE1DX0ZM
QUdfTUNFCQkoMSA8PCA2KQorCisvKiBjb250YWlucyB4ODYgZ2xvYmFsIG1jIGluZm9ybWF0aW9u
ICovCitzdHJ1Y3QgbWNpbmZvX2dsb2JhbCB7CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9u
OworCisJdWludDE2X3QgbWNfZG9taWQ7IC8qIHJ1bm5pbmcgZG9tYWluIGF0IHRoZSB0aW1lIGlu
IGVycm9yICovCisJdWludDE2X3QgbWNfdmNwdWlkOyAvKiB2aXJ0dWFsIGNwdSBzY2hlZHVsZWQg
Zm9yIG1jX2RvbWlkICovCisJdWludDMyX3QgbWNfc29ja2V0aWQ7IC8qIHBoeXNpY2FsIHNvY2tl
dCBvZiB0aGUgcGh5c2ljYWwgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVpZDsgLyogcGh5c2lj
YWwgaW1wYWN0ZWQgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7IC8qIGNvcmUg
dGhyZWFkIG9mIHBoeXNpY2FsIGNvcmUgKi8KKwl1aW50MzJfdCBtY19hcGljaWQ7CisJdWludDMy
X3QgbWNfZmxhZ3M7CisJdWludDY0X3QgbWNfZ3N0YXR1czsgLyogZ2xvYmFsIHN0YXR1cyAqLwor
fTsKKworLyogY29udGFpbnMgeDg2IGJhbmsgbWMgaW5mb3JtYXRpb24gKi8KK3N0cnVjdCBtY2lu
Zm9fYmFuayB7CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOworCisJdWludDE2X3QgbWNf
YmFuazsgLyogYmFuayBuciAqLworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBkb21haW4gcmVmZXJl
bmNlZCBieSBtY19hZGRyIGlmIHZhbGlkICovCisJdWludDY0X3QgbWNfc3RhdHVzOyAvKiBiYW5r
IHN0YXR1cyAqLworCXVpbnQ2NF90IG1jX2FkZHI7IC8qIGJhbmsgYWRkcmVzcyAqLworCXVpbnQ2
NF90IG1jX21pc2M7CisJdWludDY0X3QgbWNfY3RybDI7CisJdWludDY0X3QgbWNfdHNjOworfTsK
Kworc3RydWN0IG1jaW5mb19tc3IgeworCXVpbnQ2NF90IHJlZzsgLyogTVNSICovCisJdWludDY0
X3QgdmFsdWU7IC8qIE1TUiB2YWx1ZSAqLworfTsKKworLyogY29udGFpbnMgbWMgaW5mb3JtYXRp
b24gZnJvbSBvdGhlciBvciBhZGRpdGlvbmFsIG1jIE1TUnMgKi8KK3N0cnVjdCBtY2luZm9fZXh0
ZW5kZWQgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNvbW1vbjsKKwl1aW50MzJfdCBtY19tc3Jz
OyAvKiBOdW1iZXIgb2YgbXNyIHdpdGggdmFsaWQgdmFsdWVzLiAqLworCS8qCisJICogQ3VycmVu
dGx5IEludGVsIGV4dGVuZGVkIE1TUiAoMzIvNjQpIGluY2x1ZGUgYWxsIGdwIHJlZ2lzdGVycwor
CSAqIGFuZCBFKFIpRkxBR1MsIEUoUilJUCwgRShSKU1JU0MsIHVwIHRvIDExLzE5IG9mIHRoZW0g
bWlnaHQgYmUKKwkgKiB1c2VmdWwgYXQgcHJlc2VudC4gU28gZXhwYW5kIHRoaXMgYXJyYXkgdG8g
MTYvMzIgdG8gbGVhdmUgcm9vbS4KKwkgKi8KKwlzdHJ1Y3QgbWNpbmZvX21zciBtY19tc3Jbc2l6
ZW9mKHZvaWQgKikgKiA0XTsKK307CisKKy8qIFJlY292ZXJ5IEFjdGlvbiBmbGFncy4gR2l2aW5n
IHJlY292ZXJ5IHJlc3VsdCBpbmZvcm1hdGlvbiB0byBET00wICovCisKKy8qIFhlbiB0YWtlcyBz
dWNjZXNzZnVsIHJlY292ZXJ5IGFjdGlvbiwgdGhlIGVycm9yIGlzIHJlY292ZXJlZCAqLworI2Rl
ZmluZSBSRUNfQUNUSU9OX1JFQ09WRVJFRCAoMHgxIDw8IDApCisvKiBObyBhY3Rpb24gaXMgcGVy
Zm9ybWVkIGJ5IFhFTiAqLworI2RlZmluZSBSRUNfQUNUSU9OX05PTkUgKDB4MSA8PCAxKQorLyog
SXQncyBwb3NzaWJsZSBET00wIG1pZ2h0IHRha2UgYWN0aW9uIG93bmVyc2hpcCBpbiBzb21lIGNh
c2UgKi8KKyNkZWZpbmUgUkVDX0FDVElPTl9ORUVEX1JFU0VUICgweDEgPDwgMikKKworLyoKKyAq
IERpZmZlcmVudCBSZWNvdmVyeSBBY3Rpb24gdHlwZXMsIGlmIHRoZSBhY3Rpb24gaXMgcGVyZm9y
bWVkIHN1Y2Nlc3NmdWxseSwKKyAqIFJFQ19BQ1RJT05fUkVDT1ZFUkVEIGZsYWcgd2lsbCBiZSBy
ZXR1cm5lZC4KKyAqLworCisvKiBQYWdlIE9mZmxpbmUgQWN0aW9uICovCisjZGVmaW5lIE1DX0FD
VElPTl9QQUdFX09GRkxJTkUgKDB4MSA8PCAwKQorLyogQ1BVIG9mZmxpbmUgQWN0aW9uICovCisj
ZGVmaW5lIE1DX0FDVElPTl9DUFVfT0ZGTElORSAoMHgxIDw8IDEpCisvKiBMMyBjYWNoZSBkaXNh
YmxlIEFjdGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fQ0FDSEVfU0hSSU5LICgweDEgPDwgMikK
KworLyoKKyAqIEJlbG93IGludGVyZmFjZSB1c2VkIGJldHdlZW4gWEVOL0RPTTAgZm9yIHBhc3Np
bmcgWEVOJ3MgcmVjb3ZlcnkgYWN0aW9uCisgKiBpbmZvcm1hdGlvbiB0byBET00wLgorICovCitz
dHJ1Y3QgcGFnZV9vZmZsaW5lX2FjdGlvbiB7CisJLyogUGFyYW1zIGZvciBwYXNzaW5nIHRoZSBv
ZmZsaW5lZCBwYWdlIG51bWJlciB0byBET00wICovCisJdWludDY0X3QgbWZuOworCXVpbnQ2NF90
IHN0YXR1czsKK307CisKK3N0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24geworCS8qIFBhcmFtcyBm
b3IgcGFzc2luZyB0aGUgaWRlbnRpdHkgb2YgdGhlIG9mZmxpbmVkIENQVSB0byBET00wICovCisJ
dWludDMyX3QgbWNfc29ja2V0aWQ7CisJdWludDE2X3QgbWNfY29yZWlkOworCXVpbnQxNl90IG1j
X2NvcmVfdGhyZWFkaWQ7Cit9OworCisjZGVmaW5lIE1BWF9VTklPTl9TSVpFIDE2CitzdHJ1Y3Qg
bWNpbmZvX3JlY292ZXJ5IHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21tb247CisJdWludDE2
X3QgbWNfYmFuazsgLyogYmFuayBuciAqLworCXVpbnQ4X3QgYWN0aW9uX2ZsYWdzOworCXVpbnQ4
X3QgYWN0aW9uX3R5cGVzOworCXVuaW9uIHsKKwkJc3RydWN0IHBhZ2Vfb2ZmbGluZV9hY3Rpb24g
cGFnZV9yZXRpcmU7CisJCXN0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24gY3B1X29mZmxpbmU7CisJ
CXVpbnQ4X3QgcGFkW01BWF9VTklPTl9TSVpFXTsKKwl9IGFjdGlvbl9pbmZvOworfTsKKworCisj
ZGVmaW5lIE1DSU5GT19NQVhTSVpFIDc2OAorc3RydWN0IG1jX2luZm8geworCS8qIE51bWJlciBv
ZiBtY2luZm9fKiBlbnRyaWVzIGluIG1pX2RhdGEgKi8KKwl1aW50MzJfdCBtaV9uZW50cmllczsK
Kwl1aW50MzJfdCBmbGFnczsKKwl1aW50NjRfdCBtaV9kYXRhWyhNQ0lORk9fTUFYU0laRSAtIDEp
IC8gOF07Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QobWNfaW5mbyk7CisKKyNkZWZp
bmUgX19NQ19NU1JfQVJSQVlTSVpFIDgKKyNkZWZpbmUgX19NQ19NU1JfTUNHQ0FQIDAKKyNkZWZp
bmUgX19NQ19OTVNSUyAxCisjZGVmaW5lIE1DX05DQVBTIDcKK3N0cnVjdCBtY2luZm9fbG9naWNh
bF9jcHUgeworCXVpbnQzMl90IG1jX2NwdW5yOworCXVpbnQzMl90IG1jX2NoaXBpZDsKKwl1aW50
MTZfdCBtY19jb3JlaWQ7CisJdWludDE2X3QgbWNfdGhyZWFkaWQ7CisJdWludDMyX3QgbWNfYXBp
Y2lkOworCXVpbnQzMl90IG1jX2NsdXN0ZXJpZDsKKwl1aW50MzJfdCBtY19uY29yZXM7CisJdWlu
dDMyX3QgbWNfbmNvcmVzX2FjdGl2ZTsKKwl1aW50MzJfdCBtY19udGhyZWFkczsKKwl1aW50MzJf
dCBtY19jcHVpZF9sZXZlbDsKKwl1aW50MzJfdCBtY19mYW1pbHk7CisJdWludDMyX3QgbWNfdmVu
ZG9yOworCXVpbnQzMl90IG1jX21vZGVsOworCXVpbnQzMl90IG1jX3N0ZXA7CisJY2hhciBtY192
ZW5kb3JpZFsxNl07CisJY2hhciBtY19icmFuZGlkWzY0XTsKKwl1aW50MzJfdCBtY19jcHVfY2Fw
c1tNQ19OQ0FQU107CisJdWludDMyX3QgbWNfY2FjaGVfc2l6ZTsKKwl1aW50MzJfdCBtY19jYWNo
ZV9hbGlnbm1lbnQ7CisJdWludDMyX3QgbWNfbm1zcnZhbHM7CisJc3RydWN0IG1jaW5mb19tc3Ig
bWNfbXNydmFsdWVzW19fTUNfTVNSX0FSUkFZU0laRV07Cit9OworREVGSU5FX0dVRVNUX0hBTkRM
RV9TVFJVQ1QobWNpbmZvX2xvZ2ljYWxfY3B1KTsKKworLyoKKyAqIFByb3RvdHlwZToKKyAqICAg
IHVpbnQzMl90IHg4Nl9tY2luZm9fbmVudHJpZXMoc3RydWN0IG1jX2luZm8gKm1pKTsKKyAqLwor
I2RlZmluZSB4ODZfbWNpbmZvX25lbnRyaWVzKF9taSkgICAgXAorCSgoX21pKS0+bWlfbmVudHJp
ZXMpCisvKgorICogUHJvdG90eXBlOgorICogICAgc3RydWN0IG1jaW5mb19jb21tb24gKng4Nl9t
Y2luZm9fZmlyc3Qoc3RydWN0IG1jX2luZm8gKm1pKTsKKyAqLworI2RlZmluZSB4ODZfbWNpbmZv
X2ZpcnN0KF9taSkgICAgICAgXAorCSgoc3RydWN0IG1jaW5mb19jb21tb24gKikoX21pKS0+bWlf
ZGF0YSkKKy8qCisgKiBQcm90b3R5cGU6CisgKiAgICBzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqeDg2
X21jaW5mb19uZXh0KHN0cnVjdCBtY2luZm9fY29tbW9uICptaWMpOworICovCisjZGVmaW5lIHg4
Nl9tY2luZm9fbmV4dChfbWljKSAgICAgICBcCisJKChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKSgo
dWludDhfdCAqKShfbWljKSArIChfbWljKS0+c2l6ZSkpCisKKy8qCisgKiBQcm90b3R5cGU6Cisg
KiAgICB2b2lkIHg4Nl9tY2luZm9fbG9va3VwKHZvaWQgKnJldCwgc3RydWN0IG1jX2luZm8gKm1p
LCB1aW50MTZfdCB0eXBlKTsKKyAqLworc3RhdGljIGlubGluZSB2b2lkIHg4Nl9tY2luZm9fbG9v
a3VwKHN0cnVjdCBtY2luZm9fY29tbW9uICoqcmV0LAorCQkJCSAgICAgc3RydWN0IG1jX2luZm8g
Km1pLCB1aW50MTZfdCB0eXBlKQoreworCXVpbnQzMl90IGk7CisJc3RydWN0IG1jaW5mb19jb21t
b24gKm1pYzsKKwlib29sIGZvdW5kID0gMDsKKworCWlmICghcmV0IHx8ICFtaSkKKwkJcmV0dXJu
OworCisJbWljID0geDg2X21jaW5mb19maXJzdChtaSk7CisJZm9yIChpID0gMDsgaSA8IHg4Nl9t
Y2luZm9fbmVudHJpZXMobWkpOyBpKyspIHsKKwkJaWYgKG1pYy0+dHlwZSA9PSB0eXBlKSB7CisJ
CQlmb3VuZCA9IDE7CisJCQlicmVhazsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWlj
KTsKKwl9CisKKwkqcmV0ID0gZm91bmQgPyBtaWMgOiBOVUxMOworfQorCisvKgorICogRmV0Y2gg
bWFjaGluZSBjaGVjayBkYXRhIGZyb20gaHlwZXJ2aXNvci4KKyAqLworI2RlZmluZSBYRU5fTUNf
ZmV0Y2gJCTEKK3N0cnVjdCB4ZW5fbWNfZmV0Y2ggeworCS8qCisJICogSU46IFhFTl9NQ19OT05V
UkdFTlQsIFhFTl9NQ19VUkdFTlQsCisJICogWEVOX01DX0FDSyBpZiBhY2sna2luZyBhbiBlYXJs
aWVyIGZldGNoCisJICogT1VUOiBYRU5fTUNfT0ssIFhFTl9NQ19GRVRDSEFJTEVELCBYRU5fTUNf
Tk9EQVRBCisJICovCisJdWludDMyX3QgZmxhZ3M7CisJdWludDMyX3QgX3BhZDA7CisJLyogT1VU
OiBpZCBmb3IgYWNrLCBJTjogaWQgd2UgYXJlIGFjaydpbmcgKi8KKwl1aW50NjRfdCBmZXRjaF9p
ZDsKKworCS8qIE9VVCB2YXJpYWJsZXMuICovCisJR1VFU1RfSEFORExFKG1jX2luZm8pIGRhdGE7
Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX2ZldGNoKTsKKworCisvKgor
ICogVGhpcyB0ZWxscyB0aGUgaHlwZXJ2aXNvciB0byBub3RpZnkgYSBEb21VIGFib3V0IHRoZSBt
YWNoaW5lIGNoZWNrIGVycm9yCisgKi8KKyNkZWZpbmUgWEVOX01DX25vdGlmeWRvbWFpbgkyCitz
dHJ1Y3QgeGVuX21jX25vdGlmeWRvbWFpbiB7CisJLyogSU4gdmFyaWFibGVzICovCisJdWludDE2
X3QgbWNfZG9taWQ7IC8qIFRoZSB1bnByaXZpbGVnZWQgZG9tYWluIHRvIG5vdGlmeSAqLworCXVp
bnQxNl90IG1jX3ZjcHVpZDsgLyogVGhlIHZjcHUgaW4gbWNfZG9taWQgdG8gbm90aWZ5ICovCisK
KwkvKiBJTi9PVVQgdmFyaWFibGVzICovCisJdWludDMyX3QgZmxhZ3M7Cit9OworREVGSU5FX0dV
RVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX25vdGlmeWRvbWFpbik7CisKKyNkZWZpbmUgWEVOX01D
X3BoeXNjcHVpbmZvCTMKK3N0cnVjdCB4ZW5fbWNfcGh5c2NwdWluZm8geworCS8qIElOL09VVCAq
LworCXVpbnQzMl90IG5jcHVzOworCXVpbnQzMl90IF9wYWQwOworCS8qIE9VVCAqLworCUdVRVNU
X0hBTkRMRShtY2luZm9fbG9naWNhbF9jcHUpIGluZm87Cit9OworCisjZGVmaW5lIFhFTl9NQ19t
c3JpbmplY3QJNAorI2RlZmluZSBNQ19NU1JJTkpfTUFYTVNSUwk4CitzdHJ1Y3QgeGVuX21jX21z
cmluamVjdCB7CisJLyogSU4gKi8KKwl1aW50MzJfdCBtY2lual9jcHVucjsgLyogdGFyZ2V0IHBy
b2Nlc3NvciBpZCAqLworCXVpbnQzMl90IG1jaW5qX2ZsYWdzOyAvKiBzZWUgTUNfTVNSSU5KX0Zf
KiBiZWxvdyAqLworCXVpbnQzMl90IG1jaW5qX2NvdW50OyAvKiAwIC4uIGNvdW50LTEgaW4gYXJy
YXkgYXJlIHZhbGlkICovCisJdWludDMyX3QgX3BhZDA7CisJc3RydWN0IG1jaW5mb19tc3IgbWNp
bmpfbXNyW01DX01TUklOSl9NQVhNU1JTXTsKK307CisKKy8qIEZsYWdzIGZvciBtY2lual9mbGFn
cyBhYm92ZTsgYml0cyAxNi0zMSBhcmUgcmVzZXJ2ZWQgKi8KKyNkZWZpbmUgTUNfTVNSSU5KX0Zf
SU5URVJQT1NFCTB4MQorCisjZGVmaW5lIFhFTl9NQ19tY2VpbmplY3QJNQorc3RydWN0IHhlbl9t
Y19tY2VpbmplY3QgeworCXVuc2lnbmVkIGludCBtY2VpbmpfY3B1bnI7IC8qIHRhcmdldCBwcm9j
ZXNzb3IgaWQgKi8KK307CisKK3N0cnVjdCB4ZW5fbWMgeworCXVpbnQzMl90IGNtZDsKKwl1aW50
MzJfdCBpbnRlcmZhY2VfdmVyc2lvbjsgLyogWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTiAqLwor
CXVuaW9uIHsKKwkJc3RydWN0IHhlbl9tY19mZXRjaCAgICAgICAgbWNfZmV0Y2g7CisJCXN0cnVj
dCB4ZW5fbWNfbm90aWZ5ZG9tYWluIG1jX25vdGlmeWRvbWFpbjsKKwkJc3RydWN0IHhlbl9tY19w
aHlzY3B1aW5mbyAgbWNfcGh5c2NwdWluZm87CisJCXN0cnVjdCB4ZW5fbWNfbXNyaW5qZWN0ICAg
IG1jX21zcmluamVjdDsKKwkJc3RydWN0IHhlbl9tY19tY2VpbmplY3QgICAgbWNfbWNlaW5qZWN0
OworCX0gdTsKK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5fbWMpOworCisjZW5k
aWYgLyogX19BU1NFTUJMWV9fICovCisjZW5kaWYgLyogX19YRU5fUFVCTElDX0FSQ0hfWDg2X01D
QV9IX18gKi8KLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Apr 16 01:06:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 01:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJaON-0002KA-A2; Mon, 16 Apr 2012 01:06:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SJaOL-0002K5-Ew
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 01:06:05 +0000
Received: from [85.158.143.35:21859] by server-1.bemta-4.messagelabs.com id
	42/52-20925-C707B8F4; Mon, 16 Apr 2012 01:06:04 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334538360!13369746!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0NDMx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 574 invoked from network); 16 Apr 2012 01:06:01 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-21.messagelabs.com with SMTP;
	16 Apr 2012 01:06:01 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 15 Apr 2012 18:05:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="131240617"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 15 Apr 2012 18:05:59 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 15 Apr 2012 18:05:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Mon, 16 Apr 2012 09:05:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 1/2] Add mcelog support for xen platform
Thread-Index: Ac0bbRNQOwwDTGvoRgyQnQsEo/DLwA==
Date: Mon, 16 Apr 2012 01:05:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335146A62@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/2] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0ee0651756eb6255bc81da8a7b6313bab4b80d1e Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Sun, 15 Apr 2012 22:58:34 +0800
Subject: [PATCH 1/2] Add mcelog support for xen platform

When MCA error occurs, it would be handled by xen hypervisor first,
and then the error information would be sent to dom0 for logging.

This patch gets error information from xen hypervisor and convert
xen format error into linux format mcelog. This logic is basically
self-contained, not much touching other kernel components.

So under xen platform when MCA error occurs, the error information
would be sent to dom0 and converted into native linux mcelog format.
By using tools like mcelog tool users could read specific error information=
,
like what they did under native linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    4 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  201 ++++++++++++++++++++
 include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 555 insertions(+), 3 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..15628d4 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 9424313..f45f923 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
           module will be called xen_acpi_processor  If you do not know wha=
t to choose,
           select M here. If the CPUFREQ drivers are built in, select Y her=
e.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default n
+	help
+	  Allow kernel fetching mce log from xen platform and
+	  converting it into linux mcelog format for mcelog tools
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9adc5be..1d3e763 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..e9f86b8
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,201 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Driver for receiving and transferring machine check error infomation
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Author: Ke, Liping <liping.ke@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <asm/xen/hypercall.h>
+#include <asm/mce.h>
+#include <xen/xen.h>
+
+static struct mc_info g_mi;
+static struct mcinfo_logical_cpu *g_physinfo;
+static uint32_t ncpus;
+
+static DEFINE_SPINLOCK(mcelog_lock);
+
+static void convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	int i;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	if (unlikely(!mic))
+		return;
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+
+	for (i =3D 0; i < ncpus; i++)
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid)
+			break;
+	if (unlikely(i =3D=3D ncpus))
+		return;
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+
+	do {
+		if ((!mic) || (mic->size =3D=3D 0) ||
+		    (mic->type !=3D MC_TYPE_GLOBAL   &&
+		     mic->type !=3D MC_TYPE_BANK     &&
+		     mic->type !=3D MC_TYPE_EXTENDED &&
+		     mic->type !=3D MC_TYPE_RECOVERY))
+			break;
+
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+}
+
+static void mc_queue_handle(uint32_t flags)
+{
+	struct xen_mc mc_op;
+	int ret =3D 0;
+	unsigned long tmp;
+
+	spin_lock_irqsave(&mcelog_lock, tmp);
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
+	do {
+		mc_op.u.mc_fetch.flags =3D flags;
+		ret =3D HYPERVISOR_mca(&mc_op);
+		if (ret || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+			break;
+		else {
+			convert_log(&g_mi);
+			mc_op.u.mc_fetch.flags =3D flags | XEN_MC_ACK;
+			ret =3D HYPERVISOR_mca(&mc_op);
+			if (ret)
+				break;
+		}
+	} while (1);
+
+	spin_unlock_irqrestore(&mcelog_lock, tmp);
+
+	return;
+}
+
+/* virq handler for machine check error info*/
+static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
+{
+	/* urgent mc_info */
+	mc_queue_handle(XEN_MC_URGENT);
+
+	/* nonurgent mc_info */
+	mc_queue_handle(XEN_MC_NONURGENT);
+
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	struct xen_mc mc_op;
+
+	memset(&mc_op, 0, sizeof(struct xen_mc));
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_LOG: Failed to get CPU numbers\n");
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kzalloc(sizeof(struct mcinfo_logical_cpu) * ncpus,
+			     GFP_KERNEL);
+	if (!g_physinfo)
+		return -ENOMEM;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_LOG: Failed to get CPU info\n");
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+				       mce_dom_interrupt, 0, "mce", NULL);
+	if (ret < 0) {
+		printk(KERN_ERR "MCE_LOG: Failed to bind virq\n");
+		kfree(g_physinfo);
+	}
+
+	return ret;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return -ENODEV;
+}
+late_initcall(mcelog_init);
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f2561db
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,336 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Updated by Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/or
+ * sell copies of the Software, and to permit persons to whom the Software=
 is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT	0x1
+/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT		0x2
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK		0x4
+
+/* OUT: All is ok */
+#define XEN_MC_OK		0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED	0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA		0x2
+
+#ifndef __ASSEMBLY__
+/* vIRQ injected to Dom0 */
+#define VIRQ_MCA VIRQ_ARCH_0
+
+/*
+ * mc_info entry types
+ * mca machine check info are recorded in mc_info entries.
+ * when fetch mca info, it can use MC_TYPE_... to distinguish
+ * different mca info.
+ */
+#define MC_TYPE_GLOBAL		0
+#define MC_TYPE_BANK		1
+#define MC_TYPE_EXTENDED	2
+#define MC_TYPE_RECOVERY	3
+
+struct mcinfo_common {
+	uint16_t type; /* structure type */
+	uint16_t size; /* size of this struct in bytes */
+};
+
+#define MC_FLAG_CORRECTABLE	(1 << 0)
+#define MC_FLAG_UNCORRECTABLE	(1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+
+/* contains x86 global mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	uint16_t mc_domid; /* running domain at the time in error */
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains x86 bank mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr; /* bank address */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+struct mcinfo_msr {
+	uint64_t reg; /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/*
+ * Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/*
+ * Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ */
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	uint8_t action_flags;
+	uint8_t action_types;
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_MAXSIZE 768
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t flags;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_MSR_MCGCAP 0
+#define __MC_NMSRS 1
+#define MC_NCAPS 7
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	uint32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	uint32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+/*
+ * Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+	((_mi)->mi_nentries)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+	((struct mcinfo_common *)(_mi)->mi_data)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/*
+ * Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
+				     struct mc_info *mi, uint16_t type)
+{
+	uint32_t i;
+	struct mcinfo_common *mic;
+	bool found =3D 0;
+
+	if (!ret || !mi)
+		return;
+
+	mic =3D x86_mcinfo_first(mi);
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+
+/*
+ * Fetch machine check data from hypervisor.
+ */
+#define XEN_MC_fetch		1
+struct xen_mc_fetch {
+	/*
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
+	 */
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/*
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain	2
+struct xen_mc_notifydomain {
+	/* IN variables */
+	uint16_t mc_domid; /* The unprivileged domain to notify */
+	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
+
+	/* IN/OUT variables */
+	uint32_t flags;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo	3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject	4
+#define MC_MSRINJ_MAXMSRS	8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr; /* target processor id */
+	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE	0x1
+
+#define XEN_MC_mceinject	5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr; /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-for-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-for-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-for-xen-platform.patch"; size=19856;
	creation-date="Mon, 16 Apr 2012 00:42:43 GMT";
	modification-date="Mon, 16 Apr 2012 08:25:54 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZWUwNjUxNzU2ZWI2MjU1YmM4MWRhOGE3YjYzMTNiYWI0YjgwZDFlIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU3VuLCAxNSBBcHIgMjAxMiAyMjo1ODozNCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZm9yIHhlbiBwbGF0Zm9ybQoKV2hlbiBNQ0EgZXJyb3Igb2Nj
dXJzLCBpdCB3b3VsZCBiZSBoYW5kbGVkIGJ5IHhlbiBoeXBlcnZpc29yIGZpcnN0LAphbmQgdGhl
biB0aGUgZXJyb3IgaW5mb3JtYXRpb24gd291bGQgYmUgc2VudCB0byBkb20wIGZvciBsb2dnaW5n
LgoKVGhpcyBwYXRjaCBnZXRzIGVycm9yIGluZm9ybWF0aW9uIGZyb20geGVuIGh5cGVydmlzb3Ig
YW5kIGNvbnZlcnQKeGVuIGZvcm1hdCBlcnJvciBpbnRvIGxpbnV4IGZvcm1hdCBtY2Vsb2cuIFRo
aXMgbG9naWMgaXMgYmFzaWNhbGx5CnNlbGYtY29udGFpbmVkLCBub3QgbXVjaCB0b3VjaGluZyBv
dGhlciBrZXJuZWwgY29tcG9uZW50cy4KClNvIHVuZGVyIHhlbiBwbGF0Zm9ybSB3aGVuIE1DQSBl
cnJvciBvY2N1cnMsIHRoZSBlcnJvciBpbmZvcm1hdGlvbgp3b3VsZCBiZSBzZW50IHRvIGRvbTAg
YW5kIGNvbnZlcnRlZCBpbnRvIG5hdGl2ZSBsaW51eCBtY2Vsb2cgZm9ybWF0LgpCeSB1c2luZyB0
b29scyBsaWtlIG1jZWxvZyB0b29sIHVzZXJzIGNvdWxkIHJlYWQgc3BlY2lmaWMgZXJyb3IgaW5m
b3JtYXRpb24sCmxpa2Ugd2hhdCB0aGV5IGRpZCB1bmRlciBuYXRpdmUgbGludXguCgpTaWduZWQt
b2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1i
eTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcs
IFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkg
Rml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogYXJjaC94
ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIHwgICAgOCArCiBhcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMgICAgICAgICAgICAgfCAgICA0ICstCiBkcml2ZXJzL3hlbi9LY29uZmlnICAgICAg
ICAgICAgICAgICAgfCAgICA4ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgICAg
ICB8ICAgIDEgKwogZHJpdmVycy94ZW4vbWNlbG9nLmMgICAgICAgICAgICAgICAgIHwgIDIwMSAr
KysrKysrKysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCAgICAg
IHwgIDMzNiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiA2IGZpbGVzIGNoYW5n
ZWQsIDU1NSBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0
IGRyaXZlcnMveGVuL21jZWxvZy5jCiBjcmVhdGUgbW9kZSAxMDA2NDQgaW5jbHVkZS94ZW4vaW50
ZXJmYWNlL3hlbi1tY2EuaAoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9o
eXBlcmNhbGwuaCBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAppbmRleCA1
NzI4ODUyLi41OWMyMjZkIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaHlw
ZXJjYWxsLmgKKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oCkBAIC00
OCw2ICs0OCw3IEBACiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9zY2hlZC5oPgogI2luY2x1ZGUg
PHhlbi9pbnRlcmZhY2UvcGh5c2Rldi5oPgogI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaD4KIAogLyoKICAqIFRoZSBo
eXBlcmNhbGwgYXNtcyBoYXZlIHRvIG1lZXQgc2V2ZXJhbCBjb25zdHJhaW50czoKQEAgLTMwMiw2
ICszMDMsMTMgQEAgSFlQRVJWSVNPUl9zZXRfdGltZXJfb3AodTY0IHRpbWVvdXQpCiB9CiAKIHN0
YXRpYyBpbmxpbmUgaW50CitIWVBFUlZJU09SX21jYShzdHJ1Y3QgeGVuX21jICptY19vcCkKK3sK
KwltY19vcC0+aW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVSRkFDRV9WRVJTSU9OOwor
CXJldHVybiBfaHlwZXJjYWxsMShpbnQsIG1jYSwgbWNfb3ApOworfQorCitzdGF0aWMgaW5saW5l
IGludAogSFlQRVJWSVNPUl9kb20wX29wKHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgKnBsYXRmb3Jt
X29wKQogewogCXBsYXRmb3JtX29wLT5pbnRlcmZhY2VfdmVyc2lvbiA9IFhFTlBGX0lOVEVSRkFD
RV9WRVJTSU9OOwpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIGIvYXJjaC94
ODYveGVuL2VubGlnaHRlbi5jCmluZGV4IDRmNTFiZWIuLjE1NjI4ZDQgMTAwNjQ0Ci0tLSBhL2Fy
Y2gveDg2L3hlbi9lbmxpZ2h0ZW4uYworKysgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKQEAg
LTMyOSw5ICszMjksNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgeGVuX2luaXRfY3B1aWRfbWFzayh2
b2lkKQogCXVuc2lnbmVkIGludCB4c2F2ZV9tYXNrOwogCiAJY3B1aWRfbGVhZjFfZWR4X21hc2sg
PQotCQl+KCgxIDw8IFg4Nl9GRUFUVVJFX01DRSkgIHwgIC8qIGRpc2FibGUgTUNFICovCi0JCSAg
KDEgPDwgWDg2X0ZFQVRVUkVfTUNBKSAgfCAgLyogZGlzYWJsZSBNQ0EgKi8KLQkJICAoMSA8PCBY
ODZfRkVBVFVSRV9NVFJSKSB8ICAvKiBkaXNhYmxlIE1UUlIgKi8KKwkJfigoMSA8PCBYODZfRkVB
VFVSRV9NVFJSKSB8ICAvKiBkaXNhYmxlIE1UUlIgKi8KIAkJICAoMSA8PCBYODZfRkVBVFVSRV9B
Q0MpKTsgICAvKiB0aGVybWFsIG1vbml0b3JpbmcgKi8KIAogCWlmICgheGVuX2luaXRpYWxfZG9t
YWluKCkpCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9LY29uZmlnIGIvZHJpdmVycy94ZW4vS2Nv
bmZpZwppbmRleCA5NDI0MzEzLi5mNDVmOTIzIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9LY29u
ZmlnCisrKyBiL2RyaXZlcnMveGVuL0tjb25maWcKQEAgLTE5NCw0ICsxOTQsMTIgQEAgY29uZmln
IFhFTl9BQ1BJX1BST0NFU1NPUgogICAgICAgICAgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCB4ZW5f
YWNwaV9wcm9jZXNzb3IgIElmIHlvdSBkbyBub3Qga25vdyB3aGF0IHRvIGNob29zZSwKICAgICAg
ICAgICBzZWxlY3QgTSBoZXJlLiBJZiB0aGUgQ1BVRlJFUSBkcml2ZXJzIGFyZSBidWlsdCBpbiwg
c2VsZWN0IFkgaGVyZS4KIAorY29uZmlnIFhFTl9NQ0VfTE9HCisJYm9vbCAiWGVuIHBsYXRmb3Jt
IG1jZWxvZyIKKwlkZXBlbmRzIG9uIFhFTl9ET00wICYmIFg4Nl82NCAmJiBYODZfTUNFCisJZGVm
YXVsdCBuCisJaGVscAorCSAgQWxsb3cga2VybmVsIGZldGNoaW5nIG1jZSBsb2cgZnJvbSB4ZW4g
cGxhdGZvcm0gYW5kCisJICBjb252ZXJ0aW5nIGl0IGludG8gbGludXggbWNlbG9nIGZvcm1hdCBm
b3IgbWNlbG9nIHRvb2xzCisKIGVuZG1lbnUKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggOWFkYzViZS4uMWQzZTc2MyAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTE0LDYgKzE0LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9HTlRERVYpCQkrPSB4ZW4tZ250ZGV2Lm8K
IG9iai0kKENPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DKQkrPSB4ZW4tZ250YWxsb2Mubwogb2Jq
LSQoQ09ORklHX1hFTkZTKQkJCSs9IHhlbmZzLwogb2JqLSQoQ09ORklHX1hFTl9TWVNfSFlQRVJW
SVNPUikJKz0gc3lzLWh5cGVydmlzb3Iubworb2JqLSQoQ09ORklHX1hFTl9NQ0VfTE9HKQkJKz0g
bWNlbG9nLm8KIG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNpLm8KIG9i
ai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hF
TikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIv
ZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ZTlmODZiOAotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC0wLDAg
KzEsMjAxIEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICogRHJpdmVy
IGZvciByZWNlaXZpbmcgYW5kIHRyYW5zZmVycmluZyBtYWNoaW5lIGNoZWNrIGVycm9yIGluZm9t
YXRpb24KKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24KKyAqIEF1
dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKiBBdXRob3I6IEpp
YW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KKyAqIEF1dGhvcjogS2UsIExp
cGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkgaXQgdW5k
ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIK
KyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBvciwgd2hl
biBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwgb3IgaW5j
b3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0IHRvIHRo
ZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBncmFudGVk
LCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0
aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNvZnR3YXJl
IHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0aW9uIHRo
ZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwgZGlzdHJp
YnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwKKyAq
IGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJuaXNoZWQg
dG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKKyAqCisg
KiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBz
aGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBwb3J0aW9u
cyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJ
UyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElNUExJRUQs
IElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB
QklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5PTklORlJJ
TkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlSSUdIVCBI
T0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisgKiBMSUFC
SUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9USEVSV0lT
RSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBUSEUgU09G
VFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRXQVJFLgor
ICovCisKKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9pbml0Lmg+
CisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwuaD4KKyNp
bmNsdWRlIDxsaW51eC9zbGFiLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS94ZW4uaD4KKyNp
bmNsdWRlIDxhc20veGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+Cisj
aW5jbHVkZSA8eGVuL2ludGVyZmFjZS92Y3B1Lmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNh
bGwuaD4KKyNpbmNsdWRlIDxhc20vbWNlLmg+CisjaW5jbHVkZSA8eGVuL3hlbi5oPgorCitzdGF0
aWMgc3RydWN0IG1jX2luZm8gZ19taTsKK3N0YXRpYyBzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1
ICpnX3BoeXNpbmZvOworc3RhdGljIHVpbnQzMl90IG5jcHVzOworCitzdGF0aWMgREVGSU5FX1NQ
SU5MT0NLKG1jZWxvZ19sb2NrKTsKKworc3RhdGljIHZvaWQgY29udmVydF9sb2coc3RydWN0IG1j
X2luZm8gKm1pKQoreworCXN0cnVjdCBtY2luZm9fY29tbW9uICptaWM7CisJc3RydWN0IG1jaW5m
b19nbG9iYWwgKm1jX2dsb2JhbDsKKwlzdHJ1Y3QgbWNpbmZvX2JhbmsgKm1jX2Jhbms7CisJc3Ry
dWN0IG1jZSBtOworCWludCBpOworCisJbWljID0gTlVMTDsKKwl4ODZfbWNpbmZvX2xvb2t1cCgm
bWljLCBtaSwgTUNfVFlQRV9HTE9CQUwpOworCWlmICh1bmxpa2VseSghbWljKSkKKwkJcmV0dXJu
OworCisJbWNlX3NldHVwKCZtKTsKKwltY19nbG9iYWwgPSAoc3RydWN0IG1jaW5mb19nbG9iYWwg
KiltaWM7CisJbS5tY2dzdGF0dXMgPSBtY19nbG9iYWwtPm1jX2dzdGF0dXM7CisJbS5hcGljaWQg
PSBtY19nbG9iYWwtPm1jX2FwaWNpZDsKKworCWZvciAoaSA9IDA7IGkgPCBuY3B1czsgaSsrKQor
CQlpZiAoZ19waHlzaW5mb1tpXS5tY19hcGljaWQgPT0gbS5hcGljaWQpCisJCQlicmVhazsKKwlp
ZiAodW5saWtlbHkoaSA9PSBuY3B1cykpCisJCXJldHVybjsKKworCW0uc29ja2V0aWQgPSBnX3Bo
eXNpbmZvW2ldLm1jX2NoaXBpZDsKKwltLmNwdSA9IG0uZXh0Y3B1ID0gZ19waHlzaW5mb1tpXS5t
Y19jcHVucjsKKwltLmNwdXZlbmRvciA9IChfX3U4KWdfcGh5c2luZm9baV0ubWNfdmVuZG9yOwor
CW0ubWNnY2FwID0gZ19waHlzaW5mb1tpXS5tY19tc3J2YWx1ZXNbX19NQ19NU1JfTUNHQ0FQXS52
YWx1ZTsKKworCW1pYyA9IE5VTEw7CisJeDg2X21jaW5mb19sb29rdXAoJm1pYywgbWksIE1DX1RZ
UEVfQkFOSyk7CisKKwlkbyB7CisJCWlmICgoIW1pYykgfHwgKG1pYy0+c2l6ZSA9PSAwKSB8fAor
CQkgICAgKG1pYy0+dHlwZSAhPSBNQ19UWVBFX0dMT0JBTCAgICYmCisJCSAgICAgbWljLT50eXBl
ICE9IE1DX1RZUEVfQkFOSyAgICAgJiYKKwkJICAgICBtaWMtPnR5cGUgIT0gTUNfVFlQRV9FWFRF
TkRFRCAmJgorCQkgICAgIG1pYy0+dHlwZSAhPSBNQ19UWVBFX1JFQ09WRVJZKSkKKwkJCWJyZWFr
OworCisJCWlmIChtaWMtPnR5cGUgPT0gTUNfVFlQRV9CQU5LKSB7CisJCQltY19iYW5rID0gKHN0
cnVjdCBtY2luZm9fYmFuayAqKW1pYzsKKwkJCW0ubWlzYyA9IG1jX2JhbmstPm1jX21pc2M7CisJ
CQltLnN0YXR1cyA9IG1jX2JhbmstPm1jX3N0YXR1czsKKwkJCW0uYWRkciA9IG1jX2JhbmstPm1j
X2FkZHI7CisJCQltLnRzYyA9IG1jX2JhbmstPm1jX3RzYzsKKwkJCW0uYmFuayA9IG1jX2Jhbmst
Pm1jX2Jhbms7CisJCQltLmZpbmlzaGVkID0gMTsKKwkJCS8qbG9nIHRoaXMgcmVjb3JkKi8KKwkJ
CW1jZV9sb2coJm0pOworCQl9CisJCW1pYyA9IHg4Nl9tY2luZm9fbmV4dChtaWMpOworCX0gd2hp
bGUgKDEpOworfQorCitzdGF0aWMgdm9pZCBtY19xdWV1ZV9oYW5kbGUodWludDMyX3QgZmxhZ3Mp
Cit7CisJc3RydWN0IHhlbl9tYyBtY19vcDsKKwlpbnQgcmV0ID0gMDsKKwl1bnNpZ25lZCBsb25n
IHRtcDsKKworCXNwaW5fbG9ja19pcnFzYXZlKCZtY2Vsb2dfbG9jaywgdG1wKTsKKworCW1jX29w
LmNtZCA9IFhFTl9NQ19mZXRjaDsKKwltY19vcC5pbnRlcmZhY2VfdmVyc2lvbiA9IFhFTl9NQ0Ff
SU5URVJGQUNFX1ZFUlNJT047CisJc2V0X3hlbl9ndWVzdF9oYW5kbGUobWNfb3AudS5tY19mZXRj
aC5kYXRhLCAmZ19taSk7CisJZG8geworCQltY19vcC51Lm1jX2ZldGNoLmZsYWdzID0gZmxhZ3M7
CisJCXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJCWlmIChyZXQgfHwgbWNfb3AudS5t
Y19mZXRjaC5mbGFncyAmIFhFTl9NQ19OT0RBVEEgfHwKKwkJICAgIG1jX29wLnUubWNfZmV0Y2gu
ZmxhZ3MgJiBYRU5fTUNfRkVUQ0hGQUlMRUQpCisJCQlicmVhazsKKwkJZWxzZSB7CisJCQljb252
ZXJ0X2xvZygmZ19taSk7CisJCQltY19vcC51Lm1jX2ZldGNoLmZsYWdzID0gZmxhZ3MgfCBYRU5f
TUNfQUNLOworCQkJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwkJCWlmIChyZXQpCisJ
CQkJYnJlYWs7CisJCX0KKwl9IHdoaWxlICgxKTsKKworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUo
Jm1jZWxvZ19sb2NrLCB0bXApOworCisJcmV0dXJuOworfQorCisvKiB2aXJxIGhhbmRsZXIgZm9y
IG1hY2hpbmUgY2hlY2sgZXJyb3IgaW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgbWNlX2RvbV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCS8qIHVyZ2VudCBtY19pbmZvICov
CisJbWNfcXVldWVfaGFuZGxlKFhFTl9NQ19VUkdFTlQpOworCisJLyogbm9udXJnZW50IG1jX2lu
Zm8gKi8KKwltY19xdWV1ZV9oYW5kbGUoWEVOX01DX05PTlVSR0VOVCk7CisKKwlyZXR1cm4gSVJR
X0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgYmluZF92aXJxX2Zvcl9tY2Uodm9pZCkKK3sKKwlp
bnQgcmV0OworCXN0cnVjdCB4ZW5fbWMgbWNfb3A7CisKKwltZW1zZXQoJm1jX29wLCAwLCBzaXpl
b2Yoc3RydWN0IHhlbl9tYykpOworCisJLyogRmV0Y2ggcGh5c2ljYWwgQ1BVIE51bWJlcnMgKi8K
KwltY19vcC5jbWQgPSBYRU5fTUNfcGh5c2NwdWluZm87CisJbWNfb3AuaW50ZXJmYWNlX3ZlcnNp
b24gPSBYRU5fTUNBX0lOVEVSRkFDRV9WRVJTSU9OOworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG1j
X29wLnUubWNfcGh5c2NwdWluZm8uaW5mbywgZ19waHlzaW5mbyk7CisJcmV0ID0gSFlQRVJWSVNP
Ul9tY2EoJm1jX29wKTsKKwlpZiAocmV0KSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0xPRzog
RmFpbGVkIHRvIGdldCBDUFUgbnVtYmVyc1xuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJLyog
RmV0Y2ggZWFjaCBDUFUgUGh5c2ljYWwgSW5mbyBmb3IgbGF0ZXIgcmVmZXJlbmNlKi8KKwluY3B1
cyA9IG1jX29wLnUubWNfcGh5c2NwdWluZm8ubmNwdXM7CisJZ19waHlzaW5mbyA9IGt6YWxsb2Mo
c2l6ZW9mKHN0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUpICogbmNwdXMsCisJCQkgICAgIEdGUF9L
RVJORUwpOworCWlmICghZ19waHlzaW5mbykKKwkJcmV0dXJuIC1FTk9NRU07CisJc2V0X3hlbl9n
dWVzdF9oYW5kbGUobWNfb3AudS5tY19waHlzY3B1aW5mby5pbmZvLCBnX3BoeXNpbmZvKTsKKwly
ZXQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOworCWlmIChyZXQpIHsKKwkJcHJpbnRrKEtFUk5f
RVJSICJNQ0VfTE9HOiBGYWlsZWQgdG8gZ2V0IENQVSBpbmZvXG4iKTsKKwkJa2ZyZWUoZ19waHlz
aW5mbyk7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0ICA9IGJpbmRfdmlycV90b19pcnFoYW5k
bGVyKFZJUlFfTUNBLCAwLAorCQkJCSAgICAgICBtY2VfZG9tX2ludGVycnVwdCwgMCwgIm1jZSIs
IE5VTEwpOworCWlmIChyZXQgPCAwKSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0xPRzogRmFp
bGVkIHRvIGJpbmQgdmlycVxuIik7CisJCWtmcmVlKGdfcGh5c2luZm8pOworCX0KKworCXJldHVy
biByZXQ7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IG1jZWxvZ19pbml0KHZvaWQpCit7CisJLyog
T25seSBET00wIGlzIHJlc3BvbnNpYmxlIGZvciBNQ0UgbG9nZ2luZyAqLworCWlmICh4ZW5faW5p
dGlhbF9kb21haW4oKSkKKwkJcmV0dXJuIGJpbmRfdmlycV9mb3JfbWNlKCk7CisKKwlyZXR1cm4g
LUVOT0RFVjsKK30KK2xhdGVfaW5pdGNhbGwobWNlbG9nX2luaXQpOwpkaWZmIC0tZ2l0IGEvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4t
bWNhLmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uZjI1NjFkYgotLS0gL2Rl
di9udWxsCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNhLmgKQEAgLTAsMCArMSwz
MzYgQEAKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIGFyY2gteDg2L21jYS5oCisgKiBHdWVz
dCBPUyBtYWNoaW5lIGNoZWNrIGludGVyZmFjZSB0byB4ODYgWGVuLgorICoKKyAqIENvbnRyaWJ1
dGVkIGJ5IEFkdmFuY2VkIE1pY3JvIERldmljZXMsIEluYy4KKyAqIEF1dGhvcjogQ2hyaXN0b3Bo
IEVnZ2VyIDxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT4KKyAqCisgKiBVcGRhdGVkIGJ5IEludGVs
IENvcnBvcmF0aW9uCisgKiBBdXRob3I6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwu
Y29tPgorICoKKyAqIFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdl
LCB0byBhbnkgcGVyc29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc29mdHdhcmUgYW5k
IGFzc29jaWF0ZWQgZG9jdW1lbnRhdGlvbiBmaWxlcyAodGhlICJTb2Z0d2FyZSIpLCB0bworICog
ZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dCByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhv
dXQgbGltaXRhdGlvbiB0aGUKKyAqIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlmeSwgbWVyZ2Us
IHB1Ymxpc2gsIGRpc3RyaWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vcgorICogc2VsbCBjb3BpZXMg
b2YgdGhlIFNvZnR3YXJlLCBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdh
cmUgaXMKKyAqIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0byB0aGUgZm9sbG93aW5nIGNv
bmRpdGlvbnM6CisgKgorICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVy
bWlzc2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vi
c3RhbnRpYWwgcG9ydGlvbnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJ
UyBQUk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNT
IE9SCisgKiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5U
SUVTIE9GIE1FUkNIQU5UQUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFIEFORCBOT05JTkZSSU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9S
UyBPUiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBP
UiBPVEhFUgorICogTElBQklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwg
VE9SVCBPUiBPVEhFUldJU0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNU
SU9OIFdJVEggVEhFIFNPRlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIKKyAqIERFQUxJTkdTIElO
IFRIRSBTT0ZUV0FSRS4KKyAqLworCisjaWZuZGVmIF9fWEVOX1BVQkxJQ19BUkNIX1g4Nl9NQ0Ff
SF9fCisjZGVmaW5lIF9fWEVOX1BVQkxJQ19BUkNIX1g4Nl9NQ0FfSF9fCisKKy8qIEh5cGVyY2Fs
bCAqLworI2RlZmluZSBfX0hZUEVSVklTT1JfbWNhIF9fSFlQRVJWSVNPUl9hcmNoXzAKKworI2Rl
ZmluZSBYRU5fTUNBX0lOVEVSRkFDRV9WRVJTSU9OCTB4MDFlY2MwMDMKKworLyogSU46IERvbTAg
Y2FsbHMgaHlwZXJjYWxsIHRvIHJldHJpZXZlIG5vbnVyZ2VudCBlcnJvciBsb2cgZW50cnkgKi8K
KyNkZWZpbmUgWEVOX01DX05PTlVSR0VOVAkweDEKKy8qIElOOiBEb20wIGNhbGxzIGh5cGVyY2Fs
bCB0byByZXRyaWV2ZSB1cmdlbnQgZXJyb3IgbG9nIGVudHJ5ICovCisjZGVmaW5lIFhFTl9NQ19V
UkdFTlQJCTB4MgorLyogSU46IERvbTAgYWNrbm93bGVkZ2VzIHByZXZpb3NseS1mZXRjaGVkIGVy
cm9yIGxvZyBlbnRyeSAqLworI2RlZmluZSBYRU5fTUNfQUNLCQkweDQKKworLyogT1VUOiBBbGwg
aXMgb2sgKi8KKyNkZWZpbmUgWEVOX01DX09LCQkweDAKKy8qIE9VVDogRG9tYWluIGNvdWxkIG5v
dCBmZXRjaCBkYXRhLiAqLworI2RlZmluZSBYRU5fTUNfRkVUQ0hGQUlMRUQJMHgxCisvKiBPVVQ6
IFRoZXJlIHdhcyBubyBtYWNoaW5lIGNoZWNrIGRhdGEgdG8gZmV0Y2guICovCisjZGVmaW5lIFhF
Tl9NQ19OT0RBVEEJCTB4MgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworLyogdklSUSBpbmplY3Rl
ZCB0byBEb20wICovCisjZGVmaW5lIFZJUlFfTUNBIFZJUlFfQVJDSF8wCisKKy8qCisgKiBtY19p
bmZvIGVudHJ5IHR5cGVzCisgKiBtY2EgbWFjaGluZSBjaGVjayBpbmZvIGFyZSByZWNvcmRlZCBp
biBtY19pbmZvIGVudHJpZXMuCisgKiB3aGVuIGZldGNoIG1jYSBpbmZvLCBpdCBjYW4gdXNlIE1D
X1RZUEVfLi4uIHRvIGRpc3Rpbmd1aXNoCisgKiBkaWZmZXJlbnQgbWNhIGluZm8uCisgKi8KKyNk
ZWZpbmUgTUNfVFlQRV9HTE9CQUwJCTAKKyNkZWZpbmUgTUNfVFlQRV9CQU5LCQkxCisjZGVmaW5l
IE1DX1RZUEVfRVhURU5ERUQJMgorI2RlZmluZSBNQ19UWVBFX1JFQ09WRVJZCTMKKworc3RydWN0
IG1jaW5mb19jb21tb24geworCXVpbnQxNl90IHR5cGU7IC8qIHN0cnVjdHVyZSB0eXBlICovCisJ
dWludDE2X3Qgc2l6ZTsgLyogc2l6ZSBvZiB0aGlzIHN0cnVjdCBpbiBieXRlcyAqLworfTsKKwor
I2RlZmluZSBNQ19GTEFHX0NPUlJFQ1RBQkxFCSgxIDw8IDApCisjZGVmaW5lIE1DX0ZMQUdfVU5D
T1JSRUNUQUJMRQkoMSA8PCAxKQorI2RlZmluZSBNQ19GTEFHX1JFQ09WRVJBQkxFCSgxIDw8IDIp
CisjZGVmaW5lIE1DX0ZMQUdfUE9MTEVECQkoMSA8PCAzKQorI2RlZmluZSBNQ19GTEFHX1JFU0VU
CQkoMSA8PCA0KQorI2RlZmluZSBNQ19GTEFHX0NNQ0kJCSgxIDw8IDUpCisjZGVmaW5lIE1DX0ZM
QUdfTUNFCQkoMSA8PCA2KQorCisvKiBjb250YWlucyB4ODYgZ2xvYmFsIG1jIGluZm9ybWF0aW9u
ICovCitzdHJ1Y3QgbWNpbmZvX2dsb2JhbCB7CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9u
OworCisJdWludDE2X3QgbWNfZG9taWQ7IC8qIHJ1bm5pbmcgZG9tYWluIGF0IHRoZSB0aW1lIGlu
IGVycm9yICovCisJdWludDE2X3QgbWNfdmNwdWlkOyAvKiB2aXJ0dWFsIGNwdSBzY2hlZHVsZWQg
Zm9yIG1jX2RvbWlkICovCisJdWludDMyX3QgbWNfc29ja2V0aWQ7IC8qIHBoeXNpY2FsIHNvY2tl
dCBvZiB0aGUgcGh5c2ljYWwgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVpZDsgLyogcGh5c2lj
YWwgaW1wYWN0ZWQgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7IC8qIGNvcmUg
dGhyZWFkIG9mIHBoeXNpY2FsIGNvcmUgKi8KKwl1aW50MzJfdCBtY19hcGljaWQ7CisJdWludDMy
X3QgbWNfZmxhZ3M7CisJdWludDY0X3QgbWNfZ3N0YXR1czsgLyogZ2xvYmFsIHN0YXR1cyAqLwor
fTsKKworLyogY29udGFpbnMgeDg2IGJhbmsgbWMgaW5mb3JtYXRpb24gKi8KK3N0cnVjdCBtY2lu
Zm9fYmFuayB7CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOworCisJdWludDE2X3QgbWNf
YmFuazsgLyogYmFuayBuciAqLworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBkb21haW4gcmVmZXJl
bmNlZCBieSBtY19hZGRyIGlmIHZhbGlkICovCisJdWludDY0X3QgbWNfc3RhdHVzOyAvKiBiYW5r
IHN0YXR1cyAqLworCXVpbnQ2NF90IG1jX2FkZHI7IC8qIGJhbmsgYWRkcmVzcyAqLworCXVpbnQ2
NF90IG1jX21pc2M7CisJdWludDY0X3QgbWNfY3RybDI7CisJdWludDY0X3QgbWNfdHNjOworfTsK
Kworc3RydWN0IG1jaW5mb19tc3IgeworCXVpbnQ2NF90IHJlZzsgLyogTVNSICovCisJdWludDY0
X3QgdmFsdWU7IC8qIE1TUiB2YWx1ZSAqLworfTsKKworLyogY29udGFpbnMgbWMgaW5mb3JtYXRp
b24gZnJvbSBvdGhlciBvciBhZGRpdGlvbmFsIG1jIE1TUnMgKi8KK3N0cnVjdCBtY2luZm9fZXh0
ZW5kZWQgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNvbW1vbjsKKwl1aW50MzJfdCBtY19tc3Jz
OyAvKiBOdW1iZXIgb2YgbXNyIHdpdGggdmFsaWQgdmFsdWVzLiAqLworCS8qCisJICogQ3VycmVu
dGx5IEludGVsIGV4dGVuZGVkIE1TUiAoMzIvNjQpIGluY2x1ZGUgYWxsIGdwIHJlZ2lzdGVycwor
CSAqIGFuZCBFKFIpRkxBR1MsIEUoUilJUCwgRShSKU1JU0MsIHVwIHRvIDExLzE5IG9mIHRoZW0g
bWlnaHQgYmUKKwkgKiB1c2VmdWwgYXQgcHJlc2VudC4gU28gZXhwYW5kIHRoaXMgYXJyYXkgdG8g
MTYvMzIgdG8gbGVhdmUgcm9vbS4KKwkgKi8KKwlzdHJ1Y3QgbWNpbmZvX21zciBtY19tc3Jbc2l6
ZW9mKHZvaWQgKikgKiA0XTsKK307CisKKy8qIFJlY292ZXJ5IEFjdGlvbiBmbGFncy4gR2l2aW5n
IHJlY292ZXJ5IHJlc3VsdCBpbmZvcm1hdGlvbiB0byBET00wICovCisKKy8qIFhlbiB0YWtlcyBz
dWNjZXNzZnVsIHJlY292ZXJ5IGFjdGlvbiwgdGhlIGVycm9yIGlzIHJlY292ZXJlZCAqLworI2Rl
ZmluZSBSRUNfQUNUSU9OX1JFQ09WRVJFRCAoMHgxIDw8IDApCisvKiBObyBhY3Rpb24gaXMgcGVy
Zm9ybWVkIGJ5IFhFTiAqLworI2RlZmluZSBSRUNfQUNUSU9OX05PTkUgKDB4MSA8PCAxKQorLyog
SXQncyBwb3NzaWJsZSBET00wIG1pZ2h0IHRha2UgYWN0aW9uIG93bmVyc2hpcCBpbiBzb21lIGNh
c2UgKi8KKyNkZWZpbmUgUkVDX0FDVElPTl9ORUVEX1JFU0VUICgweDEgPDwgMikKKworLyoKKyAq
IERpZmZlcmVudCBSZWNvdmVyeSBBY3Rpb24gdHlwZXMsIGlmIHRoZSBhY3Rpb24gaXMgcGVyZm9y
bWVkIHN1Y2Nlc3NmdWxseSwKKyAqIFJFQ19BQ1RJT05fUkVDT1ZFUkVEIGZsYWcgd2lsbCBiZSBy
ZXR1cm5lZC4KKyAqLworCisvKiBQYWdlIE9mZmxpbmUgQWN0aW9uICovCisjZGVmaW5lIE1DX0FD
VElPTl9QQUdFX09GRkxJTkUgKDB4MSA8PCAwKQorLyogQ1BVIG9mZmxpbmUgQWN0aW9uICovCisj
ZGVmaW5lIE1DX0FDVElPTl9DUFVfT0ZGTElORSAoMHgxIDw8IDEpCisvKiBMMyBjYWNoZSBkaXNh
YmxlIEFjdGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fQ0FDSEVfU0hSSU5LICgweDEgPDwgMikK
KworLyoKKyAqIEJlbG93IGludGVyZmFjZSB1c2VkIGJldHdlZW4gWEVOL0RPTTAgZm9yIHBhc3Np
bmcgWEVOJ3MgcmVjb3ZlcnkgYWN0aW9uCisgKiBpbmZvcm1hdGlvbiB0byBET00wLgorICovCitz
dHJ1Y3QgcGFnZV9vZmZsaW5lX2FjdGlvbiB7CisJLyogUGFyYW1zIGZvciBwYXNzaW5nIHRoZSBv
ZmZsaW5lZCBwYWdlIG51bWJlciB0byBET00wICovCisJdWludDY0X3QgbWZuOworCXVpbnQ2NF90
IHN0YXR1czsKK307CisKK3N0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24geworCS8qIFBhcmFtcyBm
b3IgcGFzc2luZyB0aGUgaWRlbnRpdHkgb2YgdGhlIG9mZmxpbmVkIENQVSB0byBET00wICovCisJ
dWludDMyX3QgbWNfc29ja2V0aWQ7CisJdWludDE2X3QgbWNfY29yZWlkOworCXVpbnQxNl90IG1j
X2NvcmVfdGhyZWFkaWQ7Cit9OworCisjZGVmaW5lIE1BWF9VTklPTl9TSVpFIDE2CitzdHJ1Y3Qg
bWNpbmZvX3JlY292ZXJ5IHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21tb247CisJdWludDE2
X3QgbWNfYmFuazsgLyogYmFuayBuciAqLworCXVpbnQ4X3QgYWN0aW9uX2ZsYWdzOworCXVpbnQ4
X3QgYWN0aW9uX3R5cGVzOworCXVuaW9uIHsKKwkJc3RydWN0IHBhZ2Vfb2ZmbGluZV9hY3Rpb24g
cGFnZV9yZXRpcmU7CisJCXN0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24gY3B1X29mZmxpbmU7CisJ
CXVpbnQ4X3QgcGFkW01BWF9VTklPTl9TSVpFXTsKKwl9IGFjdGlvbl9pbmZvOworfTsKKworCisj
ZGVmaW5lIE1DSU5GT19NQVhTSVpFIDc2OAorc3RydWN0IG1jX2luZm8geworCS8qIE51bWJlciBv
ZiBtY2luZm9fKiBlbnRyaWVzIGluIG1pX2RhdGEgKi8KKwl1aW50MzJfdCBtaV9uZW50cmllczsK
Kwl1aW50MzJfdCBmbGFnczsKKwl1aW50NjRfdCBtaV9kYXRhWyhNQ0lORk9fTUFYU0laRSAtIDEp
IC8gOF07Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QobWNfaW5mbyk7CisKKyNkZWZp
bmUgX19NQ19NU1JfQVJSQVlTSVpFIDgKKyNkZWZpbmUgX19NQ19NU1JfTUNHQ0FQIDAKKyNkZWZp
bmUgX19NQ19OTVNSUyAxCisjZGVmaW5lIE1DX05DQVBTIDcKK3N0cnVjdCBtY2luZm9fbG9naWNh
bF9jcHUgeworCXVpbnQzMl90IG1jX2NwdW5yOworCXVpbnQzMl90IG1jX2NoaXBpZDsKKwl1aW50
MTZfdCBtY19jb3JlaWQ7CisJdWludDE2X3QgbWNfdGhyZWFkaWQ7CisJdWludDMyX3QgbWNfYXBp
Y2lkOworCXVpbnQzMl90IG1jX2NsdXN0ZXJpZDsKKwl1aW50MzJfdCBtY19uY29yZXM7CisJdWlu
dDMyX3QgbWNfbmNvcmVzX2FjdGl2ZTsKKwl1aW50MzJfdCBtY19udGhyZWFkczsKKwl1aW50MzJf
dCBtY19jcHVpZF9sZXZlbDsKKwl1aW50MzJfdCBtY19mYW1pbHk7CisJdWludDMyX3QgbWNfdmVu
ZG9yOworCXVpbnQzMl90IG1jX21vZGVsOworCXVpbnQzMl90IG1jX3N0ZXA7CisJY2hhciBtY192
ZW5kb3JpZFsxNl07CisJY2hhciBtY19icmFuZGlkWzY0XTsKKwl1aW50MzJfdCBtY19jcHVfY2Fw
c1tNQ19OQ0FQU107CisJdWludDMyX3QgbWNfY2FjaGVfc2l6ZTsKKwl1aW50MzJfdCBtY19jYWNo
ZV9hbGlnbm1lbnQ7CisJdWludDMyX3QgbWNfbm1zcnZhbHM7CisJc3RydWN0IG1jaW5mb19tc3Ig
bWNfbXNydmFsdWVzW19fTUNfTVNSX0FSUkFZU0laRV07Cit9OworREVGSU5FX0dVRVNUX0hBTkRM
RV9TVFJVQ1QobWNpbmZvX2xvZ2ljYWxfY3B1KTsKKworLyoKKyAqIFByb3RvdHlwZToKKyAqICAg
IHVpbnQzMl90IHg4Nl9tY2luZm9fbmVudHJpZXMoc3RydWN0IG1jX2luZm8gKm1pKTsKKyAqLwor
I2RlZmluZSB4ODZfbWNpbmZvX25lbnRyaWVzKF9taSkgICAgXAorCSgoX21pKS0+bWlfbmVudHJp
ZXMpCisvKgorICogUHJvdG90eXBlOgorICogICAgc3RydWN0IG1jaW5mb19jb21tb24gKng4Nl9t
Y2luZm9fZmlyc3Qoc3RydWN0IG1jX2luZm8gKm1pKTsKKyAqLworI2RlZmluZSB4ODZfbWNpbmZv
X2ZpcnN0KF9taSkgICAgICAgXAorCSgoc3RydWN0IG1jaW5mb19jb21tb24gKikoX21pKS0+bWlf
ZGF0YSkKKy8qCisgKiBQcm90b3R5cGU6CisgKiAgICBzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqeDg2
X21jaW5mb19uZXh0KHN0cnVjdCBtY2luZm9fY29tbW9uICptaWMpOworICovCisjZGVmaW5lIHg4
Nl9tY2luZm9fbmV4dChfbWljKSAgICAgICBcCisJKChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKSgo
dWludDhfdCAqKShfbWljKSArIChfbWljKS0+c2l6ZSkpCisKKy8qCisgKiBQcm90b3R5cGU6Cisg
KiAgICB2b2lkIHg4Nl9tY2luZm9fbG9va3VwKHZvaWQgKnJldCwgc3RydWN0IG1jX2luZm8gKm1p
LCB1aW50MTZfdCB0eXBlKTsKKyAqLworc3RhdGljIGlubGluZSB2b2lkIHg4Nl9tY2luZm9fbG9v
a3VwKHN0cnVjdCBtY2luZm9fY29tbW9uICoqcmV0LAorCQkJCSAgICAgc3RydWN0IG1jX2luZm8g
Km1pLCB1aW50MTZfdCB0eXBlKQoreworCXVpbnQzMl90IGk7CisJc3RydWN0IG1jaW5mb19jb21t
b24gKm1pYzsKKwlib29sIGZvdW5kID0gMDsKKworCWlmICghcmV0IHx8ICFtaSkKKwkJcmV0dXJu
OworCisJbWljID0geDg2X21jaW5mb19maXJzdChtaSk7CisJZm9yIChpID0gMDsgaSA8IHg4Nl9t
Y2luZm9fbmVudHJpZXMobWkpOyBpKyspIHsKKwkJaWYgKG1pYy0+dHlwZSA9PSB0eXBlKSB7CisJ
CQlmb3VuZCA9IDE7CisJCQlicmVhazsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWlj
KTsKKwl9CisKKwkqcmV0ID0gZm91bmQgPyBtaWMgOiBOVUxMOworfQorCisvKgorICogRmV0Y2gg
bWFjaGluZSBjaGVjayBkYXRhIGZyb20gaHlwZXJ2aXNvci4KKyAqLworI2RlZmluZSBYRU5fTUNf
ZmV0Y2gJCTEKK3N0cnVjdCB4ZW5fbWNfZmV0Y2ggeworCS8qCisJICogSU46IFhFTl9NQ19OT05V
UkdFTlQsIFhFTl9NQ19VUkdFTlQsCisJICogWEVOX01DX0FDSyBpZiBhY2sna2luZyBhbiBlYXJs
aWVyIGZldGNoCisJICogT1VUOiBYRU5fTUNfT0ssIFhFTl9NQ19GRVRDSEFJTEVELCBYRU5fTUNf
Tk9EQVRBCisJICovCisJdWludDMyX3QgZmxhZ3M7CisJdWludDMyX3QgX3BhZDA7CisJLyogT1VU
OiBpZCBmb3IgYWNrLCBJTjogaWQgd2UgYXJlIGFjaydpbmcgKi8KKwl1aW50NjRfdCBmZXRjaF9p
ZDsKKworCS8qIE9VVCB2YXJpYWJsZXMuICovCisJR1VFU1RfSEFORExFKG1jX2luZm8pIGRhdGE7
Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX2ZldGNoKTsKKworCisvKgor
ICogVGhpcyB0ZWxscyB0aGUgaHlwZXJ2aXNvciB0byBub3RpZnkgYSBEb21VIGFib3V0IHRoZSBt
YWNoaW5lIGNoZWNrIGVycm9yCisgKi8KKyNkZWZpbmUgWEVOX01DX25vdGlmeWRvbWFpbgkyCitz
dHJ1Y3QgeGVuX21jX25vdGlmeWRvbWFpbiB7CisJLyogSU4gdmFyaWFibGVzICovCisJdWludDE2
X3QgbWNfZG9taWQ7IC8qIFRoZSB1bnByaXZpbGVnZWQgZG9tYWluIHRvIG5vdGlmeSAqLworCXVp
bnQxNl90IG1jX3ZjcHVpZDsgLyogVGhlIHZjcHUgaW4gbWNfZG9taWQgdG8gbm90aWZ5ICovCisK
KwkvKiBJTi9PVVQgdmFyaWFibGVzICovCisJdWludDMyX3QgZmxhZ3M7Cit9OworREVGSU5FX0dV
RVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX25vdGlmeWRvbWFpbik7CisKKyNkZWZpbmUgWEVOX01D
X3BoeXNjcHVpbmZvCTMKK3N0cnVjdCB4ZW5fbWNfcGh5c2NwdWluZm8geworCS8qIElOL09VVCAq
LworCXVpbnQzMl90IG5jcHVzOworCXVpbnQzMl90IF9wYWQwOworCS8qIE9VVCAqLworCUdVRVNU
X0hBTkRMRShtY2luZm9fbG9naWNhbF9jcHUpIGluZm87Cit9OworCisjZGVmaW5lIFhFTl9NQ19t
c3JpbmplY3QJNAorI2RlZmluZSBNQ19NU1JJTkpfTUFYTVNSUwk4CitzdHJ1Y3QgeGVuX21jX21z
cmluamVjdCB7CisJLyogSU4gKi8KKwl1aW50MzJfdCBtY2lual9jcHVucjsgLyogdGFyZ2V0IHBy
b2Nlc3NvciBpZCAqLworCXVpbnQzMl90IG1jaW5qX2ZsYWdzOyAvKiBzZWUgTUNfTVNSSU5KX0Zf
KiBiZWxvdyAqLworCXVpbnQzMl90IG1jaW5qX2NvdW50OyAvKiAwIC4uIGNvdW50LTEgaW4gYXJy
YXkgYXJlIHZhbGlkICovCisJdWludDMyX3QgX3BhZDA7CisJc3RydWN0IG1jaW5mb19tc3IgbWNp
bmpfbXNyW01DX01TUklOSl9NQVhNU1JTXTsKK307CisKKy8qIEZsYWdzIGZvciBtY2lual9mbGFn
cyBhYm92ZTsgYml0cyAxNi0zMSBhcmUgcmVzZXJ2ZWQgKi8KKyNkZWZpbmUgTUNfTVNSSU5KX0Zf
SU5URVJQT1NFCTB4MQorCisjZGVmaW5lIFhFTl9NQ19tY2VpbmplY3QJNQorc3RydWN0IHhlbl9t
Y19tY2VpbmplY3QgeworCXVuc2lnbmVkIGludCBtY2VpbmpfY3B1bnI7IC8qIHRhcmdldCBwcm9j
ZXNzb3IgaWQgKi8KK307CisKK3N0cnVjdCB4ZW5fbWMgeworCXVpbnQzMl90IGNtZDsKKwl1aW50
MzJfdCBpbnRlcmZhY2VfdmVyc2lvbjsgLyogWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTiAqLwor
CXVuaW9uIHsKKwkJc3RydWN0IHhlbl9tY19mZXRjaCAgICAgICAgbWNfZmV0Y2g7CisJCXN0cnVj
dCB4ZW5fbWNfbm90aWZ5ZG9tYWluIG1jX25vdGlmeWRvbWFpbjsKKwkJc3RydWN0IHhlbl9tY19w
aHlzY3B1aW5mbyAgbWNfcGh5c2NwdWluZm87CisJCXN0cnVjdCB4ZW5fbWNfbXNyaW5qZWN0ICAg
IG1jX21zcmluamVjdDsKKwkJc3RydWN0IHhlbl9tY19tY2VpbmplY3QgICAgbWNfbWNlaW5qZWN0
OworCX0gdTsKK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5fbWMpOworCisjZW5k
aWYgLyogX19BU1NFTUJMWV9fICovCisjZW5kaWYgLyogX19YRU5fUFVCTElDX0FSQ0hfWDg2X01D
QV9IX18gKi8KLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335146A62SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Apr 16 01:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 01:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJaRK-0002R0-32; Mon, 16 Apr 2012 01:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SJaRJ-0002Qu-AM
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 01:09:09 +0000
Received: from [85.158.143.99:10605] by server-1.bemta-4.messagelabs.com id
	4A/33-20925-4317B8F4; Mon, 16 Apr 2012 01:09:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334538545!22841902!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0NDMx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 16 Apr 2012 01:09:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 01:09:06 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 15 Apr 2012 18:09:04 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="131241497"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 15 Apr 2012 18:09:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 15 Apr 2012 18:09:04 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Mon, 16 Apr 2012 09:07:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 2/2] Register native mce handler as vMCE bounce back point
Thread-Index: Ac0bbU8p/TdpFhoPSxCwxlIbh3KVRg==
Date: Mon, 16 Apr 2012 01:07:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE bounce
	back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Mon, 16 Apr 2012 00:16:58 +0800
Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back point

When xen hyeprvisor inject vMCE to guest, use native mce handler to handle =
it

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 15628d4..346ba64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	/*
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
-	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * about.  Xen will handle faults like double_fault,
+	 * so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		/*
+		 * when xen hyeprvisor inject vMCE to guest,
+		 * use native mce handler to handle it
+		 */
+		;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch"
Content-Description: 0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch
Content-Disposition: attachment;
	filename="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch";
	size=1663; creation-date="Mon, 16 Apr 2012 00:42:43 GMT";
	modification-date="Mon, 16 Apr 2012 08:25:54 GMT"
Content-Transfer-Encoding: base64

RnJvbSA3NmU0MGE2MDg3OGZmNzI5ODZmZDhkOTI2MTE0MDAxOTVhZTBmOTk3IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogTW9uLCAxNiBBcHIgMjAxMiAwMDoxNjo1OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBSZWdpc3RlciBuYXRpdmUgbWNlIGhhbmRsZXIgYXMgdk1DRSBib3VuY2UgYmFjayBwb2ludAoK
V2hlbiB4ZW4gaHllcHJ2aXNvciBpbmplY3Qgdk1DRSB0byBndWVzdCwgdXNlIG5hdGl2ZSBtY2Ug
aGFuZGxlciB0byBoYW5kbGUgaXQKClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29u
Zy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBpbmcua2VAaW50
ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRl
bC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFy
ZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgfCAgIDEwICsr
KysrKystLS0KIDEgZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyBiL2FyY2gveDg2L3hlbi9l
bmxpZ2h0ZW4uYwppbmRleCAxNTYyOGQ0Li4zNDZiYTY0IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCkBAIC02MTQsOCAr
NjE0LDggQEAgc3RhdGljIGludCBjdnRfZ2F0ZV90b190cmFwKGludCB2ZWN0b3IsIGNvbnN0IGdh
dGVfZGVzYyAqdmFsLAogCS8qCiAJICogTG9vayBmb3Iga25vd24gdHJhcHMgdXNpbmcgSVNULCBh
bmQgc3Vic3RpdHV0ZSB0aGVtCiAJICogYXBwcm9wcmlhdGVseS4gIFRoZSBkZWJ1Z2dlciBvbmVz
IGFyZSB0aGUgb25seSBvbmVzIHdlIGNhcmUKLQkgKiBhYm91dC4gIFhlbiB3aWxsIGhhbmRsZSBm
YXVsdHMgbGlrZSBkb3VibGVfZmF1bHQgYW5kCi0JICogbWFjaGluZV9jaGVjaywgc28gd2Ugc2hv
dWxkIG5ldmVyIHNlZSB0aGVtLiAgV2FybiBpZgorCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxl
IGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVsdCwKKwkgKiBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRo
ZW0uICBXYXJuIGlmCiAJICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBo
YW5kbGVyLgogCSAqLwogCWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNjMw
LDcgKzYzMCwxMSBAQCBzdGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29u
c3QgZ2F0ZV9kZXNjICp2YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJ
fSBlbHNlIGlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0
dXJuIDA7CisJCS8qCisJCSAqIHdoZW4geGVuIGh5ZXBydmlzb3IgaW5qZWN0IHZNQ0UgdG8gZ3Vl
c3QsCisJCSAqIHVzZSBuYXRpdmUgbWNlIGhhbmRsZXIgdG8gaGFuZGxlIGl0CisJCSAqLworCQk7
CiAjZW5kaWYKIAl9IGVsc2UgewogCQkvKiBTb21lIG90aGVyIHRyYXAgdXNpbmcgSVNUPyAqLwot
LSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Apr 16 01:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 01:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJaRK-0002R0-32; Mon, 16 Apr 2012 01:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SJaRJ-0002Qu-AM
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 01:09:09 +0000
Received: from [85.158.143.99:10605] by server-1.bemta-4.messagelabs.com id
	4A/33-20925-4317B8F4; Mon, 16 Apr 2012 01:09:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334538545!22841902!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0NDMx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 16 Apr 2012 01:09:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 01:09:06 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 15 Apr 2012 18:09:04 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="131241497"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 15 Apr 2012 18:09:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 15 Apr 2012 18:09:04 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Mon, 16 Apr 2012 09:07:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 2/2] Register native mce handler as vMCE bounce back point
Thread-Index: Ac0bbU8p/TdpFhoPSxCwxlIbh3KVRg==
Date: Mon, 16 Apr 2012 01:07:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE bounce
	back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Mon, 16 Apr 2012 00:16:58 +0800
Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back point

When xen hyeprvisor inject vMCE to guest, use native mce handler to handle =
it

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 15628d4..346ba64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	/*
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
-	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * about.  Xen will handle faults like double_fault,
+	 * so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		/*
+		 * when xen hyeprvisor inject vMCE to guest,
+		 * use native mce handler to handle it
+		 */
+		;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch"
Content-Description: 0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch
Content-Disposition: attachment;
	filename="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch";
	size=1663; creation-date="Mon, 16 Apr 2012 00:42:43 GMT";
	modification-date="Mon, 16 Apr 2012 08:25:54 GMT"
Content-Transfer-Encoding: base64

RnJvbSA3NmU0MGE2MDg3OGZmNzI5ODZmZDhkOTI2MTE0MDAxOTVhZTBmOTk3IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogTW9uLCAxNiBBcHIgMjAxMiAwMDoxNjo1OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBSZWdpc3RlciBuYXRpdmUgbWNlIGhhbmRsZXIgYXMgdk1DRSBib3VuY2UgYmFjayBwb2ludAoK
V2hlbiB4ZW4gaHllcHJ2aXNvciBpbmplY3Qgdk1DRSB0byBndWVzdCwgdXNlIG5hdGl2ZSBtY2Ug
aGFuZGxlciB0byBoYW5kbGUgaXQKClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29u
Zy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBpbmcua2VAaW50
ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRl
bC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFy
ZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgfCAgIDEwICsr
KysrKystLS0KIDEgZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyBiL2FyY2gveDg2L3hlbi9l
bmxpZ2h0ZW4uYwppbmRleCAxNTYyOGQ0Li4zNDZiYTY0IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCkBAIC02MTQsOCAr
NjE0LDggQEAgc3RhdGljIGludCBjdnRfZ2F0ZV90b190cmFwKGludCB2ZWN0b3IsIGNvbnN0IGdh
dGVfZGVzYyAqdmFsLAogCS8qCiAJICogTG9vayBmb3Iga25vd24gdHJhcHMgdXNpbmcgSVNULCBh
bmQgc3Vic3RpdHV0ZSB0aGVtCiAJICogYXBwcm9wcmlhdGVseS4gIFRoZSBkZWJ1Z2dlciBvbmVz
IGFyZSB0aGUgb25seSBvbmVzIHdlIGNhcmUKLQkgKiBhYm91dC4gIFhlbiB3aWxsIGhhbmRsZSBm
YXVsdHMgbGlrZSBkb3VibGVfZmF1bHQgYW5kCi0JICogbWFjaGluZV9jaGVjaywgc28gd2Ugc2hv
dWxkIG5ldmVyIHNlZSB0aGVtLiAgV2FybiBpZgorCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxl
IGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVsdCwKKwkgKiBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRo
ZW0uICBXYXJuIGlmCiAJICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBo
YW5kbGVyLgogCSAqLwogCWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNjMw
LDcgKzYzMCwxMSBAQCBzdGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29u
c3QgZ2F0ZV9kZXNjICp2YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJ
fSBlbHNlIGlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0
dXJuIDA7CisJCS8qCisJCSAqIHdoZW4geGVuIGh5ZXBydmlzb3IgaW5qZWN0IHZNQ0UgdG8gZ3Vl
c3QsCisJCSAqIHVzZSBuYXRpdmUgbWNlIGhhbmRsZXIgdG8gaGFuZGxlIGl0CisJCSAqLworCQk7
CiAjZW5kaWYKIAl9IGVsc2UgewogCQkvKiBTb21lIG90aGVyIHRyYXAgdXNpbmcgSVNUPyAqLwot
LSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335146A7ASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Apr 16 07:40:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgWx-0005MX-JW; Mon, 16 Apr 2012 07:39:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJgWw-0005MQ-7r
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 07:39:22 +0000
Received: from [85.158.138.51:52466] by server-7.bemta-3.messagelabs.com id
	38/54-03078-9ACCB8F4; Mon, 16 Apr 2012 07:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334561959!18092355!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32577 invoked from network); 16 Apr 2012 07:39:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11946899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:39:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 08:39:18 +0100
Message-ID: <1334561958.4445.5.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=E5=A4=8F=E4=B8=9A=E6=B7=BB?= <summerxyt@gmail.com>
Date: Mon, 16 Apr 2012 08:39:18 +0100
In-Reply-To: <CAMjnu2e4DL_MKHPEJcSWwBUkCTSQ9kha5D-TzkPu4PWUb4nu6Q@mail.gmail.com>
References: <CAMjnu2e4DL_MKHPEJcSWwBUkCTSQ9kha5D-TzkPu4PWUb4nu6Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problem about DOMID_SELF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA0LTE1IGF0IDA5OjU4ICswMTAwLCDlpI/kuJrmt7sgd3JvdGU6Cj4gSGkg
ZXZlcnlvbmUsCj4gCj4gSSdtIG5ldyBvbiB0aGlzIGZpZWxkLiBUaGUgY29tbWVudCBvZiBzb3Vy
Y2UgY29kZSBzYXlzIHRoYXQKPiAiRE9NSURfU0VMRiBpcyB1c2VkIGluIGNlcnRhaW4gY29udGV4
dHMgdG8gcmVmZXIgdG8gb25lc2VsZi4iIElzIHRoaXMKPiBpZCB0aGUgbWljcm8gcmV0dXJucyB0
aGUgc2FtZSBhcyB0aGUgaWQgd2hpY2ggaSBjYW4gZ2V0IGJ5IHhtIGxpc3Q/CgpET01JRF9TRUxG
IGlzIGEgbWFnaWMgbnVtYmVyIHVzZWQgYXMgYSBwbGFjZWhvbGRlciB0byBtZWFuICJ0aGlzCmRv
bWFpbiIsIGl0IGlzIGludGVycHJldGVkIHRoaXMgd2F5IGJ5IHZhcmlvdXMgcm91dGluZXMgaW4g
dGhlCmh5cGVydnNvciwgaXQgaXMgbm90IGxpdGVyYWxseSB0aGUgZG9taWQgb2YgdGhlIGN1cnJl
bnQgZG9tYWluLgoKSSBzdWdnZXN0IHlvdSBncmVwIHRoZSBYZW4gc291cmNlIGZvciB0aGUgZGVm
aW5pdGlvbiBhbmQgdXNlIG9mCkRPTUlEX1NFTEYsIGFsbCBzaG91bGQgYmVjb21lIGNsZWFyLgoK
SW4gZ2VuZXJhbCBkb21haW5zIGFyZSBub3QgKGFuZCBkbyBub3QgbmVlZCB0byBiZSkgYXdhcmUg
b2YgdGhlaXIgb3duCmRvbWFpbiBpZC4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 16 07:40:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgWx-0005MX-JW; Mon, 16 Apr 2012 07:39:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJgWw-0005MQ-7r
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 07:39:22 +0000
Received: from [85.158.138.51:52466] by server-7.bemta-3.messagelabs.com id
	38/54-03078-9ACCB8F4; Mon, 16 Apr 2012 07:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334561959!18092355!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32577 invoked from network); 16 Apr 2012 07:39:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11946899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:39:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 08:39:18 +0100
Message-ID: <1334561958.4445.5.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=E5=A4=8F=E4=B8=9A=E6=B7=BB?= <summerxyt@gmail.com>
Date: Mon, 16 Apr 2012 08:39:18 +0100
In-Reply-To: <CAMjnu2e4DL_MKHPEJcSWwBUkCTSQ9kha5D-TzkPu4PWUb4nu6Q@mail.gmail.com>
References: <CAMjnu2e4DL_MKHPEJcSWwBUkCTSQ9kha5D-TzkPu4PWUb4nu6Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problem about DOMID_SELF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA0LTE1IGF0IDA5OjU4ICswMTAwLCDlpI/kuJrmt7sgd3JvdGU6Cj4gSGkg
ZXZlcnlvbmUsCj4gCj4gSSdtIG5ldyBvbiB0aGlzIGZpZWxkLiBUaGUgY29tbWVudCBvZiBzb3Vy
Y2UgY29kZSBzYXlzIHRoYXQKPiAiRE9NSURfU0VMRiBpcyB1c2VkIGluIGNlcnRhaW4gY29udGV4
dHMgdG8gcmVmZXIgdG8gb25lc2VsZi4iIElzIHRoaXMKPiBpZCB0aGUgbWljcm8gcmV0dXJucyB0
aGUgc2FtZSBhcyB0aGUgaWQgd2hpY2ggaSBjYW4gZ2V0IGJ5IHhtIGxpc3Q/CgpET01JRF9TRUxG
IGlzIGEgbWFnaWMgbnVtYmVyIHVzZWQgYXMgYSBwbGFjZWhvbGRlciB0byBtZWFuICJ0aGlzCmRv
bWFpbiIsIGl0IGlzIGludGVycHJldGVkIHRoaXMgd2F5IGJ5IHZhcmlvdXMgcm91dGluZXMgaW4g
dGhlCmh5cGVydnNvciwgaXQgaXMgbm90IGxpdGVyYWxseSB0aGUgZG9taWQgb2YgdGhlIGN1cnJl
bnQgZG9tYWluLgoKSSBzdWdnZXN0IHlvdSBncmVwIHRoZSBYZW4gc291cmNlIGZvciB0aGUgZGVm
aW5pdGlvbiBhbmQgdXNlIG9mCkRPTUlEX1NFTEYsIGFsbCBzaG91bGQgYmVjb21lIGNsZWFyLgoK
SW4gZ2VuZXJhbCBkb21haW5zIGFyZSBub3QgKGFuZCBkbyBub3QgbmVlZCB0byBiZSkgYXdhcmUg
b2YgdGhlaXIgb3duCmRvbWFpbiBpZC4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 16 07:43:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgaQ-0005Y9-FQ; Mon, 16 Apr 2012 07:42:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJgaO-0005Y0-Ra
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 07:42:57 +0000
Received: from [85.158.143.99:11964] by server-3.bemta-4.messagelabs.com id
	97/F9-05853-08DCB8F4; Mon, 16 Apr 2012 07:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334562174!14143708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19129 invoked from network); 16 Apr 2012 07:42:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:42:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11946985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:42:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 08:42:53 +0100
Message-ID: <1334562173.4445.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 16 Apr 2012 08:42:53 +0100
In-Reply-To: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-15 at 19:43 +0100, Jean Guyader wrote:
> libxl require the command flex to be present.
> Verify in the configure script that the flex
> command exsits.

If only it were that simple :-/

We need a fairly recent version of flex (to avoid bugs WRT reentrancy of
the generated parsers) and this version is not in various stable
releases of common distros.

So we check in the generated files and are supposed to only rebuild them
when the source has changed. However there seems to be a bug somewhere
(probably something to do with VCS vs. timestamps) and sometime the
files get regenerated when they needn't be, at which point you need =

flex...

I think Roger Pau Monn=E9 posted a fix for all this last week.

> =

> Signed-off-by: Jean Guyader <jean.guyader@gmail.com>
> ---
>  tools/configure    |  633 +++++++++++++++++++++++++++++-----------------=
------
>  tools/configure.ac |    1 +
>  2 files changed, 350 insertions(+), 284 deletions(-)
> =

> diff --git a/tools/configure b/tools/configure
> index 86618f5..071adf7 100755
> --- a/tools/configure
> +++ b/tools/configure
> @@ -1,6 +1,6 @@
>  #! /bin/sh
>  # Guess values for system-dependent variables and create Makefiles.
> -# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
> +# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
>  #
>  # Report bugs to <xen-devel@lists.xensource.com>.
>  #
> @@ -91,6 +91,7 @@ fi
>  IFS=3D" ""       $as_nl"
> =

>  # Find who we are.  Look in the path if we contain no directory separato=
r.
> +as_myself=3D
>  case $0 in #((
>    *[\\/]* ) as_myself=3D$0 ;;
>    *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> @@ -216,11 +217,18 @@ IFS=3D$as_save_IFS
>    # We cannot yet assume a decent shell, so we have to provide a
>         # neutralization value for shells without unset; and this also
>         # works around shells that cannot unset nonexistent variables.
> +       # Preserve -v and -x to the replacement shell.
>         BASH_ENV=3D/dev/null
>         ENV=3D/dev/null
>         (unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
>         export CONFIG_SHELL
> -       exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
> +       case $- in # ((((
> +         *v*x* | *x*v* ) as_opts=3D-vx ;;
> +         *v* ) as_opts=3D-v ;;
> +         *x* ) as_opts=3D-x ;;
> +         * ) as_opts=3D ;;
> +       esac
> +       exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
>  fi
> =

>      if test x$as_have_required =3D xno; then :
> @@ -1164,7 +1172,7 @@ Try \`$0 --help' for more information"
>      $as_echo "$as_me: WARNING: you should use --build, --host, --target"=
 >&2
>      expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
>        $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
> -    : ${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_al=
ias=3D$ac_option}
> +    : "${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_a=
lias=3D$ac_option}"
>      ;;
> =

>    esac
> @@ -1490,7 +1498,7 @@ test -n "$ac_init_help" && exit $ac_status
>  if $ac_init_version; then
>    cat <<\_ACEOF
>  Xen Hypervisor configure 4.2
> -generated by GNU Autoconf 2.67
> +generated by GNU Autoconf 2.68
> =

>  Copyright (C) 2010 Free Software Foundation, Inc.
>  This configure script is free software; the Free Software Foundation
> @@ -1536,7 +1544,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
> =

>         ac_retval=3D1
>  fi
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_compile
> @@ -1573,7 +1581,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
> =

>      ac_retval=3D1
>  fi
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_cpp
> @@ -1586,10 +1594,10 @@ fi
>  ac_fn_c_check_header_mongrel ()
>  {
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
> -  if eval "test \"\${$3+set}\"" =3D set; then :
> +  if eval \${$3+:} false; then :
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  fi
>  eval ac_res=3D\$$3
> @@ -1656,7 +1664,7 @@ $as_echo "$as_me: WARNING: $2: proceeding with the =
compiler's result" >&2;}
>  esac
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    eval "$3=3D\$ac_header_compiler"
> @@ -1665,7 +1673,7 @@ eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
>  fi
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_header_mongrel
> =

> @@ -1706,7 +1714,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
>         ac_retval=3D$ac_status
>  fi
>    rm -rf conftest.dSYM conftest_ipa8_conftest.oo
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_run
> @@ -1720,7 +1728,7 @@ ac_fn_c_check_header_compile ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -1738,7 +1746,7 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_header_compile
> =

> @@ -1783,11 +1791,65 @@ fi
>    # interfere with the next link command; also delete a directory that is
>    # left behind by Apple's compiler.  We do this before executing the ac=
tions.
>    rm -rf conftest.dSYM conftest_ipa8_conftest.oo
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_link
> =

> +# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
> +# -------------------------------------------
> +# Tests whether TYPE exists after having included INCLUDES, setting cache
> +# variable VAR accordingly.
> +ac_fn_c_check_type ()
> +{
> +  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
> +$as_echo_n "checking for $2... " >&6; }
> +if eval \${$3+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  eval "$3=3Dno"
> +  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +$4
> +int
> +main ()
> +{
> +if (sizeof ($2))
> +        return 0;
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_c_try_compile "$LINENO"; then :
> +  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +$4
> +int
> +main ()
> +{
> +if (sizeof (($2)))
> +           return 0;
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_c_try_compile "$LINENO"; then :
> +
> +else
> +  eval "$3=3Dyes"
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +fi
> +eval ac_res=3D\$$3
> +              { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
> +$as_echo "$ac_res" >&6; }
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> +
> +} # ac_fn_c_check_type
> +
>  # ac_fn_c_check_func LINENO FUNC VAR
>  # ----------------------------------
>  # Tests whether FUNC exists, setting the cache variable VAR accordingly
> @@ -1796,7 +1858,7 @@ ac_fn_c_check_func ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -1851,64 +1913,10 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_func
> =

> -# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
> -# -------------------------------------------
> -# Tests whether TYPE exists after having included INCLUDES, setting cache
> -# variable VAR accordingly.
> -ac_fn_c_check_type ()
> -{
> -  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
> -  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
> -$as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> -  $as_echo_n "(cached) " >&6
> -else
> -  eval "$3=3Dno"
> -  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> -/* end confdefs.h.  */
> -$4
> -int
> -main ()
> -{
> -if (sizeof ($2))
> -        return 0;
> -  ;
> -  return 0;
> -}
> -_ACEOF
> -if ac_fn_c_try_compile "$LINENO"; then :
> -  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> -/* end confdefs.h.  */
> -$4
> -int
> -main ()
> -{
> -if (sizeof (($2)))
> -           return 0;
> -  ;
> -  return 0;
> -}
> -_ACEOF
> -if ac_fn_c_try_compile "$LINENO"; then :
> -
> -else
> -  eval "$3=3Dyes"
> -fi
> -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> -fi
> -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> -fi
> -eval ac_res=3D\$$3
> -              { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
> -$as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> -
> -} # ac_fn_c_check_type
> -
>  # ac_fn_c_find_intX_t LINENO BITS VAR
>  # -----------------------------------
>  # Finds a signed integer type with width BITS, setting cache variable VAR
> @@ -1918,7 +1926,7 @@ ac_fn_c_find_intX_t ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
>  $as_echo_n "checking for int$2_t... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    eval "$3=3Dno"
> @@ -1979,7 +1987,7 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_find_intX_t
> =

> @@ -1992,7 +2000,7 @@ ac_fn_c_check_member ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
>  $as_echo_n "checking for $2.$3... " >&6; }
> -if eval "test \"\${$4+set}\"" =3D set; then :
> +if eval \${$4+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -2036,7 +2044,7 @@ fi
>  eval ac_res=3D\$$4
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_member
> =

> @@ -2049,7 +2057,7 @@ ac_fn_c_find_uintX_t ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
>  $as_echo_n "checking for uint$2_t... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    eval "$3=3Dno"
> @@ -2089,7 +2097,7 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_find_uintX_t
>  cat >config.log <<_ACEOF
> @@ -2097,7 +2105,7 @@ This file contains any messages produced by compile=
rs while
>  running configure, to aid debugging if configure makes a mistake.
> =

>  It was created by Xen Hypervisor $as_me 4.2, which was
> -generated by GNU Autoconf 2.67.  Invocation command line was
> +generated by GNU Autoconf 2.68.  Invocation command line was
> =

>    $ $0 $@
> =

> @@ -2355,7 +2363,7 @@ $as_echo "$as_me: loading site script $ac_site_file=
" >&6;}
>        || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd'=
:" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "failed to load site script $ac_site_file
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>    fi
>  done
> =

> @@ -2508,7 +2516,7 @@ if test -n "$ac_tool_prefix"; then
>  set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2548,7 +2556,7 @@ if test -z "$ac_cv_prog_CC"; then
>  set dummy gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -2601,7 +2609,7 @@ if test -z "$CC"; then
>  set dummy ${ac_tool_prefix}cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2641,7 +2649,7 @@ if test -z "$CC"; then
>  set dummy cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2700,7 +2708,7 @@ if test -z "$CC"; then
>  set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2744,7 +2752,7 @@ do
>  set dummy $ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -2799,7 +2807,7 @@ fi
>  test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "no acceptable C compiler found in \$PATH
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
> =

>  # Provide some information about the compiler.
>  $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
> @@ -2914,7 +2922,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
>  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error 77 "C compiler cannot create executables
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  else
>    { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
>  $as_echo "yes" >&6; }
> @@ -2957,7 +2965,7 @@ else
>    { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "cannot compute suffix of executables: cannot compile and=
 link
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  fi
>  rm -f conftest conftest$ac_cv_exeext
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
> @@ -3016,7 +3024,7 @@ $as_echo "$ac_try_echo"; } >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "cannot run C compiled programs.
>  If you meant to cross compile, use \`--host'.
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>      fi
>    fi
>  fi
> @@ -3027,7 +3035,7 @@ rm -f conftest.$ac_ext conftest$ac_cv_exeext confte=
st.out
>  ac_clean_files=3D$ac_clean_files_save
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object f=
iles" >&5
>  $as_echo_n "checking for suffix of object files... " >&6; }
> -if test "${ac_cv_objext+set}" =3D set; then :
> +if ${ac_cv_objext+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3068,7 +3076,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
>  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "cannot compute suffix of object files: cannot compile
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  fi
>  rm -f conftest.$ac_cv_objext conftest.$ac_ext
>  fi
> @@ -3078,7 +3086,7 @@ OBJEXT=3D$ac_cv_objext
>  ac_objext=3D$OBJEXT
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
>  $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
> -if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
> +if ${ac_cv_c_compiler_gnu+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3115,7 +3123,7 @@ ac_test_CFLAGS=3D${CFLAGS+set}
>  ac_save_CFLAGS=3D$CFLAGS
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
>  $as_echo_n "checking whether $CC accepts -g... " >&6; }
> -if test "${ac_cv_prog_cc_g+set}" =3D set; then :
> +if ${ac_cv_prog_cc_g+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_save_c_werror_flag=3D$ac_c_werror_flag
> @@ -3193,7 +3201,7 @@ else
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
>  $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
> -if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
> +if ${ac_cv_prog_cc_c89+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_prog_cc_c89=3Dno
> @@ -3301,7 +3309,7 @@ if test -n "$CPP" && test -d "$CPP"; then
>    CPP=3D
>  fi
>  if test -z "$CPP"; then
> -  if test "${ac_cv_prog_CPP+set}" =3D set; then :
> +  if ${ac_cv_prog_CPP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>        # Double quotes because CPP needs to be expanded
> @@ -3417,7 +3425,7 @@ else
>    { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  fi
> =

>  ac_ext=3Dc
> @@ -3429,7 +3437,7 @@ ac_compiler_gnu=3D$ac_cv_c_compiler_gnu
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles =
long lines and -e" >&5
>  $as_echo_n "checking for grep that handles long lines and -e... " >&6; }
> -if test "${ac_cv_path_GREP+set}" =3D set; then :
> +if ${ac_cv_path_GREP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -z "$GREP"; then
> @@ -3492,7 +3500,7 @@ $as_echo "$ac_cv_path_GREP" >&6; }
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
>  $as_echo_n "checking for egrep... " >&6; }
> -if test "${ac_cv_path_EGREP+set}" =3D set; then :
> +if ${ac_cv_path_EGREP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
> @@ -3559,7 +3567,7 @@ $as_echo "$ac_cv_path_EGREP" >&6; }
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header file=
s" >&5
>  $as_echo_n "checking for ANSI C header files... " >&6; }
> -if test "${ac_cv_header_stdc+set}" =3D set; then :
> +if ${ac_cv_header_stdc+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3688,7 +3696,7 @@ done
> =

> =

>    ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_=
minix_config_h" "$ac_includes_default"
> -if test "x$ac_cv_header_minix_config_h" =3D x""yes; then :
> +if test "x$ac_cv_header_minix_config_h" =3D xyes; then :
>    MINIX=3Dyes
>  else
>    MINIX=3D
> @@ -3710,7 +3718,7 @@ $as_echo "#define _MINIX 1" >>confdefs.h
> =

>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe t=
o define __EXTENSIONS__" >&5
>  $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&=
6; }
> -if test "${ac_cv_safe_to_define___extensions__+set}" =3D set; then :
> +if ${ac_cv_safe_to_define___extensions__+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3753,7 +3761,7 @@ $SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&=
1 ||
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
>  $as_echo_n "checking build system type... " >&6; }
> -if test "${ac_cv_build+set}" =3D set; then :
> +if ${ac_cv_build+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_build_alias=3D$build_alias
> @@ -3769,7 +3777,7 @@ fi
>  $as_echo "$ac_cv_build" >&6; }
>  case $ac_cv_build in
>  *-*-*) ;;
> -*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
> +*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
>  esac
>  build=3D$ac_cv_build
>  ac_save_IFS=3D$IFS; IFS=3D'-'
> @@ -3787,7 +3795,7 @@ case $build_os in *\ *) build_os=3D`echo "$build_os=
" | sed 's/ /-/g'`;; esac
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
>  $as_echo_n "checking host system type... " >&6; }
> -if test "${ac_cv_host+set}" =3D set; then :
> +if ${ac_cv_host+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "x$host_alias" =3D x; then
> @@ -3802,7 +3810,7 @@ fi
>  $as_echo "$ac_cv_host" >&6; }
>  case $ac_cv_host in
>  *-*-*) ;;
> -*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
> +*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
>  esac
>  host=3D$ac_cv_host
>  ac_save_IFS=3D$IFS; IFS=3D'-'
> @@ -4196,7 +4204,7 @@ LDFLAGS=3D"$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAG=
S"
>  # Checks for programs.
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does no=
t truncate output" >&5
>  $as_echo_n "checking for a sed that does not truncate output... " >&6; }
> -if test "${ac_cv_path_SED+set}" =3D set; then :
> +if ${ac_cv_path_SED+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>              ac_script=3Ds/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbb=
bbbbbbbbbbbbbbbbbbbbbbb/
> @@ -4273,7 +4281,7 @@ if test -n "$ac_tool_prefix"; then
>  set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4313,7 +4321,7 @@ if test -z "$ac_cv_prog_CC"; then
>  set dummy gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -4366,7 +4374,7 @@ if test -z "$CC"; then
>  set dummy ${ac_tool_prefix}cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4406,7 +4414,7 @@ if test -z "$CC"; then
>  set dummy cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4465,7 +4473,7 @@ if test -z "$CC"; then
>  set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4509,7 +4517,7 @@ do
>  set dummy $ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -4564,7 +4572,7 @@ fi
>  test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "no acceptable C compiler found in \$PATH
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
> =

>  # Provide some information about the compiler.
>  $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
> @@ -4593,7 +4601,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
>  $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
> -if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
> +if ${ac_cv_c_compiler_gnu+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -4630,7 +4638,7 @@ ac_test_CFLAGS=3D${CFLAGS+set}
>  ac_save_CFLAGS=3D$CFLAGS
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
>  $as_echo_n "checking whether $CC accepts -g... " >&6; }
> -if test "${ac_cv_prog_cc_g+set}" =3D set; then :
> +if ${ac_cv_prog_cc_g+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_save_c_werror_flag=3D$ac_c_werror_flag
> @@ -4708,7 +4716,7 @@ else
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
>  $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
> -if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
> +if ${ac_cv_prog_cc_c89+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_prog_cc_c89=3Dno
> @@ -4818,7 +4826,7 @@ fi
>  $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
>  set x ${MAKE-make}
>  ac_make=3D`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
> -if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" =3D set; then :
> +if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat >conftest.make <<\_ACEOF
> @@ -4862,7 +4870,7 @@ fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible i=
nstall" >&5
>  $as_echo_n "checking for a BSD-compatible install... " >&6; }
>  if test -z "$INSTALL"; then
> -if test "${ac_cv_path_install+set}" =3D set; then :
> +if ${ac_cv_path_install+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> @@ -4942,7 +4950,7 @@ test -z "$INSTALL_DATA" && INSTALL_DATA=3D'${INSTAL=
L} -m 644'
>  set dummy perl; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_PERL+set}" =3D set; then :
> +if ${ac_cv_path_PERL+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $PERL in
> @@ -4989,7 +4997,7 @@ if test "x$xapi" =3D "xy"; then :
>  set dummy curl-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_CURL+set}" =3D set; then :
> +if ${ac_cv_path_CURL+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $CURL in
> @@ -5034,7 +5042,7 @@ fi
>  set dummy xml2-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_XML+set}" =3D set; then :
> +if ${ac_cv_path_XML+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $XML in
> @@ -5085,7 +5093,7 @@ if test "x$ocamltools" =3D "xy"; then :
>  set dummy ${ac_tool_prefix}ocamlc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLC+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLC"; then
> @@ -5125,7 +5133,7 @@ if test -z "$ac_cv_prog_OCAMLC"; then
>  set dummy ocamlc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLC"; then
> @@ -5196,7 +5204,7 @@ $as_echo "OCaml library path is $OCAMLLIB" >&6; }
>  set dummy ${ac_tool_prefix}ocamlopt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLOPT+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLOPT"; then
> @@ -5236,7 +5244,7 @@ if test -z "$ac_cv_prog_OCAMLOPT"; then
>  set dummy ocamlopt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLOPT"; then
> @@ -5306,7 +5314,7 @@ $as_echo "versions differs from ocamlc; ocamlopt di=
scarded." >&6; }
>  set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLCDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLCDOTOPT"; then
> @@ -5346,7 +5354,7 @@ if test -z "$ac_cv_prog_OCAMLCDOTOPT"; then
>  set dummy ocamlc.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLCDOTOPT"; then
> @@ -5410,7 +5418,7 @@ $as_echo "versions differs from ocamlc; ocamlc.opt =
discarded." >&6; }
>  set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLOPTDOTOPT"; then
> @@ -5450,7 +5458,7 @@ if test -z "$ac_cv_prog_OCAMLOPTDOTOPT"; then
>  set dummy ocamlopt.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
> @@ -5519,7 +5527,7 @@ $as_echo "version differs from ocamlc; ocamlopt.opt=
 discarded." >&6; }
>  set dummy ${ac_tool_prefix}ocaml; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAML+set}" =3D set; then :
> +if ${ac_cv_prog_OCAML+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAML"; then
> @@ -5559,7 +5567,7 @@ if test -z "$ac_cv_prog_OCAML"; then
>  set dummy ocaml; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAML+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAML"; then
> @@ -5613,7 +5621,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamldep; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLDEP+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLDEP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLDEP"; then
> @@ -5653,7 +5661,7 @@ if test -z "$ac_cv_prog_OCAMLDEP"; then
>  set dummy ocamldep; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLDEP"; then
> @@ -5707,7 +5715,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamlmktop; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLMKTOP+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLMKTOP"; then
> @@ -5747,7 +5755,7 @@ if test -z "$ac_cv_prog_OCAMLMKTOP"; then
>  set dummy ocamlmktop; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLMKTOP"; then
> @@ -5801,7 +5809,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamlmklib; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLMKLIB+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLMKLIB"; then
> @@ -5841,7 +5849,7 @@ if test -z "$ac_cv_prog_OCAMLMKLIB"; then
>  set dummy ocamlmklib; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLMKLIB"; then
> @@ -5895,7 +5903,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamldoc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLDOC+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLDOC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLDOC"; then
> @@ -5935,7 +5943,7 @@ if test -z "$ac_cv_prog_OCAMLDOC"; then
>  set dummy ocamldoc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLDOC"; then
> @@ -5989,7 +5997,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamlbuild; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLBUILD+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLBUILD+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLBUILD"; then
> @@ -6029,7 +6037,7 @@ if test -z "$ac_cv_prog_OCAMLBUILD"; then
>  set dummy ocamlbuild; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLBUILD"; then
> @@ -6092,7 +6100,7 @@ fi
>  set dummy bash; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_BASH+set}" =3D set; then :
> +if ${ac_cv_path_BASH+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $BASH in
> @@ -6149,7 +6157,7 @@ fi
>  set dummy $PYTHON; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_PYTHONPATH+set}" =3D set; then :
> +if ${ac_cv_path_PYTHONPATH+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $PYTHONPATH in
> @@ -6225,7 +6233,7 @@ LDFLAGS=3D"$LDFLAGS `$PYTHON -c 'import distutils.s=
ysconfig; \
>      print distutils.sysconfig.get_config_var("LDFLAGS")'`"
> =

>  ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h=
" "$ac_includes_default"
> -if test "x$ac_cv_header_Python_h" =3D x""yes; then :
> +if test "x$ac_cv_header_Python_h" =3D xyes; then :
> =

>  else
>    as_fn_error $? "Unable to find Python development headers" "$LINENO" 5
> @@ -6235,7 +6243,7 @@ fi
>  as_ac_Lib=3D`$as_echo "ac_cv_lib_python$ac_python_version''_PyArg_ParseT=
uple" | $as_tr_sh`
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PyArg_ParseTuple i=
n -lpython$ac_python_version" >&5
>  $as_echo_n "checking for PyArg_ParseTuple in -lpython$ac_python_version.=
.. " >&6; }
> -if eval "test \"\${$as_ac_Lib+set}\"" =3D set; then :
> +if eval \${$as_ac_Lib+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6290,7 +6298,7 @@ fi
>  set dummy xgettext; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_XGETTEXT+set}" =3D set; then :
> +if ${ac_cv_path_XGETTEXT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $XGETTEXT in
> @@ -6335,7 +6343,7 @@ fi
>  set dummy as86; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_AS86+set}" =3D set; then :
> +if ${ac_cv_path_AS86+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $AS86 in
> @@ -6380,7 +6388,7 @@ fi
>  set dummy ld86; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_LD86+set}" =3D set; then :
> +if ${ac_cv_path_LD86+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $LD86 in
> @@ -6425,7 +6433,7 @@ fi
>  set dummy bcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_BCC+set}" =3D set; then :
> +if ${ac_cv_path_BCC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $BCC in
> @@ -6470,7 +6478,7 @@ fi
>  set dummy iasl; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_IASL+set}" =3D set; then :
> +if ${ac_cv_path_IASL+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $IASL in
> @@ -6511,13 +6519,58 @@ if test x"${IASL}" =3D=3D x"no"
>  then
>      as_fn_error $? "Unable to find iasl, please install iasl" "$LINENO" 5
>  fi
> +# Extract the first word of "flex", so it can be a program name with arg=
s.
> +set dummy flex; ac_word=3D$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_path_FLEX+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  case $FLEX in
> +  [\\/]* | ?:[\\/]*)
> +  ac_cv_path_FLEX=3D"$FLEX" # Let the user override the test with a path.
> +  ;;
> +  *)
> +  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> +  IFS=3D$as_save_IFS
> +  test -z "$as_dir" && as_dir=3D.
> +    for ac_exec_ext in '' $ac_executable_extensions; do
> +  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac=
_word$ac_exec_ext"; }; then
> +    ac_cv_path_FLEX=3D"$as_dir/$ac_word$ac_exec_ext"
> +    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exe=
c_ext" >&5
> +    break 2
> +  fi
> +done
> +  done
> +IFS=3D$as_save_IFS
> +
> +  test -z "$ac_cv_path_FLEX" && ac_cv_path_FLEX=3D"no"
> +  ;;
> +esac
> +fi
> +FLEX=3D$ac_cv_path_FLEX
> +if test -n "$FLEX"; then
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $FLEX" >&5
> +$as_echo "$FLEX" >&6; }
> +else
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +
> +if test x"${FLEX}" =3D=3D x"no"
> +then
> +    as_fn_error $? "Unable to find flex, please install flex" "$LINENO" 5
> +fi
> =

>  ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_=
uuid_h" "$ac_includes_default"
> -if test "x$ac_cv_header_uuid_uuid_h" =3D x""yes; then :
> +if test "x$ac_cv_header_uuid_uuid_h" =3D xyes; then :
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in =
-luuid" >&5
>  $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
> -if test "${ac_cv_lib_uuid_uuid_clear+set}" =3D set; then :
> +if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6551,7 +6604,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_cl=
ear" >&5
>  $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
> -if test "x$ac_cv_lib_uuid_uuid_clear" =3D x""yes; then :
> +if test "x$ac_cv_lib_uuid_uuid_clear" =3D xyes; then :
>    libuuid=3D"y"
>  fi
> =

> @@ -6560,7 +6613,7 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$=
ac_includes_default"
> -if test "x$ac_cv_header_uuid_h" =3D x""yes; then :
> +if test "x$ac_cv_header_uuid_h" =3D xyes; then :
>    libuuid=3D"y"
>  fi
> =

> @@ -6573,11 +6626,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h=
" "$ac_includes_default"
> -if test "x$ac_cv_header_curses_h" =3D x""yes; then :
> +if test "x$ac_cv_header_curses_h" =3D xyes; then :
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcur=
ses" >&5
>  $as_echo_n "checking for clear in -lcurses... " >&6; }
> -if test "${ac_cv_lib_curses_clear+set}" =3D set; then :
> +if ${ac_cv_lib_curses_clear+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6611,7 +6664,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear=
" >&5
>  $as_echo "$ac_cv_lib_curses_clear" >&6; }
> -if test "x$ac_cv_lib_curses_clear" =3D x""yes; then :
> +if test "x$ac_cv_lib_curses_clear" =3D xyes; then :
>    curses=3D"y"
>  else
>    curses=3D"n"
> @@ -6624,11 +6677,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses=
_h" "$ac_includes_default"
> -if test "x$ac_cv_header_ncurses_h" =3D x""yes; then :
> +if test "x$ac_cv_header_ncurses_h" =3D xyes; then :
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncu=
rses" >&5
>  $as_echo_n "checking for clear in -lncurses... " >&6; }
> -if test "${ac_cv_lib_ncurses_clear+set}" =3D set; then :
> +if ${ac_cv_lib_ncurses_clear+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6662,7 +6715,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clea=
r" >&5
>  $as_echo "$ac_cv_lib_ncurses_clear" >&6; }
> -if test "x$ac_cv_lib_ncurses_clear" =3D x""yes; then :
> +if test "x$ac_cv_lib_ncurses_clear" =3D xyes; then :
>    ncurses=3D"y"
>  else
>    ncurses=3D"n"
> @@ -6709,7 +6762,7 @@ if test "x$ac_cv_env_PKG_CONFIG_set" !=3D "xset"; t=
hen
>  set dummy ${ac_tool_prefix}pkg-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_PKG_CONFIG+set}" =3D set; then :
> +if ${ac_cv_path_PKG_CONFIG+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $PKG_CONFIG in
> @@ -6752,7 +6805,7 @@ if test -z "$ac_cv_path_PKG_CONFIG"; then
>  set dummy pkg-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" =3D set; then :
> +if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $ac_pt_PKG_CONFIG in
> @@ -6897,7 +6950,7 @@ and glib_LIBS to avoid the need to call pkg-config.
>  See the pkg-config man page for more details.
> =

>  To get pkg-config, see <http://pkg-config.freedesktop.org/>.
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  else
>         glib_CFLAGS=3D$pkg_cv_glib_CFLAGS
>         glib_LIBS=3D$pkg_cv_glib_LIBS
> @@ -6933,11 +6986,11 @@ fi
> =

>  # Checks for libraries.
>  ac_fn_c_check_header_mongrel "$LINENO" "bzlib.h" "ac_cv_header_bzlib_h" =
"$ac_includes_default"
> -if test "x$ac_cv_header_bzlib_h" =3D x""yes; then :
> +if test "x$ac_cv_header_bzlib_h" =3D xyes; then :
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for BZ2_bzDecompressIn=
it in -lbz2" >&5
>  $as_echo_n "checking for BZ2_bzDecompressInit in -lbz2... " >&6; }
> -if test "${ac_cv_lib_bz2_BZ2_bzDecompressInit+set}" =3D set; then :
> +if ${ac_cv_lib_bz2_BZ2_bzDecompressInit+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6971,7 +7024,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_bz2_BZ2_bzDe=
compressInit" >&5
>  $as_echo "$ac_cv_lib_bz2_BZ2_bzDecompressInit" >&6; }
> -if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D x""yes; then :
> +if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D xyes; then :
>    zlib=3D"$zlib -DHAVE_BZLIB -lbz2"
>  fi
> =

> @@ -6980,11 +7033,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "lzma.h" "ac_cv_header_lzma_h" "$=
ac_includes_default"
> -if test "x$ac_cv_header_lzma_h" =3D x""yes; then :
> +if test "x$ac_cv_header_lzma_h" =3D xyes; then :
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzma_stream_decode=
r in -llzma" >&5
>  $as_echo_n "checking for lzma_stream_decoder in -llzma... " >&6; }
> -if test "${ac_cv_lib_lzma_lzma_stream_decoder+set}" =3D set; then :
> +if ${ac_cv_lib_lzma_lzma_stream_decoder+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7018,7 +7071,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzma_lzma_st=
ream_decoder" >&5
>  $as_echo "$ac_cv_lib_lzma_lzma_stream_decoder" >&6; }
> -if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D x""yes; then :
> +if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D xyes; then :
>    zlib=3D"$zlib -DHAVE_LZMA -llzma"
>  fi
> =

> @@ -7027,11 +7080,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "lzo/lzo1x.h" "ac_cv_header_lzo_l=
zo1x_h" "$ac_includes_default"
> -if test "x$ac_cv_header_lzo_lzo1x_h" =3D x""yes; then :
> +if test "x$ac_cv_header_lzo_lzo1x_h" =3D xyes; then :
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzo1x_decompress i=
n -llzo2" >&5
>  $as_echo_n "checking for lzo1x_decompress in -llzo2... " >&6; }
> -if test "${ac_cv_lib_lzo2_lzo1x_decompress+set}" =3D set; then :
> +if ${ac_cv_lib_lzo2_lzo1x_decompress+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7065,7 +7118,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzo2_lzo1x_d=
ecompress" >&5
>  $as_echo "$ac_cv_lib_lzo2_lzo1x_decompress" >&6; }
> -if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D x""yes; then :
> +if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D xyes; then :
>    zlib=3D"$zlib -DHAVE_LZO1X -llzo2"
>  fi
> =

> @@ -7076,7 +7129,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio"=
 >&5
>  $as_echo_n "checking for io_setup in -laio... " >&6; }
> -if test "${ac_cv_lib_aio_io_setup+set}" =3D set; then :
> +if ${ac_cv_lib_aio_io_setup+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7110,7 +7163,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup=
" >&5
>  $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
> -if test "x$ac_cv_lib_aio_io_setup" =3D x""yes; then :
> +if test "x$ac_cv_lib_aio_io_setup" =3D xyes; then :
>    system_aio=3D"y"
>  else
>    system_aio=3D"n"
> @@ -7119,7 +7172,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >=
&5
>  $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
> -if test "${ac_cv_lib_crypto_MD5+set}" =3D set; then :
> +if ${ac_cv_lib_crypto_MD5+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7153,7 +7206,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" =
>&5
>  $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
> -if test "x$ac_cv_lib_crypto_MD5" =3D x""yes; then :
> +if test "x$ac_cv_lib_crypto_MD5" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBCRYPTO 1
>  _ACEOF
> @@ -7166,7 +7219,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -l=
ext2fs" >&5
>  $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
> -if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" =3D set; then :
> +if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7200,7 +7253,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2f=
s_open2" >&5
>  $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
> -if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D x""yes; then :
> +if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D xyes; then :
>    libext2fs=3D"y"
>  else
>    libext2fs=3D"n"
> @@ -7209,7 +7262,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffe=
r in -lgcrypt" >&5
>  $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
> -if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" =3D set; then :
> +if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7243,7 +7296,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_=
md_hash_buffer" >&5
>  $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
> -if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D x""yes; then :
> +if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D xyes; then :
>    libgcrypt=3D"y"
>  else
>    libgcrypt=3D"n"
> @@ -7253,7 +7306,7 @@ fi
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" =
>&5
>  $as_echo_n "checking for pthread flag... " >&6; }
> -if test "${ax_cv_pthread_flags+set}" =3D set; then :
> +if ${ax_cv_pthread_flags+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
> =

> @@ -7317,7 +7370,7 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -=
lrt" >&5
>  $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
> -if test "${ac_cv_lib_rt_clock_gettime+set}" =3D set; then :
> +if ${ac_cv_lib_rt_clock_gettime+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7351,7 +7404,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_get=
time" >&5
>  $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
> -if test "x$ac_cv_lib_rt_clock_gettime" =3D x""yes; then :
> +if test "x$ac_cv_lib_rt_clock_gettime" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBRT 1
>  _ACEOF
> @@ -7362,7 +7415,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lya=
jl" >&5
>  $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
> -if test "${ac_cv_lib_yajl_yajl_alloc+set}" =3D set; then :
> +if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7396,7 +7449,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_al=
loc" >&5
>  $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
> -if test "x$ac_cv_lib_yajl_yajl_alloc" =3D x""yes; then :
> +if test "x$ac_cv_lib_yajl_yajl_alloc" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBYAJL 1
>  _ACEOF
> @@ -7409,7 +7462,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz=
" >&5
>  $as_echo_n "checking for deflateCopy in -lz... " >&6; }
> -if test "${ac_cv_lib_z_deflateCopy+set}" =3D set; then :
> +if ${ac_cv_lib_z_deflateCopy+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7443,7 +7496,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCop=
y" >&5
>  $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
> -if test "x$ac_cv_lib_z_deflateCopy" =3D x""yes; then :
> +if test "x$ac_cv_lib_z_deflateCopy" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBZ 1
>  _ACEOF
> @@ -7456,7 +7509,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -=
liconv" >&5
>  $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
> -if test "${ac_cv_lib_iconv_libiconv_open+set}" =3D set; then :
> +if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7490,7 +7543,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libico=
nv_open" >&5
>  $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
> -if test "x$ac_cv_lib_iconv_libiconv_open" =3D x""yes; then :
> +if test "x$ac_cv_lib_iconv_libiconv_open" =3D xyes; then :
>    libiconv=3D"y"
>  else
>    libiconv=3D"n"
> @@ -7499,11 +7552,22 @@ fi
> =

> =

>  # Checks for header files.
> +ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
> +if test "x$ac_cv_type_size_t" =3D xyes; then :
> +
> +else
> +
> +cat >>confdefs.h <<_ACEOF
> +#define size_t unsigned int
> +_ACEOF
> +
> +fi
> +
>  # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
>  # for constant arguments.  Useless!
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" =
>&5
>  $as_echo_n "checking for working alloca.h... " >&6; }
> -if test "${ac_cv_working_alloca_h+set}" =3D set; then :
> +if ${ac_cv_working_alloca_h+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7536,7 +7600,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
>  $as_echo_n "checking for alloca... " >&6; }
> -if test "${ac_cv_func_alloca_works+set}" =3D set; then :
> +if ${ac_cv_func_alloca_works+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7555,7 +7619,7 @@ else
>   #pragma alloca
>  #   else
>  #    ifndef alloca /* predefined by HP cc +Olibcalls */
> -char *alloca ();
> +void *alloca (size_t);
>  #    endif
>  #   endif
>  #  endif
> @@ -7599,7 +7663,7 @@ $as_echo "#define C_ALLOCA 1" >>confdefs.h
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' ne=
eds Cray hooks" >&5
>  $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
> -if test "${ac_cv_os_cray+set}" =3D set; then :
> +if ${ac_cv_os_cray+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7640,7 +7704,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C =
alloca" >&5
>  $as_echo_n "checking stack direction for C alloca... " >&6; }
> -if test "${ac_cv_c_stack_direction+set}" =3D set; then :
> +if ${ac_cv_c_stack_direction+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -7711,7 +7775,7 @@ done
>  # Checks for typedefs, structures, and compiler characteristics.
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that con=
forms to C99" >&5
>  $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
> -if test "${ac_cv_header_stdbool_h+set}" =3D set; then :
> +if ${ac_cv_header_stdbool_h+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7743,7 +7807,7 @@ else
>         char b[false =3D=3D 0 ? 1 : -1];
>         char c[__bool_true_false_are_defined =3D=3D 1 ? 1 : -1];
>         char d[(bool) 0.5 =3D=3D true ? 1 : -1];
> -       bool e =3D &s;
> +       /* See body of main program for 'e'.  */
>         char f[(_Bool) 0.0 =3D=3D false ? 1 : -1];
>         char g[true];
>         char h[sizeof (_Bool)];
> @@ -7754,25 +7818,6 @@ else
>         _Bool n[m];
>         char o[sizeof n =3D=3D m * sizeof n[0] ? 1 : -1];
>         char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
> -#      if defined __xlc__ || defined __GNUC__
> -        /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
> -           reported by James Lemley on 2005-10-05; see
> -           http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00=
086.html
> -           This test is not quite right, since xlc is allowed to
> -           reject this program, as the initializer for xlcbug is
> -           not one of the forms that C requires support for.
> -           However, doing the test right would require a runtime
> -           test, and that would make cross-compilation harder.
> -           Let us hope that IBM fixes the xlc bug, and also adds
> -           support for this kind of constant expression.  In the
> -           meantime, this test will reject xlc, which is OK, since
> -           our stdbool.h substitute should suffice.  We also test
> -           this with GCC, where it should work, to detect more
> -           quickly whether someone messes up the test in the
> -           future.  */
> -        char digs[] =3D "0123456789";
> -        int xlcbug =3D 1 / (&(digs + 5)[-2 + (bool) 1] =3D=3D &digs[4] ?=
 1 : -1);
> -#      endif
>         /* Catch a bug in an HP-UX C compiler.  See
>            http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
>            http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg001=
61.html
> @@ -7784,6 +7829,7 @@ int
>  main ()
>  {
> =

> +       bool e =3D &s;
>         *pq |=3D q;
>         *pq |=3D ! q;
>         /* Refer to every declared value, to avoid compiler optimizations=
.  */
> @@ -7804,7 +7850,7 @@ fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h=
" >&5
>  $as_echo "$ac_cv_header_stdbool_h" >&6; }
>  ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_de=
fault"
> -if test "x$ac_cv_type__Bool" =3D x""yes; then :
> +if test "x$ac_cv_type__Bool" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE__BOOL 1
> @@ -7821,7 +7867,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types=
.h" >&5
>  $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
> -if test "${ac_cv_type_uid_t+set}" =3D set; then :
> +if ${ac_cv_type_uid_t+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7851,7 +7897,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
>  $as_echo_n "checking for inline... " >&6; }
> -if test "${ac_cv_c_inline+set}" =3D set; then :
> +if ${ac_cv_c_inline+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_c_inline=3Dno
> @@ -7936,7 +7982,7 @@ _ACEOF
>  esac
> =

>  ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_=
default"
> -if test "x$ac_cv_type_mode_t" =3D x""yes; then :
> +if test "x$ac_cv_type_mode_t" =3D xyes; then :
> =

>  else
> =

> @@ -7947,7 +7993,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_de=
fault"
> -if test "x$ac_cv_type_off_t" =3D x""yes; then :
> +if test "x$ac_cv_type_off_t" =3D xyes; then :
> =

>  else
> =

> @@ -7958,7 +8004,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_de=
fault"
> -if test "x$ac_cv_type_pid_t" =3D x""yes; then :
> +if test "x$ac_cv_type_pid_t" =3D xyes; then :
> =

>  else
> =

> @@ -7970,7 +8016,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict key=
word" >&5
>  $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
> -if test "${ac_cv_c_restrict+set}" =3D set; then :
> +if ${ac_cv_c_restrict+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_c_restrict=3Dno
> @@ -8015,7 +8061,7 @@ _ACEOF
>   esac
> =

>  ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
> -if test "x$ac_cv_type_size_t" =3D x""yes; then :
> +if test "x$ac_cv_type_size_t" =3D xyes; then :
> =

>  else
> =

> @@ -8026,7 +8072,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_include=
s_default"
> -if test "x$ac_cv_type_ssize_t" =3D x""yes; then :
> +if test "x$ac_cv_type_ssize_t" =3D xyes; then :
> =

>  else
> =

> @@ -8037,7 +8083,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_=
struct_stat_st_blksize" "$ac_includes_default"
> -if test "x$ac_cv_member_struct_stat_st_blksize" =3D x""yes; then :
> +if test "x$ac_cv_member_struct_stat_st_blksize" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
> @@ -8047,7 +8093,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_s=
truct_stat_st_blocks" "$ac_includes_default"
> -if test "x$ac_cv_member_struct_stat_st_blocks" =3D x""yes; then :
> +if test "x$ac_cv_member_struct_stat_st_blocks" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_STRUCT_STAT_ST_BLOCKS 1
> @@ -8067,7 +8113,7 @@ fi
> =

> =

>  ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_str=
uct_stat_st_rdev" "$ac_includes_default"
> -if test "x$ac_cv_member_struct_stat_st_rdev" =3D x""yes; then :
> +if test "x$ac_cv_member_struct_stat_st_rdev" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_STRUCT_STAT_ST_RDEV 1
> @@ -8131,7 +8177,7 @@ _ACEOF
>    esac
> =

>  ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_inc=
ludes_default"
> -if test "x$ac_cv_type_ptrdiff_t" =3D x""yes; then :
> +if test "x$ac_cv_type_ptrdiff_t" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_PTRDIFF_T 1
> @@ -8144,7 +8190,7 @@ fi
>  # Checks for library functions.
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5
>  $as_echo_n "checking for error_at_line... " >&6; }
> -if test "${ac_cv_lib_error_at_line+set}" =3D set; then :
> +if ${ac_cv_lib_error_at_line+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -8180,7 +8226,7 @@ fi
>  for ac_header in vfork.h
>  do :
>    ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h=
" "$ac_includes_default"
> -if test "x$ac_cv_header_vfork_h" =3D x""yes; then :
> +if test "x$ac_cv_header_vfork_h" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_VFORK_H 1
>  _ACEOF
> @@ -8204,7 +8250,7 @@ done
>  if test "x$ac_cv_func_fork" =3D xyes; then
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&5
>  $as_echo_n "checking for working fork... " >&6; }
> -if test "${ac_cv_func_fork_works+set}" =3D set; then :
> +if ${ac_cv_func_fork_works+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8257,7 +8303,7 @@ ac_cv_func_vfork_works=3D$ac_cv_func_vfork
>  if test "x$ac_cv_func_vfork" =3D xyes; then
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >=
&5
>  $as_echo_n "checking for working vfork... " >&6; }
> -if test "${ac_cv_func_vfork_works+set}" =3D set; then :
> +if ${ac_cv_func_vfork_works+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8392,7 +8438,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE =
value needed for large files" >&5
>  $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files.=
.. " >&6; }
> -if test "${ac_cv_sys_largefile_source+set}" =3D set; then :
> +if ${ac_cv_sys_largefile_source+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    while :; do
> @@ -8460,7 +8506,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctl=
y handles trailing slash" >&5
>  $as_echo_n "checking whether lstat correctly handles trailing slash... "=
 >&6; }
> -if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" =3D set; =
then :
> +if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    rm -f conftest.sym conftest.file
> @@ -8522,7 +8568,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h de=
fines makedev" >&5
>  $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
> -if test "${ac_cv_header_sys_types_h_makedev+set}" =3D set; then :
> +if ${ac_cv_header_sys_types_h_makedev+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -8550,7 +8596,7 @@ $as_echo "$ac_cv_header_sys_types_h_makedev" >&6; }
> =

>  if test $ac_cv_header_sys_types_h_makedev =3D no; then
>  ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_m=
kdev_h" "$ac_includes_default"
> -if test "x$ac_cv_header_sys_mkdev_h" =3D x""yes; then :
> +if test "x$ac_cv_header_sys_mkdev_h" =3D xyes; then :
> =

>  $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
> =

> @@ -8560,7 +8606,7 @@ fi
> =

>    if test $ac_cv_header_sys_mkdev_h =3D no; then
>      ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_head=
er_sys_sysmacros_h" "$ac_includes_default"
> -if test "x$ac_cv_header_sys_sysmacros_h" =3D x""yes; then :
> +if test "x$ac_cv_header_sys_sysmacros_h" =3D xyes; then :
> =

>  $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
> =

> @@ -8573,7 +8619,7 @@ fi
>  for ac_header in stdlib.h
>  do :
>    ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
> -if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
> +if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_STDLIB_H 1
>  _ACEOF
> @@ -8584,7 +8630,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e malloc" >&5
>  $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
> -if test "${ac_cv_func_malloc_0_nonnull+set}" =3D set; then :
> +if ${ac_cv_func_malloc_0_nonnull+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8639,7 +8685,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys=
/time.h may both be included" >&5
>  $as_echo_n "checking whether time.h and sys/time.h may both be included.=
.. " >&6; }
> -if test "${ac_cv_header_time+set}" =3D set; then :
> +if ${ac_cv_header_time+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -8714,7 +8760,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&5
>  $as_echo_n "checking for working mktime... " >&6; }
> -if test "${ac_cv_func_working_mktime+set}" =3D set; then :
> +if ${ac_cv_func_working_mktime+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8943,7 +8989,7 @@ fi
>  for ac_func in getpagesize
>  do :
>    ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
> -if test "x$ac_cv_func_getpagesize" =3D x""yes; then :
> +if test "x$ac_cv_func_getpagesize" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_GETPAGESIZE 1
>  _ACEOF
> @@ -8953,7 +8999,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
>  $as_echo_n "checking for working mmap... " >&6; }
> -if test "${ac_cv_func_mmap_fixed_mapped+set}" =3D set; then :
> +if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -9120,7 +9166,7 @@ rm -f conftest.mmap conftest.txt
>  for ac_header in stdlib.h
>  do :
>    ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
> -if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
> +if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_STDLIB_H 1
>  _ACEOF
> @@ -9131,7 +9177,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e realloc" >&5
>  $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
> -if test "${ac_cv_func_realloc_0_nonnull+set}" =3D set; then :
> +if ${ac_cv_func_realloc_0_nonnull+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -9184,13 +9230,17 @@ $as_echo "#define realloc rpl_realloc" >>confdefs=
.h
>  fi
> =

> =

> -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >=
&5
> + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" =
>&5
>  $as_echo_n "checking for working strnlen... " >&6; }
> -if test "${ac_cv_func_strnlen_working+set}" =3D set; then :
> +if ${ac_cv_func_strnlen_working+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> -  ac_cv_func_strnlen_working=3Dno
> +  # Guess no on AIX systems, yes otherwise.
> +               case "$host_os" in
> +                 aix*) ac_cv_func_strnlen_working=3Dno;;
> +                 *)    ac_cv_func_strnlen_working=3Dyes;;
> +               esac
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>  /* end confdefs.h.  */
> @@ -9239,7 +9289,7 @@ esac
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&5
>  $as_echo_n "checking for working strtod... " >&6; }
> -if test "${ac_cv_func_strtod+set}" =3D set; then :
> +if ${ac_cv_func_strtod+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -9298,14 +9348,14 @@ if test $ac_cv_func_strtod =3D no; then
>  esac
> =

>  ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
> -if test "x$ac_cv_func_pow" =3D x""yes; then :
> +if test "x$ac_cv_func_pow" =3D xyes; then :
> =

>  fi
> =

>  if test $ac_cv_func_pow =3D no; then
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
>  $as_echo_n "checking for pow in -lm... " >&6; }
> -if test "${ac_cv_lib_m_pow+set}" =3D set; then :
> +if ${ac_cv_lib_m_pow+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -9339,7 +9389,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
>  $as_echo "$ac_cv_lib_m_pow" >&6; }
> -if test "x$ac_cv_lib_m_pow" =3D x""yes; then :
> +if test "x$ac_cv_lib_m_pow" =3D xyes; then :
>    POW_LIB=3D-lm
>  else
>    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library =
containing definition of pow" >&5
> @@ -9435,10 +9485,21 @@ $as_echo "$as_me: WARNING: cache variable $ac_var=
 contains a newline" >&2;} ;;
>       :end' >>confcache
>  if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
>    if test -w "$cache_file"; then
> -    test "x$cache_file" !=3D "x/dev/null" &&
> +    if test "x$cache_file" !=3D "x/dev/null"; then
>        { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_fil=
e" >&5
>  $as_echo "$as_me: updating cache $cache_file" >&6;}
> -    cat confcache >$cache_file
> +      if test ! -f "$cache_file" || test -h "$cache_file"; then
> +       cat confcache >"$cache_file"
> +      else
> +        case $cache_file in #(
> +        */* | ?:*)
> +         mv -f confcache "$cache_file"$$ &&
> +         mv -f "$cache_file"$$ "$cache_file" ;; #(
> +        *)
> +         mv -f confcache "$cache_file" ;;
> +       esac
> +      fi
> +    fi
>    else
>      { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cac=
he $cache_file" >&5
>  $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
> @@ -9470,7 +9531,7 @@ LTLIBOBJS=3D$ac_ltlibobjs
> =

> =

> =

> -: ${CONFIG_STATUS=3D./config.status}
> +: "${CONFIG_STATUS=3D./config.status}"
>  ac_write_fail=3D0
>  ac_clean_files_save=3D$ac_clean_files
>  ac_clean_files=3D"$ac_clean_files $CONFIG_STATUS"
> @@ -9571,6 +9632,7 @@ fi
>  IFS=3D" ""       $as_nl"
> =

>  # Find who we are.  Look in the path if we contain no directory separato=
r.
> +as_myself=3D
>  case $0 in #((
>    *[\\/]* ) as_myself=3D$0 ;;
>    *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> @@ -9878,7 +9940,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=3D1
>  # values after options handling.
>  ac_log=3D"
>  This file was extended by Xen Hypervisor $as_me 4.2, which was
> -generated by GNU Autoconf 2.67.  Invocation command line was
> +generated by GNU Autoconf 2.68.  Invocation command line was
> =

>    CONFIG_FILES    =3D $CONFIG_FILES
>    CONFIG_HEADERS  =3D $CONFIG_HEADERS
> @@ -9940,7 +10002,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
>  ac_cs_config=3D"`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\=
$]/\\\\&/g'`"
>  ac_cs_version=3D"\\
>  Xen Hypervisor config.status 4.2
> -configured by $0, generated by GNU Autoconf 2.67,
> +configured by $0, generated by GNU Autoconf 2.68,
>    with options \\"\$ac_cs_config\\"
> =

>  Copyright (C) 2010 Free Software Foundation, Inc.
> @@ -10064,7 +10126,7 @@ do
>      "../config/Tools.mk") CONFIG_FILES=3D"$CONFIG_FILES ../config/Tools.=
mk" ;;
>      "config.h") CONFIG_HEADERS=3D"$CONFIG_HEADERS config.h" ;;
> =

> -  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
 ;;
> +  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
;;
>    esac
>  done
> =

> @@ -10086,9 +10148,10 @@ fi
>  # after its creation but before its name has been assigned to `$tmp'.
>  $debug ||
>  {
> -  tmp=3D
> +  tmp=3D ac_tmp=3D
>    trap 'exit_status=3D$?
> -  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit=
_status
> +  : "${ac_tmp:=3D$tmp}"
> +  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
>  ' 0
>    trap 'as_fn_exit 1' 1 2 13 15
>  }
> @@ -10096,12 +10159,13 @@ $debug ||
> =

>  {
>    tmp=3D`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
> -  test -n "$tmp" && test -d "$tmp"
> +  test -d "$tmp"
>  }  ||
>  {
>    tmp=3D./conf$$-$RANDOM
>    (umask 077 && mkdir "$tmp")
>  } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO"=
 5
> +ac_tmp=3D$tmp
> =

>  # Set up the scripts for CONFIG_FILES section.
>  # No need to generate them if there are no CONFIG_FILES.
> @@ -10123,7 +10187,7 @@ else
>    ac_cs_awk_cr=3D$ac_cr
>  fi
> =

> -echo 'BEGIN {' >"$tmp/subs1.awk" &&
> +echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
>  _ACEOF
> =

> =

> @@ -10151,7 +10215,7 @@ done
>  rm -f conf$$subs.sh
> =

>  cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
> -cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
> +cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
>  _ACEOF
>  sed -n '
>  h
> @@ -10199,7 +10263,7 @@ t delim
>  rm -f conf$$subs.awk
>  cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
>  _ACAWK
> -cat >>"\$tmp/subs1.awk" <<_ACAWK &&
> +cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
>    for (key in S) S_is_set[key] =3D 1
>    FS =3D "=07"
> =

> @@ -10231,7 +10295,7 @@ if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1;=
 then
>    sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
>  else
>    cat
> -fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
> +fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
>    || as_fn_error $? "could not setup config files machinery" "$LINENO" 5
>  _ACEOF
> =

> @@ -10265,7 +10329,7 @@ fi # test -n "$CONFIG_FILES"
>  # No need to generate them if there are no CONFIG_HEADERS.
>  # This happens for instance with `./config.status Makefile'.
>  if test -n "$CONFIG_HEADERS"; then
> -cat >"$tmp/defines.awk" <<\_ACAWK ||
> +cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
>  BEGIN {
>  _ACEOF
> =

> @@ -10277,8 +10341,8 @@ _ACEOF
>  # handling of long lines.
>  ac_delim=3D'%!_!# '
>  for ac_last_try in false false :; do
> -  ac_t=3D`sed -n "/$ac_delim/p" confdefs.h`
> -  if test -z "$ac_t"; then
> +  ac_tt=3D`sed -n "/$ac_delim/p" confdefs.h`
> +  if test -z "$ac_tt"; then
>      break
>    elif $ac_last_try; then
>      as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
> @@ -10379,7 +10443,7 @@ do
>    esac
>    case $ac_mode$ac_tag in
>    :[FHL]*:*);;
> -  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
> +  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
>    :[FH]-) ac_tag=3D-:-;;
>    :[FH]*) ac_tag=3D$ac_tag:$ac_tag.in;;
>    esac
> @@ -10398,7 +10462,7 @@ do
>      for ac_f
>      do
>        case $ac_f in
> -      -) ac_f=3D"$tmp/stdin";;
> +      -) ac_f=3D"$ac_tmp/stdin";;
>        *) # Look for the file first in the build tree, then in the source=
 tree
>          # (if the path is not absolute).  The absolute path cannot be DO=
S-style,
>          # because $ac_f cannot contain `:'.
> @@ -10407,7 +10471,7 @@ do
>            [\\/$]*) false;;
>            *) test -f "$srcdir/$ac_f" && ac_f=3D"$srcdir/$ac_f";;
>            esac ||
> -          as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
> +          as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
>        esac
>        case $ac_f in *\'*) ac_f=3D`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\'=
'/g"`;; esac
>        as_fn_append ac_file_inputs " '$ac_f'"
> @@ -10433,8 +10497,8 @@ $as_echo "$as_me: creating $ac_file" >&6;}
>      esac
> =

>      case $ac_tag in
> -    *:-:* | *:-) cat >"$tmp/stdin" \
> -      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
> +    *:-:* | *:-) cat >"$ac_tmp/stdin" \
> +      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
>      esac
>      ;;
>    esac
> @@ -10564,21 +10628,22 @@ s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
>  s&@INSTALL@&$ac_INSTALL&;t t
>  $ac_datarootdir_hack
>  "
> -eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" =
>$tmp/out \
> -  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
> +eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.aw=
k" \
> +  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5
> =

>  test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
> -  { ac_out=3D`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"=
; } &&
> -  { ac_out=3D`sed -n '/^[         ]*datarootdir[  ]*:*=3D/p' "$tmp/out"`=
; test -z "$ac_out"; } &&
> +  { ac_out=3D`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_o=
ut"; } &&
> +  { ac_out=3D`sed -n '/^[         ]*datarootdir[  ]*:*=3D/p' \
> +      "$ac_tmp/out"`; test -z "$ac_out"; } &&
>    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a =
reference to the variable \`datarootdir'
>  which seems to be undefined.  Please make sure it is defined" >&5
>  $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable=
 \`datarootdir'
>  which seems to be undefined.  Please make sure it is defined" >&2;}
> =

> -  rm -f "$tmp/stdin"
> +  rm -f "$ac_tmp/stdin"
>    case $ac_file in
> -  -) cat "$tmp/out" && rm -f "$tmp/out";;
> -  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
> +  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
> +  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
>    esac \
>    || as_fn_error $? "could not create $ac_file" "$LINENO" 5
>   ;;
> @@ -10589,20 +10654,20 @@ which seems to be undefined.  Please make sure =
it is defined" >&2;}
>    if test x"$ac_file" !=3D x-; then
>      {
>        $as_echo "/* $configure_input  */" \
> -      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
> -    } >"$tmp/config.h" \
> +      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
> +    } >"$ac_tmp/config.h" \
>        || as_fn_error $? "could not create $ac_file" "$LINENO" 5
> -    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
> +    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
>        { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&5
>  $as_echo "$as_me: $ac_file is unchanged" >&6;}
>      else
>        rm -f "$ac_file"
> -      mv "$tmp/config.h" "$ac_file" \
> +      mv "$ac_tmp/config.h" "$ac_file" \
>         || as_fn_error $? "could not create $ac_file" "$LINENO" 5
>      fi
>    else
>      $as_echo "/* $configure_input  */" \
> -      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
> +      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
>        || as_fn_error $? "could not create -" "$LINENO" 5
>    fi
>   ;;
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 250dffd..ddabfef 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -106,6 +106,7 @@ AX_PATH_PROG_OR_FAIL([AS86], [as86])
>  AX_PATH_PROG_OR_FAIL([LD86], [ld86])
>  AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>  AX_PATH_PROG_OR_FAIL([IASL], [iasl])
> +AX_PATH_PROG_OR_FAIL([FLEX], [flex])
>  AX_CHECK_UUID
>  AX_CHECK_CURSES
>  PKG_CHECK_MODULES(glib, glib-2.0)
> --
> 1.7.9.5
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 07:43:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgaQ-0005Y9-FQ; Mon, 16 Apr 2012 07:42:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJgaO-0005Y0-Ra
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 07:42:57 +0000
Received: from [85.158.143.99:11964] by server-3.bemta-4.messagelabs.com id
	97/F9-05853-08DCB8F4; Mon, 16 Apr 2012 07:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334562174!14143708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19129 invoked from network); 16 Apr 2012 07:42:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:42:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11946985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:42:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 08:42:53 +0100
Message-ID: <1334562173.4445.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 16 Apr 2012 08:42:53 +0100
In-Reply-To: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-04-15 at 19:43 +0100, Jean Guyader wrote:
> libxl require the command flex to be present.
> Verify in the configure script that the flex
> command exsits.

If only it were that simple :-/

We need a fairly recent version of flex (to avoid bugs WRT reentrancy of
the generated parsers) and this version is not in various stable
releases of common distros.

So we check in the generated files and are supposed to only rebuild them
when the source has changed. However there seems to be a bug somewhere
(probably something to do with VCS vs. timestamps) and sometime the
files get regenerated when they needn't be, at which point you need =

flex...

I think Roger Pau Monn=E9 posted a fix for all this last week.

> =

> Signed-off-by: Jean Guyader <jean.guyader@gmail.com>
> ---
>  tools/configure    |  633 +++++++++++++++++++++++++++++-----------------=
------
>  tools/configure.ac |    1 +
>  2 files changed, 350 insertions(+), 284 deletions(-)
> =

> diff --git a/tools/configure b/tools/configure
> index 86618f5..071adf7 100755
> --- a/tools/configure
> +++ b/tools/configure
> @@ -1,6 +1,6 @@
>  #! /bin/sh
>  # Guess values for system-dependent variables and create Makefiles.
> -# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
> +# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
>  #
>  # Report bugs to <xen-devel@lists.xensource.com>.
>  #
> @@ -91,6 +91,7 @@ fi
>  IFS=3D" ""       $as_nl"
> =

>  # Find who we are.  Look in the path if we contain no directory separato=
r.
> +as_myself=3D
>  case $0 in #((
>    *[\\/]* ) as_myself=3D$0 ;;
>    *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> @@ -216,11 +217,18 @@ IFS=3D$as_save_IFS
>    # We cannot yet assume a decent shell, so we have to provide a
>         # neutralization value for shells without unset; and this also
>         # works around shells that cannot unset nonexistent variables.
> +       # Preserve -v and -x to the replacement shell.
>         BASH_ENV=3D/dev/null
>         ENV=3D/dev/null
>         (unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
>         export CONFIG_SHELL
> -       exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
> +       case $- in # ((((
> +         *v*x* | *x*v* ) as_opts=3D-vx ;;
> +         *v* ) as_opts=3D-v ;;
> +         *x* ) as_opts=3D-x ;;
> +         * ) as_opts=3D ;;
> +       esac
> +       exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
>  fi
> =

>      if test x$as_have_required =3D xno; then :
> @@ -1164,7 +1172,7 @@ Try \`$0 --help' for more information"
>      $as_echo "$as_me: WARNING: you should use --build, --host, --target"=
 >&2
>      expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
>        $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
> -    : ${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_al=
ias=3D$ac_option}
> +    : "${build_alias=3D$ac_option} ${host_alias=3D$ac_option} ${target_a=
lias=3D$ac_option}"
>      ;;
> =

>    esac
> @@ -1490,7 +1498,7 @@ test -n "$ac_init_help" && exit $ac_status
>  if $ac_init_version; then
>    cat <<\_ACEOF
>  Xen Hypervisor configure 4.2
> -generated by GNU Autoconf 2.67
> +generated by GNU Autoconf 2.68
> =

>  Copyright (C) 2010 Free Software Foundation, Inc.
>  This configure script is free software; the Free Software Foundation
> @@ -1536,7 +1544,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
> =

>         ac_retval=3D1
>  fi
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_compile
> @@ -1573,7 +1581,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
> =

>      ac_retval=3D1
>  fi
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_cpp
> @@ -1586,10 +1594,10 @@ fi
>  ac_fn_c_check_header_mongrel ()
>  {
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
> -  if eval "test \"\${$3+set}\"" =3D set; then :
> +  if eval \${$3+:} false; then :
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  fi
>  eval ac_res=3D\$$3
> @@ -1656,7 +1664,7 @@ $as_echo "$as_me: WARNING: $2: proceeding with the =
compiler's result" >&2;}
>  esac
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    eval "$3=3D\$ac_header_compiler"
> @@ -1665,7 +1673,7 @@ eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
>  fi
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_header_mongrel
> =

> @@ -1706,7 +1714,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
>         ac_retval=3D$ac_status
>  fi
>    rm -rf conftest.dSYM conftest_ipa8_conftest.oo
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_run
> @@ -1720,7 +1728,7 @@ ac_fn_c_check_header_compile ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -1738,7 +1746,7 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_header_compile
> =

> @@ -1783,11 +1791,65 @@ fi
>    # interfere with the next link command; also delete a directory that is
>    # left behind by Apple's compiler.  We do this before executing the ac=
tions.
>    rm -rf conftest.dSYM conftest_ipa8_conftest.oo
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
>    as_fn_set_status $ac_retval
> =

>  } # ac_fn_c_try_link
> =

> +# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
> +# -------------------------------------------
> +# Tests whether TYPE exists after having included INCLUDES, setting cache
> +# variable VAR accordingly.
> +ac_fn_c_check_type ()
> +{
> +  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
> +$as_echo_n "checking for $2... " >&6; }
> +if eval \${$3+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  eval "$3=3Dno"
> +  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +$4
> +int
> +main ()
> +{
> +if (sizeof ($2))
> +        return 0;
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_c_try_compile "$LINENO"; then :
> +  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +$4
> +int
> +main ()
> +{
> +if (sizeof (($2)))
> +           return 0;
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_c_try_compile "$LINENO"; then :
> +
> +else
> +  eval "$3=3Dyes"
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +fi
> +eval ac_res=3D\$$3
> +              { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
> +$as_echo "$ac_res" >&6; }
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> +
> +} # ac_fn_c_check_type
> +
>  # ac_fn_c_check_func LINENO FUNC VAR
>  # ----------------------------------
>  # Tests whether FUNC exists, setting the cache variable VAR accordingly
> @@ -1796,7 +1858,7 @@ ac_fn_c_check_func ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
>  $as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -1851,64 +1913,10 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_func
> =

> -# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
> -# -------------------------------------------
> -# Tests whether TYPE exists after having included INCLUDES, setting cache
> -# variable VAR accordingly.
> -ac_fn_c_check_type ()
> -{
> -  as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
> -  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
> -$as_echo_n "checking for $2... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> -  $as_echo_n "(cached) " >&6
> -else
> -  eval "$3=3Dno"
> -  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> -/* end confdefs.h.  */
> -$4
> -int
> -main ()
> -{
> -if (sizeof ($2))
> -        return 0;
> -  ;
> -  return 0;
> -}
> -_ACEOF
> -if ac_fn_c_try_compile "$LINENO"; then :
> -  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> -/* end confdefs.h.  */
> -$4
> -int
> -main ()
> -{
> -if (sizeof (($2)))
> -           return 0;
> -  ;
> -  return 0;
> -}
> -_ACEOF
> -if ac_fn_c_try_compile "$LINENO"; then :
> -
> -else
> -  eval "$3=3Dyes"
> -fi
> -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> -fi
> -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> -fi
> -eval ac_res=3D\$$3
> -              { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
> -$as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> -
> -} # ac_fn_c_check_type
> -
>  # ac_fn_c_find_intX_t LINENO BITS VAR
>  # -----------------------------------
>  # Finds a signed integer type with width BITS, setting cache variable VAR
> @@ -1918,7 +1926,7 @@ ac_fn_c_find_intX_t ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
>  $as_echo_n "checking for int$2_t... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    eval "$3=3Dno"
> @@ -1979,7 +1987,7 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_find_intX_t
> =

> @@ -1992,7 +2000,7 @@ ac_fn_c_check_member ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
>  $as_echo_n "checking for $2.$3... " >&6; }
> -if eval "test \"\${$4+set}\"" =3D set; then :
> +if eval \${$4+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -2036,7 +2044,7 @@ fi
>  eval ac_res=3D\$$4
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_check_member
> =

> @@ -2049,7 +2057,7 @@ ac_fn_c_find_uintX_t ()
>    as_lineno=3D${as_lineno-"$1"} as_lineno_stack=3Das_lineno_stack=3D$as_=
lineno_stack
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
>  $as_echo_n "checking for uint$2_t... " >&6; }
> -if eval "test \"\${$3+set}\"" =3D set; then :
> +if eval \${$3+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    eval "$3=3Dno"
> @@ -2089,7 +2097,7 @@ fi
>  eval ac_res=3D\$$3
>                { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" =
>&5
>  $as_echo "$ac_res" >&6; }
> -  eval $as_lineno_stack; test "x$as_lineno_stack" =3D x && { as_lineno=
=3D; unset as_lineno;}
> +  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
> =

>  } # ac_fn_c_find_uintX_t
>  cat >config.log <<_ACEOF
> @@ -2097,7 +2105,7 @@ This file contains any messages produced by compile=
rs while
>  running configure, to aid debugging if configure makes a mistake.
> =

>  It was created by Xen Hypervisor $as_me 4.2, which was
> -generated by GNU Autoconf 2.67.  Invocation command line was
> +generated by GNU Autoconf 2.68.  Invocation command line was
> =

>    $ $0 $@
> =

> @@ -2355,7 +2363,7 @@ $as_echo "$as_me: loading site script $ac_site_file=
" >&6;}
>        || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd'=
:" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "failed to load site script $ac_site_file
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>    fi
>  done
> =

> @@ -2508,7 +2516,7 @@ if test -n "$ac_tool_prefix"; then
>  set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2548,7 +2556,7 @@ if test -z "$ac_cv_prog_CC"; then
>  set dummy gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -2601,7 +2609,7 @@ if test -z "$CC"; then
>  set dummy ${ac_tool_prefix}cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2641,7 +2649,7 @@ if test -z "$CC"; then
>  set dummy cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2700,7 +2708,7 @@ if test -z "$CC"; then
>  set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -2744,7 +2752,7 @@ do
>  set dummy $ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -2799,7 +2807,7 @@ fi
>  test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "no acceptable C compiler found in \$PATH
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
> =

>  # Provide some information about the compiler.
>  $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
> @@ -2914,7 +2922,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
>  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error 77 "C compiler cannot create executables
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  else
>    { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
>  $as_echo "yes" >&6; }
> @@ -2957,7 +2965,7 @@ else
>    { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "cannot compute suffix of executables: cannot compile and=
 link
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  fi
>  rm -f conftest conftest$ac_cv_exeext
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
> @@ -3016,7 +3024,7 @@ $as_echo "$ac_try_echo"; } >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "cannot run C compiled programs.
>  If you meant to cross compile, use \`--host'.
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>      fi
>    fi
>  fi
> @@ -3027,7 +3035,7 @@ rm -f conftest.$ac_ext conftest$ac_cv_exeext confte=
st.out
>  ac_clean_files=3D$ac_clean_files_save
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object f=
iles" >&5
>  $as_echo_n "checking for suffix of object files... " >&6; }
> -if test "${ac_cv_objext+set}" =3D set; then :
> +if ${ac_cv_objext+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3068,7 +3076,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
>  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "cannot compute suffix of object files: cannot compile
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  fi
>  rm -f conftest.$ac_cv_objext conftest.$ac_ext
>  fi
> @@ -3078,7 +3086,7 @@ OBJEXT=3D$ac_cv_objext
>  ac_objext=3D$OBJEXT
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
>  $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
> -if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
> +if ${ac_cv_c_compiler_gnu+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3115,7 +3123,7 @@ ac_test_CFLAGS=3D${CFLAGS+set}
>  ac_save_CFLAGS=3D$CFLAGS
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
>  $as_echo_n "checking whether $CC accepts -g... " >&6; }
> -if test "${ac_cv_prog_cc_g+set}" =3D set; then :
> +if ${ac_cv_prog_cc_g+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_save_c_werror_flag=3D$ac_c_werror_flag
> @@ -3193,7 +3201,7 @@ else
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
>  $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
> -if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
> +if ${ac_cv_prog_cc_c89+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_prog_cc_c89=3Dno
> @@ -3301,7 +3309,7 @@ if test -n "$CPP" && test -d "$CPP"; then
>    CPP=3D
>  fi
>  if test -z "$CPP"; then
> -  if test "${ac_cv_prog_CPP+set}" =3D set; then :
> +  if ${ac_cv_prog_CPP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>        # Double quotes because CPP needs to be expanded
> @@ -3417,7 +3425,7 @@ else
>    { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  fi
> =

>  ac_ext=3Dc
> @@ -3429,7 +3437,7 @@ ac_compiler_gnu=3D$ac_cv_c_compiler_gnu
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles =
long lines and -e" >&5
>  $as_echo_n "checking for grep that handles long lines and -e... " >&6; }
> -if test "${ac_cv_path_GREP+set}" =3D set; then :
> +if ${ac_cv_path_GREP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -z "$GREP"; then
> @@ -3492,7 +3500,7 @@ $as_echo "$ac_cv_path_GREP" >&6; }
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
>  $as_echo_n "checking for egrep... " >&6; }
> -if test "${ac_cv_path_EGREP+set}" =3D set; then :
> +if ${ac_cv_path_EGREP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
> @@ -3559,7 +3567,7 @@ $as_echo "$ac_cv_path_EGREP" >&6; }
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header file=
s" >&5
>  $as_echo_n "checking for ANSI C header files... " >&6; }
> -if test "${ac_cv_header_stdc+set}" =3D set; then :
> +if ${ac_cv_header_stdc+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3688,7 +3696,7 @@ done
> =

> =

>    ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_=
minix_config_h" "$ac_includes_default"
> -if test "x$ac_cv_header_minix_config_h" =3D x""yes; then :
> +if test "x$ac_cv_header_minix_config_h" =3D xyes; then :
>    MINIX=3Dyes
>  else
>    MINIX=3D
> @@ -3710,7 +3718,7 @@ $as_echo "#define _MINIX 1" >>confdefs.h
> =

>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe t=
o define __EXTENSIONS__" >&5
>  $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&=
6; }
> -if test "${ac_cv_safe_to_define___extensions__+set}" =3D set; then :
> +if ${ac_cv_safe_to_define___extensions__+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -3753,7 +3761,7 @@ $SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&=
1 ||
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
>  $as_echo_n "checking build system type... " >&6; }
> -if test "${ac_cv_build+set}" =3D set; then :
> +if ${ac_cv_build+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_build_alias=3D$build_alias
> @@ -3769,7 +3777,7 @@ fi
>  $as_echo "$ac_cv_build" >&6; }
>  case $ac_cv_build in
>  *-*-*) ;;
> -*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
> +*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
>  esac
>  build=3D$ac_cv_build
>  ac_save_IFS=3D$IFS; IFS=3D'-'
> @@ -3787,7 +3795,7 @@ case $build_os in *\ *) build_os=3D`echo "$build_os=
" | sed 's/ /-/g'`;; esac
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
>  $as_echo_n "checking host system type... " >&6; }
> -if test "${ac_cv_host+set}" =3D set; then :
> +if ${ac_cv_host+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "x$host_alias" =3D x; then
> @@ -3802,7 +3810,7 @@ fi
>  $as_echo "$ac_cv_host" >&6; }
>  case $ac_cv_host in
>  *-*-*) ;;
> -*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
> +*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
>  esac
>  host=3D$ac_cv_host
>  ac_save_IFS=3D$IFS; IFS=3D'-'
> @@ -4196,7 +4204,7 @@ LDFLAGS=3D"$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAG=
S"
>  # Checks for programs.
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does no=
t truncate output" >&5
>  $as_echo_n "checking for a sed that does not truncate output... " >&6; }
> -if test "${ac_cv_path_SED+set}" =3D set; then :
> +if ${ac_cv_path_SED+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>              ac_script=3Ds/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbb=
bbbbbbbbbbbbbbbbbbbbbbb/
> @@ -4273,7 +4281,7 @@ if test -n "$ac_tool_prefix"; then
>  set dummy ${ac_tool_prefix}gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4313,7 +4321,7 @@ if test -z "$ac_cv_prog_CC"; then
>  set dummy gcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -4366,7 +4374,7 @@ if test -z "$CC"; then
>  set dummy ${ac_tool_prefix}cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4406,7 +4414,7 @@ if test -z "$CC"; then
>  set dummy cc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4465,7 +4473,7 @@ if test -z "$CC"; then
>  set dummy $ac_tool_prefix$ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_CC+set}" =3D set; then :
> +if ${ac_cv_prog_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$CC"; then
> @@ -4509,7 +4517,7 @@ do
>  set dummy $ac_prog; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_CC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_CC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_CC"; then
> @@ -4564,7 +4572,7 @@ fi
>  test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`=
$ac_pwd':" >&5
>  $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>  as_fn_error $? "no acceptable C compiler found in \$PATH
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
> =

>  # Provide some information about the compiler.
>  $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" =
>&5
> @@ -4593,7 +4601,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using t=
he GNU C compiler" >&5
>  $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
> -if test "${ac_cv_c_compiler_gnu+set}" =3D set; then :
> +if ${ac_cv_c_compiler_gnu+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -4630,7 +4638,7 @@ ac_test_CFLAGS=3D${CFLAGS+set}
>  ac_save_CFLAGS=3D$CFLAGS
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g=
" >&5
>  $as_echo_n "checking whether $CC accepts -g... " >&6; }
> -if test "${ac_cv_prog_cc_g+set}" =3D set; then :
> +if ${ac_cv_prog_cc_g+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_save_c_werror_flag=3D$ac_c_werror_flag
> @@ -4708,7 +4716,7 @@ else
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to acce=
pt ISO C89" >&5
>  $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
> -if test "${ac_cv_prog_cc_c89+set}" =3D set; then :
> +if ${ac_cv_prog_cc_c89+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_prog_cc_c89=3Dno
> @@ -4818,7 +4826,7 @@ fi
>  $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
>  set x ${MAKE-make}
>  ac_make=3D`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
> -if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" =3D set; then :
> +if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat >conftest.make <<\_ACEOF
> @@ -4862,7 +4870,7 @@ fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible i=
nstall" >&5
>  $as_echo_n "checking for a BSD-compatible install... " >&6; }
>  if test -z "$INSTALL"; then
> -if test "${ac_cv_path_install+set}" =3D set; then :
> +if ${ac_cv_path_install+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> @@ -4942,7 +4950,7 @@ test -z "$INSTALL_DATA" && INSTALL_DATA=3D'${INSTAL=
L} -m 644'
>  set dummy perl; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_PERL+set}" =3D set; then :
> +if ${ac_cv_path_PERL+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $PERL in
> @@ -4989,7 +4997,7 @@ if test "x$xapi" =3D "xy"; then :
>  set dummy curl-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_CURL+set}" =3D set; then :
> +if ${ac_cv_path_CURL+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $CURL in
> @@ -5034,7 +5042,7 @@ fi
>  set dummy xml2-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_XML+set}" =3D set; then :
> +if ${ac_cv_path_XML+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $XML in
> @@ -5085,7 +5093,7 @@ if test "x$ocamltools" =3D "xy"; then :
>  set dummy ${ac_tool_prefix}ocamlc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLC+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLC"; then
> @@ -5125,7 +5133,7 @@ if test -z "$ac_cv_prog_OCAMLC"; then
>  set dummy ocamlc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLC"; then
> @@ -5196,7 +5204,7 @@ $as_echo "OCaml library path is $OCAMLLIB" >&6; }
>  set dummy ${ac_tool_prefix}ocamlopt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLOPT+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLOPT"; then
> @@ -5236,7 +5244,7 @@ if test -z "$ac_cv_prog_OCAMLOPT"; then
>  set dummy ocamlopt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLOPT"; then
> @@ -5306,7 +5314,7 @@ $as_echo "versions differs from ocamlc; ocamlopt di=
scarded." >&6; }
>  set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLCDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLCDOTOPT"; then
> @@ -5346,7 +5354,7 @@ if test -z "$ac_cv_prog_OCAMLCDOTOPT"; then
>  set dummy ocamlc.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLCDOTOPT"; then
> @@ -5410,7 +5418,7 @@ $as_echo "versions differs from ocamlc; ocamlc.opt =
discarded." >&6; }
>  set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLOPTDOTOPT"; then
> @@ -5450,7 +5458,7 @@ if test -z "$ac_cv_prog_OCAMLOPTDOTOPT"; then
>  set dummy ocamlopt.opt; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
> @@ -5519,7 +5527,7 @@ $as_echo "version differs from ocamlc; ocamlopt.opt=
 discarded." >&6; }
>  set dummy ${ac_tool_prefix}ocaml; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAML+set}" =3D set; then :
> +if ${ac_cv_prog_OCAML+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAML"; then
> @@ -5559,7 +5567,7 @@ if test -z "$ac_cv_prog_OCAML"; then
>  set dummy ocaml; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAML+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAML"; then
> @@ -5613,7 +5621,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamldep; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLDEP+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLDEP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLDEP"; then
> @@ -5653,7 +5661,7 @@ if test -z "$ac_cv_prog_OCAMLDEP"; then
>  set dummy ocamldep; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLDEP"; then
> @@ -5707,7 +5715,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamlmktop; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLMKTOP+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLMKTOP"; then
> @@ -5747,7 +5755,7 @@ if test -z "$ac_cv_prog_OCAMLMKTOP"; then
>  set dummy ocamlmktop; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLMKTOP"; then
> @@ -5801,7 +5809,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamlmklib; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLMKLIB+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLMKLIB"; then
> @@ -5841,7 +5849,7 @@ if test -z "$ac_cv_prog_OCAMLMKLIB"; then
>  set dummy ocamlmklib; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLMKLIB"; then
> @@ -5895,7 +5903,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamldoc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLDOC+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLDOC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLDOC"; then
> @@ -5935,7 +5943,7 @@ if test -z "$ac_cv_prog_OCAMLDOC"; then
>  set dummy ocamldoc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLDOC"; then
> @@ -5989,7 +5997,7 @@ fi
>  set dummy ${ac_tool_prefix}ocamlbuild; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_OCAMLBUILD+set}" =3D set; then :
> +if ${ac_cv_prog_OCAMLBUILD+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$OCAMLBUILD"; then
> @@ -6029,7 +6037,7 @@ if test -z "$ac_cv_prog_OCAMLBUILD"; then
>  set dummy ocamlbuild; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" =3D set; then :
> +if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test -n "$ac_ct_OCAMLBUILD"; then
> @@ -6092,7 +6100,7 @@ fi
>  set dummy bash; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_BASH+set}" =3D set; then :
> +if ${ac_cv_path_BASH+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $BASH in
> @@ -6149,7 +6157,7 @@ fi
>  set dummy $PYTHON; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_PYTHONPATH+set}" =3D set; then :
> +if ${ac_cv_path_PYTHONPATH+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $PYTHONPATH in
> @@ -6225,7 +6233,7 @@ LDFLAGS=3D"$LDFLAGS `$PYTHON -c 'import distutils.s=
ysconfig; \
>      print distutils.sysconfig.get_config_var("LDFLAGS")'`"
> =

>  ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h=
" "$ac_includes_default"
> -if test "x$ac_cv_header_Python_h" =3D x""yes; then :
> +if test "x$ac_cv_header_Python_h" =3D xyes; then :
> =

>  else
>    as_fn_error $? "Unable to find Python development headers" "$LINENO" 5
> @@ -6235,7 +6243,7 @@ fi
>  as_ac_Lib=3D`$as_echo "ac_cv_lib_python$ac_python_version''_PyArg_ParseT=
uple" | $as_tr_sh`
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PyArg_ParseTuple i=
n -lpython$ac_python_version" >&5
>  $as_echo_n "checking for PyArg_ParseTuple in -lpython$ac_python_version.=
.. " >&6; }
> -if eval "test \"\${$as_ac_Lib+set}\"" =3D set; then :
> +if eval \${$as_ac_Lib+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6290,7 +6298,7 @@ fi
>  set dummy xgettext; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_XGETTEXT+set}" =3D set; then :
> +if ${ac_cv_path_XGETTEXT+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $XGETTEXT in
> @@ -6335,7 +6343,7 @@ fi
>  set dummy as86; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_AS86+set}" =3D set; then :
> +if ${ac_cv_path_AS86+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $AS86 in
> @@ -6380,7 +6388,7 @@ fi
>  set dummy ld86; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_LD86+set}" =3D set; then :
> +if ${ac_cv_path_LD86+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $LD86 in
> @@ -6425,7 +6433,7 @@ fi
>  set dummy bcc; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_BCC+set}" =3D set; then :
> +if ${ac_cv_path_BCC+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $BCC in
> @@ -6470,7 +6478,7 @@ fi
>  set dummy iasl; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_IASL+set}" =3D set; then :
> +if ${ac_cv_path_IASL+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $IASL in
> @@ -6511,13 +6519,58 @@ if test x"${IASL}" =3D=3D x"no"
>  then
>      as_fn_error $? "Unable to find iasl, please install iasl" "$LINENO" 5
>  fi
> +# Extract the first word of "flex", so it can be a program name with arg=
s.
> +set dummy flex; ac_word=3D$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_path_FLEX+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  case $FLEX in
> +  [\\/]* | ?:[\\/]*)
> +  ac_cv_path_FLEX=3D"$FLEX" # Let the user override the test with a path.
> +  ;;
> +  *)
> +  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> +  IFS=3D$as_save_IFS
> +  test -z "$as_dir" && as_dir=3D.
> +    for ac_exec_ext in '' $ac_executable_extensions; do
> +  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac=
_word$ac_exec_ext"; }; then
> +    ac_cv_path_FLEX=3D"$as_dir/$ac_word$ac_exec_ext"
> +    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exe=
c_ext" >&5
> +    break 2
> +  fi
> +done
> +  done
> +IFS=3D$as_save_IFS
> +
> +  test -z "$ac_cv_path_FLEX" && ac_cv_path_FLEX=3D"no"
> +  ;;
> +esac
> +fi
> +FLEX=3D$ac_cv_path_FLEX
> +if test -n "$FLEX"; then
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $FLEX" >&5
> +$as_echo "$FLEX" >&6; }
> +else
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +
> +if test x"${FLEX}" =3D=3D x"no"
> +then
> +    as_fn_error $? "Unable to find flex, please install flex" "$LINENO" 5
> +fi
> =

>  ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_=
uuid_h" "$ac_includes_default"
> -if test "x$ac_cv_header_uuid_uuid_h" =3D x""yes; then :
> +if test "x$ac_cv_header_uuid_uuid_h" =3D xyes; then :
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in =
-luuid" >&5
>  $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
> -if test "${ac_cv_lib_uuid_uuid_clear+set}" =3D set; then :
> +if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6551,7 +6604,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_cl=
ear" >&5
>  $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
> -if test "x$ac_cv_lib_uuid_uuid_clear" =3D x""yes; then :
> +if test "x$ac_cv_lib_uuid_uuid_clear" =3D xyes; then :
>    libuuid=3D"y"
>  fi
> =

> @@ -6560,7 +6613,7 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$=
ac_includes_default"
> -if test "x$ac_cv_header_uuid_h" =3D x""yes; then :
> +if test "x$ac_cv_header_uuid_h" =3D xyes; then :
>    libuuid=3D"y"
>  fi
> =

> @@ -6573,11 +6626,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h=
" "$ac_includes_default"
> -if test "x$ac_cv_header_curses_h" =3D x""yes; then :
> +if test "x$ac_cv_header_curses_h" =3D xyes; then :
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcur=
ses" >&5
>  $as_echo_n "checking for clear in -lcurses... " >&6; }
> -if test "${ac_cv_lib_curses_clear+set}" =3D set; then :
> +if ${ac_cv_lib_curses_clear+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6611,7 +6664,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear=
" >&5
>  $as_echo "$ac_cv_lib_curses_clear" >&6; }
> -if test "x$ac_cv_lib_curses_clear" =3D x""yes; then :
> +if test "x$ac_cv_lib_curses_clear" =3D xyes; then :
>    curses=3D"y"
>  else
>    curses=3D"n"
> @@ -6624,11 +6677,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses=
_h" "$ac_includes_default"
> -if test "x$ac_cv_header_ncurses_h" =3D x""yes; then :
> +if test "x$ac_cv_header_ncurses_h" =3D xyes; then :
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncu=
rses" >&5
>  $as_echo_n "checking for clear in -lncurses... " >&6; }
> -if test "${ac_cv_lib_ncurses_clear+set}" =3D set; then :
> +if ${ac_cv_lib_ncurses_clear+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6662,7 +6715,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clea=
r" >&5
>  $as_echo "$ac_cv_lib_ncurses_clear" >&6; }
> -if test "x$ac_cv_lib_ncurses_clear" =3D x""yes; then :
> +if test "x$ac_cv_lib_ncurses_clear" =3D xyes; then :
>    ncurses=3D"y"
>  else
>    ncurses=3D"n"
> @@ -6709,7 +6762,7 @@ if test "x$ac_cv_env_PKG_CONFIG_set" !=3D "xset"; t=
hen
>  set dummy ${ac_tool_prefix}pkg-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_PKG_CONFIG+set}" =3D set; then :
> +if ${ac_cv_path_PKG_CONFIG+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $PKG_CONFIG in
> @@ -6752,7 +6805,7 @@ if test -z "$ac_cv_path_PKG_CONFIG"; then
>  set dummy pkg-config; ac_word=3D$2
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>  $as_echo_n "checking for $ac_word... " >&6; }
> -if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" =3D set; then :
> +if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    case $ac_pt_PKG_CONFIG in
> @@ -6897,7 +6950,7 @@ and glib_LIBS to avoid the need to call pkg-config.
>  See the pkg-config man page for more details.
> =

>  To get pkg-config, see <http://pkg-config.freedesktop.org/>.
> -See \`config.log' for more details" "$LINENO" 5 ; }
> +See \`config.log' for more details" "$LINENO" 5; }
>  else
>         glib_CFLAGS=3D$pkg_cv_glib_CFLAGS
>         glib_LIBS=3D$pkg_cv_glib_LIBS
> @@ -6933,11 +6986,11 @@ fi
> =

>  # Checks for libraries.
>  ac_fn_c_check_header_mongrel "$LINENO" "bzlib.h" "ac_cv_header_bzlib_h" =
"$ac_includes_default"
> -if test "x$ac_cv_header_bzlib_h" =3D x""yes; then :
> +if test "x$ac_cv_header_bzlib_h" =3D xyes; then :
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for BZ2_bzDecompressIn=
it in -lbz2" >&5
>  $as_echo_n "checking for BZ2_bzDecompressInit in -lbz2... " >&6; }
> -if test "${ac_cv_lib_bz2_BZ2_bzDecompressInit+set}" =3D set; then :
> +if ${ac_cv_lib_bz2_BZ2_bzDecompressInit+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -6971,7 +7024,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_bz2_BZ2_bzDe=
compressInit" >&5
>  $as_echo "$ac_cv_lib_bz2_BZ2_bzDecompressInit" >&6; }
> -if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D x""yes; then :
> +if test "x$ac_cv_lib_bz2_BZ2_bzDecompressInit" =3D xyes; then :
>    zlib=3D"$zlib -DHAVE_BZLIB -lbz2"
>  fi
> =

> @@ -6980,11 +7033,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "lzma.h" "ac_cv_header_lzma_h" "$=
ac_includes_default"
> -if test "x$ac_cv_header_lzma_h" =3D x""yes; then :
> +if test "x$ac_cv_header_lzma_h" =3D xyes; then :
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzma_stream_decode=
r in -llzma" >&5
>  $as_echo_n "checking for lzma_stream_decoder in -llzma... " >&6; }
> -if test "${ac_cv_lib_lzma_lzma_stream_decoder+set}" =3D set; then :
> +if ${ac_cv_lib_lzma_lzma_stream_decoder+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7018,7 +7071,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzma_lzma_st=
ream_decoder" >&5
>  $as_echo "$ac_cv_lib_lzma_lzma_stream_decoder" >&6; }
> -if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D x""yes; then :
> +if test "x$ac_cv_lib_lzma_lzma_stream_decoder" =3D xyes; then :
>    zlib=3D"$zlib -DHAVE_LZMA -llzma"
>  fi
> =

> @@ -7027,11 +7080,11 @@ fi
> =

> =

>  ac_fn_c_check_header_mongrel "$LINENO" "lzo/lzo1x.h" "ac_cv_header_lzo_l=
zo1x_h" "$ac_includes_default"
> -if test "x$ac_cv_header_lzo_lzo1x_h" =3D x""yes; then :
> +if test "x$ac_cv_header_lzo_lzo1x_h" =3D xyes; then :
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lzo1x_decompress i=
n -llzo2" >&5
>  $as_echo_n "checking for lzo1x_decompress in -llzo2... " >&6; }
> -if test "${ac_cv_lib_lzo2_lzo1x_decompress+set}" =3D set; then :
> +if ${ac_cv_lib_lzo2_lzo1x_decompress+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7065,7 +7118,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lzo2_lzo1x_d=
ecompress" >&5
>  $as_echo "$ac_cv_lib_lzo2_lzo1x_decompress" >&6; }
> -if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D x""yes; then :
> +if test "x$ac_cv_lib_lzo2_lzo1x_decompress" =3D xyes; then :
>    zlib=3D"$zlib -DHAVE_LZO1X -llzo2"
>  fi
> =

> @@ -7076,7 +7129,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio"=
 >&5
>  $as_echo_n "checking for io_setup in -laio... " >&6; }
> -if test "${ac_cv_lib_aio_io_setup+set}" =3D set; then :
> +if ${ac_cv_lib_aio_io_setup+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7110,7 +7163,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup=
" >&5
>  $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
> -if test "x$ac_cv_lib_aio_io_setup" =3D x""yes; then :
> +if test "x$ac_cv_lib_aio_io_setup" =3D xyes; then :
>    system_aio=3D"y"
>  else
>    system_aio=3D"n"
> @@ -7119,7 +7172,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >=
&5
>  $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
> -if test "${ac_cv_lib_crypto_MD5+set}" =3D set; then :
> +if ${ac_cv_lib_crypto_MD5+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7153,7 +7206,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" =
>&5
>  $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
> -if test "x$ac_cv_lib_crypto_MD5" =3D x""yes; then :
> +if test "x$ac_cv_lib_crypto_MD5" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBCRYPTO 1
>  _ACEOF
> @@ -7166,7 +7219,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -l=
ext2fs" >&5
>  $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
> -if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" =3D set; then :
> +if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7200,7 +7253,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2f=
s_open2" >&5
>  $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
> -if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D x""yes; then :
> +if test "x$ac_cv_lib_ext2fs_ext2fs_open2" =3D xyes; then :
>    libext2fs=3D"y"
>  else
>    libext2fs=3D"n"
> @@ -7209,7 +7262,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffe=
r in -lgcrypt" >&5
>  $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
> -if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" =3D set; then :
> +if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7243,7 +7296,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_=
md_hash_buffer" >&5
>  $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
> -if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D x""yes; then :
> +if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" =3D xyes; then :
>    libgcrypt=3D"y"
>  else
>    libgcrypt=3D"n"
> @@ -7253,7 +7306,7 @@ fi
> =

>      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" =
>&5
>  $as_echo_n "checking for pthread flag... " >&6; }
> -if test "${ax_cv_pthread_flags+set}" =3D set; then :
> +if ${ax_cv_pthread_flags+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
> =

> @@ -7317,7 +7370,7 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -=
lrt" >&5
>  $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
> -if test "${ac_cv_lib_rt_clock_gettime+set}" =3D set; then :
> +if ${ac_cv_lib_rt_clock_gettime+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7351,7 +7404,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_get=
time" >&5
>  $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
> -if test "x$ac_cv_lib_rt_clock_gettime" =3D x""yes; then :
> +if test "x$ac_cv_lib_rt_clock_gettime" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBRT 1
>  _ACEOF
> @@ -7362,7 +7415,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lya=
jl" >&5
>  $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
> -if test "${ac_cv_lib_yajl_yajl_alloc+set}" =3D set; then :
> +if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7396,7 +7449,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_al=
loc" >&5
>  $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
> -if test "x$ac_cv_lib_yajl_yajl_alloc" =3D x""yes; then :
> +if test "x$ac_cv_lib_yajl_yajl_alloc" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBYAJL 1
>  _ACEOF
> @@ -7409,7 +7462,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz=
" >&5
>  $as_echo_n "checking for deflateCopy in -lz... " >&6; }
> -if test "${ac_cv_lib_z_deflateCopy+set}" =3D set; then :
> +if ${ac_cv_lib_z_deflateCopy+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7443,7 +7496,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCop=
y" >&5
>  $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
> -if test "x$ac_cv_lib_z_deflateCopy" =3D x""yes; then :
> +if test "x$ac_cv_lib_z_deflateCopy" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_LIBZ 1
>  _ACEOF
> @@ -7456,7 +7509,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -=
liconv" >&5
>  $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
> -if test "${ac_cv_lib_iconv_libiconv_open+set}" =3D set; then :
> +if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -7490,7 +7543,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libico=
nv_open" >&5
>  $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
> -if test "x$ac_cv_lib_iconv_libiconv_open" =3D x""yes; then :
> +if test "x$ac_cv_lib_iconv_libiconv_open" =3D xyes; then :
>    libiconv=3D"y"
>  else
>    libiconv=3D"n"
> @@ -7499,11 +7552,22 @@ fi
> =

> =

>  # Checks for header files.
> +ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
> +if test "x$ac_cv_type_size_t" =3D xyes; then :
> +
> +else
> +
> +cat >>confdefs.h <<_ACEOF
> +#define size_t unsigned int
> +_ACEOF
> +
> +fi
> +
>  # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
>  # for constant arguments.  Useless!
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" =
>&5
>  $as_echo_n "checking for working alloca.h... " >&6; }
> -if test "${ac_cv_working_alloca_h+set}" =3D set; then :
> +if ${ac_cv_working_alloca_h+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7536,7 +7600,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
>  $as_echo_n "checking for alloca... " >&6; }
> -if test "${ac_cv_func_alloca_works+set}" =3D set; then :
> +if ${ac_cv_func_alloca_works+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7555,7 +7619,7 @@ else
>   #pragma alloca
>  #   else
>  #    ifndef alloca /* predefined by HP cc +Olibcalls */
> -char *alloca ();
> +void *alloca (size_t);
>  #    endif
>  #   endif
>  #  endif
> @@ -7599,7 +7663,7 @@ $as_echo "#define C_ALLOCA 1" >>confdefs.h
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' ne=
eds Cray hooks" >&5
>  $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
> -if test "${ac_cv_os_cray+set}" =3D set; then :
> +if ${ac_cv_os_cray+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7640,7 +7704,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C =
alloca" >&5
>  $as_echo_n "checking stack direction for C alloca... " >&6; }
> -if test "${ac_cv_c_stack_direction+set}" =3D set; then :
> +if ${ac_cv_c_stack_direction+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -7711,7 +7775,7 @@ done
>  # Checks for typedefs, structures, and compiler characteristics.
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that con=
forms to C99" >&5
>  $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
> -if test "${ac_cv_header_stdbool_h+set}" =3D set; then :
> +if ${ac_cv_header_stdbool_h+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7743,7 +7807,7 @@ else
>         char b[false =3D=3D 0 ? 1 : -1];
>         char c[__bool_true_false_are_defined =3D=3D 1 ? 1 : -1];
>         char d[(bool) 0.5 =3D=3D true ? 1 : -1];
> -       bool e =3D &s;
> +       /* See body of main program for 'e'.  */
>         char f[(_Bool) 0.0 =3D=3D false ? 1 : -1];
>         char g[true];
>         char h[sizeof (_Bool)];
> @@ -7754,25 +7818,6 @@ else
>         _Bool n[m];
>         char o[sizeof n =3D=3D m * sizeof n[0] ? 1 : -1];
>         char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
> -#      if defined __xlc__ || defined __GNUC__
> -        /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
> -           reported by James Lemley on 2005-10-05; see
> -           http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00=
086.html
> -           This test is not quite right, since xlc is allowed to
> -           reject this program, as the initializer for xlcbug is
> -           not one of the forms that C requires support for.
> -           However, doing the test right would require a runtime
> -           test, and that would make cross-compilation harder.
> -           Let us hope that IBM fixes the xlc bug, and also adds
> -           support for this kind of constant expression.  In the
> -           meantime, this test will reject xlc, which is OK, since
> -           our stdbool.h substitute should suffice.  We also test
> -           this with GCC, where it should work, to detect more
> -           quickly whether someone messes up the test in the
> -           future.  */
> -        char digs[] =3D "0123456789";
> -        int xlcbug =3D 1 / (&(digs + 5)[-2 + (bool) 1] =3D=3D &digs[4] ?=
 1 : -1);
> -#      endif
>         /* Catch a bug in an HP-UX C compiler.  See
>            http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
>            http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg001=
61.html
> @@ -7784,6 +7829,7 @@ int
>  main ()
>  {
> =

> +       bool e =3D &s;
>         *pq |=3D q;
>         *pq |=3D ! q;
>         /* Refer to every declared value, to avoid compiler optimizations=
.  */
> @@ -7804,7 +7850,7 @@ fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h=
" >&5
>  $as_echo "$ac_cv_header_stdbool_h" >&6; }
>  ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_de=
fault"
> -if test "x$ac_cv_type__Bool" =3D x""yes; then :
> +if test "x$ac_cv_type__Bool" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE__BOOL 1
> @@ -7821,7 +7867,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types=
.h" >&5
>  $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
> -if test "${ac_cv_type_uid_t+set}" =3D set; then :
> +if ${ac_cv_type_uid_t+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -7851,7 +7897,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
>  $as_echo_n "checking for inline... " >&6; }
> -if test "${ac_cv_c_inline+set}" =3D set; then :
> +if ${ac_cv_c_inline+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_c_inline=3Dno
> @@ -7936,7 +7982,7 @@ _ACEOF
>  esac
> =

>  ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_=
default"
> -if test "x$ac_cv_type_mode_t" =3D x""yes; then :
> +if test "x$ac_cv_type_mode_t" =3D xyes; then :
> =

>  else
> =

> @@ -7947,7 +7993,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_de=
fault"
> -if test "x$ac_cv_type_off_t" =3D x""yes; then :
> +if test "x$ac_cv_type_off_t" =3D xyes; then :
> =

>  else
> =

> @@ -7958,7 +8004,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_de=
fault"
> -if test "x$ac_cv_type_pid_t" =3D x""yes; then :
> +if test "x$ac_cv_type_pid_t" =3D xyes; then :
> =

>  else
> =

> @@ -7970,7 +8016,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict key=
word" >&5
>  $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
> -if test "${ac_cv_c_restrict+set}" =3D set; then :
> +if ${ac_cv_c_restrict+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_cv_c_restrict=3Dno
> @@ -8015,7 +8061,7 @@ _ACEOF
>   esac
> =

>  ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_=
default"
> -if test "x$ac_cv_type_size_t" =3D x""yes; then :
> +if test "x$ac_cv_type_size_t" =3D xyes; then :
> =

>  else
> =

> @@ -8026,7 +8072,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_include=
s_default"
> -if test "x$ac_cv_type_ssize_t" =3D x""yes; then :
> +if test "x$ac_cv_type_ssize_t" =3D xyes; then :
> =

>  else
> =

> @@ -8037,7 +8083,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_=
struct_stat_st_blksize" "$ac_includes_default"
> -if test "x$ac_cv_member_struct_stat_st_blksize" =3D x""yes; then :
> +if test "x$ac_cv_member_struct_stat_st_blksize" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
> @@ -8047,7 +8093,7 @@ _ACEOF
>  fi
> =

>  ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_s=
truct_stat_st_blocks" "$ac_includes_default"
> -if test "x$ac_cv_member_struct_stat_st_blocks" =3D x""yes; then :
> +if test "x$ac_cv_member_struct_stat_st_blocks" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_STRUCT_STAT_ST_BLOCKS 1
> @@ -8067,7 +8113,7 @@ fi
> =

> =

>  ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_str=
uct_stat_st_rdev" "$ac_includes_default"
> -if test "x$ac_cv_member_struct_stat_st_rdev" =3D x""yes; then :
> +if test "x$ac_cv_member_struct_stat_st_rdev" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_STRUCT_STAT_ST_RDEV 1
> @@ -8131,7 +8177,7 @@ _ACEOF
>    esac
> =

>  ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_inc=
ludes_default"
> -if test "x$ac_cv_type_ptrdiff_t" =3D x""yes; then :
> +if test "x$ac_cv_type_ptrdiff_t" =3D xyes; then :
> =

>  cat >>confdefs.h <<_ACEOF
>  #define HAVE_PTRDIFF_T 1
> @@ -8144,7 +8190,7 @@ fi
>  # Checks for library functions.
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5
>  $as_echo_n "checking for error_at_line... " >&6; }
> -if test "${ac_cv_lib_error_at_line+set}" =3D set; then :
> +if ${ac_cv_lib_error_at_line+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -8180,7 +8226,7 @@ fi
>  for ac_header in vfork.h
>  do :
>    ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h=
" "$ac_includes_default"
> -if test "x$ac_cv_header_vfork_h" =3D x""yes; then :
> +if test "x$ac_cv_header_vfork_h" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_VFORK_H 1
>  _ACEOF
> @@ -8204,7 +8250,7 @@ done
>  if test "x$ac_cv_func_fork" =3D xyes; then
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&5
>  $as_echo_n "checking for working fork... " >&6; }
> -if test "${ac_cv_func_fork_works+set}" =3D set; then :
> +if ${ac_cv_func_fork_works+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8257,7 +8303,7 @@ ac_cv_func_vfork_works=3D$ac_cv_func_vfork
>  if test "x$ac_cv_func_vfork" =3D xyes; then
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >=
&5
>  $as_echo_n "checking for working vfork... " >&6; }
> -if test "${ac_cv_func_vfork_works+set}" =3D set; then :
> +if ${ac_cv_func_vfork_works+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8392,7 +8438,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE =
value needed for large files" >&5
>  $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files.=
.. " >&6; }
> -if test "${ac_cv_sys_largefile_source+set}" =3D set; then :
> +if ${ac_cv_sys_largefile_source+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    while :; do
> @@ -8460,7 +8506,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctl=
y handles trailing slash" >&5
>  $as_echo_n "checking whether lstat correctly handles trailing slash... "=
 >&6; }
> -if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" =3D set; =
then :
> +if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    rm -f conftest.sym conftest.file
> @@ -8522,7 +8568,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h de=
fines makedev" >&5
>  $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
> -if test "${ac_cv_header_sys_types_h_makedev+set}" =3D set; then :
> +if ${ac_cv_header_sys_types_h_makedev+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -8550,7 +8596,7 @@ $as_echo "$ac_cv_header_sys_types_h_makedev" >&6; }
> =

>  if test $ac_cv_header_sys_types_h_makedev =3D no; then
>  ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_m=
kdev_h" "$ac_includes_default"
> -if test "x$ac_cv_header_sys_mkdev_h" =3D x""yes; then :
> +if test "x$ac_cv_header_sys_mkdev_h" =3D xyes; then :
> =

>  $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
> =

> @@ -8560,7 +8606,7 @@ fi
> =

>    if test $ac_cv_header_sys_mkdev_h =3D no; then
>      ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_head=
er_sys_sysmacros_h" "$ac_includes_default"
> -if test "x$ac_cv_header_sys_sysmacros_h" =3D x""yes; then :
> +if test "x$ac_cv_header_sys_sysmacros_h" =3D xyes; then :
> =

>  $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
> =

> @@ -8573,7 +8619,7 @@ fi
>  for ac_header in stdlib.h
>  do :
>    ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
> -if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
> +if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_STDLIB_H 1
>  _ACEOF
> @@ -8584,7 +8630,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e malloc" >&5
>  $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
> -if test "${ac_cv_func_malloc_0_nonnull+set}" =3D set; then :
> +if ${ac_cv_func_malloc_0_nonnull+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8639,7 +8685,7 @@ fi
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys=
/time.h may both be included" >&5
>  $as_echo_n "checking whether time.h and sys/time.h may both be included.=
.. " >&6; }
> -if test "${ac_cv_header_time+set}" =3D set; then :
> +if ${ac_cv_header_time+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> @@ -8714,7 +8760,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&5
>  $as_echo_n "checking for working mktime... " >&6; }
> -if test "${ac_cv_func_working_mktime+set}" =3D set; then :
> +if ${ac_cv_func_working_mktime+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -8943,7 +8989,7 @@ fi
>  for ac_func in getpagesize
>  do :
>    ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
> -if test "x$ac_cv_func_getpagesize" =3D x""yes; then :
> +if test "x$ac_cv_func_getpagesize" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_GETPAGESIZE 1
>  _ACEOF
> @@ -8953,7 +8999,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
>  $as_echo_n "checking for working mmap... " >&6; }
> -if test "${ac_cv_func_mmap_fixed_mapped+set}" =3D set; then :
> +if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -9120,7 +9166,7 @@ rm -f conftest.mmap conftest.txt
>  for ac_header in stdlib.h
>  do :
>    ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib=
_h" "$ac_includes_default"
> -if test "x$ac_cv_header_stdlib_h" =3D x""yes; then :
> +if test "x$ac_cv_header_stdlib_h" =3D xyes; then :
>    cat >>confdefs.h <<_ACEOF
>  #define HAVE_STDLIB_H 1
>  _ACEOF
> @@ -9131,7 +9177,7 @@ done
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatibl=
e realloc" >&5
>  $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
> -if test "${ac_cv_func_realloc_0_nonnull+set}" =3D set; then :
> +if ${ac_cv_func_realloc_0_nonnull+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -9184,13 +9230,17 @@ $as_echo "#define realloc rpl_realloc" >>confdefs=
.h
>  fi
> =

> =

> -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >=
&5
> + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" =
>&5
>  $as_echo_n "checking for working strnlen... " >&6; }
> -if test "${ac_cv_func_strnlen_working+set}" =3D set; then :
> +if ${ac_cv_func_strnlen_working+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> -  ac_cv_func_strnlen_working=3Dno
> +  # Guess no on AIX systems, yes otherwise.
> +               case "$host_os" in
> +                 aix*) ac_cv_func_strnlen_working=3Dno;;
> +                 *)    ac_cv_func_strnlen_working=3Dyes;;
> +               esac
>  else
>    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>  /* end confdefs.h.  */
> @@ -9239,7 +9289,7 @@ esac
> =

>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&5
>  $as_echo_n "checking for working strtod... " >&6; }
> -if test "${ac_cv_func_strtod+set}" =3D set; then :
> +if ${ac_cv_func_strtod+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    if test "$cross_compiling" =3D yes; then :
> @@ -9298,14 +9348,14 @@ if test $ac_cv_func_strtod =3D no; then
>  esac
> =

>  ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
> -if test "x$ac_cv_func_pow" =3D x""yes; then :
> +if test "x$ac_cv_func_pow" =3D xyes; then :
> =

>  fi
> =

>  if test $ac_cv_func_pow =3D no; then
>    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
>  $as_echo_n "checking for pow in -lm... " >&6; }
> -if test "${ac_cv_lib_m_pow+set}" =3D set; then :
> +if ${ac_cv_lib_m_pow+:} false; then :
>    $as_echo_n "(cached) " >&6
>  else
>    ac_check_lib_save_LIBS=3D$LIBS
> @@ -9339,7 +9389,7 @@ LIBS=3D$ac_check_lib_save_LIBS
>  fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
>  $as_echo "$ac_cv_lib_m_pow" >&6; }
> -if test "x$ac_cv_lib_m_pow" =3D x""yes; then :
> +if test "x$ac_cv_lib_m_pow" =3D xyes; then :
>    POW_LIB=3D-lm
>  else
>    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library =
containing definition of pow" >&5
> @@ -9435,10 +9485,21 @@ $as_echo "$as_me: WARNING: cache variable $ac_var=
 contains a newline" >&2;} ;;
>       :end' >>confcache
>  if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
>    if test -w "$cache_file"; then
> -    test "x$cache_file" !=3D "x/dev/null" &&
> +    if test "x$cache_file" !=3D "x/dev/null"; then
>        { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_fil=
e" >&5
>  $as_echo "$as_me: updating cache $cache_file" >&6;}
> -    cat confcache >$cache_file
> +      if test ! -f "$cache_file" || test -h "$cache_file"; then
> +       cat confcache >"$cache_file"
> +      else
> +        case $cache_file in #(
> +        */* | ?:*)
> +         mv -f confcache "$cache_file"$$ &&
> +         mv -f "$cache_file"$$ "$cache_file" ;; #(
> +        *)
> +         mv -f confcache "$cache_file" ;;
> +       esac
> +      fi
> +    fi
>    else
>      { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cac=
he $cache_file" >&5
>  $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
> @@ -9470,7 +9531,7 @@ LTLIBOBJS=3D$ac_ltlibobjs
> =

> =

> =

> -: ${CONFIG_STATUS=3D./config.status}
> +: "${CONFIG_STATUS=3D./config.status}"
>  ac_write_fail=3D0
>  ac_clean_files_save=3D$ac_clean_files
>  ac_clean_files=3D"$ac_clean_files $CONFIG_STATUS"
> @@ -9571,6 +9632,7 @@ fi
>  IFS=3D" ""       $as_nl"
> =

>  # Find who we are.  Look in the path if we contain no directory separato=
r.
> +as_myself=3D
>  case $0 in #((
>    *[\\/]* ) as_myself=3D$0 ;;
>    *) as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
> @@ -9878,7 +9940,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=3D1
>  # values after options handling.
>  ac_log=3D"
>  This file was extended by Xen Hypervisor $as_me 4.2, which was
> -generated by GNU Autoconf 2.67.  Invocation command line was
> +generated by GNU Autoconf 2.68.  Invocation command line was
> =

>    CONFIG_FILES    =3D $CONFIG_FILES
>    CONFIG_HEADERS  =3D $CONFIG_HEADERS
> @@ -9940,7 +10002,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
>  ac_cs_config=3D"`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\=
$]/\\\\&/g'`"
>  ac_cs_version=3D"\\
>  Xen Hypervisor config.status 4.2
> -configured by $0, generated by GNU Autoconf 2.67,
> +configured by $0, generated by GNU Autoconf 2.68,
>    with options \\"\$ac_cs_config\\"
> =

>  Copyright (C) 2010 Free Software Foundation, Inc.
> @@ -10064,7 +10126,7 @@ do
>      "../config/Tools.mk") CONFIG_FILES=3D"$CONFIG_FILES ../config/Tools.=
mk" ;;
>      "config.h") CONFIG_HEADERS=3D"$CONFIG_HEADERS config.h" ;;
> =

> -  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
 ;;
> +  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5=
;;
>    esac
>  done
> =

> @@ -10086,9 +10148,10 @@ fi
>  # after its creation but before its name has been assigned to `$tmp'.
>  $debug ||
>  {
> -  tmp=3D
> +  tmp=3D ac_tmp=3D
>    trap 'exit_status=3D$?
> -  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit=
_status
> +  : "${ac_tmp:=3D$tmp}"
> +  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
>  ' 0
>    trap 'as_fn_exit 1' 1 2 13 15
>  }
> @@ -10096,12 +10159,13 @@ $debug ||
> =

>  {
>    tmp=3D`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
> -  test -n "$tmp" && test -d "$tmp"
> +  test -d "$tmp"
>  }  ||
>  {
>    tmp=3D./conf$$-$RANDOM
>    (umask 077 && mkdir "$tmp")
>  } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO"=
 5
> +ac_tmp=3D$tmp
> =

>  # Set up the scripts for CONFIG_FILES section.
>  # No need to generate them if there are no CONFIG_FILES.
> @@ -10123,7 +10187,7 @@ else
>    ac_cs_awk_cr=3D$ac_cr
>  fi
> =

> -echo 'BEGIN {' >"$tmp/subs1.awk" &&
> +echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
>  _ACEOF
> =

> =

> @@ -10151,7 +10215,7 @@ done
>  rm -f conf$$subs.sh
> =

>  cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
> -cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
> +cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
>  _ACEOF
>  sed -n '
>  h
> @@ -10199,7 +10263,7 @@ t delim
>  rm -f conf$$subs.awk
>  cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=3D1
>  _ACAWK
> -cat >>"\$tmp/subs1.awk" <<_ACAWK &&
> +cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
>    for (key in S) S_is_set[key] =3D 1
>    FS =3D "=07"
> =

> @@ -10231,7 +10295,7 @@ if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1;=
 then
>    sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
>  else
>    cat
> -fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
> +fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
>    || as_fn_error $? "could not setup config files machinery" "$LINENO" 5
>  _ACEOF
> =

> @@ -10265,7 +10329,7 @@ fi # test -n "$CONFIG_FILES"
>  # No need to generate them if there are no CONFIG_HEADERS.
>  # This happens for instance with `./config.status Makefile'.
>  if test -n "$CONFIG_HEADERS"; then
> -cat >"$tmp/defines.awk" <<\_ACAWK ||
> +cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
>  BEGIN {
>  _ACEOF
> =

> @@ -10277,8 +10341,8 @@ _ACEOF
>  # handling of long lines.
>  ac_delim=3D'%!_!# '
>  for ac_last_try in false false :; do
> -  ac_t=3D`sed -n "/$ac_delim/p" confdefs.h`
> -  if test -z "$ac_t"; then
> +  ac_tt=3D`sed -n "/$ac_delim/p" confdefs.h`
> +  if test -z "$ac_tt"; then
>      break
>    elif $ac_last_try; then
>      as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
> @@ -10379,7 +10443,7 @@ do
>    esac
>    case $ac_mode$ac_tag in
>    :[FHL]*:*);;
> -  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
> +  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
>    :[FH]-) ac_tag=3D-:-;;
>    :[FH]*) ac_tag=3D$ac_tag:$ac_tag.in;;
>    esac
> @@ -10398,7 +10462,7 @@ do
>      for ac_f
>      do
>        case $ac_f in
> -      -) ac_f=3D"$tmp/stdin";;
> +      -) ac_f=3D"$ac_tmp/stdin";;
>        *) # Look for the file first in the build tree, then in the source=
 tree
>          # (if the path is not absolute).  The absolute path cannot be DO=
S-style,
>          # because $ac_f cannot contain `:'.
> @@ -10407,7 +10471,7 @@ do
>            [\\/$]*) false;;
>            *) test -f "$srcdir/$ac_f" && ac_f=3D"$srcdir/$ac_f";;
>            esac ||
> -          as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
> +          as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
>        esac
>        case $ac_f in *\'*) ac_f=3D`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\'=
'/g"`;; esac
>        as_fn_append ac_file_inputs " '$ac_f'"
> @@ -10433,8 +10497,8 @@ $as_echo "$as_me: creating $ac_file" >&6;}
>      esac
> =

>      case $ac_tag in
> -    *:-:* | *:-) cat >"$tmp/stdin" \
> -      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
> +    *:-:* | *:-) cat >"$ac_tmp/stdin" \
> +      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
>      esac
>      ;;
>    esac
> @@ -10564,21 +10628,22 @@ s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
>  s&@INSTALL@&$ac_INSTALL&;t t
>  $ac_datarootdir_hack
>  "
> -eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" =
>$tmp/out \
> -  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
> +eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.aw=
k" \
> +  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5
> =

>  test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
> -  { ac_out=3D`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"=
; } &&
> -  { ac_out=3D`sed -n '/^[         ]*datarootdir[  ]*:*=3D/p' "$tmp/out"`=
; test -z "$ac_out"; } &&
> +  { ac_out=3D`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_o=
ut"; } &&
> +  { ac_out=3D`sed -n '/^[         ]*datarootdir[  ]*:*=3D/p' \
> +      "$ac_tmp/out"`; test -z "$ac_out"; } &&
>    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a =
reference to the variable \`datarootdir'
>  which seems to be undefined.  Please make sure it is defined" >&5
>  $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable=
 \`datarootdir'
>  which seems to be undefined.  Please make sure it is defined" >&2;}
> =

> -  rm -f "$tmp/stdin"
> +  rm -f "$ac_tmp/stdin"
>    case $ac_file in
> -  -) cat "$tmp/out" && rm -f "$tmp/out";;
> -  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
> +  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
> +  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
>    esac \
>    || as_fn_error $? "could not create $ac_file" "$LINENO" 5
>   ;;
> @@ -10589,20 +10654,20 @@ which seems to be undefined.  Please make sure =
it is defined" >&2;}
>    if test x"$ac_file" !=3D x-; then
>      {
>        $as_echo "/* $configure_input  */" \
> -      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
> -    } >"$tmp/config.h" \
> +      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
> +    } >"$ac_tmp/config.h" \
>        || as_fn_error $? "could not create $ac_file" "$LINENO" 5
> -    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
> +    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
>        { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&5
>  $as_echo "$as_me: $ac_file is unchanged" >&6;}
>      else
>        rm -f "$ac_file"
> -      mv "$tmp/config.h" "$ac_file" \
> +      mv "$ac_tmp/config.h" "$ac_file" \
>         || as_fn_error $? "could not create $ac_file" "$LINENO" 5
>      fi
>    else
>      $as_echo "/* $configure_input  */" \
> -      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
> +      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
>        || as_fn_error $? "could not create -" "$LINENO" 5
>    fi
>   ;;
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 250dffd..ddabfef 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -106,6 +106,7 @@ AX_PATH_PROG_OR_FAIL([AS86], [as86])
>  AX_PATH_PROG_OR_FAIL([LD86], [ld86])
>  AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>  AX_PATH_PROG_OR_FAIL([IASL], [iasl])
> +AX_PATH_PROG_OR_FAIL([FLEX], [flex])
>  AX_CHECK_UUID
>  AX_CHECK_CURSES
>  PKG_CHECK_MODULES(glib, glib-2.0)
> --
> 1.7.9.5
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 07:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJggj-0005wz-6Y; Mon, 16 Apr 2012 07:49:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJggh-0005wh-Gv
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 07:49:27 +0000
Received: from [193.109.254.147:60684] by server-10.bemta-14.messagelabs.com
	id A7/97-05847-60FCB8F4; Mon, 16 Apr 2012 07:49:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334562566!1636347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15158 invoked from network); 16 Apr 2012 07:49:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11947114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:49:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 08:49:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJggf-0007Tq-Mx;
	Mon, 16 Apr 2012 07:49:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJggf-0000rS-HF;
	Mon, 16 Apr 2012 08:49:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12698-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 08:49:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12698: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12698 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12698/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12695
 test-i386-i386-xl             9 guest-start                 fail pass in 12695

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12695

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12695 never pass

version targeted for testing:
 xen                  6b72eb3b40cf
baseline version:
 xen                  6b72eb3b40cf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 07:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJggj-0005wz-6Y; Mon, 16 Apr 2012 07:49:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJggh-0005wh-Gv
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 07:49:27 +0000
Received: from [193.109.254.147:60684] by server-10.bemta-14.messagelabs.com
	id A7/97-05847-60FCB8F4; Mon, 16 Apr 2012 07:49:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334562566!1636347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15158 invoked from network); 16 Apr 2012 07:49:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11947114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:49:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 08:49:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJggf-0007Tq-Mx;
	Mon, 16 Apr 2012 07:49:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJggf-0000rS-HF;
	Mon, 16 Apr 2012 08:49:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12698-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 08:49:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12698: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12698 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12698/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12695
 test-i386-i386-xl             9 guest-start                 fail pass in 12695

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12695

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12695 never pass

version targeted for testing:
 xen                  6b72eb3b40cf
baseline version:
 xen                  6b72eb3b40cf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 07:53:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgkO-0006DE-TW; Mon, 16 Apr 2012 07:53:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJgkN-0006D7-RR
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 07:53:16 +0000
Received: from [85.158.143.35:39939] by server-2.bemta-4.messagelabs.com id
	B2/D0-17550-BEFCB8F4; Mon, 16 Apr 2012 07:53:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334562794!8990093!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21563 invoked from network); 16 Apr 2012 07:53:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:53:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11947177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:53:13 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 08:53:13 +0100
Message-ID: <1334562793.4445.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 08:53:13 +0100
In-Reply-To: <1334342414-10289-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/20] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
> Crash on POLLNVAL since that means our fds are messed up.
> 
> Document the behaviour (including the fact that poll sometimes sets
> POLLHUP or POLLERR even if only POLLIN was requested.
> 
> Fix the one current fd callback to do something with POLLERR|POLLHUP.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_event.c    |    7 ++++++-
>  tools/libxl/libxl_internal.h |    5 +++++
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 638b9ab..5e1a207 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>  {
>      EGC_GC;
>  
> +    if (revents & (POLLERR|POLLHUP))
> +        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
> +
>      for (;;) {
>          char **event = xs_check_watch(CTX->xsh);
>          if (!event) {
> @@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
>          /* again, stale slot entry */
>          return 0;
>  
> -    int revents = fds[slot].revents & events;
> +    assert(!(fds[slot].revents & POLLNVAL));
> +
> +    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
>      /* we mask in case requested events have changed */
>  
>      return revents;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index a4b933b..af631fb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
>  typedef struct libxl__ev_fd libxl__ev_fd;
>  typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>                                     int fd, short events, short revents);
> +  /* Note that revents may contain POLLERR or POLLHUP regardless of
> +   * events; otherwise revents contains only bits in events.  Contrary
> +   * to the documentation for poll(2), POLLERR and POLLHUP can occur
> +   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
> +   * error and will cause libxl event machinery to fail an assertion.) */
>  struct libxl__ev_fd {
>      /* caller should include this in their own struct */
>      /* read-only for caller, who may read only when registered: */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 07:53:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 07:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgkO-0006DE-TW; Mon, 16 Apr 2012 07:53:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJgkN-0006D7-RR
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 07:53:16 +0000
Received: from [85.158.143.35:39939] by server-2.bemta-4.messagelabs.com id
	B2/D0-17550-BEFCB8F4; Mon, 16 Apr 2012 07:53:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334562794!8990093!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21563 invoked from network); 16 Apr 2012 07:53:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 07:53:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11947177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 07:53:13 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 08:53:13 +0100
Message-ID: <1334562793.4445.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 08:53:13 +0100
In-Reply-To: <1334342414-10289-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/20] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
> Crash on POLLNVAL since that means our fds are messed up.
> 
> Document the behaviour (including the fact that poll sometimes sets
> POLLHUP or POLLERR even if only POLLIN was requested.
> 
> Fix the one current fd callback to do something with POLLERR|POLLHUP.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_event.c    |    7 ++++++-
>  tools/libxl/libxl_internal.h |    5 +++++
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 638b9ab..5e1a207 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>  {
>      EGC_GC;
>  
> +    if (revents & (POLLERR|POLLHUP))
> +        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
> +
>      for (;;) {
>          char **event = xs_check_watch(CTX->xsh);
>          if (!event) {
> @@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
>          /* again, stale slot entry */
>          return 0;
>  
> -    int revents = fds[slot].revents & events;
> +    assert(!(fds[slot].revents & POLLNVAL));
> +
> +    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
>      /* we mask in case requested events have changed */
>  
>      return revents;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index a4b933b..af631fb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
>  typedef struct libxl__ev_fd libxl__ev_fd;
>  typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
>                                     int fd, short events, short revents);
> +  /* Note that revents may contain POLLERR or POLLHUP regardless of
> +   * events; otherwise revents contains only bits in events.  Contrary
> +   * to the documentation for poll(2), POLLERR and POLLHUP can occur
> +   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
> +   * error and will cause libxl event machinery to fail an assertion.) */
>  struct libxl__ev_fd {
>      /* caller should include this in their own struct */
>      /* read-only for caller, who may read only when registered: */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 08:04:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgv0-0007Bc-MU; Mon, 16 Apr 2012 08:04:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJguz-0007BW-NN
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 08:04:13 +0000
Received: from [85.158.143.99:23505] by server-3.bemta-4.messagelabs.com id
	33/FA-05853-D72DB8F4; Mon, 16 Apr 2012 08:04:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334563451!23772290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18248 invoked from network); 16 Apr 2012 08:04:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 08:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11947420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 08:04:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 09:04:11 +0100
Message-ID: <1334563449.4445.24.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 09:04:09 +0100
In-Reply-To: <1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds
 for the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> We need a slightly more sophisticated data structure to allow this,
> where we record the slot not just for each fd but also for each
> (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Just to be sure I'm following: By multiple you mean you can have one
libxl__ev_fds listening for e.g. POLLIN and another for POLLOUT but you
specifically exclude the case where two libxl__ev_fds both want to
listen for POLLIN? Similarly one listening for POLLIN|POLLPRI and the
other for POLLOUT|POLLPRI (overlapping) is forbidden.

> Document the new relaxed restriction.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
>  tools/libxl/libxl_internal.h |   10 +++++--
>  2 files changed, 42 insertions(+), 30 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 5e1a207..672e3fe 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>  
> 
>      /*
> -     * In order to be able to efficiently find the libxl__ev_fd
> -     * for a struct poll during _afterpoll, we maintain a shadow
> -     * data structure in CTX->fd_beforepolled: each slot in
> -     * the fds array corresponds to a slot in fd_beforepolled.
> +     * In order to be able to efficiently find the libxl__ev_fd for a
> +     * struct poll during _afterpoll, we maintain a shadow data
> +     * structure in CTX->fd_rindices: each fd corresponds to a slot in
> +     * fd_rindices, and each elemebnt in the rindices is three indices

                               element

> +     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
>       */
>  
>      if (*nfds_io) {
> @@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>          });
>  
>          /* make sure our array is as big as *nfds_io */
> -        if (poller->fd_rindex_allocd < maxfd) {
> -            assert(maxfd < INT_MAX / sizeof(int) / 2);
> -            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
> -            if (!newarray) { rc = ERROR_NOMEM; goto out; }
> -            memset(newarray + poller->fd_rindex_allocd, 0,
> -                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
> -            poller->fd_rindex = newarray;
> -            poller->fd_rindex_allocd = maxfd;
> +        if (poller->fd_rindices_allocd < maxfd) {
> +            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
> +            poller->fd_rindices =
> +                libxl__realloc(0, poller->fd_rindices,
> +                               maxfd * sizeof(*poller->fd_rindices));
> +            memset(poller->fd_rindices + poller->fd_rindices_allocd,
> +                   0,
> +                   (maxfd - poller->fd_rindices_allocd)
> +                     * sizeof(*poller->fd_rindices));
> +            poller->fd_rindices_allocd = maxfd;
>          }
>      }
>  
> @@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>              fds[used].fd = req_fd;
>              fds[used].events = req_events;
>              fds[used].revents = 0;
> -            assert(req_fd < poller->fd_rindex_allocd);
> -            poller->fd_rindex[req_fd] = used;
> +            assert(req_fd < poller->fd_rindices_allocd);
> +            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
> +            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
> +            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;

Would it be possible to have a little struct here instead of the [3]? So
you'd get
	poller->fd_rindeices[req_fd].{in,pri,out}
?

Ah, I see this would make afterpoll_check_fd more complex which I think
would outweigh any gain here.

So, other than the typoe:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 08:04:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJgv0-0007Bc-MU; Mon, 16 Apr 2012 08:04:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJguz-0007BW-NN
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 08:04:13 +0000
Received: from [85.158.143.99:23505] by server-3.bemta-4.messagelabs.com id
	33/FA-05853-D72DB8F4; Mon, 16 Apr 2012 08:04:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334563451!23772290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18248 invoked from network); 16 Apr 2012 08:04:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 08:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11947420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 08:04:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 09:04:11 +0100
Message-ID: <1334563449.4445.24.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 09:04:09 +0100
In-Reply-To: <1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds
 for the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> We need a slightly more sophisticated data structure to allow this,
> where we record the slot not just for each fd but also for each
> (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Just to be sure I'm following: By multiple you mean you can have one
libxl__ev_fds listening for e.g. POLLIN and another for POLLOUT but you
specifically exclude the case where two libxl__ev_fds both want to
listen for POLLIN? Similarly one listening for POLLIN|POLLPRI and the
other for POLLOUT|POLLPRI (overlapping) is forbidden.

> Document the new relaxed restriction.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
>  tools/libxl/libxl_internal.h |   10 +++++--
>  2 files changed, 42 insertions(+), 30 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 5e1a207..672e3fe 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>  
> 
>      /*
> -     * In order to be able to efficiently find the libxl__ev_fd
> -     * for a struct poll during _afterpoll, we maintain a shadow
> -     * data structure in CTX->fd_beforepolled: each slot in
> -     * the fds array corresponds to a slot in fd_beforepolled.
> +     * In order to be able to efficiently find the libxl__ev_fd for a
> +     * struct poll during _afterpoll, we maintain a shadow data
> +     * structure in CTX->fd_rindices: each fd corresponds to a slot in
> +     * fd_rindices, and each elemebnt in the rindices is three indices

                               element

> +     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
>       */
>  
>      if (*nfds_io) {
> @@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>          });
>  
>          /* make sure our array is as big as *nfds_io */
> -        if (poller->fd_rindex_allocd < maxfd) {
> -            assert(maxfd < INT_MAX / sizeof(int) / 2);
> -            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
> -            if (!newarray) { rc = ERROR_NOMEM; goto out; }
> -            memset(newarray + poller->fd_rindex_allocd, 0,
> -                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
> -            poller->fd_rindex = newarray;
> -            poller->fd_rindex_allocd = maxfd;
> +        if (poller->fd_rindices_allocd < maxfd) {
> +            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
> +            poller->fd_rindices =
> +                libxl__realloc(0, poller->fd_rindices,
> +                               maxfd * sizeof(*poller->fd_rindices));
> +            memset(poller->fd_rindices + poller->fd_rindices_allocd,
> +                   0,
> +                   (maxfd - poller->fd_rindices_allocd)
> +                     * sizeof(*poller->fd_rindices));
> +            poller->fd_rindices_allocd = maxfd;
>          }
>      }
>  
> @@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>              fds[used].fd = req_fd;
>              fds[used].events = req_events;
>              fds[used].revents = 0;
> -            assert(req_fd < poller->fd_rindex_allocd);
> -            poller->fd_rindex[req_fd] = used;
> +            assert(req_fd < poller->fd_rindices_allocd);
> +            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
> +            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
> +            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;

Would it be possible to have a little struct here instead of the [3]? So
you'd get
	poller->fd_rindeices[req_fd].{in,pri,out}
?

Ah, I see this would make afterpoll_check_fd more complex which I think
would outweigh any gain here.

So, other than the typoe:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 08:16:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJh6u-0007TT-UY; Mon, 16 Apr 2012 08:16:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJh6s-0007TO-UB
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 08:16:31 +0000
Received: from [85.158.143.35:25382] by server-3.bemta-4.messagelabs.com id
	0E/80-05853-E55DB8F4; Mon, 16 Apr 2012 08:16:30 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334564188!5098889!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4247 invoked from network); 16 Apr 2012 08:16:29 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-9.tower-21.messagelabs.com with SMTP;
	16 Apr 2012 08:16:29 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id B8DE8DBA90
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 16:16:11 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so4331471vcb.32
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 01:16:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.198.135 with SMTP id eo7mr5568490vcb.35.1334564168041;
	Mon, 16 Apr 2012 01:16:08 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Mon, 16 Apr 2012 01:16:07 -0700 (PDT)
In-Reply-To: <1334154629.3943.4.camel@hp6530s>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<20120411134648.GB21703@andromeda.dapyr.net>
	<1334154629.3943.4.camel@hp6530s>
Date: Mon, 16 Apr 2012 16:16:07 +0800
Message-ID: <CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, wei.huang2@amd.com,
	marcus.granado@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 10:30 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:

[....]

>> That isn't actually true. If you run it, you will see it working
>> in the guest - it just that it does not use the performence counters
>> but instead uses the timer to sample data.
>
> Right, I mean "hardware event" does not work.
>
> Hardware event, for example, perf top -e cycles, does not work.

Just found that vpmu is disabled by default.
You need to pass xen boot parameter "vpmu" to make hardware event work.

> Software event, for example, perf top -e cpu-clock, works.

So both hardware and software event work in DomU.
Great!

>
>>
>> > Run "perf top", but no data was collected.
>>
>> Hm, I am able to collect data using Fedora Core 16 PV guest.
>> For dom0 or domU? For dom0 there is a bug somewhere where
>
> For domU HVM guest.
> I have problem to run domU PV guest. Still looking at it.
>
>> the machine crashes after 30 seconds or so - hadn't actually
>> gotten to the bottom of it. There was an email thread:
>> https://lkml.org/lkml/2012/2/12/74 about this.
>>
>> Patches are most welcome!

Here are the patches.
https://lkml.org/lkml/2012/4/15/12

Regards,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 08:16:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJh6u-0007TT-UY; Mon, 16 Apr 2012 08:16:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SJh6s-0007TO-UB
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 08:16:31 +0000
Received: from [85.158.143.35:25382] by server-3.bemta-4.messagelabs.com id
	0E/80-05853-E55DB8F4; Mon, 16 Apr 2012 08:16:30 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334564188!5098889!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4247 invoked from network); 16 Apr 2012 08:16:29 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-9.tower-21.messagelabs.com with SMTP;
	16 Apr 2012 08:16:29 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id B8DE8DBA90
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 16:16:11 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so4331471vcb.32
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 01:16:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.198.135 with SMTP id eo7mr5568490vcb.35.1334564168041;
	Mon, 16 Apr 2012 01:16:08 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Mon, 16 Apr 2012 01:16:07 -0700 (PDT)
In-Reply-To: <1334154629.3943.4.camel@hp6530s>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<20120411134648.GB21703@andromeda.dapyr.net>
	<1334154629.3943.4.camel@hp6530s>
Date: Mon, 16 Apr 2012 16:16:07 +0800
Message-ID: <CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, wei.huang2@amd.com,
	marcus.granado@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 11, 2012 at 10:30 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:

[....]

>> That isn't actually true. If you run it, you will see it working
>> in the guest - it just that it does not use the performence counters
>> but instead uses the timer to sample data.
>
> Right, I mean "hardware event" does not work.
>
> Hardware event, for example, perf top -e cycles, does not work.

Just found that vpmu is disabled by default.
You need to pass xen boot parameter "vpmu" to make hardware event work.

> Software event, for example, perf top -e cpu-clock, works.

So both hardware and software event work in DomU.
Great!

>
>>
>> > Run "perf top", but no data was collected.
>>
>> Hm, I am able to collect data using Fedora Core 16 PV guest.
>> For dom0 or domU? For dom0 there is a bug somewhere where
>
> For domU HVM guest.
> I have problem to run domU PV guest. Still looking at it.
>
>> the machine crashes after 30 seconds or so - hadn't actually
>> gotten to the bottom of it. There was an email thread:
>> https://lkml.org/lkml/2012/2/12/74 about this.
>>
>> Patches are most welcome!

Here are the patches.
https://lkml.org/lkml/2012/4/15/12

Regards,
Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 08:55:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:55:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhhl-0007k6-3a; Mon, 16 Apr 2012 08:54:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJhhk-0007k1-6D
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 08:54:36 +0000
Received: from [193.109.254.147:57562] by server-7.bemta-14.messagelabs.com id
	D0/29-01627-B4EDB8F4; Mon, 16 Apr 2012 08:54:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334566473!2281387!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18482 invoked from network); 16 Apr 2012 08:54:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 08:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330923600"; d="scan'208";a="190457198"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 04:54:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 04:54:33 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJhhg-0003rK-MO;
	Mon, 16 Apr 2012 09:54:32 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
Date: Mon, 16 Apr 2012 09:54:34 +0100
Message-ID: <115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 15/04/2012, a las 19:43, Jean Guyader escribi=F3:
> libxl require the command flex to be present.
> Verify in the configure script that the flex
> command exsits.
> =

> Signed-off-by: Jean Guyader <jean.guyader@gmail.com>


I've already sent a patch for this, detecting and setting Flex and Bison at=
 configure, and printing a pretty error message if libxl needs them and the=
y are not found:

http://lists.xen.org/archives/html/xen-devel/2012-04/msg00923.html

I've been able to build xen without Flex or Bison, so I'm not sure if we sh=
ould enforce them to be present on the system.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 08:55:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:55:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhhl-0007k6-3a; Mon, 16 Apr 2012 08:54:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJhhk-0007k1-6D
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 08:54:36 +0000
Received: from [193.109.254.147:57562] by server-7.bemta-14.messagelabs.com id
	D0/29-01627-B4EDB8F4; Mon, 16 Apr 2012 08:54:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334566473!2281387!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18482 invoked from network); 16 Apr 2012 08:54:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 08:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330923600"; d="scan'208";a="190457198"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 04:54:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 04:54:33 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJhhg-0003rK-MO;
	Mon, 16 Apr 2012 09:54:32 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
Date: Mon, 16 Apr 2012 09:54:34 +0100
Message-ID: <115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 15/04/2012, a las 19:43, Jean Guyader escribi=F3:
> libxl require the command flex to be present.
> Verify in the configure script that the flex
> command exsits.
> =

> Signed-off-by: Jean Guyader <jean.guyader@gmail.com>


I've already sent a patch for this, detecting and setting Flex and Bison at=
 configure, and printing a pretty error message if libxl needs them and the=
y are not found:

http://lists.xen.org/archives/html/xen-devel/2012-04/msg00923.html

I've been able to build xen without Flex or Bison, so I'm not sure if we sh=
ould enforce them to be present on the system.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 08:56:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhig-0007md-IT; Mon, 16 Apr 2012 08:55:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SJhie-0007mW-Ke
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 08:55:33 +0000
Received: from [85.158.139.83:27391] by server-12.bemta-5.messagelabs.com id
	5D/39-05587-38EDB8F4; Mon, 16 Apr 2012 08:55:31 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334566528!23972030!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEzMDkz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3343 invoked from network); 16 Apr 2012 08:55:29 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-182.messagelabs.com with SMTP;
	16 Apr 2012 08:55:29 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 16 Apr 2012 01:55:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,217";a="131358469"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 16 Apr 2012 01:55:26 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 16 Apr 2012 01:55:26 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.195]) with mapi id
	14.01.0355.002; Mon, 16 Apr 2012 16:55:14 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Aleksandr Tarutin <atarutin@orionsbelt.net>
Thread-Topic: [Xen-devel] PCI Passthrough of SAS controller not working
Thread-Index: AQHNGB0PzLWiCnCV1EGhgknobH6H3JadKdsg
Date: Mon, 16 Apr 2012 08:55:14 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD11C89@SHSMSX102.ccr.corp.intel.com>
References: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
In-Reply-To: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: multipart/alternative;
	boundary="_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_"

--_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In your guest lspci log file, I do see the attached SAS device is owned by =
mpt2sas driver in your guest log.

We did simple testing with a SAS controller assignment to RHEL6.2 guest on =
Xen unstable 25164, both passthrough and pci-attach/detach works well.

Sharing the log to you, and can you update your Xen to latest and try?


Thanks,
-Xudong

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Aleksandr Tarutin
Sent: Thursday, April 12, 2012 3:52 AM
To: xen-devel@lists.xen.org
Subject: [Xen-devel] PCI Passthrough of SAS controller not working

Hello.

I tried to setup PCI Passthrough of a SAS controller into a PVHVM domU. The=
 device was present in the domU but its modules wouldn't load.

The first related thing was the following message in the guest BIOS just be=
fore grub starts:
MPT BIOS Fault 09h encountered at adapter PCI(00h,05h,00h).

I'm attaching the xm dmesg and dmesg from both the host and a guest as well=
 as lspci -v.

--
AT.


--_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In your gu=
est lspci log file, I do see the attached SAS device is owned by mpt2sas dr=
iver in your guest log.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">We did sim=
ple testing with a SAS controller assignment to RHEL6.2 guest on Xen unstab=
le 25164, both passthrough and pci-attach/detach works well.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Sharing th=
e log to you, and can you update your Xen to latest and try?<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:p></o:p></span></=
p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1F497D">-Xudong<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> xen-devel-bounces@lists.xen.org [mailto:xen-devel-bou=
nces@lists.xen.org]
<b>On Behalf Of </b>Aleksandr Tarutin<br>
<b>Sent:</b> Thursday, April 12, 2012 3:52 AM<br>
<b>To:</b> xen-devel@lists.xen.org<br>
<b>Subject:</b> [Xen-devel] PCI Passthrough of SAS controller not working<o=
:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hello.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I tried to setup PCI Passthroug=
h of a SAS controller into a PVHVM domU. The device was present in the domU=
 but its modules wouldn't load.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The first related thing was the=
 following message in the guest BIOS just before grub starts:<o:p></o:p></s=
pan></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">MPT BIOS Fault 09h encountered =
at adapter&nbsp;PCI(00h,05h,00h).<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I'm attaching the xm dmesg and =
dmesg from both the host and a guest as well as lspci -v.<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">-- <o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">AT.<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_--

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: application/octet-stream; name="dom0_lspci"
Content-Description: dom0_lspci
Content-Disposition: attachment; filename="dom0_lspci"; size=3334;
	creation-date="Mon, 16 Apr 2012 08:52:53 GMT";
	modification-date="Mon, 16 Apr 2012 01:55:42 GMT"
Content-Transfer-Encoding: base64

MDc6MDAuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlv
biBQYXRzYnVyZyA0LVBvcnQgU0FUQS9TQVMgU3RvcmFnZSBDb250cm9sIFVuaXQgKHJldiAwNSkK
CVN1YnN5c3RlbTogSW50ZWwgQ29ycG9yYXRpb24gRGV2aWNlIDM1ODUKCUNvbnRyb2w6IEkvTysg
TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+
U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTYKCVJlZ2lvbiAwOiBNZW1vcnkgYXQg
ZWI4MDAwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdCglSZWdpb24gMjogTWVt
b3J5IGF0IGViNDAwMDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9NE1dCglSZWdpb24g
NDogSS9PIHBvcnRzIGF0IDIwMDAgW3NpemU9MjU2XQoJQ2FwYWJpbGl0aWVzOiBbOThdIFBvd2Vy
IE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1
cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5v
U29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczog
W2M0XSBFeHByZXNzICh2MikgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAx
MDI0IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQKCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldCsKCQlE
ZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1
cHBvcnRlZC0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsg
RkxSZXNldC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTAyNCBieXRlcwoJ
CURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3It
IFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cwoJCQlDbG9ja1BNLSBTdXJwcmlz
ZS0gTExBY3RSZXAtIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVz
IERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lk
RGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNh
cDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcy0KCQlEZXZD
dGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtD
dGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9y
bWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VT
T1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBE
ZS1lbXBoYXNpcyBMZXZlbDogLTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSS1YOiBFbmFibGUr
IENvdW50PTIgTWFza2VkLQoJCVZlY3RvciB0YWJsZTogQkFSPTAgb2Zmc2V0PTAwMDAyMDAwCgkJ
UEJBOiBCQVI9MCBvZmZzZXQ9MDAwMDMwMDAKCUNhcGFiaWxpdGllczogWzEwMF0gQWR2YW5jZWQg
RXJyb3IgUmVwb3J0aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENt
cGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxKyBBQ1NWaW9s
LQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENt
cGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURM
UCsgU0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1h
bGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBC
YWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4RXJyLSBC
YWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6
CUZpcnN0IEVycm9yIFBvaW50ZXI6IDE0LCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtFbi0K
CUNhcGFiaWxpdGllczogWzEzOF0gQWx0ZXJuYXRpdmUgUm91dGluZy1JRCBJbnRlcnByZXRhdGlv
biAoQVJJKQoJCUFSSUNhcDoJTUZWQy0gQUNTLSwgTmV4dCBGdW5jdGlvbjogMwoJCUFSSUN0bDoJ
TUZWQy0gQUNTLSwgRnVuY3Rpb24gR3JvdXA6IDAKCUNhcGFiaWxpdGllczogWzE4MF0gVHJhbnNh
Y3Rpb24gUHJvY2Vzc2luZyBIaW50cwoJCURldmljZSBzcGVjaWZpYyBtb2RlIHN1cHBvcnRlZAoJ
CU5vIHN0ZWVyaW5nIHRhYmxlIGF2YWlsYWJsZQoJQ2FwYWJpbGl0aWVzOiBbMTQwXSBTaW5nbGUg
Um9vdCBJL08gVmlydHVhbGl6YXRpb24gKFNSLUlPVikKCQlJT1ZDYXA6CU1pZ3JhdGlvbi0sIElu
dGVycnVwdCBNZXNzYWdlIE51bWJlcjogMDAwCgkJSU9WQ3RsOglFbmFibGUtIE1pZ3JhdGlvbi0g
SW50ZXJydXB0LSBNU0UtIEFSSUhpZXJhcmNoeSsKCQlJT1ZTdGE6CU1pZ3JhdGlvbi0KCQlJbml0
aWFsIFZGczogMzEsIFRvdGFsIFZGczogMzEsIE51bWJlciBvZiBWRnM6IDAsIEZ1bmN0aW9uIERl
cGVuZGVuY3kgTGluazogMDAKCQlWRiBvZmZzZXQ6IDgsIHN0cmlkZTogMSwgRGV2aWNlIElEOiAx
ZDU5CgkJU3VwcG9ydGVkIFBhZ2UgU2l6ZTogMDAwMDA1NTMsIFN5c3RlbSBQYWdlIFNpemU6IDAw
MDAwMDAxCgkJUmVnaW9uIDA6IE1lbW9yeSBhdCAwMDAwMDAwMGViODEwMDAwICg2NC1iaXQsIHBy
ZWZldGNoYWJsZSkKCQlWRiBNaWdyYXRpb246IG9mZnNldDogMDAwMDAwMDAsIEJJUjogMAoJS2Vy
bmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sKCg==

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: application/octet-stream; name="guest_dmesg"
Content-Description: guest_dmesg
Content-Disposition: attachment; filename="guest_dmesg"; size=22115;
	creation-date="Mon, 16 Apr 2012 08:53:18 GMT";
	modification-date="Mon, 16 Apr 2012 01:55:42 GMT"
Content-Transfer-Encoding: base64

SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vi
c3lzIGNwdQpMaW51eCB2ZXJzaW9uIDIuNi4zMi0yMjAuZWw2Lng4Nl82NCAobW9ja2J1aWxkQHg4
Ni0wMDQuYnVpbGQuYm9zLnJlZGhhdC5jb20pIChnY2MgdmVyc2lvbiA0LjQuNSAyMDExMDIxNCAo
UmVkIEhhdCA0LjQuNS02KSAoR0NDKSApICMxIFNNUCBXZWQgTm92IDkgMDg6MDM6MTMgRVNUIDIw
MTEKQ29tbWFuZCBsaW5lOiBybyByb290PVVVSUQ9YzJhNjkzNTctOThhYy00OWZjLTgxYmQtNzAy
ZTRhODZjZWQ4IHJkX05PX0xVS1MgcmRfTk9fTFZNIExBTkc9ZW5fVVMuVVRGLTggcmRfTk9fTUQg
cXVpZXQgU1lTRk9OVD1sYXRhcmN5cmhlYi1zdW4xNiByaGdiICBLRVlCT0FSRFRZUEU9cGMgS0VZ
VEFCTEU9dXMgcmRfTk9fRE0KS0VSTkVMIHN1cHBvcnRlZCBjcHVzOgogIEludGVsIEdlbnVpbmVJ
bnRlbAogIEFNRCBBdXRoZW50aWNBTUQKICBDZW50YXVyIENlbnRhdXJIYXVscwpCSU9TLXByb3Zp
ZGVkIHBoeXNpY2FsIFJBTSBtYXA6CiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAw
MDAwMDAwMDllMDAwICh1c2FibGUpCiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAw
MDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKIEJJT1MtZTgyMDogMDAwMDAwMDAwMDBlMDAwMCAtIDAw
MDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQogQklPUy1lODIwOiAwMDAwMDAwMDAwMTAwMDAwIC0g
MDAwMDAwMDA3ZjgwMDAwMCAodXNhYmxlKQogQklPUy1lODIwOiAwMDAwMDAwMGZjMDAwMDAwIC0g
MDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCkRNSSAyLjQgcHJlc2VudC4KU01CSU9TIHZlcnNp
b24gMi40IEAgMHhGQkI4MApETUk6IFhlbiBIVk0gZG9tVSwgQklPUyA0LjItdW5zdGFibGUgMDQv
MTIvMjAxMgplODIwIHVwZGF0ZSByYW5nZTogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAw
MDEwMDAgKHVzYWJsZSkgPT0+IChyZXNlcnZlZCkKZTgyMCByZW1vdmUgcmFuZ2U6IDAwMDAwMDAw
MDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwICh1c2FibGUpCmxhc3RfcGZuID0gMHg3ZjgwMCBt
YXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApNVFJSIGRlZmF1bHQgdHlwZTogd3JpdGUtYmFjawpN
VFJSIGZpeGVkIHJhbmdlcyBlbmFibGVkOgogIDAwMDAwLTlGRkZGIHdyaXRlLWJhY2sKICBBMDAw
MC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKICBDMDAwMC1GRkZGRiB3cml0ZS1iYWNrCk1UUlIgdmFy
aWFibGUgcmFuZ2VzIGVuYWJsZWQ6CiAgMCBiYXNlIDAwMDBGMDAwMDAwMCBtYXNrIDNGRkZGODAw
MDAwMCB1bmNhY2hhYmxlCiAgMSBiYXNlIDAwMDBGODAwMDAwMCBtYXNrIDNGRkZGQzAwMDAwMCB1
bmNhY2hhYmxlCiAgMiBkaXNhYmxlZAogIDMgZGlzYWJsZWQKICA0IGRpc2FibGVkCiAgNSBkaXNh
YmxlZAogIDYgZGlzYWJsZWQKICA3IGRpc2FibGVkCng4NiBQQVQgZW5hYmxlZDogY3B1IDAsIG9s
ZCAweDcwNDA2MDAwNzA0MDYsIG5ldyAweDcwMTA2MDAwNzAxMDYKaW5pdGlhbCBtZW1vcnkgbWFw
cGVkIDogMCAtIDIwMDAwMDAwCmluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAt
MDAwMDAwMDA3ZjgwMDAwMAogMDAwMDAwMDAwMCAtIDAwN2Y4MDAwMDAgcGFnZSAyTQprZXJuZWwg
ZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDdmODAwMDAwIEAgODAwMC1iMDAwClJBTURJU0s6
IDM3MGI5MDAwIC0gMzdmZWZhNTMKQUNQSTogUlNEUCAwMDAwMDAwMDAwMGVhMDIwIDAwMDI0ICh2
MDIgICAgWGVuKQpBQ1BJOiBYU0RUIDAwMDAwMDAwZmMwMGY2MTAgMDAwNTQgKHYwMSAgICBYZW4g
ICAgICBIVk0gMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKQUNQSTogRkFDUCAwMDAwMDAwMGZjMDBm
MmQwIDAwMEY0ICh2MDQgICAgWGVuICAgICAgSFZNIDAwMDAwMDAwIEhWTUwgMDAwMDAwMDApCkFD
UEk6IERTRFQgMDAwMDAwMDBmYzAwMzVlMCAwQkM2RSAodjAyICAgIFhlbiAgICAgIEhWTSAwMDAw
MDAwMCBJTlRMIDIwMDkwMTIzKQpBQ1BJOiBGQUNTIDAwMDAwMDAwZmMwMDM1YTAgMDAwNDAKQUNQ
STogQVBJQyAwMDAwMDAwMGZjMDBmM2QwIDAwMEQ4ICh2MDIgICAgWGVuICAgICAgSFZNIDAwMDAw
MDAwIEhWTUwgMDAwMDAwMDApCkFDUEk6IEhQRVQgMDAwMDAwMDBmYzAwZjUyMCAwMDAzOCAodjAx
ICAgIFhlbiAgICAgIEhWTSAwMDAwMDAwMCBIVk1MIDAwMDAwMDAwKQpBQ1BJOiBXQUVUIDAwMDAw
MDAwZmMwMGY1NjAgMDAwMjggKHYwMSAgICBYZW4gICAgICBIVk0gMDAwMDAwMDAgSFZNTCAwMDAw
MDAwMCkKQUNQSTogU1NEVCAwMDAwMDAwMGZjMDBmNTkwIDAwMDMxICh2MDIgICAgWGVuICAgICAg
SFZNIDAwMDAwMDAwIElOVEwgMjAwOTAxMjMpCkFDUEk6IFNTRFQgMDAwMDAwMDBmYzAwZjVkMCAw
MDAzMSAodjAyICAgIFhlbiAgICAgIEhWTSAwMDAwMDAwMCBJTlRMIDIwMDkwMTIzKQpBQ1BJOiBM
b2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQK
RmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwN2Y4MDAwMDAKQm9vdG1l
bSBzZXR1cCBub2RlIDAgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDdmODAwMDAwCiAgTk9ERV9E
QVRBIFswMDAwMDAwMDAwMDA5MDAwIC0gMDAwMDAwMDAwMDAzY2ZmZl0KICBib290bWFwIFswMDAw
MDAwMDAwMDNkMDAwIC0gIDAwMDAwMDAwMDAwNGNlZmZdIHBhZ2VzIDEwCig3IGVhcmx5IHJlc2Vy
dmF0aW9ucykgPT0+IGJvb3RtZW0gWzAwMDAwMDAwMDAgLSAwMDdmODAwMDAwXQogICMwIFswMDAw
MDAwMDAwIC0gMDAwMDAwMTAwMF0gICBCSU9TIGRhdGEgcGFnZSA9PT4gWzAwMDAwMDAwMDAgLSAw
MDAwMDAxMDAwXQogICMxIFswMDAwMDA2MDAwIC0gMDAwMDAwODAwMF0gICAgICAgVFJBTVBPTElO
RSA9PT4gWzAwMDAwMDYwMDAgLSAwMDAwMDA4MDAwXQogICMyIFswMDAxMDAwMDAwIC0gMDAwMjAw
YzdlNF0gICAgVEVYVCBEQVRBIEJTUyA9PT4gWzAwMDEwMDAwMDAgLSAwMDAyMDBjN2U0XQogICMz
IFswMDM3MGI5MDAwIC0gMDAzN2ZlZmE1M10gICAgICAgICAgUkFNRElTSyA9PT4gWzAwMzcwYjkw
MDAgLSAwMDM3ZmVmYTUzXQogICM0IFswMDAwMDllMDAwIC0gMDAwMDEwMDAwMF0gICAgQklPUyBy
ZXNlcnZlZCA9PT4gWzAwMDAwOWUwMDAgLSAwMDAwMTAwMDAwXQogICM1IFswMDAyMDBkMDAwIC0g
MDAwMjAwZDBkOF0gICAgICAgICAgICAgIEJSSyA9PT4gWzAwMDIwMGQwMDAgLSAwMDAyMDBkMGQ4
XQogICM2IFswMDAwMDA4MDAwIC0gMDAwMDAwOTAwMF0gICAgICAgICAgUEdUQUJMRSA9PT4gWzAw
MDAwMDgwMDAgLSAwMDAwMDA5MDAwXQpmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAwMDAw
ZmJiYTBdIGZiYmEwCiBbZmZmZmVhMDAwMDAwMDAwMC1mZmZmZWEwMDAxYmZmZmZmXSBQTUQgLT4g
W2ZmZmY4ODAwMDI2MDAwMDAtZmZmZjg4MDAwNDFmZmZmZl0gb24gbm9kZSAwClpvbmUgUEZOIHJh
bmdlczoKICBETUEgICAgICAweDAwMDAwMDAxIC0+IDB4MDAwMDEwMDAKICBETUEzMiAgICAweDAw
MDAxMDAwIC0+IDB4MDAxMDAwMDAKICBOb3JtYWwgICAweDAwMTAwMDAwIC0+IDB4MDAxMDAwMDAK
TW92YWJsZSB6b25lIHN0YXJ0IFBGTiBmb3IgZWFjaCBub2RlCmVhcmx5X25vZGVfbWFwWzJdIGFj
dGl2ZSBQRk4gcmFuZ2VzCiAgICAwOiAweDAwMDAwMDAxIC0+IDB4MDAwMDAwOWUKICAgIDA6IDB4
MDAwMDAxMDAgLT4gMHgwMDA3ZjgwMApPbiBub2RlIDAgdG90YWxwYWdlczogNTIyMTQxCiAgRE1B
IHpvbmU6IDU2IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcAogIERNQSB6b25lOiAxMDIgcGFnZXMgcmVz
ZXJ2ZWQKICBETUEgem9uZTogMzgzOSBwYWdlcywgTElGTyBiYXRjaDowCiAgRE1BMzIgem9uZTog
NzA4NCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKICBETUEzMiB6b25lOiA1MTEwNjAgcGFnZXMsIExJ
Rk8gYmF0Y2g6MzEKQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHhiMDA4CkFDUEk6IExvY2FsIEFQ
SUMgYWRkcmVzcyAweGZlZTAwMDAwCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDBdIGxhcGljX2lk
WzB4MDBdIGVuYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDJd
IGVuYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDRdIGVuYWJs
ZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDZdIGVuYWJsZWQpCkFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDhdIGRpc2FibGVkKQpBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDBhXSBkaXNhYmxlZCkKQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwY10gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDddIGxhcGljX2lkWzB4MGVdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDA4XSBsYXBpY19pZFsweDEwXSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0g
bGFwaWNfaWRbMHgxMl0gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGFdIGxhcGlj
X2lkWzB4MTRdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBiXSBsYXBpY19pZFsw
eDE2XSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwY10gbGFwaWNfaWRbMHgxOF0g
ZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGRdIGxhcGljX2lkWzB4MWFdIGRpc2Fi
bGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBlXSBsYXBpY19pZFsweDFjXSBkaXNhYmxlZCkK
QUNQSTogSU9BUElDIChpZFsweDAxXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpJ
T0FQSUNbMF06IGFwaWNfaWQgMSwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kg
MC00NwpBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwg
ZGZsKQpBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBsb3cg
bGV2ZWwpCkFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDEwIGdsb2JhbF9pcnEgMTAg
bG93IGxldmVsKQpBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAxMSBnbG9iYWxfaXJx
IDExIGxvdyBsZXZlbCkKQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlEyIHVz
ZWQgYnkgb3ZlcnJpZGUuCkFDUEk6IElSUTUgdXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJROSB1
c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlExMCB1c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlEx
MSB1c2VkIGJ5IG92ZXJyaWRlLgpVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRp
b24gaW5mb3JtYXRpb24KQUNQSTogSFBFVCBpZDogMHg4MDg2YTIwMSBiYXNlOiAweGZlZDAwMDAw
ClNNUDogQWxsb3dpbmcgMTUgQ1BVcywgMTEgaG90cGx1ZyBDUFVzCm5yX2lycXNfZ3NpOiA0OApY
ZW4gdmVyc2lvbiA0LjIuClhlbiBQbGF0Zm9ybSBQQ0k6IEkvTyBwcm90b2NvbCB2ZXJzaW9uIDEK
TmV0ZnJvbnQgYW5kIHRoZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGls
ZWQgZm9yIHRoaXMga2VybmVsOiB1bnBsdWcgZW11bGF0ZWQgTklDcy4KQmxrZnJvbnQgYW5kIHRo
ZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGlsZWQgZm9yIHRoaXMga2Vy
bmVsOiB1bnBsdWcgZW11bGF0ZWQgZGlza3MuCllvdSBtaWdodCBoYXZlIHRvIGNoYW5nZSB0aGUg
cm9vdCBkZXZpY2UKZnJvbSAvZGV2L2hkW2EtZF0gdG8gL2Rldi94dmRbYS1kXQppbiB5b3VyIHJv
b3Q9IGtlcm5lbCBjb21tYW5kIGxpbmUgb3B0aW9uClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAwMDAwMDAwMGEwMDAwClBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMGUwMDAwClBNOiBSZWdp
c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAw
CkFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFydGluZyBhdCA3ZjgwMDAwMCAoZ2FwOiA3Zjgw
MDAwMDo3YzgwMDAwMCkKQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpOUl9D
UFVTOjQwOTYgbnJfY3B1bWFza19iaXRzOjE1IG5yX2NwdV9pZHM6MTUgbnJfbm9kZV9pZHM6MQpQ
RVJDUFU6IEVtYmVkZGVkIDMwIHBhZ2VzL2NwdSBAZmZmZjg4MDAwMjIwMDAwMCBzOTI2OTYgcjgx
OTIgZDIxOTkyIHUxMzEwNzIKcGNwdS1hbGxvYzogczkyNjk2IHI4MTkyIGQyMTk5MiB1MTMxMDcy
IGFsbG9jPTEqMjA5NzE1MgpwY3B1LWFsbG9jOiBbMF0gMDAgMDEgMDIgMDMgMDQgMDUgMDYgMDcg
MDggMDkgMTAgMTEgMTIgMTMgMTQgLS0gCkJ1aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIs
IG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDUxNDg5OQpQb2xpY3kgem9uZTog
RE1BMzIKS2VybmVsIGNvbW1hbmQgbGluZTogcm8gcm9vdD1VVUlEPWMyYTY5MzU3LTk4YWMtNDlm
Yy04MWJkLTcwMmU0YTg2Y2VkOCByZF9OT19MVUtTIHJkX05PX0xWTSBMQU5HPWVuX1VTLlVURi04
IHJkX05PX01EIHF1aWV0IFNZU0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgcmhnYiAgS0VZQk9BUkRU
WVBFPXBjIEtFWVRBQkxFPXVzIHJkX05PX0RNClBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYg
KG9yZGVyOiAzLCAzMjc2OCBieXRlcykKeHNhdmUveHJzdG9yOiBlbmFibGVkIHhzdGF0ZV9idiAw
eDcsIGNudHh0IHNpemUgMHgzNDAKQ2hlY2tpbmcgYXBlcnR1cmUuLi4KTm8gQUdQIGJyaWRnZSBm
b3VuZApNZW1vcnk6IDIwMjU1NjRrLzIwODg5NjBrIGF2YWlsYWJsZSAoNTA4NGsga2VybmVsIGNv
ZGUsIDM5NmsgYWJzZW50LCA2MzAwMGsgcmVzZXJ2ZWQsIDcyMjlrIGRhdGEsIDEyNDRrIGluaXQp
CkhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uCk5SX0lSUVM6MzMwMjQgbnJfaXJxczo5
MzYKWGVuIEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50IGRlbGl2ZXJ5IGlzIGVuYWJsZWQK
Q29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKY29uc29sZSBbdHR5MF0gZW5hYmxlZAphbGxvY2F0
ZWQgMTY3NzcyMTYgYnl0ZXMgb2YgcGFnZV9jZ3JvdXAKcGxlYXNlIHRyeSAnY2dyb3VwX2Rpc2Fi
bGU9bWVtb3J5JyBvcHRpb24gaWYgeW91IGRvbid0IHdhbnQgbWVtb3J5IGNncm91cHMKaHBldCBj
bG9ja2V2ZW50IHJlZ2lzdGVyZWQKSFBFVDogMyB0aW1lcnMgaW4gdG90YWwsIDAgdGltZXJzIHdp
bGwgYmUgdXNlZCBmb3IgcGVyLWNwdSB0aW1lcgpGYXN0IFRTQyBjYWxpYnJhdGlvbiB1c2luZyBQ
SVQKRGV0ZWN0ZWQgMjY5My41ODcgTUh6IHByb2Nlc3Nvci4KQ2FsaWJyYXRpbmcgZGVsYXkgbG9v
cCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNTM4
Ny4xNyBCb2dvTUlQUyAobHBqPTI2OTM1ODcpCnBpZF9tYXg6IGRlZmF1bHQ6IDMyNzY4IG1pbmlt
dW06IDMwMQpTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQKU0VMaW51eDogIEluaXRpYWxp
emluZy4KU0VMaW51eDogIFN0YXJ0aW5nIGluIHBlcm1pc3NpdmUgbW9kZQpEZW50cnkgY2FjaGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9yZGVyOiA5LCAyMDk3MTUyIGJ5dGVzKQpJbm9k
ZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0
ZXMpCk1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMjU2CkluaXRpYWxpemluZyBjZ3Jv
dXAgc3Vic3lzIG5zCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QKSW5pdGlhbGl6
aW5nIGNncm91cCBzdWJzeXMgbWVtb3J5CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGRldmlj
ZXMKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcgpJbml0aWFsaXppbmcgY2dyb3Vw
IHN1YnN5cyBuZXRfY2xzCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGJsa2lvCkluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIHBlcmZfZXZlbnQKQ1BVOiBDUFUgZmVhdHVyZSByZHRzY3AgZGlz
YWJsZWQgb24geGVuIGd1ZXN0CkNQVTogQ1BVIGZlYXR1cmUgY29uc3RhbnRfdHNjIGRpc2FibGVk
IG9uIHhlbiBndWVzdApDUFU6IFVuc3VwcG9ydGVkIG51bWJlciBvZiBzaWJsaW5ncyA2NAptY2U6
IENQVSBzdXBwb3J0cyAyMCBNQ0UgYmFua3MKYWx0ZXJuYXRpdmVzOiBzd2l0Y2hpbmcgdG8gdW5m
YWlyIHNwaW5sb2NrCkFDUEk6IENvcmUgcmV2aXNpb24gMjAwOTA5MDMKZnRyYWNlOiBjb252ZXJ0
aW5nIG1jb3VudCBjYWxscyB0byAwZiAxZiA0NCAwMCAwMApmdHJhY2U6IGFsbG9jYXRpbmcgMjA3
NzYgZW50cmllcyBpbiA4MiBwYWdlcwp4MmFwaWMgbm90IGVuYWJsZWQsIElSUSByZW1hcHBpbmcg
aW5pdCBmYWlsZWQKU2V0dGluZyBBUElDIHJvdXRpbmcgdG8gcGh5c2ljYWwgZmxhdAouLlRJTUVS
OiB2ZWN0b3I9MHgzMCBhcGljMT0wIHBpbjE9MiBhcGljMj0wIHBpbjI9MApDUFUwOiBJbnRlbChS
KSBYZW9uKFIpIENQVSBFNS0yNjgwIDAgQCAyLjcwR0h6IHN0ZXBwaW5nIDA2ClBlcmZvcm1hbmNl
IEV2ZW50czogU2FuZHlCcmlkZ2UgZXZlbnRzLCBJbnRlbCBQTVUgZHJpdmVyLgouLi4gdmVyc2lv
bjogICAgICAgICAgICAgICAgMwouLi4gYml0IHdpZHRoOiAgICAgICAgICAgICAgNDgKLi4uIGdl
bmVyaWMgcmVnaXN0ZXJzOiAgICAgIDQKLi4uIHZhbHVlIG1hc2s6ICAgICAgICAgICAgIDAwMDBm
ZmZmZmZmZmZmZmYKLi4uIG1heCBwZXJpb2Q6ICAgICAgICAgICAgIDAwMDAwMDAwN2ZmZmZmZmYK
Li4uIGZpeGVkLXB1cnBvc2UgZXZlbnRzOiAgIDMKLi4uIGV2ZW50IG1hc2s6ICAgICAgICAgICAg
IDAwMDAwMDA3MDAwMDAwMGYKTk1JIHdhdGNoZG9nIGVuYWJsZWQsIHRha2VzIG9uZSBody1wbXUg
Y291bnRlci4KQm9vdGluZyBOb2RlICAgMCwgUHJvY2Vzc29ycyAgIzEKQ1BVOiBDUFUgZmVhdHVy
ZSByZHRzY3AgZGlzYWJsZWQgb24geGVuIGd1ZXN0CkNQVTogQ1BVIGZlYXR1cmUgY29uc3RhbnRf
dHNjIGRpc2FibGVkIG9uIHhlbiBndWVzdApDUFU6IFVuc3VwcG9ydGVkIG51bWJlciBvZiBzaWJs
aW5ncyA2NCAjMgpDUFU6IENQVSBmZWF0dXJlIHJkdHNjcCBkaXNhYmxlZCBvbiB4ZW4gZ3Vlc3QK
Q1BVOiBDUFUgZmVhdHVyZSBjb25zdGFudF90c2MgZGlzYWJsZWQgb24geGVuIGd1ZXN0CkNQVTog
VW5zdXBwb3J0ZWQgbnVtYmVyIG9mIHNpYmxpbmdzIDY0ICMzCkNQVTogQ1BVIGZlYXR1cmUgcmR0
c2NwIGRpc2FibGVkIG9uIHhlbiBndWVzdApDUFU6IENQVSBmZWF0dXJlIGNvbnN0YW50X3RzYyBk
aXNhYmxlZCBvbiB4ZW4gZ3Vlc3QKQ1BVOiBVbnN1cHBvcnRlZCBudW1iZXIgb2Ygc2libGluZ3Mg
NjQKQnJvdWdodCB1cCA0IENQVXMKVG90YWwgb2YgNCBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMjE1
NDguMTIgQm9nb01JUFMpLgpzaXplb2Yodm1hKT0yMDAgYnl0ZXMKc2l6ZW9mKHBhZ2UpPTU2IGJ5
dGVzCnNpemVvZihpbm9kZSk9NTkyIGJ5dGVzCnNpemVvZihkZW50cnkpPTE5MiBieXRlcwpzaXpl
b2YoZXh0M2lub2RlKT04MDAgYnl0ZXMKc2l6ZW9mKGJ1ZmZlcl9oZWFkKT0xMDQgYnl0ZXMKc2l6
ZW9mKHNrYnVmZik9MjMyIGJ5dGVzCnNpemVvZih0YXNrX3N0cnVjdCk9MjYxNiBieXRlcwpkZXZ0
bXBmczogaW5pdGlhbGl6ZWQKcmVndWxhdG9yOiBjb3JlIHZlcnNpb24gMC41Ck5FVDogUmVnaXN0
ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKICBhbGxvYyBpcnFfZGVzYyBmb3IgMTYgb24gbm9kZSAw
CiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVy
ZWQKUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MKYmlvOiBj
cmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKQUNQSTogRUM6IExvb2sgdXAgRUMgaW4gRFNEVApBQ1BJ
OiBJbnRlcnByZXRlciBlbmFibGVkCkFDUEk6IChzdXBwb3J0cyBTMCBTMyBTNCBTNSkKQUNQSTog
VXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZwpBQ1BJOiBObyBkb2NrIGRldmljZXMg
Zm91bmQuCkhFU1Q6IFRhYmxlIG5vdCBmb3VuZC4KQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kw
XSAoMDAwMDowMCkKcGNpIDAwMDA6MDA6MDEuMTogcmVnIDIwIGlvIHBvcnQ6IFsweGMzMDAtMHhj
MzBmXQoqIEZvdW5kIFBNLVRpbWVyIEJ1ZyBvbiB0aGUgY2hpcHNldC4gRHVlIHRvIHdvcmthcm91
bmRzIGZvciBhIGJ1ZywKKiB0aGlzIGNsb2NrIHNvdXJjZSBpcyBzbG93LiBDb25zaWRlciB0cnlp
bmcgb3RoZXIgY2xvY2sgc291cmNlcwpwY2kgMDAwMDowMDowMS4zOiBxdWlyazogcmVnaW9uIGIw
MDAtYjAzZiBjbGFpbWVkIGJ5IFBJSVg0IEFDUEkKcGNpIDAwMDA6MDA6MDIuMDogcmVnIDEwIDMy
Yml0IG1taW8gcHJlZjogWzB4ZjAwMDAwMDAtMHhmMWZmZmZmZl0KcGNpIDAwMDA6MDA6MDIuMDog
cmVnIDE0IDMyYml0IG1taW86IFsweGYzNDA0MDAwLTB4ZjM0MDRmZmZdCnBjaSAwMDAwOjAwOjAz
LjA6IHJlZyAxMCBpbyBwb3J0OiBbMHhjMDAwLTB4YzBmZl0KcGNpIDAwMDA6MDA6MDMuMDogcmVn
IDE0IDMyYml0IG1taW8gcHJlZjogWzB4ZjIwMDAwMDAtMHhmMmZmZmZmZl0KcGNpIDAwMDA6MDA6
MDUuMDogcmVnIDEwIDY0Yml0IG1taW8gcHJlZjogWzB4ZjM0MDAwMDAtMHhmMzQwM2ZmZl0KcGNp
IDAwMDA6MDA6MDUuMDogcmVnIDE4IDY0Yml0IG1taW8gcHJlZjogWzB4ZjMwMDAwMDAtMHhmMzNm
ZmZmZl0KcGNpIDAwMDA6MDA6MDUuMDogcmVnIDIwIGlvIHBvcnQ6IFsweGMyMDAtMHhjMmZmXQpB
Q1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuX1BSVF0KQUNQSTog
UENJIEludGVycnVwdCBMaW5rIFtMTktBXSAoSVJRcyAqNSAxMCAxMSkKQUNQSTogUENJIEludGVy
cnVwdCBMaW5rIFtMTktCXSAoSVJRcyA1ICoxMCAxMSkKQUNQSTogUENJIEludGVycnVwdCBMaW5r
IFtMTktDXSAoSVJRcyA1IDEwICoxMSkKQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAo
SVJRcyAqNSAxMCAxMSkKdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTowMDAwOjAwOjAyLjAsZGVj
b2Rlcz1pbyttZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQp2Z2FhcmI6IGxvYWRlZAp2Z2FhcmI6
IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDA6MDIuMApTQ1NJIHN1YnN5c3RlbSBpbml0
aWFsaXplZApsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4KdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcwp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIGh1Ygp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpQ
Q0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nClBDSTogb2xkIGNvZGUgd291bGQgaGF2ZSBz
ZXQgY2FjaGVsaW5lIHNpemUgdG8gMzIgYnl0ZXMsIGJ1dCBjbGZsdXNoX3NpemUgPSA2NApQQ0k6
IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzCk5ldExhYmVsOiBJbml0aWFsaXpp
bmcKTmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4Ck5ldExhYmVsOiAgcHJvdG9jb2xz
ID0gVU5MQUJFTEVEIENJUFNPdjQKTmV0TGFiZWw6ICB1bmxhYmVsZWQgdHJhZmZpYyBhbGxvd2Vk
IGJ5IGRlZmF1bHQKaHBldDA6IGF0IE1NSU8gMHhmZWQwMDAwMCwgSVJRcyAyLCA4LCAwCmhwZXQw
OiAzIGNvbXBhcmF0b3JzLCA2NC1iaXQgNjIuNTAwMDAwIE1IeiBjb3VudGVyClN3aXRjaGluZyB0
byBjbG9ja3NvdXJjZSB0c2MKcG5wOiBQblAgQUNQSSBpbml0CkFDUEk6IGJ1cyB0eXBlIHBucCBy
ZWdpc3RlcmVkCnBucDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMKQUNQSTogQUNQSSBidXMg
dHlwZSBwbnAgdW5yZWdpc3RlcmVkCnN5c3RlbSAwMDowMDogaW9tZW0gcmFuZ2UgMHgwLTB4OWZm
ZmYgY291bGQgbm90IGJlIHJlc2VydmVkCnN5c3RlbSAwMDowMzogaW9wb3J0IHJhbmdlIDB4OGEw
LTB4OGEzIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowMzogaW9wb3J0IHJhbmdlIDB4Y2Mw
LTB4Y2NmIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowMzogaW9wb3J0IHJhbmdlIDB4NGQw
LTB4NGQxIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowYzogaW9wb3J0IHJhbmdlIDB4MTBj
MC0weDExNDEgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjBjOiBpb3BvcnQgcmFuZ2UgMHhi
MDQ0LTB4YjA0NyBoYXMgYmVlbiByZXNlcnZlZApwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDAg
aW86ICBbMHgwMC0weGZmZmZdCnBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgMSBtZW06IFsweDAw
MDAwMC0weGZmZmZmZmZmZmZmZmZmZmZdCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkg
MgpJUCByb3V0ZSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNywgNTI0
Mjg4IGJ5dGVzKQpUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9y
ZGVyOiAxMCwgNDE5NDMwNCBieXRlcykKVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUz
NiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpClRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAo
ZXN0YWJsaXNoZWQgMjYyMTQ0IGJpbmQgNjU1MzYpClRDUCByZW5vIHJlZ2lzdGVyZWQKTkVUOiBS
ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxCnBjaSAwMDAwOjAwOjAwLjA6IExpbWl0aW5nIGRp
cmVjdCBQQ0kvUENJIHRyYW5zZmVycwpwY2kgMDAwMDowMDowMS4wOiBQSUlYMzogRW5hYmxpbmcg
UGFzc2l2ZSBSZWxlYXNlCnBjaSAwMDAwOjAwOjAxLjA6IEFjdGl2YXRpbmcgSVNBIERNQSBoYW5n
IHdvcmthcm91bmRzCnBjaSAwMDAwOjAwOjAyLjA6IEJvb3QgdmlkZW8gZGV2aWNlClRyeWluZyB0
byB1bnBhY2sgcm9vdGZzIGltYWdlIGFzIGluaXRyYW1mcy4uLgpGcmVlaW5nIGluaXRyZCBtZW1v
cnk6IDE1NTc4ayBmcmVlZAphdWRpdDogaW5pdGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNh
YmxlZCkKdHlwZT0yMDAwIGF1ZGl0KDEzMzQ1OTM4NDkuOTI2OjEpOiBpbml0aWFsaXplZApIdWdl
VExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpWRlM6
IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yCkRxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczog
NTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQptc2dtbmkgaGFzIGJlZW4gc2V0IHRvIDM5ODYKU0VM
aW51eDogIFJlZ2lzdGVyaW5nIG5ldGZpbHRlciBob29rcwphbGc6IE5vIHRlc3QgZm9yIHN0ZHJu
ZyAoa3JuZykKa3NpZ246IEluc3RhbGxpbmcgcHVibGljIGtleSBkYXRhCkxvYWRpbmcga2V5cmlu
ZwotIEFkZGVkIHB1YmxpYyBrZXkgNEJCMUU2M0QxOEI0MjY1OAotIFVzZXIgSUQ6IFJlZCBIYXQs
IEluYy4gKEtlcm5lbCBNb2R1bGUgR1BHIGtleSkKLSBBZGRlZCBwdWJsaWMga2V5IEQ0QTI2QzlD
Q0QwOUJFREEKLSBVc2VyIElEOiBSZWQgSGF0IEVudGVycHJpc2UgTGludXggRHJpdmVyIFVwZGF0
ZSBQcm9ncmFtIDxzZWNhbGVydEByZWRoYXQuY29tPgpCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMg
KGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUyKQppbyBzY2hlZHVsZXIg
bm9vcCByZWdpc3RlcmVkCmlvIHNjaGVkdWxlciBhbnRpY2lwYXRvcnkgcmVnaXN0ZXJlZAppbyBz
Y2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJlZAppbyBzY2hlZHVsZXIgY2ZxIHJlZ2lzdGVyZWQg
KGRlZmF1bHQpCnBjaV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUgdmVyc2lvbjogMC41
CnBjaWVocDogUENJIEV4cHJlc3MgSG90IFBsdWcgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjog
MC40CmFjcGlwaHA6IEFDUEkgSG90IFBsdWcgUENJIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246
IDAuNQphY3BpcGhwOiBTbG90IFswXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzFdIHJlZ2lz
dGVyZWQKYWNwaXBocDogU2xvdCBbMl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFszXSByZWdp
c3RlcmVkCmFjcGlwaHA6IFNsb3QgWzRdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xvdCBbNV0gcmVn
aXN0ZXJlZAphY3BpcGhwOiBTbG90IFs2XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzddIHJl
Z2lzdGVyZWQKYWNwaXBocDogU2xvdCBbOF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFs5XSBy
ZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzEwXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzEx
XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzEyXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3Qg
WzEzXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzE0XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNs
b3QgWzE1XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzE2XSByZWdpc3RlcmVkCmFjcGlwaHA6
IFNsb3QgWzE3XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzE4XSByZWdpc3RlcmVkCmFjcGlw
aHA6IFNsb3QgWzE5XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzIwXSByZWdpc3RlcmVkCmFj
cGlwaHA6IFNsb3QgWzIxXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzIyXSByZWdpc3RlcmVk
CmFjcGlwaHA6IFNsb3QgWzIzXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI0XSByZWdpc3Rl
cmVkCmFjcGlwaHA6IFNsb3QgWzI1XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI2XSByZWdp
c3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI3XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI4XSBy
ZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI5XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzMw
XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzMxXSByZWdpc3RlcmVkCmlucHV0OiBQb3dlciBC
dXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQwCkFD
UEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KaW5wdXQ6IFNsZWVwIEJ1dHRvbiBhcyAvZGV2aWNlcy9M
TlhTWVNUTTowMC9MTlhTTFBCTjowMC9pbnB1dC9pbnB1dDEKQUNQSTogU2xlZXAgQnV0dG9uIFtT
TFBGXQpBQ1BJOiBhY3BpX2lkbGUgcmVnaXN0ZXJlZCB3aXRoIGNwdWlkbGUKcHJvY2Vzc29yIExO
WENQVTowMDogcmVnaXN0ZXJlZCBhcyBjb29saW5nX2RldmljZTAKcHJvY2Vzc29yIExOWENQVTow
MTogcmVnaXN0ZXJlZCBhcyBjb29saW5nX2RldmljZTEKcHJvY2Vzc29yIExOWENQVTowMjogcmVn
aXN0ZXJlZCBhcyBjb29saW5nX2RldmljZTIKcHJvY2Vzc29yIExOWENQVTowMzogcmVnaXN0ZXJl
ZCBhcyBjb29saW5nX2RldmljZTMKRVJTVDogVGFibGUgaXMgbm90IGZvdW5kIQpHSEVTOiBIRVNU
IGlzIG5vdCBlbmFibGVkIQogIGFsbG9jIGlycV9kZXNjIGZvciAyOCBvbiBub2RlIC0xCiAgYWxs
b2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCnhlbi1wbGF0Zm9ybS1wY2kgMDAwMDowMDowMy4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDI4IChsZXZlbCwgbG93KSAtPiBJUlEgMjgKR3JhbnQgdGFibGUgaW5p
dGlhbGl6ZWQKTm9uLXZvbGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwpMaW51eCBhZ3BnYXJ0IGlu
dGVyZmFjZSB2MC4xMDMKY3Jhc2ggbWVtb3J5IGRyaXZlcjogdmVyc2lvbiAxLjEKU2VyaWFsOiA4
MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZApzZXJpYWw4MjUw
OiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBCjAwOjBhOiB0dHlTMCBh
dCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBCmJyZDogbW9kdWxlIGxvYWRlZApsb29w
OiBtb2R1bGUgbG9hZGVkCmlucHV0OiBNYWNpbnRvc2ggbW91c2UgYnV0dG9uIGVtdWxhdGlvbiBh
cyAvZGV2aWNlcy92aXJ0dWFsL2lucHV0L2lucHV0MgpGaXhlZCBNRElPIEJ1czogcHJvYmVkCmVo
Y2lfaGNkOiBVU0IgMi4wICdFbmhhbmNlZCcgSG9zdCBDb250cm9sbGVyIChFSENJKSBEcml2ZXIK
b2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyCnVo
Y2lfaGNkOiBVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlciBJbnRlcmZhY2UgZHJpdmVyClBO
UDogUFMvMiBDb250cm9sbGVyIFtQTlAwMzAzOlBTMkssUE5QMGYxMzpQUzJNXSBhdCAweDYwLDB4
NjQgaXJxIDEsMTIKc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQpzZXJp
bzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgptaWNlOiBQUy8yIG1vdXNlIGRl
dmljZSBjb21tb24gZm9yIGFsbCBtaWNlCnJ0Y19jbW9zIDAwOjA1OiBydGMgY29yZTogcmVnaXN0
ZXJlZCBydGNfY21vcyBhcyBydGMwCnJ0YzA6IGFsYXJtcyB1cCB0byBvbmUgZGF5LCAxMTQgYnl0
ZXMgbnZyYW0sIGhwZXQgaXJxcwpjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBsYWRkZXIKY3B1aWRs
ZTogdXNpbmcgZ292ZXJub3IgbWVudQppbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBrZXlib2Fy
ZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5wdXQvaW5wdXQzCnVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaGlkZGV2CnVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkCnVzYmhpZDogdjIuNjpVU0IgSElEIGNvcmUg
ZHJpdmVyClRDUCBjdWJpYyByZWdpc3RlcmVkCkluaXRpYWxpemluZyBYRlJNIG5ldGxpbmsgc29j
a2V0Ck5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKcmVnaXN0ZXJlZCB0YXNrc3Rh
dHMgdmVyc2lvbiAxClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmJkLzc2
OApYRU5CVVM6IERldmljZSB3aXRoIG5vIGRyaXZlcjogZGV2aWNlL3ZpZi8wClhFTkJVUzogRGV2
aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmtiZC8wClhFTkJVUzogRGV2aWNlIHdpdGggbm8g
ZHJpdmVyOiBkZXZpY2UvcGNpLzAKcnRjX2Ntb3MgMDA6MDU6IHNldHRpbmcgc3lzdGVtIGNsb2Nr
IHRvIDIwMTItMDQtMTYgMTY6MzA6NTEgVVRDICgxMzM0NTkzODUxKQpJbml0YWxpemluZyBuZXR3
b3JrIGRyb3AgbW9uaXRvciBzZXJ2aWNlCkZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEy
NDRrIGZyZWVkCldyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTAy
NDBrCkZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEwNDBrIGZyZWVkCkZyZWVpbmcgdW51
c2VkIGtlcm5lbCBtZW1vcnk6IDE3NjBrIGZyZWVkCmRyYWN1dDogZHJhY3V0LTAwNC0yNTYuZWw2
CmRyYWN1dDogcmRfTk9fTFVLUzogcmVtb3ZpbmcgY3J5cHRvbHVrcyBhY3RpdmF0aW9uCmRyYWN1
dDogcmRfTk9fTFZNOiByZW1vdmluZyBMVk0gYWN0aXZhdGlvbgpkZXZpY2UtbWFwcGVyOiB1ZXZl
bnQ6IHZlcnNpb24gMS4wLjMKZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjIuNi1pb2N0bCAoMjAx
MS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KdWRldjogc3RhcnRpbmcg
dmVyc2lvbiAxNDcKZHJhY3V0OiBTdGFydGluZyBwbHltb3V0aCBkYWVtb24KaW5wdXQ6IEltRXhQ
Uy8yIEdlbmVyaWMgRXhwbG9yZXIgTW91c2UgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2Vy
aW8xL2lucHV0L2lucHV0NApkcmFjdXQ6IHJkX05PX0RNOiByZW1vdmluZyBETSBSQUlEIGFjdGl2
YXRpb24KZHJhY3V0OiByZF9OT19NRDogcmVtb3ZpbmcgTUQgUkFJRCBhY3RpdmF0aW9uCmF0YV9w
aWl4IDAwMDA6MDA6MDEuMTogdmVyc2lvbiAyLjEzCmF0YV9waWl4IDAwMDA6MDA6MDEuMTogc2V0
dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0CnNjc2kwIDogYXRhX3BpaXgKc2NzaTEgOiBhdGFfcGlp
eAphdGExOiBQQVRBIG1heCBNV0RNQTIgY21kIDB4MWYwIGN0bCAweDNmNiBibWRtYSAweGMzMDAg
aXJxIDE0CmF0YTI6IFBBVEEgbWF4IE1XRE1BMiBjbWQgMHgxNzAgY3RsIDB4Mzc2IGJtZG1hIDB4
YzMwOCBpcnEgMTUKaXNjaTogSW50ZWwoUikgQzYwMCBTQVMgQ29udHJvbGxlciBEcml2ZXIgLSB2
ZXJzaW9uIDEuMC4wLXJoCmlzY2kgMDAwMDowMDowNS4wOiBkcml2ZXIgY29uZmlndXJlZCBmb3Ig
cmV2OiA1IHNpbGljb24KaXNjaSAwMDAwOjAwOjA1LjA6IGZpcm13YXJlOiByZXF1ZXN0aW5nIGlz
Y2kvaXNjaV9maXJtd2FyZS5iaW4KaXNjaSAwMDAwOjAwOjA1LjA6IE9FTSBTQVMgcGFyYW1ldGVy
cyAodmVyc2lvbjogMS4wKSBsb2FkZWQgKGZpcm13YXJlKQogIGFsbG9jIGlycV9kZXNjIGZvciAz
NiBvbiBub2RlIC0xCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCmlzY2kgMDAwMDowMDow
NS4wOiBQQ0kgSU5UIEEgLT4gR1NJIDM2IChsZXZlbCwgbG93KSAtPiBJUlEgMzYKaXNjaSAwMDAw
OjAwOjA1LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApzY3NpMiA6IGlzY2kKICBhbGxv
YyBpcnFfZGVzYyBmb3IgNDggb24gbm9kZSAtMQogIGFsbG9jIGtzdGF0X2lycXMgb24gbm9kZSAt
MQppc2NpIDAwMDA6MDA6MDUuMDogaXJxIDQ4IGZvciBNU0kvTVNJLVgKICBhbGxvYyBpcnFfZGVz
YyBmb3IgNDkgb24gbm9kZSAtMQogIGFsbG9jIGtzdGF0X2lycXMgb24gbm9kZSAtMQppc2NpIDAw
MDA6MDA6MDUuMDogaXJxIDQ5IGZvciBNU0kvTVNJLVgKeGxibGtfaW5pdDogcmVnaXN0ZXJfYmxr
ZGV2IG1ham9yOiAyMDIgCiAgYWxsb2MgaXJxX2Rlc2MgZm9yIDE3IG9uIG5vZGUgMAogIGFsbG9j
IGtzdGF0X2lycXMgb24gbm9kZSAwCmJsa2Zyb250OiB4dmRhOiBiYXJyaWVycyBkaXNhYmxlZAog
eHZkYTogeHZkYTEgeHZkYTIKc2NzaSAyOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBTRUFHQVRF
ICBTVDkxNDY4MDJTUyAgICAgIDAwMDMgUFE6IDAgQU5TSTogNQpFWFQ0LWZzICh4dmRhMSk6IG1v
dW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiAKc2QgMjowOjA6
MDogW3NkYV0gMjg2NzQ5NDg4IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTQ2IEdCLzEzNiBH
aUIpCnNkIDI6MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmCnNkIDI6MDowOjA6IFtz
ZGFdIE1vZGUgU2Vuc2U6IGIzIDAwIDEwIDA4CnNkIDI6MDowOjA6IFtzZGFdIFdyaXRlIGNhY2hl
OiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBzdXBwb3J0cyBEUE8gYW5kIEZVQQogc2Rh
OiBzZGExIHNkYTIgc2RhMwpkcmFjdXQ6IE1vdW50ZWQgcm9vdCBmaWxlc3lzdGVtIC9kZXYveHZk
YTEKc2QgMjowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrClNFTGludXg6ICBEaXNhYmxl
ZCBhdCBydW50aW1lLgpTRUxpbnV4OiAgVW5yZWdpc3RlcmluZyBuZXRmaWx0ZXIgaG9va3MKdHlw
ZT0xNDA0IGF1ZGl0KDEzMzQ1OTM4NTIuODkwOjIpOiBzZWxpbnV4PTAgYXVpZD00Mjk0OTY3Mjk1
IHNlcz00Mjk0OTY3Mjk1CmRyYWN1dDogCmRyYWN1dDogU3dpdGNoaW5nIHJvb3QKcmVhZGFoZWFk
LWNvbGxlY3Rvcjogc3RhcnRpbmcKdWRldjogc3RhcnRpbmcgdmVyc2lvbiAxNDcKcGlpeDRfc21i
dXMgMDAwMDowMDowMS4zOiBTTUJ1cyBiYXNlIGFkZHJlc3MgdW5pbml0aWFsaXplZCAtIHVwZ3Jh
ZGUgQklPUyBvciB1c2UgZm9yY2VfYWRkcj0weGFkZHIKSW5pdGlhbGlzaW5nIFhlbiB2aXJ0dWFs
IGV0aGVybmV0IGRyaXZlci4KICBhbGxvYyBpcnFfZGVzYyBmb3IgMTggb24gbm9kZSAwCiAgYWxs
b2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKbWljcm9jb2RlOiBDUFUwIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKbWljcm9jb2RlOiBDUFUxIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKbWljcm9jb2RlOiBDUFUyIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKbWljcm9jb2RlOiBDUFUzIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKTWljcm9jb2RlIFVwZGF0ZSBEcml2ZXI6IHYyLjAwIDx0
aWdyYW5AYWl2YXppYW4uZnNuZXQuY28udWs+LCBQZXRlciBPcnViYQpzZCAyOjA6MDowOiBBdHRh
Y2hlZCBzY3NpIGdlbmVyaWMgc2cwIHR5cGUgMApwYXJwb3J0X3BjIDAwOjBiOiByZXBvcnRlZCBi
eSBQbHVnIGFuZCBQbGF5IEFDUEkKcGFycG9ydDA6IFBDLXN0eWxlIGF0IDB4Mzc4LCBpcnEgNyBb
UENTUFAsVFJJU1RBVEVdCnBwZGV2OiB1c2VyLXNwYWNlIHBhcmFsbGVsIHBvcnQgZHJpdmVyCnR1
bjogVW5pdmVyc2FsIFRVTi9UQVAgZGV2aWNlIGRyaXZlciwgMS42CnR1bjogKEMpIDE5OTktMjAw
NCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPgpBZGRpbmcgNTExOTkyayBzd2Fw
IG9uIC9kZXYveHZkYTIuICBQcmlvcml0eTotMSBleHRlbnRzOjEgYWNyb3NzOjUxMTk5MmsgU1MK
cmVhZGFoZWFkLWRpc2FibGUtc2VydmljZTogZGVsYXlpbmcgc2VydmljZSBhdWRpdGQKTkVUOiBS
ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMApsbzogRGlzYWJsZWQgUHJpdmFjeSBFeHRlbnNp
b25zClJQQzogUmVnaXN0ZXJlZCB1ZHAgdHJhbnNwb3J0IG1vZHVsZS4KUlBDOiBSZWdpc3RlcmVk
IHRjcCB0cmFuc3BvcnQgbW9kdWxlLgpSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2No
YW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4KQnJpZGdlIGZpcmV3YWxsaW5nIHJlZ2lzdGVyZWQKZGV2
aWNlIHZpcmJyMC1uaWMgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlCk5ldyBkZXZpY2UgdmlyYnIw
LW5pYyBkb2VzIG5vdCBzdXBwb3J0IG5ldHBvbGwKRGlzYWJsaW5nIG5ldHBvbGwgZm9yIHZpcmJy
MAp2aXJicjA6IHN0YXJ0aW5nIHVzZXJzcGFjZSBTVFAgZmFpbGVkLCBzdGFydGluZyBrZXJuZWwg
U1RQCmlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCm5mX2Nvbm50
cmFjayB2ZXJzaW9uIDAuNS4wICgxNjM4NCBidWNrZXRzLCA2NTUzNiBtYXgpCkVidGFibGVzIHYy
LjAgcmVnaXN0ZXJlZAppcDZfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBDb3JlIFRl
YW0KbG86IERpc2FibGVkIFByaXZhY3kgRXh0ZW5zaW9ucwpldGgwOiBubyBJUHY2IHJvdXRlcnMg
cHJlc2VudAp0eXBlPTEzMDUgYXVkaXQoMTMzNDU5Mzg4MC4zNjg6MjgxNDgpOiBhdWlkPTQyOTQ5
NjcyOTUgc2VzPTQyOTQ5NjcyOTUgb3A9InJlbW92ZSBydWxlIiBrZXk9KG51bGwpIGxpc3Q9NCBy
ZXM9MQp0eXBlPTEzMDUgYXVkaXQoMTMzNDU5Mzg4MC4zNjg6MjgxNDkpOiBhdWRpdF9lbmFibGVk
PTAgb2xkPTEgYXVpZD00Mjk0OTY3Mjk1IHNlcz00Mjk0OTY3Mjk1IHJlcz0xCnJlYWRhaGVhZC1j
b2xsZWN0b3I6IHN0YXJ0aW5nIGRlbGF5ZWQgc2VydmljZSBhdWRpdGQKcmVhZGFoZWFkLWNvbGxl
Y3Rvcjogc29ydGluZwpyZWFkYWhlYWQtY29sbGVjdG9yOiBmaW5pc2hlZApwc21vdXNlLmM6IEV4
cGxvcmVyIE1vdXNlIGF0IGlzYTAwNjAvc2VyaW8xL2lucHV0MCBsb3N0IHN5bmNocm9uaXphdGlv
biwgdGhyb3dpbmcgMSBieXRlcyBhd2F5Lgpwc21vdXNlLmM6IHJlc3luYyBmYWlsZWQsIGlzc3Vp
bmcgcmVjb25uZWN0IHJlcXVlc3QKaW5wdXQ6IEltRXhQUy8yIEdlbmVyaWMgRXhwbG9yZXIgTW91
c2UgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2VyaW8xL2lucHV0L2lucHV0NQppbnB1dDog
SW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3VzZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0
Mi9zZXJpbzEvaW5wdXQvaW5wdXQ2CnBzbW91c2UuYzogRXhwbG9yZXIgTW91c2UgYXQgaXNhMDA2
MC9zZXJpbzEvaW5wdXQwIGxvc3Qgc3luY2hyb25pemF0aW9uLCB0aHJvd2luZyAzIGJ5dGVzIGF3
YXkuCnBzbW91c2UuYzogcmVzeW5jIGZhaWxlZCwgaXNzdWluZyByZWNvbm5lY3QgcmVxdWVzdAo=

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: application/octet-stream; name="guest_lspci"
Content-Description: guest_lspci
Content-Disposition: attachment; filename="guest_lspci"; size=2055;
	creation-date="Mon, 16 Apr 2012 08:53:23 GMT";
	modification-date="Mon, 16 Apr 2012 01:55:42 GMT"
Content-Transfer-Encoding: base64

MDA6MDUuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlv
biBQYXRzYnVyZyA0LVBvcnQgU0FUQS9TQVMgU3RvcmFnZSBDb250cm9sIFVuaXQgKHJldiAwNSkK
CVN1YnN5c3RlbTogSW50ZWwgQ29ycG9yYXRpb24gRGV2aWNlIDM1ODUKCVBoeXNpY2FsIFNsb3Q6
IDUKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6
IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8
VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiA2NAoJSW50ZXJy
dXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDM2CglSZWdpb24gMDogTWVtb3J5IGF0IGYzNDAwMDAw
ICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZLXQoJUmVnaW9uIDI6IE1lbW9yeSBhdCBm
MzAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRNXQoJUmVnaW9uIDQ6IEkvTyBw
b3J0cyBhdCBjMjAwIFtzaXplPTI1Nl0KCUNhcGFiaWxpdGllczogWzk4XSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBt
QSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3Qr
IFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFtjNF0gRXhw
cmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTAyNCBieXRl
cywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkCgkJCUV4
dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglS
ZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQt
CgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0KCQlMbmtD
YXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5j
eSBMMCA8NjRucywgTDEgPDF1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90
LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWlu
LSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJ
bnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENvbXBsZXRpb24gVGlt
ZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcy0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRp
bWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBT
cGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNl
IERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSS1YOiBFbmFibGUrIENvdW50PTIgTWFza2VkLQoJ
CVZlY3RvciB0YWJsZTogQkFSPTAgb2Zmc2V0PTAwMDAyMDAwCgkJUEJBOiBCQVI9MCBvZmZzZXQ9
MDAwMDMwMDAKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBpc2NpCglLZXJuZWwgbW9kdWxlczogaXNj
aQoK

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_--


From xen-devel-bounces@lists.xen.org Mon Apr 16 08:56:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 08:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhig-0007md-IT; Mon, 16 Apr 2012 08:55:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SJhie-0007mW-Ke
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 08:55:33 +0000
Received: from [85.158.139.83:27391] by server-12.bemta-5.messagelabs.com id
	5D/39-05587-38EDB8F4; Mon, 16 Apr 2012 08:55:31 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334566528!23972030!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEzMDkz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3343 invoked from network); 16 Apr 2012 08:55:29 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-182.messagelabs.com with SMTP;
	16 Apr 2012 08:55:29 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 16 Apr 2012 01:55:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,217";a="131358469"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 16 Apr 2012 01:55:26 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 16 Apr 2012 01:55:26 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.195]) with mapi id
	14.01.0355.002; Mon, 16 Apr 2012 16:55:14 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Aleksandr Tarutin <atarutin@orionsbelt.net>
Thread-Topic: [Xen-devel] PCI Passthrough of SAS controller not working
Thread-Index: AQHNGB0PzLWiCnCV1EGhgknobH6H3JadKdsg
Date: Mon, 16 Apr 2012 08:55:14 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD11C89@SHSMSX102.ccr.corp.intel.com>
References: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
In-Reply-To: <CAO9X3SiEk1RE+Zi=w3yWutvRpGGUpcyaLptVB0Um-dtK0oKzdg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI Passthrough of SAS controller not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: multipart/alternative;
	boundary="_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_"

--_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In your guest lspci log file, I do see the attached SAS device is owned by =
mpt2sas driver in your guest log.

We did simple testing with a SAS controller assignment to RHEL6.2 guest on =
Xen unstable 25164, both passthrough and pci-attach/detach works well.

Sharing the log to you, and can you update your Xen to latest and try?


Thanks,
-Xudong

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Aleksandr Tarutin
Sent: Thursday, April 12, 2012 3:52 AM
To: xen-devel@lists.xen.org
Subject: [Xen-devel] PCI Passthrough of SAS controller not working

Hello.

I tried to setup PCI Passthrough of a SAS controller into a PVHVM domU. The=
 device was present in the domU but its modules wouldn't load.

The first related thing was the following message in the guest BIOS just be=
fore grub starts:
MPT BIOS Fault 09h encountered at adapter PCI(00h,05h,00h).

I'm attaching the xm dmesg and dmesg from both the host and a guest as well=
 as lspci -v.

--
AT.


--_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In your gu=
est lspci log file, I do see the attached SAS device is owned by mpt2sas dr=
iver in your guest log.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">We did sim=
ple testing with a SAS controller assignment to RHEL6.2 guest on Xen unstab=
le 25164, both passthrough and pci-attach/detach works well.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Sharing th=
e log to you, and can you update your Xen to latest and try?<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:p></o:p></span></=
p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1F497D">-Xudong<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> xen-devel-bounces@lists.xen.org [mailto:xen-devel-bou=
nces@lists.xen.org]
<b>On Behalf Of </b>Aleksandr Tarutin<br>
<b>Sent:</b> Thursday, April 12, 2012 3:52 AM<br>
<b>To:</b> xen-devel@lists.xen.org<br>
<b>Subject:</b> [Xen-devel] PCI Passthrough of SAS controller not working<o=
:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hello.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I tried to setup PCI Passthroug=
h of a SAS controller into a PVHVM domU. The device was present in the domU=
 but its modules wouldn't load.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The first related thing was the=
 following message in the guest BIOS just before grub starts:<o:p></o:p></s=
pan></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">MPT BIOS Fault 09h encountered =
at adapter&nbsp;PCI(00h,05h,00h).<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I'm attaching the xm dmesg and =
dmesg from both the host and a guest as well as lspci -v.<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">-- <o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">AT.<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_--

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: application/octet-stream; name="dom0_lspci"
Content-Description: dom0_lspci
Content-Disposition: attachment; filename="dom0_lspci"; size=3334;
	creation-date="Mon, 16 Apr 2012 08:52:53 GMT";
	modification-date="Mon, 16 Apr 2012 01:55:42 GMT"
Content-Transfer-Encoding: base64

MDc6MDAuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlv
biBQYXRzYnVyZyA0LVBvcnQgU0FUQS9TQVMgU3RvcmFnZSBDb250cm9sIFVuaXQgKHJldiAwNSkK
CVN1YnN5c3RlbTogSW50ZWwgQ29ycG9yYXRpb24gRGV2aWNlIDM1ODUKCUNvbnRyb2w6IEkvTysg
TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+
U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTYKCVJlZ2lvbiAwOiBNZW1vcnkgYXQg
ZWI4MDAwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdCglSZWdpb24gMjogTWVt
b3J5IGF0IGViNDAwMDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9NE1dCglSZWdpb24g
NDogSS9PIHBvcnRzIGF0IDIwMDAgW3NpemU9MjU2XQoJQ2FwYWJpbGl0aWVzOiBbOThdIFBvd2Vy
IE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1
cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5v
U29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczog
W2M0XSBFeHByZXNzICh2MikgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAx
MDI0IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQKCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldCsKCQlE
ZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1
cHBvcnRlZC0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsg
RkxSZXNldC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTAyNCBieXRlcwoJ
CURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3It
IFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cwoJCQlDbG9ja1BNLSBTdXJwcmlz
ZS0gTExBY3RSZXAtIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVz
IERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lk
RGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNh
cDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcy0KCQlEZXZD
dGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtD
dGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9y
bWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VT
T1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBE
ZS1lbXBoYXNpcyBMZXZlbDogLTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSS1YOiBFbmFibGUr
IENvdW50PTIgTWFza2VkLQoJCVZlY3RvciB0YWJsZTogQkFSPTAgb2Zmc2V0PTAwMDAyMDAwCgkJ
UEJBOiBCQVI9MCBvZmZzZXQ9MDAwMDMwMDAKCUNhcGFiaWxpdGllczogWzEwMF0gQWR2YW5jZWQg
RXJyb3IgUmVwb3J0aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENt
cGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxKyBBQ1NWaW9s
LQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENt
cGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURM
UCsgU0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1h
bGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBC
YWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4RXJyLSBC
YWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6
CUZpcnN0IEVycm9yIFBvaW50ZXI6IDE0LCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtFbi0K
CUNhcGFiaWxpdGllczogWzEzOF0gQWx0ZXJuYXRpdmUgUm91dGluZy1JRCBJbnRlcnByZXRhdGlv
biAoQVJJKQoJCUFSSUNhcDoJTUZWQy0gQUNTLSwgTmV4dCBGdW5jdGlvbjogMwoJCUFSSUN0bDoJ
TUZWQy0gQUNTLSwgRnVuY3Rpb24gR3JvdXA6IDAKCUNhcGFiaWxpdGllczogWzE4MF0gVHJhbnNh
Y3Rpb24gUHJvY2Vzc2luZyBIaW50cwoJCURldmljZSBzcGVjaWZpYyBtb2RlIHN1cHBvcnRlZAoJ
CU5vIHN0ZWVyaW5nIHRhYmxlIGF2YWlsYWJsZQoJQ2FwYWJpbGl0aWVzOiBbMTQwXSBTaW5nbGUg
Um9vdCBJL08gVmlydHVhbGl6YXRpb24gKFNSLUlPVikKCQlJT1ZDYXA6CU1pZ3JhdGlvbi0sIElu
dGVycnVwdCBNZXNzYWdlIE51bWJlcjogMDAwCgkJSU9WQ3RsOglFbmFibGUtIE1pZ3JhdGlvbi0g
SW50ZXJydXB0LSBNU0UtIEFSSUhpZXJhcmNoeSsKCQlJT1ZTdGE6CU1pZ3JhdGlvbi0KCQlJbml0
aWFsIFZGczogMzEsIFRvdGFsIFZGczogMzEsIE51bWJlciBvZiBWRnM6IDAsIEZ1bmN0aW9uIERl
cGVuZGVuY3kgTGluazogMDAKCQlWRiBvZmZzZXQ6IDgsIHN0cmlkZTogMSwgRGV2aWNlIElEOiAx
ZDU5CgkJU3VwcG9ydGVkIFBhZ2UgU2l6ZTogMDAwMDA1NTMsIFN5c3RlbSBQYWdlIFNpemU6IDAw
MDAwMDAxCgkJUmVnaW9uIDA6IE1lbW9yeSBhdCAwMDAwMDAwMGViODEwMDAwICg2NC1iaXQsIHBy
ZWZldGNoYWJsZSkKCQlWRiBNaWdyYXRpb246IG9mZnNldDogMDAwMDAwMDAsIEJJUjogMAoJS2Vy
bmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sKCg==

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: application/octet-stream; name="guest_dmesg"
Content-Description: guest_dmesg
Content-Disposition: attachment; filename="guest_dmesg"; size=22115;
	creation-date="Mon, 16 Apr 2012 08:53:18 GMT";
	modification-date="Mon, 16 Apr 2012 01:55:42 GMT"
Content-Transfer-Encoding: base64

SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vi
c3lzIGNwdQpMaW51eCB2ZXJzaW9uIDIuNi4zMi0yMjAuZWw2Lng4Nl82NCAobW9ja2J1aWxkQHg4
Ni0wMDQuYnVpbGQuYm9zLnJlZGhhdC5jb20pIChnY2MgdmVyc2lvbiA0LjQuNSAyMDExMDIxNCAo
UmVkIEhhdCA0LjQuNS02KSAoR0NDKSApICMxIFNNUCBXZWQgTm92IDkgMDg6MDM6MTMgRVNUIDIw
MTEKQ29tbWFuZCBsaW5lOiBybyByb290PVVVSUQ9YzJhNjkzNTctOThhYy00OWZjLTgxYmQtNzAy
ZTRhODZjZWQ4IHJkX05PX0xVS1MgcmRfTk9fTFZNIExBTkc9ZW5fVVMuVVRGLTggcmRfTk9fTUQg
cXVpZXQgU1lTRk9OVD1sYXRhcmN5cmhlYi1zdW4xNiByaGdiICBLRVlCT0FSRFRZUEU9cGMgS0VZ
VEFCTEU9dXMgcmRfTk9fRE0KS0VSTkVMIHN1cHBvcnRlZCBjcHVzOgogIEludGVsIEdlbnVpbmVJ
bnRlbAogIEFNRCBBdXRoZW50aWNBTUQKICBDZW50YXVyIENlbnRhdXJIYXVscwpCSU9TLXByb3Zp
ZGVkIHBoeXNpY2FsIFJBTSBtYXA6CiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAw
MDAwMDAwMDllMDAwICh1c2FibGUpCiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAw
MDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKIEJJT1MtZTgyMDogMDAwMDAwMDAwMDBlMDAwMCAtIDAw
MDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQogQklPUy1lODIwOiAwMDAwMDAwMDAwMTAwMDAwIC0g
MDAwMDAwMDA3ZjgwMDAwMCAodXNhYmxlKQogQklPUy1lODIwOiAwMDAwMDAwMGZjMDAwMDAwIC0g
MDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCkRNSSAyLjQgcHJlc2VudC4KU01CSU9TIHZlcnNp
b24gMi40IEAgMHhGQkI4MApETUk6IFhlbiBIVk0gZG9tVSwgQklPUyA0LjItdW5zdGFibGUgMDQv
MTIvMjAxMgplODIwIHVwZGF0ZSByYW5nZTogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAw
MDEwMDAgKHVzYWJsZSkgPT0+IChyZXNlcnZlZCkKZTgyMCByZW1vdmUgcmFuZ2U6IDAwMDAwMDAw
MDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwICh1c2FibGUpCmxhc3RfcGZuID0gMHg3ZjgwMCBt
YXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApNVFJSIGRlZmF1bHQgdHlwZTogd3JpdGUtYmFjawpN
VFJSIGZpeGVkIHJhbmdlcyBlbmFibGVkOgogIDAwMDAwLTlGRkZGIHdyaXRlLWJhY2sKICBBMDAw
MC1CRkZGRiB3cml0ZS1jb21iaW5pbmcKICBDMDAwMC1GRkZGRiB3cml0ZS1iYWNrCk1UUlIgdmFy
aWFibGUgcmFuZ2VzIGVuYWJsZWQ6CiAgMCBiYXNlIDAwMDBGMDAwMDAwMCBtYXNrIDNGRkZGODAw
MDAwMCB1bmNhY2hhYmxlCiAgMSBiYXNlIDAwMDBGODAwMDAwMCBtYXNrIDNGRkZGQzAwMDAwMCB1
bmNhY2hhYmxlCiAgMiBkaXNhYmxlZAogIDMgZGlzYWJsZWQKICA0IGRpc2FibGVkCiAgNSBkaXNh
YmxlZAogIDYgZGlzYWJsZWQKICA3IGRpc2FibGVkCng4NiBQQVQgZW5hYmxlZDogY3B1IDAsIG9s
ZCAweDcwNDA2MDAwNzA0MDYsIG5ldyAweDcwMTA2MDAwNzAxMDYKaW5pdGlhbCBtZW1vcnkgbWFw
cGVkIDogMCAtIDIwMDAwMDAwCmluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAt
MDAwMDAwMDA3ZjgwMDAwMAogMDAwMDAwMDAwMCAtIDAwN2Y4MDAwMDAgcGFnZSAyTQprZXJuZWwg
ZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDdmODAwMDAwIEAgODAwMC1iMDAwClJBTURJU0s6
IDM3MGI5MDAwIC0gMzdmZWZhNTMKQUNQSTogUlNEUCAwMDAwMDAwMDAwMGVhMDIwIDAwMDI0ICh2
MDIgICAgWGVuKQpBQ1BJOiBYU0RUIDAwMDAwMDAwZmMwMGY2MTAgMDAwNTQgKHYwMSAgICBYZW4g
ICAgICBIVk0gMDAwMDAwMDAgSFZNTCAwMDAwMDAwMCkKQUNQSTogRkFDUCAwMDAwMDAwMGZjMDBm
MmQwIDAwMEY0ICh2MDQgICAgWGVuICAgICAgSFZNIDAwMDAwMDAwIEhWTUwgMDAwMDAwMDApCkFD
UEk6IERTRFQgMDAwMDAwMDBmYzAwMzVlMCAwQkM2RSAodjAyICAgIFhlbiAgICAgIEhWTSAwMDAw
MDAwMCBJTlRMIDIwMDkwMTIzKQpBQ1BJOiBGQUNTIDAwMDAwMDAwZmMwMDM1YTAgMDAwNDAKQUNQ
STogQVBJQyAwMDAwMDAwMGZjMDBmM2QwIDAwMEQ4ICh2MDIgICAgWGVuICAgICAgSFZNIDAwMDAw
MDAwIEhWTUwgMDAwMDAwMDApCkFDUEk6IEhQRVQgMDAwMDAwMDBmYzAwZjUyMCAwMDAzOCAodjAx
ICAgIFhlbiAgICAgIEhWTSAwMDAwMDAwMCBIVk1MIDAwMDAwMDAwKQpBQ1BJOiBXQUVUIDAwMDAw
MDAwZmMwMGY1NjAgMDAwMjggKHYwMSAgICBYZW4gICAgICBIVk0gMDAwMDAwMDAgSFZNTCAwMDAw
MDAwMCkKQUNQSTogU1NEVCAwMDAwMDAwMGZjMDBmNTkwIDAwMDMxICh2MDIgICAgWGVuICAgICAg
SFZNIDAwMDAwMDAwIElOVEwgMjAwOTAxMjMpCkFDUEk6IFNTRFQgMDAwMDAwMDBmYzAwZjVkMCAw
MDAzMSAodjAyICAgIFhlbiAgICAgIEhWTSAwMDAwMDAwMCBJTlRMIDIwMDkwMTIzKQpBQ1BJOiBM
b2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQK
RmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwN2Y4MDAwMDAKQm9vdG1l
bSBzZXR1cCBub2RlIDAgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDdmODAwMDAwCiAgTk9ERV9E
QVRBIFswMDAwMDAwMDAwMDA5MDAwIC0gMDAwMDAwMDAwMDAzY2ZmZl0KICBib290bWFwIFswMDAw
MDAwMDAwMDNkMDAwIC0gIDAwMDAwMDAwMDAwNGNlZmZdIHBhZ2VzIDEwCig3IGVhcmx5IHJlc2Vy
dmF0aW9ucykgPT0+IGJvb3RtZW0gWzAwMDAwMDAwMDAgLSAwMDdmODAwMDAwXQogICMwIFswMDAw
MDAwMDAwIC0gMDAwMDAwMTAwMF0gICBCSU9TIGRhdGEgcGFnZSA9PT4gWzAwMDAwMDAwMDAgLSAw
MDAwMDAxMDAwXQogICMxIFswMDAwMDA2MDAwIC0gMDAwMDAwODAwMF0gICAgICAgVFJBTVBPTElO
RSA9PT4gWzAwMDAwMDYwMDAgLSAwMDAwMDA4MDAwXQogICMyIFswMDAxMDAwMDAwIC0gMDAwMjAw
YzdlNF0gICAgVEVYVCBEQVRBIEJTUyA9PT4gWzAwMDEwMDAwMDAgLSAwMDAyMDBjN2U0XQogICMz
IFswMDM3MGI5MDAwIC0gMDAzN2ZlZmE1M10gICAgICAgICAgUkFNRElTSyA9PT4gWzAwMzcwYjkw
MDAgLSAwMDM3ZmVmYTUzXQogICM0IFswMDAwMDllMDAwIC0gMDAwMDEwMDAwMF0gICAgQklPUyBy
ZXNlcnZlZCA9PT4gWzAwMDAwOWUwMDAgLSAwMDAwMTAwMDAwXQogICM1IFswMDAyMDBkMDAwIC0g
MDAwMjAwZDBkOF0gICAgICAgICAgICAgIEJSSyA9PT4gWzAwMDIwMGQwMDAgLSAwMDAyMDBkMGQ4
XQogICM2IFswMDAwMDA4MDAwIC0gMDAwMDAwOTAwMF0gICAgICAgICAgUEdUQUJMRSA9PT4gWzAw
MDAwMDgwMDAgLSAwMDAwMDA5MDAwXQpmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAwMDAw
ZmJiYTBdIGZiYmEwCiBbZmZmZmVhMDAwMDAwMDAwMC1mZmZmZWEwMDAxYmZmZmZmXSBQTUQgLT4g
W2ZmZmY4ODAwMDI2MDAwMDAtZmZmZjg4MDAwNDFmZmZmZl0gb24gbm9kZSAwClpvbmUgUEZOIHJh
bmdlczoKICBETUEgICAgICAweDAwMDAwMDAxIC0+IDB4MDAwMDEwMDAKICBETUEzMiAgICAweDAw
MDAxMDAwIC0+IDB4MDAxMDAwMDAKICBOb3JtYWwgICAweDAwMTAwMDAwIC0+IDB4MDAxMDAwMDAK
TW92YWJsZSB6b25lIHN0YXJ0IFBGTiBmb3IgZWFjaCBub2RlCmVhcmx5X25vZGVfbWFwWzJdIGFj
dGl2ZSBQRk4gcmFuZ2VzCiAgICAwOiAweDAwMDAwMDAxIC0+IDB4MDAwMDAwOWUKICAgIDA6IDB4
MDAwMDAxMDAgLT4gMHgwMDA3ZjgwMApPbiBub2RlIDAgdG90YWxwYWdlczogNTIyMTQxCiAgRE1B
IHpvbmU6IDU2IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcAogIERNQSB6b25lOiAxMDIgcGFnZXMgcmVz
ZXJ2ZWQKICBETUEgem9uZTogMzgzOSBwYWdlcywgTElGTyBiYXRjaDowCiAgRE1BMzIgem9uZTog
NzA4NCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKICBETUEzMiB6b25lOiA1MTEwNjAgcGFnZXMsIExJ
Rk8gYmF0Y2g6MzEKQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHhiMDA4CkFDUEk6IExvY2FsIEFQ
SUMgYWRkcmVzcyAweGZlZTAwMDAwCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDBdIGxhcGljX2lk
WzB4MDBdIGVuYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDJd
IGVuYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDRdIGVuYWJs
ZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDZdIGVuYWJsZWQpCkFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDhdIGRpc2FibGVkKQpBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDBhXSBkaXNhYmxlZCkKQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwY10gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDddIGxhcGljX2lkWzB4MGVdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDA4XSBsYXBpY19pZFsweDEwXSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0g
bGFwaWNfaWRbMHgxMl0gZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGFdIGxhcGlj
X2lkWzB4MTRdIGRpc2FibGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBiXSBsYXBpY19pZFsw
eDE2XSBkaXNhYmxlZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwY10gbGFwaWNfaWRbMHgxOF0g
ZGlzYWJsZWQpCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGRdIGxhcGljX2lkWzB4MWFdIGRpc2Fi
bGVkKQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBlXSBsYXBpY19pZFsweDFjXSBkaXNhYmxlZCkK
QUNQSTogSU9BUElDIChpZFsweDAxXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQpJ
T0FQSUNbMF06IGFwaWNfaWQgMSwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kg
MC00NwpBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwg
ZGZsKQpBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBsb3cg
bGV2ZWwpCkFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDEwIGdsb2JhbF9pcnEgMTAg
bG93IGxldmVsKQpBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAxMSBnbG9iYWxfaXJx
IDExIGxvdyBsZXZlbCkKQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlEyIHVz
ZWQgYnkgb3ZlcnJpZGUuCkFDUEk6IElSUTUgdXNlZCBieSBvdmVycmlkZS4KQUNQSTogSVJROSB1
c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlExMCB1c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlEx
MSB1c2VkIGJ5IG92ZXJyaWRlLgpVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRp
b24gaW5mb3JtYXRpb24KQUNQSTogSFBFVCBpZDogMHg4MDg2YTIwMSBiYXNlOiAweGZlZDAwMDAw
ClNNUDogQWxsb3dpbmcgMTUgQ1BVcywgMTEgaG90cGx1ZyBDUFVzCm5yX2lycXNfZ3NpOiA0OApY
ZW4gdmVyc2lvbiA0LjIuClhlbiBQbGF0Zm9ybSBQQ0k6IEkvTyBwcm90b2NvbCB2ZXJzaW9uIDEK
TmV0ZnJvbnQgYW5kIHRoZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGls
ZWQgZm9yIHRoaXMga2VybmVsOiB1bnBsdWcgZW11bGF0ZWQgTklDcy4KQmxrZnJvbnQgYW5kIHRo
ZSBYZW4gcGxhdGZvcm0gUENJIGRyaXZlciBoYXZlIGJlZW4gY29tcGlsZWQgZm9yIHRoaXMga2Vy
bmVsOiB1bnBsdWcgZW11bGF0ZWQgZGlza3MuCllvdSBtaWdodCBoYXZlIHRvIGNoYW5nZSB0aGUg
cm9vdCBkZXZpY2UKZnJvbSAvZGV2L2hkW2EtZF0gdG8gL2Rldi94dmRbYS1kXQppbiB5b3VyIHJv
b3Q9IGtlcm5lbCBjb21tYW5kIGxpbmUgb3B0aW9uClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAwMDAwMDAwMGEwMDAwClBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMGUwMDAwClBNOiBSZWdp
c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAw
CkFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFydGluZyBhdCA3ZjgwMDAwMCAoZ2FwOiA3Zjgw
MDAwMDo3YzgwMDAwMCkKQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpOUl9D
UFVTOjQwOTYgbnJfY3B1bWFza19iaXRzOjE1IG5yX2NwdV9pZHM6MTUgbnJfbm9kZV9pZHM6MQpQ
RVJDUFU6IEVtYmVkZGVkIDMwIHBhZ2VzL2NwdSBAZmZmZjg4MDAwMjIwMDAwMCBzOTI2OTYgcjgx
OTIgZDIxOTkyIHUxMzEwNzIKcGNwdS1hbGxvYzogczkyNjk2IHI4MTkyIGQyMTk5MiB1MTMxMDcy
IGFsbG9jPTEqMjA5NzE1MgpwY3B1LWFsbG9jOiBbMF0gMDAgMDEgMDIgMDMgMDQgMDUgMDYgMDcg
MDggMDkgMTAgMTEgMTIgMTMgMTQgLS0gCkJ1aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIs
IG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDUxNDg5OQpQb2xpY3kgem9uZTog
RE1BMzIKS2VybmVsIGNvbW1hbmQgbGluZTogcm8gcm9vdD1VVUlEPWMyYTY5MzU3LTk4YWMtNDlm
Yy04MWJkLTcwMmU0YTg2Y2VkOCByZF9OT19MVUtTIHJkX05PX0xWTSBMQU5HPWVuX1VTLlVURi04
IHJkX05PX01EIHF1aWV0IFNZU0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgcmhnYiAgS0VZQk9BUkRU
WVBFPXBjIEtFWVRBQkxFPXVzIHJkX05PX0RNClBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYg
KG9yZGVyOiAzLCAzMjc2OCBieXRlcykKeHNhdmUveHJzdG9yOiBlbmFibGVkIHhzdGF0ZV9idiAw
eDcsIGNudHh0IHNpemUgMHgzNDAKQ2hlY2tpbmcgYXBlcnR1cmUuLi4KTm8gQUdQIGJyaWRnZSBm
b3VuZApNZW1vcnk6IDIwMjU1NjRrLzIwODg5NjBrIGF2YWlsYWJsZSAoNTA4NGsga2VybmVsIGNv
ZGUsIDM5NmsgYWJzZW50LCA2MzAwMGsgcmVzZXJ2ZWQsIDcyMjlrIGRhdGEsIDEyNDRrIGluaXQp
CkhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uCk5SX0lSUVM6MzMwMjQgbnJfaXJxczo5
MzYKWGVuIEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50IGRlbGl2ZXJ5IGlzIGVuYWJsZWQK
Q29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKY29uc29sZSBbdHR5MF0gZW5hYmxlZAphbGxvY2F0
ZWQgMTY3NzcyMTYgYnl0ZXMgb2YgcGFnZV9jZ3JvdXAKcGxlYXNlIHRyeSAnY2dyb3VwX2Rpc2Fi
bGU9bWVtb3J5JyBvcHRpb24gaWYgeW91IGRvbid0IHdhbnQgbWVtb3J5IGNncm91cHMKaHBldCBj
bG9ja2V2ZW50IHJlZ2lzdGVyZWQKSFBFVDogMyB0aW1lcnMgaW4gdG90YWwsIDAgdGltZXJzIHdp
bGwgYmUgdXNlZCBmb3IgcGVyLWNwdSB0aW1lcgpGYXN0IFRTQyBjYWxpYnJhdGlvbiB1c2luZyBQ
SVQKRGV0ZWN0ZWQgMjY5My41ODcgTUh6IHByb2Nlc3Nvci4KQ2FsaWJyYXRpbmcgZGVsYXkgbG9v
cCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNTM4
Ny4xNyBCb2dvTUlQUyAobHBqPTI2OTM1ODcpCnBpZF9tYXg6IGRlZmF1bHQ6IDMyNzY4IG1pbmlt
dW06IDMwMQpTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQKU0VMaW51eDogIEluaXRpYWxp
emluZy4KU0VMaW51eDogIFN0YXJ0aW5nIGluIHBlcm1pc3NpdmUgbW9kZQpEZW50cnkgY2FjaGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9yZGVyOiA5LCAyMDk3MTUyIGJ5dGVzKQpJbm9k
ZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0
ZXMpCk1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMjU2CkluaXRpYWxpemluZyBjZ3Jv
dXAgc3Vic3lzIG5zCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QKSW5pdGlhbGl6
aW5nIGNncm91cCBzdWJzeXMgbWVtb3J5CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGRldmlj
ZXMKSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcgpJbml0aWFsaXppbmcgY2dyb3Vw
IHN1YnN5cyBuZXRfY2xzCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGJsa2lvCkluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIHBlcmZfZXZlbnQKQ1BVOiBDUFUgZmVhdHVyZSByZHRzY3AgZGlz
YWJsZWQgb24geGVuIGd1ZXN0CkNQVTogQ1BVIGZlYXR1cmUgY29uc3RhbnRfdHNjIGRpc2FibGVk
IG9uIHhlbiBndWVzdApDUFU6IFVuc3VwcG9ydGVkIG51bWJlciBvZiBzaWJsaW5ncyA2NAptY2U6
IENQVSBzdXBwb3J0cyAyMCBNQ0UgYmFua3MKYWx0ZXJuYXRpdmVzOiBzd2l0Y2hpbmcgdG8gdW5m
YWlyIHNwaW5sb2NrCkFDUEk6IENvcmUgcmV2aXNpb24gMjAwOTA5MDMKZnRyYWNlOiBjb252ZXJ0
aW5nIG1jb3VudCBjYWxscyB0byAwZiAxZiA0NCAwMCAwMApmdHJhY2U6IGFsbG9jYXRpbmcgMjA3
NzYgZW50cmllcyBpbiA4MiBwYWdlcwp4MmFwaWMgbm90IGVuYWJsZWQsIElSUSByZW1hcHBpbmcg
aW5pdCBmYWlsZWQKU2V0dGluZyBBUElDIHJvdXRpbmcgdG8gcGh5c2ljYWwgZmxhdAouLlRJTUVS
OiB2ZWN0b3I9MHgzMCBhcGljMT0wIHBpbjE9MiBhcGljMj0wIHBpbjI9MApDUFUwOiBJbnRlbChS
KSBYZW9uKFIpIENQVSBFNS0yNjgwIDAgQCAyLjcwR0h6IHN0ZXBwaW5nIDA2ClBlcmZvcm1hbmNl
IEV2ZW50czogU2FuZHlCcmlkZ2UgZXZlbnRzLCBJbnRlbCBQTVUgZHJpdmVyLgouLi4gdmVyc2lv
bjogICAgICAgICAgICAgICAgMwouLi4gYml0IHdpZHRoOiAgICAgICAgICAgICAgNDgKLi4uIGdl
bmVyaWMgcmVnaXN0ZXJzOiAgICAgIDQKLi4uIHZhbHVlIG1hc2s6ICAgICAgICAgICAgIDAwMDBm
ZmZmZmZmZmZmZmYKLi4uIG1heCBwZXJpb2Q6ICAgICAgICAgICAgIDAwMDAwMDAwN2ZmZmZmZmYK
Li4uIGZpeGVkLXB1cnBvc2UgZXZlbnRzOiAgIDMKLi4uIGV2ZW50IG1hc2s6ICAgICAgICAgICAg
IDAwMDAwMDA3MDAwMDAwMGYKTk1JIHdhdGNoZG9nIGVuYWJsZWQsIHRha2VzIG9uZSBody1wbXUg
Y291bnRlci4KQm9vdGluZyBOb2RlICAgMCwgUHJvY2Vzc29ycyAgIzEKQ1BVOiBDUFUgZmVhdHVy
ZSByZHRzY3AgZGlzYWJsZWQgb24geGVuIGd1ZXN0CkNQVTogQ1BVIGZlYXR1cmUgY29uc3RhbnRf
dHNjIGRpc2FibGVkIG9uIHhlbiBndWVzdApDUFU6IFVuc3VwcG9ydGVkIG51bWJlciBvZiBzaWJs
aW5ncyA2NCAjMgpDUFU6IENQVSBmZWF0dXJlIHJkdHNjcCBkaXNhYmxlZCBvbiB4ZW4gZ3Vlc3QK
Q1BVOiBDUFUgZmVhdHVyZSBjb25zdGFudF90c2MgZGlzYWJsZWQgb24geGVuIGd1ZXN0CkNQVTog
VW5zdXBwb3J0ZWQgbnVtYmVyIG9mIHNpYmxpbmdzIDY0ICMzCkNQVTogQ1BVIGZlYXR1cmUgcmR0
c2NwIGRpc2FibGVkIG9uIHhlbiBndWVzdApDUFU6IENQVSBmZWF0dXJlIGNvbnN0YW50X3RzYyBk
aXNhYmxlZCBvbiB4ZW4gZ3Vlc3QKQ1BVOiBVbnN1cHBvcnRlZCBudW1iZXIgb2Ygc2libGluZ3Mg
NjQKQnJvdWdodCB1cCA0IENQVXMKVG90YWwgb2YgNCBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMjE1
NDguMTIgQm9nb01JUFMpLgpzaXplb2Yodm1hKT0yMDAgYnl0ZXMKc2l6ZW9mKHBhZ2UpPTU2IGJ5
dGVzCnNpemVvZihpbm9kZSk9NTkyIGJ5dGVzCnNpemVvZihkZW50cnkpPTE5MiBieXRlcwpzaXpl
b2YoZXh0M2lub2RlKT04MDAgYnl0ZXMKc2l6ZW9mKGJ1ZmZlcl9oZWFkKT0xMDQgYnl0ZXMKc2l6
ZW9mKHNrYnVmZik9MjMyIGJ5dGVzCnNpemVvZih0YXNrX3N0cnVjdCk9MjYxNiBieXRlcwpkZXZ0
bXBmczogaW5pdGlhbGl6ZWQKcmVndWxhdG9yOiBjb3JlIHZlcnNpb24gMC41Ck5FVDogUmVnaXN0
ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKICBhbGxvYyBpcnFfZGVzYyBmb3IgMTYgb24gbm9kZSAw
CiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVy
ZWQKUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MKYmlvOiBj
cmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKQUNQSTogRUM6IExvb2sgdXAgRUMgaW4gRFNEVApBQ1BJ
OiBJbnRlcnByZXRlciBlbmFibGVkCkFDUEk6IChzdXBwb3J0cyBTMCBTMyBTNCBTNSkKQUNQSTog
VXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZwpBQ1BJOiBObyBkb2NrIGRldmljZXMg
Zm91bmQuCkhFU1Q6IFRhYmxlIG5vdCBmb3VuZC4KQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kw
XSAoMDAwMDowMCkKcGNpIDAwMDA6MDA6MDEuMTogcmVnIDIwIGlvIHBvcnQ6IFsweGMzMDAtMHhj
MzBmXQoqIEZvdW5kIFBNLVRpbWVyIEJ1ZyBvbiB0aGUgY2hpcHNldC4gRHVlIHRvIHdvcmthcm91
bmRzIGZvciBhIGJ1ZywKKiB0aGlzIGNsb2NrIHNvdXJjZSBpcyBzbG93LiBDb25zaWRlciB0cnlp
bmcgb3RoZXIgY2xvY2sgc291cmNlcwpwY2kgMDAwMDowMDowMS4zOiBxdWlyazogcmVnaW9uIGIw
MDAtYjAzZiBjbGFpbWVkIGJ5IFBJSVg0IEFDUEkKcGNpIDAwMDA6MDA6MDIuMDogcmVnIDEwIDMy
Yml0IG1taW8gcHJlZjogWzB4ZjAwMDAwMDAtMHhmMWZmZmZmZl0KcGNpIDAwMDA6MDA6MDIuMDog
cmVnIDE0IDMyYml0IG1taW86IFsweGYzNDA0MDAwLTB4ZjM0MDRmZmZdCnBjaSAwMDAwOjAwOjAz
LjA6IHJlZyAxMCBpbyBwb3J0OiBbMHhjMDAwLTB4YzBmZl0KcGNpIDAwMDA6MDA6MDMuMDogcmVn
IDE0IDMyYml0IG1taW8gcHJlZjogWzB4ZjIwMDAwMDAtMHhmMmZmZmZmZl0KcGNpIDAwMDA6MDA6
MDUuMDogcmVnIDEwIDY0Yml0IG1taW8gcHJlZjogWzB4ZjM0MDAwMDAtMHhmMzQwM2ZmZl0KcGNp
IDAwMDA6MDA6MDUuMDogcmVnIDE4IDY0Yml0IG1taW8gcHJlZjogWzB4ZjMwMDAwMDAtMHhmMzNm
ZmZmZl0KcGNpIDAwMDA6MDA6MDUuMDogcmVnIDIwIGlvIHBvcnQ6IFsweGMyMDAtMHhjMmZmXQpB
Q1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuX1BSVF0KQUNQSTog
UENJIEludGVycnVwdCBMaW5rIFtMTktBXSAoSVJRcyAqNSAxMCAxMSkKQUNQSTogUENJIEludGVy
cnVwdCBMaW5rIFtMTktCXSAoSVJRcyA1ICoxMCAxMSkKQUNQSTogUENJIEludGVycnVwdCBMaW5r
IFtMTktDXSAoSVJRcyA1IDEwICoxMSkKQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAo
SVJRcyAqNSAxMCAxMSkKdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTowMDAwOjAwOjAyLjAsZGVj
b2Rlcz1pbyttZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQp2Z2FhcmI6IGxvYWRlZAp2Z2FhcmI6
IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDA6MDIuMApTQ1NJIHN1YnN5c3RlbSBpbml0
aWFsaXplZApsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4KdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcwp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIGh1Ygp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpQ
Q0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nClBDSTogb2xkIGNvZGUgd291bGQgaGF2ZSBz
ZXQgY2FjaGVsaW5lIHNpemUgdG8gMzIgYnl0ZXMsIGJ1dCBjbGZsdXNoX3NpemUgPSA2NApQQ0k6
IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzCk5ldExhYmVsOiBJbml0aWFsaXpp
bmcKTmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4Ck5ldExhYmVsOiAgcHJvdG9jb2xz
ID0gVU5MQUJFTEVEIENJUFNPdjQKTmV0TGFiZWw6ICB1bmxhYmVsZWQgdHJhZmZpYyBhbGxvd2Vk
IGJ5IGRlZmF1bHQKaHBldDA6IGF0IE1NSU8gMHhmZWQwMDAwMCwgSVJRcyAyLCA4LCAwCmhwZXQw
OiAzIGNvbXBhcmF0b3JzLCA2NC1iaXQgNjIuNTAwMDAwIE1IeiBjb3VudGVyClN3aXRjaGluZyB0
byBjbG9ja3NvdXJjZSB0c2MKcG5wOiBQblAgQUNQSSBpbml0CkFDUEk6IGJ1cyB0eXBlIHBucCBy
ZWdpc3RlcmVkCnBucDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMKQUNQSTogQUNQSSBidXMg
dHlwZSBwbnAgdW5yZWdpc3RlcmVkCnN5c3RlbSAwMDowMDogaW9tZW0gcmFuZ2UgMHgwLTB4OWZm
ZmYgY291bGQgbm90IGJlIHJlc2VydmVkCnN5c3RlbSAwMDowMzogaW9wb3J0IHJhbmdlIDB4OGEw
LTB4OGEzIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowMzogaW9wb3J0IHJhbmdlIDB4Y2Mw
LTB4Y2NmIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowMzogaW9wb3J0IHJhbmdlIDB4NGQw
LTB4NGQxIGhhcyBiZWVuIHJlc2VydmVkCnN5c3RlbSAwMDowYzogaW9wb3J0IHJhbmdlIDB4MTBj
MC0weDExNDEgaGFzIGJlZW4gcmVzZXJ2ZWQKc3lzdGVtIDAwOjBjOiBpb3BvcnQgcmFuZ2UgMHhi
MDQ0LTB4YjA0NyBoYXMgYmVlbiByZXNlcnZlZApwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDAg
aW86ICBbMHgwMC0weGZmZmZdCnBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgMSBtZW06IFsweDAw
MDAwMC0weGZmZmZmZmZmZmZmZmZmZmZdCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkg
MgpJUCByb3V0ZSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNywgNTI0
Mjg4IGJ5dGVzKQpUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9y
ZGVyOiAxMCwgNDE5NDMwNCBieXRlcykKVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUz
NiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpClRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAo
ZXN0YWJsaXNoZWQgMjYyMTQ0IGJpbmQgNjU1MzYpClRDUCByZW5vIHJlZ2lzdGVyZWQKTkVUOiBS
ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxCnBjaSAwMDAwOjAwOjAwLjA6IExpbWl0aW5nIGRp
cmVjdCBQQ0kvUENJIHRyYW5zZmVycwpwY2kgMDAwMDowMDowMS4wOiBQSUlYMzogRW5hYmxpbmcg
UGFzc2l2ZSBSZWxlYXNlCnBjaSAwMDAwOjAwOjAxLjA6IEFjdGl2YXRpbmcgSVNBIERNQSBoYW5n
IHdvcmthcm91bmRzCnBjaSAwMDAwOjAwOjAyLjA6IEJvb3QgdmlkZW8gZGV2aWNlClRyeWluZyB0
byB1bnBhY2sgcm9vdGZzIGltYWdlIGFzIGluaXRyYW1mcy4uLgpGcmVlaW5nIGluaXRyZCBtZW1v
cnk6IDE1NTc4ayBmcmVlZAphdWRpdDogaW5pdGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNh
YmxlZCkKdHlwZT0yMDAwIGF1ZGl0KDEzMzQ1OTM4NDkuOTI2OjEpOiBpbml0aWFsaXplZApIdWdl
VExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpWRlM6
IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yCkRxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczog
NTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQptc2dtbmkgaGFzIGJlZW4gc2V0IHRvIDM5ODYKU0VM
aW51eDogIFJlZ2lzdGVyaW5nIG5ldGZpbHRlciBob29rcwphbGc6IE5vIHRlc3QgZm9yIHN0ZHJu
ZyAoa3JuZykKa3NpZ246IEluc3RhbGxpbmcgcHVibGljIGtleSBkYXRhCkxvYWRpbmcga2V5cmlu
ZwotIEFkZGVkIHB1YmxpYyBrZXkgNEJCMUU2M0QxOEI0MjY1OAotIFVzZXIgSUQ6IFJlZCBIYXQs
IEluYy4gKEtlcm5lbCBNb2R1bGUgR1BHIGtleSkKLSBBZGRlZCBwdWJsaWMga2V5IEQ0QTI2QzlD
Q0QwOUJFREEKLSBVc2VyIElEOiBSZWQgSGF0IEVudGVycHJpc2UgTGludXggRHJpdmVyIFVwZGF0
ZSBQcm9ncmFtIDxzZWNhbGVydEByZWRoYXQuY29tPgpCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMg
KGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUyKQppbyBzY2hlZHVsZXIg
bm9vcCByZWdpc3RlcmVkCmlvIHNjaGVkdWxlciBhbnRpY2lwYXRvcnkgcmVnaXN0ZXJlZAppbyBz
Y2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJlZAppbyBzY2hlZHVsZXIgY2ZxIHJlZ2lzdGVyZWQg
KGRlZmF1bHQpCnBjaV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUgdmVyc2lvbjogMC41
CnBjaWVocDogUENJIEV4cHJlc3MgSG90IFBsdWcgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjog
MC40CmFjcGlwaHA6IEFDUEkgSG90IFBsdWcgUENJIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246
IDAuNQphY3BpcGhwOiBTbG90IFswXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzFdIHJlZ2lz
dGVyZWQKYWNwaXBocDogU2xvdCBbMl0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFszXSByZWdp
c3RlcmVkCmFjcGlwaHA6IFNsb3QgWzRdIHJlZ2lzdGVyZWQKYWNwaXBocDogU2xvdCBbNV0gcmVn
aXN0ZXJlZAphY3BpcGhwOiBTbG90IFs2XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzddIHJl
Z2lzdGVyZWQKYWNwaXBocDogU2xvdCBbOF0gcmVnaXN0ZXJlZAphY3BpcGhwOiBTbG90IFs5XSBy
ZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzEwXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzEx
XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzEyXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3Qg
WzEzXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzE0XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNs
b3QgWzE1XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzE2XSByZWdpc3RlcmVkCmFjcGlwaHA6
IFNsb3QgWzE3XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzE4XSByZWdpc3RlcmVkCmFjcGlw
aHA6IFNsb3QgWzE5XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzIwXSByZWdpc3RlcmVkCmFj
cGlwaHA6IFNsb3QgWzIxXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzIyXSByZWdpc3RlcmVk
CmFjcGlwaHA6IFNsb3QgWzIzXSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI0XSByZWdpc3Rl
cmVkCmFjcGlwaHA6IFNsb3QgWzI1XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI2XSByZWdp
c3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI3XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI4XSBy
ZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzI5XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzMw
XSByZWdpc3RlcmVkCmFjcGlwaHA6IFNsb3QgWzMxXSByZWdpc3RlcmVkCmlucHV0OiBQb3dlciBC
dXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQwCkFD
UEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KaW5wdXQ6IFNsZWVwIEJ1dHRvbiBhcyAvZGV2aWNlcy9M
TlhTWVNUTTowMC9MTlhTTFBCTjowMC9pbnB1dC9pbnB1dDEKQUNQSTogU2xlZXAgQnV0dG9uIFtT
TFBGXQpBQ1BJOiBhY3BpX2lkbGUgcmVnaXN0ZXJlZCB3aXRoIGNwdWlkbGUKcHJvY2Vzc29yIExO
WENQVTowMDogcmVnaXN0ZXJlZCBhcyBjb29saW5nX2RldmljZTAKcHJvY2Vzc29yIExOWENQVTow
MTogcmVnaXN0ZXJlZCBhcyBjb29saW5nX2RldmljZTEKcHJvY2Vzc29yIExOWENQVTowMjogcmVn
aXN0ZXJlZCBhcyBjb29saW5nX2RldmljZTIKcHJvY2Vzc29yIExOWENQVTowMzogcmVnaXN0ZXJl
ZCBhcyBjb29saW5nX2RldmljZTMKRVJTVDogVGFibGUgaXMgbm90IGZvdW5kIQpHSEVTOiBIRVNU
IGlzIG5vdCBlbmFibGVkIQogIGFsbG9jIGlycV9kZXNjIGZvciAyOCBvbiBub2RlIC0xCiAgYWxs
b2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCnhlbi1wbGF0Zm9ybS1wY2kgMDAwMDowMDowMy4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDI4IChsZXZlbCwgbG93KSAtPiBJUlEgMjgKR3JhbnQgdGFibGUgaW5p
dGlhbGl6ZWQKTm9uLXZvbGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwpMaW51eCBhZ3BnYXJ0IGlu
dGVyZmFjZSB2MC4xMDMKY3Jhc2ggbWVtb3J5IGRyaXZlcjogdmVyc2lvbiAxLjEKU2VyaWFsOiA4
MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZApzZXJpYWw4MjUw
OiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBCjAwOjBhOiB0dHlTMCBh
dCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBCmJyZDogbW9kdWxlIGxvYWRlZApsb29w
OiBtb2R1bGUgbG9hZGVkCmlucHV0OiBNYWNpbnRvc2ggbW91c2UgYnV0dG9uIGVtdWxhdGlvbiBh
cyAvZGV2aWNlcy92aXJ0dWFsL2lucHV0L2lucHV0MgpGaXhlZCBNRElPIEJ1czogcHJvYmVkCmVo
Y2lfaGNkOiBVU0IgMi4wICdFbmhhbmNlZCcgSG9zdCBDb250cm9sbGVyIChFSENJKSBEcml2ZXIK
b2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyCnVo
Y2lfaGNkOiBVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlciBJbnRlcmZhY2UgZHJpdmVyClBO
UDogUFMvMiBDb250cm9sbGVyIFtQTlAwMzAzOlBTMkssUE5QMGYxMzpQUzJNXSBhdCAweDYwLDB4
NjQgaXJxIDEsMTIKc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQpzZXJp
bzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgptaWNlOiBQUy8yIG1vdXNlIGRl
dmljZSBjb21tb24gZm9yIGFsbCBtaWNlCnJ0Y19jbW9zIDAwOjA1OiBydGMgY29yZTogcmVnaXN0
ZXJlZCBydGNfY21vcyBhcyBydGMwCnJ0YzA6IGFsYXJtcyB1cCB0byBvbmUgZGF5LCAxMTQgYnl0
ZXMgbnZyYW0sIGhwZXQgaXJxcwpjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBsYWRkZXIKY3B1aWRs
ZTogdXNpbmcgZ292ZXJub3IgbWVudQppbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBrZXlib2Fy
ZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5wdXQvaW5wdXQzCnVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaGlkZGV2CnVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkCnVzYmhpZDogdjIuNjpVU0IgSElEIGNvcmUg
ZHJpdmVyClRDUCBjdWJpYyByZWdpc3RlcmVkCkluaXRpYWxpemluZyBYRlJNIG5ldGxpbmsgc29j
a2V0Ck5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKcmVnaXN0ZXJlZCB0YXNrc3Rh
dHMgdmVyc2lvbiAxClhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmJkLzc2
OApYRU5CVVM6IERldmljZSB3aXRoIG5vIGRyaXZlcjogZGV2aWNlL3ZpZi8wClhFTkJVUzogRGV2
aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmtiZC8wClhFTkJVUzogRGV2aWNlIHdpdGggbm8g
ZHJpdmVyOiBkZXZpY2UvcGNpLzAKcnRjX2Ntb3MgMDA6MDU6IHNldHRpbmcgc3lzdGVtIGNsb2Nr
IHRvIDIwMTItMDQtMTYgMTY6MzA6NTEgVVRDICgxMzM0NTkzODUxKQpJbml0YWxpemluZyBuZXR3
b3JrIGRyb3AgbW9uaXRvciBzZXJ2aWNlCkZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEy
NDRrIGZyZWVkCldyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogMTAy
NDBrCkZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDEwNDBrIGZyZWVkCkZyZWVpbmcgdW51
c2VkIGtlcm5lbCBtZW1vcnk6IDE3NjBrIGZyZWVkCmRyYWN1dDogZHJhY3V0LTAwNC0yNTYuZWw2
CmRyYWN1dDogcmRfTk9fTFVLUzogcmVtb3ZpbmcgY3J5cHRvbHVrcyBhY3RpdmF0aW9uCmRyYWN1
dDogcmRfTk9fTFZNOiByZW1vdmluZyBMVk0gYWN0aXZhdGlvbgpkZXZpY2UtbWFwcGVyOiB1ZXZl
bnQ6IHZlcnNpb24gMS4wLjMKZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjIuNi1pb2N0bCAoMjAx
MS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KdWRldjogc3RhcnRpbmcg
dmVyc2lvbiAxNDcKZHJhY3V0OiBTdGFydGluZyBwbHltb3V0aCBkYWVtb24KaW5wdXQ6IEltRXhQ
Uy8yIEdlbmVyaWMgRXhwbG9yZXIgTW91c2UgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2Vy
aW8xL2lucHV0L2lucHV0NApkcmFjdXQ6IHJkX05PX0RNOiByZW1vdmluZyBETSBSQUlEIGFjdGl2
YXRpb24KZHJhY3V0OiByZF9OT19NRDogcmVtb3ZpbmcgTUQgUkFJRCBhY3RpdmF0aW9uCmF0YV9w
aWl4IDAwMDA6MDA6MDEuMTogdmVyc2lvbiAyLjEzCmF0YV9waWl4IDAwMDA6MDA6MDEuMTogc2V0
dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0CnNjc2kwIDogYXRhX3BpaXgKc2NzaTEgOiBhdGFfcGlp
eAphdGExOiBQQVRBIG1heCBNV0RNQTIgY21kIDB4MWYwIGN0bCAweDNmNiBibWRtYSAweGMzMDAg
aXJxIDE0CmF0YTI6IFBBVEEgbWF4IE1XRE1BMiBjbWQgMHgxNzAgY3RsIDB4Mzc2IGJtZG1hIDB4
YzMwOCBpcnEgMTUKaXNjaTogSW50ZWwoUikgQzYwMCBTQVMgQ29udHJvbGxlciBEcml2ZXIgLSB2
ZXJzaW9uIDEuMC4wLXJoCmlzY2kgMDAwMDowMDowNS4wOiBkcml2ZXIgY29uZmlndXJlZCBmb3Ig
cmV2OiA1IHNpbGljb24KaXNjaSAwMDAwOjAwOjA1LjA6IGZpcm13YXJlOiByZXF1ZXN0aW5nIGlz
Y2kvaXNjaV9maXJtd2FyZS5iaW4KaXNjaSAwMDAwOjAwOjA1LjA6IE9FTSBTQVMgcGFyYW1ldGVy
cyAodmVyc2lvbjogMS4wKSBsb2FkZWQgKGZpcm13YXJlKQogIGFsbG9jIGlycV9kZXNjIGZvciAz
NiBvbiBub2RlIC0xCiAgYWxsb2Mga3N0YXRfaXJxcyBvbiBub2RlIC0xCmlzY2kgMDAwMDowMDow
NS4wOiBQQ0kgSU5UIEEgLT4gR1NJIDM2IChsZXZlbCwgbG93KSAtPiBJUlEgMzYKaXNjaSAwMDAw
OjAwOjA1LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApzY3NpMiA6IGlzY2kKICBhbGxv
YyBpcnFfZGVzYyBmb3IgNDggb24gbm9kZSAtMQogIGFsbG9jIGtzdGF0X2lycXMgb24gbm9kZSAt
MQppc2NpIDAwMDA6MDA6MDUuMDogaXJxIDQ4IGZvciBNU0kvTVNJLVgKICBhbGxvYyBpcnFfZGVz
YyBmb3IgNDkgb24gbm9kZSAtMQogIGFsbG9jIGtzdGF0X2lycXMgb24gbm9kZSAtMQppc2NpIDAw
MDA6MDA6MDUuMDogaXJxIDQ5IGZvciBNU0kvTVNJLVgKeGxibGtfaW5pdDogcmVnaXN0ZXJfYmxr
ZGV2IG1ham9yOiAyMDIgCiAgYWxsb2MgaXJxX2Rlc2MgZm9yIDE3IG9uIG5vZGUgMAogIGFsbG9j
IGtzdGF0X2lycXMgb24gbm9kZSAwCmJsa2Zyb250OiB4dmRhOiBiYXJyaWVycyBkaXNhYmxlZAog
eHZkYTogeHZkYTEgeHZkYTIKc2NzaSAyOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBTRUFHQVRF
ICBTVDkxNDY4MDJTUyAgICAgIDAwMDMgUFE6IDAgQU5TSTogNQpFWFQ0LWZzICh4dmRhMSk6IG1v
dW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiAKc2QgMjowOjA6
MDogW3NkYV0gMjg2NzQ5NDg4IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTQ2IEdCLzEzNiBH
aUIpCnNkIDI6MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmCnNkIDI6MDowOjA6IFtz
ZGFdIE1vZGUgU2Vuc2U6IGIzIDAwIDEwIDA4CnNkIDI6MDowOjA6IFtzZGFdIFdyaXRlIGNhY2hl
OiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBzdXBwb3J0cyBEUE8gYW5kIEZVQQogc2Rh
OiBzZGExIHNkYTIgc2RhMwpkcmFjdXQ6IE1vdW50ZWQgcm9vdCBmaWxlc3lzdGVtIC9kZXYveHZk
YTEKc2QgMjowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrClNFTGludXg6ICBEaXNhYmxl
ZCBhdCBydW50aW1lLgpTRUxpbnV4OiAgVW5yZWdpc3RlcmluZyBuZXRmaWx0ZXIgaG9va3MKdHlw
ZT0xNDA0IGF1ZGl0KDEzMzQ1OTM4NTIuODkwOjIpOiBzZWxpbnV4PTAgYXVpZD00Mjk0OTY3Mjk1
IHNlcz00Mjk0OTY3Mjk1CmRyYWN1dDogCmRyYWN1dDogU3dpdGNoaW5nIHJvb3QKcmVhZGFoZWFk
LWNvbGxlY3Rvcjogc3RhcnRpbmcKdWRldjogc3RhcnRpbmcgdmVyc2lvbiAxNDcKcGlpeDRfc21i
dXMgMDAwMDowMDowMS4zOiBTTUJ1cyBiYXNlIGFkZHJlc3MgdW5pbml0aWFsaXplZCAtIHVwZ3Jh
ZGUgQklPUyBvciB1c2UgZm9yY2VfYWRkcj0weGFkZHIKSW5pdGlhbGlzaW5nIFhlbiB2aXJ0dWFs
IGV0aGVybmV0IGRyaXZlci4KICBhbGxvYyBpcnFfZGVzYyBmb3IgMTggb24gbm9kZSAwCiAgYWxs
b2Mga3N0YXRfaXJxcyBvbiBub2RlIDAKbWljcm9jb2RlOiBDUFUwIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKbWljcm9jb2RlOiBDUFUxIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKbWljcm9jb2RlOiBDUFUyIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKbWljcm9jb2RlOiBDUFUzIHNpZz0weDIwNmQ2LCBwZj0w
eDEsIHJldmlzaW9uPTB4NjEzCnBsYXRmb3JtIG1pY3JvY29kZTogZmlybXdhcmU6IHJlcXVlc3Rp
bmcgaW50ZWwtdWNvZGUvMDYtMmQtMDYKTWljcm9jb2RlIFVwZGF0ZSBEcml2ZXI6IHYyLjAwIDx0
aWdyYW5AYWl2YXppYW4uZnNuZXQuY28udWs+LCBQZXRlciBPcnViYQpzZCAyOjA6MDowOiBBdHRh
Y2hlZCBzY3NpIGdlbmVyaWMgc2cwIHR5cGUgMApwYXJwb3J0X3BjIDAwOjBiOiByZXBvcnRlZCBi
eSBQbHVnIGFuZCBQbGF5IEFDUEkKcGFycG9ydDA6IFBDLXN0eWxlIGF0IDB4Mzc4LCBpcnEgNyBb
UENTUFAsVFJJU1RBVEVdCnBwZGV2OiB1c2VyLXNwYWNlIHBhcmFsbGVsIHBvcnQgZHJpdmVyCnR1
bjogVW5pdmVyc2FsIFRVTi9UQVAgZGV2aWNlIGRyaXZlciwgMS42CnR1bjogKEMpIDE5OTktMjAw
NCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPgpBZGRpbmcgNTExOTkyayBzd2Fw
IG9uIC9kZXYveHZkYTIuICBQcmlvcml0eTotMSBleHRlbnRzOjEgYWNyb3NzOjUxMTk5MmsgU1MK
cmVhZGFoZWFkLWRpc2FibGUtc2VydmljZTogZGVsYXlpbmcgc2VydmljZSBhdWRpdGQKTkVUOiBS
ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMApsbzogRGlzYWJsZWQgUHJpdmFjeSBFeHRlbnNp
b25zClJQQzogUmVnaXN0ZXJlZCB1ZHAgdHJhbnNwb3J0IG1vZHVsZS4KUlBDOiBSZWdpc3RlcmVk
IHRjcCB0cmFuc3BvcnQgbW9kdWxlLgpSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2No
YW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4KQnJpZGdlIGZpcmV3YWxsaW5nIHJlZ2lzdGVyZWQKZGV2
aWNlIHZpcmJyMC1uaWMgZW50ZXJlZCBwcm9taXNjdW91cyBtb2RlCk5ldyBkZXZpY2UgdmlyYnIw
LW5pYyBkb2VzIG5vdCBzdXBwb3J0IG5ldHBvbGwKRGlzYWJsaW5nIG5ldHBvbGwgZm9yIHZpcmJy
MAp2aXJicjA6IHN0YXJ0aW5nIHVzZXJzcGFjZSBTVFAgZmFpbGVkLCBzdGFydGluZyBrZXJuZWwg
U1RQCmlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCm5mX2Nvbm50
cmFjayB2ZXJzaW9uIDAuNS4wICgxNjM4NCBidWNrZXRzLCA2NTUzNiBtYXgpCkVidGFibGVzIHYy
LjAgcmVnaXN0ZXJlZAppcDZfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBDb3JlIFRl
YW0KbG86IERpc2FibGVkIFByaXZhY3kgRXh0ZW5zaW9ucwpldGgwOiBubyBJUHY2IHJvdXRlcnMg
cHJlc2VudAp0eXBlPTEzMDUgYXVkaXQoMTMzNDU5Mzg4MC4zNjg6MjgxNDgpOiBhdWlkPTQyOTQ5
NjcyOTUgc2VzPTQyOTQ5NjcyOTUgb3A9InJlbW92ZSBydWxlIiBrZXk9KG51bGwpIGxpc3Q9NCBy
ZXM9MQp0eXBlPTEzMDUgYXVkaXQoMTMzNDU5Mzg4MC4zNjg6MjgxNDkpOiBhdWRpdF9lbmFibGVk
PTAgb2xkPTEgYXVpZD00Mjk0OTY3Mjk1IHNlcz00Mjk0OTY3Mjk1IHJlcz0xCnJlYWRhaGVhZC1j
b2xsZWN0b3I6IHN0YXJ0aW5nIGRlbGF5ZWQgc2VydmljZSBhdWRpdGQKcmVhZGFoZWFkLWNvbGxl
Y3Rvcjogc29ydGluZwpyZWFkYWhlYWQtY29sbGVjdG9yOiBmaW5pc2hlZApwc21vdXNlLmM6IEV4
cGxvcmVyIE1vdXNlIGF0IGlzYTAwNjAvc2VyaW8xL2lucHV0MCBsb3N0IHN5bmNocm9uaXphdGlv
biwgdGhyb3dpbmcgMSBieXRlcyBhd2F5Lgpwc21vdXNlLmM6IHJlc3luYyBmYWlsZWQsIGlzc3Vp
bmcgcmVjb25uZWN0IHJlcXVlc3QKaW5wdXQ6IEltRXhQUy8yIEdlbmVyaWMgRXhwbG9yZXIgTW91
c2UgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2VyaW8xL2lucHV0L2lucHV0NQppbnB1dDog
SW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3VzZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0
Mi9zZXJpbzEvaW5wdXQvaW5wdXQ2CnBzbW91c2UuYzogRXhwbG9yZXIgTW91c2UgYXQgaXNhMDA2
MC9zZXJpbzEvaW5wdXQwIGxvc3Qgc3luY2hyb25pemF0aW9uLCB0aHJvd2luZyAzIGJ5dGVzIGF3
YXkuCnBzbW91c2UuYzogcmVzeW5jIGZhaWxlZCwgaXNzdWluZyByZWNvbm5lY3QgcmVxdWVzdAo=

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: application/octet-stream; name="guest_lspci"
Content-Description: guest_lspci
Content-Disposition: attachment; filename="guest_lspci"; size=2055;
	creation-date="Mon, 16 Apr 2012 08:53:23 GMT";
	modification-date="Mon, 16 Apr 2012 01:55:42 GMT"
Content-Transfer-Encoding: base64

MDA6MDUuMCBTZXJpYWwgQXR0YWNoZWQgU0NTSSBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlv
biBQYXRzYnVyZyA0LVBvcnQgU0FUQS9TQVMgU3RvcmFnZSBDb250cm9sIFVuaXQgKHJldiAwNSkK
CVN1YnN5c3RlbTogSW50ZWwgQ29ycG9yYXRpb24gRGV2aWNlIDM1ODUKCVBoeXNpY2FsIFNsb3Q6
IDUKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6
IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8
VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiA2NAoJSW50ZXJy
dXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDM2CglSZWdpb24gMDogTWVtb3J5IGF0IGYzNDAwMDAw
ICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZLXQoJUmVnaW9uIDI6IE1lbW9yeSBhdCBm
MzAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRNXQoJUmVnaW9uIDQ6IEkvTyBw
b3J0cyBhdCBjMjAwIFtzaXplPTI1Nl0KCUNhcGFiaWxpdGllczogWzk4XSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBt
QSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3Qr
IFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFtjNF0gRXhw
cmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTAyNCBieXRl
cywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkCgkJCUV4
dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglS
ZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQt
CgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0KCQlMbmtD
YXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5j
eSBMMCA8NjRucywgTDEgPDF1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90
LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWlu
LSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJ
bnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENvbXBsZXRpb24gVGlt
ZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcy0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRp
bWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBT
cGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNl
IERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSS1YOiBFbmFibGUrIENvdW50PTIgTWFza2VkLQoJ
CVZlY3RvciB0YWJsZTogQkFSPTAgb2Zmc2V0PTAwMDAyMDAwCgkJUEJBOiBCQVI9MCBvZmZzZXQ9
MDAwMDMwMDAKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBpc2NpCglLZXJuZWwgbW9kdWxlczogaXNj
aQoK

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_006_403610A45A2B5242BD291EDAE8B37D300FD11C89SHSMSX102ccrcor_--


From xen-devel-bounces@lists.xen.org Mon Apr 16 09:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:08:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhvA-00086G-7r; Mon, 16 Apr 2012 09:08:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1SJhv8-00086B-GZ
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 09:08:27 +0000
Received: from [85.158.138.51:2168] by server-12.bemta-3.messagelabs.com id
	13/91-29760-981EB8F4; Mon, 16 Apr 2012 09:08:25 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334567304!22332142!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8756 invoked from network); 16 Apr 2012 09:08:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	16 Apr 2012 09:08:24 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3G98HIc008351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 05:08:18 -0400
Received: from rincewind.home.kraxel.org (ovpn-116-46.ams2.redhat.com
	[10.36.116.46])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3G8Hbnb013528; Mon, 16 Apr 2012 04:17:38 -0400
Message-ID: <4F8BD5A1.8080101@redhat.com>
Date: Mon, 16 Apr 2012 10:17:37 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120307 Thunderbird/10.0.3
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1334151739-10484-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1334151739-10484-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.4
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: kwolf@redhat.com, anthony.perard@citrix.com, aliguori@us.ibm.com,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH] xen: handle backend deletion from xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/12 15:42, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  hw/xen_backend.c |   17 +++++++++--------
>  hw/xen_disk.c    |    4 ++++
>  2 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/xen_backend.c b/hw/xen_backend.c
> index d876cab..555da41 100644
> --- a/hw/xen_backend.c
> +++ b/hw/xen_backend.c
> @@ -589,7 +589,7 @@ static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
>      struct XenDevice *xendev;
> -    char path[XEN_BUFSIZE], *dom0;
> +    char path[XEN_BUFSIZE], *dom0, *bepath;
>      unsigned int len, dev;
>  
>      dom0 = xs_get_domain_path(xenstore, 0);
> @@ -608,15 +608,16 @@ static void xenstore_update_be(char *watch, char *type, int dom,
>          return;
>      }
>  
> -    if (0) {
> -        /* FIXME: detect devices being deleted from xenstore ... */
> -        xen_be_del_xendev(dom, dev);
> -    }
> -
>      xendev = xen_be_get_xendev(type, dom, dev, ops);
>      if (xendev != NULL) {
> -        xen_be_backend_changed(xendev, path);
> -        xen_be_check_state(xendev);
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +            xen_be_check_state(xendev);
> +        }
>      }
>  }
>  
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index e9bbbf7..8217109 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -824,6 +824,10 @@ static int blk_free(struct XenDevice *xendev)
>      struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
>      struct ioreq *ioreq;
>  
> +    if (blkdev->bs || blkdev->sring) {
> +        blk_disconnect(xendev);
> +    }
> +
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq = QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 09:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:08:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhvA-00086G-7r; Mon, 16 Apr 2012 09:08:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1SJhv8-00086B-GZ
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 09:08:27 +0000
Received: from [85.158.138.51:2168] by server-12.bemta-3.messagelabs.com id
	13/91-29760-981EB8F4; Mon, 16 Apr 2012 09:08:25 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334567304!22332142!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8756 invoked from network); 16 Apr 2012 09:08:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	16 Apr 2012 09:08:24 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3G98HIc008351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 05:08:18 -0400
Received: from rincewind.home.kraxel.org (ovpn-116-46.ams2.redhat.com
	[10.36.116.46])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3G8Hbnb013528; Mon, 16 Apr 2012 04:17:38 -0400
Message-ID: <4F8BD5A1.8080101@redhat.com>
Date: Mon, 16 Apr 2012 10:17:37 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120307 Thunderbird/10.0.3
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1334151739-10484-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1334151739-10484-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.4
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: kwolf@redhat.com, anthony.perard@citrix.com, aliguori@us.ibm.com,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH] xen: handle backend deletion from xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/11/12 15:42, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  hw/xen_backend.c |   17 +++++++++--------
>  hw/xen_disk.c    |    4 ++++
>  2 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/xen_backend.c b/hw/xen_backend.c
> index d876cab..555da41 100644
> --- a/hw/xen_backend.c
> +++ b/hw/xen_backend.c
> @@ -589,7 +589,7 @@ static void xenstore_update_be(char *watch, char *type, int dom,
>                                 struct XenDevOps *ops)
>  {
>      struct XenDevice *xendev;
> -    char path[XEN_BUFSIZE], *dom0;
> +    char path[XEN_BUFSIZE], *dom0, *bepath;
>      unsigned int len, dev;
>  
>      dom0 = xs_get_domain_path(xenstore, 0);
> @@ -608,15 +608,16 @@ static void xenstore_update_be(char *watch, char *type, int dom,
>          return;
>      }
>  
> -    if (0) {
> -        /* FIXME: detect devices being deleted from xenstore ... */
> -        xen_be_del_xendev(dom, dev);
> -    }
> -
>      xendev = xen_be_get_xendev(type, dom, dev, ops);
>      if (xendev != NULL) {
> -        xen_be_backend_changed(xendev, path);
> -        xen_be_check_state(xendev);
> +        bepath = xs_read(xenstore, 0, xendev->be, &len);
> +        if (bepath == NULL) {
> +            xen_be_del_xendev(dom, dev);
> +        } else {
> +            free(bepath);
> +            xen_be_backend_changed(xendev, path);
> +            xen_be_check_state(xendev);
> +        }
>      }
>  }
>  
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index e9bbbf7..8217109 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -824,6 +824,10 @@ static int blk_free(struct XenDevice *xendev)
>      struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
>      struct ioreq *ioreq;
>  
> +    if (blkdev->bs || blkdev->sring) {
> +        blk_disconnect(xendev);
> +    }
> +
>      while (!QLIST_EMPTY(&blkdev->freelist)) {
>          ioreq = QLIST_FIRST(&blkdev->freelist);
>          QLIST_REMOVE(ioreq, list);

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 09:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhvr-00088h-LZ; Mon, 16 Apr 2012 09:09:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJhvq-00088L-AC
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 09:09:10 +0000
Received: from [85.158.139.83:34051] by server-8.bemta-5.messagelabs.com id
	6A/79-26964-5B1EB8F4; Mon, 16 Apr 2012 09:09:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334567348!12703835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3460 invoked from network); 16 Apr 2012 09:09:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 09:09:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11949052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:09:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:09:08 +0100
Message-ID: <1334567346.14560.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 10:09:06 +0100
In-Reply-To: <1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> We may need to #include <libutil.h>, and/or link with -lutil, to use
> openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
> (preprocessor constant, not always defined) and PTYFUNCS_LIBS
> (makefile variable).
> 
> We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
> than UTIL_LIBS, and #include <libutil.h> where appropriate.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  config/Tools.mk.in             |    2 +
>  tools/configure                |   51 ++++++++++++++++++++++++++++++++++++++++
>  tools/configure.ac             |    2 +
>  tools/libxl/Makefile           |    2 +-
>  tools/libxl/libxl_bootloader.c |    4 +++
>  tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
>  6 files changed, 84 insertions(+), 1 deletions(-)
>  create mode 100644 tools/m4/ptyfuncs.m4
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index e5ea867..5ba144f 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
>  endif
>  
>  LIBXL_LIBS =
> -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
> +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)

Did you intend to remove the definition of UTIL_LIBS? I don't see a hunk
which does that.

> diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
> new file mode 100644
> index 0000000..2846a6d
> --- /dev/null
> +++ b/tools/m4/ptyfuncs.m4
> @@ -0,0 +1,24 @@
> +AC_DEFUN([AX_CHECK_PTYFUNCS], [
> +    AC_CHECK_HEADER([libutil.h],[
> +      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
> +    ])
> +    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
> +        ax_cv_ptyfuncs_libs=-lutil
> +        AX_SAVEVAR_SAVE(LIBS)
> +        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> +        AC_LINK_IFELSE([
> +#ifdef INCLUDE_LIBUTIL_H
> +#include INCLUDE_LIBUTIL_H
> +#endif
> +int main(void) {
> +  openpty(0,0,0,0,0);
> +  login_tty(0);
> +}
> +])
> +        AX_SAVEVAR_RESTORE(LIBS)],
> +    [],[
> +        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
> +    ])
> +    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
> +    AC_SUBST(PTYFUNCS_LIBS)
> +])

Does this fail if -lutil isn't available? My (perhaps mistaken) reading
of the commit message was that -lutil was only needed on some platforms?

On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
configure output -- so maybe I just understand what all these macros are
actually doing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 09:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJhvr-00088h-LZ; Mon, 16 Apr 2012 09:09:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJhvq-00088L-AC
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 09:09:10 +0000
Received: from [85.158.139.83:34051] by server-8.bemta-5.messagelabs.com id
	6A/79-26964-5B1EB8F4; Mon, 16 Apr 2012 09:09:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334567348!12703835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3460 invoked from network); 16 Apr 2012 09:09:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 09:09:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11949052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:09:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:09:08 +0100
Message-ID: <1334567346.14560.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 10:09:06 +0100
In-Reply-To: <1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> We may need to #include <libutil.h>, and/or link with -lutil, to use
> openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
> (preprocessor constant, not always defined) and PTYFUNCS_LIBS
> (makefile variable).
> 
> We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
> than UTIL_LIBS, and #include <libutil.h> where appropriate.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  config/Tools.mk.in             |    2 +
>  tools/configure                |   51 ++++++++++++++++++++++++++++++++++++++++
>  tools/configure.ac             |    2 +
>  tools/libxl/Makefile           |    2 +-
>  tools/libxl/libxl_bootloader.c |    4 +++
>  tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
>  6 files changed, 84 insertions(+), 1 deletions(-)
>  create mode 100644 tools/m4/ptyfuncs.m4
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index e5ea867..5ba144f 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
>  endif
>  
>  LIBXL_LIBS =
> -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
> +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)

Did you intend to remove the definition of UTIL_LIBS? I don't see a hunk
which does that.

> diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
> new file mode 100644
> index 0000000..2846a6d
> --- /dev/null
> +++ b/tools/m4/ptyfuncs.m4
> @@ -0,0 +1,24 @@
> +AC_DEFUN([AX_CHECK_PTYFUNCS], [
> +    AC_CHECK_HEADER([libutil.h],[
> +      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
> +    ])
> +    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
> +        ax_cv_ptyfuncs_libs=-lutil
> +        AX_SAVEVAR_SAVE(LIBS)
> +        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> +        AC_LINK_IFELSE([
> +#ifdef INCLUDE_LIBUTIL_H
> +#include INCLUDE_LIBUTIL_H
> +#endif
> +int main(void) {
> +  openpty(0,0,0,0,0);
> +  login_tty(0);
> +}
> +])
> +        AX_SAVEVAR_RESTORE(LIBS)],
> +    [],[
> +        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
> +    ])
> +    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
> +    AC_SUBST(PTYFUNCS_LIBS)
> +])

Does this fail if -lutil isn't available? My (perhaps mistaken) reading
of the commit message was that -lutil was only needed on some platforms?

On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
configure output -- so maybe I just understand what all these macros are
actually doing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 09:24:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:24:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJiAM-0008Os-4c; Mon, 16 Apr 2012 09:24:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJiAK-0008Ok-VX
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 09:24:09 +0000
Received: from [85.158.139.83:53453] by server-11.bemta-5.messagelabs.com id
	1E/F5-12959-835EB8F4; Mon, 16 Apr 2012 09:24:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334568247!20028693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10202 invoked from network); 16 Apr 2012 09:24:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 09:24:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11949512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:24:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:24:06 +0100
Message-ID: <1334568245.14560.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 10:24:05 +0100
In-Reply-To: <1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> +int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
> +{
> +    int rc = 0;
> +    DIR *d = 0;
> +
> +    d = opendir(dirpath);
> +    if (!d) {
> +        if (errno == ENOENT)
> +            goto out;
> +
> +        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    size_t need = offsetof(struct dirent, d_name) +
> +        pathconf(dirpath, _PC_NAME_MAX) + 1;

This was an interesting pattern, but I see that readdir(3) recommends
portable programs do things this way...

> +    struct dirent *de_buf = libxl__zalloc(gc, need);
> +    struct dirent *de;
> +
> +    for (;;) {
> +        int r = readdir_r(d, de_buf, &de);
> +        if (r) {
> +            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
> +            rc = ERROR_FAIL;
> +            break;
> +        }
> +        if (!de)
> +            break;
> +
> +        if (!strcmp(de->d_name, ".") ||
> +            !strcmp(de->d_name, ".."))
> +            continue;
> +
> +        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
> +        if (libxl__remove_file_or_directory(gc, subpath))
> +            rc = ERROR_FAIL;

Deliberately doesn't "goto out" so as to remove as much as possible?

If so then:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> +    }
> +
> +    for (;;) {
> +        int r = rmdir(dirpath);
> +        if (!r) break;
> +        if (errno == ENOENT) goto out;
> +        if (errno == EINTR) continue;
> +        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
> +        rc = ERROR_FAIL;
> +    }
> +
> + out:
> +    if (d) closedir(d);
> +
> +    return rc;
> +}
>  
>  pid_t libxl_fork(libxl_ctx *ctx)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 09:24:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:24:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJiAM-0008Os-4c; Mon, 16 Apr 2012 09:24:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJiAK-0008Ok-VX
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 09:24:09 +0000
Received: from [85.158.139.83:53453] by server-11.bemta-5.messagelabs.com id
	1E/F5-12959-835EB8F4; Mon, 16 Apr 2012 09:24:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334568247!20028693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10202 invoked from network); 16 Apr 2012 09:24:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 09:24:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11949512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:24:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:24:06 +0100
Message-ID: <1334568245.14560.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 10:24:05 +0100
In-Reply-To: <1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> +int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
> +{
> +    int rc = 0;
> +    DIR *d = 0;
> +
> +    d = opendir(dirpath);
> +    if (!d) {
> +        if (errno == ENOENT)
> +            goto out;
> +
> +        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    size_t need = offsetof(struct dirent, d_name) +
> +        pathconf(dirpath, _PC_NAME_MAX) + 1;

This was an interesting pattern, but I see that readdir(3) recommends
portable programs do things this way...

> +    struct dirent *de_buf = libxl__zalloc(gc, need);
> +    struct dirent *de;
> +
> +    for (;;) {
> +        int r = readdir_r(d, de_buf, &de);
> +        if (r) {
> +            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
> +            rc = ERROR_FAIL;
> +            break;
> +        }
> +        if (!de)
> +            break;
> +
> +        if (!strcmp(de->d_name, ".") ||
> +            !strcmp(de->d_name, ".."))
> +            continue;
> +
> +        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
> +        if (libxl__remove_file_or_directory(gc, subpath))
> +            rc = ERROR_FAIL;

Deliberately doesn't "goto out" so as to remove as much as possible?

If so then:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> +    }
> +
> +    for (;;) {
> +        int r = rmdir(dirpath);
> +        if (!r) break;
> +        if (errno == ENOENT) goto out;
> +        if (errno == EINTR) continue;
> +        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
> +        rc = ERROR_FAIL;
> +    }
> +
> + out:
> +    if (d) closedir(d);
> +
> +    return rc;
> +}
>  
>  pid_t libxl_fork(libxl_ctx *ctx)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 09:58:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJigq-0000AS-JW; Mon, 16 Apr 2012 09:57:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJigo-0000A9-DC
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 09:57:42 +0000
Received: from [85.158.143.99:8400] by server-3.bemta-4.messagelabs.com id
	29/DF-05853-51DEB8F4; Mon, 16 Apr 2012 09:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334570259!17437425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25866 invoked from network); 16 Apr 2012 09:57:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 09:57:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11950466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:57:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:57:38 +0100
Message-ID: <1334570256.14560.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Todd Deshane <todd.deshane@xen.org>
Date: Mon, 16 Apr 2012 10:57:36 +0100
In-Reply-To: <CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
	<CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Lloyd Dizon <thecarrionkind@gmail.com>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Remi Gacogne <rgacogne-xen@valombre.net>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 18:22 +0100, Todd Deshane wrote:
> Adding Xen-devel.
> 
> What are the current timekeeping best practices now?

pvops kernels behave as if independent_wallclock == 1, so the existing
advice:
        set /proc/sys/xen/independent_wallclock to 1 and run ntp on
        domU. 
still applies.

Ian.

> 
> Thanks,
> Todd
> 
> ---------- Forwarded message ----------
> From: Remi Gacogne <rgacogne-xen@valombre.net>
> Date: Fri, Apr 13, 2012 at 12:31 PM
> Subject: Re: [Xen-users] Xen timekeeping best practices
> To: Todd Deshane <todd.deshane@xen.org>
> Cc: Lloyd Dizon <thecarrionkind@gmail.com>, xen-users@lists.xen.org
> 
> 
> 
> > Does this help at all:
> > http://wiki.xensource.com/wiki/Xen_FAQ_DomU#How_can_i_synchronize_a_dom0_clock.3F
> 
> 
> Well, thank you but independent_wallclock doesn't exist anymore on
> pvops kernel, and the link to blogspot seems broken so, no, not very
> much :)
> 
> --
> 
> Regards,
> 
> Remi Gacogne
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 09:58:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 09:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJigq-0000AS-JW; Mon, 16 Apr 2012 09:57:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJigo-0000A9-DC
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 09:57:42 +0000
Received: from [85.158.143.99:8400] by server-3.bemta-4.messagelabs.com id
	29/DF-05853-51DEB8F4; Mon, 16 Apr 2012 09:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334570259!17437425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25866 invoked from network); 16 Apr 2012 09:57:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 09:57:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11950466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:57:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:57:38 +0100
Message-ID: <1334570256.14560.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Todd Deshane <todd.deshane@xen.org>
Date: Mon, 16 Apr 2012 10:57:36 +0100
In-Reply-To: <CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
	<CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Lloyd Dizon <thecarrionkind@gmail.com>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Remi Gacogne <rgacogne-xen@valombre.net>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 18:22 +0100, Todd Deshane wrote:
> Adding Xen-devel.
> 
> What are the current timekeeping best practices now?

pvops kernels behave as if independent_wallclock == 1, so the existing
advice:
        set /proc/sys/xen/independent_wallclock to 1 and run ntp on
        domU. 
still applies.

Ian.

> 
> Thanks,
> Todd
> 
> ---------- Forwarded message ----------
> From: Remi Gacogne <rgacogne-xen@valombre.net>
> Date: Fri, Apr 13, 2012 at 12:31 PM
> Subject: Re: [Xen-users] Xen timekeeping best practices
> To: Todd Deshane <todd.deshane@xen.org>
> Cc: Lloyd Dizon <thecarrionkind@gmail.com>, xen-users@lists.xen.org
> 
> 
> 
> > Does this help at all:
> > http://wiki.xensource.com/wiki/Xen_FAQ_DomU#How_can_i_synchronize_a_dom0_clock.3F
> 
> 
> Well, thank you but independent_wallclock doesn't exist anymore on
> pvops kernel, and the link to blogspot seems broken so, no, not very
> much :)
> 
> --
> 
> Regards,
> 
> Remi Gacogne
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:10:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJisZ-0000xM-Ha; Mon, 16 Apr 2012 10:09:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJisY-0000xF-8U
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:09:50 +0000
Received: from [193.109.254.147:61267] by server-4.bemta-14.messagelabs.com id
	08/2D-11570-DEFEB8F4; Mon, 16 Apr 2012 10:09:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334570987!1665338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5216 invoked from network); 16 Apr 2012 10:09:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330923600"; d="scan'208";a="190464380"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 06:09:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 06:09:47 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJisU-0005Ea-AP;
	Mon, 16 Apr 2012 11:09:46 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 11:09:48 +0100
Message-ID: <B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 13/04/2012, a las 19:39, Ian Jackson escribi=F3:
> We may need to #include <libutil.h>, and/or link with -lutil, to use
> openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
> (preprocessor constant, not always defined) and PTYFUNCS_LIBS
> (makefile variable).
> =

> We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
> than UTIL_LIBS, and #include <libutil.h> where appropriate.
> =

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
> config/Tools.mk.in             |    2 +
> tools/configure                |   51 +++++++++++++++++++++++++++++++++++=
+++++
> tools/configure.ac             |    2 +
> tools/libxl/Makefile           |    2 +-
> tools/libxl/libxl_bootloader.c |    4 +++
> tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
> 6 files changed, 84 insertions(+), 1 deletions(-)
> create mode 100644 tools/m4/ptyfuncs.m4
> =

> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloade=
r.c
> index 2774062..b50944a 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -16,6 +16,10 @@
> =

> #include <termios.h>
> =

> +#ifdef INCLUDE_LIBUTIL_H
> +#include INCLUDE_LIBUTIL_H
> +#endif
> +

Maybe I'm missing something, because this autoconf macros are hard to read,=
 but shouldn't you add something like

#undef INCLUDE_LIBUTIL_H

to tools/config.h.in, so the generated config.h contains this define?

> #include "libxl_internal.h"
> =

> #define XENCONSOLED_BUF_SIZE 16



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:10:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJisZ-0000xM-Ha; Mon, 16 Apr 2012 10:09:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJisY-0000xF-8U
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:09:50 +0000
Received: from [193.109.254.147:61267] by server-4.bemta-14.messagelabs.com id
	08/2D-11570-DEFEB8F4; Mon, 16 Apr 2012 10:09:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334570987!1665338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5216 invoked from network); 16 Apr 2012 10:09:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330923600"; d="scan'208";a="190464380"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 06:09:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 06:09:47 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJisU-0005Ea-AP;
	Mon, 16 Apr 2012 11:09:46 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 11:09:48 +0100
Message-ID: <B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 13/04/2012, a las 19:39, Ian Jackson escribi=F3:
> We may need to #include <libutil.h>, and/or link with -lutil, to use
> openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
> (preprocessor constant, not always defined) and PTYFUNCS_LIBS
> (makefile variable).
> =

> We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
> than UTIL_LIBS, and #include <libutil.h> where appropriate.
> =

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
> config/Tools.mk.in             |    2 +
> tools/configure                |   51 +++++++++++++++++++++++++++++++++++=
+++++
> tools/configure.ac             |    2 +
> tools/libxl/Makefile           |    2 +-
> tools/libxl/libxl_bootloader.c |    4 +++
> tools/m4/ptyfuncs.m4           |   24 ++++++++++++++++++
> 6 files changed, 84 insertions(+), 1 deletions(-)
> create mode 100644 tools/m4/ptyfuncs.m4
> =

> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloade=
r.c
> index 2774062..b50944a 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -16,6 +16,10 @@
> =

> #include <termios.h>
> =

> +#ifdef INCLUDE_LIBUTIL_H
> +#include INCLUDE_LIBUTIL_H
> +#endif
> +

Maybe I'm missing something, because this autoconf macros are hard to read,=
 but shouldn't you add something like

#undef INCLUDE_LIBUTIL_H

to tools/config.h.in, so the generated config.h contains this define?

> #include "libxl_internal.h"
> =

> #define XENCONSOLED_BUF_SIZE 16



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJiyy-0001A8-CO; Mon, 16 Apr 2012 10:16:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJiyx-0001A3-4n
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:16:27 +0000
Received: from [85.158.138.51:51015] by server-3.bemta-3.messagelabs.com id
	4E/4E-04048-A71FB8F4; Mon, 16 Apr 2012 10:16:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334571385!22279068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28376 invoked from network); 16 Apr 2012 10:16:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:16:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:16:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJiyu-0000a8-Uw; Mon, 16 Apr 2012 10:16:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJiyu-0002AR-Q7;
	Mon, 16 Apr 2012 11:16:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.61816.741962.128152@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:16:24 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <7bd96bdf-f7ab-450e-98e6-85fa273a5d28@default>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
	<20360.961.392060.587905@mariner.uk.xensource.com>
	<7bd96bdf-f7ab-450e-98e6-85fa273a5d28@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan Magenheimer writes ("RE: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
...
> > There are a few operations that make a function necessarily have to be
> > slow in the libxl api sense.  These are: xenstore watches; spawning
> > subprocesses; anything with a timeout.
> > 
> > More broadly any function which is sufficiently slow that a caller
> > might reasonably want to initiate it, and then carry on doing
> > something else while the function completes.  So this includes any
> > operation which a toolstack might want to parallelise.
> 
> Got it.  Thanks.  This is a bit clearer than the comment in libxl.h.

The internal-facing documentation, which is for people who might be
implementing libxl facilities and API designers, is in
libxl_internal.h.  But the comment there is less comprehensive.  I
will prepare a patch to update it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJiyy-0001A8-CO; Mon, 16 Apr 2012 10:16:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJiyx-0001A3-4n
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:16:27 +0000
Received: from [85.158.138.51:51015] by server-3.bemta-3.messagelabs.com id
	4E/4E-04048-A71FB8F4; Mon, 16 Apr 2012 10:16:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334571385!22279068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28376 invoked from network); 16 Apr 2012 10:16:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:16:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:16:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJiyu-0000a8-Uw; Mon, 16 Apr 2012 10:16:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJiyu-0002AR-Q7;
	Mon, 16 Apr 2012 11:16:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.61816.741962.128152@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:16:24 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <7bd96bdf-f7ab-450e-98e6-85fa273a5d28@default>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334217564.12209.250.camel@dagon.hellion.org.uk>
	<2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default>
	<20360.961.392060.587905@mariner.uk.xensource.com>
	<7bd96bdf-f7ab-450e-98e6-85fa273a5d28@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan Magenheimer writes ("RE: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
...
> > There are a few operations that make a function necessarily have to be
> > slow in the libxl api sense.  These are: xenstore watches; spawning
> > subprocesses; anything with a timeout.
> > 
> > More broadly any function which is sufficiently slow that a caller
> > might reasonably want to initiate it, and then carry on doing
> > something else while the function completes.  So this includes any
> > operation which a toolstack might want to parallelise.
> 
> Got it.  Thanks.  This is a bit clearer than the comment in libxl.h.

The internal-facing documentation, which is for people who might be
implementing libxl facilities and API designers, is in
libxl_internal.h.  But the comment there is less comprehensive.  I
will prepare a patch to update it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:26:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJj8l-0001N9-Nk; Mon, 16 Apr 2012 10:26:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJj8j-0001N4-Ru
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:26:34 +0000
Received: from [85.158.139.83:37005] by server-10.bemta-5.messagelabs.com id
	0B/2B-08260-9D3FB8F4; Mon, 16 Apr 2012 10:26:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334571990!16638049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18770 invoked from network); 16 Apr 2012 10:26:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:26:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:26:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:26:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJj8W-0000j6-A5; Mon, 16 Apr 2012 10:26:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJj8W-0002sz-7g;
	Mon, 16 Apr 2012 11:26:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62412.202259.832878@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:26:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334563449.4445.24.camel@dagon.hellion.org.uk>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
	<1334563449.4445.24.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds
 for the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds for the same fd"):
> On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> > We need a slightly more sophisticated data structure to allow this,
> > where we record the slot not just for each fd but also for each
> > (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.
> 
> Just to be sure I'm following: By multiple you mean you can have one
> libxl__ev_fds listening for e.g. POLLIN and another for POLLOUT but you
> specifically exclude the case where two libxl__ev_fds both want to
> listen for POLLIN? Similarly one listening for POLLIN|POLLPRI and the
> other for POLLOUT|POLLPRI (overlapping) is forbidden.

Yes, exactly.  As I say in the new doc comment:
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.

This restriction is actually stronger than that required by the code.
The code merely requires that for every distinct libxl__ev_fd
listening on the same fd, it has at least one of the three flags all
to itself.  So your second scenario would actually work.

Would it be worth documenting this precise restriction ?

> > +     * fd_rindices, and each elemebnt in the rindices is three indices
> 
>                                element

Fixed.

> So, other than the typoe:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:26:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJj8l-0001N9-Nk; Mon, 16 Apr 2012 10:26:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJj8j-0001N4-Ru
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:26:34 +0000
Received: from [85.158.139.83:37005] by server-10.bemta-5.messagelabs.com id
	0B/2B-08260-9D3FB8F4; Mon, 16 Apr 2012 10:26:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334571990!16638049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18770 invoked from network); 16 Apr 2012 10:26:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:26:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:26:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:26:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJj8W-0000j6-A5; Mon, 16 Apr 2012 10:26:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJj8W-0002sz-7g;
	Mon, 16 Apr 2012 11:26:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62412.202259.832878@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:26:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334563449.4445.24.camel@dagon.hellion.org.uk>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
	<1334563449.4445.24.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds
 for the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds for the same fd"):
> On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> > We need a slightly more sophisticated data structure to allow this,
> > where we record the slot not just for each fd but also for each
> > (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.
> 
> Just to be sure I'm following: By multiple you mean you can have one
> libxl__ev_fds listening for e.g. POLLIN and another for POLLOUT but you
> specifically exclude the case where two libxl__ev_fds both want to
> listen for POLLIN? Similarly one listening for POLLIN|POLLPRI and the
> other for POLLOUT|POLLPRI (overlapping) is forbidden.

Yes, exactly.  As I say in the new doc comment:
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.

This restriction is actually stronger than that required by the code.
The code merely requires that for every distinct libxl__ev_fd
listening on the same fd, it has at least one of the three flags all
to itself.  So your second scenario would actually work.

Would it be worth documenting this precise restriction ?

> > +     * fd_rindices, and each elemebnt in the rindices is three indices
> 
>                                element

Fixed.

> So, other than the typoe:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:30:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:30:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjC4-0001VD-GZ; Mon, 16 Apr 2012 10:30:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SJjC3-0001V5-8d
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:29:59 +0000
Received: from [85.158.138.51:40027] by server-6.bemta-3.messagelabs.com id
	54/D3-05145-6A4FB8F4; Mon, 16 Apr 2012 10:29:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334572197!22281694!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6366 invoked from network); 16 Apr 2012 10:29:57 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-174.messagelabs.com with SMTP;
	16 Apr 2012 10:29:57 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.116.148])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77167430; Mon, 16 Apr 2012 12:29:56 +0200
Message-ID: <1334572174.2417.17.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 11:29:34 +0100
In-Reply-To: <62ef1186c24b850cbc1c.1334150276@Solace>
References: <patchbomb.1334150267@Solace>
	<62ef1186c24b850cbc1c.1334150276@Solace>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10 [RFC]] xl: Introduce Best and Worst
 Fit guest placement algorithms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2962668513317338837=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2962668513317338837==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8WMcL80bYZ3q3z2lDD7c"


--=-8WMcL80bYZ3q3z2lDD7c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 15:17 +0200, Dario Faggioli wrote:=20
> Besides than "auto" and "ffit", as per the previous patch, enable
> Best and Worst Fit placement heuristics to `xl`, for the user to
> chose them in the config file. Implementation just sits on top
> of the First Fit algorithm code, with just the proper reordering
> of the nodes and their free memory before invoking it (and after
> it finishes).
>=20
> TODO: * As usual for this series, benchmarking and testing,
>         as much thorough and comprehensive as possible!
>=20
I manage in getting some numbers from these placement heuristics too.

http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa_aggr/index=
.html

As a foreword, they come from some of the benchmarks I already run, and
from running some new ones, but with the same logic and infrastructure,
meaning:
- all the VMs were equal in (memory) size
- all the VMs had the same # of VCPUs
- all the VMs are always created in the very same order
These are definitely not the best condition for stressing the
algorithms, neither they are for trying to understand the algorithms'
differences and capabilities of bringing performance benefits... Anyway,
they're _something_, and a slight improvement wrt default placement is
already noticeable in the graphs. :-)

Look, for example, at one here this:

http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa_aggr/2.htm=
l

And compare the red curve (default placement/schedulig) with all the
other ones. They all represents the aggregate throughput achieved by the
SpecJBB 2005 benchmark --counting (and averaging it on) all the VMs--
when varying the number of VMs, so as usual for SpecJBB, higher is
better.

"wfit" and "bfit" clearly works better than "default", which would have
been desirable, and actually expected, especially for Worst Fit, in this
particular scenario. It is also normal that "ffit" does a worse job than
"default" until the number of VMs excedes 4. In fact, considering the
amount of RAM each VM has (without forgetting some RAM is assigned to
Dom0 as well), with less than 5 VMs all of them are fitted on the first
NUMA node, thus the memory accesses are local, but the load distribution
is clearly sub-optimal!

As for the scheduling related results, more serious testing and tracing
is needed in order to verify things are happening as expected, but the
graphs seemed nice to me, and I thus thought it could be worth sending
them, while working on having more interesting ones. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-8WMcL80bYZ3q3z2lDD7c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+L9I8ACgkQk4XaBE3IOsR0+gCfWesLK7O10AhHQHTBdUaOcbsj
1NEAn0SrubK9MOXk2iLOUPIVjF3gxFft
=DTnA
-----END PGP SIGNATURE-----

--=-8WMcL80bYZ3q3z2lDD7c--



--===============2962668513317338837==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2962668513317338837==--



From xen-devel-bounces@lists.xen.org Mon Apr 16 10:30:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:30:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjC4-0001VD-GZ; Mon, 16 Apr 2012 10:30:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SJjC3-0001V5-8d
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:29:59 +0000
Received: from [85.158.138.51:40027] by server-6.bemta-3.messagelabs.com id
	54/D3-05145-6A4FB8F4; Mon, 16 Apr 2012 10:29:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334572197!22281694!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6366 invoked from network); 16 Apr 2012 10:29:57 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-174.messagelabs.com with SMTP;
	16 Apr 2012 10:29:57 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.116.148])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77167430; Mon, 16 Apr 2012 12:29:56 +0200
Message-ID: <1334572174.2417.17.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 11:29:34 +0100
In-Reply-To: <62ef1186c24b850cbc1c.1334150276@Solace>
References: <patchbomb.1334150267@Solace>
	<62ef1186c24b850cbc1c.1334150276@Solace>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10 [RFC]] xl: Introduce Best and Worst
 Fit guest placement algorithms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2962668513317338837=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2962668513317338837==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8WMcL80bYZ3q3z2lDD7c"


--=-8WMcL80bYZ3q3z2lDD7c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-04-11 at 15:17 +0200, Dario Faggioli wrote:=20
> Besides than "auto" and "ffit", as per the previous patch, enable
> Best and Worst Fit placement heuristics to `xl`, for the user to
> chose them in the config file. Implementation just sits on top
> of the First Fit algorithm code, with just the proper reordering
> of the nodes and their free memory before invoking it (and after
> it finishes).
>=20
> TODO: * As usual for this series, benchmarking and testing,
>         as much thorough and comprehensive as possible!
>=20
I manage in getting some numbers from these placement heuristics too.

http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa_aggr/index=
.html

As a foreword, they come from some of the benchmarks I already run, and
from running some new ones, but with the same logic and infrastructure,
meaning:
- all the VMs were equal in (memory) size
- all the VMs had the same # of VCPUs
- all the VMs are always created in the very same order
These are definitely not the best condition for stressing the
algorithms, neither they are for trying to understand the algorithms'
differences and capabilities of bringing performance benefits... Anyway,
they're _something_, and a slight improvement wrt default placement is
already noticeable in the graphs. :-)

Look, for example, at one here this:

http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa_aggr/2.htm=
l

And compare the red curve (default placement/schedulig) with all the
other ones. They all represents the aggregate throughput achieved by the
SpecJBB 2005 benchmark --counting (and averaging it on) all the VMs--
when varying the number of VMs, so as usual for SpecJBB, higher is
better.

"wfit" and "bfit" clearly works better than "default", which would have
been desirable, and actually expected, especially for Worst Fit, in this
particular scenario. It is also normal that "ffit" does a worse job than
"default" until the number of VMs excedes 4. In fact, considering the
amount of RAM each VM has (without forgetting some RAM is assigned to
Dom0 as well), with less than 5 VMs all of them are fitted on the first
NUMA node, thus the memory accesses are local, but the load distribution
is clearly sub-optimal!

As for the scheduling related results, more serious testing and tracing
is needed in order to verify things are happening as expected, but the
graphs seemed nice to me, and I thus thought it could be worth sending
them, while working on having more interesting ones. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-8WMcL80bYZ3q3z2lDD7c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+L9I8ACgkQk4XaBE3IOsR0+gCfWesLK7O10AhHQHTBdUaOcbsj
1NEAn0SrubK9MOXk2iLOUPIVjF3gxFft
=DTnA
-----END PGP SIGNATURE-----

--=-8WMcL80bYZ3q3z2lDD7c--



--===============2962668513317338837==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2962668513317338837==--



From xen-devel-bounces@lists.xen.org Mon Apr 16 10:32:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjEO-0001cf-2o; Mon, 16 Apr 2012 10:32:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjEM-0001cX-5B
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:32:22 +0000
Received: from [85.158.139.83:2539] by server-2.bemta-5.messagelabs.com id
	A1/29-17016-535FB8F4; Mon, 16 Apr 2012 10:32:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334572340!20109761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29853 invoked from network); 16 Apr 2012 10:32:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:32:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:32:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:32:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjEK-0000mU-9h; Mon, 16 Apr 2012 10:32:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjEK-0002v5-5P;
	Mon, 16 Apr 2012 11:32:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62771.531826.469233@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:32:19 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334567346.14560.48.camel@zakaz.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334567346.14560.48.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> >  LIBXL_LIBS =
> > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
> > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> 
> Did you intend to remove the definition of UTIL_LIBS? I don't see a hunk
> which does that.

It's also used by xenconsoled.

> > +AC_DEFUN([AX_CHECK_PTYFUNCS], [
> > +    AC_CHECK_HEADER([libutil.h],[
> > +      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
> > +    ])
> > +    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
> > +        ax_cv_ptyfuncs_libs=-lutil
> > +        AX_SAVEVAR_SAVE(LIBS)
> > +        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> > +        AC_LINK_IFELSE([
> > +#ifdef INCLUDE_LIBUTIL_H
> > +#include INCLUDE_LIBUTIL_H
> > +#endif
> > +int main(void) {
> > +  openpty(0,0,0,0,0);
> > +  login_tty(0);
> > +}
> > +])
> > +        AX_SAVEVAR_RESTORE(LIBS)],
> > +    [],[
> > +        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
> > +    ])
> > +    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
> > +    AC_SUBST(PTYFUNCS_LIBS)
> > +])
> 
> Does this fail if -lutil isn't available? My (perhaps mistaken) reading
> of the commit message was that -lutil was only needed on some platforms?

Yes, it will do.  Currently -lutil is used everywhere except Solaris
but surely Solaris support has rotted by now.  I could change the
patch to try both with and without, I guess.

> On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
> configure output -- so maybe I just understand what all these macros are
> actually doing.

Linux has -lutil.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:32:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjEO-0001cf-2o; Mon, 16 Apr 2012 10:32:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjEM-0001cX-5B
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:32:22 +0000
Received: from [85.158.139.83:2539] by server-2.bemta-5.messagelabs.com id
	A1/29-17016-535FB8F4; Mon, 16 Apr 2012 10:32:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334572340!20109761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29853 invoked from network); 16 Apr 2012 10:32:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:32:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:32:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:32:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjEK-0000mU-9h; Mon, 16 Apr 2012 10:32:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjEK-0002v5-5P;
	Mon, 16 Apr 2012 11:32:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62771.531826.469233@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:32:19 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334567346.14560.48.camel@zakaz.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334567346.14560.48.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> >  LIBXL_LIBS =
> > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
> > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> 
> Did you intend to remove the definition of UTIL_LIBS? I don't see a hunk
> which does that.

It's also used by xenconsoled.

> > +AC_DEFUN([AX_CHECK_PTYFUNCS], [
> > +    AC_CHECK_HEADER([libutil.h],[
> > +      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
> > +    ])
> > +    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
> > +        ax_cv_ptyfuncs_libs=-lutil
> > +        AX_SAVEVAR_SAVE(LIBS)
> > +        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> > +        AC_LINK_IFELSE([
> > +#ifdef INCLUDE_LIBUTIL_H
> > +#include INCLUDE_LIBUTIL_H
> > +#endif
> > +int main(void) {
> > +  openpty(0,0,0,0,0);
> > +  login_tty(0);
> > +}
> > +])
> > +        AX_SAVEVAR_RESTORE(LIBS)],
> > +    [],[
> > +        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
> > +    ])
> > +    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
> > +    AC_SUBST(PTYFUNCS_LIBS)
> > +])
> 
> Does this fail if -lutil isn't available? My (perhaps mistaken) reading
> of the commit message was that -lutil was only needed on some platforms?

Yes, it will do.  Currently -lutil is used everywhere except Solaris
but surely Solaris support has rotted by now.  I could change the
patch to try both with and without, I guess.

> On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
> configure output -- so maybe I just understand what all these macros are
> actually doing.

Linux has -lutil.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjFK-0001hS-Gz; Mon, 16 Apr 2012 10:33:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjFI-0001hC-EQ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:33:20 +0000
Received: from [85.158.143.35:16713] by server-1.bemta-4.messagelabs.com id
	D4/B6-20925-F65FB8F4; Mon, 16 Apr 2012 10:33:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334572398!10149274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10784 invoked from network); 16 Apr 2012 10:33:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:33:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:33:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:33:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjFG-0000mp-2m; Mon, 16 Apr 2012 10:33:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjFG-0002vs-22;
	Mon, 16 Apr 2012 11:33:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62829.891721.733072@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:33:17 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334568245.14560.57.camel@zakaz.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
	<1334568245.14560.57.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et al."):
> > +    size_t need = offsetof(struct dirent, d_name) +
> > +        pathconf(dirpath, _PC_NAME_MAX) + 1;
> 
> This was an interesting pattern, but I see that readdir(3) recommends
> portable programs do things this way...

Bizarre, eh ?

> > +        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
> > +        if (libxl__remove_file_or_directory(gc, subpath))
> > +            rc = ERROR_FAIL;
> 
> Deliberately doesn't "goto out" so as to remove as much as possible?

Yes.

> If so then:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjFK-0001hS-Gz; Mon, 16 Apr 2012 10:33:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjFI-0001hC-EQ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:33:20 +0000
Received: from [85.158.143.35:16713] by server-1.bemta-4.messagelabs.com id
	D4/B6-20925-F65FB8F4; Mon, 16 Apr 2012 10:33:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334572398!10149274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10784 invoked from network); 16 Apr 2012 10:33:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:33:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:33:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:33:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjFG-0000mp-2m; Mon, 16 Apr 2012 10:33:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjFG-0002vs-22;
	Mon, 16 Apr 2012 11:33:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62829.891721.733072@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:33:17 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334568245.14560.57.camel@zakaz.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-6-git-send-email-ian.jackson@eu.citrix.com>
	<1334568245.14560.57.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et
 al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/20] libxl: provide libxl__remove_file et al."):
> > +    size_t need = offsetof(struct dirent, d_name) +
> > +        pathconf(dirpath, _PC_NAME_MAX) + 1;
> 
> This was an interesting pattern, but I see that readdir(3) recommends
> portable programs do things this way...

Bizarre, eh ?

> > +        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
> > +        if (libxl__remove_file_or_directory(gc, subpath))
> > +            rc = ERROR_FAIL;
> 
> Deliberately doesn't "goto out" so as to remove as much as possible?

Yes.

> If so then:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:33:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjFZ-0001jO-TR; Mon, 16 Apr 2012 10:33:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJjFY-0001j3-Ev
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:33:36 +0000
Received: from [85.158.143.35:17934] by server-3.bemta-4.messagelabs.com id
	51/93-05853-F75FB8F4; Mon, 16 Apr 2012 10:33:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334572415!7256815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9418 invoked from network); 16 Apr 2012 10:33:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:33:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:33:35 +0100
Message-ID: <1334572413.14560.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 11:33:33 +0100
In-Reply-To: <1334231571.16387.100.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334231571.16387.100.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > > ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> > ...
> > > > These functions should not exec things for you; they should tell you
> > > > the parameters.  Any execing helpers should be in libxlu.
> > > 
> > > It's not enough for them to just use libxl__exec?
> > > 
> > > It'd be reasonably easy to make this return a libxl_string_list or
> > > similar and to write a libxlu function which takes one of those.
> > 
> > But what if your vnc viewer doesn't have the command line options
> > these functions expect ?  libxl_vncviewer_* should give you an idl
> > struct containing the ip address (or perhaps the domain name), port
> > number, and password.
> > 
> > The command lines should be built in xlu.
> 
> Hrm, this seems like 4.3 material at this stage.
> 
> I'd expect that the functions which behaved this way would not be
> called ..._exec (perhaps ..._get_params or so) so implementing the
> proper interface in 4.3 won't cause a compat issue.

Just looking at this again, does this argument only really apply to
vncviewer (which is a 3rd party component)?

The other libxl_FOO_exec are both variations of execing xenconsole which
is supplied as part of the xen install and is not really subject to 3rd
party replacements (at least we can decree that they are cmdline
compatible).




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:33:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjFZ-0001jO-TR; Mon, 16 Apr 2012 10:33:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJjFY-0001j3-Ev
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:33:36 +0000
Received: from [85.158.143.35:17934] by server-3.bemta-4.messagelabs.com id
	51/93-05853-F75FB8F4; Mon, 16 Apr 2012 10:33:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334572415!7256815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9418 invoked from network); 16 Apr 2012 10:33:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:33:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:33:35 +0100
Message-ID: <1334572413.14560.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 11:33:33 +0100
In-Reply-To: <1334231571.16387.100.camel@zakaz.uk.xensource.com>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<20357.44475.632787.365339@mariner.uk.xensource.com>
	<1334216554.12209.239.camel@dagon.hellion.org.uk>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<20358.47143.994639.76453@mariner.uk.xensource.com>
	<1334231571.16387.100.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > > ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> > ...
> > > > These functions should not exec things for you; they should tell you
> > > > the parameters.  Any execing helpers should be in libxlu.
> > > 
> > > It's not enough for them to just use libxl__exec?
> > > 
> > > It'd be reasonably easy to make this return a libxl_string_list or
> > > similar and to write a libxlu function which takes one of those.
> > 
> > But what if your vnc viewer doesn't have the command line options
> > these functions expect ?  libxl_vncviewer_* should give you an idl
> > struct containing the ip address (or perhaps the domain name), port
> > number, and password.
> > 
> > The command lines should be built in xlu.
> 
> Hrm, this seems like 4.3 material at this stage.
> 
> I'd expect that the functions which behaved this way would not be
> called ..._exec (perhaps ..._get_params or so) so implementing the
> proper interface in 4.3 won't cause a compat issue.

Just looking at this again, does this argument only really apply to
vncviewer (which is a 3rd party component)?

The other libxl_FOO_exec are both variations of execing xenconsole which
is supplied as part of the xen install and is not really subject to 3rd
party replacements (at least we can decree that they are cmdline
compatible).




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:35:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjHC-0001us-DC; Mon, 16 Apr 2012 10:35:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjHB-0001uZ-Dd
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:35:17 +0000
Received: from [85.158.143.35:29300] by server-2.bemta-4.messagelabs.com id
	27/81-17550-3E5FB8F4; Mon, 16 Apr 2012 10:35:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334572514!12224454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22704 invoked from network); 16 Apr 2012 10:35:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:35:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:35:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjH8-0000nZ-2t; Mon, 16 Apr 2012 10:35:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjH8-0002wH-1q;
	Mon, 16 Apr 2012 11:35:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62946.40242.576539@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:35:14 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> > +#ifdef INCLUDE_LIBUTIL_H
> > +#include INCLUDE_LIBUTIL_H
> > +#endif
> > +
> 
> Maybe I'm missing something, because this autoconf macros are hard to read, but shouldn't you add something like
> 
> #undef INCLUDE_LIBUTIL_H
> 
> to tools/config.h.in, so the generated config.h contains this define?

Yes.  This is normally done by autoheader, which is normally done by
autogen.sh.  But I see that we aren't running autoheader.  I will see
about fixing that.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:35:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjHC-0001us-DC; Mon, 16 Apr 2012 10:35:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjHB-0001uZ-Dd
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:35:17 +0000
Received: from [85.158.143.35:29300] by server-2.bemta-4.messagelabs.com id
	27/81-17550-3E5FB8F4; Mon, 16 Apr 2012 10:35:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334572514!12224454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22704 invoked from network); 16 Apr 2012 10:35:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11951672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:35:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:35:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjH8-0000nZ-2t; Mon, 16 Apr 2012 10:35:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjH8-0002wH-1q;
	Mon, 16 Apr 2012 11:35:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.62946.40242.576539@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:35:14 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> > +#ifdef INCLUDE_LIBUTIL_H
> > +#include INCLUDE_LIBUTIL_H
> > +#endif
> > +
> 
> Maybe I'm missing something, because this autoconf macros are hard to read, but shouldn't you add something like
> 
> #undef INCLUDE_LIBUTIL_H
> 
> to tools/config.h.in, so the generated config.h contains this define?

Yes.  This is normally done by autoheader, which is normally done by
autogen.sh.  But I see that we aren't running autoheader.  I will see
about fixing that.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjMR-0002Ex-7v; Mon, 16 Apr 2012 10:40:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJjMP-0002Ek-C9
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:40:41 +0000
Received: from [85.158.143.35:27568] by server-1.bemta-4.messagelabs.com id
	C2/63-20925-827FB8F4; Mon, 16 Apr 2012 10:40:40 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334572835!11519439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20819 invoked from network); 16 Apr 2012 10:40:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330923600"; d="scan'208";a="190467755"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 06:40:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 06:40:34 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJjMI-0005ed-6m;
	Mon, 16 Apr 2012 11:40:34 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <20363.62946.40242.576539@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:40:36 +0100
Message-ID: <4CEB2412-545B-48A4-A6F2-52213D328565@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
	<20363.62946.40242.576539@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 11:35, Ian Jackson escribi=F3:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test=
 for openpty et al."):
>>> +#ifdef INCLUDE_LIBUTIL_H
>>> +#include INCLUDE_LIBUTIL_H
>>> +#endif
>>> +
>> =

>> Maybe I'm missing something, because this autoconf macros are hard to re=
ad, but shouldn't you add something like
>> =

>> #undef INCLUDE_LIBUTIL_H
>> =

>> to tools/config.h.in, so the generated config.h contains this define?
> =

> Yes.  This is normally done by autoheader, which is normally done by
> autogen.sh.  But I see that we aren't running autoheader.  I will see
> about fixing that.
> =


Autoheader was adding a lot of stuff which we weren't using, so I preferred=
 to keep config.h.in (and config.h) with just the defines we really need.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjMR-0002Ex-7v; Mon, 16 Apr 2012 10:40:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJjMP-0002Ek-C9
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:40:41 +0000
Received: from [85.158.143.35:27568] by server-1.bemta-4.messagelabs.com id
	C2/63-20925-827FB8F4; Mon, 16 Apr 2012 10:40:40 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334572835!11519439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20819 invoked from network); 16 Apr 2012 10:40:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330923600"; d="scan'208";a="190467755"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 06:40:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 06:40:34 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJjMI-0005ed-6m;
	Mon, 16 Apr 2012 11:40:34 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <20363.62946.40242.576539@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:40:36 +0100
Message-ID: <4CEB2412-545B-48A4-A6F2-52213D328565@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
	<20363.62946.40242.576539@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 11:35, Ian Jackson escribi=F3:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test=
 for openpty et al."):
>>> +#ifdef INCLUDE_LIBUTIL_H
>>> +#include INCLUDE_LIBUTIL_H
>>> +#endif
>>> +
>> =

>> Maybe I'm missing something, because this autoconf macros are hard to re=
ad, but shouldn't you add something like
>> =

>> #undef INCLUDE_LIBUTIL_H
>> =

>> to tools/config.h.in, so the generated config.h contains this define?
> =

> Yes.  This is normally done by autoheader, which is normally done by
> autogen.sh.  But I see that we aren't running autoheader.  I will see
> about fixing that.
> =


Autoheader was adding a lot of stuff which we weren't using, so I preferred=
 to keep config.h.in (and config.h) with just the defines we really need.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:56:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjbi-0002RU-Vt; Mon, 16 Apr 2012 10:56:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjbh-0002RP-Ox
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:56:29 +0000
Received: from [85.158.138.51:45827] by server-10.bemta-3.messagelabs.com id
	04/C3-29478-DDAFB8F4; Mon, 16 Apr 2012 10:56:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334573788!22306067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16131 invoked from network); 16 Apr 2012 10:56:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:56:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11952385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:56:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:56:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjbe-00010W-Gx; Mon, 16 Apr 2012 10:56:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjbe-0002yH-G4;
	Mon, 16 Apr 2012 11:56:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.64218.480437.208423@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:56:26 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4CEB2412-545B-48A4-A6F2-52213D328565@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
	<20363.62946.40242.576539@mariner.uk.xensource.com>
	<4CEB2412-545B-48A4-A6F2-52213D328565@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test f=
or openpty et al."):
> El 16/04/2012, a las 11:35, Ian Jackson escribi=F3:
> > Yes.  This is normally done by autoheader, which is normally done by
> > autogen.sh.  But I see that we aren't running autoheader.  I will see
> > about fixing that.
> =

> Autoheader was adding a lot of stuff which we weren't using, so I preferr=
ed to keep config.h.in (and config.h) with just the defines we really need.

I just ran it and everything it generates seems to be produced by
something in configure.ac, as I expected.

Surely the problem then is that configure.ac has too much useless
stuff in it ?  For example why are we checking for things like alarm
and atexit and everything from <string.h>, which are going to exist
everywhere ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 10:56:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 10:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjbi-0002RU-Vt; Mon, 16 Apr 2012 10:56:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJjbh-0002RP-Ox
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 10:56:29 +0000
Received: from [85.158.138.51:45827] by server-10.bemta-3.messagelabs.com id
	04/C3-29478-DDAFB8F4; Mon, 16 Apr 2012 10:56:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334573788!22306067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16131 invoked from network); 16 Apr 2012 10:56:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 10:56:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11952385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:56:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 11:56:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJjbe-00010W-Gx; Mon, 16 Apr 2012 10:56:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJjbe-0002yH-G4;
	Mon, 16 Apr 2012 11:56:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20363.64218.480437.208423@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 11:56:26 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4CEB2412-545B-48A4-A6F2-52213D328565@citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<B3BE1540-C11A-4403-8909-3FB4F7135F14@citrix.com>
	<20363.62946.40242.576539@mariner.uk.xensource.com>
	<4CEB2412-545B-48A4-A6F2-52213D328565@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test f=
or openpty et al."):
> El 16/04/2012, a las 11:35, Ian Jackson escribi=F3:
> > Yes.  This is normally done by autoheader, which is normally done by
> > autogen.sh.  But I see that we aren't running autoheader.  I will see
> > about fixing that.
> =

> Autoheader was adding a lot of stuff which we weren't using, so I preferr=
ed to keep config.h.in (and config.h) with just the defines we really need.

I just ran it and everything it generates seems to be produced by
something in configure.ac, as I expected.

Surely the problem then is that configure.ac has too much useless
stuff in it ?  For example why are we checking for things like alarm
and atexit and everything from <string.h>, which are going to exist
everywhere ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:18:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjwC-0002yi-Hw; Mon, 16 Apr 2012 11:17:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJjwA-0002yd-Vf
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:17:39 +0000
Received: from [85.158.143.35:28324] by server-1.bemta-4.messagelabs.com id
	61/73-20925-2DFFB8F4; Mon, 16 Apr 2012 11:17:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334575057!7265765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 885 invoked from network); 16 Apr 2012 11:17:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11952892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:17:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:17:37 +0100
Message-ID: <1334575056.14560.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 12:17:36 +0100
In-Reply-To: <20363.62412.202259.832878@mariner.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
	<1334563449.4445.24.camel@dagon.hellion.org.uk>
	<20363.62412.202259.832878@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds
 for the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 11:26 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds for the same fd"):
> > On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> > > We need a slightly more sophisticated data structure to allow this,
> > > where we record the slot not just for each fd but also for each
> > > (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.
> > 
> > Just to be sure I'm following: By multiple you mean you can have one
> > libxl__ev_fds listening for e.g. POLLIN and another for POLLOUT but you
> > specifically exclude the case where two libxl__ev_fds both want to
> > listen for POLLIN? Similarly one listening for POLLIN|POLLPRI and the
> > other for POLLOUT|POLLPRI (overlapping) is forbidden.
> 
> Yes, exactly.  As I say in the new doc comment:
> +   *
> +   * It is not permitted to listen for the same or overlapping events
> +   * on the same fd using multiple different libxl__ev_fd's.
> 
> This restriction is actually stronger than that required by the code.
> The code merely requires that for every distinct libxl__ev_fd
> listening on the same fd, it has at least one of the three flags all
> to itself.  So your second scenario would actually work.
> 
> Would it be worth documenting this precise restriction ?

I guess it would just confuse the language but only really add anything
for what is a pretty small corner case?

Since it's a libxl internal thing I'm not too concerned about people
coming to rely on the actual broader behaviour.

> 
> > > +     * fd_rindices, and each elemebnt in the rindices is three indices
> > 
> >                                element
> 
> Fixed.
> 
> > So, other than the typoe:
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:18:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjwC-0002yi-Hw; Mon, 16 Apr 2012 11:17:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJjwA-0002yd-Vf
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:17:39 +0000
Received: from [85.158.143.35:28324] by server-1.bemta-4.messagelabs.com id
	61/73-20925-2DFFB8F4; Mon, 16 Apr 2012 11:17:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334575057!7265765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 885 invoked from network); 16 Apr 2012 11:17:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11952892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:17:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:17:37 +0100
Message-ID: <1334575056.14560.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 12:17:36 +0100
In-Reply-To: <20363.62412.202259.832878@mariner.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-3-git-send-email-ian.jackson@eu.citrix.com>
	<1334563449.4445.24.camel@dagon.hellion.org.uk>
	<20363.62412.202259.832878@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds
 for the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 11:26 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/20] libxl: support multiple libxl__ev_fds for the same fd"):
> > On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> > > We need a slightly more sophisticated data structure to allow this,
> > > where we record the slot not just for each fd but also for each
> > > (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.
> > 
> > Just to be sure I'm following: By multiple you mean you can have one
> > libxl__ev_fds listening for e.g. POLLIN and another for POLLOUT but you
> > specifically exclude the case where two libxl__ev_fds both want to
> > listen for POLLIN? Similarly one listening for POLLIN|POLLPRI and the
> > other for POLLOUT|POLLPRI (overlapping) is forbidden.
> 
> Yes, exactly.  As I say in the new doc comment:
> +   *
> +   * It is not permitted to listen for the same or overlapping events
> +   * on the same fd using multiple different libxl__ev_fd's.
> 
> This restriction is actually stronger than that required by the code.
> The code merely requires that for every distinct libxl__ev_fd
> listening on the same fd, it has at least one of the three flags all
> to itself.  So your second scenario would actually work.
> 
> Would it be worth documenting this precise restriction ?

I guess it would just confuse the language but only really add anything
for what is a pretty small corner case?

Since it's a libxl internal thing I'm not too concerned about people
coming to rely on the actual broader behaviour.

> 
> > > +     * fd_rindices, and each elemebnt in the rindices is three indices
> > 
> >                                element
> 
> Fixed.
> 
> > So, other than the typoe:
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:19:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjxp-00032e-2R; Mon, 16 Apr 2012 11:19:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJjxn-00032X-UN
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:19:20 +0000
Received: from [85.158.143.99:48356] by server-2.bemta-4.messagelabs.com id
	75/DC-17550-7300C8F4; Mon, 16 Apr 2012 11:19:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334575141!23841111!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20959 invoked from network); 16 Apr 2012 11:19:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:19:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11952938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:19:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:19:01 +0100
Message-ID: <1334575140.14560.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 12:19:00 +0100
In-Reply-To: <20363.62771.531826.469233@mariner.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334567346.14560.48.camel@zakaz.uk.xensource.com>
	<20363.62771.531826.469233@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 11:32 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> > On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> > >  LIBXL_LIBS =
> > > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
> > > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> > 
> > Did you intend to remove the definition of UTIL_LIBS? I don't see a hunk
> > which does that.
> 
> It's also used by xenconsoled.
> 
> > > +AC_DEFUN([AX_CHECK_PTYFUNCS], [
> > > +    AC_CHECK_HEADER([libutil.h],[
> > > +      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
> > > +    ])
> > > +    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
> > > +        ax_cv_ptyfuncs_libs=-lutil
> > > +        AX_SAVEVAR_SAVE(LIBS)
> > > +        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> > > +        AC_LINK_IFELSE([
> > > +#ifdef INCLUDE_LIBUTIL_H
> > > +#include INCLUDE_LIBUTIL_H
> > > +#endif
> > > +int main(void) {
> > > +  openpty(0,0,0,0,0);
> > > +  login_tty(0);
> > > +}
> > > +])
> > > +        AX_SAVEVAR_RESTORE(LIBS)],
> > > +    [],[
> > > +        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
> > > +    ])
> > > +    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
> > > +    AC_SUBST(PTYFUNCS_LIBS)
> > > +])
> > 
> > Does this fail if -lutil isn't available? My (perhaps mistaken) reading
> > of the commit message was that -lutil was only needed on some platforms?
> 
> Yes, it will do.  Currently -lutil is used everywhere except Solaris
> but surely Solaris support has rotted by now.  I could change the
> patch to try both with and without, I guess.

OK, I think we can just leave it until someone ports Xen to a platform
which has this behaviour (i.e. it can be tested)

> > On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
> > configure output -- so maybe I just understand what all these macros are
> > actually doing.
> 
> Linux has -lutil.

I meant that the message doesn't seem to appear in the generate
configure script itself.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:19:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJjxp-00032e-2R; Mon, 16 Apr 2012 11:19:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJjxn-00032X-UN
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:19:20 +0000
Received: from [85.158.143.99:48356] by server-2.bemta-4.messagelabs.com id
	75/DC-17550-7300C8F4; Mon, 16 Apr 2012 11:19:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334575141!23841111!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20959 invoked from network); 16 Apr 2012 11:19:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:19:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11952938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:19:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:19:01 +0100
Message-ID: <1334575140.14560.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 12:19:00 +0100
In-Reply-To: <20363.62771.531826.469233@mariner.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334567346.14560.48.camel@zakaz.uk.xensource.com>
	<20363.62771.531826.469233@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 11:32 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> > On Fri, 2012-04-13 at 19:39 +0100, Ian Jackson wrote:
> > >  LIBXL_LIBS =
> > > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
> > > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> > 
> > Did you intend to remove the definition of UTIL_LIBS? I don't see a hunk
> > which does that.
> 
> It's also used by xenconsoled.
> 
> > > +AC_DEFUN([AX_CHECK_PTYFUNCS], [
> > > +    AC_CHECK_HEADER([libutil.h],[
> > > +      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
> > > +    ])
> > > +    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
> > > +        ax_cv_ptyfuncs_libs=-lutil
> > > +        AX_SAVEVAR_SAVE(LIBS)
> > > +        LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> > > +        AC_LINK_IFELSE([
> > > +#ifdef INCLUDE_LIBUTIL_H
> > > +#include INCLUDE_LIBUTIL_H
> > > +#endif
> > > +int main(void) {
> > > +  openpty(0,0,0,0,0);
> > > +  login_tty(0);
> > > +}
> > > +])
> > > +        AX_SAVEVAR_RESTORE(LIBS)],
> > > +    [],[
> > > +        AC_MSG_FAILURE([Unable to find -lutil for openpty and login_tty])
> > > +    ])
> > > +    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
> > > +    AC_SUBST(PTYFUNCS_LIBS)
> > > +])
> > 
> > Does this fail if -lutil isn't available? My (perhaps mistaken) reading
> > of the commit message was that -lutil was only needed on some platforms?
> 
> Yes, it will do.  Currently -lutil is used everywhere except Solaris
> but surely Solaris support has rotted by now.  I could change the
> patch to try both with and without, I guess.

OK, I think we can just leave it until someone ports Xen to a platform
which has this behaviour (i.e. it can be tested)

> > On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
> > configure output -- so maybe I just understand what all these macros are
> > actually doing.
> 
> Linux has -lutil.

I meant that the message doesn't seem to appear in the generate
configure script itself.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:32:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkA0-0003Gb-Dk; Mon, 16 Apr 2012 11:31:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJk9y-0003GW-PW
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:31:55 +0000
Received: from [85.158.143.35:29251] by server-2.bemta-4.messagelabs.com id
	99/71-17550-A230C8F4; Mon, 16 Apr 2012 11:31:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334575913!12603000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25617 invoked from network); 16 Apr 2012 11:31:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:31:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11953250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:31:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:31:52 +0100
Message-ID: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 12:31:50 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt
bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv
bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg
ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKTWlkL0xhdGUgQXByaWwgIC0t
IEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCBp
dCBpcyByZWFkeQoKVGhlIHVwZGF0ZWQgVE9ETyBsaXN0IGZvbGxvd3MuIFBlciB0aGUgcmVsZWFz
ZSBwbGFuIGEgc3Ryb25nIGNhc2Ugd2lsbApub3cgaGF2ZSB0byBiZSBtYWRlIGFzIHRvIHdoeSBu
ZXcgaXRlbXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0LAplc3BlY2lhbGx5IGFzIGEgYmxv
Y2tlciwgcmF0aGVyIHRoYW4gZGVmZXJyZWQgdG8gNC4zLgoKV2UgaGF2ZSBub3cgZW50ZXJlZCBG
ZWF0dXJlIEZyZWV6ZS4gUGF0Y2hlcyB3aGljaCBoYXZlIGJlZW4gcG9zdGVkCmJlZm9yZSBvciB3
aGljaCBhZGRyZXNzIHNvbWV0aGluZyBvbiB0aGUgbGlzdCBiZWxvdyBhcmUgc3RpbGwgYWNjZXB0
YWJsZQooZm9yIG5vdywgd2Ugd2lsbCBncmFkdWFsbHkgYmUgZ2V0dGluZyBzdHJpY3RlciBhYm91
dCB0aGlzKSwgZXZlcnl0aGluZwplbHNlIHdpbGwgYmUgZGVmZXJyZWQgdW50aWwgNC4zIGJ5IGRl
ZmF1bHQuCgpBIGJ1bmNoIG9mIG5ldyBpdGVtcyBoYXZlIGJlZW4gYWRkZWQgdG8gdGhlIGxpc3Qs
IG1haW5seSBkdWUgdG8gSWFuCkphY2tzb25zIHJldmlldyBvZiB0aGUgbGlieGwgQVBJIGZvciBz
dGFiaWxpdHkuIEkgYmVsaWV2ZSB0aGVzZSBhcmUKbW9zdGx5IHVuZGVyIGNvbnRyb2wuIFNvbWUg
b2YgdGhlc2UgYXJlIGdvaW5nIHRvIGJlIGltbWVkaWF0ZWx5IGRlZmVycmVkCnRvIDQuMyBidXQg
SSBoYXZlIGluY2x1ZGVkIHRoZW0gaW4gdGhpcyB3ZWVrJ3MgbGlzdCB0byBhbGxvdyB0aGUKb3Bw
b3J0dW5pdHkgZm9yIGZlZWRiYWNrLgoKU29tZSBvZiB0aGUgbmV3IGl0ZW1zIGFyZSB1bmNsYWlt
ZWQuIFZvbHVudGVlcnMgd291bGQgYmUgbXVjaAphcHByZWNpYXRlZC4KCkFzIGRpc2N1c3NlZCBs
YXN0IHdlZWsgSSBoYXZlIGFkZGVkIGtub3duIGJ1Z3MgdG8gdGhlIGxpc3RzIGJlbG93LgpQbGVh
c2UgcmVmZXIgbWUgdG8gYW55IHNob3VsZCBvciBtdXN0IGJlIGZpeGVkIGJ1Z3MgKGJlc3Qgd2F5
IGl0IGJ5CnJlc3BvbmRpbmcgdG8gdGhpcyBtYWlsIHdpdGggYSBwb2ludGVyIHNvIG15IHRocmVh
ZGluZyBtYWlsZXIgd2lsbCB0cmFjawppdCBmb3IgbmV4dCB3ZWVrKS4KCmh5cGVydmlzb3IsIGJs
b2NrZXJzOgogICAgICAqIFtCVUddIFpvbWJpZSBkcml2ZXIgZG9tYWlucy4gIFRoZXJlJ3MgYSBi
dWcgd2hlcmUgUFYgZ3Vlc3RzIHdpdGgKICAgICAgICBkZXZpY2VzIHBhc3NlZCB0aHJvdWdoIHdp
dGggeGwgaGFuZyBhcm91bmQgYXMgInpvbWJpZXMiLCB3aXRoCiAgICAgICAgb25lIG91dHN0YW5k
aW5nIHBhZ2UgcmVmZXJlbmNlLiAgSSB0aGluayB0aGlzIHNob3VsZCByZWFsbHkgYmUgYQogICAg
ICAgIGJsb2NrZXIuIEknbSB3b3JraW5nIG9uIHRoaXMgYXQgdGhlIG1vbWVudCAoR2VvcmdlIER1
bmxhcCkuCiAgICAgICAgICAgICAgKiBPbmUgb2Ygc2V2ZXJhbCByZWNlbnQgcmVwb3J0cyBvZiBa
b21iaWUgZG9tYWlucywgd2hpY2gKICAgICAgICAgICAgICAgIG1heSBvciBtYXkgbm90IGJlIGFs
bCByZWxhdGVkLgogICAgICAgICAgICAgICogTGlzdCBhcyBoeXBlcnZpc29yIGZvciBub3csIGJ1
dCBtYXkgdHVybiBvdXQgdG8gYmUgYQogICAgICAgICAgICAgICAgdG9vbHMgaXNzdWUuCiAKdG9v
bHMsIGJsb2NrZXJzOgogICAgICAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0
LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQogICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4g
c3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YKICAgICAgICB0aGlzIGFy
ZToKICAgICAgICAgICAgICAqIFNhZmUgZm9yayB2cy4gZmQgaGFuZGxpbmcgaG9va3MuIEludm9s
dmVzIEFQSSBjaGFuZ2VzCiAgICAgICAgICAgICAgICAoSWFuIEosIHBhdGNoZXMgcG9zdGVkKQog
ICAgICAgICAgICAgICogbG9ja2luZy9zZXJpYWxpemF0aW9uLCBlLmcuLCBmb3IgZG9tYWluIGNy
ZWF0aW9uLiBbLi4uXQogICAgICAgICAgICAgICAgICAgICAgKiBEZWZlcnJlZCB1bnRpbCA0LjMu
IFdlIHRoaW5rIHRoaXMgZnVuY3Rpb25hbGl0eQogICAgICAgICAgICAgICAgICAgICAgICBjYW4g
YmUgYWRkZWQgd2l0aG91dCBpbXBhY3RpbmcgQVBJIHN0YWJpbGl0eS4KICAgICAgICAgICAgICAq
IGxpYnhsX3dhaXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQu
CiAgICAgICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8K
ICAgICAgICAgICAgICAgIGxvY2tpbmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUg
KHNlZSBhYm92ZSkuCiAgICAgICAgICAgICAgICBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMg
aW50ZXJmYWNlIGJlaW5nIHN1YnN0YW5kYXJkCiAgICAgICAgICAgICAgICBidXQgb3RoZXJ3aXNl
IGRlZmVyIHRvIDQuMy4KICAgICAgICAgICAgICAqIGxpYnhsX3tGT099X2V4ZWMuIFNob3VsZCBy
ZXR1cm4gYSBkYXRhIHN0cnVjdHVyZQogICAgICAgICAgICAgICAgZGVjbGFyaW5nIHdoYXQgdG8g
ZG8sIG5vdCBmb3JrIGFuZCBleGVjIHRoZW1zZWx2ZXMuCiAgICAgICAgICAgICAgICBIb3dldmVy
IHdlIGNhbiBkZWZlciB0aGlzIHVudGlsIDQuMy4KICAgICAgICAgICAgICAqIGxpYnhsXypfcGF0
aC4gTWFqb3JpdHkgbWFkZSBpbnRlcm5hbCwgb25seSBjb25maWdkaXIgYW5kCiAgICAgICAgICAg
ICAgICBsb2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVzZWQgYnkgeGwpLiBHb29kIGVub3VnaD8KICAg
ICAgICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6CiAgICAg
ICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9zdXNwZW5kLiBOb2JvZHkgaGFzIGxvb2tl
ZCBhdCB0aGVzZQogICAgICAgICAgICAgICAgICAgICAgICBhdCBhbGwuIEEgdm9sdW50ZWVyIHdv
dWxkIGJlIGFwcHJlY2lhdGVkLgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5f
Y3JlYXRlX3tuZXcscmVzdG9yZX0gLS0gSWFuSiBoYXMKICAgICAgICAgICAgICAgICAgICAgICAg
cGF0Y2hlcyBhcyBwYXJ0IG9mIGV2ZW50IHNlcmllcy4KICAgICAgICAgICAgICAgICAgICAgICog
bGlieGxfZG9tYWluX3tzaHV0ZG93bixyZWJvb3R9LiBUaGVzZSBhcmUgImZhc3QiCiAgICAgICAg
ICAgICAgICAgICAgICAgIGZ1bmN0aW9ucyBhbmQgdGhlcmUgZG8gbm90IG5lZWQgdG8gYmUgYXN5
bmMuCiAgICAgICAgICAgICAgICAgICAgICAgIChTbywgRE9ORSB3aXRoIG5vIGFjdGlvbiByZXF1
aXJlZCkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZG9tYWluX2NvcmVfZHVtcC4gQ2Fu
IHRha2UgYSBkdW1teSBhb19ob3cKICAgICAgICAgICAgICAgICAgICAgICAgYW5kIHJlbWFpbiBz
eW5jaHJvbm91cyBpbnRlcm5hbGx5LgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kZXZp
Y2Vfe2Rpc2ssbmljLHZrYixhZGR9X2FkZCAoYW5kCiAgICAgICAgICAgICAgICAgICAgICAgIHJl
bW92ZT8pLiBSb2dlciBQYXUgTW9ubsOpIGZpeGVzIGRpc2sgYXMgcGFydCBvZgogICAgICAgICAg
ICAgICAgICAgICAgICBob3RwbHVnIHNjcmlwdCBzZXJpZXMgYW5kIGFkZHMgaW5mcmFzdHJ1Y3R1
cmUKICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggc2hvdWxkIG1ha2UgdGhlIG90aGVycyB0
cml2aWFsLgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9jZHJvbV9pbnNlcnQuIFNob3Vs
ZCBiZSBlYXN5IG9uY2UKICAgICAgICAgICAgICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0g
ZG9uZSwgSWFuSiB0byBsb29rIGF0LgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kZXZp
Y2VfZGlza19sb2NhbF97YXR0YWNoLGRldGFjaH0uIEJlY29tZQogICAgICAgICAgICAgICAgICAg
ICAgICBpbnRlcm5hbCBhcyBwYXJ0IG9mIFN0ZWZhbm8ncyBkb21haW4gMCBkaXNrCiAgICAgICAg
ICAgICAgICAgICAgICAgIGF0dGFjaCBzZXJpZXMuCiAgICAgICAgICAgICAgICAgICAgICAqIGxp
YnhsX2RldmljZV9wY2lfe2FkZCxyZW1vdmV9LiBMZXNzIHRyaXZpYWwgdGhhbgogICAgICAgICAg
ICAgICAgICAgICAgICB0aGUgb3RoZXJzLiBBIHZvbHVudGVlciB3b3VsZCBiZSBhcHByZWNpYXRl
ZC4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfeGVuX2NvbnNvbGVfKi4gTm8gaW50ZXJm
YWNlIGZvciB3YWl0aW5nCiAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBlYWNoIGNhbGwganVz
dCBkdW1wcyBhIGJpdCBtb3JlIG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICByaW5nICwg
c28gaXMgZmFzdC4gTm90aGluZyB0byBkbyBoZXJlICh0aGVyZWZvcmUKICAgICAgICAgICAgICAg
ICAgICAgICAgRE9ORSkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfeGVuX3RtZW1fKi4g
QWxsIGZ1bmN0aW9ucyBhcmUgImZhc3QiIGFuZAogICAgICAgICAgICAgICAgICAgICAgICB0aGVy
ZWZvcmUgbm8gYXN5bmMgbmVlZGVkLiBFeGNlcHRpb24gaXMKICAgICAgICAgICAgICAgICAgICAg
ICAgdG1lbV9kZXN0cm95IHdoaWNoIERhbiBNYWdlbmhlaW1lciBzYXlzIGlzCiAgICAgICAgICAg
ICAgICAgICAgICAgIG9ic29sZXRlIGFuZCBjYW4ganVzdCBiZSByZW1vdmVkLgogICAgICAgICAg
ICAgICAgICAgICAgKiBsaWJ4bF9mb3JrIC0tIElhbkoncyBldmVudCBzZXJpZXMgcmVtb3ZlcyBh
bGwKICAgICAgICAgICAgICAgICAgICAgICAgdXNlcnMgb2YgdGhpcy4KICAgICAgKiBbQlVHXSBN
YW51YWxseSBiYWxsb29uaW5nIGRvbTAuICB4bCBtZW0tc2V0IDAgW2Zvb10gZmFpbHMgd2l0aAog
ICAgICAgICJsaWJ4bDogZXJyb3I6IGxpYnhsLmM6MjU2OTpsaWJ4bF9zZXRfbWVtb3J5X3Rhcmdl
dDogY2Fubm90IGdldAogICAgICAgIG1lbW9yeSBpbmZvIGZyb20gL2xvY2FsL2RvbWFpbi8wL21l
bW9yeS9zdGF0aWMtbWF4OiBObyBzdWNoIGZpbGUKICAgICAgICBvciBkaXJlY3RvcnkiLiBUaGlz
IG1pZ2h0IGJlIHN1aXRhYmxlIGZvciBhbiBlbnRodXNpYXN0aWMKICAgICAgICBvbi1sb29rZXIu
IChHZW9yZ2UgRHVubGFwLCBpbiB0aGUgYWJzZW5jZSBvZiBzYWlkIG9ubG9va2VyKQogICAgICAq
IHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKICAgICAgICAgICAgICAqIE5vbmUgcmVtYWluaW5n
PwogICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hl
cyBhbHJlYWR5IGluCiAgICAgICAgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11
bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KICAgICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwu
CiAgICAgICogRG9tYWluIDAgYmxvY2sgYXR0YWNoICYgZ2VuZXJhbCBob3RwbHVnIHdoZW4gdXNp
bmcgcWRpc2sgYmFja2VuZAogICAgICAgIChuZWVkIHRvIHN0YXJ0IHFlbXUgYXMgbmVjZXNzYXJ5
IGV0YykgKFN0ZWZhbm8gUywgcGF0Y2hlcwogICAgICAgIHBvc3RlZCkKICAgICAgKiBmaWxlOi8v
IGJhY2tlbmQgcGVyZm9ybWFuY2UuCiAgICAgICAgICAgICAgKiBxZW11LXhlbi10cmFkaXRpb25h
bCBhbmQgdXBzdHJlYW0gcWVtdS14ZW4gcGVyZm9ybWFuY2UKICAgICAgICAgICAgICAgIGhhcyBi
ZWVuIGltcHJvdmVkIGFuZCBpcyBub3cgc2F0aXNmYWN0b3J5LgogICAgICAgICAgICAgICogWGVu
IDQuMiB3aWxsIHByZWZlciBibGt0YXAyIGlmIGEga2VybmVsIG1vZHVsZSBpcwogICAgICAgICAg
ICAgICAgYXZhaWxhYmxlIChlLmcuIG9sZGVyIGRvbTAga2VybmVsIG9yIERLTVMgcHJvdmlkZWQK
ICAgICAgICAgICAgICAgIGtlcm5lbCBtb2R1bGUpIGFuZCB3aWxsIGZhbGxiYWNrIHRvIHFlbXUg
cWRpc2sgaWYgbm8KICAgICAgICAgICAgICAgIGJsa3RhcDIgaXMgYXZhaWxhYmxlLgogICAgICAg
ICAgICAgICogVGhlcmUgd2lsbCBiZSBubyB1c2Vyc3BhY2UgImJsa3RhcDMiIGZvciBYZW4gNC4y
CiAgICAgICogSW1wcm92ZWQgSG90cGx1ZyBzY3JpcHQgc3VwcG9ydCAoUm9nZXIgUGF1IE1vbm7D
qSwgcGF0Y2hlcwogICAgICAgIHBvc3RlZCkKICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAt
LSBmb2xsb3dzIG9uIGZyb20gaG90cGx1ZyBzY3JpcHQgKFJvZ2VyCiAgICAgICAgUGF1IE1vbm7D
qSkKCmh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKICAgICAgKiBzb2xpZCBpbXBsZW1lbnRhdGlv
biBvZiBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCiAgICAgICAgcXVldWVz
KSAoVGltIERlZWdhbiwgT2xhZiBIZXJyaW5nIGV0IGFsIC0tIHBhdGNoZXMgcG9zdGVkKQogICAg
ICAgICAgICAgICogIlRoZSBsYXN0IHBhdGNoIHRvIHVzZSBhIHdhaXRxdWV1ZSBpbgogICAgICAg
ICAgICAgICAgX19nZXRfZ2ZuX3R5cGVfYWNjZXNzKCkgZnJvbSBUaW0gd29ya3MuICBIb3dldmVy
LCB0aGVyZQogICAgICAgICAgICAgICAgYXJlIGEgZmV3IHVzZXJzIHdobyBjYWxsIF9fZ2V0X2dm
bl90eXBlX2FjY2VzcyB3aXRoIHRoZQogICAgICAgICAgICAgICAgZG9tYWluX2xvY2sgaGVsZC4g
VGhpcyBwYXJ0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpbgogICAgICAgICAgICAgICAgc29tZSB3
YXkuIgogICAgICAqIFNoYXJpbmcgc3VwcG9ydCBmb3IgQU1EIChUaW0sIEFuZHJlcykuCiAgICAg
ICogUG9EIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyAoR2VvcmdlIER1bmxhcCkKCkl0IHNlZW1z
IHRoYXQgbm9uZSBvZiB0aGUgYWJvdmUgYXJlIGdvaW5nIHRvIGhhcHBlbiBmb3IgNC4yPwoKdG9v
bHMsIG5pY2UgdG8gaGF2ZToKICAgICAgKiBDb25maWd1cmUvY29udHJvbCBwYWdpbmcgdmlhIHhs
L2xpYnhsIChPbGFmIEhlcnJpbmcsIGxvdHMgb2YKICAgICAgICBkaXNjdXNzaW9uIGFyb3VuZCBp
bnRlcmZhY2UsIGdlbmVyYWwgY29uc2Vuc3VzIHJlYWNoZWQgb24gd2hhdAogICAgICAgIGl0IHNo
b3VsZCBsb29rIGxpa2UuIE9sYWYgaGFzIGxldCBtZSBrbm93IHRoYXQgaGUgaXMgcHJvYmFibHkK
ICAgICAgICBub3QgZ29pbmcgdG8gaGF2ZSB0aW1lIHRvIGRvIHRoaXMgZm9yIDQuMiwgd2lsbCBs
aWtlbHkgc2xpcCB0bwogICAgICAgIDQuMyB1bmxlc3Mgc29tZW9uZSBlbHNlIHdhbnQgdG8gcGlj
ayB1cCB0aGF0IHdvcmspCiAgICAgICogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6CiAg
ICAgICAgICAgICAgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRo
b255IFBlcmFyZCwKICAgICAgICAgICAgICAgIHBhdGNoZXMgc2VudCkKICAgICAgICAgICAgICAq
IFVwc3RyZWFtIHFlbXUgc2F2ZSByZXN0b3JlIChBbnRob255IFBlcmFyZCwgU3RlZmFubwogICAg
ICAgICAgICAgICAgU3RhYmVsbGluaSwgcWVtdSBwYXRjaGVzIGFwcGxpZWQsIHdhaXRpbmcgZm9y
IGxpYnhsIGV0YwogICAgICAgICAgICAgICAgc2lkZSB3aGljaCBoYXMgYmVlbiByZWNlbnRseSBy
ZXBvc3RlZCkKICAgICAgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24uIEN1cnJlbnRseSAiZXhwZXJp
bWVudGFsIi4gTGlrZWx5IHRvCiAgICAgICAgcmVsZWFzZSB0aGF0IHdheS4KICAgICAgICAgICAg
ICAqIE5lc3RlZCBTVk0uIFRlc3RlZCBpbiBhIHZhcmlldHkgb2YgY29uZmlndXJhdGlvbnMgYnV0
CiAgICAgICAgICAgICAgICBzdGlsbCBzb21lIGlzc3VlcyB3aXRoIHRoZSBtb3N0IGltcG9ydGFu
dCB1c2UgY2FzZSAodzcKICAgICAgICAgICAgICAgIFhQIG1vZGUpIFswXSAgKENocmlzdG9waCBF
Z2dlcikKICAgICAgICAgICAgICAqIE5lc3RlZCBWTVguIE5lZWRzIG5lc3RlZCBFUFQgdG8gYmUg
Z2VudWluZWx5IHVzZWZ1bC4KICAgICAgICAgICAgICAgIE5lZWQgbW9yZSBkYXRhIG9uIHRlc3Rl
ZG5lc3MgZXRjIChJbnRlbCkKICAgICAgKiBJbml0aWFsIHhsIHN1cHBvcnQgZm9yIFJlbXVzICht
ZW1vcnkgY2hlY2twb2ludCwgYmxhY2tob2xpbmcpCiAgICAgICAgKFNocmlyYW0sIHdhaXRpbmcg
b24gbGlieGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9yZSkKICAgICAgKiB4bCBj
b21wYXRpYmlsaXR5IHdpdGggeG06CiAgICAgICAgICAgICAgKiB4bCBzdXBwb3J0IGZvciBhdXRv
c3Bhd25pbmcgdm5jdmlld2VyICh2bmN2aWV3ZXI9MSBvcgogICAgICAgICAgICAgICAgb3RoZXJ3
aXNlKSAoR29uY2FsbyBHb21lcywgd2FpdGluZyBvbiBuZXcgdmVyc2lvbiBvZgogICAgICAgICAg
ICAgICAgcGF0Y2hlcykKICAgICAgICAgICAgICAqIHN1cHBvcnQgZm9yIHZpZiAicmF0ZSIgcGFy
YW1ldGVyIChNYXRoaWV1IEdhZ27DqSwgd2FpdGluZwogICAgICAgICAgICAgICAgb24gbmV3IHZl
cnNpb24gb2YgcGF0Y2hlcykKICAgICAgICAgICAgICAqIGV4cG9zZSBQQ0kgYmFjayAicGVybWlz
c2l2ZSIgcGFyYW1ldGVyIChHZW9yZ2UgRHVubGFwLAogICAgICAgICAgICAgICAgRE9ORSkKClsw
XSBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAzL21z
ZzAwODgzLmh0bWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:32:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkA0-0003Gb-Dk; Mon, 16 Apr 2012 11:31:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJk9y-0003GW-PW
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:31:55 +0000
Received: from [85.158.143.35:29251] by server-2.bemta-4.messagelabs.com id
	99/71-17550-A230C8F4; Mon, 16 Apr 2012 11:31:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334575913!12603000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25617 invoked from network); 16 Apr 2012 11:31:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:31:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11953250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:31:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:31:52 +0100
Message-ID: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 12:31:50 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt
bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv
bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg
ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKTWlkL0xhdGUgQXByaWwgIC0t
IEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCBp
dCBpcyByZWFkeQoKVGhlIHVwZGF0ZWQgVE9ETyBsaXN0IGZvbGxvd3MuIFBlciB0aGUgcmVsZWFz
ZSBwbGFuIGEgc3Ryb25nIGNhc2Ugd2lsbApub3cgaGF2ZSB0byBiZSBtYWRlIGFzIHRvIHdoeSBu
ZXcgaXRlbXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0LAplc3BlY2lhbGx5IGFzIGEgYmxv
Y2tlciwgcmF0aGVyIHRoYW4gZGVmZXJyZWQgdG8gNC4zLgoKV2UgaGF2ZSBub3cgZW50ZXJlZCBG
ZWF0dXJlIEZyZWV6ZS4gUGF0Y2hlcyB3aGljaCBoYXZlIGJlZW4gcG9zdGVkCmJlZm9yZSBvciB3
aGljaCBhZGRyZXNzIHNvbWV0aGluZyBvbiB0aGUgbGlzdCBiZWxvdyBhcmUgc3RpbGwgYWNjZXB0
YWJsZQooZm9yIG5vdywgd2Ugd2lsbCBncmFkdWFsbHkgYmUgZ2V0dGluZyBzdHJpY3RlciBhYm91
dCB0aGlzKSwgZXZlcnl0aGluZwplbHNlIHdpbGwgYmUgZGVmZXJyZWQgdW50aWwgNC4zIGJ5IGRl
ZmF1bHQuCgpBIGJ1bmNoIG9mIG5ldyBpdGVtcyBoYXZlIGJlZW4gYWRkZWQgdG8gdGhlIGxpc3Qs
IG1haW5seSBkdWUgdG8gSWFuCkphY2tzb25zIHJldmlldyBvZiB0aGUgbGlieGwgQVBJIGZvciBz
dGFiaWxpdHkuIEkgYmVsaWV2ZSB0aGVzZSBhcmUKbW9zdGx5IHVuZGVyIGNvbnRyb2wuIFNvbWUg
b2YgdGhlc2UgYXJlIGdvaW5nIHRvIGJlIGltbWVkaWF0ZWx5IGRlZmVycmVkCnRvIDQuMyBidXQg
SSBoYXZlIGluY2x1ZGVkIHRoZW0gaW4gdGhpcyB3ZWVrJ3MgbGlzdCB0byBhbGxvdyB0aGUKb3Bw
b3J0dW5pdHkgZm9yIGZlZWRiYWNrLgoKU29tZSBvZiB0aGUgbmV3IGl0ZW1zIGFyZSB1bmNsYWlt
ZWQuIFZvbHVudGVlcnMgd291bGQgYmUgbXVjaAphcHByZWNpYXRlZC4KCkFzIGRpc2N1c3NlZCBs
YXN0IHdlZWsgSSBoYXZlIGFkZGVkIGtub3duIGJ1Z3MgdG8gdGhlIGxpc3RzIGJlbG93LgpQbGVh
c2UgcmVmZXIgbWUgdG8gYW55IHNob3VsZCBvciBtdXN0IGJlIGZpeGVkIGJ1Z3MgKGJlc3Qgd2F5
IGl0IGJ5CnJlc3BvbmRpbmcgdG8gdGhpcyBtYWlsIHdpdGggYSBwb2ludGVyIHNvIG15IHRocmVh
ZGluZyBtYWlsZXIgd2lsbCB0cmFjawppdCBmb3IgbmV4dCB3ZWVrKS4KCmh5cGVydmlzb3IsIGJs
b2NrZXJzOgogICAgICAqIFtCVUddIFpvbWJpZSBkcml2ZXIgZG9tYWlucy4gIFRoZXJlJ3MgYSBi
dWcgd2hlcmUgUFYgZ3Vlc3RzIHdpdGgKICAgICAgICBkZXZpY2VzIHBhc3NlZCB0aHJvdWdoIHdp
dGggeGwgaGFuZyBhcm91bmQgYXMgInpvbWJpZXMiLCB3aXRoCiAgICAgICAgb25lIG91dHN0YW5k
aW5nIHBhZ2UgcmVmZXJlbmNlLiAgSSB0aGluayB0aGlzIHNob3VsZCByZWFsbHkgYmUgYQogICAg
ICAgIGJsb2NrZXIuIEknbSB3b3JraW5nIG9uIHRoaXMgYXQgdGhlIG1vbWVudCAoR2VvcmdlIER1
bmxhcCkuCiAgICAgICAgICAgICAgKiBPbmUgb2Ygc2V2ZXJhbCByZWNlbnQgcmVwb3J0cyBvZiBa
b21iaWUgZG9tYWlucywgd2hpY2gKICAgICAgICAgICAgICAgIG1heSBvciBtYXkgbm90IGJlIGFs
bCByZWxhdGVkLgogICAgICAgICAgICAgICogTGlzdCBhcyBoeXBlcnZpc29yIGZvciBub3csIGJ1
dCBtYXkgdHVybiBvdXQgdG8gYmUgYQogICAgICAgICAgICAgICAgdG9vbHMgaXNzdWUuCiAKdG9v
bHMsIGJsb2NrZXJzOgogICAgICAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0
LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQogICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4g
c3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YKICAgICAgICB0aGlzIGFy
ZToKICAgICAgICAgICAgICAqIFNhZmUgZm9yayB2cy4gZmQgaGFuZGxpbmcgaG9va3MuIEludm9s
dmVzIEFQSSBjaGFuZ2VzCiAgICAgICAgICAgICAgICAoSWFuIEosIHBhdGNoZXMgcG9zdGVkKQog
ICAgICAgICAgICAgICogbG9ja2luZy9zZXJpYWxpemF0aW9uLCBlLmcuLCBmb3IgZG9tYWluIGNy
ZWF0aW9uLiBbLi4uXQogICAgICAgICAgICAgICAgICAgICAgKiBEZWZlcnJlZCB1bnRpbCA0LjMu
IFdlIHRoaW5rIHRoaXMgZnVuY3Rpb25hbGl0eQogICAgICAgICAgICAgICAgICAgICAgICBjYW4g
YmUgYWRkZWQgd2l0aG91dCBpbXBhY3RpbmcgQVBJIHN0YWJpbGl0eS4KICAgICAgICAgICAgICAq
IGxpYnhsX3dhaXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQu
CiAgICAgICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8K
ICAgICAgICAgICAgICAgIGxvY2tpbmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUg
KHNlZSBhYm92ZSkuCiAgICAgICAgICAgICAgICBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMg
aW50ZXJmYWNlIGJlaW5nIHN1YnN0YW5kYXJkCiAgICAgICAgICAgICAgICBidXQgb3RoZXJ3aXNl
IGRlZmVyIHRvIDQuMy4KICAgICAgICAgICAgICAqIGxpYnhsX3tGT099X2V4ZWMuIFNob3VsZCBy
ZXR1cm4gYSBkYXRhIHN0cnVjdHVyZQogICAgICAgICAgICAgICAgZGVjbGFyaW5nIHdoYXQgdG8g
ZG8sIG5vdCBmb3JrIGFuZCBleGVjIHRoZW1zZWx2ZXMuCiAgICAgICAgICAgICAgICBIb3dldmVy
IHdlIGNhbiBkZWZlciB0aGlzIHVudGlsIDQuMy4KICAgICAgICAgICAgICAqIGxpYnhsXypfcGF0
aC4gTWFqb3JpdHkgbWFkZSBpbnRlcm5hbCwgb25seSBjb25maWdkaXIgYW5kCiAgICAgICAgICAg
ICAgICBsb2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVzZWQgYnkgeGwpLiBHb29kIGVub3VnaD8KICAg
ICAgICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6CiAgICAg
ICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9zdXNwZW5kLiBOb2JvZHkgaGFzIGxvb2tl
ZCBhdCB0aGVzZQogICAgICAgICAgICAgICAgICAgICAgICBhdCBhbGwuIEEgdm9sdW50ZWVyIHdv
dWxkIGJlIGFwcHJlY2lhdGVkLgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5f
Y3JlYXRlX3tuZXcscmVzdG9yZX0gLS0gSWFuSiBoYXMKICAgICAgICAgICAgICAgICAgICAgICAg
cGF0Y2hlcyBhcyBwYXJ0IG9mIGV2ZW50IHNlcmllcy4KICAgICAgICAgICAgICAgICAgICAgICog
bGlieGxfZG9tYWluX3tzaHV0ZG93bixyZWJvb3R9LiBUaGVzZSBhcmUgImZhc3QiCiAgICAgICAg
ICAgICAgICAgICAgICAgIGZ1bmN0aW9ucyBhbmQgdGhlcmUgZG8gbm90IG5lZWQgdG8gYmUgYXN5
bmMuCiAgICAgICAgICAgICAgICAgICAgICAgIChTbywgRE9ORSB3aXRoIG5vIGFjdGlvbiByZXF1
aXJlZCkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZG9tYWluX2NvcmVfZHVtcC4gQ2Fu
IHRha2UgYSBkdW1teSBhb19ob3cKICAgICAgICAgICAgICAgICAgICAgICAgYW5kIHJlbWFpbiBz
eW5jaHJvbm91cyBpbnRlcm5hbGx5LgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kZXZp
Y2Vfe2Rpc2ssbmljLHZrYixhZGR9X2FkZCAoYW5kCiAgICAgICAgICAgICAgICAgICAgICAgIHJl
bW92ZT8pLiBSb2dlciBQYXUgTW9ubsOpIGZpeGVzIGRpc2sgYXMgcGFydCBvZgogICAgICAgICAg
ICAgICAgICAgICAgICBob3RwbHVnIHNjcmlwdCBzZXJpZXMgYW5kIGFkZHMgaW5mcmFzdHJ1Y3R1
cmUKICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggc2hvdWxkIG1ha2UgdGhlIG90aGVycyB0
cml2aWFsLgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9jZHJvbV9pbnNlcnQuIFNob3Vs
ZCBiZSBlYXN5IG9uY2UKICAgICAgICAgICAgICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0g
ZG9uZSwgSWFuSiB0byBsb29rIGF0LgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kZXZp
Y2VfZGlza19sb2NhbF97YXR0YWNoLGRldGFjaH0uIEJlY29tZQogICAgICAgICAgICAgICAgICAg
ICAgICBpbnRlcm5hbCBhcyBwYXJ0IG9mIFN0ZWZhbm8ncyBkb21haW4gMCBkaXNrCiAgICAgICAg
ICAgICAgICAgICAgICAgIGF0dGFjaCBzZXJpZXMuCiAgICAgICAgICAgICAgICAgICAgICAqIGxp
YnhsX2RldmljZV9wY2lfe2FkZCxyZW1vdmV9LiBMZXNzIHRyaXZpYWwgdGhhbgogICAgICAgICAg
ICAgICAgICAgICAgICB0aGUgb3RoZXJzLiBBIHZvbHVudGVlciB3b3VsZCBiZSBhcHByZWNpYXRl
ZC4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfeGVuX2NvbnNvbGVfKi4gTm8gaW50ZXJm
YWNlIGZvciB3YWl0aW5nCiAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBlYWNoIGNhbGwganVz
dCBkdW1wcyBhIGJpdCBtb3JlIG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICByaW5nICwg
c28gaXMgZmFzdC4gTm90aGluZyB0byBkbyBoZXJlICh0aGVyZWZvcmUKICAgICAgICAgICAgICAg
ICAgICAgICAgRE9ORSkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfeGVuX3RtZW1fKi4g
QWxsIGZ1bmN0aW9ucyBhcmUgImZhc3QiIGFuZAogICAgICAgICAgICAgICAgICAgICAgICB0aGVy
ZWZvcmUgbm8gYXN5bmMgbmVlZGVkLiBFeGNlcHRpb24gaXMKICAgICAgICAgICAgICAgICAgICAg
ICAgdG1lbV9kZXN0cm95IHdoaWNoIERhbiBNYWdlbmhlaW1lciBzYXlzIGlzCiAgICAgICAgICAg
ICAgICAgICAgICAgIG9ic29sZXRlIGFuZCBjYW4ganVzdCBiZSByZW1vdmVkLgogICAgICAgICAg
ICAgICAgICAgICAgKiBsaWJ4bF9mb3JrIC0tIElhbkoncyBldmVudCBzZXJpZXMgcmVtb3ZlcyBh
bGwKICAgICAgICAgICAgICAgICAgICAgICAgdXNlcnMgb2YgdGhpcy4KICAgICAgKiBbQlVHXSBN
YW51YWxseSBiYWxsb29uaW5nIGRvbTAuICB4bCBtZW0tc2V0IDAgW2Zvb10gZmFpbHMgd2l0aAog
ICAgICAgICJsaWJ4bDogZXJyb3I6IGxpYnhsLmM6MjU2OTpsaWJ4bF9zZXRfbWVtb3J5X3Rhcmdl
dDogY2Fubm90IGdldAogICAgICAgIG1lbW9yeSBpbmZvIGZyb20gL2xvY2FsL2RvbWFpbi8wL21l
bW9yeS9zdGF0aWMtbWF4OiBObyBzdWNoIGZpbGUKICAgICAgICBvciBkaXJlY3RvcnkiLiBUaGlz
IG1pZ2h0IGJlIHN1aXRhYmxlIGZvciBhbiBlbnRodXNpYXN0aWMKICAgICAgICBvbi1sb29rZXIu
IChHZW9yZ2UgRHVubGFwLCBpbiB0aGUgYWJzZW5jZSBvZiBzYWlkIG9ubG9va2VyKQogICAgICAq
IHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKICAgICAgICAgICAgICAqIE5vbmUgcmVtYWluaW5n
PwogICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hl
cyBhbHJlYWR5IGluCiAgICAgICAgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11
bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KICAgICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwu
CiAgICAgICogRG9tYWluIDAgYmxvY2sgYXR0YWNoICYgZ2VuZXJhbCBob3RwbHVnIHdoZW4gdXNp
bmcgcWRpc2sgYmFja2VuZAogICAgICAgIChuZWVkIHRvIHN0YXJ0IHFlbXUgYXMgbmVjZXNzYXJ5
IGV0YykgKFN0ZWZhbm8gUywgcGF0Y2hlcwogICAgICAgIHBvc3RlZCkKICAgICAgKiBmaWxlOi8v
IGJhY2tlbmQgcGVyZm9ybWFuY2UuCiAgICAgICAgICAgICAgKiBxZW11LXhlbi10cmFkaXRpb25h
bCBhbmQgdXBzdHJlYW0gcWVtdS14ZW4gcGVyZm9ybWFuY2UKICAgICAgICAgICAgICAgIGhhcyBi
ZWVuIGltcHJvdmVkIGFuZCBpcyBub3cgc2F0aXNmYWN0b3J5LgogICAgICAgICAgICAgICogWGVu
IDQuMiB3aWxsIHByZWZlciBibGt0YXAyIGlmIGEga2VybmVsIG1vZHVsZSBpcwogICAgICAgICAg
ICAgICAgYXZhaWxhYmxlIChlLmcuIG9sZGVyIGRvbTAga2VybmVsIG9yIERLTVMgcHJvdmlkZWQK
ICAgICAgICAgICAgICAgIGtlcm5lbCBtb2R1bGUpIGFuZCB3aWxsIGZhbGxiYWNrIHRvIHFlbXUg
cWRpc2sgaWYgbm8KICAgICAgICAgICAgICAgIGJsa3RhcDIgaXMgYXZhaWxhYmxlLgogICAgICAg
ICAgICAgICogVGhlcmUgd2lsbCBiZSBubyB1c2Vyc3BhY2UgImJsa3RhcDMiIGZvciBYZW4gNC4y
CiAgICAgICogSW1wcm92ZWQgSG90cGx1ZyBzY3JpcHQgc3VwcG9ydCAoUm9nZXIgUGF1IE1vbm7D
qSwgcGF0Y2hlcwogICAgICAgIHBvc3RlZCkKICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAt
LSBmb2xsb3dzIG9uIGZyb20gaG90cGx1ZyBzY3JpcHQgKFJvZ2VyCiAgICAgICAgUGF1IE1vbm7D
qSkKCmh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKICAgICAgKiBzb2xpZCBpbXBsZW1lbnRhdGlv
biBvZiBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCiAgICAgICAgcXVldWVz
KSAoVGltIERlZWdhbiwgT2xhZiBIZXJyaW5nIGV0IGFsIC0tIHBhdGNoZXMgcG9zdGVkKQogICAg
ICAgICAgICAgICogIlRoZSBsYXN0IHBhdGNoIHRvIHVzZSBhIHdhaXRxdWV1ZSBpbgogICAgICAg
ICAgICAgICAgX19nZXRfZ2ZuX3R5cGVfYWNjZXNzKCkgZnJvbSBUaW0gd29ya3MuICBIb3dldmVy
LCB0aGVyZQogICAgICAgICAgICAgICAgYXJlIGEgZmV3IHVzZXJzIHdobyBjYWxsIF9fZ2V0X2dm
bl90eXBlX2FjY2VzcyB3aXRoIHRoZQogICAgICAgICAgICAgICAgZG9tYWluX2xvY2sgaGVsZC4g
VGhpcyBwYXJ0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpbgogICAgICAgICAgICAgICAgc29tZSB3
YXkuIgogICAgICAqIFNoYXJpbmcgc3VwcG9ydCBmb3IgQU1EIChUaW0sIEFuZHJlcykuCiAgICAg
ICogUG9EIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyAoR2VvcmdlIER1bmxhcCkKCkl0IHNlZW1z
IHRoYXQgbm9uZSBvZiB0aGUgYWJvdmUgYXJlIGdvaW5nIHRvIGhhcHBlbiBmb3IgNC4yPwoKdG9v
bHMsIG5pY2UgdG8gaGF2ZToKICAgICAgKiBDb25maWd1cmUvY29udHJvbCBwYWdpbmcgdmlhIHhs
L2xpYnhsIChPbGFmIEhlcnJpbmcsIGxvdHMgb2YKICAgICAgICBkaXNjdXNzaW9uIGFyb3VuZCBp
bnRlcmZhY2UsIGdlbmVyYWwgY29uc2Vuc3VzIHJlYWNoZWQgb24gd2hhdAogICAgICAgIGl0IHNo
b3VsZCBsb29rIGxpa2UuIE9sYWYgaGFzIGxldCBtZSBrbm93IHRoYXQgaGUgaXMgcHJvYmFibHkK
ICAgICAgICBub3QgZ29pbmcgdG8gaGF2ZSB0aW1lIHRvIGRvIHRoaXMgZm9yIDQuMiwgd2lsbCBs
aWtlbHkgc2xpcCB0bwogICAgICAgIDQuMyB1bmxlc3Mgc29tZW9uZSBlbHNlIHdhbnQgdG8gcGlj
ayB1cCB0aGF0IHdvcmspCiAgICAgICogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6CiAg
ICAgICAgICAgICAgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRo
b255IFBlcmFyZCwKICAgICAgICAgICAgICAgIHBhdGNoZXMgc2VudCkKICAgICAgICAgICAgICAq
IFVwc3RyZWFtIHFlbXUgc2F2ZSByZXN0b3JlIChBbnRob255IFBlcmFyZCwgU3RlZmFubwogICAg
ICAgICAgICAgICAgU3RhYmVsbGluaSwgcWVtdSBwYXRjaGVzIGFwcGxpZWQsIHdhaXRpbmcgZm9y
IGxpYnhsIGV0YwogICAgICAgICAgICAgICAgc2lkZSB3aGljaCBoYXMgYmVlbiByZWNlbnRseSBy
ZXBvc3RlZCkKICAgICAgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24uIEN1cnJlbnRseSAiZXhwZXJp
bWVudGFsIi4gTGlrZWx5IHRvCiAgICAgICAgcmVsZWFzZSB0aGF0IHdheS4KICAgICAgICAgICAg
ICAqIE5lc3RlZCBTVk0uIFRlc3RlZCBpbiBhIHZhcmlldHkgb2YgY29uZmlndXJhdGlvbnMgYnV0
CiAgICAgICAgICAgICAgICBzdGlsbCBzb21lIGlzc3VlcyB3aXRoIHRoZSBtb3N0IGltcG9ydGFu
dCB1c2UgY2FzZSAodzcKICAgICAgICAgICAgICAgIFhQIG1vZGUpIFswXSAgKENocmlzdG9waCBF
Z2dlcikKICAgICAgICAgICAgICAqIE5lc3RlZCBWTVguIE5lZWRzIG5lc3RlZCBFUFQgdG8gYmUg
Z2VudWluZWx5IHVzZWZ1bC4KICAgICAgICAgICAgICAgIE5lZWQgbW9yZSBkYXRhIG9uIHRlc3Rl
ZG5lc3MgZXRjIChJbnRlbCkKICAgICAgKiBJbml0aWFsIHhsIHN1cHBvcnQgZm9yIFJlbXVzICht
ZW1vcnkgY2hlY2twb2ludCwgYmxhY2tob2xpbmcpCiAgICAgICAgKFNocmlyYW0sIHdhaXRpbmcg
b24gbGlieGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9yZSkKICAgICAgKiB4bCBj
b21wYXRpYmlsaXR5IHdpdGggeG06CiAgICAgICAgICAgICAgKiB4bCBzdXBwb3J0IGZvciBhdXRv
c3Bhd25pbmcgdm5jdmlld2VyICh2bmN2aWV3ZXI9MSBvcgogICAgICAgICAgICAgICAgb3RoZXJ3
aXNlKSAoR29uY2FsbyBHb21lcywgd2FpdGluZyBvbiBuZXcgdmVyc2lvbiBvZgogICAgICAgICAg
ICAgICAgcGF0Y2hlcykKICAgICAgICAgICAgICAqIHN1cHBvcnQgZm9yIHZpZiAicmF0ZSIgcGFy
YW1ldGVyIChNYXRoaWV1IEdhZ27DqSwgd2FpdGluZwogICAgICAgICAgICAgICAgb24gbmV3IHZl
cnNpb24gb2YgcGF0Y2hlcykKICAgICAgICAgICAgICAqIGV4cG9zZSBQQ0kgYmFjayAicGVybWlz
c2l2ZSIgcGFyYW1ldGVyIChHZW9yZ2UgRHVubGFwLAogICAgICAgICAgICAgICAgRE9ORSkKClsw
XSBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAzL21z
ZzAwODgzLmh0bWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkAf-0003Ii-Ro; Mon, 16 Apr 2012 11:32:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SJkAe-0003IV-65
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:32:36 +0000
Received: from [85.158.143.35:34961] by server-1.bemta-4.messagelabs.com id
	21/DB-20925-3530C8F4; Mon, 16 Apr 2012 11:32:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334575954!11529147!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19518 invoked from network); 16 Apr 2012 11:32:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 11:32:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Apr 2012 12:32:33 +0100
Message-Id: <4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Apr 2012 12:32:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Tim Deegan <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> The sched clock was considered stable based on the capabilities of the
> underlying hardware.  This does not make sense for Xen PV guests as:
> a) the hardware TSC is not used directly as the clock source; and b)
> guests may migrate to hosts with different hardware capabilities.
> 
> It is not clear to me whether the Xen clock source is supposed to be
> stable and whether it should be stable across migration.  For a clock
> source to be stable it must be: a) monotonic; c) synchronized across
> CPUs; and c) constant rate.
> 
> There have also been reports of systems with apparently unstable
> clocks where clearing sched_clock_stable has fixed problems with
> migrated VMs hanging.
> 
> So, always set the sched clock as unstable when using the Xen clock
> source.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..8469b5a 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>  	do_settimeofday(&tp);
>  
>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> +	sched_clock_stable = 0;

This, unfortunately, is not sufficient afaict: If a CPU gets brought up
post-boot, the variable may need to be cleared again. Instead you
ought to call mark_tsc_unstable().

Jan

>  
>  	xen_setup_runstate_info(cpu);
>  	xen_setup_timer(cpu);
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkAf-0003Ii-Ro; Mon, 16 Apr 2012 11:32:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SJkAe-0003IV-65
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:32:36 +0000
Received: from [85.158.143.35:34961] by server-1.bemta-4.messagelabs.com id
	21/DB-20925-3530C8F4; Mon, 16 Apr 2012 11:32:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334575954!11529147!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19518 invoked from network); 16 Apr 2012 11:32:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 11:32:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Apr 2012 12:32:33 +0100
Message-Id: <4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Apr 2012 12:32:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Tim Deegan <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> The sched clock was considered stable based on the capabilities of the
> underlying hardware.  This does not make sense for Xen PV guests as:
> a) the hardware TSC is not used directly as the clock source; and b)
> guests may migrate to hosts with different hardware capabilities.
> 
> It is not clear to me whether the Xen clock source is supposed to be
> stable and whether it should be stable across migration.  For a clock
> source to be stable it must be: a) monotonic; c) synchronized across
> CPUs; and c) constant rate.
> 
> There have also been reports of systems with apparently unstable
> clocks where clearing sched_clock_stable has fixed problems with
> migrated VMs hanging.
> 
> So, always set the sched clock as unstable when using the Xen clock
> source.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..8469b5a 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>  	do_settimeofday(&tp);
>  
>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> +	sched_clock_stable = 0;

This, unfortunately, is not sufficient afaict: If a CPU gets brought up
post-boot, the variable may need to be cleared again. Instead you
ought to call mark_tsc_unstable().

Jan

>  
>  	xen_setup_runstate_info(cpu);
>  	xen_setup_timer(cpu);
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:45:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkMq-0003ZD-5I; Mon, 16 Apr 2012 11:45:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SJkMp-0003Z8-8d
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 11:45:11 +0000
Received: from [85.158.143.99:59373] by server-3.bemta-4.messagelabs.com id
	7B/60-05853-6460C8F4; Mon, 16 Apr 2012 11:45:10 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334576708!22919566!1
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8368 invoked from network); 16 Apr 2012 11:45:08 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-13.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 11:45:08 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp209.alice.it (8.6.023.02)
	id 4EF08A630CEF5512 for xen-devel@lists.xensource.com;
	Mon, 16 Apr 2012 13:45:07 +0200
Message-ID: <4F8C0641.6030206@tiscali.it>
Date: Mon, 16 Apr 2012 13:45:05 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2565754811198684334=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2565754811198684334==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020407080003000004010906"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020407080003000004010906
Content-Type: multipart/mixed;
 boundary="------------060804010308080407010308"

This is a multi-part message in MIME format.
--------------060804010308080407010308
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1334565174 -7200
# Node ID a9c00a9b48c708a8e448bf5d9cd96026721fbf2f
# Parent  6b72eb3b40cf2b3d5a6c75d68fa7093c57fc0d1f
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 6b72eb3b40cf -r a9c00a9b48c7 Makefile
--- a/Makefile    ven apr 13 17:13:01 2012 +0100
+++ b/Makefile    lun apr 16 10:32:54 2012 +0200
@@ -220,13 +220,12 @@
  uninstall: D=3D$(DESTDIR)
  uninstall:
      [ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR)=20
$(D)$(XEN_CONFIG_DIR).old-`date +%s` || true
-    rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+    rm -rf $(D)$(CONFIG_DIR)/init.d/xen*
      rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
      rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+    rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
      rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
      rm -rf $(D)/boot/*xen*
      rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +235,16 @@
      rm -rf $(D)$(BINDIR)/pygrub
      rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
      rm -rf $(D)$(BINDIR)/xsls
-    rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+    rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+    rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+    rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+    rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
      rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
      rm -rf $(D)$(INCLUDEDIR)/xen
+    rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+    rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
      rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-    rm -rf $(D)$(LIBDIR)/libxenstore*
+    rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
      rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
      rm -rf $(D)$(LIBDIR)/xen/
      rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +252,7 @@
      rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
      rm -rf $(D)$(SHAREDIR)/doc/xen
      rm -rf $(D)$(SHAREDIR)/xen
+    rm -rf $(D)$(SHAREDIR)/qemu-xen
      rm -rf $(D)$(MAN1DIR)/xen*
      rm -rf $(D)$(MAN8DIR)/xen*
      rm -rf $(D)/boot/tboot*


--------------060804010308080407010308
Content-Type: text/plain; charset=windows-1252;
 name="make_uninstall_updates.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="make_uninstall_updates.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1334565174 -7200
# Node ID a9c00a9b48c708a8e448bf5d9cd96026721fbf2f
# Parent  6b72eb3b40cf2b3d5a6c75d68fa7093c57fc0d1f
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 6b72eb3b40cf -r a9c00a9b48c7 Makefile
--- a/Makefile	ven apr 13 17:13:01 2012 +0100
+++ b/Makefile	lun apr 16 10:32:54 2012 +0200
@@ -220,13 +220,12 @@
 uninstall: D=3D$(DESTDIR)
 uninstall:
 	[ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR) $(D)$(XEN_C=
ONFIG_DIR).old-`date +%s` || true
-	rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+	rm -rf $(D)$(CONFIG_DIR)/init.d/xen*
 	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
 	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+	rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
 	rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
 	rm -rf $(D)/boot/*xen*
 	rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +235,16 @@
 	rm -rf $(D)$(BINDIR)/pygrub
 	rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
 	rm -rf $(D)$(BINDIR)/xsls
-	rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+	rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+	rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+	rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+	rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
 	rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
 	rm -rf $(D)$(INCLUDEDIR)/xen
+	rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+	rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
 	rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-	rm -rf $(D)$(LIBDIR)/libxenstore*
+	rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
 	rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
 	rm -rf $(D)$(LIBDIR)/xen/
 	rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +252,7 @@
 	rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
 	rm -rf $(D)$(SHAREDIR)/doc/xen
 	rm -rf $(D)$(SHAREDIR)/xen
+	rm -rf $(D)$(SHAREDIR)/qemu-xen
 	rm -rf $(D)$(MAN1DIR)/xen*
 	rm -rf $(D)$(MAN8DIR)/xen*
 	rm -rf $(D)/boot/tboot*

--------------060804010308080407010308--

--------------ms020407080003000004010906
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQxNjExNDUwNVowIwYJKoZIhvcNAQkEMRYEFIb/g/AFla7lIe4GFxGTwQNX
4RNGMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQB9T5MCh0SgmbqvaHFBQYjzxHvM36u3Ng3FM8MNzH33
ewPvFqxpevSwwI3dXP+AAxmcD0eh7bOxC75t+JA6AEpHNaYDyiCLAp/PeIq8nQwuWy+QBX1W
fPs81ydBYA5ToiatoRsWkxSdy81blxzRQGq7dgAhRuoVyEFAMmuVxcB95axKRrg9TEMVq3SM
MUd5AhccWeRRdi037z3c5JLmcZ12lmEPKPCePGBSXZWsKoDdf86wKgSsvKLJqrmIjhXrEwWH
H1txvD8uxh1TRCwwbrSkELCdjdPB2EyYZLQTDlyIzplkyIr0lHMcXCj9JGZrYT9oMLB8/mzK
cqCHNWbZ5BILAAAAAAAA
--------------ms020407080003000004010906--


--===============2565754811198684334==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2565754811198684334==--


From xen-devel-bounces@lists.xen.org Mon Apr 16 11:45:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkMq-0003ZD-5I; Mon, 16 Apr 2012 11:45:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SJkMp-0003Z8-8d
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 11:45:11 +0000
Received: from [85.158.143.99:59373] by server-3.bemta-4.messagelabs.com id
	7B/60-05853-6460C8F4; Mon, 16 Apr 2012 11:45:10 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334576708!22919566!1
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8368 invoked from network); 16 Apr 2012 11:45:08 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-13.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 11:45:08 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp209.alice.it (8.6.023.02)
	id 4EF08A630CEF5512 for xen-devel@lists.xensource.com;
	Mon, 16 Apr 2012 13:45:07 +0200
Message-ID: <4F8C0641.6030206@tiscali.it>
Date: Mon, 16 Apr 2012 13:45:05 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2565754811198684334=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2565754811198684334==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020407080003000004010906"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020407080003000004010906
Content-Type: multipart/mixed;
 boundary="------------060804010308080407010308"

This is a multi-part message in MIME format.
--------------060804010308080407010308
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1334565174 -7200
# Node ID a9c00a9b48c708a8e448bf5d9cd96026721fbf2f
# Parent  6b72eb3b40cf2b3d5a6c75d68fa7093c57fc0d1f
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 6b72eb3b40cf -r a9c00a9b48c7 Makefile
--- a/Makefile    ven apr 13 17:13:01 2012 +0100
+++ b/Makefile    lun apr 16 10:32:54 2012 +0200
@@ -220,13 +220,12 @@
  uninstall: D=3D$(DESTDIR)
  uninstall:
      [ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR)=20
$(D)$(XEN_CONFIG_DIR).old-`date +%s` || true
-    rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+    rm -rf $(D)$(CONFIG_DIR)/init.d/xen*
      rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
      rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+    rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
      rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
      rm -rf $(D)/boot/*xen*
      rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +235,16 @@
      rm -rf $(D)$(BINDIR)/pygrub
      rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
      rm -rf $(D)$(BINDIR)/xsls
-    rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+    rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+    rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+    rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+    rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
      rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
      rm -rf $(D)$(INCLUDEDIR)/xen
+    rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+    rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
      rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-    rm -rf $(D)$(LIBDIR)/libxenstore*
+    rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
      rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
      rm -rf $(D)$(LIBDIR)/xen/
      rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +252,7 @@
      rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
      rm -rf $(D)$(SHAREDIR)/doc/xen
      rm -rf $(D)$(SHAREDIR)/xen
+    rm -rf $(D)$(SHAREDIR)/qemu-xen
      rm -rf $(D)$(MAN1DIR)/xen*
      rm -rf $(D)$(MAN8DIR)/xen*
      rm -rf $(D)/boot/tboot*


--------------060804010308080407010308
Content-Type: text/plain; charset=windows-1252;
 name="make_uninstall_updates.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="make_uninstall_updates.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1334565174 -7200
# Node ID a9c00a9b48c708a8e448bf5d9cd96026721fbf2f
# Parent  6b72eb3b40cf2b3d5a6c75d68fa7093c57fc0d1f
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 6b72eb3b40cf -r a9c00a9b48c7 Makefile
--- a/Makefile	ven apr 13 17:13:01 2012 +0100
+++ b/Makefile	lun apr 16 10:32:54 2012 +0200
@@ -220,13 +220,12 @@
 uninstall: D=3D$(DESTDIR)
 uninstall:
 	[ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR) $(D)$(XEN_C=
ONFIG_DIR).old-`date +%s` || true
-	rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+	rm -rf $(D)$(CONFIG_DIR)/init.d/xen*
 	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
 	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+	rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
 	rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
 	rm -rf $(D)/boot/*xen*
 	rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +235,16 @@
 	rm -rf $(D)$(BINDIR)/pygrub
 	rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
 	rm -rf $(D)$(BINDIR)/xsls
-	rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+	rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+	rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+	rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+	rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
 	rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
 	rm -rf $(D)$(INCLUDEDIR)/xen
+	rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+	rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
 	rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-	rm -rf $(D)$(LIBDIR)/libxenstore*
+	rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
 	rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
 	rm -rf $(D)$(LIBDIR)/xen/
 	rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +252,7 @@
 	rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
 	rm -rf $(D)$(SHAREDIR)/doc/xen
 	rm -rf $(D)$(SHAREDIR)/xen
+	rm -rf $(D)$(SHAREDIR)/qemu-xen
 	rm -rf $(D)$(MAN1DIR)/xen*
 	rm -rf $(D)$(MAN8DIR)/xen*
 	rm -rf $(D)/boot/tboot*

--------------060804010308080407010308--

--------------ms020407080003000004010906
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQxNjExNDUwNVowIwYJKoZIhvcNAQkEMRYEFIb/g/AFla7lIe4GFxGTwQNX
4RNGMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQB9T5MCh0SgmbqvaHFBQYjzxHvM36u3Ng3FM8MNzH33
ewPvFqxpevSwwI3dXP+AAxmcD0eh7bOxC75t+JA6AEpHNaYDyiCLAp/PeIq8nQwuWy+QBX1W
fPs81ydBYA5ToiatoRsWkxSdy81blxzRQGq7dgAhRuoVyEFAMmuVxcB95axKRrg9TEMVq3SM
MUd5AhccWeRRdi037z3c5JLmcZ12lmEPKPCePGBSXZWsKoDdf86wKgSsvKLJqrmIjhXrEwWH
H1txvD8uxh1TRCwwbrSkELCdjdPB2EyYZLQTDlyIzplkyIr0lHMcXCj9JGZrYT9oMLB8/mzK
cqCHNWbZ5BILAAAAAAAA
--------------ms020407080003000004010906--


--===============2565754811198684334==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2565754811198684334==--


From xen-devel-bounces@lists.xen.org Mon Apr 16 11:51:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkSB-0003j6-5R; Mon, 16 Apr 2012 11:50:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJkS9-0003j1-5P
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:50:41 +0000
Received: from [85.158.138.51:27417] by server-2.bemta-3.messagelabs.com id
	22/A8-09269-0970C8F4; Mon, 16 Apr 2012 11:50:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334577039!22327487!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11521 invoked from network); 16 Apr 2012 11:50:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:50:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11953657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:50:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 12:50:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJkS3-0001VB-9U; Mon, 16 Apr 2012 11:50:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJkS3-0005A5-6g;
	Mon, 16 Apr 2012 12:50:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20364.1930.443039.980717@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 12:50:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334575140.14560.138.camel@zakaz.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334567346.14560.48.camel@zakaz.uk.xensource.com>
	<20363.62771.531826.469233@mariner.uk.xensource.com>
	<1334575140.14560.138.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> On Mon, 2012-04-16 at 11:32 +0100, Ian Jackson wrote:
> > > Does this fail if -lutil isn't available? My (perhaps mistaken) reading
> > > of the commit message was that -lutil was only needed on some platforms?
> > 
> > Yes, it will do.  Currently -lutil is used everywhere except Solaris
> > but surely Solaris support has rotted by now.  I could change the
> > patch to try both with and without, I guess.
> 
> OK, I think we can just leave it until someone ports Xen to a platform
> which has this behaviour (i.e. it can be tested)

I've updated it anyway, as it wasn't too hard.

> > > On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
> > > configure output -- so maybe I just understand what all these macros are
> > > actually doing.
> > 
> > Linux has -lutil.
> 
> I meant that the message doesn't seem to appear in the generate
> configure script itself.

While editing this patch I found that I had some of the bracketing
wrong.  That was probably it.  It'll be fixed in v2.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 11:51:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 11:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkSB-0003j6-5R; Mon, 16 Apr 2012 11:50:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJkS9-0003j1-5P
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 11:50:41 +0000
Received: from [85.158.138.51:27417] by server-2.bemta-3.messagelabs.com id
	22/A8-09269-0970C8F4; Mon, 16 Apr 2012 11:50:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334577039!22327487!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11521 invoked from network); 16 Apr 2012 11:50:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 11:50:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11953657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:50:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 12:50:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJkS3-0001VB-9U; Mon, 16 Apr 2012 11:50:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJkS3-0005A5-6g;
	Mon, 16 Apr 2012 12:50:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20364.1930.443039.980717@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 12:50:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334575140.14560.138.camel@zakaz.uk.xensource.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334567346.14560.48.camel@zakaz.uk.xensource.com>
	<20363.62771.531826.469233@mariner.uk.xensource.com>
	<1334575140.14560.138.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/20] autoconf: New test for openpty et al."):
> On Mon, 2012-04-16 at 11:32 +0100, Ian Jackson wrote:
> > > Does this fail if -lutil isn't available? My (perhaps mistaken) reading
> > > of the commit message was that -lutil was only needed on some platforms?
> > 
> > Yes, it will do.  Currently -lutil is used everywhere except Solaris
> > but surely Solaris support has rotted by now.  I could change the
> > patch to try both with and without, I guess.
> 
> OK, I think we can just leave it until someone ports Xen to a platform
> which has this behaviour (i.e. it can be tested)

I've updated it anyway, as it wasn't too hard.

> > > On the other hand the AC_MSG_FAILURE doesn't see to have appeared in the
> > > configure output -- so maybe I just understand what all these macros are
> > > actually doing.
> > 
> > Linux has -lutil.
> 
> I meant that the message doesn't seem to appear in the generate
> configure script itself.

While editing this patch I found that I had some of the bracketing
wrong.  That was probably it.  It'll be fixed in v2.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 12:08:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 12:08:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkj2-0004KK-3U; Mon, 16 Apr 2012 12:08:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJkj0-0004KD-76
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 12:08:06 +0000
Received: from [193.109.254.147:24466] by server-9.bemta-14.messagelabs.com id
	B3/2B-05787-5AB0C8F4; Mon, 16 Apr 2012 12:08:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334578083!4769413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8477 invoked from network); 16 Apr 2012 12:08:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 12:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11954038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 12:08:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 13:08:02 +0100
Message-ID: <1334578081.14560.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 16 Apr 2012 13:08:01 +0100
In-Reply-To: <4F8C0641.6030206@tiscali.it>
References: <4F8C0641.6030206@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 12:45 +0100, Fabio Fantoni wrote:
> # HG changeset patch
> # User Fabio Fantoni
> # Date 1334565174 -7200
> # Node ID a9c00a9b48c708a8e448bf5d9cd96026721fbf2f
> # Parent  6b72eb3b40cf2b3d5a6c75d68fa7093c57fc0d1f
> Makefile: Some updates to uninstall
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> diff -r 6b72eb3b40cf -r a9c00a9b48c7 Makefile
> --- a/Makefile    ven apr 13 17:13:01 2012 +0100
> +++ b/Makefile    lun apr 16 10:32:54 2012 +0200
> @@ -220,13 +220,12 @@
>   uninstall: D=$(DESTDIR)
>   uninstall:
>       [ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR) 
> $(D)$(XEN_CONFIG_DIR).old-`date +%s` || true
> -    rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
> +    rm -rf $(D)$(CONFIG_DIR)/init.d/xen*

I know this is pre-existing but I'd rather see these enumerating all the
actual possibilities without wildcards, so as to not remove any local
initscripts which might happen to match (which becomes move likely with
your removal of the "d")

>       rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
> -    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
> -    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules

These two are things older versions of Xen installed but which current
versions do not?

>       rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
> +    rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
>       rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
>       rm -rf $(D)/boot/*xen*
>       rm -rf $(D)/lib/modules/*xen*
> @@ -236,11 +235,16 @@
>       rm -rf $(D)$(BINDIR)/pygrub
>       rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
>       rm -rf $(D)$(BINDIR)/xsls
> -    rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
> +    rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
> +    rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
> +    rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
> +    rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
>       rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
>       rm -rf $(D)$(INCLUDEDIR)/xen
> +    rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
> +    rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
>       rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
> -    rm -rf $(D)$(LIBDIR)/libxenstore*
> +    rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
>       rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
>       rm -rf $(D)$(LIBDIR)/xen/
>       rm -rf $(D)$(LIBEXEC)/xen*
> @@ -248,6 +252,7 @@
>       rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
>       rm -rf $(D)$(SHAREDIR)/doc/xen
>       rm -rf $(D)$(SHAREDIR)/xen
> +    rm -rf $(D)$(SHAREDIR)/qemu-xen
>       rm -rf $(D)$(MAN1DIR)/xen*
>       rm -rf $(D)$(MAN8DIR)/xen*
>       rm -rf $(D)/boot/tboot*
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 12:08:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 12:08:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJkj2-0004KK-3U; Mon, 16 Apr 2012 12:08:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJkj0-0004KD-76
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 12:08:06 +0000
Received: from [193.109.254.147:24466] by server-9.bemta-14.messagelabs.com id
	B3/2B-05787-5AB0C8F4; Mon, 16 Apr 2012 12:08:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334578083!4769413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8477 invoked from network); 16 Apr 2012 12:08:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 12:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,428,1330905600"; d="scan'208";a="11954038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 12:08:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 13:08:02 +0100
Message-ID: <1334578081.14560.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 16 Apr 2012 13:08:01 +0100
In-Reply-To: <4F8C0641.6030206@tiscali.it>
References: <4F8C0641.6030206@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 12:45 +0100, Fabio Fantoni wrote:
> # HG changeset patch
> # User Fabio Fantoni
> # Date 1334565174 -7200
> # Node ID a9c00a9b48c708a8e448bf5d9cd96026721fbf2f
> # Parent  6b72eb3b40cf2b3d5a6c75d68fa7093c57fc0d1f
> Makefile: Some updates to uninstall
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> diff -r 6b72eb3b40cf -r a9c00a9b48c7 Makefile
> --- a/Makefile    ven apr 13 17:13:01 2012 +0100
> +++ b/Makefile    lun apr 16 10:32:54 2012 +0200
> @@ -220,13 +220,12 @@
>   uninstall: D=$(DESTDIR)
>   uninstall:
>       [ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR) 
> $(D)$(XEN_CONFIG_DIR).old-`date +%s` || true
> -    rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
> +    rm -rf $(D)$(CONFIG_DIR)/init.d/xen*

I know this is pre-existing but I'd rather see these enumerating all the
actual possibilities without wildcards, so as to not remove any local
initscripts which might happen to match (which becomes move likely with
your removal of the "d")

>       rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
> -    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
> -    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules

These two are things older versions of Xen installed but which current
versions do not?

>       rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
> +    rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
>       rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
>       rm -rf $(D)/boot/*xen*
>       rm -rf $(D)/lib/modules/*xen*
> @@ -236,11 +235,16 @@
>       rm -rf $(D)$(BINDIR)/pygrub
>       rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
>       rm -rf $(D)$(BINDIR)/xsls
> -    rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
> +    rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
> +    rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
> +    rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
> +    rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
>       rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
>       rm -rf $(D)$(INCLUDEDIR)/xen
> +    rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
> +    rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
>       rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
> -    rm -rf $(D)$(LIBDIR)/libxenstore*
> +    rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
>       rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
>       rm -rf $(D)$(LIBDIR)/xen/
>       rm -rf $(D)$(LIBEXEC)/xen*
> @@ -248,6 +252,7 @@
>       rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
>       rm -rf $(D)$(SHAREDIR)/doc/xen
>       rm -rf $(D)$(SHAREDIR)/xen
> +    rm -rf $(D)$(SHAREDIR)/qemu-xen
>       rm -rf $(D)$(MAN1DIR)/xen*
>       rm -rf $(D)$(MAN8DIR)/xen*
>       rm -rf $(D)/boot/tboot*
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJlgY-0005Ye-E9; Mon, 16 Apr 2012 13:09:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SJlgX-0005YW-35
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 13:09:37 +0000
Received: from [85.158.143.99:26791] by server-2.bemta-4.messagelabs.com id
	46/40-17550-01A1C8F4; Mon, 16 Apr 2012 13:09:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334581774!12644987!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTg4NDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19821 invoked from network); 16 Apr 2012 13:09:35 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 13:09:35 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 6DCEB5EC07C;
	Mon, 16 Apr 2012 06:09:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Nphm+o5xkOIZGMTHU0MseoOWH6D8G8q6o6Vf+kMd9lKH
	wXT1vUycwEdVJIGQuiy8nzzJ3KbtgaD5W3NP0ceLBM6TmSPtcI1Wr2RA7A+pkFm5
	hvQj0HGleUaVG/T9eDBPvKsrNO0ORNQkKfk0Umt2A9oB68oVzgHDQOev5IbT07k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SS4IgV0ixrRLV7s/TlKGYk/mU6c=; b=hWKi6Jng
	c+D82MoCZnFbiVoIWn3r03X//KyApN7yHR5wkt81v/bpbg4fxxyR6Fd5vngB5Dob
	UAT8975VZ25CPUPasSNPCFBiZSbMNPVoEZIu98h+Sc8nicGHCIUSQzQFGpA5ejA6
	oMH/okDFBG+9iPjNJ7dj2bYRbLk+OC/ctR4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id EA7905EC07E; 
	Mon, 16 Apr 2012 06:09:33 -0700 (PDT)
Received: from 75.119.246.151 (proxying for 75.119.246.151)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 16 Apr 2012 06:09:34 -0700
Message-ID: <2ff01d8ce8cb284cf41389b6c71a231f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2355.1334576711.1399.xen-devel@lists.xen.org>
References: <mailman.2355.1334576711.1399.xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 06:09:34 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Date: Mon, 16 Apr 2012 12:31:50 +0100
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: xen-devel <xen-devel@lists.xen.org>
> Subject: [Xen-devel] 4.2 Release Plan / TODO
> Message-ID: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March        -- TODO list locked down
> 2 April         -- Feature Freeze
>                                                        << WE ARE HERE
> Mid/Late April  -- First release candidate
> Weekly          -- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> A bunch of new items have been added to the list, mainly due to Ian
> Jacksons review of the libxl API for stability. I believe these are
> mostly under control. Some of these are going to be immediately deferred
> to 4.3 but I have included them in this week's list to allow the
> opportunity for feedback.
>
> Some of the new items are unclaimed. Volunteers would be much
> appreciated.
>
> As discussed last week I have added known bugs to the lists below.
> Please refer me to any should or must be fixed bugs (best way it by
> responding to this mail with a pointer so my threading mailer will track
> it for next week).
>
> hypervisor, blockers:
>       * [BUG] Zombie driver domains.  There's a bug where PV guests with
>         devices passed through with xl hang around as "zombies", with
>         one outstanding page reference.  I think this should really be a
>         blocker. I'm working on this at the moment (George Dunlap).
>               * One of several recent reports of Zombie domains, which
>                 may or may not be all related.
>               * List as hypervisor for now, but may turn out to be a
>                 tools issue.
>
> tools, blockers:
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * Safe fork vs. fd handling hooks. Involves API changes
>                 (Ian J, patches posted)
>               * locking/serialization, e.g., for domain creation. [...]
>                       * Deferred until 4.3. We think this functionality
>                         can be added without impacting API stability.
>               * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
>                 Interface needs an overhaul, related to
>                 locking/serialization over domain create (see above).
>                 IanJ to add note about this interface being substandard
>                 but otherwise defer to 4.3.
>               * libxl_{FOO}_exec. Should return a data structure
>                 declaring what to do, not fork and exec themselves.
>                 However we can defer this until 4.3.
>               * libxl_*_path. Majority made internal, only configdir and
>                 lockdir remain public (used by xl). Good enough?
>               * Interfaces which may need to be async:
>                       * libxl_domain_suspend. Nobody has looked at these
>                         at all. A volunteer would be appreciated.
>                       * libxl_domain_create_{new,restore} -- IanJ has
>                         patches as part of event series.
>                       * libxl_domain_{shutdown,reboot}. These are "fast"
>                         functions and there do not need to be async.
>                         (So, DONE with no action required)
>                       * libxl_domain_core_dump. Can take a dummy ao_how
>                         and remain synchronous internally.
>                       * libxl_device_{disk,nic,vkb,add}_add (and
>                         remove?). Roger Pau Monn? fixes disk as part of
>                         hotplug script series and adds infrastructure
>                         which should make the others trivial.
>                       * libxl_cdrom_insert. Should be easy once
>                         disk_{add,remove} done, IanJ to look at.
>                       * libxl_device_disk_local_{attach,detach}. Become
>                         internal as part of Stefano's domain 0 disk
>                         attach series.
>                       * libxl_device_pci_{add,remove}. Less trivial than
>                         the others. A volunteer would be appreciated.
>                       * libxl_xen_console_*. No interface for waiting
>                         and each call just dumps a bit more of the
>                         ring , so is fast. Nothing to do here (therefore
>                         DONE)
>                       * libxl_xen_tmem_*. All functions are "fast" and
>                         therefore no async needed. Exception is
>                         tmem_destroy which Dan Magenheimer says is
>                         obsolete and can just be removed.
>                       * libxl_fork -- IanJ's event series removes all
>                         users of this.
>       * [BUG] Manually ballooning dom0.  xl mem-set 0 [foo] fails with
>         "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get
>         memory info from /local/domain/0/memory/static-max: No such file
>         or directory". This might be suitable for an enthusiastic
>         on-looker. (George Dunlap, in the absence of said onlooker)
>       * xl compatibility with xm:
>               * None remaining?
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
>       * Domain 0 block attach & general hotplug when using qdisk backend
>         (need to start qemu as necessary etc) (Stefano S, patches
>         posted)
>       * file:// backend performance.
>               * qemu-xen-traditional and upstream qemu-xen performance
>                 has been improved and is now satisfactory.
>               * Xen 4.2 will prefer blktap2 if a kernel module is
>                 available (e.g. older dom0 kernel or DKMS provided
>                 kernel module) and will fallback to qemu qdisk if no
>                 blktap2 is available.
>               * There will be no userspace "blktap3" for Xen 4.2
>       * Improved Hotplug script support (Roger Pau Monn?, patches
>         posted)
>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monn?)
>
> hypervisor, nice to have:
>       * solid implementation of sharing/paging/mem-events (using work
>         queues) (Tim Deegan, Olaf Herring et al -- patches posted)
>               * "The last patch to use a waitqueue in
>                 __get_gfn_type_access() from Tim works.  However, there
>                 are a few users who call __get_gfn_type_access with the
>                 domain_lock held. This part needs to be addressed in
>                 some way."
>       * Sharing support for AMD (Tim, Andres).
>       * PoD performance improvements (George Dunlap)
>
> It seems that none of the above are going to happen for 4.2?

Item 1, no.

Item 2, AMD+paging, people have reported moderate success with what's in
the tree. The AMD folks are looking into trying to reproduce some issues I
run into win7 guest + PV drivers. So it's in, but marked as experimental.

I posted a bunch of hap, shadow and sharing bug fixes that I hope to get
into 4.2. All internal to the hypervisor. Also posted sharing doc patches
for the tools.

Cheers,
Andres

>
> tools, nice to have:
>       * Configure/control paging via xl/libxl (Olaf Herring, lots of
>         discussion around interface, general consensus reached on what
>         it should look like. Olaf has let me know that he is probably
>         not going to have time to do this for 4.2, will likely slip to
>         4.3 unless someone else want to pick up that work)
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard,
>                 patches sent)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini, qemu patches applied, waiting for libxl etc
>                 side which has been recently reposted)
>       * Nested-virtualisation. Currently "experimental". Likely to
>         release that way.
>               * Nested SVM. Tested in a variety of configurations but
>                 still some issues with the most important use case (w7
>                 XP mode) [0]  (Christoph Egger)
>               * Nested VMX. Needs nested EPT to be genuinely useful.
>                 Need more data on testedness etc (Intel)
>       * Initial xl support for Remus (memory checkpoint, blackholing)
>         (Shriram, waiting on libxl side of qemu upstream save/restore)
>       * xl compatibility with xm:
>               * xl support for autospawning vncviewer (vncviewer=1 or
>                 otherwise) (Goncalo Gomes, waiting on new version of
>                 patches)
>               * support for vif "rate" parameter (Mathieu Gagn?, waiting
>                 on new version of patches)
>               * expose PCI back "permissive" parameter (George Dunlap,
>                 DONE)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJlgY-0005Ye-E9; Mon, 16 Apr 2012 13:09:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SJlgX-0005YW-35
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 13:09:37 +0000
Received: from [85.158.143.99:26791] by server-2.bemta-4.messagelabs.com id
	46/40-17550-01A1C8F4; Mon, 16 Apr 2012 13:09:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334581774!12644987!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTg4NDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19821 invoked from network); 16 Apr 2012 13:09:35 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 13:09:35 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 6DCEB5EC07C;
	Mon, 16 Apr 2012 06:09:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Nphm+o5xkOIZGMTHU0MseoOWH6D8G8q6o6Vf+kMd9lKH
	wXT1vUycwEdVJIGQuiy8nzzJ3KbtgaD5W3NP0ceLBM6TmSPtcI1Wr2RA7A+pkFm5
	hvQj0HGleUaVG/T9eDBPvKsrNO0ORNQkKfk0Umt2A9oB68oVzgHDQOev5IbT07k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SS4IgV0ixrRLV7s/TlKGYk/mU6c=; b=hWKi6Jng
	c+D82MoCZnFbiVoIWn3r03X//KyApN7yHR5wkt81v/bpbg4fxxyR6Fd5vngB5Dob
	UAT8975VZ25CPUPasSNPCFBiZSbMNPVoEZIu98h+Sc8nicGHCIUSQzQFGpA5ejA6
	oMH/okDFBG+9iPjNJ7dj2bYRbLk+OC/ctR4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id EA7905EC07E; 
	Mon, 16 Apr 2012 06:09:33 -0700 (PDT)
Received: from 75.119.246.151 (proxying for 75.119.246.151)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 16 Apr 2012 06:09:34 -0700
Message-ID: <2ff01d8ce8cb284cf41389b6c71a231f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2355.1334576711.1399.xen-devel@lists.xen.org>
References: <mailman.2355.1334576711.1399.xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 06:09:34 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Date: Mon, 16 Apr 2012 12:31:50 +0100
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: xen-devel <xen-devel@lists.xen.org>
> Subject: [Xen-devel] 4.2 Release Plan / TODO
> Message-ID: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March        -- TODO list locked down
> 2 April         -- Feature Freeze
>                                                        << WE ARE HERE
> Mid/Late April  -- First release candidate
> Weekly          -- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> A bunch of new items have been added to the list, mainly due to Ian
> Jacksons review of the libxl API for stability. I believe these are
> mostly under control. Some of these are going to be immediately deferred
> to 4.3 but I have included them in this week's list to allow the
> opportunity for feedback.
>
> Some of the new items are unclaimed. Volunteers would be much
> appreciated.
>
> As discussed last week I have added known bugs to the lists below.
> Please refer me to any should or must be fixed bugs (best way it by
> responding to this mail with a pointer so my threading mailer will track
> it for next week).
>
> hypervisor, blockers:
>       * [BUG] Zombie driver domains.  There's a bug where PV guests with
>         devices passed through with xl hang around as "zombies", with
>         one outstanding page reference.  I think this should really be a
>         blocker. I'm working on this at the moment (George Dunlap).
>               * One of several recent reports of Zombie domains, which
>                 may or may not be all related.
>               * List as hypervisor for now, but may turn out to be a
>                 tools issue.
>
> tools, blockers:
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * Safe fork vs. fd handling hooks. Involves API changes
>                 (Ian J, patches posted)
>               * locking/serialization, e.g., for domain creation. [...]
>                       * Deferred until 4.3. We think this functionality
>                         can be added without impacting API stability.
>               * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
>                 Interface needs an overhaul, related to
>                 locking/serialization over domain create (see above).
>                 IanJ to add note about this interface being substandard
>                 but otherwise defer to 4.3.
>               * libxl_{FOO}_exec. Should return a data structure
>                 declaring what to do, not fork and exec themselves.
>                 However we can defer this until 4.3.
>               * libxl_*_path. Majority made internal, only configdir and
>                 lockdir remain public (used by xl). Good enough?
>               * Interfaces which may need to be async:
>                       * libxl_domain_suspend. Nobody has looked at these
>                         at all. A volunteer would be appreciated.
>                       * libxl_domain_create_{new,restore} -- IanJ has
>                         patches as part of event series.
>                       * libxl_domain_{shutdown,reboot}. These are "fast"
>                         functions and there do not need to be async.
>                         (So, DONE with no action required)
>                       * libxl_domain_core_dump. Can take a dummy ao_how
>                         and remain synchronous internally.
>                       * libxl_device_{disk,nic,vkb,add}_add (and
>                         remove?). Roger Pau Monn? fixes disk as part of
>                         hotplug script series and adds infrastructure
>                         which should make the others trivial.
>                       * libxl_cdrom_insert. Should be easy once
>                         disk_{add,remove} done, IanJ to look at.
>                       * libxl_device_disk_local_{attach,detach}. Become
>                         internal as part of Stefano's domain 0 disk
>                         attach series.
>                       * libxl_device_pci_{add,remove}. Less trivial than
>                         the others. A volunteer would be appreciated.
>                       * libxl_xen_console_*. No interface for waiting
>                         and each call just dumps a bit more of the
>                         ring , so is fast. Nothing to do here (therefore
>                         DONE)
>                       * libxl_xen_tmem_*. All functions are "fast" and
>                         therefore no async needed. Exception is
>                         tmem_destroy which Dan Magenheimer says is
>                         obsolete and can just be removed.
>                       * libxl_fork -- IanJ's event series removes all
>                         users of this.
>       * [BUG] Manually ballooning dom0.  xl mem-set 0 [foo] fails with
>         "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get
>         memory info from /local/domain/0/memory/static-max: No such file
>         or directory". This might be suitable for an enthusiastic
>         on-looker. (George Dunlap, in the absence of said onlooker)
>       * xl compatibility with xm:
>               * None remaining?
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
>       * Domain 0 block attach & general hotplug when using qdisk backend
>         (need to start qemu as necessary etc) (Stefano S, patches
>         posted)
>       * file:// backend performance.
>               * qemu-xen-traditional and upstream qemu-xen performance
>                 has been improved and is now satisfactory.
>               * Xen 4.2 will prefer blktap2 if a kernel module is
>                 available (e.g. older dom0 kernel or DKMS provided
>                 kernel module) and will fallback to qemu qdisk if no
>                 blktap2 is available.
>               * There will be no userspace "blktap3" for Xen 4.2
>       * Improved Hotplug script support (Roger Pau Monn?, patches
>         posted)
>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monn?)
>
> hypervisor, nice to have:
>       * solid implementation of sharing/paging/mem-events (using work
>         queues) (Tim Deegan, Olaf Herring et al -- patches posted)
>               * "The last patch to use a waitqueue in
>                 __get_gfn_type_access() from Tim works.  However, there
>                 are a few users who call __get_gfn_type_access with the
>                 domain_lock held. This part needs to be addressed in
>                 some way."
>       * Sharing support for AMD (Tim, Andres).
>       * PoD performance improvements (George Dunlap)
>
> It seems that none of the above are going to happen for 4.2?

Item 1, no.

Item 2, AMD+paging, people have reported moderate success with what's in
the tree. The AMD folks are looking into trying to reproduce some issues I
run into win7 guest + PV drivers. So it's in, but marked as experimental.

I posted a bunch of hap, shadow and sharing bug fixes that I hope to get
into 4.2. All internal to the hypervisor. Also posted sharing doc patches
for the tools.

Cheers,
Andres

>
> tools, nice to have:
>       * Configure/control paging via xl/libxl (Olaf Herring, lots of
>         discussion around interface, general consensus reached on what
>         it should look like. Olaf has let me know that he is probably
>         not going to have time to do this for 4.2, will likely slip to
>         4.3 unless someone else want to pick up that work)
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard,
>                 patches sent)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini, qemu patches applied, waiting for libxl etc
>                 side which has been recently reposted)
>       * Nested-virtualisation. Currently "experimental". Likely to
>         release that way.
>               * Nested SVM. Tested in a variety of configurations but
>                 still some issues with the most important use case (w7
>                 XP mode) [0]  (Christoph Egger)
>               * Nested VMX. Needs nested EPT to be genuinely useful.
>                 Need more data on testedness etc (Intel)
>       * Initial xl support for Remus (memory checkpoint, blackholing)
>         (Shriram, waiting on libxl side of qemu upstream save/restore)
>       * xl compatibility with xm:
>               * xl support for autospawning vncviewer (vncviewer=1 or
>                 otherwise) (Goncalo Gomes, waiting on new version of
>                 patches)
>               * support for vif "rate" parameter (Mathieu Gagn?, waiting
>                 on new version of patches)
>               * expose PCI back "permissive" parameter (George Dunlap,
>                 DONE)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJm6l-0005s1-H1; Mon, 16 Apr 2012 13:36:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJm6k-0005ru-3x
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 13:36:42 +0000
Received: from [193.109.254.147:13220] by server-12.bemta-14.messagelabs.com
	id CE/89-05898-9602C8F4; Mon, 16 Apr 2012 13:36:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334583399!4818963!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18669 invoked from network); 16 Apr 2012 13:36:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 13:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24191289"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 09:36:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJm6O-0008KJ-4D;
	Mon, 16 Apr 2012 14:36:20 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 14:36:15 +0100
Message-ID: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] autoconf: add ovmf,
	rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Move this hardcoded options from Config.mk to config/Tools.mk and add the
appropiate configure options.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 Config.mk          |    4 ----
 config/Tools.mk.in |    3 +++
 tools/configure.ac |    3 +++
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Config.mk b/Config.mk
index 796fb8c..09ac1f9 100644
--- a/Config.mk
+++ b/Config.mk
@@ -207,10 +207,6 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
-CONFIG_OVMF ?= n
-CONFIG_ROMBIOS ?= y
-CONFIG_SEABIOS ?= y
-
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 339a7b6..5d9276a 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -40,6 +40,9 @@ PYTHON_TOOLS        := @pythontools@
 OCAML_TOOLS         := @ocamltools@
 CONFIG_MINITERM     := @miniterm@
 CONFIG_LOMOUNT      := @lomount@
+CONFIG_OVMF         := @ovmf@
+CONFIG_ROMBIOS      := @rombios@
+CONFIG_SEABIOS      := @seabios@
 
 #System options
 CONFIG_SYSTEM_LIBAIO:= @system_aio@
diff --git a/tools/configure.ac b/tools/configure.ac
index 0204e36..52571e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -43,6 +43,9 @@ AX_ARG_DEFAULT_ENABLE([pythontools], [Disable Python tools])
 AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
+AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
+AX_ARG_DEFAULT_ENABLE([rombios], [Disable ROM BIOS])
+AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
 
 AC_ARG_VAR([PREPEND_INCLUDES],
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJm6l-0005s1-H1; Mon, 16 Apr 2012 13:36:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJm6k-0005ru-3x
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 13:36:42 +0000
Received: from [193.109.254.147:13220] by server-12.bemta-14.messagelabs.com
	id CE/89-05898-9602C8F4; Mon, 16 Apr 2012 13:36:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334583399!4818963!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18669 invoked from network); 16 Apr 2012 13:36:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 13:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24191289"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 09:36:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 09:36:20 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJm6O-0008KJ-4D;
	Mon, 16 Apr 2012 14:36:20 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 14:36:15 +0100
Message-ID: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] autoconf: add ovmf,
	rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Move this hardcoded options from Config.mk to config/Tools.mk and add the
appropiate configure options.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 Config.mk          |    4 ----
 config/Tools.mk.in |    3 +++
 tools/configure.ac |    3 +++
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Config.mk b/Config.mk
index 796fb8c..09ac1f9 100644
--- a/Config.mk
+++ b/Config.mk
@@ -207,10 +207,6 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
-CONFIG_OVMF ?= n
-CONFIG_ROMBIOS ?= y
-CONFIG_SEABIOS ?= y
-
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 339a7b6..5d9276a 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -40,6 +40,9 @@ PYTHON_TOOLS        := @pythontools@
 OCAML_TOOLS         := @ocamltools@
 CONFIG_MINITERM     := @miniterm@
 CONFIG_LOMOUNT      := @lomount@
+CONFIG_OVMF         := @ovmf@
+CONFIG_ROMBIOS      := @rombios@
+CONFIG_SEABIOS      := @seabios@
 
 #System options
 CONFIG_SYSTEM_LIBAIO:= @system_aio@
diff --git a/tools/configure.ac b/tools/configure.ac
index 0204e36..52571e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -43,6 +43,9 @@ AX_ARG_DEFAULT_ENABLE([pythontools], [Disable Python tools])
 AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
+AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
+AX_ARG_DEFAULT_ENABLE([rombios], [Disable ROM BIOS])
+AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
 
 AC_ARG_VAR([PREPEND_INCLUDES],
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:53:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmMy-0006in-Iy; Mon, 16 Apr 2012 13:53:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJmMx-0006id-4Q
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 13:53:27 +0000
Received: from [85.158.138.51:24561] by server-8.bemta-3.messagelabs.com id
	31/D0-24428-6542C8F4; Mon, 16 Apr 2012 13:53:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334584404!14448385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16483 invoked from network); 16 Apr 2012 13:53:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 13:53:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11956843"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:53:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:53:23 +0100
Message-ID: <1334584402.14560.184.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 16 Apr 2012 14:53:22 +0100
In-Reply-To: <20120413182952.504e2775@mantra.us.oracle.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-14 at 02:29 +0100, Mukesh Rathor wrote:
> Hi,
> 
> I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
> can please look at it and give any comments. I tested it and seems to work
> ok.

I'm not all that familiar with x86 p2m stuff but I'll try. (I've also
added Tim, who is familiar with this stuff)

> Basically, the library, xl running in hybrid dom0, needs to map domU pages
> during guest creation. I tried using existing add to physmap, mmu_update,
> but nothing was feasible. So wrote this. Its called from
> privcmd_ioctl_mmap_batch().
> 
> thanks,
> Mukesh
> 
> 
> /* add frames from foreign domain to current domain physmap. Similar to 
>  * XENMEM_add_to_physmap

Why a whole new hypercall rather than a new XENMAPSPACE for the exiting
XENMEM_add_to_physmap.

>  but the mfn frame is foreign, is being mapped into 
>  * current privileged domain, and is not removed from foreign domain. 
>  * Usage: libxl when creating guest in hybrid dom0 doing privcmd_ioctl_mmap
>  * Return: 0 success
>  */
> static long _add_foreign_to_pmap_batch(XEN_GUEST_HANDLE(void) arg)
> {
>     struct xen_add_to_foreign_pmap_batch pmapb;

Ideally we'd have the definition of this (or the equivalent mod to the
XENMEM_add_to_physmap associated struct) for context, but I can probably
guess what the content looks like.

>     unsigned long rc=0, i, prev_mfn, mfn = 0;
>     struct domain *fdom, *currd = current->domain;
>     p2m_type_t p2mt;
> 
>     if ( copy_from_guest(&pmapb, arg, 1) )
>         return -EFAULT;
> 
>     fdom = get_pg_owner(pmapb.foreign_domid);
> 
>     if ( fdom== NULL ) {
>         put_pg_owner(fdom);
>         return -EPERM;
>     }
> 
>     for (i=0; (rc == 0) && (i < pmapb.count); i++) {
>         unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
>         mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));

I don't see gfn_to_mfn_query anywhere, I presume it's just a pretty
straight forward p2m lookup? Surprised there is no existing API but OK.

> 	if ( !p2m_is_valid(p2mt) )
>             rc = -EINVAL;
> 
>         if ( !rc && !get_page_from_pagenr(mfn, fdom) )
>             rc = -EPERM;
> 
>         if (!rc) 
>             put_page(mfn_to_page(mfn));
>         else 
>             break;
> 
>         /* Remove previously mapped page if it was present. */
>         prev_mfn = gmfn_to_mfn(currd, gpfn);
>         if ( mfn_valid(prev_mfn) )
>         {
>             if ( is_xen_heap_mfn(prev_mfn) )
>                 /* Xen heap frames are simply unhooked from this phys slot */
>                 guest_physmap_remove_page(currd, gpfn, prev_mfn, 0);
>             else
>                 /* Normal domain memory is freed, to avoid leaking memory. */
>                 guest_remove_page(currd, gpfn);

Do you mean "unrefd" here rather than freed? Presumably the remote
domain (which owns the page) is still using it?

>         }
>         /* Map at new location. */
> 	/* Can't use guest_physmap_add_page() because it will update the m2p
> 	 * table so mfn ---> gpfn in dom0 and not gpfn of domU.
> 	 */
>         /* rc = guest_physmap_add_page(currd, gpfn, mfn, 0); */
> 
> 	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);

This ends up setting the page type to p2m_mmio_direct, which doesn't
seem likely to be correct. Perhaps you should be calling
set_p2m_entry()? Or adding a set_ram_p2m_entry which does similar checks
etc to set_mmio_p2m_entry (or maybe you could abstract out some generic
bits there)?

>         if (rc==0) {
>             printk("guest_physmap_add_page failed.gpfn:%lx mfn:%lx fgmfn:%lx\n",
>                    gpfn, mfn, fgmfn);
>             rc == -EINVAL;
>         } else 
>             rc = 0;
>     }
> 
>     pmapb.count = i;
>     copy_to_guest(arg, &pmapb, 1);
>     put_pg_owner(fdom);
>     return rc;
> }
> 
> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void) arg)

Can't XENMEM_remove_from_physmap be used here?

> {
>     xen_pfn_t gmfn;
>     struct xen_rem_foreign_pmap_batch pmapb;
>     p2m_type_t p2mt;
>     int i, rc=0;
>     struct domain *currd = current->domain;
> 
>     if ( copy_from_guest(&pmapb, arg, 1) )
>         return -EFAULT;
> 
>     for ( gmfn=pmapb.s_gpfn, i=0;  i < pmapb.count;  i++, gmfn++ ) {
> 
>         mfn_t mfn = mfn_x(gfn_to_mfn(p2m_get_hostp2m(currd), gmfn, &p2mt));
>         if ( unlikely(!mfn_valid(mfn)) )
>         {
>             gdprintk(XENLOG_INFO, "%s: Domain:%u gmfn:%lx invalid\n",
>                      __FUNCTION__, currd->domain_id, gmfn);
>             rc = -EINVAL;
>             break;
>         }
>         /* guest_physmap_remove_page(currd, gmfn, mfn, 0); */
> 	clear_mmio_p2m_entry(p2m_get_hostp2m(currd), gmfn);
>     }
>     pmapb.count = i;
>     copy_to_guest(arg, &pmapb, 1);
>     return rc;
> }
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:53:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmMy-0006in-Iy; Mon, 16 Apr 2012 13:53:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJmMx-0006id-4Q
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 13:53:27 +0000
Received: from [85.158.138.51:24561] by server-8.bemta-3.messagelabs.com id
	31/D0-24428-6542C8F4; Mon, 16 Apr 2012 13:53:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334584404!14448385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16483 invoked from network); 16 Apr 2012 13:53:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 13:53:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11956843"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:53:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:53:23 +0100
Message-ID: <1334584402.14560.184.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 16 Apr 2012 14:53:22 +0100
In-Reply-To: <20120413182952.504e2775@mantra.us.oracle.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-14 at 02:29 +0100, Mukesh Rathor wrote:
> Hi,
> 
> I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
> can please look at it and give any comments. I tested it and seems to work
> ok.

I'm not all that familiar with x86 p2m stuff but I'll try. (I've also
added Tim, who is familiar with this stuff)

> Basically, the library, xl running in hybrid dom0, needs to map domU pages
> during guest creation. I tried using existing add to physmap, mmu_update,
> but nothing was feasible. So wrote this. Its called from
> privcmd_ioctl_mmap_batch().
> 
> thanks,
> Mukesh
> 
> 
> /* add frames from foreign domain to current domain physmap. Similar to 
>  * XENMEM_add_to_physmap

Why a whole new hypercall rather than a new XENMAPSPACE for the exiting
XENMEM_add_to_physmap.

>  but the mfn frame is foreign, is being mapped into 
>  * current privileged domain, and is not removed from foreign domain. 
>  * Usage: libxl when creating guest in hybrid dom0 doing privcmd_ioctl_mmap
>  * Return: 0 success
>  */
> static long _add_foreign_to_pmap_batch(XEN_GUEST_HANDLE(void) arg)
> {
>     struct xen_add_to_foreign_pmap_batch pmapb;

Ideally we'd have the definition of this (or the equivalent mod to the
XENMEM_add_to_physmap associated struct) for context, but I can probably
guess what the content looks like.

>     unsigned long rc=0, i, prev_mfn, mfn = 0;
>     struct domain *fdom, *currd = current->domain;
>     p2m_type_t p2mt;
> 
>     if ( copy_from_guest(&pmapb, arg, 1) )
>         return -EFAULT;
> 
>     fdom = get_pg_owner(pmapb.foreign_domid);
> 
>     if ( fdom== NULL ) {
>         put_pg_owner(fdom);
>         return -EPERM;
>     }
> 
>     for (i=0; (rc == 0) && (i < pmapb.count); i++) {
>         unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
>         mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));

I don't see gfn_to_mfn_query anywhere, I presume it's just a pretty
straight forward p2m lookup? Surprised there is no existing API but OK.

> 	if ( !p2m_is_valid(p2mt) )
>             rc = -EINVAL;
> 
>         if ( !rc && !get_page_from_pagenr(mfn, fdom) )
>             rc = -EPERM;
> 
>         if (!rc) 
>             put_page(mfn_to_page(mfn));
>         else 
>             break;
> 
>         /* Remove previously mapped page if it was present. */
>         prev_mfn = gmfn_to_mfn(currd, gpfn);
>         if ( mfn_valid(prev_mfn) )
>         {
>             if ( is_xen_heap_mfn(prev_mfn) )
>                 /* Xen heap frames are simply unhooked from this phys slot */
>                 guest_physmap_remove_page(currd, gpfn, prev_mfn, 0);
>             else
>                 /* Normal domain memory is freed, to avoid leaking memory. */
>                 guest_remove_page(currd, gpfn);

Do you mean "unrefd" here rather than freed? Presumably the remote
domain (which owns the page) is still using it?

>         }
>         /* Map at new location. */
> 	/* Can't use guest_physmap_add_page() because it will update the m2p
> 	 * table so mfn ---> gpfn in dom0 and not gpfn of domU.
> 	 */
>         /* rc = guest_physmap_add_page(currd, gpfn, mfn, 0); */
> 
> 	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);

This ends up setting the page type to p2m_mmio_direct, which doesn't
seem likely to be correct. Perhaps you should be calling
set_p2m_entry()? Or adding a set_ram_p2m_entry which does similar checks
etc to set_mmio_p2m_entry (or maybe you could abstract out some generic
bits there)?

>         if (rc==0) {
>             printk("guest_physmap_add_page failed.gpfn:%lx mfn:%lx fgmfn:%lx\n",
>                    gpfn, mfn, fgmfn);
>             rc == -EINVAL;
>         } else 
>             rc = 0;
>     }
> 
>     pmapb.count = i;
>     copy_to_guest(arg, &pmapb, 1);
>     put_pg_owner(fdom);
>     return rc;
> }
> 
> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void) arg)

Can't XENMEM_remove_from_physmap be used here?

> {
>     xen_pfn_t gmfn;
>     struct xen_rem_foreign_pmap_batch pmapb;
>     p2m_type_t p2mt;
>     int i, rc=0;
>     struct domain *currd = current->domain;
> 
>     if ( copy_from_guest(&pmapb, arg, 1) )
>         return -EFAULT;
> 
>     for ( gmfn=pmapb.s_gpfn, i=0;  i < pmapb.count;  i++, gmfn++ ) {
> 
>         mfn_t mfn = mfn_x(gfn_to_mfn(p2m_get_hostp2m(currd), gmfn, &p2mt));
>         if ( unlikely(!mfn_valid(mfn)) )
>         {
>             gdprintk(XENLOG_INFO, "%s: Domain:%u gmfn:%lx invalid\n",
>                      __FUNCTION__, currd->domain_id, gmfn);
>             rc = -EINVAL;
>             break;
>         }
>         /* guest_physmap_remove_page(currd, gmfn, mfn, 0); */
> 	clear_mmio_p2m_entry(p2m_get_hostp2m(currd), gmfn);
>     }
>     pmapb.count = i;
>     copy_to_guest(arg, &pmapb, 1);
>     return rc;
> }
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:58:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmRY-00076G-F4; Mon, 16 Apr 2012 13:58:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJmRW-000764-Gh
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 13:58:10 +0000
Received: from [85.158.143.99:25243] by server-3.bemta-4.messagelabs.com id
	20/F9-05853-1752C8F4; Mon, 16 Apr 2012 13:58:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334584688!18606618!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4310 invoked from network); 16 Apr 2012 13:58:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 13:58:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11956980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:58:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:58:07 +0100
Message-ID: <1334584686.14560.187.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 14:58:06 +0100
In-Reply-To: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
> Move this hardcoded options from Config.mk to config/Tools.mk and add the
> appropiate configure options.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Config.mk          |    4 ----
>  config/Tools.mk.in |    3 +++
>  tools/configure.ac |    3 +++
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Config.mk b/Config.mk
> index 796fb8c..09ac1f9 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -207,10 +207,6 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
>  
>  ETHERBOOT_NICS ?= rtl8139 8086100e
>  
> -CONFIG_OVMF ?= n
> -CONFIG_ROMBIOS ?= y
> -CONFIG_SEABIOS ?= y
> -
>  # Specify which qemu-dm to use. This may be `ioemu' to use the old
>  # Mercurial in-tree version, or a local directory, or a git URL.
>  # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 339a7b6..5d9276a 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -40,6 +40,9 @@ PYTHON_TOOLS        := @pythontools@
>  OCAML_TOOLS         := @ocamltools@
>  CONFIG_MINITERM     := @miniterm@
>  CONFIG_LOMOUNT      := @lomount@
> +CONFIG_OVMF         := @ovmf@
> +CONFIG_ROMBIOS      := @rombios@
> +CONFIG_SEABIOS      := @seabios@
>  
>  #System options
>  CONFIG_SYSTEM_LIBAIO:= @system_aio@
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 0204e36..52571e8 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -43,6 +43,9 @@ AX_ARG_DEFAULT_ENABLE([pythontools], [Disable Python tools])
>  AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
>  AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
>  AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
> +AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
> +AX_ARG_DEFAULT_ENABLE([rombios], [Disable ROM BIOS])
> +AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
>  AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
>  
>  AC_ARG_VAR([PREPEND_INCLUDES],



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 13:58:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 13:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmRY-00076G-F4; Mon, 16 Apr 2012 13:58:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJmRW-000764-Gh
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 13:58:10 +0000
Received: from [85.158.143.99:25243] by server-3.bemta-4.messagelabs.com id
	20/F9-05853-1752C8F4; Mon, 16 Apr 2012 13:58:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334584688!18606618!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4310 invoked from network); 16 Apr 2012 13:58:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 13:58:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11956980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:58:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:58:07 +0100
Message-ID: <1334584686.14560.187.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 14:58:06 +0100
In-Reply-To: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
> Move this hardcoded options from Config.mk to config/Tools.mk and add the
> appropiate configure options.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Config.mk          |    4 ----
>  config/Tools.mk.in |    3 +++
>  tools/configure.ac |    3 +++
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Config.mk b/Config.mk
> index 796fb8c..09ac1f9 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -207,10 +207,6 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
>  
>  ETHERBOOT_NICS ?= rtl8139 8086100e
>  
> -CONFIG_OVMF ?= n
> -CONFIG_ROMBIOS ?= y
> -CONFIG_SEABIOS ?= y
> -
>  # Specify which qemu-dm to use. This may be `ioemu' to use the old
>  # Mercurial in-tree version, or a local directory, or a git URL.
>  # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 339a7b6..5d9276a 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -40,6 +40,9 @@ PYTHON_TOOLS        := @pythontools@
>  OCAML_TOOLS         := @ocamltools@
>  CONFIG_MINITERM     := @miniterm@
>  CONFIG_LOMOUNT      := @lomount@
> +CONFIG_OVMF         := @ovmf@
> +CONFIG_ROMBIOS      := @rombios@
> +CONFIG_SEABIOS      := @seabios@
>  
>  #System options
>  CONFIG_SYSTEM_LIBAIO:= @system_aio@
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 0204e36..52571e8 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -43,6 +43,9 @@ AX_ARG_DEFAULT_ENABLE([pythontools], [Disable Python tools])
>  AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
>  AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
>  AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
> +AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
> +AX_ARG_DEFAULT_ENABLE([rombios], [Disable ROM BIOS])
> +AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
>  AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools])
>  
>  AC_ARG_VAR([PREPEND_INCLUDES],



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmVL-0007OA-A1; Mon, 16 Apr 2012 14:02:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJmVK-0007O3-66
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:02:06 +0000
Received: from [85.158.138.51:3679] by server-5.bemta-3.messagelabs.com id
	64/BA-17113-D562C8F4; Mon, 16 Apr 2012 14:02:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334584924!22342243!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13471 invoked from network); 16 Apr 2012 14:02:04 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 14:02:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJmVE-0004FH-74; Mon, 16 Apr 2012 14:02:00 +0000
Date: Mon, 16 Apr 2012 15:02:00 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120416140200.GA13111@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334584402.14560.184.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:53 +0100 on 16 Apr (1334588002), Ian Campbell wrote:
> On Sat, 2012-04-14 at 02:29 +0100, Mukesh Rathor wrote:
> > Hi,
> > 
> > I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
> > can please look at it and give any comments. I tested it and seems to work
> > ok.
> 
> I'm not all that familiar with x86 p2m stuff but I'll try. (I've also
> added Tim, who is familiar with this stuff)

This is on my todo list for later this week. 

> >     for (i=0; (rc == 0) && (i < pmapb.count); i++) {
> >         unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
> >         mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));
> 
> I don't see gfn_to_mfn_query anywhere, I presume it's just a pretty
> straight forward p2m lookup? Surprised there is no existing API but OK.

Yes, it's a lookup with no PoD/paging/sharing side-effects.
gfn_to_mfn_*() have been replaced by get_gfn()/put_gfn(), so at the
very least this will have to be rebased across that change.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmVL-0007OA-A1; Mon, 16 Apr 2012 14:02:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJmVK-0007O3-66
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:02:06 +0000
Received: from [85.158.138.51:3679] by server-5.bemta-3.messagelabs.com id
	64/BA-17113-D562C8F4; Mon, 16 Apr 2012 14:02:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334584924!22342243!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13471 invoked from network); 16 Apr 2012 14:02:04 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 14:02:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJmVE-0004FH-74; Mon, 16 Apr 2012 14:02:00 +0000
Date: Mon, 16 Apr 2012 15:02:00 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120416140200.GA13111@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334584402.14560.184.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:53 +0100 on 16 Apr (1334588002), Ian Campbell wrote:
> On Sat, 2012-04-14 at 02:29 +0100, Mukesh Rathor wrote:
> > Hi,
> > 
> > I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
> > can please look at it and give any comments. I tested it and seems to work
> > ok.
> 
> I'm not all that familiar with x86 p2m stuff but I'll try. (I've also
> added Tim, who is familiar with this stuff)

This is on my todo list for later this week. 

> >     for (i=0; (rc == 0) && (i < pmapb.count); i++) {
> >         unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
> >         mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));
> 
> I don't see gfn_to_mfn_query anywhere, I presume it's just a pretty
> straight forward p2m lookup? Surprised there is no existing API but OK.

Yes, it's a lookup with no PoD/paging/sharing side-effects.
gfn_to_mfn_*() have been replaced by get_gfn()/put_gfn(), so at the
very least this will have to be rebased across that change.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:14:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmgy-0007lg-CI; Mon, 16 Apr 2012 14:14:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJmgx-0007lW-5r
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:14:07 +0000
Received: from [193.109.254.147:41909] by server-6.bemta-14.messagelabs.com id
	BD/E8-02047-E292C8F4; Mon, 16 Apr 2012 14:14:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334585645!2350774!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14960 invoked from network); 16 Apr 2012 14:14:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:14:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11957461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:14:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:14:05 +0100
Message-ID: <1334585643.14560.199.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 16 Apr 2012 15:14:03 +0100
In-Reply-To: <20120413184705.77b4d316@mantra.us.oracle.com>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-14 at 02:47 +0100, Mukesh Rathor wrote:
> On Mon, 26 Mar 2012 11:37:46 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > I think that we should explicitly allocate these pages/addresses and
> > not rely on the fact that they are at a specific location that we deem
> > safe for now.
> > So if we explicitly introduce a new region at the end of the e820 that
> > we mark as reserved and we use it for this, I would be OK with that.
> > However we need to be careful because editing the e820 has proved to
> > be challenging in the past.
> > Also we would need to figure out a way to tell Linux that these
> > reserved addresses are actually OK to be used. Maybe we need a new
> > command line or hypercall for that.
> 
> That sounds like reasonable approach. Lets do it as part of phase II.
> I wanna get some basic code in.
> 
> So, to give an update of where I am, good news, I've got guests 
> finally booting using hybrid dom0. So, that means I am almost there 
> now!!!! Yeay...

Awesome news!

> But, the pfn space management for privcmd mapping is still a hack. 
> Running into many issues. Basially, it is forcing me to write a slab
> allocator for the resvd pfn space, that I am trying to avoid. During
> guest creation, xl process maps about 10k foreign pgs, and xenstored 1.

10k simultaneously or over the life of a domain build?

> I was thinking of just dividing my pfn space into say 10 chunks, each
> with 10k pages, so 10 guest creations can happen simultaneously. But,
> then xl is not the only process doing the mapping I found out. xenstored
> also needs to map domU frames. Otherwise, I could just do one chunk
> per process. Also, I am breaking mmap semantics somewhat by hooking
> via privcmd_mmap, because the unmaps don't follow any order. So my last
> unmap frees the entire 10k chunk it's using. 

Presumably that's mostly just an issue of doing more accounting/tracking
in the privcmd driver (like the gntdev device does) so you can properly
release things at the right time/place?

> In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> for privcmd without writing a slab allocator.

Can't you just use the core get_page function (or
alloc_xenballooned_pages) and move the associated mfn aside temporarily
(or not if using alloc_xenballooned_pages)?

>  I think using mmap makes
> it harder, can't we just use ioctl to get the VA? Then, I could nicely
> do something like:
>   xl: 
>     - open(privcmd file)
>     - ioctl(get rsvd/e820 pfn handle)
>     - ioctl(get VA using above handle) /* alternate to mmap */
>     - ioctl(get VA1 using above handle) /* alternate to mmap */
>     ...
>     - ioctl(release handle)
>     - ioctl(release VA)
>     - close file
> 
> Is that an option (to change mmap to ioctl)? 
> 
> Hope that makes sense,
> 
> thanks,
> Mukesh
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:14:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmgy-0007lg-CI; Mon, 16 Apr 2012 14:14:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJmgx-0007lW-5r
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:14:07 +0000
Received: from [193.109.254.147:41909] by server-6.bemta-14.messagelabs.com id
	BD/E8-02047-E292C8F4; Mon, 16 Apr 2012 14:14:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334585645!2350774!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14960 invoked from network); 16 Apr 2012 14:14:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:14:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11957461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:14:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:14:05 +0100
Message-ID: <1334585643.14560.199.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 16 Apr 2012 15:14:03 +0100
In-Reply-To: <20120413184705.77b4d316@mantra.us.oracle.com>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-14 at 02:47 +0100, Mukesh Rathor wrote:
> On Mon, 26 Mar 2012 11:37:46 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > I think that we should explicitly allocate these pages/addresses and
> > not rely on the fact that they are at a specific location that we deem
> > safe for now.
> > So if we explicitly introduce a new region at the end of the e820 that
> > we mark as reserved and we use it for this, I would be OK with that.
> > However we need to be careful because editing the e820 has proved to
> > be challenging in the past.
> > Also we would need to figure out a way to tell Linux that these
> > reserved addresses are actually OK to be used. Maybe we need a new
> > command line or hypercall for that.
> 
> That sounds like reasonable approach. Lets do it as part of phase II.
> I wanna get some basic code in.
> 
> So, to give an update of where I am, good news, I've got guests 
> finally booting using hybrid dom0. So, that means I am almost there 
> now!!!! Yeay...

Awesome news!

> But, the pfn space management for privcmd mapping is still a hack. 
> Running into many issues. Basially, it is forcing me to write a slab
> allocator for the resvd pfn space, that I am trying to avoid. During
> guest creation, xl process maps about 10k foreign pgs, and xenstored 1.

10k simultaneously or over the life of a domain build?

> I was thinking of just dividing my pfn space into say 10 chunks, each
> with 10k pages, so 10 guest creations can happen simultaneously. But,
> then xl is not the only process doing the mapping I found out. xenstored
> also needs to map domU frames. Otherwise, I could just do one chunk
> per process. Also, I am breaking mmap semantics somewhat by hooking
> via privcmd_mmap, because the unmaps don't follow any order. So my last
> unmap frees the entire 10k chunk it's using. 

Presumably that's mostly just an issue of doing more accounting/tracking
in the privcmd driver (like the gntdev device does) so you can properly
release things at the right time/place?

> In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> for privcmd without writing a slab allocator.

Can't you just use the core get_page function (or
alloc_xenballooned_pages) and move the associated mfn aside temporarily
(or not if using alloc_xenballooned_pages)?

>  I think using mmap makes
> it harder, can't we just use ioctl to get the VA? Then, I could nicely
> do something like:
>   xl: 
>     - open(privcmd file)
>     - ioctl(get rsvd/e820 pfn handle)
>     - ioctl(get VA using above handle) /* alternate to mmap */
>     - ioctl(get VA1 using above handle) /* alternate to mmap */
>     ...
>     - ioctl(release handle)
>     - ioctl(release VA)
>     - close file
> 
> Is that an option (to change mmap to ioctl)? 
> 
> Hope that makes sense,
> 
> thanks,
> Mukesh
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmnH-000830-8C; Mon, 16 Apr 2012 14:20:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SJmnG-00082v-2H
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:20:38 +0000
Received: from [85.158.143.35:48924] by server-1.bemta-4.messagelabs.com id
	BB/F3-20925-5BA2C8F4; Mon, 16 Apr 2012 14:20:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334586033!11561294!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23542 invoked from network); 16 Apr 2012 14:20:35 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:20:35 -0000
Received: by qcsc20 with SMTP id c20so3899382qcs.32
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 07:20:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=l2wVtGveJ46TQPNGES39PpUCq1DF+iCwjN7gWLGs0GI=;
	b=a5rweMbN9pZvELV/VLv2SllaGWtxhElQiY1mC6JaqwtV15FmIp/h5XZyFg8TkGuQD+
	H50HdxPzh9A8Dl1imeyxDKNrM2jUKqwcuJx9Zpw8gLMoL6ydhpJVuY/m6pIhVXV95Agd
	bNu6dUOVWVbWKD8F1mqnJ20NiDxigTvge68BM8IZd9dbzT5obXiVx9cRU8Vvo8uRr5GQ
	TGmvFd+U/AIAG5GSAumjspZF4Bj3C9VKgIZ/xsCHHqWxaT3SKEeF+Zoe9Av7DQMU9wJQ
	gcbTCQ9qGKXpCI5CbGXwsII9ML4dLsbTir7PHtLky6cZWQ8L45T4Ue2GmkGoHjh2uxnz
	N9cw==
MIME-Version: 1.0
Received: by 10.224.181.69 with SMTP id bx5mr15549390qab.49.1334586033512;
	Mon, 16 Apr 2012 07:20:33 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Mon, 16 Apr 2012 07:20:33 -0700 (PDT)
In-Reply-To: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
References: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
Date: Mon, 16 Apr 2012 15:20:33 +0100
X-Google-Sender-Auth: Ww-C2Aaw_-K1dkVOHERpxb-fwWs
Message-ID: <CAFLBxZZPVf4jHBkyMNke0pr++Nw35WLRzLkdjSxYgTPQ-ajpnA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 12:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March =A0 =A0 =A0 =A0-- TODO list locked down
> 2 April =A0 =A0 =A0 =A0 -- Feature Freeze
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 << WE ARE HERE
> Mid/Late April =A0-- First release candidate
> Weekly =A0 =A0 =A0 =A0 =A0-- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> A bunch of new items have been added to the list, mainly due to Ian
> Jacksons review of the libxl API for stability. I believe these are
> mostly under control. Some of these are going to be immediately deferred
> to 4.3 but I have included them in this week's list to allow the
> opportunity for feedback.
>
> Some of the new items are unclaimed. Volunteers would be much
> appreciated.
>
> As discussed last week I have added known bugs to the lists below.
> Please refer me to any should or must be fixed bugs (best way it by
> responding to this mail with a pointer so my threading mailer will track
> it for next week).
>
> hypervisor, blockers:
> =A0 =A0 =A0* [BUG] Zombie driver domains. =A0There's a bug where PV guest=
s with
> =A0 =A0 =A0 =A0devices passed through with xl hang around as "zombies", w=
ith
> =A0 =A0 =A0 =A0one outstanding page reference. =A0I think this should rea=
lly be a
> =A0 =A0 =A0 =A0blocker. I'm working on this at the moment (George Dunlap).
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* One of several recent reports of Zombie doma=
ins, which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0may or may not be all related.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* List as hypervisor for now, but may turn out=
 to be a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tools issue.
>
> tools, blockers:
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. Involves AP=
I changes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* locking/serialization, e.g., for domain crea=
tion. [...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Deferred until 4.3. We think=
 this functionality
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0can be added without impac=
ting API stability.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_wait_for_free_memory/libxl_wait_for_me=
mory_target.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Interface needs an overhaul, related to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0locking/serialization over domain create (=
see above).
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IanJ to add note about this interface bein=
g substandard
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0but otherwise defer to 4.3.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_{FOO}_exec. Should return a data struc=
ture
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0declaring what to do, not fork and exec th=
emselves.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0However we can defer this until 4.3.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_*_path. Majority made internal, only c=
onfigdir and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lockdir remain public (used by xl). Good e=
nough?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Interfaces which may need to be async:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_suspend. Nobody=
 has looked at these
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at all. A volunteer would =
be appreciated.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_create_{new,res=
tore} -- IanJ has
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches as part of event s=
eries.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_{shutdown,reboo=
t}. These are "fast"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0functions and there do not=
 need to be async.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(So, DONE with no action r=
equired)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_core_dump. Can =
take a dummy ao_how
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and remain synchronous int=
ernally.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_{disk,nic,vkb,a=
dd}_add (and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remove?). Roger Pau Monn=
=E9 fixes disk as part of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hotplug script series and =
adds infrastructure
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0which should make the othe=
rs trivial.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_cdrom_insert. Should b=
e easy once
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0disk_{add,remove} done, Ia=
nJ to look at.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_disk_local_{att=
ach,detach}. Become
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0internal as part of Stefan=
o's domain 0 disk
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attach series.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_pci_{add,remove=
}. Less trivial than
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the others. A volunteer wo=
uld be appreciated.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_xen_console_*. No inte=
rface for waiting
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and each call just dumps a=
 bit more of the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ring , so is fast. Nothing=
 to do here (therefore
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_xen_tmem_*. All functi=
ons are "fast" and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0therefore no async needed.=
 Exception is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmem_destroy which Dan Mag=
enheimer says is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0obsolete and can just be r=
emoved.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_fork -- IanJ's event s=
eries removes all
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0users of this.
> =A0 =A0 =A0* [BUG] Manually ballooning dom0. =A0xl mem-set 0 [foo] fails =
with
> =A0 =A0 =A0 =A0"libxl: error: libxl.c:2569:libxl_set_memory_target: canno=
t get
> =A0 =A0 =A0 =A0memory info from /local/domain/0/memory/static-max: No suc=
h file
> =A0 =A0 =A0 =A0or directory". This might be suitable for an enthusiastic
> =A0 =A0 =A0 =A0on-looker. (George Dunlap, in the absence of said onlooker)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* None remaining?
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
> =A0 =A0 =A0* Domain 0 block attach & general hotplug when using qdisk bac=
kend
> =A0 =A0 =A0 =A0(need to start qemu as necessary etc) (Stefano S, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* file:// backend performance.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen-traditional and upstream qemu-xen p=
erformance
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has been improved and is now satisfactory.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Xen 4.2 will prefer blktap2 if a kernel modu=
le is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0available (e.g. older dom0 kernel or DKMS =
provided
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kernel module) and will fallback to qemu q=
disk if no
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0blktap2 is available.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* There will be no userspace "blktap3" for Xen=
 4.2
> =A0 =A0 =A0* Improved Hotplug script support (Roger Pau Monn=E9, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
>
> hypervisor, nice to have:
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "The last patch to use a waitqueue in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__get_gfn_type_access() from Tim works. =
=A0However, there
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are a few users who call __get_gfn_type_ac=
cess with the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_lock held. This part needs to be ad=
dressed in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some way."
> =A0 =A0 =A0* Sharing support for AMD (Tim, Andres).
> =A0 =A0 =A0* PoD performance improvements (George Dunlap)
>
> It seems that none of the above are going to happen for 4.2?

I'm still hoping to get the PoD patches in, but we'll see.

 -George

>
> tools, nice to have:
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring, lots of
> =A0 =A0 =A0 =A0discussion around interface, general consensus reached on =
what
> =A0 =A0 =A0 =A0it should look like. Olaf has let me know that he is proba=
bly
> =A0 =A0 =A0 =A0not going to have time to do this for 4.2, will likely sli=
p to
> =A0 =A0 =A0 =A04.3 unless someone else want to pick up that work)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, qemu patches applied, waiting =
for libxl etc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0side which has been recently reposted)
> =A0 =A0 =A0* Nested-virtualisation. Currently "experimental". Likely to
> =A0 =A0 =A0 =A0release that way.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested SVM. Tested in a variety of configura=
tions but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still some issues with the most important =
use case (w7
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XP mode) [0] =A0(Christoph Egger)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested VMX. Needs nested EPT to be genuinely=
 useful.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Need more data on testedness etc (Intel)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, waiting on libxl side of qemu upstream save/rest=
ore)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for autospawning vncviewer (vncvi=
ewer=3D1 or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise) (Goncalo Gomes, waiting on new =
version of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga=
gn=E9, waiting
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0on new version of patches)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor=
ge Dunlap,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmnH-000830-8C; Mon, 16 Apr 2012 14:20:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SJmnG-00082v-2H
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:20:38 +0000
Received: from [85.158.143.35:48924] by server-1.bemta-4.messagelabs.com id
	BB/F3-20925-5BA2C8F4; Mon, 16 Apr 2012 14:20:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334586033!11561294!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23542 invoked from network); 16 Apr 2012 14:20:35 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:20:35 -0000
Received: by qcsc20 with SMTP id c20so3899382qcs.32
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 07:20:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=l2wVtGveJ46TQPNGES39PpUCq1DF+iCwjN7gWLGs0GI=;
	b=a5rweMbN9pZvELV/VLv2SllaGWtxhElQiY1mC6JaqwtV15FmIp/h5XZyFg8TkGuQD+
	H50HdxPzh9A8Dl1imeyxDKNrM2jUKqwcuJx9Zpw8gLMoL6ydhpJVuY/m6pIhVXV95Agd
	bNu6dUOVWVbWKD8F1mqnJ20NiDxigTvge68BM8IZd9dbzT5obXiVx9cRU8Vvo8uRr5GQ
	TGmvFd+U/AIAG5GSAumjspZF4Bj3C9VKgIZ/xsCHHqWxaT3SKEeF+Zoe9Av7DQMU9wJQ
	gcbTCQ9qGKXpCI5CbGXwsII9ML4dLsbTir7PHtLky6cZWQ8L45T4Ue2GmkGoHjh2uxnz
	N9cw==
MIME-Version: 1.0
Received: by 10.224.181.69 with SMTP id bx5mr15549390qab.49.1334586033512;
	Mon, 16 Apr 2012 07:20:33 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Mon, 16 Apr 2012 07:20:33 -0700 (PDT)
In-Reply-To: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
References: <1334575910.14560.146.camel@zakaz.uk.xensource.com>
Date: Mon, 16 Apr 2012 15:20:33 +0100
X-Google-Sender-Auth: Ww-C2Aaw_-K1dkVOHERpxb-fwWs
Message-ID: <CAFLBxZZPVf4jHBkyMNke0pr++Nw35WLRzLkdjSxYgTPQ-ajpnA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 12:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March =A0 =A0 =A0 =A0-- TODO list locked down
> 2 April =A0 =A0 =A0 =A0 -- Feature Freeze
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 << WE ARE HERE
> Mid/Late April =A0-- First release candidate
> Weekly =A0 =A0 =A0 =A0 =A0-- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> A bunch of new items have been added to the list, mainly due to Ian
> Jacksons review of the libxl API for stability. I believe these are
> mostly under control. Some of these are going to be immediately deferred
> to 4.3 but I have included them in this week's list to allow the
> opportunity for feedback.
>
> Some of the new items are unclaimed. Volunteers would be much
> appreciated.
>
> As discussed last week I have added known bugs to the lists below.
> Please refer me to any should or must be fixed bugs (best way it by
> responding to this mail with a pointer so my threading mailer will track
> it for next week).
>
> hypervisor, blockers:
> =A0 =A0 =A0* [BUG] Zombie driver domains. =A0There's a bug where PV guest=
s with
> =A0 =A0 =A0 =A0devices passed through with xl hang around as "zombies", w=
ith
> =A0 =A0 =A0 =A0one outstanding page reference. =A0I think this should rea=
lly be a
> =A0 =A0 =A0 =A0blocker. I'm working on this at the moment (George Dunlap).
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* One of several recent reports of Zombie doma=
ins, which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0may or may not be all related.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* List as hypervisor for now, but may turn out=
 to be a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tools issue.
>
> tools, blockers:
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. Involves AP=
I changes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* locking/serialization, e.g., for domain crea=
tion. [...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Deferred until 4.3. We think=
 this functionality
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0can be added without impac=
ting API stability.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_wait_for_free_memory/libxl_wait_for_me=
mory_target.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Interface needs an overhaul, related to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0locking/serialization over domain create (=
see above).
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IanJ to add note about this interface bein=
g substandard
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0but otherwise defer to 4.3.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_{FOO}_exec. Should return a data struc=
ture
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0declaring what to do, not fork and exec th=
emselves.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0However we can defer this until 4.3.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_*_path. Majority made internal, only c=
onfigdir and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lockdir remain public (used by xl). Good e=
nough?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Interfaces which may need to be async:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_suspend. Nobody=
 has looked at these
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at all. A volunteer would =
be appreciated.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_create_{new,res=
tore} -- IanJ has
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches as part of event s=
eries.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_{shutdown,reboo=
t}. These are "fast"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0functions and there do not=
 need to be async.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(So, DONE with no action r=
equired)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_core_dump. Can =
take a dummy ao_how
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and remain synchronous int=
ernally.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_{disk,nic,vkb,a=
dd}_add (and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remove?). Roger Pau Monn=
=E9 fixes disk as part of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hotplug script series and =
adds infrastructure
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0which should make the othe=
rs trivial.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_cdrom_insert. Should b=
e easy once
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0disk_{add,remove} done, Ia=
nJ to look at.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_disk_local_{att=
ach,detach}. Become
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0internal as part of Stefan=
o's domain 0 disk
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attach series.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_pci_{add,remove=
}. Less trivial than
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the others. A volunteer wo=
uld be appreciated.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_xen_console_*. No inte=
rface for waiting
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and each call just dumps a=
 bit more of the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ring , so is fast. Nothing=
 to do here (therefore
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_xen_tmem_*. All functi=
ons are "fast" and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0therefore no async needed.=
 Exception is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmem_destroy which Dan Mag=
enheimer says is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0obsolete and can just be r=
emoved.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_fork -- IanJ's event s=
eries removes all
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0users of this.
> =A0 =A0 =A0* [BUG] Manually ballooning dom0. =A0xl mem-set 0 [foo] fails =
with
> =A0 =A0 =A0 =A0"libxl: error: libxl.c:2569:libxl_set_memory_target: canno=
t get
> =A0 =A0 =A0 =A0memory info from /local/domain/0/memory/static-max: No suc=
h file
> =A0 =A0 =A0 =A0or directory". This might be suitable for an enthusiastic
> =A0 =A0 =A0 =A0on-looker. (George Dunlap, in the absence of said onlooker)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* None remaining?
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
> =A0 =A0 =A0* Domain 0 block attach & general hotplug when using qdisk bac=
kend
> =A0 =A0 =A0 =A0(need to start qemu as necessary etc) (Stefano S, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* file:// backend performance.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen-traditional and upstream qemu-xen p=
erformance
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has been improved and is now satisfactory.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Xen 4.2 will prefer blktap2 if a kernel modu=
le is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0available (e.g. older dom0 kernel or DKMS =
provided
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kernel module) and will fallback to qemu q=
disk if no
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0blktap2 is available.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* There will be no userspace "blktap3" for Xen=
 4.2
> =A0 =A0 =A0* Improved Hotplug script support (Roger Pau Monn=E9, patches
> =A0 =A0 =A0 =A0posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
>
> hypervisor, nice to have:
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "The last patch to use a waitqueue in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__get_gfn_type_access() from Tim works. =
=A0However, there
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are a few users who call __get_gfn_type_ac=
cess with the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_lock held. This part needs to be ad=
dressed in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some way."
> =A0 =A0 =A0* Sharing support for AMD (Tim, Andres).
> =A0 =A0 =A0* PoD performance improvements (George Dunlap)
>
> It seems that none of the above are going to happen for 4.2?

I'm still hoping to get the PoD patches in, but we'll see.

 -George

>
> tools, nice to have:
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring, lots of
> =A0 =A0 =A0 =A0discussion around interface, general consensus reached on =
what
> =A0 =A0 =A0 =A0it should look like. Olaf has let me know that he is proba=
bly
> =A0 =A0 =A0 =A0not going to have time to do this for 4.2, will likely sli=
p to
> =A0 =A0 =A0 =A04.3 unless someone else want to pick up that work)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, qemu patches applied, waiting =
for libxl etc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0side which has been recently reposted)
> =A0 =A0 =A0* Nested-virtualisation. Currently "experimental". Likely to
> =A0 =A0 =A0 =A0release that way.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested SVM. Tested in a variety of configura=
tions but
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still some issues with the most important =
use case (w7
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XP mode) [0] =A0(Christoph Egger)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested VMX. Needs nested EPT to be genuinely=
 useful.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Need more data on testedness etc (Intel)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, waiting on libxl side of qemu upstream save/rest=
ore)
> =A0 =A0 =A0* xl compatibility with xm:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for autospawning vncviewer (vncvi=
ewer=3D1 or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise) (Goncalo Gomes, waiting on new =
version of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga=
gn=E9, waiting
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0on new version of patches)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor=
ge Dunlap,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE)
>
> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:25:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmrS-0008Dj-Iy; Mon, 16 Apr 2012 14:24:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJmrR-0008DU-1b
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:24:57 +0000
Received: from [85.158.138.51:31387] by server-2.bemta-3.messagelabs.com id
	51/CC-09269-8BB2C8F4; Mon, 16 Apr 2012 14:24:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334586294!22390122!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9090 invoked from network); 16 Apr 2012 14:24:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 14:24:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GENvd5019096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 14:23:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GENtxn021300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 14:23:56 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GENtp7008209; Mon, 16 Apr 2012 09:23:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 07:23:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A38664027C; Mon, 16 Apr 2012 10:18:57 -0400 (EDT)
Date: Mon, 16 Apr 2012 10:18:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Nathan March <nathan@gt.net>
Message-ID: <20120416141857.GA1903@phenom.dumpdata.com>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
	<4F3DFE96.2030803@gt.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3DFE96.2030803@gt.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8C2B7E.0077,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >>I've still got 1 dom0 that's exhibiting the problem, if anyone is able
> >>to suggest any further debugging steps?
> >>
> >>- Nathan
> >>
> >>
> >>(XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1,
> >>pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011
> >>
> >>ukxen1 xen # xm info
> >>host                   : ukxen1
> >>release                : 3.0.3
> >>version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
> >>machine                : x86_64
> >>nr_cpus                : 24
> >>nr_nodes               : 2
> >>cores_per_socket       : 6
> >>threads_per_core       : 2
> >>cpu_mhz                : 2261
> >>hw_caps                :
> >>bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
> >>virt_caps              : hvm hvm_directio
> >>total_memory           : 98291
> >>free_memory            : 91908
> >>free_cpus              : 0
> >>xen_major              : 4
> >>xen_minor              : 1
> >>xen_extra              : .1
> >>xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> >>hvm-3.0-x86_32p hvm-3.0-x86_64
> >>xen_scheduler          : credit
> >>xen_pagesize           : 4096
> >>platform_params        : virt_start=0xffff800000000000
> >>xen_changeset          : unavailable
> >>xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1

It could be that you are running out of memory. So the pvops kernel
(or at least the one you are running) has a bug in that it will
allocate pages up to 98GB. The solution for that is to use
dom0_mem=max:1024M , not dom0_mem=1024M.

Please try that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:25:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmrS-0008Dj-Iy; Mon, 16 Apr 2012 14:24:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJmrR-0008DU-1b
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:24:57 +0000
Received: from [85.158.138.51:31387] by server-2.bemta-3.messagelabs.com id
	51/CC-09269-8BB2C8F4; Mon, 16 Apr 2012 14:24:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334586294!22390122!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9090 invoked from network); 16 Apr 2012 14:24:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 14:24:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GENvd5019096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 14:23:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GENtxn021300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 14:23:56 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GENtp7008209; Mon, 16 Apr 2012 09:23:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 07:23:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A38664027C; Mon, 16 Apr 2012 10:18:57 -0400 (EDT)
Date: Mon, 16 Apr 2012 10:18:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Nathan March <nathan@gt.net>
Message-ID: <20120416141857.GA1903@phenom.dumpdata.com>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
	<4F3DFE96.2030803@gt.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3DFE96.2030803@gt.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8C2B7E.0077,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >>I've still got 1 dom0 that's exhibiting the problem, if anyone is able
> >>to suggest any further debugging steps?
> >>
> >>- Nathan
> >>
> >>
> >>(XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1,
> >>pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011
> >>
> >>ukxen1 xen # xm info
> >>host                   : ukxen1
> >>release                : 3.0.3
> >>version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
> >>machine                : x86_64
> >>nr_cpus                : 24
> >>nr_nodes               : 2
> >>cores_per_socket       : 6
> >>threads_per_core       : 2
> >>cpu_mhz                : 2261
> >>hw_caps                :
> >>bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
> >>virt_caps              : hvm hvm_directio
> >>total_memory           : 98291
> >>free_memory            : 91908
> >>free_cpus              : 0
> >>xen_major              : 4
> >>xen_minor              : 1
> >>xen_extra              : .1
> >>xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> >>hvm-3.0-x86_32p hvm-3.0-x86_64
> >>xen_scheduler          : credit
> >>xen_pagesize           : 4096
> >>platform_params        : virt_start=0xffff800000000000
> >>xen_changeset          : unavailable
> >>xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1

It could be that you are running out of memory. So the pvops kernel
(or at least the one you are running) has a bug in that it will
allocate pages up to 98GB. The solution for that is to use
dom0_mem=max:1024M , not dom0_mem=1024M.

Please try that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:30:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmwr-0000HV-3Y; Mon, 16 Apr 2012 14:30:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJmwp-0000HB-I4
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:30:31 +0000
Received: from [85.158.143.99:6024] by server-2.bemta-4.messagelabs.com id
	60/FC-17550-60D2C8F4; Mon, 16 Apr 2012 14:30:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334586628!17487490!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9664 invoked from network); 16 Apr 2012 14:30:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 14:30:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GEUQED024911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 14:30:27 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GEUPZ5026464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 14:30:26 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GEUPPk022518; Mon, 16 Apr 2012 09:30:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 07:30:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 428314027C; Mon, 16 Apr 2012 10:25:27 -0400 (EDT)
Date: Mon, 16 Apr 2012 10:25:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>, konrad.wilk@oracle.com
Message-ID: <20120416142527.GC1903@phenom.dumpdata.com>
References: <CAO8_4VqSr_jdN+pkgoA_sxmtDsQzvJ+8U=tLqtqHYtRjzqcoPQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO8_4VqSr_jdN+pkgoA_sxmtDsQzvJ+8U=tLqtqHYtRjzqcoPQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F8C2D03.00C5,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Call Trace after insertion of modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 11:13:03PM +0530, Nupur Ghatnekar wrote:
> Hello,
> 
> I have written a small split device driver which caters to xenbus devices...
> attached is the call trace i got in the frontend driver.
> all i did was, inform the frontend when the backend was probed. after that,
> i got the attached call trace.
> Sorry i cant print it.. its looping continuously.
> Can you help me with debugging this?

You can post the driver - that might give us an idea what is wrong.
> 
> -- 
> 
> Nupur Ghatnekar


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:30:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJmwr-0000HV-3Y; Mon, 16 Apr 2012 14:30:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJmwp-0000HB-I4
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:30:31 +0000
Received: from [85.158.143.99:6024] by server-2.bemta-4.messagelabs.com id
	60/FC-17550-60D2C8F4; Mon, 16 Apr 2012 14:30:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334586628!17487490!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9664 invoked from network); 16 Apr 2012 14:30:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 14:30:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GEUQED024911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 14:30:27 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GEUPZ5026464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 14:30:26 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GEUPPk022518; Mon, 16 Apr 2012 09:30:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 07:30:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 428314027C; Mon, 16 Apr 2012 10:25:27 -0400 (EDT)
Date: Mon, 16 Apr 2012 10:25:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>, konrad.wilk@oracle.com
Message-ID: <20120416142527.GC1903@phenom.dumpdata.com>
References: <CAO8_4VqSr_jdN+pkgoA_sxmtDsQzvJ+8U=tLqtqHYtRjzqcoPQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO8_4VqSr_jdN+pkgoA_sxmtDsQzvJ+8U=tLqtqHYtRjzqcoPQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F8C2D03.00C5,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Call Trace after insertion of modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Mar 23, 2012 at 11:13:03PM +0530, Nupur Ghatnekar wrote:
> Hello,
> 
> I have written a small split device driver which caters to xenbus devices...
> attached is the call trace i got in the frontend driver.
> all i did was, inform the frontend when the backend was probed. after that,
> i got the attached call trace.
> Sorry i cant print it.. its looping continuously.
> Can you help me with debugging this?

You can post the driver - that might give us an idea what is wrong.
> 
> -- 
> 
> Nupur Ghatnekar


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJn6Y-0001Rg-C2; Mon, 16 Apr 2012 14:40:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1SJn6X-0001RW-A1
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:40:33 +0000
Received: from [85.158.143.99:17318] by server-1.bemta-4.messagelabs.com id
	73/74-20925-06F2C8F4; Mon, 16 Apr 2012 14:40:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334587228!23536170!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29547 invoked from network); 16 Apr 2012 14:40:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 14:40:31 -0000
X-TM-IMSS-Message-ID: <bce50cdc00000166@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id bce50cdc00000166 ;
	Mon, 16 Apr 2012 10:40:23 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q3GEeKk1032123; 
	Mon, 16 Apr 2012 10:40:20 -0400
Message-ID: <4F8C2F1A.6010109@tycho.nsa.gov>
Date: Mon, 16 Apr 2012 10:39:22 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Mukesh Rathor <mukesh.rathor@oracle.com>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
In-Reply-To: <20120413184705.77b4d316@mantra.us.oracle.com>
X-Enigmail-Version: 1.4
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/13/2012 09:47 PM, Mukesh Rathor wrote:
> On Mon, 26 Mar 2012 11:37:46 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>> I think that we should explicitly allocate these pages/addresses and
>> not rely on the fact that they are at a specific location that we deem
>> safe for now.
>> So if we explicitly introduce a new region at the end of the e820 that
>> we mark as reserved and we use it for this, I would be OK with that.
>> However we need to be careful because editing the e820 has proved to
>> be challenging in the past.
>> Also we would need to figure out a way to tell Linux that these
>> reserved addresses are actually OK to be used. Maybe we need a new
>> command line or hypercall for that.
> 
> That sounds like reasonable approach. Lets do it as part of phase II.
> I wanna get some basic code in.
> 
> So, to give an update of where I am, good news, I've got guests 
> finally booting using hybrid dom0. So, that means I am almost there 
> now!!!! Yeay...
> 
> But, the pfn space management for privcmd mapping is still a hack. 
> Running into many issues. Basially, it is forcing me to write a slab
> allocator for the resvd pfn space, that I am trying to avoid. During
> guest creation, xl process maps about 10k foreign pgs, and xenstored 1.
> 
> I was thinking of just dividing my pfn space into say 10 chunks, each
> with 10k pages, so 10 guest creations can happen simultaneously. But,
> then xl is not the only process doing the mapping I found out. xenstored
> also needs to map domU frames.

With Xen 4.2, xenstored should be using the grant table for its shared
page. Similar changes can be made to xenconsoled so that only the domain
build/migrate processes use map_foreign_range. I have a patch to xenconsoled
without the fallback to map_foreign_range sitting around; I was planning to
post it with proper fallback (which I may do soon, looks simple enough).

> Otherwise, I could just do one chunk
> per process. Also, I am breaking mmap semantics somewhat by hooking
> via privcmd_mmap, because the unmaps don't follow any order. So my last
> unmap frees the entire 10k chunk it's using. 
> 
> In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> for privcmd without writing a slab allocator. I think using mmap makes
> it harder, can't we just use ioctl to get the VA? Then, I could nicely
> do something like:
>   xl: 
>     - open(privcmd file)
>     - ioctl(get rsvd/e820 pfn handle)
>     - ioctl(get VA using above handle) /* alternate to mmap */
>     - ioctl(get VA1 using above handle) /* alternate to mmap */
>     ...
>     - ioctl(release handle)
>     - ioctl(release VA)
>     - close file
> 
> Is that an option (to change mmap to ioctl)? 
> 
> Hope that makes sense,
> 
> thanks,
> Mukesh
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJn6Y-0001Rg-C2; Mon, 16 Apr 2012 14:40:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1SJn6X-0001RW-A1
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:40:33 +0000
Received: from [85.158.143.99:17318] by server-1.bemta-4.messagelabs.com id
	73/74-20925-06F2C8F4; Mon, 16 Apr 2012 14:40:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334587228!23536170!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29547 invoked from network); 16 Apr 2012 14:40:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 14:40:31 -0000
X-TM-IMSS-Message-ID: <bce50cdc00000166@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id bce50cdc00000166 ;
	Mon, 16 Apr 2012 10:40:23 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q3GEeKk1032123; 
	Mon, 16 Apr 2012 10:40:20 -0400
Message-ID: <4F8C2F1A.6010109@tycho.nsa.gov>
Date: Mon, 16 Apr 2012 10:39:22 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Mukesh Rathor <mukesh.rathor@oracle.com>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
In-Reply-To: <20120413184705.77b4d316@mantra.us.oracle.com>
X-Enigmail-Version: 1.4
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/13/2012 09:47 PM, Mukesh Rathor wrote:
> On Mon, 26 Mar 2012 11:37:46 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>> I think that we should explicitly allocate these pages/addresses and
>> not rely on the fact that they are at a specific location that we deem
>> safe for now.
>> So if we explicitly introduce a new region at the end of the e820 that
>> we mark as reserved and we use it for this, I would be OK with that.
>> However we need to be careful because editing the e820 has proved to
>> be challenging in the past.
>> Also we would need to figure out a way to tell Linux that these
>> reserved addresses are actually OK to be used. Maybe we need a new
>> command line or hypercall for that.
> 
> That sounds like reasonable approach. Lets do it as part of phase II.
> I wanna get some basic code in.
> 
> So, to give an update of where I am, good news, I've got guests 
> finally booting using hybrid dom0. So, that means I am almost there 
> now!!!! Yeay...
> 
> But, the pfn space management for privcmd mapping is still a hack. 
> Running into many issues. Basially, it is forcing me to write a slab
> allocator for the resvd pfn space, that I am trying to avoid. During
> guest creation, xl process maps about 10k foreign pgs, and xenstored 1.
> 
> I was thinking of just dividing my pfn space into say 10 chunks, each
> with 10k pages, so 10 guest creations can happen simultaneously. But,
> then xl is not the only process doing the mapping I found out. xenstored
> also needs to map domU frames.

With Xen 4.2, xenstored should be using the grant table for its shared
page. Similar changes can be made to xenconsoled so that only the domain
build/migrate processes use map_foreign_range. I have a patch to xenconsoled
without the fallback to map_foreign_range sitting around; I was planning to
post it with proper fallback (which I may do soon, looks simple enough).

> Otherwise, I could just do one chunk
> per process. Also, I am breaking mmap semantics somewhat by hooking
> via privcmd_mmap, because the unmaps don't follow any order. So my last
> unmap frees the entire 10k chunk it's using. 
> 
> In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> for privcmd without writing a slab allocator. I think using mmap makes
> it harder, can't we just use ioctl to get the VA? Then, I could nicely
> do something like:
>   xl: 
>     - open(privcmd file)
>     - ioctl(get rsvd/e820 pfn handle)
>     - ioctl(get VA using above handle) /* alternate to mmap */
>     - ioctl(get VA1 using above handle) /* alternate to mmap */
>     ...
>     - ioctl(release handle)
>     - ioctl(release VA)
>     - close file
> 
> Is that an option (to change mmap to ioctl)? 
> 
> Hope that makes sense,
> 
> thanks,
> Mukesh
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:44:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:44:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJn9j-0001h0-WF; Mon, 16 Apr 2012 14:43:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJn9i-0001gi-Gh
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:43:50 +0000
Received: from [193.109.254.147:51848] by server-9.bemta-14.messagelabs.com id
	AE/31-05787-5203C8F4; Mon, 16 Apr 2012 14:43:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334587427!4827983!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11450 invoked from network); 16 Apr 2012 14:43:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:43:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190518458"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:43:27 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:43:27 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SJn9L-0000s2-4z;
	Mon, 16 Apr 2012 15:43:27 +0100
MIME-Version: 1.0
X-Mercurial-Node: a20c43492fbff622aa9746404981628b498e0711
Message-ID: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 15:43:26 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334587303 -3600
# Node ID a20c43492fbff622aa9746404981628b498e0711
# Parent  f95c8fe372d35fdf8937750e9271ea76ff991488
libxl: add a dummy ao_how to libxl_domain_core_dump

Although this function is not currently slow it may become so in the future
(this also depends somewhat on the size of the guest).  Therefore arrange for
it to take an ao_how which it completes immediately.  This will allow us to
make it asynchronous in the future without breaking API compatibility.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used"

diff -r f95c8fe372d3 -r a20c43492fbf tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Apr 16 15:41:43 2012 +0100
@@ -627,16 +627,22 @@ int libxl_domain_pause(libxl_ctx *ctx, u
 }
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
-                           const char *filename)
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how)
 {
-    int ret;
+    AO_CREATE(ctx, domid, ao_how);
+    int ret, rc = 0;
+
     ret = xc_domain_dumpcore(ctx->xch, domid, filename);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
                      domid, filename);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL;
     }
-    return 0;
+
+    libxl__ao_complete(egc, ao, rc);
+
+    return AO_INPROGRESS;
 }
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
diff -r f95c8fe372d3 -r a20c43492fbf tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.h	Mon Apr 16 15:41:43 2012 +0100
@@ -509,7 +509,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
-int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
+int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how);
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
diff -r f95c8fe372d3 -r a20c43492fbf tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 16 15:41:43 2012 +0100
@@ -1276,7 +1276,7 @@ static int handle_domain_death(libxl_ctx
             LOG("failed to construct core dump path");
         } else {
             LOG("dumping core to %s", corefile);
-            rc=libxl_domain_core_dump(ctx, domid, corefile);
+            rc=libxl_domain_core_dump(ctx, domid, corefile, NULL);
             if (rc) LOG("core dump failed (rc=%d).", rc);
         }
         /* No point crying over spilled milk, continue on failure. */
@@ -2893,7 +2893,7 @@ static void core_dump_domain(const char 
 {
     int rc;
     find_domain(domain_spec);
-    rc=libxl_domain_core_dump(ctx, domid, filename);
+    rc=libxl_domain_core_dump(ctx, domid, filename, NULL);
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:44:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:44:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJn9j-0001h0-WF; Mon, 16 Apr 2012 14:43:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJn9i-0001gi-Gh
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:43:50 +0000
Received: from [193.109.254.147:51848] by server-9.bemta-14.messagelabs.com id
	AE/31-05787-5203C8F4; Mon, 16 Apr 2012 14:43:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334587427!4827983!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11450 invoked from network); 16 Apr 2012 14:43:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:43:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190518458"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:43:27 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 10:43:27 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SJn9L-0000s2-4z;
	Mon, 16 Apr 2012 15:43:27 +0100
MIME-Version: 1.0
X-Mercurial-Node: a20c43492fbff622aa9746404981628b498e0711
Message-ID: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 15:43:26 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334587303 -3600
# Node ID a20c43492fbff622aa9746404981628b498e0711
# Parent  f95c8fe372d35fdf8937750e9271ea76ff991488
libxl: add a dummy ao_how to libxl_domain_core_dump

Although this function is not currently slow it may become so in the future
(this also depends somewhat on the size of the guest).  Therefore arrange for
it to take an ao_how which it completes immediately.  This will allow us to
make it asynchronous in the future without breaking API compatibility.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used"

diff -r f95c8fe372d3 -r a20c43492fbf tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Apr 16 15:41:43 2012 +0100
@@ -627,16 +627,22 @@ int libxl_domain_pause(libxl_ctx *ctx, u
 }
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
-                           const char *filename)
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how)
 {
-    int ret;
+    AO_CREATE(ctx, domid, ao_how);
+    int ret, rc = 0;
+
     ret = xc_domain_dumpcore(ctx->xch, domid, filename);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
                      domid, filename);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL;
     }
-    return 0;
+
+    libxl__ao_complete(egc, ao, rc);
+
+    return AO_INPROGRESS;
 }
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
diff -r f95c8fe372d3 -r a20c43492fbf tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.h	Mon Apr 16 15:41:43 2012 +0100
@@ -509,7 +509,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
-int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
+int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how);
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
diff -r f95c8fe372d3 -r a20c43492fbf tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 16 15:41:43 2012 +0100
@@ -1276,7 +1276,7 @@ static int handle_domain_death(libxl_ctx
             LOG("failed to construct core dump path");
         } else {
             LOG("dumping core to %s", corefile);
-            rc=libxl_domain_core_dump(ctx, domid, corefile);
+            rc=libxl_domain_core_dump(ctx, domid, corefile, NULL);
             if (rc) LOG("core dump failed (rc=%d).", rc);
         }
         /* No point crying over spilled milk, continue on failure. */
@@ -2893,7 +2893,7 @@ static void core_dump_domain(const char 
 {
     int rc;
     find_domain(domain_spec);
-    rc=libxl_domain_core_dump(ctx, domid, filename);
+    rc=libxl_domain_core_dump(ctx, domid, filename, NULL);
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:44:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnA2-0001jI-FN; Mon, 16 Apr 2012 14:44:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnA0-0001j2-Sf
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:44:09 +0000
Received: from [193.109.254.147:53540] by server-2.bemta-14.messagelabs.com id
	CD/70-19409-8303C8F4; Mon, 16 Apr 2012 14:44:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334587445!4846415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28944 invoked from network); 16 Apr 2012 14:44:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:44:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:44:05 +0100
Message-ID: <1334587438.14560.200.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 15:43:58 +0100
In-Reply-To: <1334342414-10289-14-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-14-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 13/20] libxl: Allow AO_GC and EGC_GC even if
 not used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:40 +0100, Ian Jackson wrote:
> Mark the gc produced by AO_GC and EGC_GC with the gcc feature
> __attribute__((unused)).  This allows the use of EGC_INIT and
> STATE_AO_GC by functions which do actually use the gc.
> 
> This is convenient because those functions might want to use the ao or
> egc, rather than the gc; and also because it means that functions
> which morally ought to be fishing any gc they use out of an egc or
> state structure can be written do so regardless of whether the gc is
> actually used right then.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Needed this for one of my patches (just sent, with a reference to this
patch). So:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4cfb8d5..74dc2c5 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1280,7 +1280,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  /* useful for all functions which take an egc: */
>  
>  #define EGC_GC                                  \
> -    libxl__gc *const gc = &egc->gc
> +    libxl__gc *const gc __attribute__((unused)) = &egc->gc
>  
>  /* egc initialisation and destruction: */
>  
> @@ -1383,7 +1383,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>      })
>  
>  #define AO_GC                                   \
> -    libxl__gc *const gc = &ao->gc
> +    libxl__gc *const gc __attribute__((unused)) = &ao->gc
>  
>  #define STATE_AO_GC(op_ao)                      \
>      libxl__ao *const ao = (op_ao);              \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:44:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnA2-0001jI-FN; Mon, 16 Apr 2012 14:44:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnA0-0001j2-Sf
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:44:09 +0000
Received: from [193.109.254.147:53540] by server-2.bemta-14.messagelabs.com id
	CD/70-19409-8303C8F4; Mon, 16 Apr 2012 14:44:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334587445!4846415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28944 invoked from network); 16 Apr 2012 14:44:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:44:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:44:05 +0100
Message-ID: <1334587438.14560.200.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 15:43:58 +0100
In-Reply-To: <1334342414-10289-14-git-send-email-ian.jackson@eu.citrix.com>
References: <1334342414-10289-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334342414-10289-14-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 13/20] libxl: Allow AO_GC and EGC_GC even if
 not used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-13 at 19:40 +0100, Ian Jackson wrote:
> Mark the gc produced by AO_GC and EGC_GC with the gcc feature
> __attribute__((unused)).  This allows the use of EGC_INIT and
> STATE_AO_GC by functions which do actually use the gc.
> 
> This is convenient because those functions might want to use the ao or
> egc, rather than the gc; and also because it means that functions
> which morally ought to be fishing any gc they use out of an egc or
> state structure can be written do so regardless of whether the gc is
> actually used right then.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Needed this for one of my patches (just sent, with a reference to this
patch). So:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4cfb8d5..74dc2c5 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1280,7 +1280,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  /* useful for all functions which take an egc: */
>  
>  #define EGC_GC                                  \
> -    libxl__gc *const gc = &egc->gc
> +    libxl__gc *const gc __attribute__((unused)) = &egc->gc
>  
>  /* egc initialisation and destruction: */
>  
> @@ -1383,7 +1383,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>      })
>  
>  #define AO_GC                                   \
> -    libxl__gc *const gc = &ao->gc
> +    libxl__gc *const gc __attribute__((unused)) = &ao->gc
>  
>  #define STATE_AO_GC(op_ao)                      \
>      libxl__ao *const ao = (op_ao);              \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnFt-0002Ku-3Z; Mon, 16 Apr 2012 14:50:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJnFr-0002Km-7T
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:50:11 +0000
Received: from [85.158.143.35:16168] by server-1.bemta-4.messagelabs.com id
	09/93-20925-2A13C8F4; Mon, 16 Apr 2012 14:50:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334587805!13485441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27820 invoked from network); 16 Apr 2012 14:50:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958415"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:50:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 15:50:05 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJnFk-0002jB-Sx;
	Mon, 16 Apr 2012 14:50:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJnFk-0006Uy-Mp;
	Mon, 16 Apr 2012 15:50:04 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12699-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 15:50:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12699: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12699 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12699/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                e816b57a337ea3b755de72bec38c10c864f23015
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnFt-0002Ku-3Z; Mon, 16 Apr 2012 14:50:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJnFr-0002Km-7T
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:50:11 +0000
Received: from [85.158.143.35:16168] by server-1.bemta-4.messagelabs.com id
	09/93-20925-2A13C8F4; Mon, 16 Apr 2012 14:50:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334587805!13485441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27820 invoked from network); 16 Apr 2012 14:50:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958415"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:50:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 15:50:05 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJnFk-0002jB-Sx;
	Mon, 16 Apr 2012 14:50:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJnFk-0006Uy-Mp;
	Mon, 16 Apr 2012 15:50:04 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12699-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 15:50:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12699: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12699 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12699/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                e816b57a337ea3b755de72bec38c10c864f23015
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnMb-0002aa-Pp; Mon, 16 Apr 2012 14:57:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnMZ-0002aF-RM
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:57:08 +0000
Received: from [85.158.143.35:60128] by server-2.bemta-4.messagelabs.com id
	24/C7-17550-3433C8F4; Mon, 16 Apr 2012 14:57:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334588225!14760826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1793 invoked from network); 16 Apr 2012 14:57:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:57:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:57:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:57:05 +0100
Message-ID: <1334588223.14560.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lloyd Dizon <thecarrionkind@gmail.com>
Date: Mon, 16 Apr 2012 15:57:03 +0100
In-Reply-To: <CAFj8LaeXZNzSaNVcAMU1r3svwh4UrZLhv1wZfXn7_UHaT7A3GA@mail.gmail.com>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
	<CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
	<1334570256.14560.80.camel@zakaz.uk.xensource.com>
	<CAFj8LaeXZNzSaNVcAMU1r3svwh4UrZLhv1wZfXn7_UHaT7A3GA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Todd Deshane <todd.deshane@xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Remi Gacogne <rgacogne-xen@valombre.net>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 15:45 +0100, Lloyd Dizon wrote:
> On Mon, Apr 16, 2012 at 11:57 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > On Fri, 2012-04-13 at 18:22 +0100, Todd Deshane wrote:
> > > Adding Xen-devel.
> > >
> > > What are the current timekeeping best practices now?
> >
> > pvops kernels behave as if independent_wallclock == 1, so the existing
> > advice:
> >        set /proc/sys/xen/independent_wallclock to 1 and run ntp on
> >        domU.
> > still applies.
> 
> This also applies to Xen 4.0 (4.0.0) if I understood correctly?

This is entirely a function of the guest kernel version and not the
hypervisor

> If so and based on previous posts can we resume that this is what is
> recommended:

If you s/Xen3/Classic XenoLinux Kernels/ and s/Xen4/Paravirt Ops Linux
Kernels/g then I think it is somewhat accurate, at least for the PV
line.

I must confess I don't really know for the HVM line. I suspect that it
is actually:

Classic XenoLinux -- no PV time source, independent_wallclock means
nothing, run NTP in the guest

Paravirt ops kernels _without_ PV time PVHVM extensions -- no PV time
source, independent_wallclock means nothing, run NTP in the guest

Paravirt ops kernels _with_ PV time PVHVM extensions -- PV time source,
independent_wallclock always == 1, run NTP.

So in short always run NTP in an HVM guest, regardless of the presence
or absence of PV time extensions.

>         |        Xen3                     |          Xen4               |
> ---------------------------------------------------------------------
> PV    | independent_wallclock = 0 or 1  | independent_wallclock =  1  |
> ---------------------------------------------------------------------
> HVM | independent_wallclock = 0       | independent_wallclock =  1  |
> ---------------------------------------------------------------------
> 
> With priority to independent_wallclock=1 and if activated, ntp required.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnMb-0002aa-Pp; Mon, 16 Apr 2012 14:57:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnMZ-0002aF-RM
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:57:08 +0000
Received: from [85.158.143.35:60128] by server-2.bemta-4.messagelabs.com id
	24/C7-17550-3433C8F4; Mon, 16 Apr 2012 14:57:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334588225!14760826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1793 invoked from network); 16 Apr 2012 14:57:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:57:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:57:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:57:05 +0100
Message-ID: <1334588223.14560.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lloyd Dizon <thecarrionkind@gmail.com>
Date: Mon, 16 Apr 2012 15:57:03 +0100
In-Reply-To: <CAFj8LaeXZNzSaNVcAMU1r3svwh4UrZLhv1wZfXn7_UHaT7A3GA@mail.gmail.com>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
	<CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
	<1334570256.14560.80.camel@zakaz.uk.xensource.com>
	<CAFj8LaeXZNzSaNVcAMU1r3svwh4UrZLhv1wZfXn7_UHaT7A3GA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Todd Deshane <todd.deshane@xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Remi Gacogne <rgacogne-xen@valombre.net>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 15:45 +0100, Lloyd Dizon wrote:
> On Mon, Apr 16, 2012 at 11:57 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > On Fri, 2012-04-13 at 18:22 +0100, Todd Deshane wrote:
> > > Adding Xen-devel.
> > >
> > > What are the current timekeeping best practices now?
> >
> > pvops kernels behave as if independent_wallclock == 1, so the existing
> > advice:
> >        set /proc/sys/xen/independent_wallclock to 1 and run ntp on
> >        domU.
> > still applies.
> 
> This also applies to Xen 4.0 (4.0.0) if I understood correctly?

This is entirely a function of the guest kernel version and not the
hypervisor

> If so and based on previous posts can we resume that this is what is
> recommended:

If you s/Xen3/Classic XenoLinux Kernels/ and s/Xen4/Paravirt Ops Linux
Kernels/g then I think it is somewhat accurate, at least for the PV
line.

I must confess I don't really know for the HVM line. I suspect that it
is actually:

Classic XenoLinux -- no PV time source, independent_wallclock means
nothing, run NTP in the guest

Paravirt ops kernels _without_ PV time PVHVM extensions -- no PV time
source, independent_wallclock means nothing, run NTP in the guest

Paravirt ops kernels _with_ PV time PVHVM extensions -- PV time source,
independent_wallclock always == 1, run NTP.

So in short always run NTP in an HVM guest, regardless of the presence
or absence of PV time extensions.

>         |        Xen3                     |          Xen4               |
> ---------------------------------------------------------------------
> PV    | independent_wallclock = 0 or 1  | independent_wallclock =  1  |
> ---------------------------------------------------------------------
> HVM | independent_wallclock = 0       | independent_wallclock =  1  |
> ---------------------------------------------------------------------
> 
> With priority to independent_wallclock=1 and if activated, ntp required.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:59:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnP4-0002rB-FQ; Mon, 16 Apr 2012 14:59:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnP2-0002qv-Uq
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:59:41 +0000
Received: from [85.158.143.99:15936] by server-1.bemta-4.messagelabs.com id
	41/52-20925-CD33C8F4; Mon, 16 Apr 2012 14:59:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334588379!14092974!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 16 Apr 2012 14:59:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:59:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:59:39 +0100
Message-ID: <1334588378.14560.207.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 16 Apr 2012 15:59:38 +0100
In-Reply-To: <4F8C2F1A.6010109@tycho.nsa.gov>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<4F8C2F1A.6010109@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 15:39 +0100, Daniel De Graaf wrote:
> On 04/13/2012 09:47 PM, Mukesh Rathor wrote:
> > I was thinking of just dividing my pfn space into say 10 chunks, each
> > with 10k pages, so 10 guest creations can happen simultaneously. But,
> > then xl is not the only process doing the mapping I found out. xenstored
> > also needs to map domU frames.
> 
> With Xen 4.2, xenstored should be using the grant table for its shared
> page. Similar changes can be made to xenconsoled so that only the domain
> build/migrate processes use map_foreign_range. I have a patch to xenconsoled
> without the fallback to map_foreign_range sitting around; I was planning to
> post it with proper fallback (which I may do soon, looks simple enough).

That sounds like a good thing to have, although I don't think we'd take
it for 4.2 at this point so you've got some time.

I think the privcmd stuff needs to still assume that domain build is not
the only privileged mapper of pages and do proper tracking of what it
has mapped where. Various debug utilities etc also use this interface,
i.e. xenctx (and gdbsx? I suppose Mukesh would know ;-))

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 14:59:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 14:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnP4-0002rB-FQ; Mon, 16 Apr 2012 14:59:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnP2-0002qv-Uq
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 14:59:41 +0000
Received: from [85.158.143.99:15936] by server-1.bemta-4.messagelabs.com id
	41/52-20925-CD33C8F4; Mon, 16 Apr 2012 14:59:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334588379!14092974!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 16 Apr 2012 14:59:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11958654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:59:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 15:59:39 +0100
Message-ID: <1334588378.14560.207.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 16 Apr 2012 15:59:38 +0100
In-Reply-To: <4F8C2F1A.6010109@tycho.nsa.gov>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<4F8C2F1A.6010109@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 15:39 +0100, Daniel De Graaf wrote:
> On 04/13/2012 09:47 PM, Mukesh Rathor wrote:
> > I was thinking of just dividing my pfn space into say 10 chunks, each
> > with 10k pages, so 10 guest creations can happen simultaneously. But,
> > then xl is not the only process doing the mapping I found out. xenstored
> > also needs to map domU frames.
> 
> With Xen 4.2, xenstored should be using the grant table for its shared
> page. Similar changes can be made to xenconsoled so that only the domain
> build/migrate processes use map_foreign_range. I have a patch to xenconsoled
> without the fallback to map_foreign_range sitting around; I was planning to
> post it with proper fallback (which I may do soon, looks simple enough).

That sounds like a good thing to have, although I don't think we'd take
it for 4.2 at this point so you've got some time.

I think the privcmd stuff needs to still assume that domain build is not
the only privileged mapper of pages and do proper tracking of what it
has mapped where. Various debug utilities etc also use this interface,
i.e. xenctx (and gdbsx? I suppose Mukesh would know ;-))

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:00:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnPD-0002tI-1E; Mon, 16 Apr 2012 14:59:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SJnPB-0002sl-Gk
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:59:49 +0000
Received: from [85.158.143.35:18461] by server-1.bemta-4.messagelabs.com id
	F4/82-20925-4E33C8F4; Mon, 16 Apr 2012 14:59:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334588386!12670555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20165 invoked from network); 16 Apr 2012 14:59:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:59:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190522964"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:59:46 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012
	10:59:46 -0400
Message-ID: <4F8C33E0.2080007@citrix.com>
Date: Mon, 16 Apr 2012 15:59:44 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
In-Reply-To: <4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/04/12 12:32, Jan Beulich wrote:
>>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> The sched clock was considered stable based on the capabilities of the
>> underlying hardware.  This does not make sense for Xen PV guests as:
>> a) the hardware TSC is not used directly as the clock source; and b)
>> guests may migrate to hosts with different hardware capabilities.
>>
>> It is not clear to me whether the Xen clock source is supposed to be
>> stable and whether it should be stable across migration.  For a clock
>> source to be stable it must be: a) monotonic; c) synchronized across
>> CPUs; and c) constant rate.

Tim, Thomas, can you comment on the above paragraph?  Is it correct?

>> There have also been reports of systems with apparently unstable
>> clocks where clearing sched_clock_stable has fixed problems with
>> migrated VMs hanging.
>>
>> So, always set the sched clock as unstable when using the Xen clock
>> source.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  arch/x86/xen/time.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 0296a95..8469b5a 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>>  	do_settimeofday(&tp);
>>  
>>  	setup_force_cpu_cap(X86_FEATURE_TSC);
>> +	sched_clock_stable = 0;
> 
> This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> post-boot, the variable may need to be cleared again. Instead you
> ought to call mark_tsc_unstable().

Yeah, mark_tsc_unstable() is the right thing to do.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:00:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnPD-0002tI-1E; Mon, 16 Apr 2012 14:59:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SJnPB-0002sl-Gk
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 14:59:49 +0000
Received: from [85.158.143.35:18461] by server-1.bemta-4.messagelabs.com id
	F4/82-20925-4E33C8F4; Mon, 16 Apr 2012 14:59:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334588386!12670555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20165 invoked from network); 16 Apr 2012 14:59:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 14:59:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190522964"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 10:59:46 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012
	10:59:46 -0400
Message-ID: <4F8C33E0.2080007@citrix.com>
Date: Mon, 16 Apr 2012 15:59:44 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
In-Reply-To: <4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/04/12 12:32, Jan Beulich wrote:
>>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> The sched clock was considered stable based on the capabilities of the
>> underlying hardware.  This does not make sense for Xen PV guests as:
>> a) the hardware TSC is not used directly as the clock source; and b)
>> guests may migrate to hosts with different hardware capabilities.
>>
>> It is not clear to me whether the Xen clock source is supposed to be
>> stable and whether it should be stable across migration.  For a clock
>> source to be stable it must be: a) monotonic; c) synchronized across
>> CPUs; and c) constant rate.

Tim, Thomas, can you comment on the above paragraph?  Is it correct?

>> There have also been reports of systems with apparently unstable
>> clocks where clearing sched_clock_stable has fixed problems with
>> migrated VMs hanging.
>>
>> So, always set the sched clock as unstable when using the Xen clock
>> source.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  arch/x86/xen/time.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 0296a95..8469b5a 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>>  	do_settimeofday(&tp);
>>  
>>  	setup_force_cpu_cap(X86_FEATURE_TSC);
>> +	sched_clock_stable = 0;
> 
> This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> post-boot, the variable may need to be cleared again. Instead you
> ought to call mark_tsc_unstable().

Yeah, mark_tsc_unstable() is the right thing to do.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:01:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnQs-0003D9-Hg; Mon, 16 Apr 2012 15:01:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnQq-0003Co-Nz
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:01:32 +0000
Received: from [85.158.143.35:31022] by server-1.bemta-4.messagelabs.com id
	68/95-20925-C443C8F4; Mon, 16 Apr 2012 15:01:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334588489!5069253!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29879 invoked from network); 16 Apr 2012 15:01:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:01:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190523462"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:01:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:01:24 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SJnQh-00018y-K8;
	Mon, 16 Apr 2012 16:01:23 +0100
MIME-Version: 1.0
X-Mercurial-Node: bf46871ecfeee48a86855823df835a1ff174429e
Message-ID: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 16:01:23 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and associated
	xl command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334588447 -3600
# Node ID bf46871ecfeee48a86855823df835a1ff174429e
# Parent  a20c43492fbff622aa9746404981628b498e0711
libxl: Remove libxl_tmem_destroy and associated xl command

Dan Magenheimer explains in <4c2f7fca-dda2-4598-aaab-3a6a3fe532cd@default>:

	I think the tmem_destroy functionality pre-dates the
	existence of tmem "freeable" memory* and was a way for
	a toolset to force the hypervisor to free up the hypervisor
	memory used by some or all ephemeral tmem pools.  Once the
	tmem allocation/free process was directly linked into
	alloc_heap_pages() in the hypervisor (see call to
	tmem_relinquish_pages()), this forcing function was
	no longer needed.

	So, bottom line, I *think* it can be ripped out, or at least
	for now removed from the definition of the stable xl API/UI.
	The libxl.c routine libxl_tmem_destroy() could also be
	removed if you like, but I guess I'd prefer to leave the
	lower level droppings in xc.c and in the hypervisor in case
	I am misremembering.

Accordingly remove this interface from libxl and xl but don't touch libxc or
the hypervisor.

This is the only libxl_tmem_* function which might potentially have required
conversion to be asynchronous and which therefore might have been a potential
API stability concern.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a20c43492fbf -r bf46871ecfee docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Apr 16 15:41:43 2012 +0100
+++ b/docs/man/xl.pod.1	Mon Apr 16 16:00:47 2012 +0100
@@ -1055,10 +1055,6 @@ List tmem pools. If I<-l> is specified, 
 
 Freeze tmem pools.
 
-=item B<tmem-destroy> I<domain-id>
-
-Destroy tmem pools.
-
 =item B<tmem-thaw> I<domain-id>
 
 Thaw tmem pools.
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Apr 16 16:00:47 2012 +0100
@@ -3495,21 +3495,6 @@ int libxl_tmem_freeze(libxl_ctx *ctx, ui
     return rc;
 }
 
-int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid)
-{
-    int rc;
-
-    rc = xc_tmem_control(ctx->xch, -1, TMEMC_DESTROY, domid, 0, 0,
-                         0, NULL);
-    if (rc < 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-            "Can not destroy tmem pools");
-        return ERROR_FAIL;
-    }
-
-    return rc;
-}
-
 int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid)
 {
     int rc;
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/libxl.h	Mon Apr 16 16:00:47 2012 +0100
@@ -757,7 +757,6 @@ uint32_t libxl_vm_get_start_time(libxl_c
 
 char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long);
 int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
-int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
 int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
                    uint32_t set);
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/xl.h	Mon Apr 16 16:00:47 2012 +0100
@@ -76,7 +76,6 @@ int main_blockdetach(int argc, char **ar
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
-int main_tmem_destroy(int argc, char **argv);
 int main_tmem_thaw(int argc, char **argv);
 int main_tmem_set(int argc, char **argv);
 int main_tmem_shared_auth(int argc, char **argv);
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 16 16:00:47 2012 +0100
@@ -5348,38 +5348,6 @@ int main_tmem_freeze(int argc, char **ar
     return 0;
 }
 
-int main_tmem_destroy(int argc, char **argv)
-{
-    const char *dom = NULL;
-    int all = 0;
-    int opt;
-
-    while ((opt = def_getopt(argc, argv, "a", "tmem-destroy", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        }
-    }
-
-    dom = argv[optind];
-    if (!dom && all == 0) {
-        fprintf(stderr, "You must specify -a or a domain id.\n\n");
-        help("tmem-destroy");
-        return 1;
-    }
-
-    if (all)
-        domid = -1;
-    else
-        find_domain(dom);
-
-    libxl_tmem_destroy(ctx, domid);
-    return 0;
-}
-
 int main_tmem_thaw(int argc, char **argv)
 {
     const char *dom = NULL;
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Apr 16 16:00:47 2012 +0100
@@ -336,12 +336,6 @@ struct cmd_spec cmd_table[] = {
       "[<Domain>|-a]",
       "  -a                             Freeze all tmem",
     },
-    { "tmem-destroy",
-      &main_tmem_destroy, 0,
-      "Destroy tmem pools",
-      "[<Domain>|-a]",
-      "  -a                             Destroy all tmem",
-    },
     { "tmem-thaw",
       &main_tmem_thaw, 0,
       "Thaw tmem pools",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:01:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnQs-0003D9-Hg; Mon, 16 Apr 2012 15:01:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJnQq-0003Co-Nz
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:01:32 +0000
Received: from [85.158.143.35:31022] by server-1.bemta-4.messagelabs.com id
	68/95-20925-C443C8F4; Mon, 16 Apr 2012 15:01:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334588489!5069253!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29879 invoked from network); 16 Apr 2012 15:01:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:01:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190523462"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:01:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:01:24 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SJnQh-00018y-K8;
	Mon, 16 Apr 2012 16:01:23 +0100
MIME-Version: 1.0
X-Mercurial-Node: bf46871ecfeee48a86855823df835a1ff174429e
Message-ID: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 16:01:23 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and associated
	xl command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334588447 -3600
# Node ID bf46871ecfeee48a86855823df835a1ff174429e
# Parent  a20c43492fbff622aa9746404981628b498e0711
libxl: Remove libxl_tmem_destroy and associated xl command

Dan Magenheimer explains in <4c2f7fca-dda2-4598-aaab-3a6a3fe532cd@default>:

	I think the tmem_destroy functionality pre-dates the
	existence of tmem "freeable" memory* and was a way for
	a toolset to force the hypervisor to free up the hypervisor
	memory used by some or all ephemeral tmem pools.  Once the
	tmem allocation/free process was directly linked into
	alloc_heap_pages() in the hypervisor (see call to
	tmem_relinquish_pages()), this forcing function was
	no longer needed.

	So, bottom line, I *think* it can be ripped out, or at least
	for now removed from the definition of the stable xl API/UI.
	The libxl.c routine libxl_tmem_destroy() could also be
	removed if you like, but I guess I'd prefer to leave the
	lower level droppings in xc.c and in the hypervisor in case
	I am misremembering.

Accordingly remove this interface from libxl and xl but don't touch libxc or
the hypervisor.

This is the only libxl_tmem_* function which might potentially have required
conversion to be asynchronous and which therefore might have been a potential
API stability concern.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a20c43492fbf -r bf46871ecfee docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Apr 16 15:41:43 2012 +0100
+++ b/docs/man/xl.pod.1	Mon Apr 16 16:00:47 2012 +0100
@@ -1055,10 +1055,6 @@ List tmem pools. If I<-l> is specified, 
 
 Freeze tmem pools.
 
-=item B<tmem-destroy> I<domain-id>
-
-Destroy tmem pools.
-
 =item B<tmem-thaw> I<domain-id>
 
 Thaw tmem pools.
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Apr 16 16:00:47 2012 +0100
@@ -3495,21 +3495,6 @@ int libxl_tmem_freeze(libxl_ctx *ctx, ui
     return rc;
 }
 
-int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid)
-{
-    int rc;
-
-    rc = xc_tmem_control(ctx->xch, -1, TMEMC_DESTROY, domid, 0, 0,
-                         0, NULL);
-    if (rc < 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-            "Can not destroy tmem pools");
-        return ERROR_FAIL;
-    }
-
-    return rc;
-}
-
 int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid)
 {
     int rc;
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/libxl.h	Mon Apr 16 16:00:47 2012 +0100
@@ -757,7 +757,6 @@ uint32_t libxl_vm_get_start_time(libxl_c
 
 char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long);
 int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
-int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
 int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
                    uint32_t set);
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/xl.h	Mon Apr 16 16:00:47 2012 +0100
@@ -76,7 +76,6 @@ int main_blockdetach(int argc, char **ar
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
-int main_tmem_destroy(int argc, char **argv);
 int main_tmem_thaw(int argc, char **argv);
 int main_tmem_set(int argc, char **argv);
 int main_tmem_shared_auth(int argc, char **argv);
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 16 16:00:47 2012 +0100
@@ -5348,38 +5348,6 @@ int main_tmem_freeze(int argc, char **ar
     return 0;
 }
 
-int main_tmem_destroy(int argc, char **argv)
-{
-    const char *dom = NULL;
-    int all = 0;
-    int opt;
-
-    while ((opt = def_getopt(argc, argv, "a", "tmem-destroy", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        }
-    }
-
-    dom = argv[optind];
-    if (!dom && all == 0) {
-        fprintf(stderr, "You must specify -a or a domain id.\n\n");
-        help("tmem-destroy");
-        return 1;
-    }
-
-    if (all)
-        domid = -1;
-    else
-        find_domain(dom);
-
-    libxl_tmem_destroy(ctx, domid);
-    return 0;
-}
-
 int main_tmem_thaw(int argc, char **argv)
 {
     const char *dom = NULL;
diff -r a20c43492fbf -r bf46871ecfee tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Apr 16 15:41:43 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Apr 16 16:00:47 2012 +0100
@@ -336,12 +336,6 @@ struct cmd_spec cmd_table[] = {
       "[<Domain>|-a]",
       "  -a                             Freeze all tmem",
     },
-    { "tmem-destroy",
-      &main_tmem_destroy, 0,
-      "Destroy tmem pools",
-      "[<Domain>|-a]",
-      "  -a                             Destroy all tmem",
-    },
     { "tmem-thaw",
       &main_tmem_thaw, 0,
       "Thaw tmem pools",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnVy-0003le-0X; Mon, 16 Apr 2012 15:06:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnVw-0003lN-Me
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:06:48 +0000
Received: from [85.158.143.35:10865] by server-3.bemta-4.messagelabs.com id
	BC/A0-05853-8853C8F4; Mon, 16 Apr 2012 15:06:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334588806!12930686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 720 invoked from network); 16 Apr 2012 15:06:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:06:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24195838"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-Dg	for xen-devel@lists.xen.org;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:39 +0100
Message-ID: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/5] libxl: call hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series removes the use of udev rules to call hotplug scripts when using
libxl. Scripts are directly called from the toolstack at the necessary points,
making use of the new event library and it's fork support.

[PATCH 1/5] libxl: allow libxl__exec to take a parameter containing

Small change to libxl__exec, so we can pass an array of env variables.

[PATCH 2/5] libxl: call hotplug scripts from libxl for vbd

Much of the meat is in this patch and the following one. Most significant
changes in this patch, (apart from the introduction of the hotplug functions),
is the addition of a new xenstore entry in each backend directory, that tells
the hotplug script wheter it should be executed from udev or form the toolstack.

[PATCH 3/5] libxl: call hotplug scripts from libxl for vif

Another xenstore backend entry is added on this patch for each nic device,
called "type", it stores the type of the interface (currently only VIF or
IOEMU), so that the plug and unplug operations know with what they are dealing.

[PATCH 4/5] libxl: add "downscript=no" to Qemu call
[PATCH 5/5] libxl: clean xenstore console directories recursively on

Two minor bugfixes that I've found while working on this hotplug series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnVy-0003le-0X; Mon, 16 Apr 2012 15:06:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnVw-0003lN-Me
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:06:48 +0000
Received: from [85.158.143.35:10865] by server-3.bemta-4.messagelabs.com id
	BC/A0-05853-8853C8F4; Mon, 16 Apr 2012 15:06:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334588806!12930686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 720 invoked from network); 16 Apr 2012 15:06:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:06:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24195838"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-Dg	for xen-devel@lists.xen.org;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:39 +0100
Message-ID: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/5] libxl: call hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series removes the use of udev rules to call hotplug scripts when using
libxl. Scripts are directly called from the toolstack at the necessary points,
making use of the new event library and it's fork support.

[PATCH 1/5] libxl: allow libxl__exec to take a parameter containing

Small change to libxl__exec, so we can pass an array of env variables.

[PATCH 2/5] libxl: call hotplug scripts from libxl for vbd

Much of the meat is in this patch and the following one. Most significant
changes in this patch, (apart from the introduction of the hotplug functions),
is the addition of a new xenstore entry in each backend directory, that tells
the hotplug script wheter it should be executed from udev or form the toolstack.

[PATCH 3/5] libxl: call hotplug scripts from libxl for vif

Another xenstore backend entry is added on this patch for each nic device,
called "type", it stores the type of the interface (currently only VIF or
IOEMU), so that the plug and unplug operations know with what they are dealing.

[PATCH 4/5] libxl: add "downscript=no" to Qemu call
[PATCH 5/5] libxl: clean xenstore console directories recursively on

Two minor bugfixes that I've found while working on this hotplug series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnVz-0003lt-DD; Mon, 16 Apr 2012 15:06:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnVx-0003lX-GW
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:06:49 +0000
Received: from [85.158.143.35:27009] by server-2.bemta-4.messagelabs.com id
	D5/08-17550-8853C8F4; Mon, 16 Apr 2012 15:06:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334588806!12930686!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 782 invoked from network); 16 Apr 2012 15:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24195839"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-Fz;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:43 +0100
Message-ID: <1334588804-7755-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ba5bef7..8dc588d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,11 +216,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = vifs[i].ifname;
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
+                                       vifs[i].devid, smac, vifs[i].model),
+                "-net", libxl__sprintf(gc,
+                               "tap,vlan=%d,ifname=%s,bridge=%s,script=%s,"
+                               "downscript=%s",
+                               vifs[i].devid, ifname, vifs[i].bridge,
+                               libxl_tapif_script(gc), libxl_tapif_script(gc)),
+                               NULL);
                 ioemu_vifs++;
             }
         }
@@ -462,8 +465,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
                 flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
+                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s,"
+                                      "downscript=%s",
                                                 vifs[i].devid, ifname,
+                                                libxl_tapif_script(gc),
                                                 libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnVz-0003lt-DD; Mon, 16 Apr 2012 15:06:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnVx-0003lX-GW
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:06:49 +0000
Received: from [85.158.143.35:27009] by server-2.bemta-4.messagelabs.com id
	D5/08-17550-8853C8F4; Mon, 16 Apr 2012 15:06:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334588806!12930686!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 782 invoked from network); 16 Apr 2012 15:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24195839"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-Fz;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:43 +0100
Message-ID: <1334588804-7755-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ba5bef7..8dc588d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,11 +216,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = vifs[i].ifname;
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
+                                       vifs[i].devid, smac, vifs[i].model),
+                "-net", libxl__sprintf(gc,
+                               "tap,vlan=%d,ifname=%s,bridge=%s,script=%s,"
+                               "downscript=%s",
+                               vifs[i].devid, ifname, vifs[i].bridge,
+                               libxl_tapif_script(gc), libxl_tapif_script(gc)),
+                               NULL);
                 ioemu_vifs++;
             }
         }
@@ -462,8 +465,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
                 flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
+                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s,"
+                                      "downscript=%s",
                                                 vifs[i].devid, ifname,
+                                                libxl_tapif_script(gc),
                                                 libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnVz-0003m3-Ol; Mon, 16 Apr 2012 15:06:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnVx-0003lX-W3
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:06:50 +0000
Received: from [85.158.143.35:11035] by server-2.bemta-4.messagelabs.com id
	DB/08-17550-9853C8F4; Mon, 16 Apr 2012 15:06:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334588806!12930686!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 852 invoked from network); 16 Apr 2012 15:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24195840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-EJ;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:40 +0100
Message-ID: <1334588804-7755-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59992b6..16ebef3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 1261499..30908d1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -991,7 +991,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d486af2..2181774 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -949,8 +949,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnVz-0003m3-Ol; Mon, 16 Apr 2012 15:06:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnVx-0003lX-W3
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:06:50 +0000
Received: from [85.158.143.35:11035] by server-2.bemta-4.messagelabs.com id
	DB/08-17550-9853C8F4; Mon, 16 Apr 2012 15:06:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334588806!12930686!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzU2ODc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 852 invoked from network); 16 Apr 2012 15:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="24195840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-EJ;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:40 +0100
Message-ID: <1334588804-7755-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59992b6..16ebef3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 1261499..30908d1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -991,7 +991,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d486af2..2181774 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -949,8 +949,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnWC-0003pO-6l; Mon, 16 Apr 2012 15:07:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnWA-0003od-QQ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:07:03 +0000
Received: from [85.158.139.83:36448] by server-8.bemta-5.messagelabs.com id
	C5/53-26964-6953C8F4; Mon, 16 Apr 2012 15:07:02 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334588819!21331337!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16946 invoked from network); 16 Apr 2012 15:07:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:07:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190525132"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-Hi;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:44 +0100
Message-ID: <1334588804-7755-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console directories
	recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Clean xenstore, to prevent leaving empty directories in the tree, like:

/local/domain/0/backend/console = ""   (n0)
/local/domain/0/backend/console/3 = ""   (n0)

That was left after a guest was destroyed.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index d773d71..4161d1bd 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -609,12 +609,11 @@ out_ok:
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnWC-0003pO-6l; Mon, 16 Apr 2012 15:07:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnWA-0003od-QQ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:07:03 +0000
Received: from [85.158.139.83:36448] by server-8.bemta-5.messagelabs.com id
	C5/53-26964-6953C8F4; Mon, 16 Apr 2012 15:07:02 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334588819!21331337!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16946 invoked from network); 16 Apr 2012 15:07:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:07:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190525132"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-Hi;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:44 +0100
Message-ID: <1334588804-7755-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console directories
	recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Clean xenstore, to prevent leaving empty directories in the tree, like:

/local/domain/0/backend/console = ""   (n0)
/local/domain/0/backend/console/3 = ""   (n0)

That was left after a guest was destroyed.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index d773d71..4161d1bd 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -609,12 +609,11 @@ out_ok:
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnWD-0003qH-Po; Mon, 16 Apr 2012 15:07:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnWC-0003pH-5h
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:07:04 +0000
Received: from [85.158.139.83:36552] by server-12.bemta-5.messagelabs.com id
	E1/65-05587-7953C8F4; Mon, 16 Apr 2012 15:07:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334588819!21331337!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17029 invoked from network); 16 Apr 2012 15:07:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:07:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190525134"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-En;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:41 +0100
Message-ID: <1334588804-7755-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl for
	vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

 * Added a check in xen-hotplug-common.sh, so scripts are only executed from
   udev when using xend. xl adds an execute_udev=n to xenstore device backend
   and passes XL_CALL=y to the env of the script call, and udev calls check that
   execute_udev is not set and XL_CALL is empty also.

I've also modified the python binding for pyxl_domain_destroy, that now take the
ao_how parameter, but I'm not really sure if it's done correctly, let's just say
that it compiles.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
 tools/libxl/Makefile                      |    3 +-
 tools/libxl/libxl.c                       |  104 ++++++++++++++++++----
 tools/libxl/libxl.h                       |    7 +-
 tools/libxl/libxl_create.c                |    4 +-
 tools/libxl/libxl_device.c                |  140 +++++++++++++++++++++++++++--
 tools/libxl/libxl_dm.c                    |    4 +-
 tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++
 tools/libxl/libxl_internal.h              |   43 +++++++++-
 tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c                  |   14 ++--
 tools/python/xen/lowlevel/xl/xl.c         |    5 +-
 12 files changed, 474 insertions(+), 40 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..dc3e867 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts form udev if the domain
+# has ben launched from libxl
+execute_udev=`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
+if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b30d11f..ac8b810 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 16ebef3..fb4fbf2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
@@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(20, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->readwrite ? "w" : "r");
     flexarray_append(back, "device-type");
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+    /* compatibility addon to keep udev rules */
+    flexarray_append(back, "execute_udev");
+    flexarray_append(back, "n");
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
@@ -1420,14 +1439,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+    } else {
+        /* no need to execute hotplug scripts */
+        libxl__ao_complete(egc, ao, 0);
+    }
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1470,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1705,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1909,7 +1948,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2256,7 +2306,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2389,7 +2450,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 50bae2f..b7347be 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,7 +394,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -523,7 +524,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..eb94bd2 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,26 +356,95 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
 
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events where added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -392,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -413,6 +481,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -420,7 +489,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -428,8 +497,51 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+    libxl__xs_path_cleanup(gc, be_path);
+    return 0;
+}
+
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
+{
+    AO_GC;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
     return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
@@ -446,13 +558,14 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -482,11 +595,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events where added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 30908d1..2d51a7f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -790,7 +790,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1044,7 +1044,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..2eace0c
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.pau@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2181774..a39346c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -455,6 +456,37 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -740,7 +772,8 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -763,6 +796,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..9a9e44a 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,120 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    flexarray_t *f_env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return NULL;
+    }
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, script);
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    /* compatibility addon to keep udev rules */
+    flexarray_set(f_env, nr++, "XL_CALL");
+    flexarray_set(f_env, nr++, "y");
+
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 08815a3..01ff363 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1301,7 +1301,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1862,7 +1862,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2339,7 +2339,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2613,7 +2613,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2846,7 +2846,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2964,7 +2964,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5011,7 +5011,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index bbbf2a9..a41a720 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -444,9 +444,10 @@ static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid;
-    if ( !PyArg_ParseTuple(args, "i", &domid) )
+    const libxl_asyncop_how *ao_how;
+    if ( !PyArg_ParseTuple(args, "ii", &domid, &ao_how) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, ao_how) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnWD-0003qH-Po; Mon, 16 Apr 2012 15:07:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnWC-0003pH-5h
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:07:04 +0000
Received: from [85.158.139.83:36552] by server-12.bemta-5.messagelabs.com id
	E1/65-05587-7953C8F4; Mon, 16 Apr 2012 15:07:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334588819!21331337!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17029 invoked from network); 16 Apr 2012 15:07:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:07:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190525134"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-En;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:41 +0100
Message-ID: <1334588804-7755-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl for
	vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

 * Added a check in xen-hotplug-common.sh, so scripts are only executed from
   udev when using xend. xl adds an execute_udev=n to xenstore device backend
   and passes XL_CALL=y to the env of the script call, and udev calls check that
   execute_udev is not set and XL_CALL is empty also.

I've also modified the python binding for pyxl_domain_destroy, that now take the
ao_how parameter, but I'm not really sure if it's done correctly, let's just say
that it compiles.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
 tools/libxl/Makefile                      |    3 +-
 tools/libxl/libxl.c                       |  104 ++++++++++++++++++----
 tools/libxl/libxl.h                       |    7 +-
 tools/libxl/libxl_create.c                |    4 +-
 tools/libxl/libxl_device.c                |  140 +++++++++++++++++++++++++++--
 tools/libxl/libxl_dm.c                    |    4 +-
 tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++
 tools/libxl/libxl_internal.h              |   43 +++++++++-
 tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c                  |   14 ++--
 tools/python/xen/lowlevel/xl/xl.c         |    5 +-
 12 files changed, 474 insertions(+), 40 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..dc3e867 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts form udev if the domain
+# has ben launched from libxl
+execute_udev=`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
+if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b30d11f..ac8b810 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 16ebef3..fb4fbf2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
@@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(20, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->readwrite ? "w" : "r");
     flexarray_append(back, "device-type");
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+    /* compatibility addon to keep udev rules */
+    flexarray_append(back, "execute_udev");
+    flexarray_append(back, "n");
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
@@ -1420,14 +1439,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+    } else {
+        /* no need to execute hotplug scripts */
+        libxl__ao_complete(egc, ao, 0);
+    }
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1470,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1705,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1909,7 +1948,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2256,7 +2306,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2389,7 +2450,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 50bae2f..b7347be 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,7 +394,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -523,7 +524,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..eb94bd2 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,26 +356,95 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
 
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events where added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -392,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -413,6 +481,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -420,7 +489,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -428,8 +497,51 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+    libxl__xs_path_cleanup(gc, be_path);
+    return 0;
+}
+
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
+{
+    AO_GC;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
     return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
@@ -446,13 +558,14 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -482,11 +595,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events where added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 30908d1..2d51a7f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -790,7 +790,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1044,7 +1044,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..2eace0c
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.pau@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2181774..a39346c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -455,6 +456,37 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -740,7 +772,8 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -763,6 +796,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..9a9e44a 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,120 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    flexarray_t *f_env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return NULL;
+    }
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, script);
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    /* compatibility addon to keep udev rules */
+    flexarray_set(f_env, nr++, "XL_CALL");
+    flexarray_set(f_env, nr++, "y");
+
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 08815a3..01ff363 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1301,7 +1301,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1862,7 +1862,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2339,7 +2339,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2613,7 +2613,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2846,7 +2846,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2964,7 +2964,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5011,7 +5011,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index bbbf2a9..a41a720 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -444,9 +444,10 @@ static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid;
-    if ( !PyArg_ParseTuple(args, "i", &domid) )
+    const libxl_asyncop_how *ao_how;
+    if ( !PyArg_ParseTuple(args, "ii", &domid, &ao_how) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, ao_how) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnWE-0003qm-DL; Mon, 16 Apr 2012 15:07:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnWD-0003pm-86
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:07:05 +0000
Received: from [85.158.139.83:14987] by server-6.bemta-5.messagelabs.com id
	53/38-13222-8953C8F4; Mon, 16 Apr 2012 15:07:04 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334588819!21331337!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17092 invoked from network); 16 Apr 2012 15:07:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190525133"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-FR;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:42 +0100
Message-ID: <1334588804-7755-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] libxl: call hotplug scripts from libxl for
	vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

An exception has been introduced for tap devices, since hotplug scripts
should be called after the device model has been created, so the hotplug
call for those is done in do_domain_create after confirmation of the device
model startup. On the other hand, tap devices don't use teardown scripts,
so add another exception for that.

libxl__device_from_nic was moved to libxl_device.c, so it can be used
in libxl_create.c, and libxl__device_from_disk was also moved to mantain
the simmetry.

libxl__initiate_device_remove has been changed a little, to nuke the frontend
xenstore path before trying to perform device teardown, this allows for
unitialized devices to be closed gracefully, specially vif interfaces added to
HVM machines and not used.

PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
LIBXL_NIC_TYPE_IOEMU regardless of the guest type.

A new gobal option, called disable_vif_scripts has been added to allow the user
decide if he wants to execute the hotplug scripts from xl or from udev. This has
been documented in the xl.conf man page.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5       |    7 ++
 tools/libxl/libxl.c          |   85 ++++++++------------------
 tools/libxl/libxl.h          |    3 +-
 tools/libxl/libxl_create.c   |   22 ++++++-
 tools/libxl/libxl_device.c   |   77 +++++++++++++++++++++--
 tools/libxl/libxl_dm.c       |    2 +-
 tools/libxl/libxl_internal.h |    6 ++
 tools/libxl/libxl_linux.c    |  138 +++++++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_types.idl  |    1 +
 tools/libxl/xl.c             |    4 +
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |   15 ++++-
 12 files changed, 289 insertions(+), 72 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8bd45ea..cf2c477 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,13 @@ default.
 
 Default: C<1>
 
+=item B<disable_vif_scripts=BOOLEAN>
+
+If enabled xl will not execute nic hotplug scripts itself, and instead
+relegate this task to udev.
+
+Default: C<0>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fb4fbf2..44a54cb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1277,46 +1277,6 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
                           libxl_device_disk *disk,
                           const libxl_asyncop_how *ao_how)
@@ -1828,23 +1788,10 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
     return 0;
 }
 
-static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
-                                  libxl_device_nic *nic,
-                                  libxl__device *device)
-{
-    device->backend_devid    = nic->devid;
-    device->backend_domid    = nic->backend_domid;
-    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
-    device->devid            = nic->devid;
-    device->domid            = domid;
-    device->kind             = LIBXL__DEVICE_KIND_VIF;
-
-    return 0;
-}
-
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1859,7 +1806,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1912,6 +1859,13 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
     flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->nictype));
+    /* compatibility addon to keep udev rules */
+    if (!nic->disable_vif_script) {
+        flexarray_append(back, "execute_udev");
+        flexarray_append(back, "n");
+    }
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
@@ -1926,14 +1880,25 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    if (nic->nictype == LIBXL_NIC_TYPE_VIF &&
+        !nic->disable_vif_script) {
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+    } else {
+        /*
+         * Don't execute hotplug scripts for IOEMU interfaces yet,
+         * we need to launch the device model first.
+        */
+        libxl__ao_complete(egc, ao, 0);
+    }
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b7347be..6da6107 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -551,7 +551,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..a1f5731 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
@@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                        "device model did not start: %d", ret);
             goto error_out;
         }
+        /* 
+         * Execute hotplug scripts for tap devices, this has to be done
+         * after the domain model has been started.
+        */
+        for (i = 0; i < d_config->num_vifs; i++) {
+            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
+                !d_config->vifs[i].disable_vif_script) {
+                libxl__device device;
+                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
+                                             &device);
+                if (ret < 0) goto error_out;
+                ret = libxl__device_hotplug(gc, &device, CONNECT);
+                if (ret < 0) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                               "unable to launch hotplug script for device: "
+                               "%"PRIu32, device.devid);
+                    goto error_out;
+                }
+            }
+        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index eb94bd2..d773d71 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -249,6 +249,60 @@ char *libxl__device_disk_string_of_backend(libxl_disk_backend backend)
     }
 }
 
+int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                           libxl_device_nic *nic,
+                           libxl__device *device)
+{
+    device->backend_devid    = nic->devid;
+    device->backend_domid    = nic->backend_domid;
+    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
+    device->devid            = nic->devid;
+    device->domid            = domid;
+    device->kind             = LIBXL__DEVICE_KIND_VIF;
+
+    return 0;
+}
+
+int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                            libxl_device_disk *disk,
+                            libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
 int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor)
 {
     struct stat buf;
@@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
+    xs_transaction_t t = 0;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
     libxl__ao_device_remove *aorm = 0;
 
+    /*
+     * Nuke frontend to force backend teardown
+     * It's not pretty, but it's the only way that seems to work for all
+     * types of backends
+     */
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
     if (!state)
         goto out_ok;
-    if (atoi(state) != 4) {
+    if (atoi(state) == XenbusStateClosed)
         libxl__device_destroy_tapdisk(gc, be_path);
         goto out_ok;
-    }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -476,6 +537,8 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
@@ -497,8 +560,8 @@ retry_transaction:
     return rc;
 
  out_ok:
+    if (t) xs_transaction_end(ctx->xsh, t, 0);
     rc = libxl__device_hotplug(gc, dev, DISCONNECT);
-    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
     libxl__xs_path_cleanup(gc, be_path);
     return 0;
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 2d51a7f..ba5bef7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -795,7 +795,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a39346c..3787217 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -756,6 +756,12 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
 _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*);
+_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__device *device);
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                    libxl_device_disk *disk,
+                                    libxl__device *device);
 
 _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor);
 _hidden int libxl__device_disk_dev_number(const char *virtpath,
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 9a9e44a..474265c 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -27,6 +27,25 @@ int libxl__try_phy_backend(mode_t st_mode)
 }
 
 /* Hotplug scripts helpers */
+
+static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *snictype, *be_path;
+
+    be_path = libxl__device_backend_path(gc, dev);
+
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "type"));
+    if (!snictype) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
+                                          be_path);
+        return -1;
+    }
+
+    return atoi(snictype);
+}
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -43,7 +62,8 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    f_env = flexarray_make(11, 1);
+    f_env = flexarray_make(15, 1);
+
     if (!f_env) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "unable to create environment array");
@@ -62,6 +82,24 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
                   dev->domid, dev->devid));
     flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
     flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        switch (get_nic_type(gc, dev)) {
+        case LIBXL_NIC_TYPE_IOEMU:
+            flexarray_set(f_env, nr++, "INTERFACE");
+            flexarray_set(f_env, nr++,
+                          libxl__sprintf(gc, "tap%u.%d",
+                          dev->domid, dev->devid));
+        case LIBXL_NIC_TYPE_VIF:
+            flexarray_set(f_env, nr++, "vif");
+            flexarray_set(f_env, nr++,
+                          libxl__sprintf(gc, "vif%u.%d",
+                          dev->domid, dev->devid));
+            break;
+        default:
+            return NULL;
+        }
+    }
+
     /* compatibility addon to keep udev rules */
     flexarray_set(f_env, nr++, "XL_CALL");
     flexarray_set(f_env, nr++, "y");
@@ -126,6 +164,101 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+    flexarray_t *vif_args, *tap_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    nictype = get_nic_type(gc, dev);
+    if (nictype < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "error when fetching nic type");
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    vif_args = flexarray_make(4, 1);
+    if (!vif_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+    tap_args = flexarray_make(4, 1);
+    if (!tap_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    switch(nictype) {
+    case LIBXL_NIC_TYPE_IOEMU:
+        flexarray_set(tap_args, nr++, script);
+        flexarray_set(tap_args, nr++, action == CONNECT ? "add" : "remove");
+        flexarray_set(tap_args, nr++, libxl__sprintf(gc, "type_if=tap"));
+        flexarray_set(tap_args, nr++, NULL);
+        args = (char **) flexarray_contents(tap_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        free(args);
+        nr = 0;
+    case LIBXL_NIC_TYPE_VIF:
+        flexarray_set(vif_args, nr++, script);
+        flexarray_set(vif_args, nr++, action == CONNECT ? "online" : "offline");
+        flexarray_set(vif_args, nr++, libxl__sprintf(gc, "type_if=vif"));
+        flexarray_set(vif_args, nr++, NULL);
+        args = (char **) flexarray_contents(vif_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        break;
+    default:
+        /* Unknown network type */
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unknown network card type with "
+                                            "id %"PRIu32, dev->devid);
+        return 0;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -135,6 +268,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 09089b2..ac3e79f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
     ("ifname", string),
     ("script", string),
     ("nictype", libxl_nic_type),
+    ("disable_vif_script", integer),
     ])
 
 libxl_device_pci = Struct("device_pci", [
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..2a705b8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+int disable_vif_scripts = 0;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    if (!xlu_cfg_get_long (config, "disable_vif_scripts", &l, 0))
+        disable_vif_scripts = l;
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..13619e7 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -109,6 +109,7 @@ void postfork(void);
 
 /* global options */
 extern int autoballoon;
+extern int disable_vif_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 01ff363..41230a6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -846,6 +846,19 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+            /* Set default nic type for PV guests correctly */
+            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
+                nic->nictype = LIBXL_NIC_TYPE_VIF;
+            }
+
+            /*
+             * Disable nic network script calling, to allow the user
+             * to attach the nic backend from a different domain.
+             */
+            if (disable_vif_scripts) {
+                nic->disable_vif_script = 1;
+            }
+
 	    if (default_bridge) {
 		free(nic->bridge);
 		nic->bridge = strdup(default_bridge);
@@ -4901,7 +4914,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:07:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnWE-0003qm-DL; Mon, 16 Apr 2012 15:07:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJnWD-0003pm-86
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:07:05 +0000
Received: from [85.158.139.83:14987] by server-6.bemta-5.messagelabs.com id
	53/38-13222-8953C8F4; Mon, 16 Apr 2012 15:07:04 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334588819!21331337!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17092 invoked from network); 16 Apr 2012 15:07:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190525133"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:06:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:06:46 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJnVt-0001Ff-FR;
	Mon, 16 Apr 2012 16:06:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 16:06:42 +0100
Message-ID: <1334588804-7755-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] libxl: call hotplug scripts from libxl for
	vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

An exception has been introduced for tap devices, since hotplug scripts
should be called after the device model has been created, so the hotplug
call for those is done in do_domain_create after confirmation of the device
model startup. On the other hand, tap devices don't use teardown scripts,
so add another exception for that.

libxl__device_from_nic was moved to libxl_device.c, so it can be used
in libxl_create.c, and libxl__device_from_disk was also moved to mantain
the simmetry.

libxl__initiate_device_remove has been changed a little, to nuke the frontend
xenstore path before trying to perform device teardown, this allows for
unitialized devices to be closed gracefully, specially vif interfaces added to
HVM machines and not used.

PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
LIBXL_NIC_TYPE_IOEMU regardless of the guest type.

A new gobal option, called disable_vif_scripts has been added to allow the user
decide if he wants to execute the hotplug scripts from xl or from udev. This has
been documented in the xl.conf man page.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5       |    7 ++
 tools/libxl/libxl.c          |   85 ++++++++------------------
 tools/libxl/libxl.h          |    3 +-
 tools/libxl/libxl_create.c   |   22 ++++++-
 tools/libxl/libxl_device.c   |   77 +++++++++++++++++++++--
 tools/libxl/libxl_dm.c       |    2 +-
 tools/libxl/libxl_internal.h |    6 ++
 tools/libxl/libxl_linux.c    |  138 +++++++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_types.idl  |    1 +
 tools/libxl/xl.c             |    4 +
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |   15 ++++-
 12 files changed, 289 insertions(+), 72 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8bd45ea..cf2c477 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,13 @@ default.
 
 Default: C<1>
 
+=item B<disable_vif_scripts=BOOLEAN>
+
+If enabled xl will not execute nic hotplug scripts itself, and instead
+relegate this task to udev.
+
+Default: C<0>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fb4fbf2..44a54cb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1277,46 +1277,6 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
                           libxl_device_disk *disk,
                           const libxl_asyncop_how *ao_how)
@@ -1828,23 +1788,10 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
     return 0;
 }
 
-static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
-                                  libxl_device_nic *nic,
-                                  libxl__device *device)
-{
-    device->backend_devid    = nic->devid;
-    device->backend_domid    = nic->backend_domid;
-    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
-    device->devid            = nic->devid;
-    device->domid            = domid;
-    device->kind             = LIBXL__DEVICE_KIND_VIF;
-
-    return 0;
-}
-
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1859,7 +1806,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1912,6 +1859,13 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
     flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->nictype));
+    /* compatibility addon to keep udev rules */
+    if (!nic->disable_vif_script) {
+        flexarray_append(back, "execute_udev");
+        flexarray_append(back, "n");
+    }
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
@@ -1926,14 +1880,25 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    if (nic->nictype == LIBXL_NIC_TYPE_VIF &&
+        !nic->disable_vif_script) {
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+    } else {
+        /*
+         * Don't execute hotplug scripts for IOEMU interfaces yet,
+         * we need to launch the device model first.
+        */
+        libxl__ao_complete(egc, ao, 0);
+    }
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b7347be..6da6107 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -551,7 +551,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..a1f5731 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
@@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                        "device model did not start: %d", ret);
             goto error_out;
         }
+        /* 
+         * Execute hotplug scripts for tap devices, this has to be done
+         * after the domain model has been started.
+        */
+        for (i = 0; i < d_config->num_vifs; i++) {
+            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
+                !d_config->vifs[i].disable_vif_script) {
+                libxl__device device;
+                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
+                                             &device);
+                if (ret < 0) goto error_out;
+                ret = libxl__device_hotplug(gc, &device, CONNECT);
+                if (ret < 0) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                               "unable to launch hotplug script for device: "
+                               "%"PRIu32, device.devid);
+                    goto error_out;
+                }
+            }
+        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index eb94bd2..d773d71 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -249,6 +249,60 @@ char *libxl__device_disk_string_of_backend(libxl_disk_backend backend)
     }
 }
 
+int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                           libxl_device_nic *nic,
+                           libxl__device *device)
+{
+    device->backend_devid    = nic->devid;
+    device->backend_domid    = nic->backend_domid;
+    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
+    device->devid            = nic->devid;
+    device->domid            = domid;
+    device->kind             = LIBXL__DEVICE_KIND_VIF;
+
+    return 0;
+}
+
+int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                            libxl_device_disk *disk,
+                            libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
 int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor)
 {
     struct stat buf;
@@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
+    xs_transaction_t t = 0;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
     libxl__ao_device_remove *aorm = 0;
 
+    /*
+     * Nuke frontend to force backend teardown
+     * It's not pretty, but it's the only way that seems to work for all
+     * types of backends
+     */
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
     if (!state)
         goto out_ok;
-    if (atoi(state) != 4) {
+    if (atoi(state) == XenbusStateClosed)
         libxl__device_destroy_tapdisk(gc, be_path);
         goto out_ok;
-    }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -476,6 +537,8 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
@@ -497,8 +560,8 @@ retry_transaction:
     return rc;
 
  out_ok:
+    if (t) xs_transaction_end(ctx->xsh, t, 0);
     rc = libxl__device_hotplug(gc, dev, DISCONNECT);
-    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
     libxl__xs_path_cleanup(gc, be_path);
     return 0;
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 2d51a7f..ba5bef7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -795,7 +795,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a39346c..3787217 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -756,6 +756,12 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
 _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*);
+_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__device *device);
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                    libxl_device_disk *disk,
+                                    libxl__device *device);
 
 _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor);
 _hidden int libxl__device_disk_dev_number(const char *virtpath,
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 9a9e44a..474265c 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -27,6 +27,25 @@ int libxl__try_phy_backend(mode_t st_mode)
 }
 
 /* Hotplug scripts helpers */
+
+static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *snictype, *be_path;
+
+    be_path = libxl__device_backend_path(gc, dev);
+
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "type"));
+    if (!snictype) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
+                                          be_path);
+        return -1;
+    }
+
+    return atoi(snictype);
+}
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -43,7 +62,8 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    f_env = flexarray_make(11, 1);
+    f_env = flexarray_make(15, 1);
+
     if (!f_env) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "unable to create environment array");
@@ -62,6 +82,24 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
                   dev->domid, dev->devid));
     flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
     flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        switch (get_nic_type(gc, dev)) {
+        case LIBXL_NIC_TYPE_IOEMU:
+            flexarray_set(f_env, nr++, "INTERFACE");
+            flexarray_set(f_env, nr++,
+                          libxl__sprintf(gc, "tap%u.%d",
+                          dev->domid, dev->devid));
+        case LIBXL_NIC_TYPE_VIF:
+            flexarray_set(f_env, nr++, "vif");
+            flexarray_set(f_env, nr++,
+                          libxl__sprintf(gc, "vif%u.%d",
+                          dev->domid, dev->devid));
+            break;
+        default:
+            return NULL;
+        }
+    }
+
     /* compatibility addon to keep udev rules */
     flexarray_set(f_env, nr++, "XL_CALL");
     flexarray_set(f_env, nr++, "y");
@@ -126,6 +164,101 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+    flexarray_t *vif_args, *tap_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    nictype = get_nic_type(gc, dev);
+    if (nictype < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "error when fetching nic type");
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    vif_args = flexarray_make(4, 1);
+    if (!vif_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+    tap_args = flexarray_make(4, 1);
+    if (!tap_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    switch(nictype) {
+    case LIBXL_NIC_TYPE_IOEMU:
+        flexarray_set(tap_args, nr++, script);
+        flexarray_set(tap_args, nr++, action == CONNECT ? "add" : "remove");
+        flexarray_set(tap_args, nr++, libxl__sprintf(gc, "type_if=tap"));
+        flexarray_set(tap_args, nr++, NULL);
+        args = (char **) flexarray_contents(tap_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        free(args);
+        nr = 0;
+    case LIBXL_NIC_TYPE_VIF:
+        flexarray_set(vif_args, nr++, script);
+        flexarray_set(vif_args, nr++, action == CONNECT ? "online" : "offline");
+        flexarray_set(vif_args, nr++, libxl__sprintf(gc, "type_if=vif"));
+        flexarray_set(vif_args, nr++, NULL);
+        args = (char **) flexarray_contents(vif_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        break;
+    default:
+        /* Unknown network type */
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unknown network card type with "
+                                            "id %"PRIu32, dev->devid);
+        return 0;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -135,6 +268,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 09089b2..ac3e79f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
     ("ifname", string),
     ("script", string),
     ("nictype", libxl_nic_type),
+    ("disable_vif_script", integer),
     ])
 
 libxl_device_pci = Struct("device_pci", [
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..2a705b8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+int disable_vif_scripts = 0;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    if (!xlu_cfg_get_long (config, "disable_vif_scripts", &l, 0))
+        disable_vif_scripts = l;
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..13619e7 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -109,6 +109,7 @@ void postfork(void);
 
 /* global options */
 extern int autoballoon;
+extern int disable_vif_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 01ff363..41230a6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -846,6 +846,19 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+            /* Set default nic type for PV guests correctly */
+            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
+                nic->nictype = LIBXL_NIC_TYPE_VIF;
+            }
+
+            /*
+             * Disable nic network script calling, to allow the user
+             * to attach the nic backend from a different domain.
+             */
+            if (disable_vif_scripts) {
+                nic->disable_vif_script = 1;
+            }
+
 	    if (default_bridge) {
 		free(nic->bridge);
 		nic->bridge = strdup(default_bridge);
@@ -4901,7 +4914,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:16:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnei-00052C-6b; Mon, 16 Apr 2012 15:15:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJneh-000520-4P
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:15:51 +0000
Received: from [85.158.143.99:60062] by server-1.bemta-4.messagelabs.com id
	A9/9B-20925-6A73C8F4; Mon, 16 Apr 2012 15:15:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334589348!23821395!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 445 invoked from network); 16 Apr 2012 15:15:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:15:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GFFixV032640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 15:15:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GFFhHQ026559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 15:15:44 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GFFh7c020443; Mon, 16 Apr 2012 10:15:43 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 08:15:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B56584027C; Mon, 16 Apr 2012 11:10:45 -0400 (EDT)
Date: Mon, 16 Apr 2012 11:10:45 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416151045.GH1903@phenom.dumpdata.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F88222F.7050703@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F8C37A2.00BF,ss=1,re=0.000,fgs=0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 01:55:11PM +0100, David Vrabel wrote:
> On 13/04/12 13:29, Jan Beulich wrote:
> >>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The accessing PCI configuration space with the PCI BIOS service does
> >> not work in PV guests.
> >>
> >> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
> >> marked the MMCONFIG region as reserved in the e820 map.
> > 
> > ... and where "direct" access doesn't work either? Are there really
> > machines where Xen works on but this doesn't work? (Or, in case
> > this is disabled in your config, is it really useful to have
> > CONFIG_PCI_DIRECT disabled?)
> 
> If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
> direct.  So this change makes it skip BIOS and fall back to direct.
> 
> On the system I had saw the problem, the first call into the BIOS
> service would hang the system.
> 
> > That's just a comment on the description, the patch itself is fine
> > nevertheless (but should probably be sent to the x86 and/or PCI
> > maintainers).
> 
> I was expecting Konrad to pick it up and forward it to the relevant
> maintainer as appropriate.  Konrad, would you prefer if I sent to direct?

You can send it to me. But I think it makes sense to stick
this in arch/x86/pci/xen.c - if it is not to late in teh bootup cycle?

> 
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > 
> > Acked-by: Jan Beulich <jbeulich@suse.com>
> > 
> >> Cc: stable@kernel.org 
> >> ---
> >>  arch/x86/xen/enlighten.c |    5 ++++-
> >>  1 files changed, 4 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >> index b132ade..dbb5bb7 100644
> >> --- a/arch/x86/xen/enlighten.c
> >> +++ b/arch/x86/xen/enlighten.c
> >> @@ -63,6 +63,7 @@
> >>  #include <asm/stackprotector.h>
> >>  #include <asm/hypervisor.h>
> >>  #include <asm/mwait.h>
> >> +#include <asm/pci_x86.h>
> >>  
> >>  #ifdef CONFIG_ACPI
> >>  #include <linux/acpi.h>
> >> @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
> >>  		/* Make sure ACS will be enabled */
> >>  		pci_request_acs();
> >>  	}
> >> -		
> >> +
> >> +	/* PCI BIOS service won't work from a PV guest. */
> >> +	pci_probe &= ~PCI_PROBE_BIOS;
> >>  
> >>  	xen_raw_console_write("about to get started...\n");
> >>  
> >> -- 
> >> 1.7.2.5
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org 
> >> http://lists.xen.org/xen-devel 
> > 
> > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:16:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnei-00052C-6b; Mon, 16 Apr 2012 15:15:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJneh-000520-4P
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:15:51 +0000
Received: from [85.158.143.99:60062] by server-1.bemta-4.messagelabs.com id
	A9/9B-20925-6A73C8F4; Mon, 16 Apr 2012 15:15:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334589348!23821395!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 445 invoked from network); 16 Apr 2012 15:15:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:15:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GFFixV032640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 15:15:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GFFhHQ026559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 15:15:44 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GFFh7c020443; Mon, 16 Apr 2012 10:15:43 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 08:15:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B56584027C; Mon, 16 Apr 2012 11:10:45 -0400 (EDT)
Date: Mon, 16 Apr 2012 11:10:45 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416151045.GH1903@phenom.dumpdata.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F88222F.7050703@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F8C37A2.00BF,ss=1,re=0.000,fgs=0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 01:55:11PM +0100, David Vrabel wrote:
> On 13/04/12 13:29, Jan Beulich wrote:
> >>>> On 13.04.12 at 14:08, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The accessing PCI configuration space with the PCI BIOS service does
> >> not work in PV guests.
> >>
> >> This fixes boot on systems without MMCONFIG or where the BIOS hasn't
> >> marked the MMCONFIG region as reserved in the e820 map.
> > 
> > ... and where "direct" access doesn't work either? Are there really
> > machines where Xen works on but this doesn't work? (Or, in case
> > this is disabled in your config, is it really useful to have
> > CONFIG_PCI_DIRECT disabled?)
> 
> If you have CONFIG_PCI_GOANY (the default) BIOS is preferred over
> direct.  So this change makes it skip BIOS and fall back to direct.
> 
> On the system I had saw the problem, the first call into the BIOS
> service would hang the system.
> 
> > That's just a comment on the description, the patch itself is fine
> > nevertheless (but should probably be sent to the x86 and/or PCI
> > maintainers).
> 
> I was expecting Konrad to pick it up and forward it to the relevant
> maintainer as appropriate.  Konrad, would you prefer if I sent to direct?

You can send it to me. But I think it makes sense to stick
this in arch/x86/pci/xen.c - if it is not to late in teh bootup cycle?

> 
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > 
> > Acked-by: Jan Beulich <jbeulich@suse.com>
> > 
> >> Cc: stable@kernel.org 
> >> ---
> >>  arch/x86/xen/enlighten.c |    5 ++++-
> >>  1 files changed, 4 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >> index b132ade..dbb5bb7 100644
> >> --- a/arch/x86/xen/enlighten.c
> >> +++ b/arch/x86/xen/enlighten.c
> >> @@ -63,6 +63,7 @@
> >>  #include <asm/stackprotector.h>
> >>  #include <asm/hypervisor.h>
> >>  #include <asm/mwait.h>
> >> +#include <asm/pci_x86.h>
> >>  
> >>  #ifdef CONFIG_ACPI
> >>  #include <linux/acpi.h>
> >> @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void)
> >>  		/* Make sure ACS will be enabled */
> >>  		pci_request_acs();
> >>  	}
> >> -		
> >> +
> >> +	/* PCI BIOS service won't work from a PV guest. */
> >> +	pci_probe &= ~PCI_PROBE_BIOS;
> >>  
> >>  	xen_raw_console_write("about to get started...\n");
> >>  
> >> -- 
> >> 1.7.2.5
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org 
> >> http://lists.xen.org/xen-devel 
> > 
> > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:16:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnfD-00055z-Pd; Mon, 16 Apr 2012 15:16:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJnfC-00055f-D4
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:16:22 +0000
Received: from [85.158.138.51:7163] by server-8.bemta-3.messagelabs.com id
	2C/21-24428-5C73C8F4; Mon, 16 Apr 2012 15:16:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334589380!20548390!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4611 invoked from network); 16 Apr 2012 15:16:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 15:16:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJnf3-0004Sb-Ao; Mon, 16 Apr 2012 15:16:13 +0000
Date: Mon, 16 Apr 2012 16:16:13 +0100
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416151613.GB13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8C33E0.2080007@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:59 +0100 on 16 Apr (1334591984), David Vrabel wrote:
> On 16/04/12 12:32, Jan Beulich wrote:
> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The sched clock was considered stable based on the capabilities of the
> >> underlying hardware.  This does not make sense for Xen PV guests as:
> >> a) the hardware TSC is not used directly as the clock source; and b)
> >> guests may migrate to hosts with different hardware capabilities.
> >>
> >> It is not clear to me whether the Xen clock source is supposed to be
> >> stable and whether it should be stable across migration.  For a clock
> >> source to be stable it must be: a) monotonic; c) synchronized across
> >> CPUs; and c) constant rate.
> 
> Tim, Thomas, can you comment on the above paragraph?  Is it correct?

How synchronized does it need to be?  The adjustment of the rate happens
independently on different CPUs so you might be able to see small
differences if once CPU has made the adjustment but another hasn't yet.

That aside, on platforms where the real TSC is stable, AFAIK the xen PV
time will be too, _except_ across migration.  I have no idea whether Xen
exports sufficient information to the guest for it to be able to tell
whether this is the case, though -- it needs to know not only that the
hardware is stable, but thet _Xen_ thinks it's stable.

Across migration, the PV time might not be monotonic (because it's always
the wallclock time on the current host, not a VM-specific attribute).
Which is not to say that the linux-side code couldn't make it monotonic,
at least for small differences between hosts. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:16:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnfD-00055z-Pd; Mon, 16 Apr 2012 15:16:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJnfC-00055f-D4
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:16:22 +0000
Received: from [85.158.138.51:7163] by server-8.bemta-3.messagelabs.com id
	2C/21-24428-5C73C8F4; Mon, 16 Apr 2012 15:16:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334589380!20548390!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4611 invoked from network); 16 Apr 2012 15:16:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 15:16:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJnf3-0004Sb-Ao; Mon, 16 Apr 2012 15:16:13 +0000
Date: Mon, 16 Apr 2012 16:16:13 +0100
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416151613.GB13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8C33E0.2080007@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:59 +0100 on 16 Apr (1334591984), David Vrabel wrote:
> On 16/04/12 12:32, Jan Beulich wrote:
> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The sched clock was considered stable based on the capabilities of the
> >> underlying hardware.  This does not make sense for Xen PV guests as:
> >> a) the hardware TSC is not used directly as the clock source; and b)
> >> guests may migrate to hosts with different hardware capabilities.
> >>
> >> It is not clear to me whether the Xen clock source is supposed to be
> >> stable and whether it should be stable across migration.  For a clock
> >> source to be stable it must be: a) monotonic; c) synchronized across
> >> CPUs; and c) constant rate.
> 
> Tim, Thomas, can you comment on the above paragraph?  Is it correct?

How synchronized does it need to be?  The adjustment of the rate happens
independently on different CPUs so you might be able to see small
differences if once CPU has made the adjustment but another hasn't yet.

That aside, on platforms where the real TSC is stable, AFAIK the xen PV
time will be too, _except_ across migration.  I have no idea whether Xen
exports sufficient information to the guest for it to be able to tell
whether this is the case, though -- it needs to know not only that the
hardware is stable, but thet _Xen_ thinks it's stable.

Across migration, the PV time might not be monotonic (because it's always
the wallclock time on the current host, not a VM-specific attribute).
Which is not to say that the linux-side code couldn't make it monotonic,
at least for small differences between hosts. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnll-0005Uh-Dh; Mon, 16 Apr 2012 15:23:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1SJnlk-0005UW-Hl
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:23:08 +0000
Received: from [85.158.143.99:42793] by server-3.bemta-4.messagelabs.com id
	AB/59-05853-B593C8F4; Mon, 16 Apr 2012 15:23:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334589783!12669556!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6231 invoked from network); 16 Apr 2012 15:23:07 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 15:23:07 -0000
X-TM-IMSS-Message-ID: <e0c40f8700000e72@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	e0c40f8700000e72 ; Mon, 16 Apr 2012 11:23:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q3GFN0aC003155; 
	Mon, 16 Apr 2012 11:23:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 11:21:57 -0400
Message-Id: <1334589717-2675-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH] xsm/flask: clean up auditing output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The audit data for normal MMU updates was incorrectly using the RANGE
type which presented the data badly in audit messages; add a MEMORY type
for this showing the correct names for the fields. This patch also shows
the target domain in event channel mapping checks to make debugging
those denials easier.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c         |    3 +++
 xen/xsm/flask/hooks.c       |   16 ++++++++++------
 xen/xsm/flask/include/avc.h |    8 +++++---
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index b5486a3..95c928b 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -639,6 +639,9 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
     case AVC_AUDIT_DATA_RANGE:
         avc_printk(&buf, "range=0x%lx-0x%lx ", a->range.start, a->range.end);
         break;
+    case AVC_AUDIT_DATA_MEMORY:
+        avc_printk(&buf, "pte=0x%lx mfn=0x%lx", a->memory.pte, a->memory.mfn);
+        break;
     }
 
     avc_dump_query(&buf, ssid, tsid, tclass);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 9948fca..c93b8d0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -186,6 +186,10 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
     int rc;
     struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec1, *esec2;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+    ad.sdom = d1;
+    ad.tdom = d2;
 
     dsec = current->domain->ssid;
     dsec1 = d1->ssid;
@@ -203,15 +207,15 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -1328,13 +1332,13 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *t,
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
         map_perms |= MMU__MAP_WRITE;
 
-    AVC_AUDIT_DATA_INIT(&ad, RANGE);
+    AVC_AUDIT_DATA_INIT(&ad, MEMORY);
     fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
 
     ad.sdom = d;
     ad.tdom = f;
-    ad.range.start = fpte;
-    ad.range.end = fmfn;
+    ad.memory.pte = fpte;
+    ad.memory.mfn = fmfn;
 
     rc = get_mfn_sid(fmfn, &fsid);
 
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 0f62891..42a5e4b 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -42,6 +42,7 @@ struct avc_audit_data {
 #define AVC_AUDIT_DATA_DEV   1
 #define AVC_AUDIT_DATA_IRQ   2
 #define AVC_AUDIT_DATA_RANGE 3
+#define AVC_AUDIT_DATA_MEMORY 4
     struct domain *sdom;
     struct domain *tdom;
     union {
@@ -51,12 +52,13 @@ struct avc_audit_data {
             unsigned long start;
             unsigned long end;
         } range;
+        struct {
+            unsigned long pte;
+            unsigned long mfn;
+        } memory;
     };
 };
 
-#define v4info fam.v4
-#define v6info fam.v6
-
 /* Initialize an AVC audit data structure. */
 #define AVC_AUDIT_DATA_INIT(_d,_t) \
         { memset((_d), 0, sizeof(struct avc_audit_data)); \
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnll-0005Uh-Dh; Mon, 16 Apr 2012 15:23:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1SJnlk-0005UW-Hl
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:23:08 +0000
Received: from [85.158.143.99:42793] by server-3.bemta-4.messagelabs.com id
	AB/59-05853-B593C8F4; Mon, 16 Apr 2012 15:23:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334589783!12669556!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6231 invoked from network); 16 Apr 2012 15:23:07 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-216.messagelabs.com with SMTP;
	16 Apr 2012 15:23:07 -0000
X-TM-IMSS-Message-ID: <e0c40f8700000e72@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	e0c40f8700000e72 ; Mon, 16 Apr 2012 11:23:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q3GFN0aC003155; 
	Mon, 16 Apr 2012 11:23:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 11:21:57 -0400
Message-Id: <1334589717-2675-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH] xsm/flask: clean up auditing output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The audit data for normal MMU updates was incorrectly using the RANGE
type which presented the data badly in audit messages; add a MEMORY type
for this showing the correct names for the fields. This patch also shows
the target domain in event channel mapping checks to make debugging
those denials easier.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c         |    3 +++
 xen/xsm/flask/hooks.c       |   16 ++++++++++------
 xen/xsm/flask/include/avc.h |    8 +++++---
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index b5486a3..95c928b 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -639,6 +639,9 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
     case AVC_AUDIT_DATA_RANGE:
         avc_printk(&buf, "range=0x%lx-0x%lx ", a->range.start, a->range.end);
         break;
+    case AVC_AUDIT_DATA_MEMORY:
+        avc_printk(&buf, "pte=0x%lx mfn=0x%lx", a->memory.pte, a->memory.mfn);
+        break;
     }
 
     avc_dump_query(&buf, ssid, tsid, tclass);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 9948fca..c93b8d0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -186,6 +186,10 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
     int rc;
     struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec1, *esec2;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+    ad.sdom = d1;
+    ad.tdom = d2;
 
     dsec = current->domain->ssid;
     dsec1 = d1->ssid;
@@ -203,15 +207,15 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -1328,13 +1332,13 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *t,
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
         map_perms |= MMU__MAP_WRITE;
 
-    AVC_AUDIT_DATA_INIT(&ad, RANGE);
+    AVC_AUDIT_DATA_INIT(&ad, MEMORY);
     fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
 
     ad.sdom = d;
     ad.tdom = f;
-    ad.range.start = fpte;
-    ad.range.end = fmfn;
+    ad.memory.pte = fpte;
+    ad.memory.mfn = fmfn;
 
     rc = get_mfn_sid(fmfn, &fsid);
 
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 0f62891..42a5e4b 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -42,6 +42,7 @@ struct avc_audit_data {
 #define AVC_AUDIT_DATA_DEV   1
 #define AVC_AUDIT_DATA_IRQ   2
 #define AVC_AUDIT_DATA_RANGE 3
+#define AVC_AUDIT_DATA_MEMORY 4
     struct domain *sdom;
     struct domain *tdom;
     union {
@@ -51,12 +52,13 @@ struct avc_audit_data {
             unsigned long start;
             unsigned long end;
         } range;
+        struct {
+            unsigned long pte;
+            unsigned long mfn;
+        } memory;
     };
 };
 
-#define v4info fam.v4
-#define v6info fam.v6
-
 /* Initialize an AVC audit data structure. */
 #define AVC_AUDIT_DATA_INIT(_d,_t) \
         { memset((_d), 0, sizeof(struct avc_audit_data)); \
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:23:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnls-0005Vc-QS; Mon, 16 Apr 2012 15:23:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJnlr-0005VM-7j
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:23:15 +0000
Received: from [85.158.138.51:64741] by server-8.bemta-3.messagelabs.com id
	FD/BD-24428-2693C8F4; Mon, 16 Apr 2012 15:23:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334589791!14465532!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24421 invoked from network); 16 Apr 2012 15:23:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 15:23:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GFN0d3023193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 15:23:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GFMwm3008969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 15:22:59 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GFMvm7024494; Mon, 16 Apr 2012 10:22:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 08:22:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B84624027C; Mon, 16 Apr 2012 11:17:59 -0400 (EDT)
Date: Mon, 16 Apr 2012 11:17:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416151759.GI1903@phenom.dumpdata.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8C33E0.2080007@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F8C3955.00F6,ss=1,re=0.000,fgs=0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote:
> On 16/04/12 12:32, Jan Beulich wrote:
> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The sched clock was considered stable based on the capabilities of the
> >> underlying hardware.  This does not make sense for Xen PV guests as:

In regards to PV dom0 is this still the case? Asking b/c your
patch will make dom0 be in the same category.

> >> a) the hardware TSC is not used directly as the clock source; and b)
> >> guests may migrate to hosts with different hardware capabilities.
> >>
> >> It is not clear to me whether the Xen clock source is supposed to be
> >> stable and whether it should be stable across migration.  For a clock

I thought it was dependent on XEN_DOMCTL_settscinfo:
 - whether it gets emulated, or the guest can do rdtsc or pvrdtsc?

Which I think is determined by some 'timer=X' option in the guest config?


> >> source to be stable it must be: a) monotonic; c) synchronized across
> >> CPUs; and c) constant rate.
> 
> Tim, Thomas, can you comment on the above paragraph?  Is it correct?
> 
> >> There have also been reports of systems with apparently unstable
> >> clocks where clearing sched_clock_stable has fixed problems with
> >> migrated VMs hanging.
> >>
> >> So, always set the sched clock as unstable when using the Xen clock
> >> source.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  arch/x86/xen/time.c |    1 +
> >>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> >> index 0296a95..8469b5a 100644
> >> --- a/arch/x86/xen/time.c
> >> +++ b/arch/x86/xen/time.c
> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> >>  	do_settimeofday(&tp);
> >>  
> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> >> +	sched_clock_stable = 0;
> > 
> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> > post-boot, the variable may need to be cleared again. Instead you
> > ought to call mark_tsc_unstable().
> 
> Yeah, mark_tsc_unstable() is the right thing to do.
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:23:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnls-0005Vc-QS; Mon, 16 Apr 2012 15:23:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJnlr-0005VM-7j
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:23:15 +0000
Received: from [85.158.138.51:64741] by server-8.bemta-3.messagelabs.com id
	FD/BD-24428-2693C8F4; Mon, 16 Apr 2012 15:23:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1334589791!14465532!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24421 invoked from network); 16 Apr 2012 15:23:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 15:23:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GFN0d3023193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 15:23:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GFMwm3008969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 15:22:59 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GFMvm7024494; Mon, 16 Apr 2012 10:22:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 08:22:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B84624027C; Mon, 16 Apr 2012 11:17:59 -0400 (EDT)
Date: Mon, 16 Apr 2012 11:17:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416151759.GI1903@phenom.dumpdata.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8C33E0.2080007@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F8C3955.00F6,ss=1,re=0.000,fgs=0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote:
> On 16/04/12 12:32, Jan Beulich wrote:
> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The sched clock was considered stable based on the capabilities of the
> >> underlying hardware.  This does not make sense for Xen PV guests as:

In regards to PV dom0 is this still the case? Asking b/c your
patch will make dom0 be in the same category.

> >> a) the hardware TSC is not used directly as the clock source; and b)
> >> guests may migrate to hosts with different hardware capabilities.
> >>
> >> It is not clear to me whether the Xen clock source is supposed to be
> >> stable and whether it should be stable across migration.  For a clock

I thought it was dependent on XEN_DOMCTL_settscinfo:
 - whether it gets emulated, or the guest can do rdtsc or pvrdtsc?

Which I think is determined by some 'timer=X' option in the guest config?


> >> source to be stable it must be: a) monotonic; c) synchronized across
> >> CPUs; and c) constant rate.
> 
> Tim, Thomas, can you comment on the above paragraph?  Is it correct?
> 
> >> There have also been reports of systems with apparently unstable
> >> clocks where clearing sched_clock_stable has fixed problems with
> >> migrated VMs hanging.
> >>
> >> So, always set the sched clock as unstable when using the Xen clock
> >> source.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  arch/x86/xen/time.c |    1 +
> >>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> >> index 0296a95..8469b5a 100644
> >> --- a/arch/x86/xen/time.c
> >> +++ b/arch/x86/xen/time.c
> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> >>  	do_settimeofday(&tp);
> >>  
> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> >> +	sched_clock_stable = 0;
> > 
> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> > post-boot, the variable may need to be cleared again. Instead you
> > ought to call mark_tsc_unstable().
> 
> Yeah, mark_tsc_unstable() is the right thing to do.
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:28:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:28:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnqQ-0005wZ-HO; Mon, 16 Apr 2012 15:27:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJnqO-0005wS-Pn
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:27:56 +0000
Received: from [193.109.254.147:60204] by server-7.bemta-14.messagelabs.com id
	3D/D7-01627-C7A3C8F4; Mon, 16 Apr 2012 15:27:56 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334590074!4854349!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4895 invoked from network); 16 Apr 2012 15:27:55 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Apr 2012 15:27:55 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJnqC-0002P8-Hm
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:27:45 +0200
Received: from 94.103.167.176 ([94.103.167.176])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 17:27:44 +0200
Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 17:27:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 15:27:32 +0000 (UTC)
Lines: 12
Message-ID: <loom.20120416T171925-109@post.gmane.org>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:11.0) Gecko/20100101 Firefox/11.0)
Subject: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

May I ask what the current nestedhvm status in Xen 4.1 is? The parameter exists,
the documentation just says that only previously existent cpu features will be
passed through, but I can't seem to get a VM with "vmx" (for testing of ESX or
Hyper-V in a Xen domU) working. "nestedhvm=1" seems just to be ignored...

Is this AMD-only in 4.1? Are additional CPU host features required to make this
work (like EPT, which I do have on this Xeon 5520 box or "Shared EPT" that I
dont have but could be AMD related anyway)? Do I need unstable to make use of it?


Thanks,
   Christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:28:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:28:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJnqQ-0005wZ-HO; Mon, 16 Apr 2012 15:27:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJnqO-0005wS-Pn
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:27:56 +0000
Received: from [193.109.254.147:60204] by server-7.bemta-14.messagelabs.com id
	3D/D7-01627-C7A3C8F4; Mon, 16 Apr 2012 15:27:56 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334590074!4854349!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4895 invoked from network); 16 Apr 2012 15:27:55 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Apr 2012 15:27:55 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJnqC-0002P8-Hm
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:27:45 +0200
Received: from 94.103.167.176 ([94.103.167.176])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 17:27:44 +0200
Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 17:27:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 15:27:32 +0000 (UTC)
Lines: 12
Message-ID: <loom.20120416T171925-109@post.gmane.org>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:11.0) Gecko/20100101 Firefox/11.0)
Subject: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

May I ask what the current nestedhvm status in Xen 4.1 is? The parameter exists,
the documentation just says that only previously existent cpu features will be
passed through, but I can't seem to get a VM with "vmx" (for testing of ESX or
Hyper-V in a Xen domU) working. "nestedhvm=1" seems just to be ignored...

Is this AMD-only in 4.1? Are additional CPU host features required to make this
work (like EPT, which I do have on this Xeon 5520 box or "Shared EPT" that I
dont have but could be AMD related anyway)? Do I need unstable to make use of it?


Thanks,
   Christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo2M-0006He-Rj; Mon, 16 Apr 2012 15:40:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SJo2M-0006HZ-0k
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:40:18 +0000
Received: from [85.158.143.35:47237] by server-1.bemta-4.messagelabs.com id
	99/AE-20925-16D3C8F4; Mon, 16 Apr 2012 15:40:17 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334590805!13494171!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10280 invoked from network); 16 Apr 2012 15:40:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:40:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190534383"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:39:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:39:59 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SJo22-0001kx-Fl;
	Mon, 16 Apr 2012 16:39:58 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 16:38:49 +0100
Message-ID: <1334590729-6971-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	"John V. Baboval" <john.baboval@virtualcomputer.com>,
	Tom Goetz <tom.goetz@virtualcomputer.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: Support guest reboots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: John V. Baboval <john.baboval@virtualcomputer.com>

Call xc_domain_shutdown with the reboot flag when the guest requests a reboot.

Signed-off-by: John V. Baboval <john.baboval@virtualcomputer.com>
Signed-off-by: Tom Goetz <tom.goetz@virtualcomputer.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 hw/xen_common.h |    2 +-
 xen-all.c       |   18 +++++++++++-------
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..bb5a12f 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -133,6 +133,6 @@ static inline int xc_fd(xc_interface *xen_xc)
 }
 #endif
 
-void destroy_hvm_domain(void);
+void destroy_hvm_domain(bool reboot);
 
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..4eb2270 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -832,7 +832,7 @@ static void cpu_handle_ioreq(void *opaque)
                     "data: %"PRIx64", count: %" FMT_ioreq_size ", size: %" FMT_ioreq_size "\n",
                     req->state, req->data_is_ptr, req->addr,
                     req->data, req->count, req->size);
-            destroy_hvm_domain();
+            destroy_hvm_domain(false);
             return;
         }
 
@@ -846,10 +846,11 @@ static void cpu_handle_ioreq(void *opaque)
          */
         if (runstate_is_running()) {
             if (qemu_shutdown_requested_get()) {
-                destroy_hvm_domain();
+                destroy_hvm_domain(false);
             }
             if (qemu_reset_requested_get()) {
                 qemu_system_reset(VMRESET_REPORT);
+                destroy_hvm_domain(true);
             }
         }
 
@@ -1121,7 +1122,7 @@ int xen_hvm_init(void)
     return 0;
 }
 
-void destroy_hvm_domain(void)
+void destroy_hvm_domain(bool reboot)
 {
     XenXC xc_handle;
     int sts;
@@ -1130,12 +1131,15 @@ void destroy_hvm_domain(void)
     if (xc_handle == XC_HANDLER_INITIAL_VALUE) {
         fprintf(stderr, "Cannot acquire xenctrl handle\n");
     } else {
-        sts = xc_domain_shutdown(xc_handle, xen_domid, SHUTDOWN_poweroff);
+        sts = xc_domain_shutdown(xc_handle, xen_domid,
+                                 reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff);
         if (sts != 0) {
-            fprintf(stderr, "? xc_domain_shutdown failed to issue poweroff, "
-                    "sts %d, %s\n", sts, strerror(errno));
+            fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
+                    "sts %d, %s\n", reboot ? "reboot" : "poweroff",
+                    sts, strerror(errno));
         } else {
-            fprintf(stderr, "Issued domain %d poweroff\n", xen_domid);
+            fprintf(stderr, "Issued domain %d %s\n", xen_domid,
+                    reboot ? "reboot" : "poweroff");
         }
         xc_interface_close(xc_handle);
     }
-- 
tg: (df4fc17..) bavoral-fix/reboot (depends on: perso/master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo2M-0006He-Rj; Mon, 16 Apr 2012 15:40:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SJo2M-0006HZ-0k
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:40:18 +0000
Received: from [85.158.143.35:47237] by server-1.bemta-4.messagelabs.com id
	99/AE-20925-16D3C8F4; Mon, 16 Apr 2012 15:40:17 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334590805!13494171!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10280 invoked from network); 16 Apr 2012 15:40:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:40:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190534383"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:39:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 11:39:59 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SJo22-0001kx-Fl;
	Mon, 16 Apr 2012 16:39:58 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 16:38:49 +0100
Message-ID: <1334590729-6971-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	"John V. Baboval" <john.baboval@virtualcomputer.com>,
	Tom Goetz <tom.goetz@virtualcomputer.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: Support guest reboots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: John V. Baboval <john.baboval@virtualcomputer.com>

Call xc_domain_shutdown with the reboot flag when the guest requests a reboot.

Signed-off-by: John V. Baboval <john.baboval@virtualcomputer.com>
Signed-off-by: Tom Goetz <tom.goetz@virtualcomputer.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 hw/xen_common.h |    2 +-
 xen-all.c       |   18 +++++++++++-------
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..bb5a12f 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -133,6 +133,6 @@ static inline int xc_fd(xc_interface *xen_xc)
 }
 #endif
 
-void destroy_hvm_domain(void);
+void destroy_hvm_domain(bool reboot);
 
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/xen-all.c b/xen-all.c
index 3e6de41..4eb2270 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -832,7 +832,7 @@ static void cpu_handle_ioreq(void *opaque)
                     "data: %"PRIx64", count: %" FMT_ioreq_size ", size: %" FMT_ioreq_size "\n",
                     req->state, req->data_is_ptr, req->addr,
                     req->data, req->count, req->size);
-            destroy_hvm_domain();
+            destroy_hvm_domain(false);
             return;
         }
 
@@ -846,10 +846,11 @@ static void cpu_handle_ioreq(void *opaque)
          */
         if (runstate_is_running()) {
             if (qemu_shutdown_requested_get()) {
-                destroy_hvm_domain();
+                destroy_hvm_domain(false);
             }
             if (qemu_reset_requested_get()) {
                 qemu_system_reset(VMRESET_REPORT);
+                destroy_hvm_domain(true);
             }
         }
 
@@ -1121,7 +1122,7 @@ int xen_hvm_init(void)
     return 0;
 }
 
-void destroy_hvm_domain(void)
+void destroy_hvm_domain(bool reboot)
 {
     XenXC xc_handle;
     int sts;
@@ -1130,12 +1131,15 @@ void destroy_hvm_domain(void)
     if (xc_handle == XC_HANDLER_INITIAL_VALUE) {
         fprintf(stderr, "Cannot acquire xenctrl handle\n");
     } else {
-        sts = xc_domain_shutdown(xc_handle, xen_domid, SHUTDOWN_poweroff);
+        sts = xc_domain_shutdown(xc_handle, xen_domid,
+                                 reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff);
         if (sts != 0) {
-            fprintf(stderr, "? xc_domain_shutdown failed to issue poweroff, "
-                    "sts %d, %s\n", sts, strerror(errno));
+            fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
+                    "sts %d, %s\n", reboot ? "reboot" : "poweroff",
+                    sts, strerror(errno));
         } else {
-            fprintf(stderr, "Issued domain %d poweroff\n", xen_domid);
+            fprintf(stderr, "Issued domain %d %s\n", xen_domid,
+                    reboot ? "reboot" : "poweroff");
         }
         xc_interface_close(xc_handle);
     }
-- 
tg: (df4fc17..) bavoral-fix/reboot (depends on: perso/master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:41:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:41:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo2v-0006KD-8b; Mon, 16 Apr 2012 15:40:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SJo2u-0006K0-0O
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:40:52 +0000
Received: from [85.158.143.35:4609] by server-1.bemta-4.messagelabs.com id
	E4/9F-20925-38D3C8F4; Mon, 16 Apr 2012 15:40:51 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334590849!13494287!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11832 invoked from network); 16 Apr 2012 15:40:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190534636"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:40:49 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012
	11:40:48 -0400
Message-ID: <4F8C3D7F.4020703@citrix.com>
Date: Mon, 16 Apr 2012 16:40:47 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
	<20120416151045.GH1903@phenom.dumpdata.com>
In-Reply-To: <20120416151045.GH1903@phenom.dumpdata.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/04/12 16:10, Konrad Rzeszutek Wilk wrote:
> 
> But I think it makes sense to stick this in arch/x86/pci/xen.c - if
> it is not to late in teh bootup cycle?

pci_xen_init() is called early enough I think, but is only called for
domU (not dom0).  I can change this if you prefer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:41:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:41:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo2v-0006KD-8b; Mon, 16 Apr 2012 15:40:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SJo2u-0006K0-0O
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:40:52 +0000
Received: from [85.158.143.35:4609] by server-1.bemta-4.messagelabs.com id
	E4/9F-20925-38D3C8F4; Mon, 16 Apr 2012 15:40:51 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334590849!13494287!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11832 invoked from network); 16 Apr 2012 15:40:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190534636"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 11:40:49 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012
	11:40:48 -0400
Message-ID: <4F8C3D7F.4020703@citrix.com>
Date: Mon, 16 Apr 2012 16:40:47 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
	<20120416151045.GH1903@phenom.dumpdata.com>
In-Reply-To: <20120416151045.GH1903@phenom.dumpdata.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/04/12 16:10, Konrad Rzeszutek Wilk wrote:
> 
> But I think it makes sense to stick this in arch/x86/pci/xen.c - if
> it is not to late in teh bootup cycle?

pci_xen_init() is called early enough I think, but is only called for
domU (not dom0).  I can change this if you prefer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo4N-0006RA-OS; Mon, 16 Apr 2012 15:42:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SJo4L-0006R3-JX
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:42:21 +0000
Received: from [193.109.254.147:58865] by server-11.bemta-14.messagelabs.com
	id A0/AD-05858-CDD3C8F4; Mon, 16 Apr 2012 15:42:20 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334590933!4784103!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8266 invoked from network); 16 Apr 2012 15:42:14 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:42:14 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 01184542FD; Mon, 16 Apr 2012 17:42:10 +0200 (CEST)
Date: Mon, 16 Apr 2012 17:42:10 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120416154210.GA6338@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

The xenstore header xs.h is producing conflicts with other software[1].

xs is a too short identifier and does not matche the library. Renaming
the headers to xenstore.h and xenstore_lib.h is the easiest way to make
them easy recognizable and prevent furthe problems.

Bastian

[1]: http://bugs.debian.org/668550
-- 
Where there's no emotion, there's no motive for violence.
		-- Spock, "Dagger of the Mind", stardate 2715.1

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename=diff

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -237,7 +237,7 @@
 	rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
 	rm -rf $(D)$(BINDIR)/xsls
 	rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
-	rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
+	rm -rf $(D)$(INCLUDEDIR)/xenstore_lib.h $(D)$(INCLUDEDIR)/xenstore.h
 	rm -rf $(D)$(INCLUDEDIR)/xen
 	rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
 	rm -rf $(D)$(LIBDIR)/libxenstore*
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -28,7 +28,7 @@
 #include <blkfront.h>
 #include <fbfront.h>
 #include <xenbus.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
diff --git a/extras/mini-os/lib/xs.c b/extras/mini-os/lib/xs.c
--- a/extras/mini-os/lib/xs.c
+++ b/extras/mini-os/lib/xs.c
@@ -9,7 +9,7 @@
 #ifdef HAVE_LIBC
 #include <os.h>
 #include <lib.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <xenbus.h>
 #include <stdlib.h>
 #include <unistd.h>
diff --git a/tools/blktap/drivers/blktapctrl.c b/tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c
+++ b/tools/blktap/drivers/blktapctrl.c
@@ -47,7 +47,7 @@
 #include <sys/ioctl.h>
 #include <string.h>
 #include <unistd.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/time.h>
 #include <syslog.h>
 #include <memshr.h>
diff --git a/tools/blktap/lib/blktaplib.h b/tools/blktap/lib/blktaplib.h
--- a/tools/blktap/lib/blktaplib.h
+++ b/tools/blktap/lib/blktaplib.h
@@ -38,7 +38,7 @@
 #include <xen/xen.h>
 #include <xen/io/blkif.h>
 #include <xen/io/ring.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/types.h>
 #include <unistd.h>
 
diff --git a/tools/blktap/lib/xenbus.c b/tools/blktap/lib/xenbus.c
--- a/tools/blktap/lib/xenbus.c
+++ b/tools/blktap/lib/xenbus.c
@@ -41,7 +41,7 @@
 #include <err.h>
 #include <stdarg.h>
 #include <errno.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
diff --git a/tools/blktap/lib/xs_api.c b/tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -38,7 +38,7 @@
 #include <err.h>
 #include <stdarg.h>
 #include <errno.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
diff --git a/tools/console/client/main.c b/tools/console/client/main.c
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -39,7 +39,7 @@
 #include <sys/stropts.h>
 #endif
 
-#include "xs.h"
+#include <xenstore.h>
 #include "xenctrl.h"
 
 #define ESCAPE_CHARACTER 0x1d
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -22,7 +22,7 @@
 
 #include "utils.h"
 #include "io.h"
-#include <xs.h>
+#include <xenstore.h>
 #include <xen/io/console.h>
 
 #include <stdlib.h>
diff --git a/tools/console/daemon/utils.h b/tools/console/daemon/utils.h
--- a/tools/console/daemon/utils.h
+++ b/tools/console/daemon/utils.h
@@ -26,7 +26,7 @@
 #include <stdio.h>
 #include <xenctrl.h>
 
-#include "xs.h"
+#include <xenstore.h>
 
 void daemonize(const char *pidfile);
 bool xen_setup(void);
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -40,7 +40,7 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xen/sys/evtchn.h>
 #include <xen/sys/gntalloc.h>
 #include <xen/sys/gntdev.h>
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -43,7 +43,7 @@
 #include <sys/types.h>
 #include <sys/wait.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xenctrl.h>
 
 #include "xentoollog.h"
diff --git a/tools/misc/xen-lowmemd.c b/tools/misc/xen-lowmemd.c
--- a/tools/misc/xen-lowmemd.c
+++ b/tools/misc/xen-lowmemd.c
@@ -5,7 +5,7 @@
 
 #include <stdio.h>
 #include <xenctrl.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <stdlib.h>
 #include <string.h>
 
diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.c b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
@@ -2,7 +2,7 @@
 
 #include <Python.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xenctrl.h>
 
 #include "checkpoint.h"
diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.h b/tools/python/xen/lowlevel/checkpoint/checkpoint.h
--- a/tools/python/xen/lowlevel/checkpoint/checkpoint.h
+++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.h
@@ -8,7 +8,7 @@
 #include <time.h>
 
 #include <xenguest.h>
-#include <xs.h>
+#include <xenstore.h>
 
 typedef enum {
     dt_unknown,
diff --git a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
@@ -11,7 +11,7 @@
 
 #include <xenctrl.h>
 #include <xenguest.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #include "checkpoint.h"
 
diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -30,7 +30,7 @@
 #include <fcntl.h>
 #include <errno.h>
 
-#include "xs.h"
+#include <xenstore.h>
 
 /** @file
  * Python interface to the Xen Store Daemon (xs).
diff --git a/tools/tests/mce-test/tools/xen-mceinj.c b/tools/tests/mce-test/tools/xen-mceinj.c
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -38,7 +38,7 @@
 #include <sys/time.h>
 #include <xen/arch-x86/xen-mca.h>
 #include <xg_save_restore.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #define MCi_type_CTL        0x0
 #define MCi_type_STATUS     0x1
diff --git a/tools/xcutils/xc_save.c b/tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -19,7 +19,7 @@
 #include <fcntl.h>
 #include <err.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xenctrl.h>
 #include <xenguest.h>
 
diff --git a/tools/xenbackendd/xenbackendd.c b/tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c
+++ b/tools/xenbackendd/xenbackendd.c
@@ -28,7 +28,7 @@
 #include <string.h>
 #include <syslog.h>
 
-#include <xs.h>
+#include <xenstore.h>
 
 #define DEVTYPE_UNKNOWN 0
 #define DEVTYPE_VIF 1
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -29,7 +29,7 @@
 #include <unistd.h>
 #include <poll.h>
 #include <xc_private.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <getopt.h>
 
 #include "xc_bitops.h"
diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c
--- a/tools/xenpmd/xenpmd.c
+++ b/tools/xenpmd/xenpmd.c
@@ -40,7 +40,7 @@
 #include <dirent.h>
 #include <unistd.h>
 #include <sys/stat.h>
-#include <xs.h>
+#include <xenstore.h>
 
 /* #define RUN_STANDALONE */
 #define RUN_IN_SIMULATE_MODE
diff --git a/tools/xenstat/libxenstat/src/xenstat_priv.h b/tools/xenstat/libxenstat/src/xenstat_priv.h
--- a/tools/xenstat/libxenstat/src/xenstat_priv.h
+++ b/tools/xenstat/libxenstat/src/xenstat_priv.h
@@ -24,7 +24,7 @@
 #define XENSTAT_PRIV_H
 
 #include <sys/types.h>
-#include <xs.h>
+#include <xenstore.h>
 #include "xenstat.h"
 
 #include "xenctrl.h"
diff --git a/tools/xenstore/COPYING b/tools/xenstore/COPYING
--- a/tools/xenstore/COPYING
+++ b/tools/xenstore/COPYING
@@ -1,6 +1,6 @@
 This license (LGPL) applies to the xenstore library which interfaces
-with the xenstore daemon (as stated in xs.c, xs.h, xs_lib.c and
-xs_lib.h).  The remaining files in the directory are licensed as
+with the xenstore daemon (as stated in xs.c, xenstore.h, xs_lib.c and
+xenstore_lib.h).  The remaining files in the directory are licensed as
 stated in the comments (as of this writing, GPL, see ../../COPYING).
 
 
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -122,8 +122,8 @@
 	ln -sf libxenstore.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenstore.so.$(MAJOR)
 	ln -sf libxenstore.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenstore.so
 	$(INSTALL_DATA) libxenstore.a $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) xs.h $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_DATA) xs_lib.h $(DESTDIR)$(INCLUDEDIR)
+	$(INSTALL_DATA) xenstore.h $(DESTDIR)$(INCLUDEDIR)
+	$(INSTALL_DATA) xenstore_lib.h $(DESTDIR)$(INCLUDEDIR)
 
 -include $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
--- a/tools/xenstore/init-xenstore-domain.c
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -7,7 +7,7 @@
 #include <sys/mman.h>
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <xen/sys/xenbus_dev.h>
 
 static uint32_t domid = -1;
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xenstore.h
rename from tools/xenstore/xs.h
rename to tools/xenstore/xenstore.h
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xenstore.h
@@ -17,10 +17,10 @@
     Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
-#ifndef _XS_H
-#define _XS_H
+#ifndef XENSTORE_H
+#define XENSTORE_H
 
-#include <xs_lib.h>
+#include <xenstore_lib.h>
 
 #define XBT_NULL 0
 
@@ -223,7 +223,7 @@
 		       void *data, unsigned int len);
 
 int xs_suspend_evtchn_port(int domid);
-#endif /* _XS_H */
+#endif /* XENSTORE_H */
 
 /*
  * Local variables:
diff --git a/tools/xenstore/xenstore_client.c b/tools/xenstore/xenstore_client.c
--- a/tools/xenstore/xenstore_client.c
+++ b/tools/xenstore/xenstore_client.c
@@ -18,7 +18,7 @@
 #include <string.h>
 #include <termios.h>
 #include <unistd.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #include <sys/ioctl.h>
 
diff --git a/tools/xenstore/xenstore_control.c b/tools/xenstore/xenstore_control.c
--- a/tools/xenstore/xenstore_control.c
+++ b/tools/xenstore/xenstore_control.c
@@ -2,7 +2,7 @@
 #include <stdlib.h>
 #include <string.h>
 
-#include "xs.h"
+#include "xenstore.h"
 
 
 int main(int argc, char **argv)
diff --git a/tools/xenstore/xs_lib.h b/tools/xenstore/xenstore_lib.h
rename from tools/xenstore/xs_lib.h
rename to tools/xenstore/xenstore_lib.h
--- a/tools/xenstore/xs_lib.h
+++ b/tools/xenstore/xenstore_lib.h
@@ -17,8 +17,8 @@
     Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
-#ifndef _XS_LIB_H
-#define _XS_LIB_H
+#ifndef XENSTORE_LIB_H
+#define XENSTORE_LIB_H
 
 #include <stdbool.h>
 #include <limits.h>
@@ -82,4 +82,4 @@
 /* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */
 void unsanitise_value(char *out, unsigned *out_len_r, const char *in);
 
-#endif /* _XS_LIB_H */
+#endif /* XENSTORE_LIB_H */
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -44,7 +44,7 @@
 #include "utils.h"
 #include "list.h"
 #include "talloc.h"
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "xenstored_core.h"
 #include "xenstored_watch.h"
 #include "xenstored_transaction.h"
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -27,7 +27,7 @@
 #include <stdbool.h>
 #include <stdint.h>
 #include <errno.h>
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "list.h"
 #include "tdb.h"
 
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -33,7 +33,7 @@
 #include "xenstored_transaction.h"
 #include "xenstored_watch.h"
 #include "xenstored_domain.h"
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "utils.h"
 
 struct changed_node
diff --git a/tools/xenstore/xenstored_watch.c b/tools/xenstore/xenstored_watch.c
--- a/tools/xenstore/xenstored_watch.c
+++ b/tools/xenstore/xenstored_watch.c
@@ -27,7 +27,7 @@
 #include "talloc.h"
 #include "list.h"
 #include "xenstored_watch.h"
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "utils.h"
 #include "xenstored_domain.h"
 
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -32,7 +32,7 @@
 #include <signal.h>
 #include <stdint.h>
 #include <errno.h>
-#include "xs.h"
+#include "xenstore.h"
 #include "list.h"
 #include "utils.h"
 
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -23,7 +23,7 @@
 #include <stdlib.h>
 #include <errno.h>
 #include <assert.h>
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 
 /* Common routines for the Xen store daemon and client library. */
 
diff --git a/tools/xenstore/xs_tdb_dump.c b/tools/xenstore/xs_tdb_dump.c
--- a/tools/xenstore/xs_tdb_dump.c
+++ b/tools/xenstore/xs_tdb_dump.c
@@ -5,7 +5,7 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <string.h>
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "tdb.h"
 #include "talloc.h"
 #include "utils.h"

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bp/iNruPH9dso1Pn--


From xen-devel-bounces@lists.xen.org Mon Apr 16 15:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo4N-0006RA-OS; Mon, 16 Apr 2012 15:42:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SJo4L-0006R3-JX
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:42:21 +0000
Received: from [193.109.254.147:58865] by server-11.bemta-14.messagelabs.com
	id A0/AD-05858-CDD3C8F4; Mon, 16 Apr 2012 15:42:20 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334590933!4784103!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8266 invoked from network); 16 Apr 2012 15:42:14 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:42:14 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 01184542FD; Mon, 16 Apr 2012 17:42:10 +0200 (CEST)
Date: Mon, 16 Apr 2012 17:42:10 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120416154210.GA6338@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

The xenstore header xs.h is producing conflicts with other software[1].

xs is a too short identifier and does not matche the library. Renaming
the headers to xenstore.h and xenstore_lib.h is the easiest way to make
them easy recognizable and prevent furthe problems.

Bastian

[1]: http://bugs.debian.org/668550
-- 
Where there's no emotion, there's no motive for violence.
		-- Spock, "Dagger of the Mind", stardate 2715.1

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename=diff

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -237,7 +237,7 @@
 	rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
 	rm -rf $(D)$(BINDIR)/xsls
 	rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
-	rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
+	rm -rf $(D)$(INCLUDEDIR)/xenstore_lib.h $(D)$(INCLUDEDIR)/xenstore.h
 	rm -rf $(D)$(INCLUDEDIR)/xen
 	rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
 	rm -rf $(D)$(LIBDIR)/libxenstore*
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -28,7 +28,7 @@
 #include <blkfront.h>
 #include <fbfront.h>
 #include <xenbus.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
diff --git a/extras/mini-os/lib/xs.c b/extras/mini-os/lib/xs.c
--- a/extras/mini-os/lib/xs.c
+++ b/extras/mini-os/lib/xs.c
@@ -9,7 +9,7 @@
 #ifdef HAVE_LIBC
 #include <os.h>
 #include <lib.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <xenbus.h>
 #include <stdlib.h>
 #include <unistd.h>
diff --git a/tools/blktap/drivers/blktapctrl.c b/tools/blktap/drivers/blktapctrl.c
--- a/tools/blktap/drivers/blktapctrl.c
+++ b/tools/blktap/drivers/blktapctrl.c
@@ -47,7 +47,7 @@
 #include <sys/ioctl.h>
 #include <string.h>
 #include <unistd.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/time.h>
 #include <syslog.h>
 #include <memshr.h>
diff --git a/tools/blktap/lib/blktaplib.h b/tools/blktap/lib/blktaplib.h
--- a/tools/blktap/lib/blktaplib.h
+++ b/tools/blktap/lib/blktaplib.h
@@ -38,7 +38,7 @@
 #include <xen/xen.h>
 #include <xen/io/blkif.h>
 #include <xen/io/ring.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/types.h>
 #include <unistd.h>
 
diff --git a/tools/blktap/lib/xenbus.c b/tools/blktap/lib/xenbus.c
--- a/tools/blktap/lib/xenbus.c
+++ b/tools/blktap/lib/xenbus.c
@@ -41,7 +41,7 @@
 #include <err.h>
 #include <stdarg.h>
 #include <errno.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
diff --git a/tools/blktap/lib/xs_api.c b/tools/blktap/lib/xs_api.c
--- a/tools/blktap/lib/xs_api.c
+++ b/tools/blktap/lib/xs_api.c
@@ -38,7 +38,7 @@
 #include <err.h>
 #include <stdarg.h>
 #include <errno.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
diff --git a/tools/console/client/main.c b/tools/console/client/main.c
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -39,7 +39,7 @@
 #include <sys/stropts.h>
 #endif
 
-#include "xs.h"
+#include <xenstore.h>
 #include "xenctrl.h"
 
 #define ESCAPE_CHARACTER 0x1d
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -22,7 +22,7 @@
 
 #include "utils.h"
 #include "io.h"
-#include <xs.h>
+#include <xenstore.h>
 #include <xen/io/console.h>
 
 #include <stdlib.h>
diff --git a/tools/console/daemon/utils.h b/tools/console/daemon/utils.h
--- a/tools/console/daemon/utils.h
+++ b/tools/console/daemon/utils.h
@@ -26,7 +26,7 @@
 #include <stdio.h>
 #include <xenctrl.h>
 
-#include "xs.h"
+#include <xenstore.h>
 
 void daemonize(const char *pidfile);
 bool xen_setup(void);
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -40,7 +40,7 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xen/sys/evtchn.h>
 #include <xen/sys/gntalloc.h>
 #include <xen/sys/gntdev.h>
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -43,7 +43,7 @@
 #include <sys/types.h>
 #include <sys/wait.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xenctrl.h>
 
 #include "xentoollog.h"
diff --git a/tools/misc/xen-lowmemd.c b/tools/misc/xen-lowmemd.c
--- a/tools/misc/xen-lowmemd.c
+++ b/tools/misc/xen-lowmemd.c
@@ -5,7 +5,7 @@
 
 #include <stdio.h>
 #include <xenctrl.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <stdlib.h>
 #include <string.h>
 
diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.c b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
@@ -2,7 +2,7 @@
 
 #include <Python.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xenctrl.h>
 
 #include "checkpoint.h"
diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.h b/tools/python/xen/lowlevel/checkpoint/checkpoint.h
--- a/tools/python/xen/lowlevel/checkpoint/checkpoint.h
+++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.h
@@ -8,7 +8,7 @@
 #include <time.h>
 
 #include <xenguest.h>
-#include <xs.h>
+#include <xenstore.h>
 
 typedef enum {
     dt_unknown,
diff --git a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
@@ -11,7 +11,7 @@
 
 #include <xenctrl.h>
 #include <xenguest.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #include "checkpoint.h"
 
diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -30,7 +30,7 @@
 #include <fcntl.h>
 #include <errno.h>
 
-#include "xs.h"
+#include <xenstore.h>
 
 /** @file
  * Python interface to the Xen Store Daemon (xs).
diff --git a/tools/tests/mce-test/tools/xen-mceinj.c b/tools/tests/mce-test/tools/xen-mceinj.c
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -38,7 +38,7 @@
 #include <sys/time.h>
 #include <xen/arch-x86/xen-mca.h>
 #include <xg_save_restore.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #define MCi_type_CTL        0x0
 #define MCi_type_STATUS     0x1
diff --git a/tools/xcutils/xc_save.c b/tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -19,7 +19,7 @@
 #include <fcntl.h>
 #include <err.h>
 
-#include <xs.h>
+#include <xenstore.h>
 #include <xenctrl.h>
 #include <xenguest.h>
 
diff --git a/tools/xenbackendd/xenbackendd.c b/tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c
+++ b/tools/xenbackendd/xenbackendd.c
@@ -28,7 +28,7 @@
 #include <string.h>
 #include <syslog.h>
 
-#include <xs.h>
+#include <xenstore.h>
 
 #define DEVTYPE_UNKNOWN 0
 #define DEVTYPE_VIF 1
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -29,7 +29,7 @@
 #include <unistd.h>
 #include <poll.h>
 #include <xc_private.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <getopt.h>
 
 #include "xc_bitops.h"
diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c
--- a/tools/xenpmd/xenpmd.c
+++ b/tools/xenpmd/xenpmd.c
@@ -40,7 +40,7 @@
 #include <dirent.h>
 #include <unistd.h>
 #include <sys/stat.h>
-#include <xs.h>
+#include <xenstore.h>
 
 /* #define RUN_STANDALONE */
 #define RUN_IN_SIMULATE_MODE
diff --git a/tools/xenstat/libxenstat/src/xenstat_priv.h b/tools/xenstat/libxenstat/src/xenstat_priv.h
--- a/tools/xenstat/libxenstat/src/xenstat_priv.h
+++ b/tools/xenstat/libxenstat/src/xenstat_priv.h
@@ -24,7 +24,7 @@
 #define XENSTAT_PRIV_H
 
 #include <sys/types.h>
-#include <xs.h>
+#include <xenstore.h>
 #include "xenstat.h"
 
 #include "xenctrl.h"
diff --git a/tools/xenstore/COPYING b/tools/xenstore/COPYING
--- a/tools/xenstore/COPYING
+++ b/tools/xenstore/COPYING
@@ -1,6 +1,6 @@
 This license (LGPL) applies to the xenstore library which interfaces
-with the xenstore daemon (as stated in xs.c, xs.h, xs_lib.c and
-xs_lib.h).  The remaining files in the directory are licensed as
+with the xenstore daemon (as stated in xs.c, xenstore.h, xs_lib.c and
+xenstore_lib.h).  The remaining files in the directory are licensed as
 stated in the comments (as of this writing, GPL, see ../../COPYING).
 
 
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -122,8 +122,8 @@
 	ln -sf libxenstore.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenstore.so.$(MAJOR)
 	ln -sf libxenstore.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenstore.so
 	$(INSTALL_DATA) libxenstore.a $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) xs.h $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_DATA) xs_lib.h $(DESTDIR)$(INCLUDEDIR)
+	$(INSTALL_DATA) xenstore.h $(DESTDIR)$(INCLUDEDIR)
+	$(INSTALL_DATA) xenstore_lib.h $(DESTDIR)$(INCLUDEDIR)
 
 -include $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
--- a/tools/xenstore/init-xenstore-domain.c
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -7,7 +7,7 @@
 #include <sys/mman.h>
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <xen/sys/xenbus_dev.h>
 
 static uint32_t domid = -1;
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xenstore.h
rename from tools/xenstore/xs.h
rename to tools/xenstore/xenstore.h
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xenstore.h
@@ -17,10 +17,10 @@
     Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
-#ifndef _XS_H
-#define _XS_H
+#ifndef XENSTORE_H
+#define XENSTORE_H
 
-#include <xs_lib.h>
+#include <xenstore_lib.h>
 
 #define XBT_NULL 0
 
@@ -223,7 +223,7 @@
 		       void *data, unsigned int len);
 
 int xs_suspend_evtchn_port(int domid);
-#endif /* _XS_H */
+#endif /* XENSTORE_H */
 
 /*
  * Local variables:
diff --git a/tools/xenstore/xenstore_client.c b/tools/xenstore/xenstore_client.c
--- a/tools/xenstore/xenstore_client.c
+++ b/tools/xenstore/xenstore_client.c
@@ -18,7 +18,7 @@
 #include <string.h>
 #include <termios.h>
 #include <unistd.h>
-#include <xs.h>
+#include <xenstore.h>
 
 #include <sys/ioctl.h>
 
diff --git a/tools/xenstore/xenstore_control.c b/tools/xenstore/xenstore_control.c
--- a/tools/xenstore/xenstore_control.c
+++ b/tools/xenstore/xenstore_control.c
@@ -2,7 +2,7 @@
 #include <stdlib.h>
 #include <string.h>
 
-#include "xs.h"
+#include "xenstore.h"
 
 
 int main(int argc, char **argv)
diff --git a/tools/xenstore/xs_lib.h b/tools/xenstore/xenstore_lib.h
rename from tools/xenstore/xs_lib.h
rename to tools/xenstore/xenstore_lib.h
--- a/tools/xenstore/xs_lib.h
+++ b/tools/xenstore/xenstore_lib.h
@@ -17,8 +17,8 @@
     Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
-#ifndef _XS_LIB_H
-#define _XS_LIB_H
+#ifndef XENSTORE_LIB_H
+#define XENSTORE_LIB_H
 
 #include <stdbool.h>
 #include <limits.h>
@@ -82,4 +82,4 @@
 /* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */
 void unsanitise_value(char *out, unsigned *out_len_r, const char *in);
 
-#endif /* _XS_LIB_H */
+#endif /* XENSTORE_LIB_H */
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -44,7 +44,7 @@
 #include "utils.h"
 #include "list.h"
 #include "talloc.h"
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "xenstored_core.h"
 #include "xenstored_watch.h"
 #include "xenstored_transaction.h"
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -27,7 +27,7 @@
 #include <stdbool.h>
 #include <stdint.h>
 #include <errno.h>
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "list.h"
 #include "tdb.h"
 
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -33,7 +33,7 @@
 #include "xenstored_transaction.h"
 #include "xenstored_watch.h"
 #include "xenstored_domain.h"
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "utils.h"
 
 struct changed_node
diff --git a/tools/xenstore/xenstored_watch.c b/tools/xenstore/xenstored_watch.c
--- a/tools/xenstore/xenstored_watch.c
+++ b/tools/xenstore/xenstored_watch.c
@@ -27,7 +27,7 @@
 #include "talloc.h"
 #include "list.h"
 #include "xenstored_watch.h"
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "utils.h"
 #include "xenstored_domain.h"
 
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -32,7 +32,7 @@
 #include <signal.h>
 #include <stdint.h>
 #include <errno.h>
-#include "xs.h"
+#include "xenstore.h"
 #include "list.h"
 #include "utils.h"
 
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -23,7 +23,7 @@
 #include <stdlib.h>
 #include <errno.h>
 #include <assert.h>
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 
 /* Common routines for the Xen store daemon and client library. */
 
diff --git a/tools/xenstore/xs_tdb_dump.c b/tools/xenstore/xs_tdb_dump.c
--- a/tools/xenstore/xs_tdb_dump.c
+++ b/tools/xenstore/xs_tdb_dump.c
@@ -5,7 +5,7 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <string.h>
-#include "xs_lib.h"
+#include "xenstore_lib.h"
 #include "tdb.h"
 #include "talloc.h"
 #include "utils.h"

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bp/iNruPH9dso1Pn--


From xen-devel-bounces@lists.xen.org Mon Apr 16 15:43:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo4q-0006Uv-Bp; Mon, 16 Apr 2012 15:42:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJo4p-0006Ue-NP
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:42:51 +0000
Received: from [85.158.143.35:61187] by server-1.bemta-4.messagelabs.com id
	15/32-20925-BFD3C8F4; Mon, 16 Apr 2012 15:42:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334590970!13494597!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17186 invoked from network); 16 Apr 2012 15:42:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 15:42:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJo4c-0004Ze-Rq; Mon, 16 Apr 2012 15:42:38 +0000
Date: Mon, 16 Apr 2012 16:42:38 +0100
From: Tim Deegan <tim@xen.org>
To: Christian Tramnitz <chris.ace@gmx.net>
Message-ID: <20120416154238.GC13111@ocelot.phlegethon.org>
References: <loom.20120416T171925-109@post.gmane.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <loom.20120416T171925-109@post.gmane.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:27 +0000 on 16 Apr (1334590052), Christian Tramnitz wrote:
> Do I need unstable to make use of it?

Yes, all the nested HVM code is newer than 4.1.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:43:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo4q-0006Uv-Bp; Mon, 16 Apr 2012 15:42:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJo4p-0006Ue-NP
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:42:51 +0000
Received: from [85.158.143.35:61187] by server-1.bemta-4.messagelabs.com id
	15/32-20925-BFD3C8F4; Mon, 16 Apr 2012 15:42:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334590970!13494597!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17186 invoked from network); 16 Apr 2012 15:42:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 15:42:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJo4c-0004Ze-Rq; Mon, 16 Apr 2012 15:42:38 +0000
Date: Mon, 16 Apr 2012 16:42:38 +0100
From: Tim Deegan <tim@xen.org>
To: Christian Tramnitz <chris.ace@gmx.net>
Message-ID: <20120416154238.GC13111@ocelot.phlegethon.org>
References: <loom.20120416T171925-109@post.gmane.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <loom.20120416T171925-109@post.gmane.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:27 +0000 on 16 Apr (1334590052), Christian Tramnitz wrote:
> Do I need unstable to make use of it?

Yes, all the nested HVM code is newer than 4.1.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:44:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo6L-0006iP-Ub; Mon, 16 Apr 2012 15:44:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJo6K-0006iC-8B
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:44:24 +0000
Received: from [85.158.143.99:42464] by server-3.bemta-4.messagelabs.com id
	6C/77-05853-75E3C8F4; Mon, 16 Apr 2012 15:44:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334591062!23546833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3173 invoked from network); 16 Apr 2012 15:44:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11959703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:44:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 16:44:22 +0100
Message-ID: <1334591061.14560.213.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 16:44:21 +0100
In-Reply-To: <loom.20120416T171925-109@post.gmane.org>
References: <loom.20120416T171925-109@post.gmane.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:27 +0100, Christian Tramnitz wrote:
> May I ask what the current nestedhvm status in Xen 4.1 is? The parameter exists,
> the documentation just says that only previously existent cpu features will be
> passed through, but I can't seem to get a VM with "vmx" (for testing of ESX or
> Hyper-V in a Xen domU) working. "nestedhvm=1" seems just to be ignored...
> 
> Is this AMD-only in 4.1? Are additional CPU host features required to make this
> work (like EPT, which I do have on this Xeon 5520 box or "Shared EPT" that I
> dont have but could be AMD related anyway)? Do I need unstable to make use of it?

I can't see any support for nested HVM of any sort in 4.1. AFAIK it is
going to be an (experimental) feature in 4.2.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:44:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo6L-0006iP-Ub; Mon, 16 Apr 2012 15:44:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJo6K-0006iC-8B
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:44:24 +0000
Received: from [85.158.143.99:42464] by server-3.bemta-4.messagelabs.com id
	6C/77-05853-75E3C8F4; Mon, 16 Apr 2012 15:44:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334591062!23546833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3173 invoked from network); 16 Apr 2012 15:44:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11959703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:44:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 16:44:22 +0100
Message-ID: <1334591061.14560.213.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 16:44:21 +0100
In-Reply-To: <loom.20120416T171925-109@post.gmane.org>
References: <loom.20120416T171925-109@post.gmane.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:27 +0100, Christian Tramnitz wrote:
> May I ask what the current nestedhvm status in Xen 4.1 is? The parameter exists,
> the documentation just says that only previously existent cpu features will be
> passed through, but I can't seem to get a VM with "vmx" (for testing of ESX or
> Hyper-V in a Xen domU) working. "nestedhvm=1" seems just to be ignored...
> 
> Is this AMD-only in 4.1? Are additional CPU host features required to make this
> work (like EPT, which I do have on this Xeon 5520 box or "Shared EPT" that I
> dont have but could be AMD related anyway)? Do I need unstable to make use of it?

I can't see any support for nested HVM of any sort in 4.1. AFAIK it is
going to be an (experimental) feature in 4.2.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:46:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo8e-0006x4-Fu; Mon, 16 Apr 2012 15:46:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SJo8d-0006wp-4d
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:46:47 +0000
Received: from [193.109.254.147:2213] by server-10.bemta-14.messagelabs.com id
	21/B5-05847-6EE3C8F4; Mon, 16 Apr 2012 15:46:46 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334591190!4856930!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21560 invoked from network); 16 Apr 2012 15:46:31 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:46:31 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C6DCB542FD; Mon, 16 Apr 2012 17:46:29 +0200 (CEST)
Date: Mon, 16 Apr 2012 17:46:29 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120416154629.GB6338@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="wq9mPyueHGvFACwf"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [PATCH] Don't use a4wide in latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

a4wide is not longer shipped in texlive. Just don't use it.

Bastian

-- 
Men will always be men -- no matter where they are.
		-- Harry Mudd, "Mudd's Women", stardate 1329.8

--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename=diff

diff --git a/docs/xen-api/xenapi.tex b/docs/xen-api/xenapi.tex
--- a/docs/xen-api/xenapi.tex
+++ b/docs/xen-api/xenapi.tex
@@ -13,7 +13,6 @@
 
 \documentclass{report}
 
-\usepackage{a4wide}
 \usepackage{graphics}
 \usepackage{longtable}
 \usepackage{fancyhdr}

--wq9mPyueHGvFACwf
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--wq9mPyueHGvFACwf--


From xen-devel-bounces@lists.xen.org Mon Apr 16 15:46:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJo8e-0006x4-Fu; Mon, 16 Apr 2012 15:46:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SJo8d-0006wp-4d
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:46:47 +0000
Received: from [193.109.254.147:2213] by server-10.bemta-14.messagelabs.com id
	21/B5-05847-6EE3C8F4; Mon, 16 Apr 2012 15:46:46 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334591190!4856930!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21560 invoked from network); 16 Apr 2012 15:46:31 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:46:31 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C6DCB542FD; Mon, 16 Apr 2012 17:46:29 +0200 (CEST)
Date: Mon, 16 Apr 2012 17:46:29 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120416154629.GB6338@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="wq9mPyueHGvFACwf"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [PATCH] Don't use a4wide in latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

a4wide is not longer shipped in texlive. Just don't use it.

Bastian

-- 
Men will always be men -- no matter where they are.
		-- Harry Mudd, "Mudd's Women", stardate 1329.8

--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename=diff

diff --git a/docs/xen-api/xenapi.tex b/docs/xen-api/xenapi.tex
--- a/docs/xen-api/xenapi.tex
+++ b/docs/xen-api/xenapi.tex
@@ -13,7 +13,6 @@
 
 \documentclass{report}
 
-\usepackage{a4wide}
 \usepackage{graphics}
 \usepackage{longtable}
 \usepackage{fancyhdr}

--wq9mPyueHGvFACwf
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--wq9mPyueHGvFACwf--


From xen-devel-bounces@lists.xen.org Mon Apr 16 15:50:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoCS-0007BO-S3; Mon, 16 Apr 2012 15:50:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJoCR-0007BF-Vl
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:50:44 +0000
Received: from [193.109.254.147:17334] by server-12.bemta-14.messagelabs.com
	id EB/4B-05898-3DF3C8F4; Mon, 16 Apr 2012 15:50:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334591442!4841119!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28592 invoked from network); 16 Apr 2012 15:50:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:50:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11959903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:50:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 16:50:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJoCQ-0003G4-5E; Mon, 16 Apr 2012 15:50:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJoCQ-0004mZ-0E;
	Mon, 16 Apr 2012 16:50:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20364.16337.971144.457146@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 16:50:41 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> libxl: add a dummy ao_how to libxl_domain_core_dump
> 
> Although this function is not currently slow it may become so in the future
> (this also depends somewhat on the size of the guest).  Therefore arrange for
> it to take an ao_how which it completes immediately.  This will allow us to
> make it asynchronous in the future without breaking API compatibility.
...
>      ret = xc_domain_dumpcore(ctx->xch, domid, filename);
>      if (ret<0) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
>                       domid, filename);
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL;

While you're doing that, did you want to change it to use "goto out" ?

>      }
> -    return 0;
> +
> +    libxl__ao_complete(egc, ao, rc);
> +
> +    return AO_INPROGRESS;

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:50:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoCS-0007BO-S3; Mon, 16 Apr 2012 15:50:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJoCR-0007BF-Vl
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:50:44 +0000
Received: from [193.109.254.147:17334] by server-12.bemta-14.messagelabs.com
	id EB/4B-05898-3DF3C8F4; Mon, 16 Apr 2012 15:50:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334591442!4841119!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28592 invoked from network); 16 Apr 2012 15:50:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:50:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11959903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:50:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 16:50:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJoCQ-0003G4-5E; Mon, 16 Apr 2012 15:50:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJoCQ-0004mZ-0E;
	Mon, 16 Apr 2012 16:50:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20364.16337.971144.457146@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 16:50:41 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> libxl: add a dummy ao_how to libxl_domain_core_dump
> 
> Although this function is not currently slow it may become so in the future
> (this also depends somewhat on the size of the guest).  Therefore arrange for
> it to take an ao_how which it completes immediately.  This will allow us to
> make it asynchronous in the future without breaking API compatibility.
...
>      ret = xc_domain_dumpcore(ctx->xch, domid, filename);
>      if (ret<0) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
>                       domid, filename);
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL;

While you're doing that, did you want to change it to use "goto out" ?

>      }
> -    return 0;
> +
> +    libxl__ao_complete(egc, ao, rc);
> +
> +    return AO_INPROGRESS;

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:51:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:51:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoDB-0007JF-AK; Mon, 16 Apr 2012 15:51:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJoD9-0007J2-SR
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:51:27 +0000
Received: from [85.158.138.51:46560] by server-11.bemta-3.messagelabs.com id
	CD/D5-18894-FFF3C8F4; Mon, 16 Apr 2012 15:51:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334591486!11371511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4055 invoked from network); 16 Apr 2012 15:51:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:51:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11959919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:51:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 16:51:26 +0100
Message-ID: <1334591484.14560.219.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 16 Apr 2012 16:51:24 +0100
In-Reply-To: <20120416154210.GA6338@wavehammer.waldi.eu.org>
References: <20120416154210.GA6338@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:42 +0100, Bastian Blank wrote:
> The xenstore header xs.h is producing conflicts with other software[1].
> 
> xs is a too short identifier and does not matche the library. Renaming
> the headers to xenstore.h and xenstore_lib.h is the easiest way to make
> them easy recognizable and prevent furthe problems.

Thanks Bastian.

This needs a Signed-off-by from you, per the DCO at
http://wiki.xen.org/wiki/SubmittingXenPatches

For my part:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I can't see a good way to do this in a compatible manner for out of tree
users[0], so I think if we are going to make this change then we should
make a freeze exception and do it in 4.2 (i.e. rip the plaster off
quickly rather than have distros solve this their own way while waiting
for 4.3).

Ian.

[0] apart perhaps from having /usr/include/xen-compat/xs.h and
suggesting that people can use -I/usr/include/xen-compat as a bandaid,
but at that point they may as well just sed their code, since they may
need to support 4.1 anyhow.

Ian.
> Bastian
> 
> [1]: http://bugs.debian.org/668550



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:51:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:51:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoDB-0007JF-AK; Mon, 16 Apr 2012 15:51:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJoD9-0007J2-SR
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:51:27 +0000
Received: from [85.158.138.51:46560] by server-11.bemta-3.messagelabs.com id
	CD/D5-18894-FFF3C8F4; Mon, 16 Apr 2012 15:51:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334591486!11371511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4055 invoked from network); 16 Apr 2012 15:51:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:51:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11959919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:51:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 16:51:26 +0100
Message-ID: <1334591484.14560.219.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 16 Apr 2012 16:51:24 +0100
In-Reply-To: <20120416154210.GA6338@wavehammer.waldi.eu.org>
References: <20120416154210.GA6338@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:42 +0100, Bastian Blank wrote:
> The xenstore header xs.h is producing conflicts with other software[1].
> 
> xs is a too short identifier and does not matche the library. Renaming
> the headers to xenstore.h and xenstore_lib.h is the easiest way to make
> them easy recognizable and prevent furthe problems.

Thanks Bastian.

This needs a Signed-off-by from you, per the DCO at
http://wiki.xen.org/wiki/SubmittingXenPatches

For my part:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I can't see a good way to do this in a compatible manner for out of tree
users[0], so I think if we are going to make this change then we should
make a freeze exception and do it in 4.2 (i.e. rip the plaster off
quickly rather than have distros solve this their own way while waiting
for 4.3).

Ian.

[0] apart perhaps from having /usr/include/xen-compat/xs.h and
suggesting that people can use -I/usr/include/xen-compat as a bandaid,
but at that point they may as well just sed their code, since they may
need to support 4.1 anyhow.

Ian.
> Bastian
> 
> [1]: http://bugs.debian.org/668550



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:57:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoIO-0007iD-4b; Mon, 16 Apr 2012 15:56:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJoIN-0007i8-1o
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:56:51 +0000
Received: from [85.158.139.83:42036] by server-5.bemta-5.messagelabs.com id
	4B/D5-13566-2414C8F4; Mon, 16 Apr 2012 15:56:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334591809!20170578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23084 invoked from network); 16 Apr 2012 15:56:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11960041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:56:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 16:56:49 +0100
Message-ID: <1334591807.14560.220.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 16:56:47 +0100
In-Reply-To: <20364.16337.971144.457146@mariner.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:50 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > libxl: add a dummy ao_how to libxl_domain_core_dump
> > 
> > Although this function is not currently slow it may become so in the future
> > (this also depends somewhat on the size of the guest).  Therefore arrange for
> > it to take an ao_how which it completes immediately.  This will allow us to
> > make it asynchronous in the future without breaking API compatibility.
> ...
> >      ret = xc_domain_dumpcore(ctx->xch, domid, filename);
> >      if (ret<0) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
> >                       domid, filename);
> > -        return ERROR_FAIL;
> > +        rc = ERROR_FAIL;
> 
> While you're doing that, did you want to change it to use "goto out" ?

wouldn't the "out:" be immediately after this immediately following
closing brace?

> >      }
> > -    return 0;
> > +
> > +    libxl__ao_complete(egc, ao, rc);
> > +
> > +    return AO_INPROGRESS;
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 15:57:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 15:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoIO-0007iD-4b; Mon, 16 Apr 2012 15:56:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJoIN-0007i8-1o
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 15:56:51 +0000
Received: from [85.158.139.83:42036] by server-5.bemta-5.messagelabs.com id
	4B/D5-13566-2414C8F4; Mon, 16 Apr 2012 15:56:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334591809!20170578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23084 invoked from network); 16 Apr 2012 15:56:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 15:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="11960041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 15:56:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 16:56:49 +0100
Message-ID: <1334591807.14560.220.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 16:56:47 +0100
In-Reply-To: <20364.16337.971144.457146@mariner.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:50 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > libxl: add a dummy ao_how to libxl_domain_core_dump
> > 
> > Although this function is not currently slow it may become so in the future
> > (this also depends somewhat on the size of the guest).  Therefore arrange for
> > it to take an ao_how which it completes immediately.  This will allow us to
> > make it asynchronous in the future without breaking API compatibility.
> ...
> >      ret = xc_domain_dumpcore(ctx->xch, domid, filename);
> >      if (ret<0) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
> >                       domid, filename);
> > -        return ERROR_FAIL;
> > +        rc = ERROR_FAIL;
> 
> While you're doing that, did you want to change it to use "goto out" ?

wouldn't the "out:" be immediately after this immediately following
closing brace?

> >      }
> > -    return 0;
> > +
> > +    libxl__ao_complete(egc, ao, rc);
> > +
> > +    return AO_INPROGRESS;
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:03:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoOs-0008Kh-V6; Mon, 16 Apr 2012 16:03:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJoCB-0007AO-OW
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:50:27 +0000
Received: from [85.158.143.35:32811] by server-1.bemta-4.messagelabs.com id
	37/9C-20925-3CF3C8F4; Mon, 16 Apr 2012 15:50:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334591424!11237184!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21396 invoked from network); 16 Apr 2012 15:50:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:50:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GFnaU1015067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 15:49:37 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GFnVt6028639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 15:49:32 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GFnRDm014800; Mon, 16 Apr 2012 10:49:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 08:49:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7BEFC4027C; Mon, 16 Apr 2012 11:44:29 -0400 (EDT)
Date: Mon, 16 Apr 2012 11:44:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20120416154429.GB4654@phenom.dumpdata.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120331040745.GC14030@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8C3F95.00E5,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Mon, 16 Apr 2012 16:03:34 +0000
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
> * Thomas Gleixner <tglx@linutronix.de> [2012-03-31 00:07:58]:
> 
> > I know that Peter is going to go berserk on me, but if we are running
> > a paravirt guest then it's simple to provide a mechanism which allows
> > the host (aka hypervisor) to check that in the guest just by looking
> > at some global state.
> > 
> > So if a guest exits due to an external event it's easy to inspect the
> > state of that guest and avoid to schedule away when it was interrupted
> > in a spinlock held section. That guest/host shared state needs to be
> > modified to indicate the guest to invoke an exit when the last nested
> > lock has been released.
> 
> I had attempted something like that long back:
> 
> http://lkml.org/lkml/2010/6/3/4
> 
> The issue is with ticketlocks though. VCPUs could go into a spin w/o
> a lock being held by anybody. Say VCPUs 1-99 try to grab a lock in
> that order (on a host with one cpu). VCPU1 wins (after VCPU0 releases it)
> and releases the lock. VCPU1 is next eligible to take the lock. If 
> that is not scheduled early enough by host, then remaining vcpus would keep 
> spinning (even though lock is technically not held by anybody) w/o making 
> forward progress.
> 
> In that situation, what we really need is for the guest to hint to host
> scheduler to schedule VCPU1 early (via yield_to or something similar). 
> 
> The current pv-spinlock patches however does not track which vcpu is
> spinning at what head of the ticketlock. I suppose we can consider 
> that optimization in future and see how much benefit it provides (over
> plain yield/sleep the way its done now).

Right. I think Jeremy played around with this some time?
> 
> Do you see any issues if we take in what we have today and address the
> finer-grained optimization as next step?

I think that is the proper course - these patches show
that on baremetal we don't incur performance regressions and in
virtualization case we benefit greatly. Since these are the basic
building blocks of a kernel - taking it slow and just adding
this set of patches for v3.5 is a good idea - and then building on top
of that for further refinement.

> 
> - vatsa 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:03:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoOs-0008Kh-V6; Mon, 16 Apr 2012 16:03:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJoCB-0007AO-OW
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 15:50:27 +0000
Received: from [85.158.143.35:32811] by server-1.bemta-4.messagelabs.com id
	37/9C-20925-3CF3C8F4; Mon, 16 Apr 2012 15:50:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334591424!11237184!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21396 invoked from network); 16 Apr 2012 15:50:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 15:50:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GFnaU1015067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 15:49:37 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GFnVt6028639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 15:49:32 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GFnRDm014800; Mon, 16 Apr 2012 10:49:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 08:49:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7BEFC4027C; Mon, 16 Apr 2012 11:44:29 -0400 (EDT)
Date: Mon, 16 Apr 2012 11:44:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20120416154429.GB4654@phenom.dumpdata.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120331040745.GC14030@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8C3F95.00E5,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Mon, 16 Apr 2012 16:03:34 +0000
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
> * Thomas Gleixner <tglx@linutronix.de> [2012-03-31 00:07:58]:
> 
> > I know that Peter is going to go berserk on me, but if we are running
> > a paravirt guest then it's simple to provide a mechanism which allows
> > the host (aka hypervisor) to check that in the guest just by looking
> > at some global state.
> > 
> > So if a guest exits due to an external event it's easy to inspect the
> > state of that guest and avoid to schedule away when it was interrupted
> > in a spinlock held section. That guest/host shared state needs to be
> > modified to indicate the guest to invoke an exit when the last nested
> > lock has been released.
> 
> I had attempted something like that long back:
> 
> http://lkml.org/lkml/2010/6/3/4
> 
> The issue is with ticketlocks though. VCPUs could go into a spin w/o
> a lock being held by anybody. Say VCPUs 1-99 try to grab a lock in
> that order (on a host with one cpu). VCPU1 wins (after VCPU0 releases it)
> and releases the lock. VCPU1 is next eligible to take the lock. If 
> that is not scheduled early enough by host, then remaining vcpus would keep 
> spinning (even though lock is technically not held by anybody) w/o making 
> forward progress.
> 
> In that situation, what we really need is for the guest to hint to host
> scheduler to schedule VCPU1 early (via yield_to or something similar). 
> 
> The current pv-spinlock patches however does not track which vcpu is
> spinning at what head of the ticketlock. I suppose we can consider 
> that optimization in future and see how much benefit it provides (over
> plain yield/sleep the way its done now).

Right. I think Jeremy played around with this some time?
> 
> Do you see any issues if we take in what we have today and address the
> finer-grained optimization as next step?

I think that is the proper course - these patches show
that on baremetal we don't incur performance regressions and in
virtualization case we benefit greatly. Since these are the basic
building blocks of a kernel - taking it slow and just adding
this set of patches for v3.5 is a good idea - and then building on top
of that for further refinement.

> 
> - vatsa 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:04:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoPp-0008OI-DW; Mon, 16 Apr 2012 16:04:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJoPn-0008O9-Tr
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:04:32 +0000
Received: from [193.109.254.147:26273] by server-10.bemta-14.messagelabs.com
	id 7F/03-05847-F034C8F4; Mon, 16 Apr 2012 16:04:31 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334592266!4837353!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1113 invoked from network); 16 Apr 2012 16:04:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:04:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190541979"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 12:00:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:00:57 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJoML-00025B-9Y;
	Mon, 16 Apr 2012 17:00:57 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 17:00:52 +0100
Message-ID: <1334592052-7995-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: make libxl_device_{vkb,
	vfb}_add take a dummy ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a dummy ao parameter to both functions, since they may become slow in the
future.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---

Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used"

 tools/libxl/libxl.c        |   20 ++++++++++++--------
 tools/libxl/libxl.h        |    6 ++++--
 tools/libxl/libxl_create.c |    6 +++---
 tools/libxl/libxl_dm.c     |    4 ++--
 4 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 44a54cb..3fd8d5b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2208,9 +2208,10 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
+int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -2255,8 +2256,9 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    /* Dummy ao */
+    libxl__ao_complete(egc, ao, rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
@@ -2339,9 +2341,10 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
+int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -2399,8 +2402,9 @@ out_free:
     flexarray_free(front);
     flexarray_free(back);
 out:
-    GC_FREE;
-    return rc;
+    /* Dummy ao */
+    libxl__ao_complete(egc, ao, rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6da6107..ce89b31 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -563,14 +563,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
                             const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a1f5731..39e9257 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
-        libxl_device_vkb_add(ctx, domid, &vkb);
+        libxl_device_vkb_add(ctx, domid, &vkb, 0);
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
@@ -646,8 +646,8 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console console;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
-            libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
-            libxl_device_vkb_add(ctx, domid, &d_config->vkbs[i]);
+            libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i], 0);
+            libxl_device_vkb_add(ctx, domid, &d_config->vkbs[i], 0);
         }
 
         ret = init_console_info(&console, 0);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8dc588d..4a2b5c1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -804,10 +804,10 @@ retry_transaction:
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0], 0);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0], 0);
     if (ret)
         goto out_free;
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:04:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoPp-0008OI-DW; Mon, 16 Apr 2012 16:04:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJoPn-0008O9-Tr
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:04:32 +0000
Received: from [193.109.254.147:26273] by server-10.bemta-14.messagelabs.com
	id 7F/03-05847-F034C8F4; Mon, 16 Apr 2012 16:04:31 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334592266!4837353!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1113 invoked from network); 16 Apr 2012 16:04:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:04:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208";a="190541979"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 12:00:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 12:00:57 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJoML-00025B-9Y;
	Mon, 16 Apr 2012 17:00:57 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 17:00:52 +0100
Message-ID: <1334592052-7995-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: make libxl_device_{vkb,
	vfb}_add take a dummy ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a dummy ao parameter to both functions, since they may become slow in the
future.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---

Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used"

 tools/libxl/libxl.c        |   20 ++++++++++++--------
 tools/libxl/libxl.h        |    6 ++++--
 tools/libxl/libxl_create.c |    6 +++---
 tools/libxl/libxl_dm.c     |    4 ++--
 4 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 44a54cb..3fd8d5b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2208,9 +2208,10 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
+int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -2255,8 +2256,9 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    /* Dummy ao */
+    libxl__ao_complete(egc, ao, rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
@@ -2339,9 +2341,10 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
+int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -2399,8 +2402,9 @@ out_free:
     flexarray_free(front);
     flexarray_free(back);
 out:
-    GC_FREE;
-    return rc;
+    /* Dummy ao */
+    libxl__ao_complete(egc, ao, rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6da6107..ce89b31 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -563,14 +563,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
                             const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a1f5731..39e9257 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
-        libxl_device_vkb_add(ctx, domid, &vkb);
+        libxl_device_vkb_add(ctx, domid, &vkb, 0);
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
@@ -646,8 +646,8 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console console;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
-            libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
-            libxl_device_vkb_add(ctx, domid, &d_config->vkbs[i]);
+            libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i], 0);
+            libxl_device_vkb_add(ctx, domid, &d_config->vkbs[i], 0);
         }
 
         ret = init_console_info(&console, 0);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8dc588d..4a2b5c1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -804,10 +804,10 @@ retry_transaction:
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0], 0);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0], 0);
     if (ret)
         goto out_free;
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:06:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoRP-00008g-2S; Mon, 16 Apr 2012 16:06:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJoRN-00008M-Ut
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:06:10 +0000
Received: from [193.109.254.147:32306] by server-11.bemta-14.messagelabs.com
	id 3E/8E-05858-1734C8F4; Mon, 16 Apr 2012 16:06:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334592362!4858256!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10641 invoked from network); 16 Apr 2012 16:06:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 16:06:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GG5muM005926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 16:05:49 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GG5lbg021517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 16:05:47 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GG5kxL002999; Mon, 16 Apr 2012 11:05:46 -0500
MIME-Version: 1.0
Message-ID: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Date: Mon, 16 Apr 2012 09:05:32 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
In-Reply-To: <4F8C33E0.2080007@citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F8C435E.0078,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: David Vrabel [mailto:david.vrabel@citrix.com]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable

Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

(Apologies for missing the original post... our Oracle mail server
has gone bonkers again... classifying nearly all (but not all) xen-devel
email as spam.  This problem started when xen.org moved to a different
ISP last year, was supposedly fixed by Oracle IT, and has just
started being a problem again. Argh!)
 
> On 16/04/12 12:32, Jan Beulich wrote:
> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The sched clock was considered stable based on the capabilities of the
> >> underlying hardware.  This does not make sense for Xen PV guests as:
> >> a) the hardware TSC is not used directly as the clock source; and b)
> >> guests may migrate to hosts with different hardware capabilities.
> >>
> >> It is not clear to me whether the Xen clock source is supposed to be
> >> stable and whether it should be stable across migration.  For a clock
> >> source to be stable it must be: a) monotonic; c) synchronized across
> >> CPUs; and c) constant rate.
> 
> Tim, Thomas, can you comment on the above paragraph?  Is it correct?

(Sigh... I keep seeing clock-related things, wish I had more time
to spend on them, cursing, and going back to other things.  But,
I need to comment further here...)

Hmmm... I spent a great deal of time on TSC support in the hypervisor
2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
everything on HVM as well.  There's most likely a bug or two still lurking
but, for all guests, with the default tsc_mode, TSC is provided by Xen
as an absolutely stable clock source.  If Xen determines that the underlying
hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
save/restore, TSC is always emulated.  The result is (ignoring possible
bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
CPUs; and c) constant rate.  Even across migration/save/restore.

This should be true for Xen 4.0+ (but not for pre-Xen-4.0).

Please see docs/misc/tscmode.txt in the xen tree.  Though
it may appear at first to be targeted at a different audience,
all the relevant info is in there if you read it all the way through.

(If you have any questions or disagreements on that doc, please start
a new thread and cc me directly since my list access is unreliable.)
 
> >> There have also been reports of systems with apparently unstable
> >> clocks where clearing sched_clock_stable has fixed problems with
> >> migrated VMs hanging.
> >>
> >> So, always set the sched clock as unstable when using the Xen clock
> >> source.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  arch/x86/xen/time.c |    1 +
> >>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> >> index 0296a95..8469b5a 100644
> >> --- a/arch/x86/xen/time.c
> >> +++ b/arch/x86/xen/time.c
> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> >>  	do_settimeofday(&tp);
> >>
> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> >> +	sched_clock_stable = 0;
> >
> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> > post-boot, the variable may need to be cleared again. Instead you
> > ought to call mark_tsc_unstable().
> 
> Yeah, mark_tsc_unstable() is the right thing to do.

NACK!

No, no, no.  The exact opposite is true.  Like VMware, TSC is
stable.  The issue is that Linux trusts other clock hardware more
completely than TSC so whenever there is a problem with another
clocksource, Linux blames TSC and marks TSC unstable.  But TSC
on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
choice than clocksource=xen (aka pvclock) because pvclock
indirectly depends on TSC.

For upstream kernels, the answer is to set clocksource=tsc
and tsc=reliable, like VMware enforces. See:

https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html 

In fact, it might be wise for a Xen-savvy kernel to check to see
if it is running on Xen-4.0+ and, if so, force clocksource=tsc
and tsc=reliable.

There have been very odd rare problems reported in Xen time
handling for a very long time.  These usually manifest as some
kind of "TSC is not stable" message from a guest Linux kernel,
but the symptoms always point away from TSC as the culprit.
Forcing Xen-savvy guests to use TSC will either make these problems
go away (if they haven't already been fixed) or allow us to find
the obscure underlying hypervisor bugs rather than paper over them.

Thanks,
Dan

P.S.  For anyone new to this areas, see VMware's classic document: http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf 

P.P.S. note this recent kernel issue which is related, but
likely not seen in Xen... it pre-requires cpu overcommitment
at boot time when TSC is being calibrated by the kernel.

https://lkml.org/lkml/2012/2/21/518

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:06:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoRP-00008g-2S; Mon, 16 Apr 2012 16:06:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJoRN-00008M-Ut
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:06:10 +0000
Received: from [193.109.254.147:32306] by server-11.bemta-14.messagelabs.com
	id 3E/8E-05858-1734C8F4; Mon, 16 Apr 2012 16:06:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334592362!4858256!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10641 invoked from network); 16 Apr 2012 16:06:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 16:06:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GG5muM005926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 16:05:49 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GG5lbg021517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 16:05:47 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GG5kxL002999; Mon, 16 Apr 2012 11:05:46 -0500
MIME-Version: 1.0
Message-ID: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Date: Mon, 16 Apr 2012 09:05:32 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
In-Reply-To: <4F8C33E0.2080007@citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F8C435E.0078,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: David Vrabel [mailto:david.vrabel@citrix.com]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable

Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

(Apologies for missing the original post... our Oracle mail server
has gone bonkers again... classifying nearly all (but not all) xen-devel
email as spam.  This problem started when xen.org moved to a different
ISP last year, was supposedly fixed by Oracle IT, and has just
started being a problem again. Argh!)
 
> On 16/04/12 12:32, Jan Beulich wrote:
> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The sched clock was considered stable based on the capabilities of the
> >> underlying hardware.  This does not make sense for Xen PV guests as:
> >> a) the hardware TSC is not used directly as the clock source; and b)
> >> guests may migrate to hosts with different hardware capabilities.
> >>
> >> It is not clear to me whether the Xen clock source is supposed to be
> >> stable and whether it should be stable across migration.  For a clock
> >> source to be stable it must be: a) monotonic; c) synchronized across
> >> CPUs; and c) constant rate.
> 
> Tim, Thomas, can you comment on the above paragraph?  Is it correct?

(Sigh... I keep seeing clock-related things, wish I had more time
to spend on them, cursing, and going back to other things.  But,
I need to comment further here...)

Hmmm... I spent a great deal of time on TSC support in the hypervisor
2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
everything on HVM as well.  There's most likely a bug or two still lurking
but, for all guests, with the default tsc_mode, TSC is provided by Xen
as an absolutely stable clock source.  If Xen determines that the underlying
hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
save/restore, TSC is always emulated.  The result is (ignoring possible
bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
CPUs; and c) constant rate.  Even across migration/save/restore.

This should be true for Xen 4.0+ (but not for pre-Xen-4.0).

Please see docs/misc/tscmode.txt in the xen tree.  Though
it may appear at first to be targeted at a different audience,
all the relevant info is in there if you read it all the way through.

(If you have any questions or disagreements on that doc, please start
a new thread and cc me directly since my list access is unreliable.)
 
> >> There have also been reports of systems with apparently unstable
> >> clocks where clearing sched_clock_stable has fixed problems with
> >> migrated VMs hanging.
> >>
> >> So, always set the sched clock as unstable when using the Xen clock
> >> source.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> ---
> >>  arch/x86/xen/time.c |    1 +
> >>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> >> index 0296a95..8469b5a 100644
> >> --- a/arch/x86/xen/time.c
> >> +++ b/arch/x86/xen/time.c
> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> >>  	do_settimeofday(&tp);
> >>
> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> >> +	sched_clock_stable = 0;
> >
> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> > post-boot, the variable may need to be cleared again. Instead you
> > ought to call mark_tsc_unstable().
> 
> Yeah, mark_tsc_unstable() is the right thing to do.

NACK!

No, no, no.  The exact opposite is true.  Like VMware, TSC is
stable.  The issue is that Linux trusts other clock hardware more
completely than TSC so whenever there is a problem with another
clocksource, Linux blames TSC and marks TSC unstable.  But TSC
on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
choice than clocksource=xen (aka pvclock) because pvclock
indirectly depends on TSC.

For upstream kernels, the answer is to set clocksource=tsc
and tsc=reliable, like VMware enforces. See:

https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html 

In fact, it might be wise for a Xen-savvy kernel to check to see
if it is running on Xen-4.0+ and, if so, force clocksource=tsc
and tsc=reliable.

There have been very odd rare problems reported in Xen time
handling for a very long time.  These usually manifest as some
kind of "TSC is not stable" message from a guest Linux kernel,
but the symptoms always point away from TSC as the culprit.
Forcing Xen-savvy guests to use TSC will either make these problems
go away (if they haven't already been fixed) or allow us to find
the obscure underlying hypervisor bugs rather than paper over them.

Thanks,
Dan

P.S.  For anyone new to this areas, see VMware's classic document: http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf 

P.P.S. note this recent kernel issue which is related, but
likely not seen in Xen... it pre-requires cpu overcommitment
at boot time when TSC is being calibrated by the kernel.

https://lkml.org/lkml/2012/2/21/518

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoZw-0000Vq-2o; Mon, 16 Apr 2012 16:15:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SJoZv-0000Vl-3h
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:14:59 +0000
Received: from [85.158.143.35:4588] by server-2.bemta-4.messagelabs.com id
	97/B3-17550-1854C8F4; Mon, 16 Apr 2012 16:14:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334592895!7319374!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31698 invoked from network); 16 Apr 2012 16:14:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 16:14:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Apr 2012 17:14:55 +0100
Message-Id: <4F8C619C020000780007E34E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Apr 2012 17:14:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
In-Reply-To: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.04.12 at 18:05, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: David Vrabel [mailto:david.vrabel@citrix.com]
>> On 16/04/12 12:32, Jan Beulich wrote:
>> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
>> >> --- a/arch/x86/xen/time.c
>> >> +++ b/arch/x86/xen/time.c
>> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>> >>  	do_settimeofday(&tp);
>> >>
>> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
>> >> +	sched_clock_stable = 0;
>> >
>> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
>> > post-boot, the variable may need to be cleared again. Instead you
>> > ought to call mark_tsc_unstable().
>> 
>> Yeah, mark_tsc_unstable() is the right thing to do.
> 
> NACK!
> 
> No, no, no.  The exact opposite is true.  Like VMware, TSC is
> stable.  The issue is that Linux trusts other clock hardware more
> completely than TSC so whenever there is a problem with another
> clocksource, Linux blames TSC and marks TSC unstable.  But TSC
> on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
> choice than clocksource=xen (aka pvclock) because pvclock
> indirectly depends on TSC.
> 
> For upstream kernels, the answer is to set clocksource=tsc
> and tsc=reliable, like VMware enforces. See:
> 
> https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html 
> 
> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

Are you possibly mixing up PV and HVM cases? sched_clock_stable
getting set _is_ a problem in PV kernels - we had bug reports long
ago when this first appeared in arch/x86/kernel/cpu/intel.c. I'm
suspecting this because there's not supposed to be (and in non-
pv-ops there is no; in pv-ops I assume it simply has no effect)
clocksource=tsc in PV kernels.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoZw-0000Vq-2o; Mon, 16 Apr 2012 16:15:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SJoZv-0000Vl-3h
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:14:59 +0000
Received: from [85.158.143.35:4588] by server-2.bemta-4.messagelabs.com id
	97/B3-17550-1854C8F4; Mon, 16 Apr 2012 16:14:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334592895!7319374!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31698 invoked from network); 16 Apr 2012 16:14:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 16:14:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Apr 2012 17:14:55 +0100
Message-Id: <4F8C619C020000780007E34E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Apr 2012 17:14:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
In-Reply-To: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.04.12 at 18:05, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: David Vrabel [mailto:david.vrabel@citrix.com]
>> On 16/04/12 12:32, Jan Beulich wrote:
>> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
>> >> --- a/arch/x86/xen/time.c
>> >> +++ b/arch/x86/xen/time.c
>> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>> >>  	do_settimeofday(&tp);
>> >>
>> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
>> >> +	sched_clock_stable = 0;
>> >
>> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
>> > post-boot, the variable may need to be cleared again. Instead you
>> > ought to call mark_tsc_unstable().
>> 
>> Yeah, mark_tsc_unstable() is the right thing to do.
> 
> NACK!
> 
> No, no, no.  The exact opposite is true.  Like VMware, TSC is
> stable.  The issue is that Linux trusts other clock hardware more
> completely than TSC so whenever there is a problem with another
> clocksource, Linux blames TSC and marks TSC unstable.  But TSC
> on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
> choice than clocksource=xen (aka pvclock) because pvclock
> indirectly depends on TSC.
> 
> For upstream kernels, the answer is to set clocksource=tsc
> and tsc=reliable, like VMware enforces. See:
> 
> https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html 
> 
> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

Are you possibly mixing up PV and HVM cases? sched_clock_stable
getting set _is_ a problem in PV kernels - we had bug reports long
ago when this first appeared in arch/x86/kernel/cpu/intel.c. I'm
suspecting this because there's not supposed to be (and in non-
pv-ops there is no; in pv-ops I assume it simply has no effect)
clocksource=tsc in PV kernels.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoce-0000b7-LW; Mon, 16 Apr 2012 16:17:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJocd-0000av-8Q
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:17:47 +0000
Received: from [85.158.138.51:58419] by server-4.bemta-3.messagelabs.com id
	CC/03-15341-8264C8F4; Mon, 16 Apr 2012 16:17:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334593064!18188448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2433 invoked from network); 16 Apr 2012 16:17:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11960586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:17:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 17:17:43 +0100
Date: Mon, 16 Apr 2012 17:22:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334585643.14560.199.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012, Ian Campbell wrote:
> > In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> > for privcmd without writing a slab allocator.
> 
> Can't you just use the core get_page function (or
> alloc_xenballooned_pages) and move the associated mfn aside temporarily
> (or not if using alloc_xenballooned_pages)?

I think that is a good suggestion: if we are trying to get in something
that works but might not be the best solution, then using
alloc_xenballooned_pages to get some pages and then changing the p2m is
the best option: it wastes a non-trivial amount of memory in dom0 but at
least it is known to work well and it wouldn't be an "hack".

Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
for an example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJoce-0000b7-LW; Mon, 16 Apr 2012 16:17:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJocd-0000av-8Q
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:17:47 +0000
Received: from [85.158.138.51:58419] by server-4.bemta-3.messagelabs.com id
	CC/03-15341-8264C8F4; Mon, 16 Apr 2012 16:17:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334593064!18188448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2433 invoked from network); 16 Apr 2012 16:17:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11960586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:17:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 17:17:43 +0100
Date: Mon, 16 Apr 2012 17:22:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334585643.14560.199.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012, Ian Campbell wrote:
> > In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> > for privcmd without writing a slab allocator.
> 
> Can't you just use the core get_page function (or
> alloc_xenballooned_pages) and move the associated mfn aside temporarily
> (or not if using alloc_xenballooned_pages)?

I think that is a good suggestion: if we are trying to get in something
that works but might not be the best solution, then using
alloc_xenballooned_pages to get some pages and then changing the p2m is
the best option: it wastes a non-trivial amount of memory in dom0 but at
least it is known to work well and it wouldn't be an "hack".

Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
for an example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:21:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:21:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJofn-0000lX-AA; Mon, 16 Apr 2012 16:21:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJofl-0000lP-Fy
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:21:01 +0000
Received: from [85.158.138.51:18403] by server-4.bemta-3.messagelabs.com id
	ED/C9-15341-CE64C8F4; Mon, 16 Apr 2012 16:21:00 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334593258!22376402!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7780 invoked from network); 16 Apr 2012 16:21:00 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 16:21:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GGKaRw024919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 16:20:37 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GGKZiD024261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 16:20:35 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GGKYQV007329; Mon, 16 Apr 2012 11:20:34 -0500
MIME-Version: 1.0
Message-ID: <cab53fa9-398f-4e06-885f-c388a9ea3c29@default>
Date: Mon, 16 Apr 2012 09:20:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<20120416151759.GI1903@phenom.dumpdata.com>
In-Reply-To: <20120416151759.GI1903@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F8C46DE.00A7,ss=1,re=0.000,fgs=0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote:
> > On 16/04/12 12:32, Jan Beulich wrote:
> > >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> > >> From: David Vrabel <david.vrabel@citrix.com>
> > >>
> > >> The sched clock was considered stable based on the capabilities of the
> > >> underlying hardware.  This does not make sense for Xen PV guests as:
> 
> In regards to PV dom0 is this still the case? Asking b/c your
> patch will make dom0 be in the same category.
> 
> > >> a) the hardware TSC is not used directly as the clock source; and b)
> > >> guests may migrate to hosts with different hardware capabilities.
> > >>
> > >> It is not clear to me whether the Xen clock source is supposed to be
> > >> stable and whether it should be stable across migration.  For a clock

Xen is -- and has always been -- responsible for emulating sufficient
clock hardware devices and presenting them to the guest AND ensuring
that this emulation works properly across migration/save/restore (which
is required because these transitions may be completely transparent
to the guest).

Prior to Xen 4.0, TSC was not considered to be a clocksource worthy
of emulating and was passed through to PV guests unchanged (and not
fully handled for HVM either IIRC).  At Xen 4.0+, it is handled properly.
 
> I thought it was dependent on XEN_DOMCTL_settscinfo:
>  - whether it gets emulated, or the guest can do rdtsc or pvrdtsc?
>
> Which I think is determined by some 'timer=X' option in the guest config?

I think you may be thinking of tsc_mode.  See docs/misc/tscmode.txt
in the Xen source.  The default should work correctly.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:21:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:21:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJofn-0000lX-AA; Mon, 16 Apr 2012 16:21:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJofl-0000lP-Fy
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:21:01 +0000
Received: from [85.158.138.51:18403] by server-4.bemta-3.messagelabs.com id
	ED/C9-15341-CE64C8F4; Mon, 16 Apr 2012 16:21:00 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334593258!22376402!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7780 invoked from network); 16 Apr 2012 16:21:00 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 16:21:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GGKaRw024919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 16:20:37 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GGKZiD024261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 16:20:35 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GGKYQV007329; Mon, 16 Apr 2012 11:20:34 -0500
MIME-Version: 1.0
Message-ID: <cab53fa9-398f-4e06-885f-c388a9ea3c29@default>
Date: Mon, 16 Apr 2012 09:20:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<20120416151759.GI1903@phenom.dumpdata.com>
In-Reply-To: <20120416151759.GI1903@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F8C46DE.00A7,ss=1,re=0.000,fgs=0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote:
> > On 16/04/12 12:32, Jan Beulich wrote:
> > >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> > >> From: David Vrabel <david.vrabel@citrix.com>
> > >>
> > >> The sched clock was considered stable based on the capabilities of the
> > >> underlying hardware.  This does not make sense for Xen PV guests as:
> 
> In regards to PV dom0 is this still the case? Asking b/c your
> patch will make dom0 be in the same category.
> 
> > >> a) the hardware TSC is not used directly as the clock source; and b)
> > >> guests may migrate to hosts with different hardware capabilities.
> > >>
> > >> It is not clear to me whether the Xen clock source is supposed to be
> > >> stable and whether it should be stable across migration.  For a clock

Xen is -- and has always been -- responsible for emulating sufficient
clock hardware devices and presenting them to the guest AND ensuring
that this emulation works properly across migration/save/restore (which
is required because these transitions may be completely transparent
to the guest).

Prior to Xen 4.0, TSC was not considered to be a clocksource worthy
of emulating and was passed through to PV guests unchanged (and not
fully handled for HVM either IIRC).  At Xen 4.0+, it is handled properly.
 
> I thought it was dependent on XEN_DOMCTL_settscinfo:
>  - whether it gets emulated, or the guest can do rdtsc or pvrdtsc?
>
> Which I think is determined by some 'timer=X' option in the guest config?

I think you may be thinking of tsc_mode.  See docs/misc/tscmode.txt
in the Xen source.  The default should work correctly.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:22:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:22:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJohL-0000qS-QM; Mon, 16 Apr 2012 16:22:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJohL-0000qK-2x
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:22:39 +0000
Received: from [85.158.138.51:28904] by server-8.bemta-3.messagelabs.com id
	79/B5-24428-E474C8F4; Mon, 16 Apr 2012 16:22:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334593357!22391841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24186 invoked from network); 16 Apr 2012 16:22:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:22:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11960818"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:22:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:22:37 +0100
Message-ID: <1334593355.14560.227.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 16 Apr 2012 17:22:35 +0100
In-Reply-To: <20120416154629.GB6338@wavehammer.waldi.eu.org>
References: <20120416154629.GB6338@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Don't use a4wide in latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:46 +0100, Bastian Blank wrote:
> a4wide is not longer shipped in texlive. Just don't use it.

Needs a signed off by (I guess, although the change is about as trivial
as is possible).

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Do we also want/need:

8<----------------------------------------------

docs: use "a4" not "a4wide" paper type for doxygen

a4wide is no longer shipped in texlive.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a20c43492fbf docs/Doxyfile
--- a/docs/Doxyfile	Mon Apr 16 15:41:43 2012 +0100
+++ b/docs/Doxyfile	Mon Apr 16 17:21:22 2012 +0100
@@ -747,7 +747,7 @@ COMPACT_LATEX          = NO
 # by the printer. Possible values are: a4, a4wide, letter, legal and 
 # executive. If left blank a4wide will be used.
 
-PAPER_TYPE             = a4wide
+PAPER_TYPE             = a4
 
 # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
 # packages that should be included in the LaTeX output.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:22:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:22:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJohL-0000qS-QM; Mon, 16 Apr 2012 16:22:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJohL-0000qK-2x
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:22:39 +0000
Received: from [85.158.138.51:28904] by server-8.bemta-3.messagelabs.com id
	79/B5-24428-E474C8F4; Mon, 16 Apr 2012 16:22:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334593357!22391841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24186 invoked from network); 16 Apr 2012 16:22:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:22:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11960818"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:22:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:22:37 +0100
Message-ID: <1334593355.14560.227.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 16 Apr 2012 17:22:35 +0100
In-Reply-To: <20120416154629.GB6338@wavehammer.waldi.eu.org>
References: <20120416154629.GB6338@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Don't use a4wide in latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:46 +0100, Bastian Blank wrote:
> a4wide is not longer shipped in texlive. Just don't use it.

Needs a signed off by (I guess, although the change is about as trivial
as is possible).

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Do we also want/need:

8<----------------------------------------------

docs: use "a4" not "a4wide" paper type for doxygen

a4wide is no longer shipped in texlive.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a20c43492fbf docs/Doxyfile
--- a/docs/Doxyfile	Mon Apr 16 15:41:43 2012 +0100
+++ b/docs/Doxyfile	Mon Apr 16 17:21:22 2012 +0100
@@ -747,7 +747,7 @@ COMPACT_LATEX          = NO
 # by the printer. Possible values are: a4, a4wide, letter, legal and 
 # executive. If left blank a4wide will be used.
 
-PAPER_TYPE             = a4wide
+PAPER_TYPE             = a4
 
 # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
 # packages that should be included in the LaTeX output.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:26:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:26:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJol3-00012u-Fn; Mon, 16 Apr 2012 16:26:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJol2-00012l-CH
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:26:28 +0000
Received: from [85.158.139.83:47355] by server-9.bemta-5.messagelabs.com id
	BD/65-09826-3384C8F4; Mon, 16 Apr 2012 16:26:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334593586!23518079!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4527 invoked from network); 16 Apr 2012 16:26:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:26:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11960968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:26:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:26:12 +0100
Message-ID: <1334593570.14560.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 16 Apr 2012 17:26:10 +0100
In-Reply-To: <alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 17:22 +0100, Stefano Stabellini wrote:
> On Mon, 16 Apr 2012, Ian Campbell wrote:
> > > In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> > > for privcmd without writing a slab allocator.
> > 
> > Can't you just use the core get_page function (or
> > alloc_xenballooned_pages) and move the associated mfn aside temporarily
> > (or not if using alloc_xenballooned_pages)?
> 
> I think that is a good suggestion: if we are trying to get in something
> that works but might not be the best solution, then using
> alloc_xenballooned_pages to get some pages and then changing the p2m is
> the best option: it wastes a non-trivial amount of memory in dom0 but at
> least it is known to work well and it wouldn't be an "hack".

I don't think it wastes all that much -- even 10k pages is only a few
10s of megabytes for the duration of the build.

Also free_xenballooned_pages does the right thing if
alloc_xenballooned_pages had to explicitly free some pages to satisfy
the allocation. i.e. it will shrink the balloon and re-add those pages
to the allocator, it won't leave them in the balloon or something.

Ian.

> 
> Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
> for an example.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:26:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:26:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJol3-00012u-Fn; Mon, 16 Apr 2012 16:26:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJol2-00012l-CH
	for Xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:26:28 +0000
Received: from [85.158.139.83:47355] by server-9.bemta-5.messagelabs.com id
	BD/65-09826-3384C8F4; Mon, 16 Apr 2012 16:26:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334593586!23518079!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4527 invoked from network); 16 Apr 2012 16:26:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:26:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11960968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:26:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:26:12 +0100
Message-ID: <1334593570.14560.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 16 Apr 2012 17:26:10 +0100
In-Reply-To: <alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 17:22 +0100, Stefano Stabellini wrote:
> On Mon, 16 Apr 2012, Ian Campbell wrote:
> > > In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> > > for privcmd without writing a slab allocator.
> > 
> > Can't you just use the core get_page function (or
> > alloc_xenballooned_pages) and move the associated mfn aside temporarily
> > (or not if using alloc_xenballooned_pages)?
> 
> I think that is a good suggestion: if we are trying to get in something
> that works but might not be the best solution, then using
> alloc_xenballooned_pages to get some pages and then changing the p2m is
> the best option: it wastes a non-trivial amount of memory in dom0 but at
> least it is known to work well and it wouldn't be an "hack".

I don't think it wastes all that much -- even 10k pages is only a few
10s of megabytes for the duration of the build.

Also free_xenballooned_pages does the right thing if
alloc_xenballooned_pages had to explicitly free some pages to satisfy
the allocation. i.e. it will shrink the balloon and re-add those pages
to the allocator, it won't leave them in the balloon or something.

Ian.

> 
> Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
> for an example.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJooG-0001AN-3h; Mon, 16 Apr 2012 16:29:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SJooD-0001AC-Vu
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:29:46 +0000
Received: from [85.158.143.35:2672] by server-2.bemta-4.messagelabs.com id
	2D/F2-17550-9F84C8F4; Mon, 16 Apr 2012 16:29:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334593782!12288329!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30839 invoked from network); 16 Apr 2012 16:29:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:29:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190550051"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 12:26:03 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012
	12:26:03 -0400
Message-ID: <4F8C4818.8070603@citrix.com>
Date: Mon, 16 Apr 2012 17:26:00 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Dan Magenheimer <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
In-Reply-To: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/04/12 17:05, Dan Magenheimer wrote:
>> From: David Vrabel [mailto:david.vrabel@citrix.com]
>> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

Fair enough,

> [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).

The original customer problem is on a host with Xen 3.4.  What do you
recommend for Linux guests running such hosts?

> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

So, should the xen clocksource do:

if Xen 4.0+
    clock is stable, use rdtsc only.
else
    clock is unstable, use existing pvclock implementation.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJooG-0001AN-3h; Mon, 16 Apr 2012 16:29:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SJooD-0001AC-Vu
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:29:46 +0000
Received: from [85.158.143.35:2672] by server-2.bemta-4.messagelabs.com id
	2D/F2-17550-9F84C8F4; Mon, 16 Apr 2012 16:29:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334593782!12288329!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDMyOTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30839 invoked from network); 16 Apr 2012 16:29:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:29:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190550051"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 12:26:03 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012
	12:26:03 -0400
Message-ID: <4F8C4818.8070603@citrix.com>
Date: Mon, 16 Apr 2012 17:26:00 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Dan Magenheimer <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
In-Reply-To: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/04/12 17:05, Dan Magenheimer wrote:
>> From: David Vrabel [mailto:david.vrabel@citrix.com]
>> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

Fair enough,

> [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).

The original customer problem is on a host with Xen 3.4.  What do you
recommend for Linux guests running such hosts?

> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

So, should the xen clocksource do:

if Xen 4.0+
    clock is stable, use rdtsc only.
else
    clock is unstable, use existing pvclock implementation.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:31:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJopr-0001II-ON; Mon, 16 Apr 2012 16:31:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJopq-0001IB-SF
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:31:27 +0000
Received: from [85.158.139.83:16579] by server-5.bemta-5.messagelabs.com id
	50/84-13566-E594C8F4; Mon, 16 Apr 2012 16:31:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334593885!20175496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29357 invoked from network); 16 Apr 2012 16:31:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:31:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:31:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 17:31:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJopg-0003TO-IU; Mon, 16 Apr 2012 16:31:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJopg-0005iL-Hd;
	Mon, 16 Apr 2012 17:31:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20364.18772.529397.220632@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 17:31:16 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334591807.14560.220.camel@zakaz.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> On Mon, 2012-04-16 at 16:50 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > > libxl: add a dummy ao_how to libxl_domain_core_dump
> > > -        return ERROR_FAIL;
> > > +        rc = ERROR_FAIL;
> > 
> > While you're doing that, did you want to change it to use "goto out" ?
> 
> wouldn't the "out:" be immediately after this immediately following
> closing brace?

I think it would look like this:

            
> > > +        rc = ERROR_FAIL;
               goto out;
> > >      }
> > > -    return 0;
> > > +
           rc = 0;
        out:
> > > +    libxl__ao_complete(egc, ao, rc);
> > > +
> > > +    return AO_INPROGRESS;

And removing the initialisation of rc at the top of the function.

This pattern is the usual one when we have an operation which should
fail, and stop executing, when any sub-operations fail.

Setting rc=0 at the top and setting it to ERROR_FAIL as we go, without
an error exit, is what we do if we want to blunder on after errors (eg
the remove files patch).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:31:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJopr-0001II-ON; Mon, 16 Apr 2012 16:31:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJopq-0001IB-SF
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:31:27 +0000
Received: from [85.158.139.83:16579] by server-5.bemta-5.messagelabs.com id
	50/84-13566-E594C8F4; Mon, 16 Apr 2012 16:31:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334593885!20175496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29357 invoked from network); 16 Apr 2012 16:31:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:31:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:31:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 17:31:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJopg-0003TO-IU; Mon, 16 Apr 2012 16:31:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJopg-0005iL-Hd;
	Mon, 16 Apr 2012 17:31:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20364.18772.529397.220632@mariner.uk.xensource.com>
Date: Mon, 16 Apr 2012 17:31:16 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334591807.14560.220.camel@zakaz.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> On Mon, 2012-04-16 at 16:50 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > > libxl: add a dummy ao_how to libxl_domain_core_dump
> > > -        return ERROR_FAIL;
> > > +        rc = ERROR_FAIL;
> > 
> > While you're doing that, did you want to change it to use "goto out" ?
> 
> wouldn't the "out:" be immediately after this immediately following
> closing brace?

I think it would look like this:

            
> > > +        rc = ERROR_FAIL;
               goto out;
> > >      }
> > > -    return 0;
> > > +
           rc = 0;
        out:
> > > +    libxl__ao_complete(egc, ao, rc);
> > > +
> > > +    return AO_INPROGRESS;

And removing the initialisation of rc at the top of the function.

This pattern is the usual one when we have an operation which should
fail, and stop executing, when any sub-operations fail.

Setting rc=0 at the top and setting it to ERROR_FAIL as we go, without
an error exit, is what we do if we want to blunder on after errors (eg
the remove files patch).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:39:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJowy-0001Ww-NN; Mon, 16 Apr 2012 16:38:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJowx-0001Wo-2x
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:38:47 +0000
Received: from [85.158.138.51:10056] by server-9.bemta-3.messagelabs.com id
	F3/FA-26691-61B4C8F4; Mon, 16 Apr 2012 16:38:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334594324!22339010!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12198 invoked from network); 16 Apr 2012 16:38:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 16:38:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GGcfx1012448
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 16:38:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GGceNO003012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 16:38:40 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GGcd23019542; Mon, 16 Apr 2012 11:38:39 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 09:38:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2A1D940280; Mon, 16 Apr 2012 12:33:42 -0400 (EDT)
Date: Mon, 16 Apr 2012 12:33:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416163342.GC9925@phenom.dumpdata.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
	<20120416151045.GH1903@phenom.dumpdata.com>
	<4F8C3D7F.4020703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8C3D7F.4020703@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F8C4B12.0059,ss=1,re=0.000,fgs=0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 04:40:47PM +0100, David Vrabel wrote:
> On 16/04/12 16:10, Konrad Rzeszutek Wilk wrote:
> > 
> > But I think it makes sense to stick this in arch/x86/pci/xen.c - if
> > it is not to late in teh bootup cycle?
> 
> pci_xen_init() is called early enough I think, but is only called for
> domU (not dom0).  I can change this if you prefer.

For dom0 it could be done in: pci_xen_initial_domain ?
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:39:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJowy-0001Ww-NN; Mon, 16 Apr 2012 16:38:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJowx-0001Wo-2x
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:38:47 +0000
Received: from [85.158.138.51:10056] by server-9.bemta-3.messagelabs.com id
	F3/FA-26691-61B4C8F4; Mon, 16 Apr 2012 16:38:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334594324!22339010!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12198 invoked from network); 16 Apr 2012 16:38:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 16:38:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GGcfx1012448
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 16:38:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GGceNO003012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 16:38:40 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GGcd23019542; Mon, 16 Apr 2012 11:38:39 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 09:38:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2A1D940280; Mon, 16 Apr 2012 12:33:42 -0400 (EDT)
Date: Mon, 16 Apr 2012 12:33:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120416163342.GC9925@phenom.dumpdata.com>
References: <1334318915-9083-1-git-send-email-david.vrabel@citrix.com>
	<4F883848020000780007DCD2@nat28.tlf.novell.com>
	<4F88222F.7050703@citrix.com>
	<20120416151045.GH1903@phenom.dumpdata.com>
	<4F8C3D7F.4020703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8C3D7F.4020703@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F8C4B12.0059,ss=1,re=0.000,fgs=0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: don't use PCI BIOS service for
 configuration space accesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 04:40:47PM +0100, David Vrabel wrote:
> On 16/04/12 16:10, Konrad Rzeszutek Wilk wrote:
> > 
> > But I think it makes sense to stick this in arch/x86/pci/xen.c - if
> > it is not to late in teh bootup cycle?
> 
> pci_xen_init() is called early enough I think, but is only called for
> domU (not dom0).  I can change this if you prefer.

For dom0 it could be done in: pci_xen_initial_domain ?
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp2o-0001zL-Sd; Mon, 16 Apr 2012 16:44:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJp2n-0001zD-Nc
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:44:50 +0000
Received: from [193.109.254.147:50769] by server-2.bemta-14.messagelabs.com id
	74/61-19409-18C4C8F4; Mon, 16 Apr 2012 16:44:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334594688!4874097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28896 invoked from network); 16 Apr 2012 16:44:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:44:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:44:47 +0100
Message-ID: <1334594686.14560.242.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 17:44:46 +0100
In-Reply-To: <1334588804-7755-3-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
 for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
> This is a rather big change, that adds the necessary machinery to perform
> hotplug script calling from libxl for Linux. This patch launches the necessary
> scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
> scripts).
> 
> Here's a list of the major changes introduced:
> 
>  * libxl_device_disk_add makes use of the new event library and takes the
>    optional parameter libxl_asyncop_how, to choose how the operation has to be
>    issued (sync or async).
> 
>  * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
>    and then launches the hotplug script.
> 
>  * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
>    calls libxl__initiate_device_remove, so we can disconnect the device and
>    execute the necessary hotplug scripts instead of just deleting the backend
>    entries. So libxl__devices_destroy now uses the event library, and so does
>    libxl_domain_destroy.
> 
>  * Since libxl__devices_destroy calls multiple times
>    libxl__initiate_device_remove, this function now returns a different value
>    regarding the actions taken (if an event was added or not). The user has to
>    call libxl__ao_complete after using this function if necessary.
> 
>  * The internal API for hotplug scripts has been added, which consists of one
>    function; libxl__device_hotplug that takes the device and the action to
>    execute.
> 
>  * Linux hotplug scripts are called by setting the necessary env variables to
>    emulate udev rules, so there's no need to change them (although a rework to
>    pass this as parameters insted of env variables would be suitable, so both
>    NetBSD and Linux hotplug scripts take the same parameters).
> 
>  * Added a check in xen-hotplug-common.sh, so scripts are only executed from
>    udev when using xend. xl adds an execute_udev=n to xenstore device backend
>    and passes XL_CALL=y to the env of the script call, and udev calls check that
>    execute_udev is not set and XL_CALL is empty also.
> 
> I've also modified the python binding for pyxl_domain_destroy, that now take the
> ao_how parameter, but I'm not really sure if it's done correctly, let's just say
> that it compiles.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
>  tools/libxl/Makefile                      |    3 +-
>  tools/libxl/libxl.c                       |  104 ++++++++++++++++++----
>  tools/libxl/libxl.h                       |    7 +-
>  tools/libxl/libxl_create.c                |    4 +-
>  tools/libxl/libxl_device.c                |  140 +++++++++++++++++++++++++++--
>  tools/libxl/libxl_dm.c                    |    4 +-
>  tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++
>  tools/libxl/libxl_internal.h              |   43 +++++++++-
>  tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++++
>  tools/libxl/xl_cmdimpl.c                  |   14 ++--
>  tools/python/xen/lowlevel/xl/xl.c         |    5 +-
>  12 files changed, 474 insertions(+), 40 deletions(-)
>  create mode 100644 tools/libxl/libxl_hotplug.c
> 
> diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
> index 8f6557d..dc3e867 100644
> --- a/tools/hotplug/Linux/xen-hotplug-common.sh
> +++ b/tools/hotplug/Linux/xen-hotplug-common.sh
> @@ -15,6 +15,12 @@
>  # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>  #
> 
> +# Hack to prevent the execution of hotplug scripts form udev if the domain

                                                      from
> +# has ben launched from libxl

        been

> +execute_udev=`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
> +if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
> +    exit 0
> +fi

So, am I right that in some future world where we have got rid of xend
and made this stuff work without udev everywhere (e.g. including driver
domains) there is a path to deprecating this snippet without requiring
everyone to go through some sort of transition?

Or are we stuck with this envvar forever? It's not a big deal but if we
can invert it (e.g. by setting ENV{HOTPLUG_GATE}=${XENBUS}/evecute_udev
in xen-backend.rules and ...if -n "${HOTPLUG_GATE}" && xenstore-read
${HOTPLUG_GATE}... etc) then that would be nicer?

>  dir=$(dirname "$0")
>  . "$dir/hotplugpath.sh"
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 16ebef3..fb4fbf2 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
>      GC_FREE;
>  }
> 
> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
> +                         const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
>      char *dom_path;
>      char *vm_path;
>      char *pid;
>      int rc, dm_present;
> +    int rc_ao = 0;
> 
>      rc = libxl_domain_info(ctx, NULL, domid);
>      switch(rc) {
> @@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
> 
>          libxl__qmp_cleanup(gc, domid);
>      }
> -    if (libxl__devices_destroy(gc, domid) < 0)
> +    rc_ao = libxl__devices_destroy(egc, ao, domid);
> +    if (rc_ao < 0)
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                     "libxl__devices_destroy failed for %d", domid);
> 
> @@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>          goto out;
>      }
>      rc = 0;
> +
>  out:
> -    GC_FREE;
> -    return rc;
> +    if (rc_ao) return AO_ABORT(rc_ao);
> +    return AO_INPROGRESS;
>  }
> 
>  int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
> @@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
>      return 0;
>  }
> 
> -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
> +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
> +                          libxl_device_disk *disk,
> +                          const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
>      flexarray_t *front;
>      flexarray_t *back;
>      char *dev;
> @@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>          rc = ERROR_NOMEM;
>          goto out;
>      }
> -    back = flexarray_make(16, 1);
> +    back = flexarray_make(20, 1);
>      if (!back) {
>          rc = ERROR_NOMEM;
>          goto out_free;
> @@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>              flexarray_append(back, "params");
>              flexarray_append(back, dev);
> 
> +            flexarray_append(back, "script");
> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
> +                                                  libxl_xen_script_dir_path(),
> +                                                  "block"));
> +
>              assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> @@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>                  libxl__device_disk_string_of_format(disk->format),
>                  disk->pdev_path));
> 
> +            flexarray_append(back, "script");
> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
> +                             libxl_xen_script_dir_path(),
> +                             "blktap"));
> +
>              /* now create a phy device to export the device to the guest */
>              goto do_backend_phy;
>          case LIBXL_DISK_BACKEND_QDISK:
> @@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      flexarray_append(back, disk->readwrite ? "w" : "r");
>      flexarray_append(back, "device-type");
>      flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
> +    /* compatibility addon to keep udev rules */
> +    flexarray_append(back, "execute_udev");
> +    flexarray_append(back, "n");
> 
>      flexarray_append(front, "backend-id");
>      flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
> @@ -1420,14 +1439,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
> +    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
> +        disk->backend == LIBXL_DISK_BACKEND_TAP) {
> +        rc = libxl__initiate_device_add(egc, ao, &device);
> +        if (rc) goto out_free;
> +    } else {
> +        /* no need to execute hotplug scripts */
> +        libxl__ao_complete(egc, ao, 0);
> +    }

This would be better as a switch, since it would make it more obvious
that the "else" is actually "case LIBXL_DISK_BACKEND_QDISK" etc.

[...]
> +
> +/*
> + * Return codes:
> + * 1 Success and event(s) HAVE BEEN added
> + * 0 Success and NO events where added

                              were

(I saw a few of these)

> + * < 0 Error
> + *
> + * Since this function can be called several times, and several events
> + * can be added to the same context, the user has to call
> + * libxl__ao_complete when necessary (if no events are added).
> + */
>  int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>                                    libxl__device *dev)
>  {
> @@ -392,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp2o-0001zL-Sd; Mon, 16 Apr 2012 16:44:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJp2n-0001zD-Nc
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:44:50 +0000
Received: from [193.109.254.147:50769] by server-2.bemta-14.messagelabs.com id
	74/61-19409-18C4C8F4; Mon, 16 Apr 2012 16:44:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334594688!4874097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28896 invoked from network); 16 Apr 2012 16:44:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:44:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:44:47 +0100
Message-ID: <1334594686.14560.242.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 17:44:46 +0100
In-Reply-To: <1334588804-7755-3-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
 for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
> This is a rather big change, that adds the necessary machinery to perform
> hotplug script calling from libxl for Linux. This patch launches the necessary
> scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
> scripts).
> 
> Here's a list of the major changes introduced:
> 
>  * libxl_device_disk_add makes use of the new event library and takes the
>    optional parameter libxl_asyncop_how, to choose how the operation has to be
>    issued (sync or async).
> 
>  * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
>    and then launches the hotplug script.
> 
>  * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
>    calls libxl__initiate_device_remove, so we can disconnect the device and
>    execute the necessary hotplug scripts instead of just deleting the backend
>    entries. So libxl__devices_destroy now uses the event library, and so does
>    libxl_domain_destroy.
> 
>  * Since libxl__devices_destroy calls multiple times
>    libxl__initiate_device_remove, this function now returns a different value
>    regarding the actions taken (if an event was added or not). The user has to
>    call libxl__ao_complete after using this function if necessary.
> 
>  * The internal API for hotplug scripts has been added, which consists of one
>    function; libxl__device_hotplug that takes the device and the action to
>    execute.
> 
>  * Linux hotplug scripts are called by setting the necessary env variables to
>    emulate udev rules, so there's no need to change them (although a rework to
>    pass this as parameters insted of env variables would be suitable, so both
>    NetBSD and Linux hotplug scripts take the same parameters).
> 
>  * Added a check in xen-hotplug-common.sh, so scripts are only executed from
>    udev when using xend. xl adds an execute_udev=n to xenstore device backend
>    and passes XL_CALL=y to the env of the script call, and udev calls check that
>    execute_udev is not set and XL_CALL is empty also.
> 
> I've also modified the python binding for pyxl_domain_destroy, that now take the
> ao_how parameter, but I'm not really sure if it's done correctly, let's just say
> that it compiles.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
>  tools/libxl/Makefile                      |    3 +-
>  tools/libxl/libxl.c                       |  104 ++++++++++++++++++----
>  tools/libxl/libxl.h                       |    7 +-
>  tools/libxl/libxl_create.c                |    4 +-
>  tools/libxl/libxl_device.c                |  140 +++++++++++++++++++++++++++--
>  tools/libxl/libxl_dm.c                    |    4 +-
>  tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++
>  tools/libxl/libxl_internal.h              |   43 +++++++++-
>  tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++++
>  tools/libxl/xl_cmdimpl.c                  |   14 ++--
>  tools/python/xen/lowlevel/xl/xl.c         |    5 +-
>  12 files changed, 474 insertions(+), 40 deletions(-)
>  create mode 100644 tools/libxl/libxl_hotplug.c
> 
> diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
> index 8f6557d..dc3e867 100644
> --- a/tools/hotplug/Linux/xen-hotplug-common.sh
> +++ b/tools/hotplug/Linux/xen-hotplug-common.sh
> @@ -15,6 +15,12 @@
>  # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>  #
> 
> +# Hack to prevent the execution of hotplug scripts form udev if the domain

                                                      from
> +# has ben launched from libxl

        been

> +execute_udev=`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
> +if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
> +    exit 0
> +fi

So, am I right that in some future world where we have got rid of xend
and made this stuff work without udev everywhere (e.g. including driver
domains) there is a path to deprecating this snippet without requiring
everyone to go through some sort of transition?

Or are we stuck with this envvar forever? It's not a big deal but if we
can invert it (e.g. by setting ENV{HOTPLUG_GATE}=${XENBUS}/evecute_udev
in xen-backend.rules and ...if -n "${HOTPLUG_GATE}" && xenstore-read
${HOTPLUG_GATE}... etc) then that would be nicer?

>  dir=$(dirname "$0")
>  . "$dir/hotplugpath.sh"
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 16ebef3..fb4fbf2 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
>      GC_FREE;
>  }
> 
> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
> +                         const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
>      char *dom_path;
>      char *vm_path;
>      char *pid;
>      int rc, dm_present;
> +    int rc_ao = 0;
> 
>      rc = libxl_domain_info(ctx, NULL, domid);
>      switch(rc) {
> @@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
> 
>          libxl__qmp_cleanup(gc, domid);
>      }
> -    if (libxl__devices_destroy(gc, domid) < 0)
> +    rc_ao = libxl__devices_destroy(egc, ao, domid);
> +    if (rc_ao < 0)
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                     "libxl__devices_destroy failed for %d", domid);
> 
> @@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>          goto out;
>      }
>      rc = 0;
> +
>  out:
> -    GC_FREE;
> -    return rc;
> +    if (rc_ao) return AO_ABORT(rc_ao);
> +    return AO_INPROGRESS;
>  }
> 
>  int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
> @@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
>      return 0;
>  }
> 
> -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
> +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
> +                          libxl_device_disk *disk,
> +                          const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
>      flexarray_t *front;
>      flexarray_t *back;
>      char *dev;
> @@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>          rc = ERROR_NOMEM;
>          goto out;
>      }
> -    back = flexarray_make(16, 1);
> +    back = flexarray_make(20, 1);
>      if (!back) {
>          rc = ERROR_NOMEM;
>          goto out_free;
> @@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>              flexarray_append(back, "params");
>              flexarray_append(back, dev);
> 
> +            flexarray_append(back, "script");
> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
> +                                                  libxl_xen_script_dir_path(),
> +                                                  "block"));
> +
>              assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> @@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>                  libxl__device_disk_string_of_format(disk->format),
>                  disk->pdev_path));
> 
> +            flexarray_append(back, "script");
> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
> +                             libxl_xen_script_dir_path(),
> +                             "blktap"));
> +
>              /* now create a phy device to export the device to the guest */
>              goto do_backend_phy;
>          case LIBXL_DISK_BACKEND_QDISK:
> @@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      flexarray_append(back, disk->readwrite ? "w" : "r");
>      flexarray_append(back, "device-type");
>      flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
> +    /* compatibility addon to keep udev rules */
> +    flexarray_append(back, "execute_udev");
> +    flexarray_append(back, "n");
> 
>      flexarray_append(front, "backend-id");
>      flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
> @@ -1420,14 +1439,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
> +    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
> +        disk->backend == LIBXL_DISK_BACKEND_TAP) {
> +        rc = libxl__initiate_device_add(egc, ao, &device);
> +        if (rc) goto out_free;
> +    } else {
> +        /* no need to execute hotplug scripts */
> +        libxl__ao_complete(egc, ao, 0);
> +    }

This would be better as a switch, since it would make it more obvious
that the "else" is actually "case LIBXL_DISK_BACKEND_QDISK" etc.

[...]
> +
> +/*
> + * Return codes:
> + * 1 Success and event(s) HAVE BEEN added
> + * 0 Success and NO events where added

                              were

(I saw a few of these)

> + * < 0 Error
> + *
> + * Since this function can be called several times, and several events
> + * can be added to the same context, the user has to call
> + * libxl__ao_complete when necessary (if no events are added).
> + */
>  int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>                                    libxl__device *dev)
>  {
> @@ -392,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp3r-00025E-Bz; Mon, 16 Apr 2012 16:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJovS-0001WT-Sx
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:37:15 +0000
Received: from [85.158.143.35:62763] by server-3.bemta-4.messagelabs.com id
	09/C6-05853-ABA4C8F4; Mon, 16 Apr 2012 16:37:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334594231!12656699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27744 invoked from network); 16 Apr 2012 16:37:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:37:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:36:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:36:37 +0100
Message-ID: <1334594195.14560.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 16 Apr 2012 17:36:35 +0100
In-Reply-To: <20120416154429.GB4654@phenom.dumpdata.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
	<20120416154429.GB4654@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 16 Apr 2012 16:45:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, the arch/x86
	maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>, Jeremy
	Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Stephan
	Diestelhorst <stephan.diestelhorst@amd.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:44 +0100, Konrad Rzeszutek Wilk wrote:
> On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
> > * Thomas Gleixner <tglx@linutronix.de> [2012-03-31 00:07:58]:
> > 
> > > I know that Peter is going to go berserk on me, but if we are running
> > > a paravirt guest then it's simple to provide a mechanism which allows
> > > the host (aka hypervisor) to check that in the guest just by looking
> > > at some global state.
> > > 
> > > So if a guest exits due to an external event it's easy to inspect the
> > > state of that guest and avoid to schedule away when it was interrupted
> > > in a spinlock held section. That guest/host shared state needs to be
> > > modified to indicate the guest to invoke an exit when the last nested
> > > lock has been released.
> > 
> > I had attempted something like that long back:
> > 
> > http://lkml.org/lkml/2010/6/3/4
> > 
> > The issue is with ticketlocks though. VCPUs could go into a spin w/o
> > a lock being held by anybody. Say VCPUs 1-99 try to grab a lock in
> > that order (on a host with one cpu). VCPU1 wins (after VCPU0 releases it)
> > and releases the lock. VCPU1 is next eligible to take the lock. If 
> > that is not scheduled early enough by host, then remaining vcpus would keep 
> > spinning (even though lock is technically not held by anybody) w/o making 
> > forward progress.
> > 
> > In that situation, what we really need is for the guest to hint to host
> > scheduler to schedule VCPU1 early (via yield_to or something similar). 
> > 
> > The current pv-spinlock patches however does not track which vcpu is
> > spinning at what head of the ticketlock. I suppose we can consider 
> > that optimization in future and see how much benefit it provides (over
> > plain yield/sleep the way its done now).
> 
> Right. I think Jeremy played around with this some time?

5/11 "xen/pvticketlock: Xen implementation for PV ticket locks" tracks
which vcpus are waiting for a lock in "cpumask_t waiting_cpus" and
tracks which lock each is waiting for in per-cpu "lock_waiting". This is
used in xen_unlock_kick to kick the right CPU. There's a loop over only
the waiting cpus to figure out who to kick.

> > 
> > Do you see any issues if we take in what we have today and address the
> > finer-grained optimization as next step?
> 
> I think that is the proper course - these patches show
> that on baremetal we don't incur performance regressions and in
> virtualization case we benefit greatly. Since these are the basic
> building blocks of a kernel - taking it slow and just adding
> this set of patches for v3.5 is a good idea - and then building on top
> of that for further refinement.
> 
> > 
> > - vatsa 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp3r-00025E-Bz; Mon, 16 Apr 2012 16:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJovS-0001WT-Sx
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:37:15 +0000
Received: from [85.158.143.35:62763] by server-3.bemta-4.messagelabs.com id
	09/C6-05853-ABA4C8F4; Mon, 16 Apr 2012 16:37:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334594231!12656699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27744 invoked from network); 16 Apr 2012 16:37:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:37:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:36:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:36:37 +0100
Message-ID: <1334594195.14560.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 16 Apr 2012 17:36:35 +0100
In-Reply-To: <20120416154429.GB4654@phenom.dumpdata.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
	<20120416154429.GB4654@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 16 Apr 2012 16:45:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, the arch/x86
	maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>, Jeremy
	Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Stephan
	Diestelhorst <stephan.diestelhorst@amd.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:44 +0100, Konrad Rzeszutek Wilk wrote:
> On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
> > * Thomas Gleixner <tglx@linutronix.de> [2012-03-31 00:07:58]:
> > 
> > > I know that Peter is going to go berserk on me, but if we are running
> > > a paravirt guest then it's simple to provide a mechanism which allows
> > > the host (aka hypervisor) to check that in the guest just by looking
> > > at some global state.
> > > 
> > > So if a guest exits due to an external event it's easy to inspect the
> > > state of that guest and avoid to schedule away when it was interrupted
> > > in a spinlock held section. That guest/host shared state needs to be
> > > modified to indicate the guest to invoke an exit when the last nested
> > > lock has been released.
> > 
> > I had attempted something like that long back:
> > 
> > http://lkml.org/lkml/2010/6/3/4
> > 
> > The issue is with ticketlocks though. VCPUs could go into a spin w/o
> > a lock being held by anybody. Say VCPUs 1-99 try to grab a lock in
> > that order (on a host with one cpu). VCPU1 wins (after VCPU0 releases it)
> > and releases the lock. VCPU1 is next eligible to take the lock. If 
> > that is not scheduled early enough by host, then remaining vcpus would keep 
> > spinning (even though lock is technically not held by anybody) w/o making 
> > forward progress.
> > 
> > In that situation, what we really need is for the guest to hint to host
> > scheduler to schedule VCPU1 early (via yield_to or something similar). 
> > 
> > The current pv-spinlock patches however does not track which vcpu is
> > spinning at what head of the ticketlock. I suppose we can consider 
> > that optimization in future and see how much benefit it provides (over
> > plain yield/sleep the way its done now).
> 
> Right. I think Jeremy played around with this some time?

5/11 "xen/pvticketlock: Xen implementation for PV ticket locks" tracks
which vcpus are waiting for a lock in "cpumask_t waiting_cpus" and
tracks which lock each is waiting for in per-cpu "lock_waiting". This is
used in xen_unlock_kick to kick the right CPU. There's a loop over only
the waiting cpus to figure out who to kick.

> > 
> > Do you see any issues if we take in what we have today and address the
> > finer-grained optimization as next step?
> 
> I think that is the proper course - these patches show
> that on baremetal we don't incur performance regressions and in
> virtualization case we benefit greatly. Since these are the basic
> building blocks of a kernel - taking it slow and just adding
> this set of patches for v3.5 is a good idea - and then building on top
> of that for further refinement.
> 
> > 
> > - vatsa 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp3x-00025w-1V; Mon, 16 Apr 2012 16:46:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1SJp0e-0001oh-Lv
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:42:36 +0000
Received: from [193.109.254.147:26381] by server-8.bemta-14.messagelabs.com id
	2D/53-23244-BFB4C8F4; Mon, 16 Apr 2012 16:42:35 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334594553!4846312!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5626 invoked from network); 16 Apr 2012 16:42:34 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 16:42:34 -0000
Received: from saboo.goop.org (md20536d0.tmodns.net [208.54.5.210])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 3A3B290DA;
	Mon, 16 Apr 2012 09:42:32 -0700 (PDT)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 3112A20C1B;
	Mon, 16 Apr 2012 09:42:18 -0700 (PDT)
Message-ID: <4F8C4BEA.8040601@goop.org>
Date: Mon, 16 Apr 2012 09:42:18 -0700
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
	<20120416154429.GB4654@phenom.dumpdata.com>
	<1334594195.14560.236.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334594195.14560.236.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
X-Mailman-Approved-At: Mon, 16 Apr 2012 16:46:00 +0000
Cc: Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/16/2012 09:36 AM, Ian Campbell wrote:
> On Mon, 2012-04-16 at 16:44 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
>>> * Thomas Gleixner <tglx@linutronix.de> [2012-03-31 00:07:58]:
>>>
>>>> I know that Peter is going to go berserk on me, but if we are running
>>>> a paravirt guest then it's simple to provide a mechanism which allows
>>>> the host (aka hypervisor) to check that in the guest just by looking
>>>> at some global state.
>>>>
>>>> So if a guest exits due to an external event it's easy to inspect the
>>>> state of that guest and avoid to schedule away when it was interrupted
>>>> in a spinlock held section. That guest/host shared state needs to be
>>>> modified to indicate the guest to invoke an exit when the last nested
>>>> lock has been released.
>>> I had attempted something like that long back:
>>>
>>> http://lkml.org/lkml/2010/6/3/4
>>>
>>> The issue is with ticketlocks though. VCPUs could go into a spin w/o
>>> a lock being held by anybody. Say VCPUs 1-99 try to grab a lock in
>>> that order (on a host with one cpu). VCPU1 wins (after VCPU0 releases it)
>>> and releases the lock. VCPU1 is next eligible to take the lock. If 
>>> that is not scheduled early enough by host, then remaining vcpus would keep 
>>> spinning (even though lock is technically not held by anybody) w/o making 
>>> forward progress.
>>>
>>> In that situation, what we really need is for the guest to hint to host
>>> scheduler to schedule VCPU1 early (via yield_to or something similar). 
>>>
>>> The current pv-spinlock patches however does not track which vcpu is
>>> spinning at what head of the ticketlock. I suppose we can consider 
>>> that optimization in future and see how much benefit it provides (over
>>> plain yield/sleep the way its done now).
>> Right. I think Jeremy played around with this some time?
> 5/11 "xen/pvticketlock: Xen implementation for PV ticket locks" tracks
> which vcpus are waiting for a lock in "cpumask_t waiting_cpus" and
> tracks which lock each is waiting for in per-cpu "lock_waiting". This is
> used in xen_unlock_kick to kick the right CPU. There's a loop over only
> the waiting cpus to figure out who to kick.

Yes, and AFAIK the KVM pv-ticketlock patches do the same thing.  If a
(V)CPU is asleep, then sending it a kick is pretty much equivalent to a
yield to (not precisely, but it should get scheduled soon enough, and it
won't be competing with a pile of VCPUs with no useful work to do).

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp3x-00025w-1V; Mon, 16 Apr 2012 16:46:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1SJp0e-0001oh-Lv
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 16:42:36 +0000
Received: from [193.109.254.147:26381] by server-8.bemta-14.messagelabs.com id
	2D/53-23244-BFB4C8F4; Mon, 16 Apr 2012 16:42:35 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334594553!4846312!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5626 invoked from network); 16 Apr 2012 16:42:34 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 16:42:34 -0000
Received: from saboo.goop.org (md20536d0.tmodns.net [208.54.5.210])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 3A3B290DA;
	Mon, 16 Apr 2012 09:42:32 -0700 (PDT)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 3112A20C1B;
	Mon, 16 Apr 2012 09:42:18 -0700 (PDT)
Message-ID: <4F8C4BEA.8040601@goop.org>
Date: Mon, 16 Apr 2012 09:42:18 -0700
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
	<20120416154429.GB4654@phenom.dumpdata.com>
	<1334594195.14560.236.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334594195.14560.236.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
X-Mailman-Approved-At: Mon, 16 Apr 2012 16:46:00 +0000
Cc: Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/16/2012 09:36 AM, Ian Campbell wrote:
> On Mon, 2012-04-16 at 16:44 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
>>> * Thomas Gleixner <tglx@linutronix.de> [2012-03-31 00:07:58]:
>>>
>>>> I know that Peter is going to go berserk on me, but if we are running
>>>> a paravirt guest then it's simple to provide a mechanism which allows
>>>> the host (aka hypervisor) to check that in the guest just by looking
>>>> at some global state.
>>>>
>>>> So if a guest exits due to an external event it's easy to inspect the
>>>> state of that guest and avoid to schedule away when it was interrupted
>>>> in a spinlock held section. That guest/host shared state needs to be
>>>> modified to indicate the guest to invoke an exit when the last nested
>>>> lock has been released.
>>> I had attempted something like that long back:
>>>
>>> http://lkml.org/lkml/2010/6/3/4
>>>
>>> The issue is with ticketlocks though. VCPUs could go into a spin w/o
>>> a lock being held by anybody. Say VCPUs 1-99 try to grab a lock in
>>> that order (on a host with one cpu). VCPU1 wins (after VCPU0 releases it)
>>> and releases the lock. VCPU1 is next eligible to take the lock. If 
>>> that is not scheduled early enough by host, then remaining vcpus would keep 
>>> spinning (even though lock is technically not held by anybody) w/o making 
>>> forward progress.
>>>
>>> In that situation, what we really need is for the guest to hint to host
>>> scheduler to schedule VCPU1 early (via yield_to or something similar). 
>>>
>>> The current pv-spinlock patches however does not track which vcpu is
>>> spinning at what head of the ticketlock. I suppose we can consider 
>>> that optimization in future and see how much benefit it provides (over
>>> plain yield/sleep the way its done now).
>> Right. I think Jeremy played around with this some time?
> 5/11 "xen/pvticketlock: Xen implementation for PV ticket locks" tracks
> which vcpus are waiting for a lock in "cpumask_t waiting_cpus" and
> tracks which lock each is waiting for in per-cpu "lock_waiting". This is
> used in xen_unlock_kick to kick the right CPU. There's a loop over only
> the waiting cpus to figure out who to kick.

Yes, and AFAIK the KVM pv-ticketlock patches do the same thing.  If a
(V)CPU is asleep, then sending it a kick is pretty much equivalent to a
yield to (not precisely, but it should get scheduled soon enough, and it
won't be competing with a pile of VCPUs with no useful work to do).

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:48:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp65-0002M6-Or; Mon, 16 Apr 2012 16:48:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJp64-0002Lv-Da
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:48:12 +0000
Received: from [193.109.254.147:38567] by server-9.bemta-14.messagelabs.com id
	7C/B9-05787-B4D4C8F4; Mon, 16 Apr 2012 16:48:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334594891!4847072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26089 invoked from network); 16 Apr 2012 16:48:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:48:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:48:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:48:10 +0100
Message-ID: <1334594889.14560.244.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 17:48:09 +0100
In-Reply-To: <1334588804-7755-5-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-5-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
> Currently we only pass script=no to Qemu, to avoid calling any scripts when
> attaching a tap interface, but we should also pass downscript=no to avoid Qemu
> trying to execute a script when disconnecting the interface. This prevents the
> following harmless error message:
> 
> /etc/qemu-ifdown: could not launch network script
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/libxl/libxl_dm.c |   17 +++++++++++------
>  1 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index ba5bef7..8dc588d 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -216,11 +216,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>                  else
>                      ifname = vifs[i].ifname;
>                  flexarray_vappend(dm_args,
> -                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
> -                                                       vifs[i].devid, smac, vifs[i].model),
> -                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
> -                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
> -                                NULL);
> +                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
> +                                       vifs[i].devid, smac, vifs[i].model),
> +                "-net", libxl__sprintf(gc,
> +                               "tap,vlan=%d,ifname=%s,bridge=%s,script=%s,"
> +                               "downscript=%s",
> +                               vifs[i].devid, ifname, vifs[i].bridge,
> +                               libxl_tapif_script(gc), libxl_tapif_script(gc)),
> +                               NULL);

I think these should be indented at least a little bit wrt the
flexarray_vappend. Since you've already split the string you might just
need to re-wrap a bit to fit in 80 chars (which I guess is why you
changed this)

>                  ioemu_vifs++;
>              }
>          }
> @@ -462,8 +465,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                                                  vifs[i].devid, smac));
>                  flexarray_append(dm_args, "-netdev");
>                  flexarray_append(dm_args,
> -                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
> +                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s,"
> +                                      "downscript=%s",
>                                                  vifs[i].devid, ifname,
> +                                                libxl_tapif_script(gc),
>                                                  libxl_tapif_script(gc)));

The indentation here is now inconsistent.

Other than the whitepace issues:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

>                  ioemu_vifs++;
>              }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:48:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp65-0002M6-Or; Mon, 16 Apr 2012 16:48:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJp64-0002Lv-Da
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:48:12 +0000
Received: from [193.109.254.147:38567] by server-9.bemta-14.messagelabs.com id
	7C/B9-05787-B4D4C8F4; Mon, 16 Apr 2012 16:48:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334594891!4847072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26089 invoked from network); 16 Apr 2012 16:48:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:48:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:48:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:48:10 +0100
Message-ID: <1334594889.14560.244.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 17:48:09 +0100
In-Reply-To: <1334588804-7755-5-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-5-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
> Currently we only pass script=no to Qemu, to avoid calling any scripts when
> attaching a tap interface, but we should also pass downscript=no to avoid Qemu
> trying to execute a script when disconnecting the interface. This prevents the
> following harmless error message:
> 
> /etc/qemu-ifdown: could not launch network script
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/libxl/libxl_dm.c |   17 +++++++++++------
>  1 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index ba5bef7..8dc588d 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -216,11 +216,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>                  else
>                      ifname = vifs[i].ifname;
>                  flexarray_vappend(dm_args,
> -                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
> -                                                       vifs[i].devid, smac, vifs[i].model),
> -                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
> -                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
> -                                NULL);
> +                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
> +                                       vifs[i].devid, smac, vifs[i].model),
> +                "-net", libxl__sprintf(gc,
> +                               "tap,vlan=%d,ifname=%s,bridge=%s,script=%s,"
> +                               "downscript=%s",
> +                               vifs[i].devid, ifname, vifs[i].bridge,
> +                               libxl_tapif_script(gc), libxl_tapif_script(gc)),
> +                               NULL);

I think these should be indented at least a little bit wrt the
flexarray_vappend. Since you've already split the string you might just
need to re-wrap a bit to fit in 80 chars (which I guess is why you
changed this)

>                  ioemu_vifs++;
>              }
>          }
> @@ -462,8 +465,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                                                  vifs[i].devid, smac));
>                  flexarray_append(dm_args, "-netdev");
>                  flexarray_append(dm_args,
> -                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
> +                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s,"
> +                                      "downscript=%s",
>                                                  vifs[i].devid, ifname,
> +                                                libxl_tapif_script(gc),
>                                                  libxl_tapif_script(gc)));

The indentation here is now inconsistent.

Other than the whitepace issues:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

>                  ioemu_vifs++;
>              }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:50:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:50:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp8D-0002Zl-AC; Mon, 16 Apr 2012 16:50:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJp8B-0002ZW-54
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:50:23 +0000
Received: from [85.158.139.83:57869] by server-3.bemta-5.messagelabs.com id
	B9/50-25237-ECD4C8F4; Mon, 16 Apr 2012 16:50:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334595021!23521046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17028 invoked from network); 16 Apr 2012 16:50:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:50:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:50:20 +0100
Message-ID: <1334595019.14560.246.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 17:50:19 +0100
In-Reply-To: <1334588804-7755-6-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
 directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
> Clean xenstore, to prevent leaving empty directories in the tree, like:
> 
> /local/domain/0/backend/console = ""   (n0)
> /local/domain/0/backend/console/3 = ""   (n0)
> 
> That was left after a guest was destroyed.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/libxl/libxl_device.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index d773d71..4161d1bd 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -609,12 +609,11 @@ out_ok:
>  
>  int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>  {
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *fe_path = libxl__device_frontend_path(gc, dev);
>  
> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
> +    libxl__xs_path_cleanup(gc, fe_path);
> +    libxl__xs_path_cleanup(gc, be_path);

is xs_rm not recursive? At least from the CLI it seems to be

quartz:~# xenstore-write /foo/bar/baz 123
quartz:~# xenstore-ls -f | grep foo
/foo = ""
/foo/bar = ""
/foo/bar/baz = "123"
quartz:~# xenstore-rm  /foo
quartz:~# xenstore-ls -f | grep foo
quartz:~# 

looking at xenstore_client.c it seems to only call xs_rm() and not do
any traversal itself?

>  
>      libxl__device_destroy_tapdisk(gc, be_path);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:50:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:50:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJp8D-0002Zl-AC; Mon, 16 Apr 2012 16:50:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJp8B-0002ZW-54
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:50:23 +0000
Received: from [85.158.139.83:57869] by server-3.bemta-5.messagelabs.com id
	B9/50-25237-ECD4C8F4; Mon, 16 Apr 2012 16:50:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334595021!23521046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17028 invoked from network); 16 Apr 2012 16:50:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:50:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:50:20 +0100
Message-ID: <1334595019.14560.246.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 16 Apr 2012 17:50:19 +0100
In-Reply-To: <1334588804-7755-6-git-send-email-roger.pau@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
 directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
> Clean xenstore, to prevent leaving empty directories in the tree, like:
> 
> /local/domain/0/backend/console = ""   (n0)
> /local/domain/0/backend/console/3 = ""   (n0)
> 
> That was left after a guest was destroyed.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/libxl/libxl_device.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index d773d71..4161d1bd 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -609,12 +609,11 @@ out_ok:
>  
>  int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>  {
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *fe_path = libxl__device_frontend_path(gc, dev);
>  
> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
> +    libxl__xs_path_cleanup(gc, fe_path);
> +    libxl__xs_path_cleanup(gc, be_path);

is xs_rm not recursive? At least from the CLI it seems to be

quartz:~# xenstore-write /foo/bar/baz 123
quartz:~# xenstore-ls -f | grep foo
/foo = ""
/foo/bar = ""
/foo/bar/baz = "123"
quartz:~# xenstore-rm  /foo
quartz:~# xenstore-ls -f | grep foo
quartz:~# 

looking at xenstore_client.c it seems to only call xs_rm() and not do
any traversal itself?

>  
>      libxl__device_destroy_tapdisk(gc, be_path);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpFg-0002r0-AW; Mon, 16 Apr 2012 16:58:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJpFe-0002qv-MF
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:58:06 +0000
Received: from [85.158.143.99:38704] by server-3.bemta-4.messagelabs.com id
	E4/E8-05853-E9F4C8F4; Mon, 16 Apr 2012 16:58:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334595485!22971757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30355 invoked from network); 16 Apr 2012 16:58:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:58:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:58:04 +0100
Message-ID: <1334595483.14560.249.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 17:58:03 +0100
In-Reply-To: <20364.18772.529397.220632@mariner.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
	<20364.18772.529397.220632@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 17:31 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > On Mon, 2012-04-16 at 16:50 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > > > libxl: add a dummy ao_how to libxl_domain_core_dump
> > > > -        return ERROR_FAIL;
> > > > +        rc = ERROR_FAIL;
> > > 
> > > While you're doing that, did you want to change it to use "goto out" ?
> > 
> > wouldn't the "out:" be immediately after this immediately following
> > closing brace?
> 
> I think it would look like this:

Make sense.

8<--------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334595420 -3600
# Node ID 8d92d1f34921c8675d85c74aa36e319c9451f68f
# Parent  f95c8fe372d35fdf8937750e9271ea76ff991488
libxl: add a dummy ao_how to libxl_domain_core_dump

Although this function is not currently slow it may become so in the future
(this also depends somewhat on the size of the guest).  Therefore arrange for
it to take an ao_how which it completes immediately.  This will allow us to
make it asynchronous in the future without breaking API compatibility.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used"

diff -r f95c8fe372d3 -r 8d92d1f34921 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Apr 16 17:57:00 2012 +0100
@@ -627,16 +627,26 @@ int libxl_domain_pause(libxl_ctx *ctx, u
 }
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
-                           const char *filename)
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how)
 {
-    int ret;
+    AO_CREATE(ctx, domid, ao_how);
+    int ret, rc;
+
     ret = xc_domain_dumpcore(ctx->xch, domid, filename);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
                      domid, filename);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL;
+        goto out;
     }
-    return 0;
+
+    rc = 0;
+out:
+
+    libxl__ao_complete(egc, ao, rc);
+
+    return AO_INPROGRESS;
 }
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
diff -r f95c8fe372d3 -r 8d92d1f34921 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.h	Mon Apr 16 17:57:00 2012 +0100
@@ -509,7 +509,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
-int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
+int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how);
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
diff -r f95c8fe372d3 -r 8d92d1f34921 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 16 17:57:00 2012 +0100
@@ -1276,7 +1276,7 @@ static int handle_domain_death(libxl_ctx
             LOG("failed to construct core dump path");
         } else {
             LOG("dumping core to %s", corefile);
-            rc=libxl_domain_core_dump(ctx, domid, corefile);
+            rc=libxl_domain_core_dump(ctx, domid, corefile, NULL);
             if (rc) LOG("core dump failed (rc=%d).", rc);
         }
         /* No point crying over spilled milk, continue on failure. */
@@ -2893,7 +2893,7 @@ static void core_dump_domain(const char 
 {
     int rc;
     find_domain(domain_spec);
-    rc=libxl_domain_core_dump(ctx, domid, filename);
+    rc=libxl_domain_core_dump(ctx, domid, filename, NULL);
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 16:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 16:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpFg-0002r0-AW; Mon, 16 Apr 2012 16:58:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SJpFe-0002qv-MF
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 16:58:06 +0000
Received: from [85.158.143.99:38704] by server-3.bemta-4.messagelabs.com id
	E4/E8-05853-E9F4C8F4; Mon, 16 Apr 2012 16:58:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334595485!22971757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30355 invoked from network); 16 Apr 2012 16:58:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 16:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 16:58:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 17:58:04 +0100
Message-ID: <1334595483.14560.249.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 17:58:03 +0100
In-Reply-To: <20364.18772.529397.220632@mariner.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
	<20364.18772.529397.220632@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 17:31 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > On Mon, 2012-04-16 at 16:50 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("[PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > > > libxl: add a dummy ao_how to libxl_domain_core_dump
> > > > -        return ERROR_FAIL;
> > > > +        rc = ERROR_FAIL;
> > > 
> > > While you're doing that, did you want to change it to use "goto out" ?
> > 
> > wouldn't the "out:" be immediately after this immediately following
> > closing brace?
> 
> I think it would look like this:

Make sense.

8<--------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334595420 -3600
# Node ID 8d92d1f34921c8675d85c74aa36e319c9451f68f
# Parent  f95c8fe372d35fdf8937750e9271ea76ff991488
libxl: add a dummy ao_how to libxl_domain_core_dump

Although this function is not currently slow it may become so in the future
(this also depends somewhat on the size of the guest).  Therefore arrange for
it to take an ao_how which it completes immediately.  This will allow us to
make it asynchronous in the future without breaking API compatibility.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used"

diff -r f95c8fe372d3 -r 8d92d1f34921 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Apr 16 17:57:00 2012 +0100
@@ -627,16 +627,26 @@ int libxl_domain_pause(libxl_ctx *ctx, u
 }
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
-                           const char *filename)
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how)
 {
-    int ret;
+    AO_CREATE(ctx, domid, ao_how);
+    int ret, rc;
+
     ret = xc_domain_dumpcore(ctx->xch, domid, filename);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s",
                      domid, filename);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL;
+        goto out;
     }
-    return 0;
+
+    rc = 0;
+out:
+
+    libxl__ao_complete(egc, ao, rc);
+
+    return AO_INPROGRESS;
 }
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
diff -r f95c8fe372d3 -r 8d92d1f34921 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/libxl.h	Mon Apr 16 17:57:00 2012 +0100
@@ -509,7 +509,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
-int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
+int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
+                           const char *filename,
+                           const libxl_asyncop_how *ao_how);
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
diff -r f95c8fe372d3 -r 8d92d1f34921 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Apr 13 19:40:07 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Apr 16 17:57:00 2012 +0100
@@ -1276,7 +1276,7 @@ static int handle_domain_death(libxl_ctx
             LOG("failed to construct core dump path");
         } else {
             LOG("dumping core to %s", corefile);
-            rc=libxl_domain_core_dump(ctx, domid, corefile);
+            rc=libxl_domain_core_dump(ctx, domid, corefile, NULL);
             if (rc) LOG("core dump failed (rc=%d).", rc);
         }
         /* No point crying over spilled milk, continue on failure. */
@@ -2893,7 +2893,7 @@ static void core_dump_domain(const char 
 {
     int rc;
     find_domain(domain_spec);
-    rc=libxl_domain_core_dump(ctx, domid, filename);
+    rc=libxl_domain_core_dump(ctx, domid, filename, NULL);
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpJ9-000303-WA; Mon, 16 Apr 2012 17:01:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJpJ7-0002zu-Us
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:01:42 +0000
Received: from [85.158.138.51:16695] by server-8.bemta-3.messagelabs.com id
	E5/37-24428-5705C8F4; Mon, 16 Apr 2012 17:01:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334595699!22416785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9316 invoked from network); 16 Apr 2012 17:01:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24200431"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:01:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 13:01:12 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJpIe-0002vK-1P; Mon, 16 Apr 2012 18:01:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Apr 2012 18:05:57 +0100
Message-ID: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE,
	remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 015d2af..3e4a47b 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -183,12 +183,12 @@ static int ioreq_parse(struct ioreq *ioreq)
     case BLKIF_OP_READ:
         ioreq->prot = PROT_WRITE; /* to memory */
         break;
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments) {
             ioreq->presync = 1;
             return 0;
         }
-        ioreq->presync = ioreq->postsync = 1;
+        ioreq->postsync = 1;
         /* fall through */
     case BLKIF_OP_WRITE:
         ioreq->prot = PROT_READ; /* from memory */
@@ -354,7 +354,7 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
                        qemu_aio_complete, ioreq);
         break;
     case BLKIF_OP_WRITE:
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments) {
             break;
         }
@@ -627,7 +627,7 @@ static int blk_init(struct XenDevice *xendev)
                   blkdev->file_size, blkdev->file_size >> 20);
 
     /* fill info */
-    xenstore_write_be_int(&blkdev->xendev, "feature-barrier", 1);
+    xenstore_write_be_int(&blkdev->xendev, "feature-flush-cache", 1);
     xenstore_write_be_int(&blkdev->xendev, "info",            info);
     xenstore_write_be_int(&blkdev->xendev, "sector-size",     blkdev->file_blk);
     xenstore_write_be_int(&blkdev->xendev, "sectors",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpJ9-000303-WA; Mon, 16 Apr 2012 17:01:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJpJ7-0002zu-Us
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:01:42 +0000
Received: from [85.158.138.51:16695] by server-8.bemta-3.messagelabs.com id
	E5/37-24428-5705C8F4; Mon, 16 Apr 2012 17:01:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334595699!22416785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9316 invoked from network); 16 Apr 2012 17:01:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24200431"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:01:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 13:01:12 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJpIe-0002vK-1P; Mon, 16 Apr 2012 18:01:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Apr 2012 18:05:57 +0100
Message-ID: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE,
	remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 015d2af..3e4a47b 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -183,12 +183,12 @@ static int ioreq_parse(struct ioreq *ioreq)
     case BLKIF_OP_READ:
         ioreq->prot = PROT_WRITE; /* to memory */
         break;
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments) {
             ioreq->presync = 1;
             return 0;
         }
-        ioreq->presync = ioreq->postsync = 1;
+        ioreq->postsync = 1;
         /* fall through */
     case BLKIF_OP_WRITE:
         ioreq->prot = PROT_READ; /* from memory */
@@ -354,7 +354,7 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
                        qemu_aio_complete, ioreq);
         break;
     case BLKIF_OP_WRITE:
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments) {
             break;
         }
@@ -627,7 +627,7 @@ static int blk_init(struct XenDevice *xendev)
                   blkdev->file_size, blkdev->file_size >> 20);
 
     /* fill info */
-    xenstore_write_be_int(&blkdev->xendev, "feature-barrier", 1);
+    xenstore_write_be_int(&blkdev->xendev, "feature-flush-cache", 1);
     xenstore_write_be_int(&blkdev->xendev, "info",            info);
     xenstore_write_be_int(&blkdev->xendev, "sector-size",     blkdev->file_blk);
     xenstore_write_be_int(&blkdev->xendev, "sectors",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpMZ-0003CN-L2; Mon, 16 Apr 2012 17:05:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJpMX-0003CH-L2
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:05:13 +0000
Received: from [85.158.139.83:16215] by server-3.bemta-5.messagelabs.com id
	08/EF-25237-8415C8F4; Mon, 16 Apr 2012 17:05:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334595910!19457008!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10584 invoked from network); 16 Apr 2012 17:05:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:05:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24200559"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:05:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 13:05:09 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJpMS-0002yl-W6;
	Mon, 16 Apr 2012 18:05:08 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334595019.14560.246.camel@zakaz.uk.xensource.com>
Date: Mon, 16 Apr 2012 18:05:10 +0100
Message-ID: <86B21C60-CA21-4BE1-AD9F-C01EB7762282@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 17:50, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>> Clean xenstore, to prevent leaving empty directories in the tree, like:
>> =

>> /local/domain/0/backend/console =3D ""   (n0)
>> /local/domain/0/backend/console/3 =3D ""   (n0)
>> =

>> That was left after a guest was destroyed.
>> =

>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> tools/libxl/libxl_device.c |    5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>> =

>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index d773d71..4161d1bd 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -609,12 +609,11 @@ out_ok:
>> =

>> int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>> {
>> -    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>>     char *be_path =3D libxl__device_backend_path(gc, dev);
>>     char *fe_path =3D libxl__device_frontend_path(gc, dev);
>> =

>> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
>> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
>> +    libxl__xs_path_cleanup(gc, fe_path);
>> +    libxl__xs_path_cleanup(gc, be_path);
> =

> is xs_rm not recursive? At least from the CLI it seems to be
> =

> quartz:~# xenstore-write /foo/bar/baz 123
> quartz:~# xenstore-ls -f | grep foo
> /foo =3D ""
> /foo/bar =3D ""
> /foo/bar/baz =3D "123"
> quartz:~# xenstore-rm  /foo
> quartz:~# xenstore-ls -f | grep foo
> quartz:~# =

> =

> looking at xenstore_client.c it seems to only call xs_rm() and not do
> any traversal itself?


Sure! I had an error probably somewhere else in the code, and changing libx=
l__xs_path_cleanup to xs_rm didn't make it happen again, so forget about th=
is. I will send an updated version of the series without this stuff (and th=
e appropriate changes).

> =

>> =

>>     libxl__device_destroy_tapdisk(gc, be_path);
>> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpMZ-0003CN-L2; Mon, 16 Apr 2012 17:05:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SJpMX-0003CH-L2
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:05:13 +0000
Received: from [85.158.139.83:16215] by server-3.bemta-5.messagelabs.com id
	08/EF-25237-8415C8F4; Mon, 16 Apr 2012 17:05:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334595910!19457008!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10584 invoked from network); 16 Apr 2012 17:05:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:05:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24200559"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 13:05:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 13:05:09 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SJpMS-0002yl-W6;
	Mon, 16 Apr 2012 18:05:08 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334595019.14560.246.camel@zakaz.uk.xensource.com>
Date: Mon, 16 Apr 2012 18:05:10 +0100
Message-ID: <86B21C60-CA21-4BE1-AD9F-C01EB7762282@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 17:50, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>> Clean xenstore, to prevent leaving empty directories in the tree, like:
>> =

>> /local/domain/0/backend/console =3D ""   (n0)
>> /local/domain/0/backend/console/3 =3D ""   (n0)
>> =

>> That was left after a guest was destroyed.
>> =

>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> tools/libxl/libxl_device.c |    5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>> =

>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index d773d71..4161d1bd 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -609,12 +609,11 @@ out_ok:
>> =

>> int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>> {
>> -    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>>     char *be_path =3D libxl__device_backend_path(gc, dev);
>>     char *fe_path =3D libxl__device_frontend_path(gc, dev);
>> =

>> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
>> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
>> +    libxl__xs_path_cleanup(gc, fe_path);
>> +    libxl__xs_path_cleanup(gc, be_path);
> =

> is xs_rm not recursive? At least from the CLI it seems to be
> =

> quartz:~# xenstore-write /foo/bar/baz 123
> quartz:~# xenstore-ls -f | grep foo
> /foo =3D ""
> /foo/bar =3D ""
> /foo/bar/baz =3D "123"
> quartz:~# xenstore-rm  /foo
> quartz:~# xenstore-ls -f | grep foo
> quartz:~# =

> =

> looking at xenstore_client.c it seems to only call xs_rm() and not do
> any traversal itself?


Sure! I had an error probably somewhere else in the code, and changing libx=
l__xs_path_cleanup to xs_rm didn't make it happen again, so forget about th=
is. I will send an updated version of the series without this stuff (and th=
e appropriate changes).

> =

>> =

>>     libxl__device_destroy_tapdisk(gc, be_path);
>> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:08:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpPr-0003K5-8z; Mon, 16 Apr 2012 17:08:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJpPq-0003Jx-E5
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:08:38 +0000
Received: from [193.109.254.147:7455] by server-3.bemta-14.messagelabs.com id
	F5/F2-23274-5125C8F4; Mon, 16 Apr 2012 17:08:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334596117!4868231!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12359 invoked from network); 16 Apr 2012 17:08:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 17:08:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJpPf-0004qS-Ir; Mon, 16 Apr 2012 17:08:27 +0000
Date: Mon, 16 Apr 2012 18:08:27 +0100
From: Tim Deegan <tim@xen.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120416170827.GE13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
User-Agent: Mutt/1.4.2.1i
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> Hmmm... I spent a great deal of time on TSC support in the hypervisor
> 2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
> everything on HVM as well.  There's most likely a bug or two still lurking
> but, for all guests, with the default tsc_mode, TSC is provided by Xen
> as an absolutely stable clock source.  If Xen determines that the underlying
> hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
> If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
> save/restore, TSC is always emulated.  The result is (ignoring possible
> bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
> CPUs; and c) constant rate.  Even across migration/save/restore.

AIUI, this thread is about the PV-time clock source, not about the TSC
itself.  Even if the TSC is emulated (or in some other way made
"stable") the PV wallclock is not necessarily stable across migration.
But since migration is controlled by the kernel, presumably the kernel
can DTRT about it.

> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

That seems like overdoing it.  Certainly it's not OK unless it can also
check that Xen is providing a stable TSC (i.e. that tscmode==1).

In the case where the PV clock has been selected, can it not be marked
unstable without also marking the TSC unstable?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:08:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpPr-0003K5-8z; Mon, 16 Apr 2012 17:08:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJpPq-0003Jx-E5
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:08:38 +0000
Received: from [193.109.254.147:7455] by server-3.bemta-14.messagelabs.com id
	F5/F2-23274-5125C8F4; Mon, 16 Apr 2012 17:08:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334596117!4868231!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12359 invoked from network); 16 Apr 2012 17:08:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 17:08:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJpPf-0004qS-Ir; Mon, 16 Apr 2012 17:08:27 +0000
Date: Mon, 16 Apr 2012 18:08:27 +0100
From: Tim Deegan <tim@xen.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120416170827.GE13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <049b7b93-fb37-4962-b272-d786e1dcfacb@default>
User-Agent: Mutt/1.4.2.1i
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> Hmmm... I spent a great deal of time on TSC support in the hypervisor
> 2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
> everything on HVM as well.  There's most likely a bug or two still lurking
> but, for all guests, with the default tsc_mode, TSC is provided by Xen
> as an absolutely stable clock source.  If Xen determines that the underlying
> hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
> If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
> save/restore, TSC is always emulated.  The result is (ignoring possible
> bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
> CPUs; and c) constant rate.  Even across migration/save/restore.

AIUI, this thread is about the PV-time clock source, not about the TSC
itself.  Even if the TSC is emulated (or in some other way made
"stable") the PV wallclock is not necessarily stable across migration.
But since migration is controlled by the kernel, presumably the kernel
can DTRT about it.

> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

That seems like overdoing it.  Certainly it's not OK unless it can also
check that Xen is providing a stable TSC (i.e. that tscmode==1).

In the case where the PV clock has been selected, can it not be marked
unstable without also marking the TSC unstable?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpWV-0003Xt-5O; Mon, 16 Apr 2012 17:15:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpWT-0003Xo-FC
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:15:29 +0000
Received: from [85.158.143.99:26859] by server-3.bemta-4.messagelabs.com id
	CC/F6-05853-0B35C8F4; Mon, 16 Apr 2012 17:15:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334596526!14112790!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9965 invoked from network); 16 Apr 2012 17:15:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:15:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHFLGe004038
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:15:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHFJOx002532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:15:20 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHFJX1023924; Mon, 16 Apr 2012 12:15:19 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:15:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 084DD40280; Mon, 16 Apr 2012 13:10:22 -0400 (EDT)
Date: Mon, 16 Apr 2012 13:10:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120416171021.GG9925@phenom.dumpdata.com>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F8C53AA.0055,ss=1,re=0.000,fgs=0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 06:05:57PM +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/xen_disk.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 015d2af..3e4a47b 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -183,12 +183,12 @@ static int ioreq_parse(struct ioreq *ioreq)
>      case BLKIF_OP_READ:
>          ioreq->prot = PROT_WRITE; /* to memory */
>          break;
> -    case BLKIF_OP_WRITE_BARRIER:
> +    case BLKIF_OP_FLUSH_DISKCACHE:
>          if (!ioreq->req.nr_segments) {
>              ioreq->presync = 1;
>              return 0;
>          }
> -        ioreq->presync = ioreq->postsync = 1;
> +        ioreq->postsync = 1;
>          /* fall through */
>      case BLKIF_OP_WRITE:
>          ioreq->prot = PROT_READ; /* from memory */
> @@ -354,7 +354,7 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
>                         qemu_aio_complete, ioreq);
>          break;
>      case BLKIF_OP_WRITE:
> -    case BLKIF_OP_WRITE_BARRIER:
> +    case BLKIF_OP_FLUSH_DISKCACHE:
>          if (!ioreq->req.nr_segments) {
>              break;
>          }
> @@ -627,7 +627,7 @@ static int blk_init(struct XenDevice *xendev)
>                    blkdev->file_size, blkdev->file_size >> 20);
>  
>      /* fill info */
> -    xenstore_write_be_int(&blkdev->xendev, "feature-barrier", 1);
> +    xenstore_write_be_int(&blkdev->xendev, "feature-flush-cache", 1);
>      xenstore_write_be_int(&blkdev->xendev, "info",            info);
>      xenstore_write_be_int(&blkdev->xendev, "sector-size",     blkdev->file_blk);
>      xenstore_write_be_int(&blkdev->xendev, "sectors",
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpWV-0003Xt-5O; Mon, 16 Apr 2012 17:15:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpWT-0003Xo-FC
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:15:29 +0000
Received: from [85.158.143.99:26859] by server-3.bemta-4.messagelabs.com id
	CC/F6-05853-0B35C8F4; Mon, 16 Apr 2012 17:15:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334596526!14112790!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9965 invoked from network); 16 Apr 2012 17:15:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:15:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHFLGe004038
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:15:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHFJOx002532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:15:20 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHFJX1023924; Mon, 16 Apr 2012 12:15:19 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:15:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 084DD40280; Mon, 16 Apr 2012 13:10:22 -0400 (EDT)
Date: Mon, 16 Apr 2012 13:10:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120416171021.GG9925@phenom.dumpdata.com>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F8C53AA.0055,ss=1,re=0.000,fgs=0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 06:05:57PM +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/xen_disk.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 015d2af..3e4a47b 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -183,12 +183,12 @@ static int ioreq_parse(struct ioreq *ioreq)
>      case BLKIF_OP_READ:
>          ioreq->prot = PROT_WRITE; /* to memory */
>          break;
> -    case BLKIF_OP_WRITE_BARRIER:
> +    case BLKIF_OP_FLUSH_DISKCACHE:
>          if (!ioreq->req.nr_segments) {
>              ioreq->presync = 1;
>              return 0;
>          }
> -        ioreq->presync = ioreq->postsync = 1;
> +        ioreq->postsync = 1;
>          /* fall through */
>      case BLKIF_OP_WRITE:
>          ioreq->prot = PROT_READ; /* from memory */
> @@ -354,7 +354,7 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
>                         qemu_aio_complete, ioreq);
>          break;
>      case BLKIF_OP_WRITE:
> -    case BLKIF_OP_WRITE_BARRIER:
> +    case BLKIF_OP_FLUSH_DISKCACHE:
>          if (!ioreq->req.nr_segments) {
>              break;
>          }
> @@ -627,7 +627,7 @@ static int blk_init(struct XenDevice *xendev)
>                    blkdev->file_size, blkdev->file_size >> 20);
>  
>      /* fill info */
> -    xenstore_write_be_int(&blkdev->xendev, "feature-barrier", 1);
> +    xenstore_write_be_int(&blkdev->xendev, "feature-flush-cache", 1);
>      xenstore_write_be_int(&blkdev->xendev, "info",            info);
>      xenstore_write_be_int(&blkdev->xendev, "sector-size",     blkdev->file_blk);
>      xenstore_write_be_int(&blkdev->xendev, "sectors",
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ9-0003i5-A4; Mon, 16 Apr 2012 17:18:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g3-Hf
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:15899] by server-2.bemta-14.messagelabs.com id
	2A/E0-19409-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17940 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kQ-DP; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EF-BU;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:52 +0100
Message-ID: <1334596686-8479-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/24] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 4c60ad9..734a5dc 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op->ao);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op->ao);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 20c95db..9af99ec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1498,6 +1498,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ8-0003hV-FV; Mon, 16 Apr 2012 17:18:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003fu-3g
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:50477] by server-6.bemta-14.messagelabs.com id
	24/63-02047-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17912 invoked from network); 16 Apr 2012 17:18:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kD-5f; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dn-4K;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:45 +0100
Message-ID: <1334596686-8479-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/24] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   62 ++++++++++-
 6 files changed, 515 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..42ac89f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..03e71f6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 149a4eb..2f559d5 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index dce88ad..35c8bdd 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ce4bb5..abc38fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -315,10 +328,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -566,6 +583,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon.  The child may not
+ * make any further calls to libxl infrastructure, except for memory
+ * allocation and logging.  If the child needs to use xenstore it
+ * must open its own xs handle and use it directly, rather than via
+ * the libxl event machinery.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -619,6 +666,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ9-0003i5-A4; Mon, 16 Apr 2012 17:18:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g3-Hf
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:15899] by server-2.bemta-14.messagelabs.com id
	2A/E0-19409-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17940 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kQ-DP; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EF-BU;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:52 +0100
Message-ID: <1334596686-8479-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/24] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 4c60ad9..734a5dc 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op->ao);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op->ao);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 20c95db..9af99ec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1498,6 +1498,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZB-0003k4-GV; Mon, 16 Apr 2012 17:18:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003g3-3V
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [193.109.254.147:55426] by server-2.bemta-14.messagelabs.com id
	1C/E0-19409-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17982 invoked from network); 16 Apr 2012 17:18:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kS-EC; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EJ-D8;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:53 +0100
Message-ID: <1334596686-8479-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/24] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Use libxl__ev_child_inuse rather than testing pid directly.
 * Fix a code style error.
 * Properly initialise the sub-operations' aos in _init.
 * Bugfixes.
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  713 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 419 insertions(+), 343 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..54f3813 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 03e71f6..477b72a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -494,7 +494,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..bdc4cb4 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl->ao);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,217 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    return pid;
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
+
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl->ao);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
-        }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-    libxl__ptr_add(gc, output);
-    return output;
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-out_err:
-    free(output);
-    return NULL;
-}
-
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    assert(bl->ao);
+    bl->diskpath = NULL;
+    bl->openpty.ao = bl->ao;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
+    bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl->ao);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl->ao);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
-        goto out;
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        rc = 0;
+        goto out_ok;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+ out_ok:
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl->ao);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +332,188 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
+
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-        goto out_close;
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl->ao);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..dbc3cf0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -572,8 +572,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9af99ec..b3f84ba 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -449,6 +450,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1534,6 +1536,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ8-0003hV-FV; Mon, 16 Apr 2012 17:18:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003fu-3g
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:50477] by server-6.bemta-14.messagelabs.com id
	24/63-02047-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17912 invoked from network); 16 Apr 2012 17:18:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kD-5f; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dn-4K;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:45 +0100
Message-ID: <1334596686-8479-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/24] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   62 ++++++++++-
 6 files changed, 515 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..42ac89f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..03e71f6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 149a4eb..2f559d5 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index dce88ad..35c8bdd 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2ce4bb5..abc38fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -196,6 +196,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -315,10 +328,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -566,6 +583,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon.  The child may not
+ * make any further calls to libxl infrastructure, except for memory
+ * allocation and logging.  If the child needs to use xenstore it
+ * must open its own xs handle and use it directly, rather than via
+ * the libxl event machinery.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -619,6 +666,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZB-0003k4-GV; Mon, 16 Apr 2012 17:18:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003g3-3V
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [193.109.254.147:55426] by server-2.bemta-14.messagelabs.com id
	1C/E0-19409-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17982 invoked from network); 16 Apr 2012 17:18:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kS-EC; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EJ-D8;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:53 +0100
Message-ID: <1334596686-8479-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/24] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Use libxl__ev_child_inuse rather than testing pid directly.
 * Fix a code style error.
 * Properly initialise the sub-operations' aos in _init.
 * Bugfixes.
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  713 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 419 insertions(+), 343 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..54f3813 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 03e71f6..477b72a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -494,7 +494,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..bdc4cb4 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl->ao);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,217 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    return pid;
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
+
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl->ao);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
-        }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-    libxl__ptr_add(gc, output);
-    return output;
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-out_err:
-    free(output);
-    return NULL;
-}
-
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    assert(bl->ao);
+    bl->diskpath = NULL;
+    bl->openpty.ao = bl->ao;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
+    bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl->ao);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl->ao);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
-        goto out;
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        rc = 0;
+        goto out_ok;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+ out_ok:
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl->ao);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +332,188 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
+
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-        goto out_close;
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl->ao);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..dbc3cf0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -572,8 +572,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9af99ec..b3f84ba 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -449,6 +450,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1534,6 +1536,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZA-0003jD-H4; Mon, 16 Apr 2012 17:18:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003g1-0U
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [193.109.254.147:55398] by server-9.bemta-14.messagelabs.com id
	65/97-05787-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17954 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ki-L9; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Et-KI;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:02 +0100
Message-ID: <1334596686-8479-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/24] libxl: remove malloc failure handling
	from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to use libxl__zalloc, where allocation failure is fatal.

Also remove a spurious semicolon from the helper macro.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    2 --
 tools/libxl/libxl_event.c    |    8 +-------
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 54f3813..b7f665a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -779,7 +779,6 @@ static void domain_death_occurred(libxl__egc *egc,
     *evg_upd = evg_next;
 
     libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
-    if (!ev) return;
 
     libxl__event_occurred(egc, ev);
 
@@ -866,7 +865,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                if (!ev) goto out;
                 
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 3795654..991f16e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -980,13 +980,7 @@ libxl_event *libxl__event_new(libxl__egc *egc,
 {
     libxl_event *ev;
 
-    ev = malloc(sizeof(*ev));
-    if (!ev) {
-        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
-        return NULL;
-    }
-
-    memset(ev, 0, sizeof(*ev));
+    ev = libxl__zalloc(0,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e97f5e..977db2a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -641,10 +641,10 @@ _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
                                       uint32_t domid);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
-   * If allocation fails, calls _disaster, and returns NULL. */
+   * Cannot fail. */
 
 #define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
     /* Convenience macro. */
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZA-0003jD-H4; Mon, 16 Apr 2012 17:18:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003g1-0U
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [193.109.254.147:55398] by server-9.bemta-14.messagelabs.com id
	65/97-05787-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17954 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ki-L9; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Et-KI;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:02 +0100
Message-ID: <1334596686-8479-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/24] libxl: remove malloc failure handling
	from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to use libxl__zalloc, where allocation failure is fatal.

Also remove a spurious semicolon from the helper macro.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    2 --
 tools/libxl/libxl_event.c    |    8 +-------
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 54f3813..b7f665a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -779,7 +779,6 @@ static void domain_death_occurred(libxl__egc *egc,
     *evg_upd = evg_next;
 
     libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
-    if (!ev) return;
 
     libxl__event_occurred(egc, ev);
 
@@ -866,7 +865,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                if (!ev) goto out;
                 
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 3795654..991f16e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -980,13 +980,7 @@ libxl_event *libxl__event_new(libxl__egc *egc,
 {
     libxl_event *ev;
 
-    ev = malloc(sizeof(*ev));
-    if (!ev) {
-        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
-        return NULL;
-    }
-
-    memset(ev, 0, sizeof(*ev));
+    ev = libxl__zalloc(0,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e97f5e..977db2a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -641,10 +641,10 @@ _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
                                       uint32_t domid);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
-   * If allocation fails, calls _disaster, and returns NULL. */
+   * Cannot fail. */
 
 #define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
     /* Convenience macro. */
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZF-0003oq-GR; Mon, 16 Apr 2012 17:18:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003hk-5W
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [85.158.139.83:16643] by server-11.bemta-5.messagelabs.com id
	22/C8-12959-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8834 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kp-NZ; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002F5-Mo;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:05 +0100
Message-ID: <1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Abolish libxl_fork.  Its only callers were in xl.  Its functionality
is now moved elsewhere, as follows:

* The "logging version of fork", which is what it was billed as, is now
  xl_fork, which also dies on failure.

* Closing the xenstore handle in the child is now done in
  libxl__ev_child_fork, which is the only remaining place where fork
  is called in libxl.

* We provide a new function libxl__ev_child_xenstore_reopen for
  in-libxl children to make the ctx useable for xenstore again.

* Consequently libxl__spawn_record_pid now no longer needs to mess
  about with its own xenstore handle.  As a bonus it can now just use
  libxl__xs_write.

Also, since we have now converted all the forkers in libxl, we can
always honour the fork_replacement childproc hook - so do so.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   35 ++++++++++++++++-------------------
 tools/libxl/libxl_fork.c     |   25 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 tools/libxl/libxl_utils.c    |   21 ---------------------
 tools/libxl/libxl_utils.h    |    3 +--
 tools/libxl/xl.c             |   12 ++++++++++++
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |    5 ++---
 8 files changed, 61 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index d44b702..d681736 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,34 +127,23 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
-                            pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, pid_t pid)
 {
-    struct xs_handle *xsh = NULL;
-    const char *pid = NULL;
-    int rc, xsok;
+    int r, rc;
 
-    pid = GCSPRINTF("%d", innerchild);
+    rc = libxl__ev_child_xenstore_reopen(gc, spawn->what);
+    if (rc) goto out;
 
-    /* we mustn't use the parent's handle in the child */
-    xsh = xs_daemon_open();
-    if (!xsh) {
-        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
-             spawn->pidpath, pid);
-        rc = ERROR_FAIL;  goto out;
-    }
-
-    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
-    if (!xsok) {
+    r = libxl__xs_write(gc, XBT_NULL, spawn->pidpath, "%d", pid);
+    if (r) {
         LOGE(ERROR,
-             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+             "write %s = %d: xenstore write failed", spawn->pidpath, pid);
         rc = ERROR_FAIL;  goto out;
     }
 
     rc = 0;
 
 out:
-    if (xsh) xs_daemon_close(xsh);
     return rc ? SIGTERM : 0;
 }
 
@@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
     /* we are now the middle process */
 
-    child = fork();
+    pid_t (*fork_replacement)(void*) =
+        CTX->childproc_hooks
+        ? CTX->childproc_hooks->fork_replacement
+        : 0;
+    child =
+        fork_replacement
+        ? fork_replacement(CTX->childproc_user)
+        : fork();
+
     if (child == -1)
         exit(255);
     if (!child) {
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 35c8bdd..9ff99e0 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -347,7 +347,12 @@ pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
 
     if (!pid) {
         /* woohoo! */
-        return 0; /* Yes, CTX is left locked in the child. */
+        if (CTX->xsh) {
+            xs_daemon_destroy_postfork(CTX->xsh);
+            CTX->xsh = NULL; /* turns mistakes into crashes */
+        }
+        /* Yes, CTX is left locked in the child. */
+        return 0;
     }
 
     ch->pid = pid;
@@ -395,6 +400,24 @@ const libxl_childproc_hooks libxl__childproc_default_hooks = {
     libxl_sigchld_owner_libxl, 0, 0
 };
 
+int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what) {
+    int rc;
+
+    assert(!CTX->xsh);
+    CTX->xsh = xs_daemon_open();
+    if (!CTX->xsh) {
+        LOGE(ERROR, "%s: xenstore reopen failed", what);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    libxl_fd_set_cloexec(CTX, xs_fileno(CTX->xsh), 1);
+
+    return 0;
+
+ out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fb4dee8..3e90ac4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -627,6 +627,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
 static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
                 { return childw_out->pid >= 0; }
 
+/* Useable (only) in the child to once more make the ctx useable for
+ * xenstore operations.  logs failure in the form "what: <error
+ * message>". */
+_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what);
+
 
 /*
  * Other event-handling support provided by the libxl event core to
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f0d94c6..858410e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -444,27 +444,6 @@ int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
     return rc;
 }
 
-pid_t libxl_fork(libxl_ctx *ctx)
-{
-    pid_t pid;
-
-    pid = fork();
-    if (pid == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed");
-        return -1;
-    }
-
-    if (!pid) {
-        if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-        ctx->xsh = 0;
-        /* This ensures that anyone who forks but doesn't exec,
-         * and doesn't reinitialise the libxl_ctx, is OK.
-         * It also means they can safely call libxl_ctx_free. */
-    }
-
-    return pid;
-}
-
 int libxl_pipe(libxl_ctx *ctx, int pipes[2])
 {
     if (pipe(pipes) < 0) {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 2b47622..74beb52 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -47,9 +47,8 @@ int libxl_write_exactly(libxl_ctx *ctx, int fd, const void *data,
    * logged using filename (which is only used for logging) and what
    * (which may be 0). */
 
-pid_t libxl_fork(libxl_ctx *ctx);
 int libxl_pipe(libxl_ctx *ctx, int pipes[2]);
-  /* Just like fork(2), pipe(2), but log errors. */
+  /* Just like pipe(2), but log errors. */
 
 void libxl_report_child_exitstatus(libxl_ctx *ctx, xentoollog_level,
                                    const char *what, pid_t pid, int status);
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..d4db1f8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -105,6 +105,18 @@ void postfork(void)
     }
 }
 
+pid_t xl_fork(libxl_ctx *ctx) {
+    pid_t pid;
+
+    pid = fork();
+    if (pid == -1) {
+        perror("fork failed");
+        exit(-1);
+    }
+
+    return pid;
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..c031bb3 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -105,6 +105,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+pid_t xl_fork(libxl_ctx *ctx); /* like fork, but prints and dies if it fails */
 void postfork(void);
 
 /* global options */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index ce52599..ebfd4fe 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1709,7 +1709,7 @@ start:
         pid_t child1, got_child;
         int nullfd;
 
-        child1 = libxl_fork(ctx);
+        child1 = xl_fork(ctx);
         if (child1) {
             printf("Daemon running with PID %d\n", child1);
 
@@ -2748,8 +2748,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     MUST( libxl_pipe(ctx, sendpipe) );
     MUST( libxl_pipe(ctx, recvpipe) );
 
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
+    child = xl_fork(ctx);
 
     if (!child) {
         dup2(sendpipe[0], 0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZF-0003oq-GR; Mon, 16 Apr 2012 17:18:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003hk-5W
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [85.158.139.83:16643] by server-11.bemta-5.messagelabs.com id
	22/C8-12959-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8834 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kp-NZ; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002F5-Mo;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:05 +0100
Message-ID: <1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Abolish libxl_fork.  Its only callers were in xl.  Its functionality
is now moved elsewhere, as follows:

* The "logging version of fork", which is what it was billed as, is now
  xl_fork, which also dies on failure.

* Closing the xenstore handle in the child is now done in
  libxl__ev_child_fork, which is the only remaining place where fork
  is called in libxl.

* We provide a new function libxl__ev_child_xenstore_reopen for
  in-libxl children to make the ctx useable for xenstore again.

* Consequently libxl__spawn_record_pid now no longer needs to mess
  about with its own xenstore handle.  As a bonus it can now just use
  libxl__xs_write.

Also, since we have now converted all the forkers in libxl, we can
always honour the fork_replacement childproc hook - so do so.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   35 ++++++++++++++++-------------------
 tools/libxl/libxl_fork.c     |   25 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 tools/libxl/libxl_utils.c    |   21 ---------------------
 tools/libxl/libxl_utils.h    |    3 +--
 tools/libxl/xl.c             |   12 ++++++++++++
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |    5 ++---
 8 files changed, 61 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index d44b702..d681736 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,34 +127,23 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
-                            pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, pid_t pid)
 {
-    struct xs_handle *xsh = NULL;
-    const char *pid = NULL;
-    int rc, xsok;
+    int r, rc;
 
-    pid = GCSPRINTF("%d", innerchild);
+    rc = libxl__ev_child_xenstore_reopen(gc, spawn->what);
+    if (rc) goto out;
 
-    /* we mustn't use the parent's handle in the child */
-    xsh = xs_daemon_open();
-    if (!xsh) {
-        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
-             spawn->pidpath, pid);
-        rc = ERROR_FAIL;  goto out;
-    }
-
-    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
-    if (!xsok) {
+    r = libxl__xs_write(gc, XBT_NULL, spawn->pidpath, "%d", pid);
+    if (r) {
         LOGE(ERROR,
-             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+             "write %s = %d: xenstore write failed", spawn->pidpath, pid);
         rc = ERROR_FAIL;  goto out;
     }
 
     rc = 0;
 
 out:
-    if (xsh) xs_daemon_close(xsh);
     return rc ? SIGTERM : 0;
 }
 
@@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
     /* we are now the middle process */
 
-    child = fork();
+    pid_t (*fork_replacement)(void*) =
+        CTX->childproc_hooks
+        ? CTX->childproc_hooks->fork_replacement
+        : 0;
+    child =
+        fork_replacement
+        ? fork_replacement(CTX->childproc_user)
+        : fork();
+
     if (child == -1)
         exit(255);
     if (!child) {
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 35c8bdd..9ff99e0 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -347,7 +347,12 @@ pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
 
     if (!pid) {
         /* woohoo! */
-        return 0; /* Yes, CTX is left locked in the child. */
+        if (CTX->xsh) {
+            xs_daemon_destroy_postfork(CTX->xsh);
+            CTX->xsh = NULL; /* turns mistakes into crashes */
+        }
+        /* Yes, CTX is left locked in the child. */
+        return 0;
     }
 
     ch->pid = pid;
@@ -395,6 +400,24 @@ const libxl_childproc_hooks libxl__childproc_default_hooks = {
     libxl_sigchld_owner_libxl, 0, 0
 };
 
+int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what) {
+    int rc;
+
+    assert(!CTX->xsh);
+    CTX->xsh = xs_daemon_open();
+    if (!CTX->xsh) {
+        LOGE(ERROR, "%s: xenstore reopen failed", what);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    libxl_fd_set_cloexec(CTX, xs_fileno(CTX->xsh), 1);
+
+    return 0;
+
+ out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fb4dee8..3e90ac4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -627,6 +627,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
 static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
                 { return childw_out->pid >= 0; }
 
+/* Useable (only) in the child to once more make the ctx useable for
+ * xenstore operations.  logs failure in the form "what: <error
+ * message>". */
+_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what);
+
 
 /*
  * Other event-handling support provided by the libxl event core to
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f0d94c6..858410e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -444,27 +444,6 @@ int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
     return rc;
 }
 
-pid_t libxl_fork(libxl_ctx *ctx)
-{
-    pid_t pid;
-
-    pid = fork();
-    if (pid == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed");
-        return -1;
-    }
-
-    if (!pid) {
-        if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-        ctx->xsh = 0;
-        /* This ensures that anyone who forks but doesn't exec,
-         * and doesn't reinitialise the libxl_ctx, is OK.
-         * It also means they can safely call libxl_ctx_free. */
-    }
-
-    return pid;
-}
-
 int libxl_pipe(libxl_ctx *ctx, int pipes[2])
 {
     if (pipe(pipes) < 0) {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 2b47622..74beb52 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -47,9 +47,8 @@ int libxl_write_exactly(libxl_ctx *ctx, int fd, const void *data,
    * logged using filename (which is only used for logging) and what
    * (which may be 0). */
 
-pid_t libxl_fork(libxl_ctx *ctx);
 int libxl_pipe(libxl_ctx *ctx, int pipes[2]);
-  /* Just like fork(2), pipe(2), but log errors. */
+  /* Just like pipe(2), but log errors. */
 
 void libxl_report_child_exitstatus(libxl_ctx *ctx, xentoollog_level,
                                    const char *what, pid_t pid, int status);
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..d4db1f8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -105,6 +105,18 @@ void postfork(void)
     }
 }
 
+pid_t xl_fork(libxl_ctx *ctx) {
+    pid_t pid;
+
+    pid = fork();
+    if (pid == -1) {
+        perror("fork failed");
+        exit(-1);
+    }
+
+    return pid;
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..c031bb3 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -105,6 +105,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+pid_t xl_fork(libxl_ctx *ctx); /* like fork, but prints and dies if it fails */
 void postfork(void);
 
 /* global options */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index ce52599..ebfd4fe 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1709,7 +1709,7 @@ start:
         pid_t child1, got_child;
         int nullfd;
 
-        child1 = libxl_fork(ctx);
+        child1 = xl_fork(ctx);
         if (child1) {
             printf("Daemon running with PID %d\n", child1);
 
@@ -2748,8 +2748,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     MUST( libxl_pipe(ctx, sendpipe) );
     MUST( libxl_pipe(ctx, recvpipe) );
 
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
+    child = xl_fork(ctx);
 
     if (!child) {
         dup2(sendpipe[0], 0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ8-0003hF-1s; Mon, 16 Apr 2012 17:18:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003fv-5S
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [85.158.139.83:16512] by server-12.bemta-5.messagelabs.com id
	4D/84-05587-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7004 invoked from network); 16 Apr 2012 17:18:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kC-4e; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dj-3p;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:44 +0100
Message-ID: <1334596686-8479-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/24] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Fix typo
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..149a4eb 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each element in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index af631fb..2ce4bb5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -257,8 +261,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ8-0003hF-1s; Mon, 16 Apr 2012 17:18:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003fv-5S
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [85.158.139.83:16512] by server-12.bemta-5.messagelabs.com id
	4D/84-05587-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7004 invoked from network); 16 Apr 2012 17:18:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kC-4e; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dj-3p;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:44 +0100
Message-ID: <1334596686-8479-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/24] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Fix typo
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..149a4eb 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each element in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index af631fb..2ce4bb5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -257,8 +261,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZB-0003jg-2j; Mon, 16 Apr 2012 17:18:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g6-Uq
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [85.158.139.83:16539] by server-1.bemta-5.messagelabs.com id
	CB/FD-28458-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7037 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kP-C1; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EB-Ay;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:51 +0100
Message-ID: <1334596686-8479-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/24] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v6
 * assert that the ao is non-null on _init.
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 231 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5ba144f..6e253b1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..4c60ad9
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    assert(dc->ao);
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        datacopier_callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc->ao);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6ceb362..20c95db 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -833,6 +833,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1458,6 +1459,45 @@ int libxl__carefd_close(libxl__carefd*);
 int libxl__carefd_fd(const libxl__carefd*);
 
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errnoval is valid
+ * onwrite==0 means failure happened when reading
+ *     errnoval==0 means we got eof and all data was written
+ *     errnoval!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZD-0003lg-29; Mon, 16 Apr 2012 17:18:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ8-0003g6-Bn
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [85.158.139.83:16635] by server-1.bemta-5.messagelabs.com id
	C5/0E-28458-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8829 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kY-I6; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EU-Gj;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:56 +0100
Message-ID: <1334596686-8479-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/24] libxl: Allow AO_GC and EGC_GC even if not
	used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mark the gc produced by AO_GC and EGC_GC with the gcc feature
__attribute__((unused)).  This allows the use of EGC_INIT and
STATE_AO_GC by functions which do actually use the gc.

This is convenient because those functions might want to use the ao or
egc, rather than the gc; and also because it means that functions
which morally ought to be fishing any gc they use out of an egc or
state structure can be written do so regardless of whether the gc is
actually used right then.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4cfb8d5..74dc2c5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1280,7 +1280,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 /* useful for all functions which take an egc: */
 
 #define EGC_GC                                  \
-    libxl__gc *const gc = &egc->gc
+    libxl__gc *const gc __attribute__((unused)) = &egc->gc
 
 /* egc initialisation and destruction: */
 
@@ -1383,7 +1383,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     })
 
 #define AO_GC                                   \
-    libxl__gc *const gc = &ao->gc
+    libxl__gc *const gc __attribute__((unused)) = &ao->gc
 
 #define STATE_AO_GC(op_ao)                      \
     libxl__ao *const ao = (op_ao);              \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZB-0003jg-2j; Mon, 16 Apr 2012 17:18:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g6-Uq
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [85.158.139.83:16539] by server-1.bemta-5.messagelabs.com id
	CB/FD-28458-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7037 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kP-C1; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EB-Ay;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:51 +0100
Message-ID: <1334596686-8479-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/24] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v6
 * assert that the ao is non-null on _init.
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 231 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5ba144f..6e253b1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..4c60ad9
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    assert(dc->ao);
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        datacopier_callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc->ao);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6ceb362..20c95db 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -833,6 +833,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1458,6 +1459,45 @@ int libxl__carefd_close(libxl__carefd*);
 int libxl__carefd_fd(const libxl__carefd*);
 
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errnoval is valid
+ * onwrite==0 means failure happened when reading
+ *     errnoval==0 means we got eof and all data was written
+ *     errnoval!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZD-0003lg-29; Mon, 16 Apr 2012 17:18:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ8-0003g6-Bn
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [85.158.139.83:16635] by server-1.bemta-5.messagelabs.com id
	C5/0E-28458-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8829 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kY-I6; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EU-Gj;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:56 +0100
Message-ID: <1334596686-8479-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/24] libxl: Allow AO_GC and EGC_GC even if not
	used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mark the gc produced by AO_GC and EGC_GC with the gcc feature
__attribute__((unused)).  This allows the use of EGC_INIT and
STATE_AO_GC by functions which do actually use the gc.

This is convenient because those functions might want to use the ao or
egc, rather than the gc; and also because it means that functions
which morally ought to be fishing any gc they use out of an egc or
state structure can be written do so regardless of whether the gc is
actually used right then.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4cfb8d5..74dc2c5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1280,7 +1280,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 /* useful for all functions which take an egc: */
 
 #define EGC_GC                                  \
-    libxl__gc *const gc = &egc->gc
+    libxl__gc *const gc __attribute__((unused)) = &egc->gc
 
 /* egc initialisation and destruction: */
 
@@ -1383,7 +1383,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     })
 
 #define AO_GC                                   \
-    libxl__gc *const gc = &ao->gc
+    libxl__gc *const gc __attribute__((unused)) = &ao->gc
 
 #define STATE_AO_GC(op_ao)                      \
     libxl__ao *const ao = (op_ao);              \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZF-0003oT-3z; Mon, 16 Apr 2012 17:18:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003hn-8a
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [193.109.254.147:20048] by server-5.bemta-14.messagelabs.com id
	C5/7E-30733-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18130 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ko-N9; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002F2-MH;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:04 +0100
Message-ID: <1334596686-8479-23-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/24] libxl: clarify definition of "slow"
	operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the comment in libxl_internal.h to be clearer about which
application-facing libxl operations need to take an ao_how.

Reported-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++------
 1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b77a891..fb4dee8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1399,17 +1399,34 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 /*
  * Machinery for asynchronous operations ("ao")
  *
- * All "slow" functions (includes anything that might block on a
- * guest or an external script) need to use the asynchronous
- * operation ("ao") machinery.  The function should take a parameter
- * const libxl_asyncop_how *ao_how and must start with a call to
- * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * inside libxl, because they can cause reentrancy callbacks.
+ * All "slow" functions (see below for the exact definition) need to
+ * use the asynchronous operation ("ao") machinery.  The function
+ * should take a parameter const libxl_asyncop_how *ao_how and must
+ * start with a call to AO_INITIATOR_ENTRY.  These functions MAY NOT
+ * be called from inside libxl, because they can cause reentrancy
+ * callbacks.
  *
  * For the same reason functions taking an ao_how may make themselves
  * an egc with EGC_INIT (and they will generally want to, to be able
  * to immediately complete an ao during its setup).
  *
+ *
+ * "Slow" functions includes any that might block on a guest or an
+ * external script.  More broadly, it includes any operations which
+ * are sufficiently slow that an application might reasonably want to
+ * initiate them, and then carry on doing something else, while the
+ * operation completes.  That is, a "fast" function must be fast
+ * enough that we do not mind blocking all other management operations
+ * on the same host while it completes.
+ *
+ * There are certain primitive functions which make a libxl operation
+ * necessarily "slow" for API reasons.  These are:
+ *  - awaiting xenstore watches (although read-modify-write xenstore
+ *    transactions are OK for fast functions)
+ *  - spawning subprocesses
+ *  - anything with a timeout
+ *
+ *
  * Lifecycle of an ao:
  *
  * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZF-0003oT-3z; Mon, 16 Apr 2012 17:18:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003hn-8a
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [193.109.254.147:20048] by server-5.bemta-14.messagelabs.com id
	C5/7E-30733-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18130 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ko-N9; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002F2-MH;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:04 +0100
Message-ID: <1334596686-8479-23-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/24] libxl: clarify definition of "slow"
	operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the comment in libxl_internal.h to be clearer about which
application-facing libxl operations need to take an ao_how.

Reported-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++------
 1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b77a891..fb4dee8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1399,17 +1399,34 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 /*
  * Machinery for asynchronous operations ("ao")
  *
- * All "slow" functions (includes anything that might block on a
- * guest or an external script) need to use the asynchronous
- * operation ("ao") machinery.  The function should take a parameter
- * const libxl_asyncop_how *ao_how and must start with a call to
- * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * inside libxl, because they can cause reentrancy callbacks.
+ * All "slow" functions (see below for the exact definition) need to
+ * use the asynchronous operation ("ao") machinery.  The function
+ * should take a parameter const libxl_asyncop_how *ao_how and must
+ * start with a call to AO_INITIATOR_ENTRY.  These functions MAY NOT
+ * be called from inside libxl, because they can cause reentrancy
+ * callbacks.
  *
  * For the same reason functions taking an ao_how may make themselves
  * an egc with EGC_INIT (and they will generally want to, to be able
  * to immediately complete an ao during its setup).
  *
+ *
+ * "Slow" functions includes any that might block on a guest or an
+ * external script.  More broadly, it includes any operations which
+ * are sufficiently slow that an application might reasonably want to
+ * initiate them, and then carry on doing something else, while the
+ * operation completes.  That is, a "fast" function must be fast
+ * enough that we do not mind blocking all other management operations
+ * on the same host while it completes.
+ *
+ * There are certain primitive functions which make a libxl operation
+ * necessarily "slow" for API reasons.  These are:
+ *  - awaiting xenstore watches (although read-modify-write xenstore
+ *    transactions are OK for fast functions)
+ *  - spawning subprocesses
+ *  - anything with a timeout
+ *
+ *
  * Lifecycle of an ao:
  *
  * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ6-0003gV-Tj; Mon, 16 Apr 2012 17:18:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ4-0003fl-V9
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:11 +0000
Received: from [85.158.139.83:16444] by server-9.bemta-5.messagelabs.com id
	6E/4C-09826-2545C8F4; Mon, 16 Apr 2012 17:18:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6954 invoked from network); 16 Apr 2012 17:18:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ3-0003k8-23; Mon, 16 Apr 2012 17:18:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ3-0002DX-05;
	Mon, 16 Apr 2012 18:18:09 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 18:17:42 +0100
Message-ID: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v7 00/24] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This has now been tested and appears to work for me.

Changes since v6 are bugfixes, comments from the list addressed, and
three new patches (marked with "*" below).

   01/24 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
   02/24 libxl: support multiple libxl__ev_fds for the same fd
   03/24 libxl: event API: new facilities for waiting for subprocesses
 * 04/24 autoconf: trim the configure script; use autoheader
   05/24 autoconf: New test for openpty et al.
   06/24 libxl: provide libxl__remove_file et al.
   07/24 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
   08/24 libxl: Clean up setdefault in do_domain_create
   09/24 libxl: provide libxl__datacopier_*
   10/24 libxl: provide libxl__openpty_*
   11/24 libxl: ao: Convert libxl_run_bootloader
   12/24 libxl: make libxl_create_logfile const-correct
   13/24 libxl: log bootloader output
   14/24 libxl: Allow AO_GC and EGC_GC even if not used
   15/24 libxl: remove ctx->waitpid_instead
   16/24 libxl: change some structures to unit arrays
   17/24 libxl: ao: convert libxl__spawn_*
   18/24 libxl: make libxl_create run bootloader via callback
   19/24 libxl: provide progress reporting for long-running operations
   20/24 libxl: remove malloc failure handling from NEW_EVENT
   21/24 libxl: convert console callback to libxl_asyncprogress_how
 * 22/24 libxl: clarify definition of "slow" operation
 * 23/24 libxl: child processes cleanups
 * 24/24 libxl: aborting bootloader invocation when domain dies


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ8-0003hq-TL; Mon, 16 Apr 2012 17:18:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g1-ES
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:50501] by server-9.bemta-14.messagelabs.com id
	84/97-05787-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17926 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kL-Ad; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002E3-8c;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:49 +0100
Message-ID: <1334596686-8479-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/24] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3996824..6ceb362 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1128,6 +1128,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..83c22b3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1a4874c..19b4615 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZC-0003lG-LH; Mon, 16 Apr 2012 17:18:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003g3-VJ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [193.109.254.147:55490] by server-2.bemta-14.messagelabs.com id
	1E/E0-19409-5545C8F4; Mon, 16 Apr 2012 17:18:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18088 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kX-Gr; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002ER-G3;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:55 +0100
Message-ID: <1334596686-8479-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/24] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 734a5dc..91e34de 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index bdc4cb4..1534bae 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -236,6 +236,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -258,6 +262,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -269,6 +275,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -308,6 +330,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
  out:
     assert(rc);
  out_ok:
+    free(logfile_tmp);
     bootloader_callback(egc, bl, rc);
 }
 
@@ -465,6 +488,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b3f84ba..4cfb8d5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1488,6 +1488,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1550,7 +1551,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ6-0003gV-Tj; Mon, 16 Apr 2012 17:18:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ4-0003fl-V9
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:11 +0000
Received: from [85.158.139.83:16444] by server-9.bemta-5.messagelabs.com id
	6E/4C-09826-2545C8F4; Mon, 16 Apr 2012 17:18:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6954 invoked from network); 16 Apr 2012 17:18:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ3-0003k8-23; Mon, 16 Apr 2012 17:18:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ3-0002DX-05;
	Mon, 16 Apr 2012 18:18:09 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 16 Apr 2012 18:17:42 +0100
Message-ID: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v7 00/24] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This has now been tested and appears to work for me.

Changes since v6 are bugfixes, comments from the list addressed, and
three new patches (marked with "*" below).

   01/24 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
   02/24 libxl: support multiple libxl__ev_fds for the same fd
   03/24 libxl: event API: new facilities for waiting for subprocesses
 * 04/24 autoconf: trim the configure script; use autoheader
   05/24 autoconf: New test for openpty et al.
   06/24 libxl: provide libxl__remove_file et al.
   07/24 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
   08/24 libxl: Clean up setdefault in do_domain_create
   09/24 libxl: provide libxl__datacopier_*
   10/24 libxl: provide libxl__openpty_*
   11/24 libxl: ao: Convert libxl_run_bootloader
   12/24 libxl: make libxl_create_logfile const-correct
   13/24 libxl: log bootloader output
   14/24 libxl: Allow AO_GC and EGC_GC even if not used
   15/24 libxl: remove ctx->waitpid_instead
   16/24 libxl: change some structures to unit arrays
   17/24 libxl: ao: convert libxl__spawn_*
   18/24 libxl: make libxl_create run bootloader via callback
   19/24 libxl: provide progress reporting for long-running operations
   20/24 libxl: remove malloc failure handling from NEW_EVENT
   21/24 libxl: convert console callback to libxl_asyncprogress_how
 * 22/24 libxl: clarify definition of "slow" operation
 * 23/24 libxl: child processes cleanups
 * 24/24 libxl: aborting bootloader invocation when domain dies


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ8-0003hq-TL; Mon, 16 Apr 2012 17:18:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g1-ES
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:50501] by server-9.bemta-14.messagelabs.com id
	84/97-05787-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17926 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kL-Ad; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002E3-8c;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:49 +0100
Message-ID: <1334596686-8479-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/24] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3996824..6ceb362 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1128,6 +1128,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..83c22b3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1a4874c..19b4615 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZG-0003pr-CC; Mon, 16 Apr 2012 17:18:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003fl-KF
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:16 +0000
Received: from [85.158.139.83:5762] by server-9.bemta-5.messagelabs.com id
	F5/7C-09826-7545C8F4; Mon, 16 Apr 2012 17:18:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8882 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kd-Ja; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Eg-IL;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:59 +0100
Message-ID: <1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn becomes a callback-style asynchronous function.
The implementation is now in terms of libxl__ev_* including
libxl_ev_child.

All the callers need to be updated.  This includes the device model
spawning functions libxl__create_device_model and
libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
abolished; instead the dm spawner calls back.

(The choice of which kind of device model to create is lifted out of
what used to be libxl__create_device_model, because that function was
indirectly recursive.  Recursive callback-style operations are clumsy
because they require a pointer indirection for the nested states.)

Waiting for proper device model startup it is no longer notionally
optional.  Previously the code appeared to tolerate this by passing
NULL for various libxl__spawner_starting* parameters to device model
spawners.  However, this was not used anywhere.

Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
no longer supported.  It remains as an unused formal parameter to
avoid updating, in this patch, all the call sites which pass NULL.
libxl__wait_for_offspring is in any case itself an obsolete function,
so this wrinkle will go away when its callers are updated to use the
event system.  Consequently libxl__spawn_check is also abolished.

The "console ready" callback also remains unchanged in this patch.
The API for this needs to be reviewed in the context of the event
series and its reentrancy restrictions documented.

Thus their callers need to be updated.  These are the domain creation
functions libxl_domain_create_new and _restore.  These functions now
take ao_hows, and have a private state structure.

However domain creation remains not completely converted to the event
mechanism; in particular it runs the outward-facing function
libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
happens in the current code this is not a bug because none of the rest
of the functionality surrounding the bootloader call will mind if the
event loop is reentered in the middle of its execution.

The file-scope function libxl__set_fd_flag which was used by the
previous spawn arrangements becomes unused and is removed; other
places in libxl can use libxl_fd_set_nonblock and
libxl_fd_set_cloexec, which of course remain.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   14 ++-
 tools/libxl/libxl_create.c   |  198 +++++++++++++++++++-----
 tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
 tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
 tools/libxl/xl_cmdimpl.c     |    6 +-
 6 files changed, 677 insertions(+), 400 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 477b72a..6f59364 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
+   * properties need to be documented but they may turn out to be too
+   * awkward */
+
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            const libxl_asyncop_how *ao_how);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how);
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8408c26..09a03a7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -537,16 +537,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
-static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+/*----- main domain creation -----*/
+
+/* We have a linear control flow; only one event callback is
+ * outstanding at any time.  Each initiation and callback function
+ * arranges for the next to be called, as the very last thing it
+ * does.  (If that particular sub-operation is not needed, a
+ * function will call the next event callback directly.)
+ */
+
+/* Event callbacks, in this order: */
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+/* Our own function to clean up and call the user's callback.
+ * The final call in the sequence. */
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc);
+
+static void initiate_domain_create(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs)
 {
+    STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
     domid = 0;
 
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
@@ -559,9 +583,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
+    dcs->guest_domid = domid;
+    dcs->dmss.guest_domid = 0; /* means we haven't spawned */
+
     if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
@@ -585,7 +612,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(state, 0, sizeof(*state));
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+    libxl__domain_build_state *state = &dcs->build_state;
+    dcs->dmss.spawn.ao = ao;
+    dcs->dmss.guest_config = dcs->guest_config;
+    dcs->dmss.build_state = &dcs->build_state;
+    dcs->dmss.callback = domcreate_devmodel_started;
 
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
@@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        ret = libxl__create_device_model(gc, domid, d_config,
-                                         state, &dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to create device model: %d", ret);
-            goto error_out;
-        }
+        dcs->dmss.guest_domid = domid;
+        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
+            libxl__spawn_stubdom(egc, &dcs->sdss);
+        else
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+        return;
+
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
@@ -669,7 +701,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
+            dcs->dmss.guest_domid = domid;
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+            return;
         }
         break;
     }
@@ -678,17 +712,41 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
-    if (dm_starting) {
+    assert(!dcs->dmss.guest_domid);
+    domcreate_devmodel_started(egc, &dcs->dmss, 0);
+    return;
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss);
+    STATE_AO_GC(dmss->spawn.ao);
+    int i;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
+    if (ret) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "device model did not start: %d", ret);
+        goto error_out;
+    }
+
+    if (dcs->dmss.guest_domid) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "device model did not start: %d", ret);
-            goto error_out;
-        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
@@ -716,38 +774,94 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
-    *domid_out = domid;
-    return 0;
+    domcreate_complete(egc, dcs, 0);
+    return;
 
 error_out:
-    if (domid)
-        libxl_domain_destroy(ctx, domid);
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
 
-    return ret;
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc) {
+    STATE_AO_GC(dcs->ao);
+
+    if (rc) {
+        if (dcs->guest_domid) {
+            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
+            if (rc2)
+                LOG(ERROR, "unable to destroy domain %d following"
+                    " failed creation", dcs->guest_domid);
+        }
+        dcs->guest_domid = -1;
+    }
+    dcs->callback(egc, dcs, rc, dcs->guest_domid);
+}
+
+/*----- application-facing domain creation interface -----*/
+
+typedef struct {
+    libxl__domain_create_state dcs;
+    uint32_t *domid_out;
+} libxl__app_domain_create_state;
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid);
+
+static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, 0, ao_how);
+    libxl__app_domain_create_state *cdcs;
+
+    GCNEW(cdcs);
+    cdcs->dcs.ao = ao;
+    cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.console_cb = cb;
+    cdcs->dcs.console_cb_priv = priv;
+    cdcs->dcs.callback = domain_create_cb;
+    cdcs->domid_out = domid;
+
+    initiate_domain_create(egc, &cdcs->dcs);
+
+    return AO_INPROGRESS;
 }
 
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid)
+{
+    libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs);
+    STATE_AO_GC(cdcs->dcs.ao);
+
+    if (!rc)
+        *cdcs->domid_out = domid;
+
+    libxl__ao_complete(egc, ao, rc);
+}
+    
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv,
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3921e2a..15472a8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -667,24 +667,28 @@ retry_transaction:
     return 0;
 }
 
-static int libxl__create_stubdom(libxl__gc *gc,
-                                 int guest_domid,
-                                 libxl_domain_config *guest_config,
-                                 libxl__domain_build_state *d_state,
-                                 libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc);
+
+void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state *sdss)
 {
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state[1];
-    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
-    libxl__spawner_starting *dm_starting = 0;
+
+    /* convenience aliases */
+    libxl_domain_config *dm_config = &sdss->stubdom_config;
+    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
+    int guest_domid = sdss->stubdom.guest_domid;
+    libxl__domain_build_state *d_state = sdss->stubdom.build_state;
+    libxl__domain_build_state *stubdom_state = &sdss->stubdom_state;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -692,6 +696,8 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
+    sdss->pvqemu.guest_domid = 0;
+
     libxl_domain_create_info_init(&dm_config->c_info);
     dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
@@ -739,10 +745,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
     if (ret)
         goto out;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
     ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
@@ -850,42 +856,67 @@ retry_transaction:
             goto out_free;
     }
 
-    if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 dm_config,
-                                 stubdom_state,
-                                 &dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-
-    libxl_domain_unpause(ctx, dm_domid);
+    sdss->pvqemu.guest_domid = dm_domid;
+    sdss->pvqemu.guest_config = &sdss->stubdom_config;
+    sdss->pvqemu.build_state = &sdss->stubdom_state;
+    sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
-    if (starting_r) {
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = guest_domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
-        (*starting_r)->for_spawn = NULL;
-    }
+    libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    ret = 0;
+    free(args);
+    return;
 
 out_free:
     free(args);
 out:
-    return ret;
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
 }
 
-int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__stubdom_spawn_state *sdss =
+        CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) goto out;
+
+    rc = libxl_domain_unpause(CTX, dm_domid);
+    if (rc) goto out;
+
+ out:
+    if (rc) {
+        if (dm_domid)
+            libxl_domain_destroy(CTX, dm_domid);
+    }
+    sdss->callback(egc, &sdss->stubdom, rc);
+}
+
+/* callbacks passed to libxl__spawn_spawn */
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata);
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn);
+
+/* our "next step" function, called from those callbacks and elsewhere */
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
+{
+    /* convenience aliases */
+    int domid = dmss->guest_domid;
+    libxl__domain_build_state *state = dmss->build_state;
+    libxl__spawn_state *spawn = &dmss->spawn;
+
+    STATE_AO_GC(dmss->spawn.ao);
+
+    libxl_ctx *ctx = CTX;
+    libxl_domain_config *guest_config = dmss->guest_config;
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
@@ -893,15 +924,13 @@ int libxl__create_device_model(libxl__gc *gc,
     int logfile_w, null;
     int rc;
     char **args, **arg;
-    libxl__spawner_starting buf_starting, *p;
     xs_transaction_t t;
     char *vm_path;
     char **pass_stuff;
     const char *dm;
 
     if (libxl_defbool_val(b_info->device_model_stubdomain)) {
-        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
-        goto out;
+        abort();
     }
 
     dm = libxl__domain_device_model(gc, b_info);
@@ -945,25 +974,8 @@ int libxl__create_device_model(libxl__gc *gc,
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
-    if (starting_r) {
-        rc = ERROR_NOMEM;
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        if (!*starting_r)
-            goto out_close;
-        p = *starting_r;
-        p->for_spawn = calloc(1, sizeof(libxl__spawn_starting));
-    } else {
-        p = &buf_starting;
-        p->for_spawn = NULL;
-    }
-
-    p->domid = domid;
-    p->dom_path = libxl__xs_get_dompath(gc, domid);
-    p->pid_path = "image/device-model-pid";
-    if (!p->dom_path) {
-        rc = ERROR_FAIL;
-        goto out_close;
-    }
+    const char *dom_path = libxl__xs_get_dompath(gc, domid);
+    spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid");
 
     if (vnc && vnc->passwd) {
         /* This xenstore key will only be used by qemu-xen-traditionnal.
@@ -971,7 +983,7 @@ int libxl__create_device_model(libxl__gc *gc,
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
-        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path));
+        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path));
         if (vm_path) {
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
@@ -988,8 +1000,15 @@ retry_transaction:
     for (arg = args; *arg; arg++)
         LIBXL__LOG(CTX, XTL_DEBUG, "  %s", *arg);
 
-    rc = libxl__spawn_spawn(gc, p->for_spawn, "device model",
-                            libxl_spawner_record_pid, p);
+    spawn->what = GCSPRINTF("domain %d device model", domid);
+    spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid);
+    spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+    spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
+    spawn->midproc_cb = libxl__spawn_record_pid;
+    spawn->confirm_cb = device_model_confirm;
+    spawn->failure_cb = device_model_startup_failed;
+
+    rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
     if (!rc) { /* inner child */
@@ -1004,30 +1023,61 @@ out_close:
     close(logfile_w);
     free(args);
 out:
-    return rc;
+    if (rc)
+        device_model_spawn_outcome(egc, dmss, rc);
+}
+
+
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    STATE_AO_GC(spawn->ao);
+
+    if (!xsdata)
+        return;
+
+    if (strcmp(xsdata, "running"))
+        return;
+
+    libxl__spawn_detach(gc, spawn);
+
+    device_model_spawn_outcome(egc, dmss, 0);
 }
 
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
+}
 
-int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl__domain_build_state *state,
-                                libxl__spawner_starting *starting)
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc)
 {
-    char *path;
-    int domid = starting->domid;
-    int ret, ret2;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    ret = libxl__spawn_confirm_offspring_startup(gc,
-                                     LIBXL_DEVICE_MODEL_START_TIMEOUT,
-                                     "Device Model", path, "running", starting);
+    STATE_AO_GC(dmss->spawn.ao);
+    int ret2;
+
+    if (rc)
+        LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc);
+
+    libxl__domain_build_state *state = dmss->build_state;
+
     if (state->saved_state) {
         ret2 = unlink(state->saved_state);
-        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
-                                   "failed to remove device-model state %s\n",
-                                   state->saved_state);
-        /* Do not clobber spawn_confirm error code with unlink error code. */
-        if (!ret) ret = ret2;
+        if (ret2) {
+            LOGE(ERROR, "%s: failed to remove device-model state %s",
+                 dmss->spawn.what, state->saved_state);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
-    return ret;
+
+    rc = 0;
+
+ out:
+    dmss->callback(egc, dmss, rc);
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
@@ -1123,15 +1173,6 @@ out:
     return ret;
 }
 
-int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                             libxl_domain_config *guest_config,
-                             libxl__domain_build_state *state,
-                             libxl__spawner_starting **starting_r)
-{
-    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 2ee2154..d44b702 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
+                            pid_t innerchild)
 {
-    libxl__spawner_starting *starting = for_spawn;
-    struct xs_handle *xsh;
-    char *path = NULL, *pid = NULL;
-    int len;
-
-    if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0)
-        goto out;
+    struct xs_handle *xsh = NULL;
+    const char *pid = NULL;
+    int rc, xsok;
 
-    len = asprintf(&pid, "%d", innerchild);
-    if (len < 0)
-        goto out;
+    pid = GCSPRINTF("%d", innerchild);
 
     /* we mustn't use the parent's handle in the child */
     xsh = xs_daemon_open();
+    if (!xsh) {
+        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
+             spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
 
-    xs_write(xsh, XBT_NULL, path, pid, len);
+    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
+    if (!xsok) {
+        LOGE(ERROR,
+             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    rc = 0;
 
-    xs_daemon_close(xsh);
 out:
-    free(path);
-    free(pid);
+    if (xsh) xs_daemon_close(xsh);
+    return rc ? SIGTERM : 0;
 }
 
 int libxl__wait_for_offspring(libxl__gc *gc,
@@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc,
     tv.tv_sec = timeout;
     tv.tv_usec = 0;
     nfds = xs_fileno(xsh) + 1;
-    if (spawning && spawning->fd > xs_fileno(xsh))
-        nfds = spawning->fd + 1;
+    assert(!spawning);
 
     while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        if ( spawning ) {
-            rc = libxl__spawn_check(gc, spawning);
-            if ( rc ) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "%s died during startup", what);
-                rc = -1;
-                goto err_died;
-            }
-        }
         p = xs_read(xsh, XBT_NULL, path, &len);
         if ( NULL == p )
             goto again;
@@ -218,8 +214,6 @@ again:
         free(p);
         FD_ZERO(&rfds);
         FD_SET(xs_fileno(xsh), &rfds);
-        if (spawning)
-            FD_SET(spawning->fd, &rfds);
         rc = select(nfds, &rfds, NULL, NULL, &tv);
         if (rc > 0) {
             if (FD_ISSET(xs_fileno(xsh), &rfds)) {
@@ -229,207 +223,215 @@ again:
                 else
                     goto again;
             }
-            if (spawning && FD_ISSET(spawning->fd, &rfds)) {
-                unsigned char dummy;
-                if (read(spawning->fd, &dummy, sizeof(dummy)) != 1)
-                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG,
-                                     "failed to read spawn status pipe");
-            }
         }
     }
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what);
-err_died:
+
     xs_unwatch(xsh, path, path);
     xs_daemon_close(xsh);
 err:
     return -1;
 }
 
-static int detach_offspring(libxl__gc *gc,
-                               libxl__spawner_starting *starting)
-{
-    int rc;
-    rc = libxl__spawn_detach(gc, starting->for_spawn);
-    if (starting->for_spawn)
-        free(starting->for_spawn);
-    free(starting);
-    return rc;
-}
 
-int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting)
-{
-    int detach;
-    int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what,
-                                               path, state,
-                                               starting->for_spawn, NULL, NULL);
-    detach = detach_offspring(gc, starting);
-    return problem ? problem : detach;
-}
+/*----- spawn implementation -----*/
 
-static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag)
-{
-    int flags;
+/*
+ * Full set of possible states of a libxl__spawn_state and its _detachable:
+ *
+ *               ss->        ss->        ss->    | ssd->       ssd->
+ *               timeout     xswatch     ssd     |  mid         ss
+ *  - Undefined   undef       undef       no     |  -           -
+ *  - Idle        Idle        Idle        no     |  -           -
+ *  - Active      Active      Active      yes    |  Active      yes
+ *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
+ *  - Detached    -           -           -      |  Active      no
+ *
+ * When in state Detached, the middle process has been sent a SIGKILL.
+ */
 
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1)
-        return ERROR_FAIL;
+/* Event callbacks. */
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path);
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs);
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status);
 
-    flags |= flag;
+/* Precondition: Partial.  Results: Detached. */
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-    if (fcntl(fd, F_SETFL, flags) == -1)
-        return ERROR_FAIL;
+/* Precondition: Partial; caller has logged failure reason.
+ * Results: Caller notified of failure;
+ *  after return, ss may be completely invalid as caller may reuse it */
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
 
-    return 0;
+void libxl__spawn_init(libxl__spawn_state *ss)
+{
+    libxl__ev_time_init(&ss->timeout);
+    libxl__ev_xswatch_init(&ss->xswatch);
+    ss->ssd = 0;
 }
 
-int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn,
-                                                pid_t innerchild),
-                      void *hook_data)
+int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    pid_t child, got;
+    STATE_AO_GC(ss->ao);
+    int r;
+    pid_t child;
     int status, rc;
-    pid_t intermediate;
-    int pipes[2];
-    unsigned char dummy = 0;
-
-    if (for_spawn) {
-        for_spawn->what = strdup(what);
-        if (!for_spawn->what) return ERROR_NOMEM;
-
-        if (libxl_pipe(ctx, pipes) < 0)
-            goto err_parent;
-        if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 ||
-            libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0)
-            goto err_parent_pipes;
-    }
 
-    intermediate = libxl_fork(ctx);
-    if (intermediate ==-1)
-        goto err_parent_pipes;
+    libxl__spawn_init(ss);
+    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    libxl__ev_child_init(&ss->ssd->mid);
+
+    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
+                                     spawn_timeout, ss->timeout_ms);
+    if (rc) goto out_err;
 
-    if (intermediate) {
+    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
+                                    spawn_watch_event, ss->xspath);
+    if (rc) goto out_err;
+
+    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
+
+    if (middle) {
         /* parent */
-        if (for_spawn) {
-            for_spawn->intermediate = intermediate;
-            for_spawn->fd = pipes[0];
-            close(pipes[1]);
-        }
         return 1;
     }
 
-    /* we are now the intermediate process */
-    if (for_spawn) close(pipes[0]);
+    /* we are now the middle process */
 
     child = fork();
     if (child == -1)
         exit(255);
     if (!child) {
-        if (for_spawn) close(pipes[1]);
         return 0; /* caller runs child code */
     }
 
-    intermediate_hook(hook_data, child);
-
-    if (!for_spawn) _exit(0); /* just detach then */
-
-    got = waitpid(child, &status, 0);
-    assert(got == child);
-
-    rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
-          WIFSIGNALED(status) && WTERMSIG(status) < 127
-          ? WTERMSIG(status)+128 : -1);
-    if (for_spawn) {
-        if (write(pipes[1], &dummy, sizeof(dummy)) != 1)
-            perror("libxl__spawn_spawn: unable to signal child exit to parent");
+    int failsig = ss->midproc_cb(gc, ss, middle);
+    if (failsig) {
+        kill(child, failsig);
+        _exit(127);
     }
-    _exit(rc);
 
- err_parent_pipes:
-    if (for_spawn) {
-        close(pipes[0]);
-        close(pipes[1]);
+    for (;;) {
+        pid_t got = waitpid(child, &status, 0);
+        if (got == -1) {
+            assert(errno == EINTR);
+            continue;
+        }
+        assert(got == child);
+        break;
     }
 
- err_parent:
-    if (for_spawn) free(for_spawn->what);
+    r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) :
+         WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 :
+         -1);
+    _exit(r);
 
-    return ERROR_FAIL;
+ out_err:
+    spawn_cleanup(gc, ss);
+    return rc;
 }
 
-static void report_spawn_intermediate_status(libxl__gc *gc,
-                                             libxl__spawn_starting *for_spawn,
-                                             int status)
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
-    if (!WIFEXITED(status)) {
-        libxl_ctx *ctx = libxl__gc_owner(gc);
-        char *intermediate_what;
-        /* intermediate process did the logging itself if it exited */
-        if ( asprintf(&intermediate_what,
-                 "%s intermediate process (startup monitor)",
-                 for_spawn->what) < 0 )
-            intermediate_what = "intermediate process (startup monitor)";
-        libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what,
-                                      for_spawn->intermediate, status);
+    int r;
+
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+
+    libxl__spawn_state_detachable *ssd = ss->ssd;
+    if (ssd) {
+        if (libxl__ev_child_inuse(&ssd->mid)) {
+            pid_t child = ssd->mid.pid;
+            r = kill(child, SIGKILL);
+            if (r && errno != ESRCH)
+                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+                     ss->what, (unsigned long)child);
+        }
+
+        /* disconnect the ss and ssd from each other */
+        ssd->ss = 0;
+        ss->ssd = 0;
     }
 }
 
-int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn)
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int r, status;
-    pid_t got;
-    int rc = 0;
+    EGC_GC;
+    spawn_cleanup(gc, ss);
+    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+}
 
-    if (!for_spawn) return 0;
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs)
+{
+    /* Before event, was Active; is now Partial. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
+    LOG(ERROR, "%s: startup timed out", ss->what);
+    spawn_failed(egc, ss); /* must be last */
+}
 
-    if (for_spawn->intermediate) {
-        r = kill(for_spawn->intermediate, SIGKILL);
-        if (r) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                         "could not kill %s intermediate process [%ld]",
-                         for_spawn->what,
-                         (unsigned long)for_spawn->intermediate);
-            abort(); /* things are very wrong */
-        }
-        got = waitpid(for_spawn->intermediate, &status, 0);
-        assert(got == for_spawn->intermediate);
-        if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
-            report_spawn_intermediate_status(gc, for_spawn, status);
-            rc = ERROR_FAIL;
-        }
-        for_spawn->intermediate = 0;
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path)
+{
+    /* On entry, is Active. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
+    char *p = libxl__xs_read(gc, 0, ss->xspath);
+    if (!p && errno != ENOENT) {
+        LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
+        spawn_failed(egc, ss); /* must be last */
+        return;
     }
-
-    free(for_spawn->what);
-    for_spawn->what = 0;
-
-    return rc;
+    ss->confirm_cb(egc, ss, p); /* must be last */
 }
 
-int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status)
+    /* Before event, was Active or Detached;
+     * is now Active or Detached except that ssd->mid is Idle */
 {
-    pid_t got;
-    int status;
-
-    if (!for_spawn) return 0;
+    EGC_GC;
+    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
+    libxl__spawn_state *ss = ssd->ss;
 
-    assert(for_spawn->intermediate);
-    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
-    if (!got) return 0;
-
-    assert(got == for_spawn->intermediate);
-    report_spawn_intermediate_status(gc, for_spawn, status);
+    if (!WIFEXITED(status)) {
+        const char *what =
+            GCSPRINTF("%s intermediate process (startup monitor)",
+                      ss ? ss->what : "(detached)");
+        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+        libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
+    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        if (!status)
+            LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
+                " when we were waiting for it to confirm startup",
+                ss->what, (unsigned long)pid);
+        else if (status <= 127)
+            LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d",
+                ss->what, (unsigned long)pid, status);
+        else if (status < 255) {
+            int sig = status - 128;
+            const char *str = strsignal(sig);
+            if (str)
+                LOG(ERROR, "%s [%ld]: died during startup due to fatal"
+                    " signal %s", ss->what, (unsigned long)pid, str);
+            else
+                LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
+                    " signal number %d", ss->what, (unsigned long)pid, sig);
+        }
+        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
+        spawn_failed(egc, ss); /* must be last use of ss */
+    }
+    free(ssd);
+}
 
-    for_spawn->intermediate = 0;
-    return ERROR_FAIL;
+void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    spawn_cleanup(gc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ae71f70..5bab4d6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -840,75 +840,197 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                                       libxl_device_pci *pcidev, int num);
 _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
 
-/* xl_exec */
+/*
+ *----- spawn -----
+ *
+ * Higher-level double-fork and separate detach eg as for device models
+ *
+ * Each libxl__spawn_state is in one of the conventional states
+ *    Undefined, Idle, Active
+ */
 
- /* higher-level double-fork and separate detach eg as for device models */
+typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
+/* this type is never defined, so no objects of this type exist
+ * fixme-ao  This should go away completely.  */
 
-typedef struct {
-    /* put this in your own status structure as returned to application */
-    /* all fields are private to libxl_spawn_... */
-    pid_t intermediate;
-    int fd;
-    char *what; /* malloc'd in spawn_spawn */
-} libxl__spawn_starting;
+typedef struct libxl__spawn_state libxl__spawn_state;
 
-typedef struct {
-    char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */
-    const char *pid_path; /* only for libxl_spawner_record_pid */
-    int domid;
-    libxl__spawn_starting *for_spawn;
-} libxl__spawner_starting;
+/* Clears out a spawn state; idempotent. */
+_hidden void libxl__spawn_init(libxl__spawn_state*);
 
 /*
- * libxl__spawn_spawn - Create a new process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * what: string describing the spawned process
- * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
- * hook_data: data to pass to the hook function
+ * libxl__spawn_spawn - Create a new process which will become daemonic
+ * Forks twice, to allow the child to detach entirely from the parent.
+ *
+ * We call the two generated processes the "middle child" (result of
+ * the first fork) and the "inner child" (result of the second fork
+ * which takes place in the middle child).
+ *
+ * The inner child must soon exit or exec.  If must also soon exit or
+ * notify the parent of its successful startup by writing to the
+ * xenstore path xspath (or by other means).  xspath may be 0 to
+ * indicate that only other means are being used.
+ *
+ * The user (in the parent) will be called back (confirm_cb) every
+ * time that xenstore path is modified.
+ *
+ * In both children, the ctx is not fully useable: gc and logging
+ * operations are OK, but operations on Xen and xenstore are not.
+ * (The restrictions are the same as those which apply to children
+ * made with libxl__ev_child_fork.)
+ *
+ * midproc_cb will be called in the middle child, with the pid of the
+ * inner child; this could for example record the pid.  midproc_cb
+ * should be fast, and should return.  It will be called (reentrantly)
+ * within libxl__spawn_init.
+ *
+ * failure_cb will be called in the parent on failure of the
+ * intermediate or final child; an error message will have been
+ * logged.
+ *
+ * confirm_cb and failure_cb will not be called reentrantly from
+ * within libxl__spawn_spawn.
+ *
+ * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
- *  < 0   error, for_spawn need not be detached
- *   +1   caller is the parent, must call detach on *for_spawn eventually
+ *  < 0   error, *spawn is now Idle and need not be detached
+ *   +1   caller is the parent, *spawn is Active and must eventually be detached
  *    0   caller is now the inner child, should probably call libxl__exec
- * Caller, may pass 0 for for_spawn, in which case no need to detach.
+ *
+ * The spawn state must be Undefined or Idle on entry.
  */
-_hidden int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
-                      void *hook_data);
+_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl_spawner_record_pid - Record given pid in xenstore
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * innerchild: pid of the child
+ * libxl__spawn_detach - Detaches the daemonic child.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, failures of either child are no
+ * longer repaorted via failure_cb.
+ *
+ * If called before the inner child has been created, this may prevent
+ * it from running at all.  Thus this should be called only when the
+ * inner child has notified that it is ready.  Normally it will be
+ * called from within confirm_cb.
  *
- * This function is passed as intermediate_hook to libxl__spawn_spawn.
+ * Logs errors.
+ *
+ * The spawn state must be Active or Idle on entry and will be Idle
+ * on return.
  */
-_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild);
+_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
- * libxl__spawn_confirm_offspring_startup - Wait for child state
- * gc: allocation pool
- * timeout: how many seconds to wait for the child
- * what: string describing the spawned process
- * path: path to the state file in xenstore
- * state: expected string to wait for in path (optional)
- * starting: malloc'd pointer to libxl__spawner_starting
+ * If successful, this should return 0.
  *
- * Returns 0 on success, and < 0 on error.
+ * Otherwise it should return a signal number, which will be
+ * sent to the inner child; the overall spawn will then fail.
+ */
+typedef int /* signal number */
+libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner);
+
+/*
+ * Called if the spawn failed.  The reason will have been logged.
+ * The spawn state will be Idle on entry to the callback (and
+ * it may be reused immediately if desired).
+ */
+typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
+
+/*
+ * Called when the xspath watch triggers.  xspath will have been read
+ * and the result placed in xsdata; if that failed because the key
+ * didn't exist, xspath==0.  (If it failed for some other reason,
+ * the spawn machinery calls failure_cb instead.)
  *
- * This function waits the given timeout for the given path to appear
- * in xenstore, and optionally for state in path.
- * The intermediate process created in libxl__spawn_spawn is killed.
- * The memory referenced by starting->for_spawn and starting is free'd.
+ * If the child has indicated its successful startup, or a failure
+ * has occurred, this should call libxl__spawn_detach.
+ *
+ * If the child is still starting up, should simply return, doing
+ * nothing.
+ *
+ * The spawn state will be Active on entry to the callback; there
+ * are no restrictions on the state on return; it may even have
+ * been detached and reused.
+ */
+typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
+                                     const char *xsdata);
+
+typedef struct {
+    /* Private to the spawn implementation.
+     */
+    /* This separate struct, from malloc, allows us to "detach"
+     * the child and reap it later, when our user has gone
+     * away and freed its libxl__spawn_state */
+    struct libxl__spawn_state *ss;
+    libxl__ev_child mid;
+} libxl__spawn_state_detachable;
+
+struct libxl__spawn_state {
+    /* must be filled in by user and remain valid */
+    libxl__ao *ao;
+    const char *what;
+    const char *xspath;
+    const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */
+    int timeout_ms; /* -1 means forever */
+    libxl__spawn_midproc_cb *midproc_cb;
+    libxl__spawn_failure_cb *failure_cb;
+    libxl__spawn_confirm_cb *confirm_cb;
+
+    /* remaining fields are private to libxl_spawn_... */
+    libxl__ev_time timeout;
+    libxl__ev_xswatch xswatch;
+    libxl__spawn_state_detachable *ssd;
+};
+
+static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
+    { return !!ss->ssd; }
+
+/*
+ * libxl_spawner_record_pid - Record given pid in xenstore
+ *
+ * This function can be passed directly as an intermediate_hook to
+ * libxl__spawn_spawn.  On failure, returns the value SIGTERM.
  */
-_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting);
+_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
+                                    pid_t innerchild);
+
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdoms. */
+
+typedef struct {
+    /* mixed - user must fill in public parts only: */
+    libxl__dm_spawn_state stubdom; /* will always remain the first member */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->stubdom,) */
+    /* private to libxl__spawn_stubdom: */
+    libxl_domain_config stubdom_config;
+    libxl__domain_build_state stubdom_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stubdom_spawn_state;
+
+_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
+
 
 /*
  * libxl__wait_for_offspring - Wait for child state
@@ -941,31 +1063,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
                                                        void *userdata),
                                  void *check_callback_userdata);
 
-/*
- * libxl__spawn_detach - Kill intermediate process from spawn_spawn
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors.  Idempotent, but only permitted after successful
- * call to libxl__spawn_spawn, and no point calling it again if it fails.
- */
-_hidden int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
-
-/*
- * libxl__spawn_check - Check intermediate child process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors but also returns them.
- * Caller must still call detach.
- */
-_hidden int libxl__spawn_check(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
@@ -984,15 +1081,6 @@ _hidden int libxl__domain_build(libxl__gc *gc,
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
-_hidden int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
-_hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1000,10 +1088,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
   /* Caller must either: pass starting_r==0, or on successful
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
-_hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting *starting);
-_hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,
                                 uint32_t domid, char *state,
                                 libxl__spawn_starting *spawning,
@@ -1566,6 +1650,32 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
 
+/*----- Domain creation -----*/
+
+typedef struct libxl__domain_create_state libxl__domain_create_state;
+
+typedef void libxl__domain_create_cb(libxl__egc *egc,
+                                     libxl__domain_create_state*,
+                                     int rc, uint32_t domid);
+
+struct libxl__domain_create_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl_domain_config *guest_config;
+    int restore_fd;
+    libxl_console_ready console_cb;
+    void *console_cb_priv;
+    libxl__domain_create_cb *callback;
+    /* private to domain_create */
+    int guest_domid;
+    libxl__domain_build_state build_state;
+    union {
+        libxl__dm_spawn_state dmss;
+        libxl__stubdom_spawn_state sdss;
+    };
+};
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..9e66536 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1668,8 +1668,8 @@ start:
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                            cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                          cb, &child_console_pid,
+                                          &domid, restore_fd, 0);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1677,7 +1677,7 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                      cb, &child_console_pid, &domid, 0);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZC-0003lG-LH; Mon, 16 Apr 2012 17:18:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003g3-VJ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [193.109.254.147:55490] by server-2.bemta-14.messagelabs.com id
	1E/E0-19409-5545C8F4; Mon, 16 Apr 2012 17:18:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18088 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kX-Gr; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002ER-G3;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:55 +0100
Message-ID: <1334596686-8479-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/24] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 734a5dc..91e34de 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index bdc4cb4..1534bae 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -236,6 +236,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -258,6 +262,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -269,6 +275,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -308,6 +330,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
  out:
     assert(rc);
  out_ok:
+    free(logfile_tmp);
     bootloader_callback(egc, bl, rc);
 }
 
@@ -465,6 +488,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b3f84ba..4cfb8d5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1488,6 +1488,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1550,7 +1551,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZG-0003pr-CC; Mon, 16 Apr 2012 17:18:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003fl-KF
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:16 +0000
Received: from [85.158.139.83:5762] by server-9.bemta-5.messagelabs.com id
	F5/7C-09826-7545C8F4; Mon, 16 Apr 2012 17:18:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8882 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kd-Ja; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Eg-IL;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:59 +0100
Message-ID: <1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn becomes a callback-style asynchronous function.
The implementation is now in terms of libxl__ev_* including
libxl_ev_child.

All the callers need to be updated.  This includes the device model
spawning functions libxl__create_device_model and
libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
abolished; instead the dm spawner calls back.

(The choice of which kind of device model to create is lifted out of
what used to be libxl__create_device_model, because that function was
indirectly recursive.  Recursive callback-style operations are clumsy
because they require a pointer indirection for the nested states.)

Waiting for proper device model startup it is no longer notionally
optional.  Previously the code appeared to tolerate this by passing
NULL for various libxl__spawner_starting* parameters to device model
spawners.  However, this was not used anywhere.

Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
no longer supported.  It remains as an unused formal parameter to
avoid updating, in this patch, all the call sites which pass NULL.
libxl__wait_for_offspring is in any case itself an obsolete function,
so this wrinkle will go away when its callers are updated to use the
event system.  Consequently libxl__spawn_check is also abolished.

The "console ready" callback also remains unchanged in this patch.
The API for this needs to be reviewed in the context of the event
series and its reentrancy restrictions documented.

Thus their callers need to be updated.  These are the domain creation
functions libxl_domain_create_new and _restore.  These functions now
take ao_hows, and have a private state structure.

However domain creation remains not completely converted to the event
mechanism; in particular it runs the outward-facing function
libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
happens in the current code this is not a bug because none of the rest
of the functionality surrounding the bootloader call will mind if the
event loop is reentered in the middle of its execution.

The file-scope function libxl__set_fd_flag which was used by the
previous spawn arrangements becomes unused and is removed; other
places in libxl can use libxl_fd_set_nonblock and
libxl_fd_set_cloexec, which of course remain.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   14 ++-
 tools/libxl/libxl_create.c   |  198 +++++++++++++++++++-----
 tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
 tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
 tools/libxl/xl_cmdimpl.c     |    6 +-
 6 files changed, 677 insertions(+), 400 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 477b72a..6f59364 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
+   * properties need to be documented but they may turn out to be too
+   * awkward */
+
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            const libxl_asyncop_how *ao_how);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how);
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8408c26..09a03a7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -537,16 +537,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
-static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+/*----- main domain creation -----*/
+
+/* We have a linear control flow; only one event callback is
+ * outstanding at any time.  Each initiation and callback function
+ * arranges for the next to be called, as the very last thing it
+ * does.  (If that particular sub-operation is not needed, a
+ * function will call the next event callback directly.)
+ */
+
+/* Event callbacks, in this order: */
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+/* Our own function to clean up and call the user's callback.
+ * The final call in the sequence. */
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc);
+
+static void initiate_domain_create(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs)
 {
+    STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
     domid = 0;
 
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
@@ -559,9 +583,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
+    dcs->guest_domid = domid;
+    dcs->dmss.guest_domid = 0; /* means we haven't spawned */
+
     if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
@@ -585,7 +612,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(state, 0, sizeof(*state));
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+    libxl__domain_build_state *state = &dcs->build_state;
+    dcs->dmss.spawn.ao = ao;
+    dcs->dmss.guest_config = dcs->guest_config;
+    dcs->dmss.build_state = &dcs->build_state;
+    dcs->dmss.callback = domcreate_devmodel_started;
 
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
@@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        ret = libxl__create_device_model(gc, domid, d_config,
-                                         state, &dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to create device model: %d", ret);
-            goto error_out;
-        }
+        dcs->dmss.guest_domid = domid;
+        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
+            libxl__spawn_stubdom(egc, &dcs->sdss);
+        else
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+        return;
+
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
@@ -669,7 +701,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
+            dcs->dmss.guest_domid = domid;
+            libxl__spawn_local_dm(egc, &dcs->dmss);
+            return;
         }
         break;
     }
@@ -678,17 +712,41 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
-    if (dm_starting) {
+    assert(!dcs->dmss.guest_domid);
+    domcreate_devmodel_started(egc, &dcs->dmss, 0);
+    return;
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss);
+    STATE_AO_GC(dmss->spawn.ao);
+    int i;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *d_config = dcs->guest_config;
+    libxl_console_ready cb = dcs->console_cb;
+    void *priv = dcs->console_cb_priv;
+
+    if (ret) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "device model did not start: %d", ret);
+        goto error_out;
+    }
+
+    if (dcs->dmss.guest_domid) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "device model did not start: %d", ret);
-            goto error_out;
-        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
@@ -716,38 +774,94 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
-    *domid_out = domid;
-    return 0;
+    domcreate_complete(egc, dcs, 0);
+    return;
 
 error_out:
-    if (domid)
-        libxl_domain_destroy(ctx, domid);
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
 
-    return ret;
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc) {
+    STATE_AO_GC(dcs->ao);
+
+    if (rc) {
+        if (dcs->guest_domid) {
+            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
+            if (rc2)
+                LOG(ERROR, "unable to destroy domain %d following"
+                    " failed creation", dcs->guest_domid);
+        }
+        dcs->guest_domid = -1;
+    }
+    dcs->callback(egc, dcs, rc, dcs->guest_domid);
+}
+
+/*----- application-facing domain creation interface -----*/
+
+typedef struct {
+    libxl__domain_create_state dcs;
+    uint32_t *domid_out;
+} libxl__app_domain_create_state;
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid);
+
+static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, 0, ao_how);
+    libxl__app_domain_create_state *cdcs;
+
+    GCNEW(cdcs);
+    cdcs->dcs.ao = ao;
+    cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.console_cb = cb;
+    cdcs->dcs.console_cb_priv = priv;
+    cdcs->dcs.callback = domain_create_cb;
+    cdcs->domid_out = domid;
+
+    initiate_domain_create(egc, &cdcs->dcs);
+
+    return AO_INPROGRESS;
 }
 
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid)
+{
+    libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs);
+    STATE_AO_GC(cdcs->dcs.ao);
+
+    if (!rc)
+        *cdcs->domid_out = domid;
+
+    libxl__ao_complete(egc, ao, rc);
+}
+    
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv,
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3921e2a..15472a8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -667,24 +667,28 @@ retry_transaction:
     return 0;
 }
 
-static int libxl__create_stubdom(libxl__gc *gc,
-                                 int guest_domid,
-                                 libxl_domain_config *guest_config,
-                                 libxl__domain_build_state *d_state,
-                                 libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc);
+
+void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state *sdss)
 {
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state[1];
-    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
-    libxl__spawner_starting *dm_starting = 0;
+
+    /* convenience aliases */
+    libxl_domain_config *dm_config = &sdss->stubdom_config;
+    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
+    int guest_domid = sdss->stubdom.guest_domid;
+    libxl__domain_build_state *d_state = sdss->stubdom.build_state;
+    libxl__domain_build_state *stubdom_state = &sdss->stubdom_state;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -692,6 +696,8 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
+    sdss->pvqemu.guest_domid = 0;
+
     libxl_domain_create_info_init(&dm_config->c_info);
     dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
@@ -739,10 +745,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
     if (ret)
         goto out;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
     ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
@@ -850,42 +856,67 @@ retry_transaction:
             goto out_free;
     }
 
-    if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 dm_config,
-                                 stubdom_state,
-                                 &dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-
-    libxl_domain_unpause(ctx, dm_domid);
+    sdss->pvqemu.guest_domid = dm_domid;
+    sdss->pvqemu.guest_config = &sdss->stubdom_config;
+    sdss->pvqemu.build_state = &sdss->stubdom_state;
+    sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
-    if (starting_r) {
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = guest_domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
-        (*starting_r)->for_spawn = NULL;
-    }
+    libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    ret = 0;
+    free(args);
+    return;
 
 out_free:
     free(args);
 out:
-    return ret;
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
 }
 
-int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__stubdom_spawn_state *sdss =
+        CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
+    STATE_AO_GC(sdss->stubdom.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) goto out;
+
+    rc = libxl_domain_unpause(CTX, dm_domid);
+    if (rc) goto out;
+
+ out:
+    if (rc) {
+        if (dm_domid)
+            libxl_domain_destroy(CTX, dm_domid);
+    }
+    sdss->callback(egc, &sdss->stubdom, rc);
+}
+
+/* callbacks passed to libxl__spawn_spawn */
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata);
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn);
+
+/* our "next step" function, called from those callbacks and elsewhere */
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
+{
+    /* convenience aliases */
+    int domid = dmss->guest_domid;
+    libxl__domain_build_state *state = dmss->build_state;
+    libxl__spawn_state *spawn = &dmss->spawn;
+
+    STATE_AO_GC(dmss->spawn.ao);
+
+    libxl_ctx *ctx = CTX;
+    libxl_domain_config *guest_config = dmss->guest_config;
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
@@ -893,15 +924,13 @@ int libxl__create_device_model(libxl__gc *gc,
     int logfile_w, null;
     int rc;
     char **args, **arg;
-    libxl__spawner_starting buf_starting, *p;
     xs_transaction_t t;
     char *vm_path;
     char **pass_stuff;
     const char *dm;
 
     if (libxl_defbool_val(b_info->device_model_stubdomain)) {
-        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
-        goto out;
+        abort();
     }
 
     dm = libxl__domain_device_model(gc, b_info);
@@ -945,25 +974,8 @@ int libxl__create_device_model(libxl__gc *gc,
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
-    if (starting_r) {
-        rc = ERROR_NOMEM;
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        if (!*starting_r)
-            goto out_close;
-        p = *starting_r;
-        p->for_spawn = calloc(1, sizeof(libxl__spawn_starting));
-    } else {
-        p = &buf_starting;
-        p->for_spawn = NULL;
-    }
-
-    p->domid = domid;
-    p->dom_path = libxl__xs_get_dompath(gc, domid);
-    p->pid_path = "image/device-model-pid";
-    if (!p->dom_path) {
-        rc = ERROR_FAIL;
-        goto out_close;
-    }
+    const char *dom_path = libxl__xs_get_dompath(gc, domid);
+    spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid");
 
     if (vnc && vnc->passwd) {
         /* This xenstore key will only be used by qemu-xen-traditionnal.
@@ -971,7 +983,7 @@ int libxl__create_device_model(libxl__gc *gc,
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
-        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path));
+        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path));
         if (vm_path) {
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
@@ -988,8 +1000,15 @@ retry_transaction:
     for (arg = args; *arg; arg++)
         LIBXL__LOG(CTX, XTL_DEBUG, "  %s", *arg);
 
-    rc = libxl__spawn_spawn(gc, p->for_spawn, "device model",
-                            libxl_spawner_record_pid, p);
+    spawn->what = GCSPRINTF("domain %d device model", domid);
+    spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid);
+    spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+    spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
+    spawn->midproc_cb = libxl__spawn_record_pid;
+    spawn->confirm_cb = device_model_confirm;
+    spawn->failure_cb = device_model_startup_failed;
+
+    rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
     if (!rc) { /* inner child */
@@ -1004,30 +1023,61 @@ out_close:
     close(logfile_w);
     free(args);
 out:
-    return rc;
+    if (rc)
+        device_model_spawn_outcome(egc, dmss, rc);
+}
+
+
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    STATE_AO_GC(spawn->ao);
+
+    if (!xsdata)
+        return;
+
+    if (strcmp(xsdata, "running"))
+        return;
+
+    libxl__spawn_detach(gc, spawn);
+
+    device_model_spawn_outcome(egc, dmss, 0);
 }
 
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
+}
 
-int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl__domain_build_state *state,
-                                libxl__spawner_starting *starting)
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc)
 {
-    char *path;
-    int domid = starting->domid;
-    int ret, ret2;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    ret = libxl__spawn_confirm_offspring_startup(gc,
-                                     LIBXL_DEVICE_MODEL_START_TIMEOUT,
-                                     "Device Model", path, "running", starting);
+    STATE_AO_GC(dmss->spawn.ao);
+    int ret2;
+
+    if (rc)
+        LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc);
+
+    libxl__domain_build_state *state = dmss->build_state;
+
     if (state->saved_state) {
         ret2 = unlink(state->saved_state);
-        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
-                                   "failed to remove device-model state %s\n",
-                                   state->saved_state);
-        /* Do not clobber spawn_confirm error code with unlink error code. */
-        if (!ret) ret = ret2;
+        if (ret2) {
+            LOGE(ERROR, "%s: failed to remove device-model state %s",
+                 dmss->spawn.what, state->saved_state);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
-    return ret;
+
+    rc = 0;
+
+ out:
+    dmss->callback(egc, dmss, rc);
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
@@ -1123,15 +1173,6 @@ out:
     return ret;
 }
 
-int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                             libxl_domain_config *guest_config,
-                             libxl__domain_build_state *state,
-                             libxl__spawner_starting **starting_r)
-{
-    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 2ee2154..d44b702 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
+                            pid_t innerchild)
 {
-    libxl__spawner_starting *starting = for_spawn;
-    struct xs_handle *xsh;
-    char *path = NULL, *pid = NULL;
-    int len;
-
-    if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0)
-        goto out;
+    struct xs_handle *xsh = NULL;
+    const char *pid = NULL;
+    int rc, xsok;
 
-    len = asprintf(&pid, "%d", innerchild);
-    if (len < 0)
-        goto out;
+    pid = GCSPRINTF("%d", innerchild);
 
     /* we mustn't use the parent's handle in the child */
     xsh = xs_daemon_open();
+    if (!xsh) {
+        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
+             spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
 
-    xs_write(xsh, XBT_NULL, path, pid, len);
+    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
+    if (!xsok) {
+        LOGE(ERROR,
+             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    rc = 0;
 
-    xs_daemon_close(xsh);
 out:
-    free(path);
-    free(pid);
+    if (xsh) xs_daemon_close(xsh);
+    return rc ? SIGTERM : 0;
 }
 
 int libxl__wait_for_offspring(libxl__gc *gc,
@@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc,
     tv.tv_sec = timeout;
     tv.tv_usec = 0;
     nfds = xs_fileno(xsh) + 1;
-    if (spawning && spawning->fd > xs_fileno(xsh))
-        nfds = spawning->fd + 1;
+    assert(!spawning);
 
     while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        if ( spawning ) {
-            rc = libxl__spawn_check(gc, spawning);
-            if ( rc ) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "%s died during startup", what);
-                rc = -1;
-                goto err_died;
-            }
-        }
         p = xs_read(xsh, XBT_NULL, path, &len);
         if ( NULL == p )
             goto again;
@@ -218,8 +214,6 @@ again:
         free(p);
         FD_ZERO(&rfds);
         FD_SET(xs_fileno(xsh), &rfds);
-        if (spawning)
-            FD_SET(spawning->fd, &rfds);
         rc = select(nfds, &rfds, NULL, NULL, &tv);
         if (rc > 0) {
             if (FD_ISSET(xs_fileno(xsh), &rfds)) {
@@ -229,207 +223,215 @@ again:
                 else
                     goto again;
             }
-            if (spawning && FD_ISSET(spawning->fd, &rfds)) {
-                unsigned char dummy;
-                if (read(spawning->fd, &dummy, sizeof(dummy)) != 1)
-                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG,
-                                     "failed to read spawn status pipe");
-            }
         }
     }
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what);
-err_died:
+
     xs_unwatch(xsh, path, path);
     xs_daemon_close(xsh);
 err:
     return -1;
 }
 
-static int detach_offspring(libxl__gc *gc,
-                               libxl__spawner_starting *starting)
-{
-    int rc;
-    rc = libxl__spawn_detach(gc, starting->for_spawn);
-    if (starting->for_spawn)
-        free(starting->for_spawn);
-    free(starting);
-    return rc;
-}
 
-int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting)
-{
-    int detach;
-    int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what,
-                                               path, state,
-                                               starting->for_spawn, NULL, NULL);
-    detach = detach_offspring(gc, starting);
-    return problem ? problem : detach;
-}
+/*----- spawn implementation -----*/
 
-static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag)
-{
-    int flags;
+/*
+ * Full set of possible states of a libxl__spawn_state and its _detachable:
+ *
+ *               ss->        ss->        ss->    | ssd->       ssd->
+ *               timeout     xswatch     ssd     |  mid         ss
+ *  - Undefined   undef       undef       no     |  -           -
+ *  - Idle        Idle        Idle        no     |  -           -
+ *  - Active      Active      Active      yes    |  Active      yes
+ *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
+ *  - Detached    -           -           -      |  Active      no
+ *
+ * When in state Detached, the middle process has been sent a SIGKILL.
+ */
 
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1)
-        return ERROR_FAIL;
+/* Event callbacks. */
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path);
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs);
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status);
 
-    flags |= flag;
+/* Precondition: Partial.  Results: Detached. */
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-    if (fcntl(fd, F_SETFL, flags) == -1)
-        return ERROR_FAIL;
+/* Precondition: Partial; caller has logged failure reason.
+ * Results: Caller notified of failure;
+ *  after return, ss may be completely invalid as caller may reuse it */
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
 
-    return 0;
+void libxl__spawn_init(libxl__spawn_state *ss)
+{
+    libxl__ev_time_init(&ss->timeout);
+    libxl__ev_xswatch_init(&ss->xswatch);
+    ss->ssd = 0;
 }
 
-int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn,
-                                                pid_t innerchild),
-                      void *hook_data)
+int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    pid_t child, got;
+    STATE_AO_GC(ss->ao);
+    int r;
+    pid_t child;
     int status, rc;
-    pid_t intermediate;
-    int pipes[2];
-    unsigned char dummy = 0;
-
-    if (for_spawn) {
-        for_spawn->what = strdup(what);
-        if (!for_spawn->what) return ERROR_NOMEM;
-
-        if (libxl_pipe(ctx, pipes) < 0)
-            goto err_parent;
-        if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 ||
-            libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0)
-            goto err_parent_pipes;
-    }
 
-    intermediate = libxl_fork(ctx);
-    if (intermediate ==-1)
-        goto err_parent_pipes;
+    libxl__spawn_init(ss);
+    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    libxl__ev_child_init(&ss->ssd->mid);
+
+    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
+                                     spawn_timeout, ss->timeout_ms);
+    if (rc) goto out_err;
 
-    if (intermediate) {
+    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
+                                    spawn_watch_event, ss->xspath);
+    if (rc) goto out_err;
+
+    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
+
+    if (middle) {
         /* parent */
-        if (for_spawn) {
-            for_spawn->intermediate = intermediate;
-            for_spawn->fd = pipes[0];
-            close(pipes[1]);
-        }
         return 1;
     }
 
-    /* we are now the intermediate process */
-    if (for_spawn) close(pipes[0]);
+    /* we are now the middle process */
 
     child = fork();
     if (child == -1)
         exit(255);
     if (!child) {
-        if (for_spawn) close(pipes[1]);
         return 0; /* caller runs child code */
     }
 
-    intermediate_hook(hook_data, child);
-
-    if (!for_spawn) _exit(0); /* just detach then */
-
-    got = waitpid(child, &status, 0);
-    assert(got == child);
-
-    rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
-          WIFSIGNALED(status) && WTERMSIG(status) < 127
-          ? WTERMSIG(status)+128 : -1);
-    if (for_spawn) {
-        if (write(pipes[1], &dummy, sizeof(dummy)) != 1)
-            perror("libxl__spawn_spawn: unable to signal child exit to parent");
+    int failsig = ss->midproc_cb(gc, ss, middle);
+    if (failsig) {
+        kill(child, failsig);
+        _exit(127);
     }
-    _exit(rc);
 
- err_parent_pipes:
-    if (for_spawn) {
-        close(pipes[0]);
-        close(pipes[1]);
+    for (;;) {
+        pid_t got = waitpid(child, &status, 0);
+        if (got == -1) {
+            assert(errno == EINTR);
+            continue;
+        }
+        assert(got == child);
+        break;
     }
 
- err_parent:
-    if (for_spawn) free(for_spawn->what);
+    r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) :
+         WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 :
+         -1);
+    _exit(r);
 
-    return ERROR_FAIL;
+ out_err:
+    spawn_cleanup(gc, ss);
+    return rc;
 }
 
-static void report_spawn_intermediate_status(libxl__gc *gc,
-                                             libxl__spawn_starting *for_spawn,
-                                             int status)
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
-    if (!WIFEXITED(status)) {
-        libxl_ctx *ctx = libxl__gc_owner(gc);
-        char *intermediate_what;
-        /* intermediate process did the logging itself if it exited */
-        if ( asprintf(&intermediate_what,
-                 "%s intermediate process (startup monitor)",
-                 for_spawn->what) < 0 )
-            intermediate_what = "intermediate process (startup monitor)";
-        libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what,
-                                      for_spawn->intermediate, status);
+    int r;
+
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+
+    libxl__spawn_state_detachable *ssd = ss->ssd;
+    if (ssd) {
+        if (libxl__ev_child_inuse(&ssd->mid)) {
+            pid_t child = ssd->mid.pid;
+            r = kill(child, SIGKILL);
+            if (r && errno != ESRCH)
+                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+                     ss->what, (unsigned long)child);
+        }
+
+        /* disconnect the ss and ssd from each other */
+        ssd->ss = 0;
+        ss->ssd = 0;
     }
 }
 
-int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn)
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int r, status;
-    pid_t got;
-    int rc = 0;
+    EGC_GC;
+    spawn_cleanup(gc, ss);
+    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+}
 
-    if (!for_spawn) return 0;
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs)
+{
+    /* Before event, was Active; is now Partial. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
+    LOG(ERROR, "%s: startup timed out", ss->what);
+    spawn_failed(egc, ss); /* must be last */
+}
 
-    if (for_spawn->intermediate) {
-        r = kill(for_spawn->intermediate, SIGKILL);
-        if (r) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                         "could not kill %s intermediate process [%ld]",
-                         for_spawn->what,
-                         (unsigned long)for_spawn->intermediate);
-            abort(); /* things are very wrong */
-        }
-        got = waitpid(for_spawn->intermediate, &status, 0);
-        assert(got == for_spawn->intermediate);
-        if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
-            report_spawn_intermediate_status(gc, for_spawn, status);
-            rc = ERROR_FAIL;
-        }
-        for_spawn->intermediate = 0;
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path)
+{
+    /* On entry, is Active. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
+    char *p = libxl__xs_read(gc, 0, ss->xspath);
+    if (!p && errno != ENOENT) {
+        LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
+        spawn_failed(egc, ss); /* must be last */
+        return;
     }
-
-    free(for_spawn->what);
-    for_spawn->what = 0;
-
-    return rc;
+    ss->confirm_cb(egc, ss, p); /* must be last */
 }
 
-int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status)
+    /* Before event, was Active or Detached;
+     * is now Active or Detached except that ssd->mid is Idle */
 {
-    pid_t got;
-    int status;
-
-    if (!for_spawn) return 0;
+    EGC_GC;
+    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
+    libxl__spawn_state *ss = ssd->ss;
 
-    assert(for_spawn->intermediate);
-    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
-    if (!got) return 0;
-
-    assert(got == for_spawn->intermediate);
-    report_spawn_intermediate_status(gc, for_spawn, status);
+    if (!WIFEXITED(status)) {
+        const char *what =
+            GCSPRINTF("%s intermediate process (startup monitor)",
+                      ss ? ss->what : "(detached)");
+        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+        libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
+    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        if (!status)
+            LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
+                " when we were waiting for it to confirm startup",
+                ss->what, (unsigned long)pid);
+        else if (status <= 127)
+            LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d",
+                ss->what, (unsigned long)pid, status);
+        else if (status < 255) {
+            int sig = status - 128;
+            const char *str = strsignal(sig);
+            if (str)
+                LOG(ERROR, "%s [%ld]: died during startup due to fatal"
+                    " signal %s", ss->what, (unsigned long)pid, str);
+            else
+                LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
+                    " signal number %d", ss->what, (unsigned long)pid, sig);
+        }
+        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
+        spawn_failed(egc, ss); /* must be last use of ss */
+    }
+    free(ssd);
+}
 
-    for_spawn->intermediate = 0;
-    return ERROR_FAIL;
+void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    spawn_cleanup(gc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ae71f70..5bab4d6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -840,75 +840,197 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                                       libxl_device_pci *pcidev, int num);
 _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
 
-/* xl_exec */
+/*
+ *----- spawn -----
+ *
+ * Higher-level double-fork and separate detach eg as for device models
+ *
+ * Each libxl__spawn_state is in one of the conventional states
+ *    Undefined, Idle, Active
+ */
 
- /* higher-level double-fork and separate detach eg as for device models */
+typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
+/* this type is never defined, so no objects of this type exist
+ * fixme-ao  This should go away completely.  */
 
-typedef struct {
-    /* put this in your own status structure as returned to application */
-    /* all fields are private to libxl_spawn_... */
-    pid_t intermediate;
-    int fd;
-    char *what; /* malloc'd in spawn_spawn */
-} libxl__spawn_starting;
+typedef struct libxl__spawn_state libxl__spawn_state;
 
-typedef struct {
-    char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */
-    const char *pid_path; /* only for libxl_spawner_record_pid */
-    int domid;
-    libxl__spawn_starting *for_spawn;
-} libxl__spawner_starting;
+/* Clears out a spawn state; idempotent. */
+_hidden void libxl__spawn_init(libxl__spawn_state*);
 
 /*
- * libxl__spawn_spawn - Create a new process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * what: string describing the spawned process
- * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
- * hook_data: data to pass to the hook function
+ * libxl__spawn_spawn - Create a new process which will become daemonic
+ * Forks twice, to allow the child to detach entirely from the parent.
+ *
+ * We call the two generated processes the "middle child" (result of
+ * the first fork) and the "inner child" (result of the second fork
+ * which takes place in the middle child).
+ *
+ * The inner child must soon exit or exec.  If must also soon exit or
+ * notify the parent of its successful startup by writing to the
+ * xenstore path xspath (or by other means).  xspath may be 0 to
+ * indicate that only other means are being used.
+ *
+ * The user (in the parent) will be called back (confirm_cb) every
+ * time that xenstore path is modified.
+ *
+ * In both children, the ctx is not fully useable: gc and logging
+ * operations are OK, but operations on Xen and xenstore are not.
+ * (The restrictions are the same as those which apply to children
+ * made with libxl__ev_child_fork.)
+ *
+ * midproc_cb will be called in the middle child, with the pid of the
+ * inner child; this could for example record the pid.  midproc_cb
+ * should be fast, and should return.  It will be called (reentrantly)
+ * within libxl__spawn_init.
+ *
+ * failure_cb will be called in the parent on failure of the
+ * intermediate or final child; an error message will have been
+ * logged.
+ *
+ * confirm_cb and failure_cb will not be called reentrantly from
+ * within libxl__spawn_spawn.
+ *
+ * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
- *  < 0   error, for_spawn need not be detached
- *   +1   caller is the parent, must call detach on *for_spawn eventually
+ *  < 0   error, *spawn is now Idle and need not be detached
+ *   +1   caller is the parent, *spawn is Active and must eventually be detached
  *    0   caller is now the inner child, should probably call libxl__exec
- * Caller, may pass 0 for for_spawn, in which case no need to detach.
+ *
+ * The spawn state must be Undefined or Idle on entry.
  */
-_hidden int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
-                      void *hook_data);
+_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl_spawner_record_pid - Record given pid in xenstore
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * innerchild: pid of the child
+ * libxl__spawn_detach - Detaches the daemonic child.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, failures of either child are no
+ * longer repaorted via failure_cb.
+ *
+ * If called before the inner child has been created, this may prevent
+ * it from running at all.  Thus this should be called only when the
+ * inner child has notified that it is ready.  Normally it will be
+ * called from within confirm_cb.
  *
- * This function is passed as intermediate_hook to libxl__spawn_spawn.
+ * Logs errors.
+ *
+ * The spawn state must be Active or Idle on entry and will be Idle
+ * on return.
  */
-_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild);
+_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
- * libxl__spawn_confirm_offspring_startup - Wait for child state
- * gc: allocation pool
- * timeout: how many seconds to wait for the child
- * what: string describing the spawned process
- * path: path to the state file in xenstore
- * state: expected string to wait for in path (optional)
- * starting: malloc'd pointer to libxl__spawner_starting
+ * If successful, this should return 0.
  *
- * Returns 0 on success, and < 0 on error.
+ * Otherwise it should return a signal number, which will be
+ * sent to the inner child; the overall spawn will then fail.
+ */
+typedef int /* signal number */
+libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner);
+
+/*
+ * Called if the spawn failed.  The reason will have been logged.
+ * The spawn state will be Idle on entry to the callback (and
+ * it may be reused immediately if desired).
+ */
+typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
+
+/*
+ * Called when the xspath watch triggers.  xspath will have been read
+ * and the result placed in xsdata; if that failed because the key
+ * didn't exist, xspath==0.  (If it failed for some other reason,
+ * the spawn machinery calls failure_cb instead.)
  *
- * This function waits the given timeout for the given path to appear
- * in xenstore, and optionally for state in path.
- * The intermediate process created in libxl__spawn_spawn is killed.
- * The memory referenced by starting->for_spawn and starting is free'd.
+ * If the child has indicated its successful startup, or a failure
+ * has occurred, this should call libxl__spawn_detach.
+ *
+ * If the child is still starting up, should simply return, doing
+ * nothing.
+ *
+ * The spawn state will be Active on entry to the callback; there
+ * are no restrictions on the state on return; it may even have
+ * been detached and reused.
+ */
+typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
+                                     const char *xsdata);
+
+typedef struct {
+    /* Private to the spawn implementation.
+     */
+    /* This separate struct, from malloc, allows us to "detach"
+     * the child and reap it later, when our user has gone
+     * away and freed its libxl__spawn_state */
+    struct libxl__spawn_state *ss;
+    libxl__ev_child mid;
+} libxl__spawn_state_detachable;
+
+struct libxl__spawn_state {
+    /* must be filled in by user and remain valid */
+    libxl__ao *ao;
+    const char *what;
+    const char *xspath;
+    const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */
+    int timeout_ms; /* -1 means forever */
+    libxl__spawn_midproc_cb *midproc_cb;
+    libxl__spawn_failure_cb *failure_cb;
+    libxl__spawn_confirm_cb *confirm_cb;
+
+    /* remaining fields are private to libxl_spawn_... */
+    libxl__ev_time timeout;
+    libxl__ev_xswatch xswatch;
+    libxl__spawn_state_detachable *ssd;
+};
+
+static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
+    { return !!ss->ssd; }
+
+/*
+ * libxl_spawner_record_pid - Record given pid in xenstore
+ *
+ * This function can be passed directly as an intermediate_hook to
+ * libxl__spawn_spawn.  On failure, returns the value SIGTERM.
  */
-_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting);
+_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
+                                    pid_t innerchild);
+
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdoms. */
+
+typedef struct {
+    /* mixed - user must fill in public parts only: */
+    libxl__dm_spawn_state stubdom; /* will always remain the first member */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->stubdom,) */
+    /* private to libxl__spawn_stubdom: */
+    libxl_domain_config stubdom_config;
+    libxl__domain_build_state stubdom_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stubdom_spawn_state;
+
+_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
+
 
 /*
  * libxl__wait_for_offspring - Wait for child state
@@ -941,31 +1063,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
                                                        void *userdata),
                                  void *check_callback_userdata);
 
-/*
- * libxl__spawn_detach - Kill intermediate process from spawn_spawn
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors.  Idempotent, but only permitted after successful
- * call to libxl__spawn_spawn, and no point calling it again if it fails.
- */
-_hidden int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
-
-/*
- * libxl__spawn_check - Check intermediate child process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors but also returns them.
- * Caller must still call detach.
- */
-_hidden int libxl__spawn_check(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
@@ -984,15 +1081,6 @@ _hidden int libxl__domain_build(libxl__gc *gc,
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
-_hidden int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
-_hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1000,10 +1088,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
   /* Caller must either: pass starting_r==0, or on successful
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
-_hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting *starting);
-_hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,
                                 uint32_t domid, char *state,
                                 libxl__spawn_starting *spawning,
@@ -1566,6 +1650,32 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
 
+/*----- Domain creation -----*/
+
+typedef struct libxl__domain_create_state libxl__domain_create_state;
+
+typedef void libxl__domain_create_cb(libxl__egc *egc,
+                                     libxl__domain_create_state*,
+                                     int rc, uint32_t domid);
+
+struct libxl__domain_create_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl_domain_config *guest_config;
+    int restore_fd;
+    libxl_console_ready console_cb;
+    void *console_cb_priv;
+    libxl__domain_create_cb *callback;
+    /* private to domain_create */
+    int guest_domid;
+    libxl__domain_build_state build_state;
+    union {
+        libxl__dm_spawn_state dmss;
+        libxl__stubdom_spawn_state sdss;
+    };
+};
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..9e66536 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1668,8 +1668,8 @@ start:
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                            cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                          cb, &child_console_pid,
+                                          &domid, restore_fd, 0);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1677,7 +1677,7 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                      cb, &child_console_pid, &domid, 0);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ7-0003h2-Mi; Mon, 16 Apr 2012 17:18:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g0-8H
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:15888] by server-1.bemta-14.messagelabs.com id
	F9/7B-29372-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17918 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kH-8i; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dz-82;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:48 +0100
Message-ID: <1334596686-8479-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/24] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index abc38fb..3996824 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..1a4874c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) goto out;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ7-0003h2-Mi; Mon, 16 Apr 2012 17:18:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g0-8H
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [193.109.254.147:15888] by server-1.bemta-14.messagelabs.com id
	F9/7B-29372-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17918 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kH-8i; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dz-82;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:48 +0100
Message-ID: <1334596686-8479-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/24] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index abc38fb..3996824 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -442,6 +442,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..1a4874c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) goto out;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ9-0003ii-Ne; Mon, 16 Apr 2012 17:18:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g2-Gq
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [85.158.139.83:5575] by server-10.bemta-5.messagelabs.com id
	83/3E-08260-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7014 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kG-8N; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dv-6j;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:47 +0100
Message-ID: <1334596686-8479-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/24] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v6:
 * Put failure macro call in correct place so it might actually happen.
 * Try both with -lutil and without.
 * Patch now contains update for config.h.in.
---
 config/Tools.mk.in             |    2 +
 tools/config.h.in              |    3 ++
 tools/configure                |   62 +++++++++++++++++++++++++++++++++++++++-
 tools/configure.ac             |    1 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++
 tools/m4/ptyfuncs.m4           |   28 ++++++++++++++++++
 7 files changed, 100 insertions(+), 2 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 912d021..eb879dd 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/config.h.in b/tools/config.h.in
index 17c8913..bc1ed10 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -42,6 +42,9 @@
 /* Define curses header to use */
 #undef INCLUDE_CURSES_H
 
+/* libutil header file name */
+#undef INCLUDE_LIBUTIL_H
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
diff --git a/tools/configure b/tools/configure
index 8765f20..e2678e7 100755
--- a/tools/configure
+++ b/tools/configure
@@ -598,6 +598,7 @@ ac_includes_default="\
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -2298,6 +2299,8 @@ fi
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -6234,7 +6237,64 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
-AX_CHECK_PTYFUNCS
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "Unable to find library for openpty and login_tty
+See \`config.log' for more details" "$LINENO" 5 ; }
+            fi
+
+    saved_LIBS="$LIBS"
+
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+                break
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+        done
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 7fde2fb..6ff1c03 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -32,6 +32,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..5ba144f 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..7581704
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,28 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                AC_MSG_FAILURE([Unable to find library for openpty and login_tty])
+            fi
+            AX_SAVEVAR_SAVE(LIBS)
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+],[
+                break
+            ],[])
+            AX_SAVEVAR_RESTORE(LIBS)
+        done
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ9-0003ii-Ne; Mon, 16 Apr 2012 17:18:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g2-Gq
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:12 +0000
Received: from [85.158.139.83:5575] by server-10.bemta-5.messagelabs.com id
	83/3E-08260-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7014 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kG-8N; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dv-6j;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:47 +0100
Message-ID: <1334596686-8479-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/24] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v6:
 * Put failure macro call in correct place so it might actually happen.
 * Try both with -lutil and without.
 * Patch now contains update for config.h.in.
---
 config/Tools.mk.in             |    2 +
 tools/config.h.in              |    3 ++
 tools/configure                |   62 +++++++++++++++++++++++++++++++++++++++-
 tools/configure.ac             |    1 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++
 tools/m4/ptyfuncs.m4           |   28 ++++++++++++++++++
 7 files changed, 100 insertions(+), 2 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 912d021..eb879dd 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/config.h.in b/tools/config.h.in
index 17c8913..bc1ed10 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -42,6 +42,9 @@
 /* Define curses header to use */
 #undef INCLUDE_CURSES_H
 
+/* libutil header file name */
+#undef INCLUDE_LIBUTIL_H
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
diff --git a/tools/configure b/tools/configure
index 8765f20..e2678e7 100755
--- a/tools/configure
+++ b/tools/configure
@@ -598,6 +598,7 @@ ac_includes_default="\
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -2298,6 +2299,8 @@ fi
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -6234,7 +6237,64 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
-AX_CHECK_PTYFUNCS
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "Unable to find library for openpty and login_tty
+See \`config.log' for more details" "$LINENO" 5 ; }
+            fi
+
+    saved_LIBS="$LIBS"
+
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+                break
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+        done
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 7fde2fb..6ff1c03 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -32,6 +32,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..5ba144f 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..7581704
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,28 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                AC_MSG_FAILURE([Unable to find library for openpty and login_tty])
+            fi
+            AX_SAVEVAR_SAVE(LIBS)
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+],[
+                break
+            ],[])
+            AX_SAVEVAR_RESTORE(LIBS)
+        done
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZE-0003mw-9Z; Mon, 16 Apr 2012 17:18:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003fv-1K
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [85.158.139.83:16654] by server-12.bemta-5.messagelabs.com id
	21/A4-05587-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8846 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kq-OC; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002FA-NQ;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:06 +0100
Message-ID: <1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
	when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cancel the bootloader (specifically, by sending it a signal) if the
domain is seen to disappear from xenstore.

We use a new utility event source libxl__domaindeathcheck which
provides a convenient wrapper for the xenstore watch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_bootloader.c |   43 ++++++++++++++++++++++++++++++---------
 tools/libxl/libxl_event.c      |   31 ++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   29 ++++++++++++++++++++++++++-
 3 files changed, 92 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 8436c07..fb1302b 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -31,6 +31,7 @@ static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
 static void bootloader_display_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_domaindeath(libxl__egc*, libxl__domaindeathcheck *dc);
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status);
 
@@ -213,6 +214,7 @@ void libxl__bootloader_init(libxl__bootloader_state *bl)
     bl->ptys[0].master = bl->ptys[0].slave = 0;
     bl->ptys[1].master = bl->ptys[1].slave = 0;
     libxl__ev_child_init(&bl->child);
+    libxl__domaindeathcheck_init(&bl->deathcheck);
     bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
     bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
 }
@@ -230,6 +232,7 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         free(bl->diskpath);
         bl->diskpath = 0;
     }
+    libxl__domaindeathcheck_stop(gc,&bl->deathcheck);
     libxl__datacopier_kill(&bl->keystrokes);
     libxl__datacopier_kill(&bl->display);
     for (i=0; i<2; i++) {
@@ -256,6 +259,23 @@ static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
     bl->callback(egc, bl, rc);
 }
 
+/* might be called at any time, provided it's init'd */
+static void bootloader_abort(libxl__egc *egc,
+                             libxl__bootloader_state *bl, int rc)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
+    }
+    bl->rc = rc;
+}
+
 /*----- main flow of control -----*/
 
 void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
@@ -377,6 +397,12 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    bl->deathcheck.what = "stopping bootloader";
+    bl->deathcheck.domid = bl->domid;
+    bl->deathcheck.callback = bootloader_domaindeath;
+    rc = libxl__domaindeathcheck_start(gc, &bl->deathcheck);
+    if (rc) goto out;
+
     if (bl->console_available)
         bl->console_available(egc, bl);
 
@@ -454,18 +480,9 @@ static void bootloader_copyfail(libxl__egc *egc, const char *which,
        libxl__bootloader_state *bl, int onwrite, int errnoval)
 {
     STATE_AO_GC(bl->ao);
-    int r;
-
     if (!onwrite && !errnoval)
         LOG(ERROR, "unexpected eof copying %s", which);
-    libxl__datacopier_kill(&bl->keystrokes);
-    libxl__datacopier_kill(&bl->display);
-    if (libxl__ev_child_inuse(&bl->child)) {
-        r = kill(bl->child.pid, SIGTERM);
-        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
-                    (unsigned long)bl->child.pid);
-    }
-    bl->rc = ERROR_FAIL;
+    bootloader_abort(egc, bl, ERROR_FAIL);
 }
 static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval)
@@ -480,6 +497,12 @@ static void bootloader_display_copyfail(libxl__egc *egc,
     bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
 }
 
+static void bootloader_domaindeath(libxl__egc *egc, libxl__domaindeathcheck *dc)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, deathcheck);
+    bootloader_abort(egc, bl, ERROR_FAIL);
+}
+
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status)
 {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 991f16e..e43aedc 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -585,6 +585,37 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
 }
 
 /*
+ * domain death/destruction
+ */
+
+static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch);
+    EGC_GC;
+    const char *p = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (p) return;
+
+    if (errno!=ENOENT) {
+        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
+                              " for domain deatch check", errno, 0);
+        return;
+    }
+
+    LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)",
+        dc->what, dc->domid, watch_path);
+    dc->callback(egc, dc);
+}
+
+int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                  libxl__domaindeathcheck *dc)
+{
+    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
+    return libxl__ev_xswatch_register(gc, &dc->watch,
+                                      domaindeathcheck_callback, path);
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3e90ac4..92e06f1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -837,6 +837,33 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
                                     const char *state_path,
                                     int state, int milliseconds);
 
+/*
+ * libxl__ev_domaindeathcheck_register - arranges to call back (once)
+ * if the domain is destroyed.  If the domain dies, we log a message
+ * of the form "<what>: <explanation of the situation, including the domid>".
+ */
+
+typedef struct libxl__domaindeathcheck libxl__domaindeathcheck;
+typedef void libxl___domaindeathcheck_callback(libxl__egc *egc,
+                                         libxl__domaindeathcheck*);
+
+struct libxl__domaindeathcheck {
+    /* must be filled in by caller, and remain valid: */
+    const char *what;
+    uint32_t domid;
+    libxl___domaindeathcheck_callback *callback;
+    /* private */
+    libxl__ev_xswatch watch;
+};
+
+_hidden int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                          libxl__domaindeathcheck *dc);
+
+static inline void libxl__domaindeathcheck_init
+ (libxl__domaindeathcheck *dc) { libxl__ev_xswatch_init(&dc->watch); }
+static inline void libxl__domaindeathcheck_stop(libxl__gc *gc,
+  libxl__domaindeathcheck *dc) { libxl__ev_xswatch_deregister(gc,&dc->watch); }
+
 
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
@@ -1690,6 +1717,7 @@ struct libxl__bootloader_state {
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
     libxl__ev_child child;
+    libxl__domaindeathcheck deathcheck;
     int nargs, argsspace;
     const char **args;
     libxl__datacopier_state keystrokes, display;
@@ -1702,7 +1730,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
-
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZE-0003mw-9Z; Mon, 16 Apr 2012 17:18:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003fv-1K
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [85.158.139.83:16654] by server-12.bemta-5.messagelabs.com id
	21/A4-05587-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8846 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kq-OC; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002FA-NQ;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:06 +0100
Message-ID: <1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
	when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cancel the bootloader (specifically, by sending it a signal) if the
domain is seen to disappear from xenstore.

We use a new utility event source libxl__domaindeathcheck which
provides a convenient wrapper for the xenstore watch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_bootloader.c |   43 ++++++++++++++++++++++++++++++---------
 tools/libxl/libxl_event.c      |   31 ++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   29 ++++++++++++++++++++++++++-
 3 files changed, 92 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 8436c07..fb1302b 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -31,6 +31,7 @@ static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
 static void bootloader_display_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_domaindeath(libxl__egc*, libxl__domaindeathcheck *dc);
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status);
 
@@ -213,6 +214,7 @@ void libxl__bootloader_init(libxl__bootloader_state *bl)
     bl->ptys[0].master = bl->ptys[0].slave = 0;
     bl->ptys[1].master = bl->ptys[1].slave = 0;
     libxl__ev_child_init(&bl->child);
+    libxl__domaindeathcheck_init(&bl->deathcheck);
     bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
     bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
 }
@@ -230,6 +232,7 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         free(bl->diskpath);
         bl->diskpath = 0;
     }
+    libxl__domaindeathcheck_stop(gc,&bl->deathcheck);
     libxl__datacopier_kill(&bl->keystrokes);
     libxl__datacopier_kill(&bl->display);
     for (i=0; i<2; i++) {
@@ -256,6 +259,23 @@ static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
     bl->callback(egc, bl, rc);
 }
 
+/* might be called at any time, provided it's init'd */
+static void bootloader_abort(libxl__egc *egc,
+                             libxl__bootloader_state *bl, int rc)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
+    }
+    bl->rc = rc;
+}
+
 /*----- main flow of control -----*/
 
 void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
@@ -377,6 +397,12 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    bl->deathcheck.what = "stopping bootloader";
+    bl->deathcheck.domid = bl->domid;
+    bl->deathcheck.callback = bootloader_domaindeath;
+    rc = libxl__domaindeathcheck_start(gc, &bl->deathcheck);
+    if (rc) goto out;
+
     if (bl->console_available)
         bl->console_available(egc, bl);
 
@@ -454,18 +480,9 @@ static void bootloader_copyfail(libxl__egc *egc, const char *which,
        libxl__bootloader_state *bl, int onwrite, int errnoval)
 {
     STATE_AO_GC(bl->ao);
-    int r;
-
     if (!onwrite && !errnoval)
         LOG(ERROR, "unexpected eof copying %s", which);
-    libxl__datacopier_kill(&bl->keystrokes);
-    libxl__datacopier_kill(&bl->display);
-    if (libxl__ev_child_inuse(&bl->child)) {
-        r = kill(bl->child.pid, SIGTERM);
-        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
-                    (unsigned long)bl->child.pid);
-    }
-    bl->rc = ERROR_FAIL;
+    bootloader_abort(egc, bl, ERROR_FAIL);
 }
 static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval)
@@ -480,6 +497,12 @@ static void bootloader_display_copyfail(libxl__egc *egc,
     bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
 }
 
+static void bootloader_domaindeath(libxl__egc *egc, libxl__domaindeathcheck *dc)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, deathcheck);
+    bootloader_abort(egc, bl, ERROR_FAIL);
+}
+
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status)
 {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 991f16e..e43aedc 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -585,6 +585,37 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
 }
 
 /*
+ * domain death/destruction
+ */
+
+static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch);
+    EGC_GC;
+    const char *p = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (p) return;
+
+    if (errno!=ENOENT) {
+        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
+                              " for domain deatch check", errno, 0);
+        return;
+    }
+
+    LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)",
+        dc->what, dc->domid, watch_path);
+    dc->callback(egc, dc);
+}
+
+int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                  libxl__domaindeathcheck *dc)
+{
+    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
+    return libxl__ev_xswatch_register(gc, &dc->watch,
+                                      domaindeathcheck_callback, path);
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3e90ac4..92e06f1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -837,6 +837,33 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
                                     const char *state_path,
                                     int state, int milliseconds);
 
+/*
+ * libxl__ev_domaindeathcheck_register - arranges to call back (once)
+ * if the domain is destroyed.  If the domain dies, we log a message
+ * of the form "<what>: <explanation of the situation, including the domid>".
+ */
+
+typedef struct libxl__domaindeathcheck libxl__domaindeathcheck;
+typedef void libxl___domaindeathcheck_callback(libxl__egc *egc,
+                                         libxl__domaindeathcheck*);
+
+struct libxl__domaindeathcheck {
+    /* must be filled in by caller, and remain valid: */
+    const char *what;
+    uint32_t domid;
+    libxl___domaindeathcheck_callback *callback;
+    /* private */
+    libxl__ev_xswatch watch;
+};
+
+_hidden int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                          libxl__domaindeathcheck *dc);
+
+static inline void libxl__domaindeathcheck_init
+ (libxl__domaindeathcheck *dc) { libxl__ev_xswatch_init(&dc->watch); }
+static inline void libxl__domaindeathcheck_stop(libxl__gc *gc,
+  libxl__domaindeathcheck *dc) { libxl__ev_xswatch_deregister(gc,&dc->watch); }
+
 
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
@@ -1690,6 +1717,7 @@ struct libxl__bootloader_state {
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
     libxl__ev_child child;
+    libxl__domaindeathcheck deathcheck;
     int nargs, argsspace;
     const char **args;
     libxl__datacopier_state keystrokes, display;
@@ -1702,7 +1730,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
-
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZA-0003iv-45; Mon, 16 Apr 2012 17:18:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g5-S2
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [85.158.139.83:16529] by server-7.bemta-5.messagelabs.com id
	FF/BC-16195-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7033 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kM-BI; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002E7-AU;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:50 +0100
Message-ID: <1334596686-8479-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/24] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..3675afe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZA-0003iv-45; Mon, 16 Apr 2012 17:18:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ6-0003g5-S2
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [85.158.139.83:16529] by server-7.bemta-5.messagelabs.com id
	FF/BC-16195-4545C8F4; Mon, 16 Apr 2012 17:18:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7033 invoked from network); 16 Apr 2012 17:18:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kM-BI; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002E7-AU;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:50 +0100
Message-ID: <1334596686-8479-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/24] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..3675afe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -552,9 +552,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZC-0003kg-2l; Mon, 16 Apr 2012 17:18:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003gk-MQ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [193.109.254.147:19928] by server-4.bemta-14.messagelabs.com id
	B2/90-11570-5545C8F4; Mon, 16 Apr 2012 17:18:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 16 Apr 2012 17:18:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ka-IH; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EZ-HE;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:57 +0100
Message-ID: <1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove this obsolete hook.  Callers inside libxl which create and reap
children should use the mechanisms provided by the event system.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   12 +++---------
 tools/libxl/libxl_internal.h |    3 ---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..2ee2154 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -19,11 +19,6 @@
 
 #include "libxl_internal.h"
 
-static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
-{
-    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
-}
-
 static void check_open_fds(const char *what)
 {
     const char *env_debug;
@@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
 
     if (!for_spawn) _exit(0); /* just detach then */
 
-    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
+    got = waitpid(child, &status, 0);
     assert(got == child);
 
     rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
@@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
                          (unsigned long)for_spawn->intermediate);
             abort(); /* things are very wrong */
         }
-        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
+        got = waitpid(for_spawn->intermediate, &status, 0);
         assert(got == for_spawn->intermediate);
         if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
             report_spawn_intermediate_status(gc, for_spawn, status);
@@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
 
 int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     pid_t got;
     int status;
 
     if (!for_spawn) return 0;
 
     assert(for_spawn->intermediate);
-    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
+    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
     if (!got) return 0;
 
     assert(got == for_spawn->intermediate);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 74dc2c5..ae71f70 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -334,9 +334,6 @@ struct libxl__ctx {
     int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
     LIBXL_LIST_HEAD(, libxl__ev_child) children;
 
-    /* This is obsolete and must be removed: */
-    int (*waitpid_instead)(pid_t pid, int *status, int flags);
-
     libxl_version_info version_info;
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZC-0003kg-2l; Mon, 16 Apr 2012 17:18:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ7-0003gk-MQ
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:13 +0000
Received: from [193.109.254.147:19928] by server-4.bemta-14.messagelabs.com id
	B2/90-11570-5545C8F4; Mon, 16 Apr 2012 17:18:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 16 Apr 2012 17:18:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ka-IH; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EZ-HE;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:57 +0100
Message-ID: <1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove this obsolete hook.  Callers inside libxl which create and reap
children should use the mechanisms provided by the event system.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   12 +++---------
 tools/libxl/libxl_internal.h |    3 ---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..2ee2154 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -19,11 +19,6 @@
 
 #include "libxl_internal.h"
 
-static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
-{
-    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
-}
-
 static void check_open_fds(const char *what)
 {
     const char *env_debug;
@@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
 
     if (!for_spawn) _exit(0); /* just detach then */
 
-    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
+    got = waitpid(child, &status, 0);
     assert(got == child);
 
     rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
@@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
                          (unsigned long)for_spawn->intermediate);
             abort(); /* things are very wrong */
         }
-        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
+        got = waitpid(for_spawn->intermediate, &status, 0);
         assert(got == for_spawn->intermediate);
         if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
             report_spawn_intermediate_status(gc, for_spawn, status);
@@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
 
 int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     pid_t got;
     int status;
 
     if (!for_spawn) return 0;
 
     assert(for_spawn->intermediate);
-    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
+    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
     if (!got) return 0;
 
     assert(got == for_spawn->intermediate);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 74dc2c5..ae71f70 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -334,9 +334,6 @@ struct libxl__ctx {
     int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
     LIBXL_LIST_HEAD(, libxl__ev_child) children;
 
-    /* This is obsolete and must be removed: */
-    int (*waitpid_instead)(pid_t pid, int *status, int flags);
-
     libxl_version_info version_info;
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ7-0003gl-9t; Mon, 16 Apr 2012 17:18:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ5-0003fl-F3
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:11 +0000
Received: from [85.158.139.83:16503] by server-9.bemta-5.messagelabs.com id
	66/5C-09826-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6993 invoked from network); 16 Apr 2012 17:18:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kB-47; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dh-2O;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:43 +0100
Message-ID: <1334596686-8479-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/24] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..af631fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZ7-0003gl-9t; Mon, 16 Apr 2012 17:18:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ5-0003fl-F3
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:11 +0000
Received: from [85.158.139.83:16503] by server-9.bemta-5.messagelabs.com id
	66/5C-09826-3545C8F4; Mon, 16 Apr 2012 17:18:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334596689!24063819!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6993 invoked from network); 16 Apr 2012 17:18:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kB-47; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dh-2O;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:43 +0100
Message-ID: <1334596686-8479-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/24] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..af631fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZD-0003m6-G1; Mon, 16 Apr 2012 17:18:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ8-0003g2-98
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [85.158.139.83:5686] by server-10.bemta-5.messagelabs.com id
	44/4E-08260-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8818 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kb-IU; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Ed-Hm;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:58 +0100
Message-ID: <1334596686-8479-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/24] libxl: change some structures to unit
	arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch these variables will turn into actual pointers.

To clarify that patch, prepare the ground by changing these variables
from "struct foo var" to "struct foo var[1]".  This enables accesses
to them and their members to be made as if they were pointers.

No functional change.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   18 +++++-----
 tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index dbc3cf0..8408c26 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -543,7 +543,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state;
+    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
@@ -585,12 +585,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(&state, 0, sizeof(state));
+    memset(state, 0, sizeof(*state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
     }
 
     if (ret) {
@@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
@@ -636,7 +636,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
-                                         &state, &dm_starting);
+                                         state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -665,11 +665,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (need_qemu)
              console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
         }
         break;
     }
@@ -683,7 +683,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 7bf653a..3921e2a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config;
+    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state;
+    libxl__domain_build_state stubdom_state[1];
     uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
@@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
-    libxl_domain_create_info_init(&dm_config.c_info);
-    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+    libxl_domain_create_info_init(&dm_config->c_info);
+    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
-    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
+    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
-    libxl_uuid_generate(&dm_config.c_info.uuid);
+    libxl_uuid_generate(&dm_config->c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info);
-    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
+    libxl_domain_build_info_init(&dm_config->b_info);
+    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
 
-    dm_config.b_info.max_vcpus = 1;
-    dm_config.b_info.max_memkb = 32 * 1024;
-    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+    dm_config->b_info.max_vcpus = 1;
+    dm_config->b_info.max_memkb = 32 * 1024;
+    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
-    dm_config.b_info.u.pv.ramdisk.path = "";
-    dm_config.b_info.u.pv.features = "";
+    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
+    dm_config->b_info.u.pv.ramdisk.path = "";
+    dm_config->b_info.u.pv.features = "";
 
-    dm_config.b_info.device_model_version =
+    dm_config->b_info.device_model_version =
         guest_config->b_info.device_model_version;
-    dm_config.b_info.device_model =
+    dm_config->b_info.device_model =
         guest_config->b_info.device_model;
-    dm_config.b_info.extra = guest_config->b_info.extra;
-    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
-    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+    dm_config->b_info.extra = guest_config->b_info.extra;
+    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
 
-    dm_config.disks = guest_config->disks;
-    dm_config.num_disks = guest_config->num_disks;
+    dm_config->disks = guest_config->disks;
+    dm_config->num_disks = guest_config->num_disks;
 
-    dm_config.vifs = guest_config->vifs;
-    dm_config.num_vifs = guest_config->num_vifs;
+    dm_config->vifs = guest_config->vifs;
+    dm_config->num_vifs = guest_config->num_vifs;
 
-    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
     if (ret) goto out;
-    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
     if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
-    dm_config.vfbs = &vfb;
-    dm_config.num_vfbs = 1;
-    dm_config.vkbs = &vkb;
-    dm_config.num_vkbs = 1;
+    dm_config->vfbs = &vfb;
+    dm_config->num_vfbs = 1;
+    dm_config->vkbs = &vkb;
+    dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
     dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
 
@@ -788,20 +788,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+    for (i = 0; i < dm_config->num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+    for (i = 0; i < dm_config->num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -845,14 +845,14 @@ retry_transaction:
                 break;
         }
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
-                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
     if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 &dm_config,
-                                 &stubdom_state,
+                                 dm_config,
+                                 stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZD-0003m6-G1; Mon, 16 Apr 2012 17:18:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ8-0003g2-98
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [85.158.139.83:5686] by server-10.bemta-5.messagelabs.com id
	44/4E-08260-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8818 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kb-IU; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Ed-Hm;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:58 +0100
Message-ID: <1334596686-8479-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/24] libxl: change some structures to unit
	arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch these variables will turn into actual pointers.

To clarify that patch, prepare the ground by changing these variables
from "struct foo var" to "struct foo var[1]".  This enables accesses
to them and their members to be made as if they were pointers.

No functional change.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   18 +++++-----
 tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index dbc3cf0..8408c26 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -543,7 +543,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state;
+    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
@@ -585,12 +585,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(&state, 0, sizeof(state));
+    memset(state, 0, sizeof(*state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
     }
 
     if (ret) {
@@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
@@ -636,7 +636,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
-                                         &state, &dm_starting);
+                                         state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -665,11 +665,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (need_qemu)
              console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
         }
         break;
     }
@@ -683,7 +683,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 7bf653a..3921e2a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config;
+    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state;
+    libxl__domain_build_state stubdom_state[1];
     uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
@@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
-    libxl_domain_create_info_init(&dm_config.c_info);
-    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+    libxl_domain_create_info_init(&dm_config->c_info);
+    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
-    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
+    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
-    libxl_uuid_generate(&dm_config.c_info.uuid);
+    libxl_uuid_generate(&dm_config->c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info);
-    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
+    libxl_domain_build_info_init(&dm_config->b_info);
+    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
 
-    dm_config.b_info.max_vcpus = 1;
-    dm_config.b_info.max_memkb = 32 * 1024;
-    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+    dm_config->b_info.max_vcpus = 1;
+    dm_config->b_info.max_memkb = 32 * 1024;
+    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
-    dm_config.b_info.u.pv.ramdisk.path = "";
-    dm_config.b_info.u.pv.features = "";
+    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
+    dm_config->b_info.u.pv.ramdisk.path = "";
+    dm_config->b_info.u.pv.features = "";
 
-    dm_config.b_info.device_model_version =
+    dm_config->b_info.device_model_version =
         guest_config->b_info.device_model_version;
-    dm_config.b_info.device_model =
+    dm_config->b_info.device_model =
         guest_config->b_info.device_model;
-    dm_config.b_info.extra = guest_config->b_info.extra;
-    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
-    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+    dm_config->b_info.extra = guest_config->b_info.extra;
+    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
 
-    dm_config.disks = guest_config->disks;
-    dm_config.num_disks = guest_config->num_disks;
+    dm_config->disks = guest_config->disks;
+    dm_config->num_disks = guest_config->num_disks;
 
-    dm_config.vifs = guest_config->vifs;
-    dm_config.num_vifs = guest_config->num_vifs;
+    dm_config->vifs = guest_config->vifs;
+    dm_config->num_vifs = guest_config->num_vifs;
 
-    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
     if (ret) goto out;
-    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
     if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
-    dm_config.vfbs = &vfb;
-    dm_config.num_vfbs = 1;
-    dm_config.vkbs = &vkb;
-    dm_config.num_vkbs = 1;
+    dm_config->vfbs = &vfb;
+    dm_config->num_vfbs = 1;
+    dm_config->vkbs = &vkb;
+    dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
     dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
 
@@ -788,20 +788,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+    for (i = 0; i < dm_config->num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+    for (i = 0; i < dm_config->num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -845,14 +845,14 @@ retry_transaction:
                 break;
         }
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
-                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
     if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 &dm_config,
-                                 &stubdom_state,
+                                 dm_config,
+                                 stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZF-0003pM-UG; Mon, 16 Apr 2012 17:18:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003g6-7n
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [85.158.139.83:16667] by server-1.bemta-5.messagelabs.com id
	B9/0E-28458-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8852 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003km-N4; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Ex-Kp;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:03 +0100
Message-ID: <1334596686-8479-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/24] libxl: convert console callback to
	libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the old console callback.  (Its reentrancy properties were
troublesome: in principle, the event loop might be reentered during
the callback, and the libxl__domain_create_state swept out from under
the feet of the domain creation.)

As a side effect of the new code arrangements, the console callback
for non-bootloader-using PV guests now occurs near the end of domain
creation, in the same place as for HVM guests, rather than near the
start.

The new arrangements should in principle mean that by the time the
console is described as ready by the callback, the xenstore key is
indeed ready.  So in the future the timeout might be removed from
the console client.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.h            |   17 ++++++-----
 tools/libxl/libxl_bootloader.c |    3 ++
 tools/libxl/libxl_create.c     |   59 +++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h   |    6 +++-
 tools/libxl/libxl_types.idl    |    2 +
 tools/libxl/xl_cmdimpl.c       |   25 ++++++++++-------
 6 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bfe684..de8d1872 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
-typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
-   * properties need to be documented but they may turn out to be too
-   * awkward */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            const libxl_asyncop_how *ao_how);
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how);
+                                const libxl_asyncop_how *ao_how,
+                                const libxl_asyncprogress_how *aop_console_how);
+  /* A progress report will be made via ao_console_how, of type
+   * domain_create_console_available, when the domain's primary
+   * console is available and can be connected to.
+   */
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 1534bae..8436c07 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -377,6 +377,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    if (bl->console_available)
+        bl->console_available(egc, bl);
+
     int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
     int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1dd9a02..4f6b327 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,10 +550,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl);
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -571,8 +576,6 @@ static void initiate_domain_create(libxl__egc *egc,
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
     int restore_fd = dcs->restore_fd;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
@@ -590,11 +593,6 @@ static void initiate_domain_create(libxl__egc *egc,
     dcs->guest_domid = domid;
     dcs->dmss.guest_domid = 0; /* means we haven't spawned */
 
-    if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
-
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
@@ -609,6 +607,7 @@ static void initiate_domain_create(libxl__egc *egc,
 
     if (restore_fd < 0 && bootdisk) {
         dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.console_available = domcreate_bootloader_console_available;
         dcs->bl.info = &d_config->b_info,
         dcs->bl.disk = bootdisk;
         dcs->bl.domid = dcs->guest_domid;
@@ -624,6 +623,21 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    domcreate_console_available(egc, dcs);
+}
+
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs) {
+    libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
+                              NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
+                                        dcs->guest_domid));
+}
+
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int ret)
@@ -760,8 +774,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
 
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -799,12 +811,7 @@ static void domcreate_devmodel_started(libxl__egc *egc,
             goto error_out;
         }
     }
-    if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
-                (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-                 d_config->b_info.u.pv.bootloader ))) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
+    domcreate_console_available(egc, dcs);
 
     domcreate_complete(egc, dcs, 0);
     return;
@@ -843,8 +850,9 @@ static void domain_create_cb(libxl__egc *egc,
                              int rc, uint32_t domid);
 
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            int restore_fd, const libxl_asyncop_how *ao_how)
+                            uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
     AO_CREATE(ctx, 0, ao_how);
     libxl__app_domain_create_state *cdcs;
@@ -853,9 +861,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
     cdcs->dcs.restore_fd = restore_fd;
-    cdcs->dcs.console_cb = cb;
-    cdcs->dcs.console_cb_priv = priv;
     cdcs->dcs.callback = domain_create_cb;
+    libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
     cdcs->domid_out = domid;
 
     initiate_domain_create(egc, &cdcs->dcs);
@@ -877,19 +884,21 @@ static void domain_create_cb(libxl__egc *egc,
 }
     
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
                             uint32_t *domid,
-                            const libxl_asyncop_how *ao_how)
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
+    return do_domain_create(ctx, d_config, domid, -1,
+                            ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how)
+                                const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
+    return do_domain_create(ctx, d_config, domid, restore_fd,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 977db2a..b77a891 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1651,11 +1651,14 @@ int libxl__openptys(libxl__openpty_state *op,
 typedef struct libxl__bootloader_state libxl__bootloader_state;
 typedef void libxl__run_bootloader_callback(libxl__egc*,
                                 libxl__bootloader_state*, int rc);
+typedef void libxl__bootloader_console_callback(libxl__egc*,
+                                libxl__bootloader_state*);
 
 struct libxl__bootloader_state {
     /* caller must fill these in, and they must all remain valid */
     libxl__ao *ao;
     libxl__run_bootloader_callback *callback;
+    libxl__bootloader_console_callback *console_available;
     libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
     libxl_device_disk *disk;
     uint32_t domid;
@@ -1691,9 +1694,8 @@ struct libxl__domain_create_state {
     libxl__ao *ao;
     libxl_domain_config *guest_config;
     int restore_fd;
-    libxl_console_ready console_cb;
-    void *console_cb_priv;
     libxl__domain_create_cb *callback;
+    libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..f28d785 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -444,6 +444,7 @@ libxl_event_type = Enumeration("event_type", [
     (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
+    (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -469,4 +470,5 @@ libxl_event = Struct("event",[
            ("operation_complete", Struct(None, [
                                         ("rc", integer),
                                  ])),
+           ("domain_create_console_available", Struct(None, [])),
            ]))])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9e66536..ce52599 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1430,16 +1430,18 @@ static int freemem(libxl_domain_build_info *b_info)
     return ERROR_NOMEM;
 }
 
-static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
+static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv)
 {
     pid_t *pid = priv;
 
+    libxl_event_free(ctx, ev);
+
     *pid = fork();
     if (*pid < 0) {
         perror("unable to fork xenconsole");
-        return ERROR_FAIL;
+        return;
     } else if (*pid > 0)
-        return 0;
+        return;
 
     postfork();
 
@@ -1506,7 +1508,7 @@ static int create_domain(struct domain_create *dom_info)
     int config_len = 0;
     int restore_fd = -1;
     int status = 0;
-    libxl_console_ready cb;
+    const libxl_asyncprogress_how *autoconnect_console_how;
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
@@ -1660,24 +1662,27 @@ start:
         goto error_out;
     }
 
+    libxl_asyncprogress_how autoconnect_console_how_buf;
     if ( dom_info->console_autoconnect ) {
-        cb = autoconnect_console;
+        autoconnect_console_how_buf.callback = autoconnect_console;
+        autoconnect_console_how_buf.for_callback = &child_console_pid;
+        autoconnect_console_how = &autoconnect_console_how_buf;
     }else{
-        cb = NULL;
+        autoconnect_console_how = 0;
     }
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                          cb, &child_console_pid,
-                                          &domid, restore_fd, 0);
+                                          &domid, restore_fd,
+                                          0, autoconnect_console_how);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
          */
         restore_file = NULL;
     }else{
-        ret = libxl_domain_create_new(ctx, &d_config,
-                                      cb, &child_console_pid, &domid, 0);
+        ret = libxl_domain_create_new(ctx, &d_config, &domid,
+                                      0, autoconnect_console_how);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZF-0003pM-UG; Mon, 16 Apr 2012 17:18:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003g6-7n
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [85.158.139.83:16667] by server-1.bemta-5.messagelabs.com id
	B9/0E-28458-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334596692!19787134!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8852 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003km-N4; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Ex-Kp;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:03 +0100
Message-ID: <1334596686-8479-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/24] libxl: convert console callback to
	libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the old console callback.  (Its reentrancy properties were
troublesome: in principle, the event loop might be reentered during
the callback, and the libxl__domain_create_state swept out from under
the feet of the domain creation.)

As a side effect of the new code arrangements, the console callback
for non-bootloader-using PV guests now occurs near the end of domain
creation, in the same place as for HVM guests, rather than near the
start.

The new arrangements should in principle mean that by the time the
console is described as ready by the callback, the xenstore key is
indeed ready.  So in the future the timeout might be removed from
the console client.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.h            |   17 ++++++-----
 tools/libxl/libxl_bootloader.c |    3 ++
 tools/libxl/libxl_create.c     |   59 +++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h   |    6 +++-
 tools/libxl/libxl_types.idl    |    2 +
 tools/libxl/xl_cmdimpl.c       |   25 ++++++++++-------
 6 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bfe684..de8d1872 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
-typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
-   * properties need to be documented but they may turn out to be too
-   * awkward */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            const libxl_asyncop_how *ao_how);
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how);
+                                const libxl_asyncop_how *ao_how,
+                                const libxl_asyncprogress_how *aop_console_how);
+  /* A progress report will be made via ao_console_how, of type
+   * domain_create_console_available, when the domain's primary
+   * console is available and can be connected to.
+   */
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 1534bae..8436c07 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -377,6 +377,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    if (bl->console_available)
+        bl->console_available(egc, bl);
+
     int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
     int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1dd9a02..4f6b327 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,10 +550,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl);
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -571,8 +576,6 @@ static void initiate_domain_create(libxl__egc *egc,
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
     int restore_fd = dcs->restore_fd;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
@@ -590,11 +593,6 @@ static void initiate_domain_create(libxl__egc *egc,
     dcs->guest_domid = domid;
     dcs->dmss.guest_domid = 0; /* means we haven't spawned */
 
-    if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
-
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
@@ -609,6 +607,7 @@ static void initiate_domain_create(libxl__egc *egc,
 
     if (restore_fd < 0 && bootdisk) {
         dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.console_available = domcreate_bootloader_console_available;
         dcs->bl.info = &d_config->b_info,
         dcs->bl.disk = bootdisk;
         dcs->bl.domid = dcs->guest_domid;
@@ -624,6 +623,21 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    domcreate_console_available(egc, dcs);
+}
+
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs) {
+    libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
+                              NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
+                                        dcs->guest_domid));
+}
+
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int ret)
@@ -760,8 +774,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *d_config = dcs->guest_config;
-    libxl_console_ready cb = dcs->console_cb;
-    void *priv = dcs->console_cb_priv;
 
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -799,12 +811,7 @@ static void domcreate_devmodel_started(libxl__egc *egc,
             goto error_out;
         }
     }
-    if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
-                (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-                 d_config->b_info.u.pv.bootloader ))) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
+    domcreate_console_available(egc, dcs);
 
     domcreate_complete(egc, dcs, 0);
     return;
@@ -843,8 +850,9 @@ static void domain_create_cb(libxl__egc *egc,
                              int rc, uint32_t domid);
 
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            int restore_fd, const libxl_asyncop_how *ao_how)
+                            uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
     AO_CREATE(ctx, 0, ao_how);
     libxl__app_domain_create_state *cdcs;
@@ -853,9 +861,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
     cdcs->dcs.restore_fd = restore_fd;
-    cdcs->dcs.console_cb = cb;
-    cdcs->dcs.console_cb_priv = priv;
     cdcs->dcs.callback = domain_create_cb;
+    libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
     cdcs->domid_out = domid;
 
     initiate_domain_create(egc, &cdcs->dcs);
@@ -877,19 +884,21 @@ static void domain_create_cb(libxl__egc *egc,
 }
     
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
                             uint32_t *domid,
-                            const libxl_asyncop_how *ao_how)
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
+    return do_domain_create(ctx, d_config, domid, -1,
+                            ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how)
+                                const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
+    return do_domain_create(ctx, d_config, domid, restore_fd,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 977db2a..b77a891 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1651,11 +1651,14 @@ int libxl__openptys(libxl__openpty_state *op,
 typedef struct libxl__bootloader_state libxl__bootloader_state;
 typedef void libxl__run_bootloader_callback(libxl__egc*,
                                 libxl__bootloader_state*, int rc);
+typedef void libxl__bootloader_console_callback(libxl__egc*,
+                                libxl__bootloader_state*);
 
 struct libxl__bootloader_state {
     /* caller must fill these in, and they must all remain valid */
     libxl__ao *ao;
     libxl__run_bootloader_callback *callback;
+    libxl__bootloader_console_callback *console_available;
     libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
     libxl_device_disk *disk;
     uint32_t domid;
@@ -1691,9 +1694,8 @@ struct libxl__domain_create_state {
     libxl__ao *ao;
     libxl_domain_config *guest_config;
     int restore_fd;
-    libxl_console_ready console_cb;
-    void *console_cb_priv;
     libxl__domain_create_cb *callback;
+    libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..f28d785 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -444,6 +444,7 @@ libxl_event_type = Enumeration("event_type", [
     (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
+    (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -469,4 +470,5 @@ libxl_event = Struct("event",[
            ("operation_complete", Struct(None, [
                                         ("rc", integer),
                                  ])),
+           ("domain_create_console_available", Struct(None, [])),
            ]))])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9e66536..ce52599 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1430,16 +1430,18 @@ static int freemem(libxl_domain_build_info *b_info)
     return ERROR_NOMEM;
 }
 
-static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
+static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv)
 {
     pid_t *pid = priv;
 
+    libxl_event_free(ctx, ev);
+
     *pid = fork();
     if (*pid < 0) {
         perror("unable to fork xenconsole");
-        return ERROR_FAIL;
+        return;
     } else if (*pid > 0)
-        return 0;
+        return;
 
     postfork();
 
@@ -1506,7 +1508,7 @@ static int create_domain(struct domain_create *dom_info)
     int config_len = 0;
     int restore_fd = -1;
     int status = 0;
-    libxl_console_ready cb;
+    const libxl_asyncprogress_how *autoconnect_console_how;
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
@@ -1660,24 +1662,27 @@ start:
         goto error_out;
     }
 
+    libxl_asyncprogress_how autoconnect_console_how_buf;
     if ( dom_info->console_autoconnect ) {
-        cb = autoconnect_console;
+        autoconnect_console_how_buf.callback = autoconnect_console;
+        autoconnect_console_how_buf.for_callback = &child_console_pid;
+        autoconnect_console_how = &autoconnect_console_how_buf;
     }else{
-        cb = NULL;
+        autoconnect_console_how = 0;
     }
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                          cb, &child_console_pid,
-                                          &domid, restore_fd, 0);
+                                          &domid, restore_fd,
+                                          0, autoconnect_console_how);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
          */
         restore_file = NULL;
     }else{
-        ret = libxl_domain_create_new(ctx, &d_config,
-                                      cb, &child_console_pid, &domid, 0);
+        ret = libxl_domain_create_new(ctx, &d_config, &domid,
+                                      0, autoconnect_console_how);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZH-0003r1-1o; Mon, 16 Apr 2012 17:18:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZA-0003g5-1d
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:17 +0000
Received: from [85.158.139.83:5776] by server-7.bemta-5.messagelabs.com id
	9F/CC-16195-7545C8F4; Mon, 16 Apr 2012 17:18:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334596693!23973070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14681 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kE-7N; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dr-5h;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:46 +0100
Message-ID: <1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] =?utf-8?q?=5BPATCH_04/24=5D_autoconf=3A_trim_the_conf?=
	=?utf-8?q?igure_script=3B_use_autoheader?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVtb3ZlIGEgbG90IG9mIHVubmVjZXNzYXJ5IHRlc3RzLiAgU3BlY2lmaWNhbGx5LCB3ZSBubyBs
b25nZXIgdGVzdApmb3Igc3RhbmRhcmQgUE9TSVggZmFjaWxpdGllcyB3aGljaCB3ZSBleHBlY3Qg
dG8gYmUgcHJvdmlkZWQKZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNhc2Ug
aGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgoKU3dpdGNoIHRvIGdlbmVyYXRpbmcgY29uZmlnLmgu
aW4gd2l0aCBhdXRvaGVhZGVyLgoKU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNr
c29uQGV1LmNpdHJpeC5jb20+CkNjOiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51
cGMuZWR1PgotLS0KIGF1dG9nZW4uc2ggICAgICAgICB8ICAgIDEgKwogdG9vbHMvY29uZmlnLmgu
aW4gIHwgICA3MyArLQogdG9vbHMvY29uZmlndXJlICAgIHwgODYwNCArKysrKysrKysrKysrKysr
Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiB0b29scy9jb25maWd1cmUuYWMg
fCAgIDYxICstCiA0IGZpbGVzIGNoYW5nZWQsIDI4NzIgaW5zZXJ0aW9ucygrKSwgNTg2NyBkZWxl
dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hdXRvZ2VuLnNoIGIvYXV0b2dlbi5zaAppbmRleCBjMjg4
YjcxLi41OGE3MWNlIDEwMDc1NQotLS0gYS9hdXRvZ2VuLnNoCisrKyBiL2F1dG9nZW4uc2gKQEAg
LTEsMyArMSw0IEBACiAjIS9iaW4vc2ggLWUKIGNkIHRvb2xzCiBhdXRvY29uZgorYXV0b2hlYWRl
cgpkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlnLmguaW4gYi90b29scy9jb25maWcuaC5pbgppbmRl
eCBmOGY5NmRjLi4xN2M4OTEzIDEwMDY0NAotLS0gYS90b29scy9jb25maWcuaC5pbgorKysgYi90
b29scy9jb25maWcuaC5pbgpAQCAtMSwxOSArMSw2NCBAQAotLyoKLSAqIENvcHlyaWdodCAoQykg
MjAxMgotICoKLSAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlz
dHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5Ci0gKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdO
VSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQKLSAqIGJ5IHRoZSBG
cmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IHZlcnNpb24gMi4xIG9ubHkuIHdpdGggdGhlIHNwZWNp
YWwKLSAqIGV4Y2VwdGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBpbiBmaWxlIExJQ0VOU0UuCi0g
KgotICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2ls
bCBiZSB1c2VmdWwsCi0gKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgotICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9S
IEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQotICogR05VIExlc3NlciBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCi0gKi8KKy8qIGNvbmZpZy5oLmluLiAgR2Vu
ZXJhdGVkIGZyb20gY29uZmlndXJlLmFjIGJ5IGF1dG9oZWFkZXIuICAqLworCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGludHR5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVm
IEhBVkVfSU5UVFlQRVNfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGNyeXB0
bycgbGlicmFyeSAoLWxjcnlwdG8pLiAqLworI3VuZGVmIEhBVkVfTElCQ1JZUFRPCisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgeWFqbCcgbGlicmFyeSAoLWx5YWpsKS4gKi8KKyN1
bmRlZiBIQVZFX0xJQllBSkwKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB6JyBs
aWJyYXJ5ICgtbHopLiAqLworI3VuZGVmIEhBVkVfTElCWgorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPG1lbW9yeS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01FTU9S
WV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkaW50Lmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfU1RESU5UX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzdGRsaWIuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERMSUJfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0cmluZ3MuaD4gaGVhZGVyIGZpbGUu
ICovCisjdW5kZWYgSEFWRV9TVFJJTkdTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDxzdHJpbmcuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVFJJTkdfSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0Lmg+IGhlYWRlciBmaWxlLiAq
LworI3VuZGVmIEhBVkVfU1lTX1NUQVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN5cy90eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19UWVBFU19I
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8dW5pc3RkLmg+IGhlYWRlciBmaWxl
LiAqLworI3VuZGVmIEhBVkVfVU5JU1REX0gKIAogLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDx5YWpsL3lhamxfdmVyc2lvbi5oPiBoZWFkZXIgZmlsZS4gKi8KICN1bmRlZiBIQVZFX1lB
SkxfWUFKTF9WRVJTSU9OX0gKIAotLyogRGVmaW5lIGN1cnNlcyBoZWFkZXIgdG8gaW5jbHVkZS4g
Ki8KKy8qIERlZmluZSBjdXJzZXMgaGVhZGVyIHRvIHVzZSAqLwogI3VuZGVmIElOQ0xVREVfQ1VS
U0VTX0gKKworLyogRGVmaW5lIHRvIHRoZSBhZGRyZXNzIHdoZXJlIGJ1ZyByZXBvcnRzIGZvciB0
aGlzIHBhY2thZ2Ugc2hvdWxkIGJlIHNlbnQuICovCisjdW5kZWYgUEFDS0FHRV9CVUdSRVBPUlQK
KworLyogRGVmaW5lIHRvIHRoZSBmdWxsIG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVm
IFBBQ0tBR0VfTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFtZSBhbmQgdmVyc2lvbiBv
ZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9TVFJJTkcKKworLyogRGVmaW5lIHRv
IHRoZSBvbmUgc3ltYm9sIHNob3J0IG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBB
Q0tBR0VfVEFSTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGhvbWUgcGFnZSBmb3IgdGhpcyBwYWNr
YWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfVVJMCisKKy8qIERlZmluZSB0byB0aGUgdmVyc2lvbiBv
ZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9WRVJTSU9OCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSBBTlNJIEMgaGVhZGVyIGZpbGVzLiAqLworI3VuZGVmIFNURENf
SEVBREVSUwpkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlndXJlIGIvdG9vbHMvY29uZmlndXJlCmlu
ZGV4IDg2NjE4ZjUuLjg3NjVmMjAgMTAwNzU1Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZQorKysgYi90
b29scy9jb25maWd1cmUKQEAgLTU5NSwxMiArNTk1LDggQEAgYWNfaW5jbHVkZXNfZGVmYXVsdD0i
XAogIyBpbmNsdWRlIDx1bmlzdGQuaD4KICNlbmRpZiIKIAotYWNfaGVhZGVyX2xpc3Q9Ci1hY19m
dW5jX2xpc3Q9CiBhY19zdWJzdF92YXJzPSdMVExJQk9CSlMKLVBPV19MSUIKIExJQk9CSlMKLUFM
TE9DQQogbGliaWNvbnYKIFBUSFJFQURfTElCUwogUFRIUkVBRF9MREZMQUdTCkBAIC02MTYsNiAr
NjEyLDkgQEAgUEtHX0NPTkZJR19MSUJESVIKIFBLR19DT05GSUdfUEFUSAogUEtHX0NPTkZJRwog
Q1VSU0VTX0xJQlMKK0VHUkVQCitHUkVQCitDUFAKIFBZVEhPTlBBVEgKIE9DQU1MQlVJTEQKIE9D
QU1MRE9DCkBAIC02MzQsOCArNjMzLDEzIEBAIElOU1RBTExfREFUQQogSU5TVEFMTF9TQ1JJUFQK
IElOU1RBTExfUFJPR1JBTQogU0VUX01BS0UKLUxOX1MKLVNFRAorT0JKRVhUCitFWEVFWFQKK2Fj
X2N0X0NDCitDUFBGTEFHUworTERGTEFHUworQ0ZMQUdTCitDQwogSUFTTAogQkNDCiBMRDg2CkBA
IC02NjEsMjQgKzY2NSw2IEBAIHhlbmFwaQogdnRwbQogbW9uaXRvcnMKIGdpdGh0dHAKLWhvc3Rf
b3MKLWhvc3RfdmVuZG9yCi1ob3N0X2NwdQotaG9zdAotYnVpbGRfb3MKLWJ1aWxkX3ZlbmRvcgot
YnVpbGRfY3B1Ci1idWlsZAotRUdSRVAKLUdSRVAKLUNQUAotT0JKRVhUCi1FWEVFWFQKLWFjX2N0
X0NDCi1DUFBGTEFHUwotTERGTEFHUwotQ0ZMQUdTCi1DQwogdGFyZ2V0X2FsaWFzCiBob3N0X2Fs
aWFzCiBidWlsZF9hbGlhcwpAQCAtNzMzLDEyICs3MTksNiBAQCBlbmFibGVfZGVidWcKICAgICAg
IGFjX3ByZWNpb3VzX3ZhcnM9J2J1aWxkX2FsaWFzCiBob3N0X2FsaWFzCiB0YXJnZXRfYWxpYXMK
LUNDCi1DRkxBR1MKLUxERkxBR1MKLUxJQlMKLUNQUEZMQUdTCi1DUFAKIFBSRVBFTkRfSU5DTFVE
RVMKIFBSRVBFTkRfTElCCiBBUFBFTkRfSU5DTFVERVMKQEAgLTc1NSw2ICs3MzUsMTIgQEAgQVM4
NgogTEQ4NgogQkNDCiBJQVNMCitDQworQ0ZMQUdTCitMREZMQUdTCitMSUJTCitDUFBGTEFHUwor
Q1BQCiBQS0dfQ09ORklHCiBQS0dfQ09ORklHX1BBVEgKIFBLR19DT05GSUdfTElCRElSCkBAIC0x
MzU4LDEwICsxMzQ0LDYgQEAgRmluZSB0dW5pbmcgb2YgdGhlIGluc3RhbGxhdGlvbiBkaXJlY3Rv
cmllczoKIF9BQ0VPRgogCiAgIGNhdCA8PFxfQUNFT0YKLQotU3lzdGVtIHR5cGVzOgotICAtLWJ1
aWxkPUJVSUxEICAgICBjb25maWd1cmUgZm9yIGJ1aWxkaW5nIG9uIEJVSUxEIFtndWVzc2VkXQot
ICAtLWhvc3Q9SE9TVCAgICAgICBjcm9zcy1jb21waWxlIHRvIGJ1aWxkIHByb2dyYW1zIHRvIHJ1
biBvbiBIT1NUIFtCVUlMRF0KIF9BQ0VPRgogZmkKIApAQCAtMTM4OSwxNCArMTM3MSw2IEBAIE9w
dGlvbmFsIEZlYXR1cmVzOgogICAtLWRpc2FibGUtZGVidWcgICAgICAgICBEaXNhYmxlIGRlYnVn
IGJ1aWxkIG9mIHRvb2xzIChkZWZhdWx0IGlzIEVOQUJMRUQpCiAKIFNvbWUgaW5mbHVlbnRpYWwg
ZW52aXJvbm1lbnQgdmFyaWFibGVzOgotICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQK
LSAgQ0ZMQUdTICAgICAgQyBjb21waWxlciBmbGFncwotICBMREZMQUdTICAgICBsaW5rZXIgZmxh
Z3MsIGUuZy4gLUw8bGliIGRpcj4gaWYgeW91IGhhdmUgbGlicmFyaWVzIGluIGEKLSAgICAgICAg
ICAgICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgotICBMSUJTICAgICAgICBsaWJy
YXJpZXMgdG8gcGFzcyB0byB0aGUgbGlua2VyLCBlLmcuIC1sPGxpYnJhcnk+Ci0gIENQUEZMQUdT
ICAgIChPYmplY3RpdmUpIEMvQysrIHByZXByb2Nlc3NvciBmbGFncywgZS5nLiAtSTxpbmNsdWRl
IGRpcj4gaWYKLSAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5kYXJk
IGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+Ci0gIENQUCAgICAgICAgIEMgcHJlcHJvY2Vzc29yCiAg
IFBSRVBFTkRfSU5DTFVERVMKICAgICAgICAgICAgICAgTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMg
dG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCiAgIFBSRVBFTkRfTElCIExpc3Qgb2Yg
bGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCkKQEAgLTE0
MTUsNiArMTM4OSwxNCBAQCBTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoK
ICAgTEQ4NiAgICAgICAgUGF0aCB0byBsZDg2IHRvb2wKICAgQkNDICAgICAgICAgUGF0aCB0byBi
Y2MgdG9vbAogICBJQVNMICAgICAgICBQYXRoIHRvIGlhc2wgdG9vbAorICBDQyAgICAgICAgICBD
IGNvbXBpbGVyIGNvbW1hbmQKKyAgQ0ZMQUdTICAgICAgQyBjb21waWxlciBmbGFncworICBMREZM
QUdTICAgICBsaW5rZXIgZmxhZ3MsIGUuZy4gLUw8bGliIGRpcj4gaWYgeW91IGhhdmUgbGlicmFy
aWVzIGluIGEKKyAgICAgICAgICAgICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgor
ICBMSUJTICAgICAgICBsaWJyYXJpZXMgdG8gcGFzcyB0byB0aGUgbGlua2VyLCBlLmcuIC1sPGxp
YnJhcnk+CisgIENQUEZMQUdTICAgIChPYmplY3RpdmUpIEMvQysrIHByZXByb2Nlc3NvciBmbGFn
cywgZS5nLiAtSTxpbmNsdWRlIGRpcj4gaWYKKyAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVy
cyBpbiBhIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+CisgIENQUCAgICAgICAg
IEMgcHJlcHJvY2Vzc29yCiAgIFBLR19DT05GSUcgIHBhdGggdG8gcGtnLWNvbmZpZyB1dGlsaXR5
CiAgIFBLR19DT05GSUdfUEFUSAogICAgICAgICAgICAgICBkaXJlY3RvcmllcyB0byBhZGQgdG8g
cGtnLWNvbmZpZydzIHNlYXJjaCBwYXRoCkBAIC0xNzg3LDMxMSArMTc2OSw2IEBAIGZpCiAgIGFz
X2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAogCiB9ICMgYWNfZm5fY190cnlfbGluawotCi0jIGFj
X2ZuX2NfY2hlY2tfZnVuYyBMSU5FTk8gRlVOQyBWQVIKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQotIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3RzLCBzZXR0aW5nIHRoZSBj
YWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkKLWFjX2ZuX2NfY2hlY2tfZnVuYyAoKQotewot
ICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19z
dGFjaz0kYXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
Mi4uLiAiID4mNjsgfQotaWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4g
OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0vKiBE
ZWZpbmUgJDIgdG8gYW4gaW5ub2N1b3VzIHZhcmlhbnQsIGluIGNhc2UgPGxpbWl0cy5oPiBkZWNs
YXJlcyAkMi4KLSAgIEZvciBleGFtcGxlLCBIUC1VWCAxMWkgPGxpbWl0cy5oPiBkZWNsYXJlcyBn
ZXR0aW1lb2ZkYXkuICAqLwotI2RlZmluZSAkMiBpbm5vY3VvdXNfJDIKLQotLyogU3lzdGVtIGhl
YWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVz
LAotICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgJDIgKCk7IGJlbG93LgotICAgIFBy
ZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2lu
Y2UKLSAgICA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMu
ICAqLwotCi0jaWZkZWYgX19TVERDX18KLSMgaW5jbHVkZSA8bGltaXRzLmg+Ci0jZWxzZQotIyBp
bmNsdWRlIDxhc3NlcnQuaD4KLSNlbmRpZgotCi0jdW5kZWYgJDIKLQotLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
Ci0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciAkMiAoKTsKLS8q
IFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGlt
cGxlbWVudHMKLSAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25z
IGFyZSBhY3R1YWxseSBuYW1lZAotICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0
aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLwotI2lmIGRlZmluZWQgX19zdHViXyQyIHx8
IGRlZmluZWQgX19zdHViX19fJDIKLWNob2tlIG1lCi0jZW5kaWYKLQotaW50Ci1tYWluICgpCi17
Ci1yZXR1cm4gJDIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgZXZhbCAiJDM9eWVzIgotZWxzZQotICBldmFs
ICIkMz1ubyIKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLWV2YWwgYWNf
cmVzPVwkJDMKLQkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFs
ICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19s
aW5lbm89OyB1bnNldCBhc19saW5lbm87fQotCi19ICMgYWNfZm5fY19jaGVja19mdW5jCi0KLSMg
YWNfZm5fY19jaGVja190eXBlIExJTkVOTyBUWVBFIFZBUiBJTkNMVURFUwotIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFRlc3RzIHdoZXRoZXIgVFlQRSBl
eGlzdHMgYWZ0ZXIgaGF2aW5nIGluY2x1ZGVkIElOQ0xVREVTLCBzZXR0aW5nIGNhY2hlCi0jIHZh
cmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KLWFjX2ZuX2NfY2hlY2tfdHlwZSAoKQotewotICBhc19s
aW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0k
YXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICQyIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4uLiAi
ID4mNjsgfQotaWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBldmFsICIkMz1ubyIKLSAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwotJDQKLWludAotbWFpbiAoKQotewotaWYgKHNpemVvZiAoJDIpKQotCSByZXR1cm4gMDsK
LSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kNAotaW50Ci1tYWluICgpCi17Ci1pZiAoc2l6
ZW9mICgoJDIpKSkKLQkgICAgcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YK
LWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQotICBldmFs
ICIkMz15ZXMiCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotZXZhbCBhY19yZXM9XCQkMwotCSAgICAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3Jl
cyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFj
azsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFz
X2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2NoZWNrX3R5cGUKLQotIyBhY19mbl9jX2ZpbmRfaW50
WF90IExJTkVOTyBCSVRTIFZBUgotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQotIyBGaW5kcyBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0aCBCSVRTLCBzZXR0aW5n
IGNhY2hlIHZhcmlhYmxlIFZBUgotIyBhY2NvcmRpbmdseS4KLWFjX2ZuX2NfZmluZF9pbnRYX3Qg
KCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19s
aW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpbnQkMl90IiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBpbnQkMl90Li4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0
fVwiIiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0g
IGV2YWwgIiQzPW5vIgotICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAtIG5ldmVyIGNoZWNrIGEg
dHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKLSAgICAgIyB0aGFuIGhhbGYgb2YgdGhl
IGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KLSAgICAgZm9yIGFjX3R5cGUgaW4gaW50JDJfdCAnaW50
JyAnbG9uZyBpbnQnIFwKLQkgJ2xvbmcgbG9uZyBpbnQnICdzaG9ydCBpbnQnICdzaWduZWQgY2hh
cic7IGRvCi0gICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLQkgICAgIGVu
dW0geyBOID0gJDIgLyAyIC0gMSB9OwotaW50Ci1tYWluICgpCi17Ci1zdGF0aWMgaW50IHRlc3Rf
YXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4pIDw8
IE4pIC0gMSkgKiAyICsgMSkpXTsKLXRlc3RfYXJyYXkgWzBdID0gMAotCi0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLQkgICAgICAgIGVudW0geyBOID0g
JDIgLyAyIC0gMSB9OwotaW50Ci1tYWluICgpCi17Ci1zdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEg
LSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIg
KyAxKQotCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwgTikgLSAxKSAq
IDIgKyAyKSldOwotdGVzdF9hcnJheSBbMF0gPSAwCi0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9B
Q0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotCi1lbHNlCi0g
IGNhc2UgJGFjX3R5cGUgaW4gIygKLSAgaW50JDJfdCkgOgotICAgIGV2YWwgIiQzPXllcyIgOzsg
IygKLSAgKikgOgotICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKLWVzYWMKLWZpCi1ybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKLSAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6Ci0K
LWVsc2UKLSAgYnJlYWsKLWZpCi0gICAgIGRvbmUKLWZpCi1ldmFsIGFjX3Jlcz1cJCQzCi0JICAg
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
cmVzIiA+JjUKLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0
YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQg
YXNfbGluZW5vO30KLQotfSAjIGFjX2ZuX2NfZmluZF9pbnRYX3QKLQotIyBhY19mbl9jX2NoZWNr
X21lbWJlciBMSU5FTk8gQUdHUiBNRU1CRVIgVkFSIElOQ0xVREVTCi0jIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgVHJpZXMgdG8gZmluZCBp
ZiB0aGUgZmllbGQgTUVNQkVSIGV4aXN0cyBpbiB0eXBlIEFHR1IsIGFmdGVyIGluY2x1ZGluZwot
IyBJTkNMVURFUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCi1hY19m
bl9jX2NoZWNrX21lbWJlciAoKQotewotICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNf
bGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyLiQzIiA+JjUK
LSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4kMy4uLiAiID4mNjsgfQotaWYgZXZhbCAidGVz
dCBcIlwkeyQ0K3NldH1cIiIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kNQotaW50Ci1tYWluICgpCi17Ci1zdGF0aWMgJDIg
YWNfYWdncjsKLWlmIChhY19hZ2dyLiQzKQotcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19
Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgZXZh
bCAiJDQ9eWVzIgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kNQotaW50Ci1tYWluICgpCi17Ci1zdGF0
aWMgJDIgYWNfYWdncjsKLWlmIChzaXplb2YgYWNfYWdnci4kMykKLXJldHVybiAwOwotICA7Ci0g
IHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0gIGV2YWwgIiQ0PXllcyIKLWVsc2UKLSAgZXZhbCAiJDQ9bm8iCi1maQotcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1m
aQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0Ci1maQotZXZhbCBhY19yZXM9XCQkNAotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFj
X3JlcyIgPiY2OyB9Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9f
c3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19m
bl9jX2NoZWNrX21lbWJlcgotCi0jIGFjX2ZuX2NfZmluZF91aW50WF90IExJTkVOTyBCSVRTIFZB
UgotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgRmluZHMgYW4gdW5z
aWduZWQgaW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJs
ZSBWQVIKLSMgYWNjb3JkaW5nbHkuCi1hY19mbl9jX2ZpbmRfdWludFhfdCAoKQotewotICBhc19s
aW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0k
YXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHVpbnQkMl90IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB1
aW50JDJfdC4uLiAiID4mNjsgfQotaWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBldmFsICIkMz1u
byIKLSAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhhdCBp
cyBwb3RlbnRpYWxseSBzbWFsbGVyCi0gICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3RlZCB0
YXJnZXQgd2lkdGguCi0gICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90ICd1bnNpZ25lZCBpbnQn
ICd1bnNpZ25lZCBsb25nIGludCcgXAotCSAndW5zaWduZWQgbG9uZyBsb25nIGludCcgJ3Vuc2ln
bmVkIHNob3J0IGludCcgJ3Vuc2lnbmVkIGNoYXInOyBkbwotICAgICAgIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRh
Y19pbmNsdWRlc19kZWZhdWx0Ci1pbnQKLW1haW4gKCkKLXsKLXN0YXRpYyBpbnQgdGVzdF9hcnJh
eSBbMSAtIDIgKiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8gMiAt
IDEpID09IDMpXTsKLXRlc3RfYXJyYXkgWzBdID0gMAotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1f
QUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgY2FzZSAk
YWNfdHlwZSBpbiAjKAotICB1aW50JDJfdCkgOgotICAgIGV2YWwgIiQzPXllcyIgOzsgIygKLSAg
KikgOgotICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKLWVzYWMKLWZpCi1ybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgICAgICBp
ZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6Ci0KLWVsc2UKLSAgYnJlYWsK
LWZpCi0gICAgIGRvbmUKLWZpCi1ldmFsIGFjX3Jlcz1cJCQzCi0JICAgICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19l
Y2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFz
X2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KLQot
fSAjIGFjX2ZuX2NfZmluZF91aW50WF90CiBjYXQgPmNvbmZpZy5sb2cgPDxfQUNFT0YKIFRoaXMg
ZmlsZSBjb250YWlucyBhbnkgbWVzc2FnZXMgcHJvZHVjZWQgYnkgY29tcGlsZXJzIHdoaWxlCiBy
dW5uaW5nIGNvbmZpZ3VyZSwgdG8gYWlkIGRlYnVnZ2luZyBpZiBjb25maWd1cmUgbWFrZXMgYSBt
aXN0YWtlLgpAQCAtMjM3NiwxMSArMjA1Myw2IEBAICRhc19lY2hvICIkYXNfbWU6IGNyZWF0aW5n
IGNhY2hlICRjYWNoZV9maWxlIiA+JjY7fQogICA+JGNhY2hlX2ZpbGUKIGZpCiAKLWFzX2ZuX2Fw
cGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy90aW1lLmgiCi1hc19mbl9hcHBlbmQgYWNfaGVhZGVy
X2xpc3QgIiB1bmlzdGQuaCIKLWFzX2ZuX2FwcGVuZCBhY19mdW5jX2xpc3QgIiBhbGFybSIKLWFz
X2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN0ZGxpYi5oIgotYXNfZm5fYXBwZW5kIGFjX2hl
YWRlcl9saXN0ICIgc3lzL3BhcmFtLmgiCiAjIENoZWNrIHRoYXQgdGhlIHByZWNpb3VzIHZhcmlh
YmxlcyBzYXZlZCBpbiB0aGUgY2FjaGUgaGF2ZSBrZXB0IHRoZSBzYW1lCiAjIHZhbHVlLgogYWNf
Y2FjaGVfY29ycnVwdGVkPWZhbHNlCkBAIC0yNDk4LDE2NjEgKzIxNzAsMzUgQEAgQVBQRU5EX0lO
Q0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS4iID4mMjt9CiAKIGZp
CiAKLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29tcGlsZT0nJENDIC1j
ICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNfbGluaz0nJENDIC1v
IGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4k
YWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUK
LWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9
JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgot
ICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgot
ZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBp
biAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2MiCi0gICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZT
Ci0KLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1
Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1m
aQotCi0KLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KLSAgYWNfY3RfQ0M9
JENDCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKLXsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3Jk
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYg
dGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhl
bgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgotICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZl
X0lGUwotCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1pZiB0ZXN0IC1u
ICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9
Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotICBpZiB0ZXN0ICJ4JGFjX2N0
X0NDIiA9IHg7IHRoZW4KLSAgICBDQz0iIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xf
d2FybmVkPXllcyA7OwotZXNhYwotICAgIENDPSRhY19jdF9DQwotICBmaQotZWxzZQotICBDQz0i
JGFjX2N2X3Byb2dfQ0MiCi1maQotCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gICAgICAgICAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1jYzsgYWNfd29yZD0k
MgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0g
IGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1l
bHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGlu
ICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFz
X2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg
JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh
Y19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgotICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwot
Ci1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQot
JGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkK
LQotCi0gIGZpCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
LXNldCBkdW1teSBjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi0gIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRv
Ci0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGlmIHRlc3QgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgotICAgICAg
IGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCi0gICAgICAgY29udGludWUKLSAgICAgZmkKLSAgICBhY19j
dl9wcm9nX0NDPSJjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0g
IGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotaWYgdGVzdCAkYWNfcHJvZ19y
ZWplY3RlZCA9IHllczsgdGhlbgotICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBhdGgsIHNv
IG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCi0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwot
ICBzaGlmdAotICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KLSAgICAjIFdlIGNob3NlIGEgZGlmZmVy
ZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KLSAgICAjIEhvd2V2ZXIsIGl0IGhhcyB0
aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCi0gICAgIyBmaXJz
dCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVsbCBmaWxlIG5h
bWUuCi0gICAgc2hpZnQKLSAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193b3JkJHsxKycg
J30kQCIKLSAgZmkKLWZpCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAi
bm8iID4mNjsgfQotZmkKLQotCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotICBk
bwotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3By
b2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRh
Y190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1l
bHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2
ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3By
ZWZpeCRhY19wcm9nIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAg
ZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1maQotZmkKLUNDPSRhY19jdl9w
cm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9
Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotCi0gICAgdGVzdCAtbiAiJEND
IiAmJiBicmVhawotICBkb25lCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBhY19jdF9D
Qz0kQ0MKLSAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCi1kbwotICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KLXNldCBkdW1teSAkYWNfcHJvZzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By
b2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2df
YWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1l
bHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGlu
ICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFz
X2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg
JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh
Y19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfcHJvZyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
LSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkK
LWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQwotaWYgdGVzdCAtbiAiJGFjX2N0X0ND
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X0NDIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQotZWxzZQotICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQot
JGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCi0KLQotICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJy
ZWFrCi1kb25lCi0KLSAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIK
LSAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXll
czopCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBD
Qz0kYWNfY3RfQ0MKLSAgZmkKLWZpCi0KLWZpCi0KLQotdGVzdCAteiAiJENDIiAmJiB7IHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6
IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KLWFz
X2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQQVRICi1T
ZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KLQotIyBQ
cm92aWRlIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgotJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgdmVyc2lv
biIgPiY1Ci1zZXQgWCAkYWNfY29tcGlsZQotYWNfY29tcGlsZXI9JDIKLWZvciBhY19vcHRpb24g
aW4gLS12ZXJzaW9uIC12IC1WIC1xdmVyc2lvbjsgZG8KLSAgeyB7IGFjX3RyeT0iJGFjX2NvbXBp
bGVyICRhY19vcHRpb24gPiY1IgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8
ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7
Ci1lc2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
ICRhY190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFs
ICIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgotICBhY19zdGF0
dXM9JD8KLSAgaWYgdGVzdCAtcyBjb25mdGVzdC5lcnI7IHRoZW4KLSAgICBzZWQgJzEwYVwKLS4u
LiByZXN0IG9mIHN0ZGVyciBvdXRwdXQgZGVsZXRlZCAuLi4KLSAgICAgICAgIDEwcScgY29uZnRl
c3QuZXJyID5jb25mdGVzdC5lcjEKLSAgICBjYXQgY29uZnRlc3QuZXIxID4mNQotICBmaQotICBy
bSAtZiBjb25mdGVzdC5lcjEgY29uZnRlc3QuZXJyCi0gICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMg
PSAwOyB9Ci1kb25lCi0KLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICBy
ZXR1cm4gMDsKLX0KLV9BQ0VPRgotYWNfY2xlYW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMK
LWFjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5fZmlsZXMgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBi
Lm91dCIKLSMgVHJ5IHRvIGNyZWF0ZSBhbiBleGVjdXRhYmxlIHdpdGhvdXQgLW8gZmlyc3QsIGRp
c3JlZ2FyZCBhLm91dC4KLSMgSXQgd2lsbCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBjb21waWxl
cnMsIGFuZCBmaW5kaW5nIG91dCBhbiBpbnR1aXRpb24KLSMgb2YgZXhlZXh0LgoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv
bXBpbGVyIHdvcmtzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29t
cGlsZXIgd29ya3MuLi4gIiA+JjY7IH0KLWFjX2xpbmtfZGVmYXVsdD1gJGFzX2VjaG8gIiRhY19s
aW5rIiB8IHNlZCAncy8gLW8gKmNvbmZ0ZXN0W14gXSovLydgCi0KLSMgVGhlIHBvc3NpYmxlIG91
dHB1dCBmaWxlczoKLWFjX2ZpbGVzPSJhLm91dCBjb25mdGVzdC5leGUgY29uZnRlc3QgYS5leGUg
YV9vdXQuZXhlIGIub3V0IGNvbmZ0ZXN0LioiCi0KLWFjX3JtZmlsZXM9Ci1mb3IgYWNfZmlsZSBp
biAkYWNfZmlsZXMKLWRvCi0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAgICAqLiRhY19leHQgfCAqLnhj
b2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFw
IHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7Ci0gICAgKiApIGFjX3JtZmlsZXM9
IiRhY19ybWZpbGVzICRhY19maWxlIjs7Ci0gIGVzYWMKLWRvbmUKLXJtIC1mICRhY19ybWZpbGVz
Ci0KLWlmIHsgeyBhY190cnk9IiRhY19saW5rX2RlZmF1bHQiCi1jYXNlICIoKCRhY190cnkiIGlu
Ci0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190
cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hv
IjsgfSA+JjUKLSAgKGV2YWwgIiRhY19saW5rX2RlZmF1bHQiKSAyPiY1Ci0gIGFjX3N0YXR1cz0k
PwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6Ci0gICMgQXV0b2NvbmYt
Mi4xMyBjb3VsZCBzZXQgdGhlIGFjX2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgotIyBTbyBp
Z25vcmUgYSB2YWx1ZSBvZiBgbm8nLCBvdGhlcndpc2UgdGhpcyB3b3VsZCBsZWFkIHRvIGBFWEVF
WFQgPSBubycKLSMgaW4gYSBNYWtlZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUgYWNfY3Zf
ZXhlZXh0IGlmIGl0IHdhcyBjYWNoZWQsCi0jIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNob3J0LWNp
cmN1aXQgdGhpcyB0ZXN0IGZvciBjb21waWxlcnMgdW5rbm93biB0bwotIyBBdXRvY29uZi4KLWZv
ciBhY19maWxlIGluICRhY19maWxlcyAnJwotZG8KLSAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNv
bnRpbnVlCi0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50
ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYg
fCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApCi0JOzsKLSAgICBbYWJdLm91dCApCi0JIyBXZSBmb3Vu
ZCB0aGUgZGVmYXVsdCBleGVjdXRhYmxlLCBidXQgZXhlZXh0PScnIGlzIG1vc3QKLQkjIGNlcnRh
aW5seSByaWdodC4KLQlicmVhazs7Ci0gICAgKi4qICkKLQlpZiB0ZXN0ICIke2FjX2N2X2V4ZWV4
dCtzZXR9IiA9IHNldCAmJiB0ZXN0ICIkYWNfY3ZfZXhlZXh0IiAhPSBubzsKLQl0aGVuIDo7IGVs
c2UKLQkgICBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AK
LQlmaQotCSMgV2Ugc2V0IGFjX2N2X2V4ZWV4dCBoZXJlIGJlY2F1c2UgdGhlIGxhdGVyIHRlc3Qg
Zm9yIGl0IGlzIG5vdAotCSMgc2FmZTogY3Jvc3MgY29tcGlsZXJzIG1heSBub3QgYWRkIHRoZSBz
dWZmaXggaWYgZ2l2ZW4gYW4gYC1vJwotCSMgYXJndW1lbnQsIHNvIHdlIG1heSBuZWVkIHRvIGtu
b3cgaXQgYXQgdGhhdCBwb2ludCBhbHJlYWR5LgotCSMgRXZlbiBpZiB0aGlzIHNlY3Rpb24gbG9v
a3MgY3J1ZnR5OiBpdCBoYXMgdGhlIGFkdmFudGFnZSBvZgotCSMgYWN0dWFsbHkgd29ya2luZy4K
LQlicmVhazs7Ci0gICAgKiApCi0JYnJlYWs7OwotICBlc2FjCi1kb25lCi10ZXN0ICIkYWNfY3Zf
ZXhlZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KLQotZWxzZQotICBhY19maWxlPScnCi1maQot
aWYgdGVzdCAteiAiJGFjX2ZpbGUiOyB0aGVuIDoKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci0k
YXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKLXNlZCAncy9eL3wgLycg
Y29uZnRlc3QuJGFjX2V4dCA+JjUKLQoteyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBl
cnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBj
YW5ub3QgY3JlYXRlIGV4ZWN1dGFibGVzCi1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRh
aWxzIiAiJExJTkVOTyIgNSA7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Ci0kYXNfZWNobyAieWVzIiA+JjY7IH0KLWZp
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBD
IGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZSIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUuLi4gIiA+JjY7IH0K
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfZmls
ZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2ZpbGUiID4mNjsgfQotYWNfZXhlZXh0PSRhY19jdl9leGVl
eHQKLQotcm0gLWYgLXIgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25mdGVzdCRhY19jdl9leGVl
eHQgYi5vdXQKLWFjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhl
Y3V0YWJsZXMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBleGVjdXRh
Ymxlcy4uLiAiID4mNjsgfQotaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCi1jYXNlICIoKCRhY190
cnkiIGluCi0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAq
KSBhY190cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3Ry
eV9lY2hvIjsgfSA+JjUKLSAgKGV2YWwgIiRhY19saW5rIikgMj4mNQotICBhY19zdGF0dXM9JD8K
LSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1
cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgotICAjIElmIGJvdGggYGNv
bmZ0ZXN0LmV4ZScgYW5kIGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAod2VsbCwgb2JzZXJ2YWJs
ZSkKLSMgY2F0Y2ggYGNvbmZ0ZXN0LmV4ZScuICBGb3IgaW5zdGFuY2Ugd2l0aCBDeWd3aW4sIGBs
cyBjb25mdGVzdCcgd2lsbAotIyB3b3JrIHByb3Blcmx5IChpLmUuLCByZWZlciB0byBgY29uZnRl
c3QuZXhlJyksIHdoaWxlIGl0IHdvbid0IHdpdGgKLSMgYHJtJy4KLWZvciBhY19maWxlIGluIGNv
bmZ0ZXN0LmV4ZSBjb25mdGVzdCBjb25mdGVzdC4qOyBkbwotICB0ZXN0IC1mICIkYWNfZmlsZSIg
fHwgY29udGludWUKLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICouJGFjX2V4dCB8ICoueGNvZmYg
fCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAq
LmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKLSAgICAqLiogKSBhY19jdl9leGVleHQ9
YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKLQkgIGJyZWFrOzsKLSAgICAqICkg
YnJlYWs7OwotICBlc2FjCi1kb25lCi1lbHNlCi0gIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8gIiRh
c19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBjb21wdXRlIHN1ZmZpeCBvZiBleGVjdXRhYmxlczogY2Fubm90IGNvbXBpbGUgYW5kIGxpbmsK
LVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQotZmkK
LXJtIC1mIGNvbmZ0ZXN0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dAoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9leGVleHQiID4mNQotJGFzX2Vj
aG8gIiRhY19jdl9leGVleHQiID4mNjsgfQotCi1ybSAtZiBjb25mdGVzdC4kYWNfZXh0Ci1FWEVF
WFQ9JGFjX2N2X2V4ZWV4dAotYWNfZXhlZXh0PSRFWEVFWFQKLWNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRl
IDxzdGRpby5oPgotaW50Ci1tYWluICgpCi17Ci1GSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5v
dXQiLCAidyIpOwotIHJldHVybiBmZXJyb3IgKGYpIHx8IGZjbG9zZSAoZikgIT0gMDsKLQotICA7
Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1hY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVz
IGNvbmZ0ZXN0Lm91dCIKLSMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIgcHJvZHVjZXMgZXhlY3V0
YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwgZWl0aGVyCi0jIHRoZSBjb21waWxlciBpcyBicm9r
ZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZyIgPiY1Ci0k
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmcuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciICE9IHllczsgdGhlbgotICB7IHsgYWNf
dHJ5PSIkYWNfbGluayIKLWNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwq
KSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNh
YwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNf
dHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFj
X2xpbmsiKSAyPiY1Ci0gIGFjX3N0YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0g
MDsgfQotICBpZiB7IGFjX3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVleHQnCi0gIHsgeyBjYXNl
ICIoKCRhY190cnkiIGluCi0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190
cnk7OwotICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNo
byAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKLSAgKGV2YWwgIiRhY190cnkiKSAyPiY1Ci0gIGFjX3N0
YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgfTsgdGhlbgotICAgIGNy
b3NzX2NvbXBpbGluZz1ubwotICBlbHNlCi0gICAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIg
PSBtYXliZTsgdGhlbgotCWNyb3NzX2NvbXBpbGluZz15ZXMKLSAgICBlbHNlCi0JeyB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIg
PiY1Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19m
bl9lcnJvciAkPyAiY2Fubm90IHJ1biBDIGNvbXBpbGVkIHByb2dyYW1zLgotSWYgeW91IG1lYW50
IHRvIGNyb3NzIGNvbXBpbGUsIHVzZSBcYC0taG9zdCcuCi1TZWUgXGBjb25maWcubG9nJyBmb3Ig
bW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KLSAgICBmaQotICBmaQotZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkY3Jvc3NfY29tcGlsaW5n
IiA+JjUKLSRhc19lY2hvICIkY3Jvc3NfY29tcGlsaW5nIiA+JjY7IH0KLQotcm0gLWYgY29uZnRl
c3QuJGFjX2V4dCBjb25mdGVzdCRhY19jdl9leGVleHQgY29uZnRlc3Qub3V0Ci1hY19jbGVhbl9m
aWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3VmZml4IG9mIG9iamVjdCBmaWxlcyIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3Igc3VmZml4IG9mIG9iamVjdCBmaWxlcy4uLiAiID4mNjsgfQot
aWYgdGVzdCAiJHthY19jdl9vYmpleHQrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQotewot
Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLXJtIC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qu
b2JqCi1pZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIKLWNhc2UgIigoJGFjX3RyeSIgaW4KLSAg
KlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9l
Y2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9
ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPiY1Ci0gIGFjX3N0YXR1cz0kPwotICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUK
LSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6Ci0gIGZvciBhY19maWxlIGluIGNvbmZ0
ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCi0gIHRlc3QgLWYgIiRhY19maWxlIiB8
fCBjb250aW51ZTsKLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICouJGFjX2V4dCB8ICoueGNvZmYg
fCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAq
LmluZiB8ICouZFNZTSApIDs7Ci0gICAgKikgYWNfY3Zfb2JqZXh0PWBleHByICIkYWNfZmlsZSIg
OiAnLipcLlwoLipcKSdgCi0gICAgICAgYnJlYWs7OwotICBlc2FjCi1kb25lCi1lbHNlCi0gICRh
c19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQotc2VkICdzL14vfCAvJyBj
b25mdGVzdC4kYWNfZXh0ID4mNQotCi17IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVy
cm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KLWFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0
ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3QgY29tcGlsZQotU2VlIFxgY29uZmlnLmxv
ZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci1maQotcm0gLWYgY29uZnRlc3Qu
JGFjX2N2X29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9vYmpleHQiID4mNQotJGFzX2VjaG8g
IiRhY19jdl9vYmpleHQiID4mNjsgfQotT0JKRVhUPSRhY19jdl9vYmpleHQKLWFjX29iamV4dD0k
T0JKRVhUCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0fSIgPSBzZXQ7IHRoZW4g
OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWlu
dAotbWFpbiAoKQotewotI2lmbmRlZiBfX0dOVUNfXwotICAgICAgIGNob2tlIG1lCi0jZW5kaWYK
LQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIk
TElORU5PIjsgdGhlbiA6Ci0gIGFjX2NvbXBpbGVyX2dudT15ZXMKLWVsc2UKLSAgYWNfY29tcGls
ZXJfZ251PW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1hY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251
Ci0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfY19jb21waWxlcl9n
bnUiID4mNjsgfQotaWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCi0gIEdDQz15
ZXMKLWVsc2UKLSAgR0NDPQotZmkKLWFjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KLWFjX3Nh
dmVfQ0ZMQUdTPSRDRkxBR1MKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3Byb2dfY2NfZytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2Ci1lbHNlCi0gIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZwotICAg
YWNfY193ZXJyb3JfZmxhZz15ZXMKLSAgIGFjX2N2X3Byb2dfY2NfZz1ubwotICAgQ0ZMQUdTPSIt
ZyIKLSAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsK
LX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBh
Y19jdl9wcm9nX2NjX2c9eWVzCi1lbHNlCi0gIENGTEFHUz0iIgotICAgICAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwot
Ci1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0KLWVsc2UKLSAgYWNfY193ZXJyb3Jf
ZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCi0JIENGTEFHUz0iLWciCi0JIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf
Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9wcm9nX2NjX2c9eWVz
Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZl
X2Nfd2Vycm9yX2ZsYWcKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3Byb2df
Y2NfZyIgPiY2OyB9Ci1pZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCi0gIENG
TEFHUz0kYWNfc2F2ZV9DRkxBR1MKLWVsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0
aGVuCi0gIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItZyAtTzIiCi0g
IGVsc2UKLSAgICBDRkxBR1M9Ii1nIgotICBmaQotZWxzZQotICBpZiB0ZXN0ICIkR0NDIiA9IHll
czsgdGhlbgotICAgIENGTEFHUz0iLU8yIgotICBlbHNlCi0gICAgQ0ZMQUdTPQotICBmaQotZmkK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBhY19jdl9wcm9nX2NjX2M4OT1ubwotYWNfc2F2ZV9DQz0kQ0MKLWNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KLSNpbmNsdWRlIDxzdGRhcmcuaD4KLSNpbmNsdWRlIDxzdGRpby5oPgotI2luY2x1
ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5cy9zdGF0Lmg+Ci0vKiBNb3N0IG9mIHRoZSBm
b2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICov
Ci1zdHJ1Y3QgYnVmIHsgaW50IHg7IH07Ci1GSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAq
LCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOwotc3RhdGljIGNoYXIgKmUgKHAsIGkpCi0gICAgIGNoYXIg
KipwOwotICAgICBpbnQgaTsKLXsKLSAgcmV0dXJuIHBbaV07Ci19Ci1zdGF0aWMgY2hhciAqZiAo
Y2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCi17Ci0gIGNoYXIgKnM7
Ci0gIHZhX2xpc3QgdjsKLSAgdmFfc3RhcnQgKHYscCk7Ci0gIHMgPSBnIChwLCB2YV9hcmcgKHYs
aW50KSk7Ci0gIHZhX2VuZCAodik7Ci0gIHJldHVybiBzOwotfQotCi0vKiBPU0YgNC4wIENvbXBh
cSBjYyBpcyBzb21lIHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcwotICAg
ZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0
ZXIgY29uc3RhbnRzLgotICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0
ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCi0gICBhcyAneCcuICBUaGUgZm9sbG93
aW5nIGluZHVjZXMgYW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0Ci0gICBwcm9w
ZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1
ZSwgZm9yIGFuCi0gICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3Jp
dGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKLSAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAt
c3RkLiAgKi8KLWludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07Ci0KLS8q
IElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFj
ZXMgbWFjcm8gcGFyYW1ldGVycwotICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25z
dGFudHMuICAqLwotI2RlZmluZSBGT08oeCkgJ3gnCi1pbnQgeGxjNl9jY19hcnJheVtGT08oYSkg
PT0gJ3gnID8gMSA6IC0xXTsKLQotaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7Ci1zdHJ1Y3Qg
czEge2ludCAoKmYpIChpbnQgYSk7fTsKLXN0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9
OwotaW50IHBhaXJuYW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBz
dHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQsIGludCk7Ci1pbnQgYXJnYzsKLWNoYXIgKiphcmd2Owot
aW50Ci1tYWluICgpCi17Ci1yZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYg
KGUsIGFyZ3YsIDEpICE9IGFyZ3ZbMV07Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWZv
ciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKLQkt
QWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgotZG8KLSAgQ0M9
IiRhY19zYXZlX0NDICRhY19hcmciCi0gIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKLSAgYWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKLSAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4
OSIgIT0gInhubyIgJiYgYnJlYWsKLWRvbmUKLXJtIC1mIGNvbmZ0ZXN0LiRhY19leHQKLUNDPSRh
Y19zYXZlX0NDCi0KLWZpCi0jIEFDX0NBQ0hFX1ZBTAotY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4
OSIgaW4KLSAgeCkKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQotJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0g
OzsKLSAgeG5vKQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1Ci0kYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7
OwotICAqKQotICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgotICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODki
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Ci1lc2FjCi1pZiB0
ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgotCi1maQotCi1hY19leHQ9
YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRD
UFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRh
Y19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElC
UyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Ci0KLQotYWNfZXh0
PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAk
Q1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19saW5rPSckQ0MgLW8gY29uZnRlc3Qk
YWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJ
QlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBob3cgdG8gcnVuIHRoZSBD
IHByZXByb2Nlc3NvciIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBob3cgdG8gcnVuIHRoZSBD
IHByZXByb2Nlc3Nvci4uLiAiID4mNjsgfQotIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1l
cyBhIGRpcmVjdG9yeS4KLWlmIHRlc3QgLW4gIiRDUFAiICYmIHRlc3QgLWQgIiRDUFAiOyB0aGVu
Ci0gIENQUD0KLWZpCi1pZiB0ZXN0IC16ICIkQ1BQIjsgdGhlbgotICBpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfQ1BQK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKLWVsc2UKLSAgICAgICMgRG91YmxlIHF1b3RlcyBiZWNhdXNlIENQUCBuZWVkcyB0byBiZSBl
eHBhbmRlZAotICAgIGZvciBDUFAgaW4gIiRDQyAtRSIgIiRDQyAtRSAtdHJhZGl0aW9uYWwtY3Bw
IiAiL2xpYi9jcHAiCi0gICAgZG8KLSAgICAgIGFjX3ByZXByb2Nfb2s9ZmFsc2UKLWZvciBhY19j
X3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwotZG8KLSAgIyBVc2UgYSBoZWFkZXIgZmlsZSB0
aGF0IGNvbWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGliYwotICAjIHdpdGggYSBmcmVz
aCBjcm9zcy1jb21waWxlciB3b3Jrcy4KLSAgIyBQcmVmZXIgPGxpbWl0cy5oPiB0byA8YXNzZXJ0
Lmg+IGlmIF9fU1REQ19fIGlzIGRlZmluZWQsIHNpbmNlCi0gICMgPGxpbWl0cy5oPiBleGlzdHMg
ZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgotICAjIE9uIHRoZSBOZVhULCBjYyAtRSBy
dW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVyJ3MgcGFyc2VyLAotICAjIG5vdCBqdXN0
IHRocm91Z2ggY3BwLiAiU3ludGF4IGVycm9yIiBpcyBoZXJlIHRvIGNhdGNoIHRoaXMgY2FzZS4K
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotI2lmZGVmIF9fU1REQ19fCi0jIGluY2x1ZGUgPGxpbWl0cy5oPgotI2Vs
c2UKLSMgaW5jbHVkZSA8YXNzZXJ0Lmg+Ci0jZW5kaWYKLQkJICAgICBTeW50YXggZXJyb3IKLV9B
Q0VPRgotaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6Ci0KLWVsc2UKLSAgIyBC
cm9rZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgotY29udGludWUKLWZpCi1ybSAtZiBjb25mdGVz
dC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0KLSAgIyBPSywgd29ya3Mgb24gc2Fu
ZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50IGhlYWRlcnMKLSAgIyBjYW4g
YmUgZGV0ZWN0ZWQgYW5kIGhvdy4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPGFjX25vbmV4aXN0
ZW50Lmg+Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgotICAj
IEJyb2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgotY29udGludWUKLWVsc2UKLSAgIyBQ
YXNzZXMgYm90aCB0ZXN0cy4KLWFjX3ByZXByb2Nfb2s9OgotYnJlYWsKLWZpCi1ybSAtZiBjb25m
dGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0KLWRvbmUKLSMgQmVjYXVzZSBv
ZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBjbGVhbmluZyBjb2RlIHdhcyBza2lwcGVk
Lgotcm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX2V4dAotaWYgJGFj
X3ByZXByb2Nfb2s7IHRoZW4gOgotICBicmVhawotZmkKLQotICAgIGRvbmUKLSAgICBhY19jdl9w
cm9nX0NQUD0kQ1BQCi0KLWZpCi0gIENQUD0kYWNfY3ZfcHJvZ19DUFAKLWVsc2UKLSAgYWNfY3Zf
cHJvZ19DUFA9JENQUAotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQ1BQIiA+JjUKLSRhc19lY2hvICIkQ1BQIiA+JjY7IH0KLWFjX3ByZXByb2Nf
b2s9ZmFsc2UKLWZvciBhY19jX3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwotZG8KLSAgIyBV
c2UgYSBoZWFkZXIgZmlsZSB0aGF0IGNvbWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGli
YwotICAjIHdpdGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jrcy4KLSAgIyBQcmVmZXIgPGxp
bWl0cy5oPiB0byA8YXNzZXJ0Lmg+IGlmIF9fU1REQ19fIGlzIGRlZmluZWQsIHNpbmNlCi0gICMg
PGxpbWl0cy5oPiBleGlzdHMgZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgotICAjIE9u
IHRoZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVyJ3MgcGFy
c2VyLAotICAjIG5vdCBqdXN0IHRocm91Z2ggY3BwLiAiU3ludGF4IGVycm9yIiBpcyBoZXJlIHRv
IGNhdGNoIHRoaXMgY2FzZS4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmZGVmIF9fU1REQ19fCi0jIGluY2x1
ZGUgPGxpbWl0cy5oPgotI2Vsc2UKLSMgaW5jbHVkZSA8YXNzZXJ0Lmg+Ci0jZW5kaWYKLQkJICAg
ICBTeW50YXggZXJyb3IKLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6Ci0KLWVsc2UKLSAgIyBCcm9rZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgotY29udGludWUK
LWZpCi1ybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0KLSAg
IyBPSywgd29ya3Mgb24gc2FuZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50
IGhlYWRlcnMKLSAgIyBjYW4gYmUgZGV0ZWN0ZWQgYW5kIGhvdy4KLSAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lu
Y2x1ZGUgPGFjX25vbmV4aXN0ZW50Lmg+Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJ
TkVOTyI7IHRoZW4gOgotICAjIEJyb2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgotY29u
dGludWUKLWVsc2UKLSAgIyBQYXNzZXMgYm90aCB0ZXN0cy4KLWFjX3ByZXByb2Nfb2s9OgotYnJl
YWsKLWZpCi1ybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0K
LWRvbmUKLSMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBjbGVhbmlu
ZyBjb2RlIHdhcyBza2lwcGVkLgotcm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX2V4dAotaWYgJGFjX3ByZXByb2Nfb2s7IHRoZW4gOgotCi1lbHNlCi0gIHsgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mNQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNf
Zm5fZXJyb3IgJD8gIkMgcHJlcHJvY2Vzc29yIFwiJENQUFwiIGZhaWxzIHNhbml0eSBjaGVjawot
U2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci1maQot
Ci1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBpbGU9JyRDQyAtYyAk
Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xpbms9JyRDQyAtbyBj
b25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFj
X2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Ci0K
LQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
Z3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgot
ICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UKLSAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBw
YXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKLSAgYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRP
Ui91c3IveHBnNC9iaW4KLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfcHJvZyBpbiBncmVwIGdncmVwOyBkbwotICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICAgICAg
YWNfcGF0aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgotICAgICAgeyB0ZXN0
IC1mICIkYWNfcGF0aF9HUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBj
b250aW51ZQotIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0
IGlzIGZvdW5kLgotICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAotY2FzZSBgIiRhY19w
YXRoX0dSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgotKkdOVSopCi0gIGFjX2N2X3BhdGhfR1JFUD0i
JGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7OwotKikKLSAgYWNfY291bnQ9MAot
ICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKLSAgd2hpbGUgOgotICBkbwot
ICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCi0gICAg
bXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgotICAgIGNwICJjb25mdGVzdC5pbiIgImNv
bmZ0ZXN0Lm5sIgotICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRh
Y19wYXRoX0dSRVAiIC1lICdHUkVQJCcgLWUgJy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0
Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKLSAgICBkaWZmICJjb25m
dGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCi0gICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCi0gICAgaWYgdGVzdCAk
YWNfY291bnQgLWd0ICR7YWNfcGF0aF9HUkVQX21heC0wfTsgdGhlbgotICAgICAgIyBCZXN0IG9u
ZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCi0gICAg
ICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiCi0gICAgICBhY19wYXRoX0dSRVBfbWF4
PSRhY19jb3VudAotICAgIGZpCi0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMg
bW9yZSB0aGFuIGVub3VnaAotICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawotICBk
b25lCi0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVz
dC5vdXQ7OwotZXNhYwotCi0gICAgICAkYWNfcGF0aF9HUkVQX2ZvdW5kICYmIGJyZWFrIDMKLSAg
ICBkb25lCi0gIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotICBpZiB0ZXN0IC16ICIk
YWNfY3ZfcGF0aF9HUkVQIjsgdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxl
IGdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmlu
IiAiJExJTkVOTyIgNQotICBmaQotZWxzZQotICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKLWZpCi0K
LWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X3BhdGhfR1JFUCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9Ci0g
R1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9FR1JFUCtzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlm
IGVjaG8gYSB8ICRHUkVQIC1FICcoYXxiKScgPi9kZXYvbnVsbCAyPiYxCi0gICB0aGVuIGFjX2N2
X3BhdGhfRUdSRVA9IiRHUkVQIC1FIgotICAgZWxzZQotICAgICBpZiB0ZXN0IC16ICIkRUdSRVAi
OyB0aGVuCi0gIGFjX3BhdGhfRUdSRVBfZm91bmQ9ZmFsc2UKLSAgIyBMb29wIHRocm91Z2ggdGhl
IHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKLSAgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRI
X1NFUEFSQVRPUi91c3IveHBnNC9iaW4KLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfcHJvZyBpbiBlZ3JlcDsgZG8KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
ICAgIGFjX3BhdGhfRUdSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCi0gICAgICB7
IHRlc3QgLWYgIiRhY19wYXRoX0VHUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9FR1JFUCI7
IH0gfHwgY29udGludWUKLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0VHUkVQIGFuZCBzZWxlY3Qg
aXQgaWYgaXQgaXMgZm91bmQuCi0gICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9FR1JFUAotY2Fz
ZSBgIiRhY19wYXRoX0VHUkVQIiAtLXZlcnNpb24gMj4mMWAgaW4KLSpHTlUqKQotICBhY19jdl9w
YXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIgYWNfcGF0aF9FR1JFUF9mb3VuZD06OzsKLSopCi0g
IGFjX2NvdW50PTAKLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCi0gIHdo
aWxlIDoKLSAgZG8KLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRl
c3QudG1wIgotICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKLSAgICBjcCAiY29u
ZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKLSAgICAkYXNfZWNobyAnRUdSRVAnID4+ICJjb25mdGVz
dC5ubCIKLSAgICAiJGFjX3BhdGhfRUdSRVAiICdFR1JFUCQnIDwgImNvbmZ0ZXN0Lm5sIiA+ImNv
bmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKLSAgICBkaWZmICJjb25mdGVzdC5vdXQi
ICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCi0gICAgYXNfZm5fYXJpdGgg
JGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCi0gICAgaWYgdGVzdCAkYWNfY291bnQg
LWd0ICR7YWNfcGF0aF9FR1JFUF9tYXgtMH07IHRoZW4KLSAgICAgICMgQmVzdCBvbmUgc28gZmFy
LCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQotICAgICAgYWNfY3Zf
cGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiCi0gICAgICBhY19wYXRoX0VHUkVQX21heD0kYWNf
Y291bnQKLSAgICBmaQotICAgICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUg
dGhhbiBlbm91Z2gKLSAgICB0ZXN0ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKLSAgZG9uZQot
ICBybSAtZiBjb25mdGVzdC5pbiBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0
OzsKLWVzYWMKLQotICAgICAgJGFjX3BhdGhfRUdSRVBfZm91bmQgJiYgYnJlYWsgMwotICAgIGRv
bmUKLSAgZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0gIGlmIHRlc3QgLXogIiRhY19j
dl9wYXRoX0VHUkVQIjsgdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGVn
cmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIg
IiRMSU5FTk8iIDUKLSAgZmkKLWVsc2UKLSAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAKLWZpCi0K
LSAgIGZpCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9wYXRoX0VHUkVQIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcGF0aF9FR1JFUCIg
PiY2OyB9Ci0gRUdSRVA9IiRhY19jdl9wYXRoX0VHUkVQIgotCi0KLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMi
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3N0ZGMrc2V0fSIgPSBzZXQ7IHRoZW4gOgot
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVk
ZSA8c3RkbGliLmg+Ci0jaW5jbHVkZSA8c3RkYXJnLmg+Ci0jaW5jbHVkZSA8c3RyaW5nLmg+Ci0j
aW5jbHVkZSA8ZmxvYXQuaD4KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsK
LX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBh
Y19jdl9oZWFkZXJfc3RkYz15ZXMKLWVsc2UKLSAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KLWZpCi1y
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKLQotaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLSAgIyBTdW5PUyA0
Lnggc3RyaW5nLmggZG9lcyBub3QgZGVjbGFyZSBtZW0qLCBjb250cmFyeSB0byBBTlNJLgotICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCi0jaW5jbHVkZSA8c3RyaW5nLmg+Ci0KLV9BQ0VPRgotaWYgKGV2YWwgIiRhY19j
cHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAotICAkRUdSRVAgIm1lbWNociIgPi9kZXYvbnVs
bCAyPiYxOyB0aGVuIDoKLQotZWxzZQotICBhY19jdl9oZWFkZXJfc3RkYz1ubwotZmkKLXJtIC1m
IGNvbmZ0ZXN0KgotCi1maQotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhl
bgotICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2VzIG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5
IHRvIEFOU0kuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
LS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzdGRsaWIuaD4KLQotX0FDRU9GCi1p
ZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAiZnJl
ZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKLQotZWxzZQotICBhY19jdl9oZWFkZXJfc3RkYz1u
bwotZmkKLXJtIC1mIGNvbmZ0ZXN0KgotCi1maQotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3Rk
YyA9IHllczsgdGhlbgotICAjIC9iaW4vY2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0
eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2kuCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxp
bmciID0geWVzOyB0aGVuIDoKLSAgOgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8Y3R5
cGUuaD4KLSNpbmNsdWRlIDxzdGRsaWIuaD4KLSNpZiAoKCcgJyAmIDB4MEZGKSA9PSAweDAyMCkK
LSMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykKLSMgZGVmaW5l
IFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAnQScgKyAoKGMpIC0gJ2EnKSA6IChjKSkKLSNlbHNl
Ci0jIGRlZmluZSBJU0xPV0VSKGMpIFwKLQkJICAgKCgnYScgPD0gKGMpICYmIChjKSA8PSAnaScp
IFwKLQkJICAgICB8fCAoJ2onIDw9IChjKSAmJiAoYykgPD0gJ3InKSBcCi0JCSAgICAgfHwgKCdz
JyA8PSAoYykgJiYgKGMpIDw9ICd6JykpCi0jIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMp
ID8gKChjKSB8IDB4NDApIDogKGMpKQotI2VuZGlmCi0KLSNkZWZpbmUgWE9SKGUsIGYpICgoKGUp
ICYmICEoZikpIHx8ICghKGUpICYmIChmKSkpCi1pbnQKLW1haW4gKCkKLXsKLSAgaW50IGk7Ci0g
IGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKLSAgICBpZiAoWE9SIChpc2xvd2VyIChpKSwgSVNM
T1dFUiAoaSkpCi0JfHwgdG91cHBlciAoaSkgIT0gVE9VUFBFUiAoaSkpCi0gICAgICByZXR1cm4g
MjsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7
IHRoZW4gOgotCi1lbHNlCi0gIGFjX2N2X2hlYWRlcl9zdGRjPW5vCi1maQotcm0gLWYgY29yZSAq
LmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQg
XAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAot
ZmkKLQotZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0
ZGMiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLQotJGFz
X2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAotCi1maQotCi0jIE9u
IElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5cGVzLmggYXJlIGNvbmZsaWN0aW5nLgotZm9y
IGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5oIHN0cmluZy5oIG1l
bW9yeS5oIHN0cmluZ3MuaCBcCi0JCSAgaW50dHlwZXMuaCBzdGRpbnQuaCB1bmlzdGQuaAotZG8g
OgotICBhc19hY19IZWFkZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAk
YXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hl
YWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdAotIgotaWYgZXZhbCB0
ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgotICBjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRh
c190cl9jcHBgIDEKLV9BQ0VPRgotCi1maQotCi1kb25lCi0KLQotCi0gIGFjX2ZuX2NfY2hlY2tf
aGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJtaW5peC9jb25maWcuaCIgImFjX2N2X2hlYWRlcl9t
aW5peF9jb25maWdfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9o
ZWFkZXJfbWluaXhfY29uZmlnX2giID0geCIieWVzOyB0aGVuIDoKLSAgTUlOSVg9eWVzCi1lbHNl
Ci0gIE1JTklYPQotZmkKLQotCi0gIGlmIHRlc3QgIiRNSU5JWCIgPSB5ZXM7IHRoZW4KLQotJGFz
X2VjaG8gIiNkZWZpbmUgX1BPU0lYX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKLQotCi0kYXNfZWNo
byAiI2RlZmluZSBfUE9TSVhfMV9TT1VSQ0UgMiIgPj5jb25mZGVmcy5oCi0KLQotJGFzX2VjaG8g
IiNkZWZpbmUgX01JTklYIDEiID4+Y29uZmRlZnMuaAotCi0gIGZpCi0KLQotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2Fm
ZSB0byBkZWZpbmUgX19FWFRFTlNJT05TX18iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hl
dGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXy4uLiAiID4mNjsgfQotaWYg
dGVzdCAiJHthY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXytzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LQotIwkgIGRlZmluZSBfX0VYVEVOU0lPTlNfXyAxCi0JICAkYWNfaW5jbHVkZXNfZGVmYXVsdAot
aW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9zYWZlX3RvX2RlZmluZV9f
X2V4dGVuc2lvbnNfXz15ZXMKLWVsc2UKLSAgYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNp
b25zX189bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fIiA+JjUK
LSRhc19lY2hvICIkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18iID4mNjsgfQot
ICB0ZXN0ICRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyA9IHllcyAmJgotICAg
ICRhc19lY2hvICIjZGVmaW5lIF9fRVhURU5TSU9OU19fIDEiID4+Y29uZmRlZnMuaAotCi0gICRh
c19lY2hvICIjZGVmaW5lIF9BTExfU09VUkNFIDEiID4+Y29uZmRlZnMuaAotCi0gICRhc19lY2hv
ICIjZGVmaW5lIF9HTlVfU09VUkNFIDEiID4+Y29uZmRlZnMuaAotCi0gICRhc19lY2hvICIjZGVm
aW5lIF9QT1NJWF9QVEhSRUFEX1NFTUFOVElDUyAxIiA+PmNvbmZkZWZzLmgKLQotICAkYXNfZWNo
byAiI2RlZmluZSBfVEFOREVNX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKLQotCi0jIE1ha2Ugc3Vy
ZSB3ZSBjYW4gcnVuIGNvbmZpZy5zdWIuCi0kU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIi
IHN1bjQgPi9kZXYvbnVsbCAyPiYxIHx8Ci0gIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuICRT
SEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViIiAiJExJTkVOTyIgNQotCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGJ1aWxkIHN5c3RlbSB0eXBlIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGJ1aWxkIHN5c3RlbSB0eXBlLi4uICIgPiY2OyB9Ci1p
ZiB0ZXN0ICIke2FjX2N2X2J1aWxkK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfYnVpbGRfYWxpYXM9JGJ1aWxkX2FsaWFzCi10ZXN0
ICJ4JGFjX2J1aWxkX2FsaWFzIiA9IHggJiYKLSAgYWNfYnVpbGRfYWxpYXM9YCRTSEVMTCAiJGFj
X2F1eF9kaXIvY29uZmlnLmd1ZXNzImAKLXRlc3QgIngkYWNfYnVpbGRfYWxpYXMiID0geCAmJgot
ICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGd1ZXNzIGJ1aWxkIHR5cGU7IHlvdSBtdXN0IHNwZWNp
Znkgb25lIiAiJExJTkVOTyIgNQotYWNfY3ZfYnVpbGQ9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29u
ZmlnLnN1YiIgJGFjX2J1aWxkX2FsaWFzYCB8fAotICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRh
Y19hdXhfZGlyL2NvbmZpZy5zdWIgJGFjX2J1aWxkX2FsaWFzIGZhaWxlZCIgIiRMSU5FTk8iIDUK
LQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfYnVpbGQiID4mNQotJGFzX2VjaG8gIiRhY19jdl9idWlsZCIgPiY2OyB9Ci1jYXNlICRh
Y19jdl9idWlsZCBpbgotKi0qLSopIDs7Ci0qKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YWx1
ZSBvZiBjYW5vbmljYWwgYnVpbGQiICIkTElORU5PIiA1IDs7Ci1lc2FjCi1idWlsZD0kYWNfY3Zf
YnVpbGQKLWFjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKLXNldCB4ICRhY19jdl9idWlsZAotc2hp
ZnQKLWJ1aWxkX2NwdT0kMQotYnVpbGRfdmVuZG9yPSQyCi1zaGlmdDsgc2hpZnQKLSMgUmVtZW1i
ZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAotIyBl
eGNlcHQgd2l0aCBvbGQgc2hlbGxzOgotYnVpbGRfb3M9JCoKLUlGUz0kYWNfc2F2ZV9JRlMKLWNh
c2UgJGJ1aWxkX29zIGluICpcICopIGJ1aWxkX29zPWBlY2hvICIkYnVpbGRfb3MiIHwgc2VkICdz
LyAvLS9nJ2A7OyBlc2FjCi0KLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGhvc3Qgc3lzdGVtIHR5cGUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaG9zdCtzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlm
IHRlc3QgIngkaG9zdF9hbGlhcyIgPSB4OyB0aGVuCi0gIGFjX2N2X2hvc3Q9JGFjX2N2X2J1aWxk
Ci1lbHNlCi0gIGFjX2N2X2hvc3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhv
c3RfYWxpYXNgIHx8Ci0gICAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25m
aWcuc3ViICRob3N0X2FsaWFzIGZhaWxlZCIgIiRMSU5FTk8iIDUKLWZpCi0KLWZpCi17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hvc3QiID4m
NQotJGFzX2VjaG8gIiRhY19jdl9ob3N0IiA+JjY7IH0KLWNhc2UgJGFjX2N2X2hvc3QgaW4KLSot
Ki0qKSA7OwotKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGhv
c3QiICIkTElORU5PIiA1IDs7Ci1lc2FjCi1ob3N0PSRhY19jdl9ob3N0Ci1hY19zYXZlX0lGUz0k
SUZTOyBJRlM9Jy0nCi1zZXQgeCAkYWNfY3ZfaG9zdAotc2hpZnQKLWhvc3RfY3B1PSQxCi1ob3N0
X3ZlbmRvcj0kMgotc2hpZnQ7IHNoaWZ0Ci0jIFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVy
IG9mIElGUyBpcyB1c2VkIHRvIGNyZWF0ZSAkKiwKLSMgZXhjZXB0IHdpdGggb2xkIHNoZWxsczoK
LWhvc3Rfb3M9JCoKLUlGUz0kYWNfc2F2ZV9JRlMKLWNhc2UgJGhvc3Rfb3MgaW4gKlwgKikgaG9z
dF9vcz1gZWNobyAiJGhvc3Rfb3MiIHwgc2VkICdzLyAvLS9nJ2A7OyBlc2FjCi0KLQotCi0jIE00
IE1hY3JvIGluY2x1ZGVzCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQot
Ci0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotIyBw
a2cubTQgLSBNYWNyb3MgdG8gbG9jYXRlIGFuZCB1dGlsaXNlIHBrZy1jb25maWcuICAgICAgICAg
ICAgLSotIEF1dG9jb25mIC0qLQotIyBzZXJpYWwgMSAocGtnLWNvbmZpZy0wLjI0KQotIwotIyBD
b3B5cmlnaHQgwqkgMjAwNCBTY290dCBKYW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+
LgotIwotIyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yIG1vZGlmeQotIyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQotIyB0aGUgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgotIyAoYXQgeW91
ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgotIwotIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0Ci0jIFdJVEhPVVQg
QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKLSMgTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRo
ZSBHTlUKLSMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgotIwotIyBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZQotIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUg
RnJlZSBTb2Z0d2FyZQotIyBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0
ZSAzMzAsIEJvc3RvbiwgTUEgMDIxMTEtMTMwNywgVVNBLgotIwotIyBBcyBhIHNwZWNpYWwgZXhj
ZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91Ci0jIGRpc3Ry
aWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQotIyBj
b25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVk
ZSBpdCB1bmRlcgotIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZv
ciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCi0KLSMgUEtHX1BST0dfUEtHX0NPTkZJRyhbTUlO
LVZFUlNJT05dKQotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFBLR19Q
Uk9HX1BLR19DT05GSUcKLQotIyBQS0dfQ0hFQ0tfRVhJU1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYt
Rk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCi0jCi0jIENoZWNrIHRvIHNlZSB3aGV0aGVy
IGEgcGFydGljdWxhciBzZXQgb2YgbW9kdWxlcyBleGlzdHMuICBTaW1pbGFyCi0jIHRvIFBLR19D
SEVDS19NT0RVTEVTKCksIGJ1dCBkb2VzIG5vdCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9y
cy4KLSMKLSMgUGxlYXNlIHJlbWVtYmVyIHRoYXQgbTQgZXhwYW5kcyBBQ19SRVFVSVJFKFtQS0df
UFJPR19QS0dfQ09ORklHXSkKLSMgb25seSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZp
Z3VyZS5hYywgc28gaWYgdGhlIGZpcnN0IHBsYWNlCi0jIGl0J3MgY2FsbGVkIG1pZ2h0IGJlIHNr
aXBwZWQgKHN1Y2ggYXMgaWYgaXQgaXMgd2l0aGluIGFuICJpZiIsIHlvdQotIyBoYXZlIHRvIGNh
bGwgUEtHX0NIRUNLX0VYSVNUUyBtYW51YWxseQotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotCi0KLSMgX1BLR19DT05GSUco
W1ZBUklBQkxFXSwgW0NPTU1BTkRdLCBbTU9EVUxFU10pCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotIyBfUEtHX0NPTkZJRwotCi0jIF9QS0dfU0hPUlRf
RVJST1JTX1NVUFBPUlRFRAotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotIyBfUEtH
X1NIT1JUX0VSUk9SU19TVVBQT1JURUQKLQotCi0jIFBLR19DSEVDS19NT0RVTEVTKFZBUklBQkxF
LVBSRUZJWCwgTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sCi0jIFtBQ1RJT04tSUYtTk9ULUZP
VU5EXSkKLSMKLSMKLSMgTm90ZSB0aGF0IGlmIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhlIGZp
cnN0IGNhbGwgdG8KLSMgUEtHX0NIRUNLX01PRFVMRVMgbWlnaHQgbm90IGhhcHBlbiwgeW91IHNo
b3VsZCBiZSBzdXJlIHRvIGluY2x1ZGUgYW4KLSMgZXhwbGljaXQgY2FsbCB0byBQS0dfUFJPR19Q
S0dfQ09ORklHIGluIHlvdXIgY29uZmlndXJlLmFjCi0jCi0jCi0jIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFBLR19DSEVD
S19NT0RVTEVTCi0KLQotCi0jIFdlIGRlZmluZSwgc2VwYXJhdGVseSwgUFRIUkVBRF9DRkxBR1Ms
IF9MREZMQUdTIGFuZCBfTElCUwotIyBldmVuIHRob3VnaCBjdXJyZW50bHkgd2UgZG9uJ3Qgc2V0
IHRoZW0gdmVyeSBzZXBhcmF0ZWx5LgotIyBUaGlzIG1lYW5zIHRoYXQgdGhlIG1ha2VmaWxlcyB3
aWxsIG5vdCBuZWVkIHRvIGNoYW5nZSBpbgotIyB0aGUgZnV0dXJlIGlmIHdlIG1ha2UgdGhlIHRl
c3QgbW9yZSBzb3BoaXN0aWNhdGVkLgotCi0KLQotIyBXZSBpbnZva2UgQVhfUFRIUkVBRF9WQVJT
IHdpdGggdGhlIG5hbWUgb2YgYW5vdGhlciBtYWNybwotIyB3aGljaCBpcyB0aGVuIGV4cGFuZGVk
IG9uY2UgZm9yIGVhY2ggdmFyaWFibGUuCi0KLQotCi0KLQotCi0KLQotIyBFbmFibGUvZGlzYWJs
ZSBvcHRpb25zCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4K
LWlmIHRlc3QgIiR7ZW5hYmxlX2dpdGh0dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2
YWw9JGVuYWJsZV9naXRodHRwOwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9
ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X2dpdGh0dHA9Im4iCi0KLWVsaWYgdGVzdCAieCRl
bmFibGVfZ2l0aHR0cCIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfZ2l0aHR0cD0ieSIK
LQotZWxpZiB0ZXN0IC16ICRheF9jdl9naXRodHRwOyB0aGVuIDoKLQotICAgIGF4X2N2X2dpdGh0
dHA9Im4iCi0KLWZpCi1naXRodHRwPSRheF9jdl9naXRodHRwCi0KLQotCi0jIENoZWNrIHdoZXRo
ZXIgLS1lbmFibGUtbW9uaXRvcnMgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfbW9uaXRv
cnMrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9tb25pdG9yczsKLWZp
Ci0KLQotaWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInhubyI7IHRoZW4gOgotCi0gICAg
YXhfY3ZfbW9uaXRvcnM9Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInh5
ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X21vbml0b3JzPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4
X2N2X21vbml0b3JzOyB0aGVuIDoKLQotICAgIGF4X2N2X21vbml0b3JzPSJ5IgotCi1maQotbW9u
aXRvcnM9JGF4X2N2X21vbml0b3JzCi0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtdnRw
bSB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV92dHBtK3NldH0iID0gc2V0OyB0aGVuIDoK
LSAgZW5hYmxldmFsPSRlbmFibGVfdnRwbTsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfdnRw
bSIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl92dHBtPSJuIgotCi1lbGlmIHRlc3QgIngk
ZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X3Z0cG09InkiCi0KLWVs
aWYgdGVzdCAteiAkYXhfY3ZfdnRwbTsgdGhlbiA6Ci0KLSAgICBheF9jdl92dHBtPSJuIgotCi1m
aQotdnRwbT0kYXhfY3ZfdnRwbQotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhlbmFw
aSB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV94ZW5hcGkrc2V0fSIgPSBzZXQ7IHRoZW4g
OgotICBlbmFibGV2YWw9JGVuYWJsZV94ZW5hcGk7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxl
X3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl94ZW5hcGk9Im4iCi0KLWVsaWYg
dGVzdCAieCRlbmFibGVfeGVuYXBpIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9jdl94ZW5h
cGk9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfeGVuYXBpOyB0aGVuIDoKLQotICAgIGF4X2N2
X3hlbmFwaT0ibiIKLQotZmkKLXhlbmFwaT0kYXhfY3ZfeGVuYXBpCi0KLQotCi0jIENoZWNrIHdo
ZXRoZXIgLS1lbmFibGUtcHl0aG9udG9vbHMgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVf
cHl0aG9udG9vbHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9weXRo
b250b29sczsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInhubyI7
IHRoZW4gOgotCi0gICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFi
bGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X3B5dGhvbnRvb2xz
PSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRvb2xzOyB0aGVuIDoKLQotICAgIGF4
X2N2X3B5dGhvbnRvb2xzPSJ5IgotCi1maQotcHl0aG9udG9vbHM9JGF4X2N2X3B5dGhvbnRvb2xz
Ci0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2ZW4uCi1p
ZiB0ZXN0ICIke2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxl
dmFsPSRlbmFibGVfb2NhbWx0b29sczsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0
b29scyIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgotCi1lbGlm
IHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2
X29jYW1sdG9vbHM9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6
Ci0KLSAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgotCi1maQotb2NhbWx0b29scz0kYXhfY3Zfb2Nh
bWx0b29scwotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1pbml0ZXJtIHdhcyBnaXZl
bi4KLWlmIHRlc3QgIiR7ZW5hYmxlX21pbml0ZXJtK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5h
YmxldmFsPSRlbmFibGVfbWluaXRlcm07Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxlX21pbml0
ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKyMgTTQgTWFjcm8gaW5jbHVkZXMKIAotICAgIGF4X2N2X21p
bml0ZXJtPSJuIgogCi1lbGlmIHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4eWVzIjsgdGhl
biA6CiAKLSAgICBheF9jdl9taW5pdGVybT0ieSIKIAotZWxpZiB0ZXN0IC16ICRheF9jdl9taW5p
dGVybTsgdGhlbiA6CiAKLSAgICBheF9jdl9taW5pdGVybT0ibiIKIAotZmkKLW1pbml0ZXJtPSRh
eF9jdl9taW5pdGVybQogCiAKIAotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWxvbW91bnQgd2Fz
IGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0g
IGVuYWJsZXZhbD0kZW5hYmxlX2xvbW91bnQ7Ci1maQogCiAKLWlmIHRlc3QgIngkZW5hYmxlX2xv
bW91bnQiID0gInhubyI7IHRoZW4gOgogCi0gICAgYXhfY3ZfbG9tb3VudD0ibiIKIAotZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICBheF9jdl9sb21v
dW50PSJ5IgogCi1lbGlmIHRlc3QgLXogJGF4X2N2X2xvbW91bnQ7IHRoZW4gOgogCi0gICAgYXhf
Y3ZfbG9tb3VudD0ibiIKIAotZmkKLWxvbW91bnQ9JGF4X2N2X2xvbW91bnQKIAogCiAKLSMgQ2hl
Y2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9k
ZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX2RlYnVnOwotZmkK
IAogCi1pZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6CiAKLSAgICBheF9j
dl9kZWJ1Zz0ibiIKIAotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieHllcyI7IHRoZW4g
OgogCi0gICAgYXhfY3ZfZGVidWc9InkiCiAKLWVsaWYgdGVzdCAteiAkYXhfY3ZfZGVidWc7IHRo
ZW4gOgogCi0gICAgYXhfY3ZfZGVidWc9InkiCiAKLWZpCi1kZWJ1Zz0kYXhfY3ZfZGVidWcKIAog
CiAKQEAgLTQxNjEsMjQgKzIyMDcsNiBAQCBkZWJ1Zz0kYXhfY3ZfZGVidWcKIAogCiAKLWZvciBj
ZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUwotZG8KLSAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRj
ZmxhZyIKLWRvbmUKLWZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCi1kbwotICAgIFBSRVBFTkRf
TERGTEFHUys9IiAtTCRsZGZsYWciCi1kb25lCi1mb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURF
UwotZG8KLSAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgotZG9uZQotZm9yIGxkZmxhZyBp
biAkQVBQRU5EX0xJQgotZG8KLSAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCi1kb25l
Ci1DRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgotTERGTEFH
Uz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiCiAKIAogCkBAIC00
MTkwLDkwNiArMjIxOCwzNDggQEAgTERGTEFHUz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAk
QVBQRU5EX0xERkxBR1MiCiAKIAogCisjIHBrZy5tNCAtIE1hY3JvcyB0byBsb2NhdGUgYW5kIHV0
aWxpc2UgcGtnLWNvbmZpZy4gICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCisjIHNlcmlhbCAx
IChwa2ctY29uZmlnLTAuMjQpCisjCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVzIFJl
bW5hbnQgPHNjb3R0QG5ldHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNv
ZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisjIGl0IHVuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVk
IGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2Yg
dGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisj
CisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQ
QVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkg
b2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGggdGhpcyBwcm9n
cmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5kYXRpb24sIElu
Yy4sIDU5IFRlbXBsZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBV
U0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHBy
b2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBi
eSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1
dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KIAor
IyBQS0dfUFJPR19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KKyMgUEtHX1BST0dfUEtHX0NPTkZJRwogCisjIFBLR19DSEVDS19F
WElTVFMoTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkK
KyMKKyMgQ2hlY2sgdG8gc2VlIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIHNldCBvZiBtb2R1bGVzIGV4
aXN0cy4gIFNpbWlsYXIKKyMgdG8gUEtHX0NIRUNLX01PRFVMRVMoKSwgYnV0IGRvZXMgbm90IHNl
dCB2YXJpYWJsZXMgb3IgcHJpbnQgZXJyb3JzLgorIworIyBQbGVhc2UgcmVtZW1iZXIgdGhhdCBt
NCBleHBhbmRzIEFDX1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05GSUddKQorIyBvbmx5IGF0IHRo
ZSBmaXJzdCBvY2N1cmVuY2UgaW4gY29uZmlndXJlLmFjLCBzbyBpZiB0aGUgZmlyc3QgcGxhY2UK
KyMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBpZiBpdCBpcyB3aXRoaW4g
YW4gImlmIiwgeW91CisjIGhhdmUgdG8gY2FsbCBQS0dfQ0hFQ0tfRVhJU1RTIG1hbnVhbGx5Cisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCiAKLSMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNh
dGUgb3V0cHV0IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMg
bm90IHRydW5jYXRlIG91dHB1dC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1NF
RCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNl
Ci0gICAgICAgICAgICBhY19zY3JpcHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYS9iYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmIvCi0gICAgIGZvciBhY19pIGlu
IDEgMiAzIDQgNSA2IDc7IGRvCi0gICAgICAgYWNfc2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFj
X3NjcmlwdCIKLSAgICAgZG9uZQotICAgICBlY2hvICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8
IHNlZCA5OXEgPmNvbmZ0ZXN0LnNlZAotICAgICB7IGFjX3NjcmlwdD07IHVuc2V0IGFjX3Njcmlw
dDt9Ci0gICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0aGVuCi0gIGFjX3BhdGhfU0VEX2ZvdW5kPWZh
bHNlCi0gICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBv
ZiBQUk9HTkFNRS1MSVNUCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
ICAgIGFjX3BhdGhfU0VEPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgotICAgICAgeyB0
ZXN0IC1mICIkYWNfcGF0aF9TRUQiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwg
Y29udGludWUKLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0
IGlzIGZvdW5kLgotICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfU0VECi1jYXNlIGAiJGFjX3Bh
dGhfU0VEIiAtLXZlcnNpb24gMj4mMWAgaW4KLSpHTlUqKQotICBhY19jdl9wYXRoX1NFRD0iJGFj
X3BhdGhfU0VEIiBhY19wYXRoX1NFRF9mb3VuZD06OzsKLSopCi0gIGFjX2NvdW50PTAKLSAgJGFz
X2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCi0gIHdoaWxlIDoKLSAgZG8KLSAgICBj
YXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgotICAgIG12ICJj
b25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVz
dC5ubCIKLSAgICAkYXNfZWNobyAnJyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRhY19wYXRoX1NF
RCIgLWYgY29uZnRlc3Quc2VkIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2
L251bGwgfHwgYnJlYWsKLSAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9k
ZXYvbnVsbCAyPiYxIHx8IGJyZWFrCi0gICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBh
Y19jb3VudD0kYXNfdmFsCi0gICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURf
bWF4LTB9OyB0aGVuCi0gICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBs
b29raW5nIGZvciBhIGJldHRlciBvbmUKLSAgICAgIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9T
RUQiCi0gICAgICBhY19wYXRoX1NFRF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigy
XjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNf
Y291bnQgLWd0IDEwICYmIGJyZWFrCi0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRl
c3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Ci1lc2FjCiAKLSAgICAgICRhY19wYXRo
X1NFRF9mb3VuZCAmJiBicmVhayAzCi0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNf
c2F2ZV9JRlMKLSAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfU0VEIjsgdGhlbgotICAgIGFzX2Zu
X2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIHNlZCBjb3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIk
TElORU5PIiA1Ci0gIGZpCi1lbHNlCi0gIGFjX2N2X3BhdGhfU0VEPSRTRUQKLWZpCisjIF9QS0df
Q09ORklHKFtWQVJJQUJMRV0sIFtDT01NQU5EXSwgW01PRFVMRVNdKQorIyAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BLR19DT05GSUcKIAotZmkKLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0
aF9TRUQiID4mNQotJGFzX2VjaG8gIiRhY19jdl9wYXRoX1NFRCIgPiY2OyB9Ci0gU0VEPSIkYWNf
Y3ZfcGF0aF9TRUQiCi0gIHJtIC1mIGNvbmZ0ZXN0LnNlZAorIyBfUEtHX1NIT1JUX0VSUk9SU19T
VVBQT1JURUQKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BLR19TSE9SVF9F
UlJPUlNfU1VQUE9SVEVECiAKLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNf
Y29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1Jwot
YWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERG
TEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3Zf
Y19jb21waWxlcl9nbnUKLWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZp
eH1nY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0
OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAt
biAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2MiCi0gICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4g
IiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hv
ICJubyIgPiY2OyB9Ci1maQorIyBQS0dfQ0hFQ0tfTU9EVUxFUyhWQVJJQUJMRS1QUkVGSVgsIE1P
RFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLAorIyBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCisjCisj
CisjIE5vdGUgdGhhdCBpZiB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IHRoZSBmaXJzdCBjYWxsIHRv
CisjIFBLR19DSEVDS19NT0RVTEVTIG1pZ2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3Vy
ZSB0byBpbmNsdWRlIGFuCisjIGV4cGxpY2l0IGNhbGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBp
biB5b3VyIGNvbmZpZ3VyZS5hYworIworIworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBQS0dfQ0hFQ0tfTU9EVUxFUwog
CiAKLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KLSAgYWNfY3RfQ0M9JEND
Ci0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgot
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgot
Zm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0
YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9
OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgotICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lG
UwogCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1pZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Ci1l
bHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKKyMgV2UgZGVmaW5lLCBzZXBhcmF0ZWx5
LCBQVEhSRUFEX0NGTEFHUywgX0xERkxBR1MgYW5kIF9MSUJTCisjIGV2ZW4gdGhvdWdoIGN1cnJl
bnRseSB3ZSBkb24ndCBzZXQgdGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCisjIFRoaXMgbWVhbnMgdGhh
dCB0aGUgbWFrZWZpbGVzIHdpbGwgbm90IG5lZWQgdG8gY2hhbmdlIGluCisjIHRoZSBmdXR1cmUg
aWYgd2UgbWFrZSB0aGUgdGVzdCBtb3JlIHNvcGhpc3RpY2F0ZWQuCiAKLSAgaWYgdGVzdCAieCRh
Y19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIKLSAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2lu
ZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190
b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBDQz0kYWNfY3RfQ0MKLSAgZmkKLWVsc2UKLSAg
Q0M9IiRhY19jdl9wcm9nX0NDIgotZmkKIAotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAgICAg
ICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9Y2M7IGFjX3dv
cmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi
ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhl
bgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2Rp
ciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl
bnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0g
ICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKLSAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9J
RlMKIAotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAtbiAiJENDIjsgdGhlbgot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+
JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0K
LWZpCisjIFdlIGludm9rZSBBWF9QVEhSRUFEX1ZBUlMgd2l0aCB0aGUgbmFtZSBvZiBhbm90aGVy
IG1hY3JvCisjIHdoaWNoIGlzIHRoZW4gZXhwYW5kZWQgb25jZSBmb3IgZWFjaCB2YXJpYWJsZS4K
IAogCi0gIGZpCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
LXNldCBkdW1teSBjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi0gIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRv
Ci0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGlmIHRlc3QgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgotICAgICAg
IGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCi0gICAgICAgY29udGludWUKLSAgICAgZmkKLSAgICBhY19j
dl9wcm9nX0NDPSJjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0g
IGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKIAotaWYgdGVzdCAkYWNfcHJvZ19y
ZWplY3RlZCA9IHllczsgdGhlbgotICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBhdGgsIHNv
IG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCi0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwot
ICBzaGlmdAotICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KLSAgICAjIFdlIGNob3NlIGEgZGlmZmVy
ZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KLSAgICAjIEhvd2V2ZXIsIGl0IGhhcyB0
aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCi0gICAgIyBmaXJz
dCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVsbCBmaWxlIG5h
bWUuCi0gICAgc2hpZnQKLSAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193b3JkJHsxKycg
J30kQCIKLSAgZmkKLWZpCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAi
bm8iID4mNjsgfQotZmkKIAogCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotICBk
bwotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3By
b2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRh
Y190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1l
bHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2
ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3By
ZWZpeCRhY19wcm9nIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAg
ZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwogCi1maQotZmkKLUNDPSRhY19jdl9w
cm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9
Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtZ2l0aHR0cCB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9naXRodHRwK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRl
bmFibGVfZ2l0aHR0cDsKIGZpCiAKIAotICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKLSAgZG9u
ZQotZmkKLWlmIHRlc3QgLXogIiRDQyI7IHRoZW4KLSAgYWNfY3RfQ0M9JENDCi0gIGZvciBhY19w
cm9nIGluIGNsLmV4ZQotZG8KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfcHJv
ZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJGFj
X3Byb2c7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3Rf
Q0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZT
PSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9D
Qz0iJGFjX3Byb2ciCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBm
aQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRo
dHRwIiA9ICJ4bm8iOyB0aGVuIDoKIAotZmkKLWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19j
dF9DQwotaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKLSRhc19lY2hvICIk
YWNfY3RfQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCisgICAg
YXhfY3ZfZ2l0aHR0cD0ibiIKIAorZWxpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVz
IjsgdGhlbiA6CiAKLSAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhawotZG9uZQorICAgIGF4
X2N2X2dpdGh0dHA9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhlbiA6CisK
KyAgICBheF9jdl9naXRodHRwPSJuIgogCi0gIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7
Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0gIGZpCiBmaQorZ2l0aHR0cD0kYXhfY3ZfZ2l0aHR0
cAogCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KK2lm
IHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFs
PSRlbmFibGVfbW9uaXRvcnM7CiBmaQogCiAKLXRlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1
Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9l
cnJvciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAotU2VlIFxg
Y29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CitpZiB0ZXN0ICJ4
JGVuYWJsZV9tb25pdG9ycyIgPSAieG5vIjsgdGhlbiA6CiAKLSMgUHJvdmlkZSBzb21lIGluZm9y
bWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KLSRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQotc2V0IFggJGFj
X2NvbXBpbGUKLWFjX2NvbXBpbGVyPSQyCi1mb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAt
ViAtcXZlcnNpb247IGRvCi0gIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4m
NSIKLWNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNo
bz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190
cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIK
LSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGVyICRh
Y19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKLSAgYWNfc3RhdHVzPSQ/Ci0gIGlmIHRlc3Qg
LXMgY29uZnRlc3QuZXJyOyB0aGVuCi0gICAgc2VkICcxMGFcCi0uLi4gcmVzdCBvZiBzdGRlcnIg
b3V0cHV0IGRlbGV0ZWQgLi4uCi0gICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3Qu
ZXIxCi0gICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKLSAgZmkKLSAgcm0gLWYgY29uZnRlc3QuZXIx
IGNvbmZ0ZXN0LmVycgotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBc
JD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQotZG9uZQorICAg
IGF4X2N2X21vbml0b3JzPSJuIgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCitlbGlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsgdGhlbiA6
CiAKLWludAotbWFpbiAoKQotewotI2lmbmRlZiBfX0dOVUNfXwotICAgICAgIGNob2tlIG1lCi0j
ZW5kaWYKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKIAotICA7Ci0gIHJldHVybiAwOwotfQotX0FD
RU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2NvbXBp
bGVyX2dudT15ZXMKLWVsc2UKLSAgYWNfY29tcGlsZXJfZ251PW5vCi1maQotcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1hY19jdl9j
X2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251CitlbGlmIHRlc3QgLXogJGF4X2N2X21vbml0
b3JzOyB0aGVuIDoKKworICAgIGF4X2N2X21vbml0b3JzPSJ5IgogCiBmaQoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2du
dSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KLWlmIHRlc3Qg
JGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhlbgotICBHQ0M9eWVzCi1lbHNlCi0gIEdDQz0KK21v
bml0b3JzPSRheF9jdl9tb25pdG9ycworCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0
cG0gd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6
CisgIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07CiBmaQotYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mr
c2V0fQotYWNfc2F2ZV9DRkxBR1M9JENGTEFHUwoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKLSRhc19l
Y2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KLWlmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJv
cl9mbGFnCi0gICBhY19jX3dlcnJvcl9mbGFnPXllcwotICAgYWNfY3ZfcHJvZ19jY19nPW5vCi0g
ICBDRkxBR1M9Ii1nIgotICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwogCi1pbnQKLW1haW4gKCkKLXsKIAotICA7Ci0g
IHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWVsc2UKLSAgQ0ZMQUdTPSIiCi0gICAgICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCitpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKIAotaW50
Ci1tYWluICgpCi17CisgICAgYXhfY3ZfdnRwbT0ibiIKIAotICA7Ci0gIHJldHVybiAwOwotfQot
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CitlbGlmIHRl
c3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKIAotZWxzZQotICBhY19jX3dlcnJv
cl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLQkgQ0ZMQUdTPSItZyIKLQkgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAq
LworICAgIGF4X2N2X3Z0cG09InkiCiAKLWludAotbWFpbiAoKQoteworZWxpZiB0ZXN0IC16ICRh
eF9jdl92dHBtOyB0aGVuIDoKKworICAgIGF4X2N2X3Z0cG09Im4iCiAKLSAgOwotICByZXR1cm4g
MDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgot
ICBhY19jdl9wcm9nX2NjX2c9eWVzCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cit2dHBtPSRheF9jdl92dHBtCisKKworCisj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUteGVuYXBpIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5h
YmxlX3hlbmFwaStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hlbmFw
aTsKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInhubyI7IHRoZW4g
OgorCisgICAgYXhfY3ZfeGVuYXBpPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIg
PSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfeGVuYXBpPSJ5IgorCitlbGlmIHRlc3QgLXog
JGF4X2N2X3hlbmFwaTsgdGhlbiA6CisKKyAgICBheF9jdl94ZW5hcGk9Im4iCisKIGZpCi1ybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQK
LSAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZworeGVuYXBpPSRheF9j
dl94ZW5hcGkKKworCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1weXRob250b29scyB3YXMg
Z2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9weXRob250b29scytzZXR9IiA9IHNldDsgdGhlbiA6
CisgIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xzOwogZmkKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKLSRh
c19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KLWlmIHRlc3QgIiRhY190ZXN0X0NGTEFH
UyIgPSBzZXQ7IHRoZW4KLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwotZWxpZiB0ZXN0ICRhY19j
dl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KLSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KLSAg
ICBDRkxBR1M9Ii1nIC1PMiIKLSAgZWxzZQotICAgIENGTEFHUz0iLWciCi0gIGZpCi1lbHNlCi0g
IGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItTzIiCi0gIGVsc2UKLSAg
ICBDRkxBR1M9Ci0gIGZpCisKKworaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInhu
byI7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4iCisKK2VsaWYgdGVzdCAieCRl
bmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRv
b2xzPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRvb2xzOyB0aGVuIDoKKworICAg
IGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4
OS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2N2X3Byb2df
Y2NfYzg5PW5vCi1hY19zYXZlX0NDPSRDQwotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGFyZy5o
PgotI2luY2x1ZGUgPHN0ZGlvLmg+Ci0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8
c3lzL3N0YXQuaD4KLS8qIE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZy
b20gUkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KLXN0cnVjdCBidWYgeyBpbnQgeDsgfTsKLUZJ
TEUgKiAoKnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Ci1zdGF0
aWMgY2hhciAqZSAocCwgaSkKLSAgICAgY2hhciAqKnA7Ci0gICAgIGludCBpOwotewotICByZXR1
cm4gcFtpXTsKLX0KLXN0YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50KSwg
Y2hhciAqKnAsIC4uLikKLXsKLSAgY2hhciAqczsKLSAgdmFfbGlzdCB2OwotICB2YV9zdGFydCAo
dixwKTsKLSAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKLSAgdmFfZW5kICh2KTsKLSAgcmV0
dXJuIHM7Ci19CitweXRob250b29scz0kYXhfY3ZfcHl0aG9udG9vbHMKIAotLyogT1NGIDQuMCBD
b21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMK
LSAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hh
cmFjdGVyIGNvbnN0YW50cy4KLSAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5mb3J0
dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAotICAgYXMgJ3gnLiAgVGhlIGZv
bGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAotICAg
cHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMgb3V0
IHRydWUsIGZvciBhbgotICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5IHRv
IHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCi0gICB0aGF0J3MgdHJ1ZSBvbmx5IHdp
dGggLXN0ZC4gICovCi1pbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFdOwog
Ci0vKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0IHJl
cGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKLSAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0ZXIg
Y29uc3RhbnRzLiAgKi8KLSNkZWZpbmUgRk9PKHgpICd4JwotaW50IHhsYzZfY2NfYXJyYXlbRk9P
KGEpID09ICd4JyA/IDEgOiAtMV07CiAKLWludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOwotc3Ry
dWN0IHMxIHtpbnQgKCpmKSAoaW50IGEpO307Ci1zdHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUg
YSk7fTsKLWludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYg
Kiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOwotaW50IGFyZ2M7Ci1jaGFyICoqYXJn
djsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0gIHx8
ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9G
Ci1mb3IgYWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBc
Ci0JLUFlICItQWEgLURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKLWRvCi0g
IENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgotICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19hcmcKKyMgQ2hlY2sgd2hldGhl
ciAtLWVuYWJsZS1vY2FtbHRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX29jYW1s
dG9vbHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xz
OwogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKLSAgdGVz
dCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIgJiYgYnJlYWsKLWRvbmUKLXJtIC1mIGNv
bmZ0ZXN0LiRhY19leHQKLUNDPSRhY19zYXZlX0NDCisKKworaWYgdGVzdCAieCRlbmFibGVfb2Nh
bWx0b29scyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitl
bGlmIHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4
X2N2X29jYW1sdG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhl
biA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgogCiBmaQotIyBBQ19DQUNIRV9WQUwKLWNh
c2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCi0gIHgpCi0gICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vbmUgbmVlZGVkIiA+JjUKLSRhc19lY2hv
ICJub25lIG5lZWRlZCIgPiY2OyB9IDs7Ci0gIHhubykKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdW5zdXBwb3J0ZWQiID4mNQotJGFzX2VjaG8g
InVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKLSAgKikKLSAgICBDQz0iJENDICRhY19jdl9wcm9nX2Nj
X2M4OSIKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODki
ID4mNjsgfSA7OwotZXNhYwotaWYgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0
aGVuIDoKK29jYW1sdG9vbHM9JGF4X2N2X29jYW1sdG9vbHMKKworCiAKKyMgQ2hlY2sgd2hldGhl
ciAtLWVuYWJsZS1taW5pdGVybSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9taW5pdGVy
bStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOwogZmkK
IAotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21waWxlPSckQ0MgLWMg
JENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19saW5rPSckQ0MgLW8g
Y29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRh
Y19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQog
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRo
ZXIgbG4gLXMgd29ya3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3
b3Jrcy4uLiAiID4mNjsgfQotTE5fUz0kYXNfbG5fcwotaWYgdGVzdCAiJExOX1MiID0gImxuIC1z
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8sIHVzaW5nICRMTl9TIiA+JjUK
LSRhc19lY2hvICJubywgdXNpbmcgJExOX1MiID4mNjsgfQoraWYgdGVzdCAieCRlbmFibGVfbWlu
aXRlcm0iID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbWluaXRlcm09Im4iCisKK2VsaWYg
dGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X21p
bml0ZXJtPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAg
IGF4X2N2X21pbml0ZXJtPSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKwor
CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbG9tb3VudCB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV9sb21vdW50K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVf
bG9tb3VudDsKIGZpCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0UpLi4uICIgPiY2
OyB9Ci1zZXQgeCAke01BS0UtbWFrZX0KLWFjX21ha2U9YCRhc19lY2hvICIkMiIgfCBzZWQgJ3Mv
Ky9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAotaWYgZXZhbCAidGVzdCBcIlwke2FjX2N2X3By
b2dfbWFrZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9BQ0VPRgot
U0hFTEwgPSAvYmluL3NoCi1hbGw6Ci0JQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUlJScKLV9B
Q0VPRgotIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4i
LCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgotY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNvbmZ0ZXN0
Lm1ha2UgMj4vZGV2L251bGxgIGluCi0gICpAQEAlJSU9Pyo9QEBAJSUlKikKLSAgICBldmFsIGFj
X2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OwotICAqKQotICAgIGV2YWwgYWNfY3Zf
cHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKLWVzYWMKLXJtIC1mIGNvbmZ0ZXN0Lm1ha2UK
KworaWYgdGVzdCAieCRlbmFibGVfbG9tb3VudCIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9j
dl9sb21vdW50PSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInh5ZXMiOyB0
aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbG9t
b3VudDsgdGhlbiA6CisKKyAgICBheF9jdl9sb21vdW50PSJuIgorCiBmaQotaWYgZXZhbCB0ZXN0
IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVzOyB0aGVuCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2Vj
aG8gInllcyIgPiY2OyB9Ci0gIFNFVF9NQUtFPQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7
IH0KLSAgU0VUX01BS0U9Ik1BS0U9JHtNQUtFLW1ha2V9IgorbG9tb3VudD0kYXhfY3ZfbG9tb3Vu
dAorCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWRlYnVnIHdhcyBnaXZlbi4KK2lmIHRl
c3QgIiR7ZW5hYmxlX2RlYnVnK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfZGVidWc7CiBmaQogCi0jIEZpbmQgYSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZl
ciBhIEMgcHJvZ3JhbSAoZmFzdGVyKSwKLSMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFu
b3RoZXIuICBCdXQgYXZvaWQgdGhlIGJyb2tlbiBvcgotIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6
Ci0jIFN5c1YgL2V0Yy9pbnN0YWxsLCAvdXNyL3NiaW4vaW5zdGFsbAotIyBTdW5PUyAvdXNyL2V0
Yy9pbnN0YWxsCi0jIElSSVggL3NiaW4vaW5zdGFsbAotIyBBSVggL2Jpbi9pbnN0YWxsCi0jIEFt
aWdhT1MgL0MvaW5zdGFsbCwgd2hpY2ggaW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlz
Y3MKLSMgQUlYIDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhv
dXQgYSAtZyBmbGFnCi0jIEFGUyAvdXNyL2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5k
bGVzIG5vbmV4aXN0ZW50IGFyZ3MKLSMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmll
cyB0byB1c2UgdGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiIKLSMgT1MvMidzIHN5c3RlbSBp
bnN0YWxsLCB3aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYwotIyAuL2lu
c3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2lu
c3RhbGwuc2guCi0jIFJlamVjdCBpbnN0YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwg
bXVsdGlwbGUgZmlsZXMuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwiID4mNQotJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQotaWYgdGVz
dCAteiAiJElOU1RBTEwiOyB0aGVuCi1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgK
LWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
LSAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFU
SCBlbGVtZW50cy4KLWNhc2UgJGFzX2Rpci8gaW4gIygoCi0gIC4vIHwgLi8vIHwgL1tjQ10vKiB8
IFwKLSAgL2V0Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3Iv
YWZzd3MvYmluLyogfCBcCi0gID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9d
T1MyW1xcL11JTlNUQUxMW1xcL10qIHwgXAotICAvdXNyL3VjYi8qICkgOzsKLSAgKikKLSAgICAj
IE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgot
ICAgICMgRG9uJ3QgdXNlIGluc3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1
ZmYgYXMgcm9vdAotICAgICMgYnkgZGVmYXVsdC4KLSAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFs
bCBzY29pbnN0IGluc3RhbGw7IGRvCi0gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLQlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0JICBpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAgICBncmVwIGRz
cG1zZyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVu
Ci0JICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29u
dmVudGlvbi4KLQkgICAgOgotCSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAg
ICBncmVwIHB3cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAy
PiYxOyB0aGVuCi0JICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5
IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgotCSAgICA6Ci0JICBlbHNlCi0JICAgIHJtIC1yZiBjb25m
dGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgotCSAgICBlY2hvIG9uZSA+IGNvbmZ0
ZXN0Lm9uZQotCSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0LnR3bwotCSAgICBta2RpciBjb25mdGVz
dC5kaXIKLQkgICAgaWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0
Lm9uZSBjb25mdGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKLQkgICAgICB0ZXN0IC1z
IGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgotCSAgICAgIHRlc3QgLXMg
Y29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAmJgotCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGly
L2NvbmZ0ZXN0LnR3bwotCSAgICB0aGVuCi0JICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNf
ZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgotCSAgICAgIGJyZWFrIDMKLQkgICAgZmkKLQkg
IGZpCi0JZmkKLSAgICAgIGRvbmUKLSAgICBkb25lCi0gICAgOzsKLWVzYWMKIAotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6
CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAi
eHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfZGVidWc7IHRoZW4gOgogCi1ybSAtcmYgY29uZnRlc3Qub25lIGNvbmZ0ZXN0LnR3byBjb25m
dGVzdC5kaXIKKyAgICBheF9jdl9kZWJ1Zz0ieSIKIAogZmkKLSAgaWYgdGVzdCAiJHthY19jdl9w
YXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KLSAgICBJTlNUQUxMPSRhY19jdl9wYXRoX2lu
c3RhbGwKLSAgZWxzZQotICAgICMgQXMgYSBsYXN0IHJlc29ydCwgdXNlIHRoZSBzbG93IHNoZWxs
IHNjcmlwdC4gIERvbid0IGNhY2hlIGEKLSAgICAjIHZhbHVlIGZvciBJTlNUQUxMIHdpdGhpbiBh
IHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2UgdGhhdCB3aWxsCi0gICAgIyBicmVhayBvdGhlciBw
YWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBkaXJlY3RvcnkgaXMKLSAgICAjIHJlbW92
ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZlIG5hbWUuCi0gICAgSU5TVEFMTD0kYWNf
aW5zdGFsbF9zaAotICBmaQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkSU5TVEFMTCIgPiY1Ci0kYXNfZWNobyAiJElOU1RBTEwiID4mNjsgfQor
ZGVidWc9JGF4X2N2X2RlYnVnCiAKLSMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlz
aGFuZGxlcyBicmFjZXMgaW4gJHt2YXItdmFsfS4KLSMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9z
ZSBicmFjZSBlbmRzIHRoZSB2YXJpYWJsZSBzdWJzdGl0dXRpb24uCi10ZXN0IC16ICIkSU5TVEFM
TF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCiAKLXRlc3QgLXogIiRJ
TlNUQUxMX1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCiAKLXRlc3QgLXog
IiRJTlNUQUxMX0RBVEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCiAKLSMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQot
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfUEVSTCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJFBFUkwgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0g
IGFjX2N2X3BhdGhfUEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0g
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBm
aQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJMPSJubyIKLSAgOzsKLWVzYWMKLWZpCi1QRVJMPSRh
Y19jdl9wYXRoX1BFUkwKLWlmIHRlc3QgLW4gIiRQRVJMIjsgdGhlbgotICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFBFUkwiID4mNQotJGFzX2VjaG8g
IiRQRVJMIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQogCiAKLWlm
IHRlc3QgeCIke1BFUkx9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCBwZXJsLCBwbGVhc2UgaW5zdGFsbCBwZXJsIiAiJExJTkVOTyIgNQotZmkKLWlm
IHRlc3QgIngkeGFwaSIgPSAieHkiOyB0aGVuIDoKIAotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgotc2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf
Y3ZfcGF0aF9DVVJMK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKLWVsc2UKLSAgY2FzZSAkQ1VSTCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNf
Y3ZfcGF0aF9DVVJMPSIkQ1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0
aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKK2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNMVURF
UwogZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3Zf
cGF0aF9DVVJMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgotICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRj
ZmxhZyIKIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworZm9yIGxkZmxhZyBpbiAkUFJF
UEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2Zv
ciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkk
Y2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9M
REZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxB
R1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRB
UFBFTkRfTERGTEFHUyIKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9w
YXRoX0NVUkw9Im5vIgotICA7OwotZXNhYwotZmkKLUNVUkw9JGFjX2N2X3BhdGhfQ1VSTAotaWYg
dGVzdCAtbiAiJENVUkwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Ci0kYXNfZWNobyAiJENVUkwiID4mNjsgfQotZWxz
ZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCiAKIAotaWYgdGVzdCB4IiR7Q1VSTH0iID09
IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29u
ZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKLWZpCi0gICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1hNTCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJFhNTCBpbgotICBbXFwvXSogfCA/
OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3Nh
dmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVh
ayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIk
YWNfY3ZfcGF0aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKLSAgOzsKLWVzYWMKLWZpCi1Y
TUw9JGFjX2N2X3BhdGhfWE1MCi1pZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1Ci0kYXNfZWNo
byAiJFhNTCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKIAogCi1p
ZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElO
RU5PIiA1Ci1maQogCi1maQotaWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRoZW4gOgog
Ci0gICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl
Zml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBk
dW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgorCisKKworCisKKworIyBD
aGVja3MgZm9yIHByb2dyYW1zLgorYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCith
Y19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUn
CithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRM
REZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19j
dl9jX2NvbXBpbGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJl
Zml4fWdjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxDK3NldH0i
ID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhl
biA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRP
Q0FNTEMiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9w
cm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQogYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSApA
QCAtNTA5OCw3ICsyNTY4LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
ICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
ICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3By
b2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIKKyAgICBhY19jdl9wcm9nX0NDPSIk
e2FjX3Rvb2xfcHJlZml4fWdjYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh
ayAyCiAgIGZpCkBAIC01MTA4LDEwICsyNTc4LDEwIEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkK
IGZpCi1PQ0FNTEM9JGFjX2N2X3Byb2dfT0NBTUxDCi1pZiB0ZXN0IC1uICIkT0NBTUxDIjsgdGhl
bgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MQyIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MQyIgPiY2OyB9CitDQz0kYWNfY3ZfcHJvZ19DQwor
aWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQog
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KQEAgLTUxMTksMTcgKzI1ODksMTcgQEAgZmkKIAogCiBm
aQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgotICBhY19jdF9PQ0FNTEM9
JE9DQU1MQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxjOyBhY193b3Jk
PSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
ICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAi
JHthY19jdl9wcm9nX2FjX2N0X09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgot
ICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0iJGFjX2N0X09DQU1MQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBh
c19kaXIgaW4gJFBBVEgKQEAgLTUxMzgsNyArMjYwOCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0ib2NhbWxjIgorICAgIGFjX2N2X3Byb2df
YWNfY3RfQ0M9ImdjYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC01MTQ4LDE3ICsyNjE4LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1h
Y19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDCi1pZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X09DQU1MQyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MQyIgPiY2
OyB9CithY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0ND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQogZWxzZQogICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog
JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEMiID0g
eDsgdGhlbgotICAgIE9DQU1MQz0ibm8iCisgIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgorICAgIENDPSIiCiAgIGVsc2UKICAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCiB5ZXM6KQpAQCAtNTE2Niw0MSArMjYzNiwyMyBAQCB5ZXM6KQogJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBlc2FjCi0gICAgT0NBTUxD
PSRhY19jdF9PQ0FNTEMKKyAgICBDQz0kYWNfY3RfQ0MKICAgZmkKIGVsc2UKLSAgT0NBTUxDPSIk
YWNfY3ZfcHJvZ19PQ0FNTEMiCisgIENDPSIkYWNfY3ZfcHJvZ19DQyIKIGZpCiAKLQotICBpZiB0
ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCi0gICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAt
diB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAotICAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NhbWwgdmVyc2lvbiBp
cyAkT0NBTUxWRVJTSU9OIiA+JjUKLSRhc19lY2hvICJPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZF
UlNJT04iID4mNjsgfQotICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0Ci0gICAgIGlm
IHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgotICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAt
d2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAK
LSAgICAgZWxzZQotICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjUK
LSRhc19lY2hvICJPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNjsg
fQotICAgICBmaQotICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogT0NhbWwgbGlicmFyeSBwYXRoIGlzICRPQ0FNTExJQiIgPiY1Ci0kYXNfZWNobyAi
T0NhbWwgbGlicmFyeSBwYXRoIGlzICRPQ0FNTExJQiIgPiY2OyB9Ci0KLQotCi0KLSAgICAgIyBj
aGVja2luZyBmb3Igb2NhbWxvcHQKLSAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4Ijsg
dGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQ7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRDQyI7
IHRoZW4KKyAgICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJl
Zml4fWNjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9
IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIk
T0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiRPQ0FNTE9QVCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVs
c2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4g
JFBBVEgKQEAgLTUyMDksNyArMjY2MSw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFz
X2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg
JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh
Y19jdl9wcm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0IgorICAgIGFjX2N2
X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTIxOSwyOSArMjY3MSwzMCBAQCBJRlM9JGFzX3NhdmVf
SUZTCiAKIGZpCiBmaQotT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKLWlmIHRlc3QgLW4g
IiRPQ0FNTE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7IH0K
K0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8g
IiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCisgIGZp
CiBmaQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N0X09D
QU1MT1BUPSRPQ0FNTE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBvY2Ft
bG9wdDsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0ND
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BUIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MT1BUPSIkYWNfY3RfT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9
bm8KIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4g
JFBBVEgKIGRvCkBAIC01MjQ5LDcgKzI3MDIsMTEgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgot
ICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgorICAgIGlmIHRlc3QgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgorICAgICAg
IGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29udGludWUKKyAgICAgZmkKKyAgICBhY19j
dl9wcm9nX0NDPSJjYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC01MjU3LDYwICsyNzE0LDQ0IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lG
UwogCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91bmQg
YSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAgc2V0
IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgor
ICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgor
ICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2ls
bCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFt
ZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2dfQ0M9
IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQogZmkKIGZpCi1hY19jdF9PQ0FNTE9Q
VD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BU
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X09DQU1MT1BUIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUxPUFQiID4mNjsg
fQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFz
X2VjaG8gIiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAot
ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE9QVD0ibm8i
Ci0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15
ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFz
X2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAg
T0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCi0gIGZpCi1lbHNlCi0gIE9DQU1MT1BUPSIkYWNfY3Zf
cHJvZ19PQ0FNTE9QVCIKLWZpCi0KLSAgICAgT0NBTUxCRVNUPWJ5dGUKLSAgICAgaWYgdGVzdCAi
JE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KLQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxh
dGlvbiBvbmx5LiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBv
Y2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9Ci0gICAgIGVsc2UKLQlU
TVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwp
JHxcMXxwJyBgCi0JaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRo
ZW4KLQkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQot
JGFzX2VjaG8gInZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRl
ZC4iID4mNjsgfQotCSAgICBPQ0FNTE9QVD1ubwotCWVsc2UKLQkgICAgT0NBTUxCRVNUPW9wdAot
CWZpCi0gICAgIGZpCi0KIAotCi0gICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKLSAgICAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMu
b3B0OyBhY193b3JkPSQyCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBpZiB0ZXN0IC1u
ICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNsLmV4ZQorICBkbwor
ICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ci
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY190
b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P
Q0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0ND
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgaWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTENE
T1RPUFQ9IiRPQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgor
ICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICkBAIC01MzE5LDcgKzI3NjAsNyBAQCBk
bwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIKKyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVm
aXgkYWNfcHJvZyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZp
CkBAIC01MzI5LDQzOCArMjc3MCw3MTUgQEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9D
QU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQKLWlmIHRlc3QgLW4gIiRPQ0FNTENE
T1RPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKLSRhc19lY2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7
IH0KK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2Vj
aG8gIiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCisg
ICAgdGVzdCAtbiAiJENDIiAmJiBicmVhaworICBkb25lCiBmaQotaWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxDRE9UT1BUIjsgdGhlbgotICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RP
VE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYy5vcHQiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sYy5vcHQ7IGFj
X3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZvciBh
Y19wcm9nIGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNf
cHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JGFjX3Byb2c7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1M
Q0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
Q0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BUIjsgdGhlbgotICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MQ0RPVE9QVD0iJGFjX2N0X09DQU1MQ0RPVE9QVCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBh
c19kaXIgaW4gJFBBVEgKIGRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSJvY2FtbGMub3B0IgotICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX3Byb2ci
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAi
JGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
KyAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRlc3QgIngkYWNf
Y3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitmaQorCitmaQor
CisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJv
cjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBD
IGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0
YWlscyIgIiRMSU5FTk8iIDUgOyB9CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0
IHRoZSBjb21waWxlci4KKyRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2Fj
X2NvbXBpbGVyPSQyCitmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247
IGRvCisgIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigo
JGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7
CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJc
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIk
YWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1
IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3Qu
ZXJyOyB0aGVuCisgICAgc2VkICcxMGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0
ZWQgLi4uCisgICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0
IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVy
cgorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorZG9uZQorCitjYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisK
K2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFu
X2ZpbGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCithY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2Zp
bGVzIGEub3V0IGEub3V0LmRTWU0gYS5leGUgYi5vdXQiCisjIFRyeSB0byBjcmVhdGUgYW4gZXhl
Y3V0YWJsZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNyZWdhcmQgYS5vdXQuCisjIEl0IHdpbGwgaGVs
cCB1cyBkaWFnbm9zZSBicm9rZW4gY29tcGlsZXJzLCBhbmQgZmluZGluZyBvdXQgYW4gaW50dWl0
aW9uCisjIG9mIGV4ZWV4dC4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3JrcyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzLi4uICIgPiY2OyB9CithY19s
aW5rX2RlZmF1bHQ9YCRhc19lY2hvICIkYWNfbGluayIgfCBzZWQgJ3MvIC1vICpjb25mdGVzdFte
IF0qLy8nYAorCisjIFRoZSBwb3NzaWJsZSBvdXRwdXQgZmlsZXM6CithY19maWxlcz0iYS5vdXQg
Y29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFfb3V0LmV4ZSBiLm91dCBjb25mdGVzdC4qIgor
CithY19ybWZpbGVzPQorZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzCitkbworICBjYXNlICRhY19m
aWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAq
LnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5v
YmogKSA7OworICAgICogKSBhY19ybWZpbGVzPSIkYWNfcm1maWxlcyAkYWNfZmlsZSI7OworICBl
c2FjCitkb25lCitybSAtZiAkYWNfcm1maWxlcworCitpZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19k
ZWZhdWx0IgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3Ry
eV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFs
IGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNo
b1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfbGlua19k
ZWZhdWx0IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH07IHRoZW4gOgorICAjIEF1dG9jb25mLTIuMTMgY291bGQgc2V0IHRoZSBhY19jdl9leGVl
eHQgdmFyaWFibGUgdG8gYG5vJy4KKyMgU28gaWdub3JlIGEgdmFsdWUgb2YgYG5vJywgb3RoZXJ3
aXNlIHRoaXMgd291bGQgbGVhZCB0byBgRVhFRVhUID0gbm8nCisjIGluIGEgTWFrZWZpbGUuICBX
ZSBzaG91bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4ZWV4dCBpZiBpdCB3YXMgY2FjaGVkLAorIyBz
byB0aGF0IHRoZSB1c2VyIGNhbiBzaG9ydC1jaXJjdWl0IHRoaXMgdGVzdCBmb3IgY29tcGlsZXJz
IHVua25vd24gdG8KKyMgQXV0b2NvbmYuCitmb3IgYWNfZmlsZSBpbiAkYWNfZmlsZXMgJycKK2Rv
CisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQorICBjYXNlICRhY19maWxlIGluCisg
ICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAq
LmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKQorCTs7
CisgICAgW2FiXS5vdXQgKQorCSMgV2UgZm91bmQgdGhlIGRlZmF1bHQgZXhlY3V0YWJsZSwgYnV0
IGV4ZWV4dD0nJyBpcyBtb3N0CisJIyBjZXJ0YWlubHkgcmlnaHQuCisJYnJlYWs7OworICAgICou
KiApCisJaWYgdGVzdCAiJHthY19jdl9leGVleHQrc2V0fSIgPSBzZXQgJiYgdGVzdCAiJGFjX2N2
X2V4ZWV4dCIgIT0gbm87CisJdGhlbiA6OyBlbHNlCisJICAgYWNfY3ZfZXhlZXh0PWBleHByICIk
YWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCisJZmkKKwkjIFdlIHNldCBhY19jdl9leGVleHQg
aGVyZSBiZWNhdXNlIHRoZSBsYXRlciB0ZXN0IGZvciBpdCBpcyBub3QKKwkjIHNhZmU6IGNyb3Nz
IGNvbXBpbGVycyBtYXkgbm90IGFkZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKKwkjIGFy
Z3VtZW50LCBzbyB3ZSBtYXkgbmVlZCB0byBrbm93IGl0IGF0IHRoYXQgcG9pbnQgYWxyZWFkeS4K
KwkjIEV2ZW4gaWYgdGhpcyBzZWN0aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFzIHRoZSBhZHZhbnRh
Z2Ugb2YKKwkjIGFjdHVhbGx5IHdvcmtpbmcuCisJYnJlYWs7OworICAgICogKQorCWJyZWFrOzsK
KyAgZXNhYwogZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCit0ZXN0ICIkYWNfY3ZfZXhl
ZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KIAotZmkKLWZpCi1hY19jdF9PQ0FNTENET1RPUFQ9
JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUCi1pZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxD
RE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X09DQU1MQ0RPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1M
Q0RPVE9QVCIgPiY2OyB9CiBlbHNlCisgIGFjX2ZpbGU9JycKK2ZpCitpZiB0ZXN0IC16ICIkYWNf
ZmlsZSI7IHRoZW4gOgogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCiskYXNfZWNobyAiJGFz
X21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFj
X2V4dCA+JjUKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQ0RPVE9QVCIgPSB4OyB0aGVuCi0g
ICAgT0NBTUxDRE9UT1BUPSJubyIKLSAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzok
YWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5l
ZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FNTENET1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAotICBm
aQoreyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mMjt9Cithc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBjYW5ub3QgY3JlYXRlIGV4ZWN1dGFi
bGVzCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0K
IGVsc2UKLSAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFz
X2VjaG8gInllcyIgPiY2OyB9CiBmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQg
ZmlsZSBuYW1lLi4uICIgPiY2OyB9Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhY19maWxlIiA+JjY7IH0K
K2FjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0CiAKLSAgICAgaWYgdGVzdCAiJE9DQU1MQ0RPVE9QVCIg
IT0gIm5vIjsgdGhlbgotCVRNUFZFUlNJT049YCRPQ0FNTENET1RPUFQgLXYgfCBzZWQgLW4gLWUg
J3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCi0JaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9
ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KLQkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1s
Yy5vcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j
YW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KLQllbHNlCi0JICAgIE9DQU1MQz0k
T0NBTUxDRE9UT1BUCi0JZmkKLSAgICAgZmkKLQotICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9w
dC5vcHQKLSAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsgdGhlbgotCWlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7
IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MT1BURE9U
T1BUPSIkT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgot
ZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBp
biAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQi
Ci0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQorcm0gLWYgLXIg
YS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25mdGVzdCRhY19jdl9leGVleHQgYi5vdXQKK2FjX2Ns
ZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxlcy4uLiAiID4mNjsg
fQoraWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiog
fCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0k
YWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUK
KyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3Qg
JGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgorICAjIElmIGJvdGggYGNvbmZ0ZXN0LmV4ZScgYW5k
IGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAod2VsbCwgb2JzZXJ2YWJsZSkKKyMgY2F0Y2ggYGNv
bmZ0ZXN0LmV4ZScuICBGb3IgaW5zdGFuY2Ugd2l0aCBDeWd3aW4sIGBscyBjb25mdGVzdCcgd2ls
bAorIyB3b3JrIHByb3Blcmx5IChpLmUuLCByZWZlciB0byBgY29uZnRlc3QuZXhlJyksIHdoaWxl
IGl0IHdvbid0IHdpdGgKKyMgYHJtJy4KK2ZvciBhY19maWxlIGluIGNvbmZ0ZXN0LmV4ZSBjb25m
dGVzdCBjb25mdGVzdC4qOyBkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAg
Y2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8
ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8
ICoubyB8ICoub2JqICkgOzsKKyAgICAqLiogKSBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxl
IiA6ICdbXi5dKlwoXC4uKlwpJ2AKKwkgIGJyZWFrOzsKKyAgICAqICkgYnJlYWs7OworICBlc2Fj
CiBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1PQ0FNTE9QVERPVE9Q
VD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAotaWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BU
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MT1BURE9UT1BUIiA+JjUKLSRhc19lY2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsg
fQogZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAi
Y2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVzOiBjYW5ub3QgY29tcGlsZSBhbmQg
bGluaworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9
CiBmaQorcm0gLWYgY29uZnRlc3QgY29uZnRlc3QkYWNfY3ZfZXhlZXh0Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2V4ZWV4dCIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9CiAKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQK
K0VYRUVYVD0kYWNfY3ZfZXhlZXh0CithY19leGVleHQ9JEVYRUVYVAorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lu
Y2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK0ZJTEUgKmYgPSBmb3BlbiAoImNvbmZ0
ZXN0Lm91dCIsICJ3Iik7CisgcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAwOwog
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5f
ZmlsZXMgY29uZnRlc3Qub3V0IgorIyBDaGVjayB0aGF0IHRoZSBjb21waWxlciBwcm9kdWNlcyBl
eGVjdXRhYmxlcyB3ZSBjYW4gcnVuLiAgSWYgbm90LCBlaXRoZXIKKyMgdGhlIGNvbXBpbGVyIGlz
IGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5nIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZy4u
LiAiID4mNjsgfQoraWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgIT0geWVzOyB0aGVuCisgIHsg
eyBhY190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8
ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7
Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFs
ICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0
dXMgPSAwOyB9CisgIGlmIHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCcKKyAgeyB7
IGNhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c
JGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRh
c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX3RyeSIpIDI+JjUKKyAg
YWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwk
PyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9OyB0aGVuCisg
ICAgY3Jvc3NfY29tcGlsaW5nPW5vCisgIGVsc2UKKyAgICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGls
aW5nIiA9IG1heWJlOyB0aGVuCisJY3Jvc3NfY29tcGlsaW5nPXllcworICAgIGVsc2UKKwl7IHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30K
K2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMuCitJZiB5b3Ug
bWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNlIFxgLS1ob3N0Jy4KK1NlZSBcYGNvbmZpZy5sb2cn
IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAgIGZpCisgIGZpCiBmaQotaWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCi0gIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
Im9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTE9QVERPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGNyb3NzX2NvbXBpbGluZyIgPiY1
CiskYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIgPiY2OyB9CisKK3JtIC1mIGNvbmZ0ZXN0LiRh
Y19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNvbmZ0ZXN0Lm91dAorYWNfY2xlYW5fZmlsZXM9
JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3Zfb2JqZXh0K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsg
dGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUPSIkYWNfY3RfT0NBTUxPUFRE
T1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAg
SUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE9QVERPVE9QVD0ib2NhbWxvcHQub3B0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4m
NQotICAgIGJyZWFrIDIKLSAgZmkKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitybSAtZiBjb25mdGVzdC5vIGNvbmZ0ZXN0Lm9i
agoraWYgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpc
IiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNo
bz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+
JjUKKyAgKGV2YWwgIiRhY19jb21waWxlIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cisg
IHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgorICBmb3IgYWNfZmlsZSBpbiBjb25mdGVz
dC5vIGNvbmZ0ZXN0Lm9iaiBjb25mdGVzdC4qOyBkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwg
Y29udGludWU7CisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwg
Ki50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5p
bmYgfCAqLmRTWU0gKSA7OworICAgICopIGFjX2N2X29iamV4dD1gZXhwciAiJGFjX2ZpbGUiIDog
Jy4qXC5cKC4qXCknYAorICAgICAgIGJyZWFrOzsKKyAgZXNhYwogZG9uZQotICBkb25lCi1JRlM9
JGFzX3NhdmVfSUZTCitlbHNlCisgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdh
czoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQogCit7IHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2Zu
X2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3Qg
Y29tcGlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUg
OyB9CiBmaQorcm0gLWYgY29uZnRlc3QuJGFjX2N2X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CiBm
aQotYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQK
LWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE9QVERPVE9Q
VCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7IH0KK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb2JqZXh0IiA+
JjUKKyRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KK09CSkVYVD0kYWNfY3Zfb2JqZXh0
CithY19vYmpleHQ9JE9CSkVYVAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNv
bXBpbGVyLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJfZ251K3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRh
c19lY2hvICJubyIgPiY2OyB9Ci1maQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKLSAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTE9QVERPVE9QVCIgPSB4OyB0aGVuCi0gICAgT0NBTUxPUFRET1RPUFQ9Im5vIgotICBl
bHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwotICAgIE9DQU1M
T1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERPVE9QVAotICBmaQoraW50CittYWluICgpCit7Cisj
aWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hva2UgbWUKKyNlbmRpZgorCisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY29tcGlsZXJfZ251PXllcwogZWxzZQotICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3By
b2dfT0NBTUxPUFRET1RPUFQiCisgIGFjX2NvbXBpbGVyX2dudT1ubwogZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorYWNfY3Zf
Y19jb21waWxlcl9nbnU9JGFjX2NvbXBpbGVyX2dudQogCi0JaWYgdGVzdCAiJE9DQU1MT1BURE9U
T1BUIiAhPSAibm8iOyB0aGVuCi0JICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAotCSAgIGlmIHRlc3QgIiRU
TVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCi0JICAgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9t
IG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNQotJGFzX2VjaG8gInZlcnNpb24g
ZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQotCSAg
IGVsc2UKLQkgICAgICBPQ0FNTE9QVD0kT0NBTUxPUFRET1RPUFQKLQkgICBmaQotICAgICAgICBm
aQotICAgICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX2Nv
bXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7IHRoZW4K
KyAgR0NDPXllcworZWxzZQorICBHQ0M9CitmaQorYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0
fQorYWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9m
bGFnCisgICBhY19jX3dlcnJvcl9mbGFnPXllcworICAgYWNfY3ZfcHJvZ19jY19nPW5vCisgICBD
RkxBR1M9Ii1nIgorICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwogCitpbnQKK21haW4gKCkKK3sKIAotICBmaQorICA7
CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P
IjsgdGhlbiA6CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKK2Vsc2UKKyAgQ0ZMQUdTPSIiCisgICAg
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u
ZmRlZnMuaC4gICovCiAKK2ludAorbWFpbiAoKQorewogCisgIDsKKyAgcmV0dXJuIDA7Cit9Citf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKIAotICAjIGNo
ZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgi
OyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1v
Y2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By
b2dfT0NBTUwrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgotZWxzZQotICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUw9
IiRPQ0FNTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCi1hc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwot
ICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX09D
QU1MPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot
ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworICBhY19j
X3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKKwkgQ0ZMQUdTPSItZyIKKwkgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworCitpbnQKK21haW4gKCkKK3sKIAorICA7CisgIHJldHVybiAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2df
Y2NfZz15ZXMKIGZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKIGZpCi1PQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAotaWYgdGVzdCAt
biAiJE9DQU1MIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJE9DQU1MIiA+JjUKLSRhc19lY2hvICIkT0NBTUwiID4mNjsgfQotZWxzZQot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAogZmkKLQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0
LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9y
X2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9n
X09DQU1MIjsgdGhlbgotICBhY19jdF9PQ0FNTD0kT0NBTUwKLSAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICJvY2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgb2NhbWw7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj
X2N0X09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KK2lm
IHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4KKyAgQ0ZMQUdTPSRhY19zYXZlX0NG
TEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KKyAgaWYgdGVzdCAi
JEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1nIC1PMiIKKyAgZWxzZQorICAgIENGTEFH
Uz0iLWciCisgIGZpCiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KLSAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0iJGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9
Ii1PMiIKKyAgZWxzZQorICAgIENGTEFHUz0KKyAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJ
U08gQzg5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2Vw
dCBJU08gQzg5Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfYzg5K3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKKyAg
YWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3NhdmVfQ0M9JENDCitjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVk
ZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4K
KyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyogTW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFy
ZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYuc2guICAqLworc3RydWN0IGJ1ZiB7IGlu
dCB4OyB9OworRklMRSAqICgqcmNzb3BlbikgKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwg
aW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBpKQorICAgICBjaGFyICoqcDsKKyAgICAgaW50IGk7
Cit7CisgIHJldHVybiBwW2ldOworfQorc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFy
ICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQoreworICBjaGFyICpzOworICB2YV9saXN0IHY7Cisg
IHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAocCwgdmFfYXJnICh2LGludCkpOworICB2YV9lbmQg
KHYpOworICByZXR1cm4gczsKK30KKworLyogT1NGIDQuMCBDb21wYXEgY2MgaXMgc29tZSBzb3J0
IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMKKyAgIGZ1bmN0aW9uIHByb3RvdHlw
ZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hhcmFjdGVyIGNvbnN0YW50cy4KKyAg
IFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5mb3J0dW5hdGVseSwgaW5zdGVhZCBhcmUg
c2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gnLiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVy
cm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAorICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1
cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMgb3V0IHRydWUsIGZvciBhbgorICAgYXJy
YXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5IHRvIHdyaXRlICdceDAwJz09MCB0byBn
ZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICovCitpbnQgb3Nm
NF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFdOworCisvKiBJQk0gQyA2IGZvciBBSVgg
aXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRl
cnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0ZXIgY29uc3RhbnRzLiAgKi8KKyNkZWZp
bmUgRk9PKHgpICd4JworaW50IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07
CisKK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOworc3RydWN0IHMxIHtpbnQgKCpmKSAoaW50
IGEpO307CitzdHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUgYSk7fTsKK2ludCBwYWlybmFtZXMg
KGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50
KSwgaW50LCBpbnQpOworaW50IGFyZ2M7CitjaGFyICoqYXJndjsKK2ludAorbWFpbiAoKQorewor
cmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2LCAxKSAhPSBh
cmd2WzFdOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitmb3IgYWNfYXJnIGluICcnIC1x
bGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBcCisJLUFlICItQWEgLURfSFBVWF9T
T1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKIGRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgotICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgQ0M9IiRhY19zYXZl
X0NDICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhu
byIgJiYgYnJlYWsKIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworcm0gLWYgY29uZnRl
c3QuJGFjX2V4dAorQ0M9JGFjX3NhdmVfQ0MKIAogZmkKLWZpCi1hY19jdF9PQ0FNTD0kYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgotICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1M
IiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUwiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8g
Im5vIiA+JjY7IH0KLWZpCi0KLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTCIgPSB4OyB0aGVuCi0g
ICAgT0NBTUw9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29s
X3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7
OworIyBBQ19DQUNIRV9WQUwKK2Nhc2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCisgIHgpCisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vbmUg
bmVlZGVkIiA+JjUKKyRhc19lY2hvICJub25lIG5lZWRlZCIgPiY2OyB9IDs7CisgIHhubykKKyAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdW5zdXBw
b3J0ZWQiID4mNQorJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKKyAgKikKKyAgICBD
Qz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7OwogZXNhYwotICAgIE9DQU1MPSRhY19jdF9P
Q0FNTAotICBmaQotZWxzZQotICBPQ0FNTD0iJGFjX2N2X3Byb2dfT0NBTUwiCitpZiB0ZXN0ICJ4
JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCiBmaQogCithY19leHQ9YworYWNf
Y3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFH
UyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVl
eHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUn
CithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CiAKLSAgIyBjaGVja2luZyBm
b3Igb2NhbWxkZXAKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxkZXA7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1M
REVQK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0Up
Li4uICIgPiY2OyB9CitzZXQgeCAke01BS0UtbWFrZX0KK2FjX21ha2U9YCRhc19lY2hvICIkMiIg
fCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAoraWYgZXZhbCAidGVzdCBcIlwk
e2FjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MREVQ
IjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJHthY190b29sX3ByZWZp
eH1vY2FtbGRlcCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZp
Ci1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKKyAgY2F0ID5jb25mdGVzdC5t
YWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAvYmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1B
S0UpPUBAQCUlJScKK19BQ0VPRgorIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFd
OiBFbnRlcmluZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1h
a2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUl
KikKKyAgICBldmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQor
ICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1m
IGNvbmZ0ZXN0Lm1ha2UKIGZpCi1PQ0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAotaWYgdGVz
dCAtbiAiJE9DQU1MREVQIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJE9DQU1MREVQIiA+JjUKLSRhc19lY2hvICIkT0NBTUxERVAiID4m
NjsgfQoraWYgZXZhbCB0ZXN0IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVz
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisgIFNFVF9NQUtFPQogZWxzZQogICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog
JGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgU0VUX01BS0U9Ik1BS0U9JHtNQUtFLW1ha2V9IgogZmkK
IAotCi1maQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxERVAiOyB0aGVuCi0gIGFjX2N0
X09DQU1MREVQPSRPQ0FNTERFUAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1s
ZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBv
Y2FtbGRlcDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxE
RVArc2V0fSIgPSBzZXQ7IHRoZW4gOgorIyBGaW5kIGEgZ29vZCBpbnN0YWxsIHByb2dyYW0uICBX
ZSBwcmVmZXIgYSBDIHByb2dyYW0gKGZhc3RlciksCisjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29v
ZCBhcyBhbm90aGVyLiAgQnV0IGF2b2lkIHRoZSBicm9rZW4gb3IKKyMgaW5jb21wYXRpYmxlIHZl
cnNpb25zOgorIyBTeXNWIC9ldGMvaW5zdGFsbCwgL3Vzci9zYmluL2luc3RhbGwKKyMgU3VuT1Mg
L3Vzci9ldGMvaW5zdGFsbAorIyBJUklYIC9zYmluL2luc3RhbGwKKyMgQUlYIC9iaW4vaW5zdGFs
bAorIyBBbWlnYU9TIC9DL2luc3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxv
cHB5IGRpc2NzCisjIEFJWCA0IC91c3IvYmluL2luc3RhbGxic2QsIHdoaWNoIGRvZXNuJ3Qgd29y
ayB3aXRob3V0IGEgLWcgZmxhZworIyBBRlMgL3Vzci9hZnN3cy9iaW4vaW5zdGFsbCwgd2hpY2gg
bWlzaGFuZGxlcyBub25leGlzdGVudCBhcmdzCisjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hp
Y2ggdHJpZXMgdG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCisjIE9TLzIncyBz
eXN0ZW0gaW5zdGFsbCwgd2hpY2ggaGFzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc2VtYW50aWMK
KyMgLi9pbnN0YWxsLCB3aGljaCBjYW4gYmUgZXJyb25lb3VzbHkgY3JlYXRlZCBieSBtYWtlIGZy
b20gLi9pbnN0YWxsLnNoLgorIyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0aGF0IGNhbm5vdCBp
bnN0YWxsIG11bHRpcGxlIGZpbGVzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwuLi4gIiA+JjY7IH0K
K2lmIHRlc3QgLXogIiRJTlNUQUxMIjsgdGhlbgoraWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3Rh
bGwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxERVA9IiRhY19jdF9PQ0FNTERFUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGFz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgK
IGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
LSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
LSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot
ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1maQot
ZmkKLWFjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQCi1pZiB0ZXN0IC1u
ICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxERVAiID4mNQotJGFzX2VjaG8gIiRhY19j
dF9PQ0FNTERFUCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQot
ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7IHRoZW4KLSAgICBPQ0FNTERFUD0ibm8i
Ci0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15
ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFz
X2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7CisgICAgIyBBY2Nv
dW50IGZvciBwZW9wbGUgd2hvIHB1dCB0cmFpbGluZyBzbGFzaGVzIGluIFBBVEggZWxlbWVudHMu
CitjYXNlICRhc19kaXIvIGluICMoKAorICAuLyB8IC4vLyB8IC9bY0NdLyogfCBcCisgIC9ldGMv
KiB8IC91c3Ivc2Jpbi8qIHwgL3Vzci9ldGMvKiB8IC9zYmluLyogfCAvdXNyL2Fmc3dzL2Jpbi8q
IHwgXAorICA/OltcXC9db3MyW1xcL11pbnN0YWxsW1xcL10qIHwgPzpbXFwvXU9TMltcXC9dSU5T
VEFMTFtcXC9dKiB8IFwKKyAgL3Vzci91Y2IvKiApIDs7CisgICopCisgICAgIyBPU0YxIGFuZCBT
Q08gT0RUIDMuMCBoYXZlIHRoZWlyIG93biBuYW1lcyBmb3IgaW5zdGFsbC4KKyAgICAjIERvbid0
IHVzZSBpbnN0YWxsYnNkIGZyb20gT1NGIHNpbmNlIGl0IGluc3RhbGxzIHN0dWZmIGFzIHJvb3QK
KyAgICAjIGJ5IGRlZmF1bHQuCisgICAgZm9yIGFjX3Byb2cgaW4gZ2luc3RhbGwgc2NvaW5zdCBp
bnN0YWxsOyBkbworICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisJaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
CSAgaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBkc3Btc2cgIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgorCSAgICAjIEFJ
WCBpbnN0YWxsLiAgSXQgaGFzIGFuIGluY29tcGF0aWJsZSBjYWxsaW5nIGNvbnZlbnRpb24uCisJ
ICAgIDoKKwkgIGVsaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBwd3Bs
dXMgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgor
CSAgICAjIHByb2dyYW0tc3BlY2lmaWMgaW5zdGFsbCBzY3JpcHQgdXNlZCBieSBIUCBwd3BsdXMt
LWRvbid0IHVzZS4KKwkgICAgOgorCSAgZWxzZQorCSAgICBybSAtcmYgY29uZnRlc3Qub25lIGNv
bmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwkgICAgZWNobyBvbmUgPiBjb25mdGVzdC5vbmUKKwkg
ICAgZWNobyB0d28gPiBjb25mdGVzdC50d28KKwkgICAgbWtkaXIgY29uZnRlc3QuZGlyCisJICAg
IGlmICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAtYyBjb25mdGVzdC5vbmUgY29uZnRl
c3QudHdvICJgcHdkYC9jb25mdGVzdC5kaXIiICYmCisJICAgICAgdGVzdCAtcyBjb25mdGVzdC5v
bmUgJiYgdGVzdCAtcyBjb25mdGVzdC50d28gJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRp
ci9jb25mdGVzdC5vbmUgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRpci9jb25mdGVzdC50
d28KKwkgICAgdGhlbgorCSAgICAgIGFjX2N2X3BhdGhfaW5zdGFsbD0iJGFzX2Rpci8kYWNfcHJv
ZyRhY19leGVjX2V4dCAtYyIKKwkgICAgICBicmVhayAzCisJICAgIGZpCisJICBmaQorCWZpCisg
ICAgICBkb25lCisgICAgZG9uZQorICAgIDs7CiBlc2FjCi0gICAgT0NBTUxERVA9JGFjX2N0X09D
QU1MREVQCi0gIGZpCi1lbHNlCi0gIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKLWZp
Ci0KIAotICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCi0gIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sbWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p
ZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9Q
IjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMK
LSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29s
X3ByZWZpeH1vY2FtbG1rdG9wIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFr
IDIKLSAgZmkKLWRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCitybSAtcmYgY29uZnRl
c3Qub25lIGNvbmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwogZmkKKyAgaWYgdGVzdCAiJHthY19j
dl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KKyAgICBJTlNUQUxMPSRhY19jdl9wYXRo
X2luc3RhbGwKKyAgZWxzZQorICAgICMgQXMgYSBsYXN0IHJlc29ydCwgdXNlIHRoZSBzbG93IHNo
ZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKKyAgICAjIHZhbHVlIGZvciBJTlNUQUxMIHdpdGhp
biBhIHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2UgdGhhdCB3aWxsCisgICAgIyBicmVhayBvdGhl
ciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBkaXJlY3RvcnkgaXMKKyAgICAjIHJl
bW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZlIG5hbWUuCisgICAgSU5TVEFMTD0k
YWNfaW5zdGFsbF9zaAorICBmaQogZmkKLU9DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxNS1RP
UAotaWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1Ci0kYXNfZWNobyAi
JE9DQU1MTUtUT1AiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElOU1RBTEwi
ID4mNQorJGFzX2VjaG8gIiRJTlNUQUxMIiA+JjY7IH0KIAorIyBVc2UgdGVzdCAteiBiZWNhdXNl
IFN1bk9TNCBzaCBtaXNoYW5kbGVzIGJyYWNlcyBpbiAke3Zhci12YWx9LgorIyBJdCB0aGlua3Mg
dGhlIGZpcnN0IGNsb3NlIGJyYWNlIGVuZHMgdGhlIHZhcmlhYmxlIHN1YnN0aXR1dGlvbi4KK3Rl
c3QgLXogIiRJTlNUQUxMX1BST0dSQU0iICYmIElOU1RBTExfUFJPR1JBTT0nJHtJTlNUQUxMfScK
IAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCi0gIGFjX2N0
X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBk
dW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit0ZXN0IC16ICIkSU5TVEFMTF9TQ1JJUFQiICYm
IElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworCit0ZXN0IC16ICIkSU5TVEFMTF9EQVRBIiAm
JiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0JworCisjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgInBlcmwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IHBlcmw7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MTUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRoX1BF
Ukwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LVE9QPSIkYWNfY3RfT0NBTUxNS1RPUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp
ZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
CisgIGNhc2UgJFBFUkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfUEVS
TD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor
ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3Ig
YXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtUT1A9Im9jYW1sbWt0b3AiCisgICAgYWNf
Y3ZfcGF0aF9QRVJMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTU3NjgsNTMgKzM0ODYsNDYgQEAg
ZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhf
UEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJMPSJubyIKKyAgOzsKK2VzYWMKIGZpCi1maQotYWNfY3Rf
T0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QCi1pZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxNS1RPUCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9QIiA+JjUKLSRhc19lY2hvICIkYWNfY3Rf
T0NBTUxNS1RPUCIgPiY2OyB9CitQRVJMPSRhY19jdl9wYXRoX1BFUkwKK2lmIHRlc3QgLW4gIiRQ
RVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19l
Y2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4
OyB0aGVuCi0gICAgT0NBTUxNS1RPUD0ibm8iCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAot
ICBmaQotZWxzZQotICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgotZmkKIAor
aWYgdGVzdCB4IiR7UEVSTH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kIHBlcmwsIHBsZWFzZSBpbnN0YWxsIHBlcmwiICIkTElORU5PIiA1CitmaQor
aWYgdGVzdCAieCR4YXBpIiA9ICJ4eSI7IHRoZW4gOgogCi0gICMgY2hlY2tpbmcgZm9yIG9jYW1s
bWtsaWIKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZp
eH1vY2FtbG1rbGliOyBhY193b3JkPSQyCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgY3VybC1jb25maWc7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9n
X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRoX0NV
Ukwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTE1L
TElCPSIkT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNl
Ci1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGNhc2UgJENVUkwgaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQ1VSTD0iJENVUkwiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBk
bwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9n
X09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICBhY19jdl9wYXRo
X0NVUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCiAgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTgyMiwzOSArMzUzMyw0NCBAQCBkb25lCiAg
IGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAm
JiBhY19jdl9wYXRoX0NVUkw9Im5vIgorICA7OworZXNhYwogZmkKLWZpCi1PQ0FNTE1LTElCPSRh
Y19jdl9wcm9nX09DQU1MTUtMSUIKLWlmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgotICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtM
SUIiID4mNQotJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KK0NVUkw9JGFjX2N2X3BhdGhf
Q1VSTAoraWYgdGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENVUkwiID4m
NjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAoraWYgdGVzdCB4IiR7
Q1VSTH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k
IGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKIGZp
Ci1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIjsgdGhlbgotICBhY19jdF9PQ0FN
TE1LTElCPSRPQ0FNTE1LTElCCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxt
a2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
b2NhbWxta2xpYjsgYWNfd29yZD0kMgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
eG1sMi1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15IHhtbDItY29uZmlnOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0
aF9YTUwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgog
ZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KLSAgYWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTE1LTElCPSIkYWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCisgIGNhc2UgJFhNTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9Y
TUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor
ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3Ig
YXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9Im9jYW1sbWtsaWIiCisgICAgYWNf
Y3ZfcGF0aF9YTUw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCiAgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTg2Miw0NCArMzU3OCwzOSBAQCBk
b25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9Y
TUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMKIGZpCi1maQotYWNfY3RfT0NB
TUxNS0xJQj0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCCi1pZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxNS0xJQiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LTElCIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NB
TUxNS0xJQiIgPiY2OyB9CitYTUw9JGFjX2N2X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFhNTCIgPiY1CiskYXNfZWNobyAiJFhNTCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8i
ID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgot
ICAgIE9DQU1MTUtMSUI9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRh
Y190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv
b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVk
PXllcyA7OwotZXNhYwotICAgIE9DQU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKLSAgZmkKLWVs
c2UKLSAgT0NBTUxNS0xJQj0iJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiIKKworaWYgdGVzdCB4IiR7
WE1MfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQg
eG1sMi1jb25maWcsIHBsZWFzZSBpbnN0YWxsIHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQogZmkK
IAorZmkKK2lmIHRlc3QgIngkb2NhbWx0b29scyIgPSAieHkiOyB0aGVuIDoKIAotICAjIGNoZWNr
aW5nIGZvciBvY2FtbGRvYworICAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjCiAgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3Jk
PSQyCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft
bGMiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19PQ0FNTERPQytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NB
TUxDK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVs
c2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MRE9D
PSIkT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0
IC1uICIkT0NBTUxDIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQz0iJE9DQU1MQyIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICkBAIC01OTA4LDcgKzM2MTksNyBA
QCBkbwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJHthY190
b29sX3ByZWZpeH1vY2FtbGRvYyIKKyAgICBhY19jdl9wcm9nX09DQU1MQz0iJHthY190b29sX3By
ZWZpeH1vY2FtbGMiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBm
aQpAQCAtNTkxOCwxMCArMzYyOSwxMCBAQCBJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotT0NB
TUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKLWlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4K
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERPQyIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KK09DQU1MQz0kYWNfY3ZfcHJv
Z19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+JjUKKyRhc19lY2hvICIk
T0NBTUxDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CkBAIC01OTI5LDE3
ICszNjQwLDE3IEBAIGZpCiAKIAogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MRE9D
IjsgdGhlbgotICBhY19jdF9PQ0FNTERPQz0kT0NBTUxET0MKLSAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICJvY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCi1zZXQgZHVtbXkgb2NhbWxkb2M7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9w
cm9nX09DQU1MQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxDPSRPQ0FNTEMKKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3Byb2dfYWNfY3RfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19j
dl9wcm9nX2FjX2N0X09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRoZW4K
LSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09DQU1MRE9DIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQyI7IHRo
ZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9IiRhY19jdF9PQ0FNTEMiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSApAQCAtNTk0OCw3ICszNjU5LDcgQEAgZG8K
ICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9jYW1s
ZG9jIgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSJvY2FtbGMiCiAgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTk1OCwxNyArMzY2OSwxNyBAQCBJ
RlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotYWNfY3RfT0NBTUxET0M9JGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxET0MKLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRoZW4KLSAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERP
QyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MRE9DIiA+JjY7IH0KK2FjX2N0X09DQU1MQz0k
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxDIiA+JjY7IH0KIGVsc2UKICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
ICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxET0Mi
ID0geDsgdGhlbgotICAgIE9DQU1MRE9DPSJubyIKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEMi
ID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCiAgIGVsc2UKICAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCiB5ZXM6KQpAQCAtNTk3NiwyNCArMzY4Nyw0MSBAQCB5
ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBl
c2FjCi0gICAgT0NBTUxET0M9JGFjX2N0X09DQU1MRE9DCisgICAgT0NBTUxDPSRhY19jdF9PQ0FN
TEMKICAgZmkKIGVsc2UKLSAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgorICBPQ0FN
TEM9IiRhY19jdl9wcm9nX09DQU1MQyIKIGZpCiAKIAotICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1
aWxkCi0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxidWlsZDsgYWNfd29yZD0kMgorICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVu
CisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24q
ICpcKC4qXCkkfFwxfHAnYAorICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjUKKyRhc19l
Y2hvICJPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT04iID4mNjsgfQorICAgICAjIElmIE9D
QU1MTElCIGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhl
bgorICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1M
QyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NBTUxMSUIgcHJldmlv
dXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjUKKyRhc19lY2hvICJPQ0FNTExJQiBwcmV2aW91
c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNjsgfQorICAgICBmaQorICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NhbWwgbGlicmFyeSBwYXRo
IGlzICRPQ0FNTExJQiIgPiY1CiskYXNfZWNobyAiT0NhbWwgbGlicmFyeSBwYXRoIGlzICRPQ0FN
TExJQiIgPiY2OyB9CisKKworCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQKKyAgICAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQ7
IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQlVJTEQrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BUK3NldH0iID0gc2V0OyB0
aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAi
JE9DQU1MQlVJTEQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0IC1uICIkT0NBTUxP
UFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiRPQ0FNTE9QVCIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICkBAIC02MDAyLDcgKzM3MzAsNyBAQCBkbwog
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sYnVpbGQiCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE9QVD0iJHthY190b29sX3By
ZWZpeH1vY2FtbG9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02MDEyLDEwICszNzQwLDEwIEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1P
Q0FNTEJVSUxEPSRhY19jdl9wcm9nX09DQU1MQlVJTEQKLWlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxE
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MQlVJTEQiID4mNQotJGFzX2VjaG8gIiRPQ0FNTEJVSUxEIiA+JjY7IH0KK09DQU1M
T1BUPSRhY19jdl9wcm9nX09DQU1MT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxP
UFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAi
bm8iID4mNjsgfQpAQCAtNjAyMywxNyArMzc1MSwxNyBAQCBmaQogCiAKIGZpCi1pZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIjsgdGhlbgotICBhY19jdF9PQ0FNTEJVSUxEPSRPQ0FN
TEJVSUxECi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxidWlsZDsg
YWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFQiOyB0aGVuCisgIGFj
X2N0X09DQU1MT1BUPSRPQ0FNTE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9j
YW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSBvY2FtbG9wdDsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NB
TUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgogZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxCVUlMRCI7IHRoZW4KLSAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTEJVSUxEPSIkYWNfY3RfT0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKQEAgLTYwNDIsNyArMzc3MCw3IEBAIGRv
CiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9Im9j
YW1sYnVpbGQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0ib2NhbWxvcHQiCiAgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjA1MiwxNyArMzc4
MCwxNyBAQCBJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotYWNfY3RfT0NBTUxCVUlMRD0kYWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxECi1pZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxCVUlMRCI7
IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdF9PQ0FNTEJVSUxEIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUxCVUlMRCIgPiY2
OyB9CithY19jdF9PQ0FNTE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVAoraWYgdGVzdCAt
biAiJGFjX2N0X09DQU1MT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BUIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3RfT0NBTUxPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAK
LSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KLSAgICBPQ0FNTEJVSUxE
PSJubyIKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxP
UFQ9Im5vIgogICBlbHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgogeWVzOikKQEAgLTYwNzAsNDQgKzM3OTgsNDkgQEAgeWVzOikKICRhc19lY2hvICIkYXNf
bWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp
cGxldCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7OwogZXNhYwotICAgIE9DQU1MQlVJTEQ9
JGFjX2N0X09DQU1MQlVJTEQKKyAgICBPQ0FNTE9QVD0kYWNfY3RfT0NBTUxPUFQKICAgZmkKIGVs
c2UKLSAgT0NBTUxCVUlMRD0iJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCIKKyAgT0NBTUxPUFQ9IiRh
Y19jdl9wcm9nX09DQU1MT1BUIgogZmkKIAorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0
ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNv
bXBpbGF0aW9uIG9ubHkuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IENhbm5vdCBm
aW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIgPiYyO30KKyAgICAgZWxz
ZQorCVRNUFZFUlNJT049YCRPQ0FNTE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpc
KC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04i
IDsgdGhlbgorCSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLiIg
PiY1CiskYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlz
Y2FyZGVkLiIgPiY2OyB9CisJICAgIE9DQU1MT1BUPW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9
b3B0CisJZmkKKyAgICAgZmkKIAotICAgIGlmIHRlc3QgIngkT0NBTUxDIiA9ICJ4bm8iOyB0aGVu
IDoKLQotICAgICAgICBpZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIjsgdGhl
biA6Ci0KLSAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJPY2FtbCB0b29scyBlbmFibGVkLCBi
dXQgdW5hYmxlIHRvIGZpbmQgT2NhbWwiICIkTElORU5PIiA1Ci1maQotICAgICAgICBvY2FtbHRv
b2xzPSJuIgogCi1maQogCi1maQotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiYXNoIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBiYXNoOyBh
Y193b3JkPSQyCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgaWYgdGVzdCAt
biAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0OyBhY193
b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoK
K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgog
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRCQVNIIGluCi0gIFtc
XC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9UT1BU
IjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVf
SUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0JBU0g9IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxjLm9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh
ayAyCiAgIGZpCkBAIC02MTE1LDU2ICszODQ4LDM5IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19z
YXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3BhdGhfQkFT
SD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotQkFTSD0kYWNfY3ZfcGF0aF9CQVNICi1pZiB0ZXN0IC1u
ICIkQkFTSCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRCQVNIIiA+JjUKLSRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitmaQorT0NBTUxD
RE9UT1BUPSRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9Q
VCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRPQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTENET1RPUFQiID4mNjsgfQog
ZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7QkFTSH0i
ID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gs
IHBsZWFzZSBpbnN0YWxsIGJhc2giICIkTElORU5PIiA1Ci1maQotaWYgdGVzdCAieCRweXRob250
b29scyIgPSAieHkiOyB0aGVuIDoKLQotICAgIGlmIGVjaG8gIiRQWVRIT04iIHwgZ3JlcCAtcSAi
Xi8iOyB0aGVuIDoKLQotICAgICAgICBQWVRIT05QQVRIPSRQWVRIT04KLSAgICAgICAgUFlUSE9O
PWBiYXNlbmFtZSAkUFlUSE9OUEFUSGAKLQotZWxpZiB0ZXN0IC16ICIkUFlUSE9OIjsgdGhlbiA6
Ci0gIFBZVEhPTj0icHl0aG9uIgotZWxzZQotICBhc19mbl9lcnJvciAkPyAiUFlUSE9OIHNwZWNp
ZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoIiAiJExJTkVOTyIgNQogZmkKLSAgICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRQWVRIT04iLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRQWVRIT047IGFjX3dvcmQ9JDIKK2lmIHRl
c3QgLXogIiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxDRE9U
T1BUPSRPQ0FNTENET1RPUFQKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMu
b3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBv
Y2FtbGMub3B0OyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBm
b3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QWVRIT05QQVRI
K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENE
T1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgog
ZWxzZQotICBjYXNlICRQWVRIT05QQVRIIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19j
dl9wYXRoX1BZVEhPTlBBVEg9IiRQWVRIT05QQVRIIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BUIjsgdGhl
bgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVD0iJGFjX2N0X09DQU1MQ0RPVE9QVCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFz
X3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN
TENET1RPUFQ9Im9jYW1sYy5vcHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJl
YWsgMgogICBmaQpAQCAtNjE3MiwxNDAgKzM4ODgsMTcyIEBAIGRvbmUKICAgZG9uZQogSUZTPSRh
c19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1BZVEhPTlBBVEgiICYmIGFjX2N2
X3BhdGhfUFlUSE9OUEFUSD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotUFlUSE9OUEFUSD0kYWNfY3Zf
cGF0aF9QWVRIT05QQVRICi1pZiB0ZXN0IC1uICIkUFlUSE9OUEFUSCI7IHRoZW4KLSAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQWVRIT05QQVRIIiA+
JjUKLSRhc19lY2hvICIkUFlUSE9OUEFUSCIgPiY2OyB9CitmaQorYWNfY3RfT0NBTUxDRE9UT1BU
PSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1M
Q0RPVE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FN
TENET1RPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQot
aWYgdGVzdCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3Ig
JD8gIlVuYWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElO
RU5PIiA1Ci1maQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KLWAkUFlUSE9OIC1j
ICdpbXBvcnQgc3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikp
J2AKLWlmIHRlc3QgIiQ/IiAhPSAiMCIKLXRoZW4KLSAgICBweXRob25fdmVyc2lvbj1gJFBZVEhP
TiAtViAyPiYxYAotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotICAgIGFzX2ZuX2Vycm9yICQ/
ICIkcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlz
IDIuMyIgIiRMSU5FTk8iIDUKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsg
dGhlbgorICAgIE9DQU1MQ0RPVE9QVD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RP
UFQKKyAgZmkKIGVsc2UKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQorICBPQ0FNTENET1RP
UFQ9IiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCIKIGZpCiAKLWFjX3B5dGhvbl92ZXJzaW9uPWAk
UFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50IGRpc3R1
dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIlZFUlNJT04iKSdgCi1hY19wcmV2aW91c19j
cHBmbGFncz0kQ1BQRkxBR1MKLUNQUEZMQUdTPSIkQ0ZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQg
ZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50ICItSSIgKyBkaXN0dXRpbHMuc3lzY29u
ZmlnLmdldF9jb25maWdfdmFyKCJJTkNMVURFUFkiKSdgIgotQ1BQRkxBR1M9IiRDUFBGTEFHUyBg
JFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0
dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJDRkxBR1MiKSdgIgotYWNfcHJldmlvdXNf
bGRmbGFncz0kTERGTEFHUwotTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBk
aXN0dXRpbHMuc3lzY29uZmlnOyBcCi0gICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRf
Y29uZmlnX3ZhcigiTElCUyIpJ2AiCi1MREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1w
b3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmln
LmdldF9jb25maWdfdmFyKCJTWVNMSUJTIiknYCIKLUxERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9O
IC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50ICItTCIgKyBkaXN0
dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBsYXRfc3BlY2lmaWM9MSxcCi0gICAgc3Rh
bmRhcmRfbGliPTEpICsgIi9jb25maWciJ2AiCi1MREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAt
YyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0dXRpbHMuc3lz
Y29uZmlnLmdldF9jb25maWdfdmFyKCJMSU5LRk9SU0hBUkVEIiknYCIKLUxERkxBR1M9IiRMREZM
QUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50
IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIkxERkxBR1MiKSdgIgorICAgICBp
ZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1M
Q0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlp
ZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlm
ZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19lY2hvICJ2
ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsg
fQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBmaQogCi1hY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiUHl0aG9uLmgiICJhY19jdl9oZWFk
ZXJfUHl0aG9uX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVh
ZGVyX1B5dGhvbl9oIiA9IHgiInllczsgdGhlbiA6CisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1s
b3B0Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJaWYgdGVz
dCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg
b2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9w
dDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBp
ZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQ9IiRPQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9w
dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAorZmkKK2ZpCitPQ0FNTE9QVERPVE9QVD0kYWNfY3Zf
cHJvZ19PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1M
T1BURE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsgfQogZWxzZQot
ICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgUHl0aG9uIGRldmVsb3BtZW50IGhlYWRl
cnMiICIkTElORU5PIiA1CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1hc19hY19M
aWI9YCRhc19lY2hvICJhY19jdl9saWJfcHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uJydfUHlBcmdf
UGFyc2VUdXBsZSIgfCAkYXNfdHJfc2hgCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciBQeUFyZ19QYXJzZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5
dGhvbl92ZXJzaW9uIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBQeUFyZ19QYXJzZVR1
cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uLi4uICIgPiY2OyB9Ci1pZiBldmFsICJ0
ZXN0IFwiXCR7JGFzX2FjX0xpYitzZXR9XCIiID0gc2V0OyB0aGVuIDoKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFRET1RP
UFQ9JE9DQU1MT1BURE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxv
cHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSBvY2FtbG9wdC5vcHQ7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MT1BURE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxw
eXRob24kYWNfcHl0aG9uX3ZlcnNpb24gICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlk
ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBj
aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAg
YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5
LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIFB5QXJn
X1BhcnNlVHVwbGUgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBQeUFyZ19QYXJzZVR1cGxl
ICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6Ci0gIGV2YWwgIiRhc19hY19MaWI9eWVzIgorICBpZiB0ZXN0IC1uICIk
YWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE
T1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCiBlbHNlCi0gIGV2YWwgIiRhc19hY19MaWI9bm8iCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BU
RE9UT1BUPSJvY2FtbG9wdC5vcHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi1ybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkK
LWV2YWwgYWNfcmVzPVwkJGFzX2FjX0xpYgotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3Jl
cyIgPiY2OyB9Ci1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0xpYiJcIiA9IHgieWVzIjsgdGhl
biA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZF
X0xJQnB5dGhvbiRhY19weXRob25fdmVyc2lvbiIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQot
ICBMSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiAkTElCUyIKK2FjX2N0X09DQU1MT1BU
RE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8g
IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKIAorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BURE9UT1BUIiA9IHg7IHRoZW4K
KyAgICBPQ0FNTE9QVERPVE9QVD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxp
bmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93
YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxPUFRET1RPUFQ9JGFjX2N0X09DQU1MT1BURE9U
T1BUCisgIGZpCiBlbHNlCi0gIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRh
YmxlIHB5dGhvbiBkZXZlbG9wbWVudCBsaWJyYXJ5IiAiJExJTkVOTyIgNQorICBPQ0FNTE9QVERP
VE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiCiBmaQogCi1DUFBGTEFHUz0kYWNfcHJl
dmlvdXNfY3BwZmxhZ3MKLUxETEZBR1M9JGFjX3ByZXZpb3VzX2xkZmxhZ3MKKwlpZiB0ZXN0ICIk
T0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRE
T1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAg
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbiBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIgPiY1CiskYXNfZWNo
byAidmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIg
PiY2OyB9CisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZp
CisgICAgICAgIGZpCisgICAgIGZpCiAKIAotZmkKLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0
IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCisgIGZpCisKKworCisgICMgY2hlY2tpbmcgZm9y
IG9jYW1sIHRvcGxldmVsCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xf
cHJlZml4fW9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVY
VCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUwrc2V0fSIg
PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNl
ICRYR0VUVEVYVCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YR0VUVEVY
VD0iJFhHRVRURVhUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0
aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor
ICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUw9IiRPQ0FNTCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFz
X3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1hHRVRURVhUPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsg
MgogICBmaQpAQCAtNjMxMyw0NCArNDA2MSwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2
ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIgJiYgYWNfY3ZfcGF0aF9Y
R0VUVEVYVD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotWEdFVFRFWFQ9JGFjX2N2X3BhdGhfWEdFVFRF
WFQKLWlmIHRlc3QgLW4gIiRYR0VUVEVYVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1Ci0kYXNfZWNobyAiJFhH
RVRURVhUIiA+JjY7IH0KK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAtbiAi
JE9DQU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJE9DQU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQogZWxzZQogICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog
JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4
Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4dCwg
cGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1CiBmaQotIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KLXNldCBkdW1teSBhczg2OyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19P
Q0FNTCI7IHRoZW4KKyAgYWNfY3RfT0NBTUw9JE9DQU1MCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9BUzg2
K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTCtz
ZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0g
IGNhc2UgJEFTODYgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQVM4Nj0i
JEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7
OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0iJGFj
X2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
QVM4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MPSJvY2FtbCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02MzU4LDQ0ICs0MTAxLDUzIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lG
UwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0FTODYiICYmIGFjX2N2X3BhdGhfQVM4Nj0ibm8i
Ci0gIDs7Ci1lc2FjCiBmaQotQVM4Nj0kYWNfY3ZfcGF0aF9BUzg2Ci1pZiB0ZXN0IC1uICIkQVM4
NiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRBUzg2IiA+JjUKLSRhc19lY2hvICIkQVM4NiIgPiY2OyB9CitmaQorYWNfY3RfT0NBTUw9
JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KIGVsc2UKICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRh
c19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIke0FTODZ9IiA9PSB4Im5vIgot
dGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhczg2LCBwbGVhc2UgaW5z
dGFsbCBhczg2IiAiJExJTkVOTyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MIiA9IHg7IHRo
ZW4KKyAgICBPQ0FNTD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFj
X3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9v
bHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9
eWVzIDs7Citlc2FjCisgICAgT0NBTUw9JGFjX2N0X09DQU1MCisgIGZpCitlbHNlCisgIE9DQU1M
PSIkYWNfY3ZfcHJvZ19PQ0FNTCIKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImxk
ODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGxk
ODY7IGFjX3dvcmQ9JDIKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBhY193b3Jk
PSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoKK2lm
IHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJExEODYgaW4KLSAgW1xcL10qIHwg
PzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfTEQ4Nj0iJExEODYiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZv
ciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgotICAgIGFjX2N2X3BhdGhfTEQ4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIK
KyAgICBhY19jdl9wcm9nX09DQU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgogICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY0MDMsNDQgKzQx
NTUsMzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFj
X2N2X3BhdGhfTEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKLSAgOzsKLWVzYWMKIGZpCi1M
RDg2PSRhY19jdl9wYXRoX0xEODYKLWlmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgotICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJExEODYiID4mNQotJGFz
X2VjaG8gIiRMRDg2IiA+JjY7IH0KK2ZpCitPQ0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAor
aWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MREVQIiA+JjUKKyRhc19lY2hvICIkT0NBTUxE
RVAiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVz
dCB4IiR7TEQ4Nn0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGxkODYsIHBsZWFzZSBpbnN0YWxsIGxkODYiICIkTElORU5PIiA1CiBmaQotIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgotc2V0IGR1bW15IGJjYzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxERVAiOyB0aGVuCisgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAorICAjIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRlcDsgYWNfd29yZD0kMgogeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0
ZXN0ICIke2FjX2N2X3BhdGhfQkNDK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJEJDQyBpbgotICBbXFwvXSogfCA/OltcXC9d
KikKLSAgYWNfY3ZfcGF0aF9CQ0M9IiRCQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfQkNDPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgogICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY0NDgsNDQgKzQxOTUs
NTMgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2
X3BhdGhfQkNDIiAmJiBhY19jdl9wYXRoX0JDQz0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotQkNDPSRh
Y19jdl9wYXRoX0JDQwotaWYgdGVzdCAtbiAiJEJDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCQ0MiID4mNQotJGFzX2VjaG8gIiRC
Q0MiID4mNjsgfQorZmkKK2FjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQ
CitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxERVAiID4mNQorJGFz
X2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4m
NjsgfQogZmkKIAotCi1pZiB0ZXN0IHgiJHtCQ0N9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2Zu
X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiY2MsIHBsZWFzZSBpbnN0YWxsIGJjYyIgIiRMSU5F
Tk8iIDUKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTERFUCIgPSB4OyB0aGVuCisgICAgT0NBTUxE
RVA9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIE9DQU1MREVQPSRhY19jdF9PQ0FNTERFUAorICBmaQorZWxzZQorICBPQ0FNTERFUD0i
JGFjX2N2X3Byb2dfT0NBTUxERVAiCiBmaQotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJp
YXNsIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBp
YXNsOyBhY193b3JkPSQyCisKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRl
c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsg
YWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfSUFTTCtzZXR9IiA9IHNldDsgdGhl
biA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6
CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJElBU0wgaW4KLSAg
W1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfSUFTTD0iJElBU0wiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9Q
IjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMK
ICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfSUFTTD0iJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxta3RvcCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02NDkzLDIzOCArNDI0OSw5MyBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9J
RlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5v
IgotICA7OwotZXNhYwogZmkKLUlBU0w9JGFjX2N2X3BhdGhfSUFTTAotaWYgdGVzdCAtbiAiJElB
U0wiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkSUFTTCIgPiY1Ci0kYXNfZWNobyAiJElBU0wiID4mNjsgfQorZmkKK09DQU1MTUtUT1A9
JGFjX2N2X3Byb2dfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxN
S1RPUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MTUtUT1AiID4mNjsgfQogZWxzZQogICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7SUFTTH0iID09IHgibm8iCi10aGVu
Ci0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGlhc2wsIHBsZWFzZSBpbnN0YWxs
IGlhc2wiICIkTElORU5PIiA1Ci1maQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAidXVpZC91dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF91dWlkX2giICIkYWNfaW5j
bHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiA9IHgi
InllczsgdGhlbiA6Ci0KLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZCIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7
YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMK
LUxJQlM9Ii1sdXVpZCAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0Mg
aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVz
ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFu
ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lm
ZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgdXVpZF9jbGVhciAoKTsK
LWludAotbWFpbiAoKQotewotcmV0dXJuIHV1aWRfY2xlYXIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7
Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf
Y3ZfbGliX3V1aWRfdXVpZF9jbGVhcj15ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX3V1aWRfdXVpZF9j
bGVhcj1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
XAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVj
a19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjUKLSRhc19lY2hvICIk
YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl91
dWlkX3V1aWRfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKLSAgbGlidXVpZD0ieSIKLWZpCi0KLQog
ZmkKLQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidXVpZC5oIiAi
YWNfY3ZfaGVhZGVyX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRh
Y19jdl9oZWFkZXJfdXVpZF9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYnV1aWQ9InkiCi1maQot
Ci0KLWlmIHRlc3QgIiRsaWJ1dWlkIiAhPSAieSI7IHRoZW4gOgotCi0gICAgYXNfZm5fZXJyb3Ig
JD8gImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBsaWJyYXJ5IiAiJExJTkVOTyIgNQotCi1maQot
Ci0KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJjdXJzZXMuaCIgImFj
X2N2X2hlYWRlcl9jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRh
Y19jdl9oZWFkZXJfY3Vyc2VzX2giID0geCIieWVzOyB0aGVuIDoKLQotICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vy
c2VzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcy4uLiAi
ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfY3Vyc2VzX2NsZWFyK3NldH0iID0gc2V0OyB0
aGVuIDoKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCisgIGFjX2N0
X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBk
dW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LVE9QK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxjdXJz
ZXMgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot
LyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHBy
b3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0
IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg
YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVz
cGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGNsZWFyICgpOwotaW50Ci1tYWluICgpCi17
Ci1yZXR1cm4gY2xlYXIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj15
ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj1ubwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3Vy
c2VzX2NsZWFyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPiY2OyB9
Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKLSAg
Y3Vyc2VzPSJ5IgotZWxzZQotICBjdXJzZXM9Im4iCi1maQotCi0KLWVsc2UKLSAgY3Vyc2VzPSJu
IgotZmkKLQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibmN1cnNl
cy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYg
dGVzdCAieCRhY19jdl9oZWFkZXJfbmN1cnNlc19oIiA9IHgiInllczsgdGhlbiA6Ci0KLSAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVh
ciBpbiAtbG5jdXJzZXMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1s
bmN1cnNlcy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfbmN1cnNlc19jbGVhcitz
ZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
TUtUT1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxuY3Vyc2Vz
ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0ib2NhbWxta3RvcCIK
KyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRv
bmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90
b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBt
YXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFy
Z3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3Bs
dXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBjbGVhciAoKTsKLWludAotbWFpbiAoKQotewot
cmV0dXJuIGNsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9j
X3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyPXll
cwotZWxzZQotICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj1ubwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbmN1
cnNlc19jbGVhciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjY7
IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoK
LSAgbmN1cnNlcz0ieSIKLWVsc2UKLSAgbmN1cnNlcz0ibiIKIGZpCi0KLQorYWNfY3RfT0NBTUxN
S1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxNS1RPUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9QIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxN
S1RPUCIgPiY2OyB9CiBlbHNlCi0gIG5jdXJzZXM9Im4iCi1maQotCi0KLWlmIHRlc3QgIiRjdXJz
ZXMiID0gIm4iICYmIHRlc3QgIiRuY3Vyc2VzIiA9ICJuIjsgdGhlbiA6Ci0KLSAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYSBzdWl0YWJsZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5F
Tk8iIDUKLQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCi0jIFByZWZlciBuY3Vyc2VzIG92
ZXIgY3Vyc2VzIGlmIGJvdGggYXJlIHByZXNlbnQKLWlmIHRlc3QgIiRuY3Vyc2VzIiA9ICJ5Ijsg
dGhlbiA6Ci0KLSAgICBDVVJTRVNfTElCUz0iLWxuY3Vyc2VzIgotCi0kYXNfZWNobyAiI2RlZmlu
ZSBJTkNMVURFX0NVUlNFU19IIDxuY3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKLQogCisgIGlmIHRl
c3QgIngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4OyB0aGVuCisgICAgT0NBTUxNS1RPUD0ibm8iCisg
IGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6
KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2lu
ZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGgg
aG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NB
TUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAorICBmaQogZWxzZQotCi0gICAgQ1VSU0VTX0xJQlM9
Ii1sY3Vyc2VzIgotCi0kYXNfZWNobyAiI2RlZmluZSBJTkNMVURFX0NVUlNFU19IIDxjdXJzZXMu
aD4iID4+Y29uZmRlZnMuaAotCi0KKyAgT0NBTUxNS1RPUD0iJGFjX2N2X3Byb2dfT0NBTUxNS1RP
UCIKIGZpCiAKIAotCi0KLQotCi0KLQotaWYgdGVzdCAieCRhY19jdl9lbnZfUEtHX0NPTkZJR19z
ZXQiICE9ICJ4c2V0IjsgdGhlbgotCWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25m
aWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9cGtnLWNvbmZpZzsgYWNfd29yZD0kMgorICAjIGNoZWNraW5nIGZvciBv
Y2FtbG1rbGliCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWIiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfUEtH
X0NPTkZJRytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Ci1lbHNlCi0gIGNhc2UgJFBLR19DT05GSUcgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFj
X2N2X3BhdGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS0xJQitzZXR9
IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlm
IHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiRP
Q0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
UEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9n
X09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKICAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC02NzMyLDEzICs0MzQzLDEyIEBAIGRv
bmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi0gIDs7Ci1lc2FjCiBmaQotUEtHX0NPTkZJ
Rz0kYWNfY3ZfcGF0aF9QS0dfQ09ORklHCi1pZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4K
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQS0df
Q09ORklHIiA+JjUKLSRhc19lY2hvICIkUEtHX0NPTkZJRyIgPiY2OyB9CitmaQorT0NBTUxNS0xJ
Qj0kYWNfY3ZfcHJvZ19PQ0FNTE1LTElCCitpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TE1LTElCIiA+JjUKKyRhc19lY2hvICIkT0NBTUxNS0xJQiIgPiY2OyB9CiBlbHNlCiAgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNf
ZWNobyAibm8iID4mNjsgfQpAQCAtNjc0NiwyOCArNDM1NiwyNiBAQCBmaQogCiAKIGZpCi1pZiB0
ZXN0IC16ICIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIjsgdGhlbgotICBhY19wdF9QS0dfQ09ORklH
PSRQS0dfQ09ORklHCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGtnLWNvbmZpZyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgcGtnLWNv
bmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRo
ZW4KKyAgYWNfY3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIm9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19j
dl9wYXRoX2FjX3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHth
Y19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCi0g
IFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19w
dF9QS0dfQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0
aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor
ICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LTElCPSIkYWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBm
b3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KLSAgICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSJvY2FtbG1rbGli
IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY3NzUs
MjAgKzQzODMsMTkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgOzsKLWVz
YWMKIGZpCi1hY19wdF9QS0dfQ09ORklHPSRhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUcKLWlm
IHRlc3QgLW4gIiRhY19wdF9QS0dfQ09ORklHIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3B0X1BLR19DT05GSUciID4mNQotJGFz
X2VjaG8gIiRhY19wdF9QS0dfQ09ORklHIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTE1LTElCPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElC
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+
JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngk
YWNfcHRfUEtHX0NPTkZJRyIgPSB4OyB0aGVuCi0gICAgUEtHX0NPTkZJRz0iIgorICBpZiB0ZXN0
ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgorICAgIE9DQU1MTUtMSUI9Im5vIgogICBl
bHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgogeWVzOikK
QEAgLTY3OTYsNjcxICs0NDAzLDc2MiBAQCB5ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBlc2FjCi0gICAgUEtHX0NPTkZJRz0kYWNfcHRfUEtH
X0NPTkZJRworICAgIE9DQU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKICAgZmkKIGVsc2UKLSAg
UEtHX0NPTkZJRz0iJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyIKLWZpCi0KLWZpCi1pZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyI7IHRoZW4KLQlfcGtnX21pbl92ZXJzaW9uPTAuOS4wCi0JeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0
IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uLi4uICIg
PiY2OyB9Ci0JaWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uICRfcGtn
X21pbl92ZXJzaW9uOyB0aGVuCi0JCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIgPiY2OyB9Ci0JZWxzZQotCQl7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQot
JGFzX2VjaG8gIm5vIiA+JjY7IH0KLQkJUEtHX0NPTkZJRz0iIgotCWZpCisgIE9DQU1MTUtMSUI9
IiRhY19jdl9wcm9nX09DQU1MTUtMSUIiCiBmaQogCi1wa2dfZmFpbGVkPW5vCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBnbGliIiA+JjUKLSRh
c19lY2hvX24gImNoZWNraW5nIGZvciBnbGliLi4uICIgPiY2OyB9CiAKLWlmIHRlc3QgLW4gIiRn
bGliX0NGTEFHUyI7IHRoZW4KLSAgICBwa2dfY3ZfZ2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIK
LSBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgotICAgIGlmIHRlc3QgLW4gIiRQS0df
Q09ORklHIiAmJiBcCi0gICAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IFwkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9
ID4mNQotICAoJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIikg
Mj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRo
ZW4KLSAgcGtnX2N2X2dsaWJfQ0ZMQUdTPWAkUEtHX0NPTkZJRyAtLWNmbGFncyAiZ2xpYi0yLjAi
IDI+L2Rldi9udWxsYAorICAjIGNoZWNraW5nIGZvciBvY2FtbGRvYworICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHth
Y190b29sX3ByZWZpeH1vY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGRvYzsgYWNfd29yZD0kMgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBwa2dfZmFpbGVkPXllcworICBpZiB0
ZXN0IC1uICIkT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERP
QyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MRE9D
PSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCiBmaQot
IGVsc2UKLSAgICBwa2dfZmFpbGVkPXVudHJpZWQKIGZpCi1pZiB0ZXN0IC1uICIkZ2xpYl9MSUJT
IjsgdGhlbgotICAgIHBrZ19jdl9nbGliX0xJQlM9IiRnbGliX0xJQlMiCi0gZWxpZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyI7IHRoZW4KLSAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAot
ICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05G
SUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGliLTIuMFwiIjsgfSA+JjUKLSAgKCRQS0df
Q09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIpIDI+JjUKLSAgYWNfc3Rh
dHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh
Y19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuCi0gIHBrZ19jdl9n
bGliX0xJQlM9YCRQS0dfQ09ORklHIC0tbGlicyAiZ2xpYi0yLjAiIDI+L2Rldi9udWxsYAorT0NB
TUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KIGVsc2UKLSAgcGtnX2ZhaWxl
ZD15ZXMKLWZpCi0gZWxzZQotICAgIHBrZ19mYWlsZWQ9dW50cmllZAorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KIGZpCiAKIAorZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MRE9DIjsg
dGhlbgorICBhY19jdF9PQ0FNTERPQz0kT0NBTUxET0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJvY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
CitzZXQgZHVtbXkgb2NhbWxkb2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9n
X2FjX2N0X09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICBh
Y19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSIkYWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0ib2NhbWxkb2Mi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCiAKLWlmIHRlc3QgJHBrZ19mYWlsZWQgPSB5ZXM7IHRoZW4K
LSAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorZmkKK2ZpCithY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQwor
aWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCiAKLWlmICRQS0dfQ09ORklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAwLjIw
OyB0aGVuCi0gICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZD15ZXMKKyAgaWYgdGVz
dCAieCRhY19jdF9PQ0FNTERPQyIgPSB4OyB0aGVuCisgICAgT0NBTUxET0M9Im5vIgorICBlbHNl
CisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIk
YXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3Qg
dHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MRE9D
PSRhY19jdF9PQ0FNTERPQworICBmaQogZWxzZQotICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19z
dXBwb3J0ZWQ9bm8KKyAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgogZmkKLSAgICAg
ICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCi0JICAg
ICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQt
ZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKLSAgICAgICAgZWxzZQotCSAgICAgICAgZ2xpYl9QS0df
RVJST1JTPWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCi0gICAg
ICAgIGZpCi0JIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVy
ZSBpdCBiZWxvbmdzCi0JZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIgPiY1Ci0KLQlhc19mbl9lcnJv
ciAkPyAiUGFja2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3ZXJlIG5vdCBtZXQ6Ci0KLSRn
bGliX1BLR19FUlJPUlMKLQotQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEgg
ZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91Ci1pbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24t
c3RhbmRhcmQgcHJlZml4LgotCi1BbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJv
bm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCi1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBu
ZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KLVNlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3Ig
bW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKLWVsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJp
ZWQ7IHRoZW4KLSAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCXsgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFz
X2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3Ig
JD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9s
ZC4gIE1ha2Ugc3VyZSBpdAotaXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBl
bnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAotcGF0aCB0byBwa2ctY29uZmlnLgogCi1B
bHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJf
Q0ZMQUdTCi1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZp
Zy4KLVNlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLgogCi1UbyBn
ZXQgcGtnLWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5mcmVlZGVza3RvcC5vcmcvPi4K
LVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAj
IGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CiBlbHNlCi0JZ2xpYl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUwot
CWdsaWJfTElCUz0kcGtnX2N2X2dsaWJfTElCUwotICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4m
NjsgfQotCi1maQotCi0jIENoZWNrIGxpYnJhcnkgcGF0aAotaWYgdGVzdCAiXCR7ZXhlY19wcmVm
aXh9L2xpYiIgPSAiJGxpYmRpciI7IHRoZW4gOgotICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0g
Ik5PTkUiICYmIHRlc3QgIiRwcmVmaXgiICE9ICJOT05FIjsgdGhlbiA6Ci0gIGV4ZWNfcHJlZml4
PSRwcmVmaXgKKyAgaWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIGFjX2N2X3Byb2df
T0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2Rp
ciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl
bnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisg
ICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiCisg
ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25l
CitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi0gICAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJO
T05FIjsgdGhlbiA6Ci0gIGV4ZWNfcHJlZml4PSRhY19kZWZhdWx0X3ByZWZpeAogZmkKLSAgICBp
ZiB0ZXN0IC1kICIke2V4ZWNfcHJlZml4fS9saWI2NCI7IHRoZW4gOgotCi0gICAgICAgIExJQl9Q
QVRIPSJsaWI2NCIKLQorT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19PQ0FNTEJVSUxECitpZiB0ZXN0
IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJVSUxEIiA+JjUKKyRhc19lY2hvICIkT0NBTUxCVUlM
RCIgPiY2OyB9CiBlbHNlCi0KLSAgICAgICAgTElCX1BBVEg9ImxpYiIKLQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KIGZpCiAKLWVsc2UKLQotICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBs
ZW5ndGggIiRleGVjX3ByZWZpeCIgKyAxYH0iCiAKIGZpCi0KLQotIyBDaGVja3MgZm9yIGxpYnJh
cmllcy4KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJiemxpYi5oIiAi
YWNfY3ZfaGVhZGVyX2J6bGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngk
YWNfY3ZfaGVhZGVyX2J6bGliX2giID0geCIieWVzOyB0aGVuIDoKLQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQloyX2J6RGVjb21wcmVzc0lu
aXQgaW4gLWxiejIiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEJaMl9iekRlY29tcHJl
c3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloy
X2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxCVUlMRD0kT0NBTUxCVUlMRAor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGJ6MiAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgot
ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg
R0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp
bGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNo
YXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBCWjJf
YnpEZWNvbXByZXNzSW5pdCAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfYnoyX0JaMl9iekRl
Y29tcHJlc3NJbml0PXllcworICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxCVUlMRCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSIkYWNfY3RfT0NBTUxCVUlMRCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCi0gIGFjX2N2X2xpYl9iejJfQloyX2J6
RGVjb21wcmVzc0luaXQ9bm8KK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0ib2NhbWxidWlsZCIKKyAg
ICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUK
K0lGUz0kYXNfc2F2ZV9JRlMKKwogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1M
SUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJ
bml0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIg
PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID0g
eCIieWVzOyB0aGVuIDoKLSAgemxpYj0iJHpsaWIgLURIQVZFX0JaTElCIC1sYnoyIgorYWNfY3Rf
T0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxECitpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxCVUlMRCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEJVSUxEIiA+JjUKKyRhc19lY2hvICIkYWNfY3Rf
T0NBTUxCVUlMRCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAot
CisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxCVUlMRCIgPSB4OyB0aGVuCisgICAgT0NBTUxCVUlM
RD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVk
IGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJO
SU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp
eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2Fj
CisgICAgT0NBTUxCVUlMRD0kYWNfY3RfT0NBTUxCVUlMRAorICBmaQorZWxzZQorICBPQ0FNTEJV
SUxEPSIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIgogZmkKIAogCi1hY19mbl9jX2NoZWNrX2hlYWRl
cl9tb25ncmVsICIkTElORU5PIiAibHptYS5oIiAiYWNfY3ZfaGVhZGVyX2x6bWFfaCIgIiRhY19p
bmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHptYV9oIiA9IHgiInll
czsgdGhlbiA6CisgICAgaWYgdGVzdCAieCRPQ0FNTEMiID0gInhubyI7IHRoZW4gOgogCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem1hX3N0
cmVhbV9kZWNvZGVyIGluIC1sbHptYSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgbHpt
YV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKLUxJQlM9Ii1sbHptYSAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCisgICAgICAgIGlmIHRlc3QgIngk
ZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKIAotLyogT3ZlcnJpZGUgYW55IEdD
QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNh
dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4g
YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0j
aWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBsem1hX3N0cmVhbV9k
ZWNvZGVyICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4gbHptYV9zdHJlYW1fZGVjb2RlciAo
KTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPXllcwot
ZWxzZQotICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5vCi1maQotcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKyAg
ICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJPY2FtbCB0b29scyBlbmFibGVkLCBidXQgdW5hYmxl
IHRvIGZpbmQgT2NhbWwiICIkTElORU5PIiA1CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNv
ZGVyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIg
PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXIiID0g
eCIieWVzOyB0aGVuIDoKLSAgemxpYj0iJHpsaWIgLURIQVZFX0xaTUEgLWxsem1hIgorICAgICAg
ICBvY2FtbHRvb2xzPSJuIgorCiBmaQogCitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJiYXNoIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSBiYXNoOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAk
QkFTSCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CQVNIPSIkQkFTSCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICop
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFj
X2N2X3BhdGhfQkFTSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JB
U0g9Im5vIgorICA7OworZXNhYworZmkKK0JBU0g9JGFjX2N2X3BhdGhfQkFTSAoraWYgdGVzdCAt
biAiJEJBU0giOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQkFTSCIgPiY1CiskYXNfZWNobyAiJEJBU0giID4mNjsgfQorZWxzZQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor
JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem9fbHpvMXhfaCIg
PSB4IiJ5ZXM7IHRoZW4gOgoraWYgdGVzdCB4IiR7QkFTSH0iID09IHgibm8iCit0aGVuCisgICAg
YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2gi
ICIkTElORU5PIiA1CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMiIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgbHpvMXhfZGVjb21wcmVzcyBpbiAtbGx6bzIuLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcytzZXR9IiA9IHNldDsg
dGhlbiA6CithY19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRD
QyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRD
QyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRl
c3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJf
Z251Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhv
dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhv
dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yLi4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0
aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAt
ZCAiJENQUCI7IHRoZW4KKyAgQ1BQPQorZmkKK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlm
IHRlc3QgIiR7YWNfY3ZfcHJvZ19DUFArc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1M
SUJTPSItbGx6bzIgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorICAgICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQIG5lZWRzIHRvIGJlIGV4
cGFuZGVkCisgICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRpb25hbC1jcHAi
ICIvbGliL2NwcCIKKyAgICBkbworICAgICAgYWNfcHJlcHJvY19vaz1mYWxzZQorZm9yIGFjX2Nf
cHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRlciBmaWxlIHRo
YXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0aCBhIGZyZXNo
IGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQu
aD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+IGV4aXN0cyBl
dmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1
bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMgbm90IGp1c3Qg
dGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgor
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29u
ZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRv
IGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl
IHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBw
cm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRl
cm4gIkMiCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBp
bmNsdWRlIDxhc3NlcnQuaD4KICNlbmRpZgotY2hhciBsem8xeF9kZWNvbXByZXNzICgpOwotaW50
Ci1tYWluICgpCi17Ci1yZXR1cm4gbHpvMXhfZGVjb21wcmVzcyAoKTsKLSAgOwotICByZXR1cm4g
MDsKLX0KKwkJICAgICBTeW50YXggZXJyb3IKIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPXllcwor
aWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisKIGVsc2UKLSAgYWNfY3ZfbGli
X2x6bzJfbHpvMXhfZGVjb21wcmVzcz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf
ZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNv
bXByZXNzIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIg
PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID0geCIi
eWVzOyB0aGVuIDoKLSAgemxpYj0iJHpsaWIgLURIQVZFX0xaTzFYIC1sbHpvMiIKKyAgIyBCcm9r
ZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgorY29udGludWUKIGZpCitybSAtZiBjb25mdGVzdC5l
cnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CiAKLQorICAjIE9LLCB3b3JrcyBvbiBzYW5l
IGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAjIGNhbiBi
ZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9uZXhpc3Rl
bnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisgICMg
QnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQorICAjIFBh
c3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhawogZmkKK3JtIC1mIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKIAorZG9uZQorIyBCZWNhdXNlIG9m
IGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQu
CitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNf
cHJlcHJvY19vazsgdGhlbiA6CisgIGJyZWFrCitmaQogCisgICAgZG9uZQorICAgIGFjX2N2X3By
b2dfQ1BQPSRDUFAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGlvX3NldHVwIGluIC1sYWlvLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9h
aW9faW9fc2V0dXArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAogZWxzZQotICBhY19jaGVja19saWJfc2F2
ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGFpbyAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENQUCIgPiY1CiskYXNf
ZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19wcmVwcm9j
X3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21l
cyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3Mt
Y29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBf
X1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24g
ZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUg
Y29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0aHJvdWdo
IGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIK
KyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUg
PGFzc2VydC5oPgogI2VuZGlmCi1jaGFyIGlvX3NldHVwICgpOwotaW50Ci1tYWluICgpCi17Ci1y
ZXR1cm4gaW9fc2V0dXAgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19CisJCSAgICAgU3ludGF4IGVy
cm9yCiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf
Y3ZfbGliX2Fpb19pb19zZXR1cD15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRo
ZW4gOgorCiBlbHNlCi0gIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9bm8KKyAgIyBCcm9rZW46IGZh
aWxzIG9uIHZhbGlkIGlucHV0LgorY29udGludWUKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3Qu
JGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworcm0gLWYgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNhbmUgY2Fz
ZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2FuIGJlIGRl
dGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlzdGVudC5o
PgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAgIyBCcm9r
ZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMgUGFzc2Vz
IGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFrCiBmaQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVw
IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9Ci1pZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKLSAgc3lzdGVtX2Fp
bz0ieSIKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKwor
ZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5n
IGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisKIGVsc2UKLSAgc3lzdGVtX2Fp
bz0ibiIKKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9y
OiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNf
cHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFp
bHMgc2FuaXR5IGNoZWNrCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJ
TkVOTyIgNSA7IH0KIGZpCiAKK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNf
Y29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1Jwor
YWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERG
TEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3Zf
Y19jb21waWxlcl9nbnUKKwogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIE1ENSBpbiAtbGNyeXB0by4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJf
Y3J5cHRvX01ENStzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVz
IGFuZCAtZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMg
bG9uZyBsaW5lcyBhbmQgLWUuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9HUkVQ
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxjcnlwdG8gICRMSUJTIgot
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZk
ZWZzLmguICAqLworICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9HUkVQX2Zv
dW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3Ig
ZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX3Byb2cgaW4gZ3JlcCBnZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfR1JFUD0iJGFz
X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfR1JF
UCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sg
Zm9yIEdOVSBhY19wYXRoX0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBD
aGVjayBmb3IgR05VICRhY19wYXRoX0dSRVAKK2Nhc2UgYCIkYWNfcGF0aF9HUkVQIiAtLXZlcnNp
b24gMj4mMWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiIGFj
X3BhdGhfR1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIz
NDU2Nzg5ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0
LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAi
ICJjb25mdGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAk
YXNfZWNobyAnR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9HUkVQIiAtZSAn
R1JFUCQnIC1lICctKGNhbm5vdCBtYXRjaCktJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5v
dXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRl
c3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3Vu
dCArIDEgJiYgYWNfY291bnQ9JGFzX3ZhbAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2Fj
X3BhdGhfR1JFUF9tYXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0
IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9HUkVQ
PSIkYWNfcGF0aF9HUkVQIgorICAgICAgYWNfcGF0aF9HUkVQX21heD0kYWNfY291bnQKKyAgICBm
aQorICAgICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gK
KyAgICB0ZXN0ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25m
dGVzdC5pbiBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKIAot
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Ci0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgot
Y2hhciBNRDUgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBNRDUgKCk7Ci0gIDsKLSAgcmV0
dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
LSAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCisgICAgICAkYWNfcGF0aF9HUkVQX2ZvdW5kICYm
IGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworICBp
ZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9HUkVQIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJu
byBhY2NlcHRhYmxlIGdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1Iv
dXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQogZWxzZQotICBhY19jdl9saWJfY3J5cHRv
X01ENT1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
XAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVj
a19saWJfc2F2ZV9MSUJTCisgIGFjX2N2X3BhdGhfR1JFUD0kR1JFUAogZmkKLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2NyeXB0b19N
RDUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY2OyB9Ci1pZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9MSUJDUllQVE8gMQotX0FDRU9GCi0KLSAgTElC
Uz0iLWxjcnlwdG8gJExJQlMiCiAKLWVsc2UKLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBm
aW5kIGxpYmNyeXB0byIgIiRMSU5FTk8iIDUKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKIAoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZXh0MmZz
X29wZW4yIGluIC1sZXh0MmZzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBleHQyZnNf
b3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2V4dDJm
c19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9F
R1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sZXh0MmZzICAkTElC
UyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyAgaWYgZWNobyBhIHwgJEdSRVAgLUUgJyhhfGIpJyA+L2Rldi9udWxs
IDI+JjEKKyAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCisgICBlbHNlCisgICAg
IGlmIHRlc3QgLXogIiRFR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9FR1JFUF9mb3VuZD1mYWxzZQor
ICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJP
R05BTUUtTElTVAorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19w
cm9nIGluIGVncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs
ZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfRUdSRVAiICYmICRhc190ZXN0
X3ggIiRhY19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3Bh
dGhfRUdSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBDaGVjayBmb3IgR05V
ICRhY19wYXRoX0VHUkVQCitjYXNlIGAiJGFjX3BhdGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBp
bgorKkdOVSopCisgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VH
UkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19uIDAxMjM0NTY3ODkg
PiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29uZnRlc3QuaW4iICJj
b25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0
ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgorICAgICRhc19lY2hv
ICdFR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcg
PCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAg
IGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJl
YWsKKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAg
ICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgorICAg
ICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0
ZXIgb25lCisgICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIKKyAgICAgIGFj
X3BhdGhfRUdSRVBfbWF4PSRhY19jb3VudAorICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMg
YXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAx
MCAmJiBicmVhaworICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25m
dGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNhYwogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBf
X2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGV4dDJmc19vcGVuMiAoKTsKLWlu
dAotbWFpbiAoKQotewotcmV0dXJuIGV4dDJmc19vcGVuMiAoKTsKLSAgOwotICByZXR1cm4gMDsK
LX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19j
dl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj15ZXMKKyAgICAgICRhY19wYXRoX0VHUkVQX2ZvdW5k
ICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwor
ICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JFUCI7IHRoZW4KKyAgICBhc19mbl9lcnJvciAk
PyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFS
QVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1CisgIGZpCiBlbHNlCi0gIGFjX2N2X2xpYl9l
eHQyZnNfZXh0MmZzX29wZW4yPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQK
LUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKyAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAK
IGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2V4
dDJmc19leHQyZnNfb3BlbjIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMiIgPSB4IiJ5ZXM7IHRoZW4gOgotICBsaWJleHQyZnM9InkiCi1lbHNlCi0gIGxp
YmV4dDJmcz0ibiIKKworICAgZmkKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9wYXRoX0VHUkVQIiA+JjY7IH0KKyBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCiAKIAoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9t
ZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
Z2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHth
Y19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQU5T
SSBDIGhlYWRlciBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgQU5TSSBDIGhl
YWRlciBmaWxlcy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYytzZXR9
IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sZ2NyeXB0ICAkTElCUyIKLWNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lu
Y2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHN0cmluZy5o
PgorI2luY2x1ZGUgPGZsb2F0Lmg+CiAKLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv
dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg
bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBh
cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNw
bHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsKIGlu
dAogbWFpbiAoKQogewotcmV0dXJuIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CisKICAgOwogICBy
ZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9eWVzCi1lbHNlCi0gIGFj
X2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2Ny
eXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID0geCIieWVzOyB0aGVuIDoKLSAgbGliZ2NyeXB0PSJ5Igor
aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJf
c3RkYz15ZXMKIGVsc2UKLSAgbGliZ2NyeXB0PSJuIgorICBhY19jdl9oZWFkZXJfc3RkYz1ubwog
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu
JGFjX2V4dAogCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIFN1
bk9TIDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFOU0ku
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdHJpbmcuaD4KIAorX0FDRU9GCitpZiAoZXZhbCAi
JGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAibWVtY2hyIiA+L2Rl
di9udWxsIDI+JjE7IHRoZW4gOgogCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgcHRocmVhZCBmbGFnIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBwdGhyZWFkIGZsYWcuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YXhfY3ZfcHRo
cmVhZF9mbGFncytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CiBlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitmaQorcm0gLWYgY29uZnRlc3QqCiAK
LSAgICAgICAgYXhfY3ZfcHRocmVhZF9mbGFncz0tcHRocmVhZAotCi0gICAgUFRIUkVBRF9DRkxB
R1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgotICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0
aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9MSUJTPSIiCi0KLQotICAgIHNhdmVkX0NGTEFHUz0i
JENGTEFHUyIKLQotICAgIHNhdmVkX0xERkxBR1M9IiRMREZMQUdTIgotCi0gICAgc2F2ZWRfTElC
Uz0iJExJQlMiCi0KLQotICAgIENGTEFHUz0iJENGTEFHUyAkUFRIUkVBRF9DRkxBR1MiCi0KLSAg
ICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgotCi0gICAgTElCUz0iJExJQlMg
JFBUSFJFQURfTElCUyIKK2ZpCiAKLSAgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAoraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4K
KyAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3QgZGVjbGFyZSBmcmVlLCBjb250cmFyeSB0
byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAv
KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLSNpbmNsdWRlIDxwdGhyZWFkLmg+Ci1pbnQgbWFpbih2
b2lkKSB7Ci0gIHB0aHJlYWRfYXRmb3JrKDAsMCwwKTsKLSAgcHRocmVhZF9jcmVhdGUoMCwwLDAs
MCk7Ci19CisjaW5jbHVkZSA8c3RkbGliLmg+CiAKIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGlu
ayAiJExJTkVOTyI7IHRoZW4gOgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIp
IDI+JjUgfAorICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CiAKIGVsc2UK
LSAgYXhfY3ZfcHRocmVhZF9mbGFncz1mYWlsZWQKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KIGZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotCi0gICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZM
QUdTIgotCi0gICAgTERGTEFHUz0iJHNhdmVkX0xERkxBR1MiCi0KLSAgICBMSUJTPSIkc2F2ZWRf
TElCUyIKLQorcm0gLWYgY29uZnRlc3QqCiAKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQotJGFzX2Vj
aG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7IH0KLSAgICBpZiB0ZXN0ICJ4JGF4X2N2X3B0
aHJlYWRfZmxhZ3MiID0geGZhaWxlZDsgdGhlbgotICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0
aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKLSAgICBmaQotCi0gICAgUFRIUkVBRF9D
RkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgotICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2
X3B0aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9MSUJTPSIiCi0KLQogCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbG9ja19nZXR0aW1lIGlu
IC1scnQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsb2NrX2dldHRpbWUgaW4gLWxy
dC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZStzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitpZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4vY2MgaW4gSXJpeC00LjAuNSBn
ZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2kuCisgIGlmIHRlc3Qg
IiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgogZWxzZQotICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHJ0ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgorI2luY2x1ZGUgPGN0eXBlLmg+Cisj
aW5jbHVkZSA8c3RkbGliLmg+CisjaWYgKCgnICcgJiAweDBGRikgPT0gMHgwMjApCisjIGRlZmlu
ZSBJU0xPV0VSKGMpICgnYScgPD0gKGMpICYmIChjKSA8PSAneicpCisjIGRlZmluZSBUT1VQUEVS
KGMpIChJU0xPV0VSKGMpID8gJ0EnICsgKChjKSAtICdhJykgOiAoYykpCisjZWxzZQorIyBkZWZp
bmUgSVNMT1dFUihjKSBcCisJCSAgICgoJ2EnIDw9IChjKSAmJiAoYykgPD0gJ2knKSBcCisJCSAg
ICAgfHwgKCdqJyA8PSAoYykgJiYgKGMpIDw9ICdyJykgXAorCQkgICAgIHx8ICgncycgPD0gKGMp
ICYmIChjKSA8PSAneicpKQorIyBkZWZpbmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICgoYykg
fCAweDQwKSA6IChjKSkKICNlbmRpZgotY2hhciBjbG9ja19nZXR0aW1lICgpOworCisjZGVmaW5l
IFhPUihlLCBmKSAoKChlKSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQogaW50CiBtYWluICgp
CiB7Ci1yZXR1cm4gY2xvY2tfZ2V0dGltZSAoKTsKLSAgOworICBpbnQgaTsKKyAgZm9yIChpID0g
MDsgaSA8IDI1NjsgaSsrKQorICAgIGlmIChYT1IgKGlzbG93ZXIgKGkpLCBJU0xPV0VSIChpKSkK
Kwl8fCB0b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkKKyAgICAgIHJldHVybiAyOwogICByZXR1
cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgot
ICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZT15ZXMKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJ
TkVOTyI7IHRoZW4gOgorCiBlbHNlCi0gIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lPW5vCisg
IGFjX2N2X2hlYWRlcl9zdGRjPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQK
LUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29u
ZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKIGZpCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9ydF9jbG9j
a19nZXR0aW1lIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID4m
NjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSIgPSB4IiJ5ZXM7IHRo
ZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCUlQgMQot
X0FDRU9GCi0KLSAgTElCUz0iLWxydCAkTElCUyIKIAogZmkKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUK
KyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfaGVh
ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2OyB9Ci1pZiB0ZXN0
ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRM
SUJTCi1MSUJTPSItbHlhamwgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFzX2VjaG8gIiNkZWZpbmUg
U1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBf
X2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIHlhamxfYWxsb2MgKCk7Ci1pbnQK
LW1haW4gKCkKLXsKLXJldHVybiB5YWpsX2FsbG9jICgpOwotICA7Ci0gIHJldHVybiAwOwotfQot
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xp
Yl95YWpsX3lhamxfYWxsb2M9eWVzCi1lbHNlCi0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9
bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAg
ICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGli
X3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2
X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfeWFqbF95
YWpsX2FsbG9jIiA9IHgiInllczsgdGhlbiA6CisKKyMgT24gSVJJWCA1LjMsIHN5cy90eXBlcyBh
bmQgaW50dHlwZXMuaCBhcmUgY29uZmxpY3RpbmcuCitmb3IgYWNfaGVhZGVyIGluIHN5cy90eXBl
cy5oIHN5cy9zdGF0Lmggc3RkbGliLmggc3RyaW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKKwkJ
ICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0ZC5oCitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFz
X2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hl
Y2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIg
IiRhY19pbmNsdWRlc19kZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRl
ciJcIiA9IHgieWVzIjsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZp
bmUgSEFWRV9MSUJZQUpMIDEKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwg
JGFzX3RyX2NwcGAgMQogX0FDRU9GCiAKLSAgTElCUz0iLWx5YWpsICRMSUJTIgorZmkKKworZG9u
ZQorCisKK2lmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhlbiA6CisKKyAgICBpZiBl
Y2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CisKKyAgICAgICAgUFlUSE9OUEFU
SD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCiAKK2VsaWYg
dGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgorICBQWVRIT049InB5dGhvbiIKIGVsc2UKLSAgYXNf
Zm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwiICIkTElORU5PIiA1CisgIGFzX2ZuX2Vy
cm9yICQ/ICJQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRlIHBhdGgiICIk
TElORU5PIiA1CiBmaQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHoiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGRlZmxhdGVDb3B5IGluIC1sei4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9s
aWJfel9kZWZsYXRlQ29weStzZXR9IiA9IHNldDsgdGhlbiA6CisgICAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zf
cGF0aF9QWVRIT05QQVRIK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWx6
ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/
OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf
UFlUSE9OUEFUSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKIAotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIK
LSNlbmRpZgotY2hhciBkZWZsYXRlQ29weSAoKTsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGRl
ZmxhdGVDb3B5ICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PXllcwor
ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBB
VEg9Im5vIgorICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFU
SAoraWYgdGVzdCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAi
JFBZVEhPTlBBVEgiID4mNjsgfQogZWxzZQotICBhY19jdl9saWJfel9kZWZsYXRlQ29weT1ubwor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworCisKK2lmIHRlc3QgeCIke1BZVEhPTlBB
VEh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCAk
UFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQorZmkKKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRob24g
dmVyc2lvbiA+PSAyLjMgIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24gdmVy
c2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgc3lzLmV4
aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgyLCAzKSIpKSdgCitpZiB0ZXN0ICIkPyIgIT0g
IjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLVYgMj4mMWAKKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiJHB5dGhvbl92ZXJzaW9uIGlz
IHRvbyBvbGQsIG1pbmltdW0gcmVxdWlyZWQgdmVyc2lvbiBpcyAyLjMiICIkTElORU5PIiA1Citl
bHNlCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KIGZpCi17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+
JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4mNjsgfQotaWYgdGVzdCAi
eCRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCWiAxCi1fQUNFT0YKIAotICBMSUJTPSIt
bHogJExJQlMiCithY19weXRob25fdmVyc2lvbj1gJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGls
cy5zeXNjb25maWc7IFwKKyAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdf
dmFyKCJWRVJTSU9OIiknYAorYWNfcHJldmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCitDUFBGTEFH
Uz0iJENGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAg
ICBwcmludCAiLUkiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiSU5DTFVE
RVBZIiknYCIKK0NQUEZMQUdTPSIkQ1BQRkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRp
bHMuc3lzY29uZmlnOyBcCisgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmln
X3ZhcigiQ0ZMQUdTIiknYCIKK2FjX3ByZXZpb3VzX2xkZmxhZ3M9JExERkxBR1MKK0xERkxBR1M9
IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAorICAg
IHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIkxJQlMiKSdgIgorTERG
TEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBc
CisgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiU1lTTElCUyIp
J2AiCitMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNj
b25maWc7IFwKKyAgICBwcmludCAiLUwiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9u
X2xpYihwbGF0X3NwZWNpZmljPTEsXAorICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidg
IgorTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29u
ZmlnOyBcCisgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElO
S0ZPUlNIQVJFRCIpJ2AiCitMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRp
c3R1dGlscy5zeXNjb25maWc7IFwKKyAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9j
b25maWdfdmFyKCJMREZMQUdTIiknYCIKKworYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi
JExJTkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVyX1B5dGhvbl9oIiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9QeXRob25faCIgPSB4IiJ5ZXM7IHRo
ZW4gOgogCiBlbHNlCi0gIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB6bGliIiAiJExJ
TkVOTyIgNQorICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgUHl0aG9uIGRldmVsb3Bt
ZW50IGhlYWRlcnMiICIkTElORU5PIiA1CiBmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udi4uLiAi
ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9
IHNldDsgdGhlbiA6CisKK2FzX2FjX0xpYj1gJGFzX2VjaG8gImFjX2N2X2xpYl9weXRob24kYWNf
cHl0aG9uX3ZlcnNpb24nJ19QeUFyZ19QYXJzZVR1cGxlIiB8ICRhc190cl9zaGAKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNl
VHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24u
Li4gIiA+JjY7IH0KK2lmIGV2YWwgInRlc3QgXCJcJHskYXNfYWNfTGliK3NldH1cIiIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQogICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGljb252ICAkTElCUyIKK0xJQlM9Ii1scHl0aG9u
JGFjX3B5dGhvbl92ZXJzaW9uICAkTElCUyIKIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIApAQCAtNzQ3MCwxODQ2ICs1
MTY4LDExNzQgQEAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAog
I2lmZGVmIF9fY3BsdXNwbHVzCiBleHRlcm4gIkMiCiAjZW5kaWYKLWNoYXIgbGliaWNvbnZfb3Bl
biAoKTsKK2NoYXIgUHlBcmdfUGFyc2VUdXBsZSAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJu
IGxpYmljb252X29wZW4gKCk7CityZXR1cm4gUHlBcmdfUGFyc2VUdXBsZSAoKTsKICAgOwogICBy
ZXR1cm4gMDsKIH0KIF9BQ0VPRgogaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj15ZXMKKyAgZXZhbCAiJGFzX2FjX0xp
Yj15ZXMiCiBlbHNlCi0gIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPW5vCisgIGV2YWwg
IiRhc19hY19MaWI9bm8iCiBmaQogcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBcCiAgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKIExJQlM9
JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjUK
LSRhc19lY2hvICIkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNjsgfQotaWYgdGVz
dCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgotICBs
aWJpY29udj0ieSIKLWVsc2UKLSAgbGliaWNvbnY9Im4iCi1maQotCitldmFsIGFjX3Jlcz1cJCRh
c19hY19MaWIKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQoraWYgZXZh
bCB0ZXN0IFwieFwkIiRhc19hY19MaWIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV9MSUJweXRob24kYWNfcHl0
aG9uX3ZlcnNpb24iIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCiAKKyAgTElCUz0iLWxweXRob24k
YWNfcHl0aG9uX3ZlcnNpb24gJExJQlMiCiAKLSMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCi0j
IFRoZSBVbHRyaXggNC4yIG1pcHMgYnVpbHRpbiBhbGxvY2EgZGVjbGFyZWQgYnkgYWxsb2NhLmgg
b25seSB3b3JrcwotIyBmb3IgY29uc3RhbnQgYXJndW1lbnRzLiAgVXNlbGVzcyEKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxs
b2NhLmgiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmguLi4g
IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfd29ya2luZ19hbGxvY2FfaCtzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LSNpbmNsdWRlIDxhbGxvY2EuaD4KLWludAotbWFpbiAoKQotewotY2hhciAqcCA9IChjaGFyICop
IGFsbG9jYSAoMiAqIHNpemVvZiAoaW50KSk7Ci0JCQkgIGlmIChwKSByZXR1cm4gMDsKLSAgOwot
ICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgotICBhY19jdl93b3JraW5nX2FsbG9jYV9oPXllcwogZWxzZQotICBhY19jdl93b3JraW5n
X2FsbG9jYV9oPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgYXNfZm5f
ZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgcHl0aG9uIGRldmVsb3BtZW50IGxp
YnJhcnkiICIkTElORU5PIiA1CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKLSRhc19lY2hvICIk
YWNfY3Zfd29ya2luZ19hbGxvY2FfaCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl93b3JraW5nX2Fs
bG9jYV9oID0geWVzOyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIg
Pj5jb25mZGVmcy5oCitDUFBGTEFHUz0kYWNfcHJldmlvdXNfY3BwZmxhZ3MKK0xETEZBR1M9JGFj
X3ByZXZpb3VzX2xkZmxhZ3MKKwogCiBmaQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhbGxvY2EiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGFsbG9jYS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX2FsbG9jYV93
b3JrcytzZXR9IiA9IHNldDsgdGhlbiA6CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInhn
ZXR0ZXh0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSB4Z2V0dGV4dDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfWEdFVFRFWFQr
c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u
ZmRlZnMuaC4gICovCi0jaWZkZWYgX19HTlVDX18KLSMgZGVmaW5lIGFsbG9jYSBfX2J1aWx0aW5f
YWxsb2NhCi0jZWxzZQotIyBpZmRlZiBfTVNDX1ZFUgotIyAgaW5jbHVkZSA8bWFsbG9jLmg+Ci0j
ICBkZWZpbmUgYWxsb2NhIF9hbGxvY2EKLSMgZWxzZQotIyAgaWZkZWYgSEFWRV9BTExPQ0FfSAot
IyAgIGluY2x1ZGUgPGFsbG9jYS5oPgotIyAgZWxzZQotIyAgIGlmZGVmIF9BSVgKLSAjcHJhZ21h
IGFsbG9jYQotIyAgIGVsc2UKLSMgICAgaWZuZGVmIGFsbG9jYSAvKiBwcmVkZWZpbmVkIGJ5IEhQ
IGNjICtPbGliY2FsbHMgKi8KLWNoYXIgKmFsbG9jYSAoKTsKLSMgICAgZW5kaWYKLSMgICBlbmRp
ZgotIyAgZW5kaWYKLSMgZW5kaWYKLSNlbmRpZgorICBjYXNlICRYR0VUVEVYVCBpbgorICBbXFwv
XSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9YR0VUVEVYVD0iJFhHRVRURVhUIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9YR0VUVEVYVD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKIAotaW50Ci1tYWluICgpCi17Ci1jaGFyICpwID0gKGNoYXIgKikgYWxsb2NhICgxKTsK
LQkJCQkgICAgaWYgKHApIHJldHVybiAwOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1p
ZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfYWxsb2Nh
X3dvcmtzPXllcwotZWxzZQotICBhY19jdl9mdW5jX2FsbG9jYV93b3Jrcz1ubworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIgJiYgYWNfY3ZfcGF0aF9YR0VUVEVYVD0ibm8iCisgIDs7
Citlc2FjCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBc
Ci0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK1hHRVRURVhUPSRhY19j
dl9wYXRoX1hHRVRURVhUCitpZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQor
JGFzX2VjaG8gIiRYR0VUVEVYVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX2FsbG9j
YV93b3JrcyIgPiY2OyB9CiAKLWlmIHRlc3QgJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzID0geWVz
OyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBIDEiID4+Y29uZmRlZnMuaAor
aWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/
ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElO
RU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBhczg2OyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9BUzg2K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkQVM4NiBpbgorICBbXFwvXSog
fCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9BUzg2PSIkQVM4NiIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQVM4Nj0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9BUzg2IiAmJiBhY19jdl9wYXRoX0FTODY9Im5vIgorICA7OworZXNh
YworZmkKK0FTODY9JGFjX2N2X3BhdGhfQVM4NgoraWYgdGVzdCAtbiAiJEFTODYiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQVM4NiIg
PiY1CiskYXNfZWNobyAiJEFTODYiID4mNjsgfQogZWxzZQotICAjIFRoZSBTVlIzIGxpYlBXIGFu
ZCBTVlI0IGxpYnVjYiBib3RoIGNvbnRhaW4gaW5jb21wYXRpYmxlIGZ1bmN0aW9ucwotIyB0aGF0
IGNhdXNlIHRyb3VibGUuICBTb21lIHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2Nh
IG9yCi0jIGNvbnRhaW4gYSBidWdneSB2ZXJzaW9uLiAgSWYgeW91IHN0aWxsIHdhbnQgdG8gdXNl
IHRoZWlyIGFsbG9jYSwKLSMgdXNlIGFyIHRvIGV4dHJhY3QgYWxsb2NhLm8gZnJvbSB0aGVtIGlu
c3RlYWQgb2YgY29tcGlsaW5nIGFsbG9jYS5jLgotCi1BTExPQ0E9XCR7TElCT0JKRElSfWFsbG9j
YS4kYWNfb2JqZXh0Ci0KLSRhc19lY2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMu
aAorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENy
YXkgaG9va3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBcYGFsbG9jYS5jJyBu
ZWVkcyBDcmF5IGhvb2tzLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X29zX2NyYXkrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCB4IiR7QVM4Nn0iID09IHgibm8iCit0aGVuCisgICAg
YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGFzODYsIHBsZWFzZSBpbnN0YWxsIGFzODYi
ICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJsZDg2Iiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBsZDg2OyBhY193
b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmIGRl
ZmluZWQgQ1JBWSAmJiAhIGRlZmluZWQgQ1JBWTIKLXdlYmVjcmF5Ci0jZWxzZQotd2Vub3RiZWNy
YXkKLSNlbmRpZgorICBjYXNlICRMRDg2IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19j
dl9wYXRoX0xEODY9IiRMRDg2IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRo
IGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9MRDg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCi1fQUNFT0YKLWlmIChldmFsICIkYWNfY3Bw
IGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKLSAgJEVHUkVQICJ3ZWJlY3JheSIgPi9kZXYvbnVs
bCAyPiYxOyB0aGVuIDoKLSAgYWNfY3Zfb3NfY3JheT15ZXMKLWVsc2UKLSAgYWNfY3Zfb3NfY3Jh
eT1ubworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9MRDg2IiAmJiBhY19jdl9wYXRoX0xEODY9Im5v
IgorICA7OworZXNhYwogZmkKLXJtIC1mIGNvbmZ0ZXN0KgotCitMRDg2PSRhY19jdl9wYXRoX0xE
ODYKK2lmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJExEODYiID4mNQorJGFzX2VjaG8gIiRMRDg2IiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9vc19jcmF5IiA+JjUKLSRhc19l
Y2hvICIkYWNfY3Zfb3NfY3JheSIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9vc19jcmF5ID0geWVz
OyB0aGVuCi0gIGZvciBhY19mdW5jIGluIF9nZXRiNjcgR0VUQjY3IGdldGI2NzsgZG8KLSAgICBh
c19hY192YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKLWFj
X2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKLWlmIGV2
YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLQotY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBDUkFZX1NUQUNLU0VHX0VORCAkYWNfZnVuYwotX0FD
RU9GCiAKLSAgICBicmVhawotZmkKIAotICBkb25lCitpZiB0ZXN0IHgiJHtMRDg2fSIgPT0geCJu
byIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNl
IGluc3RhbGwgbGQ4NiIgIiRMSU5FTk8iIDUKIGZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYSIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBzdGFjayBkaXJlY3Rpb24gZm9yIEMgYWxsb2NhLi4u
ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uK3NldH0iID0gc2V0
OyB0aGVuIDoKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmNjIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBiY2M7IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9wYXRoX0JDQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0g
eWVzOyB0aGVuIDoKLSAgYWNfY3ZfY19zdGFja19kaXJlY3Rpb249MAotZWxzZQotICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4g
ICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAotaW50Ci1maW5kX3N0YWNrX2RpcmVjdGlvbiAoKQot
ewotICBzdGF0aWMgY2hhciAqYWRkciA9IDA7Ci0gIGF1dG8gY2hhciBkdW1teTsKLSAgaWYgKGFk
ZHIgPT0gMCkKLSAgICB7Ci0gICAgICBhZGRyID0gJmR1bW15OwotICAgICAgcmV0dXJuIGZpbmRf
c3RhY2tfZGlyZWN0aW9uICgpOwotICAgIH0KLSAgZWxzZQotICAgIHJldHVybiAoJmR1bW15ID4g
YWRkcikgPyAxIDogLTE7Ci19CisgIGNhc2UgJEJDQyBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9CQ0M9IiRCQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0JDQz0iJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotaW50Ci1tYWluICgpCi17Ci0gIHJl
dHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKSA8IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0xCi1l
bHNlCi0gIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPS0xCi1maQotcm0gLWYgY29yZSAqLmNvcmUg
Y29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9CQ0MiICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKKyAgOzsKK2VzYWMK
IGZpCi0KK0JDQz0kYWNfY3ZfcGF0aF9CQ0MKK2lmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQkNDIiA+JjUK
KyRhc19lY2hvICIkQkNDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBm
aQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Nfc3RhY2tfZGlyZWN0
aW9uIiA+JjY7IH0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgU1RBQ0tfRElS
RUNUSU9OICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbgotX0FDRU9GCiAKIAoraWYgdGVzdCB4IiR7
QkNDfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQg
YmNjLCBwbGVhc2UgaW5zdGFsbCBiY2MiICIkTElORU5PIiA1CiBmaQorIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJpYXNsIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBpYXNsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9J
QVNMK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgY2FzZSAkSUFTTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9J
QVNMPSIkSUFTTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGgu
CisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3BhdGhfSUFTTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIK
KyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRv
bmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotZm9yIGFjX2hlYWRlciBpbiAgXAotICAgICAgICAgICAg
ICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFs
bG9jLmggXAotICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0
ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKLSAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lz
L2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCi0gICAgICAgICAg
ICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJt
aW9zLmggXAotICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAor
ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5vIgorICA7
OworZXNhYworZmkKK0lBU0w9JGFjX2N2X3BhdGhfSUFTTAoraWYgdGVzdCAtbiAiJElBU0wiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
SUFTTCIgPiY1CiskYXNfZWNobyAiJElBU0wiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCiAKLWRvIDoKLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVh
ZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhl
biA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZF
XyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQotX0FDRU9GCiAKK2lmIHRlc3QgeCIke0lBU0x9
IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNs
LCBwbGVhc2UgaW5zdGFsbCBpYXNsIiAiJExJTkVOTyIgNQogZmkKIAotZG9uZQotCithY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidXVpZC91dWlkLmgiICJhY19jdl9oZWFk
ZXJfdXVpZF91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3Zf
aGVhZGVyX3V1aWRfdXVpZF9oIiA9IHgiInllczsgdGhlbiA6CiAKLSMgQ2hlY2tzIGZvciB0eXBl
ZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0
aGF0IGNvbmZvcm1zIHRvIEM5OSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3RkYm9v
bC5oIHRoYXQgY29uZm9ybXMgdG8gQzk5Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2hl
YWRlcl9zdGRib29sX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIgaW4gLWx1dWlk
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZC4uLiAi
ID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfdXVpZF91dWlkX2NsZWFyK3NldH0iID0gc2V0
OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCitMSUJTPSItbHV1aWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwogCi0jaW5jbHVkZSA8
c3RkYm9vbC5oPgotI2lmbmRlZiBib29sCi0gImVycm9yOiBib29sIGlzIG5vdCBkZWZpbmVkIgot
I2VuZGlmCi0jaWZuZGVmIGZhbHNlCi0gImVycm9yOiBmYWxzZSBpcyBub3QgZGVmaW5lZCIKLSNl
bmRpZgotI2lmIGZhbHNlCi0gImVycm9yOiBmYWxzZSBpcyBub3QgMCIKLSNlbmRpZgotI2lmbmRl
ZiB0cnVlCi0gImVycm9yOiB0cnVlIGlzIG5vdCBkZWZpbmVkIgotI2VuZGlmCi0jaWYgdHJ1ZSAh
PSAxCi0gImVycm9yOiB0cnVlIGlzIG5vdCAxIgotI2VuZGlmCi0jaWZuZGVmIF9fYm9vbF90cnVl
X2ZhbHNlX2FyZV9kZWZpbmVkCi0gImVycm9yOiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5l
ZCBpcyBub3QgZGVmaW5lZCIKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl
IHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg
dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu
dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitl
eHRlcm4gIkMiCiAjZW5kaWYKLQotCXN0cnVjdCBzIHsgX0Jvb2wgczogMTsgX0Jvb2wgdDsgfSBz
OwotCi0JY2hhciBhW3RydWUgPT0gMSA/IDEgOiAtMV07Ci0JY2hhciBiW2ZhbHNlID09IDAgPyAx
IDogLTFdOwotCWNoYXIgY1tfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCA9PSAxID8gMSA6
IC0xXTsKLQljaGFyIGRbKGJvb2wpIDAuNSA9PSB0cnVlID8gMSA6IC0xXTsKLQlib29sIGUgPSAm
czsKLQljaGFyIGZbKF9Cb29sKSAwLjAgPT0gZmFsc2UgPyAxIDogLTFdOwotCWNoYXIgZ1t0cnVl
XTsKLQljaGFyIGhbc2l6ZW9mIChfQm9vbCldOwotCWNoYXIgaVtzaXplb2Ygcy50XTsKLQllbnVt
IHsgaiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAyNTYg
fTsKLQkvKiBUaGUgZm9sbG93aW5nIGZhaWxzIGZvcgotCSAgIEhQIGFDKysvQU5TSSBDIEIzOTEw
QiBBLjA1LjU1IFtEZWMgMDQgMjAwM10uICovCi0JX0Jvb2wgblttXTsKLQljaGFyIG9bc2l6ZW9m
IG4gPT0gbSAqIHNpemVvZiBuWzBdID8gMSA6IC0xXTsKLQljaGFyIHBbLTEgLSAoX0Jvb2wpIDAg
PCAwICYmIC0xIC0gKGJvb2wpIDAgPCAwID8gMSA6IC0xXTsKLSMJaWYgZGVmaW5lZCBfX3hsY19f
IHx8IGRlZmluZWQgX19HTlVDX18KLQkgLyogQ2F0Y2ggYSBidWcgaW4gSUJNIEFJWCB4bGMgY29t
cGlsZXIgdmVyc2lvbiA2LjAuMC4wCi0JICAgIHJlcG9ydGVkIGJ5IEphbWVzIExlbWxleSBvbiAy
MDA1LTEwLTA1OyBzZWUKLQkgICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2J1
Zy1jb3JldXRpbHMvMjAwNS0xMC9tc2cwMDA4Ni5odG1sCi0JICAgIFRoaXMgdGVzdCBpcyBub3Qg
cXVpdGUgcmlnaHQsIHNpbmNlIHhsYyBpcyBhbGxvd2VkIHRvCi0JICAgIHJlamVjdCB0aGlzIHBy
b2dyYW0sIGFzIHRoZSBpbml0aWFsaXplciBmb3IgeGxjYnVnIGlzCi0JICAgIG5vdCBvbmUgb2Yg
dGhlIGZvcm1zIHRoYXQgQyByZXF1aXJlcyBzdXBwb3J0IGZvci4KLQkgICAgSG93ZXZlciwgZG9p
bmcgdGhlIHRlc3QgcmlnaHQgd291bGQgcmVxdWlyZSBhIHJ1bnRpbWUKLQkgICAgdGVzdCwgYW5k
IHRoYXQgd291bGQgbWFrZSBjcm9zcy1jb21waWxhdGlvbiBoYXJkZXIuCi0JICAgIExldCB1cyBo
b3BlIHRoYXQgSUJNIGZpeGVzIHRoZSB4bGMgYnVnLCBhbmQgYWxzbyBhZGRzCi0JICAgIHN1cHBv
cnQgZm9yIHRoaXMga2luZCBvZiBjb25zdGFudCBleHByZXNzaW9uLiAgSW4gdGhlCi0JICAgIG1l
YW50aW1lLCB0aGlzIHRlc3Qgd2lsbCByZWplY3QgeGxjLCB3aGljaCBpcyBPSywgc2luY2UKLQkg
ICAgb3VyIHN0ZGJvb2wuaCBzdWJzdGl0dXRlIHNob3VsZCBzdWZmaWNlLiAgV2UgYWxzbyB0ZXN0
Ci0JICAgIHRoaXMgd2l0aCBHQ0MsIHdoZXJlIGl0IHNob3VsZCB3b3JrLCB0byBkZXRlY3QgbW9y
ZQotCSAgICBxdWlja2x5IHdoZXRoZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRlc3QgaW4gdGhl
Ci0JICAgIGZ1dHVyZS4gICovCi0JIGNoYXIgZGlnc1tdID0gIjAxMjM0NTY3ODkiOwotCSBpbnQg
eGxjYnVnID0gMSAvICgmKGRpZ3MgKyA1KVstMiArIChib29sKSAxXSA9PSAmZGlnc1s0XSA/IDEg
OiAtMSk7Ci0jCWVuZGlmCi0JLyogQ2F0Y2ggYSBidWcgaW4gYW4gSFAtVVggQyBjb21waWxlci4g
IFNlZQotCSAgIGh0dHA6Ly9nY2MuZ251Lm9yZy9tbC9nY2MtcGF0Y2hlcy8yMDAzLTEyL21zZzAy
MzAzLmh0bWwKLQkgICBodHRwOi8vbGlzdHMuZ251Lm9yZy9hcmNoaXZlL2h0bWwvYnVnLWNvcmV1
dGlscy8yMDA1LTExL21zZzAwMTYxLmh0bWwKLQkgKi8KLQlfQm9vbCBxID0gdHJ1ZTsKLQlfQm9v
bCAqcHEgPSAmcTsKLQorY2hhciB1dWlkX2NsZWFyICgpOwogaW50CiBtYWluICgpCiB7Ci0KLQkq
cHEgfD0gcTsKLQkqcHEgfD0gISBxOwotCS8qIFJlZmVyIHRvIGV2ZXJ5IGRlY2xhcmVkIHZhbHVl
LCB0byBhdm9pZCBjb21waWxlciBvcHRpbWl6YXRpb25zLiAgKi8KLQlyZXR1cm4gKCFhICsgIWIg
KyAhYyArICFkICsgIWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCi0JCSsg
IW0gKyAhbiArICFvICsgIXAgKyAhcSArICFwcSk7Ci0KK3JldHVybiB1dWlkX2NsZWFyICgpOwog
ICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2hlYWRlcl9zdGRib29sX2g9eWVzCi1lbHNlCi0gIGFjX2N2
X2hlYWRlcl9zdGRib29sX2g9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRib29sX2giID4mNQot
JGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjY7IH0KLWFjX2ZuX2NfY2hlY2tf
dHlwZSAiJExJTkVOTyIgIl9Cb29sIiAiYWNfY3ZfdHlwZV9fQm9vbCIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX19Cb29sIiA9IHgiInllczsgdGhlbiA6Ci0K
LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9fQk9PTCAxCi1fQUNFT0YK
LQotCi1maQotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oID0geWVzOyB0aGVuCi0K
LSRhc19lY2hvICIjZGVmaW5lIEhBVkVfU1REQk9PTF9IIDEiID4+Y29uZmRlZnMuaAotCi1maQot
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1
aWRfdCBpbiBzeXMvdHlwZXMuaCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgdWlkX3Qg
aW4gc3lzL3R5cGVzLmguLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfdHlwZV91aWRfdCtz
ZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0g
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KLQotX0FDRU9GCi1pZiAoZXZhbCAi
JGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAidWlkX3QiID4vZGV2
L251bGwgMj4mMTsgdGhlbiA6Ci0gIGFjX2N2X3R5cGVfdWlkX3Q9eWVzCi1lbHNlCi0gIGFjX2N2
X3R5cGVfdWlkX3Q9bm8KLWZpCi1ybSAtZiBjb25mdGVzdCoKLQotZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIgPiY1
Ci0kYXNfZWNobyAiJGFjX2N2X3R5cGVfdWlkX3QiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfdHlw
ZV91aWRfdCA9IG5vOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIHVpZF90IGludCIgPj5jb25m
ZGVmcy5oCi0KLQotJGFzX2VjaG8gIiNkZWZpbmUgZ2lkX3QgaW50IiA+PmNvbmZkZWZzLmgKLQot
ZmkKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgaW5saW5lIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7
IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19pbmxpbmUrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jdl9jX2lubGluZT1ubwotZm9yIGFj
X2t3IGluIGlubGluZSBfX2lubGluZV9fIF9faW5saW5lOyBkbwotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZu
ZGVmIF9fY3BsdXNwbHVzCi10eXBlZGVmIGludCBmb29fdDsKLXN0YXRpYyAkYWNfa3cgZm9vX3Qg
c3RhdGljX2ZvbyAoKSB7cmV0dXJuIDA7IH0KLSRhY19rdyBmb29fdCBmb28gKCkge3JldHVybiAw
OyB9Ci0jZW5kaWYKLQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X2NfaW5saW5lPSRhY19rdworaWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPXllcworZWxzZQorICBh
Y19jdl9saWJfdXVpZF91dWlkX2NsZWFyPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gIHRlc3QgIiRhY19jdl9jX2lu
bGluZSIgIT0gbm8gJiYgYnJlYWsKLWRvbmUKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KK2lmIHRl
c3QgIngkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJ1
dWlkPSJ5IgogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfY19pbmxpbmUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2
OyB9CiAKLWNhc2UgJGFjX2N2X2NfaW5saW5lIGluCi0gIGlubGluZSB8IHllcykgOzsKLSAgKikK
LSAgICBjYXNlICRhY19jdl9jX2lubGluZSBpbgotICAgICAgbm8pIGFjX3ZhbD07OwotICAgICAg
KikgYWNfdmFsPSRhY19jdl9jX2lubGluZTs7Ci0gICAgZXNhYwotICAgIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKLSNpZm5kZWYgX19jcGx1c3BsdXMKLSNkZWZpbmUgaW5saW5lICRhY192YWwK
LSNlbmRpZgotX0FDRU9GCi0gICAgOzsKLWVzYWMKIAotYWNfZm5fY19maW5kX2ludFhfdCAiJExJ
TkVOTyIgIjE2IiAiYWNfY3ZfY19pbnQxNl90IgotY2FzZSAkYWNfY3ZfY19pbnQxNl90IGluICMo
Ci0gIG5vfHllcykgOzsgIygKLSAgKikKK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgaW50MTZfdCAkYWNfY3ZfY19pbnQxNl90Ci1fQUNFT0YKLTs7Ci1lc2FjCiAKLWFj
X2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKLWNhc2Ug
JGFjX2N2X2NfaW50MzJfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCi0gICopCithY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRf
aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF9o
IiA9IHgiInllczsgdGhlbiA6CisgIGxpYnV1aWQ9InkiCitmaQogCi1jYXQgPj5jb25mZGVmcy5o
IDw8X0FDRU9GCi0jZGVmaW5lIGludDMyX3QgJGFjX2N2X2NfaW50MzJfdAotX0FDRU9GCi07Owot
ZXNhYwogCi1hY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0
X3QiCi1jYXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQor
aWYgdGVzdCAiJGxpYnV1aWQiICE9ICJ5IjsgdGhlbiA6CiAKLWNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKLSNkZWZpbmUgaW50NjRfdCAkYWNfY3ZfY19pbnQ2NF90Ci1fQUNFT0YKLTs7Ci1lc2Fj
CisgICAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBsaWJyYXJ5IiAi
JExJTkVOTyIgNQogCi1hY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIgImFjX2N2X2Nf
aW50OF90IgotY2FzZSAkYWNfY3ZfY19pbnQ4X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAq
KQorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBpbnQ4X3QgJGFjX2N2
X2NfaW50OF90Ci1fQUNFT0YKLTs7Ci1lc2FjCiAKLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVO
TyIgIm1vZGVfdCIgImFjX2N2X3R5cGVfbW9kZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1p
ZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfbW9kZV90IiA9IHgiInllczsgdGhlbiA6CithY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJfY3Vy
c2VzX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2N1
cnNlc19oIiA9IHgiInllczsgdGhlbiA6CiAKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxjdXJzZXMuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2N1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKK0xJQlM9Ii1sY3Vyc2VzICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgotI2RlZmluZSBtb2RlX3QgaW50CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBf
X2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGNsZWFyICgpOworaW50CittYWlu
ICgpCit7CityZXR1cm4gY2xlYXIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CiBfQUNFT0YKLQor
aWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfY3Vyc2Vz
X2NsZWFyPXllcworZWxzZQorICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPW5vCiBmaQotCi1hY19m
bl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2X3R5cGVfb2ZmX3QiICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZfdCIgPSB4IiJ5ZXM7
IHRoZW4gOgotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
KyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tf
bGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2xpYl9jdXJzZXNfY2xlYXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfY3Vyc2VzX2Ns
ZWFyIiA9IHgiInllczsgdGhlbiA6CisgIGN1cnNlcz0ieSIKIGVsc2UKLQotY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBvZmZfdCBsb25nIGludAotX0FDRU9GCi0KKyAgY3Vyc2Vz
PSJuIgogZmkKIAotYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAicGlkX3QiICJhY19jdl90
eXBlX3BpZF90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
cGlkX3QiID0geCIieWVzOyB0aGVuIDoKIAogZWxzZQorICBjdXJzZXM9Im4iCitmaQogCi1jYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHBpZF90IGludAotX0FDRU9GCiAKLWZpCith
Y19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3Zf
aGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl9oZWFkZXJfbmN1cnNlc19oIiA9IHgiInllczsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdv
cmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQu
Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19yZXN0cmljdCtzZXR9IiA9IHNldDsgdGhl
biA6CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBj
bGVhciBpbiAtbG5jdXJzZXMuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX25jdXJz
ZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgogZWxzZQotICBhY19jdl9jX3Jlc3RyaWN0PW5vCi0gICAjIFRoZSBvcmRlciBoZXJlIGNhdGVy
cyB0byB0aGUgZmFjdCB0aGF0IEMrKyBkb2VzIG5vdCByZXF1aXJlIHJlc3RyaWN0LgotICAgZm9y
IGFjX2t3IGluIF9fcmVzdHJpY3QgX19yZXN0cmljdF9fIF9SZXN0cmljdCByZXN0cmljdDsgZG8K
LSAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19j
aGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbG5jdXJzZXMgICRMSUJTIgorY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwotdHlwZWRlZiBpbnQgKiBpbnRfcHRyOwotCWludCBmb28gKGludF9wdHIgJGFjX2t3IGlw
KSB7Ci0JcmV0dXJuIGlwWzBdOwotICAgICAgIH0KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRl
cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGlu
dCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRo
ZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYg
X19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBjbGVhciAoKTsKIGludAogbWFp
biAoKQogewotaW50IHNbMV07Ci0JaW50ICogJGFjX2t3IHQgPSBzOwotCXRbMF0gPSAwOwotCXJl
dHVybiBmb28odCkKK3JldHVybiBjbGVhciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VP
RgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX3Jl
c3RyaWN0PSRhY19rdworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9saWJfbmN1cnNlc19jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xl
YXI9bm8KIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKLSAgICAgdGVzdCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJy
ZWFrCi0gICBkb25lCi0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19j
aGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3Jlc3RyaWN0IiA+JjUKLSRhc19lY2hvICIkYWNfY3Zf
Y19yZXN0cmljdCIgPiY2OyB9Ci0KLSBjYXNlICRhY19jdl9jX3Jlc3RyaWN0IGluCi0gICByZXN0
cmljdCkgOzsKLSAgIG5vKSAkYXNfZWNobyAiI2RlZmluZSByZXN0cmljdCAvKiovIiA+PmNvbmZk
ZWZzLmgKLSA7OwotICAgKikgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgcmVz
dHJpY3QgJGFjX2N2X2NfcmVzdHJpY3QKLV9BQ0VPRgotIDs7Ci0gZXNhYwotCi1hY19mbl9jX2No
ZWNrX3R5cGUgIiRMSU5FTk8iICJzaXplX3QiICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNs
dWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3NpemVfdCIgPSB4IiJ5ZXM7IHRo
ZW4gOgotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX25jdXJz
ZXNfY2xlYXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPSB4
IiJ5ZXM7IHRoZW4gOgorICBuY3Vyc2VzPSJ5IgogZWxzZQotCi1jYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCi0jZGVmaW5lIHNpemVfdCB1bnNpZ25lZCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9
Im4iCiBmaQogCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzc2l6ZV90IiAiYWNfY3Zf
dHlwZV9zc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5
cGVfc3NpemVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgogCiBlbHNlCi0KLWNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKLSNkZWZpbmUgc3NpemVfdCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9Im4iCiBm
aQogCi1hY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxr
c2l6ZSIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXpl
IiA9IHgiInllczsgdGhlbiA6CiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUg
SEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFIDEKLV9BQ0VPRgoraWYgdGVzdCAiJGN1cnNlcyIg
PSAibiIgJiYgdGVzdCAiJG5jdXJzZXMiID0gIm4iOyB0aGVuIDoKIAorICAgIGFzX2ZuX2Vycm9y
ICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRhYmxlIGN1cnNlcyBsaWJyYXJ5IiAiJExJTkVOTyIg
NQogCiBmaQorIyBQcmVmZXIgbmN1cnNlcyBvdmVyIGN1cnNlcyBpZiBib3RoIGFyZSBwcmVzZW50
CitpZiB0ZXN0ICIkbmN1cnNlcyIgPSAieSI7IHRoZW4gOgogCi1hY19mbl9jX2NoZWNrX21lbWJl
ciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVj
dF9zdGF0X3N0X2Jsb2NrcyIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tzIiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1Mg
MQotX0FDRU9GCisgICAgQ1VSU0VTX0xJQlM9Ii1sbmN1cnNlcyIKIAorJGFzX2VjaG8gIiNkZWZp
bmUgSU5DTFVERV9DVVJTRVNfSCA8bmN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCiAKLSRhc19lY2hv
ICIjZGVmaW5lIEhBVkVfU1RfQkxPQ0tTIDEiID4+Y29uZmRlZnMuaAogCiBlbHNlCi0gIGNhc2Ug
IiAkTElCT0JKUyAiIGluCi0gICoiIGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiApIDs7Ci0gICop
IExJQk9CSlM9IiRMSUJPQkpTIGZpbGVibG9ja3MuJGFjX29iamV4dCIKLSA7OwotZXNhYwotCi1m
aQotCiAKLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0YXQiICJzdF9y
ZGV2IiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiID0geCIi
eWVzOyB0aGVuIDoKKyAgICBDVVJTRVNfTElCUz0iLWxjdXJzZXMiCiAKLWNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9SREVWIDEKLV9BQ0VPRgor
JGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNfSCA8Y3Vyc2VzLmg+IiA+PmNvbmZkZWZz
LmgKIAogCiBmaQogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3Zf
Y191aW50MTZfdCIKLWNhc2UgJGFjX2N2X2NfdWludDE2X3QgaW4gIygKLSAgbm98eWVzKSA7OyAj
KAotICAqKQogCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgdWludDE2X3Qg
JGFjX2N2X2NfdWludDE2X3QKLV9BQ0VPRgotOzsKLSAgZXNhYwogCi1hY19mbl9jX2ZpbmRfdWlu
dFhfdCAiJExJTkVOTyIgIjMyIiAiYWNfY3ZfY191aW50MzJfdCIKLWNhc2UgJGFjX2N2X2NfdWlu
dDMyX3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQogCi0kYXNfZWNobyAiI2RlZmluZSBf
VUlOVDMyX1QgMSIgPj5jb25mZGVmcy5oCiAKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgot
I2RlZmluZSB1aW50MzJfdCAkYWNfY3ZfY191aW50MzJfdAotX0FDRU9GCi07OwotICBlc2FjCiAK
LWFjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX3VpbnQ2NF90Igot
Y2FzZSAkYWNfY3ZfY191aW50NjRfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCitpZiB0ZXN0ICJ4
JGFjX2N2X2Vudl9QS0dfQ09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCisJaWYgdGVzdCAtbiAi
JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7
YWNfdG9vbF9wcmVmaXh9cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QS0dfQ09ORklHK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUEtHX0NPTkZJ
RyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtH
X0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisg
IDs7CiAgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3BhdGhfUEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ2NF9UIDEi
ID4+Y29uZmRlZnMuaAotCisgIDs7Citlc2FjCitmaQorUEtHX0NPTkZJRz0kYWNfY3ZfcGF0aF9Q
S0dfQ09ORklHCitpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQS0dfQ09ORklHIiA+JjUKKyRh
c19lY2hvICIkUEtHX0NPTkZJRyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50NjRfdCAkYWNf
Y3ZfY191aW50NjRfdAotX0FDRU9GCi07OwotICBlc2FjCiAKLWFjX2ZuX2NfZmluZF91aW50WF90
ICIkTElORU5PIiAiOCIgImFjX2N2X2NfdWludDhfdCIKLWNhc2UgJGFjX2N2X2NfdWludDhfdCBp
biAjKAotICBub3x5ZXMpIDs7ICMoCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NP
TkZJRyI7IHRoZW4KKyAgYWNfcHRfUEtHX0NPTkZJRz0kUEtHX0NPTkZJRworICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgInBrZy1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRhY19wdF9QS0dfQ09ORklH
IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9
IiRhY19wdF9QS0dfQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRo
IGEgcGF0aC4KKyAgOzsKICAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCi0kYXNfZWNobyAiI2Rl
ZmluZSBfVUlOVDhfVCAxIiA+PmNvbmZkZWZzLmgKLQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCi0jZGVmaW5lIHVpbnQ4X3QgJGFjX2N2X2NfdWludDhfdAotX0FDRU9GCi07OwotICBlc2Fj
Ci0KLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVf
cHRyZGlmZl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
cHRyZGlmZl90IiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgSEFWRV9QVFJESUZGX1QgMQotX0FDRU9GCi0KLQorICA7OworZXNhYworZmkKK2Fj
X3B0X1BLR19DT05GSUc9JGFjX2N2X3BhdGhfYWNfcHRfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAi
JGFjX3B0X1BLR19DT05GSUciOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcHRfUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJGFj
X3B0X1BLR19DT05GSUciID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZp
CiAKLQotIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1Ci0k
YXNfZWNob19uICJjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9saWJfZXJyb3JfYXRfbGluZStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxlcnJv
ci5oPgotaW50Ci1tYWluICgpCi17Ci1lcnJvcl9hdF9saW5lICgwLCAwLCAiIiwgMCwgImFuIGVy
cm9yIG9jY3VycmVkIik7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVz
CisgIGlmIHRlc3QgIngkYWNfcHRfUEtHX0NPTkZJRyIgPSB4OyB0aGVuCisgICAgUEtHX0NPTkZJ
Rz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBp
bgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYwor
ICAgIFBLR19DT05GSUc9JGFjX3B0X1BLR19DT05GSUcKKyAgZmkKIGVsc2UKLSAgYWNfY3ZfbGli
X2Vycm9yX2F0X2xpbmU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorICBQ
S0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgogZmkKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUi
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9Ci1pZiB0ZXN0
ICRhY19jdl9saWJfZXJyb3JfYXRfbGluZSA9IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAi
IGluCi0gICoiIGVycm9yLiRhY19vYmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JK
UyBlcnJvci4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCiAKIGZpCi0KLWZvciBhY19oZWFkZXIgaW4g
dmZvcmsuaAotZG8gOgotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAi
dmZvcmsuaCIgImFjX2N2X2hlYWRlcl92Zm9ya19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1p
ZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl92Zm9ya19oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9WRk9SS19IIDEKLV9BQ0VPRgotCitp
ZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKwlfcGtnX21pbl92ZXJzaW9uPTAuOS4wCisJ
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29u
ZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJz
aW9uLi4uICIgPiY2OyB9CisJaWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJz
aW9uICRfcGtnX21pbl92ZXJzaW9uOyB0aGVuCisJCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisJ
ZWxzZQorCQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKwkJUEtHX0NPTkZJRz0iIgorCWZpCiBmaQog
Ci1kb25lCi0KLWZvciBhY19mdW5jIGluIGZvcmsgdmZvcmsKLWRvIDoKLSAgYXNfYWNfdmFyPWAk
YXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNr
X2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4
XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEK
LV9BQ0VPRgotCi1maQotZG9uZQorcGtnX2ZhaWxlZD1ubworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2xpYiIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgZ2xpYi4uLiAiID4mNjsgfQogCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9y
ayIgPSB4eWVzOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yayIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm
b3Igd29ya2luZyBmb3JrLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfZm9ya193
b3JrcytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1l
bHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3Zf
ZnVuY19mb3JrX3dvcmtzPWNyb3NzCitpZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0aGVuCisg
ICAgcGtnX2N2X2dsaWJfQ0ZMQUdTPSIkZ2xpYl9DRkxBR1MiCisgZWxpZiB0ZXN0IC1uICIkUEtH
X0NPTkZJRyI7IHRoZW4KKyAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIHsg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1l
eGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGliLTIuMFwiIjsgfSA+JjUKKyAgKCRQS0dfQ09ORklH
IC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/
CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0
dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuCisgIHBrZ19jdl9nbGliX0NG
TEFHUz1gJFBLR19DT05GSUcgLS1jZmxhZ3MgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAKIGVsc2UK
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotCi0J
ICAvKiBCeSBSdWVkaWdlciBLdWhsbWFubi4gKi8KLQkgIHJldHVybiBmb3JrICgpIDwgMDsKLQot
ICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8i
OyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPXllcworICBwa2dfZmFpbGVkPXllcwor
ZmkKKyBlbHNlCisgICAgcGtnX2ZhaWxlZD11bnRyaWVkCitmaQoraWYgdGVzdCAtbiAiJGdsaWJf
TElCUyI7IHRoZW4KKyAgICBwa2dfY3ZfZ2xpYl9MSUJTPSIkZ2xpYl9MSUJTIgorIGVsaWYgdGVz
dCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisgICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYm
IFwKKyAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0df
Q09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1CisgICgk
UEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1CisgIGFj
X3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8g
PSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgorICBwa2df
Y3ZfZ2xpYl9MSUJTPWAkUEtHX0NPTkZJRyAtLWxpYnMgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAK
IGVsc2UKLSAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCisgIHBrZ19mYWlsZWQ9eWVzCiBmaQot
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKIGZpCiAKLWZpCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNf
Zm9ya193b3JrcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9
CiAKKworaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHllczsgdGhlbgorICAgCXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8i
ID4mNjsgfQorCitpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4y
MDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCiBlbHNlCi0g
IGFjX2N2X2Z1bmNfZm9ya193b3Jrcz0kYWNfY3ZfZnVuY19mb3JrCisgICAgICAgIF9wa2dfc2hv
cnRfZXJyb3JzX3N1cHBvcnRlZD1ubwogZmkKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dv
cmtzIiA9IHhjcm9zczsgdGhlbgotICBjYXNlICRob3N0IGluCi0gICAgKi0qLWFtaWdhb3MqIHwg
Ki0qLW1zZG9zZGpncHAqKQotICAgICAgIyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZl
IG9ubHkgYSBkdW1teSBmb3JrKCkgc3R1YgotICAgICAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5v
Ci0gICAgICA7OwotICAgICopCi0gICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCi0gICAg
ICA7OwotICBlc2FjCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
V0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX2Zvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9m
IGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3Vs
dCAkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxh
dGlvbiIgPiYyO30KLWZpCi1hY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3Jr
Ci1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfdmZvcmsiID0geHllczsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHZmb3Jr
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHZmb3JrLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfdmZvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgot
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9Y3Jvc3MKLWVs
c2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k
IGNvbmZkZWZzLmguICAqLwotLyogVGhhbmtzIHRvIFBhdWwgRWdnZXJ0IGZvciB0aGlzIHRlc3Qu
ICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSNpbmNsdWRlIDxzeXMvd2FpdC5oPgotI2lmZGVm
IEhBVkVfVkZPUktfSAotIyBpbmNsdWRlIDx2Zm9yay5oPgotI2VuZGlmCi0vKiBPbiBzb21lIHNw
YXJjIHN5c3RlbXMsIGNoYW5nZXMgYnkgdGhlIGNoaWxkIHRvIGxvY2FsIGFuZCBpbmNvbWluZwot
ICAgYXJndW1lbnQgcmVnaXN0ZXJzIGFyZSBwcm9wYWdhdGVkIGJhY2sgdG8gdGhlIHBhcmVudC4g
IFRoZSBjb21waWxlcgotICAgaXMgdG9sZCBhYm91dCB0aGlzIHdpdGggI2luY2x1ZGUgPHZmb3Jr
Lmg+LCBidXQgc29tZSBjb21waWxlcnMKLSAgIChlLmcuIGdjYyAtTykgZG9uJ3QgZ3JvayA8dmZv
cmsuaD4uICBUZXN0IGZvciB0aGlzIGJ5IHVzaW5nIGEKLSAgIHN0YXRpYyB2YXJpYWJsZSB3aG9z
ZSBhZGRyZXNzIGlzIHB1dCBpbnRvIGEgcmVnaXN0ZXIgdGhhdCBpcwotICAgY2xvYmJlcmVkIGJ5
IHRoZSB2Zm9yay4gICovCi1zdGF0aWMgdm9pZAotI2lmZGVmIF9fY3BsdXNwbHVzCi1zcGFyY19h
ZGRyZXNzX3Rlc3QgKGludCBhcmcpCi0jIGVsc2UKLXNwYXJjX2FkZHJlc3NfdGVzdCAoYXJnKSBp
bnQgYXJnOwotI2VuZGlmCi17Ci0gIHN0YXRpYyBwaWRfdCBjaGlsZDsKLSAgaWYgKCFjaGlsZCkg
ewotICAgIGNoaWxkID0gdmZvcmsgKCk7Ci0gICAgaWYgKGNoaWxkIDwgMCkgewotICAgICAgcGVy
cm9yICgidmZvcmsiKTsKLSAgICAgIF9leGl0KDIpOwotICAgIH0KLSAgICBpZiAoIWNoaWxkKSB7
Ci0gICAgICBhcmcgPSBnZXRwaWQoKTsKLSAgICAgIHdyaXRlKC0xLCAiIiwgMCk7Ci0gICAgICBf
ZXhpdCAoYXJnKTsKLSAgICB9Ci0gIH0KLX0KKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9l
cnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQ
S0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAK
KyAgICAgICAgZWxzZQorCSAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXBy
aW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCisgICAgICAgIGZpCisJIyBQdXQgdGhlIG5hc3R5
IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdzCisJZWNobyAiJGds
aWJfUEtHX0VSUk9SUyIgPiY1CiAKLWludAotbWFpbiAoKQotewotICBwaWRfdCBwYXJlbnQgPSBn
ZXRwaWQgKCk7Ci0gIHBpZF90IGNoaWxkOwotCi0gIHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7Ci0K
LSAgY2hpbGQgPSB2Zm9yayAoKTsKLQotICBpZiAoY2hpbGQgPT0gMCkgewotICAgIC8qIEhlcmUg
aXMgYW5vdGhlciB0ZXN0IGZvciBzcGFyYyB2Zm9yayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMK
LSAgICAgICB0ZXN0IHVzZXMgbG90cyBvZiBsb2NhbCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1h
bnkgbG9jYWwKLSAgICAgICB2YXJpYWJsZXMgYXMgbWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBp
bmNsdWRpbmcgY29tcGlsZXIKLSAgICAgICB0ZW1wb3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91
Z2ggZm9yIGdjYyAxLjQwLjMgb24gYSBTb2xhcmlzCi0gICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3
ZSB1c2UgOCB0byBiZSBzYWZlLiAgQSBidWdneSBjb21waWxlciBzaG91bGQKLSAgICAgICByZXVz
ZSB0aGUgcmVnaXN0ZXIgb2YgcGFyZW50IGZvciBvbmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywK
LSAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRoYXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJl
IHVzZWQgYW55IG1vcmUKLSAgICAgICBpbiB0aGlzIHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhl
IGxvY2FsIHZhcmlhYmxlIHdpbGwgdGh1cwotICAgICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFy
ZW50IHByb2Nlc3MuICAqLwotICAgIHBpZF90Ci0gICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0
cGlkKCksIHAyID0gZ2V0cGlkKCksIHAzID0gZ2V0cGlkKCksCi0gICAgICBwNCA9IGdldHBpZCgp
LCBwNSA9IGdldHBpZCgpLCBwNiA9IGdldHBpZCgpLCBwNyA9IGdldHBpZCgpOwotICAgIC8qIENv
bnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1p
Z2h0Ci0gICAgICAgdXNlIHRoZSBzYW1lIGhhcmR3YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2Nh
bCB2YXJpYWJsZXMuICAqLwotICAgIGlmIChwICE9IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8
fCBwICE9IHA0Ci0JfHwgcCAhPSBwNSB8fCBwICE9IHA2IHx8IHAgIT0gcDcpCi0gICAgICBfZXhp
dCgxKTsKLQotICAgIC8qIE9uIHNvbWUgc3lzdGVtcyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRv
ZXNuJ3Qgc2VwYXJhdGUgcGFyZW50Ci0gICAgICAgZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3Jz
LiAgSWYgdGhlIGNoaWxkIGNsb3NlcyBhIGRlc2NyaXB0b3IKLSAgICAgICBiZWZvcmUgaXQgZXhl
Y3Mgb3IgZXhpdHMsIHRoaXMgbXVuZ2VzIHRoZSBwYXJlbnQncyBkZXNjcmlwdG9yCi0gICAgICAg
YXMgd2VsbC4gIFRlc3QgZm9yIHRoaXMgYnkgY2xvc2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAg
Ki8KLSAgICBfZXhpdChjbG9zZShmaWxlbm8oc3Rkb3V0KSkgIT0gMCk7Ci0gIH0gZWxzZSB7Ci0g
ICAgaW50IHN0YXR1czsKLSAgICBzdHJ1Y3Qgc3RhdCBzdDsKKwlhc19mbl9lcnJvciAkPyAiUGFj
a2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3ZXJlIG5vdCBtZXQ6CiAKLSAgICB3aGlsZSAo
d2FpdCgmc3RhdHVzKSAhPSBjaGlsZCkKLSAgICAgIDsKLSAgICByZXR1cm4gKAotCSAvKiBXYXMg
dGhlcmUgc29tZSBwcm9ibGVtIHdpdGggdmZvcmtpbmc/ICAqLwotCSBjaGlsZCA8IDAKKyRnbGli
X1BLR19FUlJPUlMKIAotCSAvKiBEaWQgdGhlIGNoaWxkIGZhaWw/ICAoVGhpcyBzaG91bGRuJ3Qg
aGFwcGVuLikgICovCi0JIHx8IHN0YXR1cworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09O
RklHX1BBVEggZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUg
aW4gYSBub24tc3RhbmRhcmQgcHJlZml4LgogCi0JIC8qIERpZCB0aGUgdmZvcmsvY29tcGlsZXIg
YnVnIG9jY3VyPyAgKi8KLQkgfHwgcGFyZW50ICE9IGdldHBpZCgpCitBbHRlcm5hdGl2ZWx5LCB5
b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xp
Yl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtn
LWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKK2VsaWYgdGVz
dCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KKyAgICAgCXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6
IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3Qg
YmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9y
IHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0
aCB0byBwa2ctY29uZmlnLgogCi0JIC8qIERpZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1
cj8gICovCi0JIHx8IGZzdGF0KGZpbGVubyhzdGRvdXQpLCAmc3QpICE9IDAKLQkgKTsKLSAgfQot
fQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zf
ZnVuY192Zm9ya193b3Jrcz15ZXMKK0FsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZp
cm9ubWVudCB2YXJpYWJsZXMgZ2xpYl9DRkxBR1MKK2FuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhl
IG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgorU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZv
ciBtb3JlIGRldGFpbHMuCisKK1RvIGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29u
ZmlnLmZyZWVkZXNrdG9wLm9yZy8+LgorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWls
cyIgIiRMSU5FTk8iIDUgOyB9CiBlbHNlCi0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KLWZp
Ci1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25m
dGVzdC4kYWNfZXh0Ci1maQorCWdsaWJfQ0ZMQUdTPSRwa2dfY3ZfZ2xpYl9DRkxBR1MKKwlnbGli
X0xJQlM9JHBrZ19jdl9nbGliX0xJQlMKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0K
IAogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfdmZvcmtf
d29ya3MiID4mNjsgfQogCi1maTsKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9
IHhjcm9zczsgdGhlbgotICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3Jr
Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVz
dWx0ICRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21w
aWxhdGlvbiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7
fQorIyBDaGVjayBsaWJyYXJ5IHBhdGgKK2lmIHRlc3QgIlwke2V4ZWNfcHJlZml4fS9saWIiID0g
IiRsaWJkaXIiOyB0aGVuIDoKKyAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIiAmJiB0
ZXN0ICIkcHJlZml4IiAhPSAiTk9ORSI7IHRoZW4gOgorICBleGVjX3ByZWZpeD0kcHJlZml4CiBm
aQorICAgIGlmIHRlc3QgIiRleGVjX3ByZWZpeCIgPSAiTk9ORSI7IHRoZW4gOgorICBleGVjX3By
ZWZpeD0kYWNfZGVmYXVsdF9wcmVmaXgKK2ZpCisgICAgaWYgdGVzdCAtZCAiJHtleGVjX3ByZWZp
eH0vbGliNjQiOyB0aGVuIDoKIAotaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA9
IHh5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX1ZGT1JLIDEiID4+
Y29uZmRlZnMuaAorICAgICAgICBMSUJfUEFUSD0ibGliNjQiCiAKIGVsc2UKIAotJGFzX2VjaG8g
IiNkZWZpbmUgdmZvcmsgZm9yayIgPj5jb25mZGVmcy5oCisgICAgICAgIExJQl9QQVRIPSJsaWIi
CiAKIGZpCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCiAK
LSRhc19lY2hvICIjZGVmaW5lIEhBVkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorZWxz
ZQogCi1maQorICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVjX3ByZWZp
eCIgKyAxYH0iCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMi
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5l
ZWRlZCBmb3IgbGFyZ2UgZmlsZXMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfc3lzX2xh
cmdlZmlsZV9zb3VyY2Urc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICB3aGlsZSA6OyBkbwotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lz
L3R5cGVzLmg+IC8qIGZvciBvZmZfdCAqLwotICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KLWludAot
bWFpbiAoKQotewotaW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwotICAg
ICByZXR1cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKLSAgOwot
ICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgotICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT1ubzsgYnJlYWsKLWZpCi1ybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jZGVmaW5lIF9MQVJHRUZJTEVf
U09VUkNFIDEKLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCi0gICAgICNp
bmNsdWRlIDxzdGRpby5oPgotaW50Ci1tYWluICgpCi17Ci1pbnQgKCpmcCkgKEZJTEUgKiwgb2Zm
X3QsIGludCkgPSBmc2Vla287Ci0gICAgIHJldHVybiBmc2Vla28gKHN0ZGluLCAwLCAwKSAmJiBm
cCAoc3RkaW4sIDAsIDApOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9j
X3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNl
PTE7IGJyZWFrCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgYWNfY3Zfc3lz
X2xhcmdlZmlsZV9zb3VyY2U9dW5rbm93bgotICBicmVhawotZG9uZQotZmkKLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc3lzX2xhcmdlZmls
ZV9zb3VyY2UiID4mNQotJGFzX2VjaG8gIiRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2
OyB9Ci1jYXNlICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSBpbiAjKAotICBubyB8IHVua25v
d24pIDs7Ci0gICopCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIF9MQVJHRUZJ
TEVfU09VUkNFICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZQotX0FDRU9GCi07OwotZXNhYwot
cm0gLXJmIGNvbmZ0ZXN0KgotCi0jIFdlIHVzZWQgdG8gdHJ5IGRlZmluaW5nIF9YT1BFTl9TT1VS
Q0U9NTAwIHRvbywgdG8gd29yayBhcm91bmQgYSBidWcKLSMgaW4gZ2xpYmMgMi4xLjMsIGJ1dCB0
aGF0IGJyZWFrcyB0b28gbWFueSBvdGhlciB0aGluZ3MuCi0jIElmIHlvdSB3YW50IGZzZWVrbyBh
bmQgZnRlbGxvIHdpdGggZ2xpYmMsIHVwZ3JhZGUgdG8gYSBmaXhlZCBnbGliYy4KLWlmIHRlc3Qg
JGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlICE9IHVua25vd247IHRoZW4KIAotJGFzX2VjaG8g
IiNkZWZpbmUgSEFWRV9GU0VFS08gMSIgPj5jb25mZGVmcy5oCiAKLWZpCisjIENoZWNrcyBmb3Ig
bGlicmFyaWVzLgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImJ6bGli
LmgiICJhY19jdl9oZWFkZXJfYnpsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl9oZWFkZXJfYnpsaWJfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29y
cmVjdGx5IGhhbmRsZXMgdHJhaWxpbmcgc2xhc2giID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg
d2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxp
bmsrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgQloyX2J6RGVjb21wcmVzc0luaXQgaW4gLWxiejIiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4u
ICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQr
c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot
ICBybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQotZWNobyA+Y29uZnRlc3QuZmlsZQot
aWYgdGVzdCAiJGFzX2xuX3MiID0gImxuIC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0
ZXN0LnN5bTsgdGhlbgotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6
Ci0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubwotZWxz
ZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sYnoyICAkTElCUyIKK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LSRhY19pbmNsdWRlc19kZWZhdWx0CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv
dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg
bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBh
cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNw
bHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7CiBp
bnQKIG1haW4gKCkKIHsKLXN0cnVjdCBzdGF0IHNidWY7Ci0gICAgIC8qIExpbnV4IHdpbGwgZGVy
ZWZlcmVuY2UgdGhlIHN5bWxpbmsgYW5kIGZhaWwsIGFzIHJlcXVpcmVkIGJ5IFBPU0lYLgotCVRo
YXQgaXMgYmV0dGVyIGluIHRoZSBzZW5zZSB0aGF0IGl0IG1lYW5zIHdlIHdpbGwgbm90Ci0JaGF2
ZSB0byBjb21waWxlIGFuZCB1c2UgdGhlIGxzdGF0IHdyYXBwZXIuICAqLwotICAgICByZXR1cm4g
bHN0YXQgKCJjb25mdGVzdC5zeW0vIiwgJnNidWYpID09IDA7CityZXR1cm4gQloyX2J6RGVjb21w
cmVzc0luaXQgKCk7CiAgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5
X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19z
bGFzaGVkX3N5bWxpbms9eWVzCi1lbHNlCi0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2Vz
X3NsYXNoZWRfc3ltbGluaz1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3Qu
KiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29i
amV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKLWZpCi0KK2lmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNz
SW5pdD15ZXMKIGVsc2UKLSAgIyBJZiB0aGUgYGxuIC1zJyBjb21tYW5kIGZhaWxlZCwgdGhlbiB3
ZSBwcm9iYWJseSBkb24ndCBldmVuCi0gICMgaGF2ZSBhbiBsc3RhdCBmdW5jdGlvbi4KLSAgYWNf
Y3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCisgIGFjX2N2X2xp
Yl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9bm8KIGZpCi1ybSAtZiBjb25mdGVzdC5zeW0gY29u
ZnRlc3QuZmlsZQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hl
Y2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0IiA9IHgiInllczsgdGhl
biA6CisgIHpsaWI9IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKIGZpCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0YXRfZGVy
ZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfbHN0
YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9Ci0KLXRlc3QgJGFjX2N2X2Z1
bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgogCi1jYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5L
IDEKLV9BQ0VPRgogCitmaQogCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVu
Y2VzX3NsYXNoZWRfc3ltbGluayIgPSB4bm87IHRoZW4KLSAgY2FzZSAiICRMSUJPQkpTICIgaW4K
LSAgKiIgbHN0YXQuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIGxz
dGF0LiRhY19vYmpleHQiCi0gOzsKLWVzYWMKIAotZmkKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21v
bmdyZWwgIiRMSU5FTk8iICJsem1hLmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1
ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem1hX2giID0geCIieWVzOyB0
aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldiIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldi4uLiAiID4mNjsgfQot
aWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRlditzZXR9IiA9IHNldDsg
dGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBsem1hX3N0cmVhbV9kZWNvZGVyIGluIC1sbHptYSIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhl
biA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k
TElCUworTElCUz0iLWxsem1hICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzeXMvdHlw
ZXMuaD4KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIK
KyNlbmRpZgorY2hhciBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwogaW50CiBtYWluICgpCiB7Ci1y
ZXR1cm4gbWFrZWRldigwLCAwKTsKK3JldHVybiBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwogICA7
CiAgIHJldHVybiAwOwogfQogX0FDRU9GCiBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2PXllcworICBhY19jdl9s
aWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPXllcwogZWxzZQotICBhY19jdl9oZWFkZXJfc3lz
X3R5cGVzX2hfbWFrZWRldj1ubworICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVy
PW5vCiBmaQogcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCiAg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLQotZmkKLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N5c190
eXBlc19oX21ha2VkZXYiID4mNQotJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hf
bWFrZWRldiIgPiY2OyB9Ci0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtl
ZGV2ID0gbm87IHRoZW4KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJz
eXMvbWtkZXYuaCIgImFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2giID0geCIieWVzOyB0aGVu
IDoKLQotJGFzX2VjaG8gIiNkZWZpbmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCi0K
K0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KLQotCi0gIGlmIHRlc3QgJGFjX2N2
X2hlYWRlcl9zeXNfbWtkZXZfaCA9IG5vOyB0aGVuCi0gICAgYWNfZm5fY19jaGVja19oZWFkZXJf
bW9uZ3JlbCAiJExJTkVOTyIgInN5cy9zeXNtYWNyb3MuaCIgImFjX2N2X2hlYWRlcl9zeXNfc3lz
bWFjcm9zX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVy
X3N5c19zeXNtYWNyb3NfaCIgPSB4IiJ5ZXM7IHRoZW4gOgotCi0kYXNfZWNobyAiI2RlZmluZSBN
QUpPUl9JTl9TWVNNQUNST1MgMSIgPj5jb25mZGVmcy5oCi0KK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1f
ZGVjb2RlciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29k
ZXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVy
IiA9IHgiInllczsgdGhlbiA6CisgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk1BIC1sbHptYSIKIGZp
CiAKIAotICBmaQogZmkKIAotZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAotZG8gOgotICBhY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFk
ZXJfc3RkbGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVh
ZGVyX3N0ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKLSNkZWZpbmUgSEFWRV9TVERMSUJfSCAxCi1fQUNFT0YKLQotZmkKIAotZG9uZQorYWNfZm5f
Y19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVh
ZGVyX2x6b19sem8xeF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2
X2hlYWRlcl9sem9fbHpvMXhfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxl
IG1hbGxvYyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJs
ZSBtYWxsb2MuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u
dWxsK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMi4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzK3NldH0iID0g
c2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX21hbGxvY18w
X25vbm51bGw9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGx6bzIgICRM
SUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5k
IGNvbmZkZWZzLmguICAqLwotI2lmIGRlZmluZWQgU1REQ19IRUFERVJTIHx8IGRlZmluZWQgSEFW
RV9TVERMSUJfSAotIyBpbmNsdWRlIDxzdGRsaWIuaD4KLSNlbHNlCi1jaGFyICptYWxsb2MgKCk7
Ci0jZW5kaWYKIAorLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv
aWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0
dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3Rv
dHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAi
QyIKKyNlbmRpZgorY2hhciBsem8xeF9kZWNvbXByZXNzICgpOwogaW50CiBtYWluICgpCiB7Ci1y
ZXR1cm4gISBtYWxsb2MgKDApOworcmV0dXJuIGx6bzF4X2RlY29tcHJlc3MgKCk7CiAgIDsKICAg
cmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9eWVzCitpZiBhY19mbl9jX3RyeV9saW5r
ICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9eWVz
CiBlbHNlCi0gIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1ubworICBhY19jdl9saWJfbHpv
Ml9sem8xeF9kZWNvbXByZXNzPW5vCiBmaQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVz
dC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNf
b2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJf
bHpvMXhfZGVjb21wcmVzcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9sem8yX2x6bzF4X2Rl
Y29tcHJlc3MiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXBy
ZXNzIiA9IHgiInllczsgdGhlbiA6CisgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIi
CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX21h
bGxvY18wX25vbm51bGwiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u
dWxsID0geWVzOyB0aGVuIDoKLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMSIgPj5j
b25mZGVmcy5oCi0KLWVsc2UKLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMCIgPj5j
b25mZGVmcy5oCi0KLSAgIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIG1hbGxvYy4kYWNfb2Jq
ZXh0ICIqICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgbWFsbG9jLiRhY19vYmpleHQiCi0g
OzsKLWVzYWMKLQogCi0kYXNfZWNobyAiI2RlZmluZSBtYWxsb2MgcnBsX21hbGxvYyIgPj5jb25m
ZGVmcy5oCiAKIGZpCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNs
dWRlZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3Rp
bWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9o
ZWFkZXJfdGltZStzZXR9IiA9IHNldDsgdGhlbiA6CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9saWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJT
PSItbGFpbyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5j
bHVkZSA8c3lzL3RpbWUuaD4KLSNpbmNsdWRlIDx0aW1lLmg+CiAKKy8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj
YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu
IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor
I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgaW9fc2V0dXAgKCk7
CiBpbnQKIG1haW4gKCkKIHsKLWlmICgoc3RydWN0IHRtICopIDApCi1yZXR1cm4gMDsKK3JldHVy
biBpb19zZXR1cCAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9oZWFkZXJfdGltZT15ZXMKK2lm
IGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2Fpb19pb19z
ZXR1cD15ZXMKIGVsc2UKLSAgYWNfY3ZfaGVhZGVyX3RpbWU9bm8KLWZpCi1ybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRl
cl90aW1lIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQotaWYgdGVz
dCAkYWNfY3ZfaGVhZGVyX3RpbWUgPSB5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgVElN
RV9XSVRIX1NZU19USU1FIDEiID4+Y29uZmRlZnMuaAotCisgIGFjX2N2X2xpYl9haW9faW9fc2V0
dXA9bm8KIGZpCi0KLQotCi0KLSAgZm9yIGFjX2hlYWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKLWRv
IDoKLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwg
JGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19o
ZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSIKLWlmIGV2YWwg
dGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLSAgY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAk
YXNfdHJfY3BwYCAxCi1fQUNFT0YKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJ
QlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KLWRvbmUKLQotCi0KLQotCi0KLQotCi0g
IGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKLWRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNo
byAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMg
IiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFz
X2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VP
RgotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2xpYl9haW9faW9fc2V0dXAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfYWlvX2lvX3Nl
dHVwIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPSB4IiJ5ZXM7
IHRoZW4gOgorICBzeXN0ZW1fYWlvPSJ5IgorZWxzZQorICBzeXN0ZW1fYWlvPSJuIgogZmkKLWRv
bmUKLQogCiAKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciB3b3JraW5nIG1rdGltZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
d29ya2luZyBta3RpbWUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY193b3JraW5n
X21rdGltZStzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIE1ENSBpbiAtbGNyeXB0by4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth
Y19jdl9saWJfY3J5cHRvX01ENStzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKLSAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubwotZWxzZQotICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlM9JExJQlMKK0xJQlM9Ii1sY3J5cHRvICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLS8qIFRlc3QgcHJv
Z3JhbSBmcm9tIFBhdWwgRWdnZXJ0IGFuZCBUb255IExlbmVpcy4gICovCi0jaWZkZWYgVElNRV9X
SVRIX1NZU19USU1FCi0jIGluY2x1ZGUgPHN5cy90aW1lLmg+Ci0jIGluY2x1ZGUgPHRpbWUuaD4K
LSNlbHNlCi0jIGlmZGVmIEhBVkVfU1lTX1RJTUVfSAotIyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4K
LSMgZWxzZQotIyAgaW5jbHVkZSA8dGltZS5oPgotIyBlbmRpZgotI2VuZGlmCi0KLSNpbmNsdWRl
IDxsaW1pdHMuaD4KLSNpbmNsdWRlIDxzdGRsaWIuaD4KIAotI2lmZGVmIEhBVkVfVU5JU1REX0gK
LSMgaW5jbHVkZSA8dW5pc3RkLmg+Ci0jZW5kaWYKLQotI2lmbmRlZiBIQVZFX0FMQVJNCi0jIGRl
ZmluZSBhbGFybShYKSAvKiBlbXB0eSAqLworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1
c3BsdXMKK2V4dGVybiAiQyIKICNlbmRpZgotCi0vKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24g
dG8gcnBsX3B1dGVudiBieSBvdGhlciBjb25maWcgdGVzdHMuICAqLwotI3VuZGVmIHB1dGVudgot
Ci1zdGF0aWMgdGltZV90IHRpbWVfdF9tYXg7Ci1zdGF0aWMgdGltZV90IHRpbWVfdF9taW47Ci0K
LS8qIFZhbHVlcyB3ZSdsbCB1c2UgdG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4g
ICovCi1zdGF0aWMgY29uc3QgY2hhciAqdHpfc3RyaW5nc1tdID0gewotICAoY29uc3QgY2hhciAq
KSAwLCAiVFo9R01UMCIsICJUWj1KU1QtOSIsCi0gICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6
MDA6MDAsTTIuMy4wLzAwOjAwOjAwIgotfTsKLSNkZWZpbmUgTl9TVFJJTkdTIChzaXplb2YgKHR6
X3N0cmluZ3MpIC8gc2l6ZW9mICh0el9zdHJpbmdzWzBdKSkKLQotLyogUmV0dXJuIDAgaWYgbWt0
aW1lIGZhaWxzIHRvIGNvbnZlcnQgYSBkYXRlIGluIHRoZSBzcHJpbmctZm9yd2FyZCBnYXAuCi0g
ICBCYXNlZCBvbiBhIHByb2JsZW0gcmVwb3J0IGZyb20gQW5kcmVhcyBKYWVnZXIuICAqLwotc3Rh
dGljIGludAotc3ByaW5nX2ZvcndhcmRfZ2FwICgpCi17Ci0gIC8qIGdsaWJjICh1cCB0byBhYm91
dCAxOTk4LTEwLTA3KSBmYWlsZWQgdGhpcyB0ZXN0LiAqLwotICBzdHJ1Y3QgdG0gdG07Ci0KLSAg
LyogVXNlIHRoZSBwb3J0YWJsZSBQT1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQu
MS4wLE0xMC41LjAiCi0gICAgIGluc3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBv
cmRlciB0byBkZXRlY3QgdGhlIGJ1ZyBldmVuCi0gICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBz
dXBwb3J0IHRoZSBPbHNvbiBleHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCi0gICAgIGZ1bGwg
em9uZWluZm8gdGFibGVzIGluc3RhbGxlZC4gICovCi0gIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNU
OFBEVCxNNC4xLjAsTTEwLjUuMCIpOwotCi0gIHRtLnRtX3llYXIgPSA5ODsKLSAgdG0udG1fbW9u
ID0gMzsKLSAgdG0udG1fbWRheSA9IDU7Ci0gIHRtLnRtX2hvdXIgPSAyOwotICB0bS50bV9taW4g
PSAwOwotICB0bS50bV9zZWMgPSAwOwotICB0bS50bV9pc2RzdCA9IC0xOwotICByZXR1cm4gbWt0
aW1lICgmdG0pICE9ICh0aW1lX3QpIC0xOwotfQotCi1zdGF0aWMgaW50Ci1ta3RpbWVfdGVzdDEg
KHRpbWVfdCBub3cpCi17Ci0gIHN0cnVjdCB0bSAqbHQ7Ci0gIHJldHVybiAhIChsdCA9IGxvY2Fs
dGltZSAoJm5vdykpIHx8IG1rdGltZSAobHQpID09IG5vdzsKLX0KLQotc3RhdGljIGludAotbWt0
aW1lX3Rlc3QgKHRpbWVfdCBub3cpCi17Ci0gIHJldHVybiAobWt0aW1lX3Rlc3QxIChub3cpCi0J
ICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3QpICh0aW1lX3RfbWF4IC0gbm93KSkKLQkgICYmIG1r
dGltZV90ZXN0MSAoKHRpbWVfdCkgKHRpbWVfdF9taW4gKyBub3cpKSk7Ci19Ci0KLXN0YXRpYyBp
bnQKLWlyaXhfNl80X2J1ZyAoKQotewotICAvKiBCYXNlZCBvbiBjb2RlIGZyb20gQXJpZWwgRmFp
Z29uLiAgKi8KLSAgc3RydWN0IHRtIHRtOwotICB0bS50bV95ZWFyID0gOTY7Ci0gIHRtLnRtX21v
biA9IDM7Ci0gIHRtLnRtX21kYXkgPSAwOwotICB0bS50bV9ob3VyID0gMDsKLSAgdG0udG1fbWlu
ID0gMDsKLSAgdG0udG1fc2VjID0gMDsKLSAgdG0udG1faXNkc3QgPSAtMTsKLSAgbWt0aW1lICgm
dG0pOwotICByZXR1cm4gdG0udG1fbW9uID09IDIgJiYgdG0udG1fbWRheSA9PSAzMTsKLX0KLQot
c3RhdGljIGludAotYmlndGltZV90ZXN0IChpbnQgaikKLXsKLSAgc3RydWN0IHRtIHRtOwotICB0
aW1lX3Qgbm93OwotICB0bS50bV95ZWFyID0gdG0udG1fbW9uID0gdG0udG1fbWRheSA9IHRtLnRt
X2hvdXIgPSB0bS50bV9taW4gPSB0bS50bV9zZWMgPSBqOwotICBub3cgPSBta3RpbWUgKCZ0bSk7
Ci0gIGlmIChub3cgIT0gKHRpbWVfdCkgLTEpCi0gICAgewotICAgICAgc3RydWN0IHRtICpsdCA9
IGxvY2FsdGltZSAoJm5vdyk7Ci0gICAgICBpZiAoISAobHQKLQkgICAgICYmIGx0LT50bV95ZWFy
ID09IHRtLnRtX3llYXIKLQkgICAgICYmIGx0LT50bV9tb24gPT0gdG0udG1fbW9uCi0JICAgICAm
JiBsdC0+dG1fbWRheSA9PSB0bS50bV9tZGF5Ci0JICAgICAmJiBsdC0+dG1faG91ciA9PSB0bS50
bV9ob3VyCi0JICAgICAmJiBsdC0+dG1fbWluID09IHRtLnRtX21pbgotCSAgICAgJiYgbHQtPnRt
X3NlYyA9PSB0bS50bV9zZWMKLQkgICAgICYmIGx0LT50bV95ZGF5ID09IHRtLnRtX3lkYXkKLQkg
ICAgICYmIGx0LT50bV93ZGF5ID09IHRtLnRtX3dkYXkKLQkgICAgICYmICgobHQtPnRtX2lzZHN0
IDwgMCA/IC0xIDogMCA8IGx0LT50bV9pc2RzdCkKLQkJICA9PSAodG0udG1faXNkc3QgPCAwID8g
LTEgOiAwIDwgdG0udG1faXNkc3QpKSkpCi0JcmV0dXJuIDA7Ci0gICAgfQotICByZXR1cm4gMTsK
LX0KLQotc3RhdGljIGludAoteWVhcl8yMDUwX3Rlc3QgKCkKLXsKLSAgLyogVGhlIGNvcnJlY3Qg
YW5zd2VyIGZvciAyMDUwLTAyLTAxIDAwOjAwOjAwIGluIFBhY2lmaWMgdGltZSwKLSAgICAgaWdu
b3JpbmcgbGVhcCBzZWNvbmRzLiAgKi8KLSAgdW5zaWduZWQgbG9uZyBpbnQgYW5zd2VyID0gMjUy
NzMxNTIwMFVMOwotCi0gIHN0cnVjdCB0bSB0bTsKLSAgdGltZV90IHQ7Ci0gIHRtLnRtX3llYXIg
PSAyMDUwIC0gMTkwMDsKLSAgdG0udG1fbW9uID0gMiAtIDE7Ci0gIHRtLnRtX21kYXkgPSAxOwot
ICB0bS50bV9ob3VyID0gdG0udG1fbWluID0gdG0udG1fc2VjID0gMDsKLSAgdG0udG1faXNkc3Qg
PSAtMTsKLQotICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9
UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIKLSAgICAgaW5zdGVhZCBvZiAiVFo9QW1lcmljYS9WYW5j
b3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVnIGV2ZW4KLSAgICAgb24gc3lzdGVtcyB0
aGF0IGRvbid0IHN1cHBvcnQgdGhlIE9sc29uIGV4dGVuc2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUK
LSAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFsbGVkLiAgKi8KLSAgcHV0ZW52ICgoY2hh
ciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7Ci0KLSAgdCA9IG1rdGltZSAoJnRtKTsK
LQotICAvKiBDaGVjayB0aGF0IHRoZSByZXN1bHQgaXMgZWl0aGVyIGEgZmFpbHVyZSwgb3IgY2xv
c2UgZW5vdWdoCi0gICAgIHRvIHRoZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdlIGNhbiBhc3N1bWUg
dGhlIGRpc2NyZXBhbmN5IGlzCi0gICAgIGR1ZSB0byBsZWFwIHNlY29uZHMuICAqLwotICByZXR1
cm4gKHQgPT0gKHRpbWVfdCkgLTEKLQkgIHx8ICgwIDwgdCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAm
JiB0IDw9IGFuc3dlciArIDEyMCkpOwotfQotCitjaGFyIE1ENSAoKTsKIGludAogbWFpbiAoKQog
ewotICB0aW1lX3QgdCwgZGVsdGE7Ci0gIGludCBpLCBqOwotCi0gIC8qIFRoaXMgdGVzdCBtYWtl
cyBzb21lIGJ1Z2d5IG1rdGltZSBpbXBsZW1lbnRhdGlvbnMgbG9vcC4KLSAgICAgR2l2ZSB1cCBh
ZnRlciA2MCBzZWNvbmRzOyBhIG1rdGltZSBzbG93ZXIgdGhhbiB0aGF0Ci0gICAgIGlzbid0IHdv
cnRoIHVzaW5nIGFueXdheS4gICovCi0gIGFsYXJtICg2MCk7Ci0KLSAgZm9yICg7OykKLSAgICB7
Ci0gICAgICB0ID0gKHRpbWVfdF9tYXggPDwgMSkgKyAxOwotICAgICAgaWYgKHQgPD0gdGltZV90
X21heCkKLQlicmVhazsKLSAgICAgIHRpbWVfdF9tYXggPSB0OwotICAgIH0KLSAgdGltZV90X21p
biA9IC0gKCh0aW1lX3QpIH4gKHRpbWVfdCkgMCA9PSAodGltZV90KSAtMSkgLSB0aW1lX3RfbWF4
OwotCi0gIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyogYSBzdWl0YWJsZSBwcmltZSBudW1i
ZXIgKi8KLSAgZm9yIChpID0gMDsgaSA8IE5fU1RSSU5HUzsgaSsrKQotICAgIHsKLSAgICAgIGlm
ICh0el9zdHJpbmdzW2ldKQotCXB1dGVudiAoKGNoYXIqKSB0el9zdHJpbmdzW2ldKTsKLQotICAg
ICAgZm9yICh0ID0gMDsgdCA8PSB0aW1lX3RfbWF4IC0gZGVsdGE7IHQgKz0gZGVsdGEpCi0JaWYg
KCEgbWt0aW1lX3Rlc3QgKHQpKQotCSAgcmV0dXJuIDE7Ci0gICAgICBpZiAoISAobWt0aW1lX3Rl
c3QgKCh0aW1lX3QpIDEpCi0JICAgICAmJiBta3RpbWVfdGVzdCAoKHRpbWVfdCkgKDYwICogNjAp
KQotCSAgICAgJiYgbWt0aW1lX3Rlc3QgKCh0aW1lX3QpICg2MCAqIDYwICogMjQpKSkpCi0JcmV0
dXJuIDE7Ci0KLSAgICAgIGZvciAoaiA9IDE7IDsgaiA8PD0gMSkKLQlpZiAoISBiaWd0aW1lX3Rl
c3QgKGopKQotCSAgcmV0dXJuIDE7Ci0JZWxzZSBpZiAoSU5UX01BWCAvIDIgPCBqKQotCSAgYnJl
YWs7Ci0gICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKElOVF9NQVgpKQotCXJldHVybiAxOwotICAg
IH0KLSAgcmV0dXJuICEgKGlyaXhfNl80X2J1ZyAoKSAmJiBzcHJpbmdfZm9yd2FyZF9nYXAgKCkg
JiYgeWVhcl8yMDUwX3Rlc3QgKCkpOworcmV0dXJuIE1ENSAoKTsKKyAgOworICByZXR1cm4gMDsK
IH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2
X2Z1bmNfd29ya2luZ19ta3RpbWU9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6CisgIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PXllcwogZWxzZQotICBhY19jdl9mdW5jX3dv
cmtpbmdfbWt0aW1lPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdt
b24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKLQorICBhY19jdl9saWJfY3J5cHRv
X01ENT1ubwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfZnVuY193b3JraW5nX21rdGltZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1
bmNfd29ya2luZ19ta3RpbWUiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVuY193b3JraW5nX21r
dGltZSA9IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIG1rdGltZS4kYWNf
b2JqZXh0ICIqICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgbWt0aW1lLiRhY19vYmpleHQi
Ci0gOzsKLWVzYWMKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KLQotCi0KLQotCi1mb3IgYWNfZnVuYyBpbiBnZXRwYWdl
c2l6ZQotZG8gOgotICBhY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6ZSIg
ImFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNp
emUiID0geCIieWVzOyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9saWJfY3J5cHRvX01ENSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1
IiA9IHgiInllczsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUg
SEFWRV9HRVRQQUdFU0laRSAxCisjZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKIF9BQ0VPRgogCisg
IExJQlM9Ii1sY3J5cHRvICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBu
b3QgZmluZCBsaWJjcnlwdG8iICIkTElORU5PIiA1CiBmaQotZG9uZQogCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQotaWYg
dGVzdCAiJHthY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkK3NldH0iID0gc2V0OyB0aGVuIDoK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGV4
dDJmc19vcGVuMiBpbiAtbGV4dDJmcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZXh0
MmZzX29wZW4yIGluIC1sZXh0MmZzLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9l
eHQyZnNfZXh0MmZzX29wZW4yK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRo
ZW4gOgotICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCi1lbHNlCi0gIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVf
TElCUz0kTElCUworTElCUz0iLWxleHQyZnMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1
ZGVzX2RlZmF1bHQKLS8qIG1hbGxvYyBtaWdodCBoYXZlIGJlZW4gcmVuYW1lZCBhcyBycGxfbWFs
bG9jLiAqLwotI3VuZGVmIG1hbGxvYwotCi0vKiBUaGFua3MgdG8gTWlrZSBIYWVydGVsIGFuZCBK
aW0gQXZlcmEgZm9yIHRoaXMgdGVzdC4KLSAgIEhlcmUgaXMgYSBtYXRyaXggb2YgbW1hcCBwb3Nz
aWJpbGl0aWVzOgotCW1tYXAgcHJpdmF0ZSBub3QgZml4ZWQKLQltbWFwIHByaXZhdGUgZml4ZWQg
YXQgc29tZXdoZXJlIGN1cnJlbnRseSB1bm1hcHBlZAotCW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBz
b21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKLQltbWFwIHNoYXJlZCBub3QgZml4ZWQKLQltbWFwIHNo
YXJlZCBmaXhlZCBhdCBzb21ld2hlcmUgY3VycmVudGx5IHVubWFwcGVkCi0JbW1hcCBzaGFyZWQg
Zml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCi0gICBGb3IgcHJpdmF0ZSBtYXBwaW5n
cywgd2Ugc2hvdWxkIHZlcmlmeSB0aGF0IGNoYW5nZXMgY2Fubm90IGJlIHJlYWQoKQotICAgYmFj
ayBmcm9tIHRoZSBmaWxlLCBub3IgbW1hcCdzIGJhY2sgZnJvbSB0aGUgZmlsZSBhdCBhIGRpZmZl
cmVudAotICAgYWRkcmVzcy4gIChUaGVyZSBoYXZlIGJlZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRl
IHdhcyBub3QgY29ycmVjdGx5Ci0gICBpbXBsZW1lbnRlZCBsaWtlIHRoZSBpbmZhbW91cyBpMzg2
IHN2cjQuMCwgYW5kIHN5c3RlbXMgd2hlcmUgdGhlCi0gICBWTSBwYWdlIGNhY2hlIHdhcyBub3Qg
Y29oZXJlbnQgd2l0aCB0aGUgZmlsZSBzeXN0ZW0gYnVmZmVyIGNhY2hlCi0gICBsaWtlIGVhcmx5
IHZlcnNpb25zIG9mIEZyZWVCU0QgYW5kIHBvc3NpYmx5IGNvbnRlbXBvcmFyeSBOZXRCU0QuKQot
ICAgRm9yIHNoYXJlZCBtYXBwaW5ncywgd2Ugc2hvdWxkIGNvbnZlcnNlbHkgdmVyaWZ5IHRoYXQg
Y2hhbmdlcyBnZXQKLSAgIHByb3BhZ2F0ZWQgYmFjayB0byBhbGwgdGhlIHBsYWNlcyB0aGV5J3Jl
IHN1cHBvc2VkIHRvIGJlLgotCi0gICBHcmVwIHdhbnRzIHByaXZhdGUgZml4ZWQgYWxyZWFkeSBt
YXBwZWQuCi0gICBUaGUgbWFpbiB0aGluZ3MgZ3JlcCBuZWVkcyB0byBrbm93IGFib3V0IG1tYXAg
YXJlOgotICAgKiBkb2VzIGl0IGV4aXN0IGFuZCBpcyBpdCBzYWZlIHRvIHdyaXRlIGludG8gdGhl
IG1tYXAnZCBhcmVhCi0gICAqIGhvdyB0byB1c2UgaXQgKEJTRCB2YXJpYW50cykgICovCi0KLSNp
bmNsdWRlIDxmY250bC5oPgotI2luY2x1ZGUgPHN5cy9tbWFuLmg+Ci0KLSNpZiAhZGVmaW5lZCBT
VERDX0hFQURFUlMgJiYgIWRlZmluZWQgSEFWRV9TVERMSUJfSAotY2hhciAqbWFsbG9jICgpOwot
I2VuZGlmCi0KLS8qIFRoaXMgbWVzcyB3YXMgY29waWVkIGZyb20gdGhlIEdOVSBnZXRwYWdlc2l6
ZS5oLiAgKi8KLSNpZm5kZWYgSEFWRV9HRVRQQUdFU0laRQotIyBpZmRlZiBfU0NfUEFHRVNJWkUK
LSMgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIHN5c2NvbmYoX1NDX1BBR0VTSVpFKQotIyBlbHNlIC8q
IG5vIF9TQ19QQUdFU0laRSAqLwotIyAgaWZkZWYgSEFWRV9TWVNfUEFSQU1fSAotIyAgIGluY2x1
ZGUgPHN5cy9wYXJhbS5oPgotIyAgIGlmZGVmIEVYRUNfUEFHRVNJWkUKLSMgICAgZGVmaW5lIGdl
dHBhZ2VzaXplKCkgRVhFQ19QQUdFU0laRQotIyAgIGVsc2UgLyogbm8gRVhFQ19QQUdFU0laRSAq
LwotIyAgICBpZmRlZiBOQlBHCi0jICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBOQlBHICogQ0xT
SVpFCi0jICAgICBpZm5kZWYgQ0xTSVpFCi0jICAgICAgZGVmaW5lIENMU0laRSAxCi0jICAgICBl
bmRpZiAvKiBubyBDTFNJWkUgKi8KLSMgICAgZWxzZSAvKiBubyBOQlBHICovCi0jICAgICBpZmRl
ZiBOQlBDCi0jICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgTkJQQwotIyAgICAgZWxzZSAvKiBu
byBOQlBDICovCi0jICAgICAgaWZkZWYgUEFHRVNJWkUKLSMgICAgICAgZGVmaW5lIGdldHBhZ2Vz
aXplKCkgUEFHRVNJWkUKLSMgICAgICBlbmRpZiAvKiBQQUdFU0laRSAqLwotIyAgICAgZW5kaWYg
Lyogbm8gTkJQQyAqLwotIyAgICBlbmRpZiAvKiBubyBOQlBHICovCi0jICAgZW5kaWYgLyogbm8g
RVhFQ19QQUdFU0laRSAqLwotIyAgZWxzZSAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCi0jICAg
ZGVmaW5lIGdldHBhZ2VzaXplKCkgODE5MgkvKiBwdW50IHRvdGFsbHkgKi8KLSMgIGVuZGlmIC8q
IG5vIEhBVkVfU1lTX1BBUkFNX0ggKi8KLSMgZW5kaWYgLyogbm8gX1NDX1BBR0VTSVpFICovCi0K
LSNlbmRpZiAvKiBubyBIQVZFX0dFVFBBR0VTSVpFICovCiAKKy8qIE92ZXJyaWRlIGFueSBHQ0Mg
aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVz
ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFu
ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lm
ZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0MmZzX29wZW4yICgp
OwogaW50CiBtYWluICgpCiB7Ci0gIGNoYXIgKmRhdGEsICpkYXRhMiwgKmRhdGEzOwotICBjb25z
dCBjaGFyICpjZGF0YTI7Ci0gIGludCBpLCBwYWdlc2l6ZTsKLSAgaW50IGZkLCBmZDI7Ci0KLSAg
cGFnZXNpemUgPSBnZXRwYWdlc2l6ZSAoKTsKLQotICAvKiBGaXJzdCwgbWFrZSBhIGZpbGUgd2l0
aCBzb21lIGtub3duIGdhcmJhZ2UgaW4gaXQuICovCi0gIGRhdGEgPSAoY2hhciAqKSBtYWxsb2Mg
KHBhZ2VzaXplKTsKLSAgaWYgKCFkYXRhKQotICAgIHJldHVybiAxOwotICBmb3IgKGkgPSAwOyBp
IDwgcGFnZXNpemU7ICsraSkKLSAgICAqKGRhdGEgKyBpKSA9IHJhbmQgKCk7Ci0gIHVtYXNrICgw
KTsKLSAgZmQgPSBjcmVhdCAoImNvbmZ0ZXN0Lm1tYXAiLCAwNjAwKTsKLSAgaWYgKGZkIDwgMCkK
LSAgICByZXR1cm4gMjsKLSAgaWYgKHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2Vz
aXplKQotICAgIHJldHVybiAzOwotICBjbG9zZSAoZmQpOwotCi0gIC8qIE5leHQsIGNoZWNrIHRo
YXQgdGhlIHRhaWwgb2YgYSBwYWdlIGlzIHplcm8tZmlsbGVkLiAgRmlsZSBtdXN0IGhhdmUKLSAg
ICAgbm9uLXplcm8gbGVuZ3RoLCBvdGhlcndpc2Ugd2UgcmlzayBTSUdCVVMgZm9yIGVudGlyZSBw
YWdlLiAgKi8KLSAgZmQyID0gb3BlbiAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQg
fCBPX1RSVU5DLCAwNjAwKTsKLSAgaWYgKGZkMiA8IDApCi0gICAgcmV0dXJuIDQ7Ci0gIGNkYXRh
MiA9ICIiOwotICBpZiAod3JpdGUgKGZkMiwgY2RhdGEyLCAxKSAhPSAxKQotICAgIHJldHVybiA1
OwotICBkYXRhMiA9IChjaGFyICopIG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9U
X1dSSVRFLCBNQVBfU0hBUkVELCBmZDIsIDBMKTsKLSAgaWYgKGRhdGEyID09IE1BUF9GQUlMRUQp
Ci0gICAgcmV0dXJuIDY7Ci0gIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQotICAgIGlm
ICgqKGRhdGEyICsgaSkpCi0gICAgICByZXR1cm4gNzsKLSAgY2xvc2UgKGZkMik7Ci0gIGlmICht
dW5tYXAgKGRhdGEyLCBwYWdlc2l6ZSkpCi0gICAgcmV0dXJuIDg7Ci0KLSAgLyogTmV4dCwgdHJ5
IHRvIG1tYXAgdGhlIGZpbGUgYXQgYSBmaXhlZCBhZGRyZXNzIHdoaWNoIGFscmVhZHkgaGFzCi0g
ICAgIHNvbWV0aGluZyBlbHNlIGFsbG9jYXRlZCBhdCBpdC4gIElmIHdlIGNhbiwgYWxzbyBtYWtl
IHN1cmUgdGhhdAotICAgICB3ZSBzZWUgdGhlIHNhbWUgZ2FyYmFnZS4gICovCi0gIGZkID0gb3Bl
biAoImNvbmZ0ZXN0Lm1tYXAiLCBPX1JEV1IpOwotICBpZiAoZmQgPCAwKQotICAgIHJldHVybiA5
OwotICBpZiAoZGF0YTIgIT0gbW1hcCAoZGF0YTIsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9U
X1dSSVRFLAotCQkgICAgIE1BUF9QUklWQVRFIHwgTUFQX0ZJWEVELCBmZCwgMEwpKQotICAgIHJl
dHVybiAxMDsKLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgaWYgKCooZGF0
YSArIGkpICE9ICooZGF0YTIgKyBpKSkKLSAgICAgIHJldHVybiAxMTsKLQotICAvKiBGaW5hbGx5
LCBtYWtlIHN1cmUgdGhhdCBjaGFuZ2VzIHRvIHRoZSBtYXBwZWQgYXJlYSBkbyBub3QKLSAgICAg
cGVyY29sYXRlIGJhY2sgdG8gdGhlIGZpbGUgYXMgc2VlbiBieSByZWFkKCkuICAoVGhpcyBpcyBh
IGJ1ZyBvbgotICAgICBzb21lIHZhcmlhbnRzIG9mIGkzODYgc3ZyNC4wLikgICovCi0gIGZvciAo
aSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQotICAgICooZGF0YTIgKyBpKSA9ICooZGF0YTIgKyBp
KSArIDE7Ci0gIGRhdGEzID0gKGNoYXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7Ci0gIGlmICghZGF0
YTMpCi0gICAgcmV0dXJuIDEyOwotICBpZiAocmVhZCAoZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0g
cGFnZXNpemUpCi0gICAgcmV0dXJuIDEzOwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsr
aSkKLSAgICBpZiAoKihkYXRhICsgaSkgIT0gKihkYXRhMyArIGkpKQotICAgICAgcmV0dXJuIDE0
OwotICBjbG9zZSAoZmQpOworcmV0dXJuIGV4dDJmc19vcGVuMiAoKTsKKyAgOwogICByZXR1cm4g
MDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFj
X2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcwogZWxzZQot
ICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUg
Y29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKLQor
ICBhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj1ubwogZmkKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21h
cHBlZCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNjsg
fQotaWYgdGVzdCAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCA9IHllczsgdGhlbgotCi0k
YXNfZWNobyAiI2RlZmluZSBIQVZFX01NQVAgMSIgPj5jb25mZGVmcy5oCi0KK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotcm0g
LWYgY29uZnRlc3QubW1hcCBjb25mdGVzdC50eHQKLQotZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIu
aAotZG8gOgotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGli
LmgiICJhY19jdl9oZWFkZXJfc3RkbGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRl
c3QgIngkYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVERMSUJfSCAxCi1fQUNFT0YKLQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJf
ZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0
MmZzX29wZW4yIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3Bl
bjIiID0geCIieWVzOyB0aGVuIDoKKyAgbGliZXh0MmZzPSJ5IgorZWxzZQorICBsaWJleHQyZnM9
Im4iCiBmaQogCi1kb25lCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgcmVhbGxvYyIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSByZWFsbG9jLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdCIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIk
Y3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25v
bm51bGw9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGdjcnlwdCAgJExJ
QlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQg
Y29uZmRlZnMuaC4gICovCi0jaWYgZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5lZCBIQVZF
X1NURExJQl9ICi0jIGluY2x1ZGUgPHN0ZGxpYi5oPgotI2Vsc2UKLWNoYXIgKnJlYWxsb2MgKCk7
Ci0jZW5kaWYKIAorLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv
aWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0
dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3Rv
dHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAi
QyIKKyNlbmRpZgorY2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwogaW50CiBtYWluICgpCiB7
Ci1yZXR1cm4gISByZWFsbG9jICgwLCAwKTsKK3JldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgp
OwogICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5F
Tk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21k
X2hhc2hfYnVmZmVyPXllcwogZWxzZQotICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5v
CisgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwogZmkKLXJtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l
eHQKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2
ZV9MSUJTCiBmaQotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9CitpZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPSB4IiJ5ZXM7IHRoZW4g
OgorICBsaWJnY3J5cHQ9InkiCitlbHNlCisgIGxpYmdjcnlwdD0ibiIKIGZpCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxv
Y18wX25vbm51bGwiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxs
IiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwgPSB5ZXM7IHRo
ZW4gOgogCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1JFQUxMT0MgMSIgPj5jb25mZGVmcy5oCiAK
KworICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIHB0aHJlYWQgZmxhZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZCBm
bGFnLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2F4X2N2X3B0aHJlYWRfZmxhZ3Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICAkYXNfZWNo
byAiI2RlZmluZSBIQVZFX1JFQUxMT0MgMCIgPj5jb25mZGVmcy5oCiAKLSAgIGNhc2UgIiAkTElC
T0JKUyAiIGluCi0gICoiIHJlYWxsb2MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9
IiRMSUJPQkpTIHJlYWxsb2MuJGFjX29iamV4dCIKLSA7OwotZXNhYworICAgICAgICBheF9jdl9w
dGhyZWFkX2ZsYWdzPS1wdGhyZWFkCisKKyAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJl
YWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKKyAg
ICBQVEhSRUFEX0xJQlM9IiIKKworCisgICAgc2F2ZWRfQ0ZMQUdTPSIkQ0ZMQUdTIgorCisgICAg
c2F2ZWRfTERGTEFHUz0iJExERkxBR1MiCisKKyAgICBzYXZlZF9MSUJTPSIkTElCUyIKKworCisg
ICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQVEhSRUFEX0NGTEFHUyIKKworICAgIExERkxBR1M9IiRMREZM
QUdTICRQVEhSRUFEX0xERkxBR1MiCisKKyAgICBMSUJTPSIkTElCUyAkUFRIUkVBRF9MSUJTIgor
CisgICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKworI2luY2x1ZGUgPHB0aHJlYWQuaD4KK2ludCBtYWluKHZv
aWQpIHsKKyAgcHRocmVhZF9hdGZvcmsoMCwwLDApOworICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCww
KTsKK30KKworX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisK
K2Vsc2UKKyAgYXhfY3ZfcHRocmVhZF9mbGFncz1mYWlsZWQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29u
ZnRlc3QuJGFjX2V4dAorCisgICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgorCisgICAgTERGTEFH
Uz0iJHNhdmVkX0xERkxBR1MiCiAKKyAgICBMSUJTPSIkc2F2ZWRfTElCUyIKIAotJGFzX2VjaG8g
IiNkZWZpbmUgcmVhbGxvYyBycGxfcmVhbGxvYyIgPj5jb25mZGVmcy5oCiAKIGZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRf
ZmxhZ3MiID4mNQorJGFzX2VjaG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7IH0KKyAgICBp
ZiB0ZXN0ICJ4JGF4X2N2X3B0aHJlYWRfZmxhZ3MiID0geGZhaWxlZDsgdGhlbgorICAgICAgICBh
c19mbl9lcnJvciAkPyAiLXB0aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKKyAgICBm
aQorCisgICAgUFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgorICAgIFBUSFJF
QURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MSUJTPSIiCisK
IAogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciB3b3JraW5nIHN0cm5sZW4iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcg
c3Rybmxlbi4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX3N0cm5sZW5fd29ya2lu
ZytzZXR9IiA9IHNldDsgdGhlbiA6CitBWF9DSEVDS19QVFlGVU5DUworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlh
amwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4u
ICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3Rybmxlbl93
b3JraW5nPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx5YWpsICAkTElC
UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0CisKKy8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj
YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu
IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor
I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgeWFqbF9hbGxvYyAo
KTsKIGludAogbWFpbiAoKQogewotCi0jZGVmaW5lIFMgImZvb2JhciIKLSNkZWZpbmUgU19MRU4g
KHNpemVvZiBTIC0gMSkKLQotICAvKiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gaXMgYnVn
Z3k6IHRoYXQgb2YgQUlYIDQuMyB3b3VsZAotICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMu
ICAqLwotCi0gIGludCBpOwotICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCi0gICAg
ewotICAgICAgaW50IGV4cGVjdGVkID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsKLSAgICAgIGlm
IChzdHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKLQlyZXR1cm4gMTsKLSAgICB9Ci0gIHJldHVy
biAwOwotCityZXR1cm4geWFqbF9hbGxvYyAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VP
RgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3Ry
bmxlbl93b3JraW5nPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgor
ICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcwogZWxzZQotICBhY19jdl9mdW5jX3N0cm5s
ZW5fd29ya2luZz1ubworICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPW5vCiBmaQotcm0gLWYg
Y29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19l
eGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAg
Y29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlMKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQorJGFzX2VjaG8gIiRhY19jdl9s
aWJfeWFqbF95YWpsX2FsbG9jIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3lhamxfeWFq
bF9hbGxvYyIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIEhBVkVfTElCWUFKTCAxCitfQUNFT0YKIAotZmkKLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmci
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyIgPiY2OyB9Ci10ZXN0
ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyA9IG5vICYmIGNhc2UgIiAkTElCT0JKUyAiIGlu
Ci0gICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpT
IHN0cm5sZW4uJGFjX29iamV4dCIKLSA7OwotZXNhYworICBMSUJTPSItbHlhamwgJExJQlMiCiAK
K2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwiICIkTElORU5PIiA1
CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciB3b3JraW5nIHN0cnRvZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2lu
ZyBzdHJ0b2QuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19zdHJ0b2Qrc2V0fSIg
PSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBkZWZsYXRlQ29weSBpbiAtbHouLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6
Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElC
Uz0iLWx6ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSNpZm5k
ZWYgc3RydG9kCi1kb3VibGUgc3RydG9kICgpOworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5h
bCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBt
aWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4g
aXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19j
cGx1c3BsdXMKK2V4dGVybiAiQyIKICNlbmRpZgorY2hhciBkZWZsYXRlQ29weSAoKTsKIGludAot
bWFpbigpCittYWluICgpCiB7Ci0gIHsKLSAgICAvKiBTb21lIHZlcnNpb25zIG9mIExpbnV4IHN0
cnRvZCBtaXMtcGFyc2Ugc3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KLSAgICBjaGFyICpz
dHJpbmcgPSAiICs2OSI7Ci0gICAgY2hhciAqdGVybTsKLSAgICBkb3VibGUgdmFsdWU7Ci0gICAg
dmFsdWUgPSBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOwotICAgIGlmICh2YWx1ZSAhPSA2OSB8fCB0
ZXJtICE9IChzdHJpbmcgKyA0KSkKLSAgICAgIHJldHVybiAxOwotICB9Ci0KLSAgewotICAgIC8q
IFVuZGVyIFNvbGFyaXMgMi40LCBzdHJ0b2QgcmV0dXJucyB0aGUgd3JvbmcgdmFsdWUgZm9yIHRo
ZQotICAgICAgIHRlcm1pbmF0aW5nIGNoYXJhY3RlciB1bmRlciBzb21lIGNvbmRpdGlvbnMuICAq
LwotICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOwotICAgIGNoYXIgKnRlcm07Ci0gICAgc3RydG9k
IChzdHJpbmcsICZ0ZXJtKTsKLSAgICBpZiAodGVybSAhPSBzdHJpbmcgJiYgKih0ZXJtIC0gMSkg
PT0gMCkKLSAgICAgIHJldHVybiAxOwotICB9CityZXR1cm4gZGVmbGF0ZUNvcHkgKCk7CisgIDsK
ICAgcmV0dXJuIDA7CiB9Ci0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKIGVsc2UKLSAgYWNf
Y3ZfZnVuY19zdHJ0b2Q9bm8KLWZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0Liog
Z21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X2xpYl96X2RlZmxhdGVD
b3B5PW5vCiBmaQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hl
Y2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNQotJGFzX2VjaG8gIiRhY19jdl9m
dW5jX3N0cnRvZCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRvZCA9IG5vOyB0aGVu
Ci0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIHN0cnRvZC4kYWNfb2JqZXh0ICIqICkgOzsK
LSAgKikgTElCT0JKUz0iJExJQk9CSlMgc3RydG9kLiRhY19vYmpleHQiCi0gOzsKLWVzYWMKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfel9kZWZsYXRlQ29weSIg
PiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA9IHgiInllczsgdGhl
biA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJaIDEKK19B
Q0VPRgogCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJwb3ciICJhY19jdl9mdW5jX3Bv
dyIKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19wb3ciID0geCIieWVzOyB0aGVuIDoKKyAgTElCUz0i
LWx6ICRMSUJTIgogCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB6bGli
IiAiJExJTkVOTyIgNQogZmkKIAotaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBubzsgdGhlbgot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBw
b3cgaW4gLWxtIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBwb3cgaW4gLWxtLi4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9tX3BvdytzZXR9IiA9IHNldDsgdGhlbiA6Cit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsaWJp
Y29udl9vcGVuIGluIC1saWNvbnYiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGxpYmlj
b252X29wZW4gaW4gLWxpY29udi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfaWNv
bnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CiBlbHNlCiAgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1s
bSAgJExJQlMiCitMSUJTPSItbGljb252ICAkTElCUyIKIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIApAQCAtOTMxOSw1
NSArNjM0NSw0NSBAQCBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CiAjaWZkZWYgX19jcGx1c3BsdXMKIGV4dGVybiAiQyIKICNlbmRpZgotY2hhciBwb3cgKCk7Citj
aGFyIGxpYmljb252X29wZW4gKCk7CiBpbnQKIG1haW4gKCkKIHsKLXJldHVybiBwb3cgKCk7City
ZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgogaWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbV9wb3c9eWVz
CisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwogZWxzZQotICBhY19jdl9saWJf
bV9wb3c9bm8KKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KIGZpCiBybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKICAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAogTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX21fcG93IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX21fcG93IiA+JjY7IH0KLWlmIHRl
c3QgIngkYWNfY3ZfbGliX21fcG93IiA9IHgiInllczsgdGhlbiA6Ci0gIFBPV19MSUI9LWxtCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xp
Yl9pY29udl9saWJpY29udl9vcGVuIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2ljb252X2xp
Ymljb252X29wZW4iID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZf
b3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJpY29udj0ieSIKIGVsc2UKLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJy
YXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mNQotJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRlZmluaXRpb24gb2YgcG93
IiA+JjI7fQotZmkKLQorICBsaWJpY29udj0ibiIKIGZpCiAKLWZpCiAKLWZvciBhY19mdW5jIGlu
ICBcCi0gICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVw
MiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKLSAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5
bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAotICAgICAgICAgICAg
ICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3ZlIG1lbXNldCBt
a2RpciBcCi0gICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0aCBy
ZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAotICAgICAgICAgICAgICAgIHNvY2tldCBzdHJj
YXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKLSAgICAgICAg
ICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0
b3VsbCB0enNldCBcCi0gICAgICAgICAgICAgICAgdW5hbWUgXAogCisjIENoZWNrcyBmb3IgaGVh
ZGVyIGZpbGVzLgorZm9yIGFjX2hlYWRlciBpbiB5YWpsL3lhamxfdmVyc2lvbi5oCiBkbyA6Ci0g
IGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAot
YWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFyIgotaWYg
ZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBhY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAieWFqbC95YWpsX3ZlcnNpb24uaCIgImFj
X2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitp
ZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiA9IHgiInllczsgdGhl
biA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZF
XyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKKyNkZWZpbmUgSEFWRV9ZQUpMX1lBSkxfVkVSU0lP
Tl9IIDEKIF9BQ0VPRgogCiBmaQorCiBkb25lCiAKIApkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmln
dXJlLmFjIGIvdG9vbHMvY29uZmlndXJlLmFjCmluZGV4IDI1MGRmZmQuLjdmZGUyZmIgMTAwNjQ0
Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYworKysgYi90b29scy9jb25maWd1cmUuYWMKQEAgLTE5
LDkgKzE5LDYgQEAgcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJ
QiwgXAogQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJs
ZS5dKQogXSkKIAotQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCi1BQ19DQU5PTklDQUxfSE9TVAot
CiAjIE00IE1hY3JvIGluY2x1ZGVzCiBtNF9pbmNsdWRlKFttNC9zYXZldmFyLm00XSkKIG00X2lu
Y2x1ZGUoW200L2ZlYXR1cmVzLm00XSkKQEAgLTcyLDkgKzY5LDcgQEAgQUNfQVJHX1ZBUihbQkND
XSwgW1BhdGggdG8gYmNjIHRvb2xdKQogQUNfQVJHX1ZBUihbSUFTTF0sIFtQYXRoIHRvIGlhc2wg
dG9vbF0pCiAKICMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KLUFDX1BST0dfU0VECiBBQ19QUk9HX0ND
Ci1BQ19QUk9HX0xOX1MKIEFDX1BST0dfTUFLRV9TRVQKIEFDX1BST0dfSU5TVEFMTAogQVhfUEFU
SF9QUk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVybF0pCkBAIC0xMzIsNyArMTI3LDcgQEAgQUNfU1VC
U1QobGliZXh0MmZzKQogQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZl
cl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQogQUNfU1VCU1QobGliZ2NyeXB0
KQogQVhfQ0hFQ0tfUFRIUkVBRAotQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1lXSkK
K0FYX0NIRUNLX1BUWUZVTkNTCiBBQ19DSEVDS19MSUIoW3lhamxdLCBbeWFqbF9hbGxvY10sIFtd
LAogICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHlhamxdKV0pCiBBQ19DSEVDS19M
SUIoW3pdLCBbZGVmbGF0ZUNvcHldLCBbXSwgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQg
emxpYl0pXSkKQEAgLTE0MCw1OCArMTM1LDYgQEAgQUNfQ0hFQ0tfTElCKFtpY29udl0sIFtsaWJp
Y29udl9vcGVuXSwgW2xpYmljb252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQogQUNfU1VCU1QobGli
aWNvbnYpCiAKICMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCi1BQ19GVU5DX0FMTE9DQQotQUNf
Q0hFQ0tfSEVBREVSUyhbIFwKLSAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGlu
dHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKLSAgICAgICAgICAgICAgICBu
ZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBc
Ci0gICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21v
dW50Lmggc3lzL3BhcmFtLmggXAotICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3Rh
dHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKLSAgICAgICAgICAgICAgICB1
bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKLSAgICAgICAgICAgICAgICBdKQotCi0jIENo
ZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3Rp
Y3MuCi1BQ19IRUFERVJfU1REQk9PTAotQUNfVFlQRV9VSURfVAotQUNfQ19JTkxJTkUKLUFDX1RZ
UEVfSU5UMTZfVAotQUNfVFlQRV9JTlQzMl9UCi1BQ19UWVBFX0lOVDY0X1QKLUFDX1RZUEVfSU5U
OF9UCi1BQ19UWVBFX01PREVfVAotQUNfVFlQRV9PRkZfVAotQUNfVFlQRV9QSURfVAotQUNfQ19S
RVNUUklDVAotQUNfVFlQRV9TSVpFX1QKLUFDX1RZUEVfU1NJWkVfVAotQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCi1BQ19TVFJVQ1RfU1RfQkxPQ0tTCi1BQ19DSEVD
S19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9yZGV2XSkKLUFDX1RZUEVfVUlOVDE2X1QKLUFDX1RZ
UEVfVUlOVDMyX1QKLUFDX1RZUEVfVUlOVDY0X1QKLUFDX1RZUEVfVUlOVDhfVAotQUNfQ0hFQ0tf
VFlQRVMoW3B0cmRpZmZfdF0pCi0KLSMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KLUFD
X0ZVTkNfRVJST1JfQVRfTElORQotQUNfRlVOQ19GT1JLCi1BQ19GVU5DX0ZTRUVLTwotQUNfRlVO
Q19MU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSwotQUNfSEVBREVSX01BSk9SCi1BQ19GVU5D
X01BTExPQwotQUNfRlVOQ19NS1RJTUUKLUFDX0ZVTkNfTU1BUAotQUNfRlVOQ19SRUFMTE9DCi1B
Q19GVU5DX1NUUk5MRU4KLUFDX0ZVTkNfU1RSVE9ECi1BQ19DSEVDS19GVU5DUyhbIFwKLSAgICAg
ICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3lu
YyBmdHJ1bmNhdGUgXAotICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhv
c3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCi0gICAgICAgICAgICAgICAgaW5ldF9u
dG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKLSAg
ICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1k
aXIgc2VsZWN0IHNldGVudiBcCi0gICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3Ry
Y2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAotICAgICAgICAgICAgICAgIHN0
cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0
IFwKLSAgICAgICAgICAgICAgICB1bmFtZSBcCi0gICAgICAgICAgICAgICAgXSkKK0FDX0NIRUNL
X0hFQURFUlMoW3lhamwveWFqbF92ZXJzaW9uLmhdKQogCiBBQ19PVVRQVVQoKQotLSAKMS43LjIu
NQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZH-0003r1-1o; Mon, 16 Apr 2012 17:18:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZA-0003g5-1d
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:17 +0000
Received: from [85.158.139.83:5776] by server-7.bemta-5.messagelabs.com id
	9F/CC-16195-7545C8F4; Mon, 16 Apr 2012 17:18:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334596693!23973070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14681 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kE-7N; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Dr-5h;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:46 +0100
Message-ID: <1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] =?utf-8?q?=5BPATCH_04/24=5D_autoconf=3A_trim_the_conf?=
	=?utf-8?q?igure_script=3B_use_autoheader?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVtb3ZlIGEgbG90IG9mIHVubmVjZXNzYXJ5IHRlc3RzLiAgU3BlY2lmaWNhbGx5LCB3ZSBubyBs
b25nZXIgdGVzdApmb3Igc3RhbmRhcmQgUE9TSVggZmFjaWxpdGllcyB3aGljaCB3ZSBleHBlY3Qg
dG8gYmUgcHJvdmlkZWQKZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNhc2Ug
aGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgoKU3dpdGNoIHRvIGdlbmVyYXRpbmcgY29uZmlnLmgu
aW4gd2l0aCBhdXRvaGVhZGVyLgoKU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNr
c29uQGV1LmNpdHJpeC5jb20+CkNjOiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51
cGMuZWR1PgotLS0KIGF1dG9nZW4uc2ggICAgICAgICB8ICAgIDEgKwogdG9vbHMvY29uZmlnLmgu
aW4gIHwgICA3MyArLQogdG9vbHMvY29uZmlndXJlICAgIHwgODYwNCArKysrKysrKysrKysrKysr
Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiB0b29scy9jb25maWd1cmUuYWMg
fCAgIDYxICstCiA0IGZpbGVzIGNoYW5nZWQsIDI4NzIgaW5zZXJ0aW9ucygrKSwgNTg2NyBkZWxl
dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hdXRvZ2VuLnNoIGIvYXV0b2dlbi5zaAppbmRleCBjMjg4
YjcxLi41OGE3MWNlIDEwMDc1NQotLS0gYS9hdXRvZ2VuLnNoCisrKyBiL2F1dG9nZW4uc2gKQEAg
LTEsMyArMSw0IEBACiAjIS9iaW4vc2ggLWUKIGNkIHRvb2xzCiBhdXRvY29uZgorYXV0b2hlYWRl
cgpkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlnLmguaW4gYi90b29scy9jb25maWcuaC5pbgppbmRl
eCBmOGY5NmRjLi4xN2M4OTEzIDEwMDY0NAotLS0gYS90b29scy9jb25maWcuaC5pbgorKysgYi90
b29scy9jb25maWcuaC5pbgpAQCAtMSwxOSArMSw2NCBAQAotLyoKLSAqIENvcHlyaWdodCAoQykg
MjAxMgotICoKLSAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlz
dHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5Ci0gKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdO
VSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQKLSAqIGJ5IHRoZSBG
cmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IHZlcnNpb24gMi4xIG9ubHkuIHdpdGggdGhlIHNwZWNp
YWwKLSAqIGV4Y2VwdGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBpbiBmaWxlIExJQ0VOU0UuCi0g
KgotICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2ls
bCBiZSB1c2VmdWwsCi0gKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgotICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9S
IEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQotICogR05VIExlc3NlciBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCi0gKi8KKy8qIGNvbmZpZy5oLmluLiAgR2Vu
ZXJhdGVkIGZyb20gY29uZmlndXJlLmFjIGJ5IGF1dG9oZWFkZXIuICAqLworCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGludHR5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVm
IEhBVkVfSU5UVFlQRVNfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGNyeXB0
bycgbGlicmFyeSAoLWxjcnlwdG8pLiAqLworI3VuZGVmIEhBVkVfTElCQ1JZUFRPCisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgeWFqbCcgbGlicmFyeSAoLWx5YWpsKS4gKi8KKyN1
bmRlZiBIQVZFX0xJQllBSkwKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB6JyBs
aWJyYXJ5ICgtbHopLiAqLworI3VuZGVmIEhBVkVfTElCWgorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPG1lbW9yeS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01FTU9S
WV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkaW50Lmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfU1RESU5UX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzdGRsaWIuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERMSUJfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0cmluZ3MuaD4gaGVhZGVyIGZpbGUu
ICovCisjdW5kZWYgSEFWRV9TVFJJTkdTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDxzdHJpbmcuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVFJJTkdfSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0Lmg+IGhlYWRlciBmaWxlLiAq
LworI3VuZGVmIEhBVkVfU1lTX1NUQVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN5cy90eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19UWVBFU19I
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8dW5pc3RkLmg+IGhlYWRlciBmaWxl
LiAqLworI3VuZGVmIEhBVkVfVU5JU1REX0gKIAogLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDx5YWpsL3lhamxfdmVyc2lvbi5oPiBoZWFkZXIgZmlsZS4gKi8KICN1bmRlZiBIQVZFX1lB
SkxfWUFKTF9WRVJTSU9OX0gKIAotLyogRGVmaW5lIGN1cnNlcyBoZWFkZXIgdG8gaW5jbHVkZS4g
Ki8KKy8qIERlZmluZSBjdXJzZXMgaGVhZGVyIHRvIHVzZSAqLwogI3VuZGVmIElOQ0xVREVfQ1VS
U0VTX0gKKworLyogRGVmaW5lIHRvIHRoZSBhZGRyZXNzIHdoZXJlIGJ1ZyByZXBvcnRzIGZvciB0
aGlzIHBhY2thZ2Ugc2hvdWxkIGJlIHNlbnQuICovCisjdW5kZWYgUEFDS0FHRV9CVUdSRVBPUlQK
KworLyogRGVmaW5lIHRvIHRoZSBmdWxsIG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVm
IFBBQ0tBR0VfTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFtZSBhbmQgdmVyc2lvbiBv
ZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9TVFJJTkcKKworLyogRGVmaW5lIHRv
IHRoZSBvbmUgc3ltYm9sIHNob3J0IG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBB
Q0tBR0VfVEFSTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGhvbWUgcGFnZSBmb3IgdGhpcyBwYWNr
YWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfVVJMCisKKy8qIERlZmluZSB0byB0aGUgdmVyc2lvbiBv
ZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9WRVJTSU9OCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSBBTlNJIEMgaGVhZGVyIGZpbGVzLiAqLworI3VuZGVmIFNURENf
SEVBREVSUwpkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlndXJlIGIvdG9vbHMvY29uZmlndXJlCmlu
ZGV4IDg2NjE4ZjUuLjg3NjVmMjAgMTAwNzU1Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZQorKysgYi90
b29scy9jb25maWd1cmUKQEAgLTU5NSwxMiArNTk1LDggQEAgYWNfaW5jbHVkZXNfZGVmYXVsdD0i
XAogIyBpbmNsdWRlIDx1bmlzdGQuaD4KICNlbmRpZiIKIAotYWNfaGVhZGVyX2xpc3Q9Ci1hY19m
dW5jX2xpc3Q9CiBhY19zdWJzdF92YXJzPSdMVExJQk9CSlMKLVBPV19MSUIKIExJQk9CSlMKLUFM
TE9DQQogbGliaWNvbnYKIFBUSFJFQURfTElCUwogUFRIUkVBRF9MREZMQUdTCkBAIC02MTYsNiAr
NjEyLDkgQEAgUEtHX0NPTkZJR19MSUJESVIKIFBLR19DT05GSUdfUEFUSAogUEtHX0NPTkZJRwog
Q1VSU0VTX0xJQlMKK0VHUkVQCitHUkVQCitDUFAKIFBZVEhPTlBBVEgKIE9DQU1MQlVJTEQKIE9D
QU1MRE9DCkBAIC02MzQsOCArNjMzLDEzIEBAIElOU1RBTExfREFUQQogSU5TVEFMTF9TQ1JJUFQK
IElOU1RBTExfUFJPR1JBTQogU0VUX01BS0UKLUxOX1MKLVNFRAorT0JKRVhUCitFWEVFWFQKK2Fj
X2N0X0NDCitDUFBGTEFHUworTERGTEFHUworQ0ZMQUdTCitDQwogSUFTTAogQkNDCiBMRDg2CkBA
IC02NjEsMjQgKzY2NSw2IEBAIHhlbmFwaQogdnRwbQogbW9uaXRvcnMKIGdpdGh0dHAKLWhvc3Rf
b3MKLWhvc3RfdmVuZG9yCi1ob3N0X2NwdQotaG9zdAotYnVpbGRfb3MKLWJ1aWxkX3ZlbmRvcgot
YnVpbGRfY3B1Ci1idWlsZAotRUdSRVAKLUdSRVAKLUNQUAotT0JKRVhUCi1FWEVFWFQKLWFjX2N0
X0NDCi1DUFBGTEFHUwotTERGTEFHUwotQ0ZMQUdTCi1DQwogdGFyZ2V0X2FsaWFzCiBob3N0X2Fs
aWFzCiBidWlsZF9hbGlhcwpAQCAtNzMzLDEyICs3MTksNiBAQCBlbmFibGVfZGVidWcKICAgICAg
IGFjX3ByZWNpb3VzX3ZhcnM9J2J1aWxkX2FsaWFzCiBob3N0X2FsaWFzCiB0YXJnZXRfYWxpYXMK
LUNDCi1DRkxBR1MKLUxERkxBR1MKLUxJQlMKLUNQUEZMQUdTCi1DUFAKIFBSRVBFTkRfSU5DTFVE
RVMKIFBSRVBFTkRfTElCCiBBUFBFTkRfSU5DTFVERVMKQEAgLTc1NSw2ICs3MzUsMTIgQEAgQVM4
NgogTEQ4NgogQkNDCiBJQVNMCitDQworQ0ZMQUdTCitMREZMQUdTCitMSUJTCitDUFBGTEFHUwor
Q1BQCiBQS0dfQ09ORklHCiBQS0dfQ09ORklHX1BBVEgKIFBLR19DT05GSUdfTElCRElSCkBAIC0x
MzU4LDEwICsxMzQ0LDYgQEAgRmluZSB0dW5pbmcgb2YgdGhlIGluc3RhbGxhdGlvbiBkaXJlY3Rv
cmllczoKIF9BQ0VPRgogCiAgIGNhdCA8PFxfQUNFT0YKLQotU3lzdGVtIHR5cGVzOgotICAtLWJ1
aWxkPUJVSUxEICAgICBjb25maWd1cmUgZm9yIGJ1aWxkaW5nIG9uIEJVSUxEIFtndWVzc2VkXQot
ICAtLWhvc3Q9SE9TVCAgICAgICBjcm9zcy1jb21waWxlIHRvIGJ1aWxkIHByb2dyYW1zIHRvIHJ1
biBvbiBIT1NUIFtCVUlMRF0KIF9BQ0VPRgogZmkKIApAQCAtMTM4OSwxNCArMTM3MSw2IEBAIE9w
dGlvbmFsIEZlYXR1cmVzOgogICAtLWRpc2FibGUtZGVidWcgICAgICAgICBEaXNhYmxlIGRlYnVn
IGJ1aWxkIG9mIHRvb2xzIChkZWZhdWx0IGlzIEVOQUJMRUQpCiAKIFNvbWUgaW5mbHVlbnRpYWwg
ZW52aXJvbm1lbnQgdmFyaWFibGVzOgotICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQK
LSAgQ0ZMQUdTICAgICAgQyBjb21waWxlciBmbGFncwotICBMREZMQUdTICAgICBsaW5rZXIgZmxh
Z3MsIGUuZy4gLUw8bGliIGRpcj4gaWYgeW91IGhhdmUgbGlicmFyaWVzIGluIGEKLSAgICAgICAg
ICAgICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgotICBMSUJTICAgICAgICBsaWJy
YXJpZXMgdG8gcGFzcyB0byB0aGUgbGlua2VyLCBlLmcuIC1sPGxpYnJhcnk+Ci0gIENQUEZMQUdT
ICAgIChPYmplY3RpdmUpIEMvQysrIHByZXByb2Nlc3NvciBmbGFncywgZS5nLiAtSTxpbmNsdWRl
IGRpcj4gaWYKLSAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5kYXJk
IGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+Ci0gIENQUCAgICAgICAgIEMgcHJlcHJvY2Vzc29yCiAg
IFBSRVBFTkRfSU5DTFVERVMKICAgICAgICAgICAgICAgTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMg
dG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCiAgIFBSRVBFTkRfTElCIExpc3Qgb2Yg
bGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCkKQEAgLTE0
MTUsNiArMTM4OSwxNCBAQCBTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoK
ICAgTEQ4NiAgICAgICAgUGF0aCB0byBsZDg2IHRvb2wKICAgQkNDICAgICAgICAgUGF0aCB0byBi
Y2MgdG9vbAogICBJQVNMICAgICAgICBQYXRoIHRvIGlhc2wgdG9vbAorICBDQyAgICAgICAgICBD
IGNvbXBpbGVyIGNvbW1hbmQKKyAgQ0ZMQUdTICAgICAgQyBjb21waWxlciBmbGFncworICBMREZM
QUdTICAgICBsaW5rZXIgZmxhZ3MsIGUuZy4gLUw8bGliIGRpcj4gaWYgeW91IGhhdmUgbGlicmFy
aWVzIGluIGEKKyAgICAgICAgICAgICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgor
ICBMSUJTICAgICAgICBsaWJyYXJpZXMgdG8gcGFzcyB0byB0aGUgbGlua2VyLCBlLmcuIC1sPGxp
YnJhcnk+CisgIENQUEZMQUdTICAgIChPYmplY3RpdmUpIEMvQysrIHByZXByb2Nlc3NvciBmbGFn
cywgZS5nLiAtSTxpbmNsdWRlIGRpcj4gaWYKKyAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVy
cyBpbiBhIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+CisgIENQUCAgICAgICAg
IEMgcHJlcHJvY2Vzc29yCiAgIFBLR19DT05GSUcgIHBhdGggdG8gcGtnLWNvbmZpZyB1dGlsaXR5
CiAgIFBLR19DT05GSUdfUEFUSAogICAgICAgICAgICAgICBkaXJlY3RvcmllcyB0byBhZGQgdG8g
cGtnLWNvbmZpZydzIHNlYXJjaCBwYXRoCkBAIC0xNzg3LDMxMSArMTc2OSw2IEBAIGZpCiAgIGFz
X2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAogCiB9ICMgYWNfZm5fY190cnlfbGluawotCi0jIGFj
X2ZuX2NfY2hlY2tfZnVuYyBMSU5FTk8gRlVOQyBWQVIKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQotIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3RzLCBzZXR0aW5nIHRoZSBj
YWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkKLWFjX2ZuX2NfY2hlY2tfZnVuYyAoKQotewot
ICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19z
dGFjaz0kYXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
Mi4uLiAiID4mNjsgfQotaWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4g
OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0vKiBE
ZWZpbmUgJDIgdG8gYW4gaW5ub2N1b3VzIHZhcmlhbnQsIGluIGNhc2UgPGxpbWl0cy5oPiBkZWNs
YXJlcyAkMi4KLSAgIEZvciBleGFtcGxlLCBIUC1VWCAxMWkgPGxpbWl0cy5oPiBkZWNsYXJlcyBn
ZXR0aW1lb2ZkYXkuICAqLwotI2RlZmluZSAkMiBpbm5vY3VvdXNfJDIKLQotLyogU3lzdGVtIGhl
YWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVz
LAotICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgJDIgKCk7IGJlbG93LgotICAgIFBy
ZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2lu
Y2UKLSAgICA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMu
ICAqLwotCi0jaWZkZWYgX19TVERDX18KLSMgaW5jbHVkZSA8bGltaXRzLmg+Ci0jZWxzZQotIyBp
bmNsdWRlIDxhc3NlcnQuaD4KLSNlbmRpZgotCi0jdW5kZWYgJDIKLQotLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
Ci0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciAkMiAoKTsKLS8q
IFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGlt
cGxlbWVudHMKLSAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25z
IGFyZSBhY3R1YWxseSBuYW1lZAotICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0
aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLwotI2lmIGRlZmluZWQgX19zdHViXyQyIHx8
IGRlZmluZWQgX19zdHViX19fJDIKLWNob2tlIG1lCi0jZW5kaWYKLQotaW50Ci1tYWluICgpCi17
Ci1yZXR1cm4gJDIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgZXZhbCAiJDM9eWVzIgotZWxzZQotICBldmFs
ICIkMz1ubyIKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLWV2YWwgYWNf
cmVzPVwkJDMKLQkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFs
ICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19s
aW5lbm89OyB1bnNldCBhc19saW5lbm87fQotCi19ICMgYWNfZm5fY19jaGVja19mdW5jCi0KLSMg
YWNfZm5fY19jaGVja190eXBlIExJTkVOTyBUWVBFIFZBUiBJTkNMVURFUwotIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFRlc3RzIHdoZXRoZXIgVFlQRSBl
eGlzdHMgYWZ0ZXIgaGF2aW5nIGluY2x1ZGVkIElOQ0xVREVTLCBzZXR0aW5nIGNhY2hlCi0jIHZh
cmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KLWFjX2ZuX2NfY2hlY2tfdHlwZSAoKQotewotICBhc19s
aW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0k
YXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICQyIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4uLiAi
ID4mNjsgfQotaWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBldmFsICIkMz1ubyIKLSAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwotJDQKLWludAotbWFpbiAoKQotewotaWYgKHNpemVvZiAoJDIpKQotCSByZXR1cm4gMDsK
LSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kNAotaW50Ci1tYWluICgpCi17Ci1pZiAoc2l6
ZW9mICgoJDIpKSkKLQkgICAgcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YK
LWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQotICBldmFs
ICIkMz15ZXMiCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotZXZhbCBhY19yZXM9XCQkMwotCSAgICAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3Jl
cyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFj
azsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFz
X2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2NoZWNrX3R5cGUKLQotIyBhY19mbl9jX2ZpbmRfaW50
WF90IExJTkVOTyBCSVRTIFZBUgotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQotIyBGaW5kcyBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0aCBCSVRTLCBzZXR0aW5n
IGNhY2hlIHZhcmlhYmxlIFZBUgotIyBhY2NvcmRpbmdseS4KLWFjX2ZuX2NfZmluZF9pbnRYX3Qg
KCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19s
aW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpbnQkMl90IiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBpbnQkMl90Li4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0
fVwiIiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0g
IGV2YWwgIiQzPW5vIgotICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAtIG5ldmVyIGNoZWNrIGEg
dHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKLSAgICAgIyB0aGFuIGhhbGYgb2YgdGhl
IGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KLSAgICAgZm9yIGFjX3R5cGUgaW4gaW50JDJfdCAnaW50
JyAnbG9uZyBpbnQnIFwKLQkgJ2xvbmcgbG9uZyBpbnQnICdzaG9ydCBpbnQnICdzaWduZWQgY2hh
cic7IGRvCi0gICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLQkgICAgIGVu
dW0geyBOID0gJDIgLyAyIC0gMSB9OwotaW50Ci1tYWluICgpCi17Ci1zdGF0aWMgaW50IHRlc3Rf
YXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4pIDw8
IE4pIC0gMSkgKiAyICsgMSkpXTsKLXRlc3RfYXJyYXkgWzBdID0gMAotCi0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLQkgICAgICAgIGVudW0geyBOID0g
JDIgLyAyIC0gMSB9OwotaW50Ci1tYWluICgpCi17Ci1zdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEg
LSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIg
KyAxKQotCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwgTikgLSAxKSAq
IDIgKyAyKSldOwotdGVzdF9hcnJheSBbMF0gPSAwCi0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9B
Q0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotCi1lbHNlCi0g
IGNhc2UgJGFjX3R5cGUgaW4gIygKLSAgaW50JDJfdCkgOgotICAgIGV2YWwgIiQzPXllcyIgOzsg
IygKLSAgKikgOgotICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKLWVzYWMKLWZpCi1ybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKLSAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6Ci0K
LWVsc2UKLSAgYnJlYWsKLWZpCi0gICAgIGRvbmUKLWZpCi1ldmFsIGFjX3Jlcz1cJCQzCi0JICAg
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
cmVzIiA+JjUKLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0
YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQg
YXNfbGluZW5vO30KLQotfSAjIGFjX2ZuX2NfZmluZF9pbnRYX3QKLQotIyBhY19mbl9jX2NoZWNr
X21lbWJlciBMSU5FTk8gQUdHUiBNRU1CRVIgVkFSIElOQ0xVREVTCi0jIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgVHJpZXMgdG8gZmluZCBp
ZiB0aGUgZmllbGQgTUVNQkVSIGV4aXN0cyBpbiB0eXBlIEFHR1IsIGFmdGVyIGluY2x1ZGluZwot
IyBJTkNMVURFUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCi1hY19m
bl9jX2NoZWNrX21lbWJlciAoKQotewotICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNf
bGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyLiQzIiA+JjUK
LSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4kMy4uLiAiID4mNjsgfQotaWYgZXZhbCAidGVz
dCBcIlwkeyQ0K3NldH1cIiIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kNQotaW50Ci1tYWluICgpCi17Ci1zdGF0aWMgJDIg
YWNfYWdncjsKLWlmIChhY19hZ2dyLiQzKQotcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19
Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgZXZh
bCAiJDQ9eWVzIgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kNQotaW50Ci1tYWluICgpCi17Ci1zdGF0
aWMgJDIgYWNfYWdncjsKLWlmIChzaXplb2YgYWNfYWdnci4kMykKLXJldHVybiAwOwotICA7Ci0g
IHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0gIGV2YWwgIiQ0PXllcyIKLWVsc2UKLSAgZXZhbCAiJDQ9bm8iCi1maQotcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1m
aQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0Ci1maQotZXZhbCBhY19yZXM9XCQkNAotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFj
X3JlcyIgPiY2OyB9Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9f
c3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19m
bl9jX2NoZWNrX21lbWJlcgotCi0jIGFjX2ZuX2NfZmluZF91aW50WF90IExJTkVOTyBCSVRTIFZB
UgotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgRmluZHMgYW4gdW5z
aWduZWQgaW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJs
ZSBWQVIKLSMgYWNjb3JkaW5nbHkuCi1hY19mbl9jX2ZpbmRfdWludFhfdCAoKQotewotICBhc19s
aW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0k
YXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHVpbnQkMl90IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB1
aW50JDJfdC4uLiAiID4mNjsgfQotaWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBldmFsICIkMz1u
byIKLSAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhhdCBp
cyBwb3RlbnRpYWxseSBzbWFsbGVyCi0gICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3RlZCB0
YXJnZXQgd2lkdGguCi0gICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90ICd1bnNpZ25lZCBpbnQn
ICd1bnNpZ25lZCBsb25nIGludCcgXAotCSAndW5zaWduZWQgbG9uZyBsb25nIGludCcgJ3Vuc2ln
bmVkIHNob3J0IGludCcgJ3Vuc2lnbmVkIGNoYXInOyBkbwotICAgICAgIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRh
Y19pbmNsdWRlc19kZWZhdWx0Ci1pbnQKLW1haW4gKCkKLXsKLXN0YXRpYyBpbnQgdGVzdF9hcnJh
eSBbMSAtIDIgKiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8gMiAt
IDEpID09IDMpXTsKLXRlc3RfYXJyYXkgWzBdID0gMAotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1f
QUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgY2FzZSAk
YWNfdHlwZSBpbiAjKAotICB1aW50JDJfdCkgOgotICAgIGV2YWwgIiQzPXllcyIgOzsgIygKLSAg
KikgOgotICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKLWVzYWMKLWZpCi1ybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgICAgICBp
ZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6Ci0KLWVsc2UKLSAgYnJlYWsK
LWZpCi0gICAgIGRvbmUKLWZpCi1ldmFsIGFjX3Jlcz1cJCQzCi0JICAgICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19l
Y2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFz
X2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KLQot
fSAjIGFjX2ZuX2NfZmluZF91aW50WF90CiBjYXQgPmNvbmZpZy5sb2cgPDxfQUNFT0YKIFRoaXMg
ZmlsZSBjb250YWlucyBhbnkgbWVzc2FnZXMgcHJvZHVjZWQgYnkgY29tcGlsZXJzIHdoaWxlCiBy
dW5uaW5nIGNvbmZpZ3VyZSwgdG8gYWlkIGRlYnVnZ2luZyBpZiBjb25maWd1cmUgbWFrZXMgYSBt
aXN0YWtlLgpAQCAtMjM3NiwxMSArMjA1Myw2IEBAICRhc19lY2hvICIkYXNfbWU6IGNyZWF0aW5n
IGNhY2hlICRjYWNoZV9maWxlIiA+JjY7fQogICA+JGNhY2hlX2ZpbGUKIGZpCiAKLWFzX2ZuX2Fw
cGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy90aW1lLmgiCi1hc19mbl9hcHBlbmQgYWNfaGVhZGVy
X2xpc3QgIiB1bmlzdGQuaCIKLWFzX2ZuX2FwcGVuZCBhY19mdW5jX2xpc3QgIiBhbGFybSIKLWFz
X2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN0ZGxpYi5oIgotYXNfZm5fYXBwZW5kIGFjX2hl
YWRlcl9saXN0ICIgc3lzL3BhcmFtLmgiCiAjIENoZWNrIHRoYXQgdGhlIHByZWNpb3VzIHZhcmlh
YmxlcyBzYXZlZCBpbiB0aGUgY2FjaGUgaGF2ZSBrZXB0IHRoZSBzYW1lCiAjIHZhbHVlLgogYWNf
Y2FjaGVfY29ycnVwdGVkPWZhbHNlCkBAIC0yNDk4LDE2NjEgKzIxNzAsMzUgQEAgQVBQRU5EX0lO
Q0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS4iID4mMjt9CiAKIGZp
CiAKLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29tcGlsZT0nJENDIC1j
ICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNfbGluaz0nJENDIC1v
IGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4k
YWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUK
LWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9
JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgot
ICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgot
ZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBp
biAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2MiCi0gICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZT
Ci0KLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1
Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1m
aQotCi0KLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KLSAgYWNfY3RfQ0M9
JENDCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKLXsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3Jk
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYg
dGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhl
bgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgotICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZl
X0lGUwotCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1pZiB0ZXN0IC1u
ICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9
Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotICBpZiB0ZXN0ICJ4JGFjX2N0
X0NDIiA9IHg7IHRoZW4KLSAgICBDQz0iIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xf
d2FybmVkPXllcyA7OwotZXNhYwotICAgIENDPSRhY19jdF9DQwotICBmaQotZWxzZQotICBDQz0i
JGFjX2N2X3Byb2dfQ0MiCi1maQotCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gICAgICAgICAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1jYzsgYWNfd29yZD0k
MgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0g
IGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1l
bHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGlu
ICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFz
X2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg
JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh
Y19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgotICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwot
Ci1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQot
JGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkK
LQotCi0gIGZpCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
LXNldCBkdW1teSBjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi0gIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRv
Ci0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGlmIHRlc3QgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgotICAgICAg
IGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCi0gICAgICAgY29udGludWUKLSAgICAgZmkKLSAgICBhY19j
dl9wcm9nX0NDPSJjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0g
IGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotaWYgdGVzdCAkYWNfcHJvZ19y
ZWplY3RlZCA9IHllczsgdGhlbgotICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBhdGgsIHNv
IG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCi0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwot
ICBzaGlmdAotICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KLSAgICAjIFdlIGNob3NlIGEgZGlmZmVy
ZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KLSAgICAjIEhvd2V2ZXIsIGl0IGhhcyB0
aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCi0gICAgIyBmaXJz
dCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVsbCBmaWxlIG5h
bWUuCi0gICAgc2hpZnQKLSAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193b3JkJHsxKycg
J30kQCIKLSAgZmkKLWZpCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAi
bm8iID4mNjsgfQotZmkKLQotCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotICBk
bwotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3By
b2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRh
Y190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1l
bHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2
ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3By
ZWZpeCRhY19wcm9nIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAg
ZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1maQotZmkKLUNDPSRhY19jdl9w
cm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9
Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotCi0gICAgdGVzdCAtbiAiJEND
IiAmJiBicmVhawotICBkb25lCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBhY19jdF9D
Qz0kQ0MKLSAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCi1kbwotICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KLXNldCBkdW1teSAkYWNfcHJvZzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By
b2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2df
YWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1l
bHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGlu
ICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFz
X2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg
JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh
Y19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfcHJvZyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
LSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkK
LWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQwotaWYgdGVzdCAtbiAiJGFjX2N0X0ND
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X0NDIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQotZWxzZQotICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQot
JGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCi0KLQotICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJy
ZWFrCi1kb25lCi0KLSAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIK
LSAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXll
czopCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBD
Qz0kYWNfY3RfQ0MKLSAgZmkKLWZpCi0KLWZpCi0KLQotdGVzdCAteiAiJENDIiAmJiB7IHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6
IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KLWFz
X2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQQVRICi1T
ZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KLQotIyBQ
cm92aWRlIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgotJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgdmVyc2lv
biIgPiY1Ci1zZXQgWCAkYWNfY29tcGlsZQotYWNfY29tcGlsZXI9JDIKLWZvciBhY19vcHRpb24g
aW4gLS12ZXJzaW9uIC12IC1WIC1xdmVyc2lvbjsgZG8KLSAgeyB7IGFjX3RyeT0iJGFjX2NvbXBp
bGVyICRhY19vcHRpb24gPiY1IgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8
ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7
Ci1lc2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
ICRhY190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFs
ICIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgotICBhY19zdGF0
dXM9JD8KLSAgaWYgdGVzdCAtcyBjb25mdGVzdC5lcnI7IHRoZW4KLSAgICBzZWQgJzEwYVwKLS4u
LiByZXN0IG9mIHN0ZGVyciBvdXRwdXQgZGVsZXRlZCAuLi4KLSAgICAgICAgIDEwcScgY29uZnRl
c3QuZXJyID5jb25mdGVzdC5lcjEKLSAgICBjYXQgY29uZnRlc3QuZXIxID4mNQotICBmaQotICBy
bSAtZiBjb25mdGVzdC5lcjEgY29uZnRlc3QuZXJyCi0gICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMg
PSAwOyB9Ci1kb25lCi0KLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICBy
ZXR1cm4gMDsKLX0KLV9BQ0VPRgotYWNfY2xlYW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMK
LWFjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5fZmlsZXMgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBi
Lm91dCIKLSMgVHJ5IHRvIGNyZWF0ZSBhbiBleGVjdXRhYmxlIHdpdGhvdXQgLW8gZmlyc3QsIGRp
c3JlZ2FyZCBhLm91dC4KLSMgSXQgd2lsbCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBjb21waWxl
cnMsIGFuZCBmaW5kaW5nIG91dCBhbiBpbnR1aXRpb24KLSMgb2YgZXhlZXh0LgoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv
bXBpbGVyIHdvcmtzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29t
cGlsZXIgd29ya3MuLi4gIiA+JjY7IH0KLWFjX2xpbmtfZGVmYXVsdD1gJGFzX2VjaG8gIiRhY19s
aW5rIiB8IHNlZCAncy8gLW8gKmNvbmZ0ZXN0W14gXSovLydgCi0KLSMgVGhlIHBvc3NpYmxlIG91
dHB1dCBmaWxlczoKLWFjX2ZpbGVzPSJhLm91dCBjb25mdGVzdC5leGUgY29uZnRlc3QgYS5leGUg
YV9vdXQuZXhlIGIub3V0IGNvbmZ0ZXN0LioiCi0KLWFjX3JtZmlsZXM9Ci1mb3IgYWNfZmlsZSBp
biAkYWNfZmlsZXMKLWRvCi0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAgICAqLiRhY19leHQgfCAqLnhj
b2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFw
IHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7Ci0gICAgKiApIGFjX3JtZmlsZXM9
IiRhY19ybWZpbGVzICRhY19maWxlIjs7Ci0gIGVzYWMKLWRvbmUKLXJtIC1mICRhY19ybWZpbGVz
Ci0KLWlmIHsgeyBhY190cnk9IiRhY19saW5rX2RlZmF1bHQiCi1jYXNlICIoKCRhY190cnkiIGlu
Ci0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190
cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hv
IjsgfSA+JjUKLSAgKGV2YWwgIiRhY19saW5rX2RlZmF1bHQiKSAyPiY1Ci0gIGFjX3N0YXR1cz0k
PwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6Ci0gICMgQXV0b2NvbmYt
Mi4xMyBjb3VsZCBzZXQgdGhlIGFjX2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgotIyBTbyBp
Z25vcmUgYSB2YWx1ZSBvZiBgbm8nLCBvdGhlcndpc2UgdGhpcyB3b3VsZCBsZWFkIHRvIGBFWEVF
WFQgPSBubycKLSMgaW4gYSBNYWtlZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUgYWNfY3Zf
ZXhlZXh0IGlmIGl0IHdhcyBjYWNoZWQsCi0jIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNob3J0LWNp
cmN1aXQgdGhpcyB0ZXN0IGZvciBjb21waWxlcnMgdW5rbm93biB0bwotIyBBdXRvY29uZi4KLWZv
ciBhY19maWxlIGluICRhY19maWxlcyAnJwotZG8KLSAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNv
bnRpbnVlCi0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50
ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYg
fCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApCi0JOzsKLSAgICBbYWJdLm91dCApCi0JIyBXZSBmb3Vu
ZCB0aGUgZGVmYXVsdCBleGVjdXRhYmxlLCBidXQgZXhlZXh0PScnIGlzIG1vc3QKLQkjIGNlcnRh
aW5seSByaWdodC4KLQlicmVhazs7Ci0gICAgKi4qICkKLQlpZiB0ZXN0ICIke2FjX2N2X2V4ZWV4
dCtzZXR9IiA9IHNldCAmJiB0ZXN0ICIkYWNfY3ZfZXhlZXh0IiAhPSBubzsKLQl0aGVuIDo7IGVs
c2UKLQkgICBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AK
LQlmaQotCSMgV2Ugc2V0IGFjX2N2X2V4ZWV4dCBoZXJlIGJlY2F1c2UgdGhlIGxhdGVyIHRlc3Qg
Zm9yIGl0IGlzIG5vdAotCSMgc2FmZTogY3Jvc3MgY29tcGlsZXJzIG1heSBub3QgYWRkIHRoZSBz
dWZmaXggaWYgZ2l2ZW4gYW4gYC1vJwotCSMgYXJndW1lbnQsIHNvIHdlIG1heSBuZWVkIHRvIGtu
b3cgaXQgYXQgdGhhdCBwb2ludCBhbHJlYWR5LgotCSMgRXZlbiBpZiB0aGlzIHNlY3Rpb24gbG9v
a3MgY3J1ZnR5OiBpdCBoYXMgdGhlIGFkdmFudGFnZSBvZgotCSMgYWN0dWFsbHkgd29ya2luZy4K
LQlicmVhazs7Ci0gICAgKiApCi0JYnJlYWs7OwotICBlc2FjCi1kb25lCi10ZXN0ICIkYWNfY3Zf
ZXhlZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KLQotZWxzZQotICBhY19maWxlPScnCi1maQot
aWYgdGVzdCAteiAiJGFjX2ZpbGUiOyB0aGVuIDoKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci0k
YXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKLXNlZCAncy9eL3wgLycg
Y29uZnRlc3QuJGFjX2V4dCA+JjUKLQoteyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBl
cnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBj
YW5ub3QgY3JlYXRlIGV4ZWN1dGFibGVzCi1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRh
aWxzIiAiJExJTkVOTyIgNSA7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Ci0kYXNfZWNobyAieWVzIiA+JjY7IH0KLWZp
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBD
IGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZSIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUuLi4gIiA+JjY7IH0K
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfZmls
ZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2ZpbGUiID4mNjsgfQotYWNfZXhlZXh0PSRhY19jdl9leGVl
eHQKLQotcm0gLWYgLXIgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25mdGVzdCRhY19jdl9leGVl
eHQgYi5vdXQKLWFjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhl
Y3V0YWJsZXMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBleGVjdXRh
Ymxlcy4uLiAiID4mNjsgfQotaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCi1jYXNlICIoKCRhY190
cnkiIGluCi0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAq
KSBhY190cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3Ry
eV9lY2hvIjsgfSA+JjUKLSAgKGV2YWwgIiRhY19saW5rIikgMj4mNQotICBhY19zdGF0dXM9JD8K
LSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1
cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgotICAjIElmIGJvdGggYGNv
bmZ0ZXN0LmV4ZScgYW5kIGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAod2VsbCwgb2JzZXJ2YWJs
ZSkKLSMgY2F0Y2ggYGNvbmZ0ZXN0LmV4ZScuICBGb3IgaW5zdGFuY2Ugd2l0aCBDeWd3aW4sIGBs
cyBjb25mdGVzdCcgd2lsbAotIyB3b3JrIHByb3Blcmx5IChpLmUuLCByZWZlciB0byBgY29uZnRl
c3QuZXhlJyksIHdoaWxlIGl0IHdvbid0IHdpdGgKLSMgYHJtJy4KLWZvciBhY19maWxlIGluIGNv
bmZ0ZXN0LmV4ZSBjb25mdGVzdCBjb25mdGVzdC4qOyBkbwotICB0ZXN0IC1mICIkYWNfZmlsZSIg
fHwgY29udGludWUKLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICouJGFjX2V4dCB8ICoueGNvZmYg
fCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAq
LmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKLSAgICAqLiogKSBhY19jdl9leGVleHQ9
YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKLQkgIGJyZWFrOzsKLSAgICAqICkg
YnJlYWs7OwotICBlc2FjCi1kb25lCi1lbHNlCi0gIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8gIiRh
c19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBjb21wdXRlIHN1ZmZpeCBvZiBleGVjdXRhYmxlczogY2Fubm90IGNvbXBpbGUgYW5kIGxpbmsK
LVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQotZmkK
LXJtIC1mIGNvbmZ0ZXN0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dAoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9leGVleHQiID4mNQotJGFzX2Vj
aG8gIiRhY19jdl9leGVleHQiID4mNjsgfQotCi1ybSAtZiBjb25mdGVzdC4kYWNfZXh0Ci1FWEVF
WFQ9JGFjX2N2X2V4ZWV4dAotYWNfZXhlZXh0PSRFWEVFWFQKLWNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRl
IDxzdGRpby5oPgotaW50Ci1tYWluICgpCi17Ci1GSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5v
dXQiLCAidyIpOwotIHJldHVybiBmZXJyb3IgKGYpIHx8IGZjbG9zZSAoZikgIT0gMDsKLQotICA7
Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1hY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVz
IGNvbmZ0ZXN0Lm91dCIKLSMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIgcHJvZHVjZXMgZXhlY3V0
YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwgZWl0aGVyCi0jIHRoZSBjb21waWxlciBpcyBicm9r
ZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZyIgPiY1Ci0k
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmcuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciICE9IHllczsgdGhlbgotICB7IHsgYWNf
dHJ5PSIkYWNfbGluayIKLWNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwq
KSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNh
YwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNf
dHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFj
X2xpbmsiKSAyPiY1Ci0gIGFjX3N0YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0g
MDsgfQotICBpZiB7IGFjX3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVleHQnCi0gIHsgeyBjYXNl
ICIoKCRhY190cnkiIGluCi0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190
cnk7OwotICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNo
byAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKLSAgKGV2YWwgIiRhY190cnkiKSAyPiY1Ci0gIGFjX3N0
YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgfTsgdGhlbgotICAgIGNy
b3NzX2NvbXBpbGluZz1ubwotICBlbHNlCi0gICAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIg
PSBtYXliZTsgdGhlbgotCWNyb3NzX2NvbXBpbGluZz15ZXMKLSAgICBlbHNlCi0JeyB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIg
PiY1Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19m
bl9lcnJvciAkPyAiY2Fubm90IHJ1biBDIGNvbXBpbGVkIHByb2dyYW1zLgotSWYgeW91IG1lYW50
IHRvIGNyb3NzIGNvbXBpbGUsIHVzZSBcYC0taG9zdCcuCi1TZWUgXGBjb25maWcubG9nJyBmb3Ig
bW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KLSAgICBmaQotICBmaQotZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkY3Jvc3NfY29tcGlsaW5n
IiA+JjUKLSRhc19lY2hvICIkY3Jvc3NfY29tcGlsaW5nIiA+JjY7IH0KLQotcm0gLWYgY29uZnRl
c3QuJGFjX2V4dCBjb25mdGVzdCRhY19jdl9leGVleHQgY29uZnRlc3Qub3V0Ci1hY19jbGVhbl9m
aWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3VmZml4IG9mIG9iamVjdCBmaWxlcyIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3Igc3VmZml4IG9mIG9iamVjdCBmaWxlcy4uLiAiID4mNjsgfQot
aWYgdGVzdCAiJHthY19jdl9vYmpleHQrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQotewot
Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLXJtIC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qu
b2JqCi1pZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIKLWNhc2UgIigoJGFjX3RyeSIgaW4KLSAg
KlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9l
Y2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9
ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPiY1Ci0gIGFjX3N0YXR1cz0kPwotICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUK
LSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6Ci0gIGZvciBhY19maWxlIGluIGNvbmZ0
ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCi0gIHRlc3QgLWYgIiRhY19maWxlIiB8
fCBjb250aW51ZTsKLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICouJGFjX2V4dCB8ICoueGNvZmYg
fCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAq
LmluZiB8ICouZFNZTSApIDs7Ci0gICAgKikgYWNfY3Zfb2JqZXh0PWBleHByICIkYWNfZmlsZSIg
OiAnLipcLlwoLipcKSdgCi0gICAgICAgYnJlYWs7OwotICBlc2FjCi1kb25lCi1lbHNlCi0gICRh
c19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQotc2VkICdzL14vfCAvJyBj
b25mdGVzdC4kYWNfZXh0ID4mNQotCi17IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVy
cm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KLWFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0
ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3QgY29tcGlsZQotU2VlIFxgY29uZmlnLmxv
ZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci1maQotcm0gLWYgY29uZnRlc3Qu
JGFjX2N2X29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9vYmpleHQiID4mNQotJGFzX2VjaG8g
IiRhY19jdl9vYmpleHQiID4mNjsgfQotT0JKRVhUPSRhY19jdl9vYmpleHQKLWFjX29iamV4dD0k
T0JKRVhUCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0fSIgPSBzZXQ7IHRoZW4g
OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWlu
dAotbWFpbiAoKQotewotI2lmbmRlZiBfX0dOVUNfXwotICAgICAgIGNob2tlIG1lCi0jZW5kaWYK
LQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIk
TElORU5PIjsgdGhlbiA6Ci0gIGFjX2NvbXBpbGVyX2dudT15ZXMKLWVsc2UKLSAgYWNfY29tcGls
ZXJfZ251PW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1hY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251
Ci0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfY19jb21waWxlcl9n
bnUiID4mNjsgfQotaWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCi0gIEdDQz15
ZXMKLWVsc2UKLSAgR0NDPQotZmkKLWFjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KLWFjX3Nh
dmVfQ0ZMQUdTPSRDRkxBR1MKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3Byb2dfY2NfZytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2Ci1lbHNlCi0gIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZwotICAg
YWNfY193ZXJyb3JfZmxhZz15ZXMKLSAgIGFjX2N2X3Byb2dfY2NfZz1ubwotICAgQ0ZMQUdTPSIt
ZyIKLSAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsK
LX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBh
Y19jdl9wcm9nX2NjX2c9eWVzCi1lbHNlCi0gIENGTEFHUz0iIgotICAgICAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwot
Ci1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0KLWVsc2UKLSAgYWNfY193ZXJyb3Jf
ZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCi0JIENGTEFHUz0iLWciCi0JIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf
Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9wcm9nX2NjX2c9eWVz
Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZl
X2Nfd2Vycm9yX2ZsYWcKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3Byb2df
Y2NfZyIgPiY2OyB9Ci1pZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCi0gIENG
TEFHUz0kYWNfc2F2ZV9DRkxBR1MKLWVsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0
aGVuCi0gIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItZyAtTzIiCi0g
IGVsc2UKLSAgICBDRkxBR1M9Ii1nIgotICBmaQotZWxzZQotICBpZiB0ZXN0ICIkR0NDIiA9IHll
czsgdGhlbgotICAgIENGTEFHUz0iLU8yIgotICBlbHNlCi0gICAgQ0ZMQUdTPQotICBmaQotZmkK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBhY19jdl9wcm9nX2NjX2M4OT1ubwotYWNfc2F2ZV9DQz0kQ0MKLWNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KLSNpbmNsdWRlIDxzdGRhcmcuaD4KLSNpbmNsdWRlIDxzdGRpby5oPgotI2luY2x1
ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5cy9zdGF0Lmg+Ci0vKiBNb3N0IG9mIHRoZSBm
b2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICov
Ci1zdHJ1Y3QgYnVmIHsgaW50IHg7IH07Ci1GSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAq
LCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOwotc3RhdGljIGNoYXIgKmUgKHAsIGkpCi0gICAgIGNoYXIg
KipwOwotICAgICBpbnQgaTsKLXsKLSAgcmV0dXJuIHBbaV07Ci19Ci1zdGF0aWMgY2hhciAqZiAo
Y2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCi17Ci0gIGNoYXIgKnM7
Ci0gIHZhX2xpc3QgdjsKLSAgdmFfc3RhcnQgKHYscCk7Ci0gIHMgPSBnIChwLCB2YV9hcmcgKHYs
aW50KSk7Ci0gIHZhX2VuZCAodik7Ci0gIHJldHVybiBzOwotfQotCi0vKiBPU0YgNC4wIENvbXBh
cSBjYyBpcyBzb21lIHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcwotICAg
ZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0
ZXIgY29uc3RhbnRzLgotICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0
ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCi0gICBhcyAneCcuICBUaGUgZm9sbG93
aW5nIGluZHVjZXMgYW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0Ci0gICBwcm9w
ZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1
ZSwgZm9yIGFuCi0gICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3Jp
dGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKLSAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAt
c3RkLiAgKi8KLWludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07Ci0KLS8q
IElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFj
ZXMgbWFjcm8gcGFyYW1ldGVycwotICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25z
dGFudHMuICAqLwotI2RlZmluZSBGT08oeCkgJ3gnCi1pbnQgeGxjNl9jY19hcnJheVtGT08oYSkg
PT0gJ3gnID8gMSA6IC0xXTsKLQotaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7Ci1zdHJ1Y3Qg
czEge2ludCAoKmYpIChpbnQgYSk7fTsKLXN0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9
OwotaW50IHBhaXJuYW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBz
dHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQsIGludCk7Ci1pbnQgYXJnYzsKLWNoYXIgKiphcmd2Owot
aW50Ci1tYWluICgpCi17Ci1yZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYg
KGUsIGFyZ3YsIDEpICE9IGFyZ3ZbMV07Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWZv
ciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKLQkt
QWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgotZG8KLSAgQ0M9
IiRhY19zYXZlX0NDICRhY19hcmciCi0gIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKLSAgYWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKLSAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4
OSIgIT0gInhubyIgJiYgYnJlYWsKLWRvbmUKLXJtIC1mIGNvbmZ0ZXN0LiRhY19leHQKLUNDPSRh
Y19zYXZlX0NDCi0KLWZpCi0jIEFDX0NBQ0hFX1ZBTAotY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4
OSIgaW4KLSAgeCkKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQotJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0g
OzsKLSAgeG5vKQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1Ci0kYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7
OwotICAqKQotICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgotICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODki
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Ci1lc2FjCi1pZiB0
ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgotCi1maQotCi1hY19leHQ9
YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRD
UFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRh
Y19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElC
UyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Ci0KLQotYWNfZXh0
PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAk
Q1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19saW5rPSckQ0MgLW8gY29uZnRlc3Qk
YWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJ
QlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBob3cgdG8gcnVuIHRoZSBD
IHByZXByb2Nlc3NvciIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBob3cgdG8gcnVuIHRoZSBD
IHByZXByb2Nlc3Nvci4uLiAiID4mNjsgfQotIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1l
cyBhIGRpcmVjdG9yeS4KLWlmIHRlc3QgLW4gIiRDUFAiICYmIHRlc3QgLWQgIiRDUFAiOyB0aGVu
Ci0gIENQUD0KLWZpCi1pZiB0ZXN0IC16ICIkQ1BQIjsgdGhlbgotICBpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfQ1BQK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKLWVsc2UKLSAgICAgICMgRG91YmxlIHF1b3RlcyBiZWNhdXNlIENQUCBuZWVkcyB0byBiZSBl
eHBhbmRlZAotICAgIGZvciBDUFAgaW4gIiRDQyAtRSIgIiRDQyAtRSAtdHJhZGl0aW9uYWwtY3Bw
IiAiL2xpYi9jcHAiCi0gICAgZG8KLSAgICAgIGFjX3ByZXByb2Nfb2s9ZmFsc2UKLWZvciBhY19j
X3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwotZG8KLSAgIyBVc2UgYSBoZWFkZXIgZmlsZSB0
aGF0IGNvbWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGliYwotICAjIHdpdGggYSBmcmVz
aCBjcm9zcy1jb21waWxlciB3b3Jrcy4KLSAgIyBQcmVmZXIgPGxpbWl0cy5oPiB0byA8YXNzZXJ0
Lmg+IGlmIF9fU1REQ19fIGlzIGRlZmluZWQsIHNpbmNlCi0gICMgPGxpbWl0cy5oPiBleGlzdHMg
ZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgotICAjIE9uIHRoZSBOZVhULCBjYyAtRSBy
dW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVyJ3MgcGFyc2VyLAotICAjIG5vdCBqdXN0
IHRocm91Z2ggY3BwLiAiU3ludGF4IGVycm9yIiBpcyBoZXJlIHRvIGNhdGNoIHRoaXMgY2FzZS4K
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotI2lmZGVmIF9fU1REQ19fCi0jIGluY2x1ZGUgPGxpbWl0cy5oPgotI2Vs
c2UKLSMgaW5jbHVkZSA8YXNzZXJ0Lmg+Ci0jZW5kaWYKLQkJICAgICBTeW50YXggZXJyb3IKLV9B
Q0VPRgotaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6Ci0KLWVsc2UKLSAgIyBC
cm9rZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgotY29udGludWUKLWZpCi1ybSAtZiBjb25mdGVz
dC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0KLSAgIyBPSywgd29ya3Mgb24gc2Fu
ZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50IGhlYWRlcnMKLSAgIyBjYW4g
YmUgZGV0ZWN0ZWQgYW5kIGhvdy4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPGFjX25vbmV4aXN0
ZW50Lmg+Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgotICAj
IEJyb2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgotY29udGludWUKLWVsc2UKLSAgIyBQ
YXNzZXMgYm90aCB0ZXN0cy4KLWFjX3ByZXByb2Nfb2s9OgotYnJlYWsKLWZpCi1ybSAtZiBjb25m
dGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0KLWRvbmUKLSMgQmVjYXVzZSBv
ZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBjbGVhbmluZyBjb2RlIHdhcyBza2lwcGVk
Lgotcm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX2V4dAotaWYgJGFj
X3ByZXByb2Nfb2s7IHRoZW4gOgotICBicmVhawotZmkKLQotICAgIGRvbmUKLSAgICBhY19jdl9w
cm9nX0NQUD0kQ1BQCi0KLWZpCi0gIENQUD0kYWNfY3ZfcHJvZ19DUFAKLWVsc2UKLSAgYWNfY3Zf
cHJvZ19DUFA9JENQUAotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQ1BQIiA+JjUKLSRhc19lY2hvICIkQ1BQIiA+JjY7IH0KLWFjX3ByZXByb2Nf
b2s9ZmFsc2UKLWZvciBhY19jX3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwotZG8KLSAgIyBV
c2UgYSBoZWFkZXIgZmlsZSB0aGF0IGNvbWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGli
YwotICAjIHdpdGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jrcy4KLSAgIyBQcmVmZXIgPGxp
bWl0cy5oPiB0byA8YXNzZXJ0Lmg+IGlmIF9fU1REQ19fIGlzIGRlZmluZWQsIHNpbmNlCi0gICMg
PGxpbWl0cy5oPiBleGlzdHMgZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgotICAjIE9u
IHRoZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVyJ3MgcGFy
c2VyLAotICAjIG5vdCBqdXN0IHRocm91Z2ggY3BwLiAiU3ludGF4IGVycm9yIiBpcyBoZXJlIHRv
IGNhdGNoIHRoaXMgY2FzZS4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmZGVmIF9fU1REQ19fCi0jIGluY2x1
ZGUgPGxpbWl0cy5oPgotI2Vsc2UKLSMgaW5jbHVkZSA8YXNzZXJ0Lmg+Ci0jZW5kaWYKLQkJICAg
ICBTeW50YXggZXJyb3IKLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6Ci0KLWVsc2UKLSAgIyBCcm9rZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgotY29udGludWUK
LWZpCi1ybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0KLSAg
IyBPSywgd29ya3Mgb24gc2FuZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50
IGhlYWRlcnMKLSAgIyBjYW4gYmUgZGV0ZWN0ZWQgYW5kIGhvdy4KLSAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lu
Y2x1ZGUgPGFjX25vbmV4aXN0ZW50Lmg+Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJ
TkVOTyI7IHRoZW4gOgotICAjIEJyb2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgotY29u
dGludWUKLWVsc2UKLSAgIyBQYXNzZXMgYm90aCB0ZXN0cy4KLWFjX3ByZXByb2Nfb2s9OgotYnJl
YWsKLWZpCi1ybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Ci0K
LWRvbmUKLSMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBjbGVhbmlu
ZyBjb2RlIHdhcyBza2lwcGVkLgotcm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX2V4dAotaWYgJGFjX3ByZXByb2Nfb2s7IHRoZW4gOgotCi1lbHNlCi0gIHsgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mNQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNf
Zm5fZXJyb3IgJD8gIkMgcHJlcHJvY2Vzc29yIFwiJENQUFwiIGZhaWxzIHNhbml0eSBjaGVjawot
U2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci1maQot
Ci1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBpbGU9JyRDQyAtYyAk
Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xpbms9JyRDQyAtbyBj
b25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFj
X2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Ci0K
LQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
Z3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgot
ICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UKLSAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBw
YXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKLSAgYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRP
Ui91c3IveHBnNC9iaW4KLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfcHJvZyBpbiBncmVwIGdncmVwOyBkbwotICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICAgICAg
YWNfcGF0aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgotICAgICAgeyB0ZXN0
IC1mICIkYWNfcGF0aF9HUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBj
b250aW51ZQotIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0
IGlzIGZvdW5kLgotICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAotY2FzZSBgIiRhY19w
YXRoX0dSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgotKkdOVSopCi0gIGFjX2N2X3BhdGhfR1JFUD0i
JGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7OwotKikKLSAgYWNfY291bnQ9MAot
ICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKLSAgd2hpbGUgOgotICBkbwot
ICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCi0gICAg
bXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgotICAgIGNwICJjb25mdGVzdC5pbiIgImNv
bmZ0ZXN0Lm5sIgotICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRh
Y19wYXRoX0dSRVAiIC1lICdHUkVQJCcgLWUgJy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0
Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKLSAgICBkaWZmICJjb25m
dGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCi0gICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCi0gICAgaWYgdGVzdCAk
YWNfY291bnQgLWd0ICR7YWNfcGF0aF9HUkVQX21heC0wfTsgdGhlbgotICAgICAgIyBCZXN0IG9u
ZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCi0gICAg
ICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiCi0gICAgICBhY19wYXRoX0dSRVBfbWF4
PSRhY19jb3VudAotICAgIGZpCi0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMg
bW9yZSB0aGFuIGVub3VnaAotICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawotICBk
b25lCi0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVz
dC5vdXQ7OwotZXNhYwotCi0gICAgICAkYWNfcGF0aF9HUkVQX2ZvdW5kICYmIGJyZWFrIDMKLSAg
ICBkb25lCi0gIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotICBpZiB0ZXN0IC16ICIk
YWNfY3ZfcGF0aF9HUkVQIjsgdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxl
IGdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmlu
IiAiJExJTkVOTyIgNQotICBmaQotZWxzZQotICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKLWZpCi0K
LWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X3BhdGhfR1JFUCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9Ci0g
R1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9FR1JFUCtzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlm
IGVjaG8gYSB8ICRHUkVQIC1FICcoYXxiKScgPi9kZXYvbnVsbCAyPiYxCi0gICB0aGVuIGFjX2N2
X3BhdGhfRUdSRVA9IiRHUkVQIC1FIgotICAgZWxzZQotICAgICBpZiB0ZXN0IC16ICIkRUdSRVAi
OyB0aGVuCi0gIGFjX3BhdGhfRUdSRVBfZm91bmQ9ZmFsc2UKLSAgIyBMb29wIHRocm91Z2ggdGhl
IHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKLSAgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRI
X1NFUEFSQVRPUi91c3IveHBnNC9iaW4KLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfcHJvZyBpbiBlZ3JlcDsgZG8KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
ICAgIGFjX3BhdGhfRUdSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCi0gICAgICB7
IHRlc3QgLWYgIiRhY19wYXRoX0VHUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9FR1JFUCI7
IH0gfHwgY29udGludWUKLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0VHUkVQIGFuZCBzZWxlY3Qg
aXQgaWYgaXQgaXMgZm91bmQuCi0gICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9FR1JFUAotY2Fz
ZSBgIiRhY19wYXRoX0VHUkVQIiAtLXZlcnNpb24gMj4mMWAgaW4KLSpHTlUqKQotICBhY19jdl9w
YXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIgYWNfcGF0aF9FR1JFUF9mb3VuZD06OzsKLSopCi0g
IGFjX2NvdW50PTAKLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCi0gIHdo
aWxlIDoKLSAgZG8KLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRl
c3QudG1wIgotICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKLSAgICBjcCAiY29u
ZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKLSAgICAkYXNfZWNobyAnRUdSRVAnID4+ICJjb25mdGVz
dC5ubCIKLSAgICAiJGFjX3BhdGhfRUdSRVAiICdFR1JFUCQnIDwgImNvbmZ0ZXN0Lm5sIiA+ImNv
bmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKLSAgICBkaWZmICJjb25mdGVzdC5vdXQi
ICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCi0gICAgYXNfZm5fYXJpdGgg
JGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCi0gICAgaWYgdGVzdCAkYWNfY291bnQg
LWd0ICR7YWNfcGF0aF9FR1JFUF9tYXgtMH07IHRoZW4KLSAgICAgICMgQmVzdCBvbmUgc28gZmFy
LCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQotICAgICAgYWNfY3Zf
cGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiCi0gICAgICBhY19wYXRoX0VHUkVQX21heD0kYWNf
Y291bnQKLSAgICBmaQotICAgICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUg
dGhhbiBlbm91Z2gKLSAgICB0ZXN0ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKLSAgZG9uZQot
ICBybSAtZiBjb25mdGVzdC5pbiBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0
OzsKLWVzYWMKLQotICAgICAgJGFjX3BhdGhfRUdSRVBfZm91bmQgJiYgYnJlYWsgMwotICAgIGRv
bmUKLSAgZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0gIGlmIHRlc3QgLXogIiRhY19j
dl9wYXRoX0VHUkVQIjsgdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGVn
cmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIg
IiRMSU5FTk8iIDUKLSAgZmkKLWVsc2UKLSAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAKLWZpCi0K
LSAgIGZpCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9wYXRoX0VHUkVQIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcGF0aF9FR1JFUCIg
PiY2OyB9Ci0gRUdSRVA9IiRhY19jdl9wYXRoX0VHUkVQIgotCi0KLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMi
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3N0ZGMrc2V0fSIgPSBzZXQ7IHRoZW4gOgot
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVk
ZSA8c3RkbGliLmg+Ci0jaW5jbHVkZSA8c3RkYXJnLmg+Ci0jaW5jbHVkZSA8c3RyaW5nLmg+Ci0j
aW5jbHVkZSA8ZmxvYXQuaD4KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsK
LX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBh
Y19jdl9oZWFkZXJfc3RkYz15ZXMKLWVsc2UKLSAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KLWZpCi1y
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKLQotaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLSAgIyBTdW5PUyA0
Lnggc3RyaW5nLmggZG9lcyBub3QgZGVjbGFyZSBtZW0qLCBjb250cmFyeSB0byBBTlNJLgotICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCi0jaW5jbHVkZSA8c3RyaW5nLmg+Ci0KLV9BQ0VPRgotaWYgKGV2YWwgIiRhY19j
cHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAotICAkRUdSRVAgIm1lbWNociIgPi9kZXYvbnVs
bCAyPiYxOyB0aGVuIDoKLQotZWxzZQotICBhY19jdl9oZWFkZXJfc3RkYz1ubwotZmkKLXJtIC1m
IGNvbmZ0ZXN0KgotCi1maQotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhl
bgotICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2VzIG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5
IHRvIEFOU0kuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
LS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzdGRsaWIuaD4KLQotX0FDRU9GCi1p
ZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAiZnJl
ZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKLQotZWxzZQotICBhY19jdl9oZWFkZXJfc3RkYz1u
bwotZmkKLXJtIC1mIGNvbmZ0ZXN0KgotCi1maQotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3Rk
YyA9IHllczsgdGhlbgotICAjIC9iaW4vY2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0
eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2kuCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxp
bmciID0geWVzOyB0aGVuIDoKLSAgOgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8Y3R5
cGUuaD4KLSNpbmNsdWRlIDxzdGRsaWIuaD4KLSNpZiAoKCcgJyAmIDB4MEZGKSA9PSAweDAyMCkK
LSMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykKLSMgZGVmaW5l
IFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAnQScgKyAoKGMpIC0gJ2EnKSA6IChjKSkKLSNlbHNl
Ci0jIGRlZmluZSBJU0xPV0VSKGMpIFwKLQkJICAgKCgnYScgPD0gKGMpICYmIChjKSA8PSAnaScp
IFwKLQkJICAgICB8fCAoJ2onIDw9IChjKSAmJiAoYykgPD0gJ3InKSBcCi0JCSAgICAgfHwgKCdz
JyA8PSAoYykgJiYgKGMpIDw9ICd6JykpCi0jIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMp
ID8gKChjKSB8IDB4NDApIDogKGMpKQotI2VuZGlmCi0KLSNkZWZpbmUgWE9SKGUsIGYpICgoKGUp
ICYmICEoZikpIHx8ICghKGUpICYmIChmKSkpCi1pbnQKLW1haW4gKCkKLXsKLSAgaW50IGk7Ci0g
IGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKLSAgICBpZiAoWE9SIChpc2xvd2VyIChpKSwgSVNM
T1dFUiAoaSkpCi0JfHwgdG91cHBlciAoaSkgIT0gVE9VUFBFUiAoaSkpCi0gICAgICByZXR1cm4g
MjsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7
IHRoZW4gOgotCi1lbHNlCi0gIGFjX2N2X2hlYWRlcl9zdGRjPW5vCi1maQotcm0gLWYgY29yZSAq
LmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQg
XAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAot
ZmkKLQotZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0
ZGMiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLQotJGFz
X2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAotCi1maQotCi0jIE9u
IElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5cGVzLmggYXJlIGNvbmZsaWN0aW5nLgotZm9y
IGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5oIHN0cmluZy5oIG1l
bW9yeS5oIHN0cmluZ3MuaCBcCi0JCSAgaW50dHlwZXMuaCBzdGRpbnQuaCB1bmlzdGQuaAotZG8g
OgotICBhc19hY19IZWFkZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAk
YXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hl
YWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdAotIgotaWYgZXZhbCB0
ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgotICBjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRh
c190cl9jcHBgIDEKLV9BQ0VPRgotCi1maQotCi1kb25lCi0KLQotCi0gIGFjX2ZuX2NfY2hlY2tf
aGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJtaW5peC9jb25maWcuaCIgImFjX2N2X2hlYWRlcl9t
aW5peF9jb25maWdfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9o
ZWFkZXJfbWluaXhfY29uZmlnX2giID0geCIieWVzOyB0aGVuIDoKLSAgTUlOSVg9eWVzCi1lbHNl
Ci0gIE1JTklYPQotZmkKLQotCi0gIGlmIHRlc3QgIiRNSU5JWCIgPSB5ZXM7IHRoZW4KLQotJGFz
X2VjaG8gIiNkZWZpbmUgX1BPU0lYX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKLQotCi0kYXNfZWNo
byAiI2RlZmluZSBfUE9TSVhfMV9TT1VSQ0UgMiIgPj5jb25mZGVmcy5oCi0KLQotJGFzX2VjaG8g
IiNkZWZpbmUgX01JTklYIDEiID4+Y29uZmRlZnMuaAotCi0gIGZpCi0KLQotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2Fm
ZSB0byBkZWZpbmUgX19FWFRFTlNJT05TX18iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hl
dGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXy4uLiAiID4mNjsgfQotaWYg
dGVzdCAiJHthY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXytzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LQotIwkgIGRlZmluZSBfX0VYVEVOU0lPTlNfXyAxCi0JICAkYWNfaW5jbHVkZXNfZGVmYXVsdAot
aW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9zYWZlX3RvX2RlZmluZV9f
X2V4dGVuc2lvbnNfXz15ZXMKLWVsc2UKLSAgYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNp
b25zX189bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fIiA+JjUK
LSRhc19lY2hvICIkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18iID4mNjsgfQot
ICB0ZXN0ICRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyA9IHllcyAmJgotICAg
ICRhc19lY2hvICIjZGVmaW5lIF9fRVhURU5TSU9OU19fIDEiID4+Y29uZmRlZnMuaAotCi0gICRh
c19lY2hvICIjZGVmaW5lIF9BTExfU09VUkNFIDEiID4+Y29uZmRlZnMuaAotCi0gICRhc19lY2hv
ICIjZGVmaW5lIF9HTlVfU09VUkNFIDEiID4+Y29uZmRlZnMuaAotCi0gICRhc19lY2hvICIjZGVm
aW5lIF9QT1NJWF9QVEhSRUFEX1NFTUFOVElDUyAxIiA+PmNvbmZkZWZzLmgKLQotICAkYXNfZWNo
byAiI2RlZmluZSBfVEFOREVNX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKLQotCi0jIE1ha2Ugc3Vy
ZSB3ZSBjYW4gcnVuIGNvbmZpZy5zdWIuCi0kU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIi
IHN1bjQgPi9kZXYvbnVsbCAyPiYxIHx8Ci0gIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuICRT
SEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViIiAiJExJTkVOTyIgNQotCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGJ1aWxkIHN5c3RlbSB0eXBlIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGJ1aWxkIHN5c3RlbSB0eXBlLi4uICIgPiY2OyB9Ci1p
ZiB0ZXN0ICIke2FjX2N2X2J1aWxkK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfYnVpbGRfYWxpYXM9JGJ1aWxkX2FsaWFzCi10ZXN0
ICJ4JGFjX2J1aWxkX2FsaWFzIiA9IHggJiYKLSAgYWNfYnVpbGRfYWxpYXM9YCRTSEVMTCAiJGFj
X2F1eF9kaXIvY29uZmlnLmd1ZXNzImAKLXRlc3QgIngkYWNfYnVpbGRfYWxpYXMiID0geCAmJgot
ICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGd1ZXNzIGJ1aWxkIHR5cGU7IHlvdSBtdXN0IHNwZWNp
Znkgb25lIiAiJExJTkVOTyIgNQotYWNfY3ZfYnVpbGQ9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29u
ZmlnLnN1YiIgJGFjX2J1aWxkX2FsaWFzYCB8fAotICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRh
Y19hdXhfZGlyL2NvbmZpZy5zdWIgJGFjX2J1aWxkX2FsaWFzIGZhaWxlZCIgIiRMSU5FTk8iIDUK
LQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfYnVpbGQiID4mNQotJGFzX2VjaG8gIiRhY19jdl9idWlsZCIgPiY2OyB9Ci1jYXNlICRh
Y19jdl9idWlsZCBpbgotKi0qLSopIDs7Ci0qKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YWx1
ZSBvZiBjYW5vbmljYWwgYnVpbGQiICIkTElORU5PIiA1IDs7Ci1lc2FjCi1idWlsZD0kYWNfY3Zf
YnVpbGQKLWFjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKLXNldCB4ICRhY19jdl9idWlsZAotc2hp
ZnQKLWJ1aWxkX2NwdT0kMQotYnVpbGRfdmVuZG9yPSQyCi1zaGlmdDsgc2hpZnQKLSMgUmVtZW1i
ZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAotIyBl
eGNlcHQgd2l0aCBvbGQgc2hlbGxzOgotYnVpbGRfb3M9JCoKLUlGUz0kYWNfc2F2ZV9JRlMKLWNh
c2UgJGJ1aWxkX29zIGluICpcICopIGJ1aWxkX29zPWBlY2hvICIkYnVpbGRfb3MiIHwgc2VkICdz
LyAvLS9nJ2A7OyBlc2FjCi0KLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGhvc3Qgc3lzdGVtIHR5cGUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaG9zdCtzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlm
IHRlc3QgIngkaG9zdF9hbGlhcyIgPSB4OyB0aGVuCi0gIGFjX2N2X2hvc3Q9JGFjX2N2X2J1aWxk
Ci1lbHNlCi0gIGFjX2N2X2hvc3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhv
c3RfYWxpYXNgIHx8Ci0gICAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25m
aWcuc3ViICRob3N0X2FsaWFzIGZhaWxlZCIgIiRMSU5FTk8iIDUKLWZpCi0KLWZpCi17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hvc3QiID4m
NQotJGFzX2VjaG8gIiRhY19jdl9ob3N0IiA+JjY7IH0KLWNhc2UgJGFjX2N2X2hvc3QgaW4KLSot
Ki0qKSA7OwotKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGhv
c3QiICIkTElORU5PIiA1IDs7Ci1lc2FjCi1ob3N0PSRhY19jdl9ob3N0Ci1hY19zYXZlX0lGUz0k
SUZTOyBJRlM9Jy0nCi1zZXQgeCAkYWNfY3ZfaG9zdAotc2hpZnQKLWhvc3RfY3B1PSQxCi1ob3N0
X3ZlbmRvcj0kMgotc2hpZnQ7IHNoaWZ0Ci0jIFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVy
IG9mIElGUyBpcyB1c2VkIHRvIGNyZWF0ZSAkKiwKLSMgZXhjZXB0IHdpdGggb2xkIHNoZWxsczoK
LWhvc3Rfb3M9JCoKLUlGUz0kYWNfc2F2ZV9JRlMKLWNhc2UgJGhvc3Rfb3MgaW4gKlwgKikgaG9z
dF9vcz1gZWNobyAiJGhvc3Rfb3MiIHwgc2VkICdzLyAvLS9nJ2A7OyBlc2FjCi0KLQotCi0jIE00
IE1hY3JvIGluY2x1ZGVzCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQot
Ci0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotIyBw
a2cubTQgLSBNYWNyb3MgdG8gbG9jYXRlIGFuZCB1dGlsaXNlIHBrZy1jb25maWcuICAgICAgICAg
ICAgLSotIEF1dG9jb25mIC0qLQotIyBzZXJpYWwgMSAocGtnLWNvbmZpZy0wLjI0KQotIwotIyBD
b3B5cmlnaHQgwqkgMjAwNCBTY290dCBKYW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+
LgotIwotIyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yIG1vZGlmeQotIyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQotIyB0aGUgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgotIyAoYXQgeW91
ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgotIwotIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0Ci0jIFdJVEhPVVQg
QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKLSMgTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRo
ZSBHTlUKLSMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgotIwotIyBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZQotIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUg
RnJlZSBTb2Z0d2FyZQotIyBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0
ZSAzMzAsIEJvc3RvbiwgTUEgMDIxMTEtMTMwNywgVVNBLgotIwotIyBBcyBhIHNwZWNpYWwgZXhj
ZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91Ci0jIGRpc3Ry
aWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQotIyBj
b25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVk
ZSBpdCB1bmRlcgotIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZv
ciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCi0KLSMgUEtHX1BST0dfUEtHX0NPTkZJRyhbTUlO
LVZFUlNJT05dKQotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFBLR19Q
Uk9HX1BLR19DT05GSUcKLQotIyBQS0dfQ0hFQ0tfRVhJU1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYt
Rk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCi0jCi0jIENoZWNrIHRvIHNlZSB3aGV0aGVy
IGEgcGFydGljdWxhciBzZXQgb2YgbW9kdWxlcyBleGlzdHMuICBTaW1pbGFyCi0jIHRvIFBLR19D
SEVDS19NT0RVTEVTKCksIGJ1dCBkb2VzIG5vdCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9y
cy4KLSMKLSMgUGxlYXNlIHJlbWVtYmVyIHRoYXQgbTQgZXhwYW5kcyBBQ19SRVFVSVJFKFtQS0df
UFJPR19QS0dfQ09ORklHXSkKLSMgb25seSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZp
Z3VyZS5hYywgc28gaWYgdGhlIGZpcnN0IHBsYWNlCi0jIGl0J3MgY2FsbGVkIG1pZ2h0IGJlIHNr
aXBwZWQgKHN1Y2ggYXMgaWYgaXQgaXMgd2l0aGluIGFuICJpZiIsIHlvdQotIyBoYXZlIHRvIGNh
bGwgUEtHX0NIRUNLX0VYSVNUUyBtYW51YWxseQotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotCi0KLSMgX1BLR19DT05GSUco
W1ZBUklBQkxFXSwgW0NPTU1BTkRdLCBbTU9EVUxFU10pCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotIyBfUEtHX0NPTkZJRwotCi0jIF9QS0dfU0hPUlRf
RVJST1JTX1NVUFBPUlRFRAotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotIyBfUEtH
X1NIT1JUX0VSUk9SU19TVVBQT1JURUQKLQotCi0jIFBLR19DSEVDS19NT0RVTEVTKFZBUklBQkxF
LVBSRUZJWCwgTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sCi0jIFtBQ1RJT04tSUYtTk9ULUZP
VU5EXSkKLSMKLSMKLSMgTm90ZSB0aGF0IGlmIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhlIGZp
cnN0IGNhbGwgdG8KLSMgUEtHX0NIRUNLX01PRFVMRVMgbWlnaHQgbm90IGhhcHBlbiwgeW91IHNo
b3VsZCBiZSBzdXJlIHRvIGluY2x1ZGUgYW4KLSMgZXhwbGljaXQgY2FsbCB0byBQS0dfUFJPR19Q
S0dfQ09ORklHIGluIHlvdXIgY29uZmlndXJlLmFjCi0jCi0jCi0jIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFBLR19DSEVD
S19NT0RVTEVTCi0KLQotCi0jIFdlIGRlZmluZSwgc2VwYXJhdGVseSwgUFRIUkVBRF9DRkxBR1Ms
IF9MREZMQUdTIGFuZCBfTElCUwotIyBldmVuIHRob3VnaCBjdXJyZW50bHkgd2UgZG9uJ3Qgc2V0
IHRoZW0gdmVyeSBzZXBhcmF0ZWx5LgotIyBUaGlzIG1lYW5zIHRoYXQgdGhlIG1ha2VmaWxlcyB3
aWxsIG5vdCBuZWVkIHRvIGNoYW5nZSBpbgotIyB0aGUgZnV0dXJlIGlmIHdlIG1ha2UgdGhlIHRl
c3QgbW9yZSBzb3BoaXN0aWNhdGVkLgotCi0KLQotIyBXZSBpbnZva2UgQVhfUFRIUkVBRF9WQVJT
IHdpdGggdGhlIG5hbWUgb2YgYW5vdGhlciBtYWNybwotIyB3aGljaCBpcyB0aGVuIGV4cGFuZGVk
IG9uY2UgZm9yIGVhY2ggdmFyaWFibGUuCi0KLQotCi0KLQotCi0KLQotIyBFbmFibGUvZGlzYWJs
ZSBvcHRpb25zCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4K
LWlmIHRlc3QgIiR7ZW5hYmxlX2dpdGh0dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2
YWw9JGVuYWJsZV9naXRodHRwOwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9
ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X2dpdGh0dHA9Im4iCi0KLWVsaWYgdGVzdCAieCRl
bmFibGVfZ2l0aHR0cCIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfZ2l0aHR0cD0ieSIK
LQotZWxpZiB0ZXN0IC16ICRheF9jdl9naXRodHRwOyB0aGVuIDoKLQotICAgIGF4X2N2X2dpdGh0
dHA9Im4iCi0KLWZpCi1naXRodHRwPSRheF9jdl9naXRodHRwCi0KLQotCi0jIENoZWNrIHdoZXRo
ZXIgLS1lbmFibGUtbW9uaXRvcnMgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfbW9uaXRv
cnMrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9tb25pdG9yczsKLWZp
Ci0KLQotaWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInhubyI7IHRoZW4gOgotCi0gICAg
YXhfY3ZfbW9uaXRvcnM9Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInh5
ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X21vbml0b3JzPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4
X2N2X21vbml0b3JzOyB0aGVuIDoKLQotICAgIGF4X2N2X21vbml0b3JzPSJ5IgotCi1maQotbW9u
aXRvcnM9JGF4X2N2X21vbml0b3JzCi0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtdnRw
bSB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV92dHBtK3NldH0iID0gc2V0OyB0aGVuIDoK
LSAgZW5hYmxldmFsPSRlbmFibGVfdnRwbTsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfdnRw
bSIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl92dHBtPSJuIgotCi1lbGlmIHRlc3QgIngk
ZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X3Z0cG09InkiCi0KLWVs
aWYgdGVzdCAteiAkYXhfY3ZfdnRwbTsgdGhlbiA6Ci0KLSAgICBheF9jdl92dHBtPSJuIgotCi1m
aQotdnRwbT0kYXhfY3ZfdnRwbQotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhlbmFw
aSB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV94ZW5hcGkrc2V0fSIgPSBzZXQ7IHRoZW4g
OgotICBlbmFibGV2YWw9JGVuYWJsZV94ZW5hcGk7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxl
X3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl94ZW5hcGk9Im4iCi0KLWVsaWYg
dGVzdCAieCRlbmFibGVfeGVuYXBpIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9jdl94ZW5h
cGk9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfeGVuYXBpOyB0aGVuIDoKLQotICAgIGF4X2N2
X3hlbmFwaT0ibiIKLQotZmkKLXhlbmFwaT0kYXhfY3ZfeGVuYXBpCi0KLQotCi0jIENoZWNrIHdo
ZXRoZXIgLS1lbmFibGUtcHl0aG9udG9vbHMgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVf
cHl0aG9udG9vbHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9weXRo
b250b29sczsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInhubyI7
IHRoZW4gOgotCi0gICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFi
bGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X3B5dGhvbnRvb2xz
PSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRvb2xzOyB0aGVuIDoKLQotICAgIGF4
X2N2X3B5dGhvbnRvb2xzPSJ5IgotCi1maQotcHl0aG9udG9vbHM9JGF4X2N2X3B5dGhvbnRvb2xz
Ci0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2ZW4uCi1p
ZiB0ZXN0ICIke2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxl
dmFsPSRlbmFibGVfb2NhbWx0b29sczsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0
b29scyIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgotCi1lbGlm
IHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2
X29jYW1sdG9vbHM9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6
Ci0KLSAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgotCi1maQotb2NhbWx0b29scz0kYXhfY3Zfb2Nh
bWx0b29scwotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1pbml0ZXJtIHdhcyBnaXZl
bi4KLWlmIHRlc3QgIiR7ZW5hYmxlX21pbml0ZXJtK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5h
YmxldmFsPSRlbmFibGVfbWluaXRlcm07Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxlX21pbml0
ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKyMgTTQgTWFjcm8gaW5jbHVkZXMKIAotICAgIGF4X2N2X21p
bml0ZXJtPSJuIgogCi1lbGlmIHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4eWVzIjsgdGhl
biA6CiAKLSAgICBheF9jdl9taW5pdGVybT0ieSIKIAotZWxpZiB0ZXN0IC16ICRheF9jdl9taW5p
dGVybTsgdGhlbiA6CiAKLSAgICBheF9jdl9taW5pdGVybT0ibiIKIAotZmkKLW1pbml0ZXJtPSRh
eF9jdl9taW5pdGVybQogCiAKIAotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWxvbW91bnQgd2Fz
IGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0g
IGVuYWJsZXZhbD0kZW5hYmxlX2xvbW91bnQ7Ci1maQogCiAKLWlmIHRlc3QgIngkZW5hYmxlX2xv
bW91bnQiID0gInhubyI7IHRoZW4gOgogCi0gICAgYXhfY3ZfbG9tb3VudD0ibiIKIAotZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICBheF9jdl9sb21v
dW50PSJ5IgogCi1lbGlmIHRlc3QgLXogJGF4X2N2X2xvbW91bnQ7IHRoZW4gOgogCi0gICAgYXhf
Y3ZfbG9tb3VudD0ibiIKIAotZmkKLWxvbW91bnQ9JGF4X2N2X2xvbW91bnQKIAogCiAKLSMgQ2hl
Y2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9k
ZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX2RlYnVnOwotZmkK
IAogCi1pZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6CiAKLSAgICBheF9j
dl9kZWJ1Zz0ibiIKIAotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieHllcyI7IHRoZW4g
OgogCi0gICAgYXhfY3ZfZGVidWc9InkiCiAKLWVsaWYgdGVzdCAteiAkYXhfY3ZfZGVidWc7IHRo
ZW4gOgogCi0gICAgYXhfY3ZfZGVidWc9InkiCiAKLWZpCi1kZWJ1Zz0kYXhfY3ZfZGVidWcKIAog
CiAKQEAgLTQxNjEsMjQgKzIyMDcsNiBAQCBkZWJ1Zz0kYXhfY3ZfZGVidWcKIAogCiAKLWZvciBj
ZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUwotZG8KLSAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRj
ZmxhZyIKLWRvbmUKLWZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCi1kbwotICAgIFBSRVBFTkRf
TERGTEFHUys9IiAtTCRsZGZsYWciCi1kb25lCi1mb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURF
UwotZG8KLSAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgotZG9uZQotZm9yIGxkZmxhZyBp
biAkQVBQRU5EX0xJQgotZG8KLSAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCi1kb25l
Ci1DRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgotTERGTEFH
Uz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiCiAKIAogCkBAIC00
MTkwLDkwNiArMjIxOCwzNDggQEAgTERGTEFHUz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAk
QVBQRU5EX0xERkxBR1MiCiAKIAogCisjIHBrZy5tNCAtIE1hY3JvcyB0byBsb2NhdGUgYW5kIHV0
aWxpc2UgcGtnLWNvbmZpZy4gICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCisjIHNlcmlhbCAx
IChwa2ctY29uZmlnLTAuMjQpCisjCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVzIFJl
bW5hbnQgPHNjb3R0QG5ldHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNv
ZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisjIGl0IHVuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVk
IGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2Yg
dGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisj
CisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQ
QVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkg
b2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGggdGhpcyBwcm9n
cmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5kYXRpb24sIElu
Yy4sIDU5IFRlbXBsZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBV
U0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHBy
b2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBi
eSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1
dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KIAor
IyBQS0dfUFJPR19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KKyMgUEtHX1BST0dfUEtHX0NPTkZJRwogCisjIFBLR19DSEVDS19F
WElTVFMoTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkK
KyMKKyMgQ2hlY2sgdG8gc2VlIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIHNldCBvZiBtb2R1bGVzIGV4
aXN0cy4gIFNpbWlsYXIKKyMgdG8gUEtHX0NIRUNLX01PRFVMRVMoKSwgYnV0IGRvZXMgbm90IHNl
dCB2YXJpYWJsZXMgb3IgcHJpbnQgZXJyb3JzLgorIworIyBQbGVhc2UgcmVtZW1iZXIgdGhhdCBt
NCBleHBhbmRzIEFDX1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05GSUddKQorIyBvbmx5IGF0IHRo
ZSBmaXJzdCBvY2N1cmVuY2UgaW4gY29uZmlndXJlLmFjLCBzbyBpZiB0aGUgZmlyc3QgcGxhY2UK
KyMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBpZiBpdCBpcyB3aXRoaW4g
YW4gImlmIiwgeW91CisjIGhhdmUgdG8gY2FsbCBQS0dfQ0hFQ0tfRVhJU1RTIG1hbnVhbGx5Cisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCiAKLSMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNh
dGUgb3V0cHV0IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMg
bm90IHRydW5jYXRlIG91dHB1dC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1NF
RCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNl
Ci0gICAgICAgICAgICBhY19zY3JpcHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYS9iYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmIvCi0gICAgIGZvciBhY19pIGlu
IDEgMiAzIDQgNSA2IDc7IGRvCi0gICAgICAgYWNfc2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFj
X3NjcmlwdCIKLSAgICAgZG9uZQotICAgICBlY2hvICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8
IHNlZCA5OXEgPmNvbmZ0ZXN0LnNlZAotICAgICB7IGFjX3NjcmlwdD07IHVuc2V0IGFjX3Njcmlw
dDt9Ci0gICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0aGVuCi0gIGFjX3BhdGhfU0VEX2ZvdW5kPWZh
bHNlCi0gICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBv
ZiBQUk9HTkFNRS1MSVNUCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
ICAgIGFjX3BhdGhfU0VEPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgotICAgICAgeyB0
ZXN0IC1mICIkYWNfcGF0aF9TRUQiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwg
Y29udGludWUKLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0
IGlzIGZvdW5kLgotICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfU0VECi1jYXNlIGAiJGFjX3Bh
dGhfU0VEIiAtLXZlcnNpb24gMj4mMWAgaW4KLSpHTlUqKQotICBhY19jdl9wYXRoX1NFRD0iJGFj
X3BhdGhfU0VEIiBhY19wYXRoX1NFRF9mb3VuZD06OzsKLSopCi0gIGFjX2NvdW50PTAKLSAgJGFz
X2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCi0gIHdoaWxlIDoKLSAgZG8KLSAgICBj
YXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgotICAgIG12ICJj
b25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVz
dC5ubCIKLSAgICAkYXNfZWNobyAnJyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRhY19wYXRoX1NF
RCIgLWYgY29uZnRlc3Quc2VkIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2
L251bGwgfHwgYnJlYWsKLSAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9k
ZXYvbnVsbCAyPiYxIHx8IGJyZWFrCi0gICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBh
Y19jb3VudD0kYXNfdmFsCi0gICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURf
bWF4LTB9OyB0aGVuCi0gICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBs
b29raW5nIGZvciBhIGJldHRlciBvbmUKLSAgICAgIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9T
RUQiCi0gICAgICBhY19wYXRoX1NFRF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigy
XjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNf
Y291bnQgLWd0IDEwICYmIGJyZWFrCi0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRl
c3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Ci1lc2FjCiAKLSAgICAgICRhY19wYXRo
X1NFRF9mb3VuZCAmJiBicmVhayAzCi0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNf
c2F2ZV9JRlMKLSAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfU0VEIjsgdGhlbgotICAgIGFzX2Zu
X2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIHNlZCBjb3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIk
TElORU5PIiA1Ci0gIGZpCi1lbHNlCi0gIGFjX2N2X3BhdGhfU0VEPSRTRUQKLWZpCisjIF9QS0df
Q09ORklHKFtWQVJJQUJMRV0sIFtDT01NQU5EXSwgW01PRFVMRVNdKQorIyAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BLR19DT05GSUcKIAotZmkKLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0
aF9TRUQiID4mNQotJGFzX2VjaG8gIiRhY19jdl9wYXRoX1NFRCIgPiY2OyB9Ci0gU0VEPSIkYWNf
Y3ZfcGF0aF9TRUQiCi0gIHJtIC1mIGNvbmZ0ZXN0LnNlZAorIyBfUEtHX1NIT1JUX0VSUk9SU19T
VVBQT1JURUQKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BLR19TSE9SVF9F
UlJPUlNfU1VQUE9SVEVECiAKLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNf
Y29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1Jwot
YWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERG
TEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3Zf
Y19jb21waWxlcl9nbnUKLWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZp
eH1nY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0
OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAt
biAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2MiCi0gICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4g
IiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hv
ICJubyIgPiY2OyB9Ci1maQorIyBQS0dfQ0hFQ0tfTU9EVUxFUyhWQVJJQUJMRS1QUkVGSVgsIE1P
RFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLAorIyBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCisjCisj
CisjIE5vdGUgdGhhdCBpZiB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IHRoZSBmaXJzdCBjYWxsIHRv
CisjIFBLR19DSEVDS19NT0RVTEVTIG1pZ2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3Vy
ZSB0byBpbmNsdWRlIGFuCisjIGV4cGxpY2l0IGNhbGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBp
biB5b3VyIGNvbmZpZ3VyZS5hYworIworIworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBQS0dfQ0hFQ0tfTU9EVUxFUwog
CiAKLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KLSAgYWNfY3RfQ0M9JEND
Ci0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgot
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgot
Zm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0
YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9
OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgotICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lG
UwogCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1pZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Ci1l
bHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKKyMgV2UgZGVmaW5lLCBzZXBhcmF0ZWx5
LCBQVEhSRUFEX0NGTEFHUywgX0xERkxBR1MgYW5kIF9MSUJTCisjIGV2ZW4gdGhvdWdoIGN1cnJl
bnRseSB3ZSBkb24ndCBzZXQgdGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCisjIFRoaXMgbWVhbnMgdGhh
dCB0aGUgbWFrZWZpbGVzIHdpbGwgbm90IG5lZWQgdG8gY2hhbmdlIGluCisjIHRoZSBmdXR1cmUg
aWYgd2UgbWFrZSB0aGUgdGVzdCBtb3JlIHNvcGhpc3RpY2F0ZWQuCiAKLSAgaWYgdGVzdCAieCRh
Y19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIKLSAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2lu
ZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190
b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBDQz0kYWNfY3RfQ0MKLSAgZmkKLWVsc2UKLSAg
Q0M9IiRhY19jdl9wcm9nX0NDIgotZmkKIAotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAgICAg
ICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9Y2M7IGFjX3dv
cmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi
ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhl
bgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2Rp
ciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl
bnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0g
ICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKLSAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9J
RlMKIAotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAtbiAiJENDIjsgdGhlbgot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+
JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0K
LWZpCisjIFdlIGludm9rZSBBWF9QVEhSRUFEX1ZBUlMgd2l0aCB0aGUgbmFtZSBvZiBhbm90aGVy
IG1hY3JvCisjIHdoaWNoIGlzIHRoZW4gZXhwYW5kZWQgb25jZSBmb3IgZWFjaCB2YXJpYWJsZS4K
IAogCi0gIGZpCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
LXNldCBkdW1teSBjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi0gIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRv
Ci0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGlmIHRlc3QgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgotICAgICAg
IGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCi0gICAgICAgY29udGludWUKLSAgICAgZmkKLSAgICBhY19j
dl9wcm9nX0NDPSJjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0g
IGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKIAotaWYgdGVzdCAkYWNfcHJvZ19y
ZWplY3RlZCA9IHllczsgdGhlbgotICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBhdGgsIHNv
IG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCi0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwot
ICBzaGlmdAotICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KLSAgICAjIFdlIGNob3NlIGEgZGlmZmVy
ZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KLSAgICAjIEhvd2V2ZXIsIGl0IGhhcyB0
aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCi0gICAgIyBmaXJz
dCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVsbCBmaWxlIG5h
bWUuCi0gICAgc2hpZnQKLSAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193b3JkJHsxKycg
J30kQCIKLSAgZmkKLWZpCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAi
bm8iID4mNjsgfQotZmkKIAogCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotICBk
bwotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3By
b2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRh
Y190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1l
bHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2
ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3By
ZWZpeCRhY19wcm9nIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAg
ZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwogCi1maQotZmkKLUNDPSRhY19jdl9w
cm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9
Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtZ2l0aHR0cCB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9naXRodHRwK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRl
bmFibGVfZ2l0aHR0cDsKIGZpCiAKIAotICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKLSAgZG9u
ZQotZmkKLWlmIHRlc3QgLXogIiRDQyI7IHRoZW4KLSAgYWNfY3RfQ0M9JENDCi0gIGZvciBhY19w
cm9nIGluIGNsLmV4ZQotZG8KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfcHJv
ZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJGFj
X3Byb2c7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3Rf
Q0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZT
PSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9D
Qz0iJGFjX3Byb2ciCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBm
aQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRo
dHRwIiA9ICJ4bm8iOyB0aGVuIDoKIAotZmkKLWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19j
dF9DQwotaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKLSRhc19lY2hvICIk
YWNfY3RfQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCisgICAg
YXhfY3ZfZ2l0aHR0cD0ibiIKIAorZWxpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVz
IjsgdGhlbiA6CiAKLSAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhawotZG9uZQorICAgIGF4
X2N2X2dpdGh0dHA9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhlbiA6CisK
KyAgICBheF9jdl9naXRodHRwPSJuIgogCi0gIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7
Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0gIGZpCiBmaQorZ2l0aHR0cD0kYXhfY3ZfZ2l0aHR0
cAogCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KK2lm
IHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFs
PSRlbmFibGVfbW9uaXRvcnM7CiBmaQogCiAKLXRlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1
Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9l
cnJvciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAotU2VlIFxg
Y29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CitpZiB0ZXN0ICJ4
JGVuYWJsZV9tb25pdG9ycyIgPSAieG5vIjsgdGhlbiA6CiAKLSMgUHJvdmlkZSBzb21lIGluZm9y
bWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KLSRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQotc2V0IFggJGFj
X2NvbXBpbGUKLWFjX2NvbXBpbGVyPSQyCi1mb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAt
ViAtcXZlcnNpb247IGRvCi0gIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4m
NSIKLWNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNo
bz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190
cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIK
LSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGVyICRh
Y19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKLSAgYWNfc3RhdHVzPSQ/Ci0gIGlmIHRlc3Qg
LXMgY29uZnRlc3QuZXJyOyB0aGVuCi0gICAgc2VkICcxMGFcCi0uLi4gcmVzdCBvZiBzdGRlcnIg
b3V0cHV0IGRlbGV0ZWQgLi4uCi0gICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3Qu
ZXIxCi0gICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKLSAgZmkKLSAgcm0gLWYgY29uZnRlc3QuZXIx
IGNvbmZ0ZXN0LmVycgotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBc
JD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQotZG9uZQorICAg
IGF4X2N2X21vbml0b3JzPSJuIgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCitlbGlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsgdGhlbiA6
CiAKLWludAotbWFpbiAoKQotewotI2lmbmRlZiBfX0dOVUNfXwotICAgICAgIGNob2tlIG1lCi0j
ZW5kaWYKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKIAotICA7Ci0gIHJldHVybiAwOwotfQotX0FD
RU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2NvbXBp
bGVyX2dudT15ZXMKLWVsc2UKLSAgYWNfY29tcGlsZXJfZ251PW5vCi1maQotcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1hY19jdl9j
X2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251CitlbGlmIHRlc3QgLXogJGF4X2N2X21vbml0
b3JzOyB0aGVuIDoKKworICAgIGF4X2N2X21vbml0b3JzPSJ5IgogCiBmaQoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2du
dSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KLWlmIHRlc3Qg
JGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhlbgotICBHQ0M9eWVzCi1lbHNlCi0gIEdDQz0KK21v
bml0b3JzPSRheF9jdl9tb25pdG9ycworCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0
cG0gd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6
CisgIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07CiBmaQotYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mr
c2V0fQotYWNfc2F2ZV9DRkxBR1M9JENGTEFHUwoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKLSRhc19l
Y2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KLWlmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJv
cl9mbGFnCi0gICBhY19jX3dlcnJvcl9mbGFnPXllcwotICAgYWNfY3ZfcHJvZ19jY19nPW5vCi0g
ICBDRkxBR1M9Ii1nIgotICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwogCi1pbnQKLW1haW4gKCkKLXsKIAotICA7Ci0g
IHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWVsc2UKLSAgQ0ZMQUdTPSIiCi0gICAgICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCitpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKIAotaW50
Ci1tYWluICgpCi17CisgICAgYXhfY3ZfdnRwbT0ibiIKIAotICA7Ci0gIHJldHVybiAwOwotfQot
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CitlbGlmIHRl
c3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKIAotZWxzZQotICBhY19jX3dlcnJv
cl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLQkgQ0ZMQUdTPSItZyIKLQkgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAq
LworICAgIGF4X2N2X3Z0cG09InkiCiAKLWludAotbWFpbiAoKQoteworZWxpZiB0ZXN0IC16ICRh
eF9jdl92dHBtOyB0aGVuIDoKKworICAgIGF4X2N2X3Z0cG09Im4iCiAKLSAgOwotICByZXR1cm4g
MDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgot
ICBhY19jdl9wcm9nX2NjX2c9eWVzCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cit2dHBtPSRheF9jdl92dHBtCisKKworCisj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUteGVuYXBpIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5h
YmxlX3hlbmFwaStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hlbmFw
aTsKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInhubyI7IHRoZW4g
OgorCisgICAgYXhfY3ZfeGVuYXBpPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIg
PSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfeGVuYXBpPSJ5IgorCitlbGlmIHRlc3QgLXog
JGF4X2N2X3hlbmFwaTsgdGhlbiA6CisKKyAgICBheF9jdl94ZW5hcGk9Im4iCisKIGZpCi1ybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQK
LSAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZworeGVuYXBpPSRheF9j
dl94ZW5hcGkKKworCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1weXRob250b29scyB3YXMg
Z2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9weXRob250b29scytzZXR9IiA9IHNldDsgdGhlbiA6
CisgIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xzOwogZmkKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKLSRh
c19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KLWlmIHRlc3QgIiRhY190ZXN0X0NGTEFH
UyIgPSBzZXQ7IHRoZW4KLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwotZWxpZiB0ZXN0ICRhY19j
dl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KLSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KLSAg
ICBDRkxBR1M9Ii1nIC1PMiIKLSAgZWxzZQotICAgIENGTEFHUz0iLWciCi0gIGZpCi1lbHNlCi0g
IGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItTzIiCi0gIGVsc2UKLSAg
ICBDRkxBR1M9Ci0gIGZpCisKKworaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInhu
byI7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4iCisKK2VsaWYgdGVzdCAieCRl
bmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRv
b2xzPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRvb2xzOyB0aGVuIDoKKworICAg
IGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4
OS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2N2X3Byb2df
Y2NfYzg5PW5vCi1hY19zYXZlX0NDPSRDQwotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGFyZy5o
PgotI2luY2x1ZGUgPHN0ZGlvLmg+Ci0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8
c3lzL3N0YXQuaD4KLS8qIE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZy
b20gUkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KLXN0cnVjdCBidWYgeyBpbnQgeDsgfTsKLUZJ
TEUgKiAoKnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Ci1zdGF0
aWMgY2hhciAqZSAocCwgaSkKLSAgICAgY2hhciAqKnA7Ci0gICAgIGludCBpOwotewotICByZXR1
cm4gcFtpXTsKLX0KLXN0YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50KSwg
Y2hhciAqKnAsIC4uLikKLXsKLSAgY2hhciAqczsKLSAgdmFfbGlzdCB2OwotICB2YV9zdGFydCAo
dixwKTsKLSAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKLSAgdmFfZW5kICh2KTsKLSAgcmV0
dXJuIHM7Ci19CitweXRob250b29scz0kYXhfY3ZfcHl0aG9udG9vbHMKIAotLyogT1NGIDQuMCBD
b21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMK
LSAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hh
cmFjdGVyIGNvbnN0YW50cy4KLSAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5mb3J0
dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAotICAgYXMgJ3gnLiAgVGhlIGZv
bGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAotICAg
cHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMgb3V0
IHRydWUsIGZvciBhbgotICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5IHRv
IHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCi0gICB0aGF0J3MgdHJ1ZSBvbmx5IHdp
dGggLXN0ZC4gICovCi1pbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFdOwog
Ci0vKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0IHJl
cGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKLSAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0ZXIg
Y29uc3RhbnRzLiAgKi8KLSNkZWZpbmUgRk9PKHgpICd4JwotaW50IHhsYzZfY2NfYXJyYXlbRk9P
KGEpID09ICd4JyA/IDEgOiAtMV07CiAKLWludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOwotc3Ry
dWN0IHMxIHtpbnQgKCpmKSAoaW50IGEpO307Ci1zdHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUg
YSk7fTsKLWludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYg
Kiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOwotaW50IGFyZ2M7Ci1jaGFyICoqYXJn
djsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0gIHx8
ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9G
Ci1mb3IgYWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBc
Ci0JLUFlICItQWEgLURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKLWRvCi0g
IENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgotICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19hcmcKKyMgQ2hlY2sgd2hldGhl
ciAtLWVuYWJsZS1vY2FtbHRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX29jYW1s
dG9vbHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xz
OwogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKLSAgdGVz
dCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIgJiYgYnJlYWsKLWRvbmUKLXJtIC1mIGNv
bmZ0ZXN0LiRhY19leHQKLUNDPSRhY19zYXZlX0NDCisKKworaWYgdGVzdCAieCRlbmFibGVfb2Nh
bWx0b29scyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitl
bGlmIHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4
X2N2X29jYW1sdG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhl
biA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgogCiBmaQotIyBBQ19DQUNIRV9WQUwKLWNh
c2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCi0gIHgpCi0gICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vbmUgbmVlZGVkIiA+JjUKLSRhc19lY2hv
ICJub25lIG5lZWRlZCIgPiY2OyB9IDs7Ci0gIHhubykKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdW5zdXBwb3J0ZWQiID4mNQotJGFzX2VjaG8g
InVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKLSAgKikKLSAgICBDQz0iJENDICRhY19jdl9wcm9nX2Nj
X2M4OSIKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODki
ID4mNjsgfSA7OwotZXNhYwotaWYgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0
aGVuIDoKK29jYW1sdG9vbHM9JGF4X2N2X29jYW1sdG9vbHMKKworCiAKKyMgQ2hlY2sgd2hldGhl
ciAtLWVuYWJsZS1taW5pdGVybSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9taW5pdGVy
bStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOwogZmkK
IAotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21waWxlPSckQ0MgLWMg
JENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19saW5rPSckQ0MgLW8g
Y29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRh
Y19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQog
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRo
ZXIgbG4gLXMgd29ya3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3
b3Jrcy4uLiAiID4mNjsgfQotTE5fUz0kYXNfbG5fcwotaWYgdGVzdCAiJExOX1MiID0gImxuIC1z
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8sIHVzaW5nICRMTl9TIiA+JjUK
LSRhc19lY2hvICJubywgdXNpbmcgJExOX1MiID4mNjsgfQoraWYgdGVzdCAieCRlbmFibGVfbWlu
aXRlcm0iID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbWluaXRlcm09Im4iCisKK2VsaWYg
dGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X21p
bml0ZXJtPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAg
IGF4X2N2X21pbml0ZXJtPSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKwor
CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbG9tb3VudCB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV9sb21vdW50K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVf
bG9tb3VudDsKIGZpCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0UpLi4uICIgPiY2
OyB9Ci1zZXQgeCAke01BS0UtbWFrZX0KLWFjX21ha2U9YCRhc19lY2hvICIkMiIgfCBzZWQgJ3Mv
Ky9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAotaWYgZXZhbCAidGVzdCBcIlwke2FjX2N2X3By
b2dfbWFrZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9BQ0VPRgot
U0hFTEwgPSAvYmluL3NoCi1hbGw6Ci0JQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUlJScKLV9B
Q0VPRgotIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4i
LCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgotY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNvbmZ0ZXN0
Lm1ha2UgMj4vZGV2L251bGxgIGluCi0gICpAQEAlJSU9Pyo9QEBAJSUlKikKLSAgICBldmFsIGFj
X2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OwotICAqKQotICAgIGV2YWwgYWNfY3Zf
cHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKLWVzYWMKLXJtIC1mIGNvbmZ0ZXN0Lm1ha2UK
KworaWYgdGVzdCAieCRlbmFibGVfbG9tb3VudCIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9j
dl9sb21vdW50PSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInh5ZXMiOyB0
aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbG9t
b3VudDsgdGhlbiA6CisKKyAgICBheF9jdl9sb21vdW50PSJuIgorCiBmaQotaWYgZXZhbCB0ZXN0
IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVzOyB0aGVuCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2Vj
aG8gInllcyIgPiY2OyB9Ci0gIFNFVF9NQUtFPQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7
IH0KLSAgU0VUX01BS0U9Ik1BS0U9JHtNQUtFLW1ha2V9IgorbG9tb3VudD0kYXhfY3ZfbG9tb3Vu
dAorCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWRlYnVnIHdhcyBnaXZlbi4KK2lmIHRl
c3QgIiR7ZW5hYmxlX2RlYnVnK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfZGVidWc7CiBmaQogCi0jIEZpbmQgYSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZl
ciBhIEMgcHJvZ3JhbSAoZmFzdGVyKSwKLSMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFu
b3RoZXIuICBCdXQgYXZvaWQgdGhlIGJyb2tlbiBvcgotIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6
Ci0jIFN5c1YgL2V0Yy9pbnN0YWxsLCAvdXNyL3NiaW4vaW5zdGFsbAotIyBTdW5PUyAvdXNyL2V0
Yy9pbnN0YWxsCi0jIElSSVggL3NiaW4vaW5zdGFsbAotIyBBSVggL2Jpbi9pbnN0YWxsCi0jIEFt
aWdhT1MgL0MvaW5zdGFsbCwgd2hpY2ggaW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlz
Y3MKLSMgQUlYIDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhv
dXQgYSAtZyBmbGFnCi0jIEFGUyAvdXNyL2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5k
bGVzIG5vbmV4aXN0ZW50IGFyZ3MKLSMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmll
cyB0byB1c2UgdGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiIKLSMgT1MvMidzIHN5c3RlbSBp
bnN0YWxsLCB3aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYwotIyAuL2lu
c3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2lu
c3RhbGwuc2guCi0jIFJlamVjdCBpbnN0YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwg
bXVsdGlwbGUgZmlsZXMuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwiID4mNQotJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQotaWYgdGVz
dCAteiAiJElOU1RBTEwiOyB0aGVuCi1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgK
LWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
LSAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFU
SCBlbGVtZW50cy4KLWNhc2UgJGFzX2Rpci8gaW4gIygoCi0gIC4vIHwgLi8vIHwgL1tjQ10vKiB8
IFwKLSAgL2V0Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3Iv
YWZzd3MvYmluLyogfCBcCi0gID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9d
T1MyW1xcL11JTlNUQUxMW1xcL10qIHwgXAotICAvdXNyL3VjYi8qICkgOzsKLSAgKikKLSAgICAj
IE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgot
ICAgICMgRG9uJ3QgdXNlIGluc3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1
ZmYgYXMgcm9vdAotICAgICMgYnkgZGVmYXVsdC4KLSAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFs
bCBzY29pbnN0IGluc3RhbGw7IGRvCi0gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLQlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0JICBpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAgICBncmVwIGRz
cG1zZyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVu
Ci0JICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29u
dmVudGlvbi4KLQkgICAgOgotCSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAg
ICBncmVwIHB3cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAy
PiYxOyB0aGVuCi0JICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5
IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgotCSAgICA6Ci0JICBlbHNlCi0JICAgIHJtIC1yZiBjb25m
dGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgotCSAgICBlY2hvIG9uZSA+IGNvbmZ0
ZXN0Lm9uZQotCSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0LnR3bwotCSAgICBta2RpciBjb25mdGVz
dC5kaXIKLQkgICAgaWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0
Lm9uZSBjb25mdGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKLQkgICAgICB0ZXN0IC1z
IGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgotCSAgICAgIHRlc3QgLXMg
Y29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAmJgotCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGly
L2NvbmZ0ZXN0LnR3bwotCSAgICB0aGVuCi0JICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNf
ZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgotCSAgICAgIGJyZWFrIDMKLQkgICAgZmkKLQkg
IGZpCi0JZmkKLSAgICAgIGRvbmUKLSAgICBkb25lCi0gICAgOzsKLWVzYWMKIAotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6
CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAi
eHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfZGVidWc7IHRoZW4gOgogCi1ybSAtcmYgY29uZnRlc3Qub25lIGNvbmZ0ZXN0LnR3byBjb25m
dGVzdC5kaXIKKyAgICBheF9jdl9kZWJ1Zz0ieSIKIAogZmkKLSAgaWYgdGVzdCAiJHthY19jdl9w
YXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KLSAgICBJTlNUQUxMPSRhY19jdl9wYXRoX2lu
c3RhbGwKLSAgZWxzZQotICAgICMgQXMgYSBsYXN0IHJlc29ydCwgdXNlIHRoZSBzbG93IHNoZWxs
IHNjcmlwdC4gIERvbid0IGNhY2hlIGEKLSAgICAjIHZhbHVlIGZvciBJTlNUQUxMIHdpdGhpbiBh
IHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2UgdGhhdCB3aWxsCi0gICAgIyBicmVhayBvdGhlciBw
YWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBkaXJlY3RvcnkgaXMKLSAgICAjIHJlbW92
ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZlIG5hbWUuCi0gICAgSU5TVEFMTD0kYWNf
aW5zdGFsbF9zaAotICBmaQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkSU5TVEFMTCIgPiY1Ci0kYXNfZWNobyAiJElOU1RBTEwiID4mNjsgfQor
ZGVidWc9JGF4X2N2X2RlYnVnCiAKLSMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlz
aGFuZGxlcyBicmFjZXMgaW4gJHt2YXItdmFsfS4KLSMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9z
ZSBicmFjZSBlbmRzIHRoZSB2YXJpYWJsZSBzdWJzdGl0dXRpb24uCi10ZXN0IC16ICIkSU5TVEFM
TF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCiAKLXRlc3QgLXogIiRJ
TlNUQUxMX1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCiAKLXRlc3QgLXog
IiRJTlNUQUxMX0RBVEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCiAKLSMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQot
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfUEVSTCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJFBFUkwgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0g
IGFjX2N2X3BhdGhfUEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0g
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBm
aQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJMPSJubyIKLSAgOzsKLWVzYWMKLWZpCi1QRVJMPSRh
Y19jdl9wYXRoX1BFUkwKLWlmIHRlc3QgLW4gIiRQRVJMIjsgdGhlbgotICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFBFUkwiID4mNQotJGFzX2VjaG8g
IiRQRVJMIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQogCiAKLWlm
IHRlc3QgeCIke1BFUkx9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCBwZXJsLCBwbGVhc2UgaW5zdGFsbCBwZXJsIiAiJExJTkVOTyIgNQotZmkKLWlm
IHRlc3QgIngkeGFwaSIgPSAieHkiOyB0aGVuIDoKIAotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgotc2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf
Y3ZfcGF0aF9DVVJMK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKLWVsc2UKLSAgY2FzZSAkQ1VSTCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNf
Y3ZfcGF0aF9DVVJMPSIkQ1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0
aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKK2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNMVURF
UwogZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3Zf
cGF0aF9DVVJMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgotICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRj
ZmxhZyIKIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworZm9yIGxkZmxhZyBpbiAkUFJF
UEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2Zv
ciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkk
Y2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9M
REZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxB
R1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRB
UFBFTkRfTERGTEFHUyIKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9w
YXRoX0NVUkw9Im5vIgotICA7OwotZXNhYwotZmkKLUNVUkw9JGFjX2N2X3BhdGhfQ1VSTAotaWYg
dGVzdCAtbiAiJENVUkwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Ci0kYXNfZWNobyAiJENVUkwiID4mNjsgfQotZWxz
ZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCiAKIAotaWYgdGVzdCB4IiR7Q1VSTH0iID09
IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29u
ZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKLWZpCi0gICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1hNTCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJFhNTCBpbgotICBbXFwvXSogfCA/
OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3Nh
dmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVh
ayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIk
YWNfY3ZfcGF0aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKLSAgOzsKLWVzYWMKLWZpCi1Y
TUw9JGFjX2N2X3BhdGhfWE1MCi1pZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1Ci0kYXNfZWNo
byAiJFhNTCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKIAogCi1p
ZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElO
RU5PIiA1Ci1maQogCi1maQotaWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRoZW4gOgog
Ci0gICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl
Zml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBk
dW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgorCisKKworCisKKworIyBD
aGVja3MgZm9yIHByb2dyYW1zLgorYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCith
Y19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUn
CithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRM
REZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19j
dl9jX2NvbXBpbGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJl
Zml4fWdjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxDK3NldH0i
ID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhl
biA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRP
Q0FNTEMiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9w
cm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQogYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSApA
QCAtNTA5OCw3ICsyNTY4LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
ICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
ICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3By
b2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIKKyAgICBhY19jdl9wcm9nX0NDPSIk
e2FjX3Rvb2xfcHJlZml4fWdjYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh
ayAyCiAgIGZpCkBAIC01MTA4LDEwICsyNTc4LDEwIEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkK
IGZpCi1PQ0FNTEM9JGFjX2N2X3Byb2dfT0NBTUxDCi1pZiB0ZXN0IC1uICIkT0NBTUxDIjsgdGhl
bgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MQyIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MQyIgPiY2OyB9CitDQz0kYWNfY3ZfcHJvZ19DQwor
aWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQog
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KQEAgLTUxMTksMTcgKzI1ODksMTcgQEAgZmkKIAogCiBm
aQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgotICBhY19jdF9PQ0FNTEM9
JE9DQU1MQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxjOyBhY193b3Jk
PSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
ICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAi
JHthY19jdl9wcm9nX2FjX2N0X09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgot
ICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0iJGFjX2N0X09DQU1MQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBh
c19kaXIgaW4gJFBBVEgKQEAgLTUxMzgsNyArMjYwOCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0ib2NhbWxjIgorICAgIGFjX2N2X3Byb2df
YWNfY3RfQ0M9ImdjYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC01MTQ4LDE3ICsyNjE4LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1h
Y19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDCi1pZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X09DQU1MQyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MQyIgPiY2
OyB9CithY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0ND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQogZWxzZQogICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog
JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEMiID0g
eDsgdGhlbgotICAgIE9DQU1MQz0ibm8iCisgIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgorICAgIENDPSIiCiAgIGVsc2UKICAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCiB5ZXM6KQpAQCAtNTE2Niw0MSArMjYzNiwyMyBAQCB5ZXM6KQogJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBlc2FjCi0gICAgT0NBTUxD
PSRhY19jdF9PQ0FNTEMKKyAgICBDQz0kYWNfY3RfQ0MKICAgZmkKIGVsc2UKLSAgT0NBTUxDPSIk
YWNfY3ZfcHJvZ19PQ0FNTEMiCisgIENDPSIkYWNfY3ZfcHJvZ19DQyIKIGZpCiAKLQotICBpZiB0
ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCi0gICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAt
diB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAotICAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NhbWwgdmVyc2lvbiBp
cyAkT0NBTUxWRVJTSU9OIiA+JjUKLSRhc19lY2hvICJPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZF
UlNJT04iID4mNjsgfQotICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0Ci0gICAgIGlm
IHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgotICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAt
d2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAK
LSAgICAgZWxzZQotICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjUK
LSRhc19lY2hvICJPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNjsg
fQotICAgICBmaQotICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogT0NhbWwgbGlicmFyeSBwYXRoIGlzICRPQ0FNTExJQiIgPiY1Ci0kYXNfZWNobyAi
T0NhbWwgbGlicmFyeSBwYXRoIGlzICRPQ0FNTExJQiIgPiY2OyB9Ci0KLQotCi0KLSAgICAgIyBj
aGVja2luZyBmb3Igb2NhbWxvcHQKLSAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4Ijsg
dGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQ7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRDQyI7
IHRoZW4KKyAgICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJl
Zml4fWNjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9
IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIk
T0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiRPQ0FNTE9QVCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVs
c2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4g
JFBBVEgKQEAgLTUyMDksNyArMjY2MSw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFz
X2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg
JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh
Y19jdl9wcm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0IgorICAgIGFjX2N2
X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTIxOSwyOSArMjY3MSwzMCBAQCBJRlM9JGFzX3NhdmVf
SUZTCiAKIGZpCiBmaQotT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKLWlmIHRlc3QgLW4g
IiRPQ0FNTE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7IH0K
K0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8g
IiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCisgIGZp
CiBmaQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N0X09D
QU1MT1BUPSRPQ0FNTE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBvY2Ft
bG9wdDsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0ND
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BUIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MT1BUPSIkYWNfY3RfT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9
bm8KIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4g
JFBBVEgKIGRvCkBAIC01MjQ5LDcgKzI3MDIsMTEgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgot
ICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgorICAgIGlmIHRlc3QgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgorICAgICAg
IGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29udGludWUKKyAgICAgZmkKKyAgICBhY19j
dl9wcm9nX0NDPSJjYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC01MjU3LDYwICsyNzE0LDQ0IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lG
UwogCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91bmQg
YSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAgc2V0
IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgor
ICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgor
ICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2ls
bCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFt
ZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2dfQ0M9
IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQogZmkKIGZpCi1hY19jdF9PQ0FNTE9Q
VD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BU
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X09DQU1MT1BUIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUxPUFQiID4mNjsg
fQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFz
X2VjaG8gIiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAot
ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE9QVD0ibm8i
Ci0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15
ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFz
X2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAg
T0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCi0gIGZpCi1lbHNlCi0gIE9DQU1MT1BUPSIkYWNfY3Zf
cHJvZ19PQ0FNTE9QVCIKLWZpCi0KLSAgICAgT0NBTUxCRVNUPWJ5dGUKLSAgICAgaWYgdGVzdCAi
JE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KLQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxh
dGlvbiBvbmx5LiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBv
Y2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9Ci0gICAgIGVsc2UKLQlU
TVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwp
JHxcMXxwJyBgCi0JaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRo
ZW4KLQkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQot
JGFzX2VjaG8gInZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRl
ZC4iID4mNjsgfQotCSAgICBPQ0FNTE9QVD1ubwotCWVsc2UKLQkgICAgT0NBTUxCRVNUPW9wdAot
CWZpCi0gICAgIGZpCi0KIAotCi0gICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKLSAgICAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMu
b3B0OyBhY193b3JkPSQyCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBpZiB0ZXN0IC1u
ICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNsLmV4ZQorICBkbwor
ICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ci
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY190
b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P
Q0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0ND
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgaWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTENE
T1RPUFQ9IiRPQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgor
ICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICkBAIC01MzE5LDcgKzI3NjAsNyBAQCBk
bwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIKKyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVm
aXgkYWNfcHJvZyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZp
CkBAIC01MzI5LDQzOCArMjc3MCw3MTUgQEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9D
QU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQKLWlmIHRlc3QgLW4gIiRPQ0FNTENE
T1RPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKLSRhc19lY2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7
IH0KK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2Vj
aG8gIiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCisg
ICAgdGVzdCAtbiAiJENDIiAmJiBicmVhaworICBkb25lCiBmaQotaWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxDRE9UT1BUIjsgdGhlbgotICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RP
VE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYy5vcHQiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sYy5vcHQ7IGFj
X3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZvciBh
Y19wcm9nIGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNf
cHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JGFjX3Byb2c7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1M
Q0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
Q0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BUIjsgdGhlbgotICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MQ0RPVE9QVD0iJGFjX2N0X09DQU1MQ0RPVE9QVCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBh
c19kaXIgaW4gJFBBVEgKIGRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSJvY2FtbGMub3B0IgotICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX3Byb2ci
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAi
JGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
KyAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRlc3QgIngkYWNf
Y3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitmaQorCitmaQor
CisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJv
cjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBD
IGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0
YWlscyIgIiRMSU5FTk8iIDUgOyB9CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0
IHRoZSBjb21waWxlci4KKyRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2Fj
X2NvbXBpbGVyPSQyCitmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247
IGRvCisgIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigo
JGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7
CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJc
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIk
YWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1
IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3Qu
ZXJyOyB0aGVuCisgICAgc2VkICcxMGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0
ZWQgLi4uCisgICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0
IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVy
cgorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorZG9uZQorCitjYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisK
K2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFu
X2ZpbGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCithY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2Zp
bGVzIGEub3V0IGEub3V0LmRTWU0gYS5leGUgYi5vdXQiCisjIFRyeSB0byBjcmVhdGUgYW4gZXhl
Y3V0YWJsZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNyZWdhcmQgYS5vdXQuCisjIEl0IHdpbGwgaGVs
cCB1cyBkaWFnbm9zZSBicm9rZW4gY29tcGlsZXJzLCBhbmQgZmluZGluZyBvdXQgYW4gaW50dWl0
aW9uCisjIG9mIGV4ZWV4dC4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3JrcyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzLi4uICIgPiY2OyB9CithY19s
aW5rX2RlZmF1bHQ9YCRhc19lY2hvICIkYWNfbGluayIgfCBzZWQgJ3MvIC1vICpjb25mdGVzdFte
IF0qLy8nYAorCisjIFRoZSBwb3NzaWJsZSBvdXRwdXQgZmlsZXM6CithY19maWxlcz0iYS5vdXQg
Y29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFfb3V0LmV4ZSBiLm91dCBjb25mdGVzdC4qIgor
CithY19ybWZpbGVzPQorZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzCitkbworICBjYXNlICRhY19m
aWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAq
LnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5v
YmogKSA7OworICAgICogKSBhY19ybWZpbGVzPSIkYWNfcm1maWxlcyAkYWNfZmlsZSI7OworICBl
c2FjCitkb25lCitybSAtZiAkYWNfcm1maWxlcworCitpZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19k
ZWZhdWx0IgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3Ry
eV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFs
IGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNo
b1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfbGlua19k
ZWZhdWx0IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH07IHRoZW4gOgorICAjIEF1dG9jb25mLTIuMTMgY291bGQgc2V0IHRoZSBhY19jdl9leGVl
eHQgdmFyaWFibGUgdG8gYG5vJy4KKyMgU28gaWdub3JlIGEgdmFsdWUgb2YgYG5vJywgb3RoZXJ3
aXNlIHRoaXMgd291bGQgbGVhZCB0byBgRVhFRVhUID0gbm8nCisjIGluIGEgTWFrZWZpbGUuICBX
ZSBzaG91bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4ZWV4dCBpZiBpdCB3YXMgY2FjaGVkLAorIyBz
byB0aGF0IHRoZSB1c2VyIGNhbiBzaG9ydC1jaXJjdWl0IHRoaXMgdGVzdCBmb3IgY29tcGlsZXJz
IHVua25vd24gdG8KKyMgQXV0b2NvbmYuCitmb3IgYWNfZmlsZSBpbiAkYWNfZmlsZXMgJycKK2Rv
CisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQorICBjYXNlICRhY19maWxlIGluCisg
ICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAq
LmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKQorCTs7
CisgICAgW2FiXS5vdXQgKQorCSMgV2UgZm91bmQgdGhlIGRlZmF1bHQgZXhlY3V0YWJsZSwgYnV0
IGV4ZWV4dD0nJyBpcyBtb3N0CisJIyBjZXJ0YWlubHkgcmlnaHQuCisJYnJlYWs7OworICAgICou
KiApCisJaWYgdGVzdCAiJHthY19jdl9leGVleHQrc2V0fSIgPSBzZXQgJiYgdGVzdCAiJGFjX2N2
X2V4ZWV4dCIgIT0gbm87CisJdGhlbiA6OyBlbHNlCisJICAgYWNfY3ZfZXhlZXh0PWBleHByICIk
YWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCisJZmkKKwkjIFdlIHNldCBhY19jdl9leGVleHQg
aGVyZSBiZWNhdXNlIHRoZSBsYXRlciB0ZXN0IGZvciBpdCBpcyBub3QKKwkjIHNhZmU6IGNyb3Nz
IGNvbXBpbGVycyBtYXkgbm90IGFkZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKKwkjIGFy
Z3VtZW50LCBzbyB3ZSBtYXkgbmVlZCB0byBrbm93IGl0IGF0IHRoYXQgcG9pbnQgYWxyZWFkeS4K
KwkjIEV2ZW4gaWYgdGhpcyBzZWN0aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFzIHRoZSBhZHZhbnRh
Z2Ugb2YKKwkjIGFjdHVhbGx5IHdvcmtpbmcuCisJYnJlYWs7OworICAgICogKQorCWJyZWFrOzsK
KyAgZXNhYwogZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCit0ZXN0ICIkYWNfY3ZfZXhl
ZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KIAotZmkKLWZpCi1hY19jdF9PQ0FNTENET1RPUFQ9
JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUCi1pZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxD
RE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X09DQU1MQ0RPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1M
Q0RPVE9QVCIgPiY2OyB9CiBlbHNlCisgIGFjX2ZpbGU9JycKK2ZpCitpZiB0ZXN0IC16ICIkYWNf
ZmlsZSI7IHRoZW4gOgogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCiskYXNfZWNobyAiJGFz
X21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFj
X2V4dCA+JjUKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQ0RPVE9QVCIgPSB4OyB0aGVuCi0g
ICAgT0NBTUxDRE9UT1BUPSJubyIKLSAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzok
YWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5l
ZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FNTENET1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAotICBm
aQoreyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mMjt9Cithc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBjYW5ub3QgY3JlYXRlIGV4ZWN1dGFi
bGVzCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0K
IGVsc2UKLSAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFz
X2VjaG8gInllcyIgPiY2OyB9CiBmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQg
ZmlsZSBuYW1lLi4uICIgPiY2OyB9Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhY19maWxlIiA+JjY7IH0K
K2FjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0CiAKLSAgICAgaWYgdGVzdCAiJE9DQU1MQ0RPVE9QVCIg
IT0gIm5vIjsgdGhlbgotCVRNUFZFUlNJT049YCRPQ0FNTENET1RPUFQgLXYgfCBzZWQgLW4gLWUg
J3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCi0JaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9
ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KLQkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1s
Yy5vcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j
YW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KLQllbHNlCi0JICAgIE9DQU1MQz0k
T0NBTUxDRE9UT1BUCi0JZmkKLSAgICAgZmkKLQotICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9w
dC5vcHQKLSAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsgdGhlbgotCWlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7
IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MT1BURE9U
T1BUPSIkT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgot
ZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBp
biAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQi
Ci0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQorcm0gLWYgLXIg
YS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25mdGVzdCRhY19jdl9leGVleHQgYi5vdXQKK2FjX2Ns
ZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxlcy4uLiAiID4mNjsg
fQoraWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiog
fCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0k
YWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUK
KyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3Qg
JGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgorICAjIElmIGJvdGggYGNvbmZ0ZXN0LmV4ZScgYW5k
IGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAod2VsbCwgb2JzZXJ2YWJsZSkKKyMgY2F0Y2ggYGNv
bmZ0ZXN0LmV4ZScuICBGb3IgaW5zdGFuY2Ugd2l0aCBDeWd3aW4sIGBscyBjb25mdGVzdCcgd2ls
bAorIyB3b3JrIHByb3Blcmx5IChpLmUuLCByZWZlciB0byBgY29uZnRlc3QuZXhlJyksIHdoaWxl
IGl0IHdvbid0IHdpdGgKKyMgYHJtJy4KK2ZvciBhY19maWxlIGluIGNvbmZ0ZXN0LmV4ZSBjb25m
dGVzdCBjb25mdGVzdC4qOyBkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAg
Y2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8
ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8
ICoubyB8ICoub2JqICkgOzsKKyAgICAqLiogKSBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxl
IiA6ICdbXi5dKlwoXC4uKlwpJ2AKKwkgIGJyZWFrOzsKKyAgICAqICkgYnJlYWs7OworICBlc2Fj
CiBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1PQ0FNTE9QVERPVE9Q
VD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAotaWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BU
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MT1BURE9UT1BUIiA+JjUKLSRhc19lY2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsg
fQogZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAi
Y2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVzOiBjYW5ub3QgY29tcGlsZSBhbmQg
bGluaworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9
CiBmaQorcm0gLWYgY29uZnRlc3QgY29uZnRlc3QkYWNfY3ZfZXhlZXh0Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2V4ZWV4dCIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9CiAKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQK
K0VYRUVYVD0kYWNfY3ZfZXhlZXh0CithY19leGVleHQ9JEVYRUVYVAorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lu
Y2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK0ZJTEUgKmYgPSBmb3BlbiAoImNvbmZ0
ZXN0Lm91dCIsICJ3Iik7CisgcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAwOwog
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5f
ZmlsZXMgY29uZnRlc3Qub3V0IgorIyBDaGVjayB0aGF0IHRoZSBjb21waWxlciBwcm9kdWNlcyBl
eGVjdXRhYmxlcyB3ZSBjYW4gcnVuLiAgSWYgbm90LCBlaXRoZXIKKyMgdGhlIGNvbXBpbGVyIGlz
IGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5nIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZy4u
LiAiID4mNjsgfQoraWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgIT0geWVzOyB0aGVuCisgIHsg
eyBhY190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8
ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7
Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFs
ICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0
dXMgPSAwOyB9CisgIGlmIHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCcKKyAgeyB7
IGNhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c
JGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRh
c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX3RyeSIpIDI+JjUKKyAg
YWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwk
PyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9OyB0aGVuCisg
ICAgY3Jvc3NfY29tcGlsaW5nPW5vCisgIGVsc2UKKyAgICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGls
aW5nIiA9IG1heWJlOyB0aGVuCisJY3Jvc3NfY29tcGlsaW5nPXllcworICAgIGVsc2UKKwl7IHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30K
K2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMuCitJZiB5b3Ug
bWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNlIFxgLS1ob3N0Jy4KK1NlZSBcYGNvbmZpZy5sb2cn
IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAgIGZpCisgIGZpCiBmaQotaWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCi0gIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
Im9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTE9QVERPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGNyb3NzX2NvbXBpbGluZyIgPiY1
CiskYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIgPiY2OyB9CisKK3JtIC1mIGNvbmZ0ZXN0LiRh
Y19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNvbmZ0ZXN0Lm91dAorYWNfY2xlYW5fZmlsZXM9
JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3Zfb2JqZXh0K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsg
dGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUPSIkYWNfY3RfT0NBTUxPUFRE
T1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAg
SUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE9QVERPVE9QVD0ib2NhbWxvcHQub3B0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4m
NQotICAgIGJyZWFrIDIKLSAgZmkKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitybSAtZiBjb25mdGVzdC5vIGNvbmZ0ZXN0Lm9i
agoraWYgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpc
IiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNo
bz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+
JjUKKyAgKGV2YWwgIiRhY19jb21waWxlIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cisg
IHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgorICBmb3IgYWNfZmlsZSBpbiBjb25mdGVz
dC5vIGNvbmZ0ZXN0Lm9iaiBjb25mdGVzdC4qOyBkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwg
Y29udGludWU7CisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwg
Ki50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5p
bmYgfCAqLmRTWU0gKSA7OworICAgICopIGFjX2N2X29iamV4dD1gZXhwciAiJGFjX2ZpbGUiIDog
Jy4qXC5cKC4qXCknYAorICAgICAgIGJyZWFrOzsKKyAgZXNhYwogZG9uZQotICBkb25lCi1JRlM9
JGFzX3NhdmVfSUZTCitlbHNlCisgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdh
czoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQogCit7IHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2Zu
X2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3Qg
Y29tcGlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUg
OyB9CiBmaQorcm0gLWYgY29uZnRlc3QuJGFjX2N2X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CiBm
aQotYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQK
LWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE9QVERPVE9Q
VCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7IH0KK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb2JqZXh0IiA+
JjUKKyRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KK09CSkVYVD0kYWNfY3Zfb2JqZXh0
CithY19vYmpleHQ9JE9CSkVYVAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNv
bXBpbGVyLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJfZ251K3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRh
c19lY2hvICJubyIgPiY2OyB9Ci1maQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKLSAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTE9QVERPVE9QVCIgPSB4OyB0aGVuCi0gICAgT0NBTUxPUFRET1RPUFQ9Im5vIgotICBl
bHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwotICAgIE9DQU1M
T1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERPVE9QVAotICBmaQoraW50CittYWluICgpCit7Cisj
aWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hva2UgbWUKKyNlbmRpZgorCisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY29tcGlsZXJfZ251PXllcwogZWxzZQotICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3By
b2dfT0NBTUxPUFRET1RPUFQiCisgIGFjX2NvbXBpbGVyX2dudT1ubwogZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorYWNfY3Zf
Y19jb21waWxlcl9nbnU9JGFjX2NvbXBpbGVyX2dudQogCi0JaWYgdGVzdCAiJE9DQU1MT1BURE9U
T1BUIiAhPSAibm8iOyB0aGVuCi0JICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAotCSAgIGlmIHRlc3QgIiRU
TVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCi0JICAgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9t
IG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNQotJGFzX2VjaG8gInZlcnNpb24g
ZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQotCSAg
IGVsc2UKLQkgICAgICBPQ0FNTE9QVD0kT0NBTUxPUFRET1RPUFQKLQkgICBmaQotICAgICAgICBm
aQotICAgICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX2Nv
bXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7IHRoZW4K
KyAgR0NDPXllcworZWxzZQorICBHQ0M9CitmaQorYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0
fQorYWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9m
bGFnCisgICBhY19jX3dlcnJvcl9mbGFnPXllcworICAgYWNfY3ZfcHJvZ19jY19nPW5vCisgICBD
RkxBR1M9Ii1nIgorICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwogCitpbnQKK21haW4gKCkKK3sKIAotICBmaQorICA7
CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P
IjsgdGhlbiA6CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKK2Vsc2UKKyAgQ0ZMQUdTPSIiCisgICAg
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u
ZmRlZnMuaC4gICovCiAKK2ludAorbWFpbiAoKQorewogCisgIDsKKyAgcmV0dXJuIDA7Cit9Citf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKIAotICAjIGNo
ZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgi
OyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1v
Y2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By
b2dfT0NBTUwrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgotZWxzZQotICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUw9
IiRPQ0FNTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCi1hc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwot
ICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX09D
QU1MPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot
ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworICBhY19j
X3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKKwkgQ0ZMQUdTPSItZyIKKwkgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworCitpbnQKK21haW4gKCkKK3sKIAorICA7CisgIHJldHVybiAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2df
Y2NfZz15ZXMKIGZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKIGZpCi1PQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAotaWYgdGVzdCAt
biAiJE9DQU1MIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJE9DQU1MIiA+JjUKLSRhc19lY2hvICIkT0NBTUwiID4mNjsgfQotZWxzZQot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAogZmkKLQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0
LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9y
X2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9n
X09DQU1MIjsgdGhlbgotICBhY19jdF9PQ0FNTD0kT0NBTUwKLSAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICJvY2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgb2NhbWw7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj
X2N0X09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KK2lm
IHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4KKyAgQ0ZMQUdTPSRhY19zYXZlX0NG
TEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KKyAgaWYgdGVzdCAi
JEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1nIC1PMiIKKyAgZWxzZQorICAgIENGTEFH
Uz0iLWciCisgIGZpCiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KLSAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0iJGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9
Ii1PMiIKKyAgZWxzZQorICAgIENGTEFHUz0KKyAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJ
U08gQzg5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2Vw
dCBJU08gQzg5Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfYzg5K3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKKyAg
YWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3NhdmVfQ0M9JENDCitjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVk
ZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4K
KyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyogTW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFy
ZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYuc2guICAqLworc3RydWN0IGJ1ZiB7IGlu
dCB4OyB9OworRklMRSAqICgqcmNzb3BlbikgKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwg
aW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBpKQorICAgICBjaGFyICoqcDsKKyAgICAgaW50IGk7
Cit7CisgIHJldHVybiBwW2ldOworfQorc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFy
ICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQoreworICBjaGFyICpzOworICB2YV9saXN0IHY7Cisg
IHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAocCwgdmFfYXJnICh2LGludCkpOworICB2YV9lbmQg
KHYpOworICByZXR1cm4gczsKK30KKworLyogT1NGIDQuMCBDb21wYXEgY2MgaXMgc29tZSBzb3J0
IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMKKyAgIGZ1bmN0aW9uIHByb3RvdHlw
ZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hhcmFjdGVyIGNvbnN0YW50cy4KKyAg
IFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5mb3J0dW5hdGVseSwgaW5zdGVhZCBhcmUg
c2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gnLiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVy
cm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAorICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1
cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMgb3V0IHRydWUsIGZvciBhbgorICAgYXJy
YXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5IHRvIHdyaXRlICdceDAwJz09MCB0byBn
ZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICovCitpbnQgb3Nm
NF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFdOworCisvKiBJQk0gQyA2IGZvciBBSVgg
aXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRl
cnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0ZXIgY29uc3RhbnRzLiAgKi8KKyNkZWZp
bmUgRk9PKHgpICd4JworaW50IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07
CisKK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOworc3RydWN0IHMxIHtpbnQgKCpmKSAoaW50
IGEpO307CitzdHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUgYSk7fTsKK2ludCBwYWlybmFtZXMg
KGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50
KSwgaW50LCBpbnQpOworaW50IGFyZ2M7CitjaGFyICoqYXJndjsKK2ludAorbWFpbiAoKQorewor
cmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2LCAxKSAhPSBh
cmd2WzFdOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitmb3IgYWNfYXJnIGluICcnIC1x
bGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBcCisJLUFlICItQWEgLURfSFBVWF9T
T1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKIGRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgotICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgQ0M9IiRhY19zYXZl
X0NDICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhu
byIgJiYgYnJlYWsKIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworcm0gLWYgY29uZnRl
c3QuJGFjX2V4dAorQ0M9JGFjX3NhdmVfQ0MKIAogZmkKLWZpCi1hY19jdF9PQ0FNTD0kYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgotICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1M
IiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUwiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8g
Im5vIiA+JjY7IH0KLWZpCi0KLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTCIgPSB4OyB0aGVuCi0g
ICAgT0NBTUw9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29s
X3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7
OworIyBBQ19DQUNIRV9WQUwKK2Nhc2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCisgIHgpCisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vbmUg
bmVlZGVkIiA+JjUKKyRhc19lY2hvICJub25lIG5lZWRlZCIgPiY2OyB9IDs7CisgIHhubykKKyAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdW5zdXBw
b3J0ZWQiID4mNQorJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKKyAgKikKKyAgICBD
Qz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7OwogZXNhYwotICAgIE9DQU1MPSRhY19jdF9P
Q0FNTAotICBmaQotZWxzZQotICBPQ0FNTD0iJGFjX2N2X3Byb2dfT0NBTUwiCitpZiB0ZXN0ICJ4
JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCiBmaQogCithY19leHQ9YworYWNf
Y3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFH
UyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVl
eHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUn
CithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CiAKLSAgIyBjaGVja2luZyBm
b3Igb2NhbWxkZXAKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxkZXA7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1M
REVQK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0Up
Li4uICIgPiY2OyB9CitzZXQgeCAke01BS0UtbWFrZX0KK2FjX21ha2U9YCRhc19lY2hvICIkMiIg
fCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAoraWYgZXZhbCAidGVzdCBcIlwk
e2FjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MREVQ
IjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJHthY190b29sX3ByZWZp
eH1vY2FtbGRlcCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZp
Ci1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKKyAgY2F0ID5jb25mdGVzdC5t
YWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAvYmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1B
S0UpPUBAQCUlJScKK19BQ0VPRgorIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFd
OiBFbnRlcmluZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1h
a2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUl
KikKKyAgICBldmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQor
ICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1m
IGNvbmZ0ZXN0Lm1ha2UKIGZpCi1PQ0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAotaWYgdGVz
dCAtbiAiJE9DQU1MREVQIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJE9DQU1MREVQIiA+JjUKLSRhc19lY2hvICIkT0NBTUxERVAiID4m
NjsgfQoraWYgZXZhbCB0ZXN0IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVz
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisgIFNFVF9NQUtFPQogZWxzZQogICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog
JGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgU0VUX01BS0U9Ik1BS0U9JHtNQUtFLW1ha2V9IgogZmkK
IAotCi1maQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxERVAiOyB0aGVuCi0gIGFjX2N0
X09DQU1MREVQPSRPQ0FNTERFUAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1s
ZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBv
Y2FtbGRlcDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxE
RVArc2V0fSIgPSBzZXQ7IHRoZW4gOgorIyBGaW5kIGEgZ29vZCBpbnN0YWxsIHByb2dyYW0uICBX
ZSBwcmVmZXIgYSBDIHByb2dyYW0gKGZhc3RlciksCisjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29v
ZCBhcyBhbm90aGVyLiAgQnV0IGF2b2lkIHRoZSBicm9rZW4gb3IKKyMgaW5jb21wYXRpYmxlIHZl
cnNpb25zOgorIyBTeXNWIC9ldGMvaW5zdGFsbCwgL3Vzci9zYmluL2luc3RhbGwKKyMgU3VuT1Mg
L3Vzci9ldGMvaW5zdGFsbAorIyBJUklYIC9zYmluL2luc3RhbGwKKyMgQUlYIC9iaW4vaW5zdGFs
bAorIyBBbWlnYU9TIC9DL2luc3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxv
cHB5IGRpc2NzCisjIEFJWCA0IC91c3IvYmluL2luc3RhbGxic2QsIHdoaWNoIGRvZXNuJ3Qgd29y
ayB3aXRob3V0IGEgLWcgZmxhZworIyBBRlMgL3Vzci9hZnN3cy9iaW4vaW5zdGFsbCwgd2hpY2gg
bWlzaGFuZGxlcyBub25leGlzdGVudCBhcmdzCisjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hp
Y2ggdHJpZXMgdG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCisjIE9TLzIncyBz
eXN0ZW0gaW5zdGFsbCwgd2hpY2ggaGFzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc2VtYW50aWMK
KyMgLi9pbnN0YWxsLCB3aGljaCBjYW4gYmUgZXJyb25lb3VzbHkgY3JlYXRlZCBieSBtYWtlIGZy
b20gLi9pbnN0YWxsLnNoLgorIyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0aGF0IGNhbm5vdCBp
bnN0YWxsIG11bHRpcGxlIGZpbGVzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwuLi4gIiA+JjY7IH0K
K2lmIHRlc3QgLXogIiRJTlNUQUxMIjsgdGhlbgoraWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3Rh
bGwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxERVA9IiRhY19jdF9PQ0FNTERFUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGFz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgK
IGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
LSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
LSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot
ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1maQot
ZmkKLWFjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQCi1pZiB0ZXN0IC1u
ICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxERVAiID4mNQotJGFzX2VjaG8gIiRhY19j
dF9PQ0FNTERFUCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQot
ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7IHRoZW4KLSAgICBPQ0FNTERFUD0ibm8i
Ci0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15
ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFz
X2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7CisgICAgIyBBY2Nv
dW50IGZvciBwZW9wbGUgd2hvIHB1dCB0cmFpbGluZyBzbGFzaGVzIGluIFBBVEggZWxlbWVudHMu
CitjYXNlICRhc19kaXIvIGluICMoKAorICAuLyB8IC4vLyB8IC9bY0NdLyogfCBcCisgIC9ldGMv
KiB8IC91c3Ivc2Jpbi8qIHwgL3Vzci9ldGMvKiB8IC9zYmluLyogfCAvdXNyL2Fmc3dzL2Jpbi8q
IHwgXAorICA/OltcXC9db3MyW1xcL11pbnN0YWxsW1xcL10qIHwgPzpbXFwvXU9TMltcXC9dSU5T
VEFMTFtcXC9dKiB8IFwKKyAgL3Vzci91Y2IvKiApIDs7CisgICopCisgICAgIyBPU0YxIGFuZCBT
Q08gT0RUIDMuMCBoYXZlIHRoZWlyIG93biBuYW1lcyBmb3IgaW5zdGFsbC4KKyAgICAjIERvbid0
IHVzZSBpbnN0YWxsYnNkIGZyb20gT1NGIHNpbmNlIGl0IGluc3RhbGxzIHN0dWZmIGFzIHJvb3QK
KyAgICAjIGJ5IGRlZmF1bHQuCisgICAgZm9yIGFjX3Byb2cgaW4gZ2luc3RhbGwgc2NvaW5zdCBp
bnN0YWxsOyBkbworICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisJaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
CSAgaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBkc3Btc2cgIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgorCSAgICAjIEFJ
WCBpbnN0YWxsLiAgSXQgaGFzIGFuIGluY29tcGF0aWJsZSBjYWxsaW5nIGNvbnZlbnRpb24uCisJ
ICAgIDoKKwkgIGVsaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBwd3Bs
dXMgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgor
CSAgICAjIHByb2dyYW0tc3BlY2lmaWMgaW5zdGFsbCBzY3JpcHQgdXNlZCBieSBIUCBwd3BsdXMt
LWRvbid0IHVzZS4KKwkgICAgOgorCSAgZWxzZQorCSAgICBybSAtcmYgY29uZnRlc3Qub25lIGNv
bmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwkgICAgZWNobyBvbmUgPiBjb25mdGVzdC5vbmUKKwkg
ICAgZWNobyB0d28gPiBjb25mdGVzdC50d28KKwkgICAgbWtkaXIgY29uZnRlc3QuZGlyCisJICAg
IGlmICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAtYyBjb25mdGVzdC5vbmUgY29uZnRl
c3QudHdvICJgcHdkYC9jb25mdGVzdC5kaXIiICYmCisJICAgICAgdGVzdCAtcyBjb25mdGVzdC5v
bmUgJiYgdGVzdCAtcyBjb25mdGVzdC50d28gJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRp
ci9jb25mdGVzdC5vbmUgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRpci9jb25mdGVzdC50
d28KKwkgICAgdGhlbgorCSAgICAgIGFjX2N2X3BhdGhfaW5zdGFsbD0iJGFzX2Rpci8kYWNfcHJv
ZyRhY19leGVjX2V4dCAtYyIKKwkgICAgICBicmVhayAzCisJICAgIGZpCisJICBmaQorCWZpCisg
ICAgICBkb25lCisgICAgZG9uZQorICAgIDs7CiBlc2FjCi0gICAgT0NBTUxERVA9JGFjX2N0X09D
QU1MREVQCi0gIGZpCi1lbHNlCi0gIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKLWZp
Ci0KIAotICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCi0gIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sbWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p
ZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9Q
IjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMK
LSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29s
X3ByZWZpeH1vY2FtbG1rdG9wIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFr
IDIKLSAgZmkKLWRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCitybSAtcmYgY29uZnRl
c3Qub25lIGNvbmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwogZmkKKyAgaWYgdGVzdCAiJHthY19j
dl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KKyAgICBJTlNUQUxMPSRhY19jdl9wYXRo
X2luc3RhbGwKKyAgZWxzZQorICAgICMgQXMgYSBsYXN0IHJlc29ydCwgdXNlIHRoZSBzbG93IHNo
ZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKKyAgICAjIHZhbHVlIGZvciBJTlNUQUxMIHdpdGhp
biBhIHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2UgdGhhdCB3aWxsCisgICAgIyBicmVhayBvdGhl
ciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBkaXJlY3RvcnkgaXMKKyAgICAjIHJl
bW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZlIG5hbWUuCisgICAgSU5TVEFMTD0k
YWNfaW5zdGFsbF9zaAorICBmaQogZmkKLU9DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxNS1RP
UAotaWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1Ci0kYXNfZWNobyAi
JE9DQU1MTUtUT1AiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElOU1RBTEwi
ID4mNQorJGFzX2VjaG8gIiRJTlNUQUxMIiA+JjY7IH0KIAorIyBVc2UgdGVzdCAteiBiZWNhdXNl
IFN1bk9TNCBzaCBtaXNoYW5kbGVzIGJyYWNlcyBpbiAke3Zhci12YWx9LgorIyBJdCB0aGlua3Mg
dGhlIGZpcnN0IGNsb3NlIGJyYWNlIGVuZHMgdGhlIHZhcmlhYmxlIHN1YnN0aXR1dGlvbi4KK3Rl
c3QgLXogIiRJTlNUQUxMX1BST0dSQU0iICYmIElOU1RBTExfUFJPR1JBTT0nJHtJTlNUQUxMfScK
IAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCi0gIGFjX2N0
X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBk
dW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit0ZXN0IC16ICIkSU5TVEFMTF9TQ1JJUFQiICYm
IElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworCit0ZXN0IC16ICIkSU5TVEFMTF9EQVRBIiAm
JiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0JworCisjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgInBlcmwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IHBlcmw7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MTUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRoX1BF
Ukwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LVE9QPSIkYWNfY3RfT0NBTUxNS1RPUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp
ZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
CisgIGNhc2UgJFBFUkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfUEVS
TD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor
ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3Ig
YXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtUT1A9Im9jYW1sbWt0b3AiCisgICAgYWNf
Y3ZfcGF0aF9QRVJMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTU3NjgsNTMgKzM0ODYsNDYgQEAg
ZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhf
UEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJMPSJubyIKKyAgOzsKK2VzYWMKIGZpCi1maQotYWNfY3Rf
T0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QCi1pZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxNS1RPUCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9QIiA+JjUKLSRhc19lY2hvICIkYWNfY3Rf
T0NBTUxNS1RPUCIgPiY2OyB9CitQRVJMPSRhY19jdl9wYXRoX1BFUkwKK2lmIHRlc3QgLW4gIiRQ
RVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19l
Y2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4
OyB0aGVuCi0gICAgT0NBTUxNS1RPUD0ibm8iCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAot
ICBmaQotZWxzZQotICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgotZmkKIAor
aWYgdGVzdCB4IiR7UEVSTH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kIHBlcmwsIHBsZWFzZSBpbnN0YWxsIHBlcmwiICIkTElORU5PIiA1CitmaQor
aWYgdGVzdCAieCR4YXBpIiA9ICJ4eSI7IHRoZW4gOgogCi0gICMgY2hlY2tpbmcgZm9yIG9jYW1s
bWtsaWIKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZp
eH1vY2FtbG1rbGliOyBhY193b3JkPSQyCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgY3VybC1jb25maWc7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9n
X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRoX0NV
Ukwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTE1L
TElCPSIkT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNl
Ci1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGNhc2UgJENVUkwgaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQ1VSTD0iJENVUkwiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBk
bwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9n
X09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICBhY19jdl9wYXRo
X0NVUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCiAgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTgyMiwzOSArMzUzMyw0NCBAQCBkb25lCiAg
IGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAm
JiBhY19jdl9wYXRoX0NVUkw9Im5vIgorICA7OworZXNhYwogZmkKLWZpCi1PQ0FNTE1LTElCPSRh
Y19jdl9wcm9nX09DQU1MTUtMSUIKLWlmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgotICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtM
SUIiID4mNQotJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KK0NVUkw9JGFjX2N2X3BhdGhf
Q1VSTAoraWYgdGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENVUkwiID4m
NjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAoraWYgdGVzdCB4IiR7
Q1VSTH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k
IGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKIGZp
Ci1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIjsgdGhlbgotICBhY19jdF9PQ0FN
TE1LTElCPSRPQ0FNTE1LTElCCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxt
a2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
b2NhbWxta2xpYjsgYWNfd29yZD0kMgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
eG1sMi1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15IHhtbDItY29uZmlnOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0
aF9YTUwrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgog
ZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KLSAgYWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTE1LTElCPSIkYWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCisgIGNhc2UgJFhNTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9Y
TUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor
ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3Ig
YXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9Im9jYW1sbWtsaWIiCisgICAgYWNf
Y3ZfcGF0aF9YTUw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCiAgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTg2Miw0NCArMzU3OCwzOSBAQCBk
b25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9Y
TUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMKIGZpCi1maQotYWNfY3RfT0NB
TUxNS0xJQj0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCCi1pZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxNS0xJQiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LTElCIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NB
TUxNS0xJQiIgPiY2OyB9CitYTUw9JGFjX2N2X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFhNTCIgPiY1CiskYXNfZWNobyAiJFhNTCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8i
ID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgot
ICAgIE9DQU1MTUtMSUI9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRh
Y190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv
b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVk
PXllcyA7OwotZXNhYwotICAgIE9DQU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKLSAgZmkKLWVs
c2UKLSAgT0NBTUxNS0xJQj0iJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiIKKworaWYgdGVzdCB4IiR7
WE1MfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQg
eG1sMi1jb25maWcsIHBsZWFzZSBpbnN0YWxsIHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQogZmkK
IAorZmkKK2lmIHRlc3QgIngkb2NhbWx0b29scyIgPSAieHkiOyB0aGVuIDoKIAotICAjIGNoZWNr
aW5nIGZvciBvY2FtbGRvYworICAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjCiAgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3Jk
PSQyCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft
bGMiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19PQ0FNTERPQytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NB
TUxDK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVs
c2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MRE9D
PSIkT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0
IC1uICIkT0NBTUxDIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQz0iJE9DQU1MQyIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICkBAIC01OTA4LDcgKzM2MTksNyBA
QCBkbwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJHthY190
b29sX3ByZWZpeH1vY2FtbGRvYyIKKyAgICBhY19jdl9wcm9nX09DQU1MQz0iJHthY190b29sX3By
ZWZpeH1vY2FtbGMiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBm
aQpAQCAtNTkxOCwxMCArMzYyOSwxMCBAQCBJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotT0NB
TUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKLWlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4K
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERPQyIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KK09DQU1MQz0kYWNfY3ZfcHJv
Z19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+JjUKKyRhc19lY2hvICIk
T0NBTUxDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CkBAIC01OTI5LDE3
ICszNjQwLDE3IEBAIGZpCiAKIAogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MRE9D
IjsgdGhlbgotICBhY19jdF9PQ0FNTERPQz0kT0NBTUxET0MKLSAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICJvY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCi1zZXQgZHVtbXkgb2NhbWxkb2M7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9w
cm9nX09DQU1MQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxDPSRPQ0FNTEMKKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3Byb2dfYWNfY3RfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19j
dl9wcm9nX2FjX2N0X09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRoZW4K
LSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09DQU1MRE9DIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQyI7IHRo
ZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9IiRhY19jdF9PQ0FNTEMiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSApAQCAtNTk0OCw3ICszNjU5LDcgQEAgZG8K
ICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9jYW1s
ZG9jIgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSJvY2FtbGMiCiAgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTk1OCwxNyArMzY2OSwxNyBAQCBJ
RlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotYWNfY3RfT0NBTUxET0M9JGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxET0MKLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRoZW4KLSAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERP
QyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MRE9DIiA+JjY7IH0KK2FjX2N0X09DQU1MQz0k
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxDIiA+JjY7IH0KIGVsc2UKICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
ICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxET0Mi
ID0geDsgdGhlbgotICAgIE9DQU1MRE9DPSJubyIKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEMi
ID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCiAgIGVsc2UKICAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCiB5ZXM6KQpAQCAtNTk3NiwyNCArMzY4Nyw0MSBAQCB5
ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBl
c2FjCi0gICAgT0NBTUxET0M9JGFjX2N0X09DQU1MRE9DCisgICAgT0NBTUxDPSRhY19jdF9PQ0FN
TEMKICAgZmkKIGVsc2UKLSAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgorICBPQ0FN
TEM9IiRhY19jdl9wcm9nX09DQU1MQyIKIGZpCiAKIAotICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1
aWxkCi0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxidWlsZDsgYWNfd29yZD0kMgorICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVu
CisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24q
ICpcKC4qXCkkfFwxfHAnYAorICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjUKKyRhc19l
Y2hvICJPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT04iID4mNjsgfQorICAgICAjIElmIE9D
QU1MTElCIGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhl
bgorICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1M
QyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NBTUxMSUIgcHJldmlv
dXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjUKKyRhc19lY2hvICJPQ0FNTExJQiBwcmV2aW91
c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNjsgfQorICAgICBmaQorICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NhbWwgbGlicmFyeSBwYXRo
IGlzICRPQ0FNTExJQiIgPiY1CiskYXNfZWNobyAiT0NhbWwgbGlicmFyeSBwYXRoIGlzICRPQ0FN
TExJQiIgPiY2OyB9CisKKworCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQKKyAgICAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQ7
IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQlVJTEQrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BUK3NldH0iID0gc2V0OyB0
aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAi
JE9DQU1MQlVJTEQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0IC1uICIkT0NBTUxP
UFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiRPQ0FNTE9QVCIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICkBAIC02MDAyLDcgKzM3MzAsNyBAQCBkbwog
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sYnVpbGQiCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE9QVD0iJHthY190b29sX3By
ZWZpeH1vY2FtbG9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02MDEyLDEwICszNzQwLDEwIEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1P
Q0FNTEJVSUxEPSRhY19jdl9wcm9nX09DQU1MQlVJTEQKLWlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxE
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MQlVJTEQiID4mNQotJGFzX2VjaG8gIiRPQ0FNTEJVSUxEIiA+JjY7IH0KK09DQU1M
T1BUPSRhY19jdl9wcm9nX09DQU1MT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxP
UFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAi
bm8iID4mNjsgfQpAQCAtNjAyMywxNyArMzc1MSwxNyBAQCBmaQogCiAKIGZpCi1pZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIjsgdGhlbgotICBhY19jdF9PQ0FNTEJVSUxEPSRPQ0FN
TEJVSUxECi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxidWlsZDsg
YWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFQiOyB0aGVuCisgIGFj
X2N0X09DQU1MT1BUPSRPQ0FNTE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9j
YW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSBvY2FtbG9wdDsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NB
TUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgogZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxCVUlMRCI7IHRoZW4KLSAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTEJVSUxEPSIkYWNfY3RfT0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKQEAgLTYwNDIsNyArMzc3MCw3IEBAIGRv
CiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9Im9j
YW1sYnVpbGQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0ib2NhbWxvcHQiCiAgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjA1MiwxNyArMzc4
MCwxNyBAQCBJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotYWNfY3RfT0NBTUxCVUlMRD0kYWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxECi1pZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxCVUlMRCI7
IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdF9PQ0FNTEJVSUxEIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUxCVUlMRCIgPiY2
OyB9CithY19jdF9PQ0FNTE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVAoraWYgdGVzdCAt
biAiJGFjX2N0X09DQU1MT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BUIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3RfT0NBTUxPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAK
LSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KLSAgICBPQ0FNTEJVSUxE
PSJubyIKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxP
UFQ9Im5vIgogICBlbHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgogeWVzOikKQEAgLTYwNzAsNDQgKzM3OTgsNDkgQEAgeWVzOikKICRhc19lY2hvICIkYXNf
bWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp
cGxldCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7OwogZXNhYwotICAgIE9DQU1MQlVJTEQ9
JGFjX2N0X09DQU1MQlVJTEQKKyAgICBPQ0FNTE9QVD0kYWNfY3RfT0NBTUxPUFQKICAgZmkKIGVs
c2UKLSAgT0NBTUxCVUlMRD0iJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCIKKyAgT0NBTUxPUFQ9IiRh
Y19jdl9wcm9nX09DQU1MT1BUIgogZmkKIAorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0
ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNv
bXBpbGF0aW9uIG9ubHkuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IENhbm5vdCBm
aW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIgPiYyO30KKyAgICAgZWxz
ZQorCVRNUFZFUlNJT049YCRPQ0FNTE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpc
KC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04i
IDsgdGhlbgorCSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLiIg
PiY1CiskYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlz
Y2FyZGVkLiIgPiY2OyB9CisJICAgIE9DQU1MT1BUPW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9
b3B0CisJZmkKKyAgICAgZmkKIAotICAgIGlmIHRlc3QgIngkT0NBTUxDIiA9ICJ4bm8iOyB0aGVu
IDoKLQotICAgICAgICBpZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIjsgdGhl
biA6Ci0KLSAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJPY2FtbCB0b29scyBlbmFibGVkLCBi
dXQgdW5hYmxlIHRvIGZpbmQgT2NhbWwiICIkTElORU5PIiA1Ci1maQotICAgICAgICBvY2FtbHRv
b2xzPSJuIgogCi1maQogCi1maQotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiYXNoIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBiYXNoOyBh
Y193b3JkPSQyCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgaWYgdGVzdCAt
biAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0OyBhY193
b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoK
K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgog
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRCQVNIIGluCi0gIFtc
XC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9UT1BU
IjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVf
SUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0JBU0g9IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxjLm9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh
ayAyCiAgIGZpCkBAIC02MTE1LDU2ICszODQ4LDM5IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19z
YXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3BhdGhfQkFT
SD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotQkFTSD0kYWNfY3ZfcGF0aF9CQVNICi1pZiB0ZXN0IC1u
ICIkQkFTSCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRCQVNIIiA+JjUKLSRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitmaQorT0NBTUxD
RE9UT1BUPSRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9Q
VCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRPQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTENET1RPUFQiID4mNjsgfQog
ZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7QkFTSH0i
ID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gs
IHBsZWFzZSBpbnN0YWxsIGJhc2giICIkTElORU5PIiA1Ci1maQotaWYgdGVzdCAieCRweXRob250
b29scyIgPSAieHkiOyB0aGVuIDoKLQotICAgIGlmIGVjaG8gIiRQWVRIT04iIHwgZ3JlcCAtcSAi
Xi8iOyB0aGVuIDoKLQotICAgICAgICBQWVRIT05QQVRIPSRQWVRIT04KLSAgICAgICAgUFlUSE9O
PWBiYXNlbmFtZSAkUFlUSE9OUEFUSGAKLQotZWxpZiB0ZXN0IC16ICIkUFlUSE9OIjsgdGhlbiA6
Ci0gIFBZVEhPTj0icHl0aG9uIgotZWxzZQotICBhc19mbl9lcnJvciAkPyAiUFlUSE9OIHNwZWNp
ZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoIiAiJExJTkVOTyIgNQogZmkKLSAgICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRQWVRIT04iLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRQWVRIT047IGFjX3dvcmQ9JDIKK2lmIHRl
c3QgLXogIiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxDRE9U
T1BUPSRPQ0FNTENET1RPUFQKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMu
b3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBv
Y2FtbGMub3B0OyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBm
b3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QWVRIT05QQVRI
K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENE
T1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgog
ZWxzZQotICBjYXNlICRQWVRIT05QQVRIIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19j
dl9wYXRoX1BZVEhPTlBBVEg9IiRQWVRIT05QQVRIIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BUIjsgdGhl
bgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVD0iJGFjX2N0X09DQU1MQ0RPVE9QVCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFz
X3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN
TENET1RPUFQ9Im9jYW1sYy5vcHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJl
YWsgMgogICBmaQpAQCAtNjE3MiwxNDAgKzM4ODgsMTcyIEBAIGRvbmUKICAgZG9uZQogSUZTPSRh
c19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1BZVEhPTlBBVEgiICYmIGFjX2N2
X3BhdGhfUFlUSE9OUEFUSD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotUFlUSE9OUEFUSD0kYWNfY3Zf
cGF0aF9QWVRIT05QQVRICi1pZiB0ZXN0IC1uICIkUFlUSE9OUEFUSCI7IHRoZW4KLSAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQWVRIT05QQVRIIiA+
JjUKLSRhc19lY2hvICIkUFlUSE9OUEFUSCIgPiY2OyB9CitmaQorYWNfY3RfT0NBTUxDRE9UT1BU
PSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1M
Q0RPVE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FN
TENET1RPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQot
aWYgdGVzdCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3Ig
JD8gIlVuYWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElO
RU5PIiA1Ci1maQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KLWAkUFlUSE9OIC1j
ICdpbXBvcnQgc3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikp
J2AKLWlmIHRlc3QgIiQ/IiAhPSAiMCIKLXRoZW4KLSAgICBweXRob25fdmVyc2lvbj1gJFBZVEhP
TiAtViAyPiYxYAotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotICAgIGFzX2ZuX2Vycm9yICQ/
ICIkcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlz
IDIuMyIgIiRMSU5FTk8iIDUKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsg
dGhlbgorICAgIE9DQU1MQ0RPVE9QVD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RP
UFQKKyAgZmkKIGVsc2UKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQorICBPQ0FNTENET1RP
UFQ9IiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCIKIGZpCiAKLWFjX3B5dGhvbl92ZXJzaW9uPWAk
UFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50IGRpc3R1
dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIlZFUlNJT04iKSdgCi1hY19wcmV2aW91c19j
cHBmbGFncz0kQ1BQRkxBR1MKLUNQUEZMQUdTPSIkQ0ZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQg
ZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50ICItSSIgKyBkaXN0dXRpbHMuc3lzY29u
ZmlnLmdldF9jb25maWdfdmFyKCJJTkNMVURFUFkiKSdgIgotQ1BQRkxBR1M9IiRDUFBGTEFHUyBg
JFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0
dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJDRkxBR1MiKSdgIgotYWNfcHJldmlvdXNf
bGRmbGFncz0kTERGTEFHUwotTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBk
aXN0dXRpbHMuc3lzY29uZmlnOyBcCi0gICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRf
Y29uZmlnX3ZhcigiTElCUyIpJ2AiCi1MREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1w
b3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmln
LmdldF9jb25maWdfdmFyKCJTWVNMSUJTIiknYCIKLUxERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9O
IC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50ICItTCIgKyBkaXN0
dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBsYXRfc3BlY2lmaWM9MSxcCi0gICAgc3Rh
bmRhcmRfbGliPTEpICsgIi9jb25maWciJ2AiCi1MREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAt
YyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0dXRpbHMuc3lz
Y29uZmlnLmdldF9jb25maWdfdmFyKCJMSU5LRk9SU0hBUkVEIiknYCIKLUxERkxBR1M9IiRMREZM
QUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50
IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIkxERkxBR1MiKSdgIgorICAgICBp
ZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1M
Q0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlp
ZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlm
ZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19lY2hvICJ2
ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsg
fQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBmaQogCi1hY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiUHl0aG9uLmgiICJhY19jdl9oZWFk
ZXJfUHl0aG9uX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVh
ZGVyX1B5dGhvbl9oIiA9IHgiInllczsgdGhlbiA6CisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1s
b3B0Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJaWYgdGVz
dCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg
b2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9w
dDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBp
ZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQ9IiRPQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9w
dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAorZmkKK2ZpCitPQ0FNTE9QVERPVE9QVD0kYWNfY3Zf
cHJvZ19PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1M
T1BURE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsgfQogZWxzZQot
ICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgUHl0aG9uIGRldmVsb3BtZW50IGhlYWRl
cnMiICIkTElORU5PIiA1CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1hc19hY19M
aWI9YCRhc19lY2hvICJhY19jdl9saWJfcHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uJydfUHlBcmdf
UGFyc2VUdXBsZSIgfCAkYXNfdHJfc2hgCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciBQeUFyZ19QYXJzZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5
dGhvbl92ZXJzaW9uIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBQeUFyZ19QYXJzZVR1
cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uLi4uICIgPiY2OyB9Ci1pZiBldmFsICJ0
ZXN0IFwiXCR7JGFzX2FjX0xpYitzZXR9XCIiID0gc2V0OyB0aGVuIDoKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFRET1RP
UFQ9JE9DQU1MT1BURE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxv
cHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSBvY2FtbG9wdC5vcHQ7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MT1BURE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxw
eXRob24kYWNfcHl0aG9uX3ZlcnNpb24gICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlk
ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBj
aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAg
YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5
LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIFB5QXJn
X1BhcnNlVHVwbGUgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBQeUFyZ19QYXJzZVR1cGxl
ICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6Ci0gIGV2YWwgIiRhc19hY19MaWI9eWVzIgorICBpZiB0ZXN0IC1uICIk
YWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE
T1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCiBlbHNlCi0gIGV2YWwgIiRhc19hY19MaWI9bm8iCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BU
RE9UT1BUPSJvY2FtbG9wdC5vcHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi1ybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkK
LWV2YWwgYWNfcmVzPVwkJGFzX2FjX0xpYgotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3Jl
cyIgPiY2OyB9Ci1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0xpYiJcIiA9IHgieWVzIjsgdGhl
biA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZF
X0xJQnB5dGhvbiRhY19weXRob25fdmVyc2lvbiIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQot
ICBMSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiAkTElCUyIKK2FjX2N0X09DQU1MT1BU
RE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8g
IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKIAorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BURE9UT1BUIiA9IHg7IHRoZW4K
KyAgICBPQ0FNTE9QVERPVE9QVD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxp
bmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93
YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxPUFRET1RPUFQ9JGFjX2N0X09DQU1MT1BURE9U
T1BUCisgIGZpCiBlbHNlCi0gIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRh
YmxlIHB5dGhvbiBkZXZlbG9wbWVudCBsaWJyYXJ5IiAiJExJTkVOTyIgNQorICBPQ0FNTE9QVERP
VE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiCiBmaQogCi1DUFBGTEFHUz0kYWNfcHJl
dmlvdXNfY3BwZmxhZ3MKLUxETEZBR1M9JGFjX3ByZXZpb3VzX2xkZmxhZ3MKKwlpZiB0ZXN0ICIk
T0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRE
T1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAg
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbiBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIgPiY1CiskYXNfZWNo
byAidmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIg
PiY2OyB9CisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZp
CisgICAgICAgIGZpCisgICAgIGZpCiAKIAotZmkKLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0
IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCisgIGZpCisKKworCisgICMgY2hlY2tpbmcgZm9y
IG9jYW1sIHRvcGxldmVsCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xf
cHJlZml4fW9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVY
VCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUwrc2V0fSIg
PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNl
ICRYR0VUVEVYVCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YR0VUVEVY
VD0iJFhHRVRURVhUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0
aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor
ICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUw9IiRPQ0FNTCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFz
X3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1hHRVRURVhUPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsg
MgogICBmaQpAQCAtNjMxMyw0NCArNDA2MSwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2
ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIgJiYgYWNfY3ZfcGF0aF9Y
R0VUVEVYVD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotWEdFVFRFWFQ9JGFjX2N2X3BhdGhfWEdFVFRF
WFQKLWlmIHRlc3QgLW4gIiRYR0VUVEVYVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1Ci0kYXNfZWNobyAiJFhH
RVRURVhUIiA+JjY7IH0KK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAtbiAi
JE9DQU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJE9DQU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQogZWxzZQogICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog
JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4
Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4dCwg
cGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1CiBmaQotIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KLXNldCBkdW1teSBhczg2OyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19P
Q0FNTCI7IHRoZW4KKyAgYWNfY3RfT0NBTUw9JE9DQU1MCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9BUzg2
K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTCtz
ZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0g
IGNhc2UgJEFTODYgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQVM4Nj0i
JEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7
OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0iJGFj
X2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
QVM4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MPSJvY2FtbCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02MzU4LDQ0ICs0MTAxLDUzIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lG
UwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0FTODYiICYmIGFjX2N2X3BhdGhfQVM4Nj0ibm8i
Ci0gIDs7Ci1lc2FjCiBmaQotQVM4Nj0kYWNfY3ZfcGF0aF9BUzg2Ci1pZiB0ZXN0IC1uICIkQVM4
NiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRBUzg2IiA+JjUKLSRhc19lY2hvICIkQVM4NiIgPiY2OyB9CitmaQorYWNfY3RfT0NBTUw9
JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KIGVsc2UKICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRh
c19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIke0FTODZ9IiA9PSB4Im5vIgot
dGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhczg2LCBwbGVhc2UgaW5z
dGFsbCBhczg2IiAiJExJTkVOTyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MIiA9IHg7IHRo
ZW4KKyAgICBPQ0FNTD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFj
X3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9v
bHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9
eWVzIDs7Citlc2FjCisgICAgT0NBTUw9JGFjX2N0X09DQU1MCisgIGZpCitlbHNlCisgIE9DQU1M
PSIkYWNfY3ZfcHJvZ19PQ0FNTCIKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImxk
ODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGxk
ODY7IGFjX3dvcmQ9JDIKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBhY193b3Jk
PSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoKK2lm
IHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJExEODYgaW4KLSAgW1xcL10qIHwg
PzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfTEQ4Nj0iJExEODYiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZv
ciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgotICAgIGFjX2N2X3BhdGhfTEQ4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIK
KyAgICBhY19jdl9wcm9nX09DQU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgogICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY0MDMsNDQgKzQx
NTUsMzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFj
X2N2X3BhdGhfTEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKLSAgOzsKLWVzYWMKIGZpCi1M
RDg2PSRhY19jdl9wYXRoX0xEODYKLWlmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgotICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJExEODYiID4mNQotJGFz
X2VjaG8gIiRMRDg2IiA+JjY7IH0KK2ZpCitPQ0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAor
aWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MREVQIiA+JjUKKyRhc19lY2hvICIkT0NBTUxE
RVAiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVz
dCB4IiR7TEQ4Nn0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGxkODYsIHBsZWFzZSBpbnN0YWxsIGxkODYiICIkTElORU5PIiA1CiBmaQotIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgotc2V0IGR1bW15IGJjYzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxERVAiOyB0aGVuCisgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAorICAjIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRlcDsgYWNfd29yZD0kMgogeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0
ZXN0ICIke2FjX2N2X3BhdGhfQkNDK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJEJDQyBpbgotICBbXFwvXSogfCA/OltcXC9d
KikKLSAgYWNfY3ZfcGF0aF9CQ0M9IiRCQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfQkNDPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgogICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY0NDgsNDQgKzQxOTUs
NTMgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2
X3BhdGhfQkNDIiAmJiBhY19jdl9wYXRoX0JDQz0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotQkNDPSRh
Y19jdl9wYXRoX0JDQwotaWYgdGVzdCAtbiAiJEJDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCQ0MiID4mNQotJGFzX2VjaG8gIiRC
Q0MiID4mNjsgfQorZmkKK2FjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQ
CitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxERVAiID4mNQorJGFz
X2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4m
NjsgfQogZmkKIAotCi1pZiB0ZXN0IHgiJHtCQ0N9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2Zu
X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiY2MsIHBsZWFzZSBpbnN0YWxsIGJjYyIgIiRMSU5F
Tk8iIDUKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTERFUCIgPSB4OyB0aGVuCisgICAgT0NBTUxE
RVA9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIE9DQU1MREVQPSRhY19jdF9PQ0FNTERFUAorICBmaQorZWxzZQorICBPQ0FNTERFUD0i
JGFjX2N2X3Byb2dfT0NBTUxERVAiCiBmaQotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJp
YXNsIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBp
YXNsOyBhY193b3JkPSQyCisKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRl
c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsg
YWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfSUFTTCtzZXR9IiA9IHNldDsgdGhl
biA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6
CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJElBU0wgaW4KLSAg
W1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfSUFTTD0iJElBU0wiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9Q
IjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMK
ICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfSUFTTD0iJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxta3RvcCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02NDkzLDIzOCArNDI0OSw5MyBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9J
RlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5v
IgotICA7OwotZXNhYwogZmkKLUlBU0w9JGFjX2N2X3BhdGhfSUFTTAotaWYgdGVzdCAtbiAiJElB
U0wiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkSUFTTCIgPiY1Ci0kYXNfZWNobyAiJElBU0wiID4mNjsgfQorZmkKK09DQU1MTUtUT1A9
JGFjX2N2X3Byb2dfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxN
S1RPUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MTUtUT1AiID4mNjsgfQogZWxzZQogICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7SUFTTH0iID09IHgibm8iCi10aGVu
Ci0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGlhc2wsIHBsZWFzZSBpbnN0YWxs
IGlhc2wiICIkTElORU5PIiA1Ci1maQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAidXVpZC91dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF91dWlkX2giICIkYWNfaW5j
bHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiA9IHgi
InllczsgdGhlbiA6Ci0KLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZCIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7
YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMK
LUxJQlM9Ii1sdXVpZCAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0Mg
aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVz
ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFu
ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lm
ZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgdXVpZF9jbGVhciAoKTsK
LWludAotbWFpbiAoKQotewotcmV0dXJuIHV1aWRfY2xlYXIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7
Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf
Y3ZfbGliX3V1aWRfdXVpZF9jbGVhcj15ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX3V1aWRfdXVpZF9j
bGVhcj1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
XAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVj
a19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjUKLSRhc19lY2hvICIk
YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl91
dWlkX3V1aWRfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKLSAgbGlidXVpZD0ieSIKLWZpCi0KLQog
ZmkKLQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidXVpZC5oIiAi
YWNfY3ZfaGVhZGVyX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRh
Y19jdl9oZWFkZXJfdXVpZF9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYnV1aWQ9InkiCi1maQot
Ci0KLWlmIHRlc3QgIiRsaWJ1dWlkIiAhPSAieSI7IHRoZW4gOgotCi0gICAgYXNfZm5fZXJyb3Ig
JD8gImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBsaWJyYXJ5IiAiJExJTkVOTyIgNQotCi1maQot
Ci0KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJjdXJzZXMuaCIgImFj
X2N2X2hlYWRlcl9jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRh
Y19jdl9oZWFkZXJfY3Vyc2VzX2giID0geCIieWVzOyB0aGVuIDoKLQotICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vy
c2VzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcy4uLiAi
ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfY3Vyc2VzX2NsZWFyK3NldH0iID0gc2V0OyB0
aGVuIDoKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCisgIGFjX2N0
X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBk
dW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LVE9QK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxjdXJz
ZXMgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot
LyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHBy
b3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0
IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg
YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVz
cGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGNsZWFyICgpOwotaW50Ci1tYWluICgpCi17
Ci1yZXR1cm4gY2xlYXIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj15
ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj1ubwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3Vy
c2VzX2NsZWFyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPiY2OyB9
Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKLSAg
Y3Vyc2VzPSJ5IgotZWxzZQotICBjdXJzZXM9Im4iCi1maQotCi0KLWVsc2UKLSAgY3Vyc2VzPSJu
IgotZmkKLQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibmN1cnNl
cy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYg
dGVzdCAieCRhY19jdl9oZWFkZXJfbmN1cnNlc19oIiA9IHgiInllczsgdGhlbiA6Ci0KLSAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVh
ciBpbiAtbG5jdXJzZXMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1s
bmN1cnNlcy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfbmN1cnNlc19jbGVhcitz
ZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
TUtUT1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxuY3Vyc2Vz
ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0ib2NhbWxta3RvcCIK
KyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRv
bmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90
b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBt
YXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFy
Z3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3Bs
dXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBjbGVhciAoKTsKLWludAotbWFpbiAoKQotewot
cmV0dXJuIGNsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9j
X3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyPXll
cwotZWxzZQotICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj1ubwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbmN1
cnNlc19jbGVhciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjY7
IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoK
LSAgbmN1cnNlcz0ieSIKLWVsc2UKLSAgbmN1cnNlcz0ibiIKIGZpCi0KLQorYWNfY3RfT0NBTUxN
S1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxNS1RPUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9QIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxN
S1RPUCIgPiY2OyB9CiBlbHNlCi0gIG5jdXJzZXM9Im4iCi1maQotCi0KLWlmIHRlc3QgIiRjdXJz
ZXMiID0gIm4iICYmIHRlc3QgIiRuY3Vyc2VzIiA9ICJuIjsgdGhlbiA6Ci0KLSAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYSBzdWl0YWJsZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5F
Tk8iIDUKLQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCi0jIFByZWZlciBuY3Vyc2VzIG92
ZXIgY3Vyc2VzIGlmIGJvdGggYXJlIHByZXNlbnQKLWlmIHRlc3QgIiRuY3Vyc2VzIiA9ICJ5Ijsg
dGhlbiA6Ci0KLSAgICBDVVJTRVNfTElCUz0iLWxuY3Vyc2VzIgotCi0kYXNfZWNobyAiI2RlZmlu
ZSBJTkNMVURFX0NVUlNFU19IIDxuY3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKLQogCisgIGlmIHRl
c3QgIngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4OyB0aGVuCisgICAgT0NBTUxNS1RPUD0ibm8iCisg
IGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6
KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2lu
ZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGgg
aG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NB
TUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAorICBmaQogZWxzZQotCi0gICAgQ1VSU0VTX0xJQlM9
Ii1sY3Vyc2VzIgotCi0kYXNfZWNobyAiI2RlZmluZSBJTkNMVURFX0NVUlNFU19IIDxjdXJzZXMu
aD4iID4+Y29uZmRlZnMuaAotCi0KKyAgT0NBTUxNS1RPUD0iJGFjX2N2X3Byb2dfT0NBTUxNS1RP
UCIKIGZpCiAKIAotCi0KLQotCi0KLQotaWYgdGVzdCAieCRhY19jdl9lbnZfUEtHX0NPTkZJR19z
ZXQiICE9ICJ4c2V0IjsgdGhlbgotCWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25m
aWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9cGtnLWNvbmZpZzsgYWNfd29yZD0kMgorICAjIGNoZWNraW5nIGZvciBv
Y2FtbG1rbGliCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWIiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfUEtH
X0NPTkZJRytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Ci1lbHNlCi0gIGNhc2UgJFBLR19DT05GSUcgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFj
X2N2X3BhdGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS0xJQitzZXR9
IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlm
IHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiRP
Q0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
UEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9n
X09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKICAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC02NzMyLDEzICs0MzQzLDEyIEBAIGRv
bmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi0gIDs7Ci1lc2FjCiBmaQotUEtHX0NPTkZJ
Rz0kYWNfY3ZfcGF0aF9QS0dfQ09ORklHCi1pZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4K
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQS0df
Q09ORklHIiA+JjUKLSRhc19lY2hvICIkUEtHX0NPTkZJRyIgPiY2OyB9CitmaQorT0NBTUxNS0xJ
Qj0kYWNfY3ZfcHJvZ19PQ0FNTE1LTElCCitpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TE1LTElCIiA+JjUKKyRhc19lY2hvICIkT0NBTUxNS0xJQiIgPiY2OyB9CiBlbHNlCiAgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNf
ZWNobyAibm8iID4mNjsgfQpAQCAtNjc0NiwyOCArNDM1NiwyNiBAQCBmaQogCiAKIGZpCi1pZiB0
ZXN0IC16ICIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIjsgdGhlbgotICBhY19wdF9QS0dfQ09ORklH
PSRQS0dfQ09ORklHCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGtnLWNvbmZpZyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgcGtnLWNv
bmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRo
ZW4KKyAgYWNfY3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIm9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19j
dl9wYXRoX2FjX3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHth
Y19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCi0g
IFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19w
dF9QS0dfQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0
aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor
ICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LTElCPSIkYWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBm
b3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KLSAgICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSJvY2FtbG1rbGli
IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY3NzUs
MjAgKzQzODMsMTkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgOzsKLWVz
YWMKIGZpCi1hY19wdF9QS0dfQ09ORklHPSRhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUcKLWlm
IHRlc3QgLW4gIiRhY19wdF9QS0dfQ09ORklHIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3B0X1BLR19DT05GSUciID4mNQotJGFz
X2VjaG8gIiRhY19wdF9QS0dfQ09ORklHIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTE1LTElCPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElC
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+
JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngk
YWNfcHRfUEtHX0NPTkZJRyIgPSB4OyB0aGVuCi0gICAgUEtHX0NPTkZJRz0iIgorICBpZiB0ZXN0
ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgorICAgIE9DQU1MTUtMSUI9Im5vIgogICBl
bHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgogeWVzOikK
QEAgLTY3OTYsNjcxICs0NDAzLDc2MiBAQCB5ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBlc2FjCi0gICAgUEtHX0NPTkZJRz0kYWNfcHRfUEtH
X0NPTkZJRworICAgIE9DQU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKICAgZmkKIGVsc2UKLSAg
UEtHX0NPTkZJRz0iJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyIKLWZpCi0KLWZpCi1pZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyI7IHRoZW4KLQlfcGtnX21pbl92ZXJzaW9uPTAuOS4wCi0JeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0
IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uLi4uICIg
PiY2OyB9Ci0JaWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uICRfcGtn
X21pbl92ZXJzaW9uOyB0aGVuCi0JCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIgPiY2OyB9Ci0JZWxzZQotCQl7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQot
JGFzX2VjaG8gIm5vIiA+JjY7IH0KLQkJUEtHX0NPTkZJRz0iIgotCWZpCisgIE9DQU1MTUtMSUI9
IiRhY19jdl9wcm9nX09DQU1MTUtMSUIiCiBmaQogCi1wa2dfZmFpbGVkPW5vCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBnbGliIiA+JjUKLSRh
c19lY2hvX24gImNoZWNraW5nIGZvciBnbGliLi4uICIgPiY2OyB9CiAKLWlmIHRlc3QgLW4gIiRn
bGliX0NGTEFHUyI7IHRoZW4KLSAgICBwa2dfY3ZfZ2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIK
LSBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgotICAgIGlmIHRlc3QgLW4gIiRQS0df
Q09ORklHIiAmJiBcCi0gICAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IFwkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9
ID4mNQotICAoJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIikg
Mj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRo
ZW4KLSAgcGtnX2N2X2dsaWJfQ0ZMQUdTPWAkUEtHX0NPTkZJRyAtLWNmbGFncyAiZ2xpYi0yLjAi
IDI+L2Rldi9udWxsYAorICAjIGNoZWNraW5nIGZvciBvY2FtbGRvYworICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHth
Y190b29sX3ByZWZpeH1vY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGRvYzsgYWNfd29yZD0kMgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBwa2dfZmFpbGVkPXllcworICBpZiB0
ZXN0IC1uICIkT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERP
QyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MRE9D
PSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCiBmaQot
IGVsc2UKLSAgICBwa2dfZmFpbGVkPXVudHJpZWQKIGZpCi1pZiB0ZXN0IC1uICIkZ2xpYl9MSUJT
IjsgdGhlbgotICAgIHBrZ19jdl9nbGliX0xJQlM9IiRnbGliX0xJQlMiCi0gZWxpZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyI7IHRoZW4KLSAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAot
ICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05G
SUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGliLTIuMFwiIjsgfSA+JjUKLSAgKCRQS0df
Q09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIpIDI+JjUKLSAgYWNfc3Rh
dHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh
Y19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuCi0gIHBrZ19jdl9n
bGliX0xJQlM9YCRQS0dfQ09ORklHIC0tbGlicyAiZ2xpYi0yLjAiIDI+L2Rldi9udWxsYAorT0NB
TUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KIGVsc2UKLSAgcGtnX2ZhaWxl
ZD15ZXMKLWZpCi0gZWxzZQotICAgIHBrZ19mYWlsZWQ9dW50cmllZAorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KIGZpCiAKIAorZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MRE9DIjsg
dGhlbgorICBhY19jdF9PQ0FNTERPQz0kT0NBTUxET0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJvY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
CitzZXQgZHVtbXkgb2NhbWxkb2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9n
X2FjX2N0X09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICBh
Y19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSIkYWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0ib2NhbWxkb2Mi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCiAKLWlmIHRlc3QgJHBrZ19mYWlsZWQgPSB5ZXM7IHRoZW4K
LSAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorZmkKK2ZpCithY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQwor
aWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCiAKLWlmICRQS0dfQ09ORklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAwLjIw
OyB0aGVuCi0gICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZD15ZXMKKyAgaWYgdGVz
dCAieCRhY19jdF9PQ0FNTERPQyIgPSB4OyB0aGVuCisgICAgT0NBTUxET0M9Im5vIgorICBlbHNl
CisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIk
YXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3Qg
dHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MRE9D
PSRhY19jdF9PQ0FNTERPQworICBmaQogZWxzZQotICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19z
dXBwb3J0ZWQ9bm8KKyAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgogZmkKLSAgICAg
ICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCi0JICAg
ICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQt
ZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKLSAgICAgICAgZWxzZQotCSAgICAgICAgZ2xpYl9QS0df
RVJST1JTPWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCi0gICAg
ICAgIGZpCi0JIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVy
ZSBpdCBiZWxvbmdzCi0JZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIgPiY1Ci0KLQlhc19mbl9lcnJv
ciAkPyAiUGFja2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3ZXJlIG5vdCBtZXQ6Ci0KLSRn
bGliX1BLR19FUlJPUlMKLQotQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEgg
ZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91Ci1pbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24t
c3RhbmRhcmQgcHJlZml4LgotCi1BbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJv
bm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCi1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBu
ZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KLVNlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3Ig
bW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKLWVsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJp
ZWQ7IHRoZW4KLSAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCXsgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFz
X2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3Ig
JD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9s
ZC4gIE1ha2Ugc3VyZSBpdAotaXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBl
bnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAotcGF0aCB0byBwa2ctY29uZmlnLgogCi1B
bHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJf
Q0ZMQUdTCi1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZp
Zy4KLVNlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLgogCi1UbyBn
ZXQgcGtnLWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5mcmVlZGVza3RvcC5vcmcvPi4K
LVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAj
IGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CiBlbHNlCi0JZ2xpYl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUwot
CWdsaWJfTElCUz0kcGtnX2N2X2dsaWJfTElCUwotICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4m
NjsgfQotCi1maQotCi0jIENoZWNrIGxpYnJhcnkgcGF0aAotaWYgdGVzdCAiXCR7ZXhlY19wcmVm
aXh9L2xpYiIgPSAiJGxpYmRpciI7IHRoZW4gOgotICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0g
Ik5PTkUiICYmIHRlc3QgIiRwcmVmaXgiICE9ICJOT05FIjsgdGhlbiA6Ci0gIGV4ZWNfcHJlZml4
PSRwcmVmaXgKKyAgaWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIGFjX2N2X3Byb2df
T0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2Rp
ciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl
bnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisg
ICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiCisg
ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25l
CitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi0gICAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJO
T05FIjsgdGhlbiA6Ci0gIGV4ZWNfcHJlZml4PSRhY19kZWZhdWx0X3ByZWZpeAogZmkKLSAgICBp
ZiB0ZXN0IC1kICIke2V4ZWNfcHJlZml4fS9saWI2NCI7IHRoZW4gOgotCi0gICAgICAgIExJQl9Q
QVRIPSJsaWI2NCIKLQorT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19PQ0FNTEJVSUxECitpZiB0ZXN0
IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJVSUxEIiA+JjUKKyRhc19lY2hvICIkT0NBTUxCVUlM
RCIgPiY2OyB9CiBlbHNlCi0KLSAgICAgICAgTElCX1BBVEg9ImxpYiIKLQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KIGZpCiAKLWVsc2UKLQotICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBs
ZW5ndGggIiRleGVjX3ByZWZpeCIgKyAxYH0iCiAKIGZpCi0KLQotIyBDaGVja3MgZm9yIGxpYnJh
cmllcy4KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJiemxpYi5oIiAi
YWNfY3ZfaGVhZGVyX2J6bGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngk
YWNfY3ZfaGVhZGVyX2J6bGliX2giID0geCIieWVzOyB0aGVuIDoKLQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQloyX2J6RGVjb21wcmVzc0lu
aXQgaW4gLWxiejIiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEJaMl9iekRlY29tcHJl
c3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloy
X2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxCVUlMRD0kT0NBTUxCVUlMRAor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGJ6MiAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgot
ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg
R0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp
bGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNo
YXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBCWjJf
YnpEZWNvbXByZXNzSW5pdCAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfYnoyX0JaMl9iekRl
Y29tcHJlc3NJbml0PXllcworICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxCVUlMRCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSIkYWNfY3RfT0NBTUxCVUlMRCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCi0gIGFjX2N2X2xpYl9iejJfQloyX2J6
RGVjb21wcmVzc0luaXQ9bm8KK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0ib2NhbWxidWlsZCIKKyAg
ICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUK
K0lGUz0kYXNfc2F2ZV9JRlMKKwogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1M
SUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJ
bml0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIg
PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID0g
eCIieWVzOyB0aGVuIDoKLSAgemxpYj0iJHpsaWIgLURIQVZFX0JaTElCIC1sYnoyIgorYWNfY3Rf
T0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxECitpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxCVUlMRCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEJVSUxEIiA+JjUKKyRhc19lY2hvICIkYWNfY3Rf
T0NBTUxCVUlMRCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAot
CisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxCVUlMRCIgPSB4OyB0aGVuCisgICAgT0NBTUxCVUlM
RD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVk
IGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJO
SU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp
eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2Fj
CisgICAgT0NBTUxCVUlMRD0kYWNfY3RfT0NBTUxCVUlMRAorICBmaQorZWxzZQorICBPQ0FNTEJV
SUxEPSIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIgogZmkKIAogCi1hY19mbl9jX2NoZWNrX2hlYWRl
cl9tb25ncmVsICIkTElORU5PIiAibHptYS5oIiAiYWNfY3ZfaGVhZGVyX2x6bWFfaCIgIiRhY19p
bmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHptYV9oIiA9IHgiInll
czsgdGhlbiA6CisgICAgaWYgdGVzdCAieCRPQ0FNTEMiID0gInhubyI7IHRoZW4gOgogCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem1hX3N0
cmVhbV9kZWNvZGVyIGluIC1sbHptYSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgbHpt
YV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKLUxJQlM9Ii1sbHptYSAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCisgICAgICAgIGlmIHRlc3QgIngk
ZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKIAotLyogT3ZlcnJpZGUgYW55IEdD
QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNh
dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4g
YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0j
aWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBsem1hX3N0cmVhbV9k
ZWNvZGVyICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4gbHptYV9zdHJlYW1fZGVjb2RlciAo
KTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPXllcwot
ZWxzZQotICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5vCi1maQotcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKyAg
ICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJPY2FtbCB0b29scyBlbmFibGVkLCBidXQgdW5hYmxl
IHRvIGZpbmQgT2NhbWwiICIkTElORU5PIiA1CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNv
ZGVyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIg
PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXIiID0g
eCIieWVzOyB0aGVuIDoKLSAgemxpYj0iJHpsaWIgLURIQVZFX0xaTUEgLWxsem1hIgorICAgICAg
ICBvY2FtbHRvb2xzPSJuIgorCiBmaQogCitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJiYXNoIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSBiYXNoOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAk
QkFTSCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CQVNIPSIkQkFTSCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICop
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFj
X2N2X3BhdGhfQkFTSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JB
U0g9Im5vIgorICA7OworZXNhYworZmkKK0JBU0g9JGFjX2N2X3BhdGhfQkFTSAoraWYgdGVzdCAt
biAiJEJBU0giOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQkFTSCIgPiY1CiskYXNfZWNobyAiJEJBU0giID4mNjsgfQorZWxzZQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor
JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem9fbHpvMXhfaCIg
PSB4IiJ5ZXM7IHRoZW4gOgoraWYgdGVzdCB4IiR7QkFTSH0iID09IHgibm8iCit0aGVuCisgICAg
YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2gi
ICIkTElORU5PIiA1CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMiIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgbHpvMXhfZGVjb21wcmVzcyBpbiAtbGx6bzIuLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcytzZXR9IiA9IHNldDsg
dGhlbiA6CithY19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRD
QyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRD
QyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRl
c3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJf
Z251Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhv
dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhv
dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yLi4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0
aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAt
ZCAiJENQUCI7IHRoZW4KKyAgQ1BQPQorZmkKK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlm
IHRlc3QgIiR7YWNfY3ZfcHJvZ19DUFArc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1M
SUJTPSItbGx6bzIgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorICAgICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQIG5lZWRzIHRvIGJlIGV4
cGFuZGVkCisgICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRpb25hbC1jcHAi
ICIvbGliL2NwcCIKKyAgICBkbworICAgICAgYWNfcHJlcHJvY19vaz1mYWxzZQorZm9yIGFjX2Nf
cHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRlciBmaWxlIHRo
YXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0aCBhIGZyZXNo
IGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQu
aD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+IGV4aXN0cyBl
dmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1
bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMgbm90IGp1c3Qg
dGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgor
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29u
ZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRv
IGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl
IHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBw
cm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRl
cm4gIkMiCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBp
bmNsdWRlIDxhc3NlcnQuaD4KICNlbmRpZgotY2hhciBsem8xeF9kZWNvbXByZXNzICgpOwotaW50
Ci1tYWluICgpCi17Ci1yZXR1cm4gbHpvMXhfZGVjb21wcmVzcyAoKTsKLSAgOwotICByZXR1cm4g
MDsKLX0KKwkJICAgICBTeW50YXggZXJyb3IKIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPXllcwor
aWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisKIGVsc2UKLSAgYWNfY3ZfbGli
X2x6bzJfbHpvMXhfZGVjb21wcmVzcz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf
ZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNv
bXByZXNzIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIg
PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID0geCIi
eWVzOyB0aGVuIDoKLSAgemxpYj0iJHpsaWIgLURIQVZFX0xaTzFYIC1sbHpvMiIKKyAgIyBCcm9r
ZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgorY29udGludWUKIGZpCitybSAtZiBjb25mdGVzdC5l
cnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CiAKLQorICAjIE9LLCB3b3JrcyBvbiBzYW5l
IGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAjIGNhbiBi
ZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9uZXhpc3Rl
bnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisgICMg
QnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQorICAjIFBh
c3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhawogZmkKK3JtIC1mIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKIAorZG9uZQorIyBCZWNhdXNlIG9m
IGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQu
CitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNf
cHJlcHJvY19vazsgdGhlbiA6CisgIGJyZWFrCitmaQogCisgICAgZG9uZQorICAgIGFjX2N2X3By
b2dfQ1BQPSRDUFAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGlvX3NldHVwIGluIC1sYWlvLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9h
aW9faW9fc2V0dXArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAogZWxzZQotICBhY19jaGVja19saWJfc2F2
ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGFpbyAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENQUCIgPiY1CiskYXNf
ZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19wcmVwcm9j
X3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21l
cyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3Mt
Y29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBf
X1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24g
ZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUg
Y29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0aHJvdWdo
IGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIK
KyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUg
PGFzc2VydC5oPgogI2VuZGlmCi1jaGFyIGlvX3NldHVwICgpOwotaW50Ci1tYWluICgpCi17Ci1y
ZXR1cm4gaW9fc2V0dXAgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19CisJCSAgICAgU3ludGF4IGVy
cm9yCiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf
Y3ZfbGliX2Fpb19pb19zZXR1cD15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRo
ZW4gOgorCiBlbHNlCi0gIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9bm8KKyAgIyBCcm9rZW46IGZh
aWxzIG9uIHZhbGlkIGlucHV0LgorY29udGludWUKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3Qu
JGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworcm0gLWYgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNhbmUgY2Fz
ZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2FuIGJlIGRl
dGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlzdGVudC5o
PgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAgIyBCcm9r
ZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMgUGFzc2Vz
IGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFrCiBmaQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVw
IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9Ci1pZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKLSAgc3lzdGVtX2Fp
bz0ieSIKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKwor
ZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5n
IGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisKIGVsc2UKLSAgc3lzdGVtX2Fp
bz0ibiIKKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9y
OiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNf
cHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFp
bHMgc2FuaXR5IGNoZWNrCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJ
TkVOTyIgNSA7IH0KIGZpCiAKK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNf
Y29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1Jwor
YWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERG
TEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3Zf
Y19jb21waWxlcl9nbnUKKwogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIE1ENSBpbiAtbGNyeXB0by4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJf
Y3J5cHRvX01ENStzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVz
IGFuZCAtZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMg
bG9uZyBsaW5lcyBhbmQgLWUuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9HUkVQ
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxjcnlwdG8gICRMSUJTIgot
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZk
ZWZzLmguICAqLworICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9HUkVQX2Zv
dW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3Ig
ZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX3Byb2cgaW4gZ3JlcCBnZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfR1JFUD0iJGFz
X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfR1JF
UCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sg
Zm9yIEdOVSBhY19wYXRoX0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBD
aGVjayBmb3IgR05VICRhY19wYXRoX0dSRVAKK2Nhc2UgYCIkYWNfcGF0aF9HUkVQIiAtLXZlcnNp
b24gMj4mMWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiIGFj
X3BhdGhfR1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIz
NDU2Nzg5ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0
LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAi
ICJjb25mdGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAk
YXNfZWNobyAnR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9HUkVQIiAtZSAn
R1JFUCQnIC1lICctKGNhbm5vdCBtYXRjaCktJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5v
dXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRl
c3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3Vu
dCArIDEgJiYgYWNfY291bnQ9JGFzX3ZhbAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2Fj
X3BhdGhfR1JFUF9tYXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0
IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9HUkVQ
PSIkYWNfcGF0aF9HUkVQIgorICAgICAgYWNfcGF0aF9HUkVQX21heD0kYWNfY291bnQKKyAgICBm
aQorICAgICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gK
KyAgICB0ZXN0ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25m
dGVzdC5pbiBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKIAot
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Ci0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgot
Y2hhciBNRDUgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBNRDUgKCk7Ci0gIDsKLSAgcmV0
dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
LSAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCisgICAgICAkYWNfcGF0aF9HUkVQX2ZvdW5kICYm
IGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworICBp
ZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9HUkVQIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJu
byBhY2NlcHRhYmxlIGdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1Iv
dXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQogZWxzZQotICBhY19jdl9saWJfY3J5cHRv
X01ENT1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
XAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVj
a19saWJfc2F2ZV9MSUJTCisgIGFjX2N2X3BhdGhfR1JFUD0kR1JFUAogZmkKLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2NyeXB0b19N
RDUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY2OyB9Ci1pZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9MSUJDUllQVE8gMQotX0FDRU9GCi0KLSAgTElC
Uz0iLWxjcnlwdG8gJExJQlMiCiAKLWVsc2UKLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBm
aW5kIGxpYmNyeXB0byIgIiRMSU5FTk8iIDUKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKIAoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZXh0MmZz
X29wZW4yIGluIC1sZXh0MmZzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBleHQyZnNf
b3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2V4dDJm
c19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9F
R1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sZXh0MmZzICAkTElC
UyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyAgaWYgZWNobyBhIHwgJEdSRVAgLUUgJyhhfGIpJyA+L2Rldi9udWxs
IDI+JjEKKyAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCisgICBlbHNlCisgICAg
IGlmIHRlc3QgLXogIiRFR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9FR1JFUF9mb3VuZD1mYWxzZQor
ICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJP
R05BTUUtTElTVAorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19w
cm9nIGluIGVncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs
ZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfRUdSRVAiICYmICRhc190ZXN0
X3ggIiRhY19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3Bh
dGhfRUdSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBDaGVjayBmb3IgR05V
ICRhY19wYXRoX0VHUkVQCitjYXNlIGAiJGFjX3BhdGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBp
bgorKkdOVSopCisgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VH
UkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19uIDAxMjM0NTY3ODkg
PiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29uZnRlc3QuaW4iICJj
b25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0
ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgorICAgICRhc19lY2hv
ICdFR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcg
PCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAg
IGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJl
YWsKKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAg
ICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgorICAg
ICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0
ZXIgb25lCisgICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIKKyAgICAgIGFj
X3BhdGhfRUdSRVBfbWF4PSRhY19jb3VudAorICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMg
YXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAx
MCAmJiBicmVhaworICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25m
dGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNhYwogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBf
X2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGV4dDJmc19vcGVuMiAoKTsKLWlu
dAotbWFpbiAoKQotewotcmV0dXJuIGV4dDJmc19vcGVuMiAoKTsKLSAgOwotICByZXR1cm4gMDsK
LX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19j
dl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj15ZXMKKyAgICAgICRhY19wYXRoX0VHUkVQX2ZvdW5k
ICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwor
ICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JFUCI7IHRoZW4KKyAgICBhc19mbl9lcnJvciAk
PyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFS
QVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1CisgIGZpCiBlbHNlCi0gIGFjX2N2X2xpYl9l
eHQyZnNfZXh0MmZzX29wZW4yPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQK
LUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKyAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAK
IGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2V4
dDJmc19leHQyZnNfb3BlbjIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMiIgPSB4IiJ5ZXM7IHRoZW4gOgotICBsaWJleHQyZnM9InkiCi1lbHNlCi0gIGxp
YmV4dDJmcz0ibiIKKworICAgZmkKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9wYXRoX0VHUkVQIiA+JjY7IH0KKyBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCiAKIAoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9t
ZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
Z2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHth
Y19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQU5T
SSBDIGhlYWRlciBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgQU5TSSBDIGhl
YWRlciBmaWxlcy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYytzZXR9
IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sZ2NyeXB0ICAkTElCUyIKLWNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lu
Y2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHN0cmluZy5o
PgorI2luY2x1ZGUgPGZsb2F0Lmg+CiAKLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv
dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg
bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBh
cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNw
bHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsKIGlu
dAogbWFpbiAoKQogewotcmV0dXJuIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CisKICAgOwogICBy
ZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9eWVzCi1lbHNlCi0gIGFj
X2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwotZmkKLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2Ny
eXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID0geCIieWVzOyB0aGVuIDoKLSAgbGliZ2NyeXB0PSJ5Igor
aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJf
c3RkYz15ZXMKIGVsc2UKLSAgbGliZ2NyeXB0PSJuIgorICBhY19jdl9oZWFkZXJfc3RkYz1ubwog
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu
JGFjX2V4dAogCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIFN1
bk9TIDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFOU0ku
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdHJpbmcuaD4KIAorX0FDRU9GCitpZiAoZXZhbCAi
JGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAibWVtY2hyIiA+L2Rl
di9udWxsIDI+JjE7IHRoZW4gOgogCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgcHRocmVhZCBmbGFnIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBwdGhyZWFkIGZsYWcuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YXhfY3ZfcHRo
cmVhZF9mbGFncytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CiBlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitmaQorcm0gLWYgY29uZnRlc3QqCiAK
LSAgICAgICAgYXhfY3ZfcHRocmVhZF9mbGFncz0tcHRocmVhZAotCi0gICAgUFRIUkVBRF9DRkxB
R1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgotICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0
aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9MSUJTPSIiCi0KLQotICAgIHNhdmVkX0NGTEFHUz0i
JENGTEFHUyIKLQotICAgIHNhdmVkX0xERkxBR1M9IiRMREZMQUdTIgotCi0gICAgc2F2ZWRfTElC
Uz0iJExJQlMiCi0KLQotICAgIENGTEFHUz0iJENGTEFHUyAkUFRIUkVBRF9DRkxBR1MiCi0KLSAg
ICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgotCi0gICAgTElCUz0iJExJQlMg
JFBUSFJFQURfTElCUyIKK2ZpCiAKLSAgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAoraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4K
KyAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3QgZGVjbGFyZSBmcmVlLCBjb250cmFyeSB0
byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAv
KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLSNpbmNsdWRlIDxwdGhyZWFkLmg+Ci1pbnQgbWFpbih2
b2lkKSB7Ci0gIHB0aHJlYWRfYXRmb3JrKDAsMCwwKTsKLSAgcHRocmVhZF9jcmVhdGUoMCwwLDAs
MCk7Ci19CisjaW5jbHVkZSA8c3RkbGliLmg+CiAKIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGlu
ayAiJExJTkVOTyI7IHRoZW4gOgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIp
IDI+JjUgfAorICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CiAKIGVsc2UK
LSAgYXhfY3ZfcHRocmVhZF9mbGFncz1mYWlsZWQKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KIGZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotCi0gICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZM
QUdTIgotCi0gICAgTERGTEFHUz0iJHNhdmVkX0xERkxBR1MiCi0KLSAgICBMSUJTPSIkc2F2ZWRf
TElCUyIKLQorcm0gLWYgY29uZnRlc3QqCiAKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQotJGFzX2Vj
aG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7IH0KLSAgICBpZiB0ZXN0ICJ4JGF4X2N2X3B0
aHJlYWRfZmxhZ3MiID0geGZhaWxlZDsgdGhlbgotICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0
aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKLSAgICBmaQotCi0gICAgUFRIUkVBRF9D
RkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgotICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2
X3B0aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9MSUJTPSIiCi0KLQogCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbG9ja19nZXR0aW1lIGlu
IC1scnQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsb2NrX2dldHRpbWUgaW4gLWxy
dC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZStzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitpZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4vY2MgaW4gSXJpeC00LjAuNSBn
ZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2kuCisgIGlmIHRlc3Qg
IiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgogZWxzZQotICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHJ0ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgorI2luY2x1ZGUgPGN0eXBlLmg+Cisj
aW5jbHVkZSA8c3RkbGliLmg+CisjaWYgKCgnICcgJiAweDBGRikgPT0gMHgwMjApCisjIGRlZmlu
ZSBJU0xPV0VSKGMpICgnYScgPD0gKGMpICYmIChjKSA8PSAneicpCisjIGRlZmluZSBUT1VQUEVS
KGMpIChJU0xPV0VSKGMpID8gJ0EnICsgKChjKSAtICdhJykgOiAoYykpCisjZWxzZQorIyBkZWZp
bmUgSVNMT1dFUihjKSBcCisJCSAgICgoJ2EnIDw9IChjKSAmJiAoYykgPD0gJ2knKSBcCisJCSAg
ICAgfHwgKCdqJyA8PSAoYykgJiYgKGMpIDw9ICdyJykgXAorCQkgICAgIHx8ICgncycgPD0gKGMp
ICYmIChjKSA8PSAneicpKQorIyBkZWZpbmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICgoYykg
fCAweDQwKSA6IChjKSkKICNlbmRpZgotY2hhciBjbG9ja19nZXR0aW1lICgpOworCisjZGVmaW5l
IFhPUihlLCBmKSAoKChlKSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQogaW50CiBtYWluICgp
CiB7Ci1yZXR1cm4gY2xvY2tfZ2V0dGltZSAoKTsKLSAgOworICBpbnQgaTsKKyAgZm9yIChpID0g
MDsgaSA8IDI1NjsgaSsrKQorICAgIGlmIChYT1IgKGlzbG93ZXIgKGkpLCBJU0xPV0VSIChpKSkK
Kwl8fCB0b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkKKyAgICAgIHJldHVybiAyOwogICByZXR1
cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgot
ICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZT15ZXMKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJ
TkVOTyI7IHRoZW4gOgorCiBlbHNlCi0gIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lPW5vCisg
IGFjX2N2X2hlYWRlcl9zdGRjPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQK
LUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29u
ZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKIGZpCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9ydF9jbG9j
a19nZXR0aW1lIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID4m
NjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSIgPSB4IiJ5ZXM7IHRo
ZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCUlQgMQot
X0FDRU9GCi0KLSAgTElCUz0iLWxydCAkTElCUyIKIAogZmkKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUK
KyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfaGVh
ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2OyB9Ci1pZiB0ZXN0
ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRM
SUJTCi1MSUJTPSItbHlhamwgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFzX2VjaG8gIiNkZWZpbmUg
U1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBf
X2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIHlhamxfYWxsb2MgKCk7Ci1pbnQK
LW1haW4gKCkKLXsKLXJldHVybiB5YWpsX2FsbG9jICgpOwotICA7Ci0gIHJldHVybiAwOwotfQot
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xp
Yl95YWpsX3lhamxfYWxsb2M9eWVzCi1lbHNlCi0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9
bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAg
ICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGli
X3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2
X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfeWFqbF95
YWpsX2FsbG9jIiA9IHgiInllczsgdGhlbiA6CisKKyMgT24gSVJJWCA1LjMsIHN5cy90eXBlcyBh
bmQgaW50dHlwZXMuaCBhcmUgY29uZmxpY3RpbmcuCitmb3IgYWNfaGVhZGVyIGluIHN5cy90eXBl
cy5oIHN5cy9zdGF0Lmggc3RkbGliLmggc3RyaW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKKwkJ
ICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0ZC5oCitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFz
X2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hl
Y2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIg
IiRhY19pbmNsdWRlc19kZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRl
ciJcIiA9IHgieWVzIjsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZp
bmUgSEFWRV9MSUJZQUpMIDEKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwg
JGFzX3RyX2NwcGAgMQogX0FDRU9GCiAKLSAgTElCUz0iLWx5YWpsICRMSUJTIgorZmkKKworZG9u
ZQorCisKK2lmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhlbiA6CisKKyAgICBpZiBl
Y2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CisKKyAgICAgICAgUFlUSE9OUEFU
SD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCiAKK2VsaWYg
dGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgorICBQWVRIT049InB5dGhvbiIKIGVsc2UKLSAgYXNf
Zm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwiICIkTElORU5PIiA1CisgIGFzX2ZuX2Vy
cm9yICQ/ICJQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRlIHBhdGgiICIk
TElORU5PIiA1CiBmaQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHoiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGRlZmxhdGVDb3B5IGluIC1sei4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9s
aWJfel9kZWZsYXRlQ29weStzZXR9IiA9IHNldDsgdGhlbiA6CisgICAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zf
cGF0aF9QWVRIT05QQVRIK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWx6
ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/
OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf
UFlUSE9OUEFUSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKIAotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIK
LSNlbmRpZgotY2hhciBkZWZsYXRlQ29weSAoKTsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGRl
ZmxhdGVDb3B5ICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PXllcwor
ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBB
VEg9Im5vIgorICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFU
SAoraWYgdGVzdCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAi
JFBZVEhPTlBBVEgiID4mNjsgfQogZWxzZQotICBhY19jdl9saWJfel9kZWZsYXRlQ29weT1ubwor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworCisKK2lmIHRlc3QgeCIke1BZVEhPTlBB
VEh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCAk
UFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQorZmkKKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRob24g
dmVyc2lvbiA+PSAyLjMgIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24gdmVy
c2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgc3lzLmV4
aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgyLCAzKSIpKSdgCitpZiB0ZXN0ICIkPyIgIT0g
IjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLVYgMj4mMWAKKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiJHB5dGhvbl92ZXJzaW9uIGlz
IHRvbyBvbGQsIG1pbmltdW0gcmVxdWlyZWQgdmVyc2lvbiBpcyAyLjMiICIkTElORU5PIiA1Citl
bHNlCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KIGZpCi17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+
JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4mNjsgfQotaWYgdGVzdCAi
eCRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCWiAxCi1fQUNFT0YKIAotICBMSUJTPSIt
bHogJExJQlMiCithY19weXRob25fdmVyc2lvbj1gJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGls
cy5zeXNjb25maWc7IFwKKyAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdf
dmFyKCJWRVJTSU9OIiknYAorYWNfcHJldmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCitDUFBGTEFH
Uz0iJENGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAg
ICBwcmludCAiLUkiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiSU5DTFVE
RVBZIiknYCIKK0NQUEZMQUdTPSIkQ1BQRkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRp
bHMuc3lzY29uZmlnOyBcCisgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmln
X3ZhcigiQ0ZMQUdTIiknYCIKK2FjX3ByZXZpb3VzX2xkZmxhZ3M9JExERkxBR1MKK0xERkxBR1M9
IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAorICAg
IHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIkxJQlMiKSdgIgorTERG
TEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBc
CisgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiU1lTTElCUyIp
J2AiCitMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNj
b25maWc7IFwKKyAgICBwcmludCAiLUwiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9u
X2xpYihwbGF0X3NwZWNpZmljPTEsXAorICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidg
IgorTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29u
ZmlnOyBcCisgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElO
S0ZPUlNIQVJFRCIpJ2AiCitMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRp
c3R1dGlscy5zeXNjb25maWc7IFwKKyAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9j
b25maWdfdmFyKCJMREZMQUdTIiknYCIKKworYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi
JExJTkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVyX1B5dGhvbl9oIiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9QeXRob25faCIgPSB4IiJ5ZXM7IHRo
ZW4gOgogCiBlbHNlCi0gIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB6bGliIiAiJExJ
TkVOTyIgNQorICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgUHl0aG9uIGRldmVsb3Bt
ZW50IGhlYWRlcnMiICIkTElORU5PIiA1CiBmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udi4uLiAi
ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9
IHNldDsgdGhlbiA6CisKK2FzX2FjX0xpYj1gJGFzX2VjaG8gImFjX2N2X2xpYl9weXRob24kYWNf
cHl0aG9uX3ZlcnNpb24nJ19QeUFyZ19QYXJzZVR1cGxlIiB8ICRhc190cl9zaGAKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNl
VHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24u
Li4gIiA+JjY7IH0KK2lmIGV2YWwgInRlc3QgXCJcJHskYXNfYWNfTGliK3NldH1cIiIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQogICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGljb252ICAkTElCUyIKK0xJQlM9Ii1scHl0aG9u
JGFjX3B5dGhvbl92ZXJzaW9uICAkTElCUyIKIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIApAQCAtNzQ3MCwxODQ2ICs1
MTY4LDExNzQgQEAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAog
I2lmZGVmIF9fY3BsdXNwbHVzCiBleHRlcm4gIkMiCiAjZW5kaWYKLWNoYXIgbGliaWNvbnZfb3Bl
biAoKTsKK2NoYXIgUHlBcmdfUGFyc2VUdXBsZSAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJu
IGxpYmljb252X29wZW4gKCk7CityZXR1cm4gUHlBcmdfUGFyc2VUdXBsZSAoKTsKICAgOwogICBy
ZXR1cm4gMDsKIH0KIF9BQ0VPRgogaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj15ZXMKKyAgZXZhbCAiJGFzX2FjX0xp
Yj15ZXMiCiBlbHNlCi0gIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPW5vCisgIGV2YWwg
IiRhc19hY19MaWI9bm8iCiBmaQogcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBcCiAgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKIExJQlM9
JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjUK
LSRhc19lY2hvICIkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNjsgfQotaWYgdGVz
dCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgotICBs
aWJpY29udj0ieSIKLWVsc2UKLSAgbGliaWNvbnY9Im4iCi1maQotCitldmFsIGFjX3Jlcz1cJCRh
c19hY19MaWIKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQoraWYgZXZh
bCB0ZXN0IFwieFwkIiRhc19hY19MaWIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV9MSUJweXRob24kYWNfcHl0
aG9uX3ZlcnNpb24iIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCiAKKyAgTElCUz0iLWxweXRob24k
YWNfcHl0aG9uX3ZlcnNpb24gJExJQlMiCiAKLSMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCi0j
IFRoZSBVbHRyaXggNC4yIG1pcHMgYnVpbHRpbiBhbGxvY2EgZGVjbGFyZWQgYnkgYWxsb2NhLmgg
b25seSB3b3JrcwotIyBmb3IgY29uc3RhbnQgYXJndW1lbnRzLiAgVXNlbGVzcyEKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxs
b2NhLmgiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmguLi4g
IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfd29ya2luZ19hbGxvY2FfaCtzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LSNpbmNsdWRlIDxhbGxvY2EuaD4KLWludAotbWFpbiAoKQotewotY2hhciAqcCA9IChjaGFyICop
IGFsbG9jYSAoMiAqIHNpemVvZiAoaW50KSk7Ci0JCQkgIGlmIChwKSByZXR1cm4gMDsKLSAgOwot
ICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgotICBhY19jdl93b3JraW5nX2FsbG9jYV9oPXllcwogZWxzZQotICBhY19jdl93b3JraW5n
X2FsbG9jYV9oPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgYXNfZm5f
ZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgcHl0aG9uIGRldmVsb3BtZW50IGxp
YnJhcnkiICIkTElORU5PIiA1CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKLSRhc19lY2hvICIk
YWNfY3Zfd29ya2luZ19hbGxvY2FfaCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl93b3JraW5nX2Fs
bG9jYV9oID0geWVzOyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIg
Pj5jb25mZGVmcy5oCitDUFBGTEFHUz0kYWNfcHJldmlvdXNfY3BwZmxhZ3MKK0xETEZBR1M9JGFj
X3ByZXZpb3VzX2xkZmxhZ3MKKwogCiBmaQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhbGxvY2EiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGFsbG9jYS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX2FsbG9jYV93
b3JrcytzZXR9IiA9IHNldDsgdGhlbiA6CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInhn
ZXR0ZXh0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSB4Z2V0dGV4dDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfWEdFVFRFWFQr
c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u
ZmRlZnMuaC4gICovCi0jaWZkZWYgX19HTlVDX18KLSMgZGVmaW5lIGFsbG9jYSBfX2J1aWx0aW5f
YWxsb2NhCi0jZWxzZQotIyBpZmRlZiBfTVNDX1ZFUgotIyAgaW5jbHVkZSA8bWFsbG9jLmg+Ci0j
ICBkZWZpbmUgYWxsb2NhIF9hbGxvY2EKLSMgZWxzZQotIyAgaWZkZWYgSEFWRV9BTExPQ0FfSAot
IyAgIGluY2x1ZGUgPGFsbG9jYS5oPgotIyAgZWxzZQotIyAgIGlmZGVmIF9BSVgKLSAjcHJhZ21h
IGFsbG9jYQotIyAgIGVsc2UKLSMgICAgaWZuZGVmIGFsbG9jYSAvKiBwcmVkZWZpbmVkIGJ5IEhQ
IGNjICtPbGliY2FsbHMgKi8KLWNoYXIgKmFsbG9jYSAoKTsKLSMgICAgZW5kaWYKLSMgICBlbmRp
ZgotIyAgZW5kaWYKLSMgZW5kaWYKLSNlbmRpZgorICBjYXNlICRYR0VUVEVYVCBpbgorICBbXFwv
XSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9YR0VUVEVYVD0iJFhHRVRURVhUIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9YR0VUVEVYVD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKIAotaW50Ci1tYWluICgpCi17Ci1jaGFyICpwID0gKGNoYXIgKikgYWxsb2NhICgxKTsK
LQkJCQkgICAgaWYgKHApIHJldHVybiAwOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1p
ZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfYWxsb2Nh
X3dvcmtzPXllcwotZWxzZQotICBhY19jdl9mdW5jX2FsbG9jYV93b3Jrcz1ubworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIgJiYgYWNfY3ZfcGF0aF9YR0VUVEVYVD0ibm8iCisgIDs7
Citlc2FjCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBc
Ci0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK1hHRVRURVhUPSRhY19j
dl9wYXRoX1hHRVRURVhUCitpZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQor
JGFzX2VjaG8gIiRYR0VUVEVYVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX2FsbG9j
YV93b3JrcyIgPiY2OyB9CiAKLWlmIHRlc3QgJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzID0geWVz
OyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBIDEiID4+Y29uZmRlZnMuaAor
aWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/
ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElO
RU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBhczg2OyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9BUzg2K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkQVM4NiBpbgorICBbXFwvXSog
fCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9BUzg2PSIkQVM4NiIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQVM4Nj0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9BUzg2IiAmJiBhY19jdl9wYXRoX0FTODY9Im5vIgorICA7OworZXNh
YworZmkKK0FTODY9JGFjX2N2X3BhdGhfQVM4NgoraWYgdGVzdCAtbiAiJEFTODYiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQVM4NiIg
PiY1CiskYXNfZWNobyAiJEFTODYiID4mNjsgfQogZWxzZQotICAjIFRoZSBTVlIzIGxpYlBXIGFu
ZCBTVlI0IGxpYnVjYiBib3RoIGNvbnRhaW4gaW5jb21wYXRpYmxlIGZ1bmN0aW9ucwotIyB0aGF0
IGNhdXNlIHRyb3VibGUuICBTb21lIHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2Nh
IG9yCi0jIGNvbnRhaW4gYSBidWdneSB2ZXJzaW9uLiAgSWYgeW91IHN0aWxsIHdhbnQgdG8gdXNl
IHRoZWlyIGFsbG9jYSwKLSMgdXNlIGFyIHRvIGV4dHJhY3QgYWxsb2NhLm8gZnJvbSB0aGVtIGlu
c3RlYWQgb2YgY29tcGlsaW5nIGFsbG9jYS5jLgotCi1BTExPQ0E9XCR7TElCT0JKRElSfWFsbG9j
YS4kYWNfb2JqZXh0Ci0KLSRhc19lY2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMu
aAorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENy
YXkgaG9va3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBcYGFsbG9jYS5jJyBu
ZWVkcyBDcmF5IGhvb2tzLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X29zX2NyYXkrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCB4IiR7QVM4Nn0iID09IHgibm8iCit0aGVuCisgICAg
YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGFzODYsIHBsZWFzZSBpbnN0YWxsIGFzODYi
ICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJsZDg2Iiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBsZDg2OyBhY193
b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmIGRl
ZmluZWQgQ1JBWSAmJiAhIGRlZmluZWQgQ1JBWTIKLXdlYmVjcmF5Ci0jZWxzZQotd2Vub3RiZWNy
YXkKLSNlbmRpZgorICBjYXNlICRMRDg2IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19j
dl9wYXRoX0xEODY9IiRMRDg2IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRo
IGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9MRDg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCi1fQUNFT0YKLWlmIChldmFsICIkYWNfY3Bw
IGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKLSAgJEVHUkVQICJ3ZWJlY3JheSIgPi9kZXYvbnVs
bCAyPiYxOyB0aGVuIDoKLSAgYWNfY3Zfb3NfY3JheT15ZXMKLWVsc2UKLSAgYWNfY3Zfb3NfY3Jh
eT1ubworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9MRDg2IiAmJiBhY19jdl9wYXRoX0xEODY9Im5v
IgorICA7OworZXNhYwogZmkKLXJtIC1mIGNvbmZ0ZXN0KgotCitMRDg2PSRhY19jdl9wYXRoX0xE
ODYKK2lmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJExEODYiID4mNQorJGFzX2VjaG8gIiRMRDg2IiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9vc19jcmF5IiA+JjUKLSRhc19l
Y2hvICIkYWNfY3Zfb3NfY3JheSIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9vc19jcmF5ID0geWVz
OyB0aGVuCi0gIGZvciBhY19mdW5jIGluIF9nZXRiNjcgR0VUQjY3IGdldGI2NzsgZG8KLSAgICBh
c19hY192YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKLWFj
X2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKLWlmIGV2
YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLQotY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBDUkFZX1NUQUNLU0VHX0VORCAkYWNfZnVuYwotX0FD
RU9GCiAKLSAgICBicmVhawotZmkKIAotICBkb25lCitpZiB0ZXN0IHgiJHtMRDg2fSIgPT0geCJu
byIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNl
IGluc3RhbGwgbGQ4NiIgIiRMSU5FTk8iIDUKIGZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYSIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBzdGFjayBkaXJlY3Rpb24gZm9yIEMgYWxsb2NhLi4u
ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uK3NldH0iID0gc2V0
OyB0aGVuIDoKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmNjIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBiY2M7IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9wYXRoX0JDQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0g
eWVzOyB0aGVuIDoKLSAgYWNfY3ZfY19zdGFja19kaXJlY3Rpb249MAotZWxzZQotICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4g
ICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAotaW50Ci1maW5kX3N0YWNrX2RpcmVjdGlvbiAoKQot
ewotICBzdGF0aWMgY2hhciAqYWRkciA9IDA7Ci0gIGF1dG8gY2hhciBkdW1teTsKLSAgaWYgKGFk
ZHIgPT0gMCkKLSAgICB7Ci0gICAgICBhZGRyID0gJmR1bW15OwotICAgICAgcmV0dXJuIGZpbmRf
c3RhY2tfZGlyZWN0aW9uICgpOwotICAgIH0KLSAgZWxzZQotICAgIHJldHVybiAoJmR1bW15ID4g
YWRkcikgPyAxIDogLTE7Ci19CisgIGNhc2UgJEJDQyBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9CQ0M9IiRCQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0JDQz0iJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotaW50Ci1tYWluICgpCi17Ci0gIHJl
dHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKSA8IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0xCi1l
bHNlCi0gIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPS0xCi1maQotcm0gLWYgY29yZSAqLmNvcmUg
Y29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9CQ0MiICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKKyAgOzsKK2VzYWMK
IGZpCi0KK0JDQz0kYWNfY3ZfcGF0aF9CQ0MKK2lmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQkNDIiA+JjUK
KyRhc19lY2hvICIkQkNDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBm
aQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Nfc3RhY2tfZGlyZWN0
aW9uIiA+JjY7IH0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgU1RBQ0tfRElS
RUNUSU9OICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbgotX0FDRU9GCiAKIAoraWYgdGVzdCB4IiR7
QkNDfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQg
YmNjLCBwbGVhc2UgaW5zdGFsbCBiY2MiICIkTElORU5PIiA1CiBmaQorIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJpYXNsIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBpYXNsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9J
QVNMK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgY2FzZSAkSUFTTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9J
QVNMPSIkSUFTTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGgu
CisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3BhdGhfSUFTTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIK
KyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRv
bmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotZm9yIGFjX2hlYWRlciBpbiAgXAotICAgICAgICAgICAg
ICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFs
bG9jLmggXAotICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0
ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKLSAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lz
L2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCi0gICAgICAgICAg
ICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJt
aW9zLmggXAotICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAor
ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5vIgorICA7
OworZXNhYworZmkKK0lBU0w9JGFjX2N2X3BhdGhfSUFTTAoraWYgdGVzdCAtbiAiJElBU0wiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
SUFTTCIgPiY1CiskYXNfZWNobyAiJElBU0wiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCiAKLWRvIDoKLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVh
ZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhl
biA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZF
XyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQotX0FDRU9GCiAKK2lmIHRlc3QgeCIke0lBU0x9
IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNs
LCBwbGVhc2UgaW5zdGFsbCBpYXNsIiAiJExJTkVOTyIgNQogZmkKIAotZG9uZQotCithY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidXVpZC91dWlkLmgiICJhY19jdl9oZWFk
ZXJfdXVpZF91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3Zf
aGVhZGVyX3V1aWRfdXVpZF9oIiA9IHgiInllczsgdGhlbiA6CiAKLSMgQ2hlY2tzIGZvciB0eXBl
ZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0
aGF0IGNvbmZvcm1zIHRvIEM5OSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3RkYm9v
bC5oIHRoYXQgY29uZm9ybXMgdG8gQzk5Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2hl
YWRlcl9zdGRib29sX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIgaW4gLWx1dWlk
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZC4uLiAi
ID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfdXVpZF91dWlkX2NsZWFyK3NldH0iID0gc2V0
OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCitMSUJTPSItbHV1aWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwogCi0jaW5jbHVkZSA8
c3RkYm9vbC5oPgotI2lmbmRlZiBib29sCi0gImVycm9yOiBib29sIGlzIG5vdCBkZWZpbmVkIgot
I2VuZGlmCi0jaWZuZGVmIGZhbHNlCi0gImVycm9yOiBmYWxzZSBpcyBub3QgZGVmaW5lZCIKLSNl
bmRpZgotI2lmIGZhbHNlCi0gImVycm9yOiBmYWxzZSBpcyBub3QgMCIKLSNlbmRpZgotI2lmbmRl
ZiB0cnVlCi0gImVycm9yOiB0cnVlIGlzIG5vdCBkZWZpbmVkIgotI2VuZGlmCi0jaWYgdHJ1ZSAh
PSAxCi0gImVycm9yOiB0cnVlIGlzIG5vdCAxIgotI2VuZGlmCi0jaWZuZGVmIF9fYm9vbF90cnVl
X2ZhbHNlX2FyZV9kZWZpbmVkCi0gImVycm9yOiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5l
ZCBpcyBub3QgZGVmaW5lZCIKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl
IHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg
dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu
dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitl
eHRlcm4gIkMiCiAjZW5kaWYKLQotCXN0cnVjdCBzIHsgX0Jvb2wgczogMTsgX0Jvb2wgdDsgfSBz
OwotCi0JY2hhciBhW3RydWUgPT0gMSA/IDEgOiAtMV07Ci0JY2hhciBiW2ZhbHNlID09IDAgPyAx
IDogLTFdOwotCWNoYXIgY1tfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCA9PSAxID8gMSA6
IC0xXTsKLQljaGFyIGRbKGJvb2wpIDAuNSA9PSB0cnVlID8gMSA6IC0xXTsKLQlib29sIGUgPSAm
czsKLQljaGFyIGZbKF9Cb29sKSAwLjAgPT0gZmFsc2UgPyAxIDogLTFdOwotCWNoYXIgZ1t0cnVl
XTsKLQljaGFyIGhbc2l6ZW9mIChfQm9vbCldOwotCWNoYXIgaVtzaXplb2Ygcy50XTsKLQllbnVt
IHsgaiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAyNTYg
fTsKLQkvKiBUaGUgZm9sbG93aW5nIGZhaWxzIGZvcgotCSAgIEhQIGFDKysvQU5TSSBDIEIzOTEw
QiBBLjA1LjU1IFtEZWMgMDQgMjAwM10uICovCi0JX0Jvb2wgblttXTsKLQljaGFyIG9bc2l6ZW9m
IG4gPT0gbSAqIHNpemVvZiBuWzBdID8gMSA6IC0xXTsKLQljaGFyIHBbLTEgLSAoX0Jvb2wpIDAg
PCAwICYmIC0xIC0gKGJvb2wpIDAgPCAwID8gMSA6IC0xXTsKLSMJaWYgZGVmaW5lZCBfX3hsY19f
IHx8IGRlZmluZWQgX19HTlVDX18KLQkgLyogQ2F0Y2ggYSBidWcgaW4gSUJNIEFJWCB4bGMgY29t
cGlsZXIgdmVyc2lvbiA2LjAuMC4wCi0JICAgIHJlcG9ydGVkIGJ5IEphbWVzIExlbWxleSBvbiAy
MDA1LTEwLTA1OyBzZWUKLQkgICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2J1
Zy1jb3JldXRpbHMvMjAwNS0xMC9tc2cwMDA4Ni5odG1sCi0JICAgIFRoaXMgdGVzdCBpcyBub3Qg
cXVpdGUgcmlnaHQsIHNpbmNlIHhsYyBpcyBhbGxvd2VkIHRvCi0JICAgIHJlamVjdCB0aGlzIHBy
b2dyYW0sIGFzIHRoZSBpbml0aWFsaXplciBmb3IgeGxjYnVnIGlzCi0JICAgIG5vdCBvbmUgb2Yg
dGhlIGZvcm1zIHRoYXQgQyByZXF1aXJlcyBzdXBwb3J0IGZvci4KLQkgICAgSG93ZXZlciwgZG9p
bmcgdGhlIHRlc3QgcmlnaHQgd291bGQgcmVxdWlyZSBhIHJ1bnRpbWUKLQkgICAgdGVzdCwgYW5k
IHRoYXQgd291bGQgbWFrZSBjcm9zcy1jb21waWxhdGlvbiBoYXJkZXIuCi0JICAgIExldCB1cyBo
b3BlIHRoYXQgSUJNIGZpeGVzIHRoZSB4bGMgYnVnLCBhbmQgYWxzbyBhZGRzCi0JICAgIHN1cHBv
cnQgZm9yIHRoaXMga2luZCBvZiBjb25zdGFudCBleHByZXNzaW9uLiAgSW4gdGhlCi0JICAgIG1l
YW50aW1lLCB0aGlzIHRlc3Qgd2lsbCByZWplY3QgeGxjLCB3aGljaCBpcyBPSywgc2luY2UKLQkg
ICAgb3VyIHN0ZGJvb2wuaCBzdWJzdGl0dXRlIHNob3VsZCBzdWZmaWNlLiAgV2UgYWxzbyB0ZXN0
Ci0JICAgIHRoaXMgd2l0aCBHQ0MsIHdoZXJlIGl0IHNob3VsZCB3b3JrLCB0byBkZXRlY3QgbW9y
ZQotCSAgICBxdWlja2x5IHdoZXRoZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRlc3QgaW4gdGhl
Ci0JICAgIGZ1dHVyZS4gICovCi0JIGNoYXIgZGlnc1tdID0gIjAxMjM0NTY3ODkiOwotCSBpbnQg
eGxjYnVnID0gMSAvICgmKGRpZ3MgKyA1KVstMiArIChib29sKSAxXSA9PSAmZGlnc1s0XSA/IDEg
OiAtMSk7Ci0jCWVuZGlmCi0JLyogQ2F0Y2ggYSBidWcgaW4gYW4gSFAtVVggQyBjb21waWxlci4g
IFNlZQotCSAgIGh0dHA6Ly9nY2MuZ251Lm9yZy9tbC9nY2MtcGF0Y2hlcy8yMDAzLTEyL21zZzAy
MzAzLmh0bWwKLQkgICBodHRwOi8vbGlzdHMuZ251Lm9yZy9hcmNoaXZlL2h0bWwvYnVnLWNvcmV1
dGlscy8yMDA1LTExL21zZzAwMTYxLmh0bWwKLQkgKi8KLQlfQm9vbCBxID0gdHJ1ZTsKLQlfQm9v
bCAqcHEgPSAmcTsKLQorY2hhciB1dWlkX2NsZWFyICgpOwogaW50CiBtYWluICgpCiB7Ci0KLQkq
cHEgfD0gcTsKLQkqcHEgfD0gISBxOwotCS8qIFJlZmVyIHRvIGV2ZXJ5IGRlY2xhcmVkIHZhbHVl
LCB0byBhdm9pZCBjb21waWxlciBvcHRpbWl6YXRpb25zLiAgKi8KLQlyZXR1cm4gKCFhICsgIWIg
KyAhYyArICFkICsgIWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCi0JCSsg
IW0gKyAhbiArICFvICsgIXAgKyAhcSArICFwcSk7Ci0KK3JldHVybiB1dWlkX2NsZWFyICgpOwog
ICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2hlYWRlcl9zdGRib29sX2g9eWVzCi1lbHNlCi0gIGFjX2N2
X2hlYWRlcl9zdGRib29sX2g9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRib29sX2giID4mNQot
JGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjY7IH0KLWFjX2ZuX2NfY2hlY2tf
dHlwZSAiJExJTkVOTyIgIl9Cb29sIiAiYWNfY3ZfdHlwZV9fQm9vbCIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX19Cb29sIiA9IHgiInllczsgdGhlbiA6Ci0K
LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9fQk9PTCAxCi1fQUNFT0YK
LQotCi1maQotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oID0geWVzOyB0aGVuCi0K
LSRhc19lY2hvICIjZGVmaW5lIEhBVkVfU1REQk9PTF9IIDEiID4+Y29uZmRlZnMuaAotCi1maQot
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1
aWRfdCBpbiBzeXMvdHlwZXMuaCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgdWlkX3Qg
aW4gc3lzL3R5cGVzLmguLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfdHlwZV91aWRfdCtz
ZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0g
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KLQotX0FDRU9GCi1pZiAoZXZhbCAi
JGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAidWlkX3QiID4vZGV2
L251bGwgMj4mMTsgdGhlbiA6Ci0gIGFjX2N2X3R5cGVfdWlkX3Q9eWVzCi1lbHNlCi0gIGFjX2N2
X3R5cGVfdWlkX3Q9bm8KLWZpCi1ybSAtZiBjb25mdGVzdCoKLQotZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIgPiY1
Ci0kYXNfZWNobyAiJGFjX2N2X3R5cGVfdWlkX3QiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfdHlw
ZV91aWRfdCA9IG5vOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIHVpZF90IGludCIgPj5jb25m
ZGVmcy5oCi0KLQotJGFzX2VjaG8gIiNkZWZpbmUgZ2lkX3QgaW50IiA+PmNvbmZkZWZzLmgKLQot
ZmkKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgaW5saW5lIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7
IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19pbmxpbmUrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jdl9jX2lubGluZT1ubwotZm9yIGFj
X2t3IGluIGlubGluZSBfX2lubGluZV9fIF9faW5saW5lOyBkbwotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZu
ZGVmIF9fY3BsdXNwbHVzCi10eXBlZGVmIGludCBmb29fdDsKLXN0YXRpYyAkYWNfa3cgZm9vX3Qg
c3RhdGljX2ZvbyAoKSB7cmV0dXJuIDA7IH0KLSRhY19rdyBmb29fdCBmb28gKCkge3JldHVybiAw
OyB9Ci0jZW5kaWYKLQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X2NfaW5saW5lPSRhY19rdworaWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPXllcworZWxzZQorICBh
Y19jdl9saWJfdXVpZF91dWlkX2NsZWFyPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gIHRlc3QgIiRhY19jdl9jX2lu
bGluZSIgIT0gbm8gJiYgYnJlYWsKLWRvbmUKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KK2lmIHRl
c3QgIngkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJ1
dWlkPSJ5IgogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfY19pbmxpbmUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2
OyB9CiAKLWNhc2UgJGFjX2N2X2NfaW5saW5lIGluCi0gIGlubGluZSB8IHllcykgOzsKLSAgKikK
LSAgICBjYXNlICRhY19jdl9jX2lubGluZSBpbgotICAgICAgbm8pIGFjX3ZhbD07OwotICAgICAg
KikgYWNfdmFsPSRhY19jdl9jX2lubGluZTs7Ci0gICAgZXNhYwotICAgIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKLSNpZm5kZWYgX19jcGx1c3BsdXMKLSNkZWZpbmUgaW5saW5lICRhY192YWwK
LSNlbmRpZgotX0FDRU9GCi0gICAgOzsKLWVzYWMKIAotYWNfZm5fY19maW5kX2ludFhfdCAiJExJ
TkVOTyIgIjE2IiAiYWNfY3ZfY19pbnQxNl90IgotY2FzZSAkYWNfY3ZfY19pbnQxNl90IGluICMo
Ci0gIG5vfHllcykgOzsgIygKLSAgKikKK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgaW50MTZfdCAkYWNfY3ZfY19pbnQxNl90Ci1fQUNFT0YKLTs7Ci1lc2FjCiAKLWFj
X2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKLWNhc2Ug
JGFjX2N2X2NfaW50MzJfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCi0gICopCithY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRf
aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF9o
IiA9IHgiInllczsgdGhlbiA6CisgIGxpYnV1aWQ9InkiCitmaQogCi1jYXQgPj5jb25mZGVmcy5o
IDw8X0FDRU9GCi0jZGVmaW5lIGludDMyX3QgJGFjX2N2X2NfaW50MzJfdAotX0FDRU9GCi07Owot
ZXNhYwogCi1hY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0
X3QiCi1jYXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQor
aWYgdGVzdCAiJGxpYnV1aWQiICE9ICJ5IjsgdGhlbiA6CiAKLWNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKLSNkZWZpbmUgaW50NjRfdCAkYWNfY3ZfY19pbnQ2NF90Ci1fQUNFT0YKLTs7Ci1lc2Fj
CisgICAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBsaWJyYXJ5IiAi
JExJTkVOTyIgNQogCi1hY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIgImFjX2N2X2Nf
aW50OF90IgotY2FzZSAkYWNfY3ZfY19pbnQ4X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAq
KQorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBpbnQ4X3QgJGFjX2N2
X2NfaW50OF90Ci1fQUNFT0YKLTs7Ci1lc2FjCiAKLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVO
TyIgIm1vZGVfdCIgImFjX2N2X3R5cGVfbW9kZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1p
ZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfbW9kZV90IiA9IHgiInllczsgdGhlbiA6CithY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJfY3Vy
c2VzX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2N1
cnNlc19oIiA9IHgiInllczsgdGhlbiA6CiAKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxjdXJzZXMuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2N1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKK0xJQlM9Ii1sY3Vyc2VzICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgotI2RlZmluZSBtb2RlX3QgaW50CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBf
X2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGNsZWFyICgpOworaW50CittYWlu
ICgpCit7CityZXR1cm4gY2xlYXIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CiBfQUNFT0YKLQor
aWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfY3Vyc2Vz
X2NsZWFyPXllcworZWxzZQorICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPW5vCiBmaQotCi1hY19m
bl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2X3R5cGVfb2ZmX3QiICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZfdCIgPSB4IiJ5ZXM7
IHRoZW4gOgotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
KyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tf
bGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2xpYl9jdXJzZXNfY2xlYXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfY3Vyc2VzX2Ns
ZWFyIiA9IHgiInllczsgdGhlbiA6CisgIGN1cnNlcz0ieSIKIGVsc2UKLQotY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBvZmZfdCBsb25nIGludAotX0FDRU9GCi0KKyAgY3Vyc2Vz
PSJuIgogZmkKIAotYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAicGlkX3QiICJhY19jdl90
eXBlX3BpZF90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
cGlkX3QiID0geCIieWVzOyB0aGVuIDoKIAogZWxzZQorICBjdXJzZXM9Im4iCitmaQogCi1jYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHBpZF90IGludAotX0FDRU9GCiAKLWZpCith
Y19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3Zf
aGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl9oZWFkZXJfbmN1cnNlc19oIiA9IHgiInllczsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdv
cmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQu
Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19yZXN0cmljdCtzZXR9IiA9IHNldDsgdGhl
biA6CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBj
bGVhciBpbiAtbG5jdXJzZXMuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX25jdXJz
ZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgogZWxzZQotICBhY19jdl9jX3Jlc3RyaWN0PW5vCi0gICAjIFRoZSBvcmRlciBoZXJlIGNhdGVy
cyB0byB0aGUgZmFjdCB0aGF0IEMrKyBkb2VzIG5vdCByZXF1aXJlIHJlc3RyaWN0LgotICAgZm9y
IGFjX2t3IGluIF9fcmVzdHJpY3QgX19yZXN0cmljdF9fIF9SZXN0cmljdCByZXN0cmljdDsgZG8K
LSAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19j
aGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbG5jdXJzZXMgICRMSUJTIgorY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwotdHlwZWRlZiBpbnQgKiBpbnRfcHRyOwotCWludCBmb28gKGludF9wdHIgJGFjX2t3IGlw
KSB7Ci0JcmV0dXJuIGlwWzBdOwotICAgICAgIH0KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRl
cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGlu
dCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRo
ZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYg
X19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBjbGVhciAoKTsKIGludAogbWFp
biAoKQogewotaW50IHNbMV07Ci0JaW50ICogJGFjX2t3IHQgPSBzOwotCXRbMF0gPSAwOwotCXJl
dHVybiBmb28odCkKK3JldHVybiBjbGVhciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VP
RgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX3Jl
c3RyaWN0PSRhY19rdworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9saWJfbmN1cnNlc19jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xl
YXI9bm8KIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKLSAgICAgdGVzdCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJy
ZWFrCi0gICBkb25lCi0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19j
aGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3Jlc3RyaWN0IiA+JjUKLSRhc19lY2hvICIkYWNfY3Zf
Y19yZXN0cmljdCIgPiY2OyB9Ci0KLSBjYXNlICRhY19jdl9jX3Jlc3RyaWN0IGluCi0gICByZXN0
cmljdCkgOzsKLSAgIG5vKSAkYXNfZWNobyAiI2RlZmluZSByZXN0cmljdCAvKiovIiA+PmNvbmZk
ZWZzLmgKLSA7OwotICAgKikgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgcmVz
dHJpY3QgJGFjX2N2X2NfcmVzdHJpY3QKLV9BQ0VPRgotIDs7Ci0gZXNhYwotCi1hY19mbl9jX2No
ZWNrX3R5cGUgIiRMSU5FTk8iICJzaXplX3QiICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNs
dWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3NpemVfdCIgPSB4IiJ5ZXM7IHRo
ZW4gOgotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX25jdXJz
ZXNfY2xlYXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPSB4
IiJ5ZXM7IHRoZW4gOgorICBuY3Vyc2VzPSJ5IgogZWxzZQotCi1jYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCi0jZGVmaW5lIHNpemVfdCB1bnNpZ25lZCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9
Im4iCiBmaQogCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzc2l6ZV90IiAiYWNfY3Zf
dHlwZV9zc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5
cGVfc3NpemVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgogCiBlbHNlCi0KLWNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKLSNkZWZpbmUgc3NpemVfdCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9Im4iCiBm
aQogCi1hY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxr
c2l6ZSIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXpl
IiA9IHgiInllczsgdGhlbiA6CiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUg
SEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFIDEKLV9BQ0VPRgoraWYgdGVzdCAiJGN1cnNlcyIg
PSAibiIgJiYgdGVzdCAiJG5jdXJzZXMiID0gIm4iOyB0aGVuIDoKIAorICAgIGFzX2ZuX2Vycm9y
ICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRhYmxlIGN1cnNlcyBsaWJyYXJ5IiAiJExJTkVOTyIg
NQogCiBmaQorIyBQcmVmZXIgbmN1cnNlcyBvdmVyIGN1cnNlcyBpZiBib3RoIGFyZSBwcmVzZW50
CitpZiB0ZXN0ICIkbmN1cnNlcyIgPSAieSI7IHRoZW4gOgogCi1hY19mbl9jX2NoZWNrX21lbWJl
ciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVj
dF9zdGF0X3N0X2Jsb2NrcyIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tzIiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1Mg
MQotX0FDRU9GCisgICAgQ1VSU0VTX0xJQlM9Ii1sbmN1cnNlcyIKIAorJGFzX2VjaG8gIiNkZWZp
bmUgSU5DTFVERV9DVVJTRVNfSCA8bmN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCiAKLSRhc19lY2hv
ICIjZGVmaW5lIEhBVkVfU1RfQkxPQ0tTIDEiID4+Y29uZmRlZnMuaAogCiBlbHNlCi0gIGNhc2Ug
IiAkTElCT0JKUyAiIGluCi0gICoiIGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiApIDs7Ci0gICop
IExJQk9CSlM9IiRMSUJPQkpTIGZpbGVibG9ja3MuJGFjX29iamV4dCIKLSA7OwotZXNhYwotCi1m
aQotCiAKLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0YXQiICJzdF9y
ZGV2IiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiID0geCIi
eWVzOyB0aGVuIDoKKyAgICBDVVJTRVNfTElCUz0iLWxjdXJzZXMiCiAKLWNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9SREVWIDEKLV9BQ0VPRgor
JGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNfSCA8Y3Vyc2VzLmg+IiA+PmNvbmZkZWZz
LmgKIAogCiBmaQogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3Zf
Y191aW50MTZfdCIKLWNhc2UgJGFjX2N2X2NfdWludDE2X3QgaW4gIygKLSAgbm98eWVzKSA7OyAj
KAotICAqKQogCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgdWludDE2X3Qg
JGFjX2N2X2NfdWludDE2X3QKLV9BQ0VPRgotOzsKLSAgZXNhYwogCi1hY19mbl9jX2ZpbmRfdWlu
dFhfdCAiJExJTkVOTyIgIjMyIiAiYWNfY3ZfY191aW50MzJfdCIKLWNhc2UgJGFjX2N2X2NfdWlu
dDMyX3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQogCi0kYXNfZWNobyAiI2RlZmluZSBf
VUlOVDMyX1QgMSIgPj5jb25mZGVmcy5oCiAKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgot
I2RlZmluZSB1aW50MzJfdCAkYWNfY3ZfY191aW50MzJfdAotX0FDRU9GCi07OwotICBlc2FjCiAK
LWFjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX3VpbnQ2NF90Igot
Y2FzZSAkYWNfY3ZfY191aW50NjRfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCitpZiB0ZXN0ICJ4
JGFjX2N2X2Vudl9QS0dfQ09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCisJaWYgdGVzdCAtbiAi
JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7
YWNfdG9vbF9wcmVmaXh9cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QS0dfQ09ORklHK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUEtHX0NPTkZJ
RyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtH
X0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisg
IDs7CiAgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3BhdGhfUEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ2NF9UIDEi
ID4+Y29uZmRlZnMuaAotCisgIDs7Citlc2FjCitmaQorUEtHX0NPTkZJRz0kYWNfY3ZfcGF0aF9Q
S0dfQ09ORklHCitpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQS0dfQ09ORklHIiA+JjUKKyRh
c19lY2hvICIkUEtHX0NPTkZJRyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50NjRfdCAkYWNf
Y3ZfY191aW50NjRfdAotX0FDRU9GCi07OwotICBlc2FjCiAKLWFjX2ZuX2NfZmluZF91aW50WF90
ICIkTElORU5PIiAiOCIgImFjX2N2X2NfdWludDhfdCIKLWNhc2UgJGFjX2N2X2NfdWludDhfdCBp
biAjKAotICBub3x5ZXMpIDs7ICMoCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NP
TkZJRyI7IHRoZW4KKyAgYWNfcHRfUEtHX0NPTkZJRz0kUEtHX0NPTkZJRworICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgInBrZy1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRhY19wdF9QS0dfQ09ORklH
IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9
IiRhY19wdF9QS0dfQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRo
IGEgcGF0aC4KKyAgOzsKICAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCi0kYXNfZWNobyAiI2Rl
ZmluZSBfVUlOVDhfVCAxIiA+PmNvbmZkZWZzLmgKLQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCi0jZGVmaW5lIHVpbnQ4X3QgJGFjX2N2X2NfdWludDhfdAotX0FDRU9GCi07OwotICBlc2Fj
Ci0KLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVf
cHRyZGlmZl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
cHRyZGlmZl90IiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgSEFWRV9QVFJESUZGX1QgMQotX0FDRU9GCi0KLQorICA7OworZXNhYworZmkKK2Fj
X3B0X1BLR19DT05GSUc9JGFjX2N2X3BhdGhfYWNfcHRfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAi
JGFjX3B0X1BLR19DT05GSUciOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcHRfUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJGFj
X3B0X1BLR19DT05GSUciID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZp
CiAKLQotIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1Ci0k
YXNfZWNob19uICJjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9saWJfZXJyb3JfYXRfbGluZStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxlcnJv
ci5oPgotaW50Ci1tYWluICgpCi17Ci1lcnJvcl9hdF9saW5lICgwLCAwLCAiIiwgMCwgImFuIGVy
cm9yIG9jY3VycmVkIik7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVz
CisgIGlmIHRlc3QgIngkYWNfcHRfUEtHX0NPTkZJRyIgPSB4OyB0aGVuCisgICAgUEtHX0NPTkZJ
Rz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBp
bgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYwor
ICAgIFBLR19DT05GSUc9JGFjX3B0X1BLR19DT05GSUcKKyAgZmkKIGVsc2UKLSAgYWNfY3ZfbGli
X2Vycm9yX2F0X2xpbmU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorICBQ
S0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgogZmkKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUi
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9Ci1pZiB0ZXN0
ICRhY19jdl9saWJfZXJyb3JfYXRfbGluZSA9IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAi
IGluCi0gICoiIGVycm9yLiRhY19vYmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JK
UyBlcnJvci4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCiAKIGZpCi0KLWZvciBhY19oZWFkZXIgaW4g
dmZvcmsuaAotZG8gOgotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAi
dmZvcmsuaCIgImFjX2N2X2hlYWRlcl92Zm9ya19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1p
ZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl92Zm9ya19oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9WRk9SS19IIDEKLV9BQ0VPRgotCitp
ZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKwlfcGtnX21pbl92ZXJzaW9uPTAuOS4wCisJ
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29u
ZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJz
aW9uLi4uICIgPiY2OyB9CisJaWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJz
aW9uICRfcGtnX21pbl92ZXJzaW9uOyB0aGVuCisJCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisJ
ZWxzZQorCQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKwkJUEtHX0NPTkZJRz0iIgorCWZpCiBmaQog
Ci1kb25lCi0KLWZvciBhY19mdW5jIGluIGZvcmsgdmZvcmsKLWRvIDoKLSAgYXNfYWNfdmFyPWAk
YXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNr
X2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4
XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEK
LV9BQ0VPRgotCi1maQotZG9uZQorcGtnX2ZhaWxlZD1ubworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2xpYiIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgZ2xpYi4uLiAiID4mNjsgfQogCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9y
ayIgPSB4eWVzOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yayIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm
b3Igd29ya2luZyBmb3JrLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfZm9ya193
b3JrcytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1l
bHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3Zf
ZnVuY19mb3JrX3dvcmtzPWNyb3NzCitpZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0aGVuCisg
ICAgcGtnX2N2X2dsaWJfQ0ZMQUdTPSIkZ2xpYl9DRkxBR1MiCisgZWxpZiB0ZXN0IC1uICIkUEtH
X0NPTkZJRyI7IHRoZW4KKyAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIHsg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1l
eGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGliLTIuMFwiIjsgfSA+JjUKKyAgKCRQS0dfQ09ORklH
IC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/
CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0
dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuCisgIHBrZ19jdl9nbGliX0NG
TEFHUz1gJFBLR19DT05GSUcgLS1jZmxhZ3MgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAKIGVsc2UK
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotCi0J
ICAvKiBCeSBSdWVkaWdlciBLdWhsbWFubi4gKi8KLQkgIHJldHVybiBmb3JrICgpIDwgMDsKLQot
ICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8i
OyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPXllcworICBwa2dfZmFpbGVkPXllcwor
ZmkKKyBlbHNlCisgICAgcGtnX2ZhaWxlZD11bnRyaWVkCitmaQoraWYgdGVzdCAtbiAiJGdsaWJf
TElCUyI7IHRoZW4KKyAgICBwa2dfY3ZfZ2xpYl9MSUJTPSIkZ2xpYl9MSUJTIgorIGVsaWYgdGVz
dCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisgICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYm
IFwKKyAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0df
Q09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1CisgICgk
UEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1CisgIGFj
X3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8g
PSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgorICBwa2df
Y3ZfZ2xpYl9MSUJTPWAkUEtHX0NPTkZJRyAtLWxpYnMgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAK
IGVsc2UKLSAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCisgIHBrZ19mYWlsZWQ9eWVzCiBmaQot
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKIGZpCiAKLWZpCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNf
Zm9ya193b3JrcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9
CiAKKworaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHllczsgdGhlbgorICAgCXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8i
ID4mNjsgfQorCitpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4y
MDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCiBlbHNlCi0g
IGFjX2N2X2Z1bmNfZm9ya193b3Jrcz0kYWNfY3ZfZnVuY19mb3JrCisgICAgICAgIF9wa2dfc2hv
cnRfZXJyb3JzX3N1cHBvcnRlZD1ubwogZmkKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dv
cmtzIiA9IHhjcm9zczsgdGhlbgotICBjYXNlICRob3N0IGluCi0gICAgKi0qLWFtaWdhb3MqIHwg
Ki0qLW1zZG9zZGpncHAqKQotICAgICAgIyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZl
IG9ubHkgYSBkdW1teSBmb3JrKCkgc3R1YgotICAgICAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5v
Ci0gICAgICA7OwotICAgICopCi0gICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCi0gICAg
ICA7OwotICBlc2FjCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
V0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX2Zvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9m
IGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3Vs
dCAkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxh
dGlvbiIgPiYyO30KLWZpCi1hY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3Jr
Ci1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfdmZvcmsiID0geHllczsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHZmb3Jr
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHZmb3JrLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfdmZvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgot
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9Y3Jvc3MKLWVs
c2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k
IGNvbmZkZWZzLmguICAqLwotLyogVGhhbmtzIHRvIFBhdWwgRWdnZXJ0IGZvciB0aGlzIHRlc3Qu
ICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSNpbmNsdWRlIDxzeXMvd2FpdC5oPgotI2lmZGVm
IEhBVkVfVkZPUktfSAotIyBpbmNsdWRlIDx2Zm9yay5oPgotI2VuZGlmCi0vKiBPbiBzb21lIHNw
YXJjIHN5c3RlbXMsIGNoYW5nZXMgYnkgdGhlIGNoaWxkIHRvIGxvY2FsIGFuZCBpbmNvbWluZwot
ICAgYXJndW1lbnQgcmVnaXN0ZXJzIGFyZSBwcm9wYWdhdGVkIGJhY2sgdG8gdGhlIHBhcmVudC4g
IFRoZSBjb21waWxlcgotICAgaXMgdG9sZCBhYm91dCB0aGlzIHdpdGggI2luY2x1ZGUgPHZmb3Jr
Lmg+LCBidXQgc29tZSBjb21waWxlcnMKLSAgIChlLmcuIGdjYyAtTykgZG9uJ3QgZ3JvayA8dmZv
cmsuaD4uICBUZXN0IGZvciB0aGlzIGJ5IHVzaW5nIGEKLSAgIHN0YXRpYyB2YXJpYWJsZSB3aG9z
ZSBhZGRyZXNzIGlzIHB1dCBpbnRvIGEgcmVnaXN0ZXIgdGhhdCBpcwotICAgY2xvYmJlcmVkIGJ5
IHRoZSB2Zm9yay4gICovCi1zdGF0aWMgdm9pZAotI2lmZGVmIF9fY3BsdXNwbHVzCi1zcGFyY19h
ZGRyZXNzX3Rlc3QgKGludCBhcmcpCi0jIGVsc2UKLXNwYXJjX2FkZHJlc3NfdGVzdCAoYXJnKSBp
bnQgYXJnOwotI2VuZGlmCi17Ci0gIHN0YXRpYyBwaWRfdCBjaGlsZDsKLSAgaWYgKCFjaGlsZCkg
ewotICAgIGNoaWxkID0gdmZvcmsgKCk7Ci0gICAgaWYgKGNoaWxkIDwgMCkgewotICAgICAgcGVy
cm9yICgidmZvcmsiKTsKLSAgICAgIF9leGl0KDIpOwotICAgIH0KLSAgICBpZiAoIWNoaWxkKSB7
Ci0gICAgICBhcmcgPSBnZXRwaWQoKTsKLSAgICAgIHdyaXRlKC0xLCAiIiwgMCk7Ci0gICAgICBf
ZXhpdCAoYXJnKTsKLSAgICB9Ci0gIH0KLX0KKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9l
cnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQ
S0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAK
KyAgICAgICAgZWxzZQorCSAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXBy
aW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCisgICAgICAgIGZpCisJIyBQdXQgdGhlIG5hc3R5
IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdzCisJZWNobyAiJGds
aWJfUEtHX0VSUk9SUyIgPiY1CiAKLWludAotbWFpbiAoKQotewotICBwaWRfdCBwYXJlbnQgPSBn
ZXRwaWQgKCk7Ci0gIHBpZF90IGNoaWxkOwotCi0gIHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7Ci0K
LSAgY2hpbGQgPSB2Zm9yayAoKTsKLQotICBpZiAoY2hpbGQgPT0gMCkgewotICAgIC8qIEhlcmUg
aXMgYW5vdGhlciB0ZXN0IGZvciBzcGFyYyB2Zm9yayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMK
LSAgICAgICB0ZXN0IHVzZXMgbG90cyBvZiBsb2NhbCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1h
bnkgbG9jYWwKLSAgICAgICB2YXJpYWJsZXMgYXMgbWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBp
bmNsdWRpbmcgY29tcGlsZXIKLSAgICAgICB0ZW1wb3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91
Z2ggZm9yIGdjYyAxLjQwLjMgb24gYSBTb2xhcmlzCi0gICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3
ZSB1c2UgOCB0byBiZSBzYWZlLiAgQSBidWdneSBjb21waWxlciBzaG91bGQKLSAgICAgICByZXVz
ZSB0aGUgcmVnaXN0ZXIgb2YgcGFyZW50IGZvciBvbmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywK
LSAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRoYXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJl
IHVzZWQgYW55IG1vcmUKLSAgICAgICBpbiB0aGlzIHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhl
IGxvY2FsIHZhcmlhYmxlIHdpbGwgdGh1cwotICAgICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFy
ZW50IHByb2Nlc3MuICAqLwotICAgIHBpZF90Ci0gICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0
cGlkKCksIHAyID0gZ2V0cGlkKCksIHAzID0gZ2V0cGlkKCksCi0gICAgICBwNCA9IGdldHBpZCgp
LCBwNSA9IGdldHBpZCgpLCBwNiA9IGdldHBpZCgpLCBwNyA9IGdldHBpZCgpOwotICAgIC8qIENv
bnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1p
Z2h0Ci0gICAgICAgdXNlIHRoZSBzYW1lIGhhcmR3YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2Nh
bCB2YXJpYWJsZXMuICAqLwotICAgIGlmIChwICE9IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8
fCBwICE9IHA0Ci0JfHwgcCAhPSBwNSB8fCBwICE9IHA2IHx8IHAgIT0gcDcpCi0gICAgICBfZXhp
dCgxKTsKLQotICAgIC8qIE9uIHNvbWUgc3lzdGVtcyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRv
ZXNuJ3Qgc2VwYXJhdGUgcGFyZW50Ci0gICAgICAgZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3Jz
LiAgSWYgdGhlIGNoaWxkIGNsb3NlcyBhIGRlc2NyaXB0b3IKLSAgICAgICBiZWZvcmUgaXQgZXhl
Y3Mgb3IgZXhpdHMsIHRoaXMgbXVuZ2VzIHRoZSBwYXJlbnQncyBkZXNjcmlwdG9yCi0gICAgICAg
YXMgd2VsbC4gIFRlc3QgZm9yIHRoaXMgYnkgY2xvc2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAg
Ki8KLSAgICBfZXhpdChjbG9zZShmaWxlbm8oc3Rkb3V0KSkgIT0gMCk7Ci0gIH0gZWxzZSB7Ci0g
ICAgaW50IHN0YXR1czsKLSAgICBzdHJ1Y3Qgc3RhdCBzdDsKKwlhc19mbl9lcnJvciAkPyAiUGFj
a2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3ZXJlIG5vdCBtZXQ6CiAKLSAgICB3aGlsZSAo
d2FpdCgmc3RhdHVzKSAhPSBjaGlsZCkKLSAgICAgIDsKLSAgICByZXR1cm4gKAotCSAvKiBXYXMg
dGhlcmUgc29tZSBwcm9ibGVtIHdpdGggdmZvcmtpbmc/ICAqLwotCSBjaGlsZCA8IDAKKyRnbGli
X1BLR19FUlJPUlMKIAotCSAvKiBEaWQgdGhlIGNoaWxkIGZhaWw/ICAoVGhpcyBzaG91bGRuJ3Qg
aGFwcGVuLikgICovCi0JIHx8IHN0YXR1cworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09O
RklHX1BBVEggZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUg
aW4gYSBub24tc3RhbmRhcmQgcHJlZml4LgogCi0JIC8qIERpZCB0aGUgdmZvcmsvY29tcGlsZXIg
YnVnIG9jY3VyPyAgKi8KLQkgfHwgcGFyZW50ICE9IGdldHBpZCgpCitBbHRlcm5hdGl2ZWx5LCB5
b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xp
Yl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtn
LWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKK2VsaWYgdGVz
dCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KKyAgICAgCXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6
IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3Qg
YmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9y
IHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0
aCB0byBwa2ctY29uZmlnLgogCi0JIC8qIERpZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1
cj8gICovCi0JIHx8IGZzdGF0KGZpbGVubyhzdGRvdXQpLCAmc3QpICE9IDAKLQkgKTsKLSAgfQot
fQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zf
ZnVuY192Zm9ya193b3Jrcz15ZXMKK0FsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZp
cm9ubWVudCB2YXJpYWJsZXMgZ2xpYl9DRkxBR1MKK2FuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhl
IG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgorU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZv
ciBtb3JlIGRldGFpbHMuCisKK1RvIGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29u
ZmlnLmZyZWVkZXNrdG9wLm9yZy8+LgorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWls
cyIgIiRMSU5FTk8iIDUgOyB9CiBlbHNlCi0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KLWZp
Ci1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25m
dGVzdC4kYWNfZXh0Ci1maQorCWdsaWJfQ0ZMQUdTPSRwa2dfY3ZfZ2xpYl9DRkxBR1MKKwlnbGli
X0xJQlM9JHBrZ19jdl9nbGliX0xJQlMKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0K
IAogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfdmZvcmtf
d29ya3MiID4mNjsgfQogCi1maTsKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9
IHhjcm9zczsgdGhlbgotICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3Jr
Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVz
dWx0ICRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21w
aWxhdGlvbiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7
fQorIyBDaGVjayBsaWJyYXJ5IHBhdGgKK2lmIHRlc3QgIlwke2V4ZWNfcHJlZml4fS9saWIiID0g
IiRsaWJkaXIiOyB0aGVuIDoKKyAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIiAmJiB0
ZXN0ICIkcHJlZml4IiAhPSAiTk9ORSI7IHRoZW4gOgorICBleGVjX3ByZWZpeD0kcHJlZml4CiBm
aQorICAgIGlmIHRlc3QgIiRleGVjX3ByZWZpeCIgPSAiTk9ORSI7IHRoZW4gOgorICBleGVjX3By
ZWZpeD0kYWNfZGVmYXVsdF9wcmVmaXgKK2ZpCisgICAgaWYgdGVzdCAtZCAiJHtleGVjX3ByZWZp
eH0vbGliNjQiOyB0aGVuIDoKIAotaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA9
IHh5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX1ZGT1JLIDEiID4+
Y29uZmRlZnMuaAorICAgICAgICBMSUJfUEFUSD0ibGliNjQiCiAKIGVsc2UKIAotJGFzX2VjaG8g
IiNkZWZpbmUgdmZvcmsgZm9yayIgPj5jb25mZGVmcy5oCisgICAgICAgIExJQl9QQVRIPSJsaWIi
CiAKIGZpCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCiAK
LSRhc19lY2hvICIjZGVmaW5lIEhBVkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorZWxz
ZQogCi1maQorICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVjX3ByZWZp
eCIgKyAxYH0iCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMi
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5l
ZWRlZCBmb3IgbGFyZ2UgZmlsZXMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfc3lzX2xh
cmdlZmlsZV9zb3VyY2Urc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICB3aGlsZSA6OyBkbwotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lz
L3R5cGVzLmg+IC8qIGZvciBvZmZfdCAqLwotICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KLWludAot
bWFpbiAoKQotewotaW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwotICAg
ICByZXR1cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKLSAgOwot
ICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgotICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT1ubzsgYnJlYWsKLWZpCi1ybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jZGVmaW5lIF9MQVJHRUZJTEVf
U09VUkNFIDEKLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCi0gICAgICNp
bmNsdWRlIDxzdGRpby5oPgotaW50Ci1tYWluICgpCi17Ci1pbnQgKCpmcCkgKEZJTEUgKiwgb2Zm
X3QsIGludCkgPSBmc2Vla287Ci0gICAgIHJldHVybiBmc2Vla28gKHN0ZGluLCAwLCAwKSAmJiBm
cCAoc3RkaW4sIDAsIDApOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9j
X3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNl
PTE7IGJyZWFrCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgYWNfY3Zfc3lz
X2xhcmdlZmlsZV9zb3VyY2U9dW5rbm93bgotICBicmVhawotZG9uZQotZmkKLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc3lzX2xhcmdlZmls
ZV9zb3VyY2UiID4mNQotJGFzX2VjaG8gIiRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2
OyB9Ci1jYXNlICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSBpbiAjKAotICBubyB8IHVua25v
d24pIDs7Ci0gICopCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIF9MQVJHRUZJ
TEVfU09VUkNFICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZQotX0FDRU9GCi07OwotZXNhYwot
cm0gLXJmIGNvbmZ0ZXN0KgotCi0jIFdlIHVzZWQgdG8gdHJ5IGRlZmluaW5nIF9YT1BFTl9TT1VS
Q0U9NTAwIHRvbywgdG8gd29yayBhcm91bmQgYSBidWcKLSMgaW4gZ2xpYmMgMi4xLjMsIGJ1dCB0
aGF0IGJyZWFrcyB0b28gbWFueSBvdGhlciB0aGluZ3MuCi0jIElmIHlvdSB3YW50IGZzZWVrbyBh
bmQgZnRlbGxvIHdpdGggZ2xpYmMsIHVwZ3JhZGUgdG8gYSBmaXhlZCBnbGliYy4KLWlmIHRlc3Qg
JGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlICE9IHVua25vd247IHRoZW4KIAotJGFzX2VjaG8g
IiNkZWZpbmUgSEFWRV9GU0VFS08gMSIgPj5jb25mZGVmcy5oCiAKLWZpCisjIENoZWNrcyBmb3Ig
bGlicmFyaWVzLgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImJ6bGli
LmgiICJhY19jdl9oZWFkZXJfYnpsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl9oZWFkZXJfYnpsaWJfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29y
cmVjdGx5IGhhbmRsZXMgdHJhaWxpbmcgc2xhc2giID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg
d2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxp
bmsrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgQloyX2J6RGVjb21wcmVzc0luaXQgaW4gLWxiejIiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4u
ICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQr
c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot
ICBybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQotZWNobyA+Y29uZnRlc3QuZmlsZQot
aWYgdGVzdCAiJGFzX2xuX3MiID0gImxuIC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0
ZXN0LnN5bTsgdGhlbgotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6
Ci0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubwotZWxz
ZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sYnoyICAkTElCUyIKK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LSRhY19pbmNsdWRlc19kZWZhdWx0CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv
dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg
bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBh
cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNw
bHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7CiBp
bnQKIG1haW4gKCkKIHsKLXN0cnVjdCBzdGF0IHNidWY7Ci0gICAgIC8qIExpbnV4IHdpbGwgZGVy
ZWZlcmVuY2UgdGhlIHN5bWxpbmsgYW5kIGZhaWwsIGFzIHJlcXVpcmVkIGJ5IFBPU0lYLgotCVRo
YXQgaXMgYmV0dGVyIGluIHRoZSBzZW5zZSB0aGF0IGl0IG1lYW5zIHdlIHdpbGwgbm90Ci0JaGF2
ZSB0byBjb21waWxlIGFuZCB1c2UgdGhlIGxzdGF0IHdyYXBwZXIuICAqLwotICAgICByZXR1cm4g
bHN0YXQgKCJjb25mdGVzdC5zeW0vIiwgJnNidWYpID09IDA7CityZXR1cm4gQloyX2J6RGVjb21w
cmVzc0luaXQgKCk7CiAgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5
X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19z
bGFzaGVkX3N5bWxpbms9eWVzCi1lbHNlCi0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2Vz
X3NsYXNoZWRfc3ltbGluaz1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3Qu
KiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29i
amV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKLWZpCi0KK2lmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNz
SW5pdD15ZXMKIGVsc2UKLSAgIyBJZiB0aGUgYGxuIC1zJyBjb21tYW5kIGZhaWxlZCwgdGhlbiB3
ZSBwcm9iYWJseSBkb24ndCBldmVuCi0gICMgaGF2ZSBhbiBsc3RhdCBmdW5jdGlvbi4KLSAgYWNf
Y3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCisgIGFjX2N2X2xp
Yl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9bm8KIGZpCi1ybSAtZiBjb25mdGVzdC5zeW0gY29u
ZnRlc3QuZmlsZQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hl
Y2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0IiA9IHgiInllczsgdGhl
biA6CisgIHpsaWI9IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKIGZpCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0YXRfZGVy
ZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfbHN0
YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9Ci0KLXRlc3QgJGFjX2N2X2Z1
bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgogCi1jYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5L
IDEKLV9BQ0VPRgogCitmaQogCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVu
Y2VzX3NsYXNoZWRfc3ltbGluayIgPSB4bm87IHRoZW4KLSAgY2FzZSAiICRMSUJPQkpTICIgaW4K
LSAgKiIgbHN0YXQuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIGxz
dGF0LiRhY19vYmpleHQiCi0gOzsKLWVzYWMKIAotZmkKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21v
bmdyZWwgIiRMSU5FTk8iICJsem1hLmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1
ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem1hX2giID0geCIieWVzOyB0
aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldiIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldi4uLiAiID4mNjsgfQot
aWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRlditzZXR9IiA9IHNldDsg
dGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBsem1hX3N0cmVhbV9kZWNvZGVyIGluIC1sbHptYSIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhl
biA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k
TElCUworTElCUz0iLWxsem1hICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzeXMvdHlw
ZXMuaD4KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIK
KyNlbmRpZgorY2hhciBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwogaW50CiBtYWluICgpCiB7Ci1y
ZXR1cm4gbWFrZWRldigwLCAwKTsKK3JldHVybiBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwogICA7
CiAgIHJldHVybiAwOwogfQogX0FDRU9GCiBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2PXllcworICBhY19jdl9s
aWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPXllcwogZWxzZQotICBhY19jdl9oZWFkZXJfc3lz
X3R5cGVzX2hfbWFrZWRldj1ubworICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVy
PW5vCiBmaQogcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCiAg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLQotZmkKLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N5c190
eXBlc19oX21ha2VkZXYiID4mNQotJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hf
bWFrZWRldiIgPiY2OyB9Ci0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtl
ZGV2ID0gbm87IHRoZW4KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJz
eXMvbWtkZXYuaCIgImFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2giID0geCIieWVzOyB0aGVu
IDoKLQotJGFzX2VjaG8gIiNkZWZpbmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCi0K
K0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KLQotCi0gIGlmIHRlc3QgJGFjX2N2
X2hlYWRlcl9zeXNfbWtkZXZfaCA9IG5vOyB0aGVuCi0gICAgYWNfZm5fY19jaGVja19oZWFkZXJf
bW9uZ3JlbCAiJExJTkVOTyIgInN5cy9zeXNtYWNyb3MuaCIgImFjX2N2X2hlYWRlcl9zeXNfc3lz
bWFjcm9zX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVy
X3N5c19zeXNtYWNyb3NfaCIgPSB4IiJ5ZXM7IHRoZW4gOgotCi0kYXNfZWNobyAiI2RlZmluZSBN
QUpPUl9JTl9TWVNNQUNST1MgMSIgPj5jb25mZGVmcy5oCi0KK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1f
ZGVjb2RlciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29k
ZXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVy
IiA9IHgiInllczsgdGhlbiA6CisgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk1BIC1sbHptYSIKIGZp
CiAKIAotICBmaQogZmkKIAotZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAotZG8gOgotICBhY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFk
ZXJfc3RkbGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVh
ZGVyX3N0ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKLSNkZWZpbmUgSEFWRV9TVERMSUJfSCAxCi1fQUNFT0YKLQotZmkKIAotZG9uZQorYWNfZm5f
Y19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVh
ZGVyX2x6b19sem8xeF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2
X2hlYWRlcl9sem9fbHpvMXhfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxl
IG1hbGxvYyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJs
ZSBtYWxsb2MuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u
dWxsK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMi4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzK3NldH0iID0g
c2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX21hbGxvY18w
X25vbm51bGw9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGx6bzIgICRM
SUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5k
IGNvbmZkZWZzLmguICAqLwotI2lmIGRlZmluZWQgU1REQ19IRUFERVJTIHx8IGRlZmluZWQgSEFW
RV9TVERMSUJfSAotIyBpbmNsdWRlIDxzdGRsaWIuaD4KLSNlbHNlCi1jaGFyICptYWxsb2MgKCk7
Ci0jZW5kaWYKIAorLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv
aWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0
dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3Rv
dHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAi
QyIKKyNlbmRpZgorY2hhciBsem8xeF9kZWNvbXByZXNzICgpOwogaW50CiBtYWluICgpCiB7Ci1y
ZXR1cm4gISBtYWxsb2MgKDApOworcmV0dXJuIGx6bzF4X2RlY29tcHJlc3MgKCk7CiAgIDsKICAg
cmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9eWVzCitpZiBhY19mbl9jX3RyeV9saW5r
ICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9eWVz
CiBlbHNlCi0gIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1ubworICBhY19jdl9saWJfbHpv
Ml9sem8xeF9kZWNvbXByZXNzPW5vCiBmaQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVz
dC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNf
b2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJf
bHpvMXhfZGVjb21wcmVzcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9sem8yX2x6bzF4X2Rl
Y29tcHJlc3MiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXBy
ZXNzIiA9IHgiInllczsgdGhlbiA6CisgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIi
CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX21h
bGxvY18wX25vbm51bGwiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u
dWxsID0geWVzOyB0aGVuIDoKLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMSIgPj5j
b25mZGVmcy5oCi0KLWVsc2UKLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMCIgPj5j
b25mZGVmcy5oCi0KLSAgIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIG1hbGxvYy4kYWNfb2Jq
ZXh0ICIqICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgbWFsbG9jLiRhY19vYmpleHQiCi0g
OzsKLWVzYWMKLQogCi0kYXNfZWNobyAiI2RlZmluZSBtYWxsb2MgcnBsX21hbGxvYyIgPj5jb25m
ZGVmcy5oCiAKIGZpCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNs
dWRlZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3Rp
bWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9o
ZWFkZXJfdGltZStzZXR9IiA9IHNldDsgdGhlbiA6CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9saWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJT
PSItbGFpbyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5j
bHVkZSA8c3lzL3RpbWUuaD4KLSNpbmNsdWRlIDx0aW1lLmg+CiAKKy8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj
YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu
IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor
I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgaW9fc2V0dXAgKCk7
CiBpbnQKIG1haW4gKCkKIHsKLWlmICgoc3RydWN0IHRtICopIDApCi1yZXR1cm4gMDsKK3JldHVy
biBpb19zZXR1cCAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9oZWFkZXJfdGltZT15ZXMKK2lm
IGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2Fpb19pb19z
ZXR1cD15ZXMKIGVsc2UKLSAgYWNfY3ZfaGVhZGVyX3RpbWU9bm8KLWZpCi1ybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRl
cl90aW1lIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQotaWYgdGVz
dCAkYWNfY3ZfaGVhZGVyX3RpbWUgPSB5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgVElN
RV9XSVRIX1NZU19USU1FIDEiID4+Y29uZmRlZnMuaAotCisgIGFjX2N2X2xpYl9haW9faW9fc2V0
dXA9bm8KIGZpCi0KLQotCi0KLSAgZm9yIGFjX2hlYWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKLWRv
IDoKLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwg
JGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19o
ZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSIKLWlmIGV2YWwg
dGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLSAgY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAk
YXNfdHJfY3BwYCAxCi1fQUNFT0YKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJ
QlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KLWRvbmUKLQotCi0KLQotCi0KLQotCi0g
IGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKLWRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNo
byAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMg
IiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFz
X2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VP
RgotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2xpYl9haW9faW9fc2V0dXAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfYWlvX2lvX3Nl
dHVwIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPSB4IiJ5ZXM7
IHRoZW4gOgorICBzeXN0ZW1fYWlvPSJ5IgorZWxzZQorICBzeXN0ZW1fYWlvPSJuIgogZmkKLWRv
bmUKLQogCiAKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciB3b3JraW5nIG1rdGltZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
d29ya2luZyBta3RpbWUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY193b3JraW5n
X21rdGltZStzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIE1ENSBpbiAtbGNyeXB0by4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth
Y19jdl9saWJfY3J5cHRvX01ENStzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKLSAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubwotZWxzZQotICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlM9JExJQlMKK0xJQlM9Ii1sY3J5cHRvICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLS8qIFRlc3QgcHJv
Z3JhbSBmcm9tIFBhdWwgRWdnZXJ0IGFuZCBUb255IExlbmVpcy4gICovCi0jaWZkZWYgVElNRV9X
SVRIX1NZU19USU1FCi0jIGluY2x1ZGUgPHN5cy90aW1lLmg+Ci0jIGluY2x1ZGUgPHRpbWUuaD4K
LSNlbHNlCi0jIGlmZGVmIEhBVkVfU1lTX1RJTUVfSAotIyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4K
LSMgZWxzZQotIyAgaW5jbHVkZSA8dGltZS5oPgotIyBlbmRpZgotI2VuZGlmCi0KLSNpbmNsdWRl
IDxsaW1pdHMuaD4KLSNpbmNsdWRlIDxzdGRsaWIuaD4KIAotI2lmZGVmIEhBVkVfVU5JU1REX0gK
LSMgaW5jbHVkZSA8dW5pc3RkLmg+Ci0jZW5kaWYKLQotI2lmbmRlZiBIQVZFX0FMQVJNCi0jIGRl
ZmluZSBhbGFybShYKSAvKiBlbXB0eSAqLworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1
c3BsdXMKK2V4dGVybiAiQyIKICNlbmRpZgotCi0vKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24g
dG8gcnBsX3B1dGVudiBieSBvdGhlciBjb25maWcgdGVzdHMuICAqLwotI3VuZGVmIHB1dGVudgot
Ci1zdGF0aWMgdGltZV90IHRpbWVfdF9tYXg7Ci1zdGF0aWMgdGltZV90IHRpbWVfdF9taW47Ci0K
LS8qIFZhbHVlcyB3ZSdsbCB1c2UgdG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4g
ICovCi1zdGF0aWMgY29uc3QgY2hhciAqdHpfc3RyaW5nc1tdID0gewotICAoY29uc3QgY2hhciAq
KSAwLCAiVFo9R01UMCIsICJUWj1KU1QtOSIsCi0gICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6
MDA6MDAsTTIuMy4wLzAwOjAwOjAwIgotfTsKLSNkZWZpbmUgTl9TVFJJTkdTIChzaXplb2YgKHR6
X3N0cmluZ3MpIC8gc2l6ZW9mICh0el9zdHJpbmdzWzBdKSkKLQotLyogUmV0dXJuIDAgaWYgbWt0
aW1lIGZhaWxzIHRvIGNvbnZlcnQgYSBkYXRlIGluIHRoZSBzcHJpbmctZm9yd2FyZCBnYXAuCi0g
ICBCYXNlZCBvbiBhIHByb2JsZW0gcmVwb3J0IGZyb20gQW5kcmVhcyBKYWVnZXIuICAqLwotc3Rh
dGljIGludAotc3ByaW5nX2ZvcndhcmRfZ2FwICgpCi17Ci0gIC8qIGdsaWJjICh1cCB0byBhYm91
dCAxOTk4LTEwLTA3KSBmYWlsZWQgdGhpcyB0ZXN0LiAqLwotICBzdHJ1Y3QgdG0gdG07Ci0KLSAg
LyogVXNlIHRoZSBwb3J0YWJsZSBQT1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQu
MS4wLE0xMC41LjAiCi0gICAgIGluc3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBv
cmRlciB0byBkZXRlY3QgdGhlIGJ1ZyBldmVuCi0gICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBz
dXBwb3J0IHRoZSBPbHNvbiBleHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCi0gICAgIGZ1bGwg
em9uZWluZm8gdGFibGVzIGluc3RhbGxlZC4gICovCi0gIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNU
OFBEVCxNNC4xLjAsTTEwLjUuMCIpOwotCi0gIHRtLnRtX3llYXIgPSA5ODsKLSAgdG0udG1fbW9u
ID0gMzsKLSAgdG0udG1fbWRheSA9IDU7Ci0gIHRtLnRtX2hvdXIgPSAyOwotICB0bS50bV9taW4g
PSAwOwotICB0bS50bV9zZWMgPSAwOwotICB0bS50bV9pc2RzdCA9IC0xOwotICByZXR1cm4gbWt0
aW1lICgmdG0pICE9ICh0aW1lX3QpIC0xOwotfQotCi1zdGF0aWMgaW50Ci1ta3RpbWVfdGVzdDEg
KHRpbWVfdCBub3cpCi17Ci0gIHN0cnVjdCB0bSAqbHQ7Ci0gIHJldHVybiAhIChsdCA9IGxvY2Fs
dGltZSAoJm5vdykpIHx8IG1rdGltZSAobHQpID09IG5vdzsKLX0KLQotc3RhdGljIGludAotbWt0
aW1lX3Rlc3QgKHRpbWVfdCBub3cpCi17Ci0gIHJldHVybiAobWt0aW1lX3Rlc3QxIChub3cpCi0J
ICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3QpICh0aW1lX3RfbWF4IC0gbm93KSkKLQkgICYmIG1r
dGltZV90ZXN0MSAoKHRpbWVfdCkgKHRpbWVfdF9taW4gKyBub3cpKSk7Ci19Ci0KLXN0YXRpYyBp
bnQKLWlyaXhfNl80X2J1ZyAoKQotewotICAvKiBCYXNlZCBvbiBjb2RlIGZyb20gQXJpZWwgRmFp
Z29uLiAgKi8KLSAgc3RydWN0IHRtIHRtOwotICB0bS50bV95ZWFyID0gOTY7Ci0gIHRtLnRtX21v
biA9IDM7Ci0gIHRtLnRtX21kYXkgPSAwOwotICB0bS50bV9ob3VyID0gMDsKLSAgdG0udG1fbWlu
ID0gMDsKLSAgdG0udG1fc2VjID0gMDsKLSAgdG0udG1faXNkc3QgPSAtMTsKLSAgbWt0aW1lICgm
dG0pOwotICByZXR1cm4gdG0udG1fbW9uID09IDIgJiYgdG0udG1fbWRheSA9PSAzMTsKLX0KLQot
c3RhdGljIGludAotYmlndGltZV90ZXN0IChpbnQgaikKLXsKLSAgc3RydWN0IHRtIHRtOwotICB0
aW1lX3Qgbm93OwotICB0bS50bV95ZWFyID0gdG0udG1fbW9uID0gdG0udG1fbWRheSA9IHRtLnRt
X2hvdXIgPSB0bS50bV9taW4gPSB0bS50bV9zZWMgPSBqOwotICBub3cgPSBta3RpbWUgKCZ0bSk7
Ci0gIGlmIChub3cgIT0gKHRpbWVfdCkgLTEpCi0gICAgewotICAgICAgc3RydWN0IHRtICpsdCA9
IGxvY2FsdGltZSAoJm5vdyk7Ci0gICAgICBpZiAoISAobHQKLQkgICAgICYmIGx0LT50bV95ZWFy
ID09IHRtLnRtX3llYXIKLQkgICAgICYmIGx0LT50bV9tb24gPT0gdG0udG1fbW9uCi0JICAgICAm
JiBsdC0+dG1fbWRheSA9PSB0bS50bV9tZGF5Ci0JICAgICAmJiBsdC0+dG1faG91ciA9PSB0bS50
bV9ob3VyCi0JICAgICAmJiBsdC0+dG1fbWluID09IHRtLnRtX21pbgotCSAgICAgJiYgbHQtPnRt
X3NlYyA9PSB0bS50bV9zZWMKLQkgICAgICYmIGx0LT50bV95ZGF5ID09IHRtLnRtX3lkYXkKLQkg
ICAgICYmIGx0LT50bV93ZGF5ID09IHRtLnRtX3dkYXkKLQkgICAgICYmICgobHQtPnRtX2lzZHN0
IDwgMCA/IC0xIDogMCA8IGx0LT50bV9pc2RzdCkKLQkJICA9PSAodG0udG1faXNkc3QgPCAwID8g
LTEgOiAwIDwgdG0udG1faXNkc3QpKSkpCi0JcmV0dXJuIDA7Ci0gICAgfQotICByZXR1cm4gMTsK
LX0KLQotc3RhdGljIGludAoteWVhcl8yMDUwX3Rlc3QgKCkKLXsKLSAgLyogVGhlIGNvcnJlY3Qg
YW5zd2VyIGZvciAyMDUwLTAyLTAxIDAwOjAwOjAwIGluIFBhY2lmaWMgdGltZSwKLSAgICAgaWdu
b3JpbmcgbGVhcCBzZWNvbmRzLiAgKi8KLSAgdW5zaWduZWQgbG9uZyBpbnQgYW5zd2VyID0gMjUy
NzMxNTIwMFVMOwotCi0gIHN0cnVjdCB0bSB0bTsKLSAgdGltZV90IHQ7Ci0gIHRtLnRtX3llYXIg
PSAyMDUwIC0gMTkwMDsKLSAgdG0udG1fbW9uID0gMiAtIDE7Ci0gIHRtLnRtX21kYXkgPSAxOwot
ICB0bS50bV9ob3VyID0gdG0udG1fbWluID0gdG0udG1fc2VjID0gMDsKLSAgdG0udG1faXNkc3Qg
PSAtMTsKLQotICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9
UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIKLSAgICAgaW5zdGVhZCBvZiAiVFo9QW1lcmljYS9WYW5j
b3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVnIGV2ZW4KLSAgICAgb24gc3lzdGVtcyB0
aGF0IGRvbid0IHN1cHBvcnQgdGhlIE9sc29uIGV4dGVuc2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUK
LSAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFsbGVkLiAgKi8KLSAgcHV0ZW52ICgoY2hh
ciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7Ci0KLSAgdCA9IG1rdGltZSAoJnRtKTsK
LQotICAvKiBDaGVjayB0aGF0IHRoZSByZXN1bHQgaXMgZWl0aGVyIGEgZmFpbHVyZSwgb3IgY2xv
c2UgZW5vdWdoCi0gICAgIHRvIHRoZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdlIGNhbiBhc3N1bWUg
dGhlIGRpc2NyZXBhbmN5IGlzCi0gICAgIGR1ZSB0byBsZWFwIHNlY29uZHMuICAqLwotICByZXR1
cm4gKHQgPT0gKHRpbWVfdCkgLTEKLQkgIHx8ICgwIDwgdCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAm
JiB0IDw9IGFuc3dlciArIDEyMCkpOwotfQotCitjaGFyIE1ENSAoKTsKIGludAogbWFpbiAoKQog
ewotICB0aW1lX3QgdCwgZGVsdGE7Ci0gIGludCBpLCBqOwotCi0gIC8qIFRoaXMgdGVzdCBtYWtl
cyBzb21lIGJ1Z2d5IG1rdGltZSBpbXBsZW1lbnRhdGlvbnMgbG9vcC4KLSAgICAgR2l2ZSB1cCBh
ZnRlciA2MCBzZWNvbmRzOyBhIG1rdGltZSBzbG93ZXIgdGhhbiB0aGF0Ci0gICAgIGlzbid0IHdv
cnRoIHVzaW5nIGFueXdheS4gICovCi0gIGFsYXJtICg2MCk7Ci0KLSAgZm9yICg7OykKLSAgICB7
Ci0gICAgICB0ID0gKHRpbWVfdF9tYXggPDwgMSkgKyAxOwotICAgICAgaWYgKHQgPD0gdGltZV90
X21heCkKLQlicmVhazsKLSAgICAgIHRpbWVfdF9tYXggPSB0OwotICAgIH0KLSAgdGltZV90X21p
biA9IC0gKCh0aW1lX3QpIH4gKHRpbWVfdCkgMCA9PSAodGltZV90KSAtMSkgLSB0aW1lX3RfbWF4
OwotCi0gIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyogYSBzdWl0YWJsZSBwcmltZSBudW1i
ZXIgKi8KLSAgZm9yIChpID0gMDsgaSA8IE5fU1RSSU5HUzsgaSsrKQotICAgIHsKLSAgICAgIGlm
ICh0el9zdHJpbmdzW2ldKQotCXB1dGVudiAoKGNoYXIqKSB0el9zdHJpbmdzW2ldKTsKLQotICAg
ICAgZm9yICh0ID0gMDsgdCA8PSB0aW1lX3RfbWF4IC0gZGVsdGE7IHQgKz0gZGVsdGEpCi0JaWYg
KCEgbWt0aW1lX3Rlc3QgKHQpKQotCSAgcmV0dXJuIDE7Ci0gICAgICBpZiAoISAobWt0aW1lX3Rl
c3QgKCh0aW1lX3QpIDEpCi0JICAgICAmJiBta3RpbWVfdGVzdCAoKHRpbWVfdCkgKDYwICogNjAp
KQotCSAgICAgJiYgbWt0aW1lX3Rlc3QgKCh0aW1lX3QpICg2MCAqIDYwICogMjQpKSkpCi0JcmV0
dXJuIDE7Ci0KLSAgICAgIGZvciAoaiA9IDE7IDsgaiA8PD0gMSkKLQlpZiAoISBiaWd0aW1lX3Rl
c3QgKGopKQotCSAgcmV0dXJuIDE7Ci0JZWxzZSBpZiAoSU5UX01BWCAvIDIgPCBqKQotCSAgYnJl
YWs7Ci0gICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKElOVF9NQVgpKQotCXJldHVybiAxOwotICAg
IH0KLSAgcmV0dXJuICEgKGlyaXhfNl80X2J1ZyAoKSAmJiBzcHJpbmdfZm9yd2FyZF9nYXAgKCkg
JiYgeWVhcl8yMDUwX3Rlc3QgKCkpOworcmV0dXJuIE1ENSAoKTsKKyAgOworICByZXR1cm4gMDsK
IH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2
X2Z1bmNfd29ya2luZ19ta3RpbWU9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6CisgIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PXllcwogZWxzZQotICBhY19jdl9mdW5jX3dv
cmtpbmdfbWt0aW1lPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdt
b24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKLQorICBhY19jdl9saWJfY3J5cHRv
X01ENT1ubwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfZnVuY193b3JraW5nX21rdGltZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1
bmNfd29ya2luZ19ta3RpbWUiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVuY193b3JraW5nX21r
dGltZSA9IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIG1rdGltZS4kYWNf
b2JqZXh0ICIqICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgbWt0aW1lLiRhY19vYmpleHQi
Ci0gOzsKLWVzYWMKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KLQotCi0KLQotCi1mb3IgYWNfZnVuYyBpbiBnZXRwYWdl
c2l6ZQotZG8gOgotICBhY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6ZSIg
ImFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNp
emUiID0geCIieWVzOyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9saWJfY3J5cHRvX01ENSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1
IiA9IHgiInllczsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUg
SEFWRV9HRVRQQUdFU0laRSAxCisjZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKIF9BQ0VPRgogCisg
IExJQlM9Ii1sY3J5cHRvICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBu
b3QgZmluZCBsaWJjcnlwdG8iICIkTElORU5PIiA1CiBmaQotZG9uZQogCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQotaWYg
dGVzdCAiJHthY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkK3NldH0iID0gc2V0OyB0aGVuIDoK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGV4
dDJmc19vcGVuMiBpbiAtbGV4dDJmcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZXh0
MmZzX29wZW4yIGluIC1sZXh0MmZzLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9l
eHQyZnNfZXh0MmZzX29wZW4yK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRo
ZW4gOgotICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCi1lbHNlCi0gIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVf
TElCUz0kTElCUworTElCUz0iLWxleHQyZnMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1
ZGVzX2RlZmF1bHQKLS8qIG1hbGxvYyBtaWdodCBoYXZlIGJlZW4gcmVuYW1lZCBhcyBycGxfbWFs
bG9jLiAqLwotI3VuZGVmIG1hbGxvYwotCi0vKiBUaGFua3MgdG8gTWlrZSBIYWVydGVsIGFuZCBK
aW0gQXZlcmEgZm9yIHRoaXMgdGVzdC4KLSAgIEhlcmUgaXMgYSBtYXRyaXggb2YgbW1hcCBwb3Nz
aWJpbGl0aWVzOgotCW1tYXAgcHJpdmF0ZSBub3QgZml4ZWQKLQltbWFwIHByaXZhdGUgZml4ZWQg
YXQgc29tZXdoZXJlIGN1cnJlbnRseSB1bm1hcHBlZAotCW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBz
b21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKLQltbWFwIHNoYXJlZCBub3QgZml4ZWQKLQltbWFwIHNo
YXJlZCBmaXhlZCBhdCBzb21ld2hlcmUgY3VycmVudGx5IHVubWFwcGVkCi0JbW1hcCBzaGFyZWQg
Zml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCi0gICBGb3IgcHJpdmF0ZSBtYXBwaW5n
cywgd2Ugc2hvdWxkIHZlcmlmeSB0aGF0IGNoYW5nZXMgY2Fubm90IGJlIHJlYWQoKQotICAgYmFj
ayBmcm9tIHRoZSBmaWxlLCBub3IgbW1hcCdzIGJhY2sgZnJvbSB0aGUgZmlsZSBhdCBhIGRpZmZl
cmVudAotICAgYWRkcmVzcy4gIChUaGVyZSBoYXZlIGJlZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRl
IHdhcyBub3QgY29ycmVjdGx5Ci0gICBpbXBsZW1lbnRlZCBsaWtlIHRoZSBpbmZhbW91cyBpMzg2
IHN2cjQuMCwgYW5kIHN5c3RlbXMgd2hlcmUgdGhlCi0gICBWTSBwYWdlIGNhY2hlIHdhcyBub3Qg
Y29oZXJlbnQgd2l0aCB0aGUgZmlsZSBzeXN0ZW0gYnVmZmVyIGNhY2hlCi0gICBsaWtlIGVhcmx5
IHZlcnNpb25zIG9mIEZyZWVCU0QgYW5kIHBvc3NpYmx5IGNvbnRlbXBvcmFyeSBOZXRCU0QuKQot
ICAgRm9yIHNoYXJlZCBtYXBwaW5ncywgd2Ugc2hvdWxkIGNvbnZlcnNlbHkgdmVyaWZ5IHRoYXQg
Y2hhbmdlcyBnZXQKLSAgIHByb3BhZ2F0ZWQgYmFjayB0byBhbGwgdGhlIHBsYWNlcyB0aGV5J3Jl
IHN1cHBvc2VkIHRvIGJlLgotCi0gICBHcmVwIHdhbnRzIHByaXZhdGUgZml4ZWQgYWxyZWFkeSBt
YXBwZWQuCi0gICBUaGUgbWFpbiB0aGluZ3MgZ3JlcCBuZWVkcyB0byBrbm93IGFib3V0IG1tYXAg
YXJlOgotICAgKiBkb2VzIGl0IGV4aXN0IGFuZCBpcyBpdCBzYWZlIHRvIHdyaXRlIGludG8gdGhl
IG1tYXAnZCBhcmVhCi0gICAqIGhvdyB0byB1c2UgaXQgKEJTRCB2YXJpYW50cykgICovCi0KLSNp
bmNsdWRlIDxmY250bC5oPgotI2luY2x1ZGUgPHN5cy9tbWFuLmg+Ci0KLSNpZiAhZGVmaW5lZCBT
VERDX0hFQURFUlMgJiYgIWRlZmluZWQgSEFWRV9TVERMSUJfSAotY2hhciAqbWFsbG9jICgpOwot
I2VuZGlmCi0KLS8qIFRoaXMgbWVzcyB3YXMgY29waWVkIGZyb20gdGhlIEdOVSBnZXRwYWdlc2l6
ZS5oLiAgKi8KLSNpZm5kZWYgSEFWRV9HRVRQQUdFU0laRQotIyBpZmRlZiBfU0NfUEFHRVNJWkUK
LSMgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIHN5c2NvbmYoX1NDX1BBR0VTSVpFKQotIyBlbHNlIC8q
IG5vIF9TQ19QQUdFU0laRSAqLwotIyAgaWZkZWYgSEFWRV9TWVNfUEFSQU1fSAotIyAgIGluY2x1
ZGUgPHN5cy9wYXJhbS5oPgotIyAgIGlmZGVmIEVYRUNfUEFHRVNJWkUKLSMgICAgZGVmaW5lIGdl
dHBhZ2VzaXplKCkgRVhFQ19QQUdFU0laRQotIyAgIGVsc2UgLyogbm8gRVhFQ19QQUdFU0laRSAq
LwotIyAgICBpZmRlZiBOQlBHCi0jICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBOQlBHICogQ0xT
SVpFCi0jICAgICBpZm5kZWYgQ0xTSVpFCi0jICAgICAgZGVmaW5lIENMU0laRSAxCi0jICAgICBl
bmRpZiAvKiBubyBDTFNJWkUgKi8KLSMgICAgZWxzZSAvKiBubyBOQlBHICovCi0jICAgICBpZmRl
ZiBOQlBDCi0jICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgTkJQQwotIyAgICAgZWxzZSAvKiBu
byBOQlBDICovCi0jICAgICAgaWZkZWYgUEFHRVNJWkUKLSMgICAgICAgZGVmaW5lIGdldHBhZ2Vz
aXplKCkgUEFHRVNJWkUKLSMgICAgICBlbmRpZiAvKiBQQUdFU0laRSAqLwotIyAgICAgZW5kaWYg
Lyogbm8gTkJQQyAqLwotIyAgICBlbmRpZiAvKiBubyBOQlBHICovCi0jICAgZW5kaWYgLyogbm8g
RVhFQ19QQUdFU0laRSAqLwotIyAgZWxzZSAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCi0jICAg
ZGVmaW5lIGdldHBhZ2VzaXplKCkgODE5MgkvKiBwdW50IHRvdGFsbHkgKi8KLSMgIGVuZGlmIC8q
IG5vIEhBVkVfU1lTX1BBUkFNX0ggKi8KLSMgZW5kaWYgLyogbm8gX1NDX1BBR0VTSVpFICovCi0K
LSNlbmRpZiAvKiBubyBIQVZFX0dFVFBBR0VTSVpFICovCiAKKy8qIE92ZXJyaWRlIGFueSBHQ0Mg
aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVz
ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFu
ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lm
ZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0MmZzX29wZW4yICgp
OwogaW50CiBtYWluICgpCiB7Ci0gIGNoYXIgKmRhdGEsICpkYXRhMiwgKmRhdGEzOwotICBjb25z
dCBjaGFyICpjZGF0YTI7Ci0gIGludCBpLCBwYWdlc2l6ZTsKLSAgaW50IGZkLCBmZDI7Ci0KLSAg
cGFnZXNpemUgPSBnZXRwYWdlc2l6ZSAoKTsKLQotICAvKiBGaXJzdCwgbWFrZSBhIGZpbGUgd2l0
aCBzb21lIGtub3duIGdhcmJhZ2UgaW4gaXQuICovCi0gIGRhdGEgPSAoY2hhciAqKSBtYWxsb2Mg
KHBhZ2VzaXplKTsKLSAgaWYgKCFkYXRhKQotICAgIHJldHVybiAxOwotICBmb3IgKGkgPSAwOyBp
IDwgcGFnZXNpemU7ICsraSkKLSAgICAqKGRhdGEgKyBpKSA9IHJhbmQgKCk7Ci0gIHVtYXNrICgw
KTsKLSAgZmQgPSBjcmVhdCAoImNvbmZ0ZXN0Lm1tYXAiLCAwNjAwKTsKLSAgaWYgKGZkIDwgMCkK
LSAgICByZXR1cm4gMjsKLSAgaWYgKHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2Vz
aXplKQotICAgIHJldHVybiAzOwotICBjbG9zZSAoZmQpOwotCi0gIC8qIE5leHQsIGNoZWNrIHRo
YXQgdGhlIHRhaWwgb2YgYSBwYWdlIGlzIHplcm8tZmlsbGVkLiAgRmlsZSBtdXN0IGhhdmUKLSAg
ICAgbm9uLXplcm8gbGVuZ3RoLCBvdGhlcndpc2Ugd2UgcmlzayBTSUdCVVMgZm9yIGVudGlyZSBw
YWdlLiAgKi8KLSAgZmQyID0gb3BlbiAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQg
fCBPX1RSVU5DLCAwNjAwKTsKLSAgaWYgKGZkMiA8IDApCi0gICAgcmV0dXJuIDQ7Ci0gIGNkYXRh
MiA9ICIiOwotICBpZiAod3JpdGUgKGZkMiwgY2RhdGEyLCAxKSAhPSAxKQotICAgIHJldHVybiA1
OwotICBkYXRhMiA9IChjaGFyICopIG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9U
X1dSSVRFLCBNQVBfU0hBUkVELCBmZDIsIDBMKTsKLSAgaWYgKGRhdGEyID09IE1BUF9GQUlMRUQp
Ci0gICAgcmV0dXJuIDY7Ci0gIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQotICAgIGlm
ICgqKGRhdGEyICsgaSkpCi0gICAgICByZXR1cm4gNzsKLSAgY2xvc2UgKGZkMik7Ci0gIGlmICht
dW5tYXAgKGRhdGEyLCBwYWdlc2l6ZSkpCi0gICAgcmV0dXJuIDg7Ci0KLSAgLyogTmV4dCwgdHJ5
IHRvIG1tYXAgdGhlIGZpbGUgYXQgYSBmaXhlZCBhZGRyZXNzIHdoaWNoIGFscmVhZHkgaGFzCi0g
ICAgIHNvbWV0aGluZyBlbHNlIGFsbG9jYXRlZCBhdCBpdC4gIElmIHdlIGNhbiwgYWxzbyBtYWtl
IHN1cmUgdGhhdAotICAgICB3ZSBzZWUgdGhlIHNhbWUgZ2FyYmFnZS4gICovCi0gIGZkID0gb3Bl
biAoImNvbmZ0ZXN0Lm1tYXAiLCBPX1JEV1IpOwotICBpZiAoZmQgPCAwKQotICAgIHJldHVybiA5
OwotICBpZiAoZGF0YTIgIT0gbW1hcCAoZGF0YTIsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9U
X1dSSVRFLAotCQkgICAgIE1BUF9QUklWQVRFIHwgTUFQX0ZJWEVELCBmZCwgMEwpKQotICAgIHJl
dHVybiAxMDsKLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgaWYgKCooZGF0
YSArIGkpICE9ICooZGF0YTIgKyBpKSkKLSAgICAgIHJldHVybiAxMTsKLQotICAvKiBGaW5hbGx5
LCBtYWtlIHN1cmUgdGhhdCBjaGFuZ2VzIHRvIHRoZSBtYXBwZWQgYXJlYSBkbyBub3QKLSAgICAg
cGVyY29sYXRlIGJhY2sgdG8gdGhlIGZpbGUgYXMgc2VlbiBieSByZWFkKCkuICAoVGhpcyBpcyBh
IGJ1ZyBvbgotICAgICBzb21lIHZhcmlhbnRzIG9mIGkzODYgc3ZyNC4wLikgICovCi0gIGZvciAo
aSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQotICAgICooZGF0YTIgKyBpKSA9ICooZGF0YTIgKyBp
KSArIDE7Ci0gIGRhdGEzID0gKGNoYXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7Ci0gIGlmICghZGF0
YTMpCi0gICAgcmV0dXJuIDEyOwotICBpZiAocmVhZCAoZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0g
cGFnZXNpemUpCi0gICAgcmV0dXJuIDEzOwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsr
aSkKLSAgICBpZiAoKihkYXRhICsgaSkgIT0gKihkYXRhMyArIGkpKQotICAgICAgcmV0dXJuIDE0
OwotICBjbG9zZSAoZmQpOworcmV0dXJuIGV4dDJmc19vcGVuMiAoKTsKKyAgOwogICByZXR1cm4g
MDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFj
X2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcwogZWxzZQot
ICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUg
Y29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKLQor
ICBhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj1ubwogZmkKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21h
cHBlZCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNjsg
fQotaWYgdGVzdCAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCA9IHllczsgdGhlbgotCi0k
YXNfZWNobyAiI2RlZmluZSBIQVZFX01NQVAgMSIgPj5jb25mZGVmcy5oCi0KK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotcm0g
LWYgY29uZnRlc3QubW1hcCBjb25mdGVzdC50eHQKLQotZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIu
aAotZG8gOgotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGli
LmgiICJhY19jdl9oZWFkZXJfc3RkbGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRl
c3QgIngkYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVERMSUJfSCAxCi1fQUNFT0YKLQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJf
ZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0
MmZzX29wZW4yIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3Bl
bjIiID0geCIieWVzOyB0aGVuIDoKKyAgbGliZXh0MmZzPSJ5IgorZWxzZQorICBsaWJleHQyZnM9
Im4iCiBmaQogCi1kb25lCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgcmVhbGxvYyIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSByZWFsbG9jLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdCIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIk
Y3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25v
bm51bGw9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGdjcnlwdCAgJExJ
QlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQg
Y29uZmRlZnMuaC4gICovCi0jaWYgZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5lZCBIQVZF
X1NURExJQl9ICi0jIGluY2x1ZGUgPHN0ZGxpYi5oPgotI2Vsc2UKLWNoYXIgKnJlYWxsb2MgKCk7
Ci0jZW5kaWYKIAorLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv
aWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0
dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3Rv
dHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAi
QyIKKyNlbmRpZgorY2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwogaW50CiBtYWluICgpCiB7
Ci1yZXR1cm4gISByZWFsbG9jICgwLCAwKTsKK3JldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgp
OwogICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5F
Tk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21k
X2hhc2hfYnVmZmVyPXllcwogZWxzZQotICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5v
CisgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwogZmkKLXJtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l
eHQKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2
ZV9MSUJTCiBmaQotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9CitpZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPSB4IiJ5ZXM7IHRoZW4g
OgorICBsaWJnY3J5cHQ9InkiCitlbHNlCisgIGxpYmdjcnlwdD0ibiIKIGZpCi17ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxv
Y18wX25vbm51bGwiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxs
IiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwgPSB5ZXM7IHRo
ZW4gOgogCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1JFQUxMT0MgMSIgPj5jb25mZGVmcy5oCiAK
KworICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIHB0aHJlYWQgZmxhZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZCBm
bGFnLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2F4X2N2X3B0aHJlYWRfZmxhZ3Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICAkYXNfZWNo
byAiI2RlZmluZSBIQVZFX1JFQUxMT0MgMCIgPj5jb25mZGVmcy5oCiAKLSAgIGNhc2UgIiAkTElC
T0JKUyAiIGluCi0gICoiIHJlYWxsb2MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9
IiRMSUJPQkpTIHJlYWxsb2MuJGFjX29iamV4dCIKLSA7OwotZXNhYworICAgICAgICBheF9jdl9w
dGhyZWFkX2ZsYWdzPS1wdGhyZWFkCisKKyAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJl
YWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKKyAg
ICBQVEhSRUFEX0xJQlM9IiIKKworCisgICAgc2F2ZWRfQ0ZMQUdTPSIkQ0ZMQUdTIgorCisgICAg
c2F2ZWRfTERGTEFHUz0iJExERkxBR1MiCisKKyAgICBzYXZlZF9MSUJTPSIkTElCUyIKKworCisg
ICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQVEhSRUFEX0NGTEFHUyIKKworICAgIExERkxBR1M9IiRMREZM
QUdTICRQVEhSRUFEX0xERkxBR1MiCisKKyAgICBMSUJTPSIkTElCUyAkUFRIUkVBRF9MSUJTIgor
CisgICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKworI2luY2x1ZGUgPHB0aHJlYWQuaD4KK2ludCBtYWluKHZv
aWQpIHsKKyAgcHRocmVhZF9hdGZvcmsoMCwwLDApOworICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCww
KTsKK30KKworX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisK
K2Vsc2UKKyAgYXhfY3ZfcHRocmVhZF9mbGFncz1mYWlsZWQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29u
ZnRlc3QuJGFjX2V4dAorCisgICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgorCisgICAgTERGTEFH
Uz0iJHNhdmVkX0xERkxBR1MiCiAKKyAgICBMSUJTPSIkc2F2ZWRfTElCUyIKIAotJGFzX2VjaG8g
IiNkZWZpbmUgcmVhbGxvYyBycGxfcmVhbGxvYyIgPj5jb25mZGVmcy5oCiAKIGZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRf
ZmxhZ3MiID4mNQorJGFzX2VjaG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7IH0KKyAgICBp
ZiB0ZXN0ICJ4JGF4X2N2X3B0aHJlYWRfZmxhZ3MiID0geGZhaWxlZDsgdGhlbgorICAgICAgICBh
c19mbl9lcnJvciAkPyAiLXB0aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKKyAgICBm
aQorCisgICAgUFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgorICAgIFBUSFJF
QURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MSUJTPSIiCisK
IAogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciB3b3JraW5nIHN0cm5sZW4iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcg
c3Rybmxlbi4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX3N0cm5sZW5fd29ya2lu
ZytzZXR9IiA9IHNldDsgdGhlbiA6CitBWF9DSEVDS19QVFlGVU5DUworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlh
amwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4u
ICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3Rybmxlbl93
b3JraW5nPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx5YWpsICAkTElC
UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0CisKKy8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj
YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu
IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor
I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgeWFqbF9hbGxvYyAo
KTsKIGludAogbWFpbiAoKQogewotCi0jZGVmaW5lIFMgImZvb2JhciIKLSNkZWZpbmUgU19MRU4g
KHNpemVvZiBTIC0gMSkKLQotICAvKiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gaXMgYnVn
Z3k6IHRoYXQgb2YgQUlYIDQuMyB3b3VsZAotICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMu
ICAqLwotCi0gIGludCBpOwotICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCi0gICAg
ewotICAgICAgaW50IGV4cGVjdGVkID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsKLSAgICAgIGlm
IChzdHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKLQlyZXR1cm4gMTsKLSAgICB9Ci0gIHJldHVy
biAwOwotCityZXR1cm4geWFqbF9hbGxvYyAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VP
RgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3Ry
bmxlbl93b3JraW5nPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgor
ICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcwogZWxzZQotICBhY19jdl9mdW5jX3N0cm5s
ZW5fd29ya2luZz1ubworICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPW5vCiBmaQotcm0gLWYg
Y29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19l
eGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAg
Y29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlMKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQorJGFzX2VjaG8gIiRhY19jdl9s
aWJfeWFqbF95YWpsX2FsbG9jIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3lhamxfeWFq
bF9hbGxvYyIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIEhBVkVfTElCWUFKTCAxCitfQUNFT0YKIAotZmkKLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmci
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyIgPiY2OyB9Ci10ZXN0
ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyA9IG5vICYmIGNhc2UgIiAkTElCT0JKUyAiIGlu
Ci0gICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpT
IHN0cm5sZW4uJGFjX29iamV4dCIKLSA7OwotZXNhYworICBMSUJTPSItbHlhamwgJExJQlMiCiAK
K2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwiICIkTElORU5PIiA1
CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciB3b3JraW5nIHN0cnRvZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2lu
ZyBzdHJ0b2QuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19zdHJ0b2Qrc2V0fSIg
PSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBkZWZsYXRlQ29weSBpbiAtbHouLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6
Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElC
Uz0iLWx6ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSNpZm5k
ZWYgc3RydG9kCi1kb3VibGUgc3RydG9kICgpOworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5h
bCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBt
aWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4g
aXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19j
cGx1c3BsdXMKK2V4dGVybiAiQyIKICNlbmRpZgorY2hhciBkZWZsYXRlQ29weSAoKTsKIGludAot
bWFpbigpCittYWluICgpCiB7Ci0gIHsKLSAgICAvKiBTb21lIHZlcnNpb25zIG9mIExpbnV4IHN0
cnRvZCBtaXMtcGFyc2Ugc3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KLSAgICBjaGFyICpz
dHJpbmcgPSAiICs2OSI7Ci0gICAgY2hhciAqdGVybTsKLSAgICBkb3VibGUgdmFsdWU7Ci0gICAg
dmFsdWUgPSBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOwotICAgIGlmICh2YWx1ZSAhPSA2OSB8fCB0
ZXJtICE9IChzdHJpbmcgKyA0KSkKLSAgICAgIHJldHVybiAxOwotICB9Ci0KLSAgewotICAgIC8q
IFVuZGVyIFNvbGFyaXMgMi40LCBzdHJ0b2QgcmV0dXJucyB0aGUgd3JvbmcgdmFsdWUgZm9yIHRo
ZQotICAgICAgIHRlcm1pbmF0aW5nIGNoYXJhY3RlciB1bmRlciBzb21lIGNvbmRpdGlvbnMuICAq
LwotICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOwotICAgIGNoYXIgKnRlcm07Ci0gICAgc3RydG9k
IChzdHJpbmcsICZ0ZXJtKTsKLSAgICBpZiAodGVybSAhPSBzdHJpbmcgJiYgKih0ZXJtIC0gMSkg
PT0gMCkKLSAgICAgIHJldHVybiAxOwotICB9CityZXR1cm4gZGVmbGF0ZUNvcHkgKCk7CisgIDsK
ICAgcmV0dXJuIDA7CiB9Ci0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKIGVsc2UKLSAgYWNf
Y3ZfZnVuY19zdHJ0b2Q9bm8KLWZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0Liog
Z21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X2xpYl96X2RlZmxhdGVD
b3B5PW5vCiBmaQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hl
Y2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNQotJGFzX2VjaG8gIiRhY19jdl9m
dW5jX3N0cnRvZCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRvZCA9IG5vOyB0aGVu
Ci0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIHN0cnRvZC4kYWNfb2JqZXh0ICIqICkgOzsK
LSAgKikgTElCT0JKUz0iJExJQk9CSlMgc3RydG9kLiRhY19vYmpleHQiCi0gOzsKLWVzYWMKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfel9kZWZsYXRlQ29weSIg
PiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA9IHgiInllczsgdGhl
biA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJaIDEKK19B
Q0VPRgogCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJwb3ciICJhY19jdl9mdW5jX3Bv
dyIKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19wb3ciID0geCIieWVzOyB0aGVuIDoKKyAgTElCUz0i
LWx6ICRMSUJTIgogCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB6bGli
IiAiJExJTkVOTyIgNQogZmkKIAotaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBubzsgdGhlbgot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBw
b3cgaW4gLWxtIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBwb3cgaW4gLWxtLi4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9tX3BvdytzZXR9IiA9IHNldDsgdGhlbiA6Cit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsaWJp
Y29udl9vcGVuIGluIC1saWNvbnYiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGxpYmlj
b252X29wZW4gaW4gLWxpY29udi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfaWNv
bnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CiBlbHNlCiAgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1s
bSAgJExJQlMiCitMSUJTPSItbGljb252ICAkTElCUyIKIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIApAQCAtOTMxOSw1
NSArNjM0NSw0NSBAQCBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CiAjaWZkZWYgX19jcGx1c3BsdXMKIGV4dGVybiAiQyIKICNlbmRpZgotY2hhciBwb3cgKCk7Citj
aGFyIGxpYmljb252X29wZW4gKCk7CiBpbnQKIG1haW4gKCkKIHsKLXJldHVybiBwb3cgKCk7City
ZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgogaWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbV9wb3c9eWVz
CisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwogZWxzZQotICBhY19jdl9saWJf
bV9wb3c9bm8KKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KIGZpCiBybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKICAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAogTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX21fcG93IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX21fcG93IiA+JjY7IH0KLWlmIHRl
c3QgIngkYWNfY3ZfbGliX21fcG93IiA9IHgiInllczsgdGhlbiA6Ci0gIFBPV19MSUI9LWxtCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xp
Yl9pY29udl9saWJpY29udl9vcGVuIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2ljb252X2xp
Ymljb252X29wZW4iID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZf
b3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJpY29udj0ieSIKIGVsc2UKLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJy
YXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mNQotJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRlZmluaXRpb24gb2YgcG93
IiA+JjI7fQotZmkKLQorICBsaWJpY29udj0ibiIKIGZpCiAKLWZpCiAKLWZvciBhY19mdW5jIGlu
ICBcCi0gICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVw
MiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKLSAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5
bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAotICAgICAgICAgICAg
ICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3ZlIG1lbXNldCBt
a2RpciBcCi0gICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0aCBy
ZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAotICAgICAgICAgICAgICAgIHNvY2tldCBzdHJj
YXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKLSAgICAgICAg
ICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0
b3VsbCB0enNldCBcCi0gICAgICAgICAgICAgICAgdW5hbWUgXAogCisjIENoZWNrcyBmb3IgaGVh
ZGVyIGZpbGVzLgorZm9yIGFjX2hlYWRlciBpbiB5YWpsL3lhamxfdmVyc2lvbi5oCiBkbyA6Ci0g
IGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAot
YWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFyIgotaWYg
ZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBhY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAieWFqbC95YWpsX3ZlcnNpb24uaCIgImFj
X2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitp
ZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiA9IHgiInllczsgdGhl
biA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZF
XyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKKyNkZWZpbmUgSEFWRV9ZQUpMX1lBSkxfVkVSU0lP
Tl9IIDEKIF9BQ0VPRgogCiBmaQorCiBkb25lCiAKIApkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmln
dXJlLmFjIGIvdG9vbHMvY29uZmlndXJlLmFjCmluZGV4IDI1MGRmZmQuLjdmZGUyZmIgMTAwNjQ0
Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYworKysgYi90b29scy9jb25maWd1cmUuYWMKQEAgLTE5
LDkgKzE5LDYgQEAgcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJ
QiwgXAogQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJs
ZS5dKQogXSkKIAotQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCi1BQ19DQU5PTklDQUxfSE9TVAot
CiAjIE00IE1hY3JvIGluY2x1ZGVzCiBtNF9pbmNsdWRlKFttNC9zYXZldmFyLm00XSkKIG00X2lu
Y2x1ZGUoW200L2ZlYXR1cmVzLm00XSkKQEAgLTcyLDkgKzY5LDcgQEAgQUNfQVJHX1ZBUihbQkND
XSwgW1BhdGggdG8gYmNjIHRvb2xdKQogQUNfQVJHX1ZBUihbSUFTTF0sIFtQYXRoIHRvIGlhc2wg
dG9vbF0pCiAKICMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KLUFDX1BST0dfU0VECiBBQ19QUk9HX0ND
Ci1BQ19QUk9HX0xOX1MKIEFDX1BST0dfTUFLRV9TRVQKIEFDX1BST0dfSU5TVEFMTAogQVhfUEFU
SF9QUk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVybF0pCkBAIC0xMzIsNyArMTI3LDcgQEAgQUNfU1VC
U1QobGliZXh0MmZzKQogQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZl
cl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQogQUNfU1VCU1QobGliZ2NyeXB0
KQogQVhfQ0hFQ0tfUFRIUkVBRAotQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1lXSkK
K0FYX0NIRUNLX1BUWUZVTkNTCiBBQ19DSEVDS19MSUIoW3lhamxdLCBbeWFqbF9hbGxvY10sIFtd
LAogICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHlhamxdKV0pCiBBQ19DSEVDS19M
SUIoW3pdLCBbZGVmbGF0ZUNvcHldLCBbXSwgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQg
emxpYl0pXSkKQEAgLTE0MCw1OCArMTM1LDYgQEAgQUNfQ0hFQ0tfTElCKFtpY29udl0sIFtsaWJp
Y29udl9vcGVuXSwgW2xpYmljb252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQogQUNfU1VCU1QobGli
aWNvbnYpCiAKICMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCi1BQ19GVU5DX0FMTE9DQQotQUNf
Q0hFQ0tfSEVBREVSUyhbIFwKLSAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGlu
dHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKLSAgICAgICAgICAgICAgICBu
ZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBc
Ci0gICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21v
dW50Lmggc3lzL3BhcmFtLmggXAotICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3Rh
dHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKLSAgICAgICAgICAgICAgICB1
bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKLSAgICAgICAgICAgICAgICBdKQotCi0jIENo
ZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3Rp
Y3MuCi1BQ19IRUFERVJfU1REQk9PTAotQUNfVFlQRV9VSURfVAotQUNfQ19JTkxJTkUKLUFDX1RZ
UEVfSU5UMTZfVAotQUNfVFlQRV9JTlQzMl9UCi1BQ19UWVBFX0lOVDY0X1QKLUFDX1RZUEVfSU5U
OF9UCi1BQ19UWVBFX01PREVfVAotQUNfVFlQRV9PRkZfVAotQUNfVFlQRV9QSURfVAotQUNfQ19S
RVNUUklDVAotQUNfVFlQRV9TSVpFX1QKLUFDX1RZUEVfU1NJWkVfVAotQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCi1BQ19TVFJVQ1RfU1RfQkxPQ0tTCi1BQ19DSEVD
S19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9yZGV2XSkKLUFDX1RZUEVfVUlOVDE2X1QKLUFDX1RZ
UEVfVUlOVDMyX1QKLUFDX1RZUEVfVUlOVDY0X1QKLUFDX1RZUEVfVUlOVDhfVAotQUNfQ0hFQ0tf
VFlQRVMoW3B0cmRpZmZfdF0pCi0KLSMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KLUFD
X0ZVTkNfRVJST1JfQVRfTElORQotQUNfRlVOQ19GT1JLCi1BQ19GVU5DX0ZTRUVLTwotQUNfRlVO
Q19MU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSwotQUNfSEVBREVSX01BSk9SCi1BQ19GVU5D
X01BTExPQwotQUNfRlVOQ19NS1RJTUUKLUFDX0ZVTkNfTU1BUAotQUNfRlVOQ19SRUFMTE9DCi1B
Q19GVU5DX1NUUk5MRU4KLUFDX0ZVTkNfU1RSVE9ECi1BQ19DSEVDS19GVU5DUyhbIFwKLSAgICAg
ICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3lu
YyBmdHJ1bmNhdGUgXAotICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhv
c3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCi0gICAgICAgICAgICAgICAgaW5ldF9u
dG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKLSAg
ICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1k
aXIgc2VsZWN0IHNldGVudiBcCi0gICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3Ry
Y2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAotICAgICAgICAgICAgICAgIHN0
cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0
IFwKLSAgICAgICAgICAgICAgICB1bmFtZSBcCi0gICAgICAgICAgICAgICAgXSkKK0FDX0NIRUNL
X0hFQURFUlMoW3lhamwveWFqbF92ZXJzaW9uLmhdKQogCiBBQ19PVVRQVVQoKQotLSAKMS43LjIu
NQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZJ-0003wJ-8y; Mon, 16 Apr 2012 17:18:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZB-0003jQ-6p
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:17 +0000
Received: from [193.109.254.147:55727] by server-11.bemta-14.messagelabs.com
	id B7/16-05858-8545C8F4; Mon, 16 Apr 2012 17:18:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18157 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kh-Kt; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Ep-Jf;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:01 +0100
Message-ID: <1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for
	long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used for reporting, during domain creation, that the
console is ready.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   45 +++++++++++++++
 tools/libxl/libxl_event.c    |  122 ++++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |   28 ++++++++++
 3 files changed, 167 insertions(+), 28 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6f59364..1bfe684 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -435,6 +435,51 @@ typedef struct {
     } u;
 } libxl_asyncop_how;
 
+/*
+ * Some more complex asynchronous operations can report intermediate
+ * progress.  How this is to be reported is controlled, for each
+ * function, by a parameter
+ *    libxl_asyncprogress_how *aop_FOO_how;
+ * for each kind of progress FOO supported by that function.  Each
+ * such kind of progress is associated with an event type.
+ *
+ * The function description will document whether, when, and how
+ * many times, the intermediate progress will be reported, and
+ * what the corresponding event type(s) are.
+ *
+ * If aop_FOO_how==NULL, intermediate progress reports are discarded.
+ *
+ * If aop_FOO_how->callback==NULL, intermediate progress reports
+ * generate libxl events which can be obtained from libxl_event_wait
+ * or libxl_event_check.
+ *
+ * If aop_FOO_how->callback!=NULL, libxl will report intermediate
+ * progress by calling callback(ctx, &event, for_callback).
+ *
+ * The rules for these events are otherwise the same as those for
+ * ordinary events.  The reentrancy and threading rules for the
+ * callback are the same as those for ao completion callbacks.
+ *
+ * Note that the callback, if provided, is responsible for freeing
+ * the event.
+ *
+ * If callbacks are requested, they will be made, and returned, before
+ * the long-running libxl operation is considered finished (so if the
+ * long-running libxl operation was invoked with ao_how==NULL then any
+ * callbacks will occur strictly before the long-running operation
+ * returns).  However, the callbacks may occur on any thread.
+ *
+ * In general, otherwise, no promises are made about the relative
+ * order of callbacks in a multithreaded program.  In particular
+ * different callbacks relating to the same long-running operation may
+ * be delivered out of order.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback);
+    libxl_ev_user for_event; /* always used */
+    void *for_callback; /* passed to callback */
+} libxl_asyncprogress_how;
 
 #define LIBXL_VERSION 0
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 2f559d5..3795654 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+    libxl__aop_occurred *aop, *aop_tmp;
 
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
 
+    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
+        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
+
+        CTX_LOCK;
+        aop->ao->progress_reports_outstanding--;
+        libxl__ao_complete_check_progress_reports(egc, aop->ao);
+        CTX_UNLOCK;
+
+        free(aop);
+    }
+
     libxl__ao *ao, *ao_tmp;
     LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
                              entry_for_callback, ao_tmp) {
@@ -1285,6 +1298,7 @@ void libxl__ao_abort(libxl__ao *ao)
     assert(ao->magic == LIBXL__AO_MAGIC);
     assert(ao->in_initiator);
     assert(!ao->complete);
+    assert(!ao->progress_reports_outstanding);
     libxl__ao__destroy(CTX, ao);
 }
 
@@ -1295,6 +1309,23 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
     ao->complete = 1;
     ao->rc = rc;
 
+    libxl__ao_complete_check_progress_reports(egc, ao);
+}
+
+void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+{
+    /* We don't consider an ao complete if it has any outstanding
+     * callbacks.  These callbacks might be outstanding on other
+     * threads, queued up in the other threads' egc's.  Those threads
+     * will, after making the callback, take out the lock again,
+     * decrememt progress_reports_outstanding, and call us again.
+     */
+
+    assert(ao->progress_reports_outstanding >= 0);
+
+    if (!ao->complete || ao->progress_reports_outstanding)
+        return;
+
     if (ao->poller) {
         assert(ao->in_initiator);
         if (!ao->constructing)
@@ -1316,34 +1347,6 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
         libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
 }
 
-libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
-                            const libxl_asyncop_how *how)
-{
-    libxl__ao *ao;
-
-    ao = calloc(1, sizeof(*ao));
-    if (!ao) goto out;
-
-    ao->magic = LIBXL__AO_MAGIC;
-    ao->constructing = 1;
-    ao->in_initiator = 1;
-    ao->poller = 0;
-    ao->domid = domid;
-    LIBXL_INIT_GC(ao->gc, ctx);
-
-    if (how) {
-        ao->how = *how;
-    } else {
-        ao->poller = libxl__poller_get(ctx);
-        if (!ao->poller) goto out;
-    }
-    return ao;
-
- out:
-    if (ao) libxl__ao__destroy(ctx, ao);
-    return NULL;
-}
-
 int libxl__ao_inprogress(libxl__ao *ao)
 {
     AO_GC;
@@ -1401,6 +1404,69 @@ int libxl__ao_inprogress(libxl__ao *ao)
 }
 
 
+/* progress reporting */
+
+/* The application indicates a desire to ignore events by passing NULL
+ * for how.  But we want to copy *how.  So we have this dummy function
+ * whose address is stored in callback if the app passed how==NULL. */
+static void dummy_asyncprogress_callback_ignore
+  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
+
+void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                               const libxl_asyncprogress_how *from_app) {
+    if (from_app)
+        *in_state = *from_app;
+    else
+        in_state->callback = dummy_asyncprogress_callback_ignore;
+}
+
+void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+        const libxl_asyncprogress_how *how, libxl_event *ev)
+{
+    ev->for_user = how->for_event;
+    if (how->callback == dummy_asyncprogress_callback_ignore) {
+        /* ignore */
+    } else if (how->callback) {
+        libxl__aop_occurred *aop = libxl__zalloc(0, sizeof(*aop));
+        ao->progress_reports_outstanding++;
+        aop->ao = ao;
+        aop->ev = ev;
+        aop->how = how;
+    } else {
+        libxl__event_occurred(egc, ev);
+    }
+}
+
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how)
+{
+    libxl__ao *ao;
+
+    ao = calloc(1, sizeof(*ao));
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 56c3eec..4e97f5e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -118,6 +118,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
+typedef struct libxl__aop_occurred libxl__aop_occurred;
 
 void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
@@ -372,6 +373,14 @@ struct libxl__egc {
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback;
+};
+
+struct libxl__aop_occurred {
+    LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry;
+    libxl__ao *ao;
+    libxl_event *ev;
+    const libxl_asyncprogress_how *how;
 };
 
 #define LIBXL__AO_MAGIC              0xA0FACE00ul
@@ -380,6 +389,7 @@ struct libxl__egc {
 struct libxl__ao {
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
+    int progress_reports_outstanding;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1369,6 +1379,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
         LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
+        LIBXL_TAILQ_INIT(&(egc).aops_for_callback);     \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1415,6 +1426,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *        pointer to the internal event generation request routines
  *        libxl__evgen_FOO, so that at some point a CALLBACK will be
  *        made when the operation is complete.
+ *      - if the operation provides progress reports, the aop_how(s)
+ *        must be copied into the per-operation structure using
+ *        libxl__ao_progress_gethow.
  *
  * - If initiation is successful, the initiating function needs
  *   to run libxl__ao_inprogress right before unlocking and
@@ -1424,6 +1438,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   call libxl__ao_abort before unlocking and returning whatever
  *   error code is appropriate (AO_ABORT macro).
  *
+ * - If the operation supports progress reports, it may generate
+ *   suitable events with NEW_EVENT and report them with
+ *   libxl__ao_progress_report (with the ctx locked).
+ *
  * - Later, some callback function, whose callback has been requested
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
@@ -1479,8 +1497,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
+/* Can be called at any time.  Use is essential for any aop user. */
+_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                                       const libxl_asyncprogress_how *from_app);
+
+/* Must be called with the ctx locked.  Will fill in ev->for_user,
+ * so caller need not do that. */
+_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+   const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */);
+
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*);
 
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZJ-0003wJ-8y; Mon, 16 Apr 2012 17:18:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZB-0003jQ-6p
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:17 +0000
Received: from [193.109.254.147:55727] by server-11.bemta-14.messagelabs.com
	id B7/16-05858-8545C8F4; Mon, 16 Apr 2012 17:18:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18157 invoked from network); 16 Apr 2012 17:18:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kh-Kt; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002Ep-Jf;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:01 +0100
Message-ID: <1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for
	long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used for reporting, during domain creation, that the
console is ready.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   45 +++++++++++++++
 tools/libxl/libxl_event.c    |  122 ++++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |   28 ++++++++++
 3 files changed, 167 insertions(+), 28 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6f59364..1bfe684 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -435,6 +435,51 @@ typedef struct {
     } u;
 } libxl_asyncop_how;
 
+/*
+ * Some more complex asynchronous operations can report intermediate
+ * progress.  How this is to be reported is controlled, for each
+ * function, by a parameter
+ *    libxl_asyncprogress_how *aop_FOO_how;
+ * for each kind of progress FOO supported by that function.  Each
+ * such kind of progress is associated with an event type.
+ *
+ * The function description will document whether, when, and how
+ * many times, the intermediate progress will be reported, and
+ * what the corresponding event type(s) are.
+ *
+ * If aop_FOO_how==NULL, intermediate progress reports are discarded.
+ *
+ * If aop_FOO_how->callback==NULL, intermediate progress reports
+ * generate libxl events which can be obtained from libxl_event_wait
+ * or libxl_event_check.
+ *
+ * If aop_FOO_how->callback!=NULL, libxl will report intermediate
+ * progress by calling callback(ctx, &event, for_callback).
+ *
+ * The rules for these events are otherwise the same as those for
+ * ordinary events.  The reentrancy and threading rules for the
+ * callback are the same as those for ao completion callbacks.
+ *
+ * Note that the callback, if provided, is responsible for freeing
+ * the event.
+ *
+ * If callbacks are requested, they will be made, and returned, before
+ * the long-running libxl operation is considered finished (so if the
+ * long-running libxl operation was invoked with ao_how==NULL then any
+ * callbacks will occur strictly before the long-running operation
+ * returns).  However, the callbacks may occur on any thread.
+ *
+ * In general, otherwise, no promises are made about the relative
+ * order of callbacks in a multithreaded program.  In particular
+ * different callbacks relating to the same long-running operation may
+ * be delivered out of order.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback);
+    libxl_ev_user for_event; /* always used */
+    void *for_callback; /* passed to callback */
+} libxl_asyncprogress_how;
 
 #define LIBXL_VERSION 0
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 2f559d5..3795654 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+    libxl__aop_occurred *aop, *aop_tmp;
 
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
 
+    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
+        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
+
+        CTX_LOCK;
+        aop->ao->progress_reports_outstanding--;
+        libxl__ao_complete_check_progress_reports(egc, aop->ao);
+        CTX_UNLOCK;
+
+        free(aop);
+    }
+
     libxl__ao *ao, *ao_tmp;
     LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
                              entry_for_callback, ao_tmp) {
@@ -1285,6 +1298,7 @@ void libxl__ao_abort(libxl__ao *ao)
     assert(ao->magic == LIBXL__AO_MAGIC);
     assert(ao->in_initiator);
     assert(!ao->complete);
+    assert(!ao->progress_reports_outstanding);
     libxl__ao__destroy(CTX, ao);
 }
 
@@ -1295,6 +1309,23 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
     ao->complete = 1;
     ao->rc = rc;
 
+    libxl__ao_complete_check_progress_reports(egc, ao);
+}
+
+void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+{
+    /* We don't consider an ao complete if it has any outstanding
+     * callbacks.  These callbacks might be outstanding on other
+     * threads, queued up in the other threads' egc's.  Those threads
+     * will, after making the callback, take out the lock again,
+     * decrememt progress_reports_outstanding, and call us again.
+     */
+
+    assert(ao->progress_reports_outstanding >= 0);
+
+    if (!ao->complete || ao->progress_reports_outstanding)
+        return;
+
     if (ao->poller) {
         assert(ao->in_initiator);
         if (!ao->constructing)
@@ -1316,34 +1347,6 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
         libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
 }
 
-libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
-                            const libxl_asyncop_how *how)
-{
-    libxl__ao *ao;
-
-    ao = calloc(1, sizeof(*ao));
-    if (!ao) goto out;
-
-    ao->magic = LIBXL__AO_MAGIC;
-    ao->constructing = 1;
-    ao->in_initiator = 1;
-    ao->poller = 0;
-    ao->domid = domid;
-    LIBXL_INIT_GC(ao->gc, ctx);
-
-    if (how) {
-        ao->how = *how;
-    } else {
-        ao->poller = libxl__poller_get(ctx);
-        if (!ao->poller) goto out;
-    }
-    return ao;
-
- out:
-    if (ao) libxl__ao__destroy(ctx, ao);
-    return NULL;
-}
-
 int libxl__ao_inprogress(libxl__ao *ao)
 {
     AO_GC;
@@ -1401,6 +1404,69 @@ int libxl__ao_inprogress(libxl__ao *ao)
 }
 
 
+/* progress reporting */
+
+/* The application indicates a desire to ignore events by passing NULL
+ * for how.  But we want to copy *how.  So we have this dummy function
+ * whose address is stored in callback if the app passed how==NULL. */
+static void dummy_asyncprogress_callback_ignore
+  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
+
+void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                               const libxl_asyncprogress_how *from_app) {
+    if (from_app)
+        *in_state = *from_app;
+    else
+        in_state->callback = dummy_asyncprogress_callback_ignore;
+}
+
+void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+        const libxl_asyncprogress_how *how, libxl_event *ev)
+{
+    ev->for_user = how->for_event;
+    if (how->callback == dummy_asyncprogress_callback_ignore) {
+        /* ignore */
+    } else if (how->callback) {
+        libxl__aop_occurred *aop = libxl__zalloc(0, sizeof(*aop));
+        ao->progress_reports_outstanding++;
+        aop->ao = ao;
+        aop->ev = ev;
+        aop->how = how;
+    } else {
+        libxl__event_occurred(egc, ev);
+    }
+}
+
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how)
+{
+    libxl__ao *ao;
+
+    ao = calloc(1, sizeof(*ao));
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 56c3eec..4e97f5e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -118,6 +118,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
+typedef struct libxl__aop_occurred libxl__aop_occurred;
 
 void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
@@ -372,6 +373,14 @@ struct libxl__egc {
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback;
+};
+
+struct libxl__aop_occurred {
+    LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry;
+    libxl__ao *ao;
+    libxl_event *ev;
+    const libxl_asyncprogress_how *how;
 };
 
 #define LIBXL__AO_MAGIC              0xA0FACE00ul
@@ -380,6 +389,7 @@ struct libxl__egc {
 struct libxl__ao {
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
+    int progress_reports_outstanding;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1369,6 +1379,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
         LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
+        LIBXL_TAILQ_INIT(&(egc).aops_for_callback);     \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1415,6 +1426,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *        pointer to the internal event generation request routines
  *        libxl__evgen_FOO, so that at some point a CALLBACK will be
  *        made when the operation is complete.
+ *      - if the operation provides progress reports, the aop_how(s)
+ *        must be copied into the per-operation structure using
+ *        libxl__ao_progress_gethow.
  *
  * - If initiation is successful, the initiating function needs
  *   to run libxl__ao_inprogress right before unlocking and
@@ -1424,6 +1438,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   call libxl__ao_abort before unlocking and returning whatever
  *   error code is appropriate (AO_ABORT macro).
  *
+ * - If the operation supports progress reports, it may generate
+ *   suitable events with NEW_EVENT and report them with
+ *   libxl__ao_progress_report (with the ctx locked).
+ *
  * - Later, some callback function, whose callback has been requested
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
@@ -1479,8 +1497,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
+/* Can be called at any time.  Use is essential for any aop user. */
+_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                                       const libxl_asyncprogress_how *from_app);
+
+/* Must be called with the ctx locked.  Will fill in ev->for_user,
+ * so caller need not do that. */
+_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+   const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */);
+
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*);
 
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZD-0003mZ-Sg; Mon, 16 Apr 2012 17:18:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ8-0003hN-LD
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [193.109.254.147:55522] by server-10.bemta-14.messagelabs.com
	id C1/BA-05847-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18103 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kW-GX; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EN-Di;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:54 +0100
Message-ID: <1334596686-8479-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/24] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 19b4615..f0d94c6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZD-0003mZ-Sg; Mon, 16 Apr 2012 17:18:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ8-0003hN-LD
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:14 +0000
Received: from [193.109.254.147:55522] by server-10.bemta-14.messagelabs.com
	id C1/BA-05847-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18103 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003kW-GX; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002EN-Di;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:17:54 +0100
Message-ID: <1334596686-8479-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/24] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 19b4615..f0d94c6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZE-0003ny-N6; Mon, 16 Apr 2012 17:18:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003hm-7m
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [193.109.254.147:50653] by server-8.bemta-14.messagelabs.com id
	1A/24-23244-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18113 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ke-K0; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002El-J8;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:00 +0100
Message-ID: <1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run bootloader
	via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change initiate_domain_create to properly use libxl__bootloader_run
rather than improperly calling libxl_run_bootloader with NULL ao_how.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v6:
 * Bugfixes from testing.
---
 tools/libxl/libxl_create.c   |   52 ++++++++++++++++++++++++++++++++---------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 09a03a7..1dd9a02 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,6 +550,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int rc);
 
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
@@ -570,6 +573,7 @@ static void initiate_domain_create(libxl__egc *egc,
     int restore_fd = dcs->restore_fd;
     libxl_console_ready cb = dcs->console_cb;
     void *priv = dcs->console_cb_priv;
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
 
@@ -599,21 +603,44 @@ static void initiate_domain_create(libxl__egc *egc,
         if (ret) goto error_out;
     }
 
+    dcs->bl.ao = ao;
     libxl_device_disk *bootdisk =
         d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
 
     if (restore_fd < 0 && bootdisk) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
-                                   0 /* fixme-ao */);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to run bootloader: %d", ret);
-            goto error_out;
-        }
+        dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.info = &d_config->b_info,
+        dcs->bl.disk = bootdisk;
+        dcs->bl.domid = dcs->guest_domid;
+            
+        libxl__bootloader_run(egc, &dcs->bl);
+    } else {
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     }
+    return;
 
-    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    int i;
+
+    /* convenience aliases */
+    uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *state = &dcs->build_state;
+    libxl_ctx *ctx = CTX;
+
+    if (ret) goto error_out;
+
     dcs->dmss.spawn.ao = ao;
     dcs->dmss.guest_config = dcs->guest_config;
     dcs->dmss.build_state = &dcs->build_state;
@@ -764,12 +791,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
+        ret = libxl__e820_alloc(gc, domid, d_config);
+        if (ret) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
+                      ret, errno);
+            goto error_out;
+        }
     }
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5bab4d6..56c3eec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1669,6 +1669,7 @@ struct libxl__domain_create_state {
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
+    libxl__bootloader_state bl;
     union {
         libxl__dm_spawn_state dmss;
         libxl__stubdom_spawn_state sdss;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpZE-0003ny-N6; Mon, 16 Apr 2012 17:18:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJpZ9-0003hm-7m
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:18:15 +0000
Received: from [193.109.254.147:50653] by server-8.bemta-14.messagelabs.com id
	1A/24-23244-6545C8F4; Mon, 16 Apr 2012 17:18:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334596690!4867267!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18113 invoked from network); 16 Apr 2012 17:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 17:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11961754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 17:18:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 18:18:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SJpZ4-0003ke-K0; Mon, 16 Apr 2012 17:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SJpZ4-0002El-J8;
	Mon, 16 Apr 2012 18:18:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 18:18:00 +0100
Message-ID: <1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run bootloader
	via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change initiate_domain_create to properly use libxl__bootloader_run
rather than improperly calling libxl_run_bootloader with NULL ao_how.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v6:
 * Bugfixes from testing.
---
 tools/libxl/libxl_create.c   |   52 ++++++++++++++++++++++++++++++++---------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 09a03a7..1dd9a02 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -550,6 +550,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int rc);
 
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
@@ -570,6 +573,7 @@ static void initiate_domain_create(libxl__egc *egc,
     int restore_fd = dcs->restore_fd;
     libxl_console_ready cb = dcs->console_cb;
     void *priv = dcs->console_cb_priv;
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
 
@@ -599,21 +603,44 @@ static void initiate_domain_create(libxl__egc *egc,
         if (ret) goto error_out;
     }
 
+    dcs->bl.ao = ao;
     libxl_device_disk *bootdisk =
         d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
 
     if (restore_fd < 0 && bootdisk) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
-                                   0 /* fixme-ao */);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to run bootloader: %d", ret);
-            goto error_out;
-        }
+        dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.info = &d_config->b_info,
+        dcs->bl.disk = bootdisk;
+        dcs->bl.domid = dcs->guest_domid;
+            
+        libxl__bootloader_run(egc, &dcs->bl);
+    } else {
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     }
+    return;
 
-    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    int i;
+
+    /* convenience aliases */
+    uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *d_config = dcs->guest_config;
+    int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *state = &dcs->build_state;
+    libxl_ctx *ctx = CTX;
+
+    if (ret) goto error_out;
+
     dcs->dmss.spawn.ao = ao;
     dcs->dmss.guest_config = dcs->guest_config;
     dcs->dmss.build_state = &dcs->build_state;
@@ -764,12 +791,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
+        ret = libxl__e820_alloc(gc, domid, d_config);
+        if (ret) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
+                      ret, errno);
+            goto error_out;
+        }
     }
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5bab4d6..56c3eec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1669,6 +1669,7 @@ struct libxl__domain_create_state {
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
+    libxl__bootloader_state bl;
     union {
         libxl__dm_spawn_state dmss;
         libxl__stubdom_spawn_state sdss;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbe-00063x-1V; Mon, 16 Apr 2012 17:20:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbb-00061z-TV
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.138.51:38815] by server-8.bemta-3.messagelabs.com id
	B9/6D-24428-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334596845!22418949!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23862 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKgTs011138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgDC011675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKghD018207; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B7C8C4035D; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:37 -0400
Message-Id: <1334596539-18172-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F8C54EB.007B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 6/8] xen/setup: Work properly with 'dom0_mem=X'
	or with not dom0_mem.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We ignored the X value and ended up populating up to
max(MAX_DOMAIN_PAGES, last E820_RAM entry).

This fixes it by figuring out how many RAM nr_pages the
hypervisor wanted to provide to us and cap the populate
hypercalls up to that.

The end result is (on a 8GB box):

dom0_mem=1G
-Memory: 610884k/9435136k available (5817k kernel code, 1136060k absent, 7688192k reserved, 2899k data, 696k init)
+Memory: 724184k/1053064k available (5817k kernel code, 4552k absent, 324328k reserved, 2899k data, 696k init)

no dom0_mem
-Memory: 7619036k/9435136k available (5817k kernel code, 1136060k absent, 680040k reserved, 2899k data, 696k init)
+Memory: 7621460k/9208688k available (5817k kernel code, 1136060k absent, 451168k reserved, 2899k data, 696k init)

[v1: Details added]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7b0ab77..0e82bf1 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -185,11 +185,29 @@ static unsigned long __init xen_get_max_pages(void)
 	 * the current maximum rather than the static maximum. In this
 	 * case the e820 map provided to us will cover the static
 	 * maximum region.
+	 *
+	 * The dom0_mem=min:X,max:Y tweaks options differently depending
+	 * on the version, but in general this is what we get:
+	 *                | XENMEM_maximum_reser  | nr_pages
+	 * --------------++-----------------------+-------------------
+	 *  no dom0_mem   | INT_MAX               | max_phys_pfn
+	 *  =3G           | INT_MAX               | 786432
+	 *  =max:3G       | 786432                | 786432
+	 *  =min:1G,max:3G| INT_MAX               | max_phys_fn
+	 *  =1G,max:3G    | INT_MAX               | 262144
+	 *  =min:1G,max:3G,2G | INT_MAX           | max_phys_fn
+	 *
+	 * The =3G is often used and it lead to us initially setting
+	 * 786432 and allowing dom0 to balloon up to the max_physical_pfn.
+	 * This is at odd with the classic XenOClassic so lets emulate
+	 * the classic behavior.
 	 */
 	if (xen_initial_domain()) {
 		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
 		if (ret > 0)
 			max_pages = ret;
+		if (ret == -1UL)
+			max_pages = xen_start_info->nr_pages;
 	}
 
 	return min(max_pages, MAX_DOMAIN_PAGES);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbc-00062t-Jz; Mon, 16 Apr 2012 17:20:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbb-00061V-2h
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:47 +0000
Received: from [85.158.143.35:23914] by server-2.bemta-4.messagelabs.com id
	D7/3D-17550-EE45C8F4; Mon, 16 Apr 2012 17:20:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334596844!13507467!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7871 invoked from network); 16 Apr 2012 17:20:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKg93011127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfBG011649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:41 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfhc020213; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 779F440280; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:31 -0400
Message-Id: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F8C54EB.0027,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X
	inconsistencies (v5).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changelog v5 [since v4]:
 - used populate_physmap, fixed bugs.
[v2-v4: not posted]
 - reworked the code in setup.c to work properly.
[v1: https://lkml.org/lkml/2012/3/30/492]
 - initial patchset


These patches that did not change between the first posting and this one are:

      xen/p2m: Move code around to allow for better re-usage.
      xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
      xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
      xen/p2m: An early bootup variant of set_phys_to_machine

so if you read them before - you can skip them.

The purpose of these patches is three-fold:
 1) Fix the case where dom0_mem=X is not used and the machine boots with less
    memory than it should. A subsequent 'xl mem-set 0 X' is required to balloon up
    to the right amount. Here is an example of what it looks like with the older
    kernels and with a pvops (and the patches):

	2.6.32 SLES:
	Memory: 7538688k/8079432k available (3971k kernel code, 8192k absent, 532300k reserved, 2491k data, 348k init)
	MemTotal:        8063140 kB
	MemFree:         7421504 kB
	DirectMap4k:     8071240 kB
	Domain-0                                     0  7873     4     r-----     20.3

	3.3:
	Memory: 6486452k/9208688k available (5825k kernel code, 1136060k absent, 1586176k reserved, 2890k data, 692k init)
	MemTotal:        6716156 kB
	MemFree:         6365696 kB
	DirectMap4k:     8078192 kB
	Domain-0                                     0  6774     4     r-----     26.0

	3.3+patches:
	Memory: 7621460k/9208688k available (5817k kernel code, 1136060k absent, 451168k reserved, 2899k data, 692k init)
	MemTotal:        7849924 kB
	MemFree:         7500748 kB
	DirectMap4k:     8078192 kB
	Domain-0                                     0  7883     4     r-----     11.9

    This is implemented in:
    [PATCH 7/8] xen/setup: Populate freed MFNs from non-RAM E820 entries

 2). Fix where dom0_mem=XXXG is used (so the 'max' parameter is not involved). The
     bug is that we would ignore it:

	With dom0_mem=1G
	2.6.32 SLES:
	Memory: 650240k/1056768k available (3971k kernel code, 8192k absent, 397852k reserved, 2491k data, 348k init)
	3.3:
	Memory: 610884k/9435136k available (5817k kernel code, 1136060k absent, 7688192k reserved, 2899k data, 696k init)
	3.3+patches:
	Memory: 724184k/1053064k available (5817k kernel code, 4552k absent, 324328k reserved, 2899k data, 696k init)

   This is implemented in:
   [PATCH 6/8] xen/setup: Work properly with 'dom0_mem=X' or with not


Note, that the combination of 'dom0_mem=XXXG,max:YYYG' is perfectly fine, so there is no
need to fix that:

	With dom0_mem=1G,max:3G

	2.6.32 SLES:
	Memory: 650240k/1056768k available (3971k kernel code, 8192k absent, 397852k reserved, 2491k data, 348k init)
	3.3:
	Memory: 690324k/4281724k available (5826k kernel code, 1136060k absent, 2455340k reserved, 2891k data, 692k init)
	3.3+patches:
	Memory: 690960k/4281724k available (5824k kernel code, 1136060k absent, 2454704k reserved, 2893k data, 692k init)


Konrad Rzeszutek Wilk (8):
      xen/p2m: Move code around to allow for better re-usage.
      xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
      xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
      xen/p2m: An early bootup variant of set_phys_to_machine
      xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
      xen/setup: Work properly with 'dom0_mem=X' or with not dom0_mem.
      xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
      xen/setup: Combine the two hypercall functions - since they are quite similar.

 arch/x86/include/asm/xen/page.h |    1 +
 arch/x86/xen/p2m.c              |  104 ++++++++++++++++-----------
 arch/x86/xen/setup.c            |  152 +++++++++++++++++++++++++++++++++------
 3 files changed, 193 insertions(+), 64 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbe-00064l-Uc; Mon, 16 Apr 2012 17:20:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-000625-1w
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.143.35:23949] by server-3.bemta-4.messagelabs.com id
	45/FA-05853-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334596845!7326926!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwNjcx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14573 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKh7g025889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfYM019661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfbl018193; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9AD5D40359; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:34 -0400
Message-Id: <1334596539-18172-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8C54EC.0008,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/8] xen/p2m: Collapse early_alloc_p2m_middle
	redundant checks.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At the start of the function we were checking for idx != 0
and bailing out. And later calling extend_brk if idx != 0.

That is unnecessary so remove that checks.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |   25 ++++++++++++-------------
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b3a395..952edef 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -502,6 +502,8 @@ static bool alloc_p2m(unsigned long pfn)
 static bool __init early_alloc_p2m_middle(unsigned long pfn, bool check_boundary)
 {
 	unsigned topidx, mididx, idx;
+	unsigned long *p2m;
+	unsigned long *mid_mfn_p;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -522,24 +524,21 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn, bool check_boundary
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	if (idx) {
-		unsigned long *p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
-		unsigned long *mid_mfn_p;
+	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
 
-		p2m_init(p2m);
+	p2m_init(p2m);
 
-		p2m_top[topidx][mididx] = p2m;
+	p2m_top[topidx][mididx] = p2m;
 
-		/* For save/restore we need to MFN of the P2M saved */
+	/* For save/restore we need to MFN of the P2M saved */
 
-		mid_mfn_p = p2m_top_mfn_p[topidx];
-		WARN(mid_mfn_p[mididx] != virt_to_mfn(p2m_missing),
-			"P2M_TOP_P[%d][%d] != MFN of p2m_missing!\n",
-			topidx, mididx);
-		mid_mfn_p[mididx] = virt_to_mfn(p2m);
+	mid_mfn_p = p2m_top_mfn_p[topidx];
+	WARN(mid_mfn_p[mididx] != virt_to_mfn(p2m_missing),
+		"P2M_TOP_P[%d][%d] != MFN of p2m_missing!\n",
+		topidx, mididx);
+	mid_mfn_p[mididx] = virt_to_mfn(p2m);
 
-	}
-	return idx != 0;
+	return true;
 }
 
 static bool __init early_alloc_p2m(unsigned long pfn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbc-00062t-Jz; Mon, 16 Apr 2012 17:20:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbb-00061V-2h
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:47 +0000
Received: from [85.158.143.35:23914] by server-2.bemta-4.messagelabs.com id
	D7/3D-17550-EE45C8F4; Mon, 16 Apr 2012 17:20:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334596844!13507467!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7871 invoked from network); 16 Apr 2012 17:20:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKg93011127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfBG011649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:41 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfhc020213; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 779F440280; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:31 -0400
Message-Id: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F8C54EB.0027,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X
	inconsistencies (v5).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changelog v5 [since v4]:
 - used populate_physmap, fixed bugs.
[v2-v4: not posted]
 - reworked the code in setup.c to work properly.
[v1: https://lkml.org/lkml/2012/3/30/492]
 - initial patchset


These patches that did not change between the first posting and this one are:

      xen/p2m: Move code around to allow for better re-usage.
      xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
      xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
      xen/p2m: An early bootup variant of set_phys_to_machine

so if you read them before - you can skip them.

The purpose of these patches is three-fold:
 1) Fix the case where dom0_mem=X is not used and the machine boots with less
    memory than it should. A subsequent 'xl mem-set 0 X' is required to balloon up
    to the right amount. Here is an example of what it looks like with the older
    kernels and with a pvops (and the patches):

	2.6.32 SLES:
	Memory: 7538688k/8079432k available (3971k kernel code, 8192k absent, 532300k reserved, 2491k data, 348k init)
	MemTotal:        8063140 kB
	MemFree:         7421504 kB
	DirectMap4k:     8071240 kB
	Domain-0                                     0  7873     4     r-----     20.3

	3.3:
	Memory: 6486452k/9208688k available (5825k kernel code, 1136060k absent, 1586176k reserved, 2890k data, 692k init)
	MemTotal:        6716156 kB
	MemFree:         6365696 kB
	DirectMap4k:     8078192 kB
	Domain-0                                     0  6774     4     r-----     26.0

	3.3+patches:
	Memory: 7621460k/9208688k available (5817k kernel code, 1136060k absent, 451168k reserved, 2899k data, 692k init)
	MemTotal:        7849924 kB
	MemFree:         7500748 kB
	DirectMap4k:     8078192 kB
	Domain-0                                     0  7883     4     r-----     11.9

    This is implemented in:
    [PATCH 7/8] xen/setup: Populate freed MFNs from non-RAM E820 entries

 2). Fix where dom0_mem=XXXG is used (so the 'max' parameter is not involved). The
     bug is that we would ignore it:

	With dom0_mem=1G
	2.6.32 SLES:
	Memory: 650240k/1056768k available (3971k kernel code, 8192k absent, 397852k reserved, 2491k data, 348k init)
	3.3:
	Memory: 610884k/9435136k available (5817k kernel code, 1136060k absent, 7688192k reserved, 2899k data, 696k init)
	3.3+patches:
	Memory: 724184k/1053064k available (5817k kernel code, 4552k absent, 324328k reserved, 2899k data, 696k init)

   This is implemented in:
   [PATCH 6/8] xen/setup: Work properly with 'dom0_mem=X' or with not


Note, that the combination of 'dom0_mem=XXXG,max:YYYG' is perfectly fine, so there is no
need to fix that:

	With dom0_mem=1G,max:3G

	2.6.32 SLES:
	Memory: 650240k/1056768k available (3971k kernel code, 8192k absent, 397852k reserved, 2491k data, 348k init)
	3.3:
	Memory: 690324k/4281724k available (5826k kernel code, 1136060k absent, 2455340k reserved, 2891k data, 692k init)
	3.3+patches:
	Memory: 690960k/4281724k available (5824k kernel code, 1136060k absent, 2454704k reserved, 2893k data, 692k init)


Konrad Rzeszutek Wilk (8):
      xen/p2m: Move code around to allow for better re-usage.
      xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
      xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
      xen/p2m: An early bootup variant of set_phys_to_machine
      xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
      xen/setup: Work properly with 'dom0_mem=X' or with not dom0_mem.
      xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
      xen/setup: Combine the two hypercall functions - since they are quite similar.

 arch/x86/include/asm/xen/page.h |    1 +
 arch/x86/xen/p2m.c              |  104 ++++++++++++++++-----------
 arch/x86/xen/setup.c            |  152 +++++++++++++++++++++++++++++++++------
 3 files changed, 193 insertions(+), 64 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbe-00064l-Uc; Mon, 16 Apr 2012 17:20:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-000625-1w
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.143.35:23949] by server-3.bemta-4.messagelabs.com id
	45/FA-05853-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334596845!7326926!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwNjcx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14573 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKh7g025889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfYM019661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfbl018193; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9AD5D40359; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:34 -0400
Message-Id: <1334596539-18172-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8C54EC.0008,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/8] xen/p2m: Collapse early_alloc_p2m_middle
	redundant checks.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At the start of the function we were checking for idx != 0
and bailing out. And later calling extend_brk if idx != 0.

That is unnecessary so remove that checks.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |   25 ++++++++++++-------------
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b3a395..952edef 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -502,6 +502,8 @@ static bool alloc_p2m(unsigned long pfn)
 static bool __init early_alloc_p2m_middle(unsigned long pfn, bool check_boundary)
 {
 	unsigned topidx, mididx, idx;
+	unsigned long *p2m;
+	unsigned long *mid_mfn_p;
 
 	topidx = p2m_top_index(pfn);
 	mididx = p2m_mid_index(pfn);
@@ -522,24 +524,21 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn, bool check_boundary
 		return false;
 
 	/* Boundary cross-over for the edges: */
-	if (idx) {
-		unsigned long *p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
-		unsigned long *mid_mfn_p;
+	p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
 
-		p2m_init(p2m);
+	p2m_init(p2m);
 
-		p2m_top[topidx][mididx] = p2m;
+	p2m_top[topidx][mididx] = p2m;
 
-		/* For save/restore we need to MFN of the P2M saved */
+	/* For save/restore we need to MFN of the P2M saved */
 
-		mid_mfn_p = p2m_top_mfn_p[topidx];
-		WARN(mid_mfn_p[mididx] != virt_to_mfn(p2m_missing),
-			"P2M_TOP_P[%d][%d] != MFN of p2m_missing!\n",
-			topidx, mididx);
-		mid_mfn_p[mididx] = virt_to_mfn(p2m);
+	mid_mfn_p = p2m_top_mfn_p[topidx];
+	WARN(mid_mfn_p[mididx] != virt_to_mfn(p2m_missing),
+		"P2M_TOP_P[%d][%d] != MFN of p2m_missing!\n",
+		topidx, mididx);
+	mid_mfn_p[mididx] = virt_to_mfn(p2m);
 
-	}
-	return idx != 0;
+	return true;
 }
 
 static bool __init early_alloc_p2m(unsigned long pfn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbe-00063x-1V; Mon, 16 Apr 2012 17:20:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbb-00061z-TV
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.138.51:38815] by server-8.bemta-3.messagelabs.com id
	B9/6D-24428-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334596845!22418949!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23862 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKgTs011138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgDC011675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKghD018207; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B7C8C4035D; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:37 -0400
Message-Id: <1334596539-18172-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F8C54EB.007B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 6/8] xen/setup: Work properly with 'dom0_mem=X'
	or with not dom0_mem.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We ignored the X value and ended up populating up to
max(MAX_DOMAIN_PAGES, last E820_RAM entry).

This fixes it by figuring out how many RAM nr_pages the
hypervisor wanted to provide to us and cap the populate
hypercalls up to that.

The end result is (on a 8GB box):

dom0_mem=1G
-Memory: 610884k/9435136k available (5817k kernel code, 1136060k absent, 7688192k reserved, 2899k data, 696k init)
+Memory: 724184k/1053064k available (5817k kernel code, 4552k absent, 324328k reserved, 2899k data, 696k init)

no dom0_mem
-Memory: 7619036k/9435136k available (5817k kernel code, 1136060k absent, 680040k reserved, 2899k data, 696k init)
+Memory: 7621460k/9208688k available (5817k kernel code, 1136060k absent, 451168k reserved, 2899k data, 696k init)

[v1: Details added]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7b0ab77..0e82bf1 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -185,11 +185,29 @@ static unsigned long __init xen_get_max_pages(void)
 	 * the current maximum rather than the static maximum. In this
 	 * case the e820 map provided to us will cover the static
 	 * maximum region.
+	 *
+	 * The dom0_mem=min:X,max:Y tweaks options differently depending
+	 * on the version, but in general this is what we get:
+	 *                | XENMEM_maximum_reser  | nr_pages
+	 * --------------++-----------------------+-------------------
+	 *  no dom0_mem   | INT_MAX               | max_phys_pfn
+	 *  =3G           | INT_MAX               | 786432
+	 *  =max:3G       | 786432                | 786432
+	 *  =min:1G,max:3G| INT_MAX               | max_phys_fn
+	 *  =1G,max:3G    | INT_MAX               | 262144
+	 *  =min:1G,max:3G,2G | INT_MAX           | max_phys_fn
+	 *
+	 * The =3G is often used and it lead to us initially setting
+	 * 786432 and allowing dom0 to balloon up to the max_physical_pfn.
+	 * This is at odd with the classic XenOClassic so lets emulate
+	 * the classic behavior.
 	 */
 	if (xen_initial_domain()) {
 		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
 		if (ret > 0)
 			max_pages = ret;
+		if (ret == -1UL)
+			max_pages = xen_start_info->nr_pages;
 	}
 
 	return min(max_pages, MAX_DOMAIN_PAGES);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbe-00064J-F9; Mon, 16 Apr 2012 17:20:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbb-000622-Vl
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.138.51:60219] by server-12.bemta-3.messagelabs.com id
	E0/CB-29760-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334596845!22372801!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22196 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKgPK025877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfnl011648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:41 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfNh020215; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9099C40357; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:33 -0400
Message-Id: <1334596539-18172-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090204.4F8C54EB.0079,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/8] xen/p2m: Allow alloc_p2m_middle to call
	reserve_brk depending on argument
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For identity cases we want to call reserve_brk only on the boundary
conditions of the middle P2M (so P2M[x][y][0] = extend_brk). This is
to work around identify regions (PCI spaces, gaps in E820) which are not
aligned on 2MB regions.

However for the case were we want to allocate P2M middle leafs at the
early bootup stage, irregardless of this alignment check we need some
means of doing that.  For that we provide the new argument.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 3cc3afe..8b3a395 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -499,7 +499,7 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
+static bool __init early_alloc_p2m_middle(unsigned long pfn, bool check_boundary)
 {
 	unsigned topidx, mididx, idx;
 
@@ -508,7 +508,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	idx = p2m_index(pfn);
 
 	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx)
+	if (!idx && check_boundary)
 		return false;
 
 	WARN(p2m_top[topidx][mididx] == p2m_identity,
@@ -531,7 +531,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 		p2m_top[topidx][mididx] = p2m;
 
 		/* For save/restore we need to MFN of the P2M saved */
-		
+
 		mid_mfn_p = p2m_top_mfn_p[topidx];
 		WARN(mid_mfn_p[mididx] != virt_to_mfn(p2m_missing),
 			"P2M_TOP_P[%d][%d] != MFN of p2m_missing!\n",
@@ -592,8 +592,8 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 		WARN_ON(!early_alloc_p2m(pfn));
 	}
 
-	early_alloc_p2m_middle(pfn_s);
-	early_alloc_p2m_middle(pfn_e);
+	early_alloc_p2m_middle(pfn_s, true);
+	early_alloc_p2m_middle(pfn_e, true);
 
 	for (pfn = pfn_s; pfn < pfn_e; pfn++)
 		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbe-00064J-F9; Mon, 16 Apr 2012 17:20:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbb-000622-Vl
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.138.51:60219] by server-12.bemta-3.messagelabs.com id
	E0/CB-29760-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334596845!22372801!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22196 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKgPK025877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfnl011648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:41 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfNh020215; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9099C40357; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:33 -0400
Message-Id: <1334596539-18172-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090204.4F8C54EB.0079,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/8] xen/p2m: Allow alloc_p2m_middle to call
	reserve_brk depending on argument
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For identity cases we want to call reserve_brk only on the boundary
conditions of the middle P2M (so P2M[x][y][0] = extend_brk). This is
to work around identify regions (PCI spaces, gaps in E820) which are not
aligned on 2MB regions.

However for the case were we want to allocate P2M middle leafs at the
early bootup stage, irregardless of this alignment check we need some
means of doing that.  For that we provide the new argument.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 3cc3afe..8b3a395 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -499,7 +499,7 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init early_alloc_p2m_middle(unsigned long pfn)
+static bool __init early_alloc_p2m_middle(unsigned long pfn, bool check_boundary)
 {
 	unsigned topidx, mididx, idx;
 
@@ -508,7 +508,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 	idx = p2m_index(pfn);
 
 	/* Pfff.. No boundary cross-over, lets get out. */
-	if (!idx)
+	if (!idx && check_boundary)
 		return false;
 
 	WARN(p2m_top[topidx][mididx] == p2m_identity,
@@ -531,7 +531,7 @@ static bool __init early_alloc_p2m_middle(unsigned long pfn)
 		p2m_top[topidx][mididx] = p2m;
 
 		/* For save/restore we need to MFN of the P2M saved */
-		
+
 		mid_mfn_p = p2m_top_mfn_p[topidx];
 		WARN(mid_mfn_p[mididx] != virt_to_mfn(p2m_missing),
 			"P2M_TOP_P[%d][%d] != MFN of p2m_missing!\n",
@@ -592,8 +592,8 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 		WARN_ON(!early_alloc_p2m(pfn));
 	}
 
-	early_alloc_p2m_middle(pfn_s);
-	early_alloc_p2m_middle(pfn_e);
+	early_alloc_p2m_middle(pfn_s, true);
+	early_alloc_p2m_middle(pfn_e, true);
 
 	for (pfn = pfn_s; pfn < pfn_e; pfn++)
 		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbf-00065U-Sk; Mon, 16 Apr 2012 17:20:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-00062h-Ns
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [193.109.254.147:16398] by server-1.bemta-14.messagelabs.com id
	AC/6C-29372-0F45C8F4; Mon, 16 Apr 2012 17:20:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334596845!4869570!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10446 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKglR025875
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKf8u008808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:41 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfbY020214; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 84E254032D; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:32 -0400
Message-Id: <1334596539-18172-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090208.4F8C54EB.006C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/8] xen/p2m: Move code around to allow for
	better re-usage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to be using the early_alloc_p2m (and
early_alloc_p2m_middle) code in follow up patches which
are not related to setting identity pages.

Hence lets move the code out in its own function and
rename them as appropiate.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |   62 ++++++++++++++++++++++++++++-----------------------
 1 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 1b267e7..3cc3afe 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -499,7 +499,7 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init __early_alloc_p2m(unsigned long pfn)
+static bool __init early_alloc_p2m_middle(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
@@ -541,6 +541,36 @@ static bool __init __early_alloc_p2m(unsigned long pfn)
 	}
 	return idx != 0;
 }
+
+static bool __init early_alloc_p2m(unsigned long pfn)
+{
+	unsigned topidx = p2m_top_index(pfn);
+	unsigned long *mid_mfn_p;
+	unsigned long **mid;
+
+	mid = p2m_top[topidx];
+	mid_mfn_p = p2m_top_mfn_p[topidx];
+	if (mid == p2m_mid_missing) {
+		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+		p2m_mid_init(mid);
+
+		p2m_top[topidx] = mid;
+
+		BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
+	}
+	/* And the save/restore P2M tables.. */
+	if (mid_mfn_p == p2m_mid_missing_mfn) {
+		mid_mfn_p = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_mfn_init(mid_mfn_p);
+
+		p2m_top_mfn_p[topidx] = mid_mfn_p;
+		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
+		/* Note: we don't set mid_mfn_p[midix] here,
+		 * look in early_alloc_p2m_middle */
+	}
+	return true;
+}
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
@@ -559,35 +589,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 		pfn < ALIGN(pfn_e, (P2M_MID_PER_PAGE * P2M_PER_PAGE));
 		pfn += P2M_MID_PER_PAGE * P2M_PER_PAGE)
 	{
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned long *mid_mfn_p;
-		unsigned long **mid;
-
-		mid = p2m_top[topidx];
-		mid_mfn_p = p2m_top_mfn_p[topidx];
-		if (mid == p2m_mid_missing) {
-			mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
-
-			p2m_mid_init(mid);
-
-			p2m_top[topidx] = mid;
-
-			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
-		}
-		/* And the save/restore P2M tables.. */
-		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			mid_mfn_p = extend_brk(PAGE_SIZE, PAGE_SIZE);
-			p2m_mid_mfn_init(mid_mfn_p);
-
-			p2m_top_mfn_p[topidx] = mid_mfn_p;
-			p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-			/* Note: we don't set mid_mfn_p[midix] here,
-		 	 * look in __early_alloc_p2m */
-		}
+		WARN_ON(!early_alloc_p2m(pfn));
 	}
 
-	__early_alloc_p2m(pfn_s);
-	__early_alloc_p2m(pfn_e);
+	early_alloc_p2m_middle(pfn_s);
+	early_alloc_p2m_middle(pfn_e);
 
 	for (pfn = pfn_s; pfn < pfn_e; pfn++)
 		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbf-00065U-Sk; Mon, 16 Apr 2012 17:20:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-00062h-Ns
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [193.109.254.147:16398] by server-1.bemta-14.messagelabs.com id
	AC/6C-29372-0F45C8F4; Mon, 16 Apr 2012 17:20:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334596845!4869570!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10446 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKglR025875
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKf8u008808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:41 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKfbY020214; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 84E254032D; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:32 -0400
Message-Id: <1334596539-18172-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090208.4F8C54EB.006C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/8] xen/p2m: Move code around to allow for
	better re-usage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to be using the early_alloc_p2m (and
early_alloc_p2m_middle) code in follow up patches which
are not related to setting identity pages.

Hence lets move the code out in its own function and
rename them as appropiate.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |   62 ++++++++++++++++++++++++++++-----------------------
 1 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 1b267e7..3cc3afe 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -499,7 +499,7 @@ static bool alloc_p2m(unsigned long pfn)
 	return true;
 }
 
-static bool __init __early_alloc_p2m(unsigned long pfn)
+static bool __init early_alloc_p2m_middle(unsigned long pfn)
 {
 	unsigned topidx, mididx, idx;
 
@@ -541,6 +541,36 @@ static bool __init __early_alloc_p2m(unsigned long pfn)
 	}
 	return idx != 0;
 }
+
+static bool __init early_alloc_p2m(unsigned long pfn)
+{
+	unsigned topidx = p2m_top_index(pfn);
+	unsigned long *mid_mfn_p;
+	unsigned long **mid;
+
+	mid = p2m_top[topidx];
+	mid_mfn_p = p2m_top_mfn_p[topidx];
+	if (mid == p2m_mid_missing) {
+		mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+		p2m_mid_init(mid);
+
+		p2m_top[topidx] = mid;
+
+		BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
+	}
+	/* And the save/restore P2M tables.. */
+	if (mid_mfn_p == p2m_mid_missing_mfn) {
+		mid_mfn_p = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		p2m_mid_mfn_init(mid_mfn_p);
+
+		p2m_top_mfn_p[topidx] = mid_mfn_p;
+		p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
+		/* Note: we don't set mid_mfn_p[midix] here,
+		 * look in early_alloc_p2m_middle */
+	}
+	return true;
+}
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
@@ -559,35 +589,11 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 		pfn < ALIGN(pfn_e, (P2M_MID_PER_PAGE * P2M_PER_PAGE));
 		pfn += P2M_MID_PER_PAGE * P2M_PER_PAGE)
 	{
-		unsigned topidx = p2m_top_index(pfn);
-		unsigned long *mid_mfn_p;
-		unsigned long **mid;
-
-		mid = p2m_top[topidx];
-		mid_mfn_p = p2m_top_mfn_p[topidx];
-		if (mid == p2m_mid_missing) {
-			mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
-
-			p2m_mid_init(mid);
-
-			p2m_top[topidx] = mid;
-
-			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
-		}
-		/* And the save/restore P2M tables.. */
-		if (mid_mfn_p == p2m_mid_missing_mfn) {
-			mid_mfn_p = extend_brk(PAGE_SIZE, PAGE_SIZE);
-			p2m_mid_mfn_init(mid_mfn_p);
-
-			p2m_top_mfn_p[topidx] = mid_mfn_p;
-			p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
-			/* Note: we don't set mid_mfn_p[midix] here,
-		 	 * look in __early_alloc_p2m */
-		}
+		WARN_ON(!early_alloc_p2m(pfn));
 	}
 
-	__early_alloc_p2m(pfn_s);
-	__early_alloc_p2m(pfn_e);
+	early_alloc_p2m_middle(pfn_s);
+	early_alloc_p2m_middle(pfn_e);
 
 	for (pfn = pfn_s; pfn < pfn_e; pfn++)
 		if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbg-00065x-HA; Mon, 16 Apr 2012 17:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-00062O-Lm
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.138.51:60247] by server-2.bemta-3.messagelabs.com id
	58/AA-09269-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334596845!22398886!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12339 invoked from network); 16 Apr 2012 17:20:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKhqb025888
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgLS008829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKgKo027788; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C188B4035E; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:38 -0400
Message-Id: <1334596539-18172-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090204.4F8C54EC.000D,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 7/8] xen/setup: Populate freed MFNs from non-RAM
	E820 entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the Xen hypervisor boots a PV kernel it hands it two pieces
of information: nr_pages and a made up E820 entry.

The nr_pages value defines the range from zero to nr_pages of PFNs
which have a valid Machine Frame Number (MFN) underneath it. The
E820 mirrors that (with the VGA hole):
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000000a0000 (usable)
 Xen: 00000000000a0000 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000080800000 (usable)

The fun comes when a PV guest that is run with a machine E820 - that
can either be the initial domain or a PCI PV guest, where the E820
looks like the normal thing:

BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000000009e000 (usable)
 Xen: 000000000009ec00 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000020000000 (usable)
 Xen: 0000000020000000 - 0000000020200000 (reserved)
 Xen: 0000000020200000 - 0000000040000000 (usable)
 Xen: 0000000040000000 - 0000000040200000 (reserved)
 Xen: 0000000040200000 - 00000000bad80000 (usable)
 Xen: 00000000bad80000 - 00000000badc9000 (ACPI NVS)
..
With that overlaying the nr_pages directly on the E820 does not
work as there are gaps and non-RAM regions that won't be used
by the memory allocator. The 'xen_release_chunk' helps with that
by punching holes in the P2M (PFN to MFN lookup tree) for those
regions and tells us that:

Freeing  20000-20200 pfn range: 512 pages freed
Freeing  40000-40200 pfn range: 512 pages freed
Freeing  bad80-badf4 pfn range: 116 pages freed
Freeing  badf6-bae7f pfn range: 137 pages freed
Freeing  bb000-100000 pfn range: 282624 pages freed
Released 283999 pages of unused memory

Those 283999 pages are subtracted from the nr_pages and are returned
to the hypervisor. The end result is that the initial domain
boots with 1GB less memory as the nr_pages has been subtracted by
the amount of pages residing within the PCI hole. It can balloon up
to that if desired using 'xl mem-set 0 8092', but the balloon driver
is not always compiled in for the initial domain.

This patch, implements the populate hypercall (XENMEM_populate_physmap)
which increases the the domain with the same amount of pages that
were released.

The other solution (that did not work) was to transplant the MFN in
the P2M tree - the ones that were going to be freed were put in
the E820_RAM regions past the nr_pages. But the modifications to the
M2P array (the other side of creating PTEs) were not carried away.
As the hypervisor is the only one capable of modifying that and the
only two hypercalls that would do this are: the update_va_mapping
(which won't work, as during initial bootup only PFNs up to nr_pages
are mapped in the guest) or via the populate hypercall.

The end result is that the kernel can now boot with the
nr_pages without having to subtract the 283999 pages.

On a 8GB machine, with various dom0_mem= parameters this is what we get:

no dom0_mem
-Memory: 6485264k/9435136k available (5817k kernel code, 1136060k absent, 1813812k reserved, 2899k data, 696k init)
+Memory: 7619036k/9435136k available (5817k kernel code, 1136060k absent, 680040k reserved, 2899k data, 696k init)

dom0_mem=3G
-Memory: 2616536k/9435136k available (5817k kernel code, 1136060k absent, 5682540k reserved, 2899k data, 696k init)
+Memory: 2703776k/9435136k available (5817k kernel code, 1136060k absent, 5595300k reserved, 2899k data, 696k init)

dom0_mem=max:3G
-Memory: 2696732k/4281724k available (5817k kernel code, 1136060k absent, 448932k reserved, 2899k data, 696k init)
+Memory: 2702204k/4281724k available (5817k kernel code, 1136060k absent, 443460k reserved, 2899k data, 696k init)

And the 'xm list' or 'xl list' now reflect what the dom0_mem=
argument is.

[v2: Use populate hypercall]
[v3: Remove debug printks]
[v4: Simplify code]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |  116 ++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 112 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0e82bf1..b44d409 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -26,7 +26,6 @@
 #include <xen/interface/memory.h>
 #include <xen/interface/physdev.h>
 #include <xen/features.h>
-
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -120,7 +119,105 @@ static unsigned long __init xen_release_chunk(unsigned long start,
 
 	return len;
 }
+static unsigned long __init xen_populate_physmap(unsigned long start,
+						 unsigned long end)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+	unsigned long len = 0;
+	int ret;
+
+	for (pfn = start; pfn < end; pfn++) {
+		unsigned long frame;
+
+		/* Make sure pfn does not exists to start with */
+		if (pfn_to_mfn(pfn) != INVALID_P2M_ENTRY)
+			continue;
 
+		frame = pfn;
+		set_xen_guest_handle(reservation.extent_start, &frame);
+		reservation.nr_extents = 1;
+
+		ret = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
+		WARN(ret != 1, "Failed to populate pfn %lx err=%d\n", pfn, ret);
+		if (ret == 1) {
+			if (!early_set_phys_to_machine(pfn, frame)) {
+				set_xen_guest_handle(reservation.extent_start, &frame);
+				reservation.nr_extents = 1;
+				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
+							&reservation);
+				break;
+			}
+			len++;
+		} else
+			break;
+	}
+	if (len)
+		printk(KERN_INFO "Populated %lx-%lx pfn range: %lu pages added\n",
+		       start, end, len);
+	return len;
+}
+static unsigned long __init xen_populate_chunk(
+	const struct e820entry *list, size_t map_size,
+	unsigned long max_pfn, unsigned long *last_pfn,
+	unsigned long credits_left)
+{
+	const struct e820entry *entry;
+	unsigned int i;
+	unsigned long done = 0;
+	unsigned long dest_pfn;
+
+	for (i = 0, entry = list; i < map_size; i++, entry++) {
+		unsigned long credits = credits_left;
+		unsigned long s_pfn;
+		unsigned long e_pfn;
+		unsigned long pfns;
+		long capacity;
+
+		if (credits <= 0)
+			break;
+
+		if (entry->type != E820_RAM)
+			continue;
+
+		e_pfn = PFN_UP(entry->addr + entry->size);
+
+		/* We only care about E820 after the xen_start_info->nr_pages */
+		if (e_pfn <= max_pfn)
+			continue;
+
+		s_pfn = PFN_DOWN(entry->addr);
+		/* If the E820 falls within the nr_pages, we want to start
+		 * at the nr_pages PFN.
+		 * If that would mean going past the E820 entry, skip it
+		 */
+		if (s_pfn <= max_pfn) {
+			capacity = e_pfn - max_pfn;
+			dest_pfn = max_pfn;
+		} else {
+			/* last_pfn MUST be within E820_RAM regions */
+			if (*last_pfn && e_pfn >= *last_pfn)
+				s_pfn = *last_pfn;
+			capacity = e_pfn - s_pfn;
+			dest_pfn = s_pfn;
+		}
+		/* If we had filled this E820_RAM entry, go to the next one. */
+		if (capacity <= 0)
+			continue;
+
+		if (credits > capacity)
+			credits = capacity;
+
+		pfns = xen_populate_physmap(dest_pfn, dest_pfn + credits);
+		done += pfns;
+		credits_left -= pfns;
+		*last_pfn = (dest_pfn + pfns);
+	}
+	return done;
+}
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -143,7 +240,6 @@ static unsigned long __init xen_set_identity_and_release(
 	 */
 	for (i = 0, entry = list; i < map_size; i++, entry++) {
 		phys_addr_t end = entry->addr + entry->size;
-
 		if (entry->type == E820_RAM || i == map_size - 1) {
 			unsigned long start_pfn = PFN_DOWN(start);
 			unsigned long end_pfn = PFN_UP(end);
@@ -238,7 +334,9 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
+	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
+	unsigned long populated;
 	int i;
 	int op;
 
@@ -278,9 +376,20 @@ char * __init xen_memory_setup(void)
 	 */
 	xen_released_pages = xen_set_identity_and_release(
 		map, memmap.nr_entries, max_pfn);
-	extra_pages += xen_released_pages;
 
 	/*
+	 * Populate back the non-RAM pages and E820 gaps that had been
+	 * released. */
+	populated = xen_populate_chunk(map, memmap.nr_entries,
+			max_pfn, &last_pfn, xen_released_pages);
+
+	extra_pages += (xen_released_pages - populated);
+
+	if (last_pfn > max_pfn) {
+		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
+		mem_end = PFN_PHYS(max_pfn);
+	}
+	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
 	 * size is the full initial memory allocation; on highmem it
@@ -293,7 +402,6 @@ char * __init xen_memory_setup(void)
 	 */
 	extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
 			  extra_pages);
-
 	i = 0;
 	while (i < memmap.nr_entries) {
 		u64 addr = map[i].addr;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbf-00065B-HH; Mon, 16 Apr 2012 17:20:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-00062Q-K9
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.139.83:26040] by server-6.bemta-5.messagelabs.com id
	28/4B-13222-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334596845!24057451!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29753 invoked from network); 16 Apr 2012 17:20:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKhPn025890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfbP001679
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKf3J027771; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A54C14035A; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:35 -0400
Message-Id: <1334596539-18172-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8C54EC.0009,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/8] xen/p2m: An early bootup variant of
	set_phys_to_machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

During early bootup we can't use alloc_page, so to allocate
leaf pages in the P2M we need to use extend_brk. For that
we are utilizing the early_alloc_p2m and early_alloc_p2m_middle
functions to do the job for us. This function follows the
same logic as set_phys_to_machine.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/xen/page.h |    1 +
 arch/x86/xen/p2m.c              |   15 +++++++++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c34f96c..93971e8 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,6 +44,7 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
+extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 952edef..ffd08c4 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -570,6 +570,21 @@ static bool __init early_alloc_p2m(unsigned long pfn)
 	}
 	return true;
 }
+bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+		if (!early_alloc_p2m(pfn))
+			return false;
+
+		if (!early_alloc_p2m_middle(pfn, false /* boundary crossover OK!*/))
+			return false;
+
+		if (!__set_phys_to_machine(pfn, mfn))
+			return false;
+	}
+
+	return true;
+}
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbf-00065B-HH; Mon, 16 Apr 2012 17:20:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-00062Q-K9
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.139.83:26040] by server-6.bemta-5.messagelabs.com id
	28/4B-13222-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334596845!24057451!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29753 invoked from network); 16 Apr 2012 17:20:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKhPn025890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKfbP001679
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKf3J027771; Mon, 16 Apr 2012 12:20:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A54C14035A; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:35 -0400
Message-Id: <1334596539-18172-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8C54EC.0009,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/8] xen/p2m: An early bootup variant of
	set_phys_to_machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

During early bootup we can't use alloc_page, so to allocate
leaf pages in the P2M we need to use extend_brk. For that
we are utilizing the early_alloc_p2m and early_alloc_p2m_middle
functions to do the job for us. This function follows the
same logic as set_phys_to_machine.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/xen/page.h |    1 +
 arch/x86/xen/p2m.c              |   15 +++++++++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c34f96c..93971e8 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,6 +44,7 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
+extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 					     unsigned long pfn_e);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 952edef..ffd08c4 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -570,6 +570,21 @@ static bool __init early_alloc_p2m(unsigned long pfn)
 	}
 	return true;
 }
+bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	if (unlikely(!__set_phys_to_machine(pfn, mfn)))  {
+		if (!early_alloc_p2m(pfn))
+			return false;
+
+		if (!early_alloc_p2m_middle(pfn, false /* boundary crossover OK!*/))
+			return false;
+
+		if (!__set_phys_to_machine(pfn, mfn))
+			return false;
+	}
+
+	return true;
+}
 unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 				      unsigned long pfn_e)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbg-00065x-HA; Mon, 16 Apr 2012 17:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbc-00062O-Lm
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:48 +0000
Received: from [85.158.138.51:60247] by server-2.bemta-3.messagelabs.com id
	58/AA-09269-FE45C8F4; Mon, 16 Apr 2012 17:20:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334596845!22398886!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12339 invoked from network); 16 Apr 2012 17:20:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKhqb025888
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgLS008829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKgKo027788; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C188B4035E; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:38 -0400
Message-Id: <1334596539-18172-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090204.4F8C54EC.000D,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 7/8] xen/setup: Populate freed MFNs from non-RAM
	E820 entries and gaps to E820 RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the Xen hypervisor boots a PV kernel it hands it two pieces
of information: nr_pages and a made up E820 entry.

The nr_pages value defines the range from zero to nr_pages of PFNs
which have a valid Machine Frame Number (MFN) underneath it. The
E820 mirrors that (with the VGA hole):
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000000a0000 (usable)
 Xen: 00000000000a0000 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000080800000 (usable)

The fun comes when a PV guest that is run with a machine E820 - that
can either be the initial domain or a PCI PV guest, where the E820
looks like the normal thing:

BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000000009e000 (usable)
 Xen: 000000000009ec00 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000020000000 (usable)
 Xen: 0000000020000000 - 0000000020200000 (reserved)
 Xen: 0000000020200000 - 0000000040000000 (usable)
 Xen: 0000000040000000 - 0000000040200000 (reserved)
 Xen: 0000000040200000 - 00000000bad80000 (usable)
 Xen: 00000000bad80000 - 00000000badc9000 (ACPI NVS)
..
With that overlaying the nr_pages directly on the E820 does not
work as there are gaps and non-RAM regions that won't be used
by the memory allocator. The 'xen_release_chunk' helps with that
by punching holes in the P2M (PFN to MFN lookup tree) for those
regions and tells us that:

Freeing  20000-20200 pfn range: 512 pages freed
Freeing  40000-40200 pfn range: 512 pages freed
Freeing  bad80-badf4 pfn range: 116 pages freed
Freeing  badf6-bae7f pfn range: 137 pages freed
Freeing  bb000-100000 pfn range: 282624 pages freed
Released 283999 pages of unused memory

Those 283999 pages are subtracted from the nr_pages and are returned
to the hypervisor. The end result is that the initial domain
boots with 1GB less memory as the nr_pages has been subtracted by
the amount of pages residing within the PCI hole. It can balloon up
to that if desired using 'xl mem-set 0 8092', but the balloon driver
is not always compiled in for the initial domain.

This patch, implements the populate hypercall (XENMEM_populate_physmap)
which increases the the domain with the same amount of pages that
were released.

The other solution (that did not work) was to transplant the MFN in
the P2M tree - the ones that were going to be freed were put in
the E820_RAM regions past the nr_pages. But the modifications to the
M2P array (the other side of creating PTEs) were not carried away.
As the hypervisor is the only one capable of modifying that and the
only two hypercalls that would do this are: the update_va_mapping
(which won't work, as during initial bootup only PFNs up to nr_pages
are mapped in the guest) or via the populate hypercall.

The end result is that the kernel can now boot with the
nr_pages without having to subtract the 283999 pages.

On a 8GB machine, with various dom0_mem= parameters this is what we get:

no dom0_mem
-Memory: 6485264k/9435136k available (5817k kernel code, 1136060k absent, 1813812k reserved, 2899k data, 696k init)
+Memory: 7619036k/9435136k available (5817k kernel code, 1136060k absent, 680040k reserved, 2899k data, 696k init)

dom0_mem=3G
-Memory: 2616536k/9435136k available (5817k kernel code, 1136060k absent, 5682540k reserved, 2899k data, 696k init)
+Memory: 2703776k/9435136k available (5817k kernel code, 1136060k absent, 5595300k reserved, 2899k data, 696k init)

dom0_mem=max:3G
-Memory: 2696732k/4281724k available (5817k kernel code, 1136060k absent, 448932k reserved, 2899k data, 696k init)
+Memory: 2702204k/4281724k available (5817k kernel code, 1136060k absent, 443460k reserved, 2899k data, 696k init)

And the 'xm list' or 'xl list' now reflect what the dom0_mem=
argument is.

[v2: Use populate hypercall]
[v3: Remove debug printks]
[v4: Simplify code]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |  116 ++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 112 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0e82bf1..b44d409 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -26,7 +26,6 @@
 #include <xen/interface/memory.h>
 #include <xen/interface/physdev.h>
 #include <xen/features.h>
-
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -120,7 +119,105 @@ static unsigned long __init xen_release_chunk(unsigned long start,
 
 	return len;
 }
+static unsigned long __init xen_populate_physmap(unsigned long start,
+						 unsigned long end)
+{
+	struct xen_memory_reservation reservation = {
+		.address_bits = 0,
+		.extent_order = 0,
+		.domid        = DOMID_SELF
+	};
+	unsigned long len = 0;
+	int ret;
+
+	for (pfn = start; pfn < end; pfn++) {
+		unsigned long frame;
+
+		/* Make sure pfn does not exists to start with */
+		if (pfn_to_mfn(pfn) != INVALID_P2M_ENTRY)
+			continue;
 
+		frame = pfn;
+		set_xen_guest_handle(reservation.extent_start, &frame);
+		reservation.nr_extents = 1;
+
+		ret = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
+		WARN(ret != 1, "Failed to populate pfn %lx err=%d\n", pfn, ret);
+		if (ret == 1) {
+			if (!early_set_phys_to_machine(pfn, frame)) {
+				set_xen_guest_handle(reservation.extent_start, &frame);
+				reservation.nr_extents = 1;
+				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
+							&reservation);
+				break;
+			}
+			len++;
+		} else
+			break;
+	}
+	if (len)
+		printk(KERN_INFO "Populated %lx-%lx pfn range: %lu pages added\n",
+		       start, end, len);
+	return len;
+}
+static unsigned long __init xen_populate_chunk(
+	const struct e820entry *list, size_t map_size,
+	unsigned long max_pfn, unsigned long *last_pfn,
+	unsigned long credits_left)
+{
+	const struct e820entry *entry;
+	unsigned int i;
+	unsigned long done = 0;
+	unsigned long dest_pfn;
+
+	for (i = 0, entry = list; i < map_size; i++, entry++) {
+		unsigned long credits = credits_left;
+		unsigned long s_pfn;
+		unsigned long e_pfn;
+		unsigned long pfns;
+		long capacity;
+
+		if (credits <= 0)
+			break;
+
+		if (entry->type != E820_RAM)
+			continue;
+
+		e_pfn = PFN_UP(entry->addr + entry->size);
+
+		/* We only care about E820 after the xen_start_info->nr_pages */
+		if (e_pfn <= max_pfn)
+			continue;
+
+		s_pfn = PFN_DOWN(entry->addr);
+		/* If the E820 falls within the nr_pages, we want to start
+		 * at the nr_pages PFN.
+		 * If that would mean going past the E820 entry, skip it
+		 */
+		if (s_pfn <= max_pfn) {
+			capacity = e_pfn - max_pfn;
+			dest_pfn = max_pfn;
+		} else {
+			/* last_pfn MUST be within E820_RAM regions */
+			if (*last_pfn && e_pfn >= *last_pfn)
+				s_pfn = *last_pfn;
+			capacity = e_pfn - s_pfn;
+			dest_pfn = s_pfn;
+		}
+		/* If we had filled this E820_RAM entry, go to the next one. */
+		if (capacity <= 0)
+			continue;
+
+		if (credits > capacity)
+			credits = capacity;
+
+		pfns = xen_populate_physmap(dest_pfn, dest_pfn + credits);
+		done += pfns;
+		credits_left -= pfns;
+		*last_pfn = (dest_pfn + pfns);
+	}
+	return done;
+}
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -143,7 +240,6 @@ static unsigned long __init xen_set_identity_and_release(
 	 */
 	for (i = 0, entry = list; i < map_size; i++, entry++) {
 		phys_addr_t end = entry->addr + entry->size;
-
 		if (entry->type == E820_RAM || i == map_size - 1) {
 			unsigned long start_pfn = PFN_DOWN(start);
 			unsigned long end_pfn = PFN_UP(end);
@@ -238,7 +334,9 @@ char * __init xen_memory_setup(void)
 	int rc;
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
+	unsigned long last_pfn = 0;
 	unsigned long extra_pages = 0;
+	unsigned long populated;
 	int i;
 	int op;
 
@@ -278,9 +376,20 @@ char * __init xen_memory_setup(void)
 	 */
 	xen_released_pages = xen_set_identity_and_release(
 		map, memmap.nr_entries, max_pfn);
-	extra_pages += xen_released_pages;
 
 	/*
+	 * Populate back the non-RAM pages and E820 gaps that had been
+	 * released. */
+	populated = xen_populate_chunk(map, memmap.nr_entries,
+			max_pfn, &last_pfn, xen_released_pages);
+
+	extra_pages += (xen_released_pages - populated);
+
+	if (last_pfn > max_pfn) {
+		max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
+		mem_end = PFN_PHYS(max_pfn);
+	}
+	/*
 	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
 	 * factor the base size.  On non-highmem systems, the base
 	 * size is the full initial memory allocation; on highmem it
@@ -293,7 +402,6 @@ char * __init xen_memory_setup(void)
 	 */
 	extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
 			  extra_pages);
-
 	i = 0;
 	while (i < memmap.nr_entries) {
 		u64 addr = map[i].addr;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbh-00067i-Nn; Mon, 16 Apr 2012 17:20:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbd-00062h-Hv
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:49 +0000
Received: from [193.109.254.147:31720] by server-1.bemta-14.messagelabs.com id
	BE/6C-29372-1F45C8F4; Mon, 16 Apr 2012 17:20:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334596845!4869571!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10457 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKhjq011144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgLV001694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKgut020231; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CB4FA40364; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:39 -0400
Message-Id: <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8C54EC.0033,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 8/8] xen/setup: Combine the two hypercall
	functions - since they are quite similar.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

They use the same set of arguments, so it is just the matter
of using the proper hypercall.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   81 ++++++++++++++++++-------------------------------
 1 files changed, 30 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index b44d409..506a3e6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -83,8 +83,8 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 }
 
-static unsigned long __init xen_release_chunk(unsigned long start,
-					      unsigned long end)
+static unsigned long __init xen_do_chunk(unsigned long start,
+					 unsigned long end, bool release)
 {
 	struct xen_memory_reservation reservation = {
 		.address_bits = 0,
@@ -95,60 +95,36 @@ static unsigned long __init xen_release_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
-	for(pfn = start; pfn < end; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		/* Make sure pfn exists to start with */
-		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-			continue;
-
-		set_xen_guest_handle(reservation.extent_start, &mfn);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-					   &reservation);
-		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
-		if (ret == 1) {
-			__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
-			len++;
-		}
-	}
-	if (len)
-		printk(KERN_INFO "Freeing  %lx-%lx pfn range: %lu pages freed\n",
-		       start, end, len);
-
-	return len;
-}
-static unsigned long __init xen_populate_physmap(unsigned long start,
-						 unsigned long end)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	int ret;
-
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
+		unsigned long mfn = pfn_to_mfn(pfn);
 
-		/* Make sure pfn does not exists to start with */
-		if (pfn_to_mfn(pfn) != INVALID_P2M_ENTRY)
-			continue;
-
-		frame = pfn;
+		if (release) {
+			/* Make sure pfn exists to start with */
+			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+				continue;
+			frame = mfn;
+		} else {
+			if (mfn != INVALID_P2M_ENTRY)
+				continue;
+			frame = pfn;
+		}
 		set_xen_guest_handle(reservation.extent_start, &frame);
 		reservation.nr_extents = 1;
 
-		ret = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
-		WARN(ret != 1, "Failed to populate pfn %lx err=%d\n", pfn, ret);
+		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
+					   &reservation);
+		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
+		     release ? "release" : "populate", pfn, ret);
+
 		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, frame)) {
+			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
+				if (release)
+					break;
 				set_xen_guest_handle(reservation.extent_start, &frame);
 				reservation.nr_extents = 1;
 				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							&reservation);
+							   &reservation);
 				break;
 			}
 			len++;
@@ -156,8 +132,11 @@ static unsigned long __init xen_populate_physmap(unsigned long start,
 			break;
 	}
 	if (len)
-		printk(KERN_INFO "Populated %lx-%lx pfn range: %lu pages added\n",
-		       start, end, len);
+		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
+		       release ? "Freeing" : "Populating",
+		       start, end, len,
+		       release ? "freed" : "added");
+
 	return len;
 }
 static unsigned long __init xen_populate_chunk(
@@ -211,7 +190,7 @@ static unsigned long __init xen_populate_chunk(
 		if (credits > capacity)
 			credits = capacity;
 
-		pfns = xen_populate_physmap(dest_pfn, dest_pfn + credits);
+		pfns = xen_do_chunk(dest_pfn, dest_pfn + credits, false);
 		done += pfns;
 		credits_left -= pfns;
 		*last_pfn = (dest_pfn + pfns);
@@ -249,8 +228,8 @@ static unsigned long __init xen_set_identity_and_release(
 
 			if (start_pfn < end_pfn) {
 				if (start_pfn < nr_pages)
-					released += xen_release_chunk(
-						start_pfn, min(end_pfn, nr_pages));
+					released += xen_do_chunk(
+						start_pfn, min(end_pfn, nr_pages), true);
 
 				identity += set_phys_range_identity(
 					start_pfn, end_pfn);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbh-00067i-Nn; Mon, 16 Apr 2012 17:20:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbd-00062h-Hv
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:49 +0000
Received: from [193.109.254.147:31720] by server-1.bemta-14.messagelabs.com id
	BE/6C-29372-1F45C8F4; Mon, 16 Apr 2012 17:20:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334596845!4869571!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10457 invoked from network); 16 Apr 2012 17:20:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKhjq011144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgLV001694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKgut020231; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CB4FA40364; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:39 -0400
Message-Id: <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8C54EC.0033,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 8/8] xen/setup: Combine the two hypercall
	functions - since they are quite similar.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

They use the same set of arguments, so it is just the matter
of using the proper hypercall.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   81 ++++++++++++++++++-------------------------------
 1 files changed, 30 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index b44d409..506a3e6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -83,8 +83,8 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 }
 
-static unsigned long __init xen_release_chunk(unsigned long start,
-					      unsigned long end)
+static unsigned long __init xen_do_chunk(unsigned long start,
+					 unsigned long end, bool release)
 {
 	struct xen_memory_reservation reservation = {
 		.address_bits = 0,
@@ -95,60 +95,36 @@ static unsigned long __init xen_release_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
-	for(pfn = start; pfn < end; pfn++) {
-		unsigned long mfn = pfn_to_mfn(pfn);
-
-		/* Make sure pfn exists to start with */
-		if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
-			continue;
-
-		set_xen_guest_handle(reservation.extent_start, &mfn);
-		reservation.nr_extents = 1;
-
-		ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-					   &reservation);
-		WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret);
-		if (ret == 1) {
-			__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
-			len++;
-		}
-	}
-	if (len)
-		printk(KERN_INFO "Freeing  %lx-%lx pfn range: %lu pages freed\n",
-		       start, end, len);
-
-	return len;
-}
-static unsigned long __init xen_populate_physmap(unsigned long start,
-						 unsigned long end)
-{
-	struct xen_memory_reservation reservation = {
-		.address_bits = 0,
-		.extent_order = 0,
-		.domid        = DOMID_SELF
-	};
-	unsigned long len = 0;
-	int ret;
-
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
+		unsigned long mfn = pfn_to_mfn(pfn);
 
-		/* Make sure pfn does not exists to start with */
-		if (pfn_to_mfn(pfn) != INVALID_P2M_ENTRY)
-			continue;
-
-		frame = pfn;
+		if (release) {
+			/* Make sure pfn exists to start with */
+			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+				continue;
+			frame = mfn;
+		} else {
+			if (mfn != INVALID_P2M_ENTRY)
+				continue;
+			frame = pfn;
+		}
 		set_xen_guest_handle(reservation.extent_start, &frame);
 		reservation.nr_extents = 1;
 
-		ret = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
-		WARN(ret != 1, "Failed to populate pfn %lx err=%d\n", pfn, ret);
+		ret = HYPERVISOR_memory_op(release ? XENMEM_decrease_reservation : XENMEM_populate_physmap,
+					   &reservation);
+		WARN(ret != 1, "Failed to %s pfn %lx err=%d\n",
+		     release ? "release" : "populate", pfn, ret);
+
 		if (ret == 1) {
-			if (!early_set_phys_to_machine(pfn, frame)) {
+			if (!early_set_phys_to_machine(pfn, release ? INVALID_P2M_ENTRY : frame)) {
+				if (release)
+					break;
 				set_xen_guest_handle(reservation.extent_start, &frame);
 				reservation.nr_extents = 1;
 				ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
-							&reservation);
+							   &reservation);
 				break;
 			}
 			len++;
@@ -156,8 +132,11 @@ static unsigned long __init xen_populate_physmap(unsigned long start,
 			break;
 	}
 	if (len)
-		printk(KERN_INFO "Populated %lx-%lx pfn range: %lu pages added\n",
-		       start, end, len);
+		printk(KERN_INFO "%s %lx-%lx pfn range: %lu pages %s\n",
+		       release ? "Freeing" : "Populating",
+		       start, end, len,
+		       release ? "freed" : "added");
+
 	return len;
 }
 static unsigned long __init xen_populate_chunk(
@@ -211,7 +190,7 @@ static unsigned long __init xen_populate_chunk(
 		if (credits > capacity)
 			credits = capacity;
 
-		pfns = xen_populate_physmap(dest_pfn, dest_pfn + credits);
+		pfns = xen_do_chunk(dest_pfn, dest_pfn + credits, false);
 		done += pfns;
 		credits_left -= pfns;
 		*last_pfn = (dest_pfn + pfns);
@@ -249,8 +228,8 @@ static unsigned long __init xen_set_identity_and_release(
 
 			if (start_pfn < end_pfn) {
 				if (start_pfn < nr_pages)
-					released += xen_release_chunk(
-						start_pfn, min(end_pfn, nr_pages));
+					released += xen_do_chunk(
+						start_pfn, min(end_pfn, nr_pages), true);
 
 				identity += set_phys_range_identity(
 					start_pfn, end_pfn);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbi-00068j-B3; Mon, 16 Apr 2012 17:20:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbe-00061V-LI
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:50 +0000
Received: from [85.158.143.99:64777] by server-2.bemta-4.messagelabs.com id
	52/4D-17550-2F45C8F4; Mon, 16 Apr 2012 17:20:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334596845!18609226!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14071 invoked from network); 16 Apr 2012 17:20:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKgGl025886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgcT011678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKgZf018208; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AE3164035B; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:36 -0400
Message-Id: <1334596539-18172-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090208.4F8C54EB.00A0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/8] xen/setup: Only print "Freeing XXX-YYY pfn
	range: Z pages freed" if Z > 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Otherwise we can get these meaningless:
Freeing  bad80-badf4 pfn range: 0 pages freed

We also can do this for the summary ones - no point of printing
"Set 0 page(s) to 1-1 mapping"

[v1: Extended to the summary printks]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 1ba8dff..7b0ab77 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -114,8 +114,9 @@ static unsigned long __init xen_release_chunk(unsigned long start,
 			len++;
 		}
 	}
-	printk(KERN_INFO "Freeing  %lx-%lx pfn range: %lu pages freed\n",
-	       start, end, len);
+	if (len)
+		printk(KERN_INFO "Freeing  %lx-%lx pfn range: %lu pages freed\n",
+		       start, end, len);
 
 	return len;
 }
@@ -162,8 +163,10 @@ static unsigned long __init xen_set_identity_and_release(
 		}
 	}
 
-	printk(KERN_INFO "Released %lu pages of unused memory\n", released);
-	printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity);
+	if (released)
+		printk(KERN_INFO "Released %lu pages of unused memory\n", released);
+	if (identity)
+		printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity);
 
 	return released;
 }
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:20:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpbi-00068j-B3; Mon, 16 Apr 2012 17:20:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpbe-00061V-LI
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 17:20:50 +0000
Received: from [85.158.143.99:64777] by server-2.bemta-4.messagelabs.com id
	52/4D-17550-2F45C8F4; Mon, 16 Apr 2012 17:20:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334596845!18609226!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14071 invoked from network); 16 Apr 2012 17:20:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:20:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHKgGl025886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:20:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHKgcT011678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:20:42 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHKgZf018208; Mon, 16 Apr 2012 12:20:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:20:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AE3164035B; Mon, 16 Apr 2012 13:15:43 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com
Date: Mon, 16 Apr 2012 13:15:36 -0400
Message-Id: <1334596539-18172-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090208.4F8C54EB.00A0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/8] xen/setup: Only print "Freeing XXX-YYY pfn
	range: Z pages freed" if Z > 0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Otherwise we can get these meaningless:
Freeing  bad80-badf4 pfn range: 0 pages freed

We also can do this for the summary ones - no point of printing
"Set 0 page(s) to 1-1 mapping"

[v1: Extended to the summary printks]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 1ba8dff..7b0ab77 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -114,8 +114,9 @@ static unsigned long __init xen_release_chunk(unsigned long start,
 			len++;
 		}
 	}
-	printk(KERN_INFO "Freeing  %lx-%lx pfn range: %lu pages freed\n",
-	       start, end, len);
+	if (len)
+		printk(KERN_INFO "Freeing  %lx-%lx pfn range: %lu pages freed\n",
+		       start, end, len);
 
 	return len;
 }
@@ -162,8 +163,10 @@ static unsigned long __init xen_set_identity_and_release(
 		}
 	}
 
-	printk(KERN_INFO "Released %lu pages of unused memory\n", released);
-	printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity);
+	if (released)
+		printk(KERN_INFO "Released %lu pages of unused memory\n", released);
+	if (identity)
+		printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity);
 
 	return released;
 }
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpdK-0007fQ-KA; Mon, 16 Apr 2012 17:22:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJpdI-0007du-Na
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:22:32 +0000
Received: from [85.158.143.35:21622] by server-3.bemta-4.messagelabs.com id
	A4/2C-05853-8555C8F4; Mon, 16 Apr 2012 17:22:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334596949!11248585!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18149 invoked from network); 16 Apr 2012 17:22:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:22:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHMIVr013195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:22:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHMHaS013803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:22:17 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHMGsF029011; Mon, 16 Apr 2012 12:22:17 -0500
MIME-Version: 1.0
Message-ID: <84023b26-a682-44b5-990e-1635da6949ff@default>
Date: Mon, 16 Apr 2012 10:22:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C619C020000780007E34E@nat28.tlf.novell.com>
In-Reply-To: <4F8C619C020000780007E34E@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F8C554B.0120,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> >>> On 16.04.12 at 18:05, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> On 16/04/12 12:32, Jan Beulich wrote:
> >> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> >> --- a/arch/x86/xen/time.c
> >> >> +++ b/arch/x86/xen/time.c
> >> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> >> >>  	do_settimeofday(&tp);
> >> >>
> >> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> >> >> +	sched_clock_stable = 0;
> >> >
> >> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> >> > post-boot, the variable may need to be cleared again. Instead you
> >> > ought to call mark_tsc_unstable().
> >>
> >> Yeah, mark_tsc_unstable() is the right thing to do.
> >
> > NACK!
> >
> > No, no, no.  The exact opposite is true.  Like VMware, TSC is
> > stable.  The issue is that Linux trusts other clock hardware more
> > completely than TSC so whenever there is a problem with another
> > clocksource, Linux blames TSC and marks TSC unstable.  But TSC
> > on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
> > choice than clocksource=xen (aka pvclock) because pvclock
> > indirectly depends on TSC.
> >
> > For upstream kernels, the answer is to set clocksource=tsc
> > and tsc=reliable, like VMware enforces. See:
> >
> > https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html
> >
> > In fact, it might be wise for a Xen-savvy kernel to check to see
> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > and tsc=reliable.
> 
> Are you possibly mixing up PV and HVM cases? sched_clock_stable
> getting set _is_ a problem in PV kernels - we had bug reports long
> ago when this first appeared in arch/x86/kernel/cpu/intel.c. I'm
> suspecting this because there's not supposed to be (and in non-
> pv-ops there is no; in pv-ops I assume it simply has no effect)
> clocksource=tsc in PV kernels.

Hi Jan --

In upstream (and recent pv-ops) kernels, is there any need for there
to be a difference between HVM and PV in the clocksource chosen?  The
pvclock algorithm was necessary for PV when non-TSC hardware clocks
were privileged and the only non-privileged hardware clock (TSC)
was badly broken in hardware and for migration/save/restore.
With TSC now working and stable, and now that we are making changes
in the upstream kernel that work for both PV and HVM, is it
time to drop pvclock (at least as the default for PV)?

Certainly if an old (non-pv-ops) kernel is broken, something like
David's patch might be an acceptable workaround.  I'm just arguing
against perpetuating pvclock-as-the-only-xen-clock upstream.

Does that make sense?
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpdK-0007fQ-KA; Mon, 16 Apr 2012 17:22:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJpdI-0007du-Na
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:22:32 +0000
Received: from [85.158.143.35:21622] by server-3.bemta-4.messagelabs.com id
	A4/2C-05853-8555C8F4; Mon, 16 Apr 2012 17:22:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334596949!11248585!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18149 invoked from network); 16 Apr 2012 17:22:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:22:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHMIVr013195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:22:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHMHaS013803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:22:17 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHMGsF029011; Mon, 16 Apr 2012 12:22:17 -0500
MIME-Version: 1.0
Message-ID: <84023b26-a682-44b5-990e-1635da6949ff@default>
Date: Mon, 16 Apr 2012 10:22:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C619C020000780007E34E@nat28.tlf.novell.com>
In-Reply-To: <4F8C619C020000780007E34E@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F8C554B.0120,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> >>> On 16.04.12 at 18:05, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> On 16/04/12 12:32, Jan Beulich wrote:
> >> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> >> >> --- a/arch/x86/xen/time.c
> >> >> +++ b/arch/x86/xen/time.c
> >> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
> >> >>  	do_settimeofday(&tp);
> >> >>
> >> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
> >> >> +	sched_clock_stable = 0;
> >> >
> >> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
> >> > post-boot, the variable may need to be cleared again. Instead you
> >> > ought to call mark_tsc_unstable().
> >>
> >> Yeah, mark_tsc_unstable() is the right thing to do.
> >
> > NACK!
> >
> > No, no, no.  The exact opposite is true.  Like VMware, TSC is
> > stable.  The issue is that Linux trusts other clock hardware more
> > completely than TSC so whenever there is a problem with another
> > clocksource, Linux blames TSC and marks TSC unstable.  But TSC
> > on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
> > choice than clocksource=xen (aka pvclock) because pvclock
> > indirectly depends on TSC.
> >
> > For upstream kernels, the answer is to set clocksource=tsc
> > and tsc=reliable, like VMware enforces. See:
> >
> > https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html
> >
> > In fact, it might be wise for a Xen-savvy kernel to check to see
> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > and tsc=reliable.
> 
> Are you possibly mixing up PV and HVM cases? sched_clock_stable
> getting set _is_ a problem in PV kernels - we had bug reports long
> ago when this first appeared in arch/x86/kernel/cpu/intel.c. I'm
> suspecting this because there's not supposed to be (and in non-
> pv-ops there is no; in pv-ops I assume it simply has no effect)
> clocksource=tsc in PV kernels.

Hi Jan --

In upstream (and recent pv-ops) kernels, is there any need for there
to be a difference between HVM and PV in the clocksource chosen?  The
pvclock algorithm was necessary for PV when non-TSC hardware clocks
were privileged and the only non-privileged hardware clock (TSC)
was badly broken in hardware and for migration/save/restore.
With TSC now working and stable, and now that we are making changes
in the upstream kernel that work for both PV and HVM, is it
time to drop pvclock (at least as the default for PV)?

Certainly if an old (non-pv-ops) kernel is broken, something like
David's patch might be an acceptable workaround.  I'm just arguing
against perpetuating pvclock-as-the-only-xen-clock upstream.

Does that make sense?
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJplT-0000Js-L7; Mon, 16 Apr 2012 17:30:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJplS-0000Jn-5r
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:30:58 +0000
Received: from [193.109.254.147:52268] by server-3.bemta-14.messagelabs.com id
	88/7C-23274-1575C8F4; Mon, 16 Apr 2012 17:30:57 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334597455!2375838!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24863 invoked from network); 16 Apr 2012 17:30:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:30:56 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHUj35023993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:30:46 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHUiJA017048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:30:44 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHUh3v027504; Mon, 16 Apr 2012 12:30:43 -0500
MIME-Version: 1.0
Message-ID: <8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
Date: Mon, 16 Apr 2012 10:30:35 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C4818.8070603@citrix.com>
In-Reply-To: <4F8C4818.8070603@citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F8C5747.0023,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: David Vrabel [mailto:david.vrabel@citrix.com]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> On 16/04/12 17:05, Dan Magenheimer wrote:
> >> From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> >
> > Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> Fair enough,
> 
> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
> 
> The original customer problem is on a host with Xen 3.4.  What do you
> recommend for Linux guests running such hosts?

For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
back-patch the guest kernel with a workaround such as your patch, great!
I'm only arguing against the patch getting perpetuated upstream.
 
> > In fact, it might be wise for a Xen-savvy kernel to check to see
> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > and tsc=reliable.
> 
> So, should the xen clocksource do:
> 
> if Xen 4.0+
>     clock is stable, use rdtsc only.
> else
>     clock is unstable, use existing pvclock implementation.

Yes, that's what I propose.  To clarify:

if the guest can and does determine it is running on Xen 4.0+
	TSC is guaranteed by Xen to be stable, use clocksource=tsc tsc=reliable
else
	Xen only guarantees that pvclock is stable, use pvclock

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJplT-0000Js-L7; Mon, 16 Apr 2012 17:30:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJplS-0000Jn-5r
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:30:58 +0000
Received: from [193.109.254.147:52268] by server-3.bemta-14.messagelabs.com id
	88/7C-23274-1575C8F4; Mon, 16 Apr 2012 17:30:57 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334597455!2375838!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24863 invoked from network); 16 Apr 2012 17:30:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 17:30:56 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHUj35023993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:30:46 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHUiJA017048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:30:44 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHUh3v027504; Mon, 16 Apr 2012 12:30:43 -0500
MIME-Version: 1.0
Message-ID: <8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
Date: Mon, 16 Apr 2012 10:30:35 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C4818.8070603@citrix.com>
In-Reply-To: <4F8C4818.8070603@citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F8C5747.0023,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: David Vrabel [mailto:david.vrabel@citrix.com]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> On 16/04/12 17:05, Dan Magenheimer wrote:
> >> From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> >
> > Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> Fair enough,
> 
> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
> 
> The original customer problem is on a host with Xen 3.4.  What do you
> recommend for Linux guests running such hosts?

For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
back-patch the guest kernel with a workaround such as your patch, great!
I'm only arguing against the patch getting perpetuated upstream.
 
> > In fact, it might be wise for a Xen-savvy kernel to check to see
> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > and tsc=reliable.
> 
> So, should the xen clocksource do:
> 
> if Xen 4.0+
>     clock is stable, use rdtsc only.
> else
>     clock is unstable, use existing pvclock implementation.

Yes, that's what I propose.  To clarify:

if the guest can and does determine it is running on Xen 4.0+
	TSC is guaranteed by Xen to be stable, use clocksource=tsc tsc=reliable
else
	Xen only guarantees that pvclock is stable, use pvclock

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:45:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpzX-0000cj-PX; Mon, 16 Apr 2012 17:45:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpzW-0000ce-75
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:45:30 +0000
Received: from [85.158.143.99:34654] by server-2.bemta-4.messagelabs.com id
	0C/DE-17550-9BA5C8F4; Mon, 16 Apr 2012 17:45:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334598327!23345656!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 16 Apr 2012 17:45:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 17:45:28 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHiaSM018193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:44:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHiYrE018308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:44:35 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHiY5B012465; Mon, 16 Apr 2012 12:44:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:44:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B103940280; Mon, 16 Apr 2012 13:39:36 -0400 (EDT)
Date: Mon, 16 Apr 2012 13:39:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>, wei.wang2@amd.com
Message-ID: <20120416173936.GD18314@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<20120411134648.GB21703@andromeda.dapyr.net>
	<1334154629.3943.4.camel@hp6530s>
	<CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F8C5A86.002B,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, wei.huang2@amd.com,
	marcus.granado@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 04:16:07PM +0800, Lin Ming wrote:
> On Wed, Apr 11, 2012 at 10:30 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> 
> [....]
> 
> >> That isn't actually true. If you run it, you will see it working
> >> in the guest - it just that it does not use the performence counters
> >> but instead uses the timer to sample data.
> >
> > Right, I mean "hardware event" does not work.
> >
> > Hardware event, for example, perf top -e cycles, does not work.
> 
> Just found that vpmu is disabled by default.
> You need to pass xen boot parameter "vpmu" to make hardware event work.

Oh, I wonder why it was disabled by default? Wei, would you know
by any chance?

> 
> > Software event, for example, perf top -e cpu-clock, works.
> 
> So both hardware and software event work in DomU.
> Great!

Excellent!
> 
> >
> >>
> >> > Run "perf top", but no data was collected.
> >>
> >> Hm, I am able to collect data using Fedora Core 16 PV guest.
> >> For dom0 or domU? For dom0 there is a bug somewhere where
> >
> > For domU HVM guest.
> > I have problem to run domU PV guest. Still looking at it.
> >
> >> the machine crashes after 30 seconds or so - hadn't actually
> >> gotten to the bottom of it. There was an email thread:
> >> https://lkml.org/lkml/2012/2/12/74 about this.
> >>
> >> Patches are most welcome!
> 
> Here are the patches.
> https://lkml.org/lkml/2012/4/15/12

Let me play with them a bit. At first glance they look ok - but I recall
Peter Z saying something about not implementing the IRQ WORKER, but I can't
recall the reasons.
> 
> Regards,
> Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:45:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJpzX-0000cj-PX; Mon, 16 Apr 2012 17:45:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJpzW-0000ce-75
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:45:30 +0000
Received: from [85.158.143.99:34654] by server-2.bemta-4.messagelabs.com id
	0C/DE-17550-9BA5C8F4; Mon, 16 Apr 2012 17:45:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334598327!23345656!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 16 Apr 2012 17:45:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 17:45:28 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHiaSM018193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:44:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHiYrE018308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:44:35 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHiY5B012465; Mon, 16 Apr 2012 12:44:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 10:44:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B103940280; Mon, 16 Apr 2012 13:39:36 -0400 (EDT)
Date: Mon, 16 Apr 2012 13:39:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>, wei.wang2@amd.com
Message-ID: <20120416173936.GD18314@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<4F7F1D14.9040208@amd.com>
	<CAF1ivSZfGmeNbNt-wfArRDFB=_OQPJV15BpXw9ZeXa2=+SbiAQ@mail.gmail.com>
	<20120411134648.GB21703@andromeda.dapyr.net>
	<1334154629.3943.4.camel@hp6530s>
	<CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F8C5A86.002B,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, wei.huang2@amd.com,
	marcus.granado@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 04:16:07PM +0800, Lin Ming wrote:
> On Wed, Apr 11, 2012 at 10:30 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> 
> [....]
> 
> >> That isn't actually true. If you run it, you will see it working
> >> in the guest - it just that it does not use the performence counters
> >> but instead uses the timer to sample data.
> >
> > Right, I mean "hardware event" does not work.
> >
> > Hardware event, for example, perf top -e cycles, does not work.
> 
> Just found that vpmu is disabled by default.
> You need to pass xen boot parameter "vpmu" to make hardware event work.

Oh, I wonder why it was disabled by default? Wei, would you know
by any chance?

> 
> > Software event, for example, perf top -e cpu-clock, works.
> 
> So both hardware and software event work in DomU.
> Great!

Excellent!
> 
> >
> >>
> >> > Run "perf top", but no data was collected.
> >>
> >> Hm, I am able to collect data using Fedora Core 16 PV guest.
> >> For dom0 or domU? For dom0 there is a bug somewhere where
> >
> > For domU HVM guest.
> > I have problem to run domU PV guest. Still looking at it.
> >
> >> the machine crashes after 30 seconds or so - hadn't actually
> >> gotten to the bottom of it. There was an email thread:
> >> https://lkml.org/lkml/2012/2/12/74 about this.
> >>
> >> Patches are most welcome!
> 
> Here are the patches.
> https://lkml.org/lkml/2012/4/15/12

Let me play with them a bit. At first glance they look ok - but I recall
Peter Z saying something about not implementing the IRQ WORKER, but I can't
recall the reasons.
> 
> Regards,
> Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:53:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJq70-00012x-BY; Mon, 16 Apr 2012 17:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJq6z-00012l-0J
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:53:13 +0000
Received: from [85.158.138.51:35848] by server-11.bemta-3.messagelabs.com id
	57/1A-18894-88C5C8F4; Mon, 16 Apr 2012 17:53:12 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334598789!22204595!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31938 invoked from network); 16 Apr 2012 17:53:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 17:53:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHqx39019805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:53:00 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHqvSr020574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:52:58 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHquBl018531; Mon, 16 Apr 2012 12:52:56 -0500
MIME-Version: 1.0
Message-ID: <3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
Date: Mon, 16 Apr 2012 10:52:48 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Tim Deegan <tim@xen.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
In-Reply-To: <20120416170827.GE13111@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F8C5C7D.0010,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> > Hmmm... I spent a great deal of time on TSC support in the hypervisor
> > 2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
> > everything on HVM as well.  There's most likely a bug or two still lurking
> > but, for all guests, with the default tsc_mode, TSC is provided by Xen
> > as an absolutely stable clock source.  If Xen determines that the underlying
> > hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
> > If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
> > save/restore, TSC is always emulated.  The result is (ignoring possible
> > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
> > CPUs; and c) constant rate.  Even across migration/save/restore.
> 
> AIUI, this thread is about the PV-time clock source, not about the TSC
> itself.  Even if the TSC is emulated (or in some other way made
> "stable") the PV wallclock is not necessarily stable across migration.
> But since migration is controlled by the kernel, presumably the kernel
> can DTRT about it.

Under what circumstances is PV wallclock not stable across migration?

> > In fact, it might be wise for a Xen-savvy kernel to check to see
> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > and tsc=reliable.
> 
> That seems like overdoing it.  Certainly it's not OK unless it can also
> check that Xen is providing a stable TSC (i.e. that tscmode==1).

Xen guarantees a stable TSC for the default (tsc_mode==0) also.

If the vm.cfg file explicitly sets a guest tsc_mode==2, you are correct
that pvclock is still necessary.  But as the documentation says:
tsc_mode==2 should be set if "it is certain that all apps running in this
VM are TSC-resilient and highest performance is required".  In
the case we are talking about, the PV guest kernel itself isn't TSC-
resilient!

In any case, IIRC, there is a pvcpuid instruction to determine the
tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
also check to ensure the tsc_mode wasn't overridden and set to 2.
If it is set to 2, TSC should not be an available clocksource,
as the guest kernel would break on migration/save/restore.

> In the case where the PV clock has been selected, can it not be marked
> unstable without also marking the TSC unstable?

I'm not sure I understand...

Are you talking about the HVM case of an upstream kernel, maybe
when the clocksource is manually overridden on the kernel command
line or after boot with sysfs?

If pvclock is necessary (e.g. old Xen), how would it be
marked unstable? (I didn't know there was code to do that.)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 17:53:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 17:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJq70-00012x-BY; Mon, 16 Apr 2012 17:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJq6z-00012l-0J
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 17:53:13 +0000
Received: from [85.158.138.51:35848] by server-11.bemta-3.messagelabs.com id
	57/1A-18894-88C5C8F4; Mon, 16 Apr 2012 17:53:12 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334598789!22204595!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31938 invoked from network); 16 Apr 2012 17:53:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 17:53:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GHqx39019805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 17:53:00 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GHqvSr020574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 17:52:58 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GHquBl018531; Mon, 16 Apr 2012 12:52:56 -0500
MIME-Version: 1.0
Message-ID: <3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
Date: Mon, 16 Apr 2012 10:52:48 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Tim Deegan <tim@xen.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
In-Reply-To: <20120416170827.GE13111@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F8C5C7D.0010,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> > Hmmm... I spent a great deal of time on TSC support in the hypervisor
> > 2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
> > everything on HVM as well.  There's most likely a bug or two still lurking
> > but, for all guests, with the default tsc_mode, TSC is provided by Xen
> > as an absolutely stable clock source.  If Xen determines that the underlying
> > hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
> > If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
> > save/restore, TSC is always emulated.  The result is (ignoring possible
> > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
> > CPUs; and c) constant rate.  Even across migration/save/restore.
> 
> AIUI, this thread is about the PV-time clock source, not about the TSC
> itself.  Even if the TSC is emulated (or in some other way made
> "stable") the PV wallclock is not necessarily stable across migration.
> But since migration is controlled by the kernel, presumably the kernel
> can DTRT about it.

Under what circumstances is PV wallclock not stable across migration?

> > In fact, it might be wise for a Xen-savvy kernel to check to see
> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > and tsc=reliable.
> 
> That seems like overdoing it.  Certainly it's not OK unless it can also
> check that Xen is providing a stable TSC (i.e. that tscmode==1).

Xen guarantees a stable TSC for the default (tsc_mode==0) also.

If the vm.cfg file explicitly sets a guest tsc_mode==2, you are correct
that pvclock is still necessary.  But as the documentation says:
tsc_mode==2 should be set if "it is certain that all apps running in this
VM are TSC-resilient and highest performance is required".  In
the case we are talking about, the PV guest kernel itself isn't TSC-
resilient!

In any case, IIRC, there is a pvcpuid instruction to determine the
tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
also check to ensure the tsc_mode wasn't overridden and set to 2.
If it is set to 2, TSC should not be an available clocksource,
as the guest kernel would break on migration/save/restore.

> In the case where the PV clock has been selected, can it not be marked
> unstable without also marking the TSC unstable?

I'm not sure I understand...

Are you talking about the HVM case of an upstream kernel, maybe
when the clocksource is manually overridden on the kernel command
line or after boot with sysfs?

If pvclock is necessary (e.g. old Xen), how would it be
marked unstable? (I didn't know there was code to do that.)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqT2-0001fZ-MD; Mon, 16 Apr 2012 18:16:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SJqT1-0001fU-CS
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 18:15:59 +0000
Received: from [193.109.254.147:51703] by server-9.bemta-14.messagelabs.com id
	61/EE-05787-ED16C8F4; Mon, 16 Apr 2012 18:15:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334600156!4874966!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3420 invoked from network); 16 Apr 2012 18:15:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190577097"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:15:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:15:54 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SJqSw-0003ym-M1;
	Mon, 16 Apr 2012 19:15:54 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 19:15:51 +0100
Message-ID: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently `xl vncviewer $dom` does not work because the VNC port is not
registered in xenstore when using qemu-upstream. This patch attempted to fix
this.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_qmp.c |   59 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..72ff4a4 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -154,6 +154,55 @@ static int register_serials_chardev_callback(libxl__qmp_handler *qmp,
     return ret;
 }
 
+static int qmp_write_domain_console_item(libxl__gc *gc, int domid,
+                                         const char *item, const char *value)
+{
+    char *path;
+
+    path = libxl__xs_get_dompath(gc, domid);
+    path = libxl__sprintf(gc, "%s/console/%s", path, item);
+
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", value);
+}
+
+static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
+                                     const libxl__json_object *o,
+                                     void *unused)
+{
+    GC_INIT(qmp->ctx);
+    const libxl__json_object *obj;
+    const char *listen, *port;
+    int rc = -1;
+
+    if (!libxl__json_object_is_map(o)) {
+        goto out;
+    }
+
+    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+        rc = 0;
+        goto out;
+    }
+
+    obj = libxl__json_map_get("host", o, JSON_STRING);
+    listen = libxl__json_object_get_string(obj);
+    obj = libxl__json_map_get("service", o, JSON_STRING);
+    port = libxl__json_object_get_string(obj);
+
+    if (!listen || !port) {
+        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
+                   "Failed to retreive VNC connect information.");
+        goto out;
+    }
+
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    if (!rc)
+        rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
+
+out:
+    GC_FREE;
+    return rc;
+}
+
 static int qmp_capabilities_callback(libxl__qmp_handler *qmp,
                                      const libxl__json_object *o, void *unused)
 {
@@ -688,6 +737,13 @@ int libxl__qmp_query_serial(libxl__qmp_handler *qmp)
                                 NULL, qmp->timeout);
 }
 
+static int qmp_query_vnc(libxl__qmp_handler *qmp)
+{
+    return qmp_synchronous_send(qmp, "query-vnc", NULL,
+                                qmp_register_vnc_callback,
+                                NULL, qmp->timeout);
+}
+
 static int pci_add_callback(libxl__qmp_handler *qmp,
                             const libxl__json_object *response, void *opaque)
 {
@@ -917,6 +973,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
     if (!ret && vnc && vnc->passwd) {
         ret = qmp_change(gc, qmp, "vnc", "password", vnc->passwd);
     }
+    if (!ret) {
+        ret = qmp_query_vnc(qmp);
+    }
     libxl__qmp_close(qmp);
     return ret;
 }
-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqT2-0001fZ-MD; Mon, 16 Apr 2012 18:16:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SJqT1-0001fU-CS
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 18:15:59 +0000
Received: from [193.109.254.147:51703] by server-9.bemta-14.messagelabs.com id
	61/EE-05787-ED16C8F4; Mon, 16 Apr 2012 18:15:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334600156!4874966!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3420 invoked from network); 16 Apr 2012 18:15:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190577097"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:15:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:15:54 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SJqSw-0003ym-M1;
	Mon, 16 Apr 2012 19:15:54 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 16 Apr 2012 19:15:51 +0100
Message-ID: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently `xl vncviewer $dom` does not work because the VNC port is not
registered in xenstore when using qemu-upstream. This patch attempted to fix
this.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_qmp.c |   59 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f5a3edc..72ff4a4 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -154,6 +154,55 @@ static int register_serials_chardev_callback(libxl__qmp_handler *qmp,
     return ret;
 }
 
+static int qmp_write_domain_console_item(libxl__gc *gc, int domid,
+                                         const char *item, const char *value)
+{
+    char *path;
+
+    path = libxl__xs_get_dompath(gc, domid);
+    path = libxl__sprintf(gc, "%s/console/%s", path, item);
+
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", value);
+}
+
+static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
+                                     const libxl__json_object *o,
+                                     void *unused)
+{
+    GC_INIT(qmp->ctx);
+    const libxl__json_object *obj;
+    const char *listen, *port;
+    int rc = -1;
+
+    if (!libxl__json_object_is_map(o)) {
+        goto out;
+    }
+
+    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+        rc = 0;
+        goto out;
+    }
+
+    obj = libxl__json_map_get("host", o, JSON_STRING);
+    listen = libxl__json_object_get_string(obj);
+    obj = libxl__json_map_get("service", o, JSON_STRING);
+    port = libxl__json_object_get_string(obj);
+
+    if (!listen || !port) {
+        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
+                   "Failed to retreive VNC connect information.");
+        goto out;
+    }
+
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    if (!rc)
+        rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
+
+out:
+    GC_FREE;
+    return rc;
+}
+
 static int qmp_capabilities_callback(libxl__qmp_handler *qmp,
                                      const libxl__json_object *o, void *unused)
 {
@@ -688,6 +737,13 @@ int libxl__qmp_query_serial(libxl__qmp_handler *qmp)
                                 NULL, qmp->timeout);
 }
 
+static int qmp_query_vnc(libxl__qmp_handler *qmp)
+{
+    return qmp_synchronous_send(qmp, "query-vnc", NULL,
+                                qmp_register_vnc_callback,
+                                NULL, qmp->timeout);
+}
+
 static int pci_add_callback(libxl__qmp_handler *qmp,
                             const libxl__json_object *response, void *opaque)
 {
@@ -917,6 +973,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
     if (!ret && vnc && vnc->passwd) {
         ret = qmp_change(gc, qmp, "vnc", "password", vnc->passwd);
     }
+    if (!ret) {
+        ret = qmp_query_vnc(qmp);
+    }
     libxl__qmp_close(qmp);
     return ret;
 }
-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:18:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqUw-0001mm-CS; Mon, 16 Apr 2012 18:17:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJqUu-0001mX-RA
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 18:17:57 +0000
Received: from [85.158.139.83:38832] by server-11.bemta-5.messagelabs.com id
	6E/24-12959-4526C8F4; Mon, 16 Apr 2012 18:17:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334600275!12795109!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3297 invoked from network); 16 Apr 2012 18:17:55 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:17:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJqUi-00056E-NR; Mon, 16 Apr 2012 18:17:44 +0000
Date: Mon, 16 Apr 2012 19:17:44 +0100
From: Tim Deegan <tim@xen.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120416181744.GF13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
User-Agent: Mutt/1.4.2.1i
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:52 -0700 on 16 Apr (1334573568), Dan Magenheimer wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> > 
> > At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> > > Hmmm... I spent a great deal of time on TSC support in the hypervisor
> > > 2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
> > > everything on HVM as well.  There's most likely a bug or two still lurking
> > > but, for all guests, with the default tsc_mode, TSC is provided by Xen
> > > as an absolutely stable clock source.  If Xen determines that the underlying
> > > hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
> > > If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
> > > save/restore, TSC is always emulated.  The result is (ignoring possible
> > > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
> > > CPUs; and c) constant rate.  Even across migration/save/restore.
> > 
> > AIUI, this thread is about the PV-time clock source, not about the TSC
> > itself.  Even if the TSC is emulated (or in some other way made
> > "stable") the PV wallclock is not necessarily stable across migration.
> > But since migration is controlled by the kernel, presumably the kernel
> > can DTRT about it.
> 
> Under what circumstances is PV wallclock not stable across migration?

The wallclock is host-local, so I don't think it can be guaranteed to be
strictly monotonic across migration.  But as I said that's OK because
the Xen code in the kernel is in control during migration.

> > > In fact, it might be wise for a Xen-savvy kernel to check to see
> > > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > > and tsc=reliable.
> > 
> > That seems like overdoing it.  Certainly it's not OK unless it can also
> > check that Xen is providing a stable TSC (i.e. that tscmode==1).
> 
> Xen guarantees a stable TSC for the default (tsc_mode==0) also.
> 
> If the vm.cfg file explicitly sets a guest tsc_mode==2, you are correct
> that pvclock is still necessary.  But as the documentation says:
> tsc_mode==2 should be set if "it is certain that all apps running in this
> VM are TSC-resilient and highest performance is required".  In
> the case we are talking about, the PV guest kernel itself isn't TSC-
> resilient!

Only if we deliberately break it! :) 

> In any case, IIRC, there is a pvcpuid instruction to determine the
> tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
> also check to ensure the tsc_mode wasn't overridden and set to 2.

Yes, that's what I was suggesting.

> > In the case where the PV clock has been selected, can it not be marked
> > unstable without also marking the TSC unstable?
> 
> I'm not sure I understand...
> 
> Are you talking about the HVM case of an upstream kernel, maybe
> when the clocksource is manually overridden on the kernel command
> line or after boot with sysfs?

I'm talking about any case where the clocksource == xen.  

> If pvclock is necessary (e.g. old Xen), how would it be
> marked unstable? (I didn't know there was code to do that.)

I think I'm confused by terminology.  Maybe David can correct me.  My
understanding was that there is some concept inside linux of a time
source being 'stable', which requires it to be synchronized, monotonic
and constant-rate.  The PV clock is two of those things (within a
reasonable tolerance) but may not be monotonic over migration.  I was
suggesting that, however linux deals with that, it can probably do it
without changing its opinion of whether the TSC is stable.

If the PV clocksource works, and works in more configurations than TSC,
I don't see much advantage of deprecating it in favour of TSC.  But I
don't have any huge objection to it either, I guess, as long as it only
happens when it's safe.

And on older Xens, or for tsc_mode==2, the kernel probably ought to mark
the TSC as unstable, because it is.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:18:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqUw-0001mm-CS; Mon, 16 Apr 2012 18:17:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SJqUu-0001mX-RA
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 18:17:57 +0000
Received: from [85.158.139.83:38832] by server-11.bemta-5.messagelabs.com id
	6E/24-12959-4526C8F4; Mon, 16 Apr 2012 18:17:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334600275!12795109!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3297 invoked from network); 16 Apr 2012 18:17:55 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:17:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SJqUi-00056E-NR; Mon, 16 Apr 2012 18:17:44 +0000
Date: Mon, 16 Apr 2012 19:17:44 +0100
From: Tim Deegan <tim@xen.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120416181744.GF13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
User-Agent: Mutt/1.4.2.1i
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:52 -0700 on 16 Apr (1334573568), Dan Magenheimer wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> > 
> > At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> > > Hmmm... I spent a great deal of time on TSC support in the hypervisor
> > > 2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
> > > everything on HVM as well.  There's most likely a bug or two still lurking
> > > but, for all guests, with the default tsc_mode, TSC is provided by Xen
> > > as an absolutely stable clock source.  If Xen determines that the underlying
> > > hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
> > > If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
> > > save/restore, TSC is always emulated.  The result is (ignoring possible
> > > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
> > > CPUs; and c) constant rate.  Even across migration/save/restore.
> > 
> > AIUI, this thread is about the PV-time clock source, not about the TSC
> > itself.  Even if the TSC is emulated (or in some other way made
> > "stable") the PV wallclock is not necessarily stable across migration.
> > But since migration is controlled by the kernel, presumably the kernel
> > can DTRT about it.
> 
> Under what circumstances is PV wallclock not stable across migration?

The wallclock is host-local, so I don't think it can be guaranteed to be
strictly monotonic across migration.  But as I said that's OK because
the Xen code in the kernel is in control during migration.

> > > In fact, it might be wise for a Xen-savvy kernel to check to see
> > > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> > > and tsc=reliable.
> > 
> > That seems like overdoing it.  Certainly it's not OK unless it can also
> > check that Xen is providing a stable TSC (i.e. that tscmode==1).
> 
> Xen guarantees a stable TSC for the default (tsc_mode==0) also.
> 
> If the vm.cfg file explicitly sets a guest tsc_mode==2, you are correct
> that pvclock is still necessary.  But as the documentation says:
> tsc_mode==2 should be set if "it is certain that all apps running in this
> VM are TSC-resilient and highest performance is required".  In
> the case we are talking about, the PV guest kernel itself isn't TSC-
> resilient!

Only if we deliberately break it! :) 

> In any case, IIRC, there is a pvcpuid instruction to determine the
> tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
> also check to ensure the tsc_mode wasn't overridden and set to 2.

Yes, that's what I was suggesting.

> > In the case where the PV clock has been selected, can it not be marked
> > unstable without also marking the TSC unstable?
> 
> I'm not sure I understand...
> 
> Are you talking about the HVM case of an upstream kernel, maybe
> when the clocksource is manually overridden on the kernel command
> line or after boot with sysfs?

I'm talking about any case where the clocksource == xen.  

> If pvclock is necessary (e.g. old Xen), how would it be
> marked unstable? (I didn't know there was code to do that.)

I think I'm confused by terminology.  Maybe David can correct me.  My
understanding was that there is some concept inside linux of a time
source being 'stable', which requires it to be synchronized, monotonic
and constant-rate.  The PV clock is two of those things (within a
reasonable tolerance) but may not be monotonic over migration.  I was
suggesting that, however linux deals with that, it can probably do it
without changing its opinion of whether the TSC is stable.

If the PV clocksource works, and works in more configurations than TSC,
I don't see much advantage of deprecating it in favour of TSC.  But I
don't have any huge objection to it either, I guess, as long as it only
happens when it's safe.

And on older Xens, or for tsc_mode==2, the kernel probably ought to mark
the TSC as unstable, because it is.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqeY-0002AO-Fi; Mon, 16 Apr 2012 18:27:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqeX-0002AJ-Dy
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:27:53 +0000
Received: from [85.158.143.35:60509] by server-3.bemta-4.messagelabs.com id
	0B/07-05853-8A46C8F4; Mon, 16 Apr 2012 18:27:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334600869!11254407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30555 invoked from network); 16 Apr 2012 18:27:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11962438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 18:27:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 19:27:47 +0100
Date: Mon, 16 Apr 2012 19:32:29 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/7] qdisk local attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch implements local_attach support for QDISK: that means that
you can use qcow2 as disk format for your PV guests disks and use
pygrub to retrieve the kernel and initrd in dom0.

The idea is that we start a QEMU instance at boot time to listen to
local_attach requests. When libxl_device_disk_local_attach is called on
a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk
so that blkfront in dom0 will create a new xvd device for it.
Then pygrub can be pointed at this device to retrieve kernel and
initrd.


Changes in v3:
- libxl__device_disk_local_attach: wait for the backend to be
"connected" before returning.

Changes in v2:
- make libxl_device_disk_local_(de)attach internal functions;
- allocate the new disk in libxl_device_disk_local_attatch on the GC;
- remove libxl__device_generic_add_t, add a transaction parameter to
libxl__device_generic_add instead;
- add a new patch to introduce a blkdev_start option to xl.conf;
- reimplement libxl__alloc_vdev checking for the frontend path and
starting from blkdev_start;
- introduce a Linux specific libxl__devid_to_vdev function based on last
Jan's patch to blkfront.



Stefano Stabellini (7):
      libxl: libxl__device_disk_local_attach return a new libxl_device_disk
      libxl: add a transaction parameter to libxl__device_generic_add
      libxl: introduce libxl__device_disk_add_t
      xl/libxl: add a blkdev_start parameter
      libxl: introduce libxl__alloc_vdev
      xl/libxl: implement QDISK libxl_device_disk_local_attach
      libxl__device_disk_local_attach: wait for state "connected"

 tools/examples/xl.conf                          |    3 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl.c                             |  232 +-----------------
 tools/libxl/libxl.h                             |   17 +-
 tools/libxl/libxl_bootloader.c                  |   13 +-
 tools/libxl/libxl_create.c                      |   18 +-
 tools/libxl/libxl_device.c                      |   14 +-
 tools/libxl/libxl_internal.c                    |  299 +++++++++++++++++++++++
 tools/libxl/libxl_internal.h                    |   24 ++-
 tools/libxl/libxl_linux.c                       |   40 +++
 tools/libxl/libxl_netbsd.c                      |    6 +
 tools/libxl/libxl_pci.c                         |    2 +-
 tools/libxl/xl.c                                |    3 +
 tools/libxl/xl.h                                |    1 +
 tools/libxl/xl_cmdimpl.c                        |    5 +-
 16 files changed, 422 insertions(+), 261 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqeY-0002AO-Fi; Mon, 16 Apr 2012 18:27:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqeX-0002AJ-Dy
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:27:53 +0000
Received: from [85.158.143.35:60509] by server-3.bemta-4.messagelabs.com id
	0B/07-05853-8A46C8F4; Mon, 16 Apr 2012 18:27:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334600869!11254407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30555 invoked from network); 16 Apr 2012 18:27:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="11962438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 18:27:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 19:27:47 +0100
Date: Mon, 16 Apr 2012 19:32:29 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/7] qdisk local attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch implements local_attach support for QDISK: that means that
you can use qcow2 as disk format for your PV guests disks and use
pygrub to retrieve the kernel and initrd in dom0.

The idea is that we start a QEMU instance at boot time to listen to
local_attach requests. When libxl_device_disk_local_attach is called on
a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk
so that blkfront in dom0 will create a new xvd device for it.
Then pygrub can be pointed at this device to retrieve kernel and
initrd.


Changes in v3:
- libxl__device_disk_local_attach: wait for the backend to be
"connected" before returning.

Changes in v2:
- make libxl_device_disk_local_(de)attach internal functions;
- allocate the new disk in libxl_device_disk_local_attatch on the GC;
- remove libxl__device_generic_add_t, add a transaction parameter to
libxl__device_generic_add instead;
- add a new patch to introduce a blkdev_start option to xl.conf;
- reimplement libxl__alloc_vdev checking for the frontend path and
starting from blkdev_start;
- introduce a Linux specific libxl__devid_to_vdev function based on last
Jan's patch to blkfront.



Stefano Stabellini (7):
      libxl: libxl__device_disk_local_attach return a new libxl_device_disk
      libxl: add a transaction parameter to libxl__device_generic_add
      libxl: introduce libxl__device_disk_add_t
      xl/libxl: add a blkdev_start parameter
      libxl: introduce libxl__alloc_vdev
      xl/libxl: implement QDISK libxl_device_disk_local_attach
      libxl__device_disk_local_attach: wait for state "connected"

 tools/examples/xl.conf                          |    3 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl.c                             |  232 +-----------------
 tools/libxl/libxl.h                             |   17 +-
 tools/libxl/libxl_bootloader.c                  |   13 +-
 tools/libxl/libxl_create.c                      |   18 +-
 tools/libxl/libxl_device.c                      |   14 +-
 tools/libxl/libxl_internal.c                    |  299 +++++++++++++++++++++++
 tools/libxl/libxl_internal.h                    |   24 ++-
 tools/libxl/libxl_linux.c                       |   40 +++
 tools/libxl/libxl_netbsd.c                      |    6 +
 tools/libxl/libxl_pci.c                         |    2 +-
 tools/libxl/xl.c                                |    3 +
 tools/libxl/xl.h                                |    1 +
 tools/libxl/xl_cmdimpl.c                        |    5 +-
 16 files changed, 422 insertions(+), 261 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqha-0002Lf-9t; Mon, 16 Apr 2012 18:31:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhY-0002KZ-6Z
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:31:00 +0000
Received: from [85.158.143.35:12851] by server-2.bemta-4.messagelabs.com id
	78/5A-17550-3656C8F4; Mon, 16 Apr 2012 18:30:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334601057!11593671!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 303 invoked from network); 16 Apr 2012 18:30:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579575"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-GT; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:08 +0100
Message-ID: <1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__alloc_vdev: find a spare virtual block device in the
domain passed as argument.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   18 ++++++++++++++++++
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_linux.c    |   40 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   |    6 ++++++
 4 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 6131ec5..ac59aa6 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -480,6 +480,24 @@ out:
     return rc;
 }
 
+static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
+        char *blkdev_start, xs_transaction_t t)
+{
+    int devid = 0;
+    char *vdev = libxl__strdup(gc, blkdev_start);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
+
+    do {
+        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
+        if (libxl__xs_read(gc, t,
+                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
+                        dompath, devid)) == NULL)
+            return libxl__devid_to_vdev(gc, devid);
+        vdev[strlen(vdev) - 1]++;
+    } while(vdev[strlen(vdev) - 1] <= 'z');
+    return NULL;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index aab8300..871df05 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -761,6 +761,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..955a23b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,43 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+#define EXT_SHIFT 28
+#define EXTENDED (1<<EXT_SHIFT)
+#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED))
+#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
+
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+    if (n >= 26)
+        ptr = encode_disk_name(ptr, n / 26 - 1);
+    *ptr = 'a' + n % 26;
+    return ptr + 1;
+}
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    int minor;
+    int offset;
+    int nr_parts;
+    char *ptr = NULL;
+    char *ret = libxl__zalloc(gc, 32);
+
+    if (!VDEV_IS_EXTENDED(devid)) {
+        minor = devid & 0xff;
+        nr_parts = 16;
+    } else {
+        minor = BLKIF_MINOR_EXT(devid);
+        nr_parts = 256;
+    }
+    offset = minor / nr_parts;
+
+    strcpy(ret, "xvd");
+    ptr = encode_disk_name(ret + 3, offset);
+    if (minor % nr_parts == 0)
+        *ptr = 0;
+    else
+        snprintf(ptr, ret + 32 - ptr,
+                "%d", minor & (nr_parts - 1));
+    return ret;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 9e0ed6d..c8977ac 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 0;
 }
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    /* TODO */
+    return NULL;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqha-0002Lf-9t; Mon, 16 Apr 2012 18:31:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhY-0002KZ-6Z
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:31:00 +0000
Received: from [85.158.143.35:12851] by server-2.bemta-4.messagelabs.com id
	78/5A-17550-3656C8F4; Mon, 16 Apr 2012 18:30:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334601057!11593671!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 303 invoked from network); 16 Apr 2012 18:30:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579575"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-GT; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:08 +0100
Message-ID: <1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__alloc_vdev: find a spare virtual block device in the
domain passed as argument.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   18 ++++++++++++++++++
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_linux.c    |   40 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   |    6 ++++++
 4 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 6131ec5..ac59aa6 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -480,6 +480,24 @@ out:
     return rc;
 }
 
+static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
+        char *blkdev_start, xs_transaction_t t)
+{
+    int devid = 0;
+    char *vdev = libxl__strdup(gc, blkdev_start);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
+
+    do {
+        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
+        if (libxl__xs_read(gc, t,
+                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
+                        dompath, devid)) == NULL)
+            return libxl__devid_to_vdev(gc, devid);
+        vdev[strlen(vdev) - 1]++;
+    } while(vdev[strlen(vdev) - 1] <= 'z');
+    return NULL;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index aab8300..871df05 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -761,6 +761,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..955a23b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,43 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+#define EXT_SHIFT 28
+#define EXTENDED (1<<EXT_SHIFT)
+#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED))
+#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
+
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+    if (n >= 26)
+        ptr = encode_disk_name(ptr, n / 26 - 1);
+    *ptr = 'a' + n % 26;
+    return ptr + 1;
+}
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    int minor;
+    int offset;
+    int nr_parts;
+    char *ptr = NULL;
+    char *ret = libxl__zalloc(gc, 32);
+
+    if (!VDEV_IS_EXTENDED(devid)) {
+        minor = devid & 0xff;
+        nr_parts = 16;
+    } else {
+        minor = BLKIF_MINOR_EXT(devid);
+        nr_parts = 256;
+    }
+    offset = minor / nr_parts;
+
+    strcpy(ret, "xvd");
+    ptr = encode_disk_name(ret + 3, offset);
+    if (minor % nr_parts == 0)
+        *ptr = 0;
+    else
+        snprintf(ptr, ret + 32 - ptr,
+                "%d", minor & (nr_parts - 1));
+    return ret;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 9e0ed6d..c8977ac 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 0;
 }
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+    /* TODO */
+    return NULL;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhY-0002Kx-T8; Mon, 16 Apr 2012 18:31:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhW-0002KB-Tk
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:59 +0000
Received: from [85.158.138.51:3649] by server-5.bemta-3.messagelabs.com id
	63/BB-17113-2656C8F4; Mon, 16 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334601055!22249710!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19211 invoked from network); 16 Apr 2012 18:30:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579572"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-Ef; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:07 +0100
Message-ID: <1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a blkdev_start in xl.conf and pass it to
libxl_domain_create_* and all the way through libxl_run_bootloader and
libxl__device_disk_local_attach.

blkdev_start specifies the first block device to be used for temporary
block device allocations by the toolstack.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/examples/xl.conf         |    3 +++
 tools/libxl/libxl.h            |   10 +++++++---
 tools/libxl/libxl_bootloader.c |    6 ++++--
 tools/libxl/libxl_create.c     |   18 ++++++++++++------
 tools/libxl/libxl_internal.c   |    3 ++-
 tools/libxl/libxl_internal.h   |    3 ++-
 tools/libxl/xl.c               |    3 +++
 tools/libxl/xl.h               |    1 +
 tools/libxl/xl_cmdimpl.c       |    5 +++--
 9 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..ebf057c 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# first block device to be used for temporary VM disk mounts
+#blkdev_start="xvda"
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 779c8dd..151a6e0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -464,8 +464,11 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, char* blkdev_start);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd,
+		char *blkdev_start);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
@@ -493,7 +496,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         char *blkdev_start);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 429253d..fe56615 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -323,7 +323,8 @@ static void parse_bootloader_result(libxl__gc *gc,
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid)
+                         uint32_t domid,
+                         char *blkdev_start)
 {
     GC_INIT(ctx);
     int ret, rc = 0;
@@ -387,7 +388,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk,
+            blkdev_start);
     if (!diskpath) {
         goto out_close;
     }
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 6029445..5064bc3 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -544,7 +544,8 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+                            uint32_t *domid_out, int restore_fd,
+							char* blkdev_start)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
@@ -581,7 +582,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     }
 
     if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+        ret = libxl_run_bootloader(ctx, &d_config->b_info,
+                d_config->num_disks > 0 ? &d_config->disks[0] : NULL,
+                domid, blkdev_start);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
@@ -735,21 +738,24 @@ error_out:
 }
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+							char* blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1, blkdev_start);
     GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv, uint32_t *domid,
+								int restore_fd, char *blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd,
+			blkdev_start);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 9ecfcc7..6131ec5 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -482,7 +482,8 @@ out:
 
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk)
+        libxl_device_disk **new_disk,
+        char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c171f24..aab8300 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1013,7 +1013,8 @@ _hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk);
+        libxl_device_disk **new_disk,
+        char *blkdev_start);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..6a735e9 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+char *blkdev_start = "xvda";
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile,
             fprintf(stderr, "invalid default output format \"%s\"\n", buf);
         }
     }
+    if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0))
+        blkdev_start = strdup(buf);
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..dba2c94 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -113,6 +113,7 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 extern char *default_bridge;
+extern char *blkdev_start;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..1a3945c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1669,7 +1669,7 @@ start:
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
                                             cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                            &domid, restore_fd, blkdev_start);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1677,7 +1677,8 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                        cb, &child_console_pid, &domid,
+										blkdev_start);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhY-0002Kx-T8; Mon, 16 Apr 2012 18:31:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhW-0002KB-Tk
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:59 +0000
Received: from [85.158.138.51:3649] by server-5.bemta-3.messagelabs.com id
	63/BB-17113-2656C8F4; Mon, 16 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334601055!22249710!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19211 invoked from network); 16 Apr 2012 18:30:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579572"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-Ef; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:07 +0100
Message-ID: <1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a blkdev_start in xl.conf and pass it to
libxl_domain_create_* and all the way through libxl_run_bootloader and
libxl__device_disk_local_attach.

blkdev_start specifies the first block device to be used for temporary
block device allocations by the toolstack.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/examples/xl.conf         |    3 +++
 tools/libxl/libxl.h            |   10 +++++++---
 tools/libxl/libxl_bootloader.c |    6 ++++--
 tools/libxl/libxl_create.c     |   18 ++++++++++++------
 tools/libxl/libxl_internal.c   |    3 ++-
 tools/libxl/libxl_internal.h   |    3 ++-
 tools/libxl/xl.c               |    3 +++
 tools/libxl/xl.h               |    1 +
 tools/libxl/xl_cmdimpl.c       |    5 +++--
 9 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..ebf057c 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# first block device to be used for temporary VM disk mounts
+#blkdev_start="xvda"
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 779c8dd..151a6e0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -464,8 +464,11 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, char* blkdev_start);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+		libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd,
+		char *blkdev_start);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
@@ -493,7 +496,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         char *blkdev_start);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 429253d..fe56615 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -323,7 +323,8 @@ static void parse_bootloader_result(libxl__gc *gc,
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid)
+                         uint32_t domid,
+                         char *blkdev_start)
 {
     GC_INIT(ctx);
     int ret, rc = 0;
@@ -387,7 +388,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk,
+            blkdev_start);
     if (!diskpath) {
         goto out_close;
     }
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 6029445..5064bc3 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -544,7 +544,8 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+                            uint32_t *domid_out, int restore_fd,
+							char* blkdev_start)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
@@ -581,7 +582,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     }
 
     if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+        ret = libxl_run_bootloader(ctx, &d_config->b_info,
+                d_config->num_disks > 0 ? &d_config->disks[0] : NULL,
+                domid, blkdev_start);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
@@ -735,21 +738,24 @@ error_out:
 }
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+							char* blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1, blkdev_start);
     GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv, uint32_t *domid,
+								int restore_fd, char *blkdev_start)
 {
     GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd,
+			blkdev_start);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 9ecfcc7..6131ec5 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -482,7 +482,8 @@ out:
 
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk)
+        libxl_device_disk **new_disk,
+        char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c171f24..aab8300 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1013,7 +1013,8 @@ _hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk);
+        libxl_device_disk **new_disk,
+        char *blkdev_start);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..6a735e9 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+char *blkdev_start = "xvda";
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile,
             fprintf(stderr, "invalid default output format \"%s\"\n", buf);
         }
     }
+    if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0))
+        blkdev_start = strdup(buf);
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..dba2c94 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -113,6 +113,7 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 extern char *default_bridge;
+extern char *blkdev_start;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..1a3945c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1669,7 +1669,7 @@ start:
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
                                             cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                            &domid, restore_fd, blkdev_start);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1677,7 +1677,8 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                        cb, &child_console_pid, &domid,
+										blkdev_start);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhX-0002KH-47; Mon, 16 Apr 2012 18:30:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhV-0002K3-Nl
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:58 +0000
Received: from [85.158.139.83:18612] by server-5.bemta-5.messagelabs.com id
	6D/DF-13566-0656C8F4; Mon, 16 Apr 2012 18:30:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334601054!24064244!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5767 invoked from network); 16 Apr 2012 18:30:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24203151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-In; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:10 +0100
Message-ID: <1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach: wait
	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to make sure that the block device is available and ready to be
used, wait for state "connected" in the backend before returning.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ba7b395..c955bf4 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -504,8 +504,9 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
-    char *dev = NULL;
+    char *dev = NULL, *be_path = NULL;
     int rc;
+    libxl__device device;
     libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
     if (tmpdisk == NULL) goto out;
 
@@ -581,6 +582,19 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
                 "type: %d", tmpdisk->backend);
             break;
     }
+    if (tmpdisk->vdev != NULL) {
+        rc = libxl__device_from_disk(gc, 0, tmpdisk, &device);
+        if (rc < 0) {
+            libxl__device_disk_local_detach(gc, tmpdisk);
+            return NULL;
+        }
+        be_path = libxl__device_backend_path(gc, &device);
+        rc = libxl__wait_for_backend(gc, be_path, "4");
+        if (rc < 0) {
+            libxl__device_disk_local_detach(gc, tmpdisk);
+            return NULL;
+        }
+    }
 
  out:
     return dev;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhX-0002KH-47; Mon, 16 Apr 2012 18:30:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhV-0002K3-Nl
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:58 +0000
Received: from [85.158.139.83:18612] by server-5.bemta-5.messagelabs.com id
	6D/DF-13566-0656C8F4; Mon, 16 Apr 2012 18:30:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334601054!24064244!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5767 invoked from network); 16 Apr 2012 18:30:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24203151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-In; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:10 +0100
Message-ID: <1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach: wait
	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to make sure that the block device is available and ready to be
used, wait for state "connected" in the backend before returning.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ba7b395..c955bf4 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -504,8 +504,9 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
-    char *dev = NULL;
+    char *dev = NULL, *be_path = NULL;
     int rc;
+    libxl__device device;
     libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
     if (tmpdisk == NULL) goto out;
 
@@ -581,6 +582,19 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
                 "type: %d", tmpdisk->backend);
             break;
     }
+    if (tmpdisk->vdev != NULL) {
+        rc = libxl__device_from_disk(gc, 0, tmpdisk, &device);
+        if (rc < 0) {
+            libxl__device_disk_local_detach(gc, tmpdisk);
+            return NULL;
+        }
+        be_path = libxl__device_backend_path(gc, &device);
+        rc = libxl__wait_for_backend(gc, be_path, "4");
+        if (rc < 0) {
+            libxl__device_disk_local_detach(gc, tmpdisk);
+            return NULL;
+        }
+    }
 
  out:
     return dev;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhY-0002Kl-Ge; Mon, 16 Apr 2012 18:31:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhW-0002K6-F1
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:58 +0000
Received: from [85.158.139.83:18661] by server-9.bemta-5.messagelabs.com id
	47/F3-09826-1656C8F4; Mon, 16 Apr 2012 18:30:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334601054!24064244!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5800 invoked from network); 16 Apr 2012 18:30:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24203152"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-BI; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:04 +0100
Message-ID: <1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach
	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- make libxl_device_disk_local_attach/detach two internal functions;

- pass a gc rather than a ctx to them;

- introduce a new libxl_device_disk** parameter to
libxl__device_disk_local_attach, the parameter is allocated on the gc by
libxl__device_disk_local_attach. It is going to fill it with
informations about the new locally attached disk.  The new
libxl_device_disk should be passed to libxl_device_disk_local_detach
afterwards.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c            |   73 -----------------------------------
 tools/libxl/libxl.h            |    7 ---
 tools/libxl/libxl_bootloader.c |    9 ++--
 tools/libxl/libxl_internal.c   |   82 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   11 +++++
 5 files changed, 97 insertions(+), 85 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..e645d2a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1664,79 +1664,6 @@ out:
     return ret;
 }
 
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    char *dev = NULL;
-    char *ret = NULL;
-    int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
-    }
-
- out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    GC_FREE;
-    return ret;
-}
-
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
-}
-
 /******************************************************************************/
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..779c8dd 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -618,13 +618,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
  */
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
-
 /* Network Interfaces */
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..429253d 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    libxl_device_disk *tmpdisk = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -386,7 +387,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
     if (!diskpath) {
         goto out_close;
     }
@@ -452,10 +453,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     rc = 0;
 out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
+    if (tmpdisk)
+        libxl__device_disk_local_detach(gc, tmpdisk);
     if (fifo_fd > -1)
         close(fifo_fd);
     if (bootloader_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index b89aef7..95fb918 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,88 @@ out:
     return rc;
 }
 
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk)
+{
+    libxl_ctx *ctx = gc->owner;
+    char *dev = NULL;
+    int rc;
+    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
+    if (tmpdisk == NULL) goto out;
+
+    *new_disk = tmpdisk;
+    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));
+    if (disk->pdev_path != NULL)
+        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
+    if (disk->script != NULL)
+        tmpdisk->script = libxl__strdup(gc, disk->script);
+    tmpdisk->vdev = NULL;
+
+    rc = libxl__device_disk_setdefault(gc, tmpdisk);
+    if (rc) goto out;
+
+    switch (tmpdisk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
+                       tmpdisk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            switch (tmpdisk->format) {
+            case LIBXL_DISK_FORMAT_RAW:
+                /* optimise away the early tapdisk attach in this case */
+                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
+                           " tap disk %s directly (ie without using blktap)",
+                           tmpdisk->pdev_path);
+                dev = tmpdisk->pdev_path;
+                break;
+            case LIBXL_DISK_FORMAT_VHD:
+                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
+                                            tmpdisk->format);
+                break;
+            case LIBXL_DISK_FORMAT_QCOW:
+            case LIBXL_DISK_FORMAT_QCOW2:
+                abort(); /* prevented by libxl__device_disk_set_backend */
+            default:
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unrecognized disk format: %d", tmpdisk->format);
+                break;
+            }
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
+                           " attach a qdisk image if the format is not raw");
+                break;
+            }
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
+                       disk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
+                "type: %d", tmpdisk->backend);
+            break;
+    }
+
+ out:
+    return dev;
+}
+
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk)
+{
+    /* Nothing to do for PHYSTYPE_PHY. */
+
+    /*
+     * For other device types assume that the blktap2 process is
+     * needed by the soon to be started domain and do nothing.
+     */
+
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..4e0d203 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,17 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+/*
+ * Make a disk available in this (the control) domain. Returns path to
+ * a device.
+ */
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk);
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk);
+
+
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhY-0002Kl-Ge; Mon, 16 Apr 2012 18:31:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhW-0002K6-F1
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:58 +0000
Received: from [85.158.139.83:18661] by server-9.bemta-5.messagelabs.com id
	47/F3-09826-1656C8F4; Mon, 16 Apr 2012 18:30:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334601054!24064244!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5800 invoked from network); 16 Apr 2012 18:30:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24203152"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-BI; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:04 +0100
Message-ID: <1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach
	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- make libxl_device_disk_local_attach/detach two internal functions;

- pass a gc rather than a ctx to them;

- introduce a new libxl_device_disk** parameter to
libxl__device_disk_local_attach, the parameter is allocated on the gc by
libxl__device_disk_local_attach. It is going to fill it with
informations about the new locally attached disk.  The new
libxl_device_disk should be passed to libxl_device_disk_local_detach
afterwards.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c            |   73 -----------------------------------
 tools/libxl/libxl.h            |    7 ---
 tools/libxl/libxl_bootloader.c |    9 ++--
 tools/libxl/libxl_internal.c   |   82 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   11 +++++
 5 files changed, 97 insertions(+), 85 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..e645d2a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1664,79 +1664,6 @@ out:
     return ret;
 }
 
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    char *dev = NULL;
-    char *ret = NULL;
-    int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
-    }
-
- out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    GC_FREE;
-    return ret;
-}
-
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
-}
-
 /******************************************************************************/
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..779c8dd 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -618,13 +618,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
  */
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
-
 /* Network Interfaces */
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..429253d 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    libxl_device_disk *tmpdisk = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -386,7 +387,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
     if (!diskpath) {
         goto out_close;
     }
@@ -452,10 +453,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     rc = 0;
 out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
+    if (tmpdisk)
+        libxl__device_disk_local_detach(gc, tmpdisk);
     if (fifo_fd > -1)
         close(fifo_fd);
     if (bootloader_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index b89aef7..95fb918 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,88 @@ out:
     return rc;
 }
 
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk)
+{
+    libxl_ctx *ctx = gc->owner;
+    char *dev = NULL;
+    int rc;
+    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
+    if (tmpdisk == NULL) goto out;
+
+    *new_disk = tmpdisk;
+    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));
+    if (disk->pdev_path != NULL)
+        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
+    if (disk->script != NULL)
+        tmpdisk->script = libxl__strdup(gc, disk->script);
+    tmpdisk->vdev = NULL;
+
+    rc = libxl__device_disk_setdefault(gc, tmpdisk);
+    if (rc) goto out;
+
+    switch (tmpdisk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
+                       tmpdisk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            switch (tmpdisk->format) {
+            case LIBXL_DISK_FORMAT_RAW:
+                /* optimise away the early tapdisk attach in this case */
+                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
+                           " tap disk %s directly (ie without using blktap)",
+                           tmpdisk->pdev_path);
+                dev = tmpdisk->pdev_path;
+                break;
+            case LIBXL_DISK_FORMAT_VHD:
+                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
+                                            tmpdisk->format);
+                break;
+            case LIBXL_DISK_FORMAT_QCOW:
+            case LIBXL_DISK_FORMAT_QCOW2:
+                abort(); /* prevented by libxl__device_disk_set_backend */
+            default:
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unrecognized disk format: %d", tmpdisk->format);
+                break;
+            }
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
+                           " attach a qdisk image if the format is not raw");
+                break;
+            }
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
+                       disk->pdev_path);
+            dev = tmpdisk->pdev_path;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
+                "type: %d", tmpdisk->backend);
+            break;
+    }
+
+ out:
+    return dev;
+}
+
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk)
+{
+    /* Nothing to do for PHYSTYPE_PHY. */
+
+    /*
+     * For other device types assume that the blktap2 process is
+     * needed by the soon to be started domain and do nothing.
+     */
+
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..4e0d203 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,17 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+/*
+ * Make a disk available in this (the control) domain. Returns path to
+ * a device.
+ */
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk);
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk);
+
+
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqha-0002Lt-Mb; Mon, 16 Apr 2012 18:31:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhY-0002Ka-CP
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:31:00 +0000
Received: from [85.158.138.51:31694] by server-10.bemta-3.messagelabs.com id
	DA/DC-29478-3656C8F4; Mon, 16 Apr 2012 18:30:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334601055!22249710!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19237 invoked from network); 16 Apr 2012 18:30:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579574"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-IE; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:09 +0100
Message-ID: <1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Spawn a QEMU instance at boot time to handle disk local attach
requests.

- Implement libxl_device_disk_local_attach for QDISKs in terms of a
regular disk attach with the frontend and backend running in the same
domain.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl_internal.c                    |   49 +++++++++++++++++-----
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons
index 6543204..0f3b9ad 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -12,3 +12,6 @@
 
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
+
+# qemu path and log file
+#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 2f81ea2..9dda6e2 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -104,6 +104,9 @@ do_start () {
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
 	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting QEMU as disk backend for dom0
+	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ac59aa6..ba7b395 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -550,13 +550,31 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
+                xs_transaction_t t;
+                do {
+                    t = xs_transaction_start(ctx->xsh);
+                    /* use 0 as the domid of the toolstack domain for now */
+                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);
+                    if (tmpdisk->vdev == NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl__alloc_vdev failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    if (libxl__device_disk_add_t(gc, 0, t, tmpdisk)) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl_device_disk_add failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    rc = xs_transaction_end(ctx->xsh, t, 0);
+                } while (rc == 0 && errno == EAGAIN);
+                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);
+            } else {
+                dev = tmpdisk->pdev_path;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = tmpdisk->pdev_path;
+                       dev);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
@@ -571,12 +589,21 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+                libxl_device_disk_remove(gc->owner, 0, disk, 0);
+                return libxl_device_disk_destroy(gc->owner, 0, disk);
+            }
+            break;
+        default:
+            /*
+             * Nothing to do for PHYSTYPE_PHY.
+             * For other device types assume that the blktap2 process is
+             * needed by the soon to be started domain and do nothing.
+             */
+            break;
+    }
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqha-0002Lt-Mb; Mon, 16 Apr 2012 18:31:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhY-0002Ka-CP
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:31:00 +0000
Received: from [85.158.138.51:31694] by server-10.bemta-3.messagelabs.com id
	DA/DC-29478-3656C8F4; Mon, 16 Apr 2012 18:30:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334601055!22249710!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19237 invoked from network); 16 Apr 2012 18:30:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579574"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-IE; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:09 +0100
Message-ID: <1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Spawn a QEMU instance at boot time to handle disk local attach
requests.

- Implement libxl_device_disk_local_attach for QDISKs in terms of a
regular disk attach with the frontend and backend running in the same
domain.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl_internal.c                    |   49 +++++++++++++++++-----
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons
index 6543204..0f3b9ad 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -12,3 +12,6 @@
 
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
+
+# qemu path and log file
+#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 2f81ea2..9dda6e2 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -104,6 +104,9 @@ do_start () {
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
 	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting QEMU as disk backend for dom0
+	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ac59aa6..ba7b395 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -550,13 +550,31 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
+                xs_transaction_t t;
+                do {
+                    t = xs_transaction_start(ctx->xsh);
+                    /* use 0 as the domid of the toolstack domain for now */
+                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);
+                    if (tmpdisk->vdev == NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl__alloc_vdev failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    if (libxl__device_disk_add_t(gc, 0, t, tmpdisk)) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl_device_disk_add failed\n");
+                        xs_transaction_end(ctx->xsh, t, 1);
+                        goto out;
+                    }
+                    rc = xs_transaction_end(ctx->xsh, t, 0);
+                } while (rc == 0 && errno == EAGAIN);
+                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);
+            } else {
+                dev = tmpdisk->pdev_path;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = tmpdisk->pdev_path;
+                       dev);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
@@ -571,12 +589,21 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+                libxl_device_disk_remove(gc->owner, 0, disk, 0);
+                return libxl_device_disk_destroy(gc->owner, 0, disk);
+            }
+            break;
+        default:
+            /*
+             * Nothing to do for PHYSTYPE_PHY.
+             * For other device types assume that the blktap2 process is
+             * needed by the soon to be started domain and do nothing.
+             */
+            break;
+    }
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhZ-0002L5-9b; Mon, 16 Apr 2012 18:31:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhX-0002KC-64
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:59 +0000
Received: from [85.158.139.83:18697] by server-8.bemta-5.messagelabs.com id
	D6/6A-26964-2656C8F4; Mon, 16 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334601054!24064244!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5819 invoked from network); 16 Apr 2012 18:30:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24203153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-CK; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:05 +0100
Message-ID: <1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter to
	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
XBT_NULL, allocate a proper one.

Update all the callers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |   10 +++++-----
 tools/libxl/libxl_device.c   |   14 +++++++-------
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_pci.c      |    2 +-
 4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e645d2a..85082eb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -1795,7 +1795,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -2073,7 +2073,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
     }
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2144,7 +2144,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2277,7 +2277,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
                           libxl__sprintf(gc, "%d", vfb->backend_domid));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..05909c5 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
-int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *frontend_path, *backend_path;
-    xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    int create_transaction = t == XBT_NULL;
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
@@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].perms = XS_PERM_READ;
 
 retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
+    if (create_transaction)
+        t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
 
     if (fents) {
@@ -101,13 +102,12 @@ retry_transaction:
     }
 
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
-        if (errno == EAGAIN)
+        if (errno == EAGAIN && create_transaction)
             goto retry_transaction;
         else
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
     }
-
-    return 0;
+    return ERROR_FAIL;
 }
 
 typedef struct {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e0d203..c0991eb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -681,8 +681,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
-_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index e8b8839..202a101 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhZ-0002L5-9b; Mon, 16 Apr 2012 18:31:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhX-0002KC-64
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:30:59 +0000
Received: from [85.158.139.83:18697] by server-8.bemta-5.messagelabs.com id
	D6/6A-26964-2656C8F4; Mon, 16 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334601054!24064244!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5819 invoked from network); 16 Apr 2012 18:30:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="24203153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-CK; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:05 +0100
Message-ID: <1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter to
	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
XBT_NULL, allocate a proper one.

Update all the callers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |   10 +++++-----
 tools/libxl/libxl_device.c   |   14 +++++++-------
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_pci.c      |    2 +-
 4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e645d2a..85082eb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -1795,7 +1795,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -2073,7 +2073,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
     }
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2144,7 +2144,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2277,7 +2277,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
                           libxl__sprintf(gc, "%d", vfb->backend_domid));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..05909c5 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
-int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *frontend_path, *backend_path;
-    xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    int create_transaction = t == XBT_NULL;
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
@@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].perms = XS_PERM_READ;
 
 retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
+    if (create_transaction)
+        t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
 
     if (fents) {
@@ -101,13 +102,12 @@ retry_transaction:
     }
 
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
-        if (errno == EAGAIN)
+        if (errno == EAGAIN && create_transaction)
             goto retry_transaction;
         else
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
     }
-
-    return 0;
+    return ERROR_FAIL;
 }
 
 typedef struct {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e0d203..c0991eb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -681,8 +681,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
-_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index e8b8839..202a101 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhZ-0002LV-TM; Mon, 16 Apr 2012 18:31:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhX-0002KL-OM
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:31:00 +0000
Received: from [85.158.138.51:31661] by server-1.bemta-3.messagelabs.com id
	70/21-11491-2656C8F4; Mon, 16 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334601055!22249710!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19224 invoked from network); 16 Apr 2012 18:30:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579573"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-E8; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:06 +0100
Message-ID: <1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/7] libxl: introduce libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__device_disk_add_t that takes an additional
xs_transaction_t paramter.
Implement libxl_device_disk_add using libxl__device_disk_add_t.
Move libxl__device_from_disk to libxl_internal.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |  151 +----------------------------------------
 tools/libxl/libxl_internal.c |  157 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++
 3 files changed, 164 insertions(+), 150 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 85082eb..0d7c0f6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
-    flexarray_t *front;
-    flexarray_t *back;
-    char *dev;
-    libxl__device device;
-    int major, minor, rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
-
-    if (disk->script) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
-                   " not yet supported, sorry");
-        rc = ERROR_INVAL;
-        goto out_free;
-    }
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        goto out_free;
-    }
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            dev = disk->pdev_path;
-    do_backend_phy:
-            libxl__device_physdisk_major_minor(dev, &major, &minor);
-            flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
-
-            flexarray_append(back, "params");
-            flexarray_append(back, dev);
-
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-            if (!dev) {
-                rc = ERROR_FAIL;
-                goto out_free;
-            }
-            flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                libxl__device_disk_string_of_format(disk->format),
-                disk->pdev_path));
-
-            /* now create a phy device to export the device to the guest */
-            goto do_backend_phy;
-        case LIBXL_DISK_BACKEND_QDISK:
-            flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
-            rc = ERROR_INVAL;
-            goto out_free;
-    }
-
-    flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
-    flexarray_append(back, "online");
-    flexarray_append(back, "1");
-    flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
-    flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "dev");
-    flexarray_append(back, disk->vdev);
-    flexarray_append(back, "type");
-    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
-    flexarray_append(back, "mode");
-    flexarray_append(back, disk->readwrite ? "w" : "r");
-    flexarray_append(back, "device-type");
-    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
-
-    flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
-    flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
-    flexarray_append(front, "device-type");
-    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
-
-    libxl__device_generic_add(gc, XBT_NULL, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
-
-    rc = 0;
-
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
-out:
+    int rc = libxl__device_disk_add_t(gc, domid, XBT_NULL, disk);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 95fb918..9ecfcc7 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,163 @@ out:
     return rc;
 }
 
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    char *dev;
+    libxl__device device;
+    int major, minor, rc;
+    libxl_ctx *ctx = gc->owner;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out_free;
+    }
+
+    if (disk->script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
+                   " not yet supported, sorry");
+        rc = ERROR_INVAL;
+        goto out_free;
+    }
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        goto out_free;
+    }
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            dev = disk->pdev_path;
+    do_backend_phy:
+            libxl__device_physdisk_major_minor(dev, &major, &minor);
+            flexarray_append(back, "physical-device");
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
+
+            flexarray_append(back, "params");
+            flexarray_append(back, dev);
+
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+            if (!dev) {
+                rc = ERROR_FAIL;
+                goto out_free;
+            }
+            flexarray_append(back, "tapdisk-params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                libxl__device_disk_string_of_format(disk->format),
+                disk->pdev_path));
+
+            /* now create a phy device to export the device to the guest */
+            goto do_backend_phy;
+        case LIBXL_DISK_BACKEND_QDISK:
+            flexarray_append(back, "params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
+            rc = ERROR_INVAL;
+            goto out_free;
+    }
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "removable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, "bootable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "dev");
+    flexarray_append(back, disk->vdev);
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
+    flexarray_append(back, "mode");
+    flexarray_append(back, disk->readwrite ? "w" : "r");
+    flexarray_append(back, "device-type");
+    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "virtual-device");
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, "device-type");
+    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
+
+    libxl__device_generic_add(gc, t, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+
+    rc = 0;
+
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    return rc;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c0991eb..c171f24 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device);
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk);
 /*
  * Make a disk available in this (the control) domain. Returns path to
  * a device.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:31:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqhZ-0002LV-TM; Mon, 16 Apr 2012 18:31:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SJqhX-0002KL-OM
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:31:00 +0000
Received: from [85.158.138.51:31661] by server-1.bemta-3.messagelabs.com id
	70/21-11491-2656C8F4; Mon, 16 Apr 2012 18:30:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334601055!22249710!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19224 invoked from network); 16 Apr 2012 18:30:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 18:30:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,430,1330923600"; d="scan'208";a="190579573"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 14:30:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Apr 2012 14:30:54 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SJqhM-0004BP-E8; Mon, 16 Apr 2012 19:30:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Apr 2012 19:33:06 +0100
Message-ID: <1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/7] libxl: introduce libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__device_disk_add_t that takes an additional
xs_transaction_t paramter.
Implement libxl_device_disk_add using libxl__device_disk_add_t.
Move libxl__device_from_disk to libxl_internal.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |  151 +----------------------------------------
 tools/libxl/libxl_internal.c |  157 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++
 3 files changed, 164 insertions(+), 150 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 85082eb..0d7c0f6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
-    flexarray_t *front;
-    flexarray_t *back;
-    char *dev;
-    libxl__device device;
-    int major, minor, rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
-
-    if (disk->script) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
-                   " not yet supported, sorry");
-        rc = ERROR_INVAL;
-        goto out_free;
-    }
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        goto out_free;
-    }
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            dev = disk->pdev_path;
-    do_backend_phy:
-            libxl__device_physdisk_major_minor(dev, &major, &minor);
-            flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
-
-            flexarray_append(back, "params");
-            flexarray_append(back, dev);
-
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-            if (!dev) {
-                rc = ERROR_FAIL;
-                goto out_free;
-            }
-            flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                libxl__device_disk_string_of_format(disk->format),
-                disk->pdev_path));
-
-            /* now create a phy device to export the device to the guest */
-            goto do_backend_phy;
-        case LIBXL_DISK_BACKEND_QDISK:
-            flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
-            rc = ERROR_INVAL;
-            goto out_free;
-    }
-
-    flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
-    flexarray_append(back, "online");
-    flexarray_append(back, "1");
-    flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
-    flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "dev");
-    flexarray_append(back, disk->vdev);
-    flexarray_append(back, "type");
-    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
-    flexarray_append(back, "mode");
-    flexarray_append(back, disk->readwrite ? "w" : "r");
-    flexarray_append(back, "device-type");
-    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
-
-    flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
-    flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
-    flexarray_append(front, "device-type");
-    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
-
-    libxl__device_generic_add(gc, XBT_NULL, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
-
-    rc = 0;
-
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
-out:
+    int rc = libxl__device_disk_add_t(gc, domid, XBT_NULL, disk);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 95fb918..9ecfcc7 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,163 @@ out:
     return rc;
 }
 
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    char *dev;
+    libxl__device device;
+    int major, minor, rc;
+    libxl_ctx *ctx = gc->owner;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out_free;
+    }
+
+    if (disk->script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
+                   " not yet supported, sorry");
+        rc = ERROR_INVAL;
+        goto out_free;
+    }
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        goto out_free;
+    }
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            dev = disk->pdev_path;
+    do_backend_phy:
+            libxl__device_physdisk_major_minor(dev, &major, &minor);
+            flexarray_append(back, "physical-device");
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
+
+            flexarray_append(back, "params");
+            flexarray_append(back, dev);
+
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+            if (!dev) {
+                rc = ERROR_FAIL;
+                goto out_free;
+            }
+            flexarray_append(back, "tapdisk-params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                libxl__device_disk_string_of_format(disk->format),
+                disk->pdev_path));
+
+            /* now create a phy device to export the device to the guest */
+            goto do_backend_phy;
+        case LIBXL_DISK_BACKEND_QDISK:
+            flexarray_append(back, "params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
+            rc = ERROR_INVAL;
+            goto out_free;
+    }
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "removable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, "bootable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "dev");
+    flexarray_append(back, disk->vdev);
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
+    flexarray_append(back, "mode");
+    flexarray_append(back, disk->readwrite ? "w" : "r");
+    flexarray_append(back, "device-type");
+    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "virtual-device");
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, "device-type");
+    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
+
+    libxl__device_generic_add(gc, t, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+
+    rc = 0;
+
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    return rc;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c0991eb..c171f24 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device);
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk);
 /*
  * Make a disk available in this (the control) domain. Returns path to
  * a device.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwJ-0003pG-5R; Mon, 16 Apr 2012 18:46:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwH-0003on-PF
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:13 +0000
Received: from [85.158.139.83:20021] by server-4.bemta-5.messagelabs.com id
	1D/D4-10788-4F86C8F4; Mon, 16 Apr 2012 18:46:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334601970!19466384!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6290 invoked from network); 16 Apr 2012 18:46:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:46:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjw2k015024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjv8O027731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvvO014899; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B08914032D; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:15 -0400
Message-Id: <1334601616-25309-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F8C68E8.0046,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, suresh.b.siddha@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.co,
	hpa@zytor.com, tglx@linutronix.de
Subject: [Xen-devel] [PATCH 2/3] xen/x86: Implement x86_apic_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Or rather just implement one different function as opposed
to the native one : the read function.

We synthesize the values.

Acked-by:  Suresh Siddha <suresh.b.siddha@intel.com>
[v1: Rebased on top of tip/x86/urgent]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/Makefile    |    2 +-
 arch/x86/xen/apic.c      |   17 +++++++++++++++++
 arch/x86/xen/enlighten.c |    2 ++
 arch/x86/xen/xen-ops.h   |    4 ++++
 4 files changed, 24 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/xen/apic.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index add2c2d..96ab2c0 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -20,5 +20,5 @@ obj-$(CONFIG_EVENT_TRACING) += trace.o
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
-obj-$(CONFIG_XEN_DOM0)		+= vga.o
+obj-$(CONFIG_XEN_DOM0)		+= apic.o vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
new file mode 100644
index 0000000..aee16ab
--- /dev/null
+++ b/arch/x86/xen/apic.c
@@ -0,0 +1,17 @@
+#include <linux/init.h>
+#include <asm/x86_init.h>
+
+unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
+{
+	if (reg == 0x1)
+		return 0x00170020;
+	else if (reg == 0x0)
+		return apic << 24;
+
+	return 0xff;
+}
+
+void __init xen_init_apic(void)
+{
+	x86_io_apic_ops.read = xen_io_apic_read;
+}
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..2e9cde8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1362,6 +1362,8 @@ asmlinkage void __init xen_start_kernel(void)
 		xen_start_info->console.domU.mfn = 0;
 		xen_start_info->console.domU.evtchn = 0;
 
+		xen_init_apic();
+
 		/* Make sure ACS will be enabled */
 		pci_request_acs();
 	}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index b095739..45c0c06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -92,11 +92,15 @@ struct dom0_vga_console_info;
 
 #ifdef CONFIG_XEN_DOM0
 void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size);
+void __init xen_init_apic(void);
 #else
 static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
 				       size_t size)
 {
 }
+static inline void __init xen_init_apic(void)
+{
+}
 #endif
 
 /* Declare an asm function, along with symbols needed to make it
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwJ-0003pG-5R; Mon, 16 Apr 2012 18:46:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwH-0003on-PF
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:13 +0000
Received: from [85.158.139.83:20021] by server-4.bemta-5.messagelabs.com id
	1D/D4-10788-4F86C8F4; Mon, 16 Apr 2012 18:46:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334601970!19466384!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6290 invoked from network); 16 Apr 2012 18:46:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:46:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjw2k015024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjv8O027731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvvO014899; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B08914032D; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:15 -0400
Message-Id: <1334601616-25309-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F8C68E8.0046,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, suresh.b.siddha@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.co,
	hpa@zytor.com, tglx@linutronix.de
Subject: [Xen-devel] [PATCH 2/3] xen/x86: Implement x86_apic_ops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Or rather just implement one different function as opposed
to the native one : the read function.

We synthesize the values.

Acked-by:  Suresh Siddha <suresh.b.siddha@intel.com>
[v1: Rebased on top of tip/x86/urgent]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/Makefile    |    2 +-
 arch/x86/xen/apic.c      |   17 +++++++++++++++++
 arch/x86/xen/enlighten.c |    2 ++
 arch/x86/xen/xen-ops.h   |    4 ++++
 4 files changed, 24 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/xen/apic.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index add2c2d..96ab2c0 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -20,5 +20,5 @@ obj-$(CONFIG_EVENT_TRACING) += trace.o
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
-obj-$(CONFIG_XEN_DOM0)		+= vga.o
+obj-$(CONFIG_XEN_DOM0)		+= apic.o vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
new file mode 100644
index 0000000..aee16ab
--- /dev/null
+++ b/arch/x86/xen/apic.c
@@ -0,0 +1,17 @@
+#include <linux/init.h>
+#include <asm/x86_init.h>
+
+unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
+{
+	if (reg == 0x1)
+		return 0x00170020;
+	else if (reg == 0x0)
+		return apic << 24;
+
+	return 0xff;
+}
+
+void __init xen_init_apic(void)
+{
+	x86_io_apic_ops.read = xen_io_apic_read;
+}
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..2e9cde8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1362,6 +1362,8 @@ asmlinkage void __init xen_start_kernel(void)
 		xen_start_info->console.domU.mfn = 0;
 		xen_start_info->console.domU.evtchn = 0;
 
+		xen_init_apic();
+
 		/* Make sure ACS will be enabled */
 		pci_request_acs();
 	}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index b095739..45c0c06 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -92,11 +92,15 @@ struct dom0_vga_console_info;
 
 #ifdef CONFIG_XEN_DOM0
 void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size);
+void __init xen_init_apic(void);
 #else
 static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
 				       size_t size)
 {
 }
+static inline void __init xen_init_apic(void)
+{
+}
 #endif
 
 /* Declare an asm function, along with symbols needed to make it
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwI-0003p8-Pa; Mon, 16 Apr 2012 18:46:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwH-0003oo-KY
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:13 +0000
Received: from [85.158.143.35:3504] by server-1.bemta-4.messagelabs.com id
	7C/DA-20925-4F86C8F4; Mon, 16 Apr 2012 18:46:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334601970!7334475!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjYxNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6812 invoked from network); 16 Apr 2012 18:46:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 18:46:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjwZM021525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjvTp027733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvKx024453; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B9D940280; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:13 -0400
Message-Id: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020209.4F8C68E8.008D,ss=1,re=0.000,fgs=0
Cc: hpa@zytor.co, tglx@linutronix.de, xen-devel@lists.xensource.com,
	suresh.b.siddha@intel.com, hpa@zytor.com
Subject: [Xen-devel] [GIT PULL] (xen) for stable/for-ingo-v3.5.v3 for v3.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey Ingo,

Please git pull the following branch for v3.5:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-ingo-v3.5.v3

It has the proper fix for the IO-APIC having 0xfffff... contents when booting under Xen.

Compared to the patch you have already in the tree (136d249ef7dbf0fefa292082cc40be1ea864cbd6
 x86/ioapic: Add io_apic_ops driver layer to allow interception) it does three things:

 1) Exposes the io_apic baremetal functions and uses the x86_io_apic_ops function table
    instead of keeping it in the io_apic. This makes the code fit within the rest of
    x86_ops functions.

 2) Use the x86_io_apic_ops to re-direct the (*read) to the Xen emulated one.

 3) Removes the work-around.

Please note, that the existing interface (136d249) can be used to do 2) as well. But the
1) makes the code more uniform by putting the function table redirection in the same
location.

Thank you!

Konrad Rzeszutek Wilk (3):
      x86/apic: Replace io_apic_ops with x86_io_apic_ops.
      xen/x86: Implement x86_apic_ops
      Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'"

 arch/x86/include/asm/io_apic.h  |   35 +++++++++++++++++++----------
 arch/x86/include/asm/x86_init.h |    9 ++++++-
 arch/x86/kernel/apic/io_apic.c  |   46 +++-----------------------------------
 arch/x86/kernel/setup.c         |    2 +-
 arch/x86/kernel/x86_init.c      |    8 ++++++
 arch/x86/xen/Makefile           |    2 +-
 arch/x86/xen/apic.c             |   17 ++++++++++++++
 arch/x86/xen/enlighten.c        |    2 +
 arch/x86/xen/mmu.c              |    4 +--
 arch/x86/xen/xen-ops.h          |    4 +++
 10 files changed, 69 insertions(+), 60 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwI-0003p8-Pa; Mon, 16 Apr 2012 18:46:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwH-0003oo-KY
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:13 +0000
Received: from [85.158.143.35:3504] by server-1.bemta-4.messagelabs.com id
	7C/DA-20925-4F86C8F4; Mon, 16 Apr 2012 18:46:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334601970!7334475!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjYxNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6812 invoked from network); 16 Apr 2012 18:46:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 18:46:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjwZM021525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjvTp027733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvKx024453; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B9D940280; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:13 -0400
Message-Id: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020209.4F8C68E8.008D,ss=1,re=0.000,fgs=0
Cc: hpa@zytor.co, tglx@linutronix.de, xen-devel@lists.xensource.com,
	suresh.b.siddha@intel.com, hpa@zytor.com
Subject: [Xen-devel] [GIT PULL] (xen) for stable/for-ingo-v3.5.v3 for v3.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey Ingo,

Please git pull the following branch for v3.5:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-ingo-v3.5.v3

It has the proper fix for the IO-APIC having 0xfffff... contents when booting under Xen.

Compared to the patch you have already in the tree (136d249ef7dbf0fefa292082cc40be1ea864cbd6
 x86/ioapic: Add io_apic_ops driver layer to allow interception) it does three things:

 1) Exposes the io_apic baremetal functions and uses the x86_io_apic_ops function table
    instead of keeping it in the io_apic. This makes the code fit within the rest of
    x86_ops functions.

 2) Use the x86_io_apic_ops to re-direct the (*read) to the Xen emulated one.

 3) Removes the work-around.

Please note, that the existing interface (136d249) can be used to do 2) as well. But the
1) makes the code more uniform by putting the function table redirection in the same
location.

Thank you!

Konrad Rzeszutek Wilk (3):
      x86/apic: Replace io_apic_ops with x86_io_apic_ops.
      xen/x86: Implement x86_apic_ops
      Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'"

 arch/x86/include/asm/io_apic.h  |   35 +++++++++++++++++++----------
 arch/x86/include/asm/x86_init.h |    9 ++++++-
 arch/x86/kernel/apic/io_apic.c  |   46 +++-----------------------------------
 arch/x86/kernel/setup.c         |    2 +-
 arch/x86/kernel/x86_init.c      |    8 ++++++
 arch/x86/xen/Makefile           |    2 +-
 arch/x86/xen/apic.c             |   17 ++++++++++++++
 arch/x86/xen/enlighten.c        |    2 +
 arch/x86/xen/mmu.c              |    4 +--
 arch/x86/xen/xen-ops.h          |    4 +++
 10 files changed, 69 insertions(+), 60 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwJ-0003pQ-IJ; Mon, 16 Apr 2012 18:46:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwI-0003or-71
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:14 +0000
Received: from [85.158.139.83:20048] by server-9.bemta-5.messagelabs.com id
	B6/63-09826-5F86C8F4; Mon, 16 Apr 2012 18:46:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334601971!16718324!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14053 invoked from network); 16 Apr 2012 18:46:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:46:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjw1d021526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjwpq027735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvDI014905; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A52EC4031D; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:14 -0400
Message-Id: <1334601616-25309-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020204.4F8C68E8.009A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, suresh.b.siddha@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.co,
	hpa@zytor.com, tglx@linutronix.de
Subject: [Xen-devel] [PATCH 1/3] x86/apic: Replace io_apic_ops with
	x86_io_apic_ops.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Which makes the code fit within the rest of the x86_ops functions.

Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
[v1: Changed x86_apic -> x86_ioapic per Yinghai Lu <yinghai@kernel.org> suggestion]
[v2: Rebased on tip/x86/urgent and redid to match Ingo's syntax style]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/io_apic.h  |   35 +++++++++++++++++++----------
 arch/x86/include/asm/x86_init.h |    9 ++++++-
 arch/x86/kernel/apic/io_apic.c  |   46 +++-----------------------------------
 arch/x86/kernel/setup.c         |    2 +-
 arch/x86/kernel/x86_init.c      |    8 ++++++
 5 files changed, 44 insertions(+), 56 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 2c4943d..73d8c53 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -5,7 +5,7 @@
 #include <asm/mpspec.h>
 #include <asm/apicdef.h>
 #include <asm/irq_vectors.h>
-
+#include <asm/x86_init.h>
 /*
  * Intel IO-APIC support for SMP and UP systems.
  *
@@ -21,15 +21,6 @@
 #define IO_APIC_REDIR_LEVEL_TRIGGER	(1 << 15)
 #define IO_APIC_REDIR_MASKED		(1 << 16)
 
-struct io_apic_ops {
-	void		(*init)  (void);
-	unsigned int	(*read)  (unsigned int apic, unsigned int reg);
-	void		(*write) (unsigned int apic, unsigned int reg, unsigned int value);
-	void		(*modify)(unsigned int apic, unsigned int reg, unsigned int value);
-};
-
-void __init set_io_apic_ops(const struct io_apic_ops *);
-
 /*
  * The structure of the IO-APIC:
  */
@@ -156,7 +147,6 @@ struct io_apic_irq_attr;
 extern int io_apic_set_pci_routing(struct device *dev, int irq,
 		 struct io_apic_irq_attr *irq_attr);
 void setup_IO_APIC_irq_extra(u32 gsi);
-extern void ioapic_and_gsi_init(void);
 extern void ioapic_insert_resources(void);
 
 int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct io_apic_irq_attr *attr);
@@ -185,12 +175,29 @@ extern void mp_save_irq(struct mpc_intsrc *m);
 
 extern void disable_ioapic_support(void);
 
+extern void __init native_io_apic_init_mappings(void);
+extern unsigned int native_io_apic_read(unsigned int apic, unsigned int reg);
+extern void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int val);
+extern void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val);
+
+static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+{
+	return x86_io_apic_ops.read(apic, reg);
+}
+
+static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
+{
+	x86_io_apic_ops.write(apic, reg, value);
+}
+static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
+{
+	x86_io_apic_ops.modify(apic, reg, value);
+}
 #else  /* !CONFIG_X86_IO_APIC */
 
 #define io_apic_assign_pci_irqs 0
 #define setup_ioapic_ids_from_mpc x86_init_noop
 static const int timer_through_8259 = 0;
-static inline void ioapic_and_gsi_init(void) { }
 static inline void ioapic_insert_resources(void) { }
 #define gsi_top (NR_IRQS_LEGACY)
 static inline int mp_find_ioapic(u32 gsi) { return 0; }
@@ -212,6 +219,10 @@ static inline int restore_ioapic_entries(void)
 
 static inline void mp_save_irq(struct mpc_intsrc *m) { };
 static inline void disable_ioapic_support(void) { }
+#define native_io_apic_init_mappings	NULL
+#define native_io_apic_read		NULL
+#define native_io_apic_write		NULL
+#define native_io_apic_modify		NULL
 #endif
 
 #endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index baaca8d..1101580 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -188,11 +188,18 @@ struct x86_msi_ops {
 	void (*restore_msi_irqs)(struct pci_dev *dev, int irq);
 };
 
+struct x86_io_apic_ops {
+	void		(*init)  (void);
+	unsigned int	(*read)  (unsigned int apic, unsigned int reg);
+	void		(*write) (unsigned int apic, unsigned int reg, unsigned int value);
+	void		(*modify)(unsigned int apic, unsigned int reg, unsigned int value);
+};
+
 extern struct x86_init_ops x86_init;
 extern struct x86_cpuinit_ops x86_cpuinit;
 extern struct x86_platform_ops x86_platform;
 extern struct x86_msi_ops x86_msi;
-
+extern struct x86_io_apic_ops x86_io_apic_ops;
 extern void x86_init_noop(void);
 extern void x86_init_uint_noop(unsigned int unused);
 extern void x86_default_fixup_cpu_id(struct cpuinfo_x86 *c, int node);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e88300d..973539c 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -68,24 +68,6 @@
 #define for_each_irq_pin(entry, head) \
 	for (entry = head; entry; entry = entry->next)
 
-static void		__init __ioapic_init_mappings(void);
-
-static unsigned int	__io_apic_read  (unsigned int apic, unsigned int reg);
-static void		__io_apic_write (unsigned int apic, unsigned int reg, unsigned int val);
-static void		__io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val);
-
-static struct io_apic_ops io_apic_ops = {
-	.init	= __ioapic_init_mappings,
-	.read	= __io_apic_read,
-	.write	= __io_apic_write,
-	.modify = __io_apic_modify,
-};
-
-void __init set_io_apic_ops(const struct io_apic_ops *ops)
-{
-	io_apic_ops = *ops;
-}
-
 /*
  *      Is the SiS APIC rmw bug present ?
  *      -1 = don't know, 0 = no, 1 = yes
@@ -313,21 +295,6 @@ static void free_irq_at(unsigned int at, struct irq_cfg *cfg)
 	irq_free_desc(at);
 }
 
-static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
-{
-	return io_apic_ops.read(apic, reg);
-}
-
-static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
-{
-	io_apic_ops.write(apic, reg, value);
-}
-
-static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
-{
-	io_apic_ops.modify(apic, reg, value);
-}
-
 
 struct io_apic {
 	unsigned int index;
@@ -349,14 +316,14 @@ static inline void io_apic_eoi(unsigned int apic, unsigned int vector)
 	writel(vector, &io_apic->eoi);
 }
 
-static unsigned int __io_apic_read(unsigned int apic, unsigned int reg)
+unsigned int native_io_apic_read(unsigned int apic, unsigned int reg)
 {
 	struct io_apic __iomem *io_apic = io_apic_base(apic);
 	writel(reg, &io_apic->index);
 	return readl(&io_apic->data);
 }
 
-static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
+void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
 {
 	struct io_apic __iomem *io_apic = io_apic_base(apic);
 
@@ -370,7 +337,7 @@ static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int va
  *
  * Older SiS APIC requires we rewrite the index register
  */
-static void __io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
+void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
 {
 	struct io_apic __iomem *io_apic = io_apic_base(apic);
 
@@ -3931,12 +3898,7 @@ static struct resource * __init ioapic_setup_resources(int nr_ioapics)
 	return res;
 }
 
-void __init ioapic_and_gsi_init(void)
-{
-	io_apic_ops.init();
-}
-
-static void __init __ioapic_init_mappings(void)
+void __init native_io_apic_init_mappings(void)
 {
 	unsigned long ioapic_phys, idx = FIX_IO_APIC_BASE_0;
 	struct resource *ioapic_res;
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1a29015..8526317 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p)
 	init_cpu_to_node();
 
 	init_apic_mappings();
-	ioapic_and_gsi_init();
+	x86_io_apic_ops.init();
 
 	kvm_guest_init();
 
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index e9f265f..b108682 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -18,6 +18,7 @@
 #include <asm/e820.h>
 #include <asm/time.h>
 #include <asm/irq.h>
+#include <asm/io_apic.h>
 #include <asm/pat.h>
 #include <asm/tsc.h>
 #include <asm/iommu.h>
@@ -120,3 +121,10 @@ struct x86_msi_ops x86_msi = {
 	.teardown_msi_irqs = default_teardown_msi_irqs,
 	.restore_msi_irqs = default_restore_msi_irqs,
 };
+
+struct x86_io_apic_ops x86_io_apic_ops = {
+	.init	= native_io_apic_init_mappings,
+	.read	= native_io_apic_read,
+	.write	= native_io_apic_write,
+	.modify	= native_io_apic_modify,
+};
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwJ-0003pQ-IJ; Mon, 16 Apr 2012 18:46:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwI-0003or-71
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:14 +0000
Received: from [85.158.139.83:20048] by server-9.bemta-5.messagelabs.com id
	B6/63-09826-5F86C8F4; Mon, 16 Apr 2012 18:46:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334601971!16718324!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14053 invoked from network); 16 Apr 2012 18:46:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:46:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjw1d021526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjwpq027735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvDI014905; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A52EC4031D; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:14 -0400
Message-Id: <1334601616-25309-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020204.4F8C68E8.009A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, suresh.b.siddha@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.co,
	hpa@zytor.com, tglx@linutronix.de
Subject: [Xen-devel] [PATCH 1/3] x86/apic: Replace io_apic_ops with
	x86_io_apic_ops.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Which makes the code fit within the rest of the x86_ops functions.

Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
[v1: Changed x86_apic -> x86_ioapic per Yinghai Lu <yinghai@kernel.org> suggestion]
[v2: Rebased on tip/x86/urgent and redid to match Ingo's syntax style]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/io_apic.h  |   35 +++++++++++++++++++----------
 arch/x86/include/asm/x86_init.h |    9 ++++++-
 arch/x86/kernel/apic/io_apic.c  |   46 +++-----------------------------------
 arch/x86/kernel/setup.c         |    2 +-
 arch/x86/kernel/x86_init.c      |    8 ++++++
 5 files changed, 44 insertions(+), 56 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 2c4943d..73d8c53 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -5,7 +5,7 @@
 #include <asm/mpspec.h>
 #include <asm/apicdef.h>
 #include <asm/irq_vectors.h>
-
+#include <asm/x86_init.h>
 /*
  * Intel IO-APIC support for SMP and UP systems.
  *
@@ -21,15 +21,6 @@
 #define IO_APIC_REDIR_LEVEL_TRIGGER	(1 << 15)
 #define IO_APIC_REDIR_MASKED		(1 << 16)
 
-struct io_apic_ops {
-	void		(*init)  (void);
-	unsigned int	(*read)  (unsigned int apic, unsigned int reg);
-	void		(*write) (unsigned int apic, unsigned int reg, unsigned int value);
-	void		(*modify)(unsigned int apic, unsigned int reg, unsigned int value);
-};
-
-void __init set_io_apic_ops(const struct io_apic_ops *);
-
 /*
  * The structure of the IO-APIC:
  */
@@ -156,7 +147,6 @@ struct io_apic_irq_attr;
 extern int io_apic_set_pci_routing(struct device *dev, int irq,
 		 struct io_apic_irq_attr *irq_attr);
 void setup_IO_APIC_irq_extra(u32 gsi);
-extern void ioapic_and_gsi_init(void);
 extern void ioapic_insert_resources(void);
 
 int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct io_apic_irq_attr *attr);
@@ -185,12 +175,29 @@ extern void mp_save_irq(struct mpc_intsrc *m);
 
 extern void disable_ioapic_support(void);
 
+extern void __init native_io_apic_init_mappings(void);
+extern unsigned int native_io_apic_read(unsigned int apic, unsigned int reg);
+extern void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int val);
+extern void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val);
+
+static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+{
+	return x86_io_apic_ops.read(apic, reg);
+}
+
+static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
+{
+	x86_io_apic_ops.write(apic, reg, value);
+}
+static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
+{
+	x86_io_apic_ops.modify(apic, reg, value);
+}
 #else  /* !CONFIG_X86_IO_APIC */
 
 #define io_apic_assign_pci_irqs 0
 #define setup_ioapic_ids_from_mpc x86_init_noop
 static const int timer_through_8259 = 0;
-static inline void ioapic_and_gsi_init(void) { }
 static inline void ioapic_insert_resources(void) { }
 #define gsi_top (NR_IRQS_LEGACY)
 static inline int mp_find_ioapic(u32 gsi) { return 0; }
@@ -212,6 +219,10 @@ static inline int restore_ioapic_entries(void)
 
 static inline void mp_save_irq(struct mpc_intsrc *m) { };
 static inline void disable_ioapic_support(void) { }
+#define native_io_apic_init_mappings	NULL
+#define native_io_apic_read		NULL
+#define native_io_apic_write		NULL
+#define native_io_apic_modify		NULL
 #endif
 
 #endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index baaca8d..1101580 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -188,11 +188,18 @@ struct x86_msi_ops {
 	void (*restore_msi_irqs)(struct pci_dev *dev, int irq);
 };
 
+struct x86_io_apic_ops {
+	void		(*init)  (void);
+	unsigned int	(*read)  (unsigned int apic, unsigned int reg);
+	void		(*write) (unsigned int apic, unsigned int reg, unsigned int value);
+	void		(*modify)(unsigned int apic, unsigned int reg, unsigned int value);
+};
+
 extern struct x86_init_ops x86_init;
 extern struct x86_cpuinit_ops x86_cpuinit;
 extern struct x86_platform_ops x86_platform;
 extern struct x86_msi_ops x86_msi;
-
+extern struct x86_io_apic_ops x86_io_apic_ops;
 extern void x86_init_noop(void);
 extern void x86_init_uint_noop(unsigned int unused);
 extern void x86_default_fixup_cpu_id(struct cpuinfo_x86 *c, int node);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e88300d..973539c 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -68,24 +68,6 @@
 #define for_each_irq_pin(entry, head) \
 	for (entry = head; entry; entry = entry->next)
 
-static void		__init __ioapic_init_mappings(void);
-
-static unsigned int	__io_apic_read  (unsigned int apic, unsigned int reg);
-static void		__io_apic_write (unsigned int apic, unsigned int reg, unsigned int val);
-static void		__io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val);
-
-static struct io_apic_ops io_apic_ops = {
-	.init	= __ioapic_init_mappings,
-	.read	= __io_apic_read,
-	.write	= __io_apic_write,
-	.modify = __io_apic_modify,
-};
-
-void __init set_io_apic_ops(const struct io_apic_ops *ops)
-{
-	io_apic_ops = *ops;
-}
-
 /*
  *      Is the SiS APIC rmw bug present ?
  *      -1 = don't know, 0 = no, 1 = yes
@@ -313,21 +295,6 @@ static void free_irq_at(unsigned int at, struct irq_cfg *cfg)
 	irq_free_desc(at);
 }
 
-static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
-{
-	return io_apic_ops.read(apic, reg);
-}
-
-static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
-{
-	io_apic_ops.write(apic, reg, value);
-}
-
-static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
-{
-	io_apic_ops.modify(apic, reg, value);
-}
-
 
 struct io_apic {
 	unsigned int index;
@@ -349,14 +316,14 @@ static inline void io_apic_eoi(unsigned int apic, unsigned int vector)
 	writel(vector, &io_apic->eoi);
 }
 
-static unsigned int __io_apic_read(unsigned int apic, unsigned int reg)
+unsigned int native_io_apic_read(unsigned int apic, unsigned int reg)
 {
 	struct io_apic __iomem *io_apic = io_apic_base(apic);
 	writel(reg, &io_apic->index);
 	return readl(&io_apic->data);
 }
 
-static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
+void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
 {
 	struct io_apic __iomem *io_apic = io_apic_base(apic);
 
@@ -370,7 +337,7 @@ static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int va
  *
  * Older SiS APIC requires we rewrite the index register
  */
-static void __io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
+void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value)
 {
 	struct io_apic __iomem *io_apic = io_apic_base(apic);
 
@@ -3931,12 +3898,7 @@ static struct resource * __init ioapic_setup_resources(int nr_ioapics)
 	return res;
 }
 
-void __init ioapic_and_gsi_init(void)
-{
-	io_apic_ops.init();
-}
-
-static void __init __ioapic_init_mappings(void)
+void __init native_io_apic_init_mappings(void)
 {
 	unsigned long ioapic_phys, idx = FIX_IO_APIC_BASE_0;
 	struct resource *ioapic_res;
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1a29015..8526317 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p)
 	init_cpu_to_node();
 
 	init_apic_mappings();
-	ioapic_and_gsi_init();
+	x86_io_apic_ops.init();
 
 	kvm_guest_init();
 
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index e9f265f..b108682 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -18,6 +18,7 @@
 #include <asm/e820.h>
 #include <asm/time.h>
 #include <asm/irq.h>
+#include <asm/io_apic.h>
 #include <asm/pat.h>
 #include <asm/tsc.h>
 #include <asm/iommu.h>
@@ -120,3 +121,10 @@ struct x86_msi_ops x86_msi = {
 	.teardown_msi_irqs = default_teardown_msi_irqs,
 	.restore_msi_irqs = default_restore_msi_irqs,
 };
+
+struct x86_io_apic_ops x86_io_apic_ops = {
+	.init	= native_io_apic_init_mappings,
+	.read	= native_io_apic_read,
+	.write	= native_io_apic_write,
+	.modify	= native_io_apic_modify,
+};
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwK-0003pm-Vr; Mon, 16 Apr 2012 18:46:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwJ-0003pI-Nw
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:15 +0000
Received: from [85.158.138.51:49739] by server-3.bemta-3.messagelabs.com id
	B2/1A-04048-6F86C8F4; Mon, 16 Apr 2012 18:46:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334601971!22209587!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24198 invoked from network); 16 Apr 2012 18:46:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:46:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjwsE015025
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjwsq021190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvlo024462; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B898640357; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:16 -0400
Message-Id: <1334601616-25309-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090206.4F8C68E8.0060,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, suresh.b.siddha@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.co,
	hpa@zytor.com, tglx@linutronix.de
Subject: [Xen-devel] [PATCH 3/3] Revert "xen/x86: Workaround 'x86/ioapic:
	Add register level checks to detect bogus io-apic entries'"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This reverts commit 2531d64b6fe2724dc432b67d8dc66bd45621da0b.

The two patches:
      x86/apic: Replace io_apic_ops with x86_io_apic_ops.
      xen/x86: Implement x86_apic_ops

take care of fixing it properly.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b8e2794..988828b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1859,7 +1859,6 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
 #endif	/* CONFIG_X86_64 */
 
 static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;
-static unsigned char fake_ioapic_mapping[PAGE_SIZE] __page_aligned_bss;
 
 static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 {
@@ -1900,7 +1899,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 		 * We just don't map the IO APIC - all access is via
 		 * hypercalls.  Keep the address in the pte for reference.
 		 */
-		pte = pfn_pte(PFN_DOWN(__pa(fake_ioapic_mapping)), PAGE_KERNEL);
+		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
 		break;
 #endif
 
@@ -2065,7 +2064,6 @@ void __init xen_init_mmu_ops(void)
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
-	memset(fake_ioapic_mapping, 0xfd, PAGE_SIZE);
 }
 
 /* Protected by xen_reservation_lock. */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 18:46:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 18:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJqwK-0003pm-Vr; Mon, 16 Apr 2012 18:46:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJqwJ-0003pI-Nw
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:46:15 +0000
Received: from [85.158.138.51:49739] by server-3.bemta-3.messagelabs.com id
	B2/1A-04048-6F86C8F4; Mon, 16 Apr 2012 18:46:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334601971!22209587!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24198 invoked from network); 16 Apr 2012 18:46:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:46:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GIjwsE015025
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 18:45:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GIjwsq021190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 18:45:58 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GIjvlo024462; Mon, 16 Apr 2012 13:45:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 11:45:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B898640357; Mon, 16 Apr 2012 14:40:59 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Date: Mon, 16 Apr 2012 14:40:16 -0400
Message-Id: <1334601616-25309-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090206.4F8C68E8.0060,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, suresh.b.siddha@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.co,
	hpa@zytor.com, tglx@linutronix.de
Subject: [Xen-devel] [PATCH 3/3] Revert "xen/x86: Workaround 'x86/ioapic:
	Add register level checks to detect bogus io-apic entries'"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This reverts commit 2531d64b6fe2724dc432b67d8dc66bd45621da0b.

The two patches:
      x86/apic: Replace io_apic_ops with x86_io_apic_ops.
      xen/x86: Implement x86_apic_ops

take care of fixing it properly.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b8e2794..988828b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1859,7 +1859,6 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
 #endif	/* CONFIG_X86_64 */
 
 static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;
-static unsigned char fake_ioapic_mapping[PAGE_SIZE] __page_aligned_bss;
 
 static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 {
@@ -1900,7 +1899,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 		 * We just don't map the IO APIC - all access is via
 		 * hypercalls.  Keep the address in the pte for reference.
 		 */
-		pte = pfn_pte(PFN_DOWN(__pa(fake_ioapic_mapping)), PAGE_KERNEL);
+		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
 		break;
 #endif
 
@@ -2065,7 +2064,6 @@ void __init xen_init_mmu_ops(void)
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
-	memset(fake_ioapic_mapping, 0xfd, PAGE_SIZE);
 }
 
 /* Protected by xen_reservation_lock. */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:04:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrE3-0004zj-JE; Mon, 16 Apr 2012 19:04:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1SJrE2-0004ze-1W
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 19:04:34 +0000
Received: from [193.109.254.147:49606] by server-11.bemta-14.messagelabs.com
	id 42/4D-05858-14D6C8F4; Mon, 16 Apr 2012 19:04:33 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334603072!4856520!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA3OTEzNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17356 invoked from network); 16 Apr 2012 19:04:32 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 19:04:32 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q3GJ4Hre031342
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:04:21 +0100
Received: from vega-b.dur.ac.uk (vega-b.dur.ac.uk [129.234.250.134])
	by smtphost1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q3GJ3x03004496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:03:59 +0100
Received: from vega-b.dur.ac.uk (localhost [127.0.0.1])
	by vega-b.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q3GJ3xpi013879
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:03:59 +0100
Received: from localhost (dcl0may@localhost)
	by vega-b.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q3GJ3xal013875
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:03:59 +0100
Date: Mon, 16 Apr 2012 20:03:59 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-435547570-1334603039=:5305"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q3GJ4Hre031342
Subject: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-435547570-1334603039=:5305
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

There is a Fedora bug report 
https://bugzilla.redhat.com/show_bug.cgi?id=812421 reporting that openvpn 
is having problems because of the line
SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
in /etc/udev/rules.d/xen-backend.rules which is causing the xen script to 
run when openvpn tries to use a tap device, causing it to fail. I have 
used the attached patch to solve this problem, by matching the form of the 
tap device that xen uses more exactly to avoid to openvpn case. A better 
long-term solution (suggested in one of the comments in the bug) might be 
to use a more specific name instead of "tap" so we have less chance of 
interfering with another application.

 	Michael Young

--8323329-435547570-1334603039=:5305
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xen-backend.rules.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xen-backend.rules.patch

VGhlIHVkZXYgdGFwIHhlbiBiYWNrZW5kIHJ1bGUgaW50ZXJmZXJlcyB3aXRo
IG9wZW52cG4uIE1ha2UgdGhlIG1hdGNoIGNvbmRpdGlvbiANCm1vcmUgc3Bl
Y2lmaWMgdG8geGVuIHNvIGl0IGRvZXNuJ3QgbWF0Y2ggdGhlIG9wZW52cG4g
dGFwIGRldmljZS4NCg0KU2lnbmVkLW9mZi1ieTogTWljaGFlbCBZb3VuZyA8
bS5hLnlvdW5nQGR1cmhhbS5hYy51az4NCg0KLS0tIHhlbi00LjEuMi90b29s
cy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzLm9yaWcJMjAxMS0x
MC0yMCAxODowNTo0Mi4wMDAwMDAwMDAgKzAxMDANCisrKyB4ZW4tNC4xLjIv
dG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcwkyMDEyLTA0
LTE1IDE3OjA4OjI0Ljc3NDk1NTkzMiArMDEwMA0KQEAgLTEzLDQgKzEzLDQg
QEANCiBLRVJORUw9PSJnbnRkZXYiLCBOQU1FPSJ4ZW4vJWsiLCBNT0RFPSIw
NjAwIg0KIEtFUk5FTD09InBjaV9pb211bCIsIE5BTUU9Inhlbi8layIsIE1P
REU9IjA2MDAiDQogS0VSTkVMPT0idGFwZGV2W2Etel0qIiwgTkFNRT0ieGVu
L2Jsa3RhcC0yL3RhcGRldiVtIiwgTU9ERT0iMDYwMCINCi1TVUJTWVNURU09
PSJuZXQiLCBLRVJORUw9PSJ0YXAqIiwgQUNUSU9OPT0iYWRkIiwgUlVOKz0i
L2V0Yy94ZW4vc2NyaXB0cy92aWYtc2V0dXAgJGVudntBQ1RJT059IHR5cGVf
aWY9dGFwIg0KK1NVQlNZU1RFTT09Im5ldCIsIEtFUk5FTD09InRhcFswLTld
Ki5bMC05XSoiLCBBQ1RJT049PSJhZGQiLCBSVU4rPSIvZXRjL3hlbi9zY3Jp
cHRzL3ZpZi1zZXR1cCAkZW52e0FDVElPTn0gdHlwZV9pZj10YXAiDQo=

--8323329-435547570-1334603039=:5305
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-435547570-1334603039=:5305--


From xen-devel-bounces@lists.xen.org Mon Apr 16 19:04:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrE3-0004zj-JE; Mon, 16 Apr 2012 19:04:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1SJrE2-0004ze-1W
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 19:04:34 +0000
Received: from [193.109.254.147:49606] by server-11.bemta-14.messagelabs.com
	id 42/4D-05858-14D6C8F4; Mon, 16 Apr 2012 19:04:33 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334603072!4856520!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA3OTEzNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17356 invoked from network); 16 Apr 2012 19:04:32 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 19:04:32 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q3GJ4Hre031342
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:04:21 +0100
Received: from vega-b.dur.ac.uk (vega-b.dur.ac.uk [129.234.250.134])
	by smtphost1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q3GJ3x03004496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:03:59 +0100
Received: from vega-b.dur.ac.uk (localhost [127.0.0.1])
	by vega-b.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q3GJ3xpi013879
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:03:59 +0100
Received: from localhost (dcl0may@localhost)
	by vega-b.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q3GJ3xal013875
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 20:03:59 +0100
Date: Mon, 16 Apr 2012 20:03:59 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-435547570-1334603039=:5305"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q3GJ4Hre031342
Subject: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-435547570-1334603039=:5305
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

There is a Fedora bug report 
https://bugzilla.redhat.com/show_bug.cgi?id=812421 reporting that openvpn 
is having problems because of the line
SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
in /etc/udev/rules.d/xen-backend.rules which is causing the xen script to 
run when openvpn tries to use a tap device, causing it to fail. I have 
used the attached patch to solve this problem, by matching the form of the 
tap device that xen uses more exactly to avoid to openvpn case. A better 
long-term solution (suggested in one of the comments in the bug) might be 
to use a more specific name instead of "tap" so we have less chance of 
interfering with another application.

 	Michael Young

--8323329-435547570-1334603039=:5305
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xen-backend.rules.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=xen-backend.rules.patch

VGhlIHVkZXYgdGFwIHhlbiBiYWNrZW5kIHJ1bGUgaW50ZXJmZXJlcyB3aXRo
IG9wZW52cG4uIE1ha2UgdGhlIG1hdGNoIGNvbmRpdGlvbiANCm1vcmUgc3Bl
Y2lmaWMgdG8geGVuIHNvIGl0IGRvZXNuJ3QgbWF0Y2ggdGhlIG9wZW52cG4g
dGFwIGRldmljZS4NCg0KU2lnbmVkLW9mZi1ieTogTWljaGFlbCBZb3VuZyA8
bS5hLnlvdW5nQGR1cmhhbS5hYy51az4NCg0KLS0tIHhlbi00LjEuMi90b29s
cy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzLm9yaWcJMjAxMS0x
MC0yMCAxODowNTo0Mi4wMDAwMDAwMDAgKzAxMDANCisrKyB4ZW4tNC4xLjIv
dG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcwkyMDEyLTA0
LTE1IDE3OjA4OjI0Ljc3NDk1NTkzMiArMDEwMA0KQEAgLTEzLDQgKzEzLDQg
QEANCiBLRVJORUw9PSJnbnRkZXYiLCBOQU1FPSJ4ZW4vJWsiLCBNT0RFPSIw
NjAwIg0KIEtFUk5FTD09InBjaV9pb211bCIsIE5BTUU9Inhlbi8layIsIE1P
REU9IjA2MDAiDQogS0VSTkVMPT0idGFwZGV2W2Etel0qIiwgTkFNRT0ieGVu
L2Jsa3RhcC0yL3RhcGRldiVtIiwgTU9ERT0iMDYwMCINCi1TVUJTWVNURU09
PSJuZXQiLCBLRVJORUw9PSJ0YXAqIiwgQUNUSU9OPT0iYWRkIiwgUlVOKz0i
L2V0Yy94ZW4vc2NyaXB0cy92aWYtc2V0dXAgJGVudntBQ1RJT059IHR5cGVf
aWY9dGFwIg0KK1NVQlNZU1RFTT09Im5ldCIsIEtFUk5FTD09InRhcFswLTld
Ki5bMC05XSoiLCBBQ1RJT049PSJhZGQiLCBSVU4rPSIvZXRjL3hlbi9zY3Jp
cHRzL3ZpZi1zZXR1cCAkZW52e0FDVElPTn0gdHlwZV9pZj10YXAiDQo=

--8323329-435547570-1334603039=:5305
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-435547570-1334603039=:5305--


From xen-devel-bounces@lists.xen.org Mon Apr 16 19:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrXa-0005QP-El; Mon, 16 Apr 2012 19:24:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJrXY-0005QK-Cb
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:24:44 +0000
Received: from [85.158.143.99:51015] by server-1.bemta-4.messagelabs.com id
	9D/EF-20925-BF17C8F4; Mon, 16 Apr 2012 19:24:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334604281!22984184!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21441 invoked from network); 16 Apr 2012 19:24:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 19:24:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GJOTS2009935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 19:24:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GJORxr020979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 19:24:28 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GJOQe3020797; Mon, 16 Apr 2012 14:24:26 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 12:24:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBCEE40280; Mon, 16 Apr 2012 15:19:28 -0400 (EDT)
Date: Mon, 16 Apr 2012 15:19:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Message-ID: <20120416191928.GA25676@phenom.dumpdata.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8C71EE.00AE,ss=1,re=0.000,fgs=0
Cc: hpa@zytor.co, tglx@linutronix.de, xen-devel@lists.xensource.com,
	suresh.b.siddha@intel.com, hpa@zytor.com
Subject: Re: [Xen-devel] [GIT PULL] (xen) for stable/for-ingo-v3.5.v3 for
	v3.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 02:40:13PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey Ingo,
> 
> Please git pull the following branch for v3.5:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-ingo-v3.5.v3
> 
> It has the proper fix for the IO-APIC having 0xfffff... contents when booting under Xen.
> 
> Compared to the patch you have already in the tree (136d249ef7dbf0fefa292082cc40be1ea864cbd6
>  x86/ioapic: Add io_apic_ops driver layer to allow interception) it does three things:
> 
>  1) Exposes the io_apic baremetal functions and uses the x86_io_apic_ops function table
>     instead of keeping it in the io_apic. This makes the code fit within the rest of
>     x86_ops functions.
> 
>  2) Use the x86_io_apic_ops to re-direct the (*read) to the Xen emulated one.
> 
>  3) Removes the work-around.
> 
> Please note, that the existing interface (136d249) can be used to do 2) as well. But the

.. If the __ioapic_init_mappings is made visible (so that we can call it in the Xen's
version of io_apic_ops.init() - as we want to re-use as much as possible of the generic
code:

commit fa45ea06ab785ce82644980befc7e983f884f72a
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Apr 16 14:50:02 2012 -0400

    x86/io_apic: Make __ioapic_init_mappings visible to other sub-systems.
    
    This way, we can re-use as much as possible of the generic code as possible
    and re-use the generic initialization.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 2c4943d..e75979c 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -157,6 +157,7 @@ extern int io_apic_set_pci_routing(struct device *dev, int irq,
 		 struct io_apic_irq_attr *irq_attr);
 void setup_IO_APIC_irq_extra(u32 gsi);
 extern void ioapic_and_gsi_init(void);
+extern void __ioapic_init_mappings(void);
 extern void ioapic_insert_resources(void);
 
 int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct io_apic_irq_attr *attr);
@@ -191,6 +192,7 @@ extern void disable_ioapic_support(void);
 #define setup_ioapic_ids_from_mpc x86_init_noop
 static const int timer_through_8259 = 0;
 static inline void ioapic_and_gsi_init(void) { }
+static inline void __ioapic_init_mappings(void) { }
 static inline void ioapic_insert_resources(void) { }
 #define gsi_top (NR_IRQS_LEGACY)
 static inline int mp_find_ioapic(u32 gsi) { return 0; }
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e88300d..58e6986 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -68,8 +68,6 @@
 #define for_each_irq_pin(entry, head) \
 	for (entry = head; entry; entry = entry->next)
 
-static void		__init __ioapic_init_mappings(void);
-
 static unsigned int	__io_apic_read  (unsigned int apic, unsigned int reg);
 static void		__io_apic_write (unsigned int apic, unsigned int reg, unsigned int val);
 static void		__io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val);
@@ -3936,7 +3934,7 @@ void __init ioapic_and_gsi_init(void)
 	io_apic_ops.init();
 }
 
-static void __init __ioapic_init_mappings(void)
+void __init __ioapic_init_mappings(void)
 {
 	unsigned long ioapic_phys, idx = FIX_IO_APIC_BASE_0;
 	struct resource *ioapic_res;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrXa-0005QP-El; Mon, 16 Apr 2012 19:24:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJrXY-0005QK-Cb
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:24:44 +0000
Received: from [85.158.143.99:51015] by server-1.bemta-4.messagelabs.com id
	9D/EF-20925-BF17C8F4; Mon, 16 Apr 2012 19:24:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334604281!22984184!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21441 invoked from network); 16 Apr 2012 19:24:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 19:24:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GJOTS2009935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 19:24:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GJORxr020979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 19:24:28 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GJOQe3020797; Mon, 16 Apr 2012 14:24:26 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 12:24:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBCEE40280; Mon, 16 Apr 2012 15:19:28 -0400 (EDT)
Date: Mon, 16 Apr 2012 15:19:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, mingo@kernel.org
Message-ID: <20120416191928.GA25676@phenom.dumpdata.com>
References: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334601616-25309-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F8C71EE.00AE,ss=1,re=0.000,fgs=0
Cc: hpa@zytor.co, tglx@linutronix.de, xen-devel@lists.xensource.com,
	suresh.b.siddha@intel.com, hpa@zytor.com
Subject: Re: [Xen-devel] [GIT PULL] (xen) for stable/for-ingo-v3.5.v3 for
	v3.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 02:40:13PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey Ingo,
> 
> Please git pull the following branch for v3.5:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-ingo-v3.5.v3
> 
> It has the proper fix for the IO-APIC having 0xfffff... contents when booting under Xen.
> 
> Compared to the patch you have already in the tree (136d249ef7dbf0fefa292082cc40be1ea864cbd6
>  x86/ioapic: Add io_apic_ops driver layer to allow interception) it does three things:
> 
>  1) Exposes the io_apic baremetal functions and uses the x86_io_apic_ops function table
>     instead of keeping it in the io_apic. This makes the code fit within the rest of
>     x86_ops functions.
> 
>  2) Use the x86_io_apic_ops to re-direct the (*read) to the Xen emulated one.
> 
>  3) Removes the work-around.
> 
> Please note, that the existing interface (136d249) can be used to do 2) as well. But the

.. If the __ioapic_init_mappings is made visible (so that we can call it in the Xen's
version of io_apic_ops.init() - as we want to re-use as much as possible of the generic
code:

commit fa45ea06ab785ce82644980befc7e983f884f72a
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Apr 16 14:50:02 2012 -0400

    x86/io_apic: Make __ioapic_init_mappings visible to other sub-systems.
    
    This way, we can re-use as much as possible of the generic code as possible
    and re-use the generic initialization.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 2c4943d..e75979c 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -157,6 +157,7 @@ extern int io_apic_set_pci_routing(struct device *dev, int irq,
 		 struct io_apic_irq_attr *irq_attr);
 void setup_IO_APIC_irq_extra(u32 gsi);
 extern void ioapic_and_gsi_init(void);
+extern void __ioapic_init_mappings(void);
 extern void ioapic_insert_resources(void);
 
 int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct io_apic_irq_attr *attr);
@@ -191,6 +192,7 @@ extern void disable_ioapic_support(void);
 #define setup_ioapic_ids_from_mpc x86_init_noop
 static const int timer_through_8259 = 0;
 static inline void ioapic_and_gsi_init(void) { }
+static inline void __ioapic_init_mappings(void) { }
 static inline void ioapic_insert_resources(void) { }
 #define gsi_top (NR_IRQS_LEGACY)
 static inline int mp_find_ioapic(u32 gsi) { return 0; }
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e88300d..58e6986 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -68,8 +68,6 @@
 #define for_each_irq_pin(entry, head) \
 	for (entry = head; entry; entry = entry->next)
 
-static void		__init __ioapic_init_mappings(void);
-
 static unsigned int	__io_apic_read  (unsigned int apic, unsigned int reg);
 static void		__io_apic_write (unsigned int apic, unsigned int reg, unsigned int val);
 static void		__io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val);
@@ -3936,7 +3934,7 @@ void __init ioapic_and_gsi_init(void)
 	io_apic_ops.init();
 }
 
-static void __init __ioapic_init_mappings(void)
+void __init __ioapic_init_mappings(void)
 {
 	unsigned long ioapic_phys, idx = FIX_IO_APIC_BASE_0;
 	struct resource *ioapic_res;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:32:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJreH-0005ck-Av; Mon, 16 Apr 2012 19:31:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJreF-0005cf-V2
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:31:40 +0000
Received: from [85.158.139.83:10519] by server-9.bemta-5.messagelabs.com id
	8D/9D-09826-B937C8F4; Mon, 16 Apr 2012 19:31:39 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334604697!19799202!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15660 invoked from network); 16 Apr 2012 19:31:38 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-14.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Apr 2012 19:31:38 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJreA-0007pr-AP
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:31:34 +0200
Received: from 94.103.167.176 ([94.103.167.176])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:31:34 +0200
Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:31:34 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 19:31:25 +0000 (UTC)
Lines: 19
Message-ID: <loom.20120416T212343-893@post.gmane.org>
References: <loom.20120416T171925-109@post.gmane.org>
	<1334591061.14560.213.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:11.0) Gecko/20100101 Firefox/11.0)
Subject: Re: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell <Ian.Campbell <at> citrix.com> writes:

> I can't see any support for nested HVM of any sort in 4.1. AFAIK it is
> going to be an (experimental) feature in 4.2.
> 
> Ian.


My fault, I was looking at config options here
http://www.xen.org/support/generated.html to get used to xl (always using xm
before). I wasn't paying attention to the note above that this is for unstable
only...


Thanks for the hint!


Best regards,
   Christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:32:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJreH-0005ck-Av; Mon, 16 Apr 2012 19:31:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJreF-0005cf-V2
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:31:40 +0000
Received: from [85.158.139.83:10519] by server-9.bemta-5.messagelabs.com id
	8D/9D-09826-B937C8F4; Mon, 16 Apr 2012 19:31:39 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334604697!19799202!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15660 invoked from network); 16 Apr 2012 19:31:38 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-14.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Apr 2012 19:31:38 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJreA-0007pr-AP
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:31:34 +0200
Received: from 94.103.167.176 ([94.103.167.176])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:31:34 +0200
Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:31:34 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 19:31:25 +0000 (UTC)
Lines: 19
Message-ID: <loom.20120416T212343-893@post.gmane.org>
References: <loom.20120416T171925-109@post.gmane.org>
	<1334591061.14560.213.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:11.0) Gecko/20100101 Firefox/11.0)
Subject: Re: [Xen-devel] Status of nestedhvm (on Intel)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell <Ian.Campbell <at> citrix.com> writes:

> I can't see any support for nested HVM of any sort in 4.1. AFAIK it is
> going to be an (experimental) feature in 4.2.
> 
> Ian.


My fault, I was looking at config options here
http://www.xen.org/support/generated.html to get used to xl (always using xm
before). I wasn't paying attention to the note above that this is for unstable
only...


Thanks for the hint!


Best regards,
   Christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrju-0005kI-44; Mon, 16 Apr 2012 19:37:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJrjs-0005kD-OS
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 19:37:28 +0000
Received: from [85.158.139.83:20472] by server-12.bemta-5.messagelabs.com id
	F0/7C-05587-7F47C8F4; Mon, 16 Apr 2012 19:37:27 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334605045!24076121!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25078 invoked from network); 16 Apr 2012 19:37:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 19:37:27 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GJbKKx027826
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 19:37:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GJbJ2X015799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 19:37:20 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GJbJIx023534; Mon, 16 Apr 2012 14:37:19 -0500
MIME-Version: 1.0
Message-ID: <86afad50-a6a2-4b10-b2e3-f675215d003d@default>
Date: Mon, 16 Apr 2012 12:37:11 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
In-Reply-To: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020204.4F8C74F1.00C6,ss=1,re=0.000,fgs=0
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and
 associated xl command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Subject: [PATCH] libxl: Remove libxl_tmem_destroy and associated xl command
> 
> 
> Accordingly remove this interface from libxl and xl but don't touch libxc or
> the hypervisor.
> 
> This is the only libxl_tmem_* function which might potentially have required
> conversion to be asynchronous and which therefore might have been a potential
> API stability concern.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Thanks for handling this!

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrju-0005kI-44; Mon, 16 Apr 2012 19:37:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJrjs-0005kD-OS
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 19:37:28 +0000
Received: from [85.158.139.83:20472] by server-12.bemta-5.messagelabs.com id
	F0/7C-05587-7F47C8F4; Mon, 16 Apr 2012 19:37:27 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334605045!24076121!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25078 invoked from network); 16 Apr 2012 19:37:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 19:37:27 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GJbKKx027826
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 19:37:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GJbJ2X015799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 19:37:20 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GJbJIx023534; Mon, 16 Apr 2012 14:37:19 -0500
MIME-Version: 1.0
Message-ID: <86afad50-a6a2-4b10-b2e3-f675215d003d@default>
Date: Mon, 16 Apr 2012 12:37:11 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
References: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
In-Reply-To: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020204.4F8C74F1.00C6,ss=1,re=0.000,fgs=0
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and
 associated xl command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Subject: [PATCH] libxl: Remove libxl_tmem_destroy and associated xl command
> 
> 
> Accordingly remove this interface from libxl and xl but don't touch libxc or
> the hypervisor.
> 
> This is the only libxl_tmem_* function which might potentially have required
> conversion to be asynchronous and which therefore might have been a potential
> API stability concern.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Thanks for handling this!

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:44:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:44:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrq3-0005tx-Ts; Mon, 16 Apr 2012 19:43:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJrq2-0005ts-Ai
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:43:50 +0000
Received: from [85.158.143.99:13317] by server-1.bemta-4.messagelabs.com id
	00/1A-20925-5767C8F4; Mon, 16 Apr 2012 19:43:49 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334605427!22985869!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4720 invoked from network); 16 Apr 2012 19:43:48 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Apr 2012 19:43:48 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJrps-0000FV-HD
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:43:40 +0200
Received: from 94.103.167.176 ([94.103.167.176])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:43:40 +0200
Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:43:40 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 19:43:29 +0000 (UTC)
Lines: 17
Message-ID: <loom.20120416T213327-280@post.gmane.org>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:11.0) Gecko/20100101 Firefox/11.0)
Subject: [Xen-devel] Xen VGA Passthrough to Windows 8 with Xen 4.2-unstable
	article on Xen.org Wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have been away for some time from this list and was really sursprised that
some people are still around here. I never understood why using a video as
tutorial would be a good idea (where you cannot search or navigate to a defined
section) but that may be just my personal taste.... BUT, do we really something
like this on Xen.org wiki:
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
?

I see the point if one wants hits for a name in a specific context on a popular
site (I counted more than 40 occurences of the authors name in the document) and
I also don't quite understand what is to be copyrighted there? It is neither
deserving any protection, nor would be a public wiki be the right place to
upload copyrighted data without stating any license or rights to use.


Regards,
   Christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:44:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:44:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJrq3-0005tx-Ts; Mon, 16 Apr 2012 19:43:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJrq2-0005ts-Ai
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:43:50 +0000
Received: from [85.158.143.99:13317] by server-1.bemta-4.messagelabs.com id
	00/1A-20925-5767C8F4; Mon, 16 Apr 2012 19:43:49 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334605427!22985869!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4720 invoked from network); 16 Apr 2012 19:43:48 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Apr 2012 19:43:48 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SJrps-0000FV-HD
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:43:40 +0200
Received: from 94.103.167.176 ([94.103.167.176])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:43:40 +0200
Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Mon, 16 Apr 2012 21:43:40 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Tramnitz <chris.ace@gmx.net>
Date: Mon, 16 Apr 2012 19:43:29 +0000 (UTC)
Lines: 17
Message-ID: <loom.20120416T213327-280@post.gmane.org>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:11.0) Gecko/20100101 Firefox/11.0)
Subject: [Xen-devel] Xen VGA Passthrough to Windows 8 with Xen 4.2-unstable
	article on Xen.org Wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have been away for some time from this list and was really sursprised that
some people are still around here. I never understood why using a video as
tutorial would be a good idea (where you cannot search or navigate to a defined
section) but that may be just my personal taste.... BUT, do we really something
like this on Xen.org wiki:
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
?

I see the point if one wants hits for a name in a specific context on a popular
site (I counted more than 40 occurences of the authors name in the document) and
I also don't quite understand what is to be copyrighted there? It is neither
deserving any protection, nor would be a public wiki be the right place to
upload copyrighted data without stating any license or rights to use.


Regards,
   Christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:58:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJs3r-0006Ae-Ay; Mon, 16 Apr 2012 19:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJs3p-0006AZ-58
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:58:05 +0000
Received: from [85.158.138.51:48904] by server-1.bemta-3.messagelabs.com id
	0A/D4-11491-CC97C8F4; Mon, 16 Apr 2012 19:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334606281!11395963!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22029 invoked from network); 16 Apr 2012 19:58:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 19:58:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GJvvra001256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 19:57:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GJvukG016695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 19:57:56 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GJvupb005528; Mon, 16 Apr 2012 14:57:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 12:57:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97E3740280; Mon, 16 Apr 2012 15:52:58 -0400 (EDT)
Date: Mon, 16 Apr 2012 15:52:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120416195258.GA14982@phenom.dumpdata.com>
References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F8C79C6.00A9,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are
 FOREIGN_FRAME when sharing them
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote:
> Set pages as FOREIGN_FRAME whenever blkfront shares them with another
> domain. Then when blkfront un-share them, also removes the
> FOREIGN_FRAME_BIT from the p2m.
> 
> We do it so that when the source and the destination domain are the same
> (blkfront connected to blkback in the same domain) we can more easily

Hm, however you mention qdisk which does not use blkback?

> recognize which ones are the source pfns and which ones are the
> destination pfns (both are going to be pointing to the same mfns).

OK, so what happens if we do not do this?
> 
> Without this patch enstablishing a connection between blkfront and QEMU
> qdisk in the same domain causes QEMU to hang and never return.

What is the reason behind it..?

Just to make sure I got it right:

The scenario is where a PV guest launches and inside it, it runs
QEMU exporting its disk (xvda, or some sda if iSCSI or FCoE) to some
other domain. In other words - a stubdomain, right? That would
imply that we have xen-blkfront, xen-blkback [or not?], and QEMU
using gntdev on the same page at some point.

So if we have a request from the other guest to read, it would be:
 - QEMU allocates some pages.
 - QEMU qdisk getting kicked.
 - QEMU using gntdev to IOCTL_GNTDEV_MAP_GRANT_REF the appropiate
   page
 - gntdev ends up calling gnttab_map_refs. The gnttab_map_refs then
   uses the m2p_add_override, which calls set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)).
 - QEMU passes the mentioned page to the kernel using the libaio.
 - libaio does its syscall to sys_aio? which then maps the 'struct page'
   in the kernel space. The PFN has FOREIGN_FRAME set.
 - kernel aio code passes the 'struct page' to xen-blkfront.
 - xen-blkfront now (with your patch) makes sure to re-stamp FOREIGN_FRAME on the
   PFN.
   
 - once xen-blkfront is done, it returns to libaio. libaio calls
   QEMU and it calls gntdev to unmap. The grant dev does it, and calls
   m2p_remove_override on the PFN [the one that had the FOREIGN_FRAME bit set].
   
Hm, I think I lost myself here.  Is the case here that QEMU does not
do the IOCTL_GNTDEV_MAP_GRANT_REF so in reality the PFN that is provided
to xen-blkfront does not have FOREIGN_FRAME stamped?


> 
> 
> Changes in v3:
> - only set_phys_to_machine if xen_pv_domain.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/block/xen-blkfront.c |   33 ++++++++++++++++++++++++++++-----
>  1 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..cabfbbb 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -262,7 +262,7 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode,
>  static int blkif_queue_request(struct request *req)
>  {
>  	struct blkfront_info *info = req->rq_disk->private_data;
> -	unsigned long buffer_mfn;
> +	unsigned long buffer_mfn, buffer_pfn;
>  	struct blkif_request *ring_req;
>  	unsigned long id;
>  	unsigned int fsect, lsect;
> @@ -321,7 +321,8 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
> +			buffer_pfn = page_to_pfn(sg_page(sg));
> +			buffer_mfn = pfn_to_mfn(buffer_pfn);
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
>  			/* install a grant reference. */
> @@ -340,6 +341,17 @@ static int blkif_queue_request(struct request *req)
>  						.gref       = ref,
>  						.first_sect = fsect,
>  						.last_sect  = lsect };
> +			/* 
> +			 * Set the page as foreign, considering that we are giving
> +			 * it to a foreign domain.
> +			 * This is important in case the destination domain is
> +			 * ourselves, so that we can more easily recognize the
> +			 * source pfn from destination pfn, both mapping to the same
> +			 * mfn.
> +			 */
> +			if (xen_pv_domain())

Should this also do the auto_translate bit check? Or do we not care
about that since the set_phys_to_machine does it for us?

> +				set_phys_to_machine(buffer_pfn,
> +						FOREIGN_FRAME(buffer_mfn));
>  		}
>  	}
>  
> @@ -715,8 +727,12 @@ static void blkif_completion(struct blk_shadow *s)
>  	int i;
>  	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
>  	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
>  		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +		if (xen_pv_domain())
> +			set_phys_to_machine(s->frame[i],
> +					get_phys_to_machine(s->frame[i]) & ~FOREIGN_FRAME_BIT);
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -1051,13 +1067,20 @@ static int blkif_recover(struct blkfront_info *info)
>  		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
>  
>  		if (req->operation != BLKIF_OP_DISCARD) {
> +			unsigned long buffer_pfn;
> +			unsigned long buffer_mfn;
>  		/* Rewrite any grant references invalidated by susp/resume. */
> -			for (j = 0; j < req->u.rw.nr_segments; j++)
> +			for (j = 0; j < req->u.rw.nr_segments; j++) {
> +				buffer_pfn = info->shadow[req->u.rw.id].frame[j];
> +				buffer_mfn = pfn_to_mfn(buffer_pfn);
>  				gnttab_grant_foreign_access_ref(
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
> -					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> +					buffer_mfn,
>  					rq_data_dir(info->shadow[req->u.rw.id].request));
> +				if (xen_pv_domain())
> +					set_phys_to_machine(buffer_pfn, FOREIGN_FRAME(buffer_mfn));
> +			}
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 19:58:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 19:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJs3r-0006Ae-Ay; Mon, 16 Apr 2012 19:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJs3p-0006AZ-58
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 19:58:05 +0000
Received: from [85.158.138.51:48904] by server-1.bemta-3.messagelabs.com id
	0A/D4-11491-CC97C8F4; Mon, 16 Apr 2012 19:58:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334606281!11395963!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22029 invoked from network); 16 Apr 2012 19:58:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 19:58:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GJvvra001256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 19:57:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GJvukG016695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 19:57:56 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GJvupb005528; Mon, 16 Apr 2012 14:57:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 12:57:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97E3740280; Mon, 16 Apr 2012 15:52:58 -0400 (EDT)
Date: Mon, 16 Apr 2012 15:52:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120416195258.GA14982@phenom.dumpdata.com>
References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F8C79C6.00A9,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are
 FOREIGN_FRAME when sharing them
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote:
> Set pages as FOREIGN_FRAME whenever blkfront shares them with another
> domain. Then when blkfront un-share them, also removes the
> FOREIGN_FRAME_BIT from the p2m.
> 
> We do it so that when the source and the destination domain are the same
> (blkfront connected to blkback in the same domain) we can more easily

Hm, however you mention qdisk which does not use blkback?

> recognize which ones are the source pfns and which ones are the
> destination pfns (both are going to be pointing to the same mfns).

OK, so what happens if we do not do this?
> 
> Without this patch enstablishing a connection between blkfront and QEMU
> qdisk in the same domain causes QEMU to hang and never return.

What is the reason behind it..?

Just to make sure I got it right:

The scenario is where a PV guest launches and inside it, it runs
QEMU exporting its disk (xvda, or some sda if iSCSI or FCoE) to some
other domain. In other words - a stubdomain, right? That would
imply that we have xen-blkfront, xen-blkback [or not?], and QEMU
using gntdev on the same page at some point.

So if we have a request from the other guest to read, it would be:
 - QEMU allocates some pages.
 - QEMU qdisk getting kicked.
 - QEMU using gntdev to IOCTL_GNTDEV_MAP_GRANT_REF the appropiate
   page
 - gntdev ends up calling gnttab_map_refs. The gnttab_map_refs then
   uses the m2p_add_override, which calls set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)).
 - QEMU passes the mentioned page to the kernel using the libaio.
 - libaio does its syscall to sys_aio? which then maps the 'struct page'
   in the kernel space. The PFN has FOREIGN_FRAME set.
 - kernel aio code passes the 'struct page' to xen-blkfront.
 - xen-blkfront now (with your patch) makes sure to re-stamp FOREIGN_FRAME on the
   PFN.
   
 - once xen-blkfront is done, it returns to libaio. libaio calls
   QEMU and it calls gntdev to unmap. The grant dev does it, and calls
   m2p_remove_override on the PFN [the one that had the FOREIGN_FRAME bit set].
   
Hm, I think I lost myself here.  Is the case here that QEMU does not
do the IOCTL_GNTDEV_MAP_GRANT_REF so in reality the PFN that is provided
to xen-blkfront does not have FOREIGN_FRAME stamped?


> 
> 
> Changes in v3:
> - only set_phys_to_machine if xen_pv_domain.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/block/xen-blkfront.c |   33 ++++++++++++++++++++++++++++-----
>  1 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..cabfbbb 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -262,7 +262,7 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode,
>  static int blkif_queue_request(struct request *req)
>  {
>  	struct blkfront_info *info = req->rq_disk->private_data;
> -	unsigned long buffer_mfn;
> +	unsigned long buffer_mfn, buffer_pfn;
>  	struct blkif_request *ring_req;
>  	unsigned long id;
>  	unsigned int fsect, lsect;
> @@ -321,7 +321,8 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
> +			buffer_pfn = page_to_pfn(sg_page(sg));
> +			buffer_mfn = pfn_to_mfn(buffer_pfn);
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
>  			/* install a grant reference. */
> @@ -340,6 +341,17 @@ static int blkif_queue_request(struct request *req)
>  						.gref       = ref,
>  						.first_sect = fsect,
>  						.last_sect  = lsect };
> +			/* 
> +			 * Set the page as foreign, considering that we are giving
> +			 * it to a foreign domain.
> +			 * This is important in case the destination domain is
> +			 * ourselves, so that we can more easily recognize the
> +			 * source pfn from destination pfn, both mapping to the same
> +			 * mfn.
> +			 */
> +			if (xen_pv_domain())

Should this also do the auto_translate bit check? Or do we not care
about that since the set_phys_to_machine does it for us?

> +				set_phys_to_machine(buffer_pfn,
> +						FOREIGN_FRAME(buffer_mfn));
>  		}
>  	}
>  
> @@ -715,8 +727,12 @@ static void blkif_completion(struct blk_shadow *s)
>  	int i;
>  	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
>  	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
>  		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +		if (xen_pv_domain())
> +			set_phys_to_machine(s->frame[i],
> +					get_phys_to_machine(s->frame[i]) & ~FOREIGN_FRAME_BIT);
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -1051,13 +1067,20 @@ static int blkif_recover(struct blkfront_info *info)
>  		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
>  
>  		if (req->operation != BLKIF_OP_DISCARD) {
> +			unsigned long buffer_pfn;
> +			unsigned long buffer_mfn;
>  		/* Rewrite any grant references invalidated by susp/resume. */
> -			for (j = 0; j < req->u.rw.nr_segments; j++)
> +			for (j = 0; j < req->u.rw.nr_segments; j++) {
> +				buffer_pfn = info->shadow[req->u.rw.id].frame[j];
> +				buffer_mfn = pfn_to_mfn(buffer_pfn);
>  				gnttab_grant_foreign_access_ref(
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
> -					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> +					buffer_mfn,
>  					rq_data_dir(info->shadow[req->u.rw.id].request));
> +				if (xen_pv_domain())
> +					set_phys_to_machine(buffer_pfn, FOREIGN_FRAME(buffer_mfn));
> +			}
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:14:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:14:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsJC-0006Z5-Ku; Mon, 16 Apr 2012 20:13:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1SJsJA-0006Yp-TJ
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:13:57 +0000
Received: from [85.158.143.99:48708] by server-1.bemta-4.messagelabs.com id
	1D/E9-20925-48D7C8F4; Mon, 16 Apr 2012 20:13:56 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334607233!20522278!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27202 invoked from network); 16 Apr 2012 20:13:55 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 20:13:55 -0000
Received: by obbtb18 with SMTP id tb18so3082915obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Apr 2012 13:13:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=1CaWPCEinMftfng0TojMtpGnQBGGOMXV1nKRQ0oZa+w=;
	b=Dnuy/JwTYWK3mWKiVemiwZXT5knkvvLX3ge/QdpFiZJ9a6nIJDWvyqGsanmSJxREig
	5HDce5XiefxLufNHUM/GspY7YA3+z6MMujySUZVLmVD6NVGeWH/EsXIaEmeZofVKDO+X
	v/UySaX56Pj8aiEuH1jOzoh6xseXzsrL8eFQSHIObFPKHH77gQTLdWO7J15qdiPSwbJP
	MCj/k9lwwJnC3DFstT8Pnt7MQOS2Gg8Eco845eBe5TE3L+D9ytsSc8QVuZs1Hl9FnBew
	2NCI62W65q3ShXVRZeLg+lXjwiUoyweRbcrmPWe32OZfs8bO5sNR0Auy+w7VDxtWZW+6
	kf2w==
Received: by 10.182.119.101 with SMTP id kt5mr17752768obb.70.1334607233278;
	Mon, 16 Apr 2012 13:13:53 -0700 (PDT)
Received: from [192.168.0.108] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id h2sm20541465obn.20.2012.04.16.13.13.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 16 Apr 2012 13:13:52 -0700 (PDT)
Message-ID: <4F8C7D7E.2060203@codemonkey.ws>
Date: Mon, 16 Apr 2012 15:13:50 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204131840110.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204131840110.26786@kaball-desktop>
X-Gm-Message-State: ALoCoQkpK5NV1p3unXfbWtIqKRYMyCO/FtS1WT6TnpH/1qkpK1t14KZLaOGaifuI5TPJ5kGCWxef
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PULL] Xen MSI, mapcache, xen_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/13/2012 01:01 PM, Stefano Stabellini wrote:
> Hi Anthony,
> please pull the following branch:
>
> git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_anthony

Pulled.  Thanks.

Regards,

Anthony Liguori

>
>
> It includes two mapcache fixes, one xen_disk fix, two patches to allow
> MSI injection into HVM guests and finally a patch to receive
> notification from Xen for buffered io events:
>
>
> Anthony PERARD (1):
>        Xen, mapcache: Fix the compute of the size of bucket.
>
> Julien Grall (1):
>        xen-mapcache: don't unmap locked entry during mapcache invalidation
>
> Stefano Stabellini (2):
>        xen: handle backend deletion from xenstore
>        xen: introduce an event channel for buffered io event notifications
>
> Wei Liu (2):
>        Xen: basic HVM MSI injection support.
>        Xen: Add xen-apic support and hook it up.
>
>
>   Makefile.target  |    2 +-
>   hw/pc.c          |    8 +++++
>   hw/xen.h         |    1 +
>   hw/xen_apic.c    |   90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   hw/xen_backend.c |   17 +++++-----
>   hw/xen_disk.c    |    4 ++
>   xen-all.c        |   50 ++++++++++++++++++++++++++---
>   xen-mapcache.c   |   15 ++++++---
>   xen-stub.c       |    4 ++
>   9 files changed, 171 insertions(+), 20 deletions(-)
>
> Cheers,
>
> Stefano
>
>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:14:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:14:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsJC-0006Z5-Ku; Mon, 16 Apr 2012 20:13:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1SJsJA-0006Yp-TJ
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:13:57 +0000
Received: from [85.158.143.99:48708] by server-1.bemta-4.messagelabs.com id
	1D/E9-20925-48D7C8F4; Mon, 16 Apr 2012 20:13:56 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334607233!20522278!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27202 invoked from network); 16 Apr 2012 20:13:55 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 20:13:55 -0000
Received: by obbtb18 with SMTP id tb18so3082915obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Apr 2012 13:13:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=1CaWPCEinMftfng0TojMtpGnQBGGOMXV1nKRQ0oZa+w=;
	b=Dnuy/JwTYWK3mWKiVemiwZXT5knkvvLX3ge/QdpFiZJ9a6nIJDWvyqGsanmSJxREig
	5HDce5XiefxLufNHUM/GspY7YA3+z6MMujySUZVLmVD6NVGeWH/EsXIaEmeZofVKDO+X
	v/UySaX56Pj8aiEuH1jOzoh6xseXzsrL8eFQSHIObFPKHH77gQTLdWO7J15qdiPSwbJP
	MCj/k9lwwJnC3DFstT8Pnt7MQOS2Gg8Eco845eBe5TE3L+D9ytsSc8QVuZs1Hl9FnBew
	2NCI62W65q3ShXVRZeLg+lXjwiUoyweRbcrmPWe32OZfs8bO5sNR0Auy+w7VDxtWZW+6
	kf2w==
Received: by 10.182.119.101 with SMTP id kt5mr17752768obb.70.1334607233278;
	Mon, 16 Apr 2012 13:13:53 -0700 (PDT)
Received: from [192.168.0.108] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id h2sm20541465obn.20.2012.04.16.13.13.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 16 Apr 2012 13:13:52 -0700 (PDT)
Message-ID: <4F8C7D7E.2060203@codemonkey.ws>
Date: Mon, 16 Apr 2012 15:13:50 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204131840110.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204131840110.26786@kaball-desktop>
X-Gm-Message-State: ALoCoQkpK5NV1p3unXfbWtIqKRYMyCO/FtS1WT6TnpH/1qkpK1t14KZLaOGaifuI5TPJ5kGCWxef
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PULL] Xen MSI, mapcache, xen_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/13/2012 01:01 PM, Stefano Stabellini wrote:
> Hi Anthony,
> please pull the following branch:
>
> git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_anthony

Pulled.  Thanks.

Regards,

Anthony Liguori

>
>
> It includes two mapcache fixes, one xen_disk fix, two patches to allow
> MSI injection into HVM guests and finally a patch to receive
> notification from Xen for buffered io events:
>
>
> Anthony PERARD (1):
>        Xen, mapcache: Fix the compute of the size of bucket.
>
> Julien Grall (1):
>        xen-mapcache: don't unmap locked entry during mapcache invalidation
>
> Stefano Stabellini (2):
>        xen: handle backend deletion from xenstore
>        xen: introduce an event channel for buffered io event notifications
>
> Wei Liu (2):
>        Xen: basic HVM MSI injection support.
>        Xen: Add xen-apic support and hook it up.
>
>
>   Makefile.target  |    2 +-
>   hw/pc.c          |    8 +++++
>   hw/xen.h         |    1 +
>   hw/xen_apic.c    |   90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   hw/xen_backend.c |   17 +++++-----
>   hw/xen_disk.c    |    4 ++
>   xen-all.c        |   50 ++++++++++++++++++++++++++---
>   xen-mapcache.c   |   15 ++++++---
>   xen-stub.c       |    4 ++
>   9 files changed, 171 insertions(+), 20 deletions(-)
>
> Cheers,
>
> Stefano
>
>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:32:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsad-00072G-AJ; Mon, 16 Apr 2012 20:31:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJsab-00072B-5E
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:31:57 +0000
Received: from [85.158.139.83:21855] by server-7.bemta-5.messagelabs.com id
	EF/33-16195-CB18C8F4; Mon, 16 Apr 2012 20:31:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334608312!19804253!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4763 invoked from network); 16 Apr 2012 20:31:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 20:31:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKVn63008224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:31:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKVmkJ014217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:31:48 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKVlRL031799; Mon, 16 Apr 2012 15:31:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:31:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2ED0340280; Mon, 16 Apr 2012 16:26:50 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:26:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120416202650.GB14982@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A62@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335146A62@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F8C81B6.00DD,ss=1,re=1.599,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 01:05:55AM +0000, Liu, Jinsong wrote:
> >From 0ee0651756eb6255bc81da8a7b6313bab4b80d1e Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Sun, 15 Apr 2012 22:58:34 +0800
> Subject: [PATCH 1/2] Add mcelog support for xen platform
> 
> When MCA error occurs, it would be handled by xen hypervisor first,
> and then the error information would be sent to dom0 for logging.
> 
> This patch gets error information from xen hypervisor and convert
> xen format error into linux format mcelog. This logic is basically
> self-contained, not much touching other kernel components.
> 
> So under xen platform when MCA error occurs, the error information
> would be sent to dom0 and converted into native linux mcelog format.
> By using tools like mcelog tool users could read specific error information,
> like what they did under native linux.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/include/asm/xen/hypercall.h |    8 +
>  arch/x86/xen/enlighten.c             |    4 +-
>  drivers/xen/Kconfig                  |    8 +
>  drivers/xen/Makefile                 |    1 +
>  drivers/xen/mcelog.c                 |  201 ++++++++++++++++++++
>  include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++++++
>  6 files changed, 555 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/xen/mcelog.c
>  create mode 100644 include/xen/interface/xen-mca.h
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 5728852..59c226d 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@
>  #include <xen/interface/sched.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/platform.h>
> +#include <xen/interface/xen-mca.h>
>  
>  /*
>   * The hypercall asms have to meet several constraints:
> @@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
>  }
>  
>  static inline int
> +HYPERVISOR_mca(struct xen_mc *mc_op)
> +{
> +	mc_op->interface_version = XEN_MCA_INTERFACE_VERSION;
> +	return _hypercall1(int, mca, mc_op);
> +}
> +
> +static inline int
>  HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
>  {
>  	platform_op->interface_version = XENPF_INTERFACE_VERSION;
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 4f51beb..15628d4 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
>  	unsigned int xsave_mask;
>  
>  	cpuid_leaf1_edx_mask =
> -		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> -		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> -		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 9424313..f45f923 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
>            module will be called xen_acpi_processor  If you do not know what to choose,
>            select M here. If the CPUFREQ drivers are built in, select Y here.
>  
> +config XEN_MCE_LOG
> +	bool "Xen platform mcelog"
> +	depends on XEN_DOM0 && X86_64 && X86_MCE
> +	default n
> +	help
> +	  Allow kernel fetching mce log from xen platform and
> +	  converting it into linux mcelog format for mcelog tools

You should use proper capitalization. Such as 'Linux' and 'Xen'
and MCE.
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 9adc5be..1d3e763 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+= xen-gntdev.o
>  obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+= xen-gntalloc.o
>  obj-$(CONFIG_XENFS)			+= xenfs/
>  obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
> +obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> new file mode 100644
> index 0000000..e9f86b8
> --- /dev/null
> +++ b/drivers/xen/mcelog.c
> @@ -0,0 +1,201 @@
> +/******************************************************************************
> + * mcelog.c
> + * Driver for receiving and transferring machine check error infomation
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + * Author: Ke, Liping <liping.ke@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +#include <xen/events.h>
> +#include <xen/interface/vcpu.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/mce.h>
> +#include <xen/xen.h>
> +
> +static struct mc_info g_mi;
> +static struct mcinfo_logical_cpu *g_physinfo;
> +static uint32_t ncpus;
> +
> +static DEFINE_SPINLOCK(mcelog_lock);
> +
> +static void convert_log(struct mc_info *mi)

There is a bunch of checks you do in this function.

Why don't you make this function return a value and
then you can do a similar check for return code in
mc_queue_handle?

> +{
> +	struct mcinfo_common *mic;
> +	struct mcinfo_global *mc_global;
> +	struct mcinfo_bank *mc_bank;
> +	struct mce m;
> +	int i;

unsigned int as the ncpus is unsigned int.


> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
> +	if (unlikely(!mic))
> +		return;
> +
> +	mce_setup(&m);
> +	mc_global = (struct mcinfo_global *)mic;
> +	m.mcgstatus = mc_global->mc_gstatus;
> +	m.apicid = mc_global->mc_apicid;
> +
> +	for (i = 0; i < ncpus; i++)
> +		if (g_physinfo[i].mc_apicid == m.apicid)
> +			break;
> +	if (unlikely(i == ncpus))
> +		return;
> +
> +	m.socketid = g_physinfo[i].mc_chipid;
> +	m.cpu = m.extcpu = g_physinfo[i].mc_cpunr;
> +	m.cpuvendor = (__u8)g_physinfo[i].mc_vendor;
> +	m.mcgcap = g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
> +
> +	do {
> +		if ((!mic) || (mic->size == 0) ||
> +		    (mic->type != MC_TYPE_GLOBAL   &&
> +		     mic->type != MC_TYPE_BANK     &&
> +		     mic->type != MC_TYPE_EXTENDED &&
> +		     mic->type != MC_TYPE_RECOVERY))
> +			break;
> +
> +		if (mic->type == MC_TYPE_BANK) {
> +			mc_bank = (struct mcinfo_bank *)mic;
> +			m.misc = mc_bank->mc_misc;
> +			m.status = mc_bank->mc_status;
> +			m.addr = mc_bank->mc_addr;
> +			m.tsc = mc_bank->mc_tsc;
> +			m.bank = mc_bank->mc_bank;
> +			m.finished = 1;
> +			/*log this record*/
> +			mce_log(&m);
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	} while (1);
> +}
> +
> +static void mc_queue_handle(uint32_t flags)
> +{
> +	struct xen_mc mc_op;
> +	int ret = 0;
> +	unsigned long tmp;
> +
> +	spin_lock_irqsave(&mcelog_lock, tmp);
> +
> +	mc_op.cmd = XEN_MC_fetch;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
> +	do {
> +		mc_op.u.mc_fetch.flags = flags;
> +		ret = HYPERVISOR_mca(&mc_op);
> +		if (ret || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
> +			break;
> +		else {
> +			convert_log(&g_mi);
> +			mc_op.u.mc_fetch.flags = flags | XEN_MC_ACK;
> +			ret = HYPERVISOR_mca(&mc_op);
> +			if (ret)
> +				break;
> +		}
> +	} while (1);
> +
> +	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +
> +	return;

No 'return ret' ?

Or at least:

WARN_ON(ret, "Failed @ ... (ret: %d)", g_mi.. something ?, ret);
> +}
> +
> +/* virq handler for machine check error info*/
> +static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
> +{
> +	/* urgent mc_info */
> +	mc_queue_handle(XEN_MC_URGENT);
> +
> +	/* nonurgent mc_info */
> +	mc_queue_handle(XEN_MC_NONURGENT);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int bind_virq_for_mce(void)
> +{
> +	int ret;
> +	struct xen_mc mc_op;
> +
> +	memset(&mc_op, 0, sizeof(struct xen_mc));
> +
> +	/* Fetch physical CPU Numbers */
> +	mc_op.cmd = XEN_MC_physcpuinfo;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_LOG: Failed to get CPU numbers\n");

pr_err. And
if you can something like this:

#define DRV_NAME "xen_mce: "

pr_err(DRV_NAME "Failed to get CPU numbers! (ret: %d)\n, ret)

> +		return ret;
> +	}
> +
> +	/* Fetch each CPU Physical Info for later reference*/
> +	ncpus = mc_op.u.mc_physcpuinfo.ncpus;
> +	g_physinfo = kzalloc(sizeof(struct mcinfo_logical_cpu) * ncpus,
> +			     GFP_KERNEL);

Use kcalloc please.

> +	if (!g_physinfo)
> +		return -ENOMEM;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_LOG: Failed to get CPU info\n");

Ditto - pr_err

> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	ret  = bind_virq_to_irqhandler(VIRQ_MCA, 0,
> +				       mce_dom_interrupt, 0, "mce", NULL);

s/mce_dom_interrupt/xen_mce_interrupt/g


> +	if (ret < 0) {
> +		printk(KERN_ERR "MCE_LOG: Failed to bind virq\n");
> +		kfree(g_physinfo);
> +	}
> +
> +	return ret;
> +}
> +
> +static int __init mcelog_init(void)
> +{
> +	/* Only DOM0 is responsible for MCE logging */
> +	if (xen_initial_domain())
> +		return bind_virq_for_mce();
> +
> +	return -ENODEV;
> +}
> +late_initcall(mcelog_init);
> diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mca.h
> new file mode 100644
> index 0000000..f2561db
> --- /dev/null
> +++ b/include/xen/interface/xen-mca.h
> @@ -0,0 +1,336 @@
> +/******************************************************************************
> + * arch-x86/mca.h
> + * Guest OS machine check interface to x86 Xen.
> + *
> + * Contributed by Advanced Micro Devices, Inc.
> + * Author: Christoph Egger <Christoph.Egger@amd.com>
> + *
> + * Updated by Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
> +#define __XEN_PUBLIC_ARCH_X86_MCA_H__
> +
> +/* Hypercall */
> +#define __HYPERVISOR_mca __HYPERVISOR_arch_0
> +
> +#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
> +
> +/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
> +#define XEN_MC_NONURGENT	0x1
> +/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
> +#define XEN_MC_URGENT		0x2
> +/* IN: Dom0 acknowledges previosly-fetched error log entry */
> +#define XEN_MC_ACK		0x4
> +
> +/* OUT: All is ok */
> +#define XEN_MC_OK		0x0
> +/* OUT: Domain could not fetch data. */
> +#define XEN_MC_FETCHFAILED	0x1
> +/* OUT: There was no machine check data to fetch. */
> +#define XEN_MC_NODATA		0x2
> +
> +#ifndef __ASSEMBLY__
> +/* vIRQ injected to Dom0 */
> +#define VIRQ_MCA VIRQ_ARCH_0
> +
> +/*
> + * mc_info entry types
> + * mca machine check info are recorded in mc_info entries.
> + * when fetch mca info, it can use MC_TYPE_... to distinguish
> + * different mca info.
> + */
> +#define MC_TYPE_GLOBAL		0
> +#define MC_TYPE_BANK		1
> +#define MC_TYPE_EXTENDED	2
> +#define MC_TYPE_RECOVERY	3
> +
> +struct mcinfo_common {
> +	uint16_t type; /* structure type */
> +	uint16_t size; /* size of this struct in bytes */
> +};
> +
> +#define MC_FLAG_CORRECTABLE	(1 << 0)
> +#define MC_FLAG_UNCORRECTABLE	(1 << 1)
> +#define MC_FLAG_RECOVERABLE	(1 << 2)
> +#define MC_FLAG_POLLED		(1 << 3)
> +#define MC_FLAG_RESET		(1 << 4)
> +#define MC_FLAG_CMCI		(1 << 5)
> +#define MC_FLAG_MCE		(1 << 6)
> +
> +/* contains x86 global mc information */
> +struct mcinfo_global {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_domid; /* running domain at the time in error */
> +	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
> +	uint32_t mc_socketid; /* physical socket of the physical core */
> +	uint16_t mc_coreid; /* physical impacted core */
> +	uint16_t mc_core_threadid; /* core thread of physical core */
> +	uint32_t mc_apicid;
> +	uint32_t mc_flags;
> +	uint64_t mc_gstatus; /* global status */
> +};
> +
> +/* contains x86 bank mc information */
> +struct mcinfo_bank {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_bank; /* bank nr */
> +	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
> +	uint64_t mc_status; /* bank status */
> +	uint64_t mc_addr; /* bank address */
> +	uint64_t mc_misc;
> +	uint64_t mc_ctrl2;
> +	uint64_t mc_tsc;
> +};
> +
> +struct mcinfo_msr {
> +	uint64_t reg; /* MSR */
> +	uint64_t value; /* MSR value */
> +};
> +
> +/* contains mc information from other or additional mc MSRs */
> +struct mcinfo_extended {
> +	struct mcinfo_common common;
> +	uint32_t mc_msrs; /* Number of msr with valid values. */
> +	/*
> +	 * Currently Intel extended MSR (32/64) include all gp registers
> +	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
> +	 * useful at present. So expand this array to 16/32 to leave room.
> +	 */
> +	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
> +};
> +
> +/* Recovery Action flags. Giving recovery result information to DOM0 */
> +
> +/* Xen takes successful recovery action, the error is recovered */
> +#define REC_ACTION_RECOVERED (0x1 << 0)
> +/* No action is performed by XEN */
> +#define REC_ACTION_NONE (0x1 << 1)
> +/* It's possible DOM0 might take action ownership in some case */
> +#define REC_ACTION_NEED_RESET (0x1 << 2)
> +
> +/*
> + * Different Recovery Action types, if the action is performed successfully,
> + * REC_ACTION_RECOVERED flag will be returned.
> + */
> +
> +/* Page Offline Action */
> +#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
> +/* CPU offline Action */
> +#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
> +/* L3 cache disable Action */
> +#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
> +
> +/*
> + * Below interface used between XEN/DOM0 for passing XEN's recovery action
> + * information to DOM0.
> + */
> +struct page_offline_action {
> +	/* Params for passing the offlined page number to DOM0 */
> +	uint64_t mfn;
> +	uint64_t status;
> +};
> +
> +struct cpu_offline_action {
> +	/* Params for passing the identity of the offlined CPU to DOM0 */
> +	uint32_t mc_socketid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_core_threadid;
> +};
> +
> +#define MAX_UNION_SIZE 16
> +struct mcinfo_recovery {
> +	struct mcinfo_common common;
> +	uint16_t mc_bank; /* bank nr */
> +	uint8_t action_flags;
> +	uint8_t action_types;
> +	union {
> +		struct page_offline_action page_retire;
> +		struct cpu_offline_action cpu_offline;
> +		uint8_t pad[MAX_UNION_SIZE];
> +	} action_info;
> +};
> +
> +
> +#define MCINFO_MAXSIZE 768
> +struct mc_info {
> +	/* Number of mcinfo_* entries in mi_data */
> +	uint32_t mi_nentries;
> +	uint32_t flags;
> +	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mc_info);
> +
> +#define __MC_MSR_ARRAYSIZE 8
> +#define __MC_MSR_MCGCAP 0
> +#define __MC_NMSRS 1
> +#define MC_NCAPS 7
> +struct mcinfo_logical_cpu {
> +	uint32_t mc_cpunr;
> +	uint32_t mc_chipid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_threadid;
> +	uint32_t mc_apicid;
> +	uint32_t mc_clusterid;
> +	uint32_t mc_ncores;
> +	uint32_t mc_ncores_active;
> +	uint32_t mc_nthreads;
> +	uint32_t mc_cpuid_level;
> +	uint32_t mc_family;
> +	uint32_t mc_vendor;
> +	uint32_t mc_model;
> +	uint32_t mc_step;
> +	char mc_vendorid[16];
> +	char mc_brandid[64];
> +	uint32_t mc_cpu_caps[MC_NCAPS];
> +	uint32_t mc_cache_size;
> +	uint32_t mc_cache_alignment;
> +	uint32_t mc_nmsrvals;
> +	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
> +
> +/*
> + * Prototype:
> + *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
> + */
> +#define x86_mcinfo_nentries(_mi)    \
> +	((_mi)->mi_nentries)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
> + */
> +#define x86_mcinfo_first(_mi)       \
> +	((struct mcinfo_common *)(_mi)->mi_data)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
> + */
> +#define x86_mcinfo_next(_mic)       \
> +	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
> +
> +/*
> + * Prototype:
> + *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type);
> + */
> +static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
> +				     struct mc_info *mi, uint16_t type)
> +{
> +	uint32_t i;
> +	struct mcinfo_common *mic;
> +	bool found = 0;
> +
> +	if (!ret || !mi)
> +		return;
> +
> +	mic = x86_mcinfo_first(mi);
> +	for (i = 0; i < x86_mcinfo_nentries(mi); i++) {
> +		if (mic->type == type) {
> +			found = 1;
> +			break;
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	}
> +
> +	*ret = found ? mic : NULL;
> +}
> +
> +/*
> + * Fetch machine check data from hypervisor.
> + */
> +#define XEN_MC_fetch		1
> +struct xen_mc_fetch {
> +	/*
> +	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
> +	 * XEN_MC_ACK if ack'king an earlier fetch
> +	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
> +	 */
> +	uint32_t flags;
> +	uint32_t _pad0;
> +	/* OUT: id for ack, IN: id we are ack'ing */
> +	uint64_t fetch_id;
> +
> +	/* OUT variables. */
> +	GUEST_HANDLE(mc_info) data;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
> +
> +
> +/*
> + * This tells the hypervisor to notify a DomU about the machine check error
> + */
> +#define XEN_MC_notifydomain	2
> +struct xen_mc_notifydomain {
> +	/* IN variables */
> +	uint16_t mc_domid; /* The unprivileged domain to notify */
> +	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
> +
> +	/* IN/OUT variables */
> +	uint32_t flags;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
> +
> +#define XEN_MC_physcpuinfo	3
> +struct xen_mc_physcpuinfo {
> +	/* IN/OUT */
> +	uint32_t ncpus;
> +	uint32_t _pad0;
> +	/* OUT */
> +	GUEST_HANDLE(mcinfo_logical_cpu) info;
> +};
> +
> +#define XEN_MC_msrinject	4
> +#define MC_MSRINJ_MAXMSRS	8
> +struct xen_mc_msrinject {
> +	/* IN */
> +	uint32_t mcinj_cpunr; /* target processor id */
> +	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
> +	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
> +	uint32_t _pad0;
> +	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
> +};
> +
> +/* Flags for mcinj_flags above; bits 16-31 are reserved */
> +#define MC_MSRINJ_F_INTERPOSE	0x1
> +
> +#define XEN_MC_mceinject	5
> +struct xen_mc_mceinject {
> +	unsigned int mceinj_cpunr; /* target processor id */
> +};
> +
> +struct xen_mc {
> +	uint32_t cmd;
> +	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
> +	union {
> +		struct xen_mc_fetch        mc_fetch;
> +		struct xen_mc_notifydomain mc_notifydomain;
> +		struct xen_mc_physcpuinfo  mc_physcpuinfo;
> +		struct xen_mc_msrinject    mc_msrinject;
> +		struct xen_mc_mceinject    mc_mceinject;
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */

OK, besides those comments it looks great. Please re-send with
the modifications.

> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:32:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsad-00072G-AJ; Mon, 16 Apr 2012 20:31:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJsab-00072B-5E
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:31:57 +0000
Received: from [85.158.139.83:21855] by server-7.bemta-5.messagelabs.com id
	EF/33-16195-CB18C8F4; Mon, 16 Apr 2012 20:31:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334608312!19804253!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4763 invoked from network); 16 Apr 2012 20:31:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 20:31:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKVn63008224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:31:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKVmkJ014217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:31:48 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKVlRL031799; Mon, 16 Apr 2012 15:31:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:31:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2ED0340280; Mon, 16 Apr 2012 16:26:50 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:26:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120416202650.GB14982@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A62@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335146A62@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F8C81B6.00DD,ss=1,re=1.599,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 01:05:55AM +0000, Liu, Jinsong wrote:
> >From 0ee0651756eb6255bc81da8a7b6313bab4b80d1e Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Sun, 15 Apr 2012 22:58:34 +0800
> Subject: [PATCH 1/2] Add mcelog support for xen platform
> 
> When MCA error occurs, it would be handled by xen hypervisor first,
> and then the error information would be sent to dom0 for logging.
> 
> This patch gets error information from xen hypervisor and convert
> xen format error into linux format mcelog. This logic is basically
> self-contained, not much touching other kernel components.
> 
> So under xen platform when MCA error occurs, the error information
> would be sent to dom0 and converted into native linux mcelog format.
> By using tools like mcelog tool users could read specific error information,
> like what they did under native linux.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/include/asm/xen/hypercall.h |    8 +
>  arch/x86/xen/enlighten.c             |    4 +-
>  drivers/xen/Kconfig                  |    8 +
>  drivers/xen/Makefile                 |    1 +
>  drivers/xen/mcelog.c                 |  201 ++++++++++++++++++++
>  include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++++++
>  6 files changed, 555 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/xen/mcelog.c
>  create mode 100644 include/xen/interface/xen-mca.h
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 5728852..59c226d 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@
>  #include <xen/interface/sched.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/platform.h>
> +#include <xen/interface/xen-mca.h>
>  
>  /*
>   * The hypercall asms have to meet several constraints:
> @@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
>  }
>  
>  static inline int
> +HYPERVISOR_mca(struct xen_mc *mc_op)
> +{
> +	mc_op->interface_version = XEN_MCA_INTERFACE_VERSION;
> +	return _hypercall1(int, mca, mc_op);
> +}
> +
> +static inline int
>  HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
>  {
>  	platform_op->interface_version = XENPF_INTERFACE_VERSION;
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 4f51beb..15628d4 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
>  	unsigned int xsave_mask;
>  
>  	cpuid_leaf1_edx_mask =
> -		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> -		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> -		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 9424313..f45f923 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
>            module will be called xen_acpi_processor  If you do not know what to choose,
>            select M here. If the CPUFREQ drivers are built in, select Y here.
>  
> +config XEN_MCE_LOG
> +	bool "Xen platform mcelog"
> +	depends on XEN_DOM0 && X86_64 && X86_MCE
> +	default n
> +	help
> +	  Allow kernel fetching mce log from xen platform and
> +	  converting it into linux mcelog format for mcelog tools

You should use proper capitalization. Such as 'Linux' and 'Xen'
and MCE.
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 9adc5be..1d3e763 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+= xen-gntdev.o
>  obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+= xen-gntalloc.o
>  obj-$(CONFIG_XENFS)			+= xenfs/
>  obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
> +obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> new file mode 100644
> index 0000000..e9f86b8
> --- /dev/null
> +++ b/drivers/xen/mcelog.c
> @@ -0,0 +1,201 @@
> +/******************************************************************************
> + * mcelog.c
> + * Driver for receiving and transferring machine check error infomation
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + * Author: Ke, Liping <liping.ke@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +#include <xen/events.h>
> +#include <xen/interface/vcpu.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/mce.h>
> +#include <xen/xen.h>
> +
> +static struct mc_info g_mi;
> +static struct mcinfo_logical_cpu *g_physinfo;
> +static uint32_t ncpus;
> +
> +static DEFINE_SPINLOCK(mcelog_lock);
> +
> +static void convert_log(struct mc_info *mi)

There is a bunch of checks you do in this function.

Why don't you make this function return a value and
then you can do a similar check for return code in
mc_queue_handle?

> +{
> +	struct mcinfo_common *mic;
> +	struct mcinfo_global *mc_global;
> +	struct mcinfo_bank *mc_bank;
> +	struct mce m;
> +	int i;

unsigned int as the ncpus is unsigned int.


> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
> +	if (unlikely(!mic))
> +		return;
> +
> +	mce_setup(&m);
> +	mc_global = (struct mcinfo_global *)mic;
> +	m.mcgstatus = mc_global->mc_gstatus;
> +	m.apicid = mc_global->mc_apicid;
> +
> +	for (i = 0; i < ncpus; i++)
> +		if (g_physinfo[i].mc_apicid == m.apicid)
> +			break;
> +	if (unlikely(i == ncpus))
> +		return;
> +
> +	m.socketid = g_physinfo[i].mc_chipid;
> +	m.cpu = m.extcpu = g_physinfo[i].mc_cpunr;
> +	m.cpuvendor = (__u8)g_physinfo[i].mc_vendor;
> +	m.mcgcap = g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
> +
> +	do {
> +		if ((!mic) || (mic->size == 0) ||
> +		    (mic->type != MC_TYPE_GLOBAL   &&
> +		     mic->type != MC_TYPE_BANK     &&
> +		     mic->type != MC_TYPE_EXTENDED &&
> +		     mic->type != MC_TYPE_RECOVERY))
> +			break;
> +
> +		if (mic->type == MC_TYPE_BANK) {
> +			mc_bank = (struct mcinfo_bank *)mic;
> +			m.misc = mc_bank->mc_misc;
> +			m.status = mc_bank->mc_status;
> +			m.addr = mc_bank->mc_addr;
> +			m.tsc = mc_bank->mc_tsc;
> +			m.bank = mc_bank->mc_bank;
> +			m.finished = 1;
> +			/*log this record*/
> +			mce_log(&m);
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	} while (1);
> +}
> +
> +static void mc_queue_handle(uint32_t flags)
> +{
> +	struct xen_mc mc_op;
> +	int ret = 0;
> +	unsigned long tmp;
> +
> +	spin_lock_irqsave(&mcelog_lock, tmp);
> +
> +	mc_op.cmd = XEN_MC_fetch;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
> +	do {
> +		mc_op.u.mc_fetch.flags = flags;
> +		ret = HYPERVISOR_mca(&mc_op);
> +		if (ret || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
> +			break;
> +		else {
> +			convert_log(&g_mi);
> +			mc_op.u.mc_fetch.flags = flags | XEN_MC_ACK;
> +			ret = HYPERVISOR_mca(&mc_op);
> +			if (ret)
> +				break;
> +		}
> +	} while (1);
> +
> +	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +
> +	return;

No 'return ret' ?

Or at least:

WARN_ON(ret, "Failed @ ... (ret: %d)", g_mi.. something ?, ret);
> +}
> +
> +/* virq handler for machine check error info*/
> +static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
> +{
> +	/* urgent mc_info */
> +	mc_queue_handle(XEN_MC_URGENT);
> +
> +	/* nonurgent mc_info */
> +	mc_queue_handle(XEN_MC_NONURGENT);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int bind_virq_for_mce(void)
> +{
> +	int ret;
> +	struct xen_mc mc_op;
> +
> +	memset(&mc_op, 0, sizeof(struct xen_mc));
> +
> +	/* Fetch physical CPU Numbers */
> +	mc_op.cmd = XEN_MC_physcpuinfo;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_LOG: Failed to get CPU numbers\n");

pr_err. And
if you can something like this:

#define DRV_NAME "xen_mce: "

pr_err(DRV_NAME "Failed to get CPU numbers! (ret: %d)\n, ret)

> +		return ret;
> +	}
> +
> +	/* Fetch each CPU Physical Info for later reference*/
> +	ncpus = mc_op.u.mc_physcpuinfo.ncpus;
> +	g_physinfo = kzalloc(sizeof(struct mcinfo_logical_cpu) * ncpus,
> +			     GFP_KERNEL);

Use kcalloc please.

> +	if (!g_physinfo)
> +		return -ENOMEM;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_LOG: Failed to get CPU info\n");

Ditto - pr_err

> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	ret  = bind_virq_to_irqhandler(VIRQ_MCA, 0,
> +				       mce_dom_interrupt, 0, "mce", NULL);

s/mce_dom_interrupt/xen_mce_interrupt/g


> +	if (ret < 0) {
> +		printk(KERN_ERR "MCE_LOG: Failed to bind virq\n");
> +		kfree(g_physinfo);
> +	}
> +
> +	return ret;
> +}
> +
> +static int __init mcelog_init(void)
> +{
> +	/* Only DOM0 is responsible for MCE logging */
> +	if (xen_initial_domain())
> +		return bind_virq_for_mce();
> +
> +	return -ENODEV;
> +}
> +late_initcall(mcelog_init);
> diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mca.h
> new file mode 100644
> index 0000000..f2561db
> --- /dev/null
> +++ b/include/xen/interface/xen-mca.h
> @@ -0,0 +1,336 @@
> +/******************************************************************************
> + * arch-x86/mca.h
> + * Guest OS machine check interface to x86 Xen.
> + *
> + * Contributed by Advanced Micro Devices, Inc.
> + * Author: Christoph Egger <Christoph.Egger@amd.com>
> + *
> + * Updated by Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
> +#define __XEN_PUBLIC_ARCH_X86_MCA_H__
> +
> +/* Hypercall */
> +#define __HYPERVISOR_mca __HYPERVISOR_arch_0
> +
> +#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
> +
> +/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
> +#define XEN_MC_NONURGENT	0x1
> +/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
> +#define XEN_MC_URGENT		0x2
> +/* IN: Dom0 acknowledges previosly-fetched error log entry */
> +#define XEN_MC_ACK		0x4
> +
> +/* OUT: All is ok */
> +#define XEN_MC_OK		0x0
> +/* OUT: Domain could not fetch data. */
> +#define XEN_MC_FETCHFAILED	0x1
> +/* OUT: There was no machine check data to fetch. */
> +#define XEN_MC_NODATA		0x2
> +
> +#ifndef __ASSEMBLY__
> +/* vIRQ injected to Dom0 */
> +#define VIRQ_MCA VIRQ_ARCH_0
> +
> +/*
> + * mc_info entry types
> + * mca machine check info are recorded in mc_info entries.
> + * when fetch mca info, it can use MC_TYPE_... to distinguish
> + * different mca info.
> + */
> +#define MC_TYPE_GLOBAL		0
> +#define MC_TYPE_BANK		1
> +#define MC_TYPE_EXTENDED	2
> +#define MC_TYPE_RECOVERY	3
> +
> +struct mcinfo_common {
> +	uint16_t type; /* structure type */
> +	uint16_t size; /* size of this struct in bytes */
> +};
> +
> +#define MC_FLAG_CORRECTABLE	(1 << 0)
> +#define MC_FLAG_UNCORRECTABLE	(1 << 1)
> +#define MC_FLAG_RECOVERABLE	(1 << 2)
> +#define MC_FLAG_POLLED		(1 << 3)
> +#define MC_FLAG_RESET		(1 << 4)
> +#define MC_FLAG_CMCI		(1 << 5)
> +#define MC_FLAG_MCE		(1 << 6)
> +
> +/* contains x86 global mc information */
> +struct mcinfo_global {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_domid; /* running domain at the time in error */
> +	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
> +	uint32_t mc_socketid; /* physical socket of the physical core */
> +	uint16_t mc_coreid; /* physical impacted core */
> +	uint16_t mc_core_threadid; /* core thread of physical core */
> +	uint32_t mc_apicid;
> +	uint32_t mc_flags;
> +	uint64_t mc_gstatus; /* global status */
> +};
> +
> +/* contains x86 bank mc information */
> +struct mcinfo_bank {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_bank; /* bank nr */
> +	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
> +	uint64_t mc_status; /* bank status */
> +	uint64_t mc_addr; /* bank address */
> +	uint64_t mc_misc;
> +	uint64_t mc_ctrl2;
> +	uint64_t mc_tsc;
> +};
> +
> +struct mcinfo_msr {
> +	uint64_t reg; /* MSR */
> +	uint64_t value; /* MSR value */
> +};
> +
> +/* contains mc information from other or additional mc MSRs */
> +struct mcinfo_extended {
> +	struct mcinfo_common common;
> +	uint32_t mc_msrs; /* Number of msr with valid values. */
> +	/*
> +	 * Currently Intel extended MSR (32/64) include all gp registers
> +	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
> +	 * useful at present. So expand this array to 16/32 to leave room.
> +	 */
> +	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
> +};
> +
> +/* Recovery Action flags. Giving recovery result information to DOM0 */
> +
> +/* Xen takes successful recovery action, the error is recovered */
> +#define REC_ACTION_RECOVERED (0x1 << 0)
> +/* No action is performed by XEN */
> +#define REC_ACTION_NONE (0x1 << 1)
> +/* It's possible DOM0 might take action ownership in some case */
> +#define REC_ACTION_NEED_RESET (0x1 << 2)
> +
> +/*
> + * Different Recovery Action types, if the action is performed successfully,
> + * REC_ACTION_RECOVERED flag will be returned.
> + */
> +
> +/* Page Offline Action */
> +#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
> +/* CPU offline Action */
> +#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
> +/* L3 cache disable Action */
> +#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
> +
> +/*
> + * Below interface used between XEN/DOM0 for passing XEN's recovery action
> + * information to DOM0.
> + */
> +struct page_offline_action {
> +	/* Params for passing the offlined page number to DOM0 */
> +	uint64_t mfn;
> +	uint64_t status;
> +};
> +
> +struct cpu_offline_action {
> +	/* Params for passing the identity of the offlined CPU to DOM0 */
> +	uint32_t mc_socketid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_core_threadid;
> +};
> +
> +#define MAX_UNION_SIZE 16
> +struct mcinfo_recovery {
> +	struct mcinfo_common common;
> +	uint16_t mc_bank; /* bank nr */
> +	uint8_t action_flags;
> +	uint8_t action_types;
> +	union {
> +		struct page_offline_action page_retire;
> +		struct cpu_offline_action cpu_offline;
> +		uint8_t pad[MAX_UNION_SIZE];
> +	} action_info;
> +};
> +
> +
> +#define MCINFO_MAXSIZE 768
> +struct mc_info {
> +	/* Number of mcinfo_* entries in mi_data */
> +	uint32_t mi_nentries;
> +	uint32_t flags;
> +	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mc_info);
> +
> +#define __MC_MSR_ARRAYSIZE 8
> +#define __MC_MSR_MCGCAP 0
> +#define __MC_NMSRS 1
> +#define MC_NCAPS 7
> +struct mcinfo_logical_cpu {
> +	uint32_t mc_cpunr;
> +	uint32_t mc_chipid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_threadid;
> +	uint32_t mc_apicid;
> +	uint32_t mc_clusterid;
> +	uint32_t mc_ncores;
> +	uint32_t mc_ncores_active;
> +	uint32_t mc_nthreads;
> +	uint32_t mc_cpuid_level;
> +	uint32_t mc_family;
> +	uint32_t mc_vendor;
> +	uint32_t mc_model;
> +	uint32_t mc_step;
> +	char mc_vendorid[16];
> +	char mc_brandid[64];
> +	uint32_t mc_cpu_caps[MC_NCAPS];
> +	uint32_t mc_cache_size;
> +	uint32_t mc_cache_alignment;
> +	uint32_t mc_nmsrvals;
> +	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
> +
> +/*
> + * Prototype:
> + *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
> + */
> +#define x86_mcinfo_nentries(_mi)    \
> +	((_mi)->mi_nentries)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
> + */
> +#define x86_mcinfo_first(_mi)       \
> +	((struct mcinfo_common *)(_mi)->mi_data)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
> + */
> +#define x86_mcinfo_next(_mic)       \
> +	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
> +
> +/*
> + * Prototype:
> + *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type);
> + */
> +static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
> +				     struct mc_info *mi, uint16_t type)
> +{
> +	uint32_t i;
> +	struct mcinfo_common *mic;
> +	bool found = 0;
> +
> +	if (!ret || !mi)
> +		return;
> +
> +	mic = x86_mcinfo_first(mi);
> +	for (i = 0; i < x86_mcinfo_nentries(mi); i++) {
> +		if (mic->type == type) {
> +			found = 1;
> +			break;
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	}
> +
> +	*ret = found ? mic : NULL;
> +}
> +
> +/*
> + * Fetch machine check data from hypervisor.
> + */
> +#define XEN_MC_fetch		1
> +struct xen_mc_fetch {
> +	/*
> +	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
> +	 * XEN_MC_ACK if ack'king an earlier fetch
> +	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
> +	 */
> +	uint32_t flags;
> +	uint32_t _pad0;
> +	/* OUT: id for ack, IN: id we are ack'ing */
> +	uint64_t fetch_id;
> +
> +	/* OUT variables. */
> +	GUEST_HANDLE(mc_info) data;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
> +
> +
> +/*
> + * This tells the hypervisor to notify a DomU about the machine check error
> + */
> +#define XEN_MC_notifydomain	2
> +struct xen_mc_notifydomain {
> +	/* IN variables */
> +	uint16_t mc_domid; /* The unprivileged domain to notify */
> +	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
> +
> +	/* IN/OUT variables */
> +	uint32_t flags;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
> +
> +#define XEN_MC_physcpuinfo	3
> +struct xen_mc_physcpuinfo {
> +	/* IN/OUT */
> +	uint32_t ncpus;
> +	uint32_t _pad0;
> +	/* OUT */
> +	GUEST_HANDLE(mcinfo_logical_cpu) info;
> +};
> +
> +#define XEN_MC_msrinject	4
> +#define MC_MSRINJ_MAXMSRS	8
> +struct xen_mc_msrinject {
> +	/* IN */
> +	uint32_t mcinj_cpunr; /* target processor id */
> +	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
> +	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
> +	uint32_t _pad0;
> +	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
> +};
> +
> +/* Flags for mcinj_flags above; bits 16-31 are reserved */
> +#define MC_MSRINJ_F_INTERPOSE	0x1
> +
> +#define XEN_MC_mceinject	5
> +struct xen_mc_mceinject {
> +	unsigned int mceinj_cpunr; /* target processor id */
> +};
> +
> +struct xen_mc {
> +	uint32_t cmd;
> +	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
> +	union {
> +		struct xen_mc_fetch        mc_fetch;
> +		struct xen_mc_notifydomain mc_notifydomain;
> +		struct xen_mc_physcpuinfo  mc_physcpuinfo;
> +		struct xen_mc_msrinject    mc_msrinject;
> +		struct xen_mc_mceinject    mc_mceinject;
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */

OK, besides those comments it looks great. Please re-send with
the modifications.

> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:33:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsc7-00075g-Qm; Mon, 16 Apr 2012 20:33:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJsc7-00075U-1t
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:33:31 +0000
Received: from [85.158.143.99:47547] by server-2.bemta-4.messagelabs.com id
	CF/EA-17550-A128C8F4; Mon, 16 Apr 2012 20:33:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334608405!20523885!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13744 invoked from network); 16 Apr 2012 20:33:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 20:33:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKXK81011717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:33:20 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKXJVq017546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:33:19 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKXJBl002527; Mon, 16 Apr 2012 15:33:19 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:33:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9FC0240280; Mon, 16 Apr 2012 16:28:21 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:28:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120416202821.GC14982@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F8C8211.001D,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
	bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
> >From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Mon, 16 Apr 2012 00:16:58 +0800
> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back point
> 
> When xen hyeprvisor inject vMCE to guest, use native mce handler to handle it

hypervisor

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/xen/enlighten.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 15628d4..346ba64 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  	/*
>  	 * Look for known traps using IST, and substitute them
>  	 * appropriately.  The debugger ones are the only ones we care
> -	 * about.  Xen will handle faults like double_fault and
> -	 * machine_check, so we should never see them.  Warn if
> +	 * about.  Xen will handle faults like double_fault,
> +	 * so we should never see them.  Warn if
>  	 * there's an unexpected IST-using fault handler.
>  	 */
>  	if (addr == (unsigned long)debug)
> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  		return 0;
>  #ifdef CONFIG_X86_MCE
>  	} else if (addr == (unsigned long)machine_check) {
> -		return 0;
> +		/*
> +		 * when xen hyeprvisor inject vMCE to guest,
> +		 * use native mce handler to handle it
> +		 */
> +		;


Can you just take the check out?


>  #endif
>  	} else {
>  		/* Some other trap using IST? */
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:33:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsc7-00075g-Qm; Mon, 16 Apr 2012 20:33:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJsc7-00075U-1t
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:33:31 +0000
Received: from [85.158.143.99:47547] by server-2.bemta-4.messagelabs.com id
	CF/EA-17550-A128C8F4; Mon, 16 Apr 2012 20:33:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334608405!20523885!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcwOTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13744 invoked from network); 16 Apr 2012 20:33:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 20:33:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKXK81011717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:33:20 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKXJVq017546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:33:19 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKXJBl002527; Mon, 16 Apr 2012 15:33:19 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:33:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9FC0240280; Mon, 16 Apr 2012 16:28:21 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:28:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120416202821.GC14982@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F8C8211.001D,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
	bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
> >From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Mon, 16 Apr 2012 00:16:58 +0800
> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back point
> 
> When xen hyeprvisor inject vMCE to guest, use native mce handler to handle it

hypervisor

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/xen/enlighten.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 15628d4..346ba64 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  	/*
>  	 * Look for known traps using IST, and substitute them
>  	 * appropriately.  The debugger ones are the only ones we care
> -	 * about.  Xen will handle faults like double_fault and
> -	 * machine_check, so we should never see them.  Warn if
> +	 * about.  Xen will handle faults like double_fault,
> +	 * so we should never see them.  Warn if
>  	 * there's an unexpected IST-using fault handler.
>  	 */
>  	if (addr == (unsigned long)debug)
> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  		return 0;
>  #ifdef CONFIG_X86_MCE
>  	} else if (addr == (unsigned long)machine_check) {
> -		return 0;
> +		/*
> +		 * when xen hyeprvisor inject vMCE to guest,
> +		 * use native mce handler to handle it
> +		 */
> +		;


Can you just take the check out?


>  #endif
>  	} else {
>  		/* Some other trap using IST? */
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsft-0007J3-KX; Mon, 16 Apr 2012 20:37:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJsfs-0007Iw-Jd
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 20:37:24 +0000
Received: from [85.158.143.35:16603] by server-3.bemta-4.messagelabs.com id
	FF/4C-05853-3038C8F4; Mon, 16 Apr 2012 20:37:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334608641!7343560!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjYxNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26616 invoked from network); 16 Apr 2012 20:37:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 20:37:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKbEOw017770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:37:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKbBRc000406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:37:11 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKb8f5003566; Mon, 16 Apr 2012 15:37:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:37:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 96D8340280; Mon, 16 Apr 2012 16:32:10 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:32:10 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120416203210.GD14982@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F8C82FC.00DB,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 15, 2012 at 02:09:32PM +0800, Lin Ming wrote:
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
>  arch/x86/include/asm/xen/events.h |    1 +
>  arch/x86/xen/smp.c                |   30 ++++++++++++++++++++++++++++++
>  2 files changed, 31 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index 1df3541..cc146d5 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -6,6 +6,7 @@ enum ipi_vector {
>  	XEN_CALL_FUNCTION_VECTOR,
>  	XEN_CALL_FUNCTION_SINGLE_VECTOR,
>  	XEN_SPIN_UNLOCK_VECTOR,
> +	XEN_IRQ_WORK_VECTOR,
>  
>  	XEN_NR_IPIS,
>  };
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 2dc6628..92ad12d 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -16,6 +16,7 @@
>  #include <linux/err.h>
>  #include <linux/slab.h>
>  #include <linux/smp.h>
> +#include <linux/irq_work.h>
>  
>  #include <asm/paravirt.h>
>  #include <asm/desc.h>
> @@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
>  static DEFINE_PER_CPU(int, xen_resched_irq);
>  static DEFINE_PER_CPU(int, xen_callfunc_irq);
>  static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
> +static DEFINE_PER_CPU(int, xen_irq_work);
>  static DEFINE_PER_CPU(int, xen_debug_irq) = -1;
>  
>  static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
>  static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
>  
>  /*
>   * Reschedule call back.
> @@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
>  		goto fail;
>  	per_cpu(xen_callfuncsingle_irq, cpu) = rc;
>  
> +	callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
> +	rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
> +				    cpu,
> +				    xen_irq_work_interrupt,
> +				    IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
> +				    callfunc_name,
> +				    NULL);
> +	if (rc < 0)
> +		goto fail;
> +	per_cpu(xen_irq_work, cpu) = rc;
> +
>  	return 0;
>  
>   fail:
> @@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
>  	if (per_cpu(xen_callfuncsingle_irq, cpu) >= 0)
>  		unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),
>  				       NULL);
> +	if (per_cpu(xen_irq_work, cpu) >= 0)
> +		unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
>  
>  	return rc;
>  }
> @@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
>  	case CALL_FUNCTION_SINGLE_VECTOR:
>  		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
>  		break;
> +	case IRQ_WORK_VECTOR:
> +		xen_vector = XEN_IRQ_WORK_VECTOR;
> +		break;
>  	default:
>  		xen_vector = -1;
>  		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
> @@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
>  	return IRQ_HANDLED;
>  }
>  
> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
> +{
> +	irq_enter();
> +	inc_irq_stat(apic_irq_work_irqs);
> +	irq_work_run();

I think this usually done the other way around:

irq_work_run()
inc_irq_stat(apic_irq_work_irqs)

Or is there an excellent reason for doing it this way?

> +	irq_exit();
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct smp_ops xen_smp_ops __initconst = {
>  	.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
>  	.smp_prepare_cpus = xen_smp_prepare_cpus,
> @@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
>  	unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
>  	unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
>  	unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu), NULL);
> +	unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
>  	native_cpu_die(cpu);
>  }
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsft-0007J3-KX; Mon, 16 Apr 2012 20:37:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJsfs-0007Iw-Jd
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 20:37:24 +0000
Received: from [85.158.143.35:16603] by server-3.bemta-4.messagelabs.com id
	FF/4C-05853-3038C8F4; Mon, 16 Apr 2012 20:37:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334608641!7343560!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjYxNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26616 invoked from network); 16 Apr 2012 20:37:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Apr 2012 20:37:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKbEOw017770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:37:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKbBRc000406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:37:11 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKb8f5003566; Mon, 16 Apr 2012 15:37:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:37:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 96D8340280; Mon, 16 Apr 2012 16:32:10 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:32:10 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120416203210.GD14982@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F8C82FC.00DB,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 15, 2012 at 02:09:32PM +0800, Lin Ming wrote:
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
>  arch/x86/include/asm/xen/events.h |    1 +
>  arch/x86/xen/smp.c                |   30 ++++++++++++++++++++++++++++++
>  2 files changed, 31 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index 1df3541..cc146d5 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -6,6 +6,7 @@ enum ipi_vector {
>  	XEN_CALL_FUNCTION_VECTOR,
>  	XEN_CALL_FUNCTION_SINGLE_VECTOR,
>  	XEN_SPIN_UNLOCK_VECTOR,
> +	XEN_IRQ_WORK_VECTOR,
>  
>  	XEN_NR_IPIS,
>  };
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 2dc6628..92ad12d 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -16,6 +16,7 @@
>  #include <linux/err.h>
>  #include <linux/slab.h>
>  #include <linux/smp.h>
> +#include <linux/irq_work.h>
>  
>  #include <asm/paravirt.h>
>  #include <asm/desc.h>
> @@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
>  static DEFINE_PER_CPU(int, xen_resched_irq);
>  static DEFINE_PER_CPU(int, xen_callfunc_irq);
>  static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
> +static DEFINE_PER_CPU(int, xen_irq_work);
>  static DEFINE_PER_CPU(int, xen_debug_irq) = -1;
>  
>  static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
>  static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
>  
>  /*
>   * Reschedule call back.
> @@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
>  		goto fail;
>  	per_cpu(xen_callfuncsingle_irq, cpu) = rc;
>  
> +	callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
> +	rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
> +				    cpu,
> +				    xen_irq_work_interrupt,
> +				    IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
> +				    callfunc_name,
> +				    NULL);
> +	if (rc < 0)
> +		goto fail;
> +	per_cpu(xen_irq_work, cpu) = rc;
> +
>  	return 0;
>  
>   fail:
> @@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
>  	if (per_cpu(xen_callfuncsingle_irq, cpu) >= 0)
>  		unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),
>  				       NULL);
> +	if (per_cpu(xen_irq_work, cpu) >= 0)
> +		unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
>  
>  	return rc;
>  }
> @@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
>  	case CALL_FUNCTION_SINGLE_VECTOR:
>  		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
>  		break;
> +	case IRQ_WORK_VECTOR:
> +		xen_vector = XEN_IRQ_WORK_VECTOR;
> +		break;
>  	default:
>  		xen_vector = -1;
>  		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
> @@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
>  	return IRQ_HANDLED;
>  }
>  
> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
> +{
> +	irq_enter();
> +	inc_irq_stat(apic_irq_work_irqs);
> +	irq_work_run();

I think this usually done the other way around:

irq_work_run()
inc_irq_stat(apic_irq_work_irqs)

Or is there an excellent reason for doing it this way?

> +	irq_exit();
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct smp_ops xen_smp_ops __initconst = {
>  	.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
>  	.smp_prepare_cpus = xen_smp_prepare_cpus,
> @@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
>  	unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
>  	unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
>  	unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu), NULL);
> +	unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
>  	native_cpu_die(cpu);
>  }
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:43:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsld-0007Zb-EQ; Mon, 16 Apr 2012 20:43:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJslb-0007ZT-D6
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:43:19 +0000
Received: from [85.158.138.51:14209] by server-3.bemta-3.messagelabs.com id
	85/62-04048-6648C8F4; Mon, 16 Apr 2012 20:43:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334608996!22219031!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13124 invoked from network); 16 Apr 2012 20:43:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 20:43:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKh5TQ028530
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:43:06 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKh2f4006072
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:43:03 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKh1Pq009995; Mon, 16 Apr 2012 15:43:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:43:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7AC6A40280; Mon, 16 Apr 2012 16:38:04 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:38:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alessandro Di Federico <ale@clearmind.me>
Message-ID: <20120416203804.GB6037@phenom.dumpdata.com>
References: <ElNbB-ufuspHhZoM35TaM_XjQCGfpzfXwpw-EGz4eBthjwQuefRSAxYw0xkKR2CtXPGlEQ7EPey9gxtE3abkeA@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ElNbB-ufuspHhZoM35TaM_XjQCGfpzfXwpw-EGz4eBthjwQuefRSAxYw0xkKR2CtXPGlEQ7EPey9gxtE3abkeA@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F8C845B.0002,ss=1,re=0.000,fgs=0
Cc: Konrad Scherer <konrad.scherer@windriver.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen & suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 15, 2012 at 04:57:21PM +0200, Alessandro Di Federico wrote:
> Hello, I want to use Xen on my notebook so it's fundamental to have the
> possibility to suspend the machine.
> 
> I know there's some ongoing work to add S3 suspend support to Xen, in
> particular I've tried this:
> 
> https://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/acpi-s3.v9
> 
> But when I try to suspend the system simply freezes.
> 
> Can you give me some hints to make it work or try to make a better
> diagnosis of the problem?

There is a new version of it. But before I point you to it - what version
of Linux are you running and want to try the patches on?

> 
> Thanks!
> Ale

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 20:43:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 20:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJsld-0007Zb-EQ; Mon, 16 Apr 2012 20:43:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SJslb-0007ZT-D6
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 20:43:19 +0000
Received: from [85.158.138.51:14209] by server-3.bemta-3.messagelabs.com id
	85/62-04048-6648C8F4; Mon, 16 Apr 2012 20:43:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334608996!22219031!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13124 invoked from network); 16 Apr 2012 20:43:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 20:43:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3GKh5TQ028530
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Apr 2012 20:43:06 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3GKh2f4006072
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2012 20:43:03 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3GKh1Pq009995; Mon, 16 Apr 2012 15:43:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 13:43:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7AC6A40280; Mon, 16 Apr 2012 16:38:04 -0400 (EDT)
Date: Mon, 16 Apr 2012 16:38:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alessandro Di Federico <ale@clearmind.me>
Message-ID: <20120416203804.GB6037@phenom.dumpdata.com>
References: <ElNbB-ufuspHhZoM35TaM_XjQCGfpzfXwpw-EGz4eBthjwQuefRSAxYw0xkKR2CtXPGlEQ7EPey9gxtE3abkeA@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ElNbB-ufuspHhZoM35TaM_XjQCGfpzfXwpw-EGz4eBthjwQuefRSAxYw0xkKR2CtXPGlEQ7EPey9gxtE3abkeA@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F8C845B.0002,ss=1,re=0.000,fgs=0
Cc: Konrad Scherer <konrad.scherer@windriver.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen & suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 15, 2012 at 04:57:21PM +0200, Alessandro Di Federico wrote:
> Hello, I want to use Xen on my notebook so it's fundamental to have the
> possibility to suspend the machine.
> 
> I know there's some ongoing work to add S3 suspend support to Xen, in
> particular I've tried this:
> 
> https://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/acpi-s3.v9
> 
> But when I try to suspend the system simply freezes.
> 
> Can you give me some hints to make it work or try to make a better
> diagnosis of the problem?

There is a new version of it. But before I point you to it - what version
of Linux are you running and want to try the patches on?

> 
> Thanks!
> Ale

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 21:24:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 21:24:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJtP8-0007sC-Rt; Mon, 16 Apr 2012 21:24:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJtP7-0007s4-Ur
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:24:10 +0000
Received: from [193.109.254.147:18489] by server-2.bemta-14.messagelabs.com id
	38/EB-19409-9FD8C8F4; Mon, 16 Apr 2012 21:24:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334611448!2400547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9327 invoked from network); 16 Apr 2012 21:24:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 21:24:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,431,1330905600"; d="scan'208";a="11963754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 21:24:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 22:24:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJtP5-0005Le-Jl;
	Mon, 16 Apr 2012 21:24:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJtP5-00033h-Gi;
	Mon, 16 Apr 2012 22:24:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12700-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 22:24:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12700: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12700 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12700/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                14322a50bb7a599c8fef376bf40d50cbd1582c01
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 14322a50bb7a599c8fef376bf40d50cbd1582c01
Merge: 52adf95... e816b57...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Apr 16 07:14:08 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 21:24:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 21:24:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJtP8-0007sC-Rt; Mon, 16 Apr 2012 21:24:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJtP7-0007s4-Ur
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:24:10 +0000
Received: from [193.109.254.147:18489] by server-2.bemta-14.messagelabs.com id
	38/EB-19409-9FD8C8F4; Mon, 16 Apr 2012 21:24:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334611448!2400547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9327 invoked from network); 16 Apr 2012 21:24:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 21:24:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,431,1330905600"; d="scan'208";a="11963754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 21:24:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Apr 2012 22:24:08 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJtP5-0005Le-Jl;
	Mon, 16 Apr 2012 21:24:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJtP5-00033h-Gi;
	Mon, 16 Apr 2012 22:24:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12700-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Apr 2012 22:24:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12700: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12700 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12700/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                14322a50bb7a599c8fef376bf40d50cbd1582c01
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 14322a50bb7a599c8fef376bf40d50cbd1582c01
Merge: 52adf95... e816b57...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Apr 16 07:14:08 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 21:40:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 21:40:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJtef-00089R-Ca; Mon, 16 Apr 2012 21:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bugs@humanleg.org.uk>) id 1SJqIy-0001WH-HF
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:05:36 +0000
Received: from [85.158.139.83:15585] by server-9.bemta-5.messagelabs.com id
	C4/B9-09826-F6F5C8F4; Mon, 16 Apr 2012 18:05:35 +0000
X-Env-Sender: bugs@humanleg.org.uk
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334599530!23977526!1
X-Originating-IP: [88.151.129.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTUxLjEyOS4yNCA9PiAzMTgwNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26375 invoked from network); 16 Apr 2012 18:05:31 -0000
Received: from inf-mxout4.simplymailsolutions.com (HELO
	inf-mxout4.simplymailsolutions.com) (88.151.129.24)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:05:31 -0000
Received: from unx-s-manc1.ifeltd.com ([10.1.10.1])
	by inf-mxout4.simplymailsolutions.com (8.14.1/8.14.1) with ESMTP id
	q3GI5Fu3027658; Mon, 16 Apr 2012 19:05:15 +0100
Received: from leclerc.lan (cpc2-bedf1-0-0-cust49.9-1.cable.virginmedia.com
	[81.105.12.50])
	by unx-s-manc1.ifeltd.com (Postfix) with ESMTP id 8534C14E061F;
	Mon, 16 Apr 2012 19:05:15 +0100 (BST)
From: Robert Scott <bugs@humanleg.org.uk>
Organization: none
To: Jonathan Nieder <jrnieder@gmail.com>
Date: Mon, 16 Apr 2012 19:05:05 +0100
User-Agent: KMail/1.9.9
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<20110829041532.GA22087@elie.gateway.2wire.net>
	<20120415140628.GA4536@burratino>
In-Reply-To: <20120415140628.GA4536@burratino>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201204161905.13260.bugs@humanleg.org.uk>
X-Mailman-Approved-At: Mon, 16 Apr 2012 21:40:11 +0000
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: bugs@humanleg.org.uk
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sunday 15 April 2012, Jonathan Nieder wrote:
> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
> it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
> semantics in fixup_irqs()") will fix this.

Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.


robert.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 21:40:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 21:40:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJtef-00089R-Ca; Mon, 16 Apr 2012 21:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bugs@humanleg.org.uk>) id 1SJqIy-0001WH-HF
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 18:05:36 +0000
Received: from [85.158.139.83:15585] by server-9.bemta-5.messagelabs.com id
	C4/B9-09826-F6F5C8F4; Mon, 16 Apr 2012 18:05:35 +0000
X-Env-Sender: bugs@humanleg.org.uk
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334599530!23977526!1
X-Originating-IP: [88.151.129.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTUxLjEyOS4yNCA9PiAzMTgwNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26375 invoked from network); 16 Apr 2012 18:05:31 -0000
Received: from inf-mxout4.simplymailsolutions.com (HELO
	inf-mxout4.simplymailsolutions.com) (88.151.129.24)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Apr 2012 18:05:31 -0000
Received: from unx-s-manc1.ifeltd.com ([10.1.10.1])
	by inf-mxout4.simplymailsolutions.com (8.14.1/8.14.1) with ESMTP id
	q3GI5Fu3027658; Mon, 16 Apr 2012 19:05:15 +0100
Received: from leclerc.lan (cpc2-bedf1-0-0-cust49.9-1.cable.virginmedia.com
	[81.105.12.50])
	by unx-s-manc1.ifeltd.com (Postfix) with ESMTP id 8534C14E061F;
	Mon, 16 Apr 2012 19:05:15 +0100 (BST)
From: Robert Scott <bugs@humanleg.org.uk>
Organization: none
To: Jonathan Nieder <jrnieder@gmail.com>
Date: Mon, 16 Apr 2012 19:05:05 +0100
User-Agent: KMail/1.9.9
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<20110829041532.GA22087@elie.gateway.2wire.net>
	<20120415140628.GA4536@burratino>
In-Reply-To: <20120415140628.GA4536@burratino>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201204161905.13260.bugs@humanleg.org.uk>
X-Mailman-Approved-At: Mon, 16 Apr 2012 21:40:11 +0000
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: bugs@humanleg.org.uk
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sunday 15 April 2012, Jonathan Nieder wrote:
> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
> it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
> semantics in fixup_irqs()") will fix this.

Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.


robert.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 23:02:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 23:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJuvV-0000CP-N6; Mon, 16 Apr 2012 23:01:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SJuvT-0000CI-Dz
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 23:01:39 +0000
Received: from [85.158.143.35:26540] by server-2.bemta-4.messagelabs.com id
	EE/60-17550-2D4AC8F4; Mon, 16 Apr 2012 23:01:38 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334617297!11274400!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29475 invoked from network); 16 Apr 2012 23:01:37 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 23:01:37 -0000
Received: by bkcjg9 with SMTP id jg9so5151556bkc.32
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 16:01:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=z5kHVaquzhW+RFeEwte1OUnpdy5g8eh+dRNHzdEWmzY=;
	b=Fd5TMNewsBVQ6Fy4i4XGu6tOlvrIw0VZlI4UGMl4wOiemek1gGyksSGC93JbdmYiiM
	QECJMqxB6ZicyAH6qB+GOM47f+tfMW8zNsZN14NyICoHYe89W3GboDSvXkso5q9omlkI
	MmT/Xr3ErZf7IFhVvLQrpy4SKW9fl4IjudGeNEKQvDKKNGXjgS5/xs0WFHTRN6cCAYoQ
	ymDxe7h9Vb3Opfqr6H7HBb/BclXvWjwjMhQnl8AehyFaKGIMrvuAe+fVGTesOPRwW1E5
	dJNiHW9xbT1EViMstn12DKDZEb1NBF03hFOtcyfowWQ3+hQ4zjhG7jqbYB9ddhsI8AJ2
	LqFg==
MIME-Version: 1.0
Received: by 10.204.133.196 with SMTP id g4mr4173807bkt.0.1334617296767; Mon,
	16 Apr 2012 16:01:36 -0700 (PDT)
Received: by 10.204.166.3 with HTTP; Mon, 16 Apr 2012 16:01:36 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <20120416181744.GF13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
	<20120416181744.GF13111@ocelot.phlegethon.org>
Date: Mon, 16 Apr 2012 16:01:36 -0700
Message-ID: <CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQm6s/WfyjpfbKQwin7D5jMO3dKkfx5xjz/lCbQbm11F2aKU3VL3/SmOx/nFQL8VwArIVvq6
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 11:17 AM, Tim Deegan <tim@xen.org> wrote:
> At 10:52 -0700 on 16 Apr (1334573568), Dan Magenheimer wrote:
>> > From: Tim Deegan [mailto:tim@xen.org]
>> > Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as un=
stable
>> >
>> > At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
>> > > Hmmm... I spent a great deal of time on TSC support in the hypervisor
>> > > 2-3 years ago. =A0I worked primarily on PV, but Intel supposedly was=
 tracking
>> > > everything on HVM as well. =A0There's most likely a bug or two still=
 lurking
>> > > but, for all guests, with the default tsc_mode, TSC is provided by X=
en
>> > > as an absolutely stable clock source. =A0If Xen determines that the =
underlying
>> > > hardware declares that TSC is stable, guest rdtsc instructions are n=
ot trapped.
>> > > If it is not, Xen emulates all guest rdtsc instructions. =A0After a =
migration or
>> > > save/restore, TSC is always emulated. =A0The result is (ignoring pos=
sible
>> > > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized a=
cross
>> > > CPUs; and c) constant rate. =A0Even across migration/save/restore.
>> >
>> > AIUI, this thread is about the PV-time clock source, not about the TSC
>> > itself. =A0Even if the TSC is emulated (or in some other way made
>> > "stable") the PV wallclock is not necessarily stable across migration.
>> > But since migration is controlled by the kernel, presumably the kernel
>> > can DTRT about it.
>>
>> Under what circumstances is PV wallclock not stable across migration?
>
> The wallclock is host-local, so I don't think it can be guaranteed to be
> strictly monotonic across migration. =A0But as I said that's OK because
> the Xen code in the kernel is in control during migration.
>
>> > > In fact, it might be wise for a Xen-savvy kernel to check to see
>> > > if it is running on Xen-4.0+ and, if so, force clocksource=3Dtsc
>> > > and tsc=3Dreliable.
>> >
>> > That seems like overdoing it. =A0Certainly it's not OK unless it can a=
lso
>> > check that Xen is providing a stable TSC (i.e. that tscmode=3D=3D1).
>>
>> Xen guarantees a stable TSC for the default (tsc_mode=3D=3D0) also.
>>
>> If the vm.cfg file explicitly sets a guest tsc_mode=3D=3D2, you are corr=
ect
>> that pvclock is still necessary. =A0But as the documentation says:
>> tsc_mode=3D=3D2 should be set if "it is certain that all apps running in=
 this
>> VM are TSC-resilient and highest performance is required". =A0In
>> the case we are talking about, the PV guest kernel itself isn't TSC-
>> resilient!
>
> Only if we deliberately break it! :)
>
>> In any case, IIRC, there is a pvcpuid instruction to determine the
>> tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
>> also check to ensure the tsc_mode wasn't overridden and set to 2.
>
> Yes, that's what I was suggesting.
>
>> > In the case where the PV clock has been selected, can it not be marked
>> > unstable without also marking the TSC unstable?
>>
>> I'm not sure I understand...
>>
>> Are you talking about the HVM case of an upstream kernel, maybe
>> when the clocksource is manually overridden on the kernel command
>> line or after boot with sysfs?
>
> I'm talking about any case where the clocksource =3D=3D xen.
>
>> If pvclock is necessary (e.g. old Xen), how would it be
>> marked unstable? (I didn't know there was code to do that.)
>
> I think I'm confused by terminology. =A0Maybe David can correct me. =A0My
> understanding was that there is some concept inside linux of a time
> source being 'stable', which requires it to be synchronized, monotonic
> and constant-rate. =A0The PV clock is two of those things (within a
> reasonable tolerance) but may not be monotonic over migration. =A0I was
> suggesting that, however linux deals with that, it can probably do it
> without changing its opinion of whether the TSC is stable.

In fact the sched_clock_stable is only regarding one Intel processor
feature named "Invarient TSC"(a.k.a Non-stop TSC).

I've reported the original issue to xen-devel, and purpose one patch
to fix CPUID filter in the libxc of Xen.

I think mask CPUID bit in the hypervisor is better than make this
change in the kernel, since Xen controlled what to present to the
guest, it doesn't make sense if we present a feature to the guest, and
hack the kernel to disable this feature at the same time.

I haven't dug much into the code, but here is the background(most
copied from my xen-devel post):

Recently we got some reports of migration hang on latest
Debian(2.6.32-41kernel package) kernel with some certain machines(but
it's hard to debug on them since they're customer's machine).

Booting dmesg snippet below:

[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 3.4.2 (preserve-AD)
[    0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1
nr_node_ids:1
[    0.000000] PERCPU: Embedded 15 pages/cpu @c1608000 s37656 r0
d23784 u65536
[    0.000000] pcpu-alloc: s37656 r0 d23784 u65536 alloc=3D16*4096
[    0.000000] pcpu-alloc: [0] 0
[508119.807590] trying to map vcpu_info 0 at c1609010, mfn 992cac,
offset 16
[508119.807593] cpu 0 using vcpu_info at c1609010
[508119.807594] Xen: using vcpu_info placement
[508119.807598] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 32416

Dmesg show that when booting, timestamp of printk jumped from 0 to a
big number([508119.807590] in this case) immediately.

And when migrating:

[509508.914333] suspending xenstore...
[516212.055921] trying to map vcpu_info 0 at c1609010, mfn 895fd7,
offset 16
[516212.055930] cpu 0 using vcpu_info at c1609010

Timestamp jumped again. We can reproduce above issues on our Sandy
Bridge machines.

After this, call trace and guest hang *maybe* observed on some machines:

[516383.019499] INFO: task xenwatch:12 blocked for more than 120
seconds.
[516383.019566] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[516383.019578] xenwatch      D c1610e20     0    12      2 0x00000000
[516383.019591]  c781eec0 00000246 c1610e58 c1610e20 c781f300 c1441e20
c1441e20 001cf000
[516383.019605]  c781f07c c1610e20 00000000 00000001 c1441e20 c62e01c0
c1610e20 c62e01c0
[516383.019617]  c127e18e c781f07c c7830020 c7830020 c1441e20 c1441e20
c127f2f1 c781f080
[516383.019629] Call Trace:
[516383.019640]  [<c127e18e>] ? schedule+0x78f/0x7dc
[516383.019645]  [<c127f2f1>] ? _spin_unlock_irqrestore+0xd/0xf
[516383.019649]  [<c127e4a1>] ? schedule_timeout+0x20/0xb0
[516383.019656]  [<c100573c>] ? xen_force_evtchn_callback+0xc/0x10
[516383.019660]  [<c127e3aa>] ? wait_for_common+0xa4/0x100
[516383.019665]  [<c1033315>] ? default_wake_function+0x0/0x8
[516383.019671]  [<c104a144>] ? kthread_stop+0x4f/0x8e
[516383.019675]  [<c1047883>] ? cleanup_workqueue_thread+0x3a/0x45
[516383.019679]  [<c1047903>] ? destroy_workqueue+0x56/0x85
[516383.019684]  [<c106a395>] ? stop_machine_destroy+0x23/0x37
[516383.019690]  [<c11962d8>] ? shutdown_handler+0x200/0x22f
[516383.019694]  [<c1197439>] ? xenwatch_thread+0xdc/0x103
[516383.019698]  [<c104a322>] ? autoremove_wake_function+0x0/0x2d
[516383.019701]  [<c119735d>] ? xenwatch_thread+0x0/0x103
[516383.019705]  [<c104a0f0>] ? kthread+0x61/0x66
[516383.019709]  [<c104a08f>] ? kthread+0x0/0x66
[516383.019714]  [<c1008d87>] ? kernel_thread_helper+0x7/0x10

But I _cannot_ reproduce the call trace and hang on our Sandy Bridge.

So I think there are maybe *two* bugs in this issue, one caused time
jump(detail below), the other in the kernel triggered by the first bug
sometime, thus result in migration fail.

I've spent some time to identify the timestamp jump issue, and finally
found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
called non-stop TSC). The present of the feature would enable a
parameter in the kernel named: sched_clock_stable. Seems this
parameter is unable to work with Xen's pvclock. If
sched_clock_stable() is set, value returned by xen_clocksource_read()
would be returned as sched_clock_cpu() directly(rather than calculated
through sched_clock_local()), but CMIIW the value returned by
xen_clocksource_read() is based on host(vcpu) uptime rather than this
VM's uptime, then result in the timestamp jump.

I've compiled a kernel, force sched_clock_stable=3D0, then it solved the
timestamp jump issue as expected. Luckily, seems it also solved the
call trace and guest hang issue as well.

I've posted a patch to mask the CPUID leaf 0x80000007 in Xen. I think
the issue can be easily reproduced using a Westmere or SandyBridge
machine(my old colleagues at Intel said the feature likely existed
after Nehalem) running newer version of PV guest, check the guest
cpuinfo you would see nonstop_tsc, and you would notice the abnormal
timestamp of printk.

-- =

regards
Yang, Sheng

>
> If the PV clocksource works, and works in more configurations than TSC,
> I don't see much advantage of deprecating it in favour of TSC. =A0But I
> don't have any huge objection to it either, I guess, as long as it only
> happens when it's safe.
>
> And on older Xens, or for tsc_mode=3D=3D2, the kernel probably ought to m=
ark
> the TSC as unstable, because it is.
>
> Cheers,
>
> Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 23:02:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 23:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJuvV-0000CP-N6; Mon, 16 Apr 2012 23:01:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sheng@yasker.org>) id 1SJuvT-0000CI-Dz
	for xen-devel@lists.xen.org; Mon, 16 Apr 2012 23:01:39 +0000
Received: from [85.158.143.35:26540] by server-2.bemta-4.messagelabs.com id
	EE/60-17550-2D4AC8F4; Mon, 16 Apr 2012 23:01:38 +0000
X-Env-Sender: sheng@yasker.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334617297!11274400!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29475 invoked from network); 16 Apr 2012 23:01:37 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 23:01:37 -0000
Received: by bkcjg9 with SMTP id jg9so5151556bkc.32
	for <xen-devel@lists.xen.org>; Mon, 16 Apr 2012 16:01:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=z5kHVaquzhW+RFeEwte1OUnpdy5g8eh+dRNHzdEWmzY=;
	b=Fd5TMNewsBVQ6Fy4i4XGu6tOlvrIw0VZlI4UGMl4wOiemek1gGyksSGC93JbdmYiiM
	QECJMqxB6ZicyAH6qB+GOM47f+tfMW8zNsZN14NyICoHYe89W3GboDSvXkso5q9omlkI
	MmT/Xr3ErZf7IFhVvLQrpy4SKW9fl4IjudGeNEKQvDKKNGXjgS5/xs0WFHTRN6cCAYoQ
	ymDxe7h9Vb3Opfqr6H7HBb/BclXvWjwjMhQnl8AehyFaKGIMrvuAe+fVGTesOPRwW1E5
	dJNiHW9xbT1EViMstn12DKDZEb1NBF03hFOtcyfowWQ3+hQ4zjhG7jqbYB9ddhsI8AJ2
	LqFg==
MIME-Version: 1.0
Received: by 10.204.133.196 with SMTP id g4mr4173807bkt.0.1334617296767; Mon,
	16 Apr 2012 16:01:36 -0700 (PDT)
Received: by 10.204.166.3 with HTTP; Mon, 16 Apr 2012 16:01:36 -0700 (PDT)
X-Originating-IP: [63.110.51.11]
In-Reply-To: <20120416181744.GF13111@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
	<20120416181744.GF13111@ocelot.phlegethon.org>
Date: Mon, 16 Apr 2012 16:01:36 -0700
Message-ID: <CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
From: Sheng Yang <sheng@yasker.org>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQm6s/WfyjpfbKQwin7D5jMO3dKkfx5xjz/lCbQbm11F2aKU3VL3/SmOx/nFQL8VwArIVvq6
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 11:17 AM, Tim Deegan <tim@xen.org> wrote:
> At 10:52 -0700 on 16 Apr (1334573568), Dan Magenheimer wrote:
>> > From: Tim Deegan [mailto:tim@xen.org]
>> > Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as un=
stable
>> >
>> > At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
>> > > Hmmm... I spent a great deal of time on TSC support in the hypervisor
>> > > 2-3 years ago. =A0I worked primarily on PV, but Intel supposedly was=
 tracking
>> > > everything on HVM as well. =A0There's most likely a bug or two still=
 lurking
>> > > but, for all guests, with the default tsc_mode, TSC is provided by X=
en
>> > > as an absolutely stable clock source. =A0If Xen determines that the =
underlying
>> > > hardware declares that TSC is stable, guest rdtsc instructions are n=
ot trapped.
>> > > If it is not, Xen emulates all guest rdtsc instructions. =A0After a =
migration or
>> > > save/restore, TSC is always emulated. =A0The result is (ignoring pos=
sible
>> > > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized a=
cross
>> > > CPUs; and c) constant rate. =A0Even across migration/save/restore.
>> >
>> > AIUI, this thread is about the PV-time clock source, not about the TSC
>> > itself. =A0Even if the TSC is emulated (or in some other way made
>> > "stable") the PV wallclock is not necessarily stable across migration.
>> > But since migration is controlled by the kernel, presumably the kernel
>> > can DTRT about it.
>>
>> Under what circumstances is PV wallclock not stable across migration?
>
> The wallclock is host-local, so I don't think it can be guaranteed to be
> strictly monotonic across migration. =A0But as I said that's OK because
> the Xen code in the kernel is in control during migration.
>
>> > > In fact, it might be wise for a Xen-savvy kernel to check to see
>> > > if it is running on Xen-4.0+ and, if so, force clocksource=3Dtsc
>> > > and tsc=3Dreliable.
>> >
>> > That seems like overdoing it. =A0Certainly it's not OK unless it can a=
lso
>> > check that Xen is providing a stable TSC (i.e. that tscmode=3D=3D1).
>>
>> Xen guarantees a stable TSC for the default (tsc_mode=3D=3D0) also.
>>
>> If the vm.cfg file explicitly sets a guest tsc_mode=3D=3D2, you are corr=
ect
>> that pvclock is still necessary. =A0But as the documentation says:
>> tsc_mode=3D=3D2 should be set if "it is certain that all apps running in=
 this
>> VM are TSC-resilient and highest performance is required". =A0In
>> the case we are talking about, the PV guest kernel itself isn't TSC-
>> resilient!
>
> Only if we deliberately break it! :)
>
>> In any case, IIRC, there is a pvcpuid instruction to determine the
>> tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
>> also check to ensure the tsc_mode wasn't overridden and set to 2.
>
> Yes, that's what I was suggesting.
>
>> > In the case where the PV clock has been selected, can it not be marked
>> > unstable without also marking the TSC unstable?
>>
>> I'm not sure I understand...
>>
>> Are you talking about the HVM case of an upstream kernel, maybe
>> when the clocksource is manually overridden on the kernel command
>> line or after boot with sysfs?
>
> I'm talking about any case where the clocksource =3D=3D xen.
>
>> If pvclock is necessary (e.g. old Xen), how would it be
>> marked unstable? (I didn't know there was code to do that.)
>
> I think I'm confused by terminology. =A0Maybe David can correct me. =A0My
> understanding was that there is some concept inside linux of a time
> source being 'stable', which requires it to be synchronized, monotonic
> and constant-rate. =A0The PV clock is two of those things (within a
> reasonable tolerance) but may not be monotonic over migration. =A0I was
> suggesting that, however linux deals with that, it can probably do it
> without changing its opinion of whether the TSC is stable.

In fact the sched_clock_stable is only regarding one Intel processor
feature named "Invarient TSC"(a.k.a Non-stop TSC).

I've reported the original issue to xen-devel, and purpose one patch
to fix CPUID filter in the libxc of Xen.

I think mask CPUID bit in the hypervisor is better than make this
change in the kernel, since Xen controlled what to present to the
guest, it doesn't make sense if we present a feature to the guest, and
hack the kernel to disable this feature at the same time.

I haven't dug much into the code, but here is the background(most
copied from my xen-devel post):

Recently we got some reports of migration hang on latest
Debian(2.6.32-41kernel package) kernel with some certain machines(but
it's hard to debug on them since they're customer's machine).

Booting dmesg snippet below:

[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 3.4.2 (preserve-AD)
[    0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1
nr_node_ids:1
[    0.000000] PERCPU: Embedded 15 pages/cpu @c1608000 s37656 r0
d23784 u65536
[    0.000000] pcpu-alloc: s37656 r0 d23784 u65536 alloc=3D16*4096
[    0.000000] pcpu-alloc: [0] 0
[508119.807590] trying to map vcpu_info 0 at c1609010, mfn 992cac,
offset 16
[508119.807593] cpu 0 using vcpu_info at c1609010
[508119.807594] Xen: using vcpu_info placement
[508119.807598] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 32416

Dmesg show that when booting, timestamp of printk jumped from 0 to a
big number([508119.807590] in this case) immediately.

And when migrating:

[509508.914333] suspending xenstore...
[516212.055921] trying to map vcpu_info 0 at c1609010, mfn 895fd7,
offset 16
[516212.055930] cpu 0 using vcpu_info at c1609010

Timestamp jumped again. We can reproduce above issues on our Sandy
Bridge machines.

After this, call trace and guest hang *maybe* observed on some machines:

[516383.019499] INFO: task xenwatch:12 blocked for more than 120
seconds.
[516383.019566] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[516383.019578] xenwatch      D c1610e20     0    12      2 0x00000000
[516383.019591]  c781eec0 00000246 c1610e58 c1610e20 c781f300 c1441e20
c1441e20 001cf000
[516383.019605]  c781f07c c1610e20 00000000 00000001 c1441e20 c62e01c0
c1610e20 c62e01c0
[516383.019617]  c127e18e c781f07c c7830020 c7830020 c1441e20 c1441e20
c127f2f1 c781f080
[516383.019629] Call Trace:
[516383.019640]  [<c127e18e>] ? schedule+0x78f/0x7dc
[516383.019645]  [<c127f2f1>] ? _spin_unlock_irqrestore+0xd/0xf
[516383.019649]  [<c127e4a1>] ? schedule_timeout+0x20/0xb0
[516383.019656]  [<c100573c>] ? xen_force_evtchn_callback+0xc/0x10
[516383.019660]  [<c127e3aa>] ? wait_for_common+0xa4/0x100
[516383.019665]  [<c1033315>] ? default_wake_function+0x0/0x8
[516383.019671]  [<c104a144>] ? kthread_stop+0x4f/0x8e
[516383.019675]  [<c1047883>] ? cleanup_workqueue_thread+0x3a/0x45
[516383.019679]  [<c1047903>] ? destroy_workqueue+0x56/0x85
[516383.019684]  [<c106a395>] ? stop_machine_destroy+0x23/0x37
[516383.019690]  [<c11962d8>] ? shutdown_handler+0x200/0x22f
[516383.019694]  [<c1197439>] ? xenwatch_thread+0xdc/0x103
[516383.019698]  [<c104a322>] ? autoremove_wake_function+0x0/0x2d
[516383.019701]  [<c119735d>] ? xenwatch_thread+0x0/0x103
[516383.019705]  [<c104a0f0>] ? kthread+0x61/0x66
[516383.019709]  [<c104a08f>] ? kthread+0x0/0x66
[516383.019714]  [<c1008d87>] ? kernel_thread_helper+0x7/0x10

But I _cannot_ reproduce the call trace and hang on our Sandy Bridge.

So I think there are maybe *two* bugs in this issue, one caused time
jump(detail below), the other in the kernel triggered by the first bug
sometime, thus result in migration fail.

I've spent some time to identify the timestamp jump issue, and finally
found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
called non-stop TSC). The present of the feature would enable a
parameter in the kernel named: sched_clock_stable. Seems this
parameter is unable to work with Xen's pvclock. If
sched_clock_stable() is set, value returned by xen_clocksource_read()
would be returned as sched_clock_cpu() directly(rather than calculated
through sched_clock_local()), but CMIIW the value returned by
xen_clocksource_read() is based on host(vcpu) uptime rather than this
VM's uptime, then result in the timestamp jump.

I've compiled a kernel, force sched_clock_stable=3D0, then it solved the
timestamp jump issue as expected. Luckily, seems it also solved the
call trace and guest hang issue as well.

I've posted a patch to mask the CPUID leaf 0x80000007 in Xen. I think
the issue can be easily reproduced using a Westmere or SandyBridge
machine(my old colleagues at Intel said the feature likely existed
after Nehalem) running newer version of PV guest, check the guest
cpuinfo you would see nonstop_tsc, and you would notice the abnormal
timestamp of printk.

-- =

regards
Yang, Sheng

>
> If the PV clocksource works, and works in more configurations than TSC,
> I don't see much advantage of deprecating it in favour of TSC. =A0But I
> don't have any huge objection to it either, I guess, as long as it only
> happens when it's safe.
>
> And on older Xens, or for tsc_mode=3D=3D2, the kernel probably ought to m=
ark
> the TSC as unstable, because it is.
>
> Cheers,
>
> Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 23:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 23:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJvTu-0000So-T7; Mon, 16 Apr 2012 23:37:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJvTt-0000Sj-NU
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 23:37:14 +0000
Received: from [85.158.143.35:31502] by server-2.bemta-4.messagelabs.com id
	28/2A-17550-92DAC8F4; Mon, 16 Apr 2012 23:37:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334619431!18887042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8273 invoked from network); 16 Apr 2012 23:37:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 23:37:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208";a="11964720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 23:37:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 00:37:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJvTq-0006Ab-3P;
	Mon, 16 Apr 2012 23:37:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJvTq-0006gZ-09;
	Tue, 17 Apr 2012 00:37:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12701-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 00:37:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12701: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12701 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12701/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12698

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a06e6cdeafe3
baseline version:
 xen                  6b72eb3b40cf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a06e6cdeafe3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a06e6cdeafe3
+ branch=xen-unstable
+ revision=a06e6cdeafe3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a06e6cdeafe3 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 16 23:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Apr 2012 23:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJvTu-0000So-T7; Mon, 16 Apr 2012 23:37:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SJvTt-0000Sj-NU
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 23:37:14 +0000
Received: from [85.158.143.35:31502] by server-2.bemta-4.messagelabs.com id
	28/2A-17550-92DAC8F4; Mon, 16 Apr 2012 23:37:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334619431!18887042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8273 invoked from network); 16 Apr 2012 23:37:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Apr 2012 23:37:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208";a="11964720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Apr 2012 23:37:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 00:37:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SJvTq-0006Ab-3P;
	Mon, 16 Apr 2012 23:37:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SJvTq-0006gZ-09;
	Tue, 17 Apr 2012 00:37:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12701-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 00:37:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12701: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12701 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12701/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12698

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a06e6cdeafe3
baseline version:
 xen                  6b72eb3b40cf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a06e6cdeafe3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a06e6cdeafe3
+ branch=xen-unstable
+ revision=a06e6cdeafe3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a06e6cdeafe3 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 00:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 00:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJwIl-0001Rh-LA; Tue, 17 Apr 2012 00:29:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJwIk-0001Rc-0q
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 00:29:46 +0000
Received: from [85.158.138.51:50604] by server-1.bemta-3.messagelabs.com id
	97/18-11491-979BC8F4; Tue, 17 Apr 2012 00:29:45 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334622582!22450536!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NDMyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23147 invoked from network); 17 Apr 2012 00:29:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 00:29:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3H0TUns012537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 00:29:31 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3H0TTGx021887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 00:29:29 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3H0TRBK013240; Mon, 16 Apr 2012 19:29:28 -0500
MIME-Version: 1.0
Message-ID: <1019c5a1-983d-42c0-9f18-e3db8d10455f@default>
Date: Mon, 16 Apr 2012 17:29:19 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Sheng Yang <sheng@yasker.org>, Tim Deegan <tim@xen.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
	<20120416181744.GF13111@ocelot.phlegethon.org>
	<CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
In-Reply-To: <CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020205.4F8CB96C.00B6,ss=1,re=-2.300,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Sheng Yang [mailto:sheng@yasker.org]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unsta=
ble

Hi Sheng --

See reply at the very end...

> On Mon, Apr 16, 2012 at 11:17 AM, Tim Deegan <tim@xen.org> wrote:
> > At 10:52 -0700 on 16 Apr (1334573568), Dan Magenheimer wrote:
> >> > From: Tim Deegan [mailto:tim@xen.org]
> >> > Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as =
unstable
> >> >
> >> > At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> >> > > Hmmm... I spent a great deal of time on TSC support in the hypervi=
sor
> >> > > 2-3 years ago. =A0I worked primarily on PV, but Intel supposedly w=
as tracking
> >> > > everything on HVM as well. =A0There's most likely a bug or two sti=
ll lurking
> >> > > but, for all guests, with the default tsc_mode, TSC is provided by=
 Xen
> >> > > as an absolutely stable clock source. =A0If Xen determines that th=
e underlying
> >> > > hardware declares that TSC is stable, guest rdtsc instructions are=
 not trapped.
> >> > > If it is not, Xen emulates all guest rdtsc instructions. =A0After =
a migration or
> >> > > save/restore, TSC is always emulated. =A0The result is (ignoring p=
ossible
> >> > > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized=
 across
> >> > > CPUs; and c) constant rate. =A0Even across migration/save/restore.
> >> >
> >> > AIUI, this thread is about the PV-time clock source, not about the T=
SC
> >> > itself. =A0Even if the TSC is emulated (or in some other way made
> >> > "stable") the PV wallclock is not necessarily stable across migratio=
n.
> >> > But since migration is controlled by the kernel, presumably the kern=
el
> >> > can DTRT about it.
> >>
> >> Under what circumstances is PV wallclock not stable across migration?
> >
> > The wallclock is host-local, so I don't think it can be guaranteed to be
> > strictly monotonic across migration. =A0But as I said that's OK because
> > the Xen code in the kernel is in control during migration.
> >
> >> > > In fact, it might be wise for a Xen-savvy kernel to check to see
> >> > > if it is running on Xen-4.0+ and, if so, force clocksource=3Dtsc
> >> > > and tsc=3Dreliable.
> >> >
> >> > That seems like overdoing it. =A0Certainly it's not OK unless it can=
 also
> >> > check that Xen is providing a stable TSC (i.e. that tscmode=3D=3D1).
> >>
> >> Xen guarantees a stable TSC for the default (tsc_mode=3D=3D0) also.
> >>
> >> If the vm.cfg file explicitly sets a guest tsc_mode=3D=3D2, you are co=
rrect
> >> that pvclock is still necessary. =A0But as the documentation says:
> >> tsc_mode=3D=3D2 should be set if "it is certain that all apps running =
in this
> >> VM are TSC-resilient and highest performance is required". =A0In
> >> the case we are talking about, the PV guest kernel itself isn't TSC-
> >> resilient!
> >
> > Only if we deliberately break it! :)
> >
> >> In any case, IIRC, there is a pvcpuid instruction to determine the
> >> tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
> >> also check to ensure the tsc_mode wasn't overridden and set to 2.
> >
> > Yes, that's what I was suggesting.
> >
> >> > In the case where the PV clock has been selected, can it not be mark=
ed
> >> > unstable without also marking the TSC unstable?
> >>
> >> I'm not sure I understand...
> >>
> >> Are you talking about the HVM case of an upstream kernel, maybe
> >> when the clocksource is manually overridden on the kernel command
> >> line or after boot with sysfs?
> >
> > I'm talking about any case where the clocksource =3D=3D xen.
> >
> >> If pvclock is necessary (e.g. old Xen), how would it be
> >> marked unstable? (I didn't know there was code to do that.)
> >
> > I think I'm confused by terminology. =A0Maybe David can correct me. =A0=
My
> > understanding was that there is some concept inside linux of a time
> > source being 'stable', which requires it to be synchronized, monotonic
> > and constant-rate. =A0The PV clock is two of those things (within a
> > reasonable tolerance) but may not be monotonic over migration. =A0I was
> > suggesting that, however linux deals with that, it can probably do it
> > without changing its opinion of whether the TSC is stable.
> =

> In fact the sched_clock_stable is only regarding one Intel processor
> feature named "Invarient TSC"(a.k.a Non-stop TSC).
> =

> I've reported the original issue to xen-devel, and purpose one patch
> to fix CPUID filter in the libxc of Xen.
> =

> I think mask CPUID bit in the hypervisor is better than make this
> change in the kernel, since Xen controlled what to present to the
> guest, it doesn't make sense if we present a feature to the guest, and
> hack the kernel to disable this feature at the same time.
> =

> I haven't dug much into the code, but here is the background(most
> copied from my xen-devel post):
> =

> Recently we got some reports of migration hang on latest
> Debian(2.6.32-41kernel package) kernel with some certain machines(but
> it's hard to debug on them since they're customer's machine).
> =

> Booting dmesg snippet below:
> =

> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 3.4.2 (preserve-AD)
> [    0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1
> nr_node_ids:1
> [    0.000000] PERCPU: Embedded 15 pages/cpu @c1608000 s37656 r0
> d23784 u65536
> [    0.000000] pcpu-alloc: s37656 r0 d23784 u65536 alloc=3D16*4096
> [    0.000000] pcpu-alloc: [0] 0
> [508119.807590] trying to map vcpu_info 0 at c1609010, mfn 992cac,
> offset 16
> [508119.807593] cpu 0 using vcpu_info at c1609010
> [508119.807594] Xen: using vcpu_info placement
> [508119.807598] Built 1 zonelists in Zone order, mobility grouping on.
>  Total pages: 32416
> =

> Dmesg show that when booting, timestamp of printk jumped from 0 to a
> big number([508119.807590] in this case) immediately.
> =

> And when migrating:
> =

> [509508.914333] suspending xenstore...
> [516212.055921] trying to map vcpu_info 0 at c1609010, mfn 895fd7,
> offset 16
> [516212.055930] cpu 0 using vcpu_info at c1609010
> =

> Timestamp jumped again. We can reproduce above issues on our Sandy
> Bridge machines.
> =

> After this, call trace and guest hang *maybe* observed on some machines:
> =

> [516383.019499] INFO: task xenwatch:12 blocked for more than 120
> seconds.
> [516383.019566] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [516383.019578] xenwatch      D c1610e20     0    12      2 0x00000000
> [516383.019591]  c781eec0 00000246 c1610e58 c1610e20 c781f300 c1441e20
> c1441e20 001cf000
> [516383.019605]  c781f07c c1610e20 00000000 00000001 c1441e20 c62e01c0
> c1610e20 c62e01c0
> [516383.019617]  c127e18e c781f07c c7830020 c7830020 c1441e20 c1441e20
> c127f2f1 c781f080
> [516383.019629] Call Trace:
> [516383.019640]  [<c127e18e>] ? schedule+0x78f/0x7dc
> [516383.019645]  [<c127f2f1>] ? _spin_unlock_irqrestore+0xd/0xf
> [516383.019649]  [<c127e4a1>] ? schedule_timeout+0x20/0xb0
> [516383.019656]  [<c100573c>] ? xen_force_evtchn_callback+0xc/0x10
> [516383.019660]  [<c127e3aa>] ? wait_for_common+0xa4/0x100
> [516383.019665]  [<c1033315>] ? default_wake_function+0x0/0x8
> [516383.019671]  [<c104a144>] ? kthread_stop+0x4f/0x8e
> [516383.019675]  [<c1047883>] ? cleanup_workqueue_thread+0x3a/0x45
> [516383.019679]  [<c1047903>] ? destroy_workqueue+0x56/0x85
> [516383.019684]  [<c106a395>] ? stop_machine_destroy+0x23/0x37
> [516383.019690]  [<c11962d8>] ? shutdown_handler+0x200/0x22f
> [516383.019694]  [<c1197439>] ? xenwatch_thread+0xdc/0x103
> [516383.019698]  [<c104a322>] ? autoremove_wake_function+0x0/0x2d
> [516383.019701]  [<c119735d>] ? xenwatch_thread+0x0/0x103
> [516383.019705]  [<c104a0f0>] ? kthread+0x61/0x66
> [516383.019709]  [<c104a08f>] ? kthread+0x0/0x66
> [516383.019714]  [<c1008d87>] ? kernel_thread_helper+0x7/0x10
> =

> But I _cannot_ reproduce the call trace and hang on our Sandy Bridge.
> =

> So I think there are maybe *two* bugs in this issue, one caused time
> jump(detail below), the other in the kernel triggered by the first bug
> sometime, thus result in migration fail.
> =

> I've spent some time to identify the timestamp jump issue, and finally
> found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
> called non-stop TSC). The present of the feature would enable a
> parameter in the kernel named: sched_clock_stable. Seems this
> parameter is unable to work with Xen's pvclock. If
> sched_clock_stable() is set, value returned by xen_clocksource_read()
> would be returned as sched_clock_cpu() directly(rather than calculated
> through sched_clock_local()), but CMIIW the value returned by
> xen_clocksource_read() is based on host(vcpu) uptime rather than this
> VM's uptime, then result in the timestamp jump.
> =

> I've compiled a kernel, force sched_clock_stable=3D0, then it solved the
> timestamp jump issue as expected. Luckily, seems it also solved the
> call trace and guest hang issue as well.
> =

> I've posted a patch to mask the CPUID leaf 0x80000007 in Xen. I think
> the issue can be easily reproduced using a Westmere or SandyBridge
> machine(my old colleagues at Intel said the feature likely existed
> after Nehalem) running newer version of PV guest, check the guest
> cpuinfo you would see nonstop_tsc, and you would notice the abnormal
> timestamp of printk.

Yes definitely.  I thought that I implemented this properly for
PV but I think maybe it never got implemented for HVM?  See the section
titled "TSC INVARIANT BIT and NO_MIGRATE" in docs/misc/tscmode.txt in
the Xen source.

However, if "clocksource=3Dtsc tsc=3Dreliable" is selected for a HVM
domain, I think the results may be the same as if Invariant TSC
bit is checked by the Linux kernel?  So maybe the code for
readjusting the TSC to adjust to migration was also never implemented
in HVM, just in PV?  (I remember discussing this problem with Jun Nakajima
on an Oracle/Intel call a couple of years ago.  Maybe it was
discussed but never implemented... at the time, I was primarily
concerned with and tested only for PV as that was Oracle's
customer at the time.)

Anyway, please force "clocksource=3Dtsc tsc=3Dreliable" on your HVM
guest to see if it fails the same way as when the guest "sees"
the Invariant TSC bit is set.

Thanks,
Dan

P.S. The Invariant TSC bit *did* exist on Nehalem, however there
definitely exists old firmware that did not properly align the
TSCs across all cores on boot, so the bit was present but "lied".
Maybe you are seeing the problems on a Nehalem system with broken
firmware?  I know some Sun x86 systems shipped with broken
firmware, so it is very likely other system vendors did also.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 00:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 00:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJwIl-0001Rh-LA; Tue, 17 Apr 2012 00:29:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SJwIk-0001Rc-0q
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 00:29:46 +0000
Received: from [85.158.138.51:50604] by server-1.bemta-3.messagelabs.com id
	97/18-11491-979BC8F4; Tue, 17 Apr 2012 00:29:45 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334622582!22450536!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NDMyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23147 invoked from network); 17 Apr 2012 00:29:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 00:29:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3H0TUns012537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 00:29:31 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3H0TTGx021887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 00:29:29 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3H0TRBK013240; Mon, 16 Apr 2012 19:29:28 -0500
MIME-Version: 1.0
Message-ID: <1019c5a1-983d-42c0-9f18-e3db8d10455f@default>
Date: Mon, 16 Apr 2012 17:29:19 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Sheng Yang <sheng@yasker.org>, Tim Deegan <tim@xen.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
	<20120416181744.GF13111@ocelot.phlegethon.org>
	<CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
In-Reply-To: <CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020205.4F8CB96C.00B6,ss=1,re=-2.300,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Sheng Yang [mailto:sheng@yasker.org]
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unsta=
ble

Hi Sheng --

See reply at the very end...

> On Mon, Apr 16, 2012 at 11:17 AM, Tim Deegan <tim@xen.org> wrote:
> > At 10:52 -0700 on 16 Apr (1334573568), Dan Magenheimer wrote:
> >> > From: Tim Deegan [mailto:tim@xen.org]
> >> > Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as =
unstable
> >> >
> >> > At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> >> > > Hmmm... I spent a great deal of time on TSC support in the hypervi=
sor
> >> > > 2-3 years ago. =A0I worked primarily on PV, but Intel supposedly w=
as tracking
> >> > > everything on HVM as well. =A0There's most likely a bug or two sti=
ll lurking
> >> > > but, for all guests, with the default tsc_mode, TSC is provided by=
 Xen
> >> > > as an absolutely stable clock source. =A0If Xen determines that th=
e underlying
> >> > > hardware declares that TSC is stable, guest rdtsc instructions are=
 not trapped.
> >> > > If it is not, Xen emulates all guest rdtsc instructions. =A0After =
a migration or
> >> > > save/restore, TSC is always emulated. =A0The result is (ignoring p=
ossible
> >> > > bugs) that TSC as provided by Xen is a) monotonic; b) synchronized=
 across
> >> > > CPUs; and c) constant rate. =A0Even across migration/save/restore.
> >> >
> >> > AIUI, this thread is about the PV-time clock source, not about the T=
SC
> >> > itself. =A0Even if the TSC is emulated (or in some other way made
> >> > "stable") the PV wallclock is not necessarily stable across migratio=
n.
> >> > But since migration is controlled by the kernel, presumably the kern=
el
> >> > can DTRT about it.
> >>
> >> Under what circumstances is PV wallclock not stable across migration?
> >
> > The wallclock is host-local, so I don't think it can be guaranteed to be
> > strictly monotonic across migration. =A0But as I said that's OK because
> > the Xen code in the kernel is in control during migration.
> >
> >> > > In fact, it might be wise for a Xen-savvy kernel to check to see
> >> > > if it is running on Xen-4.0+ and, if so, force clocksource=3Dtsc
> >> > > and tsc=3Dreliable.
> >> >
> >> > That seems like overdoing it. =A0Certainly it's not OK unless it can=
 also
> >> > check that Xen is providing a stable TSC (i.e. that tscmode=3D=3D1).
> >>
> >> Xen guarantees a stable TSC for the default (tsc_mode=3D=3D0) also.
> >>
> >> If the vm.cfg file explicitly sets a guest tsc_mode=3D=3D2, you are co=
rrect
> >> that pvclock is still necessary. =A0But as the documentation says:
> >> tsc_mode=3D=3D2 should be set if "it is certain that all apps running =
in this
> >> VM are TSC-resilient and highest performance is required". =A0In
> >> the case we are talking about, the PV guest kernel itself isn't TSC-
> >> resilient!
> >
> > Only if we deliberately break it! :)
> >
> >> In any case, IIRC, there is a pvcpuid instruction to determine the
> >> tsc_mode, so when the upstream kernel checks for Xen 4.0+, it could
> >> also check to ensure the tsc_mode wasn't overridden and set to 2.
> >
> > Yes, that's what I was suggesting.
> >
> >> > In the case where the PV clock has been selected, can it not be mark=
ed
> >> > unstable without also marking the TSC unstable?
> >>
> >> I'm not sure I understand...
> >>
> >> Are you talking about the HVM case of an upstream kernel, maybe
> >> when the clocksource is manually overridden on the kernel command
> >> line or after boot with sysfs?
> >
> > I'm talking about any case where the clocksource =3D=3D xen.
> >
> >> If pvclock is necessary (e.g. old Xen), how would it be
> >> marked unstable? (I didn't know there was code to do that.)
> >
> > I think I'm confused by terminology. =A0Maybe David can correct me. =A0=
My
> > understanding was that there is some concept inside linux of a time
> > source being 'stable', which requires it to be synchronized, monotonic
> > and constant-rate. =A0The PV clock is two of those things (within a
> > reasonable tolerance) but may not be monotonic over migration. =A0I was
> > suggesting that, however linux deals with that, it can probably do it
> > without changing its opinion of whether the TSC is stable.
> =

> In fact the sched_clock_stable is only regarding one Intel processor
> feature named "Invarient TSC"(a.k.a Non-stop TSC).
> =

> I've reported the original issue to xen-devel, and purpose one patch
> to fix CPUID filter in the libxc of Xen.
> =

> I think mask CPUID bit in the hypervisor is better than make this
> change in the kernel, since Xen controlled what to present to the
> guest, it doesn't make sense if we present a feature to the guest, and
> hack the kernel to disable this feature at the same time.
> =

> I haven't dug much into the code, but here is the background(most
> copied from my xen-devel post):
> =

> Recently we got some reports of migration hang on latest
> Debian(2.6.32-41kernel package) kernel with some certain machines(but
> it's hard to debug on them since they're customer's machine).
> =

> Booting dmesg snippet below:
> =

> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 3.4.2 (preserve-AD)
> [    0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1
> nr_node_ids:1
> [    0.000000] PERCPU: Embedded 15 pages/cpu @c1608000 s37656 r0
> d23784 u65536
> [    0.000000] pcpu-alloc: s37656 r0 d23784 u65536 alloc=3D16*4096
> [    0.000000] pcpu-alloc: [0] 0
> [508119.807590] trying to map vcpu_info 0 at c1609010, mfn 992cac,
> offset 16
> [508119.807593] cpu 0 using vcpu_info at c1609010
> [508119.807594] Xen: using vcpu_info placement
> [508119.807598] Built 1 zonelists in Zone order, mobility grouping on.
>  Total pages: 32416
> =

> Dmesg show that when booting, timestamp of printk jumped from 0 to a
> big number([508119.807590] in this case) immediately.
> =

> And when migrating:
> =

> [509508.914333] suspending xenstore...
> [516212.055921] trying to map vcpu_info 0 at c1609010, mfn 895fd7,
> offset 16
> [516212.055930] cpu 0 using vcpu_info at c1609010
> =

> Timestamp jumped again. We can reproduce above issues on our Sandy
> Bridge machines.
> =

> After this, call trace and guest hang *maybe* observed on some machines:
> =

> [516383.019499] INFO: task xenwatch:12 blocked for more than 120
> seconds.
> [516383.019566] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [516383.019578] xenwatch      D c1610e20     0    12      2 0x00000000
> [516383.019591]  c781eec0 00000246 c1610e58 c1610e20 c781f300 c1441e20
> c1441e20 001cf000
> [516383.019605]  c781f07c c1610e20 00000000 00000001 c1441e20 c62e01c0
> c1610e20 c62e01c0
> [516383.019617]  c127e18e c781f07c c7830020 c7830020 c1441e20 c1441e20
> c127f2f1 c781f080
> [516383.019629] Call Trace:
> [516383.019640]  [<c127e18e>] ? schedule+0x78f/0x7dc
> [516383.019645]  [<c127f2f1>] ? _spin_unlock_irqrestore+0xd/0xf
> [516383.019649]  [<c127e4a1>] ? schedule_timeout+0x20/0xb0
> [516383.019656]  [<c100573c>] ? xen_force_evtchn_callback+0xc/0x10
> [516383.019660]  [<c127e3aa>] ? wait_for_common+0xa4/0x100
> [516383.019665]  [<c1033315>] ? default_wake_function+0x0/0x8
> [516383.019671]  [<c104a144>] ? kthread_stop+0x4f/0x8e
> [516383.019675]  [<c1047883>] ? cleanup_workqueue_thread+0x3a/0x45
> [516383.019679]  [<c1047903>] ? destroy_workqueue+0x56/0x85
> [516383.019684]  [<c106a395>] ? stop_machine_destroy+0x23/0x37
> [516383.019690]  [<c11962d8>] ? shutdown_handler+0x200/0x22f
> [516383.019694]  [<c1197439>] ? xenwatch_thread+0xdc/0x103
> [516383.019698]  [<c104a322>] ? autoremove_wake_function+0x0/0x2d
> [516383.019701]  [<c119735d>] ? xenwatch_thread+0x0/0x103
> [516383.019705]  [<c104a0f0>] ? kthread+0x61/0x66
> [516383.019709]  [<c104a08f>] ? kthread+0x0/0x66
> [516383.019714]  [<c1008d87>] ? kernel_thread_helper+0x7/0x10
> =

> But I _cannot_ reproduce the call trace and hang on our Sandy Bridge.
> =

> So I think there are maybe *two* bugs in this issue, one caused time
> jump(detail below), the other in the kernel triggered by the first bug
> sometime, thus result in migration fail.
> =

> I've spent some time to identify the timestamp jump issue, and finally
> found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
> called non-stop TSC). The present of the feature would enable a
> parameter in the kernel named: sched_clock_stable. Seems this
> parameter is unable to work with Xen's pvclock. If
> sched_clock_stable() is set, value returned by xen_clocksource_read()
> would be returned as sched_clock_cpu() directly(rather than calculated
> through sched_clock_local()), but CMIIW the value returned by
> xen_clocksource_read() is based on host(vcpu) uptime rather than this
> VM's uptime, then result in the timestamp jump.
> =

> I've compiled a kernel, force sched_clock_stable=3D0, then it solved the
> timestamp jump issue as expected. Luckily, seems it also solved the
> call trace and guest hang issue as well.
> =

> I've posted a patch to mask the CPUID leaf 0x80000007 in Xen. I think
> the issue can be easily reproduced using a Westmere or SandyBridge
> machine(my old colleagues at Intel said the feature likely existed
> after Nehalem) running newer version of PV guest, check the guest
> cpuinfo you would see nonstop_tsc, and you would notice the abnormal
> timestamp of printk.

Yes definitely.  I thought that I implemented this properly for
PV but I think maybe it never got implemented for HVM?  See the section
titled "TSC INVARIANT BIT and NO_MIGRATE" in docs/misc/tscmode.txt in
the Xen source.

However, if "clocksource=3Dtsc tsc=3Dreliable" is selected for a HVM
domain, I think the results may be the same as if Invariant TSC
bit is checked by the Linux kernel?  So maybe the code for
readjusting the TSC to adjust to migration was also never implemented
in HVM, just in PV?  (I remember discussing this problem with Jun Nakajima
on an Oracle/Intel call a couple of years ago.  Maybe it was
discussed but never implemented... at the time, I was primarily
concerned with and tested only for PV as that was Oracle's
customer at the time.)

Anyway, please force "clocksource=3Dtsc tsc=3Dreliable" on your HVM
guest to see if it fails the same way as when the guest "sees"
the Invariant TSC bit is set.

Thanks,
Dan

P.S. The Invariant TSC bit *did* exist on Nehalem, however there
definitely exists old firmware that did not properly align the
TSCs across all cores on boot, so the bit was present but "lied".
Maybe you are seeing the problems on a Nehalem system with broken
firmware?  I know some Sun x86 systems shipped with broken
firmware, so it is very likely other system vendors did also.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:55:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxcy-0006Ke-B0; Tue, 17 Apr 2012 01:54:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SJxcx-0006KZ-7T
	for Xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:54:43 +0000
Received: from [85.158.143.35:52948] by server-3.bemta-4.messagelabs.com id
	D7/79-05853-26DCC8F4; Tue, 17 Apr 2012 01:54:42 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334627680!12726997!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NDMyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23918 invoked from network); 17 Apr 2012 01:54:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 01:54:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3H1sWNk023317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 01:54:33 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3H1sUhL017587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 01:54:31 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3H1sUvD001333; Mon, 16 Apr 2012 20:54:30 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 18:54:30 -0700
Date: Mon, 16 Apr 2012 18:53:40 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120416185340.72ef5566@mantra.us.oracle.com>
In-Reply-To: <1334584402.14560.184.camel@zakaz.uk.xensource.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F8CCD5A.0011,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012 14:53:22 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> > Similar to 
> >  * XENMEM_add_to_physmap
> 
> Why a whole new hypercall rather than a new XENMAPSPACE for the
> exiting XENMEM_add_to_physmap.

> Ideally we'd have the definition of this (or the equivalent mod to the
> XENMEM_add_to_physmap associated struct) for context, but I can
> probably guess what the content looks like.

Not a new hcall, just a new subcall. Forgot to include the struct:

#define XENMEM_add_foreign_to_pmap_batch      19
struct xen_add_to_foreign_pmap_batch {
    domid_t foreign_domid;         /* IN: gmfn belongs to this domain */
    int count;                     /* IN/OUT: number of contigous
frames */ unsigned long     gpfn;        /* IN: pfn in the current
domain */ unsigned long     gmfn;        /* IN: from foreign domain */
    int fpmap_flags;               /* future use */
};
typedef struct xen_add_to_foreign_pmap_batch
xen_add_to_foreign_pmap_batch_t;
DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_foreign_pmap_batch_t);


> > 	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);
> 
> This ends up setting the page type to p2m_mmio_direct, which doesn't
> seem likely to be correct. Perhaps you should be calling
> set_p2m_entry()? Or adding a set_ram_p2m_entry which does similar
> checks etc to set_mmio_p2m_entry (or maybe you could abstract out
> some generic bits there)?

well, set_mmio_p2m_entry() calls set_p2m_entry() with a couple checks.
I can add those to my function and just call set_p2m_entry too. It says
mmio, but doesn't seem to do anything mmio specific. 

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:55:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxcy-0006Ke-B0; Tue, 17 Apr 2012 01:54:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SJxcx-0006KZ-7T
	for Xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:54:43 +0000
Received: from [85.158.143.35:52948] by server-3.bemta-4.messagelabs.com id
	D7/79-05853-26DCC8F4; Tue, 17 Apr 2012 01:54:42 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334627680!12726997!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NDMyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23918 invoked from network); 17 Apr 2012 01:54:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 01:54:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3H1sWNk023317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 01:54:33 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3H1sUhL017587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 01:54:31 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3H1sUvD001333; Mon, 16 Apr 2012 20:54:30 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 16 Apr 2012 18:54:30 -0700
Date: Mon, 16 Apr 2012 18:53:40 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120416185340.72ef5566@mantra.us.oracle.com>
In-Reply-To: <1334584402.14560.184.camel@zakaz.uk.xensource.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F8CCD5A.0011,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012 14:53:22 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> > Similar to 
> >  * XENMEM_add_to_physmap
> 
> Why a whole new hypercall rather than a new XENMAPSPACE for the
> exiting XENMEM_add_to_physmap.

> Ideally we'd have the definition of this (or the equivalent mod to the
> XENMEM_add_to_physmap associated struct) for context, but I can
> probably guess what the content looks like.

Not a new hcall, just a new subcall. Forgot to include the struct:

#define XENMEM_add_foreign_to_pmap_batch      19
struct xen_add_to_foreign_pmap_batch {
    domid_t foreign_domid;         /* IN: gmfn belongs to this domain */
    int count;                     /* IN/OUT: number of contigous
frames */ unsigned long     gpfn;        /* IN: pfn in the current
domain */ unsigned long     gmfn;        /* IN: from foreign domain */
    int fpmap_flags;               /* future use */
};
typedef struct xen_add_to_foreign_pmap_batch
xen_add_to_foreign_pmap_batch_t;
DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_foreign_pmap_batch_t);


> > 	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);
> 
> This ends up setting the page type to p2m_mmio_direct, which doesn't
> seem likely to be correct. Perhaps you should be calling
> set_p2m_entry()? Or adding a set_ram_p2m_entry which does similar
> checks etc to set_mmio_p2m_entry (or maybe you could abstract out
> some generic bits there)?

well, set_mmio_p2m_entry() calls set_p2m_entry() with a couple checks.
I can add those to my function and just call set_p2m_entry too. It says
mmio, but doesn't seem to do anything mmio specific. 

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgm-0006Rp-CM; Tue, 17 Apr 2012 01:58:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgl-0006R8-4q
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:39 +0000
Received: from [85.158.138.51:37791] by server-4.bemta-3.messagelabs.com id
	16/A7-15341-E4ECC8F4; Tue, 17 Apr 2012 01:58:38 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334627916!22436561!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30676 invoked from network); 17 Apr 2012 01:58:37 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 01:58:37 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 97D1D23A69; Mon, 16 Apr 2012 22:06:53 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_22,
	J_CHICKENPOX_43,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no 
	version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id EE399245B9;
	Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id BF93D281A5; Mon, 16 Apr 2012 21:58:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 26d95b70f172c74052018863f6027fffe303e581
Message-Id: <26d95b70f172c7405201.1334627906@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:26 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 v2] xl: add "check-xl-vif-parse" test
	script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyB0ZXN0IHNjcmlwdCBydW5zICJ4bCAtTiBuZXR3b3JrLWF0dGFjaCAwIDxmb29iYXI+IiBh
Z2FpbnN0IHZhcmlvdXMKcmF0ZSBzeW50YXggYW5kIGNoZWNrcyB0aGF0IHRoZSBvdXRwdXQgaXMg
YXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIu
Y29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2NoZWNrLXhsLXZpZi1wYXJzZSBiL3Rvb2xz
L2xpYnhsL2NoZWNrLXhsLXZpZi1wYXJzZQpuZXcgZmlsZSBtb2RlIDEwMDc1NQotLS0gL2Rldi9u
dWxsCisrKyBiL3Rvb2xzL2xpYnhsL2NoZWNrLXhsLXZpZi1wYXJzZQpAQCAtMCwwICsxLDIwOSBA
QAorIyEvYmluL2Jhc2gKKworc2V0IC1lCisKK2lmIFsgLXggLi94bCBdIDsgdGhlbgorICAgIGV4
cG9ydCBMRF9MSUJSQVJZX1BBVEg9LgorICAgIFhMPS4veGwKK2Vsc2UKKyAgICBYTD14bAorZmkK
KworZnByZWZpeD10bXAuY2hlY2steGwtdmlmLXBhcnNlCisKK2V4cGVjdGVkICgpIHsKKyAgICBj
YXQgPiRmcHJlZml4LmV4cGVjdGVkCit9CisKK2ZhaWx1cmVzPTAKKworb25lICgpIHsKKyAgICBl
eHBlY3RlZF9yYz0kMTsgc2hpZnQKKyAgICBwcmludGYgInRlc3QgY2FzZSAlcy4uLlxuIiAiJCoi
CisgICAgc2V0ICtlCisgICAgJHtYTH0gLU4gbmV0d29yay1hdHRhY2ggMCAiJEAiIDwvZGV2L251
bGwgPiRmcHJlZml4LmFjdHVhbCAyPi9kZXYvbnVsbAorICAgIGFjdHVhbF9yYz0kPworICAgIGRp
ZmYgLXUgJGZwcmVmaXguZXhwZWN0ZWQgJGZwcmVmaXguYWN0dWFsCisgICAgZGlmZl9yYz0kPwor
ICAgIHNldCAtZQorICAgIGlmIFsgJGFjdHVhbF9yYyAhPSAkZXhwZWN0ZWRfcmMgXSB8fCBbICRk
aWZmX3JjICE9IDAgXTsgdGhlbgorICAgICAgICBlY2hvID4mMiAidGVzdCBjYXNlIFxgJConIGZh
aWxlZCAoJGFjdHVhbF9yYyAkZGlmZl9yYykiCisgICAgICAgIGZhaWx1cmVzPSQoKCAkZmFpbHVy
ZXMgKyAxICkpCisgICAgZmkKK30KKworY29tcGxldGUgKCkgeworICAgIGlmIFsgIiRmYWlsdXJl
cyIgPSAwIF07IHRoZW4KKyAgICAgICAgZWNobyBhbGwgb2suOyBleGl0IDAKKyAgICBlbHNlCisg
ICAgICAgIGVjaG8gIiRmYWlsdXJlcyB0ZXN0cyBmYWlsZWQuIjsgZXhpdCAxCisgICAgZmkKK30K
KworZT0yNTUKKworCisjLS0tLS0tLS0tLSB0ZXN0IGRhdGEgLS0tLS0tLS0tLQorCisjIHRlc3Qg
aW52YWxpZCB2aWYgY29uZmlnCitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgMSBmb28KKworIyB0
ZXN0IGludmFsaWQgcmF0ZSB1bml0cworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9
Zm9vCitvbmUgJGUgcmF0ZT1mb28KK29uZSAkZSByYXRlPTEwTUIKK29uZSAkZSByYXRlPTEwTUIv
bQorb25lICRlIHJhdGU9MTBaQgorb25lICRlIHJhdGU9MTBaQi9zCitvbmUgJGUgcmF0ZT0xMFpC
L20KKworIyB0ZXN0IGIvcyBhbmQgQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6
IHsKKyAgICAiYmFja2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1Ijog
MCwKKyAgICAibW9kZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAor
ICAgICJpcCI6IG51bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGws
CisgICAgInNjcmlwdCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5
dGVzX3Blcl9pbnRlcnZhbCI6IDEwMDAwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUw
MDAwCit9CisKK0VORAorCitvbmUgMCByYXRlPTE2MDAwMDAwYi9zCitvbmUgMCByYXRlPTE2MDAw
MDAwYi9zQDUwbXMKK29uZSAwIHJhdGU9MjAwMDAwMEIvcworb25lIDAgcmF0ZT0yMDAwMDAwQi9z
QDUwbXMKKworIyB0ZXN0IEtiL3MgYW5kIEtCL3MgcmF0ZSB1bml0cworZXhwZWN0ZWQgPDxFTkQK
K3ZpZjogeworICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQiOiAwLAorICAgICJt
dHUiOiAwLAorICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDowMDowMDowMDowMDow
MCIsCisgICAgImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAgICAiaWZuYW1lIjog
bnVsbCwKKyAgICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51bGwsCisgICAgInJh
dGVfYnl0ZXNfcGVyX2ludGVydmFsIjogMTAwLAorICAgICJyYXRlX2ludGVydmFsX3VzZWNzIjog
NTAwMDAKK30KKworRU5ECitvbmUgMCByYXRlPTE2S2Ivcworb25lIDAgcmF0ZT0xNktiL3NANTBt
cworb25lIDAgcmF0ZT0yS0Ivcworb25lIDAgcmF0ZT0yS0Ivc0A1MG1zCisKKyMgdGVzdCBNYi9z
IGFuZCBNQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsKKyAgICAiYmFja2Vu
ZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwKKyAgICAibW9kZWwi
OiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAgICJpcCI6IG51bGws
CisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisgICAgInNjcmlwdCI6
IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVzX3Blcl9pbnRlcnZh
bCI6IDEwMDAwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9CisKK0VORAor
b25lIDAgcmF0ZT0xNk1iL3MKK29uZSAwIHJhdGU9MTZNYi9zQDUwbXMKK29uZSAwIHJhdGU9Mk1C
L3MKK29uZSAwIHJhdGU9Mk1CL3NANTBtcworCisjIHRlc3QgR2IvcyBhbmQgR0IvcyByYXRlIHVu
aXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAgImJhY2tlbmRfZG9taWQiOiAwLAorICAg
ICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAgIm1vZGVsIjogbnVsbCwKKyAgICAibWFj
IjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAiOiBudWxsLAorICAgICJicmlkZ2UiOiBu
dWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJzY3JpcHQiOiBudWxsLAorICAgICJuaWN0
eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiOiA1MDAwMDAwMCwKKyAg
ICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9CisKK0VORAorb25lIDAgcmF0ZT04R2Iv
cworb25lIDAgcmF0ZT04R2Ivc0A1MG1zCitvbmUgMCByYXRlPTFHQi9zCitvbmUgMCByYXRlPTFH
Qi9zQDUwbXMKKworIyB0ZXN0IHJhdGUgb3ZlcmZsb3cKK2V4cGVjdGVkIDwvZGV2L251bGwKK29u
ZSAkZSByYXRlPTQyOTQ5NjcyOTZiL3MKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTZLYi9zCitvbmUg
JGUgcmF0ZT00Mjk0OTY3Mjk2TWIvcworb25lICRlIHJhdGU9NDI5NDk2NzI5NkdiL3MKKworIyB0
ZXN0IHJhdGUgdW5kZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0ZT0wQi9z
CisKKyMgdGVzdCBpbnZhbGlkIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwKK2V4cGVjdGVkIDwvZGV2
L251bGwKK29uZSAkZSByYXRlPTEwTWIvc0Bmb28KK29uZSAkZSByYXRlPTEwTWIvc0AxMGgKK29u
ZSAkZSByYXRlPTEwTUIvc0Bmb28KK29uZSAkZSByYXRlPTEwTUIvc0AxMGgKKworIyB0ZXN0IHJl
cGxlbmlzaG1lbnQgaW50ZXJ2YWwgaW4gc2Vjb25kcworZXhwZWN0ZWQgPDxFTkQKK3ZpZjogewor
ICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQiOiAwLAorICAgICJtdHUiOiAwLAor
ICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDowMDowMDowMDowMDowMCIsCisgICAg
ImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAgICAiaWZuYW1lIjogbnVsbCwKKyAg
ICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51bGwsCisgICAgInJhdGVfYnl0ZXNf
cGVyX2ludGVydmFsIjogMTAwMDAwMDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiAxMDAw
MDAwCit9CisKK0VORAorb25lIDAgcmF0ZT04ME1iL3NAMXMKK29uZSAwIHJhdGU9MTBNQi9zQDFz
CisKKyMgdGVzdCByZXBsZW5pc2htZW50IGludGVydmFsIG92ZXJmbG93CitleHBlY3RlZCA8L2Rl
di9udWxsCitvbmUgJGUgcmF0ZT0xQi9zQDQyOTQ5NjcyOTZ1cworb25lICRlIHJhdGU9MUIvc0A0
Mjk0OTY4bXMKK29uZSAkZSByYXRlPTFCL3NANDI5NXMKKworIyB0ZXN0IHJlcGxlbmlzaG1lbnQg
aW50ZXJ2YWwgdW5kZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0ZT0xQi9z
QDB1cworCisjIHRlc3QgcmF0ZSBsaW1pdGluZyByZXN1bHRpbmcgaW4gb3ZlcmZsb3cKK2V4cGVj
dGVkIDwvZGV2L251bGwKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTVHQi9zQDV1cworb25lICRlIHJh
dGU9NDI5Nk1CL3NANDI5NHMKKworY29tcGxldGUKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgm-0006Rh-09; Tue, 17 Apr 2012 01:58:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgl-0006RJ-4U
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:39 +0000
Received: from [85.158.139.83:48832] by server-6.bemta-5.messagelabs.com id
	E7/B2-13222-E4ECC8F4; Tue, 17 Apr 2012 01:58:38 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334627917!24095792!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25050 invoked from network); 17 Apr 2012 01:58:37 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-3.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 01:58:37 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 93ADC245BE; Mon, 16 Apr 2012 22:06:53 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A1F7223A72;
	Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 0A298281A7; Mon, 16 Apr 2012 21:58:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 0303c3ef7788de6522f9c8c1ceab8ba21f8a8ea7
Message-Id: <0303c3ef7788de6522f9.1334627904@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:24 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 v2] xl: xl network-attach -N (dry run)
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIGRyeXJ1biBmb3IgdGVzdGluZyBhbmQgZGVidWdnaW5nIHB1cnBvc2VzLgoKU2lnbmVkLW9m
Zi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC00
OTE2LDYgKzQ5MTYsMTYgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIH0KICAgICB9CisKKyAgICBpZiAoZHJ5
cnVuX29ubHkpIHsKKyAgICAgICAgY2hhciAqanNvbiA9IGxpYnhsX2RldmljZV9uaWNfdG9fanNv
bihjdHgsICZuaWMpOworICAgICAgICBwcmludGYoInZpZjogJXNcbiIsIGpzb24pOworICAgICAg
ICBmcmVlKGpzb24pOworICAgICAgICBsaWJ4bF9kZXZpY2VfbmljX2Rpc3Bvc2UoJm5pYyk7Cisg
ICAgICAgIGlmIChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3IoInN0
ZG91dCIpOyBleGl0KC0xKTsgfQorICAgICAgICByZXR1cm4gMDsKKyAgICB9CisKICAgICBpZiAo
bGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYykpIHsKICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJsaWJ4bF9kZXZpY2VfbmljX2FkZCBmYWlsZWQuXG4iKTsKICAgICAgICAgcmV0
dXJuIDE7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jIGIvdG9vbHMvbGli
eGwveGxfY21kdGFibGUuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jCisrKyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMKQEAgLTI4OCw3ICsyODgsNyBAQCBzdHJ1Y3QgY21kX3Nw
ZWMgY21kX3RhYmxlW10gPSB7CiAgICAgICAiIiwKICAgICB9LAogICAgIHsgIm5ldHdvcmstYXR0
YWNoIiwKLSAgICAgICZtYWluX25ldHdvcmthdHRhY2gsIDAsCisgICAgICAmbWFpbl9uZXR3b3Jr
YXR0YWNoLCAxLAogICAgICAgIkNyZWF0ZSBhIG5ldyB2aXJ0dWFsIG5ldHdvcmsgZGV2aWNlIiwK
ICAgICAgICI8RG9tYWluPiBbdHlwZT08dHlwZT5dIFttYWM9PG1hYz5dIFticmlkZ2U9PGJyaWRn
ZT5dICIKICAgICAgICJbaXA9PGlwPl0gW3NjcmlwdD08c2NyaXB0Pl0gW2JhY2tlbmQ9PEJhY2tE
b21haW4+XSBbdmlmbmFtZT08bmFtZT5dICIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgk-0006Qu-0c; Tue, 17 Apr 2012 01:58:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgi-0006Qm-In
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:36 +0000
Received: from [193.109.254.147:60664] by server-8.bemta-14.messagelabs.com id
	A4/40-23244-B4ECC8F4; Tue, 17 Apr 2012 01:58:35 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334627915!4897992!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30140 invoked from network); 17 Apr 2012 01:58:35 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-11.tower-27.messagelabs.com with SMTP;
	17 Apr 2012 01:58:35 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 9FB2F23C2E; Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id 46DBB23A72;
	Mon, 16 Apr 2012 22:06:50 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id B40AF281A6; Mon, 16 Apr 2012 21:58:33 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 4e99650a2d6e280310667c214b86313e718c7acd
Message-Id: <4e99650a2d6e28031066.1334627903@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:23 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 v2] xl: cleanup indentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdp
dCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwot
LS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jCkBAIC04NDcsMTAgKzg0NywxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShj
b25zdCBjaGFyCiAgICAgICAgICAgICAgICAgbmljLT5zY3JpcHQgPSBzdHJkdXAoZGVmYXVsdF92
aWZzY3JpcHQpOwogICAgICAgICAgICAgfQogCi0JICAgIGlmIChkZWZhdWx0X2JyaWRnZSkgewot
CQlmcmVlKG5pYy0+YnJpZGdlKTsKLQkJbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwotCSAgICB9CisgICAgICAgICAgICBpZiAoZGVmYXVsdF9icmlkZ2UpIHsKKyAgICAgICAg
ICAgICAgICBmcmVlKG5pYy0+YnJpZGdlKTsKKyAgICAgICAgICAgICAgICBuaWMtPmJyaWRnZSA9
IHN0cmR1cChkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIHAg
PSBzdHJ0b2soYnVmMiwgIiwiKTsKICAgICAgICAgICAgIGlmICghcCkKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgk-0006Qu-0c; Tue, 17 Apr 2012 01:58:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgi-0006Qm-In
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:36 +0000
Received: from [193.109.254.147:60664] by server-8.bemta-14.messagelabs.com id
	A4/40-23244-B4ECC8F4; Tue, 17 Apr 2012 01:58:35 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334627915!4897992!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30140 invoked from network); 17 Apr 2012 01:58:35 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-11.tower-27.messagelabs.com with SMTP;
	17 Apr 2012 01:58:35 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 9FB2F23C2E; Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id 46DBB23A72;
	Mon, 16 Apr 2012 22:06:50 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id B40AF281A6; Mon, 16 Apr 2012 21:58:33 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 4e99650a2d6e280310667c214b86313e718c7acd
Message-Id: <4e99650a2d6e28031066.1334627903@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:23 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 v2] xl: cleanup indentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdp
dCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwot
LS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jCkBAIC04NDcsMTAgKzg0NywxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShj
b25zdCBjaGFyCiAgICAgICAgICAgICAgICAgbmljLT5zY3JpcHQgPSBzdHJkdXAoZGVmYXVsdF92
aWZzY3JpcHQpOwogICAgICAgICAgICAgfQogCi0JICAgIGlmIChkZWZhdWx0X2JyaWRnZSkgewot
CQlmcmVlKG5pYy0+YnJpZGdlKTsKLQkJbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwotCSAgICB9CisgICAgICAgICAgICBpZiAoZGVmYXVsdF9icmlkZ2UpIHsKKyAgICAgICAg
ICAgICAgICBmcmVlKG5pYy0+YnJpZGdlKTsKKyAgICAgICAgICAgICAgICBuaWMtPmJyaWRnZSA9
IHN0cmR1cChkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIHAg
PSBzdHJ0b2soYnVmMiwgIiwiKTsKICAgICAgICAgICAgIGlmICghcCkKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgm-0006Rh-09; Tue, 17 Apr 2012 01:58:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgl-0006RJ-4U
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:39 +0000
Received: from [85.158.139.83:48832] by server-6.bemta-5.messagelabs.com id
	E7/B2-13222-E4ECC8F4; Tue, 17 Apr 2012 01:58:38 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334627917!24095792!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25050 invoked from network); 17 Apr 2012 01:58:37 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-3.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 01:58:37 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 93ADC245BE; Mon, 16 Apr 2012 22:06:53 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A1F7223A72;
	Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 0A298281A7; Mon, 16 Apr 2012 21:58:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 0303c3ef7788de6522f9c8c1ceab8ba21f8a8ea7
Message-Id: <0303c3ef7788de6522f9.1334627904@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:24 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 v2] xl: xl network-attach -N (dry run)
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIGRyeXJ1biBmb3IgdGVzdGluZyBhbmQgZGVidWdnaW5nIHB1cnBvc2VzLgoKU2lnbmVkLW9m
Zi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC00
OTE2LDYgKzQ5MTYsMTYgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIH0KICAgICB9CisKKyAgICBpZiAoZHJ5
cnVuX29ubHkpIHsKKyAgICAgICAgY2hhciAqanNvbiA9IGxpYnhsX2RldmljZV9uaWNfdG9fanNv
bihjdHgsICZuaWMpOworICAgICAgICBwcmludGYoInZpZjogJXNcbiIsIGpzb24pOworICAgICAg
ICBmcmVlKGpzb24pOworICAgICAgICBsaWJ4bF9kZXZpY2VfbmljX2Rpc3Bvc2UoJm5pYyk7Cisg
ICAgICAgIGlmIChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3IoInN0
ZG91dCIpOyBleGl0KC0xKTsgfQorICAgICAgICByZXR1cm4gMDsKKyAgICB9CisKICAgICBpZiAo
bGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYykpIHsKICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJsaWJ4bF9kZXZpY2VfbmljX2FkZCBmYWlsZWQuXG4iKTsKICAgICAgICAgcmV0
dXJuIDE7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jIGIvdG9vbHMvbGli
eGwveGxfY21kdGFibGUuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jCisrKyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMKQEAgLTI4OCw3ICsyODgsNyBAQCBzdHJ1Y3QgY21kX3Nw
ZWMgY21kX3RhYmxlW10gPSB7CiAgICAgICAiIiwKICAgICB9LAogICAgIHsgIm5ldHdvcmstYXR0
YWNoIiwKLSAgICAgICZtYWluX25ldHdvcmthdHRhY2gsIDAsCisgICAgICAmbWFpbl9uZXR3b3Jr
YXR0YWNoLCAxLAogICAgICAgIkNyZWF0ZSBhIG5ldyB2aXJ0dWFsIG5ldHdvcmsgZGV2aWNlIiwK
ICAgICAgICI8RG9tYWluPiBbdHlwZT08dHlwZT5dIFttYWM9PG1hYz5dIFticmlkZ2U9PGJyaWRn
ZT5dICIKICAgICAgICJbaXA9PGlwPl0gW3NjcmlwdD08c2NyaXB0Pl0gW2JhY2tlbmQ9PEJhY2tE
b21haW4+XSBbdmlmbmFtZT08bmFtZT5dICIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgm-0006Rp-CM; Tue, 17 Apr 2012 01:58:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgl-0006R8-4q
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:39 +0000
Received: from [85.158.138.51:37791] by server-4.bemta-3.messagelabs.com id
	16/A7-15341-E4ECC8F4; Tue, 17 Apr 2012 01:58:38 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334627916!22436561!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30676 invoked from network); 17 Apr 2012 01:58:37 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 01:58:37 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 97D1D23A69; Mon, 16 Apr 2012 22:06:53 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_22,
	J_CHICKENPOX_43,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no 
	version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id EE399245B9;
	Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id BF93D281A5; Mon, 16 Apr 2012 21:58:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 26d95b70f172c74052018863f6027fffe303e581
Message-Id: <26d95b70f172c7405201.1334627906@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:26 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 v2] xl: add "check-xl-vif-parse" test
	script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyB0ZXN0IHNjcmlwdCBydW5zICJ4bCAtTiBuZXR3b3JrLWF0dGFjaCAwIDxmb29iYXI+IiBh
Z2FpbnN0IHZhcmlvdXMKcmF0ZSBzeW50YXggYW5kIGNoZWNrcyB0aGF0IHRoZSBvdXRwdXQgaXMg
YXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIu
Y29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2NoZWNrLXhsLXZpZi1wYXJzZSBiL3Rvb2xz
L2xpYnhsL2NoZWNrLXhsLXZpZi1wYXJzZQpuZXcgZmlsZSBtb2RlIDEwMDc1NQotLS0gL2Rldi9u
dWxsCisrKyBiL3Rvb2xzL2xpYnhsL2NoZWNrLXhsLXZpZi1wYXJzZQpAQCAtMCwwICsxLDIwOSBA
QAorIyEvYmluL2Jhc2gKKworc2V0IC1lCisKK2lmIFsgLXggLi94bCBdIDsgdGhlbgorICAgIGV4
cG9ydCBMRF9MSUJSQVJZX1BBVEg9LgorICAgIFhMPS4veGwKK2Vsc2UKKyAgICBYTD14bAorZmkK
KworZnByZWZpeD10bXAuY2hlY2steGwtdmlmLXBhcnNlCisKK2V4cGVjdGVkICgpIHsKKyAgICBj
YXQgPiRmcHJlZml4LmV4cGVjdGVkCit9CisKK2ZhaWx1cmVzPTAKKworb25lICgpIHsKKyAgICBl
eHBlY3RlZF9yYz0kMTsgc2hpZnQKKyAgICBwcmludGYgInRlc3QgY2FzZSAlcy4uLlxuIiAiJCoi
CisgICAgc2V0ICtlCisgICAgJHtYTH0gLU4gbmV0d29yay1hdHRhY2ggMCAiJEAiIDwvZGV2L251
bGwgPiRmcHJlZml4LmFjdHVhbCAyPi9kZXYvbnVsbAorICAgIGFjdHVhbF9yYz0kPworICAgIGRp
ZmYgLXUgJGZwcmVmaXguZXhwZWN0ZWQgJGZwcmVmaXguYWN0dWFsCisgICAgZGlmZl9yYz0kPwor
ICAgIHNldCAtZQorICAgIGlmIFsgJGFjdHVhbF9yYyAhPSAkZXhwZWN0ZWRfcmMgXSB8fCBbICRk
aWZmX3JjICE9IDAgXTsgdGhlbgorICAgICAgICBlY2hvID4mMiAidGVzdCBjYXNlIFxgJConIGZh
aWxlZCAoJGFjdHVhbF9yYyAkZGlmZl9yYykiCisgICAgICAgIGZhaWx1cmVzPSQoKCAkZmFpbHVy
ZXMgKyAxICkpCisgICAgZmkKK30KKworY29tcGxldGUgKCkgeworICAgIGlmIFsgIiRmYWlsdXJl
cyIgPSAwIF07IHRoZW4KKyAgICAgICAgZWNobyBhbGwgb2suOyBleGl0IDAKKyAgICBlbHNlCisg
ICAgICAgIGVjaG8gIiRmYWlsdXJlcyB0ZXN0cyBmYWlsZWQuIjsgZXhpdCAxCisgICAgZmkKK30K
KworZT0yNTUKKworCisjLS0tLS0tLS0tLSB0ZXN0IGRhdGEgLS0tLS0tLS0tLQorCisjIHRlc3Qg
aW52YWxpZCB2aWYgY29uZmlnCitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgMSBmb28KKworIyB0
ZXN0IGludmFsaWQgcmF0ZSB1bml0cworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9
Zm9vCitvbmUgJGUgcmF0ZT1mb28KK29uZSAkZSByYXRlPTEwTUIKK29uZSAkZSByYXRlPTEwTUIv
bQorb25lICRlIHJhdGU9MTBaQgorb25lICRlIHJhdGU9MTBaQi9zCitvbmUgJGUgcmF0ZT0xMFpC
L20KKworIyB0ZXN0IGIvcyBhbmQgQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6
IHsKKyAgICAiYmFja2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1Ijog
MCwKKyAgICAibW9kZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAor
ICAgICJpcCI6IG51bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGws
CisgICAgInNjcmlwdCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5
dGVzX3Blcl9pbnRlcnZhbCI6IDEwMDAwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUw
MDAwCit9CisKK0VORAorCitvbmUgMCByYXRlPTE2MDAwMDAwYi9zCitvbmUgMCByYXRlPTE2MDAw
MDAwYi9zQDUwbXMKK29uZSAwIHJhdGU9MjAwMDAwMEIvcworb25lIDAgcmF0ZT0yMDAwMDAwQi9z
QDUwbXMKKworIyB0ZXN0IEtiL3MgYW5kIEtCL3MgcmF0ZSB1bml0cworZXhwZWN0ZWQgPDxFTkQK
K3ZpZjogeworICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQiOiAwLAorICAgICJt
dHUiOiAwLAorICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDowMDowMDowMDowMDow
MCIsCisgICAgImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAgICAiaWZuYW1lIjog
bnVsbCwKKyAgICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51bGwsCisgICAgInJh
dGVfYnl0ZXNfcGVyX2ludGVydmFsIjogMTAwLAorICAgICJyYXRlX2ludGVydmFsX3VzZWNzIjog
NTAwMDAKK30KKworRU5ECitvbmUgMCByYXRlPTE2S2Ivcworb25lIDAgcmF0ZT0xNktiL3NANTBt
cworb25lIDAgcmF0ZT0yS0Ivcworb25lIDAgcmF0ZT0yS0Ivc0A1MG1zCisKKyMgdGVzdCBNYi9z
IGFuZCBNQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsKKyAgICAiYmFja2Vu
ZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwKKyAgICAibW9kZWwi
OiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAgICJpcCI6IG51bGws
CisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisgICAgInNjcmlwdCI6
IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVzX3Blcl9pbnRlcnZh
bCI6IDEwMDAwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9CisKK0VORAor
b25lIDAgcmF0ZT0xNk1iL3MKK29uZSAwIHJhdGU9MTZNYi9zQDUwbXMKK29uZSAwIHJhdGU9Mk1C
L3MKK29uZSAwIHJhdGU9Mk1CL3NANTBtcworCisjIHRlc3QgR2IvcyBhbmQgR0IvcyByYXRlIHVu
aXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAgImJhY2tlbmRfZG9taWQiOiAwLAorICAg
ICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAgIm1vZGVsIjogbnVsbCwKKyAgICAibWFj
IjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAiOiBudWxsLAorICAgICJicmlkZ2UiOiBu
dWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJzY3JpcHQiOiBudWxsLAorICAgICJuaWN0
eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiOiA1MDAwMDAwMCwKKyAg
ICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9CisKK0VORAorb25lIDAgcmF0ZT04R2Iv
cworb25lIDAgcmF0ZT04R2Ivc0A1MG1zCitvbmUgMCByYXRlPTFHQi9zCitvbmUgMCByYXRlPTFH
Qi9zQDUwbXMKKworIyB0ZXN0IHJhdGUgb3ZlcmZsb3cKK2V4cGVjdGVkIDwvZGV2L251bGwKK29u
ZSAkZSByYXRlPTQyOTQ5NjcyOTZiL3MKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTZLYi9zCitvbmUg
JGUgcmF0ZT00Mjk0OTY3Mjk2TWIvcworb25lICRlIHJhdGU9NDI5NDk2NzI5NkdiL3MKKworIyB0
ZXN0IHJhdGUgdW5kZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0ZT0wQi9z
CisKKyMgdGVzdCBpbnZhbGlkIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwKK2V4cGVjdGVkIDwvZGV2
L251bGwKK29uZSAkZSByYXRlPTEwTWIvc0Bmb28KK29uZSAkZSByYXRlPTEwTWIvc0AxMGgKK29u
ZSAkZSByYXRlPTEwTUIvc0Bmb28KK29uZSAkZSByYXRlPTEwTUIvc0AxMGgKKworIyB0ZXN0IHJl
cGxlbmlzaG1lbnQgaW50ZXJ2YWwgaW4gc2Vjb25kcworZXhwZWN0ZWQgPDxFTkQKK3ZpZjogewor
ICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQiOiAwLAorICAgICJtdHUiOiAwLAor
ICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDowMDowMDowMDowMDowMCIsCisgICAg
ImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAgICAiaWZuYW1lIjogbnVsbCwKKyAg
ICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51bGwsCisgICAgInJhdGVfYnl0ZXNf
cGVyX2ludGVydmFsIjogMTAwMDAwMDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiAxMDAw
MDAwCit9CisKK0VORAorb25lIDAgcmF0ZT04ME1iL3NAMXMKK29uZSAwIHJhdGU9MTBNQi9zQDFz
CisKKyMgdGVzdCByZXBsZW5pc2htZW50IGludGVydmFsIG92ZXJmbG93CitleHBlY3RlZCA8L2Rl
di9udWxsCitvbmUgJGUgcmF0ZT0xQi9zQDQyOTQ5NjcyOTZ1cworb25lICRlIHJhdGU9MUIvc0A0
Mjk0OTY4bXMKK29uZSAkZSByYXRlPTFCL3NANDI5NXMKKworIyB0ZXN0IHJlcGxlbmlzaG1lbnQg
aW50ZXJ2YWwgdW5kZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0ZT0xQi9z
QDB1cworCisjIHRlc3QgcmF0ZSBsaW1pdGluZyByZXN1bHRpbmcgaW4gb3ZlcmZsb3cKK2V4cGVj
dGVkIDwvZGV2L251bGwKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTVHQi9zQDV1cworb25lICRlIHJh
dGU9NDI5Nk1CL3NANDI5NHMKKworY29tcGxldGUKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgk-0006RF-J2; Tue, 17 Apr 2012 01:58:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgk-0006Qs-4l
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:38 +0000
Received: from [85.158.138.51:11238] by server-5.bemta-3.messagelabs.com id
	8B/91-17113-D4ECC8F4; Tue, 17 Apr 2012 01:58:37 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334627916!18233998!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6338 invoked from network); 17 Apr 2012 01:58:36 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 01:58:36 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id F1BE5245BD; Mon, 16 Apr 2012 22:06:52 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id D58F723A69;
	Mon, 16 Apr 2012 22:06:50 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 68619281A5; Mon, 16 Apr 2012 21:58:33 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:22 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 v2] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch series implements the required plumbering for vif rate limiting in libxl/xl.

The first patch fixes trivial indentation issues and introduces no functional changes.

The second patch implements dry-run for `xl network-attach` for debugging and testing purposes.

The third patch adds the required plumbering in libxl/xl to add vif rate limiting support. It uses the `rate` option syntax from xm/xend, ensuring full backward compatiblity.

The final patch adds the "check-xl-vif-parse" test script which tests various `rate` syntax.

Changes in v2:
- Don't default to unlimited in case of overflow/underflow or invalid syntax in rate
- Add error handling
- Remove use of matches in regex which weren't used anyway
- Add docs about the syntax
- Add note in docs explaining that limitations are netback implementation specific
- Modify test cases according to new behavior

Please comment on the overflow and error handling.

Sorry for the delay.

--
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgk-0006RF-J2; Tue, 17 Apr 2012 01:58:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgk-0006Qs-4l
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:38 +0000
Received: from [85.158.138.51:11238] by server-5.bemta-3.messagelabs.com id
	8B/91-17113-D4ECC8F4; Tue, 17 Apr 2012 01:58:37 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334627916!18233998!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6338 invoked from network); 17 Apr 2012 01:58:36 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 01:58:36 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id F1BE5245BD; Mon, 16 Apr 2012 22:06:52 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id D58F723A69;
	Mon, 16 Apr 2012 22:06:50 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 68619281A5; Mon, 16 Apr 2012 21:58:33 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:22 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 v2] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch series implements the required plumbering for vif rate limiting in libxl/xl.

The first patch fixes trivial indentation issues and introduces no functional changes.

The second patch implements dry-run for `xl network-attach` for debugging and testing purposes.

The third patch adds the required plumbering in libxl/xl to add vif rate limiting support. It uses the `rate` option syntax from xm/xend, ensuring full backward compatiblity.

The final patch adds the "check-xl-vif-parse" test script which tests various `rate` syntax.

Changes in v2:
- Don't default to unlimited in case of overflow/underflow or invalid syntax in rate
- Add error handling
- Remove use of matches in regex which weren't used anyway
- Add docs about the syntax
- Add note in docs explaining that limitations are netback implementation specific
- Modify test cases according to new behavior

Please comment on the overflow and error handling.

Sorry for the delay.

--
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgq-0006St-R4; Tue, 17 Apr 2012 01:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgo-0006SC-5w
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:43 +0000
Received: from [85.158.143.99:39711] by server-3.bemta-4.messagelabs.com id
	A5/FA-05853-15ECC8F4; Tue, 17 Apr 2012 01:58:41 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334627918!23593808!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5853 invoked from network); 17 Apr 2012 01:58:39 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-5.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 01:58:39 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 4664623A72; Mon, 16 Apr 2012 22:06:55 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: **
X-Spam-Status: No, score=2.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_64,
	J_CHICKENPOX_81,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME,TW_BX,TW_CF,
	TW_IB autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id B991523ADA;
	Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 5207B281A8; Mon, 16 Apr 2012 21:58:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: a523c29eb8751c50de0916bb97717d9509aeed9c
Message-Id: <a523c29eb8751c50de09.1334627905@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:25 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 v2] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIGByYXRlYCBrZXl3b3JkIHNwZWNpZmllcyB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgb3V0Z29p
bmcgdHJhZmZpYyB3aWxsIGJlIGxpbWl0ZWQgdG8uClRoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29y
ZCBpcyBub3Qgc3BlY2lmaWVkIGlzIHVubGltaXRlZC4KClRoZSBgcmF0ZWAga2V5d29yZCBzdXBw
b3J0cyBhbiBvcHRpb25hbCByZXBsZW5pc2htZW50IGludGVydmFsIHBhcmFtZXRlciBmb3Igc3Bl
Y2lmeWluZwp0aGUgZ3JhbnVsYXJpdHkgb2YgY3JlZGl0IHJlcGxlbmlzaG1lbnQuIEl0IGRldGVy
bWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaAp0aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQg
aXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMuCgpGb3IgZXhhbXBs
ZToKCiAgICAgICAgJ3JhdGU9MTBNYi9zJwogICAgICAgICdyYXRlPTI1MEtCL3MnCiAgICAgICAg
J3JhdGU9MU1CL3NAMjBtcycKClNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2FnbmVA
aXdlYi5jb20+CgpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlv
bi5tYXJrZG93biBiL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24K
LS0tIGEvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgorKysgYi9k
b2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCkBAIC0xMjIsNSArMTIy
LDM0IEBAIFNwZWNpZmllcyB0aGUgYmFja2VuZCBkb21haW4gd2hpY2ggdGhpcyAKIGRlZmF1bHRz
IHRvIGRvbWFpbiAwLiBTcGVjaWZ5aW5nIGFub3RoZXIgZG9tYWluIHJlcXVpcmVzIHNldHRpbmcg
dXAgYQogZHJpdmVyIGRvbWFpbiB3aGljaCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv
Y3VtZW50LgogCisjIyMgcmF0ZQorCitTcGVjaWZpZXMgdGhlIHJhdGUgYXQgd2hpY2ggdGhlIG91
dGdvaW5nIHRyYWZmaWMgd2lsbCBiZSBsaW1pdGVkIHRvLgorVGhlIGRlZmF1bHQgaWYgdGhpcyBr
ZXl3b3JkIGlzIG5vdCBzcGVjaWZpZWQgaXMgdW5saW1pdGVkLgorCitUaGUgcmF0ZSBtYXkgYmUg
c3BlY2lmaWVkIGFzICI8UkFURT4vcyIgb3Igb3B0aW9uYWxseSAiPFJBVEU+L3NAPElOVEVSVkFM
PiIuCisKKyAgKiBgUkFURWAgaXMgaW4gYnl0ZXMgYW5kIGNhbiBhY2NlcHQgc3VmZml4ZXM6Cisg
ICAgICAqIEdCLCBNQiwgS0IsIEIgZm9yIGJ5dGVzLgorICAgICAgKiBHYiwgTWIsIEtiLCBiIGZv
ciBiaXRzLgorICAqIGBJTlRFUlZBTGAgaXMgaW4gbWljcm9zZWNvbmRzIGFuZCBjYW4gYWNjZXB0
IHN1ZmZpeGVzOiBtcywgdXMsIHMuCisgICAgSXQgZGV0ZXJtaW5lcyB0aGUgZnJlcXVlbmN5IGF0
IHdoaWNoIHRoZSB2aWYgdHJhbnNtaXNzaW9uIGNyZWRpdAorICAgIGlzIHJlcGxlbmlzaGVkLiBU
aGUgZGVmYXVsdCBpcyA1MG1zLgorCitWaWYgcmF0ZSBsaW1pdGluZyBpcyBjcmVkaXQtYmFzZWQu
IEl0IG1lYW5zIHRoYXQgZm9yICIxTUIvc0AyMG1zIiwgdGhlCithdmFpbGFibGUgY3JlZGl0IHdp
bGwgYmUgZXF1aXZhbGVudCBvZiB0aGUgdHJhZmZpYyB5b3Ugd291bGQgaGF2ZSBkb25lCithdCAi
MU1CL3MiIGR1cmluZyAyMG1zLiBUaGlzIHdpbGwgcmVzdWx0cyBpbiBhIGNyZWRpdCBvZiAyMCww
MDAgYnl0ZXMKK3JlcGxlbmlzaGVkIGV2ZXJ5IDIwLDAwMCB1cy4KKworRm9yIGV4YW1wbGU6CisK
KyAgICAgICAgJ3JhdGU9MTBNYi9zJyAtLSBtZWFuaW5nIHVwIHRvIDEwIG1lZ2FiaXRzIGV2ZXJ5
IHNlY29uZAorICAgICAgICAncmF0ZT0yNTBLQi9zJyAtLSBtZWFuaW5nIHVwIHRvIDI1MCBraWxv
Ynl0ZXMgZXZlcnkgc2Vjb25kCisgICAgICAgICdyYXRlPTFNQi9zQDIwbXMnIC0tIG1lYW5pbmcg
MjAsMDAwIGJ5dGVzIGluIGV2ZXJ5IDIwIG1pbGxpc2Vjb25kIHBlcmlvZAorCitOT1RFOiBUaGUg
YWN0dWFsIHVuZGVybHlpbmcgbGltaXRzIG9mIHJhdGUgbGltaXRpbmcgYXJlIGRlcGVuZGVudAor
b24gdGhlIHVuZGVybHlpbmcgbmV0YmFjayBpbXBsZW1lbnRhdGlvbi4KKworCiBbb3VpXTogaHR0
cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Pcmdhbml6YXRpb25hbGx5X1VuaXF1ZV9JZGVudGlm
aWVyCiBbbmV0XTogaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL0hvc3RDb25maWd1cmF0aW9uL05l
dHdvcmtpbmcKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlIGIvdG9vbHMvbGlieGwv
TWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUKKysrIGIvdG9vbHMvbGlieGwvTWFr
ZWZpbGUKQEAgLTYxLDcgKzYxLDcgQEAgTElCWExfT0JKUyArPSBfbGlieGxfdHlwZXMubyBsaWJ4
bF9mbGFzawogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhsdV9jZmdfbC5oIF9saWJ4bF9s
aXN0LmgKIEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVfY2ZnX2wuYwogTElCWExVX09C
SlMgPSBsaWJ4bHVfY2ZnX3kubyBsaWJ4bHVfY2ZnX2wubyBsaWJ4bHVfY2ZnLm8gXAotCWxpYnhs
dV9kaXNrX2wubyBsaWJ4bHVfZGlzay5vIGxpYnhsdV9wY2kubworCWxpYnhsdV9kaXNrX2wubyBs
aWJ4bHVfZGlzay5vIGxpYnhsdV92aWYubyBsaWJ4bHVfcGNpLm8KICQoTElCWExVX09CSlMpOiBD
RkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3IgeGVudG9vbGxvZy5oCiAKIENMSUVO
VFMgPSB4bCB0ZXN0aWRsCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMv
bGlieGwvbGlieGwuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCisrKyBiL3Rvb2xzL2xpYnhs
L2xpYnhsLmMKQEAgLTE4NTQsNiArMTg1NCwxMyBAQCBpbnQgbGlieGxfZGV2aWNlX25pY19hZGQo
bGlieGxfY3R4ICpjdHgsCiAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0
cmR1cChnYywgbmljLT5pcCkpOwogICAgIH0KIAorICAgIGlmIChuaWMtPnJhdGVfaW50ZXJ2YWxf
dXNlY3MgPiAwKSB7CisgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgInJhdGUiKTsKKyAg
ICAgICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCBsaWJ4bF9fc3ByaW50ZihnYywgIiVsbHUsJWx1
IiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAodW5zaWduZWQgbG9uZyBsb25nKSBuaWMt
PnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICh1
bnNpZ25lZCBsb25nKSBuaWMtPnJhdGVfaW50ZXJ2YWxfdXNlY3MpKTsKKyAgICB9CisKICAgICBm
bGV4YXJyYXlfYXBwZW5kKGJhY2ssICJicmlkZ2UiKTsKICAgICBmbGV4YXJyYXlfYXBwZW5kKGJh
Y2ssIGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+YnJpZGdlKSk7CiAgICAgZmxleGFycmF5X2FwcGVu
ZChiYWNrLCAiaGFuZGxlIik7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5p
ZGwgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbApAQCAtMzQzLDYgKzM0
Myw4IEBAIGxpYnhsX2RldmljZV9uaWMgPSBTdHJ1Y3QoImRldmljZV9uaWMiLCAKICAgICAoImlm
bmFtZSIsIHN0cmluZyksCiAgICAgKCJzY3JpcHQiLCBzdHJpbmcpLAogICAgICgibmljdHlwZSIs
IGxpYnhsX25pY190eXBlKSwKKyAgICAoInJhdGVfYnl0ZXNfcGVyX2ludGVydmFsIiwgdWludDY0
KSwKKyAgICAoInJhdGVfaW50ZXJ2YWxfdXNlY3MiLCB1aW50MzIpLAogICAgIF0pCiAKIGxpYnhs
X2RldmljZV9wY2kgPSBTdHJ1Y3QoImRldmljZV9wY2kiLCBbCmRpZmYgLS1naXQgYS90b29scy9s
aWJ4bC9saWJ4bHVfaW50ZXJuYWwuaCBiL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oCi0t
LSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhs
dV9pbnRlcm5hbC5oCkBAIC0xNyw5ICsxNywxMSBAQAogI2RlZmluZSBMSUJYTFVfSU5URVJOQUxf
SAogCiAjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KICNpbmNsdWRlIDxl
cnJuby5oPgogI2luY2x1ZGUgPHN0cmluZy5oPgogI2luY2x1ZGUgPGFzc2VydC5oPgorI2luY2x1
ZGUgPHJlZ2V4Lmg+CiAKICNkZWZpbmUgWExVX0NvbmZpZ0xpc3QgWExVX0NvbmZpZ1NldHRpbmcK
IApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGx1X3ZpZi5jIGIvdG9vbHMvbGlieGwvbGli
eGx1X3ZpZi5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Ci0tLSAvZGV2L251bGwKKysrIGIvdG9vbHMv
bGlieGwvbGlieGx1X3ZpZi5jCkBAIC0wLDAgKzEsMTQxIEBACisjaW5jbHVkZSAibGlieGxfb3Nk
ZXBzLmgiIC8qIG11c3QgY29tZSBiZWZvcmUgYW55IG90aGVyIGhlYWRlcnMgKi8KKyNpbmNsdWRl
ICJsaWJ4bHVfaW50ZXJuYWwuaCIKKworc3RhdGljIGNvbnN0IGNoYXIgKnZpZl9ieXRlc19wZXJf
c2VjX3JlID0gIl5bMC05XStbR01LXT9bQmJdL3MkIjsKK3N0YXRpYyBjb25zdCBjaGFyICp2aWZf
aW50ZXJuYWxfdXNlY19yZSA9ICJeWzAtOV0rW211XT9zPyQiOworCitzdGF0aWMgdm9pZCB4bHVf
X3ZpZl9lcnIoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICptc2csIGNvbnN0IGNoYXIgKnJh
dGUpIHsKKyAgICBmcHJpbnRmKGNmZy0+cmVwb3J0LAorICAgICAgICAgICAgIiVzOiBjb25maWcg
cGFyc2luZyBlcnJvciBpbiB2aWY6ICVzIGluIGAlcydcbiIsCisgICAgICAgICAgICBjZmctPmZp
bGVuYW1lLCBtc2csIHJhdGUpOworfQorCitzdGF0aWMgaW50IHZpZl9wYXJzZV9yYXRlX2J5dGVz
X3Blcl9zZWMoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICpieXRlcywKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50NjRfdCAqYnl0ZXNfcGVyX3NlYykKK3sK
KyAgICByZWdleF90IHJlYzsKKyAgICB1aW50NjRfdCB0bXAgPSAwOworICAgIGNvbnN0IGNoYXIg
KnA7CisgICAgaW50IHJjID0gMDsKKworICAgIHJlZ2NvbXAoJnJlYywgdmlmX2J5dGVzX3Blcl9z
ZWNfcmUsIFJFR19FWFRFTkRFRHxSRUdfTk9TVUIpOworICAgIGlmIChyZWdleGVjKCZyZWMsIGJ5
dGVzLCAwLCBOVUxMLCAwKSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAiaW52YWxpZCBy
YXRlIiwgYnl0ZXMpOworICAgICAgICByYyA9IEVJTlZBTDsKKyAgICAgICAgZ290byBvdXQ7Cisg
ICAgfQorCisgICAgcCA9IGJ5dGVzOworICAgIHRtcCA9IHN0cnRvdWxsKHAsIChjaGFyKiopJnAs
IDApOworICAgIGlmICh0bXAgPT0gMCB8fCB0bXAgPiBVSU5UMzJfTUFYIHx8IGVycm5vID09IEVS
QU5HRSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAicmF0ZSBvdmVyZmxvdyIsIGJ5dGVz
KTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKwor
ICAgIGlmICgqcCA9PSAnRycpCisgICAgICAgdG1wICo9IDEwMDAgKiAxMDAwICogMTAwMDsKKyAg
ICBlbHNlIGlmICgqcCA9PSAnTScpCisgICAgICAgdG1wICo9IDEwMDAgKiAxMDAwOworICAgIGVs
c2UgaWYgKCpwID09ICdLJykKKyAgICAgICB0bXAgKj0gMTAwMDsKKyAgICBpZiAoKnAgPT0gJ2In
IHx8ICoocCsxKSA9PSAnYicpCisgICAgICAgdG1wIC89IDg7CisKKyAgICAqYnl0ZXNfcGVyX3Nl
YyA9IHRtcDsKKworb3V0OgorICAgIHJlZ2ZyZWUoJnJlYyk7CisgICAgcmV0dXJuIHJjOworfQor
CitzdGF0aWMgaW50IHZpZl9wYXJzZV9yYXRlX2ludGVydmFsX3VzZWNzKFhMVV9Db25maWcgKmNm
ZywgY29uc3QgY2hhciAqaW50ZXJ2YWwsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHVpbnQzMl90ICppbnRlcnZhbF91c2VjcykKK3sKKyAgICByZWdleF90IHJlYzsK
KyAgICB1aW50NjRfdCB0bXAgPSAwOworICAgIGNvbnN0IGNoYXIgKnA7CisgICAgaW50IHJjID0g
MDsKKworICAgIHJlZ2NvbXAoJnJlYywgdmlmX2ludGVybmFsX3VzZWNfcmUsIFJFR19FWFRFTkRF
RHxSRUdfTk9TVUIpOworICAgIGlmIChyZWdleGVjKCZyZWMsIGludGVydmFsLCAwLCBOVUxMLCAw
KSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAiaW52YWxpZCByZXBsZW5pc2htZW50IGlu
dGVydmFsIiwgaW50ZXJ2YWwpOworICAgICAgICByYyA9IEVJTlZBTDsKKyAgICAgICAgZ290byBv
dXQ7CisgICAgfQorCisgICAgcCA9IGludGVydmFsOworICAgIHRtcCA9IHN0cnRvdWxsKHAsIChj
aGFyKiopJnAsIDApOworICAgIGlmICh0bXAgPT0gMCB8fCB0bXAgPiBVSU5UMzJfTUFYIHx8IGVy
cm5vID09IEVSQU5HRSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAicmVwbGVuaXNobWVu
dCBpbnRlcnZhbCBvdmVyZmxvdyIsIGludGVydmFsKTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7
CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKworICAgIGlmICgqcCA9PSAncycgfHwgKnAgPT0g
J1wwJykKKyAgICAgICAgdG1wICo9IDEwMDAgKiAxMDAwOworICAgIGVsc2UgaWYgKCpwID09ICdt
JykKKyAgICAgICAgdG1wICo9IDEwMDA7CisKKyAgICBpZiAodG1wID4gVUlOVDMyX01BWCkgewor
ICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAicmVwbGVuaXNobWVudCBpbnRlcnZhbCBvdmVyZmxv
dyIsIGludGVydmFsKTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7CisgICAgICAgIGdvdG8gb3V0
OworICAgIH0KKworICAgICppbnRlcnZhbF91c2VjcyA9ICh1aW50MzJfdCkgdG1wOworCitvdXQ6
CisgICAgcmVnZnJlZSgmcmVjKTsKKyAgICByZXR1cm4gcmM7Cit9CisKK2ludCB4bHVfdmlmX3Bh
cnNlX3JhdGUoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICpyYXRlLCBsaWJ4bF9kZXZpY2Vf
bmljICpuaWMpCit7CisgICAgdWludDY0X3QgYnl0ZXNfcGVyX3NlYyA9IDA7CisgICAgdWludDY0
X3QgYnl0ZXNfcGVyX2ludGVydmFsID0gMDsKKyAgICB1aW50MzJfdCBpbnRlcnZhbF91c2VjcyA9
IDUwMDAwVUw7IC8qIERlZmF1bHQgdG8gNTBtcyAqLworICAgIGNoYXIgKnJhdGV0b2ssICp0bXBy
YXRlOworICAgIGludCByYyA9IDA7CisKKyAgICB0bXByYXRlID0gc3RyZHVwKHJhdGUpOworICAg
IGlmICghc3RyY21wKHRtcHJhdGUsIiIpKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJu
byByYXRlIHNwZWNpZmllZCIsIHJhdGUpOworICAgICAgICByYyA9IEVJTlZBTDsKKyAgICAgICAg
Z290byBvdXQ7CisgICAgfQorCisgICAgcmF0ZXRvayA9IHN0cnRvayh0bXByYXRlLCAiQCIpOwor
ICAgIHJjID0gdmlmX3BhcnNlX3JhdGVfYnl0ZXNfcGVyX3NlYyhjZmcsIHJhdGV0b2ssICZieXRl
c19wZXJfc2VjKTsKKyAgICBpZiAocmMpIGdvdG8gb3V0OworCisgICAgcmF0ZXRvayA9IHN0cnRv
ayhOVUxMLCAiQCIpOworICAgIGlmIChyYXRldG9rICE9IE5VTEwpIHsKKyAgICAgICAgcmMgPSB2
aWZfcGFyc2VfcmF0ZV9pbnRlcnZhbF91c2VjcyhjZmcsIHJhdGV0b2ssICZpbnRlcnZhbF91c2Vj
cyk7CisgICAgICAgIGlmIChyYykgZ290byBvdXQ7CisgICAgfQorCisgICAgaWYgKGludGVydmFs
X3VzZWNzICE9IDAgJiYgKGJ5dGVzX3Blcl9zZWMgPiAoVUlOVDY0X01BWCAvIGludGVydmFsX3Vz
ZWNzKSkpIHsKKyAgICAgICAgeGx1X192aWZfZXJyKGNmZywgInJhdGUgb3ZlcmZsb3ciLCByYXRl
KTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKwor
ICAgIGJ5dGVzX3Blcl9pbnRlcnZhbCA9CisgICAgICAgICgoKHVpbnQ2NF90KSBieXRlc19wZXJf
c2VjICogKHVpbnQ2NF90KSBpbnRlcnZhbF91c2VjcykgLyAxMDAwMDAwVUwpOworCisgICAgbmlj
LT5yYXRlX2ludGVydmFsX3VzZWNzID0gaW50ZXJ2YWxfdXNlY3M7CisgICAgbmljLT5yYXRlX2J5
dGVzX3Blcl9pbnRlcnZhbCA9IGJ5dGVzX3Blcl9pbnRlcnZhbDsKKworb3V0OgorICAgIGZyZWUo
dG1wcmF0ZSk7CisgICAgcmV0dXJuIHJjOworfQorCisvKgorICogTG9jYWwgdmFyaWFibGVzOgor
ICogbW9kZTogQworICogYy1iYXNpYy1vZmZzZXQ6IDQKKyAqIGluZGVudC10YWJzLW1vZGU6IG5p
bAorICogRW5kOgorICovCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bHV0aWwuaCBiL3Rv
b2xzL2xpYnhsL2xpYnhsdXRpbC5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdXRpbC5oCisrKyBi
L3Rvb2xzL2xpYnhsL2xpYnhsdXRpbC5oCkBAIC05NCw2ICs5NCwxMyBAQCBpbnQgeGx1X2Rpc2tf
cGFyc2UoWExVX0NvbmZpZyAqY2ZnLCBpbnQgCiBpbnQgeGx1X3BjaV9wYXJzZV9iZGYoWExVX0Nv
bmZpZyAqY2ZnLCBsaWJ4bF9kZXZpY2VfcGNpICpwY2lkZXYsIGNvbnN0IGNoYXIgKnN0cik7CiAK
IAorLyoKKyAqIFZpZiByYXRlIHBhcnNpbmcuCisgKi8KKworaW50IHhsdV92aWZfcGFyc2VfcmF0
ZShYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNoYXIgKnJhdGUsCisgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX2RldmljZV9uaWMgKm5pYyk7CisKICNlbmRpZiAvKiBMSUJYTFVUSUxfSCAqLwog
CiAvKgpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jIGIvdG9vbHMvbGlieGwv
eGxfY21kaW1wbC5jCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYworKysgYi90b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMKQEAgLTQwMyw2ICs0MDMsMjQgQEAgc3RhdGljIHZvaWQgcGFyc2Vf
ZGlza19jb25maWcoWExVX0NvbmZpZwogICAgIHBhcnNlX2Rpc2tfY29uZmlnX211bHRpc3RyaW5n
KGNvbmZpZywgMSwgJnNwZWMsIGRpc2spOwogfQogCitzdGF0aWMgdm9pZCBwYXJzZV92aWZfcmF0
ZShYTFVfQ29uZmlnICoqY29uZmlnLCBjb25zdCBjaGFyICpyYXRlLAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbGlieGxfZGV2aWNlX25pYyAqbmljKQoreworICAgIGludCBlOworCisgICAg
aWYgKCEqY29uZmlnKSB7CisgICAgICAgICpjb25maWcgPSB4bHVfY2ZnX2luaXQoc3RkZXJyLCAi
Y29tbWFuZCBsaW5lIik7CisgICAgICAgIGlmICghKmNvbmZpZykgeyBwZXJyb3IoInhsdV9jZmdf
aW5pdCIpOyBleGl0KC0xKTsgfQorICAgIH0KKworICAgIGUgPSB4bHVfdmlmX3BhcnNlX3JhdGUo
KmNvbmZpZywgcmF0ZSwgbmljKTsKKyAgICBpZiAoZSA9PSBFSU5WQUwgfHwgZSA9PSBFT1ZFUkZM
T1cpIGV4aXQoLTEpOworICAgIGlmIChlKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCJ4bHVf
dmlmX3BhcnNlX3JhdGUgZmFpbGVkOiAlc1xuIixzdHJlcnJvcihlcnJubykpOworICAgICAgICBl
eGl0KC0xKTsKKyAgICB9Cit9CisKIHN0YXRpYyB2b2lkIHNwbGl0X3N0cmluZ19pbnRvX3N0cmlu
Z19saXN0KGNvbnN0IGNoYXIgKnN0ciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGNvbnN0IGNoYXIgKmRlbGltLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbGlieGxfc3RyaW5nX2xpc3QgKnBzbCkKQEAgLTkwNiw3ICs5MjQsNyBA
QCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFyCiAgICAgICAgICAgICAg
ICAgICAgICAgICBuaWMtPmJhY2tlbmRfZG9taWQgPSAwOwogICAgICAgICAgICAgICAgICAgICB9
CiAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICghc3RyY21wKHAsICJyYXRlIikpIHsKLSAgICAg
ICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgcmF0ZSBwYXJhbWV0ZXIgZm9yIHZp
ZnMgaXMgY3VycmVudGx5IG5vdCBzdXBwb3J0ZWRcbiIpOworICAgICAgICAgICAgICAgICAgICBw
YXJzZV92aWZfcmF0ZSgmY29uZmlnLCAocDIgKyAxKSwgbmljKTsKICAgICAgICAgICAgICAgICB9
IGVsc2UgaWYgKCFzdHJjbXAocCwgImFjY2VsIikpIHsKICAgICAgICAgICAgICAgICAgICAgZnBy
aW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJlbnRseSBu
b3Qgc3VwcG9ydGVkXG4iKTsKICAgICAgICAgICAgICAgICB9CkBAIC00ODU1LDYgKzQ4NzMsNyBA
QCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCiB7CiAgICAgaW50IG9w
dDsKICAgICBsaWJ4bF9kZXZpY2VfbmljIG5pYzsKKyAgICBYTFVfQ29uZmlnICpjb25maWcgPSAw
OwogICAgIGNoYXIgKmVuZHB0ciwgKm9wYXJnOwogICAgIGNvbnN0IGNoYXIgKnRvazsKICAgICBp
bnQgaTsKQEAgLTQ5MTAsNiArNDkyOSw3IEBAIGludCBtYWluX25ldHdvcmthdHRhY2goaW50IGFy
Z2MsIGNoYXIgKioKICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04oIm1vZGVsIiwgKmFy
Z3YsIG9wYXJnKSkgewogICAgICAgICAgICAgcmVwbGFjZV9zdHJpbmcoJm5pYy5tb2RlbCwgb3Bh
cmcpOwogICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigicmF0ZSIsICphcmd2LCBvcGFy
ZykpIHsKKyAgICAgICAgICAgIHBhcnNlX3ZpZl9yYXRlKCZjb25maWcsIG9wYXJnLCAmbmljKTsK
ICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04oImFjY2VsIiwgKmFyZ3YsIG9wYXJnKSkg
ewogICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ1bnJlY29n
bml6ZWQgYXJndW1lbnQgYCVzJ1xuIiwgKmFyZ3YpOwpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 17 01:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 01:59:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxgq-0006St-R4; Tue, 17 Apr 2012 01:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SJxgo-0006SC-5w
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 01:58:43 +0000
Received: from [85.158.143.99:39711] by server-3.bemta-4.messagelabs.com id
	A5/FA-05853-15ECC8F4; Tue, 17 Apr 2012 01:58:41 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334627918!23593808!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5853 invoked from network); 17 Apr 2012 01:58:39 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-5.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 01:58:39 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 4664623A72; Mon, 16 Apr 2012 22:06:55 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: **
X-Spam-Status: No, score=2.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_64,
	J_CHICKENPOX_81,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME,TW_BX,TW_CF,
	TW_IB autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id B991523ADA;
	Mon, 16 Apr 2012 22:06:51 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 5207B281A8; Mon, 16 Apr 2012 21:58:34 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: a523c29eb8751c50de0916bb97717d9509aeed9c
Message-Id: <a523c29eb8751c50de09.1334627905@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 21:58:25 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 v2] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIGByYXRlYCBrZXl3b3JkIHNwZWNpZmllcyB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgb3V0Z29p
bmcgdHJhZmZpYyB3aWxsIGJlIGxpbWl0ZWQgdG8uClRoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29y
ZCBpcyBub3Qgc3BlY2lmaWVkIGlzIHVubGltaXRlZC4KClRoZSBgcmF0ZWAga2V5d29yZCBzdXBw
b3J0cyBhbiBvcHRpb25hbCByZXBsZW5pc2htZW50IGludGVydmFsIHBhcmFtZXRlciBmb3Igc3Bl
Y2lmeWluZwp0aGUgZ3JhbnVsYXJpdHkgb2YgY3JlZGl0IHJlcGxlbmlzaG1lbnQuIEl0IGRldGVy
bWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaAp0aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQg
aXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMuCgpGb3IgZXhhbXBs
ZToKCiAgICAgICAgJ3JhdGU9MTBNYi9zJwogICAgICAgICdyYXRlPTI1MEtCL3MnCiAgICAgICAg
J3JhdGU9MU1CL3NAMjBtcycKClNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2FnbmVA
aXdlYi5jb20+CgpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlv
bi5tYXJrZG93biBiL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24K
LS0tIGEvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgorKysgYi9k
b2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCkBAIC0xMjIsNSArMTIy
LDM0IEBAIFNwZWNpZmllcyB0aGUgYmFja2VuZCBkb21haW4gd2hpY2ggdGhpcyAKIGRlZmF1bHRz
IHRvIGRvbWFpbiAwLiBTcGVjaWZ5aW5nIGFub3RoZXIgZG9tYWluIHJlcXVpcmVzIHNldHRpbmcg
dXAgYQogZHJpdmVyIGRvbWFpbiB3aGljaCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv
Y3VtZW50LgogCisjIyMgcmF0ZQorCitTcGVjaWZpZXMgdGhlIHJhdGUgYXQgd2hpY2ggdGhlIG91
dGdvaW5nIHRyYWZmaWMgd2lsbCBiZSBsaW1pdGVkIHRvLgorVGhlIGRlZmF1bHQgaWYgdGhpcyBr
ZXl3b3JkIGlzIG5vdCBzcGVjaWZpZWQgaXMgdW5saW1pdGVkLgorCitUaGUgcmF0ZSBtYXkgYmUg
c3BlY2lmaWVkIGFzICI8UkFURT4vcyIgb3Igb3B0aW9uYWxseSAiPFJBVEU+L3NAPElOVEVSVkFM
PiIuCisKKyAgKiBgUkFURWAgaXMgaW4gYnl0ZXMgYW5kIGNhbiBhY2NlcHQgc3VmZml4ZXM6Cisg
ICAgICAqIEdCLCBNQiwgS0IsIEIgZm9yIGJ5dGVzLgorICAgICAgKiBHYiwgTWIsIEtiLCBiIGZv
ciBiaXRzLgorICAqIGBJTlRFUlZBTGAgaXMgaW4gbWljcm9zZWNvbmRzIGFuZCBjYW4gYWNjZXB0
IHN1ZmZpeGVzOiBtcywgdXMsIHMuCisgICAgSXQgZGV0ZXJtaW5lcyB0aGUgZnJlcXVlbmN5IGF0
IHdoaWNoIHRoZSB2aWYgdHJhbnNtaXNzaW9uIGNyZWRpdAorICAgIGlzIHJlcGxlbmlzaGVkLiBU
aGUgZGVmYXVsdCBpcyA1MG1zLgorCitWaWYgcmF0ZSBsaW1pdGluZyBpcyBjcmVkaXQtYmFzZWQu
IEl0IG1lYW5zIHRoYXQgZm9yICIxTUIvc0AyMG1zIiwgdGhlCithdmFpbGFibGUgY3JlZGl0IHdp
bGwgYmUgZXF1aXZhbGVudCBvZiB0aGUgdHJhZmZpYyB5b3Ugd291bGQgaGF2ZSBkb25lCithdCAi
MU1CL3MiIGR1cmluZyAyMG1zLiBUaGlzIHdpbGwgcmVzdWx0cyBpbiBhIGNyZWRpdCBvZiAyMCww
MDAgYnl0ZXMKK3JlcGxlbmlzaGVkIGV2ZXJ5IDIwLDAwMCB1cy4KKworRm9yIGV4YW1wbGU6CisK
KyAgICAgICAgJ3JhdGU9MTBNYi9zJyAtLSBtZWFuaW5nIHVwIHRvIDEwIG1lZ2FiaXRzIGV2ZXJ5
IHNlY29uZAorICAgICAgICAncmF0ZT0yNTBLQi9zJyAtLSBtZWFuaW5nIHVwIHRvIDI1MCBraWxv
Ynl0ZXMgZXZlcnkgc2Vjb25kCisgICAgICAgICdyYXRlPTFNQi9zQDIwbXMnIC0tIG1lYW5pbmcg
MjAsMDAwIGJ5dGVzIGluIGV2ZXJ5IDIwIG1pbGxpc2Vjb25kIHBlcmlvZAorCitOT1RFOiBUaGUg
YWN0dWFsIHVuZGVybHlpbmcgbGltaXRzIG9mIHJhdGUgbGltaXRpbmcgYXJlIGRlcGVuZGVudAor
b24gdGhlIHVuZGVybHlpbmcgbmV0YmFjayBpbXBsZW1lbnRhdGlvbi4KKworCiBbb3VpXTogaHR0
cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Pcmdhbml6YXRpb25hbGx5X1VuaXF1ZV9JZGVudGlm
aWVyCiBbbmV0XTogaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL0hvc3RDb25maWd1cmF0aW9uL05l
dHdvcmtpbmcKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlIGIvdG9vbHMvbGlieGwv
TWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUKKysrIGIvdG9vbHMvbGlieGwvTWFr
ZWZpbGUKQEAgLTYxLDcgKzYxLDcgQEAgTElCWExfT0JKUyArPSBfbGlieGxfdHlwZXMubyBsaWJ4
bF9mbGFzawogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhsdV9jZmdfbC5oIF9saWJ4bF9s
aXN0LmgKIEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVfY2ZnX2wuYwogTElCWExVX09C
SlMgPSBsaWJ4bHVfY2ZnX3kubyBsaWJ4bHVfY2ZnX2wubyBsaWJ4bHVfY2ZnLm8gXAotCWxpYnhs
dV9kaXNrX2wubyBsaWJ4bHVfZGlzay5vIGxpYnhsdV9wY2kubworCWxpYnhsdV9kaXNrX2wubyBs
aWJ4bHVfZGlzay5vIGxpYnhsdV92aWYubyBsaWJ4bHVfcGNpLm8KICQoTElCWExVX09CSlMpOiBD
RkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3IgeGVudG9vbGxvZy5oCiAKIENMSUVO
VFMgPSB4bCB0ZXN0aWRsCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMv
bGlieGwvbGlieGwuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCisrKyBiL3Rvb2xzL2xpYnhs
L2xpYnhsLmMKQEAgLTE4NTQsNiArMTg1NCwxMyBAQCBpbnQgbGlieGxfZGV2aWNlX25pY19hZGQo
bGlieGxfY3R4ICpjdHgsCiAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0
cmR1cChnYywgbmljLT5pcCkpOwogICAgIH0KIAorICAgIGlmIChuaWMtPnJhdGVfaW50ZXJ2YWxf
dXNlY3MgPiAwKSB7CisgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgInJhdGUiKTsKKyAg
ICAgICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCBsaWJ4bF9fc3ByaW50ZihnYywgIiVsbHUsJWx1
IiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAodW5zaWduZWQgbG9uZyBsb25nKSBuaWMt
PnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICh1
bnNpZ25lZCBsb25nKSBuaWMtPnJhdGVfaW50ZXJ2YWxfdXNlY3MpKTsKKyAgICB9CisKICAgICBm
bGV4YXJyYXlfYXBwZW5kKGJhY2ssICJicmlkZ2UiKTsKICAgICBmbGV4YXJyYXlfYXBwZW5kKGJh
Y2ssIGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+YnJpZGdlKSk7CiAgICAgZmxleGFycmF5X2FwcGVu
ZChiYWNrLCAiaGFuZGxlIik7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5p
ZGwgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbApAQCAtMzQzLDYgKzM0
Myw4IEBAIGxpYnhsX2RldmljZV9uaWMgPSBTdHJ1Y3QoImRldmljZV9uaWMiLCAKICAgICAoImlm
bmFtZSIsIHN0cmluZyksCiAgICAgKCJzY3JpcHQiLCBzdHJpbmcpLAogICAgICgibmljdHlwZSIs
IGxpYnhsX25pY190eXBlKSwKKyAgICAoInJhdGVfYnl0ZXNfcGVyX2ludGVydmFsIiwgdWludDY0
KSwKKyAgICAoInJhdGVfaW50ZXJ2YWxfdXNlY3MiLCB1aW50MzIpLAogICAgIF0pCiAKIGxpYnhs
X2RldmljZV9wY2kgPSBTdHJ1Y3QoImRldmljZV9wY2kiLCBbCmRpZmYgLS1naXQgYS90b29scy9s
aWJ4bC9saWJ4bHVfaW50ZXJuYWwuaCBiL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oCi0t
LSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhs
dV9pbnRlcm5hbC5oCkBAIC0xNyw5ICsxNywxMSBAQAogI2RlZmluZSBMSUJYTFVfSU5URVJOQUxf
SAogCiAjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KICNpbmNsdWRlIDxl
cnJuby5oPgogI2luY2x1ZGUgPHN0cmluZy5oPgogI2luY2x1ZGUgPGFzc2VydC5oPgorI2luY2x1
ZGUgPHJlZ2V4Lmg+CiAKICNkZWZpbmUgWExVX0NvbmZpZ0xpc3QgWExVX0NvbmZpZ1NldHRpbmcK
IApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGx1X3ZpZi5jIGIvdG9vbHMvbGlieGwvbGli
eGx1X3ZpZi5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Ci0tLSAvZGV2L251bGwKKysrIGIvdG9vbHMv
bGlieGwvbGlieGx1X3ZpZi5jCkBAIC0wLDAgKzEsMTQxIEBACisjaW5jbHVkZSAibGlieGxfb3Nk
ZXBzLmgiIC8qIG11c3QgY29tZSBiZWZvcmUgYW55IG90aGVyIGhlYWRlcnMgKi8KKyNpbmNsdWRl
ICJsaWJ4bHVfaW50ZXJuYWwuaCIKKworc3RhdGljIGNvbnN0IGNoYXIgKnZpZl9ieXRlc19wZXJf
c2VjX3JlID0gIl5bMC05XStbR01LXT9bQmJdL3MkIjsKK3N0YXRpYyBjb25zdCBjaGFyICp2aWZf
aW50ZXJuYWxfdXNlY19yZSA9ICJeWzAtOV0rW211XT9zPyQiOworCitzdGF0aWMgdm9pZCB4bHVf
X3ZpZl9lcnIoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICptc2csIGNvbnN0IGNoYXIgKnJh
dGUpIHsKKyAgICBmcHJpbnRmKGNmZy0+cmVwb3J0LAorICAgICAgICAgICAgIiVzOiBjb25maWcg
cGFyc2luZyBlcnJvciBpbiB2aWY6ICVzIGluIGAlcydcbiIsCisgICAgICAgICAgICBjZmctPmZp
bGVuYW1lLCBtc2csIHJhdGUpOworfQorCitzdGF0aWMgaW50IHZpZl9wYXJzZV9yYXRlX2J5dGVz
X3Blcl9zZWMoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICpieXRlcywKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50NjRfdCAqYnl0ZXNfcGVyX3NlYykKK3sK
KyAgICByZWdleF90IHJlYzsKKyAgICB1aW50NjRfdCB0bXAgPSAwOworICAgIGNvbnN0IGNoYXIg
KnA7CisgICAgaW50IHJjID0gMDsKKworICAgIHJlZ2NvbXAoJnJlYywgdmlmX2J5dGVzX3Blcl9z
ZWNfcmUsIFJFR19FWFRFTkRFRHxSRUdfTk9TVUIpOworICAgIGlmIChyZWdleGVjKCZyZWMsIGJ5
dGVzLCAwLCBOVUxMLCAwKSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAiaW52YWxpZCBy
YXRlIiwgYnl0ZXMpOworICAgICAgICByYyA9IEVJTlZBTDsKKyAgICAgICAgZ290byBvdXQ7Cisg
ICAgfQorCisgICAgcCA9IGJ5dGVzOworICAgIHRtcCA9IHN0cnRvdWxsKHAsIChjaGFyKiopJnAs
IDApOworICAgIGlmICh0bXAgPT0gMCB8fCB0bXAgPiBVSU5UMzJfTUFYIHx8IGVycm5vID09IEVS
QU5HRSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAicmF0ZSBvdmVyZmxvdyIsIGJ5dGVz
KTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKwor
ICAgIGlmICgqcCA9PSAnRycpCisgICAgICAgdG1wICo9IDEwMDAgKiAxMDAwICogMTAwMDsKKyAg
ICBlbHNlIGlmICgqcCA9PSAnTScpCisgICAgICAgdG1wICo9IDEwMDAgKiAxMDAwOworICAgIGVs
c2UgaWYgKCpwID09ICdLJykKKyAgICAgICB0bXAgKj0gMTAwMDsKKyAgICBpZiAoKnAgPT0gJ2In
IHx8ICoocCsxKSA9PSAnYicpCisgICAgICAgdG1wIC89IDg7CisKKyAgICAqYnl0ZXNfcGVyX3Nl
YyA9IHRtcDsKKworb3V0OgorICAgIHJlZ2ZyZWUoJnJlYyk7CisgICAgcmV0dXJuIHJjOworfQor
CitzdGF0aWMgaW50IHZpZl9wYXJzZV9yYXRlX2ludGVydmFsX3VzZWNzKFhMVV9Db25maWcgKmNm
ZywgY29uc3QgY2hhciAqaW50ZXJ2YWwsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHVpbnQzMl90ICppbnRlcnZhbF91c2VjcykKK3sKKyAgICByZWdleF90IHJlYzsK
KyAgICB1aW50NjRfdCB0bXAgPSAwOworICAgIGNvbnN0IGNoYXIgKnA7CisgICAgaW50IHJjID0g
MDsKKworICAgIHJlZ2NvbXAoJnJlYywgdmlmX2ludGVybmFsX3VzZWNfcmUsIFJFR19FWFRFTkRF
RHxSRUdfTk9TVUIpOworICAgIGlmIChyZWdleGVjKCZyZWMsIGludGVydmFsLCAwLCBOVUxMLCAw
KSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAiaW52YWxpZCByZXBsZW5pc2htZW50IGlu
dGVydmFsIiwgaW50ZXJ2YWwpOworICAgICAgICByYyA9IEVJTlZBTDsKKyAgICAgICAgZ290byBv
dXQ7CisgICAgfQorCisgICAgcCA9IGludGVydmFsOworICAgIHRtcCA9IHN0cnRvdWxsKHAsIChj
aGFyKiopJnAsIDApOworICAgIGlmICh0bXAgPT0gMCB8fCB0bXAgPiBVSU5UMzJfTUFYIHx8IGVy
cm5vID09IEVSQU5HRSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAicmVwbGVuaXNobWVu
dCBpbnRlcnZhbCBvdmVyZmxvdyIsIGludGVydmFsKTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7
CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKworICAgIGlmICgqcCA9PSAncycgfHwgKnAgPT0g
J1wwJykKKyAgICAgICAgdG1wICo9IDEwMDAgKiAxMDAwOworICAgIGVsc2UgaWYgKCpwID09ICdt
JykKKyAgICAgICAgdG1wICo9IDEwMDA7CisKKyAgICBpZiAodG1wID4gVUlOVDMyX01BWCkgewor
ICAgICAgICB4bHVfX3ZpZl9lcnIoY2ZnLCAicmVwbGVuaXNobWVudCBpbnRlcnZhbCBvdmVyZmxv
dyIsIGludGVydmFsKTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7CisgICAgICAgIGdvdG8gb3V0
OworICAgIH0KKworICAgICppbnRlcnZhbF91c2VjcyA9ICh1aW50MzJfdCkgdG1wOworCitvdXQ6
CisgICAgcmVnZnJlZSgmcmVjKTsKKyAgICByZXR1cm4gcmM7Cit9CisKK2ludCB4bHVfdmlmX3Bh
cnNlX3JhdGUoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICpyYXRlLCBsaWJ4bF9kZXZpY2Vf
bmljICpuaWMpCit7CisgICAgdWludDY0X3QgYnl0ZXNfcGVyX3NlYyA9IDA7CisgICAgdWludDY0
X3QgYnl0ZXNfcGVyX2ludGVydmFsID0gMDsKKyAgICB1aW50MzJfdCBpbnRlcnZhbF91c2VjcyA9
IDUwMDAwVUw7IC8qIERlZmF1bHQgdG8gNTBtcyAqLworICAgIGNoYXIgKnJhdGV0b2ssICp0bXBy
YXRlOworICAgIGludCByYyA9IDA7CisKKyAgICB0bXByYXRlID0gc3RyZHVwKHJhdGUpOworICAg
IGlmICghc3RyY21wKHRtcHJhdGUsIiIpKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJu
byByYXRlIHNwZWNpZmllZCIsIHJhdGUpOworICAgICAgICByYyA9IEVJTlZBTDsKKyAgICAgICAg
Z290byBvdXQ7CisgICAgfQorCisgICAgcmF0ZXRvayA9IHN0cnRvayh0bXByYXRlLCAiQCIpOwor
ICAgIHJjID0gdmlmX3BhcnNlX3JhdGVfYnl0ZXNfcGVyX3NlYyhjZmcsIHJhdGV0b2ssICZieXRl
c19wZXJfc2VjKTsKKyAgICBpZiAocmMpIGdvdG8gb3V0OworCisgICAgcmF0ZXRvayA9IHN0cnRv
ayhOVUxMLCAiQCIpOworICAgIGlmIChyYXRldG9rICE9IE5VTEwpIHsKKyAgICAgICAgcmMgPSB2
aWZfcGFyc2VfcmF0ZV9pbnRlcnZhbF91c2VjcyhjZmcsIHJhdGV0b2ssICZpbnRlcnZhbF91c2Vj
cyk7CisgICAgICAgIGlmIChyYykgZ290byBvdXQ7CisgICAgfQorCisgICAgaWYgKGludGVydmFs
X3VzZWNzICE9IDAgJiYgKGJ5dGVzX3Blcl9zZWMgPiAoVUlOVDY0X01BWCAvIGludGVydmFsX3Vz
ZWNzKSkpIHsKKyAgICAgICAgeGx1X192aWZfZXJyKGNmZywgInJhdGUgb3ZlcmZsb3ciLCByYXRl
KTsKKyAgICAgICAgcmMgPSBFT1ZFUkZMT1c7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKwor
ICAgIGJ5dGVzX3Blcl9pbnRlcnZhbCA9CisgICAgICAgICgoKHVpbnQ2NF90KSBieXRlc19wZXJf
c2VjICogKHVpbnQ2NF90KSBpbnRlcnZhbF91c2VjcykgLyAxMDAwMDAwVUwpOworCisgICAgbmlj
LT5yYXRlX2ludGVydmFsX3VzZWNzID0gaW50ZXJ2YWxfdXNlY3M7CisgICAgbmljLT5yYXRlX2J5
dGVzX3Blcl9pbnRlcnZhbCA9IGJ5dGVzX3Blcl9pbnRlcnZhbDsKKworb3V0OgorICAgIGZyZWUo
dG1wcmF0ZSk7CisgICAgcmV0dXJuIHJjOworfQorCisvKgorICogTG9jYWwgdmFyaWFibGVzOgor
ICogbW9kZTogQworICogYy1iYXNpYy1vZmZzZXQ6IDQKKyAqIGluZGVudC10YWJzLW1vZGU6IG5p
bAorICogRW5kOgorICovCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bHV0aWwuaCBiL3Rv
b2xzL2xpYnhsL2xpYnhsdXRpbC5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdXRpbC5oCisrKyBi
L3Rvb2xzL2xpYnhsL2xpYnhsdXRpbC5oCkBAIC05NCw2ICs5NCwxMyBAQCBpbnQgeGx1X2Rpc2tf
cGFyc2UoWExVX0NvbmZpZyAqY2ZnLCBpbnQgCiBpbnQgeGx1X3BjaV9wYXJzZV9iZGYoWExVX0Nv
bmZpZyAqY2ZnLCBsaWJ4bF9kZXZpY2VfcGNpICpwY2lkZXYsIGNvbnN0IGNoYXIgKnN0cik7CiAK
IAorLyoKKyAqIFZpZiByYXRlIHBhcnNpbmcuCisgKi8KKworaW50IHhsdV92aWZfcGFyc2VfcmF0
ZShYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNoYXIgKnJhdGUsCisgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX2RldmljZV9uaWMgKm5pYyk7CisKICNlbmRpZiAvKiBMSUJYTFVUSUxfSCAqLwog
CiAvKgpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jIGIvdG9vbHMvbGlieGwv
eGxfY21kaW1wbC5jCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYworKysgYi90b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMKQEAgLTQwMyw2ICs0MDMsMjQgQEAgc3RhdGljIHZvaWQgcGFyc2Vf
ZGlza19jb25maWcoWExVX0NvbmZpZwogICAgIHBhcnNlX2Rpc2tfY29uZmlnX211bHRpc3RyaW5n
KGNvbmZpZywgMSwgJnNwZWMsIGRpc2spOwogfQogCitzdGF0aWMgdm9pZCBwYXJzZV92aWZfcmF0
ZShYTFVfQ29uZmlnICoqY29uZmlnLCBjb25zdCBjaGFyICpyYXRlLAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbGlieGxfZGV2aWNlX25pYyAqbmljKQoreworICAgIGludCBlOworCisgICAg
aWYgKCEqY29uZmlnKSB7CisgICAgICAgICpjb25maWcgPSB4bHVfY2ZnX2luaXQoc3RkZXJyLCAi
Y29tbWFuZCBsaW5lIik7CisgICAgICAgIGlmICghKmNvbmZpZykgeyBwZXJyb3IoInhsdV9jZmdf
aW5pdCIpOyBleGl0KC0xKTsgfQorICAgIH0KKworICAgIGUgPSB4bHVfdmlmX3BhcnNlX3JhdGUo
KmNvbmZpZywgcmF0ZSwgbmljKTsKKyAgICBpZiAoZSA9PSBFSU5WQUwgfHwgZSA9PSBFT1ZFUkZM
T1cpIGV4aXQoLTEpOworICAgIGlmIChlKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCJ4bHVf
dmlmX3BhcnNlX3JhdGUgZmFpbGVkOiAlc1xuIixzdHJlcnJvcihlcnJubykpOworICAgICAgICBl
eGl0KC0xKTsKKyAgICB9Cit9CisKIHN0YXRpYyB2b2lkIHNwbGl0X3N0cmluZ19pbnRvX3N0cmlu
Z19saXN0KGNvbnN0IGNoYXIgKnN0ciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGNvbnN0IGNoYXIgKmRlbGltLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbGlieGxfc3RyaW5nX2xpc3QgKnBzbCkKQEAgLTkwNiw3ICs5MjQsNyBA
QCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFyCiAgICAgICAgICAgICAg
ICAgICAgICAgICBuaWMtPmJhY2tlbmRfZG9taWQgPSAwOwogICAgICAgICAgICAgICAgICAgICB9
CiAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICghc3RyY21wKHAsICJyYXRlIikpIHsKLSAgICAg
ICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgcmF0ZSBwYXJhbWV0ZXIgZm9yIHZp
ZnMgaXMgY3VycmVudGx5IG5vdCBzdXBwb3J0ZWRcbiIpOworICAgICAgICAgICAgICAgICAgICBw
YXJzZV92aWZfcmF0ZSgmY29uZmlnLCAocDIgKyAxKSwgbmljKTsKICAgICAgICAgICAgICAgICB9
IGVsc2UgaWYgKCFzdHJjbXAocCwgImFjY2VsIikpIHsKICAgICAgICAgICAgICAgICAgICAgZnBy
aW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJlbnRseSBu
b3Qgc3VwcG9ydGVkXG4iKTsKICAgICAgICAgICAgICAgICB9CkBAIC00ODU1LDYgKzQ4NzMsNyBA
QCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCiB7CiAgICAgaW50IG9w
dDsKICAgICBsaWJ4bF9kZXZpY2VfbmljIG5pYzsKKyAgICBYTFVfQ29uZmlnICpjb25maWcgPSAw
OwogICAgIGNoYXIgKmVuZHB0ciwgKm9wYXJnOwogICAgIGNvbnN0IGNoYXIgKnRvazsKICAgICBp
bnQgaTsKQEAgLTQ5MTAsNiArNDkyOSw3IEBAIGludCBtYWluX25ldHdvcmthdHRhY2goaW50IGFy
Z2MsIGNoYXIgKioKICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04oIm1vZGVsIiwgKmFy
Z3YsIG9wYXJnKSkgewogICAgICAgICAgICAgcmVwbGFjZV9zdHJpbmcoJm5pYy5tb2RlbCwgb3Bh
cmcpOwogICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigicmF0ZSIsICphcmd2LCBvcGFy
ZykpIHsKKyAgICAgICAgICAgIHBhcnNlX3ZpZl9yYXRlKCZjb25maWcsIG9wYXJnLCAmbmljKTsK
ICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04oImFjY2VsIiwgKmFyZ3YsIG9wYXJnKSkg
ewogICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ1bnJlY29n
bml6ZWQgYXJndW1lbnQgYCVzJ1xuIiwgKmFyZ3YpOwpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 17 02:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 02:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxmm-0007WX-SL; Tue, 17 Apr 2012 02:04:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1SJxml-0007WP-Pl
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 02:04:52 +0000
Received: from [85.158.139.83:45057] by server-9.bemta-5.messagelabs.com id
	D5/BC-09826-2CFCC8F4; Tue, 17 Apr 2012 02:04:50 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334628288!19495151!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15448 invoked from network); 17 Apr 2012 02:04:50 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 02:04:50 -0000
Received: by iadj38 with SMTP id j38so10226487iad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Apr 2012 19:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dQI+6rVmFdP7Nvw5gqtfzC+PVYMPuDVN1QB6zW2gBRI=;
	b=pjB8Nywah3yLf6FTKVDwBucv9Cil4ifRZt52AqSpZqXVcakfcFRjPcfWgR+vKYlhjk
	8egiQDSYZLJrtfu+pRRzg36Z5TZbB0Ac2YfcWueDrCgQPsuFGxQ3/mRofVKKTjbWHrFm
	KTDlvEY3HyIE5fcGp3xMzi2ZMIMOMcZOO3ad+yQUYeyjvhEQdCiuqAQ/axIDp++xNRss
	G3WQ8gYfHll1EM8940w6McYqHlUojDTWgfhhg3o3UbQpe4oxRz8C4Oorq8DuoTJ1ctTj
	IWai3trdLCEwj4A//q7aSRDu8ZtLT5uZE+QuNRxHQuAx6XmWP9Y9CLgqyWtkrxjyuLtv
	40+w==
Received: by 10.50.191.200 with SMTP id ha8mr6771654igc.45.1334628288316;
	Mon, 16 Apr 2012 19:04:48 -0700 (PDT)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id en3sm30005892igc.2.2012.04.16.19.04.44
	(version=SSLv3 cipher=OTHER); Mon, 16 Apr 2012 19:04:45 -0700 (PDT)
Date: Mon, 16 Apr 2012 21:04:33 -0500
From: Jonathan Nieder <jrnieder@gmail.com>
To: Robert Scott <bugs@humanleg.org.uk>
Message-ID: <20120417020433.GA15848@burratino>
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<20110829041532.GA22087@elie.gateway.2wire.net>
	<20120415140628.GA4536@burratino>
	<201204161905.13260.bugs@humanleg.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204161905.13260.bugs@humanleg.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Robert Scott wrote:
> On Sunday 15 April 2012, Jonathan Nieder wrote:

>> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
>> it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
>> semantics in fixup_irqs()") will fix this.
>
> Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.

Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
same problem?  Can you get a log of the failure with
"no_console_suspend" appended to the kernel command line, for example
with a serial console or netconsole?

If someone has time to go through the steps in
"Documentation/power/basic-pm-debugging.txt", that would also be useful.

Thanks, and sorry to take so long to get to this.

Sincerely,
Jonathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 02:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 02:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJxmm-0007WX-SL; Tue, 17 Apr 2012 02:04:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1SJxml-0007WP-Pl
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 02:04:52 +0000
Received: from [85.158.139.83:45057] by server-9.bemta-5.messagelabs.com id
	D5/BC-09826-2CFCC8F4; Tue, 17 Apr 2012 02:04:50 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334628288!19495151!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15448 invoked from network); 17 Apr 2012 02:04:50 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 02:04:50 -0000
Received: by iadj38 with SMTP id j38so10226487iad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Apr 2012 19:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dQI+6rVmFdP7Nvw5gqtfzC+PVYMPuDVN1QB6zW2gBRI=;
	b=pjB8Nywah3yLf6FTKVDwBucv9Cil4ifRZt52AqSpZqXVcakfcFRjPcfWgR+vKYlhjk
	8egiQDSYZLJrtfu+pRRzg36Z5TZbB0Ac2YfcWueDrCgQPsuFGxQ3/mRofVKKTjbWHrFm
	KTDlvEY3HyIE5fcGp3xMzi2ZMIMOMcZOO3ad+yQUYeyjvhEQdCiuqAQ/axIDp++xNRss
	G3WQ8gYfHll1EM8940w6McYqHlUojDTWgfhhg3o3UbQpe4oxRz8C4Oorq8DuoTJ1ctTj
	IWai3trdLCEwj4A//q7aSRDu8ZtLT5uZE+QuNRxHQuAx6XmWP9Y9CLgqyWtkrxjyuLtv
	40+w==
Received: by 10.50.191.200 with SMTP id ha8mr6771654igc.45.1334628288316;
	Mon, 16 Apr 2012 19:04:48 -0700 (PDT)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id en3sm30005892igc.2.2012.04.16.19.04.44
	(version=SSLv3 cipher=OTHER); Mon, 16 Apr 2012 19:04:45 -0700 (PDT)
Date: Mon, 16 Apr 2012 21:04:33 -0500
From: Jonathan Nieder <jrnieder@gmail.com>
To: Robert Scott <bugs@humanleg.org.uk>
Message-ID: <20120417020433.GA15848@burratino>
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<20110829041532.GA22087@elie.gateway.2wire.net>
	<20120415140628.GA4536@burratino>
	<201204161905.13260.bugs@humanleg.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204161905.13260.bugs@humanleg.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Robert Scott wrote:
> On Sunday 15 April 2012, Jonathan Nieder wrote:

>> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
>> it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
>> semantics in fixup_irqs()") will fix this.
>
> Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.

Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
same problem?  Can you get a log of the failure with
"no_console_suspend" appended to the kernel command line, for example
with a serial console or netconsole?

If someone has time to go through the steps in
"Documentation/power/basic-pm-debugging.txt", that would also be useful.

Thanks, and sorry to take so long to get to this.

Sincerely,
Jonathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 03:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 03:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJz3g-0008J5-TX; Tue, 17 Apr 2012 03:26:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SJz3g-0008J0-F8
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 03:26:24 +0000
Received: from [85.158.143.99:51665] by server-1.bemta-4.messagelabs.com id
	30/2D-20925-FD2EC8F4; Tue, 17 Apr 2012 03:26:23 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334633182!23383933!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0OTA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 17 Apr 2012 03:26:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 03:26:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 16 Apr 2012 20:26:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="131727049"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 16 Apr 2012 20:26:21 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 16 Apr 2012 20:26:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.125]) with mapi id
	14.01.0355.002; Tue, 17 Apr 2012 11:26:19 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+Q==
Date: Tue, 17 Apr 2012 03:26:18 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D84A1@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi keir

I noticed that the changeset 15289 introuduced locking to platform timers. And you mentioned that it only handy for correctness. Are there some potential issues which is fixed by this patch? If not, I wonder why we need those locks? I think it should be OS's responsibly to guarantee the access sequentially, not hypervisor. Am I right? 
I don't know whether all those locks are necessary, but at least the lock for vhpet, especially the reading lock, is not required.

best regards
yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 03:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 03:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJz3g-0008J5-TX; Tue, 17 Apr 2012 03:26:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SJz3g-0008J0-F8
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 03:26:24 +0000
Received: from [85.158.143.99:51665] by server-1.bemta-4.messagelabs.com id
	30/2D-20925-FD2EC8F4; Tue, 17 Apr 2012 03:26:23 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334633182!23383933!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0OTA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 17 Apr 2012 03:26:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 03:26:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 16 Apr 2012 20:26:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="131727049"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 16 Apr 2012 20:26:21 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 16 Apr 2012 20:26:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.125]) with mapi id
	14.01.0355.002; Tue, 17 Apr 2012 11:26:19 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+Q==
Date: Tue, 17 Apr 2012 03:26:18 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D84A1@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi keir

I noticed that the changeset 15289 introuduced locking to platform timers. And you mentioned that it only handy for correctness. Are there some potential issues which is fixed by this patch? If not, I wonder why we need those locks? I think it should be OS's responsibly to guarantee the access sequentially, not hypervisor. Am I right? 
I don't know whether all those locks are necessary, but at least the lock for vhpet, especially the reading lock, is not required.

best regards
yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 03:49:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 03:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJzPn-0008WI-Tv; Tue, 17 Apr 2012 03:49:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SJzPm-0008WD-N3
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 03:49:14 +0000
Received: from [193.109.254.147:51848] by server-9.bemta-14.messagelabs.com id
	DA/F8-05787-938EC8F4; Tue, 17 Apr 2012 03:49:13 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334634550!1788384!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzQyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23261 invoked from network); 17 Apr 2012 03:49:13 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 03:49:13 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Apr 2012 09:19:09 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 09:19:07 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H3n6kU4366386
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 09:19:06 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3H9IrgT001772
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 19:18:54 +1000
Received: from [9.79.218.201] ([9.79.218.201])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3H9Ipbx001716; Tue, 17 Apr 2012 19:18:51 +1000
Message-ID: <4F8CE82D.80503@linux.vnet.ibm.com>
Date: Tue, 17 Apr 2012 09:19:01 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
	<20120412000629.GA32051@amt.cnet>
In-Reply-To: <20120412000629.GA32051@amt.cnet>
x-cbid: 12041703-9574-0000-0000-00000239F97F
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Sorry for late reply,
was on vacation for a week (without IMAP access :( )

On 04/12/2012 05:36 AM, Marcelo Tosatti wrote:
> On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
[snip]
>> @@ -1567,6 +1568,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>>   		prepare_to_wait(&vcpu->wq,&wait, TASK_INTERRUPTIBLE);
>>
>>   		if (kvm_arch_vcpu_runnable(vcpu)) {
>> +			vcpu->pv_unhalted = 0;
>> +			/* preventing reordering should be enough here */
>> +			barrier();
>
> Is it always OK to erase the notification, even in case an unrelated
> event such as interrupt was the source of wakeup?


Erasing notification is not good, But I think in this case,

kvm_make_request(KVM_REQ_UNHALT, vcpu);

below this would take care of the rest.

>
> It would be easier to verify that notifications are not lost with atomic
>
> test_and_clear(pv_unhalted).

true, I 'll verify that (with pv_unhalt as atomic variable). my heart
says  current code is just fine, since we are about to unblock.

>
> Also x86 specific code should remain in arch/x86/kvm/
>

I agree. 'll have clear function in arch/x86/kvm and add stub to rest
of the archs

>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 03:49:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 03:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SJzPn-0008WI-Tv; Tue, 17 Apr 2012 03:49:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SJzPm-0008WD-N3
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 03:49:14 +0000
Received: from [193.109.254.147:51848] by server-9.bemta-14.messagelabs.com id
	DA/F8-05787-938EC8F4; Tue, 17 Apr 2012 03:49:13 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334634550!1788384!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzQyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23261 invoked from network); 17 Apr 2012 03:49:13 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 03:49:13 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Apr 2012 09:19:09 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 09:19:07 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H3n6kU4366386
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 09:19:06 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3H9IrgT001772
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 19:18:54 +1000
Received: from [9.79.218.201] ([9.79.218.201])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3H9Ipbx001716; Tue, 17 Apr 2012 19:18:51 +1000
Message-ID: <4F8CE82D.80503@linux.vnet.ibm.com>
Date: Tue, 17 Apr 2012 09:19:01 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
	<20120412000629.GA32051@amt.cnet>
In-Reply-To: <20120412000629.GA32051@amt.cnet>
x-cbid: 12041703-9574-0000-0000-00000239F97F
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Sorry for late reply,
was on vacation for a week (without IMAP access :( )

On 04/12/2012 05:36 AM, Marcelo Tosatti wrote:
> On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
[snip]
>> @@ -1567,6 +1568,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>>   		prepare_to_wait(&vcpu->wq,&wait, TASK_INTERRUPTIBLE);
>>
>>   		if (kvm_arch_vcpu_runnable(vcpu)) {
>> +			vcpu->pv_unhalted = 0;
>> +			/* preventing reordering should be enough here */
>> +			barrier();
>
> Is it always OK to erase the notification, even in case an unrelated
> event such as interrupt was the source of wakeup?


Erasing notification is not good, But I think in this case,

kvm_make_request(KVM_REQ_UNHALT, vcpu);

below this would take care of the rest.

>
> It would be easier to verify that notifications are not lost with atomic
>
> test_and_clear(pv_unhalted).

true, I 'll verify that (with pv_unhalt as atomic variable). my heart
says  current code is just fine, since we are about to unblock.

>
> Also x86 specific code should remain in arch/x86/kvm/
>

I agree. 'll have clear function in arch/x86/kvm and add stub to rest
of the archs

>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 04:33:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 04:33:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK06Q-0000On-HL; Tue, 17 Apr 2012 04:33:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK06P-0000Oi-0i
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 04:33:17 +0000
Received: from [193.109.254.147:46738] by server-7.bemta-14.messagelabs.com id
	8C/6E-01627-C82FC8F4; Tue, 17 Apr 2012 04:33:16 +0000
X-Env-Sender: skibrianski@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334637194!4897970!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17387 invoked from network); 17 Apr 2012 04:33:15 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 04:33:15 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK06M-00051W-0Z
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:33:14 -0700
Date: Mon, 16 Apr 2012 21:33:14 -0700 (PDT)
From: Brian Szymanski <skibrianski@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334637194009-5645610.post@n5.nabble.com>
In-Reply-To: <1332160201177-5576960.post@n5.nabble.com>
References: <4F468B96.5030703@cantab.net>
	<CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
	<CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
	<jjj8bj$r19$1@dough.gmane.org>
	<20120315183330.GB3034@phenom.dumpdata.com>
	<4F623AD5.3020400@citrix.com> <4F624C02.3000004@gmail.com>
	<4F6713EC.7070804@citrix.com> <4F6725C9.9000304@gmail.com>
	<1332160201177-5576960.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm having this problem in a vanillla debian squeeze install, too:

ski@xen:~$ dpkg -l | grep -e linux-image -e hypervisor | grep xen
ii  linux-image-2.6.32-5-xen-amd64          2.6.32-41squeeze2           
Linux 2.6.32 for 64-bit PCs, Xen dom0 support
ii  linux-image-xen-amd64                   2.6.32+29                   
Linux for 64-bit PCs (meta-package), Xen dom0 support
ii  xen-hypervisor-4.0-amd64                4.0.1-4                      The
Xen Hypervisor on AMD64

ski@xen:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          4373       2478       1895          0         16         79
-/+ buffers/cache:       2382       1991
Swap:         3814          0       3814

ski@xen:~$ sudo xm info
host                   : xen.allafrica.com
release                : 2.6.32-5-xen-amd64
version                : #1 SMP Thu Mar 22 21:14:26 UTC 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2493
hw_caps                :
bfebfbff:20100800:00000000:00000940:000ce3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 32762
free_memory            : 29280
node_to_cpu            : node0:0-7
node_to_memory         : node0:29280
node_to_dma32_mem      : node0:1974
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder com1=57600,8n1,0x2f8,3 console=com1,vga
loglvl=all guest_loglvl=all dom0_mem=max:6144M
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) 
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Thu Jun  9 18:38:03 UTC 2011
xend_config_format     : 4

Cheers.


--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-not-seeing-all-of-the-assigned-memory-tp5506459p5645610.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 04:33:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 04:33:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK06Q-0000On-HL; Tue, 17 Apr 2012 04:33:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK06P-0000Oi-0i
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 04:33:17 +0000
Received: from [193.109.254.147:46738] by server-7.bemta-14.messagelabs.com id
	8C/6E-01627-C82FC8F4; Tue, 17 Apr 2012 04:33:16 +0000
X-Env-Sender: skibrianski@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334637194!4897970!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17387 invoked from network); 17 Apr 2012 04:33:15 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 04:33:15 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK06M-00051W-0Z
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:33:14 -0700
Date: Mon, 16 Apr 2012 21:33:14 -0700 (PDT)
From: Brian Szymanski <skibrianski@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334637194009-5645610.post@n5.nabble.com>
In-Reply-To: <1332160201177-5576960.post@n5.nabble.com>
References: <4F468B96.5030703@cantab.net>
	<CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
	<CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
	<jjj8bj$r19$1@dough.gmane.org>
	<20120315183330.GB3034@phenom.dumpdata.com>
	<4F623AD5.3020400@citrix.com> <4F624C02.3000004@gmail.com>
	<4F6713EC.7070804@citrix.com> <4F6725C9.9000304@gmail.com>
	<1332160201177-5576960.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm having this problem in a vanillla debian squeeze install, too:

ski@xen:~$ dpkg -l | grep -e linux-image -e hypervisor | grep xen
ii  linux-image-2.6.32-5-xen-amd64          2.6.32-41squeeze2           
Linux 2.6.32 for 64-bit PCs, Xen dom0 support
ii  linux-image-xen-amd64                   2.6.32+29                   
Linux for 64-bit PCs (meta-package), Xen dom0 support
ii  xen-hypervisor-4.0-amd64                4.0.1-4                      The
Xen Hypervisor on AMD64

ski@xen:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          4373       2478       1895          0         16         79
-/+ buffers/cache:       2382       1991
Swap:         3814          0       3814

ski@xen:~$ sudo xm info
host                   : xen.allafrica.com
release                : 2.6.32-5-xen-amd64
version                : #1 SMP Thu Mar 22 21:14:26 UTC 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2493
hw_caps                :
bfebfbff:20100800:00000000:00000940:000ce3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 32762
free_memory            : 29280
node_to_cpu            : node0:0-7
node_to_memory         : node0:29280
node_to_dma32_mem      : node0:1974
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder com1=57600,8n1,0x2f8,3 console=com1,vga
loglvl=all guest_loglvl=all dom0_mem=max:6144M
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) 
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Thu Jun  9 18:38:03 UTC 2011
xend_config_format     : 4

Cheers.


--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-not-seeing-all-of-the-assigned-memory-tp5506459p5645610.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 04:47:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 04:47:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK0JM-0000ab-RY; Tue, 17 Apr 2012 04:46:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK0JK-0000aW-Ko
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 04:46:38 +0000
Received: from [85.158.143.35:54167] by server-3.bemta-4.messagelabs.com id
	07/26-05853-DA5FC8F4; Tue, 17 Apr 2012 04:46:37 +0000
X-Env-Sender: skibrianski@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334637995!16422291!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10148 invoked from network); 17 Apr 2012 04:46:37 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 04:46:37 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK0JH-0005fM-0L
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:46:35 -0700
Date: Mon, 16 Apr 2012 21:46:35 -0700 (PDT)
From: Brian Szymanski <skibrianski@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334637995004-5645620.post@n5.nabble.com>
In-Reply-To: <1334637194009-5645610.post@n5.nabble.com>
References: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
	<CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
	<jjj8bj$r19$1@dough.gmane.org>
	<20120315183330.GB3034@phenom.dumpdata.com>
	<4F623AD5.3020400@citrix.com> <4F624C02.3000004@gmail.com>
	<4F6713EC.7070804@citrix.com> <4F6725C9.9000304@gmail.com>
	<1332160201177-5576960.post@n5.nabble.com>
	<1334637194009-5645610.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also, if I xm mem-set Domain-0 6144, xm list is updated to the new value, but
xm top continues to show the old (even after restarting it).




--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-not-seeing-all-of-the-assigned-memory-tp5506459p5645620.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 04:47:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 04:47:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK0JM-0000ab-RY; Tue, 17 Apr 2012 04:46:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK0JK-0000aW-Ko
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 04:46:38 +0000
Received: from [85.158.143.35:54167] by server-3.bemta-4.messagelabs.com id
	07/26-05853-DA5FC8F4; Tue, 17 Apr 2012 04:46:37 +0000
X-Env-Sender: skibrianski@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334637995!16422291!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10148 invoked from network); 17 Apr 2012 04:46:37 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 04:46:37 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <skibrianski@gmail.com>) id 1SK0JH-0005fM-0L
	for xen-devel@lists.xensource.com; Mon, 16 Apr 2012 21:46:35 -0700
Date: Mon, 16 Apr 2012 21:46:35 -0700 (PDT)
From: Brian Szymanski <skibrianski@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334637995004-5645620.post@n5.nabble.com>
In-Reply-To: <1334637194009-5645610.post@n5.nabble.com>
References: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
	<CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
	<jjj8bj$r19$1@dough.gmane.org>
	<20120315183330.GB3034@phenom.dumpdata.com>
	<4F623AD5.3020400@citrix.com> <4F624C02.3000004@gmail.com>
	<4F6713EC.7070804@citrix.com> <4F6725C9.9000304@gmail.com>
	<1332160201177-5576960.post@n5.nabble.com>
	<1334637194009-5645610.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also, if I xm mem-set Domain-0 6144, xm list is updated to the new value, but
xm top continues to show the old (even after restarting it).




--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-not-seeing-all-of-the-assigned-memory-tp5506459p5645620.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 04:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 04:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK0TZ-0000k5-US; Tue, 17 Apr 2012 04:57:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SK0TY-0000jx-V7
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 04:57:13 +0000
Received: from [85.158.138.51:10451] by server-4.bemta-3.messagelabs.com id
	23/10-15341-828FC8F4; Tue, 17 Apr 2012 04:57:12 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334638630!22431928!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28881 invoked from network); 17 Apr 2012 04:57:11 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 04:57:11 -0000
Received: by qabg27 with SMTP id g27so156801qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Apr 2012 21:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=UrLbzNC+drIXPfw4LiSgw0yoQQaQR7N1aWDmyxnCE0Y=;
	b=fan5WZ0C2QirZwH+WMgjsqxwi26QbiAg8tJdbgbrMKJI5EkVWkW3Y1Ep7eKwdFrQJd
	UZkVNGww1rHOTdcZJyEFb/1EA+ry3h1480gHtEd5OUN4F2szKlly2G8q/JUjrlIUZXm0
	OnFWrWrFbRPhRLHmTefQonNcqTgAbUf7C7/S3r7RZIvAFKL8O0y4cuWeFCEsKjv5O/sD
	E5PPc4m9FNnppZFmwCjqY2yWuTxy6hY9XhLfgpk+dgU2ApR1qGY/4snXHlT91f9L7CuT
	uv6ZQt+CTxuHsNHVpyGslmanQrdDABSegmYs/qOi6JxUom6yycqBrYtdb6FNqvux+NnV
	FuhA==
MIME-Version: 1.0
Received: by 10.224.199.202 with SMTP id et10mr18961727qab.60.1334638629950;
	Mon, 16 Apr 2012 21:57:09 -0700 (PDT)
Received: by 10.229.120.132 with HTTP; Mon, 16 Apr 2012 21:57:09 -0700 (PDT)
Date: Mon, 16 Apr 2012 21:57:09 -0700
Message-ID: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
of pages (in the GB range) from a guest in to Dom0 using
xc_map_foreign_bulk() I am hitting a segfault.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
    h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
    err=0x7ffff67f4010, num=<optimized out>)
    at /usr/include/x86_64-linux-gnu/bits/string3.h:52
52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) bt
#0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
    h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
    err=0x7ffff67f4010, num=<optimized out>)
    at /usr/include/x86_64-linux-gnu/bits/string3.h:52
#1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
    dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
    err=<optimized out>, num=<optimized out>) at xc_foreign_memory.c:79

This was working for me with Xen 4.1.2. On comparing
linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
stack with the call. If I replace the alloca() with malloc() the call
goes through. What is the way around this? Should I be using
xc_map_foreign_batch() instead, which I think is deprecated? Please
advice...

Thanks,
AP

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 04:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 04:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK0TZ-0000k5-US; Tue, 17 Apr 2012 04:57:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SK0TY-0000jx-V7
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 04:57:13 +0000
Received: from [85.158.138.51:10451] by server-4.bemta-3.messagelabs.com id
	23/10-15341-828FC8F4; Tue, 17 Apr 2012 04:57:12 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334638630!22431928!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28881 invoked from network); 17 Apr 2012 04:57:11 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 04:57:11 -0000
Received: by qabg27 with SMTP id g27so156801qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Apr 2012 21:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=UrLbzNC+drIXPfw4LiSgw0yoQQaQR7N1aWDmyxnCE0Y=;
	b=fan5WZ0C2QirZwH+WMgjsqxwi26QbiAg8tJdbgbrMKJI5EkVWkW3Y1Ep7eKwdFrQJd
	UZkVNGww1rHOTdcZJyEFb/1EA+ry3h1480gHtEd5OUN4F2szKlly2G8q/JUjrlIUZXm0
	OnFWrWrFbRPhRLHmTefQonNcqTgAbUf7C7/S3r7RZIvAFKL8O0y4cuWeFCEsKjv5O/sD
	E5PPc4m9FNnppZFmwCjqY2yWuTxy6hY9XhLfgpk+dgU2ApR1qGY/4snXHlT91f9L7CuT
	uv6ZQt+CTxuHsNHVpyGslmanQrdDABSegmYs/qOi6JxUom6yycqBrYtdb6FNqvux+NnV
	FuhA==
MIME-Version: 1.0
Received: by 10.224.199.202 with SMTP id et10mr18961727qab.60.1334638629950;
	Mon, 16 Apr 2012 21:57:09 -0700 (PDT)
Received: by 10.229.120.132 with HTTP; Mon, 16 Apr 2012 21:57:09 -0700 (PDT)
Date: Mon, 16 Apr 2012 21:57:09 -0700
Message-ID: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
of pages (in the GB range) from a guest in to Dom0 using
xc_map_foreign_bulk() I am hitting a segfault.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
    h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
    err=0x7ffff67f4010, num=<optimized out>)
    at /usr/include/x86_64-linux-gnu/bits/string3.h:52
52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) bt
#0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
    h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
    err=0x7ffff67f4010, num=<optimized out>)
    at /usr/include/x86_64-linux-gnu/bits/string3.h:52
#1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
    dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
    err=<optimized out>, num=<optimized out>) at xc_foreign_memory.c:79

This was working for me with Xen 4.1.2. On comparing
linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
stack with the call. If I replace the alloca() with malloc() the call
goes through. What is the way around this? Should I be using
xc_map_foreign_batch() instead, which I think is deprecated? Please
advice...

Thanks,
AP

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 06:11:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 06:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK1dM-0001LJ-Pb; Tue, 17 Apr 2012 06:11:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SK1dK-0001LE-Tg
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 06:11:23 +0000
Received: from [85.158.143.35:41554] by server-3.bemta-4.messagelabs.com id
	EC/09-05853-A890D8F4; Tue, 17 Apr 2012 06:11:22 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334643081!5144460!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEzNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29331 invoked from network); 17 Apr 2012 06:11:21 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 06:11:21 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=i1yxoluJKSSP+E70rNtzowLL2/BCEaemCQYhtltbSyyl+tHSnrYLQBNh
	kMqoQA0Q2d7WbXq+ACbOxM1515zzLJQpC5witTWiL+xlPvFJNdHPfwr4V
	XPmrrJAfPR+u4J2btxk0Q16OmBK4siBtxcb4oqgC8cgRD09leXK7SPMLG
	P9VkZC+03ulCSiwo3G57lmZKFy15yM/RnxMgO/+F91ElnNIvP/1im6eu+
	SG7bv8Le4m7Q/3kYUl1rVwgdS/kwg;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1334643081; x=1366179081;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=E490qf13uzPaO9uroh5Oe5F4cCJ8co7k7iSYlxLC5zM=;
	b=pV5dRyy5cvpJYEqJfyKorpivNkyrBNO5k9CacFCIgGHM0U2rHqBYuWUP
	yFnMt6UBzq3vo9qr7hEDYmOMHVFJb0Cawd+J3/TKUC8I4Ks9IfYkaQJG/
	mYb6bZS6QNTA06CUCp86MRZF0RqHOMcNsMMYC714qp+ByI6kxSwnzXfg9
	eqWm4hQcNoe/980djRQiEK0Stw8R8LZ/EH2nW1z+R1dDB9M4/J19RU//Q
	hgqdk/sujKA+wxcbgP+PiNC7CZpLQ;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,432,1330902000"; d="scan'208";a="107823723"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 17 Apr 2012 08:11:20 +0200
X-IronPort-AV: E=Sophos;i="4.75,432,1330902000"; d="scan'208";a="132779801"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Apr 2012 08:11:20 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 54A7B569ADF;
	Tue, 17 Apr 2012 08:11:20 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 08:11:19 +0200
Message-ID: <58047712.uBa5W5J32N@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <20120416173936.GD18314@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
	<20120416173936.GD18314@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>, wei.huang2@amd.com,
	marcus.granado@citrix.com, wei.wang2@amd.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Montag 16 April 2012, 13:39:36 schrieb Konrad Rzeszutek Wilk:
> On Mon, Apr 16, 2012 at 04:16:07PM +0800, Lin Ming wrote:
> > On Wed, Apr 11, 2012 at 10:30 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > 
> > [....]
> > 
> > >> That isn't actually true. If you run it, you will see it working
> > >> in the guest - it just that it does not use the performence counters
> > >> but instead uses the timer to sample data.
> > >
> > > Right, I mean "hardware event" does not work.
> > >
> > > Hardware event, for example, perf top -e cycles, does not work.
> > 
> > Just found that vpmu is disabled by default.
> > You need to pass xen boot parameter "vpmu" to make hardware event work.
> 
> Oh, I wonder why it was disabled by default? Wei, would you know
> by any chance?

This had to do with a problem in the intel nehalem processors which could cause
endless interrupt loops in the hypervisor if a hvm guest uses the performance
counters so Keir proposed to add the vpmu boot flag.

http://lists.xen.org/archives/html/xen-devel/2009-10/msg01460.html
and
http://lists.xen.org/archives/html/xen-devel/2009-11/msg00088.html

Dietmar

> 
> > 
> > > Software event, for example, perf top -e cpu-clock, works.
> > 
> > So both hardware and software event work in DomU.
> > Great!
> 
> Excellent!
> > 
> > >
> > >>
> > >> > Run "perf top", but no data was collected.
> > >>
> > >> Hm, I am able to collect data using Fedora Core 16 PV guest.
> > >> For dom0 or domU? For dom0 there is a bug somewhere where
> > >
> > > For domU HVM guest.
> > > I have problem to run domU PV guest. Still looking at it.
> > >
> > >> the machine crashes after 30 seconds or so - hadn't actually
> > >> gotten to the bottom of it. There was an email thread:
> > >> https://lkml.org/lkml/2012/2/12/74 about this.
> > >>
> > >> Patches are most welcome!
> > 
> > Here are the patches.
> > https://lkml.org/lkml/2012/4/15/12
> 
> Let me play with them a bit. At first glance they look ok - but I recall
> Peter Z saying something about not implementing the IRQ WORKER, but I can't
> recall the reasons.
> > 
> > Regards,
> > Lin Ming
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 06:11:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 06:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK1dM-0001LJ-Pb; Tue, 17 Apr 2012 06:11:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SK1dK-0001LE-Tg
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 06:11:23 +0000
Received: from [85.158.143.35:41554] by server-3.bemta-4.messagelabs.com id
	EC/09-05853-A890D8F4; Tue, 17 Apr 2012 06:11:22 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334643081!5144460!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEzNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29331 invoked from network); 17 Apr 2012 06:11:21 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 06:11:21 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=i1yxoluJKSSP+E70rNtzowLL2/BCEaemCQYhtltbSyyl+tHSnrYLQBNh
	kMqoQA0Q2d7WbXq+ACbOxM1515zzLJQpC5witTWiL+xlPvFJNdHPfwr4V
	XPmrrJAfPR+u4J2btxk0Q16OmBK4siBtxcb4oqgC8cgRD09leXK7SPMLG
	P9VkZC+03ulCSiwo3G57lmZKFy15yM/RnxMgO/+F91ElnNIvP/1im6eu+
	SG7bv8Le4m7Q/3kYUl1rVwgdS/kwg;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1334643081; x=1366179081;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=E490qf13uzPaO9uroh5Oe5F4cCJ8co7k7iSYlxLC5zM=;
	b=pV5dRyy5cvpJYEqJfyKorpivNkyrBNO5k9CacFCIgGHM0U2rHqBYuWUP
	yFnMt6UBzq3vo9qr7hEDYmOMHVFJb0Cawd+J3/TKUC8I4Ks9IfYkaQJG/
	mYb6bZS6QNTA06CUCp86MRZF0RqHOMcNsMMYC714qp+ByI6kxSwnzXfg9
	eqWm4hQcNoe/980djRQiEK0Stw8R8LZ/EH2nW1z+R1dDB9M4/J19RU//Q
	hgqdk/sujKA+wxcbgP+PiNC7CZpLQ;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,432,1330902000"; d="scan'208";a="107823723"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 17 Apr 2012 08:11:20 +0200
X-IronPort-AV: E=Sophos;i="4.75,432,1330902000"; d="scan'208";a="132779801"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Apr 2012 08:11:20 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 54A7B569ADF;
	Tue, 17 Apr 2012 08:11:20 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 08:11:19 +0200
Message-ID: <58047712.uBa5W5J32N@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <20120416173936.GD18314@phenom.dumpdata.com>
References: <CAF1ivSZW0B0t324=62MhCcEy-h3C26k6Jm+Ek1GcbHArNPX4Rw@mail.gmail.com>
	<CAF1ivSa6fOdzt8pdRGYQhJNEEBCjLoGU5gdSt=rqQ-2EG6Op4Q@mail.gmail.com>
	<20120416173936.GD18314@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>, wei.huang2@amd.com,
	marcus.granado@citrix.com, wei.wang2@amd.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Virtualization of the CPU Performance Monitoring
	Unit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Montag 16 April 2012, 13:39:36 schrieb Konrad Rzeszutek Wilk:
> On Mon, Apr 16, 2012 at 04:16:07PM +0800, Lin Ming wrote:
> > On Wed, Apr 11, 2012 at 10:30 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > 
> > [....]
> > 
> > >> That isn't actually true. If you run it, you will see it working
> > >> in the guest - it just that it does not use the performence counters
> > >> but instead uses the timer to sample data.
> > >
> > > Right, I mean "hardware event" does not work.
> > >
> > > Hardware event, for example, perf top -e cycles, does not work.
> > 
> > Just found that vpmu is disabled by default.
> > You need to pass xen boot parameter "vpmu" to make hardware event work.
> 
> Oh, I wonder why it was disabled by default? Wei, would you know
> by any chance?

This had to do with a problem in the intel nehalem processors which could cause
endless interrupt loops in the hypervisor if a hvm guest uses the performance
counters so Keir proposed to add the vpmu boot flag.

http://lists.xen.org/archives/html/xen-devel/2009-10/msg01460.html
and
http://lists.xen.org/archives/html/xen-devel/2009-11/msg00088.html

Dietmar

> 
> > 
> > > Software event, for example, perf top -e cpu-clock, works.
> > 
> > So both hardware and software event work in DomU.
> > Great!
> 
> Excellent!
> > 
> > >
> > >>
> > >> > Run "perf top", but no data was collected.
> > >>
> > >> Hm, I am able to collect data using Fedora Core 16 PV guest.
> > >> For dom0 or domU? For dom0 there is a bug somewhere where
> > >
> > > For domU HVM guest.
> > > I have problem to run domU PV guest. Still looking at it.
> > >
> > >> the machine crashes after 30 seconds or so - hadn't actually
> > >> gotten to the bottom of it. There was an email thread:
> > >> https://lkml.org/lkml/2012/2/12/74 about this.
> > >>
> > >> Patches are most welcome!
> > 
> > Here are the patches.
> > https://lkml.org/lkml/2012/4/15/12
> 
> Let me play with them a bit. At first glance they look ok - but I recall
> Peter Z saying something about not implementing the IRQ WORKER, but I can't
> recall the reasons.
> > 
> > Regards,
> > Lin Ming
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:08:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2WF-00025p-JJ; Tue, 17 Apr 2012 07:08:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SK2WD-00025j-8d
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:08:05 +0000
Received: from [193.109.254.147:5260] by server-2.bemta-14.messagelabs.com id
	20/9A-19409-4D61D8F4; Tue, 17 Apr 2012 07:08:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334646433!4889919!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNDM5MTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30768 invoked from network); 17 Apr 2012 07:07:47 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 07:07:47 -0000
Received: from /spool/local
	by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Apr 2012 06:49:26 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 06:49:22 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H70PjI1048742
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 17:00:28 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3H76vgh028450
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 17:06:58 +1000
Received: from [9.124.158.200] (codeblue.in.ibm.com [9.124.158.200])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3H76riJ028264; Tue, 17 Apr 2012 17:06:54 +1000
Message-ID: <4F8D168B.7090806@linux.vnet.ibm.com>
Date: Tue, 17 Apr 2012 12:36:51 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
	<20120412000629.GA32051@amt.cnet> <20120412002909.GD32051@amt.cnet>
In-Reply-To: <20120412002909.GD32051@amt.cnet>
x-cbid: 12041620-5490-0000-0000-00000129BBF6
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/2012 05:59 AM, Marcelo Tosatti wrote:
> On Wed, Apr 11, 2012 at 09:06:29PM -0300, Marcelo Tosatti wrote:
>> On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
>>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>>
[...]

		barrier();
>>
>> Is it always OK to erase the notification, even in case an unrelated
>> event such as interrupt was the source of wakeup?
>
> Note i am only asking whether it is OK to lose a notification, not
> requesting a change to atomic test-and-clear.

Yes.. got your point.
IMO, this is the only (safe) place where it can clear
kicked(pv_unhalted) flag. Since it is going to be runnable.

and you are also right in having concern on unwanted clear of flag
since that would result in vcpu /vm hangs eventually.

Hope I did not miss anything.

>
> It would be nice to have a comment explaining it.
>

Sure will do that

>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:08:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2WF-00025p-JJ; Tue, 17 Apr 2012 07:08:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SK2WD-00025j-8d
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:08:05 +0000
Received: from [193.109.254.147:5260] by server-2.bemta-14.messagelabs.com id
	20/9A-19409-4D61D8F4; Tue, 17 Apr 2012 07:08:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334646433!4889919!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNDM5MTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30768 invoked from network); 17 Apr 2012 07:07:47 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 07:07:47 -0000
Received: from /spool/local
	by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Apr 2012 06:49:26 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 06:49:22 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H70PjI1048742
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 17:00:28 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3H76vgh028450
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 17:06:58 +1000
Received: from [9.124.158.200] (codeblue.in.ibm.com [9.124.158.200])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3H76riJ028264; Tue, 17 Apr 2012 17:06:54 +1000
Message-ID: <4F8D168B.7090806@linux.vnet.ibm.com>
Date: Tue, 17 Apr 2012 12:36:51 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080701.14568.97779.sendpatchset@codeblue>
	<20120412000629.GA32051@amt.cnet> <20120412002909.GD32051@amt.cnet>
In-Reply-To: <20120412002909.GD32051@amt.cnet>
x-cbid: 12041620-5490-0000-0000-00000129BBF6
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 2/6] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/2012 05:59 AM, Marcelo Tosatti wrote:
> On Wed, Apr 11, 2012 at 09:06:29PM -0300, Marcelo Tosatti wrote:
>> On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
>>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>>
[...]

		barrier();
>>
>> Is it always OK to erase the notification, even in case an unrelated
>> event such as interrupt was the source of wakeup?
>
> Note i am only asking whether it is OK to lose a notification, not
> requesting a change to atomic test-and-clear.

Yes.. got your point.
IMO, this is the only (safe) place where it can clear
kicked(pv_unhalted) flag. Since it is going to be runnable.

and you are also right in having concern on unwanted clear of flag
since that would result in vcpu /vm hangs eventually.

Hope I did not miss anything.

>
> It would be nice to have a comment explaining it.
>

Sure will do that

>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:18:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2fQ-0002M0-Kt; Tue, 17 Apr 2012 07:17:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SK2fP-0002Lu-FT
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:17:35 +0000
Received: from [85.158.143.99:63367] by server-3.bemta-4.messagelabs.com id
	99/72-05853-E091D8F4; Tue, 17 Apr 2012 07:17:34 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334647046!20571643!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzQyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31202 invoked from network); 17 Apr 2012 07:17:32 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 07:17:32 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Apr 2012 12:47:25 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 12:47:22 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H7HLuu4051056
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 12:47:22 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3HCl16F031391
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 18:17:02 +0530
Received: from [9.124.158.200] (codeblue.in.ibm.com [9.124.158.200])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3HCl16d031378; Tue, 17 Apr 2012 18:17:01 +0530
Message-ID: <4F8D18FD.2040801@linux.vnet.ibm.com>
Date: Tue, 17 Apr 2012 12:47:17 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080723.14568.23068.sendpatchset@codeblue>
	<20120412001517.GB32051@amt.cnet>
In-Reply-To: <20120412001517.GB32051@amt.cnet>
x-cbid: 12041707-9574-0000-0000-0000023A8AB9
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 3/6] kvm : Add unhalt msr to aid
	(live) migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/2012 05:45 AM, Marcelo Tosatti wrote:
> On Fri, Mar 23, 2012 at 01:37:26PM +0530, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>

[...]
>
> Unless there is a reason to use an MSR, should use a normal ioctl
> such as KVM_{GET,SET}_MP_STATE.
>
>

I agree with you. In the current implementation, since we are not doing
any communication between host/guest (on this flag), I too felt MSR is
an overkill for this.

IMO, patch like below should do the job, which I am planning to include
in next version of patch.
Let me know if you foresee any side-effects.

---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index aa44292..5c81a66 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu 
*vcpu,
  int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
  				    struct kvm_mp_state *mp_state)
  {
-	mp_state->mp_state = vcpu->arch.mp_state;
+	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED &&
+				vcpu->pv_unhalted)?
+				KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
  	return 0;
  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:18:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2fQ-0002M0-Kt; Tue, 17 Apr 2012 07:17:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SK2fP-0002Lu-FT
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:17:35 +0000
Received: from [85.158.143.99:63367] by server-3.bemta-4.messagelabs.com id
	99/72-05853-E091D8F4; Tue, 17 Apr 2012 07:17:34 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334647046!20571643!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzQyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31202 invoked from network); 17 Apr 2012 07:17:32 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 07:17:32 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Apr 2012 12:47:25 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 12:47:22 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H7HLuu4051056
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 12:47:22 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3HCl16F031391
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 18:17:02 +0530
Received: from [9.124.158.200] (codeblue.in.ibm.com [9.124.158.200])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3HCl16d031378; Tue, 17 Apr 2012 18:17:01 +0530
Message-ID: <4F8D18FD.2040801@linux.vnet.ibm.com>
Date: Tue, 17 Apr 2012 12:47:17 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120323080503.14568.43092.sendpatchset@codeblue>
	<20120323080723.14568.23068.sendpatchset@codeblue>
	<20120412001517.GB32051@amt.cnet>
In-Reply-To: <20120412001517.GB32051@amt.cnet>
x-cbid: 12041707-9574-0000-0000-0000023A8AB9
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-doc@vger.kernel.org,
	Alexander Graf <agraf@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V5 3/6] kvm : Add unhalt msr to aid
	(live) migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/2012 05:45 AM, Marcelo Tosatti wrote:
> On Fri, Mar 23, 2012 at 01:37:26PM +0530, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>

[...]
>
> Unless there is a reason to use an MSR, should use a normal ioctl
> such as KVM_{GET,SET}_MP_STATE.
>
>

I agree with you. In the current implementation, since we are not doing
any communication between host/guest (on this flag), I too felt MSR is
an overkill for this.

IMO, patch like below should do the job, which I am planning to include
in next version of patch.
Let me know if you foresee any side-effects.

---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index aa44292..5c81a66 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu 
*vcpu,
  int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
  				    struct kvm_mp_state *mp_state)
  {
-	mp_state->mp_state = vcpu->arch.mp_state;
+	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED &&
+				vcpu->pv_unhalted)?
+				KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
  	return 0;
  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2ow-0002WL-Mk; Tue, 17 Apr 2012 07:27:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK2ou-0002WG-RC
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 07:27:25 +0000
Received: from [85.158.143.35:53770] by server-1.bemta-4.messagelabs.com id
	E9/DF-20925-C5B1D8F4; Tue, 17 Apr 2012 07:27:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334647642!13573363!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32508 invoked from network); 17 Apr 2012 07:27:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 07:27:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 08:29:01 +0100
Message-Id: <4F8D3778020000780007E63A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 08:27:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C619C020000780007E34E@nat28.tlf.novell.com>
	<84023b26-a682-44b5-990e-1635da6949ff@default>
In-Reply-To: <84023b26-a682-44b5-990e-1635da6949ff@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim\(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.04.12 at 19:22, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> In upstream (and recent pv-ops) kernels, is there any need for there
> to be a difference between HVM and PV in the clocksource chosen?  The

Yes, because RDTSC interception for PV guests is slow (using #GP
and requiring instruction decode).

> pvclock algorithm was necessary for PV when non-TSC hardware clocks
> were privileged and the only non-privileged hardware clock (TSC)
> was badly broken in hardware and for migration/save/restore.
> With TSC now working and stable, and now that we are making changes
> in the upstream kernel that work for both PV and HVM, is it
> time to drop pvclock (at least as the default for PV)?
> 
> Certainly if an old (non-pv-ops) kernel is broken, something like
> David's patch might be an acceptable workaround.  I'm just arguing
> against perpetuating pvclock-as-the-only-xen-clock upstream.

Afaict, the only uniformly reliable clocksource for PV guests is the
virtual one which pvclock builds upon. Raw TSC is definitely not an
option on NUMA systems (and PV guests aren't aware of the
NUMAness of the underlying system).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2ow-0002WL-Mk; Tue, 17 Apr 2012 07:27:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK2ou-0002WG-RC
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 07:27:25 +0000
Received: from [85.158.143.35:53770] by server-1.bemta-4.messagelabs.com id
	E9/DF-20925-C5B1D8F4; Tue, 17 Apr 2012 07:27:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334647642!13573363!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32508 invoked from network); 17 Apr 2012 07:27:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 07:27:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 08:29:01 +0100
Message-Id: <4F8D3778020000780007E63A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 08:27:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C619C020000780007E34E@nat28.tlf.novell.com>
	<84023b26-a682-44b5-990e-1635da6949ff@default>
In-Reply-To: <84023b26-a682-44b5-990e-1635da6949ff@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim\(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.04.12 at 19:22, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> In upstream (and recent pv-ops) kernels, is there any need for there
> to be a difference between HVM and PV in the clocksource chosen?  The

Yes, because RDTSC interception for PV guests is slow (using #GP
and requiring instruction decode).

> pvclock algorithm was necessary for PV when non-TSC hardware clocks
> were privileged and the only non-privileged hardware clock (TSC)
> was badly broken in hardware and for migration/save/restore.
> With TSC now working and stable, and now that we are making changes
> in the upstream kernel that work for both PV and HVM, is it
> time to drop pvclock (at least as the default for PV)?
> 
> Certainly if an old (non-pv-ops) kernel is broken, something like
> David's patch might be an acceptable workaround.  I'm just arguing
> against perpetuating pvclock-as-the-only-xen-clock upstream.

Afaict, the only uniformly reliable clocksource for PV guests is the
virtual one which pvclock builds upon. Raw TSC is definitely not an
option on NUMA systems (and PV guests aren't aware of the
NUMAness of the underlying system).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:27:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2p5-0002Wz-F9; Tue, 17 Apr 2012 07:27:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK2p4-0002Wj-6L
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:27:34 +0000
Received: from [193.109.254.147:35936] by server-2.bemta-14.messagelabs.com id
	44/F4-19409-56B1D8F4; Tue, 17 Apr 2012 07:27:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334647652!4889821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32739 invoked from network); 17 Apr 2012 07:27:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 07:27:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11968370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 07:27:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 08:27:32 +0100
Message-ID: <1334647651.11493.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: AP <apxeng@gmail.com>
Date: Tue, 17 Apr 2012 08:27:31 +0100
In-Reply-To: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
> On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
> of pages (in the GB range) from a guest in to Dom0

Out of interest -- what are you doing this for?

>  using
> xc_map_foreign_bulk() I am hitting a segfault.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>     err=0x7ffff67f4010, num=<optimized out>)
>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>     err=0x7ffff67f4010, num=<optimized out>)
>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>     err=<optimized out>, num=<optimized out>) at xc_foreign_memory.c:79
> 
> This was working for me with Xen 4.1.2. On comparing
> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
> the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
> using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
> stack with the call.

I bet this is due to Linux's stack guard page. This means that if you
try and increase the stack by more than ~1 page you skip entirely over
the "next" stack page and into the guard.

Does it help if after the alloca you add a loop which touches the first
word of each page of the new buffer? Since the stack grows down you
might actually need to do it backwards from the end of the array in
order to start at the end which is nearest the existing stack? (it's
before coffee o'clock so thinking about stack direction isn't my strong
point yet...)

The switch to alloca was made recently in order to optimise the hotpath
for a userspace I/O backend.

BTW, Santosh, it didn't occur to me at the time but what is privcmd mmap
doing on the hot path for the userspace I/O anyway? Most hotpath
operations should really be grant table ops, a backend shouldn't be
relying on the privileges accorded to dom0 -- for one thing it should be
expected to work in a driver domain.

>  If I replace the alloca() with malloc() the call
> goes through. What is the way around this? Should I be using
> xc_map_foreign_batch() instead, which I think is deprecated? Please
> advice...
> 
> Thanks,
> AP
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:27:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2p5-0002Wz-F9; Tue, 17 Apr 2012 07:27:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK2p4-0002Wj-6L
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:27:34 +0000
Received: from [193.109.254.147:35936] by server-2.bemta-14.messagelabs.com id
	44/F4-19409-56B1D8F4; Tue, 17 Apr 2012 07:27:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334647652!4889821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32739 invoked from network); 17 Apr 2012 07:27:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 07:27:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11968370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 07:27:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 08:27:32 +0100
Message-ID: <1334647651.11493.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: AP <apxeng@gmail.com>
Date: Tue, 17 Apr 2012 08:27:31 +0100
In-Reply-To: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
> On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
> of pages (in the GB range) from a guest in to Dom0

Out of interest -- what are you doing this for?

>  using
> xc_map_foreign_bulk() I am hitting a segfault.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>     err=0x7ffff67f4010, num=<optimized out>)
>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>     err=0x7ffff67f4010, num=<optimized out>)
>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>     err=<optimized out>, num=<optimized out>) at xc_foreign_memory.c:79
> 
> This was working for me with Xen 4.1.2. On comparing
> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
> the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
> using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
> stack with the call.

I bet this is due to Linux's stack guard page. This means that if you
try and increase the stack by more than ~1 page you skip entirely over
the "next" stack page and into the guard.

Does it help if after the alloca you add a loop which touches the first
word of each page of the new buffer? Since the stack grows down you
might actually need to do it backwards from the end of the array in
order to start at the end which is nearest the existing stack? (it's
before coffee o'clock so thinking about stack direction isn't my strong
point yet...)

The switch to alloca was made recently in order to optimise the hotpath
for a userspace I/O backend.

BTW, Santosh, it didn't occur to me at the time but what is privcmd mmap
doing on the hot path for the userspace I/O anyway? Most hotpath
operations should really be grant table ops, a backend shouldn't be
relying on the privileges accorded to dom0 -- for one thing it should be
expected to work in a driver domain.

>  If I replace the alloca() with malloc() the call
> goes through. What is the way around this? Should I be using
> xc_map_foreign_batch() instead, which I think is deprecated? Please
> advice...
> 
> Thanks,
> AP
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:27:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2p5-0002Wq-2q; Tue, 17 Apr 2012 07:27:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK2p3-0002Wd-EP
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:27:33 +0000
Received: from [85.158.143.35:54373] by server-3.bemta-4.messagelabs.com id
	B4/30-05853-46B1D8F4; Tue, 17 Apr 2012 07:27:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334647651!16440528!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3847 invoked from network); 17 Apr 2012 07:27:31 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 07:27:31 -0000
Received: by wibhj13 with SMTP id hj13so249033wib.6
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 00:27:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cATjygA4YaKMDwru4s11A9xlEHgsY63hwogn0vZzb5c=;
	b=I2Cs2NkyzwnHtmDr4KerQwLyOTePMGnbtTkgBPmoFeqznY8GGOFVMdFs7EWAL492fc
	CVjb6Uv7ZVL0osR0NUWr6MI13LHaynTbSV2kPDP8FLOKbJe8i/fwN0YJrVhALVM5Iio4
	TX7pjJXsaFn6BmBMioPULJAx1TcwjdKwgFjlGdjPNLRUJxzLmLRf0LSn4vnsyvi9ipbH
	FEFEXz/Eu/1iYiqimUSYAhBDNF/JiWYUZKQv/1mgWoPqbiPIvVGjQSZNHMo/KXdzvNo3
	j3d0A7lzVBUtNSvIPmFW4hMFsmTFA4Ju1clnxErxSnn3I5jmxJhXGDygvZJ4+H8K4W6h
	V7Hw==
Received: by 10.180.101.8 with SMTP id fc8mr11970242wib.12.1334647650624;
	Tue, 17 Apr 2012 00:27:30 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id h8sm40446982wix.4.2012.04.17.00.27.29
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 00:27:30 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 08:27:21 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB2D9E9.3DE0F%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0D84A1@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 04:26, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

> Hi keir
> 
> I noticed that the changeset 15289 introuduced locking to platform timers. And
> you mentioned that it only handy for correctness. Are there some potential
> issues which is fixed by this patch? If not, I wonder why we need those locks?

Yes, issues were fixed by the patch. That's why I bothered to implement it.
However I think the observed issues were with protecting the mechanisms in
vpt.c, and the other locking at least partially may be overly cautious.

> I think it should be OS's responsibly to guarantee the access sequentially,
> not hypervisor. Am I right?

It depends. Where an access is an apparently-atomic memory-mapped access,
but implemented as a sequence of operations in the hypervisor, the
hypervisor might need to maintain atomicity through locking.

> I don't know whether all those locks are necessary, but at least the lock for
> vhpet, especially the reading lock, is not required.

This is definitely not true, for example locking is required around calls to
create_periodic_time(), to serialise them. So in general the locking I
added, even in vhpet.c is required. If you have a specific hot path you are
looking to optimise, and especially if you have numbers to back that up,
then we can consider specific localised optimisations to avoid locking where
we can reason it is not needed.

 -- Keir

> best regards
> yang
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:27:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK2p5-0002Wq-2q; Tue, 17 Apr 2012 07:27:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK2p3-0002Wd-EP
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:27:33 +0000
Received: from [85.158.143.35:54373] by server-3.bemta-4.messagelabs.com id
	B4/30-05853-46B1D8F4; Tue, 17 Apr 2012 07:27:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334647651!16440528!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3847 invoked from network); 17 Apr 2012 07:27:31 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 07:27:31 -0000
Received: by wibhj13 with SMTP id hj13so249033wib.6
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 00:27:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cATjygA4YaKMDwru4s11A9xlEHgsY63hwogn0vZzb5c=;
	b=I2Cs2NkyzwnHtmDr4KerQwLyOTePMGnbtTkgBPmoFeqznY8GGOFVMdFs7EWAL492fc
	CVjb6Uv7ZVL0osR0NUWr6MI13LHaynTbSV2kPDP8FLOKbJe8i/fwN0YJrVhALVM5Iio4
	TX7pjJXsaFn6BmBMioPULJAx1TcwjdKwgFjlGdjPNLRUJxzLmLRf0LSn4vnsyvi9ipbH
	FEFEXz/Eu/1iYiqimUSYAhBDNF/JiWYUZKQv/1mgWoPqbiPIvVGjQSZNHMo/KXdzvNo3
	j3d0A7lzVBUtNSvIPmFW4hMFsmTFA4Ju1clnxErxSnn3I5jmxJhXGDygvZJ4+H8K4W6h
	V7Hw==
Received: by 10.180.101.8 with SMTP id fc8mr11970242wib.12.1334647650624;
	Tue, 17 Apr 2012 00:27:30 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id h8sm40446982wix.4.2012.04.17.00.27.29
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 00:27:30 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 08:27:21 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB2D9E9.3DE0F%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0D84A1@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 04:26, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

> Hi keir
> 
> I noticed that the changeset 15289 introuduced locking to platform timers. And
> you mentioned that it only handy for correctness. Are there some potential
> issues which is fixed by this patch? If not, I wonder why we need those locks?

Yes, issues were fixed by the patch. That's why I bothered to implement it.
However I think the observed issues were with protecting the mechanisms in
vpt.c, and the other locking at least partially may be overly cautious.

> I think it should be OS's responsibly to guarantee the access sequentially,
> not hypervisor. Am I right?

It depends. Where an access is an apparently-atomic memory-mapped access,
but implemented as a sequence of operations in the hypervisor, the
hypervisor might need to maintain atomicity through locking.

> I don't know whether all those locks are necessary, but at least the lock for
> vhpet, especially the reading lock, is not required.

This is definitely not true, for example locking is required around calls to
create_periodic_time(), to serialise them. So in general the locking I
added, even in vhpet.c is required. If you have a specific hot path you are
looking to optimise, and especially if you have numbers to back that up,
then we can consider specific localised optimisations to avoid locking where
we can reason it is not needed.

 -- Keir

> best regards
> yang
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK38x-0003Fw-8b; Tue, 17 Apr 2012 07:48:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK38v-0003Fr-NM
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 07:48:05 +0000
Received: from [85.158.143.99:64744] by server-1.bemta-4.messagelabs.com id
	72/ED-20925-3302D8F4; Tue, 17 Apr 2012 07:48:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334648881!14312570!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30991 invoked from network); 17 Apr 2012 07:48:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 07:48:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 08:49:40 +0100
Message-Id: <4F8D3C4E020000780007E658@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 08:47:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C4818.8070603@citrix.com>
	<8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
In-Reply-To: <8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.04.12 at 19:30, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: David Vrabel [mailto:david.vrabel@citrix.com]
>> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> 
>> On 16/04/12 17:05, Dan Magenheimer wrote:
>> >> From: David Vrabel [mailto:david.vrabel@citrix.com]
>> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> >
>> > Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
>> 
>> Fair enough,
>> 
>> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
>> 
>> The original customer problem is on a host with Xen 3.4.  What do you
>> recommend for Linux guests running such hosts?
> 
> For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
> back-patch the guest kernel with a workaround such as your patch, great!
> I'm only arguing against the patch getting perpetuated upstream.
>  
>> > In fact, it might be wise for a Xen-savvy kernel to check to see
>> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
>> > and tsc=reliable.
>> 
>> So, should the xen clocksource do:
>> 
>> if Xen 4.0+
>>     clock is stable, use rdtsc only.
>> else
>>     clock is unstable, use existing pvclock implementation.
> 
> Yes, that's what I propose.  To clarify:
> 
> if the guest can and does determine it is running on Xen 4.0+

_and_ TSC reads are emulated (which I don't think they are by
default).

Jan

> 	TSC is guaranteed by Xen to be stable, use clocksource=tsc tsc=reliable
> else
> 	Xen only guarantees that pvclock is stable, use pvclock



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK38x-0003Fw-8b; Tue, 17 Apr 2012 07:48:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK38v-0003Fr-NM
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 07:48:05 +0000
Received: from [85.158.143.99:64744] by server-1.bemta-4.messagelabs.com id
	72/ED-20925-3302D8F4; Tue, 17 Apr 2012 07:48:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334648881!14312570!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30991 invoked from network); 17 Apr 2012 07:48:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 07:48:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 08:49:40 +0100
Message-Id: <4F8D3C4E020000780007E658@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 08:47:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C4818.8070603@citrix.com>
	<8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
In-Reply-To: <8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	Sheng Yang <sheng@yasker.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.04.12 at 19:30, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: David Vrabel [mailto:david.vrabel@citrix.com]
>> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> 
>> On 16/04/12 17:05, Dan Magenheimer wrote:
>> >> From: David Vrabel [mailto:david.vrabel@citrix.com]
>> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> >
>> > Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
>> 
>> Fair enough,
>> 
>> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
>> 
>> The original customer problem is on a host with Xen 3.4.  What do you
>> recommend for Linux guests running such hosts?
> 
> For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
> back-patch the guest kernel with a workaround such as your patch, great!
> I'm only arguing against the patch getting perpetuated upstream.
>  
>> > In fact, it might be wise for a Xen-savvy kernel to check to see
>> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
>> > and tsc=reliable.
>> 
>> So, should the xen clocksource do:
>> 
>> if Xen 4.0+
>>     clock is stable, use rdtsc only.
>> else
>>     clock is unstable, use existing pvclock implementation.
> 
> Yes, that's what I propose.  To clarify:
> 
> if the guest can and does determine it is running on Xen 4.0+

_and_ TSC reads are emulated (which I don't think they are by
default).

Jan

> 	TSC is guaranteed by Xen to be stable, use clocksource=tsc tsc=reliable
> else
> 	Xen only guarantees that pvclock is stable, use pvclock



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3Gv-0003Sm-7G; Tue, 17 Apr 2012 07:56:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK3Gu-0003Sf-He
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:56:20 +0000
Received: from [85.158.138.51:53399] by server-12.bemta-3.messagelabs.com id
	72/45-29760-3222D8F4; Tue, 17 Apr 2012 07:56:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334649378!18373495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29505 invoked from network); 17 Apr 2012 07:56:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 07:56:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 08:57:56 +0100
Message-Id: <4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 08:56:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,"AP" <apxeng@gmail.com>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
In-Reply-To: <1334647651.11493.4.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
>> of pages (in the GB range) from a guest in to Dom0
> 
> Out of interest -- what are you doing this for?
> 
>>  using
>> xc_map_foreign_bulk() I am hitting a segfault.
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
>> (gdb) bt
>> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>>     err=<optimized out>, num=<optimized out>) at xc_foreign_memory.c:79
>> 
>> This was working for me with Xen 4.1.2. On comparing
>> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
>> the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
>> using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
>> stack with the call.
> 
> I bet this is due to Linux's stack guard page. This means that if you
> try and increase the stack by more than ~1 page you skip entirely over
> the "next" stack page and into the guard.
> 
> Does it help if after the alloca you add a loop which touches the first
> word of each page of the new buffer? Since the stack grows down you
> might actually need to do it backwards from the end of the array in
> order to start at the end which is nearest the existing stack? (it's
> before coffee o'clock so thinking about stack direction isn't my strong
> point yet...)

This should really be done by the alloca() implementation itself -
anything else is a bug.

> The switch to alloca was made recently in order to optimise the hotpath
> for a userspace I/O backend.

Probably this should be made size-dependent ...

> BTW, Santosh, it didn't occur to me at the time but what is privcmd mmap
> doing on the hot path for the userspace I/O anyway? Most hotpath
> operations should really be grant table ops, a backend shouldn't be
> relying on the privileges accorded to dom0 -- for one thing it should be
> expected to work in a driver domain.

... if this indeed turns out to be a hot path for something at all?

Jan

>>  If I replace the alloca() with malloc() the call
>> goes through. What is the way around this? Should I be using
>> xc_map_foreign_batch() instead, which I think is deprecated? Please
>> advice...
>> 
>> Thanks,
>> AP
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3Gv-0003Sm-7G; Tue, 17 Apr 2012 07:56:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK3Gu-0003Sf-He
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:56:20 +0000
Received: from [85.158.138.51:53399] by server-12.bemta-3.messagelabs.com id
	72/45-29760-3222D8F4; Tue, 17 Apr 2012 07:56:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334649378!18373495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29505 invoked from network); 17 Apr 2012 07:56:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 07:56:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 08:57:56 +0100
Message-Id: <4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 08:56:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,"AP" <apxeng@gmail.com>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
In-Reply-To: <1334647651.11493.4.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
>> of pages (in the GB range) from a guest in to Dom0
> 
> Out of interest -- what are you doing this for?
> 
>>  using
>> xc_map_foreign_bulk() I am hitting a segfault.
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
>> (gdb) bt
>> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>>     err=<optimized out>, num=<optimized out>) at xc_foreign_memory.c:79
>> 
>> This was working for me with Xen 4.1.2. On comparing
>> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
>> the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
>> using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
>> stack with the call.
> 
> I bet this is due to Linux's stack guard page. This means that if you
> try and increase the stack by more than ~1 page you skip entirely over
> the "next" stack page and into the guard.
> 
> Does it help if after the alloca you add a loop which touches the first
> word of each page of the new buffer? Since the stack grows down you
> might actually need to do it backwards from the end of the array in
> order to start at the end which is nearest the existing stack? (it's
> before coffee o'clock so thinking about stack direction isn't my strong
> point yet...)

This should really be done by the alloca() implementation itself -
anything else is a bug.

> The switch to alloca was made recently in order to optimise the hotpath
> for a userspace I/O backend.

Probably this should be made size-dependent ...

> BTW, Santosh, it didn't occur to me at the time but what is privcmd mmap
> doing on the hot path for the userspace I/O anyway? Most hotpath
> operations should really be grant table ops, a backend shouldn't be
> relying on the privileges accorded to dom0 -- for one thing it should be
> expected to work in a driver domain.

... if this indeed turns out to be a hot path for something at all?

Jan

>>  If I replace the alloca() with malloc() the call
>> goes through. What is the way around this? Should I be using
>> xc_map_foreign_batch() instead, which I think is deprecated? Please
>> advice...
>> 
>> Thanks,
>> AP
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3Jm-0003bW-Vw; Tue, 17 Apr 2012 07:59:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SK3Jk-0003bQ-I9
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:59:17 +0000
Received: from [85.158.138.51:18491] by server-6.bemta-3.messagelabs.com id
	33/61-05145-3D22D8F4; Tue, 17 Apr 2012 07:59:15 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334649553!22485922!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0OTA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4624 invoked from network); 17 Apr 2012 07:59:14 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 07:59:14 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 17 Apr 2012 00:59:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89901335"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 00:56:03 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 00:56:02 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Tue, 17 Apr 2012 09:28:06 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNEzo9b8szDONMp0ufANRY641D2paMVoHAgBH1osA=
Date: Tue, 17 Apr 2012 01:28:04 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD12DE8@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Ian

Any other comments for this patch?

Thanks,
-Xudong


> -----Original Message-----
> From: Hao, Xudong
> Sent: Thursday, April 05, 2012 11:37 PM
> To: 'Ian Jackson'
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> <Porting from xen 4.1, patch on Xen unstable 25138>
> 
> libxl: passthrough: avoid passing through devices not owned by pciback
> 
> This patch makes sure the passthrough device belongs to pciback before allow
> them passthrough to the guest.  There are still many other checks missing.
> 
> xm terminates the guest startup process when this type of condition is found.
> This patch just allows the guest to continue to boot but with no device
> passthrough.
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff -r 4e1d091d10d8 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Fri Mar 16 15:24:25 2012 +0000
> +++ b/tools/libxl/libxl_pci.c	Thu Mar 22 00:43:14 2012 +0800
> @@ -779,6 +779,24 @@ int libxl_device_pci_add(libxl_ctx *ctx,
>      return rc;
>  }
> 
> +static int libxl_pcidev_assignable(libxl_ctx *ctx, libxl_device_pci
> +*pcidev) {
> +    libxl_device_pci *pcidevs;
> +    int num, i;
> +
> +    pcidevs = libxl_device_pci_list_assignable(ctx, &num);
> +    for (i = 0; i < num; i++) {
> +        if (pcidevs[i].domain == pcidev->domain &&
> +            pcidevs[i].bus == pcidev->bus &&
> +            pcidevs[i].dev == pcidev->dev &&
> +            pcidevs[i].func == pcidev->func)
> +        {
> +            return 1;
> +        }
> +    }
> +    return 0;
> +}
> +
>  int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci
> *pcidev, int starting)  {
>      libxl_ctx *ctx = libxl__gc_owner(gc); @@ -789,6 +807,13 @@ int
> libxl__device_pci_add(libxl__gc *gc,
> 
>      rc = libxl__device_pci_setdefault(gc, pcidev);
>      if (rc) goto out;
> +
> +    if (!libxl_pcidev_assignable(ctx, pcidev)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device %x:%x:%x.%x is
> not assignable",
> +                   pcidev->domain, pcidev->bus, pcidev->dev,
> pcidev->func);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> 
>      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc ) {
> 
> Thanks,
> -Xudong
> 
> > -----Original Message-----
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > Sent: Thursday, April 05, 2012 10:42 PM
> > To: Hao, Xudong
> > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > Subject: RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> > devices not owned by pciback
> >
> > Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid
> passing
> > through devices not owned by pciback"):
> > >
> > > > -----Original Message-----
> > > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > > > Sent: Tuesday, April 03, 2012 1:01 AM
> > > > To: Hao, Xudong
> > > > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > > > Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> > > > through devices not owned by pciback
> > > >
> > > > Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid
> > > > passing through devices not owned by pciback"):
> > > > > <Porting from Xen 4.1 tree.>
> > > > >
> > > > > libxl: passthrough: avoid passing through devices not owned by
> > > > > pciback
> > > >
> > > > I'm afraid this no longer applies to xen-unstable.hg tip.
> > > >
> > > Reason?
> > >
> > > If no pciback checking, one device could be assigned to guest even it's being
> > used by dom0, is there security issue?
> >
> > I mean that it has conflicts when I try to apply it.  You need to refresh it.
> >
> > Thanks,
> > Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 07:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 07:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3Jm-0003bW-Vw; Tue, 17 Apr 2012 07:59:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SK3Jk-0003bQ-I9
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:59:17 +0000
Received: from [85.158.138.51:18491] by server-6.bemta-3.messagelabs.com id
	33/61-05145-3D22D8F4; Tue, 17 Apr 2012 07:59:15 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334649553!22485922!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY0OTA5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4624 invoked from network); 17 Apr 2012 07:59:14 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 07:59:14 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 17 Apr 2012 00:59:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89901335"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 00:56:03 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 00:56:02 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.125]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Tue, 17 Apr 2012 09:28:06 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNEzo9b8szDONMp0ufANRY641D2paMVoHAgBH1osA=
Date: Tue, 17 Apr 2012 01:28:04 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD12DE8@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Ian

Any other comments for this patch?

Thanks,
-Xudong


> -----Original Message-----
> From: Hao, Xudong
> Sent: Thursday, April 05, 2012 11:37 PM
> To: 'Ian Jackson'
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> <Porting from xen 4.1, patch on Xen unstable 25138>
> 
> libxl: passthrough: avoid passing through devices not owned by pciback
> 
> This patch makes sure the passthrough device belongs to pciback before allow
> them passthrough to the guest.  There are still many other checks missing.
> 
> xm terminates the guest startup process when this type of condition is found.
> This patch just allows the guest to continue to boot but with no device
> passthrough.
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff -r 4e1d091d10d8 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Fri Mar 16 15:24:25 2012 +0000
> +++ b/tools/libxl/libxl_pci.c	Thu Mar 22 00:43:14 2012 +0800
> @@ -779,6 +779,24 @@ int libxl_device_pci_add(libxl_ctx *ctx,
>      return rc;
>  }
> 
> +static int libxl_pcidev_assignable(libxl_ctx *ctx, libxl_device_pci
> +*pcidev) {
> +    libxl_device_pci *pcidevs;
> +    int num, i;
> +
> +    pcidevs = libxl_device_pci_list_assignable(ctx, &num);
> +    for (i = 0; i < num; i++) {
> +        if (pcidevs[i].domain == pcidev->domain &&
> +            pcidevs[i].bus == pcidev->bus &&
> +            pcidevs[i].dev == pcidev->dev &&
> +            pcidevs[i].func == pcidev->func)
> +        {
> +            return 1;
> +        }
> +    }
> +    return 0;
> +}
> +
>  int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci
> *pcidev, int starting)  {
>      libxl_ctx *ctx = libxl__gc_owner(gc); @@ -789,6 +807,13 @@ int
> libxl__device_pci_add(libxl__gc *gc,
> 
>      rc = libxl__device_pci_setdefault(gc, pcidev);
>      if (rc) goto out;
> +
> +    if (!libxl_pcidev_assignable(ctx, pcidev)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device %x:%x:%x.%x is
> not assignable",
> +                   pcidev->domain, pcidev->bus, pcidev->dev,
> pcidev->func);
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> 
>      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc ) {
> 
> Thanks,
> -Xudong
> 
> > -----Original Message-----
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > Sent: Thursday, April 05, 2012 10:42 PM
> > To: Hao, Xudong
> > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > Subject: RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> > devices not owned by pciback
> >
> > Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid
> passing
> > through devices not owned by pciback"):
> > >
> > > > -----Original Message-----
> > > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > > > Sent: Tuesday, April 03, 2012 1:01 AM
> > > > To: Hao, Xudong
> > > > Cc: xen-devel@lists.xensource.com; Kay, Allen M
> > > > Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> > > > through devices not owned by pciback
> > > >
> > > > Hao, Xudong writes ("[Xen-devel] [PATCH] libxl: passthrough: avoid
> > > > passing through devices not owned by pciback"):
> > > > > <Porting from Xen 4.1 tree.>
> > > > >
> > > > > libxl: passthrough: avoid passing through devices not owned by
> > > > > pciback
> > > >
> > > > I'm afraid this no longer applies to xen-unstable.hg tip.
> > > >
> > > Reason?
> > >
> > > If no pciback checking, one device could be assigned to guest even it's being
> > used by dom0, is there security issue?
> >
> > I mean that it has conflicts when I try to apply it.  You need to refresh it.
> >
> > Thanks,
> > Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:16:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3aR-0004LD-2b; Tue, 17 Apr 2012 08:16:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK3aP-0004Kz-Lt
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 08:16:29 +0000
Received: from [85.158.138.51:32071] by server-6.bemta-3.messagelabs.com id
	A5/53-05145-CD62D8F4; Tue, 17 Apr 2012 08:16:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334650587!11456499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32602 invoked from network); 17 Apr 2012 08:16:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11969666"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 08:16:07 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 09:16:07 +0100
Message-ID: <1334650567.11493.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lloyd Dizon <thecarrionkind@gmail.com>
Date: Tue, 17 Apr 2012 09:16:07 +0100
In-Reply-To: <CAFj8LadtTpTFgxouiPxab9wW8xQCktrqrPzOOxyVYnBcaaZJvQ@mail.gmail.com>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
	<CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
	<1334570256.14560.80.camel@zakaz.uk.xensource.com>
	<CAFj8LaeXZNzSaNVcAMU1r3svwh4UrZLhv1wZfXn7_UHaT7A3GA@mail.gmail.com>
	<1334588223.14560.205.camel@zakaz.uk.xensource.com>
	<CAFj8LadtTpTFgxouiPxab9wW8xQCktrqrPzOOxyVYnBcaaZJvQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Todd Deshane <todd.deshane@xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Remi Gacogne <rgacogne-xen@valombre.net>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 08:41 +0100, Lloyd Dizon wrote:
> On Mon, Apr 16, 2012 at 4:57 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-04-16 at 15:45 +0100, Lloyd Dizon wrote:
> >> On Mon, Apr 16, 2012 at 11:57 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >
> >> > On Fri, 2012-04-13 at 18:22 +0100, Todd Deshane wrote:
> >> > > Adding Xen-devel.
> >> > >
> >> > > What are the current timekeeping best practices now?
> >> >
> >> > pvops kernels behave as if independent_wallclock == 1, so the existing
> >> > advice:
> >> >        set /proc/sys/xen/independent_wallclock to 1 and run ntp on
> >> >        domU.
> >> > still applies.
> >>
> >> This also applies to Xen 4.0 (4.0.0) if I understood correctly?
> >
> > This is entirely a function of the guest kernel version and not the
> > hypervisor
> >
> >> If so and based on previous posts can we resume that this is what is
> >> recommended:
> >
> > If you s/Xen3/Classic XenoLinux Kernels/ and s/Xen4/Paravirt Ops Linux
> > Kernels/g then I think it is somewhat accurate, at least for the PV
> > line.
> >
> > I must confess I don't really know for the HVM line. I suspect that it
> > is actually:
> >
> > Classic XenoLinux -- no PV time source, independent_wallclock means
> > nothing, run NTP in the guest
> >
> > Paravirt ops kernels _without_ PV time PVHVM extensions -- no PV time
> > source, independent_wallclock means nothing, run NTP in the guest
> >
> > Paravirt ops kernels _with_ PV time PVHVM extensions -- PV time source,
> > independent_wallclock always == 1, run NTP.
> >
> > So in short always run NTP in an HVM guest, regardless of the presence
> > or absence of PV time extensions
> 
> I do not fully understand the difference yet between and Classic
> XenoLinux and Paravirt Ops Kernel (will dig the info later)

Roughly:

classic == old out-of-tree Xen patches, static compile time support for
Xen. This is the old "2.6.18-xen.hg" tree and includes the "SuSE forward
port kernels" which are the classic patches kept up to date with recent
kernels.

pvops == patches in upstream Linux, dynamic support for Xen enabled at
kernel boot time. pvops supported domU from ~2.6.24 and dom0 from 3.0
onwards.

>  but here
> is the resume:
> 
>        -------------------------------------------------------------------------------------------------------------------
>        |  Xen3: Classic XenoLinux Kern                     |
>     Xen4: Paravirt Ops Linux Kern                 |
> --------------------------------------------------------------------------------------------------------------------------
>  PV    | independent_wallclock = 0 or 1                    |
> independent_wallclock =  1                                  |
> --------------------------------------------------------------------------------------------------------------------------
>  HVM   | -> no PV timesource, no ind. wallclock, run NTP   | -> w/o PV
> time PVHVM extensions, no ind. wallclock, run NTP |
>        |                                                   | -> PV
> time source, ind. wallclock always 1, run NTP         |
> --------------------------------------------------------------------------------------------------------------------------

It got a bit mangled in transit but it looks reasonable.

You should remove "Xen3" and "Xen4" from the titles since the hypervisor
version has no bearing on any of this. You can just as easily run a
pvops kernel on Xen3.x or a classic kernel on Xen4.x (and of course you
can mix and match those on a single host)

The 3->4 major number transition was mostly just a version number bump,
it didn't indicate any major change in the API or anything like that --
any PV kernel should run on any Xen from 3.0 onwards, right through to
4.2 (and beyond).

> Should we put this somewhere (wiki) until somebody else proves this is
> inaccurate ?

Please do put it on the wiki, I think there was a reference to a page (a
FAQ?) further up thread which seems like as good a place as any to add
it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:16:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3aR-0004LD-2b; Tue, 17 Apr 2012 08:16:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK3aP-0004Kz-Lt
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 08:16:29 +0000
Received: from [85.158.138.51:32071] by server-6.bemta-3.messagelabs.com id
	A5/53-05145-CD62D8F4; Tue, 17 Apr 2012 08:16:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334650587!11456499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32602 invoked from network); 17 Apr 2012 08:16:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11969666"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 08:16:07 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 09:16:07 +0100
Message-ID: <1334650567.11493.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lloyd Dizon <thecarrionkind@gmail.com>
Date: Tue, 17 Apr 2012 09:16:07 +0100
In-Reply-To: <CAFj8LadtTpTFgxouiPxab9wW8xQCktrqrPzOOxyVYnBcaaZJvQ@mail.gmail.com>
References: <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
	<CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
	<CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
	<alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
	<CAMrPLWJKxD9FSOAp9ovCuqgMCzREw5B68XeUegvgdOPmG=hUkg@mail.gmail.com>
	<1334570256.14560.80.camel@zakaz.uk.xensource.com>
	<CAFj8LaeXZNzSaNVcAMU1r3svwh4UrZLhv1wZfXn7_UHaT7A3GA@mail.gmail.com>
	<1334588223.14560.205.camel@zakaz.uk.xensource.com>
	<CAFj8LadtTpTFgxouiPxab9wW8xQCktrqrPzOOxyVYnBcaaZJvQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Todd Deshane <todd.deshane@xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Remi Gacogne <rgacogne-xen@valombre.net>
Subject: Re: [Xen-devel] [Xen-users] Xen timekeeping best practices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 08:41 +0100, Lloyd Dizon wrote:
> On Mon, Apr 16, 2012 at 4:57 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-04-16 at 15:45 +0100, Lloyd Dizon wrote:
> >> On Mon, Apr 16, 2012 at 11:57 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >
> >> > On Fri, 2012-04-13 at 18:22 +0100, Todd Deshane wrote:
> >> > > Adding Xen-devel.
> >> > >
> >> > > What are the current timekeeping best practices now?
> >> >
> >> > pvops kernels behave as if independent_wallclock == 1, so the existing
> >> > advice:
> >> >        set /proc/sys/xen/independent_wallclock to 1 and run ntp on
> >> >        domU.
> >> > still applies.
> >>
> >> This also applies to Xen 4.0 (4.0.0) if I understood correctly?
> >
> > This is entirely a function of the guest kernel version and not the
> > hypervisor
> >
> >> If so and based on previous posts can we resume that this is what is
> >> recommended:
> >
> > If you s/Xen3/Classic XenoLinux Kernels/ and s/Xen4/Paravirt Ops Linux
> > Kernels/g then I think it is somewhat accurate, at least for the PV
> > line.
> >
> > I must confess I don't really know for the HVM line. I suspect that it
> > is actually:
> >
> > Classic XenoLinux -- no PV time source, independent_wallclock means
> > nothing, run NTP in the guest
> >
> > Paravirt ops kernels _without_ PV time PVHVM extensions -- no PV time
> > source, independent_wallclock means nothing, run NTP in the guest
> >
> > Paravirt ops kernels _with_ PV time PVHVM extensions -- PV time source,
> > independent_wallclock always == 1, run NTP.
> >
> > So in short always run NTP in an HVM guest, regardless of the presence
> > or absence of PV time extensions
> 
> I do not fully understand the difference yet between and Classic
> XenoLinux and Paravirt Ops Kernel (will dig the info later)

Roughly:

classic == old out-of-tree Xen patches, static compile time support for
Xen. This is the old "2.6.18-xen.hg" tree and includes the "SuSE forward
port kernels" which are the classic patches kept up to date with recent
kernels.

pvops == patches in upstream Linux, dynamic support for Xen enabled at
kernel boot time. pvops supported domU from ~2.6.24 and dom0 from 3.0
onwards.

>  but here
> is the resume:
> 
>        -------------------------------------------------------------------------------------------------------------------
>        |  Xen3: Classic XenoLinux Kern                     |
>     Xen4: Paravirt Ops Linux Kern                 |
> --------------------------------------------------------------------------------------------------------------------------
>  PV    | independent_wallclock = 0 or 1                    |
> independent_wallclock =  1                                  |
> --------------------------------------------------------------------------------------------------------------------------
>  HVM   | -> no PV timesource, no ind. wallclock, run NTP   | -> w/o PV
> time PVHVM extensions, no ind. wallclock, run NTP |
>        |                                                   | -> PV
> time source, ind. wallclock always 1, run NTP         |
> --------------------------------------------------------------------------------------------------------------------------

It got a bit mangled in transit but it looks reasonable.

You should remove "Xen3" and "Xen4" from the titles since the hypervisor
version has no bearing on any of this. You can just as easily run a
pvops kernel on Xen3.x or a classic kernel on Xen4.x (and of course you
can mix and match those on a single host)

The 3->4 major number transition was mostly just a version number bump,
it didn't indicate any major change in the API or anything like that --
any PV kernel should run on any Xen from 3.0 onwards, right through to
4.2 (and beyond).

> Should we put this somewhere (wiki) until somebody else proves this is
> inaccurate ?

Please do put it on the wiki, I think there was a reference to a page (a
FAQ?) further up thread which seems like as good a place as any to add
it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:20:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:20:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3dV-0004ZO-Mb; Tue, 17 Apr 2012 08:19:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SK3dU-0004ZE-3B
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 08:19:40 +0000
Received: from [85.158.143.99:14074] by server-3.bemta-4.messagelabs.com id
	F8/DA-05853-B972D8F4; Tue, 17 Apr 2012 08:19:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334650778!18684868!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8944 invoked from network); 17 Apr 2012 08:19:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 08:19:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SK3dI-0007vO-4l; Tue, 17 Apr 2012 08:19:28 +0000
Date: Tue, 17 Apr 2012 09:19:28 +0100
From: Tim Deegan <tim@xen.org>
To: Sheng Yang <sheng@yasker.org>
Message-ID: <20120417081928.GA29964@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
	<20120416181744.GF13111@ocelot.phlegethon.org>
	<CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 -0700 on 16 Apr (1334592096), Sheng Yang wrote:
> So I think there are maybe *two* bugs in this issue, one caused time
> jump(detail below), the other in the kernel triggered by the first bug
> sometime, thus result in migration fail.
> 
> I've spent some time to identify the timestamp jump issue, and finally
> found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
> called non-stop TSC). The present of the feature would enable a
> parameter in the kernel named: sched_clock_stable. Seems this
> parameter is unable to work with Xen's pvclock. If
> sched_clock_stable() is set, value returned by xen_clocksource_read()
> would be returned as sched_clock_cpu() directly(rather than calculated
> through sched_clock_local()), but CMIIW the value returned by
> xen_clocksource_read() is based on host(vcpu) uptime rather than this
> VM's uptime, then result in the timestamp jump.

OK - that seems like a kernel bug.  Linux should not be modifying how it
treats the PV clocksource based on the 'Invariant TSC' bit.
(Conversely, the patch to pretend the TSC is not invariant just because
the PV clocksource is present also seems wrong, and the earlier patch
that just enforces sched_clock_stable=0 would be better.)

> I've compiled a kernel, force sched_clock_stable=0, then it solved the
> timestamp jump issue as expected. Luckily, seems it also solved the
> call trace and guest hang issue as well.
> 
> I've posted a patch to mask the CPUID leaf 0x80000007 in Xen.

Well, as Dan says, if Xen is emulating RDTSC to provide a 'stable' TSC, 
we shouldn't _also_ tell the guest that it's not stable. :)  

OTOH, grepping for CONSTANT_TSC, NONSTOP_TSC, and TSC_RELIABLE, I don't
see anywhere even in xen-unstable where these bits are ever hidden from
the guest.  I think it would be reasonable to mask this from PV guests
at least for tsc_mode == 2, and on older Xens.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:20:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:20:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3dV-0004ZO-Mb; Tue, 17 Apr 2012 08:19:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SK3dU-0004ZE-3B
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 08:19:40 +0000
Received: from [85.158.143.99:14074] by server-3.bemta-4.messagelabs.com id
	F8/DA-05853-B972D8F4; Tue, 17 Apr 2012 08:19:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334650778!18684868!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8944 invoked from network); 17 Apr 2012 08:19:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 08:19:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SK3dI-0007vO-4l; Tue, 17 Apr 2012 08:19:28 +0000
Date: Tue, 17 Apr 2012 09:19:28 +0100
From: Tim Deegan <tim@xen.org>
To: Sheng Yang <sheng@yasker.org>
Message-ID: <20120417081928.GA29964@ocelot.phlegethon.org>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<20120416170827.GE13111@ocelot.phlegethon.org>
	<3e05ae0e-afe4-4ed7-b839-39a343cc0d06@default>
	<20120416181744.GF13111@ocelot.phlegethon.org>
	<CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+2rt41pCFV1haMAHo63rY9kx88VgiV419pf8Y=u2cXrdmGOBA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 -0700 on 16 Apr (1334592096), Sheng Yang wrote:
> So I think there are maybe *two* bugs in this issue, one caused time
> jump(detail below), the other in the kernel triggered by the first bug
> sometime, thus result in migration fail.
> 
> I've spent some time to identify the timestamp jump issue, and finally
> found it's due to Invarient TSC (CPUID Leaf 0x80000007 EDX:8, also
> called non-stop TSC). The present of the feature would enable a
> parameter in the kernel named: sched_clock_stable. Seems this
> parameter is unable to work with Xen's pvclock. If
> sched_clock_stable() is set, value returned by xen_clocksource_read()
> would be returned as sched_clock_cpu() directly(rather than calculated
> through sched_clock_local()), but CMIIW the value returned by
> xen_clocksource_read() is based on host(vcpu) uptime rather than this
> VM's uptime, then result in the timestamp jump.

OK - that seems like a kernel bug.  Linux should not be modifying how it
treats the PV clocksource based on the 'Invariant TSC' bit.
(Conversely, the patch to pretend the TSC is not invariant just because
the PV clocksource is present also seems wrong, and the earlier patch
that just enforces sched_clock_stable=0 would be better.)

> I've compiled a kernel, force sched_clock_stable=0, then it solved the
> timestamp jump issue as expected. Luckily, seems it also solved the
> call trace and guest hang issue as well.
> 
> I've posted a patch to mask the CPUID leaf 0x80000007 in Xen.

Well, as Dan says, if Xen is emulating RDTSC to provide a 'stable' TSC, 
we shouldn't _also_ tell the guest that it's not stable. :)  

OTOH, grepping for CONSTANT_TSC, NONSTOP_TSC, and TSC_RELIABLE, I don't
see anywhere even in xen-unstable where these bits are ever hidden from
the guest.  I think it would be reasonable to mask this from PV guests
at least for tsc_mode == 2, and on older Xens.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:23:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3hB-0004nO-BF; Tue, 17 Apr 2012 08:23:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SK3hA-0004nI-GZ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 08:23:28 +0000
Received: from [193.109.254.147:3125] by server-6.bemta-14.messagelabs.com id
	AA/3F-02047-F782D8F4; Tue, 17 Apr 2012 08:23:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334651006!2453998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12367 invoked from network); 17 Apr 2012 08:23:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:23:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11969857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 08:23:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 09:23:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SK3h8-0001fm-8p;
	Tue, 17 Apr 2012 08:23:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SK3h8-0003xH-1Z;
	Tue, 17 Apr 2012 09:23:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12702-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 09:23:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12702: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12702 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12702/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12701

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 12701

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12701

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a06e6cdeafe3
baseline version:
 xen                  a06e6cdeafe3

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:23:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3hB-0004nO-BF; Tue, 17 Apr 2012 08:23:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SK3hA-0004nI-GZ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 08:23:28 +0000
Received: from [193.109.254.147:3125] by server-6.bemta-14.messagelabs.com id
	AA/3F-02047-F782D8F4; Tue, 17 Apr 2012 08:23:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334651006!2453998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12367 invoked from network); 17 Apr 2012 08:23:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:23:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11969857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 08:23:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 09:23:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SK3h8-0001fm-8p;
	Tue, 17 Apr 2012 08:23:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SK3h8-0003xH-1Z;
	Tue, 17 Apr 2012 09:23:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12702-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 09:23:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12702: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12702 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12702/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12701

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 12701

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12701

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a06e6cdeafe3
baseline version:
 xen                  a06e6cdeafe3

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:25:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:25:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3ip-0004sZ-RQ; Tue, 17 Apr 2012 08:25:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <j.farzin@yahoo.com>) id 1SK3io-0004sM-9I
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 08:25:10 +0000
Received: from [85.158.143.35:43562] by server-1.bemta-4.messagelabs.com id
	CA/70-20925-5E82D8F4; Tue, 17 Apr 2012 08:25:09 +0000
X-Env-Sender: j.farzin@yahoo.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334651106!5165879!1
X-Originating-IP: [98.139.212.189]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22072 invoked from network); 17 Apr 2012 08:25:06 -0000
Received: from nm30.bullet.mail.bf1.yahoo.com (HELO
	nm30.bullet.mail.bf1.yahoo.com) (98.139.212.189)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Apr 2012 08:25:06 -0000
Received: from [98.139.212.144] by nm30.bullet.mail.bf1.yahoo.com with NNFMP;
	17 Apr 2012 08:25:05 -0000
Received: from [98.139.212.196] by tm1.bullet.mail.bf1.yahoo.com with NNFMP;
	17 Apr 2012 08:25:05 -0000
Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP;
	17 Apr 2012 08:25:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 382096.69382.bm@omp1005.mail.bf1.yahoo.com
Received: (qmail 45235 invoked by uid 60001); 17 Apr 2012 08:25:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334651105; bh=kLyRD6EdCAD4L8VmVq8nwseRrZx0MPLLazl2NzXnalw=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=X0REEjOB7ZBPNmjtHx32urOuxUsDuMDKNkYpQHobMWrsldUGoSIG4TIfX9g80hummL2l422DjJ4m+UyIf6UTsOSSYl2x7S2eW4b6/UxoAXVSkwqyjdfVbycN0ZoFMR+X5+h9JXqmg/pbFd/ZWbnpV4pg8brrOdKPTR/EyT4M2eQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=HAp9AEifoTQ7B9c+VGSHBKwmQUP/R77FHMsl9Y+vjwxGOTepv92CshNePhDNLABMzyb8PBN6ef1b+BqYngBEbd/pyu/BNUjiXWHl8f2swa6LrDO8K/CcMF2HEAOHVrLZfZJdrLTT/nqP524wE+Oa3BTTmOSgcGKeh/3xe2QhVeM=;
X-YMail-OSG: 3MeficoVM1lEQNSBwaOZcSv465GIJWdGzc6uqFzsOD3XXqu
	xRl1vlND1nPNDctwMuWloL4OM3..CihmXbQ3tsr9C0N5rZ0v1MRowzJE1WIW
	DgkIDibFTQPhI3.0G0iHB5wkLS0PxAn4_E4w448nwzFRM5EmM9w7vHZUD1bm
	v92Ey0SG4yCKdVhxi3yGYhFXiT7u8xmX1rOz8sGuwbZpAxQLwPRbOxN8oHUy
	MimvwD4BMkQwCfE4bYhmcMcEdyE8APeUtHoVRnJHWmUV4PjCoLt2uek_y6iU
	k9gzY3dnV6_Fm3NitM9yj34X6JJbC5NNQCM1P5iMbuNPYtCfxE..QInUqqFW
	K4rKUXuN0kq1DuAvQYwLUHGtSpsaviHiFvJwK5JuKWyDGmOvZ6EShmlDvd6a
	vyXWGW73Ki0Ygj5wB.RaLuv2fY4ag56f._Axpgn_AOLdXloP3UbB1p6UlGcZ
	7gTVS9aeLHTFYJjsZEqdPdzqkSHFssyAtU8QxMuMiiicnNSyHZyjfAAJvBHY
	wEoAQFU4f53FK2SxGjjc15IG6kz6L4FxjSn5zls2E5aG.R4ep_nt6D6EYXmP
	V43lkl.0mG7UZm86BcbCwqz.Ghe38zzAZHYgrW_gOjeI-
Received: from [95.81.88.23] by web161504.mail.bf1.yahoo.com via HTTP;
	Tue, 17 Apr 2012 01:25:05 PDT
X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979
Message-ID: <1334651105.42763.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Date: Tue, 17 Apr 2012 01:25:05 -0700 (PDT)
From: Javanshir Farzin <j.farzin@yahoo.com>
To: xen-devel@lists.xensource.com, Xen-users@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] xen live migration is doing but with problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2039632552603854555=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2039632552603854555==
Content-Type: multipart/alternative; boundary="1835785293-1546991667-1334651105=:42763"

--1835785293-1546991667-1334651105=:42763
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

HI,
I compile and build xen 4.1.2 and kernel 3.0.23 from source on ubuntu 11.10=
.
with xm command (xm migrate --live my_vm host2 ) my virtual machine migrate=
 from host1 to host2 successfully, after migration is done, I use (xm list)=
 in host 2 and I=A0 can see my_vm in host2 virtual machines list while it i=
s running .it disappear from host1 virtual machines list.
I=A0 know if migration is successful then some details such as
Saving memory pages: iter 1
1: sent 28847, skipped 3921, delta .....
must be=A0 appeared in my xend.log.but when I see xend.log below messages a=
ppear.

=0A=0A[2012-04-17=0A01:52:07 26453] DEBUG (XendDomainInfo:2498) XendDomainI=
nfo.constructDomain
=0A[2012-04-17 01:52:07 26453] DEBUG (balloon:187) Balloon: 538500 KiB free=
; need=0A16384; done.
=0A[2012-04-17 01:52:07 26453] DEBUG (XendDomain:476) Adding Domain: 7
=0A[2012-04-17 01:52:07 26453] DEBUG (XendDomainInfo:3420) Storing VM detai=
ls:=0A{'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '5=
', 'uuid':=0A'50012590-62ac-0666-115d-91bef70f1cc8', 'on_reboot': 'restart'=
, 'start_time':=0A'1334608987.7', 'on_poweroff': 'destroy', 'bootloader_arg=
s': '',=0A'on_xend_start': 'ignore', 'on_crash': 'restart', 'xend/restart_c=
ount': '0',=0A'vcpus': '1', 'vcpu_avail': '1', 'bootloader': '', 'image': "=
(hvm (kernel=0A'') (superpages 0) (videoram 4) (hpet 0) (stdvga 0) (loader=
=0A/usr/lib/xen/boot/hvmloader) (xen_platform_pci 1) (opengl 1) (rtc_timeof=
fset 0)=0A(pci ()) (hap 1) (localtime 0) (timer_mode 1) (pci_msitranslate 1=
) (oos 1)=0A(apic 1) (sdl 0) (display :0.0) (vpt_align 1) (serial pty) (vnc=
unused 1) (boot=0Ac) (pae 1) (viridian 0) (acpi 1) (vnc 1) (nographic 0) (n=
omigrate 0) (usb 0)=0A(tsc_mode 0) (guest_os_type default) (device_model /u=
sr/lib/xen/bin/qemu-dm)=0A(pci_power_mgmt 0) (xauthority /root/.Xauthority)=
 (isa 0) (notes (SUSPEND_CANCEL=0A1)))", 'name': 'ubuntu'}
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: con=
sole :=0A{'protocol': 'vt100', 'location': '3', 'uuid':=0A'743e2e7c-9c5b-37=
86-bb47-d95f54e85cfd'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend':=0A'/local/domain/0/backe=
nd/console/7/0'} to /local/domain/7/device/console/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'domain': 'ubuntu', 'frontend': '/local/domain/7/device/console/0', =
'uuid':=0A'743e2e7c-9c5b-3786-bb47-d95f54e85cfd', 'frontend-id': '7', 'stat=
e': '1',=0A'location': '3', 'online': '1', 'protocol': 'vt100'} to=0A/local=
/domain/0/backend/console/7/0.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vfb=
 :=0A{'vncunused': '1', 'other_config': {'vncunused': '1', 'vnc': '1'}, 'vn=
c': '1',=0A'uuid': 'bd8a739a-9a08-ee89-fe7e-547e721fecb0', 'location': '127=
.0.0.1:5900'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend=
/vfb/7/0'}=0Ato /local/domain/7/device/vfb/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'vncunused': '1', 'domain': 'ubuntu', 'frontend': '/local/domain/7/d=
evice/vfb/0',=0A'uuid': 'bd8a739a-9a08-ee89-fe7e-547e721fecb0', 'frontend-i=
d': '7', 'state':=0A'1', 'location': '127.0.0.1:5900', 'online': '1', 'vnc'=
: '1'} to=0A/local/domain/0/backend/vfb/7/0.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vbd=
 :=0A{'uuid': '5ae36766-81b1-791e-585d-4a653611923b', 'bootable': 1, 'drive=
r':=0A'paravirtualised', 'dev': 'hda:disk', 'uname':=0A'file:/var/lib/libvi=
rt/images/ubuntu.img', 'mode': 'w', 'VDI': '', 'backend':=0A'0'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'backend-id': '0', 'virtual-device': '768', 'device-type': 'disk', '=
state':=0A'1', 'backend': '/local/domain/0/backend/vbd/7/768'} to=0A/local/=
domain/7/device/vbd/768.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'domain': 'ubuntu', 'frontend': '/local/domain/7/device/vbd/768', 'u=
uid':=0A'5ae36766-81b1-791e-585d-4a653611923b', 'bootable': '1', 'dev': 'hd=
a', 'state':=0A'1', 'params': '/var/lib/libvirt/images/ubuntu.img', 'mode':=
 'w', 'online':=0A'1', 'frontend-id': '7', 'type': 'file'} to /local/domain=
/0/backend/vbd/7/768.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vbd=
 :=0A{'uuid': 'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': 0, 'drive=
r':=0A'paravirtualised', 'dev': 'hdc:cdrom', 'uname': 'phy:/dev/cdrom', 'mo=
de': 'r',=0A'VDI': '', 'backend': '0'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'backend-id': '0', 'virtual-device': '5632', 'device-type': 'cdrom',=
 'state':=0A'1', 'backend': '/local/domain/0/backend/vbd/7/5632'} to=0A/loc=
al/domain/7/device/vbd/5632.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'domain': 'ubuntu', 'frontend': '/local/domain/7/device/vbd/5632', '=
uuid':=0A'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': '0', 'dev': 'h=
dc', 'state':=0A'1', 'params': '/dev/cdrom', 'mode': 'r', 'online': '1', 'f=
rontend-id': '7',=0A'type': 'phy'} to /local/domain/0/backend/vbd/7/5632.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vif=
 :=0A{'bridge': 'xenbr0', 'uuid': '08cb242e-758e-8284-4250-34d2bd318338', '=
script':=0A'/etc/xen/scripts/vif-bridge', 'mac': '00:16:3e:60:30:b1', 'type=
': 'ioemu',=0A'backend': '0'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend=
/vif/7/0'}=0Ato /local/domain/7/device/vif/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'bridge': 'xenbr0', 'domain': 'ubuntu', 'handle': '0', 'uuid':=0A'08=
cb242e-758e-8284-4250-34d2bd318338', 'script':=0A'/etc/xen/scripts/vif-brid=
ge', 'mac': '00:16:3e:60:30:b1', 'frontend-id': '7',=0A'state': '1', 'onlin=
e': '1', 'frontend': '/local/domain/7/device/vif/0',=0A'type': 'ioemu'} to =
/local/domain/0/backend/vif/7/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (XendDomainInfo:1794) Storing domain d=
etails:=0A{'console/port': '3', 'description': '', 'console/limit': '104857=
6',=0A'image/suspend-cancel': '1', 'domid': '7', 'vm':=0A'/vm/50012590-62ac=
-0666-115d-91bef70f1cc8', 'cpu/0/availability': 'online',=0A'memory/target'=
: '524288', 'control/platform-feature-multiprocessor-suspend':=0A'1', 'cons=
ole/type': 'ioemu', 'store/port': '2', 'name': 'ubuntu'}
=0A[2012-04-17 01:52:07 26453] INFO (XendCheckpoint:260) restore hvm domain=
 7,=0Aapic=3D1, pae=3D1
=0A[2012-04-17 01:52:07 26453] DEBUG (image:339) No VNC passwd configured f=
or vfb=0Aaccess
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: boot, val: c
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: fda, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: fdb, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: soundhw, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: localtime, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: serial, val: ['pty']
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: std-vga, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: isa, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: acpi, val: 1
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: usb, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: usbdevice, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: gfx_passthru, val: N=
one
=0A[2012-04-17 01:52:07 26453] INFO (image:822) Need to create platform=0Ad=
evice.[domid:7]
=0A[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:278) restore:shadow=3D=
0x5,=0A_static_max=3D0x20000000, _static_min=3D0x0,=20
=0A[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:305) [xc_restore]:=0A/=
usr/lib/xen/bin/xc_restore 26 7 2 3 1 1 1 0
=0A[2012-04-17 01:52:16 26453] DEBUG (XendCheckpoint:394) store-mfn 1044476
=0A[2012-04-17 01:52:16 26453] DEBUG (XendDomainInfo:3010)=0AXendDomainInfo=
.completeRestore
=0A[2012-04-17 01:52:16 26453] DEBUG (image:339) No VNC passwd configured f=
or vfb=0Aaccess
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: boot, val: c
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fda, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fdb, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: soundhw, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: localtime, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: serial, val: ['pty']
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: std-vga, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: isa, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: acpi, val: 1
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usb, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usbdevice, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: gfx_passthru, val: N=
one
=0A[2012-04-17 01:52:17 26453] INFO (image:822) Need to create platform=0Ad=
evice.[domid:7]
=0A[2012-04-17 01:52:17 26453] INFO (image:418) spawning device models:=0A/=
usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '7',=0A'-domain-=
name', 'ubuntu', '-videoram', '4', '-vnc', '127.0.0.1:0',=0A'-vncunused', '=
-vcpus', '1', '-vcpu_avail', '0x1L', '-boot', 'c', '-serial',=0A'pty', '-ac=
pi', '-net', 'nic,vlan=3D1,macaddr=3D00:16:3e:60:30:b1,model=3Drtl8139',=0A=
'-net', 'tap,vlan=3D1,ifname=3Dtap7.0,bridge=3Dxenbr0', '-M', 'xenfv', '-lo=
advm',=0A'/var/lib/xen/qemu-resume.7']
=0A[2012-04-17 01:52:17 26453] INFO (image:467) device model pid: 26903
=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1794) Storing domain d=
etails:=0A{'console/port': '3', 'description': '', 'console/limit': '104857=
6',=0A'store/port': '2', 'vm': '/vm/50012590-62ac-0666-115d-91bef70f1cc8', =
'domid':=0A'7', 'image/suspend-cancel': '1', 'cpu/0/availability': 'online'=
,=0A'memory/target': '524288', 'control/platform-feature-multiprocessor-sus=
pend':=0A'1', 'store/ring-ref': '1044476', 'console/type': 'ioemu', 'name':=
 'ubuntu'}
=0A[2012-04-17 01:52:17 26453] INFO (image:590) waiting for sentinel_fifo
=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1881)=0AXendDomainInfo=
.handleShutdownWatch
=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:3023)=0AXendDomainInfo=
.completeRestore done
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s tap2.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vif.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 0.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatusCallb=
ack=0A/local/domain/0/backend/vif/7/0/hotplug-status.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallb=
ack 1.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vkbd.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s=0Aioports.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s tap.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vif2.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s=0Aconsole.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 0.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s=0Avscsi.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vbd.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 768.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatusCallb=
ack=0A/local/domain/0/backend/vbd/7/768/hotplug-status.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallb=
ack 1.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 5632.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatusCallb=
ack=0A/local/domain/0/backend/vbd/7/5632/hotplug-status.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallb=
ack 1.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s irq.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vfb.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s pci.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vusb.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vtpm.
=0A[2012-04-17 01:54:33 26453] DEBUG (XendCheckpoint:124) [xc_save]:=0A/usr=
/lib/xen/bin/xc_save 26 7 0 0 5
=0A[2012-04-17 01:54:33 26453] INFO (XendCheckpoint:423) xc_save: failed to=
 get=0Athe suspend evtchn port
=0A[2012-04-17 01:54:33 26453] INFO (XendCheckpoint:423)=20
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:394) suspend
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:127) In saveInputHandl=
er=0Asuspend
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:129) Suspending 7 ...
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:524) XendDomainInfo.sh=
utdown(suspend)
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1881)=0AXendDomainInfo=
.handleShutdownWatch
=0A[2012-04-17 01:55:04 26453] INFO (XendDomainInfo:541) HVM save:remote sh=
utdown=0Adom 7!
=0A[2012-04-17 01:55:04 26453] INFO (XendCheckpoint:135) Domain 7 suspended=
.
=0A[2012-04-17 01:55:04 26453] INFO (XendDomainInfo:2078) Domain has shutdo=
wn:=0Aname=3Dmigrating-ubuntu id=3D7 reason=3Dsuspend.
=0A[2012-04-17 01:55:04 26453] INFO (image:538) signalDeviceModel:restore d=
m state=0Ato running
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:144) Written done
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:3071) XendDomainInfo.d=
estroy:=0Adomid=3D7
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2401) Destroying devic=
e model
=0A[2012-04-17 01:55:04 26453] INFO (image:615) migrating-ubuntu device mod=
el=0Aterminated
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2408) Releasing device=
s
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vif/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D vif, device =3D vif/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing console=
/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D console, device =3D console/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vbd/768
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D vbd, device =3D vbd/768
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vbd/563=
2
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D vbd, device =3D vbd/5632
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vfb/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276) XendDomainInfo.d=
estroyDevice:=0AdeviceClass =3D vfb, device =3D vfb/0
=0A[2012-04-17 02:14:21 26453] DEBUG (SrvServer:77) SrvServer.cleanup()
=0A[2012-04-17 02:14:21 26453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanu=
p()
=0A[2012-04-17 02:14:21 26453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanu=
p()
=0A[2012-04-17 02:14:21 26453] DEBUG (XendDomain:644) cleanup_domains
=0A[2012-04-17 02:14:21 26452] INFO (SrvDaemon:220) Xend exited with status=
 0.
=0A=A0=0A=0A=A0=0A=0A

Javanshir Farzin
--1835785293-1546991667-1334651105=:42763
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><font size=3D"4"><span style=3D"font-family: =
courier,monaco,monospace,sans-serif; font-weight: bold;">HI,</span><br styl=
e=3D"font-family: courier,monaco,monospace,sans-serif; font-weight: bold;">=
<span style=3D"font-family: courier,monaco,monospace,sans-serif; font-weigh=
t: bold;">I compile and build xen 4.1.2 and kernel 3.0.23 from source on ub=
untu 11.10.</span><br style=3D"font-family: courier,monaco,monospace,sans-s=
erif; font-weight: bold;"><span style=3D"font-family: courier,monaco,monosp=
ace,sans-serif; font-weight: bold;">with xm command (xm migrate --live my_v=
m host2 ) my virtual machine migrate from host1 to host2 successfully, afte=
r migration is done, I use (xm list) in host 2 and I&nbsp; can see my_vm in=
 host2 virtual machines list while it is running .it disappear from host1 v=
irtual machines list.</span><br style=3D"font-family: courier,monaco,monosp=
ace,sans-serif;
 font-weight: bold;"><span style=3D"font-family: courier,monaco,monospace,s=
ans-serif; font-weight: bold;">I&nbsp; know if migration is successful then=
 some details such as</span><br></font><pre><font size=3D"3"><span style=3D=
"font-family: courier,monaco,monospace,sans-serif;">Saving memory pages: it=
er 1</span><br style=3D"font-family: courier,monaco,monospace,sans-serif;">=
</font><font size=3D"4"><font size=3D"3"><span style=3D"font-family: courie=
r,monaco,monospace,sans-serif;">1: sent 28847, skipped 3921, delta .....</s=
pan></font><br></font></pre><font style=3D"font-family: courier,monaco,mono=
space,sans-serif; font-weight: bold;" size=3D"4">must be&nbsp; appeared in =
my xend.log.</font><font style=3D"font-family: courier,monaco,monospace,san=
s-serif; font-weight: bold;" size=3D"4">but when I see xend.log below messa=
ges appear</font><font style=3D"font-family: courier,monaco,monospace,sans-=
serif; font-weight: bold;" size=3D"4">.</font><br><br><!--[if gte mso 9]><x=
ml>=0A <o:OfficeDocumentSettings>=0A  <o:AllowPNG/>=0A </o:OfficeDocumentSe=
ttings>=0A</xml><![endif][if gte mso 9]><xml>=0A <w:WordDocument>=0A  <w:Vi=
ew>Normal</w:View>=0A  <w:Zoom>0</w:Zoom>=0A  <w:TrackMoves/>=0A  <w:TrackF=
ormatting/>=0A  <w:PunctuationKerning/>=0A  <w:ValidateAgainstSchemas/>=0A =
 <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>=0A  <w:IgnoreMixedContent>f=
alse</w:IgnoreMixedContent>=0A  <w:AlwaysShowPlaceholderText>false</w:Alway=
sShowPlaceholderText>=0A  <w:DoNotPromoteQF/>=0A  <w:LidThemeOther>EN-US</w=
:LidThemeOther>=0A  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>=0A  <w:LidThe=
meComplexScript>AR-SA</w:LidThemeComplexScript>=0A  <w:Compatibility>=0A   =
<w:BreakWrappedTables/>=0A   <w:SnapToGridInCell/>=0A   <w:WrapTextWithPunc=
t/>=0A   <w:UseAsianBreakRules/>=0A   <w:DontGrowAutofit/>=0A   <w:SplitPgB=
reakAndParaMark/>=0A   <w:EnableOpenTypeKerning/>=0A   <w:DontFlipMirrorInd=
ents/>=0A   <w:OverrideTableStyleHps/>=0A  </w:Compatibility>=0A  <m:mathPr=
>=0A   <m:mathFont m:val=3D"Cambria Math"/>=0A   <m:brkBin m:val=3D"before"=
/>=0A   <m:brkBinSub m:val=3D"&#45;-"/>=0A   <m:smallFrac m:val=3D"off"/>=
=0A   <m:dispDef/>=0A   <m:lMargin m:val=3D"0"/>=0A   <m:rMargin m:val=3D"0=
"/>=0A   <m:defJc m:val=3D"centerGroup"/>=0A   <m:wrapIndent m:val=3D"1440"=
/>=0A   <m:intLim m:val=3D"subSup"/>=0A   <m:naryLim m:val=3D"undOvr"/>=0A =
 </m:mathPr></w:WordDocument>=0A</xml><![endif][if gte mso 9]><xml>=0A <w:L=
atentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"=0A  DefSemi=
Hidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"=0A  LatentStyleCoun=
t=3D"267">=0A  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"head=
ing 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"tru=
e" Name=3D"heading 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9"=
 QFormat=3D"true" Name=3D"heading 4"/>=0A  <w:LsdException Locked=3D"false"=
 Priority=3D"9" QFormat=3D"true" Name=3D"heading 5"/>=0A  <w:LsdException L=
ocked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"heading 6"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"head=
ing 7"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"tru=
e" Name=3D"heading 8"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9"=
 QFormat=3D"true" Name=3D"heading 9"/>=0A  <w:LsdException Locked=3D"false"=
 Priority=3D"39" Name=3D"toc 1"/>=0A  <w:LsdException Locked=3D"false" Prio=
rity=3D"39" Name=3D"toc 2"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"39" Name=3D"toc 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"3=
9" Name=3D"toc 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Na=
me=3D"toc 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D=
"toc 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc =
7"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>=0A  =
<w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" Name=3D"c=
aption"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default Paragr=
aph Font"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"=
/>=0A  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false=
"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>=0A  <w:L=
sdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"=0A   Unhi=
deWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>=0A  <w:LsdExcepti=
on Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"=0A   UnhideWhenUse=
d=3D"false" Name=3D"Table Grid"/>=0A  <w:LsdException Locked=3D"false" Unhi=
deWhenUsed=3D"false" Name=3D"Placeholder Text"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"1" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false=
" QFormat=3D"true" Name=3D"No Spacing"/>=0A  <w:LsdException Locked=3D"fals=
e" Priority=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Light Shading"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"61" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light List"/>=0A =
 <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=0A  =
 UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"63" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Medium Shading 1"/>=0A  <w:LsdException Locked=3D"false" Priorit=
y=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium =
Shading 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidde=
n=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>=0A  <w:L=
sdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=0A   Unhi=
deWhenUsed=3D"false" Name=3D"Medium List 2"/>=0A  <w:LsdException Locked=3D=
"false" Priority=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" =
Name=3D"Medium Grid 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"6=
8" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2=
"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"fals=
e"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>=0A  <w:LsdExcepti=
on Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   UnhideWhenUse=
d=3D"false" Name=3D"Dark List"/>=0A  <w:LsdException Locked=3D"false" Prior=
ity=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Color=
ful Shading"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHid=
den=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=0A   Un=
hideWhenUsed=3D"false" Name=3D"Colorful Grid"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Light Shading Accent 1"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"61" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"L=
ight List Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"62" =
SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accen=
t 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"f=
alse"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>=0A=
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=0A =
  UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>=0A  <w:LsdE=
xception Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=0A   UnhideW=
henUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>=0A  <w:LsdException Loc=
ked=3D"false" UnhideWhenUsed=3D"false" Name=3D"Revision"/>=0A  <w:LsdExcept=
ion Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"=0A   UnhideWhenUs=
ed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>=0A  <w:LsdException=
 Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" QFormat=3D"true" Name=3D"Quote"/>=0A  <w:LsdException Locked=3D"=
false" Priority=3D"30" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Q=
Format=3D"true" Name=3D"Intense Quote"/>=0A  <w:LsdException Locked=3D"fals=
e" Priority=3D"66" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Medium List 2 Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium G=
rid 1 Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"68" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent=
 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   Un=
hideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Colorful Shading Accent 1"/>=0A  <w:LsdException Locked=3D"f=
alse" Priority=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Na=
me=3D"Colorful List Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priori=
ty=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorf=
ul Grid Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"60" Se=
miHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Shading Acce=
nt 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"=
false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>=0A  <w:=
LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=0A   Unh=
ideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"63" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Medium Shading 1 Accent 2"/>=0A  <w:LsdException Locked=3D"f=
alse" Priority=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Na=
me=3D"Medium Shading 2 Accent 2"/>=0A  <w:LsdException Locked=3D"false" Pri=
ority=3D"65" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Med=
ium List 1 Accent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"66"=
 SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 A=
ccent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Dark List Accent 2"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"C=
olorful Shading Accent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful=
 List Accent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"73" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent=
 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=0A   Un=
hideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>=0A  <w:LsdException L=
ocked=3D"false" Priority=3D"62" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D=
"false" Name=3D"Light Grid Accent 3"/>=0A  <w:LsdException Locked=3D"false"=
 Priority=3D"63" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D=
"Medium Shading 1 Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium S=
hading 2 Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"65" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Acc=
ent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D=
"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>=0A =
 <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=0A  =
 UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>=0A  <w:LsdExcep=
tion Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=0A   UnhideWhenU=
sed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"69" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Medium Grid 3 Accent 3"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"70" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"D=
ark List Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"71" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading =
Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"61" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Light List Accent 4"/>=0A  <w:LsdException Locked=3D"false" =
Priority=3D"62" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"=
Light Grid Accent 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"63"=
 SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading =
1 Accent 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidd=
en=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent =
4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"fal=
se"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>=0A  <w:=
LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=0A   Unh=
ideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>=0A  <w:LsdException=
 Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" Name=3D"Medium Grid 1 Accent 4"/>=0A  <w:LsdException Locked=3D"=
false" Priority=3D"68" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" N=
ame=3D"Medium Grid 2 Accent 4"/>=0A  <w:LsdException Locked=3D"false" Prior=
ity=3D"69" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Mediu=
m Grid 3 Accent 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"70" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent =
4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"fal=
se"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>=0A  =
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=0A   =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>=0A  <w:LsdExcept=
ion Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUs=
ed=3D"false" Name=3D"Colorful Grid Accent 4"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Light Shading Accent 5"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"61" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"L=
ight List Accent 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"62" =
SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accen=
t 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"f=
alse"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>=0A=
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=0A =
  UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>=0A  <w:LsdE=
xception Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=0A   UnhideW=
henUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>=0A  <w:LsdException Loc=
ked=3D"false" Priority=3D"66" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"f=
alse" Name=3D"Medium List 2 Accent 5"/>=0A  <w:LsdException Locked=3D"false=
" Priority=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Medium Grid 1 Accent 5"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"68" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium G=
rid 2 Accent 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"69" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent=
 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>=0A  <w:LsdException=
 Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" Name=3D"Colorful List Accent 5"/>=0A  <w:LsdException Locked=3D"=
false" Priority=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" N=
ame=3D"Colorful Grid Accent 5"/>=0A  <w:LsdException Locked=3D"false" Prior=
ity=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light=
 Shading Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"61" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light List Accent=
 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>=0A  <w:Ls=
dException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=0A   Unhid=
eWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>=0A  <w:LsdExceptio=
n Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" Name=3D"Medium Shading 2 Accent 6"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"65" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Medium List 1 Accent 6"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"66" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"M=
edium List 2 Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"6=
7" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1=
 Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidde=
n=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Dark List Accent 6"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Colorful Shading Accent 6"/>=0A  <w:LsdException Locked=3D"false=
" Priority=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Colorful List Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful=
 Grid Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"19" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Sub=
tle Emphasis"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHi=
dden=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Inten=
se Emphasis"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHid=
den=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle=
 Reference"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidd=
en=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense=
 Reference"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidd=
en=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Ti=
tle"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliog=
raphy"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"tr=
ue" Name=3D"TOC Heading"/>=0A </w:LatentStyles>=0A</xml><![endif][if gte ms=
o 10]>=0A<style>=0A /* Style Definitions */=0A table.MsoNormalTable=0A=09{m=
so-style-name:"Table Normal";=0A=09mso-tstyle-rowband-size:0;=0A=09mso-tsty=
le-colband-size:0;=0A=09mso-style-noshow:yes;=0A=09mso-style-priority:99;=
=0A=09mso-style-parent:"";=0A=09mso-padding-alt:0cm 5.4pt 0cm 5.4pt;=0A=09m=
so-para-margin-top:0cm;=0A=09mso-para-margin-right:0cm;=0A=09mso-para-margi=
n-bottom:10.0pt;=0A=09mso-para-margin-left:0cm;=0A=09line-height:115%;=0A=
=09mso-pagination:widow-orphan;=0A=09font-size:11.0pt;=0A=09font-family:"Ca=
libri","sans-serif";=0A=09mso-ascii-font-family:Calibri;=0A=09mso-ascii-the=
me-font:minor-latin;=0A=09mso-hansi-font-family:Calibri;=0A=09mso-hansi-the=
me-font:minor-latin;=0A=09mso-bidi-font-family:Arial;=0A=09mso-bidi-theme-f=
ont:minor-bidi;}=0A</style>=0A<![endif]-->=0A=0A<p class=3D"MsoNormal" styl=
e=3D"margin-bottom:0cm;margin-bottom:.0001pt;line-height:=0Anormal"><span s=
tyle=3D"font-size:10.5pt;font-family:&quot;Courier New&quot;">[2012-04-17=
=0A01:52:07 26453] DEBUG (XendDomainInfo:2498) XendDomainInfo.constructDoma=
in<br>=0A[2012-04-17 01:52:07 26453] DEBUG (balloon:187) Balloon: 538500 Ki=
B free; need=0A16384; done.<br>=0A[2012-04-17 01:52:07 26453] DEBUG (XendDo=
main:476) Adding Domain: 7<br>=0A[2012-04-17 01:52:07 26453] DEBUG (XendDom=
ainInfo:3420) Storing VM details:=0A{'on_xend_stop': 'ignore', 'pool_name':=
 'Pool-0', 'shadow_memory': '5', 'uuid':=0A'50012590-62ac-0666-115d-91bef70=
f1cc8', 'on_reboot': 'restart', 'start_time':=0A'1334608987.7', 'on_powerof=
f': 'destroy', 'bootloader_args': '',=0A'on_xend_start': 'ignore', 'on_cras=
h': 'restart', 'xend/restart_count': '0',=0A'vcpus': '1', 'vcpu_avail': '1'=
, 'bootloader': '', 'image': "(hvm (kernel=0A'') (superpages 0) (videoram 4=
) (hpet 0) (stdvga 0) (loader=0A/usr/lib/xen/boot/hvmloader) (xen_platform_=
pci 1) (opengl 1) (rtc_timeoffset 0)=0A(pci ()) (hap 1) (localtime 0) (time=
r_mode 1) (pci_msitranslate 1) (oos 1)=0A(apic 1) (sdl 0) (display :0.0) (v=
pt_align 1) (serial pty) (vncunused 1) (boot=0Ac) (pae 1) (viridian 0) (acp=
i 1) (vnc 1) (nographic 0) (nomigrate 0) (usb 0)=0A(tsc_mode 0) (guest_os_t=
ype default) (device_model /usr/lib/xen/bin/qemu-dm)=0A(pci_power_mgmt 0) (=
xauthority /root/.Xauthority) (isa 0) (notes (SUSPEND_CANCEL=0A1)))", 'name=
': 'ubuntu'}<br>=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) c=
reateDevice: console :=0A{'protocol': 'vt100', 'location': '3', 'uuid':=0A'=
743e2e7c-9c5b-3786-bb47-d95f54e85cfd'}<br>=0A[2012-04-17 01:52:07 26453] DE=
BUG (DevController:95) DevController: writing=0A{'state': '1', 'backend-id'=
: '0', 'backend':=0A'/local/domain/0/backend/console/7/0'} to /local/domain=
/7/device/console/0.<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevController=
:97) DevController: writing=0A{'domain': 'ubuntu', 'frontend': '/local/doma=
in/7/device/console/0', 'uuid':=0A'743e2e7c-9c5b-3786-bb47-d95f54e85cfd', '=
frontend-id': '7', 'state': '1',=0A'location': '3', 'online': '1', 'protoco=
l': 'vt100'} to=0A/local/domain/0/backend/console/7/0.<br>=0A[2012-04-17 01=
:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vfb :=0A{'vncunused'=
: '1', 'other_config': {'vncunused': '1', 'vnc': '1'}, 'vnc': '1',=0A'uuid'=
: 'bd8a739a-9a08-ee89-fe7e-547e721fecb0', 'location': '127.0.0.1:5900'}<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend=
/vfb/7/0'}=0Ato /local/domain/7/device/vfb/0.<br>=0A[2012-04-17 01:52:07 26=
453] DEBUG (DevController:97) DevController: writing=0A{'vncunused': '1', '=
domain': 'ubuntu', 'frontend': '/local/domain/7/device/vfb/0',=0A'uuid': 'b=
d8a739a-9a08-ee89-fe7e-547e721fecb0', 'frontend-id': '7', 'state':=0A'1', '=
location': '127.0.0.1:5900', 'online': '1', 'vnc': '1'} to=0A/local/domain/=
0/backend/vfb/7/0.<br>=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2=
357) createDevice: vbd :=0A{'uuid': '5ae36766-81b1-791e-585d-4a653611923b',=
 'bootable': 1, 'driver':=0A'paravirtualised', 'dev': 'hda:disk', 'uname':=
=0A'file:/var/lib/libvirt/images/ubuntu.img', 'mode': 'w', 'VDI': '', 'back=
end':=0A'0'}<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) Dev=
Controller: writing=0A{'backend-id': '0', 'virtual-device': '768', 'device-=
type': 'disk', 'state':=0A'1', 'backend': '/local/domain/0/backend/vbd/7/76=
8'} to=0A/local/domain/7/device/vbd/768.<br>=0A[2012-04-17 01:52:07 26453] =
DEBUG (DevController:97) DevController: writing=0A{'domain': 'ubuntu', 'fro=
ntend': '/local/domain/7/device/vbd/768', 'uuid':=0A'5ae36766-81b1-791e-585=
d-4a653611923b', 'bootable': '1', 'dev': 'hda', 'state':=0A'1', 'params': '=
/var/lib/libvirt/images/ubuntu.img', 'mode': 'w', 'online':=0A'1', 'fronten=
d-id': '7', 'type': 'file'} to /local/domain/0/backend/vbd/7/768.<br>=0A[20=
12-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vbd :=0A{=
'uuid': 'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': 0, 'driver':=0A=
'paravirtualised', 'dev': 'hdc:cdrom', 'uname': 'phy:/dev/cdrom', 'mode': '=
r',=0A'VDI': '', 'backend': '0'}<br>=0A[2012-04-17 01:52:07 26453] DEBUG (D=
evController:95) DevController: writing=0A{'backend-id': '0', 'virtual-devi=
ce': '5632', 'device-type': 'cdrom', 'state':=0A'1', 'backend': '/local/dom=
ain/0/backend/vbd/7/5632'} to=0A/local/domain/7/device/vbd/5632.<br>=0A[201=
2-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writing=0A{=
'domain': 'ubuntu', 'frontend': '/local/domain/7/device/vbd/5632', 'uuid':=
=0A'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': '0', 'dev': 'hdc', '=
state':=0A'1', 'params': '/dev/cdrom', 'mode': 'r', 'online': '1', 'fronten=
d-id': '7',=0A'type': 'phy'} to /local/domain/0/backend/vbd/7/5632.<br>=0A[=
2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vif :=
=0A{'bridge': 'xenbr0', 'uuid': '08cb242e-758e-8284-4250-34d2bd318338', 'sc=
ript':=0A'/etc/xen/scripts/vif-bridge', 'mac': '00:16:3e:60:30:b1', 'type':=
 'ioemu',=0A'backend': '0'}<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevCon=
troller:95) DevController: writing=0A{'state': '1', 'backend-id': '0', 'bac=
kend': '/local/domain/0/backend/vif/7/0'}=0Ato /local/domain/7/device/vif/0=
.<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController:=
 writing=0A{'bridge': 'xenbr0', 'domain': 'ubuntu', 'handle': '0', 'uuid':=
=0A'08cb242e-758e-8284-4250-34d2bd318338', 'script':=0A'/etc/xen/scripts/vi=
f-bridge', 'mac': '00:16:3e:60:30:b1', 'frontend-id': '7',=0A'state': '1', =
'online': '1', 'frontend': '/local/domain/7/device/vif/0',=0A'type': 'ioemu=
'} to /local/domain/0/backend/vif/7/0.<br>=0A[2012-04-17 01:52:07 26453] DE=
BUG (XendDomainInfo:1794) Storing domain details:=0A{'console/port': '3', '=
description': '', 'console/limit': '1048576',=0A'image/suspend-cancel': '1'=
, 'domid': '7', 'vm':=0A'/vm/50012590-62ac-0666-115d-91bef70f1cc8', 'cpu/0/=
availability': 'online',=0A'memory/target': '524288', 'control/platform-fea=
ture-multiprocessor-suspend':=0A'1', 'console/type': 'ioemu', 'store/port':=
 '2', 'name': 'ubuntu'}<br>=0A[2012-04-17 01:52:07 26453] INFO (XendCheckpo=
int:260) restore hvm domain 7,=0Aapic=3D1, pae=3D1<br>=0A[2012-04-17 01:52:=
07 26453] DEBUG (image:339) No VNC passwd configured for vfb=0Aaccess<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: boot, val: c<br>=0A[=
2012-04-17 01:52:07 26453] DEBUG (image:891) args: fda, val: None<br>=0A[20=
12-04-17 01:52:07 26453] DEBUG (image:891) args: fdb, val: None<br>=0A[2012=
-04-17 01:52:07 26453] DEBUG (image:891) args: soundhw, val: None<br>=0A[20=
12-04-17 01:52:07 26453] DEBUG (image:891) args: localtime, val: 0<br>=0A[2=
012-04-17 01:52:07 26453] DEBUG (image:891) args: serial, val: ['pty']<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: std-vga, val: 0<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: isa, val: 0<br>=0A[2=
012-04-17 01:52:07 26453] DEBUG (image:891) args: acpi, val: 1<br>=0A[2012-=
04-17 01:52:07 26453] DEBUG (image:891) args: usb, val: 0<br>=0A[2012-04-17=
 01:52:07 26453] DEBUG (image:891) args: usbdevice, val: None<br>=0A[2012-0=
4-17 01:52:07 26453] DEBUG (image:891) args: gfx_passthru, val: None<br>=0A=
[2012-04-17 01:52:07 26453] INFO (image:822) Need to create platform=0Adevi=
ce.[domid:7]<br>=0A[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:278) r=
estore:shadow=3D0x5,=0A_static_max=3D0x20000000, _static_min=3D0x0, <br>=0A=
[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:305) [xc_restore]:=0A/usr=
/lib/xen/bin/xc_restore 26 7 2 3 1 1 1 0<br>=0A[2012-04-17 01:52:16 26453] =
DEBUG (XendCheckpoint:394) store-mfn 1044476<br>=0A[2012-04-17 01:52:16 264=
53] DEBUG (XendDomainInfo:3010)=0AXendDomainInfo.completeRestore<br>=0A[201=
2-04-17 01:52:16 26453] DEBUG (image:339) No VNC passwd configured for vfb=
=0Aaccess<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: boot, v=
al: c<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fda, val: N=
one<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fdb, val: Non=
e<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: soundhw, val: N=
one<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: localtime, va=
l: 0<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: serial, val:=
 ['pty']<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: std-vga,=
 val: 0<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: isa, val:=
 0<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: acpi, val: 1<b=
r>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usb, val: 0<br>=0A=
[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usbdevice, val: None<br=
>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: gfx_passthru, val: =
None<br>=0A[2012-04-17 01:52:17 26453] INFO (image:822) Need to create plat=
form=0Adevice.[domid:7]<br>=0A[2012-04-17 01:52:17 26453] INFO (image:418) =
spawning device models:=0A/usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-=
dm', '-d', '7',=0A'-domain-name', 'ubuntu', '-videoram', '4', '-vnc', '127.=
0.0.1:0',=0A'-vncunused', '-vcpus', '1', '-vcpu_avail', '0x1L', '-boot', 'c=
', '-serial',=0A'pty', '-acpi', '-net', 'nic,vlan=3D1,macaddr=3D00:16:3e:60=
:30:b1,model=3Drtl8139',=0A'-net', 'tap,vlan=3D1,ifname=3Dtap7.0,bridge=3Dx=
enbr0', '-M', 'xenfv', '-loadvm',=0A'/var/lib/xen/qemu-resume.7']<br>=0A[20=
12-04-17 01:52:17 26453] INFO (image:467) device model pid: 26903<br>=0A[20=
12-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1794) Storing domain details=
:=0A{'console/port': '3', 'description': '', 'console/limit': '1048576',=0A=
'store/port': '2', 'vm': '/vm/50012590-62ac-0666-115d-91bef70f1cc8', 'domid=
':=0A'7', 'image/suspend-cancel': '1', 'cpu/0/availability': 'online',=0A'm=
emory/target': '524288', 'control/platform-feature-multiprocessor-suspend':=
=0A'1', 'store/ring-ref': '1044476', 'console/type': 'ioemu', 'name': 'ubun=
tu'}<br>=0A[2012-04-17 01:52:17 26453] INFO (image:590) waiting for sentine=
l_fifo<br>=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1881)=0AXend=
DomainInfo.handleShutdownWatch<br>=0A[2012-04-17 01:52:17 26453] DEBUG (Xen=
dDomainInfo:3023)=0AXendDomainInfo.completeRestore done<br>=0A[2012-04-17 0=
1:52:17 26453] DEBUG (DevController:139) Waiting for devices tap2.<br>=0A[2=
012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for devices vif=
.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 0=
.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatus=
Callback=0A/local/domain/0/backend/vif/7/0/hotplug-status.<br>=0A[2012-04-1=
7 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallback 1.<br>=0A=
[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for devices v=
kbd.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting fo=
r devices=0Aioports.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController=
:139) Waiting for devices tap.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (Dev=
Controller:139) Waiting for devices vif2.<br>=0A[2012-04-17 01:52:17 26453]=
 DEBUG (DevController:139) Waiting for devices=0Aconsole.<br>=0A[2012-04-17=
 01:52:17 26453] DEBUG (DevController:144) Waiting for 0.<br>=0A[2012-04-17=
 01:52:17 26453] DEBUG (DevController:139) Waiting for devices=0Avscsi.<br>=
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vbd.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting =
for 768.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplu=
gStatusCallback=0A/local/domain/0/backend/vbd/7/768/hotplug-status.<br>=0A[=
2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallback =
1.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for =
5632.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugSt=
atusCallback=0A/local/domain/0/backend/vbd/7/5632/hotplug-status.<br>=0A[20=
12-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallback 1.=
<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for de=
vices irq.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Wait=
ing for devices vfb.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController=
:139) Waiting for devices pci.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (Dev=
Controller:139) Waiting for devices vusb.<br>=0A[2012-04-17 01:52:17 26453]=
 DEBUG (DevController:139) Waiting for devices vtpm.<br>=0A[2012-04-17 01:5=
4:33 26453] DEBUG (XendCheckpoint:124) [xc_save]:=0A/usr/lib/xen/bin/xc_sav=
e 26 7 0 0 5<br>=0A[2012-04-17 01:54:33 26453] INFO (XendCheckpoint:423) xc=
_save: failed to get=0Athe suspend evtchn port<br>=0A[2012-04-17 01:54:33 2=
6453] INFO (XendCheckpoint:423) <br>=0A[2012-04-17 01:55:04 26453] DEBUG (X=
endCheckpoint:394) suspend<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendChe=
ckpoint:127) In saveInputHandler=0Asuspend<br>=0A[2012-04-17 01:55:04 26453=
] DEBUG (XendCheckpoint:129) Suspending 7 ...<br>=0A[2012-04-17 01:55:04 26=
453] DEBUG (XendDomainInfo:524) XendDomainInfo.shutdown(suspend)<br>=0A[201=
2-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1881)=0AXendDomainInfo.handle=
ShutdownWatch<br>=0A[2012-04-17 01:55:04 26453] INFO (XendDomainInfo:541) H=
VM save:remote shutdown=0Adom 7!<br>=0A[2012-04-17 01:55:04 26453] INFO (Xe=
ndCheckpoint:135) Domain 7 suspended.<br>=0A[2012-04-17 01:55:04 26453] INF=
O (XendDomainInfo:2078) Domain has shutdown:=0Aname=3Dmigrating-ubuntu id=
=3D7 reason=3Dsuspend.<br>=0A[2012-04-17 01:55:04 26453] INFO (image:538) s=
ignalDeviceModel:restore dm state=0Ato running<br>=0A[2012-04-17 01:55:04 2=
6453] DEBUG (XendCheckpoint:144) Written done<br>=0A[2012-04-17 01:55:04 26=
453] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy:=0Adomid=3D7<br>=0A=
[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2401) Destroying device m=
odel<br>=0A[2012-04-17 01:55:04 26453] INFO (image:615) migrating-ubuntu de=
vice model=0Aterminated<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomain=
Info:2408) Releasing devices<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendD=
omainInfo:2414) Removing vif/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (Xen=
dDomainInfo:1276)=0AXendDomainInfo.destroyDevice: deviceClass =3D vif, devi=
ce =3D vif/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) =
Removing console/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:=
1276)=0AXendDomainInfo.destroyDevice: deviceClass =3D console, device =3D c=
onsole/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Remo=
ving vbd/768<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=
=0AXendDomainInfo.destroyDevice: deviceClass =3D vbd, device =3D vbd/768<br=
>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vbd/56=
32<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDoma=
inInfo.destroyDevice: deviceClass =3D vbd, device =3D vbd/5632<br>=0A[2012-=
04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vfb/0<br>=0A[201=
2-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyD=
evice:=0AdeviceClass =3D vfb, device =3D vfb/0<br>=0A[2012-04-17 02:14:21 2=
6453] DEBUG (SrvServer:77) SrvServer.cleanup()<br>=0A[2012-04-17 02:14:21 2=
6453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup()<br>=0A[2012-04-17 02:=
14:21 26453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup()<br>=0A[2012-04=
-17 02:14:21 26453] DEBUG (XendDomain:644) cleanup_domains<br>=0A[2012-04-1=
7 02:14:21 26452] INFO (SrvDaemon:220) Xend exited with status 0.<br>=0A&nb=
sp;</span></p>=0A=0A<p class=3D"MsoNormal">&nbsp;</p>=0A=0A<br><br>Javanshi=
r Farzin</td></tr></table>
--1835785293-1546991667-1334651105=:42763--


--===============2039632552603854555==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2039632552603854555==--


From xen-devel-bounces@lists.xen.org Tue Apr 17 08:25:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:25:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK3ip-0004sZ-RQ; Tue, 17 Apr 2012 08:25:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <j.farzin@yahoo.com>) id 1SK3io-0004sM-9I
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 08:25:10 +0000
Received: from [85.158.143.35:43562] by server-1.bemta-4.messagelabs.com id
	CA/70-20925-5E82D8F4; Tue, 17 Apr 2012 08:25:09 +0000
X-Env-Sender: j.farzin@yahoo.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334651106!5165879!1
X-Originating-IP: [98.139.212.189]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22072 invoked from network); 17 Apr 2012 08:25:06 -0000
Received: from nm30.bullet.mail.bf1.yahoo.com (HELO
	nm30.bullet.mail.bf1.yahoo.com) (98.139.212.189)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Apr 2012 08:25:06 -0000
Received: from [98.139.212.144] by nm30.bullet.mail.bf1.yahoo.com with NNFMP;
	17 Apr 2012 08:25:05 -0000
Received: from [98.139.212.196] by tm1.bullet.mail.bf1.yahoo.com with NNFMP;
	17 Apr 2012 08:25:05 -0000
Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP;
	17 Apr 2012 08:25:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 382096.69382.bm@omp1005.mail.bf1.yahoo.com
Received: (qmail 45235 invoked by uid 60001); 17 Apr 2012 08:25:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1334651105; bh=kLyRD6EdCAD4L8VmVq8nwseRrZx0MPLLazl2NzXnalw=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=X0REEjOB7ZBPNmjtHx32urOuxUsDuMDKNkYpQHobMWrsldUGoSIG4TIfX9g80hummL2l422DjJ4m+UyIf6UTsOSSYl2x7S2eW4b6/UxoAXVSkwqyjdfVbycN0ZoFMR+X5+h9JXqmg/pbFd/ZWbnpV4pg8brrOdKPTR/EyT4M2eQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=HAp9AEifoTQ7B9c+VGSHBKwmQUP/R77FHMsl9Y+vjwxGOTepv92CshNePhDNLABMzyb8PBN6ef1b+BqYngBEbd/pyu/BNUjiXWHl8f2swa6LrDO8K/CcMF2HEAOHVrLZfZJdrLTT/nqP524wE+Oa3BTTmOSgcGKeh/3xe2QhVeM=;
X-YMail-OSG: 3MeficoVM1lEQNSBwaOZcSv465GIJWdGzc6uqFzsOD3XXqu
	xRl1vlND1nPNDctwMuWloL4OM3..CihmXbQ3tsr9C0N5rZ0v1MRowzJE1WIW
	DgkIDibFTQPhI3.0G0iHB5wkLS0PxAn4_E4w448nwzFRM5EmM9w7vHZUD1bm
	v92Ey0SG4yCKdVhxi3yGYhFXiT7u8xmX1rOz8sGuwbZpAxQLwPRbOxN8oHUy
	MimvwD4BMkQwCfE4bYhmcMcEdyE8APeUtHoVRnJHWmUV4PjCoLt2uek_y6iU
	k9gzY3dnV6_Fm3NitM9yj34X6JJbC5NNQCM1P5iMbuNPYtCfxE..QInUqqFW
	K4rKUXuN0kq1DuAvQYwLUHGtSpsaviHiFvJwK5JuKWyDGmOvZ6EShmlDvd6a
	vyXWGW73Ki0Ygj5wB.RaLuv2fY4ag56f._Axpgn_AOLdXloP3UbB1p6UlGcZ
	7gTVS9aeLHTFYJjsZEqdPdzqkSHFssyAtU8QxMuMiiicnNSyHZyjfAAJvBHY
	wEoAQFU4f53FK2SxGjjc15IG6kz6L4FxjSn5zls2E5aG.R4ep_nt6D6EYXmP
	V43lkl.0mG7UZm86BcbCwqz.Ghe38zzAZHYgrW_gOjeI-
Received: from [95.81.88.23] by web161504.mail.bf1.yahoo.com via HTTP;
	Tue, 17 Apr 2012 01:25:05 PDT
X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979
Message-ID: <1334651105.42763.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Date: Tue, 17 Apr 2012 01:25:05 -0700 (PDT)
From: Javanshir Farzin <j.farzin@yahoo.com>
To: xen-devel@lists.xensource.com, Xen-users@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] xen live migration is doing but with problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2039632552603854555=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2039632552603854555==
Content-Type: multipart/alternative; boundary="1835785293-1546991667-1334651105=:42763"

--1835785293-1546991667-1334651105=:42763
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

HI,
I compile and build xen 4.1.2 and kernel 3.0.23 from source on ubuntu 11.10=
.
with xm command (xm migrate --live my_vm host2 ) my virtual machine migrate=
 from host1 to host2 successfully, after migration is done, I use (xm list)=
 in host 2 and I=A0 can see my_vm in host2 virtual machines list while it i=
s running .it disappear from host1 virtual machines list.
I=A0 know if migration is successful then some details such as
Saving memory pages: iter 1
1: sent 28847, skipped 3921, delta .....
must be=A0 appeared in my xend.log.but when I see xend.log below messages a=
ppear.

=0A=0A[2012-04-17=0A01:52:07 26453] DEBUG (XendDomainInfo:2498) XendDomainI=
nfo.constructDomain
=0A[2012-04-17 01:52:07 26453] DEBUG (balloon:187) Balloon: 538500 KiB free=
; need=0A16384; done.
=0A[2012-04-17 01:52:07 26453] DEBUG (XendDomain:476) Adding Domain: 7
=0A[2012-04-17 01:52:07 26453] DEBUG (XendDomainInfo:3420) Storing VM detai=
ls:=0A{'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '5=
', 'uuid':=0A'50012590-62ac-0666-115d-91bef70f1cc8', 'on_reboot': 'restart'=
, 'start_time':=0A'1334608987.7', 'on_poweroff': 'destroy', 'bootloader_arg=
s': '',=0A'on_xend_start': 'ignore', 'on_crash': 'restart', 'xend/restart_c=
ount': '0',=0A'vcpus': '1', 'vcpu_avail': '1', 'bootloader': '', 'image': "=
(hvm (kernel=0A'') (superpages 0) (videoram 4) (hpet 0) (stdvga 0) (loader=
=0A/usr/lib/xen/boot/hvmloader) (xen_platform_pci 1) (opengl 1) (rtc_timeof=
fset 0)=0A(pci ()) (hap 1) (localtime 0) (timer_mode 1) (pci_msitranslate 1=
) (oos 1)=0A(apic 1) (sdl 0) (display :0.0) (vpt_align 1) (serial pty) (vnc=
unused 1) (boot=0Ac) (pae 1) (viridian 0) (acpi 1) (vnc 1) (nographic 0) (n=
omigrate 0) (usb 0)=0A(tsc_mode 0) (guest_os_type default) (device_model /u=
sr/lib/xen/bin/qemu-dm)=0A(pci_power_mgmt 0) (xauthority /root/.Xauthority)=
 (isa 0) (notes (SUSPEND_CANCEL=0A1)))", 'name': 'ubuntu'}
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: con=
sole :=0A{'protocol': 'vt100', 'location': '3', 'uuid':=0A'743e2e7c-9c5b-37=
86-bb47-d95f54e85cfd'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend':=0A'/local/domain/0/backe=
nd/console/7/0'} to /local/domain/7/device/console/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'domain': 'ubuntu', 'frontend': '/local/domain/7/device/console/0', =
'uuid':=0A'743e2e7c-9c5b-3786-bb47-d95f54e85cfd', 'frontend-id': '7', 'stat=
e': '1',=0A'location': '3', 'online': '1', 'protocol': 'vt100'} to=0A/local=
/domain/0/backend/console/7/0.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vfb=
 :=0A{'vncunused': '1', 'other_config': {'vncunused': '1', 'vnc': '1'}, 'vn=
c': '1',=0A'uuid': 'bd8a739a-9a08-ee89-fe7e-547e721fecb0', 'location': '127=
.0.0.1:5900'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend=
/vfb/7/0'}=0Ato /local/domain/7/device/vfb/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'vncunused': '1', 'domain': 'ubuntu', 'frontend': '/local/domain/7/d=
evice/vfb/0',=0A'uuid': 'bd8a739a-9a08-ee89-fe7e-547e721fecb0', 'frontend-i=
d': '7', 'state':=0A'1', 'location': '127.0.0.1:5900', 'online': '1', 'vnc'=
: '1'} to=0A/local/domain/0/backend/vfb/7/0.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vbd=
 :=0A{'uuid': '5ae36766-81b1-791e-585d-4a653611923b', 'bootable': 1, 'drive=
r':=0A'paravirtualised', 'dev': 'hda:disk', 'uname':=0A'file:/var/lib/libvi=
rt/images/ubuntu.img', 'mode': 'w', 'VDI': '', 'backend':=0A'0'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'backend-id': '0', 'virtual-device': '768', 'device-type': 'disk', '=
state':=0A'1', 'backend': '/local/domain/0/backend/vbd/7/768'} to=0A/local/=
domain/7/device/vbd/768.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'domain': 'ubuntu', 'frontend': '/local/domain/7/device/vbd/768', 'u=
uid':=0A'5ae36766-81b1-791e-585d-4a653611923b', 'bootable': '1', 'dev': 'hd=
a', 'state':=0A'1', 'params': '/var/lib/libvirt/images/ubuntu.img', 'mode':=
 'w', 'online':=0A'1', 'frontend-id': '7', 'type': 'file'} to /local/domain=
/0/backend/vbd/7/768.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vbd=
 :=0A{'uuid': 'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': 0, 'drive=
r':=0A'paravirtualised', 'dev': 'hdc:cdrom', 'uname': 'phy:/dev/cdrom', 'mo=
de': 'r',=0A'VDI': '', 'backend': '0'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'backend-id': '0', 'virtual-device': '5632', 'device-type': 'cdrom',=
 'state':=0A'1', 'backend': '/local/domain/0/backend/vbd/7/5632'} to=0A/loc=
al/domain/7/device/vbd/5632.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'domain': 'ubuntu', 'frontend': '/local/domain/7/device/vbd/5632', '=
uuid':=0A'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': '0', 'dev': 'h=
dc', 'state':=0A'1', 'params': '/dev/cdrom', 'mode': 'r', 'online': '1', 'f=
rontend-id': '7',=0A'type': 'phy'} to /local/domain/0/backend/vbd/7/5632.
=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vif=
 :=0A{'bridge': 'xenbr0', 'uuid': '08cb242e-758e-8284-4250-34d2bd318338', '=
script':=0A'/etc/xen/scripts/vif-bridge', 'mac': '00:16:3e:60:30:b1', 'type=
': 'ioemu',=0A'backend': '0'}
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend=
/vif/7/0'}=0Ato /local/domain/7/device/vif/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writ=
ing=0A{'bridge': 'xenbr0', 'domain': 'ubuntu', 'handle': '0', 'uuid':=0A'08=
cb242e-758e-8284-4250-34d2bd318338', 'script':=0A'/etc/xen/scripts/vif-brid=
ge', 'mac': '00:16:3e:60:30:b1', 'frontend-id': '7',=0A'state': '1', 'onlin=
e': '1', 'frontend': '/local/domain/7/device/vif/0',=0A'type': 'ioemu'} to =
/local/domain/0/backend/vif/7/0.
=0A[2012-04-17 01:52:07 26453] DEBUG (XendDomainInfo:1794) Storing domain d=
etails:=0A{'console/port': '3', 'description': '', 'console/limit': '104857=
6',=0A'image/suspend-cancel': '1', 'domid': '7', 'vm':=0A'/vm/50012590-62ac=
-0666-115d-91bef70f1cc8', 'cpu/0/availability': 'online',=0A'memory/target'=
: '524288', 'control/platform-feature-multiprocessor-suspend':=0A'1', 'cons=
ole/type': 'ioemu', 'store/port': '2', 'name': 'ubuntu'}
=0A[2012-04-17 01:52:07 26453] INFO (XendCheckpoint:260) restore hvm domain=
 7,=0Aapic=3D1, pae=3D1
=0A[2012-04-17 01:52:07 26453] DEBUG (image:339) No VNC passwd configured f=
or vfb=0Aaccess
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: boot, val: c
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: fda, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: fdb, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: soundhw, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: localtime, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: serial, val: ['pty']
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: std-vga, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: isa, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: acpi, val: 1
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: usb, val: 0
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: usbdevice, val: None
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: gfx_passthru, val: N=
one
=0A[2012-04-17 01:52:07 26453] INFO (image:822) Need to create platform=0Ad=
evice.[domid:7]
=0A[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:278) restore:shadow=3D=
0x5,=0A_static_max=3D0x20000000, _static_min=3D0x0,=20
=0A[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:305) [xc_restore]:=0A/=
usr/lib/xen/bin/xc_restore 26 7 2 3 1 1 1 0
=0A[2012-04-17 01:52:16 26453] DEBUG (XendCheckpoint:394) store-mfn 1044476
=0A[2012-04-17 01:52:16 26453] DEBUG (XendDomainInfo:3010)=0AXendDomainInfo=
.completeRestore
=0A[2012-04-17 01:52:16 26453] DEBUG (image:339) No VNC passwd configured f=
or vfb=0Aaccess
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: boot, val: c
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fda, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fdb, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: soundhw, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: localtime, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: serial, val: ['pty']
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: std-vga, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: isa, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: acpi, val: 1
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usb, val: 0
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usbdevice, val: None
=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: gfx_passthru, val: N=
one
=0A[2012-04-17 01:52:17 26453] INFO (image:822) Need to create platform=0Ad=
evice.[domid:7]
=0A[2012-04-17 01:52:17 26453] INFO (image:418) spawning device models:=0A/=
usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '7',=0A'-domain-=
name', 'ubuntu', '-videoram', '4', '-vnc', '127.0.0.1:0',=0A'-vncunused', '=
-vcpus', '1', '-vcpu_avail', '0x1L', '-boot', 'c', '-serial',=0A'pty', '-ac=
pi', '-net', 'nic,vlan=3D1,macaddr=3D00:16:3e:60:30:b1,model=3Drtl8139',=0A=
'-net', 'tap,vlan=3D1,ifname=3Dtap7.0,bridge=3Dxenbr0', '-M', 'xenfv', '-lo=
advm',=0A'/var/lib/xen/qemu-resume.7']
=0A[2012-04-17 01:52:17 26453] INFO (image:467) device model pid: 26903
=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1794) Storing domain d=
etails:=0A{'console/port': '3', 'description': '', 'console/limit': '104857=
6',=0A'store/port': '2', 'vm': '/vm/50012590-62ac-0666-115d-91bef70f1cc8', =
'domid':=0A'7', 'image/suspend-cancel': '1', 'cpu/0/availability': 'online'=
,=0A'memory/target': '524288', 'control/platform-feature-multiprocessor-sus=
pend':=0A'1', 'store/ring-ref': '1044476', 'console/type': 'ioemu', 'name':=
 'ubuntu'}
=0A[2012-04-17 01:52:17 26453] INFO (image:590) waiting for sentinel_fifo
=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1881)=0AXendDomainInfo=
.handleShutdownWatch
=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:3023)=0AXendDomainInfo=
.completeRestore done
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s tap2.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vif.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 0.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatusCallb=
ack=0A/local/domain/0/backend/vif/7/0/hotplug-status.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallb=
ack 1.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vkbd.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s=0Aioports.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s tap.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vif2.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s=0Aconsole.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 0.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s=0Avscsi.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vbd.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 768.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatusCallb=
ack=0A/local/domain/0/backend/vbd/7/768/hotplug-status.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallb=
ack 1.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 5632.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatusCallb=
ack=0A/local/domain/0/backend/vbd/7/5632/hotplug-status.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallb=
ack 1.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s irq.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vfb.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s pci.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vusb.
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vtpm.
=0A[2012-04-17 01:54:33 26453] DEBUG (XendCheckpoint:124) [xc_save]:=0A/usr=
/lib/xen/bin/xc_save 26 7 0 0 5
=0A[2012-04-17 01:54:33 26453] INFO (XendCheckpoint:423) xc_save: failed to=
 get=0Athe suspend evtchn port
=0A[2012-04-17 01:54:33 26453] INFO (XendCheckpoint:423)=20
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:394) suspend
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:127) In saveInputHandl=
er=0Asuspend
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:129) Suspending 7 ...
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:524) XendDomainInfo.sh=
utdown(suspend)
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1881)=0AXendDomainInfo=
.handleShutdownWatch
=0A[2012-04-17 01:55:04 26453] INFO (XendDomainInfo:541) HVM save:remote sh=
utdown=0Adom 7!
=0A[2012-04-17 01:55:04 26453] INFO (XendCheckpoint:135) Domain 7 suspended=
.
=0A[2012-04-17 01:55:04 26453] INFO (XendDomainInfo:2078) Domain has shutdo=
wn:=0Aname=3Dmigrating-ubuntu id=3D7 reason=3Dsuspend.
=0A[2012-04-17 01:55:04 26453] INFO (image:538) signalDeviceModel:restore d=
m state=0Ato running
=0A[2012-04-17 01:55:04 26453] DEBUG (XendCheckpoint:144) Written done
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:3071) XendDomainInfo.d=
estroy:=0Adomid=3D7
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2401) Destroying devic=
e model
=0A[2012-04-17 01:55:04 26453] INFO (image:615) migrating-ubuntu device mod=
el=0Aterminated
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2408) Releasing device=
s
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vif/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D vif, device =3D vif/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing console=
/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D console, device =3D console/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vbd/768
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D vbd, device =3D vbd/768
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vbd/563=
2
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDomainInfo=
.destroyDevice: deviceClass =3D vbd, device =3D vbd/5632
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vfb/0
=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276) XendDomainInfo.d=
estroyDevice:=0AdeviceClass =3D vfb, device =3D vfb/0
=0A[2012-04-17 02:14:21 26453] DEBUG (SrvServer:77) SrvServer.cleanup()
=0A[2012-04-17 02:14:21 26453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanu=
p()
=0A[2012-04-17 02:14:21 26453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanu=
p()
=0A[2012-04-17 02:14:21 26453] DEBUG (XendDomain:644) cleanup_domains
=0A[2012-04-17 02:14:21 26452] INFO (SrvDaemon:220) Xend exited with status=
 0.
=0A=A0=0A=0A=A0=0A=0A

Javanshir Farzin
--1835785293-1546991667-1334651105=:42763
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><font size=3D"4"><span style=3D"font-family: =
courier,monaco,monospace,sans-serif; font-weight: bold;">HI,</span><br styl=
e=3D"font-family: courier,monaco,monospace,sans-serif; font-weight: bold;">=
<span style=3D"font-family: courier,monaco,monospace,sans-serif; font-weigh=
t: bold;">I compile and build xen 4.1.2 and kernel 3.0.23 from source on ub=
untu 11.10.</span><br style=3D"font-family: courier,monaco,monospace,sans-s=
erif; font-weight: bold;"><span style=3D"font-family: courier,monaco,monosp=
ace,sans-serif; font-weight: bold;">with xm command (xm migrate --live my_v=
m host2 ) my virtual machine migrate from host1 to host2 successfully, afte=
r migration is done, I use (xm list) in host 2 and I&nbsp; can see my_vm in=
 host2 virtual machines list while it is running .it disappear from host1 v=
irtual machines list.</span><br style=3D"font-family: courier,monaco,monosp=
ace,sans-serif;
 font-weight: bold;"><span style=3D"font-family: courier,monaco,monospace,s=
ans-serif; font-weight: bold;">I&nbsp; know if migration is successful then=
 some details such as</span><br></font><pre><font size=3D"3"><span style=3D=
"font-family: courier,monaco,monospace,sans-serif;">Saving memory pages: it=
er 1</span><br style=3D"font-family: courier,monaco,monospace,sans-serif;">=
</font><font size=3D"4"><font size=3D"3"><span style=3D"font-family: courie=
r,monaco,monospace,sans-serif;">1: sent 28847, skipped 3921, delta .....</s=
pan></font><br></font></pre><font style=3D"font-family: courier,monaco,mono=
space,sans-serif; font-weight: bold;" size=3D"4">must be&nbsp; appeared in =
my xend.log.</font><font style=3D"font-family: courier,monaco,monospace,san=
s-serif; font-weight: bold;" size=3D"4">but when I see xend.log below messa=
ges appear</font><font style=3D"font-family: courier,monaco,monospace,sans-=
serif; font-weight: bold;" size=3D"4">.</font><br><br><!--[if gte mso 9]><x=
ml>=0A <o:OfficeDocumentSettings>=0A  <o:AllowPNG/>=0A </o:OfficeDocumentSe=
ttings>=0A</xml><![endif][if gte mso 9]><xml>=0A <w:WordDocument>=0A  <w:Vi=
ew>Normal</w:View>=0A  <w:Zoom>0</w:Zoom>=0A  <w:TrackMoves/>=0A  <w:TrackF=
ormatting/>=0A  <w:PunctuationKerning/>=0A  <w:ValidateAgainstSchemas/>=0A =
 <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>=0A  <w:IgnoreMixedContent>f=
alse</w:IgnoreMixedContent>=0A  <w:AlwaysShowPlaceholderText>false</w:Alway=
sShowPlaceholderText>=0A  <w:DoNotPromoteQF/>=0A  <w:LidThemeOther>EN-US</w=
:LidThemeOther>=0A  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>=0A  <w:LidThe=
meComplexScript>AR-SA</w:LidThemeComplexScript>=0A  <w:Compatibility>=0A   =
<w:BreakWrappedTables/>=0A   <w:SnapToGridInCell/>=0A   <w:WrapTextWithPunc=
t/>=0A   <w:UseAsianBreakRules/>=0A   <w:DontGrowAutofit/>=0A   <w:SplitPgB=
reakAndParaMark/>=0A   <w:EnableOpenTypeKerning/>=0A   <w:DontFlipMirrorInd=
ents/>=0A   <w:OverrideTableStyleHps/>=0A  </w:Compatibility>=0A  <m:mathPr=
>=0A   <m:mathFont m:val=3D"Cambria Math"/>=0A   <m:brkBin m:val=3D"before"=
/>=0A   <m:brkBinSub m:val=3D"&#45;-"/>=0A   <m:smallFrac m:val=3D"off"/>=
=0A   <m:dispDef/>=0A   <m:lMargin m:val=3D"0"/>=0A   <m:rMargin m:val=3D"0=
"/>=0A   <m:defJc m:val=3D"centerGroup"/>=0A   <m:wrapIndent m:val=3D"1440"=
/>=0A   <m:intLim m:val=3D"subSup"/>=0A   <m:naryLim m:val=3D"undOvr"/>=0A =
 </m:mathPr></w:WordDocument>=0A</xml><![endif][if gte mso 9]><xml>=0A <w:L=
atentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"=0A  DefSemi=
Hidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"=0A  LatentStyleCoun=
t=3D"267">=0A  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"head=
ing 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"tru=
e" Name=3D"heading 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9"=
 QFormat=3D"true" Name=3D"heading 4"/>=0A  <w:LsdException Locked=3D"false"=
 Priority=3D"9" QFormat=3D"true" Name=3D"heading 5"/>=0A  <w:LsdException L=
ocked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"heading 6"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"head=
ing 7"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"tru=
e" Name=3D"heading 8"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"9"=
 QFormat=3D"true" Name=3D"heading 9"/>=0A  <w:LsdException Locked=3D"false"=
 Priority=3D"39" Name=3D"toc 1"/>=0A  <w:LsdException Locked=3D"false" Prio=
rity=3D"39" Name=3D"toc 2"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"39" Name=3D"toc 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"3=
9" Name=3D"toc 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Na=
me=3D"toc 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D=
"toc 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc =
7"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>=0A  =
<w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" Name=3D"c=
aption"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default Paragr=
aph Font"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"=
/>=0A  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false=
"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>=0A  <w:L=
sdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"=0A   Unhi=
deWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>=0A  <w:LsdExcepti=
on Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"=0A   UnhideWhenUse=
d=3D"false" Name=3D"Table Grid"/>=0A  <w:LsdException Locked=3D"false" Unhi=
deWhenUsed=3D"false" Name=3D"Placeholder Text"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"1" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false=
" QFormat=3D"true" Name=3D"No Spacing"/>=0A  <w:LsdException Locked=3D"fals=
e" Priority=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Light Shading"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"61" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light List"/>=0A =
 <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=0A  =
 UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"63" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Medium Shading 1"/>=0A  <w:LsdException Locked=3D"false" Priorit=
y=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium =
Shading 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidde=
n=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>=0A  <w:L=
sdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=0A   Unhi=
deWhenUsed=3D"false" Name=3D"Medium List 2"/>=0A  <w:LsdException Locked=3D=
"false" Priority=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" =
Name=3D"Medium Grid 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"6=
8" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2=
"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"fals=
e"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>=0A  <w:LsdExcepti=
on Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   UnhideWhenUse=
d=3D"false" Name=3D"Dark List"/>=0A  <w:LsdException Locked=3D"false" Prior=
ity=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Color=
ful Shading"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHid=
den=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=0A   Un=
hideWhenUsed=3D"false" Name=3D"Colorful Grid"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Light Shading Accent 1"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"61" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"L=
ight List Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"62" =
SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accen=
t 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"f=
alse"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>=0A=
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=0A =
  UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>=0A  <w:LsdE=
xception Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=0A   UnhideW=
henUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>=0A  <w:LsdException Loc=
ked=3D"false" UnhideWhenUsed=3D"false" Name=3D"Revision"/>=0A  <w:LsdExcept=
ion Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"=0A   UnhideWhenUs=
ed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>=0A  <w:LsdException=
 Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" QFormat=3D"true" Name=3D"Quote"/>=0A  <w:LsdException Locked=3D"=
false" Priority=3D"30" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Q=
Format=3D"true" Name=3D"Intense Quote"/>=0A  <w:LsdException Locked=3D"fals=
e" Priority=3D"66" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Medium List 2 Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium G=
rid 1 Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"68" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent=
 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   Un=
hideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Colorful Shading Accent 1"/>=0A  <w:LsdException Locked=3D"f=
alse" Priority=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Na=
me=3D"Colorful List Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priori=
ty=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorf=
ul Grid Accent 1"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"60" Se=
miHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Shading Acce=
nt 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"=
false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>=0A  <w:=
LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=0A   Unh=
ideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"63" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Medium Shading 1 Accent 2"/>=0A  <w:LsdException Locked=3D"f=
alse" Priority=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Na=
me=3D"Medium Shading 2 Accent 2"/>=0A  <w:LsdException Locked=3D"false" Pri=
ority=3D"65" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Med=
ium List 1 Accent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"66"=
 SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 A=
ccent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Dark List Accent 2"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"C=
olorful Shading Accent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful=
 List Accent 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"73" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent=
 2"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>=0A  <w=
:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=0A   Un=
hideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>=0A  <w:LsdException L=
ocked=3D"false" Priority=3D"62" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D=
"false" Name=3D"Light Grid Accent 3"/>=0A  <w:LsdException Locked=3D"false"=
 Priority=3D"63" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D=
"Medium Shading 1 Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium S=
hading 2 Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"65" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Acc=
ent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D=
"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>=0A =
 <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=0A  =
 UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>=0A  <w:LsdExcep=
tion Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=0A   UnhideWhenU=
sed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"69" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Medium Grid 3 Accent 3"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"70" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"D=
ark List Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"71" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading =
Accent 3"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=
=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>=0A  <w:LsdException Lo=
cked=3D"false" Priority=3D"61" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"=
false" Name=3D"Light List Accent 4"/>=0A  <w:LsdException Locked=3D"false" =
Priority=3D"62" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"=
Light Grid Accent 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"63"=
 SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading =
1 Accent 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidd=
en=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent =
4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"fal=
se"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>=0A  <w:=
LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=0A   Unh=
ideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>=0A  <w:LsdException=
 Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" Name=3D"Medium Grid 1 Accent 4"/>=0A  <w:LsdException Locked=3D"=
false" Priority=3D"68" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" N=
ame=3D"Medium Grid 2 Accent 4"/>=0A  <w:LsdException Locked=3D"false" Prior=
ity=3D"69" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Mediu=
m Grid 3 Accent 4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"70" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent =
4"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"fal=
se"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>=0A  =
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=0A   =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>=0A  <w:LsdExcept=
ion Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUs=
ed=3D"false" Name=3D"Colorful Grid Accent 4"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Light Shading Accent 5"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"61" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"L=
ight List Accent 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"62" =
SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accen=
t 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"f=
alse"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>=0A=
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=0A =
  UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>=0A  <w:LsdE=
xception Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=0A   UnhideW=
henUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>=0A  <w:LsdException Loc=
ked=3D"false" Priority=3D"66" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"f=
alse" Name=3D"Medium List 2 Accent 5"/>=0A  <w:LsdException Locked=3D"false=
" Priority=3D"67" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Medium Grid 1 Accent 5"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"68" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium G=
rid 2 Accent 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"69" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent=
 5"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>=0A  <w:LsdException=
 Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" Name=3D"Colorful List Accent 5"/>=0A  <w:LsdException Locked=3D"=
false" Priority=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" N=
ame=3D"Colorful Grid Accent 5"/>=0A  <w:LsdException Locked=3D"false" Prior=
ity=3D"60" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light=
 Shading Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"61" S=
emiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Light List Accent=
 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"fa=
lse"=0A   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>=0A  <w:Ls=
dException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=0A   Unhid=
eWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>=0A  <w:LsdExceptio=
n Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=0A   UnhideWhenUsed=
=3D"false" Name=3D"Medium Shading 2 Accent 6"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"65" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Medium List 1 Accent 6"/>=0A  <w:LsdException Locked=3D"false" P=
riority=3D"66" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"M=
edium List 2 Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"6=
7" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1=
 Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidde=
n=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>=
=0A  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=
=0A   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>=0A  <w:Lsd=
Exception Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=0A   Unhide=
WhenUsed=3D"false" Name=3D"Dark List Accent 6"/>=0A  <w:LsdException Locked=
=3D"false" Priority=3D"71" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"fals=
e" Name=3D"Colorful Shading Accent 6"/>=0A  <w:LsdException Locked=3D"false=
" Priority=3D"72" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=
=3D"Colorful List Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=
=3D"73" SemiHidden=3D"false"=0A   UnhideWhenUsed=3D"false" Name=3D"Colorful=
 Grid Accent 6"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"19" Semi=
Hidden=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Sub=
tle Emphasis"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHi=
dden=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Inten=
se Emphasis"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHid=
den=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle=
 Reference"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidd=
en=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense=
 Reference"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidd=
en=3D"false"=0A   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Ti=
tle"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliog=
raphy"/>=0A  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"tr=
ue" Name=3D"TOC Heading"/>=0A </w:LatentStyles>=0A</xml><![endif][if gte ms=
o 10]>=0A<style>=0A /* Style Definitions */=0A table.MsoNormalTable=0A=09{m=
so-style-name:"Table Normal";=0A=09mso-tstyle-rowband-size:0;=0A=09mso-tsty=
le-colband-size:0;=0A=09mso-style-noshow:yes;=0A=09mso-style-priority:99;=
=0A=09mso-style-parent:"";=0A=09mso-padding-alt:0cm 5.4pt 0cm 5.4pt;=0A=09m=
so-para-margin-top:0cm;=0A=09mso-para-margin-right:0cm;=0A=09mso-para-margi=
n-bottom:10.0pt;=0A=09mso-para-margin-left:0cm;=0A=09line-height:115%;=0A=
=09mso-pagination:widow-orphan;=0A=09font-size:11.0pt;=0A=09font-family:"Ca=
libri","sans-serif";=0A=09mso-ascii-font-family:Calibri;=0A=09mso-ascii-the=
me-font:minor-latin;=0A=09mso-hansi-font-family:Calibri;=0A=09mso-hansi-the=
me-font:minor-latin;=0A=09mso-bidi-font-family:Arial;=0A=09mso-bidi-theme-f=
ont:minor-bidi;}=0A</style>=0A<![endif]-->=0A=0A<p class=3D"MsoNormal" styl=
e=3D"margin-bottom:0cm;margin-bottom:.0001pt;line-height:=0Anormal"><span s=
tyle=3D"font-size:10.5pt;font-family:&quot;Courier New&quot;">[2012-04-17=
=0A01:52:07 26453] DEBUG (XendDomainInfo:2498) XendDomainInfo.constructDoma=
in<br>=0A[2012-04-17 01:52:07 26453] DEBUG (balloon:187) Balloon: 538500 Ki=
B free; need=0A16384; done.<br>=0A[2012-04-17 01:52:07 26453] DEBUG (XendDo=
main:476) Adding Domain: 7<br>=0A[2012-04-17 01:52:07 26453] DEBUG (XendDom=
ainInfo:3420) Storing VM details:=0A{'on_xend_stop': 'ignore', 'pool_name':=
 'Pool-0', 'shadow_memory': '5', 'uuid':=0A'50012590-62ac-0666-115d-91bef70=
f1cc8', 'on_reboot': 'restart', 'start_time':=0A'1334608987.7', 'on_powerof=
f': 'destroy', 'bootloader_args': '',=0A'on_xend_start': 'ignore', 'on_cras=
h': 'restart', 'xend/restart_count': '0',=0A'vcpus': '1', 'vcpu_avail': '1'=
, 'bootloader': '', 'image': "(hvm (kernel=0A'') (superpages 0) (videoram 4=
) (hpet 0) (stdvga 0) (loader=0A/usr/lib/xen/boot/hvmloader) (xen_platform_=
pci 1) (opengl 1) (rtc_timeoffset 0)=0A(pci ()) (hap 1) (localtime 0) (time=
r_mode 1) (pci_msitranslate 1) (oos 1)=0A(apic 1) (sdl 0) (display :0.0) (v=
pt_align 1) (serial pty) (vncunused 1) (boot=0Ac) (pae 1) (viridian 0) (acp=
i 1) (vnc 1) (nographic 0) (nomigrate 0) (usb 0)=0A(tsc_mode 0) (guest_os_t=
ype default) (device_model /usr/lib/xen/bin/qemu-dm)=0A(pci_power_mgmt 0) (=
xauthority /root/.Xauthority) (isa 0) (notes (SUSPEND_CANCEL=0A1)))", 'name=
': 'ubuntu'}<br>=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) c=
reateDevice: console :=0A{'protocol': 'vt100', 'location': '3', 'uuid':=0A'=
743e2e7c-9c5b-3786-bb47-d95f54e85cfd'}<br>=0A[2012-04-17 01:52:07 26453] DE=
BUG (DevController:95) DevController: writing=0A{'state': '1', 'backend-id'=
: '0', 'backend':=0A'/local/domain/0/backend/console/7/0'} to /local/domain=
/7/device/console/0.<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevController=
:97) DevController: writing=0A{'domain': 'ubuntu', 'frontend': '/local/doma=
in/7/device/console/0', 'uuid':=0A'743e2e7c-9c5b-3786-bb47-d95f54e85cfd', '=
frontend-id': '7', 'state': '1',=0A'location': '3', 'online': '1', 'protoco=
l': 'vt100'} to=0A/local/domain/0/backend/console/7/0.<br>=0A[2012-04-17 01=
:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vfb :=0A{'vncunused'=
: '1', 'other_config': {'vncunused': '1', 'vnc': '1'}, 'vnc': '1',=0A'uuid'=
: 'bd8a739a-9a08-ee89-fe7e-547e721fecb0', 'location': '127.0.0.1:5900'}<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) DevController: writ=
ing=0A{'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend=
/vfb/7/0'}=0Ato /local/domain/7/device/vfb/0.<br>=0A[2012-04-17 01:52:07 26=
453] DEBUG (DevController:97) DevController: writing=0A{'vncunused': '1', '=
domain': 'ubuntu', 'frontend': '/local/domain/7/device/vfb/0',=0A'uuid': 'b=
d8a739a-9a08-ee89-fe7e-547e721fecb0', 'frontend-id': '7', 'state':=0A'1', '=
location': '127.0.0.1:5900', 'online': '1', 'vnc': '1'} to=0A/local/domain/=
0/backend/vfb/7/0.<br>=0A[2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2=
357) createDevice: vbd :=0A{'uuid': '5ae36766-81b1-791e-585d-4a653611923b',=
 'bootable': 1, 'driver':=0A'paravirtualised', 'dev': 'hda:disk', 'uname':=
=0A'file:/var/lib/libvirt/images/ubuntu.img', 'mode': 'w', 'VDI': '', 'back=
end':=0A'0'}<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:95) Dev=
Controller: writing=0A{'backend-id': '0', 'virtual-device': '768', 'device-=
type': 'disk', 'state':=0A'1', 'backend': '/local/domain/0/backend/vbd/7/76=
8'} to=0A/local/domain/7/device/vbd/768.<br>=0A[2012-04-17 01:52:07 26453] =
DEBUG (DevController:97) DevController: writing=0A{'domain': 'ubuntu', 'fro=
ntend': '/local/domain/7/device/vbd/768', 'uuid':=0A'5ae36766-81b1-791e-585=
d-4a653611923b', 'bootable': '1', 'dev': 'hda', 'state':=0A'1', 'params': '=
/var/lib/libvirt/images/ubuntu.img', 'mode': 'w', 'online':=0A'1', 'fronten=
d-id': '7', 'type': 'file'} to /local/domain/0/backend/vbd/7/768.<br>=0A[20=
12-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vbd :=0A{=
'uuid': 'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': 0, 'driver':=0A=
'paravirtualised', 'dev': 'hdc:cdrom', 'uname': 'phy:/dev/cdrom', 'mode': '=
r',=0A'VDI': '', 'backend': '0'}<br>=0A[2012-04-17 01:52:07 26453] DEBUG (D=
evController:95) DevController: writing=0A{'backend-id': '0', 'virtual-devi=
ce': '5632', 'device-type': 'cdrom', 'state':=0A'1', 'backend': '/local/dom=
ain/0/backend/vbd/7/5632'} to=0A/local/domain/7/device/vbd/5632.<br>=0A[201=
2-04-17 01:52:07 26453] DEBUG (DevController:97) DevController: writing=0A{=
'domain': 'ubuntu', 'frontend': '/local/domain/7/device/vbd/5632', 'uuid':=
=0A'd891fb8b-1d4b-d023-7d6f-acfd89f92178', 'bootable': '0', 'dev': 'hdc', '=
state':=0A'1', 'params': '/dev/cdrom', 'mode': 'r', 'online': '1', 'fronten=
d-id': '7',=0A'type': 'phy'} to /local/domain/0/backend/vbd/7/5632.<br>=0A[=
2012-04-17 01:52:07 26453] INFO (XendDomainInfo:2357) createDevice: vif :=
=0A{'bridge': 'xenbr0', 'uuid': '08cb242e-758e-8284-4250-34d2bd318338', 'sc=
ript':=0A'/etc/xen/scripts/vif-bridge', 'mac': '00:16:3e:60:30:b1', 'type':=
 'ioemu',=0A'backend': '0'}<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevCon=
troller:95) DevController: writing=0A{'state': '1', 'backend-id': '0', 'bac=
kend': '/local/domain/0/backend/vif/7/0'}=0Ato /local/domain/7/device/vif/0=
.<br>=0A[2012-04-17 01:52:07 26453] DEBUG (DevController:97) DevController:=
 writing=0A{'bridge': 'xenbr0', 'domain': 'ubuntu', 'handle': '0', 'uuid':=
=0A'08cb242e-758e-8284-4250-34d2bd318338', 'script':=0A'/etc/xen/scripts/vi=
f-bridge', 'mac': '00:16:3e:60:30:b1', 'frontend-id': '7',=0A'state': '1', =
'online': '1', 'frontend': '/local/domain/7/device/vif/0',=0A'type': 'ioemu=
'} to /local/domain/0/backend/vif/7/0.<br>=0A[2012-04-17 01:52:07 26453] DE=
BUG (XendDomainInfo:1794) Storing domain details:=0A{'console/port': '3', '=
description': '', 'console/limit': '1048576',=0A'image/suspend-cancel': '1'=
, 'domid': '7', 'vm':=0A'/vm/50012590-62ac-0666-115d-91bef70f1cc8', 'cpu/0/=
availability': 'online',=0A'memory/target': '524288', 'control/platform-fea=
ture-multiprocessor-suspend':=0A'1', 'console/type': 'ioemu', 'store/port':=
 '2', 'name': 'ubuntu'}<br>=0A[2012-04-17 01:52:07 26453] INFO (XendCheckpo=
int:260) restore hvm domain 7,=0Aapic=3D1, pae=3D1<br>=0A[2012-04-17 01:52:=
07 26453] DEBUG (image:339) No VNC passwd configured for vfb=0Aaccess<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: boot, val: c<br>=0A[=
2012-04-17 01:52:07 26453] DEBUG (image:891) args: fda, val: None<br>=0A[20=
12-04-17 01:52:07 26453] DEBUG (image:891) args: fdb, val: None<br>=0A[2012=
-04-17 01:52:07 26453] DEBUG (image:891) args: soundhw, val: None<br>=0A[20=
12-04-17 01:52:07 26453] DEBUG (image:891) args: localtime, val: 0<br>=0A[2=
012-04-17 01:52:07 26453] DEBUG (image:891) args: serial, val: ['pty']<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: std-vga, val: 0<br>=
=0A[2012-04-17 01:52:07 26453] DEBUG (image:891) args: isa, val: 0<br>=0A[2=
012-04-17 01:52:07 26453] DEBUG (image:891) args: acpi, val: 1<br>=0A[2012-=
04-17 01:52:07 26453] DEBUG (image:891) args: usb, val: 0<br>=0A[2012-04-17=
 01:52:07 26453] DEBUG (image:891) args: usbdevice, val: None<br>=0A[2012-0=
4-17 01:52:07 26453] DEBUG (image:891) args: gfx_passthru, val: None<br>=0A=
[2012-04-17 01:52:07 26453] INFO (image:822) Need to create platform=0Adevi=
ce.[domid:7]<br>=0A[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:278) r=
estore:shadow=3D0x5,=0A_static_max=3D0x20000000, _static_min=3D0x0, <br>=0A=
[2012-04-17 01:52:07 26453] DEBUG (XendCheckpoint:305) [xc_restore]:=0A/usr=
/lib/xen/bin/xc_restore 26 7 2 3 1 1 1 0<br>=0A[2012-04-17 01:52:16 26453] =
DEBUG (XendCheckpoint:394) store-mfn 1044476<br>=0A[2012-04-17 01:52:16 264=
53] DEBUG (XendDomainInfo:3010)=0AXendDomainInfo.completeRestore<br>=0A[201=
2-04-17 01:52:16 26453] DEBUG (image:339) No VNC passwd configured for vfb=
=0Aaccess<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: boot, v=
al: c<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fda, val: N=
one<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: fdb, val: Non=
e<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: soundhw, val: N=
one<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: localtime, va=
l: 0<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: serial, val:=
 ['pty']<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: std-vga,=
 val: 0<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: isa, val:=
 0<br>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: acpi, val: 1<b=
r>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usb, val: 0<br>=0A=
[2012-04-17 01:52:16 26453] DEBUG (image:891) args: usbdevice, val: None<br=
>=0A[2012-04-17 01:52:16 26453] DEBUG (image:891) args: gfx_passthru, val: =
None<br>=0A[2012-04-17 01:52:17 26453] INFO (image:822) Need to create plat=
form=0Adevice.[domid:7]<br>=0A[2012-04-17 01:52:17 26453] INFO (image:418) =
spawning device models:=0A/usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-=
dm', '-d', '7',=0A'-domain-name', 'ubuntu', '-videoram', '4', '-vnc', '127.=
0.0.1:0',=0A'-vncunused', '-vcpus', '1', '-vcpu_avail', '0x1L', '-boot', 'c=
', '-serial',=0A'pty', '-acpi', '-net', 'nic,vlan=3D1,macaddr=3D00:16:3e:60=
:30:b1,model=3Drtl8139',=0A'-net', 'tap,vlan=3D1,ifname=3Dtap7.0,bridge=3Dx=
enbr0', '-M', 'xenfv', '-loadvm',=0A'/var/lib/xen/qemu-resume.7']<br>=0A[20=
12-04-17 01:52:17 26453] INFO (image:467) device model pid: 26903<br>=0A[20=
12-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1794) Storing domain details=
:=0A{'console/port': '3', 'description': '', 'console/limit': '1048576',=0A=
'store/port': '2', 'vm': '/vm/50012590-62ac-0666-115d-91bef70f1cc8', 'domid=
':=0A'7', 'image/suspend-cancel': '1', 'cpu/0/availability': 'online',=0A'm=
emory/target': '524288', 'control/platform-feature-multiprocessor-suspend':=
=0A'1', 'store/ring-ref': '1044476', 'console/type': 'ioemu', 'name': 'ubun=
tu'}<br>=0A[2012-04-17 01:52:17 26453] INFO (image:590) waiting for sentine=
l_fifo<br>=0A[2012-04-17 01:52:17 26453] DEBUG (XendDomainInfo:1881)=0AXend=
DomainInfo.handleShutdownWatch<br>=0A[2012-04-17 01:52:17 26453] DEBUG (Xen=
dDomainInfo:3023)=0AXendDomainInfo.completeRestore done<br>=0A[2012-04-17 0=
1:52:17 26453] DEBUG (DevController:139) Waiting for devices tap2.<br>=0A[2=
012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for devices vif=
.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for 0=
.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugStatus=
Callback=0A/local/domain/0/backend/vif/7/0/hotplug-status.<br>=0A[2012-04-1=
7 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallback 1.<br>=0A=
[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for devices v=
kbd.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting fo=
r devices=0Aioports.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController=
:139) Waiting for devices tap.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (Dev=
Controller:139) Waiting for devices vif2.<br>=0A[2012-04-17 01:52:17 26453]=
 DEBUG (DevController:139) Waiting for devices=0Aconsole.<br>=0A[2012-04-17=
 01:52:17 26453] DEBUG (DevController:144) Waiting for 0.<br>=0A[2012-04-17=
 01:52:17 26453] DEBUG (DevController:139) Waiting for devices=0Avscsi.<br>=
=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for device=
s vbd.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting =
for 768.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplu=
gStatusCallback=0A/local/domain/0/backend/vbd/7/768/hotplug-status.<br>=0A[=
2012-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallback =
1.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:144) Waiting for =
5632.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:628) hotplugSt=
atusCallback=0A/local/domain/0/backend/vbd/7/5632/hotplug-status.<br>=0A[20=
12-04-17 01:52:17 26453] DEBUG (DevController:642) hotplugStatusCallback 1.=
<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Waiting for de=
vices irq.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController:139) Wait=
ing for devices vfb.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (DevController=
:139) Waiting for devices pci.<br>=0A[2012-04-17 01:52:17 26453] DEBUG (Dev=
Controller:139) Waiting for devices vusb.<br>=0A[2012-04-17 01:52:17 26453]=
 DEBUG (DevController:139) Waiting for devices vtpm.<br>=0A[2012-04-17 01:5=
4:33 26453] DEBUG (XendCheckpoint:124) [xc_save]:=0A/usr/lib/xen/bin/xc_sav=
e 26 7 0 0 5<br>=0A[2012-04-17 01:54:33 26453] INFO (XendCheckpoint:423) xc=
_save: failed to get=0Athe suspend evtchn port<br>=0A[2012-04-17 01:54:33 2=
6453] INFO (XendCheckpoint:423) <br>=0A[2012-04-17 01:55:04 26453] DEBUG (X=
endCheckpoint:394) suspend<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendChe=
ckpoint:127) In saveInputHandler=0Asuspend<br>=0A[2012-04-17 01:55:04 26453=
] DEBUG (XendCheckpoint:129) Suspending 7 ...<br>=0A[2012-04-17 01:55:04 26=
453] DEBUG (XendDomainInfo:524) XendDomainInfo.shutdown(suspend)<br>=0A[201=
2-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1881)=0AXendDomainInfo.handle=
ShutdownWatch<br>=0A[2012-04-17 01:55:04 26453] INFO (XendDomainInfo:541) H=
VM save:remote shutdown=0Adom 7!<br>=0A[2012-04-17 01:55:04 26453] INFO (Xe=
ndCheckpoint:135) Domain 7 suspended.<br>=0A[2012-04-17 01:55:04 26453] INF=
O (XendDomainInfo:2078) Domain has shutdown:=0Aname=3Dmigrating-ubuntu id=
=3D7 reason=3Dsuspend.<br>=0A[2012-04-17 01:55:04 26453] INFO (image:538) s=
ignalDeviceModel:restore dm state=0Ato running<br>=0A[2012-04-17 01:55:04 2=
6453] DEBUG (XendCheckpoint:144) Written done<br>=0A[2012-04-17 01:55:04 26=
453] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy:=0Adomid=3D7<br>=0A=
[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2401) Destroying device m=
odel<br>=0A[2012-04-17 01:55:04 26453] INFO (image:615) migrating-ubuntu de=
vice model=0Aterminated<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomain=
Info:2408) Releasing devices<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendD=
omainInfo:2414) Removing vif/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (Xen=
dDomainInfo:1276)=0AXendDomainInfo.destroyDevice: deviceClass =3D vif, devi=
ce =3D vif/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) =
Removing console/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:=
1276)=0AXendDomainInfo.destroyDevice: deviceClass =3D console, device =3D c=
onsole/0<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Remo=
ving vbd/768<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=
=0AXendDomainInfo.destroyDevice: deviceClass =3D vbd, device =3D vbd/768<br=
>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vbd/56=
32<br>=0A[2012-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276)=0AXendDoma=
inInfo.destroyDevice: deviceClass =3D vbd, device =3D vbd/5632<br>=0A[2012-=
04-17 01:55:04 26453] DEBUG (XendDomainInfo:2414) Removing vfb/0<br>=0A[201=
2-04-17 01:55:04 26453] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyD=
evice:=0AdeviceClass =3D vfb, device =3D vfb/0<br>=0A[2012-04-17 02:14:21 2=
6453] DEBUG (SrvServer:77) SrvServer.cleanup()<br>=0A[2012-04-17 02:14:21 2=
6453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup()<br>=0A[2012-04-17 02:=
14:21 26453] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup()<br>=0A[2012-04=
-17 02:14:21 26453] DEBUG (XendDomain:644) cleanup_domains<br>=0A[2012-04-1=
7 02:14:21 26452] INFO (SrvDaemon:220) Xend exited with status 0.<br>=0A&nb=
sp;</span></p>=0A=0A<p class=3D"MsoNormal">&nbsp;</p>=0A=0A<br><br>Javanshi=
r Farzin</td></tr></table>
--1835785293-1546991667-1334651105=:42763--


--===============2039632552603854555==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2039632552603854555==--


From xen-devel-bounces@lists.xen.org Tue Apr 17 08:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4BJ-0005yC-D3; Tue, 17 Apr 2012 08:54:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK4BI-0005y7-5W
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 08:54:36 +0000
Received: from [85.158.143.99:37744] by server-3.bemta-4.messagelabs.com id
	0F/B1-05853-BCF2D8F4; Tue, 17 Apr 2012 08:54:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334652872!23639122!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY5Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29536 invoked from network); 17 Apr 2012 08:54:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330923600"; d="scan'208";a="24222131"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 04:54:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 04:54:32 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK4BD-0007zl-NF;
	Tue, 17 Apr 2012 09:54:31 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334594686.14560.242.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 09:54:32 +0100
Message-ID: <8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
	<1334594686.14560.242.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 17:44, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>> This is a rather big change, that adds the necessary machinery to perform
>> hotplug script calling from libxl for Linux. This patch launches the nec=
essary
>> scripts to attach and detach PHY and TAP backend types (Qemu doesn't use=
 hotplug
>> scripts).
>> =

>> Here's a list of the major changes introduced:
>> =

>> * libxl_device_disk_add makes use of the new event library and takes the
>>   optional parameter libxl_asyncop_how, to choose how the operation has =
to be
>>   issued (sync or async).
>> =

>> * libxl_device_disk_add waits for backend to switch to state 2 (XenbusIn=
itWait)
>>   and then launches the hotplug script.
>> =

>> * libxl__devices_destroy no longer calls libxl__device_destroy, and inst=
ead
>>   calls libxl__initiate_device_remove, so we can disconnect the device a=
nd
>>   execute the necessary hotplug scripts instead of just deleting the bac=
kend
>>   entries. So libxl__devices_destroy now uses the event library, and so =
does
>>   libxl_domain_destroy.
>> =

>> * Since libxl__devices_destroy calls multiple times
>>   libxl__initiate_device_remove, this function now returns a different v=
alue
>>   regarding the actions taken (if an event was added or not). The user h=
as to
>>   call libxl__ao_complete after using this function if necessary.
>> =

>> * The internal API for hotplug scripts has been added, which consists of=
 one
>>   function; libxl__device_hotplug that takes the device and the action to
>>   execute.
>> =

>> * Linux hotplug scripts are called by setting the necessary env variable=
s to
>>   emulate udev rules, so there's no need to change them (although a rewo=
rk to
>>   pass this as parameters insted of env variables would be suitable, so =
both
>>   NetBSD and Linux hotplug scripts take the same parameters).
>> =

>> * Added a check in xen-hotplug-common.sh, so scripts are only executed f=
rom
>>   udev when using xend. xl adds an execute_udev=3Dn to xenstore device b=
ackend
>>   and passes XL_CALL=3Dy to the env of the script call, and udev calls c=
heck that
>>   execute_udev is not set and XL_CALL is empty also.
>> =

>> I've also modified the python binding for pyxl_domain_destroy, that now =
take the
>> ao_how parameter, but I'm not really sure if it's done correctly, let's =
just say
>> that it compiles.
>> =

>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
>> tools/libxl/Makefile                      |    3 +-
>> tools/libxl/libxl.c                       |  104 ++++++++++++++++++----
>> tools/libxl/libxl.h                       |    7 +-
>> tools/libxl/libxl_create.c                |    4 +-
>> tools/libxl/libxl_device.c                |  140 +++++++++++++++++++++++=
++++--
>> tools/libxl/libxl_dm.c                    |    4 +-
>> tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++
>> tools/libxl/libxl_internal.h              |   43 +++++++++-
>> tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++++
>> tools/libxl/xl_cmdimpl.c                  |   14 ++--
>> tools/python/xen/lowlevel/xl/xl.c         |    5 +-
>> 12 files changed, 474 insertions(+), 40 deletions(-)
>> create mode 100644 tools/libxl/libxl_hotplug.c
>> =

>> diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/L=
inux/xen-hotplug-common.sh
>> index 8f6557d..dc3e867 100644
>> --- a/tools/hotplug/Linux/xen-hotplug-common.sh
>> +++ b/tools/hotplug/Linux/xen-hotplug-common.sh
>> @@ -15,6 +15,12 @@
>> # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  =
USA
>> #
>> =

>> +# Hack to prevent the execution of hotplug scripts form udev if the dom=
ain
> =

>                                                      from
>> +# has ben launched from libxl
> =

>        been


Done

> =

>> +execute_udev=3D`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
>> +if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
>> +    exit 0
>> +fi
> =

> So, am I right that in some future world where we have got rid of xend
> and made this stuff work without udev everywhere (e.g. including driver
> domains) there is a path to deprecating this snippet without requiring
> everyone to go through some sort of transition?
> =

> Or are we stuck with this envvar forever? It's not a big deal but if we
> can invert it (e.g. by setting ENV{HOTPLUG_GATE}=3D${XENBUS}/evecute_udev
> in xen-backend.rules and ...if -n "${HOTPLUG_GATE}" && xenstore-read
> ${HOTPLUG_GATE}... etc) then that would be nicer?


I will change it to something like:

if [ -z "${HOTPLUG_GATE}" ] && `xenstore-read "$HOTPLUG_GATE" 2>/dev/null` =
&& \
   [ -z "$XL_CALL" ]; then

and then set HOTPLUG_GATE from udev rules. I will change the xenstore gate =
to "disable_udev", which makes more sense, since we will be setting "disabl=
e_udev=3Dy" or nothing.

>> dir=3D$(dirname "$0")
>> . "$dir/hotplugpath.sh"
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 16ebef3..fb4fbf2 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, =
libxl_evgen_disk_eject *evg) {
>>     GC_FREE;
>> }
>> =

>> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
>> +                         const libxl_asyncop_how *ao_how)
>> {
>> -    GC_INIT(ctx);
>> +    AO_CREATE(ctx, domid, ao_how);
>>     char *dom_path;
>>     char *vm_path;
>>     char *pid;
>>     int rc, dm_present;
>> +    int rc_ao =3D 0;
>> =

>>     rc =3D libxl_domain_info(ctx, NULL, domid);
>>     switch(rc) {
>> @@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t =
domid)
>> =

>>         libxl__qmp_cleanup(gc, domid);
>>     }
>> -    if (libxl__devices_destroy(gc, domid) < 0)
>> +    rc_ao =3D libxl__devices_destroy(egc, ao, domid);
>> +    if (rc_ao < 0)
>>         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>>                    "libxl__devices_destroy failed for %d", domid);
>> =

>> @@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t=
 domid)
>>         goto out;
>>     }
>>     rc =3D 0;
>> +
>> out:
>> -    GC_FREE;
>> -    return rc;
>> +    if (rc_ao) return AO_ABORT(rc_ao);
>> +    return AO_INPROGRESS;
>> }
>> =

>> int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, lib=
xl_console_type type)
>> @@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc,=
 uint32_t domid,
>>     return 0;
>> }
>> =

>> -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_=
disk *disk)
>> +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
>> +                          libxl_device_disk *disk,
>> +                          const libxl_asyncop_how *ao_how)
>> {
>> -    GC_INIT(ctx);
>> +    AO_CREATE(ctx, domid, ao_how);
>>     flexarray_t *front;
>>     flexarray_t *back;
>>     char *dev;
>> @@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t=
 domid, libxl_device_disk *dis
>>         rc =3D ERROR_NOMEM;
>>         goto out;
>>     }
>> -    back =3D flexarray_make(16, 1);
>> +    back =3D flexarray_make(20, 1);
>>     if (!back) {
>>         rc =3D ERROR_NOMEM;
>>         goto out_free;
>> @@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_=
t domid, libxl_device_disk *dis
>>             flexarray_append(back, "params");
>>             flexarray_append(back, dev);
>> =

>> +            flexarray_append(back, "script");
>> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
>> +                                                  libxl_xen_script_dir_=
path(),
>> +                                                  "block"));
>> +
>>             assert(device.backend_kind =3D=3D LIBXL__DEVICE_KIND_VBD);
>>             break;
>>         case LIBXL_DISK_BACKEND_TAP:
>> @@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_=
t domid, libxl_device_disk *dis
>>                 libxl__device_disk_string_of_format(disk->format),
>>                 disk->pdev_path));
>> =

>> +            flexarray_append(back, "script");
>> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
>> +                             libxl_xen_script_dir_path(),
>> +                             "blktap"));
>> +
>>             /* now create a phy device to export the device to the guest=
 */
>>             goto do_backend_phy;
>>         case LIBXL_DISK_BACKEND_QDISK:
>> @@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t=
 domid, libxl_device_disk *dis
>>     flexarray_append(back, disk->readwrite ? "w" : "r");
>>     flexarray_append(back, "device-type");
>>     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
>> +    /* compatibility addon to keep udev rules */
>> +    flexarray_append(back, "execute_udev");
>> +    flexarray_append(back, "n");
>> =

>>     flexarray_append(front, "backend-id");
>>     flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid=
));
>> @@ -1420,14 +1439,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32=
_t domid, libxl_device_disk *dis
>>                              libxl__xs_kvs_of_flexarray(gc, back, back->=
count),
>>                              libxl__xs_kvs_of_flexarray(gc, front, front=
->count));
>> =

>> +    if (disk->backend =3D=3D LIBXL_DISK_BACKEND_PHY ||
>> +        disk->backend =3D=3D LIBXL_DISK_BACKEND_TAP) {
>> +        rc =3D libxl__initiate_device_add(egc, ao, &device);
>> +        if (rc) goto out_free;
>> +    } else {
>> +        /* no need to execute hotplug scripts */
>> +        libxl__ao_complete(egc, ao, 0);
>> +    }
> =

> This would be better as a switch, since it would make it more obvious
> that the "else" is actually "case LIBXL_DISK_BACKEND_QDISK" etc.
> =


Yes

> [...]
>> +
>> +/*
>> + * Return codes:
>> + * 1 Success and event(s) HAVE BEEN added
>> + * 0 Success and NO events where added
> =

>                              were
> =

> (I saw a few of these)

Will do a grep to see what I can find=85

Thanks for the review.

> =

>> + * < 0 Error
>> + *
>> + * Since this function can be called several times, and several events
>> + * can be added to the same context, the user has to call
>> + * libxl__ao_complete when necessary (if no events are added).
>> + */
>> int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>>                                   libxl__device *dev)
>> {
>> @@ -392,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, l=
ibxl__ao *ao,
> [...]
> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4BJ-0005yC-D3; Tue, 17 Apr 2012 08:54:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK4BI-0005y7-5W
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 08:54:36 +0000
Received: from [85.158.143.99:37744] by server-3.bemta-4.messagelabs.com id
	0F/B1-05853-BCF2D8F4; Tue, 17 Apr 2012 08:54:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334652872!23639122!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY5Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29536 invoked from network); 17 Apr 2012 08:54:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330923600"; d="scan'208";a="24222131"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 04:54:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 04:54:32 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK4BD-0007zl-NF;
	Tue, 17 Apr 2012 09:54:31 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334594686.14560.242.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 09:54:32 +0100
Message-ID: <8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
	<1334594686.14560.242.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 17:44, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>> This is a rather big change, that adds the necessary machinery to perform
>> hotplug script calling from libxl for Linux. This patch launches the nec=
essary
>> scripts to attach and detach PHY and TAP backend types (Qemu doesn't use=
 hotplug
>> scripts).
>> =

>> Here's a list of the major changes introduced:
>> =

>> * libxl_device_disk_add makes use of the new event library and takes the
>>   optional parameter libxl_asyncop_how, to choose how the operation has =
to be
>>   issued (sync or async).
>> =

>> * libxl_device_disk_add waits for backend to switch to state 2 (XenbusIn=
itWait)
>>   and then launches the hotplug script.
>> =

>> * libxl__devices_destroy no longer calls libxl__device_destroy, and inst=
ead
>>   calls libxl__initiate_device_remove, so we can disconnect the device a=
nd
>>   execute the necessary hotplug scripts instead of just deleting the bac=
kend
>>   entries. So libxl__devices_destroy now uses the event library, and so =
does
>>   libxl_domain_destroy.
>> =

>> * Since libxl__devices_destroy calls multiple times
>>   libxl__initiate_device_remove, this function now returns a different v=
alue
>>   regarding the actions taken (if an event was added or not). The user h=
as to
>>   call libxl__ao_complete after using this function if necessary.
>> =

>> * The internal API for hotplug scripts has been added, which consists of=
 one
>>   function; libxl__device_hotplug that takes the device and the action to
>>   execute.
>> =

>> * Linux hotplug scripts are called by setting the necessary env variable=
s to
>>   emulate udev rules, so there's no need to change them (although a rewo=
rk to
>>   pass this as parameters insted of env variables would be suitable, so =
both
>>   NetBSD and Linux hotplug scripts take the same parameters).
>> =

>> * Added a check in xen-hotplug-common.sh, so scripts are only executed f=
rom
>>   udev when using xend. xl adds an execute_udev=3Dn to xenstore device b=
ackend
>>   and passes XL_CALL=3Dy to the env of the script call, and udev calls c=
heck that
>>   execute_udev is not set and XL_CALL is empty also.
>> =

>> I've also modified the python binding for pyxl_domain_destroy, that now =
take the
>> ao_how parameter, but I'm not really sure if it's done correctly, let's =
just say
>> that it compiles.
>> =

>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
>> tools/libxl/Makefile                      |    3 +-
>> tools/libxl/libxl.c                       |  104 ++++++++++++++++++----
>> tools/libxl/libxl.h                       |    7 +-
>> tools/libxl/libxl_create.c                |    4 +-
>> tools/libxl/libxl_device.c                |  140 +++++++++++++++++++++++=
++++--
>> tools/libxl/libxl_dm.c                    |    4 +-
>> tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++
>> tools/libxl/libxl_internal.h              |   43 +++++++++-
>> tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++++
>> tools/libxl/xl_cmdimpl.c                  |   14 ++--
>> tools/python/xen/lowlevel/xl/xl.c         |    5 +-
>> 12 files changed, 474 insertions(+), 40 deletions(-)
>> create mode 100644 tools/libxl/libxl_hotplug.c
>> =

>> diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/L=
inux/xen-hotplug-common.sh
>> index 8f6557d..dc3e867 100644
>> --- a/tools/hotplug/Linux/xen-hotplug-common.sh
>> +++ b/tools/hotplug/Linux/xen-hotplug-common.sh
>> @@ -15,6 +15,12 @@
>> # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  =
USA
>> #
>> =

>> +# Hack to prevent the execution of hotplug scripts form udev if the dom=
ain
> =

>                                                      from
>> +# has ben launched from libxl
> =

>        been


Done

> =

>> +execute_udev=3D`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
>> +if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
>> +    exit 0
>> +fi
> =

> So, am I right that in some future world where we have got rid of xend
> and made this stuff work without udev everywhere (e.g. including driver
> domains) there is a path to deprecating this snippet without requiring
> everyone to go through some sort of transition?
> =

> Or are we stuck with this envvar forever? It's not a big deal but if we
> can invert it (e.g. by setting ENV{HOTPLUG_GATE}=3D${XENBUS}/evecute_udev
> in xen-backend.rules and ...if -n "${HOTPLUG_GATE}" && xenstore-read
> ${HOTPLUG_GATE}... etc) then that would be nicer?


I will change it to something like:

if [ -z "${HOTPLUG_GATE}" ] && `xenstore-read "$HOTPLUG_GATE" 2>/dev/null` =
&& \
   [ -z "$XL_CALL" ]; then

and then set HOTPLUG_GATE from udev rules. I will change the xenstore gate =
to "disable_udev", which makes more sense, since we will be setting "disabl=
e_udev=3Dy" or nothing.

>> dir=3D$(dirname "$0")
>> . "$dir/hotplugpath.sh"
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 16ebef3..fb4fbf2 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, =
libxl_evgen_disk_eject *evg) {
>>     GC_FREE;
>> }
>> =

>> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
>> +                         const libxl_asyncop_how *ao_how)
>> {
>> -    GC_INIT(ctx);
>> +    AO_CREATE(ctx, domid, ao_how);
>>     char *dom_path;
>>     char *vm_path;
>>     char *pid;
>>     int rc, dm_present;
>> +    int rc_ao =3D 0;
>> =

>>     rc =3D libxl_domain_info(ctx, NULL, domid);
>>     switch(rc) {
>> @@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t =
domid)
>> =

>>         libxl__qmp_cleanup(gc, domid);
>>     }
>> -    if (libxl__devices_destroy(gc, domid) < 0)
>> +    rc_ao =3D libxl__devices_destroy(egc, ao, domid);
>> +    if (rc_ao < 0)
>>         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>>                    "libxl__devices_destroy failed for %d", domid);
>> =

>> @@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t=
 domid)
>>         goto out;
>>     }
>>     rc =3D 0;
>> +
>> out:
>> -    GC_FREE;
>> -    return rc;
>> +    if (rc_ao) return AO_ABORT(rc_ao);
>> +    return AO_INPROGRESS;
>> }
>> =

>> int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, lib=
xl_console_type type)
>> @@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc,=
 uint32_t domid,
>>     return 0;
>> }
>> =

>> -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_=
disk *disk)
>> +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
>> +                          libxl_device_disk *disk,
>> +                          const libxl_asyncop_how *ao_how)
>> {
>> -    GC_INIT(ctx);
>> +    AO_CREATE(ctx, domid, ao_how);
>>     flexarray_t *front;
>>     flexarray_t *back;
>>     char *dev;
>> @@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t=
 domid, libxl_device_disk *dis
>>         rc =3D ERROR_NOMEM;
>>         goto out;
>>     }
>> -    back =3D flexarray_make(16, 1);
>> +    back =3D flexarray_make(20, 1);
>>     if (!back) {
>>         rc =3D ERROR_NOMEM;
>>         goto out_free;
>> @@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_=
t domid, libxl_device_disk *dis
>>             flexarray_append(back, "params");
>>             flexarray_append(back, dev);
>> =

>> +            flexarray_append(back, "script");
>> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
>> +                                                  libxl_xen_script_dir_=
path(),
>> +                                                  "block"));
>> +
>>             assert(device.backend_kind =3D=3D LIBXL__DEVICE_KIND_VBD);
>>             break;
>>         case LIBXL_DISK_BACKEND_TAP:
>> @@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_=
t domid, libxl_device_disk *dis
>>                 libxl__device_disk_string_of_format(disk->format),
>>                 disk->pdev_path));
>> =

>> +            flexarray_append(back, "script");
>> +            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
>> +                             libxl_xen_script_dir_path(),
>> +                             "blktap"));
>> +
>>             /* now create a phy device to export the device to the guest=
 */
>>             goto do_backend_phy;
>>         case LIBXL_DISK_BACKEND_QDISK:
>> @@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t=
 domid, libxl_device_disk *dis
>>     flexarray_append(back, disk->readwrite ? "w" : "r");
>>     flexarray_append(back, "device-type");
>>     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
>> +    /* compatibility addon to keep udev rules */
>> +    flexarray_append(back, "execute_udev");
>> +    flexarray_append(back, "n");
>> =

>>     flexarray_append(front, "backend-id");
>>     flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid=
));
>> @@ -1420,14 +1439,23 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32=
_t domid, libxl_device_disk *dis
>>                              libxl__xs_kvs_of_flexarray(gc, back, back->=
count),
>>                              libxl__xs_kvs_of_flexarray(gc, front, front=
->count));
>> =

>> +    if (disk->backend =3D=3D LIBXL_DISK_BACKEND_PHY ||
>> +        disk->backend =3D=3D LIBXL_DISK_BACKEND_TAP) {
>> +        rc =3D libxl__initiate_device_add(egc, ao, &device);
>> +        if (rc) goto out_free;
>> +    } else {
>> +        /* no need to execute hotplug scripts */
>> +        libxl__ao_complete(egc, ao, 0);
>> +    }
> =

> This would be better as a switch, since it would make it more obvious
> that the "else" is actually "case LIBXL_DISK_BACKEND_QDISK" etc.
> =


Yes

> [...]
>> +
>> +/*
>> + * Return codes:
>> + * 1 Success and event(s) HAVE BEEN added
>> + * 0 Success and NO events where added
> =

>                              were
> =

> (I saw a few of these)

Will do a grep to see what I can find=85

Thanks for the review.

> =

>> + * < 0 Error
>> + *
>> + * Since this function can be called several times, and several events
>> + * can be added to the same context, the user has to call
>> + * libxl__ao_complete when necessary (if no events are added).
>> + */
>> int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>>                                   libxl__device *dev)
>> {
>> @@ -392,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, l=
ibxl__ao *ao,
> [...]
> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4DD-00062t-UE; Tue, 17 Apr 2012 08:56:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4DC-00062g-Da
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 08:56:34 +0000
Received: from [85.158.138.51:52073] by server-2.bemta-3.messagelabs.com id
	CA/6F-09269-1403D8F4; Tue, 17 Apr 2012 08:56:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334652992!22452986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1882 invoked from network); 17 Apr 2012 08:56:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11970798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 08:56:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 09:56:17 +0100
Message-ID: <1334652975.14560.256.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 17 Apr 2012 09:56:15 +0100
In-Reply-To: <8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
	<1334594686.14560.242.camel@zakaz.uk.xensource.com>
	<8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
 for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDA5OjU0ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gRWwgMTYvMDQvMjAxMiwgYSBsYXMgMTc6NDQsIElhbiBDYW1wYmVsbCBlc2NyaWJpw7M6Cj4g
Pj4gK2V4ZWN1dGVfdWRldj1geGVuc3RvcmUtcmVhZCAkWEVOQlVTX1BBVEgvZXhlY3V0ZV91ZGV2
IDI+L2Rldi9udWxsYAo+ID4+ICtpZiBbIC1uICIkZXhlY3V0ZV91ZGV2IiBdICYmIFsgLXogIiRY
TF9DQUxMIiBdOyB0aGVuCj4gPj4gKyAgICBleGl0IDAKPiA+PiArZmkKPiA+IAo+ID4gU28sIGFt
IEkgcmlnaHQgdGhhdCBpbiBzb21lIGZ1dHVyZSB3b3JsZCB3aGVyZSB3ZSBoYXZlIGdvdCByaWQg
b2YgeGVuZAo+ID4gYW5kIG1hZGUgdGhpcyBzdHVmZiB3b3JrIHdpdGhvdXQgdWRldiBldmVyeXdo
ZXJlIChlLmcuIGluY2x1ZGluZyBkcml2ZXIKPiA+IGRvbWFpbnMpIHRoZXJlIGlzIGEgcGF0aCB0
byBkZXByZWNhdGluZyB0aGlzIHNuaXBwZXQgd2l0aG91dCByZXF1aXJpbmcKPiA+IGV2ZXJ5b25l
IHRvIGdvIHRocm91Z2ggc29tZSBzb3J0IG9mIHRyYW5zaXRpb24/Cj4gPiAKPiA+IE9yIGFyZSB3
ZSBzdHVjayB3aXRoIHRoaXMgZW52dmFyIGZvcmV2ZXI/IEl0J3Mgbm90IGEgYmlnIGRlYWwgYnV0
IGlmIHdlCj4gPiBjYW4gaW52ZXJ0IGl0IChlLmcuIGJ5IHNldHRpbmcgRU5We0hPVFBMVUdfR0FU
RX09JHtYRU5CVVN9L2V2ZWN1dGVfdWRldgo+ID4gaW4geGVuLWJhY2tlbmQucnVsZXMgYW5kIC4u
LmlmIC1uICIke0hPVFBMVUdfR0FURX0iICYmIHhlbnN0b3JlLXJlYWQKPiA+ICR7SE9UUExVR19H
QVRFfS4uLiBldGMpIHRoZW4gdGhhdCB3b3VsZCBiZSBuaWNlcj8KPiAKPiAKPiBJIHdpbGwgY2hh
bmdlIGl0IHRvIHNvbWV0aGluZyBsaWtlOgo+IAo+IGlmIFsgLXogIiR7SE9UUExVR19HQVRFfSIg
XSAmJiBgeGVuc3RvcmUtcmVhZCAiJEhPVFBMVUdfR0FURSIgMj4vZGV2L251bGxgICYmIFwKPiAg
ICBbIC16ICIkWExfQ0FMTCIgXTsgdGhlbgoKRG8geW91IHN0aWxsIG5lZWQgJFhMX0NBTEw/CgpJ
YW4uCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 17 08:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 08:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4DD-00062t-UE; Tue, 17 Apr 2012 08:56:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4DC-00062g-Da
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 08:56:34 +0000
Received: from [85.158.138.51:52073] by server-2.bemta-3.messagelabs.com id
	CA/6F-09269-1403D8F4; Tue, 17 Apr 2012 08:56:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334652992!22452986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDU1Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1882 invoked from network); 17 Apr 2012 08:56:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 08:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11970798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 08:56:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 09:56:17 +0100
Message-ID: <1334652975.14560.256.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 17 Apr 2012 09:56:15 +0100
In-Reply-To: <8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
	<1334594686.14560.242.camel@zakaz.uk.xensource.com>
	<8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
 for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDA5OjU0ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gRWwgMTYvMDQvMjAxMiwgYSBsYXMgMTc6NDQsIElhbiBDYW1wYmVsbCBlc2NyaWJpw7M6Cj4g
Pj4gK2V4ZWN1dGVfdWRldj1geGVuc3RvcmUtcmVhZCAkWEVOQlVTX1BBVEgvZXhlY3V0ZV91ZGV2
IDI+L2Rldi9udWxsYAo+ID4+ICtpZiBbIC1uICIkZXhlY3V0ZV91ZGV2IiBdICYmIFsgLXogIiRY
TF9DQUxMIiBdOyB0aGVuCj4gPj4gKyAgICBleGl0IDAKPiA+PiArZmkKPiA+IAo+ID4gU28sIGFt
IEkgcmlnaHQgdGhhdCBpbiBzb21lIGZ1dHVyZSB3b3JsZCB3aGVyZSB3ZSBoYXZlIGdvdCByaWQg
b2YgeGVuZAo+ID4gYW5kIG1hZGUgdGhpcyBzdHVmZiB3b3JrIHdpdGhvdXQgdWRldiBldmVyeXdo
ZXJlIChlLmcuIGluY2x1ZGluZyBkcml2ZXIKPiA+IGRvbWFpbnMpIHRoZXJlIGlzIGEgcGF0aCB0
byBkZXByZWNhdGluZyB0aGlzIHNuaXBwZXQgd2l0aG91dCByZXF1aXJpbmcKPiA+IGV2ZXJ5b25l
IHRvIGdvIHRocm91Z2ggc29tZSBzb3J0IG9mIHRyYW5zaXRpb24/Cj4gPiAKPiA+IE9yIGFyZSB3
ZSBzdHVjayB3aXRoIHRoaXMgZW52dmFyIGZvcmV2ZXI/IEl0J3Mgbm90IGEgYmlnIGRlYWwgYnV0
IGlmIHdlCj4gPiBjYW4gaW52ZXJ0IGl0IChlLmcuIGJ5IHNldHRpbmcgRU5We0hPVFBMVUdfR0FU
RX09JHtYRU5CVVN9L2V2ZWN1dGVfdWRldgo+ID4gaW4geGVuLWJhY2tlbmQucnVsZXMgYW5kIC4u
LmlmIC1uICIke0hPVFBMVUdfR0FURX0iICYmIHhlbnN0b3JlLXJlYWQKPiA+ICR7SE9UUExVR19H
QVRFfS4uLiBldGMpIHRoZW4gdGhhdCB3b3VsZCBiZSBuaWNlcj8KPiAKPiAKPiBJIHdpbGwgY2hh
bmdlIGl0IHRvIHNvbWV0aGluZyBsaWtlOgo+IAo+IGlmIFsgLXogIiR7SE9UUExVR19HQVRFfSIg
XSAmJiBgeGVuc3RvcmUtcmVhZCAiJEhPVFBMVUdfR0FURSIgMj4vZGV2L251bGxgICYmIFwKPiAg
ICBbIC16ICIkWExfQ0FMTCIgXTsgdGhlbgoKRG8geW91IHN0aWxsIG5lZWQgJFhMX0NBTEw/CgpJ
YW4uCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:05:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4Lw-0006P2-AF; Tue, 17 Apr 2012 09:05:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4Lv-0006Ox-HZ
	for Xen-devel@lists.xensource.com; Tue, 17 Apr 2012 09:05:35 +0000
Received: from [85.158.138.51:15650] by server-4.bemta-3.messagelabs.com id
	99/C0-15341-E523D8F4; Tue, 17 Apr 2012 09:05:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334653530!22284673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18565 invoked from network); 17 Apr 2012 09:05:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:05:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:05:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:05:30 +0100
Message-ID: <1334653528.14560.261.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 17 Apr 2012 10:05:28 +0100
In-Reply-To: <20120416185340.72ef5566@mantra.us.oracle.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
	<20120416185340.72ef5566@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
> On Mon, 16 Apr 2012 14:53:22 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > > Similar to 
> > >  * XENMEM_add_to_physmap
> > 
> > Why a whole new hypercall rather than a new XENMAPSPACE for the
> > exiting XENMEM_add_to_physmap.
> 
> > Ideally we'd have the definition of this (or the equivalent mod to the
> > XENMEM_add_to_physmap associated struct) for context, but I can
> > probably guess what the content looks like.
> 
> Not a new hcall, just a new subcall.

Sorry, I meant why a whole new subcall instead of a new XENMAPSPACE ;-)

e.g. On ARM I did:

diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 

Effectively stealing the (currently always zero) top 16 bits of the
space member for the foreign domid.


>  Forgot to include the struct:
> 
> #define XENMEM_add_foreign_to_pmap_batch      19
> struct xen_add_to_foreign_pmap_batch {
>     domid_t foreign_domid;         /* IN: gmfn belongs to this domain */
>     int count;                     /* IN/OUT: number of contigous
> frames */ unsigned long     gpfn;        /* IN: pfn in the current
> domain */ unsigned long     gmfn;        /* IN: from foreign domain */
>     int fpmap_flags;               /* future use */
> };
> typedef struct xen_add_to_foreign_pmap_batch
> xen_add_to_foreign_pmap_batch_t;
> DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_foreign_pmap_batch_t);
> 
> 
> > > 	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);
> > 
> > This ends up setting the page type to p2m_mmio_direct, which doesn't
> > seem likely to be correct. Perhaps you should be calling
> > set_p2m_entry()? Or adding a set_ram_p2m_entry which does similar
> > checks etc to set_mmio_p2m_entry (or maybe you could abstract out
> > some generic bits there)?
> 
> well, set_mmio_p2m_entry() calls set_p2m_entry() with a couple checks.
> I can add those to my function and just call set_p2m_entry too. It says
> mmio, but doesn't seem to do anything mmio specific. 

If that's the case perhaps you could rename it and add the type as a
parameter?

If not then I wouldn't add those checks to your function -- create a new
wrapper (set_ram_p2m_entry or whatever) with the checks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:05:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4Lw-0006P2-AF; Tue, 17 Apr 2012 09:05:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4Lv-0006Ox-HZ
	for Xen-devel@lists.xensource.com; Tue, 17 Apr 2012 09:05:35 +0000
Received: from [85.158.138.51:15650] by server-4.bemta-3.messagelabs.com id
	99/C0-15341-E523D8F4; Tue, 17 Apr 2012 09:05:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334653530!22284673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18565 invoked from network); 17 Apr 2012 09:05:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:05:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:05:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:05:30 +0100
Message-ID: <1334653528.14560.261.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 17 Apr 2012 10:05:28 +0100
In-Reply-To: <20120416185340.72ef5566@mantra.us.oracle.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
	<20120416185340.72ef5566@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
> On Mon, 16 Apr 2012 14:53:22 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > > Similar to 
> > >  * XENMEM_add_to_physmap
> > 
> > Why a whole new hypercall rather than a new XENMAPSPACE for the
> > exiting XENMEM_add_to_physmap.
> 
> > Ideally we'd have the definition of this (or the equivalent mod to the
> > XENMEM_add_to_physmap associated struct) for context, but I can
> > probably guess what the content looks like.
> 
> Not a new hcall, just a new subcall.

Sorry, I meant why a whole new subcall instead of a new XENMAPSPACE ;-)

e.g. On ARM I did:

diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 

Effectively stealing the (currently always zero) top 16 bits of the
space member for the foreign domid.


>  Forgot to include the struct:
> 
> #define XENMEM_add_foreign_to_pmap_batch      19
> struct xen_add_to_foreign_pmap_batch {
>     domid_t foreign_domid;         /* IN: gmfn belongs to this domain */
>     int count;                     /* IN/OUT: number of contigous
> frames */ unsigned long     gpfn;        /* IN: pfn in the current
> domain */ unsigned long     gmfn;        /* IN: from foreign domain */
>     int fpmap_flags;               /* future use */
> };
> typedef struct xen_add_to_foreign_pmap_batch
> xen_add_to_foreign_pmap_batch_t;
> DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_foreign_pmap_batch_t);
> 
> 
> > > 	rc = set_mmio_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn);
> > 
> > This ends up setting the page type to p2m_mmio_direct, which doesn't
> > seem likely to be correct. Perhaps you should be calling
> > set_p2m_entry()? Or adding a set_ram_p2m_entry which does similar
> > checks etc to set_mmio_p2m_entry (or maybe you could abstract out
> > some generic bits there)?
> 
> well, set_mmio_p2m_entry() calls set_p2m_entry() with a couple checks.
> I can add those to my function and just call set_p2m_entry too. It says
> mmio, but doesn't seem to do anything mmio specific. 

If that's the case perhaps you could rename it and add the type as a
parameter?

If not then I wouldn't add those checks to your function -- create a new
wrapper (set_ram_p2m_entry or whatever) with the checks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4TZ-0006YK-HN; Tue, 17 Apr 2012 09:13:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK4TY-0006YE-Qf
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:13:29 +0000
Received: from [85.158.138.51:54638] by server-1.bemta-3.messagelabs.com id
	7E/63-11491-8343D8F4; Tue, 17 Apr 2012 09:13:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334654005!22286582!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29030 invoked from network); 17 Apr 2012 09:13:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:13:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330923600"; d="scan'208";a="190672159"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 05:13:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 05:13:06 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK4TB-0008I4-RR;
	Tue, 17 Apr 2012 10:13:05 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334652975.14560.256.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 10:13:06 +0100
Message-ID: <6512AEED-B0FC-4048-B16D-D5B0053A6FFB@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
	<1334594686.14560.242.camel@zakaz.uk.xensource.com>
	<8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
	<1334652975.14560.256.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 09:54, Roger Pau Monne escribi=F3:
> On Tue, 2012-04-17 at 09:54 +0100, Roger Pau Monne wrote:
>> El 16/04/2012, a las 17:44, Ian Campbell escribi=F3:
>>>> +execute_udev=3D`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
>>>> +if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
>>>> +    exit 0
>>>> +fi
>>> =

>>> So, am I right that in some future world where we have got rid of xend
>>> and made this stuff work without udev everywhere (e.g. including driver
>>> domains) there is a path to deprecating this snippet without requiring
>>> everyone to go through some sort of transition?
>>> =

>>> Or are we stuck with this envvar forever? It's not a big deal but if we
>>> can invert it (e.g. by setting ENV{HOTPLUG_GATE}=3D${XENBUS}/evecute_ud=
ev
>>> in xen-backend.rules and ...if -n "${HOTPLUG_GATE}" && xenstore-read
>>> ${HOTPLUG_GATE}... etc) then that would be nicer?
>> =

>> =

>> I will change it to something like:
>> =

>> if [ -z "${HOTPLUG_GATE}" ] && `xenstore-read "$HOTPLUG_GATE" 2>/dev/nul=
l` && \
>>   [ -z "$XL_CALL" ]; then
> =

> Do you still need $XL_CALL?

No, with HOTPLUG_GATE it's enough, thanks again.

> =

> Ian.
> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4TZ-0006YK-HN; Tue, 17 Apr 2012 09:13:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK4TY-0006YE-Qf
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:13:29 +0000
Received: from [85.158.138.51:54638] by server-1.bemta-3.messagelabs.com id
	7E/63-11491-8343D8F4; Tue, 17 Apr 2012 09:13:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334654005!22286582!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29030 invoked from network); 17 Apr 2012 09:13:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:13:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330923600"; d="scan'208";a="190672159"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 05:13:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 05:13:06 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK4TB-0008I4-RR;
	Tue, 17 Apr 2012 10:13:05 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334652975.14560.256.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 10:13:06 +0100
Message-ID: <6512AEED-B0FC-4048-B16D-D5B0053A6FFB@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-3-git-send-email-roger.pau@citrix.com>
	<1334594686.14560.242.camel@zakaz.uk.xensource.com>
	<8051D1D1-ECA8-4FD6-89A4-22D8BA65880B@citrix.com>
	<1334652975.14560.256.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 09:54, Roger Pau Monne escribi=F3:
> On Tue, 2012-04-17 at 09:54 +0100, Roger Pau Monne wrote:
>> El 16/04/2012, a las 17:44, Ian Campbell escribi=F3:
>>>> +execute_udev=3D`xenstore-read $XENBUS_PATH/execute_udev 2>/dev/null`
>>>> +if [ -n "$execute_udev" ] && [ -z "$XL_CALL" ]; then
>>>> +    exit 0
>>>> +fi
>>> =

>>> So, am I right that in some future world where we have got rid of xend
>>> and made this stuff work without udev everywhere (e.g. including driver
>>> domains) there is a path to deprecating this snippet without requiring
>>> everyone to go through some sort of transition?
>>> =

>>> Or are we stuck with this envvar forever? It's not a big deal but if we
>>> can invert it (e.g. by setting ENV{HOTPLUG_GATE}=3D${XENBUS}/evecute_ud=
ev
>>> in xen-backend.rules and ...if -n "${HOTPLUG_GATE}" && xenstore-read
>>> ${HOTPLUG_GATE}... etc) then that would be nicer?
>> =

>> =

>> I will change it to something like:
>> =

>> if [ -z "${HOTPLUG_GATE}" ] && `xenstore-read "$HOTPLUG_GATE" 2>/dev/nul=
l` && \
>>   [ -z "$XL_CALL" ]; then
> =

> Do you still need $XL_CALL?

No, with HOTPLUG_GATE it's enough, thanks again.

> =

> Ian.
> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:18:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:18:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4YK-0006gn-Jz; Tue, 17 Apr 2012 09:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4YJ-0006gf-CU
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:18:23 +0000
Received: from [85.158.143.35:54423] by server-1.bemta-4.messagelabs.com id
	15/3C-20925-E553D8F4; Tue, 17 Apr 2012 09:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334654301!7417669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2744 invoked from network); 17 Apr 2012 09:18:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:18:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:18:21 +0100
Message-ID: <1334654299.14560.268.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:18:19 +0100
In-Reply-To: <1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> Remove a lot of unnecessary tests.  Specifically, we no longer test
> for standard POSIX facilities which we expect to be provided
> everywhere and which we don't in any case have any alternative for.

A good rule of thumb might be that if it isn't provided by "apt-get
install build-essential" (or the common set of stuff from the equivalent
meta-packages across common distros) then configure should check for it
in the interest of providing a useful upfront error message?

> Switch to generating config.h.in with autoheader.

> @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
>  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
>  AC_SUBST(libgcrypt)
>  AX_CHECK_PTHREAD
> -AC_CHECK_LIB([rt], [clock_gettime])

-lrt is always available? -l<one-or-two-letters> libraries seem to be
the ones which tend to differ across platforms, despite being
standardised...

> +AX_CHECK_PTYFUNCS

You don't actually add this until the next patch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:18:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:18:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4YK-0006gn-Jz; Tue, 17 Apr 2012 09:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4YJ-0006gf-CU
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:18:23 +0000
Received: from [85.158.143.35:54423] by server-1.bemta-4.messagelabs.com id
	15/3C-20925-E553D8F4; Tue, 17 Apr 2012 09:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334654301!7417669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2744 invoked from network); 17 Apr 2012 09:18:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:18:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:18:21 +0100
Message-ID: <1334654299.14560.268.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:18:19 +0100
In-Reply-To: <1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> Remove a lot of unnecessary tests.  Specifically, we no longer test
> for standard POSIX facilities which we expect to be provided
> everywhere and which we don't in any case have any alternative for.

A good rule of thumb might be that if it isn't provided by "apt-get
install build-essential" (or the common set of stuff from the equivalent
meta-packages across common distros) then configure should check for it
in the interest of providing a useful upfront error message?

> Switch to generating config.h.in with autoheader.

> @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
>  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
>  AC_SUBST(libgcrypt)
>  AX_CHECK_PTHREAD
> -AC_CHECK_LIB([rt], [clock_gettime])

-lrt is always available? -l<one-or-two-letters> libraries seem to be
the ones which tend to differ across platforms, despite being
standardised...

> +AX_CHECK_PTYFUNCS

You don't actually add this until the next patch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:20:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4aQ-0006nV-AT; Tue, 17 Apr 2012 09:20:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4aO-0006nN-Hl
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:20:32 +0000
Received: from [85.158.139.83:14603] by server-4.bemta-5.messagelabs.com id
	06/9A-10788-FD53D8F4; Tue, 17 Apr 2012 09:20:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334654430!21440250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15578 invoked from network); 17 Apr 2012 09:20:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:20:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:20:31 +0100
Message-ID: <1334654429.14560.269.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:20:29 +0100
In-Reply-To: <1334596686-8479-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/24] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[...]
> -AX_CHECK_PTYFUNCS
> +
> +    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
> +if test "x$ac_cv_header_libutil_h" = x""yes; then :
> +
...

That's the error from the previous patch.

Assuming that's fixed in the obvious way:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:20:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4aQ-0006nV-AT; Tue, 17 Apr 2012 09:20:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4aO-0006nN-Hl
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:20:32 +0000
Received: from [85.158.139.83:14603] by server-4.bemta-5.messagelabs.com id
	06/9A-10788-FD53D8F4; Tue, 17 Apr 2012 09:20:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334654430!21440250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15578 invoked from network); 17 Apr 2012 09:20:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:20:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:20:31 +0100
Message-ID: <1334654429.14560.269.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:20:29 +0100
In-Reply-To: <1334596686-8479-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/24] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[...]
> -AX_CHECK_PTYFUNCS
> +
> +    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
> +if test "x$ac_cv_header_libutil_h" = x""yes; then :
> +
...

That's the error from the previous patch.

Assuming that's fixed in the obvious way:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:37:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4qs-0007Ft-P2; Tue, 17 Apr 2012 09:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4qr-0007FW-S0
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:37:34 +0000
Received: from [85.158.143.35:27825] by server-1.bemta-4.messagelabs.com id
	48/44-20925-DD93D8F4; Tue, 17 Apr 2012 09:37:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334655452!14873230!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27095 invoked from network); 17 Apr 2012 09:37:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:37:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:37:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:37:32 +0100
Message-ID: <1334655450.14560.270.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:37:30 +0100
In-Reply-To: <1334596686-8479-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/24] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> General facility for ao operations to shovel data between fds.
> 
> This will be used by the bootloader machinery.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes since v6
>  * assert that the ao is non-null on _init.
> ---
>  tools/libxl/Makefile         |    3 +-
>  tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   40 +++++++++
>  3 files changed, 231 insertions(+), 1 deletions(-)
>  create mode 100644 tools/libxl/libxl_aoutils.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 5ba144f..6e253b1 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
> 
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
> -                       libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
> +                       libxl_internal.o libxl_utils.o libxl_uuid.o \
> +                       libxl_json.o libxl_aoutils.o \
>                         libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> new file mode 100644
> index 0000000..4c60ad9
> --- /dev/null
> +++ b/tools/libxl/libxl_aoutils.c
> @@ -0,0 +1,189 @@
> +/*
> + * Copyright (C) 2010      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
> +#include "libxl_internal.h"
> +
> +/*----- data copier -----*/
> +
> +void libxl__datacopier_init(libxl__datacopier_state *dc)
> +{
> +    assert(dc->ao);
> +    libxl__ev_fd_init(&dc->toread);
> +    libxl__ev_fd_init(&dc->towrite);
> +    LIBXL_TAILQ_INIT(&dc->bufs);
> +}
> +
> +void libxl__datacopier_kill(libxl__datacopier_state *dc)
> +{
> +    STATE_AO_GC(dc->ao);
> +    libxl__datacopier_buf *buf, *tbuf;
> +
> +    libxl__ev_fd_deregister(gc, &dc->toread);
> +    libxl__ev_fd_deregister(gc, &dc->towrite);
> +    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
> +        free(buf);
> +    LIBXL_TAILQ_INIT(&dc->bufs);
> +}
> +
> +static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
> +                                int onwrite, int errnoval)
> +{
> +    libxl__datacopier_kill(dc);
> +    dc->callback(egc, dc, onwrite, errnoval);
> +}
> +
> +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents);
> +
> +static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
> +{
> +    STATE_AO_GC(dc->ao);
> +    int rc;
> +
> +    if (dc->used) {
> +        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
> +            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
> +                                       dc->writefd, POLLOUT);
> +            if (rc) {
> +                LOG(ERROR, "unable to establish write event on %s"
> +                    " during copy of %s", dc->writewhat, dc->copywhat);
> +                datacopier_callback(egc, dc, -1, 0);
> +                return;
> +            }
> +        }
> +    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
> +        /* we have had eof */
> +        datacopier_callback(egc, dc, 0, 0);
> +        return;
> +    } else {
> +        /* nothing buffered, but still reading */
> +        libxl__ev_fd_deregister(gc, &dc->towrite);
> +    }
> +}
> +
> +static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents) {
> +    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
> +    STATE_AO_GC(dc->ao);
> +
> +    if (revents & ~POLLIN) {
> +        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
> +            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
> +        datacopier_callback(egc, dc, -1, 0);
> +        return;
> +    }
> +    assert(revents & POLLIN);
> +    for (;;) {
> +        while (dc->used >= dc->maxsz) {
> +            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
> +            dc->used -= rm->used;
> +            assert(dc->used >= 0);
> +            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
> +            free(rm);
> +        }
> +
> +        libxl__datacopier_buf *buf =
> +            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
> +        if (!buf || buf->used >= sizeof(buf->buf)) {
> +            buf = malloc(sizeof(*buf));
> +            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
> +            buf->used = 0;
> +            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
> +        }
> +        int r = read(ev->fd,
> +                     buf->buf + buf->used,
> +                     sizeof(buf->buf) - buf->used);
> +        if (r < 0) {
> +            if (errno == EINTR) continue;
> +            if (errno == EWOULDBLOCK) break;
> +            LOGE(ERROR, "error reading %s during copy of %s",
> +                 dc->readwhat, dc->copywhat);
> +            datacopier_callback(egc, dc, 0, errno);
> +            return;
> +        }
> +        if (r == 0) {
> +            libxl__ev_fd_deregister(gc, &dc->toread);
> +            break;
> +        }
> +        buf->used += r;
> +        dc->used += r;
> +        assert(buf->used <= sizeof(buf->buf));
> +    }
> +    datacopier_check_state(egc, dc);
> +}
> +
> +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents) {
> +    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
> +    STATE_AO_GC(dc->ao);
> +
> +    if (revents & ~POLLOUT) {
> +        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
> +            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
> +        datacopier_callback(egc, dc, -1, 0);
> +        return;
> +    }
> +    assert(revents & POLLOUT);
> +    for (;;) {
> +        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
> +        if (!buf)
> +            break;
> +        if (!buf->used) {
> +            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
> +            free(buf);
> +            continue;
> +        }
> +        int r = write(ev->fd, buf->buf, buf->used);
> +        if (r < 0) {
> +            if (errno == EINTR) continue;
> +            if (errno == EWOULDBLOCK) break;
> +            LOGE(ERROR, "error writing to %s during copy of %s",
> +                 dc->writewhat, dc->copywhat);
> +            datacopier_callback(egc, dc, 1, errno);
> +            return;
> +        }
> +        assert(r > 0);
> +        assert(r <= buf->used);
> +        buf->used -= r;
> +        dc->used -= r;
> +        assert(dc->used >= 0);
> +        memmove(buf->buf, buf->buf+r, buf->used);
> +    }
> +    datacopier_check_state(egc, dc);
> +}
> +
> +int libxl__datacopier_start(libxl__datacopier_state *dc)
> +{
> +    int rc;
> +    STATE_AO_GC(dc->ao);
> +
> +    libxl__datacopier_init(dc);
> +
> +    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
> +                               dc->readfd, POLLIN);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
> +                               dc->writefd, POLLOUT);
> +    if (rc) goto out;
> +
> +    return 0;
> +
> + out:
> +    libxl__datacopier_kill(dc);
> +    return rc;
> +}
> +
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 6ceb362..20c95db 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -833,6 +833,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
>   */
>  _hidden int libxl__try_phy_backend(mode_t st_mode);
> 
> +
>  /* from libxl_pci */
> 
>  _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
> @@ -1458,6 +1459,45 @@ int libxl__carefd_close(libxl__carefd*);
>  int libxl__carefd_fd(const libxl__carefd*);
> 
> 
> +/*----- datacopier: copies data from one fd to another -----*/
> +
> +typedef struct libxl__datacopier_state libxl__datacopier_state;
> +typedef struct libxl__datacopier_buf libxl__datacopier_buf;
> +
> +/* onwrite==1 means failure happened when writing, logged, errnoval is valid
> + * onwrite==0 means failure happened when reading
> + *     errnoval==0 means we got eof and all data was written
> + *     errnoval!=0 means we had a read error, logged
> + * onwrite==-1 means some other internal failure, errnoval not valid, logged
> + * in all cases copier is killed before calling this callback */
> +typedef void libxl__datacopier_callback(libxl__egc *egc,
> +     libxl__datacopier_state *dc, int onwrite, int errnoval);
> +
> +struct libxl__datacopier_buf {
> +    /* private to datacopier */
> +    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
> +    int used;
> +    char buf[1000];
> +};
> +
> +struct libxl__datacopier_state {
> +    /* caller must fill these in, and they must all remain valid */
> +    libxl__ao *ao;
> +    int readfd, writefd;
> +    ssize_t maxsz;
> +    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
> +    libxl__datacopier_callback *callback;
> +    /* remaining fields are private to datacopier */
> +    libxl__ev_fd toread, towrite;
> +    ssize_t used;
> +    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
> +};
> +
> +_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
> +_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
> +_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
> +
> +
>  /*
>   * Convenience macros.
>   */
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:37:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4qs-0007Ft-P2; Tue, 17 Apr 2012 09:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4qr-0007FW-S0
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:37:34 +0000
Received: from [85.158.143.35:27825] by server-1.bemta-4.messagelabs.com id
	48/44-20925-DD93D8F4; Tue, 17 Apr 2012 09:37:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1334655452!14873230!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27095 invoked from network); 17 Apr 2012 09:37:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:37:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11971988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:37:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:37:32 +0100
Message-ID: <1334655450.14560.270.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:37:30 +0100
In-Reply-To: <1334596686-8479-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/24] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> General facility for ao operations to shovel data between fds.
> 
> This will be used by the bootloader machinery.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes since v6
>  * assert that the ao is non-null on _init.
> ---
>  tools/libxl/Makefile         |    3 +-
>  tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   40 +++++++++
>  3 files changed, 231 insertions(+), 1 deletions(-)
>  create mode 100644 tools/libxl/libxl_aoutils.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 5ba144f..6e253b1 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -52,7 +52,8 @@ LIBXL_LIBS += -lyajl
> 
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
> -                       libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
> +                       libxl_internal.o libxl_utils.o libxl_uuid.o \
> +                       libxl_json.o libxl_aoutils.o \
>                         libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> new file mode 100644
> index 0000000..4c60ad9
> --- /dev/null
> +++ b/tools/libxl/libxl_aoutils.c
> @@ -0,0 +1,189 @@
> +/*
> + * Copyright (C) 2010      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
> +#include "libxl_internal.h"
> +
> +/*----- data copier -----*/
> +
> +void libxl__datacopier_init(libxl__datacopier_state *dc)
> +{
> +    assert(dc->ao);
> +    libxl__ev_fd_init(&dc->toread);
> +    libxl__ev_fd_init(&dc->towrite);
> +    LIBXL_TAILQ_INIT(&dc->bufs);
> +}
> +
> +void libxl__datacopier_kill(libxl__datacopier_state *dc)
> +{
> +    STATE_AO_GC(dc->ao);
> +    libxl__datacopier_buf *buf, *tbuf;
> +
> +    libxl__ev_fd_deregister(gc, &dc->toread);
> +    libxl__ev_fd_deregister(gc, &dc->towrite);
> +    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
> +        free(buf);
> +    LIBXL_TAILQ_INIT(&dc->bufs);
> +}
> +
> +static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
> +                                int onwrite, int errnoval)
> +{
> +    libxl__datacopier_kill(dc);
> +    dc->callback(egc, dc, onwrite, errnoval);
> +}
> +
> +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents);
> +
> +static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
> +{
> +    STATE_AO_GC(dc->ao);
> +    int rc;
> +
> +    if (dc->used) {
> +        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
> +            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
> +                                       dc->writefd, POLLOUT);
> +            if (rc) {
> +                LOG(ERROR, "unable to establish write event on %s"
> +                    " during copy of %s", dc->writewhat, dc->copywhat);
> +                datacopier_callback(egc, dc, -1, 0);
> +                return;
> +            }
> +        }
> +    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
> +        /* we have had eof */
> +        datacopier_callback(egc, dc, 0, 0);
> +        return;
> +    } else {
> +        /* nothing buffered, but still reading */
> +        libxl__ev_fd_deregister(gc, &dc->towrite);
> +    }
> +}
> +
> +static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents) {
> +    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
> +    STATE_AO_GC(dc->ao);
> +
> +    if (revents & ~POLLIN) {
> +        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
> +            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
> +        datacopier_callback(egc, dc, -1, 0);
> +        return;
> +    }
> +    assert(revents & POLLIN);
> +    for (;;) {
> +        while (dc->used >= dc->maxsz) {
> +            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
> +            dc->used -= rm->used;
> +            assert(dc->used >= 0);
> +            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
> +            free(rm);
> +        }
> +
> +        libxl__datacopier_buf *buf =
> +            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
> +        if (!buf || buf->used >= sizeof(buf->buf)) {
> +            buf = malloc(sizeof(*buf));
> +            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
> +            buf->used = 0;
> +            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
> +        }
> +        int r = read(ev->fd,
> +                     buf->buf + buf->used,
> +                     sizeof(buf->buf) - buf->used);
> +        if (r < 0) {
> +            if (errno == EINTR) continue;
> +            if (errno == EWOULDBLOCK) break;
> +            LOGE(ERROR, "error reading %s during copy of %s",
> +                 dc->readwhat, dc->copywhat);
> +            datacopier_callback(egc, dc, 0, errno);
> +            return;
> +        }
> +        if (r == 0) {
> +            libxl__ev_fd_deregister(gc, &dc->toread);
> +            break;
> +        }
> +        buf->used += r;
> +        dc->used += r;
> +        assert(buf->used <= sizeof(buf->buf));
> +    }
> +    datacopier_check_state(egc, dc);
> +}
> +
> +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                int fd, short events, short revents) {
> +    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
> +    STATE_AO_GC(dc->ao);
> +
> +    if (revents & ~POLLOUT) {
> +        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
> +            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
> +        datacopier_callback(egc, dc, -1, 0);
> +        return;
> +    }
> +    assert(revents & POLLOUT);
> +    for (;;) {
> +        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
> +        if (!buf)
> +            break;
> +        if (!buf->used) {
> +            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
> +            free(buf);
> +            continue;
> +        }
> +        int r = write(ev->fd, buf->buf, buf->used);
> +        if (r < 0) {
> +            if (errno == EINTR) continue;
> +            if (errno == EWOULDBLOCK) break;
> +            LOGE(ERROR, "error writing to %s during copy of %s",
> +                 dc->writewhat, dc->copywhat);
> +            datacopier_callback(egc, dc, 1, errno);
> +            return;
> +        }
> +        assert(r > 0);
> +        assert(r <= buf->used);
> +        buf->used -= r;
> +        dc->used -= r;
> +        assert(dc->used >= 0);
> +        memmove(buf->buf, buf->buf+r, buf->used);
> +    }
> +    datacopier_check_state(egc, dc);
> +}
> +
> +int libxl__datacopier_start(libxl__datacopier_state *dc)
> +{
> +    int rc;
> +    STATE_AO_GC(dc->ao);
> +
> +    libxl__datacopier_init(dc);
> +
> +    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
> +                               dc->readfd, POLLIN);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
> +                               dc->writefd, POLLOUT);
> +    if (rc) goto out;
> +
> +    return 0;
> +
> + out:
> +    libxl__datacopier_kill(dc);
> +    return rc;
> +}
> +
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 6ceb362..20c95db 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -833,6 +833,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
>   */
>  _hidden int libxl__try_phy_backend(mode_t st_mode);
> 
> +
>  /* from libxl_pci */
> 
>  _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
> @@ -1458,6 +1459,45 @@ int libxl__carefd_close(libxl__carefd*);
>  int libxl__carefd_fd(const libxl__carefd*);
> 
> 
> +/*----- datacopier: copies data from one fd to another -----*/
> +
> +typedef struct libxl__datacopier_state libxl__datacopier_state;
> +typedef struct libxl__datacopier_buf libxl__datacopier_buf;
> +
> +/* onwrite==1 means failure happened when writing, logged, errnoval is valid
> + * onwrite==0 means failure happened when reading
> + *     errnoval==0 means we got eof and all data was written
> + *     errnoval!=0 means we had a read error, logged
> + * onwrite==-1 means some other internal failure, errnoval not valid, logged
> + * in all cases copier is killed before calling this callback */
> +typedef void libxl__datacopier_callback(libxl__egc *egc,
> +     libxl__datacopier_state *dc, int onwrite, int errnoval);
> +
> +struct libxl__datacopier_buf {
> +    /* private to datacopier */
> +    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
> +    int used;
> +    char buf[1000];
> +};
> +
> +struct libxl__datacopier_state {
> +    /* caller must fill these in, and they must all remain valid */
> +    libxl__ao *ao;
> +    int readfd, writefd;
> +    ssize_t maxsz;
> +    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
> +    libxl__datacopier_callback *callback;
> +    /* remaining fields are private to datacopier */
> +    libxl__ev_fd toread, towrite;
> +    ssize_t used;
> +    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
> +};
> +
> +_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
> +_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
> +_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
> +
> +
>  /*
>   * Convenience macros.
>   */
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:40:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4to-0007Vx-ER; Tue, 17 Apr 2012 09:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4tn-0007Vq-6M
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:40:35 +0000
Received: from [85.158.143.35:48371] by server-1.bemta-4.messagelabs.com id
	A2/B9-20925-29A3D8F4; Tue, 17 Apr 2012 09:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334655633!12784555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26561 invoked from network); 17 Apr 2012 09:40:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11972086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:40:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:40:33 +0100
Message-ID: <1334655631.14560.272.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:40:31 +0100
In-Reply-To: <1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> Remove this obsolete hook.  Callers inside libxl which create and reap
> children should use the mechanisms provided by the event system.

The hook is unused which is good because otherwise I would have asked
for this patch to go after the patches to make the users use those
mechanisms. As it is removing the hook makes no semantic difference to
anyone.

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_exec.c     |   12 +++---------
>  tools/libxl/libxl_internal.h |    3 ---
>  2 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index b10e79f..2ee2154 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -19,11 +19,6 @@
>  
>  #include "libxl_internal.h"
>  
> -static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
> -{
> -    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
> -}
> -
>  static void check_open_fds(const char *what)
>  {
>      const char *env_debug;
> @@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
>  
>      if (!for_spawn) _exit(0); /* just detach then */
>  
> -    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
> +    got = waitpid(child, &status, 0);
>      assert(got == child);
>  
>      rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
> @@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
>                           (unsigned long)for_spawn->intermediate);
>              abort(); /* things are very wrong */
>          }
> -        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
> +        got = waitpid(for_spawn->intermediate, &status, 0);
>          assert(got == for_spawn->intermediate);
>          if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
>              report_spawn_intermediate_status(gc, for_spawn, status);
> @@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
>  
>  int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
>  {
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
>      pid_t got;
>      int status;
>  
>      if (!for_spawn) return 0;
>  
>      assert(for_spawn->intermediate);
> -    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
> +    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
>      if (!got) return 0;
>  
>      assert(got == for_spawn->intermediate);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 74dc2c5..ae71f70 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -334,9 +334,6 @@ struct libxl__ctx {
>      int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
>      LIBXL_LIST_HEAD(, libxl__ev_child) children;
>  
> -    /* This is obsolete and must be removed: */
> -    int (*waitpid_instead)(pid_t pid, int *status, int flags);
> -
>      libxl_version_info version_info;
>  };
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:40:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4to-0007Vx-ER; Tue, 17 Apr 2012 09:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4tn-0007Vq-6M
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:40:35 +0000
Received: from [85.158.143.35:48371] by server-1.bemta-4.messagelabs.com id
	A2/B9-20925-29A3D8F4; Tue, 17 Apr 2012 09:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334655633!12784555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26561 invoked from network); 17 Apr 2012 09:40:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11972086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:40:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:40:33 +0100
Message-ID: <1334655631.14560.272.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:40:31 +0100
In-Reply-To: <1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> Remove this obsolete hook.  Callers inside libxl which create and reap
> children should use the mechanisms provided by the event system.

The hook is unused which is good because otherwise I would have asked
for this patch to go after the patches to make the users use those
mechanisms. As it is removing the hook makes no semantic difference to
anyone.

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_exec.c     |   12 +++---------
>  tools/libxl/libxl_internal.h |    3 ---
>  2 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index b10e79f..2ee2154 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -19,11 +19,6 @@
>  
>  #include "libxl_internal.h"
>  
> -static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
> -{
> -    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
> -}
> -
>  static void check_open_fds(const char *what)
>  {
>      const char *env_debug;
> @@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
>  
>      if (!for_spawn) _exit(0); /* just detach then */
>  
> -    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
> +    got = waitpid(child, &status, 0);
>      assert(got == child);
>  
>      rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
> @@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
>                           (unsigned long)for_spawn->intermediate);
>              abort(); /* things are very wrong */
>          }
> -        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
> +        got = waitpid(for_spawn->intermediate, &status, 0);
>          assert(got == for_spawn->intermediate);
>          if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
>              report_spawn_intermediate_status(gc, for_spawn, status);
> @@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
>  
>  int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
>  {
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
>      pid_t got;
>      int status;
>  
>      if (!for_spawn) return 0;
>  
>      assert(for_spawn->intermediate);
> -    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
> +    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
>      if (!got) return 0;
>  
>      assert(got == for_spawn->intermediate);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 74dc2c5..ae71f70 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -334,9 +334,6 @@ struct libxl__ctx {
>      int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
>      LIBXL_LIST_HEAD(, libxl__ev_child) children;
>  
> -    /* This is obsolete and must be removed: */
> -    int (*waitpid_instead)(pid_t pid, int *status, int flags);
> -
>      libxl_version_info version_info;
>  };
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4tx-0007Wn-S3; Tue, 17 Apr 2012 09:40:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1SJyYq-0007q4-UU
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 02:54:33 +0000
Received: from [85.158.143.99:5850] by server-1.bemta-4.messagelabs.com id
	E7/32-20925-76BDC8F4; Tue, 17 Apr 2012 02:54:31 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334631268!18676061!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzQyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26887 invoked from network); 17 Apr 2012 02:54:30 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 02:54:30 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Apr 2012 08:24:25 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 08:24:22 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H2sLTV3903704
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 08:24:21 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3H8O7mR010380
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 18:24:09 +1000
Received: from linux.vnet.ibm.com ([9.79.235.211])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q3H8O59P010221; Tue, 17 Apr 2012 18:24:05 +1000
Date: Tue, 17 Apr 2012 08:24:16 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120417025416.GA10184@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
	<20120416154429.GB4654@phenom.dumpdata.com>
	<1334594195.14560.236.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334594195.14560.236.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
x-cbid: 12041702-9574-0000-0000-00000239DB90
X-Mailman-Approved-At: Tue, 17 Apr 2012 09:40:44 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* Ian Campbell <Ian.Campbell@citrix.com> [2012-04-16 17:36:35]:

> > > The current pv-spinlock patches however does not track which vcpu is
> > > spinning at what head of the ticketlock. I suppose we can consider 
> > > that optimization in future and see how much benefit it provides (over
> > > plain yield/sleep the way its done now).
> > 
> > Right. I think Jeremy played around with this some time?
> 
> 5/11 "xen/pvticketlock: Xen implementation for PV ticket locks" tracks
> which vcpus are waiting for a lock in "cpumask_t waiting_cpus" and
> tracks which lock each is waiting for in per-cpu "lock_waiting". This is
> used in xen_unlock_kick to kick the right CPU. There's a loop over only
> the waiting cpus to figure out who to kick.

Yes sorry that's right. We do track who is waiting on what lock at what
position. This can be used to pass directed yield hints to host
scheduler (in a future optimization patch). What we don't track is the
vcpu owning a lock, which would have allowed other spinning vcpus to do
a directed yield to vcpu preempted holding a lock. OTOH that may be
unnecessary if we put in support for deferring preemption of vcpu that
are holding locks.

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4tx-0007Wn-S3; Tue, 17 Apr 2012 09:40:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1SJyYq-0007q4-UU
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 02:54:33 +0000
Received: from [85.158.143.99:5850] by server-1.bemta-4.messagelabs.com id
	E7/32-20925-76BDC8F4; Tue, 17 Apr 2012 02:54:31 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334631268!18676061!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzQyNDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26887 invoked from network); 17 Apr 2012 02:54:30 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 02:54:30 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Apr 2012 08:24:25 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Apr 2012 08:24:22 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3H2sLTV3903704
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 08:24:21 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3H8O7mR010380
	for <xen-devel@lists.xensource.com>; Tue, 17 Apr 2012 18:24:09 +1000
Received: from linux.vnet.ibm.com ([9.79.235.211])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q3H8O59P010221; Tue, 17 Apr 2012 18:24:05 +1000
Date: Tue, 17 Apr 2012 08:24:16 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120417025416.GA10184@linux.vnet.ibm.com>
References: <20120321102041.473.61069.sendpatchset@codeblue.in.ibm.com>
	<4F7616F5.4070000@zytor.com>
	<alpine.LFD.2.02.1203302333560.2542@ionos>
	<20120331040745.GC14030@linux.vnet.ibm.com>
	<20120416154429.GB4654@phenom.dumpdata.com>
	<1334594195.14560.236.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334594195.14560.236.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
x-cbid: 12041702-9574-0000-0000-00000239DB90
X-Mailman-Approved-At: Tue, 17 Apr 2012 09:40:44 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Attilio Rao <attilio.rao@citrix.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 0/11] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* Ian Campbell <Ian.Campbell@citrix.com> [2012-04-16 17:36:35]:

> > > The current pv-spinlock patches however does not track which vcpu is
> > > spinning at what head of the ticketlock. I suppose we can consider 
> > > that optimization in future and see how much benefit it provides (over
> > > plain yield/sleep the way its done now).
> > 
> > Right. I think Jeremy played around with this some time?
> 
> 5/11 "xen/pvticketlock: Xen implementation for PV ticket locks" tracks
> which vcpus are waiting for a lock in "cpumask_t waiting_cpus" and
> tracks which lock each is waiting for in per-cpu "lock_waiting". This is
> used in xen_unlock_kick to kick the right CPU. There's a loop over only
> the waiting cpus to figure out who to kick.

Yes sorry that's right. We do track who is waiting on what lock at what
position. This can be used to pass directed yield hints to host
scheduler (in a future optimization patch). What we don't track is the
vcpu owning a lock, which would have allowed other spinning vcpus to do
a directed yield to vcpu preempted holding a lock. OTOH that may be
unnecessary if we put in support for deferring preemption of vcpu that
are holding locks.

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4uS-0007b5-Ac; Tue, 17 Apr 2012 09:41:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Abhinandan.Prateek@citrix.com>) id 1SK4uR-0007ak-9m
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:41:15 +0000
Received: from [85.158.143.99:30084] by server-3.bemta-4.messagelabs.com id
	40/38-05853-ABA3D8F4; Tue, 17 Apr 2012 09:41:14 +0000
X-Env-Sender: Abhinandan.Prateek@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334655669!14336224!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDM3NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23342 invoked from network); 17 Apr 2012 09:41:13 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208,217";a="11125617"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:41:08 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Tue, 17 Apr 2012
	15:11:07 +0530
From: Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Date: Tue, 17 Apr 2012 15:11:05 +0530
Thread-Topic: XCP 1.5 beta
Thread-Index: Ac0cYhb/X3GK7dftToaOl5wYm8XarAAHA91g
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09@BANPMAILBOX01.citrite.net>
References: <BD9F087D95FBF64289E2C393ABD448FAF932352D19@BANPMAILBOX01.citrite.net>
In-Reply-To: <BD9F087D95FBF64289E2C393ABD448FAF932352D19@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] XCP 1.5 beta
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3156185736951376186=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3156185736951376186==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


   In XCP 1.5 beta (version 1.4.9) there is a method get_mtime missing in /=
opt/xensource/sm/util.py.  It should be there in older versions of XCP.
We are having problems adding XCP 1.4.9 hosts to our cloud.  How can I go a=
bout helping in getting this rectified ?

-Abhi

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-IN link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c=
olor:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal>&nbsp;&nbsp;=
 In XCP 1.5 beta (version 1.4.9) there is a method get_mtime missing in /op=
t/xensource/sm/util.py. &nbsp;It should be there in older versions of XCP.<=
o:p></o:p></p><p class=3DMsoNormal>We are having problems adding XCP 1.4.9 =
hosts to our cloud.&nbsp; How can I go about helping in getting this rectif=
ied ?<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
oNormal>-Abhi<o:p></o:p></p></div></body></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_--


--===============3156185736951376186==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3156185736951376186==--


From xen-devel-bounces@lists.xen.org Tue Apr 17 09:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4uS-0007b5-Ac; Tue, 17 Apr 2012 09:41:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Abhinandan.Prateek@citrix.com>) id 1SK4uR-0007ak-9m
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:41:15 +0000
Received: from [85.158.143.99:30084] by server-3.bemta-4.messagelabs.com id
	40/38-05853-ABA3D8F4; Tue, 17 Apr 2012 09:41:14 +0000
X-Env-Sender: Abhinandan.Prateek@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334655669!14336224!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDM3NDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23342 invoked from network); 17 Apr 2012 09:41:13 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208,217";a="11125617"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:41:08 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Tue, 17 Apr 2012
	15:11:07 +0530
From: Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Date: Tue, 17 Apr 2012 15:11:05 +0530
Thread-Topic: XCP 1.5 beta
Thread-Index: Ac0cYhb/X3GK7dftToaOl5wYm8XarAAHA91g
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09@BANPMAILBOX01.citrite.net>
References: <BD9F087D95FBF64289E2C393ABD448FAF932352D19@BANPMAILBOX01.citrite.net>
In-Reply-To: <BD9F087D95FBF64289E2C393ABD448FAF932352D19@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] XCP 1.5 beta
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3156185736951376186=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3156185736951376186==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


   In XCP 1.5 beta (version 1.4.9) there is a method get_mtime missing in /=
opt/xensource/sm/util.py.  It should be there in older versions of XCP.
We are having problems adding XCP 1.4.9 hosts to our cloud.  How can I go a=
bout helping in getting this rectified ?

-Abhi

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-IN link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c=
olor:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal>&nbsp;&nbsp;=
 In XCP 1.5 beta (version 1.4.9) there is a method get_mtime missing in /op=
t/xensource/sm/util.py. &nbsp;It should be there in older versions of XCP.<=
o:p></o:p></p><p class=3DMsoNormal>We are having problems adding XCP 1.4.9 =
hosts to our cloud.&nbsp; How can I go about helping in getting this rectif=
ied ?<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
oNormal>-Abhi<o:p></o:p></p></div></body></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9155BCB09BANPMAILBOX01_--


--===============3156185736951376186==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3156185736951376186==--


From xen-devel-bounces@lists.xen.org Tue Apr 17 09:41:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4uk-0007fE-UB; Tue, 17 Apr 2012 09:41:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4uj-0007er-KW
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:41:33 +0000
Received: from [85.158.143.99:31461] by server-2.bemta-4.messagelabs.com id
	F8/50-17550-CCA3D8F4; Tue, 17 Apr 2012 09:41:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334655691!17605745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15218 invoked from network); 17 Apr 2012 09:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11972114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:41:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:41:18 +0100
Message-ID: <1334655677.14560.273.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:41:17 +0100
In-Reply-To: <1334596686-8479-17-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-17-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/24] libxl: change some structures to unit
 arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> In the next patch these variables will turn into actual pointers.
> 
> To clarify that patch, prepare the ground by changing these variables
> from "struct foo var" to "struct foo var[1]".  This enables accesses
> to them and their members to be made as if they were pointers.
> 
> No functional change.

Therefore only quickly skimmed and:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_create.c |   18 +++++-----
>  tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
>  2 files changed, 51 insertions(+), 51 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index dbc3cf0..8408c26 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -543,7 +543,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      libxl__spawner_starting *dm_starting = 0;
> -    libxl__domain_build_state state;
> +    libxl__domain_build_state state[1];
>      uint32_t domid;
>      int i, ret;
> 
> @@ -585,12 +585,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          }
>      }
> 
> -    memset(&state, 0, sizeof(state));
> +    memset(state, 0, sizeof(*state));
> 
>      if ( restore_fd >= 0 ) {
> -        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
> +        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
>      } else {
> -        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
> +        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
>      }
> 
>      if (ret) {
> @@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          ret = init_console_info(&console, 0);
>          if ( ret )
>              goto error_out;
> -        libxl__device_console_add(gc, domid, &console, &state);
> +        libxl__device_console_add(gc, domid, &console, state);
>          libxl__device_console_dispose(&console);
> 
>          libxl_device_vkb_init(&vkb);
> @@ -636,7 +636,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          libxl_device_vkb_dispose(&vkb);
> 
>          ret = libxl__create_device_model(gc, domid, d_config,
> -                                         &state, &dm_starting);
> +                                         state, &dm_starting);
>          if (ret < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                         "failed to create device model: %d", ret);
> @@ -665,11 +665,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          if (need_qemu)
>               console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> 
> -        libxl__device_console_add(gc, domid, &console, &state);
> +        libxl__device_console_add(gc, domid, &console, state);
>          libxl__device_console_dispose(&console);
> 
>          if (need_qemu) {
> -            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
> +            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
>          }
>          break;
>      }
> @@ -683,7 +683,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
>              libxl__qmp_initializations(gc, domid, d_config);
>          }
> -        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
> +        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
>          if (ret < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                         "device model did not start: %d", ret);
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 7bf653a..3921e2a 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
>      libxl__device_console *console;
> -    libxl_domain_config dm_config;
> +    libxl_domain_config dm_config[1];
>      libxl_device_vfb vfb;
>      libxl_device_vkb vkb;
> -    libxl__domain_build_state stubdom_state;
> +    libxl__domain_build_state stubdom_state[1];
>      uint32_t dm_domid;
>      char **args;
>      struct xs_permissions perm[2];
> @@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
>          goto out;
>      }
> 
> -    libxl_domain_create_info_init(&dm_config.c_info);
> -    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
> -    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
> +    libxl_domain_create_info_init(&dm_config->c_info);
> +    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
> +    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
>                                      libxl__domid_to_name(gc, guest_domid));
> -    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
> +    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
> 
> -    libxl_uuid_generate(&dm_config.c_info.uuid);
> +    libxl_uuid_generate(&dm_config->c_info.uuid);
> 
> -    libxl_domain_build_info_init(&dm_config.b_info);
> -    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
> +    libxl_domain_build_info_init(&dm_config->b_info);
> +    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
> 
> -    dm_config.b_info.max_vcpus = 1;
> -    dm_config.b_info.max_memkb = 32 * 1024;
> -    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
> +    dm_config->b_info.max_vcpus = 1;
> +    dm_config->b_info.max_memkb = 32 * 1024;
> +    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
> 
> -    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
> +    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
>                                                libxl_xenfirmwaredir_path());
> -    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> -    dm_config.b_info.u.pv.ramdisk.path = "";
> -    dm_config.b_info.u.pv.features = "";
> +    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> +    dm_config->b_info.u.pv.ramdisk.path = "";
> +    dm_config->b_info.u.pv.features = "";
> 
> -    dm_config.b_info.device_model_version =
> +    dm_config->b_info.device_model_version =
>          guest_config->b_info.device_model_version;
> -    dm_config.b_info.device_model =
> +    dm_config->b_info.device_model =
>          guest_config->b_info.device_model;
> -    dm_config.b_info.extra = guest_config->b_info.extra;
> -    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
> -    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
> +    dm_config->b_info.extra = guest_config->b_info.extra;
> +    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
> +    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
> 
> -    dm_config.disks = guest_config->disks;
> -    dm_config.num_disks = guest_config->num_disks;
> +    dm_config->disks = guest_config->disks;
> +    dm_config->num_disks = guest_config->num_disks;
> 
> -    dm_config.vifs = guest_config->vifs;
> -    dm_config.num_vifs = guest_config->num_vifs;
> +    dm_config->vifs = guest_config->vifs;
> +    dm_config->num_vifs = guest_config->num_vifs;
> 
> -    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
> +    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
>      if (ret) goto out;
> -    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
> +    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
>      if (ret) goto out;
> 
>      libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
> -    dm_config.vfbs = &vfb;
> -    dm_config.num_vfbs = 1;
> -    dm_config.vkbs = &vkb;
> -    dm_config.num_vkbs = 1;
> +    dm_config->vfbs = &vfb;
> +    dm_config->num_vfbs = 1;
> +    dm_config->vkbs = &vkb;
> +    dm_config->num_vkbs = 1;
> 
>      /* fixme: this function can leak the stubdom if it fails */
>      dm_domid = 0;
> -    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
> +    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
>      if (ret)
>          goto out;
> -    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
> +    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
>      if (ret)
>          goto out;
> 
> @@ -788,20 +788,20 @@ retry_transaction:
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> -    for (i = 0; i < dm_config.num_disks; i++) {
> -        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
> +    for (i = 0; i < dm_config->num_disks; i++) {
> +        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
>          if (ret)
>              goto out_free;
>      }
> -    for (i = 0; i < dm_config.num_vifs; i++) {
> -        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
> +    for (i = 0; i < dm_config->num_vifs; i++) {
> +        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
>          if (ret)
>              goto out_free;
>      }
> -    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
> +    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
>      if (ret)
>          goto out_free;
> -    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
> +    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
>      if (ret)
>          goto out_free;
> 
> @@ -845,14 +845,14 @@ retry_transaction:
>                  break;
>          }
>          ret = libxl__device_console_add(gc, dm_domid, &console[i],
> -                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
> +                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
>          if (ret)
>              goto out_free;
>      }
> 
>      if (libxl__create_xenpv_qemu(gc, dm_domid,
> -                                 &dm_config,
> -                                 &stubdom_state,
> +                                 dm_config,
> +                                 stubdom_state,
>                                   &dm_starting) < 0) {
>          ret = ERROR_FAIL;
>          goto out_free;
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 09:41:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 09:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK4uk-0007fE-UB; Tue, 17 Apr 2012 09:41:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK4uj-0007er-KW
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 09:41:33 +0000
Received: from [85.158.143.99:31461] by server-2.bemta-4.messagelabs.com id
	F8/50-17550-CCA3D8F4; Tue, 17 Apr 2012 09:41:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334655691!17605745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15218 invoked from network); 17 Apr 2012 09:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 09:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11972114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:41:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:41:18 +0100
Message-ID: <1334655677.14560.273.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 10:41:17 +0100
In-Reply-To: <1334596686-8479-17-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-17-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/24] libxl: change some structures to unit
 arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> In the next patch these variables will turn into actual pointers.
> 
> To clarify that patch, prepare the ground by changing these variables
> from "struct foo var" to "struct foo var[1]".  This enables accesses
> to them and their members to be made as if they were pointers.
> 
> No functional change.

Therefore only quickly skimmed and:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_create.c |   18 +++++-----
>  tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
>  2 files changed, 51 insertions(+), 51 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index dbc3cf0..8408c26 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -543,7 +543,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      libxl__spawner_starting *dm_starting = 0;
> -    libxl__domain_build_state state;
> +    libxl__domain_build_state state[1];
>      uint32_t domid;
>      int i, ret;
> 
> @@ -585,12 +585,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          }
>      }
> 
> -    memset(&state, 0, sizeof(state));
> +    memset(state, 0, sizeof(*state));
> 
>      if ( restore_fd >= 0 ) {
> -        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
> +        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
>      } else {
> -        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
> +        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
>      }
> 
>      if (ret) {
> @@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          ret = init_console_info(&console, 0);
>          if ( ret )
>              goto error_out;
> -        libxl__device_console_add(gc, domid, &console, &state);
> +        libxl__device_console_add(gc, domid, &console, state);
>          libxl__device_console_dispose(&console);
> 
>          libxl_device_vkb_init(&vkb);
> @@ -636,7 +636,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          libxl_device_vkb_dispose(&vkb);
> 
>          ret = libxl__create_device_model(gc, domid, d_config,
> -                                         &state, &dm_starting);
> +                                         state, &dm_starting);
>          if (ret < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                         "failed to create device model: %d", ret);
> @@ -665,11 +665,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          if (need_qemu)
>               console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> 
> -        libxl__device_console_add(gc, domid, &console, &state);
> +        libxl__device_console_add(gc, domid, &console, state);
>          libxl__device_console_dispose(&console);
> 
>          if (need_qemu) {
> -            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
> +            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
>          }
>          break;
>      }
> @@ -683,7 +683,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
>              libxl__qmp_initializations(gc, domid, d_config);
>          }
> -        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
> +        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
>          if (ret < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                         "device model did not start: %d", ret);
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 7bf653a..3921e2a 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
>      libxl__device_console *console;
> -    libxl_domain_config dm_config;
> +    libxl_domain_config dm_config[1];
>      libxl_device_vfb vfb;
>      libxl_device_vkb vkb;
> -    libxl__domain_build_state stubdom_state;
> +    libxl__domain_build_state stubdom_state[1];
>      uint32_t dm_domid;
>      char **args;
>      struct xs_permissions perm[2];
> @@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
>          goto out;
>      }
> 
> -    libxl_domain_create_info_init(&dm_config.c_info);
> -    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
> -    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
> +    libxl_domain_create_info_init(&dm_config->c_info);
> +    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
> +    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
>                                      libxl__domid_to_name(gc, guest_domid));
> -    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
> +    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
> 
> -    libxl_uuid_generate(&dm_config.c_info.uuid);
> +    libxl_uuid_generate(&dm_config->c_info.uuid);
> 
> -    libxl_domain_build_info_init(&dm_config.b_info);
> -    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
> +    libxl_domain_build_info_init(&dm_config->b_info);
> +    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
> 
> -    dm_config.b_info.max_vcpus = 1;
> -    dm_config.b_info.max_memkb = 32 * 1024;
> -    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
> +    dm_config->b_info.max_vcpus = 1;
> +    dm_config->b_info.max_memkb = 32 * 1024;
> +    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
> 
> -    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
> +    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
>                                                libxl_xenfirmwaredir_path());
> -    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> -    dm_config.b_info.u.pv.ramdisk.path = "";
> -    dm_config.b_info.u.pv.features = "";
> +    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> +    dm_config->b_info.u.pv.ramdisk.path = "";
> +    dm_config->b_info.u.pv.features = "";
> 
> -    dm_config.b_info.device_model_version =
> +    dm_config->b_info.device_model_version =
>          guest_config->b_info.device_model_version;
> -    dm_config.b_info.device_model =
> +    dm_config->b_info.device_model =
>          guest_config->b_info.device_model;
> -    dm_config.b_info.extra = guest_config->b_info.extra;
> -    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
> -    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
> +    dm_config->b_info.extra = guest_config->b_info.extra;
> +    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
> +    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
> 
> -    dm_config.disks = guest_config->disks;
> -    dm_config.num_disks = guest_config->num_disks;
> +    dm_config->disks = guest_config->disks;
> +    dm_config->num_disks = guest_config->num_disks;
> 
> -    dm_config.vifs = guest_config->vifs;
> -    dm_config.num_vifs = guest_config->num_vifs;
> +    dm_config->vifs = guest_config->vifs;
> +    dm_config->num_vifs = guest_config->num_vifs;
> 
> -    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
> +    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
>      if (ret) goto out;
> -    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
> +    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
>      if (ret) goto out;
> 
>      libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
> -    dm_config.vfbs = &vfb;
> -    dm_config.num_vfbs = 1;
> -    dm_config.vkbs = &vkb;
> -    dm_config.num_vkbs = 1;
> +    dm_config->vfbs = &vfb;
> +    dm_config->num_vfbs = 1;
> +    dm_config->vkbs = &vkb;
> +    dm_config->num_vkbs = 1;
> 
>      /* fixme: this function can leak the stubdom if it fails */
>      dm_domid = 0;
> -    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
> +    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
>      if (ret)
>          goto out;
> -    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
> +    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
>      if (ret)
>          goto out;
> 
> @@ -788,20 +788,20 @@ retry_transaction:
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> -    for (i = 0; i < dm_config.num_disks; i++) {
> -        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
> +    for (i = 0; i < dm_config->num_disks; i++) {
> +        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
>          if (ret)
>              goto out_free;
>      }
> -    for (i = 0; i < dm_config.num_vifs; i++) {
> -        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
> +    for (i = 0; i < dm_config->num_vifs; i++) {
> +        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
>          if (ret)
>              goto out_free;
>      }
> -    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
> +    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
>      if (ret)
>          goto out_free;
> -    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
> +    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
>      if (ret)
>          goto out_free;
> 
> @@ -845,14 +845,14 @@ retry_transaction:
>                  break;
>          }
>          ret = libxl__device_console_add(gc, dm_domid, &console[i],
> -                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
> +                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
>          if (ret)
>              goto out_free;
>      }
> 
>      if (libxl__create_xenpv_qemu(gc, dm_domid,
> -                                 &dm_config,
> -                                 &stubdom_state,
> +                                 dm_config,
> +                                 stubdom_state,
>                                   &dm_starting) < 0) {
>          ret = ERROR_FAIL;
>          goto out_free;
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:27:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK5cY-0000yl-JH; Tue, 17 Apr 2012 10:26:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK5cX-0000ye-Ag
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 10:26:49 +0000
Received: from [85.158.143.35:2695] by server-3.bemta-4.messagelabs.com id
	46/F3-05853-8654D8F4; Tue, 17 Apr 2012 10:26:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334658407!12763752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9382 invoked from network); 17 Apr 2012 10:26:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11973452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:26:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:26:37 +0100
Message-ID: <1334658395.23948.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Tue, 17 Apr 2012 11:26:35 +0100
In-Reply-To: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 20:03 +0100, M A Young wrote:
> There is a Fedora bug report 
> https://bugzilla.redhat.com/show_bug.cgi?id=812421 reporting that openvpn 
> is having problems because of the line
> SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
> in /etc/udev/rules.d/xen-backend.rules which is causing the xen script to 
> run when openvpn tries to use a tap device, causing it to fail. I have 
> used the attached patch to solve this problem, by matching the form of the 
> tap device that xen uses more exactly to avoid to openvpn case. A better 
> long-term solution (suggested in one of the comments in the bug) might be 
> to use a more specific name instead of "tap" so we have less chance of 
> interfering with another application.

This is a good start, I think we should do this for 4.2.

Changing the name might be pretty simple though e.g. the following.
Works for me with xl but I didn't try xend (seems "obviously correct"?)

I noticed that when vifname is set xend prepends "tap-" (presumably to
distinguish it from the vif device) whereas libxl does not, so I suspect
named vifs for HVM guests don't work so well, I fixed that while I was
there...

Also at least for the libxl case we will likely not be running these
hotplug scripts via udev any more in 4.2, however I don't think there is
any harm in making this change first (iff we decide it is suitable for
4.2).

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334658366 -3600
# Node ID de3e65d804cceab7291e2accc18d50ae8b816433
# Parent  8d92d1f34921c8675d85c74aa36e319c9451f68f
libxl/xend: name tap devices with a xentap prefix

This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)

Also add "xentap-" prefix to the tap device when an explicit name is given to
avoid a conflict with the vif device, which would otherwise have the same name.
Likewise correct the documentation for this option which suggested it applied
to HVM tap devices only.

Reported by Michael Young.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8d92d1f34921 -r de3e65d804cc docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Mon Apr 16 17:57:00 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Tue Apr 17 11:26:06 2012 +0100
@@ -93,11 +93,14 @@ are:
 
 ### vifname
 
-This keyword is valid for HVM guest devices with `type=ioemu` only.
+Specifies the backend device name for the virtual device.
 
-Specifies the backend device name for an emulated device. The default
-is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
-is the device number.
+If the domain is an HVM domain then the associated emulated (tap)
+device will have a "xentap-" prefix added.
+
+The default name for the virtual device is `vifDOMID.DEVID` where
+`DOMID` is the guest domain ID and `DEVID` is the device
+number. Likewise the default tap name is `xentapDOMID.DEVID`.
 
 ### script
 
diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/vif-common.sh
--- a/tools/hotplug/Linux/vif-common.sh	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/hotplug/Linux/vif-common.sh	Tue Apr 17 11:26:06 2012 +0100
@@ -85,8 +85,8 @@ elif [ "$type_if" = tap ]; then
     : ${INTERFACE:?}
 
     # Get xenbus_path from device name.
-    # The name is built like that: "tap${domid}.${devid}".
-    dev_=${dev#tap}
+    # The name is built like that: "xentap${domid}.${devid}".
+    dev_=${dev#xentap}
     domid=${dev_%.*}
     devid=${dev_#*.}
 
diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Tue Apr 17 11:26:06 2012 +0100
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blkt
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff -r 8d92d1f34921 -r de3e65d804cc tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Tue Apr 17 11:26:06 2012 +0100
@@ -212,9 +212,9 @@ static char ** libxl__build_device_model
                 char *ifname;
                 if (!vifs[i].ifname)
                     ifname = libxl__sprintf(gc,
-                                            "tap%d.%d", domid, vifs[i].devid);
+                                            "xentap%d.%d", domid, vifs[i].devid);
                 else
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
@@ -451,10 +451,10 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                    ifname = libxl__sprintf(gc, "xentap%d.%d",
                                             guest_domid, vifs[i].devid);
                 } else {
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 }
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/python/xen/xend/image.py	Tue Apr 17 11:26:06 2012 +0100
@@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
             if vifname:
                 vifname = "tap-" + vifname
             else:
-                vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1)
+                vifname = "xentap%d.%d" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
             ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
                        (nics, vifname, bridge))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:27:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK5cY-0000yl-JH; Tue, 17 Apr 2012 10:26:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK5cX-0000ye-Ag
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 10:26:49 +0000
Received: from [85.158.143.35:2695] by server-3.bemta-4.messagelabs.com id
	46/F3-05853-8654D8F4; Tue, 17 Apr 2012 10:26:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334658407!12763752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9382 invoked from network); 17 Apr 2012 10:26:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11973452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:26:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:26:37 +0100
Message-ID: <1334658395.23948.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Tue, 17 Apr 2012 11:26:35 +0100
In-Reply-To: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 20:03 +0100, M A Young wrote:
> There is a Fedora bug report 
> https://bugzilla.redhat.com/show_bug.cgi?id=812421 reporting that openvpn 
> is having problems because of the line
> SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
> in /etc/udev/rules.d/xen-backend.rules which is causing the xen script to 
> run when openvpn tries to use a tap device, causing it to fail. I have 
> used the attached patch to solve this problem, by matching the form of the 
> tap device that xen uses more exactly to avoid to openvpn case. A better 
> long-term solution (suggested in one of the comments in the bug) might be 
> to use a more specific name instead of "tap" so we have less chance of 
> interfering with another application.

This is a good start, I think we should do this for 4.2.

Changing the name might be pretty simple though e.g. the following.
Works for me with xl but I didn't try xend (seems "obviously correct"?)

I noticed that when vifname is set xend prepends "tap-" (presumably to
distinguish it from the vif device) whereas libxl does not, so I suspect
named vifs for HVM guests don't work so well, I fixed that while I was
there...

Also at least for the libxl case we will likely not be running these
hotplug scripts via udev any more in 4.2, however I don't think there is
any harm in making this change first (iff we decide it is suitable for
4.2).

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334658366 -3600
# Node ID de3e65d804cceab7291e2accc18d50ae8b816433
# Parent  8d92d1f34921c8675d85c74aa36e319c9451f68f
libxl/xend: name tap devices with a xentap prefix

This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)

Also add "xentap-" prefix to the tap device when an explicit name is given to
avoid a conflict with the vif device, which would otherwise have the same name.
Likewise correct the documentation for this option which suggested it applied
to HVM tap devices only.

Reported by Michael Young.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8d92d1f34921 -r de3e65d804cc docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Mon Apr 16 17:57:00 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Tue Apr 17 11:26:06 2012 +0100
@@ -93,11 +93,14 @@ are:
 
 ### vifname
 
-This keyword is valid for HVM guest devices with `type=ioemu` only.
+Specifies the backend device name for the virtual device.
 
-Specifies the backend device name for an emulated device. The default
-is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
-is the device number.
+If the domain is an HVM domain then the associated emulated (tap)
+device will have a "xentap-" prefix added.
+
+The default name for the virtual device is `vifDOMID.DEVID` where
+`DOMID` is the guest domain ID and `DEVID` is the device
+number. Likewise the default tap name is `xentapDOMID.DEVID`.
 
 ### script
 
diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/vif-common.sh
--- a/tools/hotplug/Linux/vif-common.sh	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/hotplug/Linux/vif-common.sh	Tue Apr 17 11:26:06 2012 +0100
@@ -85,8 +85,8 @@ elif [ "$type_if" = tap ]; then
     : ${INTERFACE:?}
 
     # Get xenbus_path from device name.
-    # The name is built like that: "tap${domid}.${devid}".
-    dev_=${dev#tap}
+    # The name is built like that: "xentap${domid}.${devid}".
+    dev_=${dev#xentap}
     domid=${dev_%.*}
     devid=${dev_#*.}
 
diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Tue Apr 17 11:26:06 2012 +0100
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blkt
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff -r 8d92d1f34921 -r de3e65d804cc tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Tue Apr 17 11:26:06 2012 +0100
@@ -212,9 +212,9 @@ static char ** libxl__build_device_model
                 char *ifname;
                 if (!vifs[i].ifname)
                     ifname = libxl__sprintf(gc,
-                                            "tap%d.%d", domid, vifs[i].devid);
+                                            "xentap%d.%d", domid, vifs[i].devid);
                 else
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
@@ -451,10 +451,10 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                    ifname = libxl__sprintf(gc, "xentap%d.%d",
                                             guest_domid, vifs[i].devid);
                 } else {
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 }
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Mon Apr 16 17:57:00 2012 +0100
+++ b/tools/python/xen/xend/image.py	Tue Apr 17 11:26:06 2012 +0100
@@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
             if vifname:
                 vifname = "tap-" + vifname
             else:
-                vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1)
+                vifname = "xentap%d.%d" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
             ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
                        (nics, vifname, bridge))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:49:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:49:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK5y2-0001Eo-IX; Tue, 17 Apr 2012 10:49:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK5y1-0001Ej-0g
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 10:49:01 +0000
Received: from [85.158.143.99:64096] by server-1.bemta-4.messagelabs.com id
	CB/F9-20925-C9A4D8F4; Tue, 17 Apr 2012 10:49:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334659739!23422964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7839 invoked from network); 17 Apr 2012 10:48:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:48:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11974052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:48:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:48:59 +0100
Message-ID: <1334659737.23948.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 17 Apr 2012 11:48:57 +0100
In-Reply-To: <a523c29eb8751c50de09.1334627905@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
	<a523c29eb8751c50de09.1334627905@mgagne.users.dev.iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] xl: add support for vif rate
 limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDAyOjU4ICswMTAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBUaGUgYHJhdGVgIGtleXdvcmQgc3BlY2lmaWVzIHRoZSByYXRlIGF0IHdoaWNoIHRoZSBvdXRn
b2luZyB0cmFmZmljIHdpbGwgYmUgbGltaXRlZCB0by4KPiBUaGUgZGVmYXVsdCBpZiB0aGlzIGtl
eXdvcmQgaXMgbm90IHNwZWNpZmllZCBpcyB1bmxpbWl0ZWQuCj4gCj4gVGhlIGByYXRlYCBrZXl3
b3JkIHN1cHBvcnRzIGFuIG9wdGlvbmFsIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwgcGFyYW1ldGVy
IGZvciBzcGVjaWZ5aW5nCj4gdGhlIGdyYW51bGFyaXR5IG9mIGNyZWRpdCByZXBsZW5pc2htZW50
LiBJdCBkZXRlcm1pbmVzIHRoZSBmcmVxdWVuY3kgYXQgd2hpY2gKPiB0aGUgdmlmIHRyYW5zbWlz
c2lvbiBjcmVkaXQgaXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMu
Cj4gCj4gRm9yIGV4YW1wbGU6Cj4gCj4gICAgICAgICAncmF0ZT0xME1iL3MnCj4gICAgICAgICAn
cmF0ZT0yNTBLQi9zJwo+ICAgICAgICAgJ3JhdGU9MU1CL3NAMjBtcycKPiAKPiBTaWduZWQtb2Zm
LWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIuY29tPgo+IAo+IGRkaWZmIC0tZ2l0IGEv
dG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKPiAtLS0gYS90b29scy9s
aWJ4bC9saWJ4bC5jCj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwo+IEBAIC0xODU0LDYgKzE4
NTQsMTMgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRkKGxpYnhsX2N0eCAqY3R4LAo+ICAgICAg
ICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5pcCkpOwo+
ICAgICAgfQo+IAo+ICsgICAgaWYgKG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcyA+IDApIHsKPiAr
ICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJyYXRlIik7Cj4gKyAgICAgICAgZmxleGFy
cmF5X2FwcGVuZChiYWNrLCBsaWJ4bF9fc3ByaW50ZihnYywgIiVsbHUsJWx1IiwKCkkgdGhpbmsg
eW91IHdhbnQgdG8gdXNlIFBSSXU2NCBhbmQgUFJJdTMyIGhlcmUuIAoJIiUiUFJJdTY0IiwlIlBS
SXUzMiIKCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAodW5zaWduZWQgbG9uZyBsb25n
KSBuaWMtPnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsLAo+ICsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgKHVuc2lnbmVkIGxvbmcpIG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcykpOwo+ICsgICAg
fQo+ICsKPiAgICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgImJyaWRnZSIpOwo+ICAgICAgZmxl
eGFycmF5X2FwcGVuZChiYWNrLCBsaWJ4bF9fc3RyZHVwKGdjLCBuaWMtPmJyaWRnZSkpOwo+ICAg
ICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCAiaGFuZGxlIik7Cgo+IEBAIC00ODU1LDYgKzQ4NzMs
NyBAQCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCj4gIHsKPiAgICAg
IGludCBvcHQ7Cj4gICAgICBsaWJ4bF9kZXZpY2VfbmljIG5pYzsKPiArICAgIFhMVV9Db25maWcg
KmNvbmZpZyA9IDA7Cj4gICAgICBjaGFyICplbmRwdHIsICpvcGFyZzsKPiAgICAgIGNvbnN0IGNo
YXIgKnRvazsKPiAgICAgIGludCBpOwo+IEBAIC00OTEwLDYgKzQ5MjksNyBAQCBpbnQgbWFpbl9u
ZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRD
SF9PUFRJT04oIm1vZGVsIiwgKmFyZ3YsIG9wYXJnKSkgewo+ICAgICAgICAgICAgICByZXBsYWNl
X3N0cmluZygmbmljLm1vZGVsLCBvcGFyZyk7Cj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9P
UFRJT04oInJhdGUiLCAqYXJndiwgb3BhcmcpKSB7Cj4gKyAgICAgICAgICAgIHBhcnNlX3ZpZl9y
YXRlKCZjb25maWcsIG9wYXJnLCAmbmljKTsKPiAgICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09Q
VElPTigiYWNjZWwiLCAqYXJndiwgb3BhcmcpKSB7Cj4gICAgICAgICAgfSBlbHNlIHsKPiAgICAg
ICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ1bnJlY29nbml6ZWQgYXJndW1lbnQgYCVzJ1xuIiwg
KmFyZ3YpOwoKQm90aCB0aGlzIGFuZCB0aGUgZXhpc3RpbmcgbWFpbl9ibG9ja2F0dGFjaCBhbmQg
cGNpe2F0dGFjaCxkZXN0YWNofQphcHBlYXIgdG8gZmFpbCB0byBjYWxsIHhsdV9jZmdfZGVzdHJv
eSBhbmQgc28gYXJlIGEgYml0IGxlYWt5LiBJIGRvbid0CnRoaW5rIHRoaXMgaXMgY3JpdGljYWwg
cmlnaHQgbm93ICh0aGUgcHJvY2VzcyBleGl0cyByaWdodCBhd2F5KSAtLSBidXQKaWYgeW91IGZh
bmNpZWQgZml4aW5nIHRoZXNlIHVwIGluIGEgZnV0dXJlIHBhdGNoIGl0J2QgYmUgbXVjaAphcHBy
ZWNpYXRlZC4KCkdpdmVuIHRoZSB1c2Ugb2YgUFJJdVhYIGFzIGFib3ZlOgoKQWNrZWQtYnk6IElh
biBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CgpJYW4uCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:49:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:49:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK5y2-0001Eo-IX; Tue, 17 Apr 2012 10:49:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK5y1-0001Ej-0g
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 10:49:01 +0000
Received: from [85.158.143.99:64096] by server-1.bemta-4.messagelabs.com id
	CB/F9-20925-C9A4D8F4; Tue, 17 Apr 2012 10:49:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334659739!23422964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7839 invoked from network); 17 Apr 2012 10:48:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:48:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11974052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:48:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:48:59 +0100
Message-ID: <1334659737.23948.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 17 Apr 2012 11:48:57 +0100
In-Reply-To: <a523c29eb8751c50de09.1334627905@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
	<a523c29eb8751c50de09.1334627905@mgagne.users.dev.iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] xl: add support for vif rate
 limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDAyOjU4ICswMTAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBUaGUgYHJhdGVgIGtleXdvcmQgc3BlY2lmaWVzIHRoZSByYXRlIGF0IHdoaWNoIHRoZSBvdXRn
b2luZyB0cmFmZmljIHdpbGwgYmUgbGltaXRlZCB0by4KPiBUaGUgZGVmYXVsdCBpZiB0aGlzIGtl
eXdvcmQgaXMgbm90IHNwZWNpZmllZCBpcyB1bmxpbWl0ZWQuCj4gCj4gVGhlIGByYXRlYCBrZXl3
b3JkIHN1cHBvcnRzIGFuIG9wdGlvbmFsIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwgcGFyYW1ldGVy
IGZvciBzcGVjaWZ5aW5nCj4gdGhlIGdyYW51bGFyaXR5IG9mIGNyZWRpdCByZXBsZW5pc2htZW50
LiBJdCBkZXRlcm1pbmVzIHRoZSBmcmVxdWVuY3kgYXQgd2hpY2gKPiB0aGUgdmlmIHRyYW5zbWlz
c2lvbiBjcmVkaXQgaXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMu
Cj4gCj4gRm9yIGV4YW1wbGU6Cj4gCj4gICAgICAgICAncmF0ZT0xME1iL3MnCj4gICAgICAgICAn
cmF0ZT0yNTBLQi9zJwo+ICAgICAgICAgJ3JhdGU9MU1CL3NAMjBtcycKPiAKPiBTaWduZWQtb2Zm
LWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIuY29tPgo+IAo+IGRkaWZmIC0tZ2l0IGEv
dG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKPiAtLS0gYS90b29scy9s
aWJ4bC9saWJ4bC5jCj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwo+IEBAIC0xODU0LDYgKzE4
NTQsMTMgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRkKGxpYnhsX2N0eCAqY3R4LAo+ICAgICAg
ICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5pcCkpOwo+
ICAgICAgfQo+IAo+ICsgICAgaWYgKG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcyA+IDApIHsKPiAr
ICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJyYXRlIik7Cj4gKyAgICAgICAgZmxleGFy
cmF5X2FwcGVuZChiYWNrLCBsaWJ4bF9fc3ByaW50ZihnYywgIiVsbHUsJWx1IiwKCkkgdGhpbmsg
eW91IHdhbnQgdG8gdXNlIFBSSXU2NCBhbmQgUFJJdTMyIGhlcmUuIAoJIiUiUFJJdTY0IiwlIlBS
SXUzMiIKCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAodW5zaWduZWQgbG9uZyBsb25n
KSBuaWMtPnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsLAo+ICsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgKHVuc2lnbmVkIGxvbmcpIG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcykpOwo+ICsgICAg
fQo+ICsKPiAgICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgImJyaWRnZSIpOwo+ICAgICAgZmxl
eGFycmF5X2FwcGVuZChiYWNrLCBsaWJ4bF9fc3RyZHVwKGdjLCBuaWMtPmJyaWRnZSkpOwo+ICAg
ICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCAiaGFuZGxlIik7Cgo+IEBAIC00ODU1LDYgKzQ4NzMs
NyBAQCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCj4gIHsKPiAgICAg
IGludCBvcHQ7Cj4gICAgICBsaWJ4bF9kZXZpY2VfbmljIG5pYzsKPiArICAgIFhMVV9Db25maWcg
KmNvbmZpZyA9IDA7Cj4gICAgICBjaGFyICplbmRwdHIsICpvcGFyZzsKPiAgICAgIGNvbnN0IGNo
YXIgKnRvazsKPiAgICAgIGludCBpOwo+IEBAIC00OTEwLDYgKzQ5MjksNyBAQCBpbnQgbWFpbl9u
ZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRD
SF9PUFRJT04oIm1vZGVsIiwgKmFyZ3YsIG9wYXJnKSkgewo+ICAgICAgICAgICAgICByZXBsYWNl
X3N0cmluZygmbmljLm1vZGVsLCBvcGFyZyk7Cj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9P
UFRJT04oInJhdGUiLCAqYXJndiwgb3BhcmcpKSB7Cj4gKyAgICAgICAgICAgIHBhcnNlX3ZpZl9y
YXRlKCZjb25maWcsIG9wYXJnLCAmbmljKTsKPiAgICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09Q
VElPTigiYWNjZWwiLCAqYXJndiwgb3BhcmcpKSB7Cj4gICAgICAgICAgfSBlbHNlIHsKPiAgICAg
ICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ1bnJlY29nbml6ZWQgYXJndW1lbnQgYCVzJ1xuIiwg
KmFyZ3YpOwoKQm90aCB0aGlzIGFuZCB0aGUgZXhpc3RpbmcgbWFpbl9ibG9ja2F0dGFjaCBhbmQg
cGNpe2F0dGFjaCxkZXN0YWNofQphcHBlYXIgdG8gZmFpbCB0byBjYWxsIHhsdV9jZmdfZGVzdHJv
eSBhbmQgc28gYXJlIGEgYml0IGxlYWt5LiBJIGRvbid0CnRoaW5rIHRoaXMgaXMgY3JpdGljYWwg
cmlnaHQgbm93ICh0aGUgcHJvY2VzcyBleGl0cyByaWdodCBhd2F5KSAtLSBidXQKaWYgeW91IGZh
bmNpZWQgZml4aW5nIHRoZXNlIHVwIGluIGEgZnV0dXJlIHBhdGNoIGl0J2QgYmUgbXVjaAphcHBy
ZWNpYXRlZC4KCkdpdmVuIHRoZSB1c2Ugb2YgUFJJdVhYIGFzIGFib3ZlOgoKQWNrZWQtYnk6IElh
biBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CgpJYW4uCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK5zF-0001HM-18; Tue, 17 Apr 2012 10:50:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK5zD-0001HE-FM
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 10:50:15 +0000
Received: from [85.158.143.99:20703] by server-2.bemta-4.messagelabs.com id
	2C/B1-17550-6EA4D8F4; Tue, 17 Apr 2012 10:50:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334659813!18741805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8534 invoked from network); 17 Apr 2012 10:50:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:50:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11974092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:50:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:50:14 +0100
Message-ID: <1334659812.23948.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 17 Apr 2012 11:50:12 +0100
In-Reply-To: <26d95b70f172c7405201.1334627906@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
	<26d95b70f172c7405201.1334627906@mgagne.users.dev.iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] xl: add "check-xl-vif-parse" test
 script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDAyOjU4ICswMTAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBUaGlzIHRlc3Qgc2NyaXB0IHJ1bnMgInhsIC1OIG5ldHdvcmstYXR0YWNoIDAgPGZvb2Jhcj4i
IGFnYWluc3QgdmFyaW91cwo+IHJhdGUgc3ludGF4IGFuZCBjaGVja3MgdGhhdCB0aGUgb3V0cHV0
IGlzIGFzIGV4cGVjdGVkLgo+IAo+IFNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2Fn
bmVAaXdlYi5jb20+CgpBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4
LmNvbT4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK5zF-0001HM-18; Tue, 17 Apr 2012 10:50:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK5zD-0001HE-FM
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 10:50:15 +0000
Received: from [85.158.143.99:20703] by server-2.bemta-4.messagelabs.com id
	2C/B1-17550-6EA4D8F4; Tue, 17 Apr 2012 10:50:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334659813!18741805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8534 invoked from network); 17 Apr 2012 10:50:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:50:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11974092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:50:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:50:14 +0100
Message-ID: <1334659812.23948.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 17 Apr 2012 11:50:12 +0100
In-Reply-To: <26d95b70f172c7405201.1334627906@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
	<26d95b70f172c7405201.1334627906@mgagne.users.dev.iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] xl: add "check-xl-vif-parse" test
 script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDAyOjU4ICswMTAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBUaGlzIHRlc3Qgc2NyaXB0IHJ1bnMgInhsIC1OIG5ldHdvcmstYXR0YWNoIDAgPGZvb2Jhcj4i
IGFnYWluc3QgdmFyaW91cwo+IHJhdGUgc3ludGF4IGFuZCBjaGVja3MgdGhhdCB0aGUgb3V0cHV0
IGlzIGFzIGV4cGVjdGVkLgo+IAo+IFNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2Fn
bmVAaXdlYi5jb20+CgpBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4
LmNvbT4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:54:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK63C-0001TS-MU; Tue, 17 Apr 2012 10:54:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SK63B-0001TM-B4
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 10:54:21 +0000
Received: from [85.158.138.51:21718] by server-5.bemta-3.messagelabs.com id
	38/78-17113-CDB4D8F4; Tue, 17 Apr 2012 10:54:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334660059!22349286!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29153 invoked from network); 17 Apr 2012 10:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11974194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:54:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 11:54:19 +0100
Date: Tue, 17 Apr 2012 11:58:58 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120416195258.GA14982@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204171138020.26786@kaball-desktop>
References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120416195258.GA14982@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are
 FOREIGN_FRAME when sharing them
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote:
> > Set pages as FOREIGN_FRAME whenever blkfront shares them with another
> > domain. Then when blkfront un-share them, also removes the
> > FOREIGN_FRAME_BIT from the p2m.
> > 
> > We do it so that when the source and the destination domain are the same
> > (blkfront connected to blkback in the same domain) we can more easily
> 
> Hm, however you mention qdisk which does not use blkback?

yes, sorry for the confusion, I meant "disk backend" rather than blkback


> > recognize which ones are the source pfns and which ones are the
> > destination pfns (both are going to be pointing to the same mfns).
> 
> OK, so what happens if we do not do this?

see below

> > Without this patch enstablishing a connection between blkfront and QEMU
> > qdisk in the same domain causes QEMU to hang and never return.
> 
> What is the reason behind it..?
> 
> Just to make sure I got it right:
> 
> The scenario is where a PV guest launches and inside it, it runs
> QEMU exporting its disk (xvda, or some sda if iSCSI or FCoE) to some
> other domain. In other words - a stubdomain, right? That would
> imply that we have xen-blkfront, xen-blkback [or not?], and QEMU
> using gntdev on the same page at some point.
> 
> So if we have a request from the other guest to read, it would be:
>  - QEMU allocates some pages.
>  - QEMU qdisk getting kicked.
>  - QEMU using gntdev to IOCTL_GNTDEV_MAP_GRANT_REF the appropiate
>    page
>  - gntdev ends up calling gnttab_map_refs. The gnttab_map_refs then
>    uses the m2p_add_override, which calls set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)).
>  - QEMU passes the mentioned page to the kernel using the libaio.
>  - libaio does its syscall to sys_aio? which then maps the 'struct page'
>    in the kernel space. The PFN has FOREIGN_FRAME set.
>  - kernel aio code passes the 'struct page' to xen-blkfront.
>  - xen-blkfront now (with your patch) makes sure to re-stamp FOREIGN_FRAME on the
>    PFN.
>    
>  - once xen-blkfront is done, it returns to libaio. libaio calls
>    QEMU and it calls gntdev to unmap. The grant dev does it, and calls
>    m2p_remove_override on the PFN [the one that had the FOREIGN_FRAME bit set].
>    
> Hm, I think I lost myself here.  Is the case here that QEMU does not
> do the IOCTL_GNTDEV_MAP_GRANT_REF so in reality the PFN that is provided
> to xen-blkfront does not have FOREIGN_FRAME stamped?

Nope, the scenario is local attach in dom0: we have a PV disk image in
qcow format and we need to create a corresponding xvda device in dom0 so
that we can use pygrub on it to extract kernel and initramfs.

To solve this problem we create a disk frontend/backend pair both in
dom0, using qdisk as backend.
In this scenario, the mfns shared by the frontend are going to back two
different sets of pfns: the original pfns allocated by the frontend and
the new ones allocated by gntdev for the backend.

Now the problem is that when Linux calls mfn_to_pfn, passing as argument
one of the mfn shared by the frontend, we want to get the pfn returned by
m2p_find_override_pfn (that is the pfn setup by gntdev) but actually we
get the original pfn allocated by the frontend because considering that
the frontend and the backend are in the same domain:

pfn = machine_to_phys_mapping[mfn];
mfn2 = get_phys_to_machine(pfn);

in this case mfn == mfn2.


One possible solution would be to always call m2p_find_override_pfn to
check out whether we have an entry for a given mfn.
However it is not very efficient or scalable.
The other option (that this patch is implementing) is to mark the pages
shared by the frontend as "foreign", so that mfn != mfn2 again.
It makes sense because from the frontend point of view they are donated
to the backend and while so they are not supposed to be used by the
frontend. In a way, they don't belong to the frontend anymore, at least
temporarily.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 10:54:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 10:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK63C-0001TS-MU; Tue, 17 Apr 2012 10:54:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SK63B-0001TM-B4
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 10:54:21 +0000
Received: from [85.158.138.51:21718] by server-5.bemta-3.messagelabs.com id
	38/78-17113-CDB4D8F4; Tue, 17 Apr 2012 10:54:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334660059!22349286!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29153 invoked from network); 17 Apr 2012 10:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 10:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,434,1330905600"; d="scan'208";a="11974194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:54:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 11:54:19 +0100
Date: Tue, 17 Apr 2012 11:58:58 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120416195258.GA14982@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204171138020.26786@kaball-desktop>
References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120416195258.GA14982@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are
 FOREIGN_FRAME when sharing them
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote:
> > Set pages as FOREIGN_FRAME whenever blkfront shares them with another
> > domain. Then when blkfront un-share them, also removes the
> > FOREIGN_FRAME_BIT from the p2m.
> > 
> > We do it so that when the source and the destination domain are the same
> > (blkfront connected to blkback in the same domain) we can more easily
> 
> Hm, however you mention qdisk which does not use blkback?

yes, sorry for the confusion, I meant "disk backend" rather than blkback


> > recognize which ones are the source pfns and which ones are the
> > destination pfns (both are going to be pointing to the same mfns).
> 
> OK, so what happens if we do not do this?

see below

> > Without this patch enstablishing a connection between blkfront and QEMU
> > qdisk in the same domain causes QEMU to hang and never return.
> 
> What is the reason behind it..?
> 
> Just to make sure I got it right:
> 
> The scenario is where a PV guest launches and inside it, it runs
> QEMU exporting its disk (xvda, or some sda if iSCSI or FCoE) to some
> other domain. In other words - a stubdomain, right? That would
> imply that we have xen-blkfront, xen-blkback [or not?], and QEMU
> using gntdev on the same page at some point.
> 
> So if we have a request from the other guest to read, it would be:
>  - QEMU allocates some pages.
>  - QEMU qdisk getting kicked.
>  - QEMU using gntdev to IOCTL_GNTDEV_MAP_GRANT_REF the appropiate
>    page
>  - gntdev ends up calling gnttab_map_refs. The gnttab_map_refs then
>    uses the m2p_add_override, which calls set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)).
>  - QEMU passes the mentioned page to the kernel using the libaio.
>  - libaio does its syscall to sys_aio? which then maps the 'struct page'
>    in the kernel space. The PFN has FOREIGN_FRAME set.
>  - kernel aio code passes the 'struct page' to xen-blkfront.
>  - xen-blkfront now (with your patch) makes sure to re-stamp FOREIGN_FRAME on the
>    PFN.
>    
>  - once xen-blkfront is done, it returns to libaio. libaio calls
>    QEMU and it calls gntdev to unmap. The grant dev does it, and calls
>    m2p_remove_override on the PFN [the one that had the FOREIGN_FRAME bit set].
>    
> Hm, I think I lost myself here.  Is the case here that QEMU does not
> do the IOCTL_GNTDEV_MAP_GRANT_REF so in reality the PFN that is provided
> to xen-blkfront does not have FOREIGN_FRAME stamped?

Nope, the scenario is local attach in dom0: we have a PV disk image in
qcow format and we need to create a corresponding xvda device in dom0 so
that we can use pygrub on it to extract kernel and initramfs.

To solve this problem we create a disk frontend/backend pair both in
dom0, using qdisk as backend.
In this scenario, the mfns shared by the frontend are going to back two
different sets of pfns: the original pfns allocated by the frontend and
the new ones allocated by gntdev for the backend.

Now the problem is that when Linux calls mfn_to_pfn, passing as argument
one of the mfn shared by the frontend, we want to get the pfn returned by
m2p_find_override_pfn (that is the pfn setup by gntdev) but actually we
get the original pfn allocated by the frontend because considering that
the frontend and the backend are in the same domain:

pfn = machine_to_phys_mapping[mfn];
mfn2 = get_phys_to_machine(pfn);

in this case mfn == mfn2.


One possible solution would be to always call m2p_find_override_pfn to
check out whether we have an entry for a given mfn.
However it is not very efficient or scalable.
The other option (that this patch is implementing) is to mark the pages
shared by the frontend as "foreign", so that mfn != mfn2 again.
It makes sense because from the frontend point of view they are donated
to the backend and while so they are not supposed to be used by the
frontend. In a way, they don't belong to the frontend anymore, at least
temporarily.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 12:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7cW-0002Eu-3a; Tue, 17 Apr 2012 12:34:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7cU-0002Ep-4Y
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:34:54 +0000
Received: from [85.158.139.83:22606] by server-7.bemta-5.messagelabs.com id
	9D/B4-16195-D636D8F4; Tue, 17 Apr 2012 12:34:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334666092!24183208!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29985 invoked from network); 17 Apr 2012 12:34:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:34:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:34:51 +0100
Message-Id: <4F8D7F87020000780007E776@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:34:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBE907177.0__="
Subject: [Xen-devel] [PATCH] gnttab: remove pointless NULL check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBE907177.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Domains in the domain hash (and hence locatable via the usual lookup
functions) can't have a NULL grant table pointer; no other function
performs such a check, so remove it from gnttab_prepare_for_transfer()
for consistency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1390,17 +1390,11 @@ static int=20
 gnttab_prepare_for_transfer(
     struct domain *rd, struct domain *ld, grant_ref_t ref)
 {
-    struct grant_table *rgt;
+    struct grant_table *rgt =3D rd->grant_table;
     grant_entry_header_t *sha;
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries =3D 0;
=20
-    if ( unlikely((rgt =3D rd->grant_table) =3D=3D NULL) )
-    {
-        gdprintk(XENLOG_INFO, "Dom %d has no grant table.\n", rd->domain_i=
d);
-        return 0;
-    }
-
     spin_lock(&rgt->lock);
=20
     if ( rgt->gt_version =3D=3D 0 )




--=__PartBE907177.0__=
Content-Type: text/plain; name="gnttab-pointless-check.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gnttab-pointless-check.patch"

gnttab: remove pointless NULL check=0A=0ADomains in the domain hash (and =
hence locatable via the usual lookup=0Afunctions) can't have a NULL grant =
table pointer; no other function=0Aperforms such a check, so remove it =
from gnttab_prepare_for_transfer()=0Afor consistency.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -1390,17 +1390,11 @@ static int =0A =
gnttab_prepare_for_transfer(=0A     struct domain *rd, struct domain *ld, =
grant_ref_t ref)=0A {=0A-    struct grant_table *rgt;=0A+    struct =
grant_table *rgt =3D rd->grant_table;=0A     grant_entry_header_t *sha;=0A =
    union grant_combo   scombo, prev_scombo, new_scombo;=0A     int        =
         retries =3D 0;=0A =0A-    if ( unlikely((rgt =3D rd->grant_table) =
=3D=3D NULL) )=0A-    {=0A-        gdprintk(XENLOG_INFO, "Dom %d has no =
grant table.\n", rd->domain_id);=0A-        return 0;=0A-    }=0A-=0A     =
spin_lock(&rgt->lock);=0A =0A     if ( rgt->gt_version =3D=3D 0 )=0A
--=__PartBE907177.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartBE907177.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7cW-0002Eu-3a; Tue, 17 Apr 2012 12:34:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7cU-0002Ep-4Y
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:34:54 +0000
Received: from [85.158.139.83:22606] by server-7.bemta-5.messagelabs.com id
	9D/B4-16195-D636D8F4; Tue, 17 Apr 2012 12:34:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334666092!24183208!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29985 invoked from network); 17 Apr 2012 12:34:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:34:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:34:51 +0100
Message-Id: <4F8D7F87020000780007E776@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:34:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBE907177.0__="
Subject: [Xen-devel] [PATCH] gnttab: remove pointless NULL check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBE907177.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Domains in the domain hash (and hence locatable via the usual lookup
functions) can't have a NULL grant table pointer; no other function
performs such a check, so remove it from gnttab_prepare_for_transfer()
for consistency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1390,17 +1390,11 @@ static int=20
 gnttab_prepare_for_transfer(
     struct domain *rd, struct domain *ld, grant_ref_t ref)
 {
-    struct grant_table *rgt;
+    struct grant_table *rgt =3D rd->grant_table;
     grant_entry_header_t *sha;
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries =3D 0;
=20
-    if ( unlikely((rgt =3D rd->grant_table) =3D=3D NULL) )
-    {
-        gdprintk(XENLOG_INFO, "Dom %d has no grant table.\n", rd->domain_i=
d);
-        return 0;
-    }
-
     spin_lock(&rgt->lock);
=20
     if ( rgt->gt_version =3D=3D 0 )




--=__PartBE907177.0__=
Content-Type: text/plain; name="gnttab-pointless-check.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gnttab-pointless-check.patch"

gnttab: remove pointless NULL check=0A=0ADomains in the domain hash (and =
hence locatable via the usual lookup=0Afunctions) can't have a NULL grant =
table pointer; no other function=0Aperforms such a check, so remove it =
from gnttab_prepare_for_transfer()=0Afor consistency.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -1390,17 +1390,11 @@ static int =0A =
gnttab_prepare_for_transfer(=0A     struct domain *rd, struct domain *ld, =
grant_ref_t ref)=0A {=0A-    struct grant_table *rgt;=0A+    struct =
grant_table *rgt =3D rd->grant_table;=0A     grant_entry_header_t *sha;=0A =
    union grant_combo   scombo, prev_scombo, new_scombo;=0A     int        =
         retries =3D 0;=0A =0A-    if ( unlikely((rgt =3D rd->grant_table) =
=3D=3D NULL) )=0A-    {=0A-        gdprintk(XENLOG_INFO, "Dom %d has no =
grant table.\n", rd->domain_id);=0A-        return 0;=0A-    }=0A-=0A     =
spin_lock(&rgt->lock);=0A =0A     if ( rgt->gt_version =3D=3D 0 )=0A
--=__PartBE907177.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartBE907177.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:46:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7my-0002SL-8B; Tue, 17 Apr 2012 12:45:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK7mx-0002SG-8p
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:45:43 +0000
Received: from [193.109.254.147:10969] by server-6.bemta-14.messagelabs.com id
	8F/02-02047-6F56D8F4; Tue, 17 Apr 2012 12:45:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334666727!4987387!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30883 invoked from network); 17 Apr 2012 12:45:27 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 12:45:27 -0000
Received: by bkcjg9 with SMTP id jg9so5689319bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 05:45:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LGDCP0uDx2839PX7uriML0SNMEVARYgr9wKm40RRU8g=;
	b=IqAhfAYXt2Fd3Z5REyT4Af++irdPq3UQPL8gQIwf6o9m1E1/woGE6RQk0ZI7x+NDg/
	Wl8gIubrYfZeg/c1mYAwkeO7/FurIEorkS6Y80XonhU9rd0EdENx+LBm4awrWwnGVRv1
	aH0pQe0wktga8iTXwa3Ag/JWOd329b909bLokNLWiYudpKF/auc2tiJEHgQBrRRWm3dv
	rX6cfxm8pP0T3Nldu+Rcxop+XctpxpDVGDNkqAoCNTwQaZU7sDR1lpqMjVbZVgb8Gca5
	7O0QYub+ZmTst0X5aZ4OPt+askIl8/4tXVg8xJIUhp3claMsNI6VeifDWv9Vsx5uFVL+
	kXGw==
Received: by 10.204.155.87 with SMTP id r23mr1669146bkw.103.1334666727159;
	Tue, 17 Apr 2012 05:45:27 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183]) by mx.google.com with ESMTPS id
	zx16sm37711203bkb.13.2012.04.17.05.45.25
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 05:45:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 13:45:19 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB3246F.3DFA9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] gnttab: remove pointless NULL check
Thread-Index: Ac0cl/IKqhbdJDvgvUGahB/OopmYdw==
In-Reply-To: <4F8D7F87020000780007E776@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] gnttab: remove pointless NULL check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:34, "Jan Beulich" <JBeulich@suse.com> wrote:

> Domains in the domain hash (and hence locatable via the usual lookup
> functions) can't have a NULL grant table pointer; no other function
> performs such a check, so remove it from gnttab_prepare_for_transfer()
> for consistency.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1390,17 +1390,11 @@ static int
>  gnttab_prepare_for_transfer(
>      struct domain *rd, struct domain *ld, grant_ref_t ref)
>  {
> -    struct grant_table *rgt;
> +    struct grant_table *rgt = rd->grant_table;
>      grant_entry_header_t *sha;
>      union grant_combo   scombo, prev_scombo, new_scombo;
>      int                 retries = 0;
>  
> -    if ( unlikely((rgt = rd->grant_table) == NULL) )
> -    {
> -        gdprintk(XENLOG_INFO, "Dom %d has no grant table.\n", rd->domain_id);
> -        return 0;
> -    }
> -
>      spin_lock(&rgt->lock);
>  
>      if ( rgt->gt_version == 0 )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 12:46:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7my-0002SL-8B; Tue, 17 Apr 2012 12:45:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK7mx-0002SG-8p
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:45:43 +0000
Received: from [193.109.254.147:10969] by server-6.bemta-14.messagelabs.com id
	8F/02-02047-6F56D8F4; Tue, 17 Apr 2012 12:45:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334666727!4987387!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30883 invoked from network); 17 Apr 2012 12:45:27 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 12:45:27 -0000
Received: by bkcjg9 with SMTP id jg9so5689319bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 05:45:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LGDCP0uDx2839PX7uriML0SNMEVARYgr9wKm40RRU8g=;
	b=IqAhfAYXt2Fd3Z5REyT4Af++irdPq3UQPL8gQIwf6o9m1E1/woGE6RQk0ZI7x+NDg/
	Wl8gIubrYfZeg/c1mYAwkeO7/FurIEorkS6Y80XonhU9rd0EdENx+LBm4awrWwnGVRv1
	aH0pQe0wktga8iTXwa3Ag/JWOd329b909bLokNLWiYudpKF/auc2tiJEHgQBrRRWm3dv
	rX6cfxm8pP0T3Nldu+Rcxop+XctpxpDVGDNkqAoCNTwQaZU7sDR1lpqMjVbZVgb8Gca5
	7O0QYub+ZmTst0X5aZ4OPt+askIl8/4tXVg8xJIUhp3claMsNI6VeifDWv9Vsx5uFVL+
	kXGw==
Received: by 10.204.155.87 with SMTP id r23mr1669146bkw.103.1334666727159;
	Tue, 17 Apr 2012 05:45:27 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183]) by mx.google.com with ESMTPS id
	zx16sm37711203bkb.13.2012.04.17.05.45.25
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 05:45:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 13:45:19 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB3246F.3DFA9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] gnttab: remove pointless NULL check
Thread-Index: Ac0cl/IKqhbdJDvgvUGahB/OopmYdw==
In-Reply-To: <4F8D7F87020000780007E776@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] gnttab: remove pointless NULL check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:34, "Jan Beulich" <JBeulich@suse.com> wrote:

> Domains in the domain hash (and hence locatable via the usual lookup
> functions) can't have a NULL grant table pointer; no other function
> performs such a check, so remove it from gnttab_prepare_for_transfer()
> for consistency.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1390,17 +1390,11 @@ static int
>  gnttab_prepare_for_transfer(
>      struct domain *rd, struct domain *ld, grant_ref_t ref)
>  {
> -    struct grant_table *rgt;
> +    struct grant_table *rgt = rd->grant_table;
>      grant_entry_header_t *sha;
>      union grant_combo   scombo, prev_scombo, new_scombo;
>      int                 retries = 0;
>  
> -    if ( unlikely((rgt = rd->grant_table) == NULL) )
> -    {
> -        gdprintk(XENLOG_INFO, "Dom %d has no grant table.\n", rd->domain_id);
> -        return 0;
> -    }
> -
>      spin_lock(&rgt->lock);
>  
>      if ( rgt->gt_version == 0 )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 12:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7n2-0002Sh-KQ; Tue, 17 Apr 2012 12:45:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7n0-0002SU-Ia
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:45:46 +0000
Received: from [85.158.139.83:14431] by server-9.bemta-5.messagelabs.com id
	AF/41-09826-9F56D8F4; Tue, 17 Apr 2012 12:45:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334666744!24185406!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15649 invoked from network); 17 Apr 2012 12:45:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:45:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:45:44 +0100
Message-Id: <4F8D8216020000780007E79A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:45:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2907E6E6.0__="
Subject: [Xen-devel] [PATCH] x86-64: fix #GP generation in assembly code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2907E6E6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When guest use of sysenter (64-bit PV guest) or syscall (32-bit PV
guest) gets converted into a GP fault (due to no callback having got
registered), we must
- honor the GP fault handler's request the keep enabled or mask event
  delivery
- not allow TBF_EXCEPTION to remain set past the generation of the
  (guest) exception in the vCPU's trap_bounce.flags, as that would
  otherwise allow for the next exception occurring in guest mode,
  should it happen to get handled in Xen itself, to nevertheless get
  bounced to the guest kernel.

Also, just like compat mode syscall handling already did, native mode
sysenter handling should, when converting to #GP, subtract 2 from the
RIP present in the frame so that the guest's GP fault handler would
see the fault pointing to the offending instruction instead of past it.

Finally, since those exception generating code blocks needed to be
modified anyway, convert them to make use of UNLIKELY_{START,END}().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -145,6 +145,7 @@ void __dummy__(void)
=20
     OFFSET(TRAPINFO_eip, struct trap_info, address);
     OFFSET(TRAPINFO_cs, struct trap_info, cs);
+    OFFSET(TRAPINFO_flags, struct trap_info, flags);
     DEFINE(TRAPINFO_sizeof, sizeof(struct trap_info));
     BLANK();
=20
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -213,6 +213,7 @@ compat_failsafe_callback:
 ENTRY(compat_post_handle_exception)
         testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
         jz    compat_test_all_events
+.Lcompat_bounce_exception:
         call  compat_create_bounce_frame
         movb  $0,TRAPBOUNCE_flags(%rdx)
         jmp   compat_test_all_events
@@ -225,20 +226,21 @@ ENTRY(compat_syscall)
         leaq  VCPU_trap_bounce(%rbx),%rdx
         testl $~3,%esi
         leal  (,%rcx,TBF_INTERRUPT),%ecx
-        jz    2f
-1:      movq  %rax,TRAPBOUNCE_eip(%rdx)
-        movw  %si,TRAPBOUNCE_cs(%rdx)
-        movb  %cl,TRAPBOUNCE_flags(%rdx)
-        call  compat_create_bounce_frame
-        jmp   compat_test_all_events
-2:      movq  VCPU_trap_ctxt(%rbx),%rsi
+UNLIKELY_START(z, compat_syscall_gpf)
+        movq  VCPU_trap_ctxt(%rbx),%rdi
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         subl  $2,UREGS_rip(%rsp)
-        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%eax
-        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rsi),%esi
-        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
         movl  $0,TRAPBOUNCE_error_code(%rdx)
-        jmp   1b
+        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax
+        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi
+        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)
+        setnz %cl
+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ec=
x
+UNLIKELY_END(compat_syscall_gpf)
+        movq  %rax,TRAPBOUNCE_eip(%rdx)
+        movw  %si,TRAPBOUNCE_cs(%rdx)
+        movb  %cl,TRAPBOUNCE_flags(%rdx)
+        jmp   .Lcompat_bounce_exception
=20
 ENTRY(compat_sysenter)
         movq  VCPU_trap_ctxt(%rbx),%rcx
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -277,20 +277,22 @@ sysenter_eflags_saved:
         leaq  VCPU_trap_bounce(%rbx),%rdx
         testq %rax,%rax
         leal  (,%rcx,TBF_INTERRUPT),%ecx
-        jz    2f
-1:      movq  VCPU_domain(%rbx),%rdi
+UNLIKELY_START(z, sysenter_gpf)
+        movq  VCPU_trap_ctxt(%rbx),%rsi
+        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
+        subl  $2,UREGS_rip(%rsp)
+        movl  %eax,TRAPBOUNCE_error_code(%rdx)
+        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
+        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)
+        setnz %cl
+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ec=
x
+UNLIKELY_END(sysenter_gpf)
+        movq  VCPU_domain(%rbx),%rdi
         movq  %rax,TRAPBOUNCE_eip(%rdx)
         movb  %cl,TRAPBOUNCE_flags(%rdx)
         testb $1,DOMAIN_is_32bit_pv(%rdi)
         jnz   compat_sysenter
-        call  create_bounce_frame
-        jmp   test_all_events
-2:      movq  VCPU_trap_ctxt(%rbx),%rcx
-        movl  %eax,TRAPBOUNCE_error_code(%rdx)
-        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%rax
-        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
-        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
-        jmp   1b
+        jmp   .Lbounce_exception
=20
 ENTRY(int80_direct_trap)
         pushq $0
@@ -483,6 +485,7 @@ handle_exception_saved:
         jnz   compat_post_handle_exception
         testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
         jz    test_all_events
+.Lbounce_exception:
         call  create_bounce_frame
         movb  $0,TRAPBOUNCE_flags(%rdx)
         jmp   test_all_events



--=__Part2907E6E6.0__=
Content-Type: text/plain; name="x86_64-trap-bounce-flags.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-trap-bounce-flags.patch"

x86-64: fix #GP generation in assembly code=0A=0AWhen guest use of =
sysenter (64-bit PV guest) or syscall (32-bit PV=0Aguest) gets converted =
into a GP fault (due to no callback having got=0Aregistered), we must=0A- =
honor the GP fault handler's request the keep enabled or mask event=0A  =
delivery=0A- not allow TBF_EXCEPTION to remain set past the generation of =
the=0A  (guest) exception in the vCPU's trap_bounce.flags, as that =
would=0A  otherwise allow for the next exception occurring in guest =
mode,=0A  should it happen to get handled in Xen itself, to nevertheless =
get=0A  bounced to the guest kernel.=0A=0AAlso, just like compat mode =
syscall handling already did, native mode=0Asysenter handling should, when =
converting to #GP, subtract 2 from the=0ARIP present in the frame so that =
the guest's GP fault handler would=0Asee the fault pointing to the =
offending instruction instead of past it.=0A=0AFinally, since those =
exception generating code blocks needed to be=0Amodified anyway, convert =
them to make use of UNLIKELY_{START,END}().=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/x86_64/asm-offsets.c=0A=
+++ b/xen/arch/x86/x86_64/asm-offsets.c=0A@@ -145,6 +145,7 @@ void =
__dummy__(void)=0A =0A     OFFSET(TRAPINFO_eip, struct trap_info, =
address);=0A     OFFSET(TRAPINFO_cs, struct trap_info, cs);=0A+    =
OFFSET(TRAPINFO_flags, struct trap_info, flags);=0A     DEFINE(TRAPINFO_siz=
eof, sizeof(struct trap_info));=0A     BLANK();=0A =0A--- a/xen/arch/x86/x8=
6_64/compat/entry.S=0A+++ b/xen/arch/x86/x86_64/compat/entry.S=0A@@ -213,6 =
+213,7 @@ compat_failsafe_callback:=0A ENTRY(compat_post_handle_exception)=
=0A         testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)=0A         jz    =
compat_test_all_events=0A+.Lcompat_bounce_exception:=0A         call  =
compat_create_bounce_frame=0A         movb  $0,TRAPBOUNCE_flags(%rdx)=0A   =
      jmp   compat_test_all_events=0A@@ -225,20 +226,21 @@ ENTRY(compat_sys=
call)=0A         leaq  VCPU_trap_bounce(%rbx),%rdx=0A         testl =
$~3,%esi=0A         leal  (,%rcx,TBF_INTERRUPT),%ecx=0A-        jz    =
2f=0A-1:      movq  %rax,TRAPBOUNCE_eip(%rdx)=0A-        movw  %si,TRAPBOUN=
CE_cs(%rdx)=0A-        movb  %cl,TRAPBOUNCE_flags(%rdx)=0A-        call  =
compat_create_bounce_frame=0A-        jmp   compat_test_all_events=0A-2:   =
   movq  VCPU_trap_ctxt(%rbx),%rsi=0A+UNLIKELY_START(z, compat_syscall_gpf)=
=0A+        movq  VCPU_trap_ctxt(%rbx),%rdi=0A         movl  $TRAP_gp_fault=
,UREGS_entry_vector(%rsp)=0A         subl  $2,UREGS_rip(%rsp)=0A-        =
movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%eax=0A-        =
movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rsi),%esi=0A-        =
movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl=0A         =
movl  $0,TRAPBOUNCE_error_code(%rdx)=0A-        jmp   1b=0A+        movl  =
TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax=0A+        =
movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi=0A+        =
testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)=0A+        =
setnz %cl=0A+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_IN=
TERRUPT),%ecx=0A+UNLIKELY_END(compat_syscall_gpf)=0A+        movq  =
%rax,TRAPBOUNCE_eip(%rdx)=0A+        movw  %si,TRAPBOUNCE_cs(%rdx)=0A+     =
   movb  %cl,TRAPBOUNCE_flags(%rdx)=0A+        jmp   .Lcompat_bounce_except=
ion=0A =0A ENTRY(compat_sysenter)=0A         movq  VCPU_trap_ctxt(%rbx),%rc=
x=0A--- a/xen/arch/x86/x86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=
=0A@@ -277,20 +277,22 @@ sysenter_eflags_saved:=0A         leaq  VCPU_trap_=
bounce(%rbx),%rdx=0A         testq %rax,%rax=0A         leal  (,%rcx,TBF_IN=
TERRUPT),%ecx=0A-        jz    2f=0A-1:      movq  VCPU_domain(%rbx),%rdi=
=0A+UNLIKELY_START(z, sysenter_gpf)=0A+        movq  VCPU_trap_ctxt(%rbx),%=
rsi=0A+        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A+        =
subl  $2,UREGS_rip(%rsp)=0A+        movl  %eax,TRAPBOUNCE_error_code(%rdx)=
=0A+        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax=
=0A+        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)=
=0A+        setnz %cl=0A+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(=
,%rcx,TBF_INTERRUPT),%ecx=0A+UNLIKELY_END(sysenter_gpf)=0A+        movq  =
VCPU_domain(%rbx),%rdi=0A         movq  %rax,TRAPBOUNCE_eip(%rdx)=0A       =
  movb  %cl,TRAPBOUNCE_flags(%rdx)=0A         testb $1,DOMAIN_is_32bit_pv(%=
rdi)=0A         jnz   compat_sysenter=0A-        call  create_bounce_frame=
=0A-        jmp   test_all_events=0A-2:      movq  VCPU_trap_ctxt(%rbx),%rc=
x=0A-        movl  %eax,TRAPBOUNCE_error_code(%rdx)=0A-        movq  =
TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%rax=0A-        movb  =
$(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl=0A-        movl  =
$TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A-        jmp   1b=0A+        jmp =
  .Lbounce_exception=0A =0A ENTRY(int80_direct_trap)=0A         pushq =
$0=0A@@ -483,6 +485,7 @@ handle_exception_saved:=0A         jnz   =
compat_post_handle_exception=0A         testb $TBF_EXCEPTION,TRAPBOUNCE_fla=
gs(%rdx)=0A         jz    test_all_events=0A+.Lbounce_exception:=0A        =
 call  create_bounce_frame=0A         movb  $0,TRAPBOUNCE_flags(%rdx)=0A   =
      jmp   test_all_events=0A
--=__Part2907E6E6.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part2907E6E6.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7n2-0002Sh-KQ; Tue, 17 Apr 2012 12:45:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7n0-0002SU-Ia
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:45:46 +0000
Received: from [85.158.139.83:14431] by server-9.bemta-5.messagelabs.com id
	AF/41-09826-9F56D8F4; Tue, 17 Apr 2012 12:45:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334666744!24185406!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15649 invoked from network); 17 Apr 2012 12:45:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:45:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:45:44 +0100
Message-Id: <4F8D8216020000780007E79A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:45:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2907E6E6.0__="
Subject: [Xen-devel] [PATCH] x86-64: fix #GP generation in assembly code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2907E6E6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When guest use of sysenter (64-bit PV guest) or syscall (32-bit PV
guest) gets converted into a GP fault (due to no callback having got
registered), we must
- honor the GP fault handler's request the keep enabled or mask event
  delivery
- not allow TBF_EXCEPTION to remain set past the generation of the
  (guest) exception in the vCPU's trap_bounce.flags, as that would
  otherwise allow for the next exception occurring in guest mode,
  should it happen to get handled in Xen itself, to nevertheless get
  bounced to the guest kernel.

Also, just like compat mode syscall handling already did, native mode
sysenter handling should, when converting to #GP, subtract 2 from the
RIP present in the frame so that the guest's GP fault handler would
see the fault pointing to the offending instruction instead of past it.

Finally, since those exception generating code blocks needed to be
modified anyway, convert them to make use of UNLIKELY_{START,END}().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -145,6 +145,7 @@ void __dummy__(void)
=20
     OFFSET(TRAPINFO_eip, struct trap_info, address);
     OFFSET(TRAPINFO_cs, struct trap_info, cs);
+    OFFSET(TRAPINFO_flags, struct trap_info, flags);
     DEFINE(TRAPINFO_sizeof, sizeof(struct trap_info));
     BLANK();
=20
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -213,6 +213,7 @@ compat_failsafe_callback:
 ENTRY(compat_post_handle_exception)
         testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
         jz    compat_test_all_events
+.Lcompat_bounce_exception:
         call  compat_create_bounce_frame
         movb  $0,TRAPBOUNCE_flags(%rdx)
         jmp   compat_test_all_events
@@ -225,20 +226,21 @@ ENTRY(compat_syscall)
         leaq  VCPU_trap_bounce(%rbx),%rdx
         testl $~3,%esi
         leal  (,%rcx,TBF_INTERRUPT),%ecx
-        jz    2f
-1:      movq  %rax,TRAPBOUNCE_eip(%rdx)
-        movw  %si,TRAPBOUNCE_cs(%rdx)
-        movb  %cl,TRAPBOUNCE_flags(%rdx)
-        call  compat_create_bounce_frame
-        jmp   compat_test_all_events
-2:      movq  VCPU_trap_ctxt(%rbx),%rsi
+UNLIKELY_START(z, compat_syscall_gpf)
+        movq  VCPU_trap_ctxt(%rbx),%rdi
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         subl  $2,UREGS_rip(%rsp)
-        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%eax
-        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rsi),%esi
-        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
         movl  $0,TRAPBOUNCE_error_code(%rdx)
-        jmp   1b
+        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax
+        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi
+        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)
+        setnz %cl
+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ec=
x
+UNLIKELY_END(compat_syscall_gpf)
+        movq  %rax,TRAPBOUNCE_eip(%rdx)
+        movw  %si,TRAPBOUNCE_cs(%rdx)
+        movb  %cl,TRAPBOUNCE_flags(%rdx)
+        jmp   .Lcompat_bounce_exception
=20
 ENTRY(compat_sysenter)
         movq  VCPU_trap_ctxt(%rbx),%rcx
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -277,20 +277,22 @@ sysenter_eflags_saved:
         leaq  VCPU_trap_bounce(%rbx),%rdx
         testq %rax,%rax
         leal  (,%rcx,TBF_INTERRUPT),%ecx
-        jz    2f
-1:      movq  VCPU_domain(%rbx),%rdi
+UNLIKELY_START(z, sysenter_gpf)
+        movq  VCPU_trap_ctxt(%rbx),%rsi
+        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
+        subl  $2,UREGS_rip(%rsp)
+        movl  %eax,TRAPBOUNCE_error_code(%rdx)
+        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
+        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)
+        setnz %cl
+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ec=
x
+UNLIKELY_END(sysenter_gpf)
+        movq  VCPU_domain(%rbx),%rdi
         movq  %rax,TRAPBOUNCE_eip(%rdx)
         movb  %cl,TRAPBOUNCE_flags(%rdx)
         testb $1,DOMAIN_is_32bit_pv(%rdi)
         jnz   compat_sysenter
-        call  create_bounce_frame
-        jmp   test_all_events
-2:      movq  VCPU_trap_ctxt(%rbx),%rcx
-        movl  %eax,TRAPBOUNCE_error_code(%rdx)
-        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%rax
-        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
-        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
-        jmp   1b
+        jmp   .Lbounce_exception
=20
 ENTRY(int80_direct_trap)
         pushq $0
@@ -483,6 +485,7 @@ handle_exception_saved:
         jnz   compat_post_handle_exception
         testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
         jz    test_all_events
+.Lbounce_exception:
         call  create_bounce_frame
         movb  $0,TRAPBOUNCE_flags(%rdx)
         jmp   test_all_events



--=__Part2907E6E6.0__=
Content-Type: text/plain; name="x86_64-trap-bounce-flags.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-trap-bounce-flags.patch"

x86-64: fix #GP generation in assembly code=0A=0AWhen guest use of =
sysenter (64-bit PV guest) or syscall (32-bit PV=0Aguest) gets converted =
into a GP fault (due to no callback having got=0Aregistered), we must=0A- =
honor the GP fault handler's request the keep enabled or mask event=0A  =
delivery=0A- not allow TBF_EXCEPTION to remain set past the generation of =
the=0A  (guest) exception in the vCPU's trap_bounce.flags, as that =
would=0A  otherwise allow for the next exception occurring in guest =
mode,=0A  should it happen to get handled in Xen itself, to nevertheless =
get=0A  bounced to the guest kernel.=0A=0AAlso, just like compat mode =
syscall handling already did, native mode=0Asysenter handling should, when =
converting to #GP, subtract 2 from the=0ARIP present in the frame so that =
the guest's GP fault handler would=0Asee the fault pointing to the =
offending instruction instead of past it.=0A=0AFinally, since those =
exception generating code blocks needed to be=0Amodified anyway, convert =
them to make use of UNLIKELY_{START,END}().=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/x86_64/asm-offsets.c=0A=
+++ b/xen/arch/x86/x86_64/asm-offsets.c=0A@@ -145,6 +145,7 @@ void =
__dummy__(void)=0A =0A     OFFSET(TRAPINFO_eip, struct trap_info, =
address);=0A     OFFSET(TRAPINFO_cs, struct trap_info, cs);=0A+    =
OFFSET(TRAPINFO_flags, struct trap_info, flags);=0A     DEFINE(TRAPINFO_siz=
eof, sizeof(struct trap_info));=0A     BLANK();=0A =0A--- a/xen/arch/x86/x8=
6_64/compat/entry.S=0A+++ b/xen/arch/x86/x86_64/compat/entry.S=0A@@ -213,6 =
+213,7 @@ compat_failsafe_callback:=0A ENTRY(compat_post_handle_exception)=
=0A         testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)=0A         jz    =
compat_test_all_events=0A+.Lcompat_bounce_exception:=0A         call  =
compat_create_bounce_frame=0A         movb  $0,TRAPBOUNCE_flags(%rdx)=0A   =
      jmp   compat_test_all_events=0A@@ -225,20 +226,21 @@ ENTRY(compat_sys=
call)=0A         leaq  VCPU_trap_bounce(%rbx),%rdx=0A         testl =
$~3,%esi=0A         leal  (,%rcx,TBF_INTERRUPT),%ecx=0A-        jz    =
2f=0A-1:      movq  %rax,TRAPBOUNCE_eip(%rdx)=0A-        movw  %si,TRAPBOUN=
CE_cs(%rdx)=0A-        movb  %cl,TRAPBOUNCE_flags(%rdx)=0A-        call  =
compat_create_bounce_frame=0A-        jmp   compat_test_all_events=0A-2:   =
   movq  VCPU_trap_ctxt(%rbx),%rsi=0A+UNLIKELY_START(z, compat_syscall_gpf)=
=0A+        movq  VCPU_trap_ctxt(%rbx),%rdi=0A         movl  $TRAP_gp_fault=
,UREGS_entry_vector(%rsp)=0A         subl  $2,UREGS_rip(%rsp)=0A-        =
movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%eax=0A-        =
movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rsi),%esi=0A-        =
movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl=0A         =
movl  $0,TRAPBOUNCE_error_code(%rdx)=0A-        jmp   1b=0A+        movl  =
TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax=0A+        =
movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi=0A+        =
testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)=0A+        =
setnz %cl=0A+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_IN=
TERRUPT),%ecx=0A+UNLIKELY_END(compat_syscall_gpf)=0A+        movq  =
%rax,TRAPBOUNCE_eip(%rdx)=0A+        movw  %si,TRAPBOUNCE_cs(%rdx)=0A+     =
   movb  %cl,TRAPBOUNCE_flags(%rdx)=0A+        jmp   .Lcompat_bounce_except=
ion=0A =0A ENTRY(compat_sysenter)=0A         movq  VCPU_trap_ctxt(%rbx),%rc=
x=0A--- a/xen/arch/x86/x86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=
=0A@@ -277,20 +277,22 @@ sysenter_eflags_saved:=0A         leaq  VCPU_trap_=
bounce(%rbx),%rdx=0A         testq %rax,%rax=0A         leal  (,%rcx,TBF_IN=
TERRUPT),%ecx=0A-        jz    2f=0A-1:      movq  VCPU_domain(%rbx),%rdi=
=0A+UNLIKELY_START(z, sysenter_gpf)=0A+        movq  VCPU_trap_ctxt(%rbx),%=
rsi=0A+        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A+        =
subl  $2,UREGS_rip(%rsp)=0A+        movl  %eax,TRAPBOUNCE_error_code(%rdx)=
=0A+        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax=
=0A+        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)=
=0A+        setnz %cl=0A+        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(=
,%rcx,TBF_INTERRUPT),%ecx=0A+UNLIKELY_END(sysenter_gpf)=0A+        movq  =
VCPU_domain(%rbx),%rdi=0A         movq  %rax,TRAPBOUNCE_eip(%rdx)=0A       =
  movb  %cl,TRAPBOUNCE_flags(%rdx)=0A         testb $1,DOMAIN_is_32bit_pv(%=
rdi)=0A         jnz   compat_sysenter=0A-        call  create_bounce_frame=
=0A-        jmp   test_all_events=0A-2:      movq  VCPU_trap_ctxt(%rbx),%rc=
x=0A-        movl  %eax,TRAPBOUNCE_error_code(%rdx)=0A-        movq  =
TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%rax=0A-        movb  =
$(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl=0A-        movl  =
$TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A-        jmp   1b=0A+        jmp =
  .Lbounce_exception=0A =0A ENTRY(int80_direct_trap)=0A         pushq =
$0=0A@@ -483,6 +485,7 @@ handle_exception_saved:=0A         jnz   =
compat_post_handle_exception=0A         testb $TBF_EXCEPTION,TRAPBOUNCE_fla=
gs(%rdx)=0A         jz    test_all_events=0A+.Lbounce_exception:=0A        =
 call  create_bounce_frame=0A         movb  $0,TRAPBOUNCE_flags(%rdx)=0A   =
      jmp   test_all_events=0A
--=__Part2907E6E6.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part2907E6E6.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:50:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7ql-0002db-9g; Tue, 17 Apr 2012 12:49:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7qi-0002dP-Sp
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:49:37 +0000
Received: from [85.158.138.51:12064] by server-8.bemta-3.messagelabs.com id
	09/DB-24428-FD66D8F4; Tue, 17 Apr 2012 12:49:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334666974!22548196!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31564 invoked from network); 17 Apr 2012 12:49:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:49:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:49:34 +0100
Message-Id: <4F8D82FC020000780007E7BE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:49:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part002ECFCC.0__="
Subject: [Xen-devel] [PATCH] x86/ioapic: Add register level checks to detect
 bogus io-apic entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part002ECFCC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the recent changes to clear_IO_APIC_pin() which tries to
clear remoteIRR bit explicitly, some of the users started to see
"Unable to reset IRR for apic .." messages.

Close look shows that these are related to bogus IO-APIC entries
which returns all 1s for their io-apic registers. And the
above mentioned error messages are benign. But kernel should
have ignored such io-apic's in the first place.

Check if register 0, 1, 2 of the listed io-apic are all 1s and
ignore such io-apic.

[original Linux patch:]
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -185,7 +185,7 @@ struct IO_APIC_route_entry **alloc_ioapi
         ioapic_entries[apic] =3D
             xmalloc_array(struct IO_APIC_route_entry,
                           nr_ioapic_entries[apic]);
-        if (!ioapic_entries[apic])
+        if (!ioapic_entries[apic] && nr_ioapic_entries[apic])
             goto nomem;
     }
=20
@@ -310,6 +310,9 @@ int save_IO_APIC_setup(struct IO_APIC_ro
         return -ENOMEM;
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
+
         if (!ioapic_entries[apic])
             return -ENOMEM;
=20
@@ -331,6 +334,9 @@ void mask_IO_APIC_setup(struct IO_APIC_r
         return;
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
+
         if (!ioapic_entries[apic])
             break;
=20
@@ -358,6 +364,9 @@ int restore_IO_APIC_setup(struct IO_APIC
         return -ENOMEM;
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
+
         if (!ioapic_entries[apic])
             return -ENOMEM;
=20
@@ -610,6 +619,8 @@ static int __init find_isa_irq_apic(int=20
     if (i < mp_irq_entries) {
         int apic;
         for(apic =3D 0; apic < nr_ioapics; apic++) {
+            if (!nr_ioapic_entries[apic])
+                continue;
             if (mp_ioapics[apic].mpc_apicid =3D=3D mp_irqs[i].mpc_dstapic)=

                 return apic;
         }
@@ -1080,6 +1091,8 @@ static void /*__init*/ __print_IO_APIC(v
     printk(KERN_INFO "testing the IO APIC.......................\n");
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
=20
 	spin_lock_irqsave(&ioapic_lock, flags);
 	reg_00.raw =3D io_apic_read(apic, 0);
@@ -1229,6 +1242,8 @@ static void __init enable_IO_APIC(void)
=20
     if (directed_eoi_enabled) {
         for (apic =3D 0; apic < nr_ioapics; apic++) {
+            if (!nr_ioapic_entries[apic])
+                continue;
             vector_map[apic] =3D xzalloc(vmask_t);
             BUG_ON(!vector_map[apic]);
         }
@@ -1354,6 +1369,8 @@ static void __init setup_ioapic_ids_from
      * Set the IOAPIC ID to the value stored in the MPC table.
      */
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
=20
         /* Read the register 0 value */
         spin_lock_irqsave(&ioapic_lock, flags);
@@ -2038,6 +2055,8 @@ void ioapic_resume(void)
=20
     spin_lock_irqsave(&ioapic_lock, flags);
     for (apic =3D 0; apic < nr_ioapics; apic++){
+        if (!nr_ioapic_entries[apic])
+            continue;
         reg_00.raw =3D __io_apic_read(apic, 0);
         if (reg_00.bits.ID !=3D mp_ioapics[apic].mpc_apicid) {
             reg_00.bits.ID =3D mp_ioapics[apic].mpc_apicid;
@@ -2225,8 +2244,12 @@ static int ioapic_physbase_to_id(unsigne
 {
     int apic;
     for ( apic =3D 0; apic < nr_ioapics; apic++ )
+    {
+        if ( !nr_ioapic_entries[apic] )
+            continue;
         if ( mp_ioapics[apic].mpc_apicaddr =3D=3D physbase )
             return apic;
+    }
     return -EINVAL;
 }
=20
@@ -2444,6 +2467,22 @@ void dump_ioapic_irq_info(void)
 static unsigned int __initdata max_gsi_irqs;
 integer_param("max_gsi_irqs", max_gsi_irqs);
=20
+static __init bool_t bad_ioapic_register(unsigned int idx)
+{
+    union IO_APIC_reg_00 reg_00 =3D { .raw =3D io_apic_read(idx, 0) };
+    union IO_APIC_reg_01 reg_01 =3D { .raw =3D io_apic_read(idx, 1) };
+    union IO_APIC_reg_02 reg_02 =3D { .raw =3D io_apic_read(idx, 2) };
+
+    if ( reg_00.raw =3D=3D -1 && reg_01.raw =3D=3D -1 && reg_02.raw =
=3D=3D -1 )
+    {
+        printk(KERN_WARNING "I/O APIC %#x registers return all ones, =
skipping!\n",
+               mp_ioapics[idx].mpc_apicaddr);
+        return 1;
+    }
+
+    return 0;
+}
+
 void __init init_ioapic_mappings(void)
 {
     unsigned long ioapic_phys;
@@ -2477,6 +2516,12 @@ void __init init_ioapic_mappings(void)
                     __fix_to_virt(idx), ioapic_phys);
         idx++;
=20
+        if ( bad_ioapic_register(i) )
+        {
+            __set_fixmap(idx, 0, 0);
+            continue;
+        }
+
         if ( smp_found_config )
         {
             /* The number of IO-APIC IRQ registers (=3D=3D #pins): */



--=__Part002ECFCC.0__=
Content-Type: text/plain; name="x86-ioapic-ignore-bogus.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-ignore-bogus.patch"

x86/ioapic: Add register level checks to detect bogus io-apic entries=0A=0A=
With the recent changes to clear_IO_APIC_pin() which tries to=0Aclear =
remoteIRR bit explicitly, some of the users started to see=0A"Unable to =
reset IRR for apic .." messages.=0A=0AClose look shows that these are =
related to bogus IO-APIC entries=0Awhich returns all 1s for their io-apic =
registers. And the=0Aabove mentioned error messages are benign. But kernel =
should=0Ahave ignored such io-apic's in the first place.=0A=0ACheck if =
register 0, 1, 2 of the listed io-apic are all 1s and=0Aignore such =
io-apic.=0A=0A[original Linux patch:]=0ASigned-off-by: Suresh Siddha =
<suresh.b.siddha@intel.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ =
-185,7 +185,7 @@ struct IO_APIC_route_entry **alloc_ioapi=0A         =
ioapic_entries[apic] =3D=0A             xmalloc_array(struct IO_APIC_route_=
entry,=0A                           nr_ioapic_entries[apic]);=0A-        =
if (!ioapic_entries[apic])=0A+        if (!ioapic_entries[apic] && =
nr_ioapic_entries[apic])=0A             goto nomem;=0A     }=0A =0A@@ =
-310,6 +310,9 @@ int save_IO_APIC_setup(struct IO_APIC_ro=0A         =
return -ENOMEM;=0A =0A     for (apic =3D 0; apic < nr_ioapics; apic++) =
{=0A+        if (!nr_ioapic_entries[apic])=0A+            continue;=0A+=0A =
        if (!ioapic_entries[apic])=0A             return -ENOMEM;=0A =0A@@ =
-331,6 +334,9 @@ void mask_IO_APIC_setup(struct IO_APIC_r=0A         =
return;=0A =0A     for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+       =
 if (!nr_ioapic_entries[apic])=0A+            continue;=0A+=0A         if =
(!ioapic_entries[apic])=0A             break;=0A =0A@@ -358,6 +364,9 @@ =
int restore_IO_APIC_setup(struct IO_APIC=0A         return -ENOMEM;=0A =0A =
    for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+        if (!nr_ioapic=
_entries[apic])=0A+            continue;=0A+=0A         if (!ioapic_entries=
[apic])=0A             return -ENOMEM;=0A =0A@@ -610,6 +619,8 @@ static =
int __init find_isa_irq_apic(int =0A     if (i < mp_irq_entries) {=0A      =
   int apic;=0A         for(apic =3D 0; apic < nr_ioapics; apic++) {=0A+   =
         if (!nr_ioapic_entries[apic])=0A+                continue;=0A     =
        if (mp_ioapics[apic].mpc_apicid =3D=3D mp_irqs[i].mpc_dstapic)=0A  =
               return apic;=0A         }=0A@@ -1080,6 +1091,8 @@ static =
void /*__init*/ __print_IO_APIC(v=0A     printk(KERN_INFO "testing the IO =
APIC.......................\n");=0A =0A     for (apic =3D 0; apic < =
nr_ioapics; apic++) {=0A+        if (!nr_ioapic_entries[apic])=0A+         =
   continue;=0A =0A 	spin_lock_irqsave(&ioapic_lock, flags);=0A 	=
reg_00.raw =3D io_apic_read(apic, 0);=0A@@ -1229,6 +1242,8 @@ static void =
__init enable_IO_APIC(void)=0A =0A     if (directed_eoi_enabled) {=0A      =
   for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+            if =
(!nr_ioapic_entries[apic])=0A+                continue;=0A             =
vector_map[apic] =3D xzalloc(vmask_t);=0A             BUG_ON(!vector_map[ap=
ic]);=0A         }=0A@@ -1354,6 +1369,8 @@ static void __init setup_ioapic_=
ids_from=0A      * Set the IOAPIC ID to the value stored in the MPC =
table.=0A      */=0A     for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+ =
       if (!nr_ioapic_entries[apic])=0A+            continue;=0A =0A       =
  /* Read the register 0 value */=0A         spin_lock_irqsave(&ioapic_lock=
, flags);=0A@@ -2038,6 +2055,8 @@ void ioapic_resume(void)=0A =0A     =
spin_lock_irqsave(&ioapic_lock, flags);=0A     for (apic =3D 0; apic < =
nr_ioapics; apic++){=0A+        if (!nr_ioapic_entries[apic])=0A+          =
  continue;=0A         reg_00.raw =3D __io_apic_read(apic, 0);=0A         =
if (reg_00.bits.ID !=3D mp_ioapics[apic].mpc_apicid) {=0A             =
reg_00.bits.ID =3D mp_ioapics[apic].mpc_apicid;=0A@@ -2225,8 +2244,12 @@ =
static int ioapic_physbase_to_id(unsigne=0A {=0A     int apic;=0A     for =
( apic =3D 0; apic < nr_ioapics; apic++ )=0A+    {=0A+        if ( =
!nr_ioapic_entries[apic] )=0A+            continue;=0A         if ( =
mp_ioapics[apic].mpc_apicaddr =3D=3D physbase )=0A             return =
apic;=0A+    }=0A     return -EINVAL;=0A }=0A =0A@@ -2444,6 +2467,22 @@ =
void dump_ioapic_irq_info(void)=0A static unsigned int __initdata =
max_gsi_irqs;=0A integer_param("max_gsi_irqs", max_gsi_irqs);=0A =0A+static=
 __init bool_t bad_ioapic_register(unsigned int idx)=0A+{=0A+    union =
IO_APIC_reg_00 reg_00 =3D { .raw =3D io_apic_read(idx, 0) };=0A+    union =
IO_APIC_reg_01 reg_01 =3D { .raw =3D io_apic_read(idx, 1) };=0A+    union =
IO_APIC_reg_02 reg_02 =3D { .raw =3D io_apic_read(idx, 2) };=0A+=0A+    if =
( reg_00.raw =3D=3D -1 && reg_01.raw =3D=3D -1 && reg_02.raw =3D=3D -1 =
)=0A+    {=0A+        printk(KERN_WARNING "I/O APIC %#x registers return =
all ones, skipping!\n",=0A+               mp_ioapics[idx].mpc_apicaddr);=0A=
+        return 1;=0A+    }=0A+=0A+    return 0;=0A+}=0A+=0A void __init =
init_ioapic_mappings(void)=0A {=0A     unsigned long ioapic_phys;=0A@@ =
-2477,6 +2516,12 @@ void __init init_ioapic_mappings(void)=0A              =
       __fix_to_virt(idx), ioapic_phys);=0A         idx++;=0A =0A+        =
if ( bad_ioapic_register(i) )=0A+        {=0A+            __set_fixmap(idx,=
 0, 0);=0A+            continue;=0A+        }=0A+=0A         if ( =
smp_found_config )=0A         {=0A             /* The number of IO-APIC =
IRQ registers (=3D=3D #pins): */=0A
--=__Part002ECFCC.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part002ECFCC.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:50:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7ql-0002db-9g; Tue, 17 Apr 2012 12:49:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7qi-0002dP-Sp
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:49:37 +0000
Received: from [85.158.138.51:12064] by server-8.bemta-3.messagelabs.com id
	09/DB-24428-FD66D8F4; Tue, 17 Apr 2012 12:49:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334666974!22548196!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31564 invoked from network); 17 Apr 2012 12:49:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:49:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:49:34 +0100
Message-Id: <4F8D82FC020000780007E7BE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:49:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part002ECFCC.0__="
Subject: [Xen-devel] [PATCH] x86/ioapic: Add register level checks to detect
 bogus io-apic entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part002ECFCC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the recent changes to clear_IO_APIC_pin() which tries to
clear remoteIRR bit explicitly, some of the users started to see
"Unable to reset IRR for apic .." messages.

Close look shows that these are related to bogus IO-APIC entries
which returns all 1s for their io-apic registers. And the
above mentioned error messages are benign. But kernel should
have ignored such io-apic's in the first place.

Check if register 0, 1, 2 of the listed io-apic are all 1s and
ignore such io-apic.

[original Linux patch:]
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -185,7 +185,7 @@ struct IO_APIC_route_entry **alloc_ioapi
         ioapic_entries[apic] =3D
             xmalloc_array(struct IO_APIC_route_entry,
                           nr_ioapic_entries[apic]);
-        if (!ioapic_entries[apic])
+        if (!ioapic_entries[apic] && nr_ioapic_entries[apic])
             goto nomem;
     }
=20
@@ -310,6 +310,9 @@ int save_IO_APIC_setup(struct IO_APIC_ro
         return -ENOMEM;
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
+
         if (!ioapic_entries[apic])
             return -ENOMEM;
=20
@@ -331,6 +334,9 @@ void mask_IO_APIC_setup(struct IO_APIC_r
         return;
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
+
         if (!ioapic_entries[apic])
             break;
=20
@@ -358,6 +364,9 @@ int restore_IO_APIC_setup(struct IO_APIC
         return -ENOMEM;
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
+
         if (!ioapic_entries[apic])
             return -ENOMEM;
=20
@@ -610,6 +619,8 @@ static int __init find_isa_irq_apic(int=20
     if (i < mp_irq_entries) {
         int apic;
         for(apic =3D 0; apic < nr_ioapics; apic++) {
+            if (!nr_ioapic_entries[apic])
+                continue;
             if (mp_ioapics[apic].mpc_apicid =3D=3D mp_irqs[i].mpc_dstapic)=

                 return apic;
         }
@@ -1080,6 +1091,8 @@ static void /*__init*/ __print_IO_APIC(v
     printk(KERN_INFO "testing the IO APIC.......................\n");
=20
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
=20
 	spin_lock_irqsave(&ioapic_lock, flags);
 	reg_00.raw =3D io_apic_read(apic, 0);
@@ -1229,6 +1242,8 @@ static void __init enable_IO_APIC(void)
=20
     if (directed_eoi_enabled) {
         for (apic =3D 0; apic < nr_ioapics; apic++) {
+            if (!nr_ioapic_entries[apic])
+                continue;
             vector_map[apic] =3D xzalloc(vmask_t);
             BUG_ON(!vector_map[apic]);
         }
@@ -1354,6 +1369,8 @@ static void __init setup_ioapic_ids_from
      * Set the IOAPIC ID to the value stored in the MPC table.
      */
     for (apic =3D 0; apic < nr_ioapics; apic++) {
+        if (!nr_ioapic_entries[apic])
+            continue;
=20
         /* Read the register 0 value */
         spin_lock_irqsave(&ioapic_lock, flags);
@@ -2038,6 +2055,8 @@ void ioapic_resume(void)
=20
     spin_lock_irqsave(&ioapic_lock, flags);
     for (apic =3D 0; apic < nr_ioapics; apic++){
+        if (!nr_ioapic_entries[apic])
+            continue;
         reg_00.raw =3D __io_apic_read(apic, 0);
         if (reg_00.bits.ID !=3D mp_ioapics[apic].mpc_apicid) {
             reg_00.bits.ID =3D mp_ioapics[apic].mpc_apicid;
@@ -2225,8 +2244,12 @@ static int ioapic_physbase_to_id(unsigne
 {
     int apic;
     for ( apic =3D 0; apic < nr_ioapics; apic++ )
+    {
+        if ( !nr_ioapic_entries[apic] )
+            continue;
         if ( mp_ioapics[apic].mpc_apicaddr =3D=3D physbase )
             return apic;
+    }
     return -EINVAL;
 }
=20
@@ -2444,6 +2467,22 @@ void dump_ioapic_irq_info(void)
 static unsigned int __initdata max_gsi_irqs;
 integer_param("max_gsi_irqs", max_gsi_irqs);
=20
+static __init bool_t bad_ioapic_register(unsigned int idx)
+{
+    union IO_APIC_reg_00 reg_00 =3D { .raw =3D io_apic_read(idx, 0) };
+    union IO_APIC_reg_01 reg_01 =3D { .raw =3D io_apic_read(idx, 1) };
+    union IO_APIC_reg_02 reg_02 =3D { .raw =3D io_apic_read(idx, 2) };
+
+    if ( reg_00.raw =3D=3D -1 && reg_01.raw =3D=3D -1 && reg_02.raw =
=3D=3D -1 )
+    {
+        printk(KERN_WARNING "I/O APIC %#x registers return all ones, =
skipping!\n",
+               mp_ioapics[idx].mpc_apicaddr);
+        return 1;
+    }
+
+    return 0;
+}
+
 void __init init_ioapic_mappings(void)
 {
     unsigned long ioapic_phys;
@@ -2477,6 +2516,12 @@ void __init init_ioapic_mappings(void)
                     __fix_to_virt(idx), ioapic_phys);
         idx++;
=20
+        if ( bad_ioapic_register(i) )
+        {
+            __set_fixmap(idx, 0, 0);
+            continue;
+        }
+
         if ( smp_found_config )
         {
             /* The number of IO-APIC IRQ registers (=3D=3D #pins): */



--=__Part002ECFCC.0__=
Content-Type: text/plain; name="x86-ioapic-ignore-bogus.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-ignore-bogus.patch"

x86/ioapic: Add register level checks to detect bogus io-apic entries=0A=0A=
With the recent changes to clear_IO_APIC_pin() which tries to=0Aclear =
remoteIRR bit explicitly, some of the users started to see=0A"Unable to =
reset IRR for apic .." messages.=0A=0AClose look shows that these are =
related to bogus IO-APIC entries=0Awhich returns all 1s for their io-apic =
registers. And the=0Aabove mentioned error messages are benign. But kernel =
should=0Ahave ignored such io-apic's in the first place.=0A=0ACheck if =
register 0, 1, 2 of the listed io-apic are all 1s and=0Aignore such =
io-apic.=0A=0A[original Linux patch:]=0ASigned-off-by: Suresh Siddha =
<suresh.b.siddha@intel.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ =
-185,7 +185,7 @@ struct IO_APIC_route_entry **alloc_ioapi=0A         =
ioapic_entries[apic] =3D=0A             xmalloc_array(struct IO_APIC_route_=
entry,=0A                           nr_ioapic_entries[apic]);=0A-        =
if (!ioapic_entries[apic])=0A+        if (!ioapic_entries[apic] && =
nr_ioapic_entries[apic])=0A             goto nomem;=0A     }=0A =0A@@ =
-310,6 +310,9 @@ int save_IO_APIC_setup(struct IO_APIC_ro=0A         =
return -ENOMEM;=0A =0A     for (apic =3D 0; apic < nr_ioapics; apic++) =
{=0A+        if (!nr_ioapic_entries[apic])=0A+            continue;=0A+=0A =
        if (!ioapic_entries[apic])=0A             return -ENOMEM;=0A =0A@@ =
-331,6 +334,9 @@ void mask_IO_APIC_setup(struct IO_APIC_r=0A         =
return;=0A =0A     for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+       =
 if (!nr_ioapic_entries[apic])=0A+            continue;=0A+=0A         if =
(!ioapic_entries[apic])=0A             break;=0A =0A@@ -358,6 +364,9 @@ =
int restore_IO_APIC_setup(struct IO_APIC=0A         return -ENOMEM;=0A =0A =
    for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+        if (!nr_ioapic=
_entries[apic])=0A+            continue;=0A+=0A         if (!ioapic_entries=
[apic])=0A             return -ENOMEM;=0A =0A@@ -610,6 +619,8 @@ static =
int __init find_isa_irq_apic(int =0A     if (i < mp_irq_entries) {=0A      =
   int apic;=0A         for(apic =3D 0; apic < nr_ioapics; apic++) {=0A+   =
         if (!nr_ioapic_entries[apic])=0A+                continue;=0A     =
        if (mp_ioapics[apic].mpc_apicid =3D=3D mp_irqs[i].mpc_dstapic)=0A  =
               return apic;=0A         }=0A@@ -1080,6 +1091,8 @@ static =
void /*__init*/ __print_IO_APIC(v=0A     printk(KERN_INFO "testing the IO =
APIC.......................\n");=0A =0A     for (apic =3D 0; apic < =
nr_ioapics; apic++) {=0A+        if (!nr_ioapic_entries[apic])=0A+         =
   continue;=0A =0A 	spin_lock_irqsave(&ioapic_lock, flags);=0A 	=
reg_00.raw =3D io_apic_read(apic, 0);=0A@@ -1229,6 +1242,8 @@ static void =
__init enable_IO_APIC(void)=0A =0A     if (directed_eoi_enabled) {=0A      =
   for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+            if =
(!nr_ioapic_entries[apic])=0A+                continue;=0A             =
vector_map[apic] =3D xzalloc(vmask_t);=0A             BUG_ON(!vector_map[ap=
ic]);=0A         }=0A@@ -1354,6 +1369,8 @@ static void __init setup_ioapic_=
ids_from=0A      * Set the IOAPIC ID to the value stored in the MPC =
table.=0A      */=0A     for (apic =3D 0; apic < nr_ioapics; apic++) {=0A+ =
       if (!nr_ioapic_entries[apic])=0A+            continue;=0A =0A       =
  /* Read the register 0 value */=0A         spin_lock_irqsave(&ioapic_lock=
, flags);=0A@@ -2038,6 +2055,8 @@ void ioapic_resume(void)=0A =0A     =
spin_lock_irqsave(&ioapic_lock, flags);=0A     for (apic =3D 0; apic < =
nr_ioapics; apic++){=0A+        if (!nr_ioapic_entries[apic])=0A+          =
  continue;=0A         reg_00.raw =3D __io_apic_read(apic, 0);=0A         =
if (reg_00.bits.ID !=3D mp_ioapics[apic].mpc_apicid) {=0A             =
reg_00.bits.ID =3D mp_ioapics[apic].mpc_apicid;=0A@@ -2225,8 +2244,12 @@ =
static int ioapic_physbase_to_id(unsigne=0A {=0A     int apic;=0A     for =
( apic =3D 0; apic < nr_ioapics; apic++ )=0A+    {=0A+        if ( =
!nr_ioapic_entries[apic] )=0A+            continue;=0A         if ( =
mp_ioapics[apic].mpc_apicaddr =3D=3D physbase )=0A             return =
apic;=0A+    }=0A     return -EINVAL;=0A }=0A =0A@@ -2444,6 +2467,22 @@ =
void dump_ioapic_irq_info(void)=0A static unsigned int __initdata =
max_gsi_irqs;=0A integer_param("max_gsi_irqs", max_gsi_irqs);=0A =0A+static=
 __init bool_t bad_ioapic_register(unsigned int idx)=0A+{=0A+    union =
IO_APIC_reg_00 reg_00 =3D { .raw =3D io_apic_read(idx, 0) };=0A+    union =
IO_APIC_reg_01 reg_01 =3D { .raw =3D io_apic_read(idx, 1) };=0A+    union =
IO_APIC_reg_02 reg_02 =3D { .raw =3D io_apic_read(idx, 2) };=0A+=0A+    if =
( reg_00.raw =3D=3D -1 && reg_01.raw =3D=3D -1 && reg_02.raw =3D=3D -1 =
)=0A+    {=0A+        printk(KERN_WARNING "I/O APIC %#x registers return =
all ones, skipping!\n",=0A+               mp_ioapics[idx].mpc_apicaddr);=0A=
+        return 1;=0A+    }=0A+=0A+    return 0;=0A+}=0A+=0A void __init =
init_ioapic_mappings(void)=0A {=0A     unsigned long ioapic_phys;=0A@@ =
-2477,6 +2516,12 @@ void __init init_ioapic_mappings(void)=0A              =
       __fix_to_virt(idx), ioapic_phys);=0A         idx++;=0A =0A+        =
if ( bad_ioapic_register(i) )=0A+        {=0A+            __set_fixmap(idx,=
 0, 0);=0A+            continue;=0A+        }=0A+=0A         if ( =
smp_found_config )=0A         {=0A             /* The number of IO-APIC =
IRQ registers (=3D=3D #pins): */=0A
--=__Part002ECFCC.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part002ECFCC.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:51:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:51:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7sQ-0002mk-Vl; Tue, 17 Apr 2012 12:51:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7sP-0002mW-ME
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:51:21 +0000
Received: from [85.158.138.51:32280] by server-3.bemta-3.messagelabs.com id
	A8/77-04048-8476D8F4; Tue, 17 Apr 2012 12:51:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334667079!18432750!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1267 invoked from network); 17 Apr 2012 12:51:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:51:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:51:18 +0100
Message-Id: <4F8D8365020000780007E7C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:51:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part98B65755.0__="
Subject: [Xen-devel] [PATCH] x86/IO-APIC: adjust an otherwise pretty useless
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part98B65755.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2164,8 +2164,8 @@ int io_apic_set_pci_routing (int ioapic,
     int vector;
=20
     if (!IO_APIC_IRQ(irq)) {
-        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ 0\n",
-               ioapic);
+        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ %d\n",
+               ioapic, irq);
         return -EINVAL;
     }
=20




--=__Part98B65755.0__=
Content-Type: text/plain; name="x86-ioapic-message.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-message.patch"

x86/IO-APIC: adjust an otherwise pretty useless message=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ =
b/xen/arch/x86/io_apic.c=0A@@ -2164,8 +2164,8 @@ int io_apic_set_pci_routin=
g (int ioapic,=0A     int vector;=0A =0A     if (!IO_APIC_IRQ(irq)) {=0A-  =
      printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ 0\n",=0A-      =
         ioapic);=0A+        printk(KERN_ERR "IOAPIC[%d]: Invalid =
reference to IRQ %d\n",=0A+               ioapic, irq);=0A         return =
-EINVAL;=0A     }=0A =0A
--=__Part98B65755.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part98B65755.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:51:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:51:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7sQ-0002mk-Vl; Tue, 17 Apr 2012 12:51:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7sP-0002mW-ME
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:51:21 +0000
Received: from [85.158.138.51:32280] by server-3.bemta-3.messagelabs.com id
	A8/77-04048-8476D8F4; Tue, 17 Apr 2012 12:51:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334667079!18432750!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1267 invoked from network); 17 Apr 2012 12:51:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:51:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:51:18 +0100
Message-Id: <4F8D8365020000780007E7C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:51:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part98B65755.0__="
Subject: [Xen-devel] [PATCH] x86/IO-APIC: adjust an otherwise pretty useless
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part98B65755.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2164,8 +2164,8 @@ int io_apic_set_pci_routing (int ioapic,
     int vector;
=20
     if (!IO_APIC_IRQ(irq)) {
-        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ 0\n",
-               ioapic);
+        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ %d\n",
+               ioapic, irq);
         return -EINVAL;
     }
=20




--=__Part98B65755.0__=
Content-Type: text/plain; name="x86-ioapic-message.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-message.patch"

x86/IO-APIC: adjust an otherwise pretty useless message=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ =
b/xen/arch/x86/io_apic.c=0A@@ -2164,8 +2164,8 @@ int io_apic_set_pci_routin=
g (int ioapic,=0A     int vector;=0A =0A     if (!IO_APIC_IRQ(irq)) {=0A-  =
      printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ 0\n",=0A-      =
         ioapic);=0A+        printk(KERN_ERR "IOAPIC[%d]: Invalid =
reference to IRQ %d\n",=0A+               ioapic, irq);=0A         return =
-EINVAL;=0A     }=0A =0A
--=__Part98B65755.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part98B65755.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:51:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:51:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7sV-0002nI-C5; Tue, 17 Apr 2012 12:51:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK7sT-0002n0-P4
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 12:51:25 +0000
Received: from [85.158.138.51:29423] by server-5.bemta-3.messagelabs.com id
	0A/DF-17113-C476D8F4; Tue, 17 Apr 2012 12:51:24 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334667082!22499865!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9324 invoked from network); 17 Apr 2012 12:51:24 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 12:51:24 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK7sQ-0007yR-0i
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 05:51:22 -0700
Date: Tue, 17 Apr 2012 05:51:22 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334667082015-5646484.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Save/restore error with xen-unstable and qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.12-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25194:6b72eb3b40cf)
# Qemu upstream commit is 4db776322827f0930d53b9e162dc1c6600d918d0
vi Makefile # removed dist-kernel to not compile kernel
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- Makefile: Some updates to uninstall
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
vi config/Tools.mk # workaround for libxl compilation problem
BISON               := bison
FLEX                := flex
-------------------------
make dist
./install.sh
insserv xencommons &&
insserv xendomains

xl configuration file:
-------------------------
name='XP'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
boot='d'
xen_platform_pci=1
viridian=1
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
#spice=1
#spicehost="0.0.0.0"
#spiceport=6000
#spicedisable_ticketing=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
stdvga=1
#device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
#videoram=128
#device_model_args=["-vga qxl"]
-------------------------

xl -v save XP /mnt/vm/save/XP
Saving to /mnt/vm/save/XP new xl format (info 0x0/0x0/1173)
xc: detail: type fail: page 1015 mfn 000feff7
xc: detail: delta 24187ms, dom0 53%, target 0%, sent 359Mb/s, dirtied 0Mb/s
0 pages
xc: detail: Total pages sent= 265216 (0.25x)
xc: detail: (of which 0 were fixups)
xc: detail: All memory is saved
xc: detail: Save exit rc=0
libxl: error: libxl_qmp.c:404:qmp_next: Socket read error: Connection reset
by peer
xl: fatal error: xl_cmdimpl.c:2625: Unknown error 18446744073709551615:
libxl_domain_suspend(ctx, NULL, domid, fd)

If you need more information ask and will post them

--
View this message in context: http://xen.1045712.n5.nabble.com/Save-restore-error-with-xen-unstable-and-qemu-upstream-tp5646484p5646484.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 12:51:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:51:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7sV-0002nI-C5; Tue, 17 Apr 2012 12:51:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK7sT-0002n0-P4
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 12:51:25 +0000
Received: from [85.158.138.51:29423] by server-5.bemta-3.messagelabs.com id
	0A/DF-17113-C476D8F4; Tue, 17 Apr 2012 12:51:24 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334667082!22499865!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9324 invoked from network); 17 Apr 2012 12:51:24 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 12:51:24 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK7sQ-0007yR-0i
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 05:51:22 -0700
Date: Tue, 17 Apr 2012 05:51:22 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334667082015-5646484.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Save/restore error with xen-unstable and qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.12-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25194:6b72eb3b40cf)
# Qemu upstream commit is 4db776322827f0930d53b9e162dc1c6600d918d0
vi Makefile # removed dist-kernel to not compile kernel
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- Makefile: Some updates to uninstall
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
vi config/Tools.mk # workaround for libxl compilation problem
BISON               := bison
FLEX                := flex
-------------------------
make dist
./install.sh
insserv xencommons &&
insserv xendomains

xl configuration file:
-------------------------
name='XP'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
boot='d'
xen_platform_pci=1
viridian=1
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
#spice=1
#spicehost="0.0.0.0"
#spiceport=6000
#spicedisable_ticketing=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
stdvga=1
#device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
#videoram=128
#device_model_args=["-vga qxl"]
-------------------------

xl -v save XP /mnt/vm/save/XP
Saving to /mnt/vm/save/XP new xl format (info 0x0/0x0/1173)
xc: detail: type fail: page 1015 mfn 000feff7
xc: detail: delta 24187ms, dom0 53%, target 0%, sent 359Mb/s, dirtied 0Mb/s
0 pages
xc: detail: Total pages sent= 265216 (0.25x)
xc: detail: (of which 0 were fixups)
xc: detail: All memory is saved
xc: detail: Save exit rc=0
libxl: error: libxl_qmp.c:404:qmp_next: Socket read error: Connection reset
by peer
xl: fatal error: xl_cmdimpl.c:2625: Unknown error 18446744073709551615:
libxl_domain_suspend(ctx, NULL, domid, fd)

If you need more information ask and will post them

--
View this message in context: http://xen.1045712.n5.nabble.com/Save-restore-error-with-xen-unstable-and-qemu-upstream-tp5646484p5646484.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 12:56:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7wr-00037l-29; Tue, 17 Apr 2012 12:55:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SK7wp-00037a-D7
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 12:55:55 +0000
Received: from [85.158.143.35:26776] by server-2.bemta-4.messagelabs.com id
	18/FA-17550-A586D8F4; Tue, 17 Apr 2012 12:55:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334667353!9222553!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEzMjI5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11698 invoked from network); 17 Apr 2012 12:55:53 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-21.messagelabs.com with SMTP;
	17 Apr 2012 12:55:53 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 17 Apr 2012 05:55:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89990482"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 05:55:52 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 05:55:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Tue, 17 Apr 2012 20:55:50 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 2/2] Register native mce handler as vMCE bounce back point
Thread-Index: AQHNHA92/TdpFhoPSxCwxlIbh3KVRpae+H1Q
Date: Tue, 17 Apr 2012 12:55:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
In-Reply-To: <20120416202821.GC14982@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
 bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
>>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Mon, 16 Apr 2012 00:16:58 +0800
>> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back
>> point 
>> 
>> When xen hyeprvisor inject vMCE to guest, use native mce handler to
>> handle it 
> 
> hypervisor
> 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> Signed-off-by: Ke, Liping <liping.ke@intel.com>
>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>  --- arch/x86/xen/enlighten.c |   10 +++++++---
>>  1 files changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 15628d4..346ba64 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
>> gate_desc *val,  	/* 
>>  	 * Look for known traps using IST, and substitute them
>>  	 * appropriately.  The debugger ones are the only ones we care
>> -	 * about.  Xen will handle faults like double_fault and
>> -	 * machine_check, so we should never see them.  Warn if
>> +	 * about.  Xen will handle faults like double_fault,
>> +	 * so we should never see them.  Warn if
>>  	 * there's an unexpected IST-using fault handler.  	 */
>>  	if (addr == (unsigned long)debug)
>> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
>>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
>>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
>> +		/*
>> +		 * when xen hyeprvisor inject vMCE to guest,
>> +		 * use native mce handler to handle it
>> +		 */
>> +		;
> 
> 
> Can you just take the check out?

What do you mean by 'check out'? remove
else if (addr == (unsigned long) machine_check) {
	;
}
?

That would fail to register mce bounce back point.

> 
> 
>>  #endif
>>  	} else {
>>  		/* Some other trap using IST? */
>> --
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 12:56:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7wr-00037l-29; Tue, 17 Apr 2012 12:55:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SK7wp-00037a-D7
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 12:55:55 +0000
Received: from [85.158.143.35:26776] by server-2.bemta-4.messagelabs.com id
	18/FA-17550-A586D8F4; Tue, 17 Apr 2012 12:55:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334667353!9222553!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEzMjI5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11698 invoked from network); 17 Apr 2012 12:55:53 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-21.messagelabs.com with SMTP;
	17 Apr 2012 12:55:53 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 17 Apr 2012 05:55:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89990482"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 05:55:52 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 05:55:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Tue, 17 Apr 2012 20:55:50 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 2/2] Register native mce handler as vMCE bounce back point
Thread-Index: AQHNHA92/TdpFhoPSxCwxlIbh3KVRpae+H1Q
Date: Tue, 17 Apr 2012 12:55:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
In-Reply-To: <20120416202821.GC14982@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
 bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
>>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Mon, 16 Apr 2012 00:16:58 +0800
>> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back
>> point 
>> 
>> When xen hyeprvisor inject vMCE to guest, use native mce handler to
>> handle it 
> 
> hypervisor
> 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> Signed-off-by: Ke, Liping <liping.ke@intel.com>
>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>  --- arch/x86/xen/enlighten.c |   10 +++++++---
>>  1 files changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 15628d4..346ba64 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
>> gate_desc *val,  	/* 
>>  	 * Look for known traps using IST, and substitute them
>>  	 * appropriately.  The debugger ones are the only ones we care
>> -	 * about.  Xen will handle faults like double_fault and
>> -	 * machine_check, so we should never see them.  Warn if
>> +	 * about.  Xen will handle faults like double_fault,
>> +	 * so we should never see them.  Warn if
>>  	 * there's an unexpected IST-using fault handler.  	 */
>>  	if (addr == (unsigned long)debug)
>> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
>>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
>>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
>> +		/*
>> +		 * when xen hyeprvisor inject vMCE to guest,
>> +		 * use native mce handler to handle it
>> +		 */
>> +		;
> 
> 
> Can you just take the check out?

What do you mean by 'check out'? remove
else if (addr == (unsigned long) machine_check) {
	;
}
?

That would fail to register mce bounce back point.

> 
> 
>>  #endif
>>  	} else {
>>  		/* Some other trap using IST? */
>> --
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 12:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7zX-0003FK-Ko; Tue, 17 Apr 2012 12:58:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7zW-0003FD-CW
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:58:42 +0000
Received: from [85.158.138.51:9439] by server-12.bemta-3.messagelabs.com id
	51/20-29760-FF86D8F4; Tue, 17 Apr 2012 12:58:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334667517!22427245!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5341 invoked from network); 17 Apr 2012 12:58:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:58:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:58:37 +0100
Message-Id: <4F8D851B020000780007E7E6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:58:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2907E6EB.0__="
Subject: [Xen-devel] [PATCH] x86: suppress warning messages on IO-APIC-less
	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2907E6EB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Each call to mp_register_gsi() so far produced two warnings (about not
being able to find the corresponding IO-APIC pin).

However, we should use the provided information for setting the ELCR
correctly (we might want to even do this when there is an IO-APIC, if
was absolutely certain that all machines really have this register
[and specifically not some other device at the two I/O ports in
question]). It is in any case questionable that we allow Dom0 to set
this register - it could particularly be the interrupt of a plug-in
serial port card that might not work due to this. The problem is that
all Dom0 kernels to date do so, hence we can't simply #GP on such an
access (which would be the result if we disallowed access to the port
as we should have done from the beginning).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -1034,6 +1034,21 @@ int mp_register_gsi (u32 gsi, int trigge
 		return gsi;
 #endif
=20
+	if (!nr_ioapics) {
+		unsigned int port =3D 0x4d0 + (gsi >> 3);
+		u8 val;
+
+		if (!platform_legacy_irq(gsi))
+			return -EINVAL;
+		val =3D inb(port);
+		if (triggering)
+			val |=3D 1 << (gsi & 7);
+		else
+			val &=3D ~(1 << (gsi & 7));
+		outb(val, port);
+		return 0;
+	}
+
 	ioapic =3D mp_find_ioapic(gsi);
 	if (ioapic < 0) {
 		printk(KERN_WARNING "No IOAPIC for GSI %u\n", gsi);




--=__Part2907E6EB.0__=
Content-Type: text/plain; name="x86-no-ioapic.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-no-ioapic.patch"

x86: suppress warning messages on IO-APIC-less systems=0A=0AEach call to =
mp_register_gsi() so far produced two warnings (about not=0Abeing able to =
find the corresponding IO-APIC pin).=0A=0AHowever, we should use the =
provided information for setting the ELCR=0Acorrectly (we might want to =
even do this when there is an IO-APIC, if=0Awas absolutely certain that =
all machines really have this register=0A[and specifically not some other =
device at the two I/O ports in=0Aquestion]). It is in any case questionable=
 that we allow Dom0 to set=0Athis register - it could particularly be the =
interrupt of a plug-in=0Aserial port card that might not work due to this. =
The problem is that=0Aall Dom0 kernels to date do so, hence we can't =
simply #GP on such an=0Aaccess (which would be the result if we disallowed =
access to the port=0Aas we should have done from the beginning).=0A=0ASigne=
d-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mpparse.c=
=0A+++ b/xen/arch/x86/mpparse.c=0A@@ -1034,6 +1034,21 @@ int mp_register_gs=
i (u32 gsi, int trigge=0A 		return gsi;=0A #endif=0A =0A+	if =
(!nr_ioapics) {=0A+		unsigned int port =3D 0x4d0 + (gsi >> =
3);=0A+		u8 val;=0A+=0A+		if (!platform_legacy_irq(gsi))=0A+	=
		return -EINVAL;=0A+		val =3D inb(port);=0A+		=
if (triggering)=0A+			val |=3D 1 << (gsi & 7);=0A+		=
else=0A+			val &=3D ~(1 << (gsi & 7));=0A+		=
outb(val, port);=0A+		return 0;=0A+	}=0A+=0A 	ioapic =3D =
mp_find_ioapic(gsi);=0A 	if (ioapic < 0) {=0A 		printk(KERN=
_WARNING "No IOAPIC for GSI %u\n", gsi);=0A
--=__Part2907E6EB.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part2907E6EB.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 12:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 12:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK7zX-0003FK-Ko; Tue, 17 Apr 2012 12:58:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK7zW-0003FD-CW
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 12:58:42 +0000
Received: from [85.158.138.51:9439] by server-12.bemta-3.messagelabs.com id
	51/20-29760-FF86D8F4; Tue, 17 Apr 2012 12:58:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334667517!22427245!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5341 invoked from network); 17 Apr 2012 12:58:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 12:58:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 13:58:37 +0100
Message-Id: <4F8D851B020000780007E7E6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 13:58:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2907E6EB.0__="
Subject: [Xen-devel] [PATCH] x86: suppress warning messages on IO-APIC-less
	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2907E6EB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Each call to mp_register_gsi() so far produced two warnings (about not
being able to find the corresponding IO-APIC pin).

However, we should use the provided information for setting the ELCR
correctly (we might want to even do this when there is an IO-APIC, if
was absolutely certain that all machines really have this register
[and specifically not some other device at the two I/O ports in
question]). It is in any case questionable that we allow Dom0 to set
this register - it could particularly be the interrupt of a plug-in
serial port card that might not work due to this. The problem is that
all Dom0 kernels to date do so, hence we can't simply #GP on such an
access (which would be the result if we disallowed access to the port
as we should have done from the beginning).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -1034,6 +1034,21 @@ int mp_register_gsi (u32 gsi, int trigge
 		return gsi;
 #endif
=20
+	if (!nr_ioapics) {
+		unsigned int port =3D 0x4d0 + (gsi >> 3);
+		u8 val;
+
+		if (!platform_legacy_irq(gsi))
+			return -EINVAL;
+		val =3D inb(port);
+		if (triggering)
+			val |=3D 1 << (gsi & 7);
+		else
+			val &=3D ~(1 << (gsi & 7));
+		outb(val, port);
+		return 0;
+	}
+
 	ioapic =3D mp_find_ioapic(gsi);
 	if (ioapic < 0) {
 		printk(KERN_WARNING "No IOAPIC for GSI %u\n", gsi);




--=__Part2907E6EB.0__=
Content-Type: text/plain; name="x86-no-ioapic.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-no-ioapic.patch"

x86: suppress warning messages on IO-APIC-less systems=0A=0AEach call to =
mp_register_gsi() so far produced two warnings (about not=0Abeing able to =
find the corresponding IO-APIC pin).=0A=0AHowever, we should use the =
provided information for setting the ELCR=0Acorrectly (we might want to =
even do this when there is an IO-APIC, if=0Awas absolutely certain that =
all machines really have this register=0A[and specifically not some other =
device at the two I/O ports in=0Aquestion]). It is in any case questionable=
 that we allow Dom0 to set=0Athis register - it could particularly be the =
interrupt of a plug-in=0Aserial port card that might not work due to this. =
The problem is that=0Aall Dom0 kernels to date do so, hence we can't =
simply #GP on such an=0Aaccess (which would be the result if we disallowed =
access to the port=0Aas we should have done from the beginning).=0A=0ASigne=
d-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mpparse.c=
=0A+++ b/xen/arch/x86/mpparse.c=0A@@ -1034,6 +1034,21 @@ int mp_register_gs=
i (u32 gsi, int trigge=0A 		return gsi;=0A #endif=0A =0A+	if =
(!nr_ioapics) {=0A+		unsigned int port =3D 0x4d0 + (gsi >> =
3);=0A+		u8 val;=0A+=0A+		if (!platform_legacy_irq(gsi))=0A+	=
		return -EINVAL;=0A+		val =3D inb(port);=0A+		=
if (triggering)=0A+			val |=3D 1 << (gsi & 7);=0A+		=
else=0A+			val &=3D ~(1 << (gsi & 7));=0A+		=
outb(val, port);=0A+		return 0;=0A+	}=0A+=0A 	ioapic =3D =
mp_find_ioapic(gsi);=0A 	if (ioapic < 0) {=0A 		printk(KERN=
_WARNING "No IOAPIC for GSI %u\n", gsi);=0A
--=__Part2907E6EB.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part2907E6EB.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89J-0003U9-PX; Tue, 17 Apr 2012 13:08:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SK89I-0003U4-Lb
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 13:08:48 +0000
Received: from [193.109.254.147:20972] by server-1.bemta-14.messagelabs.com id
	9F/30-29372-06B6D8F4; Tue, 17 Apr 2012 13:08:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334668126!4989202!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7938 invoked from network); 17 Apr 2012 13:08:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 13:08:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HD8f4Z019398
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 13:08:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HD8eKm013380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 13:08:40 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HD8dxp018818; Tue, 17 Apr 2012 08:08:40 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 06:08:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A36CE40280; Tue, 17 Apr 2012 09:03:40 -0400 (EDT)
Date: Tue, 17 Apr 2012 09:03:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120417130340.GA25593@phenom.dumpdata.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F8D6B5A.00A8,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> This patch is a significant performance improvement for the
> m2p_override: about 6% using the gntdev device.
> 
> Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> is a great performance benefit because it means issuing one hypercall
> total rather than two hypercall per page.
> If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> going to be batched together, otherwise they are issued one at a time.
> 
> Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> m2p_add/remove_override calls forces paravirt_lazy_mode to
> PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> 
> 
> Changes in v3:
> - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> can be called in interrupt context.

This is with RHEL5 (somehow the pvops kernels don't trigger this):

[  311.247884] xen-blkback:ring-ref 8, event-channel 11, protocol 1 (x86_64-abi)
[  313.200497] ------------[ cut here ]------------
[  313.205166] kernel BUG at /home/konrad/linux/arch/x86/kernel/paravirt.cahci libahci font bitblit ttm libata softcursor scsi_mod drm_kms_helper wmi xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd [last unloaded: dump_dma]
[  313.256453]
[  313.258064] Pid: 3370, comm: run_guests Tainted: G           O 3.4.0-rc3upstream-10947-g331a503 #1 System manufacturer System Product Name/F1A75-M
[  313.271667] RIP: e030:[<ffffffff8105f86e>]  [<ffffffff8105f86e>] paravirt_enter_lazy_mmu+0x1e/0x30
[  313.280977] RSP: e02b:ffff8802014549e0  EFLAGS: 00010202
[  313.286544] RAX: 0000000000000001 RBX: ffff880201454b50 RCX: 0000000000000000
[  313.293971] RDX: 0000000000000001 RSI: ffff880201454a40 RDI: 0000000000000001
[  313.301400] RBP: ffff8802014549e0 R08: ffff880000000000 R09: 0000000000000000
[  313.308829] R10: 0000000000000000 R11: 0000000000000028 R12: 0000000000000001
[  313.316257] R13: 0000000000000000 R14: 0000000000000030 R15: aaaaaaaaaaaaaaab
[  313.323691] FS:  00007fb6cc941700(0000) GS:ffff880201451000(0000) knlGS:0000000000000000
[  313.332101] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  313.338099] CR2: 0000000001d2a1a8 CR3: 00000001e660e000 CR4: 0000000000000660
[  313.345527] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  313.352955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  313.360384] Process run_guests (pid: 3370, threadinfo ffff8801ecece000, task ffff8801f4e91080)
[  313.369334] Stack:
[  313.371482]  ffff880201454a10 ffffffff81310048 0000000000000001 0000000000000001
[  313.379181]  ffff8801e48c74b0 0000000000000030 ffff880201454be0 ffffffff8138d677
[  313.386877]  00000000000004b0 0000160000000000 0000000000000000 ffff880201454a40
[  313.394576] Call Trace:
[  313.397172]  <IRQ>
[  313.399411]  [<ffffffff81310048>] gnttab_unmap_refs+0x38/0x90
[  313.405410]  [<ffffffff8138d677>] xen_blkbk_unmap+0x1f7/0x220
[  313.411406]  [<ffffffff814b165b>] ? tcp_cleanup_rbuf+0x6b/0x100
[  313.417579]  [<ffffffff814b3bfb>] ? tcp_read_sock+0x1bb/0x220
[  313.423578]  [<ffffffffa030fec0>] ? iscsi_sw_tcp_state_change+0xd0/0xd0 [iscsi_tcp]
[  313.431543]  [<ffffffffa03102f3>] ? iscsi_sw_tcp_data_ready+0x73/0xe8 [iscsi_tcp]
[  313.439330]  [<ffffffff814b7ea8>] ? __tcp_ack_snd_check+0x68/0x90
[  313.445686]  [<ffffffff81032fed>] ? xen_force_evtchn_callback+0xd/0x10
[  313.439330]  [<ffffffff814b7ea8>] ? __tcp_ack_snd_check+0x68/0x90
[  313.445686]  [<ffffffff81032fed>] ? xen_force_evtchn_callback+0xd/0x10
[  313.452488]  [<ffffffff81033852>] ? check_events+0x12/0x20
[  313.458216]  [<ffffffff8103383f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  313.465110]  [<ffffffff8113d7f5>] ? kmem_cache_free+0xc5/0x2a0
[  313.471194]  [<ffffffff8138d6e8>] __end_block_io_op+0x48/0x110
[  313.477283]  [<ffffffff8138d7c5>] end_block_io_op+0x15/0x30
[  313.483099]  [<ffffffff81175dc8>] bio_endio+0x18/0x30
[  313.488381]  [<ffffffffa0316239>] dec_pending+0x189/0x290 [dm_mod]
[  313.494824]  [<ffffffffa0316569>] clone_endio+0x99/0xd0 [dm_mod]
[  313.501089]  [<ffffffff81175dc8>] bio_endio+0x18/0x30
[  313.506373]  [<ffffffff81269cf3>] req_bio_endio+0x83/0xc0
[  313.512009]  [<ffffffff8126b217>] blk_update_request+0xe7/0x450
[  313.518186]  [<ffffffff8131d9d1>] ? xen_virt_to_bus+0x11/0x20
[  313.524181]  [<ffffffff8126b5a2>] blk_update_bidi_request+0x22/0xa0
[  313.530715]  [<ffffffff8126b64a>] blk_end_bidi_request+0x2a/0x80
[  313.536981]  [<ffffffff8126b6db>] blk_end_request+0xb/0x10
[  313.542712]  [<ffffffffa005a96a>] scsi_io_completion+0xaa/0x630 [scsi_mod]
[  313.549870]  [<ffffffff815a7c69>] ? _raw_spin_unlock_irqrestore+0x19/0x30
[  313.556942]  [<ffffffffa005290f>] scsi_finish_command+0xcf/0x130 [scsi_mod]
[  313.564193]  [<ffffffffa005b03f>] scsi_softirq_done+0x13f/0x160 [scsi_mod]
[  313.571352]  [<ffffffff8127168d>] blk_done_softirq+0x7d/0x90
[  313.577260]  [<ffffffff810773a9>] __do_softirq+0xa9/0x160
[  313.582899]  [<ffffffff815afc9c>] call_softirq+0x1c/0x30
[  313.588446]  [<ffffffff81039405>] do_softirq+0x65/0xa0
[  313.593819]  [<ffffffff810771a5>] irq_exit+0xd5/0xf0
[  313.599010]  [<ffffffff8131207f>] xen_evtchn_do_upcall+0x2f/0x40
[  313.605273]  [<ffffffff815afcee>] xen_do_hypervisor_callback+0x1e/0x30
[  313.612076]  <EOI>
[  313.614313]  [<ffffffff8111d19e>] ? copy_pte_range+0x36e/0x5f0
[  313.620401]  [<ffffffff8111d6a8>] ? copy_page_range+0x288/0x490
[  313.626576]  [<ffffffff8106e643>] ? dup_mm+0x2d3/0x4a0
[  313.631946]  [<ffffffff8106f710>] ? copy_process+0xf00/0x13e0
[  313.637944]  [<ffffffff8106fe79>] ? do_fork+0x59/0x300
[  313.643314]  [<ffffffff8107e74b>] ? do_sigaction+0x13b/0x1e0
[  313.649221]  [<ffffffff8107f252>] ? __set_task_blocked+0x32/0x80
[  313.655486]  [<ffffffff8107f2f7>] ? set_current_blocked+0x57/0x80
[  313.661842]  [<ffffffff8103fd33>] ? sys_clone+0x23/0x30
[  313.667302]  [<ffffffff815aebc3>] ? stub_clone+0x13/0x20
[  313.672851]  [<ffffffff815ae8b9>] ? system_call_fastpath+0x16/0x1b
[  313.679294] Code: 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 65 8b 04 25 00 e0 00 00 85 c0 48 89 e5 75 0e 65 c7 04 25 00 e0 00 00 01 00 00 00 c9 c3 <0f> 0b eb fe 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 65 48
[  313.698805] RIP  [<ffffffff8105f86e>] paravirt_enter_lazy_mmu+0x1e/0x30
[  313.705698]  RSP <ffff8802014549e0>
[  313.709370] ---[ end trace 6d0134ded298d0e6 ]---
[  313.714201] Kernel panic - not syncing: Fatal exception in interrupt
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/block/xen-blkback/blkback.c |    2 ++
>  drivers/xen/grant-table.c           |    8 ++++++++
>  2 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 0088bf6..0453695 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -386,6 +386,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> +	arch_enter_lazy_mmu_mode();
>  	for (i = 0; i < nseg; i++) {
>  		if (unlikely(map[i].status != 0)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> @@ -410,6 +411,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  		seg[i].buf  = map[i].dev_bus_addr |
>  			(req->u.rw.seg[i].first_sect << 9);
>  	}
> +	arch_leave_lazy_mmu_mode();
>  	return ret;
>  }
>  
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b4d4eac..c7dc2d6 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -751,6 +751,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	arch_enter_lazy_mmu_mode();
> +
>  	for (i = 0; i < count; i++) {
>  		/* Do not add to override if the map failed. */
>  		if (map_ops[i].status)
> @@ -769,6 +771,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  			return ret;
>  	}
>  
> +	arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_map_refs);
> @@ -785,12 +789,16 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	arch_enter_lazy_mmu_mode();
> +
>  	for (i = 0; i < count; i++) {
>  		ret = m2p_remove_override(pages[i], clear_pte);
>  		if (ret)
>  			return ret;
>  	}
>  
> +	arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89J-0003U9-PX; Tue, 17 Apr 2012 13:08:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SK89I-0003U4-Lb
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 13:08:48 +0000
Received: from [193.109.254.147:20972] by server-1.bemta-14.messagelabs.com id
	9F/30-29372-06B6D8F4; Tue, 17 Apr 2012 13:08:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334668126!4989202!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7938 invoked from network); 17 Apr 2012 13:08:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 13:08:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HD8f4Z019398
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 13:08:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HD8eKm013380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 13:08:40 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HD8dxp018818; Tue, 17 Apr 2012 08:08:40 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 06:08:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A36CE40280; Tue, 17 Apr 2012 09:03:40 -0400 (EDT)
Date: Tue, 17 Apr 2012 09:03:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120417130340.GA25593@phenom.dumpdata.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F8D6B5A.00A8,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> This patch is a significant performance improvement for the
> m2p_override: about 6% using the gntdev device.
> 
> Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> is a great performance benefit because it means issuing one hypercall
> total rather than two hypercall per page.
> If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> going to be batched together, otherwise they are issued one at a time.
> 
> Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> m2p_add/remove_override calls forces paravirt_lazy_mode to
> PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> 
> 
> Changes in v3:
> - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> can be called in interrupt context.

This is with RHEL5 (somehow the pvops kernels don't trigger this):

[  311.247884] xen-blkback:ring-ref 8, event-channel 11, protocol 1 (x86_64-abi)
[  313.200497] ------------[ cut here ]------------
[  313.205166] kernel BUG at /home/konrad/linux/arch/x86/kernel/paravirt.cahci libahci font bitblit ttm libata softcursor scsi_mod drm_kms_helper wmi xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd [last unloaded: dump_dma]
[  313.256453]
[  313.258064] Pid: 3370, comm: run_guests Tainted: G           O 3.4.0-rc3upstream-10947-g331a503 #1 System manufacturer System Product Name/F1A75-M
[  313.271667] RIP: e030:[<ffffffff8105f86e>]  [<ffffffff8105f86e>] paravirt_enter_lazy_mmu+0x1e/0x30
[  313.280977] RSP: e02b:ffff8802014549e0  EFLAGS: 00010202
[  313.286544] RAX: 0000000000000001 RBX: ffff880201454b50 RCX: 0000000000000000
[  313.293971] RDX: 0000000000000001 RSI: ffff880201454a40 RDI: 0000000000000001
[  313.301400] RBP: ffff8802014549e0 R08: ffff880000000000 R09: 0000000000000000
[  313.308829] R10: 0000000000000000 R11: 0000000000000028 R12: 0000000000000001
[  313.316257] R13: 0000000000000000 R14: 0000000000000030 R15: aaaaaaaaaaaaaaab
[  313.323691] FS:  00007fb6cc941700(0000) GS:ffff880201451000(0000) knlGS:0000000000000000
[  313.332101] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  313.338099] CR2: 0000000001d2a1a8 CR3: 00000001e660e000 CR4: 0000000000000660
[  313.345527] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  313.352955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  313.360384] Process run_guests (pid: 3370, threadinfo ffff8801ecece000, task ffff8801f4e91080)
[  313.369334] Stack:
[  313.371482]  ffff880201454a10 ffffffff81310048 0000000000000001 0000000000000001
[  313.379181]  ffff8801e48c74b0 0000000000000030 ffff880201454be0 ffffffff8138d677
[  313.386877]  00000000000004b0 0000160000000000 0000000000000000 ffff880201454a40
[  313.394576] Call Trace:
[  313.397172]  <IRQ>
[  313.399411]  [<ffffffff81310048>] gnttab_unmap_refs+0x38/0x90
[  313.405410]  [<ffffffff8138d677>] xen_blkbk_unmap+0x1f7/0x220
[  313.411406]  [<ffffffff814b165b>] ? tcp_cleanup_rbuf+0x6b/0x100
[  313.417579]  [<ffffffff814b3bfb>] ? tcp_read_sock+0x1bb/0x220
[  313.423578]  [<ffffffffa030fec0>] ? iscsi_sw_tcp_state_change+0xd0/0xd0 [iscsi_tcp]
[  313.431543]  [<ffffffffa03102f3>] ? iscsi_sw_tcp_data_ready+0x73/0xe8 [iscsi_tcp]
[  313.439330]  [<ffffffff814b7ea8>] ? __tcp_ack_snd_check+0x68/0x90
[  313.445686]  [<ffffffff81032fed>] ? xen_force_evtchn_callback+0xd/0x10
[  313.439330]  [<ffffffff814b7ea8>] ? __tcp_ack_snd_check+0x68/0x90
[  313.445686]  [<ffffffff81032fed>] ? xen_force_evtchn_callback+0xd/0x10
[  313.452488]  [<ffffffff81033852>] ? check_events+0x12/0x20
[  313.458216]  [<ffffffff8103383f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  313.465110]  [<ffffffff8113d7f5>] ? kmem_cache_free+0xc5/0x2a0
[  313.471194]  [<ffffffff8138d6e8>] __end_block_io_op+0x48/0x110
[  313.477283]  [<ffffffff8138d7c5>] end_block_io_op+0x15/0x30
[  313.483099]  [<ffffffff81175dc8>] bio_endio+0x18/0x30
[  313.488381]  [<ffffffffa0316239>] dec_pending+0x189/0x290 [dm_mod]
[  313.494824]  [<ffffffffa0316569>] clone_endio+0x99/0xd0 [dm_mod]
[  313.501089]  [<ffffffff81175dc8>] bio_endio+0x18/0x30
[  313.506373]  [<ffffffff81269cf3>] req_bio_endio+0x83/0xc0
[  313.512009]  [<ffffffff8126b217>] blk_update_request+0xe7/0x450
[  313.518186]  [<ffffffff8131d9d1>] ? xen_virt_to_bus+0x11/0x20
[  313.524181]  [<ffffffff8126b5a2>] blk_update_bidi_request+0x22/0xa0
[  313.530715]  [<ffffffff8126b64a>] blk_end_bidi_request+0x2a/0x80
[  313.536981]  [<ffffffff8126b6db>] blk_end_request+0xb/0x10
[  313.542712]  [<ffffffffa005a96a>] scsi_io_completion+0xaa/0x630 [scsi_mod]
[  313.549870]  [<ffffffff815a7c69>] ? _raw_spin_unlock_irqrestore+0x19/0x30
[  313.556942]  [<ffffffffa005290f>] scsi_finish_command+0xcf/0x130 [scsi_mod]
[  313.564193]  [<ffffffffa005b03f>] scsi_softirq_done+0x13f/0x160 [scsi_mod]
[  313.571352]  [<ffffffff8127168d>] blk_done_softirq+0x7d/0x90
[  313.577260]  [<ffffffff810773a9>] __do_softirq+0xa9/0x160
[  313.582899]  [<ffffffff815afc9c>] call_softirq+0x1c/0x30
[  313.588446]  [<ffffffff81039405>] do_softirq+0x65/0xa0
[  313.593819]  [<ffffffff810771a5>] irq_exit+0xd5/0xf0
[  313.599010]  [<ffffffff8131207f>] xen_evtchn_do_upcall+0x2f/0x40
[  313.605273]  [<ffffffff815afcee>] xen_do_hypervisor_callback+0x1e/0x30
[  313.612076]  <EOI>
[  313.614313]  [<ffffffff8111d19e>] ? copy_pte_range+0x36e/0x5f0
[  313.620401]  [<ffffffff8111d6a8>] ? copy_page_range+0x288/0x490
[  313.626576]  [<ffffffff8106e643>] ? dup_mm+0x2d3/0x4a0
[  313.631946]  [<ffffffff8106f710>] ? copy_process+0xf00/0x13e0
[  313.637944]  [<ffffffff8106fe79>] ? do_fork+0x59/0x300
[  313.643314]  [<ffffffff8107e74b>] ? do_sigaction+0x13b/0x1e0
[  313.649221]  [<ffffffff8107f252>] ? __set_task_blocked+0x32/0x80
[  313.655486]  [<ffffffff8107f2f7>] ? set_current_blocked+0x57/0x80
[  313.661842]  [<ffffffff8103fd33>] ? sys_clone+0x23/0x30
[  313.667302]  [<ffffffff815aebc3>] ? stub_clone+0x13/0x20
[  313.672851]  [<ffffffff815ae8b9>] ? system_call_fastpath+0x16/0x1b
[  313.679294] Code: 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 65 8b 04 25 00 e0 00 00 85 c0 48 89 e5 75 0e 65 c7 04 25 00 e0 00 00 01 00 00 00 c9 c3 <0f> 0b eb fe 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 65 48
[  313.698805] RIP  [<ffffffff8105f86e>] paravirt_enter_lazy_mmu+0x1e/0x30
[  313.705698]  RSP <ffff8802014549e0>
[  313.709370] ---[ end trace 6d0134ded298d0e6 ]---
[  313.714201] Kernel panic - not syncing: Fatal exception in interrupt
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/block/xen-blkback/blkback.c |    2 ++
>  drivers/xen/grant-table.c           |    8 ++++++++
>  2 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 0088bf6..0453695 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -386,6 +386,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> +	arch_enter_lazy_mmu_mode();
>  	for (i = 0; i < nseg; i++) {
>  		if (unlikely(map[i].status != 0)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> @@ -410,6 +411,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  		seg[i].buf  = map[i].dev_bus_addr |
>  			(req->u.rw.seg[i].first_sect << 9);
>  	}
> +	arch_leave_lazy_mmu_mode();
>  	return ret;
>  }
>  
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b4d4eac..c7dc2d6 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -751,6 +751,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	arch_enter_lazy_mmu_mode();
> +
>  	for (i = 0; i < count; i++) {
>  		/* Do not add to override if the map failed. */
>  		if (map_ops[i].status)
> @@ -769,6 +771,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  			return ret;
>  	}
>  
> +	arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_map_refs);
> @@ -785,12 +789,16 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	arch_enter_lazy_mmu_mode();
> +
>  	for (i = 0; i < count; i++) {
>  		ret = m2p_remove_override(pages[i], clear_pte);
>  		if (ret)
>  			return ret;
>  	}
>  
> +	arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89O-0003Us-AT; Tue, 17 Apr 2012 13:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89M-0003Ud-S0
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:08:53 +0000
Received: from [85.158.143.99:64157] by server-3.bemta-4.messagelabs.com id
	1B/21-05853-46B6D8F4; Tue, 17 Apr 2012 13:08:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12151 invoked from network); 17 Apr 2012 13:08:50 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:08:50 -0000
Received: by bkcjg9 with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7CMqIJGUansWfIGvqlEUWdpQExavSiADZjRJ5NnxWgw=;
	b=o/hCLCKUgFb+VfbHNMfAGxrdc0NG5PvR8aIE6PLNOrFfRIT3zpVCYwyScT4OTsNBsJ
	h0spzFnHVzqSe5Xs6DqW+7v1NBCySjhmKA2dm8HY2iBq6WKwKdk3dNRE6GzXZssLh/2C
	yF8U5tYFq9tn72jnsSMGAH8z1hyXm6zB/v57h1rSSiytiduzpIvCHVxIn4q/K4wBLRej
	IIYPI2U5Pa5Xe8AdTdOcz+D0PDus/fOaEU4sAkfYmdXs8G9MmNGLzsK81RJThrOiUmNM
	mh0NrkDDVKOxmtZsdTlpUPhQqN+MydKOrNRyHhNgAcFnGpVE+nhXY2U4jii5/GxLTW2X
	pyJQ==
Received: by 10.204.153.12 with SMTP id i12mr4862612bkw.120.1334668129701;
	Tue, 17 Apr 2012 06:08:49 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id hk7sm37925291bkc.2.2012.04.17.06.08.43
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:08:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:08:36 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB329E4.3DFB6%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: fix #GP generation in assembly code
Thread-Index: Ac0cmzK3mHB2e7GEdEuzsgP67x+KYA==
In-Reply-To: <4F8D8216020000780007E79A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: fix #GP generation in assembly code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

> When guest use of sysenter (64-bit PV guest) or syscall (32-bit PV
> guest) gets converted into a GP fault (due to no callback having got
> registered), we must
> - honor the GP fault handler's request the keep enabled or mask event
>   delivery
> - not allow TBF_EXCEPTION to remain set past the generation of the
>   (guest) exception in the vCPU's trap_bounce.flags, as that would
>   otherwise allow for the next exception occurring in guest mode,
>   should it happen to get handled in Xen itself, to nevertheless get
>   bounced to the guest kernel.
> 
> Also, just like compat mode syscall handling already did, native mode
> sysenter handling should, when converting to #GP, subtract 2 from the
> RIP present in the frame so that the guest's GP fault handler would
> see the fault pointing to the offending instruction instead of past it.
> 
> Finally, since those exception generating code blocks needed to be
> modified anyway, convert them to make use of UNLIKELY_{START,END}().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -145,6 +145,7 @@ void __dummy__(void)
>  
>      OFFSET(TRAPINFO_eip, struct trap_info, address);
>      OFFSET(TRAPINFO_cs, struct trap_info, cs);
> +    OFFSET(TRAPINFO_flags, struct trap_info, flags);
>      DEFINE(TRAPINFO_sizeof, sizeof(struct trap_info));
>      BLANK();
>  
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -213,6 +213,7 @@ compat_failsafe_callback:
>  ENTRY(compat_post_handle_exception)
>          testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
>          jz    compat_test_all_events
> +.Lcompat_bounce_exception:
>          call  compat_create_bounce_frame
>          movb  $0,TRAPBOUNCE_flags(%rdx)
>          jmp   compat_test_all_events
> @@ -225,20 +226,21 @@ ENTRY(compat_syscall)
>          leaq  VCPU_trap_bounce(%rbx),%rdx
>          testl $~3,%esi
>          leal  (,%rcx,TBF_INTERRUPT),%ecx
> -        jz    2f
> -1:      movq  %rax,TRAPBOUNCE_eip(%rdx)
> -        movw  %si,TRAPBOUNCE_cs(%rdx)
> -        movb  %cl,TRAPBOUNCE_flags(%rdx)
> -        call  compat_create_bounce_frame
> -        jmp   compat_test_all_events
> -2:      movq  VCPU_trap_ctxt(%rbx),%rsi
> +UNLIKELY_START(z, compat_syscall_gpf)
> +        movq  VCPU_trap_ctxt(%rbx),%rdi
>          movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
>          subl  $2,UREGS_rip(%rsp)
> -        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%eax
> -        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rsi),%esi
> -        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
>          movl  $0,TRAPBOUNCE_error_code(%rdx)
> -        jmp   1b
> +        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax
> +        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi
> +        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)
> +        setnz %cl
> +        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ecx
> +UNLIKELY_END(compat_syscall_gpf)
> +        movq  %rax,TRAPBOUNCE_eip(%rdx)
> +        movw  %si,TRAPBOUNCE_cs(%rdx)
> +        movb  %cl,TRAPBOUNCE_flags(%rdx)
> +        jmp   .Lcompat_bounce_exception
>  
>  ENTRY(compat_sysenter)
>          movq  VCPU_trap_ctxt(%rbx),%rcx
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -277,20 +277,22 @@ sysenter_eflags_saved:
>          leaq  VCPU_trap_bounce(%rbx),%rdx
>          testq %rax,%rax
>          leal  (,%rcx,TBF_INTERRUPT),%ecx
> -        jz    2f
> -1:      movq  VCPU_domain(%rbx),%rdi
> +UNLIKELY_START(z, sysenter_gpf)
> +        movq  VCPU_trap_ctxt(%rbx),%rsi
> +        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
> +        subl  $2,UREGS_rip(%rsp)
> +        movl  %eax,TRAPBOUNCE_error_code(%rdx)
> +        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
> +        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)
> +        setnz %cl
> +        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ecx
> +UNLIKELY_END(sysenter_gpf)
> +        movq  VCPU_domain(%rbx),%rdi
>          movq  %rax,TRAPBOUNCE_eip(%rdx)
>          movb  %cl,TRAPBOUNCE_flags(%rdx)
>          testb $1,DOMAIN_is_32bit_pv(%rdi)
>          jnz   compat_sysenter
> -        call  create_bounce_frame
> -        jmp   test_all_events
> -2:      movq  VCPU_trap_ctxt(%rbx),%rcx
> -        movl  %eax,TRAPBOUNCE_error_code(%rdx)
> -        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%rax
> -        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
> -        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
> -        jmp   1b
> +        jmp   .Lbounce_exception
>  
>  ENTRY(int80_direct_trap)
>          pushq $0
> @@ -483,6 +485,7 @@ handle_exception_saved:
>          jnz   compat_post_handle_exception
>          testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
>          jz    test_all_events
> +.Lbounce_exception:
>          call  create_bounce_frame
>          movb  $0,TRAPBOUNCE_flags(%rdx)
>          jmp   test_all_events
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89O-0003Us-AT; Tue, 17 Apr 2012 13:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89M-0003Ud-S0
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:08:53 +0000
Received: from [85.158.143.99:64157] by server-3.bemta-4.messagelabs.com id
	1B/21-05853-46B6D8F4; Tue, 17 Apr 2012 13:08:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12151 invoked from network); 17 Apr 2012 13:08:50 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:08:50 -0000
Received: by bkcjg9 with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7CMqIJGUansWfIGvqlEUWdpQExavSiADZjRJ5NnxWgw=;
	b=o/hCLCKUgFb+VfbHNMfAGxrdc0NG5PvR8aIE6PLNOrFfRIT3zpVCYwyScT4OTsNBsJ
	h0spzFnHVzqSe5Xs6DqW+7v1NBCySjhmKA2dm8HY2iBq6WKwKdk3dNRE6GzXZssLh/2C
	yF8U5tYFq9tn72jnsSMGAH8z1hyXm6zB/v57h1rSSiytiduzpIvCHVxIn4q/K4wBLRej
	IIYPI2U5Pa5Xe8AdTdOcz+D0PDus/fOaEU4sAkfYmdXs8G9MmNGLzsK81RJThrOiUmNM
	mh0NrkDDVKOxmtZsdTlpUPhQqN+MydKOrNRyHhNgAcFnGpVE+nhXY2U4jii5/GxLTW2X
	pyJQ==
Received: by 10.204.153.12 with SMTP id i12mr4862612bkw.120.1334668129701;
	Tue, 17 Apr 2012 06:08:49 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id hk7sm37925291bkc.2.2012.04.17.06.08.43
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:08:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:08:36 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB329E4.3DFB6%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: fix #GP generation in assembly code
Thread-Index: Ac0cmzK3mHB2e7GEdEuzsgP67x+KYA==
In-Reply-To: <4F8D8216020000780007E79A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: fix #GP generation in assembly code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

> When guest use of sysenter (64-bit PV guest) or syscall (32-bit PV
> guest) gets converted into a GP fault (due to no callback having got
> registered), we must
> - honor the GP fault handler's request the keep enabled or mask event
>   delivery
> - not allow TBF_EXCEPTION to remain set past the generation of the
>   (guest) exception in the vCPU's trap_bounce.flags, as that would
>   otherwise allow for the next exception occurring in guest mode,
>   should it happen to get handled in Xen itself, to nevertheless get
>   bounced to the guest kernel.
> 
> Also, just like compat mode syscall handling already did, native mode
> sysenter handling should, when converting to #GP, subtract 2 from the
> RIP present in the frame so that the guest's GP fault handler would
> see the fault pointing to the offending instruction instead of past it.
> 
> Finally, since those exception generating code blocks needed to be
> modified anyway, convert them to make use of UNLIKELY_{START,END}().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -145,6 +145,7 @@ void __dummy__(void)
>  
>      OFFSET(TRAPINFO_eip, struct trap_info, address);
>      OFFSET(TRAPINFO_cs, struct trap_info, cs);
> +    OFFSET(TRAPINFO_flags, struct trap_info, flags);
>      DEFINE(TRAPINFO_sizeof, sizeof(struct trap_info));
>      BLANK();
>  
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -213,6 +213,7 @@ compat_failsafe_callback:
>  ENTRY(compat_post_handle_exception)
>          testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
>          jz    compat_test_all_events
> +.Lcompat_bounce_exception:
>          call  compat_create_bounce_frame
>          movb  $0,TRAPBOUNCE_flags(%rdx)
>          jmp   compat_test_all_events
> @@ -225,20 +226,21 @@ ENTRY(compat_syscall)
>          leaq  VCPU_trap_bounce(%rbx),%rdx
>          testl $~3,%esi
>          leal  (,%rcx,TBF_INTERRUPT),%ecx
> -        jz    2f
> -1:      movq  %rax,TRAPBOUNCE_eip(%rdx)
> -        movw  %si,TRAPBOUNCE_cs(%rdx)
> -        movb  %cl,TRAPBOUNCE_flags(%rdx)
> -        call  compat_create_bounce_frame
> -        jmp   compat_test_all_events
> -2:      movq  VCPU_trap_ctxt(%rbx),%rsi
> +UNLIKELY_START(z, compat_syscall_gpf)
> +        movq  VCPU_trap_ctxt(%rbx),%rdi
>          movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
>          subl  $2,UREGS_rip(%rsp)
> -        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%eax
> -        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rsi),%esi
> -        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
>          movl  $0,TRAPBOUNCE_error_code(%rdx)
> -        jmp   1b
> +        movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax
> +        movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi
> +        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)
> +        setnz %cl
> +        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ecx
> +UNLIKELY_END(compat_syscall_gpf)
> +        movq  %rax,TRAPBOUNCE_eip(%rdx)
> +        movw  %si,TRAPBOUNCE_cs(%rdx)
> +        movb  %cl,TRAPBOUNCE_flags(%rdx)
> +        jmp   .Lcompat_bounce_exception
>  
>  ENTRY(compat_sysenter)
>          movq  VCPU_trap_ctxt(%rbx),%rcx
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -277,20 +277,22 @@ sysenter_eflags_saved:
>          leaq  VCPU_trap_bounce(%rbx),%rdx
>          testq %rax,%rax
>          leal  (,%rcx,TBF_INTERRUPT),%ecx
> -        jz    2f
> -1:      movq  VCPU_domain(%rbx),%rdi
> +UNLIKELY_START(z, sysenter_gpf)
> +        movq  VCPU_trap_ctxt(%rbx),%rsi
> +        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
> +        subl  $2,UREGS_rip(%rsp)
> +        movl  %eax,TRAPBOUNCE_error_code(%rdx)
> +        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
> +        testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)
> +        setnz %cl
> +        leal  TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ecx
> +UNLIKELY_END(sysenter_gpf)
> +        movq  VCPU_domain(%rbx),%rdi
>          movq  %rax,TRAPBOUNCE_eip(%rdx)
>          movb  %cl,TRAPBOUNCE_flags(%rdx)
>          testb $1,DOMAIN_is_32bit_pv(%rdi)
>          jnz   compat_sysenter
> -        call  create_bounce_frame
> -        jmp   test_all_events
> -2:      movq  VCPU_trap_ctxt(%rbx),%rcx
> -        movl  %eax,TRAPBOUNCE_error_code(%rdx)
> -        movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%rax
> -        movb  $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl
> -        movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
> -        jmp   1b
> +        jmp   .Lbounce_exception
>  
>  ENTRY(int80_direct_trap)
>          pushq $0
> @@ -483,6 +485,7 @@ handle_exception_saved:
>          jnz   compat_post_handle_exception
>          testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
>          jz    test_all_events
> +.Lbounce_exception:
>          call  create_bounce_frame
>          movb  $0,TRAPBOUNCE_flags(%rdx)
>          jmp   test_all_events
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89U-0003Ve-VY; Tue, 17 Apr 2012 13:09:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89T-0003VP-OR
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:09:00 +0000
Received: from [85.158.143.99:64771] by server-3.bemta-4.messagelabs.com id
	8E/51-05853-B6B6D8F4; Tue, 17 Apr 2012 13:08:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!2
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12714 invoked from network); 17 Apr 2012 13:08:58 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:08:58 -0000
Received: by mail-bk0-f45.google.com with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:08:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YJn8Ev5YTQxti/4TOmV4/Snh/VlPrEh8AtTzsiKXLDI=;
	b=BXXGRFnxvoDUKcVQmGp+0qAEK+lkHZyZ4HTDkIv3BO6FupYMc8TsorpqYPlLnzVn2Z
	97H+i94I0h5BC62GNuy8VBUcKpUCedykBZA3EZH2SboohmYcPH/1/1J1Jk5zz4SkcyYT
	rq1rxZnV6rsD5A78NSLcapo44sljJwImWbPliRQepqxXh1D9L9Y/kqIfU1ylyxIdQ+6u
	HCfXktyVIpDkHltmLgWGgd51tRrqxur9+MQbgjn2tv+je0yVH7swIdFlTZnP9Qj21SG3
	dMsl/plczPh2PszqAsOUBdlGEXR4UG1G94qh/cnXyE3uHkZbpTPinzG+TnWK7G8jFmNH
	p/RA==
Received: by 10.204.154.201 with SMTP id p9mr4854916bkw.125.1334668137426;
	Tue, 17 Apr 2012 06:08:57 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id hk7sm37925291bkc.2.2012.04.17.06.08.52
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:08:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:08:50 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB329F2.3DFB7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/ioapic: Add register level checks to
	detect bogus io-apic entries
Thread-Index: Ac0cmzsPaBBSrX44rk2LnVC7sMX0wA==
In-Reply-To: <4F8D82FC020000780007E7BE@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/ioapic: Add register level checks to
 detect bogus io-apic entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> With the recent changes to clear_IO_APIC_pin() which tries to
> clear remoteIRR bit explicitly, some of the users started to see
> "Unable to reset IRR for apic .." messages.
> 
> Close look shows that these are related to bogus IO-APIC entries
> which returns all 1s for their io-apic registers. And the
> above mentioned error messages are benign. But kernel should
> have ignored such io-apic's in the first place.
> 
> Check if register 0, 1, 2 of the listed io-apic are all 1s and
> ignore such io-apic.
> 
> [original Linux patch:]
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -185,7 +185,7 @@ struct IO_APIC_route_entry **alloc_ioapi
>          ioapic_entries[apic] =
>              xmalloc_array(struct IO_APIC_route_entry,
>                            nr_ioapic_entries[apic]);
> -        if (!ioapic_entries[apic])
> +        if (!ioapic_entries[apic] && nr_ioapic_entries[apic])
>              goto nomem;
>      }
>  
> @@ -310,6 +310,9 @@ int save_IO_APIC_setup(struct IO_APIC_ro
>          return -ENOMEM;
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
> +
>          if (!ioapic_entries[apic])
>              return -ENOMEM;
>  
> @@ -331,6 +334,9 @@ void mask_IO_APIC_setup(struct IO_APIC_r
>          return;
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
> +
>          if (!ioapic_entries[apic])
>              break;
>  
> @@ -358,6 +364,9 @@ int restore_IO_APIC_setup(struct IO_APIC
>          return -ENOMEM;
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
> +
>          if (!ioapic_entries[apic])
>              return -ENOMEM;
>  
> @@ -610,6 +619,8 @@ static int __init find_isa_irq_apic(int
>      if (i < mp_irq_entries) {
>          int apic;
>          for(apic = 0; apic < nr_ioapics; apic++) {
> +            if (!nr_ioapic_entries[apic])
> +                continue;
>              if (mp_ioapics[apic].mpc_apicid == mp_irqs[i].mpc_dstapic)
>                  return apic;
>          }
> @@ -1080,6 +1091,8 @@ static void /*__init*/ __print_IO_APIC(v
>      printk(KERN_INFO "testing the IO APIC.......................\n");
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
>  
> spin_lock_irqsave(&ioapic_lock, flags);
> reg_00.raw = io_apic_read(apic, 0);
> @@ -1229,6 +1242,8 @@ static void __init enable_IO_APIC(void)
>  
>      if (directed_eoi_enabled) {
>          for (apic = 0; apic < nr_ioapics; apic++) {
> +            if (!nr_ioapic_entries[apic])
> +                continue;
>              vector_map[apic] = xzalloc(vmask_t);
>              BUG_ON(!vector_map[apic]);
>          }
> @@ -1354,6 +1369,8 @@ static void __init setup_ioapic_ids_from
>       * Set the IOAPIC ID to the value stored in the MPC table.
>       */
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
>  
>          /* Read the register 0 value */
>          spin_lock_irqsave(&ioapic_lock, flags);
> @@ -2038,6 +2055,8 @@ void ioapic_resume(void)
>  
>      spin_lock_irqsave(&ioapic_lock, flags);
>      for (apic = 0; apic < nr_ioapics; apic++){
> +        if (!nr_ioapic_entries[apic])
> +            continue;
>          reg_00.raw = __io_apic_read(apic, 0);
>          if (reg_00.bits.ID != mp_ioapics[apic].mpc_apicid) {
>              reg_00.bits.ID = mp_ioapics[apic].mpc_apicid;
> @@ -2225,8 +2244,12 @@ static int ioapic_physbase_to_id(unsigne
>  {
>      int apic;
>      for ( apic = 0; apic < nr_ioapics; apic++ )
> +    {
> +        if ( !nr_ioapic_entries[apic] )
> +            continue;
>          if ( mp_ioapics[apic].mpc_apicaddr == physbase )
>              return apic;
> +    }
>      return -EINVAL;
>  }
>  
> @@ -2444,6 +2467,22 @@ void dump_ioapic_irq_info(void)
>  static unsigned int __initdata max_gsi_irqs;
>  integer_param("max_gsi_irqs", max_gsi_irqs);
>  
> +static __init bool_t bad_ioapic_register(unsigned int idx)
> +{
> +    union IO_APIC_reg_00 reg_00 = { .raw = io_apic_read(idx, 0) };
> +    union IO_APIC_reg_01 reg_01 = { .raw = io_apic_read(idx, 1) };
> +    union IO_APIC_reg_02 reg_02 = { .raw = io_apic_read(idx, 2) };
> +
> +    if ( reg_00.raw == -1 && reg_01.raw == -1 && reg_02.raw == -1 )
> +    {
> +        printk(KERN_WARNING "I/O APIC %#x registers return all ones,
> skipping!\n",
> +               mp_ioapics[idx].mpc_apicaddr);
> +        return 1;
> +    }
> +
> +    return 0;
> +}
> +
>  void __init init_ioapic_mappings(void)
>  {
>      unsigned long ioapic_phys;
> @@ -2477,6 +2516,12 @@ void __init init_ioapic_mappings(void)
>                      __fix_to_virt(idx), ioapic_phys);
>          idx++;
>  
> +        if ( bad_ioapic_register(i) )
> +        {
> +            __set_fixmap(idx, 0, 0);
> +            continue;
> +        }
> +
>          if ( smp_found_config )
>          {
>              /* The number of IO-APIC IRQ registers (== #pins): */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89U-0003Ve-VY; Tue, 17 Apr 2012 13:09:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89T-0003VP-OR
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:09:00 +0000
Received: from [85.158.143.99:64771] by server-3.bemta-4.messagelabs.com id
	8E/51-05853-B6B6D8F4; Tue, 17 Apr 2012 13:08:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!2
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12714 invoked from network); 17 Apr 2012 13:08:58 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:08:58 -0000
Received: by mail-bk0-f45.google.com with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:08:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YJn8Ev5YTQxti/4TOmV4/Snh/VlPrEh8AtTzsiKXLDI=;
	b=BXXGRFnxvoDUKcVQmGp+0qAEK+lkHZyZ4HTDkIv3BO6FupYMc8TsorpqYPlLnzVn2Z
	97H+i94I0h5BC62GNuy8VBUcKpUCedykBZA3EZH2SboohmYcPH/1/1J1Jk5zz4SkcyYT
	rq1rxZnV6rsD5A78NSLcapo44sljJwImWbPliRQepqxXh1D9L9Y/kqIfU1ylyxIdQ+6u
	HCfXktyVIpDkHltmLgWGgd51tRrqxur9+MQbgjn2tv+je0yVH7swIdFlTZnP9Qj21SG3
	dMsl/plczPh2PszqAsOUBdlGEXR4UG1G94qh/cnXyE3uHkZbpTPinzG+TnWK7G8jFmNH
	p/RA==
Received: by 10.204.154.201 with SMTP id p9mr4854916bkw.125.1334668137426;
	Tue, 17 Apr 2012 06:08:57 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id hk7sm37925291bkc.2.2012.04.17.06.08.52
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:08:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:08:50 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB329F2.3DFB7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/ioapic: Add register level checks to
	detect bogus io-apic entries
Thread-Index: Ac0cmzsPaBBSrX44rk2LnVC7sMX0wA==
In-Reply-To: <4F8D82FC020000780007E7BE@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/ioapic: Add register level checks to
 detect bogus io-apic entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> With the recent changes to clear_IO_APIC_pin() which tries to
> clear remoteIRR bit explicitly, some of the users started to see
> "Unable to reset IRR for apic .." messages.
> 
> Close look shows that these are related to bogus IO-APIC entries
> which returns all 1s for their io-apic registers. And the
> above mentioned error messages are benign. But kernel should
> have ignored such io-apic's in the first place.
> 
> Check if register 0, 1, 2 of the listed io-apic are all 1s and
> ignore such io-apic.
> 
> [original Linux patch:]
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -185,7 +185,7 @@ struct IO_APIC_route_entry **alloc_ioapi
>          ioapic_entries[apic] =
>              xmalloc_array(struct IO_APIC_route_entry,
>                            nr_ioapic_entries[apic]);
> -        if (!ioapic_entries[apic])
> +        if (!ioapic_entries[apic] && nr_ioapic_entries[apic])
>              goto nomem;
>      }
>  
> @@ -310,6 +310,9 @@ int save_IO_APIC_setup(struct IO_APIC_ro
>          return -ENOMEM;
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
> +
>          if (!ioapic_entries[apic])
>              return -ENOMEM;
>  
> @@ -331,6 +334,9 @@ void mask_IO_APIC_setup(struct IO_APIC_r
>          return;
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
> +
>          if (!ioapic_entries[apic])
>              break;
>  
> @@ -358,6 +364,9 @@ int restore_IO_APIC_setup(struct IO_APIC
>          return -ENOMEM;
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
> +
>          if (!ioapic_entries[apic])
>              return -ENOMEM;
>  
> @@ -610,6 +619,8 @@ static int __init find_isa_irq_apic(int
>      if (i < mp_irq_entries) {
>          int apic;
>          for(apic = 0; apic < nr_ioapics; apic++) {
> +            if (!nr_ioapic_entries[apic])
> +                continue;
>              if (mp_ioapics[apic].mpc_apicid == mp_irqs[i].mpc_dstapic)
>                  return apic;
>          }
> @@ -1080,6 +1091,8 @@ static void /*__init*/ __print_IO_APIC(v
>      printk(KERN_INFO "testing the IO APIC.......................\n");
>  
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
>  
> spin_lock_irqsave(&ioapic_lock, flags);
> reg_00.raw = io_apic_read(apic, 0);
> @@ -1229,6 +1242,8 @@ static void __init enable_IO_APIC(void)
>  
>      if (directed_eoi_enabled) {
>          for (apic = 0; apic < nr_ioapics; apic++) {
> +            if (!nr_ioapic_entries[apic])
> +                continue;
>              vector_map[apic] = xzalloc(vmask_t);
>              BUG_ON(!vector_map[apic]);
>          }
> @@ -1354,6 +1369,8 @@ static void __init setup_ioapic_ids_from
>       * Set the IOAPIC ID to the value stored in the MPC table.
>       */
>      for (apic = 0; apic < nr_ioapics; apic++) {
> +        if (!nr_ioapic_entries[apic])
> +            continue;
>  
>          /* Read the register 0 value */
>          spin_lock_irqsave(&ioapic_lock, flags);
> @@ -2038,6 +2055,8 @@ void ioapic_resume(void)
>  
>      spin_lock_irqsave(&ioapic_lock, flags);
>      for (apic = 0; apic < nr_ioapics; apic++){
> +        if (!nr_ioapic_entries[apic])
> +            continue;
>          reg_00.raw = __io_apic_read(apic, 0);
>          if (reg_00.bits.ID != mp_ioapics[apic].mpc_apicid) {
>              reg_00.bits.ID = mp_ioapics[apic].mpc_apicid;
> @@ -2225,8 +2244,12 @@ static int ioapic_physbase_to_id(unsigne
>  {
>      int apic;
>      for ( apic = 0; apic < nr_ioapics; apic++ )
> +    {
> +        if ( !nr_ioapic_entries[apic] )
> +            continue;
>          if ( mp_ioapics[apic].mpc_apicaddr == physbase )
>              return apic;
> +    }
>      return -EINVAL;
>  }
>  
> @@ -2444,6 +2467,22 @@ void dump_ioapic_irq_info(void)
>  static unsigned int __initdata max_gsi_irqs;
>  integer_param("max_gsi_irqs", max_gsi_irqs);
>  
> +static __init bool_t bad_ioapic_register(unsigned int idx)
> +{
> +    union IO_APIC_reg_00 reg_00 = { .raw = io_apic_read(idx, 0) };
> +    union IO_APIC_reg_01 reg_01 = { .raw = io_apic_read(idx, 1) };
> +    union IO_APIC_reg_02 reg_02 = { .raw = io_apic_read(idx, 2) };
> +
> +    if ( reg_00.raw == -1 && reg_01.raw == -1 && reg_02.raw == -1 )
> +    {
> +        printk(KERN_WARNING "I/O APIC %#x registers return all ones,
> skipping!\n",
> +               mp_ioapics[idx].mpc_apicaddr);
> +        return 1;
> +    }
> +
> +    return 0;
> +}
> +
>  void __init init_ioapic_mappings(void)
>  {
>      unsigned long ioapic_phys;
> @@ -2477,6 +2516,12 @@ void __init init_ioapic_mappings(void)
>                      __fix_to_virt(idx), ioapic_phys);
>          idx++;
>  
> +        if ( bad_ioapic_register(i) )
> +        {
> +            __set_fixmap(idx, 0, 0);
> +            continue;
> +        }
> +
>          if ( smp_found_config )
>          {
>              /* The number of IO-APIC IRQ registers (== #pins): */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89p-0003aA-CH; Tue, 17 Apr 2012 13:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89n-0003Zc-RM
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:09:20 +0000
Received: from [85.158.143.99:7028] by server-2.bemta-4.messagelabs.com id
	6A/45-17550-F7B6D8F4; Tue, 17 Apr 2012 13:09:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!3
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14668 invoked from network); 17 Apr 2012 13:09:18 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:09:18 -0000
Received: by mail-bk0-f45.google.com with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DM8afz4f905nGASw+/MG7RD+UAk4qKaBQ5dF5g/bLg8=;
	b=phUeL5KBh8JyVGwkYf5L55KFQfkH2uMcKMBUWv2VAyh3yvXCv0LEJxpVp+yuGdd1T+
	BW0196H58AFS6zqPkm/v3/JQvrNKG+71U3Cf66jjc17yGDfvVAoF+BCGwNbIjNCie1/w
	1TCFS4UPXYRR4c+1eZ5OOw0c9hWBAsjcfsyenhgiRre/coLSakoA+8Cxdu3Qo+hEZSF1
	xT4DfHaEnqzUdZGsLkRVSDnCE86bpmAybDOupZvFNp9MvVCkdoGc8ek0poJlddFb+wpE
	ucfSyVGEIw7My4UXZ8wJIKR83pHuvIWdZO5vK7xUej1AZdqwlVVW7zfkLwozbS1tv7Eu
	nV/Q==
Received: by 10.205.131.3 with SMTP id ho3mr4714148bkc.48.1334668158458;
	Tue, 17 Apr 2012 06:09:18 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id f5sm37878572bke.9.2012.04.17.06.09.12
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:09:18 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:09:02 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB329FE.3DFB8%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/IO-APIC: adjust an otherwise pretty
	useless message
Thread-Index: Ac0cm0I22w7rFxnYsU+ayPv2NlHkZg==
In-Reply-To: <4F8D8365020000780007E7C2@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: adjust an otherwise pretty
 useless message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:51, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2164,8 +2164,8 @@ int io_apic_set_pci_routing (int ioapic,
>      int vector;
>  
>      if (!IO_APIC_IRQ(irq)) {
> -        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ 0\n",
> -               ioapic);
> +        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ %d\n",
> +               ioapic, irq);
>          return -EINVAL;
>      }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89p-0003aA-CH; Tue, 17 Apr 2012 13:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89n-0003Zc-RM
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:09:20 +0000
Received: from [85.158.143.99:7028] by server-2.bemta-4.messagelabs.com id
	6A/45-17550-F7B6D8F4; Tue, 17 Apr 2012 13:09:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!3
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14668 invoked from network); 17 Apr 2012 13:09:18 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:09:18 -0000
Received: by mail-bk0-f45.google.com with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DM8afz4f905nGASw+/MG7RD+UAk4qKaBQ5dF5g/bLg8=;
	b=phUeL5KBh8JyVGwkYf5L55KFQfkH2uMcKMBUWv2VAyh3yvXCv0LEJxpVp+yuGdd1T+
	BW0196H58AFS6zqPkm/v3/JQvrNKG+71U3Cf66jjc17yGDfvVAoF+BCGwNbIjNCie1/w
	1TCFS4UPXYRR4c+1eZ5OOw0c9hWBAsjcfsyenhgiRre/coLSakoA+8Cxdu3Qo+hEZSF1
	xT4DfHaEnqzUdZGsLkRVSDnCE86bpmAybDOupZvFNp9MvVCkdoGc8ek0poJlddFb+wpE
	ucfSyVGEIw7My4UXZ8wJIKR83pHuvIWdZO5vK7xUej1AZdqwlVVW7zfkLwozbS1tv7Eu
	nV/Q==
Received: by 10.205.131.3 with SMTP id ho3mr4714148bkc.48.1334668158458;
	Tue, 17 Apr 2012 06:09:18 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id f5sm37878572bke.9.2012.04.17.06.09.12
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:09:18 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:09:02 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB329FE.3DFB8%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/IO-APIC: adjust an otherwise pretty
	useless message
Thread-Index: Ac0cm0I22w7rFxnYsU+ayPv2NlHkZg==
In-Reply-To: <4F8D8365020000780007E7C2@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: adjust an otherwise pretty
 useless message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:51, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2164,8 +2164,8 @@ int io_apic_set_pci_routing (int ioapic,
>      int vector;
>  
>      if (!IO_APIC_IRQ(irq)) {
> -        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ 0\n",
> -               ioapic);
> +        printk(KERN_ERR "IOAPIC[%d]: Invalid reference to IRQ %d\n",
> +               ioapic, irq);
>          return -EINVAL;
>      }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89p-0003aP-PT; Tue, 17 Apr 2012 13:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89p-0003Zx-3g
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:09:21 +0000
Received: from [85.158.143.99:7119] by server-3.bemta-4.messagelabs.com id
	0E/12-05853-08B6D8F4; Tue, 17 Apr 2012 13:09:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!4
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14790 invoked from network); 17 Apr 2012 13:09:19 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:09:19 -0000
Received: by mail-bk0-f45.google.com with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=X6gkyj6Td9DR4vE0ibTOBCOxcwnjE4bMaOwV4KThppY=;
	b=He0+eJn+uY+Rn/4GyeS2oRS3cbjtuhskVnIS/QDzHLUvG0a18OtNhEhaz6IULGU3ND
	tlfuID81meKhyyECdNKItcuUIxzkITmSNkaomqdQbobhhkxtwdNwLdkKh0Tuf2ei33ng
	Up/cJVuKraUDORzTDuES1I9cjkYMuKuDRUxmoEpQbgHDuKHNof0NECdsEWsjfJp5YiDV
	A9FINOeOwxjtxoHoRyWCJpTzy8IQlbFtvcEh2rU8k92L3ZRvPvY+hDV9dATU/Wot68tu
	U6ktVHXPkrWq4CH8IgwVqjPla2kMAkyiFNjKf3/zzaTFAYy6ZxkhKD5nqVkbaYKXMJXu
	TVZg==
Received: by 10.204.154.201 with SMTP id p9mr4855319bkw.125.1334668159591;
	Tue, 17 Apr 2012 06:09:19 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id f5sm37878572bke.9.2012.04.17.06.09.18
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:09:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:09:16 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB32A0C.3DFB9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: suppress warning messages on
	IO-APIC-less systems
Thread-Index: Ac0cm0qOhf4jrvapB0SUcp0mzTx/MA==
In-Reply-To: <4F8D851B020000780007E7E6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: suppress warning messages on
 IO-APIC-less systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> Each call to mp_register_gsi() so far produced two warnings (about not
> being able to find the corresponding IO-APIC pin).
> 
> However, we should use the provided information for setting the ELCR
> correctly (we might want to even do this when there is an IO-APIC, if
> was absolutely certain that all machines really have this register
> [and specifically not some other device at the two I/O ports in
> question]). It is in any case questionable that we allow Dom0 to set
> this register - it could particularly be the interrupt of a plug-in
> serial port card that might not work due to this. The problem is that
> all Dom0 kernels to date do so, hence we can't simply #GP on such an
> access (which would be the result if we disallowed access to the port
> as we should have done from the beginning).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -1034,6 +1034,21 @@ int mp_register_gsi (u32 gsi, int trigge
> return gsi;
>  #endif
>  
> + if (!nr_ioapics) {
> +  unsigned int port = 0x4d0 + (gsi >> 3);
> +  u8 val;
> +
> +  if (!platform_legacy_irq(gsi))
> +   return -EINVAL;
> +  val = inb(port);
> +  if (triggering)
> +   val |= 1 << (gsi & 7);
> +  else
> +   val &= ~(1 << (gsi & 7));
> +  outb(val, port);
> +  return 0;
> + }
> +
> ioapic = mp_find_ioapic(gsi);
> if (ioapic < 0) {
> printk(KERN_WARNING "No IOAPIC for GSI %u\n", gsi);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:09:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK89p-0003aP-PT; Tue, 17 Apr 2012 13:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK89p-0003Zx-3g
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:09:21 +0000
Received: from [85.158.143.99:7119] by server-3.bemta-4.messagelabs.com id
	0E/12-05853-08B6D8F4; Tue, 17 Apr 2012 13:09:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334668130!25461937!4
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14790 invoked from network); 17 Apr 2012 13:09:19 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:09:19 -0000
Received: by mail-bk0-f45.google.com with SMTP id jg9so5715637bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 06:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=X6gkyj6Td9DR4vE0ibTOBCOxcwnjE4bMaOwV4KThppY=;
	b=He0+eJn+uY+Rn/4GyeS2oRS3cbjtuhskVnIS/QDzHLUvG0a18OtNhEhaz6IULGU3ND
	tlfuID81meKhyyECdNKItcuUIxzkITmSNkaomqdQbobhhkxtwdNwLdkKh0Tuf2ei33ng
	Up/cJVuKraUDORzTDuES1I9cjkYMuKuDRUxmoEpQbgHDuKHNof0NECdsEWsjfJp5YiDV
	A9FINOeOwxjtxoHoRyWCJpTzy8IQlbFtvcEh2rU8k92L3ZRvPvY+hDV9dATU/Wot68tu
	U6ktVHXPkrWq4CH8IgwVqjPla2kMAkyiFNjKf3/zzaTFAYy6ZxkhKD5nqVkbaYKXMJXu
	TVZg==
Received: by 10.204.154.201 with SMTP id p9mr4855319bkw.125.1334668159591;
	Tue, 17 Apr 2012 06:09:19 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id f5sm37878572bke.9.2012.04.17.06.09.18
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:09:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 14:09:16 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB32A0C.3DFB9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: suppress warning messages on
	IO-APIC-less systems
Thread-Index: Ac0cm0qOhf4jrvapB0SUcp0mzTx/MA==
In-Reply-To: <4F8D851B020000780007E7E6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: suppress warning messages on
 IO-APIC-less systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 13:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> Each call to mp_register_gsi() so far produced two warnings (about not
> being able to find the corresponding IO-APIC pin).
> 
> However, we should use the provided information for setting the ELCR
> correctly (we might want to even do this when there is an IO-APIC, if
> was absolutely certain that all machines really have this register
> [and specifically not some other device at the two I/O ports in
> question]). It is in any case questionable that we allow Dom0 to set
> this register - it could particularly be the interrupt of a plug-in
> serial port card that might not work due to this. The problem is that
> all Dom0 kernels to date do so, hence we can't simply #GP on such an
> access (which would be the result if we disallowed access to the port
> as we should have done from the beginning).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -1034,6 +1034,21 @@ int mp_register_gsi (u32 gsi, int trigge
> return gsi;
>  #endif
>  
> + if (!nr_ioapics) {
> +  unsigned int port = 0x4d0 + (gsi >> 3);
> +  u8 val;
> +
> +  if (!platform_legacy_irq(gsi))
> +   return -EINVAL;
> +  val = inb(port);
> +  if (triggering)
> +   val |= 1 << (gsi & 7);
> +  else
> +   val &= ~(1 << (gsi & 7));
> +  outb(val, port);
> +  return 0;
> + }
> +
> ioapic = mp_find_ioapic(gsi);
> if (ioapic < 0) {
> printk(KERN_WARNING "No IOAPIC for GSI %u\n", gsi);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:10:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:10:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8Aj-0003mH-8n; Tue, 17 Apr 2012 13:10:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK8Ai-0003m0-AI
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:10:16 +0000
Received: from [85.158.139.83:52892] by server-1.bemta-5.messagelabs.com id
	D7/9A-28458-7BB6D8F4; Tue, 17 Apr 2012 13:10:15 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334668210!20320260!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 17 Apr 2012 13:10:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:10:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190704173"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:08:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 09:08:02 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK88Y-0003pD-0q;
	Tue, 17 Apr 2012 14:08:02 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334658395.23948.6.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 14:08:02 +0100
Message-ID: <0BD309F0-D2F1-45D5-899B-F0242D13A569@citrix.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 11:26, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 20:03 +0100, M A Young wrote:
>> There is a Fedora bug report =

>> https://bugzilla.redhat.com/show_bug.cgi?id=3D812421 reporting that open=
vpn =

>> is having problems because of the line
>> SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", RUN+=3D"/et=
c/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
>> in /etc/udev/rules.d/xen-backend.rules which is causing the xen script t=
o =

>> run when openvpn tries to use a tap device, causing it to fail. I have =

>> used the attached patch to solve this problem, by matching the form of t=
he =

>> tap device that xen uses more exactly to avoid to openvpn case. A better =

>> long-term solution (suggested in one of the comments in the bug) might b=
e =

>> to use a more specific name instead of "tap" so we have less chance of =

>> interfering with another application.
> =

> This is a good start, I think we should do this for 4.2.
> =

> Changing the name might be pretty simple though e.g. the following.
> Works for me with xl but I didn't try xend (seems "obviously correct"?)
> =

> I noticed that when vifname is set xend prepends "tap-" (presumably to
> distinguish it from the vif device) whereas libxl does not, so I suspect
> named vifs for HVM guests don't work so well, I fixed that while I was
> there...
> =

> Also at least for the libxl case we will likely not be running these
> hotplug scripts via udev any more in 4.2, however I don't think there is
> any harm in making this change first (iff we decide it is suitable for
> 4.2).
> =

> Ian.
> =

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1334658366 -3600
> # Node ID de3e65d804cceab7291e2accc18d50ae8b816433
> # Parent  8d92d1f34921c8675d85c74aa36e319c9451f68f
> libxl/xend: name tap devices with a xentap prefix
> =

> This prevents the udev scripts from operating on other tap devices (e.g.
> openvpn etc)
> =

> Also add "xentap-" prefix to the tap device when an explicit name is give=
n to
> avoid a conflict with the vif device, which would otherwise have the same=
 name.
> Likewise correct the documentation for this option which suggested it app=
lied
> to HVM tap devices only.
> =

> Reported by Michael Young.
> =

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Roger Pau Monne <roger.pau@citrix.com>

I've already changed my hotplug series to match this change in the udev rul=
es, so this has to go in before mine.

> =

> diff -r 8d92d1f34921 -r de3e65d804cc docs/misc/xl-network-configuration.m=
arkdown
> --- a/docs/misc/xl-network-configuration.markdown	Mon Apr 16 17:57:00 201=
2 +0100
> +++ b/docs/misc/xl-network-configuration.markdown	Tue Apr 17 11:26:06 201=
2 +0100
> @@ -93,11 +93,14 @@ are:
> =

> ### vifname
> =

> -This keyword is valid for HVM guest devices with `type=3Dioemu` only.
> +Specifies the backend device name for the virtual device.
> =

> -Specifies the backend device name for an emulated device. The default
> -is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
> -is the device number.
> +If the domain is an HVM domain then the associated emulated (tap)
> +device will have a "xentap-" prefix added.
> +
> +The default name for the virtual device is `vifDOMID.DEVID` where
> +`DOMID` is the guest domain ID and `DEVID` is the device
> +number. Likewise the default tap name is `xentapDOMID.DEVID`.
> =

> ### script
> =

> diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/vif-common.sh
> --- a/tools/hotplug/Linux/vif-common.sh	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/hotplug/Linux/vif-common.sh	Tue Apr 17 11:26:06 2012 +0100
> @@ -85,8 +85,8 @@ elif [ "$type_if" =3D tap ]; then
>     : ${INTERFACE:?}
> =

>     # Get xenbus_path from device name.
> -    # The name is built like that: "tap${domid}.${devid}".
> -    dev_=3D${dev#tap}
> +    # The name is built like that: "xentap${domid}.${devid}".
> +    dev_=3D${dev#xentap}
>     domid=3D${dev_%.*}
>     devid=3D${dev_#*.}
> =

> diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/xen-backend.rules
> --- a/tools/hotplug/Linux/xen-backend.rules	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/hotplug/Linux/xen-backend.rules	Tue Apr 17 11:26:06 2012 +0100
> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", NAME=3D"xen/blkt
> KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600"
> KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600"
> KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0600"
> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", RUN+=3D"/et=
c/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"xentap*", ACTION=3D=3D"add", RUN+=3D"=
/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
> diff -r 8d92d1f34921 -r de3e65d804cc tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/libxl/libxl_dm.c	Tue Apr 17 11:26:06 2012 +0100
> @@ -212,9 +212,9 @@ static char ** libxl__build_device_model
>                 char *ifname;
>                 if (!vifs[i].ifname)
>                     ifname =3D libxl__sprintf(gc,
> -                                            "tap%d.%d", domid, vifs[i].d=
evid);
> +                                            "xentap%d.%d", domid, vifs[i=
].devid);
>                 else
> -                    ifname =3D vifs[i].ifname;
> +                    ifname =3D libxl__sprintf(gc, "xentap-%s", vifs[i].i=
fname);
>                 flexarray_vappend(dm_args,
>                                 "-net", libxl__sprintf(gc, "nic,vlan=3D%d=
,macaddr=3D%s,model=3D%s",
>                                                        vifs[i].devid, sma=
c, vifs[i].model),
> @@ -451,10 +451,10 @@ static char ** libxl__build_device_model
>                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].ma=
c));
>                 char *ifname;
>                 if (!vifs[i].ifname) {
> -                    ifname =3D libxl__sprintf(gc, "tap%d.%d",
> +                    ifname =3D libxl__sprintf(gc, "xentap%d.%d",
>                                             guest_domid, vifs[i].devid);
>                 } else {
> -                    ifname =3D vifs[i].ifname;
> +                    ifname =3D libxl__sprintf(gc, "xentap-%s", vifs[i].i=
fname);
>                 }
>                 flexarray_append(dm_args, "-device");
>                 flexarray_append(dm_args,
> diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> --- a/tools/python/xen/xend/image.py	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/python/xen/xend/image.py	Tue Apr 17 11:26:06 2012 +0100
> @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
>             if vifname:
>                 vifname =3D "tap-" + vifname
>             else:
> -                vifname =3D "tap%d.%d" % (self.vm.getDomid(), nics-1)
> +                vifname =3D "xentap%d.%d" % (self.vm.getDomid(), nics-1)
>             ret.append("-net")
>             ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%s" %
>                        (nics, vifname, bridge))
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:10:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:10:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8Aj-0003mH-8n; Tue, 17 Apr 2012 13:10:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK8Ai-0003m0-AI
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:10:16 +0000
Received: from [85.158.139.83:52892] by server-1.bemta-5.messagelabs.com id
	D7/9A-28458-7BB6D8F4; Tue, 17 Apr 2012 13:10:15 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334668210!20320260!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 17 Apr 2012 13:10:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:10:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190704173"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 09:08:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 09:08:02 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK88Y-0003pD-0q;
	Tue, 17 Apr 2012 14:08:02 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334658395.23948.6.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 14:08:02 +0100
Message-ID: <0BD309F0-D2F1-45D5-899B-F0242D13A569@citrix.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 11:26, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 20:03 +0100, M A Young wrote:
>> There is a Fedora bug report =

>> https://bugzilla.redhat.com/show_bug.cgi?id=3D812421 reporting that open=
vpn =

>> is having problems because of the line
>> SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", RUN+=3D"/et=
c/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
>> in /etc/udev/rules.d/xen-backend.rules which is causing the xen script t=
o =

>> run when openvpn tries to use a tap device, causing it to fail. I have =

>> used the attached patch to solve this problem, by matching the form of t=
he =

>> tap device that xen uses more exactly to avoid to openvpn case. A better =

>> long-term solution (suggested in one of the comments in the bug) might b=
e =

>> to use a more specific name instead of "tap" so we have less chance of =

>> interfering with another application.
> =

> This is a good start, I think we should do this for 4.2.
> =

> Changing the name might be pretty simple though e.g. the following.
> Works for me with xl but I didn't try xend (seems "obviously correct"?)
> =

> I noticed that when vifname is set xend prepends "tap-" (presumably to
> distinguish it from the vif device) whereas libxl does not, so I suspect
> named vifs for HVM guests don't work so well, I fixed that while I was
> there...
> =

> Also at least for the libxl case we will likely not be running these
> hotplug scripts via udev any more in 4.2, however I don't think there is
> any harm in making this change first (iff we decide it is suitable for
> 4.2).
> =

> Ian.
> =

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1334658366 -3600
> # Node ID de3e65d804cceab7291e2accc18d50ae8b816433
> # Parent  8d92d1f34921c8675d85c74aa36e319c9451f68f
> libxl/xend: name tap devices with a xentap prefix
> =

> This prevents the udev scripts from operating on other tap devices (e.g.
> openvpn etc)
> =

> Also add "xentap-" prefix to the tap device when an explicit name is give=
n to
> avoid a conflict with the vif device, which would otherwise have the same=
 name.
> Likewise correct the documentation for this option which suggested it app=
lied
> to HVM tap devices only.
> =

> Reported by Michael Young.
> =

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Roger Pau Monne <roger.pau@citrix.com>

I've already changed my hotplug series to match this change in the udev rul=
es, so this has to go in before mine.

> =

> diff -r 8d92d1f34921 -r de3e65d804cc docs/misc/xl-network-configuration.m=
arkdown
> --- a/docs/misc/xl-network-configuration.markdown	Mon Apr 16 17:57:00 201=
2 +0100
> +++ b/docs/misc/xl-network-configuration.markdown	Tue Apr 17 11:26:06 201=
2 +0100
> @@ -93,11 +93,14 @@ are:
> =

> ### vifname
> =

> -This keyword is valid for HVM guest devices with `type=3Dioemu` only.
> +Specifies the backend device name for the virtual device.
> =

> -Specifies the backend device name for an emulated device. The default
> -is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
> -is the device number.
> +If the domain is an HVM domain then the associated emulated (tap)
> +device will have a "xentap-" prefix added.
> +
> +The default name for the virtual device is `vifDOMID.DEVID` where
> +`DOMID` is the guest domain ID and `DEVID` is the device
> +number. Likewise the default tap name is `xentapDOMID.DEVID`.
> =

> ### script
> =

> diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/vif-common.sh
> --- a/tools/hotplug/Linux/vif-common.sh	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/hotplug/Linux/vif-common.sh	Tue Apr 17 11:26:06 2012 +0100
> @@ -85,8 +85,8 @@ elif [ "$type_if" =3D tap ]; then
>     : ${INTERFACE:?}
> =

>     # Get xenbus_path from device name.
> -    # The name is built like that: "tap${domid}.${devid}".
> -    dev_=3D${dev#tap}
> +    # The name is built like that: "xentap${domid}.${devid}".
> +    dev_=3D${dev#xentap}
>     domid=3D${dev_%.*}
>     devid=3D${dev_#*.}
> =

> diff -r 8d92d1f34921 -r de3e65d804cc tools/hotplug/Linux/xen-backend.rules
> --- a/tools/hotplug/Linux/xen-backend.rules	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/hotplug/Linux/xen-backend.rules	Tue Apr 17 11:26:06 2012 +0100
> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", NAME=3D"xen/blkt
> KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600"
> KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600"
> KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0600"
> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", RUN+=3D"/et=
c/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"xentap*", ACTION=3D=3D"add", RUN+=3D"=
/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
> diff -r 8d92d1f34921 -r de3e65d804cc tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/libxl/libxl_dm.c	Tue Apr 17 11:26:06 2012 +0100
> @@ -212,9 +212,9 @@ static char ** libxl__build_device_model
>                 char *ifname;
>                 if (!vifs[i].ifname)
>                     ifname =3D libxl__sprintf(gc,
> -                                            "tap%d.%d", domid, vifs[i].d=
evid);
> +                                            "xentap%d.%d", domid, vifs[i=
].devid);
>                 else
> -                    ifname =3D vifs[i].ifname;
> +                    ifname =3D libxl__sprintf(gc, "xentap-%s", vifs[i].i=
fname);
>                 flexarray_vappend(dm_args,
>                                 "-net", libxl__sprintf(gc, "nic,vlan=3D%d=
,macaddr=3D%s,model=3D%s",
>                                                        vifs[i].devid, sma=
c, vifs[i].model),
> @@ -451,10 +451,10 @@ static char ** libxl__build_device_model
>                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].ma=
c));
>                 char *ifname;
>                 if (!vifs[i].ifname) {
> -                    ifname =3D libxl__sprintf(gc, "tap%d.%d",
> +                    ifname =3D libxl__sprintf(gc, "xentap%d.%d",
>                                             guest_domid, vifs[i].devid);
>                 } else {
> -                    ifname =3D vifs[i].ifname;
> +                    ifname =3D libxl__sprintf(gc, "xentap-%s", vifs[i].i=
fname);
>                 }
>                 flexarray_append(dm_args, "-device");
>                 flexarray_append(dm_args,
> diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> --- a/tools/python/xen/xend/image.py	Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/python/xen/xend/image.py	Tue Apr 17 11:26:06 2012 +0100
> @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
>             if vifname:
>                 vifname =3D "tap-" + vifname
>             else:
> -                vifname =3D "tap%d.%d" % (self.vm.getDomid(), nics-1)
> +                vifname =3D "xentap%d.%d" % (self.vm.getDomid(), nics-1)
>             ret.append("-net")
>             ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%s" %
>                        (nics, vifname, bridge))
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:18:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:18:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8IK-0004Q1-Ei; Tue, 17 Apr 2012 13:18:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SK8II-0004Pw-Vs
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:18:07 +0000
Received: from [85.158.143.35:56705] by server-2.bemta-4.messagelabs.com id
	13/A5-17550-E8D6D8F4; Tue, 17 Apr 2012 13:18:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334668685!16509839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1478 invoked from network); 17 Apr 2012 13:18:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11978040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 13:18:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 14:18:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SK8IG-0004GU-7z; Tue, 17 Apr 2012 13:18:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SK8IG-0003us-5J;
	Tue, 17 Apr 2012 14:18:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.28044.149473.65854@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 14:18:04 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334654299.14560.268.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334654299.14560.268.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script; use autoheader"):
> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > Remove a lot of unnecessary tests.  Specifically, we no longer test
> > for standard POSIX facilities which we expect to be provided
> > everywhere and which we don't in any case have any alternative for.
> 
> A good rule of thumb might be that if it isn't provided by "apt-get
> install build-essential" (or the common set of stuff from the equivalent
> meta-packages across common distros) then configure should check for it
> in the interest of providing a useful upfront error message?

Yes, I think so.

> > Switch to generating config.h.in with autoheader.
> 
> > @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
> >  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
> >  AC_SUBST(libgcrypt)
> >  AX_CHECK_PTHREAD
> > -AC_CHECK_LIB([rt], [clock_gettime])
> 
> -lrt is always available? -l<one-or-two-letters> libraries seem to be
> the ones which tend to differ across platforms, despite being
> standardised...

The current configure script throws away the result of this test, so
it is definitely useless.  The effect in configure is to perhaps add
-lrt to LIBS but we do not export configure's LIBS to every tools
build.

> > +AX_CHECK_PTYFUNCS
> 
> You don't actually add this until the next patch.

Oops.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:18:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:18:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8IK-0004Q1-Ei; Tue, 17 Apr 2012 13:18:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SK8II-0004Pw-Vs
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:18:07 +0000
Received: from [85.158.143.35:56705] by server-2.bemta-4.messagelabs.com id
	13/A5-17550-E8D6D8F4; Tue, 17 Apr 2012 13:18:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334668685!16509839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1478 invoked from network); 17 Apr 2012 13:18:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11978040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 13:18:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 14:18:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SK8IG-0004GU-7z; Tue, 17 Apr 2012 13:18:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SK8IG-0003us-5J;
	Tue, 17 Apr 2012 14:18:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.28044.149473.65854@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 14:18:04 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334654299.14560.268.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334654299.14560.268.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script; use autoheader"):
> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > Remove a lot of unnecessary tests.  Specifically, we no longer test
> > for standard POSIX facilities which we expect to be provided
> > everywhere and which we don't in any case have any alternative for.
> 
> A good rule of thumb might be that if it isn't provided by "apt-get
> install build-essential" (or the common set of stuff from the equivalent
> meta-packages across common distros) then configure should check for it
> in the interest of providing a useful upfront error message?

Yes, I think so.

> > Switch to generating config.h.in with autoheader.
> 
> > @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
> >  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
> >  AC_SUBST(libgcrypt)
> >  AX_CHECK_PTHREAD
> > -AC_CHECK_LIB([rt], [clock_gettime])
> 
> -lrt is always available? -l<one-or-two-letters> libraries seem to be
> the ones which tend to differ across platforms, despite being
> standardised...

The current configure script throws away the result of this test, so
it is definitely useless.  The effect in configure is to perhaps add
-lrt to LIBS but we do not export configure's LIBS to every tools
build.

> > +AX_CHECK_PTYFUNCS
> 
> You don't actually add this until the next patch.

Oops.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:23:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8Mn-0004bC-6f; Tue, 17 Apr 2012 13:22:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK8Ml-0004b2-LX
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:22:43 +0000
Received: from [85.158.143.35:10363] by server-1.bemta-4.messagelabs.com id
	AE/C8-20925-2AE6D8F4; Tue, 17 Apr 2012 13:22:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334668962!7467297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1985 invoked from network); 17 Apr 2012 13:22:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11978253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 13:22:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 14:22:36 +0100
Message-ID: <1334668954.23948.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 14:22:34 +0100
In-Reply-To: <20365.28044.149473.65854@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334654299.14560.268.camel@zakaz.uk.xensource.com>
	<20365.28044.149473.65854@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 14:18 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script; use autoheader"):
> > On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > > Remove a lot of unnecessary tests.  Specifically, we no longer test
> > > for standard POSIX facilities which we expect to be provided
> > > everywhere and which we don't in any case have any alternative for.
> > 
> > A good rule of thumb might be that if it isn't provided by "apt-get
> > install build-essential" (or the common set of stuff from the equivalent
> > meta-packages across common distros) then configure should check for it
> > in the interest of providing a useful upfront error message?
> 
> Yes, I think so.
> 
> > > Switch to generating config.h.in with autoheader.
> > 
> > > @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
> > >  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
> > >  AC_SUBST(libgcrypt)
> > >  AX_CHECK_PTHREAD
> > > -AC_CHECK_LIB([rt], [clock_gettime])
> > 
> > -lrt is always available? -l<one-or-two-letters> libraries seem to be
> > the ones which tend to differ across platforms, despite being
> > standardised...
> 
> The current configure script throws away the result of this test, so
> it is definitely useless.  The effect in configure is to perhaps add
> -lrt to LIBS but we do not export configure's LIBS to every tools
> build.

It aborts if -lrt isn't available though, doesn't it?

> > > +AX_CHECK_PTYFUNCS
> > 
> > You don't actually add this until the next patch.
> 
> Oops.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:23:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8Mn-0004bC-6f; Tue, 17 Apr 2012 13:22:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK8Ml-0004b2-LX
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:22:43 +0000
Received: from [85.158.143.35:10363] by server-1.bemta-4.messagelabs.com id
	AE/C8-20925-2AE6D8F4; Tue, 17 Apr 2012 13:22:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334668962!7467297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1985 invoked from network); 17 Apr 2012 13:22:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11978253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 13:22:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 14:22:36 +0100
Message-ID: <1334668954.23948.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 14:22:34 +0100
In-Reply-To: <20365.28044.149473.65854@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334654299.14560.268.camel@zakaz.uk.xensource.com>
	<20365.28044.149473.65854@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 14:18 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script; use autoheader"):
> > On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > > Remove a lot of unnecessary tests.  Specifically, we no longer test
> > > for standard POSIX facilities which we expect to be provided
> > > everywhere and which we don't in any case have any alternative for.
> > 
> > A good rule of thumb might be that if it isn't provided by "apt-get
> > install build-essential" (or the common set of stuff from the equivalent
> > meta-packages across common distros) then configure should check for it
> > in the interest of providing a useful upfront error message?
> 
> Yes, I think so.
> 
> > > Switch to generating config.h.in with autoheader.
> > 
> > > @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
> > >  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
> > >  AC_SUBST(libgcrypt)
> > >  AX_CHECK_PTHREAD
> > > -AC_CHECK_LIB([rt], [clock_gettime])
> > 
> > -lrt is always available? -l<one-or-two-letters> libraries seem to be
> > the ones which tend to differ across platforms, despite being
> > standardised...
> 
> The current configure script throws away the result of this test, so
> it is definitely useless.  The effect in configure is to perhaps add
> -lrt to LIBS but we do not export configure's LIBS to every tools
> build.

It aborts if -lrt isn't available though, doesn't it?

> > > +AX_CHECK_PTYFUNCS
> > 
> > You don't actually add this until the next patch.
> 
> Oops.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:24:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8O7-0004fk-OU; Tue, 17 Apr 2012 13:24:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SK8O6-0004fc-J0
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:24:06 +0000
Received: from [193.109.254.147:3997] by server-2.bemta-14.messagelabs.com id
	74/EF-19409-5FE6D8F4; Tue, 17 Apr 2012 13:24:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334669045!4994952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21098 invoked from network); 17 Apr 2012 13:24:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:24:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11978370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 13:24:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 14:24:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SK8O4-0004IY-SS; Tue, 17 Apr 2012 13:24:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SK8O4-00047T-RZ;
	Tue, 17 Apr 2012 14:24:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.28404.838315.795899@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 14:24:04 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334655631.14560.272.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
	<1334655631.14560.272.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead"):
> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > Remove this obsolete hook.  Callers inside libxl which create and reap
> > children should use the mechanisms provided by the event system.
> 
> The hook is unused which is good because otherwise I would have asked
> for this patch to go after the patches to make the users use those
> mechanisms. As it is removing the hook makes no semantic difference to
> anyone.

Yes.  I'll add a note about that to the commit message.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:24:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8O7-0004fk-OU; Tue, 17 Apr 2012 13:24:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SK8O6-0004fc-J0
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 13:24:06 +0000
Received: from [193.109.254.147:3997] by server-2.bemta-14.messagelabs.com id
	74/EF-19409-5FE6D8F4; Tue, 17 Apr 2012 13:24:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334669045!4994952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21098 invoked from network); 17 Apr 2012 13:24:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 13:24:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11978370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 13:24:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 14:24:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SK8O4-0004IY-SS; Tue, 17 Apr 2012 13:24:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SK8O4-00047T-RZ;
	Tue, 17 Apr 2012 14:24:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.28404.838315.795899@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 14:24:04 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334655631.14560.272.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-16-git-send-email-ian.jackson@eu.citrix.com>
	<1334655631.14560.272.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/24] libxl: remove ctx->waitpid_instead"):
> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > Remove this obsolete hook.  Callers inside libxl which create and reap
> > children should use the mechanisms provided by the event system.
> 
> The hook is unused which is good because otherwise I would have asked
> for this patch to go after the patches to make the users use those
> mechanisms. As it is removing the hook makes no semantic difference to
> anyone.

Yes.  I'll add a note about that to the commit message.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8Yc-0004um-Tk; Tue, 17 Apr 2012 13:34:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK8Yb-0004uh-BJ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 13:34:57 +0000
Received: from [193.109.254.147:41082] by server-3.bemta-14.messagelabs.com id
	ED/C0-23274-0817D8F4; Tue, 17 Apr 2012 13:34:56 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334669694!2525309!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27830 invoked from network); 17 Apr 2012 13:34:55 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 13:34:55 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK8YY-0004MF-30
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 06:34:54 -0700
Date: Tue, 17 Apr 2012 06:34:54 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334669694083-5646585.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Someone can explain use of these commands? I ran tests with a hvm domU but
with errors

For example:
xl -v cd-insert XP hdc raw:/mnt/vm/iso/test.iso
libxl: error: libxl.c:1647:libxl_cdrom_insert: Virtual device not found

Thanks for any reply.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5646585.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 13:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 13:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK8Yc-0004um-Tk; Tue, 17 Apr 2012 13:34:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK8Yb-0004uh-BJ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 13:34:57 +0000
Received: from [193.109.254.147:41082] by server-3.bemta-14.messagelabs.com id
	ED/C0-23274-0817D8F4; Tue, 17 Apr 2012 13:34:56 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334669694!2525309!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27830 invoked from network); 17 Apr 2012 13:34:55 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 13:34:55 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK8YY-0004MF-30
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 06:34:54 -0700
Date: Tue, 17 Apr 2012 06:34:54 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334669694083-5646585.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Someone can explain use of these commands? I ran tests with a hvm domU but
with errors

For example:
xl -v cd-insert XP hdc raw:/mnt/vm/iso/test.iso
libxl: error: libxl.c:1647:libxl_cdrom_insert: Virtual device not found

Thanks for any reply.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5646585.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:12:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK98O-0005J3-AG; Tue, 17 Apr 2012 14:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK98M-0005Iy-Kv
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:11:54 +0000
Received: from [85.158.143.99:20981] by server-1.bemta-4.messagelabs.com id
	EF/E1-20925-92A7D8F4; Tue, 17 Apr 2012 14:11:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334671911!23462158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26809 invoked from network); 17 Apr 2012 14:11:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:11:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190722649"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:07:35 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:07:35 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK94A-0004o9-K2;
	Tue, 17 Apr 2012 15:07:34 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334668954.23948.37.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:07:35 +0100
Message-ID: <8F2F3F19-DB94-45DF-AE82-AE59D3C35A6A@citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334654299.14560.268.camel@zakaz.uk.xensource.com>
	<20365.28044.149473.65854@mariner.uk.xensource.com>
	<1334668954.23948.37.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
	use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 14:22, Ian Campbell escribi=F3:
> On Tue, 2012-04-17 at 14:18 +0100, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/24] autoconf: trim the c=
onfigure script; use autoheader"):
>>> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
>>>> Remove a lot of unnecessary tests.  Specifically, we no longer test
>>>> for standard POSIX facilities which we expect to be provided
>>>> everywhere and which we don't in any case have any alternative for.
>>> =

>>> A good rule of thumb might be that if it isn't provided by "apt-get
>>> install build-essential" (or the common set of stuff from the equivalent
>>> meta-packages across common distros) then configure should check for it
>>> in the interest of providing a useful upfront error message?
>> =

>> Yes, I think so.
>> =

>>>> Switch to generating config.h.in with autoheader.
>>> =

>>>> @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
>>>> AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt=3D"y"], [libg=
crypt=3D"n"])
>>>> AC_SUBST(libgcrypt)
>>>> AX_CHECK_PTHREAD
>>>> -AC_CHECK_LIB([rt], [clock_gettime])
>>> =

>>> -lrt is always available? -l<one-or-two-letters> libraries seem to be
>>> the ones which tend to differ across platforms, despite being
>>> standardised...
>> =

>> The current configure script throws away the result of this test, so
>> it is definitely useless.  The effect in configure is to perhaps add
>> -lrt to LIBS but we do not export configure's LIBS to every tools
>> build.
> =

> It aborts if -lrt isn't available though, doesn't it?

This is useless as-is, it adds -lrt to LIBS (which we don't use), and defin=
es HAVE_LIBRT (but doesn't abort if not found).

>From a quick grep I've realized that tools/console uses "-lrt", so maybe we=
 should enforce this and abort if not found.

> =

>>>> +AX_CHECK_PTYFUNCS
>>> =

>>> You don't actually add this until the next patch.
>> =

>> Oops.
>> =

>> Ian.
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:12:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK98O-0005J3-AG; Tue, 17 Apr 2012 14:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK98M-0005Iy-Kv
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:11:54 +0000
Received: from [85.158.143.99:20981] by server-1.bemta-4.messagelabs.com id
	EF/E1-20925-92A7D8F4; Tue, 17 Apr 2012 14:11:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334671911!23462158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26809 invoked from network); 17 Apr 2012 14:11:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:11:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190722649"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:07:35 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:07:35 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK94A-0004o9-K2;
	Tue, 17 Apr 2012 15:07:34 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334668954.23948.37.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:07:35 +0100
Message-ID: <8F2F3F19-DB94-45DF-AE82-AE59D3C35A6A@citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-5-git-send-email-ian.jackson@eu.citrix.com>
	<1334654299.14560.268.camel@zakaz.uk.xensource.com>
	<20365.28044.149473.65854@mariner.uk.xensource.com>
	<1334668954.23948.37.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/24] autoconf: trim the configure script;
	use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 14:22, Ian Campbell escribi=F3:
> On Tue, 2012-04-17 at 14:18 +0100, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/24] autoconf: trim the c=
onfigure script; use autoheader"):
>>> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
>>>> Remove a lot of unnecessary tests.  Specifically, we no longer test
>>>> for standard POSIX facilities which we expect to be provided
>>>> everywhere and which we don't in any case have any alternative for.
>>> =

>>> A good rule of thumb might be that if it isn't provided by "apt-get
>>> install build-essential" (or the common set of stuff from the equivalent
>>> meta-packages across common distros) then configure should check for it
>>> in the interest of providing a useful upfront error message?
>> =

>> Yes, I think so.
>> =

>>>> Switch to generating config.h.in with autoheader.
>>> =

>>>> @@ -132,7 +127,7 @@ AC_SUBST(libext2fs)
>>>> AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt=3D"y"], [libg=
crypt=3D"n"])
>>>> AC_SUBST(libgcrypt)
>>>> AX_CHECK_PTHREAD
>>>> -AC_CHECK_LIB([rt], [clock_gettime])
>>> =

>>> -lrt is always available? -l<one-or-two-letters> libraries seem to be
>>> the ones which tend to differ across platforms, despite being
>>> standardised...
>> =

>> The current configure script throws away the result of this test, so
>> it is definitely useless.  The effect in configure is to perhaps add
>> -lrt to LIBS but we do not export configure's LIBS to every tools
>> build.
> =

> It aborts if -lrt isn't available though, doesn't it?

This is useless as-is, it adds -lrt to LIBS (which we don't use), and defin=
es HAVE_LIBRT (but doesn't abort if not found).

>From a quick grep I've realized that tools/console uses "-lrt", so maybe we=
 should enforce this and abort if not found.

> =

>>>> +AX_CHECK_PTYFUNCS
>>> =

>>> You don't actually add this until the next patch.
>> =

>> Oops.
>> =

>> Ian.
> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:22:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9Ht-0005T9-CU; Tue, 17 Apr 2012 14:21:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SK9Hs-0005T4-5b
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:21:44 +0000
Received: from [85.158.138.51:19112] by server-10.bemta-3.messagelabs.com id
	F0/50-29478-77C7D8F4; Tue, 17 Apr 2012 14:21:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334672501!22567839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27178 invoked from network); 17 Apr 2012 14:21:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11980571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:21:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 15:21:24 +0100
Date: Tue, 17 Apr 2012 15:26:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120417130340.GA25593@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> > This patch is a significant performance improvement for the
> > m2p_override: about 6% using the gntdev device.
> > 
> > Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> > __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> > is a great performance benefit because it means issuing one hypercall
> > total rather than two hypercall per page.
> > If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> > going to be batched together, otherwise they are issued one at a time.
> > 
> > Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> > m2p_add/remove_override calls forces paravirt_lazy_mode to
> > PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> > 
> > 
> > Changes in v3:
> > - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> > can be called in interrupt context.
> 
> This is with RHEL5 (somehow the pvops kernels don't trigger this):

Do you mean RHEL5 as a guest? Are you using blkback or qdisk?
How can I repro the bug?


In any case it looks like a similar kind of issue to the one I fixed
before: paravirt_enter_lazy_mmu is probably called with
paravirt_lazy_mode == PARAVIRT_LAZY_MMU, in this case by
gnttab_unmap_refs.
But I don't understand how gnttab_unmap_refs can be called when you seem
to be using blkback.

Anyhow gnttab_unmap_refs can be called by:

- mmu_notifier on invalidate_range_start;
- vm_operations_struct on close;
- file_operations on release;
- the unmap gntdev ioctl.

I guess the mmu_notifier or vm_operations_struct could be the ones
calling gnttab_unmap_refs with lazy_mode set to PARAVIRT_LAZY_MMU.

I suspect that something like the following code would fix the issue but
it is pretty ugly and I need to test it before a submitting it as a fix:


@@ -780,7 +780,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
                      struct page **pages, unsigned int count, bool clear_pte)
 {
-       int i, ret;
+       int i, ret, lazy = 0;
 
        ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
        if (ret)

@@ -789,7 +789,10 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
        if (xen_feature(XENFEAT_auto_translated_physmap))
                return ret;
 
-       arch_enter_lazy_mmu_mode();
+       if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+               arch_enter_lazy_mmu_mode();
+               lazy = 1;
+       }
 
        for (i = 0; i < count; i++) {
                ret = m2p_remove_override(pages[i], clear_pte);
@@ -797,7 +800,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
                        return ret;
        }
 
-       arch_leave_lazy_mmu_mode();
+       if (lazy)
+               arch_leave_lazy_mmu_mode();
 
        return ret;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:22:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9Ht-0005T9-CU; Tue, 17 Apr 2012 14:21:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SK9Hs-0005T4-5b
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:21:44 +0000
Received: from [85.158.138.51:19112] by server-10.bemta-3.messagelabs.com id
	F0/50-29478-77C7D8F4; Tue, 17 Apr 2012 14:21:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334672501!22567839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27178 invoked from network); 17 Apr 2012 14:21:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11980571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:21:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 15:21:24 +0100
Date: Tue, 17 Apr 2012 15:26:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120417130340.GA25593@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> > This patch is a significant performance improvement for the
> > m2p_override: about 6% using the gntdev device.
> > 
> > Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> > __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> > is a great performance benefit because it means issuing one hypercall
> > total rather than two hypercall per page.
> > If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> > going to be batched together, otherwise they are issued one at a time.
> > 
> > Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> > m2p_add/remove_override calls forces paravirt_lazy_mode to
> > PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> > 
> > 
> > Changes in v3:
> > - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> > can be called in interrupt context.
> 
> This is with RHEL5 (somehow the pvops kernels don't trigger this):

Do you mean RHEL5 as a guest? Are you using blkback or qdisk?
How can I repro the bug?


In any case it looks like a similar kind of issue to the one I fixed
before: paravirt_enter_lazy_mmu is probably called with
paravirt_lazy_mode == PARAVIRT_LAZY_MMU, in this case by
gnttab_unmap_refs.
But I don't understand how gnttab_unmap_refs can be called when you seem
to be using blkback.

Anyhow gnttab_unmap_refs can be called by:

- mmu_notifier on invalidate_range_start;
- vm_operations_struct on close;
- file_operations on release;
- the unmap gntdev ioctl.

I guess the mmu_notifier or vm_operations_struct could be the ones
calling gnttab_unmap_refs with lazy_mode set to PARAVIRT_LAZY_MMU.

I suspect that something like the following code would fix the issue but
it is pretty ugly and I need to test it before a submitting it as a fix:


@@ -780,7 +780,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
                      struct page **pages, unsigned int count, bool clear_pte)
 {
-       int i, ret;
+       int i, ret, lazy = 0;
 
        ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
        if (ret)

@@ -789,7 +789,10 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
        if (xen_feature(XENFEAT_auto_translated_physmap))
                return ret;
 
-       arch_enter_lazy_mmu_mode();
+       if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+               arch_enter_lazy_mmu_mode();
+               lazy = 1;
+       }
 
        for (i = 0; i < count; i++) {
                ret = m2p_remove_override(pages[i], clear_pte);
@@ -797,7 +800,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
                        return ret;
        }
 
-       arch_leave_lazy_mmu_mode();
+       if (lazy)
+               arch_leave_lazy_mmu_mode();
 
        return ret;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:22:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:22:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9Hv-0005TQ-Oz; Tue, 17 Apr 2012 14:21:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK9Hu-0005TD-8h
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:21:46 +0000
Received: from [85.158.139.83:22011] by server-11.bemta-5.messagelabs.com id
	26/34-12959-97C7D8F4; Tue, 17 Apr 2012 14:21:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334672504!23533452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29158 invoked from network); 17 Apr 2012 14:21:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11980600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:21:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 15:21:36 +0100
Message-ID: <1334672495.23948.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 17 Apr 2012 15:21:35 +0100
In-Reply-To: <149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
 directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDE1OjE4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gRWwgMTYvMDQvMjAxMiwgYSBsYXMgMTc6NTAsIElhbiBDYW1wYmVsbCBlc2NyaWJpw7M6Cj4g
PiBPbiBNb24sIDIwMTItMDQtMTYgYXQgMTY6MDYgKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiBDbGVhbiB4ZW5zdG9yZSwgdG8gcHJldmVudCBsZWF2aW5nIGVtcHR5IGRpcmVjdG9y
aWVzIGluIHRoZSB0cmVlLCBsaWtlOgo+ID4+IAo+ID4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5k
L2NvbnNvbGUgPSAiIiAgIChuMCkKPiA+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9jb25zb2xl
LzMgPSAiIiAgIChuMCkKPiA+PiAKPiA+PiBUaGF0IHdhcyBsZWZ0IGFmdGVyIGEgZ3Vlc3Qgd2Fz
IGRlc3Ryb3llZC4KPiA+PiAKPiA+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJv
Z2VyLnBhdUBjaXRyaXguY29tPgo+ID4+IC0tLQo+ID4+IHRvb2xzL2xpYnhsL2xpYnhsX2Rldmlj
ZS5jIHwgICAgNSArKy0tLQo+ID4+IDEgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAz
IGRlbGV0aW9ucygtKQo+ID4+IAo+ID4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9k
ZXZpY2UuYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RldmljZS5jCj4gPj4gaW5kZXggZDc3M2Q3MS4u
NDE2MWQxYmQgMTAwNjQ0Cj4gPj4gLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMKPiA+
PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYwo+ID4+IEBAIC02MDksMTIgKzYwOSwx
MSBAQCBvdXRfb2s6Cj4gPj4gCj4gPj4gaW50IGxpYnhsX19kZXZpY2VfZGVzdHJveShsaWJ4bF9f
Z2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpCj4gPj4gewo+ID4+IC0gICAgbGlieGxfY3R4ICpj
dHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+ID4+ICAgICBjaGFyICpiZV9wYXRoID0gbGlieGxf
X2RldmljZV9iYWNrZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4gICAgIGNoYXIgKmZlX3BhdGggPSBs
aWJ4bF9fZGV2aWNlX2Zyb250ZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4gCj4gPj4gLSAgICB4c19y
bShjdHgtPnhzaCwgWEJUX05VTEwsIGJlX3BhdGgpOwo+ID4+IC0gICAgeHNfcm0oY3R4LT54c2gs
IFhCVF9OVUxMLCBmZV9wYXRoKTsKPiA+PiArICAgIGxpYnhsX194c19wYXRoX2NsZWFudXAoZ2Ms
IGZlX3BhdGgpOwo+ID4+ICsgICAgbGlieGxfX3hzX3BhdGhfY2xlYW51cChnYywgYmVfcGF0aCk7
Cj4gPiAKPiA+IGlzIHhzX3JtIG5vdCByZWN1cnNpdmU/IEF0IGxlYXN0IGZyb20gdGhlIENMSSBp
dCBzZWVtcyB0byBiZQo+IAo+IE9rLCBJIGdvdCBtZXNzZWQgdXAgaGVyZSwgd2hhdCBteSBmdW5j
dGlvbiBkaWQgd2FzIHB1cmdlIGEgZGlyZWN0b3J5Cj4gdHJlZSBmcm9tIHRvcCB0byBib3R0b20s
IHNvIHVzaW5nIHlvdXIgZXhhbXBsZSwgZG9pbmcgYToKPiAKPiBsaWJ4bF9feHNfcGF0aF9jbGVh
bnVwKGdjLCAiL2Zvby9iYXIvYmF6Iik7Cj4gCj4gV291bGQgaGF2ZSBlcmFzZWQgL2Zvby9iYXIv
YmF6LCAvZm9vL2JhciBhbmQgL2ZvbywgYmVjYXVzZSB0aGV5IHdoZXJlCj4gYWxsIGVtcHR5ICho
YWQgbm8gbW9yZSBmaWxlcyBvciBzdWJmb2xkZXJzIGluc2lkZSkgYWZ0ZXIgZGVsZXRpbmcKPiAi
YmF6Ii4KCklGRiB0aGV5IGFyZSBlbXB0eT8gU28gdGhlIHByZXNlbmNlIG9mIC9mb28vYm9iIHdv
dWxkIGhhdmUgbWFkZQpvbmx5IC9mb28vYmFyL2JheiBhbmQgL2Zvby9iYXIgYnV0IG5vdCAvZm9v
IGdldCBkZWxldGVkPwoKSU9XIGl0IGJlaGF2ZXMgbGlrZSAieGVuc3RvcmUtcm0gLXQiICh0IGZv
ciB0aWR5KT8KCj4gCj4gU28gSSBndWVzcyB0aGlzIGlzIHJlYWxseSBuZWVkZWQuCj4gCj4gPiAK
PiA+IHF1YXJ0ejp+IyB4ZW5zdG9yZS13cml0ZSAvZm9vL2Jhci9iYXogMTIzCj4gPiBxdWFydHo6
fiMgeGVuc3RvcmUtbHMgLWYgfCBncmVwIGZvbwo+ID4gL2ZvbyA9ICIiCj4gPiAvZm9vL2JhciA9
ICIiCj4gPiAvZm9vL2Jhci9iYXogPSAiMTIzIgo+ID4gcXVhcnR6On4jIHhlbnN0b3JlLXJtICAv
Zm9vCj4gPiBxdWFydHo6fiMgeGVuc3RvcmUtbHMgLWYgfCBncmVwIGZvbwo+ID4gcXVhcnR6On4j
IAo+ID4gCj4gPiBsb29raW5nIGF0IHhlbnN0b3JlX2NsaWVudC5jIGl0IHNlZW1zIHRvIG9ubHkg
Y2FsbCB4c19ybSgpIGFuZCBub3QgZG8KPiA+IGFueSB0cmF2ZXJzYWwgaXRzZWxmPwo+ID4gCj4g
Pj4gCj4gPj4gICAgIGxpYnhsX19kZXZpY2VfZGVzdHJveV90YXBkaXNrKGdjLCBiZV9wYXRoKTsK
PiA+PiAKPiA+IAo+ID4gCj4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:22:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:22:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9Hv-0005TQ-Oz; Tue, 17 Apr 2012 14:21:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK9Hu-0005TD-8h
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:21:46 +0000
Received: from [85.158.139.83:22011] by server-11.bemta-5.messagelabs.com id
	26/34-12959-97C7D8F4; Tue, 17 Apr 2012 14:21:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334672504!23533452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29158 invoked from network); 17 Apr 2012 14:21:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11980600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:21:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 15:21:36 +0100
Message-ID: <1334672495.23948.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 17 Apr 2012 15:21:35 +0100
In-Reply-To: <149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
 directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDE1OjE4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gRWwgMTYvMDQvMjAxMiwgYSBsYXMgMTc6NTAsIElhbiBDYW1wYmVsbCBlc2NyaWJpw7M6Cj4g
PiBPbiBNb24sIDIwMTItMDQtMTYgYXQgMTY6MDYgKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiBDbGVhbiB4ZW5zdG9yZSwgdG8gcHJldmVudCBsZWF2aW5nIGVtcHR5IGRpcmVjdG9y
aWVzIGluIHRoZSB0cmVlLCBsaWtlOgo+ID4+IAo+ID4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5k
L2NvbnNvbGUgPSAiIiAgIChuMCkKPiA+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9jb25zb2xl
LzMgPSAiIiAgIChuMCkKPiA+PiAKPiA+PiBUaGF0IHdhcyBsZWZ0IGFmdGVyIGEgZ3Vlc3Qgd2Fz
IGRlc3Ryb3llZC4KPiA+PiAKPiA+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJv
Z2VyLnBhdUBjaXRyaXguY29tPgo+ID4+IC0tLQo+ID4+IHRvb2xzL2xpYnhsL2xpYnhsX2Rldmlj
ZS5jIHwgICAgNSArKy0tLQo+ID4+IDEgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAz
IGRlbGV0aW9ucygtKQo+ID4+IAo+ID4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9k
ZXZpY2UuYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RldmljZS5jCj4gPj4gaW5kZXggZDc3M2Q3MS4u
NDE2MWQxYmQgMTAwNjQ0Cj4gPj4gLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMKPiA+
PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYwo+ID4+IEBAIC02MDksMTIgKzYwOSwx
MSBAQCBvdXRfb2s6Cj4gPj4gCj4gPj4gaW50IGxpYnhsX19kZXZpY2VfZGVzdHJveShsaWJ4bF9f
Z2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpCj4gPj4gewo+ID4+IC0gICAgbGlieGxfY3R4ICpj
dHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+ID4+ICAgICBjaGFyICpiZV9wYXRoID0gbGlieGxf
X2RldmljZV9iYWNrZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4gICAgIGNoYXIgKmZlX3BhdGggPSBs
aWJ4bF9fZGV2aWNlX2Zyb250ZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4gCj4gPj4gLSAgICB4c19y
bShjdHgtPnhzaCwgWEJUX05VTEwsIGJlX3BhdGgpOwo+ID4+IC0gICAgeHNfcm0oY3R4LT54c2gs
IFhCVF9OVUxMLCBmZV9wYXRoKTsKPiA+PiArICAgIGxpYnhsX194c19wYXRoX2NsZWFudXAoZ2Ms
IGZlX3BhdGgpOwo+ID4+ICsgICAgbGlieGxfX3hzX3BhdGhfY2xlYW51cChnYywgYmVfcGF0aCk7
Cj4gPiAKPiA+IGlzIHhzX3JtIG5vdCByZWN1cnNpdmU/IEF0IGxlYXN0IGZyb20gdGhlIENMSSBp
dCBzZWVtcyB0byBiZQo+IAo+IE9rLCBJIGdvdCBtZXNzZWQgdXAgaGVyZSwgd2hhdCBteSBmdW5j
dGlvbiBkaWQgd2FzIHB1cmdlIGEgZGlyZWN0b3J5Cj4gdHJlZSBmcm9tIHRvcCB0byBib3R0b20s
IHNvIHVzaW5nIHlvdXIgZXhhbXBsZSwgZG9pbmcgYToKPiAKPiBsaWJ4bF9feHNfcGF0aF9jbGVh
bnVwKGdjLCAiL2Zvby9iYXIvYmF6Iik7Cj4gCj4gV291bGQgaGF2ZSBlcmFzZWQgL2Zvby9iYXIv
YmF6LCAvZm9vL2JhciBhbmQgL2ZvbywgYmVjYXVzZSB0aGV5IHdoZXJlCj4gYWxsIGVtcHR5ICho
YWQgbm8gbW9yZSBmaWxlcyBvciBzdWJmb2xkZXJzIGluc2lkZSkgYWZ0ZXIgZGVsZXRpbmcKPiAi
YmF6Ii4KCklGRiB0aGV5IGFyZSBlbXB0eT8gU28gdGhlIHByZXNlbmNlIG9mIC9mb28vYm9iIHdv
dWxkIGhhdmUgbWFkZQpvbmx5IC9mb28vYmFyL2JheiBhbmQgL2Zvby9iYXIgYnV0IG5vdCAvZm9v
IGdldCBkZWxldGVkPwoKSU9XIGl0IGJlaGF2ZXMgbGlrZSAieGVuc3RvcmUtcm0gLXQiICh0IGZv
ciB0aWR5KT8KCj4gCj4gU28gSSBndWVzcyB0aGlzIGlzIHJlYWxseSBuZWVkZWQuCj4gCj4gPiAK
PiA+IHF1YXJ0ejp+IyB4ZW5zdG9yZS13cml0ZSAvZm9vL2Jhci9iYXogMTIzCj4gPiBxdWFydHo6
fiMgeGVuc3RvcmUtbHMgLWYgfCBncmVwIGZvbwo+ID4gL2ZvbyA9ICIiCj4gPiAvZm9vL2JhciA9
ICIiCj4gPiAvZm9vL2Jhci9iYXogPSAiMTIzIgo+ID4gcXVhcnR6On4jIHhlbnN0b3JlLXJtICAv
Zm9vCj4gPiBxdWFydHo6fiMgeGVuc3RvcmUtbHMgLWYgfCBncmVwIGZvbwo+ID4gcXVhcnR6On4j
IAo+ID4gCj4gPiBsb29raW5nIGF0IHhlbnN0b3JlX2NsaWVudC5jIGl0IHNlZW1zIHRvIG9ubHkg
Y2FsbCB4c19ybSgpIGFuZCBub3QgZG8KPiA+IGFueSB0cmF2ZXJzYWwgaXRzZWxmPwo+ID4gCj4g
Pj4gCj4gPj4gICAgIGxpYnhsX19kZXZpY2VfZGVzdHJveV90YXBkaXNrKGdjLCBiZV9wYXRoKTsK
PiA+PiAKPiA+IAo+ID4gCj4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9IM-0005Vf-By; Tue, 17 Apr 2012 14:22:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK9IK-0005VO-3z
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:22:12 +0000
Received: from [193.109.254.147:38910] by server-11.bemta-14.messagelabs.com
	id 8E/1F-05858-09C7D8F4; Tue, 17 Apr 2012 14:22:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334672525!5025531!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5802 invoked from network); 17 Apr 2012 14:22:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:22:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190725432"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:18:28 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:18:28 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK9Ei-0004x8-08;
	Tue, 17 Apr 2012 15:18:28 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334595019.14560.246.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:18:28 +0100
Message-ID: <149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 17:50, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>> Clean xenstore, to prevent leaving empty directories in the tree, like:
>> =

>> /local/domain/0/backend/console =3D ""   (n0)
>> /local/domain/0/backend/console/3 =3D ""   (n0)
>> =

>> That was left after a guest was destroyed.
>> =

>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> tools/libxl/libxl_device.c |    5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>> =

>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index d773d71..4161d1bd 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -609,12 +609,11 @@ out_ok:
>> =

>> int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>> {
>> -    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>>     char *be_path =3D libxl__device_backend_path(gc, dev);
>>     char *fe_path =3D libxl__device_frontend_path(gc, dev);
>> =

>> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
>> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
>> +    libxl__xs_path_cleanup(gc, fe_path);
>> +    libxl__xs_path_cleanup(gc, be_path);
> =

> is xs_rm not recursive? At least from the CLI it seems to be

Ok, I got messed up here, what my function did was purge a directory tree f=
rom top to bottom, so using your example, doing a:

libxl__xs_path_cleanup(gc, "/foo/bar/baz");

Would have erased /foo/bar/baz, /foo/bar and /foo, because they where all e=
mpty (had no more files or subfolders inside) after deleting "baz".

So I guess this is really needed.

> =

> quartz:~# xenstore-write /foo/bar/baz 123
> quartz:~# xenstore-ls -f | grep foo
> /foo =3D ""
> /foo/bar =3D ""
> /foo/bar/baz =3D "123"
> quartz:~# xenstore-rm  /foo
> quartz:~# xenstore-ls -f | grep foo
> quartz:~# =

> =

> looking at xenstore_client.c it seems to only call xs_rm() and not do
> any traversal itself?
> =

>> =

>>     libxl__device_destroy_tapdisk(gc, be_path);
>> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9IM-0005Vf-By; Tue, 17 Apr 2012 14:22:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK9IK-0005VO-3z
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:22:12 +0000
Received: from [193.109.254.147:38910] by server-11.bemta-14.messagelabs.com
	id 8E/1F-05858-09C7D8F4; Tue, 17 Apr 2012 14:22:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334672525!5025531!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5802 invoked from network); 17 Apr 2012 14:22:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:22:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190725432"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:18:28 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:18:28 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK9Ei-0004x8-08;
	Tue, 17 Apr 2012 15:18:28 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334595019.14560.246.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:18:28 +0100
Message-ID: <149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 16/04/2012, a las 17:50, Ian Campbell escribi=F3:
> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>> Clean xenstore, to prevent leaving empty directories in the tree, like:
>> =

>> /local/domain/0/backend/console =3D ""   (n0)
>> /local/domain/0/backend/console/3 =3D ""   (n0)
>> =

>> That was left after a guest was destroyed.
>> =

>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> tools/libxl/libxl_device.c |    5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>> =

>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index d773d71..4161d1bd 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -609,12 +609,11 @@ out_ok:
>> =

>> int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>> {
>> -    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>>     char *be_path =3D libxl__device_backend_path(gc, dev);
>>     char *fe_path =3D libxl__device_frontend_path(gc, dev);
>> =

>> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
>> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
>> +    libxl__xs_path_cleanup(gc, fe_path);
>> +    libxl__xs_path_cleanup(gc, be_path);
> =

> is xs_rm not recursive? At least from the CLI it seems to be

Ok, I got messed up here, what my function did was purge a directory tree f=
rom top to bottom, so using your example, doing a:

libxl__xs_path_cleanup(gc, "/foo/bar/baz");

Would have erased /foo/bar/baz, /foo/bar and /foo, because they where all e=
mpty (had no more files or subfolders inside) after deleting "baz".

So I guess this is really needed.

> =

> quartz:~# xenstore-write /foo/bar/baz 123
> quartz:~# xenstore-ls -f | grep foo
> /foo =3D ""
> /foo/bar =3D ""
> /foo/bar/baz =3D "123"
> quartz:~# xenstore-rm  /foo
> quartz:~# xenstore-ls -f | grep foo
> quartz:~# =

> =

> looking at xenstore_client.c it seems to only call xs_rm() and not do
> any traversal itself?
> =

>> =

>>     libxl__device_destroy_tapdisk(gc, be_path);
>> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:27:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9NZ-0005tc-4l; Tue, 17 Apr 2012 14:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SK9NX-0005tT-Vs
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:27:36 +0000
Received: from [193.109.254.147:44383] by server-4.bemta-14.messagelabs.com id
	D1/D9-11570-6DD7D8F4; Tue, 17 Apr 2012 14:27:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334672854!5026813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31640 invoked from network); 17 Apr 2012 14:27:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11980992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:27:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 15:27:33 +0100
Date: Tue, 17 Apr 2012 15:32:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1334590729-6971-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1204171532030.26786@kaball-desktop>
References: <1334590729-6971-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "John V. Baboval" <john.baboval@virtualcomputer.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Tom Goetz <tom.goetz@virtualcomputer.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Support guest reboots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012, Anthony PERARD wrote:
> From: John V. Baboval <john.baboval@virtualcomputer.com>
> 
> Call xc_domain_shutdown with the reboot flag when the guest requests a reboot.
> 
> Signed-off-by: John V. Baboval <john.baboval@virtualcomputer.com>
> Signed-off-by: Tom Goetz <tom.goetz@virtualcomputer.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:27:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9NZ-0005tc-4l; Tue, 17 Apr 2012 14:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SK9NX-0005tT-Vs
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:27:36 +0000
Received: from [193.109.254.147:44383] by server-4.bemta-14.messagelabs.com id
	D1/D9-11570-6DD7D8F4; Tue, 17 Apr 2012 14:27:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334672854!5026813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31640 invoked from network); 17 Apr 2012 14:27:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11980992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:27:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 15:27:33 +0100
Date: Tue, 17 Apr 2012 15:32:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1334590729-6971-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1204171532030.26786@kaball-desktop>
References: <1334590729-6971-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "John V. Baboval" <john.baboval@virtualcomputer.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Tom Goetz <tom.goetz@virtualcomputer.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Support guest reboots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012, Anthony PERARD wrote:
> From: John V. Baboval <john.baboval@virtualcomputer.com>
> 
> Call xc_domain_shutdown with the reboot flag when the guest requests a reboot.
> 
> Signed-off-by: John V. Baboval <john.baboval@virtualcomputer.com>
> Signed-off-by: Tom Goetz <tom.goetz@virtualcomputer.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:31:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9R2-00064z-Oj; Tue, 17 Apr 2012 14:31:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK9R1-00064r-QN
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:31:11 +0000
Received: from [193.109.254.147:55090] by server-11.bemta-14.messagelabs.com
	id 09/88-05858-EAE7D8F4; Tue, 17 Apr 2012 14:31:10 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334673056!5014023!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4896 invoked from network); 17 Apr 2012 14:30:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 14:30:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK9Ql-0003bM-L0
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:30:55 -0700
Date: Tue, 17 Apr 2012 07:30:55 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334673055645-5646707.post@n5.nabble.com>
In-Reply-To: <1334578081.14560.163.camel@zakaz.uk.xensource.com>
References: <4F8C0641.6030206@tiscali.it>
	<1334578081.14560.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
>>       rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
>>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
>> -    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
>>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
>> -    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
> 
> These two are things older versions of Xen installed but which current
> versions do not?
> 
I not understand that.
Could you clarify me?

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-Makefile-Some-updates-to-uninstall-tp5643579p5646707.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:31:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9R2-00064z-Oj; Tue, 17 Apr 2012 14:31:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK9R1-00064r-QN
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:31:11 +0000
Received: from [193.109.254.147:55090] by server-11.bemta-14.messagelabs.com
	id 09/88-05858-EAE7D8F4; Tue, 17 Apr 2012 14:31:10 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334673056!5014023!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4896 invoked from network); 17 Apr 2012 14:30:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Apr 2012 14:30:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SK9Ql-0003bM-L0
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 07:30:55 -0700
Date: Tue, 17 Apr 2012 07:30:55 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334673055645-5646707.post@n5.nabble.com>
In-Reply-To: <1334578081.14560.163.camel@zakaz.uk.xensource.com>
References: <4F8C0641.6030206@tiscali.it>
	<1334578081.14560.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
>>       rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
>>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
>> -    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
>>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
>> -    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
> 
> These two are things older versions of Xen installed but which current
> versions do not?
> 
I not understand that.
Could you clarify me?

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-Makefile-Some-updates-to-uninstall-tp5643579p5646707.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:32:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9SK-0006AM-7Y; Tue, 17 Apr 2012 14:32:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK9SI-0006AB-1U
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:32:30 +0000
Received: from [85.158.143.99:2591] by server-1.bemta-4.messagelabs.com id
	8D/15-20925-CFE7D8F4; Tue, 17 Apr 2012 14:32:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334673146!20656355!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzcxMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6738 invoked from network); 17 Apr 2012 14:32:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:32:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="24233831"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:32:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:32:25 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK9SD-00058Z-8H;
	Tue, 17 Apr 2012 15:32:25 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334672495.23948.69.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:32:26 +0100
Message-ID: <BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
	<1334672495.23948.69.camel@zakaz.uk.xensource.com>
To: Roger Pau Monne <roger.pau@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 15:18, Roger Pau Monne escribi=F3:
> On Tue, 2012-04-17 at 15:18 +0100, Roger Pau Monne wrote:
>> El 16/04/2012, a las 17:50, Ian Campbell escribi=F3:
>>> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>>>> Clean xenstore, to prevent leaving empty directories in the tree, like:
>>>> =

>>>> /local/domain/0/backend/console =3D ""   (n0)
>>>> /local/domain/0/backend/console/3 =3D ""   (n0)
>>>> =

>>>> That was left after a guest was destroyed.
>>>> =

>>>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>>>> ---
>>>> tools/libxl/libxl_device.c |    5 ++---
>>>> 1 files changed, 2 insertions(+), 3 deletions(-)
>>>> =

>>>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>>>> index d773d71..4161d1bd 100644
>>>> --- a/tools/libxl/libxl_device.c
>>>> +++ b/tools/libxl/libxl_device.c
>>>> @@ -609,12 +609,11 @@ out_ok:
>>>> =

>>>> int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>>>> {
>>>> -    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>>>>    char *be_path =3D libxl__device_backend_path(gc, dev);
>>>>    char *fe_path =3D libxl__device_frontend_path(gc, dev);
>>>> =

>>>> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
>>>> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
>>>> +    libxl__xs_path_cleanup(gc, fe_path);
>>>> +    libxl__xs_path_cleanup(gc, be_path);
>>> =

>>> is xs_rm not recursive? At least from the CLI it seems to be
>> =

>> Ok, I got messed up here, what my function did was purge a directory
>> tree from top to bottom, so using your example, doing a:
>> =

>> libxl__xs_path_cleanup(gc, "/foo/bar/baz");
>> =

>> Would have erased /foo/bar/baz, /foo/bar and /foo, because they where
>> all empty (had no more files or subfolders inside) after deleting
>> "baz".
> =

> IFF they are empty? So the presence of /foo/bob would have made
> only /foo/bar/baz and /foo/bar but not /foo get deleted?


Yes, if there's a /foo/bob that would prevent the deletion of /foo.

> =

> IOW it behaves like "xenstore-rm -t" (t for tidy)?

>From what I saw, yes (although I didn't even know of "xenstore-rm -t").

> =

>> =

>> So I guess this is really needed.
>> =

>>> =

>>> quartz:~# xenstore-write /foo/bar/baz 123
>>> quartz:~# xenstore-ls -f | grep foo
>>> /foo =3D ""
>>> /foo/bar =3D ""
>>> /foo/bar/baz =3D "123"
>>> quartz:~# xenstore-rm  /foo
>>> quartz:~# xenstore-ls -f | grep foo
>>> quartz:~# =

>>> =

>>> looking at xenstore_client.c it seems to only call xs_rm() and not do
>>> any traversal itself?
>>> =

>>>> =

>>>>    libxl__device_destroy_tapdisk(gc, be_path);
>>>> =

>>> =

>>> =

>> =

>> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:32:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9SK-0006AM-7Y; Tue, 17 Apr 2012 14:32:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK9SI-0006AB-1U
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:32:30 +0000
Received: from [85.158.143.99:2591] by server-1.bemta-4.messagelabs.com id
	8D/15-20925-CFE7D8F4; Tue, 17 Apr 2012 14:32:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334673146!20656355!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzcxMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6738 invoked from network); 17 Apr 2012 14:32:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:32:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="24233831"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:32:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:32:25 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK9SD-00058Z-8H;
	Tue, 17 Apr 2012 15:32:25 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334672495.23948.69.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:32:26 +0100
Message-ID: <BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
	<1334672495.23948.69.camel@zakaz.uk.xensource.com>
To: Roger Pau Monne <roger.pau@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 15:18, Roger Pau Monne escribi=F3:
> On Tue, 2012-04-17 at 15:18 +0100, Roger Pau Monne wrote:
>> El 16/04/2012, a las 17:50, Ian Campbell escribi=F3:
>>> On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
>>>> Clean xenstore, to prevent leaving empty directories in the tree, like:
>>>> =

>>>> /local/domain/0/backend/console =3D ""   (n0)
>>>> /local/domain/0/backend/console/3 =3D ""   (n0)
>>>> =

>>>> That was left after a guest was destroyed.
>>>> =

>>>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>>>> ---
>>>> tools/libxl/libxl_device.c |    5 ++---
>>>> 1 files changed, 2 insertions(+), 3 deletions(-)
>>>> =

>>>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>>>> index d773d71..4161d1bd 100644
>>>> --- a/tools/libxl/libxl_device.c
>>>> +++ b/tools/libxl/libxl_device.c
>>>> @@ -609,12 +609,11 @@ out_ok:
>>>> =

>>>> int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>>>> {
>>>> -    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>>>>    char *be_path =3D libxl__device_backend_path(gc, dev);
>>>>    char *fe_path =3D libxl__device_frontend_path(gc, dev);
>>>> =

>>>> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
>>>> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
>>>> +    libxl__xs_path_cleanup(gc, fe_path);
>>>> +    libxl__xs_path_cleanup(gc, be_path);
>>> =

>>> is xs_rm not recursive? At least from the CLI it seems to be
>> =

>> Ok, I got messed up here, what my function did was purge a directory
>> tree from top to bottom, so using your example, doing a:
>> =

>> libxl__xs_path_cleanup(gc, "/foo/bar/baz");
>> =

>> Would have erased /foo/bar/baz, /foo/bar and /foo, because they where
>> all empty (had no more files or subfolders inside) after deleting
>> "baz".
> =

> IFF they are empty? So the presence of /foo/bob would have made
> only /foo/bar/baz and /foo/bar but not /foo get deleted?


Yes, if there's a /foo/bob that would prevent the deletion of /foo.

> =

> IOW it behaves like "xenstore-rm -t" (t for tidy)?

>From what I saw, yes (although I didn't even know of "xenstore-rm -t").

> =

>> =

>> So I guess this is really needed.
>> =

>>> =

>>> quartz:~# xenstore-write /foo/bar/baz 123
>>> quartz:~# xenstore-ls -f | grep foo
>>> /foo =3D ""
>>> /foo/bar =3D ""
>>> /foo/bar/baz =3D "123"
>>> quartz:~# xenstore-rm  /foo
>>> quartz:~# xenstore-ls -f | grep foo
>>> quartz:~# =

>>> =

>>> looking at xenstore_client.c it seems to only call xs_rm() and not do
>>> any traversal itself?
>>> =

>>>> =

>>>>    libxl__device_destroy_tapdisk(gc, be_path);
>>>> =

>>> =

>>> =

>> =

>> =

> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:37:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9X0-0006Oa-2I; Tue, 17 Apr 2012 14:37:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK9Wy-0006OR-EB
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:37:20 +0000
Received: from [85.158.143.99:18536] by server-2.bemta-4.messagelabs.com id
	78/13-17550-F108D8F4; Tue, 17 Apr 2012 14:37:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334673435!23492162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28073 invoked from network); 17 Apr 2012 14:37:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:37:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11981458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:37:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 15:37:14 +0100
Message-ID: <1334673433.23948.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 17 Apr 2012 15:37:13 +0100
In-Reply-To: <BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
	<1334672495.23948.69.camel@zakaz.uk.xensource.com>
	<BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
 directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDE1OjMyICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gRWwgMTcvMDQvMjAxMiwgYSBsYXMgMTU6MTgsIFJvZ2VyIFBhdSBNb25uZSBlc2NyaWJpw7M6
Cj4gPiBPbiBUdWUsIDIwMTItMDQtMTcgYXQgMTU6MTggKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3
cm90ZToKPiA+PiBFbCAxNi8wNC8yMDEyLCBhIGxhcyAxNzo1MCwgSWFuIENhbXBiZWxsIGVzY3Jp
YmnDszoKPiA+Pj4gT24gTW9uLCAyMDEyLTA0LTE2IGF0IDE2OjA2ICswMTAwLCBSb2dlciBQYXUg
TW9ubmUgd3JvdGU6Cj4gPj4+PiBDbGVhbiB4ZW5zdG9yZSwgdG8gcHJldmVudCBsZWF2aW5nIGVt
cHR5IGRpcmVjdG9yaWVzIGluIHRoZSB0cmVlLCBsaWtlOgo+ID4+Pj4gCj4gPj4+PiAvbG9jYWwv
ZG9tYWluLzAvYmFja2VuZC9jb25zb2xlID0gIiIgICAobjApCj4gPj4+PiAvbG9jYWwvZG9tYWlu
LzAvYmFja2VuZC9jb25zb2xlLzMgPSAiIiAgIChuMCkKPiA+Pj4+IAo+ID4+Pj4gVGhhdCB3YXMg
bGVmdCBhZnRlciBhIGd1ZXN0IHdhcyBkZXN0cm95ZWQuCj4gPj4+PiAKPiA+Pj4+IFNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gPj4+PiAtLS0K
PiA+Pj4+IHRvb2xzL2xpYnhsL2xpYnhsX2RldmljZS5jIHwgICAgNSArKy0tLQo+ID4+Pj4gMSBm
aWxlcyBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCj4gPj4+PiAKPiA+
Pj4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYyBiL3Rvb2xzL2xpYnhs
L2xpYnhsX2RldmljZS5jCj4gPj4+PiBpbmRleCBkNzczZDcxLi40MTYxZDFiZCAxMDA2NDQKPiA+
Pj4+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RldmljZS5jCj4gPj4+PiArKysgYi90b29scy9s
aWJ4bC9saWJ4bF9kZXZpY2UuYwo+ID4+Pj4gQEAgLTYwOSwxMiArNjA5LDExIEBAIG91dF9vazoK
PiA+Pj4+IAo+ID4+Pj4gaW50IGxpYnhsX19kZXZpY2VfZGVzdHJveShsaWJ4bF9fZ2MgKmdjLCBs
aWJ4bF9fZGV2aWNlICpkZXYpCj4gPj4+PiB7Cj4gPj4+PiAtICAgIGxpYnhsX2N0eCAqY3R4ID0g
bGlieGxfX2djX293bmVyKGdjKTsKPiA+Pj4+ICAgIGNoYXIgKmJlX3BhdGggPSBsaWJ4bF9fZGV2
aWNlX2JhY2tlbmRfcGF0aChnYywgZGV2KTsKPiA+Pj4+ICAgIGNoYXIgKmZlX3BhdGggPSBsaWJ4
bF9fZGV2aWNlX2Zyb250ZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4+PiAKPiA+Pj4+IC0gICAgeHNf
cm0oY3R4LT54c2gsIFhCVF9OVUxMLCBiZV9wYXRoKTsKPiA+Pj4+IC0gICAgeHNfcm0oY3R4LT54
c2gsIFhCVF9OVUxMLCBmZV9wYXRoKTsKPiA+Pj4+ICsgICAgbGlieGxfX3hzX3BhdGhfY2xlYW51
cChnYywgZmVfcGF0aCk7Cj4gPj4+PiArICAgIGxpYnhsX194c19wYXRoX2NsZWFudXAoZ2MsIGJl
X3BhdGgpOwo+ID4+PiAKPiA+Pj4gaXMgeHNfcm0gbm90IHJlY3Vyc2l2ZT8gQXQgbGVhc3QgZnJv
bSB0aGUgQ0xJIGl0IHNlZW1zIHRvIGJlCj4gPj4gCj4gPj4gT2ssIEkgZ290IG1lc3NlZCB1cCBo
ZXJlLCB3aGF0IG15IGZ1bmN0aW9uIGRpZCB3YXMgcHVyZ2UgYSBkaXJlY3RvcnkKPiA+PiB0cmVl
IGZyb20gdG9wIHRvIGJvdHRvbSwgc28gdXNpbmcgeW91ciBleGFtcGxlLCBkb2luZyBhOgo+ID4+
IAo+ID4+IGxpYnhsX194c19wYXRoX2NsZWFudXAoZ2MsICIvZm9vL2Jhci9iYXoiKTsKPiA+PiAK
PiA+PiBXb3VsZCBoYXZlIGVyYXNlZCAvZm9vL2Jhci9iYXosIC9mb28vYmFyIGFuZCAvZm9vLCBi
ZWNhdXNlIHRoZXkgd2hlcmUKPiA+PiBhbGwgZW1wdHkgKGhhZCBubyBtb3JlIGZpbGVzIG9yIHN1
YmZvbGRlcnMgaW5zaWRlKSBhZnRlciBkZWxldGluZwo+ID4+ICJiYXoiLgo+ID4gCj4gPiBJRkYg
dGhleSBhcmUgZW1wdHk/IFNvIHRoZSBwcmVzZW5jZSBvZiAvZm9vL2JvYiB3b3VsZCBoYXZlIG1h
ZGUKPiA+IG9ubHkgL2Zvby9iYXIvYmF6IGFuZCAvZm9vL2JhciBidXQgbm90IC9mb28gZ2V0IGRl
bGV0ZWQ/Cj4gCj4gCj4gWWVzLCBpZiB0aGVyZSdzIGEgL2Zvby9ib2IgdGhhdCB3b3VsZCBwcmV2
ZW50IHRoZSBkZWxldGlvbiBvZiAvZm9vLgo+ID4gCj4gPiBJT1cgaXQgYmVoYXZlcyBsaWtlICJ4
ZW5zdG9yZS1ybSAtdCIgKHQgZm9yIHRpZHkpPwo+IAo+IEZyb20gd2hhdCBJIHNhdywgeWVzIChh
bHRob3VnaCBJIGRpZG4ndCBldmVuIGtub3cgb2YgInhlbnN0b3JlLXJtIC10IikuCgpNZSBuZWl0
aGVyIHRpbGwgSSBsb29rZWQgYXQgeGVuc3RvcmVfY2xpZW50LmMgdG8gc2VlIGhvdyBteSBleHBl
cmltZW50cwpyZWxhdGVkIHRvIHhzX3JtLi4uCgo+IAo+ID4gCj4gPj4gCj4gPj4gU28gSSBndWVz
cyB0aGlzIGlzIHJlYWxseSBuZWVkZWQuCj4gPj4gCj4gPj4+IAo+ID4+PiBxdWFydHo6fiMgeGVu
c3RvcmUtd3JpdGUgL2Zvby9iYXIvYmF6IDEyMwo+ID4+PiBxdWFydHo6fiMgeGVuc3RvcmUtbHMg
LWYgfCBncmVwIGZvbwo+ID4+PiAvZm9vID0gIiIKPiA+Pj4gL2Zvby9iYXIgPSAiIgo+ID4+PiAv
Zm9vL2Jhci9iYXogPSAiMTIzIgo+ID4+PiBxdWFydHo6fiMgeGVuc3RvcmUtcm0gIC9mb28KPiA+
Pj4gcXVhcnR6On4jIHhlbnN0b3JlLWxzIC1mIHwgZ3JlcCBmb28KPiA+Pj4gcXVhcnR6On4jIAo+
ID4+PiAKPiA+Pj4gbG9va2luZyBhdCB4ZW5zdG9yZV9jbGllbnQuYyBpdCBzZWVtcyB0byBvbmx5
IGNhbGwgeHNfcm0oKSBhbmQgbm90IGRvCj4gPj4+IGFueSB0cmF2ZXJzYWwgaXRzZWxmPwo+ID4+
PiAKPiA+Pj4+IAo+ID4+Pj4gICAgbGlieGxfX2RldmljZV9kZXN0cm95X3RhcGRpc2soZ2MsIGJl
X3BhdGgpOwo+ID4+Pj4gCj4gPj4+IAo+ID4+PiAKPiA+PiAKPiA+PiAKPiA+IAo+ID4gCj4gCj4g
Cj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:37:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9X0-0006Oa-2I; Tue, 17 Apr 2012 14:37:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK9Wy-0006OR-EB
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:37:20 +0000
Received: from [85.158.143.99:18536] by server-2.bemta-4.messagelabs.com id
	78/13-17550-F108D8F4; Tue, 17 Apr 2012 14:37:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334673435!23492162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28073 invoked from network); 17 Apr 2012 14:37:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:37:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11981458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:37:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 15:37:14 +0100
Message-ID: <1334673433.23948.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 17 Apr 2012 15:37:13 +0100
In-Reply-To: <BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
	<1334672495.23948.69.camel@zakaz.uk.xensource.com>
	<BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
 directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA0LTE3IGF0IDE1OjMyICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gRWwgMTcvMDQvMjAxMiwgYSBsYXMgMTU6MTgsIFJvZ2VyIFBhdSBNb25uZSBlc2NyaWJpw7M6
Cj4gPiBPbiBUdWUsIDIwMTItMDQtMTcgYXQgMTU6MTggKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3
cm90ZToKPiA+PiBFbCAxNi8wNC8yMDEyLCBhIGxhcyAxNzo1MCwgSWFuIENhbXBiZWxsIGVzY3Jp
YmnDszoKPiA+Pj4gT24gTW9uLCAyMDEyLTA0LTE2IGF0IDE2OjA2ICswMTAwLCBSb2dlciBQYXUg
TW9ubmUgd3JvdGU6Cj4gPj4+PiBDbGVhbiB4ZW5zdG9yZSwgdG8gcHJldmVudCBsZWF2aW5nIGVt
cHR5IGRpcmVjdG9yaWVzIGluIHRoZSB0cmVlLCBsaWtlOgo+ID4+Pj4gCj4gPj4+PiAvbG9jYWwv
ZG9tYWluLzAvYmFja2VuZC9jb25zb2xlID0gIiIgICAobjApCj4gPj4+PiAvbG9jYWwvZG9tYWlu
LzAvYmFja2VuZC9jb25zb2xlLzMgPSAiIiAgIChuMCkKPiA+Pj4+IAo+ID4+Pj4gVGhhdCB3YXMg
bGVmdCBhZnRlciBhIGd1ZXN0IHdhcyBkZXN0cm95ZWQuCj4gPj4+PiAKPiA+Pj4+IFNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gPj4+PiAtLS0K
PiA+Pj4+IHRvb2xzL2xpYnhsL2xpYnhsX2RldmljZS5jIHwgICAgNSArKy0tLQo+ID4+Pj4gMSBm
aWxlcyBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCj4gPj4+PiAKPiA+
Pj4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYyBiL3Rvb2xzL2xpYnhs
L2xpYnhsX2RldmljZS5jCj4gPj4+PiBpbmRleCBkNzczZDcxLi40MTYxZDFiZCAxMDA2NDQKPiA+
Pj4+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RldmljZS5jCj4gPj4+PiArKysgYi90b29scy9s
aWJ4bC9saWJ4bF9kZXZpY2UuYwo+ID4+Pj4gQEAgLTYwOSwxMiArNjA5LDExIEBAIG91dF9vazoK
PiA+Pj4+IAo+ID4+Pj4gaW50IGxpYnhsX19kZXZpY2VfZGVzdHJveShsaWJ4bF9fZ2MgKmdjLCBs
aWJ4bF9fZGV2aWNlICpkZXYpCj4gPj4+PiB7Cj4gPj4+PiAtICAgIGxpYnhsX2N0eCAqY3R4ID0g
bGlieGxfX2djX293bmVyKGdjKTsKPiA+Pj4+ICAgIGNoYXIgKmJlX3BhdGggPSBsaWJ4bF9fZGV2
aWNlX2JhY2tlbmRfcGF0aChnYywgZGV2KTsKPiA+Pj4+ICAgIGNoYXIgKmZlX3BhdGggPSBsaWJ4
bF9fZGV2aWNlX2Zyb250ZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4+PiAKPiA+Pj4+IC0gICAgeHNf
cm0oY3R4LT54c2gsIFhCVF9OVUxMLCBiZV9wYXRoKTsKPiA+Pj4+IC0gICAgeHNfcm0oY3R4LT54
c2gsIFhCVF9OVUxMLCBmZV9wYXRoKTsKPiA+Pj4+ICsgICAgbGlieGxfX3hzX3BhdGhfY2xlYW51
cChnYywgZmVfcGF0aCk7Cj4gPj4+PiArICAgIGxpYnhsX194c19wYXRoX2NsZWFudXAoZ2MsIGJl
X3BhdGgpOwo+ID4+PiAKPiA+Pj4gaXMgeHNfcm0gbm90IHJlY3Vyc2l2ZT8gQXQgbGVhc3QgZnJv
bSB0aGUgQ0xJIGl0IHNlZW1zIHRvIGJlCj4gPj4gCj4gPj4gT2ssIEkgZ290IG1lc3NlZCB1cCBo
ZXJlLCB3aGF0IG15IGZ1bmN0aW9uIGRpZCB3YXMgcHVyZ2UgYSBkaXJlY3RvcnkKPiA+PiB0cmVl
IGZyb20gdG9wIHRvIGJvdHRvbSwgc28gdXNpbmcgeW91ciBleGFtcGxlLCBkb2luZyBhOgo+ID4+
IAo+ID4+IGxpYnhsX194c19wYXRoX2NsZWFudXAoZ2MsICIvZm9vL2Jhci9iYXoiKTsKPiA+PiAK
PiA+PiBXb3VsZCBoYXZlIGVyYXNlZCAvZm9vL2Jhci9iYXosIC9mb28vYmFyIGFuZCAvZm9vLCBi
ZWNhdXNlIHRoZXkgd2hlcmUKPiA+PiBhbGwgZW1wdHkgKGhhZCBubyBtb3JlIGZpbGVzIG9yIHN1
YmZvbGRlcnMgaW5zaWRlKSBhZnRlciBkZWxldGluZwo+ID4+ICJiYXoiLgo+ID4gCj4gPiBJRkYg
dGhleSBhcmUgZW1wdHk/IFNvIHRoZSBwcmVzZW5jZSBvZiAvZm9vL2JvYiB3b3VsZCBoYXZlIG1h
ZGUKPiA+IG9ubHkgL2Zvby9iYXIvYmF6IGFuZCAvZm9vL2JhciBidXQgbm90IC9mb28gZ2V0IGRl
bGV0ZWQ/Cj4gCj4gCj4gWWVzLCBpZiB0aGVyZSdzIGEgL2Zvby9ib2IgdGhhdCB3b3VsZCBwcmV2
ZW50IHRoZSBkZWxldGlvbiBvZiAvZm9vLgo+ID4gCj4gPiBJT1cgaXQgYmVoYXZlcyBsaWtlICJ4
ZW5zdG9yZS1ybSAtdCIgKHQgZm9yIHRpZHkpPwo+IAo+IEZyb20gd2hhdCBJIHNhdywgeWVzIChh
bHRob3VnaCBJIGRpZG4ndCBldmVuIGtub3cgb2YgInhlbnN0b3JlLXJtIC10IikuCgpNZSBuZWl0
aGVyIHRpbGwgSSBsb29rZWQgYXQgeGVuc3RvcmVfY2xpZW50LmMgdG8gc2VlIGhvdyBteSBleHBl
cmltZW50cwpyZWxhdGVkIHRvIHhzX3JtLi4uCgo+IAo+ID4gCj4gPj4gCj4gPj4gU28gSSBndWVz
cyB0aGlzIGlzIHJlYWxseSBuZWVkZWQuCj4gPj4gCj4gPj4+IAo+ID4+PiBxdWFydHo6fiMgeGVu
c3RvcmUtd3JpdGUgL2Zvby9iYXIvYmF6IDEyMwo+ID4+PiBxdWFydHo6fiMgeGVuc3RvcmUtbHMg
LWYgfCBncmVwIGZvbwo+ID4+PiAvZm9vID0gIiIKPiA+Pj4gL2Zvby9iYXIgPSAiIgo+ID4+PiAv
Zm9vL2Jhci9iYXogPSAiMTIzIgo+ID4+PiBxdWFydHo6fiMgeGVuc3RvcmUtcm0gIC9mb28KPiA+
Pj4gcXVhcnR6On4jIHhlbnN0b3JlLWxzIC1mIHwgZ3JlcCBmb28KPiA+Pj4gcXVhcnR6On4jIAo+
ID4+PiAKPiA+Pj4gbG9va2luZyBhdCB4ZW5zdG9yZV9jbGllbnQuYyBpdCBzZWVtcyB0byBvbmx5
IGNhbGwgeHNfcm0oKSBhbmQgbm90IGRvCj4gPj4+IGFueSB0cmF2ZXJzYWwgaXRzZWxmPwo+ID4+
PiAKPiA+Pj4+IAo+ID4+Pj4gICAgbGlieGxfX2RldmljZV9kZXN0cm95X3RhcGRpc2soZ2MsIGJl
X3BhdGgpOwo+ID4+Pj4gCj4gPj4+IAo+ID4+PiAKPiA+PiAKPiA+PiAKPiA+IAo+ID4gCj4gCj4g
Cj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:38:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9Xs-0006Rp-GF; Tue, 17 Apr 2012 14:38:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK9Xr-0006Rf-Fd
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:38:15 +0000
Received: from [85.158.143.35:31397] by server-2.bemta-4.messagelabs.com id
	04/B4-17550-6508D8F4; Tue, 17 Apr 2012 14:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334673493!12447188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16906 invoked from network); 17 Apr 2012 14:38:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11981598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 15:38:07 +0100
Message-ID: <1334673485.23948.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Tue, 17 Apr 2012 15:38:05 +0100
In-Reply-To: <1334673055645-5646707.post@n5.nabble.com>
References: <4F8C0641.6030206@tiscali.it>
	<1334578081.14560.163.camel@zakaz.uk.xensource.com>
	<1334673055645-5646707.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 15:30 +0100, Fantu wrote:
> Ian Campbell-10 wrote
> > 
> >>       rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
> >>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
> >> -    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
> >>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
> >> -    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
> > 
> > These two are things older versions of Xen installed but which current
> > versions do not?
> > 
> I not understand that.
> Could you clarify me?

Why are we deleting them now (before your patch), where did they used to
come from? If we no longer create them then it is fine (IMHO) to stop
removing them.

> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/PATCH-Makefile-Some-updates-to-uninstall-tp5643579p5646707.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:38:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9Xs-0006Rp-GF; Tue, 17 Apr 2012 14:38:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SK9Xr-0006Rf-Fd
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:38:15 +0000
Received: from [85.158.143.35:31397] by server-2.bemta-4.messagelabs.com id
	04/B4-17550-6508D8F4; Tue, 17 Apr 2012 14:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334673493!12447188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16906 invoked from network); 17 Apr 2012 14:38:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330905600"; d="scan'208";a="11981598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 15:38:07 +0100
Message-ID: <1334673485.23948.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Tue, 17 Apr 2012 15:38:05 +0100
In-Reply-To: <1334673055645-5646707.post@n5.nabble.com>
References: <4F8C0641.6030206@tiscali.it>
	<1334578081.14560.163.camel@zakaz.uk.xensource.com>
	<1334673055645-5646707.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 15:30 +0100, Fantu wrote:
> Ian Campbell-10 wrote
> > 
> >>       rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
> >>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
> >> -    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
> >>       rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
> >> -    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
> > 
> > These two are things older versions of Xen installed but which current
> > versions do not?
> > 
> I not understand that.
> Could you clarify me?

Why are we deleting them now (before your patch), where did they used to
come from? If we no longer create them then it is fine (IMHO) to stop
removing them.

> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/PATCH-Makefile-Some-updates-to-uninstall-tp5643579p5646707.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:48:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9hk-0006mu-Ke; Tue, 17 Apr 2012 14:48:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SK9hj-0006mp-5P
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:48:27 +0000
Received: from [85.158.143.99:44570] by server-3.bemta-4.messagelabs.com id
	F4/68-05853-AB28D8F4; Tue, 17 Apr 2012 14:48:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334674104!23123981!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NTkzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24158 invoked from network); 17 Apr 2012 14:48:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 14:48:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HEmJEY028002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 14:48:20 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HEmIjt004956
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 14:48:19 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HEmIqQ027178; Tue, 17 Apr 2012 09:48:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 07:48:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 189B840280; Tue, 17 Apr 2012 10:43:19 -0400 (EDT)
Date: Tue, 17 Apr 2012 10:43:19 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120417144318.GA28477@phenom.dumpdata.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F8D82B4.00BE,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 03:26:05PM +0100, Stefano Stabellini wrote:
> On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> > On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> > > This patch is a significant performance improvement for the
> > > m2p_override: about 6% using the gntdev device.
> > > 
> > > Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> > > __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> > > is a great performance benefit because it means issuing one hypercall
> > > total rather than two hypercall per page.
> > > If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> > > going to be batched together, otherwise they are issued one at a time.
> > > 
> > > Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> > > m2p_add/remove_override calls forces paravirt_lazy_mode to
> > > PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> > > 
> > > 
> > > Changes in v3:
> > > - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> > > can be called in interrupt context.
> > 
> > This is with RHEL5 (somehow the pvops kernels don't trigger this):
> 
> Do you mean RHEL5 as a guest? Are you using blkback or qdisk?

blkback:

memory = 1024
name = "RHEL5-64"
hvm_loader="/usr/bin/pygrub"
vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
vcpus=2
vif = [ ' mac=00:0F:4B:00:00:74,bridge=switch' ]
disk = [ 'phy:/dev/guests/RHEL5-64,xvda,w' ]
boot = "dnc"
device_model = 'qemu-dm'
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0
usb=1
usbdevice='tablet'
xen_platform_pci=1

Thought looking at that guest config I am not sure what it boots as
anymore :-(


> How can I repro the bug?

I just bootup the RHEL5 guest and when it tries to get an DHCP address
it then blows up. Hm, maybe the issue is with network - tap vs netfront ?

> 
> 
> In any case it looks like a similar kind of issue to the one I fixed
> before: paravirt_enter_lazy_mmu is probably called with
> paravirt_lazy_mode == PARAVIRT_LAZY_MMU, in this case by
> gnttab_unmap_refs.
> But I don't understand how gnttab_unmap_refs can be called when you seem
> to be using blkback.
> 
> Anyhow gnttab_unmap_refs can be called by:
> 
> - mmu_notifier on invalidate_range_start;
> - vm_operations_struct on close;
> - file_operations on release;
> - the unmap gntdev ioctl.
> 
> I guess the mmu_notifier or vm_operations_struct could be the ones
> calling gnttab_unmap_refs with lazy_mode set to PARAVIRT_LAZY_MMU.
> 
> I suspect that something like the following code would fix the issue but
> it is pretty ugly and I need to test it before a submitting it as a fix:
> 
> 
> @@ -780,7 +780,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>                       struct page **pages, unsigned int count, bool clear_pte)
>  {
> -       int i, ret;
> +       int i, ret, lazy = 0;
>  
>         ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
>         if (ret)
> 
> @@ -789,7 +789,10 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>         if (xen_feature(XENFEAT_auto_translated_physmap))
>                 return ret;
>  
> -       arch_enter_lazy_mmu_mode();
> +       if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> +               arch_enter_lazy_mmu_mode();
> +               lazy = 1;
> +       }
>  
>         for (i = 0; i < count; i++) {
>                 ret = m2p_remove_override(pages[i], clear_pte);
> @@ -797,7 +800,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>                         return ret;
>         }
>  
> -       arch_leave_lazy_mmu_mode();
> +       if (lazy)
> +               arch_leave_lazy_mmu_mode();
>  
>         return ret;
>  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:48:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9hk-0006mu-Ke; Tue, 17 Apr 2012 14:48:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SK9hj-0006mp-5P
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 14:48:27 +0000
Received: from [85.158.143.99:44570] by server-3.bemta-4.messagelabs.com id
	F4/68-05853-AB28D8F4; Tue, 17 Apr 2012 14:48:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334674104!23123981!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NTkzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24158 invoked from network); 17 Apr 2012 14:48:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 14:48:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HEmJEY028002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 14:48:20 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HEmIjt004956
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 14:48:19 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HEmIqQ027178; Tue, 17 Apr 2012 09:48:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 07:48:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 189B840280; Tue, 17 Apr 2012 10:43:19 -0400 (EDT)
Date: Tue, 17 Apr 2012 10:43:19 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120417144318.GA28477@phenom.dumpdata.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F8D82B4.00BE,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 03:26:05PM +0100, Stefano Stabellini wrote:
> On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> > On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> > > This patch is a significant performance improvement for the
> > > m2p_override: about 6% using the gntdev device.
> > > 
> > > Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> > > __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> > > is a great performance benefit because it means issuing one hypercall
> > > total rather than two hypercall per page.
> > > If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> > > going to be batched together, otherwise they are issued one at a time.
> > > 
> > > Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> > > m2p_add/remove_override calls forces paravirt_lazy_mode to
> > > PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> > > 
> > > 
> > > Changes in v3:
> > > - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> > > can be called in interrupt context.
> > 
> > This is with RHEL5 (somehow the pvops kernels don't trigger this):
> 
> Do you mean RHEL5 as a guest? Are you using blkback or qdisk?

blkback:

memory = 1024
name = "RHEL5-64"
hvm_loader="/usr/bin/pygrub"
vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
vcpus=2
vif = [ ' mac=00:0F:4B:00:00:74,bridge=switch' ]
disk = [ 'phy:/dev/guests/RHEL5-64,xvda,w' ]
boot = "dnc"
device_model = 'qemu-dm'
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0
usb=1
usbdevice='tablet'
xen_platform_pci=1

Thought looking at that guest config I am not sure what it boots as
anymore :-(


> How can I repro the bug?

I just bootup the RHEL5 guest and when it tries to get an DHCP address
it then blows up. Hm, maybe the issue is with network - tap vs netfront ?

> 
> 
> In any case it looks like a similar kind of issue to the one I fixed
> before: paravirt_enter_lazy_mmu is probably called with
> paravirt_lazy_mode == PARAVIRT_LAZY_MMU, in this case by
> gnttab_unmap_refs.
> But I don't understand how gnttab_unmap_refs can be called when you seem
> to be using blkback.
> 
> Anyhow gnttab_unmap_refs can be called by:
> 
> - mmu_notifier on invalidate_range_start;
> - vm_operations_struct on close;
> - file_operations on release;
> - the unmap gntdev ioctl.
> 
> I guess the mmu_notifier or vm_operations_struct could be the ones
> calling gnttab_unmap_refs with lazy_mode set to PARAVIRT_LAZY_MMU.
> 
> I suspect that something like the following code would fix the issue but
> it is pretty ugly and I need to test it before a submitting it as a fix:
> 
> 
> @@ -780,7 +780,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>                       struct page **pages, unsigned int count, bool clear_pte)
>  {
> -       int i, ret;
> +       int i, ret, lazy = 0;
>  
>         ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
>         if (ret)
> 
> @@ -789,7 +789,10 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>         if (xen_feature(XENFEAT_auto_translated_physmap))
>                 return ret;
>  
> -       arch_enter_lazy_mmu_mode();
> +       if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> +               arch_enter_lazy_mmu_mode();
> +               lazy = 1;
> +       }
>  
>         for (i = 0; i < count; i++) {
>                 ret = m2p_remove_override(pages[i], clear_pte);
> @@ -797,7 +800,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>                         return ret;
>         }
>  
> -       arch_leave_lazy_mmu_mode();
> +       if (lazy)
> +               arch_leave_lazy_mmu_mode();
>  
>         return ret;
>  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:51:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9kO-0006uN-DS; Tue, 17 Apr 2012 14:51:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK9kN-0006uD-CJ
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:51:11 +0000
Received: from [85.158.143.35:44090] by server-3.bemta-4.messagelabs.com id
	01/0D-05853-E538D8F4; Tue, 17 Apr 2012 14:51:10 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334674262!13102733!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26719 invoked from network); 17 Apr 2012 14:51:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190734456"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:49:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:49:14 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK9iU-0005Mz-Hw;
	Tue, 17 Apr 2012 15:49:14 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334673433.23948.81.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:49:15 +0100
Message-ID: <882A6ABB-2648-4F38-96B7-FF75E870454C@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
	<1334672495.23948.69.camel@zakaz.uk.xensource.com>
	<BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
	<1334673433.23948.81.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 15:37, Ian Campbell escribi=F3:
> On Tue, 2012-04-17 at 15:32 +0100, Roger Pau Monne wrote:
> Me neither till I looked at xenstore_client.c to see how my experiments
> related to xs_rm=85

I've looked at the code, but I prefer mine, since it makes use of the handy=
 libxl__xs_directory libxl function (and I think is cleaner to use a for lo=
op than the goto that's used on xenstore_client.c). I've added it again to =
the series, and I'm going to resend it with the necessary fixes.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:51:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9kO-0006uN-DS; Tue, 17 Apr 2012 14:51:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SK9kN-0006uD-CJ
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:51:11 +0000
Received: from [85.158.143.35:44090] by server-3.bemta-4.messagelabs.com id
	01/0D-05853-E538D8F4; Tue, 17 Apr 2012 14:51:10 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334674262!13102733!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDI5NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26719 invoked from network); 17 Apr 2012 14:51:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 14:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,435,1330923600"; d="scan'208";a="190734456"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 10:49:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 10:49:14 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SK9iU-0005Mz-Hw;
	Tue, 17 Apr 2012 15:49:14 +0100
MIME-Version: 1.0 (Apple Message framework v1257)
From: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1334673433.23948.81.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Apr 2012 15:49:15 +0100
Message-ID: <882A6ABB-2648-4F38-96B7-FF75E870454C@citrix.com>
References: <1334588804-7755-1-git-send-email-roger.pau@citrix.com>
	<1334588804-7755-6-git-send-email-roger.pau@citrix.com>
	<1334595019.14560.246.camel@zakaz.uk.xensource.com>
	<149BAD04-0955-4F13-AF53-282B95550F04@citrix.com>
	<1334672495.23948.69.camel@zakaz.uk.xensource.com>
	<BA11BD6F-CC05-4743-A7DD-B2412AF4E7D6@citrix.com>
	<1334673433.23948.81.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console
	directories recursively on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

El 17/04/2012, a las 15:37, Ian Campbell escribi=F3:
> On Tue, 2012-04-17 at 15:32 +0100, Roger Pau Monne wrote:
> Me neither till I looked at xenstore_client.c to see how my experiments
> related to xs_rm=85

I've looked at the code, but I prefer mine, since it makes use of the handy=
 libxl__xs_directory libxl function (and I think is cleaner to use a for lo=
op than the goto that's used on xenstore_client.c). I've added it again to =
the series, and I'm going to resend it with the necessary fixes.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 14:57:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9qU-000774-7g; Tue, 17 Apr 2012 14:57:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK9qT-00076y-5H
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:57:29 +0000
Received: from [85.158.139.83:52635] by server-1.bemta-5.messagelabs.com id
	13/26-28458-8D48D8F4; Tue, 17 Apr 2012 14:57:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334674646!23539681!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28308 invoked from network); 17 Apr 2012 14:57:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 14:57:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 15:57:25 +0100
Message-Id: <4F8DA0F4020000780007E940@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 15:57:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEAC425C4.0__="
Subject: [Xen-devel] [PATCH] x86-64: fix updating of UREGS_rip when
 converting sysenter to #GP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEAC425C4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

(I spotted this copy-and-paste mistake only when backporting c/s
25200:80f4113be500 to 4.1 and 4.0.)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -280,7 +280,7 @@ sysenter_eflags_saved:
 UNLIKELY_START(z, sysenter_gpf)
         movq  VCPU_trap_ctxt(%rbx),%rsi
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
-        subl  $2,UREGS_rip(%rsp)
+        subq  $2,UREGS_rip(%rsp)
         movl  %eax,TRAPBOUNCE_error_code(%rdx)
         movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
         testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)




--=__PartEAC425C4.0__=
Content-Type: text/plain; name="x86_64-sysenter-trap-bounce-rip.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-sysenter-trap-bounce-rip.patch"

x86-64: fix updating of UREGS_rip when converting sysenter to #GP=0A=0A(I =
spotted this copy-and-paste mistake only when backporting c/s=0A25200:80f41=
13be500 to 4.1 and 4.0.)=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/x86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.=
S=0A@@ -280,7 +280,7 @@ sysenter_eflags_saved:=0A UNLIKELY_START(z, =
sysenter_gpf)=0A         movq  VCPU_trap_ctxt(%rbx),%rsi=0A         movl  =
$TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A-        subl  $2,UREGS_rip(%rsp)=
=0A+        subq  $2,UREGS_rip(%rsp)=0A         movl  %eax,TRAPBOUNCE_error=
_code(%rdx)=0A         movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip=
(%rsi),%rax=0A         testb $4,TRAP_gp_fault * TRAPINFO_sizeof + =
TRAPINFO_flags(%rsi)=0A
--=__PartEAC425C4.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartEAC425C4.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 14:57:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 14:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9qU-000774-7g; Tue, 17 Apr 2012 14:57:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SK9qT-00076y-5H
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 14:57:29 +0000
Received: from [85.158.139.83:52635] by server-1.bemta-5.messagelabs.com id
	13/26-28458-8D48D8F4; Tue, 17 Apr 2012 14:57:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334674646!23539681!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28308 invoked from network); 17 Apr 2012 14:57:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Apr 2012 14:57:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Apr 2012 15:57:25 +0100
Message-Id: <4F8DA0F4020000780007E940@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Apr 2012 15:57:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEAC425C4.0__="
Subject: [Xen-devel] [PATCH] x86-64: fix updating of UREGS_rip when
 converting sysenter to #GP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEAC425C4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

(I spotted this copy-and-paste mistake only when backporting c/s
25200:80f4113be500 to 4.1 and 4.0.)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -280,7 +280,7 @@ sysenter_eflags_saved:
 UNLIKELY_START(z, sysenter_gpf)
         movq  VCPU_trap_ctxt(%rbx),%rsi
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
-        subl  $2,UREGS_rip(%rsp)
+        subq  $2,UREGS_rip(%rsp)
         movl  %eax,TRAPBOUNCE_error_code(%rdx)
         movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
         testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)




--=__PartEAC425C4.0__=
Content-Type: text/plain; name="x86_64-sysenter-trap-bounce-rip.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-sysenter-trap-bounce-rip.patch"

x86-64: fix updating of UREGS_rip when converting sysenter to #GP=0A=0A(I =
spotted this copy-and-paste mistake only when backporting c/s=0A25200:80f41=
13be500 to 4.1 and 4.0.)=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/x86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.=
S=0A@@ -280,7 +280,7 @@ sysenter_eflags_saved:=0A UNLIKELY_START(z, =
sysenter_gpf)=0A         movq  VCPU_trap_ctxt(%rbx),%rsi=0A         movl  =
$TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A-        subl  $2,UREGS_rip(%rsp)=
=0A+        subq  $2,UREGS_rip(%rsp)=0A         movl  %eax,TRAPBOUNCE_error=
_code(%rdx)=0A         movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip=
(%rsi),%rax=0A         testb $4,TRAP_gp_fault * TRAPINFO_sizeof + =
TRAPINFO_flags(%rsi)=0A
--=__PartEAC425C4.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartEAC425C4.0__=--


From xen-devel-bounces@lists.xen.org Tue Apr 17 15:06:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9yT-0007Yk-V3; Tue, 17 Apr 2012 15:05:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK9yS-0007Ye-9U
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:05:44 +0000
Received: from [85.158.143.99:25107] by server-3.bemta-4.messagelabs.com id
	75/E5-05853-7C68D8F4; Tue, 17 Apr 2012 15:05:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334675142!23988902!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2076 invoked from network); 17 Apr 2012 15:05:43 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:05:43 -0000
Received: by bkcjg9 with SMTP id jg9so5863576bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 08:05:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xgrpyfh6iY2beENGGZsyvAaqqsF9ZFkZnrEwq09YU9E=;
	b=PHuIKpmfvVDSJKi4yMaL62zRPnxQ2Go9wL+LO5nlmZCgr7xXYC61JlLvkANDhRJFM7
	8B15P1poGqcbMlgvwWdXmU540K4D4o9TsuwZEWn0e9L5N6i3BGAYl1sNil7g98FeIuMB
	ZxQ7on6tuibw/m1U3XjGKbN4i6pGpE8GAqtxaSxLoX/4qs0SPfz5TQfCO03mhn4fA0aV
	9GeSNkb4GHYHIDODzVPzJIfQESNRDZ1b0Qk8KjbJM99QQBiSSKCnucfngJYsGynfSED2
	AXW7jmN5VJ1tioaTxsMaEINN9pSxjQlHpsvligh9vZH2PODii/Ux9CJrClWFJTXTGZeA
	d0fQ==
Received: by 10.204.157.145 with SMTP id b17mr5175331bkx.112.1334675142499;
	Tue, 17 Apr 2012 08:05:42 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id f5sm38633313bke.9.2012.04.17.08.05.41
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 08:05:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 16:05:38 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB34552.3E5A3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: fix updating of UREGS_rip when
	converting sysenter to #GP
Thread-Index: Ac0cq4wnH950xH7EQU6GL5sfOHR+cQ==
In-Reply-To: <4F8DA0F4020000780007E940@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: fix updating of UREGS_rip when
 converting sysenter to #GP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 15:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> (I spotted this copy-and-paste mistake only when backporting c/s
> 25200:80f4113be500 to 4.1 and 4.0.)
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -280,7 +280,7 @@ sysenter_eflags_saved:
>  UNLIKELY_START(z, sysenter_gpf)
>          movq  VCPU_trap_ctxt(%rbx),%rsi
>          movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
> -        subl  $2,UREGS_rip(%rsp)
> +        subq  $2,UREGS_rip(%rsp)
>          movl  %eax,TRAPBOUNCE_error_code(%rdx)
>          movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
>          testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:06:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SK9yT-0007Yk-V3; Tue, 17 Apr 2012 15:05:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SK9yS-0007Ye-9U
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:05:44 +0000
Received: from [85.158.143.99:25107] by server-3.bemta-4.messagelabs.com id
	75/E5-05853-7C68D8F4; Tue, 17 Apr 2012 15:05:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334675142!23988902!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2076 invoked from network); 17 Apr 2012 15:05:43 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:05:43 -0000
Received: by bkcjg9 with SMTP id jg9so5863576bkc.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 08:05:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xgrpyfh6iY2beENGGZsyvAaqqsF9ZFkZnrEwq09YU9E=;
	b=PHuIKpmfvVDSJKi4yMaL62zRPnxQ2Go9wL+LO5nlmZCgr7xXYC61JlLvkANDhRJFM7
	8B15P1poGqcbMlgvwWdXmU540K4D4o9TsuwZEWn0e9L5N6i3BGAYl1sNil7g98FeIuMB
	ZxQ7on6tuibw/m1U3XjGKbN4i6pGpE8GAqtxaSxLoX/4qs0SPfz5TQfCO03mhn4fA0aV
	9GeSNkb4GHYHIDODzVPzJIfQESNRDZ1b0Qk8KjbJM99QQBiSSKCnucfngJYsGynfSED2
	AXW7jmN5VJ1tioaTxsMaEINN9pSxjQlHpsvligh9vZH2PODii/Ux9CJrClWFJTXTGZeA
	d0fQ==
Received: by 10.204.157.145 with SMTP id b17mr5175331bkx.112.1334675142499;
	Tue, 17 Apr 2012 08:05:42 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id f5sm38633313bke.9.2012.04.17.08.05.41
	(version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 08:05:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Apr 2012 16:05:38 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBB34552.3E5A3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: fix updating of UREGS_rip when
	converting sysenter to #GP
Thread-Index: Ac0cq4wnH950xH7EQU6GL5sfOHR+cQ==
In-Reply-To: <4F8DA0F4020000780007E940@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: fix updating of UREGS_rip when
 converting sysenter to #GP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/2012 15:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> (I spotted this copy-and-paste mistake only when backporting c/s
> 25200:80f4113be500 to 4.1 and 4.0.)
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -280,7 +280,7 @@ sysenter_eflags_saved:
>  UNLIKELY_START(z, sysenter_gpf)
>          movq  VCPU_trap_ctxt(%rbx),%rsi
>          movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
> -        subl  $2,UREGS_rip(%rsp)
> +        subq  $2,UREGS_rip(%rsp)
>          movl  %eax,TRAPBOUNCE_error_code(%rdx)
>          movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
>          testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rsi)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:17:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKA9o-0007ss-4t; Tue, 17 Apr 2012 15:17:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKA9m-0007sn-47
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:17:26 +0000
Received: from [193.109.254.147:11121] by server-10.bemta-14.messagelabs.com
	id A2/15-05847-5898D8F4; Tue, 17 Apr 2012 15:17:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334675844!5037336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11000 invoked from network); 17 Apr 2012 15:17:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:17:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:17:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 16:17:24 +0100
Message-ID: <1334675843.23948.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 16:17:23 +0100
In-Reply-To: <1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Neither this patch nor the rest of the series seems to handle the long
running nature of xc_domain_restore, is that expected at this stage?

We discussed a similar thing in the context of xc_domain_save, and I
expect the required scaffolding (bumping an op over into a thread) will
be the same on both sides?

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> libxl__spawn_spawn becomes a callback-style asynchronous function.
> The implementation is now in terms of libxl__ev_* including
> libxl_ev_child.
> 
> All the callers need to be updated.  This includes the device model
> spawning functions libxl__create_device_model and
> libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
> and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
> abolished; instead the dm spawner calls back.
> 
> (The choice of which kind of device model to create is lifted out of
> what used to be libxl__create_device_model, because that function was
> indirectly recursive.  Recursive callback-style operations are clumsy
> because they require a pointer indirection for the nested states.)
> 
> Waiting for proper device model startup it is no longer notionally
> optional.  Previously the code appeared to tolerate this by passing
> NULL for various libxl__spawner_starting* parameters to device model
> spawners.  However, this was not used anywhere.
> 
> Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
> no longer supported.  It remains as an unused formal parameter to
> avoid updating, in this patch, all the call sites which pass NULL.
> libxl__wait_for_offspring is in any case itself an obsolete function,
> so this wrinkle will go away when its callers are updated to use the
> event system.  Consequently libxl__spawn_check is also abolished.
> 
> The "console ready" callback also remains unchanged in this patch.
> The API for this needs to be reviewed in the context of the event
> series and its reentrancy restrictions documented.
> 
> Thus their callers need to be updated.  These are the domain creation
> functions libxl_domain_create_new and _restore.  These functions now
> take ao_hows, and have a private state structure.
> 
> However domain creation remains not completely converted to the event
> mechanism; in particular it runs the outward-facing function
> libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
> happens in the current code this is not a bug because none of the rest
> of the functionality surrounding the bootloader call will mind if the
> event loop is reentered in the middle of its execution.
> 
> The file-scope function libxl__set_fd_flag which was used by the
> previous spawn arrangements becomes unused and is removed; other
> places in libxl can use libxl_fd_set_nonblock and
> libxl_fd_set_cloexec, which of course remain.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.h          |   14 ++-
>  tools/libxl/libxl_create.c   |  198 +++++++++++++++++++-----
>  tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
>  tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
>  tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
>  tools/libxl/xl_cmdimpl.c     |    6 +-
>  6 files changed, 677 insertions(+), 400 deletions(-)

(nb: I actually skipped ahead and reviewed the libxl_internal.h change
first so I could read the docs, if only diff could be taught such
things ;-))

> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 477b72a..6f59364 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
> 
>  /* domain related functions */
>  typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> -int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> -int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
> +  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
> +   * properties need to be documented but they may turn out to be too
> +   * awkward */

The reentrancy concerns here relate to the "cb" or to something else?

[...]
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 8408c26..09a03a7 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -537,16 +537,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,

[...]

> @@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc,
> libxl_domain_config *d_config,
>          libxl_device_vkb_add(ctx, domid, &vkb);
>          libxl_device_vkb_dispose(&vkb);
> [...]
> +        dcs->dmss.guest_domid = domid;

dcs->dmss is part of a union with dcs->sdss. I'd rather this was done
inside the if once we've committed to one or the other, IYSWIM.

Actually the hunk above (which I've trimmed already, sorry) also
initialised dmss unconditionally.

(does sdss really not need guest_domid somewhere too? odd)

> +        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
> +            libxl__spawn_stubdom(egc, &dcs->sdss);
> +        else
> +            libxl__spawn_local_dm(egc, &dcs->dmss);
> +        return;
> +
>          break;

return then break? I think the break is redundant.

>      }
>      case LIBXL_DOMAIN_TYPE_PV:
> @@ -669,7 +701,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          libxl__device_console_dispose(&console);
> 
>          if (need_qemu) {
> -            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
> +            dcs->dmss.guest_domid = domid;
> +            libxl__spawn_local_dm(egc, &dcs->dmss);
> +            return;
>          }
>          break;
>      }
> @@ -678,17 +712,41 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          goto error_out;
>      }
> 
> -    if (dm_starting) {
> +    assert(!dcs->dmss.guest_domid);
> +    domcreate_devmodel_started(egc, &dcs->dmss, 0);

This is actually logically the "else" of the preceding need_qemu if,
since all the other paths return before they get here. I spent quite a
while figuring out why the problem with the "return; break;" I mentioned
above was an extra break and not the return. Might be clearer to have
this in the else?

> +    return;
> +
> + error_out:
> +    assert(ret);
> +    domcreate_complete(egc, dcs, ret);
> +}
> +
> +static void domcreate_devmodel_started(libxl__egc *egc,
> +                                       libxl__dm_spawn_state *dmss,
> +                                       int ret)
> +{
[...]
> +}
> 
> -    return ret;
> +static void domcreate_complete(libxl__egc *egc,
> +                               libxl__domain_create_state *dcs,
> +                               int rc) {

{ should be on the next line.

> +    STATE_AO_GC(dcs->ao);
> +
> +    if (rc) {
> +        if (dcs->guest_domid) {
> +            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
> +            if (rc2)
> +                LOG(ERROR, "unable to destroy domain %d following"
> +                    " failed creation", dcs->guest_domid);
> +        }
> +        dcs->guest_domid = -1;
> +    }
> +    dcs->callback(egc, dcs, rc, dcs->guest_domid);
> +}
> +
> +/*----- application-facing domain creation interface -----*/
> +
[...]
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3921e2a..15472a8 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -667,24 +667,28 @@ retry_transaction:
>      return 0;
>  }
> 
> -static int libxl__create_stubdom(libxl__gc *gc,
> -                                 int guest_domid,
> -                                 libxl_domain_config *guest_config,
> -                                 libxl__domain_build_state *d_state,
> -                                 libxl__spawner_starting **starting_r)
> +static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
> +                                libxl__dm_spawn_state *stubdom_dmss,
> +                                int rc);
> +
> +void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state *sdss)
>  {
> +    STATE_AO_GC(sdss->stubdom.spawn.ao);
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
>      libxl__device_console *console;
> -    libxl_domain_config dm_config[1];
>      libxl_device_vfb vfb;
>      libxl_device_vkb vkb;
> -    libxl__domain_build_state stubdom_state[1];
> -    uint32_t dm_domid;
>      char **args;
>      struct xs_permissions perm[2];
>      xs_transaction_t t;
> -    libxl__spawner_starting *dm_starting = 0;
> +
> +    /* convenience aliases */
> +    libxl_domain_config *dm_config = &sdss->stubdom_config;
> +    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
> +    int guest_domid = sdss->stubdom.guest_domid;

const? Just in case someone tries to modify it? (maybe there are similar
cases in some of the previous blocks like this, I didn't notice).

[...]
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index 2ee2154..d44b702 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c

[...]
> +/*----- spawn implementation -----*/
[...]
> +int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
>  {
> +    STATE_AO_GC(ss->ao);
> +    int r;
> +    pid_t child;
>      int status, rc;

> +    libxl__spawn_init(ss);
> +    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
> +    libxl__ev_child_init(&ss->ssd->mid);
> +
> +    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
> +                                     spawn_timeout, ss->timeout_ms);
> +    if (rc) goto out_err;
> 
> +    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
> +                                    spawn_watch_event, ss->xspath);

IIRC xspath is optional, does libxl__ev_xswatch_register DTWT with NULL?

> +    if (rc) goto out_err;
> +
> +    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
> +    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
> +
> +    if (middle) {
>          /* parent */
>          return 1;
>      }
[...]

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index ae71f70..5bab4d6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h

> @@ -840,75 +840,197 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
>                                        libxl_device_pci *pcidev, int num);
>  _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
> 
> -/* xl_exec */
> +/*
> + *----- spawn -----
> + *
> + * Higher-level double-fork and separate detach eg as for device models
> + *
> + * Each libxl__spawn_state is in one of the conventional states
> + *    Undefined, Idle, Active

Conventional here means "as per event generation" I assume.

[...]
>  /*
> - * libxl__spawn_spawn - Create a new process
> - * gc: allocation pool
> - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
> - * what: string describing the spawned process
> - * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
> - * hook_data: data to pass to the hook function
> + * libxl__spawn_spawn - Create a new process which will become daemonic
> + * Forks twice, to allow the child to detach entirely from the parent.
> + *
> + * We call the two generated processes the "middle child" (result of
> + * the first fork) and the "inner child" (result of the second fork
> + * which takes place in the middle child).
> + *
> + * The inner child must soon exit or exec.  If must also soon exit or

                                               It?

> + * notify the parent of its successful startup by writing to the
> + * xenstore path xspath (or by other means).  xspath may be 0 to
> + * indicate that only other means are being used.
> + *
> + * The user (in the parent) will be called back (confirm_cb) every
> + * time that xenstore path is modified.
> + *
> + * In both children, the ctx is not fully useable: gc and logging

                                             usable

(apparently, I'm not convinced actually)

> + * operations are OK, but operations on Xen and xenstore are not.
> + * (The restrictions are the same as those which apply to children
> + * made with libxl__ev_child_fork.)
> + *
> + * midproc_cb will be called in the middle child, with the pid of the
> + * inner child; this could for example record the pid.  midproc_cb
> + * should be fast, and should return.  It will be called (reentrantly)
> + * within libxl__spawn_init.
> + *
> + * failure_cb will be called in the parent on failure of the
> + * intermediate or final child; an error message will have been
> + * logged.
> + *
> + * confirm_cb and failure_cb will not be called reentrantly from
> + * within libxl__spawn_spawn.
> + *
> + * what: string describing the spawned process, used for logging
>   *
>   * Logs errors.  A copy of "what" is taken.
>   * Return values:
> - *  < 0   error, for_spawn need not be detached
> - *   +1   caller is the parent, must call detach on *for_spawn eventually
> + *  < 0   error, *spawn is now Idle and need not be detached
> + *   +1   caller is the parent, *spawn is Active and must eventually be detached
>   *    0   caller is now the inner child, should probably call libxl__exec

... or libxl_postfork_child_noexec.

> - * Caller, may pass 0 for for_spawn, in which case no need to detach.
> + *
> + * The spawn state must be Undefined or Idle on entry.
>   */
> -_hidden int libxl__spawn_spawn(libxl__gc *gc,
> -                      libxl__spawn_starting *for_spawn,
> -                      const char *what,
> -                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
> -                      void *hook_data);
> +_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
> 
>  /*
> - * libxl_spawner_record_pid - Record given pid in xenstore
> - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
> - * innerchild: pid of the child
> + * libxl__spawn_detach - Detaches the daemonic child.
> + *
> + * Works by killing the intermediate process from spawn_spawn.
> + * After this function returns, failures of either child are no
> + * longer repaorted via failure_cb.

             reported

[...]

> +/*----- device model creation -----*/
> +
> +/* First layer; wraps libxl__spawn_spawn. */

The use of "First" here is terrifying to me as a reviewer ;-P

> +
> +typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
> +
> +typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
> +                                int rc /* if !0, error was logged */);
> +
> +struct libxl__dm_spawn_state {
> +    /* mixed - ao must be initialised by user; rest is private: */

I see no ao here, you mean spawn.ao?

> +    libxl__spawn_state spawn;
> +    /* filled in by user, must remain valid: */
> +    uint32_t guest_domid; /* domain being served */
> +    libxl_domain_config *guest_config;
> +    libxl__domain_build_state *build_state; /* relates to guest_domid */
> +    libxl__dm_spawn_cb *callback;
> +};
> +
> +_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);


> +
> +/* Stubdoms. */
> +
> +typedef struct {
> +    /* mixed - user must fill in public parts only: */
> +    libxl__dm_spawn_state stubdom; /* will always remain the first member */

why? If you are playing casting tricks then you could use CONTAINER_OF.

> +    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->stubdom,) */
> +    /* private to libxl__spawn_stubdom: */
> +    libxl_domain_config stubdom_config;
> +    libxl__domain_build_state stubdom_state;
> +    libxl__dm_spawn_state pvqemu;
> +} libxl__stubdom_spawn_state;
> +
> +_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
> +

Ah, I see now what local_dm meant, it's the non-stubdom DM.

stubdom is a bit of an overloaded term (we have grub stubdoms, xenstore
stubdoms etc too). stub_dm would be better.

> 
>  /*
>   * libxl__wait_for_offspring - Wait for child state
> @@ -941,31 +1063,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
[...]

> @@ -1566,6 +1650,32 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
>  _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
> 
> 
> +/*----- Domain creation -----*/
> +
> +typedef struct libxl__domain_create_state libxl__domain_create_state;
> +
> +typedef void libxl__domain_create_cb(libxl__egc *egc,
> +                                     libxl__domain_create_state*,
> +                                     int rc, uint32_t domid);
> +
> +struct libxl__domain_create_state {
> +    /* filled in by user */
> +    libxl__ao *ao;
> +    libxl_domain_config *guest_config;
> +    int restore_fd;
> +    libxl_console_ready console_cb;
> +    void *console_cb_priv;
> +    libxl__domain_create_cb *callback;
> +    /* private to domain_create */
> +    int guest_domid;
> +    libxl__domain_build_state build_state;
> +    union {
> +        libxl__dm_spawn_state dmss;
> +        libxl__stubdom_spawn_state sdss;
> +    };
> +};
> +
> +
>  /*
>   * Convenience macros.
>   */

Right, back to the top to start on the implementation...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:17:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKA9o-0007ss-4t; Tue, 17 Apr 2012 15:17:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKA9m-0007sn-47
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:17:26 +0000
Received: from [193.109.254.147:11121] by server-10.bemta-14.messagelabs.com
	id A2/15-05847-5898D8F4; Tue, 17 Apr 2012 15:17:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334675844!5037336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11000 invoked from network); 17 Apr 2012 15:17:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:17:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:17:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 16:17:24 +0100
Message-ID: <1334675843.23948.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 16:17:23 +0100
In-Reply-To: <1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Neither this patch nor the rest of the series seems to handle the long
running nature of xc_domain_restore, is that expected at this stage?

We discussed a similar thing in the context of xc_domain_save, and I
expect the required scaffolding (bumping an op over into a thread) will
be the same on both sides?

On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> libxl__spawn_spawn becomes a callback-style asynchronous function.
> The implementation is now in terms of libxl__ev_* including
> libxl_ev_child.
> 
> All the callers need to be updated.  This includes the device model
> spawning functions libxl__create_device_model and
> libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
> and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
> abolished; instead the dm spawner calls back.
> 
> (The choice of which kind of device model to create is lifted out of
> what used to be libxl__create_device_model, because that function was
> indirectly recursive.  Recursive callback-style operations are clumsy
> because they require a pointer indirection for the nested states.)
> 
> Waiting for proper device model startup it is no longer notionally
> optional.  Previously the code appeared to tolerate this by passing
> NULL for various libxl__spawner_starting* parameters to device model
> spawners.  However, this was not used anywhere.
> 
> Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
> no longer supported.  It remains as an unused formal parameter to
> avoid updating, in this patch, all the call sites which pass NULL.
> libxl__wait_for_offspring is in any case itself an obsolete function,
> so this wrinkle will go away when its callers are updated to use the
> event system.  Consequently libxl__spawn_check is also abolished.
> 
> The "console ready" callback also remains unchanged in this patch.
> The API for this needs to be reviewed in the context of the event
> series and its reentrancy restrictions documented.
> 
> Thus their callers need to be updated.  These are the domain creation
> functions libxl_domain_create_new and _restore.  These functions now
> take ao_hows, and have a private state structure.
> 
> However domain creation remains not completely converted to the event
> mechanism; in particular it runs the outward-facing function
> libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
> happens in the current code this is not a bug because none of the rest
> of the functionality surrounding the bootloader call will mind if the
> event loop is reentered in the middle of its execution.
> 
> The file-scope function libxl__set_fd_flag which was used by the
> previous spawn arrangements becomes unused and is removed; other
> places in libxl can use libxl_fd_set_nonblock and
> libxl_fd_set_cloexec, which of course remain.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.h          |   14 ++-
>  tools/libxl/libxl_create.c   |  198 +++++++++++++++++++-----
>  tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
>  tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
>  tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
>  tools/libxl/xl_cmdimpl.c     |    6 +-
>  6 files changed, 677 insertions(+), 400 deletions(-)

(nb: I actually skipped ahead and reviewed the libxl_internal.h change
first so I could read the docs, if only diff could be taught such
things ;-))

> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 477b72a..6f59364 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
> 
>  /* domain related functions */
>  typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> -int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> -int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
> +  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
> +   * properties need to be documented but they may turn out to be too
> +   * awkward */

The reentrancy concerns here relate to the "cb" or to something else?

[...]
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 8408c26..09a03a7 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -537,16 +537,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,

[...]

> @@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc,
> libxl_domain_config *d_config,
>          libxl_device_vkb_add(ctx, domid, &vkb);
>          libxl_device_vkb_dispose(&vkb);
> [...]
> +        dcs->dmss.guest_domid = domid;

dcs->dmss is part of a union with dcs->sdss. I'd rather this was done
inside the if once we've committed to one or the other, IYSWIM.

Actually the hunk above (which I've trimmed already, sorry) also
initialised dmss unconditionally.

(does sdss really not need guest_domid somewhere too? odd)

> +        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
> +            libxl__spawn_stubdom(egc, &dcs->sdss);
> +        else
> +            libxl__spawn_local_dm(egc, &dcs->dmss);
> +        return;
> +
>          break;

return then break? I think the break is redundant.

>      }
>      case LIBXL_DOMAIN_TYPE_PV:
> @@ -669,7 +701,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          libxl__device_console_dispose(&console);
> 
>          if (need_qemu) {
> -            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
> +            dcs->dmss.guest_domid = domid;
> +            libxl__spawn_local_dm(egc, &dcs->dmss);
> +            return;
>          }
>          break;
>      }
> @@ -678,17 +712,41 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          goto error_out;
>      }
> 
> -    if (dm_starting) {
> +    assert(!dcs->dmss.guest_domid);
> +    domcreate_devmodel_started(egc, &dcs->dmss, 0);

This is actually logically the "else" of the preceding need_qemu if,
since all the other paths return before they get here. I spent quite a
while figuring out why the problem with the "return; break;" I mentioned
above was an extra break and not the return. Might be clearer to have
this in the else?

> +    return;
> +
> + error_out:
> +    assert(ret);
> +    domcreate_complete(egc, dcs, ret);
> +}
> +
> +static void domcreate_devmodel_started(libxl__egc *egc,
> +                                       libxl__dm_spawn_state *dmss,
> +                                       int ret)
> +{
[...]
> +}
> 
> -    return ret;
> +static void domcreate_complete(libxl__egc *egc,
> +                               libxl__domain_create_state *dcs,
> +                               int rc) {

{ should be on the next line.

> +    STATE_AO_GC(dcs->ao);
> +
> +    if (rc) {
> +        if (dcs->guest_domid) {
> +            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
> +            if (rc2)
> +                LOG(ERROR, "unable to destroy domain %d following"
> +                    " failed creation", dcs->guest_domid);
> +        }
> +        dcs->guest_domid = -1;
> +    }
> +    dcs->callback(egc, dcs, rc, dcs->guest_domid);
> +}
> +
> +/*----- application-facing domain creation interface -----*/
> +
[...]
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3921e2a..15472a8 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -667,24 +667,28 @@ retry_transaction:
>      return 0;
>  }
> 
> -static int libxl__create_stubdom(libxl__gc *gc,
> -                                 int guest_domid,
> -                                 libxl_domain_config *guest_config,
> -                                 libxl__domain_build_state *d_state,
> -                                 libxl__spawner_starting **starting_r)
> +static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
> +                                libxl__dm_spawn_state *stubdom_dmss,
> +                                int rc);
> +
> +void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state *sdss)
>  {
> +    STATE_AO_GC(sdss->stubdom.spawn.ao);
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
>      libxl__device_console *console;
> -    libxl_domain_config dm_config[1];
>      libxl_device_vfb vfb;
>      libxl_device_vkb vkb;
> -    libxl__domain_build_state stubdom_state[1];
> -    uint32_t dm_domid;
>      char **args;
>      struct xs_permissions perm[2];
>      xs_transaction_t t;
> -    libxl__spawner_starting *dm_starting = 0;
> +
> +    /* convenience aliases */
> +    libxl_domain_config *dm_config = &sdss->stubdom_config;
> +    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
> +    int guest_domid = sdss->stubdom.guest_domid;

const? Just in case someone tries to modify it? (maybe there are similar
cases in some of the previous blocks like this, I didn't notice).

[...]
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index 2ee2154..d44b702 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c

[...]
> +/*----- spawn implementation -----*/
[...]
> +int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
>  {
> +    STATE_AO_GC(ss->ao);
> +    int r;
> +    pid_t child;
>      int status, rc;

> +    libxl__spawn_init(ss);
> +    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
> +    libxl__ev_child_init(&ss->ssd->mid);
> +
> +    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
> +                                     spawn_timeout, ss->timeout_ms);
> +    if (rc) goto out_err;
> 
> +    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
> +                                    spawn_watch_event, ss->xspath);

IIRC xspath is optional, does libxl__ev_xswatch_register DTWT with NULL?

> +    if (rc) goto out_err;
> +
> +    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
> +    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
> +
> +    if (middle) {
>          /* parent */
>          return 1;
>      }
[...]

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index ae71f70..5bab4d6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h

> @@ -840,75 +840,197 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
>                                        libxl_device_pci *pcidev, int num);
>  _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
> 
> -/* xl_exec */
> +/*
> + *----- spawn -----
> + *
> + * Higher-level double-fork and separate detach eg as for device models
> + *
> + * Each libxl__spawn_state is in one of the conventional states
> + *    Undefined, Idle, Active

Conventional here means "as per event generation" I assume.

[...]
>  /*
> - * libxl__spawn_spawn - Create a new process
> - * gc: allocation pool
> - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
> - * what: string describing the spawned process
> - * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
> - * hook_data: data to pass to the hook function
> + * libxl__spawn_spawn - Create a new process which will become daemonic
> + * Forks twice, to allow the child to detach entirely from the parent.
> + *
> + * We call the two generated processes the "middle child" (result of
> + * the first fork) and the "inner child" (result of the second fork
> + * which takes place in the middle child).
> + *
> + * The inner child must soon exit or exec.  If must also soon exit or

                                               It?

> + * notify the parent of its successful startup by writing to the
> + * xenstore path xspath (or by other means).  xspath may be 0 to
> + * indicate that only other means are being used.
> + *
> + * The user (in the parent) will be called back (confirm_cb) every
> + * time that xenstore path is modified.
> + *
> + * In both children, the ctx is not fully useable: gc and logging

                                             usable

(apparently, I'm not convinced actually)

> + * operations are OK, but operations on Xen and xenstore are not.
> + * (The restrictions are the same as those which apply to children
> + * made with libxl__ev_child_fork.)
> + *
> + * midproc_cb will be called in the middle child, with the pid of the
> + * inner child; this could for example record the pid.  midproc_cb
> + * should be fast, and should return.  It will be called (reentrantly)
> + * within libxl__spawn_init.
> + *
> + * failure_cb will be called in the parent on failure of the
> + * intermediate or final child; an error message will have been
> + * logged.
> + *
> + * confirm_cb and failure_cb will not be called reentrantly from
> + * within libxl__spawn_spawn.
> + *
> + * what: string describing the spawned process, used for logging
>   *
>   * Logs errors.  A copy of "what" is taken.
>   * Return values:
> - *  < 0   error, for_spawn need not be detached
> - *   +1   caller is the parent, must call detach on *for_spawn eventually
> + *  < 0   error, *spawn is now Idle and need not be detached
> + *   +1   caller is the parent, *spawn is Active and must eventually be detached
>   *    0   caller is now the inner child, should probably call libxl__exec

... or libxl_postfork_child_noexec.

> - * Caller, may pass 0 for for_spawn, in which case no need to detach.
> + *
> + * The spawn state must be Undefined or Idle on entry.
>   */
> -_hidden int libxl__spawn_spawn(libxl__gc *gc,
> -                      libxl__spawn_starting *for_spawn,
> -                      const char *what,
> -                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
> -                      void *hook_data);
> +_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
> 
>  /*
> - * libxl_spawner_record_pid - Record given pid in xenstore
> - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
> - * innerchild: pid of the child
> + * libxl__spawn_detach - Detaches the daemonic child.
> + *
> + * Works by killing the intermediate process from spawn_spawn.
> + * After this function returns, failures of either child are no
> + * longer repaorted via failure_cb.

             reported

[...]

> +/*----- device model creation -----*/
> +
> +/* First layer; wraps libxl__spawn_spawn. */

The use of "First" here is terrifying to me as a reviewer ;-P

> +
> +typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
> +
> +typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
> +                                int rc /* if !0, error was logged */);
> +
> +struct libxl__dm_spawn_state {
> +    /* mixed - ao must be initialised by user; rest is private: */

I see no ao here, you mean spawn.ao?

> +    libxl__spawn_state spawn;
> +    /* filled in by user, must remain valid: */
> +    uint32_t guest_domid; /* domain being served */
> +    libxl_domain_config *guest_config;
> +    libxl__domain_build_state *build_state; /* relates to guest_domid */
> +    libxl__dm_spawn_cb *callback;
> +};
> +
> +_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);


> +
> +/* Stubdoms. */
> +
> +typedef struct {
> +    /* mixed - user must fill in public parts only: */
> +    libxl__dm_spawn_state stubdom; /* will always remain the first member */

why? If you are playing casting tricks then you could use CONTAINER_OF.

> +    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->stubdom,) */
> +    /* private to libxl__spawn_stubdom: */
> +    libxl_domain_config stubdom_config;
> +    libxl__domain_build_state stubdom_state;
> +    libxl__dm_spawn_state pvqemu;
> +} libxl__stubdom_spawn_state;
> +
> +_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
> +

Ah, I see now what local_dm meant, it's the non-stubdom DM.

stubdom is a bit of an overloaded term (we have grub stubdoms, xenstore
stubdoms etc too). stub_dm would be better.

> 
>  /*
>   * libxl__wait_for_offspring - Wait for child state
> @@ -941,31 +1063,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
[...]

> @@ -1566,6 +1650,32 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
>  _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
> 
> 
> +/*----- Domain creation -----*/
> +
> +typedef struct libxl__domain_create_state libxl__domain_create_state;
> +
> +typedef void libxl__domain_create_cb(libxl__egc *egc,
> +                                     libxl__domain_create_state*,
> +                                     int rc, uint32_t domid);
> +
> +struct libxl__domain_create_state {
> +    /* filled in by user */
> +    libxl__ao *ao;
> +    libxl_domain_config *guest_config;
> +    int restore_fd;
> +    libxl_console_ready console_cb;
> +    void *console_cb_priv;
> +    libxl__domain_create_cb *callback;
> +    /* private to domain_create */
> +    int guest_domid;
> +    libxl__domain_build_state build_state;
> +    union {
> +        libxl__dm_spawn_state dmss;
> +        libxl__stubdom_spawn_state sdss;
> +    };
> +};
> +
> +
>  /*
>   * Convenience macros.
>   */

Right, back to the top to start on the implementation...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:20:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKACZ-0007zt-2X; Tue, 17 Apr 2012 15:20:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1SKACY-0007zn-8e
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 15:20:18 +0000
Received: from [85.158.143.99:54685] by server-2.bemta-4.messagelabs.com id
	BC/68-17550-13A8D8F4; Tue, 17 Apr 2012 15:20:17 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334676013!23991516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6576 invoked from network); 17 Apr 2012 15:20:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:20:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190741964"
Received: from sjcpmailmx01.citrite.net ([10.216.14.74])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:19:24 -0400
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by
	SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Tue, 17 Apr 2012
	08:19:22 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	AP <apxeng@gmail.com>
Date: Tue, 17 Apr 2012 08:19:14 -0700
Thread-Topic: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
Thread-Index: Ac0cb5PNPzvKDJkJQHOBS+S7RsO5cAAPXJ+w
Message-ID: <7914B38A4445B34AA16EB9F1352942F1010A2049CE76@SJCPMAILBOX01.citrite.net>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
	<4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
In-Reply-To: <4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I only cared about linux_gnttab_grant_map for user mode blkback. You told me to change all others while I was in there.

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Tuesday, April 17, 2012 12:56 AM
To: Ian Campbell; AP
Cc: Santosh Jodh; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing segfault

>>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> On xen-unstable 25164:5bbda657a016, when I try to map in large 
>> amounts of pages (in the GB range) from a guest in to Dom0
> 
> Out of interest -- what are you doing this for?
> 
>>  using
>> xc_map_foreign_bulk() I am hitting a segfault.
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
>> (gdb) bt
>> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>>     err=<optimized out>, num=<optimized out>) at 
>> xc_foreign_memory.c:79
>> 
>> This was working for me with Xen 4.1.2. On comparing
>> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see 
>> that the pfn array in linux_privcmd_map_foreign_bulk() is being 
>> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am 
>> blowing the stack with the call.
> 
> I bet this is due to Linux's stack guard page. This means that if you 
> try and increase the stack by more than ~1 page you skip entirely over 
> the "next" stack page and into the guard.
> 
> Does it help if after the alloca you add a loop which touches the 
> first word of each page of the new buffer? Since the stack grows down 
> you might actually need to do it backwards from the end of the array 
> in order to start at the end which is nearest the existing stack? 
> (it's before coffee o'clock so thinking about stack direction isn't my 
> strong point yet...)

This should really be done by the alloca() implementation itself - anything else is a bug.

> The switch to alloca was made recently in order to optimise the 
> hotpath for a userspace I/O backend.

Probably this should be made size-dependent ...

> BTW, Santosh, it didn't occur to me at the time but what is privcmd 
> mmap doing on the hot path for the userspace I/O anyway? Most hotpath 
> operations should really be grant table ops, a backend shouldn't be 
> relying on the privileges accorded to dom0 -- for one thing it should 
> be expected to work in a driver domain.

... if this indeed turns out to be a hot path for something at all?

Jan

>>  If I replace the alloca() with malloc() the call goes through. What 
>> is the way around this? Should I be using
>> xc_map_foreign_batch() instead, which I think is deprecated? Please 
>> advice...
>> 
>> Thanks,
>> AP
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:20:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKACZ-0007zt-2X; Tue, 17 Apr 2012 15:20:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1SKACY-0007zn-8e
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 15:20:18 +0000
Received: from [85.158.143.99:54685] by server-2.bemta-4.messagelabs.com id
	BC/68-17550-13A8D8F4; Tue, 17 Apr 2012 15:20:17 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334676013!23991516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6576 invoked from network); 17 Apr 2012 15:20:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:20:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190741964"
Received: from sjcpmailmx01.citrite.net ([10.216.14.74])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:19:24 -0400
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by
	SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Tue, 17 Apr 2012
	08:19:22 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	AP <apxeng@gmail.com>
Date: Tue, 17 Apr 2012 08:19:14 -0700
Thread-Topic: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
Thread-Index: Ac0cb5PNPzvKDJkJQHOBS+S7RsO5cAAPXJ+w
Message-ID: <7914B38A4445B34AA16EB9F1352942F1010A2049CE76@SJCPMAILBOX01.citrite.net>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
	<4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
In-Reply-To: <4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I only cared about linux_gnttab_grant_map for user mode blkback. You told me to change all others while I was in there.

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Tuesday, April 17, 2012 12:56 AM
To: Ian Campbell; AP
Cc: Santosh Jodh; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing segfault

>>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> On xen-unstable 25164:5bbda657a016, when I try to map in large 
>> amounts of pages (in the GB range) from a guest in to Dom0
> 
> Out of interest -- what are you doing this for?
> 
>>  using
>> xc_map_foreign_bulk() I am hitting a segfault.
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
>> (gdb) bt
>> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>>     err=0x7ffff67f4010, num=<optimized out>)
>>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>>     err=<optimized out>, num=<optimized out>) at 
>> xc_foreign_memory.c:79
>> 
>> This was working for me with Xen 4.1.2. On comparing
>> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see 
>> that the pfn array in linux_privcmd_map_foreign_bulk() is being 
>> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am 
>> blowing the stack with the call.
> 
> I bet this is due to Linux's stack guard page. This means that if you 
> try and increase the stack by more than ~1 page you skip entirely over 
> the "next" stack page and into the guard.
> 
> Does it help if after the alloca you add a loop which touches the 
> first word of each page of the new buffer? Since the stack grows down 
> you might actually need to do it backwards from the end of the array 
> in order to start at the end which is nearest the existing stack? 
> (it's before coffee o'clock so thinking about stack direction isn't my 
> strong point yet...)

This should really be done by the alloca() implementation itself - anything else is a bug.

> The switch to alloca was made recently in order to optimise the 
> hotpath for a userspace I/O backend.

Probably this should be made size-dependent ...

> BTW, Santosh, it didn't occur to me at the time but what is privcmd 
> mmap doing on the hot path for the userspace I/O anyway? Most hotpath 
> operations should really be grant table ops, a backend shouldn't be 
> relying on the privileges accorded to dom0 -- for one thing it should 
> be expected to work in a driver domain.

... if this indeed turns out to be a hot path for something at all?

Jan

>>  If I replace the alloca() with malloc() the call goes through. What 
>> is the way around this? Should I be using
>> xc_map_foreign_batch() instead, which I think is deprecated? Please 
>> advice...
>> 
>> Thanks,
>> AP
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAKC-0008EC-7t; Tue, 17 Apr 2012 15:28:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKAKA-0008E4-4V
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 15:28:10 +0000
Received: from [85.158.143.99:42660] by server-1.bemta-4.messagelabs.com id
	A1/DD-20925-90C8D8F4; Tue, 17 Apr 2012 15:28:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334676487!14404452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21356 invoked from network); 17 Apr 2012 15:28:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:28:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:28:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 16:28:06 +0100
Message-ID: <1334676485.23948.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>
Date: Tue, 17 Apr 2012 16:28:05 +0100
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1010A2049CE76@SJCPMAILBOX01.citrite.net>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
	<4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
	<7914B38A4445B34AA16EB9F1352942F1010A2049CE76@SJCPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
> I only cared about linux_gnttab_grant_map for user mode blkback. You
> told me to change all others while I was in there.

Oh, right, I remember now.

Given that reverting it for this case will still leave the same issue
for the grant case (which I'd forgotten about) I suppose the appropriate
workaround is to touch the alloca'd memory in the appropriate order in
all cases (perhaps with an alloca helper macro).

Ian.

> 
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com] 
> Sent: Tuesday, April 17, 2012 12:56 AM
> To: Ian Campbell; AP
> Cc: Santosh Jodh; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing segfault
> 
> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
> >> On xen-unstable 25164:5bbda657a016, when I try to map in large 
> >> amounts of pages (in the GB range) from a guest in to Dom0
> > 
> > Out of interest -- what are you doing this for?
> > 
> >>  using
> >> xc_map_foreign_bulk() I am hitting a segfault.
> >> 
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
> >>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
> >>     err=0x7ffff67f4010, num=<optimized out>)
> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> >> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> >> (gdb) bt
> >> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
> >>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
> >>     err=0x7ffff67f4010, num=<optimized out>)
> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> >> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
> >>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
> >>     err=<optimized out>, num=<optimized out>) at 
> >> xc_foreign_memory.c:79
> >> 
> >> This was working for me with Xen 4.1.2. On comparing
> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see 
> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being 
> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am 
> >> blowing the stack with the call.
> > 
> > I bet this is due to Linux's stack guard page. This means that if you 
> > try and increase the stack by more than ~1 page you skip entirely over 
> > the "next" stack page and into the guard.
> > 
> > Does it help if after the alloca you add a loop which touches the 
> > first word of each page of the new buffer? Since the stack grows down 
> > you might actually need to do it backwards from the end of the array 
> > in order to start at the end which is nearest the existing stack? 
> > (it's before coffee o'clock so thinking about stack direction isn't my 
> > strong point yet...)
> 
> This should really be done by the alloca() implementation itself - anything else is a bug.
> 
> > The switch to alloca was made recently in order to optimise the 
> > hotpath for a userspace I/O backend.
> 
> Probably this should be made size-dependent ...
> 
> > BTW, Santosh, it didn't occur to me at the time but what is privcmd 
> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath 
> > operations should really be grant table ops, a backend shouldn't be 
> > relying on the privileges accorded to dom0 -- for one thing it should 
> > be expected to work in a driver domain.
> 
> ... if this indeed turns out to be a hot path for something at all?
> 
> Jan
> 
> >>  If I replace the alloca() with malloc() the call goes through. What 
> >> is the way around this? Should I be using
> >> xc_map_foreign_batch() instead, which I think is deprecated? Please 
> >> advice...
> >> 
> >> Thanks,
> >> AP
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAKC-0008EC-7t; Tue, 17 Apr 2012 15:28:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKAKA-0008E4-4V
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 15:28:10 +0000
Received: from [85.158.143.99:42660] by server-1.bemta-4.messagelabs.com id
	A1/DD-20925-90C8D8F4; Tue, 17 Apr 2012 15:28:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334676487!14404452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21356 invoked from network); 17 Apr 2012 15:28:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:28:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:28:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 16:28:06 +0100
Message-ID: <1334676485.23948.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>
Date: Tue, 17 Apr 2012 16:28:05 +0100
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1010A2049CE76@SJCPMAILBOX01.citrite.net>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
	<4F8D3E3F020000780007E66A@nat28.tlf.novell.com>
	<7914B38A4445B34AA16EB9F1352942F1010A2049CE76@SJCPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
 segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
> I only cared about linux_gnttab_grant_map for user mode blkback. You
> told me to change all others while I was in there.

Oh, right, I remember now.

Given that reverting it for this case will still leave the same issue
for the grant case (which I'd forgotten about) I suppose the appropriate
workaround is to touch the alloca'd memory in the appropriate order in
all cases (perhaps with an alloca helper macro).

Ian.

> 
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com] 
> Sent: Tuesday, April 17, 2012 12:56 AM
> To: Ian Campbell; AP
> Cc: Santosh Jodh; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing segfault
> 
> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
> >> On xen-unstable 25164:5bbda657a016, when I try to map in large 
> >> amounts of pages (in the GB range) from a guest in to Dom0
> > 
> > Out of interest -- what are you doing this for?
> > 
> >>  using
> >> xc_map_foreign_bulk() I am hitting a segfault.
> >> 
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
> >>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
> >>     err=0x7ffff67f4010, num=<optimized out>)
> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> >> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> >> (gdb) bt
> >> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
> >>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
> >>     err=0x7ffff67f4010, num=<optimized out>)
> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> >> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
> >>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
> >>     err=<optimized out>, num=<optimized out>) at 
> >> xc_foreign_memory.c:79
> >> 
> >> This was working for me with Xen 4.1.2. On comparing
> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see 
> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being 
> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am 
> >> blowing the stack with the call.
> > 
> > I bet this is due to Linux's stack guard page. This means that if you 
> > try and increase the stack by more than ~1 page you skip entirely over 
> > the "next" stack page and into the guard.
> > 
> > Does it help if after the alloca you add a loop which touches the 
> > first word of each page of the new buffer? Since the stack grows down 
> > you might actually need to do it backwards from the end of the array 
> > in order to start at the end which is nearest the existing stack? 
> > (it's before coffee o'clock so thinking about stack direction isn't my 
> > strong point yet...)
> 
> This should really be done by the alloca() implementation itself - anything else is a bug.
> 
> > The switch to alloca was made recently in order to optimise the 
> > hotpath for a userspace I/O backend.
> 
> Probably this should be made size-dependent ...
> 
> > BTW, Santosh, it didn't occur to me at the time but what is privcmd 
> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath 
> > operations should really be grant table ops, a backend shouldn't be 
> > relying on the privileges accorded to dom0 -- for one thing it should 
> > be expected to work in a driver domain.
> 
> ... if this indeed turns out to be a hot path for something at all?
> 
> Jan
> 
> >>  If I replace the alloca() with malloc() the call goes through. What 
> >> is the way around this? Should I be using
> >> xc_map_foreign_batch() instead, which I think is deprecated? Please 
> >> advice...
> >> 
> >> Thanks,
> >> AP
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:31:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKANR-0008KX-TG; Tue, 17 Apr 2012 15:31:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKANQ-0008KP-Eu
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:31:32 +0000
Received: from [85.158.138.51:63226] by server-10.bemta-3.messagelabs.com id
	B4/B8-29478-3DC8D8F4; Tue, 17 Apr 2012 15:31:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334676690!22576932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17515 invoked from network); 17 Apr 2012 15:31:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:31:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:30:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 16:30:54 +0100
Message-ID: <1334676652.23948.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 17 Apr 2012 16:30:52 +0100
In-Reply-To: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
> Currently `xl vncviewer $dom` does not work because the VNC port is not
> registered in xenstore when using qemu-upstream. This patch attempted to fix
> this.

libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
having such a thing in xenstore strikes me as something of a
misfeature...

Otherwise: 
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> ---
>  tools/libxl/libxl_qmp.c |   59 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 59 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index f5a3edc..72ff4a4 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -154,6 +154,55 @@ static int register_serials_chardev_callback(libxl__qmp_handler *qmp,
>      return ret;
>  }
>  
> +static int qmp_write_domain_console_item(libxl__gc *gc, int domid,
> +                                         const char *item, const char *value)
> +{
> +    char *path;
> +
> +    path = libxl__xs_get_dompath(gc, domid);
> +    path = libxl__sprintf(gc, "%s/console/%s", path, item);
> +
> +    return libxl__xs_write(gc, XBT_NULL, path, "%s", value);
> +}
> +
> +static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
> +                                     const libxl__json_object *o,
> +                                     void *unused)
> +{
> +    GC_INIT(qmp->ctx);
> +    const libxl__json_object *obj;
> +    const char *listen, *port;
> +    int rc = -1;
> +
> +    if (!libxl__json_object_is_map(o)) {
> +        goto out;
> +    }
> +
> +    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    obj = libxl__json_map_get("host", o, JSON_STRING);
> +    listen = libxl__json_object_get_string(obj);
> +    obj = libxl__json_map_get("service", o, JSON_STRING);
> +    port = libxl__json_object_get_string(obj);
> +
> +    if (!listen || !port) {
> +        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
> +                   "Failed to retreive VNC connect information.");
> +        goto out;
> +    }
> +
> +    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
> +    if (!rc)
> +        rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
> +
> +out:
> +    GC_FREE;
> +    return rc;
> +}
> +
>  static int qmp_capabilities_callback(libxl__qmp_handler *qmp,
>                                       const libxl__json_object *o, void *unused)
>  {
> @@ -688,6 +737,13 @@ int libxl__qmp_query_serial(libxl__qmp_handler *qmp)
>                                  NULL, qmp->timeout);
>  }
>  
> +static int qmp_query_vnc(libxl__qmp_handler *qmp)
> +{
> +    return qmp_synchronous_send(qmp, "query-vnc", NULL,
> +                                qmp_register_vnc_callback,
> +                                NULL, qmp->timeout);
> +}
> +
>  static int pci_add_callback(libxl__qmp_handler *qmp,
>                              const libxl__json_object *response, void *opaque)
>  {
> @@ -917,6 +973,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
>      if (!ret && vnc && vnc->passwd) {
>          ret = qmp_change(gc, qmp, "vnc", "password", vnc->passwd);
>      }
> +    if (!ret) {
> +        ret = qmp_query_vnc(qmp);
> +    }
>      libxl__qmp_close(qmp);
>      return ret;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:31:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKANR-0008KX-TG; Tue, 17 Apr 2012 15:31:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKANQ-0008KP-Eu
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:31:32 +0000
Received: from [85.158.138.51:63226] by server-10.bemta-3.messagelabs.com id
	B4/B8-29478-3DC8D8F4; Tue, 17 Apr 2012 15:31:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334676690!22576932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17515 invoked from network); 17 Apr 2012 15:31:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:31:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:30:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 16:30:54 +0100
Message-ID: <1334676652.23948.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 17 Apr 2012 16:30:52 +0100
In-Reply-To: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
> Currently `xl vncviewer $dom` does not work because the VNC port is not
> registered in xenstore when using qemu-upstream. This patch attempted to fix
> this.

libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
having such a thing in xenstore strikes me as something of a
misfeature...

Otherwise: 
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> ---
>  tools/libxl/libxl_qmp.c |   59 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 59 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index f5a3edc..72ff4a4 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -154,6 +154,55 @@ static int register_serials_chardev_callback(libxl__qmp_handler *qmp,
>      return ret;
>  }
>  
> +static int qmp_write_domain_console_item(libxl__gc *gc, int domid,
> +                                         const char *item, const char *value)
> +{
> +    char *path;
> +
> +    path = libxl__xs_get_dompath(gc, domid);
> +    path = libxl__sprintf(gc, "%s/console/%s", path, item);
> +
> +    return libxl__xs_write(gc, XBT_NULL, path, "%s", value);
> +}
> +
> +static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
> +                                     const libxl__json_object *o,
> +                                     void *unused)
> +{
> +    GC_INIT(qmp->ctx);
> +    const libxl__json_object *obj;
> +    const char *listen, *port;
> +    int rc = -1;
> +
> +    if (!libxl__json_object_is_map(o)) {
> +        goto out;
> +    }
> +
> +    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    obj = libxl__json_map_get("host", o, JSON_STRING);
> +    listen = libxl__json_object_get_string(obj);
> +    obj = libxl__json_map_get("service", o, JSON_STRING);
> +    port = libxl__json_object_get_string(obj);
> +
> +    if (!listen || !port) {
> +        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
> +                   "Failed to retreive VNC connect information.");
> +        goto out;
> +    }
> +
> +    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
> +    if (!rc)
> +        rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
> +
> +out:
> +    GC_FREE;
> +    return rc;
> +}
> +
>  static int qmp_capabilities_callback(libxl__qmp_handler *qmp,
>                                       const libxl__json_object *o, void *unused)
>  {
> @@ -688,6 +737,13 @@ int libxl__qmp_query_serial(libxl__qmp_handler *qmp)
>                                  NULL, qmp->timeout);
>  }
>  
> +static int qmp_query_vnc(libxl__qmp_handler *qmp)
> +{
> +    return qmp_synchronous_send(qmp, "query-vnc", NULL,
> +                                qmp_register_vnc_callback,
> +                                NULL, qmp->timeout);
> +}
> +
>  static int pci_add_callback(libxl__qmp_handler *qmp,
>                              const libxl__json_object *response, void *opaque)
>  {
> @@ -917,6 +973,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
>      if (!ret && vnc && vnc->passwd) {
>          ret = qmp_change(gc, qmp, "vnc", "password", vnc->passwd);
>      }
> +    if (!ret) {
> +        ret = qmp_query_vnc(qmp);
> +    }
>      libxl__qmp_close(qmp);
>      return ret;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKASQ-0008VM-Lj; Tue, 17 Apr 2012 15:36:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SKASP-0008VE-AA
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:36:41 +0000
Received: from [85.158.139.83:24970] by server-3.bemta-5.messagelabs.com id
	1C/07-25237-80E8D8F4; Tue, 17 Apr 2012 15:36:40 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334676997!12956464!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9899 invoked from network); 17 Apr 2012 15:36:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 15:36:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HFaMqq009490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 15:36:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HFaLGJ004162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 15:36:22 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HFaKGp001970; Tue, 17 Apr 2012 10:36:20 -0500
MIME-Version: 1.0
Message-ID: <ee9b0e64-9659-40bc-938d-f02fb411b6a4@default>
Date: Tue, 17 Apr 2012 08:36:11 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C619C020000780007E34E@nat28.tlf.novell.com>
	<84023b26-a682-44b5-990e-1635da6949ff@default>
	<4F8D3778020000780007E63A@nat28.tlf.novell.com>
In-Reply-To: <4F8D3778020000780007E63A@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F8D8DF8.00C0,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim\(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> >>> On 16.04.12 at 19:22, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > In upstream (and recent pv-ops) kernels, is there any need for there
> > to be a difference between HVM and PV in the clocksource chosen?  The
> 
> Yes, because RDTSC interception for PV guests is slow (using #GP
> and requiring instruction decode).

"Slow" is relative.  I showed (somewhere on xen-devel years ago) that
the emulation performance hit is much smaller than the original developers
expected and is detectable only with certain applications that
execute rdtsc ~100K/second.  Furthermore, the cycle count of an rdtsc
has gone up on modern systems, so the cost ratio of emulating
rdtsc vs executing the raw instruction is going down.
 
> > pvclock algorithm was necessary for PV when non-TSC hardware clocks
> > were privileged and the only non-privileged hardware clock (TSC)
> > was badly broken in hardware and for migration/save/restore.
> > With TSC now working and stable, and now that we are making changes
> > in the upstream kernel that work for both PV and HVM, is it
> > time to drop pvclock (at least as the default for PV)?
> >
> > Certainly if an old (non-pv-ops) kernel is broken, something like
> > David's patch might be an acceptable workaround.  I'm just arguing
> > against perpetuating pvclock-as-the-only-xen-clock upstream.
> 
> Afaict, the only uniformly reliable clocksource for PV guests is the
> virtual one which pvclock builds upon. Raw TSC is definitely not an
> option on NUMA systems (and PV guests aren't aware of the
> NUMAness of the underlying system).

You'll have to define NUMA.  On "old" NUMA systems, where there are
multiple motherboards, your statement is true.  On newer systems
where NUMA simply means there are multiple memory controllers and
all of them are cache-coherent, even when there are multiple
"motherboards" joined by HT or QPI, processor and system vendors
take great pains to ensure that the clock signal (and thus TSC) is
synchronized and "stable" across all cpus.

But I agree there ARE exceptions... for those, I proposed a Xen boot
option that said "don't trust TSC even if all the evidence implies
that you can", but Keir shot it down (also years ago).

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKASQ-0008VM-Lj; Tue, 17 Apr 2012 15:36:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SKASP-0008VE-AA
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:36:41 +0000
Received: from [85.158.139.83:24970] by server-3.bemta-5.messagelabs.com id
	1C/07-25237-80E8D8F4; Tue, 17 Apr 2012 15:36:40 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334676997!12956464!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9899 invoked from network); 17 Apr 2012 15:36:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 15:36:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HFaMqq009490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 15:36:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HFaLGJ004162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 15:36:22 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HFaKGp001970; Tue, 17 Apr 2012 10:36:20 -0500
MIME-Version: 1.0
Message-ID: <ee9b0e64-9659-40bc-938d-f02fb411b6a4@default>
Date: Tue, 17 Apr 2012 08:36:11 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C619C020000780007E34E@nat28.tlf.novell.com>
	<84023b26-a682-44b5-990e-1635da6949ff@default>
	<4F8D3778020000780007E63A@nat28.tlf.novell.com>
In-Reply-To: <4F8D3778020000780007E63A@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F8D8DF8.00C0,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim\(Xen.org\)" <tim@xen.org>,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> >>> On 16.04.12 at 19:22, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > In upstream (and recent pv-ops) kernels, is there any need for there
> > to be a difference between HVM and PV in the clocksource chosen?  The
> 
> Yes, because RDTSC interception for PV guests is slow (using #GP
> and requiring instruction decode).

"Slow" is relative.  I showed (somewhere on xen-devel years ago) that
the emulation performance hit is much smaller than the original developers
expected and is detectable only with certain applications that
execute rdtsc ~100K/second.  Furthermore, the cycle count of an rdtsc
has gone up on modern systems, so the cost ratio of emulating
rdtsc vs executing the raw instruction is going down.
 
> > pvclock algorithm was necessary for PV when non-TSC hardware clocks
> > were privileged and the only non-privileged hardware clock (TSC)
> > was badly broken in hardware and for migration/save/restore.
> > With TSC now working and stable, and now that we are making changes
> > in the upstream kernel that work for both PV and HVM, is it
> > time to drop pvclock (at least as the default for PV)?
> >
> > Certainly if an old (non-pv-ops) kernel is broken, something like
> > David's patch might be an acceptable workaround.  I'm just arguing
> > against perpetuating pvclock-as-the-only-xen-clock upstream.
> 
> Afaict, the only uniformly reliable clocksource for PV guests is the
> virtual one which pvclock builds upon. Raw TSC is definitely not an
> option on NUMA systems (and PV guests aren't aware of the
> NUMAness of the underlying system).

You'll have to define NUMA.  On "old" NUMA systems, where there are
multiple motherboards, your statement is true.  On newer systems
where NUMA simply means there are multiple memory controllers and
all of them are cache-coherent, even when there are multiple
"motherboards" joined by HT or QPI, processor and system vendors
take great pains to ensure that the clock signal (and thus TSC) is
synchronized and "stable" across all cpus.

But I agree there ARE exceptions... for those, I proposed a Xen boot
option that said "don't trust TSC even if all the evidence implies
that you can", but Keir shot it down (also years ago).

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:37:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKATF-000070-3S; Tue, 17 Apr 2012 15:37:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKATD-00006i-9C
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 15:37:31 +0000
Received: from [85.158.143.99:37027] by server-1.bemta-4.messagelabs.com id
	85/EA-20925-83E8D8F4; Tue, 17 Apr 2012 15:37:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334677048!23994309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14361 invoked from network); 17 Apr 2012 15:37:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:37:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:37:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 16:37:28 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKATA-0005GR-0i;
	Tue, 17 Apr 2012 15:37:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKAT9-0004MB-UM;
	Tue, 17 Apr 2012 16:37:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12705-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 16:37:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12705: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12705 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12705/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                4643b05662966a615845803c7bc89c5a5e77d6d5
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:37:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKATF-000070-3S; Tue, 17 Apr 2012 15:37:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKATD-00006i-9C
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 15:37:31 +0000
Received: from [85.158.143.99:37027] by server-1.bemta-4.messagelabs.com id
	85/EA-20925-83E8D8F4; Tue, 17 Apr 2012 15:37:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334677048!23994309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14361 invoked from network); 17 Apr 2012 15:37:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:37:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="11983635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 15:37:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 16:37:28 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKATA-0005GR-0i;
	Tue, 17 Apr 2012 15:37:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKAT9-0004MB-UM;
	Tue, 17 Apr 2012 16:37:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12705-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 16:37:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12705: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12705 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12705/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                4643b05662966a615845803c7bc89c5a5e77d6d5
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:43:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:43:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAYn-0000Oa-2i; Tue, 17 Apr 2012 15:43:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SKAYl-0000OU-7D
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:43:15 +0000
Received: from [193.109.254.147:47058] by server-4.bemta-14.messagelabs.com id
	B7/D3-11570-29F8D8F4; Tue, 17 Apr 2012 15:43:14 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334677392!4993567!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12835 invoked from network); 17 Apr 2012 15:43:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 15:43:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HFgxlQ017633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 15:43:00 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HFgvpq000646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 15:42:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HFgv0e019300; Tue, 17 Apr 2012 10:42:57 -0500
MIME-Version: 1.0
Message-ID: <3ea2625c-bbf0-44ad-9047-ecc3b8bce29f@default>
Date: Tue, 17 Apr 2012 08:42:48 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C4818.8070603@citrix.com>
	<8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
	<4F8D3C4E020000780007E658@nat28.tlf.novell.com>
In-Reply-To: <4F8D3C4E020000780007E658@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090201.4F8D8F84.00F2,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> >>> On 16.04.12 at 19:30, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> >>
> >> On 16/04/12 17:05, Dan Magenheimer wrote:
> >> >> From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> >> >
> >> > Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> >>
> >> Fair enough,
> >>
> >> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
> >>
> >> The original customer problem is on a host with Xen 3.4.  What do you
> >> recommend for Linux guests running such hosts?
> >
> > For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
> > back-patch the guest kernel with a workaround such as your patch, great!
> > I'm only arguing against the patch getting perpetuated upstream.
> >
> >> > In fact, it might be wise for a Xen-savvy kernel to check to see
> >> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> >> > and tsc=reliable.
> >>
> >> So, should the xen clocksource do:
> >>
> >> if Xen 4.0+
> >>     clock is stable, use rdtsc only.
> >> else
> >>     clock is unstable, use existing pvclock implementation.
> >
> > Yes, that's what I propose.  To clarify:
> >
> > if the guest can and does determine it is running on Xen 4.0+
> 
> _and_ TSC reads are emulated (which I don't think they are by
> default

They are emulated by default on any machine where Xen has
determined that TSC is untrustworthy AND always after migration.
So by definition (if not always in fact, see previous email),
and ignoring Xen bugs, Xen 4.0+ guarantees to guests that TSC
is a stable clock across all vcpus.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:43:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:43:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAYn-0000Oa-2i; Tue, 17 Apr 2012 15:43:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SKAYl-0000OU-7D
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:43:15 +0000
Received: from [193.109.254.147:47058] by server-4.bemta-14.messagelabs.com id
	B7/D3-11570-29F8D8F4; Tue, 17 Apr 2012 15:43:14 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334677392!4993567!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12835 invoked from network); 17 Apr 2012 15:43:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 15:43:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HFgxlQ017633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 15:43:00 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HFgvpq000646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 15:42:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HFgv0e019300; Tue, 17 Apr 2012 10:42:57 -0500
MIME-Version: 1.0
Message-ID: <3ea2625c-bbf0-44ad-9047-ecc3b8bce29f@default>
Date: Tue, 17 Apr 2012 08:42:48 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com>
	<4F8C1F6D020000780007E11A@nat28.tlf.novell.com>
	<4F8C33E0.2080007@citrix.com>
	<049b7b93-fb37-4962-b272-d786e1dcfacb@default>
	<4F8C4818.8070603@citrix.com>
	<8a78da52-26b2-42a2-80c7-c1ab8aee86eb@default>
	<4F8D3C4E020000780007E658@nat28.tlf.novell.com>
In-Reply-To: <4F8D3C4E020000780007E658@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090201.4F8D8F84.00F2,ss=1,re=0.000,fgs=0
Cc: Konrad Wilk <konrad.wilk@oracle.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>, Sheng Yang <sheng@yasker.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> >>> On 16.04.12 at 19:30, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> >>
> >> On 16/04/12 17:05, Dan Magenheimer wrote:
> >> >> From: David Vrabel [mailto:david.vrabel@citrix.com]
> >> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> >> >
> >> > Nacked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> >>
> >> Fair enough,
> >>
> >> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
> >>
> >> The original customer problem is on a host with Xen 3.4.  What do you
> >> recommend for Linux guests running such hosts?
> >
> > For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
> > back-patch the guest kernel with a workaround such as your patch, great!
> > I'm only arguing against the patch getting perpetuated upstream.
> >
> >> > In fact, it might be wise for a Xen-savvy kernel to check to see
> >> > if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> >> > and tsc=reliable.
> >>
> >> So, should the xen clocksource do:
> >>
> >> if Xen 4.0+
> >>     clock is stable, use rdtsc only.
> >> else
> >>     clock is unstable, use existing pvclock implementation.
> >
> > Yes, that's what I propose.  To clarify:
> >
> > if the guest can and does determine it is running on Xen 4.0+
> 
> _and_ TSC reads are emulated (which I don't think they are by
> default

They are emulated by default on any machine where Xen has
determined that TSC is untrustworthy AND always after migration.
So by definition (if not always in fact, see previous email),
and ignoring Xen bugs, Xen 4.0+ guarantees to guests that TSC
is a stable clock across all vcpus.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAbH-0000XO-MD; Tue, 17 Apr 2012 15:45:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SKAbG-0000XB-A7
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:45:50 +0000
Received: from [85.158.139.83:55760] by server-1.bemta-5.messagelabs.com id
	3F/64-28458-D209D8F4; Tue, 17 Apr 2012 15:45:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334677547!19625843!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzcxMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12683 invoked from network); 17 Apr 2012 15:45:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="24238279"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:45:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:45:47 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SKAbC-0006Ii-M5;
	Tue, 17 Apr 2012 16:45:46 +0100
Message-ID: <4F8D902A.2080607@citrix.com>
Date: Tue, 17 Apr 2012 16:45:46 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334676652.23948.112.camel@zakaz.uk.xensource.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/12 16:30, Ian Campbell wrote:
> On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
>> Currently `xl vncviewer $dom` does not work because the VNC port is not
>> registered in xenstore when using qemu-upstream. This patch attempted to fix
>> this.
>
> libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
> having such a thing in xenstore strikes me as something of a
> misfeature...

Well, I thought of that, but when I tried `xl vncviewer` with a password 
set, the result was that vncviewer asked me a password. That why I 
haven't put more effort in querrying the vnc password from QEMU.

> Otherwise:
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>
>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>



-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAbH-0000XO-MD; Tue, 17 Apr 2012 15:45:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SKAbG-0000XB-A7
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:45:50 +0000
Received: from [85.158.139.83:55760] by server-1.bemta-5.messagelabs.com id
	3F/64-28458-D209D8F4; Tue, 17 Apr 2012 15:45:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334677547!19625843!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzcxMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12683 invoked from network); 17 Apr 2012 15:45:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="24238279"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:45:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:45:47 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SKAbC-0006Ii-M5;
	Tue, 17 Apr 2012 16:45:46 +0100
Message-ID: <4F8D902A.2080607@citrix.com>
Date: Tue, 17 Apr 2012 16:45:46 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334676652.23948.112.camel@zakaz.uk.xensource.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/04/12 16:30, Ian Campbell wrote:
> On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
>> Currently `xl vncviewer $dom` does not work because the VNC port is not
>> registered in xenstore when using qemu-upstream. This patch attempted to fix
>> this.
>
> libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
> having such a thing in xenstore strikes me as something of a
> misfeature...

Well, I thought of that, but when I tried `xl vncviewer` with a password 
set, the result was that vncviewer asked me a password. That why I 
haven't put more effort in querrying the vnc password from QEMU.

> Otherwise:
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>
>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>



-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgt-0000nA-Tt; Tue, 17 Apr 2012 15:51:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgr-0000mZ-Qh
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:38 +0000
Received: from [85.158.138.51:18324] by server-5.bemta-3.messagelabs.com id
	F3/C9-17113-9819D8F4; Tue, 17 Apr 2012 15:51:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334677894!22584599!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2141 invoked from network); 17 Apr 2012 15:51:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749191"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-N9;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:13 +0100
Message-ID: <1334677876-17704-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a function which behaves like "xenstore-rm -t", and which will be used to
clean xenstore after unplug since we will be no longer executing
xen-hotplug-cleanup script, that used to do that for us.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..fe4bcc6 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,6 +356,27 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
 
 typedef struct {
     libxl__ao *ao;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgt-0000nA-Tt; Tue, 17 Apr 2012 15:51:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgr-0000mZ-Qh
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:38 +0000
Received: from [85.158.138.51:18324] by server-5.bemta-3.messagelabs.com id
	F3/C9-17113-9819D8F4; Tue, 17 Apr 2012 15:51:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334677894!22584599!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2141 invoked from network); 17 Apr 2012 15:51:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749191"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-N9;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:13 +0100
Message-ID: <1334677876-17704-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a function which behaves like "xenstore-rm -t", and which will be used to
clean xenstore after unplug since we will be no longer executing
xen-hotplug-cleanup script, that used to do that for us.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..fe4bcc6 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,6 +356,27 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
 
 typedef struct {
     libxl__ao *ao;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgv-0000ng-3m; Tue, 17 Apr 2012 15:51:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgs-0000mX-OU
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:39 +0000
Received: from [85.158.138.51:18429] by server-4.bemta-3.messagelabs.com id
	8D/16-15341-A819D8F4; Tue, 17 Apr 2012 15:51:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334677894!22584599!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2192 invoked from network); 17 Apr 2012 15:51:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749196"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-Nh;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:14 +0100
Message-ID: <1334677876-17704-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 3/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

 * Added a check in xen-hotplug-common.sh, so scripts are only executed from
   udev when using xend. xl adds a disable_udev=y to xenstore device backend,
   and with the modification of the udev rules every call from udev gets
   HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is passed
   and points to a value, the hotplug script is not executed.

I've also modified the python binding for pyxl_domain_destroy, that now take the
ao_how parameter, but I'm not really sure if it's done correctly, let's just say
that it compiles.

Changes since v1:

 * Replaced the hotplug snippet that prevents execution from udev when
   necessary, and now we set the env var from udev rules instead of libxl.

 * Replaced the libxl_device_disk_add "if" with a "switch".

 * Removed libxl__xs_path_cleanup (replaced with xs_rm).

 * Fixed several spelling mistakes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules     |    6 +-
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
 tools/libxl/Makefile                      |    3 +-
 tools/libxl/libxl.c                       |  107 +++++++++++++++++++++----
 tools/libxl/libxl.h                       |    7 +-
 tools/libxl/libxl_create.c                |    4 +-
 tools/libxl/libxl_device.c                |  124 ++++++++++++++++++++++++++---
 tools/libxl/libxl_dm.c                    |    4 +-
 tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++++
 tools/libxl/libxl_internal.h              |   43 ++++++++++-
 tools/libxl/libxl_linux.c                 |  114 ++++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c                  |   14 ++--
 tools/python/xen/lowlevel/xl/xl.c         |    5 +-
 13 files changed, 458 insertions(+), 46 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 19bd0fa..ef8ef8e 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..d2aac3a 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts from udev if the domain
+# has been launched from libxl
+if [ -n "${HOTPLUG_GATE}" ] && \
+   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b30d11f..ac8b810 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 16ebef3..06438ea 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
@@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(20, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->readwrite ? "w" : "r");
     flexarray_append(back, "device-type");
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+    /* compatibility addon to keep udev rules */
+    flexarray_append(back, "disable_udev");
+    flexarray_append(back, "y");
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
@@ -1420,14 +1439,26 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    switch(disk->backend) {
+    case LIBXL_DISK_BACKEND_PHY:
+    case LIBXL_DISK_BACKEND_TAP:
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+        break;
+    case LIBXL_DISK_BACKEND_QDISK:
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1473,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1708,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1909,7 +1951,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2256,7 +2309,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2389,7 +2453,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 50bae2f..b7347be 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,7 +394,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -523,7 +524,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index fe4bcc6..f352beb 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -381,22 +381,70 @@ static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events were added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -413,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -434,6 +481,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -441,7 +489,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -449,31 +497,74 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+    libxl__xs_path_cleanup(gc, be_path);
     return 0;
 }
 
-int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
+    return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
+}
+
+int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -503,11 +594,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events were added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a09b38d..4779a78 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -790,7 +790,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1044,7 +1044,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..2eace0c
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.pau@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2181774..a39346c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -455,6 +456,37 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -740,7 +772,8 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -763,6 +796,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..c5583af 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,117 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    flexarray_t *f_env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return NULL;
+    }
+
+    f_env = flexarray_make(9, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, script);
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 08815a3..01ff363 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1301,7 +1301,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1862,7 +1862,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2339,7 +2339,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2613,7 +2613,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2846,7 +2846,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2964,7 +2964,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5011,7 +5011,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index bbbf2a9..a41a720 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -444,9 +444,10 @@ static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid;
-    if ( !PyArg_ParseTuple(args, "i", &domid) )
+    const libxl_asyncop_how *ao_how;
+    if ( !PyArg_ParseTuple(args, "ii", &domid, &ao_how) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, ao_how) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgv-0000ng-3m; Tue, 17 Apr 2012 15:51:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgs-0000mX-OU
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:39 +0000
Received: from [85.158.138.51:18429] by server-4.bemta-3.messagelabs.com id
	8D/16-15341-A819D8F4; Tue, 17 Apr 2012 15:51:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334677894!22584599!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2192 invoked from network); 17 Apr 2012 15:51:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749196"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-Nh;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:14 +0100
Message-ID: <1334677876-17704-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 3/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

 * Added a check in xen-hotplug-common.sh, so scripts are only executed from
   udev when using xend. xl adds a disable_udev=y to xenstore device backend,
   and with the modification of the udev rules every call from udev gets
   HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is passed
   and points to a value, the hotplug script is not executed.

I've also modified the python binding for pyxl_domain_destroy, that now take the
ao_how parameter, but I'm not really sure if it's done correctly, let's just say
that it compiles.

Changes since v1:

 * Replaced the hotplug snippet that prevents execution from udev when
   necessary, and now we set the env var from udev rules instead of libxl.

 * Replaced the libxl_device_disk_add "if" with a "switch".

 * Removed libxl__xs_path_cleanup (replaced with xs_rm).

 * Fixed several spelling mistakes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules     |    6 +-
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
 tools/libxl/Makefile                      |    3 +-
 tools/libxl/libxl.c                       |  107 +++++++++++++++++++++----
 tools/libxl/libxl.h                       |    7 +-
 tools/libxl/libxl_create.c                |    4 +-
 tools/libxl/libxl_device.c                |  124 ++++++++++++++++++++++++++---
 tools/libxl/libxl_dm.c                    |    4 +-
 tools/libxl/libxl_hotplug.c               |   67 ++++++++++++++++
 tools/libxl/libxl_internal.h              |   43 ++++++++++-
 tools/libxl/libxl_linux.c                 |  114 ++++++++++++++++++++++++++
 tools/libxl/xl_cmdimpl.c                  |   14 ++--
 tools/python/xen/lowlevel/xl/xl.c         |    5 +-
 13 files changed, 458 insertions(+), 46 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 19bd0fa..ef8ef8e 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..d2aac3a 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts from udev if the domain
+# has been launched from libxl
+if [ -n "${HOTPLUG_GATE}" ] && \
+   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index b30d11f..ac8b810 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 16ebef3..06438ea 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,9 +1317,11 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
@@ -1330,7 +1336,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(20, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1361,6 +1367,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1385,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1406,6 +1422,9 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->readwrite ? "w" : "r");
     flexarray_append(back, "device-type");
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+    /* compatibility addon to keep udev rules */
+    flexarray_append(back, "disable_udev");
+    flexarray_append(back, "y");
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
@@ -1420,14 +1439,26 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    switch(disk->backend) {
+    case LIBXL_DISK_BACKEND_PHY:
+    case LIBXL_DISK_BACKEND_TAP:
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+        break;
+    case LIBXL_DISK_BACKEND_QDISK:
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1473,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1708,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1909,7 +1951,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2256,7 +2309,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2389,7 +2453,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 50bae2f..b7347be 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,7 +394,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -523,7 +524,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index fe4bcc6..f352beb 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -381,22 +381,70 @@ static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events were added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -413,7 +461,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -434,6 +481,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -441,7 +489,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -449,31 +497,74 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+    libxl__xs_path_cleanup(gc, be_path);
     return 0;
 }
 
-int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
+    return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
+}
+
+int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -503,11 +594,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events were added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a09b38d..4779a78 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -790,7 +790,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1044,7 +1044,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..2eace0c
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.pau@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2181774..a39346c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -455,6 +456,37 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -740,7 +772,8 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -763,6 +796,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..c5583af 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,117 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    flexarray_t *f_env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return NULL;
+    }
+
+    f_env = flexarray_make(9, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, script);
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 08815a3..01ff363 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1301,7 +1301,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1862,7 +1862,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2339,7 +2339,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2613,7 +2613,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2846,7 +2846,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2964,7 +2964,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5011,7 +5011,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index bbbf2a9..a41a720 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -444,9 +444,10 @@ static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid;
-    if ( !PyArg_ParseTuple(args, "i", &domid) )
+    const libxl_asyncop_how *ao_how;
+    if ( !PyArg_ParseTuple(args, "ii", &domid, &ao_how) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, ao_how) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgu-0000nU-N8; Tue, 17 Apr 2012 15:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgs-0000mV-S2
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:38 +0000
Received: from [85.158.138.51:3925] by server-12.bemta-3.messagelabs.com id
	CE/B4-29760-7819D8F4; Tue, 17 Apr 2012 15:51:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334677893!22516893!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 522 invoked from network); 17 Apr 2012 15:51:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-Ko	for xen-devel@lists.xen.org;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:11 +0100
Message-ID: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 0/5] libxl: call hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series removes the use of udev rules to call hotplug scripts when using
libxl. Scripts are directly called from the toolstack at the necessary points,
making use of the new event library and it's fork support.

Fixed Ian Campbell reviews and added support for named vifs. This series should 
be applied after Ian Jackson event fork and Ian Campbell support for named vifs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgu-0000nU-N8; Tue, 17 Apr 2012 15:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgs-0000mV-S2
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:38 +0000
Received: from [85.158.138.51:3925] by server-12.bemta-3.messagelabs.com id
	CE/B4-29760-7819D8F4; Tue, 17 Apr 2012 15:51:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334677893!22516893!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 522 invoked from network); 17 Apr 2012 15:51:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-Ko	for xen-devel@lists.xen.org;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:11 +0100
Message-ID: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 0/5] libxl: call hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series removes the use of udev rules to call hotplug scripts when using
libxl. Scripts are directly called from the toolstack at the necessary points,
making use of the new event library and it's fork support.

Fixed Ian Campbell reviews and added support for named vifs. This series should 
be applied after Ian Jackson event fork and Ian Campbell support for named vifs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgs-0000mo-Go; Tue, 17 Apr 2012 15:51:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgr-0000mX-FZ
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:37 +0000
Received: from [85.158.138.51:4012] by server-4.bemta-3.messagelabs.com id
	AB/06-15341-8819D8F4; Tue, 17 Apr 2012 15:51:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334677893!22516893!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 592 invoked from network); 17 Apr 2012 15:51:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749193"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-PE;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:16 +0100
Message-ID: <1334677876-17704-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 5/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Changes since v1:

 * Indentation fixes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 04f76c2..d9c1786 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,11 +216,18 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "nic,vlan=%d,macaddr=%s,model=%s",
+                                      vifs[i].devid, smac, vifs[i].model),
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
+                                      "script=%s,downscript=%s",
+                                      vifs[i].devid, ifname, vifs[i].bridge,
+                                      libxl_tapif_script(gc),
+                                      libxl_tapif_script(gc)),
+                                  NULL);
                 ioemu_vifs++;
             }
         }
@@ -461,10 +468,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].model, vifs[i].devid,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
-                flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
-                                                vifs[i].devid, ifname,
-                                                libxl_tapif_script(gc)));
+                flexarray_append(dm_args, libxl__sprintf(gc, 
+                                          "type=tap,id=net%d,ifname=%s,"
+                                          "script=%s,downscript=%s",
+                                          vifs[i].devid, ifname,
+                                          libxl_tapif_script(gc),
+                                          libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
         }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgs-0000mo-Go; Tue, 17 Apr 2012 15:51:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgr-0000mX-FZ
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:37 +0000
Received: from [85.158.138.51:4012] by server-4.bemta-3.messagelabs.com id
	AB/06-15341-8819D8F4; Tue, 17 Apr 2012 15:51:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334677893!22516893!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 592 invoked from network); 17 Apr 2012 15:51:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749193"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-PE;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:16 +0100
Message-ID: <1334677876-17704-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 5/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Changes since v1:

 * Indentation fixes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 04f76c2..d9c1786 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,11 +216,18 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "nic,vlan=%d,macaddr=%s,model=%s",
+                                      vifs[i].devid, smac, vifs[i].model),
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
+                                      "script=%s,downscript=%s",
+                                      vifs[i].devid, ifname, vifs[i].bridge,
+                                      libxl_tapif_script(gc),
+                                      libxl_tapif_script(gc)),
+                                  NULL);
                 ioemu_vifs++;
             }
         }
@@ -461,10 +468,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].model, vifs[i].devid,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
-                flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
-                                                vifs[i].devid, ifname,
-                                                libxl_tapif_script(gc)));
+                flexarray_append(dm_args, libxl__sprintf(gc, 
+                                          "type=tap,id=net%d,ifname=%s,"
+                                          "script=%s,downscript=%s",
+                                          vifs[i].devid, ifname,
+                                          libxl_tapif_script(gc),
+                                          libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
         }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgu-0000nJ-9e; Tue, 17 Apr 2012 15:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgs-0000mZ-C2
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:38 +0000
Received: from [85.158.138.51:18363] by server-5.bemta-3.messagelabs.com id
	38/C9-17113-9819D8F4; Tue, 17 Apr 2012 15:51:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334677893!22516893!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 643 invoked from network); 17 Apr 2012 15:51:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-Md;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:12 +0100
Message-ID: <1334677876-17704-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 1/5] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59992b6..16ebef3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index fdeddc6..a09b38d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -991,7 +991,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d486af2..2181774 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -949,8 +949,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:51:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:51:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAgu-0000nJ-9e; Tue, 17 Apr 2012 15:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAgs-0000mZ-C2
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:38 +0000
Received: from [85.158.138.51:18363] by server-5.bemta-3.messagelabs.com id
	38/C9-17113-9819D8F4; Tue, 17 Apr 2012 15:51:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334677893!22516893!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 643 invoked from network); 17 Apr 2012 15:51:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="190749189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-Md;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:12 +0100
Message-ID: <1334677876-17704-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 1/5] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59992b6..16ebef3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index fdeddc6..a09b38d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -991,7 +991,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d486af2..2181774 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -949,8 +949,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:52:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:52:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAh8-0000rm-Pu; Tue, 17 Apr 2012 15:51:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAh7-0000qw-R8
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:54 +0000
Received: from [193.109.254.147:37839] by server-11.bemta-14.messagelabs.com
	id 2A/DC-05858-9919D8F4; Tue, 17 Apr 2012 15:51:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334677905!5024204!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzcxMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25452 invoked from network); 17 Apr 2012 15:51:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="24238504"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:45 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-OV;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:15 +0100
Message-ID: <1334677876-17704-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from libxl
	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

An exception has been introduced for tap devices, since hotplug scripts
should be called after the device model has been created, so the hotplug
call for those is done in do_domain_create after confirmation of the device
model startup. On the other hand, tap devices don't use teardown scripts,
so add another exception for that.

libxl__device_from_nic was moved to libxl_device.c, so it can be used
in libxl_create.c, and libxl__device_from_disk was also moved to mantain
the simmetry.

libxl__initiate_device_remove has been changed a little, to nuke the frontend
xenstore path before trying to perform device teardown, this allows for
unitialized devices to be closed gracefully, specially vif interfaces added to
HVM machines and not used.

PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
LIBXL_NIC_TYPE_IOEMU regardless of the guest type.

A new gobal option, called disable_vif_scripts has been added to allow the user
decide if he wants to execute the hotplug scripts from xl or from udev. This has
been documented in the xl.conf man page.

Changes since v1:

 * Propagated changes from previous patch (disable_udev and libxl_device_nic_add
   switch).

 * Modified udev rules to add the new env variable.

 * Added support for named interfaces.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5                |    7 ++
 tools/hotplug/Linux/xen-backend.rules |    6 +-
 tools/libxl/libxl.c                   |   90 +++++++-------------
 tools/libxl/libxl.h                   |    3 +-
 tools/libxl/libxl_create.c            |   22 +++++-
 tools/libxl/libxl_device.c            |   77 +++++++++++++++--
 tools/libxl/libxl_dm.c                |    2 +-
 tools/libxl/libxl_internal.h          |    6 ++
 tools/libxl/libxl_linux.c             |  150 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_types.idl           |    1 +
 tools/libxl/xl.c                      |    4 +
 tools/libxl/xl.h                      |    1 +
 tools/libxl/xl_cmdimpl.c              |   15 +++-
 13 files changed, 308 insertions(+), 76 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8bd45ea..cf2c477 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,13 @@ default.
 
 Default: C<1>
 
+=item B<disable_vif_scripts=BOOLEAN>
+
+If enabled xl will not execute nic hotplug scripts itself, and instead
+relegate this task to udev.
+
+Default: C<0>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index ef8ef8e..35c4e13 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disabl
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 06438ea..d0d6968 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1277,46 +1277,6 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
                           libxl_device_disk *disk,
                           const libxl_asyncop_how *ao_how)
@@ -1831,23 +1791,10 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
     return 0;
 }
 
-static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
-                                  libxl_device_nic *nic,
-                                  libxl__device *device)
-{
-    device->backend_devid    = nic->devid;
-    device->backend_domid    = nic->backend_domid;
-    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
-    device->devid            = nic->devid;
-    device->domid            = domid;
-    device->kind             = LIBXL__DEVICE_KIND_VIF;
-
-    return 0;
-}
-
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1862,7 +1809,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1915,6 +1862,13 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
     flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->nictype));
+    /* compatibility addon to keep udev rules */
+    if (!nic->disable_vif_script) {
+        flexarray_append(back, "disable_udev");
+        flexarray_append(back, "y");
+    }
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
@@ -1929,14 +1883,30 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    switch(nic->nictype) {
+    case LIBXL_NIC_TYPE_VIF:
+        if (!nic->disable_vif_script) {
+            rc = libxl__initiate_device_add(egc, ao, &device);
+            if (rc) goto out_free;
+        }
+        break;
+    case LIBXL_NIC_TYPE_IOEMU:
+        /*
+         * Don't execute hotplug scripts for IOEMU interfaces yet,
+         * we need to launch the device model first.
+        */
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b7347be..6da6107 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -551,7 +551,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..a1f5731 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
@@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                        "device model did not start: %d", ret);
             goto error_out;
         }
+        /* 
+         * Execute hotplug scripts for tap devices, this has to be done
+         * after the domain model has been started.
+        */
+        for (i = 0; i < d_config->num_vifs; i++) {
+            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
+                !d_config->vifs[i].disable_vif_script) {
+                libxl__device device;
+                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
+                                             &device);
+                if (ret < 0) goto error_out;
+                ret = libxl__device_hotplug(gc, &device, CONNECT);
+                if (ret < 0) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                               "unable to launch hotplug script for device: "
+                               "%"PRIu32, device.devid);
+                    goto error_out;
+                }
+            }
+        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index f352beb..033f23c 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -249,6 +249,60 @@ char *libxl__device_disk_string_of_backend(libxl_disk_backend backend)
     }
 }
 
+int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                           libxl_device_nic *nic,
+                           libxl__device *device)
+{
+    device->backend_devid    = nic->devid;
+    device->backend_domid    = nic->backend_domid;
+    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
+    device->devid            = nic->devid;
+    device->domid            = domid;
+    device->kind             = LIBXL__DEVICE_KIND_VIF;
+
+    return 0;
+}
+
+int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                            libxl_device_disk *disk,
+                            libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
 int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor)
 {
     struct stat buf;
@@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
+    xs_transaction_t t = 0;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
     libxl__ao_device_remove *aorm = 0;
 
+    /*
+     * Nuke frontend to force backend teardown
+     * It's not pretty, but it's the only way that seems to work for all
+     * types of backends
+     */
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
     if (!state)
         goto out_ok;
-    if (atoi(state) != 4) {
+    if (atoi(state) == XenbusStateClosed)
         libxl__device_destroy_tapdisk(gc, be_path);
         goto out_ok;
-    }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -476,6 +537,8 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
@@ -497,8 +560,8 @@ retry_transaction:
     return rc;
 
  out_ok:
+    if (t) xs_transaction_end(ctx->xsh, t, 0);
     rc = libxl__device_hotplug(gc, dev, DISCONNECT);
-    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
     libxl__xs_path_cleanup(gc, be_path);
     return 0;
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4779a78..04f76c2 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -795,7 +795,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a39346c..3787217 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -756,6 +756,12 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
 _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*);
+_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__device *device);
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                    libxl_device_disk *disk,
+                                    libxl__device *device);
 
 _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor);
 _hidden int libxl__device_disk_dev_number(const char *virtpath,
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index c5583af..1ef282f 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
 }
 
 /* Hotplug scripts helpers */
+
+static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *snictype, *be_path;
+
+    be_path = libxl__device_backend_path(gc, dev);
+
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "type"));
+    if (!snictype) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
+                                          be_path);
+        return -1;
+    }
+
+    return atoi(snictype);
+}
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
-    char *script;
+    char *script, *ifname;
     flexarray_t *f_env;
     int nr = 0;
 
@@ -43,7 +62,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    f_env = flexarray_make(9, 1);
+    f_env = flexarray_make(13, 1);
     if (!f_env) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "unable to create environment array");
@@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
                   dev->domid, dev->devid));
     flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
     flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                 be_path,
+                                                                 "vifname"));
+        switch (get_nic_type(gc, dev)) {
+        case LIBXL_NIC_TYPE_IOEMU:
+            flexarray_set(f_env, nr++, "INTERFACE");
+            if (ifname) {
+                flexarray_set(f_env, nr++, libxl__sprintf(gc, "xentap-%s",
+                                                              ifname));
+            } else {
+                flexarray_set(f_env, nr++,
+                              libxl__sprintf(gc, "xentap%u.%d",
+                              dev->domid, dev->devid));
+            }
+        case LIBXL_NIC_TYPE_VIF:
+            flexarray_set(f_env, nr++, "vif");
+            if (ifname) {
+                flexarray_set(f_env, nr++, ifname);
+            } else {
+                flexarray_set(f_env, nr++,
+                              libxl__sprintf(gc, "vif%u.%d",
+                              dev->domid, dev->devid));
+            }
+            break;
+        default:
+            return NULL;
+        }
+    }
 
     flexarray_set(f_env, nr++, NULL);
 
@@ -123,6 +171,101 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+    flexarray_t *vif_args, *tap_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    nictype = get_nic_type(gc, dev);
+    if (nictype < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "error when fetching nic type");
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    vif_args = flexarray_make(4, 1);
+    if (!vif_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+    tap_args = flexarray_make(4, 1);
+    if (!tap_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    switch(nictype) {
+    case LIBXL_NIC_TYPE_IOEMU:
+        flexarray_set(tap_args, nr++, script);
+        flexarray_set(tap_args, nr++, action == CONNECT ? "add" : "remove");
+        flexarray_set(tap_args, nr++, libxl__sprintf(gc, "type_if=tap"));
+        flexarray_set(tap_args, nr++, NULL);
+        args = (char **) flexarray_contents(tap_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        free(args);
+        nr = 0;
+    case LIBXL_NIC_TYPE_VIF:
+        flexarray_set(vif_args, nr++, script);
+        flexarray_set(vif_args, nr++, action == CONNECT ? "online" : "offline");
+        flexarray_set(vif_args, nr++, libxl__sprintf(gc, "type_if=vif"));
+        flexarray_set(vif_args, nr++, NULL);
+        args = (char **) flexarray_contents(vif_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        break;
+    default:
+        /* Unknown network type */
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unknown network card type with "
+                                            "id %"PRIu32, dev->devid);
+        return 0;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -132,6 +275,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 09089b2..ac3e79f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
     ("ifname", string),
     ("script", string),
     ("nictype", libxl_nic_type),
+    ("disable_vif_script", integer),
     ])
 
 libxl_device_pci = Struct("device_pci", [
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..2a705b8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+int disable_vif_scripts = 0;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    if (!xlu_cfg_get_long (config, "disable_vif_scripts", &l, 0))
+        disable_vif_scripts = l;
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..13619e7 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -109,6 +109,7 @@ void postfork(void);
 
 /* global options */
 extern int autoballoon;
+extern int disable_vif_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 01ff363..41230a6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -846,6 +846,19 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+            /* Set default nic type for PV guests correctly */
+            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
+                nic->nictype = LIBXL_NIC_TYPE_VIF;
+            }
+
+            /*
+             * Disable nic network script calling, to allow the user
+             * to attach the nic backend from a different domain.
+             */
+            if (disable_vif_scripts) {
+                nic->disable_vif_script = 1;
+            }
+
 	    if (default_bridge) {
 		free(nic->bridge);
 		nic->bridge = strdup(default_bridge);
@@ -4901,7 +4914,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:52:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:52:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAh8-0000rm-Pu; Tue, 17 Apr 2012 15:51:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKAh7-0000qw-R8
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:51:54 +0000
Received: from [193.109.254.147:37839] by server-11.bemta-14.messagelabs.com
	id 2A/DC-05858-9919D8F4; Tue, 17 Apr 2012 15:51:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334677905!5024204!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzcxMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25452 invoked from network); 17 Apr 2012 15:51:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 15:51:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,436,1330923600"; d="scan'208";a="24238504"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 11:51:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 11:51:45 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SKAgd-0006Ny-OV;
	Tue, 17 Apr 2012 16:51:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 17 Apr 2012 16:51:15 +0100
Message-ID: <1334677876-17704-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from libxl
	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

An exception has been introduced for tap devices, since hotplug scripts
should be called after the device model has been created, so the hotplug
call for those is done in do_domain_create after confirmation of the device
model startup. On the other hand, tap devices don't use teardown scripts,
so add another exception for that.

libxl__device_from_nic was moved to libxl_device.c, so it can be used
in libxl_create.c, and libxl__device_from_disk was also moved to mantain
the simmetry.

libxl__initiate_device_remove has been changed a little, to nuke the frontend
xenstore path before trying to perform device teardown, this allows for
unitialized devices to be closed gracefully, specially vif interfaces added to
HVM machines and not used.

PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
LIBXL_NIC_TYPE_IOEMU regardless of the guest type.

A new gobal option, called disable_vif_scripts has been added to allow the user
decide if he wants to execute the hotplug scripts from xl or from udev. This has
been documented in the xl.conf man page.

Changes since v1:

 * Propagated changes from previous patch (disable_udev and libxl_device_nic_add
   switch).

 * Modified udev rules to add the new env variable.

 * Added support for named interfaces.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5                |    7 ++
 tools/hotplug/Linux/xen-backend.rules |    6 +-
 tools/libxl/libxl.c                   |   90 +++++++-------------
 tools/libxl/libxl.h                   |    3 +-
 tools/libxl/libxl_create.c            |   22 +++++-
 tools/libxl/libxl_device.c            |   77 +++++++++++++++--
 tools/libxl/libxl_dm.c                |    2 +-
 tools/libxl/libxl_internal.h          |    6 ++
 tools/libxl/libxl_linux.c             |  150 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_types.idl           |    1 +
 tools/libxl/xl.c                      |    4 +
 tools/libxl/xl.h                      |    1 +
 tools/libxl/xl_cmdimpl.c              |   15 +++-
 13 files changed, 308 insertions(+), 76 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8bd45ea..cf2c477 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,13 @@ default.
 
 Default: C<1>
 
+=item B<disable_vif_scripts=BOOLEAN>
+
+If enabled xl will not execute nic hotplug scripts itself, and instead
+relegate this task to udev.
+
+Default: C<0>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index ef8ef8e..35c4e13 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disabl
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", ENV{HOTPLUG_GATE}="$XENBUS_PATH/disable_udev", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 06438ea..d0d6968 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1277,46 +1277,6 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
                           libxl_device_disk *disk,
                           const libxl_asyncop_how *ao_how)
@@ -1831,23 +1791,10 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
     return 0;
 }
 
-static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
-                                  libxl_device_nic *nic,
-                                  libxl__device *device)
-{
-    device->backend_devid    = nic->devid;
-    device->backend_domid    = nic->backend_domid;
-    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
-    device->devid            = nic->devid;
-    device->domid            = domid;
-    device->kind             = LIBXL__DEVICE_KIND_VIF;
-
-    return 0;
-}
-
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1862,7 +1809,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
         goto out_free;
@@ -1915,6 +1862,13 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
     flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->nictype));
+    /* compatibility addon to keep udev rules */
+    if (!nic->disable_vif_script) {
+        flexarray_append(back, "disable_udev");
+        flexarray_append(back, "y");
+    }
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
@@ -1929,14 +1883,30 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    switch(nic->nictype) {
+    case LIBXL_NIC_TYPE_VIF:
+        if (!nic->disable_vif_script) {
+            rc = libxl__initiate_device_add(egc, ao, &device);
+            if (rc) goto out_free;
+        }
+        break;
+    case LIBXL_NIC_TYPE_IOEMU:
+        /*
+         * Don't execute hotplug scripts for IOEMU interfaces yet,
+         * we need to launch the device model first.
+        */
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b7347be..6da6107 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -551,7 +551,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..a1f5731 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
@@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                        "device model did not start: %d", ret);
             goto error_out;
         }
+        /* 
+         * Execute hotplug scripts for tap devices, this has to be done
+         * after the domain model has been started.
+        */
+        for (i = 0; i < d_config->num_vifs; i++) {
+            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
+                !d_config->vifs[i].disable_vif_script) {
+                libxl__device device;
+                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
+                                             &device);
+                if (ret < 0) goto error_out;
+                ret = libxl__device_hotplug(gc, &device, CONNECT);
+                if (ret < 0) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                               "unable to launch hotplug script for device: "
+                               "%"PRIu32, device.devid);
+                    goto error_out;
+                }
+            }
+        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index f352beb..033f23c 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -249,6 +249,60 @@ char *libxl__device_disk_string_of_backend(libxl_disk_backend backend)
     }
 }
 
+int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                           libxl_device_nic *nic,
+                           libxl__device *device)
+{
+    device->backend_devid    = nic->devid;
+    device->backend_domid    = nic->backend_domid;
+    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
+    device->devid            = nic->devid;
+    device->domid            = domid;
+    device->kind             = LIBXL__DEVICE_KIND_VIF;
+
+    return 0;
+}
+
+int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                            libxl_device_disk *disk,
+                            libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
 int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor)
 {
     struct stat buf;
@@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
+    xs_transaction_t t = 0;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
     libxl__ao_device_remove *aorm = 0;
 
+    /*
+     * Nuke frontend to force backend teardown
+     * It's not pretty, but it's the only way that seems to work for all
+     * types of backends
+     */
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
     if (!state)
         goto out_ok;
-    if (atoi(state) != 4) {
+    if (atoi(state) == XenbusStateClosed)
         libxl__device_destroy_tapdisk(gc, be_path);
         goto out_ok;
-    }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -476,6 +537,8 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
@@ -497,8 +560,8 @@ retry_transaction:
     return rc;
 
  out_ok:
+    if (t) xs_transaction_end(ctx->xsh, t, 0);
     rc = libxl__device_hotplug(gc, dev, DISCONNECT);
-    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
     libxl__xs_path_cleanup(gc, be_path);
     return 0;
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4779a78..04f76c2 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -795,7 +795,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a39346c..3787217 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -756,6 +756,12 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
 _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*);
+_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__device *device);
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                    libxl_device_disk *disk,
+                                    libxl__device *device);
 
 _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor);
 _hidden int libxl__device_disk_dev_number(const char *virtpath,
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index c5583af..1ef282f 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
 }
 
 /* Hotplug scripts helpers */
+
+static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *snictype, *be_path;
+
+    be_path = libxl__device_backend_path(gc, dev);
+
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "type"));
+    if (!snictype) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
+                                          be_path);
+        return -1;
+    }
+
+    return atoi(snictype);
+}
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
-    char *script;
+    char *script, *ifname;
     flexarray_t *f_env;
     int nr = 0;
 
@@ -43,7 +62,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    f_env = flexarray_make(9, 1);
+    f_env = flexarray_make(13, 1);
     if (!f_env) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "unable to create environment array");
@@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
                   dev->domid, dev->devid));
     flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
     flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                 be_path,
+                                                                 "vifname"));
+        switch (get_nic_type(gc, dev)) {
+        case LIBXL_NIC_TYPE_IOEMU:
+            flexarray_set(f_env, nr++, "INTERFACE");
+            if (ifname) {
+                flexarray_set(f_env, nr++, libxl__sprintf(gc, "xentap-%s",
+                                                              ifname));
+            } else {
+                flexarray_set(f_env, nr++,
+                              libxl__sprintf(gc, "xentap%u.%d",
+                              dev->domid, dev->devid));
+            }
+        case LIBXL_NIC_TYPE_VIF:
+            flexarray_set(f_env, nr++, "vif");
+            if (ifname) {
+                flexarray_set(f_env, nr++, ifname);
+            } else {
+                flexarray_set(f_env, nr++,
+                              libxl__sprintf(gc, "vif%u.%d",
+                              dev->domid, dev->devid));
+            }
+            break;
+        default:
+            return NULL;
+        }
+    }
 
     flexarray_set(f_env, nr++, NULL);
 
@@ -123,6 +171,101 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+    flexarray_t *vif_args, *tap_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    nictype = get_nic_type(gc, dev);
+    if (nictype < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "error when fetching nic type");
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    vif_args = flexarray_make(4, 1);
+    if (!vif_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+    tap_args = flexarray_make(4, 1);
+    if (!tap_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    switch(nictype) {
+    case LIBXL_NIC_TYPE_IOEMU:
+        flexarray_set(tap_args, nr++, script);
+        flexarray_set(tap_args, nr++, action == CONNECT ? "add" : "remove");
+        flexarray_set(tap_args, nr++, libxl__sprintf(gc, "type_if=tap"));
+        flexarray_set(tap_args, nr++, NULL);
+        args = (char **) flexarray_contents(tap_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        free(args);
+        nr = 0;
+    case LIBXL_NIC_TYPE_VIF:
+        flexarray_set(vif_args, nr++, script);
+        flexarray_set(vif_args, nr++, action == CONNECT ? "online" : "offline");
+        flexarray_set(vif_args, nr++, libxl__sprintf(gc, "type_if=vif"));
+        flexarray_set(vif_args, nr++, NULL);
+        args = (char **) flexarray_contents(vif_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        break;
+    default:
+        /* Unknown network type */
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unknown network card type with "
+                                            "id %"PRIu32, dev->devid);
+        return 0;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -132,6 +275,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 09089b2..ac3e79f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
     ("ifname", string),
     ("script", string),
     ("nictype", libxl_nic_type),
+    ("disable_vif_script", integer),
     ])
 
 libxl_device_pci = Struct("device_pci", [
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..2a705b8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+int disable_vif_scripts = 0;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    if (!xlu_cfg_get_long (config, "disable_vif_scripts", &l, 0))
+        disable_vif_scripts = l;
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..13619e7 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -109,6 +109,7 @@ void postfork(void);
 
 /* global options */
 extern int autoballoon;
+extern int disable_vif_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 01ff363..41230a6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -846,6 +846,19 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+            /* Set default nic type for PV guests correctly */
+            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
+                nic->nictype = LIBXL_NIC_TYPE_VIF;
+            }
+
+            /*
+             * Disable nic network script calling, to allow the user
+             * to attach the nic backend from a different domain.
+             */
+            if (disable_vif_scripts) {
+                nic->disable_vif_script = 1;
+            }
+
 	    if (default_bridge) {
 		free(nic->bridge);
 		nic->bridge = strdup(default_bridge);
@@ -4901,7 +4914,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:56:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAlH-0001VD-JO; Tue, 17 Apr 2012 15:56:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SKAlG-0001V3-Cv
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:56:10 +0000
Received: from [85.158.138.51:62677] by server-4.bemta-3.messagelabs.com id
	56/1E-15341-9929D8F4; Tue, 17 Apr 2012 15:56:09 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334678167!22564689!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14917 invoked from network); 17 Apr 2012 15:56:08 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 15:56:08 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q3HFu0EI003860;
	Tue, 17 Apr 2012 10:56:00 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q3HFtxn7003859;
	Tue, 17 Apr 2012 10:55:59 -0500
Date: Tue, 17 Apr 2012 10:55:59 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204171555.q3HFtxn7003859@wind.enjellic.com>
In-Reply-To: Ian Jackson <Ian.Jackson@eu.citrix.com>
	"Re: [Xen-devel] Basic blktap2 functionality issues." (Apr  2, 4:51pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Tue, 17 Apr 2012 10:56:00 -0500 (CDT)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Apr 2,  4:51pm, Ian Jackson wrote:
} Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

Hi Ian, et. al, hope this note finds your day going well.

> Ian Campbell writes ("Re: [Xen-devel] Basic blktap2 functionality issues."):
> > On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > > I think an approach worth trying would be to have
> > > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > > doing the actual detach. i.e. it would respond with "Yes, I will do
> > > that" rather than "Yes, I have done that". My speculation is that this
> > > will allow libxl to continue and hopefully avoid the deadlock.
> > 
> > This seems to be the case as the following fixes things for me. Thanks
> > very much for your analysis which lead me to this solution...

> Greg, can you confirm whether this works for you ?

I've been grinding through the blktap2 issues and came up with some
additional findings I wanted to bounce off everyone.

The ability to reproduce this problem with the tap-ctl utility helped
confirm what the problem 'smelled like' from the beginning, ie. a hung
reference to the tapdev device instance which is ultimately preventing
the .release method from completing on the tapdisk2 side of things.

I started snooping around in xenstore and I believe I am seeing an
issue where xl does not release the the vbd instance in dom0.  This
causes a steady and persistent increase in the number of 'stale' vbd
instances held in dom0.  At a minimum this would suggest that xl is
not properly releasing resources properly which may help track the
whole issue down.

I replaced the tap: directive with a phy: device instance and saw the
orphan vbd instance as well so the problem doesn't seem related to a
blktap driver instance.

This is with the original patch applied which 'fixed' the problem with
the tapdisk2 process being left alive.  I'm going to back out that
patch to see if it reproduces with stock 4.1.2.

In the meantime let me know if anyone else is seeing this or if anyone
remembers a generic problem like this being fixed in xl in unstable.

> Ian.

Have a good afternoon.

}-- End of excerpt from Ian Jackson

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"We have more to fear from the bungling of the incompetent than from
 the machinations of the wicked."
                                -- Slashdot

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:56:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAlH-0001VD-JO; Tue, 17 Apr 2012 15:56:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1SKAlG-0001V3-Cv
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:56:10 +0000
Received: from [85.158.138.51:62677] by server-4.bemta-3.messagelabs.com id
	56/1E-15341-9929D8F4; Tue, 17 Apr 2012 15:56:09 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334678167!22564689!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14917 invoked from network); 17 Apr 2012 15:56:08 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 15:56:08 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q3HFu0EI003860;
	Tue, 17 Apr 2012 10:56:00 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q3HFtxn7003859;
	Tue, 17 Apr 2012 10:55:59 -0500
Date: Tue, 17 Apr 2012 10:55:59 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201204171555.q3HFtxn7003859@wind.enjellic.com>
In-Reply-To: Ian Jackson <Ian.Jackson@eu.citrix.com>
	"Re: [Xen-devel] Basic blktap2 functionality issues." (Apr  2, 4:51pm)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Tue, 17 Apr 2012 10:56:00 -0500 (CDT)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Basic blktap2 functionality issues.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Apr 2,  4:51pm, Ian Jackson wrote:
} Subject: Re: [Xen-devel] Basic blktap2 functionality issues.

Hi Ian, et. al, hope this note finds your day going well.

> Ian Campbell writes ("Re: [Xen-devel] Basic blktap2 functionality issues."):
> > On Fri, 2012-03-30 at 09:17 +0100, Ian Campbell wrote:
> > > I think an approach worth trying would be to have
> > > tapdisk_control_detach_vbd respond to TAPDISK_MESSAGE_DETACH before
> > > doing the actual detach. i.e. it would respond with "Yes, I will do
> > > that" rather than "Yes, I have done that". My speculation is that this
> > > will allow libxl to continue and hopefully avoid the deadlock.
> > 
> > This seems to be the case as the following fixes things for me. Thanks
> > very much for your analysis which lead me to this solution...

> Greg, can you confirm whether this works for you ?

I've been grinding through the blktap2 issues and came up with some
additional findings I wanted to bounce off everyone.

The ability to reproduce this problem with the tap-ctl utility helped
confirm what the problem 'smelled like' from the beginning, ie. a hung
reference to the tapdev device instance which is ultimately preventing
the .release method from completing on the tapdisk2 side of things.

I started snooping around in xenstore and I believe I am seeing an
issue where xl does not release the the vbd instance in dom0.  This
causes a steady and persistent increase in the number of 'stale' vbd
instances held in dom0.  At a minimum this would suggest that xl is
not properly releasing resources properly which may help track the
whole issue down.

I replaced the tap: directive with a phy: device instance and saw the
orphan vbd instance as well so the problem doesn't seem related to a
blktap driver instance.

This is with the original patch applied which 'fixed' the problem with
the tapdisk2 process being left alive.  I'm going to back out that
patch to see if it reproduces with stock 4.1.2.

In the meantime let me know if anyone else is seeing this or if anyone
remembers a generic problem like this being fixed in xl in unstable.

> Ian.

Have a good afternoon.

}-- End of excerpt from Ian Jackson

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"We have more to fear from the bungling of the incompetent than from
 the machinations of the wicked."
                                -- Slashdot

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:56:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAlb-0001YN-4T; Tue, 17 Apr 2012 15:56:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKAla-0001YB-AD
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:56:30 +0000
Received: from [85.158.143.99:24302] by server-1.bemta-4.messagelabs.com id
	6C/55-20925-DA29D8F4; Tue, 17 Apr 2012 15:56:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334678188!14276939!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTk0MTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24046 invoked from network); 17 Apr 2012 15:56:28 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 15:56:28 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 5960A60408C;
	Tue, 17 Apr 2012 08:56:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Q+qTBzP8P6a0FDKkQOWOYMKQ3x7pFlgFEKU2txE58YcF
	+JnuEtjD/tcKVtIIaR7UdRlgigN01rs2tgX9840k83lX5mspDqK6q4r5Ca6h9hpD
	FeBr11+TkwLZ488Qtop3C4e+NTm8B22J5/QP2wDCDiM6oc0ZhxDf0980ptrZg9I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=T+yeBLxoiKIspT/4ch0pWmwnrm4=; b=pDqZKzvo
	+ehhv/maRoE7hUf1TLOq0wvdnkeU6ymLj802W08K0kFxmA1iKpMAA06jPeEA+M+q
	koipcnnWsJ59AI9aoE1F+mraR+UHG4Ad0w+6iNMPTIJ+gzgN0v3BAxTkXK3dvxbu
	CZx3G2TtOP8bfb+bVa6hMsfDpF4T7X04C7o=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id EA10A60408D; 
	Tue, 17 Apr 2012 08:56:25 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 17 Apr 2012 08:56:27 -0700
Message-ID: <1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
Date: Tue, 17 Apr 2012 08:56:27 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: JBeulich@suse.com, ian.campbell@citrix.com, Santosh.Jodh@citrix.com
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>
> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>> told me to change all others while I was in there.
>
> Oh, right, I remember now.
>
> Given that reverting it for this case will still leave the same issue
> for the grant case (which I'd forgotten about) I suppose the appropriate
> workaround is to touch the alloca'd memory in the appropriate order in
> all cases (perhaps with an alloca helper macro).

FWIW, I am very skeptical about this whole alloca business. It's very very
dangerous, no surprise on the bug report. On my code I tend to map
arbitrarily-sized pfn arrays, and I've been thinking of disabling alloca.

If your only safeguard is to put a loop that touches everything so the
stack gets allocated .... then what's your gain?

Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
round_to_page_size(what_you_need)). That's likely the fastest way to get
the array in Linux. It isn't that slow either. And it's safe.

Andres

>
> Ian.
>
>>
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Tuesday, April 17, 2012 12:56 AM
>> To: Ian Campbell; AP
>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>> causing segfault
>>
>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>> >> amounts of pages (in the GB range) from a guest in to Dom0
>> >
>> > Out of interest -- what are you doing this for?
>> >
>> >>  using
>> >> xc_map_foreign_bulk() I am hitting a segfault.
>> >>
>> >> Program received signal SIGSEGV, Segmentation fault.
>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>> >>     h=<optimized out>, dom=2, prot=<optimized out>,
>> arr=0x7ffff6bf5010,
>> >>     err=0x7ffff67f4010, num=<optimized out>)
>> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> >> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0
>> (__dest));
>> >> (gdb) bt
>> >> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>> (xch=0x605050,
>> >>     h=<optimized out>, dom=2, prot=<optimized out>,
>> arr=0x7ffff6bf5010,
>> >>     err=0x7ffff67f4010, num=<optimized out>)
>> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> >> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>> >>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>> >>     err=<optimized out>, num=<optimized out>) at
>> >> xc_foreign_memory.c:79
>> >>
>> >> This was working for me with Xen 4.1.2. On comparing
>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>> >> blowing the stack with the call.
>> >
>> > I bet this is due to Linux's stack guard page. This means that if you
>> > try and increase the stack by more than ~1 page you skip entirely over
>> > the "next" stack page and into the guard.
>> >
>> > Does it help if after the alloca you add a loop which touches the
>> > first word of each page of the new buffer? Since the stack grows down
>> > you might actually need to do it backwards from the end of the array
>> > in order to start at the end which is nearest the existing stack?
>> > (it's before coffee o'clock so thinking about stack direction isn't my
>> > strong point yet...)
>>
>> This should really be done by the alloca() implementation itself -
>> anything else is a bug.
>>
>> > The switch to alloca was made recently in order to optimise the
>> > hotpath for a userspace I/O backend.
>>
>> Probably this should be made size-dependent ...
>>
>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath
>> > operations should really be grant table ops, a backend shouldn't be
>> > relying on the privileges accorded to dom0 -- for one thing it should
>> > be expected to work in a driver domain.
>>
>> ... if this indeed turns out to be a hot path for something at all?
>>
>> Jan
>>
>> >>  If I replace the alloca() with malloc() the call goes through. What
>> >> is the way around this? Should I be using
>> >> xc_map_foreign_batch() instead, which I think is deprecated? Please
>> >> advice...
>> >>
>> >> Thanks,
>> >> AP
>> >>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 15:56:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 15:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAlb-0001YN-4T; Tue, 17 Apr 2012 15:56:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKAla-0001YB-AD
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 15:56:30 +0000
Received: from [85.158.143.99:24302] by server-1.bemta-4.messagelabs.com id
	6C/55-20925-DA29D8F4; Tue, 17 Apr 2012 15:56:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334678188!14276939!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTk0MTk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24046 invoked from network); 17 Apr 2012 15:56:28 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 15:56:28 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 5960A60408C;
	Tue, 17 Apr 2012 08:56:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Q+qTBzP8P6a0FDKkQOWOYMKQ3x7pFlgFEKU2txE58YcF
	+JnuEtjD/tcKVtIIaR7UdRlgigN01rs2tgX9840k83lX5mspDqK6q4r5Ca6h9hpD
	FeBr11+TkwLZ488Qtop3C4e+NTm8B22J5/QP2wDCDiM6oc0ZhxDf0980ptrZg9I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=T+yeBLxoiKIspT/4ch0pWmwnrm4=; b=pDqZKzvo
	+ehhv/maRoE7hUf1TLOq0wvdnkeU6ymLj802W08K0kFxmA1iKpMAA06jPeEA+M+q
	koipcnnWsJ59AI9aoE1F+mraR+UHG4Ad0w+6iNMPTIJ+gzgN0v3BAxTkXK3dvxbu
	CZx3G2TtOP8bfb+bVa6hMsfDpF4T7X04C7o=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id EA10A60408D; 
	Tue, 17 Apr 2012 08:56:25 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 17 Apr 2012 08:56:27 -0700
Message-ID: <1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
Date: Tue, 17 Apr 2012 08:56:27 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: JBeulich@suse.com, ian.campbell@citrix.com, Santosh.Jodh@citrix.com
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>
> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>> told me to change all others while I was in there.
>
> Oh, right, I remember now.
>
> Given that reverting it for this case will still leave the same issue
> for the grant case (which I'd forgotten about) I suppose the appropriate
> workaround is to touch the alloca'd memory in the appropriate order in
> all cases (perhaps with an alloca helper macro).

FWIW, I am very skeptical about this whole alloca business. It's very very
dangerous, no surprise on the bug report. On my code I tend to map
arbitrarily-sized pfn arrays, and I've been thinking of disabling alloca.

If your only safeguard is to put a loop that touches everything so the
stack gets allocated .... then what's your gain?

Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
round_to_page_size(what_you_need)). That's likely the fastest way to get
the array in Linux. It isn't that slow either. And it's safe.

Andres

>
> Ian.
>
>>
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Tuesday, April 17, 2012 12:56 AM
>> To: Ian Campbell; AP
>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>> causing segfault
>>
>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>> >> amounts of pages (in the GB range) from a guest in to Dom0
>> >
>> > Out of interest -- what are you doing this for?
>> >
>> >>  using
>> >> xc_map_foreign_bulk() I am hitting a segfault.
>> >>
>> >> Program received signal SIGSEGV, Segmentation fault.
>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>> >>     h=<optimized out>, dom=2, prot=<optimized out>,
>> arr=0x7ffff6bf5010,
>> >>     err=0x7ffff67f4010, num=<optimized out>)
>> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> >> 52	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0
>> (__dest));
>> >> (gdb) bt
>> >> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>> (xch=0x605050,
>> >>     h=<optimized out>, dom=2, prot=<optimized out>,
>> arr=0x7ffff6bf5010,
>> >>     err=0x7ffff67f4010, num=<optimized out>)
>> >>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> >> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>> >>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>> >>     err=<optimized out>, num=<optimized out>) at
>> >> xc_foreign_memory.c:79
>> >>
>> >> This was working for me with Xen 4.1.2. On comparing
>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>> >> blowing the stack with the call.
>> >
>> > I bet this is due to Linux's stack guard page. This means that if you
>> > try and increase the stack by more than ~1 page you skip entirely over
>> > the "next" stack page and into the guard.
>> >
>> > Does it help if after the alloca you add a loop which touches the
>> > first word of each page of the new buffer? Since the stack grows down
>> > you might actually need to do it backwards from the end of the array
>> > in order to start at the end which is nearest the existing stack?
>> > (it's before coffee o'clock so thinking about stack direction isn't my
>> > strong point yet...)
>>
>> This should really be done by the alloca() implementation itself -
>> anything else is a bug.
>>
>> > The switch to alloca was made recently in order to optimise the
>> > hotpath for a userspace I/O backend.
>>
>> Probably this should be made size-dependent ...
>>
>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath
>> > operations should really be grant table ops, a backend shouldn't be
>> > relying on the privileges accorded to dom0 -- for one thing it should
>> > be expected to work in a driver domain.
>>
>> ... if this indeed turns out to be a hot path for something at all?
>>
>> Jan
>>
>> >>  If I replace the alloca() with malloc() the call goes through. What
>> >> is the way around this? Should I be using
>> >> xc_map_foreign_batch() instead, which I think is deprecated? Please
>> >> advice...
>> >>
>> >> Thanks,
>> >> AP
>> >>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 16:07:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 16:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAw0-0002NB-I1; Tue, 17 Apr 2012 16:07:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKAvz-0002N6-FD
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 16:07:15 +0000
Received: from [85.158.143.35:31246] by server-3.bemta-4.messagelabs.com id
	CD/7F-05853-2359D8F4; Tue, 17 Apr 2012 16:07:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334678831!13671859!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5914 invoked from network); 17 Apr 2012 16:07:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 16:07:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HG78Rc015974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 16:07:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HG77ft018016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 16:07:08 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HG778T029858; Tue, 17 Apr 2012 11:07:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 09:07:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4042440280; Tue, 17 Apr 2012 12:02:08 -0400 (EDT)
Date: Tue, 17 Apr 2012 12:02:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120417160208.GB28477@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F8D952E.0017,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
	bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 12:55:49PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
> >>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
> >>> 2001 
> >> From: Liu, Jinsong <jinsong.liu@intel.com>
> >> Date: Mon, 16 Apr 2012 00:16:58 +0800
> >> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back
> >> point 
> >> 
> >> When xen hyeprvisor inject vMCE to guest, use native mce handler to
> >> handle it 
> > 
> > hypervisor
> > 
> >> 
> >> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> >> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> >>  --- arch/x86/xen/enlighten.c |   10 +++++++---
> >>  1 files changed, 7 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >> index 15628d4..346ba64 100644
> >> --- a/arch/x86/xen/enlighten.c
> >> +++ b/arch/x86/xen/enlighten.c
> >> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
> >> gate_desc *val,  	/* 
> >>  	 * Look for known traps using IST, and substitute them
> >>  	 * appropriately.  The debugger ones are the only ones we care
> >> -	 * about.  Xen will handle faults like double_fault and
> >> -	 * machine_check, so we should never see them.  Warn if
> >> +	 * about.  Xen will handle faults like double_fault,
> >> +	 * so we should never see them.  Warn if
> >>  	 * there's an unexpected IST-using fault handler.  	 */
> >>  	if (addr == (unsigned long)debug)
> >> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
> >>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
> >>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
> >> +		/*
> >> +		 * when xen hyeprvisor inject vMCE to guest,
> >> +		 * use native mce handler to handle it
> >> +		 */
> >> +		;
> > 
> > 
> > Can you just take the check out?
> 
> What do you mean by 'check out'? remove
> else if (addr == (unsigned long) machine_check) {
> 	;
> }
> ?
> 
> That would fail to register mce bounce back point.

Right, b/c right after we hit this check:
  /* Some other trap using IST? */
 639                 if (WARN_ON(val->ist != 0))
 640                         return 0;
 641         }

.. And the val->ist is not set for MCEs right?

> 
> > 
> > 
> >>  #endif
> >>  	} else {
> >>  		/* Some other trap using IST? */
> >> --
> >> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 16:07:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 16:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKAw0-0002NB-I1; Tue, 17 Apr 2012 16:07:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKAvz-0002N6-FD
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 16:07:15 +0000
Received: from [85.158.143.35:31246] by server-3.bemta-4.messagelabs.com id
	CD/7F-05853-2359D8F4; Tue, 17 Apr 2012 16:07:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334678831!13671859!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5914 invoked from network); 17 Apr 2012 16:07:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 16:07:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HG78Rc015974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 16:07:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HG77ft018016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 16:07:08 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HG778T029858; Tue, 17 Apr 2012 11:07:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 09:07:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4042440280; Tue, 17 Apr 2012 12:02:08 -0400 (EDT)
Date: Tue, 17 Apr 2012 12:02:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120417160208.GB28477@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F8D952E.0017,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
	bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 12:55:49PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
> >>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
> >>> 2001 
> >> From: Liu, Jinsong <jinsong.liu@intel.com>
> >> Date: Mon, 16 Apr 2012 00:16:58 +0800
> >> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce back
> >> point 
> >> 
> >> When xen hyeprvisor inject vMCE to guest, use native mce handler to
> >> handle it 
> > 
> > hypervisor
> > 
> >> 
> >> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> >> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> >>  --- arch/x86/xen/enlighten.c |   10 +++++++---
> >>  1 files changed, 7 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >> index 15628d4..346ba64 100644
> >> --- a/arch/x86/xen/enlighten.c
> >> +++ b/arch/x86/xen/enlighten.c
> >> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
> >> gate_desc *val,  	/* 
> >>  	 * Look for known traps using IST, and substitute them
> >>  	 * appropriately.  The debugger ones are the only ones we care
> >> -	 * about.  Xen will handle faults like double_fault and
> >> -	 * machine_check, so we should never see them.  Warn if
> >> +	 * about.  Xen will handle faults like double_fault,
> >> +	 * so we should never see them.  Warn if
> >>  	 * there's an unexpected IST-using fault handler.  	 */
> >>  	if (addr == (unsigned long)debug)
> >> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
> >>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
> >>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
> >> +		/*
> >> +		 * when xen hyeprvisor inject vMCE to guest,
> >> +		 * use native mce handler to handle it
> >> +		 */
> >> +		;
> > 
> > 
> > Can you just take the check out?
> 
> What do you mean by 'check out'? remove
> else if (addr == (unsigned long) machine_check) {
> 	;
> }
> ?
> 
> That would fail to register mce bounce back point.

Right, b/c right after we hit this check:
  /* Some other trap using IST? */
 639                 if (WARN_ON(val->ist != 0))
 640                         return 0;
 641         }

.. And the val->ist is not set for MCEs right?

> 
> > 
> > 
> >>  #endif
> >>  	} else {
> >>  		/* Some other trap using IST? */
> >> --
> >> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:03:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKBoA-0003v1-4R; Tue, 17 Apr 2012 17:03:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKBo8-0003uv-Pt
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 17:03:13 +0000
Received: from [85.158.143.35:30065] by server-1.bemta-4.messagelabs.com id
	55/EC-20925-052AD8F4; Tue, 17 Apr 2012 17:03:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334682191!12834650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9898 invoked from network); 17 Apr 2012 17:03:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:03:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:03:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKBo6-00065f-Sc; Tue, 17 Apr 2012 17:03:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKBo6-0007o7-Rj;
	Tue, 17 Apr 2012 18:03:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.41550.838083.825783@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:03:10 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334675843.23948.102.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the review.

Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> Neither this patch nor the rest of the series seems to handle the long
> running nature of xc_domain_restore, is that expected at this stage?

This is a thorny problem.

> We discussed a similar thing in the context of xc_domain_save, and I
> expect the required scaffolding (bumping an op over into a thread) will
> be the same on both sides?

Yes.

The thread's activities will have to be severely restricted but I
think that will be doable.

We should consider another alternative: spawning a copy of xc_save,
like xend does.

> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > libxl__spawn_spawn becomes a callback-style asynchronous function.
> > The implementation is now in terms of libxl__ev_* including
> > libxl_ev_child.
> 
> (nb: I actually skipped ahead and reviewed the libxl_internal.h change
> first so I could read the docs, if only diff could be taught such
> things ;-))

Quite.

> >  typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> > -int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> > -int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
> > +  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
> > +   * properties need to be documented but they may turn out to be too
> > +   * awkward */
> 
> The reentrancy concerns here relate to the "cb" or to something else?

To the cb.  This is in fact fixed later in the series.

> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > @@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc,
> > libxl_domain_config *d_config,
> >          libxl_device_vkb_add(ctx, domid, &vkb);
> >          libxl_device_vkb_dispose(&vkb);
> > [...]
> > +        dcs->dmss.guest_domid = domid;
> 
> dcs->dmss is part of a union with dcs->sdss. I'd rather this was done
> inside the if once we've committed to one or the other, IYSWIM.
> 
> Actually the hunk above (which I've trimmed already, sorry) also
> initialised dmss unconditionally.
> 
> (does sdss really not need guest_domid somewhere too? odd)

libxl__stubdom_spawn_state is a struct containing a
libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
domid is in sdss.stubdom.guest_domid, and because stubdom is first
this is the same as dmss->guest_domid.

Maybe this needs a bigger comment ?

> > +        return;
> > +
> >          break;
> 
> return then break? I think the break is redundant.

Yes.

> > -    if (dm_starting) {
> > +    assert(!dcs->dmss.guest_domid);
> > +    domcreate_devmodel_started(egc, &dcs->dmss, 0);
> 
> This is actually logically the "else" of the preceding need_qemu if,
> since all the other paths return before they get here. I spent quite a
> while figuring out why the problem with the "return; break;" I mentioned
> above was an extra break and not the return. Might be clearer to have
> this in the else?

Yes, good idea.

> > +static void domcreate_complete(libxl__egc *egc,
> > +                               libxl__domain_create_state *dcs,
> > +                               int rc) {
> 
> { should be on the next line.

Will fix.

> > +    /* convenience aliases */
> > +    libxl_domain_config *dm_config = &sdss->stubdom_config;
> > +    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
> > +    int guest_domid = sdss->stubdom.guest_domid;
> 
> const? Just in case someone tries to modify it? (maybe there are similar
> cases in some of the previous blocks like this, I didn't notice).

OK.  (Yes, there are a couple of other similar blocks.)

> > +    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
> > +                                    spawn_watch_event, ss->xspath);
> 
> IIRC xspath is optional, does libxl__ev_xswatch_register DTWT with NULL?

No, it would crash.

xspath is no longer optional.  There can be no correct callers who
don't arrange to be notified by their demonic child that it has
started up, and the only current callers use xenstore for this.

> > -/* xl_exec */
> > +/*
> > + *----- spawn -----
> > + *
> > + * Higher-level double-fork and separate detach eg as for device models
> > + *
> > + * Each libxl__spawn_state is in one of the conventional states
> > + *    Undefined, Idle, Active
> 
> Conventional here means "as per event generation" I assume.

Yes.

> > + * The inner child must soon exit or exec.  If must also soon exit or
> 
>                                                It?

Yes.

> > + * In both children, the ctx is not fully useable: gc and logging
> 
>                                              usable
> 
> (apparently, I'm not convinced actually)

I always think "useable" is better but the rest of the code uses
"usable" elsewhere so I guess here should too.

> > + * longer repaorted via failure_cb.
> 
>              reported

Will fix.

> [...]
> 
> > +/*----- device model creation -----*/
> > +
> > +/* First layer; wraps libxl__spawn_spawn. */
> 
> The use of "First" here is terrifying to me as a reviewer ;-P

Sorry ...

> > +struct libxl__dm_spawn_state {
> > +    /* mixed - ao must be initialised by user; rest is private: */
> 
> I see no ao here, you mean spawn.ao?

Yes.  I have clarified this.

> > +/* Stubdoms. */
> > +
> > +typedef struct {
> > +    /* mixed - user must fill in public parts only: */
> > +    libxl__dm_spawn_state stubdom; /* will always remain the first member */
> 
> why? If you are playing casting tricks then you could use CONTAINER_OF.

See above.

> > +_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
> > +
> 
> Ah, I see now what local_dm meant, it's the non-stubdom DM.
> 
> stubdom is a bit of an overloaded term (we have grub stubdoms, xenstore
> stubdoms etc too). stub_dm would be better.

Do you think I should s/stubdom/stubdm/ or something ?

> >  /*
> >   * Convenience macros.
> >   */
> 
> Right, back to the top to start on the implementation...

There's no requirement to quote the patch in the order it appeared.
You can rearrange in your email...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:03:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKBoA-0003v1-4R; Tue, 17 Apr 2012 17:03:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKBo8-0003uv-Pt
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 17:03:13 +0000
Received: from [85.158.143.35:30065] by server-1.bemta-4.messagelabs.com id
	55/EC-20925-052AD8F4; Tue, 17 Apr 2012 17:03:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334682191!12834650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9898 invoked from network); 17 Apr 2012 17:03:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:03:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:03:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKBo6-00065f-Sc; Tue, 17 Apr 2012 17:03:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKBo6-0007o7-Rj;
	Tue, 17 Apr 2012 18:03:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.41550.838083.825783@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:03:10 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334675843.23948.102.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the review.

Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> Neither this patch nor the rest of the series seems to handle the long
> running nature of xc_domain_restore, is that expected at this stage?

This is a thorny problem.

> We discussed a similar thing in the context of xc_domain_save, and I
> expect the required scaffolding (bumping an op over into a thread) will
> be the same on both sides?

Yes.

The thread's activities will have to be severely restricted but I
think that will be doable.

We should consider another alternative: spawning a copy of xc_save,
like xend does.

> On Mon, 2012-04-16 at 18:17 +0100, Ian Jackson wrote:
> > libxl__spawn_spawn becomes a callback-style asynchronous function.
> > The implementation is now in terms of libxl__ev_* including
> > libxl_ev_child.
> 
> (nb: I actually skipped ahead and reviewed the libxl_internal.h change
> first so I could read the docs, if only diff could be taught such
> things ;-))

Quite.

> >  typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> > -int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> > -int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
> > +  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
> > +   * properties need to be documented but they may turn out to be too
> > +   * awkward */
> 
> The reentrancy concerns here relate to the "cb" or to something else?

To the cb.  This is in fact fixed later in the series.

> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > @@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc,
> > libxl_domain_config *d_config,
> >          libxl_device_vkb_add(ctx, domid, &vkb);
> >          libxl_device_vkb_dispose(&vkb);
> > [...]
> > +        dcs->dmss.guest_domid = domid;
> 
> dcs->dmss is part of a union with dcs->sdss. I'd rather this was done
> inside the if once we've committed to one or the other, IYSWIM.
> 
> Actually the hunk above (which I've trimmed already, sorry) also
> initialised dmss unconditionally.
> 
> (does sdss really not need guest_domid somewhere too? odd)

libxl__stubdom_spawn_state is a struct containing a
libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
domid is in sdss.stubdom.guest_domid, and because stubdom is first
this is the same as dmss->guest_domid.

Maybe this needs a bigger comment ?

> > +        return;
> > +
> >          break;
> 
> return then break? I think the break is redundant.

Yes.

> > -    if (dm_starting) {
> > +    assert(!dcs->dmss.guest_domid);
> > +    domcreate_devmodel_started(egc, &dcs->dmss, 0);
> 
> This is actually logically the "else" of the preceding need_qemu if,
> since all the other paths return before they get here. I spent quite a
> while figuring out why the problem with the "return; break;" I mentioned
> above was an extra break and not the return. Might be clearer to have
> this in the else?

Yes, good idea.

> > +static void domcreate_complete(libxl__egc *egc,
> > +                               libxl__domain_create_state *dcs,
> > +                               int rc) {
> 
> { should be on the next line.

Will fix.

> > +    /* convenience aliases */
> > +    libxl_domain_config *dm_config = &sdss->stubdom_config;
> > +    libxl_domain_config *guest_config = sdss->stubdom.guest_config;
> > +    int guest_domid = sdss->stubdom.guest_domid;
> 
> const? Just in case someone tries to modify it? (maybe there are similar
> cases in some of the previous blocks like this, I didn't notice).

OK.  (Yes, there are a couple of other similar blocks.)

> > +    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
> > +                                    spawn_watch_event, ss->xspath);
> 
> IIRC xspath is optional, does libxl__ev_xswatch_register DTWT with NULL?

No, it would crash.

xspath is no longer optional.  There can be no correct callers who
don't arrange to be notified by their demonic child that it has
started up, and the only current callers use xenstore for this.

> > -/* xl_exec */
> > +/*
> > + *----- spawn -----
> > + *
> > + * Higher-level double-fork and separate detach eg as for device models
> > + *
> > + * Each libxl__spawn_state is in one of the conventional states
> > + *    Undefined, Idle, Active
> 
> Conventional here means "as per event generation" I assume.

Yes.

> > + * The inner child must soon exit or exec.  If must also soon exit or
> 
>                                                It?

Yes.

> > + * In both children, the ctx is not fully useable: gc and logging
> 
>                                              usable
> 
> (apparently, I'm not convinced actually)

I always think "useable" is better but the rest of the code uses
"usable" elsewhere so I guess here should too.

> > + * longer repaorted via failure_cb.
> 
>              reported

Will fix.

> [...]
> 
> > +/*----- device model creation -----*/
> > +
> > +/* First layer; wraps libxl__spawn_spawn. */
> 
> The use of "First" here is terrifying to me as a reviewer ;-P

Sorry ...

> > +struct libxl__dm_spawn_state {
> > +    /* mixed - ao must be initialised by user; rest is private: */
> 
> I see no ao here, you mean spawn.ao?

Yes.  I have clarified this.

> > +/* Stubdoms. */
> > +
> > +typedef struct {
> > +    /* mixed - user must fill in public parts only: */
> > +    libxl__dm_spawn_state stubdom; /* will always remain the first member */
> 
> why? If you are playing casting tricks then you could use CONTAINER_OF.

See above.

> > +_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
> > +
> 
> Ah, I see now what local_dm meant, it's the non-stubdom DM.
> 
> stubdom is a bit of an overloaded term (we have grub stubdoms, xenstore
> stubdoms etc too). stub_dm would be better.

Do you think I should s/stubdom/stubdm/ or something ?

> >  /*
> >   * Convenience macros.
> >   */
> 
> Right, back to the top to start on the implementation...

There's no requirement to quote the patch in the order it appeared.
You can rearrange in your email...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:07:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKBsC-00041k-QS; Tue, 17 Apr 2012 17:07:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKBsB-00041a-Iu
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:07:23 +0000
Received: from [85.158.138.51:50992] by server-7.bemta-3.messagelabs.com id
	4F/96-03078-A43AD8F4; Tue, 17 Apr 2012 17:07:22 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334682441!22545796!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY1NDI1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27943 invoked from network); 17 Apr 2012 17:07:21 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 17:07:21 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 17 Apr 2012 10:06:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="90096558"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 10:06:53 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 10:06:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Wed, 18 Apr 2012 01:06:51 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 2/2] Register native mce handler as vMCE bounce back point
Thread-Index: AQHNHLNw/TdpFhoPSxCwxlIbh3KVRpafPnOQ
Date: Tue, 17 Apr 2012 17:06:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233514CDEF@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
	<20120417160208.GB28477@phenom.dumpdata.com>
In-Reply-To: <20120417160208.GB28477@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
 bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 17, 2012 at 12:55:49PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
>>>>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
>>>>> 2001
>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>>> Date: Mon, 16 Apr 2012 00:16:58 +0800
>>>> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce
>>>> back point 
>>>> 
>>>> When xen hyeprvisor inject vMCE to guest, use native mce handler to
>>>> handle it
>>> 
>>> hypervisor
>>> 
>>>> 
>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>> Signed-off-by: Ke, Liping <liping.ke@intel.com>
>>>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
>>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>>>  --- arch/x86/xen/enlighten.c |   10 +++++++---
>>>>  1 files changed, 7 insertions(+), 3 deletions(-)
>>>> 
>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>>> index 15628d4..346ba64 100644 --- a/arch/x86/xen/enlighten.c
>>>> +++ b/arch/x86/xen/enlighten.c
>>>> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
>>>> gate_desc *val,  	/* 
>>>>  	 * Look for known traps using IST, and substitute them
>>>>  	 * appropriately.  The debugger ones are the only ones we care
>>>> -	 * about.  Xen will handle faults like double_fault and
>>>> -	 * machine_check, so we should never see them.  Warn if
>>>> +	 * about.  Xen will handle faults like double_fault,
>>>> +	 * so we should never see them.  Warn if
>>>>  	 * there's an unexpected IST-using fault handler.  	 */
>>>>  	if (addr == (unsigned long)debug)
>>>> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
>>>>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
>>>>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
>>>> +		/* +		 * when xen hyeprvisor inject vMCE to guest,
>>>> +		 * use native mce handler to handle it
>>>> +		 */
>>>> +		;
>>> 
>>> 
>>> Can you just take the check out?
>> 
>> What do you mean by 'check out'? remove
>> else if (addr == (unsigned long) machine_check) {
>> 	;
>> }
>> ?
>> 
>> That would fail to register mce bounce back point.
> 
> Right, b/c right after we hit this check:
>   /* Some other trap using IST? */
>  639                 if (WARN_ON(val->ist != 0))
>  640                         return 0;
>  641         }
> 
> .. And the val->ist is not set for MCEs right?

No, mce ist is set as 0/5 (32/64), set_intr_gate_ist(X86_TRAP_MC, &machine_check, MCE_STACK); 

> 
>> 
>>> 
>>> 
>>>>  #endif
>>>>  	} else {
>>>>  		/* Some other trap using IST? */
>>>> --
>>>> 1.7.1
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:07:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKBsC-00041k-QS; Tue, 17 Apr 2012 17:07:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKBsB-00041a-Iu
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:07:23 +0000
Received: from [85.158.138.51:50992] by server-7.bemta-3.messagelabs.com id
	4F/96-03078-A43AD8F4; Tue, 17 Apr 2012 17:07:22 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334682441!22545796!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY1NDI1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27943 invoked from network); 17 Apr 2012 17:07:21 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 17:07:21 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 17 Apr 2012 10:06:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="90096558"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 10:06:53 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 10:06:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Wed, 18 Apr 2012 01:06:51 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 2/2] Register native mce handler as vMCE bounce back point
Thread-Index: AQHNHLNw/TdpFhoPSxCwxlIbh3KVRpafPnOQ
Date: Tue, 17 Apr 2012 17:06:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233514CDEF@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
	<20120417160208.GB28477@phenom.dumpdata.com>
In-Reply-To: <20120417160208.GB28477@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
 bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 17, 2012 at 12:55:49PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
>>>>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
>>>>> 2001
>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>>> Date: Mon, 16 Apr 2012 00:16:58 +0800
>>>> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce
>>>> back point 
>>>> 
>>>> When xen hyeprvisor inject vMCE to guest, use native mce handler to
>>>> handle it
>>> 
>>> hypervisor
>>> 
>>>> 
>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>> Signed-off-by: Ke, Liping <liping.ke@intel.com>
>>>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
>>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>>>  --- arch/x86/xen/enlighten.c |   10 +++++++---
>>>>  1 files changed, 7 insertions(+), 3 deletions(-)
>>>> 
>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>>> index 15628d4..346ba64 100644 --- a/arch/x86/xen/enlighten.c
>>>> +++ b/arch/x86/xen/enlighten.c
>>>> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
>>>> gate_desc *val,  	/* 
>>>>  	 * Look for known traps using IST, and substitute them
>>>>  	 * appropriately.  The debugger ones are the only ones we care
>>>> -	 * about.  Xen will handle faults like double_fault and
>>>> -	 * machine_check, so we should never see them.  Warn if
>>>> +	 * about.  Xen will handle faults like double_fault,
>>>> +	 * so we should never see them.  Warn if
>>>>  	 * there's an unexpected IST-using fault handler.  	 */
>>>>  	if (addr == (unsigned long)debug)
>>>> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
>>>>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
>>>>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
>>>> +		/* +		 * when xen hyeprvisor inject vMCE to guest,
>>>> +		 * use native mce handler to handle it
>>>> +		 */
>>>> +		;
>>> 
>>> 
>>> Can you just take the check out?
>> 
>> What do you mean by 'check out'? remove
>> else if (addr == (unsigned long) machine_check) {
>> 	;
>> }
>> ?
>> 
>> That would fail to register mce bounce back point.
> 
> Right, b/c right after we hit this check:
>   /* Some other trap using IST? */
>  639                 if (WARN_ON(val->ist != 0))
>  640                         return 0;
>  641         }
> 
> .. And the val->ist is not set for MCEs right?

No, mce ist is set as 0/5 (32/64), set_intr_gate_ist(X86_TRAP_MC, &machine_check, MCE_STACK); 

> 
>> 
>>> 
>>> 
>>>>  #endif
>>>>  	} else {
>>>>  		/* Some other trap using IST? */
>>>> --
>>>> 1.7.1
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:17:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKC1o-0004Jb-0m; Tue, 17 Apr 2012 17:17:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKC1m-0004JW-Iy
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:17:18 +0000
Received: from [85.158.143.35:37229] by server-1.bemta-4.messagelabs.com id
	57/88-20925-D95AD8F4; Tue, 17 Apr 2012 17:17:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334683037!10394627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25589 invoked from network); 17 Apr 2012 17:17:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:17:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:17:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:17:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC1k-0006Eu-6J; Tue, 17 Apr 2012 17:17:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC1k-0001e5-5E;
	Tue, 17 Apr 2012 18:17:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42396.142064.874548@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:17:16 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> qemu-xen offers better disk performances than qemu-xen-traditional
> because it supports Linux native AIO.

Does this take any account of whether the new qemu-xen dm is
installed ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:17:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKC1o-0004Jb-0m; Tue, 17 Apr 2012 17:17:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKC1m-0004JW-Iy
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:17:18 +0000
Received: from [85.158.143.35:37229] by server-1.bemta-4.messagelabs.com id
	57/88-20925-D95AD8F4; Tue, 17 Apr 2012 17:17:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334683037!10394627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25589 invoked from network); 17 Apr 2012 17:17:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:17:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:17:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:17:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC1k-0006Eu-6J; Tue, 17 Apr 2012 17:17:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC1k-0001e5-5E;
	Tue, 17 Apr 2012 18:17:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42396.142064.874548@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:17:16 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> qemu-xen offers better disk performances than qemu-xen-traditional
> because it supports Linux native AIO.

Does this take any account of whether the new qemu-xen dm is
installed ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKC3s-0004Pl-Mr; Tue, 17 Apr 2012 17:19:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKC3r-0004Pc-6r
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:19:27 +0000
Received: from [85.158.143.99:26394] by server-2.bemta-4.messagelabs.com id
	F1/5F-17550-E16AD8F4; Tue, 17 Apr 2012 17:19:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334683165!14418422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23507 invoked from network); 17 Apr 2012 17:19:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:19:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:19:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC3p-0006GW-G4; Tue, 17 Apr 2012 17:19:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC3p-0001eg-C7;
	Tue, 17 Apr 2012 18:19:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42522.203032.1240@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:19:22 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7c0fd18a2ba52da307ba.1333474566@probook.site>
References: <7c0fd18a2ba52da307ba.1333474566@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libvchan: fix build errors caused
	by	Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libvchan: fix build errors caused by Werror in io.c"):
> tools/libvchan: fix build errors caused by Werror in io.c

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKC3s-0004Pl-Mr; Tue, 17 Apr 2012 17:19:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKC3r-0004Pc-6r
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:19:27 +0000
Received: from [85.158.143.99:26394] by server-2.bemta-4.messagelabs.com id
	F1/5F-17550-E16AD8F4; Tue, 17 Apr 2012 17:19:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334683165!14418422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23507 invoked from network); 17 Apr 2012 17:19:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:19:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:19:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC3p-0006GW-G4; Tue, 17 Apr 2012 17:19:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC3p-0001eg-C7;
	Tue, 17 Apr 2012 18:19:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42522.203032.1240@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:19:22 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7c0fd18a2ba52da307ba.1333474566@probook.site>
References: <7c0fd18a2ba52da307ba.1333474566@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libvchan: fix build errors caused
	by	Werror in io.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libvchan: fix build errors caused by Werror in io.c"):
> tools/libvchan: fix build errors caused by Werror in io.c

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:23:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKC7l-0004cD-If; Tue, 17 Apr 2012 17:23:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKC7j-0004c5-J6
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 17:23:27 +0000
Received: from [85.158.138.51:3367] by server-1.bemta-3.messagelabs.com id
	BA/93-11491-E07AD8F4; Tue, 17 Apr 2012 17:23:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334683405!22560989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25260 invoked from network); 17 Apr 2012 17:23:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:23:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:23:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:23:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC7h-0006Hw-5L; Tue, 17 Apr 2012 17:23:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC7h-0001gT-4N;
	Tue, 17 Apr 2012 18:23:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42765.118047.700469@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:23:25 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, Anthony PERARD
	<anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>,
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
	[and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> Currently `xl vncviewer $dom` does not work because the VNC port is not
> registered in xenstore when using qemu-upstream. This patch attempted to fix
> this.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>


Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
> > Currently `xl vncviewer $dom` does not work because the VNC port is not
> > registered in xenstore when using qemu-upstream. This patch attempted to fix
> > this.
> 
> libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
> having such a thing in xenstore strikes me as something of a
> misfeature...
> 
> Otherwise: 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I think this is an acceptable lack-of-feature for now, certainly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:23:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKC7l-0004cD-If; Tue, 17 Apr 2012 17:23:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKC7j-0004c5-J6
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 17:23:27 +0000
Received: from [85.158.138.51:3367] by server-1.bemta-3.messagelabs.com id
	BA/93-11491-E07AD8F4; Tue, 17 Apr 2012 17:23:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334683405!22560989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25260 invoked from network); 17 Apr 2012 17:23:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:23:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:23:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:23:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC7h-0006Hw-5L; Tue, 17 Apr 2012 17:23:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC7h-0001gT-4N;
	Tue, 17 Apr 2012 18:23:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42765.118047.700469@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:23:25 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, Anthony PERARD
	<anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>,
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
	[and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> Currently `xl vncviewer $dom` does not work because the VNC port is not
> registered in xenstore when using qemu-upstream. This patch attempted to fix
> this.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>


Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
> > Currently `xl vncviewer $dom` does not work because the VNC port is not
> > registered in xenstore when using qemu-upstream. This patch attempted to fix
> > this.
> 
> libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
> having such a thing in xenstore strikes me as something of a
> misfeature...
> 
> Otherwise: 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I think this is an acceptable lack-of-feature for now, certainly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:26:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:26:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCA2-0004iJ-3o; Tue, 17 Apr 2012 17:25:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCA0-0004i8-Hc
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:25:48 +0000
Received: from [85.158.143.99:25691] by server-3.bemta-4.messagelabs.com id
	D2/8C-05853-B97AD8F4; Tue, 17 Apr 2012 17:25:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334683547!14287737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2934 invoked from network); 17 Apr 2012 17:25:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:25:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:25:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:25:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC9y-0006Id-TW; Tue, 17 Apr 2012 17:25:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC9y-0001gn-SW;
	Tue, 17 Apr 2012 18:25:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42906.867250.920616@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:25:46 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 1/7] libxl:
	libxl__device_disk_local_attach	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
> - make libxl_device_disk_local_attach/detach two internal functions;
> 
> - pass a gc rather than a ctx to them;
> 
> - introduce a new libxl_device_disk** parameter to
> libxl__device_disk_local_attach, the parameter is allocated on the gc by
> libxl__device_disk_local_attach. It is going to fill it with
> informations about the new locally attached disk.  The new
> libxl_device_disk should be passed to libxl_device_disk_local_detach
> afterwards.

Mixing the changes up with teh code motion makes this quite hard to
review.  Would it be easy to separate those out or should I do some
kind of manual hack to compare the old and new code ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:26:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:26:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCA2-0004iJ-3o; Tue, 17 Apr 2012 17:25:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCA0-0004i8-Hc
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:25:48 +0000
Received: from [85.158.143.99:25691] by server-3.bemta-4.messagelabs.com id
	D2/8C-05853-B97AD8F4; Tue, 17 Apr 2012 17:25:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334683547!14287737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2934 invoked from network); 17 Apr 2012 17:25:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:25:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:25:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:25:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKC9y-0006Id-TW; Tue, 17 Apr 2012 17:25:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKC9y-0001gn-SW;
	Tue, 17 Apr 2012 18:25:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42906.867250.920616@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:25:46 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 1/7] libxl:
	libxl__device_disk_local_attach	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
> - make libxl_device_disk_local_attach/detach two internal functions;
> 
> - pass a gc rather than a ctx to them;
> 
> - introduce a new libxl_device_disk** parameter to
> libxl__device_disk_local_attach, the parameter is allocated on the gc by
> libxl__device_disk_local_attach. It is going to fill it with
> informations about the new locally attached disk.  The new
> libxl_device_disk should be passed to libxl_device_disk_local_detach
> afterwards.

Mixing the changes up with teh code motion makes this quite hard to
review.  Would it be easy to separate those out or should I do some
kind of manual hack to compare the old and new code ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:27:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCBR-0004oA-JI; Tue, 17 Apr 2012 17:27:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCBQ-0004o3-Ox
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:27:16 +0000
Received: from [85.158.143.99:31309] by server-3.bemta-4.messagelabs.com id
	85/9D-05853-4F7AD8F4; Tue, 17 Apr 2012 17:27:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334683635!24073641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15809 invoked from network); 17 Apr 2012 17:27:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:27:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985543"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:27:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:27:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCBO-0006JE-0e; Tue, 17 Apr 2012 17:27:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCBN-0001h2-Vq;
	Tue, 17 Apr 2012 18:27:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42993.969557.680850@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:27:13 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter
	to	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter to libxl__device_generic_add"):
> Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
> XBT_NULL, allocate a proper one.
> 
> Update all the callers.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> +    int create_transaction = t == XBT_NULL;

Although I don't much like this style.  I would have written
  +    int create_transaction = !t;
but I guess you're not going to swallow that ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:27:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCBR-0004oA-JI; Tue, 17 Apr 2012 17:27:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCBQ-0004o3-Ox
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:27:16 +0000
Received: from [85.158.143.99:31309] by server-3.bemta-4.messagelabs.com id
	85/9D-05853-4F7AD8F4; Tue, 17 Apr 2012 17:27:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334683635!24073641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15809 invoked from network); 17 Apr 2012 17:27:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:27:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985543"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:27:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:27:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCBO-0006JE-0e; Tue, 17 Apr 2012 17:27:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCBN-0001h2-Vq;
	Tue, 17 Apr 2012 18:27:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.42993.969557.680850@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:27:13 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter
	to	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter to libxl__device_generic_add"):
> Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
> XBT_NULL, allocate a proper one.
> 
> Update all the callers.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> +    int create_transaction = t == XBT_NULL;

Although I don't much like this style.  I would have written
  +    int create_transaction = !t;
but I guess you're not going to swallow that ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:37:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCLC-00054t-R0; Tue, 17 Apr 2012 17:37:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCLB-00054j-5B
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:37:21 +0000
Received: from [85.158.138.51:18364] by server-10.bemta-3.messagelabs.com id
	84/10-29478-05AAD8F4; Tue, 17 Apr 2012 17:37:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334684239!18482337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22066 invoked from network); 17 Apr 2012 17:37:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:37:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:37:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:37:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCL9-0006MY-CV; Tue, 17 Apr 2012 17:37:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCL9-0001i0-BA;
	Tue, 17 Apr 2012 18:37:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.43599.157767.127615@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:37:19 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 3/7] libxl: introduce
	libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 3/7] libxl: introduce libxl__device_disk_add_t"):
> Introduce libxl__device_disk_add_t that takes an additional
> xs_transaction_t paramter.
> Implement libxl_device_disk_add using libxl__device_disk_add_t.
> Move libxl__device_from_disk to libxl_internal.c.

Is this supposed to be "no functional change" ?  If so it would really
help to say so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:37:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCLC-00054t-R0; Tue, 17 Apr 2012 17:37:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCLB-00054j-5B
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:37:21 +0000
Received: from [85.158.138.51:18364] by server-10.bemta-3.messagelabs.com id
	84/10-29478-05AAD8F4; Tue, 17 Apr 2012 17:37:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334684239!18482337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22066 invoked from network); 17 Apr 2012 17:37:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:37:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11985880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:37:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:37:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCL9-0006MY-CV; Tue, 17 Apr 2012 17:37:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCL9-0001i0-BA;
	Tue, 17 Apr 2012 18:37:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.43599.157767.127615@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:37:19 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 3/7] libxl: introduce
	libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 3/7] libxl: introduce libxl__device_disk_add_t"):
> Introduce libxl__device_disk_add_t that takes an additional
> xs_transaction_t paramter.
> Implement libxl_device_disk_add using libxl__device_disk_add_t.
> Move libxl__device_from_disk to libxl_internal.c.

Is this supposed to be "no functional change" ?  If so it would really
help to say so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:47:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCV1-0005Kn-28; Tue, 17 Apr 2012 17:47:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCUz-0005Ki-8F
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:47:29 +0000
Received: from [85.158.143.35:53453] by server-1.bemta-4.messagelabs.com id
	13/9E-20925-0BCAD8F4; Tue, 17 Apr 2012 17:47:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334684847!13683298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16180 invoked from network); 17 Apr 2012 17:47:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:47:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:47:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:47:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCUx-0006Pj-3I; Tue, 17 Apr 2012 17:47:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCUw-0001ic-VH;
	Tue, 17 Apr 2012 18:47:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.44206.42175.501006@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:47:26 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
	parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> Introduce a blkdev_start in xl.conf and pass it to
> libxl_domain_create_* and all the way through libxl_run_bootloader and
> libxl__device_disk_local_attach.

Surely this should be passed in the domain config structure rather
than being an adhoc parameter.

If the problem with that is that it really ought to be host-global and
come from xl.conf, then perhaps we need another config struct.  But
really I think that's overkill.  There is nothing wrong with taking
parameters from xl.conf and putting them in the libxl domain config.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:47:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCV1-0005Kn-28; Tue, 17 Apr 2012 17:47:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCUz-0005Ki-8F
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:47:29 +0000
Received: from [85.158.143.35:53453] by server-1.bemta-4.messagelabs.com id
	13/9E-20925-0BCAD8F4; Tue, 17 Apr 2012 17:47:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334684847!13683298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16180 invoked from network); 17 Apr 2012 17:47:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:47:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:47:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:47:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCUx-0006Pj-3I; Tue, 17 Apr 2012 17:47:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCUw-0001ic-VH;
	Tue, 17 Apr 2012 18:47:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.44206.42175.501006@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:47:26 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
	parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> Introduce a blkdev_start in xl.conf and pass it to
> libxl_domain_create_* and all the way through libxl_run_bootloader and
> libxl__device_disk_local_attach.

Surely this should be passed in the domain config structure rather
than being an adhoc parameter.

If the problem with that is that it really ought to be host-global and
come from xl.conf, then perhaps we need another config struct.  But
really I think that's overkill.  There is nothing wrong with taking
parameters from xl.conf and putting them in the libxl domain config.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:53:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCaY-0005T7-RJ; Tue, 17 Apr 2012 17:53:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCaX-0005Sw-Ua
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:53:14 +0000
Received: from [85.158.143.99:11323] by server-2.bemta-4.messagelabs.com id
	4F/47-17550-70EAD8F4; Tue, 17 Apr 2012 17:53:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334685190!25500946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3969 invoked from network); 17 Apr 2012 17:53:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:53:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:53:08 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCaR-0006S3-Lf; Tue, 17 Apr 2012 17:53:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCaR-0001j6-Kg;
	Tue, 17 Apr 2012 18:53:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.44544.739441.639648@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:53:04 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> +        char *blkdev_start, xs_transaction_t t)
> +{
> +    int devid = 0;
> +    char *vdev = libxl__strdup(gc, blkdev_start);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
> +
> +    do {
> +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> +        if (libxl__xs_read(gc, t,
> +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> +                        dompath, devid)) == NULL)
> +            return libxl__devid_to_vdev(gc, devid);

What if the error is not ENOENT ?

> +        vdev[strlen(vdev) - 1]++;
> +    } while(vdev[strlen(vdev) - 1] <= 'z');
              ^
Missing whitespace.

> +_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);

I think the terminology here needs to be corrected.  "vdev" is the
virtual device name supplied to libxl - a symbolic way of specifying a
devid in a guest-independent way.

Whereas what we actually mean is the non-portable name in this guest
OS for a device.  How about
  libxl__devid_to_localdev
?

> +static char *encode_disk_name(char *ptr, unsigned int n)

There is no clearly defined upper bound on the buffer space needed by
this function.

> diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> index 9e0ed6d..c8977ac 100644
> --- a/tools/libxl/libxl_netbsd.c
> +++ b/tools/libxl/libxl_netbsd.c
...
> +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> +{
> +    /* TODO */
> +    return NULL;
> +}

I guess this is going to be fixed in a future version of the patch ?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:53:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCaY-0005T7-RJ; Tue, 17 Apr 2012 17:53:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCaX-0005Sw-Ua
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:53:14 +0000
Received: from [85.158.143.99:11323] by server-2.bemta-4.messagelabs.com id
	4F/47-17550-70EAD8F4; Tue, 17 Apr 2012 17:53:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334685190!25500946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3969 invoked from network); 17 Apr 2012 17:53:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:53:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:53:08 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCaR-0006S3-Lf; Tue, 17 Apr 2012 17:53:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCaR-0001j6-Kg;
	Tue, 17 Apr 2012 18:53:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.44544.739441.639648@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:53:04 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> +        char *blkdev_start, xs_transaction_t t)
> +{
> +    int devid = 0;
> +    char *vdev = libxl__strdup(gc, blkdev_start);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
> +
> +    do {
> +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> +        if (libxl__xs_read(gc, t,
> +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> +                        dompath, devid)) == NULL)
> +            return libxl__devid_to_vdev(gc, devid);

What if the error is not ENOENT ?

> +        vdev[strlen(vdev) - 1]++;
> +    } while(vdev[strlen(vdev) - 1] <= 'z');
              ^
Missing whitespace.

> +_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);

I think the terminology here needs to be corrected.  "vdev" is the
virtual device name supplied to libxl - a symbolic way of specifying a
devid in a guest-independent way.

Whereas what we actually mean is the non-portable name in this guest
OS for a device.  How about
  libxl__devid_to_localdev
?

> +static char *encode_disk_name(char *ptr, unsigned int n)

There is no clearly defined upper bound on the buffer space needed by
this function.

> diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> index 9e0ed6d..c8977ac 100644
> --- a/tools/libxl/libxl_netbsd.c
> +++ b/tools/libxl/libxl_netbsd.c
...
> +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> +{
> +    /* TODO */
> +    return NULL;
> +}

I guess this is going to be fixed in a future version of the patch ?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:58:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCfa-0005bp-JA; Tue, 17 Apr 2012 17:58:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCfZ-0005bi-I4
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:58:25 +0000
Received: from [85.158.138.51:26805] by server-2.bemta-3.messagelabs.com id
	47/3B-09269-04FAD8F4; Tue, 17 Apr 2012 17:58:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334685503!22522265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 17 Apr 2012 17:58:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:58:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:58:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:58:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCfW-0006Uy-L1; Tue, 17 Apr 2012 17:58:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCfW-0001je-Jr;
	Tue, 17 Apr 2012 18:58:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.44862.597858.180770@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:58:22 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement
	QDISK	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
...
> +                    t = xs_transaction_start(ctx->xsh);

This transaction should be in the local variables block for the whole
function, and initialised to 0.

> +                    /* use 0 as the domid of the toolstack domain for now */
> +                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);

Should this 0 be abstracted into a #define or a variable ?

> +                    if (tmpdisk->vdev == NULL) {
> +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                                "libxl__alloc_vdev failed\n");
> +                        xs_transaction_end(ctx->xsh, t, 1);

And then all these xs_transaction_end calls turn into one call in the
exit path.

> +                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);

Perhaps you'd like to use GCSPRINTF now that we have it.

>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
> -                       disk->pdev_path);

Perhaps you'd like to use LOG(DEBUG, ....") now that we have it ?

> -            dev = tmpdisk->pdev_path;
> +    switch (disk->backend) {
> +        case LIBXL_DISK_BACKEND_QDISK:
> +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {

This replicates the logic earlier, which decided whether to use a
qdisk.  I think it would be better to remember whether we did use a
qdisk and detach it iff so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 17:58:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 17:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCfa-0005bp-JA; Tue, 17 Apr 2012 17:58:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCfZ-0005bi-I4
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 17:58:25 +0000
Received: from [85.158.138.51:26805] by server-2.bemta-3.messagelabs.com id
	47/3B-09269-04FAD8F4; Tue, 17 Apr 2012 17:58:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334685503!22522265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 17 Apr 2012 17:58:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 17:58:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 17:58:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 18:58:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCfW-0006Uy-L1; Tue, 17 Apr 2012 17:58:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCfW-0001je-Jr;
	Tue, 17 Apr 2012 18:58:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.44862.597858.180770@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 18:58:22 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement
	QDISK	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
...
> +                    t = xs_transaction_start(ctx->xsh);

This transaction should be in the local variables block for the whole
function, and initialised to 0.

> +                    /* use 0 as the domid of the toolstack domain for now */
> +                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);

Should this 0 be abstracted into a #define or a variable ?

> +                    if (tmpdisk->vdev == NULL) {
> +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                                "libxl__alloc_vdev failed\n");
> +                        xs_transaction_end(ctx->xsh, t, 1);

And then all these xs_transaction_end calls turn into one call in the
exit path.

> +                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);

Perhaps you'd like to use GCSPRINTF now that we have it.

>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
> -                       disk->pdev_path);

Perhaps you'd like to use LOG(DEBUG, ....") now that we have it ?

> -            dev = tmpdisk->pdev_path;
> +    switch (disk->backend) {
> +        case LIBXL_DISK_BACKEND_QDISK:
> +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {

This replicates the logic earlier, which decided whether to use a
qdisk.  I think it would be better to remember whether we did use a
qdisk and detach it iff so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCj2-0005p8-Cv; Tue, 17 Apr 2012 18:02:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCj0-0005ow-47
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:01:58 +0000
Received: from [193.109.254.147:15404] by server-8.bemta-14.messagelabs.com id
	10/3E-23244-510BD8F4; Tue, 17 Apr 2012 18:01:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334685716!5011170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2243 invoked from network); 17 Apr 2012 18:01:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 18:01:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 19:01:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCiy-0006W3-9m; Tue, 17 Apr 2012 18:01:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCiy-0001k2-7d;
	Tue, 17 Apr 2012 19:01:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.45076.153077.759249@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 19:01:56 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach:
	wait	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach: wait for state "connected""):
> In order to make sure that the block device is available and ready to be
> used, wait for state "connected" in the backend before returning.
...
> +        be_path = libxl__device_backend_path(gc, &device);
> +        rc = libxl__wait_for_backend(gc, be_path, "4");

Ideally we shouldn't be introducing new calls to functions called
"libxl__wait_for".  Although I appreciate you may not want to convert
libxl__device_disk_local_attach and all its callers to use callbacks.

> +        if (rc < 0) {
> +            libxl__device_disk_local_detach(gc, tmpdisk);
> +            return NULL;

Again, this is the "free something on every exit path" error handling
style.  Surely we should have a "goto out" or "goto out_err" or
something ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCj2-0005p8-Cv; Tue, 17 Apr 2012 18:02:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCj0-0005ow-47
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:01:58 +0000
Received: from [193.109.254.147:15404] by server-8.bemta-14.messagelabs.com id
	10/3E-23244-510BD8F4; Tue, 17 Apr 2012 18:01:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334685716!5011170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2243 invoked from network); 17 Apr 2012 18:01:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 18:01:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 19:01:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCiy-0006W3-9m; Tue, 17 Apr 2012 18:01:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCiy-0001k2-7d;
	Tue, 17 Apr 2012 19:01:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.45076.153077.759249@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 19:01:56 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach:
	wait	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach: wait for state "connected""):
> In order to make sure that the block device is available and ready to be
> used, wait for state "connected" in the backend before returning.
...
> +        be_path = libxl__device_backend_path(gc, &device);
> +        rc = libxl__wait_for_backend(gc, be_path, "4");

Ideally we shouldn't be introducing new calls to functions called
"libxl__wait_for".  Although I appreciate you may not want to convert
libxl__device_disk_local_attach and all its callers to use callbacks.

> +        if (rc < 0) {
> +            libxl__device_disk_local_detach(gc, tmpdisk);
> +            return NULL;

Again, this is the "free something on every exit path" error handling
style.  Surely we should have a "goto out" or "goto out_err" or
something ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:08:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCos-0005zz-7X; Tue, 17 Apr 2012 18:08:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKCor-0005zu-82
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:08:01 +0000
Received: from [85.158.139.83:12593] by server-12.bemta-5.messagelabs.com id
	DF/F2-05587-081BD8F4; Tue, 17 Apr 2012 18:08:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334686077!12975833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12807 invoked from network); 17 Apr 2012 18:07:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 18:07:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 19:07:56 +0100
Date: Tue, 17 Apr 2012 19:12:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com, alevy@redhat.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH BUILD FIX 0/2] build xc_hvm_inject_msi on Xen <
	4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this small patch series fixes the build breakage introduced by
f1dbf015dfb0aa7f66f710a1f1bc58b662951de2 with Xen < 4.2.

The problem is that xc_hvm_inject_msi is only defined from Xen 4.2
onwards so we need to provide a compatibility function for older Xen
versions.


Stefano Stabellini (2):
      xen,configure: detect Xen 4.2
      xen: add a dummy xc_hvm_inject_msi for Xen < 4.2

 configure       |   25 +++++++++++++++++++++++++
 hw/pc.c         |    2 +-
 hw/xen.h        |   10 ++++++++++
 hw/xen_common.h |   15 +++++++++++++++
 xen-all.c       |    2 +-
 5 files changed, 52 insertions(+), 2 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git build_fix

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:08:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCos-0005zz-7X; Tue, 17 Apr 2012 18:08:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKCor-0005zu-82
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:08:01 +0000
Received: from [85.158.139.83:12593] by server-12.bemta-5.messagelabs.com id
	DF/F2-05587-081BD8F4; Tue, 17 Apr 2012 18:08:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334686077!12975833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12807 invoked from network); 17 Apr 2012 18:07:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 18:07:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 19:07:56 +0100
Date: Tue, 17 Apr 2012 19:12:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com, alevy@redhat.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH BUILD FIX 0/2] build xc_hvm_inject_msi on Xen <
	4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this small patch series fixes the build breakage introduced by
f1dbf015dfb0aa7f66f710a1f1bc58b662951de2 with Xen < 4.2.

The problem is that xc_hvm_inject_msi is only defined from Xen 4.2
onwards so we need to provide a compatibility function for older Xen
versions.


Stefano Stabellini (2):
      xen,configure: detect Xen 4.2
      xen: add a dummy xc_hvm_inject_msi for Xen < 4.2

 configure       |   25 +++++++++++++++++++++++++
 hw/pc.c         |    2 +-
 hw/xen.h        |   10 ++++++++++
 hw/xen_common.h |   15 +++++++++++++++
 xen-all.c       |    2 +-
 5 files changed, 52 insertions(+), 2 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git build_fix

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCqp-00068b-Dj; Tue, 17 Apr 2012 18:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKCqn-00068G-7x
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:10:01 +0000
Received: from [85.158.143.35:28864] by server-3.bemta-4.messagelabs.com id
	79/8C-05853-8F1BD8F4; Tue, 17 Apr 2012 18:10:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334686197!7510814!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQwOTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21518 invoked from network); 17 Apr 2012 18:09:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:09:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330923600"; d="scan'208";a="190780619"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:08:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 14:08:16 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SKCp0-0008NB-D7; Tue, 17 Apr 2012 19:08:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 17 Apr 2012 19:13:07 +0100
Message-ID: <1334686387-2350-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com, alevy@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH BUILD FIX 2/2] xen: add a dummy
	xc_hvm_inject_msi for Xen < 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xc_hvm_inject_msi is only available on Xen >= 4.2: add a dummy
compatibility function for Xen < 4.2.

Also enable msi support only on Xen >= 4.2.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pc.c         |    2 +-
 hw/xen.h        |   10 ++++++++++
 hw/xen_common.h |   15 +++++++++++++++
 xen-all.c       |    2 +-
 4 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 1f5aacb..4d34a33 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -916,7 +916,7 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
         msi_supported = true;
     }
 
-    if (xen_enabled()) {
+    if (xen_msi_support()) {
         msi_supported = true;
     }
 
diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..3ae4cd0 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -57,4 +57,14 @@ void xen_register_framebuffer(struct MemoryRegion *mr);
 #  define HVM_MAX_VCPUS 32
 #endif
 
+static inline int xen_msi_support(void)
+{
+#if defined(CONFIG_XEN_CTRL_INTERFACE_VERSION) \
+    && CONFIG_XEN_CTRL_INTERFACE_VERSION >= 420
+    return xen_enabled();
+#else
+    return 0;
+#endif
+}
+
 #endif /* QEMU_HW_XEN_H */
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..7043c14 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -133,6 +133,21 @@ static inline int xc_fd(xc_interface *xen_xc)
 }
 #endif
 
+/* Xen before 4.2 */
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
+static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
+        uint64_t addr, uint32_t data)
+{
+    return -ENOSYS;
+}
+#else
+static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
+        uint64_t addr, uint32_t data)
+{
+    return xc_hvm_inject_msi(xen_xc, dom, addr, data);
+}
+#endif
+
 void destroy_hvm_domain(void);
 
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/xen-all.c b/xen-all.c
index a08eec0..bdf9c0f 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -129,7 +129,7 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 
 void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
 {
-    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+    xen_xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
 }
 
 static void xen_suspend_notifier(Notifier *notifier, void *data)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCqp-00068b-Dj; Tue, 17 Apr 2012 18:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKCqn-00068G-7x
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:10:01 +0000
Received: from [85.158.143.35:28864] by server-3.bemta-4.messagelabs.com id
	79/8C-05853-8F1BD8F4; Tue, 17 Apr 2012 18:10:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334686197!7510814!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQwOTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21518 invoked from network); 17 Apr 2012 18:09:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:09:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330923600"; d="scan'208";a="190780619"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:08:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 14:08:16 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SKCp0-0008NB-D7; Tue, 17 Apr 2012 19:08:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 17 Apr 2012 19:13:07 +0100
Message-ID: <1334686387-2350-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com, alevy@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH BUILD FIX 2/2] xen: add a dummy
	xc_hvm_inject_msi for Xen < 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xc_hvm_inject_msi is only available on Xen >= 4.2: add a dummy
compatibility function for Xen < 4.2.

Also enable msi support only on Xen >= 4.2.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pc.c         |    2 +-
 hw/xen.h        |   10 ++++++++++
 hw/xen_common.h |   15 +++++++++++++++
 xen-all.c       |    2 +-
 4 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 1f5aacb..4d34a33 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -916,7 +916,7 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
         msi_supported = true;
     }
 
-    if (xen_enabled()) {
+    if (xen_msi_support()) {
         msi_supported = true;
     }
 
diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..3ae4cd0 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -57,4 +57,14 @@ void xen_register_framebuffer(struct MemoryRegion *mr);
 #  define HVM_MAX_VCPUS 32
 #endif
 
+static inline int xen_msi_support(void)
+{
+#if defined(CONFIG_XEN_CTRL_INTERFACE_VERSION) \
+    && CONFIG_XEN_CTRL_INTERFACE_VERSION >= 420
+    return xen_enabled();
+#else
+    return 0;
+#endif
+}
+
 #endif /* QEMU_HW_XEN_H */
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..7043c14 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -133,6 +133,21 @@ static inline int xc_fd(xc_interface *xen_xc)
 }
 #endif
 
+/* Xen before 4.2 */
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
+static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
+        uint64_t addr, uint32_t data)
+{
+    return -ENOSYS;
+}
+#else
+static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
+        uint64_t addr, uint32_t data)
+{
+    return xc_hvm_inject_msi(xen_xc, dom, addr, data);
+}
+#endif
+
 void destroy_hvm_domain(void);
 
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/xen-all.c b/xen-all.c
index a08eec0..bdf9c0f 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -129,7 +129,7 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 
 void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
 {
-    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+    xen_xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
 }
 
 static void xen_suspend_notifier(Notifier *notifier, void *data)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCqp-00068m-QK; Tue, 17 Apr 2012 18:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKCqo-00068U-9K
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:10:02 +0000
Received: from [85.158.143.35:28913] by server-1.bemta-4.messagelabs.com id
	B6/FD-20925-9F1BD8F4; Tue, 17 Apr 2012 18:10:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334686197!7510814!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQwOTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21541 invoked from network); 17 Apr 2012 18:10:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330923600"; d="scan'208";a="190780617"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:08:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 14:08:15 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SKCp0-0008NB-CZ; Tue, 17 Apr 2012 19:08:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 17 Apr 2012 19:13:06 +0100
Message-ID: <1334686387-2350-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com, alevy@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH BUILD FIX 1/2] xen,configure: detect Xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen 4.2 is the first to support xc_hvm_inject_msi: use it to determine
if we are running on it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 1d94acd..38f45f3 100755
--- a/configure
+++ b/configure
@@ -1398,6 +1398,31 @@ int main(void) {
   xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
   xc_gnttab_open(NULL, 0);
   xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf0000000, 0x00000000);
+  return 0;
+}
+EOF
+      compile_prog "" "$xen_libs"
+    ) ; then
+    xen_ctrl_version=420
+    xen=yes
+
+  elif (
+      cat > $TMPC <<EOF
+#include <xenctrl.h>
+#include <xs.h>
+#include <stdint.h>
+#include <xen/hvm/hvm_info_table.h>
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc;
+  xs_daemon_open();
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_gnttab_open(NULL, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
   return 0;
 }
 EOF
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCqp-00068m-QK; Tue, 17 Apr 2012 18:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKCqo-00068U-9K
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:10:02 +0000
Received: from [85.158.143.35:28913] by server-1.bemta-4.messagelabs.com id
	B6/FD-20925-9F1BD8F4; Tue, 17 Apr 2012 18:10:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334686197!7510814!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQwOTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21541 invoked from network); 17 Apr 2012 18:10:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330923600"; d="scan'208";a="190780617"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 14:08:26 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Apr 2012 14:08:15 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SKCp0-0008NB-CZ; Tue, 17 Apr 2012 19:08:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 17 Apr 2012 19:13:06 +0100
Message-ID: <1334686387-2350-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204171825200.26786@kaball-desktop>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com, alevy@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH BUILD FIX 1/2] xen,configure: detect Xen 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen 4.2 is the first to support xc_hvm_inject_msi: use it to determine
if we are running on it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 1d94acd..38f45f3 100755
--- a/configure
+++ b/configure
@@ -1398,6 +1398,31 @@ int main(void) {
   xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
   xc_gnttab_open(NULL, 0);
   xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf0000000, 0x00000000);
+  return 0;
+}
+EOF
+      compile_prog "" "$xen_libs"
+    ) ; then
+    xen_ctrl_version=420
+    xen=yes
+
+  elif (
+      cat > $TMPC <<EOF
+#include <xenctrl.h>
+#include <xs.h>
+#include <stdint.h>
+#include <xen/hvm/hvm_info_table.h>
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc;
+  xs_daemon_open();
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_gnttab_open(NULL, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
   return 0;
 }
 EOF
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:16:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCwW-0006kc-LQ; Tue, 17 Apr 2012 18:15:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCwV-0006kX-TH
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:15:56 +0000
Received: from [85.158.138.51:39399] by server-8.bemta-3.messagelabs.com id
	46/9A-24428-A53BD8F4; Tue, 17 Apr 2012 18:15:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334686554!22382931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11567 invoked from network); 17 Apr 2012 18:15:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:15:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 18:15:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 19:15:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCwT-0006c4-BG; Tue, 17 Apr 2012 18:15:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCwT-0001o6-A8;
	Tue, 17 Apr 2012 19:15:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.45913.257023.201323@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 19:15:53 +0100
To: Mathieu =?iso-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mathieu Gagn=E9 writes ("[Xen-devel] [PATCH 0 of 4 v2] xl: add support for =
vif rate limiting"):
> This patch series implements the required plumbering for vif rate limitin=
g in libxl/xl.

Thanks, I have applied the first two.

Whe you repost can you please make sure to wrap the commit messages to
70 columns or so ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:16:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKCwW-0006kc-LQ; Tue, 17 Apr 2012 18:15:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKCwV-0006kX-TH
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:15:56 +0000
Received: from [85.158.138.51:39399] by server-8.bemta-3.messagelabs.com id
	46/9A-24428-A53BD8F4; Tue, 17 Apr 2012 18:15:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334686554!22382931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11567 invoked from network); 17 Apr 2012 18:15:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 18:15:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,437,1330905600"; d="scan'208";a="11986494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 18:15:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 19:15:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKCwT-0006c4-BG; Tue, 17 Apr 2012 18:15:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKCwT-0001o6-A8;
	Tue, 17 Apr 2012 19:15:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20365.45913.257023.201323@mariner.uk.xensource.com>
Date: Tue, 17 Apr 2012 19:15:53 +0100
To: Mathieu =?iso-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mathieu Gagn=E9 writes ("[Xen-devel] [PATCH 0 of 4 v2] xl: add support for =
vif rate limiting"):
> This patch series implements the required plumbering for vif rate limitin=
g in libxl/xl.

Thanks, I have applied the first two.

Whe you repost can you please make sure to wrap the commit messages to
70 columns or so ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKD4M-0006zM-N7; Tue, 17 Apr 2012 18:24:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKD4L-0006zF-9Y
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:24:01 +0000
Received: from [85.158.143.99:32331] by server-1.bemta-4.messagelabs.com id
	8D/F6-20925-045BD8F4; Tue, 17 Apr 2012 18:24:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334687038!20687296!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12574 invoked from network); 17 Apr 2012 18:24:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 18:24:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HINull029520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 18:23:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HINtlc029669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 18:23:56 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HINt19006450; Tue, 17 Apr 2012 13:23:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 11:23:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 506284031D; Tue, 17 Apr 2012 14:18:56 -0400 (EDT)
Date: Tue, 17 Apr 2012 14:18:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120417181856.GA12971@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
	<20120417160208.GB28477@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514CDEF@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233514CDEF@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090201.4F8DB53D.0070,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
	bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 05:06:49PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Tue, Apr 17, 2012 at 12:55:49PM +0000, Liu, Jinsong wrote:
> >> Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
> >>>>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
> >>>>> 2001
> >>>> From: Liu, Jinsong <jinsong.liu@intel.com>
> >>>> Date: Mon, 16 Apr 2012 00:16:58 +0800
> >>>> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce
> >>>> back point 
> >>>> 
> >>>> When xen hyeprvisor inject vMCE to guest, use native mce handler to
> >>>> handle it
> >>> 
> >>> hypervisor
> >>> 
> >>>> 
> >>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >>>> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> >>>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> >>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> >>>>  --- arch/x86/xen/enlighten.c |   10 +++++++---
> >>>>  1 files changed, 7 insertions(+), 3 deletions(-)
> >>>> 
> >>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >>>> index 15628d4..346ba64 100644 --- a/arch/x86/xen/enlighten.c
> >>>> +++ b/arch/x86/xen/enlighten.c
> >>>> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
> >>>> gate_desc *val,  	/* 
> >>>>  	 * Look for known traps using IST, and substitute them
> >>>>  	 * appropriately.  The debugger ones are the only ones we care
> >>>> -	 * about.  Xen will handle faults like double_fault and
> >>>> -	 * machine_check, so we should never see them.  Warn if
> >>>> +	 * about.  Xen will handle faults like double_fault,
> >>>> +	 * so we should never see them.  Warn if
> >>>>  	 * there's an unexpected IST-using fault handler.  	 */
> >>>>  	if (addr == (unsigned long)debug)
> >>>> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
> >>>>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
> >>>>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
> >>>> +		/* +		 * when xen hyeprvisor inject vMCE to guest,
> >>>> +		 * use native mce handler to handle it
> >>>> +		 */
> >>>> +		;
> >>> 
> >>> 
> >>> Can you just take the check out?
> >> 
> >> What do you mean by 'check out'? remove
> >> else if (addr == (unsigned long) machine_check) {
> >> 	;
> >> }
> >> ?
> >> 
> >> That would fail to register mce bounce back point.
> > 
> > Right, b/c right after we hit this check:
> >   /* Some other trap using IST? */
> >  639                 if (WARN_ON(val->ist != 0))
> >  640                         return 0;
> >  641         }
> > 
> > .. And the val->ist is not set for MCEs right?
> 
> No, mce ist is set as 0/5 (32/64), set_intr_gate_ist(X86_TRAP_MC, &machine_check, MCE_STACK); 

OK. then your idea is the right one. Please just fix the spelling and
re-submit.

> 
> > 
> >> 
> >>> 
> >>> 
> >>>>  #endif
> >>>>  	} else {
> >>>>  		/* Some other trap using IST? */
> >>>> --
> >>>> 1.7.1
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 18:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 18:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKD4M-0006zM-N7; Tue, 17 Apr 2012 18:24:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKD4L-0006zF-9Y
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 18:24:01 +0000
Received: from [85.158.143.99:32331] by server-1.bemta-4.messagelabs.com id
	8D/F6-20925-045BD8F4; Tue, 17 Apr 2012 18:24:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334687038!20687296!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12574 invoked from network); 17 Apr 2012 18:24:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 18:24:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HINull029520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 18:23:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HINtlc029669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 18:23:56 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HINt19006450; Tue, 17 Apr 2012 13:23:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 11:23:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 506284031D; Tue, 17 Apr 2012 14:18:56 -0400 (EDT)
Date: Tue, 17 Apr 2012 14:18:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120417181856.GA12971@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335146A7A@SHSMSX101.ccr.corp.intel.com>
	<20120416202821.GC14982@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514BFD4@SHSMSX101.ccr.corp.intel.com>
	<20120417160208.GB28477@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233514CDEF@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233514CDEF@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090201.4F8DB53D.0070,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Register native mce handler as vMCE
	bounce back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 05:06:49PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Tue, Apr 17, 2012 at 12:55:49PM +0000, Liu, Jinsong wrote:
> >> Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Apr 16, 2012 at 01:07:35AM +0000, Liu, Jinsong wrote:
> >>>>> From 76e40a60878ff72986fd8d92611400195ae0f997 Mon Sep 17 00:00:00
> >>>>> 2001
> >>>> From: Liu, Jinsong <jinsong.liu@intel.com>
> >>>> Date: Mon, 16 Apr 2012 00:16:58 +0800
> >>>> Subject: [PATCH 2/2] Register native mce handler as vMCE bounce
> >>>> back point 
> >>>> 
> >>>> When xen hyeprvisor inject vMCE to guest, use native mce handler to
> >>>> handle it
> >>> 
> >>> hypervisor
> >>> 
> >>>> 
> >>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >>>> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> >>>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> >>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> >>>>  --- arch/x86/xen/enlighten.c |   10 +++++++---
> >>>>  1 files changed, 7 insertions(+), 3 deletions(-)
> >>>> 
> >>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >>>> index 15628d4..346ba64 100644 --- a/arch/x86/xen/enlighten.c
> >>>> +++ b/arch/x86/xen/enlighten.c
> >>>> @@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const
> >>>> gate_desc *val,  	/* 
> >>>>  	 * Look for known traps using IST, and substitute them
> >>>>  	 * appropriately.  The debugger ones are the only ones we care
> >>>> -	 * about.  Xen will handle faults like double_fault and
> >>>> -	 * machine_check, so we should never see them.  Warn if
> >>>> +	 * about.  Xen will handle faults like double_fault,
> >>>> +	 * so we should never see them.  Warn if
> >>>>  	 * there's an unexpected IST-using fault handler.  	 */
> >>>>  	if (addr == (unsigned long)debug)
> >>>> @@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const
> >>>>  gate_desc *val,  		return 0; #ifdef CONFIG_X86_MCE
> >>>>  	} else if (addr == (unsigned long)machine_check) { -		return 0;
> >>>> +		/* +		 * when xen hyeprvisor inject vMCE to guest,
> >>>> +		 * use native mce handler to handle it
> >>>> +		 */
> >>>> +		;
> >>> 
> >>> 
> >>> Can you just take the check out?
> >> 
> >> What do you mean by 'check out'? remove
> >> else if (addr == (unsigned long) machine_check) {
> >> 	;
> >> }
> >> ?
> >> 
> >> That would fail to register mce bounce back point.
> > 
> > Right, b/c right after we hit this check:
> >   /* Some other trap using IST? */
> >  639                 if (WARN_ON(val->ist != 0))
> >  640                         return 0;
> >  641         }
> > 
> > .. And the val->ist is not set for MCEs right?
> 
> No, mce ist is set as 0/5 (32/64), set_intr_gate_ist(X86_TRAP_MC, &machine_check, MCE_STACK); 

OK. then your idea is the right one. Please just fix the spelling and
re-submit.

> 
> > 
> >> 
> >>> 
> >>> 
> >>>>  #endif
> >>>>  	} else {
> >>>>  		/* Some other trap using IST? */
> >>>> --
> >>>> 1.7.1
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEz4-0000Ti-5F; Tue, 17 Apr 2012 20:26:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEz2-0000TJ-EJ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:40 +0000
Received: from [85.158.143.35:45142] by server-1.bemta-4.messagelabs.com id
	C8/4D-20925-FF1DD8F4; Tue, 17 Apr 2012 20:26:39 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334694395!12882682!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22368 invoked from network); 17 Apr 2012 20:26:36 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-10.tower-21.messagelabs.com with SMTP;
	17 Apr 2012 20:26:36 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 9CE0023A69; Tue, 17 Apr 2012 16:34:52 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: *
X-Spam-Status: No, score=1.4 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_22,
	J_CHICKENPOX_43,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no 
	version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id CD900245B9;
	Tue, 17 Apr 2012 16:34:46 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 28DB2281A9; Mon, 16 Apr 2012 23:52:53 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: cf61db286077f7b098665d3315bc3fb4e89a4816
Message-Id: <cf61db286077f7b09866.1334634686@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:26 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 v3] xl: add "check-xl-vif-parse" test
	script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyB0ZXN0IHNjcmlwdCBydW5zICJ4bCAtTiBuZXR3b3JrLWF0dGFjaCAwIDxmb29iYXI+IiBh
Z2FpbnN0IHZhcmlvdXMKcmF0ZSBzeW50YXggYW5kIGNoZWNrcyB0aGF0IHRoZSBvdXRwdXQgaXMg
YXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIu
Y29tPgpBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UgYi90b29scy9saWJ4bC9j
aGVjay14bC12aWYtcGFyc2UKbmV3IGZpbGUgbW9kZSAxMDA3NTUKLS0tIC9kZXYvbnVsbAorKysg
Yi90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UKQEAgLTAsMCArMSwyMDkgQEAKKyMhL2Jp
bi9iYXNoCisKK3NldCAtZQorCitpZiBbIC14IC4veGwgXSA7IHRoZW4KKyAgICBleHBvcnQgTERf
TElCUkFSWV9QQVRIPS4KKyAgICBYTD0uL3hsCitlbHNlCisgICAgWEw9eGwKK2ZpCisKK2ZwcmVm
aXg9dG1wLmNoZWNrLXhsLXZpZi1wYXJzZQorCitleHBlY3RlZCAoKSB7CisgICAgY2F0ID4kZnBy
ZWZpeC5leHBlY3RlZAorfQorCitmYWlsdXJlcz0wCisKK29uZSAoKSB7CisgICAgZXhwZWN0ZWRf
cmM9JDE7IHNoaWZ0CisgICAgcHJpbnRmICJ0ZXN0IGNhc2UgJXMuLi5cbiIgIiQqIgorICAgIHNl
dCArZQorICAgICR7WEx9IC1OIG5ldHdvcmstYXR0YWNoIDAgIiRAIiA8L2Rldi9udWxsID4kZnBy
ZWZpeC5hY3R1YWwgMj4vZGV2L251bGwKKyAgICBhY3R1YWxfcmM9JD8KKyAgICBkaWZmIC11ICRm
cHJlZml4LmV4cGVjdGVkICRmcHJlZml4LmFjdHVhbAorICAgIGRpZmZfcmM9JD8KKyAgICBzZXQg
LWUKKyAgICBpZiBbICRhY3R1YWxfcmMgIT0gJGV4cGVjdGVkX3JjIF0gfHwgWyAkZGlmZl9yYyAh
PSAwIF07IHRoZW4KKyAgICAgICAgZWNobyA+JjIgInRlc3QgY2FzZSBcYCQqJyBmYWlsZWQgKCRh
Y3R1YWxfcmMgJGRpZmZfcmMpIgorICAgICAgICBmYWlsdXJlcz0kKCggJGZhaWx1cmVzICsgMSAp
KQorICAgIGZpCit9CisKK2NvbXBsZXRlICgpIHsKKyAgICBpZiBbICIkZmFpbHVyZXMiID0gMCBd
OyB0aGVuCisgICAgICAgIGVjaG8gYWxsIG9rLjsgZXhpdCAwCisgICAgZWxzZQorICAgICAgICBl
Y2hvICIkZmFpbHVyZXMgdGVzdHMgZmFpbGVkLiI7IGV4aXQgMQorICAgIGZpCit9CisKK2U9MjU1
CisKKworIy0tLS0tLS0tLS0gdGVzdCBkYXRhIC0tLS0tLS0tLS0KKworIyB0ZXN0IGludmFsaWQg
dmlmIGNvbmZpZworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lIDEgZm9vCisKKyMgdGVzdCBpbnZh
bGlkIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDwvZGV2L251bGwKK29uZSAkZSByYXRlPWZvbworb25l
ICRlIHJhdGU9Zm9vCitvbmUgJGUgcmF0ZT0xME1CCitvbmUgJGUgcmF0ZT0xME1CL20KK29uZSAk
ZSByYXRlPTEwWkIKK29uZSAkZSByYXRlPTEwWkIvcworb25lICRlIHJhdGU9MTBaQi9tCisKKyMg
dGVzdCBiL3MgYW5kIEIvcyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAg
ImJhY2tlbmRfZG9taWQiOiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAg
Im1vZGVsIjogbnVsbCwKKyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAi
OiBudWxsLAorICAgICJicmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJz
Y3JpcHQiOiBudWxsLAorICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJf
aW50ZXJ2YWwiOiAxMDAwMDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQor
CitFTkQKKworb25lIDAgcmF0ZT0xNjAwMDAwMGIvcworb25lIDAgcmF0ZT0xNjAwMDAwMGIvc0A1
MG1zCitvbmUgMCByYXRlPTIwMDAwMDBCL3MKK29uZSAwIHJhdGU9MjAwMDAwMEIvc0A1MG1zCisK
KyMgdGVzdCBLYi9zIGFuZCBLQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsK
KyAgICAiYmFja2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwK
KyAgICAibW9kZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAg
ICJpcCI6IG51bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisg
ICAgInNjcmlwdCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVz
X3Blcl9pbnRlcnZhbCI6IDEwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9
CisKK0VORAorb25lIDAgcmF0ZT0xNktiL3MKK29uZSAwIHJhdGU9MTZLYi9zQDUwbXMKK29uZSAw
IHJhdGU9MktCL3MKK29uZSAwIHJhdGU9MktCL3NANTBtcworCisjIHRlc3QgTWIvcyBhbmQgTUIv
cyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAgImJhY2tlbmRfZG9taWQi
OiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAgIm1vZGVsIjogbnVsbCwK
KyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAiOiBudWxsLAorICAgICJi
cmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJzY3JpcHQiOiBudWxsLAor
ICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiOiAxMDAw
MDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJh
dGU9MTZNYi9zCitvbmUgMCByYXRlPTE2TWIvc0A1MG1zCitvbmUgMCByYXRlPTJNQi9zCitvbmUg
MCByYXRlPTJNQi9zQDUwbXMKKworIyB0ZXN0IEdiL3MgYW5kIEdCL3MgcmF0ZSB1bml0cworZXhw
ZWN0ZWQgPDxFTkQKK3ZpZjogeworICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQi
OiAwLAorICAgICJtdHUiOiAwLAorICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDow
MDowMDowMDowMDowMCIsCisgICAgImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAg
ICAiaWZuYW1lIjogbnVsbCwKKyAgICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51
bGwsCisgICAgInJhdGVfYnl0ZXNfcGVyX2ludGVydmFsIjogNTAwMDAwMDAsCisgICAgInJhdGVf
aW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJhdGU9OEdiL3MKK29uZSAw
IHJhdGU9OEdiL3NANTBtcworb25lIDAgcmF0ZT0xR0Ivcworb25lIDAgcmF0ZT0xR0Ivc0A1MG1z
CisKKyMgdGVzdCByYXRlIG92ZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0
ZT00Mjk0OTY3Mjk2Yi9zCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk2S2Ivcworb25lICRlIHJhdGU9
NDI5NDk2NzI5Nk1iL3MKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTZHYi9zCisKKyMgdGVzdCByYXRl
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MEIvcworCisjIHRl
c3QgaW52YWxpZCByZXBsZW5pc2htZW50IGludGVydmFsCitleHBlY3RlZCA8L2Rldi9udWxsCitv
bmUgJGUgcmF0ZT0xME1iL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1iL3NAMTBoCitvbmUgJGUgcmF0
ZT0xME1CL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1CL3NAMTBoCisKKyMgdGVzdCByZXBsZW5pc2ht
ZW50IGludGVydmFsIGluIHNlY29uZHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsKKyAgICAiYmFj
a2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwKKyAgICAibW9k
ZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAgICJpcCI6IG51
bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisgICAgInNjcmlw
dCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVzX3Blcl9pbnRl
cnZhbCI6IDEwMDAwMDAwLAorICAgICJyYXRlX2ludGVydmFsX3VzZWNzIjogMTAwMDAwMAorfQor
CitFTkQKK29uZSAwIHJhdGU9ODBNYi9zQDFzCitvbmUgMCByYXRlPTEwTUIvc0AxcworCisjIHRl
c3QgcmVwbGVuaXNobWVudCBpbnRlcnZhbCBvdmVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAor
b25lICRlIHJhdGU9MUIvc0A0Mjk0OTY3Mjk2dXMKK29uZSAkZSByYXRlPTFCL3NANDI5NDk2OG1z
CitvbmUgJGUgcmF0ZT0xQi9zQDQyOTVzCisKKyMgdGVzdCByZXBsZW5pc2htZW50IGludGVydmFs
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MUIvc0AwdXMKKwor
IyB0ZXN0IHJhdGUgbGltaXRpbmcgcmVzdWx0aW5nIGluIG92ZXJmbG93CitleHBlY3RlZCA8L2Rl
di9udWxsCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk1R0Ivc0A1dXMKK29uZSAkZSByYXRlPTQyOTZN
Qi9zQDQyOTRzCisKK2NvbXBsZXRlCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEz4-0000Ti-5F; Tue, 17 Apr 2012 20:26:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEz2-0000TJ-EJ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:40 +0000
Received: from [85.158.143.35:45142] by server-1.bemta-4.messagelabs.com id
	C8/4D-20925-FF1DD8F4; Tue, 17 Apr 2012 20:26:39 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334694395!12882682!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22368 invoked from network); 17 Apr 2012 20:26:36 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-10.tower-21.messagelabs.com with SMTP;
	17 Apr 2012 20:26:36 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 9CE0023A69; Tue, 17 Apr 2012 16:34:52 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: *
X-Spam-Status: No, score=1.4 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_22,
	J_CHICKENPOX_43,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no 
	version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id CD900245B9;
	Tue, 17 Apr 2012 16:34:46 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 28DB2281A9; Mon, 16 Apr 2012 23:52:53 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: cf61db286077f7b098665d3315bc3fb4e89a4816
Message-Id: <cf61db286077f7b09866.1334634686@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:26 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 v3] xl: add "check-xl-vif-parse" test
	script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyB0ZXN0IHNjcmlwdCBydW5zICJ4bCAtTiBuZXR3b3JrLWF0dGFjaCAwIDxmb29iYXI+IiBh
Z2FpbnN0IHZhcmlvdXMKcmF0ZSBzeW50YXggYW5kIGNoZWNrcyB0aGF0IHRoZSBvdXRwdXQgaXMg
YXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIu
Y29tPgpBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UgYi90b29scy9saWJ4bC9j
aGVjay14bC12aWYtcGFyc2UKbmV3IGZpbGUgbW9kZSAxMDA3NTUKLS0tIC9kZXYvbnVsbAorKysg
Yi90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UKQEAgLTAsMCArMSwyMDkgQEAKKyMhL2Jp
bi9iYXNoCisKK3NldCAtZQorCitpZiBbIC14IC4veGwgXSA7IHRoZW4KKyAgICBleHBvcnQgTERf
TElCUkFSWV9QQVRIPS4KKyAgICBYTD0uL3hsCitlbHNlCisgICAgWEw9eGwKK2ZpCisKK2ZwcmVm
aXg9dG1wLmNoZWNrLXhsLXZpZi1wYXJzZQorCitleHBlY3RlZCAoKSB7CisgICAgY2F0ID4kZnBy
ZWZpeC5leHBlY3RlZAorfQorCitmYWlsdXJlcz0wCisKK29uZSAoKSB7CisgICAgZXhwZWN0ZWRf
cmM9JDE7IHNoaWZ0CisgICAgcHJpbnRmICJ0ZXN0IGNhc2UgJXMuLi5cbiIgIiQqIgorICAgIHNl
dCArZQorICAgICR7WEx9IC1OIG5ldHdvcmstYXR0YWNoIDAgIiRAIiA8L2Rldi9udWxsID4kZnBy
ZWZpeC5hY3R1YWwgMj4vZGV2L251bGwKKyAgICBhY3R1YWxfcmM9JD8KKyAgICBkaWZmIC11ICRm
cHJlZml4LmV4cGVjdGVkICRmcHJlZml4LmFjdHVhbAorICAgIGRpZmZfcmM9JD8KKyAgICBzZXQg
LWUKKyAgICBpZiBbICRhY3R1YWxfcmMgIT0gJGV4cGVjdGVkX3JjIF0gfHwgWyAkZGlmZl9yYyAh
PSAwIF07IHRoZW4KKyAgICAgICAgZWNobyA+JjIgInRlc3QgY2FzZSBcYCQqJyBmYWlsZWQgKCRh
Y3R1YWxfcmMgJGRpZmZfcmMpIgorICAgICAgICBmYWlsdXJlcz0kKCggJGZhaWx1cmVzICsgMSAp
KQorICAgIGZpCit9CisKK2NvbXBsZXRlICgpIHsKKyAgICBpZiBbICIkZmFpbHVyZXMiID0gMCBd
OyB0aGVuCisgICAgICAgIGVjaG8gYWxsIG9rLjsgZXhpdCAwCisgICAgZWxzZQorICAgICAgICBl
Y2hvICIkZmFpbHVyZXMgdGVzdHMgZmFpbGVkLiI7IGV4aXQgMQorICAgIGZpCit9CisKK2U9MjU1
CisKKworIy0tLS0tLS0tLS0gdGVzdCBkYXRhIC0tLS0tLS0tLS0KKworIyB0ZXN0IGludmFsaWQg
dmlmIGNvbmZpZworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lIDEgZm9vCisKKyMgdGVzdCBpbnZh
bGlkIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDwvZGV2L251bGwKK29uZSAkZSByYXRlPWZvbworb25l
ICRlIHJhdGU9Zm9vCitvbmUgJGUgcmF0ZT0xME1CCitvbmUgJGUgcmF0ZT0xME1CL20KK29uZSAk
ZSByYXRlPTEwWkIKK29uZSAkZSByYXRlPTEwWkIvcworb25lICRlIHJhdGU9MTBaQi9tCisKKyMg
dGVzdCBiL3MgYW5kIEIvcyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAg
ImJhY2tlbmRfZG9taWQiOiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAg
Im1vZGVsIjogbnVsbCwKKyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAi
OiBudWxsLAorICAgICJicmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJz
Y3JpcHQiOiBudWxsLAorICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJf
aW50ZXJ2YWwiOiAxMDAwMDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQor
CitFTkQKKworb25lIDAgcmF0ZT0xNjAwMDAwMGIvcworb25lIDAgcmF0ZT0xNjAwMDAwMGIvc0A1
MG1zCitvbmUgMCByYXRlPTIwMDAwMDBCL3MKK29uZSAwIHJhdGU9MjAwMDAwMEIvc0A1MG1zCisK
KyMgdGVzdCBLYi9zIGFuZCBLQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsK
KyAgICAiYmFja2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwK
KyAgICAibW9kZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAg
ICJpcCI6IG51bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisg
ICAgInNjcmlwdCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVz
X3Blcl9pbnRlcnZhbCI6IDEwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9
CisKK0VORAorb25lIDAgcmF0ZT0xNktiL3MKK29uZSAwIHJhdGU9MTZLYi9zQDUwbXMKK29uZSAw
IHJhdGU9MktCL3MKK29uZSAwIHJhdGU9MktCL3NANTBtcworCisjIHRlc3QgTWIvcyBhbmQgTUIv
cyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAgImJhY2tlbmRfZG9taWQi
OiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAgIm1vZGVsIjogbnVsbCwK
KyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAiOiBudWxsLAorICAgICJi
cmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJzY3JpcHQiOiBudWxsLAor
ICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiOiAxMDAw
MDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJh
dGU9MTZNYi9zCitvbmUgMCByYXRlPTE2TWIvc0A1MG1zCitvbmUgMCByYXRlPTJNQi9zCitvbmUg
MCByYXRlPTJNQi9zQDUwbXMKKworIyB0ZXN0IEdiL3MgYW5kIEdCL3MgcmF0ZSB1bml0cworZXhw
ZWN0ZWQgPDxFTkQKK3ZpZjogeworICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQi
OiAwLAorICAgICJtdHUiOiAwLAorICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDow
MDowMDowMDowMDowMCIsCisgICAgImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAg
ICAiaWZuYW1lIjogbnVsbCwKKyAgICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51
bGwsCisgICAgInJhdGVfYnl0ZXNfcGVyX2ludGVydmFsIjogNTAwMDAwMDAsCisgICAgInJhdGVf
aW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJhdGU9OEdiL3MKK29uZSAw
IHJhdGU9OEdiL3NANTBtcworb25lIDAgcmF0ZT0xR0Ivcworb25lIDAgcmF0ZT0xR0Ivc0A1MG1z
CisKKyMgdGVzdCByYXRlIG92ZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0
ZT00Mjk0OTY3Mjk2Yi9zCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk2S2Ivcworb25lICRlIHJhdGU9
NDI5NDk2NzI5Nk1iL3MKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTZHYi9zCisKKyMgdGVzdCByYXRl
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MEIvcworCisjIHRl
c3QgaW52YWxpZCByZXBsZW5pc2htZW50IGludGVydmFsCitleHBlY3RlZCA8L2Rldi9udWxsCitv
bmUgJGUgcmF0ZT0xME1iL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1iL3NAMTBoCitvbmUgJGUgcmF0
ZT0xME1CL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1CL3NAMTBoCisKKyMgdGVzdCByZXBsZW5pc2ht
ZW50IGludGVydmFsIGluIHNlY29uZHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsKKyAgICAiYmFj
a2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwKKyAgICAibW9k
ZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAgICJpcCI6IG51
bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisgICAgInNjcmlw
dCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVzX3Blcl9pbnRl
cnZhbCI6IDEwMDAwMDAwLAorICAgICJyYXRlX2ludGVydmFsX3VzZWNzIjogMTAwMDAwMAorfQor
CitFTkQKK29uZSAwIHJhdGU9ODBNYi9zQDFzCitvbmUgMCByYXRlPTEwTUIvc0AxcworCisjIHRl
c3QgcmVwbGVuaXNobWVudCBpbnRlcnZhbCBvdmVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAor
b25lICRlIHJhdGU9MUIvc0A0Mjk0OTY3Mjk2dXMKK29uZSAkZSByYXRlPTFCL3NANDI5NDk2OG1z
CitvbmUgJGUgcmF0ZT0xQi9zQDQyOTVzCisKKyMgdGVzdCByZXBsZW5pc2htZW50IGludGVydmFs
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MUIvc0AwdXMKKwor
IyB0ZXN0IHJhdGUgbGltaXRpbmcgcmVzdWx0aW5nIGluIG92ZXJmbG93CitleHBlY3RlZCA8L2Rl
di9udWxsCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk1R0Ivc0A1dXMKK29uZSAkZSByYXRlPTQyOTZN
Qi9zQDQyOTRzCisKK2NvbXBsZXRlCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyz-0000Sw-NW; Tue, 17 Apr 2012 20:26:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyz-0000Sc-0t
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:37 +0000
Received: from [85.158.143.99:53038] by server-2.bemta-4.messagelabs.com id
	FB/52-17550-CF1DD8F4; Tue, 17 Apr 2012 20:26:36 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334694394!20697255!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30468 invoked from network); 17 Apr 2012 20:26:35 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 20:26:35 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 8FAC223C2E; Tue, 17 Apr 2012 16:34:52 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A30EF23ADA;
	Tue, 17 Apr 2012 16:34:45 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 5944E281A7; Mon, 16 Apr 2012 23:52:52 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: b17fc6cfbd884d2f9ddf643b954bcb3ce6236364
Message-Id: <b17fc6cfbd884d2f9ddf.1334634684@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:24 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 v3] xl: xl network-attach -N (dry run)
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIGRyeXJ1biBmb3IgdGVzdGluZyBhbmQgZGVidWdnaW5nIHB1cnBvc2VzLgoKU2lnbmVkLW9m
Zi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC00
OTE2LDYgKzQ5MTYsMTYgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIH0KICAgICB9CisKKyAgICBpZiAoZHJ5
cnVuX29ubHkpIHsKKyAgICAgICAgY2hhciAqanNvbiA9IGxpYnhsX2RldmljZV9uaWNfdG9fanNv
bihjdHgsICZuaWMpOworICAgICAgICBwcmludGYoInZpZjogJXNcbiIsIGpzb24pOworICAgICAg
ICBmcmVlKGpzb24pOworICAgICAgICBsaWJ4bF9kZXZpY2VfbmljX2Rpc3Bvc2UoJm5pYyk7Cisg
ICAgICAgIGlmIChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3IoInN0
ZG91dCIpOyBleGl0KC0xKTsgfQorICAgICAgICByZXR1cm4gMDsKKyAgICB9CisKICAgICBpZiAo
bGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYykpIHsKICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJsaWJ4bF9kZXZpY2VfbmljX2FkZCBmYWlsZWQuXG4iKTsKICAgICAgICAgcmV0
dXJuIDE7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jIGIvdG9vbHMvbGli
eGwveGxfY21kdGFibGUuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jCisrKyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMKQEAgLTI4OCw3ICsyODgsNyBAQCBzdHJ1Y3QgY21kX3Nw
ZWMgY21kX3RhYmxlW10gPSB7CiAgICAgICAiIiwKICAgICB9LAogICAgIHsgIm5ldHdvcmstYXR0
YWNoIiwKLSAgICAgICZtYWluX25ldHdvcmthdHRhY2gsIDAsCisgICAgICAmbWFpbl9uZXR3b3Jr
YXR0YWNoLCAxLAogICAgICAgIkNyZWF0ZSBhIG5ldyB2aXJ0dWFsIG5ldHdvcmsgZGV2aWNlIiwK
ICAgICAgICI8RG9tYWluPiBbdHlwZT08dHlwZT5dIFttYWM9PG1hYz5dIFticmlkZ2U9PGJyaWRn
ZT5dICIKICAgICAgICJbaXA9PGlwPl0gW3NjcmlwdD08c2NyaXB0Pl0gW2JhY2tlbmQ9PEJhY2tE
b21haW4+XSBbdmlmbmFtZT08bmFtZT5dICIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyz-0000Sw-NW; Tue, 17 Apr 2012 20:26:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyz-0000Sc-0t
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:37 +0000
Received: from [85.158.143.99:53038] by server-2.bemta-4.messagelabs.com id
	FB/52-17550-CF1DD8F4; Tue, 17 Apr 2012 20:26:36 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334694394!20697255!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30468 invoked from network); 17 Apr 2012 20:26:35 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-216.messagelabs.com with SMTP;
	17 Apr 2012 20:26:35 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 8FAC223C2E; Tue, 17 Apr 2012 16:34:52 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A30EF23ADA;
	Tue, 17 Apr 2012 16:34:45 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 5944E281A7; Mon, 16 Apr 2012 23:52:52 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: b17fc6cfbd884d2f9ddf643b954bcb3ce6236364
Message-Id: <b17fc6cfbd884d2f9ddf.1334634684@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:24 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 v3] xl: xl network-attach -N (dry run)
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIGRyeXJ1biBmb3IgdGVzdGluZyBhbmQgZGVidWdnaW5nIHB1cnBvc2VzLgoKU2lnbmVkLW9m
Zi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC00
OTE2LDYgKzQ5MTYsMTYgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIH0KICAgICB9CisKKyAgICBpZiAoZHJ5
cnVuX29ubHkpIHsKKyAgICAgICAgY2hhciAqanNvbiA9IGxpYnhsX2RldmljZV9uaWNfdG9fanNv
bihjdHgsICZuaWMpOworICAgICAgICBwcmludGYoInZpZjogJXNcbiIsIGpzb24pOworICAgICAg
ICBmcmVlKGpzb24pOworICAgICAgICBsaWJ4bF9kZXZpY2VfbmljX2Rpc3Bvc2UoJm5pYyk7Cisg
ICAgICAgIGlmIChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3IoInN0
ZG91dCIpOyBleGl0KC0xKTsgfQorICAgICAgICByZXR1cm4gMDsKKyAgICB9CisKICAgICBpZiAo
bGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYykpIHsKICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJsaWJ4bF9kZXZpY2VfbmljX2FkZCBmYWlsZWQuXG4iKTsKICAgICAgICAgcmV0
dXJuIDE7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jIGIvdG9vbHMvbGli
eGwveGxfY21kdGFibGUuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jCisrKyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMKQEAgLTI4OCw3ICsyODgsNyBAQCBzdHJ1Y3QgY21kX3Nw
ZWMgY21kX3RhYmxlW10gPSB7CiAgICAgICAiIiwKICAgICB9LAogICAgIHsgIm5ldHdvcmstYXR0
YWNoIiwKLSAgICAgICZtYWluX25ldHdvcmthdHRhY2gsIDAsCisgICAgICAmbWFpbl9uZXR3b3Jr
YXR0YWNoLCAxLAogICAgICAgIkNyZWF0ZSBhIG5ldyB2aXJ0dWFsIG5ldHdvcmsgZGV2aWNlIiwK
ICAgICAgICI8RG9tYWluPiBbdHlwZT08dHlwZT5dIFttYWM9PG1hYz5dIFticmlkZ2U9PGJyaWRn
ZT5dICIKICAgICAgICJbaXA9PGlwPl0gW3NjcmlwdD08c2NyaXB0Pl0gW2JhY2tlbmQ9PEJhY2tE
b21haW4+XSBbdmlmbmFtZT08bmFtZT5dICIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyv-0000S1-AY; Tue, 17 Apr 2012 20:26:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyt-0000Rv-O1
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:31 +0000
Received: from [85.158.138.51:44277] by server-6.bemta-3.messagelabs.com id
	17/F9-05145-6F1DD8F4; Tue, 17 Apr 2012 20:26:30 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334694389!22394795!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 460 invoked from network); 17 Apr 2012 20:26:30 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-14.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 20:26:30 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 1FCD4245BD; Tue, 17 Apr 2012 16:34:47 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.9 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,TW_CF autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id C1AC023A69;
	Tue, 17 Apr 2012 16:34:45 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 840F8281A5; Mon, 16 Apr 2012 23:52:51 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:22 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 v3] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch series implements the required plumbering for vif rate limiting in libxl/xl.

The first patch (already applied) fixes trivial indentation issues and introduces no functional changes.

The second patch (already applied) implements dry-run for `xl network-attach` for debugging and testing purposes.

The third patch adds the required plumbering in libxl/xl to add vif rate limiting support. It uses the `rate` option syntax from xm/xend, ensuring full backward compatiblity.

The final patch adds the "check-xl-vif-parse" test script which tests various `rate` syntax.

Changes in v3:
- Move xlu_cfg_init from parse_vif_rate to main_networkattach
- Add xlu_cfg_destroy to main_networkattach
- Use %"PRIuXX" instead of %llu and %lu

Changes in v2:
- Don't default to unlimited in case of overflow/underflow or invalid syntax in rate
- Add error handling
- Remove use of matches in regex which weren't used anyway
- Add docs about the syntax
- Add note in docs explaining that limitations are netback implementation specific
- Modify test cases according to new behavior

--
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyv-0000S1-AY; Tue, 17 Apr 2012 20:26:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyt-0000Rv-O1
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:31 +0000
Received: from [85.158.138.51:44277] by server-6.bemta-3.messagelabs.com id
	17/F9-05145-6F1DD8F4; Tue, 17 Apr 2012 20:26:30 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334694389!22394795!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 460 invoked from network); 17 Apr 2012 20:26:30 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-14.tower-174.messagelabs.com with SMTP;
	17 Apr 2012 20:26:30 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 1FCD4245BD; Tue, 17 Apr 2012 16:34:47 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.9 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,TW_CF autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id C1AC023A69;
	Tue, 17 Apr 2012 16:34:45 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 840F8281A5; Mon, 16 Apr 2012 23:52:51 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:22 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 v3] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch series implements the required plumbering for vif rate limiting in libxl/xl.

The first patch (already applied) fixes trivial indentation issues and introduces no functional changes.

The second patch (already applied) implements dry-run for `xl network-attach` for debugging and testing purposes.

The third patch adds the required plumbering in libxl/xl to add vif rate limiting support. It uses the `rate` option syntax from xm/xend, ensuring full backward compatiblity.

The final patch adds the "check-xl-vif-parse" test script which tests various `rate` syntax.

Changes in v3:
- Move xlu_cfg_init from parse_vif_rate to main_networkattach
- Add xlu_cfg_destroy to main_networkattach
- Use %"PRIuXX" instead of %llu and %lu

Changes in v2:
- Don't default to unlimited in case of overflow/underflow or invalid syntax in rate
- Add error handling
- Remove use of matches in regex which weren't used anyway
- Add docs about the syntax
- Add note in docs explaining that limitations are netback implementation specific
- Modify test cases according to new behavior

--
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyw-0000SD-NS; Tue, 17 Apr 2012 20:26:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyv-0000S0-AE
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:33 +0000
Received: from [85.158.139.83:44601] by server-11.bemta-5.messagelabs.com id
	D3/3D-12959-8F1DD8F4; Tue, 17 Apr 2012 20:26:32 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334694391!24174265!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15803 invoked from network); 17 Apr 2012 20:26:31 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-15.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 20:26:31 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 69791245BC; Tue, 17 Apr 2012 16:34:48 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A185623A72;
	Tue, 17 Apr 2012 16:34:45 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id E7096281A6; Mon, 16 Apr 2012 23:52:51 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 656262a43421881ee9b2cf9288023089b30060dc
Message-Id: <656262a43421881ee9b2.1334634683@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:23 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 v3] xl: cleanup indentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdp
dCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwot
LS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jCkBAIC04NDcsMTAgKzg0NywxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShj
b25zdCBjaGFyCiAgICAgICAgICAgICAgICAgbmljLT5zY3JpcHQgPSBzdHJkdXAoZGVmYXVsdF92
aWZzY3JpcHQpOwogICAgICAgICAgICAgfQogCi0JICAgIGlmIChkZWZhdWx0X2JyaWRnZSkgewot
CQlmcmVlKG5pYy0+YnJpZGdlKTsKLQkJbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwotCSAgICB9CisgICAgICAgICAgICBpZiAoZGVmYXVsdF9icmlkZ2UpIHsKKyAgICAgICAg
ICAgICAgICBmcmVlKG5pYy0+YnJpZGdlKTsKKyAgICAgICAgICAgICAgICBuaWMtPmJyaWRnZSA9
IHN0cmR1cChkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIHAg
PSBzdHJ0b2soYnVmMiwgIiwiKTsKICAgICAgICAgICAgIGlmICghcCkKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyz-0000Sl-Ai; Tue, 17 Apr 2012 20:26:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyw-0000SC-AY
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:34 +0000
Received: from [85.158.139.83:44661] by server-2.bemta-5.messagelabs.com id
	C2/BD-17016-9F1DD8F4; Tue, 17 Apr 2012 20:26:33 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334694391!23578026!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17324 invoked from network); 17 Apr 2012 20:26:31 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-9.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 20:26:31 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id E8D8E23A72; Tue, 17 Apr 2012 16:34:48 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: **
X-Spam-Status: No, score=2.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_64,
	J_CHICKENPOX_81,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME,TW_BX,TW_CF,
	TW_IB autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A7AD023C2E;
	Tue, 17 Apr 2012 16:34:46 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id BC1EF281A8; Mon, 16 Apr 2012 23:52:52 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 4130bb154f3436a9adf45a05462bee2baea41f36
Message-Id: <4130bb154f3436a9adf4.1334634685@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:25 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 v3] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIGByYXRlYCBrZXl3b3JkIHNwZWNpZmllcyB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgb3V0Z29p
bmcgdHJhZmZpYwp3aWxsIGJlIGxpbWl0ZWQgdG8uIFRoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29y
ZCBpcyBub3Qgc3BlY2lmaWVkCmlzIHVubGltaXRlZC4KClRoZSBgcmF0ZWAga2V5d29yZCBzdXBw
b3J0cyBhbiBvcHRpb25hbCByZXBsZW5pc2htZW50IGludGVydmFsCnBhcmFtZXRlciBmb3Igc3Bl
Y2lmeWluZyB0aGUgZ3JhbnVsYXJpdHkgb2YgY3JlZGl0IHJlcGxlbmlzaG1lbnQuCkl0IGRldGVy
bWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQK
aXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMuCgpGb3IgZXhhbXBs
ZToKCiAgICAgICAgJ3JhdGU9MTBNYi9zJwogICAgICAgICdyYXRlPTI1MEtCL3MnCiAgICAgICAg
J3JhdGU9MU1CL3NAMjBtcycKClNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2FnbmVA
aXdlYi5jb20+CkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rv
d24gYi9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCi0tLSBhL2Rv
Y3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24KKysrIGIvZG9jcy9taXNj
L3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgpAQCAtMTIyLDUgKzEyMiwzNCBAQCBT
cGVjaWZpZXMgdGhlIGJhY2tlbmQgZG9tYWluIHdoaWNoIHRoaXMgCiBkZWZhdWx0cyB0byBkb21h
aW4gMC4gU3BlY2lmeWluZyBhbm90aGVyIGRvbWFpbiByZXF1aXJlcyBzZXR0aW5nIHVwIGEKIGRy
aXZlciBkb21haW4gd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4K
IAorIyMjIHJhdGUKKworU3BlY2lmaWVzIHRoZSByYXRlIGF0IHdoaWNoIHRoZSBvdXRnb2luZyB0
cmFmZmljIHdpbGwgYmUgbGltaXRlZCB0by4KK1RoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29yZCBp
cyBub3Qgc3BlY2lmaWVkIGlzIHVubGltaXRlZC4KKworVGhlIHJhdGUgbWF5IGJlIHNwZWNpZmll
ZCBhcyAiPFJBVEU+L3MiIG9yIG9wdGlvbmFsbHkgIjxSQVRFPi9zQDxJTlRFUlZBTD4iLgorCisg
ICogYFJBVEVgIGlzIGluIGJ5dGVzIGFuZCBjYW4gYWNjZXB0IHN1ZmZpeGVzOgorICAgICAgKiBH
QiwgTUIsIEtCLCBCIGZvciBieXRlcy4KKyAgICAgICogR2IsIE1iLCBLYiwgYiBmb3IgYml0cy4K
KyAgKiBgSU5URVJWQUxgIGlzIGluIG1pY3Jvc2Vjb25kcyBhbmQgY2FuIGFjY2VwdCBzdWZmaXhl
czogbXMsIHVzLCBzLgorICAgIEl0IGRldGVybWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0
aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQKKyAgICBpcyByZXBsZW5pc2hlZC4gVGhlIGRlZmF1
bHQgaXMgNTBtcy4KKworVmlmIHJhdGUgbGltaXRpbmcgaXMgY3JlZGl0LWJhc2VkLiBJdCBtZWFu
cyB0aGF0IGZvciAiMU1CL3NAMjBtcyIsIHRoZQorYXZhaWxhYmxlIGNyZWRpdCB3aWxsIGJlIGVx
dWl2YWxlbnQgb2YgdGhlIHRyYWZmaWMgeW91IHdvdWxkIGhhdmUgZG9uZQorYXQgIjFNQi9zIiBk
dXJpbmcgMjBtcy4gVGhpcyB3aWxsIHJlc3VsdHMgaW4gYSBjcmVkaXQgb2YgMjAsMDAwIGJ5dGVz
CityZXBsZW5pc2hlZCBldmVyeSAyMCwwMDAgdXMuCisKK0ZvciBleGFtcGxlOgorCisgICAgICAg
ICdyYXRlPTEwTWIvcycgLS0gbWVhbmluZyB1cCB0byAxMCBtZWdhYml0cyBldmVyeSBzZWNvbmQK
KyAgICAgICAgJ3JhdGU9MjUwS0IvcycgLS0gbWVhbmluZyB1cCB0byAyNTAga2lsb2J5dGVzIGV2
ZXJ5IHNlY29uZAorICAgICAgICAncmF0ZT0xTUIvc0AyMG1zJyAtLSBtZWFuaW5nIDIwLDAwMCBi
eXRlcyBpbiBldmVyeSAyMCBtaWxsaXNlY29uZCBwZXJpb2QKKworTk9URTogVGhlIGFjdHVhbCB1
bmRlcmx5aW5nIGxpbWl0cyBvZiByYXRlIGxpbWl0aW5nIGFyZSBkZXBlbmRlbnQKK29uIHRoZSB1
bmRlcmx5aW5nIG5ldGJhY2sgaW1wbGVtZW50YXRpb24uCisKKwogW291aV06IGh0dHA6Ly9lbi53
aWtpcGVkaWEub3JnL3dpa2kvT3JnYW5pemF0aW9uYWxseV9VbmlxdWVfSWRlbnRpZmllcgogW25l
dF06IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Ib3N0Q29uZmlndXJhdGlvbi9OZXR3b3JraW5n
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9NYWtlZmlsZSBiL3Rvb2xzL2xpYnhsL01ha2VmaWxl
Ci0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCkBA
IC02MSw3ICs2MSw3IEBAIExJQlhMX09CSlMgKz0gX2xpYnhsX3R5cGVzLm8gbGlieGxfZmxhc2sK
IEFVVE9JTkNTPSBsaWJ4bHVfY2ZnX3kuaCBsaWJ4bHVfY2ZnX2wuaCBfbGlieGxfbGlzdC5oCiBB
VVRPU1JDUz0gbGlieGx1X2NmZ195LmMgbGlieGx1X2NmZ19sLmMKIExJQlhMVV9PQkpTID0gbGli
eGx1X2NmZ195Lm8gbGlieGx1X2NmZ19sLm8gbGlieGx1X2NmZy5vIFwKLQlsaWJ4bHVfZGlza19s
Lm8gbGlieGx1X2Rpc2subyBsaWJ4bHVfcGNpLm8KKwlsaWJ4bHVfZGlza19sLm8gbGlieGx1X2Rp
c2subyBsaWJ4bHVfdmlmLm8gbGlieGx1X3BjaS5vCiAkKExJQlhMVV9PQkpTKTogQ0ZMQUdTICs9
ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICMgRm9yIHhlbnRvb2xsb2cuaAogCiBDTElFTlRTID0geGwg
dGVzdGlkbApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xp
YnhsLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGwuYworKysgYi90b29scy9saWJ4bC9saWJ4bC5j
CkBAIC0xODU0LDYgKzE4NTQsMTMgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRkKGxpYnhsX2N0
eCAqY3R4LAogICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2Ms
IG5pYy0+aXApKTsKICAgICB9CiAKKyAgICBpZiAobmljLT5yYXRlX2ludGVydmFsX3VzZWNzID4g
MCkgeworICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJyYXRlIik7CisgICAgICAgIGZs
ZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3NwcmludGYoZ2MsICIlIlBSSXU2NCIsJSJQUkl1
MzIiIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2lu
dGVydmFsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pYy0+cmF0ZV9pbnRlcnZhbF91
c2VjcykpOworICAgIH0KKwogICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgImJyaWRnZSIpOwog
ICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5icmlkZ2Up
KTsKICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJoYW5kbGUiKTsKZGlmZiAtLWdpdCBhL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCkBAIC0zNDMsNiArMzQzLDggQEAgbGlieGxfZGV2aWNlX25pYyA9IFN0cnVjdCgi
ZGV2aWNlX25pYyIsIAogICAgICgiaWZuYW1lIiwgc3RyaW5nKSwKICAgICAoInNjcmlwdCIsIHN0
cmluZyksCiAgICAgKCJuaWN0eXBlIiwgbGlieGxfbmljX3R5cGUpLAorICAgICgicmF0ZV9ieXRl
c19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAorICAgICgicmF0ZV9pbnRlcnZhbF91c2VjcyIsIHVp
bnQzMiksCiAgICAgXSkKIAogbGlieGxfZGV2aWNlX3BjaSA9IFN0cnVjdCgiZGV2aWNlX3BjaSIs
IFsKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oIGIvdG9vbHMvbGli
eGwvbGlieGx1X2ludGVybmFsLmgKLS0tIGEvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgK
KysrIGIvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgKQEAgLTE3LDkgKzE3LDExIEBACiAj
ZGVmaW5lIExJQlhMVV9JTlRFUk5BTF9ICiAKICNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUg
PHN0ZGxpYi5oPgogI2luY2x1ZGUgPGVycm5vLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5j
bHVkZSA8YXNzZXJ0Lmg+CisjaW5jbHVkZSA8cmVnZXguaD4KIAogI2RlZmluZSBYTFVfQ29uZmln
TGlzdCBYTFVfQ29uZmlnU2V0dGluZwogCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bHVf
dmlmLmMgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0t
IC9kZXYvbnVsbAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKQEAgLTAsMCArMSwxNDEg
QEAKKyNpbmNsdWRlICJsaWJ4bF9vc2RlcHMuaCIgLyogbXVzdCBjb21lIGJlZm9yZSBhbnkgb3Ro
ZXIgaGVhZGVycyAqLworI2luY2x1ZGUgImxpYnhsdV9pbnRlcm5hbC5oIgorCitzdGF0aWMgY29u
c3QgY2hhciAqdmlmX2J5dGVzX3Blcl9zZWNfcmUgPSAiXlswLTldK1tHTUtdP1tCYl0vcyQiOwor
c3RhdGljIGNvbnN0IGNoYXIgKnZpZl9pbnRlcm5hbF91c2VjX3JlID0gIl5bMC05XStbbXVdP3M/
JCI7CisKK3N0YXRpYyB2b2lkIHhsdV9fdmlmX2VycihYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKm1zZywgY29uc3QgY2hhciAqcmF0ZSkgeworICAgIGZwcmludGYoY2ZnLT5yZXBvcnQsCisg
ICAgICAgICAgICAiJXM6IGNvbmZpZyBwYXJzaW5nIGVycm9yIGluIHZpZjogJXMgaW4gYCVzJ1xu
IiwKKyAgICAgICAgICAgIGNmZy0+ZmlsZW5hbWUsIG1zZywgcmF0ZSk7Cit9CisKK3N0YXRpYyBp
bnQgdmlmX3BhcnNlX3JhdGVfYnl0ZXNfcGVyX3NlYyhYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKmJ5dGVzLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2
NF90ICpieXRlc19wZXJfc2VjKQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRt
cCA9IDA7CisgICAgY29uc3QgY2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29t
cCgmcmVjLCB2aWZfYnl0ZXNfcGVyX3NlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7Cisg
ICAgaWYgKHJlZ2V4ZWMoJnJlYywgYnl0ZXMsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9f
dmlmX2VycihjZmcsICJpbnZhbGlkIHJhdGUiLCBieXRlcyk7CisgICAgICAgIHJjID0gRUlOVkFM
OworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gYnl0ZXM7CisgICAgdG1wID0g
c3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8IHRtcCA+IFVJ
TlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcs
ICJyYXRlIG92ZXJmbG93IiwgYnl0ZXMpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgaWYgKCpwID09ICdHJykKKyAgICAgICB0bXAgKj0g
MTAwMCAqIDEwMDAgKiAxMDAwOworICAgIGVsc2UgaWYgKCpwID09ICdNJykKKyAgICAgICB0bXAg
Kj0gMTAwMCAqIDEwMDA7CisgICAgZWxzZSBpZiAoKnAgPT0gJ0snKQorICAgICAgIHRtcCAqPSAx
MDAwOworICAgIGlmICgqcCA9PSAnYicgfHwgKihwKzEpID09ICdiJykKKyAgICAgICB0bXAgLz0g
ODsKKworICAgICpieXRlc19wZXJfc2VjID0gdG1wOworCitvdXQ6CisgICAgcmVnZnJlZSgmcmVj
KTsKKyAgICByZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBpbnQgdmlmX3BhcnNlX3JhdGVfaW50ZXJ2
YWxfdXNlY3MoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICppbnRlcnZhbCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgKmludGVydmFsX3VzZWNz
KQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRtcCA9IDA7CisgICAgY29uc3Qg
Y2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29tcCgmcmVjLCB2aWZfaW50ZXJu
YWxfdXNlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7CisgICAgaWYgKHJlZ2V4ZWMoJnJl
YywgaW50ZXJ2YWwsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJp
bnZhbGlkIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwiLCBpbnRlcnZhbCk7CisgICAgICAgIHJjID0g
RUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gaW50ZXJ2YWw7Cisg
ICAgdG1wID0gc3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8
IHRtcCA+IFVJTlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlm
X2VycihjZmcsICJyZXBsZW5pc2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOwor
ICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAg
aWYgKCpwID09ICdzJyB8fCAqcCA9PSAnXDAnKQorICAgICAgICB0bXAgKj0gMTAwMCAqIDEwMDA7
CisgICAgZWxzZSBpZiAoKnAgPT0gJ20nKQorICAgICAgICB0bXAgKj0gMTAwMDsKKworICAgIGlm
ICh0bXAgPiBVSU5UMzJfTUFYKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJyZXBsZW5p
c2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOworICAgICAgICByYyA9IEVPVkVS
RkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAgKmludGVydmFsX3VzZWNzID0g
KHVpbnQzMl90KSB0bXA7CisKK291dDoKKyAgICByZWdmcmVlKCZyZWMpOworICAgIHJldHVybiBy
YzsKK30KKworaW50IHhsdV92aWZfcGFyc2VfcmF0ZShYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKnJhdGUsIGxpYnhsX2RldmljZV9uaWMgKm5pYykKK3sKKyAgICB1aW50NjRfdCBieXRlc19w
ZXJfc2VjID0gMDsKKyAgICB1aW50NjRfdCBieXRlc19wZXJfaW50ZXJ2YWwgPSAwOworICAgIHVp
bnQzMl90IGludGVydmFsX3VzZWNzID0gNTAwMDBVTDsgLyogRGVmYXVsdCB0byA1MG1zICovCisg
ICAgY2hhciAqcmF0ZXRvaywgKnRtcHJhdGU7CisgICAgaW50IHJjID0gMDsKKworICAgIHRtcHJh
dGUgPSBzdHJkdXAocmF0ZSk7CisgICAgaWYgKCFzdHJjbXAodG1wcmF0ZSwiIikpIHsKKyAgICAg
ICAgeGx1X192aWZfZXJyKGNmZywgIm5vIHJhdGUgc3BlY2lmaWVkIiwgcmF0ZSk7CisgICAgICAg
IHJjID0gRUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICByYXRldG9rID0g
c3RydG9rKHRtcHJhdGUsICJAIik7CisgICAgcmMgPSB2aWZfcGFyc2VfcmF0ZV9ieXRlc19wZXJf
c2VjKGNmZywgcmF0ZXRvaywgJmJ5dGVzX3Blcl9zZWMpOworICAgIGlmIChyYykgZ290byBvdXQ7
CisKKyAgICByYXRldG9rID0gc3RydG9rKE5VTEwsICJAIik7CisgICAgaWYgKHJhdGV0b2sgIT0g
TlVMTCkgeworICAgICAgICByYyA9IHZpZl9wYXJzZV9yYXRlX2ludGVydmFsX3VzZWNzKGNmZywg
cmF0ZXRvaywgJmludGVydmFsX3VzZWNzKTsKKyAgICAgICAgaWYgKHJjKSBnb3RvIG91dDsKKyAg
ICB9CisKKyAgICBpZiAoaW50ZXJ2YWxfdXNlY3MgIT0gMCAmJiAoYnl0ZXNfcGVyX3NlYyA+IChV
SU5UNjRfTUFYIC8gaW50ZXJ2YWxfdXNlY3MpKSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2Zn
LCAicmF0ZSBvdmVyZmxvdyIsIHJhdGUpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgYnl0ZXNfcGVyX2ludGVydmFsID0KKyAgICAgICAg
KCgodWludDY0X3QpIGJ5dGVzX3Blcl9zZWMgKiAodWludDY0X3QpIGludGVydmFsX3VzZWNzKSAv
IDEwMDAwMDBVTCk7CisKKyAgICBuaWMtPnJhdGVfaW50ZXJ2YWxfdXNlY3MgPSBpbnRlcnZhbF91
c2VjczsKKyAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsID0gYnl0ZXNfcGVyX2ludGVy
dmFsOworCitvdXQ6CisgICAgZnJlZSh0bXByYXRlKTsKKyAgICByZXR1cm4gcmM7Cit9CisKKy8q
CisgKiBMb2NhbCB2YXJpYWJsZXM6CisgKiBtb2RlOiBDCisgKiBjLWJhc2ljLW9mZnNldDogNAor
ICogaW5kZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8KZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL2xpYnhsdXRpbC5oIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGx1dGlsLmgKKysrIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKQEAgLTk0LDYg
Kzk0LDEzIEBAIGludCB4bHVfZGlza19wYXJzZShYTFVfQ29uZmlnICpjZmcsIGludCAKIGludCB4
bHVfcGNpX3BhcnNlX2JkZihYTFVfQ29uZmlnICpjZmcsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRl
diwgY29uc3QgY2hhciAqc3RyKTsKIAogCisvKgorICogVmlmIHJhdGUgcGFyc2luZy4KKyAqLwor
CitpbnQgeGx1X3ZpZl9wYXJzZV9yYXRlKFhMVV9Db25maWcgKmNmZywgY29uc3QgY2hhciAqcmF0
ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfZGV2aWNlX25pYyAqbmljKTsKKwogI2Vu
ZGlmIC8qIExJQlhMVVRJTF9IICovCiAKIC8qCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9j
bWRpbXBsLmMgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtNDAzLDYgKzQwMywx
OSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9kaXNrX2NvbmZpZyhYTFVfQ29uZmlnCiAgICAgcGFyc2Vf
ZGlza19jb25maWdfbXVsdGlzdHJpbmcoY29uZmlnLCAxLCAmc3BlYywgZGlzayk7CiB9CiAKK3N0
YXRpYyB2b2lkIHBhcnNlX3ZpZl9yYXRlKFhMVV9Db25maWcgKipjb25maWcsIGNvbnN0IGNoYXIg
KnJhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZpY2VfbmljICpuaWMp
Cit7CisgICAgaW50IGU7CisKKyAgICBlID0geGx1X3ZpZl9wYXJzZV9yYXRlKCpjb25maWcsIHJh
dGUsIG5pYyk7CisgICAgaWYgKGUgPT0gRUlOVkFMIHx8IGUgPT0gRU9WRVJGTE9XKSBleGl0KC0x
KTsKKyAgICBpZiAoZSkgeworICAgICAgICBmcHJpbnRmKHN0ZGVyciwieGx1X3ZpZl9wYXJzZV9y
YXRlIGZhaWxlZDogJXNcbiIsc3RyZXJyb3IoZXJybm8pKTsKKyAgICAgICAgZXhpdCgtMSk7Cisg
ICAgfQorfQorCiBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJpbmdfbGlzdChjb25z
dCBjaGFyICpzdHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
b25zdCBjaGFyICpkZWxpbSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX3N0cmluZ19saXN0ICpwc2wpCkBAIC05MDYsNyArOTE5LDcgQEAgc3RhdGljIHZv
aWQgcGFyc2VfY29uZmlnX2RhdGEoY29uc3QgY2hhcgogICAgICAgICAgICAgICAgICAgICAgICAg
bmljLT5iYWNrZW5kX2RvbWlkID0gMDsKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAg
ICAgICAgIH0gZWxzZSBpZiAoIXN0cmNtcChwLCAicmF0ZSIpKSB7Ci0gICAgICAgICAgICAgICAg
ICAgIGZwcmludGYoc3RkZXJyLCAidGhlIHJhdGUgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJl
bnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKKyAgICAgICAgICAgICAgICAgICAgcGFyc2VfdmlmX3Jh
dGUoJmNvbmZpZywgKHAyICsgMSksIG5pYyk7CiAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICgh
c3RyY21wKHAsICJhY2NlbCIpKSB7CiAgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJy
LCAidGhlIGFjY2VsIHBhcmFtZXRlciBmb3IgdmlmcyBpcyBjdXJyZW50bHkgbm90IHN1cHBvcnRl
ZFxuIik7CiAgICAgICAgICAgICAgICAgfQpAQCAtNDg1NSw2ICs0ODY4LDcgQEAgaW50IG1haW5f
bmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAqKgogewogICAgIGludCBvcHQ7CiAgICAgbGli
eGxfZGV2aWNlX25pYyBuaWM7CisgICAgWExVX0NvbmZpZyAqY29uZmlnID0gMDsKICAgICBjaGFy
ICplbmRwdHIsICpvcGFyZzsKICAgICBjb25zdCBjaGFyICp0b2s7CiAgICAgaW50IGk7CkBAIC00
ODcyLDYgKzQ4ODYsMTMgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIiVzIGlzIGFuIGludmFsaWQgZG9tYWluIGlkZW50
aWZpZXJcbiIsIGFyZ3Zbb3B0aW5kXSk7CiAgICAgICAgIHJldHVybiAxOwogICAgIH0KKworICAg
IGNvbmZpZz0geGx1X2NmZ19pbml0KHN0ZGVyciwgImNvbW1hbmQgbGluZSIpOworICAgIGlmICgh
Y29uZmlnKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRmFpbGVkIHRvIGFsbG9jYXRlIGZv
ciBjb25maWd1cmF0aW9uXG4iKTsKKyAgICAgICAgcmV0dXJuIDE7CisgICAgfQorCiAgICAgbGli
eGxfZGV2aWNlX25pY19pbml0KCZuaWMpOwogICAgIGZvciAoYXJndiArPSBvcHRpbmQrMSwgYXJn
YyAtPSBvcHRpbmQrMTsgYXJnYyA+IDA7ICsrYXJndiwgLS1hcmdjKSB7CiAgICAgICAgIGlmIChN
QVRDSF9PUFRJT04oInR5cGUiLCAqYXJndiwgb3BhcmcpKSB7CkBAIC00OTEwLDYgKzQ5MzEsNyBA
QCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCiAgICAgICAgIH0gZWxz
ZSBpZiAoTUFUQ0hfT1BUSU9OKCJtb2RlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgICAg
IHJlcGxhY2Vfc3RyaW5nKCZuaWMubW9kZWwsIG9wYXJnKTsKICAgICAgICAgfSBlbHNlIGlmIChN
QVRDSF9PUFRJT04oInJhdGUiLCAqYXJndiwgb3BhcmcpKSB7CisgICAgICAgICAgICBwYXJzZV92
aWZfcmF0ZSgmY29uZmlnLCBvcGFyZywgJm5pYyk7CiAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hf
T1BUSU9OKCJhY2NlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgfSBlbHNlIHsKICAgICAg
ICAgICAgIGZwcmludGYoc3RkZXJyLCAidW5yZWNvZ25pemVkIGFyZ3VtZW50IGAlcydcbiIsICph
cmd2KTsKQEAgLTQ5MzEsNiArNDk1Myw3IEBAIGludCBtYWluX25ldHdvcmthdHRhY2goaW50IGFy
Z2MsIGNoYXIgKioKICAgICAgICAgcmV0dXJuIDE7CiAgICAgfQogICAgIGxpYnhsX2RldmljZV9u
aWNfZGlzcG9zZSgmbmljKTsKKyAgICB4bHVfY2ZnX2Rlc3Ryb3koY29uZmlnKTsKICAgICByZXR1
cm4gMDsKIH0KIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyw-0000SD-NS; Tue, 17 Apr 2012 20:26:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyv-0000S0-AE
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:33 +0000
Received: from [85.158.139.83:44601] by server-11.bemta-5.messagelabs.com id
	D3/3D-12959-8F1DD8F4; Tue, 17 Apr 2012 20:26:32 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334694391!24174265!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15803 invoked from network); 17 Apr 2012 20:26:31 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-15.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 20:26:31 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 69791245BC; Tue, 17 Apr 2012 16:34:48 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A185623A72;
	Tue, 17 Apr 2012 16:34:45 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id E7096281A6; Mon, 16 Apr 2012 23:52:51 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 656262a43421881ee9b2cf9288023089b30060dc
Message-Id: <656262a43421881ee9b2.1334634683@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:23 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 v3] xl: cleanup indentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdp
dCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwot
LS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jCkBAIC04NDcsMTAgKzg0NywxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShj
b25zdCBjaGFyCiAgICAgICAgICAgICAgICAgbmljLT5zY3JpcHQgPSBzdHJkdXAoZGVmYXVsdF92
aWZzY3JpcHQpOwogICAgICAgICAgICAgfQogCi0JICAgIGlmIChkZWZhdWx0X2JyaWRnZSkgewot
CQlmcmVlKG5pYy0+YnJpZGdlKTsKLQkJbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwotCSAgICB9CisgICAgICAgICAgICBpZiAoZGVmYXVsdF9icmlkZ2UpIHsKKyAgICAgICAg
ICAgICAgICBmcmVlKG5pYy0+YnJpZGdlKTsKKyAgICAgICAgICAgICAgICBuaWMtPmJyaWRnZSA9
IHN0cmR1cChkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIHAg
PSBzdHJ0b2soYnVmMiwgIiwiKTsKICAgICAgICAgICAgIGlmICghcCkKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKEyz-0000Sl-Ai; Tue, 17 Apr 2012 20:26:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKEyw-0000SC-AY
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:26:34 +0000
Received: from [85.158.139.83:44661] by server-2.bemta-5.messagelabs.com id
	C2/BD-17016-9F1DD8F4; Tue, 17 Apr 2012 20:26:33 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334694391!23578026!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17324 invoked from network); 17 Apr 2012 20:26:31 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-9.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 20:26:31 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id E8D8E23A72; Tue, 17 Apr 2012 16:34:48 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: **
X-Spam-Status: No, score=2.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_64,
	J_CHICKENPOX_81,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME,TW_BX,TW_CF,
	TW_IB autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (unknown [69.165.202.139])
	by manny.calavera.ca (Postfix) with ESMTP id A7AD023C2E;
	Tue, 17 Apr 2012 16:34:46 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id BC1EF281A8; Mon, 16 Apr 2012 23:52:52 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 4130bb154f3436a9adf45a05462bee2baea41f36
Message-Id: <4130bb154f3436a9adf4.1334634685@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Apr 2012 23:51:25 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 v3] xl: add support for vif rate limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIGByYXRlYCBrZXl3b3JkIHNwZWNpZmllcyB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgb3V0Z29p
bmcgdHJhZmZpYwp3aWxsIGJlIGxpbWl0ZWQgdG8uIFRoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29y
ZCBpcyBub3Qgc3BlY2lmaWVkCmlzIHVubGltaXRlZC4KClRoZSBgcmF0ZWAga2V5d29yZCBzdXBw
b3J0cyBhbiBvcHRpb25hbCByZXBsZW5pc2htZW50IGludGVydmFsCnBhcmFtZXRlciBmb3Igc3Bl
Y2lmeWluZyB0aGUgZ3JhbnVsYXJpdHkgb2YgY3JlZGl0IHJlcGxlbmlzaG1lbnQuCkl0IGRldGVy
bWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQK
aXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMuCgpGb3IgZXhhbXBs
ZToKCiAgICAgICAgJ3JhdGU9MTBNYi9zJwogICAgICAgICdyYXRlPTI1MEtCL3MnCiAgICAgICAg
J3JhdGU9MU1CL3NAMjBtcycKClNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2FnbmVA
aXdlYi5jb20+CkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rv
d24gYi9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCi0tLSBhL2Rv
Y3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24KKysrIGIvZG9jcy9taXNj
L3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgpAQCAtMTIyLDUgKzEyMiwzNCBAQCBT
cGVjaWZpZXMgdGhlIGJhY2tlbmQgZG9tYWluIHdoaWNoIHRoaXMgCiBkZWZhdWx0cyB0byBkb21h
aW4gMC4gU3BlY2lmeWluZyBhbm90aGVyIGRvbWFpbiByZXF1aXJlcyBzZXR0aW5nIHVwIGEKIGRy
aXZlciBkb21haW4gd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4K
IAorIyMjIHJhdGUKKworU3BlY2lmaWVzIHRoZSByYXRlIGF0IHdoaWNoIHRoZSBvdXRnb2luZyB0
cmFmZmljIHdpbGwgYmUgbGltaXRlZCB0by4KK1RoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29yZCBp
cyBub3Qgc3BlY2lmaWVkIGlzIHVubGltaXRlZC4KKworVGhlIHJhdGUgbWF5IGJlIHNwZWNpZmll
ZCBhcyAiPFJBVEU+L3MiIG9yIG9wdGlvbmFsbHkgIjxSQVRFPi9zQDxJTlRFUlZBTD4iLgorCisg
ICogYFJBVEVgIGlzIGluIGJ5dGVzIGFuZCBjYW4gYWNjZXB0IHN1ZmZpeGVzOgorICAgICAgKiBH
QiwgTUIsIEtCLCBCIGZvciBieXRlcy4KKyAgICAgICogR2IsIE1iLCBLYiwgYiBmb3IgYml0cy4K
KyAgKiBgSU5URVJWQUxgIGlzIGluIG1pY3Jvc2Vjb25kcyBhbmQgY2FuIGFjY2VwdCBzdWZmaXhl
czogbXMsIHVzLCBzLgorICAgIEl0IGRldGVybWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0
aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQKKyAgICBpcyByZXBsZW5pc2hlZC4gVGhlIGRlZmF1
bHQgaXMgNTBtcy4KKworVmlmIHJhdGUgbGltaXRpbmcgaXMgY3JlZGl0LWJhc2VkLiBJdCBtZWFu
cyB0aGF0IGZvciAiMU1CL3NAMjBtcyIsIHRoZQorYXZhaWxhYmxlIGNyZWRpdCB3aWxsIGJlIGVx
dWl2YWxlbnQgb2YgdGhlIHRyYWZmaWMgeW91IHdvdWxkIGhhdmUgZG9uZQorYXQgIjFNQi9zIiBk
dXJpbmcgMjBtcy4gVGhpcyB3aWxsIHJlc3VsdHMgaW4gYSBjcmVkaXQgb2YgMjAsMDAwIGJ5dGVz
CityZXBsZW5pc2hlZCBldmVyeSAyMCwwMDAgdXMuCisKK0ZvciBleGFtcGxlOgorCisgICAgICAg
ICdyYXRlPTEwTWIvcycgLS0gbWVhbmluZyB1cCB0byAxMCBtZWdhYml0cyBldmVyeSBzZWNvbmQK
KyAgICAgICAgJ3JhdGU9MjUwS0IvcycgLS0gbWVhbmluZyB1cCB0byAyNTAga2lsb2J5dGVzIGV2
ZXJ5IHNlY29uZAorICAgICAgICAncmF0ZT0xTUIvc0AyMG1zJyAtLSBtZWFuaW5nIDIwLDAwMCBi
eXRlcyBpbiBldmVyeSAyMCBtaWxsaXNlY29uZCBwZXJpb2QKKworTk9URTogVGhlIGFjdHVhbCB1
bmRlcmx5aW5nIGxpbWl0cyBvZiByYXRlIGxpbWl0aW5nIGFyZSBkZXBlbmRlbnQKK29uIHRoZSB1
bmRlcmx5aW5nIG5ldGJhY2sgaW1wbGVtZW50YXRpb24uCisKKwogW291aV06IGh0dHA6Ly9lbi53
aWtpcGVkaWEub3JnL3dpa2kvT3JnYW5pemF0aW9uYWxseV9VbmlxdWVfSWRlbnRpZmllcgogW25l
dF06IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Ib3N0Q29uZmlndXJhdGlvbi9OZXR3b3JraW5n
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9NYWtlZmlsZSBiL3Rvb2xzL2xpYnhsL01ha2VmaWxl
Ci0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCkBA
IC02MSw3ICs2MSw3IEBAIExJQlhMX09CSlMgKz0gX2xpYnhsX3R5cGVzLm8gbGlieGxfZmxhc2sK
IEFVVE9JTkNTPSBsaWJ4bHVfY2ZnX3kuaCBsaWJ4bHVfY2ZnX2wuaCBfbGlieGxfbGlzdC5oCiBB
VVRPU1JDUz0gbGlieGx1X2NmZ195LmMgbGlieGx1X2NmZ19sLmMKIExJQlhMVV9PQkpTID0gbGli
eGx1X2NmZ195Lm8gbGlieGx1X2NmZ19sLm8gbGlieGx1X2NmZy5vIFwKLQlsaWJ4bHVfZGlza19s
Lm8gbGlieGx1X2Rpc2subyBsaWJ4bHVfcGNpLm8KKwlsaWJ4bHVfZGlza19sLm8gbGlieGx1X2Rp
c2subyBsaWJ4bHVfdmlmLm8gbGlieGx1X3BjaS5vCiAkKExJQlhMVV9PQkpTKTogQ0ZMQUdTICs9
ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICMgRm9yIHhlbnRvb2xsb2cuaAogCiBDTElFTlRTID0geGwg
dGVzdGlkbApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xp
YnhsLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGwuYworKysgYi90b29scy9saWJ4bC9saWJ4bC5j
CkBAIC0xODU0LDYgKzE4NTQsMTMgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRkKGxpYnhsX2N0
eCAqY3R4LAogICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2Ms
IG5pYy0+aXApKTsKICAgICB9CiAKKyAgICBpZiAobmljLT5yYXRlX2ludGVydmFsX3VzZWNzID4g
MCkgeworICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJyYXRlIik7CisgICAgICAgIGZs
ZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3NwcmludGYoZ2MsICIlIlBSSXU2NCIsJSJQUkl1
MzIiIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2lu
dGVydmFsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pYy0+cmF0ZV9pbnRlcnZhbF91
c2VjcykpOworICAgIH0KKwogICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgImJyaWRnZSIpOwog
ICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5icmlkZ2Up
KTsKICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJoYW5kbGUiKTsKZGlmZiAtLWdpdCBhL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCkBAIC0zNDMsNiArMzQzLDggQEAgbGlieGxfZGV2aWNlX25pYyA9IFN0cnVjdCgi
ZGV2aWNlX25pYyIsIAogICAgICgiaWZuYW1lIiwgc3RyaW5nKSwKICAgICAoInNjcmlwdCIsIHN0
cmluZyksCiAgICAgKCJuaWN0eXBlIiwgbGlieGxfbmljX3R5cGUpLAorICAgICgicmF0ZV9ieXRl
c19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAorICAgICgicmF0ZV9pbnRlcnZhbF91c2VjcyIsIHVp
bnQzMiksCiAgICAgXSkKIAogbGlieGxfZGV2aWNlX3BjaSA9IFN0cnVjdCgiZGV2aWNlX3BjaSIs
IFsKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oIGIvdG9vbHMvbGli
eGwvbGlieGx1X2ludGVybmFsLmgKLS0tIGEvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgK
KysrIGIvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgKQEAgLTE3LDkgKzE3LDExIEBACiAj
ZGVmaW5lIExJQlhMVV9JTlRFUk5BTF9ICiAKICNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUg
PHN0ZGxpYi5oPgogI2luY2x1ZGUgPGVycm5vLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5j
bHVkZSA8YXNzZXJ0Lmg+CisjaW5jbHVkZSA8cmVnZXguaD4KIAogI2RlZmluZSBYTFVfQ29uZmln
TGlzdCBYTFVfQ29uZmlnU2V0dGluZwogCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bHVf
dmlmLmMgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0t
IC9kZXYvbnVsbAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKQEAgLTAsMCArMSwxNDEg
QEAKKyNpbmNsdWRlICJsaWJ4bF9vc2RlcHMuaCIgLyogbXVzdCBjb21lIGJlZm9yZSBhbnkgb3Ro
ZXIgaGVhZGVycyAqLworI2luY2x1ZGUgImxpYnhsdV9pbnRlcm5hbC5oIgorCitzdGF0aWMgY29u
c3QgY2hhciAqdmlmX2J5dGVzX3Blcl9zZWNfcmUgPSAiXlswLTldK1tHTUtdP1tCYl0vcyQiOwor
c3RhdGljIGNvbnN0IGNoYXIgKnZpZl9pbnRlcm5hbF91c2VjX3JlID0gIl5bMC05XStbbXVdP3M/
JCI7CisKK3N0YXRpYyB2b2lkIHhsdV9fdmlmX2VycihYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKm1zZywgY29uc3QgY2hhciAqcmF0ZSkgeworICAgIGZwcmludGYoY2ZnLT5yZXBvcnQsCisg
ICAgICAgICAgICAiJXM6IGNvbmZpZyBwYXJzaW5nIGVycm9yIGluIHZpZjogJXMgaW4gYCVzJ1xu
IiwKKyAgICAgICAgICAgIGNmZy0+ZmlsZW5hbWUsIG1zZywgcmF0ZSk7Cit9CisKK3N0YXRpYyBp
bnQgdmlmX3BhcnNlX3JhdGVfYnl0ZXNfcGVyX3NlYyhYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKmJ5dGVzLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2
NF90ICpieXRlc19wZXJfc2VjKQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRt
cCA9IDA7CisgICAgY29uc3QgY2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29t
cCgmcmVjLCB2aWZfYnl0ZXNfcGVyX3NlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7Cisg
ICAgaWYgKHJlZ2V4ZWMoJnJlYywgYnl0ZXMsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9f
dmlmX2VycihjZmcsICJpbnZhbGlkIHJhdGUiLCBieXRlcyk7CisgICAgICAgIHJjID0gRUlOVkFM
OworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gYnl0ZXM7CisgICAgdG1wID0g
c3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8IHRtcCA+IFVJ
TlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcs
ICJyYXRlIG92ZXJmbG93IiwgYnl0ZXMpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgaWYgKCpwID09ICdHJykKKyAgICAgICB0bXAgKj0g
MTAwMCAqIDEwMDAgKiAxMDAwOworICAgIGVsc2UgaWYgKCpwID09ICdNJykKKyAgICAgICB0bXAg
Kj0gMTAwMCAqIDEwMDA7CisgICAgZWxzZSBpZiAoKnAgPT0gJ0snKQorICAgICAgIHRtcCAqPSAx
MDAwOworICAgIGlmICgqcCA9PSAnYicgfHwgKihwKzEpID09ICdiJykKKyAgICAgICB0bXAgLz0g
ODsKKworICAgICpieXRlc19wZXJfc2VjID0gdG1wOworCitvdXQ6CisgICAgcmVnZnJlZSgmcmVj
KTsKKyAgICByZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBpbnQgdmlmX3BhcnNlX3JhdGVfaW50ZXJ2
YWxfdXNlY3MoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICppbnRlcnZhbCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgKmludGVydmFsX3VzZWNz
KQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRtcCA9IDA7CisgICAgY29uc3Qg
Y2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29tcCgmcmVjLCB2aWZfaW50ZXJu
YWxfdXNlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7CisgICAgaWYgKHJlZ2V4ZWMoJnJl
YywgaW50ZXJ2YWwsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJp
bnZhbGlkIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwiLCBpbnRlcnZhbCk7CisgICAgICAgIHJjID0g
RUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gaW50ZXJ2YWw7Cisg
ICAgdG1wID0gc3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8
IHRtcCA+IFVJTlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlm
X2VycihjZmcsICJyZXBsZW5pc2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOwor
ICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAg
aWYgKCpwID09ICdzJyB8fCAqcCA9PSAnXDAnKQorICAgICAgICB0bXAgKj0gMTAwMCAqIDEwMDA7
CisgICAgZWxzZSBpZiAoKnAgPT0gJ20nKQorICAgICAgICB0bXAgKj0gMTAwMDsKKworICAgIGlm
ICh0bXAgPiBVSU5UMzJfTUFYKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJyZXBsZW5p
c2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOworICAgICAgICByYyA9IEVPVkVS
RkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAgKmludGVydmFsX3VzZWNzID0g
KHVpbnQzMl90KSB0bXA7CisKK291dDoKKyAgICByZWdmcmVlKCZyZWMpOworICAgIHJldHVybiBy
YzsKK30KKworaW50IHhsdV92aWZfcGFyc2VfcmF0ZShYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKnJhdGUsIGxpYnhsX2RldmljZV9uaWMgKm5pYykKK3sKKyAgICB1aW50NjRfdCBieXRlc19w
ZXJfc2VjID0gMDsKKyAgICB1aW50NjRfdCBieXRlc19wZXJfaW50ZXJ2YWwgPSAwOworICAgIHVp
bnQzMl90IGludGVydmFsX3VzZWNzID0gNTAwMDBVTDsgLyogRGVmYXVsdCB0byA1MG1zICovCisg
ICAgY2hhciAqcmF0ZXRvaywgKnRtcHJhdGU7CisgICAgaW50IHJjID0gMDsKKworICAgIHRtcHJh
dGUgPSBzdHJkdXAocmF0ZSk7CisgICAgaWYgKCFzdHJjbXAodG1wcmF0ZSwiIikpIHsKKyAgICAg
ICAgeGx1X192aWZfZXJyKGNmZywgIm5vIHJhdGUgc3BlY2lmaWVkIiwgcmF0ZSk7CisgICAgICAg
IHJjID0gRUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICByYXRldG9rID0g
c3RydG9rKHRtcHJhdGUsICJAIik7CisgICAgcmMgPSB2aWZfcGFyc2VfcmF0ZV9ieXRlc19wZXJf
c2VjKGNmZywgcmF0ZXRvaywgJmJ5dGVzX3Blcl9zZWMpOworICAgIGlmIChyYykgZ290byBvdXQ7
CisKKyAgICByYXRldG9rID0gc3RydG9rKE5VTEwsICJAIik7CisgICAgaWYgKHJhdGV0b2sgIT0g
TlVMTCkgeworICAgICAgICByYyA9IHZpZl9wYXJzZV9yYXRlX2ludGVydmFsX3VzZWNzKGNmZywg
cmF0ZXRvaywgJmludGVydmFsX3VzZWNzKTsKKyAgICAgICAgaWYgKHJjKSBnb3RvIG91dDsKKyAg
ICB9CisKKyAgICBpZiAoaW50ZXJ2YWxfdXNlY3MgIT0gMCAmJiAoYnl0ZXNfcGVyX3NlYyA+IChV
SU5UNjRfTUFYIC8gaW50ZXJ2YWxfdXNlY3MpKSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2Zn
LCAicmF0ZSBvdmVyZmxvdyIsIHJhdGUpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgYnl0ZXNfcGVyX2ludGVydmFsID0KKyAgICAgICAg
KCgodWludDY0X3QpIGJ5dGVzX3Blcl9zZWMgKiAodWludDY0X3QpIGludGVydmFsX3VzZWNzKSAv
IDEwMDAwMDBVTCk7CisKKyAgICBuaWMtPnJhdGVfaW50ZXJ2YWxfdXNlY3MgPSBpbnRlcnZhbF91
c2VjczsKKyAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsID0gYnl0ZXNfcGVyX2ludGVy
dmFsOworCitvdXQ6CisgICAgZnJlZSh0bXByYXRlKTsKKyAgICByZXR1cm4gcmM7Cit9CisKKy8q
CisgKiBMb2NhbCB2YXJpYWJsZXM6CisgKiBtb2RlOiBDCisgKiBjLWJhc2ljLW9mZnNldDogNAor
ICogaW5kZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8KZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL2xpYnhsdXRpbC5oIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGx1dGlsLmgKKysrIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKQEAgLTk0LDYg
Kzk0LDEzIEBAIGludCB4bHVfZGlza19wYXJzZShYTFVfQ29uZmlnICpjZmcsIGludCAKIGludCB4
bHVfcGNpX3BhcnNlX2JkZihYTFVfQ29uZmlnICpjZmcsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRl
diwgY29uc3QgY2hhciAqc3RyKTsKIAogCisvKgorICogVmlmIHJhdGUgcGFyc2luZy4KKyAqLwor
CitpbnQgeGx1X3ZpZl9wYXJzZV9yYXRlKFhMVV9Db25maWcgKmNmZywgY29uc3QgY2hhciAqcmF0
ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfZGV2aWNlX25pYyAqbmljKTsKKwogI2Vu
ZGlmIC8qIExJQlhMVVRJTF9IICovCiAKIC8qCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9j
bWRpbXBsLmMgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtNDAzLDYgKzQwMywx
OSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9kaXNrX2NvbmZpZyhYTFVfQ29uZmlnCiAgICAgcGFyc2Vf
ZGlza19jb25maWdfbXVsdGlzdHJpbmcoY29uZmlnLCAxLCAmc3BlYywgZGlzayk7CiB9CiAKK3N0
YXRpYyB2b2lkIHBhcnNlX3ZpZl9yYXRlKFhMVV9Db25maWcgKipjb25maWcsIGNvbnN0IGNoYXIg
KnJhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZpY2VfbmljICpuaWMp
Cit7CisgICAgaW50IGU7CisKKyAgICBlID0geGx1X3ZpZl9wYXJzZV9yYXRlKCpjb25maWcsIHJh
dGUsIG5pYyk7CisgICAgaWYgKGUgPT0gRUlOVkFMIHx8IGUgPT0gRU9WRVJGTE9XKSBleGl0KC0x
KTsKKyAgICBpZiAoZSkgeworICAgICAgICBmcHJpbnRmKHN0ZGVyciwieGx1X3ZpZl9wYXJzZV9y
YXRlIGZhaWxlZDogJXNcbiIsc3RyZXJyb3IoZXJybm8pKTsKKyAgICAgICAgZXhpdCgtMSk7Cisg
ICAgfQorfQorCiBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJpbmdfbGlzdChjb25z
dCBjaGFyICpzdHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
b25zdCBjaGFyICpkZWxpbSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX3N0cmluZ19saXN0ICpwc2wpCkBAIC05MDYsNyArOTE5LDcgQEAgc3RhdGljIHZv
aWQgcGFyc2VfY29uZmlnX2RhdGEoY29uc3QgY2hhcgogICAgICAgICAgICAgICAgICAgICAgICAg
bmljLT5iYWNrZW5kX2RvbWlkID0gMDsKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAg
ICAgICAgIH0gZWxzZSBpZiAoIXN0cmNtcChwLCAicmF0ZSIpKSB7Ci0gICAgICAgICAgICAgICAg
ICAgIGZwcmludGYoc3RkZXJyLCAidGhlIHJhdGUgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJl
bnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKKyAgICAgICAgICAgICAgICAgICAgcGFyc2VfdmlmX3Jh
dGUoJmNvbmZpZywgKHAyICsgMSksIG5pYyk7CiAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICgh
c3RyY21wKHAsICJhY2NlbCIpKSB7CiAgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJy
LCAidGhlIGFjY2VsIHBhcmFtZXRlciBmb3IgdmlmcyBpcyBjdXJyZW50bHkgbm90IHN1cHBvcnRl
ZFxuIik7CiAgICAgICAgICAgICAgICAgfQpAQCAtNDg1NSw2ICs0ODY4LDcgQEAgaW50IG1haW5f
bmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAqKgogewogICAgIGludCBvcHQ7CiAgICAgbGli
eGxfZGV2aWNlX25pYyBuaWM7CisgICAgWExVX0NvbmZpZyAqY29uZmlnID0gMDsKICAgICBjaGFy
ICplbmRwdHIsICpvcGFyZzsKICAgICBjb25zdCBjaGFyICp0b2s7CiAgICAgaW50IGk7CkBAIC00
ODcyLDYgKzQ4ODYsMTMgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIiVzIGlzIGFuIGludmFsaWQgZG9tYWluIGlkZW50
aWZpZXJcbiIsIGFyZ3Zbb3B0aW5kXSk7CiAgICAgICAgIHJldHVybiAxOwogICAgIH0KKworICAg
IGNvbmZpZz0geGx1X2NmZ19pbml0KHN0ZGVyciwgImNvbW1hbmQgbGluZSIpOworICAgIGlmICgh
Y29uZmlnKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRmFpbGVkIHRvIGFsbG9jYXRlIGZv
ciBjb25maWd1cmF0aW9uXG4iKTsKKyAgICAgICAgcmV0dXJuIDE7CisgICAgfQorCiAgICAgbGli
eGxfZGV2aWNlX25pY19pbml0KCZuaWMpOwogICAgIGZvciAoYXJndiArPSBvcHRpbmQrMSwgYXJn
YyAtPSBvcHRpbmQrMTsgYXJnYyA+IDA7ICsrYXJndiwgLS1hcmdjKSB7CiAgICAgICAgIGlmIChN
QVRDSF9PUFRJT04oInR5cGUiLCAqYXJndiwgb3BhcmcpKSB7CkBAIC00OTEwLDYgKzQ5MzEsNyBA
QCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCiAgICAgICAgIH0gZWxz
ZSBpZiAoTUFUQ0hfT1BUSU9OKCJtb2RlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgICAg
IHJlcGxhY2Vfc3RyaW5nKCZuaWMubW9kZWwsIG9wYXJnKTsKICAgICAgICAgfSBlbHNlIGlmIChN
QVRDSF9PUFRJT04oInJhdGUiLCAqYXJndiwgb3BhcmcpKSB7CisgICAgICAgICAgICBwYXJzZV92
aWZfcmF0ZSgmY29uZmlnLCBvcGFyZywgJm5pYyk7CiAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hf
T1BUSU9OKCJhY2NlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgfSBlbHNlIHsKICAgICAg
ICAgICAgIGZwcmludGYoc3RkZXJyLCAidW5yZWNvZ25pemVkIGFyZ3VtZW50IGAlcydcbiIsICph
cmd2KTsKQEAgLTQ5MzEsNiArNDk1Myw3IEBAIGludCBtYWluX25ldHdvcmthdHRhY2goaW50IGFy
Z2MsIGNoYXIgKioKICAgICAgICAgcmV0dXJuIDE7CiAgICAgfQogICAgIGxpYnhsX2RldmljZV9u
aWNfZGlzcG9zZSgmbmljKTsKKyAgICB4bHVfY2ZnX2Rlc3Ryb3koY29uZmlnKTsKICAgICByZXR1
cm4gMDsKIH0KIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKF9Q-0001D3-GZ; Tue, 17 Apr 2012 20:37:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKF9O-0001Cy-KJ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:37:22 +0000
Received: from [85.158.139.83:60073] by server-5.bemta-5.messagelabs.com id
	BD/8E-13566-184DD8F4; Tue, 17 Apr 2012 20:37:21 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334695039!20380822!1
X-Originating-IP: [70.38.127.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16502 invoked from network); 17 Apr 2012 20:37:20 -0000
Received: from mail2.malak.privatedns.com (HELO mail.corp.iweb.com)
	(70.38.127.104) by server-6.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 20:37:20 -0000
Received: (qmail 11676 invoked by uid 509); 17 Apr 2012 20:37:18 -0000
Received: from 69-165-202-139.cable.teksavvy.com (HELO poste-125.local)
	(mgagne@iweb.com@69.165.202.139)
	by mail.corp.iweb.com with SMTP; 17 Apr 2012 20:37:18 -0000
Message-ID: <4F8DD47E.2080201@iweb.com>
Date: Tue, 17 Apr 2012 16:37:18 -0400
From: =?ISO-8859-1?Q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:12.0) Gecko/20120321 Thunderbird/12.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
	<20365.45913.257023.201323@mariner.uk.xensource.com>
In-Reply-To: <20365.45913.257023.201323@mariner.uk.xensource.com>
X-TagToolbar-Keys: D20120417163717986
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 4/17/12 2:15 PM, Ian Jackson wrote:
> Mathieu Gagn=E9 writes ("[Xen-devel] [PATCH 0 of 4 v2] xl: add support fo=
r vif rate limiting"):
>> This patch series implements the required plumbering for vif rate limiti=
ng in libxl/xl.
>
> Thanks, I have applied the first two.

Thanks.

> Whe you repost can you please make sure to wrap the commit messages to
> 70 columns or so ?

Done. I forgot to synchronize the time of my virtual machine.

The v3 of this patch series is up there at "Mon, 16 Apr 2012 23:51:22 =

-0400".

-- =

Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKF9Q-0001D3-GZ; Tue, 17 Apr 2012 20:37:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SKF9O-0001Cy-KJ
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:37:22 +0000
Received: from [85.158.139.83:60073] by server-5.bemta-5.messagelabs.com id
	BD/8E-13566-184DD8F4; Tue, 17 Apr 2012 20:37:21 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334695039!20380822!1
X-Originating-IP: [70.38.127.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16502 invoked from network); 17 Apr 2012 20:37:20 -0000
Received: from mail2.malak.privatedns.com (HELO mail.corp.iweb.com)
	(70.38.127.104) by server-6.tower-182.messagelabs.com with SMTP;
	17 Apr 2012 20:37:20 -0000
Received: (qmail 11676 invoked by uid 509); 17 Apr 2012 20:37:18 -0000
Received: from 69-165-202-139.cable.teksavvy.com (HELO poste-125.local)
	(mgagne@iweb.com@69.165.202.139)
	by mail.corp.iweb.com with SMTP; 17 Apr 2012 20:37:18 -0000
Message-ID: <4F8DD47E.2080201@iweb.com>
Date: Tue, 17 Apr 2012 16:37:18 -0400
From: =?ISO-8859-1?Q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:12.0) Gecko/20120321 Thunderbird/12.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1334627902@mgagne.users.dev.iweb.com>
	<20365.45913.257023.201323@mariner.uk.xensource.com>
In-Reply-To: <20365.45913.257023.201323@mariner.uk.xensource.com>
X-TagToolbar-Keys: D20120417163717986
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 4/17/12 2:15 PM, Ian Jackson wrote:
> Mathieu Gagn=E9 writes ("[Xen-devel] [PATCH 0 of 4 v2] xl: add support fo=
r vif rate limiting"):
>> This patch series implements the required plumbering for vif rate limiti=
ng in libxl/xl.
>
> Thanks, I have applied the first two.

Thanks.

> Whe you repost can you please make sure to wrap the commit messages to
> 70 columns or so ?

Done. I forgot to synchronize the time of my virtual machine.

The v3 of this patch series is up there at "Mon, 16 Apr 2012 23:51:22 =

-0400".

-- =

Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:55:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFR4-0001Yv-18; Tue, 17 Apr 2012 20:55:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SKFR2-0001Ym-Qe
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:55:37 +0000
Received: from [85.158.143.35:17005] by server-1.bemta-4.messagelabs.com id
	03/3C-20925-8C8DD8F4; Tue, 17 Apr 2012 20:55:36 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334696134!12490379!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19437 invoked from network); 17 Apr 2012 20:55:35 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 20:55:35 -0000
Received: by qcsp15 with SMTP id p15so5257616qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 13:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=IT5fSm5yiaFpxbGuik1TqlhxKwXin9HofbLzA4A/EzM=;
	b=K52uqSECj/0s7tlRjUXu3+yj9GKBWUIyVgCKU3MUS1MY+sW9+9jA8GHSd2Z680Qi2d
	bhTzlkiSAXuNXELnNc8vZYi6vd1ppAZ0MWEM1t5WRFrdIIOeSAaDgLZgCgjp3fJJPAei
	n1L4/DAzTewK7QZgFoeD1+Uitv0xnk8NDDi9vSvPdOKgPj31qJy4Jizh+RXyvnvNT/jI
	qYP1l8ICdko9gna+ltWDO9nk51IIKGPEyUALyJBbkUzKJ3nClxonHFSKzJLO60tGNAxn
	ow1eQ9pG2p1KZsmR0xgVO4B2DJchCOP7R31w0T+S5Xyro674vl0euejOFknh5t6NJWnF
	8K/Q==
MIME-Version: 1.0
Received: by 10.224.184.70 with SMTP id cj6mr168708qab.77.1334696133801; Tue,
	17 Apr 2012 13:55:33 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Tue, 17 Apr 2012 13:55:33 -0700 (PDT)
In-Reply-To: <1334647651.11493.4.camel@dagon.hellion.org.uk>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
Date: Tue, 17 Apr 2012 13:55:33 -0700
Message-ID: <CAGU+aus_Qm683DT+z3OAaTqT6VoR_ApEmZNGu6W9G1EN0biyXQ@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 12:27 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
>> of pages (in the GB range) from a guest in to Dom0
>
> Out of interest -- what are you doing this for?

Mainly to speedup gva to gpa translation. I map in most of guest
memory and do the page table walk within my app as I find doing the
translation using libxc to be quite slow.

>> =A0using
>> xc_map_foreign_bulk() I am hitting a segfault.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x605050,
>> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>, arr=3D0x7f=
fff6bf5010,
>> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> 52 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src, __len, __bos=
0 (__dest));
>> (gdb) bt
>> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x6050=
50,
>> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>, arr=3D0x7f=
fff6bf5010,
>> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized out>,
>> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<optimized =
out>,
>> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at xc_foreign_memo=
ry.c:79
>>
>> This was working for me with Xen 4.1.2. On comparing
>> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
>> the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
>> using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
>> stack with the call.
>
> I bet this is due to Linux's stack guard page. This means that if you
> try and increase the stack by more than ~1 page you skip entirely over
> the "next" stack page and into the guard.
>
> Does it help if after the alloca you add a loop which touches the first
> word of each page of the new buffer? Since the stack grows down you
> might actually need to do it backwards from the end of the array in
> order to start at the end which is nearest the existing stack? (it's
> before coffee o'clock so thinking about stack direction isn't my strong
> point yet...)
>
> The switch to alloca was made recently in order to optimise the hotpath
> for a userspace I/O backend.
>
> BTW, Santosh, it didn't occur to me at the time but what is privcmd mmap
> doing on the hot path for the userspace I/O anyway? Most hotpath
> operations should really be grant table ops, a backend shouldn't be
> relying on the privileges accorded to dom0 -- for one thing it should be
> expected to work in a driver domain.
>
>> =A0If I replace the alloca() with malloc() the call
>> goes through. What is the way around this? Should I be using
>> xc_map_foreign_batch() instead, which I think is deprecated? Please
>> advice...
>>
>> Thanks,
>> AP
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:55:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFR4-0001Yv-18; Tue, 17 Apr 2012 20:55:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SKFR2-0001Ym-Qe
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 20:55:37 +0000
Received: from [85.158.143.35:17005] by server-1.bemta-4.messagelabs.com id
	03/3C-20925-8C8DD8F4; Tue, 17 Apr 2012 20:55:36 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334696134!12490379!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19437 invoked from network); 17 Apr 2012 20:55:35 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 20:55:35 -0000
Received: by qcsp15 with SMTP id p15so5257616qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 13:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=IT5fSm5yiaFpxbGuik1TqlhxKwXin9HofbLzA4A/EzM=;
	b=K52uqSECj/0s7tlRjUXu3+yj9GKBWUIyVgCKU3MUS1MY+sW9+9jA8GHSd2Z680Qi2d
	bhTzlkiSAXuNXELnNc8vZYi6vd1ppAZ0MWEM1t5WRFrdIIOeSAaDgLZgCgjp3fJJPAei
	n1L4/DAzTewK7QZgFoeD1+Uitv0xnk8NDDi9vSvPdOKgPj31qJy4Jizh+RXyvnvNT/jI
	qYP1l8ICdko9gna+ltWDO9nk51IIKGPEyUALyJBbkUzKJ3nClxonHFSKzJLO60tGNAxn
	ow1eQ9pG2p1KZsmR0xgVO4B2DJchCOP7R31w0T+S5Xyro674vl0euejOFknh5t6NJWnF
	8K/Q==
MIME-Version: 1.0
Received: by 10.224.184.70 with SMTP id cj6mr168708qab.77.1334696133801; Tue,
	17 Apr 2012 13:55:33 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Tue, 17 Apr 2012 13:55:33 -0700 (PDT)
In-Reply-To: <1334647651.11493.4.camel@dagon.hellion.org.uk>
References: <CAGU+aus=e78GO9p7rD8pPb14KTgWN5uHk-qJzGt-2KtuKR=7FA@mail.gmail.com>
	<1334647651.11493.4.camel@dagon.hellion.org.uk>
Date: Tue, 17 Apr 2012 13:55:33 -0700
Message-ID: <CAGU+aus_Qm683DT+z3OAaTqT6VoR_ApEmZNGu6W9G1EN0biyXQ@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 12:27 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>> On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
>> of pages (in the GB range) from a guest in to Dom0
>
> Out of interest -- what are you doing this for?

Mainly to speedup gva to gpa translation. I map in most of guest
memory and do the page table walk within my app as I find doing the
translation using libxc to be quite slow.

>> =A0using
>> xc_map_foreign_bulk() I am hitting a segfault.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x605050,
>> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>, arr=3D0x7f=
fff6bf5010,
>> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> 52 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src, __len, __bos=
0 (__dest));
>> (gdb) bt
>> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x6050=
50,
>> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>, arr=3D0x7f=
fff6bf5010,
>> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized out>,
>> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<optimized =
out>,
>> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at xc_foreign_memo=
ry.c:79
>>
>> This was working for me with Xen 4.1.2. On comparing
>> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
>> the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
>> using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
>> stack with the call.
>
> I bet this is due to Linux's stack guard page. This means that if you
> try and increase the stack by more than ~1 page you skip entirely over
> the "next" stack page and into the guard.
>
> Does it help if after the alloca you add a loop which touches the first
> word of each page of the new buffer? Since the stack grows down you
> might actually need to do it backwards from the end of the array in
> order to start at the end which is nearest the existing stack? (it's
> before coffee o'clock so thinking about stack direction isn't my strong
> point yet...)
>
> The switch to alloca was made recently in order to optimise the hotpath
> for a userspace I/O backend.
>
> BTW, Santosh, it didn't occur to me at the time but what is privcmd mmap
> doing on the hot path for the userspace I/O anyway? Most hotpath
> operations should really be grant table ops, a backend shouldn't be
> relying on the privileges accorded to dom0 -- for one thing it should be
> expected to work in a driver domain.
>
>> =A0If I replace the alloca() with malloc() the call
>> goes through. What is the way around this? Should I be using
>> xc_map_foreign_batch() instead, which I think is deprecated? Please
>> advice...
>>
>> Thanks,
>> AP
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:59:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFUq-0001nt-Mr; Tue, 17 Apr 2012 20:59:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SKFUo-0001nX-DC
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 20:59:32 +0000
Received: from [85.158.143.99:32240] by server-3.bemta-4.messagelabs.com id
	D2/9F-05853-0B9DD8F4; Tue, 17 Apr 2012 20:59:28 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334696366!20699557!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32049 invoked from network); 17 Apr 2012 20:59:27 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 20:59:27 -0000
Received: by qcsc20 with SMTP id c20so5081494qcs.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 13:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=3grKKmbRD9gD7HQtpBsq4CjYW2O6NW2hFjNk1Lxaw6Q=;
	b=uiVdoz4J9NPGR0EnTxaDQTCVXNUbQqhr9pYdYYHQreeo88PYSri85RN2MOlq6LXik6
	0QMewuSYIXEBV5/3SPuXzLzIc8on5vbmRMwLUz7+c1c1op4AF9qTXoYCvZ606ReuQY9Z
	ZrFG5pqYSD9WHavGmgIfJIar3SqN2QYwPJc9gKjXYprqf4C5lLHgdSaogrE2GmH062oK
	mveTFvG9ldZNKK0US3T0ba8tXpxKL89tXQh9EF/3XNF05GliFMmnFcUNkJd6nl5UwY+2
	l0x0xOHWPY3XRd2KGqZfsl8ckpsOSA0IilRR0bxuYEDDP/c2npgmEeMFCyC2dcMmbivE
	b5mA==
MIME-Version: 1.0
Received: by 10.224.211.9 with SMTP id gm9mr180225qab.78.1334696366162; Tue,
	17 Apr 2012 13:59:26 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Tue, 17 Apr 2012 13:59:26 -0700 (PDT)
In-Reply-To: <1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
	<1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
Date: Tue, 17 Apr 2012 13:59:26 -0700
Message-ID: <CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: andres@lagarcavilla.org
Cc: JBeulich@suse.com, ian.campbell@citrix.com, Santosh.Jodh@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 8:56 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>>
>> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>>> told me to change all others while I was in there.
>>
>> Oh, right, I remember now.
>>
>> Given that reverting it for this case will still leave the same issue
>> for the grant case (which I'd forgotten about) I suppose the appropriate
>> workaround is to touch the alloca'd memory in the appropriate order in
>> all cases (perhaps with an alloca helper macro).
>
> FWIW, I am very skeptical about this whole alloca business. It's very very
> dangerous, no surprise on the bug report. On my code I tend to map
> arbitrarily-sized pfn arrays, and I've been thinking of disabling alloca.
>
> If your only safeguard is to put a loop that touches everything so the
> stack gets allocated .... then what's your gain?
>
> Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
> round_to_page_size(what_you_need)). That's likely the fastest way to get
> the array in Linux. It isn't that slow either. And it's safe.

I tried and it worked for me.

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -34,16 +34,17 @@
 #include <xen/memory.h>
 #include <xen/sys/evtchn.h>
 #include <xen/sys/gntdev.h>
 #include <xen/sys/gntalloc.h>

 #include "xenctrl.h"
 #include "xenctrlosdep.h"

+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w)=
)-1))
 #define ERROR(_m, _a...)
xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d =3D %s)", ## _a , errno, xc_strerror(xch, errno))

 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
     int flags, saved_errno;
     int fd =3D open("/proc/xen/privcmd", O_RDWR);
@@ -281,17 +282,24 @@ static void *linux_privcmd_map_foreign_b
     /* Command was not recognized, use fall back */
     else if ( rc < 0 && errno =3D=3D EINVAL && (int)num > 0 )
     {
         /*
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
XC_PAGE_SHIFT),
+                              PROT_READ | PROT_WRITE,
+                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0=
);
+        if ( pfn =3D=3D MAP_FAILED )
+        {
+            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+            return NULL;
+        }

         memcpy(pfn, arr, num * sizeof(*arr));

         ioctlx.num =3D num;
         ioctlx.dom =3D dom;
         ioctlx.addr =3D (unsigned long)addr;
         ioctlx.arr =3D pfn;

@@ -323,16 +331,18 @@ static void *linux_privcmd_map_foreign_b
                     break;
                 }
                 rc =3D -ENOENT;
                 continue;
             }
             break;
         }

+        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
+
         if ( rc =3D=3D -ENOENT && i =3D=3D num )
             rc =3D 0;
         else if ( rc )
         {
             errno =3D -rc;
             rc =3D -1;
         }
     }


> Andres
>
>>
>> Ian.
>>
>>>
>>> -----Original Message-----
>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>> Sent: Tuesday, April 17, 2012 12:56 AM
>>> To: Ian Campbell; AP
>>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>>> causing segfault
>>>
>>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>>> >> amounts of pages (in the GB range) from a guest in to Dom0
>>> >
>>> > Out of interest -- what are you doing this for?
>>> >
>>> >> =A0using
>>> >> xc_map_foreign_bulk() I am hitting a segfault.
>>> >>
>>> >> Program received signal SIGSEGV, Segmentation fault.
>>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x605050,
>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>> arr=3D0x7ffff6bf5010,
>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>> >> 52 =A0 =A0 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src, =
__len, __bos0
>>> (__dest));
>>> >> (gdb) bt
>>> >> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>> (xch=3D0x605050,
>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>> arr=3D0x7ffff6bf5010,
>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>> >> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized ou=
t>,
>>> >> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<optimi=
zed out>,
>>> >> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at
>>> >> xc_foreign_memory.c:79
>>> >>
>>> >> This was working for me with Xen 4.1.2. On comparing
>>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>>> >> blowing the stack with the call.
>>> >
>>> > I bet this is due to Linux's stack guard page. This means that if you
>>> > try and increase the stack by more than ~1 page you skip entirely over
>>> > the "next" stack page and into the guard.
>>> >
>>> > Does it help if after the alloca you add a loop which touches the
>>> > first word of each page of the new buffer? Since the stack grows down
>>> > you might actually need to do it backwards from the end of the array
>>> > in order to start at the end which is nearest the existing stack?
>>> > (it's before coffee o'clock so thinking about stack direction isn't my
>>> > strong point yet...)
>>>
>>> This should really be done by the alloca() implementation itself -
>>> anything else is a bug.
>>>
>>> > The switch to alloca was made recently in order to optimise the
>>> > hotpath for a userspace I/O backend.
>>>
>>> Probably this should be made size-dependent ...
>>>
>>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>>> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath
>>> > operations should really be grant table ops, a backend shouldn't be
>>> > relying on the privileges accorded to dom0 -- for one thing it should
>>> > be expected to work in a driver domain.
>>>
>>> ... if this indeed turns out to be a hot path for something at all?
>>>
>>> Jan
>>>
>>> >> =A0If I replace the alloca() with malloc() the call goes through. Wh=
at
>>> >> is the way around this? Should I be using
>>> >> xc_map_foreign_batch() instead, which I think is deprecated? Please
>>> >> advice...
>>> >>
>>> >> Thanks,
>>> >> AP
>>> >>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 20:59:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 20:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFUq-0001nt-Mr; Tue, 17 Apr 2012 20:59:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SKFUo-0001nX-DC
	for xen-devel@lists.xen.org; Tue, 17 Apr 2012 20:59:32 +0000
Received: from [85.158.143.99:32240] by server-3.bemta-4.messagelabs.com id
	D2/9F-05853-0B9DD8F4; Tue, 17 Apr 2012 20:59:28 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334696366!20699557!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32049 invoked from network); 17 Apr 2012 20:59:27 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 20:59:27 -0000
Received: by qcsc20 with SMTP id c20so5081494qcs.32
	for <xen-devel@lists.xen.org>; Tue, 17 Apr 2012 13:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=3grKKmbRD9gD7HQtpBsq4CjYW2O6NW2hFjNk1Lxaw6Q=;
	b=uiVdoz4J9NPGR0EnTxaDQTCVXNUbQqhr9pYdYYHQreeo88PYSri85RN2MOlq6LXik6
	0QMewuSYIXEBV5/3SPuXzLzIc8on5vbmRMwLUz7+c1c1op4AF9qTXoYCvZ606ReuQY9Z
	ZrFG5pqYSD9WHavGmgIfJIar3SqN2QYwPJc9gKjXYprqf4C5lLHgdSaogrE2GmH062oK
	mveTFvG9ldZNKK0US3T0ba8tXpxKL89tXQh9EF/3XNF05GliFMmnFcUNkJd6nl5UwY+2
	l0x0xOHWPY3XRd2KGqZfsl8ckpsOSA0IilRR0bxuYEDDP/c2npgmEeMFCyC2dcMmbivE
	b5mA==
MIME-Version: 1.0
Received: by 10.224.211.9 with SMTP id gm9mr180225qab.78.1334696366162; Tue,
	17 Apr 2012 13:59:26 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Tue, 17 Apr 2012 13:59:26 -0700 (PDT)
In-Reply-To: <1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
	<1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
Date: Tue, 17 Apr 2012 13:59:26 -0700
Message-ID: <CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: andres@lagarcavilla.org
Cc: JBeulich@suse.com, ian.campbell@citrix.com, Santosh.Jodh@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 8:56 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>>
>> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>>> told me to change all others while I was in there.
>>
>> Oh, right, I remember now.
>>
>> Given that reverting it for this case will still leave the same issue
>> for the grant case (which I'd forgotten about) I suppose the appropriate
>> workaround is to touch the alloca'd memory in the appropriate order in
>> all cases (perhaps with an alloca helper macro).
>
> FWIW, I am very skeptical about this whole alloca business. It's very very
> dangerous, no surprise on the bug report. On my code I tend to map
> arbitrarily-sized pfn arrays, and I've been thinking of disabling alloca.
>
> If your only safeguard is to put a loop that touches everything so the
> stack gets allocated .... then what's your gain?
>
> Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
> round_to_page_size(what_you_need)). That's likely the fastest way to get
> the array in Linux. It isn't that slow either. And it's safe.

I tried and it worked for me.

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -34,16 +34,17 @@
 #include <xen/memory.h>
 #include <xen/sys/evtchn.h>
 #include <xen/sys/gntdev.h>
 #include <xen/sys/gntalloc.h>

 #include "xenctrl.h"
 #include "xenctrlosdep.h"

+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w)=
)-1))
 #define ERROR(_m, _a...)
xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d =3D %s)", ## _a , errno, xc_strerror(xch, errno))

 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
     int flags, saved_errno;
     int fd =3D open("/proc/xen/privcmd", O_RDWR);
@@ -281,17 +282,24 @@ static void *linux_privcmd_map_foreign_b
     /* Command was not recognized, use fall back */
     else if ( rc < 0 && errno =3D=3D EINVAL && (int)num > 0 )
     {
         /*
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
XC_PAGE_SHIFT),
+                              PROT_READ | PROT_WRITE,
+                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0=
);
+        if ( pfn =3D=3D MAP_FAILED )
+        {
+            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+            return NULL;
+        }

         memcpy(pfn, arr, num * sizeof(*arr));

         ioctlx.num =3D num;
         ioctlx.dom =3D dom;
         ioctlx.addr =3D (unsigned long)addr;
         ioctlx.arr =3D pfn;

@@ -323,16 +331,18 @@ static void *linux_privcmd_map_foreign_b
                     break;
                 }
                 rc =3D -ENOENT;
                 continue;
             }
             break;
         }

+        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
+
         if ( rc =3D=3D -ENOENT && i =3D=3D num )
             rc =3D 0;
         else if ( rc )
         {
             errno =3D -rc;
             rc =3D -1;
         }
     }


> Andres
>
>>
>> Ian.
>>
>>>
>>> -----Original Message-----
>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>> Sent: Tuesday, April 17, 2012 12:56 AM
>>> To: Ian Campbell; AP
>>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>>> causing segfault
>>>
>>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>>> >> amounts of pages (in the GB range) from a guest in to Dom0
>>> >
>>> > Out of interest -- what are you doing this for?
>>> >
>>> >> =A0using
>>> >> xc_map_foreign_bulk() I am hitting a segfault.
>>> >>
>>> >> Program received signal SIGSEGV, Segmentation fault.
>>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x605050,
>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>> arr=3D0x7ffff6bf5010,
>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>> >> 52 =A0 =A0 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src, =
__len, __bos0
>>> (__dest));
>>> >> (gdb) bt
>>> >> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>> (xch=3D0x605050,
>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>> arr=3D0x7ffff6bf5010,
>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>> >> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized ou=
t>,
>>> >> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<optimi=
zed out>,
>>> >> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at
>>> >> xc_foreign_memory.c:79
>>> >>
>>> >> This was working for me with Xen 4.1.2. On comparing
>>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>>> >> blowing the stack with the call.
>>> >
>>> > I bet this is due to Linux's stack guard page. This means that if you
>>> > try and increase the stack by more than ~1 page you skip entirely over
>>> > the "next" stack page and into the guard.
>>> >
>>> > Does it help if after the alloca you add a loop which touches the
>>> > first word of each page of the new buffer? Since the stack grows down
>>> > you might actually need to do it backwards from the end of the array
>>> > in order to start at the end which is nearest the existing stack?
>>> > (it's before coffee o'clock so thinking about stack direction isn't my
>>> > strong point yet...)
>>>
>>> This should really be done by the alloca() implementation itself -
>>> anything else is a bug.
>>>
>>> > The switch to alloca was made recently in order to optimise the
>>> > hotpath for a userspace I/O backend.
>>>
>>> Probably this should be made size-dependent ...
>>>
>>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>>> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath
>>> > operations should really be grant table ops, a backend shouldn't be
>>> > relying on the privileges accorded to dom0 -- for one thing it should
>>> > be expected to work in a driver domain.
>>>
>>> ... if this indeed turns out to be a hot path for something at all?
>>>
>>> Jan
>>>
>>> >> =A0If I replace the alloca() with malloc() the call goes through. Wh=
at
>>> >> is the way around this? Should I be using
>>> >> xc_map_foreign_batch() instead, which I think is deprecated? Please
>>> >> advice...
>>> >>
>>> >> Thanks,
>>> >> AP
>>> >>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 21:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 21:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFat-00024c-HO; Tue, 17 Apr 2012 21:05:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKFas-00024V-2V
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 21:05:46 +0000
Received: from [193.109.254.147:18317] by server-10.bemta-14.messagelabs.com
	id 3C/6A-05847-92BDD8F4; Tue, 17 Apr 2012 21:05:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334696743!5054953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3947 invoked from network); 17 Apr 2012 21:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 21:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,438,1330905600"; d="scan'208";a="11988348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 21:05:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 22:05:43 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKFap-00085j-DE;
	Tue, 17 Apr 2012 21:05:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKFap-0007Ki-CR;
	Tue, 17 Apr 2012 22:05:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12706-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 22:05:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12706: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12706 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12706/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                23cc08d8a257b7db4506b1388b1614374dc7547a
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 23cc08d8a257b7db4506b1388b1614374dc7547a
Merge: ceae86c... 6889463...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Apr 16 20:44:06 2012 +0200

    Merge branch 'x86/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 21:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 21:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFat-00024c-HO; Tue, 17 Apr 2012 21:05:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKFas-00024V-2V
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 21:05:46 +0000
Received: from [193.109.254.147:18317] by server-10.bemta-14.messagelabs.com
	id 3C/6A-05847-92BDD8F4; Tue, 17 Apr 2012 21:05:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334696743!5054953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3947 invoked from network); 17 Apr 2012 21:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Apr 2012 21:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,438,1330905600"; d="scan'208";a="11988348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Apr 2012 21:05:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Apr 2012 22:05:43 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKFap-00085j-DE;
	Tue, 17 Apr 2012 21:05:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKFap-0007Ki-CR;
	Tue, 17 Apr 2012 22:05:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12706-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Apr 2012 22:05:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12706: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12706 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12706/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 linux                23cc08d8a257b7db4506b1388b1614374dc7547a
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 23cc08d8a257b7db4506b1388b1614374dc7547a
Merge: ceae86c... 6889463...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Apr 16 20:44:06 2012 +0200

    Merge branch 'x86/urgent'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 21:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 21:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFyv-0002Oz-O2; Tue, 17 Apr 2012 21:30:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SKFyt-0002Ou-Vi
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 21:30:36 +0000
Received: from [85.158.138.51:23835] by server-9.bemta-3.messagelabs.com id
	97/85-26691-BF0ED8F4; Tue, 17 Apr 2012 21:30:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334698232!18395137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NTkzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15122 invoked from network); 17 Apr 2012 21:30:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 21:30:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HLUUuK013939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 21:30:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HLUTbg010018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 21:30:30 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HLUTtR009448; Tue, 17 Apr 2012 16:30:29 -0500
MIME-Version: 1.0
Message-ID: <57a8bc29-6075-49fb-a2fc-190dc8f44f5b@default>
Date: Tue, 17 Apr 2012 14:30:20 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Brian Szymanski <skibrianski@gmail.com>, xen-devel@lists.xensource.com
References: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
	<CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
	<jjj8bj$r19$1@dough.gmane.org>
	<20120315183330.GB3034@phenom.dumpdata.com>
	<4F623AD5.3020400@citrix.com> <4F624C02.3000004@gmail.com>
	<4F6713EC.7070804@citrix.com> <4F6725C9.9000304@gmail.com>
	<1332160201177-5576960.post@n5.nabble.com>
	<1334637194009-5645610.post@n5.nabble.com>
	<1334637995004-5645620.post@n5.nabble.com>
In-Reply-To: <1334637995004-5645620.post@n5.nabble.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F8DE0F7.0067,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Brian Szymanski [mailto:skibrianski@gmail.com]
> Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
> 
> Also, if I xm mem-set Domain-0 6144, xm list is updated to the new value, but
> xm top continues to show the old (even after restarting it).

This is a very old annoying bug in xm.  It is especially
noticeable when a tmem-savvy guest (with selfballooning)
is enabled.  With xm now deprecated, it may never get fixed.

I'm told it is fixed with "xl".  If not, please report it.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 17 21:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Apr 2012 21:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKFyv-0002Oz-O2; Tue, 17 Apr 2012 21:30:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SKFyt-0002Ou-Vi
	for xen-devel@lists.xensource.com; Tue, 17 Apr 2012 21:30:36 +0000
Received: from [85.158.138.51:23835] by server-9.bemta-3.messagelabs.com id
	97/85-26691-BF0ED8F4; Tue, 17 Apr 2012 21:30:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334698232!18395137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NTkzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15122 invoked from network); 17 Apr 2012 21:30:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Apr 2012 21:30:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3HLUUuK013939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Apr 2012 21:30:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3HLUTbg010018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2012 21:30:30 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3HLUTtR009448; Tue, 17 Apr 2012 16:30:29 -0500
MIME-Version: 1.0
Message-ID: <57a8bc29-6075-49fb-a2fc-190dc8f44f5b@default>
Date: Tue, 17 Apr 2012 14:30:20 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Brian Szymanski <skibrianski@gmail.com>, xen-devel@lists.xensource.com
References: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
	<CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
	<jjj8bj$r19$1@dough.gmane.org>
	<20120315183330.GB3034@phenom.dumpdata.com>
	<4F623AD5.3020400@citrix.com> <4F624C02.3000004@gmail.com>
	<4F6713EC.7070804@citrix.com> <4F6725C9.9000304@gmail.com>
	<1332160201177-5576960.post@n5.nabble.com>
	<1334637194009-5645610.post@n5.nabble.com>
	<1334637995004-5645620.post@n5.nabble.com>
In-Reply-To: <1334637995004-5645620.post@n5.nabble.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F8DE0F7.0067,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Brian Szymanski [mailto:skibrianski@gmail.com]
> Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
> 
> Also, if I xm mem-set Domain-0 6144, xm list is updated to the new value, but
> xm top continues to show the old (even after restarting it).

This is a very old annoying bug in xm.  It is especially
noticeable when a tmem-savvy guest (with selfballooning)
is enabled.  With xm now deprecated, it may never get fixed.

I'm told it is fixed with "xl".  If not, please report it.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 00:24:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 00:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKIgq-0004g2-PR; Wed, 18 Apr 2012 00:24:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKIgo-0004fx-DR
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 00:24:06 +0000
Received: from [85.158.138.51:65123] by server-9.bemta-3.messagelabs.com id
	9E/41-26691-5A90E8F4; Wed, 18 Apr 2012 00:24:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334708644!22610301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 18 Apr 2012 00:24:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 00:24:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="11989577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 00:24:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 01:24:03 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKIgl-000114-4F;
	Wed, 18 Apr 2012 00:24:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKIgk-000377-U4;
	Wed, 18 Apr 2012 01:24:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12707-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 01:24:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12707: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12707 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12707/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 12566
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12566

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass

version targeted for testing:
 xen                  4e446ac2c6de
baseline version:
 xen                  cbe8948799bf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=4e446ac2c6de
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing 4e446ac2c6de
+ branch=xen-4.0-testing
+ revision=4e446ac2c6de
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 4e446ac2c6de ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 5 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 00:24:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 00:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKIgq-0004g2-PR; Wed, 18 Apr 2012 00:24:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKIgo-0004fx-DR
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 00:24:06 +0000
Received: from [85.158.138.51:65123] by server-9.bemta-3.messagelabs.com id
	9E/41-26691-5A90E8F4; Wed, 18 Apr 2012 00:24:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334708644!22610301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 18 Apr 2012 00:24:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 00:24:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="11989577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 00:24:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 01:24:03 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKIgl-000114-4F;
	Wed, 18 Apr 2012 00:24:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKIgk-000377-U4;
	Wed, 18 Apr 2012 01:24:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12707-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 01:24:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12707: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12707 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12707/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 12566
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12566

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass

version targeted for testing:
 xen                  4e446ac2c6de
baseline version:
 xen                  cbe8948799bf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=4e446ac2c6de
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing 4e446ac2c6de
+ branch=xen-4.0-testing
+ revision=4e446ac2c6de
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 4e446ac2c6de ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 5 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 00:53:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 00:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJ8Z-0004wc-D9; Wed, 18 Apr 2012 00:52:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SKJ8Y-0004w1-1n
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 00:52:46 +0000
Received: from [85.158.143.99:58493] by server-3.bemta-4.messagelabs.com id
	DB/D0-05853-D501E8F4; Wed, 18 Apr 2012 00:52:45 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334710363!12891886!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY1OTAz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28483 invoked from network); 18 Apr 2012 00:52:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-16.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 00:52:44 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 17 Apr 2012 17:52:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="90268808"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 17:52:42 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 17:52:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Wed, 18 Apr 2012 08:52:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsA=
Date: Wed, 18 Apr 2012 00:52:39 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D9CDC@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0D84A1@SHSMSX101.ccr.corp.intel.com>
	<CBB2D9E9.3DE0F%keir@xen.org>
In-Reply-To: <CBB2D9E9.3DE0F%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> 
> > Hi keir
> >
> > I noticed that the changeset 15289 introuduced locking to platform
> > timers. And you mentioned that it only handy for correctness. Are
> > there some potential issues which is fixed by this patch? If not, I wonder why
> we need those locks?
> 
> Yes, issues were fixed by the patch. That's why I bothered to implement it.
> However I think the observed issues were with protecting the mechanisms in
> vpt.c, and the other locking at least partially may be overly cautious.
> 
> > I think it should be OS's responsibly to guarantee the access
> > sequentially, not hypervisor. Am I right?
> 
> It depends. Where an access is an apparently-atomic memory-mapped access,
> but implemented as a sequence of operations in the hypervisor, the hypervisor
> might need to maintain atomicity through locking.

But if there already has lock inside guest for those access, and there have no other code patch(like timer callback function) in hypervisor to access the shared data, then we don't need to use lock in hypersivor.

> > I don't know whether all those locks are necessary, but at least the
> > lock for vhpet, especially the reading lock, is not required.
> 
> This is definitely not true, for example locking is required around calls to
> create_periodic_time(), to serialise them. So in general the locking I added,
> even in vhpet.c is required. If you have a specific hot path you are looking to
> optimise, and especially if you have numbers to back that up, then we can
> consider specific localised optimisations to avoid locking where we can reason
> it is not needed.
As I mentioned, if the guest can ensure there only one CPU to access the hpet at same time, this means the access itself already is serialized. 
Yes.Win8 is booting very slowly w/ more than 16 VCPUs. And this is due to the big lock in reading hpet. Also, the xentrace data shows lots of vmexit which mainly from PAUSE instruction from other cpus. So I think if guest already uses lock to protect the hpet access, why hypervisor do the same thing too?

yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 00:53:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 00:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJ8Z-0004wc-D9; Wed, 18 Apr 2012 00:52:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SKJ8Y-0004w1-1n
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 00:52:46 +0000
Received: from [85.158.143.99:58493] by server-3.bemta-4.messagelabs.com id
	DB/D0-05853-D501E8F4; Wed, 18 Apr 2012 00:52:45 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334710363!12891886!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY1OTAz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28483 invoked from network); 18 Apr 2012 00:52:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-16.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 00:52:44 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 17 Apr 2012 17:52:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="90268808"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Apr 2012 17:52:42 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Apr 2012 17:52:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Wed, 18 Apr 2012 08:52:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsA=
Date: Wed, 18 Apr 2012 00:52:39 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0D9CDC@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0D84A1@SHSMSX101.ccr.corp.intel.com>
	<CBB2D9E9.3DE0F%keir@xen.org>
In-Reply-To: <CBB2D9E9.3DE0F%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> 
> > Hi keir
> >
> > I noticed that the changeset 15289 introuduced locking to platform
> > timers. And you mentioned that it only handy for correctness. Are
> > there some potential issues which is fixed by this patch? If not, I wonder why
> we need those locks?
> 
> Yes, issues were fixed by the patch. That's why I bothered to implement it.
> However I think the observed issues were with protecting the mechanisms in
> vpt.c, and the other locking at least partially may be overly cautious.
> 
> > I think it should be OS's responsibly to guarantee the access
> > sequentially, not hypervisor. Am I right?
> 
> It depends. Where an access is an apparently-atomic memory-mapped access,
> but implemented as a sequence of operations in the hypervisor, the hypervisor
> might need to maintain atomicity through locking.

But if there already has lock inside guest for those access, and there have no other code patch(like timer callback function) in hypervisor to access the shared data, then we don't need to use lock in hypersivor.

> > I don't know whether all those locks are necessary, but at least the
> > lock for vhpet, especially the reading lock, is not required.
> 
> This is definitely not true, for example locking is required around calls to
> create_periodic_time(), to serialise them. So in general the locking I added,
> even in vhpet.c is required. If you have a specific hot path you are looking to
> optimise, and especially if you have numbers to back that up, then we can
> consider specific localised optimisations to avoid locking where we can reason
> it is not needed.
As I mentioned, if the guest can ensure there only one CPU to access the hpet at same time, this means the access itself already is serialized. 
Yes.Win8 is booting very slowly w/ more than 16 VCPUs. And this is due to the big lock in reading hpet. Also, the xentrace data shows lots of vmexit which mainly from PAUSE instruction from other cpus. So I think if guest already uses lock to protect the hpet access, why hypervisor do the same thing too?

yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 00:54:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 00:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJ9v-00053L-QB; Wed, 18 Apr 2012 00:54:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKJ9u-00053A-A9
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 00:54:10 +0000
Received: from [85.158.138.51:42461] by server-3.bemta-3.messagelabs.com id
	6C/70-04048-1B01E8F4; Wed, 18 Apr 2012 00:54:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334710448!22509794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1030 invoked from network); 18 Apr 2012 00:54:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 00:54:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="11989655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 00:54:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 01:54:07 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKJ9r-0001J8-AJ;
	Wed, 18 Apr 2012 00:54:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKJ9r-00028j-3r;
	Wed, 18 Apr 2012 01:54:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12708-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 01:54:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12708: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12708 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12708/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12670

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  494aa5ecd2e1
baseline version:
 xen                  4ad262a48a71

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=494aa5ecd2e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 494aa5ecd2e1
+ branch=xen-4.1-testing
+ revision=494aa5ecd2e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 494aa5ecd2e1 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 7 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 00:54:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 00:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJ9v-00053L-QB; Wed, 18 Apr 2012 00:54:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKJ9u-00053A-A9
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 00:54:10 +0000
Received: from [85.158.138.51:42461] by server-3.bemta-3.messagelabs.com id
	6C/70-04048-1B01E8F4; Wed, 18 Apr 2012 00:54:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1334710448!22509794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1030 invoked from network); 18 Apr 2012 00:54:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 00:54:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="11989655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 00:54:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 01:54:07 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKJ9r-0001J8-AJ;
	Wed, 18 Apr 2012 00:54:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKJ9r-00028j-3r;
	Wed, 18 Apr 2012 01:54:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12708-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 01:54:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12708: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12708 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12708/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12670

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  494aa5ecd2e1
baseline version:
 xen                  4ad262a48a71

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=494aa5ecd2e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 494aa5ecd2e1
+ branch=xen-4.1-testing
+ revision=494aa5ecd2e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 494aa5ecd2e1 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 7 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 01:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 01:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJOP-0001E3-57; Wed, 18 Apr 2012 01:09:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SKJOO-0001Dx-2j
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 01:09:08 +0000
Received: from [193.109.254.147:49685] by server-12.bemta-14.messagelabs.com
	id 7A/39-05898-3341E8F4; Wed, 18 Apr 2012 01:09:07 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334711346!5046934!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 385 invoked from network); 18 Apr 2012 01:09:06 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 01:09:06 -0000
Received: by lbon10 with SMTP id n10so4255456lbo.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 18:09:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type; bh=/GzY9jMv9hnbJlqzj8SQ/MZf/NxQINjYZdjmJngqXgo=;
	b=jiCfqtGZp4vkKQTghHukA4c9pJ1l8FsKjuUz7Lg9Jo4tjP7Ry2/LdN2HIqc/Ll+Cab
	ZDAs0rsRBE59Ae+Hhz7c+HRak7YSvGnE5hRKnEgOJV4gzoQ4zS+BNkzvdqEHzZq19mpr
	Bl2el2q60GWg9C3fKzaYvsQ3OFo8DnfbB3X8o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type:x-gm-message-state;
	bh=/GzY9jMv9hnbJlqzj8SQ/MZf/NxQINjYZdjmJngqXgo=;
	b=NafW/1WVnfAR2PWo9hjJX+as9H2AouzRvAwrEIV7phsc+ySpKD/TqTMKcHCfm8o4pE
	07G6xKliHfuFtCNylahpDwir+m9m02YJwsHK4RunYDw3nq5rGkZOIN0zCgMdDVe7Y43y
	46nKQdsIsqYBcl3Ww45hxl4viV5fw3YhD9KIA09x7lv6cS8JJKVB5KMyiBYza6PNAjRN
	1HugZlZLGfmg49uMFSRDfdS90BGY+3ywxoD4KFF8loivhFHp9yE6hzCrSklcf1Ne/QJA
	Ulg1ENIMcwjCUKEpuz0IlPsWKDMio9e7ipTVhJmY1O2cdY4R+f7lB9I0YaU84l/mJV90
	j17g==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr148348lbm.31.1334711346026; Tue,
	17 Apr 2012 18:09:06 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 17 Apr 2012 18:09:06 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
Date: Tue, 17 Apr 2012 18:09:06 -0700
Message-ID: <CAB10MZA-64tOohf5_1-8LJ52E3dUC0xOYSUPRgUgeqC3mOBhKQ@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQlVFzBK2fi4973KavZfq3NhLfpIGl+ZHQ4aV7LtU8sgXMBJZqN9BoAaOLrAFQRe5FSp44iC
Subject: [Xen-devel] [PATCH] mem_access: fix setting default mem_access type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0)
is called, first_pfn=~0ull is a hint to HVMOP_set_mem_access as to
what the default mem_access type is for the domain. This call was
failing because it was gated by the memory range check in the
HVMOP_set_mem_access case statement in do_hvm_op(). The following
patch fixes this issue.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

---
 xen/arch/x86/hvm/hvm.c |  5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff -r a06e6cdeafe3 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Mon Apr 16 13:05:28 2012 +0200
+++ b/xen/arch/x86/hvm/hvm.c	Tue Apr 17 18:03:37 2012 -0700
@@ -4170,9 +4170,10 @@
             goto param_fail5;

         rc = -EINVAL;
-        if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
+        if ( (a.first_pfn != ~0ull) &&
+             ((a.first_pfn > domain_get_maximum_gpfn(d)) ||
              ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
-             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
+             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d))) )
             goto param_fail5;

         rc = p2m_set_mem_access(d, a.first_pfn, a.nr, a.hvmmem_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 01:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 01:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJOP-0001E3-57; Wed, 18 Apr 2012 01:09:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SKJOO-0001Dx-2j
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 01:09:08 +0000
Received: from [193.109.254.147:49685] by server-12.bemta-14.messagelabs.com
	id 7A/39-05898-3341E8F4; Wed, 18 Apr 2012 01:09:07 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334711346!5046934!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 385 invoked from network); 18 Apr 2012 01:09:06 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 01:09:06 -0000
Received: by lbon10 with SMTP id n10so4255456lbo.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 18:09:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type; bh=/GzY9jMv9hnbJlqzj8SQ/MZf/NxQINjYZdjmJngqXgo=;
	b=jiCfqtGZp4vkKQTghHukA4c9pJ1l8FsKjuUz7Lg9Jo4tjP7Ry2/LdN2HIqc/Ll+Cab
	ZDAs0rsRBE59Ae+Hhz7c+HRak7YSvGnE5hRKnEgOJV4gzoQ4zS+BNkzvdqEHzZq19mpr
	Bl2el2q60GWg9C3fKzaYvsQ3OFo8DnfbB3X8o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type:x-gm-message-state;
	bh=/GzY9jMv9hnbJlqzj8SQ/MZf/NxQINjYZdjmJngqXgo=;
	b=NafW/1WVnfAR2PWo9hjJX+as9H2AouzRvAwrEIV7phsc+ySpKD/TqTMKcHCfm8o4pE
	07G6xKliHfuFtCNylahpDwir+m9m02YJwsHK4RunYDw3nq5rGkZOIN0zCgMdDVe7Y43y
	46nKQdsIsqYBcl3Ww45hxl4viV5fw3YhD9KIA09x7lv6cS8JJKVB5KMyiBYza6PNAjRN
	1HugZlZLGfmg49uMFSRDfdS90BGY+3ywxoD4KFF8loivhFHp9yE6hzCrSklcf1Ne/QJA
	Ulg1ENIMcwjCUKEpuz0IlPsWKDMio9e7ipTVhJmY1O2cdY4R+f7lB9I0YaU84l/mJV90
	j17g==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr148348lbm.31.1334711346026; Tue,
	17 Apr 2012 18:09:06 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 17 Apr 2012 18:09:06 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
Date: Tue, 17 Apr 2012 18:09:06 -0700
Message-ID: <CAB10MZA-64tOohf5_1-8LJ52E3dUC0xOYSUPRgUgeqC3mOBhKQ@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQlVFzBK2fi4973KavZfq3NhLfpIGl+ZHQ4aV7LtU8sgXMBJZqN9BoAaOLrAFQRe5FSp44iC
Subject: [Xen-devel] [PATCH] mem_access: fix setting default mem_access type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0)
is called, first_pfn=~0ull is a hint to HVMOP_set_mem_access as to
what the default mem_access type is for the domain. This call was
failing because it was gated by the memory range check in the
HVMOP_set_mem_access case statement in do_hvm_op(). The following
patch fixes this issue.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

---
 xen/arch/x86/hvm/hvm.c |  5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff -r a06e6cdeafe3 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Mon Apr 16 13:05:28 2012 +0200
+++ b/xen/arch/x86/hvm/hvm.c	Tue Apr 17 18:03:37 2012 -0700
@@ -4170,9 +4170,10 @@
             goto param_fail5;

         rc = -EINVAL;
-        if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
+        if ( (a.first_pfn != ~0ull) &&
+             ((a.first_pfn > domain_get_maximum_gpfn(d)) ||
              ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
-             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
+             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d))) )
             goto param_fail5;

         rc = p2m_set_mem_access(d, a.first_pfn, a.nr, a.hvmmem_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 01:21:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 01:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJaD-0001fR-KM; Wed, 18 Apr 2012 01:21:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SKJaB-0001fM-Kv
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 01:21:19 +0000
Received: from [85.158.139.83:44309] by server-1.bemta-5.messagelabs.com id
	08/B0-28458-E071E8F4; Wed, 18 Apr 2012 01:21:18 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334712076!20332101!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc1NjQ3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13936 invoked from network); 18 Apr 2012 01:21:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Apr 2012 01:21:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3I1LAtr032558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Apr 2012 01:21:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3I1L9SB003546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Apr 2012 01:21:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3I1L9tX017734; Tue, 17 Apr 2012 20:21:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 18:21:08 -0700
Date: Tue, 17 Apr 2012 18:20:09 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120417182009.14219141@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090205.4F8E1707.0088,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012 17:22:14 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 16 Apr 2012, Ian Campbell wrote:
> > > In a nutshell, I am still trying to figure how to allocate rsvd
> > > pfn's for privcmd without writing a slab allocator.
> > 
> > Can't you just use the core get_page function (or
> > alloc_xenballooned_pages) and move the associated mfn aside
> > temporarily (or not if using alloc_xenballooned_pages)?
> 
> I think that is a good suggestion: if we are trying to get in
> something that works but might not be the best solution, then using
> alloc_xenballooned_pages to get some pages and then changing the p2m
> is the best option: it wastes a non-trivial amount of memory in dom0
> but at least it is known to work well and it wouldn't be an "hack".
> 
> Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
> for an example.


Ok. I changed to using alloc_xenballooned_pages. In future, if we run
into problems, we can look into alternatives. In past we've had
problems with limits reached ballooing down. We run with small dom0.

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 01:21:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 01:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKJaD-0001fR-KM; Wed, 18 Apr 2012 01:21:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SKJaB-0001fM-Kv
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 01:21:19 +0000
Received: from [85.158.139.83:44309] by server-1.bemta-5.messagelabs.com id
	08/B0-28458-E071E8F4; Wed, 18 Apr 2012 01:21:18 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334712076!20332101!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc1NjQ3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13936 invoked from network); 18 Apr 2012 01:21:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Apr 2012 01:21:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3I1LAtr032558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Apr 2012 01:21:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3I1L9SB003546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Apr 2012 01:21:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3I1L9tX017734; Tue, 17 Apr 2012 20:21:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Apr 2012 18:21:08 -0700
Date: Tue, 17 Apr 2012 18:20:09 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120417182009.14219141@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090205.4F8E1707.0088,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 16 Apr 2012 17:22:14 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 16 Apr 2012, Ian Campbell wrote:
> > > In a nutshell, I am still trying to figure how to allocate rsvd
> > > pfn's for privcmd without writing a slab allocator.
> > 
> > Can't you just use the core get_page function (or
> > alloc_xenballooned_pages) and move the associated mfn aside
> > temporarily (or not if using alloc_xenballooned_pages)?
> 
> I think that is a good suggestion: if we are trying to get in
> something that works but might not be the best solution, then using
> alloc_xenballooned_pages to get some pages and then changing the p2m
> is the best option: it wastes a non-trivial amount of memory in dom0
> but at least it is known to work well and it wouldn't be an "hack".
> 
> Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
> for an example.


Ok. I changed to using alloc_xenballooned_pages. In future, if we run
into problems, we can look into alternatives. In past we've had
problems with limits reached ballooing down. We run with small dom0.

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 03:45:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 03:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKLof-00030X-FK; Wed, 18 Apr 2012 03:44:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKLoe-00030F-Lw
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 03:44:24 +0000
Received: from [85.158.143.99:31356] by server-2.bemta-4.messagelabs.com id
	FD/5C-17550-7983E8F4; Wed, 18 Apr 2012 03:44:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334720662!23561061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31289 invoked from network); 18 Apr 2012 03:44:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 03:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="11990142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 03:44:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 04:44:22 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKLob-0002HY-Dj;
	Wed, 18 Apr 2012 03:44:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKLob-0000tx-AF;
	Wed, 18 Apr 2012 04:44:21 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12709-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 04:44:21 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12709: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12709 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12709/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12702

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6017afc70442
baseline version:
 xen                  a06e6cdeafe3

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=6017afc70442
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 6017afc70442
+ branch=xen-unstable
+ revision=6017afc70442
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6017afc70442 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 9 changes to 9 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 03:45:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 03:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKLof-00030X-FK; Wed, 18 Apr 2012 03:44:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKLoe-00030F-Lw
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 03:44:24 +0000
Received: from [85.158.143.99:31356] by server-2.bemta-4.messagelabs.com id
	FD/5C-17550-7983E8F4; Wed, 18 Apr 2012 03:44:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334720662!23561061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31289 invoked from network); 18 Apr 2012 03:44:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 03:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="11990142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 03:44:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 04:44:22 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKLob-0002HY-Dj;
	Wed, 18 Apr 2012 03:44:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKLob-0000tx-AF;
	Wed, 18 Apr 2012 04:44:21 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12709-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 04:44:21 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12709: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12709 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12709/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12702

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6017afc70442
baseline version:
 xen                  a06e6cdeafe3

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=6017afc70442
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 6017afc70442
+ branch=xen-unstable
+ revision=6017afc70442
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6017afc70442 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 9 changes to 9 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 05:12:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 05:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKNAw-0003wO-B0; Wed, 18 Apr 2012 05:11:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyclonusj@gmail.com>) id 1SKNAu-0003wJ-Vg
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 05:11:29 +0000
Received: from [85.158.139.83:17902] by server-12.bemta-5.messagelabs.com id
	2F/8C-05587-00D4E8F4; Wed, 18 Apr 2012 05:11:28 +0000
X-Env-Sender: cyclonusj@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334725886!20416071!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32164 invoked from network); 18 Apr 2012 05:11:27 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 05:11:27 -0000
Received: by obbtb18 with SMTP id tb18so5603437obb.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 22:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=YODzsfLgKpPywqP0GLDxMj0h4XeSJ5ZXz5jliZkfjCg=;
	b=kY77UZp9xyo/VrMg45wRHvOWo8AWUmMhUH+YNYuyEdHWdCRkf0ZISSQ20rlix7BL8z
	Tat+bZVVKaMS8b1W/De3c+9CQCjlQJ+pk6ZKeCN9Dg40fSW6rCaoo7KCHXNZAHRzunDU
	UCZMT78io2GQt00/1WbUUNYqBEIJtfsViCDq9289wXwE9mVJF2KXAoyrhK/gUXHXNHYe
	6wHva9ew49jnSHwJX0UGte4i5LGC+hMc4nJNDo32ud6JRdVx2oua/Y5vpddLm4tKaPNH
	+ylKxepippzougRolo9/u+q+mHrwJw9oHE1OnJD/T7AAAT6TpaS4ivMTqfejk6bV2kuv
	Yp2A==
MIME-Version: 1.0
Received: by 10.182.222.2 with SMTP id qi2mr1022072obc.27.1334725885726; Tue,
	17 Apr 2012 22:11:25 -0700 (PDT)
Received: by 10.182.157.15 with HTTP; Tue, 17 Apr 2012 22:11:25 -0700 (PDT)
Date: Tue, 17 Apr 2012 22:11:25 -0700
Message-ID: <CAOzbF4e1ruBgU-X2u3S-nTnGyq77FRNn65wPopJ_LLWtXoJ_eg@mail.gmail.com>
From: Cyclonus J <cyclonusj@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] map given mfn or domU gpfn list into dom0 kernel space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hi,

Is it possible to map a given list of DomU gpfn into Dom0 kernel
virtual space? Currently, I get Xen translated the gpfn of the DomU to
its mfn, but the problem is that I can't use this translated mfn for
dom0 vmap function call since it will always assume the input are pfn
instead of mfn because XENFEAT_auto_translated_physmap is not enabled
on Dom0.

Any suggestions?

Thanks,
CJ

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 05:12:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 05:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKNAw-0003wO-B0; Wed, 18 Apr 2012 05:11:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyclonusj@gmail.com>) id 1SKNAu-0003wJ-Vg
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 05:11:29 +0000
Received: from [85.158.139.83:17902] by server-12.bemta-5.messagelabs.com id
	2F/8C-05587-00D4E8F4; Wed, 18 Apr 2012 05:11:28 +0000
X-Env-Sender: cyclonusj@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334725886!20416071!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32164 invoked from network); 18 Apr 2012 05:11:27 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 05:11:27 -0000
Received: by obbtb18 with SMTP id tb18so5603437obb.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 17 Apr 2012 22:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=YODzsfLgKpPywqP0GLDxMj0h4XeSJ5ZXz5jliZkfjCg=;
	b=kY77UZp9xyo/VrMg45wRHvOWo8AWUmMhUH+YNYuyEdHWdCRkf0ZISSQ20rlix7BL8z
	Tat+bZVVKaMS8b1W/De3c+9CQCjlQJ+pk6ZKeCN9Dg40fSW6rCaoo7KCHXNZAHRzunDU
	UCZMT78io2GQt00/1WbUUNYqBEIJtfsViCDq9289wXwE9mVJF2KXAoyrhK/gUXHXNHYe
	6wHva9ew49jnSHwJX0UGte4i5LGC+hMc4nJNDo32ud6JRdVx2oua/Y5vpddLm4tKaPNH
	+ylKxepippzougRolo9/u+q+mHrwJw9oHE1OnJD/T7AAAT6TpaS4ivMTqfejk6bV2kuv
	Yp2A==
MIME-Version: 1.0
Received: by 10.182.222.2 with SMTP id qi2mr1022072obc.27.1334725885726; Tue,
	17 Apr 2012 22:11:25 -0700 (PDT)
Received: by 10.182.157.15 with HTTP; Tue, 17 Apr 2012 22:11:25 -0700 (PDT)
Date: Tue, 17 Apr 2012 22:11:25 -0700
Message-ID: <CAOzbF4e1ruBgU-X2u3S-nTnGyq77FRNn65wPopJ_LLWtXoJ_eg@mail.gmail.com>
From: Cyclonus J <cyclonusj@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] map given mfn or domU gpfn list into dom0 kernel space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hi,

Is it possible to map a given list of DomU gpfn into Dom0 kernel
virtual space? Currently, I get Xen translated the gpfn of the DomU to
its mfn, but the problem is that I can't use this translated mfn for
dom0 vmap function call since it will always assume the input are pfn
instead of mfn because XENFEAT_auto_translated_physmap is not enabled
on Dom0.

Any suggestions?

Thanks,
CJ

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 06:05:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 06:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKO0c-0004LT-L7; Wed, 18 Apr 2012 06:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKO0b-0004LO-Sj
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 06:04:54 +0000
Received: from [85.158.139.83:6920] by server-12.bemta-5.messagelabs.com id
	07/27-05587-4895E8F4; Wed, 18 Apr 2012 06:04:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334729091!21586544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10414 invoked from network); 18 Apr 2012 06:04:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 06:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,440,1330905600"; d="scan'208";a="11991690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 06:04:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 07:04:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKO0Z-0003Wa-0o;
	Wed, 18 Apr 2012 06:04:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKO0Y-0002lt-QV;
	Wed, 18 Apr 2012 07:04:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12710-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 07:04:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12710: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12710 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12710/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12669

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-qemuu-win      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-win   1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a

version targeted for testing:
 qemuu                ddb2abf7754fa2f968d4a4a57ff07d345e3c1e37
baseline version:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     blocked 
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  blocked 
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 06:05:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 06:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKO0c-0004LT-L7; Wed, 18 Apr 2012 06:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKO0b-0004LO-Sj
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 06:04:54 +0000
Received: from [85.158.139.83:6920] by server-12.bemta-5.messagelabs.com id
	07/27-05587-4895E8F4; Wed, 18 Apr 2012 06:04:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334729091!21586544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10414 invoked from network); 18 Apr 2012 06:04:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 06:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,440,1330905600"; d="scan'208";a="11991690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 06:04:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 07:04:51 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKO0Z-0003Wa-0o;
	Wed, 18 Apr 2012 06:04:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKO0Y-0002lt-QV;
	Wed, 18 Apr 2012 07:04:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12710-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 07:04:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12710: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12710 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12710/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12669

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win  7 windows-install              fail  never pass
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-qemuu-win      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-i386-i386-xl-qemuu-win   1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a

version targeted for testing:
 qemuu                ddb2abf7754fa2f968d4a4a57ff07d345e3c1e37
baseline version:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     blocked 
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  blocked 
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 07:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 07:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKP55-00057f-R8; Wed, 18 Apr 2012 07:13:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKP53-00057a-Fj
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 07:13:33 +0000
Received: from [85.158.143.35:27769] by server-1.bemta-4.messagelabs.com id
	C6/02-20925-C996E8F4; Wed, 18 Apr 2012 07:13:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334733211!5435882!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12119 invoked from network); 18 Apr 2012 07:13:31 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 07:13:31 -0000
Received: by wgbdr12 with SMTP id dr12so5946627wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 00:13:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=59RjHgEU4srerSBmNrSO0jHhRX6Wpn5NNyyfo0JCrRY=;
	b=hHGH7srb3WcJ9x7rUIhCnV0fuwTUp/8ZfmKvmf9eRExMPJ3/FMtr/6YjbcU3VvEpMG
	KG4Dirhsww7Yd7UG7Zu991A/fg+91zK1eGF4s2WA6aF9p0TPEu/ckTwqb3efoXtEZB1T
	62oEWxMOyOX7dgakFcC/DDKLXw9/Z48jWn4DaLBU22An3zaWJujSO4YJAcmIt3pXw56O
	sUuApt6KeQ0OHB0eJqCsWckdoX4Q8HPixHht7SRK8QL/ra2R8608fK2SOOEUmDvmQgRf
	S90244shQ8Oc5FLrCqzvO335f89WOqV/1wTXQ4X8XL8UZIKV2toZQxzqfHj+A0B6VKDH
	MdTw==
Received: by 10.180.90.102 with SMTP id bv6mr14054421wib.6.1334733210790;
	Wed, 18 Apr 2012 00:13:30 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id gd4sm52310377wib.6.2012.04.18.00.13.29
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 00:13:30 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 08:13:27 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB42827.30EE3%keir.xen@gmail.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9Q==
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0D9CDC@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/2012 01:52, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

>> It depends. Where an access is an apparently-atomic memory-mapped access,
>> but implemented as a sequence of operations in the hypervisor, the hypervisor
>> might need to maintain atomicity through locking.
> 
> But if there already has lock inside guest for those access, and there have no
> other code patch(like timer callback function) in hypervisor to access the
> shared data, then we don't need to use lock in hypersivor.

If there is a memory-mapped register access which is atomic on bare metal,
the guest may not bother with locking. We have to maintain that apparent
atomicity ourselves by implementing serialisation in the hypervisor.

>>> I don't know whether all those locks are necessary, but at least the
>>> lock for vhpet, especially the reading lock, is not required.
>> 
>> This is definitely not true, for example locking is required around calls to
>> create_periodic_time(), to serialise them. So in general the locking I added,
>> even in vhpet.c is required. If you have a specific hot path you are looking
>> to
>> optimise, and especially if you have numbers to back that up, then we can
>> consider specific localised optimisations to avoid locking where we can
>> reason
>> it is not needed.
> As I mentioned, if the guest can ensure there only one CPU to access the hpet
> at same time, this means the access itself already is serialized.
> Yes.Win8 is booting very slowly w/ more than 16 VCPUs. And this is due to the
> big lock in reading hpet. Also, the xentrace data shows lots of vmexit which
> mainly from PAUSE instruction from other cpus. So I think if guest already
> uses lock to protect the hpet access, why hypervisor do the same thing too?

If the HPET accesses are atomic on bare metal, we have to maintain that,
even if some guests have extra locking themselves. Also, in some cases Xen
needs locking to correctly maintain its own internal state regardless of
what an (untrusted) guest might do. So we cannot just get rid of the vhpet
lock everywhere. It's definitely not correct to do so. Optimising the hpet
read path however, sounds okay. I agree the lock may not be needed on that
specific path.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 07:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 07:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKP55-00057f-R8; Wed, 18 Apr 2012 07:13:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKP53-00057a-Fj
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 07:13:33 +0000
Received: from [85.158.143.35:27769] by server-1.bemta-4.messagelabs.com id
	C6/02-20925-C996E8F4; Wed, 18 Apr 2012 07:13:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1334733211!5435882!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12119 invoked from network); 18 Apr 2012 07:13:31 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 07:13:31 -0000
Received: by wgbdr12 with SMTP id dr12so5946627wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 00:13:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=59RjHgEU4srerSBmNrSO0jHhRX6Wpn5NNyyfo0JCrRY=;
	b=hHGH7srb3WcJ9x7rUIhCnV0fuwTUp/8ZfmKvmf9eRExMPJ3/FMtr/6YjbcU3VvEpMG
	KG4Dirhsww7Yd7UG7Zu991A/fg+91zK1eGF4s2WA6aF9p0TPEu/ckTwqb3efoXtEZB1T
	62oEWxMOyOX7dgakFcC/DDKLXw9/Z48jWn4DaLBU22An3zaWJujSO4YJAcmIt3pXw56O
	sUuApt6KeQ0OHB0eJqCsWckdoX4Q8HPixHht7SRK8QL/ra2R8608fK2SOOEUmDvmQgRf
	S90244shQ8Oc5FLrCqzvO335f89WOqV/1wTXQ4X8XL8UZIKV2toZQxzqfHj+A0B6VKDH
	MdTw==
Received: by 10.180.90.102 with SMTP id bv6mr14054421wib.6.1334733210790;
	Wed, 18 Apr 2012 00:13:30 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-183.range81-152.btcentralplus.com.
	[81.152.17.183])
	by mx.google.com with ESMTPS id gd4sm52310377wib.6.2012.04.18.00.13.29
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 00:13:30 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 08:13:27 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB42827.30EE3%keir.xen@gmail.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9Q==
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0D9CDC@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/2012 01:52, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

>> It depends. Where an access is an apparently-atomic memory-mapped access,
>> but implemented as a sequence of operations in the hypervisor, the hypervisor
>> might need to maintain atomicity through locking.
> 
> But if there already has lock inside guest for those access, and there have no
> other code patch(like timer callback function) in hypervisor to access the
> shared data, then we don't need to use lock in hypersivor.

If there is a memory-mapped register access which is atomic on bare metal,
the guest may not bother with locking. We have to maintain that apparent
atomicity ourselves by implementing serialisation in the hypervisor.

>>> I don't know whether all those locks are necessary, but at least the
>>> lock for vhpet, especially the reading lock, is not required.
>> 
>> This is definitely not true, for example locking is required around calls to
>> create_periodic_time(), to serialise them. So in general the locking I added,
>> even in vhpet.c is required. If you have a specific hot path you are looking
>> to
>> optimise, and especially if you have numbers to back that up, then we can
>> consider specific localised optimisations to avoid locking where we can
>> reason
>> it is not needed.
> As I mentioned, if the guest can ensure there only one CPU to access the hpet
> at same time, this means the access itself already is serialized.
> Yes.Win8 is booting very slowly w/ more than 16 VCPUs. And this is due to the
> big lock in reading hpet. Also, the xentrace data shows lots of vmexit which
> mainly from PAUSE instruction from other cpus. So I think if guest already
> uses lock to protect the hpet access, why hypervisor do the same thing too?

If the HPET accesses are atomic on bare metal, we have to maintain that,
even if some guests have extra locking themselves. Also, in some cases Xen
needs locking to correctly maintain its own internal state regardless of
what an (untrusted) guest might do. So we cannot just get rid of the vhpet
lock everywhere. It's definitely not correct to do so. Optimising the hpet
read path however, sounds okay. I agree the lock may not be needed on that
specific path.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 07:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 07:55:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKPjJ-0005R1-8W; Wed, 18 Apr 2012 07:55:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SKPjI-0005Qw-75
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 07:55:08 +0000
Received: from [85.158.143.99:53971] by server-3.bemta-4.messagelabs.com id
	1F/7D-05853-B537E8F4; Wed, 18 Apr 2012 07:55:07 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334735705!23802446!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1MjE5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11162 invoked from network); 18 Apr 2012 07:55:06 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 07:55:06 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 18 Apr 2012 00:55:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="132277044"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 18 Apr 2012 00:55:04 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 18 Apr 2012 00:55:04 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Wed, 18 Apr 2012 15:55:02 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKeg
Date: Wed, 18 Apr 2012 07:55:01 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0DA169@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0D9CDC@SHSMSX101.ccr.corp.intel.com>
	<CBB42827.30EE3%keir.xen@gmail.com>
In-Reply-To: <CBB42827.30EE3%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Wednesday, April 18, 2012 3:13 PM
> To: Zhang, Yang Z; xen-devel@lists.xensource.com
> Subject: Re: lock in vhpet
> 
> On 18/04/2012 01:52, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> 
> >> It depends. Where an access is an apparently-atomic memory-mapped
> >> access, but implemented as a sequence of operations in the
> >> hypervisor, the hypervisor might need to maintain atomicity through locking.
> >
> > But if there already has lock inside guest for those access, and there
> > have no other code patch(like timer callback function) in hypervisor
> > to access the shared data, then we don't need to use lock in hypersivor.
> 
> If there is a memory-mapped register access which is atomic on bare metal,
> the guest may not bother with locking. We have to maintain that apparent
> atomicity ourselves by implementing serialisation in the hypervisor.
> 
> >>> I don't know whether all those locks are necessary, but at least the
> >>> lock for vhpet, especially the reading lock, is not required.
> >>
> >> This is definitely not true, for example locking is required around
> >> calls to create_periodic_time(), to serialise them. So in general the
> >> locking I added, even in vhpet.c is required. If you have a specific
> >> hot path you are looking to optimise, and especially if you have
> >> numbers to back that up, then we can consider specific localised
> >> optimisations to avoid locking where we can reason it is not needed.
> > As I mentioned, if the guest can ensure there only one CPU to access
> > the hpet at same time, this means the access itself already is serialized.
> > Yes.Win8 is booting very slowly w/ more than 16 VCPUs. And this is due
> > to the big lock in reading hpet. Also, the xentrace data shows lots of
> > vmexit which mainly from PAUSE instruction from other cpus. So I think
> > if guest already uses lock to protect the hpet access, why hypervisor do the
> same thing too?
> 
> If the HPET accesses are atomic on bare metal, we have to maintain that, even
> if some guests have extra locking themselves. Also, in some cases Xen needs
> locking to correctly maintain its own internal state regardless of what an
> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
> everywhere. It's definitely not correct to do so. Optimising the hpet read path
> however, sounds okay. I agree the lock may not be needed on that specific
> path.

You are right.
For this case, since the main access of hpet is to read the main counter, so I think the rwlock is a better choice. 

yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 07:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 07:55:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKPjJ-0005R1-8W; Wed, 18 Apr 2012 07:55:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SKPjI-0005Qw-75
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 07:55:08 +0000
Received: from [85.158.143.99:53971] by server-3.bemta-4.messagelabs.com id
	1F/7D-05853-B537E8F4; Wed, 18 Apr 2012 07:55:07 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334735705!23802446!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1MjE5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11162 invoked from network); 18 Apr 2012 07:55:06 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 07:55:06 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 18 Apr 2012 00:55:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="132277044"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 18 Apr 2012 00:55:04 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 18 Apr 2012 00:55:04 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Wed, 18 Apr 2012 15:55:02 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKeg
Date: Wed, 18 Apr 2012 07:55:01 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0DA169@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0D9CDC@SHSMSX101.ccr.corp.intel.com>
	<CBB42827.30EE3%keir.xen@gmail.com>
In-Reply-To: <CBB42827.30EE3%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Wednesday, April 18, 2012 3:13 PM
> To: Zhang, Yang Z; xen-devel@lists.xensource.com
> Subject: Re: lock in vhpet
> 
> On 18/04/2012 01:52, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> 
> >> It depends. Where an access is an apparently-atomic memory-mapped
> >> access, but implemented as a sequence of operations in the
> >> hypervisor, the hypervisor might need to maintain atomicity through locking.
> >
> > But if there already has lock inside guest for those access, and there
> > have no other code patch(like timer callback function) in hypervisor
> > to access the shared data, then we don't need to use lock in hypersivor.
> 
> If there is a memory-mapped register access which is atomic on bare metal,
> the guest may not bother with locking. We have to maintain that apparent
> atomicity ourselves by implementing serialisation in the hypervisor.
> 
> >>> I don't know whether all those locks are necessary, but at least the
> >>> lock for vhpet, especially the reading lock, is not required.
> >>
> >> This is definitely not true, for example locking is required around
> >> calls to create_periodic_time(), to serialise them. So in general the
> >> locking I added, even in vhpet.c is required. If you have a specific
> >> hot path you are looking to optimise, and especially if you have
> >> numbers to back that up, then we can consider specific localised
> >> optimisations to avoid locking where we can reason it is not needed.
> > As I mentioned, if the guest can ensure there only one CPU to access
> > the hpet at same time, this means the access itself already is serialized.
> > Yes.Win8 is booting very slowly w/ more than 16 VCPUs. And this is due
> > to the big lock in reading hpet. Also, the xentrace data shows lots of
> > vmexit which mainly from PAUSE instruction from other cpus. So I think
> > if guest already uses lock to protect the hpet access, why hypervisor do the
> same thing too?
> 
> If the HPET accesses are atomic on bare metal, we have to maintain that, even
> if some guests have extra locking themselves. Also, in some cases Xen needs
> locking to correctly maintain its own internal state regardless of what an
> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
> everywhere. It's definitely not correct to do so. Optimising the hpet read path
> however, sounds okay. I agree the lock may not be needed on that specific
> path.

You are right.
For this case, since the main access of hpet is to read the main counter, so I think the rwlock is a better choice. 

yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:30:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQGQ-0006EB-TI; Wed, 18 Apr 2012 08:29:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKQGP-0006E6-K6
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:29:21 +0000
Received: from [193.109.254.147:36920] by server-12.bemta-14.messagelabs.com
	id F3/B2-05898-06B7E8F4; Wed, 18 Apr 2012 08:29:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334737758!2010638!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3040 invoked from network); 18 Apr 2012 08:29:18 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:29:18 -0000
Received: by bkwj5 with SMTP id j5so6244554bkw.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 01:29:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ivM5Om+uHBLjQQu8ZwopGTCnQgAhRu/q59iNYkQESpA=;
	b=K3nxJTbgcwdRIlXkO+xVw4Z2zaUdO5lNpXCXDtol7+1uyHbvzQAw4VdVwr58ysUStu
	MUHuBheBPOPRFO9Jk9VC/fMXnu0z3e8vgS6nVJD2k8K0eFOG+K5FiEVP+JSFB2H1fUy9
	0+D+2kHIcKz2xf3m0DbBtixG/OVRx5H3VjR8W4f5PP2OTA6nJoLiDHWN+ErRVFBU0Odc
	TffcbrMKUVyBtGWnsMiK/1fVOx/9+8iiHzcZ5zjUKyC8mlj0Qt0B/cvWULhpguZ0TGNk
	SeWMeMzEN/5Z+ul7RM27E9v5V7lrw//8C0ThsjC946GdRi3ghD6ETmmYSbGkcJMKBqHF
	YjxA==
Received: by 10.204.157.12 with SMTP id z12mr376533bkw.135.1334737758260;
	Wed, 18 Apr 2012 01:29:18 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id ic8sm29573739bkc.4.2012.04.18.01.29.17
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 01:29:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 09:29:07 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB439E3.3E625%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IU=
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0DA169@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

>> If the HPET accesses are atomic on bare metal, we have to maintain that, even
>> if some guests have extra locking themselves. Also, in some cases Xen needs
>> locking to correctly maintain its own internal state regardless of what an
>> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
>> everywhere. It's definitely not correct to do so. Optimising the hpet read
>> path
>> however, sounds okay. I agree the lock may not be needed on that specific
>> path.
> 
> You are right.
> For this case, since the main access of hpet is to read the main counter, so I
> think the rwlock is a better choice.

I'll see if I can make a patch...

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:30:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQGQ-0006EB-TI; Wed, 18 Apr 2012 08:29:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKQGP-0006E6-K6
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:29:21 +0000
Received: from [193.109.254.147:36920] by server-12.bemta-14.messagelabs.com
	id F3/B2-05898-06B7E8F4; Wed, 18 Apr 2012 08:29:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334737758!2010638!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3040 invoked from network); 18 Apr 2012 08:29:18 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:29:18 -0000
Received: by bkwj5 with SMTP id j5so6244554bkw.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 01:29:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ivM5Om+uHBLjQQu8ZwopGTCnQgAhRu/q59iNYkQESpA=;
	b=K3nxJTbgcwdRIlXkO+xVw4Z2zaUdO5lNpXCXDtol7+1uyHbvzQAw4VdVwr58ysUStu
	MUHuBheBPOPRFO9Jk9VC/fMXnu0z3e8vgS6nVJD2k8K0eFOG+K5FiEVP+JSFB2H1fUy9
	0+D+2kHIcKz2xf3m0DbBtixG/OVRx5H3VjR8W4f5PP2OTA6nJoLiDHWN+ErRVFBU0Odc
	TffcbrMKUVyBtGWnsMiK/1fVOx/9+8iiHzcZ5zjUKyC8mlj0Qt0B/cvWULhpguZ0TGNk
	SeWMeMzEN/5Z+ul7RM27E9v5V7lrw//8C0ThsjC946GdRi3ghD6ETmmYSbGkcJMKBqHF
	YjxA==
Received: by 10.204.157.12 with SMTP id z12mr376533bkw.135.1334737758260;
	Wed, 18 Apr 2012 01:29:18 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id ic8sm29573739bkc.4.2012.04.18.01.29.17
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 01:29:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 09:29:07 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB439E3.3E625%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IU=
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0DA169@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

>> If the HPET accesses are atomic on bare metal, we have to maintain that, even
>> if some guests have extra locking themselves. Also, in some cases Xen needs
>> locking to correctly maintain its own internal state regardless of what an
>> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
>> everywhere. It's definitely not correct to do so. Optimising the hpet read
>> path
>> however, sounds okay. I agree the lock may not be needed on that specific
>> path.
> 
> You are right.
> For this case, since the main access of hpet is to read the main counter, so I
> think the rwlock is a better choice.

I'll see if I can make a patch...

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQJR-0006Ki-55; Wed, 18 Apr 2012 08:32:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKQJO-0006KS-R7
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:32:27 +0000
Received: from [193.109.254.147:29432] by server-10.bemta-14.messagelabs.com
	id FE/37-05847-A1C7E8F4; Wed, 18 Apr 2012 08:32:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334737945!5128384!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3895 invoked from network); 18 Apr 2012 08:32:25 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:32:25 -0000
Received: by eekc13 with SMTP id c13so2525211eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 01:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=l7TYhq/kCucN/Y5roBX4WqVyjNmOGOTGJewbugoNVeo=;
	b=NRMt9mQ9/sQoFhcgKb5Sf1g9GVkpf9vvHYnG4+Lw4ZlXsBMZsFqlivAkNfGNWd3e0U
	rtjeazJS5GviYXN3BZ8RKocjNzPtvOXfsP3gwoVAJowK7/BFZLTEWn1RoBIBd9nBFBKa
	wiB0irTEBA8FHwH1x4PJyMBy1X0rQwRQd6fkRui6FtmPDmjBfiDwe1B3GKNGlEO5zCP1
	vOU6MyWielnxTcCbUusJ4Pf0phDGvT6QKhD4d0Jsqxlc73Wswr1Z+mTeRIKHZCaSJ3v7
	ePk4Aca33maekUjPmUgjs6ouViiCnZaP8P6OU/DUKDNr71DkNTbehQS6TXmgYElDrcVp
	m2Sg==
Received: by 10.14.188.7 with SMTP id z7mr184037eem.91.1334737944203;
	Wed, 18 Apr 2012 01:32:24 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id r44sm114652091eef.2.2012.04.18.01.32.22
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 01:32:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 09:32:19 +0100
From: Keir Fraser <keir@xen.org>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CBB43AA3.3E628%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] mem_access: fix setting default mem_access
	type
Thread-Index: Ac0dPcR3jgXxD8YT7EiznWN5E2wGkQ==
In-Reply-To: <CAB10MZA-64tOohf5_1-8LJ52E3dUC0xOYSUPRgUgeqC3mOBhKQ@mail.gmail.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] mem_access: fix setting default mem_access
 type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/2012 02:09, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

> When xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0)
> is called, first_pfn=~0ull is a hint to HVMOP_set_mem_access as to
> what the default mem_access type is for the domain. This call was
> failing because it was gated by the memory range check in the
> HVMOP_set_mem_access case statement in do_hvm_op(). The following
> patch fixes this issue.
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

Looks okay to me. Probably should be checked and applied by Tim.

 -- Keir

> ---
>  xen/arch/x86/hvm/hvm.c |  5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff -r a06e6cdeafe3 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c Mon Apr 16 13:05:28 2012 +0200
> +++ b/xen/arch/x86/hvm/hvm.c Tue Apr 17 18:03:37 2012 -0700
> @@ -4170,9 +4170,10 @@
>              goto param_fail5;
> 
>          rc = -EINVAL;
> -        if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
> +        if ( (a.first_pfn != ~0ull) &&
> +             ((a.first_pfn > domain_get_maximum_gpfn(d)) ||
>               ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
> -             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
> +             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d))) )
>              goto param_fail5;
> 
>          rc = p2m_set_mem_access(d, a.first_pfn, a.nr, a.hvmmem_access);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQJR-0006Ki-55; Wed, 18 Apr 2012 08:32:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKQJO-0006KS-R7
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:32:27 +0000
Received: from [193.109.254.147:29432] by server-10.bemta-14.messagelabs.com
	id FE/37-05847-A1C7E8F4; Wed, 18 Apr 2012 08:32:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334737945!5128384!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3895 invoked from network); 18 Apr 2012 08:32:25 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:32:25 -0000
Received: by eekc13 with SMTP id c13so2525211eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 01:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=l7TYhq/kCucN/Y5roBX4WqVyjNmOGOTGJewbugoNVeo=;
	b=NRMt9mQ9/sQoFhcgKb5Sf1g9GVkpf9vvHYnG4+Lw4ZlXsBMZsFqlivAkNfGNWd3e0U
	rtjeazJS5GviYXN3BZ8RKocjNzPtvOXfsP3gwoVAJowK7/BFZLTEWn1RoBIBd9nBFBKa
	wiB0irTEBA8FHwH1x4PJyMBy1X0rQwRQd6fkRui6FtmPDmjBfiDwe1B3GKNGlEO5zCP1
	vOU6MyWielnxTcCbUusJ4Pf0phDGvT6QKhD4d0Jsqxlc73Wswr1Z+mTeRIKHZCaSJ3v7
	ePk4Aca33maekUjPmUgjs6ouViiCnZaP8P6OU/DUKDNr71DkNTbehQS6TXmgYElDrcVp
	m2Sg==
Received: by 10.14.188.7 with SMTP id z7mr184037eem.91.1334737944203;
	Wed, 18 Apr 2012 01:32:24 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id r44sm114652091eef.2.2012.04.18.01.32.22
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 01:32:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 09:32:19 +0100
From: Keir Fraser <keir@xen.org>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CBB43AA3.3E628%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] mem_access: fix setting default mem_access
	type
Thread-Index: Ac0dPcR3jgXxD8YT7EiznWN5E2wGkQ==
In-Reply-To: <CAB10MZA-64tOohf5_1-8LJ52E3dUC0xOYSUPRgUgeqC3mOBhKQ@mail.gmail.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] mem_access: fix setting default mem_access
 type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/2012 02:09, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

> When xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0)
> is called, first_pfn=~0ull is a hint to HVMOP_set_mem_access as to
> what the default mem_access type is for the domain. This call was
> failing because it was gated by the memory range check in the
> HVMOP_set_mem_access case statement in do_hvm_op(). The following
> patch fixes this issue.
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

Looks okay to me. Probably should be checked and applied by Tim.

 -- Keir

> ---
>  xen/arch/x86/hvm/hvm.c |  5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff -r a06e6cdeafe3 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c Mon Apr 16 13:05:28 2012 +0200
> +++ b/xen/arch/x86/hvm/hvm.c Tue Apr 17 18:03:37 2012 -0700
> @@ -4170,9 +4170,10 @@
>              goto param_fail5;
> 
>          rc = -EINVAL;
> -        if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
> +        if ( (a.first_pfn != ~0ull) &&
> +             ((a.first_pfn > domain_get_maximum_gpfn(d)) ||
>               ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
> -             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
> +             ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d))) )
>              goto param_fail5;
> 
>          rc = p2m_set_mem_access(d, a.first_pfn, a.nr, a.hvmmem_access);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQKe-0006SS-KC; Wed, 18 Apr 2012 08:33:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQKd-0006S9-OE
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:33:44 +0000
Received: from [193.109.254.147:52724] by server-2.bemta-14.messagelabs.com id
	E9/39-19409-76C7E8F4; Wed, 18 Apr 2012 08:33:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334738022!5122068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21997 invoked from network); 18 Apr 2012 08:33:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11994555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:33:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:33:41 +0100
Message-ID: <1334738020.23948.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 18 Apr 2012 09:33:40 +0100
In-Reply-To: <20120417182009.14219141@mantra.us.oracle.com>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
	<20120417182009.14219141@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 02:20 +0100, Mukesh Rathor wrote:
> On Mon, 16 Apr 2012 17:22:14 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 16 Apr 2012, Ian Campbell wrote:
> > > > In a nutshell, I am still trying to figure how to allocate rsvd
> > > > pfn's for privcmd without writing a slab allocator.
> > > 
> > > Can't you just use the core get_page function (or
> > > alloc_xenballooned_pages) and move the associated mfn aside
> > > temporarily (or not if using alloc_xenballooned_pages)?
> > 
> > I think that is a good suggestion: if we are trying to get in
> > something that works but might not be the best solution, then using
> > alloc_xenballooned_pages to get some pages and then changing the p2m
> > is the best option: it wastes a non-trivial amount of memory in dom0
> > but at least it is known to work well and it wouldn't be an "hack".
> > 
> > Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
> > for an example.
> 
> 
> Ok. I changed to using alloc_xenballooned_pages. In future, if we run
> into problems, we can look into alternatives. In past we've had
> problems with limits reached ballooing down. We run with small dom0.

You don't really need to increase the size of dom0, just the size of the
balloon. e.g. if you run dom0_mem=512M,max:1024M then you get a dom0
with 512M of RAM, but a total PFN space of 1024M, which means you have
512M of balloon available for alloc_xenballooned_pages.

If you just do dom0_mem=512M then I believe you get 512M of RAM but PFN
space sized for the entire host, which is going to give you more than
enough balloon space on any typical host (but there are obviously
downsides if the host has lots of RAM relative to 512M!)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQKe-0006SS-KC; Wed, 18 Apr 2012 08:33:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQKd-0006S9-OE
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:33:44 +0000
Received: from [193.109.254.147:52724] by server-2.bemta-14.messagelabs.com id
	E9/39-19409-76C7E8F4; Wed, 18 Apr 2012 08:33:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334738022!5122068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21997 invoked from network); 18 Apr 2012 08:33:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11994555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:33:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:33:41 +0100
Message-ID: <1334738020.23948.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 18 Apr 2012 09:33:40 +0100
In-Reply-To: <20120417182009.14219141@mantra.us.oracle.com>
References: <20120323110144.4b2f1d45@mantra.us.oracle.com>
	<alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
	<20120413184705.77b4d316@mantra.us.oracle.com>
	<1334585643.14560.199.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204161715330.26786@kaball-desktop>
	<20120417182009.14219141@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid] : mmap pfn space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 02:20 +0100, Mukesh Rathor wrote:
> On Mon, 16 Apr 2012 17:22:14 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 16 Apr 2012, Ian Campbell wrote:
> > > > In a nutshell, I am still trying to figure how to allocate rsvd
> > > > pfn's for privcmd without writing a slab allocator.
> > > 
> > > Can't you just use the core get_page function (or
> > > alloc_xenballooned_pages) and move the associated mfn aside
> > > temporarily (or not if using alloc_xenballooned_pages)?
> > 
> > I think that is a good suggestion: if we are trying to get in
> > something that works but might not be the best solution, then using
> > alloc_xenballooned_pages to get some pages and then changing the p2m
> > is the best option: it wastes a non-trivial amount of memory in dom0
> > but at least it is known to work well and it wouldn't be an "hack".
> > 
> > Give a look at gntdev_alloc_map, gnttab_map_refs and m2p_add_override
> > for an example.
> 
> 
> Ok. I changed to using alloc_xenballooned_pages. In future, if we run
> into problems, we can look into alternatives. In past we've had
> problems with limits reached ballooing down. We run with small dom0.

You don't really need to increase the size of dom0, just the size of the
balloon. e.g. if you run dom0_mem=512M,max:1024M then you get a dom0
with 512M of RAM, but a total PFN space of 1024M, which means you have
512M of balloon available for alloc_xenballooned_pages.

If you just do dom0_mem=512M then I believe you get 512M of RAM but PFN
space sized for the entire host, which is going to give you more than
enough balloon space on any typical host (but there are obviously
downsides if the host has lots of RAM relative to 512M!)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:35:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQLa-0006Zy-6j; Wed, 18 Apr 2012 08:34:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQLY-0006Zb-Fz
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:34:40 +0000
Received: from [193.109.254.147:38670] by server-1.bemta-14.messagelabs.com id
	94/F8-29372-F9C7E8F4; Wed, 18 Apr 2012 08:34:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334738079!5090523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12763 invoked from network); 18 Apr 2012 08:34:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:34:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11994584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:34:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:34:39 +0100
Message-ID: <1334738077.23948.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 09:34:37 +0100
In-Reply-To: <20365.42906.867250.920616@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42906.867250.920616@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/7] libxl:
 libxl__device_disk_local_attach	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 18:25 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
> > - make libxl_device_disk_local_attach/detach two internal functions;
> > 
> > - pass a gc rather than a ctx to them;
> > 
> > - introduce a new libxl_device_disk** parameter to
> > libxl__device_disk_local_attach, the parameter is allocated on the gc by
> > libxl__device_disk_local_attach. It is going to fill it with
> > informations about the new locally attached disk.  The new
> > libxl_device_disk should be passed to libxl_device_disk_local_detach
> > afterwards.
> 
> Mixing the changes up with teh code motion makes this quite hard to
> review.

This was also going to be my first comment.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:35:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQLa-0006Zy-6j; Wed, 18 Apr 2012 08:34:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQLY-0006Zb-Fz
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:34:40 +0000
Received: from [193.109.254.147:38670] by server-1.bemta-14.messagelabs.com id
	94/F8-29372-F9C7E8F4; Wed, 18 Apr 2012 08:34:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334738079!5090523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12763 invoked from network); 18 Apr 2012 08:34:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:34:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11994584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:34:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:34:39 +0100
Message-ID: <1334738077.23948.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 09:34:37 +0100
In-Reply-To: <20365.42906.867250.920616@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42906.867250.920616@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/7] libxl:
 libxl__device_disk_local_attach	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 18:25 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
> > - make libxl_device_disk_local_attach/detach two internal functions;
> > 
> > - pass a gc rather than a ctx to them;
> > 
> > - introduce a new libxl_device_disk** parameter to
> > libxl__device_disk_local_attach, the parameter is allocated on the gc by
> > libxl__device_disk_local_attach. It is going to fill it with
> > informations about the new locally attached disk.  The new
> > libxl_device_disk should be passed to libxl_device_disk_local_detach
> > afterwards.
> 
> Mixing the changes up with teh code motion makes this quite hard to
> review.

This was also going to be my first comment.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:42:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQSZ-00078o-2p; Wed, 18 Apr 2012 08:41:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQSX-00078i-K0
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:41:53 +0000
Received: from [85.158.143.99:14005] by server-3.bemta-4.messagelabs.com id
	12/B7-05853-05E7E8F4; Wed, 18 Apr 2012 08:41:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334738512!23225957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8230 invoked from network); 18 Apr 2012 08:41:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:41:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11994829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:41:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:41:51 +0100
Message-ID: <1334738510.23948.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 18 Apr 2012 09:41:50 +0100
In-Reply-To: <1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter
 to libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 19:33 +0100, Stefano Stabellini wrote:
> Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
> XBT_NULL, allocate a proper one.
> 
> Update all the callers.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |   10 +++++-----
>  tools/libxl/libxl_device.c   |   14 +++++++-------
>  tools/libxl/libxl_internal.h |    4 ++--
>  tools/libxl/libxl_pci.c      |    2 +-
>  4 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index e645d2a..85082eb 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      flexarray_append(front, "device-type");
>      flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>  
> @@ -1795,7 +1795,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>      flexarray_append(front, "mac");
>      flexarray_append(front, libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>  
> @@ -2073,7 +2073,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
>          flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
>      }
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
> @@ -2144,7 +2144,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
>      flexarray_append(front, "state");
>      flexarray_append(front, libxl__sprintf(gc, "%d", 1));
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
> @@ -2277,7 +2277,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>                            libxl__sprintf(gc, "%d", vfb->backend_domid));
>      flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index c7e057d..05909c5 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
>      return libxl__device_kind_from_string(strkind, &dev->backend_kind);
>  }
>  
> -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> -                             char **bents, char **fents)
> +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> +        libxl__device *device, char **bents, char **fents)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      char *frontend_path, *backend_path;
> -    xs_transaction_t t;
>      struct xs_permissions frontend_perms[2];
>      struct xs_permissions backend_perms[2];
> +    int create_transaction = t == XBT_NULL;
>  
>      frontend_path = libxl__device_frontend_path(gc, device);
>      backend_path = libxl__device_backend_path(gc, device);
> @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
>      backend_perms[1].perms = XS_PERM_READ;
>  
>  retry_transaction:
> -    t = xs_transaction_start(ctx->xsh);
> +    if (create_transaction)
> +        t = xs_transaction_start(ctx->xsh);
>      /* FIXME: read frontend_path and check state before removing stuff */
>  
>      if (fents) {
> @@ -101,13 +102,12 @@ retry_transaction:
>      }
>  
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {

Do we really want to end the transaction for caller provided t? (i.e.
when create_transaction == False)

It would seem more expected to me to return to the caller and expect
them to complete the transaction and perform error handling etc. If the
caller doesn't have things of its own to do in the transaction then why
does it have one in hand to pass in?

> -        if (errno == EAGAIN)
> +        if (errno == EAGAIN && create_transaction)
>              goto retry_transaction;
>          else
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
>      }
> -
> -    return 0;
> +    return ERROR_FAIL;

Where is the success exit path in this function now?

>  }
>  
>  typedef struct {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4e0d203..c0991eb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -681,8 +681,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
>                                        libxl__device_console *console,
>                                        libxl__domain_build_state *state);
>  
> -_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> -                             char **bents, char **fents);
> +_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> +        libxl__device *device, char **bents, char **fents);
>  _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
>  _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
>  _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index e8b8839..202a101 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
>      flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
>      flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                                libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                                libxl__xs_kvs_of_flexarray(gc, front, front->count));
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:42:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQSZ-00078o-2p; Wed, 18 Apr 2012 08:41:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQSX-00078i-K0
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:41:53 +0000
Received: from [85.158.143.99:14005] by server-3.bemta-4.messagelabs.com id
	12/B7-05853-05E7E8F4; Wed, 18 Apr 2012 08:41:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334738512!23225957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDgxMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8230 invoked from network); 18 Apr 2012 08:41:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:41:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11994829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:41:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:41:51 +0100
Message-ID: <1334738510.23948.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 18 Apr 2012 09:41:50 +0100
In-Reply-To: <1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter
 to libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 19:33 +0100, Stefano Stabellini wrote:
> Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
> XBT_NULL, allocate a proper one.
> 
> Update all the callers.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |   10 +++++-----
>  tools/libxl/libxl_device.c   |   14 +++++++-------
>  tools/libxl/libxl_internal.h |    4 ++--
>  tools/libxl/libxl_pci.c      |    2 +-
>  4 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index e645d2a..85082eb 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      flexarray_append(front, "device-type");
>      flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>  
> @@ -1795,7 +1795,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>      flexarray_append(front, "mac");
>      flexarray_append(front, libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>  
> @@ -2073,7 +2073,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
>          flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
>      }
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
> @@ -2144,7 +2144,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
>      flexarray_append(front, "state");
>      flexarray_append(front, libxl__sprintf(gc, "%d", 1));
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
> @@ -2277,7 +2277,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>                            libxl__sprintf(gc, "%d", vfb->backend_domid));
>      flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index c7e057d..05909c5 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
>      return libxl__device_kind_from_string(strkind, &dev->backend_kind);
>  }
>  
> -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> -                             char **bents, char **fents)
> +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> +        libxl__device *device, char **bents, char **fents)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      char *frontend_path, *backend_path;
> -    xs_transaction_t t;
>      struct xs_permissions frontend_perms[2];
>      struct xs_permissions backend_perms[2];
> +    int create_transaction = t == XBT_NULL;
>  
>      frontend_path = libxl__device_frontend_path(gc, device);
>      backend_path = libxl__device_backend_path(gc, device);
> @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
>      backend_perms[1].perms = XS_PERM_READ;
>  
>  retry_transaction:
> -    t = xs_transaction_start(ctx->xsh);
> +    if (create_transaction)
> +        t = xs_transaction_start(ctx->xsh);
>      /* FIXME: read frontend_path and check state before removing stuff */
>  
>      if (fents) {
> @@ -101,13 +102,12 @@ retry_transaction:
>      }
>  
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {

Do we really want to end the transaction for caller provided t? (i.e.
when create_transaction == False)

It would seem more expected to me to return to the caller and expect
them to complete the transaction and perform error handling etc. If the
caller doesn't have things of its own to do in the transaction then why
does it have one in hand to pass in?

> -        if (errno == EAGAIN)
> +        if (errno == EAGAIN && create_transaction)
>              goto retry_transaction;
>          else
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
>      }
> -
> -    return 0;
> +    return ERROR_FAIL;

Where is the success exit path in this function now?

>  }
>  
>  typedef struct {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4e0d203..c0991eb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -681,8 +681,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
>                                        libxl__device_console *console,
>                                        libxl__domain_build_state *state);
>  
> -_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> -                             char **bents, char **fents);
> +_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> +        libxl__device *device, char **bents, char **fents);
>  _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
>  _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
>  _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index e8b8839..202a101 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
>      flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
>      flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
>  
> -    libxl__device_generic_add(gc, &device,
> +    libxl__device_generic_add(gc, XBT_NULL, &device,
>                                libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                                libxl__xs_kvs_of_flexarray(gc, front, front->count));
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:52:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQcA-0007N3-71; Wed, 18 Apr 2012 08:51:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQc9-0007My-CZ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 08:51:49 +0000
Received: from [85.158.143.35:59149] by server-1.bemta-4.messagelabs.com id
	32/50-20925-4A08E8F4; Wed, 18 Apr 2012 08:51:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334739105!12921850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20267 invoked from network); 18 Apr 2012 08:51:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11995121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:51:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:51:07 +0100
Message-ID: <1334739065.23948.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 09:51:05 +0100
In-Reply-To: <1334677876-17704-3-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-3-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> Add a function which behaves like "xenstore-rm -t", and which will be used to
> clean xenstore after unplug since we will be no longer executing
> xen-hotplug-cleanup script, that used to do that for us.

Can you put this in libxl_xshelp.c and a prototype in libxl_internal.h,
please. Also it should include a comment in the header describing the
function and what it does.

> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/libxl/libxl_device.c |   21 +++++++++++++++++++++
>  1 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index c7e057d..fe4bcc6 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -356,6 +356,27 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
>      return -1;
>  }
>  
> +static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    unsigned int nb = 0;
> +    char *last;
> +
> +    if (!path)
> +        return 0;
> +
> +    xs_rm(ctx->xsh, XBT_NULL, path);
> +
> +    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
> +        *last = '\0';
> +        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
> +            continue;
> +        if (nb == 0) {
> +            xs_rm(ctx->xsh, XBT_NULL, path);
> +        }
> +    }
> +    return 0;
> +}
>  
>  typedef struct {
>      libxl__ao *ao;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:52:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQcA-0007N3-71; Wed, 18 Apr 2012 08:51:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQc9-0007My-CZ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 08:51:49 +0000
Received: from [85.158.143.35:59149] by server-1.bemta-4.messagelabs.com id
	32/50-20925-4A08E8F4; Wed, 18 Apr 2012 08:51:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334739105!12921850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20267 invoked from network); 18 Apr 2012 08:51:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11995121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:51:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:51:07 +0100
Message-ID: <1334739065.23948.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 09:51:05 +0100
In-Reply-To: <1334677876-17704-3-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-3-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> Add a function which behaves like "xenstore-rm -t", and which will be used to
> clean xenstore after unplug since we will be no longer executing
> xen-hotplug-cleanup script, that used to do that for us.

Can you put this in libxl_xshelp.c and a prototype in libxl_internal.h,
please. Also it should include a comment in the header describing the
function and what it does.

> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  tools/libxl/libxl_device.c |   21 +++++++++++++++++++++
>  1 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index c7e057d..fe4bcc6 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -356,6 +356,27 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
>      return -1;
>  }
>  
> +static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    unsigned int nb = 0;
> +    char *last;
> +
> +    if (!path)
> +        return 0;
> +
> +    xs_rm(ctx->xsh, XBT_NULL, path);
> +
> +    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
> +        *last = '\0';
> +        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
> +            continue;
> +        if (nb == 0) {
> +            xs_rm(ctx->xsh, XBT_NULL, path);
> +        }
> +    }
> +    return 0;
> +}
>  
>  typedef struct {
>      libxl__ao *ao;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:59:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQj3-0007WX-4j; Wed, 18 Apr 2012 08:58:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQj1-0007WP-Sg
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:58:55 +0000
Received: from [85.158.143.35:53128] by server-1.bemta-4.messagelabs.com id
	90/60-20925-F428E8F4; Wed, 18 Apr 2012 08:58:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334739534!12923457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25055 invoked from network); 18 Apr 2012 08:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11995346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:58:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:58:54 +0100
Message-ID: <1334739533.23948.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 09:58:53 +0100
In-Reply-To: <20365.42396.142064.874548@mariner.uk.xensource.com>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42396.142064.874548@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 18:17 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> > qemu-xen offers better disk performances than qemu-xen-traditional
> > because it supports Linux native AIO.
> 
> Does this take any account of whether the new qemu-xen dm is
> installed ?

I don't think it is possible to install xen-unstable without
qemu-upstream-xen getting built and installed? At least not building
from source, perhaps a distro might package them separately but there
really ought to be a depends relationship in that case? Would we want to
support a Xen without qemu-upstream-xen configuration?

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 08:59:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 08:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQj3-0007WX-4j; Wed, 18 Apr 2012 08:58:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKQj1-0007WP-Sg
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 08:58:55 +0000
Received: from [85.158.143.35:53128] by server-1.bemta-4.messagelabs.com id
	90/60-20925-F428E8F4; Wed, 18 Apr 2012 08:58:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334739534!12923457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25055 invoked from network); 18 Apr 2012 08:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 08:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11995346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 08:58:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:58:54 +0100
Message-ID: <1334739533.23948.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 09:58:53 +0100
In-Reply-To: <20365.42396.142064.874548@mariner.uk.xensource.com>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42396.142064.874548@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 18:17 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> > qemu-xen offers better disk performances than qemu-xen-traditional
> > because it supports Linux native AIO.
> 
> Does this take any account of whether the new qemu-xen dm is
> installed ?

I don't think it is possible to install xen-unstable without
qemu-upstream-xen getting built and installed? At least not building
from source, perhaps a distro might package them separately but there
really ought to be a depends relationship in that case? Would we want to
support a Xen without qemu-upstream-xen configuration?

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 09:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQyM-0007ta-19; Wed, 18 Apr 2012 09:14:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKQyL-0007tV-6J
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 09:14:45 +0000
Received: from [85.158.143.99:31046] by server-2.bemta-4.messagelabs.com id
	6E/67-17550-4068E8F4; Wed, 18 Apr 2012 09:14:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334740483!18897058!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16165 invoked from network); 18 Apr 2012 09:14:43 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:14:43 -0000
Received: by bkwj5 with SMTP id j5so6288123bkw.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 02:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=9AEaOp075Sjvjf4SjKN6KN+jaHe6tMFf9iW/W7Z/KMs=;
	b=fy+bT5t6zLX0xQGRyuKzkJE/skiUj4w/QNglNqvguXf021x42BY1klDXR2Z4pkuLA/
	dlRiAt1jDlo8T7xGjuLLcxa/pJPFwhqcnqn28/kzw0jMBqLx/uuinXtN5J0CxOCGd/bJ
	rP7llnB7FNAlJjUSBWINNtjq/LLwJkvstaS9gMCzF3/PMxUZdP/tAE8UxfCxrbz+vQ1z
	qETqYhwf/EqZIBfzZDtY+bxij71CXRXijTPjSe2UfphxzziQ14MDuAjZTteoeL4A4bju
	zVLfyTTCcajUS1ygZOHAdgNZSTkz8m9fPKV6YauiYwH4CsUe1NfCIS2EkQcoYD594XWI
	IRww==
Received: by 10.204.156.8 with SMTP id u8mr444220bkw.36.1334740482720;
	Wed, 18 Apr 2012 02:14:42 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id gu12sm42854642bkc.1.2012.04.18.02.14.40
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 02:14:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 10:14:35 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB4448D.3E643%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IUAAZaB3A==
In-Reply-To: <CBB439E3.3E625%keir@xen.org>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3417588880_251225"
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3417588880_251225
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 18/04/2012 09:29, "Keir Fraser" <keir@xen.org> wrote:

> On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> 
>>> If the HPET accesses are atomic on bare metal, we have to maintain that,
>>> even
>>> if some guests have extra locking themselves. Also, in some cases Xen needs
>>> locking to correctly maintain its own internal state regardless of what an
>>> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
>>> everywhere. It's definitely not correct to do so. Optimising the hpet read
>>> path
>>> however, sounds okay. I agree the lock may not be needed on that specific
>>> path.
>> 
>> You are right.
>> For this case, since the main access of hpet is to read the main counter, so
>> I
>> think the rwlock is a better choice.
> 
> I'll see if I can make a patch...

Please try the attached patch (build tested only).

 -- Keir

>  -- Keir
> 
> 


--B_3417588880_251225
Content-type: application/octet-stream; name="00-hpet-lockfree"
Content-disposition: attachment;
	filename="00-hpet-lockfree"
Content-transfer-encoding: base64


ZGlmZiAtciBjZjEyOWE4MGU0N2UgeGVuL2FyY2gveDg2L2h2bS9ocGV0LmMKLS0tIGEveGVu
L2FyY2gveDg2L2h2bS9ocGV0LmMJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisr
KyBiL3hlbi9hcmNoL3g4Ni9odm0vaHBldC5jCVdlZCBBcHIgMTggMTA6MTM6MDcgMjAxMiAr
MDEwMApAQCAtNzMsMTQgKzczLDM2IEBACiAgICAgKCh0aW1lcl9jb25maWcoaCwgbikgJiBI
UEVUX1ROX0lOVF9ST1VURV9DQVBfTUFTSykgXAogICAgICAgICA+PiBIUEVUX1ROX0lOVF9S
T1VURV9DQVBfU0hJRlQpCiAKLXN0YXRpYyBpbmxpbmUgdWludDY0X3QgaHBldF9yZWFkX21h
aW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKKy8qCisgKiBocGV0X3tyZWFkLHNldH1fbWFpbmNv
dW50ZXIoKToKKyAqICBBdG9taWNhbGx5IGdldC9zZXQgaC0+bWNfY29uZmlnIHRvIGFsbG93
IHNhZmUgbG9jay1mcmVlIHJlYWQgYWNjZXNzIHRvCisgKiAgdGhlIEhQRVQgbWFpbiBjb3Vu
dGVyLiBtY19jb25maWdbMF0gaXMgMSB3aGVuIHRoZSBjb3VudGVyIGlzIGVuYWJsZWQuCisg
KiAgV2hlbiB0aGUgY291bnRlciBpcyBkaXNhYmxlZCwgbWNfY29uZmlnWzYzOjFdIGlzIHRo
ZSBjb3VudGVyIHZhbHVlLgorICogIFdoZW4gdGhlIGNvdW50ZXIgaXMgZW5hYmxlZCwgbWNf
Y29uZmlnWzYzOjFdIGlzIGEgc2lnbmVkIGNvdW50ZXIgb2Zmc2V0LgorICovCitzdGF0aWMg
dWludDY0X3QgaHBldF9yZWFkX21haW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKIHsKKyAgICBp
bnQ2NF90IG1jX2NvbmZpZyA9IHJlYWRfYXRvbWljKCZoLT5tY19jb25maWcpOworICAgIGlu
dDY0X3QgY291bnRlciA9IG1jX2NvbmZpZyA+PiAxOworICAgIGJvb2xfdCBlbmFibGVkID0g
bWNfY29uZmlnICYgMTsKKworICAgIGlmICggZW5hYmxlZCApCisgICAgICAgIGNvdW50ZXIg
Kz0gZ3Vlc3RfdGltZV9ocGV0KGgpOworCisgICAgcmV0dXJuICh1aW50NjRfdCljb3VudGVy
OworfQorCitzdGF0aWMgdm9pZCBocGV0X3NldF9tYWluY291bnRlcihIUEVUU3RhdGUgKmgp
Cit7CisgICAgaW50NjRfdCBtY19jb25maWc7CisKICAgICBBU1NFUlQoc3Bpbl9pc19sb2Nr
ZWQoJmgtPmxvY2spKTsKIAotICAgIGlmICggaHBldF9lbmFibGVkKGgpICkKLSAgICAgICAg
cmV0dXJuIGd1ZXN0X3RpbWVfaHBldChoKSArIGgtPm1jX29mZnNldDsKLSAgICBlbHNlIAot
ICAgICAgICByZXR1cm4gaC0+aHBldC5tYzY0OworICAgIG1jX2NvbmZpZyA9IChocGV0X2Vu
YWJsZWQoaCkKKyAgICAgICAgICAgICAgICAgPyAoKChoLT5ocGV0Lm1jNjQgLSBndWVzdF90
aW1lX2hwZXQoaCkpIDw8IDEpIHwgMXVsbCkKKyAgICAgICAgICAgICAgICAgOiAoaC0+aHBl
dC5tYzY0IDw8IDEpKTsKKworICAgIHdyaXRlX2F0b21pYygmaC0+bWNfY29uZmlnLCBtY19j
b25maWcpOwogfQogCiBzdGF0aWMgdWludDY0X3QgaHBldF9nZXRfY29tcGFyYXRvcihIUEVU
U3RhdGUgKmgsIHVuc2lnbmVkIGludCB0bikKQEAgLTEwNyw3ICsxMjksOCBAQCBzdGF0aWMg
dWludDY0X3QgaHBldF9nZXRfY29tcGFyYXRvcihIUEVUCiAgICAgaC0+aHBldC50aW1lcnNb
dG5dLmNtcCA9IGNvbXBhcmF0b3I7CiAgICAgcmV0dXJuIGNvbXBhcmF0b3I7CiB9Ci1zdGF0
aWMgaW5saW5lIHVpbnQ2NF90IGhwZXRfcmVhZDY0KEhQRVRTdGF0ZSAqaCwgdW5zaWduZWQg
bG9uZyBhZGRyKQorCitzdGF0aWMgdWludDY0X3QgX19ocGV0X3JlYWQ2NChIUEVUU3RhdGUg
KmgsIHVuc2lnbmVkIGxvbmcgYWRkcikKIHsKICAgICBhZGRyICY9IH43OwogCkBAIC0xMzgs
NiArMTYxLDIzIEBAIHN0YXRpYyBpbmxpbmUgdWludDY0X3QgaHBldF9yZWFkNjQoSFBFVFMK
ICAgICByZXR1cm4gMDsKIH0KIAorc3RhdGljIHVpbnQ2NF90IGhwZXRfcmVhZDY0KEhQRVRT
dGF0ZSAqaCwgdW5zaWduZWQgbG9uZyBhZGRyKQoreworICAgIC8qIEFsbG93IGxvY2stZnJl
ZSBhY2Nlc3MgdG8gbWFpbiBjb3VudGVyLiAqLworICAgIGJvb2xfdCBsb2NrID0gKChhZGRy
ICYgfjcpICE9IEhQRVRfQ09VTlRFUik7CisgICAgdWludDY0X3QgdmFsOworCisgICAgaWYg
KCBsb2NrICkKKyAgICAgICAgc3Bpbl9sb2NrKCZoLT5sb2NrKTsKKworICAgIHZhbCA9IF9f
aHBldF9yZWFkNjQoaCwgYWRkcik7CisKKyAgICBpZiAoIGxvY2sgKQorICAgICAgICBzcGlu
X3VubG9jaygmaC0+bG9jayk7CisKKyAgICByZXR1cm4gdmFsOworfQorCiBzdGF0aWMgaW5s
aW5lIGludCBocGV0X2NoZWNrX2FjY2Vzc19sZW5ndGgoCiAgICAgdW5zaWduZWQgbG9uZyBh
ZGRyLCB1bnNpZ25lZCBsb25nIGxlbikKIHsKQEAgLTE3MiwxNiArMjEyLDEyIEBAIHN0YXRp
YyBpbnQgaHBldF9yZWFkKAogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAKLSAgICBzcGlu
X2xvY2soJmgtPmxvY2spOwotCiAgICAgdmFsID0gaHBldF9yZWFkNjQoaCwgYWRkcik7CiAK
ICAgICByZXN1bHQgPSB2YWw7CiAgICAgaWYgKCBsZW5ndGggIT0gOCApCiAgICAgICAgIHJl
c3VsdCA9ICh2YWwgPj4gKChhZGRyICYgNykgKiA4KSkgJiAoKDFVTEwgPDwgKGxlbmd0aCAq
IDgpKSAtIDEpOwogCi0gICAgc3Bpbl91bmxvY2soJmgtPmxvY2spOwotCiAgb3V0OgogICAg
ICpwdmFsID0gcmVzdWx0OwogICAgIHJldHVybiBYODZFTVVMX09LQVk7CkBAIC0yOTEsNyAr
MzI3LDcgQEAgc3RhdGljIGludCBocGV0X3dyaXRlKAogCiAgICAgc3Bpbl9sb2NrKCZoLT5s
b2NrKTsKIAotICAgIG9sZF92YWwgPSBocGV0X3JlYWQ2NChoLCBhZGRyKTsKKyAgICBvbGRf
dmFsID0gX19ocGV0X3JlYWQ2NChoLCBhZGRyKTsKICAgICBuZXdfdmFsID0gdmFsOwogICAg
IGlmICggbGVuZ3RoICE9IDggKQogICAgICAgICBuZXdfdmFsID0gaHBldF9maXh1cF9yZWco
CkBAIC0zMDYsNyArMzQyLDcgQEAgc3RhdGljIGludCBocGV0X3dyaXRlKAogICAgICAgICBp
ZiAoICEob2xkX3ZhbCAmIEhQRVRfQ0ZHX0VOQUJMRSkgJiYgKG5ld192YWwgJiBIUEVUX0NG
R19FTkFCTEUpICkKICAgICAgICAgewogICAgICAgICAgICAgLyogRW5hYmxlIG1haW4gY291
bnRlciBhbmQgaW50ZXJydXB0IGdlbmVyYXRpb24uICovCi0gICAgICAgICAgICBoLT5tY19v
ZmZzZXQgPSBoLT5ocGV0Lm1jNjQgLSBndWVzdF90aW1lX2hwZXQoaCk7CisgICAgICAgICAg
ICBocGV0X3NldF9tYWluY291bnRlcihoKTsKICAgICAgICAgICAgIGZvciAoIGkgPSAwOyBp
IDwgSFBFVF9USU1FUl9OVU07IGkrKyApCiAgICAgICAgICAgICB7CiAgICAgICAgICAgICAg
ICAgaC0+aHBldC5jb21wYXJhdG9yNjRbaV0gPQpAQCAtMzIwLDcgKzM1Niw3IEBAIHN0YXRp
YyBpbnQgaHBldF93cml0ZSgKICAgICAgICAgZWxzZSBpZiAoIChvbGRfdmFsICYgSFBFVF9D
RkdfRU5BQkxFKSAmJiAhKG5ld192YWwgJiBIUEVUX0NGR19FTkFCTEUpICkKICAgICAgICAg
ewogICAgICAgICAgICAgLyogSGFsdCBtYWluIGNvdW50ZXIgYW5kIGRpc2FibGUgaW50ZXJy
dXB0IGdlbmVyYXRpb24uICovCi0gICAgICAgICAgICBoLT5ocGV0Lm1jNjQgPSBoLT5tY19v
ZmZzZXQgKyBndWVzdF90aW1lX2hwZXQoaCk7CisgICAgICAgICAgICBocGV0X3NldF9tYWlu
Y291bnRlcihoKTsKICAgICAgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgSFBFVF9USU1FUl9O
VU07IGkrKyApCiAgICAgICAgICAgICAgICAgaWYgKCB0aW1lcl9lbmFibGVkKGgsIGkpICkK
ICAgICAgICAgICAgICAgICAgICAgc2V0X3N0b3BfdGltZXIoaSk7CkBAIC00NzYsNyArNTEy
LDcgQEAgc3RhdGljIGludCBocGV0X3NhdmUoc3RydWN0IGRvbWFpbiAqZCwgaAogICAgIHNw
aW5fbG9jaygmaHAtPmxvY2spOwogCiAgICAgLyogV3JpdGUgdGhlIHByb3BlciB2YWx1ZSBp
bnRvIHRoZSBtYWluIGNvdW50ZXIgKi8KLSAgICBocC0+aHBldC5tYzY0ID0gaHAtPm1jX29m
ZnNldCArIGd1ZXN0X3RpbWVfaHBldChocCk7CisgICAgaHAtPmhwZXQubWM2NCA9IGhwZXRf
cmVhZF9tYWluY291bnRlcihocCk7CiAKICAgICAvKiBTYXZlIHRoZSBIUEVUIHJlZ2lzdGVy
cyAqLwogICAgIHJjID0gX2h2bV9pbml0X2VudHJ5KGgsIEhWTV9TQVZFX0NPREUoSFBFVCks
IDAsIEhWTV9TQVZFX0xFTkdUSChIUEVUKSk7CkBAIC01NTQsOCArNTkwLDcgQEAgc3RhdGlj
IGludCBocGV0X2xvYWQoc3RydWN0IGRvbWFpbiAqZCwgaAogICAgIH0KICN1bmRlZiBDCiAg
ICAgCi0gICAgLyogUmVjYWxjdWxhdGUgdGhlIG9mZnNldCBiZXR3ZWVuIHRoZSBtYWluIGNv
dW50ZXIgYW5kIGd1ZXN0IHRpbWUgKi8KLSAgICBocC0+bWNfb2Zmc2V0ID0gaHAtPmhwZXQu
bWM2NCAtIGd1ZXN0X3RpbWVfaHBldChocCk7CisgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIo
aHApOwogCiAgICAgLyogcmVzdGFydCBhbGwgdGltZXJzICovCiAKZGlmZiAtciBjZjEyOWE4
MGU0N2UgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdnB0LmgKLS0tIGEveGVuL2luY2x1ZGUv
YXNtLXg4Ni9odm0vdnB0LmgJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisrKyBi
L3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZwdC5oCVdlZCBBcHIgMTggMTA6MTM6MDcgMjAx
MiArMDEwMApAQCAtOTQsNyArOTQsMTMgQEAgdHlwZWRlZiBzdHJ1Y3QgSFBFVFN0YXRlIHsK
ICAgICB1aW50NjRfdCBzdGltZV9mcmVxOwogICAgIHVpbnQ2NF90IGhwZXRfdG9fbnNfc2Nh
bGU7IC8qIGhwZXQgdGlja3MgdG8gbnMgKG11bHRpcGxpZWQgYnkgMl4xMCkgKi8KICAgICB1
aW50NjRfdCBocGV0X3RvX25zX2xpbWl0OyAvKiBtYXggaHBldCB0aWNrcyBjb252ZXJ0YWJs
ZSB0byBucyAgICAgICovCi0gICAgdWludDY0X3QgbWNfb2Zmc2V0OworICAgIC8qCisgICAg
ICogbWNfY29uZmlnOiBBbGxvd3Mgc2FmZSBsb2NrLWZyZWUgcmVhZCBhY2Nlc3MgdG8gdGhl
IG1haW4gY291bnRlcgorICAgICAqICBiaXQgMDogc2V0IGlmIHRpbWVyIGlzIGVuYWJsZWQK
KyAgICAgKiAgMS02MzogbWFpbiBjb3VudGVyIHZhbHVlIChpZiB0aW1lciBlbmFibGVkKQor
ICAgICAqICAxLTYzOiBtYWluIGNvdW50ZXIgb2Zmc2V0IGZyb20gc3lzdGVtIHRpbWUgKGlm
IHRpbWVyIGRpc2FibGVkKQorICAgICAqLworICAgIGludDY0X3QgbWNfY29uZmlnOwogICAg
IHN0cnVjdCBwZXJpb2RpY190aW1lIHB0W0hQRVRfVElNRVJfTlVNXTsKICAgICBzcGlubG9j
a190IGxvY2s7CiB9IEhQRVRTdGF0ZTsK
--B_3417588880_251225
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3417588880_251225--




From xen-devel-bounces@lists.xen.org Wed Apr 18 09:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKQyM-0007ta-19; Wed, 18 Apr 2012 09:14:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKQyL-0007tV-6J
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 09:14:45 +0000
Received: from [85.158.143.99:31046] by server-2.bemta-4.messagelabs.com id
	6E/67-17550-4068E8F4; Wed, 18 Apr 2012 09:14:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334740483!18897058!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16165 invoked from network); 18 Apr 2012 09:14:43 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:14:43 -0000
Received: by bkwj5 with SMTP id j5so6288123bkw.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 02:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=9AEaOp075Sjvjf4SjKN6KN+jaHe6tMFf9iW/W7Z/KMs=;
	b=fy+bT5t6zLX0xQGRyuKzkJE/skiUj4w/QNglNqvguXf021x42BY1klDXR2Z4pkuLA/
	dlRiAt1jDlo8T7xGjuLLcxa/pJPFwhqcnqn28/kzw0jMBqLx/uuinXtN5J0CxOCGd/bJ
	rP7llnB7FNAlJjUSBWINNtjq/LLwJkvstaS9gMCzF3/PMxUZdP/tAE8UxfCxrbz+vQ1z
	qETqYhwf/EqZIBfzZDtY+bxij71CXRXijTPjSe2UfphxzziQ14MDuAjZTteoeL4A4bju
	zVLfyTTCcajUS1ygZOHAdgNZSTkz8m9fPKV6YauiYwH4CsUe1NfCIS2EkQcoYD594XWI
	IRww==
Received: by 10.204.156.8 with SMTP id u8mr444220bkw.36.1334740482720;
	Wed, 18 Apr 2012 02:14:42 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id gu12sm42854642bkc.1.2012.04.18.02.14.40
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 02:14:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 10:14:35 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB4448D.3E643%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IUAAZaB3A==
In-Reply-To: <CBB439E3.3E625%keir@xen.org>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3417588880_251225"
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3417588880_251225
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 18/04/2012 09:29, "Keir Fraser" <keir@xen.org> wrote:

> On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> 
>>> If the HPET accesses are atomic on bare metal, we have to maintain that,
>>> even
>>> if some guests have extra locking themselves. Also, in some cases Xen needs
>>> locking to correctly maintain its own internal state regardless of what an
>>> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
>>> everywhere. It's definitely not correct to do so. Optimising the hpet read
>>> path
>>> however, sounds okay. I agree the lock may not be needed on that specific
>>> path.
>> 
>> You are right.
>> For this case, since the main access of hpet is to read the main counter, so
>> I
>> think the rwlock is a better choice.
> 
> I'll see if I can make a patch...

Please try the attached patch (build tested only).

 -- Keir

>  -- Keir
> 
> 


--B_3417588880_251225
Content-type: application/octet-stream; name="00-hpet-lockfree"
Content-disposition: attachment;
	filename="00-hpet-lockfree"
Content-transfer-encoding: base64


ZGlmZiAtciBjZjEyOWE4MGU0N2UgeGVuL2FyY2gveDg2L2h2bS9ocGV0LmMKLS0tIGEveGVu
L2FyY2gveDg2L2h2bS9ocGV0LmMJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisr
KyBiL3hlbi9hcmNoL3g4Ni9odm0vaHBldC5jCVdlZCBBcHIgMTggMTA6MTM6MDcgMjAxMiAr
MDEwMApAQCAtNzMsMTQgKzczLDM2IEBACiAgICAgKCh0aW1lcl9jb25maWcoaCwgbikgJiBI
UEVUX1ROX0lOVF9ST1VURV9DQVBfTUFTSykgXAogICAgICAgICA+PiBIUEVUX1ROX0lOVF9S
T1VURV9DQVBfU0hJRlQpCiAKLXN0YXRpYyBpbmxpbmUgdWludDY0X3QgaHBldF9yZWFkX21h
aW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKKy8qCisgKiBocGV0X3tyZWFkLHNldH1fbWFpbmNv
dW50ZXIoKToKKyAqICBBdG9taWNhbGx5IGdldC9zZXQgaC0+bWNfY29uZmlnIHRvIGFsbG93
IHNhZmUgbG9jay1mcmVlIHJlYWQgYWNjZXNzIHRvCisgKiAgdGhlIEhQRVQgbWFpbiBjb3Vu
dGVyLiBtY19jb25maWdbMF0gaXMgMSB3aGVuIHRoZSBjb3VudGVyIGlzIGVuYWJsZWQuCisg
KiAgV2hlbiB0aGUgY291bnRlciBpcyBkaXNhYmxlZCwgbWNfY29uZmlnWzYzOjFdIGlzIHRo
ZSBjb3VudGVyIHZhbHVlLgorICogIFdoZW4gdGhlIGNvdW50ZXIgaXMgZW5hYmxlZCwgbWNf
Y29uZmlnWzYzOjFdIGlzIGEgc2lnbmVkIGNvdW50ZXIgb2Zmc2V0LgorICovCitzdGF0aWMg
dWludDY0X3QgaHBldF9yZWFkX21haW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKIHsKKyAgICBp
bnQ2NF90IG1jX2NvbmZpZyA9IHJlYWRfYXRvbWljKCZoLT5tY19jb25maWcpOworICAgIGlu
dDY0X3QgY291bnRlciA9IG1jX2NvbmZpZyA+PiAxOworICAgIGJvb2xfdCBlbmFibGVkID0g
bWNfY29uZmlnICYgMTsKKworICAgIGlmICggZW5hYmxlZCApCisgICAgICAgIGNvdW50ZXIg
Kz0gZ3Vlc3RfdGltZV9ocGV0KGgpOworCisgICAgcmV0dXJuICh1aW50NjRfdCljb3VudGVy
OworfQorCitzdGF0aWMgdm9pZCBocGV0X3NldF9tYWluY291bnRlcihIUEVUU3RhdGUgKmgp
Cit7CisgICAgaW50NjRfdCBtY19jb25maWc7CisKICAgICBBU1NFUlQoc3Bpbl9pc19sb2Nr
ZWQoJmgtPmxvY2spKTsKIAotICAgIGlmICggaHBldF9lbmFibGVkKGgpICkKLSAgICAgICAg
cmV0dXJuIGd1ZXN0X3RpbWVfaHBldChoKSArIGgtPm1jX29mZnNldDsKLSAgICBlbHNlIAot
ICAgICAgICByZXR1cm4gaC0+aHBldC5tYzY0OworICAgIG1jX2NvbmZpZyA9IChocGV0X2Vu
YWJsZWQoaCkKKyAgICAgICAgICAgICAgICAgPyAoKChoLT5ocGV0Lm1jNjQgLSBndWVzdF90
aW1lX2hwZXQoaCkpIDw8IDEpIHwgMXVsbCkKKyAgICAgICAgICAgICAgICAgOiAoaC0+aHBl
dC5tYzY0IDw8IDEpKTsKKworICAgIHdyaXRlX2F0b21pYygmaC0+bWNfY29uZmlnLCBtY19j
b25maWcpOwogfQogCiBzdGF0aWMgdWludDY0X3QgaHBldF9nZXRfY29tcGFyYXRvcihIUEVU
U3RhdGUgKmgsIHVuc2lnbmVkIGludCB0bikKQEAgLTEwNyw3ICsxMjksOCBAQCBzdGF0aWMg
dWludDY0X3QgaHBldF9nZXRfY29tcGFyYXRvcihIUEVUCiAgICAgaC0+aHBldC50aW1lcnNb
dG5dLmNtcCA9IGNvbXBhcmF0b3I7CiAgICAgcmV0dXJuIGNvbXBhcmF0b3I7CiB9Ci1zdGF0
aWMgaW5saW5lIHVpbnQ2NF90IGhwZXRfcmVhZDY0KEhQRVRTdGF0ZSAqaCwgdW5zaWduZWQg
bG9uZyBhZGRyKQorCitzdGF0aWMgdWludDY0X3QgX19ocGV0X3JlYWQ2NChIUEVUU3RhdGUg
KmgsIHVuc2lnbmVkIGxvbmcgYWRkcikKIHsKICAgICBhZGRyICY9IH43OwogCkBAIC0xMzgs
NiArMTYxLDIzIEBAIHN0YXRpYyBpbmxpbmUgdWludDY0X3QgaHBldF9yZWFkNjQoSFBFVFMK
ICAgICByZXR1cm4gMDsKIH0KIAorc3RhdGljIHVpbnQ2NF90IGhwZXRfcmVhZDY0KEhQRVRT
dGF0ZSAqaCwgdW5zaWduZWQgbG9uZyBhZGRyKQoreworICAgIC8qIEFsbG93IGxvY2stZnJl
ZSBhY2Nlc3MgdG8gbWFpbiBjb3VudGVyLiAqLworICAgIGJvb2xfdCBsb2NrID0gKChhZGRy
ICYgfjcpICE9IEhQRVRfQ09VTlRFUik7CisgICAgdWludDY0X3QgdmFsOworCisgICAgaWYg
KCBsb2NrICkKKyAgICAgICAgc3Bpbl9sb2NrKCZoLT5sb2NrKTsKKworICAgIHZhbCA9IF9f
aHBldF9yZWFkNjQoaCwgYWRkcik7CisKKyAgICBpZiAoIGxvY2sgKQorICAgICAgICBzcGlu
X3VubG9jaygmaC0+bG9jayk7CisKKyAgICByZXR1cm4gdmFsOworfQorCiBzdGF0aWMgaW5s
aW5lIGludCBocGV0X2NoZWNrX2FjY2Vzc19sZW5ndGgoCiAgICAgdW5zaWduZWQgbG9uZyBh
ZGRyLCB1bnNpZ25lZCBsb25nIGxlbikKIHsKQEAgLTE3MiwxNiArMjEyLDEyIEBAIHN0YXRp
YyBpbnQgaHBldF9yZWFkKAogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAKLSAgICBzcGlu
X2xvY2soJmgtPmxvY2spOwotCiAgICAgdmFsID0gaHBldF9yZWFkNjQoaCwgYWRkcik7CiAK
ICAgICByZXN1bHQgPSB2YWw7CiAgICAgaWYgKCBsZW5ndGggIT0gOCApCiAgICAgICAgIHJl
c3VsdCA9ICh2YWwgPj4gKChhZGRyICYgNykgKiA4KSkgJiAoKDFVTEwgPDwgKGxlbmd0aCAq
IDgpKSAtIDEpOwogCi0gICAgc3Bpbl91bmxvY2soJmgtPmxvY2spOwotCiAgb3V0OgogICAg
ICpwdmFsID0gcmVzdWx0OwogICAgIHJldHVybiBYODZFTVVMX09LQVk7CkBAIC0yOTEsNyAr
MzI3LDcgQEAgc3RhdGljIGludCBocGV0X3dyaXRlKAogCiAgICAgc3Bpbl9sb2NrKCZoLT5s
b2NrKTsKIAotICAgIG9sZF92YWwgPSBocGV0X3JlYWQ2NChoLCBhZGRyKTsKKyAgICBvbGRf
dmFsID0gX19ocGV0X3JlYWQ2NChoLCBhZGRyKTsKICAgICBuZXdfdmFsID0gdmFsOwogICAg
IGlmICggbGVuZ3RoICE9IDggKQogICAgICAgICBuZXdfdmFsID0gaHBldF9maXh1cF9yZWco
CkBAIC0zMDYsNyArMzQyLDcgQEAgc3RhdGljIGludCBocGV0X3dyaXRlKAogICAgICAgICBp
ZiAoICEob2xkX3ZhbCAmIEhQRVRfQ0ZHX0VOQUJMRSkgJiYgKG5ld192YWwgJiBIUEVUX0NG
R19FTkFCTEUpICkKICAgICAgICAgewogICAgICAgICAgICAgLyogRW5hYmxlIG1haW4gY291
bnRlciBhbmQgaW50ZXJydXB0IGdlbmVyYXRpb24uICovCi0gICAgICAgICAgICBoLT5tY19v
ZmZzZXQgPSBoLT5ocGV0Lm1jNjQgLSBndWVzdF90aW1lX2hwZXQoaCk7CisgICAgICAgICAg
ICBocGV0X3NldF9tYWluY291bnRlcihoKTsKICAgICAgICAgICAgIGZvciAoIGkgPSAwOyBp
IDwgSFBFVF9USU1FUl9OVU07IGkrKyApCiAgICAgICAgICAgICB7CiAgICAgICAgICAgICAg
ICAgaC0+aHBldC5jb21wYXJhdG9yNjRbaV0gPQpAQCAtMzIwLDcgKzM1Niw3IEBAIHN0YXRp
YyBpbnQgaHBldF93cml0ZSgKICAgICAgICAgZWxzZSBpZiAoIChvbGRfdmFsICYgSFBFVF9D
RkdfRU5BQkxFKSAmJiAhKG5ld192YWwgJiBIUEVUX0NGR19FTkFCTEUpICkKICAgICAgICAg
ewogICAgICAgICAgICAgLyogSGFsdCBtYWluIGNvdW50ZXIgYW5kIGRpc2FibGUgaW50ZXJy
dXB0IGdlbmVyYXRpb24uICovCi0gICAgICAgICAgICBoLT5ocGV0Lm1jNjQgPSBoLT5tY19v
ZmZzZXQgKyBndWVzdF90aW1lX2hwZXQoaCk7CisgICAgICAgICAgICBocGV0X3NldF9tYWlu
Y291bnRlcihoKTsKICAgICAgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgSFBFVF9USU1FUl9O
VU07IGkrKyApCiAgICAgICAgICAgICAgICAgaWYgKCB0aW1lcl9lbmFibGVkKGgsIGkpICkK
ICAgICAgICAgICAgICAgICAgICAgc2V0X3N0b3BfdGltZXIoaSk7CkBAIC00NzYsNyArNTEy
LDcgQEAgc3RhdGljIGludCBocGV0X3NhdmUoc3RydWN0IGRvbWFpbiAqZCwgaAogICAgIHNw
aW5fbG9jaygmaHAtPmxvY2spOwogCiAgICAgLyogV3JpdGUgdGhlIHByb3BlciB2YWx1ZSBp
bnRvIHRoZSBtYWluIGNvdW50ZXIgKi8KLSAgICBocC0+aHBldC5tYzY0ID0gaHAtPm1jX29m
ZnNldCArIGd1ZXN0X3RpbWVfaHBldChocCk7CisgICAgaHAtPmhwZXQubWM2NCA9IGhwZXRf
cmVhZF9tYWluY291bnRlcihocCk7CiAKICAgICAvKiBTYXZlIHRoZSBIUEVUIHJlZ2lzdGVy
cyAqLwogICAgIHJjID0gX2h2bV9pbml0X2VudHJ5KGgsIEhWTV9TQVZFX0NPREUoSFBFVCks
IDAsIEhWTV9TQVZFX0xFTkdUSChIUEVUKSk7CkBAIC01NTQsOCArNTkwLDcgQEAgc3RhdGlj
IGludCBocGV0X2xvYWQoc3RydWN0IGRvbWFpbiAqZCwgaAogICAgIH0KICN1bmRlZiBDCiAg
ICAgCi0gICAgLyogUmVjYWxjdWxhdGUgdGhlIG9mZnNldCBiZXR3ZWVuIHRoZSBtYWluIGNv
dW50ZXIgYW5kIGd1ZXN0IHRpbWUgKi8KLSAgICBocC0+bWNfb2Zmc2V0ID0gaHAtPmhwZXQu
bWM2NCAtIGd1ZXN0X3RpbWVfaHBldChocCk7CisgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIo
aHApOwogCiAgICAgLyogcmVzdGFydCBhbGwgdGltZXJzICovCiAKZGlmZiAtciBjZjEyOWE4
MGU0N2UgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdnB0LmgKLS0tIGEveGVuL2luY2x1ZGUv
YXNtLXg4Ni9odm0vdnB0LmgJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisrKyBi
L3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZwdC5oCVdlZCBBcHIgMTggMTA6MTM6MDcgMjAx
MiArMDEwMApAQCAtOTQsNyArOTQsMTMgQEAgdHlwZWRlZiBzdHJ1Y3QgSFBFVFN0YXRlIHsK
ICAgICB1aW50NjRfdCBzdGltZV9mcmVxOwogICAgIHVpbnQ2NF90IGhwZXRfdG9fbnNfc2Nh
bGU7IC8qIGhwZXQgdGlja3MgdG8gbnMgKG11bHRpcGxpZWQgYnkgMl4xMCkgKi8KICAgICB1
aW50NjRfdCBocGV0X3RvX25zX2xpbWl0OyAvKiBtYXggaHBldCB0aWNrcyBjb252ZXJ0YWJs
ZSB0byBucyAgICAgICovCi0gICAgdWludDY0X3QgbWNfb2Zmc2V0OworICAgIC8qCisgICAg
ICogbWNfY29uZmlnOiBBbGxvd3Mgc2FmZSBsb2NrLWZyZWUgcmVhZCBhY2Nlc3MgdG8gdGhl
IG1haW4gY291bnRlcgorICAgICAqICBiaXQgMDogc2V0IGlmIHRpbWVyIGlzIGVuYWJsZWQK
KyAgICAgKiAgMS02MzogbWFpbiBjb3VudGVyIHZhbHVlIChpZiB0aW1lciBlbmFibGVkKQor
ICAgICAqICAxLTYzOiBtYWluIGNvdW50ZXIgb2Zmc2V0IGZyb20gc3lzdGVtIHRpbWUgKGlm
IHRpbWVyIGRpc2FibGVkKQorICAgICAqLworICAgIGludDY0X3QgbWNfY29uZmlnOwogICAg
IHN0cnVjdCBwZXJpb2RpY190aW1lIHB0W0hQRVRfVElNRVJfTlVNXTsKICAgICBzcGlubG9j
a190IGxvY2s7CiB9IEhQRVRTdGF0ZTsK
--B_3417588880_251225
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3417588880_251225--




From xen-devel-bounces@lists.xen.org Wed Apr 18 09:25:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:25:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKR8j-00083J-9x; Wed, 18 Apr 2012 09:25:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKR8i-00083E-54
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:25:28 +0000
Received: from [85.158.139.83:15256] by server-4.bemta-5.messagelabs.com id
	27/36-10788-7888E8F4; Wed, 18 Apr 2012 09:25:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334741125!24251640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9318 invoked from network); 18 Apr 2012 09:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11996381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:25:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 10:25:24 +0100
Message-ID: <1334741123.23948.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 10:25:23 +0100
In-Reply-To: <1334677876-17704-4-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-4-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/5] libxl: call hotplug scripts from
 libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> index bbbf2a9..a41a720 100644
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -444,9 +444,10 @@ static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
>  static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
>  {
>      int domid;
> -    if ( !PyArg_ParseTuple(args, "i", &domid) )
> +    const libxl_asyncop_how *ao_how;
> +    if ( !PyArg_ParseTuple(args, "ii", &domid, &ao_how) )
>          return NULL;
> -    if ( libxl_domain_destroy(self->ctx, domid) ) {
> +    if ( libxl_domain_destroy(self->ctx, domid, ao_how) ) {

Without a bunch more infrastructure to allow python to create and
managed ao_how and callbacks etc there's not really much point in this
and you might as well just declare that the python bindings as
synchronous (i.e. pass NULL here).

Otherwise the poatch looks good:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

>          PyErr_SetString(xl_error_obj, "cannot destroy domain");
>          return NULL;
>      }
> --
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 09:25:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:25:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKR8j-00083J-9x; Wed, 18 Apr 2012 09:25:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKR8i-00083E-54
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:25:28 +0000
Received: from [85.158.139.83:15256] by server-4.bemta-5.messagelabs.com id
	27/36-10788-7888E8F4; Wed, 18 Apr 2012 09:25:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334741125!24251640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9318 invoked from network); 18 Apr 2012 09:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11996381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:25:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 10:25:24 +0100
Message-ID: <1334741123.23948.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 10:25:23 +0100
In-Reply-To: <1334677876-17704-4-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-4-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/5] libxl: call hotplug scripts from
 libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> index bbbf2a9..a41a720 100644
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -444,9 +444,10 @@ static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
>  static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
>  {
>      int domid;
> -    if ( !PyArg_ParseTuple(args, "i", &domid) )
> +    const libxl_asyncop_how *ao_how;
> +    if ( !PyArg_ParseTuple(args, "ii", &domid, &ao_how) )
>          return NULL;
> -    if ( libxl_domain_destroy(self->ctx, domid) ) {
> +    if ( libxl_domain_destroy(self->ctx, domid, ao_how) ) {

Without a bunch more infrastructure to allow python to create and
managed ao_how and callbacks etc there's not really much point in this
and you might as well just declare that the python bindings as
synchronous (i.e. pass NULL here).

Otherwise the poatch looks good:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

>          PyErr_SetString(xl_error_obj, "cannot destroy domain");
>          return NULL;
>      }
> --
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 09:31:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRE7-0008Il-P6; Wed, 18 Apr 2012 09:31:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKRE6-0008Id-F5
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 09:31:02 +0000
Received: from [193.109.254.147:33123] by server-6.bemta-14.messagelabs.com id
	19/3E-02047-5D98E8F4; Wed, 18 Apr 2012 09:31:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334741455!5148577!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16462 invoked from network); 18 Apr 2012 09:30:56 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:30:56 -0000
Received: by bkwj5 with SMTP id j5so6303701bkw.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 02:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=/A9yvVHTpH5rcN42bfe1XzBqVU76zQTC5JkhOsUarWc=;
	b=YWZEgibRCV7OjW6or1MEPIDcwuj5hZWX0qQDN6i7KVqW9+sup73Xy9yMRmH0SZVc8m
	5oZp8YSBVUey+df5bCYbebtMhBekIxyakonMOHAFWDmTU/6Xzlkqe+rqVR8i9Cj46dBz
	qBgYnDpx/tJuywrlyIAgZXrRt/dxevSUlW7ihKnbomFI4VP1JmyLvUm4x5QoYHFxqQnZ
	rL8DeKXxczWsk+48IF6UUIM0uCuXlVl+ShU6NL4K8X9nuLmCQl+VqNjR3mSmHnOuVN2z
	Rvg1lFCMV3+Nm8AdVAfGKT6IY19n8nFiBkl+sLerm+HzhQj/rzHt/tzgBNNNmyzkjVmj
	GyLQ==
Received: by 10.204.153.204 with SMTP id l12mr458653bkw.49.1334741455123;
	Wed, 18 Apr 2012 02:30:55 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id s16sm42950374bkt.3.2012.04.18.02.30.53
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 02:30:54 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 10:30:48 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB44859.3E648%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IUAAZaB3AAAkP3h
In-Reply-To: <CBB4448D.3E643%keir@xen.org>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3417589853_316961"
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3417589853_316961
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 18/04/2012 10:14, "Keir Fraser" <keir@xen.org> wrote:

> On 18/04/2012 09:29, "Keir Fraser" <keir@xen.org> wrote:
> 
>> On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
>> 
>>>> If the HPET accesses are atomic on bare metal, we have to maintain that,
>>>> even
>>>> if some guests have extra locking themselves. Also, in some cases Xen needs
>>>> locking to correctly maintain its own internal state regardless of what an
>>>> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
>>>> everywhere. It's definitely not correct to do so. Optimising the hpet read
>>>> path
>>>> however, sounds okay. I agree the lock may not be needed on that specific
>>>> path.
>>> 
>>> You are right.
>>> For this case, since the main access of hpet is to read the main counter, so
>>> I
>>> think the rwlock is a better choice.
>> 
>> I'll see if I can make a patch...
> 
> Please try the attached patch (build tested only).

Actually try this updated one. :-)

>  -- Keir
> 
>>  -- Keir
>> 
>> 
> 


--B_3417589853_316961
Content-type: application/octet-stream; name="00-hpet-lockfree-v2"
Content-disposition: attachment;
	filename="00-hpet-lockfree-v2"
Content-transfer-encoding: base64


ZGlmZiAtciBjZjEyOWE4MGU0N2UgeGVuL2FyY2gveDg2L2h2bS9ocGV0LmMKLS0tIGEveGVu
L2FyY2gveDg2L2h2bS9ocGV0LmMJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisr
KyBiL3hlbi9hcmNoL3g4Ni9odm0vaHBldC5jCVdlZCBBcHIgMTggMTA6Mjk6MjggMjAxMiAr
MDEwMApAQCAtNzMsMTQgKzczLDM2IEBACiAgICAgKCh0aW1lcl9jb25maWcoaCwgbikgJiBI
UEVUX1ROX0lOVF9ST1VURV9DQVBfTUFTSykgXAogICAgICAgICA+PiBIUEVUX1ROX0lOVF9S
T1VURV9DQVBfU0hJRlQpCiAKLXN0YXRpYyBpbmxpbmUgdWludDY0X3QgaHBldF9yZWFkX21h
aW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKKy8qCisgKiBocGV0X3tyZWFkLHNldH1fbWFpbmNv
dW50ZXIoKToKKyAqICBBdG9taWNhbGx5IGdldC9zZXQgaC0+bWNfY29uZmlnIHRvIGFsbG93
IHNhZmUgbG9jay1mcmVlIHJlYWQgYWNjZXNzIHRvCisgKiAgdGhlIEhQRVQgbWFpbiBjb3Vu
dGVyLiBtY19jb25maWdbMF0gaXMgMSB3aGVuIHRoZSBjb3VudGVyIGlzIGVuYWJsZWQuCisg
KiAgV2hlbiB0aGUgY291bnRlciBpcyBkaXNhYmxlZCwgbWNfY29uZmlnWzYzOjFdIGlzIHRo
ZSBjb3VudGVyIHZhbHVlLgorICogIFdoZW4gdGhlIGNvdW50ZXIgaXMgZW5hYmxlZCwgbWNf
Y29uZmlnWzYzOjFdIGlzIGEgc2lnbmVkIGNvdW50ZXIgb2Zmc2V0LgorICovCitzdGF0aWMg
dWludDY0X3QgaHBldF9yZWFkX21haW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKIHsKKyAgICBp
bnQ2NF90IG1jX2NvbmZpZyA9IHJlYWRfYXRvbWljKCZoLT5tY19jb25maWcpOworICAgIGlu
dDY0X3QgY291bnRlciA9IG1jX2NvbmZpZyA+PiAxOworICAgIGJvb2xfdCBlbmFibGVkID0g
bWNfY29uZmlnICYgMTsKKworICAgIGlmICggZW5hYmxlZCApCisgICAgICAgIGNvdW50ZXIg
Kz0gZ3Vlc3RfdGltZV9ocGV0KGgpOworCisgICAgcmV0dXJuICh1aW50NjRfdCljb3VudGVy
OworfQorCitzdGF0aWMgdm9pZCBocGV0X3NldF9tYWluY291bnRlcihIUEVUU3RhdGUgKmgs
IHVpbnQ2NF90IG1jKQoreworICAgIGludDY0X3QgbWNfY29uZmlnOworCiAgICAgQVNTRVJU
KHNwaW5faXNfbG9ja2VkKCZoLT5sb2NrKSk7CiAKLSAgICBpZiAoIGhwZXRfZW5hYmxlZCho
KSApCi0gICAgICAgIHJldHVybiBndWVzdF90aW1lX2hwZXQoaCkgKyBoLT5tY19vZmZzZXQ7
Ci0gICAgZWxzZSAKLSAgICAgICAgcmV0dXJuIGgtPmhwZXQubWM2NDsKKyAgICBtY19jb25m
aWcgPSAoaHBldF9lbmFibGVkKGgpCisgICAgICAgICAgICAgICAgID8gKCgobWMgLSBndWVz
dF90aW1lX2hwZXQoaCkpIDw8IDEpIHwgMXVsbCkKKyAgICAgICAgICAgICAgICAgOiAobWMg
PDwgMSkpOworCisgICAgd3JpdGVfYXRvbWljKCZoLT5tY19jb25maWcsIG1jX2NvbmZpZyk7
CiB9CiAKIHN0YXRpYyB1aW50NjRfdCBocGV0X2dldF9jb21wYXJhdG9yKEhQRVRTdGF0ZSAq
aCwgdW5zaWduZWQgaW50IHRuKQpAQCAtMTA3LDcgKzEyOSw4IEBAIHN0YXRpYyB1aW50NjRf
dCBocGV0X2dldF9jb21wYXJhdG9yKEhQRVQKICAgICBoLT5ocGV0LnRpbWVyc1t0bl0uY21w
ID0gY29tcGFyYXRvcjsKICAgICByZXR1cm4gY29tcGFyYXRvcjsKIH0KLXN0YXRpYyBpbmxp
bmUgdWludDY0X3QgaHBldF9yZWFkNjQoSFBFVFN0YXRlICpoLCB1bnNpZ25lZCBsb25nIGFk
ZHIpCisKK3N0YXRpYyB1aW50NjRfdCBfX2hwZXRfcmVhZDY0KEhQRVRTdGF0ZSAqaCwgdW5z
aWduZWQgbG9uZyBhZGRyKQogewogICAgIGFkZHIgJj0gfjc7CiAKQEAgLTEzOCw2ICsxNjEs
MjMgQEAgc3RhdGljIGlubGluZSB1aW50NjRfdCBocGV0X3JlYWQ2NChIUEVUUwogICAgIHJl
dHVybiAwOwogfQogCitzdGF0aWMgdWludDY0X3QgaHBldF9yZWFkNjQoSFBFVFN0YXRlICpo
LCB1bnNpZ25lZCBsb25nIGFkZHIpCit7CisgICAgLyogQWxsb3cgbG9jay1mcmVlIGFjY2Vz
cyB0byBtYWluIGNvdW50ZXIuICovCisgICAgYm9vbF90IGxvY2sgPSAoKGFkZHIgJiB+Nykg
IT0gSFBFVF9DT1VOVEVSKTsKKyAgICB1aW50NjRfdCB2YWw7CisKKyAgICBpZiAoIGxvY2sg
KQorICAgICAgICBzcGluX2xvY2soJmgtPmxvY2spOworCisgICAgdmFsID0gX19ocGV0X3Jl
YWQ2NChoLCBhZGRyKTsKKworICAgIGlmICggbG9jayApCisgICAgICAgIHNwaW5fdW5sb2Nr
KCZoLT5sb2NrKTsKKworICAgIHJldHVybiB2YWw7Cit9CisKIHN0YXRpYyBpbmxpbmUgaW50
IGhwZXRfY2hlY2tfYWNjZXNzX2xlbmd0aCgKICAgICB1bnNpZ25lZCBsb25nIGFkZHIsIHVu
c2lnbmVkIGxvbmcgbGVuKQogewpAQCAtMTcyLDE2ICsyMTIsMTIgQEAgc3RhdGljIGludCBo
cGV0X3JlYWQoCiAgICAgICAgIGdvdG8gb3V0OwogICAgIH0KIAotICAgIHNwaW5fbG9jaygm
aC0+bG9jayk7Ci0KICAgICB2YWwgPSBocGV0X3JlYWQ2NChoLCBhZGRyKTsKIAogICAgIHJl
c3VsdCA9IHZhbDsKICAgICBpZiAoIGxlbmd0aCAhPSA4ICkKICAgICAgICAgcmVzdWx0ID0g
KHZhbCA+PiAoKGFkZHIgJiA3KSAqIDgpKSAmICgoMVVMTCA8PCAobGVuZ3RoICogOCkpIC0g
MSk7CiAKLSAgICBzcGluX3VubG9jaygmaC0+bG9jayk7Ci0KICBvdXQ6CiAgICAgKnB2YWwg
PSByZXN1bHQ7CiAgICAgcmV0dXJuIFg4NkVNVUxfT0tBWTsKQEAgLTI5MSw3ICszMjcsNyBA
QCBzdGF0aWMgaW50IGhwZXRfd3JpdGUoCiAKICAgICBzcGluX2xvY2soJmgtPmxvY2spOwog
Ci0gICAgb2xkX3ZhbCA9IGhwZXRfcmVhZDY0KGgsIGFkZHIpOworICAgIG9sZF92YWwgPSBf
X2hwZXRfcmVhZDY0KGgsIGFkZHIpOwogICAgIG5ld192YWwgPSB2YWw7CiAgICAgaWYgKCBs
ZW5ndGggIT0gOCApCiAgICAgICAgIG5ld192YWwgPSBocGV0X2ZpeHVwX3JlZygKQEAgLTMw
MCwxMyArMzM2LDE1IEBAIHN0YXRpYyBpbnQgaHBldF93cml0ZSgKIAogICAgIHN3aXRjaCAo
IGFkZHIgJiB+NyApCiAgICAgewotICAgIGNhc2UgSFBFVF9DRkc6CisgICAgY2FzZSBIUEVU
X0NGRzogeworICAgICAgICB1aW50NjRfdCBtYyA9IGhwZXRfcmVhZF9tYWluY291bnRlciho
KTsKKwogICAgICAgICBoLT5ocGV0LmNvbmZpZyA9IGhwZXRfZml4dXBfcmVnKG5ld192YWws
IG9sZF92YWwsIDB4Myk7CiAKICAgICAgICAgaWYgKCAhKG9sZF92YWwgJiBIUEVUX0NGR19F
TkFCTEUpICYmIChuZXdfdmFsICYgSFBFVF9DRkdfRU5BQkxFKSApCiAgICAgICAgIHsKICAg
ICAgICAgICAgIC8qIEVuYWJsZSBtYWluIGNvdW50ZXIgYW5kIGludGVycnVwdCBnZW5lcmF0
aW9uLiAqLwotICAgICAgICAgICAgaC0+bWNfb2Zmc2V0ID0gaC0+aHBldC5tYzY0IC0gZ3Vl
c3RfdGltZV9ocGV0KGgpOworICAgICAgICAgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaCwg
bWMpOwogICAgICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBIUEVUX1RJTUVSX05VTTsgaSsr
ICkKICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICBoLT5ocGV0LmNvbXBhcmF0b3I2
NFtpXSA9CkBAIC0zMjAsMTUgKzM1OCwxNiBAQCBzdGF0aWMgaW50IGhwZXRfd3JpdGUoCiAg
ICAgICAgIGVsc2UgaWYgKCAob2xkX3ZhbCAmIEhQRVRfQ0ZHX0VOQUJMRSkgJiYgIShuZXdf
dmFsICYgSFBFVF9DRkdfRU5BQkxFKSApCiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIEhh
bHQgbWFpbiBjb3VudGVyIGFuZCBkaXNhYmxlIGludGVycnVwdCBnZW5lcmF0aW9uLiAqLwot
ICAgICAgICAgICAgaC0+aHBldC5tYzY0ID0gaC0+bWNfb2Zmc2V0ICsgZ3Vlc3RfdGltZV9o
cGV0KGgpOworICAgICAgICAgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaCwgbWMpOwogICAg
ICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBIUEVUX1RJTUVSX05VTTsgaSsrICkKICAgICAg
ICAgICAgICAgICBpZiAoIHRpbWVyX2VuYWJsZWQoaCwgaSkgKQogICAgICAgICAgICAgICAg
ICAgICBzZXRfc3RvcF90aW1lcihpKTsKICAgICAgICAgfQogICAgICAgICBicmVhazsKKyAg
ICB9CiAKICAgICBjYXNlIEhQRVRfQ09VTlRFUjoKLSAgICAgICAgaC0+aHBldC5tYzY0ID0g
bmV3X3ZhbDsKKyAgICAgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaCwgbmV3X3ZhbCk7CiAg
ICAgICAgIGlmICggaHBldF9lbmFibGVkKGgpICkKICAgICAgICAgewogICAgICAgICAgICAg
Z2RwcmludGsoWEVOTE9HX1dBUk5JTkcsIApAQCAtNDc1LDggKzUxNCw3IEBAIHN0YXRpYyBp
bnQgaHBldF9zYXZlKHN0cnVjdCBkb21haW4gKmQsIGgKIAogICAgIHNwaW5fbG9jaygmaHAt
PmxvY2spOwogCi0gICAgLyogV3JpdGUgdGhlIHByb3BlciB2YWx1ZSBpbnRvIHRoZSBtYWlu
IGNvdW50ZXIgKi8KLSAgICBocC0+aHBldC5tYzY0ID0gaHAtPm1jX29mZnNldCArIGd1ZXN0
X3RpbWVfaHBldChocCk7CisgICAgaHAtPmhwZXQubWM2NCA9IGhwZXRfcmVhZF9tYWluY291
bnRlcihocCk7CiAKICAgICAvKiBTYXZlIHRoZSBIUEVUIHJlZ2lzdGVycyAqLwogICAgIHJj
ID0gX2h2bV9pbml0X2VudHJ5KGgsIEhWTV9TQVZFX0NPREUoSFBFVCksIDAsIEhWTV9TQVZF
X0xFTkdUSChIUEVUKSk7CkBAIC01NTQsOCArNTkyLDcgQEAgc3RhdGljIGludCBocGV0X2xv
YWQoc3RydWN0IGRvbWFpbiAqZCwgaAogICAgIH0KICN1bmRlZiBDCiAgICAgCi0gICAgLyog
UmVjYWxjdWxhdGUgdGhlIG9mZnNldCBiZXR3ZWVuIHRoZSBtYWluIGNvdW50ZXIgYW5kIGd1
ZXN0IHRpbWUgKi8KLSAgICBocC0+bWNfb2Zmc2V0ID0gaHAtPmhwZXQubWM2NCAtIGd1ZXN0
X3RpbWVfaHBldChocCk7CisgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaHAsIGhwLT5ocGV0
Lm1jNjQpOwogCiAgICAgLyogcmVzdGFydCBhbGwgdGltZXJzICovCiAKZGlmZiAtciBjZjEy
OWE4MGU0N2UgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdnB0LmgKLS0tIGEveGVuL2luY2x1
ZGUvYXNtLXg4Ni9odm0vdnB0LmgJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisr
KyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZwdC5oCVdlZCBBcHIgMTggMTA6Mjk6Mjgg
MjAxMiArMDEwMApAQCAtOTQsNyArOTQsMTMgQEAgdHlwZWRlZiBzdHJ1Y3QgSFBFVFN0YXRl
IHsKICAgICB1aW50NjRfdCBzdGltZV9mcmVxOwogICAgIHVpbnQ2NF90IGhwZXRfdG9fbnNf
c2NhbGU7IC8qIGhwZXQgdGlja3MgdG8gbnMgKG11bHRpcGxpZWQgYnkgMl4xMCkgKi8KICAg
ICB1aW50NjRfdCBocGV0X3RvX25zX2xpbWl0OyAvKiBtYXggaHBldCB0aWNrcyBjb252ZXJ0
YWJsZSB0byBucyAgICAgICovCi0gICAgdWludDY0X3QgbWNfb2Zmc2V0OworICAgIC8qCisg
ICAgICogbWNfY29uZmlnOiBBbGxvd3Mgc2FmZSBsb2NrLWZyZWUgcmVhZCBhY2Nlc3MgdG8g
dGhlIG1haW4gY291bnRlcgorICAgICAqICBiaXQgMDogc2V0IGlmIHRpbWVyIGlzIGVuYWJs
ZWQKKyAgICAgKiAgMS02MzogbWFpbiBjb3VudGVyIHZhbHVlIChpZiB0aW1lciBlbmFibGVk
KQorICAgICAqICAxLTYzOiBtYWluIGNvdW50ZXIgb2Zmc2V0IGZyb20gc3lzdGVtIHRpbWUg
KGlmIHRpbWVyIGRpc2FibGVkKQorICAgICAqLworICAgIGludDY0X3QgbWNfY29uZmlnOwog
ICAgIHN0cnVjdCBwZXJpb2RpY190aW1lIHB0W0hQRVRfVElNRVJfTlVNXTsKICAgICBzcGlu
bG9ja190IGxvY2s7CiB9IEhQRVRTdGF0ZTsK
--B_3417589853_316961
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3417589853_316961--




From xen-devel-bounces@lists.xen.org Wed Apr 18 09:31:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRE7-0008Il-P6; Wed, 18 Apr 2012 09:31:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKRE6-0008Id-F5
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 09:31:02 +0000
Received: from [193.109.254.147:33123] by server-6.bemta-14.messagelabs.com id
	19/3E-02047-5D98E8F4; Wed, 18 Apr 2012 09:31:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334741455!5148577!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16462 invoked from network); 18 Apr 2012 09:30:56 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:30:56 -0000
Received: by bkwj5 with SMTP id j5so6303701bkw.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 02:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=/A9yvVHTpH5rcN42bfe1XzBqVU76zQTC5JkhOsUarWc=;
	b=YWZEgibRCV7OjW6or1MEPIDcwuj5hZWX0qQDN6i7KVqW9+sup73Xy9yMRmH0SZVc8m
	5oZp8YSBVUey+df5bCYbebtMhBekIxyakonMOHAFWDmTU/6Xzlkqe+rqVR8i9Cj46dBz
	qBgYnDpx/tJuywrlyIAgZXrRt/dxevSUlW7ihKnbomFI4VP1JmyLvUm4x5QoYHFxqQnZ
	rL8DeKXxczWsk+48IF6UUIM0uCuXlVl+ShU6NL4K8X9nuLmCQl+VqNjR3mSmHnOuVN2z
	Rvg1lFCMV3+Nm8AdVAfGKT6IY19n8nFiBkl+sLerm+HzhQj/rzHt/tzgBNNNmyzkjVmj
	GyLQ==
Received: by 10.204.153.204 with SMTP id l12mr458653bkw.49.1334741455123;
	Wed, 18 Apr 2012 02:30:55 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id s16sm42950374bkt.3.2012.04.18.02.30.53
	(version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 02:30:54 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Apr 2012 10:30:48 +0100
From: Keir Fraser <keir@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CBB44859.3E648%keir@xen.org>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IUAAZaB3AAAkP3h
In-Reply-To: <CBB4448D.3E643%keir@xen.org>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3417589853_316961"
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3417589853_316961
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 18/04/2012 10:14, "Keir Fraser" <keir@xen.org> wrote:

> On 18/04/2012 09:29, "Keir Fraser" <keir@xen.org> wrote:
> 
>> On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
>> 
>>>> If the HPET accesses are atomic on bare metal, we have to maintain that,
>>>> even
>>>> if some guests have extra locking themselves. Also, in some cases Xen needs
>>>> locking to correctly maintain its own internal state regardless of what an
>>>> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
>>>> everywhere. It's definitely not correct to do so. Optimising the hpet read
>>>> path
>>>> however, sounds okay. I agree the lock may not be needed on that specific
>>>> path.
>>> 
>>> You are right.
>>> For this case, since the main access of hpet is to read the main counter, so
>>> I
>>> think the rwlock is a better choice.
>> 
>> I'll see if I can make a patch...
> 
> Please try the attached patch (build tested only).

Actually try this updated one. :-)

>  -- Keir
> 
>>  -- Keir
>> 
>> 
> 


--B_3417589853_316961
Content-type: application/octet-stream; name="00-hpet-lockfree-v2"
Content-disposition: attachment;
	filename="00-hpet-lockfree-v2"
Content-transfer-encoding: base64


ZGlmZiAtciBjZjEyOWE4MGU0N2UgeGVuL2FyY2gveDg2L2h2bS9ocGV0LmMKLS0tIGEveGVu
L2FyY2gveDg2L2h2bS9ocGV0LmMJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisr
KyBiL3hlbi9hcmNoL3g4Ni9odm0vaHBldC5jCVdlZCBBcHIgMTggMTA6Mjk6MjggMjAxMiAr
MDEwMApAQCAtNzMsMTQgKzczLDM2IEBACiAgICAgKCh0aW1lcl9jb25maWcoaCwgbikgJiBI
UEVUX1ROX0lOVF9ST1VURV9DQVBfTUFTSykgXAogICAgICAgICA+PiBIUEVUX1ROX0lOVF9S
T1VURV9DQVBfU0hJRlQpCiAKLXN0YXRpYyBpbmxpbmUgdWludDY0X3QgaHBldF9yZWFkX21h
aW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKKy8qCisgKiBocGV0X3tyZWFkLHNldH1fbWFpbmNv
dW50ZXIoKToKKyAqICBBdG9taWNhbGx5IGdldC9zZXQgaC0+bWNfY29uZmlnIHRvIGFsbG93
IHNhZmUgbG9jay1mcmVlIHJlYWQgYWNjZXNzIHRvCisgKiAgdGhlIEhQRVQgbWFpbiBjb3Vu
dGVyLiBtY19jb25maWdbMF0gaXMgMSB3aGVuIHRoZSBjb3VudGVyIGlzIGVuYWJsZWQuCisg
KiAgV2hlbiB0aGUgY291bnRlciBpcyBkaXNhYmxlZCwgbWNfY29uZmlnWzYzOjFdIGlzIHRo
ZSBjb3VudGVyIHZhbHVlLgorICogIFdoZW4gdGhlIGNvdW50ZXIgaXMgZW5hYmxlZCwgbWNf
Y29uZmlnWzYzOjFdIGlzIGEgc2lnbmVkIGNvdW50ZXIgb2Zmc2V0LgorICovCitzdGF0aWMg
dWludDY0X3QgaHBldF9yZWFkX21haW5jb3VudGVyKEhQRVRTdGF0ZSAqaCkKIHsKKyAgICBp
bnQ2NF90IG1jX2NvbmZpZyA9IHJlYWRfYXRvbWljKCZoLT5tY19jb25maWcpOworICAgIGlu
dDY0X3QgY291bnRlciA9IG1jX2NvbmZpZyA+PiAxOworICAgIGJvb2xfdCBlbmFibGVkID0g
bWNfY29uZmlnICYgMTsKKworICAgIGlmICggZW5hYmxlZCApCisgICAgICAgIGNvdW50ZXIg
Kz0gZ3Vlc3RfdGltZV9ocGV0KGgpOworCisgICAgcmV0dXJuICh1aW50NjRfdCljb3VudGVy
OworfQorCitzdGF0aWMgdm9pZCBocGV0X3NldF9tYWluY291bnRlcihIUEVUU3RhdGUgKmgs
IHVpbnQ2NF90IG1jKQoreworICAgIGludDY0X3QgbWNfY29uZmlnOworCiAgICAgQVNTRVJU
KHNwaW5faXNfbG9ja2VkKCZoLT5sb2NrKSk7CiAKLSAgICBpZiAoIGhwZXRfZW5hYmxlZCho
KSApCi0gICAgICAgIHJldHVybiBndWVzdF90aW1lX2hwZXQoaCkgKyBoLT5tY19vZmZzZXQ7
Ci0gICAgZWxzZSAKLSAgICAgICAgcmV0dXJuIGgtPmhwZXQubWM2NDsKKyAgICBtY19jb25m
aWcgPSAoaHBldF9lbmFibGVkKGgpCisgICAgICAgICAgICAgICAgID8gKCgobWMgLSBndWVz
dF90aW1lX2hwZXQoaCkpIDw8IDEpIHwgMXVsbCkKKyAgICAgICAgICAgICAgICAgOiAobWMg
PDwgMSkpOworCisgICAgd3JpdGVfYXRvbWljKCZoLT5tY19jb25maWcsIG1jX2NvbmZpZyk7
CiB9CiAKIHN0YXRpYyB1aW50NjRfdCBocGV0X2dldF9jb21wYXJhdG9yKEhQRVRTdGF0ZSAq
aCwgdW5zaWduZWQgaW50IHRuKQpAQCAtMTA3LDcgKzEyOSw4IEBAIHN0YXRpYyB1aW50NjRf
dCBocGV0X2dldF9jb21wYXJhdG9yKEhQRVQKICAgICBoLT5ocGV0LnRpbWVyc1t0bl0uY21w
ID0gY29tcGFyYXRvcjsKICAgICByZXR1cm4gY29tcGFyYXRvcjsKIH0KLXN0YXRpYyBpbmxp
bmUgdWludDY0X3QgaHBldF9yZWFkNjQoSFBFVFN0YXRlICpoLCB1bnNpZ25lZCBsb25nIGFk
ZHIpCisKK3N0YXRpYyB1aW50NjRfdCBfX2hwZXRfcmVhZDY0KEhQRVRTdGF0ZSAqaCwgdW5z
aWduZWQgbG9uZyBhZGRyKQogewogICAgIGFkZHIgJj0gfjc7CiAKQEAgLTEzOCw2ICsxNjEs
MjMgQEAgc3RhdGljIGlubGluZSB1aW50NjRfdCBocGV0X3JlYWQ2NChIUEVUUwogICAgIHJl
dHVybiAwOwogfQogCitzdGF0aWMgdWludDY0X3QgaHBldF9yZWFkNjQoSFBFVFN0YXRlICpo
LCB1bnNpZ25lZCBsb25nIGFkZHIpCit7CisgICAgLyogQWxsb3cgbG9jay1mcmVlIGFjY2Vz
cyB0byBtYWluIGNvdW50ZXIuICovCisgICAgYm9vbF90IGxvY2sgPSAoKGFkZHIgJiB+Nykg
IT0gSFBFVF9DT1VOVEVSKTsKKyAgICB1aW50NjRfdCB2YWw7CisKKyAgICBpZiAoIGxvY2sg
KQorICAgICAgICBzcGluX2xvY2soJmgtPmxvY2spOworCisgICAgdmFsID0gX19ocGV0X3Jl
YWQ2NChoLCBhZGRyKTsKKworICAgIGlmICggbG9jayApCisgICAgICAgIHNwaW5fdW5sb2Nr
KCZoLT5sb2NrKTsKKworICAgIHJldHVybiB2YWw7Cit9CisKIHN0YXRpYyBpbmxpbmUgaW50
IGhwZXRfY2hlY2tfYWNjZXNzX2xlbmd0aCgKICAgICB1bnNpZ25lZCBsb25nIGFkZHIsIHVu
c2lnbmVkIGxvbmcgbGVuKQogewpAQCAtMTcyLDE2ICsyMTIsMTIgQEAgc3RhdGljIGludCBo
cGV0X3JlYWQoCiAgICAgICAgIGdvdG8gb3V0OwogICAgIH0KIAotICAgIHNwaW5fbG9jaygm
aC0+bG9jayk7Ci0KICAgICB2YWwgPSBocGV0X3JlYWQ2NChoLCBhZGRyKTsKIAogICAgIHJl
c3VsdCA9IHZhbDsKICAgICBpZiAoIGxlbmd0aCAhPSA4ICkKICAgICAgICAgcmVzdWx0ID0g
KHZhbCA+PiAoKGFkZHIgJiA3KSAqIDgpKSAmICgoMVVMTCA8PCAobGVuZ3RoICogOCkpIC0g
MSk7CiAKLSAgICBzcGluX3VubG9jaygmaC0+bG9jayk7Ci0KICBvdXQ6CiAgICAgKnB2YWwg
PSByZXN1bHQ7CiAgICAgcmV0dXJuIFg4NkVNVUxfT0tBWTsKQEAgLTI5MSw3ICszMjcsNyBA
QCBzdGF0aWMgaW50IGhwZXRfd3JpdGUoCiAKICAgICBzcGluX2xvY2soJmgtPmxvY2spOwog
Ci0gICAgb2xkX3ZhbCA9IGhwZXRfcmVhZDY0KGgsIGFkZHIpOworICAgIG9sZF92YWwgPSBf
X2hwZXRfcmVhZDY0KGgsIGFkZHIpOwogICAgIG5ld192YWwgPSB2YWw7CiAgICAgaWYgKCBs
ZW5ndGggIT0gOCApCiAgICAgICAgIG5ld192YWwgPSBocGV0X2ZpeHVwX3JlZygKQEAgLTMw
MCwxMyArMzM2LDE1IEBAIHN0YXRpYyBpbnQgaHBldF93cml0ZSgKIAogICAgIHN3aXRjaCAo
IGFkZHIgJiB+NyApCiAgICAgewotICAgIGNhc2UgSFBFVF9DRkc6CisgICAgY2FzZSBIUEVU
X0NGRzogeworICAgICAgICB1aW50NjRfdCBtYyA9IGhwZXRfcmVhZF9tYWluY291bnRlciho
KTsKKwogICAgICAgICBoLT5ocGV0LmNvbmZpZyA9IGhwZXRfZml4dXBfcmVnKG5ld192YWws
IG9sZF92YWwsIDB4Myk7CiAKICAgICAgICAgaWYgKCAhKG9sZF92YWwgJiBIUEVUX0NGR19F
TkFCTEUpICYmIChuZXdfdmFsICYgSFBFVF9DRkdfRU5BQkxFKSApCiAgICAgICAgIHsKICAg
ICAgICAgICAgIC8qIEVuYWJsZSBtYWluIGNvdW50ZXIgYW5kIGludGVycnVwdCBnZW5lcmF0
aW9uLiAqLwotICAgICAgICAgICAgaC0+bWNfb2Zmc2V0ID0gaC0+aHBldC5tYzY0IC0gZ3Vl
c3RfdGltZV9ocGV0KGgpOworICAgICAgICAgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaCwg
bWMpOwogICAgICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBIUEVUX1RJTUVSX05VTTsgaSsr
ICkKICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICBoLT5ocGV0LmNvbXBhcmF0b3I2
NFtpXSA9CkBAIC0zMjAsMTUgKzM1OCwxNiBAQCBzdGF0aWMgaW50IGhwZXRfd3JpdGUoCiAg
ICAgICAgIGVsc2UgaWYgKCAob2xkX3ZhbCAmIEhQRVRfQ0ZHX0VOQUJMRSkgJiYgIShuZXdf
dmFsICYgSFBFVF9DRkdfRU5BQkxFKSApCiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIEhh
bHQgbWFpbiBjb3VudGVyIGFuZCBkaXNhYmxlIGludGVycnVwdCBnZW5lcmF0aW9uLiAqLwot
ICAgICAgICAgICAgaC0+aHBldC5tYzY0ID0gaC0+bWNfb2Zmc2V0ICsgZ3Vlc3RfdGltZV9o
cGV0KGgpOworICAgICAgICAgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaCwgbWMpOwogICAg
ICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBIUEVUX1RJTUVSX05VTTsgaSsrICkKICAgICAg
ICAgICAgICAgICBpZiAoIHRpbWVyX2VuYWJsZWQoaCwgaSkgKQogICAgICAgICAgICAgICAg
ICAgICBzZXRfc3RvcF90aW1lcihpKTsKICAgICAgICAgfQogICAgICAgICBicmVhazsKKyAg
ICB9CiAKICAgICBjYXNlIEhQRVRfQ09VTlRFUjoKLSAgICAgICAgaC0+aHBldC5tYzY0ID0g
bmV3X3ZhbDsKKyAgICAgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaCwgbmV3X3ZhbCk7CiAg
ICAgICAgIGlmICggaHBldF9lbmFibGVkKGgpICkKICAgICAgICAgewogICAgICAgICAgICAg
Z2RwcmludGsoWEVOTE9HX1dBUk5JTkcsIApAQCAtNDc1LDggKzUxNCw3IEBAIHN0YXRpYyBp
bnQgaHBldF9zYXZlKHN0cnVjdCBkb21haW4gKmQsIGgKIAogICAgIHNwaW5fbG9jaygmaHAt
PmxvY2spOwogCi0gICAgLyogV3JpdGUgdGhlIHByb3BlciB2YWx1ZSBpbnRvIHRoZSBtYWlu
IGNvdW50ZXIgKi8KLSAgICBocC0+aHBldC5tYzY0ID0gaHAtPm1jX29mZnNldCArIGd1ZXN0
X3RpbWVfaHBldChocCk7CisgICAgaHAtPmhwZXQubWM2NCA9IGhwZXRfcmVhZF9tYWluY291
bnRlcihocCk7CiAKICAgICAvKiBTYXZlIHRoZSBIUEVUIHJlZ2lzdGVycyAqLwogICAgIHJj
ID0gX2h2bV9pbml0X2VudHJ5KGgsIEhWTV9TQVZFX0NPREUoSFBFVCksIDAsIEhWTV9TQVZF
X0xFTkdUSChIUEVUKSk7CkBAIC01NTQsOCArNTkyLDcgQEAgc3RhdGljIGludCBocGV0X2xv
YWQoc3RydWN0IGRvbWFpbiAqZCwgaAogICAgIH0KICN1bmRlZiBDCiAgICAgCi0gICAgLyog
UmVjYWxjdWxhdGUgdGhlIG9mZnNldCBiZXR3ZWVuIHRoZSBtYWluIGNvdW50ZXIgYW5kIGd1
ZXN0IHRpbWUgKi8KLSAgICBocC0+bWNfb2Zmc2V0ID0gaHAtPmhwZXQubWM2NCAtIGd1ZXN0
X3RpbWVfaHBldChocCk7CisgICAgaHBldF9zZXRfbWFpbmNvdW50ZXIoaHAsIGhwLT5ocGV0
Lm1jNjQpOwogCiAgICAgLyogcmVzdGFydCBhbGwgdGltZXJzICovCiAKZGlmZiAtciBjZjEy
OWE4MGU0N2UgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdnB0LmgKLS0tIGEveGVuL2luY2x1
ZGUvYXNtLXg4Ni9odm0vdnB0LmgJVHVlIEFwciAxNyAxNTozNzowNSAyMDEyICswMjAwCisr
KyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZwdC5oCVdlZCBBcHIgMTggMTA6Mjk6Mjgg
MjAxMiArMDEwMApAQCAtOTQsNyArOTQsMTMgQEAgdHlwZWRlZiBzdHJ1Y3QgSFBFVFN0YXRl
IHsKICAgICB1aW50NjRfdCBzdGltZV9mcmVxOwogICAgIHVpbnQ2NF90IGhwZXRfdG9fbnNf
c2NhbGU7IC8qIGhwZXQgdGlja3MgdG8gbnMgKG11bHRpcGxpZWQgYnkgMl4xMCkgKi8KICAg
ICB1aW50NjRfdCBocGV0X3RvX25zX2xpbWl0OyAvKiBtYXggaHBldCB0aWNrcyBjb252ZXJ0
YWJsZSB0byBucyAgICAgICovCi0gICAgdWludDY0X3QgbWNfb2Zmc2V0OworICAgIC8qCisg
ICAgICogbWNfY29uZmlnOiBBbGxvd3Mgc2FmZSBsb2NrLWZyZWUgcmVhZCBhY2Nlc3MgdG8g
dGhlIG1haW4gY291bnRlcgorICAgICAqICBiaXQgMDogc2V0IGlmIHRpbWVyIGlzIGVuYWJs
ZWQKKyAgICAgKiAgMS02MzogbWFpbiBjb3VudGVyIHZhbHVlIChpZiB0aW1lciBlbmFibGVk
KQorICAgICAqICAxLTYzOiBtYWluIGNvdW50ZXIgb2Zmc2V0IGZyb20gc3lzdGVtIHRpbWUg
KGlmIHRpbWVyIGRpc2FibGVkKQorICAgICAqLworICAgIGludDY0X3QgbWNfY29uZmlnOwog
ICAgIHN0cnVjdCBwZXJpb2RpY190aW1lIHB0W0hQRVRfVElNRVJfTlVNXTsKICAgICBzcGlu
bG9ja190IGxvY2s7CiB9IEhQRVRTdGF0ZTsK
--B_3417589853_316961
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3417589853_316961--




From xen-devel-bounces@lists.xen.org Wed Apr 18 09:55:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRbL-0000TH-Tg; Wed, 18 Apr 2012 09:55:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKRbL-0000T7-58
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:55:03 +0000
Received: from [193.109.254.147:57713] by server-11.bemta-14.messagelabs.com
	id 95/98-05858-67F8E8F4; Wed, 18 Apr 2012 09:55:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334742901!5158124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31664 invoked from network); 18 Apr 2012 09:55:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11997239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:55:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 10:55:01 +0100
Message-ID: <1334742899.23948.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 10:54:59 +0100
In-Reply-To: <1334677876-17704-5-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> As the previous change already introduces most of needed machinery to call
> hotplug scripts from libxl, this only adds the necessary bits to call this
> scripts for vif interfaces also.
> 
> libxl_device_nic_add has been changed to make use of the new event
> functionality, and the necessary vif hotplug code has been added. No changes
> where needed in the teardown part, since it uses exactly the same code
> introduced for vbd.
> 
> An exception has been introduced for tap devices, since hotplug scripts
> should be called after the device model has been created, so the hotplug
> call for those is done in do_domain_create after confirmation of the device
> model startup. On the other hand, tap devices don't use teardown scripts,
> so add another exception for that.
> 
> libxl__device_from_nic was moved to libxl_device.c, so it can be used
> in libxl_create.c, and libxl__device_from_disk was also moved to mantain
> the simmetry.

"maintain" and "symmetry"

These are pure code motion or did the code actually change too?

> libxl__initiate_device_remove has been changed a little, to nuke the frontend
> xenstore path before trying to perform device teardown, this allows for
> unitialized devices to be closed gracefully, specially vif interfaces added to

uninitialized (or -ised)

> HVM machines and not used.
> 
> PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
> LIBXL_NIC_TYPE_IOEMU regardless of the guest type.
> 
> A new gobal option, called disable_vif_scripts has been added to allow the user

        global

> decide if he wants to execute the hotplug scripts from xl or from udev. This has
> been documented in the xl.conf man page.

Did you do this for block too?

> 
> Changes since v1:
> 
>  * Propagated changes from previous patch (disable_udev and libxl_device_nic_add
>    switch).
> 
>  * Modified udev rules to add the new env variable.
> 
>  * Added support for named interfaces.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  docs/man/xl.conf.pod.5                |    7 ++
>  tools/hotplug/Linux/xen-backend.rules |    6 +-
>  tools/libxl/libxl.c                   |   90 +++++++-------------
>  tools/libxl/libxl.h                   |    3 +-
>  tools/libxl/libxl_create.c            |   22 +++++-
>  tools/libxl/libxl_device.c            |   77 +++++++++++++++--
>  tools/libxl/libxl_dm.c                |    2 +-
>  tools/libxl/libxl_internal.h          |    6 ++
>  tools/libxl/libxl_linux.c             |  150 ++++++++++++++++++++++++++++++++-
>  tools/libxl/libxl_types.idl           |    1 +
>  tools/libxl/xl.c                      |    4 +
>  tools/libxl/xl.h                      |    1 +
>  tools/libxl/xl_cmdimpl.c              |   15 +++-
>  13 files changed, 308 insertions(+), 76 deletions(-)
> 
> diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
> index 8bd45ea..cf2c477 100644
> --- a/docs/man/xl.conf.pod.5
> +++ b/docs/man/xl.conf.pod.5
> @@ -55,6 +55,13 @@ default.
> 
>  Default: C<1>
> 
> +=item B<disable_vif_scripts=BOOLEAN>
> +
> +If enabled xl will not execute nic hotplug scripts itself, and instead
> +relegate this task to udev.
> +
> +Default: C<0>

Please can you also add a commented out version
to ./tools/examples/xl.conf, with the value of the default.

This doesn't actually disable the scripts entirely, but rather only from
udev, disable_udev_vif_scripts perhaps?

>  =item B<lockfile="PATH">
> 
>  Sets the path to the lock file used by xl to serialise certain
> @@ -1929,14 +1883,30 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
> -    /* FIXME: wait for plug */
> +    switch(nic->nictype) {
> +    case LIBXL_NIC_TYPE_VIF:
> +        if (!nic->disable_vif_script) {
> +            rc = libxl__initiate_device_add(egc, ao, &device);
> +            if (rc) goto out_free;
> +        }

You don't need an ao_complete in the else case?
> +        break;
> +    case LIBXL_NIC_TYPE_IOEMU:
> +        /*
> +         * Don't execute hotplug scripts for IOEMU interfaces yet,
> +         * we need to launch the device model first.
> +        */

It'd be useful to add a reference to where these are run, at first I
thought this comment (and the patch to xen-backend.rules) meant they
weren't being run at all.

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index de598ad..a1f5731 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          }
>      }
>      for (i = 0; i < d_config->num_vifs; i++) {
> -        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
> +        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
>          if (ret) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                         "cannot add nic %d to domain: %d", i, ret);
> @@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                         "device model did not start: %d", ret);
>              goto error_out;
>          }
> +        /*
> +         * Execute hotplug scripts for tap devices, this has to be done
> +         * after the domain model has been started.
> +        */
> +        for (i = 0; i < d_config->num_vifs; i++) {
> +            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
> +                !d_config->vifs[i].disable_vif_script) {
> +                libxl__device device;
> +                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
> +                                             &device);
> +                if (ret < 0) goto error_out;
> +                ret = libxl__device_hotplug(gc, &device, CONNECT);

I should have asked this in 3/5 but does this function not need to be
async, since the script might take a while and we need to wait for it to
complete before continuing?

> +                if (ret < 0) {
> +                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                               "unable to launch hotplug script for device: "
> +                               "%"PRIu32, device.devid);
> +                    goto error_out;
> +                }
> +            }
> +        }
>      }
> 
>      for (i = 0; i < d_config->num_pcidevs; i++)
[...]
> @@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>  {
>      AO_GC;
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    xs_transaction_t t;
> +    xs_transaction_t t = 0;
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> -    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
> +    char *state;
>      int rc = 0;
>      libxl__ao_device_remove *aorm = 0;
> 
> +    /*
> +     * Nuke frontend to force backend teardown
> +     * It's not pretty, but it's the only way that seems to work for all
> +     * types of backends
> +     */

I'm still not happy with this. The _remove functions are supposed to be
a graceful + co-operative remove, that means prodding the front and
backend into doing the controlled teardown dance.

This may well take some time and may even fail after some timeout
depending on the device type, guest configuration and co-operation etc,
but that is expected and should be handled.

Forcing things in this way is appropriate for device_destroy only IMHO
since that is the function which is provided for use when the guest is
not co-operating.

> +    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
> +
> +retry_transaction:
> +    t = xs_transaction_start(ctx->xsh);
> +    state = libxl__xs_read(gc, t, state_path);
>      if (!state)
>          goto out_ok;
> -    if (atoi(state) != 4) {
> +    if (atoi(state) == XenbusStateClosed)
>          libxl__device_destroy_tapdisk(gc, be_path);
>          goto out_ok;
> -    }
> 
> -retry_transaction:
> -    t = xs_transaction_start(ctx->xsh);
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
>      xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {
> @@ -476,6 +537,8 @@ retry_transaction:
>              goto out_fail;
>          }
>      }
> +    /* mark transaction as ended, to prevent double closing it on out_ok */
> +    t = 0;
> 
>      libxl__device_destroy_tapdisk(gc, be_path);
> 
> @@ -497,8 +560,8 @@ retry_transaction:
>      return rc;
> 
>   out_ok:
> +    if (t) xs_transaction_end(ctx->xsh, t, 0);
>      rc = libxl__device_hotplug(gc, dev, DISCONNECT);
> -    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
>      libxl__xs_path_cleanup(gc, be_path);
>      return 0;
>  }
> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> index c5583af..1ef282f 100644
> --- a/tools/libxl/libxl_linux.c
> +++ b/tools/libxl/libxl_linux.c
> @@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
>  }
> 
>  /* Hotplug scripts helpers */
> +
> +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *snictype, *be_path;
> +
> +    be_path = libxl__device_backend_path(gc, dev);
> +
> +    snictype = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path, "type"));

This really ought to be under some private libxl path relating to the
device rather than under the backend/frontend visible dirs.

Actually, now I think of it, that is also true of the udev_disable key?

You could also use the handy enum to/from_strings functions to leave one
less magic number in xenstore.

> +    if (!snictype) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
> +                                          be_path);
> +        return -1;
> +    }
> +
> +    return atoi(snictype);
> +}
> +
> @@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
>                    dev->domid, dev->devid));
>      flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
>      flexarray_set(f_env, nr++, "backend");
> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
> +        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
> +                                                                 be_path,
> +                                                                 "vifname"));
> +        switch (get_nic_type(gc, dev)) {
> +        case LIBXL_NIC_TYPE_IOEMU:
> +            flexarray_set(f_env, nr++, "INTERFACE");
> +            if (ifname) {
> +                flexarray_set(f_env, nr++, libxl__sprintf(gc, "xentap-%s",
> +                                                              ifname));
> +            } else {
> +                flexarray_set(f_env, nr++,
> +                              libxl__sprintf(gc, "xentap%u.%d",
> +                              dev->domid, dev->devid));

This is cut-n-paste of some other code, perhaps create a function to get
the tap name from the vif name and or dom/devid? 

> +            }
> +        case LIBXL_NIC_TYPE_VIF:
> +            flexarray_set(f_env, nr++, "vif");
> +            if (ifname) {
> +                flexarray_set(f_env, nr++, ifname);
> +            } else {
> +                flexarray_set(f_env, nr++,
> +                              libxl__sprintf(gc, "vif%u.%d",
> +                              dev->domid, dev->devid));
> +            }

Likewise

> +            break;
> +        default:
> +            return NULL;
> +        }
> +    }
> 
>      flexarray_set(f_env, nr++, NULL);
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 01ff363..41230a6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -846,6 +846,19 @@ static void parse_config_data(const char *configfile_filename_report,
>                  nic->script = strdup(default_vifscript);
>              }
> 
> +            /* Set default nic type for PV guests correctly */
> +            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
> +                nic->nictype = LIBXL_NIC_TYPE_VIF;
> +            }

Hrm, really the lib ought to be taking care of that for us...

libxl__device_nic_setdefault has a domid so it should be able to query
the domain type with libxl__domain_type.

> +            /*
> +             * Disable nic network script calling, to allow the user
> +             * to attach the nic backend from a different domain.
> +             */
> +            if (disable_vif_scripts) {
> +                nic->disable_vif_script = 1;
> +            }

This is equivalent to :
		nic->disable_vif_script = disable_vif_scripts

> +
>             if (default_bridge) {
>                 free(nic->bridge);
>                 nic->bridge = strdup(default_bridge);
> @@ -4901,7 +4914,7 @@ int main_networkattach(int argc, char **argv)
>              return 1;
>          }
>      }
> -    if (libxl_device_nic_add(ctx, domid, &nic)) {
> +    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
>          fprintf(stderr, "libxl_device_nic_add failed.\n");
>          return 1;
>      }
> --
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 09:55:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRbL-0000TH-Tg; Wed, 18 Apr 2012 09:55:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKRbL-0000T7-58
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:55:03 +0000
Received: from [193.109.254.147:57713] by server-11.bemta-14.messagelabs.com
	id 95/98-05858-67F8E8F4; Wed, 18 Apr 2012 09:55:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334742901!5158124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31664 invoked from network); 18 Apr 2012 09:55:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11997239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:55:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 10:55:01 +0100
Message-ID: <1334742899.23948.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 10:54:59 +0100
In-Reply-To: <1334677876-17704-5-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> As the previous change already introduces most of needed machinery to call
> hotplug scripts from libxl, this only adds the necessary bits to call this
> scripts for vif interfaces also.
> 
> libxl_device_nic_add has been changed to make use of the new event
> functionality, and the necessary vif hotplug code has been added. No changes
> where needed in the teardown part, since it uses exactly the same code
> introduced for vbd.
> 
> An exception has been introduced for tap devices, since hotplug scripts
> should be called after the device model has been created, so the hotplug
> call for those is done in do_domain_create after confirmation of the device
> model startup. On the other hand, tap devices don't use teardown scripts,
> so add another exception for that.
> 
> libxl__device_from_nic was moved to libxl_device.c, so it can be used
> in libxl_create.c, and libxl__device_from_disk was also moved to mantain
> the simmetry.

"maintain" and "symmetry"

These are pure code motion or did the code actually change too?

> libxl__initiate_device_remove has been changed a little, to nuke the frontend
> xenstore path before trying to perform device teardown, this allows for
> unitialized devices to be closed gracefully, specially vif interfaces added to

uninitialized (or -ised)

> HVM machines and not used.
> 
> PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
> LIBXL_NIC_TYPE_IOEMU regardless of the guest type.
> 
> A new gobal option, called disable_vif_scripts has been added to allow the user

        global

> decide if he wants to execute the hotplug scripts from xl or from udev. This has
> been documented in the xl.conf man page.

Did you do this for block too?

> 
> Changes since v1:
> 
>  * Propagated changes from previous patch (disable_udev and libxl_device_nic_add
>    switch).
> 
>  * Modified udev rules to add the new env variable.
> 
>  * Added support for named interfaces.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  docs/man/xl.conf.pod.5                |    7 ++
>  tools/hotplug/Linux/xen-backend.rules |    6 +-
>  tools/libxl/libxl.c                   |   90 +++++++-------------
>  tools/libxl/libxl.h                   |    3 +-
>  tools/libxl/libxl_create.c            |   22 +++++-
>  tools/libxl/libxl_device.c            |   77 +++++++++++++++--
>  tools/libxl/libxl_dm.c                |    2 +-
>  tools/libxl/libxl_internal.h          |    6 ++
>  tools/libxl/libxl_linux.c             |  150 ++++++++++++++++++++++++++++++++-
>  tools/libxl/libxl_types.idl           |    1 +
>  tools/libxl/xl.c                      |    4 +
>  tools/libxl/xl.h                      |    1 +
>  tools/libxl/xl_cmdimpl.c              |   15 +++-
>  13 files changed, 308 insertions(+), 76 deletions(-)
> 
> diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
> index 8bd45ea..cf2c477 100644
> --- a/docs/man/xl.conf.pod.5
> +++ b/docs/man/xl.conf.pod.5
> @@ -55,6 +55,13 @@ default.
> 
>  Default: C<1>
> 
> +=item B<disable_vif_scripts=BOOLEAN>
> +
> +If enabled xl will not execute nic hotplug scripts itself, and instead
> +relegate this task to udev.
> +
> +Default: C<0>

Please can you also add a commented out version
to ./tools/examples/xl.conf, with the value of the default.

This doesn't actually disable the scripts entirely, but rather only from
udev, disable_udev_vif_scripts perhaps?

>  =item B<lockfile="PATH">
> 
>  Sets the path to the lock file used by xl to serialise certain
> @@ -1929,14 +1883,30 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
> -    /* FIXME: wait for plug */
> +    switch(nic->nictype) {
> +    case LIBXL_NIC_TYPE_VIF:
> +        if (!nic->disable_vif_script) {
> +            rc = libxl__initiate_device_add(egc, ao, &device);
> +            if (rc) goto out_free;
> +        }

You don't need an ao_complete in the else case?
> +        break;
> +    case LIBXL_NIC_TYPE_IOEMU:
> +        /*
> +         * Don't execute hotplug scripts for IOEMU interfaces yet,
> +         * we need to launch the device model first.
> +        */

It'd be useful to add a reference to where these are run, at first I
thought this comment (and the patch to xen-backend.rules) meant they
weren't being run at all.

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index de598ad..a1f5731 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          }
>      }
>      for (i = 0; i < d_config->num_vifs; i++) {
> -        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
> +        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
>          if (ret) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                         "cannot add nic %d to domain: %d", i, ret);
> @@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>                         "device model did not start: %d", ret);
>              goto error_out;
>          }
> +        /*
> +         * Execute hotplug scripts for tap devices, this has to be done
> +         * after the domain model has been started.
> +        */
> +        for (i = 0; i < d_config->num_vifs; i++) {
> +            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
> +                !d_config->vifs[i].disable_vif_script) {
> +                libxl__device device;
> +                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
> +                                             &device);
> +                if (ret < 0) goto error_out;
> +                ret = libxl__device_hotplug(gc, &device, CONNECT);

I should have asked this in 3/5 but does this function not need to be
async, since the script might take a while and we need to wait for it to
complete before continuing?

> +                if (ret < 0) {
> +                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                               "unable to launch hotplug script for device: "
> +                               "%"PRIu32, device.devid);
> +                    goto error_out;
> +                }
> +            }
> +        }
>      }
> 
>      for (i = 0; i < d_config->num_pcidevs; i++)
[...]
> @@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>  {
>      AO_GC;
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    xs_transaction_t t;
> +    xs_transaction_t t = 0;
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> -    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
> +    char *state;
>      int rc = 0;
>      libxl__ao_device_remove *aorm = 0;
> 
> +    /*
> +     * Nuke frontend to force backend teardown
> +     * It's not pretty, but it's the only way that seems to work for all
> +     * types of backends
> +     */

I'm still not happy with this. The _remove functions are supposed to be
a graceful + co-operative remove, that means prodding the front and
backend into doing the controlled teardown dance.

This may well take some time and may even fail after some timeout
depending on the device type, guest configuration and co-operation etc,
but that is expected and should be handled.

Forcing things in this way is appropriate for device_destroy only IMHO
since that is the function which is provided for use when the guest is
not co-operating.

> +    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
> +
> +retry_transaction:
> +    t = xs_transaction_start(ctx->xsh);
> +    state = libxl__xs_read(gc, t, state_path);
>      if (!state)
>          goto out_ok;
> -    if (atoi(state) != 4) {
> +    if (atoi(state) == XenbusStateClosed)
>          libxl__device_destroy_tapdisk(gc, be_path);
>          goto out_ok;
> -    }
> 
> -retry_transaction:
> -    t = xs_transaction_start(ctx->xsh);
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
>      xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {
> @@ -476,6 +537,8 @@ retry_transaction:
>              goto out_fail;
>          }
>      }
> +    /* mark transaction as ended, to prevent double closing it on out_ok */
> +    t = 0;
> 
>      libxl__device_destroy_tapdisk(gc, be_path);
> 
> @@ -497,8 +560,8 @@ retry_transaction:
>      return rc;
> 
>   out_ok:
> +    if (t) xs_transaction_end(ctx->xsh, t, 0);
>      rc = libxl__device_hotplug(gc, dev, DISCONNECT);
> -    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
>      libxl__xs_path_cleanup(gc, be_path);
>      return 0;
>  }
> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> index c5583af..1ef282f 100644
> --- a/tools/libxl/libxl_linux.c
> +++ b/tools/libxl/libxl_linux.c
> @@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
>  }
> 
>  /* Hotplug scripts helpers */
> +
> +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *snictype, *be_path;
> +
> +    be_path = libxl__device_backend_path(gc, dev);
> +
> +    snictype = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path, "type"));

This really ought to be under some private libxl path relating to the
device rather than under the backend/frontend visible dirs.

Actually, now I think of it, that is also true of the udev_disable key?

You could also use the handy enum to/from_strings functions to leave one
less magic number in xenstore.

> +    if (!snictype) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
> +                                          be_path);
> +        return -1;
> +    }
> +
> +    return atoi(snictype);
> +}
> +
> @@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
>                    dev->domid, dev->devid));
>      flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
>      flexarray_set(f_env, nr++, "backend");
> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
> +        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
> +                                                                 be_path,
> +                                                                 "vifname"));
> +        switch (get_nic_type(gc, dev)) {
> +        case LIBXL_NIC_TYPE_IOEMU:
> +            flexarray_set(f_env, nr++, "INTERFACE");
> +            if (ifname) {
> +                flexarray_set(f_env, nr++, libxl__sprintf(gc, "xentap-%s",
> +                                                              ifname));
> +            } else {
> +                flexarray_set(f_env, nr++,
> +                              libxl__sprintf(gc, "xentap%u.%d",
> +                              dev->domid, dev->devid));

This is cut-n-paste of some other code, perhaps create a function to get
the tap name from the vif name and or dom/devid? 

> +            }
> +        case LIBXL_NIC_TYPE_VIF:
> +            flexarray_set(f_env, nr++, "vif");
> +            if (ifname) {
> +                flexarray_set(f_env, nr++, ifname);
> +            } else {
> +                flexarray_set(f_env, nr++,
> +                              libxl__sprintf(gc, "vif%u.%d",
> +                              dev->domid, dev->devid));
> +            }

Likewise

> +            break;
> +        default:
> +            return NULL;
> +        }
> +    }
> 
>      flexarray_set(f_env, nr++, NULL);
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 01ff363..41230a6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -846,6 +846,19 @@ static void parse_config_data(const char *configfile_filename_report,
>                  nic->script = strdup(default_vifscript);
>              }
> 
> +            /* Set default nic type for PV guests correctly */
> +            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
> +                nic->nictype = LIBXL_NIC_TYPE_VIF;
> +            }

Hrm, really the lib ought to be taking care of that for us...

libxl__device_nic_setdefault has a domid so it should be able to query
the domain type with libxl__domain_type.

> +            /*
> +             * Disable nic network script calling, to allow the user
> +             * to attach the nic backend from a different domain.
> +             */
> +            if (disable_vif_scripts) {
> +                nic->disable_vif_script = 1;
> +            }

This is equivalent to :
		nic->disable_vif_script = disable_vif_scripts

> +
>             if (default_bridge) {
>                 free(nic->bridge);
>                 nic->bridge = strdup(default_bridge);
> @@ -4901,7 +4914,7 @@ int main_networkattach(int argc, char **argv)
>              return 1;
>          }
>      }
> -    if (libxl_device_nic_add(ctx, domid, &nic)) {
> +    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
>          fprintf(stderr, "libxl_device_nic_add failed.\n");
>          return 1;
>      }
> --
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 09:56:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRcX-0000bo-K8; Wed, 18 Apr 2012 09:56:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <summerxyt@gmail.com>) id 1SKRcW-0000bX-4g
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:56:16 +0000
Received: from [85.158.138.51:36379] by server-1.bemta-3.messagelabs.com id
	20/51-11491-FBF8E8F4; Wed, 18 Apr 2012 09:56:15 +0000
X-Env-Sender: summerxyt@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334742973!22520204!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: , surbl: (ASYNC_NO)
	c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRvbmVkOiBhc2VlbXN
	ldGhpLndvcmRwcmVzcy5j\nb20p\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29962 invoked from network); 18 Apr 2012 09:56:13 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:56:13 -0000
Received: by lahe6 with SMTP id e6so6536539lah.32
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 02:56:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Xm8SKR3ld23YjOH3KVoc8kUqbwdzVuLbbjzJmXHdKkY=;
	b=qJAyxNW0gMVkGLL3Uilv5dL6/MFj5PWSI7kTHj1ar97lS1eU5TU4sKHXfGqgHmdZVs
	M/o/Qm39vO0wIfSl2wK0sU/yST/tapoisHxuZfZWexyUkvBCyrtCssE3u/ver6Fm0Fqi
	+501KhubTUuSsV5RPFVPPup3RpLjl7l1hR/E5+o541VXWzXBBx8d7UsD5WRhFyQDyEiS
	zEBu8GrSNpqfkST8VpFBYWujwxAAC9VaU2zkzzs7CbE7pVx3y6WznfieYnQCOE0n60Zj
	ud0DYB7KxuPFAdRKwdsLeSwBBMRUBen2MlzRRRqblJB9imnQomsbZ5MkPl+vyuRNdMtt
	jyYA==
MIME-Version: 1.0
Received: by 10.112.99.41 with SMTP id en9mr766975lbb.5.1334742972717; Wed, 18
	Apr 2012 02:56:12 -0700 (PDT)
Received: by 10.112.127.7 with HTTP; Wed, 18 Apr 2012 02:56:12 -0700 (PDT)
Date: Wed, 18 Apr 2012 17:56:12 +0800
Message-ID: <CAMjnu2d=UNSKE7y9XkZ6P9TQQdoajriRqU2HOF+z=cmzFHuuDg@mail.gmail.com>
From: =?GB2312?B?z8TStczt?= <summerxyt@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] How to map memory by grant table.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0266348020374102441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0266348020374102441==
Content-Type: multipart/alternative; boundary=f46d040169cdc15a9b04bdf110ff

--f46d040169cdc15a9b04bdf110ff
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi everyone,

I know it's not a place for technical support queries, but I really need
some help on how to use grant table.

My goal to use grant table to transfer data by shared memory, and now want
to only share only one page. I try to learn how to use it by checking
aseemsethi's
instruction<http://aseemsethi.wordpress.com/article/learning-grant-tables-2=
9fizhrip655z-5/>and
gntdev.c. Although the sender seems OK, the reciever cannot map memory
by gref, and the ops.status always returns  -1, meaning undefined error.

I=91m totally confused about this. I guess it might due to memory-allocatin=
g,
but perhaps not. Could someone give some hints to me? Thanks!

Here is part of my code.

In the sender:
static int server_alloc_one_page_to_
grant(unsigned long* mypage,domid_t rdom){
        unsigned long addr=3D0;

        gref=3D-1; //gref is globle
        addr=3Dget_zeroed_page(GFP_KERNEL);
        if(addr=3D=3D0){
                printk("cannot alloc page\n");
        }

        sprintf((char*)addr,"%s\naaa\n","This is in sender.");

        gref=3Dgnttab_grant_foreign_access(rdom,virt_to_mfn(addr),1);
        if(gref<0){
                 free_page(addr);
        }

        printk("gref:%d\n",gref);
        return gref;
}

and it seems works well.

But in reciver:
static int client_map_page(domid_t rdom,grant_ref_t ref,struct vm_struct**
pvm){
  struct vm_struct *v_start;
  struct gnttab_map_grant_ref ops;
  struct gnttab_unmap_grant_ref unmap_ops;

  memset(&ops,0,sizeof(ops));
  memset(&ops,0,sizeof(unmap_ops));
  v_start=3Dalloc_vm_area(PAGE_SIZE,NULL);
  if(v_start=3D=3D0){
    printk("could not allocate page in client.\n");
    return -1;
  }

  /***************************things goes wrong
************************************************/
  gnttab_set_map_op(&ops,(unsigned
long)v_start->addr,GNTMAP_host_map,ref,rdom);
  if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,&ops,1)){
    free_vm_area(v_start);
    printk("\nHYPERVISOR map grant ref failed\n");
    return -1;
  }
   //ops,status always equals to -1, and map failed
  if(ops.status){
    printk("xen:HYPERVISOR map grant ref failed status=3D%d",ops.status);
    free_vm_area(v_start);
    return -1;
  }

  /*access memory by v_start->addr and unmap memory*/
  ...
}

--f46d040169cdc15a9b04bdf110ff
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi everyone,<br><br>I know it&#39;s not a place for  technical support quer=
ies, but I really need some help on how to use grant table.<br><br>My goal =
to use grant table to transfer data by shared
 memory, and now want to only share only one page. I try to learn how to
 use it by checking <a href=3D"http://aseemsethi.wordpress.com/article/lear=
ning-grant-tables-29fizhrip655z-5/" target=3D"_blank">aseemsethi&#39;s inst=
ruction</a>
 and gntdev.c. Although the sender seems OK, the reciever cannot map=20
memory by gref, and the ops.status always returns=A0 -1, meaning undefined
 error. <br>
<br>I=91m totally confused about this. I guess it might due to=20
memory-allocating, but perhaps not. Could someone give some hints to me?
 Thanks!<br><br>Here is part of my code.<br><br>In the sender:<br>static in=
t server_alloc_one_page_to_<div id=3D":115">grant(unsigned long* mypage,dom=
id_t rdom){<br>
=A0=A0=A0=A0=A0=A0=A0 unsigned long addr=3D0;<br>=A0=A0=A0=A0=A0=A0=A0 <br>=
=A0=A0=A0=A0=A0=A0=A0 gref=3D-1; //gref is globle<br>=A0=A0=A0=A0=A0=A0=A0 =
addr=3Dget_zeroed_page(GFP_KERNEL);<br>=A0=A0=A0=A0=A0=A0=A0 if(addr=3D=3D0=
){<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 printk(&quot;cannot all=
oc page\n&quot;);<br>=A0=A0=A0=A0=A0=A0=A0 }<br>

<br>=A0=A0=A0=A0=A0=A0=A0 sprintf((char*)addr,&quot;%s\naaa\n&quot;,&quot;T=
his is in sender.&quot;);<br><br>=A0=A0=A0=A0=A0=A0=A0 gref=3Dgnttab_grant_=
foreign_access(rdom,virt_to_mfn(addr),1);=A0=A0=A0=A0=A0=A0 <br>=A0=A0=A0=
=A0=A0=A0=A0 if(gref&lt;0){<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 free_page(addr);<br>

=A0=A0=A0=A0=A0=A0=A0 }<br><br>=A0=A0=A0=A0=A0=A0=A0 printk(&quot;gref:%d\n=
&quot;,gref);<br>=A0=A0=A0=A0=A0=A0=A0 return gref;<br>}<br><br>and it seem=
s works well.<br><br>But in reciver:<br>static int client_map_page(domid_t =
rdom,grant_ref_t ref,struct vm_struct** pvm){<br>

=A0 struct vm_struct *v_start;<br>=A0 struct gnttab_map_grant_ref ops;<br>=
=A0 struct gnttab_unmap_grant_ref unmap_ops;<br><br>=A0 memset(&amp;ops,0,s=
izeof(ops));<br>=A0 memset(&amp;ops,0,sizeof(unmap_ops));<br>=A0 v_start=3D=
alloc_vm_area(PAGE_SIZE,NULL);<br>

=A0 if(v_start=3D=3D0){<br>=A0=A0=A0 printk(&quot;could not allocate page i=
n client.\n&quot;);<br>=A0=A0=A0 return -1;<br>=A0 }<br><br>=A0 /**********=
*****************things goes wrong ****************************************=
********/<br>=A0 gnttab_set_map_op(&amp;ops,(unsigned long)v_start-&gt;addr=
,GNTMAP_host_map,ref,rdom);<br>

=A0 if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,&amp;ops,1)){<br>=
=A0=A0=A0 free_vm_area(v_start);<br>=A0=A0=A0 printk(&quot;\nHYPERVISOR map=
 grant ref failed\n&quot;);<br>=A0=A0=A0 return -1;<br>=A0 }<br>=A0=A0 //op=
s,status always equals to -1, and map failed<br>

=A0 if(ops.status){ =A0=A0 <br>=A0=A0=A0 printk(&quot;xen:HYPERVISOR map gr=
ant ref failed status=3D%d&quot;,ops.status);<br>=A0=A0=A0 free_vm_area(v_s=
tart);<br>=A0=A0=A0 return -1;<br>=A0 }<br><br>=A0 /*access memory by v_sta=
rt-&gt;addr and unmap memory*/<br>

=A0 ...<br>}</div>

--f46d040169cdc15a9b04bdf110ff--


--===============0266348020374102441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0266348020374102441==--


From xen-devel-bounces@lists.xen.org Wed Apr 18 09:56:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRcX-0000bo-K8; Wed, 18 Apr 2012 09:56:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <summerxyt@gmail.com>) id 1SKRcW-0000bX-4g
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:56:16 +0000
Received: from [85.158.138.51:36379] by server-1.bemta-3.messagelabs.com id
	20/51-11491-FBF8E8F4; Wed, 18 Apr 2012 09:56:15 +0000
X-Env-Sender: summerxyt@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334742973!22520204!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: , surbl: (ASYNC_NO)
	c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRvbmVkOiBhc2VlbXN
	ldGhpLndvcmRwcmVzcy5j\nb20p\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29962 invoked from network); 18 Apr 2012 09:56:13 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:56:13 -0000
Received: by lahe6 with SMTP id e6so6536539lah.32
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 02:56:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Xm8SKR3ld23YjOH3KVoc8kUqbwdzVuLbbjzJmXHdKkY=;
	b=qJAyxNW0gMVkGLL3Uilv5dL6/MFj5PWSI7kTHj1ar97lS1eU5TU4sKHXfGqgHmdZVs
	M/o/Qm39vO0wIfSl2wK0sU/yST/tapoisHxuZfZWexyUkvBCyrtCssE3u/ver6Fm0Fqi
	+501KhubTUuSsV5RPFVPPup3RpLjl7l1hR/E5+o541VXWzXBBx8d7UsD5WRhFyQDyEiS
	zEBu8GrSNpqfkST8VpFBYWujwxAAC9VaU2zkzzs7CbE7pVx3y6WznfieYnQCOE0n60Zj
	ud0DYB7KxuPFAdRKwdsLeSwBBMRUBen2MlzRRRqblJB9imnQomsbZ5MkPl+vyuRNdMtt
	jyYA==
MIME-Version: 1.0
Received: by 10.112.99.41 with SMTP id en9mr766975lbb.5.1334742972717; Wed, 18
	Apr 2012 02:56:12 -0700 (PDT)
Received: by 10.112.127.7 with HTTP; Wed, 18 Apr 2012 02:56:12 -0700 (PDT)
Date: Wed, 18 Apr 2012 17:56:12 +0800
Message-ID: <CAMjnu2d=UNSKE7y9XkZ6P9TQQdoajriRqU2HOF+z=cmzFHuuDg@mail.gmail.com>
From: =?GB2312?B?z8TStczt?= <summerxyt@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] How to map memory by grant table.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0266348020374102441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0266348020374102441==
Content-Type: multipart/alternative; boundary=f46d040169cdc15a9b04bdf110ff

--f46d040169cdc15a9b04bdf110ff
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi everyone,

I know it's not a place for technical support queries, but I really need
some help on how to use grant table.

My goal to use grant table to transfer data by shared memory, and now want
to only share only one page. I try to learn how to use it by checking
aseemsethi's
instruction<http://aseemsethi.wordpress.com/article/learning-grant-tables-2=
9fizhrip655z-5/>and
gntdev.c. Although the sender seems OK, the reciever cannot map memory
by gref, and the ops.status always returns  -1, meaning undefined error.

I=91m totally confused about this. I guess it might due to memory-allocatin=
g,
but perhaps not. Could someone give some hints to me? Thanks!

Here is part of my code.

In the sender:
static int server_alloc_one_page_to_
grant(unsigned long* mypage,domid_t rdom){
        unsigned long addr=3D0;

        gref=3D-1; //gref is globle
        addr=3Dget_zeroed_page(GFP_KERNEL);
        if(addr=3D=3D0){
                printk("cannot alloc page\n");
        }

        sprintf((char*)addr,"%s\naaa\n","This is in sender.");

        gref=3Dgnttab_grant_foreign_access(rdom,virt_to_mfn(addr),1);
        if(gref<0){
                 free_page(addr);
        }

        printk("gref:%d\n",gref);
        return gref;
}

and it seems works well.

But in reciver:
static int client_map_page(domid_t rdom,grant_ref_t ref,struct vm_struct**
pvm){
  struct vm_struct *v_start;
  struct gnttab_map_grant_ref ops;
  struct gnttab_unmap_grant_ref unmap_ops;

  memset(&ops,0,sizeof(ops));
  memset(&ops,0,sizeof(unmap_ops));
  v_start=3Dalloc_vm_area(PAGE_SIZE,NULL);
  if(v_start=3D=3D0){
    printk("could not allocate page in client.\n");
    return -1;
  }

  /***************************things goes wrong
************************************************/
  gnttab_set_map_op(&ops,(unsigned
long)v_start->addr,GNTMAP_host_map,ref,rdom);
  if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,&ops,1)){
    free_vm_area(v_start);
    printk("\nHYPERVISOR map grant ref failed\n");
    return -1;
  }
   //ops,status always equals to -1, and map failed
  if(ops.status){
    printk("xen:HYPERVISOR map grant ref failed status=3D%d",ops.status);
    free_vm_area(v_start);
    return -1;
  }

  /*access memory by v_start->addr and unmap memory*/
  ...
}

--f46d040169cdc15a9b04bdf110ff
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi everyone,<br><br>I know it&#39;s not a place for  technical support quer=
ies, but I really need some help on how to use grant table.<br><br>My goal =
to use grant table to transfer data by shared
 memory, and now want to only share only one page. I try to learn how to
 use it by checking <a href=3D"http://aseemsethi.wordpress.com/article/lear=
ning-grant-tables-29fizhrip655z-5/" target=3D"_blank">aseemsethi&#39;s inst=
ruction</a>
 and gntdev.c. Although the sender seems OK, the reciever cannot map=20
memory by gref, and the ops.status always returns=A0 -1, meaning undefined
 error. <br>
<br>I=91m totally confused about this. I guess it might due to=20
memory-allocating, but perhaps not. Could someone give some hints to me?
 Thanks!<br><br>Here is part of my code.<br><br>In the sender:<br>static in=
t server_alloc_one_page_to_<div id=3D":115">grant(unsigned long* mypage,dom=
id_t rdom){<br>
=A0=A0=A0=A0=A0=A0=A0 unsigned long addr=3D0;<br>=A0=A0=A0=A0=A0=A0=A0 <br>=
=A0=A0=A0=A0=A0=A0=A0 gref=3D-1; //gref is globle<br>=A0=A0=A0=A0=A0=A0=A0 =
addr=3Dget_zeroed_page(GFP_KERNEL);<br>=A0=A0=A0=A0=A0=A0=A0 if(addr=3D=3D0=
){<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 printk(&quot;cannot all=
oc page\n&quot;);<br>=A0=A0=A0=A0=A0=A0=A0 }<br>

<br>=A0=A0=A0=A0=A0=A0=A0 sprintf((char*)addr,&quot;%s\naaa\n&quot;,&quot;T=
his is in sender.&quot;);<br><br>=A0=A0=A0=A0=A0=A0=A0 gref=3Dgnttab_grant_=
foreign_access(rdom,virt_to_mfn(addr),1);=A0=A0=A0=A0=A0=A0 <br>=A0=A0=A0=
=A0=A0=A0=A0 if(gref&lt;0){<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 free_page(addr);<br>

=A0=A0=A0=A0=A0=A0=A0 }<br><br>=A0=A0=A0=A0=A0=A0=A0 printk(&quot;gref:%d\n=
&quot;,gref);<br>=A0=A0=A0=A0=A0=A0=A0 return gref;<br>}<br><br>and it seem=
s works well.<br><br>But in reciver:<br>static int client_map_page(domid_t =
rdom,grant_ref_t ref,struct vm_struct** pvm){<br>

=A0 struct vm_struct *v_start;<br>=A0 struct gnttab_map_grant_ref ops;<br>=
=A0 struct gnttab_unmap_grant_ref unmap_ops;<br><br>=A0 memset(&amp;ops,0,s=
izeof(ops));<br>=A0 memset(&amp;ops,0,sizeof(unmap_ops));<br>=A0 v_start=3D=
alloc_vm_area(PAGE_SIZE,NULL);<br>

=A0 if(v_start=3D=3D0){<br>=A0=A0=A0 printk(&quot;could not allocate page i=
n client.\n&quot;);<br>=A0=A0=A0 return -1;<br>=A0 }<br><br>=A0 /**********=
*****************things goes wrong ****************************************=
********/<br>=A0 gnttab_set_map_op(&amp;ops,(unsigned long)v_start-&gt;addr=
,GNTMAP_host_map,ref,rdom);<br>

=A0 if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,&amp;ops,1)){<br>=
=A0=A0=A0 free_vm_area(v_start);<br>=A0=A0=A0 printk(&quot;\nHYPERVISOR map=
 grant ref failed\n&quot;);<br>=A0=A0=A0 return -1;<br>=A0 }<br>=A0=A0 //op=
s,status always equals to -1, and map failed<br>

=A0 if(ops.status){ =A0=A0 <br>=A0=A0=A0 printk(&quot;xen:HYPERVISOR map gr=
ant ref failed status=3D%d&quot;,ops.status);<br>=A0=A0=A0 free_vm_area(v_s=
tart);<br>=A0=A0=A0 return -1;<br>=A0 }<br><br>=A0 /*access memory by v_sta=
rt-&gt;addr and unmap memory*/<br>

=A0 ...<br>}</div>

--f46d040169cdc15a9b04bdf110ff--


--===============0266348020374102441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0266348020374102441==--


From xen-devel-bounces@lists.xen.org Wed Apr 18 09:57:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRd3-0000gX-35; Wed, 18 Apr 2012 09:56:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKRd1-0000gG-P0
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:56:47 +0000
Received: from [85.158.143.35:28333] by server-1.bemta-4.messagelabs.com id
	37/CC-20925-FDF8E8F4; Wed, 18 Apr 2012 09:56:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334743005!11867917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6477 invoked from network); 18 Apr 2012 09:56:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11997292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:56:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 10:56:09 +0100
Message-ID: <1334742968.23948.181.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 10:56:08 +0100
In-Reply-To: <1334677876-17704-6-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-6-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 5/5] libxl: add "downscript=no" to Qemu
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> Currently we only pass script=no to Qemu, to avoid calling any scripts when
> attaching a tap interface, but we should also pass downscript=no to avoid Qemu
> trying to execute a script when disconnecting the interface. This prevents the
> following harmless error message:
> 
> /etc/qemu-ifdown: could not launch network script
> 
> Changes since v1:
> 
>  * Indentation fixes.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dm.c |   27 ++++++++++++++++++---------
>  1 files changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 04f76c2..d9c1786 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -216,11 +216,18 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>                  else
>                      ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
>                  flexarray_vappend(dm_args,
> -                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
> -                                                       vifs[i].devid, smac, vifs[i].model),
> -                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
> -                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
> -                                NULL);
> +                                  "-net",
> +                                  libxl__sprintf(gc,
> +                                      "nic,vlan=%d,macaddr=%s,model=%s",
> +                                      vifs[i].devid, smac, vifs[i].model),
> +                                  "-net",
> +                                  libxl__sprintf(gc,
> +                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
> +                                      "script=%s,downscript=%s",
> +                                      vifs[i].devid, ifname, vifs[i].bridge,
> +                                      libxl_tapif_script(gc),
> +                                      libxl_tapif_script(gc)),
> +                                  NULL);
>                  ioemu_vifs++;
>              }
>          }
> @@ -461,10 +468,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                                                  vifs[i].model, vifs[i].devid,
>                                                  vifs[i].devid, smac));
>                  flexarray_append(dm_args, "-netdev");
> -                flexarray_append(dm_args,
> -                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
> -                                                vifs[i].devid, ifname,
> -                                                libxl_tapif_script(gc)));
> +                flexarray_append(dm_args, libxl__sprintf(gc, 
> +                                          "type=tap,id=net%d,ifname=%s,"
> +                                          "script=%s,downscript=%s",
> +                                          vifs[i].devid, ifname,
> +                                          libxl_tapif_script(gc),
> +                                          libxl_tapif_script(gc)));
>                  ioemu_vifs++;
>              }
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 09:57:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 09:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRd3-0000gX-35; Wed, 18 Apr 2012 09:56:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKRd1-0000gG-P0
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 09:56:47 +0000
Received: from [85.158.143.35:28333] by server-1.bemta-4.messagelabs.com id
	37/CC-20925-FDF8E8F4; Wed, 18 Apr 2012 09:56:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334743005!11867917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6477 invoked from network); 18 Apr 2012 09:56:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 09:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11997292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:56:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 10:56:09 +0100
Message-ID: <1334742968.23948.181.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 10:56:08 +0100
In-Reply-To: <1334677876-17704-6-git-send-email-roger.pau@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-6-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 5/5] libxl: add "downscript=no" to Qemu
 call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
> Currently we only pass script=no to Qemu, to avoid calling any scripts when
> attaching a tap interface, but we should also pass downscript=no to avoid Qemu
> trying to execute a script when disconnecting the interface. This prevents the
> following harmless error message:
> 
> /etc/qemu-ifdown: could not launch network script
> 
> Changes since v1:
> 
>  * Indentation fixes.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dm.c |   27 ++++++++++++++++++---------
>  1 files changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 04f76c2..d9c1786 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -216,11 +216,18 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>                  else
>                      ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
>                  flexarray_vappend(dm_args,
> -                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
> -                                                       vifs[i].devid, smac, vifs[i].model),
> -                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
> -                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
> -                                NULL);
> +                                  "-net",
> +                                  libxl__sprintf(gc,
> +                                      "nic,vlan=%d,macaddr=%s,model=%s",
> +                                      vifs[i].devid, smac, vifs[i].model),
> +                                  "-net",
> +                                  libxl__sprintf(gc,
> +                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
> +                                      "script=%s,downscript=%s",
> +                                      vifs[i].devid, ifname, vifs[i].bridge,
> +                                      libxl_tapif_script(gc),
> +                                      libxl_tapif_script(gc)),
> +                                  NULL);
>                  ioemu_vifs++;
>              }
>          }
> @@ -461,10 +468,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                                                  vifs[i].model, vifs[i].devid,
>                                                  vifs[i].devid, smac));
>                  flexarray_append(dm_args, "-netdev");
> -                flexarray_append(dm_args,
> -                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
> -                                                vifs[i].devid, ifname,
> -                                                libxl_tapif_script(gc)));
> +                flexarray_append(dm_args, libxl__sprintf(gc, 
> +                                          "type=tap,id=net%d,ifname=%s,"
> +                                          "script=%s,downscript=%s",
> +                                          vifs[i].devid, ifname,
> +                                          libxl_tapif_script(gc),
> +                                          libxl_tapif_script(gc)));
>                  ioemu_vifs++;
>              }
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 10:13:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 10:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRse-0001dJ-HA; Wed, 18 Apr 2012 10:12:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKRsc-0001dA-Rg
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 10:12:55 +0000
Received: from [85.158.143.35:2305] by server-2.bemta-4.messagelabs.com id
	E2/84-17550-6A39E8F4; Wed, 18 Apr 2012 10:12:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334743972!12939644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17045 invoked from network); 18 Apr 2012 10:12:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 10:12:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11997784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 10:12:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 11:12:52 +0100
Message-ID: <1334743970.23948.193.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 11:12:50 +0100
In-Reply-To: <20365.41550.838083.825783@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
	<20365.41550.838083.825783@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 18:03 +0100, Ian Jackson wrote:
> Thanks for the review.
> 
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> > Neither this patch nor the rest of the series seems to handle the long
> > running nature of xc_domain_restore, is that expected at this stage?
> 
> This is a thorny problem.
> 
> > We discussed a similar thing in the context of xc_domain_save, and I
> > expect the required scaffolding (bumping an op over into a thread) will
> > be the same on both sides?
> 
> Yes.
> 
> The thread's activities will have to be severely restricted but I
> think that will be doable.
> 
> We should consider another alternative: spawning a copy of xc_save,
> like xend does.

I wondered about that too. Does it make things like error handling or
reporting any more difficult?

> > >  typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> > > -int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> > > -int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
> > > +  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
> > > +   * properties need to be documented but they may turn out to be too
> > > +   * awkward */
> > 
> > The reentrancy concerns here relate to the "cb" or to something else?
> 
> To the cb.  This is in fact fixed later in the series.

Great!

> > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > > @@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc,
> > > libxl_domain_config *d_config,
> > >          libxl_device_vkb_add(ctx, domid, &vkb);
> > >          libxl_device_vkb_dispose(&vkb);
> > > [...]
> > > +        dcs->dmss.guest_domid = domid;
> > 
> > dcs->dmss is part of a union with dcs->sdss. I'd rather this was done
> > inside the if once we've committed to one or the other, IYSWIM.
> > 
> > Actually the hunk above (which I've trimmed already, sorry) also
> > initialised dmss unconditionally.
> > 
> > (does sdss really not need guest_domid somewhere too? odd)
> 
> libxl__stubdom_spawn_state is a struct containing a
> libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
> domid is in sdss.stubdom.guest_domid, and because stubdom is first
> this is the same as dmss->guest_domid.
> 
> Maybe this needs a bigger comment ?

At the very least, yes.

Does combining thing in a union in this way really make some other bit
of code look substantially better? Not having the union and having a
shared libxl__dm_spawn_state in the parent struct seems more straight
forward at least from here.

> > > +    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
> > > +                                    spawn_watch_event, ss->xspath);
> > 
> > IIRC xspath is optional, does libxl__ev_xswatch_register DTWT with NULL?
> 
> No, it would crash.
> 
> xspath is no longer optional.

So this comment on libxl__spawn_spawn is wrong?
> + * The inner child must soon exit or exec.  If must also soon exit or
> + * notify the parent of its successful startup by writing to the
> + * xenstore path xspath (or by other means).  xspath may be 0 to
> + * indicate that only other means are being used.

>   There can be no correct callers who
> don't arrange to be notified by their demonic child that it has
> started up, and the only current callers use xenstore for this.

Given that the callers and the code agree and the comment disagrees I
think you could just nuke that comment (or replace it with one requiring
non-NULL).

> > > +/* Stubdoms. */
> > > +
> > > +typedef struct {
> > > +    /* mixed - user must fill in public parts only: */
> > > +    libxl__dm_spawn_state stubdom; /* will always remain the first member */
> > 
> > why? If you are playing casting tricks then you could use CONTAINER_OF.
> 
> See above.
> 
> > > +_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
> > > +
> > 
> > Ah, I see now what local_dm meant, it's the non-stubdom DM.
> > 
> > stubdom is a bit of an overloaded term (we have grub stubdoms, xenstore
> > stubdoms etc too). stub_dm would be better.
> 
> Do you think I should s/stubdom/stubdm/ or something ?

yes, or stub_dm for consistency with local_dm. I'd like to eradicate the
bare use of the term "stubdom" since it can mean several things
(admittedly not really in this context). I suspect I am fighting against
the tide here though...

> > >  /*
> > >   * Convenience macros.
> > >   */
> > 
> > Right, back to the top to start on the implementation...
> 
> There's no requirement to quote the patch in the order it appeared.
> You can rearrange in your email...

Yeah, I was just lazy ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 10:13:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 10:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKRse-0001dJ-HA; Wed, 18 Apr 2012 10:12:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKRsc-0001dA-Rg
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 10:12:55 +0000
Received: from [85.158.143.35:2305] by server-2.bemta-4.messagelabs.com id
	E2/84-17550-6A39E8F4; Wed, 18 Apr 2012 10:12:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334743972!12939644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17045 invoked from network); 18 Apr 2012 10:12:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 10:12:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11997784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 10:12:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 11:12:52 +0100
Message-ID: <1334743970.23948.193.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 11:12:50 +0100
In-Reply-To: <20365.41550.838083.825783@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
	<20365.41550.838083.825783@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 18:03 +0100, Ian Jackson wrote:
> Thanks for the review.
> 
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> > Neither this patch nor the rest of the series seems to handle the long
> > running nature of xc_domain_restore, is that expected at this stage?
> 
> This is a thorny problem.
> 
> > We discussed a similar thing in the context of xc_domain_save, and I
> > expect the required scaffolding (bumping an op over into a thread) will
> > be the same on both sides?
> 
> Yes.
> 
> The thread's activities will have to be severely restricted but I
> think that will be doable.
> 
> We should consider another alternative: spawning a copy of xc_save,
> like xend does.

I wondered about that too. Does it make things like error handling or
reporting any more difficult?

> > >  typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
> > > -int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> > > -int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
> > > +  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
> > > +   * properties need to be documented but they may turn out to be too
> > > +   * awkward */
> > 
> > The reentrancy concerns here relate to the "cb" or to something else?
> 
> To the cb.  This is in fact fixed later in the series.

Great!

> > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > > @@ -635,13 +667,13 @@ static int do_domain_create(libxl__gc *gc,
> > > libxl_domain_config *d_config,
> > >          libxl_device_vkb_add(ctx, domid, &vkb);
> > >          libxl_device_vkb_dispose(&vkb);
> > > [...]
> > > +        dcs->dmss.guest_domid = domid;
> > 
> > dcs->dmss is part of a union with dcs->sdss. I'd rather this was done
> > inside the if once we've committed to one or the other, IYSWIM.
> > 
> > Actually the hunk above (which I've trimmed already, sorry) also
> > initialised dmss unconditionally.
> > 
> > (does sdss really not need guest_domid somewhere too? odd)
> 
> libxl__stubdom_spawn_state is a struct containing a
> libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
> domid is in sdss.stubdom.guest_domid, and because stubdom is first
> this is the same as dmss->guest_domid.
> 
> Maybe this needs a bigger comment ?

At the very least, yes.

Does combining thing in a union in this way really make some other bit
of code look substantially better? Not having the union and having a
shared libxl__dm_spawn_state in the parent struct seems more straight
forward at least from here.

> > > +    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
> > > +                                    spawn_watch_event, ss->xspath);
> > 
> > IIRC xspath is optional, does libxl__ev_xswatch_register DTWT with NULL?
> 
> No, it would crash.
> 
> xspath is no longer optional.

So this comment on libxl__spawn_spawn is wrong?
> + * The inner child must soon exit or exec.  If must also soon exit or
> + * notify the parent of its successful startup by writing to the
> + * xenstore path xspath (or by other means).  xspath may be 0 to
> + * indicate that only other means are being used.

>   There can be no correct callers who
> don't arrange to be notified by their demonic child that it has
> started up, and the only current callers use xenstore for this.

Given that the callers and the code agree and the comment disagrees I
think you could just nuke that comment (or replace it with one requiring
non-NULL).

> > > +/* Stubdoms. */
> > > +
> > > +typedef struct {
> > > +    /* mixed - user must fill in public parts only: */
> > > +    libxl__dm_spawn_state stubdom; /* will always remain the first member */
> > 
> > why? If you are playing casting tricks then you could use CONTAINER_OF.
> 
> See above.
> 
> > > +_hidden void libxl__spawn_stubdom(libxl__egc *egc, libxl__stubdom_spawn_state*);
> > > +
> > 
> > Ah, I see now what local_dm meant, it's the non-stubdom DM.
> > 
> > stubdom is a bit of an overloaded term (we have grub stubdoms, xenstore
> > stubdoms etc too). stub_dm would be better.
> 
> Do you think I should s/stubdom/stubdm/ or something ?

yes, or stub_dm for consistency with local_dm. I'd like to eradicate the
bare use of the term "stubdom" since it can mean several things
(admittedly not really in this context). I suspect I am fighting against
the tide here though...

> > >  /*
> > >   * Convenience macros.
> > >   */
> > 
> > Right, back to the top to start on the implementation...
> 
> There's no requirement to quote the patch in the order it appeared.
> You can rearrange in your email...

Yeah, I was just lazy ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 10:53:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 10:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSVE-000250-Un; Wed, 18 Apr 2012 10:52:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKSVD-00024u-71
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 10:52:47 +0000
Received: from [85.158.139.83:59250] by server-4.bemta-5.messagelabs.com id
	17/1D-10788-CFC9E8F4; Wed, 18 Apr 2012 10:52:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334746362!24270315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3904 invoked from network); 18 Apr 2012 10:52:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 10:52:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11998816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 10:52:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 11:52:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKSV5-0005jx-F2; Wed, 18 Apr 2012 10:52:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKSV5-0002wP-EA;
	Wed, 18 Apr 2012 11:52:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20366.40183.410388.447630@mariner.uk.xensource.com>
Date: Wed, 18 Apr 2012 11:52:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334743970.23948.193.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
	<20365.41550.838083.825783@mariner.uk.xensource.com>
	<1334743970.23948.193.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> On Tue, 2012-04-17 at 18:03 +0100, Ian Jackson wrote:
> > We should consider another alternative: spawning a copy of xc_save,
> > like xend does.
> 
> I wondered about that too. Does it make things like error handling or
> reporting any more difficult?

With threading it's quite tricky.  I think it would be rude to call
even the application's logging callbacks on a private thread.
Certainly we can't easily propagate errors from that private thread.
We would have to arrange somehow to transfer the results to one of the
application's threads, to avoid possibly calling back to the
application on our private thread (which is a big no-no because it
might subject a non-multithreaded application to reentrancy).  And
even with all that there are vexed problems like the possibility of
generating an application-wide SIGPIPE on the migration fd.

So I think it would make it easier, now that we have all the machinery
in place, to spawn a separate process.  That process should exec, even
if the thing exec'd is a utility mostly using libxl, firstly to save
memory (in case we're talking about a huge toolstack daemon) and also
so we don't have to worry about nonconsensually generating
long-running non-execing forks of the application (which would require
us to provide a callback mirror of the postfork noexec downcall).

> > libxl__stubdom_spawn_state is a struct containing a
> > libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
> > domid is in sdss.stubdom.guest_domid, and because stubdom is first
> > this is the same as dmss->guest_domid.
> > 
> > Maybe this needs a bigger comment ?
> 
> At the very least, yes.
> 
> Does combining thing in a union in this way really make some other bit
> of code look substantially better? Not having the union and having a
> shared libxl__dm_spawn_state in the parent struct seems more straight
> forward at least from here.

I will see if there is a better way to do this, perhaps without the
union.  And try to add more comments.

> > xspath is no longer optional.
> 
> So this comment on libxl__spawn_spawn is wrong?
> > + * The inner child must soon exit or exec.  If must also soon exit or
> > + * notify the parent of its successful startup by writing to the
> > + * xenstore path xspath (or by other means).  xspath may be 0 to
> > + * indicate that only other means are being used.

Yes.  It's out of date.  We don't have any processes which do this
other than with xenstore.  If we introduce them we can make xspath
maybe be 0.  I've deleted the erroneous comment (and fixed the
preceding sentence).

> > Do you think I should s/stubdom/stubdm/ or something ?
> 
> yes, or stub_dm for consistency with local_dm. I'd like to eradicate the
> bare use of the term "stubdom" since it can mean several things
> (admittedly not really in this context). I suspect I am fighting against
> the tide here though...

I see your point and will see what I can do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 10:53:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 10:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSVE-000250-Un; Wed, 18 Apr 2012 10:52:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKSVD-00024u-71
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 10:52:47 +0000
Received: from [85.158.139.83:59250] by server-4.bemta-5.messagelabs.com id
	17/1D-10788-CFC9E8F4; Wed, 18 Apr 2012 10:52:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334746362!24270315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3904 invoked from network); 18 Apr 2012 10:52:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 10:52:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11998816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 10:52:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 11:52:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SKSV5-0005jx-F2; Wed, 18 Apr 2012 10:52:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SKSV5-0002wP-EA;
	Wed, 18 Apr 2012 11:52:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20366.40183.410388.447630@mariner.uk.xensource.com>
Date: Wed, 18 Apr 2012 11:52:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334743970.23948.193.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
	<20365.41550.838083.825783@mariner.uk.xensource.com>
	<1334743970.23948.193.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> On Tue, 2012-04-17 at 18:03 +0100, Ian Jackson wrote:
> > We should consider another alternative: spawning a copy of xc_save,
> > like xend does.
> 
> I wondered about that too. Does it make things like error handling or
> reporting any more difficult?

With threading it's quite tricky.  I think it would be rude to call
even the application's logging callbacks on a private thread.
Certainly we can't easily propagate errors from that private thread.
We would have to arrange somehow to transfer the results to one of the
application's threads, to avoid possibly calling back to the
application on our private thread (which is a big no-no because it
might subject a non-multithreaded application to reentrancy).  And
even with all that there are vexed problems like the possibility of
generating an application-wide SIGPIPE on the migration fd.

So I think it would make it easier, now that we have all the machinery
in place, to spawn a separate process.  That process should exec, even
if the thing exec'd is a utility mostly using libxl, firstly to save
memory (in case we're talking about a huge toolstack daemon) and also
so we don't have to worry about nonconsensually generating
long-running non-execing forks of the application (which would require
us to provide a callback mirror of the postfork noexec downcall).

> > libxl__stubdom_spawn_state is a struct containing a
> > libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
> > domid is in sdss.stubdom.guest_domid, and because stubdom is first
> > this is the same as dmss->guest_domid.
> > 
> > Maybe this needs a bigger comment ?
> 
> At the very least, yes.
> 
> Does combining thing in a union in this way really make some other bit
> of code look substantially better? Not having the union and having a
> shared libxl__dm_spawn_state in the parent struct seems more straight
> forward at least from here.

I will see if there is a better way to do this, perhaps without the
union.  And try to add more comments.

> > xspath is no longer optional.
> 
> So this comment on libxl__spawn_spawn is wrong?
> > + * The inner child must soon exit or exec.  If must also soon exit or
> > + * notify the parent of its successful startup by writing to the
> > + * xenstore path xspath (or by other means).  xspath may be 0 to
> > + * indicate that only other means are being used.

Yes.  It's out of date.  We don't have any processes which do this
other than with xenstore.  If we introduce them we can make xspath
maybe be 0.  I've deleted the erroneous comment (and fixed the
preceding sentence).

> > Do you think I should s/stubdom/stubdm/ or something ?
> 
> yes, or stub_dm for consistency with local_dm. I'd like to eradicate the
> bare use of the term "stubdom" since it can mean several things
> (admittedly not really in this context). I suspect I am fighting against
> the tide here though...

I see your point and will see what I can do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSh7-0002RL-QU; Wed, 18 Apr 2012 11:05:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKSh6-0002RC-1l
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:05:04 +0000
Received: from [85.158.143.99:6340] by server-3.bemta-4.messagelabs.com id
	BB/BB-05853-FDF9E8F4; Wed, 18 Apr 2012 11:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334747101!23255091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19490 invoked from network); 18 Apr 2012 11:05:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11999132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 11:05:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 12:05:01 +0100
Message-ID: <1334747100.23948.202.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 18 Apr 2012 12:05:00 +0100
In-Reply-To: <4F8D902A.2080607@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:45 +0100, Anthony PERARD wrote:
> On 17/04/12 16:30, Ian Campbell wrote:
> > On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
> >> Currently `xl vncviewer $dom` does not work because the VNC port is not
> >> registered in xenstore when using qemu-upstream. This patch attempted to fix
> >> this.
> >
> > libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
> > having such a thing in xenstore strikes me as something of a
> > misfeature...
> 
> Well, I thought of that, but when I tried `xl vncviewer` with a password 
> set, the result was that vncviewer asked me a password. That why I 
> haven't put more effort in querrying the vnc password from QEMU.

Same here even with qemu-xen-traditional.

I'm tempted to suggest that we remove this support -- having plain text
passwords in xenstore (thankfully with perms set somewhat sanely) just
doesn't seem like a Good Thing to me...

> 
> > Otherwise:
> > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> >
> >> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSh7-0002RL-QU; Wed, 18 Apr 2012 11:05:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKSh6-0002RC-1l
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:05:04 +0000
Received: from [85.158.143.99:6340] by server-3.bemta-4.messagelabs.com id
	BB/BB-05853-FDF9E8F4; Wed, 18 Apr 2012 11:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334747101!23255091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19490 invoked from network); 18 Apr 2012 11:05:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11999132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 11:05:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 12:05:01 +0100
Message-ID: <1334747100.23948.202.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 18 Apr 2012 12:05:00 +0100
In-Reply-To: <4F8D902A.2080607@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 16:45 +0100, Anthony PERARD wrote:
> On 17/04/12 16:30, Ian Campbell wrote:
> > On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
> >> Currently `xl vncviewer $dom` does not work because the VNC port is not
> >> registered in xenstore when using qemu-upstream. This patch attempted to fix
> >> this.
> >
> > libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
> > having such a thing in xenstore strikes me as something of a
> > misfeature...
> 
> Well, I thought of that, but when I tried `xl vncviewer` with a password 
> set, the result was that vncviewer asked me a password. That why I 
> haven't put more effort in querrying the vnc password from QEMU.

Same here even with qemu-xen-traditional.

I'm tempted to suggest that we remove this support -- having plain text
passwords in xenstore (thankfully with perms set somewhat sanely) just
doesn't seem like a Good Thing to me...

> 
> > Otherwise:
> > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> >
> >> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:07:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSj4-0002c3-Gj; Wed, 18 Apr 2012 11:07:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKSj3-0002bo-2Y
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:07:05 +0000
Received: from [193.109.254.147:31686] by server-2.bemta-14.messagelabs.com id
	75/71-19409-850AE8F4; Wed, 18 Apr 2012 11:07:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334747223!5174377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 18 Apr 2012 11:07:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11999174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 11:07:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 12:07:03 +0100
Message-ID: <1334747221.23948.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 12:07:01 +0100
In-Reply-To: <20366.40183.410388.447630@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
	<20365.41550.838083.825783@mariner.uk.xensource.com>
	<1334743970.23948.193.camel@zakaz.uk.xensource.com>
	<20366.40183.410388.447630@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 11:52 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> > On Tue, 2012-04-17 at 18:03 +0100, Ian Jackson wrote:
> > > We should consider another alternative: spawning a copy of xc_save,
> > > like xend does.
> > 
> > I wondered about that too. Does it make things like error handling or
> > reporting any more difficult?
> 
> With threading it's quite tricky.  I think it would be rude to call
> even the application's logging callbacks on a private thread.
> Certainly we can't easily propagate errors from that private thread.
> We would have to arrange somehow to transfer the results to one of the
> application's threads, to avoid possibly calling back to the
> application on our private thread (which is a big no-no because it
> might subject a non-multithreaded application to reentrancy).  And
> even with all that there are vexed problems like the possibility of
> generating an application-wide SIGPIPE on the migration fd.
> 
> So I think it would make it easier, now that we have all the machinery
> in place, to spawn a separate process.  That process should exec, even
> if the thing exec'd is a utility mostly using libxl, firstly to save
> memory (in case we're talking about a huge toolstack daemon) and also
> so we don't have to worry about nonconsensually generating
> long-running non-execing forks of the application (which would require
> us to provide a callback mirror of the postfork noexec downcall).

This sounds sensible to me.

Ian.

> 
> > > libxl__stubdom_spawn_state is a struct containing a
> > > libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
> > > domid is in sdss.stubdom.guest_domid, and because stubdom is first
> > > this is the same as dmss->guest_domid.
> > > 
> > > Maybe this needs a bigger comment ?
> > 
> > At the very least, yes.
> > 
> > Does combining thing in a union in this way really make some other bit
> > of code look substantially better? Not having the union and having a
> > shared libxl__dm_spawn_state in the parent struct seems more straight
> > forward at least from here.
> 
> I will see if there is a better way to do this, perhaps without the
> union.  And try to add more comments.
> 
> > > xspath is no longer optional.
> > 
> > So this comment on libxl__spawn_spawn is wrong?
> > > + * The inner child must soon exit or exec.  If must also soon exit or
> > > + * notify the parent of its successful startup by writing to the
> > > + * xenstore path xspath (or by other means).  xspath may be 0 to
> > > + * indicate that only other means are being used.
> 
> Yes.  It's out of date.  We don't have any processes which do this
> other than with xenstore.  If we introduce them we can make xspath
> maybe be 0.  I've deleted the erroneous comment (and fixed the
> preceding sentence).
> 
> > > Do you think I should s/stubdom/stubdm/ or something ?
> > 
> > yes, or stub_dm for consistency with local_dm. I'd like to eradicate the
> > bare use of the term "stubdom" since it can mean several things
> > (admittedly not really in this context). I suspect I am fighting against
> > the tide here though...
> 
> I see your point and will see what I can do.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:07:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSj4-0002c3-Gj; Wed, 18 Apr 2012 11:07:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKSj3-0002bo-2Y
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:07:05 +0000
Received: from [193.109.254.147:31686] by server-2.bemta-14.messagelabs.com id
	75/71-19409-850AE8F4; Wed, 18 Apr 2012 11:07:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334747223!5174377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 18 Apr 2012 11:07:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="11999174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 11:07:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 12:07:03 +0100
Message-ID: <1334747221.23948.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 12:07:01 +0100
In-Reply-To: <20366.40183.410388.447630@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-18-git-send-email-ian.jackson@eu.citrix.com>
	<1334675843.23948.102.camel@zakaz.uk.xensource.com>
	<20365.41550.838083.825783@mariner.uk.xensource.com>
	<1334743970.23948.193.camel@zakaz.uk.xensource.com>
	<20366.40183.410388.447630@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 11:52 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/24] libxl: ao: convert libxl__spawn_*"):
> > On Tue, 2012-04-17 at 18:03 +0100, Ian Jackson wrote:
> > > We should consider another alternative: spawning a copy of xc_save,
> > > like xend does.
> > 
> > I wondered about that too. Does it make things like error handling or
> > reporting any more difficult?
> 
> With threading it's quite tricky.  I think it would be rude to call
> even the application's logging callbacks on a private thread.
> Certainly we can't easily propagate errors from that private thread.
> We would have to arrange somehow to transfer the results to one of the
> application's threads, to avoid possibly calling back to the
> application on our private thread (which is a big no-no because it
> might subject a non-multithreaded application to reentrancy).  And
> even with all that there are vexed problems like the possibility of
> generating an application-wide SIGPIPE on the migration fd.
> 
> So I think it would make it easier, now that we have all the machinery
> in place, to spawn a separate process.  That process should exec, even
> if the thing exec'd is a utility mostly using libxl, firstly to save
> memory (in case we're talking about a huge toolstack daemon) and also
> so we don't have to worry about nonconsensually generating
> long-running non-execing forks of the application (which would require
> us to provide a callback mirror of the postfork noexec downcall).

This sounds sensible to me.

Ian.

> 
> > > libxl__stubdom_spawn_state is a struct containing a
> > > libxl__dm_spawn_state ("stubdom") as its first member.  So the sdss's
> > > domid is in sdss.stubdom.guest_domid, and because stubdom is first
> > > this is the same as dmss->guest_domid.
> > > 
> > > Maybe this needs a bigger comment ?
> > 
> > At the very least, yes.
> > 
> > Does combining thing in a union in this way really make some other bit
> > of code look substantially better? Not having the union and having a
> > shared libxl__dm_spawn_state in the parent struct seems more straight
> > forward at least from here.
> 
> I will see if there is a better way to do this, perhaps without the
> union.  And try to add more comments.
> 
> > > xspath is no longer optional.
> > 
> > So this comment on libxl__spawn_spawn is wrong?
> > > + * The inner child must soon exit or exec.  If must also soon exit or
> > > + * notify the parent of its successful startup by writing to the
> > > + * xenstore path xspath (or by other means).  xspath may be 0 to
> > > + * indicate that only other means are being used.
> 
> Yes.  It's out of date.  We don't have any processes which do this
> other than with xenstore.  If we introduce them we can make xspath
> maybe be 0.  I've deleted the erroneous comment (and fixed the
> preceding sentence).
> 
> > > Do you think I should s/stubdom/stubdm/ or something ?
> > 
> > yes, or stub_dm for consistency with local_dm. I'd like to eradicate the
> > bare use of the term "stubdom" since it can mean several things
> > (admittedly not really in this context). I suspect I am fighting against
> > the tide here though...
> 
> I see your point and will see what I can do.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:15:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSqs-00032j-FV; Wed, 18 Apr 2012 11:15:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SKSqr-00032e-0j
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:15:09 +0000
Received: from [85.158.143.35:11750] by server-2.bemta-4.messagelabs.com id
	E9/B9-17550-C32AE8F4; Wed, 18 Apr 2012 11:15:08 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334747690!12980968!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4808 invoked from network); 18 Apr 2012 11:14:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:14:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330923600"; d="scan'208";a="190888722"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 07:14:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 07:14:50 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SKSqX-00076O-GL;
	Wed, 18 Apr 2012 12:14:49 +0100
Message-ID: <4F8EA229.9000308@citrix.com>
Date: Wed, 18 Apr 2012 12:14:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
	<1334747100.23948.202.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334747100.23948.202.camel@zakaz.uk.xensource.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/12 12:05, Ian Campbell wrote:
> On Tue, 2012-04-17 at 16:45 +0100, Anthony PERARD wrote:
>> On 17/04/12 16:30, Ian Campbell wrote:
>>> On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
>>>> Currently `xl vncviewer $dom` does not work because the VNC port is not
>>>> registered in xenstore when using qemu-upstream. This patch attempted to fix
>>>> this.
>>>
>>> libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
>>> having such a thing in xenstore strikes me as something of a
>>> misfeature...
>>
>> Well, I thought of that, but when I tried `xl vncviewer` with a password
>> set, the result was that vncviewer asked me a password. That why I
>> haven't put more effort in querrying the vnc password from QEMU.
>
> Same here even with qemu-xen-traditional.

There is actually an option to xl vncviewer: --autopass, so with this, 
no need to enter the vnc pass manually. And it's works fine with the 
traditionnal.

> I'm tempted to suggest that we remove this support -- having plain text
> passwords in xenstore (thankfully with perms set somewhat sanely) just
> doesn't seem like a Good Thing to me...


-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:15:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSqs-00032j-FV; Wed, 18 Apr 2012 11:15:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SKSqr-00032e-0j
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:15:09 +0000
Received: from [85.158.143.35:11750] by server-2.bemta-4.messagelabs.com id
	E9/B9-17550-C32AE8F4; Wed, 18 Apr 2012 11:15:08 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334747690!12980968!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4808 invoked from network); 18 Apr 2012 11:14:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:14:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330923600"; d="scan'208";a="190888722"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 07:14:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 07:14:50 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SKSqX-00076O-GL;
	Wed, 18 Apr 2012 12:14:49 +0100
Message-ID: <4F8EA229.9000308@citrix.com>
Date: Wed, 18 Apr 2012 12:14:49 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
	<1334747100.23948.202.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334747100.23948.202.camel@zakaz.uk.xensource.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/04/12 12:05, Ian Campbell wrote:
> On Tue, 2012-04-17 at 16:45 +0100, Anthony PERARD wrote:
>> On 17/04/12 16:30, Ian Campbell wrote:
>>> On Mon, 2012-04-16 at 19:15 +0100, Anthony PERARD wrote:
>>>> Currently `xl vncviewer $dom` does not work because the VNC port is not
>>>> registered in xenstore when using qemu-upstream. This patch attempted to fix
>>>> this.
>>>
>>> libxl_vncviewer_exec also potentially reads vnc-pass, although frankly
>>> having such a thing in xenstore strikes me as something of a
>>> misfeature...
>>
>> Well, I thought of that, but when I tried `xl vncviewer` with a password
>> set, the result was that vncviewer asked me a password. That why I
>> haven't put more effort in querrying the vnc password from QEMU.
>
> Same here even with qemu-xen-traditional.

There is actually an option to xl vncviewer: --autopass, so with this, 
no need to enter the vnc pass manually. And it's works fine with the 
traditionnal.

> I'm tempted to suggest that we remove this support -- having plain text
> passwords in xenstore (thankfully with perms set somewhat sanely) just
> doesn't seem like a Good Thing to me...


-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSyT-0003E4-HN; Wed, 18 Apr 2012 11:23:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKSyS-0003Dz-CJ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:23:00 +0000
Received: from [85.158.143.99:13869] by server-2.bemta-4.messagelabs.com id
	A7/99-17550-314AE8F4; Wed, 18 Apr 2012 11:22:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334748176!25612383!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzc0OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30416 invoked from network); 18 Apr 2012 11:22:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:22:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330923600"; d="scan'208";a="24268274"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 07:22:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 07:22:55 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKSyM-0007FY-It;
	Wed, 18 Apr 2012 12:22:54 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 12:22:54 +0100
Message-ID: <B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
In-Reply-To: <1334742899.23948.180.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTggQXByIDIwMTIsIGF0IDEwOjU0LCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cgo+IE9uIFR1ZSwg
MjAxMi0wNC0xNyBhdCAxNjo1MSArMDEwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBBcyB0
aGUgcHJldmlvdXMgY2hhbmdlIGFscmVhZHkgaW50cm9kdWNlcyBtb3N0IG9mIG5lZWRlZCBtYWNo
aW5lcnkgdG8gCj4+IGNhbGwKPj4gaG90cGx1ZyBzY3JpcHRzIGZyb20gbGlieGwsIHRoaXMgb25s
eSBhZGRzIHRoZSBuZWNlc3NhcnkgYml0cyB0byBjYWxsIAo+PiB0aGlzCj4+IHNjcmlwdHMgZm9y
IHZpZiBpbnRlcmZhY2VzIGFsc28uCj4+Cj4+IGxpYnhsX2RldmljZV9uaWNfYWRkIGhhcyBiZWVu
IGNoYW5nZWQgdG8gbWFrZSB1c2Ugb2YgdGhlIG5ldyBldmVudAo+PiBmdW5jdGlvbmFsaXR5LCBh
bmQgdGhlIG5lY2Vzc2FyeSB2aWYgaG90cGx1ZyBjb2RlIGhhcyBiZWVuIGFkZGVkLiBObyAKPj4g
Y2hhbmdlcwo+PiB3aGVyZSBuZWVkZWQgaW4gdGhlIHRlYXJkb3duIHBhcnQsIHNpbmNlIGl0IHVz
ZXMgZXhhY3RseSB0aGUgc2FtZSAKPj4gY29kZQo+PiBpbnRyb2R1Y2VkIGZvciB2YmQuCj4+Cj4+
IEFuIGV4Y2VwdGlvbiBoYXMgYmVlbiBpbnRyb2R1Y2VkIGZvciB0YXAgZGV2aWNlcywgc2luY2Ug
aG90cGx1ZyAKPj4gc2NyaXB0cwo+PiBzaG91bGQgYmUgY2FsbGVkIGFmdGVyIHRoZSBkZXZpY2Ug
bW9kZWwgaGFzIGJlZW4gY3JlYXRlZCwgc28gdGhlIAo+PiBob3RwbHVnCj4+IGNhbGwgZm9yIHRo
b3NlIGlzIGRvbmUgaW4gZG9fZG9tYWluX2NyZWF0ZSBhZnRlciBjb25maXJtYXRpb24gb2YgdGhl
IAo+PiBkZXZpY2UKPj4gbW9kZWwgc3RhcnR1cC4gT24gdGhlIG90aGVyIGhhbmQsIHRhcCBkZXZp
Y2VzIGRvbid0IHVzZSB0ZWFyZG93biAKPj4gc2NyaXB0cywKPj4gc28gYWRkIGFub3RoZXIgZXhj
ZXB0aW9uIGZvciB0aGF0Lgo+Pgo+PiBsaWJ4bF9fZGV2aWNlX2Zyb21fbmljIHdhcyBtb3ZlZCB0
byBsaWJ4bF9kZXZpY2UuYywgc28gaXQgY2FuIGJlIHVzZWQKPj4gaW4gbGlieGxfY3JlYXRlLmMs
IGFuZCBsaWJ4bF9fZGV2aWNlX2Zyb21fZGlzayB3YXMgYWxzbyBtb3ZlZCB0byAKPj4gbWFudGFp
bgo+PiB0aGUgc2ltbWV0cnkuCj4KPiAibWFpbnRhaW4iIGFuZCAic3ltbWV0cnkiCj4KPiBUaGVz
ZSBhcmUgcHVyZSBjb2RlIG1vdGlvbiBvciBkaWQgdGhlIGNvZGUgYWN0dWFsbHkgY2hhbmdlIHRv
bz8KClRoZSBjb2RlIGRpZG4ndCBjaGFuZ2UsIEkganVzdCBtb3ZlZCBpdCBhcm91bmQuCgo+Cj4+
IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlIGhhcyBiZWVuIGNoYW5nZWQgYSBsaXR0bGUs
IHRvIG51a2UgdGhlIAo+PiBmcm9udGVuZAo+PiB4ZW5zdG9yZSBwYXRoIGJlZm9yZSB0cnlpbmcg
dG8gcGVyZm9ybSBkZXZpY2UgdGVhcmRvd24sIHRoaXMgYWxsb3dzIAo+PiBmb3IKPj4gdW5pdGlh
bGl6ZWQgZGV2aWNlcyB0byBiZSBjbG9zZWQgZ3JhY2VmdWxseSwgc3BlY2lhbGx5IHZpZiBpbnRl
cmZhY2VzIAo+PiBhZGRlZCB0bwo+Cj4gdW5pbml0aWFsaXplZCAob3IgLWlzZWQpCj4KPj4gSFZN
IG1hY2hpbmVzIGFuZCBub3QgdXNlZC4KPj4KPj4gUFYgbmljIGRldmljZXMgYXJlIHNldCB0byBM
SUJYTF9OSUNfVFlQRV9WSUYsIHNpbmNlIHRoZSBkZWZhdWx0IHZhbHVlIAo+PiBpcwo+PiBMSUJY
TF9OSUNfVFlQRV9JT0VNVSByZWdhcmRsZXNzIG9mIHRoZSBndWVzdCB0eXBlLgo+Pgo+PiBBIG5l
dyBnb2JhbCBvcHRpb24sIGNhbGxlZCBkaXNhYmxlX3ZpZl9zY3JpcHRzIGhhcyBiZWVuIGFkZGVk
IHRvIAo+PiBhbGxvdyB0aGUgdXNlcgo+Cj4gICAgZ2xvYmFsCj4KPj4gZGVjaWRlIGlmIGhlIHdh
bnRzIHRvIGV4ZWN1dGUgdGhlIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsIG9yIGZyb20gCj4+IHVk
ZXYuIFRoaXMgaGFzCj4+IGJlZW4gZG9jdW1lbnRlZCBpbiB0aGUgeGwuY29uZiBtYW4gcGFnZS4K
Pgo+IERpZCB5b3UgZG8gdGhpcyBmb3IgYmxvY2sgdG9vPwoKTm9wZSwgb25seSBmb3IgdmlmIGlu
dGVyZmFjZXMsIHRoYXQgYXJlIHRoZSBvbmx5IG9uZXMgdGhhdCBoYXZlIHNvbWUgCmtpbmQgb2Yg
bGltaXRlZCBzdXBwb3J0IGZvciB0aGUgZHJpdmVyIGRvbWFpbnMgdGhpbmcgd2hlbiBjYWxsZWQg
ZnJvbSAKdWRldi4KCj4+Cj4+IENoYW5nZXMgc2luY2UgdjE6Cj4+Cj4+ICogUHJvcGFnYXRlZCBj
aGFuZ2VzIGZyb20gcHJldmlvdXMgcGF0Y2ggKGRpc2FibGVfdWRldiBhbmQgCj4+IGxpYnhsX2Rl
dmljZV9uaWNfYWRkCj4+IHN3aXRjaCkuCj4+Cj4+ICogTW9kaWZpZWQgdWRldiBydWxlcyB0byBh
ZGQgdGhlIG5ldyBlbnYgdmFyaWFibGUuCj4+Cj4+ICogQWRkZWQgc3VwcG9ydCBmb3IgbmFtZWQg
aW50ZXJmYWNlcy4KPj4KPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5w
YXVAY2l0cml4LmNvbT4KPj4gLS0tCj4+IGRvY3MvbWFuL3hsLmNvbmYucG9kLjUgICAgICAgICAg
ICAgICAgfCAgICA3ICsrCj4+IHRvb2xzL2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMg
fCAgICA2ICstCj4+IHRvb2xzL2xpYnhsL2xpYnhsLmMgICAgICAgICAgICAgICAgICAgfCAgIDkw
ICsrKysrKystLS0tLS0tLS0tLS0tCj4+IHRvb2xzL2xpYnhsL2xpYnhsLmggICAgICAgICAgICAg
ICAgICAgfCAgICAzICstCj4+IHRvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jICAgICAgICAgICAg
fCAgIDIyICsrKysrLQo+PiB0b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYyAgICAgICAgICAgIHwg
ICA3NyArKysrKysrKysrKysrKystLQo+PiB0b29scy9saWJ4bC9saWJ4bF9kbS5jICAgICAgICAg
ICAgICAgIHwgICAgMiArLQo+PiB0b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oICAgICAgICAg
IHwgICAgNiArKwo+PiB0b29scy9saWJ4bC9saWJ4bF9saW51eC5jICAgICAgICAgICAgIHwgIDE1
MCAKPj4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCj4+IHRvb2xzL2xpYnhsL2xp
YnhsX3R5cGVzLmlkbCAgICAgICAgICAgfCAgICAxICsKPj4gdG9vbHMvbGlieGwveGwuYyAgICAg
ICAgICAgICAgICAgICAgICB8ICAgIDQgKwo+PiB0b29scy9saWJ4bC94bC5oICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgMSArCj4+IHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyAgICAgICAgICAg
ICAgfCAgIDE1ICsrKy0KPj4gMTMgZmlsZXMgY2hhbmdlZCwgMzA4IGluc2VydGlvbnMoKyksIDc2
IGRlbGV0aW9ucygtKQo+Pgo+PiBkaWZmIC0tZ2l0IGEvZG9jcy9tYW4veGwuY29uZi5wb2QuNSBi
L2RvY3MvbWFuL3hsLmNvbmYucG9kLjUKPj4gaW5kZXggOGJkNDVlYS4uY2YyYzQ3NyAxMDA2NDQK
Pj4gLS0tIGEvZG9jcy9tYW4veGwuY29uZi5wb2QuNQo+PiArKysgYi9kb2NzL21hbi94bC5jb25m
LnBvZC41Cj4+IEBAIC01NSw2ICs1NSwxMyBAQCBkZWZhdWx0Lgo+Pgo+PiBEZWZhdWx0OiBDPDE+
Cj4+Cj4+ICs9aXRlbSBCPGRpc2FibGVfdmlmX3NjcmlwdHM9Qk9PTEVBTj4KPj4gKwo+PiArSWYg
ZW5hYmxlZCB4bCB3aWxsIG5vdCBleGVjdXRlIG5pYyBob3RwbHVnIHNjcmlwdHMgaXRzZWxmLCBh
bmQgCj4+IGluc3RlYWQKPj4gK3JlbGVnYXRlIHRoaXMgdGFzayB0byB1ZGV2Lgo+PiArCj4+ICtE
ZWZhdWx0OiBDPDA+Cj4KPiBQbGVhc2UgY2FuIHlvdSBhbHNvIGFkZCBhIGNvbW1lbnRlZCBvdXQg
dmVyc2lvbgo+IHRvIC4vdG9vbHMvZXhhbXBsZXMveGwuY29uZiwgd2l0aCB0aGUgdmFsdWUgb2Yg
dGhlIGRlZmF1bHQuCj4KPiBUaGlzIGRvZXNuJ3QgYWN0dWFsbHkgZGlzYWJsZSB0aGUgc2NyaXB0
cyBlbnRpcmVseSwgYnV0IHJhdGhlciBvbmx5IAo+IGZyb20KPiB1ZGV2LCBkaXNhYmxlX3VkZXZf
dmlmX3NjcmlwdHMgcGVyaGFwcz8KCkl0IGFjdHVhbGx5IGRpc2FibGVzIHNjcmlwdCBjYWxsaW5n
IGZyb20gbGlieGwsIHNvIEkgdGhpbmsgaXQgbWlnaHQgYmUgCmJlc3QgdG8gY2FsbCBpdCBkaXNh
YmxlX3hsX3ZpZl9zY3JpcHRzPwoKPgo+PiA9aXRlbSBCPGxvY2tmaWxlPSJQQVRIIj4KPj4KPj4g
U2V0cyB0aGUgcGF0aCB0byB0aGUgbG9jayBmaWxlIHVzZWQgYnkgeGwgdG8gc2VyaWFsaXNlIGNl
cnRhaW4KPj4gQEAgLTE5MjksMTQgKzE4ODMsMzAgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRk
KGxpYnhsX2N0eCAqY3R4LCAKPj4gdWludDMyX3QgZG9taWQsIGxpYnhsX2RldmljZV9uaWMgKm5p
YykKPj4gICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX194c19rdnNfb2ZfZmxleGFycmF5
KGdjLCBiYWNrLCAKPj4gYmFjay0+Y291bnQpLAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAg
bGlieGxfX3hzX2t2c19vZl9mbGV4YXJyYXkoZ2MsIGZyb250LCAKPj4gZnJvbnQtPmNvdW50KSk7
Cj4+Cj4+IC0gICAgLyogRklYTUU6IHdhaXQgZm9yIHBsdWcgKi8KPj4gKyAgICBzd2l0Y2gobmlj
LT5uaWN0eXBlKSB7Cj4+ICsgICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9WSUY6Cj4+ICsgICAgICAg
IGlmICghbmljLT5kaXNhYmxlX3ZpZl9zY3JpcHQpIHsKPj4gKyAgICAgICAgICAgIHJjID0gbGli
eGxfX2luaXRpYXRlX2RldmljZV9hZGQoZWdjLCBhbywgJmRldmljZSk7Cj4+ICsgICAgICAgICAg
ICBpZiAocmMpIGdvdG8gb3V0X2ZyZWU7Cj4+ICsgICAgICAgIH0KPgo+IFlvdSBkb24ndCBuZWVk
IGFuIGFvX2NvbXBsZXRlIGluIHRoZSBlbHNlIGNhc2U/CgpTdXJlLCBnb29kIG9uZSwgSSB0aGlu
ayB0aGlzIGtpbmQgb2YgbWVjaGFuaXNtIGlzIHByb25lIHRvIGVycm9yc+KApiAKQU9fSU5QUk9H
UkVTUyBzaG91bGQgY2FsbCBhb19jb21wbGV0ZSBpZiBubyBldmVudHMgaGF2ZSBiZWVuIGFkZGVk
LgoKPj4gKyAgICAgICAgYnJlYWs7Cj4+ICsgICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9JT0VNVToK
Pj4gKyAgICAgICAgLyoKPj4gKyAgICAgICAgICogRG9uJ3QgZXhlY3V0ZSBob3RwbHVnIHNjcmlw
dHMgZm9yIElPRU1VIGludGVyZmFjZXMgeWV0LAo+PiArICAgICAgICAgKiB3ZSBuZWVkIHRvIGxh
dW5jaCB0aGUgZGV2aWNlIG1vZGVsIGZpcnN0Lgo+PiArICAgICAgICAqLwo+Cj4gSXQnZCBiZSB1
c2VmdWwgdG8gYWRkIGEgcmVmZXJlbmNlIHRvIHdoZXJlIHRoZXNlIGFyZSBydW4sIGF0IGZpcnN0
IEkKPiB0aG91Z2h0IHRoaXMgY29tbWVudCAoYW5kIHRoZSBwYXRjaCB0byB4ZW4tYmFja2VuZC5y
dWxlcykgbWVhbnQgdGhleQo+IHdlcmVuJ3QgYmVpbmcgcnVuIGF0IGFsbC4KCkRvbmUgSSd2ZSBh
ZGRlZCBhIHNtYWxsIG5vdGUgc2F5aW5nIHdoZXJlIHRoZXkgYXJlIGNhbGxlZC4KCj4KPj4gZGlm
ZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jIGIvdG9vbHMvbGlieGwvbGlieGxf
Y3JlYXRlLmMKPj4gaW5kZXggZGU1OThhZC4uYTFmNTczMSAxMDA2NDQKPj4gLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfY3JlYXRlLmMKPj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMK
Pj4gQEAgLTYwNyw3ICs2MDcsNyBAQCBzdGF0aWMgaW50IGRvX2RvbWFpbl9jcmVhdGUobGlieGxf
X2djICpnYywgCj4+IGxpYnhsX2RvbWFpbl9jb25maWcgKmRfY29uZmlnLAo+PiAgICAgfQo+PiB9
Cj4+IGZvciAoaSA9IDA7IGkgPCBkX2NvbmZpZy0+bnVtX3ZpZnM7IGkrKykgewo+PiAtICAgICAg
ICByZXQgPSBsaWJ4bF9kZXZpY2VfbmljX2FkZChjdHgsIGRvbWlkLCAmZF9jb25maWctPnZpZnNb
aV0pOwo+PiArICAgICAgICByZXQgPSBsaWJ4bF9kZXZpY2VfbmljX2FkZChjdHgsIGRvbWlkLCAm
ZF9jb25maWctPnZpZnNbaV0sIAo+PiAwKTsKPj4gICAgIGlmIChyZXQpIHsKPj4gICAgICAgICBM
SUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gICAgICAgICAgICAgICAgICAgICJj
YW5ub3QgYWRkIG5pYyAlZCB0byBkb21haW46ICVkIiwgaSwgcmV0KTsKPj4gQEAgLTY4NSw2ICs2
ODUsMjYgQEAgc3RhdGljIGludCBkb19kb21haW5fY3JlYXRlKGxpYnhsX19nYyAqZ2MsIAo+PiBs
aWJ4bF9kb21haW5fY29uZmlnICpkX2NvbmZpZywKPj4gICAgICAgICAgICAgICAgICAgICJkZXZp
Y2UgbW9kZWwgZGlkIG5vdCBzdGFydDogJWQiLCByZXQpOwo+PiAgICAgICAgIGdvdG8gZXJyb3Jf
b3V0Owo+PiAgICAgfQo+PiArICAgICAgICAvKgo+PiArICAgICAgICAgKiBFeGVjdXRlIGhvdHBs
dWcgc2NyaXB0cyBmb3IgdGFwIGRldmljZXMsIHRoaXMgaGFzIHRvIGJlIAo+PiBkb25lCj4+ICsg
ICAgICAgICAqIGFmdGVyIHRoZSBkb21haW4gbW9kZWwgaGFzIGJlZW4gc3RhcnRlZC4KPj4gKyAg
ICAgICAgKi8KPj4gKyAgICAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fdmlmczsg
aSsrKSB7Cj4+ICsgICAgICAgICAgICBpZiAoZF9jb25maWctPnZpZnNbaV0ubmljdHlwZSA9PSBM
SUJYTF9OSUNfVFlQRV9JT0VNVSAmJgo+PiArICAgICAgICAgICAgICAgICFkX2NvbmZpZy0+dmlm
c1tpXS5kaXNhYmxlX3ZpZl9zY3JpcHQpIHsKPj4gKyAgICAgICAgICAgICAgICBsaWJ4bF9fZGV2
aWNlIGRldmljZTsKPj4gKyAgICAgICAgICAgICAgICByZXQgPSBsaWJ4bF9fZGV2aWNlX2Zyb21f
bmljKGdjLCBkb21pZCwgCj4+ICZkX2NvbmZpZy0+dmlmc1tpXSwKPj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkZXZpY2UpOwo+PiArICAgICAgICAgICAg
ICAgIGlmIChyZXQgPCAwKSBnb3RvIGVycm9yX291dDsKPj4gKyAgICAgICAgICAgICAgICByZXQg
PSBsaWJ4bF9fZGV2aWNlX2hvdHBsdWcoZ2MsICZkZXZpY2UsIENPTk5FQ1QpOwo+Cj4gSSBzaG91
bGQgaGF2ZSBhc2tlZCB0aGlzIGluIDMvNSBidXQgZG9lcyB0aGlzIGZ1bmN0aW9uIG5vdCBuZWVk
IHRvIGJlCj4gYXN5bmMsIHNpbmNlIHRoZSBzY3JpcHQgbWlnaHQgdGFrZSBhIHdoaWxlIGFuZCB3
ZSBuZWVkIHRvIHdhaXQgZm9yIGl0IAo+IHRvCj4gY29tcGxldGUgYmVmb3JlIGNvbnRpbnVpbmc/
CgpBcmUgeW91IHN1cmUgd2UgbmVlZCB0byB3YWl0IGZvciBpdCB0byBmaW5pc2g/IFRoZXJlIHdh
c24ndCBhbnkga2luZCBvZiAKc3luY2hyb25pemF0aW9uIGluIHRoZSBwYXN0IHdoZW4gd2UgY2Fs
bGVkIHRoZSBzY3JpcHRzIGZyb20gdWRldiwgc28gSSAKZ3Vlc3Mgd2UgZG9uJ3QgaGF2ZSB0byB3
YWl0IGVpdGhlciBmb3IgdGhlbSB0byBmaW5pc2guCgo+Cj4+ICsgICAgICAgICAgICAgICAgaWYg
KHJldCA8IDApIHsKPj4gKyAgICAgICAgICAgICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhM
X19MT0dfRVJST1IsCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInVuYWJsZSB0
byBsYXVuY2ggaG90cGx1ZyBzY3JpcHQgZm9yIAo+PiBkZXZpY2U6ICIKPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAiJSJQUkl1MzIsIGRldmljZS5kZXZpZCk7Cj4+ICsgICAgICAg
ICAgICAgICAgICAgIGdvdG8gZXJyb3Jfb3V0Owo+PiArICAgICAgICAgICAgICAgIH0KPj4gKyAg
ICAgICAgICAgIH0KPj4gKyAgICAgICAgfQo+PiB9Cj4+Cj4+IGZvciAoaSA9IDA7IGkgPCBkX2Nv
bmZpZy0+bnVtX3BjaWRldnM7IGkrKykKPiBbLi4uXQo+PiBAQCAtNDUwLDIyICs1MDQsMjkgQEAg
aW50IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlKGxpYnhsX19lZ2MgCj4+ICplZ2MsIGxp
YnhsX19hbyAqYW8sCj4+IHsKPj4gQU9fR0M7Cj4+IGxpYnhsX2N0eCAqY3R4ID0gbGlieGxfX2dj
X293bmVyKGdjKTsKPj4gLSAgICB4c190cmFuc2FjdGlvbl90IHQ7Cj4+ICsgICAgeHNfdHJhbnNh
Y3Rpb25fdCB0ID0gMDsKPj4gY2hhciAqYmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfYmFja2VuZF9w
YXRoKGdjLCBkZXYpOwo+PiBjaGFyICpzdGF0ZV9wYXRoID0gbGlieGxfX3NwcmludGYoZ2MsICIl
cy9zdGF0ZSIsIGJlX3BhdGgpOwo+PiAtICAgIGNoYXIgKnN0YXRlID0gbGlieGxfX3hzX3JlYWQo
Z2MsIFhCVF9OVUxMLCBzdGF0ZV9wYXRoKTsKPj4gKyAgICBjaGFyICpzdGF0ZTsKPj4gaW50IHJj
ID0gMDsKPj4gbGlieGxfX2FvX2RldmljZV9yZW1vdmUgKmFvcm0gPSAwOwo+Pgo+PiArICAgIC8q
Cj4+ICsgICAgICogTnVrZSBmcm9udGVuZCB0byBmb3JjZSBiYWNrZW5kIHRlYXJkb3duCj4+ICsg
ICAgICogSXQncyBub3QgcHJldHR5LCBidXQgaXQncyB0aGUgb25seSB3YXkgdGhhdCBzZWVtcyB0
byB3b3JrIGZvciAKPj4gYWxsCj4+ICsgICAgICogdHlwZXMgb2YgYmFja2VuZHMKPj4gKyAgICAg
Ki8KPgo+IEknbSBzdGlsbCBub3QgaGFwcHkgd2l0aCB0aGlzLiBUaGUgX3JlbW92ZSBmdW5jdGlv
bnMgYXJlIHN1cHBvc2VkIHRvIAo+IGJlCj4gYSBncmFjZWZ1bCArIGNvLW9wZXJhdGl2ZSByZW1v
dmUsIHRoYXQgbWVhbnMgcHJvZGRpbmcgdGhlIGZyb250IGFuZAo+IGJhY2tlbmQgaW50byBkb2lu
ZyB0aGUgY29udHJvbGxlZCB0ZWFyZG93biBkYW5jZS4KPgo+IFRoaXMgbWF5IHdlbGwgdGFrZSBz
b21lIHRpbWUgYW5kIG1heSBldmVuIGZhaWwgYWZ0ZXIgc29tZSB0aW1lb3V0Cj4gZGVwZW5kaW5n
IG9uIHRoZSBkZXZpY2UgdHlwZSwgZ3Vlc3QgY29uZmlndXJhdGlvbiBhbmQgY28tb3BlcmF0aW9u
IAo+IGV0YywKPiBidXQgdGhhdCBpcyBleHBlY3RlZCBhbmQgc2hvdWxkIGJlIGhhbmRsZWQuCj4K
PiBGb3JjaW5nIHRoaW5ncyBpbiB0aGlzIHdheSBpcyBhcHByb3ByaWF0ZSBmb3IgZGV2aWNlX2Rl
c3Ryb3kgb25seSBJTUhPCj4gc2luY2UgdGhhdCBpcyB0aGUgZnVuY3Rpb24gd2hpY2ggaXMgcHJv
dmlkZWQgZm9yIHVzZSB3aGVuIHRoZSBndWVzdCBpcwo+IG5vdCBjby1vcGVyYXRpbmcuCgpCZWZv
cmUgdGhpcyBwYXRjaCwgd2UgdXNlZCB0byBqdXN0IG51a2UgYm90aCBmcm9udCBhbmQgYmFjayB4
ZW5zdG9yZSAKZGlyZWN0b3JpZXMgKGJlY2F1c2Ugd2UgYWx3YXlzIGNhbGxlZCBsaWJ4bF9fZGV2
aWNlX2Rlc3Ryb3kpLCBzbyBJIHRoaW5rIAp0aGlzIGlzIHF1aXRlIGFuZCBpbXByb3ZlbWVudCBp
biB0ZXJtIG9mIGNvLW9wZXJhdGlvbiB0aGFuIHdoYXQgd2UgaGFkIApiZWZvcmUuIFdlIG9ubHkg
dXNlZCB0aGlzIGtpbmQgb2YgbmVnb3RpYXRpb24gd2hlbiBkZXRhY2hpbmcgYSBibG9jayAKZnJv
bSBhIGxpdmUgZ3Vlc3QuCgo+Cj4+ICsgICAgbGlieGxfX3hzX3BhdGhfY2xlYW51cChnYywgbGli
eGxfX2RldmljZV9mcm9udGVuZF9wYXRoKGdjLCAKPj4gZGV2KSk7Cj4+ICsKPj4gK3JldHJ5X3Ry
YW5zYWN0aW9uOgo+PiArICAgIHQgPSB4c190cmFuc2FjdGlvbl9zdGFydChjdHgtPnhzaCk7Cj4+
ICsgICAgc3RhdGUgPSBsaWJ4bF9feHNfcmVhZChnYywgdCwgc3RhdGVfcGF0aCk7Cj4+IGlmICgh
c3RhdGUpCj4+ICAgICBnb3RvIG91dF9vazsKPj4gLSAgICBpZiAoYXRvaShzdGF0ZSkgIT0gNCkg
ewo+PiArICAgIGlmIChhdG9pKHN0YXRlKSA9PSBYZW5idXNTdGF0ZUNsb3NlZCkKPj4gICAgIGxp
YnhsX19kZXZpY2VfZGVzdHJveV90YXBkaXNrKGdjLCBiZV9wYXRoKTsKPj4gICAgIGdvdG8gb3V0
X29rOwo+PiAtICAgIH0KPj4KPj4gLXJldHJ5X3RyYW5zYWN0aW9uOgo+PiAtICAgIHQgPSB4c190
cmFuc2FjdGlvbl9zdGFydChjdHgtPnhzaCk7Cj4+IHhzX3dyaXRlKGN0eC0+eHNoLCB0LCBsaWJ4
bF9fc3ByaW50ZihnYywgIiVzL29ubGluZSIsIGJlX3BhdGgpLCAiMCIsIAo+PiBzdHJsZW4oIjAi
KSk7Cj4+IHhzX3dyaXRlKGN0eC0+eHNoLCB0LCBzdGF0ZV9wYXRoLCAiNSIsIHN0cmxlbigiNSIp
KTsKPj4gaWYgKCF4c190cmFuc2FjdGlvbl9lbmQoY3R4LT54c2gsIHQsIDApKSB7Cj4+IEBAIC00
NzYsNiArNTM3LDggQEAgcmV0cnlfdHJhbnNhY3Rpb246Cj4+ICAgICAgICAgZ290byBvdXRfZmFp
bDsKPj4gICAgIH0KPj4gfQo+PiArICAgIC8qIG1hcmsgdHJhbnNhY3Rpb24gYXMgZW5kZWQsIHRv
IHByZXZlbnQgZG91YmxlIGNsb3NpbmcgaXQgb24gCj4+IG91dF9vayAqLwo+PiArICAgIHQgPSAw
Owo+Pgo+PiBsaWJ4bF9fZGV2aWNlX2Rlc3Ryb3lfdGFwZGlzayhnYywgYmVfcGF0aCk7Cj4+Cj4+
IEBAIC00OTcsOCArNTYwLDggQEAgcmV0cnlfdHJhbnNhY3Rpb246Cj4+IHJldHVybiByYzsKPj4K
Pj4gb3V0X29rOgo+PiArICAgIGlmICh0KSB4c190cmFuc2FjdGlvbl9lbmQoY3R4LT54c2gsIHQs
IDApOwo+PiByYyA9IGxpYnhsX19kZXZpY2VfaG90cGx1ZyhnYywgZGV2LCBESVNDT05ORUNUKTsK
Pj4gLSAgICBsaWJ4bF9feHNfcGF0aF9jbGVhbnVwKGdjLCBsaWJ4bF9fZGV2aWNlX2Zyb250ZW5k
X3BhdGgoZ2MsIAo+PiBkZXYpKTsKPj4gbGlieGxfX3hzX3BhdGhfY2xlYW51cChnYywgYmVfcGF0
aCk7Cj4+IHJldHVybiAwOwo+PiB9Cj4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9s
aW51eC5jIGIvdG9vbHMvbGlieGwvbGlieGxfbGludXguYwo+PiBpbmRleCBjNTU4M2FmLi4xZWYy
ODJmIDEwMDY0NAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9saW51eC5jCj4+ICsrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPj4gQEAgLTI3LDExICsyNywzMCBAQCBpbnQgbGlieGxf
X3RyeV9waHlfYmFja2VuZChtb2RlX3Qgc3RfbW9kZSkKPj4gfQo+Pgo+PiAvKiBIb3RwbHVnIHNj
cmlwdHMgaGVscGVycyAqLwo+PiArCj4+ICtzdGF0aWMgbGlieGxfbmljX3R5cGUgZ2V0X25pY190
eXBlKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgCj4+ICpkZXYpCj4+ICt7Cj4+ICsgICAg
bGlieGxfY3R4ICpjdHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+PiArICAgIGNoYXIgKnNuaWN0
eXBlLCAqYmVfcGF0aDsKPj4gKwo+PiArICAgIGJlX3BhdGggPSBsaWJ4bF9fZGV2aWNlX2JhY2tl
bmRfcGF0aChnYywgZGV2KTsKPj4gKwo+PiArICAgIHNuaWN0eXBlID0gbGlieGxfX3hzX3JlYWQo
Z2MsIFhCVF9OVUxMLAo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX19zcHJp
bnRmKGdjLCAiJXMvJXMiLCBiZV9wYXRoLCAKPj4gInR5cGUiKSk7Cj4KPiBUaGlzIHJlYWxseSBv
dWdodCB0byBiZSB1bmRlciBzb21lIHByaXZhdGUgbGlieGwgcGF0aCByZWxhdGluZyB0byB0aGUK
PiBkZXZpY2UgcmF0aGVyIHRoYW4gdW5kZXIgdGhlIGJhY2tlbmQvZnJvbnRlbmQgdmlzaWJsZSBk
aXJzLgoKV2VsbCwgdGhpcyBpcyBjdXJyZW50bHkgb25seSB1c2VkIGJ5IGxpYnhsLCBidXQgdGhl
IHR5cGUgb2YgdGhlIGJhY2tlbmQgCnVzZWQgSSB0aGluayBzaG91bGQgYmUgaW5zaWRlIHRoZSBi
YWNrZW5kIGRldmljZSBkaXJlY3RvcnksIHNpbmNlIG90aGVyIAphcHBsaWNhdGlvbnMgbWlnaHQg
YWxzbyB3YW50IHRvIGtub3cgdGhpcy4KCj4gQWN0dWFsbHksIG5vdyBJIHRoaW5rIG9mIGl0LCB0
aGF0IGlzIGFsc28gdHJ1ZSBvZiB0aGUgdWRldl9kaXNhYmxlIAo+IGtleT8KClRoaXMgaXMgcHJv
YmFibHkgdHJ1ZSBmb3IgdWRldl9kaXNhYmxlLCBzb21ldGhpbmcgbGlrZSAKL2xpYnhsL2Rldmlj
ZXMvPGRvbWlkPi88ZGV2aWQ+L3VkZXZfZGlzYWJsZT8gSSB3aWxsIGhhdmUgdG8gbW9kaWZ5IAps
aWJ4bF9fZGV2aWNlX2dlbmVyaWNfYWRkIHRvIGRvIHRoaXMsIGJlY2F1c2UgaXQgc2hvdWxkIGJl
IGRvbmUgb24gdGhlIApzYW1lIHRyYW5zYWN0aW9uIHdoZW4gdGhlIGRldmljZSBpcyBhZGRlZC4g
SSdtIG5vdCBzdXJlIGlmIHdlIG5lZWQgdG8gCmFkZCBzbyBtdWNoIG92ZXJoZWFkIGZvciBqdXN0
IG9uZSB4ZW5zdG9yZSBlbnRyeSwgdGhhdCB3aWxsIGdvIGF3YXkgaW4gCnRoZSBuZXh0IHJlbGVh
c2UgcHJvYmFibHkuCgo+IFlvdSBjb3VsZCBhbHNvIHVzZSB0aGUgaGFuZHkgZW51bSB0by9mcm9t
X3N0cmluZ3MgZnVuY3Rpb25zIHRvIGxlYXZlIAo+IG9uZQo+IGxlc3MgbWFnaWMgbnVtYmVyIGlu
IHhlbnN0b3JlLgoKWWVzLgoKPgo+PiArICAgIGlmICghc25pY3R5cGUpIHsKPj4gKyAgICAgICAg
TElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gcmVhZCBuaWN0eXBl
IAo+PiBmcm9tICVzIiwKPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGJlX3BhdGgpOwo+PiArICAgICAgICByZXR1cm4gLTE7Cj4+ICsgICAgfQo+PiArCj4+ICsg
ICAgcmV0dXJuIGF0b2koc25pY3R5cGUpOwo+PiArfQo+PiArCj4+IEBAIC02Miw2ICs4MSwzNSBA
QCBzdGF0aWMgY2hhciAqKmdldF9ob3RwbHVnX2VudihsaWJ4bF9fZ2MgKmdjLCAKPj4gbGlieGxf
X2RldmljZSAqZGV2KQo+PiAgICAgICAgICAgICAgIGRldi0+ZG9taWQsIGRldi0+ZGV2aWQpKTsK
Pj4gZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgIlhFTkJVU19CQVNFX1BBVEgiKTsKPj4gZmxl
eGFycmF5X3NldChmX2VudiwgbnIrKywgImJhY2tlbmQiKTsKPj4gKyAgICBpZiAoZGV2LT5iYWNr
ZW5kX2tpbmQgPT0gTElCWExfX0RFVklDRV9LSU5EX1ZJRikgewo+PiArICAgICAgICBpZm5hbWUg
PSBsaWJ4bF9feHNfcmVhZChnYywgWEJUX05VTEwsIGxpYnhsX19zcHJpbnRmKGdjLCAKPj4gIiVz
LyVzIiwKPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCj4+IGJlX3BhdGgsCj4+ICsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo+PiAidmlmbmFtZSIp
KTsKPj4gKyAgICAgICAgc3dpdGNoIChnZXRfbmljX3R5cGUoZ2MsIGRldikpIHsKPj4gKyAgICAg
ICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9JT0VNVToKPj4gKyAgICAgICAgICAgIGZsZXhhcnJheV9z
ZXQoZl9lbnYsIG5yKyssICJJTlRFUkZBQ0UiKTsKPj4gKyAgICAgICAgICAgIGlmIChpZm5hbWUp
IHsKPj4gKyAgICAgICAgICAgICAgICBmbGV4YXJyYXlfc2V0KGZfZW52LCBucisrLCBsaWJ4bF9f
c3ByaW50ZihnYywgCj4+ICJ4ZW50YXAtJXMiLAo+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPj4gaWZuYW1lKSk7Cj4+ICsg
ICAgICAgICAgICB9IGVsc2Ugewo+PiArICAgICAgICAgICAgICAgIGZsZXhhcnJheV9zZXQoZl9l
bnYsIG5yKyssCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fc3ByaW50
ZihnYywgInhlbnRhcCV1LiVkIiwKPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRl
di0+ZG9taWQsIGRldi0+ZGV2aWQpKTsKPgo+IFRoaXMgaXMgY3V0LW4tcGFzdGUgb2Ygc29tZSBv
dGhlciBjb2RlLCBwZXJoYXBzIGNyZWF0ZSBhIGZ1bmN0aW9uIHRvIAo+IGdldAo+IHRoZSB0YXAg
bmFtZSBmcm9tIHRoZSB2aWYgbmFtZSBhbmQgb3IgZG9tL2RldmlkPwoKCkFyZSB5b3UgZ29pbmcg
dG8gYWRkIGl0IHRvIHlvdXIgcGF0Y2ggb3IgSSBzaG91bGQgYWRkIGl0IHRvIG1pbmU/IApTb21l
dGhpbmcgbGlrZToKCmNoYXIgKmxpYnhsX19kZXZpY2VfdGFwX25hbWUobGlieGxfX2djICpnYywg
bGlieGxfX2RldmljZSAqZGV2KQoKPj4gKyAgICAgICAgICAgIH0KPj4gKyAgICAgICAgY2FzZSBM
SUJYTF9OSUNfVFlQRV9WSUY6Cj4+ICsgICAgICAgICAgICBmbGV4YXJyYXlfc2V0KGZfZW52LCBu
cisrLCAidmlmIik7Cj4+ICsgICAgICAgICAgICBpZiAoaWZuYW1lKSB7Cj4+ICsgICAgICAgICAg
ICAgICAgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgaWZuYW1lKTsKPj4gKyAgICAgICAgICAg
IH0gZWxzZSB7Cj4+ICsgICAgICAgICAgICAgICAgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywK
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX19zcHJpbnRmKGdjLCAidmlm
JXUuJWQiLAo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGV2LT5kb21pZCwgZGV2
LT5kZXZpZCkpOwo+PiArICAgICAgICAgICAgfQo+Cj4gTGlrZXdpc2UKCmNoYXIgKmxpYnhsX19k
ZXZpY2VfdmlmX25hbWUobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAqZGV2KQoKQm90aCB0
aGlzIGZ1bmN0aW9ucyBzaG91bGQgcmV0dXJuIHRoZSBjb3JyZWN0IHZpZm5hbWUgaWYgb25lIGlz
IHNldCwgb3IgCnRoZSBkZWZhdWx0IG9uZSBvdGhlcndpc2UuCgo+PiArICAgICAgICAgICAgYnJl
YWs7Cj4+ICsgICAgICAgIGRlZmF1bHQ6Cj4+ICsgICAgICAgICAgICByZXR1cm4gTlVMTDsKPj4g
KyAgICAgICAgfQo+PiArICAgIH0KPj4KPj4gZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgTlVM
TCk7Cj4+Cj4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMKPj4gaW5kZXggMDFmZjM2My4uNDEyMzBhNiAxMDA2NDQKPj4gLS0t
IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCj4+ICsrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYwo+PiBAQCAtODQ2LDYgKzg0NiwxOSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0
YShjb25zdCBjaGFyIAo+PiAqY29uZmlnZmlsZV9maWxlbmFtZV9yZXBvcnQsCj4+ICAgICAgICAg
ICAgIG5pYy0+c2NyaXB0ID0gc3RyZHVwKGRlZmF1bHRfdmlmc2NyaXB0KTsKPj4gICAgICAgICB9
Cj4+Cj4+ICsgICAgICAgICAgICAvKiBTZXQgZGVmYXVsdCBuaWMgdHlwZSBmb3IgUFYgZ3Vlc3Rz
IGNvcnJlY3RseSAqLwo+PiArICAgICAgICAgICAgaWYgKGJfaW5mby0+dHlwZSA9PSBMSUJYTF9E
T01BSU5fVFlQRV9QVikgewo+PiArICAgICAgICAgICAgICAgIG5pYy0+bmljdHlwZSA9IExJQlhM
X05JQ19UWVBFX1ZJRjsKPj4gKyAgICAgICAgICAgIH0KPgo+IEhybSwgcmVhbGx5IHRoZSBsaWIg
b3VnaHQgdG8gYmUgdGFraW5nIGNhcmUgb2YgdGhhdCBmb3IgdXMuLi4KPgo+IGxpYnhsX19kZXZp
Y2VfbmljX3NldGRlZmF1bHQgaGFzIGEgZG9taWQgc28gaXQgc2hvdWxkIGJlIGFibGUgdG8gcXVl
cnkKPiB0aGUgZG9tYWluIHR5cGUgd2l0aCBsaWJ4bF9fZG9tYWluX3R5cGUuCgpZZXMuCgo+PiAr
ICAgICAgICAgICAgLyoKPj4gKyAgICAgICAgICAgICAqIERpc2FibGUgbmljIG5ldHdvcmsgc2Ny
aXB0IGNhbGxpbmcsIHRvIGFsbG93IHRoZSB1c2VyCj4+ICsgICAgICAgICAgICAgKiB0byBhdHRh
Y2ggdGhlIG5pYyBiYWNrZW5kIGZyb20gYSBkaWZmZXJlbnQgZG9tYWluLgo+PiArICAgICAgICAg
ICAgICovCj4+ICsgICAgICAgICAgICBpZiAoZGlzYWJsZV92aWZfc2NyaXB0cykgewo+PiArICAg
ICAgICAgICAgICAgIG5pYy0+ZGlzYWJsZV92aWZfc2NyaXB0ID0gMTsKPj4gKyAgICAgICAgICAg
IH0KPgo+IFRoaXMgaXMgZXF1aXZhbGVudCB0byA6Cj4gICAgICAgICAgICBuaWMtPmRpc2FibGVf
dmlmX3NjcmlwdCA9IGRpc2FibGVfdmlmX3NjcmlwdHMKClllcywgYW5kIGl0J3Mgb25lIGxpbmUg
bGVzcy4KCj4KPj4gKwo+PiAgICAgICAgaWYgKGRlZmF1bHRfYnJpZGdlKSB7Cj4+ICAgICAgICAg
ICAgZnJlZShuaWMtPmJyaWRnZSk7Cj4+ICAgICAgICAgICAgbmljLT5icmlkZ2UgPSBzdHJkdXAo
ZGVmYXVsdF9icmlkZ2UpOwo+PiBAQCAtNDkwMSw3ICs0OTE0LDcgQEAgaW50IG1haW5fbmV0d29y
a2F0dGFjaChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCj4+ICAgICAgICAgcmV0dXJuIDE7Cj4+ICAg
ICB9Cj4+IH0KPj4gLSAgICBpZiAobGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5p
YykpIHsKPj4gKyAgICBpZiAobGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYywg
MCkpIHsKPj4gICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfZGV2aWNlX25pY19hZGQgZmFpbGVk
LlxuIik7Cj4+ICAgICByZXR1cm4gMTsKPj4gfQo+PiAtLQo+PiAxLjcuNy41IChBcHBsZSBHaXQt
MjYpCj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
Pj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKSyT-0003E4-HN; Wed, 18 Apr 2012 11:23:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKSyS-0003Dz-CJ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:23:00 +0000
Received: from [85.158.143.99:13869] by server-2.bemta-4.messagelabs.com id
	A7/99-17550-314AE8F4; Wed, 18 Apr 2012 11:22:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334748176!25612383!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzc0OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30416 invoked from network); 18 Apr 2012 11:22:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:22:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330923600"; d="scan'208";a="24268274"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 07:22:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 07:22:55 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKSyM-0007FY-It;
	Wed, 18 Apr 2012 12:22:54 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 12:22:54 +0100
Message-ID: <B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
In-Reply-To: <1334742899.23948.180.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTggQXByIDIwMTIsIGF0IDEwOjU0LCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cgo+IE9uIFR1ZSwg
MjAxMi0wNC0xNyBhdCAxNjo1MSArMDEwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBBcyB0
aGUgcHJldmlvdXMgY2hhbmdlIGFscmVhZHkgaW50cm9kdWNlcyBtb3N0IG9mIG5lZWRlZCBtYWNo
aW5lcnkgdG8gCj4+IGNhbGwKPj4gaG90cGx1ZyBzY3JpcHRzIGZyb20gbGlieGwsIHRoaXMgb25s
eSBhZGRzIHRoZSBuZWNlc3NhcnkgYml0cyB0byBjYWxsIAo+PiB0aGlzCj4+IHNjcmlwdHMgZm9y
IHZpZiBpbnRlcmZhY2VzIGFsc28uCj4+Cj4+IGxpYnhsX2RldmljZV9uaWNfYWRkIGhhcyBiZWVu
IGNoYW5nZWQgdG8gbWFrZSB1c2Ugb2YgdGhlIG5ldyBldmVudAo+PiBmdW5jdGlvbmFsaXR5LCBh
bmQgdGhlIG5lY2Vzc2FyeSB2aWYgaG90cGx1ZyBjb2RlIGhhcyBiZWVuIGFkZGVkLiBObyAKPj4g
Y2hhbmdlcwo+PiB3aGVyZSBuZWVkZWQgaW4gdGhlIHRlYXJkb3duIHBhcnQsIHNpbmNlIGl0IHVz
ZXMgZXhhY3RseSB0aGUgc2FtZSAKPj4gY29kZQo+PiBpbnRyb2R1Y2VkIGZvciB2YmQuCj4+Cj4+
IEFuIGV4Y2VwdGlvbiBoYXMgYmVlbiBpbnRyb2R1Y2VkIGZvciB0YXAgZGV2aWNlcywgc2luY2Ug
aG90cGx1ZyAKPj4gc2NyaXB0cwo+PiBzaG91bGQgYmUgY2FsbGVkIGFmdGVyIHRoZSBkZXZpY2Ug
bW9kZWwgaGFzIGJlZW4gY3JlYXRlZCwgc28gdGhlIAo+PiBob3RwbHVnCj4+IGNhbGwgZm9yIHRo
b3NlIGlzIGRvbmUgaW4gZG9fZG9tYWluX2NyZWF0ZSBhZnRlciBjb25maXJtYXRpb24gb2YgdGhl
IAo+PiBkZXZpY2UKPj4gbW9kZWwgc3RhcnR1cC4gT24gdGhlIG90aGVyIGhhbmQsIHRhcCBkZXZp
Y2VzIGRvbid0IHVzZSB0ZWFyZG93biAKPj4gc2NyaXB0cywKPj4gc28gYWRkIGFub3RoZXIgZXhj
ZXB0aW9uIGZvciB0aGF0Lgo+Pgo+PiBsaWJ4bF9fZGV2aWNlX2Zyb21fbmljIHdhcyBtb3ZlZCB0
byBsaWJ4bF9kZXZpY2UuYywgc28gaXQgY2FuIGJlIHVzZWQKPj4gaW4gbGlieGxfY3JlYXRlLmMs
IGFuZCBsaWJ4bF9fZGV2aWNlX2Zyb21fZGlzayB3YXMgYWxzbyBtb3ZlZCB0byAKPj4gbWFudGFp
bgo+PiB0aGUgc2ltbWV0cnkuCj4KPiAibWFpbnRhaW4iIGFuZCAic3ltbWV0cnkiCj4KPiBUaGVz
ZSBhcmUgcHVyZSBjb2RlIG1vdGlvbiBvciBkaWQgdGhlIGNvZGUgYWN0dWFsbHkgY2hhbmdlIHRv
bz8KClRoZSBjb2RlIGRpZG4ndCBjaGFuZ2UsIEkganVzdCBtb3ZlZCBpdCBhcm91bmQuCgo+Cj4+
IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlIGhhcyBiZWVuIGNoYW5nZWQgYSBsaXR0bGUs
IHRvIG51a2UgdGhlIAo+PiBmcm9udGVuZAo+PiB4ZW5zdG9yZSBwYXRoIGJlZm9yZSB0cnlpbmcg
dG8gcGVyZm9ybSBkZXZpY2UgdGVhcmRvd24sIHRoaXMgYWxsb3dzIAo+PiBmb3IKPj4gdW5pdGlh
bGl6ZWQgZGV2aWNlcyB0byBiZSBjbG9zZWQgZ3JhY2VmdWxseSwgc3BlY2lhbGx5IHZpZiBpbnRl
cmZhY2VzIAo+PiBhZGRlZCB0bwo+Cj4gdW5pbml0aWFsaXplZCAob3IgLWlzZWQpCj4KPj4gSFZN
IG1hY2hpbmVzIGFuZCBub3QgdXNlZC4KPj4KPj4gUFYgbmljIGRldmljZXMgYXJlIHNldCB0byBM
SUJYTF9OSUNfVFlQRV9WSUYsIHNpbmNlIHRoZSBkZWZhdWx0IHZhbHVlIAo+PiBpcwo+PiBMSUJY
TF9OSUNfVFlQRV9JT0VNVSByZWdhcmRsZXNzIG9mIHRoZSBndWVzdCB0eXBlLgo+Pgo+PiBBIG5l
dyBnb2JhbCBvcHRpb24sIGNhbGxlZCBkaXNhYmxlX3ZpZl9zY3JpcHRzIGhhcyBiZWVuIGFkZGVk
IHRvIAo+PiBhbGxvdyB0aGUgdXNlcgo+Cj4gICAgZ2xvYmFsCj4KPj4gZGVjaWRlIGlmIGhlIHdh
bnRzIHRvIGV4ZWN1dGUgdGhlIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsIG9yIGZyb20gCj4+IHVk
ZXYuIFRoaXMgaGFzCj4+IGJlZW4gZG9jdW1lbnRlZCBpbiB0aGUgeGwuY29uZiBtYW4gcGFnZS4K
Pgo+IERpZCB5b3UgZG8gdGhpcyBmb3IgYmxvY2sgdG9vPwoKTm9wZSwgb25seSBmb3IgdmlmIGlu
dGVyZmFjZXMsIHRoYXQgYXJlIHRoZSBvbmx5IG9uZXMgdGhhdCBoYXZlIHNvbWUgCmtpbmQgb2Yg
bGltaXRlZCBzdXBwb3J0IGZvciB0aGUgZHJpdmVyIGRvbWFpbnMgdGhpbmcgd2hlbiBjYWxsZWQg
ZnJvbSAKdWRldi4KCj4+Cj4+IENoYW5nZXMgc2luY2UgdjE6Cj4+Cj4+ICogUHJvcGFnYXRlZCBj
aGFuZ2VzIGZyb20gcHJldmlvdXMgcGF0Y2ggKGRpc2FibGVfdWRldiBhbmQgCj4+IGxpYnhsX2Rl
dmljZV9uaWNfYWRkCj4+IHN3aXRjaCkuCj4+Cj4+ICogTW9kaWZpZWQgdWRldiBydWxlcyB0byBh
ZGQgdGhlIG5ldyBlbnYgdmFyaWFibGUuCj4+Cj4+ICogQWRkZWQgc3VwcG9ydCBmb3IgbmFtZWQg
aW50ZXJmYWNlcy4KPj4KPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5w
YXVAY2l0cml4LmNvbT4KPj4gLS0tCj4+IGRvY3MvbWFuL3hsLmNvbmYucG9kLjUgICAgICAgICAg
ICAgICAgfCAgICA3ICsrCj4+IHRvb2xzL2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMg
fCAgICA2ICstCj4+IHRvb2xzL2xpYnhsL2xpYnhsLmMgICAgICAgICAgICAgICAgICAgfCAgIDkw
ICsrKysrKystLS0tLS0tLS0tLS0tCj4+IHRvb2xzL2xpYnhsL2xpYnhsLmggICAgICAgICAgICAg
ICAgICAgfCAgICAzICstCj4+IHRvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jICAgICAgICAgICAg
fCAgIDIyICsrKysrLQo+PiB0b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYyAgICAgICAgICAgIHwg
ICA3NyArKysrKysrKysrKysrKystLQo+PiB0b29scy9saWJ4bC9saWJ4bF9kbS5jICAgICAgICAg
ICAgICAgIHwgICAgMiArLQo+PiB0b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oICAgICAgICAg
IHwgICAgNiArKwo+PiB0b29scy9saWJ4bC9saWJ4bF9saW51eC5jICAgICAgICAgICAgIHwgIDE1
MCAKPj4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCj4+IHRvb2xzL2xpYnhsL2xp
YnhsX3R5cGVzLmlkbCAgICAgICAgICAgfCAgICAxICsKPj4gdG9vbHMvbGlieGwveGwuYyAgICAg
ICAgICAgICAgICAgICAgICB8ICAgIDQgKwo+PiB0b29scy9saWJ4bC94bC5oICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgMSArCj4+IHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyAgICAgICAgICAg
ICAgfCAgIDE1ICsrKy0KPj4gMTMgZmlsZXMgY2hhbmdlZCwgMzA4IGluc2VydGlvbnMoKyksIDc2
IGRlbGV0aW9ucygtKQo+Pgo+PiBkaWZmIC0tZ2l0IGEvZG9jcy9tYW4veGwuY29uZi5wb2QuNSBi
L2RvY3MvbWFuL3hsLmNvbmYucG9kLjUKPj4gaW5kZXggOGJkNDVlYS4uY2YyYzQ3NyAxMDA2NDQK
Pj4gLS0tIGEvZG9jcy9tYW4veGwuY29uZi5wb2QuNQo+PiArKysgYi9kb2NzL21hbi94bC5jb25m
LnBvZC41Cj4+IEBAIC01NSw2ICs1NSwxMyBAQCBkZWZhdWx0Lgo+Pgo+PiBEZWZhdWx0OiBDPDE+
Cj4+Cj4+ICs9aXRlbSBCPGRpc2FibGVfdmlmX3NjcmlwdHM9Qk9PTEVBTj4KPj4gKwo+PiArSWYg
ZW5hYmxlZCB4bCB3aWxsIG5vdCBleGVjdXRlIG5pYyBob3RwbHVnIHNjcmlwdHMgaXRzZWxmLCBh
bmQgCj4+IGluc3RlYWQKPj4gK3JlbGVnYXRlIHRoaXMgdGFzayB0byB1ZGV2Lgo+PiArCj4+ICtE
ZWZhdWx0OiBDPDA+Cj4KPiBQbGVhc2UgY2FuIHlvdSBhbHNvIGFkZCBhIGNvbW1lbnRlZCBvdXQg
dmVyc2lvbgo+IHRvIC4vdG9vbHMvZXhhbXBsZXMveGwuY29uZiwgd2l0aCB0aGUgdmFsdWUgb2Yg
dGhlIGRlZmF1bHQuCj4KPiBUaGlzIGRvZXNuJ3QgYWN0dWFsbHkgZGlzYWJsZSB0aGUgc2NyaXB0
cyBlbnRpcmVseSwgYnV0IHJhdGhlciBvbmx5IAo+IGZyb20KPiB1ZGV2LCBkaXNhYmxlX3VkZXZf
dmlmX3NjcmlwdHMgcGVyaGFwcz8KCkl0IGFjdHVhbGx5IGRpc2FibGVzIHNjcmlwdCBjYWxsaW5n
IGZyb20gbGlieGwsIHNvIEkgdGhpbmsgaXQgbWlnaHQgYmUgCmJlc3QgdG8gY2FsbCBpdCBkaXNh
YmxlX3hsX3ZpZl9zY3JpcHRzPwoKPgo+PiA9aXRlbSBCPGxvY2tmaWxlPSJQQVRIIj4KPj4KPj4g
U2V0cyB0aGUgcGF0aCB0byB0aGUgbG9jayBmaWxlIHVzZWQgYnkgeGwgdG8gc2VyaWFsaXNlIGNl
cnRhaW4KPj4gQEAgLTE5MjksMTQgKzE4ODMsMzAgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRk
KGxpYnhsX2N0eCAqY3R4LCAKPj4gdWludDMyX3QgZG9taWQsIGxpYnhsX2RldmljZV9uaWMgKm5p
YykKPj4gICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX194c19rdnNfb2ZfZmxleGFycmF5
KGdjLCBiYWNrLCAKPj4gYmFjay0+Y291bnQpLAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAg
bGlieGxfX3hzX2t2c19vZl9mbGV4YXJyYXkoZ2MsIGZyb250LCAKPj4gZnJvbnQtPmNvdW50KSk7
Cj4+Cj4+IC0gICAgLyogRklYTUU6IHdhaXQgZm9yIHBsdWcgKi8KPj4gKyAgICBzd2l0Y2gobmlj
LT5uaWN0eXBlKSB7Cj4+ICsgICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9WSUY6Cj4+ICsgICAgICAg
IGlmICghbmljLT5kaXNhYmxlX3ZpZl9zY3JpcHQpIHsKPj4gKyAgICAgICAgICAgIHJjID0gbGli
eGxfX2luaXRpYXRlX2RldmljZV9hZGQoZWdjLCBhbywgJmRldmljZSk7Cj4+ICsgICAgICAgICAg
ICBpZiAocmMpIGdvdG8gb3V0X2ZyZWU7Cj4+ICsgICAgICAgIH0KPgo+IFlvdSBkb24ndCBuZWVk
IGFuIGFvX2NvbXBsZXRlIGluIHRoZSBlbHNlIGNhc2U/CgpTdXJlLCBnb29kIG9uZSwgSSB0aGlu
ayB0aGlzIGtpbmQgb2YgbWVjaGFuaXNtIGlzIHByb25lIHRvIGVycm9yc+KApiAKQU9fSU5QUk9H
UkVTUyBzaG91bGQgY2FsbCBhb19jb21wbGV0ZSBpZiBubyBldmVudHMgaGF2ZSBiZWVuIGFkZGVk
LgoKPj4gKyAgICAgICAgYnJlYWs7Cj4+ICsgICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9JT0VNVToK
Pj4gKyAgICAgICAgLyoKPj4gKyAgICAgICAgICogRG9uJ3QgZXhlY3V0ZSBob3RwbHVnIHNjcmlw
dHMgZm9yIElPRU1VIGludGVyZmFjZXMgeWV0LAo+PiArICAgICAgICAgKiB3ZSBuZWVkIHRvIGxh
dW5jaCB0aGUgZGV2aWNlIG1vZGVsIGZpcnN0Lgo+PiArICAgICAgICAqLwo+Cj4gSXQnZCBiZSB1
c2VmdWwgdG8gYWRkIGEgcmVmZXJlbmNlIHRvIHdoZXJlIHRoZXNlIGFyZSBydW4sIGF0IGZpcnN0
IEkKPiB0aG91Z2h0IHRoaXMgY29tbWVudCAoYW5kIHRoZSBwYXRjaCB0byB4ZW4tYmFja2VuZC5y
dWxlcykgbWVhbnQgdGhleQo+IHdlcmVuJ3QgYmVpbmcgcnVuIGF0IGFsbC4KCkRvbmUgSSd2ZSBh
ZGRlZCBhIHNtYWxsIG5vdGUgc2F5aW5nIHdoZXJlIHRoZXkgYXJlIGNhbGxlZC4KCj4KPj4gZGlm
ZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jIGIvdG9vbHMvbGlieGwvbGlieGxf
Y3JlYXRlLmMKPj4gaW5kZXggZGU1OThhZC4uYTFmNTczMSAxMDA2NDQKPj4gLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfY3JlYXRlLmMKPj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMK
Pj4gQEAgLTYwNyw3ICs2MDcsNyBAQCBzdGF0aWMgaW50IGRvX2RvbWFpbl9jcmVhdGUobGlieGxf
X2djICpnYywgCj4+IGxpYnhsX2RvbWFpbl9jb25maWcgKmRfY29uZmlnLAo+PiAgICAgfQo+PiB9
Cj4+IGZvciAoaSA9IDA7IGkgPCBkX2NvbmZpZy0+bnVtX3ZpZnM7IGkrKykgewo+PiAtICAgICAg
ICByZXQgPSBsaWJ4bF9kZXZpY2VfbmljX2FkZChjdHgsIGRvbWlkLCAmZF9jb25maWctPnZpZnNb
aV0pOwo+PiArICAgICAgICByZXQgPSBsaWJ4bF9kZXZpY2VfbmljX2FkZChjdHgsIGRvbWlkLCAm
ZF9jb25maWctPnZpZnNbaV0sIAo+PiAwKTsKPj4gICAgIGlmIChyZXQpIHsKPj4gICAgICAgICBM
SUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gICAgICAgICAgICAgICAgICAgICJj
YW5ub3QgYWRkIG5pYyAlZCB0byBkb21haW46ICVkIiwgaSwgcmV0KTsKPj4gQEAgLTY4NSw2ICs2
ODUsMjYgQEAgc3RhdGljIGludCBkb19kb21haW5fY3JlYXRlKGxpYnhsX19nYyAqZ2MsIAo+PiBs
aWJ4bF9kb21haW5fY29uZmlnICpkX2NvbmZpZywKPj4gICAgICAgICAgICAgICAgICAgICJkZXZp
Y2UgbW9kZWwgZGlkIG5vdCBzdGFydDogJWQiLCByZXQpOwo+PiAgICAgICAgIGdvdG8gZXJyb3Jf
b3V0Owo+PiAgICAgfQo+PiArICAgICAgICAvKgo+PiArICAgICAgICAgKiBFeGVjdXRlIGhvdHBs
dWcgc2NyaXB0cyBmb3IgdGFwIGRldmljZXMsIHRoaXMgaGFzIHRvIGJlIAo+PiBkb25lCj4+ICsg
ICAgICAgICAqIGFmdGVyIHRoZSBkb21haW4gbW9kZWwgaGFzIGJlZW4gc3RhcnRlZC4KPj4gKyAg
ICAgICAgKi8KPj4gKyAgICAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fdmlmczsg
aSsrKSB7Cj4+ICsgICAgICAgICAgICBpZiAoZF9jb25maWctPnZpZnNbaV0ubmljdHlwZSA9PSBM
SUJYTF9OSUNfVFlQRV9JT0VNVSAmJgo+PiArICAgICAgICAgICAgICAgICFkX2NvbmZpZy0+dmlm
c1tpXS5kaXNhYmxlX3ZpZl9zY3JpcHQpIHsKPj4gKyAgICAgICAgICAgICAgICBsaWJ4bF9fZGV2
aWNlIGRldmljZTsKPj4gKyAgICAgICAgICAgICAgICByZXQgPSBsaWJ4bF9fZGV2aWNlX2Zyb21f
bmljKGdjLCBkb21pZCwgCj4+ICZkX2NvbmZpZy0+dmlmc1tpXSwKPj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkZXZpY2UpOwo+PiArICAgICAgICAgICAg
ICAgIGlmIChyZXQgPCAwKSBnb3RvIGVycm9yX291dDsKPj4gKyAgICAgICAgICAgICAgICByZXQg
PSBsaWJ4bF9fZGV2aWNlX2hvdHBsdWcoZ2MsICZkZXZpY2UsIENPTk5FQ1QpOwo+Cj4gSSBzaG91
bGQgaGF2ZSBhc2tlZCB0aGlzIGluIDMvNSBidXQgZG9lcyB0aGlzIGZ1bmN0aW9uIG5vdCBuZWVk
IHRvIGJlCj4gYXN5bmMsIHNpbmNlIHRoZSBzY3JpcHQgbWlnaHQgdGFrZSBhIHdoaWxlIGFuZCB3
ZSBuZWVkIHRvIHdhaXQgZm9yIGl0IAo+IHRvCj4gY29tcGxldGUgYmVmb3JlIGNvbnRpbnVpbmc/
CgpBcmUgeW91IHN1cmUgd2UgbmVlZCB0byB3YWl0IGZvciBpdCB0byBmaW5pc2g/IFRoZXJlIHdh
c24ndCBhbnkga2luZCBvZiAKc3luY2hyb25pemF0aW9uIGluIHRoZSBwYXN0IHdoZW4gd2UgY2Fs
bGVkIHRoZSBzY3JpcHRzIGZyb20gdWRldiwgc28gSSAKZ3Vlc3Mgd2UgZG9uJ3QgaGF2ZSB0byB3
YWl0IGVpdGhlciBmb3IgdGhlbSB0byBmaW5pc2guCgo+Cj4+ICsgICAgICAgICAgICAgICAgaWYg
KHJldCA8IDApIHsKPj4gKyAgICAgICAgICAgICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhM
X19MT0dfRVJST1IsCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInVuYWJsZSB0
byBsYXVuY2ggaG90cGx1ZyBzY3JpcHQgZm9yIAo+PiBkZXZpY2U6ICIKPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAiJSJQUkl1MzIsIGRldmljZS5kZXZpZCk7Cj4+ICsgICAgICAg
ICAgICAgICAgICAgIGdvdG8gZXJyb3Jfb3V0Owo+PiArICAgICAgICAgICAgICAgIH0KPj4gKyAg
ICAgICAgICAgIH0KPj4gKyAgICAgICAgfQo+PiB9Cj4+Cj4+IGZvciAoaSA9IDA7IGkgPCBkX2Nv
bmZpZy0+bnVtX3BjaWRldnM7IGkrKykKPiBbLi4uXQo+PiBAQCAtNDUwLDIyICs1MDQsMjkgQEAg
aW50IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlKGxpYnhsX19lZ2MgCj4+ICplZ2MsIGxp
YnhsX19hbyAqYW8sCj4+IHsKPj4gQU9fR0M7Cj4+IGxpYnhsX2N0eCAqY3R4ID0gbGlieGxfX2dj
X293bmVyKGdjKTsKPj4gLSAgICB4c190cmFuc2FjdGlvbl90IHQ7Cj4+ICsgICAgeHNfdHJhbnNh
Y3Rpb25fdCB0ID0gMDsKPj4gY2hhciAqYmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfYmFja2VuZF9w
YXRoKGdjLCBkZXYpOwo+PiBjaGFyICpzdGF0ZV9wYXRoID0gbGlieGxfX3NwcmludGYoZ2MsICIl
cy9zdGF0ZSIsIGJlX3BhdGgpOwo+PiAtICAgIGNoYXIgKnN0YXRlID0gbGlieGxfX3hzX3JlYWQo
Z2MsIFhCVF9OVUxMLCBzdGF0ZV9wYXRoKTsKPj4gKyAgICBjaGFyICpzdGF0ZTsKPj4gaW50IHJj
ID0gMDsKPj4gbGlieGxfX2FvX2RldmljZV9yZW1vdmUgKmFvcm0gPSAwOwo+Pgo+PiArICAgIC8q
Cj4+ICsgICAgICogTnVrZSBmcm9udGVuZCB0byBmb3JjZSBiYWNrZW5kIHRlYXJkb3duCj4+ICsg
ICAgICogSXQncyBub3QgcHJldHR5LCBidXQgaXQncyB0aGUgb25seSB3YXkgdGhhdCBzZWVtcyB0
byB3b3JrIGZvciAKPj4gYWxsCj4+ICsgICAgICogdHlwZXMgb2YgYmFja2VuZHMKPj4gKyAgICAg
Ki8KPgo+IEknbSBzdGlsbCBub3QgaGFwcHkgd2l0aCB0aGlzLiBUaGUgX3JlbW92ZSBmdW5jdGlv
bnMgYXJlIHN1cHBvc2VkIHRvIAo+IGJlCj4gYSBncmFjZWZ1bCArIGNvLW9wZXJhdGl2ZSByZW1v
dmUsIHRoYXQgbWVhbnMgcHJvZGRpbmcgdGhlIGZyb250IGFuZAo+IGJhY2tlbmQgaW50byBkb2lu
ZyB0aGUgY29udHJvbGxlZCB0ZWFyZG93biBkYW5jZS4KPgo+IFRoaXMgbWF5IHdlbGwgdGFrZSBz
b21lIHRpbWUgYW5kIG1heSBldmVuIGZhaWwgYWZ0ZXIgc29tZSB0aW1lb3V0Cj4gZGVwZW5kaW5n
IG9uIHRoZSBkZXZpY2UgdHlwZSwgZ3Vlc3QgY29uZmlndXJhdGlvbiBhbmQgY28tb3BlcmF0aW9u
IAo+IGV0YywKPiBidXQgdGhhdCBpcyBleHBlY3RlZCBhbmQgc2hvdWxkIGJlIGhhbmRsZWQuCj4K
PiBGb3JjaW5nIHRoaW5ncyBpbiB0aGlzIHdheSBpcyBhcHByb3ByaWF0ZSBmb3IgZGV2aWNlX2Rl
c3Ryb3kgb25seSBJTUhPCj4gc2luY2UgdGhhdCBpcyB0aGUgZnVuY3Rpb24gd2hpY2ggaXMgcHJv
dmlkZWQgZm9yIHVzZSB3aGVuIHRoZSBndWVzdCBpcwo+IG5vdCBjby1vcGVyYXRpbmcuCgpCZWZv
cmUgdGhpcyBwYXRjaCwgd2UgdXNlZCB0byBqdXN0IG51a2UgYm90aCBmcm9udCBhbmQgYmFjayB4
ZW5zdG9yZSAKZGlyZWN0b3JpZXMgKGJlY2F1c2Ugd2UgYWx3YXlzIGNhbGxlZCBsaWJ4bF9fZGV2
aWNlX2Rlc3Ryb3kpLCBzbyBJIHRoaW5rIAp0aGlzIGlzIHF1aXRlIGFuZCBpbXByb3ZlbWVudCBp
biB0ZXJtIG9mIGNvLW9wZXJhdGlvbiB0aGFuIHdoYXQgd2UgaGFkIApiZWZvcmUuIFdlIG9ubHkg
dXNlZCB0aGlzIGtpbmQgb2YgbmVnb3RpYXRpb24gd2hlbiBkZXRhY2hpbmcgYSBibG9jayAKZnJv
bSBhIGxpdmUgZ3Vlc3QuCgo+Cj4+ICsgICAgbGlieGxfX3hzX3BhdGhfY2xlYW51cChnYywgbGli
eGxfX2RldmljZV9mcm9udGVuZF9wYXRoKGdjLCAKPj4gZGV2KSk7Cj4+ICsKPj4gK3JldHJ5X3Ry
YW5zYWN0aW9uOgo+PiArICAgIHQgPSB4c190cmFuc2FjdGlvbl9zdGFydChjdHgtPnhzaCk7Cj4+
ICsgICAgc3RhdGUgPSBsaWJ4bF9feHNfcmVhZChnYywgdCwgc3RhdGVfcGF0aCk7Cj4+IGlmICgh
c3RhdGUpCj4+ICAgICBnb3RvIG91dF9vazsKPj4gLSAgICBpZiAoYXRvaShzdGF0ZSkgIT0gNCkg
ewo+PiArICAgIGlmIChhdG9pKHN0YXRlKSA9PSBYZW5idXNTdGF0ZUNsb3NlZCkKPj4gICAgIGxp
YnhsX19kZXZpY2VfZGVzdHJveV90YXBkaXNrKGdjLCBiZV9wYXRoKTsKPj4gICAgIGdvdG8gb3V0
X29rOwo+PiAtICAgIH0KPj4KPj4gLXJldHJ5X3RyYW5zYWN0aW9uOgo+PiAtICAgIHQgPSB4c190
cmFuc2FjdGlvbl9zdGFydChjdHgtPnhzaCk7Cj4+IHhzX3dyaXRlKGN0eC0+eHNoLCB0LCBsaWJ4
bF9fc3ByaW50ZihnYywgIiVzL29ubGluZSIsIGJlX3BhdGgpLCAiMCIsIAo+PiBzdHJsZW4oIjAi
KSk7Cj4+IHhzX3dyaXRlKGN0eC0+eHNoLCB0LCBzdGF0ZV9wYXRoLCAiNSIsIHN0cmxlbigiNSIp
KTsKPj4gaWYgKCF4c190cmFuc2FjdGlvbl9lbmQoY3R4LT54c2gsIHQsIDApKSB7Cj4+IEBAIC00
NzYsNiArNTM3LDggQEAgcmV0cnlfdHJhbnNhY3Rpb246Cj4+ICAgICAgICAgZ290byBvdXRfZmFp
bDsKPj4gICAgIH0KPj4gfQo+PiArICAgIC8qIG1hcmsgdHJhbnNhY3Rpb24gYXMgZW5kZWQsIHRv
IHByZXZlbnQgZG91YmxlIGNsb3NpbmcgaXQgb24gCj4+IG91dF9vayAqLwo+PiArICAgIHQgPSAw
Owo+Pgo+PiBsaWJ4bF9fZGV2aWNlX2Rlc3Ryb3lfdGFwZGlzayhnYywgYmVfcGF0aCk7Cj4+Cj4+
IEBAIC00OTcsOCArNTYwLDggQEAgcmV0cnlfdHJhbnNhY3Rpb246Cj4+IHJldHVybiByYzsKPj4K
Pj4gb3V0X29rOgo+PiArICAgIGlmICh0KSB4c190cmFuc2FjdGlvbl9lbmQoY3R4LT54c2gsIHQs
IDApOwo+PiByYyA9IGxpYnhsX19kZXZpY2VfaG90cGx1ZyhnYywgZGV2LCBESVNDT05ORUNUKTsK
Pj4gLSAgICBsaWJ4bF9feHNfcGF0aF9jbGVhbnVwKGdjLCBsaWJ4bF9fZGV2aWNlX2Zyb250ZW5k
X3BhdGgoZ2MsIAo+PiBkZXYpKTsKPj4gbGlieGxfX3hzX3BhdGhfY2xlYW51cChnYywgYmVfcGF0
aCk7Cj4+IHJldHVybiAwOwo+PiB9Cj4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9s
aW51eC5jIGIvdG9vbHMvbGlieGwvbGlieGxfbGludXguYwo+PiBpbmRleCBjNTU4M2FmLi4xZWYy
ODJmIDEwMDY0NAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9saW51eC5jCj4+ICsrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPj4gQEAgLTI3LDExICsyNywzMCBAQCBpbnQgbGlieGxf
X3RyeV9waHlfYmFja2VuZChtb2RlX3Qgc3RfbW9kZSkKPj4gfQo+Pgo+PiAvKiBIb3RwbHVnIHNj
cmlwdHMgaGVscGVycyAqLwo+PiArCj4+ICtzdGF0aWMgbGlieGxfbmljX3R5cGUgZ2V0X25pY190
eXBlKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgCj4+ICpkZXYpCj4+ICt7Cj4+ICsgICAg
bGlieGxfY3R4ICpjdHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+PiArICAgIGNoYXIgKnNuaWN0
eXBlLCAqYmVfcGF0aDsKPj4gKwo+PiArICAgIGJlX3BhdGggPSBsaWJ4bF9fZGV2aWNlX2JhY2tl
bmRfcGF0aChnYywgZGV2KTsKPj4gKwo+PiArICAgIHNuaWN0eXBlID0gbGlieGxfX3hzX3JlYWQo
Z2MsIFhCVF9OVUxMLAo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX19zcHJp
bnRmKGdjLCAiJXMvJXMiLCBiZV9wYXRoLCAKPj4gInR5cGUiKSk7Cj4KPiBUaGlzIHJlYWxseSBv
dWdodCB0byBiZSB1bmRlciBzb21lIHByaXZhdGUgbGlieGwgcGF0aCByZWxhdGluZyB0byB0aGUK
PiBkZXZpY2UgcmF0aGVyIHRoYW4gdW5kZXIgdGhlIGJhY2tlbmQvZnJvbnRlbmQgdmlzaWJsZSBk
aXJzLgoKV2VsbCwgdGhpcyBpcyBjdXJyZW50bHkgb25seSB1c2VkIGJ5IGxpYnhsLCBidXQgdGhl
IHR5cGUgb2YgdGhlIGJhY2tlbmQgCnVzZWQgSSB0aGluayBzaG91bGQgYmUgaW5zaWRlIHRoZSBi
YWNrZW5kIGRldmljZSBkaXJlY3RvcnksIHNpbmNlIG90aGVyIAphcHBsaWNhdGlvbnMgbWlnaHQg
YWxzbyB3YW50IHRvIGtub3cgdGhpcy4KCj4gQWN0dWFsbHksIG5vdyBJIHRoaW5rIG9mIGl0LCB0
aGF0IGlzIGFsc28gdHJ1ZSBvZiB0aGUgdWRldl9kaXNhYmxlIAo+IGtleT8KClRoaXMgaXMgcHJv
YmFibHkgdHJ1ZSBmb3IgdWRldl9kaXNhYmxlLCBzb21ldGhpbmcgbGlrZSAKL2xpYnhsL2Rldmlj
ZXMvPGRvbWlkPi88ZGV2aWQ+L3VkZXZfZGlzYWJsZT8gSSB3aWxsIGhhdmUgdG8gbW9kaWZ5IAps
aWJ4bF9fZGV2aWNlX2dlbmVyaWNfYWRkIHRvIGRvIHRoaXMsIGJlY2F1c2UgaXQgc2hvdWxkIGJl
IGRvbmUgb24gdGhlIApzYW1lIHRyYW5zYWN0aW9uIHdoZW4gdGhlIGRldmljZSBpcyBhZGRlZC4g
SSdtIG5vdCBzdXJlIGlmIHdlIG5lZWQgdG8gCmFkZCBzbyBtdWNoIG92ZXJoZWFkIGZvciBqdXN0
IG9uZSB4ZW5zdG9yZSBlbnRyeSwgdGhhdCB3aWxsIGdvIGF3YXkgaW4gCnRoZSBuZXh0IHJlbGVh
c2UgcHJvYmFibHkuCgo+IFlvdSBjb3VsZCBhbHNvIHVzZSB0aGUgaGFuZHkgZW51bSB0by9mcm9t
X3N0cmluZ3MgZnVuY3Rpb25zIHRvIGxlYXZlIAo+IG9uZQo+IGxlc3MgbWFnaWMgbnVtYmVyIGlu
IHhlbnN0b3JlLgoKWWVzLgoKPgo+PiArICAgIGlmICghc25pY3R5cGUpIHsKPj4gKyAgICAgICAg
TElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gcmVhZCBuaWN0eXBl
IAo+PiBmcm9tICVzIiwKPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGJlX3BhdGgpOwo+PiArICAgICAgICByZXR1cm4gLTE7Cj4+ICsgICAgfQo+PiArCj4+ICsg
ICAgcmV0dXJuIGF0b2koc25pY3R5cGUpOwo+PiArfQo+PiArCj4+IEBAIC02Miw2ICs4MSwzNSBA
QCBzdGF0aWMgY2hhciAqKmdldF9ob3RwbHVnX2VudihsaWJ4bF9fZ2MgKmdjLCAKPj4gbGlieGxf
X2RldmljZSAqZGV2KQo+PiAgICAgICAgICAgICAgIGRldi0+ZG9taWQsIGRldi0+ZGV2aWQpKTsK
Pj4gZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgIlhFTkJVU19CQVNFX1BBVEgiKTsKPj4gZmxl
eGFycmF5X3NldChmX2VudiwgbnIrKywgImJhY2tlbmQiKTsKPj4gKyAgICBpZiAoZGV2LT5iYWNr
ZW5kX2tpbmQgPT0gTElCWExfX0RFVklDRV9LSU5EX1ZJRikgewo+PiArICAgICAgICBpZm5hbWUg
PSBsaWJ4bF9feHNfcmVhZChnYywgWEJUX05VTEwsIGxpYnhsX19zcHJpbnRmKGdjLCAKPj4gIiVz
LyVzIiwKPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCj4+IGJlX3BhdGgsCj4+ICsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo+PiAidmlmbmFtZSIp
KTsKPj4gKyAgICAgICAgc3dpdGNoIChnZXRfbmljX3R5cGUoZ2MsIGRldikpIHsKPj4gKyAgICAg
ICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9JT0VNVToKPj4gKyAgICAgICAgICAgIGZsZXhhcnJheV9z
ZXQoZl9lbnYsIG5yKyssICJJTlRFUkZBQ0UiKTsKPj4gKyAgICAgICAgICAgIGlmIChpZm5hbWUp
IHsKPj4gKyAgICAgICAgICAgICAgICBmbGV4YXJyYXlfc2V0KGZfZW52LCBucisrLCBsaWJ4bF9f
c3ByaW50ZihnYywgCj4+ICJ4ZW50YXAtJXMiLAo+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPj4gaWZuYW1lKSk7Cj4+ICsg
ICAgICAgICAgICB9IGVsc2Ugewo+PiArICAgICAgICAgICAgICAgIGZsZXhhcnJheV9zZXQoZl9l
bnYsIG5yKyssCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fc3ByaW50
ZihnYywgInhlbnRhcCV1LiVkIiwKPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRl
di0+ZG9taWQsIGRldi0+ZGV2aWQpKTsKPgo+IFRoaXMgaXMgY3V0LW4tcGFzdGUgb2Ygc29tZSBv
dGhlciBjb2RlLCBwZXJoYXBzIGNyZWF0ZSBhIGZ1bmN0aW9uIHRvIAo+IGdldAo+IHRoZSB0YXAg
bmFtZSBmcm9tIHRoZSB2aWYgbmFtZSBhbmQgb3IgZG9tL2RldmlkPwoKCkFyZSB5b3UgZ29pbmcg
dG8gYWRkIGl0IHRvIHlvdXIgcGF0Y2ggb3IgSSBzaG91bGQgYWRkIGl0IHRvIG1pbmU/IApTb21l
dGhpbmcgbGlrZToKCmNoYXIgKmxpYnhsX19kZXZpY2VfdGFwX25hbWUobGlieGxfX2djICpnYywg
bGlieGxfX2RldmljZSAqZGV2KQoKPj4gKyAgICAgICAgICAgIH0KPj4gKyAgICAgICAgY2FzZSBM
SUJYTF9OSUNfVFlQRV9WSUY6Cj4+ICsgICAgICAgICAgICBmbGV4YXJyYXlfc2V0KGZfZW52LCBu
cisrLCAidmlmIik7Cj4+ICsgICAgICAgICAgICBpZiAoaWZuYW1lKSB7Cj4+ICsgICAgICAgICAg
ICAgICAgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgaWZuYW1lKTsKPj4gKyAgICAgICAgICAg
IH0gZWxzZSB7Cj4+ICsgICAgICAgICAgICAgICAgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywK
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX19zcHJpbnRmKGdjLCAidmlm
JXUuJWQiLAo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGV2LT5kb21pZCwgZGV2
LT5kZXZpZCkpOwo+PiArICAgICAgICAgICAgfQo+Cj4gTGlrZXdpc2UKCmNoYXIgKmxpYnhsX19k
ZXZpY2VfdmlmX25hbWUobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAqZGV2KQoKQm90aCB0
aGlzIGZ1bmN0aW9ucyBzaG91bGQgcmV0dXJuIHRoZSBjb3JyZWN0IHZpZm5hbWUgaWYgb25lIGlz
IHNldCwgb3IgCnRoZSBkZWZhdWx0IG9uZSBvdGhlcndpc2UuCgo+PiArICAgICAgICAgICAgYnJl
YWs7Cj4+ICsgICAgICAgIGRlZmF1bHQ6Cj4+ICsgICAgICAgICAgICByZXR1cm4gTlVMTDsKPj4g
KyAgICAgICAgfQo+PiArICAgIH0KPj4KPj4gZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgTlVM
TCk7Cj4+Cj4+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMKPj4gaW5kZXggMDFmZjM2My4uNDEyMzBhNiAxMDA2NDQKPj4gLS0t
IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCj4+ICsrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYwo+PiBAQCAtODQ2LDYgKzg0NiwxOSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0
YShjb25zdCBjaGFyIAo+PiAqY29uZmlnZmlsZV9maWxlbmFtZV9yZXBvcnQsCj4+ICAgICAgICAg
ICAgIG5pYy0+c2NyaXB0ID0gc3RyZHVwKGRlZmF1bHRfdmlmc2NyaXB0KTsKPj4gICAgICAgICB9
Cj4+Cj4+ICsgICAgICAgICAgICAvKiBTZXQgZGVmYXVsdCBuaWMgdHlwZSBmb3IgUFYgZ3Vlc3Rz
IGNvcnJlY3RseSAqLwo+PiArICAgICAgICAgICAgaWYgKGJfaW5mby0+dHlwZSA9PSBMSUJYTF9E
T01BSU5fVFlQRV9QVikgewo+PiArICAgICAgICAgICAgICAgIG5pYy0+bmljdHlwZSA9IExJQlhM
X05JQ19UWVBFX1ZJRjsKPj4gKyAgICAgICAgICAgIH0KPgo+IEhybSwgcmVhbGx5IHRoZSBsaWIg
b3VnaHQgdG8gYmUgdGFraW5nIGNhcmUgb2YgdGhhdCBmb3IgdXMuLi4KPgo+IGxpYnhsX19kZXZp
Y2VfbmljX3NldGRlZmF1bHQgaGFzIGEgZG9taWQgc28gaXQgc2hvdWxkIGJlIGFibGUgdG8gcXVl
cnkKPiB0aGUgZG9tYWluIHR5cGUgd2l0aCBsaWJ4bF9fZG9tYWluX3R5cGUuCgpZZXMuCgo+PiAr
ICAgICAgICAgICAgLyoKPj4gKyAgICAgICAgICAgICAqIERpc2FibGUgbmljIG5ldHdvcmsgc2Ny
aXB0IGNhbGxpbmcsIHRvIGFsbG93IHRoZSB1c2VyCj4+ICsgICAgICAgICAgICAgKiB0byBhdHRh
Y2ggdGhlIG5pYyBiYWNrZW5kIGZyb20gYSBkaWZmZXJlbnQgZG9tYWluLgo+PiArICAgICAgICAg
ICAgICovCj4+ICsgICAgICAgICAgICBpZiAoZGlzYWJsZV92aWZfc2NyaXB0cykgewo+PiArICAg
ICAgICAgICAgICAgIG5pYy0+ZGlzYWJsZV92aWZfc2NyaXB0ID0gMTsKPj4gKyAgICAgICAgICAg
IH0KPgo+IFRoaXMgaXMgZXF1aXZhbGVudCB0byA6Cj4gICAgICAgICAgICBuaWMtPmRpc2FibGVf
dmlmX3NjcmlwdCA9IGRpc2FibGVfdmlmX3NjcmlwdHMKClllcywgYW5kIGl0J3Mgb25lIGxpbmUg
bGVzcy4KCj4KPj4gKwo+PiAgICAgICAgaWYgKGRlZmF1bHRfYnJpZGdlKSB7Cj4+ICAgICAgICAg
ICAgZnJlZShuaWMtPmJyaWRnZSk7Cj4+ICAgICAgICAgICAgbmljLT5icmlkZ2UgPSBzdHJkdXAo
ZGVmYXVsdF9icmlkZ2UpOwo+PiBAQCAtNDkwMSw3ICs0OTE0LDcgQEAgaW50IG1haW5fbmV0d29y
a2F0dGFjaChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCj4+ICAgICAgICAgcmV0dXJuIDE7Cj4+ICAg
ICB9Cj4+IH0KPj4gLSAgICBpZiAobGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5p
YykpIHsKPj4gKyAgICBpZiAobGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYywg
MCkpIHsKPj4gICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfZGV2aWNlX25pY19hZGQgZmFpbGVk
LlxuIik7Cj4+ICAgICByZXR1cm4gMTsKPj4gfQo+PiAtLQo+PiAxLjcuNy41IChBcHBsZSBHaXQt
MjYpCj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
Pj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:53:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKTRe-0003pN-1f; Wed, 18 Apr 2012 11:53:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKTRc-0003pG-NN
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 11:53:08 +0000
Received: from [85.158.143.35:52424] by server-3.bemta-4.messagelabs.com id
	AE/92-05853-32BAE8F4; Wed, 18 Apr 2012 11:53:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334749983!10516945!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 550 invoked from network); 18 Apr 2012 11:53:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 11:53:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKTRU-0001re-N9; Wed, 18 Apr 2012 11:53:00 +0000
Date: Wed, 18 Apr 2012 12:53:00 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120418115300.GA7013@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
	<20345.48953.952902.407000@mariner.uk.xensource.com>
	<20120412080224.GB30588@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120412080224.GB30588@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:02 +0100 on 12 Apr (1334221344), Tim Deegan wrote:
> At 16:01 +0100 on 02 Apr (1333382473), Ian Jackson wrote:
> > Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> > > tools: Fix FPU save area definition in xen-hvmctx
> > > 
> > > Reported-by: Olaf Hering <olaf@aepfle.de>
> > > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > Urgh.  This seems plausible.  (The repetition of the constant "16" is
> > unfortunate but we don't have ARRAY_SIZE Here...)
> > 
> > I intend to apply Tim's patch unless anyone objects.
> 
> Ping?

Looks like nobody objects. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:53:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKTRe-0003pN-1f; Wed, 18 Apr 2012 11:53:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKTRc-0003pG-NN
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 11:53:08 +0000
Received: from [85.158.143.35:52424] by server-3.bemta-4.messagelabs.com id
	AE/92-05853-32BAE8F4; Wed, 18 Apr 2012 11:53:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334749983!10516945!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 550 invoked from network); 18 Apr 2012 11:53:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 11:53:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKTRU-0001re-N9; Wed, 18 Apr 2012 11:53:00 +0000
Date: Wed, 18 Apr 2012 12:53:00 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120418115300.GA7013@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
	<20345.48953.952902.407000@mariner.uk.xensource.com>
	<20120412080224.GB30588@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120412080224.GB30588@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:02 +0100 on 12 Apr (1334221344), Tim Deegan wrote:
> At 16:01 +0100 on 02 Apr (1333382473), Ian Jackson wrote:
> > Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> > > tools: Fix FPU save area definition in xen-hvmctx
> > > 
> > > Reported-by: Olaf Hering <olaf@aepfle.de>
> > > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > Urgh.  This seems plausible.  (The repetition of the constant "16" is
> > unfortunate but we don't have ARRAY_SIZE Here...)
> > 
> > I intend to apply Tim's patch unless anyone objects.
> 
> Ping?

Looks like nobody objects. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:58:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKTWY-00041j-Ut; Wed, 18 Apr 2012 11:58:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKTWW-00041b-Qe
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:58:13 +0000
Received: from [85.158.139.83:12958] by server-6.bemta-5.messagelabs.com id
	D1/DE-13222-35CAE8F4; Wed, 18 Apr 2012 11:58:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334750289!23686961!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzc0OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24837 invoked from network); 18 Apr 2012 11:58:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:58:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330923600"; d="scan'208";a="24269252"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 07:58:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 07:58:08 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKTWR-0007qO-S7;
	Wed, 18 Apr 2012 12:58:07 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 12:58:07 +0100
Message-ID: <518661FA-27B6-4C87-95B4-64F6EA19F896@citrix.com>
In-Reply-To: <1334742899.23948.180.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 Apr 2012, at 10:54, Ian Campbell wrote:

> On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
>> As the previous change already introduces most of needed machinery to 
>> call
>> hotplug scripts from libxl, this only adds the necessary bits to call 
>> this
>> scripts for vif interfaces also.
>>
>> libxl_device_nic_add has been changed to make use of the new event
>> functionality, and the necessary vif hotplug code has been added. No 
>> changes
>> where needed in the teardown part, since it uses exactly the same 
>> code
>> introduced for vbd.
>>
>> An exception has been introduced for tap devices, since hotplug 
>> scripts
>> should be called after the device model has been created, so the 
>> hotplug
>> call for those is done in do_domain_create after confirmation of the 
>> device
>> model startup. On the other hand, tap devices don't use teardown 
>> scripts,
>> so add another exception for that.
>>
>> libxl__device_from_nic was moved to libxl_device.c, so it can be used
>> in libxl_create.c, and libxl__device_from_disk was also moved to 
>> mantain
>> the simmetry.
>
> "maintain" and "symmetry"
>
> These are pure code motion or did the code actually change too?
>
>> libxl__initiate_device_remove has been changed a little, to nuke the 
>> frontend
>> xenstore path before trying to perform device teardown, this allows 
>> for
>> unitialized devices to be closed gracefully, specially vif interfaces 
>> added to
>
> uninitialized (or -ised)
>
>> HVM machines and not used.
>>
>> PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value 
>> is
>> LIBXL_NIC_TYPE_IOEMU regardless of the guest type.
>>
>> A new gobal option, called disable_vif_scripts has been added to 
>> allow the user
>
>     global
>
>> decide if he wants to execute the hotplug scripts from xl or from 
>> udev. This has
>> been documented in the xl.conf man page.
>
> Did you do this for block too?
>
>>
>> Changes since v1:
>>
>> * Propagated changes from previous patch (disable_udev and 
>> libxl_device_nic_add
>> switch).
>>
>> * Modified udev rules to add the new env variable.
>>
>> * Added support for named interfaces.
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> docs/man/xl.conf.pod.5                |    7 ++
>> tools/hotplug/Linux/xen-backend.rules |    6 +-
>> tools/libxl/libxl.c                   |   90 +++++++-------------
>> tools/libxl/libxl.h                   |    3 +-
>> tools/libxl/libxl_create.c            |   22 +++++-
>> tools/libxl/libxl_device.c            |   77 +++++++++++++++--
>> tools/libxl/libxl_dm.c                |    2 +-
>> tools/libxl/libxl_internal.h          |    6 ++
>> tools/libxl/libxl_linux.c             |  150 
>> ++++++++++++++++++++++++++++++++-
>> tools/libxl/libxl_types.idl           |    1 +
>> tools/libxl/xl.c                      |    4 +
>> tools/libxl/xl.h                      |    1 +
>> tools/libxl/xl_cmdimpl.c              |   15 +++-
>> 13 files changed, 308 insertions(+), 76 deletions(-)
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 01ff363..41230a6 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -846,6 +846,19 @@ static void parse_config_data(const char 
>> *configfile_filename_report,
>>              nic->script = strdup(default_vifscript);
>>          }
>>
>> +            /* Set default nic type for PV guests correctly */
>> +            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
>> +                nic->nictype = LIBXL_NIC_TYPE_VIF;
>> +            }
>
> Hrm, really the lib ought to be taking care of that for us...
>
> libxl__device_nic_setdefault has a domid so it should be able to query
> the domain type with libxl__domain_type.

int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) 
is the prototype, and libxl_device_nic doesn't have a domid, so I'm not 
sure where should I get it from.

>> +            /*
>> +             * Disable nic network script calling, to allow the user
>> +             * to attach the nic backend from a different domain.
>> +             */
>> +            if (disable_vif_scripts) {
>> +                nic->disable_vif_script = 1;
>> +            }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 11:58:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 11:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKTWY-00041j-Ut; Wed, 18 Apr 2012 11:58:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKTWW-00041b-Qe
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 11:58:13 +0000
Received: from [85.158.139.83:12958] by server-6.bemta-5.messagelabs.com id
	D1/DE-13222-35CAE8F4; Wed, 18 Apr 2012 11:58:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334750289!23686961!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzc0OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24837 invoked from network); 18 Apr 2012 11:58:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 11:58:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330923600"; d="scan'208";a="24269252"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 07:58:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 07:58:08 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKTWR-0007qO-S7;
	Wed, 18 Apr 2012 12:58:07 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 12:58:07 +0100
Message-ID: <518661FA-27B6-4C87-95B4-64F6EA19F896@citrix.com>
In-Reply-To: <1334742899.23948.180.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 Apr 2012, at 10:54, Ian Campbell wrote:

> On Tue, 2012-04-17 at 16:51 +0100, Roger Pau Monne wrote:
>> As the previous change already introduces most of needed machinery to 
>> call
>> hotplug scripts from libxl, this only adds the necessary bits to call 
>> this
>> scripts for vif interfaces also.
>>
>> libxl_device_nic_add has been changed to make use of the new event
>> functionality, and the necessary vif hotplug code has been added. No 
>> changes
>> where needed in the teardown part, since it uses exactly the same 
>> code
>> introduced for vbd.
>>
>> An exception has been introduced for tap devices, since hotplug 
>> scripts
>> should be called after the device model has been created, so the 
>> hotplug
>> call for those is done in do_domain_create after confirmation of the 
>> device
>> model startup. On the other hand, tap devices don't use teardown 
>> scripts,
>> so add another exception for that.
>>
>> libxl__device_from_nic was moved to libxl_device.c, so it can be used
>> in libxl_create.c, and libxl__device_from_disk was also moved to 
>> mantain
>> the simmetry.
>
> "maintain" and "symmetry"
>
> These are pure code motion or did the code actually change too?
>
>> libxl__initiate_device_remove has been changed a little, to nuke the 
>> frontend
>> xenstore path before trying to perform device teardown, this allows 
>> for
>> unitialized devices to be closed gracefully, specially vif interfaces 
>> added to
>
> uninitialized (or -ised)
>
>> HVM machines and not used.
>>
>> PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value 
>> is
>> LIBXL_NIC_TYPE_IOEMU regardless of the guest type.
>>
>> A new gobal option, called disable_vif_scripts has been added to 
>> allow the user
>
>     global
>
>> decide if he wants to execute the hotplug scripts from xl or from 
>> udev. This has
>> been documented in the xl.conf man page.
>
> Did you do this for block too?
>
>>
>> Changes since v1:
>>
>> * Propagated changes from previous patch (disable_udev and 
>> libxl_device_nic_add
>> switch).
>>
>> * Modified udev rules to add the new env variable.
>>
>> * Added support for named interfaces.
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> docs/man/xl.conf.pod.5                |    7 ++
>> tools/hotplug/Linux/xen-backend.rules |    6 +-
>> tools/libxl/libxl.c                   |   90 +++++++-------------
>> tools/libxl/libxl.h                   |    3 +-
>> tools/libxl/libxl_create.c            |   22 +++++-
>> tools/libxl/libxl_device.c            |   77 +++++++++++++++--
>> tools/libxl/libxl_dm.c                |    2 +-
>> tools/libxl/libxl_internal.h          |    6 ++
>> tools/libxl/libxl_linux.c             |  150 
>> ++++++++++++++++++++++++++++++++-
>> tools/libxl/libxl_types.idl           |    1 +
>> tools/libxl/xl.c                      |    4 +
>> tools/libxl/xl.h                      |    1 +
>> tools/libxl/xl_cmdimpl.c              |   15 +++-
>> 13 files changed, 308 insertions(+), 76 deletions(-)
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 01ff363..41230a6 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -846,6 +846,19 @@ static void parse_config_data(const char 
>> *configfile_filename_report,
>>              nic->script = strdup(default_vifscript);
>>          }
>>
>> +            /* Set default nic type for PV guests correctly */
>> +            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
>> +                nic->nictype = LIBXL_NIC_TYPE_VIF;
>> +            }
>
> Hrm, really the lib ought to be taking care of that for us...
>
> libxl__device_nic_setdefault has a domid so it should be able to query
> the domain type with libxl__domain_type.

int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) 
is the prototype, and libxl_device_nic doesn't have a domid, so I'm not 
sure where should I get it from.

>> +            /*
>> +             * Disable nic network script calling, to allow the user
>> +             * to attach the nic backend from a different domain.
>> +             */
>> +            if (disable_vif_scripts) {
>> +                nic->disable_vif_script = 1;
>> +            }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:03:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKTar-0004HS-4U; Wed, 18 Apr 2012 12:02:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKTap-0004HL-P0
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:02:39 +0000
Received: from [193.109.254.147:52887] by server-7.bemta-14.messagelabs.com id
	0F/27-01627-F5DAE8F4; Wed, 18 Apr 2012 12:02:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334750557!5134687!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25636 invoked from network); 18 Apr 2012 12:02:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:02:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKTam-0001tY-H1; Wed, 18 Apr 2012 12:02:36 +0000
Date: Wed, 18 Apr 2012 13:02:36 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120418120236.GB7013@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

Can you please set up your mail client to indent quoted text?  It's not
clear which parts of your email are quoted and which are your replies.

At 13:53 +0100 on 11 Apr (1334152395), Francisco Rocha wrote:
> You can handle the second by using
> stub domains to run qemu in a different domain, or by only usoing PV
> domUs.
> 
> If I use the stub domain provided with xen the dom0 will not perform the 
> second mapping, right?

Yes; instead, the stub domain will perform it - so you'll need to allow
that to happen.  (Basically the stub domain's code lives inside the
guest's protection boundary, like its BIOS code &c).

> The third is pretty much a requirement if the domU's going to do
> any I/O via dom0, but at least with grant tables the ACL is under domU's
> control.  Or if you have an IOMMU you can give the domU direct access to
> its own network card and disk controller.
> 
> I only have one ethernet card but i can get an ethernet expresscard.
> 
> Can I do this in my the machine that gives me the output that follows?
> 
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation enabled.
> (XEN) Intel VT-d Interrupt Remapping enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.

Yes; you should be able to do it on this machine without changing any
BIOS settings.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:03:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKTar-0004HS-4U; Wed, 18 Apr 2012 12:02:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKTap-0004HL-P0
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:02:39 +0000
Received: from [193.109.254.147:52887] by server-7.bemta-14.messagelabs.com id
	0F/27-01627-F5DAE8F4; Wed, 18 Apr 2012 12:02:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334750557!5134687!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25636 invoked from network); 18 Apr 2012 12:02:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:02:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKTam-0001tY-H1; Wed, 18 Apr 2012 12:02:36 +0000
Date: Wed, 18 Apr 2012 13:02:36 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120418120236.GB7013@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

Can you please set up your mail client to indent quoted text?  It's not
clear which parts of your email are quoted and which are your replies.

At 13:53 +0100 on 11 Apr (1334152395), Francisco Rocha wrote:
> You can handle the second by using
> stub domains to run qemu in a different domain, or by only usoing PV
> domUs.
> 
> If I use the stub domain provided with xen the dom0 will not perform the 
> second mapping, right?

Yes; instead, the stub domain will perform it - so you'll need to allow
that to happen.  (Basically the stub domain's code lives inside the
guest's protection boundary, like its BIOS code &c).

> The third is pretty much a requirement if the domU's going to do
> any I/O via dom0, but at least with grant tables the ACL is under domU's
> control.  Or if you have an IOMMU you can give the domU direct access to
> its own network card and disk controller.
> 
> I only have one ethernet card but i can get an ethernet expresscard.
> 
> Can I do this in my the machine that gives me the output that follows?
> 
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation enabled.
> (XEN) Intel VT-d Interrupt Remapping enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.

Yes; you should be able to do it on this machine without changing any
BIOS settings.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:32:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU32-0004fT-Rf; Wed, 18 Apr 2012 12:31:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKU31-0004fN-TL
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:31:48 +0000
Received: from [85.158.138.51:48621] by server-9.bemta-3.messagelabs.com id
	9D/63-26691-234BE8F4; Wed, 18 Apr 2012 12:31:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334752305!18327364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31016 invoked from network); 18 Apr 2012 12:31:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:31:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 13:31:18 +0100
Message-ID: <1334752277.23948.233.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 13:31:17 +0100
In-Reply-To: <B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> >> decide if he wants to execute the hotplug scripts from xl or from
> >> udev. This has
> >> been documented in the xl.conf man page.
> >
> > Did you do this for block too?
> 
> Nope, only for vif interfaces, that are the only ones that have some
> kind of limited support for the driver domains thing when called from
> udev.

OK, makes sense.

> >> @@ -55,6 +55,13 @@ default.
> >>
> >> Default: C<1>
> >>
> >> +=item B<disable_vif_scripts=BOOLEAN>
> >> +
> >> +If enabled xl will not execute nic hotplug scripts itself, and
> >> instead
> >> +relegate this task to udev.
> >> +
> >> +Default: C<0>
> >
> > Please can you also add a commented out version
> > to ./tools/examples/xl.conf, with the value of the default.
> >
> > This doesn't actually disable the scripts entirely, but rather only
> > from > udev, disable_udev_vif_scripts perhaps?
> 
> It actually disables script calling from libxl, so I think it might be
> best to call it disable_xl_vif_scripts?

Oh, I was confusing it with the xenstore key used by the scripts! I
think your existing name is fine then.

> >
> >> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> >> index de598ad..a1f5731 100644
> >> --- a/tools/libxl/libxl_create.c
> >> +++ b/tools/libxl/libxl_create.c
> >> @@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc,
> >> libxl_domain_config *d_config,
> >>     }
> >> }
> >> for (i = 0; i < d_config->num_vifs; i++) {
> >> -        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
> >> +        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i],
> >> 0);
> >>     if (ret) {
> >>         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >>                    "cannot add nic %d to domain: %d", i, ret);
> >> @@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc,
> >> libxl_domain_config *d_config,
> >>                    "device model did not start: %d", ret);
> >>         goto error_out;
> >>     }
> >> +        /*
> >> +         * Execute hotplug scripts for tap devices, this has to be
> >> done
> >> +         * after the domain model has been started.
> >> +        */
> >> +        for (i = 0; i < d_config->num_vifs; i++) {
> >> +            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
> >> +                !d_config->vifs[i].disable_vif_script) {
> >> +                libxl__device device;
> >> +                ret = libxl__device_from_nic(gc, domid,
> >> &d_config->vifs[i],
> >> +                                             &device);
> >> +                if (ret < 0) goto error_out;
> >> +                ret = libxl__device_hotplug(gc, &device, CONNECT);
> >
> > I should have asked this in 3/5 but does this function not need to be
> > async, since the script might take a while and we need to wait for it
> > to
> > complete before continuing?
> 
> Are you sure we need to wait for it to finish?

Not at all..

> There wasn't any kind of
> synchronization in the past when we called the scripts from udev, so I
> guess we don't have to wait either for them to finish.

You are right, I don't think xl currently waits.

xend used to (IIRC) wait for the hotplug-status node to be written and
used this to do some basic error handling, waiting doe that node is
roughly equivalent to waiting for the script to finish.

Given that xl today doesn't wait I guess I'd be happy to defer that to
the future.

> >> @@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc
> >> *egc, libxl__ao *ao,
> >> {
> >> AO_GC;
> >> libxl_ctx *ctx = libxl__gc_owner(gc);
> >> -    xs_transaction_t t;
> >> +    xs_transaction_t t = 0;
> >> char *be_path = libxl__device_backend_path(gc, dev);
> >> char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> >> -    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
> >> +    char *state;
> >> int rc = 0;
> >> libxl__ao_device_remove *aorm = 0;
> >>
> >> +    /*
> >> +     * Nuke frontend to force backend teardown
> >> +     * It's not pretty, but it's the only way that seems to work for
> >> all
> >> +     * types of backends
> >> +     */
> >
> > I'm still not happy with this. The _remove functions are supposed to
> > be
> > a graceful + co-operative remove, that means prodding the front and
> > backend into doing the controlled teardown dance.
> >
> > This may well take some time and may even fail after some timeout
> > depending on the device type, guest configuration and co-operation
> > etc,
> > but that is expected and should be handled.
> >
> > Forcing things in this way is appropriate for device_destroy only IMHO
> > since that is the function which is provided for use when the guest is
> > not co-operating.
> 
> Before this patch, we used to just nuke both front and back xenstore
> directories (because we always called libxl__device_destroy),

Not always, the call to destroy depended on the current state.

In the case where the guest is alive and responsive we have to do the
hot remove in the graceful way. If the guest is alive but not responsive
then the correct approach is to try the graceful method with a timeout
which triggers the big hammer approach.

>  so I think
> this is quite and improvement in term of co-operation than what we had
> before. We only used this kind of negotiation when detaching a block
> from a live guest.
> 
> >
> >> +    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
> >> dev));
> >> +
> >> +retry_transaction:
> >> +    t = xs_transaction_start(ctx->xsh);
> >> +    state = libxl__xs_read(gc, t, state_path);
> >> if (!state)
> >>     goto out_ok;
> >> -    if (atoi(state) != 4) {
> >> +    if (atoi(state) == XenbusStateClosed)
> >>     libxl__device_destroy_tapdisk(gc, be_path);
> >>     goto out_ok;
> >> -    }
> >>
> >> -retry_transaction:
> >> -    t = xs_transaction_start(ctx->xsh);
> >> xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0",
> >> strlen("0"));
> >> xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
> >> if (!xs_transaction_end(ctx->xsh, t, 0)) {
> >> @@ -476,6 +537,8 @@ retry_transaction:
> >>         goto out_fail;
> >>     }
> >> }
> >> +    /* mark transaction as ended, to prevent double closing it on
> >> out_ok */
> >> +    t = 0;
> >>
> >> libxl__device_destroy_tapdisk(gc, be_path);
> >>
> >> @@ -497,8 +560,8 @@ retry_transaction:
> >> return rc;
> >>
> >> out_ok:
> >> +    if (t) xs_transaction_end(ctx->xsh, t, 0);
> >> rc = libxl__device_hotplug(gc, dev, DISCONNECT);
> >> -    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
> >> dev));
> >> libxl__xs_path_cleanup(gc, be_path);
> >> return 0;
> >> }
> >> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> >> index c5583af..1ef282f 100644
> >> --- a/tools/libxl/libxl_linux.c
> >> +++ b/tools/libxl/libxl_linux.c
> >> @@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
> >> }
> >>
> >> /* Hotplug scripts helpers */
> >> +
> >> +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device
> >> *dev)
> >> +{
> >> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> >> +    char *snictype, *be_path;
> >> +
> >> +    be_path = libxl__device_backend_path(gc, dev);
> >> +
> >> +    snictype = libxl__xs_read(gc, XBT_NULL,
> >> +                            libxl__sprintf(gc, "%s/%s", be_path,
> >> "type"));
> >
> > This really ought to be under some private libxl path relating to the
> > device rather than under the backend/frontend visible dirs.
> 
> Well, this is currently only used by libxl, but the type of the backend
> used I think should be inside the backend device directory, since other
> applications might also want to know this.

Hang on, can't you infer the type from the backend path, one should
contains vif and the other something else (tap)? Or is this because of
the stupid sharing of the vif dir for both vif and tap from the hotplug
scripts point of view?

It's probably too late in the 4.2 cycle to direct the tap hotplug script
to a different backend dir so I think the best thing to do for now is to
put this key somewhere else so that it doesn't become a guest visible
API (which is what happens with where you have put it). The same place
as udev_disable would work fine.

> > Actually, now I think of it, that is also true of the udev_disable
> > key?
> 
> This is probably true for udev_disable, something like
> /libxl/devices/<domid>/<devid>/udev_disable? I will have to modify
> libxl__device_generic_add to do this, because it should be done on the
> same transaction when the device is added. I'm not sure if we need to
> add so much overhead for just one xenstore entry, that will go away in
> the next release probably.

I think this will be around for more than one release (these
deprecations always take time) so it is worth doing right.

> >
> >> +    if (!snictype) {
> >> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype
> >> from %s",
> >> +                                          be_path);
> >> +        return -1;
> >> +    }
> >> +
> >> +    return atoi(snictype);
> >> +}
> >> +
> >> @@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc,
> >> libxl__device *dev)
> >>               dev->domid, dev->devid));
> >> flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
> >> flexarray_set(f_env, nr++, "backend");
> >> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
> >> +        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
> >> "%s/%s",
> >> +
> >> be_path,
> >> +
> >> "vifname"));
> >> +        switch (get_nic_type(gc, dev)) {
> >> +        case LIBXL_NIC_TYPE_IOEMU:
> >> +            flexarray_set(f_env, nr++, "INTERFACE");
> >> +            if (ifname) {
> >> +                flexarray_set(f_env, nr++, libxl__sprintf(gc,
> >> "xentap-%s",
> >> +
> >> ifname));
> >> +            } else {
> >> +                flexarray_set(f_env, nr++,
> >> +                              libxl__sprintf(gc, "xentap%u.%d",
> >> +                              dev->domid, dev->devid));
> >
> > This is cut-n-paste of some other code, perhaps create a function to
> > get
> > the tap name from the vif name and or dom/devid?
> 
> 
> Are you going to add it to your patch or I should add it to mine?

I'll let you do it if that's alright.
> Something like:
> 
> char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev)
[...]
> char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev)
> 
> Both this functions should return the correct vifname if one is set, or
> the default one otherwise.

Yep.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:32:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU32-0004fT-Rf; Wed, 18 Apr 2012 12:31:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKU31-0004fN-TL
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:31:48 +0000
Received: from [85.158.138.51:48621] by server-9.bemta-3.messagelabs.com id
	9D/63-26691-234BE8F4; Wed, 18 Apr 2012 12:31:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334752305!18327364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31016 invoked from network); 18 Apr 2012 12:31:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:31:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 13:31:18 +0100
Message-ID: <1334752277.23948.233.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 13:31:17 +0100
In-Reply-To: <B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> >> decide if he wants to execute the hotplug scripts from xl or from
> >> udev. This has
> >> been documented in the xl.conf man page.
> >
> > Did you do this for block too?
> 
> Nope, only for vif interfaces, that are the only ones that have some
> kind of limited support for the driver domains thing when called from
> udev.

OK, makes sense.

> >> @@ -55,6 +55,13 @@ default.
> >>
> >> Default: C<1>
> >>
> >> +=item B<disable_vif_scripts=BOOLEAN>
> >> +
> >> +If enabled xl will not execute nic hotplug scripts itself, and
> >> instead
> >> +relegate this task to udev.
> >> +
> >> +Default: C<0>
> >
> > Please can you also add a commented out version
> > to ./tools/examples/xl.conf, with the value of the default.
> >
> > This doesn't actually disable the scripts entirely, but rather only
> > from > udev, disable_udev_vif_scripts perhaps?
> 
> It actually disables script calling from libxl, so I think it might be
> best to call it disable_xl_vif_scripts?

Oh, I was confusing it with the xenstore key used by the scripts! I
think your existing name is fine then.

> >
> >> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> >> index de598ad..a1f5731 100644
> >> --- a/tools/libxl/libxl_create.c
> >> +++ b/tools/libxl/libxl_create.c
> >> @@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc,
> >> libxl_domain_config *d_config,
> >>     }
> >> }
> >> for (i = 0; i < d_config->num_vifs; i++) {
> >> -        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
> >> +        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i],
> >> 0);
> >>     if (ret) {
> >>         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >>                    "cannot add nic %d to domain: %d", i, ret);
> >> @@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc,
> >> libxl_domain_config *d_config,
> >>                    "device model did not start: %d", ret);
> >>         goto error_out;
> >>     }
> >> +        /*
> >> +         * Execute hotplug scripts for tap devices, this has to be
> >> done
> >> +         * after the domain model has been started.
> >> +        */
> >> +        for (i = 0; i < d_config->num_vifs; i++) {
> >> +            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
> >> +                !d_config->vifs[i].disable_vif_script) {
> >> +                libxl__device device;
> >> +                ret = libxl__device_from_nic(gc, domid,
> >> &d_config->vifs[i],
> >> +                                             &device);
> >> +                if (ret < 0) goto error_out;
> >> +                ret = libxl__device_hotplug(gc, &device, CONNECT);
> >
> > I should have asked this in 3/5 but does this function not need to be
> > async, since the script might take a while and we need to wait for it
> > to
> > complete before continuing?
> 
> Are you sure we need to wait for it to finish?

Not at all..

> There wasn't any kind of
> synchronization in the past when we called the scripts from udev, so I
> guess we don't have to wait either for them to finish.

You are right, I don't think xl currently waits.

xend used to (IIRC) wait for the hotplug-status node to be written and
used this to do some basic error handling, waiting doe that node is
roughly equivalent to waiting for the script to finish.

Given that xl today doesn't wait I guess I'd be happy to defer that to
the future.

> >> @@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc
> >> *egc, libxl__ao *ao,
> >> {
> >> AO_GC;
> >> libxl_ctx *ctx = libxl__gc_owner(gc);
> >> -    xs_transaction_t t;
> >> +    xs_transaction_t t = 0;
> >> char *be_path = libxl__device_backend_path(gc, dev);
> >> char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> >> -    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
> >> +    char *state;
> >> int rc = 0;
> >> libxl__ao_device_remove *aorm = 0;
> >>
> >> +    /*
> >> +     * Nuke frontend to force backend teardown
> >> +     * It's not pretty, but it's the only way that seems to work for
> >> all
> >> +     * types of backends
> >> +     */
> >
> > I'm still not happy with this. The _remove functions are supposed to
> > be
> > a graceful + co-operative remove, that means prodding the front and
> > backend into doing the controlled teardown dance.
> >
> > This may well take some time and may even fail after some timeout
> > depending on the device type, guest configuration and co-operation
> > etc,
> > but that is expected and should be handled.
> >
> > Forcing things in this way is appropriate for device_destroy only IMHO
> > since that is the function which is provided for use when the guest is
> > not co-operating.
> 
> Before this patch, we used to just nuke both front and back xenstore
> directories (because we always called libxl__device_destroy),

Not always, the call to destroy depended on the current state.

In the case where the guest is alive and responsive we have to do the
hot remove in the graceful way. If the guest is alive but not responsive
then the correct approach is to try the graceful method with a timeout
which triggers the big hammer approach.

>  so I think
> this is quite and improvement in term of co-operation than what we had
> before. We only used this kind of negotiation when detaching a block
> from a live guest.
> 
> >
> >> +    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
> >> dev));
> >> +
> >> +retry_transaction:
> >> +    t = xs_transaction_start(ctx->xsh);
> >> +    state = libxl__xs_read(gc, t, state_path);
> >> if (!state)
> >>     goto out_ok;
> >> -    if (atoi(state) != 4) {
> >> +    if (atoi(state) == XenbusStateClosed)
> >>     libxl__device_destroy_tapdisk(gc, be_path);
> >>     goto out_ok;
> >> -    }
> >>
> >> -retry_transaction:
> >> -    t = xs_transaction_start(ctx->xsh);
> >> xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0",
> >> strlen("0"));
> >> xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
> >> if (!xs_transaction_end(ctx->xsh, t, 0)) {
> >> @@ -476,6 +537,8 @@ retry_transaction:
> >>         goto out_fail;
> >>     }
> >> }
> >> +    /* mark transaction as ended, to prevent double closing it on
> >> out_ok */
> >> +    t = 0;
> >>
> >> libxl__device_destroy_tapdisk(gc, be_path);
> >>
> >> @@ -497,8 +560,8 @@ retry_transaction:
> >> return rc;
> >>
> >> out_ok:
> >> +    if (t) xs_transaction_end(ctx->xsh, t, 0);
> >> rc = libxl__device_hotplug(gc, dev, DISCONNECT);
> >> -    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
> >> dev));
> >> libxl__xs_path_cleanup(gc, be_path);
> >> return 0;
> >> }
> >> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> >> index c5583af..1ef282f 100644
> >> --- a/tools/libxl/libxl_linux.c
> >> +++ b/tools/libxl/libxl_linux.c
> >> @@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
> >> }
> >>
> >> /* Hotplug scripts helpers */
> >> +
> >> +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device
> >> *dev)
> >> +{
> >> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> >> +    char *snictype, *be_path;
> >> +
> >> +    be_path = libxl__device_backend_path(gc, dev);
> >> +
> >> +    snictype = libxl__xs_read(gc, XBT_NULL,
> >> +                            libxl__sprintf(gc, "%s/%s", be_path,
> >> "type"));
> >
> > This really ought to be under some private libxl path relating to the
> > device rather than under the backend/frontend visible dirs.
> 
> Well, this is currently only used by libxl, but the type of the backend
> used I think should be inside the backend device directory, since other
> applications might also want to know this.

Hang on, can't you infer the type from the backend path, one should
contains vif and the other something else (tap)? Or is this because of
the stupid sharing of the vif dir for both vif and tap from the hotplug
scripts point of view?

It's probably too late in the 4.2 cycle to direct the tap hotplug script
to a different backend dir so I think the best thing to do for now is to
put this key somewhere else so that it doesn't become a guest visible
API (which is what happens with where you have put it). The same place
as udev_disable would work fine.

> > Actually, now I think of it, that is also true of the udev_disable
> > key?
> 
> This is probably true for udev_disable, something like
> /libxl/devices/<domid>/<devid>/udev_disable? I will have to modify
> libxl__device_generic_add to do this, because it should be done on the
> same transaction when the device is added. I'm not sure if we need to
> add so much overhead for just one xenstore entry, that will go away in
> the next release probably.

I think this will be around for more than one release (these
deprecations always take time) so it is worth doing right.

> >
> >> +    if (!snictype) {
> >> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype
> >> from %s",
> >> +                                          be_path);
> >> +        return -1;
> >> +    }
> >> +
> >> +    return atoi(snictype);
> >> +}
> >> +
> >> @@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc,
> >> libxl__device *dev)
> >>               dev->domid, dev->devid));
> >> flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
> >> flexarray_set(f_env, nr++, "backend");
> >> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
> >> +        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
> >> "%s/%s",
> >> +
> >> be_path,
> >> +
> >> "vifname"));
> >> +        switch (get_nic_type(gc, dev)) {
> >> +        case LIBXL_NIC_TYPE_IOEMU:
> >> +            flexarray_set(f_env, nr++, "INTERFACE");
> >> +            if (ifname) {
> >> +                flexarray_set(f_env, nr++, libxl__sprintf(gc,
> >> "xentap-%s",
> >> +
> >> ifname));
> >> +            } else {
> >> +                flexarray_set(f_env, nr++,
> >> +                              libxl__sprintf(gc, "xentap%u.%d",
> >> +                              dev->domid, dev->devid));
> >
> > This is cut-n-paste of some other code, perhaps create a function to
> > get
> > the tap name from the vif name and or dom/devid?
> 
> 
> Are you going to add it to your patch or I should add it to mine?

I'll let you do it if that's alright.
> Something like:
> 
> char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev)
[...]
> char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev)
> 
> Both this functions should return the correct vifname if one is set, or
> the default one otherwise.

Yep.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:32:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU38-0004fm-8U; Wed, 18 Apr 2012 12:31:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKU36-0004fa-FK
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 12:31:53 +0000
Received: from [85.158.139.83:30191] by server-9.bemta-5.messagelabs.com id
	2F/D6-09826-534BE8F4; Wed, 18 Apr 2012 12:31:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334752308!24290430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14610 invoked from network); 18 Apr 2012 12:31:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:31:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:31:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 13:31:13 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKU2S-0006dA-SC;
	Wed, 18 Apr 2012 12:31:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKU2S-000197-Lm;
	Wed, 18 Apr 2012 13:31:12 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12713-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 13:31:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12713: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12713 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12713/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12669
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail like 12669

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  8 guest-saverestore            fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  8 guest-saverestore       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  8 guest-saverestore       fail never pass
 test-i386-i386-xl-qemuu-win   8 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  8 guest-saverestore  fail never pass

version targeted for testing:
 qemuu                fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
baseline version:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
+ branch=qemu-upstream-unstable
+ revision=fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7:master
Counting objects: 2   
Counting objects: 19   
Counting objects: 26, done.
Compressing objects:   5% (1/19)   
Compressing objects:  10% (2/19)   
Compressing objects:  15% (3/19)   
Compressing objects:  21% (4/19)   
Compressing objects:  26% (5/19)   
Compressing objects:  31% (6/19)   
Compressing objects:  36% (7/19)   
Compressing objects:  42% (8/19)   
Compressing objects:  47% (9/19)   
Compressing objects:  52% (10/19)   
Compressing objects:  57% (11/19)   
Compressing objects:  63% (12/19)   
Compressing objects:  68% (13/19)   
Compressing objects:  73% (14/19)   
Compressing objects:  78% (15/19)   
Compressing objects:  84% (16/19)   
Compressing objects:  89% (17/19)   
Compressing objects:  94% (18/19)   
Compressing objects: 100% (19/19)   
Compressing objects: 100% (19/19), done.
Writing objects:   5% (1/19)   
Writing objects:  10% (2/19)   
Writing objects:  15% (3/19)   
Writing objects:  21% (4/19)   
Writing objects:  26% (5/19)   
Writing objects:  31% (6/19)   
Writing objects:  36% (7/19)   
Writing objects:  42% (8/19)   
Writing objects:  47% (9/19)   
Writing objects:  52% (10/19)   
Writing objects:  57% (11/19)   
Writing objects:  63% (12/19)   
Writing objects:  68% (13/19)   
Writing objects:  73% (14/19)   
Writing objects:  78% (15/19)   
Writing objects:  84% (16/19)   
Writing objects:  89% (17/19)   
Writing objects:  94% (18/19)   
Writing objects: 100% (19/19)   
Writing objects: 100% (19/19), 3.38 KiB, done.
Total 19 (delta 14), reused 0 (delta 0)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   4db7763..fcd11a4  fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:32:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU38-0004fm-8U; Wed, 18 Apr 2012 12:31:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKU36-0004fa-FK
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 12:31:53 +0000
Received: from [85.158.139.83:30191] by server-9.bemta-5.messagelabs.com id
	2F/D6-09826-534BE8F4; Wed, 18 Apr 2012 12:31:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334752308!24290430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14610 invoked from network); 18 Apr 2012 12:31:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:31:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:31:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 13:31:13 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKU2S-0006dA-SC;
	Wed, 18 Apr 2012 12:31:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKU2S-000197-Lm;
	Wed, 18 Apr 2012 13:31:12 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12713-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 13:31:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 12713: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12713 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12713/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12669
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail like 12669

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  8 guest-saverestore            fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  8 guest-saverestore       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  8 guest-saverestore       fail never pass
 test-i386-i386-xl-qemuu-win   8 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  8 guest-saverestore  fail never pass

version targeted for testing:
 qemuu                fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
baseline version:
 qemuu                4db776322827f0930d53b9e162dc1c6600d918d0

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
+ branch=qemu-upstream-unstable
+ revision=fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7:master
Counting objects: 2   
Counting objects: 19   
Counting objects: 26, done.
Compressing objects:   5% (1/19)   
Compressing objects:  10% (2/19)   
Compressing objects:  15% (3/19)   
Compressing objects:  21% (4/19)   
Compressing objects:  26% (5/19)   
Compressing objects:  31% (6/19)   
Compressing objects:  36% (7/19)   
Compressing objects:  42% (8/19)   
Compressing objects:  47% (9/19)   
Compressing objects:  52% (10/19)   
Compressing objects:  57% (11/19)   
Compressing objects:  63% (12/19)   
Compressing objects:  68% (13/19)   
Compressing objects:  73% (14/19)   
Compressing objects:  78% (15/19)   
Compressing objects:  84% (16/19)   
Compressing objects:  89% (17/19)   
Compressing objects:  94% (18/19)   
Compressing objects: 100% (19/19)   
Compressing objects: 100% (19/19), done.
Writing objects:   5% (1/19)   
Writing objects:  10% (2/19)   
Writing objects:  15% (3/19)   
Writing objects:  21% (4/19)   
Writing objects:  26% (5/19)   
Writing objects:  31% (6/19)   
Writing objects:  36% (7/19)   
Writing objects:  42% (8/19)   
Writing objects:  47% (9/19)   
Writing objects:  52% (10/19)   
Writing objects:  57% (11/19)   
Writing objects:  63% (12/19)   
Writing objects:  68% (13/19)   
Writing objects:  73% (14/19)   
Writing objects:  78% (15/19)   
Writing objects:  84% (16/19)   
Writing objects:  89% (17/19)   
Writing objects:  94% (18/19)   
Writing objects: 100% (19/19)   
Writing objects: 100% (19/19), 3.38 KiB, done.
Total 19 (delta 14), reused 0 (delta 0)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   4db7763..fcd11a4  fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:34:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU5k-0004wk-98; Wed, 18 Apr 2012 12:34:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKU5i-0004wW-3g
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:34:34 +0000
Received: from [85.158.139.83:54504] by server-9.bemta-5.messagelabs.com id
	BA/EE-09826-9D4BE8F4; Wed, 18 Apr 2012 12:34:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334752471!17024255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21542 invoked from network); 18 Apr 2012 12:34:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:34:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 13:34:31 +0100
Message-ID: <1334752469.23948.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 13:34:29 +0100
In-Reply-To: <518661FA-27B6-4C87-95B4-64F6EA19F896@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<518661FA-27B6-4C87-95B4-64F6EA19F896@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> >> index 01ff363..41230a6 100644
> >> --- a/tools/libxl/xl_cmdimpl.c
> >> +++ b/tools/libxl/xl_cmdimpl.c
> >> @@ -846,6 +846,19 @@ static void parse_config_data(const char 
> >> *configfile_filename_report,
> >>              nic->script = strdup(default_vifscript);
> >>          }
> >>
> >> +            /* Set default nic type for PV guests correctly */
> >> +            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
> >> +                nic->nictype = LIBXL_NIC_TYPE_VIF;
> >> +            }
> >
> > Hrm, really the lib ought to be taking care of that for us...
> >
> > libxl__device_nic_setdefault has a domid so it should be able to query
> > the domain type with libxl__domain_type.
> 
> int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) 
> is the prototype, and libxl_device_nic doesn't have a domid, so I'm not 
> sure where should I get it from.

Urk, oh dear.

I think it would be ok to add parameters which are necessary for
setdefault to make its decision.

Other wise perhaps make the default be LIBXL_NIC_TYPE_VIF
unconditionally? That is the option which has a chance of working
regardless of guest type, TYPE_IOEMU is a bit of an odd choice for the
default.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:34:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU5k-0004wk-98; Wed, 18 Apr 2012 12:34:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKU5i-0004wW-3g
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:34:34 +0000
Received: from [85.158.139.83:54504] by server-9.bemta-5.messagelabs.com id
	BA/EE-09826-9D4BE8F4; Wed, 18 Apr 2012 12:34:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334752471!17024255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21542 invoked from network); 18 Apr 2012 12:34:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:34:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 13:34:31 +0100
Message-ID: <1334752469.23948.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 13:34:29 +0100
In-Reply-To: <518661FA-27B6-4C87-95B4-64F6EA19F896@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<518661FA-27B6-4C87-95B4-64F6EA19F896@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> >> index 01ff363..41230a6 100644
> >> --- a/tools/libxl/xl_cmdimpl.c
> >> +++ b/tools/libxl/xl_cmdimpl.c
> >> @@ -846,6 +846,19 @@ static void parse_config_data(const char 
> >> *configfile_filename_report,
> >>              nic->script = strdup(default_vifscript);
> >>          }
> >>
> >> +            /* Set default nic type for PV guests correctly */
> >> +            if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
> >> +                nic->nictype = LIBXL_NIC_TYPE_VIF;
> >> +            }
> >
> > Hrm, really the lib ought to be taking care of that for us...
> >
> > libxl__device_nic_setdefault has a domid so it should be able to query
> > the domain type with libxl__domain_type.
> 
> int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) 
> is the prototype, and libxl_device_nic doesn't have a domid, so I'm not 
> sure where should I get it from.

Urk, oh dear.

I think it would be ok to add parameters which are necessary for
setdefault to make its decision.

Other wise perhaps make the default be LIBXL_NIC_TYPE_VIF
unconditionally? That is the option which has a chance of working
regardless of guest type, TYPE_IOEMU is a bit of an odd choice for the
default.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:36:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU7A-000557-Ue; Wed, 18 Apr 2012 12:36:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKU79-00054p-LP
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 12:36:03 +0000
Received: from [85.158.143.35:15551] by server-2.bemta-4.messagelabs.com id
	79/DE-17550-235BE8F4; Wed, 18 Apr 2012 12:36:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334752562!11552628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7651 invoked from network); 18 Apr 2012 12:36:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:36:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:36:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 13:36:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKU77-0006et-N5;
	Wed, 18 Apr 2012 12:36:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKU77-00081U-MN;
	Wed, 18 Apr 2012 13:36:01 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12712-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 13:36:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12712: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12712 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12712/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12709
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 12709

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12709

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  e6b20ec1824c
baseline version:
 xen                  6017afc70442

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:36:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKU7A-000557-Ue; Wed, 18 Apr 2012 12:36:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKU79-00054p-LP
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 12:36:03 +0000
Received: from [85.158.143.35:15551] by server-2.bemta-4.messagelabs.com id
	79/DE-17550-235BE8F4; Wed, 18 Apr 2012 12:36:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334752562!11552628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7651 invoked from network); 18 Apr 2012 12:36:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 12:36:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="12001286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:36:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 13:36:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKU77-0006et-N5;
	Wed, 18 Apr 2012 12:36:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKU77-00081U-MN;
	Wed, 18 Apr 2012 13:36:01 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12712-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 13:36:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12712: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12712 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12712/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12709
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 12709

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12709

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  e6b20ec1824c
baseline version:
 xen                  6017afc70442

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUBS-0005VG-LA; Wed, 18 Apr 2012 12:40:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUBQ-0005V8-Qv
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:40:28 +0000
Received: from [85.158.138.51:65254] by server-10.bemta-3.messagelabs.com id
	D8/D1-29478-B36BE8F4; Wed, 18 Apr 2012 12:40:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334752826!18615375!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23852 invoked from network); 18 Apr 2012 12:40:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:40:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUB9-000204-Dl; Wed, 18 Apr 2012 12:40:11 +0000
Date: Wed, 18 Apr 2012 13:40:11 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418124011.GC7013@ocelot.phlegethon.org>
References: <c74fe64aafebebb025b5.1334239602@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c74fe64aafebebb025b5.1334239602@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, adin@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_event: Fix foregin domain flag in
	grab_slot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:06 -0400 on 12 Apr (1334225202), Andres Lagar-Cavilla wrote:
> diff -r 84c3a14dc28a -r c74fe64aafeb xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -415,7 +415,7 @@ int __mem_event_claim_slot(struct domain
>      if ( (current->domain == d) && allow_sleep )
>          return mem_event_wait_slot(med);
>      else
> -        return mem_event_grab_slot(med, 1);
> +        return mem_event_grab_slot(med, (current->domain != d));
>  }
>  
>  /* Registered with Xen-bound event channel for incoming notifications. */

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUBS-0005VG-LA; Wed, 18 Apr 2012 12:40:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUBQ-0005V8-Qv
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:40:28 +0000
Received: from [85.158.138.51:65254] by server-10.bemta-3.messagelabs.com id
	D8/D1-29478-B36BE8F4; Wed, 18 Apr 2012 12:40:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334752826!18615375!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23852 invoked from network); 18 Apr 2012 12:40:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:40:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUB9-000204-Dl; Wed, 18 Apr 2012 12:40:11 +0000
Date: Wed, 18 Apr 2012 13:40:11 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418124011.GC7013@ocelot.phlegethon.org>
References: <c74fe64aafebebb025b5.1334239602@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c74fe64aafebebb025b5.1334239602@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, adin@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_event: Fix foregin domain flag in
	grab_slot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:06 -0400 on 12 Apr (1334225202), Andres Lagar-Cavilla wrote:
> diff -r 84c3a14dc28a -r c74fe64aafeb xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -415,7 +415,7 @@ int __mem_event_claim_slot(struct domain
>      if ( (current->domain == d) && allow_sleep )
>          return mem_event_wait_slot(med);
>      else
> -        return mem_event_grab_slot(med, 1);
> +        return mem_event_grab_slot(med, (current->domain != d));
>  }
>  
>  /* Registered with Xen-bound event channel for incoming notifications. */

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:40:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUBb-0005Vo-1s; Wed, 18 Apr 2012 12:40:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUBZ-0005Vb-Si
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:40:37 +0000
Received: from [85.158.143.99:50778] by server-2.bemta-4.messagelabs.com id
	AF/B6-17550-546BE8F4; Wed, 18 Apr 2012 12:40:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334752836!18913027!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22424 invoked from network); 18 Apr 2012 12:40:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:40:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUBX-00020Q-Oj; Wed, 18 Apr 2012 12:40:35 +0000
Date: Wed, 18 Apr 2012 13:40:35 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418124035.GD7013@ocelot.phlegethon.org>
References: <15a3c740419f53702b0c.1334351886@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <15a3c740419f53702b0c.1334351886@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Fix locking on hap enable failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:18 -0400 on 13 Apr (1334337486), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/hap/hap.c |  3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> 
> If enabling hap fails due to out of memory, the locking on the clean up path is
> broken.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:40:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUBb-0005Vo-1s; Wed, 18 Apr 2012 12:40:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUBZ-0005Vb-Si
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:40:37 +0000
Received: from [85.158.143.99:50778] by server-2.bemta-4.messagelabs.com id
	AF/B6-17550-546BE8F4; Wed, 18 Apr 2012 12:40:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334752836!18913027!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22424 invoked from network); 18 Apr 2012 12:40:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:40:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUBX-00020Q-Oj; Wed, 18 Apr 2012 12:40:35 +0000
Date: Wed, 18 Apr 2012 13:40:35 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418124035.GD7013@ocelot.phlegethon.org>
References: <15a3c740419f53702b0c.1334351886@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <15a3c740419f53702b0c.1334351886@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Fix locking on hap enable failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:18 -0400 on 13 Apr (1334337486), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/hap/hap.c |  3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> 
> If enabling hap fails due to out of memory, the locking on the clean up path is
> broken.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUBt-0005YW-FK; Wed, 18 Apr 2012 12:40:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUBr-0005Y0-Rr
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 12:40:55 +0000
Received: from [85.158.139.83:4789] by server-12.bemta-5.messagelabs.com id
	CA/F9-05587-656BE8F4; Wed, 18 Apr 2012 12:40:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334752852!21662632!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3820 invoked from network); 18 Apr 2012 12:40:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:40:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUBn-00020i-HB; Wed, 18 Apr 2012 12:40:51 +0000
Date: Wed, 18 Apr 2012 13:40:51 +0100
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120418124051.GE7013@ocelot.phlegethon.org>
References: <CAB10MZA-64tOohf5_1-8LJ52E3dUC0xOYSUPRgUgeqC3mOBhKQ@mail.gmail.com>
	<CBB43AA3.3E628%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CBB43AA3.3E628%keir@xen.org>
User-Agent: Mutt/1.4.2.1i
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_access: fix setting default mem_access
	type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:32 +0100 on 18 Apr (1334741539), Keir Fraser wrote:
> On 18/04/2012 02:09, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
> 
> > When xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0)
> > is called, first_pfn=~0ull is a hint to HVMOP_set_mem_access as to
> > what the default mem_access type is for the domain. This call was
> > failing because it was gated by the memory range check in the
> > HVMOP_set_mem_access case statement in do_hvm_op(). The following
> > patch fixes this issue.
> > 
> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> Looks okay to me. Probably should be checked and applied by Tim.

Done.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUBt-0005YW-FK; Wed, 18 Apr 2012 12:40:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUBr-0005Y0-Rr
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 12:40:55 +0000
Received: from [85.158.139.83:4789] by server-12.bemta-5.messagelabs.com id
	CA/F9-05587-656BE8F4; Wed, 18 Apr 2012 12:40:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334752852!21662632!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3820 invoked from network); 18 Apr 2012 12:40:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:40:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUBn-00020i-HB; Wed, 18 Apr 2012 12:40:51 +0000
Date: Wed, 18 Apr 2012 13:40:51 +0100
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120418124051.GE7013@ocelot.phlegethon.org>
References: <CAB10MZA-64tOohf5_1-8LJ52E3dUC0xOYSUPRgUgeqC3mOBhKQ@mail.gmail.com>
	<CBB43AA3.3E628%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CBB43AA3.3E628%keir@xen.org>
User-Agent: Mutt/1.4.2.1i
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_access: fix setting default mem_access
	type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:32 +0100 on 18 Apr (1334741539), Keir Fraser wrote:
> On 18/04/2012 02:09, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
> 
> > When xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0)
> > is called, first_pfn=~0ull is a hint to HVMOP_set_mem_access as to
> > what the default mem_access type is for the domain. This call was
> > failing because it was gated by the memory range check in the
> > HVMOP_set_mem_access case statement in do_hvm_op(). The following
> > patch fixes this issue.
> > 
> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> Looks okay to me. Probably should be checked and applied by Tim.

Done.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUCz-0005i6-Ue; Wed, 18 Apr 2012 12:42:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUCy-0005hg-0F
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:42:04 +0000
Received: from [85.158.143.99:12676] by server-2.bemta-4.messagelabs.com id
	B8/29-17550-B96BE8F4; Wed, 18 Apr 2012 12:42:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334752922!24202669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19661 invoked from network); 18 Apr 2012 12:42:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:42:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUCw-000217-0A; Wed, 18 Apr 2012 12:42:02 +0000
Date: Wed, 18 Apr 2012 13:42:01 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418124201.GF7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm/sharing: Clean ups for
	relinquishing shared pages on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:16 -0400 on 12 Apr (1334225772), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/domain.c             |  16 ++++++++++++-
>  xen/arch/x86/mm/mem_sharing.c     |  45 +++++++++++++++++++++++++++++++++++++++
>  xen/arch/x86/mm/p2m.c             |   4 +++
>  xen/include/asm-arm/mm.h          |   4 +++
>  xen/include/asm-x86/domain.h      |   1 +
>  xen/include/asm-x86/mem_sharing.h |  10 ++++++++
>  xen/include/asm-x86/p2m.h         |   4 +++
>  7 files changed, 82 insertions(+), 2 deletions(-)
> 
> 
> When a domain is destroyed, its pages are freed in relinquish_resources in a
> preemptible mode, in the context of a synchronous domctl.
> 
> P2m entries pointing to shared pages are, however, released during p2m cleanup
> in an RCU callback, and in non-preemptible mode.
> 
> This is an O(n) operation for a very large n, which may include actually
> freeing shared pages for which the domain is the last holder.
> 
> To improve responsiveness, move this operation to the preemtible portion of
> domain destruction, during the synchronous domain_kill hypercall. And remove
> the bulk of the work from the RCU callback.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I've applied this as a bug-fix.  The other two seem more like new
development and I'm less happy about taking them before 4.2

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 12:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 12:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUCz-0005i6-Ue; Wed, 18 Apr 2012 12:42:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKUCy-0005hg-0F
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 12:42:04 +0000
Received: from [85.158.143.99:12676] by server-2.bemta-4.messagelabs.com id
	B8/29-17550-B96BE8F4; Wed, 18 Apr 2012 12:42:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1334752922!24202669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19661 invoked from network); 18 Apr 2012 12:42:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 12:42:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKUCw-000217-0A; Wed, 18 Apr 2012 12:42:02 +0000
Date: Wed, 18 Apr 2012 13:42:01 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418124201.GF7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm/sharing: Clean ups for
	relinquishing shared pages on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:16 -0400 on 12 Apr (1334225772), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/domain.c             |  16 ++++++++++++-
>  xen/arch/x86/mm/mem_sharing.c     |  45 +++++++++++++++++++++++++++++++++++++++
>  xen/arch/x86/mm/p2m.c             |   4 +++
>  xen/include/asm-arm/mm.h          |   4 +++
>  xen/include/asm-x86/domain.h      |   1 +
>  xen/include/asm-x86/mem_sharing.h |  10 ++++++++
>  xen/include/asm-x86/p2m.h         |   4 +++
>  7 files changed, 82 insertions(+), 2 deletions(-)
> 
> 
> When a domain is destroyed, its pages are freed in relinquish_resources in a
> preemptible mode, in the context of a synchronous domctl.
> 
> P2m entries pointing to shared pages are, however, released during p2m cleanup
> in an RCU callback, and in non-preemptible mode.
> 
> This is an O(n) operation for a very large n, which may include actually
> freeing shared pages for which the domain is the last holder.
> 
> To improve responsiveness, move this operation to the preemtible portion of
> domain destruction, during the synchronous domain_kill hypercall. And remove
> the bulk of the work from the RCU callback.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I've applied this as a bug-fix.  The other two seem more like new
development and I'm less happy about taking them before 4.2

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:01:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUVh-00068r-Ok; Wed, 18 Apr 2012 13:01:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKUVf-00068m-LE
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:01:23 +0000
Received: from [193.109.254.147:16559] by server-5.bemta-14.messagelabs.com id
	BD/4B-30733-22BBE8F4; Wed, 18 Apr 2012 13:01:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334754071!5166984!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22568 invoked from network); 18 Apr 2012 13:01:12 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.81) by server-12.tower-27.messagelabs.com with SMTP;
	18 Apr 2012 13:01:12 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 60B92300064;
	Wed, 18 Apr 2012 06:01:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=HWhKLeDprlC99MPFEVKgZv
	BuFXI/j+QcKYev0fd2HYfa7ZPVKhLnan4gvGsCtp4xkxEQH+z8fAd7yOsaGzJIFw
	P2M45+DoP/FcF24KBDccyFE9dTSmGZrOzhibtIrFAFRZBiEniIgBtcXFxQaFHMHT
	Lou1lJhHSF60Y+jV6z1BA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=WbfHHfkmaKmz
	DxvtiNuWP5WR0TA=; b=XIbRiUG1uxE8RGVGiKeohmNUFwoXbc3Ik+WReUwSt6uZ
	gdUYRcnhh2M94x5gzpySF9kLNZi7wwA9hweKA06jI4L2sZilWJv4Xe+nv9OABHPf
	uo40ORmDUeo62prxgU6JEKtTVvzCcrP8G2Qus3v6BKmYb+ZQINzuT12/r+o7X+w=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id D659F300072; 
	Wed, 18 Apr 2012 06:01:09 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 495d3df95c1d59f55d5ac94ee2eab00da60651e4
Message-Id: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 18 Apr 2012 09:06:40 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
     if ( spage->sharing->handle != sh )
         goto err_unlock;
 
-    /* Make sure the target page is a hole in the physmap */
+    /* Make sure the target page is a hole in the physmap. This is not as
+     * simple a test as we'd like it to be. Non-existent p2m entries return
+     * invalid mfn and p2m_mmio_dm type when queried. */
     if ( mfn_valid(cmfn) ||
-         (!(p2m_is_ram(cmfn_type))) )
+         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )
     {
         ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:01:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUVh-00068r-Ok; Wed, 18 Apr 2012 13:01:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKUVf-00068m-LE
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:01:23 +0000
Received: from [193.109.254.147:16559] by server-5.bemta-14.messagelabs.com id
	BD/4B-30733-22BBE8F4; Wed, 18 Apr 2012 13:01:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334754071!5166984!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22568 invoked from network); 18 Apr 2012 13:01:12 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.81) by server-12.tower-27.messagelabs.com with SMTP;
	18 Apr 2012 13:01:12 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 60B92300064;
	Wed, 18 Apr 2012 06:01:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=HWhKLeDprlC99MPFEVKgZv
	BuFXI/j+QcKYev0fd2HYfa7ZPVKhLnan4gvGsCtp4xkxEQH+z8fAd7yOsaGzJIFw
	P2M45+DoP/FcF24KBDccyFE9dTSmGZrOzhibtIrFAFRZBiEniIgBtcXFxQaFHMHT
	Lou1lJhHSF60Y+jV6z1BA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=WbfHHfkmaKmz
	DxvtiNuWP5WR0TA=; b=XIbRiUG1uxE8RGVGiKeohmNUFwoXbc3Ik+WReUwSt6uZ
	gdUYRcnhh2M94x5gzpySF9kLNZi7wwA9hweKA06jI4L2sZilWJv4Xe+nv9OABHPf
	uo40ORmDUeo62prxgU6JEKtTVvzCcrP8G2Qus3v6BKmYb+ZQINzuT12/r+o7X+w=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id D659F300072; 
	Wed, 18 Apr 2012 06:01:09 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 495d3df95c1d59f55d5ac94ee2eab00da60651e4
Message-Id: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 18 Apr 2012 09:06:40 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
     if ( spage->sharing->handle != sh )
         goto err_unlock;
 
-    /* Make sure the target page is a hole in the physmap */
+    /* Make sure the target page is a hole in the physmap. This is not as
+     * simple a test as we'd like it to be. Non-existent p2m entries return
+     * invalid mfn and p2m_mmio_dm type when queried. */
     if ( mfn_valid(cmfn) ||
-         (!(p2m_is_ram(cmfn_type))) )
+         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )
     {
         ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUac-0006GF-GP; Wed, 18 Apr 2012 13:06:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKUab-0006G9-6g
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:06:29 +0000
Received: from [85.158.143.99:55227] by server-2.bemta-4.messagelabs.com id
	DD/05-17550-45CBE8F4; Wed, 18 Apr 2012 13:06:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334754386!18917987!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODIzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7347 invoked from network); 18 Apr 2012 13:06:27 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 13:06:27 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 08ED676C065;
	Wed, 18 Apr 2012 06:06:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=RKwxJ/dLLPllV2LPePoxPm9C03j/9P1s+3a0YYgM5LEk
	4lEM9qnI7Ok5FgnLr9elIY67l7ZXryWzZYKnB9DKUnpWOq0gslQdJIaP/y7lC/nF
	hcmSVqi1iJ3TjN/Crddp6z/EjH4Cu1vdcbc6R7TDQGG+0A7n2hXv/1wqBk5irVo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=QWF5H7f+ZMuvxgETZgwQAcKIrG0=; b=bt9L/Wqd
	wGoni9CsbqtzcmK5wQbIfIM64fAMJyEdXYGGl/mItbp4H7kRPPY9L8TLQ+g7el7q
	l/tli0mY496PjNz9f89dC4UTpY2Zx9x2XTA+1ffeAHd1Ebu1isgM3LaXLbtZ6KAd
	wxLuBjbaub5jG/O5EVECTSfQt0RjXaoyZFM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 8381F76C069; 
	Wed, 18 Apr 2012 06:06:25 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 06:06:26 -0700
Message-ID: <2f4abfcbe8cf5d301c8d75ed984605a3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418124201.GF7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
	<20120418124201.GF7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 06:06:26 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm/sharing: Clean ups for
 relinquishing shared pages on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 10:16 -0400 on 12 Apr (1334225772), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/domain.c             |  16 ++++++++++++-
>>  xen/arch/x86/mm/mem_sharing.c     |  45
>> +++++++++++++++++++++++++++++++++++++++
>>  xen/arch/x86/mm/p2m.c             |   4 +++
>>  xen/include/asm-arm/mm.h          |   4 +++
>>  xen/include/asm-x86/domain.h      |   1 +
>>  xen/include/asm-x86/mem_sharing.h |  10 ++++++++
>>  xen/include/asm-x86/p2m.h         |   4 +++
>>  7 files changed, 82 insertions(+), 2 deletions(-)
>>
>>
>> When a domain is destroyed, its pages are freed in relinquish_resources
>> in a
>> preemptible mode, in the context of a synchronous domctl.
>>
>> P2m entries pointing to shared pages are, however, released during p2m
>> cleanup
>> in an RCU callback, and in non-preemptible mode.
>>
>> This is an O(n) operation for a very large n, which may include actually
>> freeing shared pages for which the domain is the last holder.
>>
>> To improve responsiveness, move this operation to the preemtible portion
>> of
>> domain destruction, during the synchronous domain_kill hypercall. And
>> remove
>> the bulk of the work from the RCU callback.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> I've applied this as a bug-fix.  The other two seem more like new
> development and I'm less happy about taking them before 4.2

Thanks for applying this one.

Can I ask you to reconsider on the other two? Right now I can freeze up
the hypervisor for several minutes (without these two patches). Soft
lockups start popping up in dom0. I've had two instances in which the
block IO driver bails out and the dom0 file system becomes read-only,
forcing host reboot. It's a horrible performance regression this is
fixing.

Thanks,
Andres
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUac-0006GF-GP; Wed, 18 Apr 2012 13:06:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKUab-0006G9-6g
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:06:29 +0000
Received: from [85.158.143.99:55227] by server-2.bemta-4.messagelabs.com id
	DD/05-17550-45CBE8F4; Wed, 18 Apr 2012 13:06:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334754386!18917987!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODIzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7347 invoked from network); 18 Apr 2012 13:06:27 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 13:06:27 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 08ED676C065;
	Wed, 18 Apr 2012 06:06:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=RKwxJ/dLLPllV2LPePoxPm9C03j/9P1s+3a0YYgM5LEk
	4lEM9qnI7Ok5FgnLr9elIY67l7ZXryWzZYKnB9DKUnpWOq0gslQdJIaP/y7lC/nF
	hcmSVqi1iJ3TjN/Crddp6z/EjH4Cu1vdcbc6R7TDQGG+0A7n2hXv/1wqBk5irVo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=QWF5H7f+ZMuvxgETZgwQAcKIrG0=; b=bt9L/Wqd
	wGoni9CsbqtzcmK5wQbIfIM64fAMJyEdXYGGl/mItbp4H7kRPPY9L8TLQ+g7el7q
	l/tli0mY496PjNz9f89dC4UTpY2Zx9x2XTA+1ffeAHd1Ebu1isgM3LaXLbtZ6KAd
	wxLuBjbaub5jG/O5EVECTSfQt0RjXaoyZFM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 8381F76C069; 
	Wed, 18 Apr 2012 06:06:25 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 06:06:26 -0700
Message-ID: <2f4abfcbe8cf5d301c8d75ed984605a3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418124201.GF7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<9cbdf6b230dc6d2d2964.1334240172@xdev.gridcentric.ca>
	<20120418124201.GF7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 06:06:26 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm/sharing: Clean ups for
 relinquishing shared pages on destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 10:16 -0400 on 12 Apr (1334225772), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/domain.c             |  16 ++++++++++++-
>>  xen/arch/x86/mm/mem_sharing.c     |  45
>> +++++++++++++++++++++++++++++++++++++++
>>  xen/arch/x86/mm/p2m.c             |   4 +++
>>  xen/include/asm-arm/mm.h          |   4 +++
>>  xen/include/asm-x86/domain.h      |   1 +
>>  xen/include/asm-x86/mem_sharing.h |  10 ++++++++
>>  xen/include/asm-x86/p2m.h         |   4 +++
>>  7 files changed, 82 insertions(+), 2 deletions(-)
>>
>>
>> When a domain is destroyed, its pages are freed in relinquish_resources
>> in a
>> preemptible mode, in the context of a synchronous domctl.
>>
>> P2m entries pointing to shared pages are, however, released during p2m
>> cleanup
>> in an RCU callback, and in non-preemptible mode.
>>
>> This is an O(n) operation for a very large n, which may include actually
>> freeing shared pages for which the domain is the last holder.
>>
>> To improve responsiveness, move this operation to the preemtible portion
>> of
>> domain destruction, during the synchronous domain_kill hypercall. And
>> remove
>> the bulk of the work from the RCU callback.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> I've applied this as a bug-fix.  The other two seem more like new
> development and I'm less happy about taking them before 4.2

Thanks for applying this one.

Can I ask you to reconsider on the other two? Right now I can freeze up
the hypervisor for several minutes (without these two patches). Soft
lockups start popping up in dom0. I've had two instances in which the
block IO driver bails out and the dom0 file system becomes read-only,
forcing host reboot. It's a horrible performance regression this is
fixing.

Thanks,
Andres
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:29:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUwi-0006cQ-Mn; Wed, 18 Apr 2012 13:29:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKUwg-0006cL-P2
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:29:19 +0000
Received: from [85.158.139.83:62847] by server-9.bemta-5.messagelabs.com id
	4F/9E-09826-DA1CE8F4; Wed, 18 Apr 2012 13:29:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334755755!24383301!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2546 invoked from network); 18 Apr 2012 13:29:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 13:29:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190915145"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:28:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:28:19 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKUvi-0000rw-FB;
	Wed, 18 Apr 2012 14:28:18 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 14:28:18 +0100
Message-ID: <2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
In-Reply-To: <1334752277.23948.233.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 Apr 2012, at 13:31, Ian Campbell wrote:

>>>> @@ -55,6 +55,13 @@ default.
>>>>
>>>> Default: C<1>
>>>>
>>>> +=item B<disable_vif_scripts=BOOLEAN>
>>>> +
>>>> +If enabled xl will not execute nic hotplug scripts itself, and
>>>> instead
>>>> +relegate this task to udev.
>>>> +
>>>> +Default: C<0>
>>>
>>> Please can you also add a commented out version
>>> to ./tools/examples/xl.conf, with the value of the default.
>>>
>>> This doesn't actually disable the scripts entirely, but rather only
>>> from > udev, disable_udev_vif_scripts perhaps?
>>
>> It actually disables script calling from libxl, so I think it might 
>> be
>> best to call it disable_xl_vif_scripts?
>
> Oh, I was confusing it with the xenstore key used by the scripts! I
> think your existing name is fine then.

I've changed it to disable_xl_vif_scripts, which I think is even more 
clear.

>>>> @@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc
>>>> *egc, libxl__ao *ao,
>>>> {
>>>> AO_GC;
>>>> libxl_ctx *ctx = libxl__gc_owner(gc);
>>>> -    xs_transaction_t t;
>>>> +    xs_transaction_t t = 0;
>>>> char *be_path = libxl__device_backend_path(gc, dev);
>>>> char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>>>> -    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
>>>> +    char *state;
>>>> int rc = 0;
>>>> libxl__ao_device_remove *aorm = 0;
>>>>
>>>> +    /*
>>>> +     * Nuke frontend to force backend teardown
>>>> +     * It's not pretty, but it's the only way that seems to work 
>>>> for
>>>> all
>>>> +     * types of backends
>>>> +     */
>>>
>>> I'm still not happy with this. The _remove functions are supposed to
>>> be
>>> a graceful + co-operative remove, that means prodding the front and
>>> backend into doing the controlled teardown dance.
>>>
>>> This may well take some time and may even fail after some timeout
>>> depending on the device type, guest configuration and co-operation
>>> etc,
>>> but that is expected and should be handled.
>>>
>>> Forcing things in this way is appropriate for device_destroy only 
>>> IMHO
>>> since that is the function which is provided for use when the guest 
>>> is
>>> not co-operating.
>>
>> Before this patch, we used to just nuke both front and back xenstore
>> directories (because we always called libxl__device_destroy),
>
> Not always, the call to destroy depended on the current state.
>
> In the case where the guest is alive and responsive we have to do the
> hot remove in the graceful way. If the guest is alive but not 
> responsive
> then the correct approach is to try the graceful method with a timeout
> which triggers the big hammer approach.

Ok, I will add and extra parameter to libxl__initiate_device_remove that 
turns on or off the destruction of the front xenstore entries. We will 
first call it without removing the fronted, and if that fails we will 
call libxl__initiate_device_remove from the callback this time forcing 
the removal of the frontend.

>
>> so I think
>> this is quite and improvement in term of co-operation than what we 
>> had
>> before. We only used this kind of negotiation when detaching a block
>> from a live guest.
>>
>>>
>>>> +    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
>>>> dev));
>>>> +
>>>> +retry_transaction:
>>>> +    t = xs_transaction_start(ctx->xsh);
>>>> +    state = libxl__xs_read(gc, t, state_path);
>>>> if (!state)
>>>>  goto out_ok;
>>>> -    if (atoi(state) != 4) {
>>>> +    if (atoi(state) == XenbusStateClosed)
>>>>  libxl__device_destroy_tapdisk(gc, be_path);
>>>>  goto out_ok;
>>>> -    }
>>>>
>>>> -retry_transaction:
>>>> -    t = xs_transaction_start(ctx->xsh);
>>>> xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), 
>>>> "0",
>>>> strlen("0"));
>>>> xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
>>>> if (!xs_transaction_end(ctx->xsh, t, 0)) {
>>>> @@ -476,6 +537,8 @@ retry_transaction:
>>>>      goto out_fail;
>>>>  }
>>>> }
>>>> +    /* mark transaction as ended, to prevent double closing it on
>>>> out_ok */
>>>> +    t = 0;
>>>>
>>>> libxl__device_destroy_tapdisk(gc, be_path);
>>>>
>>>> @@ -497,8 +560,8 @@ retry_transaction:
>>>> return rc;
>>>>
>>>> out_ok:
>>>> +    if (t) xs_transaction_end(ctx->xsh, t, 0);
>>>> rc = libxl__device_hotplug(gc, dev, DISCONNECT);
>>>> -    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
>>>> dev));
>>>> libxl__xs_path_cleanup(gc, be_path);
>>>> return 0;
>>>> }
>>>> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
>>>> index c5583af..1ef282f 100644
>>>> --- a/tools/libxl/libxl_linux.c
>>>> +++ b/tools/libxl/libxl_linux.c
>>>> @@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
>>>> }
>>>>
>>>> /* Hotplug scripts helpers */
>>>> +
>>>> +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device
>>>> *dev)
>>>> +{
>>>> +    libxl_ctx *ctx = libxl__gc_owner(gc);
>>>> +    char *snictype, *be_path;
>>>> +
>>>> +    be_path = libxl__device_backend_path(gc, dev);
>>>> +
>>>> +    snictype = libxl__xs_read(gc, XBT_NULL,
>>>> +                            libxl__sprintf(gc, "%s/%s", be_path,
>>>> "type"));
>>>
>>> This really ought to be under some private libxl path relating to 
>>> the
>>> device rather than under the backend/frontend visible dirs.
>>
>> Well, this is currently only used by libxl, but the type of the 
>> backend
>> used I think should be inside the backend device directory, since 
>> other
>> applications might also want to know this.
>
> Hang on, can't you infer the type from the backend path, one should
> contains vif and the other something else (tap)? Or is this because of
> the stupid sharing of the vif dir for both vif and tap from the 
> hotplug
> scripts point of view?

Nope, tap doesn't have a backend xenstore entry, only vifs have, so this 
is kind of a hack because I was marking a vifs path as tap...

> It's probably too late in the 4.2 cycle to direct the tap hotplug 
> script
> to a different backend dir so I think the best thing to do for now is 
> to
> put this key somewhere else so that it doesn't become a guest visible
> API (which is what happens with where you have put it). The same place
> as udev_disable would work fine.

Does this paths sound ok:

/libxl/devices/<domid>/nic/<devid>/udev_disable
/libxl/devices/<domid>/nic/<devid>/type

>>> Actually, now I think of it, that is also true of the udev_disable
>>> key?
>>
>> This is probably true for udev_disable, something like
>> /libxl/devices/<domid>/<devid>/udev_disable? I will have to modify
>> libxl__device_generic_add to do this, because it should be done on 
>> the
>> same transaction when the device is added. I'm not sure if we need to
>> add so much overhead for just one xenstore entry, that will go away 
>> in
>> the next release probably.
>
> I think this will be around for more than one release (these
> deprecations always take time) so it is worth doing right.
>
>>>
>>>> +    if (!snictype) {
>>>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype
>>>> from %s",
>>>> +                                          be_path);
>>>> +        return -1;
>>>> +    }
>>>> +
>>>> +    return atoi(snictype);
>>>> +}
>>>> +
>>>> @@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc,
>>>> libxl__device *dev)
>>>>            dev->domid, dev->devid));
>>>> flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
>>>> flexarray_set(f_env, nr++, "backend");
>>>> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
>>>> +        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
>>>> "%s/%s",
>>>> +
>>>> be_path,
>>>> +
>>>> "vifname"));
>>>> +        switch (get_nic_type(gc, dev)) {
>>>> +        case LIBXL_NIC_TYPE_IOEMU:
>>>> +            flexarray_set(f_env, nr++, "INTERFACE");
>>>> +            if (ifname) {
>>>> +                flexarray_set(f_env, nr++, libxl__sprintf(gc,
>>>> "xentap-%s",
>>>> +
>>>> ifname));
>>>> +            } else {
>>>> +                flexarray_set(f_env, nr++,
>>>> +                              libxl__sprintf(gc, "xentap%u.%d",
>>>> +                              dev->domid, dev->devid));
>>>
>>> This is cut-n-paste of some other code, perhaps create a function to
>>> get
>>> the tap name from the vif name and or dom/devid?
>>
>>
>> Are you going to add it to your patch or I should add it to mine?
>
> I'll let you do it if that's alright.
>> Something like:
>>
>> char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev)
> [...]
>> char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev)
>>
>> Both this functions should return the correct vifname if one is set, 
>> or
>> the default one otherwise.
>
> Yep.
>
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:29:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUwi-0006cQ-Mn; Wed, 18 Apr 2012 13:29:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKUwg-0006cL-P2
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:29:19 +0000
Received: from [85.158.139.83:62847] by server-9.bemta-5.messagelabs.com id
	4F/9E-09826-DA1CE8F4; Wed, 18 Apr 2012 13:29:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334755755!24383301!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2546 invoked from network); 18 Apr 2012 13:29:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 13:29:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190915145"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:28:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:28:19 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKUvi-0000rw-FB;
	Wed, 18 Apr 2012 14:28:18 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 14:28:18 +0100
Message-ID: <2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
In-Reply-To: <1334752277.23948.233.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 Apr 2012, at 13:31, Ian Campbell wrote:

>>>> @@ -55,6 +55,13 @@ default.
>>>>
>>>> Default: C<1>
>>>>
>>>> +=item B<disable_vif_scripts=BOOLEAN>
>>>> +
>>>> +If enabled xl will not execute nic hotplug scripts itself, and
>>>> instead
>>>> +relegate this task to udev.
>>>> +
>>>> +Default: C<0>
>>>
>>> Please can you also add a commented out version
>>> to ./tools/examples/xl.conf, with the value of the default.
>>>
>>> This doesn't actually disable the scripts entirely, but rather only
>>> from > udev, disable_udev_vif_scripts perhaps?
>>
>> It actually disables script calling from libxl, so I think it might 
>> be
>> best to call it disable_xl_vif_scripts?
>
> Oh, I was confusing it with the xenstore key used by the scripts! I
> think your existing name is fine then.

I've changed it to disable_xl_vif_scripts, which I think is even more 
clear.

>>>> @@ -450,22 +504,29 @@ int libxl__initiate_device_remove(libxl__egc
>>>> *egc, libxl__ao *ao,
>>>> {
>>>> AO_GC;
>>>> libxl_ctx *ctx = libxl__gc_owner(gc);
>>>> -    xs_transaction_t t;
>>>> +    xs_transaction_t t = 0;
>>>> char *be_path = libxl__device_backend_path(gc, dev);
>>>> char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>>>> -    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
>>>> +    char *state;
>>>> int rc = 0;
>>>> libxl__ao_device_remove *aorm = 0;
>>>>
>>>> +    /*
>>>> +     * Nuke frontend to force backend teardown
>>>> +     * It's not pretty, but it's the only way that seems to work 
>>>> for
>>>> all
>>>> +     * types of backends
>>>> +     */
>>>
>>> I'm still not happy with this. The _remove functions are supposed to
>>> be
>>> a graceful + co-operative remove, that means prodding the front and
>>> backend into doing the controlled teardown dance.
>>>
>>> This may well take some time and may even fail after some timeout
>>> depending on the device type, guest configuration and co-operation
>>> etc,
>>> but that is expected and should be handled.
>>>
>>> Forcing things in this way is appropriate for device_destroy only 
>>> IMHO
>>> since that is the function which is provided for use when the guest 
>>> is
>>> not co-operating.
>>
>> Before this patch, we used to just nuke both front and back xenstore
>> directories (because we always called libxl__device_destroy),
>
> Not always, the call to destroy depended on the current state.
>
> In the case where the guest is alive and responsive we have to do the
> hot remove in the graceful way. If the guest is alive but not 
> responsive
> then the correct approach is to try the graceful method with a timeout
> which triggers the big hammer approach.

Ok, I will add and extra parameter to libxl__initiate_device_remove that 
turns on or off the destruction of the front xenstore entries. We will 
first call it without removing the fronted, and if that fails we will 
call libxl__initiate_device_remove from the callback this time forcing 
the removal of the frontend.

>
>> so I think
>> this is quite and improvement in term of co-operation than what we 
>> had
>> before. We only used this kind of negotiation when detaching a block
>> from a live guest.
>>
>>>
>>>> +    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
>>>> dev));
>>>> +
>>>> +retry_transaction:
>>>> +    t = xs_transaction_start(ctx->xsh);
>>>> +    state = libxl__xs_read(gc, t, state_path);
>>>> if (!state)
>>>>  goto out_ok;
>>>> -    if (atoi(state) != 4) {
>>>> +    if (atoi(state) == XenbusStateClosed)
>>>>  libxl__device_destroy_tapdisk(gc, be_path);
>>>>  goto out_ok;
>>>> -    }
>>>>
>>>> -retry_transaction:
>>>> -    t = xs_transaction_start(ctx->xsh);
>>>> xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), 
>>>> "0",
>>>> strlen("0"));
>>>> xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
>>>> if (!xs_transaction_end(ctx->xsh, t, 0)) {
>>>> @@ -476,6 +537,8 @@ retry_transaction:
>>>>      goto out_fail;
>>>>  }
>>>> }
>>>> +    /* mark transaction as ended, to prevent double closing it on
>>>> out_ok */
>>>> +    t = 0;
>>>>
>>>> libxl__device_destroy_tapdisk(gc, be_path);
>>>>
>>>> @@ -497,8 +560,8 @@ retry_transaction:
>>>> return rc;
>>>>
>>>> out_ok:
>>>> +    if (t) xs_transaction_end(ctx->xsh, t, 0);
>>>> rc = libxl__device_hotplug(gc, dev, DISCONNECT);
>>>> -    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc,
>>>> dev));
>>>> libxl__xs_path_cleanup(gc, be_path);
>>>> return 0;
>>>> }
>>>> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
>>>> index c5583af..1ef282f 100644
>>>> --- a/tools/libxl/libxl_linux.c
>>>> +++ b/tools/libxl/libxl_linux.c
>>>> @@ -27,11 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
>>>> }
>>>>
>>>> /* Hotplug scripts helpers */
>>>> +
>>>> +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device
>>>> *dev)
>>>> +{
>>>> +    libxl_ctx *ctx = libxl__gc_owner(gc);
>>>> +    char *snictype, *be_path;
>>>> +
>>>> +    be_path = libxl__device_backend_path(gc, dev);
>>>> +
>>>> +    snictype = libxl__xs_read(gc, XBT_NULL,
>>>> +                            libxl__sprintf(gc, "%s/%s", be_path,
>>>> "type"));
>>>
>>> This really ought to be under some private libxl path relating to 
>>> the
>>> device rather than under the backend/frontend visible dirs.
>>
>> Well, this is currently only used by libxl, but the type of the 
>> backend
>> used I think should be inside the backend device directory, since 
>> other
>> applications might also want to know this.
>
> Hang on, can't you infer the type from the backend path, one should
> contains vif and the other something else (tap)? Or is this because of
> the stupid sharing of the vif dir for both vif and tap from the 
> hotplug
> scripts point of view?

Nope, tap doesn't have a backend xenstore entry, only vifs have, so this 
is kind of a hack because I was marking a vifs path as tap...

> It's probably too late in the 4.2 cycle to direct the tap hotplug 
> script
> to a different backend dir so I think the best thing to do for now is 
> to
> put this key somewhere else so that it doesn't become a guest visible
> API (which is what happens with where you have put it). The same place
> as udev_disable would work fine.

Does this paths sound ok:

/libxl/devices/<domid>/nic/<devid>/udev_disable
/libxl/devices/<domid>/nic/<devid>/type

>>> Actually, now I think of it, that is also true of the udev_disable
>>> key?
>>
>> This is probably true for udev_disable, something like
>> /libxl/devices/<domid>/<devid>/udev_disable? I will have to modify
>> libxl__device_generic_add to do this, because it should be done on 
>> the
>> same transaction when the device is added. I'm not sure if we need to
>> add so much overhead for just one xenstore entry, that will go away 
>> in
>> the next release probably.
>
> I think this will be around for more than one release (these
> deprecations always take time) so it is worth doing right.
>
>>>
>>>> +    if (!snictype) {
>>>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype
>>>> from %s",
>>>> +                                          be_path);
>>>> +        return -1;
>>>> +    }
>>>> +
>>>> +    return atoi(snictype);
>>>> +}
>>>> +
>>>> @@ -62,6 +81,35 @@ static char **get_hotplug_env(libxl__gc *gc,
>>>> libxl__device *dev)
>>>>            dev->domid, dev->devid));
>>>> flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
>>>> flexarray_set(f_env, nr++, "backend");
>>>> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
>>>> +        ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
>>>> "%s/%s",
>>>> +
>>>> be_path,
>>>> +
>>>> "vifname"));
>>>> +        switch (get_nic_type(gc, dev)) {
>>>> +        case LIBXL_NIC_TYPE_IOEMU:
>>>> +            flexarray_set(f_env, nr++, "INTERFACE");
>>>> +            if (ifname) {
>>>> +                flexarray_set(f_env, nr++, libxl__sprintf(gc,
>>>> "xentap-%s",
>>>> +
>>>> ifname));
>>>> +            } else {
>>>> +                flexarray_set(f_env, nr++,
>>>> +                              libxl__sprintf(gc, "xentap%u.%d",
>>>> +                              dev->domid, dev->devid));
>>>
>>> This is cut-n-paste of some other code, perhaps create a function to
>>> get
>>> the tap name from the vif name and or dom/devid?
>>
>>
>> Are you going to add it to your patch or I should add it to mine?
>
> I'll let you do it if that's alright.
>> Something like:
>>
>> char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev)
> [...]
>> char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev)
>>
>> Both this functions should return the correct vifname if one is set, 
>> or
>> the default one otherwise.
>
> Yep.
>
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:32:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUzH-0006jI-HL; Wed, 18 Apr 2012 13:31:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKUzG-0006jC-BB
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:31:58 +0000
Received: from [85.158.138.51:50079] by server-7.bemta-3.messagelabs.com id
	7D/AD-03078-D42CE8F4; Wed, 18 Apr 2012 13:31:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334755916!22734951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30137 invoked from network); 18 Apr 2012 13:31:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 13:31:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12003427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 13:31:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 14:31:46 +0100
Message-ID: <1334755904.23948.239.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 14:31:44 +0100
In-Reply-To: <2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> Ok, I will add and extra parameter to libxl__initiate_device_remove that 
> turns on or off the destruction of the front xenstore entries. We will 
> first call it without removing the fronted, and if that fails we will 
> call libxl__initiate_device_remove from the callback this time forcing 
> the removal of the frontend.

If libxl__initiate_device_remove fails then you should be calling
libxl__initiate_device_destroy, I think, so no need for a param to
_remove?

> > Hang on, can't you infer the type from the backend path, one should
> > contains vif and the other something else (tap)? Or is this because of
> > the stupid sharing of the vif dir for both vif and tap from the 
> > hotplug
> > scripts point of view?
> 
> Nope, tap doesn't have a backend xenstore entry, only vifs have, so this 
> is kind of a hack because I was marking a vifs path as tap...

Right, that's the stupid sharing I was referring too (which IIRC I
added :-/)

> 
> > It's probably too late in the 4.2 cycle to direct the tap hotplug 
> > script
> > to a different backend dir so I think the best thing to do for now is 
> > to
> > put this key somewhere else so that it doesn't become a guest visible
> > API (which is what happens with where you have put it). The same place
> > as udev_disable would work fine.
> 
> Does this paths sound ok:
> 
> /libxl/devices/<domid>/nic/<devid>/udev_disable
> /libxl/devices/<domid>/nic/<devid>/type

Works for me.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:32:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKUzH-0006jI-HL; Wed, 18 Apr 2012 13:31:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKUzG-0006jC-BB
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:31:58 +0000
Received: from [85.158.138.51:50079] by server-7.bemta-3.messagelabs.com id
	7D/AD-03078-D42CE8F4; Wed, 18 Apr 2012 13:31:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334755916!22734951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30137 invoked from network); 18 Apr 2012 13:31:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 13:31:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12003427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 13:31:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 14:31:46 +0100
Message-ID: <1334755904.23948.239.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 14:31:44 +0100
In-Reply-To: <2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> Ok, I will add and extra parameter to libxl__initiate_device_remove that 
> turns on or off the destruction of the front xenstore entries. We will 
> first call it without removing the fronted, and if that fails we will 
> call libxl__initiate_device_remove from the callback this time forcing 
> the removal of the frontend.

If libxl__initiate_device_remove fails then you should be calling
libxl__initiate_device_destroy, I think, so no need for a param to
_remove?

> > Hang on, can't you infer the type from the backend path, one should
> > contains vif and the other something else (tap)? Or is this because of
> > the stupid sharing of the vif dir for both vif and tap from the 
> > hotplug
> > scripts point of view?
> 
> Nope, tap doesn't have a backend xenstore entry, only vifs have, so this 
> is kind of a hack because I was marking a vifs path as tap...

Right, that's the stupid sharing I was referring too (which IIRC I
added :-/)

> 
> > It's probably too late in the 4.2 cycle to direct the tap hotplug 
> > script
> > to a different backend dir so I think the best thing to do for now is 
> > to
> > put this key somewhere else so that it doesn't become a guest visible
> > API (which is what happens with where you have put it). The same place
> > as udev_disable would work fine.
> 
> Does this paths sound ok:
> 
> /libxl/devices/<domid>/nic/<devid>/udev_disable
> /libxl/devices/<domid>/nic/<devid>/type

Works for me.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:49:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVFp-00076c-7D; Wed, 18 Apr 2012 13:49:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKVFn-00076X-KQ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:49:03 +0000
Received: from [85.158.138.51:36059] by server-3.bemta-3.messagelabs.com id
	F4/1E-04048-E46CE8F4; Wed, 18 Apr 2012 13:49:02 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334756940!22742134!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20525 invoked from network); 18 Apr 2012 13:49:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 13:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190920243"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:48:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:48:34 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKVFK-000187-4X;
	Wed, 18 Apr 2012 14:48:34 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 14:48:33 +0100
Message-ID: <498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
In-Reply-To: <1334755904.23948.239.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTggQXByIDIwMTIsIGF0IDE0OjMxLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cgo+PiBPaywgSSB3
aWxsIGFkZCBhbmQgZXh0cmEgcGFyYW1ldGVyIHRvIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVt
b3ZlIAo+PiB0aGF0Cj4+IHR1cm5zIG9uIG9yIG9mZiB0aGUgZGVzdHJ1Y3Rpb24gb2YgdGhlIGZy
b250IHhlbnN0b3JlIGVudHJpZXMuIFdlIAo+PiB3aWxsCj4+IGZpcnN0IGNhbGwgaXQgd2l0aG91
dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlmIHRoYXQgZmFpbHMgd2Ugd2lsbAo+PiBjYWxs
IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlIGZyb20gdGhlIGNhbGxiYWNrIHRoaXMgdGlt
ZSAKPj4gZm9yY2luZwo+PiB0aGUgcmVtb3ZhbCBvZiB0aGUgZnJvbnRlbmQuCj4KPiBJZiBsaWJ4
bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSBmYWlscyB0aGVuIHlvdSBzaG91bGQgYmUgY2FsbGlu
Zwo+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfZGVzdHJveSwgSSB0aGluaywgc28gbm8gbmVlZCBm
b3IgYSBwYXJhbSB0bwo+IF9yZW1vdmU/CgpOb3QgcmVhbGx54oCmIFRoYXQncyBob3cgSSB0aGlu
ayB0aGUgcmVtb3ZhbCBwYXRoIHNob3VsZCBiZToKCjEtIFdhaXQgZm9yIGJhY2tlbmQgdG8gdHVy
biB0byBzdGF0ZSA2IC0tLS0tPiBpZiBvayB0aGVuIGV4ZWN1dGUgCmhvdHBsdWcsIGFuZCByZW1v
dmUgZnJvbnQvYmFja2VuZAoyLSBJZiB0aW1lb3V0OiBudWtlIGZyb250ZW5kIGFuZCB3YWl0IGZv
ciBiYWNrZW5kIHN0YXRlIDYgLS0tLS0+IGlmIG9rIAp0aGVuIGV4ZWN1dGUgaG90cGx1ZyBhbmQg
cmVtb3ZlIGZyb250L2JhY2sKMy0gSWYgdGltZW91dDogbnVrZSBmcm9udC9iYWNrZW5kCgo+Pj4g
SGFuZyBvbiwgY2FuJ3QgeW91IGluZmVyIHRoZSB0eXBlIGZyb20gdGhlIGJhY2tlbmQgcGF0aCwg
b25lIHNob3VsZAo+Pj4gY29udGFpbnMgdmlmIGFuZCB0aGUgb3RoZXIgc29tZXRoaW5nIGVsc2Ug
KHRhcCk/IE9yIGlzIHRoaXMgYmVjYXVzZSAKPj4+IG9mCj4+PiB0aGUgc3R1cGlkIHNoYXJpbmcg
b2YgdGhlIHZpZiBkaXIgZm9yIGJvdGggdmlmIGFuZCB0YXAgZnJvbSB0aGUKPj4+IGhvdHBsdWcK
Pj4+IHNjcmlwdHMgcG9pbnQgb2Ygdmlldz8KPj4KPj4gTm9wZSwgdGFwIGRvZXNuJ3QgaGF2ZSBh
IGJhY2tlbmQgeGVuc3RvcmUgZW50cnksIG9ubHkgdmlmcyBoYXZlLCBzbyAKPj4gdGhpcwo+PiBp
cyBraW5kIG9mIGEgaGFjayBiZWNhdXNlIEkgd2FzIG1hcmtpbmcgYSB2aWZzIHBhdGggYXMgdGFw
Li4uCj4KPiBSaWdodCwgdGhhdCdzIHRoZSBzdHVwaWQgc2hhcmluZyBJIHdhcyByZWZlcnJpbmcg
dG9vICh3aGljaCBJSVJDIEkKPiBhZGRlZCA6LS8pCj4KPj4KPj4+IEl0J3MgcHJvYmFibHkgdG9v
IGxhdGUgaW4gdGhlIDQuMiBjeWNsZSB0byBkaXJlY3QgdGhlIHRhcCBob3RwbHVnCj4+PiBzY3Jp
cHQKPj4+IHRvIGEgZGlmZmVyZW50IGJhY2tlbmQgZGlyIHNvIEkgdGhpbmsgdGhlIGJlc3QgdGhp
bmcgdG8gZG8gZm9yIG5vdyAKPj4+IGlzCj4+PiB0bwo+Pj4gcHV0IHRoaXMga2V5IHNvbWV3aGVy
ZSBlbHNlIHNvIHRoYXQgaXQgZG9lc24ndCBiZWNvbWUgYSBndWVzdCAKPj4+IHZpc2libGUKPj4+
IEFQSSAod2hpY2ggaXMgd2hhdCBoYXBwZW5zIHdpdGggd2hlcmUgeW91IGhhdmUgcHV0IGl0KS4g
VGhlIHNhbWUgCj4+PiBwbGFjZQo+Pj4gYXMgdWRldl9kaXNhYmxlIHdvdWxkIHdvcmsgZmluZS4K
Pj4KPj4gRG9lcyB0aGlzIHBhdGhzIHNvdW5kIG9rOgo+Pgo+PiAvbGlieGwvZGV2aWNlcy88ZG9t
aWQ+L25pYy88ZGV2aWQ+L3VkZXZfZGlzYWJsZQo+PiAvbGlieGwvZGV2aWNlcy88ZG9taWQ+L25p
Yy88ZGV2aWQ+L3R5cGUKPgo+IFdvcmtzIGZvciBtZS4KPgo+IElhbi4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 18 13:49:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 13:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVFp-00076c-7D; Wed, 18 Apr 2012 13:49:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKVFn-00076X-KQ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:49:03 +0000
Received: from [85.158.138.51:36059] by server-3.bemta-3.messagelabs.com id
	F4/1E-04048-E46CE8F4; Wed, 18 Apr 2012 13:49:02 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334756940!22742134!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20525 invoked from network); 18 Apr 2012 13:49:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 13:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190920243"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 09:48:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 09:48:34 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKVFK-000187-4X;
	Wed, 18 Apr 2012 14:48:34 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 14:48:33 +0100
Message-ID: <498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
In-Reply-To: <1334755904.23948.239.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTggQXByIDIwMTIsIGF0IDE0OjMxLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cgo+PiBPaywgSSB3
aWxsIGFkZCBhbmQgZXh0cmEgcGFyYW1ldGVyIHRvIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVt
b3ZlIAo+PiB0aGF0Cj4+IHR1cm5zIG9uIG9yIG9mZiB0aGUgZGVzdHJ1Y3Rpb24gb2YgdGhlIGZy
b250IHhlbnN0b3JlIGVudHJpZXMuIFdlIAo+PiB3aWxsCj4+IGZpcnN0IGNhbGwgaXQgd2l0aG91
dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlmIHRoYXQgZmFpbHMgd2Ugd2lsbAo+PiBjYWxs
IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlIGZyb20gdGhlIGNhbGxiYWNrIHRoaXMgdGlt
ZSAKPj4gZm9yY2luZwo+PiB0aGUgcmVtb3ZhbCBvZiB0aGUgZnJvbnRlbmQuCj4KPiBJZiBsaWJ4
bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSBmYWlscyB0aGVuIHlvdSBzaG91bGQgYmUgY2FsbGlu
Zwo+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfZGVzdHJveSwgSSB0aGluaywgc28gbm8gbmVlZCBm
b3IgYSBwYXJhbSB0bwo+IF9yZW1vdmU/CgpOb3QgcmVhbGx54oCmIFRoYXQncyBob3cgSSB0aGlu
ayB0aGUgcmVtb3ZhbCBwYXRoIHNob3VsZCBiZToKCjEtIFdhaXQgZm9yIGJhY2tlbmQgdG8gdHVy
biB0byBzdGF0ZSA2IC0tLS0tPiBpZiBvayB0aGVuIGV4ZWN1dGUgCmhvdHBsdWcsIGFuZCByZW1v
dmUgZnJvbnQvYmFja2VuZAoyLSBJZiB0aW1lb3V0OiBudWtlIGZyb250ZW5kIGFuZCB3YWl0IGZv
ciBiYWNrZW5kIHN0YXRlIDYgLS0tLS0+IGlmIG9rIAp0aGVuIGV4ZWN1dGUgaG90cGx1ZyBhbmQg
cmVtb3ZlIGZyb250L2JhY2sKMy0gSWYgdGltZW91dDogbnVrZSBmcm9udC9iYWNrZW5kCgo+Pj4g
SGFuZyBvbiwgY2FuJ3QgeW91IGluZmVyIHRoZSB0eXBlIGZyb20gdGhlIGJhY2tlbmQgcGF0aCwg
b25lIHNob3VsZAo+Pj4gY29udGFpbnMgdmlmIGFuZCB0aGUgb3RoZXIgc29tZXRoaW5nIGVsc2Ug
KHRhcCk/IE9yIGlzIHRoaXMgYmVjYXVzZSAKPj4+IG9mCj4+PiB0aGUgc3R1cGlkIHNoYXJpbmcg
b2YgdGhlIHZpZiBkaXIgZm9yIGJvdGggdmlmIGFuZCB0YXAgZnJvbSB0aGUKPj4+IGhvdHBsdWcK
Pj4+IHNjcmlwdHMgcG9pbnQgb2Ygdmlldz8KPj4KPj4gTm9wZSwgdGFwIGRvZXNuJ3QgaGF2ZSBh
IGJhY2tlbmQgeGVuc3RvcmUgZW50cnksIG9ubHkgdmlmcyBoYXZlLCBzbyAKPj4gdGhpcwo+PiBp
cyBraW5kIG9mIGEgaGFjayBiZWNhdXNlIEkgd2FzIG1hcmtpbmcgYSB2aWZzIHBhdGggYXMgdGFw
Li4uCj4KPiBSaWdodCwgdGhhdCdzIHRoZSBzdHVwaWQgc2hhcmluZyBJIHdhcyByZWZlcnJpbmcg
dG9vICh3aGljaCBJSVJDIEkKPiBhZGRlZCA6LS8pCj4KPj4KPj4+IEl0J3MgcHJvYmFibHkgdG9v
IGxhdGUgaW4gdGhlIDQuMiBjeWNsZSB0byBkaXJlY3QgdGhlIHRhcCBob3RwbHVnCj4+PiBzY3Jp
cHQKPj4+IHRvIGEgZGlmZmVyZW50IGJhY2tlbmQgZGlyIHNvIEkgdGhpbmsgdGhlIGJlc3QgdGhp
bmcgdG8gZG8gZm9yIG5vdyAKPj4+IGlzCj4+PiB0bwo+Pj4gcHV0IHRoaXMga2V5IHNvbWV3aGVy
ZSBlbHNlIHNvIHRoYXQgaXQgZG9lc24ndCBiZWNvbWUgYSBndWVzdCAKPj4+IHZpc2libGUKPj4+
IEFQSSAod2hpY2ggaXMgd2hhdCBoYXBwZW5zIHdpdGggd2hlcmUgeW91IGhhdmUgcHV0IGl0KS4g
VGhlIHNhbWUgCj4+PiBwbGFjZQo+Pj4gYXMgdWRldl9kaXNhYmxlIHdvdWxkIHdvcmsgZmluZS4K
Pj4KPj4gRG9lcyB0aGlzIHBhdGhzIHNvdW5kIG9rOgo+Pgo+PiAvbGlieGwvZGV2aWNlcy88ZG9t
aWQ+L25pYy88ZGV2aWQ+L3VkZXZfZGlzYWJsZQo+PiAvbGlieGwvZGV2aWNlcy88ZG9taWQ+L25p
Yy88ZGV2aWQ+L3R5cGUKPgo+IFdvcmtzIGZvciBtZS4KPgo+IElhbi4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVQK-0007HP-CK; Wed, 18 Apr 2012 13:59:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKVQJ-0007HK-2K
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:59:55 +0000
Received: from [193.109.254.147:38712] by server-8.bemta-14.messagelabs.com id
	FA/15-23244-AD8CE8F4; Wed, 18 Apr 2012 13:59:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334757593!5135026!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11003 invoked from network); 18 Apr 2012 13:59:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 13:59:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKVQG-0002G4-RX; Wed, 18 Apr 2012 13:59:52 +0000
Date: Wed, 18 Apr 2012 14:59:52 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418135952.GG7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
	physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>      if ( spage->sharing->handle != sh )
>          goto err_unlock;
>  
> -    /* Make sure the target page is a hole in the physmap */
> +    /* Make sure the target page is a hole in the physmap. This is not as
> +     * simple a test as we'd like it to be. Non-existent p2m entries return
> +     * invalid mfn and p2m_mmio_dm type when queried. */
>      if ( mfn_valid(cmfn) ||
> -         (!(p2m_is_ram(cmfn_type))) )
> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )

This test looks wrong, even after the fix.  I think it should be testing
for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
mfn_valid().

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVQK-0007HP-CK; Wed, 18 Apr 2012 13:59:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKVQJ-0007HK-2K
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 13:59:55 +0000
Received: from [193.109.254.147:38712] by server-8.bemta-14.messagelabs.com id
	FA/15-23244-AD8CE8F4; Wed, 18 Apr 2012 13:59:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334757593!5135026!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11003 invoked from network); 18 Apr 2012 13:59:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 13:59:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKVQG-0002G4-RX; Wed, 18 Apr 2012 13:59:52 +0000
Date: Wed, 18 Apr 2012 14:59:52 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418135952.GG7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
	physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>      if ( spage->sharing->handle != sh )
>          goto err_unlock;
>  
> -    /* Make sure the target page is a hole in the physmap */
> +    /* Make sure the target page is a hole in the physmap. This is not as
> +     * simple a test as we'd like it to be. Non-existent p2m entries return
> +     * invalid mfn and p2m_mmio_dm type when queried. */
>      if ( mfn_valid(cmfn) ||
> -         (!(p2m_is_ram(cmfn_type))) )
> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )

This test looks wrong, even after the fix.  I think it should be testing
for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
mfn_valid().

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:06:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:06:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVW7-0007Tr-6B; Wed, 18 Apr 2012 14:05:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKVW4-0007Tl-QJ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:05:53 +0000
Received: from [85.158.139.83:62645] by server-9.bemta-5.messagelabs.com id
	68/DA-09826-04ACE8F4; Wed, 18 Apr 2012 14:05:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334757951!17042087!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32760 invoked from network); 18 Apr 2012 14:05:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 14:05:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKVW2-0002HY-Bj; Wed, 18 Apr 2012 14:05:50 +0000
Date: Wed, 18 Apr 2012 15:05:50 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418140550.GH7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse
	map for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:16 -0400 on 12 Apr (1334225773), Andres Lagar-Cavilla wrote:
>      /* Do the accounting first. If anything fails below, we have bigger
>       * bigger fish to fry. First, remove the gfn from the list. */ 
> -    last_gfn = list_has_one_entry(&page->sharing->gfns);
> +    last_gfn = rmap_has_one_entry(page);
>      if ( last_gfn )
>      {
> -        /* Clean up shared state */
> -        audit_del_list(page);
> +        /* Clean up shared state. Get rid of the <domid, gfn> tuple
> +         * before destroying the rmap. */
> +        mem_sharing_gfn_destroy(page, d, gfn_info);

Moving this mem_sharing_gfn_destroy() around seems like it's unrelated
to the rest of this patch, which is basically code motion.  If so, can
you put it in a patch of its own?

Otherwise, pending patch 3/3 being OK too, 

Acked-by: Tim Deegan <tim@xen.org>

> +        page_sharing_dispose(page);
>          page->sharing = NULL;
>          atomic_dec(&nr_shared_mfns);
>      }
>      else
>          atomic_dec(&nr_saved_mfns);
> +
>      /* If the GFN is getting destroyed drop the references to MFN 
>       * (possibly freeing the page), and exit early */
>      if ( flags & MEM_SHARING_DESTROY_GFN )
>      {
> -        mem_sharing_gfn_destroy(d, gfn_info);
> +        if ( !last_gfn )
> +            mem_sharing_gfn_destroy(page, d, gfn_info);
>          put_page_and_type(page);
>          mem_sharing_page_unlock(page);
>          if ( last_gfn && 
> @@ -987,7 +1052,6 @@ gfn_found:
>   
>      if ( last_gfn )
>      {
> -        mem_sharing_gfn_destroy(d, gfn_info);
>          /* Making a page private atomically unlocks it */
>          BUG_ON(page_make_private(d, page) != 0);
>          goto private_page_found;
> @@ -1011,7 +1075,7 @@ gfn_found:
>      unmap_domain_page(t);
>  
>      BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
> -    mem_sharing_gfn_destroy(d, gfn_info);
> +    mem_sharing_gfn_destroy(old_page, d, gfn_info);
>      mem_sharing_page_unlock(old_page);
>      put_page_and_type(old_page);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:06:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:06:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVW7-0007Tr-6B; Wed, 18 Apr 2012 14:05:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKVW4-0007Tl-QJ
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:05:53 +0000
Received: from [85.158.139.83:62645] by server-9.bemta-5.messagelabs.com id
	68/DA-09826-04ACE8F4; Wed, 18 Apr 2012 14:05:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334757951!17042087!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32760 invoked from network); 18 Apr 2012 14:05:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 14:05:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKVW2-0002HY-Bj; Wed, 18 Apr 2012 14:05:50 +0000
Date: Wed, 18 Apr 2012 15:05:50 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418140550.GH7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse
	map for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:16 -0400 on 12 Apr (1334225773), Andres Lagar-Cavilla wrote:
>      /* Do the accounting first. If anything fails below, we have bigger
>       * bigger fish to fry. First, remove the gfn from the list. */ 
> -    last_gfn = list_has_one_entry(&page->sharing->gfns);
> +    last_gfn = rmap_has_one_entry(page);
>      if ( last_gfn )
>      {
> -        /* Clean up shared state */
> -        audit_del_list(page);
> +        /* Clean up shared state. Get rid of the <domid, gfn> tuple
> +         * before destroying the rmap. */
> +        mem_sharing_gfn_destroy(page, d, gfn_info);

Moving this mem_sharing_gfn_destroy() around seems like it's unrelated
to the rest of this patch, which is basically code motion.  If so, can
you put it in a patch of its own?

Otherwise, pending patch 3/3 being OK too, 

Acked-by: Tim Deegan <tim@xen.org>

> +        page_sharing_dispose(page);
>          page->sharing = NULL;
>          atomic_dec(&nr_shared_mfns);
>      }
>      else
>          atomic_dec(&nr_saved_mfns);
> +
>      /* If the GFN is getting destroyed drop the references to MFN 
>       * (possibly freeing the page), and exit early */
>      if ( flags & MEM_SHARING_DESTROY_GFN )
>      {
> -        mem_sharing_gfn_destroy(d, gfn_info);
> +        if ( !last_gfn )
> +            mem_sharing_gfn_destroy(page, d, gfn_info);
>          put_page_and_type(page);
>          mem_sharing_page_unlock(page);
>          if ( last_gfn && 
> @@ -987,7 +1052,6 @@ gfn_found:
>   
>      if ( last_gfn )
>      {
> -        mem_sharing_gfn_destroy(d, gfn_info);
>          /* Making a page private atomically unlocks it */
>          BUG_ON(page_make_private(d, page) != 0);
>          goto private_page_found;
> @@ -1011,7 +1075,7 @@ gfn_found:
>      unmap_domain_page(t);
>  
>      BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
> -    mem_sharing_gfn_destroy(d, gfn_info);
> +    mem_sharing_gfn_destroy(old_page, d, gfn_info);
>      mem_sharing_page_unlock(old_page);
>      put_page_and_type(old_page);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:19:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:19:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVil-0007nH-Hx; Wed, 18 Apr 2012 14:18:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKVij-0007nC-Vb
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:18:58 +0000
Received: from [85.158.143.99:10706] by server-2.bemta-4.messagelabs.com id
	21/E9-17550-15DCE8F4; Wed, 18 Apr 2012 14:18:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334758730!23637578!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODIzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24173 invoked from network); 18 Apr 2012 14:18:56 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 14:18:56 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id D776A4B008F;
	Wed, 18 Apr 2012 07:18:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=OL665qb+n5+4HDluslD6mCo1sA2B1YsbnrzxGU+hLRUU
	vbnWaTCuHDL1s5Vl6ah91Sq/sMm8SaSSdOHCa3E2DsLGa5JxZkhBkVU51lNdnKgS
	mNeMFg2SZfanRg4ETtXRZhF4WPq3O94s9V9QUqVgVDHPbUoCyaHr3kqjG3HIZ5E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=AwGY27CEZ/o1aE0QC7i5IjB3rQ4=; b=EwvsL8As
	lAhMCP7OdZZLKe93wdZZM4MBS+fzA5x6ms0gvCnrKfEiHqg3jUGrocVyodHEfP2b
	XtXXnZGD4ZSmixef3uGYkJ+9eTyk7yihsd4CXoRI/7f7gGxQUuM7ZjxFamLmCLBD
	ZysnnAJgZs5sa4IoppruQzxjTWeT2E2XY7w=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 5044E4B009B; 
	Wed, 18 Apr 2012 07:18:49 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 07:18:49 -0700
Message-ID: <80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418135952.GG7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 07:18:49 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>>      if ( spage->sharing->handle != sh )
>>          goto err_unlock;
>>
>> -    /* Make sure the target page is a hole in the physmap */
>> +    /* Make sure the target page is a hole in the physmap. This is not
>> as
>> +     * simple a test as we'd like it to be. Non-existent p2m entries
>> return
>> +     * invalid mfn and p2m_mmio_dm type when queried. */
>>      if ( mfn_valid(cmfn) ||
>> -         (!(p2m_is_ram(cmfn_type))) )
>> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )
>
> This test looks wrong, even after the fix.  I think it should be testing
> for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
> mfn_valid().

Maybe :)

I'm coming up with the semantics for this one, loosely based on  the
regular populate physmap code path. That one can end up replacing existing
regular pages, or paged out entries, or PoD entries, with the new
populated pages (in guest_physmap_add_entry). I don't know that all of the
above is reasonable.

But certainly I would like to keep the ability to replace paged out
entries with (identical) pages that are already present in other domains.

Andres
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:19:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:19:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVil-0007nH-Hx; Wed, 18 Apr 2012 14:18:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKVij-0007nC-Vb
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:18:58 +0000
Received: from [85.158.143.99:10706] by server-2.bemta-4.messagelabs.com id
	21/E9-17550-15DCE8F4; Wed, 18 Apr 2012 14:18:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334758730!23637578!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODIzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24173 invoked from network); 18 Apr 2012 14:18:56 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 14:18:56 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id D776A4B008F;
	Wed, 18 Apr 2012 07:18:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=OL665qb+n5+4HDluslD6mCo1sA2B1YsbnrzxGU+hLRUU
	vbnWaTCuHDL1s5Vl6ah91Sq/sMm8SaSSdOHCa3E2DsLGa5JxZkhBkVU51lNdnKgS
	mNeMFg2SZfanRg4ETtXRZhF4WPq3O94s9V9QUqVgVDHPbUoCyaHr3kqjG3HIZ5E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=AwGY27CEZ/o1aE0QC7i5IjB3rQ4=; b=EwvsL8As
	lAhMCP7OdZZLKe93wdZZM4MBS+fzA5x6ms0gvCnrKfEiHqg3jUGrocVyodHEfP2b
	XtXXnZGD4ZSmixef3uGYkJ+9eTyk7yihsd4CXoRI/7f7gGxQUuM7ZjxFamLmCLBD
	ZysnnAJgZs5sa4IoppruQzxjTWeT2E2XY7w=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 5044E4B009B; 
	Wed, 18 Apr 2012 07:18:49 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 07:18:49 -0700
Message-ID: <80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418135952.GG7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 07:18:49 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>>      if ( spage->sharing->handle != sh )
>>          goto err_unlock;
>>
>> -    /* Make sure the target page is a hole in the physmap */
>> +    /* Make sure the target page is a hole in the physmap. This is not
>> as
>> +     * simple a test as we'd like it to be. Non-existent p2m entries
>> return
>> +     * invalid mfn and p2m_mmio_dm type when queried. */
>>      if ( mfn_valid(cmfn) ||
>> -         (!(p2m_is_ram(cmfn_type))) )
>> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )
>
> This test looks wrong, even after the fix.  I think it should be testing
> for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
> mfn_valid().

Maybe :)

I'm coming up with the semantics for this one, loosely based on  the
regular populate physmap code path. That one can end up replacing existing
regular pages, or paged out entries, or PoD entries, with the new
populated pages (in guest_physmap_add_entry). I don't know that all of the
above is reasonable.

But certainly I would like to keep the ability to replace paged out
entries with (identical) pages that are already present in other domains.

Andres
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVjm-0007pl-Vx; Wed, 18 Apr 2012 14:20:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKVjl-0007pe-19
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:20:01 +0000
Received: from [85.158.143.35:39669] by server-1.bemta-4.messagelabs.com id
	D8/AC-20925-09DCE8F4; Wed, 18 Apr 2012 14:20:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334758798!12623509!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjExMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32163 invoked from network); 18 Apr 2012 14:19:58 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-21.messagelabs.com with SMTP;
	18 Apr 2012 14:19:58 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 4A4BF1A8069;
	Wed, 18 Apr 2012 07:19:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DMH8DSllk7Gw0Fb/6ipPRqP0RkDcvqmKCw9NNZKs0uDz
	jusJoFbNSnkq87Pavk7381DlIK41fz1XLWPTB5zLbEUI0a/ZS+NsZMUbZ7NdX3b6
	m2iQy9skez/TsDwVP3jAhaBPI+KljkxlfD8Ot0kRa9jc4QF/1CErbVwgM1gI554=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=f/46KiNE1unLSc4f/gvazSHfKC0=; b=TOd5lCHV
	iEOhLKIjOXbl0iBKrMirjjntoN9xHbCVtkABNoFt+kVF9oeUAFh7WUL0WxCKZiUS
	iQQiBGgRtaaMI+mkTgITNvt4W46VkZvxHqB9i2VnRNJ6wg1wxxRA4EG/XlHp5C53
	ftrLRQPPDEhCRSojx9BfMn4C+0Rary5mWAY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 2C3D11A8063; 
	Wed, 18 Apr 2012 07:19:56 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 07:19:57 -0700
Message-ID: <f73ef505cf67b715cbf37b6f63a4db3e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418140550.GH7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
	<20120418140550.GH7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 07:19:57 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse
 map for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 10:16 -0400 on 12 Apr (1334225773), Andres Lagar-Cavilla wrote:
>>      /* Do the accounting first. If anything fails below, we have bigger
>>       * bigger fish to fry. First, remove the gfn from the list. */
>> -    last_gfn = list_has_one_entry(&page->sharing->gfns);
>> +    last_gfn = rmap_has_one_entry(page);
>>      if ( last_gfn )
>>      {
>> -        /* Clean up shared state */
>> -        audit_del_list(page);
>> +        /* Clean up shared state. Get rid of the <domid, gfn> tuple
>> +         * before destroying the rmap. */
>> +        mem_sharing_gfn_destroy(page, d, gfn_info);
>
> Moving this mem_sharing_gfn_destroy() around seems like it's unrelated
> to the rest of this patch, which is basically code motion.  If so, can
> you put it in a patch of its own?

Sure. I'll split it up but wait for feedback on 3.3 before re-submit.
Andres

>
> Otherwise, pending patch 3/3 being OK too,
>
> Acked-by: Tim Deegan <tim@xen.org>
>
>> +        page_sharing_dispose(page);
>>          page->sharing = NULL;
>>          atomic_dec(&nr_shared_mfns);
>>      }
>>      else
>>          atomic_dec(&nr_saved_mfns);
>> +
>>      /* If the GFN is getting destroyed drop the references to MFN
>>       * (possibly freeing the page), and exit early */
>>      if ( flags & MEM_SHARING_DESTROY_GFN )
>>      {
>> -        mem_sharing_gfn_destroy(d, gfn_info);
>> +        if ( !last_gfn )
>> +            mem_sharing_gfn_destroy(page, d, gfn_info);
>>          put_page_and_type(page);
>>          mem_sharing_page_unlock(page);
>>          if ( last_gfn &&
>> @@ -987,7 +1052,6 @@ gfn_found:
>>
>>      if ( last_gfn )
>>      {
>> -        mem_sharing_gfn_destroy(d, gfn_info);
>>          /* Making a page private atomically unlocks it */
>>          BUG_ON(page_make_private(d, page) != 0);
>>          goto private_page_found;
>> @@ -1011,7 +1075,7 @@ gfn_found:
>>      unmap_domain_page(t);
>>
>>      BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
>> -    mem_sharing_gfn_destroy(d, gfn_info);
>> +    mem_sharing_gfn_destroy(old_page, d, gfn_info);
>>      mem_sharing_page_unlock(old_page);
>>      put_page_and_type(old_page);
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKVjm-0007pl-Vx; Wed, 18 Apr 2012 14:20:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKVjl-0007pe-19
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:20:01 +0000
Received: from [85.158.143.35:39669] by server-1.bemta-4.messagelabs.com id
	D8/AC-20925-09DCE8F4; Wed, 18 Apr 2012 14:20:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334758798!12623509!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjExMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32163 invoked from network); 18 Apr 2012 14:19:58 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-21.messagelabs.com with SMTP;
	18 Apr 2012 14:19:58 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 4A4BF1A8069;
	Wed, 18 Apr 2012 07:19:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DMH8DSllk7Gw0Fb/6ipPRqP0RkDcvqmKCw9NNZKs0uDz
	jusJoFbNSnkq87Pavk7381DlIK41fz1XLWPTB5zLbEUI0a/ZS+NsZMUbZ7NdX3b6
	m2iQy9skez/TsDwVP3jAhaBPI+KljkxlfD8Ot0kRa9jc4QF/1CErbVwgM1gI554=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=f/46KiNE1unLSc4f/gvazSHfKC0=; b=TOd5lCHV
	iEOhLKIjOXbl0iBKrMirjjntoN9xHbCVtkABNoFt+kVF9oeUAFh7WUL0WxCKZiUS
	iQQiBGgRtaaMI+mkTgITNvt4W46VkZvxHqB9i2VnRNJ6wg1wxxRA4EG/XlHp5C53
	ftrLRQPPDEhCRSojx9BfMn4C+0Rary5mWAY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 2C3D11A8063; 
	Wed, 18 Apr 2012 07:19:56 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 07:19:57 -0700
Message-ID: <f73ef505cf67b715cbf37b6f63a4db3e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418140550.GH7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<1730bff8fccfb08cee3f.1334240173@xdev.gridcentric.ca>
	<20120418140550.GH7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 07:19:57 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse
 map for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 10:16 -0400 on 12 Apr (1334225773), Andres Lagar-Cavilla wrote:
>>      /* Do the accounting first. If anything fails below, we have bigger
>>       * bigger fish to fry. First, remove the gfn from the list. */
>> -    last_gfn = list_has_one_entry(&page->sharing->gfns);
>> +    last_gfn = rmap_has_one_entry(page);
>>      if ( last_gfn )
>>      {
>> -        /* Clean up shared state */
>> -        audit_del_list(page);
>> +        /* Clean up shared state. Get rid of the <domid, gfn> tuple
>> +         * before destroying the rmap. */
>> +        mem_sharing_gfn_destroy(page, d, gfn_info);
>
> Moving this mem_sharing_gfn_destroy() around seems like it's unrelated
> to the rest of this patch, which is basically code motion.  If so, can
> you put it in a patch of its own?

Sure. I'll split it up but wait for feedback on 3.3 before re-submit.
Andres

>
> Otherwise, pending patch 3/3 being OK too,
>
> Acked-by: Tim Deegan <tim@xen.org>
>
>> +        page_sharing_dispose(page);
>>          page->sharing = NULL;
>>          atomic_dec(&nr_shared_mfns);
>>      }
>>      else
>>          atomic_dec(&nr_saved_mfns);
>> +
>>      /* If the GFN is getting destroyed drop the references to MFN
>>       * (possibly freeing the page), and exit early */
>>      if ( flags & MEM_SHARING_DESTROY_GFN )
>>      {
>> -        mem_sharing_gfn_destroy(d, gfn_info);
>> +        if ( !last_gfn )
>> +            mem_sharing_gfn_destroy(page, d, gfn_info);
>>          put_page_and_type(page);
>>          mem_sharing_page_unlock(page);
>>          if ( last_gfn &&
>> @@ -987,7 +1052,6 @@ gfn_found:
>>
>>      if ( last_gfn )
>>      {
>> -        mem_sharing_gfn_destroy(d, gfn_info);
>>          /* Making a page private atomically unlocks it */
>>          BUG_ON(page_make_private(d, page) != 0);
>>          goto private_page_found;
>> @@ -1011,7 +1075,7 @@ gfn_found:
>>      unmap_domain_page(t);
>>
>>      BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
>> -    mem_sharing_gfn_destroy(d, gfn_info);
>> +    mem_sharing_gfn_destroy(old_page, d, gfn_info);
>>      mem_sharing_page_unlock(old_page);
>>      put_page_and_type(old_page);
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 14:38:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKW0v-0008MZ-BC; Wed, 18 Apr 2012 14:37:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKW0t-0008MT-OL
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:37:44 +0000
Received: from [85.158.143.99:15130] by server-3.bemta-4.messagelabs.com id
	F2/F6-05853-7B1DE8F4; Wed, 18 Apr 2012 14:37:43 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334759860!25647463!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAzOTQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28449 invoked from network); 18 Apr 2012 14:37:41 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 14:37:41 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKW0p-0004yX-Dl; Wed, 18 Apr 2012 15:37:39 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 18 Apr 2012
	15:36:45 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 18 Apr 2012 15:36:44 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0dcK3XItMFM9LkRCiEybmfYGt8UA==
Message-ID: <4F8ED17C.4090203@newcastle.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
In-Reply-To: <20120418120236.GB7013@ocelot.phlegethon.org>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============9169255631046611576=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9169255631046611576==
Content-Type: multipart/alternative;
	boundary="_000_4F8ED17C4090203newcastleacuk_"

--_000_4F8ED17C4090203newcastleacuk_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 04/18/2012 01:02 PM, Tim Deegan wrote:

Hi,

Can you please set up your mail client to indent quoted text?  It's not
clear which parts of your email are quoted and which are your replies.

Sorry about that.

At 13:53 +0100 on 11 Apr (1334152395), Francisco Rocha wrote:
> You can handle the second by using
> stub domains to run qemu in a different domain, or by only usoing PV
> domUs.
>
> If I use the stub domain provided with xen the dom0 will not perform the
> second mapping, right?

Yes; instead, the stub domain will perform it - so you'll need to allow
that to happen.  (Basically the stub domain's code lives inside the
guest's protection boundary, like its BIOS code &c).

> The third is pretty much a requirement if the domU's going to do
> any I/O via dom0, but at least with grant tables the ACL is under domU's
> control.  Or if you have an IOMMU you can give the domU direct access to
> its own network card and disk controller.
>
> I only have one ethernet card but i can get an ethernet expresscard.
>
> Can I do this in my the machine that gives me the output that follows?
>
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation enabled.
> (XEN) Intel VT-d Interrupt Remapping enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.

Yes; you should be able to do it on this machine without changing any
BIOS settings.

Tim.

Hi Tim,

I was thinking about changing my approach.

I think that for now I will leave those pages off because I am
mostly interested in protecting other areas.

Those accesses for now are inevitable to get the VM to properly
operate. Now, the question is if it is possible to use page table
entries to do what I want to do.

The objective would be to use a bit flag that would determine if
the pages are returned when a call to map_foreign_range is made.
So, my final objective would be that only pages used for the three
operations you describe are accessible to Dom0.
Everything that is not BIOS and related, Qemu or PV backend
drivers will not be returned.

>From what I see in the header files you use 12-bits from a 24-bit
flag (x86_64). Can we do it? This would again take us to controlling
access at get_page_from_l1e(), right?

Thank you,
Francisco

--_000_4F8ED17C4090203newcastleacuk_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
   =20
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    On 04/18/2012 01:02 PM, Tim Deegan wrote:
    <blockquote cite=3D"mid:20120418120236.GB7013@ocelot.phlegethon.org"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3DISO-8859-1">
      <meta name=3D"Generator" content=3D"MS Exchange Server version
        08.02.0254.000">
      <title>Re: [Xen-devel] reserve e820 ram</title>
      <!-- Converted from text/plain format -->
      <p><font size=3D"2">Hi,<br>
          <br>
          Can you please set up your mail client to indent quoted text?&nbs=
p;
          It's not<br>
          clear which parts of your email are quoted and which are your
          replies.<br>
        </font></p>
    </blockquote>
    Sorry about that.<br>
    <blockquote cite=3D"mid:20120418120236.GB7013@ocelot.phlegethon.org"
      type=3D"cite">
      <p><font size=3D"2">
          <br>
          At 13:53 +0100 on 11 Apr (1334152395), Francisco Rocha wrote:<br>
          &gt; You can handle the second by using<br>
          &gt; stub domains to run qemu in a different domain, or by
          only usoing PV<br>
          &gt; domUs.<br>
          &gt;<br>
          &gt; If I use the stub domain provided with xen the dom0 will
          not perform the<br>
          &gt; second mapping, right?<br>
          <br>
          Yes; instead, the stub domain will perform it - so you'll need
          to allow<br>
          that to happen.&nbsp; (Basically the stub domain's code lives
          inside the<br>
          guest's protection boundary, like its BIOS code &amp;c).<br>
          <br>
          &gt; The third is pretty much a requirement if the domU's
          going to do<br>
          &gt; any I/O via dom0, but at least with grant tables the ACL
          is under domU's<br>
          &gt; control.&nbsp; Or if you have an IOMMU you can give the domU
          direct access to<br>
          &gt; its own network card and disk controller.<br>
          &gt;<br>
          &gt; I only have one ethernet card but i can get an ethernet
          expresscard.<br>
          &gt;<br>
          &gt; Can I do this in my the machine that gives me the output
          that follows?<br>
          &gt;<br>
          &gt; (XEN) Intel VT-d Snoop Control not enabled.<br>
          &gt; (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.<br>
          &gt; (XEN) Intel VT-d Queued Invalidation enabled.<br>
          &gt; (XEN) Intel VT-d Interrupt Remapping enabled.<br>
          &gt; (XEN) Intel VT-d Shared EPT tables not enabled.<br>
          <br>
          Yes; you should be able to do it on this machine without
          changing any<br>
          BIOS settings.<br>
          <br>
          Tim.<br>
        </font>
      </p>
    </blockquote>
    Hi Tim,<br>
    <br>
    I was thinking about changing my approach.<br>
    <br>
    I think that for now I will leave those pages off because I am <br>
    mostly interested in protecting other areas.<br>
    <br>
    Those accesses for now are inevitable to get the VM to properly <br>
    operate. Now, the question is if it is possible to use page table <br>
    entries to do what I want to do.<br>
    <br>
    The objective would be to use a bit flag that would determine if <br>
    the pages are returned when a call to map_foreign_range is made.<br>
    So, my final objective would be that only pages used for the three <br>
    operations you describe are accessible to Dom0.<br>
    Everything that is not BIOS and related, Qemu or PV backend <br>
    drivers will not be returned.<br>
    <br>
    From what I see in the header files you use 12-bits from a 24-bit <br>
    flag (x86_64). Can we do it? This would again take us to controlling
    <br>
    access at get_page_from_l1e(), right?<br>
    <br>
    Thank you,<br>
    Francisco<br>
  </body>
</html>

--_000_4F8ED17C4090203newcastleacuk_--


--===============9169255631046611576==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9169255631046611576==--


From xen-devel-bounces@lists.xen.org Wed Apr 18 14:38:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 14:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKW0v-0008MZ-BC; Wed, 18 Apr 2012 14:37:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKW0t-0008MT-OL
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 14:37:44 +0000
Received: from [85.158.143.99:15130] by server-3.bemta-4.messagelabs.com id
	F2/F6-05853-7B1DE8F4; Wed, 18 Apr 2012 14:37:43 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334759860!25647463!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAzOTQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28449 invoked from network); 18 Apr 2012 14:37:41 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 14:37:41 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKW0p-0004yX-Dl; Wed, 18 Apr 2012 15:37:39 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 18 Apr 2012
	15:36:45 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 18 Apr 2012 15:36:44 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0dcK3XItMFM9LkRCiEybmfYGt8UA==
Message-ID: <4F8ED17C.4090203@newcastle.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
In-Reply-To: <20120418120236.GB7013@ocelot.phlegethon.org>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============9169255631046611576=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9169255631046611576==
Content-Type: multipart/alternative;
	boundary="_000_4F8ED17C4090203newcastleacuk_"

--_000_4F8ED17C4090203newcastleacuk_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 04/18/2012 01:02 PM, Tim Deegan wrote:

Hi,

Can you please set up your mail client to indent quoted text?  It's not
clear which parts of your email are quoted and which are your replies.

Sorry about that.

At 13:53 +0100 on 11 Apr (1334152395), Francisco Rocha wrote:
> You can handle the second by using
> stub domains to run qemu in a different domain, or by only usoing PV
> domUs.
>
> If I use the stub domain provided with xen the dom0 will not perform the
> second mapping, right?

Yes; instead, the stub domain will perform it - so you'll need to allow
that to happen.  (Basically the stub domain's code lives inside the
guest's protection boundary, like its BIOS code &c).

> The third is pretty much a requirement if the domU's going to do
> any I/O via dom0, but at least with grant tables the ACL is under domU's
> control.  Or if you have an IOMMU you can give the domU direct access to
> its own network card and disk controller.
>
> I only have one ethernet card but i can get an ethernet expresscard.
>
> Can I do this in my the machine that gives me the output that follows?
>
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation enabled.
> (XEN) Intel VT-d Interrupt Remapping enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.

Yes; you should be able to do it on this machine without changing any
BIOS settings.

Tim.

Hi Tim,

I was thinking about changing my approach.

I think that for now I will leave those pages off because I am
mostly interested in protecting other areas.

Those accesses for now are inevitable to get the VM to properly
operate. Now, the question is if it is possible to use page table
entries to do what I want to do.

The objective would be to use a bit flag that would determine if
the pages are returned when a call to map_foreign_range is made.
So, my final objective would be that only pages used for the three
operations you describe are accessible to Dom0.
Everything that is not BIOS and related, Qemu or PV backend
drivers will not be returned.

>From what I see in the header files you use 12-bits from a 24-bit
flag (x86_64). Can we do it? This would again take us to controlling
access at get_page_from_l1e(), right?

Thank you,
Francisco

--_000_4F8ED17C4090203newcastleacuk_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
   =20
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    On 04/18/2012 01:02 PM, Tim Deegan wrote:
    <blockquote cite=3D"mid:20120418120236.GB7013@ocelot.phlegethon.org"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3DISO-8859-1">
      <meta name=3D"Generator" content=3D"MS Exchange Server version
        08.02.0254.000">
      <title>Re: [Xen-devel] reserve e820 ram</title>
      <!-- Converted from text/plain format -->
      <p><font size=3D"2">Hi,<br>
          <br>
          Can you please set up your mail client to indent quoted text?&nbs=
p;
          It's not<br>
          clear which parts of your email are quoted and which are your
          replies.<br>
        </font></p>
    </blockquote>
    Sorry about that.<br>
    <blockquote cite=3D"mid:20120418120236.GB7013@ocelot.phlegethon.org"
      type=3D"cite">
      <p><font size=3D"2">
          <br>
          At 13:53 +0100 on 11 Apr (1334152395), Francisco Rocha wrote:<br>
          &gt; You can handle the second by using<br>
          &gt; stub domains to run qemu in a different domain, or by
          only usoing PV<br>
          &gt; domUs.<br>
          &gt;<br>
          &gt; If I use the stub domain provided with xen the dom0 will
          not perform the<br>
          &gt; second mapping, right?<br>
          <br>
          Yes; instead, the stub domain will perform it - so you'll need
          to allow<br>
          that to happen.&nbsp; (Basically the stub domain's code lives
          inside the<br>
          guest's protection boundary, like its BIOS code &amp;c).<br>
          <br>
          &gt; The third is pretty much a requirement if the domU's
          going to do<br>
          &gt; any I/O via dom0, but at least with grant tables the ACL
          is under domU's<br>
          &gt; control.&nbsp; Or if you have an IOMMU you can give the domU
          direct access to<br>
          &gt; its own network card and disk controller.<br>
          &gt;<br>
          &gt; I only have one ethernet card but i can get an ethernet
          expresscard.<br>
          &gt;<br>
          &gt; Can I do this in my the machine that gives me the output
          that follows?<br>
          &gt;<br>
          &gt; (XEN) Intel VT-d Snoop Control not enabled.<br>
          &gt; (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.<br>
          &gt; (XEN) Intel VT-d Queued Invalidation enabled.<br>
          &gt; (XEN) Intel VT-d Interrupt Remapping enabled.<br>
          &gt; (XEN) Intel VT-d Shared EPT tables not enabled.<br>
          <br>
          Yes; you should be able to do it on this machine without
          changing any<br>
          BIOS settings.<br>
          <br>
          Tim.<br>
        </font>
      </p>
    </blockquote>
    Hi Tim,<br>
    <br>
    I was thinking about changing my approach.<br>
    <br>
    I think that for now I will leave those pages off because I am <br>
    mostly interested in protecting other areas.<br>
    <br>
    Those accesses for now are inevitable to get the VM to properly <br>
    operate. Now, the question is if it is possible to use page table <br>
    entries to do what I want to do.<br>
    <br>
    The objective would be to use a bit flag that would determine if <br>
    the pages are returned when a call to map_foreign_range is made.<br>
    So, my final objective would be that only pages used for the three <br>
    operations you describe are accessible to Dom0.<br>
    Everything that is not BIOS and related, Qemu or PV backend <br>
    drivers will not be returned.<br>
    <br>
    From what I see in the header files you use 12-bits from a 24-bit <br>
    flag (x86_64). Can we do it? This would again take us to controlling
    <br>
    access at get_page_from_l1e(), right?<br>
    <br>
    Thank you,<br>
    Francisco<br>
  </body>
</html>

--_000_4F8ED17C4090203newcastleacuk_--


--===============9169255631046611576==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9169255631046611576==--


From xen-devel-bounces@lists.xen.org Wed Apr 18 15:02:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWOF-0000WI-DQ; Wed, 18 Apr 2012 15:01:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKWOE-0000WA-FH
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:01:50 +0000
Received: from [85.158.143.35:16301] by server-3.bemta-4.messagelabs.com id
	A3/31-05853-D57DE8F4; Wed, 18 Apr 2012 15:01:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334761309!5426124!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6207 invoked from network); 18 Apr 2012 15:01:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:01:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKWOB-0002Sk-9n; Wed, 18 Apr 2012 15:01:47 +0000
Date: Wed, 18 Apr 2012 16:01:47 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418150147.GI7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
	physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
> >>  1 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>
> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
> >> --- a/xen/arch/x86/mm/mem_sharing.c
> >> +++ b/xen/arch/x86/mm/mem_sharing.c
> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
> >>      if ( spage->sharing->handle != sh )
> >>          goto err_unlock;
> >>
> >> -    /* Make sure the target page is a hole in the physmap */
> >> +    /* Make sure the target page is a hole in the physmap. This is not
> >> as
> >> +     * simple a test as we'd like it to be. Non-existent p2m entries
> >> return
> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
> >>      if ( mfn_valid(cmfn) ||
> >> -         (!(p2m_is_ram(cmfn_type))) )
> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )
> >
> > This test looks wrong, even after the fix.  I think it should be testing
> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
> > mfn_valid().
> 
> Maybe :)
> 
> I'm coming up with the semantics for this one, loosely based on  the
> regular populate physmap code path. That one can end up replacing existing
> regular pages, or paged out entries, or PoD entries, with the new
> populated pages (in guest_physmap_add_entry). I don't know that all of the
> above is reasonable.
> 
> But certainly I would like to keep the ability to replace paged out
> entries with (identical) pages that are already present in other domains.

Fair enough.  Maybe you could define a new p2m-type-mask of all the
things you think it's OK to replace in this kind of situation, and apply
it in all cases?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:02:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWOF-0000WI-DQ; Wed, 18 Apr 2012 15:01:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKWOE-0000WA-FH
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:01:50 +0000
Received: from [85.158.143.35:16301] by server-3.bemta-4.messagelabs.com id
	A3/31-05853-D57DE8F4; Wed, 18 Apr 2012 15:01:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1334761309!5426124!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6207 invoked from network); 18 Apr 2012 15:01:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:01:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKWOB-0002Sk-9n; Wed, 18 Apr 2012 15:01:47 +0000
Date: Wed, 18 Apr 2012 16:01:47 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418150147.GI7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
	physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
> >>  1 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>
> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
> >> --- a/xen/arch/x86/mm/mem_sharing.c
> >> +++ b/xen/arch/x86/mm/mem_sharing.c
> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
> >>      if ( spage->sharing->handle != sh )
> >>          goto err_unlock;
> >>
> >> -    /* Make sure the target page is a hole in the physmap */
> >> +    /* Make sure the target page is a hole in the physmap. This is not
> >> as
> >> +     * simple a test as we'd like it to be. Non-existent p2m entries
> >> return
> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
> >>      if ( mfn_valid(cmfn) ||
> >> -         (!(p2m_is_ram(cmfn_type))) )
> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm) ) )
> >
> > This test looks wrong, even after the fix.  I think it should be testing
> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
> > mfn_valid().
> 
> Maybe :)
> 
> I'm coming up with the semantics for this one, loosely based on  the
> regular populate physmap code path. That one can end up replacing existing
> regular pages, or paged out entries, or PoD entries, with the new
> populated pages (in guest_physmap_add_entry). I don't know that all of the
> above is reasonable.
> 
> But certainly I would like to keep the ability to replace paged out
> entries with (identical) pages that are already present in other domains.

Fair enough.  Maybe you could define a new p2m-type-mask of all the
things you think it's OK to replace in this kind of situation, and apply
it in all cases?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:14:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:14:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWZc-0000wC-KY; Wed, 18 Apr 2012 15:13:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKWZa-0000w7-Rv
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:13:35 +0000
Received: from [85.158.143.99:10304] by server-1.bemta-4.messagelabs.com id
	2F/E4-20925-E1ADE8F4; Wed, 18 Apr 2012 15:13:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334762013!23674636!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMDEyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1192 invoked from network); 18 Apr 2012 15:13:33 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 15:13:33 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 7A5E260408D;
	Wed, 18 Apr 2012 08:13:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kw4wwMXcuYFzBeV96/1DbNAZVC+tIomRVaFl+aoc7CJ8
	RNspDwnj4PBDRphGLl6bnmvm83YEs7sCXa7S8JB99Vr2Xp19k2sFsDG+Kd5rTzkC
	d30dSsCKRSVDMF8oSHiBa35A+1ofa7BigCA5IROJVbEladhQre1BxON1/PpjKbM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=r2SEuUBTrEfLwayJ/A3bcuJB7ec=; b=Z4wEJTh3
	4bfzJlBlOJ3gh+4JXWWl2D01+uY7JkZbbra2j5C+oxJZCAhh68tISTwQ1FhuDWua
	4FsMKzLby2gZgnIi58/VnxkQUuYidaSozveDICovTGC5uAg8HH9M/jcdKy3VKo1L
	jgR5PjGgflUq/T7rJrDvcZvGxb1LRxOWdJs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 8002D604079; 
	Wed, 18 Apr 2012 08:13:30 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 08:13:32 -0700
Message-ID: <73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418150147.GI7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
	<20120418150147.GI7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 08:13:32 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
>> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>> >>  1 files changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >>
>> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
>> >> --- a/xen/arch/x86/mm/mem_sharing.c
>> >> +++ b/xen/arch/x86/mm/mem_sharing.c
>> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>> >>      if ( spage->sharing->handle != sh )
>> >>          goto err_unlock;
>> >>
>> >> -    /* Make sure the target page is a hole in the physmap */
>> >> +    /* Make sure the target page is a hole in the physmap. This is
>> not
>> >> as
>> >> +     * simple a test as we'd like it to be. Non-existent p2m entries
>> >> return
>> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
>> >>      if ( mfn_valid(cmfn) ||
>> >> -         (!(p2m_is_ram(cmfn_type))) )
>> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm)
>> ) )
>> >
>> > This test looks wrong, even after the fix.  I think it should be
>> testing
>> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
>> > mfn_valid().
>>
>> Maybe :)
>>
>> I'm coming up with the semantics for this one, loosely based on  the
>> regular populate physmap code path. That one can end up replacing
>> existing
>> regular pages, or paged out entries, or PoD entries, with the new
>> populated pages (in guest_physmap_add_entry). I don't know that all of
>> the
>> above is reasonable.
>>
>> But certainly I would like to keep the ability to replace paged out
>> entries with (identical) pages that are already present in other
>> domains.
>
> Fair enough.  Maybe you could define a new p2m-type-mask of all the
> things you think it's OK to replace in this kind of situation, and apply
> it in all cases?

Is there a chance for a p2m_mmio_dm entry to hold a valid mfn?
Thanks,
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:14:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:14:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWZc-0000wC-KY; Wed, 18 Apr 2012 15:13:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKWZa-0000w7-Rv
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:13:35 +0000
Received: from [85.158.143.99:10304] by server-1.bemta-4.messagelabs.com id
	2F/E4-20925-E1ADE8F4; Wed, 18 Apr 2012 15:13:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334762013!23674636!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMDEyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1192 invoked from network); 18 Apr 2012 15:13:33 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 15:13:33 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 7A5E260408D;
	Wed, 18 Apr 2012 08:13:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kw4wwMXcuYFzBeV96/1DbNAZVC+tIomRVaFl+aoc7CJ8
	RNspDwnj4PBDRphGLl6bnmvm83YEs7sCXa7S8JB99Vr2Xp19k2sFsDG+Kd5rTzkC
	d30dSsCKRSVDMF8oSHiBa35A+1ofa7BigCA5IROJVbEladhQre1BxON1/PpjKbM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=r2SEuUBTrEfLwayJ/A3bcuJB7ec=; b=Z4wEJTh3
	4bfzJlBlOJ3gh+4JXWWl2D01+uY7JkZbbra2j5C+oxJZCAhh68tISTwQ1FhuDWua
	4FsMKzLby2gZgnIi58/VnxkQUuYidaSozveDICovTGC5uAg8HH9M/jcdKy3VKo1L
	jgR5PjGgflUq/T7rJrDvcZvGxb1LRxOWdJs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 8002D604079; 
	Wed, 18 Apr 2012 08:13:30 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 08:13:32 -0700
Message-ID: <73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418150147.GI7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
	<20120418150147.GI7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 08:13:32 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
>> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>> >>  1 files changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >>
>> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
>> >> --- a/xen/arch/x86/mm/mem_sharing.c
>> >> +++ b/xen/arch/x86/mm/mem_sharing.c
>> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>> >>      if ( spage->sharing->handle != sh )
>> >>          goto err_unlock;
>> >>
>> >> -    /* Make sure the target page is a hole in the physmap */
>> >> +    /* Make sure the target page is a hole in the physmap. This is
>> not
>> >> as
>> >> +     * simple a test as we'd like it to be. Non-existent p2m entries
>> >> return
>> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
>> >>      if ( mfn_valid(cmfn) ||
>> >> -         (!(p2m_is_ram(cmfn_type))) )
>> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm)
>> ) )
>> >
>> > This test looks wrong, even after the fix.  I think it should be
>> testing
>> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
>> > mfn_valid().
>>
>> Maybe :)
>>
>> I'm coming up with the semantics for this one, loosely based on  the
>> regular populate physmap code path. That one can end up replacing
>> existing
>> regular pages, or paged out entries, or PoD entries, with the new
>> populated pages (in guest_physmap_add_entry). I don't know that all of
>> the
>> above is reasonable.
>>
>> But certainly I would like to keep the ability to replace paged out
>> entries with (identical) pages that are already present in other
>> domains.
>
> Fair enough.  Maybe you could define a new p2m-type-mask of all the
> things you think it's OK to replace in this kind of situation, and apply
> it in all cases?

Is there a chance for a p2m_mmio_dm entry to hold a valid mfn?
Thanks,
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWdB-00013K-8f; Wed, 18 Apr 2012 15:17:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKWd9-00013D-93
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:17:15 +0000
Received: from [85.158.143.99:61644] by server-2.bemta-4.messagelabs.com id
	CC/8A-17550-AFADE8F4; Wed, 18 Apr 2012 15:17:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334762233!13017501!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9563 invoked from network); 18 Apr 2012 15:17:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:17:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKWd5-0002Vt-97; Wed, 18 Apr 2012 15:17:11 +0000
Date: Wed, 18 Apr 2012 16:17:11 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418151711.GK7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
	<20120418150147.GI7013@ocelot.phlegethon.org>
	<73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
	physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:13 -0700 on 18 Apr (1334736812), Andres Lagar-Cavilla wrote:
> > At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
> >> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
> >> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
> >> >>  1 files changed, 4 insertions(+), 2 deletions(-)
> >> >>
> >> >>
> >> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> >>
> >> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
> >> >> --- a/xen/arch/x86/mm/mem_sharing.c
> >> >> +++ b/xen/arch/x86/mm/mem_sharing.c
> >> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
> >> >>      if ( spage->sharing->handle != sh )
> >> >>          goto err_unlock;
> >> >>
> >> >> -    /* Make sure the target page is a hole in the physmap */
> >> >> +    /* Make sure the target page is a hole in the physmap. This is
> >> not
> >> >> as
> >> >> +     * simple a test as we'd like it to be. Non-existent p2m entries
> >> >> return
> >> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
> >> >>      if ( mfn_valid(cmfn) ||
> >> >> -         (!(p2m_is_ram(cmfn_type))) )
> >> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm)
> >> ) )
> >> >
> >> > This test looks wrong, even after the fix.  I think it should be
> >> testing
> >> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
> >> > mfn_valid().
> >>
> >> Maybe :)
> >>
> >> I'm coming up with the semantics for this one, loosely based on  the
> >> regular populate physmap code path. That one can end up replacing
> >> existing
> >> regular pages, or paged out entries, or PoD entries, with the new
> >> populated pages (in guest_physmap_add_entry). I don't know that all of
> >> the
> >> above is reasonable.
> >>
> >> But certainly I would like to keep the ability to replace paged out
> >> entries with (identical) pages that are already present in other
> >> domains.
> >
> > Fair enough.  Maybe you could define a new p2m-type-mask of all the
> > things you think it's OK to replace in this kind of situation, and apply
> > it in all cases?
> 
> Is there a chance for a p2m_mmio_dm entry to hold a valid mfn?

At the moment the gfn is all that's needed to emulate the MFN but in
future we might encode, say, which of several servers to send the ioreq
to, and that might be a number that passes mfn_valid().  But it wouldn't
actually be an MFN, IYSWIM.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWdB-00013K-8f; Wed, 18 Apr 2012 15:17:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKWd9-00013D-93
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:17:15 +0000
Received: from [85.158.143.99:61644] by server-2.bemta-4.messagelabs.com id
	CC/8A-17550-AFADE8F4; Wed, 18 Apr 2012 15:17:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334762233!13017501!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9563 invoked from network); 18 Apr 2012 15:17:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:17:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKWd5-0002Vt-97; Wed, 18 Apr 2012 15:17:11 +0000
Date: Wed, 18 Apr 2012 16:17:11 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418151711.GK7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
	<20120418150147.GI7013@ocelot.phlegethon.org>
	<73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
	physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:13 -0700 on 18 Apr (1334736812), Andres Lagar-Cavilla wrote:
> > At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
> >> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
> >> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
> >> >>  1 files changed, 4 insertions(+), 2 deletions(-)
> >> >>
> >> >>
> >> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> >>
> >> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
> >> >> --- a/xen/arch/x86/mm/mem_sharing.c
> >> >> +++ b/xen/arch/x86/mm/mem_sharing.c
> >> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
> >> >>      if ( spage->sharing->handle != sh )
> >> >>          goto err_unlock;
> >> >>
> >> >> -    /* Make sure the target page is a hole in the physmap */
> >> >> +    /* Make sure the target page is a hole in the physmap. This is
> >> not
> >> >> as
> >> >> +     * simple a test as we'd like it to be. Non-existent p2m entries
> >> >> return
> >> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
> >> >>      if ( mfn_valid(cmfn) ||
> >> >> -         (!(p2m_is_ram(cmfn_type))) )
> >> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type != p2m_mmio_dm)
> >> ) )
> >> >
> >> > This test looks wrong, even after the fix.  I think it should be
> >> testing
> >> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and ignoring
> >> > mfn_valid().
> >>
> >> Maybe :)
> >>
> >> I'm coming up with the semantics for this one, loosely based on  the
> >> regular populate physmap code path. That one can end up replacing
> >> existing
> >> regular pages, or paged out entries, or PoD entries, with the new
> >> populated pages (in guest_physmap_add_entry). I don't know that all of
> >> the
> >> above is reasonable.
> >>
> >> But certainly I would like to keep the ability to replace paged out
> >> entries with (identical) pages that are already present in other
> >> domains.
> >
> > Fair enough.  Maybe you could define a new p2m-type-mask of all the
> > things you think it's OK to replace in this kind of situation, and apply
> > it in all cases?
> 
> Is there a chance for a p2m_mmio_dm entry to hold a valid mfn?

At the moment the gfn is all that's needed to emulate the MFN but in
future we might encode, say, which of several servers to send the ioreq
to, and that might be a number that passes mfn_valid().  But it wouldn't
actually be an MFN, IYSWIM.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWpo-0001O8-Bo; Wed, 18 Apr 2012 15:30:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKWpm-0001Nz-80
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:30:18 +0000
Received: from [85.158.138.51:35373] by server-7.bemta-3.messagelabs.com id
	9E/AD-03078-90EDE8F4; Wed, 18 Apr 2012 15:30:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334763016!22757550!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3470 invoked from network); 18 Apr 2012 15:30:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:30:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12007450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 15:30:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 16:30:16 +0100
Message-ID: <1334763014.23948.261.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 16:30:14 +0100
In-Reply-To: <498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTE4IGF0IDE0OjQ4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gT24gMTggQXByIDIwMTIsIGF0IDE0OjMxLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gCj4gPj4g
T2ssIEkgd2lsbCBhZGQgYW5kIGV4dHJhIHBhcmFtZXRlciB0byBsaWJ4bF9faW5pdGlhdGVfZGV2
aWNlX3JlbW92ZSAKPiA+PiB0aGF0Cj4gPj4gdHVybnMgb24gb3Igb2ZmIHRoZSBkZXN0cnVjdGlv
biBvZiB0aGUgZnJvbnQgeGVuc3RvcmUgZW50cmllcy4gV2UgCj4gPj4gd2lsbAo+ID4+IGZpcnN0
IGNhbGwgaXQgd2l0aG91dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlmIHRoYXQgZmFpbHMg
d2Ugd2lsbAo+ID4+IGNhbGwgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1vdmUgZnJvbSB0aGUg
Y2FsbGJhY2sgdGhpcyB0aW1lIAo+ID4+IGZvcmNpbmcKPiA+PiB0aGUgcmVtb3ZhbCBvZiB0aGUg
ZnJvbnRlbmQuCj4gPgo+ID4gSWYgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1vdmUgZmFpbHMg
dGhlbiB5b3Ugc2hvdWxkIGJlIGNhbGxpbmcKPiA+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfZGVz
dHJveSwgSSB0aGluaywgc28gbm8gbmVlZCBmb3IgYSBwYXJhbSB0bwo+ID4gX3JlbW92ZT8KPiAK
PiBOb3QgcmVhbGx54oCmIFRoYXQncyBob3cgSSB0aGluayB0aGUgcmVtb3ZhbCBwYXRoIHNob3Vs
ZCBiZToKPiAKPiAxLSBXYWl0IGZvciBiYWNrZW5kIHRvIHR1cm4gdG8gc3RhdGUgNiAtLS0tLT4g
aWYgb2sgdGhlbiBleGVjdXRlIAo+IGhvdHBsdWcsIGFuZCByZW1vdmUgZnJvbnQvYmFja2VuZAo+
IDItIElmIHRpbWVvdXQ6IG51a2UgZnJvbnRlbmQgYW5kIHdhaXQgZm9yIGJhY2tlbmQgc3RhdGUg
NiAtLS0tLT4gaWYgb2sgCj4gdGhlbiBleGVjdXRlIGhvdHBsdWcgYW5kIHJlbW92ZSBmcm9udC9i
YWNrCj4gMy0gSWYgdGltZW91dDogbnVrZSBmcm9udC9iYWNrZW5kCgpUaGF0IGNvdWxkIHdvcmss
IGJ1dCB3aGF0IGRvZXMgZG9pbmcgc3RlcCAyIGJ1eSB5b3U/IFdoeSBub3Qgc2tpcApzdHJhaWdo
dCB0byBzdGVwIDM/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWpo-0001O8-Bo; Wed, 18 Apr 2012 15:30:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKWpm-0001Nz-80
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:30:18 +0000
Received: from [85.158.138.51:35373] by server-7.bemta-3.messagelabs.com id
	9E/AD-03078-90EDE8F4; Wed, 18 Apr 2012 15:30:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334763016!22757550!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3470 invoked from network); 18 Apr 2012 15:30:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:30:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12007450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 15:30:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 16:30:16 +0100
Message-ID: <1334763014.23948.261.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 16:30:14 +0100
In-Reply-To: <498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTE4IGF0IDE0OjQ4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gT24gMTggQXByIDIwMTIsIGF0IDE0OjMxLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gCj4gPj4g
T2ssIEkgd2lsbCBhZGQgYW5kIGV4dHJhIHBhcmFtZXRlciB0byBsaWJ4bF9faW5pdGlhdGVfZGV2
aWNlX3JlbW92ZSAKPiA+PiB0aGF0Cj4gPj4gdHVybnMgb24gb3Igb2ZmIHRoZSBkZXN0cnVjdGlv
biBvZiB0aGUgZnJvbnQgeGVuc3RvcmUgZW50cmllcy4gV2UgCj4gPj4gd2lsbAo+ID4+IGZpcnN0
IGNhbGwgaXQgd2l0aG91dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlmIHRoYXQgZmFpbHMg
d2Ugd2lsbAo+ID4+IGNhbGwgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1vdmUgZnJvbSB0aGUg
Y2FsbGJhY2sgdGhpcyB0aW1lIAo+ID4+IGZvcmNpbmcKPiA+PiB0aGUgcmVtb3ZhbCBvZiB0aGUg
ZnJvbnRlbmQuCj4gPgo+ID4gSWYgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1vdmUgZmFpbHMg
dGhlbiB5b3Ugc2hvdWxkIGJlIGNhbGxpbmcKPiA+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfZGVz
dHJveSwgSSB0aGluaywgc28gbm8gbmVlZCBmb3IgYSBwYXJhbSB0bwo+ID4gX3JlbW92ZT8KPiAK
PiBOb3QgcmVhbGx54oCmIFRoYXQncyBob3cgSSB0aGluayB0aGUgcmVtb3ZhbCBwYXRoIHNob3Vs
ZCBiZToKPiAKPiAxLSBXYWl0IGZvciBiYWNrZW5kIHRvIHR1cm4gdG8gc3RhdGUgNiAtLS0tLT4g
aWYgb2sgdGhlbiBleGVjdXRlIAo+IGhvdHBsdWcsIGFuZCByZW1vdmUgZnJvbnQvYmFja2VuZAo+
IDItIElmIHRpbWVvdXQ6IG51a2UgZnJvbnRlbmQgYW5kIHdhaXQgZm9yIGJhY2tlbmQgc3RhdGUg
NiAtLS0tLT4gaWYgb2sgCj4gdGhlbiBleGVjdXRlIGhvdHBsdWcgYW5kIHJlbW92ZSBmcm9udC9i
YWNrCj4gMy0gSWYgdGltZW91dDogbnVrZSBmcm9udC9iYWNrZW5kCgpUaGF0IGNvdWxkIHdvcmss
IGJ1dCB3aGF0IGRvZXMgZG9pbmcgc3RlcCAyIGJ1eSB5b3U/IFdoeSBub3Qgc2tpcApzdHJhaWdo
dCB0byBzdGVwIDM/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:30:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWpt-0001Oa-OU; Wed, 18 Apr 2012 15:30:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKWps-0001OR-HL
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 15:30:24 +0000
Received: from [85.158.139.83:63024] by server-6.bemta-5.messagelabs.com id
	F0/DD-13222-F0EDE8F4; Wed, 18 Apr 2012 15:30:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334763023!17057678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7588 invoked from network); 18 Apr 2012 15:30:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:30:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12007452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 15:30:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 16:30:22 +0100
Date: Wed, 18 Apr 2012 16:35:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334739533.23948.152.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204181629570.26786@kaball-desktop>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42396.142064.874548@mariner.uk.xensource.com>
	<1334739533.23948.152.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 18 Apr 2012, Ian Campbell wrote:
> On Tue, 2012-04-17 at 18:17 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> > > qemu-xen offers better disk performances than qemu-xen-traditional
> > > because it supports Linux native AIO.
> > 
> > Does this take any account of whether the new qemu-xen dm is
> > installed ?
> 
> I don't think it is possible to install xen-unstable without
> qemu-upstream-xen getting built and installed? At least not building
> from source, perhaps a distro might package them separately but there
> really ought to be a depends relationship in that case?

I would think so.

> Would we want to
> support a Xen without qemu-upstream-xen configuration?

What if we check for the existence of the file in libxl?

If this is not acceptable I vote for assuming that qemu-xen is installed
in the system.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:30:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWpt-0001Oa-OU; Wed, 18 Apr 2012 15:30:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKWps-0001OR-HL
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 15:30:24 +0000
Received: from [85.158.139.83:63024] by server-6.bemta-5.messagelabs.com id
	F0/DD-13222-F0EDE8F4; Wed, 18 Apr 2012 15:30:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334763023!17057678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7588 invoked from network); 18 Apr 2012 15:30:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:30:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12007452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 15:30:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 16:30:22 +0100
Date: Wed, 18 Apr 2012 16:35:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334739533.23948.152.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204181629570.26786@kaball-desktop>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42396.142064.874548@mariner.uk.xensource.com>
	<1334739533.23948.152.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 18 Apr 2012, Ian Campbell wrote:
> On Tue, 2012-04-17 at 18:17 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> > > qemu-xen offers better disk performances than qemu-xen-traditional
> > > because it supports Linux native AIO.
> > 
> > Does this take any account of whether the new qemu-xen dm is
> > installed ?
> 
> I don't think it is possible to install xen-unstable without
> qemu-upstream-xen getting built and installed? At least not building
> from source, perhaps a distro might package them separately but there
> really ought to be a depends relationship in that case?

I would think so.

> Would we want to
> support a Xen without qemu-upstream-xen configuration?

What if we check for the existence of the file in libxl?

If this is not acceptable I vote for assuming that qemu-xen is installed
in the system.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:35:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWuC-0001j7-FH; Wed, 18 Apr 2012 15:34:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKWuA-0001iy-QD
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 15:34:51 +0000
Received: from [85.158.143.99:16270] by server-2.bemta-4.messagelabs.com id
	47/24-17550-A1FDE8F4; Wed, 18 Apr 2012 15:34:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334763289!13020229!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9736 invoked from network); 18 Apr 2012 15:34:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:34:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12007618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 15:34:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 16:34:49 +0100
Message-ID: <1334763287.23948.262.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 18 Apr 2012 16:34:47 +0100
In-Reply-To: <alpine.DEB.2.00.1204181629570.26786@kaball-desktop>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42396.142064.874548@mariner.uk.xensource.com>
	<1334739533.23948.152.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204181629570.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 16:35 +0100, Stefano Stabellini wrote:
> On Wed, 18 Apr 2012, Ian Campbell wrote:
> > On Tue, 2012-04-17 at 18:17 +0100, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> > > > qemu-xen offers better disk performances than qemu-xen-traditional
> > > > because it supports Linux native AIO.
> > > 
> > > Does this take any account of whether the new qemu-xen dm is
> > > installed ?
> > 
> > I don't think it is possible to install xen-unstable without
> > qemu-upstream-xen getting built and installed? At least not building
> > from source, perhaps a distro might package them separately but there
> > really ought to be a depends relationship in that case?
> 
> I would think so.
> 
> > Would we want to
> > support a Xen without qemu-upstream-xen configuration?
> 
> What if we check for the existence of the file in libxl?
> 
> If this is not acceptable I vote for assuming that qemu-xen is installed
> in the system.

I think an access(R_X) check or whatever + log and ERROR_INVAL would be
find.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:35:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWuC-0001j7-FH; Wed, 18 Apr 2012 15:34:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKWuA-0001iy-QD
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 15:34:51 +0000
Received: from [85.158.143.99:16270] by server-2.bemta-4.messagelabs.com id
	47/24-17550-A1FDE8F4; Wed, 18 Apr 2012 15:34:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334763289!13020229!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9736 invoked from network); 18 Apr 2012 15:34:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:34:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="12007618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 15:34:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 16:34:49 +0100
Message-ID: <1334763287.23948.262.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 18 Apr 2012 16:34:47 +0100
In-Reply-To: <alpine.DEB.2.00.1204181629570.26786@kaball-desktop>
References: <1332514347-28466-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42396.142064.874548@mariner.uk.xensource.com>
	<1334739533.23948.152.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204181629570.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 16:35 +0100, Stefano Stabellini wrote:
> On Wed, 18 Apr 2012, Ian Campbell wrote:
> > On Tue, 2012-04-17 at 18:17 +0100, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: use qemu-xen with PV guests by default"):
> > > > qemu-xen offers better disk performances than qemu-xen-traditional
> > > > because it supports Linux native AIO.
> > > 
> > > Does this take any account of whether the new qemu-xen dm is
> > > installed ?
> > 
> > I don't think it is possible to install xen-unstable without
> > qemu-upstream-xen getting built and installed? At least not building
> > from source, perhaps a distro might package them separately but there
> > really ought to be a depends relationship in that case?
> 
> I would think so.
> 
> > Would we want to
> > support a Xen without qemu-upstream-xen configuration?
> 
> What if we check for the existence of the file in libxl?
> 
> If this is not acceptable I vote for assuming that qemu-xen is installed
> in the system.

I think an access(R_X) check or whatever + log and ERROR_INVAL would be
find.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:35:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWur-0001m8-EX; Wed, 18 Apr 2012 15:35:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKWuq-0001lv-Ci
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:35:32 +0000
Received: from [193.109.254.147:12548] by server-1.bemta-14.messagelabs.com id
	21/1A-29372-34FDE8F4; Wed, 18 Apr 2012 15:35:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334763330!5231279!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5945 invoked from network); 18 Apr 2012 15:35:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:35:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKWuo-0002aY-5I; Wed, 18 Apr 2012 15:35:30 +0000
Date: Wed, 18 Apr 2012 16:35:30 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418153530.GM7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages
	with many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:16 -0400 on 12 Apr (1334225774), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
>  xen/include/asm-x86/mem_sharing.h |   13 ++-
>  2 files changed, 169 insertions(+), 14 deletions(-)
> 
> 
> For shared frames that have many references, the doubly-linked list used to
> store the rmap results in costly scans during unshare operations. To alleviate
> the overhead, replace the linked list by a hash table. However, hash tables are
> space-intensive, so only use them for pages that have "many" (arbitrary
> threshold) references.
> 
> Unsharing is heaviliy exercised during domain destroy. In experimental testing,
> for a domain that points over 100 thousand pages to the same shared frame,
> domain destruction dropped from over 7 minutes(!) to less than two seconds.

If you're adding a new datastructure, would it be better to use a tree,
since the keys are easily sorted?  Xen already has include/xen/rbtree.h.
It would have a higher per-entry overhead but you wouldn't need to keep
the list datastructure as well for the light-sharing case.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:35:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWur-0001m8-EX; Wed, 18 Apr 2012 15:35:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKWuq-0001lv-Ci
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:35:32 +0000
Received: from [193.109.254.147:12548] by server-1.bemta-14.messagelabs.com id
	21/1A-29372-34FDE8F4; Wed, 18 Apr 2012 15:35:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334763330!5231279!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5945 invoked from network); 18 Apr 2012 15:35:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:35:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKWuo-0002aY-5I; Wed, 18 Apr 2012 15:35:30 +0000
Date: Wed, 18 Apr 2012 16:35:30 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418153530.GM7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages
	with many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:16 -0400 on 12 Apr (1334225774), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
>  xen/include/asm-x86/mem_sharing.h |   13 ++-
>  2 files changed, 169 insertions(+), 14 deletions(-)
> 
> 
> For shared frames that have many references, the doubly-linked list used to
> store the rmap results in costly scans during unshare operations. To alleviate
> the overhead, replace the linked list by a hash table. However, hash tables are
> space-intensive, so only use them for pages that have "many" (arbitrary
> threshold) references.
> 
> Unsharing is heaviliy exercised during domain destroy. In experimental testing,
> for a domain that points over 100 thousand pages to the same shared frame,
> domain destruction dropped from over 7 minutes(!) to less than two seconds.

If you're adding a new datastructure, would it be better to use a tree,
since the keys are easily sorted?  Xen already has include/xen/rbtree.h.
It would have a higher per-entry overhead but you wouldn't need to keep
the list datastructure as well for the light-sharing case.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWzm-0002N2-RG; Wed, 18 Apr 2012 15:40:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKWzm-0002Ms-6s
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:40:38 +0000
Received: from [193.109.254.147:52695] by server-7.bemta-14.messagelabs.com id
	3E/87-01627-570EE8F4; Wed, 18 Apr 2012 15:40:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334763633!5220015!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18973 invoked from network); 18 Apr 2012 15:40:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190951464"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 11:40:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 11:40:32 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKWzf-0002uL-LR;
	Wed, 18 Apr 2012 16:40:31 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 16:40:31 +0100
Message-ID: <52453437-855A-4024-B30D-7D5819E9927F@citrix.com>
In-Reply-To: <1334763014.23948.261.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
	<1334763014.23948.261.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTggQXByIDIwMTIsIGF0IDE2OjMwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cgo+IE9uIFdlZCwg
MjAxMi0wNC0xOCBhdCAxNDo0OCArMDEwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBPbiAx
OCBBcHIgMjAxMiwgYXQgMTQ6MzEsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4KPj4+PiBPaywgSSB3
aWxsIGFkZCBhbmQgZXh0cmEgcGFyYW1ldGVyIHRvIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVt
b3ZlCj4+Pj4gdGhhdAo+Pj4+IHR1cm5zIG9uIG9yIG9mZiB0aGUgZGVzdHJ1Y3Rpb24gb2YgdGhl
IGZyb250IHhlbnN0b3JlIGVudHJpZXMuIFdlCj4+Pj4gd2lsbAo+Pj4+IGZpcnN0IGNhbGwgaXQg
d2l0aG91dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlmIHRoYXQgZmFpbHMgd2UgCj4+Pj4g
d2lsbAo+Pj4+IGNhbGwgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1vdmUgZnJvbSB0aGUgY2Fs
bGJhY2sgdGhpcyB0aW1lCj4+Pj4gZm9yY2luZwo+Pj4+IHRoZSByZW1vdmFsIG9mIHRoZSBmcm9u
dGVuZC4KPj4+Cj4+PiBJZiBsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSBmYWlscyB0aGVu
IHlvdSBzaG91bGQgYmUgY2FsbGluZwo+Pj4gbGlieGxfX2luaXRpYXRlX2RldmljZV9kZXN0cm95
LCBJIHRoaW5rLCBzbyBubyBuZWVkIGZvciBhIHBhcmFtIHRvCj4+PiBfcmVtb3ZlPwo+Pgo+PiBO
b3QgcmVhbGx54oCmIFRoYXQncyBob3cgSSB0aGluayB0aGUgcmVtb3ZhbCBwYXRoIHNob3VsZCBi
ZToKPj4KPj4gMS0gV2FpdCBmb3IgYmFja2VuZCB0byB0dXJuIHRvIHN0YXRlIDYgLS0tLS0+IGlm
IG9rIHRoZW4gZXhlY3V0ZQo+PiBob3RwbHVnLCBhbmQgcmVtb3ZlIGZyb250L2JhY2tlbmQKPj4g
Mi0gSWYgdGltZW91dDogbnVrZSBmcm9udGVuZCBhbmQgd2FpdCBmb3IgYmFja2VuZCBzdGF0ZSA2
IC0tLS0tPiBpZiAKPj4gb2sKPj4gdGhlbiBleGVjdXRlIGhvdHBsdWcgYW5kIHJlbW92ZSBmcm9u
dC9iYWNrCj4+IDMtIElmIHRpbWVvdXQ6IG51a2UgZnJvbnQvYmFja2VuZAo+Cj4gVGhhdCBjb3Vs
ZCB3b3JrLCBidXQgd2hhdCBkb2VzIGRvaW5nIHN0ZXAgMiBidXkgeW91PyBXaHkgbm90IHNraXAK
PiBzdHJhaWdodCB0byBzdGVwIDM/Cgpob3RwbHVnIHNjcmlwdHMgdXN1YWxseSByZXF1aXJlIHRo
ZSBkZXZpY2UgdG8gYmUgb24gc3RhdGUgNiBmb3IgdGhlbSB0byAKd29yaywgbnVraW5nIHRoZSBm
cm9udGVuZCBmb3JjZXMgdGhlIGJhY2tlbmQgZGlzY29ubmVjdGlvbiwgYW5kIGdldHMgdXMgCmEg
c3RhdGUgNi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKWzm-0002N2-RG; Wed, 18 Apr 2012 15:40:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKWzm-0002Ms-6s
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:40:38 +0000
Received: from [193.109.254.147:52695] by server-7.bemta-14.messagelabs.com id
	3E/87-01627-570EE8F4; Wed, 18 Apr 2012 15:40:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334763633!5220015!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18973 invoked from network); 18 Apr 2012 15:40:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 15:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190951464"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 11:40:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 11:40:32 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKWzf-0002uL-LR;
	Wed, 18 Apr 2012 16:40:31 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 16:40:31 +0100
Message-ID: <52453437-855A-4024-B30D-7D5819E9927F@citrix.com>
In-Reply-To: <1334763014.23948.261.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
	<1334763014.23948.261.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTggQXByIDIwMTIsIGF0IDE2OjMwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cgo+IE9uIFdlZCwg
MjAxMi0wNC0xOCBhdCAxNDo0OCArMDEwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBPbiAx
OCBBcHIgMjAxMiwgYXQgMTQ6MzEsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4KPj4+PiBPaywgSSB3
aWxsIGFkZCBhbmQgZXh0cmEgcGFyYW1ldGVyIHRvIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVt
b3ZlCj4+Pj4gdGhhdAo+Pj4+IHR1cm5zIG9uIG9yIG9mZiB0aGUgZGVzdHJ1Y3Rpb24gb2YgdGhl
IGZyb250IHhlbnN0b3JlIGVudHJpZXMuIFdlCj4+Pj4gd2lsbAo+Pj4+IGZpcnN0IGNhbGwgaXQg
d2l0aG91dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlmIHRoYXQgZmFpbHMgd2UgCj4+Pj4g
d2lsbAo+Pj4+IGNhbGwgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1vdmUgZnJvbSB0aGUgY2Fs
bGJhY2sgdGhpcyB0aW1lCj4+Pj4gZm9yY2luZwo+Pj4+IHRoZSByZW1vdmFsIG9mIHRoZSBmcm9u
dGVuZC4KPj4+Cj4+PiBJZiBsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSBmYWlscyB0aGVu
IHlvdSBzaG91bGQgYmUgY2FsbGluZwo+Pj4gbGlieGxfX2luaXRpYXRlX2RldmljZV9kZXN0cm95
LCBJIHRoaW5rLCBzbyBubyBuZWVkIGZvciBhIHBhcmFtIHRvCj4+PiBfcmVtb3ZlPwo+Pgo+PiBO
b3QgcmVhbGx54oCmIFRoYXQncyBob3cgSSB0aGluayB0aGUgcmVtb3ZhbCBwYXRoIHNob3VsZCBi
ZToKPj4KPj4gMS0gV2FpdCBmb3IgYmFja2VuZCB0byB0dXJuIHRvIHN0YXRlIDYgLS0tLS0+IGlm
IG9rIHRoZW4gZXhlY3V0ZQo+PiBob3RwbHVnLCBhbmQgcmVtb3ZlIGZyb250L2JhY2tlbmQKPj4g
Mi0gSWYgdGltZW91dDogbnVrZSBmcm9udGVuZCBhbmQgd2FpdCBmb3IgYmFja2VuZCBzdGF0ZSA2
IC0tLS0tPiBpZiAKPj4gb2sKPj4gdGhlbiBleGVjdXRlIGhvdHBsdWcgYW5kIHJlbW92ZSBmcm9u
dC9iYWNrCj4+IDMtIElmIHRpbWVvdXQ6IG51a2UgZnJvbnQvYmFja2VuZAo+Cj4gVGhhdCBjb3Vs
ZCB3b3JrLCBidXQgd2hhdCBkb2VzIGRvaW5nIHN0ZXAgMiBidXkgeW91PyBXaHkgbm90IHNraXAK
PiBzdHJhaWdodCB0byBzdGVwIDM/Cgpob3RwbHVnIHNjcmlwdHMgdXN1YWxseSByZXF1aXJlIHRo
ZSBkZXZpY2UgdG8gYmUgb24gc3RhdGUgNiBmb3IgdGhlbSB0byAKd29yaywgbnVraW5nIHRoZSBm
cm9udGVuZCBmb3JjZXMgdGhlIGJhY2tlbmQgZGlzY29ubmVjdGlvbiwgYW5kIGdldHMgdXMgCmEg
c3RhdGUgNi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:53:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXBk-0002yX-Tr; Wed, 18 Apr 2012 15:53:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXBi-0002yS-Me
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:52:58 +0000
Received: from [85.158.139.83:41755] by server-9.bemta-5.messagelabs.com id
	D3/A6-09826-953EE8F4; Wed, 18 Apr 2012 15:52:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334764376!20139189!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19694 invoked from network); 18 Apr 2012 15:52:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:52:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXBf-0002eN-4M; Wed, 18 Apr 2012 15:52:55 +0000
Date: Wed, 18 Apr 2012 16:52:55 +0100
From: Tim Deegan <tim@xen.org>
To: Gianluca Guida <glguida@gmail.com>
Message-ID: <20120418155255.GN7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
	<CAKpvNa1Hp_R5enyzjQuNxDf_WF0qH96hOaXx2RGpuJG+t=AhPQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKpvNa1Hp_R5enyzjQuNxDf_WF0qH96hOaXx2RGpuJG+t=AhPQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86/mm/shadow: enclose an OOS
	function in the proper conditional ifdef
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:08 -0700 on 14 Apr (1334387280), Gianluca Guida wrote:
> On Fri, Apr 13, 2012 at 9:22 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
> > =A0xen/arch/x86/mm/shadow/multi.c | =A03 ++-
> > =A01 files changed, 2 insertions(+), 1 deletions(-)
> >
> >
> > Otherwise compilation fails if the feature is disabled.
> =

> Oh yes, my fault. This has been around for quite a few years in my
> disks with the promise to "Send It Next Time" (TM). Thanks for fixing
> this.
> =

> Acked-By: Gianluca Guida <gianluca.guida@citrix.com>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:53:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXBk-0002yX-Tr; Wed, 18 Apr 2012 15:53:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXBi-0002yS-Me
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:52:58 +0000
Received: from [85.158.139.83:41755] by server-9.bemta-5.messagelabs.com id
	D3/A6-09826-953EE8F4; Wed, 18 Apr 2012 15:52:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1334764376!20139189!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19694 invoked from network); 18 Apr 2012 15:52:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:52:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXBf-0002eN-4M; Wed, 18 Apr 2012 15:52:55 +0000
Date: Wed, 18 Apr 2012 16:52:55 +0100
From: Tim Deegan <tim@xen.org>
To: Gianluca Guida <glguida@gmail.com>
Message-ID: <20120418155255.GN7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<f8fd4a4239a8aa7e25e5.1334334140@xdev.gridcentric.ca>
	<CAKpvNa1Hp_R5enyzjQuNxDf_WF0qH96hOaXx2RGpuJG+t=AhPQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKpvNa1Hp_R5enyzjQuNxDf_WF0qH96hOaXx2RGpuJG+t=AhPQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 6] x86/mm/shadow: enclose an OOS
	function in the proper conditional ifdef
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:08 -0700 on 14 Apr (1334387280), Gianluca Guida wrote:
> On Fri, Apr 13, 2012 at 9:22 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
> > =A0xen/arch/x86/mm/shadow/multi.c | =A03 ++-
> > =A01 files changed, 2 insertions(+), 1 deletions(-)
> >
> >
> > Otherwise compilation fails if the feature is disabled.
> =

> Oh yes, my fault. This has been around for quite a few years in my
> disks with the promise to "Send It Next Time" (TM). Thanks for fixing
> this.
> =

> Acked-By: Gianluca Guida <gianluca.guida@citrix.com>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXDt-00035h-Gh; Wed, 18 Apr 2012 15:55:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXDr-00035T-Qf
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:55:12 +0000
Received: from [85.158.143.35:15376] by server-1.bemta-4.messagelabs.com id
	B4/6E-20925-FD3EE8F4; Wed, 18 Apr 2012 15:55:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334764509!16720465!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTkzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16161 invoked from network); 18 Apr 2012 15:55:10 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-21.messagelabs.com with SMTP;
	18 Apr 2012 15:55:10 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 615E21A808D;
	Wed, 18 Apr 2012 08:55:09 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=j2dbEm8tzykeBLhAZf/veS6aZ8Q1+Dw9bcfe2ADr1bBh
	Z9Y6wkmYFEUJAVoq/kHSBETW6yb63Dn8Hfi7yRoMCaBmwGwH+/qO9jCFeiMCF/3C
	CZfH3cQiu5mo4IwOQqX649xlcvNy1md3QCrEzLdIRCzm0ZlnC3vzK5dSq3CiDS8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=oYXWl53uCGB6621ZzH9NQDEnTMg=; b=FEEX4xWG
	i/JrhMhz9aFCmjvL93C0w7EHRUva5atxACUgqBADCxQvWfwqgyQqXvl3ALRQFbMq
	2OVEHPMgG6yYtKqvtrtNCFjXs5zXbe3kf7llKaaTT25EoQloq2pmor1IzaHY/Zjf
	SbldzgknNRJ2nkKPw+yw9HIFDo8Uewpyz1c=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id EE79C1A8061; 
	Wed, 18 Apr 2012 08:55:08 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 08:55:09 -0700
Message-ID: <0b5fb4fa8e16c8156084c1f4c835a6de.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418151711.GK7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
	<20120418150147.GI7013@ocelot.phlegethon.org>
	<73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
	<20120418151711.GK7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 08:55:09 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 08:13 -0700 on 18 Apr (1334736812), Andres Lagar-Cavilla wrote:
>> > At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
>> >> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>> >> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>> >> >>  1 files changed, 4 insertions(+), 2 deletions(-)
>> >> >>
>> >> >>
>> >> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >> >>
>> >> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
>> >> >> --- a/xen/arch/x86/mm/mem_sharing.c
>> >> >> +++ b/xen/arch/x86/mm/mem_sharing.c
>> >> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>> >> >>      if ( spage->sharing->handle != sh )
>> >> >>          goto err_unlock;
>> >> >>
>> >> >> -    /* Make sure the target page is a hole in the physmap */
>> >> >> +    /* Make sure the target page is a hole in the physmap. This
>> is
>> >> not
>> >> >> as
>> >> >> +     * simple a test as we'd like it to be. Non-existent p2m
>> entries
>> >> >> return
>> >> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
>> >> >>      if ( mfn_valid(cmfn) ||
>> >> >> -         (!(p2m_is_ram(cmfn_type))) )
>> >> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type !=
>> p2m_mmio_dm)
>> >> ) )
>> >> >
>> >> > This test looks wrong, even after the fix.  I think it should be
>> >> testing
>> >> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and
>> ignoring
>> >> > mfn_valid().
>> >>
>> >> Maybe :)
>> >>
>> >> I'm coming up with the semantics for this one, loosely based on  the
>> >> regular populate physmap code path. That one can end up replacing
>> >> existing
>> >> regular pages, or paged out entries, or PoD entries, with the new
>> >> populated pages (in guest_physmap_add_entry). I don't know that all
>> of
>> >> the
>> >> above is reasonable.
>> >>
>> >> But certainly I would like to keep the ability to replace paged out
>> >> entries with (identical) pages that are already present in other
>> >> domains.
>> >
>> > Fair enough.  Maybe you could define a new p2m-type-mask of all the
>> > things you think it's OK to replace in this kind of situation, and
>> apply
>> > it in all cases?
>>
>> Is there a chance for a p2m_mmio_dm entry to hold a valid mfn?
>
> At the moment the gfn is all that's needed to emulate the MFN but in
> future we might encode, say, which of several servers to send the ioreq
> to, and that might be a number that passes mfn_valid().  But it wouldn't
> actually be an MFN, IYSWIM.

Ok great. This is what I have now. But I haven't been able to test it, so
RFC for the moment.
Andres

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.org>
# Date 1334762521 14400
# Node ID d91665827cbc9e4c7e649a664b93966e8bb00f09
# Parent  9c241969ea6db6590de1f7079309d7cd7b4d6435
x86/mem_sharing: Rectify test for "empty" physmap entry in
sharing_add_to_physmap.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9c241969ea6d -r d91665827cbc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
     if ( spage->sharing->handle != sh )
         goto err_unlock;

-    /* Make sure the target page is a hole in the physmap */
-    if ( mfn_valid(cmfn) ||
-         (!(p2m_is_ram(cmfn_type))) )
+    /* Make sure the target page is a hole in the physmap. This is not as
+     * simple a test as we'd like it to be. Non-existent p2m entries return
+     * invalid mfn and p2m_mmio_dm type when queried. */
+    if ( !p2m_is_hole(cmfn_type) )
     {
         ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
diff -r 9c241969ea6d -r d91665827cbc xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -133,6 +133,12 @@ typedef unsigned int p2m_query_t;
                        | p2m_to_mask(p2m_ram_paging_in)       \
                        | p2m_to_mask(p2m_ram_shared))

+/* Types that represent a physmap hole that is ok to replace with a shared
+ * entry */
+#define P2M_HOLE_TYPES (p2m_to_mask(p2m_mmio_dm)     \
+                       | p2m_to_mask(p2m_invalid)   \
+                       | p2m_to_mask(p2m_ram_paged))
+
 /* Grant mapping types, which map to a real machine frame in another
  * VM */
 #define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw)  \
@@ -173,6 +179,7 @@ typedef unsigned int p2m_query_t;

 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
+#define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
 #define p2m_is_magic(_t) (p2m_to_mask(_t) & P2M_MAGIC_TYPES)


>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXDt-00035h-Gh; Wed, 18 Apr 2012 15:55:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXDr-00035T-Qf
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:55:12 +0000
Received: from [85.158.143.35:15376] by server-1.bemta-4.messagelabs.com id
	B4/6E-20925-FD3EE8F4; Wed, 18 Apr 2012 15:55:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334764509!16720465!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTkzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16161 invoked from network); 18 Apr 2012 15:55:10 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-21.messagelabs.com with SMTP;
	18 Apr 2012 15:55:10 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 615E21A808D;
	Wed, 18 Apr 2012 08:55:09 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=j2dbEm8tzykeBLhAZf/veS6aZ8Q1+Dw9bcfe2ADr1bBh
	Z9Y6wkmYFEUJAVoq/kHSBETW6yb63Dn8Hfi7yRoMCaBmwGwH+/qO9jCFeiMCF/3C
	CZfH3cQiu5mo4IwOQqX649xlcvNy1md3QCrEzLdIRCzm0ZlnC3vzK5dSq3CiDS8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=oYXWl53uCGB6621ZzH9NQDEnTMg=; b=FEEX4xWG
	i/JrhMhz9aFCmjvL93C0w7EHRUva5atxACUgqBADCxQvWfwqgyQqXvl3ALRQFbMq
	2OVEHPMgG6yYtKqvtrtNCFjXs5zXbe3kf7llKaaTT25EoQloq2pmor1IzaHY/Zjf
	SbldzgknNRJ2nkKPw+yw9HIFDo8Uewpyz1c=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id EE79C1A8061; 
	Wed, 18 Apr 2012 08:55:08 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 08:55:09 -0700
Message-ID: <0b5fb4fa8e16c8156084c1f4c835a6de.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418151711.GK7013@ocelot.phlegethon.org>
References: <495d3df95c1d59f55d5a.1334754400@xdev.gridcentric.ca>
	<20120418135952.GG7013@ocelot.phlegethon.org>
	<80232f2ec1589fa3d0be7f6a575eb7f1.squirrel@webmail.lagarcavilla.org>
	<20120418150147.GI7013@ocelot.phlegethon.org>
	<73a9d24a68ebfc8358cb55c6b4864831.squirrel@webmail.lagarcavilla.org>
	<20120418151711.GK7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 08:55:09 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mem_sharing: Rectify test for "empty"
 physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 08:13 -0700 on 18 Apr (1334736812), Andres Lagar-Cavilla wrote:
>> > At 07:18 -0700 on 18 Apr (1334733529), Andres Lagar-Cavilla wrote:
>> >> > At 09:06 -0400 on 18 Apr (1334740000), Andres Lagar-Cavilla wrote:
>> >> >>  xen/arch/x86/mm/mem_sharing.c |  6 ++++--
>> >> >>  1 files changed, 4 insertions(+), 2 deletions(-)
>> >> >>
>> >> >>
>> >> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >> >>
>> >> >> diff -r 8609bbbba141 -r 495d3df95c1d xen/arch/x86/mm/mem_sharing.c
>> >> >> --- a/xen/arch/x86/mm/mem_sharing.c
>> >> >> +++ b/xen/arch/x86/mm/mem_sharing.c
>> >> >> @@ -1073,9 +1073,11 @@ int mem_sharing_add_to_physmap(struct do
>> >> >>      if ( spage->sharing->handle != sh )
>> >> >>          goto err_unlock;
>> >> >>
>> >> >> -    /* Make sure the target page is a hole in the physmap */
>> >> >> +    /* Make sure the target page is a hole in the physmap. This
>> is
>> >> not
>> >> >> as
>> >> >> +     * simple a test as we'd like it to be. Non-existent p2m
>> entries
>> >> >> return
>> >> >> +     * invalid mfn and p2m_mmio_dm type when queried. */
>> >> >>      if ( mfn_valid(cmfn) ||
>> >> >> -         (!(p2m_is_ram(cmfn_type))) )
>> >> >> +         ( (!(p2m_is_ram(cmfn_type))) && (cmfn_type !=
>> p2m_mmio_dm)
>> >> ) )
>> >> >
>> >> > This test looks wrong, even after the fix.  I think it should be
>> >> testing
>> >> > for cmfn_type == p2m_mmio_dm || cmfn_type == p2m_invalid and
>> ignoring
>> >> > mfn_valid().
>> >>
>> >> Maybe :)
>> >>
>> >> I'm coming up with the semantics for this one, loosely based on  the
>> >> regular populate physmap code path. That one can end up replacing
>> >> existing
>> >> regular pages, or paged out entries, or PoD entries, with the new
>> >> populated pages (in guest_physmap_add_entry). I don't know that all
>> of
>> >> the
>> >> above is reasonable.
>> >>
>> >> But certainly I would like to keep the ability to replace paged out
>> >> entries with (identical) pages that are already present in other
>> >> domains.
>> >
>> > Fair enough.  Maybe you could define a new p2m-type-mask of all the
>> > things you think it's OK to replace in this kind of situation, and
>> apply
>> > it in all cases?
>>
>> Is there a chance for a p2m_mmio_dm entry to hold a valid mfn?
>
> At the moment the gfn is all that's needed to emulate the MFN but in
> future we might encode, say, which of several servers to send the ioreq
> to, and that might be a number that passes mfn_valid().  But it wouldn't
> actually be an MFN, IYSWIM.

Ok great. This is what I have now. But I haven't been able to test it, so
RFC for the moment.
Andres

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.org>
# Date 1334762521 14400
# Node ID d91665827cbc9e4c7e649a664b93966e8bb00f09
# Parent  9c241969ea6db6590de1f7079309d7cd7b4d6435
x86/mem_sharing: Rectify test for "empty" physmap entry in
sharing_add_to_physmap.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9c241969ea6d -r d91665827cbc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
     if ( spage->sharing->handle != sh )
         goto err_unlock;

-    /* Make sure the target page is a hole in the physmap */
-    if ( mfn_valid(cmfn) ||
-         (!(p2m_is_ram(cmfn_type))) )
+    /* Make sure the target page is a hole in the physmap. This is not as
+     * simple a test as we'd like it to be. Non-existent p2m entries return
+     * invalid mfn and p2m_mmio_dm type when queried. */
+    if ( !p2m_is_hole(cmfn_type) )
     {
         ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
diff -r 9c241969ea6d -r d91665827cbc xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -133,6 +133,12 @@ typedef unsigned int p2m_query_t;
                        | p2m_to_mask(p2m_ram_paging_in)       \
                        | p2m_to_mask(p2m_ram_shared))

+/* Types that represent a physmap hole that is ok to replace with a shared
+ * entry */
+#define P2M_HOLE_TYPES (p2m_to_mask(p2m_mmio_dm)     \
+                       | p2m_to_mask(p2m_invalid)   \
+                       | p2m_to_mask(p2m_ram_paged))
+
 /* Grant mapping types, which map to a real machine frame in another
  * VM */
 #define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw)  \
@@ -173,6 +179,7 @@ typedef unsigned int p2m_query_t;

 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
+#define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
 #define p2m_is_magic(_t) (p2m_to_mask(_t) & P2M_MAGIC_TYPES)


>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:55:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXE7-00037V-Uc; Wed, 18 Apr 2012 15:55:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXE6-00037I-UU
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:55:27 +0000
Received: from [85.158.139.83:56528] by server-8.bemta-5.messagelabs.com id
	7C/FE-26964-EE3EE8F4; Wed, 18 Apr 2012 15:55:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334764524!19809756!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8187 invoked from network); 18 Apr 2012 15:55:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:55:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXE4-0002fN-Dv; Wed, 18 Apr 2012 15:55:24 +0000
Date: Wed, 18 Apr 2012 16:55:24 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418155524.GO7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="LpQ9ahxlCli8rRTG"
Content-Disposition: inline
In-Reply-To: <aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 6] x86/mm: Print stack trace on a an
	mm-locks deadlock panic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 12:22 -0400 on 13 Apr (1334319739), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mm-locks.h |  3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Good idea, but 'WARN(); panic();' is a bit ugly.  How about the
attached two patches instead?  The second one fixes what I think must be
a typo, unless I'm forgetting something subtle.

Tim.

--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=backtrace

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1334763793 -3600
# Node ID 33978b6482d058887c00454aff078476cef4155d
# Parent 7c777cb8f705411b77c551f34ba88bdc09e38ab8
x86/mm: BUG() rather than panic() on mm lock order violations

That gives us a backtrace showing where the bad lock happens.

Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 7c777cb8f705 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:49:55 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:50:45 2012 +0100
@@ -50,8 +50,11 @@ static inline int mm_locked_by_me(mm_loc
 #define __check_lock_level(l)                           \
 do {                                                    \
     if ( unlikely(__get_lock_level()) > (l) )           \
-        panic("mm locking order violation: %i > %i\n",  \
-              __get_lock_level(), (l));                 \
+    {                                                   \
+        printk("mm locking order violation: %i > %i\n", \
+               __get_lock_level(), (l));                \
+        BUG();                                          \
+    }                                                   \
 } while(0)
 
 #define __set_lock_level(l)         \

--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=parens

# HG changeset patch
# Parent 87eb032bda77ade8cd75b530a97ea50170becb0b
x86/mm: fix parens in mm lock level check

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 87eb032bda77 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:43:13 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:50:49 2012 +0100
@@ -49,7 +49,7 @@ static inline int mm_locked_by_me(mm_loc
  * where the offending locks are declared. */
 #define __check_lock_level(l)                           \
 do {                                                    \
-    if ( unlikely(__get_lock_level()) > (l) )           \
+    if ( unlikely(__get_lock_level() > (l)) )           \
     {                                                   \
         printk("mm locking order violation: %i > %i\n", \
                __get_lock_level(), (l));                \

--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--LpQ9ahxlCli8rRTG--


From xen-devel-bounces@lists.xen.org Wed Apr 18 15:55:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXE7-00037V-Uc; Wed, 18 Apr 2012 15:55:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXE6-00037I-UU
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:55:27 +0000
Received: from [85.158.139.83:56528] by server-8.bemta-5.messagelabs.com id
	7C/FE-26964-EE3EE8F4; Wed, 18 Apr 2012 15:55:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334764524!19809756!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8187 invoked from network); 18 Apr 2012 15:55:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 15:55:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXE4-0002fN-Dv; Wed, 18 Apr 2012 15:55:24 +0000
Date: Wed, 18 Apr 2012 16:55:24 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418155524.GO7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="LpQ9ahxlCli8rRTG"
Content-Disposition: inline
In-Reply-To: <aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 6] x86/mm: Print stack trace on a an
	mm-locks deadlock panic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 12:22 -0400 on 13 Apr (1334319739), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mm-locks.h |  3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Good idea, but 'WARN(); panic();' is a bit ugly.  How about the
attached two patches instead?  The second one fixes what I think must be
a typo, unless I'm forgetting something subtle.

Tim.

--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=backtrace

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1334763793 -3600
# Node ID 33978b6482d058887c00454aff078476cef4155d
# Parent 7c777cb8f705411b77c551f34ba88bdc09e38ab8
x86/mm: BUG() rather than panic() on mm lock order violations

That gives us a backtrace showing where the bad lock happens.

Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 7c777cb8f705 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:49:55 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:50:45 2012 +0100
@@ -50,8 +50,11 @@ static inline int mm_locked_by_me(mm_loc
 #define __check_lock_level(l)                           \
 do {                                                    \
     if ( unlikely(__get_lock_level()) > (l) )           \
-        panic("mm locking order violation: %i > %i\n",  \
-              __get_lock_level(), (l));                 \
+    {                                                   \
+        printk("mm locking order violation: %i > %i\n", \
+               __get_lock_level(), (l));                \
+        BUG();                                          \
+    }                                                   \
 } while(0)
 
 #define __set_lock_level(l)         \

--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=parens

# HG changeset patch
# Parent 87eb032bda77ade8cd75b530a97ea50170becb0b
x86/mm: fix parens in mm lock level check

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 87eb032bda77 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:43:13 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Wed Apr 18 16:50:49 2012 +0100
@@ -49,7 +49,7 @@ static inline int mm_locked_by_me(mm_loc
  * where the offending locks are declared. */
 #define __check_lock_level(l)                           \
 do {                                                    \
-    if ( unlikely(__get_lock_level()) > (l) )           \
+    if ( unlikely(__get_lock_level() > (l)) )           \
     {                                                   \
         printk("mm locking order violation: %i > %i\n", \
                __get_lock_level(), (l));                \

--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--LpQ9ahxlCli8rRTG--


From xen-devel-bounces@lists.xen.org Wed Apr 18 15:58:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXHF-0003Pu-IE; Wed, 18 Apr 2012 15:58:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXHD-0003PR-BB
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:58:39 +0000
Received: from [85.158.143.35:55713] by server-3.bemta-4.messagelabs.com id
	8A/C6-05853-EA4EE8F4; Wed, 18 Apr 2012 15:58:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334764715!13034146!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTk2ODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16394 invoked from network); 18 Apr 2012 15:58:35 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-21.messagelabs.com with SMTP;
	18 Apr 2012 15:58:35 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id CB5A4604078;
	Wed, 18 Apr 2012 08:58:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PElk17pe12ZXVcNQgn9hDEpm1LqTy1E5jXBx03WxrFkD
	dmzMMht3KE5rzmfa/myF3kd+/bwoSUQZABXlbFmah4CouZ4X5qFTSt2P52fWUZ77
	vbPynjLlFytVRAHQxioJ3SzQJKNigy8o4oecr9AyWCj+mkjftdZXdL9IuGY1KMQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=UAMM3DAQGYEIrJ7xDDqro6pjPws=; b=BSkGlTP7
	pEOzzddU3EX2lTDhRmSM8oMCoau1+FrmkQYoTbq6WChvmT3diTVIl1BzNfibFJoZ
	qGs7/+WFA1S+gyX26QwmYfhIcBVTjmZfZyFwA39HmQo2A/90a84bAz0Z4o/YViDK
	oCJBSn53hCIn1PKYQlEfTujRolORrCxzxQ0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id BFB29604076; 
	Wed, 18 Apr 2012 08:58:33 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 08:58:34 -0700
Message-ID: <643fe964526832d97970e5541a1a2104.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418155524.GO7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
	<20120418155524.GO7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 08:58:34 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 6] x86/mm: Print stack trace on a an
 mm-locks deadlock panic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 12:22 -0400 on 13 Apr (1334319739), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mm-locks.h |  3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Good idea, but 'WARN(); panic();' is a bit ugly.  How about the
> attached two patches instead?  The second one fixes what I think must be
> a typo, unless I'm forgetting something subtle.

Better. Thanks. Ack'ed both
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 15:58:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 15:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXHF-0003Pu-IE; Wed, 18 Apr 2012 15:58:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXHD-0003PR-BB
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 15:58:39 +0000
Received: from [85.158.143.35:55713] by server-3.bemta-4.messagelabs.com id
	8A/C6-05853-EA4EE8F4; Wed, 18 Apr 2012 15:58:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334764715!13034146!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTk2ODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16394 invoked from network); 18 Apr 2012 15:58:35 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-21.messagelabs.com with SMTP;
	18 Apr 2012 15:58:35 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id CB5A4604078;
	Wed, 18 Apr 2012 08:58:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PElk17pe12ZXVcNQgn9hDEpm1LqTy1E5jXBx03WxrFkD
	dmzMMht3KE5rzmfa/myF3kd+/bwoSUQZABXlbFmah4CouZ4X5qFTSt2P52fWUZ77
	vbPynjLlFytVRAHQxioJ3SzQJKNigy8o4oecr9AyWCj+mkjftdZXdL9IuGY1KMQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=UAMM3DAQGYEIrJ7xDDqro6pjPws=; b=BSkGlTP7
	pEOzzddU3EX2lTDhRmSM8oMCoau1+FrmkQYoTbq6WChvmT3diTVIl1BzNfibFJoZ
	qGs7/+WFA1S+gyX26QwmYfhIcBVTjmZfZyFwA39HmQo2A/90a84bAz0Z4o/YViDK
	oCJBSn53hCIn1PKYQlEfTujRolORrCxzxQ0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id BFB29604076; 
	Wed, 18 Apr 2012 08:58:33 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 08:58:34 -0700
Message-ID: <643fe964526832d97970e5541a1a2104.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418155524.GO7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<aa4ef559da60be600833.1334334139@xdev.gridcentric.ca>
	<20120418155524.GO7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 08:58:34 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 6] x86/mm: Print stack trace on a an
 mm-locks deadlock panic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 12:22 -0400 on 13 Apr (1334319739), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mm-locks.h |  3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Good idea, but 'WARN(); panic();' is a bit ugly.  How about the
> attached two patches instead?  The second one fixes what I think must be
> a typo, unless I'm forgetting something subtle.

Better. Thanks. Ack'ed both
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:04:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXMP-00044s-AJ; Wed, 18 Apr 2012 16:04:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXMO-00044j-5L
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:04:00 +0000
Received: from [193.109.254.147:49317] by server-4.bemta-14.messagelabs.com id
	1B/F9-11570-FE5EE8F4; Wed, 18 Apr 2012 16:03:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334765038!5180409!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7460 invoked from network); 18 Apr 2012 16:03:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 16:03:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXML-0002hN-JO; Wed, 18 Apr 2012 16:03:57 +0000
Date: Wed, 18 Apr 2012 17:03:57 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418160357.GP7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<8ec52231c03d91842d6b.1334334144@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8ec52231c03d91842d6b.1334334144@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86/mm: Locking p2m lookups in
	shadow mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:22 -0400 on 13 Apr (1334319744), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/p2m.c |  5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> 
> Fully synchronized p2m lookups have been added to hap already. Enable that for
> shadow mode as well.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Once we're happy with the rest of the series, 
Acked-by: Tim Deegan <tim@xen.org>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:04:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXMP-00044s-AJ; Wed, 18 Apr 2012 16:04:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXMO-00044j-5L
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:04:00 +0000
Received: from [193.109.254.147:49317] by server-4.bemta-14.messagelabs.com id
	1B/F9-11570-FE5EE8F4; Wed, 18 Apr 2012 16:03:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334765038!5180409!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7460 invoked from network); 18 Apr 2012 16:03:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 16:03:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXML-0002hN-JO; Wed, 18 Apr 2012 16:03:57 +0000
Date: Wed, 18 Apr 2012 17:03:57 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418160357.GP7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<8ec52231c03d91842d6b.1334334144@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8ec52231c03d91842d6b.1334334144@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6 of 6] x86/mm: Locking p2m lookups in
	shadow mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:22 -0400 on 13 Apr (1334319744), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/p2m.c |  5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> 
> Fully synchronized p2m lookups have been added to hap already. Enable that for
> shadow mode as well.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Once we're happy with the rest of the series, 
Acked-by: Tim Deegan <tim@xen.org>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXVa-0004Ih-Fd; Wed, 18 Apr 2012 16:13:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXVZ-0004Ic-CS
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:13:29 +0000
Received: from [85.158.139.83:3477] by server-2.bemta-5.messagelabs.com id
	58/94-17016-828EE8F4; Wed, 18 Apr 2012 16:13:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334765607!24407332!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 702 invoked from network); 18 Apr 2012 16:13:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 16:13:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXVW-0002jS-Sf; Wed, 18 Apr 2012 16:13:26 +0000
Date: Wed, 18 Apr 2012 17:13:26 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418161326.GQ7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
	p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nack, at least for now; we spent a fair amount of effort taking all this
emulation code out from under the shadow lock; serializing it under the
p2m lock would be unfortunate.  The other patches are less worrying,
since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
be avoided. 

The existing interlock between the shadow code and the p2m code prevents
any p2m modifications from happening when the shadow lock is held, so I
hope I can solve this by switching to unlocked lookups instead.  I'm
building a test kernel now to tell me exactly which lookps are to
blame.

If I don't get this done today I'll look into it tomorrow.  

Cheers,

Tim.

At 12:22 -0400 on 13 Apr (1334319741), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/shadow/multi.c |  25 +++++++++++++++++++++++++
>  1 files changed, 25 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r f8fd4a4239a8 -r 964c6cbad926 xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -5033,9 +5033,21 @@ sh_x86_emulate_write(struct vcpu *v, uns
>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>          return X86EMUL_UNHANDLEABLE;
>  
> +    /* To prevent a shadow mode deadlock, we need to hold the p2m from here
> +     * onwards. emulate_unmap_dest may need to verify the pte that is being
> +     * written to here, and thus get_gfn on the gfn contained in the payload
> +     * that is being written here. p2m_lock is recursive, so all is well on
> +     * that regard. Further, holding the p2m lock ensures the page table gfn
> +     * being written to won't go away (although that could be achieved with
> +     * a page reference, as done elsewhere).
> +     */
> +    p2m_lock(p2m_get_hostp2m(v->domain));
>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>      if ( emulate_map_dest_failed(addr) )
> +    {
> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>          return (long)addr;
> +    }
>  
>      paging_lock(v->domain);
>      memcpy(addr, src, bytes);
> @@ -5059,6 +5071,7 @@ sh_x86_emulate_write(struct vcpu *v, uns
>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>      shadow_audit_tables(v);
>      paging_unlock(v->domain);
> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>      return X86EMUL_OKAY;
>  }
>  
> @@ -5075,9 +5088,14 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>          return X86EMUL_UNHANDLEABLE;
>  
> +    /* see comment in sh_x86_emulate_write. */
> +    p2m_lock(p2m_get_hostp2m(v->domain));
>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>      if ( emulate_map_dest_failed(addr) )
> +    {
> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>          return (long)addr;
> +    }
>  
>      paging_lock(v->domain);
>      switch ( bytes )
> @@ -5101,6 +5119,7 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>      shadow_audit_tables(v);
>      paging_unlock(v->domain);
> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>      return rv;
>  }
>  
> @@ -5119,9 +5138,14 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>      if ( (vaddr & 7) && !is_hvm_vcpu(v) )
>          return X86EMUL_UNHANDLEABLE;
>  
> +    /* see comment in sh_x86_emulate_write. */
> +    p2m_lock(p2m_get_hostp2m(v->domain));
>      addr = emulate_map_dest(v, vaddr, 8, sh_ctxt);
>      if ( emulate_map_dest_failed(addr) )
> +    {
> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>          return (long)addr;
> +    }
>  
>      old = (((u64) old_hi) << 32) | (u64) old_lo;
>      new = (((u64) new_hi) << 32) | (u64) new_lo;
> @@ -5135,6 +5159,7 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>      emulate_unmap_dest(v, addr, 8, sh_ctxt);
>      shadow_audit_tables(v);
>      paging_unlock(v->domain);
> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>      return rv;
>  }
>  #endif
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXVa-0004Ih-Fd; Wed, 18 Apr 2012 16:13:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXVZ-0004Ic-CS
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:13:29 +0000
Received: from [85.158.139.83:3477] by server-2.bemta-5.messagelabs.com id
	58/94-17016-828EE8F4; Wed, 18 Apr 2012 16:13:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1334765607!24407332!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 702 invoked from network); 18 Apr 2012 16:13:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 16:13:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXVW-0002jS-Sf; Wed, 18 Apr 2012 16:13:26 +0000
Date: Wed, 18 Apr 2012 17:13:26 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120418161326.GQ7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
	p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nack, at least for now; we spent a fair amount of effort taking all this
emulation code out from under the shadow lock; serializing it under the
p2m lock would be unfortunate.  The other patches are less worrying,
since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
be avoided. 

The existing interlock between the shadow code and the p2m code prevents
any p2m modifications from happening when the shadow lock is held, so I
hope I can solve this by switching to unlocked lookups instead.  I'm
building a test kernel now to tell me exactly which lookps are to
blame.

If I don't get this done today I'll look into it tomorrow.  

Cheers,

Tim.

At 12:22 -0400 on 13 Apr (1334319741), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/shadow/multi.c |  25 +++++++++++++++++++++++++
>  1 files changed, 25 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r f8fd4a4239a8 -r 964c6cbad926 xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -5033,9 +5033,21 @@ sh_x86_emulate_write(struct vcpu *v, uns
>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>          return X86EMUL_UNHANDLEABLE;
>  
> +    /* To prevent a shadow mode deadlock, we need to hold the p2m from here
> +     * onwards. emulate_unmap_dest may need to verify the pte that is being
> +     * written to here, and thus get_gfn on the gfn contained in the payload
> +     * that is being written here. p2m_lock is recursive, so all is well on
> +     * that regard. Further, holding the p2m lock ensures the page table gfn
> +     * being written to won't go away (although that could be achieved with
> +     * a page reference, as done elsewhere).
> +     */
> +    p2m_lock(p2m_get_hostp2m(v->domain));
>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>      if ( emulate_map_dest_failed(addr) )
> +    {
> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>          return (long)addr;
> +    }
>  
>      paging_lock(v->domain);
>      memcpy(addr, src, bytes);
> @@ -5059,6 +5071,7 @@ sh_x86_emulate_write(struct vcpu *v, uns
>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>      shadow_audit_tables(v);
>      paging_unlock(v->domain);
> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>      return X86EMUL_OKAY;
>  }
>  
> @@ -5075,9 +5088,14 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>          return X86EMUL_UNHANDLEABLE;
>  
> +    /* see comment in sh_x86_emulate_write. */
> +    p2m_lock(p2m_get_hostp2m(v->domain));
>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>      if ( emulate_map_dest_failed(addr) )
> +    {
> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>          return (long)addr;
> +    }
>  
>      paging_lock(v->domain);
>      switch ( bytes )
> @@ -5101,6 +5119,7 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>      shadow_audit_tables(v);
>      paging_unlock(v->domain);
> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>      return rv;
>  }
>  
> @@ -5119,9 +5138,14 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>      if ( (vaddr & 7) && !is_hvm_vcpu(v) )
>          return X86EMUL_UNHANDLEABLE;
>  
> +    /* see comment in sh_x86_emulate_write. */
> +    p2m_lock(p2m_get_hostp2m(v->domain));
>      addr = emulate_map_dest(v, vaddr, 8, sh_ctxt);
>      if ( emulate_map_dest_failed(addr) )
> +    {
> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>          return (long)addr;
> +    }
>  
>      old = (((u64) old_hi) << 32) | (u64) old_lo;
>      new = (((u64) new_hi) << 32) | (u64) new_lo;
> @@ -5135,6 +5159,7 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>      emulate_unmap_dest(v, addr, 8, sh_ctxt);
>      shadow_audit_tables(v);
>      paging_unlock(v->domain);
> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>      return rv;
>  }
>  #endif
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:19:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXaj-0004Yy-9n; Wed, 18 Apr 2012 16:18:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXah-0004Yn-8o
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:18:47 +0000
Received: from [193.109.254.147:35645] by server-2.bemta-14.messagelabs.com id
	62/A6-19409-669EE8F4; Wed, 18 Apr 2012 16:18:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334765925!5212925!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11777 invoked from network); 18 Apr 2012 16:18:45 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-8.tower-27.messagelabs.com with SMTP;
	18 Apr 2012 16:18:45 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 8A05D5EC085;
	Wed, 18 Apr 2012 09:18:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=mRchV+UuYaW9ajk3jLWVOJLjwW41323M7IkRfLltyVY1
	87Qz8NLRXdt+2fF/KXREhAGyyVvlR3e7PUBWuaaWPDDMAK3DHwU1cwnUTfsJMUyN
	4Z6mpb7iiWUtQx5lfGV3QHNUbavHS21xh2/fThHiI6aNUlhYKnt0YD3VVYNjeFE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=oD7SdUEqn3PuSkQTmLxkVdZOJNk=; b=W7RcJldb
	ASr3igBhJTbTE5TK8kXXcqxKV8hMkehzV3rHsAuwBNm/dnPxIaj6irm6Vcxg4xCo
	5XNUh6Nam/HlWp7WtsEMGPT4t1InyQrkrBoGxu6baLPY4+B98cec3OMBtlCvgeS4
	H1mR9zihFAYQSwDnsaIAHAHPMwv8sZoA58I=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id B8BD45EC084; 
	Wed, 18 Apr 2012 09:18:43 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 09:18:44 -0700
Message-ID: <1278bd7674af27a3858dae12a5f16d65.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418153530.GM7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
	<20120418153530.GM7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 09:18:44 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages
 with many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 10:16 -0400 on 12 Apr (1334225774), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c     |  170
>> +++++++++++++++++++++++++++++++++++--
>>  xen/include/asm-x86/mem_sharing.h |   13 ++-
>>  2 files changed, 169 insertions(+), 14 deletions(-)
>>
>>
>> For shared frames that have many references, the doubly-linked list used
>> to
>> store the rmap results in costly scans during unshare operations. To
>> alleviate
>> the overhead, replace the linked list by a hash table. However, hash
>> tables are
>> space-intensive, so only use them for pages that have "many" (arbitrary
>> threshold) references.
>>
>> Unsharing is heaviliy exercised during domain destroy. In experimental
>> testing,
>> for a domain that points over 100 thousand pages to the same shared
>> frame,
>> domain destruction dropped from over 7 minutes(!) to less than two
>> seconds.
>
> If you're adding a new datastructure, would it be better to use a tree,
> since the keys are easily sorted?  Xen already has include/xen/rbtree.h.
> It would have a higher per-entry overhead but you wouldn't need to keep
> the list datastructure as well for the light-sharing case.

My main concern is space. A regular case we deal with is four hundred
thousand shared frames, most with roughly a hundred <domid,gfn>s they
back, some with over a hundred thousand, a few with less than ten
thousand. That's a lot of heap memory for rb trees and nodes! I find O(n)
on less than 256 to be easily tolerable, as well as spending an extra page
only when we're saving thousands.


Nevertheless I'll look into rb tree. Whose only consumer is tmem, if I'm
not mistaken. It doesn't seem like pool objects grow to contain so many
pages, but I could be wrong.

Andres
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:19:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXaj-0004Yy-9n; Wed, 18 Apr 2012 16:18:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXah-0004Yn-8o
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:18:47 +0000
Received: from [193.109.254.147:35645] by server-2.bemta-14.messagelabs.com id
	62/A6-19409-669EE8F4; Wed, 18 Apr 2012 16:18:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334765925!5212925!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4NTYy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11777 invoked from network); 18 Apr 2012 16:18:45 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-8.tower-27.messagelabs.com with SMTP;
	18 Apr 2012 16:18:45 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 8A05D5EC085;
	Wed, 18 Apr 2012 09:18:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=mRchV+UuYaW9ajk3jLWVOJLjwW41323M7IkRfLltyVY1
	87Qz8NLRXdt+2fF/KXREhAGyyVvlR3e7PUBWuaaWPDDMAK3DHwU1cwnUTfsJMUyN
	4Z6mpb7iiWUtQx5lfGV3QHNUbavHS21xh2/fThHiI6aNUlhYKnt0YD3VVYNjeFE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=oD7SdUEqn3PuSkQTmLxkVdZOJNk=; b=W7RcJldb
	ASr3igBhJTbTE5TK8kXXcqxKV8hMkehzV3rHsAuwBNm/dnPxIaj6irm6Vcxg4xCo
	5XNUh6Nam/HlWp7WtsEMGPT4t1InyQrkrBoGxu6baLPY4+B98cec3OMBtlCvgeS4
	H1mR9zihFAYQSwDnsaIAHAHPMwv8sZoA58I=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id B8BD45EC084; 
	Wed, 18 Apr 2012 09:18:43 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 09:18:44 -0700
Message-ID: <1278bd7674af27a3858dae12a5f16d65.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418153530.GM7013@ocelot.phlegethon.org>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
	<20120418153530.GM7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 09:18:44 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca, andres@gridcentric.ca, keir.xen@gmail.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages
 with many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 10:16 -0400 on 12 Apr (1334225774), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c     |  170
>> +++++++++++++++++++++++++++++++++++--
>>  xen/include/asm-x86/mem_sharing.h |   13 ++-
>>  2 files changed, 169 insertions(+), 14 deletions(-)
>>
>>
>> For shared frames that have many references, the doubly-linked list used
>> to
>> store the rmap results in costly scans during unshare operations. To
>> alleviate
>> the overhead, replace the linked list by a hash table. However, hash
>> tables are
>> space-intensive, so only use them for pages that have "many" (arbitrary
>> threshold) references.
>>
>> Unsharing is heaviliy exercised during domain destroy. In experimental
>> testing,
>> for a domain that points over 100 thousand pages to the same shared
>> frame,
>> domain destruction dropped from over 7 minutes(!) to less than two
>> seconds.
>
> If you're adding a new datastructure, would it be better to use a tree,
> since the keys are easily sorted?  Xen already has include/xen/rbtree.h.
> It would have a higher per-entry overhead but you wouldn't need to keep
> the list datastructure as well for the light-sharing case.

My main concern is space. A regular case we deal with is four hundred
thousand shared frames, most with roughly a hundred <domid,gfn>s they
back, some with over a hundred thousand, a few with less than ten
thousand. That's a lot of heap memory for rb trees and nodes! I find O(n)
on less than 256 to be easily tolerable, as well as spending an extra page
only when we're saving thousands.


Nevertheless I'll look into rb tree. Whose only consumer is tmem, if I'm
not mistaken. It doesn't seem like pool objects grow to contain so many
pages, but I could be wrong.

Andres
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:25:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXge-0004l4-8f; Wed, 18 Apr 2012 16:24:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKXgc-0004ky-KF
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:24:54 +0000
Received: from [193.109.254.147:16508] by server-9.bemta-14.messagelabs.com id
	60/A8-05787-5DAEE8F4; Wed, 18 Apr 2012 16:24:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334766292!5214445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2280 invoked from network); 18 Apr 2012 16:24:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 16:24:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190961763"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:24:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 12:24:51 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKXgZ-0003fQ-1w;
	Wed, 18 Apr 2012 17:24:51 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 17:24:50 +0100
Message-ID: <F5E91791-8948-4BEA-954E-560E4AB4FA61@citrix.com>
In-Reply-To: <1334755904.23948.239.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 Apr 2012, at 14:31, Ian Campbell wrote:

>>> It's probably too late in the 4.2 cycle to direct the tap hotplug
>>> script
>>> to a different backend dir so I think the best thing to do for now 
>>> is
>>> to
>>> put this key somewhere else so that it doesn't become a guest 
>>> visible
>>> API (which is what happens with where you have put it). The same 
>>> place
>>> as udev_disable would work fine.
>>
>> Does this paths sound ok:
>>
>> /libxl/devices/<domid>/nic/<devid>/udev_disable
>> /libxl/devices/<domid>/nic/<devid>/type
>
> Works for me.

I've just realized that it's not possible to use exactly this paths, 
because then I won't be able to set the HOTPLUG_GATE env from the udev 
rules file, so I think something like:

/libxl/backend/vif/7/0

Is one of the only options left. Here are the env variable available 
when calling a hotplug script from udev:

UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/vif-7-0
SUBSYSTEM=xen-backend
XENBUS_TYPE=vif
XENBUS_PATH=backend/vif/7/0
XENBUS_BASE_PATH=backend
SEQNUM=1382

So I would set ENV{HOTPLUG_GATE} as /libxl/$XENBUS_PATH

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:25:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXge-0004l4-8f; Wed, 18 Apr 2012 16:24:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SKXgc-0004ky-KF
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:24:54 +0000
Received: from [193.109.254.147:16508] by server-9.bemta-14.messagelabs.com id
	60/A8-05787-5DAEE8F4; Wed, 18 Apr 2012 16:24:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334766292!5214445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ4NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2280 invoked from network); 18 Apr 2012 16:24:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 16:24:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="190961763"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 12:24:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 12:24:51 -0400
Received: from [10.80.3.120]	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69)	(envelope-from <roger.pau@citrix.com>)	id 1SKXgZ-0003fQ-1w;
	Wed, 18 Apr 2012 17:24:51 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Date: Wed, 18 Apr 2012 17:24:50 +0100
Message-ID: <F5E91791-8948-4BEA-954E-560E4AB4FA61@citrix.com>
In-Reply-To: <1334755904.23948.239.camel@zakaz.uk.xensource.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: MailMate Trial (1.4.2r2818)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
	libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 Apr 2012, at 14:31, Ian Campbell wrote:

>>> It's probably too late in the 4.2 cycle to direct the tap hotplug
>>> script
>>> to a different backend dir so I think the best thing to do for now 
>>> is
>>> to
>>> put this key somewhere else so that it doesn't become a guest 
>>> visible
>>> API (which is what happens with where you have put it). The same 
>>> place
>>> as udev_disable would work fine.
>>
>> Does this paths sound ok:
>>
>> /libxl/devices/<domid>/nic/<devid>/udev_disable
>> /libxl/devices/<domid>/nic/<devid>/type
>
> Works for me.

I've just realized that it's not possible to use exactly this paths, 
because then I won't be able to set the HOTPLUG_GATE env from the udev 
rules file, so I think something like:

/libxl/backend/vif/7/0

Is one of the only options left. Here are the env variable available 
when calling a hotplug script from udev:

UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/vif-7-0
SUBSYSTEM=xen-backend
XENBUS_TYPE=vif
XENBUS_PATH=backend/vif/7/0
XENBUS_BASE_PATH=backend
SEQNUM=1382

So I would set ENV{HOTPLUG_GATE} as /libxl/$XENBUS_PATH

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:26:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXhj-0004o8-O7; Wed, 18 Apr 2012 16:26:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXhi-0004nz-GW
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:26:02 +0000
Received: from [85.158.139.83:4121] by server-11.bemta-5.messagelabs.com id
	92/FD-12959-91BEE8F4; Wed, 18 Apr 2012 16:26:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334766360!24414898!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODIzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12994 invoked from network); 18 Apr 2012 16:26:00 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-182.messagelabs.com with SMTP;
	18 Apr 2012 16:26:00 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id BCCBB5EC080;
	Wed, 18 Apr 2012 09:25:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=SGk8QibDcQUVEE87On5soSvzAbeMoS+SJ8uKLQNhSSYR
	V14qtPcrT8YfhVRDb4CAeakxXPH3A08n44KuAf1jFJNb/sb5bKA4WgTX6W9r3c56
	K7dEiBIGLuAMJY/PF5HWd+ZbyE9TkTrrdsqP0rKGFSafTiA2p5IHT9u97DWdpLc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=I+mkyHZzO0ocIX8wn3b55SRubew=; b=Okjjh5Yc
	+gNwicIBN7v/WcvUqo/v7MUAMUQzbPIlWngLQG/MR5veb2Q6sPsPFZdgk09drz67
	cohCmTnQFi6jlqepjLfujY+74jSyoqx8PYSrTKzS4EckaA7XGEGe5cE6eWaTlSmc
	ZmLMEjIHUjpiH4s0ywEMl5xLzzcmMus/B2w=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 2D59A5EC07F; 
	Wed, 18 Apr 2012 09:25:58 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 09:25:58 -0700
Message-ID: <935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418161326.GQ7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
	<20120418161326.GQ7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 09:25:58 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
 p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Nack, at least for now; we spent a fair amount of effort taking all this
> emulation code out from under the shadow lock; serializing it under the
> p2m lock would be unfortunate.  The other patches are less worrying,
> since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
> be avoided.
>
> The existing interlock between the shadow code and the p2m code prevents
> any p2m modifications from happening when the shadow lock is held, so I
> hope I can solve this by switching to unlocked lookups instead.  I'm
> building a test kernel now to tell me exactly which lookps are to
> blame.

FWIW, get_gfn_query for the target gfn of the PTE entry that is being
checked in validate_gl?e entry, is the call that causes the panic this
patch tries to fix.

As for the other two patches, sh_resync_l1 is the trigger (again,
get_gfn_query on the gfn that is contained by the PTE being verified)

Andres

>
> If I don't get this done today I'll look into it tomorrow.
>
> Cheers,
>
> Tim.
>
> At 12:22 -0400 on 13 Apr (1334319741), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/shadow/multi.c |  25 +++++++++++++++++++++++++
>>  1 files changed, 25 insertions(+), 0 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r f8fd4a4239a8 -r 964c6cbad926 xen/arch/x86/mm/shadow/multi.c
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -5033,9 +5033,21 @@ sh_x86_emulate_write(struct vcpu *v, uns
>>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>>          return X86EMUL_UNHANDLEABLE;
>>
>> +    /* To prevent a shadow mode deadlock, we need to hold the p2m from
>> here
>> +     * onwards. emulate_unmap_dest may need to verify the pte that is
>> being
>> +     * written to here, and thus get_gfn on the gfn contained in the
>> payload
>> +     * that is being written here. p2m_lock is recursive, so all is
>> well on
>> +     * that regard. Further, holding the p2m lock ensures the page
>> table gfn
>> +     * being written to won't go away (although that could be achieved
>> with
>> +     * a page reference, as done elsewhere).
>> +     */
>> +    p2m_lock(p2m_get_hostp2m(v->domain));
>>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>>      if ( emulate_map_dest_failed(addr) )
>> +    {
>> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>>          return (long)addr;
>> +    }
>>
>>      paging_lock(v->domain);
>>      memcpy(addr, src, bytes);
>> @@ -5059,6 +5071,7 @@ sh_x86_emulate_write(struct vcpu *v, uns
>>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>>      shadow_audit_tables(v);
>>      paging_unlock(v->domain);
>> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>>      return X86EMUL_OKAY;
>>  }
>>
>> @@ -5075,9 +5088,14 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>>          return X86EMUL_UNHANDLEABLE;
>>
>> +    /* see comment in sh_x86_emulate_write. */
>> +    p2m_lock(p2m_get_hostp2m(v->domain));
>>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>>      if ( emulate_map_dest_failed(addr) )
>> +    {
>> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>>          return (long)addr;
>> +    }
>>
>>      paging_lock(v->domain);
>>      switch ( bytes )
>> @@ -5101,6 +5119,7 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>>      shadow_audit_tables(v);
>>      paging_unlock(v->domain);
>> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>>      return rv;
>>  }
>>
>> @@ -5119,9 +5138,14 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>>      if ( (vaddr & 7) && !is_hvm_vcpu(v) )
>>          return X86EMUL_UNHANDLEABLE;
>>
>> +    /* see comment in sh_x86_emulate_write. */
>> +    p2m_lock(p2m_get_hostp2m(v->domain));
>>      addr = emulate_map_dest(v, vaddr, 8, sh_ctxt);
>>      if ( emulate_map_dest_failed(addr) )
>> +    {
>> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>>          return (long)addr;
>> +    }
>>
>>      old = (((u64) old_hi) << 32) | (u64) old_lo;
>>      new = (((u64) new_hi) << 32) | (u64) new_lo;
>> @@ -5135,6 +5159,7 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>>      emulate_unmap_dest(v, addr, 8, sh_ctxt);
>>      shadow_audit_tables(v);
>>      paging_unlock(v->domain);
>> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>>      return rv;
>>  }
>>  #endif
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:26:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXhj-0004o8-O7; Wed, 18 Apr 2012 16:26:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKXhi-0004nz-GW
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:26:02 +0000
Received: from [85.158.139.83:4121] by server-11.bemta-5.messagelabs.com id
	92/FD-12959-91BEE8F4; Wed, 18 Apr 2012 16:26:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334766360!24414898!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODIzNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12994 invoked from network); 18 Apr 2012 16:26:00 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-182.messagelabs.com with SMTP;
	18 Apr 2012 16:26:00 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id BCCBB5EC080;
	Wed, 18 Apr 2012 09:25:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=SGk8QibDcQUVEE87On5soSvzAbeMoS+SJ8uKLQNhSSYR
	V14qtPcrT8YfhVRDb4CAeakxXPH3A08n44KuAf1jFJNb/sb5bKA4WgTX6W9r3c56
	K7dEiBIGLuAMJY/PF5HWd+ZbyE9TkTrrdsqP0rKGFSafTiA2p5IHT9u97DWdpLc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=I+mkyHZzO0ocIX8wn3b55SRubew=; b=Okjjh5Yc
	+gNwicIBN7v/WcvUqo/v7MUAMUQzbPIlWngLQG/MR5veb2Q6sPsPFZdgk09drz67
	cohCmTnQFi6jlqepjLfujY+74jSyoqx8PYSrTKzS4EckaA7XGEGe5cE6eWaTlSmc
	ZmLMEjIHUjpiH4s0ywEMl5xLzzcmMus/B2w=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 2D59A5EC07F; 
	Wed, 18 Apr 2012 09:25:58 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 18 Apr 2012 09:25:58 -0700
Message-ID: <935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120418161326.GQ7013@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
	<20120418161326.GQ7013@ocelot.phlegethon.org>
Date: Wed, 18 Apr 2012 09:25:58 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
 p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Nack, at least for now; we spent a fair amount of effort taking all this
> emulation code out from under the shadow lock; serializing it under the
> p2m lock would be unfortunate.  The other patches are less worrying,
> since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
> be avoided.
>
> The existing interlock between the shadow code and the p2m code prevents
> any p2m modifications from happening when the shadow lock is held, so I
> hope I can solve this by switching to unlocked lookups instead.  I'm
> building a test kernel now to tell me exactly which lookps are to
> blame.

FWIW, get_gfn_query for the target gfn of the PTE entry that is being
checked in validate_gl?e entry, is the call that causes the panic this
patch tries to fix.

As for the other two patches, sh_resync_l1 is the trigger (again,
get_gfn_query on the gfn that is contained by the PTE being verified)

Andres

>
> If I don't get this done today I'll look into it tomorrow.
>
> Cheers,
>
> Tim.
>
> At 12:22 -0400 on 13 Apr (1334319741), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/shadow/multi.c |  25 +++++++++++++++++++++++++
>>  1 files changed, 25 insertions(+), 0 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r f8fd4a4239a8 -r 964c6cbad926 xen/arch/x86/mm/shadow/multi.c
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -5033,9 +5033,21 @@ sh_x86_emulate_write(struct vcpu *v, uns
>>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>>          return X86EMUL_UNHANDLEABLE;
>>
>> +    /* To prevent a shadow mode deadlock, we need to hold the p2m from
>> here
>> +     * onwards. emulate_unmap_dest may need to verify the pte that is
>> being
>> +     * written to here, and thus get_gfn on the gfn contained in the
>> payload
>> +     * that is being written here. p2m_lock is recursive, so all is
>> well on
>> +     * that regard. Further, holding the p2m lock ensures the page
>> table gfn
>> +     * being written to won't go away (although that could be achieved
>> with
>> +     * a page reference, as done elsewhere).
>> +     */
>> +    p2m_lock(p2m_get_hostp2m(v->domain));
>>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>>      if ( emulate_map_dest_failed(addr) )
>> +    {
>> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>>          return (long)addr;
>> +    }
>>
>>      paging_lock(v->domain);
>>      memcpy(addr, src, bytes);
>> @@ -5059,6 +5071,7 @@ sh_x86_emulate_write(struct vcpu *v, uns
>>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>>      shadow_audit_tables(v);
>>      paging_unlock(v->domain);
>> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>>      return X86EMUL_OKAY;
>>  }
>>
>> @@ -5075,9 +5088,14 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>>      if ( (vaddr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>>          return X86EMUL_UNHANDLEABLE;
>>
>> +    /* see comment in sh_x86_emulate_write. */
>> +    p2m_lock(p2m_get_hostp2m(v->domain));
>>      addr = emulate_map_dest(v, vaddr, bytes, sh_ctxt);
>>      if ( emulate_map_dest_failed(addr) )
>> +    {
>> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>>          return (long)addr;
>> +    }
>>
>>      paging_lock(v->domain);
>>      switch ( bytes )
>> @@ -5101,6 +5119,7 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>>      emulate_unmap_dest(v, addr, bytes, sh_ctxt);
>>      shadow_audit_tables(v);
>>      paging_unlock(v->domain);
>> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>>      return rv;
>>  }
>>
>> @@ -5119,9 +5138,14 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>>      if ( (vaddr & 7) && !is_hvm_vcpu(v) )
>>          return X86EMUL_UNHANDLEABLE;
>>
>> +    /* see comment in sh_x86_emulate_write. */
>> +    p2m_lock(p2m_get_hostp2m(v->domain));
>>      addr = emulate_map_dest(v, vaddr, 8, sh_ctxt);
>>      if ( emulate_map_dest_failed(addr) )
>> +    {
>> +        p2m_unlock(p2m_get_hostp2m(v->domain));
>>          return (long)addr;
>> +    }
>>
>>      old = (((u64) old_hi) << 32) | (u64) old_lo;
>>      new = (((u64) new_hi) << 32) | (u64) new_lo;
>> @@ -5135,6 +5159,7 @@ sh_x86_emulate_cmpxchg8b(struct vcpu *v,
>>      emulate_unmap_dest(v, addr, 8, sh_ctxt);
>>      shadow_audit_tables(v);
>>      paging_unlock(v->domain);
>> +    p2m_unlock(p2m_get_hostp2m(v->domain));
>>      return rv;
>>  }
>>  #endif
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXz1-0005ME-Ax; Wed, 18 Apr 2012 16:43:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXz0-0005M8-Gv
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:43:54 +0000
Received: from [85.158.139.83:10747] by server-3.bemta-5.messagelabs.com id
	BA/89-25237-94FEE8F4; Wed, 18 Apr 2012 16:43:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334767432!19816240!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11106 invoked from network); 18 Apr 2012 16:43:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 16:43:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXyx-0002px-T0; Wed, 18 Apr 2012 16:43:51 +0000
Date: Wed, 18 Apr 2012 17:43:51 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120418164351.GS7013@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8ED17C.4090203@newcastle.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> Hi Tim,
> 
> I was thinking about changing my approach.
> 
> I think that for now I will leave those pages off because I am
> mostly interested in protecting other areas.
> 
> Those accesses for now are inevitable to get the VM to properly
> operate. Now, the question is if it is possible to use page table
> entries to do what I want to do.
> 
> The objective would be to use a bit flag that would determine if
> the pages are returned when a call to map_foreign_range is made.
> So, my final objective would be that only pages used for the three
> operations you describe are accessible to Dom0.
> Everything that is not BIOS and related, Qemu or PV backend
> drivers will not be returned.
> 
> From what I see in the header files you use 12-bits from a 24-bit
> flag (x86_64). Can we do it? This would again take us to controlling
> access at get_page_from_l1e(), right?

Are you talking about the count_info and type_info fields?  yes, I think
you can probably put a new flag or two in there.  Choosing which pages
qemu can map will be interesting, though -- it needs to map anything the
VM uses for I/O.  But maybe you can just define the things you protect
and declare taht they can't be used for I/O.  That sounds easier. :)

Cheers,

Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 16:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 16:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKXz1-0005ME-Ax; Wed, 18 Apr 2012 16:43:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKXz0-0005M8-Gv
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 16:43:54 +0000
Received: from [85.158.139.83:10747] by server-3.bemta-5.messagelabs.com id
	BA/89-25237-94FEE8F4; Wed, 18 Apr 2012 16:43:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334767432!19816240!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11106 invoked from network); 18 Apr 2012 16:43:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 16:43:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKXyx-0002px-T0; Wed, 18 Apr 2012 16:43:51 +0000
Date: Wed, 18 Apr 2012 17:43:51 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120418164351.GS7013@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8ED17C.4090203@newcastle.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> Hi Tim,
> 
> I was thinking about changing my approach.
> 
> I think that for now I will leave those pages off because I am
> mostly interested in protecting other areas.
> 
> Those accesses for now are inevitable to get the VM to properly
> operate. Now, the question is if it is possible to use page table
> entries to do what I want to do.
> 
> The objective would be to use a bit flag that would determine if
> the pages are returned when a call to map_foreign_range is made.
> So, my final objective would be that only pages used for the three
> operations you describe are accessible to Dom0.
> Everything that is not BIOS and related, Qemu or PV backend
> drivers will not be returned.
> 
> From what I see in the header files you use 12-bits from a 24-bit
> flag (x86_64). Can we do it? This would again take us to controlling
> access at get_page_from_l1e(), right?

Are you talking about the count_info and type_info fields?  yes, I think
you can probably put a new flag or two in there.  Choosing which pages
qemu can map will be interesting, though -- it needs to map anything the
VM uses for I/O.  But maybe you can just define the things you protect
and declare taht they can't be used for I/O.  That sounds easier. :)

Cheers,

Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKYQ1-0006Eh-FQ; Wed, 18 Apr 2012 17:11:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKYQ0-0006Eb-4h
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 17:11:48 +0000
Received: from [85.158.138.51:30099] by server-11.bemta-3.messagelabs.com id
	DF/D1-18894-3D5FE8F4; Wed, 18 Apr 2012 17:11:47 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334769106!22722006!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAzOTQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28451 invoked from network); 18 Apr 2012 17:11:46 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 17:11:46 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKYPy-0003uU-EK; Wed, 18 Apr 2012 18:11:46 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 18 Apr 2012
	18:10:14 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 18 Apr 2012 18:10:13 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0dhh7KdXHkGcTfQO+C/DSfkmxR0g==
Message-ID: <4F8EF575.6000002@newcastle.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
	<20120418164351.GS7013@ocelot.phlegethon.org>
In-Reply-To: <20120418164351.GS7013@ocelot.phlegethon.org>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/18/2012 05:43 PM, Tim Deegan wrote:
>
> At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > Hi Tim,
> >
> > I was thinking about changing my approach.
> >
> > I think that for now I will leave those pages off because I am
> > mostly interested in protecting other areas.
> >
> > Those accesses for now are inevitable to get the VM to properly
> > operate. Now, the question is if it is possible to use page table
> > entries to do what I want to do.
> >
> > The objective would be to use a bit flag that would determine if
> > the pages are returned when a call to map_foreign_range is made.
> > So, my final objective would be that only pages used for the three
> > operations you describe are accessible to Dom0.
> > Everything that is not BIOS and related, Qemu or PV backend
> > drivers will not be returned.
> >
> > From what I see in the header files you use 12-bits from a 24-bit
> > flag (x86_64). Can we do it? This would again take us to controlling
> > access at get_page_from_l1e(), right?
>
> Are you talking about the count_info and type_info fields?  yes, I think
> you can probably put a new flag or two in there.
>
I was thinking about the ones used in page table entries
(_PAGE_PRESENT|RW, etc). So, I can do the type of control
I want to achieve using type_info, maybe the flags I was
thinking about are not the best option for what I want.
>
> Choosing which pages
> qemu can map will be interesting, though -- it needs to map anything the
> VM uses for I/O.  But maybe you can just define the things you protect
> and declare taht they can't be used for I/O.  That sounds easier. :)
>
The objective is to protect the kernel and its data structures.
That is why I was considering the flags I previously mentioned.
There is one denominated _PAGE_GUEST_KERNEL.

I see that we have them all available.

int get_page_from_l1e(...)
...
     struct page_info *page = mfn_to_page(mfn);
     uint32_t l1f = l1e_get_flags(l1e);
...

Which flags do you recommend I use to try this out?
>
>
> Cheers,
>
> Tim.
>
>
Thank you,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKYQ1-0006Eh-FQ; Wed, 18 Apr 2012 17:11:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKYQ0-0006Eb-4h
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 17:11:48 +0000
Received: from [85.158.138.51:30099] by server-11.bemta-3.messagelabs.com id
	DF/D1-18894-3D5FE8F4; Wed, 18 Apr 2012 17:11:47 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334769106!22722006!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTAzOTQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28451 invoked from network); 18 Apr 2012 17:11:46 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Apr 2012 17:11:46 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SKYPy-0003uU-EK; Wed, 18 Apr 2012 18:11:46 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 18 Apr 2012
	18:10:14 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Wed, 18 Apr 2012 18:10:13 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0dhh7KdXHkGcTfQO+C/DSfkmxR0g==
Message-ID: <4F8EF575.6000002@newcastle.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
	<20120418164351.GS7013@ocelot.phlegethon.org>
In-Reply-To: <20120418164351.GS7013@ocelot.phlegethon.org>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/18/2012 05:43 PM, Tim Deegan wrote:
>
> At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > Hi Tim,
> >
> > I was thinking about changing my approach.
> >
> > I think that for now I will leave those pages off because I am
> > mostly interested in protecting other areas.
> >
> > Those accesses for now are inevitable to get the VM to properly
> > operate. Now, the question is if it is possible to use page table
> > entries to do what I want to do.
> >
> > The objective would be to use a bit flag that would determine if
> > the pages are returned when a call to map_foreign_range is made.
> > So, my final objective would be that only pages used for the three
> > operations you describe are accessible to Dom0.
> > Everything that is not BIOS and related, Qemu or PV backend
> > drivers will not be returned.
> >
> > From what I see in the header files you use 12-bits from a 24-bit
> > flag (x86_64). Can we do it? This would again take us to controlling
> > access at get_page_from_l1e(), right?
>
> Are you talking about the count_info and type_info fields?  yes, I think
> you can probably put a new flag or two in there.
>
I was thinking about the ones used in page table entries
(_PAGE_PRESENT|RW, etc). So, I can do the type of control
I want to achieve using type_info, maybe the flags I was
thinking about are not the best option for what I want.
>
> Choosing which pages
> qemu can map will be interesting, though -- it needs to map anything the
> VM uses for I/O.  But maybe you can just define the things you protect
> and declare taht they can't be used for I/O.  That sounds easier. :)
>
The objective is to protect the kernel and its data structures.
That is why I was considering the flags I previously mentioned.
There is one denominated _PAGE_GUEST_KERNEL.

I see that we have them all available.

int get_page_from_l1e(...)
...
     struct page_info *page = mfn_to_page(mfn);
     uint32_t l1f = l1e_get_flags(l1e);
...

Which flags do you recommend I use to try this out?
>
>
> Cheers,
>
> Tim.
>
>
Thank you,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 17:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 17:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKYXL-0006O8-P5; Wed, 18 Apr 2012 17:19:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKYXK-0006O3-Nf
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 17:19:23 +0000
Received: from [193.109.254.147:30299] by server-12.bemta-14.messagelabs.com
	id D1/0F-05898-997FE8F4; Wed, 18 Apr 2012 17:19:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334769561!5165699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1082 invoked from network); 18 Apr 2012 17:19:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 17:19:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,443,1330905600"; d="scan'208";a="12012100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 17:19:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 18:19:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKYXI-0001fk-Vh;
	Wed, 18 Apr 2012 17:19:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKYXI-0001wG-Lc;
	Wed, 18 Apr 2012 18:19:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12714-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 18:19:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12714: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12714 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12714/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                592fe8980688e7cba46897685d014c7fb3018a67
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 17:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 17:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKYXL-0006O8-P5; Wed, 18 Apr 2012 17:19:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKYXK-0006O3-Nf
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 17:19:23 +0000
Received: from [193.109.254.147:30299] by server-12.bemta-14.messagelabs.com
	id D1/0F-05898-997FE8F4; Wed, 18 Apr 2012 17:19:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334769561!5165699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1082 invoked from network); 18 Apr 2012 17:19:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 17:19:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,443,1330905600"; d="scan'208";a="12012100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 17:19:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 18:19:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKYXI-0001fk-Vh;
	Wed, 18 Apr 2012 17:19:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKYXI-0001wG-Lc;
	Wed, 18 Apr 2012 18:19:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12714-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 18:19:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12714: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12714 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12714/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                592fe8980688e7cba46897685d014c7fb3018a67
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 17:22:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 17:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKYaD-0006TQ-BZ; Wed, 18 Apr 2012 17:22:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKYaC-0006TL-1d
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 17:22:20 +0000
Received: from [85.158.139.83:30267] by server-8.bemta-5.messagelabs.com id
	F1/63-26964-B48FE8F4; Wed, 18 Apr 2012 17:22:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334769738!24421620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29180 invoked from network); 18 Apr 2012 17:22:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 17:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,443,1330905600"; d="scan'208";a="12012309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 17:22:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 18:22:17 +0100
Message-ID: <1334769734.23948.277.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 18:22:14 +0100
In-Reply-To: <F5E91791-8948-4BEA-954E-560E4AB4FA61@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<F5E91791-8948-4BEA-954E-560E4AB4FA61@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 17:24 +0100, Roger Pau Monne wrote:
> On 18 Apr 2012, at 14:31, Ian Campbell wrote:
> 
> >>> It's probably too late in the 4.2 cycle to direct the tap hotplug
> >>> script
> >>> to a different backend dir so I think the best thing to do for now 
> >>> is
> >>> to
> >>> put this key somewhere else so that it doesn't become a guest 
> >>> visible
> >>> API (which is what happens with where you have put it). The same 
> >>> place
> >>> as udev_disable would work fine.
> >>
> >> Does this paths sound ok:
> >>
> >> /libxl/devices/<domid>/nic/<devid>/udev_disable
> >> /libxl/devices/<domid>/nic/<devid>/type
> >
> > Works for me.
> 
> I've just realized that it's not possible to use exactly this paths, 
> because then I won't be able to set the HOTPLUG_GATE env from the udev 
> rules file, so I think something like:
> 
> /libxl/backend/vif/7/0
> 
> Is one of the only options left. Here are the env variable available 
> when calling a hotplug script from udev:
> 
> UDEV_LOG=3
> ACTION=remove
> DEVPATH=/devices/vif-7-0
> SUBSYSTEM=xen-backend
> XENBUS_TYPE=vif
> XENBUS_PATH=backend/vif/7/0
> XENBUS_BASE_PATH=backend
> SEQNUM=1382
> 
> So I would set ENV{HOTPLUG_GATE} as /libxl/$XENBUS_PATH

That seems reasonable to me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 17:22:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 17:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKYaD-0006TQ-BZ; Wed, 18 Apr 2012 17:22:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKYaC-0006TL-1d
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 17:22:20 +0000
Received: from [85.158.139.83:30267] by server-8.bemta-5.messagelabs.com id
	F1/63-26964-B48FE8F4; Wed, 18 Apr 2012 17:22:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334769738!24421620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29180 invoked from network); 18 Apr 2012 17:22:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 17:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,443,1330905600"; d="scan'208";a="12012309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 17:22:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Apr 2012 18:22:17 +0100
Message-ID: <1334769734.23948.277.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 18 Apr 2012 18:22:14 +0100
In-Reply-To: <F5E91791-8948-4BEA-954E-560E4AB4FA61@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<F5E91791-8948-4BEA-954E-560E4AB4FA61@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 17:24 +0100, Roger Pau Monne wrote:
> On 18 Apr 2012, at 14:31, Ian Campbell wrote:
> 
> >>> It's probably too late in the 4.2 cycle to direct the tap hotplug
> >>> script
> >>> to a different backend dir so I think the best thing to do for now 
> >>> is
> >>> to
> >>> put this key somewhere else so that it doesn't become a guest 
> >>> visible
> >>> API (which is what happens with where you have put it). The same 
> >>> place
> >>> as udev_disable would work fine.
> >>
> >> Does this paths sound ok:
> >>
> >> /libxl/devices/<domid>/nic/<devid>/udev_disable
> >> /libxl/devices/<domid>/nic/<devid>/type
> >
> > Works for me.
> 
> I've just realized that it's not possible to use exactly this paths, 
> because then I won't be able to set the HOTPLUG_GATE env from the udev 
> rules file, so I think something like:
> 
> /libxl/backend/vif/7/0
> 
> Is one of the only options left. Here are the env variable available 
> when calling a hotplug script from udev:
> 
> UDEV_LOG=3
> ACTION=remove
> DEVPATH=/devices/vif-7-0
> SUBSYSTEM=xen-backend
> XENBUS_TYPE=vif
> XENBUS_PATH=backend/vif/7/0
> XENBUS_BASE_PATH=backend
> SEQNUM=1382
> 
> So I would set ENV{HOTPLUG_GATE} as /libxl/$XENBUS_PATH

That seems reasonable to me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 18:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 18:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKZYA-0007CD-NU; Wed, 18 Apr 2012 18:24:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKZY8-0007C8-H0
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 18:24:16 +0000
Received: from [85.158.143.35:38264] by server-1.bemta-4.messagelabs.com id
	3F/9B-20925-FC60F8F4; Wed, 18 Apr 2012 18:24:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334773453!12657303!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxMzEw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18055 invoked from network); 18 Apr 2012 18:24:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Apr 2012 18:24:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3IIO7HP001396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Apr 2012 18:24:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3IIO6ti025298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Apr 2012 18:24:06 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3IIO5xW021879; Wed, 18 Apr 2012 13:24:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Apr 2012 11:24:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B0EB94032D; Wed, 18 Apr 2012 14:19:06 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com
Date: Wed, 18 Apr 2012 14:19:04 -0400
Message-Id: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F8F06C8.0088,ss=1,re=0.000,fgs=0
Cc: konrad <konrad@localhost.localdomain>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen/xenbus: Add quirk to deal with
	misconfigured backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: konrad <konrad@localhost.localdomain>

A rather annoying and common case is when booting a PVonHVM guest
and exposing the PV KBD and PV VFB - as both of those do not
make any sense. The HVM guest is using the VGA driver and the emulated
keyboard for this. So we provide a very basic quirk framework
(can be expanded in the future) to not wait for 6 minutes for those devices
to initialize - they never wont.

To trigger this, put this in your guest config:

vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']

instead of this:
vnc=1
vnclisten="0.0.0.0"

[v3: Split delay in non-essential (30 seconds) and essential
 devices per Ian and Stefano suggestion]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>quirk
---
 drivers/xen/xenbus/xenbus_probe_frontend.c |   69 +++++++++++++++++++++------
 1 files changed, 53 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index f20c5f1..7422913 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -135,7 +135,7 @@ static int read_backend_details(struct xenbus_device *xendev)
 	return xenbus_read_otherend_details(xendev, "backend-id", "backend");
 }
 
-static int is_device_connecting(struct device *dev, void *data)
+static int is_device_connecting(struct device *dev, void *data, bool ignore_vkbd)
 {
 	struct xenbus_device *xendev = to_xenbus_device(dev);
 	struct device_driver *drv = data;
@@ -152,16 +152,41 @@ static int is_device_connecting(struct device *dev, void *data)
 	if (drv && (dev->driver != drv))
 		return 0;
 
+	if (ignore_vkbd) {
+		/* With older QEMU, for PVonHVM guests the guest config files
+		 * could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0']
+		 * which is nonsensical as there is no PV FB (there can be
+		 * a PVKB) running as HVM guest. */
+
+		if ((strncmp(xendev->nodename, "device/vkbd", 11) == 0))
+			return 0;
+
+		if ((strncmp(xendev->nodename, "device/vfb", 10) == 0))
+			return 0;
+	}
 	xendrv = to_xenbus_driver(dev->driver);
 	return (xendev->state < XenbusStateConnected ||
 		(xendev->state == XenbusStateConnected &&
 		 xendrv->is_ready && !xendrv->is_ready(xendev)));
 }
+static int essential_device_connecting(struct device *dev, void *data)
+{
+	return is_device_connecting(dev, data, true /* ignore PVKB+PVDB */);
+}
+static int non_essential_device_connecting(struct device *dev, void *data)
+{
+	return is_device_connecting(dev, data, false);
+}
 
-static int exists_connecting_device(struct device_driver *drv)
+static int exists_essential_connecting_device(struct device_driver *drv)
 {
 	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
-				is_device_connecting);
+				essential_device_connecting);
+}
+static int exists_non_essential_connecting_device(struct device_driver *drv)
+{
+	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
+				non_essential_device_connecting);
 }
 
 static int print_device_status(struct device *dev, void *data)
@@ -192,6 +217,23 @@ static int print_device_status(struct device *dev, void *data)
 /* We only wait for device setup after most initcalls have run. */
 static int ready_to_wait_for_devices;
 
+static bool wait_loop(unsigned long start, unsigned int max_delay,
+		     unsigned int *seconds_waited)
+{
+	if (time_after(jiffies, start + (*seconds_waited+5)*HZ)) {
+		if (!*seconds_waited)
+			printk(KERN_WARNING "XENBUS: Waiting for "
+			       "devices to initialise: ");
+		*seconds_waited += 5;
+		printk("%us...", max_delay - *seconds_waited);
+		if (*seconds_waited == max_delay)
+			return true;
+	}
+
+	schedule_timeout_interruptible(HZ/10);
+
+	return false;
+}
 /*
  * On a 5-minute timeout, wait for all devices currently configured.  We need
  * to do this to guarantee that the filesystems and / or network devices
@@ -215,19 +257,14 @@ static void wait_for_devices(struct xenbus_driver *xendrv)
 	if (!ready_to_wait_for_devices || !xen_domain())
 		return;
 
-	while (exists_connecting_device(drv)) {
-		if (time_after(jiffies, start + (seconds_waited+5)*HZ)) {
-			if (!seconds_waited)
-				printk(KERN_WARNING "XENBUS: Waiting for "
-				       "devices to initialise: ");
-			seconds_waited += 5;
-			printk("%us...", 300 - seconds_waited);
-			if (seconds_waited == 300)
-				break;
-		}
-
-		schedule_timeout_interruptible(HZ/10);
-	}
+	while (exists_non_essential_connecting_device(drv))
+		if (wait_loop(start, 30, &seconds_waited))
+			break;
+
+	/* Skips PVKB and PVFB check.*/
+	while (exists_essential_connecting_device(drv))
+		if (wait_loop(start, 270, &seconds_waited))
+			break;
 
 	if (seconds_waited)
 		printk("\n");
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 18:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 18:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKZYA-0007CD-NU; Wed, 18 Apr 2012 18:24:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKZY8-0007C8-H0
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 18:24:16 +0000
Received: from [85.158.143.35:38264] by server-1.bemta-4.messagelabs.com id
	3F/9B-20925-FC60F8F4; Wed, 18 Apr 2012 18:24:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334773453!12657303!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxMzEw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18055 invoked from network); 18 Apr 2012 18:24:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Apr 2012 18:24:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3IIO7HP001396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Apr 2012 18:24:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3IIO6ti025298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Apr 2012 18:24:06 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3IIO5xW021879; Wed, 18 Apr 2012 13:24:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Apr 2012 11:24:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B0EB94032D; Wed, 18 Apr 2012 14:19:06 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com
Date: Wed, 18 Apr 2012 14:19:04 -0400
Message-Id: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F8F06C8.0088,ss=1,re=0.000,fgs=0
Cc: konrad <konrad@localhost.localdomain>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen/xenbus: Add quirk to deal with
	misconfigured backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: konrad <konrad@localhost.localdomain>

A rather annoying and common case is when booting a PVonHVM guest
and exposing the PV KBD and PV VFB - as both of those do not
make any sense. The HVM guest is using the VGA driver and the emulated
keyboard for this. So we provide a very basic quirk framework
(can be expanded in the future) to not wait for 6 minutes for those devices
to initialize - they never wont.

To trigger this, put this in your guest config:

vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']

instead of this:
vnc=1
vnclisten="0.0.0.0"

[v3: Split delay in non-essential (30 seconds) and essential
 devices per Ian and Stefano suggestion]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>quirk
---
 drivers/xen/xenbus/xenbus_probe_frontend.c |   69 +++++++++++++++++++++------
 1 files changed, 53 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index f20c5f1..7422913 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -135,7 +135,7 @@ static int read_backend_details(struct xenbus_device *xendev)
 	return xenbus_read_otherend_details(xendev, "backend-id", "backend");
 }
 
-static int is_device_connecting(struct device *dev, void *data)
+static int is_device_connecting(struct device *dev, void *data, bool ignore_vkbd)
 {
 	struct xenbus_device *xendev = to_xenbus_device(dev);
 	struct device_driver *drv = data;
@@ -152,16 +152,41 @@ static int is_device_connecting(struct device *dev, void *data)
 	if (drv && (dev->driver != drv))
 		return 0;
 
+	if (ignore_vkbd) {
+		/* With older QEMU, for PVonHVM guests the guest config files
+		 * could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0']
+		 * which is nonsensical as there is no PV FB (there can be
+		 * a PVKB) running as HVM guest. */
+
+		if ((strncmp(xendev->nodename, "device/vkbd", 11) == 0))
+			return 0;
+
+		if ((strncmp(xendev->nodename, "device/vfb", 10) == 0))
+			return 0;
+	}
 	xendrv = to_xenbus_driver(dev->driver);
 	return (xendev->state < XenbusStateConnected ||
 		(xendev->state == XenbusStateConnected &&
 		 xendrv->is_ready && !xendrv->is_ready(xendev)));
 }
+static int essential_device_connecting(struct device *dev, void *data)
+{
+	return is_device_connecting(dev, data, true /* ignore PVKB+PVDB */);
+}
+static int non_essential_device_connecting(struct device *dev, void *data)
+{
+	return is_device_connecting(dev, data, false);
+}
 
-static int exists_connecting_device(struct device_driver *drv)
+static int exists_essential_connecting_device(struct device_driver *drv)
 {
 	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
-				is_device_connecting);
+				essential_device_connecting);
+}
+static int exists_non_essential_connecting_device(struct device_driver *drv)
+{
+	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
+				non_essential_device_connecting);
 }
 
 static int print_device_status(struct device *dev, void *data)
@@ -192,6 +217,23 @@ static int print_device_status(struct device *dev, void *data)
 /* We only wait for device setup after most initcalls have run. */
 static int ready_to_wait_for_devices;
 
+static bool wait_loop(unsigned long start, unsigned int max_delay,
+		     unsigned int *seconds_waited)
+{
+	if (time_after(jiffies, start + (*seconds_waited+5)*HZ)) {
+		if (!*seconds_waited)
+			printk(KERN_WARNING "XENBUS: Waiting for "
+			       "devices to initialise: ");
+		*seconds_waited += 5;
+		printk("%us...", max_delay - *seconds_waited);
+		if (*seconds_waited == max_delay)
+			return true;
+	}
+
+	schedule_timeout_interruptible(HZ/10);
+
+	return false;
+}
 /*
  * On a 5-minute timeout, wait for all devices currently configured.  We need
  * to do this to guarantee that the filesystems and / or network devices
@@ -215,19 +257,14 @@ static void wait_for_devices(struct xenbus_driver *xendrv)
 	if (!ready_to_wait_for_devices || !xen_domain())
 		return;
 
-	while (exists_connecting_device(drv)) {
-		if (time_after(jiffies, start + (seconds_waited+5)*HZ)) {
-			if (!seconds_waited)
-				printk(KERN_WARNING "XENBUS: Waiting for "
-				       "devices to initialise: ");
-			seconds_waited += 5;
-			printk("%us...", 300 - seconds_waited);
-			if (seconds_waited == 300)
-				break;
-		}
-
-		schedule_timeout_interruptible(HZ/10);
-	}
+	while (exists_non_essential_connecting_device(drv))
+		if (wait_loop(start, 30, &seconds_waited))
+			break;
+
+	/* Skips PVKB and PVFB check.*/
+	while (exists_essential_connecting_device(drv))
+		if (wait_loop(start, 270, &seconds_waited))
+			break;
 
 	if (seconds_waited)
 		printk("\n");
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 18:26:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 18:26:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKZZU-0007F2-7K; Wed, 18 Apr 2012 18:25:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SKZZS-0007Eu-RP
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 18:25:39 +0000
Received: from [85.158.138.51:22656] by server-8.bemta-3.messagelabs.com id
	13/AB-24428-1270F8F4; Wed, 18 Apr 2012 18:25:37 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334773535!22728765!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13192 invoked from network); 18 Apr 2012 18:25:37 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 18:25:37 -0000
Received: by dajx4 with SMTP id x4so11197967daj.28
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 11:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=s3zmw3pwZNfkgoaVRvh0p1EFLRAEWZuj5FPPME84LqQ=;
	b=ERRBkM/qAyUE/Je6l8dIPXuXplg3pOvVGdj7fmFN/YON8wJIR9bZVgMNpEnpYxTc7x
	lD2gfDr9Pu6CC3vY5L6sK/P0it8jIn9zETR1+5GZAzR+RwEpFDeUexElbXh1lz2pa/ZP
	YrsfW7wb3abtB8XDnPyfz0+/63y8Bsu2cEu8FrfOj2EpXbW7c7ArjqqJvVVkrxEDPeDj
	WJs/A6EUjRSi6gV4nRuLIXybVyoV3dZ3DZifeLc/e54KJJnW7Dnybkq+NTLP7/30LOZX
	vXBi9tMz/CeSJwfG5NiVxvymQy44ofRlpTRnczUhwbphXp8bLMPxHJi+fKEqdXurrwPi
	qvWA==
MIME-Version: 1.0
Received: by 10.68.203.41 with SMTP id kn9mr8447716pbc.75.1334773534393; Wed,
	18 Apr 2012 11:25:34 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 18 Apr 2012 11:25:34 -0700 (PDT)
In-Reply-To: <1334658395.23948.6.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
Date: Thu, 19 Apr 2012 02:25:34 +0800
Message-ID: <CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, roger.pau@citrix.com,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SNAP

> +++ b/tools/libxl/libxl_dm.c =A0 =A0Tue Apr 17 11:26:06 2012 +0100
> @@ -212,9 +212,9 @@ static char ** libxl__build_device_model
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *ifname;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!vifs[i].ifname)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifname =3D libxl__sprintf(gc,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0"tap%d.%d", domid, vifs[i].devid);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0"xentap%d.%d", domid, vifs[i].devid);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "x=
entap-%s", vifs[i].ifname);

To my understanding, you set ifname to prefix xentap instead of tap
for type LIBXL_NIC_TYPE_IOEMU which is for hvmdomain.  So please read
my comments below related to tools/python/xen/xend/image.py

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net", l=
ibxl__sprintf(gc, "nic,vlan=3D%d,macaddr=3D%s,model=3D%s",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, smac, vifs[i].model),
> @@ -451,10 +451,10 @@ static char ** libxl__build_device_model
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LIBXL_MAC=
_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *ifname;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!vifs[i].ifname) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "t=
ap%d.%d",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "x=
entap%d.%d",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 guest_domid, vifs[i].devid);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "x=
entap-%s", vifs[i].ifname);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-device");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args,
> diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> --- a/tools/python/xen/xend/image.py =A0 =A0Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/python/xen/xend/image.py =A0 =A0Tue Apr 17 11:26:06 2012 +0100
> @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
> =A0 =A0 =A0 =A0 =A0 =A0 if vifname:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifname =3D "tap-" + vifname

The above shouldn't it be:

vifname =3D "xentap-" + vifname

For your libxl related is:

ifname =3D libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);

Sorry if my thinking is wrong please correct me.

Thanks.

Kindest regards,
Giam Teck Choon


> =A0 =A0 =A0 =A0 =A0 =A0 else:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.getDom=
id(), nics-1)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "xentap%d.%d" % (self.vm.get=
Domid(), nics-1)
> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net")
> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%s=
" %
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge))
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 18:26:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 18:26:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKZZU-0007F2-7K; Wed, 18 Apr 2012 18:25:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SKZZS-0007Eu-RP
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 18:25:39 +0000
Received: from [85.158.138.51:22656] by server-8.bemta-3.messagelabs.com id
	13/AB-24428-1270F8F4; Wed, 18 Apr 2012 18:25:37 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334773535!22728765!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13192 invoked from network); 18 Apr 2012 18:25:37 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 18:25:37 -0000
Received: by dajx4 with SMTP id x4so11197967daj.28
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 11:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=s3zmw3pwZNfkgoaVRvh0p1EFLRAEWZuj5FPPME84LqQ=;
	b=ERRBkM/qAyUE/Je6l8dIPXuXplg3pOvVGdj7fmFN/YON8wJIR9bZVgMNpEnpYxTc7x
	lD2gfDr9Pu6CC3vY5L6sK/P0it8jIn9zETR1+5GZAzR+RwEpFDeUexElbXh1lz2pa/ZP
	YrsfW7wb3abtB8XDnPyfz0+/63y8Bsu2cEu8FrfOj2EpXbW7c7ArjqqJvVVkrxEDPeDj
	WJs/A6EUjRSi6gV4nRuLIXybVyoV3dZ3DZifeLc/e54KJJnW7Dnybkq+NTLP7/30LOZX
	vXBi9tMz/CeSJwfG5NiVxvymQy44ofRlpTRnczUhwbphXp8bLMPxHJi+fKEqdXurrwPi
	qvWA==
MIME-Version: 1.0
Received: by 10.68.203.41 with SMTP id kn9mr8447716pbc.75.1334773534393; Wed,
	18 Apr 2012 11:25:34 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 18 Apr 2012 11:25:34 -0700 (PDT)
In-Reply-To: <1334658395.23948.6.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
Date: Thu, 19 Apr 2012 02:25:34 +0800
Message-ID: <CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, roger.pau@citrix.com,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SNAP

> +++ b/tools/libxl/libxl_dm.c =A0 =A0Tue Apr 17 11:26:06 2012 +0100
> @@ -212,9 +212,9 @@ static char ** libxl__build_device_model
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *ifname;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!vifs[i].ifname)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifname =3D libxl__sprintf(gc,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0"tap%d.%d", domid, vifs[i].devid);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0"xentap%d.%d", domid, vifs[i].devid);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "x=
entap-%s", vifs[i].ifname);

To my understanding, you set ifname to prefix xentap instead of tap
for type LIBXL_NIC_TYPE_IOEMU which is for hvmdomain.  So please read
my comments below related to tools/python/xen/xend/image.py

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net", l=
ibxl__sprintf(gc, "nic,vlan=3D%d,macaddr=3D%s,model=3D%s",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, smac, vifs[i].model),
> @@ -451,10 +451,10 @@ static char ** libxl__build_device_model
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LIBXL_MAC=
_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *ifname;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!vifs[i].ifname) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "t=
ap%d.%d",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "x=
entap%d.%d",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 guest_domid, vifs[i].devid);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "x=
entap-%s", vifs[i].ifname);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-device");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args,
> diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> --- a/tools/python/xen/xend/image.py =A0 =A0Mon Apr 16 17:57:00 2012 +0100
> +++ b/tools/python/xen/xend/image.py =A0 =A0Tue Apr 17 11:26:06 2012 +0100
> @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
> =A0 =A0 =A0 =A0 =A0 =A0 if vifname:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifname =3D "tap-" + vifname

The above shouldn't it be:

vifname =3D "xentap-" + vifname

For your libxl related is:

ifname =3D libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);

Sorry if my thinking is wrong please correct me.

Thanks.

Kindest regards,
Giam Teck Choon


> =A0 =A0 =A0 =A0 =A0 =A0 else:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.getDom=
id(), nics-1)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "xentap%d.%d" % (self.vm.get=
Domid(), nics-1)
> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net")
> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%s=
" %
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge))
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 19:38:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 19:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKahM-00089w-SG; Wed, 18 Apr 2012 19:37:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vhpc.dist@gmail.com>) id 1SKahK-00089n-Ee
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 19:37:50 +0000
Received: from [85.158.143.35:26134] by server-1.bemta-4.messagelabs.com id
	CA/17-20925-D081F8F4; Wed, 18 Apr 2012 19:37:49 +0000
X-Env-Sender: vhpc.dist@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334777866!13313492!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3357 invoked from network); 18 Apr 2012 19:37:48 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 19:37:48 -0000
Received: by pbcwz12 with SMTP id wz12so9509649pbc.30
	for <multiple recipients>; Wed, 18 Apr 2012 12:37:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Vzcd0MVe4EaHThQNvrnaqTQP8nwBAYUajumlENXK3vY=;
	b=amztf2EXZ3+P8j1EqDJXowNQYcnwjSZhRyWvCTVf3Ycf/G5Ry/b4buD09dTsUCne4o
	lF4DE2pbLort/o3XydUJnkhSBqzzBl7mGhB8+YyUer0BbCNhqIgkpe9zrTzBZIun0x+I
	YvZ21Lx/lxw+f+PBW/Oeo18CTcmT8C3X4CvDAz2PSjx5GZ5bhqsKD4UxeM5Kyldnr8CJ
	RQqqNsTTGe7/Kt8LqkW4juMVrrrU5ZV+GErHcMCFHM7ffSYHDNbAHzXt/DBlWzphlg4h
	z8PG37SbFY52Hoc1xJocBwteukjpx7NXO6AAgpUCgTsZ5d8JTL7+G4EEzEA/pnuSBTlW
	ziQg==
MIME-Version: 1.0
Received: by 10.68.138.232 with SMTP id qt8mr8588571pbb.114.1334777865950;
	Wed, 18 Apr 2012 12:37:45 -0700 (PDT)
Received: by 10.68.217.231 with HTTP; Wed, 18 Apr 2012 12:37:45 -0700 (PDT)
Date: Wed, 18 Apr 2012 21:37:45 +0200
Message-ID: <CAF05tLMK40dMOt+aM4=pjJk7x3kXD=Xe6ZrmHCd4NReLqBbyLQ@mail.gmail.com>
From: VHPC 11 <vhpc.dist@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] CfP 7th Workshop on Virtualization in High-Performance
 Cloud Computing (VHPC'12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

we apologize if you receive multiple copies of this CFP.

===================================================================

CALL FOR PAPERS

7th Workshop on

Virtualization in High-Performance Cloud Computing

VHPC '12

as part of Euro-Par 2012, Rhodes Island, Greece

===================================================================

Date: August 28, 2012

Workshop URL: http://vhpc.org

SUBMISSION DEADLINE:

Rolling abstract submission
June 4, 2012 - Full paper submission


SCOPE:

Virtualization has become a common abstraction layer in modern
data centers, enabling resource owners to manage complex
infrastructure independently of their applications. Conjointly,
virtualization is becoming a driving technology for a manifold of
industry grade IT services. The cloud concept includes the notion
of a separation between resource owners and users, adding  services
such as hosted application frameworks and queueing. Utilizing the
same infrastructure, clouds carry significant potential for use in
high-performance scientific computing. The ability of clouds to provide
for requests and releases of vast computing resources dynamically and
close to the marginal cost of providing the services is unprecedented in
the history of scientific and commercial computing.

Distributed computing concepts that leverage federated resource
access are popular within the grid community, but have not seen
previously desired deployed levels so far. Also, many of the scientific
data centers have not adopted virtualization or cloud concepts yet.

This workshop aims to bring together industrial providers with the
scientific community in order to foster discussion, collaboration
and mutual exchange of knowledge and experience.

The workshop will be one day in length, composed of 20 min
paper presentations, each followed by 10 min discussion sections.
Presentations may be accompanied by interactive demonstrations.


TOPICS

Topics of interest include, but are not limited to:

Higher-level cloud architectures, focusing on issues such as:
- Languages for describing highly-distributed compute jobs
- Workload characterization for VM-based environments
- Optimized communication libraries/protocols in the cloud
- Cross-layer optimization of numeric algorithms on VM infrastructure
- System and process/bytecode VM convergence
- Cloud frameworks and API sets
- Checkpointing/migration of large compute jobs
- Instrumentation interfaces and languages
- VMM performance (auto-)tuning on various load types
- Cloud reliability, fault-tolerance, and security
- Software as a Service (SaaS) architectures
- Research and education use cases
- Virtualization in cloud, cluster and grid environments
- Cross-layer VM optimizations
- Cloud use cases including optimizations
- VM-based cloud performance modelling
- Performance and cost modelling

Lower-level design challenges for Hypervisors, VM-aware I/O devices,
hardware accelerators or filesystems in VM environments, especially:
- Cloud, grid and distributed filesystems
- Hardware for I/O virtualization (storage/network/accelerators)
- Storage and network I/O subsystems in virtualized environments
- Novel software approaches to I/O virtualization
- Paravirtualized I/O subsystems for modified/unmodified guests
- Virtualization-aware cluster interconnects
- Direct device assignment
- NUMA-aware subsystems in virtualized environments
- Hardware Accelerators in virtualization (GPUs/FPGAs)
- Hardware extensions for virtualization
- VMMs/Hypervisors for embedded systems

Data Center management methods, including:
- QoS and and service levels
- VM cloud and cluster distribution algorithms
- VM load-balancing in Clouds
- Hypervisor extensions and tools for cluster and grid computing
- Fault tolerant VM environments
- Virtual machine monitor platforms
- Management, deployment and monitoring of VM-based environments
- Cluster provisioning in the Cloud


PAPER SUBMISSION

Papers submitted to the workshop will be reviewed by at least two
members of the program committee and external reviewers. Submissions
should include abstract, key words, the e-mail address of the
corresponding author, and must not exceed 10 pages, including tables
and figures at a main font size no smaller than 11 point. Submission
of a paper should be regarded as a commitment that, should the paper
be accepted, at least one of the authors will register and attend the
conference to present the work.

Accepted papers will be published in the Springer LNCS series - the
format must be according to the Springer LNCS Style. Initial
submissions are in PDF; authors of accepted papers will be requested
to provide source files.

Format Guidelines: http://www.springer.de/comp/lncs/authors.html
Style template:
ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip
Abstract Submission Link: http://edas.info/newPaper.php?c=11943


IMPORTANT DATES

Rolling abstract submission
June 4, 2012 - Full paper submission
June 29, 2012 - Acceptance notification
July 20, 2012 - Camera-ready version due
August 28, 2012 - Workshop Date


CHAIR

Michael Alexander (chair), TU Wien, Austria
Gianluigi Zanetti (co-chair), CRS4, Italy
Anastassios Nanos (co-chair), NTUA, Greece


PROGRAM COMMITTEE

Paolo Anedda, CRS4, Italy
Giovanni Busonera, CRS4, Italy
Brad Calder, Microsoft, USA
Roberto Canonico, University of Napoli Federico II, Italy
Tommaso Cucinotta, Scuola Superiore Sant'Anna, Italy
Werner Fischer, Thomas-Krenn AG, Germany
William Gardner, University of Guelph, USA
Marcus Hardt, Forschungszentrum Karlsruhe, Germany
Sverre Jarp, CERN, Switzerland
Shantenu Jha, Louisiana State University, USA
Xuxian Jiang, NC State, USA
Nectarios Koziris, National Technical University of Athens, Greece
Simone Leo, CRS4, Italy
Ignacio Llorente, Universidad Complutense de Madrid, Spain
Naoya Maruyama, Tokyo Institute of Technology, Japan
Jean-Marc Menaud, Ecole des Mines de Nantes, France
Dimitrios Nikolopoulos, Foundation for Research&Technology Hellas, Greece
Jose Renato Santos, HP Labs, USA
Walter Schwaiger, TU Wien, Austria
Yoshio Turner, HP Labs, USA
Kurt Tutschku, University of Vienna, Austria
Lizhe Wang, Indiana University, USA
Chao-Tung Yang, Tunghai University, Taiwan


DURATION: Workshop Duration is one day.


GENERAL INFORMATION

The workshop will be held as part of Euro-Par 2012.

Euro-Par 2012: http://europar2012.cti.gr/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 19:38:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 19:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKahM-00089w-SG; Wed, 18 Apr 2012 19:37:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vhpc.dist@gmail.com>) id 1SKahK-00089n-Ee
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 19:37:50 +0000
Received: from [85.158.143.35:26134] by server-1.bemta-4.messagelabs.com id
	CA/17-20925-D081F8F4; Wed, 18 Apr 2012 19:37:49 +0000
X-Env-Sender: vhpc.dist@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334777866!13313492!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3357 invoked from network); 18 Apr 2012 19:37:48 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 19:37:48 -0000
Received: by pbcwz12 with SMTP id wz12so9509649pbc.30
	for <multiple recipients>; Wed, 18 Apr 2012 12:37:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Vzcd0MVe4EaHThQNvrnaqTQP8nwBAYUajumlENXK3vY=;
	b=amztf2EXZ3+P8j1EqDJXowNQYcnwjSZhRyWvCTVf3Ycf/G5Ry/b4buD09dTsUCne4o
	lF4DE2pbLort/o3XydUJnkhSBqzzBl7mGhB8+YyUer0BbCNhqIgkpe9zrTzBZIun0x+I
	YvZ21Lx/lxw+f+PBW/Oeo18CTcmT8C3X4CvDAz2PSjx5GZ5bhqsKD4UxeM5Kyldnr8CJ
	RQqqNsTTGe7/Kt8LqkW4juMVrrrU5ZV+GErHcMCFHM7ffSYHDNbAHzXt/DBlWzphlg4h
	z8PG37SbFY52Hoc1xJocBwteukjpx7NXO6AAgpUCgTsZ5d8JTL7+G4EEzEA/pnuSBTlW
	ziQg==
MIME-Version: 1.0
Received: by 10.68.138.232 with SMTP id qt8mr8588571pbb.114.1334777865950;
	Wed, 18 Apr 2012 12:37:45 -0700 (PDT)
Received: by 10.68.217.231 with HTTP; Wed, 18 Apr 2012 12:37:45 -0700 (PDT)
Date: Wed, 18 Apr 2012 21:37:45 +0200
Message-ID: <CAF05tLMK40dMOt+aM4=pjJk7x3kXD=Xe6ZrmHCd4NReLqBbyLQ@mail.gmail.com>
From: VHPC 11 <vhpc.dist@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] CfP 7th Workshop on Virtualization in High-Performance
 Cloud Computing (VHPC'12)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

we apologize if you receive multiple copies of this CFP.

===================================================================

CALL FOR PAPERS

7th Workshop on

Virtualization in High-Performance Cloud Computing

VHPC '12

as part of Euro-Par 2012, Rhodes Island, Greece

===================================================================

Date: August 28, 2012

Workshop URL: http://vhpc.org

SUBMISSION DEADLINE:

Rolling abstract submission
June 4, 2012 - Full paper submission


SCOPE:

Virtualization has become a common abstraction layer in modern
data centers, enabling resource owners to manage complex
infrastructure independently of their applications. Conjointly,
virtualization is becoming a driving technology for a manifold of
industry grade IT services. The cloud concept includes the notion
of a separation between resource owners and users, adding  services
such as hosted application frameworks and queueing. Utilizing the
same infrastructure, clouds carry significant potential for use in
high-performance scientific computing. The ability of clouds to provide
for requests and releases of vast computing resources dynamically and
close to the marginal cost of providing the services is unprecedented in
the history of scientific and commercial computing.

Distributed computing concepts that leverage federated resource
access are popular within the grid community, but have not seen
previously desired deployed levels so far. Also, many of the scientific
data centers have not adopted virtualization or cloud concepts yet.

This workshop aims to bring together industrial providers with the
scientific community in order to foster discussion, collaboration
and mutual exchange of knowledge and experience.

The workshop will be one day in length, composed of 20 min
paper presentations, each followed by 10 min discussion sections.
Presentations may be accompanied by interactive demonstrations.


TOPICS

Topics of interest include, but are not limited to:

Higher-level cloud architectures, focusing on issues such as:
- Languages for describing highly-distributed compute jobs
- Workload characterization for VM-based environments
- Optimized communication libraries/protocols in the cloud
- Cross-layer optimization of numeric algorithms on VM infrastructure
- System and process/bytecode VM convergence
- Cloud frameworks and API sets
- Checkpointing/migration of large compute jobs
- Instrumentation interfaces and languages
- VMM performance (auto-)tuning on various load types
- Cloud reliability, fault-tolerance, and security
- Software as a Service (SaaS) architectures
- Research and education use cases
- Virtualization in cloud, cluster and grid environments
- Cross-layer VM optimizations
- Cloud use cases including optimizations
- VM-based cloud performance modelling
- Performance and cost modelling

Lower-level design challenges for Hypervisors, VM-aware I/O devices,
hardware accelerators or filesystems in VM environments, especially:
- Cloud, grid and distributed filesystems
- Hardware for I/O virtualization (storage/network/accelerators)
- Storage and network I/O subsystems in virtualized environments
- Novel software approaches to I/O virtualization
- Paravirtualized I/O subsystems for modified/unmodified guests
- Virtualization-aware cluster interconnects
- Direct device assignment
- NUMA-aware subsystems in virtualized environments
- Hardware Accelerators in virtualization (GPUs/FPGAs)
- Hardware extensions for virtualization
- VMMs/Hypervisors for embedded systems

Data Center management methods, including:
- QoS and and service levels
- VM cloud and cluster distribution algorithms
- VM load-balancing in Clouds
- Hypervisor extensions and tools for cluster and grid computing
- Fault tolerant VM environments
- Virtual machine monitor platforms
- Management, deployment and monitoring of VM-based environments
- Cluster provisioning in the Cloud


PAPER SUBMISSION

Papers submitted to the workshop will be reviewed by at least two
members of the program committee and external reviewers. Submissions
should include abstract, key words, the e-mail address of the
corresponding author, and must not exceed 10 pages, including tables
and figures at a main font size no smaller than 11 point. Submission
of a paper should be regarded as a commitment that, should the paper
be accepted, at least one of the authors will register and attend the
conference to present the work.

Accepted papers will be published in the Springer LNCS series - the
format must be according to the Springer LNCS Style. Initial
submissions are in PDF; authors of accepted papers will be requested
to provide source files.

Format Guidelines: http://www.springer.de/comp/lncs/authors.html
Style template:
ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip
Abstract Submission Link: http://edas.info/newPaper.php?c=11943


IMPORTANT DATES

Rolling abstract submission
June 4, 2012 - Full paper submission
June 29, 2012 - Acceptance notification
July 20, 2012 - Camera-ready version due
August 28, 2012 - Workshop Date


CHAIR

Michael Alexander (chair), TU Wien, Austria
Gianluigi Zanetti (co-chair), CRS4, Italy
Anastassios Nanos (co-chair), NTUA, Greece


PROGRAM COMMITTEE

Paolo Anedda, CRS4, Italy
Giovanni Busonera, CRS4, Italy
Brad Calder, Microsoft, USA
Roberto Canonico, University of Napoli Federico II, Italy
Tommaso Cucinotta, Scuola Superiore Sant'Anna, Italy
Werner Fischer, Thomas-Krenn AG, Germany
William Gardner, University of Guelph, USA
Marcus Hardt, Forschungszentrum Karlsruhe, Germany
Sverre Jarp, CERN, Switzerland
Shantenu Jha, Louisiana State University, USA
Xuxian Jiang, NC State, USA
Nectarios Koziris, National Technical University of Athens, Greece
Simone Leo, CRS4, Italy
Ignacio Llorente, Universidad Complutense de Madrid, Spain
Naoya Maruyama, Tokyo Institute of Technology, Japan
Jean-Marc Menaud, Ecole des Mines de Nantes, France
Dimitrios Nikolopoulos, Foundation for Research&Technology Hellas, Greece
Jose Renato Santos, HP Labs, USA
Walter Schwaiger, TU Wien, Austria
Yoshio Turner, HP Labs, USA
Kurt Tutschku, University of Vienna, Austria
Lizhe Wang, Indiana University, USA
Chao-Tung Yang, Tunghai University, Taiwan


DURATION: Workshop Duration is one day.


GENERAL INFORMATION

The workshop will be held as part of Euro-Par 2012.

Euro-Par 2012: http://europar2012.cti.gr/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 20:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 20:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKbdX-0000jk-7z; Wed, 18 Apr 2012 20:37:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=0455459ea1=khamlin@ncfta.net>)
	id 1SKbdV-0000jf-9X
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 20:37:57 +0000
Received: from [85.158.143.99:29947] by server-1.bemta-4.messagelabs.com id
	2D/1B-20925-4262F8F4; Wed, 18 Apr 2012 20:37:56 +0000
X-Env-Sender: prvs=0455459ea1=khamlin@ncfta.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334781474!24228364!1
X-Originating-IP: [8.28.216.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_60_70,
	HTML_ATTR_UNIQUE,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7721 invoked from network); 18 Apr 2012 20:37:55 -0000
Received: from mail.ncfta.net (HELO mail.ncfta.net) (8.28.216.12)
	by server-15.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 20:37:55 -0000
Received-SPF: none (caradhras.ncfta.net: domain of khamlin@ncfta.net does not
	designate permitted sender hosts)
Received: from caradhras.ncfta.net (caradhras.ncfta.net [172.16.8.8]) by
	mail.ncfta.net with smtp
	id 7f75_1a79_4efc203d_496c_47fe_bc63_6456dd354c76;
	Wed, 18 Apr 2012 16:37:53 -0400
Received: from Exchange01.pg.ncfta.net ([10.1.2.116])
	by caradhras.ncfta.net (8.14.4/8.14.4) with ESMTP id q3IKbrjC013208
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 16:37:54 -0400
Received: from Exchange01.pg.ncfta.net ([::1]) by Exchange01.pg.ncfta.net
	([::1]) with mapi id 14.02.0247.003; Wed, 18 Apr 2012 16:38:01 -0400
From: Ken Hamlin <khamlin@ncfta.net>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Ether setup
Thread-Index: Ac0doyRWAAZ/bhF4RTekCusuJeK8Xg==
Date: Wed, 18 Apr 2012 20:37:59 +0000
Message-ID: <FD6F285E37447D4DBB72A9E73C1BD4A2065AD672@Exchange01.pg.ncfta.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.5.109]
MIME-Version: 1.0
Subject: [Xen-devel] Ether setup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2768798327644744403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2768798327644744403==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_"

--_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello everyone. This is my first time attempting to use Xen and I am having=
 some problems. I am trying to build a Xen system so that I can use the Eth=
er program for malware analysis (http://ether.gtisc.gatech.edu/source.html)=
.

I've installed Debian 6, and downloaded the Xen 3.1.0 source. However when =
I try to compile the source using "make world" I receive the following erro=
rs:


make[5]: Entering directory `/home/user/ether/xen-3.1.0-src/xen/arch/x86'

gcc -O2 -fomit-frame-pointer -m64 -DNDEBUG -std=3Dgnu99 -Wall -Wstrict-prot=
otypes -Wno-unused-value -Wdeclaration-after-statement -nostdinc -fno-built=
in -fno-common -fno-strict-aliasing -iwithprefix include -Werror -Wno-point=
er-arith -pipe -I/home/user/ether/xen-3.1.0-src/xen/include -I/home/user/et=
her/xen-3.1.0-src/xen/include/asm-x86/mach-generic -I/home/user/ether/xen-3=
.1.0-src/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector=
 -mno-red-zone -fpic -fno-reorder-blocks -fno-asynchronous-unwind-tables -D=
GCC_HAS_VISIBILITY_ATTRIBUTE -g -D__XEN__ -c /home/user/ether/xen-3.1.0-src=
/xen/common/symbols-dummy.c -o /home/user/ether/xen-3.1.0-src/xen/common/sy=
mbols-dummy.o

make[5]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen/arch/x86'

ld -melf_x86_64 -T xen.lds -N \

          boot/x86_64.o /home/user/ether/xen-3.1.0-src/xen/common/built_in.=
o /home/user/ether/xen-3.1.0-src/xen/drivers/built_in.o /home/user/ether/xe=
n-3.1.0-src/xen/arch/x86/built_in.o \

          /home/user/ether/xen-3.1.0-src/xen/common/symbols-dummy.o -o /hom=
e/user/ether/xen-3.1.0-src/xen/.xen-syms.0

/home/user/ether/xen-3.1.0-src/xen/arch/x86/built_in.o: In function `do_inv=
alid_op':

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:631: undefined referenc=
e to `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:631: relocation truncat=
ed to fit: R_X86_64_PLT32 against undefined symbol `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:648: undefined referenc=
e to `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:648: relocation truncat=
ed to fit: R_X86_64_PLT32 against undefined symbol `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:675: undefined referenc=
e to `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:675: relocation truncat=
ed to fit: R_X86_64_PLT32 against undefined symbol `memcmp'

make[4]: *** [/home/user/ether/xen-3.1.0-src/xen/xen-syms] Error 1

make[4]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen/arch/x86'

make[3]: *** [/home/user/ether/xen-3.1.0-src/xen/xen] Error 2

make[3]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen'

make[2]: *** [install] Error 2

make[2]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen'

make[1]: *** [install-xen] Error 2

make[1]: Leaving directory `/home/user/ether/xen-3.1.0-src'

make: *** [world] Error 2


I'm not sure what this means and several other posts have stated it is a co=
mpiler problem and to use gcc-4.1. However, even using 4.1 returns the same=
 errors.

--_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hello everyone. This is my first time attempting to =
use Xen and I am having some problems. I am trying to build a Xen system so=
 that I can use the Ether program for malware analysis (<a href=3D"http://e=
ther.gtisc.gatech.edu/source.html">http://ether.gtisc.gatech.edu/source.htm=
l</a>).<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I&#8217;ve installed Debian 6, and downloaded the Xe=
n 3.1.0 source. However when I try to compile the source using &#8220;make =
world&#8221; I receive the following errors:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">make[5]: Entering directory `/home/user/ether/xen=
-3.1.0-src/xen/arch/x86'<o:p></o:p></p>
<p class=3D"MsoPlainText">gcc -O2 -fomit-frame-pointer -m64 -DNDEBUG -std=
=3Dgnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-st=
atement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefi=
x include -Werror -Wno-pointer-arith -pipe
 -I/home/user/ether/xen-3.1.0-src/xen/include -I/home/user/ether/xen-3.1.0-=
src/xen/include/asm-x86/mach-generic -I/home/user/ether/xen-3.1.0-src/xen/i=
nclude/asm-x86/mach-default -msoft-float -fno-stack-protector -mno-red-zone=
 -fpic -fno-reorder-blocks -fno-asynchronous-unwind-tables
 -DGCC_HAS_VISIBILITY_ATTRIBUTE -g -D__XEN__ -c /home/user/ether/xen-3.1.0-=
src/xen/common/symbols-dummy.c -o /home/user/ether/xen-3.1.0-src/xen/common=
/symbols-dummy.o<o:p></o:p></p>
<p class=3D"MsoPlainText">make[5]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen/arch/x86'<o:p></o:p></p>
<p class=3D"MsoPlainText">ld -melf_x86_64 -T xen.lds -N \<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=
 boot/x86_64.o /home/user/ether/xen-3.1.0-src/xen/common/built_in.o /home/u=
ser/ether/xen-3.1.0-src/xen/drivers/built_in.o /home/user/ether/xen-3.1.0-s=
rc/xen/arch/x86/built_in.o \<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=
 /home/user/ether/xen-3.1.0-src/xen/common/symbols-dummy.o -o /home/user/et=
her/xen-3.1.0-src/xen/.xen-syms.0<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/built=
_in.o: In function `do_invalid_op':<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:631: undefined reference to `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:631: relocation truncated to fit: R_X86_64_PLT32 against undefined symbo=
l `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:648: undefined reference to `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:648: relocation truncated to fit: R_X86_64_PLT32 against undefined symbo=
l `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:675: undefined reference to `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:675: relocation truncated to fit: R_X86_64_PLT32 against undefined symbo=
l `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[4]: *** [/home/user/ether/xen-3.1.0-src/xen/=
xen-syms] Error 1<o:p></o:p></p>
<p class=3D"MsoPlainText">make[4]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen/arch/x86'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[3]: *** [/home/user/ether/xen-3.1.0-src/xen/=
xen] Error 2<o:p></o:p></p>
<p class=3D"MsoPlainText">make[3]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[2]: *** [install] Error 2<o:p></o:p></p>
<p class=3D"MsoPlainText">make[2]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[1]: *** [install-xen] Error 2<o:p></o:p></p>
<p class=3D"MsoPlainText">make[1]: Leaving directory `/home/user/ether/xen-=
3.1.0-src'<o:p></o:p></p>
<p class=3D"MsoPlainText">make: *** [world] Error 2<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I&#8217;m not sure what this means and several other=
 posts have stated it is a compiler problem and to use gcc-4.1. However, ev=
en using 4.1 returns the same errors.<o:p></o:p></p>
</div>
</body>
</html>

--_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_--


--===============2768798327644744403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2768798327644744403==--


From xen-devel-bounces@lists.xen.org Wed Apr 18 20:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 20:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKbdX-0000jk-7z; Wed, 18 Apr 2012 20:37:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=0455459ea1=khamlin@ncfta.net>)
	id 1SKbdV-0000jf-9X
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 20:37:57 +0000
Received: from [85.158.143.99:29947] by server-1.bemta-4.messagelabs.com id
	2D/1B-20925-4262F8F4; Wed, 18 Apr 2012 20:37:56 +0000
X-Env-Sender: prvs=0455459ea1=khamlin@ncfta.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334781474!24228364!1
X-Originating-IP: [8.28.216.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_60_70,
	HTML_ATTR_UNIQUE,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7721 invoked from network); 18 Apr 2012 20:37:55 -0000
Received: from mail.ncfta.net (HELO mail.ncfta.net) (8.28.216.12)
	by server-15.tower-216.messagelabs.com with SMTP;
	18 Apr 2012 20:37:55 -0000
Received-SPF: none (caradhras.ncfta.net: domain of khamlin@ncfta.net does not
	designate permitted sender hosts)
Received: from caradhras.ncfta.net (caradhras.ncfta.net [172.16.8.8]) by
	mail.ncfta.net with smtp
	id 7f75_1a79_4efc203d_496c_47fe_bc63_6456dd354c76;
	Wed, 18 Apr 2012 16:37:53 -0400
Received: from Exchange01.pg.ncfta.net ([10.1.2.116])
	by caradhras.ncfta.net (8.14.4/8.14.4) with ESMTP id q3IKbrjC013208
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 16:37:54 -0400
Received: from Exchange01.pg.ncfta.net ([::1]) by Exchange01.pg.ncfta.net
	([::1]) with mapi id 14.02.0247.003; Wed, 18 Apr 2012 16:38:01 -0400
From: Ken Hamlin <khamlin@ncfta.net>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Ether setup
Thread-Index: Ac0doyRWAAZ/bhF4RTekCusuJeK8Xg==
Date: Wed, 18 Apr 2012 20:37:59 +0000
Message-ID: <FD6F285E37447D4DBB72A9E73C1BD4A2065AD672@Exchange01.pg.ncfta.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.5.109]
MIME-Version: 1.0
Subject: [Xen-devel] Ether setup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2768798327644744403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2768798327644744403==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_"

--_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello everyone. This is my first time attempting to use Xen and I am having=
 some problems. I am trying to build a Xen system so that I can use the Eth=
er program for malware analysis (http://ether.gtisc.gatech.edu/source.html)=
.

I've installed Debian 6, and downloaded the Xen 3.1.0 source. However when =
I try to compile the source using "make world" I receive the following erro=
rs:


make[5]: Entering directory `/home/user/ether/xen-3.1.0-src/xen/arch/x86'

gcc -O2 -fomit-frame-pointer -m64 -DNDEBUG -std=3Dgnu99 -Wall -Wstrict-prot=
otypes -Wno-unused-value -Wdeclaration-after-statement -nostdinc -fno-built=
in -fno-common -fno-strict-aliasing -iwithprefix include -Werror -Wno-point=
er-arith -pipe -I/home/user/ether/xen-3.1.0-src/xen/include -I/home/user/et=
her/xen-3.1.0-src/xen/include/asm-x86/mach-generic -I/home/user/ether/xen-3=
.1.0-src/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector=
 -mno-red-zone -fpic -fno-reorder-blocks -fno-asynchronous-unwind-tables -D=
GCC_HAS_VISIBILITY_ATTRIBUTE -g -D__XEN__ -c /home/user/ether/xen-3.1.0-src=
/xen/common/symbols-dummy.c -o /home/user/ether/xen-3.1.0-src/xen/common/sy=
mbols-dummy.o

make[5]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen/arch/x86'

ld -melf_x86_64 -T xen.lds -N \

          boot/x86_64.o /home/user/ether/xen-3.1.0-src/xen/common/built_in.=
o /home/user/ether/xen-3.1.0-src/xen/drivers/built_in.o /home/user/ether/xe=
n-3.1.0-src/xen/arch/x86/built_in.o \

          /home/user/ether/xen-3.1.0-src/xen/common/symbols-dummy.o -o /hom=
e/user/ether/xen-3.1.0-src/xen/.xen-syms.0

/home/user/ether/xen-3.1.0-src/xen/arch/x86/built_in.o: In function `do_inv=
alid_op':

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:631: undefined referenc=
e to `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:631: relocation truncat=
ed to fit: R_X86_64_PLT32 against undefined symbol `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:648: undefined referenc=
e to `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:648: relocation truncat=
ed to fit: R_X86_64_PLT32 against undefined symbol `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:675: undefined referenc=
e to `memcmp'

/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:675: relocation truncat=
ed to fit: R_X86_64_PLT32 against undefined symbol `memcmp'

make[4]: *** [/home/user/ether/xen-3.1.0-src/xen/xen-syms] Error 1

make[4]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen/arch/x86'

make[3]: *** [/home/user/ether/xen-3.1.0-src/xen/xen] Error 2

make[3]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen'

make[2]: *** [install] Error 2

make[2]: Leaving directory `/home/user/ether/xen-3.1.0-src/xen'

make[1]: *** [install-xen] Error 2

make[1]: Leaving directory `/home/user/ether/xen-3.1.0-src'

make: *** [world] Error 2


I'm not sure what this means and several other posts have stated it is a co=
mpiler problem and to use gcc-4.1. However, even using 4.1 returns the same=
 errors.

--_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hello everyone. This is my first time attempting to =
use Xen and I am having some problems. I am trying to build a Xen system so=
 that I can use the Ether program for malware analysis (<a href=3D"http://e=
ther.gtisc.gatech.edu/source.html">http://ether.gtisc.gatech.edu/source.htm=
l</a>).<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I&#8217;ve installed Debian 6, and downloaded the Xe=
n 3.1.0 source. However when I try to compile the source using &#8220;make =
world&#8221; I receive the following errors:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">make[5]: Entering directory `/home/user/ether/xen=
-3.1.0-src/xen/arch/x86'<o:p></o:p></p>
<p class=3D"MsoPlainText">gcc -O2 -fomit-frame-pointer -m64 -DNDEBUG -std=
=3Dgnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-st=
atement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefi=
x include -Werror -Wno-pointer-arith -pipe
 -I/home/user/ether/xen-3.1.0-src/xen/include -I/home/user/ether/xen-3.1.0-=
src/xen/include/asm-x86/mach-generic -I/home/user/ether/xen-3.1.0-src/xen/i=
nclude/asm-x86/mach-default -msoft-float -fno-stack-protector -mno-red-zone=
 -fpic -fno-reorder-blocks -fno-asynchronous-unwind-tables
 -DGCC_HAS_VISIBILITY_ATTRIBUTE -g -D__XEN__ -c /home/user/ether/xen-3.1.0-=
src/xen/common/symbols-dummy.c -o /home/user/ether/xen-3.1.0-src/xen/common=
/symbols-dummy.o<o:p></o:p></p>
<p class=3D"MsoPlainText">make[5]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen/arch/x86'<o:p></o:p></p>
<p class=3D"MsoPlainText">ld -melf_x86_64 -T xen.lds -N \<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=
 boot/x86_64.o /home/user/ether/xen-3.1.0-src/xen/common/built_in.o /home/u=
ser/ether/xen-3.1.0-src/xen/drivers/built_in.o /home/user/ether/xen-3.1.0-s=
rc/xen/arch/x86/built_in.o \<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=
 /home/user/ether/xen-3.1.0-src/xen/common/symbols-dummy.o -o /home/user/et=
her/xen-3.1.0-src/xen/.xen-syms.0<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/built=
_in.o: In function `do_invalid_op':<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:631: undefined reference to `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:631: relocation truncated to fit: R_X86_64_PLT32 against undefined symbo=
l `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:648: undefined reference to `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:648: relocation truncated to fit: R_X86_64_PLT32 against undefined symbo=
l `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:675: undefined reference to `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">/home/user/ether/xen-3.1.0-src/xen/arch/x86/traps=
.c:675: relocation truncated to fit: R_X86_64_PLT32 against undefined symbo=
l `memcmp'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[4]: *** [/home/user/ether/xen-3.1.0-src/xen/=
xen-syms] Error 1<o:p></o:p></p>
<p class=3D"MsoPlainText">make[4]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen/arch/x86'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[3]: *** [/home/user/ether/xen-3.1.0-src/xen/=
xen] Error 2<o:p></o:p></p>
<p class=3D"MsoPlainText">make[3]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[2]: *** [install] Error 2<o:p></o:p></p>
<p class=3D"MsoPlainText">make[2]: Leaving directory `/home/user/ether/xen-=
3.1.0-src/xen'<o:p></o:p></p>
<p class=3D"MsoPlainText">make[1]: *** [install-xen] Error 2<o:p></o:p></p>
<p class=3D"MsoPlainText">make[1]: Leaving directory `/home/user/ether/xen-=
3.1.0-src'<o:p></o:p></p>
<p class=3D"MsoPlainText">make: *** [world] Error 2<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I&#8217;m not sure what this means and several other=
 posts have stated it is a compiler problem and to use gcc-4.1. However, ev=
en using 4.1 returns the same errors.<o:p></o:p></p>
</div>
</body>
</html>

--_000_FD6F285E37447D4DBB72A9E73C1BD4A2065AD672Exchange01pgncf_--


--===============2768798327644744403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2768798327644744403==--


From xen-devel-bounces@lists.xen.org Wed Apr 18 20:44:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 20:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKbjY-00013T-9K; Wed, 18 Apr 2012 20:44:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SKbjX-00013O-68
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 20:44:11 +0000
Received: from [85.158.143.99:48797] by server-3.bemta-4.messagelabs.com id
	7E/66-05853-A972F8F4; Wed, 18 Apr 2012 20:44:10 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334781847!24197810!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9088 invoked from network); 18 Apr 2012 20:44:09 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 20:44:09 -0000
Received: by pbcuo5 with SMTP id uo5so9715524pbc.32
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 13:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=cqy8JQZcFwiWsruuRtiF8Bq5YLqNm+4YRATH7iT8UzU=;
	b=YSphGDNvmbT0OqY6WjAq92ycX5MwaR23Qb3Aqa5vMg/HpxijqRiBHb18cPfl8zvj5X
	g8cD0w/2KPn4IOCOUyCmXJffD/Wmzs/ErliGVGbowbDMj/OQik5qMcNb/Ig7MdI7NppM
	DwzUJgUV70ZGHqLn8H1Z0rQLQT6FrEqVJgXC9EBdRKc9bZB9DM4ZDTe+QT/MYDHH/zNp
	Y7kzaMo/rGCSzm6SlL1Kww+ZX2Ap+UjxM3lLUT8LIa5/sxQWHn3grjGgdrbOTdcsBbb+
	+CflPJurzIF8Vt8ErLmC4XfEtc4l3/6w2R5MiPtsSFIp6s2C88uL+FDgtbnXn8dI12sl
	NmnQ==
MIME-Version: 1.0
Received: by 10.68.216.6 with SMTP id om6mr9218065pbc.117.1334781846691; Wed,
	18 Apr 2012 13:44:06 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 18 Apr 2012 13:44:06 -0700 (PDT)
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Date: Thu, 19 Apr 2012 04:44:06 +0800
Message-ID: <CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=047d7b338ed7d320e104bdfa1df2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--047d7b338ed7d320e104bdfa1df2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

I don't know whether can non-commit xen-unstable be considered for
backport so I am trying since deadline is before coming Friday 20
April 2012.

libxl/xend: name tap devices with a xentap prefix

Reference: http://lists.xen.org/archives/html/xen-devel/2012-04/msg01223.html

My backport has a modification as stated in
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01374.html
about the line:

vifname = "xen-" + vifname

to:

vifname = "xentap-" + vifname

The backport patch is attached and tested with xen-4.1-testing
changeset 23283:494aa5ecd2e1 using xm and xl.

Thanks.

Kindest regards,
Giam Teck Choon

--047d7b338ed7d320e104bdfa1df2
Content-Type: application/octet-stream; 
	name="rename-net-tap-to-xentap.patch"
Content-Disposition: attachment; filename="rename-net-tap-to-xentap.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h16umehf0

bGlieGwveGVuZDogbmFtZSB0YXAgZGV2aWNlcyB3aXRoIGEgeGVudGFwIHByZWZpeAoKVGhpcyBw
cmV2ZW50cyB0aGUgdWRldiBzY3JpcHRzIGZyb20gb3BlcmF0aW5nIG9uIG90aGVyIHRhcCBkZXZp
Y2VzIChlLmcuCm9wZW52cG4gZXRjKQoKQWxzbyBhZGQgInhlbnRhcC0iIHByZWZpeCB0byB0aGUg
dGFwIGRldmljZSB3aGVuIGFuIGV4cGxpY2l0IG5hbWUgaXMgZ2l2ZW4gdG8KYXZvaWQgYSBjb25m
bGljdCB3aXRoIHRoZSB2aWYgZGV2aWNlLCB3aGljaCB3b3VsZCBvdGhlcndpc2UgaGF2ZSB0aGUg
c2FtZSBuYW1lLgpMaWtld2lzZSBjb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGlzIG9w
dGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAp0byBIVk0gdGFwIGRldmljZXMgb25seS4K
ClJlcG9ydGVkIGJ5IE1pY2hhZWwgWW91bmcuCgpCYWNrcG9ydCBmcm9tIGh0dHA6Ly9saXN0cy54
ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDQvbXNnMDEyMjMuaHRtbAoKU2ln
bmVkLW9mZi1ieTogR2lhbSBUZWNrIENob29uIDxnaWFtdGVja2Nob29uQGdtYWlsLmNvbT4KLS0t
CiB0b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2ggICAgIHwgICAgNCArKy0tCiB0b29s
cy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzIHwgICAgMiArLQogdG9vbHMvbGlieGwv
bGlieGxfZG0uYyAgICAgICAgICAgICAgICB8ICAgIDggKysrKy0tLS0KIHRvb2xzL3B5dGhvbi94
ZW4veGVuZC9pbWFnZS5weSAgICAgICAgfCAgICA0ICsrLS0KIDQgZmlsZXMgY2hhbmdlZCwgOSBp
bnNlcnRpb25zKCspLCA5IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3Rvb2xzL2hvdHBsdWcv
TGludXgvdmlmLWNvbW1vbi5zaCBiL3Rvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaApp
bmRleCBjOWM1ZDQxLi4yM2JlMjM4IDEwMDY0NAotLS0gYS90b29scy9ob3RwbHVnL0xpbnV4L3Zp
Zi1jb21tb24uc2gKKysrIGIvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29tbW9uLnNoCkBAIC04
NSw4ICs4NSw4IEBAIGVsaWYgWyAiJHR5cGVfaWYiID0gdGFwIF07IHRoZW4KICAgICA6ICR7SU5U
RVJGQUNFOj99CiAKICAgICAjIEdldCB4ZW5idXNfcGF0aCBmcm9tIGRldmljZSBuYW1lLgotICAg
ICMgVGhlIG5hbWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAidGFwJHtkb21pZH0uJHtkZXZpZH0iLgot
ICAgIGRldl89JHtkZXYjdGFwfQorICAgICMgVGhlIG5hbWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAi
eGVudGFwJHtkb21pZH0uJHtkZXZpZH0iLgorICAgIGRldl89JHtkZXYjeGVudGFwfQogICAgIGRv
bWlkPSR7ZGV2XyUuKn0KICAgICBkZXZpZD0ke2Rldl8jKi59CiAKZGlmZiAtLWdpdCBhL3Rvb2xz
L2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMgYi90b29scy9ob3RwbHVnL0xpbnV4L3hl
bi1iYWNrZW5kLnJ1bGVzCmluZGV4IDQwZjI2NTguLjE5YmQwZmEgMTAwNjQ0Ci0tLSBhL3Rvb2xz
L2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMKKysrIGIvdG9vbHMvaG90cGx1Zy9MaW51
eC94ZW4tYmFja2VuZC5ydWxlcwpAQCAtMTMsNCArMTMsNCBAQCBLRVJORUw9PSJibGt0YXAtY29u
dHJvbCIsIE5BTUU9Inhlbi9ibGt0YXAtMi9jb250cm9sIiwgTU9ERT0iMDYwMCIKIEtFUk5FTD09
ImdudGRldiIsIE5BTUU9Inhlbi8layIsIE1PREU9IjA2MDAiCiBLRVJORUw9PSJwY2lfaW9tdWwi
LCBOQU1FPSJ4ZW4vJWsiLCBNT0RFPSIwNjAwIgogS0VSTkVMPT0idGFwZGV2W2Etel0qIiwgTkFN
RT0ieGVuL2Jsa3RhcC0yL3RhcGRldiVtIiwgTU9ERT0iMDYwMCIKLVNVQlNZU1RFTT09Im5ldCIs
IEtFUk5FTD09InRhcCoiLCBBQ1RJT049PSJhZGQiLCBSVU4rPSIvZXRjL3hlbi9zY3JpcHRzL3Zp
Zi1zZXR1cCAkZW52e0FDVElPTn0gdHlwZV9pZj10YXAiCitTVUJTWVNURU09PSJuZXQiLCBLRVJO
RUw9PSJ4ZW50YXAqIiwgQUNUSU9OPT0iYWRkIiwgUlVOKz0iL2V0Yy94ZW4vc2NyaXB0cy92aWYt
c2V0dXAgJGVudntBQ1RJT059IHR5cGVfaWY9dGFwIgpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwv
bGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMKaW5kZXggMWZmY2M5MC4uMTE3MDc3
NSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYworKysgYi90b29scy9saWJ4bC9s
aWJ4bF9kbS5jCkBAIC0xMzYsOSArMTM2LDkgQEAgc3RhdGljIGNoYXIgKiogbGlieGxfYnVpbGRf
ZGV2aWNlX21vZGVsX2FyZ3Nfb2xkKGxpYnhsX19nYyAqZ2MsCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdmlmc1tpXS5tYWNbM10sIHZpZnNbaV0ubWFjWzRdLCB2
aWZzW2ldLm1hY1s1XSk7CiAgICAgICAgICAgICAgICAgY2hhciAqaWZuYW1lOwogICAgICAgICAg
ICAgICAgIGlmICghdmlmc1tpXS5pZm5hbWUpCi0gICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9
IGxpYnhsX19zcHJpbnRmKGdjLCAidGFwJWQuJWQiLCBpbmZvLT5kb21pZCwgdmlmc1tpXS5kZXZp
ZCk7CisgICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdjLCAieGVu
dGFwJWQuJWQiLCBpbmZvLT5kb21pZCwgdmlmc1tpXS5kZXZpZCk7CiAgICAgICAgICAgICAgICAg
ZWxzZQotICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlmbmFtZTsKKyAgICAg
ICAgICAgICAgICAgICAgaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ4ZW50YXAtJXMiLCB2
aWZzW2ldLmlmbmFtZSk7CiAgICAgICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBlbmQoZG1fYXJn
cywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIi1uZXQiLCBsaWJ4bF9fc3ByaW50
ZihnYywgIm5pYyx2bGFuPSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiLAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQsIHNt
YWMsIHZpZnNbaV0ubW9kZWwpLApAQCAtMjczLDkgKzI3Myw5IEBAIHN0YXRpYyBjaGFyICoqIGxp
YnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdzX25ldyhsaWJ4bF9fZ2MgKmdjLAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0ubWFjWzNdLCB2aWZzW2ld
Lm1hY1s0XSwgdmlmc1tpXS5tYWNbNV0pOwogICAgICAgICAgICAgICAgIGNoYXIgKmlmbmFtZTsK
ICAgICAgICAgICAgICAgICBpZiAoIXZpZnNbaV0uaWZuYW1lKSB7Ci0gICAgICAgICAgICAgICAg
ICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdjLCAidGFwJWQuJWQiLCBpbmZvLT5kb21pZCwg
dmlmc1tpXS5kZXZpZCk7CisgICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJp
bnRmKGdjLCAieGVudGFwJWQuJWQiLCBpbmZvLT5kb21pZCwgdmlmc1tpXS5kZXZpZCk7CiAgICAg
ICAgICAgICAgICAgfSBlbHNlIHsKLSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gdmlmc1tp
XS5pZm5hbWU7CisgICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdj
LCAieGVudGFwLSVzIiwgdmlmc1tpXS5pZm5hbWUpOwogICAgICAgICAgICAgICAgIH0KICAgICAg
ICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItbmV0Iik7CiAgICAgICAgICAg
ICAgICAgZmxleGFycmF5X2FwcGVuZChkbV9hcmdzLCBsaWJ4bF9fc3ByaW50ZihnYywgIm5pYyx2
bGFuPSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiLApkaWZmIC0tZ2l0IGEvdG9vbHMvcHl0aG9uL3hl
bi94ZW5kL2ltYWdlLnB5IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdlLnB5CmluZGV4IGYx
NDY0YWMuLmEwN2JmNjkgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5w
eQorKysgYi90b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkKQEAgLTkxOSw5ICs5MTksOSBA
QCBjbGFzcyBIVk1JbWFnZUhhbmRsZXIoSW1hZ2VIYW5kbGVyKToKICAgICAgICAgICAgICAgICAg
ICAgICAgKG5pY3MsIG1hYywgbW9kZWwpKQogICAgICAgICAgICAgdmlmbmFtZSA9IGRldmluZm8u
Z2V0KCd2aWZuYW1lJykKICAgICAgICAgICAgIGlmIHZpZm5hbWU6Ci0gICAgICAgICAgICAgICAg
dmlmbmFtZSA9ICJ0YXAtIiArIHZpZm5hbWUKKyAgICAgICAgICAgICAgICB2aWZuYW1lID0gInhl
bnRhcC0iICsgdmlmbmFtZQogICAgICAgICAgICAgZWxzZToKLSAgICAgICAgICAgICAgICB2aWZu
YW1lID0gInRhcCVkLiVkIiAlIChzZWxmLnZtLmdldERvbWlkKCksIG5pY3MtMSkKKyAgICAgICAg
ICAgICAgICB2aWZuYW1lID0gInhlbnRhcCVkLiVkIiAlIChzZWxmLnZtLmdldERvbWlkKCksIG5p
Y3MtMSkKICAgICAgICAgICAgIHJldC5hcHBlbmQoIi1uZXQiKQogICAgICAgICAgICAgcmV0LmFw
cGVuZCgidGFwLHZsYW49JWQsaWZuYW1lPSVzLGJyaWRnZT0lcyIgJQogICAgICAgICAgICAgICAg
ICAgICAgICAobmljcywgdmlmbmFtZSwgYnJpZGdlKSkK
--047d7b338ed7d320e104bdfa1df2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b338ed7d320e104bdfa1df2--


From xen-devel-bounces@lists.xen.org Wed Apr 18 20:44:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 20:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKbjY-00013T-9K; Wed, 18 Apr 2012 20:44:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SKbjX-00013O-68
	for xen-devel@lists.xen.org; Wed, 18 Apr 2012 20:44:11 +0000
Received: from [85.158.143.99:48797] by server-3.bemta-4.messagelabs.com id
	7E/66-05853-A972F8F4; Wed, 18 Apr 2012 20:44:10 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334781847!24197810!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9088 invoked from network); 18 Apr 2012 20:44:09 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 20:44:09 -0000
Received: by pbcuo5 with SMTP id uo5so9715524pbc.32
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 13:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=cqy8JQZcFwiWsruuRtiF8Bq5YLqNm+4YRATH7iT8UzU=;
	b=YSphGDNvmbT0OqY6WjAq92ycX5MwaR23Qb3Aqa5vMg/HpxijqRiBHb18cPfl8zvj5X
	g8cD0w/2KPn4IOCOUyCmXJffD/Wmzs/ErliGVGbowbDMj/OQik5qMcNb/Ig7MdI7NppM
	DwzUJgUV70ZGHqLn8H1Z0rQLQT6FrEqVJgXC9EBdRKc9bZB9DM4ZDTe+QT/MYDHH/zNp
	Y7kzaMo/rGCSzm6SlL1Kww+ZX2Ap+UjxM3lLUT8LIa5/sxQWHn3grjGgdrbOTdcsBbb+
	+CflPJurzIF8Vt8ErLmC4XfEtc4l3/6w2R5MiPtsSFIp6s2C88uL+FDgtbnXn8dI12sl
	NmnQ==
MIME-Version: 1.0
Received: by 10.68.216.6 with SMTP id om6mr9218065pbc.117.1334781846691; Wed,
	18 Apr 2012 13:44:06 -0700 (PDT)
Received: by 10.68.227.66 with HTTP; Wed, 18 Apr 2012 13:44:06 -0700 (PDT)
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Date: Thu, 19 Apr 2012 04:44:06 +0800
Message-ID: <CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=047d7b338ed7d320e104bdfa1df2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--047d7b338ed7d320e104bdfa1df2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

I don't know whether can non-commit xen-unstable be considered for
backport so I am trying since deadline is before coming Friday 20
April 2012.

libxl/xend: name tap devices with a xentap prefix

Reference: http://lists.xen.org/archives/html/xen-devel/2012-04/msg01223.html

My backport has a modification as stated in
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01374.html
about the line:

vifname = "xen-" + vifname

to:

vifname = "xentap-" + vifname

The backport patch is attached and tested with xen-4.1-testing
changeset 23283:494aa5ecd2e1 using xm and xl.

Thanks.

Kindest regards,
Giam Teck Choon

--047d7b338ed7d320e104bdfa1df2
Content-Type: application/octet-stream; 
	name="rename-net-tap-to-xentap.patch"
Content-Disposition: attachment; filename="rename-net-tap-to-xentap.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h16umehf0

bGlieGwveGVuZDogbmFtZSB0YXAgZGV2aWNlcyB3aXRoIGEgeGVudGFwIHByZWZpeAoKVGhpcyBw
cmV2ZW50cyB0aGUgdWRldiBzY3JpcHRzIGZyb20gb3BlcmF0aW5nIG9uIG90aGVyIHRhcCBkZXZp
Y2VzIChlLmcuCm9wZW52cG4gZXRjKQoKQWxzbyBhZGQgInhlbnRhcC0iIHByZWZpeCB0byB0aGUg
dGFwIGRldmljZSB3aGVuIGFuIGV4cGxpY2l0IG5hbWUgaXMgZ2l2ZW4gdG8KYXZvaWQgYSBjb25m
bGljdCB3aXRoIHRoZSB2aWYgZGV2aWNlLCB3aGljaCB3b3VsZCBvdGhlcndpc2UgaGF2ZSB0aGUg
c2FtZSBuYW1lLgpMaWtld2lzZSBjb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGlzIG9w
dGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAp0byBIVk0gdGFwIGRldmljZXMgb25seS4K
ClJlcG9ydGVkIGJ5IE1pY2hhZWwgWW91bmcuCgpCYWNrcG9ydCBmcm9tIGh0dHA6Ly9saXN0cy54
ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDQvbXNnMDEyMjMuaHRtbAoKU2ln
bmVkLW9mZi1ieTogR2lhbSBUZWNrIENob29uIDxnaWFtdGVja2Nob29uQGdtYWlsLmNvbT4KLS0t
CiB0b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2ggICAgIHwgICAgNCArKy0tCiB0b29s
cy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzIHwgICAgMiArLQogdG9vbHMvbGlieGwv
bGlieGxfZG0uYyAgICAgICAgICAgICAgICB8ICAgIDggKysrKy0tLS0KIHRvb2xzL3B5dGhvbi94
ZW4veGVuZC9pbWFnZS5weSAgICAgICAgfCAgICA0ICsrLS0KIDQgZmlsZXMgY2hhbmdlZCwgOSBp
bnNlcnRpb25zKCspLCA5IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3Rvb2xzL2hvdHBsdWcv
TGludXgvdmlmLWNvbW1vbi5zaCBiL3Rvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaApp
bmRleCBjOWM1ZDQxLi4yM2JlMjM4IDEwMDY0NAotLS0gYS90b29scy9ob3RwbHVnL0xpbnV4L3Zp
Zi1jb21tb24uc2gKKysrIGIvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29tbW9uLnNoCkBAIC04
NSw4ICs4NSw4IEBAIGVsaWYgWyAiJHR5cGVfaWYiID0gdGFwIF07IHRoZW4KICAgICA6ICR7SU5U
RVJGQUNFOj99CiAKICAgICAjIEdldCB4ZW5idXNfcGF0aCBmcm9tIGRldmljZSBuYW1lLgotICAg
ICMgVGhlIG5hbWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAidGFwJHtkb21pZH0uJHtkZXZpZH0iLgot
ICAgIGRldl89JHtkZXYjdGFwfQorICAgICMgVGhlIG5hbWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAi
eGVudGFwJHtkb21pZH0uJHtkZXZpZH0iLgorICAgIGRldl89JHtkZXYjeGVudGFwfQogICAgIGRv
bWlkPSR7ZGV2XyUuKn0KICAgICBkZXZpZD0ke2Rldl8jKi59CiAKZGlmZiAtLWdpdCBhL3Rvb2xz
L2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMgYi90b29scy9ob3RwbHVnL0xpbnV4L3hl
bi1iYWNrZW5kLnJ1bGVzCmluZGV4IDQwZjI2NTguLjE5YmQwZmEgMTAwNjQ0Ci0tLSBhL3Rvb2xz
L2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMKKysrIGIvdG9vbHMvaG90cGx1Zy9MaW51
eC94ZW4tYmFja2VuZC5ydWxlcwpAQCAtMTMsNCArMTMsNCBAQCBLRVJORUw9PSJibGt0YXAtY29u
dHJvbCIsIE5BTUU9Inhlbi9ibGt0YXAtMi9jb250cm9sIiwgTU9ERT0iMDYwMCIKIEtFUk5FTD09
ImdudGRldiIsIE5BTUU9Inhlbi8layIsIE1PREU9IjA2MDAiCiBLRVJORUw9PSJwY2lfaW9tdWwi
LCBOQU1FPSJ4ZW4vJWsiLCBNT0RFPSIwNjAwIgogS0VSTkVMPT0idGFwZGV2W2Etel0qIiwgTkFN
RT0ieGVuL2Jsa3RhcC0yL3RhcGRldiVtIiwgTU9ERT0iMDYwMCIKLVNVQlNZU1RFTT09Im5ldCIs
IEtFUk5FTD09InRhcCoiLCBBQ1RJT049PSJhZGQiLCBSVU4rPSIvZXRjL3hlbi9zY3JpcHRzL3Zp
Zi1zZXR1cCAkZW52e0FDVElPTn0gdHlwZV9pZj10YXAiCitTVUJTWVNURU09PSJuZXQiLCBLRVJO
RUw9PSJ4ZW50YXAqIiwgQUNUSU9OPT0iYWRkIiwgUlVOKz0iL2V0Yy94ZW4vc2NyaXB0cy92aWYt
c2V0dXAgJGVudntBQ1RJT059IHR5cGVfaWY9dGFwIgpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwv
bGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMKaW5kZXggMWZmY2M5MC4uMTE3MDc3
NSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYworKysgYi90b29scy9saWJ4bC9s
aWJ4bF9kbS5jCkBAIC0xMzYsOSArMTM2LDkgQEAgc3RhdGljIGNoYXIgKiogbGlieGxfYnVpbGRf
ZGV2aWNlX21vZGVsX2FyZ3Nfb2xkKGxpYnhsX19nYyAqZ2MsCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdmlmc1tpXS5tYWNbM10sIHZpZnNbaV0ubWFjWzRdLCB2
aWZzW2ldLm1hY1s1XSk7CiAgICAgICAgICAgICAgICAgY2hhciAqaWZuYW1lOwogICAgICAgICAg
ICAgICAgIGlmICghdmlmc1tpXS5pZm5hbWUpCi0gICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9
IGxpYnhsX19zcHJpbnRmKGdjLCAidGFwJWQuJWQiLCBpbmZvLT5kb21pZCwgdmlmc1tpXS5kZXZp
ZCk7CisgICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdjLCAieGVu
dGFwJWQuJWQiLCBpbmZvLT5kb21pZCwgdmlmc1tpXS5kZXZpZCk7CiAgICAgICAgICAgICAgICAg
ZWxzZQotICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlmbmFtZTsKKyAgICAg
ICAgICAgICAgICAgICAgaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ4ZW50YXAtJXMiLCB2
aWZzW2ldLmlmbmFtZSk7CiAgICAgICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBlbmQoZG1fYXJn
cywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIi1uZXQiLCBsaWJ4bF9fc3ByaW50
ZihnYywgIm5pYyx2bGFuPSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiLAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQsIHNt
YWMsIHZpZnNbaV0ubW9kZWwpLApAQCAtMjczLDkgKzI3Myw5IEBAIHN0YXRpYyBjaGFyICoqIGxp
YnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdzX25ldyhsaWJ4bF9fZ2MgKmdjLAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0ubWFjWzNdLCB2aWZzW2ld
Lm1hY1s0XSwgdmlmc1tpXS5tYWNbNV0pOwogICAgICAgICAgICAgICAgIGNoYXIgKmlmbmFtZTsK
ICAgICAgICAgICAgICAgICBpZiAoIXZpZnNbaV0uaWZuYW1lKSB7Ci0gICAgICAgICAgICAgICAg
ICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdjLCAidGFwJWQuJWQiLCBpbmZvLT5kb21pZCwg
dmlmc1tpXS5kZXZpZCk7CisgICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJp
bnRmKGdjLCAieGVudGFwJWQuJWQiLCBpbmZvLT5kb21pZCwgdmlmc1tpXS5kZXZpZCk7CiAgICAg
ICAgICAgICAgICAgfSBlbHNlIHsKLSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gdmlmc1tp
XS5pZm5hbWU7CisgICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdj
LCAieGVudGFwLSVzIiwgdmlmc1tpXS5pZm5hbWUpOwogICAgICAgICAgICAgICAgIH0KICAgICAg
ICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItbmV0Iik7CiAgICAgICAgICAg
ICAgICAgZmxleGFycmF5X2FwcGVuZChkbV9hcmdzLCBsaWJ4bF9fc3ByaW50ZihnYywgIm5pYyx2
bGFuPSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiLApkaWZmIC0tZ2l0IGEvdG9vbHMvcHl0aG9uL3hl
bi94ZW5kL2ltYWdlLnB5IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdlLnB5CmluZGV4IGYx
NDY0YWMuLmEwN2JmNjkgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5w
eQorKysgYi90b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkKQEAgLTkxOSw5ICs5MTksOSBA
QCBjbGFzcyBIVk1JbWFnZUhhbmRsZXIoSW1hZ2VIYW5kbGVyKToKICAgICAgICAgICAgICAgICAg
ICAgICAgKG5pY3MsIG1hYywgbW9kZWwpKQogICAgICAgICAgICAgdmlmbmFtZSA9IGRldmluZm8u
Z2V0KCd2aWZuYW1lJykKICAgICAgICAgICAgIGlmIHZpZm5hbWU6Ci0gICAgICAgICAgICAgICAg
dmlmbmFtZSA9ICJ0YXAtIiArIHZpZm5hbWUKKyAgICAgICAgICAgICAgICB2aWZuYW1lID0gInhl
bnRhcC0iICsgdmlmbmFtZQogICAgICAgICAgICAgZWxzZToKLSAgICAgICAgICAgICAgICB2aWZu
YW1lID0gInRhcCVkLiVkIiAlIChzZWxmLnZtLmdldERvbWlkKCksIG5pY3MtMSkKKyAgICAgICAg
ICAgICAgICB2aWZuYW1lID0gInhlbnRhcCVkLiVkIiAlIChzZWxmLnZtLmdldERvbWlkKCksIG5p
Y3MtMSkKICAgICAgICAgICAgIHJldC5hcHBlbmQoIi1uZXQiKQogICAgICAgICAgICAgcmV0LmFw
cGVuZCgidGFwLHZsYW49JWQsaWZuYW1lPSVzLGJyaWRnZT0lcyIgJQogICAgICAgICAgICAgICAg
ICAgICAgICAobmljcywgdmlmbmFtZSwgYnJpZGdlKSkK
--047d7b338ed7d320e104bdfa1df2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b338ed7d320e104bdfa1df2--


From xen-devel-bounces@lists.xen.org Wed Apr 18 21:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 21:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKca7-0001Tq-Gf; Wed, 18 Apr 2012 21:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKca6-0001Tl-5r
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 21:38:30 +0000
Received: from [85.158.143.99:35149] by server-2.bemta-4.messagelabs.com id
	0B/57-17550-5543F8F4; Wed, 18 Apr 2012 21:38:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334785107!17880710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4783 invoked from network); 18 Apr 2012 21:38:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 21:38:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,444,1330905600"; d="scan'208";a="12015375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 21:38:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 22:38:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKca2-00034G-Gl;
	Wed, 18 Apr 2012 21:38:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKca2-00027C-FP;
	Wed, 18 Apr 2012 22:38:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12715-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 22:38:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12715: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12715 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12715/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                2adb09687b4cd369983ba4533d6eab857262e1b9
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 2adb09687b4cd369983ba4533d6eab857262e1b9
Merge: ba0ed41... 592fe89...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 18 08:07:52 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 21:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 21:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKca7-0001Tq-Gf; Wed, 18 Apr 2012 21:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKca6-0001Tl-5r
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 21:38:30 +0000
Received: from [85.158.143.99:35149] by server-2.bemta-4.messagelabs.com id
	0B/57-17550-5543F8F4; Wed, 18 Apr 2012 21:38:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334785107!17880710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4783 invoked from network); 18 Apr 2012 21:38:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Apr 2012 21:38:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,444,1330905600"; d="scan'208";a="12015375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Apr 2012 21:38:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Apr 2012 22:38:27 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKca2-00034G-Gl;
	Wed, 18 Apr 2012 21:38:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKca2-00027C-FP;
	Wed, 18 Apr 2012 22:38:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12715-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Apr 2012 22:38:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12715: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12715 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12715/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                2adb09687b4cd369983ba4533d6eab857262e1b9
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 2adb09687b4cd369983ba4533d6eab857262e1b9
Merge: ba0ed41... 592fe89...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 18 08:07:52 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 23:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 23:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKeKV-0002oG-Sz; Wed, 18 Apr 2012 23:30:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SKeKT-0002oB-Sk
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 23:30:30 +0000
Received: from [85.158.139.83:17390] by server-10.bemta-5.messagelabs.com id
	67/02-08260-59E4F8F4; Wed, 18 Apr 2012 23:30:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334791827!23774150!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc3MjQz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20950 invoked from network); 18 Apr 2012 23:30:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Apr 2012 23:30:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3INUJ8s024756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Apr 2012 23:30:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3INUIAG011416
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Apr 2012 23:30:18 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3INUHd8008730; Wed, 18 Apr 2012 18:30:17 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Apr 2012 16:30:17 -0700
Date: Wed, 18 Apr 2012 16:29:08 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120418162908.2b790fae@mantra.us.oracle.com>
In-Reply-To: <1334653528.14560.261.camel@zakaz.uk.xensource.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
	<20120416185340.72ef5566@mantra.us.oracle.com>
	<1334653528.14560.261.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8F4E8C.009A,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012 10:05:28 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
> > On Mon, 16 Apr 2012 14:53:22 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> Sorry, I meant why a whole new subcall instead of a new
> XENMAPSPACE ;-)
> 
> e.g. On ARM I did:
> 
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 86d02c8..b2adfbe 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -212,11 +212,13 @@ struct xen_add_to_physmap {
>      uint16_t    size;
>  
>      /* Source mapping space. */
> -#define XENMAPSPACE_shared_info 0 /* shared info page */
> -#define XENMAPSPACE_grant_table 1 /* grant table page */
> -#define XENMAPSPACE_gmfn        2 /* GMFN */
> -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> -    unsigned int space;
> +#define XENMAPSPACE_shared_info  0 /* shared info page */
> +#define XENMAPSPACE_grant_table  1 /* grant table page */
> +#define XENMAPSPACE_gmfn         2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */


Well, for several reasons, I didn't use it, mainly, it doesn't allow
for count. So requests have to come in one frame at a time. Second,
none of the common code can be used by my new request, because:
   - frame is not removed from foreign domain in my case
   - i don't want to update the m2p with new info.

Anyways, I put it there for now. With ballooning change in dom0, I'm
now doing the hcall one frame at a time anyways. We can always enhance
in the future.

        case XENMAPSPACE_gmfn_foreign:
        {
            rc = _add_foreign_to_pmap_batch(&xatp);
            rcu_unlock_domain(d);
            return rc;
        }


>> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void)
>> arg)  

>Can't XENMEM_remove_from_physmap be used here?

Well, that calls guest_physmap_remove_page() which calls
p2m_remove_page which updates the M2P with INVALID_M2P_ENTRY. Whereas,
i just need to remove from the dom0 p2m and leave M2P as is (mfn to
domU gmfn). I could add a flag to the struct causing it to just call
set_p2m_entry() directly?

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 18 23:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Apr 2012 23:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKeKV-0002oG-Sz; Wed, 18 Apr 2012 23:30:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SKeKT-0002oB-Sk
	for Xen-devel@lists.xensource.com; Wed, 18 Apr 2012 23:30:30 +0000
Received: from [85.158.139.83:17390] by server-10.bemta-5.messagelabs.com id
	67/02-08260-59E4F8F4; Wed, 18 Apr 2012 23:30:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334791827!23774150!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc3MjQz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20950 invoked from network); 18 Apr 2012 23:30:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Apr 2012 23:30:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3INUJ8s024756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Apr 2012 23:30:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3INUIAG011416
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Apr 2012 23:30:18 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3INUHd8008730; Wed, 18 Apr 2012 18:30:17 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Apr 2012 16:30:17 -0700
Date: Wed, 18 Apr 2012 16:29:08 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120418162908.2b790fae@mantra.us.oracle.com>
In-Reply-To: <1334653528.14560.261.camel@zakaz.uk.xensource.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
	<20120416185340.72ef5566@mantra.us.oracle.com>
	<1334653528.14560.261.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F8F4E8C.009A,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012 10:05:28 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
> > On Mon, 16 Apr 2012 14:53:22 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> Sorry, I meant why a whole new subcall instead of a new
> XENMAPSPACE ;-)
> 
> e.g. On ARM I did:
> 
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 86d02c8..b2adfbe 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -212,11 +212,13 @@ struct xen_add_to_physmap {
>      uint16_t    size;
>  
>      /* Source mapping space. */
> -#define XENMAPSPACE_shared_info 0 /* shared info page */
> -#define XENMAPSPACE_grant_table 1 /* grant table page */
> -#define XENMAPSPACE_gmfn        2 /* GMFN */
> -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> -    unsigned int space;
> +#define XENMAPSPACE_shared_info  0 /* shared info page */
> +#define XENMAPSPACE_grant_table  1 /* grant table page */
> +#define XENMAPSPACE_gmfn         2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */


Well, for several reasons, I didn't use it, mainly, it doesn't allow
for count. So requests have to come in one frame at a time. Second,
none of the common code can be used by my new request, because:
   - frame is not removed from foreign domain in my case
   - i don't want to update the m2p with new info.

Anyways, I put it there for now. With ballooning change in dom0, I'm
now doing the hcall one frame at a time anyways. We can always enhance
in the future.

        case XENMAPSPACE_gmfn_foreign:
        {
            rc = _add_foreign_to_pmap_batch(&xatp);
            rcu_unlock_domain(d);
            return rc;
        }


>> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void)
>> arg)  

>Can't XENMEM_remove_from_physmap be used here?

Well, that calls guest_physmap_remove_page() which calls
p2m_remove_page which updates the M2P with INVALID_M2P_ENTRY. Whereas,
i just need to remove from the dom0 p2m and leave M2P as is (mfn to
domU gmfn). I could add a flag to the struct causing it to just call
set_p2m_entry() directly?

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 00:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 00:06:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKesS-0003mn-Au; Thu, 19 Apr 2012 00:05:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKesQ-0003mh-IC
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 00:05:34 +0000
Received: from [85.158.139.83:58054] by server-2.bemta-5.messagelabs.com id
	DB/7E-17016-DC65F8F4; Thu, 19 Apr 2012 00:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334793932!24448782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23042 invoked from network); 19 Apr 2012 00:05:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 00:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12016262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 00:05:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 01:05:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKesN-0003vv-CC;
	Thu, 19 Apr 2012 00:05:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKesN-0002N7-1B;
	Thu, 19 Apr 2012 01:05:31 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12716-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 01:05:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12716: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12716 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12716/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12709

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  e6b20ec1824c
baseline version:
 xen                  6017afc70442

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e6b20ec1824c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e6b20ec1824c
+ branch=xen-unstable
+ revision=e6b20ec1824c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e6b20ec1824c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 13 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 00:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 00:06:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKesS-0003mn-Au; Thu, 19 Apr 2012 00:05:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKesQ-0003mh-IC
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 00:05:34 +0000
Received: from [85.158.139.83:58054] by server-2.bemta-5.messagelabs.com id
	DB/7E-17016-DC65F8F4; Thu, 19 Apr 2012 00:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334793932!24448782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDg5Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23042 invoked from network); 19 Apr 2012 00:05:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 00:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12016262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 00:05:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 01:05:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKesN-0003vv-CC;
	Thu, 19 Apr 2012 00:05:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKesN-0002N7-1B;
	Thu, 19 Apr 2012 01:05:31 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12716-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 01:05:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12716: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12716 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12716/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12709

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  e6b20ec1824c
baseline version:
 xen                  6017afc70442

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e6b20ec1824c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e6b20ec1824c
+ branch=xen-unstable
+ revision=e6b20ec1824c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e6b20ec1824c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 13 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 04:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 04:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKjF9-0002IS-CA; Thu, 19 Apr 2012 04:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Abhinandan.Prateek@citrix.com>) id 1SKjF7-0002IN-O3
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 04:45:17 +0000
Received: from [85.158.143.35:54484] by server-3.bemta-4.messagelabs.com id
	10/20-05853-C589F8F4; Thu, 19 Apr 2012 04:45:16 +0000
X-Env-Sender: Abhinandan.Prateek@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334810712!11651543!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDQ0OTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22153 invoked from network); 19 Apr 2012 04:45:15 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 04:45:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="11152829"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 04:45:11 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Thu, 19 Apr 2012
	10:15:09 +0530
From: Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 19 Apr 2012 10:15:09 +0530
Thread-Topic: XCP 1.5 beta
Thread-Index: Ac0d5pFUVNXjXUZ2ReGBQIAmq/KkKw==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F9155BCD22@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] XCP 1.5 beta
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


We are testing support for XCP 1.5 beta in the cloudstack software. While testing we saw that the method get_mtime is omitted from /opt/xensource/sm/util.py.  This method is present in XCP 1.1.  Is there a reason to do that ? Will it be possible to add it back.

Thanks and Regards,
Abhinandan Prateek


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 04:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 04:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKjF9-0002IS-CA; Thu, 19 Apr 2012 04:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Abhinandan.Prateek@citrix.com>) id 1SKjF7-0002IN-O3
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 04:45:17 +0000
Received: from [85.158.143.35:54484] by server-3.bemta-4.messagelabs.com id
	10/20-05853-C589F8F4; Thu, 19 Apr 2012 04:45:16 +0000
X-Env-Sender: Abhinandan.Prateek@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1334810712!11651543!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDQ0OTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22153 invoked from network); 19 Apr 2012 04:45:15 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 04:45:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="11152829"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 04:45:11 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Thu, 19 Apr 2012
	10:15:09 +0530
From: Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 19 Apr 2012 10:15:09 +0530
Thread-Topic: XCP 1.5 beta
Thread-Index: Ac0d5pFUVNXjXUZ2ReGBQIAmq/KkKw==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F9155BCD22@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] XCP 1.5 beta
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


We are testing support for XCP 1.5 beta in the cloudstack software. While testing we saw that the method get_mtime is omitted from /opt/xensource/sm/util.py.  This method is present in XCP 1.1.  Is there a reason to do that ? Will it be possible to add it back.

Thanks and Regards,
Abhinandan Prateek


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 04:47:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 04:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKjGi-0002LR-TM; Thu, 19 Apr 2012 04:46:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SKjGh-0002LG-02
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 04:46:55 +0000
Received: from [85.158.138.51:4711] by server-2.bemta-3.messagelabs.com id
	0F/F0-09269-EB89F8F4; Thu, 19 Apr 2012 04:46:54 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334810812!22608460!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11948 invoked from network); 19 Apr 2012 04:46:52 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 04:46:52 -0000
Received: by lagr15 with SMTP id r15so6639970lag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 21:46:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type; bh=Yhq+kjhwoGu7KdjAwD+ZRScC6xxJfs5CMkzkX/sHgaY=;
	b=Q9yZROkLE9aFKf0bRFNMPL0S4HdB1FM6OI4G3cln0zRS2BdyiHnNd9WZUVb3crfRIU
	/fOdKvm6LDin9ImPkirCslETUhkNEXvDmAQopiQVU9Fu04oseMdJCHf45Ex3np4zHu4J
	H/DvBukEBh6DUpcr13qzeMDZSFDzX/pYdRoKQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type:x-gm-message-state;
	bh=Yhq+kjhwoGu7KdjAwD+ZRScC6xxJfs5CMkzkX/sHgaY=;
	b=WwZZ4VFrzymLeqp2IOzfErVPLAb9SXgPgur9+euAI6yjAFCG9m29kWoFxas47BeT1c
	a/qgasSHEIUEye4c8BK8zYcI5GSE2d5529xHcvH1T1r+4RK0Lxtu+4LOpGnvkAUJSsK5
	J/IgjGrjJY7pKndDwrpdWcsd1YBu6Dsr37FMHBm77oOcn5jIyl8YNCf13IUpdclD6lsL
	pL5SvdnBxcF17oUPUEXr4Gm2XErLB3SqnU8P+AEmZjYp5FBC+F5kVViQ7JTKI9GOD6Z9
	qkNR8xM2wLiYJ+SUa3DWcZ72j0NGtoJan7xYbxTvjwcymn7fKaXQ+/vfQhWLgQYz2ZCI
	Vq5A==
MIME-Version: 1.0
Received: by 10.152.105.197 with SMTP id go5mr499627lab.43.1334810811646; Wed,
	18 Apr 2012 21:46:51 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Wed, 18 Apr 2012 21:46:51 -0700 (PDT)
X-Originating-IP: [108.92.21.169]
Date: Wed, 18 Apr 2012 21:46:51 -0700
Message-ID: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQndelbdTt7CCkVdVdIn9UILG1MXBCK/Wh3U2lNdMJg9jpyeA8hGyAmkt/bLIX1wWXycIAKW
Subject: [Xen-devel] [PATCH] xen-access: Check return values and clean up on
	errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check the return values of the libxc mem_access calls.
Free allocated structures (platform_info, domain_info) on errors
during initialization and exit
Unbind VIRQ, close event channel and connection to Xen on errors
during initialization

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

---

 tools/tests/xen-access/xen-access.c |  172 +++++++++++++++++++++++------------
 1 files changed, 114 insertions(+), 58 deletions(-)

diff -r a06e6cdeafe3 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c	Mon Apr 16 13:05:28 2012 +0200
+++ b/tools/tests/xen-access/xen-access.c	Wed Apr 18 21:30:17 2012 -0700
@@ -29,6 +29,7 @@
 #include <inttypes.h>
 #include <stdlib.h>
 #include <stdarg.h>
+#include <stdbool.h>
 #include <time.h>
 #include <signal.h>
 #include <unistd.h>
@@ -120,6 +121,7 @@
 } xenaccess_t;

 static int interrupted;
+bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;

 static void close_handler(int sig)
 {
@@ -167,9 +169,67 @@
     return -errno;
 }

+int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
+{
+    int rc;
+
+    if ( xenaccess == NULL )
+        return 0;
+
+    /* Tear down domain xenaccess in Xen */
+    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
+
+    if ( mem_access_enable )
+    {
+        rc = xc_mem_access_disable(xenaccess->xc_handle,
+                                   xenaccess->mem_event.domain_id);
+        if ( rc != 0 )
+        {
+            ERROR("Error tearing down domain xenaccess in xen");
+        }
+    }
+
+    /* Unbind VIRQ */
+    if ( evtchn_bind )
+    {
+        rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
+                              xenaccess->mem_event.port);
+        if ( rc != 0 )
+        {
+            ERROR("Error unbinding event port");
+        }
+    }
+
+    /* Close event channel */
+    if ( evtchn_open )
+    {
+        rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
+        if ( rc != 0 )
+        {
+            ERROR("Error closing event channel");
+        }
+    }
+
+    /* Close connection to Xen */
+    rc = xc_interface_close(xenaccess->xc_handle);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing connection to xen");
+    }
+    xenaccess->xc_handle = NULL;
+
+    if ( xenaccess->platform_info )
+        free(xenaccess->platform_info);
+    if ( xenaccess->domain_info )
+        free(xenaccess->domain_info);
+    free(xenaccess);
+
+    return 0;
+}
+
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
-    xenaccess_t *xenaccess;
+    xenaccess_t *xenaccess = 0;
     xc_interface *xch;
     int rc;
     unsigned long ring_pfn, mmap_pfn;
@@ -242,6 +302,7 @@
         }
         goto err;
     }
+    mem_access_enable = 1;

     /* Open event channel */
     xenaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
@@ -250,6 +311,7 @@
         ERROR("Failed to open event channel");
         goto err;
     }
+    evtchn_open = 1;

     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
@@ -260,7 +322,7 @@
         ERROR("Failed to bind event channel");
         goto err;
     }
-
+    evtchn_bind = 1;
     xenaccess->mem_event.port = rc;

     /* Initialise ring */
@@ -314,64 +376,12 @@
     return xenaccess;

  err:
-    if ( xenaccess )
-    {
-        if ( xenaccess->mem_event.ring_page )
-        {
-            munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-        }
-
-        free(xenaccess->platform_info);
-        free(xenaccess->domain_info);
-        free(xenaccess);
-    }
+    xenaccess_teardown(xch, xenaccess);

  err_iface:
     return NULL;
 }

-int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
-{
-    int rc;
-
-    if ( xenaccess == NULL )
-        return 0;
-
-    /* Tear down domain xenaccess in Xen */
-    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-    rc = xc_mem_access_disable(xenaccess->xc_handle,
xenaccess->mem_event.domain_id);
-    if ( rc != 0 )
-    {
-        ERROR("Error tearing down domain xenaccess in xen");
-    }
-
-    /* Unbind VIRQ */
-    rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
xenaccess->mem_event.port);
-    if ( rc != 0 )
-    {
-        ERROR("Error unbinding event port");
-    }
-    xenaccess->mem_event.port = -1;
-
-    /* Close event channel */
-    rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing event channel");
-    }
-    xenaccess->mem_event.xce_handle = NULL;
-
-    /* Close connection to Xen */
-    rc = xc_interface_close(xenaccess->xc_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing connection to xen");
-    }
-    xenaccess->xc_handle = NULL;
-
-    return 0;
-}
-
 int get_request(mem_event_t *mem_event, mem_event_request_t *req)
 {
     mem_event_back_ring_t *back_ring;
@@ -530,16 +540,39 @@
     sigaction(SIGALRM, &act, NULL);

     /* Set whether the access listener is required */
-    xc_domain_set_access_required(xch, domain_id, required);
+    rc = xc_domain_set_access_required(xch, domain_id, required);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting mem_access listener required\n", rc);
+        goto exit;
+    }

     /* Set the default access type and convert all pages to it */
     rc = xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0);
-    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0,
xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting default mem access type\n", rc);
+        goto exit;
+    }
+
+    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0,
+                               xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting all memory to access type %d\n", rc,
+              default_access);
+        goto exit;
+    }

     if ( int3 )
         rc = xc_set_hvm_param(xch, domain_id,
HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_sync);
     else
         rc = xc_set_hvm_param(xch, domain_id,
HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_disabled);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting int3 mem_event\n", rc);
+        goto exit;
+    }

     /* Wait for access */
     for (;;)
@@ -587,6 +620,12 @@
             switch (req.reason) {
             case MEM_EVENT_REASON_VIOLATION:
                 rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
+                if (rc < 0)
+                {
+                    ERROR("Error %d getting mem_access event\n", rc);
+                    interrupted = -1;
+                    continue;
+                }

                 printf("PAGE ACCESS: %c%c%c for GFN %"PRIx64" (offset %06"
                        PRIx64") gla %016"PRIx64" (vcpu %d)\n",
@@ -599,7 +638,17 @@
                        req.vcpu_id);

                 if ( default_access != after_first_access )
-                    rc = xc_hvm_set_mem_access(xch, domain_id,
after_first_access, req.gfn, 1);
+                {
+                    rc = xc_hvm_set_mem_access(xch, domain_id,
+                                               after_first_access, req.gfn, 1);
+                    if (rc < 0)
+                    {
+                        ERROR("Error %d setting gfn to access_type %d\n", rc,
+                              after_first_access);
+                        interrupted = -1;
+                        continue;
+                    }
+                }


                 rsp.gfn = req.gfn;
@@ -613,6 +662,12 @@

                 /* Reinject */
                 rc = xc_hvm_inject_trap(xch, domain_id, req.vcpu_id, 3, -1, 0);
+                if (rc < 0)
+                {
+                    ERROR("Error %d injecting int3\n", rc);
+                    interrupted = -1;
+                    continue;
+                }

                 break;
             default:
@@ -633,6 +688,7 @@
     }
     DPRINTF("xenaccess shut down on signal %d\n", interrupted);

+exit:
     /* Tear down domain xenaccess */
     rc1 = xenaccess_teardown(xch, xenaccess);
     if ( rc1 != 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 04:47:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 04:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKjGi-0002LR-TM; Thu, 19 Apr 2012 04:46:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SKjGh-0002LG-02
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 04:46:55 +0000
Received: from [85.158.138.51:4711] by server-2.bemta-3.messagelabs.com id
	0F/F0-09269-EB89F8F4; Thu, 19 Apr 2012 04:46:54 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1334810812!22608460!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11948 invoked from network); 19 Apr 2012 04:46:52 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 04:46:52 -0000
Received: by lagr15 with SMTP id r15so6639970lag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Apr 2012 21:46:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type; bh=Yhq+kjhwoGu7KdjAwD+ZRScC6xxJfs5CMkzkX/sHgaY=;
	b=Q9yZROkLE9aFKf0bRFNMPL0S4HdB1FM6OI4G3cln0zRS2BdyiHnNd9WZUVb3crfRIU
	/fOdKvm6LDin9ImPkirCslETUhkNEXvDmAQopiQVU9Fu04oseMdJCHf45Ex3np4zHu4J
	H/DvBukEBh6DUpcr13qzeMDZSFDzX/pYdRoKQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:date:message-id:subject:from:to
	:content-type:x-gm-message-state;
	bh=Yhq+kjhwoGu7KdjAwD+ZRScC6xxJfs5CMkzkX/sHgaY=;
	b=WwZZ4VFrzymLeqp2IOzfErVPLAb9SXgPgur9+euAI6yjAFCG9m29kWoFxas47BeT1c
	a/qgasSHEIUEye4c8BK8zYcI5GSE2d5529xHcvH1T1r+4RK0Lxtu+4LOpGnvkAUJSsK5
	J/IgjGrjJY7pKndDwrpdWcsd1YBu6Dsr37FMHBm77oOcn5jIyl8YNCf13IUpdclD6lsL
	pL5SvdnBxcF17oUPUEXr4Gm2XErLB3SqnU8P+AEmZjYp5FBC+F5kVViQ7JTKI9GOD6Z9
	qkNR8xM2wLiYJ+SUa3DWcZ72j0NGtoJan7xYbxTvjwcymn7fKaXQ+/vfQhWLgQYz2ZCI
	Vq5A==
MIME-Version: 1.0
Received: by 10.152.105.197 with SMTP id go5mr499627lab.43.1334810811646; Wed,
	18 Apr 2012 21:46:51 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Wed, 18 Apr 2012 21:46:51 -0700 (PDT)
X-Originating-IP: [108.92.21.169]
Date: Wed, 18 Apr 2012 21:46:51 -0700
Message-ID: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQndelbdTt7CCkVdVdIn9UILG1MXBCK/Wh3U2lNdMJg9jpyeA8hGyAmkt/bLIX1wWXycIAKW
Subject: [Xen-devel] [PATCH] xen-access: Check return values and clean up on
	errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check the return values of the libxc mem_access calls.
Free allocated structures (platform_info, domain_info) on errors
during initialization and exit
Unbind VIRQ, close event channel and connection to Xen on errors
during initialization

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

---

 tools/tests/xen-access/xen-access.c |  172 +++++++++++++++++++++++------------
 1 files changed, 114 insertions(+), 58 deletions(-)

diff -r a06e6cdeafe3 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c	Mon Apr 16 13:05:28 2012 +0200
+++ b/tools/tests/xen-access/xen-access.c	Wed Apr 18 21:30:17 2012 -0700
@@ -29,6 +29,7 @@
 #include <inttypes.h>
 #include <stdlib.h>
 #include <stdarg.h>
+#include <stdbool.h>
 #include <time.h>
 #include <signal.h>
 #include <unistd.h>
@@ -120,6 +121,7 @@
 } xenaccess_t;

 static int interrupted;
+bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;

 static void close_handler(int sig)
 {
@@ -167,9 +169,67 @@
     return -errno;
 }

+int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
+{
+    int rc;
+
+    if ( xenaccess == NULL )
+        return 0;
+
+    /* Tear down domain xenaccess in Xen */
+    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
+
+    if ( mem_access_enable )
+    {
+        rc = xc_mem_access_disable(xenaccess->xc_handle,
+                                   xenaccess->mem_event.domain_id);
+        if ( rc != 0 )
+        {
+            ERROR("Error tearing down domain xenaccess in xen");
+        }
+    }
+
+    /* Unbind VIRQ */
+    if ( evtchn_bind )
+    {
+        rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
+                              xenaccess->mem_event.port);
+        if ( rc != 0 )
+        {
+            ERROR("Error unbinding event port");
+        }
+    }
+
+    /* Close event channel */
+    if ( evtchn_open )
+    {
+        rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
+        if ( rc != 0 )
+        {
+            ERROR("Error closing event channel");
+        }
+    }
+
+    /* Close connection to Xen */
+    rc = xc_interface_close(xenaccess->xc_handle);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing connection to xen");
+    }
+    xenaccess->xc_handle = NULL;
+
+    if ( xenaccess->platform_info )
+        free(xenaccess->platform_info);
+    if ( xenaccess->domain_info )
+        free(xenaccess->domain_info);
+    free(xenaccess);
+
+    return 0;
+}
+
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
-    xenaccess_t *xenaccess;
+    xenaccess_t *xenaccess = 0;
     xc_interface *xch;
     int rc;
     unsigned long ring_pfn, mmap_pfn;
@@ -242,6 +302,7 @@
         }
         goto err;
     }
+    mem_access_enable = 1;

     /* Open event channel */
     xenaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
@@ -250,6 +311,7 @@
         ERROR("Failed to open event channel");
         goto err;
     }
+    evtchn_open = 1;

     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
@@ -260,7 +322,7 @@
         ERROR("Failed to bind event channel");
         goto err;
     }
-
+    evtchn_bind = 1;
     xenaccess->mem_event.port = rc;

     /* Initialise ring */
@@ -314,64 +376,12 @@
     return xenaccess;

  err:
-    if ( xenaccess )
-    {
-        if ( xenaccess->mem_event.ring_page )
-        {
-            munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-        }
-
-        free(xenaccess->platform_info);
-        free(xenaccess->domain_info);
-        free(xenaccess);
-    }
+    xenaccess_teardown(xch, xenaccess);

  err_iface:
     return NULL;
 }

-int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
-{
-    int rc;
-
-    if ( xenaccess == NULL )
-        return 0;
-
-    /* Tear down domain xenaccess in Xen */
-    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-    rc = xc_mem_access_disable(xenaccess->xc_handle,
xenaccess->mem_event.domain_id);
-    if ( rc != 0 )
-    {
-        ERROR("Error tearing down domain xenaccess in xen");
-    }
-
-    /* Unbind VIRQ */
-    rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
xenaccess->mem_event.port);
-    if ( rc != 0 )
-    {
-        ERROR("Error unbinding event port");
-    }
-    xenaccess->mem_event.port = -1;
-
-    /* Close event channel */
-    rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing event channel");
-    }
-    xenaccess->mem_event.xce_handle = NULL;
-
-    /* Close connection to Xen */
-    rc = xc_interface_close(xenaccess->xc_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing connection to xen");
-    }
-    xenaccess->xc_handle = NULL;
-
-    return 0;
-}
-
 int get_request(mem_event_t *mem_event, mem_event_request_t *req)
 {
     mem_event_back_ring_t *back_ring;
@@ -530,16 +540,39 @@
     sigaction(SIGALRM, &act, NULL);

     /* Set whether the access listener is required */
-    xc_domain_set_access_required(xch, domain_id, required);
+    rc = xc_domain_set_access_required(xch, domain_id, required);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting mem_access listener required\n", rc);
+        goto exit;
+    }

     /* Set the default access type and convert all pages to it */
     rc = xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0);
-    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0,
xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting default mem access type\n", rc);
+        goto exit;
+    }
+
+    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0,
+                               xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting all memory to access type %d\n", rc,
+              default_access);
+        goto exit;
+    }

     if ( int3 )
         rc = xc_set_hvm_param(xch, domain_id,
HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_sync);
     else
         rc = xc_set_hvm_param(xch, domain_id,
HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_disabled);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting int3 mem_event\n", rc);
+        goto exit;
+    }

     /* Wait for access */
     for (;;)
@@ -587,6 +620,12 @@
             switch (req.reason) {
             case MEM_EVENT_REASON_VIOLATION:
                 rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
+                if (rc < 0)
+                {
+                    ERROR("Error %d getting mem_access event\n", rc);
+                    interrupted = -1;
+                    continue;
+                }

                 printf("PAGE ACCESS: %c%c%c for GFN %"PRIx64" (offset %06"
                        PRIx64") gla %016"PRIx64" (vcpu %d)\n",
@@ -599,7 +638,17 @@
                        req.vcpu_id);

                 if ( default_access != after_first_access )
-                    rc = xc_hvm_set_mem_access(xch, domain_id,
after_first_access, req.gfn, 1);
+                {
+                    rc = xc_hvm_set_mem_access(xch, domain_id,
+                                               after_first_access, req.gfn, 1);
+                    if (rc < 0)
+                    {
+                        ERROR("Error %d setting gfn to access_type %d\n", rc,
+                              after_first_access);
+                        interrupted = -1;
+                        continue;
+                    }
+                }


                 rsp.gfn = req.gfn;
@@ -613,6 +662,12 @@

                 /* Reinject */
                 rc = xc_hvm_inject_trap(xch, domain_id, req.vcpu_id, 3, -1, 0);
+                if (rc < 0)
+                {
+                    ERROR("Error %d injecting int3\n", rc);
+                    interrupted = -1;
+                    continue;
+                }

                 break;
             default:
@@ -633,6 +688,7 @@
     }
     DPRINTF("xenaccess shut down on signal %d\n", interrupted);

+exit:
     /* Tear down domain xenaccess */
     rc1 = xenaccess_teardown(xch, xenaccess);
     if ( rc1 != 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 05:20:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 05:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKjmW-0002yu-Py; Thu, 19 Apr 2012 05:19:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SKjmV-0002yo-CX
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 05:19:47 +0000
Received: from [85.158.143.99:28147] by server-1.bemta-4.messagelabs.com id
	79/65-20925-270AF8F4; Thu, 19 Apr 2012 05:19:46 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334812784!24263844!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2NTQ5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13540 invoked from network); 19 Apr 2012 05:19:45 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 05:19:45 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 18 Apr 2012 22:19:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="132714654"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 18 Apr 2012 22:19:42 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 18 Apr 2012 22:19:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 13:19:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IUAAZaB3AAAkP3hAClszUA=
Date: Thu, 19 Apr 2012 05:19:39 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0DCE1C@SHSMSX101.ccr.corp.intel.com>
References: <CBB4448D.3E643%keir@xen.org> <CBB44859.3E648%keir@xen.org>
In-Reply-To: <CBB44859.3E648%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There have no problem with this patch, it works well. But it cannot fix the win8 issue. It seems there has some other issues with hpet. I will look into it.
Thanks for your quick patch.

best regards
yang


> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Wednesday, April 18, 2012 5:31 PM
> To: Zhang, Yang Z; xen-devel@lists.xensource.com
> Subject: Re: lock in vhpet
> 
> On 18/04/2012 10:14, "Keir Fraser" <keir@xen.org> wrote:
> 
> > On 18/04/2012 09:29, "Keir Fraser" <keir@xen.org> wrote:
> >
> >> On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> >>
> >>>> If the HPET accesses are atomic on bare metal, we have to maintain
> >>>> that, even if some guests have extra locking themselves. Also, in
> >>>> some cases Xen needs locking to correctly maintain its own internal
> >>>> state regardless of what an
> >>>> (untrusted) guest might do. So we cannot just get rid of the vhpet
> >>>> lock everywhere. It's definitely not correct to do so. Optimising
> >>>> the hpet read path however, sounds okay. I agree the lock may not
> >>>> be needed on that specific path.
> >>>
> >>> You are right.
> >>> For this case, since the main access of hpet is to read the main
> >>> counter, so I think the rwlock is a better choice.
> >>
> >> I'll see if I can make a patch...
> >
> > Please try the attached patch (build tested only).
> 
> Actually try this updated one. :-)
> 
> >  -- Keir
> >
> >>  -- Keir
> >>
> >>
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 05:20:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 05:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKjmW-0002yu-Py; Thu, 19 Apr 2012 05:19:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SKjmV-0002yo-CX
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 05:19:47 +0000
Received: from [85.158.143.99:28147] by server-1.bemta-4.messagelabs.com id
	79/65-20925-270AF8F4; Thu, 19 Apr 2012 05:19:46 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334812784!24263844!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2NTQ5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13540 invoked from network); 19 Apr 2012 05:19:45 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 05:19:45 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 18 Apr 2012 22:19:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="132714654"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 18 Apr 2012 22:19:42 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 18 Apr 2012 22:19:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 13:19:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: lock in vhpet
Thread-Index: Ac0cSdpHMDvKoPA9Rma8iOsTt0Od+QAIaxi9AAH2bsAAL9fm9QAAGKegAAKL3IUAAZaB3AAAkP3hAClszUA=
Date: Thu, 19 Apr 2012 05:19:39 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0DCE1C@SHSMSX101.ccr.corp.intel.com>
References: <CBB4448D.3E643%keir@xen.org> <CBB44859.3E648%keir@xen.org>
In-Reply-To: <CBB44859.3E648%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There have no problem with this patch, it works well. But it cannot fix the win8 issue. It seems there has some other issues with hpet. I will look into it.
Thanks for your quick patch.

best regards
yang


> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Wednesday, April 18, 2012 5:31 PM
> To: Zhang, Yang Z; xen-devel@lists.xensource.com
> Subject: Re: lock in vhpet
> 
> On 18/04/2012 10:14, "Keir Fraser" <keir@xen.org> wrote:
> 
> > On 18/04/2012 09:29, "Keir Fraser" <keir@xen.org> wrote:
> >
> >> On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> >>
> >>>> If the HPET accesses are atomic on bare metal, we have to maintain
> >>>> that, even if some guests have extra locking themselves. Also, in
> >>>> some cases Xen needs locking to correctly maintain its own internal
> >>>> state regardless of what an
> >>>> (untrusted) guest might do. So we cannot just get rid of the vhpet
> >>>> lock everywhere. It's definitely not correct to do so. Optimising
> >>>> the hpet read path however, sounds okay. I agree the lock may not
> >>>> be needed on that specific path.
> >>>
> >>> You are right.
> >>> For this case, since the main access of hpet is to read the main
> >>> counter, so I think the rwlock is a better choice.
> >>
> >> I'll see if I can make a patch...
> >
> > Please try the attached patch (build tested only).
> 
> Actually try this updated one. :-)
> 
> >  -- Keir
> >
> >>  -- Keir
> >>
> >>
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 05:55:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 05:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKkKf-0003Vg-Ab; Thu, 19 Apr 2012 05:55:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKkKe-0003Va-Bb
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 05:55:04 +0000
Received: from [85.158.139.83:14431] by server-10.bemta-5.messagelabs.com id
	55/C8-08260-7B8AF8F4; Thu, 19 Apr 2012 05:55:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334814902!24478293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1347 invoked from network); 19 Apr 2012 05:55:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 05:55:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12017931"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 05:55:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 06:55:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKkKb-0006LW-TN;
	Thu, 19 Apr 2012 05:55:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKkKb-0003Y1-O8;
	Thu, 19 Apr 2012 06:55:01 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12721-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 06:55:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12721: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12721 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12721/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  9 guest-start               fail REGR. vs. 12716

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12716

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7c777cb8f705
baseline version:
 xen                  e6b20ec1824c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 05:55:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 05:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKkKf-0003Vg-Ab; Thu, 19 Apr 2012 05:55:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKkKe-0003Va-Bb
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 05:55:04 +0000
Received: from [85.158.139.83:14431] by server-10.bemta-5.messagelabs.com id
	55/C8-08260-7B8AF8F4; Thu, 19 Apr 2012 05:55:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334814902!24478293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1347 invoked from network); 19 Apr 2012 05:55:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 05:55:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12017931"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 05:55:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 06:55:02 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKkKb-0006LW-TN;
	Thu, 19 Apr 2012 05:55:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKkKb-0003Y1-O8;
	Thu, 19 Apr 2012 06:55:01 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12721-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 06:55:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12721: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12721 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12721/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  9 guest-start               fail REGR. vs. 12716

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12716

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7c777cb8f705
baseline version:
 xen                  e6b20ec1824c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 06:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 06:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKl1z-0004BS-Q4; Thu, 19 Apr 2012 06:39:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKl1y-0004BJ-6v
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 06:39:50 +0000
Received: from [85.158.139.83:23789] by server-5.bemta-5.messagelabs.com id
	1D/B6-13566-533BF8F4; Thu, 19 Apr 2012 06:39:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334817588!24403247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26247 invoked from network); 19 Apr 2012 06:39:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 06:39:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12018451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 06:39:48 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Apr 2012 07:39:48 +0100
Message-ID: <1334817587.11493.44.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Thu, 19 Apr 2012 07:39:47 +0100
In-Reply-To: <CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> > diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> > --- a/tools/python/xen/xend/image.py    Mon Apr 16 17:57:00 2012 +0100
> > +++ b/tools/python/xen/xend/image.py    Tue Apr 17 11:26:06 2012 +0100
> > @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
> >             if vifname:
> >                 vifname = "tap-" + vifname
> 
> The above shouldn't it be:
> 
> vifname = "xentap-" + vifname

You are absolutely right, not sure how I missed that!

I'm out-of-office today but I'll resend later.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 06:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 06:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKl1z-0004BS-Q4; Thu, 19 Apr 2012 06:39:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKl1y-0004BJ-6v
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 06:39:50 +0000
Received: from [85.158.139.83:23789] by server-5.bemta-5.messagelabs.com id
	1D/B6-13566-533BF8F4; Thu, 19 Apr 2012 06:39:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334817588!24403247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26247 invoked from network); 19 Apr 2012 06:39:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 06:39:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12018451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 06:39:48 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Apr 2012 07:39:48 +0100
Message-ID: <1334817587.11493.44.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Thu, 19 Apr 2012 07:39:47 +0100
In-Reply-To: <CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> > diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> > --- a/tools/python/xen/xend/image.py    Mon Apr 16 17:57:00 2012 +0100
> > +++ b/tools/python/xen/xend/image.py    Tue Apr 17 11:26:06 2012 +0100
> > @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
> >             if vifname:
> >                 vifname = "tap-" + vifname
> 
> The above shouldn't it be:
> 
> vifname = "xentap-" + vifname

You are absolutely right, not sure how I missed that!

I'm out-of-office today but I'll resend later.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 06:48:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 06:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKl9t-0004eJ-Q3; Thu, 19 Apr 2012 06:48:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steven@uplinklabs.net>) id 1SKl9s-0004eD-U1
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 06:48:01 +0000
Received: from [85.158.143.35:32063] by server-1.bemta-4.messagelabs.com id
	EB/3B-20925-025BF8F4; Thu, 19 Apr 2012 06:48:00 +0000
X-Env-Sender: steven@uplinklabs.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334818077!13079509!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17949 invoked from network); 19 Apr 2012 06:47:59 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 06:47:59 -0000
Received: by pbcuo5 with SMTP id uo5so10197815pbc.32
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 23:47:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent:x-gm-message-state;
	bh=hfmM9Y8B3nuObDT4luACTyD9iR+X6npbyg+SlspiwnM=;
	b=DSWd/p2ZWuG6+6Dob5mWDTZ/rGiM+4a0aumbTZKw+PM2lNvbUY0ly/dj5P4H+m8CxA
	1n6bXCay3Urt3hbII72P8Zj6XtoYM+Rh9JXLiSNDhecYHsUHIF4va3fUVQG/jpPqTOF9
	VnMK+58F8R6IwK8ikud8XDUXWphcLaHr5wPCDttUrrM/kUF5ArFzKD8OWY5ksRN3EQJk
	LpiZLO15zN08T4rYs6twICbKYQBZDpD33EIcdt6oAlfUWaAWWn6QWO2AylUTF2GbWV1G
	JVcnOgUw15S+CogI6mmLhUqlRB0HZuycPnVUaNeboQjrEPe4hL09A6bupy5EALFcL+ZH
	nkug==
Received: by 10.68.194.198 with SMTP id hy6mr2931047pbc.0.1334818077109;
	Wed, 18 Apr 2012 23:47:57 -0700 (PDT)
Received: from asmodeus.uplinklabs.net (207-171-191-60.amazon.com.
	[207.171.191.60])
	by mx.google.com with ESMTPS id q5sm1405076pbp.28.2012.04.18.23.47.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Apr 2012 23:47:55 -0700 (PDT)
Date: Wed, 18 Apr 2012 23:47:51 -0700
From: Steven Noonan <steven@uplinklabs.net>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419064751.GA6268@asmodeus.uplinklabs.net>
References: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmzjQmoD8E/3v3pPC2DSerlLrgUZ2jGW29W+THZDo6TtSdwQ7eCXZw4xPrFPMN1msL7RkRh
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCBBcHIgMTUsIDIwMTIgYXQgMDI6MTQ6NTdQTSArMDgwMCwgTGluIE1pbmcgd3JvdGU6
Cj4gKEZvcmdvdCBtYWlsIHN1YmplY3QsIGFkZCBpdCkKPiAKPiBPbiBTdW4sIEFwciAxNSwgMjAx
MiBhdCAyOjA5IFBNLCBMaW4gTWluZyA8bWxpbkBzcy5wa3UuZWR1LmNuPiB3cm90ZToKPiA+IEhp
IGFsbCwKPiA+Cj4gPiBUaGVzZSAyIHBhdGNoZXMgdHJ5IHRvIGZpeCB0aGUgInBlcmYgdG9wIiBz
b2Z0IGxvY2t1cHMgdW5kZXIgWGVuCj4gPiByZXBvcnRlZCBieSBTdGV2ZW4gYXQ6IGh0dHBzOi8v
bGttbC5vcmcvbGttbC8yMDEyLzIvOS81MDYKPiA+Cj4gPiBJIHRlc3RlZCBpdCB3aXRoIDMuNC1y
YzIgYW5kICJwZXJmIHRvcCIgd29ya3Mgd2VsbCBub3cuCj4gPgo+ID4gU3RldmVuLAo+ID4gQ291
bGQgeW91IHBsZWFzZSBoZWxwIHRvIHRlc3QgaXQgdG9vPwo+ID4KPiA+IFRoZSBzb2Z0IGxvY2t1
cCBjb2RlIHBhdGggaXM6Cj4gPgo+ID4gX19pcnFfd29ya19xdWV1ZQo+ID4gwqBhcmNoX2lycV93
b3JrX3JhaXNlCj4gPiDCoCDCoGFwaWMtPnNlbmRfSVBJX3NlbGYoSVJRX1dPUktfVkVDVE9SKTsK
PiA+IMKgIMKgIMKgYXBpY19zZW5kX0lQSV9zZWxmCj4gPiDCoCDCoCDCoCDCoF9fZGVmYXVsdF9z
ZW5kX0lQSV9zaG9ydGN1dAo+ID4gwqAgwqAgwqAgwqAgwqBfX3hhcGljX3dhaXRfaWNyX2lkbGUK
PiA+Cj4gPiBzdGF0aWMgaW5saW5lIHZvaWQgX194YXBpY193YWl0X2ljcl9pZGxlKHZvaWQpCj4g
PiB7Cj4gPiDCoCDCoCDCoCDCoHdoaWxlIChuYXRpdmVfYXBpY19tZW1fcmVhZChBUElDX0lDUikg
JiBBUElDX0lDUl9CVVNZKQo+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjcHVfcmVsYXgoKTsK
PiA+IH0KPiA+Cj4gPiBUaGUgbG9ja3VwIGhhcHBlbnMgYXQgYWJvdmUgd2hpbGUgbG9vb3AuCj4g
Pgo+ID4gVGhlIGNhdXNlIGlzIHRoYXQgWGVuIGhhcyBub3QgaW1wbGVtZW50ZWQgdGhlIEFQSUMg
SVBJIGludGVyZmFjZSB5ZXQuCj4gPiBYZW4gaGFzIElQSSBpbnRlcmZhY2U6IHhlbl9zZW5kX0lQ
SV9vbmUsIGJ1dCBpdCdzIG9ubHkgdXNlZCBpbgo+ID4geGVuX3NtcF9zZW5kX3Jlc2NoZWR1bGUs
IHhlbl9zbXBfc2VuZF9jYWxsX2Z1bmN0aW9uX2lwaSBhbmQKPiA+IHhlbl9zbXBfc2VuZF9jYWxs
X2Z1bmN0aW9uX3NpbmdsZV9pcGksIGV0Yy4KPiA+Cj4gPiBTbyB3ZSBuZWVkIHRvIGltcGxlbWVu
dCBYZW4ncyBBUElDIElQSSBpbnRlcmZhY2UgYXMgQmVuJ3MgcGF0Y2ggZG9lcy4KPiA+IEFuZCBp
bXBsZW1lbnQgWGVuJ3MgSVJRX1dPUktfVkVDVE9SIGhhbmRsZXIuCj4gPgo+ID4gQmVuIEd1dGhy
byAoMSk6Cj4gPiDCoCDCoCDCoHhlbjogaW1wbGVtZW50IGFwaWMgaXBpIGludGVyZmFjZQo+ID4K
PiA+IExpbiBNaW5nICgxKToKPiA+IMKgIMKgIMKgeGVuOiBpbXBsZW1lbnQgSVJRX1dPUktfVkVD
VE9SIGhhbmRsZXIKPiA+Cj4gPiDCoGFyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9ldmVudHMuaCB8
IMKgIMKgMSArCj4gPiDCoGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyDCoCDCoCDCoCDCoCDCoHwg
wqAgwqA3ICsrCj4gPiDCoGFyY2gveDg2L3hlbi9zbXAuYyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oHwgwqAxMTEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCj4gPiDCoGFyY2gv
eDg2L3hlbi9zbXAuaCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgMTIgKysrKwo+ID4gwqA0
IGZpbGVzIGNoYW5nZWQsIDEyNyBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQo+ID4KPiA+
IEFueSBjb21tZW50IGlzIGFwcHJlY2lhdGVkLgo+ID4gTGluIE1pbmcKCk9LLCBmaW5hbGx5IGdv
dCBhcm91bmQgdG8gdGVzdGluZyB0aGlzLiBTb3JyeSBhYm91dCB0aGUgZGVsYXksIGJlZW4KcmF0
aGVyIGJ1c3kgYXQgd29yay4KClRoZXNlIHR3byBwYXRjaGVzIGRlZmluaXRlbHkgZml4IHRoZSBs
b2NrdXBzLCBidXQgJ3BlcmYgdGVzdCcgZG9lc24ndApwYXNzIGV2ZXJ5IHRlc3Q6CgoJIDE6IHZt
bGludXggc3ltdGFiIG1hdGNoZXMga2FsbHN5bXM6CgktLS0gc3RhcnQgLS0tCglMb29raW5nIGF0
IHRoZSB2bWxpbnV4X3BhdGggKDYgZW50cmllcyBsb25nKQoJZHNvX19sb2FkX3N5bTogY2Fubm90
IGdldCBlbGYgaGVhZGVyLgoJVXNpbmcgL2xpYi9tb2R1bGVzLzMuMy4yLTAwMDAyLWdmNTcxMzBk
L2J1aWxkL3ZtbGludXggZm9yIHN5bWJvbHMKCU1hcHMgb25seSBpbiB2bWxpbnV4OgoJIGZmZmZm
ZmZmODFhZTYxYjEtZmZmZmZmZmY4MWI5ZDdiNyAwIFtrZXJuZWxdLmluaXQudGV4dAoJIGZmZmZm
ZmZmODFiOWQ3YjgtZmZmZmZmZmY5ZmZmZmZmZiAwIFtrZXJuZWxdLmV4aXQudGV4dAoJTWFwcyBp
biB2bWxpbnV4IHdpdGggYSBkaWZmZXJlbnQgbmFtZSBpbiBrYWxsc3ltczoKCU1hcHMgb25seSBp
biBrYWxsc3ltczoKCS0tLS0gZW5kIC0tLS0KCXZtbGludXggc3ltdGFiIG1hdGNoZXMga2FsbHN5
bXM6IE9rCgkgMjogZGV0ZWN0IG9wZW4gc3lzY2FsbCBldmVudDoKCS0tLSBzdGFydCAtLS0KCS0t
LS0gZW5kIC0tLS0KCWRldGVjdCBvcGVuIHN5c2NhbGwgZXZlbnQ6IE9rCgkgMzogZGV0ZWN0IG9w
ZW4gc3lzY2FsbCBldmVudCBvbiBhbGwgY3B1czoKCS0tLSBzdGFydCAtLS0KCS0tLS0gZW5kIC0t
LS0KCWRldGVjdCBvcGVuIHN5c2NhbGwgZXZlbnQgb24gYWxsIGNwdXM6IE9rCgkgNDogcmVhZCBz
YW1wbGVzIHVzaW5nIHRoZSBtbWFwIGludGVyZmFjZToKCS0tLSBzdGFydCAtLS0KCS0tLS0gZW5k
IC0tLS0KCXJlYWQgc2FtcGxlcyB1c2luZyB0aGUgbW1hcCBpbnRlcmZhY2U6IE9rCgkgNTogcGFy
c2UgZXZlbnRzIHRlc3RzOgoJLS0tIHN0YXJ0IC0tLQoJLS0tLSBlbmQgLS0tLQoJcGFyc2UgZXZl
bnRzIHRlc3RzOiBPawoJIDY6IFZhbGlkYXRlIFBFUkZfUkVDT1JEXyogZXZlbnRzICYgcGVyZl9z
YW1wbGUgZmllbGRzOgoJLS0tIHN0YXJ0IC0tLQoJcGVyZl9ldmxpc3RfX29wZW46IEJhZCBmaWxl
IGRlc2NyaXB0b3IKCS0tLS0gZW5kIC0tLS0KCVZhbGlkYXRlIFBFUkZfUkVDT1JEXyogZXZlbnRz
ICYgcGVyZl9zYW1wbGUgZmllbGRzOiBGQUlMRUQhCgpJIGNvdWxkbid0IGZpZ3VyZSBvdXQgd2hh
dCBleGFjdGx5IHdhcyBmYWlsaW5nIGluIHRoYXQgdGVzdCB3aXRoIGEKcXVpY2sgaW5zcGVjdGlv
bi4uLiBTb21lb25lIGVsc2Ugd2FudCB0byB0YWtlIGEgc3RhYiBhdCBpdD8gSWYgc29tZW9uZQp3
YW50cyB0byBnaXZlIG1lIHBhdGNoZXMgdGhhdCBhZGQgZXh0cmEgb3V0cHV0LCBJIGNvdWxkIHJ1
biB0aG9zZSB0b28uCgpBbnl3YXk6CgpUZXN0ZWQtYnk6IFN0ZXZlbiBOb29uYW4gPHN0ZXZlbkB1
cGxpbmtsYWJzLm5ldD4KCi0gU3RldmVuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 19 06:48:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 06:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKl9t-0004eJ-Q3; Thu, 19 Apr 2012 06:48:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steven@uplinklabs.net>) id 1SKl9s-0004eD-U1
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 06:48:01 +0000
Received: from [85.158.143.35:32063] by server-1.bemta-4.messagelabs.com id
	EB/3B-20925-025BF8F4; Thu, 19 Apr 2012 06:48:00 +0000
X-Env-Sender: steven@uplinklabs.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334818077!13079509!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17949 invoked from network); 19 Apr 2012 06:47:59 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 06:47:59 -0000
Received: by pbcuo5 with SMTP id uo5so10197815pbc.32
	for <xen-devel@lists.xen.org>; Wed, 18 Apr 2012 23:47:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent:x-gm-message-state;
	bh=hfmM9Y8B3nuObDT4luACTyD9iR+X6npbyg+SlspiwnM=;
	b=DSWd/p2ZWuG6+6Dob5mWDTZ/rGiM+4a0aumbTZKw+PM2lNvbUY0ly/dj5P4H+m8CxA
	1n6bXCay3Urt3hbII72P8Zj6XtoYM+Rh9JXLiSNDhecYHsUHIF4va3fUVQG/jpPqTOF9
	VnMK+58F8R6IwK8ikud8XDUXWphcLaHr5wPCDttUrrM/kUF5ArFzKD8OWY5ksRN3EQJk
	LpiZLO15zN08T4rYs6twICbKYQBZDpD33EIcdt6oAlfUWaAWWn6QWO2AylUTF2GbWV1G
	JVcnOgUw15S+CogI6mmLhUqlRB0HZuycPnVUaNeboQjrEPe4hL09A6bupy5EALFcL+ZH
	nkug==
Received: by 10.68.194.198 with SMTP id hy6mr2931047pbc.0.1334818077109;
	Wed, 18 Apr 2012 23:47:57 -0700 (PDT)
Received: from asmodeus.uplinklabs.net (207-171-191-60.amazon.com.
	[207.171.191.60])
	by mx.google.com with ESMTPS id q5sm1405076pbp.28.2012.04.18.23.47.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Apr 2012 23:47:55 -0700 (PDT)
Date: Wed, 18 Apr 2012 23:47:51 -0700
From: Steven Noonan <steven@uplinklabs.net>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419064751.GA6268@asmodeus.uplinklabs.net>
References: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmzjQmoD8E/3v3pPC2DSerlLrgUZ2jGW29W+THZDo6TtSdwQ7eCXZw4xPrFPMN1msL7RkRh
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCBBcHIgMTUsIDIwMTIgYXQgMDI6MTQ6NTdQTSArMDgwMCwgTGluIE1pbmcgd3JvdGU6
Cj4gKEZvcmdvdCBtYWlsIHN1YmplY3QsIGFkZCBpdCkKPiAKPiBPbiBTdW4sIEFwciAxNSwgMjAx
MiBhdCAyOjA5IFBNLCBMaW4gTWluZyA8bWxpbkBzcy5wa3UuZWR1LmNuPiB3cm90ZToKPiA+IEhp
IGFsbCwKPiA+Cj4gPiBUaGVzZSAyIHBhdGNoZXMgdHJ5IHRvIGZpeCB0aGUgInBlcmYgdG9wIiBz
b2Z0IGxvY2t1cHMgdW5kZXIgWGVuCj4gPiByZXBvcnRlZCBieSBTdGV2ZW4gYXQ6IGh0dHBzOi8v
bGttbC5vcmcvbGttbC8yMDEyLzIvOS81MDYKPiA+Cj4gPiBJIHRlc3RlZCBpdCB3aXRoIDMuNC1y
YzIgYW5kICJwZXJmIHRvcCIgd29ya3Mgd2VsbCBub3cuCj4gPgo+ID4gU3RldmVuLAo+ID4gQ291
bGQgeW91IHBsZWFzZSBoZWxwIHRvIHRlc3QgaXQgdG9vPwo+ID4KPiA+IFRoZSBzb2Z0IGxvY2t1
cCBjb2RlIHBhdGggaXM6Cj4gPgo+ID4gX19pcnFfd29ya19xdWV1ZQo+ID4gwqBhcmNoX2lycV93
b3JrX3JhaXNlCj4gPiDCoCDCoGFwaWMtPnNlbmRfSVBJX3NlbGYoSVJRX1dPUktfVkVDVE9SKTsK
PiA+IMKgIMKgIMKgYXBpY19zZW5kX0lQSV9zZWxmCj4gPiDCoCDCoCDCoCDCoF9fZGVmYXVsdF9z
ZW5kX0lQSV9zaG9ydGN1dAo+ID4gwqAgwqAgwqAgwqAgwqBfX3hhcGljX3dhaXRfaWNyX2lkbGUK
PiA+Cj4gPiBzdGF0aWMgaW5saW5lIHZvaWQgX194YXBpY193YWl0X2ljcl9pZGxlKHZvaWQpCj4g
PiB7Cj4gPiDCoCDCoCDCoCDCoHdoaWxlIChuYXRpdmVfYXBpY19tZW1fcmVhZChBUElDX0lDUikg
JiBBUElDX0lDUl9CVVNZKQo+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjcHVfcmVsYXgoKTsK
PiA+IH0KPiA+Cj4gPiBUaGUgbG9ja3VwIGhhcHBlbnMgYXQgYWJvdmUgd2hpbGUgbG9vb3AuCj4g
Pgo+ID4gVGhlIGNhdXNlIGlzIHRoYXQgWGVuIGhhcyBub3QgaW1wbGVtZW50ZWQgdGhlIEFQSUMg
SVBJIGludGVyZmFjZSB5ZXQuCj4gPiBYZW4gaGFzIElQSSBpbnRlcmZhY2U6IHhlbl9zZW5kX0lQ
SV9vbmUsIGJ1dCBpdCdzIG9ubHkgdXNlZCBpbgo+ID4geGVuX3NtcF9zZW5kX3Jlc2NoZWR1bGUs
IHhlbl9zbXBfc2VuZF9jYWxsX2Z1bmN0aW9uX2lwaSBhbmQKPiA+IHhlbl9zbXBfc2VuZF9jYWxs
X2Z1bmN0aW9uX3NpbmdsZV9pcGksIGV0Yy4KPiA+Cj4gPiBTbyB3ZSBuZWVkIHRvIGltcGxlbWVu
dCBYZW4ncyBBUElDIElQSSBpbnRlcmZhY2UgYXMgQmVuJ3MgcGF0Y2ggZG9lcy4KPiA+IEFuZCBp
bXBsZW1lbnQgWGVuJ3MgSVJRX1dPUktfVkVDVE9SIGhhbmRsZXIuCj4gPgo+ID4gQmVuIEd1dGhy
byAoMSk6Cj4gPiDCoCDCoCDCoHhlbjogaW1wbGVtZW50IGFwaWMgaXBpIGludGVyZmFjZQo+ID4K
PiA+IExpbiBNaW5nICgxKToKPiA+IMKgIMKgIMKgeGVuOiBpbXBsZW1lbnQgSVJRX1dPUktfVkVD
VE9SIGhhbmRsZXIKPiA+Cj4gPiDCoGFyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9ldmVudHMuaCB8
IMKgIMKgMSArCj4gPiDCoGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyDCoCDCoCDCoCDCoCDCoHwg
wqAgwqA3ICsrCj4gPiDCoGFyY2gveDg2L3hlbi9zbXAuYyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oHwgwqAxMTEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCj4gPiDCoGFyY2gv
eDg2L3hlbi9zbXAuaCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgMTIgKysrKwo+ID4gwqA0
IGZpbGVzIGNoYW5nZWQsIDEyNyBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQo+ID4KPiA+
IEFueSBjb21tZW50IGlzIGFwcHJlY2lhdGVkLgo+ID4gTGluIE1pbmcKCk9LLCBmaW5hbGx5IGdv
dCBhcm91bmQgdG8gdGVzdGluZyB0aGlzLiBTb3JyeSBhYm91dCB0aGUgZGVsYXksIGJlZW4KcmF0
aGVyIGJ1c3kgYXQgd29yay4KClRoZXNlIHR3byBwYXRjaGVzIGRlZmluaXRlbHkgZml4IHRoZSBs
b2NrdXBzLCBidXQgJ3BlcmYgdGVzdCcgZG9lc24ndApwYXNzIGV2ZXJ5IHRlc3Q6CgoJIDE6IHZt
bGludXggc3ltdGFiIG1hdGNoZXMga2FsbHN5bXM6CgktLS0gc3RhcnQgLS0tCglMb29raW5nIGF0
IHRoZSB2bWxpbnV4X3BhdGggKDYgZW50cmllcyBsb25nKQoJZHNvX19sb2FkX3N5bTogY2Fubm90
IGdldCBlbGYgaGVhZGVyLgoJVXNpbmcgL2xpYi9tb2R1bGVzLzMuMy4yLTAwMDAyLWdmNTcxMzBk
L2J1aWxkL3ZtbGludXggZm9yIHN5bWJvbHMKCU1hcHMgb25seSBpbiB2bWxpbnV4OgoJIGZmZmZm
ZmZmODFhZTYxYjEtZmZmZmZmZmY4MWI5ZDdiNyAwIFtrZXJuZWxdLmluaXQudGV4dAoJIGZmZmZm
ZmZmODFiOWQ3YjgtZmZmZmZmZmY5ZmZmZmZmZiAwIFtrZXJuZWxdLmV4aXQudGV4dAoJTWFwcyBp
biB2bWxpbnV4IHdpdGggYSBkaWZmZXJlbnQgbmFtZSBpbiBrYWxsc3ltczoKCU1hcHMgb25seSBp
biBrYWxsc3ltczoKCS0tLS0gZW5kIC0tLS0KCXZtbGludXggc3ltdGFiIG1hdGNoZXMga2FsbHN5
bXM6IE9rCgkgMjogZGV0ZWN0IG9wZW4gc3lzY2FsbCBldmVudDoKCS0tLSBzdGFydCAtLS0KCS0t
LS0gZW5kIC0tLS0KCWRldGVjdCBvcGVuIHN5c2NhbGwgZXZlbnQ6IE9rCgkgMzogZGV0ZWN0IG9w
ZW4gc3lzY2FsbCBldmVudCBvbiBhbGwgY3B1czoKCS0tLSBzdGFydCAtLS0KCS0tLS0gZW5kIC0t
LS0KCWRldGVjdCBvcGVuIHN5c2NhbGwgZXZlbnQgb24gYWxsIGNwdXM6IE9rCgkgNDogcmVhZCBz
YW1wbGVzIHVzaW5nIHRoZSBtbWFwIGludGVyZmFjZToKCS0tLSBzdGFydCAtLS0KCS0tLS0gZW5k
IC0tLS0KCXJlYWQgc2FtcGxlcyB1c2luZyB0aGUgbW1hcCBpbnRlcmZhY2U6IE9rCgkgNTogcGFy
c2UgZXZlbnRzIHRlc3RzOgoJLS0tIHN0YXJ0IC0tLQoJLS0tLSBlbmQgLS0tLQoJcGFyc2UgZXZl
bnRzIHRlc3RzOiBPawoJIDY6IFZhbGlkYXRlIFBFUkZfUkVDT1JEXyogZXZlbnRzICYgcGVyZl9z
YW1wbGUgZmllbGRzOgoJLS0tIHN0YXJ0IC0tLQoJcGVyZl9ldmxpc3RfX29wZW46IEJhZCBmaWxl
IGRlc2NyaXB0b3IKCS0tLS0gZW5kIC0tLS0KCVZhbGlkYXRlIFBFUkZfUkVDT1JEXyogZXZlbnRz
ICYgcGVyZl9zYW1wbGUgZmllbGRzOiBGQUlMRUQhCgpJIGNvdWxkbid0IGZpZ3VyZSBvdXQgd2hh
dCBleGFjdGx5IHdhcyBmYWlsaW5nIGluIHRoYXQgdGVzdCB3aXRoIGEKcXVpY2sgaW5zcGVjdGlv
bi4uLiBTb21lb25lIGVsc2Ugd2FudCB0byB0YWtlIGEgc3RhYiBhdCBpdD8gSWYgc29tZW9uZQp3
YW50cyB0byBnaXZlIG1lIHBhdGNoZXMgdGhhdCBhZGQgZXh0cmEgb3V0cHV0LCBJIGNvdWxkIHJ1
biB0aG9zZSB0b28uCgpBbnl3YXk6CgpUZXN0ZWQtYnk6IFN0ZXZlbiBOb29uYW4gPHN0ZXZlbkB1
cGxpbmtsYWJzLm5ldD4KCi0gU3RldmVuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 19 07:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 07:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKlMn-0004xs-A7; Thu, 19 Apr 2012 07:01:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SKlMl-0004xd-R5
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 07:01:20 +0000
Received: from [85.158.143.99:52947] by server-3.bemta-4.messagelabs.com id
	83/F8-05853-F38BF8F4; Thu, 19 Apr 2012 07:01:19 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334818877!20922228!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32166 invoked from network); 19 Apr 2012 07:01:18 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-7.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 07:01:18 -0000
Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com
	[209.85.212.45]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 57D24DBCAE
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 15:01:01 +0800 (CST)
Received: by vbbfs19 with SMTP id fs19so7221513vbb.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 00:00:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.9 with SMTP id eu9mr475793vdb.28.1334818859719; Thu, 19
	Apr 2012 00:00:59 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Thu, 19 Apr 2012 00:00:59 -0700 (PDT)
In-Reply-To: <20120419064751.GA6268@asmodeus.uplinklabs.net>
References: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
	<20120419064751.GA6268@asmodeus.uplinklabs.net>
Date: Thu, 19 Apr 2012 15:00:59 +0800
Message-ID: <CAF1ivSYtRi-3PpF2TeQwOFSBSWp+Cnz2B6ds6Py1T5uZ6U70Nw@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Steven Noonan <steven@uplinklabs.net>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 2:47 PM, Steven Noonan <steven@uplinklabs.net> wrot=
e:

[snip]

>
> OK, finally got around to testing this. Sorry about the delay, been
> rather busy at work.
>
> These two patches definitely fix the lockups, but 'perf test' doesn't
> pass every test:

Thanks for the test!

>
> =A0 =A0 =A0 =A0 1: vmlinux symtab matches kallsyms:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0Looking at the vmlinux_path (6 entries long)
> =A0 =A0 =A0 =A0dso__load_sym: cannot get elf header.
> =A0 =A0 =A0 =A0Using /lib/modules/3.3.2-00002-gf57130d/build/vmlinux for =
symbols
> =A0 =A0 =A0 =A0Maps only in vmlinux:
> =A0 =A0 =A0 =A0 ffffffff81ae61b1-ffffffff81b9d7b7 0 [kernel].init.text
> =A0 =A0 =A0 =A0 ffffffff81b9d7b8-ffffffff9fffffff 0 [kernel].exit.text
> =A0 =A0 =A0 =A0Maps in vmlinux with a different name in kallsyms:
> =A0 =A0 =A0 =A0Maps only in kallsyms:
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0vmlinux symtab matches kallsyms: Ok
> =A0 =A0 =A0 =A0 2: detect open syscall event:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0detect open syscall event: Ok
> =A0 =A0 =A0 =A0 3: detect open syscall event on all cpus:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0detect open syscall event on all cpus: Ok
> =A0 =A0 =A0 =A0 4: read samples using the mmap interface:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0read samples using the mmap interface: Ok
> =A0 =A0 =A0 =A0 5: parse events tests:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0parse events tests: Ok
> =A0 =A0 =A0 =A0 6: Validate PERF_RECORD_* events & perf_sample fields:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0perf_evlist__open: Bad file descriptor
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0Validate PERF_RECORD_* events & perf_sample fields: FAILED!

This should be another unrelated issue.
Let me try to see if I can reproduce it.

>
> I couldn't figure out what exactly was failing in that test with a
> quick inspection... Someone else want to take a stab at it? If someone
> wants to give me patches that add extra output, I could run those too.
>
> Anyway:
>
> Tested-by: Steven Noonan <steven@uplinklabs.net>

Thanks.

Lin Ming

>
> - Steven

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 07:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 07:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKlMn-0004xs-A7; Thu, 19 Apr 2012 07:01:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SKlMl-0004xd-R5
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 07:01:20 +0000
Received: from [85.158.143.99:52947] by server-3.bemta-4.messagelabs.com id
	83/F8-05853-F38BF8F4; Thu, 19 Apr 2012 07:01:19 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-7.tower-216.messagelabs.com!1334818877!20922228!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32166 invoked from network); 19 Apr 2012 07:01:18 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-7.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 07:01:18 -0000
Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com
	[209.85.212.45]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 57D24DBCAE
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 15:01:01 +0800 (CST)
Received: by vbbfs19 with SMTP id fs19so7221513vbb.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 00:00:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.9 with SMTP id eu9mr475793vdb.28.1334818859719; Thu, 19
	Apr 2012 00:00:59 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Thu, 19 Apr 2012 00:00:59 -0700 (PDT)
In-Reply-To: <20120419064751.GA6268@asmodeus.uplinklabs.net>
References: <CAF1ivSZqe54_gAQNZW_teiApObkXsC5iu04Siy1OEnm9M9AcUA@mail.gmail.com>
	<20120419064751.GA6268@asmodeus.uplinklabs.net>
Date: Thu, 19 Apr 2012 15:00:59 +0800
Message-ID: <CAF1ivSYtRi-3PpF2TeQwOFSBSWp+Cnz2B6ds6Py1T5uZ6U70Nw@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Steven Noonan <steven@uplinklabs.net>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 2:47 PM, Steven Noonan <steven@uplinklabs.net> wrot=
e:

[snip]

>
> OK, finally got around to testing this. Sorry about the delay, been
> rather busy at work.
>
> These two patches definitely fix the lockups, but 'perf test' doesn't
> pass every test:

Thanks for the test!

>
> =A0 =A0 =A0 =A0 1: vmlinux symtab matches kallsyms:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0Looking at the vmlinux_path (6 entries long)
> =A0 =A0 =A0 =A0dso__load_sym: cannot get elf header.
> =A0 =A0 =A0 =A0Using /lib/modules/3.3.2-00002-gf57130d/build/vmlinux for =
symbols
> =A0 =A0 =A0 =A0Maps only in vmlinux:
> =A0 =A0 =A0 =A0 ffffffff81ae61b1-ffffffff81b9d7b7 0 [kernel].init.text
> =A0 =A0 =A0 =A0 ffffffff81b9d7b8-ffffffff9fffffff 0 [kernel].exit.text
> =A0 =A0 =A0 =A0Maps in vmlinux with a different name in kallsyms:
> =A0 =A0 =A0 =A0Maps only in kallsyms:
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0vmlinux symtab matches kallsyms: Ok
> =A0 =A0 =A0 =A0 2: detect open syscall event:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0detect open syscall event: Ok
> =A0 =A0 =A0 =A0 3: detect open syscall event on all cpus:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0detect open syscall event on all cpus: Ok
> =A0 =A0 =A0 =A0 4: read samples using the mmap interface:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0read samples using the mmap interface: Ok
> =A0 =A0 =A0 =A0 5: parse events tests:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0parse events tests: Ok
> =A0 =A0 =A0 =A0 6: Validate PERF_RECORD_* events & perf_sample fields:
> =A0 =A0 =A0 =A0--- start ---
> =A0 =A0 =A0 =A0perf_evlist__open: Bad file descriptor
> =A0 =A0 =A0 =A0---- end ----
> =A0 =A0 =A0 =A0Validate PERF_RECORD_* events & perf_sample fields: FAILED!

This should be another unrelated issue.
Let me try to see if I can reproduce it.

>
> I couldn't figure out what exactly was failing in that test with a
> quick inspection... Someone else want to take a stab at it? If someone
> wants to give me patches that add extra output, I could run those too.
>
> Anyway:
>
> Tested-by: Steven Noonan <steven@uplinklabs.net>

Thanks.

Lin Ming

>
> - Steven

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 07:22:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 07:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKlh1-0005QD-To; Thu, 19 Apr 2012 07:22:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKlh0-0005Q8-76
	for Xen-devel@lists.xensource.com; Thu, 19 Apr 2012 07:22:14 +0000
Received: from [193.109.254.147:8926] by server-8.bemta-14.messagelabs.com id
	9D/93-23244-52DBF8F4; Thu, 19 Apr 2012 07:22:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334820132!5285072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9852 invoked from network); 19 Apr 2012 07:22:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 07:22:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12019048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 07:22:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Apr 2012 08:22:13 +0100
Message-ID: <1334820132.11493.51.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 19 Apr 2012 08:22:12 +0100
In-Reply-To: <20120418162908.2b790fae@mantra.us.oracle.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
	<20120416185340.72ef5566@mantra.us.oracle.com>
	<1334653528.14560.261.camel@zakaz.uk.xensource.com>
	<20120418162908.2b790fae@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 00:29 +0100, Mukesh Rathor wrote:
> On Tue, 17 Apr 2012 10:05:28 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
> > > On Mon, 16 Apr 2012 14:53:22 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > Sorry, I meant why a whole new subcall instead of a new
> > XENMAPSPACE ;-)
> > 
> > e.g. On ARM I did:
> > 
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 86d02c8..b2adfbe 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -212,11 +212,13 @@ struct xen_add_to_physmap {
> >      uint16_t    size;
> >  
> >      /* Source mapping space. */
> > -#define XENMAPSPACE_shared_info 0 /* shared info page */
> > -#define XENMAPSPACE_grant_table 1 /* grant table page */
> > -#define XENMAPSPACE_gmfn        2 /* GMFN */
> > -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> > -    unsigned int space;
> > +#define XENMAPSPACE_shared_info  0 /* shared info page */
> > +#define XENMAPSPACE_grant_table  1 /* grant table page */
> > +#define XENMAPSPACE_gmfn         2 /* GMFN */
> > +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > +    uint16_t space;
> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
> 
> 
> Well, for several reasons, I didn't use it, mainly, it doesn't allow
> for count. So requests have to come in one frame at a time.

I've got it that way on ARM too at the moment but I was planning to make
it behave like gmfn_range and use the size parameter to map multiple at
a time (unless I've misunderstood what the gmfn_range variant does).

>  Second, none of the common code can be used by my new request,

I don't think that's an impediment to the API, XENMAPSPACE_gmfn_foreign
is in pretty much the same position.

>  because:
>    - frame is not removed from foreign domain in my case
>    - i don't want to update the m2p with new info.
> 
> Anyways, I put it there for now. With ballooning change in dom0, I'm
> now doing the hcall one frame at a time anyways. We can always enhance
> in the future.
> 
>         case XENMAPSPACE_gmfn_foreign:
>         {
>             rc = _add_foreign_to_pmap_batch(&xatp);
>             rcu_unlock_domain(d);
>             return rc;
>         }
> 
> 
> >> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void)
> >> arg)  
> 
> >Can't XENMEM_remove_from_physmap be used here?
> 
> Well, that calls guest_physmap_remove_page() which calls
> p2m_remove_page which updates the M2P with INVALID_M2P_ENTRY. Whereas,
> i just need to remove from the dom0 p2m and leave M2P as is (mfn to
> domU gmfn). I could add a flag to the struct causing it to just call
> set_p2m_entry() directly?

Would it be useful to track the fact that a p2m entry is foreign
somewhere? That would let you do the appropriate type of teardown etc
without relying on the tools to get it right.

Are there s/w bits available in the p2m entry itself on x86 or do we use
them all already?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 07:22:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 07:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKlh1-0005QD-To; Thu, 19 Apr 2012 07:22:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKlh0-0005Q8-76
	for Xen-devel@lists.xensource.com; Thu, 19 Apr 2012 07:22:14 +0000
Received: from [193.109.254.147:8926] by server-8.bemta-14.messagelabs.com id
	9D/93-23244-52DBF8F4; Thu, 19 Apr 2012 07:22:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334820132!5285072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9852 invoked from network); 19 Apr 2012 07:22:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 07:22:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12019048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 07:22:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Apr 2012 08:22:13 +0100
Message-ID: <1334820132.11493.51.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 19 Apr 2012 08:22:12 +0100
In-Reply-To: <20120418162908.2b790fae@mantra.us.oracle.com>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<1334584402.14560.184.camel@zakaz.uk.xensource.com>
	<20120416185340.72ef5566@mantra.us.oracle.com>
	<1334653528.14560.261.camel@zakaz.uk.xensource.com>
	<20120418162908.2b790fae@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 00:29 +0100, Mukesh Rathor wrote:
> On Tue, 17 Apr 2012 10:05:28 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
> > > On Mon, 16 Apr 2012 14:53:22 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > Sorry, I meant why a whole new subcall instead of a new
> > XENMAPSPACE ;-)
> > 
> > e.g. On ARM I did:
> > 
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 86d02c8..b2adfbe 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -212,11 +212,13 @@ struct xen_add_to_physmap {
> >      uint16_t    size;
> >  
> >      /* Source mapping space. */
> > -#define XENMAPSPACE_shared_info 0 /* shared info page */
> > -#define XENMAPSPACE_grant_table 1 /* grant table page */
> > -#define XENMAPSPACE_gmfn        2 /* GMFN */
> > -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> > -    unsigned int space;
> > +#define XENMAPSPACE_shared_info  0 /* shared info page */
> > +#define XENMAPSPACE_grant_table  1 /* grant table page */
> > +#define XENMAPSPACE_gmfn         2 /* GMFN */
> > +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > +    uint16_t space;
> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
> 
> 
> Well, for several reasons, I didn't use it, mainly, it doesn't allow
> for count. So requests have to come in one frame at a time.

I've got it that way on ARM too at the moment but I was planning to make
it behave like gmfn_range and use the size parameter to map multiple at
a time (unless I've misunderstood what the gmfn_range variant does).

>  Second, none of the common code can be used by my new request,

I don't think that's an impediment to the API, XENMAPSPACE_gmfn_foreign
is in pretty much the same position.

>  because:
>    - frame is not removed from foreign domain in my case
>    - i don't want to update the m2p with new info.
> 
> Anyways, I put it there for now. With ballooning change in dom0, I'm
> now doing the hcall one frame at a time anyways. We can always enhance
> in the future.
> 
>         case XENMAPSPACE_gmfn_foreign:
>         {
>             rc = _add_foreign_to_pmap_batch(&xatp);
>             rcu_unlock_domain(d);
>             return rc;
>         }
> 
> 
> >> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void)
> >> arg)  
> 
> >Can't XENMEM_remove_from_physmap be used here?
> 
> Well, that calls guest_physmap_remove_page() which calls
> p2m_remove_page which updates the M2P with INVALID_M2P_ENTRY. Whereas,
> i just need to remove from the dom0 p2m and leave M2P as is (mfn to
> domU gmfn). I could add a flag to the struct causing it to just call
> set_p2m_entry() directly?

Would it be useful to track the fact that a p2m entry is foreign
somewhere? That would let you do the appropriate type of teardown etc
without relying on the tools to get it right.

Are there s/w bits available in the p2m entry itself on x86 or do we use
them all already?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 07:44:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 07:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKm1q-00064f-Tz; Thu, 19 Apr 2012 07:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKm1o-00064Z-Sr
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 07:43:45 +0000
Received: from [85.158.139.83:36461] by server-11.bemta-5.messagelabs.com id
	10/0A-12959-F22CF8F4; Thu, 19 Apr 2012 07:43:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334821423!24501333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32301 invoked from network); 19 Apr 2012 07:43:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 07:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12019440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 07:43:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Apr 2012 08:43:43 +0100
Message-ID: <1334821422.11493.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ken Hamlin <khamlin@ncfta.net>
Date: Thu, 19 Apr 2012 08:43:42 +0100
In-Reply-To: <FD6F285E37447D4DBB72A9E73C1BD4A2065AD672@Exchange01.pg.ncfta.net>
References: <FD6F285E37447D4DBB72A9E73C1BD4A2065AD672@Exchange01.pg.ncfta.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ether setup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTE4IGF0IDIxOjM3ICswMTAwLCBLZW4gSGFtbGluIHdyb3RlOgo+IEhl
bGxvIGV2ZXJ5b25lLiBUaGlzIGlzIG15IGZpcnN0IHRpbWUgYXR0ZW1wdGluZyB0byB1c2UgWGVu
IGFuZCBJIGFtCj4gaGF2aW5nIHNvbWUgcHJvYmxlbXMuIEkgYW0gdHJ5aW5nIHRvIGJ1aWxkIGEg
WGVuIHN5c3RlbSBzbyB0aGF0IEkgY2FuCj4gdXNlIHRoZSBFdGhlciBwcm9ncmFtIGZvciBtYWx3
YXJlIGFuYWx5c2lzCj4gKGh0dHA6Ly9ldGhlci5ndGlzYy5nYXRlY2guZWR1L3NvdXJjZS5odG1s
KS4KPiAKPiAgCj4gCj4gSeKAmXZlIGluc3RhbGxlZCBEZWJpYW4gNiwgYW5kIGRvd25sb2FkZWQg
dGhlIFhlbiAzLjEuMCBzb3VyY2UuIAoKWGVuIDMuMS4wIGlzIHJlYWxseSB2ZXJ5IG9sZCBpbmRl
ZWQgKGl0J3MgZnJvbSAyMDA3KS4gSSBzdHJvbmdseQpyZWNvbW1lbmQgcnVubmluZyBzb21ldGhp
bmcgbmV3ZXIsIGxpa2UgWGVuIDQuMSBmb3IgZXhhbXBsZS4KCklmIHlvdSBjYW4ndCBvciB3b24n
dCBkbyB0aGF0IHRoZW4gdGhlIGFkdmljZSBpbgpodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVu
Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDA3LTA3L21zZzAwNjg4Lmh0bWwgc2VlbXMg
bGlrZSB5b3VyIGJlc3QgYmV0LgoKSW4gZ2VuZXJhbCB5b3Ugc2hvdWxkbid0IGV4cGVjdCBtYW55
IHBlb3BsZSB0byBiZSBpbnRlcmVzdGVkIGluIGFueQppc3N1ZXMgeW91IGhhdmUgd2l0aCAzLjEu
MCBhbnkgbW9yZSB0aG91Z2gsIHNvcnJ5LgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 19 07:44:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 07:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKm1q-00064f-Tz; Thu, 19 Apr 2012 07:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SKm1o-00064Z-Sr
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 07:43:45 +0000
Received: from [85.158.139.83:36461] by server-11.bemta-5.messagelabs.com id
	10/0A-12959-F22CF8F4; Thu, 19 Apr 2012 07:43:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334821423!24501333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTA4OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32301 invoked from network); 19 Apr 2012 07:43:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 07:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="12019440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 07:43:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Apr 2012 08:43:43 +0100
Message-ID: <1334821422.11493.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ken Hamlin <khamlin@ncfta.net>
Date: Thu, 19 Apr 2012 08:43:42 +0100
In-Reply-To: <FD6F285E37447D4DBB72A9E73C1BD4A2065AD672@Exchange01.pg.ncfta.net>
References: <FD6F285E37447D4DBB72A9E73C1BD4A2065AD672@Exchange01.pg.ncfta.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ether setup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTE4IGF0IDIxOjM3ICswMTAwLCBLZW4gSGFtbGluIHdyb3RlOgo+IEhl
bGxvIGV2ZXJ5b25lLiBUaGlzIGlzIG15IGZpcnN0IHRpbWUgYXR0ZW1wdGluZyB0byB1c2UgWGVu
IGFuZCBJIGFtCj4gaGF2aW5nIHNvbWUgcHJvYmxlbXMuIEkgYW0gdHJ5aW5nIHRvIGJ1aWxkIGEg
WGVuIHN5c3RlbSBzbyB0aGF0IEkgY2FuCj4gdXNlIHRoZSBFdGhlciBwcm9ncmFtIGZvciBtYWx3
YXJlIGFuYWx5c2lzCj4gKGh0dHA6Ly9ldGhlci5ndGlzYy5nYXRlY2guZWR1L3NvdXJjZS5odG1s
KS4KPiAKPiAgCj4gCj4gSeKAmXZlIGluc3RhbGxlZCBEZWJpYW4gNiwgYW5kIGRvd25sb2FkZWQg
dGhlIFhlbiAzLjEuMCBzb3VyY2UuIAoKWGVuIDMuMS4wIGlzIHJlYWxseSB2ZXJ5IG9sZCBpbmRl
ZWQgKGl0J3MgZnJvbSAyMDA3KS4gSSBzdHJvbmdseQpyZWNvbW1lbmQgcnVubmluZyBzb21ldGhp
bmcgbmV3ZXIsIGxpa2UgWGVuIDQuMSBmb3IgZXhhbXBsZS4KCklmIHlvdSBjYW4ndCBvciB3b24n
dCBkbyB0aGF0IHRoZW4gdGhlIGFkdmljZSBpbgpodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVu
Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDA3LTA3L21zZzAwNjg4Lmh0bWwgc2VlbXMg
bGlrZSB5b3VyIGJlc3QgYmV0LgoKSW4gZ2VuZXJhbCB5b3Ugc2hvdWxkbid0IGV4cGVjdCBtYW55
IHBlb3BsZSB0byBiZSBpbnRlcmVzdGVkIGluIGFueQppc3N1ZXMgeW91IGhhdmUgd2l0aCAzLjEu
MCBhbnkgbW9yZSB0aG91Z2gsIHNvcnJ5LgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 19 08:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKmi1-00070x-Aw; Thu, 19 Apr 2012 08:27:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKmi0-00070s-Dg
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 08:27:20 +0000
Received: from [85.158.143.35:64037] by server-2.bemta-4.messagelabs.com id
	65/8C-17550-76CCF8F4; Thu, 19 Apr 2012 08:27:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334824038!10654600!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16081 invoked from network); 19 Apr 2012 08:27:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 08:27:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKmhx-0006DI-9T; Thu, 19 Apr 2012 08:27:17 +0000
Date: Thu, 19 Apr 2012 09:27:17 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120419082717.GA23663@ocelot.phlegethon.org>
References: <CBB4448D.3E643%keir@xen.org> <CBB44859.3E648%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0DCE1C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0DCE1C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 05:19 +0000 on 19 Apr (1334812779), Zhang, Yang Z wrote:
> There have no problem with this patch, it works well. But it cannot
> fix the win8 issue. It seems there has some other issues with hpet. I
> will look into it.  Thanks for your quick patch.

The lock in hvm_get_guest_time() will still be serializing the hpet
reads.  But since it needs to update a shared variable, that will need to
haul cachelines around anyway. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 08:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKmi1-00070x-Aw; Thu, 19 Apr 2012 08:27:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKmi0-00070s-Dg
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 08:27:20 +0000
Received: from [85.158.143.35:64037] by server-2.bemta-4.messagelabs.com id
	65/8C-17550-76CCF8F4; Thu, 19 Apr 2012 08:27:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334824038!10654600!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16081 invoked from network); 19 Apr 2012 08:27:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 08:27:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKmhx-0006DI-9T; Thu, 19 Apr 2012 08:27:17 +0000
Date: Thu, 19 Apr 2012 09:27:17 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120419082717.GA23663@ocelot.phlegethon.org>
References: <CBB4448D.3E643%keir@xen.org> <CBB44859.3E648%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0DCE1C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0DCE1C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 05:19 +0000 on 19 Apr (1334812779), Zhang, Yang Z wrote:
> There have no problem with this patch, it works well. But it cannot
> fix the win8 issue. It seems there has some other issues with hpet. I
> will look into it.  Thanks for your quick patch.

The lock in hvm_get_guest_time() will still be serializing the hpet
reads.  But since it needs to update a shared variable, that will need to
haul cachelines around anyway. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 08:47:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKn0n-0007Mr-6K; Thu, 19 Apr 2012 08:46:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SKn0l-0007Mm-7S
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 08:46:43 +0000
Received: from [85.158.143.35:29901] by server-2.bemta-4.messagelabs.com id
	7A/AF-17550-2F0DF8F4; Thu, 19 Apr 2012 08:46:42 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334825199!10658529!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30982 invoked from network); 19 Apr 2012 08:46:40 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 08:46:40 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id B0305DBCAE
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 16:46:23 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so7353451vcb.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 01:46:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.201.199 with SMTP id fb7mr692214vcb.15.1334825181943; Thu,
	19 Apr 2012 01:46:21 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Thu, 19 Apr 2012 01:46:21 -0700 (PDT)
In-Reply-To: <20120416203210.GD14982@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
	<20120416203210.GD14982@phenom.dumpdata.com>
Date: Thu, 19 Apr 2012 16:46:21 +0800
Message-ID: <CAF1ivSZ8H2jp6sv=F8DXBAG9Wi87zCLh5Lbh+aeN66eJg_F1_Q@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 4:32 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Apr 15, 2012 at 02:09:32PM +0800, Lin Ming wrote:
>> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>> ---
>> =A0arch/x86/include/asm/xen/events.h | =A0 =A01 +
>> =A0arch/x86/xen/smp.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 30 ++++++++++=
++++++++++++++++++++
>> =A02 files changed, 31 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xe=
n/events.h
>> index 1df3541..cc146d5 100644
>> --- a/arch/x86/include/asm/xen/events.h
>> +++ b/arch/x86/include/asm/xen/events.h
>> @@ -6,6 +6,7 @@ enum ipi_vector {
>> =A0 =A0 =A0 XEN_CALL_FUNCTION_VECTOR,
>> =A0 =A0 =A0 XEN_CALL_FUNCTION_SINGLE_VECTOR,
>> =A0 =A0 =A0 XEN_SPIN_UNLOCK_VECTOR,
>> + =A0 =A0 XEN_IRQ_WORK_VECTOR,
>>
>> =A0 =A0 =A0 XEN_NR_IPIS,
>> =A0};
>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>> index 2dc6628..92ad12d 100644
>> --- a/arch/x86/xen/smp.c
>> +++ b/arch/x86/xen/smp.c
>> @@ -16,6 +16,7 @@
>> =A0#include <linux/err.h>
>> =A0#include <linux/slab.h>
>> =A0#include <linux/smp.h>
>> +#include <linux/irq_work.h>
>>
>> =A0#include <asm/paravirt.h>
>> =A0#include <asm/desc.h>
>> @@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
>> =A0static DEFINE_PER_CPU(int, xen_resched_irq);
>> =A0static DEFINE_PER_CPU(int, xen_callfunc_irq);
>> =A0static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
>> +static DEFINE_PER_CPU(int, xen_irq_work);
>> =A0static DEFINE_PER_CPU(int, xen_debug_irq) =3D -1;
>>
>> =A0static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
>> =A0static irqreturn_t xen_call_function_single_interrupt(int irq, void *=
dev_id);
>> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
>>
>> =A0/*
>> =A0 * Reschedule call back.
>> @@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto fail;
>> =A0 =A0 =A0 per_cpu(xen_callfuncsingle_irq, cpu) =3D rc;
>>
>> + =A0 =A0 callfunc_name =3D kasprintf(GFP_KERNEL, "irqwork%d", cpu);
>> + =A0 =A0 rc =3D bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen_ir=
q_work_interrupt,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IRQF_D=
ISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 callfu=
nc_name,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL);
>> + =A0 =A0 if (rc < 0)
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto fail;
>> + =A0 =A0 per_cpu(xen_irq_work, cpu) =3D rc;
>> +
>> =A0 =A0 =A0 return 0;
>>
>> =A0 fail:
>> @@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
>> =A0 =A0 =A0 if (per_cpu(xen_callfuncsingle_irq, cpu) >=3D 0)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_callfuncs=
ingle_irq, cpu),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0NULL);
>> + =A0 =A0 if (per_cpu(xen_irq_work, cpu) >=3D 0)
>> + =A0 =A0 =A0 =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_irq_work, c=
pu), NULL);
>>
>> =A0 =A0 =A0 return rc;
>> =A0}
>> @@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
>> =A0 =A0 =A0 case CALL_FUNCTION_SINGLE_VECTOR:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen_vector =3D XEN_CALL_FUNCTION_SINGLE_VECT=
OR;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> + =A0 =A0 case IRQ_WORK_VECTOR:
>> + =A0 =A0 =A0 =A0 =A0 =A0 xen_vector =3D XEN_IRQ_WORK_VECTOR;
>> + =A0 =A0 =A0 =A0 =A0 =A0 break;
>> =A0 =A0 =A0 default:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen_vector =3D -1;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_ERR "xen: vector 0x%x is not imp=
lemented\n",
>> @@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interru=
pt(int irq, void *dev_id)
>> =A0 =A0 =A0 return IRQ_HANDLED;
>> =A0}
>>
>> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
>> +{
>> + =A0 =A0 irq_enter();
>> + =A0 =A0 inc_irq_stat(apic_irq_work_irqs);
>> + =A0 =A0 irq_work_run();
>
> I think this usually done the other way around:
>
> irq_work_run()
> inc_irq_stat(apic_irq_work_irqs)
>
> Or is there an excellent reason for doing it this way?

Copy & paste from smp_irq_work_interrupt().
But I think there is no much difference.

Anyway, I can change it if needed.

Thanks,
Lin Ming

>
>> + =A0 =A0 irq_exit();
>> +
>> + =A0 =A0 return IRQ_HANDLED;
>> +}
>> +
>> =A0static const struct smp_ops xen_smp_ops __initconst =3D {
>> =A0 =A0 =A0 .smp_prepare_boot_cpu =3D xen_smp_prepare_boot_cpu,
>> =A0 =A0 =A0 .smp_prepare_cpus =3D xen_smp_prepare_cpus,
>> @@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
>> =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
>> =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
>> =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),=
 NULL);
>> + =A0 =A0 unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
>> =A0 =A0 =A0 native_cpu_die(cpu);
>> =A0}
>>
>> --
>> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 08:47:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKn0n-0007Mr-6K; Thu, 19 Apr 2012 08:46:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SKn0l-0007Mm-7S
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 08:46:43 +0000
Received: from [85.158.143.35:29901] by server-2.bemta-4.messagelabs.com id
	7A/AF-17550-2F0DF8F4; Thu, 19 Apr 2012 08:46:42 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334825199!10658529!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30982 invoked from network); 19 Apr 2012 08:46:40 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-2.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 08:46:40 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id B0305DBCAE
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 16:46:23 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so7353451vcb.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 01:46:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.201.199 with SMTP id fb7mr692214vcb.15.1334825181943; Thu,
	19 Apr 2012 01:46:21 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Thu, 19 Apr 2012 01:46:21 -0700 (PDT)
In-Reply-To: <20120416203210.GD14982@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
	<20120416203210.GD14982@phenom.dumpdata.com>
Date: Thu, 19 Apr 2012 16:46:21 +0800
Message-ID: <CAF1ivSZ8H2jp6sv=F8DXBAG9Wi87zCLh5Lbh+aeN66eJg_F1_Q@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 4:32 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Apr 15, 2012 at 02:09:32PM +0800, Lin Ming wrote:
>> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>> ---
>> =A0arch/x86/include/asm/xen/events.h | =A0 =A01 +
>> =A0arch/x86/xen/smp.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 30 ++++++++++=
++++++++++++++++++++
>> =A02 files changed, 31 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xe=
n/events.h
>> index 1df3541..cc146d5 100644
>> --- a/arch/x86/include/asm/xen/events.h
>> +++ b/arch/x86/include/asm/xen/events.h
>> @@ -6,6 +6,7 @@ enum ipi_vector {
>> =A0 =A0 =A0 XEN_CALL_FUNCTION_VECTOR,
>> =A0 =A0 =A0 XEN_CALL_FUNCTION_SINGLE_VECTOR,
>> =A0 =A0 =A0 XEN_SPIN_UNLOCK_VECTOR,
>> + =A0 =A0 XEN_IRQ_WORK_VECTOR,
>>
>> =A0 =A0 =A0 XEN_NR_IPIS,
>> =A0};
>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>> index 2dc6628..92ad12d 100644
>> --- a/arch/x86/xen/smp.c
>> +++ b/arch/x86/xen/smp.c
>> @@ -16,6 +16,7 @@
>> =A0#include <linux/err.h>
>> =A0#include <linux/slab.h>
>> =A0#include <linux/smp.h>
>> +#include <linux/irq_work.h>
>>
>> =A0#include <asm/paravirt.h>
>> =A0#include <asm/desc.h>
>> @@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
>> =A0static DEFINE_PER_CPU(int, xen_resched_irq);
>> =A0static DEFINE_PER_CPU(int, xen_callfunc_irq);
>> =A0static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
>> +static DEFINE_PER_CPU(int, xen_irq_work);
>> =A0static DEFINE_PER_CPU(int, xen_debug_irq) =3D -1;
>>
>> =A0static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
>> =A0static irqreturn_t xen_call_function_single_interrupt(int irq, void *=
dev_id);
>> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
>>
>> =A0/*
>> =A0 * Reschedule call back.
>> @@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto fail;
>> =A0 =A0 =A0 per_cpu(xen_callfuncsingle_irq, cpu) =3D rc;
>>
>> + =A0 =A0 callfunc_name =3D kasprintf(GFP_KERNEL, "irqwork%d", cpu);
>> + =A0 =A0 rc =3D bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen_ir=
q_work_interrupt,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IRQF_D=
ISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 callfu=
nc_name,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL);
>> + =A0 =A0 if (rc < 0)
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto fail;
>> + =A0 =A0 per_cpu(xen_irq_work, cpu) =3D rc;
>> +
>> =A0 =A0 =A0 return 0;
>>
>> =A0 fail:
>> @@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
>> =A0 =A0 =A0 if (per_cpu(xen_callfuncsingle_irq, cpu) >=3D 0)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_callfuncs=
ingle_irq, cpu),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0NULL);
>> + =A0 =A0 if (per_cpu(xen_irq_work, cpu) >=3D 0)
>> + =A0 =A0 =A0 =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_irq_work, c=
pu), NULL);
>>
>> =A0 =A0 =A0 return rc;
>> =A0}
>> @@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
>> =A0 =A0 =A0 case CALL_FUNCTION_SINGLE_VECTOR:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen_vector =3D XEN_CALL_FUNCTION_SINGLE_VECT=
OR;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> + =A0 =A0 case IRQ_WORK_VECTOR:
>> + =A0 =A0 =A0 =A0 =A0 =A0 xen_vector =3D XEN_IRQ_WORK_VECTOR;
>> + =A0 =A0 =A0 =A0 =A0 =A0 break;
>> =A0 =A0 =A0 default:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xen_vector =3D -1;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_ERR "xen: vector 0x%x is not imp=
lemented\n",
>> @@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interru=
pt(int irq, void *dev_id)
>> =A0 =A0 =A0 return IRQ_HANDLED;
>> =A0}
>>
>> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
>> +{
>> + =A0 =A0 irq_enter();
>> + =A0 =A0 inc_irq_stat(apic_irq_work_irqs);
>> + =A0 =A0 irq_work_run();
>
> I think this usually done the other way around:
>
> irq_work_run()
> inc_irq_stat(apic_irq_work_irqs)
>
> Or is there an excellent reason for doing it this way?

Copy & paste from smp_irq_work_interrupt().
But I think there is no much difference.

Anyway, I can change it if needed.

Thanks,
Lin Ming

>
>> + =A0 =A0 irq_exit();
>> +
>> + =A0 =A0 return IRQ_HANDLED;
>> +}
>> +
>> =A0static const struct smp_ops xen_smp_ops __initconst =3D {
>> =A0 =A0 =A0 .smp_prepare_boot_cpu =3D xen_smp_prepare_boot_cpu,
>> =A0 =A0 =A0 .smp_prepare_cpus =3D xen_smp_prepare_cpus,
>> @@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
>> =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
>> =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
>> =A0 =A0 =A0 unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),=
 NULL);
>> + =A0 =A0 unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
>> =A0 =A0 =A0 native_cpu_die(cpu);
>> =A0}
>>
>> --
>> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 08:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKn1l-0007Pb-Pm; Thu, 19 Apr 2012 08:47:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKn1j-0007PU-Kj
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 08:47:43 +0000
Received: from [85.158.143.35:37037] by server-1.bemta-4.messagelabs.com id
	FD/60-20925-E21DF8F4; Thu, 19 Apr 2012 08:47:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334825261!13641575!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9460 invoked from network); 19 Apr 2012 08:47:41 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 08:47:41 -0000
Received: by bkwj5 with SMTP id j5so7303475bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 01:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=Vq2Hf12izQLbmXnuDBechWMnxV2UiA4TE9cA8rJJp6o=;
	b=uye3zNd5jchmvJISjcQ36lhTTncm2BToVxNcndJej6XEFYMf+UDJRbzyHrategYMec
	SjGJCuL3bRR+Qm+iBaDqTQRiZ3RGdbcrNLxphHJpYXK9bT85zWd7UFkjE6UZvUFSlC4P
	k1qauXmM4AzcFlj7BWghnl3BCd243II+JqQ38fmOFDY+fdI2yBSYg4IDeKQtZJIkvhGA
	WKAcx0QAcm7GBVpORQvi/GZjcv0hwPB3PpsiejAQUZfyVTsT3DYPT8mvE1iTcqvQLxcz
	sTOl2VhuikXHRX3xyJsxI0G2YiXHwpOoYB7Z1QrXbrLll8NIAunQkSvTeIAjfqPU2tuq
	LmUg==
Received: by 10.205.81.3 with SMTP id zw3mr363086bkb.30.1334825260928;
	Thu, 19 Apr 2012 01:47:40 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id iv11sm2413316bkc.16.2012.04.19.01.47.39
	(version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 01:47:40 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Apr 2012 09:47:27 +0100
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>,
	"Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <CBB58FB0.3E7AC%keir@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQ==
In-Reply-To: <20120419082717.GA23663@ocelot.phlegethon.org>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3417673660_5389804"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3417673660_5389804
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 19/04/2012 09:27, "Tim Deegan" <tim@xen.org> wrote:

> At 05:19 +0000 on 19 Apr (1334812779), Zhang, Yang Z wrote:
>> There have no problem with this patch, it works well. But it cannot
>> fix the win8 issue. It seems there has some other issues with hpet. I
>> will look into it.  Thanks for your quick patch.
> 
> The lock in hvm_get_guest_time() will still be serializing the hpet
> reads.  But since it needs to update a shared variable, that will need to
> haul cachelines around anyway.

Yes, that's true. You could try the attached hacky patch out of interest, to
see what that lock is costing you in your scenario. But if we want
consistent monotonically-increasing guest time, I suspect we can't get rid
of the lock, so that's going to limit our scalability unavoidably. Shame.

 -- Keir

> Tim.
> 


--B_3417673660_5389804
Content-type: application/octet-stream; name="00-lockfree-hvm-time"
Content-disposition: attachment;
	filename="00-lockfree-hvm-time"
Content-transfer-encoding: base64


ZGlmZiAtciA3Yzc3N2NiOGY3MDUgeGVuL2FyY2gveDg2L2h2bS92cHQuYwotLS0gYS94ZW4v
YXJjaC94ODYvaHZtL3ZwdC5jCVdlZCBBcHIgMTggMTY6NDk6NTUgMjAxMiArMDEwMAorKysg
Yi94ZW4vYXJjaC94ODYvaHZtL3ZwdC5jCVRodSBBcHIgMTkgMDk6NDU6NDMgMjAxMiArMDEw
MApAQCAtNDMsMTQgKzQzLDcgQEAgdTY0IGh2bV9nZXRfZ3Vlc3RfdGltZShzdHJ1Y3QgdmNw
dSAqdikKICAgICAvKiBDYWxsZWQgZnJvbSBkZXZpY2UgbW9kZWxzIHNoYXJlZCB3aXRoIFBW
IGd1ZXN0cy4gQmUgY2FyZWZ1bC4gKi8KICAgICBBU1NFUlQoaXNfaHZtX3ZjcHUodikpOwog
Ci0gICAgc3Bpbl9sb2NrKCZwbC0+cGxfdGltZV9sb2NrKTsKICAgICBub3cgPSBnZXRfc190
aW1lKCkgKyBwbC0+c3RpbWVfb2Zmc2V0OwotICAgIGlmICggKGludDY0X3QpKG5vdyAtIHBs
LT5sYXN0X2d1ZXN0X3RpbWUpID4gMCApCi0gICAgICAgIHBsLT5sYXN0X2d1ZXN0X3RpbWUg
PSBub3c7Ci0gICAgZWxzZQotICAgICAgICBub3cgPSArK3BsLT5sYXN0X2d1ZXN0X3RpbWU7
Ci0gICAgc3Bpbl91bmxvY2soJnBsLT5wbF90aW1lX2xvY2spOwotCiAgICAgcmV0dXJuIG5v
dyArIHYtPmFyY2guaHZtX3ZjcHUuc3RpbWVfb2Zmc2V0OwogfQogCg==
--B_3417673660_5389804
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3417673660_5389804--




From xen-devel-bounces@lists.xen.org Thu Apr 19 08:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKn1l-0007Pb-Pm; Thu, 19 Apr 2012 08:47:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SKn1j-0007PU-Kj
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 08:47:43 +0000
Received: from [85.158.143.35:37037] by server-1.bemta-4.messagelabs.com id
	FD/60-20925-E21DF8F4; Thu, 19 Apr 2012 08:47:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334825261!13641575!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9460 invoked from network); 19 Apr 2012 08:47:41 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 08:47:41 -0000
Received: by bkwj5 with SMTP id j5so7303475bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 01:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=Vq2Hf12izQLbmXnuDBechWMnxV2UiA4TE9cA8rJJp6o=;
	b=uye3zNd5jchmvJISjcQ36lhTTncm2BToVxNcndJej6XEFYMf+UDJRbzyHrategYMec
	SjGJCuL3bRR+Qm+iBaDqTQRiZ3RGdbcrNLxphHJpYXK9bT85zWd7UFkjE6UZvUFSlC4P
	k1qauXmM4AzcFlj7BWghnl3BCd243II+JqQ38fmOFDY+fdI2yBSYg4IDeKQtZJIkvhGA
	WKAcx0QAcm7GBVpORQvi/GZjcv0hwPB3PpsiejAQUZfyVTsT3DYPT8mvE1iTcqvQLxcz
	sTOl2VhuikXHRX3xyJsxI0G2YiXHwpOoYB7Z1QrXbrLll8NIAunQkSvTeIAjfqPU2tuq
	LmUg==
Received: by 10.205.81.3 with SMTP id zw3mr363086bkb.30.1334825260928;
	Thu, 19 Apr 2012 01:47:40 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id iv11sm2413316bkc.16.2012.04.19.01.47.39
	(version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 01:47:40 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Apr 2012 09:47:27 +0100
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>,
	"Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <CBB58FB0.3E7AC%keir@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQ==
In-Reply-To: <20120419082717.GA23663@ocelot.phlegethon.org>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3417673660_5389804"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3417673660_5389804
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 19/04/2012 09:27, "Tim Deegan" <tim@xen.org> wrote:

> At 05:19 +0000 on 19 Apr (1334812779), Zhang, Yang Z wrote:
>> There have no problem with this patch, it works well. But it cannot
>> fix the win8 issue. It seems there has some other issues with hpet. I
>> will look into it.  Thanks for your quick patch.
> 
> The lock in hvm_get_guest_time() will still be serializing the hpet
> reads.  But since it needs to update a shared variable, that will need to
> haul cachelines around anyway.

Yes, that's true. You could try the attached hacky patch out of interest, to
see what that lock is costing you in your scenario. But if we want
consistent monotonically-increasing guest time, I suspect we can't get rid
of the lock, so that's going to limit our scalability unavoidably. Shame.

 -- Keir

> Tim.
> 


--B_3417673660_5389804
Content-type: application/octet-stream; name="00-lockfree-hvm-time"
Content-disposition: attachment;
	filename="00-lockfree-hvm-time"
Content-transfer-encoding: base64


ZGlmZiAtciA3Yzc3N2NiOGY3MDUgeGVuL2FyY2gveDg2L2h2bS92cHQuYwotLS0gYS94ZW4v
YXJjaC94ODYvaHZtL3ZwdC5jCVdlZCBBcHIgMTggMTY6NDk6NTUgMjAxMiArMDEwMAorKysg
Yi94ZW4vYXJjaC94ODYvaHZtL3ZwdC5jCVRodSBBcHIgMTkgMDk6NDU6NDMgMjAxMiArMDEw
MApAQCAtNDMsMTQgKzQzLDcgQEAgdTY0IGh2bV9nZXRfZ3Vlc3RfdGltZShzdHJ1Y3QgdmNw
dSAqdikKICAgICAvKiBDYWxsZWQgZnJvbSBkZXZpY2UgbW9kZWxzIHNoYXJlZCB3aXRoIFBW
IGd1ZXN0cy4gQmUgY2FyZWZ1bC4gKi8KICAgICBBU1NFUlQoaXNfaHZtX3ZjcHUodikpOwog
Ci0gICAgc3Bpbl9sb2NrKCZwbC0+cGxfdGltZV9sb2NrKTsKICAgICBub3cgPSBnZXRfc190
aW1lKCkgKyBwbC0+c3RpbWVfb2Zmc2V0OwotICAgIGlmICggKGludDY0X3QpKG5vdyAtIHBs
LT5sYXN0X2d1ZXN0X3RpbWUpID4gMCApCi0gICAgICAgIHBsLT5sYXN0X2d1ZXN0X3RpbWUg
PSBub3c7Ci0gICAgZWxzZQotICAgICAgICBub3cgPSArK3BsLT5sYXN0X2d1ZXN0X3RpbWU7
Ci0gICAgc3Bpbl91bmxvY2soJnBsLT5wbF90aW1lX2xvY2spOwotCiAgICAgcmV0dXJuIG5v
dyArIHYtPmFyY2guaHZtX3ZjcHUuc3RpbWVfb2Zmc2V0OwogfQogCg==
--B_3417673660_5389804
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3417673660_5389804--




From xen-devel-bounces@lists.xen.org Thu Apr 19 08:49:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKn2p-0007U2-IG; Thu, 19 Apr 2012 08:48:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1SKn2n-0007Ts-Uf
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 08:48:50 +0000
Received: from [85.158.138.51:63547] by server-12.bemta-3.messagelabs.com id
	DF/64-29760-171DF8F4; Thu, 19 Apr 2012 08:48:49 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334825328!22810608!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11083 invoked from network); 19 Apr 2012 08:48:48 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 08:48:48 -0000
Received: by wgbed3 with SMTP id ed3so6231774wgb.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 01:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=/sJagt4kYokOIWqDHd3ELViE2yNlBYYcnmAJ5+ZP+s0=;
	b=y+MJZK7O45hddkoqiRyjiOgtd8LJ5ZJKc0DM1nqkBGRakR+oP75VkJ4lXpsD0GlQp3
	MxffMKcq5cba5jBFsBSeDUsHMmxpwJ50Ke01y61knoLQ9/qUxAjxL/YG+W8heWNXNgaU
	pMflqWwJqe6AYUWeZi6P8PKG8zYxZj4zLsdU4xVKV4qX1vbR/wmZXNEJox5q9+GOfy6o
	zbMWNsFANrb2a3A6HsgTbSD6t7uTFXDmMoWpHDKAFt5/RMypGqLjMVUC7+KArdGLR2sv
	KoddvSgFmJm7pSaT0iMlbYK1VlnCpGHxyimA+H9VlB7r+qVqlgLahxhPkSjmjXw6VCzS
	hR2g==
Received: by 10.180.92.71 with SMTP id ck7mr3118506wib.21.1334825328031; Thu,
	19 Apr 2012 01:48:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.97.129 with HTTP; Thu, 19 Apr 2012 01:48:07 -0700 (PDT)
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Thu, 19 Apr 2012 14:18:07 +0530
Message-ID: <CAESzvYSkCozGjRayO-kdZigA0LZawD+B=CibjpaT1ae00P0NMQ@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen entry point and exit point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5273389766601952225=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5273389766601952225==
Content-Type: multipart/alternative; boundary=f46d043c807083b96c04be043dd0

--f46d043c807083b96c04be043dd0
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I need to find the points where we enters into hypercall (for all the
hypercalls) execution and from where we come out... from what i have
understood entry-point is
somewhere in arch/x86/x86_32/entry.S ...but  exactly where and what about
exit point?

 --
Nitin Gupta

--f46d043c807083b96c04be043dd0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I need to find the points where we enters into hypercall (for al=
l the hypercalls) execution and from where we come out... from what i have =
understood entry-point is <br>somewhere in arch/x86/x86_32/entry.S ...but=
=A0 exactly where and what about exit point?<br>

<br>=A0-- <br>Nitin Gupta<br><br><br>

--f46d043c807083b96c04be043dd0--


--===============5273389766601952225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5273389766601952225==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 08:49:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 08:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKn2p-0007U2-IG; Thu, 19 Apr 2012 08:48:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1SKn2n-0007Ts-Uf
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 08:48:50 +0000
Received: from [85.158.138.51:63547] by server-12.bemta-3.messagelabs.com id
	DF/64-29760-171DF8F4; Thu, 19 Apr 2012 08:48:49 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334825328!22810608!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11083 invoked from network); 19 Apr 2012 08:48:48 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 08:48:48 -0000
Received: by wgbed3 with SMTP id ed3so6231774wgb.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 01:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=/sJagt4kYokOIWqDHd3ELViE2yNlBYYcnmAJ5+ZP+s0=;
	b=y+MJZK7O45hddkoqiRyjiOgtd8LJ5ZJKc0DM1nqkBGRakR+oP75VkJ4lXpsD0GlQp3
	MxffMKcq5cba5jBFsBSeDUsHMmxpwJ50Ke01y61knoLQ9/qUxAjxL/YG+W8heWNXNgaU
	pMflqWwJqe6AYUWeZi6P8PKG8zYxZj4zLsdU4xVKV4qX1vbR/wmZXNEJox5q9+GOfy6o
	zbMWNsFANrb2a3A6HsgTbSD6t7uTFXDmMoWpHDKAFt5/RMypGqLjMVUC7+KArdGLR2sv
	KoddvSgFmJm7pSaT0iMlbYK1VlnCpGHxyimA+H9VlB7r+qVqlgLahxhPkSjmjXw6VCzS
	hR2g==
Received: by 10.180.92.71 with SMTP id ck7mr3118506wib.21.1334825328031; Thu,
	19 Apr 2012 01:48:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.97.129 with HTTP; Thu, 19 Apr 2012 01:48:07 -0700 (PDT)
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Thu, 19 Apr 2012 14:18:07 +0530
Message-ID: <CAESzvYSkCozGjRayO-kdZigA0LZawD+B=CibjpaT1ae00P0NMQ@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen entry point and exit point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5273389766601952225=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5273389766601952225==
Content-Type: multipart/alternative; boundary=f46d043c807083b96c04be043dd0

--f46d043c807083b96c04be043dd0
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I need to find the points where we enters into hypercall (for all the
hypercalls) execution and from where we come out... from what i have
understood entry-point is
somewhere in arch/x86/x86_32/entry.S ...but  exactly where and what about
exit point?

 --
Nitin Gupta

--f46d043c807083b96c04be043dd0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I need to find the points where we enters into hypercall (for al=
l the hypercalls) execution and from where we come out... from what i have =
understood entry-point is <br>somewhere in arch/x86/x86_32/entry.S ...but=
=A0 exactly where and what about exit point?<br>

<br>=A0-- <br>Nitin Gupta<br><br><br>

--f46d043c807083b96c04be043dd0--


--===============5273389766601952225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5273389766601952225==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 11:00:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 11:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKp5L-0000bK-1u; Thu, 19 Apr 2012 10:59:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKp5I-0000bF-Bf
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 10:59:33 +0000
Received: from [85.158.138.51:60291] by server-10.bemta-3.messagelabs.com id
	20/5E-29478-310FF8F4; Thu, 19 Apr 2012 10:59:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334833170!22854951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25408 invoked from network); 19 Apr 2012 10:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 10:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="12024227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 10:59:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 11:59:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKp5B-00005L-NN;
	Thu, 19 Apr 2012 10:59:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKp5B-0007sR-GI;
	Thu, 19 Apr 2012 11:59:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12723-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 11:59:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12723: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12723 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12723/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv            9 guest-start                 fail pass in 12721
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12721
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                  fail pass in 12721
 test-amd64-i386-xl-multivcpu  9 guest-start        fail in 12721 pass in 12723

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12716

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 12721 never pass

version targeted for testing:
 xen                  7c777cb8f705
baseline version:
 xen                  e6b20ec1824c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7c777cb8f705
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 7c777cb8f705
+ branch=xen-unstable
+ revision=7c777cb8f705
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7c777cb8f705 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 11 changes to 11 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 11:00:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 11:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKp5L-0000bK-1u; Thu, 19 Apr 2012 10:59:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKp5I-0000bF-Bf
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 10:59:33 +0000
Received: from [85.158.138.51:60291] by server-10.bemta-3.messagelabs.com id
	20/5E-29478-310FF8F4; Thu, 19 Apr 2012 10:59:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334833170!22854951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25408 invoked from network); 19 Apr 2012 10:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 10:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="12024227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 10:59:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 11:59:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKp5B-00005L-NN;
	Thu, 19 Apr 2012 10:59:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKp5B-0007sR-GI;
	Thu, 19 Apr 2012 11:59:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12723-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 11:59:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12723: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12723 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12723/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv            9 guest-start                 fail pass in 12721
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12721
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                  fail pass in 12721
 test-amd64-i386-xl-multivcpu  9 guest-start        fail in 12721 pass in 12723

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12716

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 12721 never pass

version targeted for testing:
 xen                  7c777cb8f705
baseline version:
 xen                  e6b20ec1824c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7c777cb8f705
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 7c777cb8f705
+ branch=xen-unstable
+ revision=7c777cb8f705
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7c777cb8f705 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 11 changes to 11 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 11:33:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 11:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKpbW-0001O9-4j; Thu, 19 Apr 2012 11:32:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKpbT-0001Nw-Qg
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 11:32:48 +0000
Received: from [85.158.139.83:7652] by server-12.bemta-5.messagelabs.com id
	C2/8F-05587-FD7FF8F4; Thu, 19 Apr 2012 11:32:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334835166!13279183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3784 invoked from network); 19 Apr 2012 11:32:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 11:32:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="12024999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 11:32:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 12:32:42 +0100
Date: Thu, 19 Apr 2012 12:37:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.00.1204191232590.26786@kaball-desktop>
References: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	konrad <konrad@localhost.localdomain>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/xenbus: Add quirk to deal with
 misconfigured backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 18 Apr 2012, Konrad Rzeszutek Wilk wrote:
> From: konrad <konrad@localhost.localdomain>

wrong email address


> A rather annoying and common case is when booting a PVonHVM guest
> and exposing the PV KBD and PV VFB - as both of those do not
> make any sense.

I would rather write: "as broken toolstacks don't always initialize the
backends correctly."


> The HVM guest is using the VGA driver and the emulated
> keyboard for this. So we provide a very basic quirk framework
> (can be expanded in the future) to not wait for 6 minutes for those devices
> to initialize - they never wont.
> 
> To trigger this, put this in your guest config:
> 
> vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
> 
> instead of this:
> vnc=1
> vnclisten="0.0.0.0"
> 
> [v3: Split delay in non-essential (30 seconds) and essential
>  devices per Ian and Stefano suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>quirk
> ---
>  drivers/xen/xenbus/xenbus_probe_frontend.c |   69 +++++++++++++++++++++------
>  1 files changed, 53 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> index f20c5f1..7422913 100644
> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -135,7 +135,7 @@ static int read_backend_details(struct xenbus_device *xendev)
>  	return xenbus_read_otherend_details(xendev, "backend-id", "backend");
>  }
>  
> -static int is_device_connecting(struct device *dev, void *data)
> +static int is_device_connecting(struct device *dev, void *data, bool ignore_vkbd)
>  {
>  	struct xenbus_device *xendev = to_xenbus_device(dev);
>  	struct device_driver *drv = data;
> @@ -152,16 +152,41 @@ static int is_device_connecting(struct device *dev, void *data)
>  	if (drv && (dev->driver != drv))
>  		return 0;
>  
> +	if (ignore_vkbd) {

I would name the parameter ignore_nonessential, just to make it clearer
that is not just about vkbd


> +		/* With older QEMU, for PVonHVM guests the guest config files
> +		 * could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0']
> +		 * which is nonsensical as there is no PV FB (there can be
> +		 * a PVKB) running as HVM guest. */
> +
> +		if ((strncmp(xendev->nodename, "device/vkbd", 11) == 0))
> +			return 0;
> +
> +		if ((strncmp(xendev->nodename, "device/vfb", 10) == 0))
> +			return 0;
> +	}
>  	xendrv = to_xenbus_driver(dev->driver);
>  	return (xendev->state < XenbusStateConnected ||
>  		(xendev->state == XenbusStateConnected &&
>  		 xendrv->is_ready && !xendrv->is_ready(xendev)));
>  }
> +static int essential_device_connecting(struct device *dev, void *data)
> +{
> +	return is_device_connecting(dev, data, true /* ignore PVKB+PVDB */);
> +}

the comment is wrong


> +static int non_essential_device_connecting(struct device *dev, void *data)
> +{
> +	return is_device_connecting(dev, data, false);
> +}
>  
> -static int exists_connecting_device(struct device_driver *drv)
> +static int exists_essential_connecting_device(struct device_driver *drv)
>  {
>  	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> -				is_device_connecting);
> +				essential_device_connecting);
> +}
> +static int exists_non_essential_connecting_device(struct device_driver *drv)
> +{
> +	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> +				non_essential_device_connecting);
>  }
>  
>  static int print_device_status(struct device *dev, void *data)
> @@ -192,6 +217,23 @@ static int print_device_status(struct device *dev, void *data)
>  /* We only wait for device setup after most initcalls have run. */
>  static int ready_to_wait_for_devices;
>  
> +static bool wait_loop(unsigned long start, unsigned int max_delay,
> +		     unsigned int *seconds_waited)
> +{
> +	if (time_after(jiffies, start + (*seconds_waited+5)*HZ)) {
> +		if (!*seconds_waited)
> +			printk(KERN_WARNING "XENBUS: Waiting for "
> +			       "devices to initialise: ");
> +		*seconds_waited += 5;
> +		printk("%us...", max_delay - *seconds_waited);
> +		if (*seconds_waited == max_delay)
> +			return true;
> +	}
> +
> +	schedule_timeout_interruptible(HZ/10);
> +
> +	return false;
> +}
>  /*
>   * On a 5-minute timeout, wait for all devices currently configured.  We need
>   * to do this to guarantee that the filesystems and / or network devices
> @@ -215,19 +257,14 @@ static void wait_for_devices(struct xenbus_driver *xendrv)
>  	if (!ready_to_wait_for_devices || !xen_domain())
>  		return;
>  
> -	while (exists_connecting_device(drv)) {
> -		if (time_after(jiffies, start + (seconds_waited+5)*HZ)) {
> -			if (!seconds_waited)
> -				printk(KERN_WARNING "XENBUS: Waiting for "
> -				       "devices to initialise: ");
> -			seconds_waited += 5;
> -			printk("%us...", 300 - seconds_waited);
> -			if (seconds_waited == 300)
> -				break;
> -		}
> -
> -		schedule_timeout_interruptible(HZ/10);
> -	}
> +	while (exists_non_essential_connecting_device(drv))
> +		if (wait_loop(start, 30, &seconds_waited))
> +			break;
> +
> +	/* Skips PVKB and PVFB check.*/
> +	while (exists_essential_connecting_device(drv))
> +		if (wait_loop(start, 270, &seconds_waited))
> +			break;
>  
>  	if (seconds_waited)
>  		printk("\n");
> -- 
> 1.7.7.5
> 

Other than the comments I wrote above, I think the patch is good


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 11:33:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 11:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKpbW-0001O9-4j; Thu, 19 Apr 2012 11:32:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SKpbT-0001Nw-Qg
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 11:32:48 +0000
Received: from [85.158.139.83:7652] by server-12.bemta-5.messagelabs.com id
	C2/8F-05587-FD7FF8F4; Thu, 19 Apr 2012 11:32:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1334835166!13279183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3784 invoked from network); 19 Apr 2012 11:32:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 11:32:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="12024999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 11:32:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 12:32:42 +0100
Date: Thu, 19 Apr 2012 12:37:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.00.1204191232590.26786@kaball-desktop>
References: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	konrad <konrad@localhost.localdomain>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/xenbus: Add quirk to deal with
 misconfigured backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 18 Apr 2012, Konrad Rzeszutek Wilk wrote:
> From: konrad <konrad@localhost.localdomain>

wrong email address


> A rather annoying and common case is when booting a PVonHVM guest
> and exposing the PV KBD and PV VFB - as both of those do not
> make any sense.

I would rather write: "as broken toolstacks don't always initialize the
backends correctly."


> The HVM guest is using the VGA driver and the emulated
> keyboard for this. So we provide a very basic quirk framework
> (can be expanded in the future) to not wait for 6 minutes for those devices
> to initialize - they never wont.
> 
> To trigger this, put this in your guest config:
> 
> vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
> 
> instead of this:
> vnc=1
> vnclisten="0.0.0.0"
> 
> [v3: Split delay in non-essential (30 seconds) and essential
>  devices per Ian and Stefano suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>quirk
> ---
>  drivers/xen/xenbus/xenbus_probe_frontend.c |   69 +++++++++++++++++++++------
>  1 files changed, 53 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> index f20c5f1..7422913 100644
> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -135,7 +135,7 @@ static int read_backend_details(struct xenbus_device *xendev)
>  	return xenbus_read_otherend_details(xendev, "backend-id", "backend");
>  }
>  
> -static int is_device_connecting(struct device *dev, void *data)
> +static int is_device_connecting(struct device *dev, void *data, bool ignore_vkbd)
>  {
>  	struct xenbus_device *xendev = to_xenbus_device(dev);
>  	struct device_driver *drv = data;
> @@ -152,16 +152,41 @@ static int is_device_connecting(struct device *dev, void *data)
>  	if (drv && (dev->driver != drv))
>  		return 0;
>  
> +	if (ignore_vkbd) {

I would name the parameter ignore_nonessential, just to make it clearer
that is not just about vkbd


> +		/* With older QEMU, for PVonHVM guests the guest config files
> +		 * could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0']
> +		 * which is nonsensical as there is no PV FB (there can be
> +		 * a PVKB) running as HVM guest. */
> +
> +		if ((strncmp(xendev->nodename, "device/vkbd", 11) == 0))
> +			return 0;
> +
> +		if ((strncmp(xendev->nodename, "device/vfb", 10) == 0))
> +			return 0;
> +	}
>  	xendrv = to_xenbus_driver(dev->driver);
>  	return (xendev->state < XenbusStateConnected ||
>  		(xendev->state == XenbusStateConnected &&
>  		 xendrv->is_ready && !xendrv->is_ready(xendev)));
>  }
> +static int essential_device_connecting(struct device *dev, void *data)
> +{
> +	return is_device_connecting(dev, data, true /* ignore PVKB+PVDB */);
> +}

the comment is wrong


> +static int non_essential_device_connecting(struct device *dev, void *data)
> +{
> +	return is_device_connecting(dev, data, false);
> +}
>  
> -static int exists_connecting_device(struct device_driver *drv)
> +static int exists_essential_connecting_device(struct device_driver *drv)
>  {
>  	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> -				is_device_connecting);
> +				essential_device_connecting);
> +}
> +static int exists_non_essential_connecting_device(struct device_driver *drv)
> +{
> +	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> +				non_essential_device_connecting);
>  }
>  
>  static int print_device_status(struct device *dev, void *data)
> @@ -192,6 +217,23 @@ static int print_device_status(struct device *dev, void *data)
>  /* We only wait for device setup after most initcalls have run. */
>  static int ready_to_wait_for_devices;
>  
> +static bool wait_loop(unsigned long start, unsigned int max_delay,
> +		     unsigned int *seconds_waited)
> +{
> +	if (time_after(jiffies, start + (*seconds_waited+5)*HZ)) {
> +		if (!*seconds_waited)
> +			printk(KERN_WARNING "XENBUS: Waiting for "
> +			       "devices to initialise: ");
> +		*seconds_waited += 5;
> +		printk("%us...", max_delay - *seconds_waited);
> +		if (*seconds_waited == max_delay)
> +			return true;
> +	}
> +
> +	schedule_timeout_interruptible(HZ/10);
> +
> +	return false;
> +}
>  /*
>   * On a 5-minute timeout, wait for all devices currently configured.  We need
>   * to do this to guarantee that the filesystems and / or network devices
> @@ -215,19 +257,14 @@ static void wait_for_devices(struct xenbus_driver *xendrv)
>  	if (!ready_to_wait_for_devices || !xen_domain())
>  		return;
>  
> -	while (exists_connecting_device(drv)) {
> -		if (time_after(jiffies, start + (seconds_waited+5)*HZ)) {
> -			if (!seconds_waited)
> -				printk(KERN_WARNING "XENBUS: Waiting for "
> -				       "devices to initialise: ");
> -			seconds_waited += 5;
> -			printk("%us...", 300 - seconds_waited);
> -			if (seconds_waited == 300)
> -				break;
> -		}
> -
> -		schedule_timeout_interruptible(HZ/10);
> -	}
> +	while (exists_non_essential_connecting_device(drv))
> +		if (wait_loop(start, 30, &seconds_waited))
> +			break;
> +
> +	/* Skips PVKB and PVFB check.*/
> +	while (exists_essential_connecting_device(drv))
> +		if (wait_loop(start, 270, &seconds_waited))
> +			break;
>  
>  	if (seconds_waited)
>  		printk("\n");
> -- 
> 1.7.7.5
> 

Other than the comments I wrote above, I think the patch is good


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 12:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 12:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKqFq-0002Oe-3Q; Thu, 19 Apr 2012 12:14:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1SKqFo-0002OW-O8
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 12:14:28 +0000
Received: from [85.158.143.99:25133] by server-1.bemta-4.messagelabs.com id
	2D/EC-20925-3A1009F4; Thu, 19 Apr 2012 12:14:27 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334837665!23790525!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI3Njg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12316 invoked from network); 19 Apr 2012 12:14:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 12:14:26 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3JCEJJw015101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 08:14:20 -0400
Received: from localhost (ovpn-113-77.phx2.redhat.com [10.3.113.77])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3JCEAkd029514; Thu, 19 Apr 2012 08:14:12 -0400
Date: Thu, 19 Apr 2012 17:44:09 +0530
From: Amit Shah <amit.shah@redhat.com>
To: kvm list <kvm@vger.kernel.org>, qemu list <qemu-devel@nongnu.org>,
	xen-devel@lists.xensource.com,
	Virtualization List <virtualization@lists.linux-foundation.org>,
	libvir-list@redhat.com, seabios@seabios.org
Message-ID: <20120419121409.GC13210@amit.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] Call for Proposals: Linux Plumbers Conference (Aug 2012)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

The Call for Proposals for the Linux Plumbers Conf 2012 is out.  We're
looking for speakers to talk at the Virtualization microconference as
well as the main conference.  The deadline for proposal submissions is
1st May.  This year's edition of LPC is co-located with LinuxCon NA
and will be held at San Diego from the 29th to the 31st of August.

More details are at:

http://www.linuxplumbersconf.org/2012/2012-lpc-call-for-proposals/

Please note: to submit a proposal for the virt microconf, use the
'lpc2012-virt-' prefix in the Name field.

LPC is oriented towards solving problems, and good proposal topics are
those which are unresolved problems or proposals that need interaction
with multiple subsystems.

Please see the CFP page linked above for more details.

Thanks,

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 12:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 12:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKqFq-0002Oe-3Q; Thu, 19 Apr 2012 12:14:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1SKqFo-0002OW-O8
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 12:14:28 +0000
Received: from [85.158.143.99:25133] by server-1.bemta-4.messagelabs.com id
	2D/EC-20925-3A1009F4; Thu, 19 Apr 2012 12:14:27 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1334837665!23790525!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI3Njg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12316 invoked from network); 19 Apr 2012 12:14:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 12:14:26 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3JCEJJw015101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 08:14:20 -0400
Received: from localhost (ovpn-113-77.phx2.redhat.com [10.3.113.77])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3JCEAkd029514; Thu, 19 Apr 2012 08:14:12 -0400
Date: Thu, 19 Apr 2012 17:44:09 +0530
From: Amit Shah <amit.shah@redhat.com>
To: kvm list <kvm@vger.kernel.org>, qemu list <qemu-devel@nongnu.org>,
	xen-devel@lists.xensource.com,
	Virtualization List <virtualization@lists.linux-foundation.org>,
	libvir-list@redhat.com, seabios@seabios.org
Message-ID: <20120419121409.GC13210@amit.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] Call for Proposals: Linux Plumbers Conference (Aug 2012)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

The Call for Proposals for the Linux Plumbers Conf 2012 is out.  We're
looking for speakers to talk at the Virtualization microconference as
well as the main conference.  The deadline for proposal submissions is
1st May.  This year's edition of LPC is co-located with LinuxCon NA
and will be held at San Diego from the 29th to the 31st of August.

More details are at:

http://www.linuxplumbersconf.org/2012/2012-lpc-call-for-proposals/

Please note: to submit a proposal for the virt microconf, use the
'lpc2012-virt-' prefix in the Name field.

LPC is oriented towards solving problems, and good proposal topics are
those which are unresolved problems or proposals that need interaction
with multiple subsystems.

Please see the CFP page linked above for more details.

Thanks,

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 13:29:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 13:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKrQC-0004My-GU; Thu, 19 Apr 2012 13:29:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKrQB-0004Mp-3Z
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 13:29:15 +0000
Received: from [85.158.143.99:45110] by server-2.bemta-4.messagelabs.com id
	27/A2-17550-A23109F4; Thu, 19 Apr 2012 13:29:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334842151!24349681!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY3MjYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30405 invoked from network); 19 Apr 2012 13:29:12 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 13:29:12 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 19 Apr 2012 06:29:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="132876559"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 19 Apr 2012 06:29:10 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 19 Apr 2012 06:29:09 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 21:29:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: Ac0eMGTbbwDu17uMTQ2vQPuvK5oUmg==
Date: Thu, 19 Apr 2012 13:29:06 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 20 Apr 2012 05:08:38 +0800
Subject: [PATCH 1/3] Add mcelog support for xen platform

When MCA error occurs, it would be handled by xen hypervisor first,
and then the error information would be sent to dom0 for logging.

This patch gets error information from xen hypervisor and convert
xen format error into linux format mcelog. This logic is basically
self-contained, not much touching other kernel components.

So under xen platform when MCA error occurs, the error information
would be sent to dom0 and converted into native linux mcelog format.
By using tools like mcelog tool users could read specific error information=
,
like what they did under native linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    4 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  240 ++++++++++++++++++++++++
 include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 594 insertions(+), 3 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..15628d4 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 9424313..0f54241 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
           module will be called xen_acpi_processor  If you do not know wha=
t to choose,
           select M here. If the CPUFREQ drivers are built in, select Y her=
e.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default n
+	help
+	  Allow kernel fetching MCE error from Xen platform and
+	  converting it into Linux mcelog format for mcelog tools
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9adc5be..1d3e763 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..95ceb5e
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,240 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Driver for receiving and transferring machine check error infomation
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Author: Ke, Liping <liping.ke@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <asm/mce.h>
+
+#include <xen/interface/xen.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <xen/xen.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+#define XEN_MCELOG "xen_mcelog: "
+
+static struct mc_info g_mi;
+static struct mcinfo_logical_cpu *g_physinfo;
+static uint32_t ncpus;
+
+static DEFINE_SPINLOCK(mcelog_lock);
+
+static int convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	uint32_t i;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	if (unlikely(!mic)) {
+		pr_warning(XEN_MCELOG "Failed to find global error info\n");
+		return -ENODEV;
+	}
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+
+	for (i =3D 0; i < ncpus; i++)
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid)
+			break;
+	if (unlikely(i =3D=3D ncpus)) {
+		pr_warning(XEN_MCELOG "Failed to match cpu with apicid %d\n",
+			   m.apicid);
+		return -ENODEV;
+	}
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+	if (unlikely(!mic)) {
+		pr_warning(XEN_MCELOG "Fail to find bank error info\n");
+		return -ENODEV;
+	}
+
+	do {
+		if ((!mic) || (mic->size =3D=3D 0) ||
+		    (mic->type !=3D MC_TYPE_GLOBAL   &&
+		     mic->type !=3D MC_TYPE_BANK     &&
+		     mic->type !=3D MC_TYPE_EXTENDED &&
+		     mic->type !=3D MC_TYPE_RECOVERY))
+			break;
+
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+
+	return 0;
+}
+
+static int mc_queue_handle(uint32_t flags)
+{
+	struct xen_mc mc_op;
+	int ret =3D 0;
+	unsigned long tmp;
+
+	spin_lock_irqsave(&mcelog_lock, tmp);
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
+	do {
+		mc_op.u.mc_fetch.flags =3D flags;
+		ret =3D HYPERVISOR_mca(&mc_op);
+		if (ret) {
+			pr_err(XEN_MCELOG "Failed to fetch %s error log\n",
+			       (flags =3D=3D XEN_MC_URGENT) ?
+			       "urgnet" : "nonurgent");
+			break;
+		}
+
+		if (mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+			break;
+		else {
+			ret =3D convert_log(&g_mi);
+			if (ret)
+				pr_warning(XEN_MCELOG
+					   "Failed to convert this error log, "
+					   "continue acking it anyway\n");
+
+			mc_op.u.mc_fetch.flags =3D flags | XEN_MC_ACK;
+			ret =3D HYPERVISOR_mca(&mc_op);
+			if (ret) {
+				pr_err(XEN_MCELOG
+				       "Failed to ack previous error log\n");
+				break;
+			}
+		}
+	} while (1);
+
+	spin_unlock_irqrestore(&mcelog_lock, tmp);
+
+	return ret;
+}
+
+/* virq handler for machine check error info*/
+static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
+{
+	int err;
+
+	/* urgent mc_info */
+	err =3D mc_queue_handle(XEN_MC_URGENT);
+	if (err)
+		pr_err(XEN_MCELOG
+		       "Failed to handle urgent mc_info queue, "
+		       "continue handling nonurgent mc_info queue anyway.\n");
+
+	/* nonurgent mc_info */
+	err =3D mc_queue_handle(XEN_MC_NONURGENT);
+	if (err)
+		pr_err(XEN_MCELOG
+		       "Failed to handle nonurgent mc_info queue.\n");
+
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	struct xen_mc mc_op;
+
+	memset(&mc_op, 0, sizeof(struct xen_mc));
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		pr_err(XEN_MCELOG "Failed to get CPU numbers\n");
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kcalloc(ncpus, sizeof(struct mcinfo_logical_cpu),
+			     GFP_KERNEL);
+	if (!g_physinfo)
+		return -ENOMEM;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		pr_err(XEN_MCELOG "Failed to get CPU info\n");
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+				       xen_mce_interrupt, 0, "mce", NULL);
+	if (ret < 0) {
+		pr_err(XEN_MCELOG "Failed to bind virq\n");
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return -ENODEV;
+}
+late_initcall(mcelog_init);
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f2561db
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,336 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Updated by Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/or
+ * sell copies of the Software, and to permit persons to whom the Software=
 is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT	0x1
+/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT		0x2
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK		0x4
+
+/* OUT: All is ok */
+#define XEN_MC_OK		0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED	0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA		0x2
+
+#ifndef __ASSEMBLY__
+/* vIRQ injected to Dom0 */
+#define VIRQ_MCA VIRQ_ARCH_0
+
+/*
+ * mc_info entry types
+ * mca machine check info are recorded in mc_info entries.
+ * when fetch mca info, it can use MC_TYPE_... to distinguish
+ * different mca info.
+ */
+#define MC_TYPE_GLOBAL		0
+#define MC_TYPE_BANK		1
+#define MC_TYPE_EXTENDED	2
+#define MC_TYPE_RECOVERY	3
+
+struct mcinfo_common {
+	uint16_t type; /* structure type */
+	uint16_t size; /* size of this struct in bytes */
+};
+
+#define MC_FLAG_CORRECTABLE	(1 << 0)
+#define MC_FLAG_UNCORRECTABLE	(1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+
+/* contains x86 global mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	uint16_t mc_domid; /* running domain at the time in error */
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains x86 bank mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr; /* bank address */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+struct mcinfo_msr {
+	uint64_t reg; /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/*
+ * Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/*
+ * Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ */
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	uint8_t action_flags;
+	uint8_t action_types;
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_MAXSIZE 768
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t flags;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_MSR_MCGCAP 0
+#define __MC_NMSRS 1
+#define MC_NCAPS 7
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	uint32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	uint32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+/*
+ * Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+	((_mi)->mi_nentries)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+	((struct mcinfo_common *)(_mi)->mi_data)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/*
+ * Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
+				     struct mc_info *mi, uint16_t type)
+{
+	uint32_t i;
+	struct mcinfo_common *mic;
+	bool found =3D 0;
+
+	if (!ret || !mi)
+		return;
+
+	mic =3D x86_mcinfo_first(mi);
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+
+/*
+ * Fetch machine check data from hypervisor.
+ */
+#define XEN_MC_fetch		1
+struct xen_mc_fetch {
+	/*
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
+	 */
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/*
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain	2
+struct xen_mc_notifydomain {
+	/* IN variables */
+	uint16_t mc_domid; /* The unprivileged domain to notify */
+	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
+
+	/* IN/OUT variables */
+	uint32_t flags;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo	3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject	4
+#define MC_MSRINJ_MAXMSRS	8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr; /* target processor id */
+	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE	0x1
+
+#define XEN_MC_mceinject	5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr; /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-for-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-for-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-for-xen-platform.patch"; size=20832;
	creation-date="Thu, 19 Apr 2012 13:21:53 GMT";
	modification-date="Thu, 19 Apr 2012 21:16:56 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhZjQ0NjdiNmNmMDEwNGNlOThjYzE2MDQzOGQ4NjUyNTZjN2Q1NTYxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyMCBBcHIgMjAxMiAwNTowODozOCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8z
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZm9yIHhlbiBwbGF0Zm9ybQoKV2hlbiBNQ0EgZXJyb3Igb2Nj
dXJzLCBpdCB3b3VsZCBiZSBoYW5kbGVkIGJ5IHhlbiBoeXBlcnZpc29yIGZpcnN0LAphbmQgdGhl
biB0aGUgZXJyb3IgaW5mb3JtYXRpb24gd291bGQgYmUgc2VudCB0byBkb20wIGZvciBsb2dnaW5n
LgoKVGhpcyBwYXRjaCBnZXRzIGVycm9yIGluZm9ybWF0aW9uIGZyb20geGVuIGh5cGVydmlzb3Ig
YW5kIGNvbnZlcnQKeGVuIGZvcm1hdCBlcnJvciBpbnRvIGxpbnV4IGZvcm1hdCBtY2Vsb2cuIFRo
aXMgbG9naWMgaXMgYmFzaWNhbGx5CnNlbGYtY29udGFpbmVkLCBub3QgbXVjaCB0b3VjaGluZyBv
dGhlciBrZXJuZWwgY29tcG9uZW50cy4KClNvIHVuZGVyIHhlbiBwbGF0Zm9ybSB3aGVuIE1DQSBl
cnJvciBvY2N1cnMsIHRoZSBlcnJvciBpbmZvcm1hdGlvbgp3b3VsZCBiZSBzZW50IHRvIGRvbTAg
YW5kIGNvbnZlcnRlZCBpbnRvIG5hdGl2ZSBsaW51eCBtY2Vsb2cgZm9ybWF0LgpCeSB1c2luZyB0
b29scyBsaWtlIG1jZWxvZyB0b29sIHVzZXJzIGNvdWxkIHJlYWQgc3BlY2lmaWMgZXJyb3IgaW5m
b3JtYXRpb24sCmxpa2Ugd2hhdCB0aGV5IGRpZCB1bmRlciBuYXRpdmUgbGludXguCgpTaWduZWQt
b2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1i
eTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcs
IFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkg
Rml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogYXJjaC94
ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIHwgICAgOCArCiBhcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMgICAgICAgICAgICAgfCAgICA0ICstCiBkcml2ZXJzL3hlbi9LY29uZmlnICAgICAg
ICAgICAgICAgICAgfCAgICA4ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgICAg
ICB8ICAgIDEgKwogZHJpdmVycy94ZW4vbWNlbG9nLmMgICAgICAgICAgICAgICAgIHwgIDI0MCAr
KysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNhLmgg
ICAgICB8ICAzMzYgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogNiBmaWxlcyBj
aGFuZ2VkLCA1OTQgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEw
MDY0NCBkcml2ZXJzL3hlbi9tY2Vsb2cuYwogY3JlYXRlIG1vZGUgMTAwNjQ0IGluY2x1ZGUveGVu
L2ludGVyZmFjZS94ZW4tbWNhLmgKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94
ZW4vaHlwZXJjYWxsLmggYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgKaW5k
ZXggNTcyODg1Mi4uNTljMjI2ZCAxMDA2NDQKLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9hc20veGVu
L2h5cGVyY2FsbC5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaApA
QCAtNDgsNiArNDgsNyBAQAogI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2Uvc2NoZWQuaD4KICNpbmNs
dWRlIDx4ZW4vaW50ZXJmYWNlL3BoeXNkZXYuaD4KICNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3Bs
YXRmb3JtLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS94ZW4tbWNhLmg+CiAKIC8qCiAgKiBU
aGUgaHlwZXJjYWxsIGFzbXMgaGF2ZSB0byBtZWV0IHNldmVyYWwgY29uc3RyYWludHM6CkBAIC0z
MDIsNiArMzAzLDEzIEBAIEhZUEVSVklTT1Jfc2V0X3RpbWVyX29wKHU2NCB0aW1lb3V0KQogfQog
CiBzdGF0aWMgaW5saW5lIGludAorSFlQRVJWSVNPUl9tY2Eoc3RydWN0IHhlbl9tYyAqbWNfb3Ap
Cit7CisJbWNfb3AtPmludGVyZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lP
TjsKKwlyZXR1cm4gX2h5cGVyY2FsbDEoaW50LCBtY2EsIG1jX29wKTsKK30KKworc3RhdGljIGlu
bGluZSBpbnQKIEhZUEVSVklTT1JfZG9tMF9vcChzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wICpwbGF0
Zm9ybV9vcCkKIHsKIAlwbGF0Zm9ybV9vcC0+aW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5QRl9JTlRF
UkZBQ0VfVkVSU0lPTjsKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyBiL2Fy
Y2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwppbmRleCA0ZjUxYmViLi4xNTYyOGQ0IDEwMDY0NAotLS0g
YS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5j
CkBAIC0zMjksOSArMzI5LDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHhlbl9pbml0X2NwdWlkX21h
c2sodm9pZCkKIAl1bnNpZ25lZCBpbnQgeHNhdmVfbWFzazsKIAogCWNwdWlkX2xlYWYxX2VkeF9t
YXNrID0KLQkJfigoMSA8PCBYODZfRkVBVFVSRV9NQ0UpICB8ICAvKiBkaXNhYmxlIE1DRSAqLwot
CQkgICgxIDw8IFg4Nl9GRUFUVVJFX01DQSkgIHwgIC8qIGRpc2FibGUgTUNBICovCi0JCSAgKDEg
PDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlzYWJsZSBNVFJSICovCisJCX4oKDEgPDwgWDg2
X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlzYWJsZSBNVFJSICovCiAJCSAgKDEgPDwgWDg2X0ZFQVRV
UkVfQUNDKSk7ICAgLyogdGhlcm1hbCBtb25pdG9yaW5nICovCiAKIAlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vS2NvbmZpZyBiL2RyaXZlcnMveGVu
L0tjb25maWcKaW5kZXggOTQyNDMxMy4uMGY1NDI0MSAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4v
S2NvbmZpZworKysgYi9kcml2ZXJzL3hlbi9LY29uZmlnCkBAIC0xOTQsNCArMTk0LDEyIEBAIGNv
bmZpZyBYRU5fQUNQSV9QUk9DRVNTT1IKICAgICAgICAgICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQg
eGVuX2FjcGlfcHJvY2Vzc29yICBJZiB5b3UgZG8gbm90IGtub3cgd2hhdCB0byBjaG9vc2UsCiAg
ICAgICAgICAgc2VsZWN0IE0gaGVyZS4gSWYgdGhlIENQVUZSRVEgZHJpdmVycyBhcmUgYnVpbHQg
aW4sIHNlbGVjdCBZIGhlcmUuCiAKK2NvbmZpZyBYRU5fTUNFX0xPRworCWJvb2wgIlhlbiBwbGF0
Zm9ybSBtY2Vsb2ciCisJZGVwZW5kcyBvbiBYRU5fRE9NMCAmJiBYODZfNjQgJiYgWDg2X01DRQor
CWRlZmF1bHQgbgorCWhlbHAKKwkgIEFsbG93IGtlcm5lbCBmZXRjaGluZyBNQ0UgZXJyb3IgZnJv
bSBYZW4gcGxhdGZvcm0gYW5kCisJICBjb252ZXJ0aW5nIGl0IGludG8gTGludXggbWNlbG9nIGZv
cm1hdCBmb3IgbWNlbG9nIHRvb2xzCisKIGVuZG1lbnUKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggOWFkYzViZS4uMWQzZTc2MyAx
MDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZp
bGUKQEAgLTE0LDYgKzE0LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9HTlRERVYpCQkrPSB4ZW4tZ250
ZGV2Lm8KIG9iai0kKENPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DKQkrPSB4ZW4tZ250YWxsb2Mu
bwogb2JqLSQoQ09ORklHX1hFTkZTKQkJCSs9IHhlbmZzLwogb2JqLSQoQ09ORklHX1hFTl9TWVNf
SFlQRVJWSVNPUikJKz0gc3lzLWh5cGVydmlzb3Iubworb2JqLSQoQ09ORklHX1hFTl9NQ0VfTE9H
KQkJKz0gbWNlbG9nLm8KIG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNp
Lm8KIG9iai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lP
VExCX1hFTikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxv
Zy5jIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAw
MDAwMC4uOTVjZWI1ZQotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBA
IC0wLDAgKzEsMjQwIEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICog
RHJpdmVyIGZvciByZWNlaXZpbmcgYW5kIHRyYW5zZmVycmluZyBtYWNoaW5lIGNoZWNrIGVycm9y
IGluZm9tYXRpb24KKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24K
KyAqIEF1dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKiBBdXRo
b3I6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KKyAqIEF1dGhvcjog
S2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkg
aXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJz
aW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBv
ciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwg
b3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0
IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBn
cmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5Cisg
KiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNv
ZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2Fy
ZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJu
aXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9p
bml0Lmg+CisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwu
aD4KKyNpbmNsdWRlIDxsaW51eC9zbGFiLmg+CisjaW5jbHVkZSA8YXNtL21jZS5oPgorCisjaW5j
bHVkZSA8eGVuL2ludGVyZmFjZS94ZW4uaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CisjaW5j
bHVkZSA8eGVuL2ludGVyZmFjZS92Y3B1Lmg+CisjaW5jbHVkZSA8eGVuL3hlbi5oPgorI2luY2x1
ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+
CisKKyNkZWZpbmUgWEVOX01DRUxPRyAieGVuX21jZWxvZzogIgorCitzdGF0aWMgc3RydWN0IG1j
X2luZm8gZ19taTsKK3N0YXRpYyBzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1ICpnX3BoeXNpbmZv
Oworc3RhdGljIHVpbnQzMl90IG5jcHVzOworCitzdGF0aWMgREVGSU5FX1NQSU5MT0NLKG1jZWxv
Z19sb2NrKTsKKworc3RhdGljIGludCBjb252ZXJ0X2xvZyhzdHJ1Y3QgbWNfaW5mbyAqbWkpCit7
CisJc3RydWN0IG1jaW5mb19jb21tb24gKm1pYzsKKwlzdHJ1Y3QgbWNpbmZvX2dsb2JhbCAqbWNf
Z2xvYmFsOworCXN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuazsKKwlzdHJ1Y3QgbWNlIG07CisJ
dWludDMyX3QgaTsKKworCW1pYyA9IE5VTEw7CisJeDg2X21jaW5mb19sb29rdXAoJm1pYywgbWks
IE1DX1RZUEVfR0xPQkFMKTsKKwlpZiAodW5saWtlbHkoIW1pYykpIHsKKwkJcHJfd2FybmluZyhY
RU5fTUNFTE9HICJGYWlsZWQgdG8gZmluZCBnbG9iYWwgZXJyb3IgaW5mb1xuIik7CisJCXJldHVy
biAtRU5PREVWOworCX0KKworCW1jZV9zZXR1cCgmbSk7CisJbWNfZ2xvYmFsID0gKHN0cnVjdCBt
Y2luZm9fZ2xvYmFsICopbWljOworCW0ubWNnc3RhdHVzID0gbWNfZ2xvYmFsLT5tY19nc3RhdHVz
OworCW0uYXBpY2lkID0gbWNfZ2xvYmFsLT5tY19hcGljaWQ7CisKKwlmb3IgKGkgPSAwOyBpIDwg
bmNwdXM7IGkrKykKKwkJaWYgKGdfcGh5c2luZm9baV0ubWNfYXBpY2lkID09IG0uYXBpY2lkKQor
CQkJYnJlYWs7CisJaWYgKHVubGlrZWx5KGkgPT0gbmNwdXMpKSB7CisJCXByX3dhcm5pbmcoWEVO
X01DRUxPRyAiRmFpbGVkIHRvIG1hdGNoIGNwdSB3aXRoIGFwaWNpZCAlZFxuIiwKKwkJCSAgIG0u
YXBpY2lkKTsKKwkJcmV0dXJuIC1FTk9ERVY7CisJfQorCisJbS5zb2NrZXRpZCA9IGdfcGh5c2lu
Zm9baV0ubWNfY2hpcGlkOworCW0uY3B1ID0gbS5leHRjcHUgPSBnX3BoeXNpbmZvW2ldLm1jX2Nw
dW5yOworCW0uY3B1dmVuZG9yID0gKF9fdTgpZ19waHlzaW5mb1tpXS5tY192ZW5kb3I7CisJbS5t
Y2djYXAgPSBnX3BoeXNpbmZvW2ldLm1jX21zcnZhbHVlc1tfX01DX01TUl9NQ0dDQVBdLnZhbHVl
OworCisJbWljID0gTlVMTDsKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9C
QU5LKTsKKwlpZiAodW5saWtlbHkoIW1pYykpIHsKKwkJcHJfd2FybmluZyhYRU5fTUNFTE9HICJG
YWlsIHRvIGZpbmQgYmFuayBlcnJvciBpbmZvXG4iKTsKKwkJcmV0dXJuIC1FTk9ERVY7CisJfQor
CisJZG8geworCQlpZiAoKCFtaWMpIHx8IChtaWMtPnNpemUgPT0gMCkgfHwKKwkJICAgIChtaWMt
PnR5cGUgIT0gTUNfVFlQRV9HTE9CQUwgICAmJgorCQkgICAgIG1pYy0+dHlwZSAhPSBNQ19UWVBF
X0JBTksgICAgICYmCisJCSAgICAgbWljLT50eXBlICE9IE1DX1RZUEVfRVhURU5ERUQgJiYKKwkJ
ICAgICBtaWMtPnR5cGUgIT0gTUNfVFlQRV9SRUNPVkVSWSkpCisJCQlicmVhazsKKworCQlpZiAo
bWljLT50eXBlID09IE1DX1RZUEVfQkFOSykgeworCQkJbWNfYmFuayA9IChzdHJ1Y3QgbWNpbmZv
X2JhbmsgKiltaWM7CisJCQltLm1pc2MgPSBtY19iYW5rLT5tY19taXNjOworCQkJbS5zdGF0dXMg
PSBtY19iYW5rLT5tY19zdGF0dXM7CisJCQltLmFkZHIgPSBtY19iYW5rLT5tY19hZGRyOworCQkJ
bS50c2MgPSBtY19iYW5rLT5tY190c2M7CisJCQltLmJhbmsgPSBtY19iYW5rLT5tY19iYW5rOwor
CQkJbS5maW5pc2hlZCA9IDE7CisJCQkvKmxvZyB0aGlzIHJlY29yZCovCisJCQltY2VfbG9nKCZt
KTsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9IHdoaWxlICgxKTsKKwor
CXJldHVybiAwOworfQorCitzdGF0aWMgaW50IG1jX3F1ZXVlX2hhbmRsZSh1aW50MzJfdCBmbGFn
cykKK3sKKwlzdHJ1Y3QgeGVuX21jIG1jX29wOworCWludCByZXQgPSAwOworCXVuc2lnbmVkIGxv
bmcgdG1wOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJm1jZWxvZ19sb2NrLCB0bXApOworCisJbWNf
b3AuY21kID0gWEVOX01DX2ZldGNoOworCW1jX29wLmludGVyZmFjZV92ZXJzaW9uID0gWEVOX01D
QV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVuX2d1ZXN0X2hhbmRsZShtY19vcC51Lm1jX2Zl
dGNoLmRhdGEsICZnX21pKTsKKwlkbyB7CisJCW1jX29wLnUubWNfZmV0Y2guZmxhZ3MgPSBmbGFn
czsKKwkJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwkJaWYgKHJldCkgeworCQkJcHJf
ZXJyKFhFTl9NQ0VMT0cgIkZhaWxlZCB0byBmZXRjaCAlcyBlcnJvciBsb2dcbiIsCisJCQkgICAg
ICAgKGZsYWdzID09IFhFTl9NQ19VUkdFTlQpID8KKwkJCSAgICAgICAidXJnbmV0IiA6ICJub251
cmdlbnQiKTsKKwkJCWJyZWFrOworCQl9CisKKwkJaWYgKG1jX29wLnUubWNfZmV0Y2guZmxhZ3Mg
JiBYRU5fTUNfTk9EQVRBIHx8CisJCSAgICBtY19vcC51Lm1jX2ZldGNoLmZsYWdzICYgWEVOX01D
X0ZFVENIRkFJTEVEKQorCQkJYnJlYWs7CisJCWVsc2UgeworCQkJcmV0ID0gY29udmVydF9sb2co
JmdfbWkpOworCQkJaWYgKHJldCkKKwkJCQlwcl93YXJuaW5nKFhFTl9NQ0VMT0cKKwkJCQkJICAg
IkZhaWxlZCB0byBjb252ZXJ0IHRoaXMgZXJyb3IgbG9nLCAiCisJCQkJCSAgICJjb250aW51ZSBh
Y2tpbmcgaXQgYW55d2F5XG4iKTsKKworCQkJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IGZsYWdz
IHwgWEVOX01DX0FDSzsKKwkJCXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJCQlpZiAo
cmV0KSB7CisJCQkJcHJfZXJyKFhFTl9NQ0VMT0cKKwkJCQkgICAgICAgIkZhaWxlZCB0byBhY2sg
cHJldmlvdXMgZXJyb3IgbG9nXG4iKTsKKwkJCQlicmVhazsKKwkJCX0KKwkJfQorCX0gd2hpbGUg
KDEpOworCisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmbWNlbG9nX2xvY2ssIHRtcCk7CisKKwly
ZXR1cm4gcmV0OworfQorCisvKiB2aXJxIGhhbmRsZXIgZm9yIG1hY2hpbmUgY2hlY2sgZXJyb3Ig
aW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9p
ZCAqZGV2X2lkKQoreworCWludCBlcnI7CisKKwkvKiB1cmdlbnQgbWNfaW5mbyAqLworCWVyciA9
IG1jX3F1ZXVlX2hhbmRsZShYRU5fTUNfVVJHRU5UKTsKKwlpZiAoZXJyKQorCQlwcl9lcnIoWEVO
X01DRUxPRworCQkgICAgICAgIkZhaWxlZCB0byBoYW5kbGUgdXJnZW50IG1jX2luZm8gcXVldWUs
ICIKKwkJICAgICAgICJjb250aW51ZSBoYW5kbGluZyBub251cmdlbnQgbWNfaW5mbyBxdWV1ZSBh
bnl3YXkuXG4iKTsKKworCS8qIG5vbnVyZ2VudCBtY19pbmZvICovCisJZXJyID0gbWNfcXVldWVf
aGFuZGxlKFhFTl9NQ19OT05VUkdFTlQpOworCWlmIChlcnIpCisJCXByX2VycihYRU5fTUNFTE9H
CisJCSAgICAgICAiRmFpbGVkIHRvIGhhbmRsZSBub251cmdlbnQgbWNfaW5mbyBxdWV1ZS5cbiIp
OworCisJcmV0dXJuIElSUV9IQU5ETEVEOworfQorCitzdGF0aWMgaW50IGJpbmRfdmlycV9mb3Jf
bWNlKHZvaWQpCit7CisJaW50IHJldDsKKwlzdHJ1Y3QgeGVuX21jIG1jX29wOworCisJbWVtc2V0
KCZtY19vcCwgMCwgc2l6ZW9mKHN0cnVjdCB4ZW5fbWMpKTsKKworCS8qIEZldGNoIHBoeXNpY2Fs
IENQVSBOdW1iZXJzICovCisJbWNfb3AuY21kID0gWEVOX01DX3BoeXNjcHVpbmZvOworCW1jX29w
LmludGVyZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVu
X2d1ZXN0X2hhbmRsZShtY19vcC51Lm1jX3BoeXNjcHVpbmZvLmluZm8sIGdfcGh5c2luZm8pOwor
CXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJaWYgKHJldCkgeworCQlwcl9lcnIoWEVO
X01DRUxPRyAiRmFpbGVkIHRvIGdldCBDUFUgbnVtYmVyc1xuIik7CisJCXJldHVybiByZXQ7CisJ
fQorCisJLyogRmV0Y2ggZWFjaCBDUFUgUGh5c2ljYWwgSW5mbyBmb3IgbGF0ZXIgcmVmZXJlbmNl
Ki8KKwluY3B1cyA9IG1jX29wLnUubWNfcGh5c2NwdWluZm8ubmNwdXM7CisJZ19waHlzaW5mbyA9
IGtjYWxsb2MobmNwdXMsIHNpemVvZihzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1KSwKKwkJCSAg
ICAgR0ZQX0tFUk5FTCk7CisJaWYgKCFnX3BoeXNpbmZvKQorCQlyZXR1cm4gLUVOT01FTTsKKwlz
ZXRfeGVuX2d1ZXN0X2hhbmRsZShtY19vcC51Lm1jX3BoeXNjcHVpbmZvLmluZm8sIGdfcGh5c2lu
Zm8pOworCXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJaWYgKHJldCkgeworCQlwcl9l
cnIoWEVOX01DRUxPRyAiRmFpbGVkIHRvIGdldCBDUFUgaW5mb1xuIik7CisJCWtmcmVlKGdfcGh5
c2luZm8pOworCQlyZXR1cm4gcmV0OworCX0KKworCXJldCAgPSBiaW5kX3ZpcnFfdG9faXJxaGFu
ZGxlcihWSVJRX01DQSwgMCwKKwkJCQkgICAgICAgeGVuX21jZV9pbnRlcnJ1cHQsIDAsICJtY2Ui
LCBOVUxMKTsKKwlpZiAocmV0IDwgMCkgeworCQlwcl9lcnIoWEVOX01DRUxPRyAiRmFpbGVkIHRv
IGJpbmQgdmlycVxuIik7CisJCWtmcmVlKGdfcGh5c2luZm8pOworCQlyZXR1cm4gcmV0OworCX0K
KworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50IF9faW5pdCBtY2Vsb2dfaW5pdCh2b2lkKQor
eworCS8qIE9ubHkgRE9NMCBpcyByZXNwb25zaWJsZSBmb3IgTUNFIGxvZ2dpbmcgKi8KKwlpZiAo
eGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiBiaW5kX3ZpcnFfZm9yX21jZSgpOworCisJ
cmV0dXJuIC1FTk9ERVY7Cit9CitsYXRlX2luaXRjYWxsKG1jZWxvZ19pbml0KTsKZGlmZiAtLWdp
dCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNhLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLW1jYS5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmYyNTYxZGIK
LS0tIC9kZXYvbnVsbAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oCkBAIC0w
LDAgKzEsMzM2IEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBhcmNoLXg4Ni9tY2EuaAor
ICogR3Vlc3QgT1MgbWFjaGluZSBjaGVjayBpbnRlcmZhY2UgdG8geDg2IFhlbi4KKyAqCisgKiBD
b250cmlidXRlZCBieSBBZHZhbmNlZCBNaWNybyBEZXZpY2VzLCBJbmMuCisgKiBBdXRob3I6IENo
cmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CisgKgorICogVXBkYXRlZCBi
eSBJbnRlbCBDb3Jwb3JhdGlvbgorICogQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1
QGludGVsLmNvbT4KKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBncmFudGVkLCBmcmVlIG9m
IGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0aGlzIHNvZnR3
YXJlIGFuZCBhc3NvY2lhdGVkIGRvY3VtZW50YXRpb24gZmlsZXMgKHRoZSAiU29mdHdhcmUiKSwg
dG8KKyAqIGRlYWwgaW4gdGhlIFNvZnR3YXJlIHdpdGhvdXQgcmVzdHJpY3Rpb24sIGluY2x1ZGlu
ZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlCisgKiByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnks
IG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3IKKyAqIHNlbGwg
Y29waWVzIG9mIHRoZSBTb2Z0d2FyZSwgYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdob20gdGhl
IFNvZnR3YXJlIGlzCisgKiBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8gdGhlIGZvbGxv
d2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0
aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwgY29waWVz
IG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUgU09G
VFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lORCwg
RVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBUSEUg
V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM
QVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUKKyAq
IEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0sIERB
TUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04gT0YgQ09O
VFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0YgT1IgSU4g
Q09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSCisgKiBERUFM
SU5HUyBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2lmbmRlZiBfX1hFTl9QVUJMSUNfQVJDSF9Y
ODZfTUNBX0hfXworI2RlZmluZSBfX1hFTl9QVUJMSUNfQVJDSF9YODZfTUNBX0hfXworCisvKiBI
eXBlcmNhbGwgKi8KKyNkZWZpbmUgX19IWVBFUlZJU09SX21jYSBfX0hZUEVSVklTT1JfYXJjaF8w
CisKKyNkZWZpbmUgWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTgkweDAxZWNjMDAzCisKKy8qIElO
OiBEb20wIGNhbGxzIGh5cGVyY2FsbCB0byByZXRyaWV2ZSBub251cmdlbnQgZXJyb3IgbG9nIGVu
dHJ5ICovCisjZGVmaW5lIFhFTl9NQ19OT05VUkdFTlQJMHgxCisvKiBJTjogRG9tMCBjYWxscyBo
eXBlcmNhbGwgdG8gcmV0cmlldmUgdXJnZW50IGVycm9yIGxvZyBlbnRyeSAqLworI2RlZmluZSBY
RU5fTUNfVVJHRU5UCQkweDIKKy8qIElOOiBEb20wIGFja25vd2xlZGdlcyBwcmV2aW9zbHktZmV0
Y2hlZCBlcnJvciBsb2cgZW50cnkgKi8KKyNkZWZpbmUgWEVOX01DX0FDSwkJMHg0CisKKy8qIE9V
VDogQWxsIGlzIG9rICovCisjZGVmaW5lIFhFTl9NQ19PSwkJMHgwCisvKiBPVVQ6IERvbWFpbiBj
b3VsZCBub3QgZmV0Y2ggZGF0YS4gKi8KKyNkZWZpbmUgWEVOX01DX0ZFVENIRkFJTEVECTB4MQor
LyogT1VUOiBUaGVyZSB3YXMgbm8gbWFjaGluZSBjaGVjayBkYXRhIHRvIGZldGNoLiAqLworI2Rl
ZmluZSBYRU5fTUNfTk9EQVRBCQkweDIKKworI2lmbmRlZiBfX0FTU0VNQkxZX18KKy8qIHZJUlEg
aW5qZWN0ZWQgdG8gRG9tMCAqLworI2RlZmluZSBWSVJRX01DQSBWSVJRX0FSQ0hfMAorCisvKgor
ICogbWNfaW5mbyBlbnRyeSB0eXBlcworICogbWNhIG1hY2hpbmUgY2hlY2sgaW5mbyBhcmUgcmVj
b3JkZWQgaW4gbWNfaW5mbyBlbnRyaWVzLgorICogd2hlbiBmZXRjaCBtY2EgaW5mbywgaXQgY2Fu
IHVzZSBNQ19UWVBFXy4uLiB0byBkaXN0aW5ndWlzaAorICogZGlmZmVyZW50IG1jYSBpbmZvLgor
ICovCisjZGVmaW5lIE1DX1RZUEVfR0xPQkFMCQkwCisjZGVmaW5lIE1DX1RZUEVfQkFOSwkJMQor
I2RlZmluZSBNQ19UWVBFX0VYVEVOREVECTIKKyNkZWZpbmUgTUNfVFlQRV9SRUNPVkVSWQkzCisK
K3N0cnVjdCBtY2luZm9fY29tbW9uIHsKKwl1aW50MTZfdCB0eXBlOyAvKiBzdHJ1Y3R1cmUgdHlw
ZSAqLworCXVpbnQxNl90IHNpemU7IC8qIHNpemUgb2YgdGhpcyBzdHJ1Y3QgaW4gYnl0ZXMgKi8K
K307CisKKyNkZWZpbmUgTUNfRkxBR19DT1JSRUNUQUJMRQkoMSA8PCAwKQorI2RlZmluZSBNQ19G
TEFHX1VOQ09SUkVDVEFCTEUJKDEgPDwgMSkKKyNkZWZpbmUgTUNfRkxBR19SRUNPVkVSQUJMRQko
MSA8PCAyKQorI2RlZmluZSBNQ19GTEFHX1BPTExFRAkJKDEgPDwgMykKKyNkZWZpbmUgTUNfRkxB
R19SRVNFVAkJKDEgPDwgNCkKKyNkZWZpbmUgTUNfRkxBR19DTUNJCQkoMSA8PCA1KQorI2RlZmlu
ZSBNQ19GTEFHX01DRQkJKDEgPDwgNikKKworLyogY29udGFpbnMgeDg2IGdsb2JhbCBtYyBpbmZv
cm1hdGlvbiAqLworc3RydWN0IG1jaW5mb19nbG9iYWwgeworCXN0cnVjdCBtY2luZm9fY29tbW9u
IGNvbW1vbjsKKworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBydW5uaW5nIGRvbWFpbiBhdCB0aGUg
dGltZSBpbiBlcnJvciAqLworCXVpbnQxNl90IG1jX3ZjcHVpZDsgLyogdmlydHVhbCBjcHUgc2No
ZWR1bGVkIGZvciBtY19kb21pZCAqLworCXVpbnQzMl90IG1jX3NvY2tldGlkOyAvKiBwaHlzaWNh
bCBzb2NrZXQgb2YgdGhlIHBoeXNpY2FsIGNvcmUgKi8KKwl1aW50MTZfdCBtY19jb3JlaWQ7IC8q
IHBoeXNpY2FsIGltcGFjdGVkIGNvcmUgKi8KKwl1aW50MTZfdCBtY19jb3JlX3RocmVhZGlkOyAv
KiBjb3JlIHRocmVhZCBvZiBwaHlzaWNhbCBjb3JlICovCisJdWludDMyX3QgbWNfYXBpY2lkOwor
CXVpbnQzMl90IG1jX2ZsYWdzOworCXVpbnQ2NF90IG1jX2dzdGF0dXM7IC8qIGdsb2JhbCBzdGF0
dXMgKi8KK307CisKKy8qIGNvbnRhaW5zIHg4NiBiYW5rIG1jIGluZm9ybWF0aW9uICovCitzdHJ1
Y3QgbWNpbmZvX2JhbmsgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNvbW1vbjsKKworCXVpbnQx
Nl90IG1jX2Jhbms7IC8qIGJhbmsgbnIgKi8KKwl1aW50MTZfdCBtY19kb21pZDsgLyogZG9tYWlu
IHJlZmVyZW5jZWQgYnkgbWNfYWRkciBpZiB2YWxpZCAqLworCXVpbnQ2NF90IG1jX3N0YXR1czsg
LyogYmFuayBzdGF0dXMgKi8KKwl1aW50NjRfdCBtY19hZGRyOyAvKiBiYW5rIGFkZHJlc3MgKi8K
Kwl1aW50NjRfdCBtY19taXNjOworCXVpbnQ2NF90IG1jX2N0cmwyOworCXVpbnQ2NF90IG1jX3Rz
YzsKK307CisKK3N0cnVjdCBtY2luZm9fbXNyIHsKKwl1aW50NjRfdCByZWc7IC8qIE1TUiAqLwor
CXVpbnQ2NF90IHZhbHVlOyAvKiBNU1IgdmFsdWUgKi8KK307CisKKy8qIGNvbnRhaW5zIG1jIGlu
Zm9ybWF0aW9uIGZyb20gb3RoZXIgb3IgYWRkaXRpb25hbCBtYyBNU1JzICovCitzdHJ1Y3QgbWNp
bmZvX2V4dGVuZGVkIHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21tb247CisJdWludDMyX3Qg
bWNfbXNyczsgLyogTnVtYmVyIG9mIG1zciB3aXRoIHZhbGlkIHZhbHVlcy4gKi8KKwkvKgorCSAq
IEN1cnJlbnRseSBJbnRlbCBleHRlbmRlZCBNU1IgKDMyLzY0KSBpbmNsdWRlIGFsbCBncCByZWdp
c3RlcnMKKwkgKiBhbmQgRShSKUZMQUdTLCBFKFIpSVAsIEUoUilNSVNDLCB1cCB0byAxMS8xOSBv
ZiB0aGVtIG1pZ2h0IGJlCisJICogdXNlZnVsIGF0IHByZXNlbnQuIFNvIGV4cGFuZCB0aGlzIGFy
cmF5IHRvIDE2LzMyIHRvIGxlYXZlIHJvb20uCisJICovCisJc3RydWN0IG1jaW5mb19tc3IgbWNf
bXNyW3NpemVvZih2b2lkICopICogNF07Cit9OworCisvKiBSZWNvdmVyeSBBY3Rpb24gZmxhZ3Mu
IEdpdmluZyByZWNvdmVyeSByZXN1bHQgaW5mb3JtYXRpb24gdG8gRE9NMCAqLworCisvKiBYZW4g
dGFrZXMgc3VjY2Vzc2Z1bCByZWNvdmVyeSBhY3Rpb24sIHRoZSBlcnJvciBpcyByZWNvdmVyZWQg
Ki8KKyNkZWZpbmUgUkVDX0FDVElPTl9SRUNPVkVSRUQgKDB4MSA8PCAwKQorLyogTm8gYWN0aW9u
IGlzIHBlcmZvcm1lZCBieSBYRU4gKi8KKyNkZWZpbmUgUkVDX0FDVElPTl9OT05FICgweDEgPDwg
MSkKKy8qIEl0J3MgcG9zc2libGUgRE9NMCBtaWdodCB0YWtlIGFjdGlvbiBvd25lcnNoaXAgaW4g
c29tZSBjYXNlICovCisjZGVmaW5lIFJFQ19BQ1RJT05fTkVFRF9SRVNFVCAoMHgxIDw8IDIpCisK
Ky8qCisgKiBEaWZmZXJlbnQgUmVjb3ZlcnkgQWN0aW9uIHR5cGVzLCBpZiB0aGUgYWN0aW9uIGlz
IHBlcmZvcm1lZCBzdWNjZXNzZnVsbHksCisgKiBSRUNfQUNUSU9OX1JFQ09WRVJFRCBmbGFnIHdp
bGwgYmUgcmV0dXJuZWQuCisgKi8KKworLyogUGFnZSBPZmZsaW5lIEFjdGlvbiAqLworI2RlZmlu
ZSBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICgweDEgPDwgMCkKKy8qIENQVSBvZmZsaW5lIEFjdGlv
biAqLworI2RlZmluZSBNQ19BQ1RJT05fQ1BVX09GRkxJTkUgKDB4MSA8PCAxKQorLyogTDMgY2Fj
aGUgZGlzYWJsZSBBY3Rpb24gKi8KKyNkZWZpbmUgTUNfQUNUSU9OX0NBQ0hFX1NIUklOSyAoMHgx
IDw8IDIpCisKKy8qCisgKiBCZWxvdyBpbnRlcmZhY2UgdXNlZCBiZXR3ZWVuIFhFTi9ET00wIGZv
ciBwYXNzaW5nIFhFTidzIHJlY292ZXJ5IGFjdGlvbgorICogaW5mb3JtYXRpb24gdG8gRE9NMC4K
KyAqLworc3RydWN0IHBhZ2Vfb2ZmbGluZV9hY3Rpb24geworCS8qIFBhcmFtcyBmb3IgcGFzc2lu
ZyB0aGUgb2ZmbGluZWQgcGFnZSBudW1iZXIgdG8gRE9NMCAqLworCXVpbnQ2NF90IG1mbjsKKwl1
aW50NjRfdCBzdGF0dXM7Cit9OworCitzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIHsKKwkvKiBQ
YXJhbXMgZm9yIHBhc3NpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSBvZmZsaW5lZCBDUFUgdG8gRE9N
MCAqLworCXVpbnQzMl90IG1jX3NvY2tldGlkOworCXVpbnQxNl90IG1jX2NvcmVpZDsKKwl1aW50
MTZfdCBtY19jb3JlX3RocmVhZGlkOworfTsKKworI2RlZmluZSBNQVhfVU5JT05fU0laRSAxNgor
c3RydWN0IG1jaW5mb19yZWNvdmVyeSB7CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOwor
CXVpbnQxNl90IG1jX2Jhbms7IC8qIGJhbmsgbnIgKi8KKwl1aW50OF90IGFjdGlvbl9mbGFnczsK
Kwl1aW50OF90IGFjdGlvbl90eXBlczsKKwl1bmlvbiB7CisJCXN0cnVjdCBwYWdlX29mZmxpbmVf
YWN0aW9uIHBhZ2VfcmV0aXJlOworCQlzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIGNwdV9vZmZs
aW5lOworCQl1aW50OF90IHBhZFtNQVhfVU5JT05fU0laRV07CisJfSBhY3Rpb25faW5mbzsKK307
CisKKworI2RlZmluZSBNQ0lORk9fTUFYU0laRSA3NjgKK3N0cnVjdCBtY19pbmZvIHsKKwkvKiBO
dW1iZXIgb2YgbWNpbmZvXyogZW50cmllcyBpbiBtaV9kYXRhICovCisJdWludDMyX3QgbWlfbmVu
dHJpZXM7CisJdWludDMyX3QgZmxhZ3M7CisJdWludDY0X3QgbWlfZGF0YVsoTUNJTkZPX01BWFNJ
WkUgLSAxKSAvIDhdOworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKG1jX2luZm8pOwor
CisjZGVmaW5lIF9fTUNfTVNSX0FSUkFZU0laRSA4CisjZGVmaW5lIF9fTUNfTVNSX01DR0NBUCAw
CisjZGVmaW5lIF9fTUNfTk1TUlMgMQorI2RlZmluZSBNQ19OQ0FQUyA3CitzdHJ1Y3QgbWNpbmZv
X2xvZ2ljYWxfY3B1IHsKKwl1aW50MzJfdCBtY19jcHVucjsKKwl1aW50MzJfdCBtY19jaGlwaWQ7
CisJdWludDE2X3QgbWNfY29yZWlkOworCXVpbnQxNl90IG1jX3RocmVhZGlkOworCXVpbnQzMl90
IG1jX2FwaWNpZDsKKwl1aW50MzJfdCBtY19jbHVzdGVyaWQ7CisJdWludDMyX3QgbWNfbmNvcmVz
OworCXVpbnQzMl90IG1jX25jb3Jlc19hY3RpdmU7CisJdWludDMyX3QgbWNfbnRocmVhZHM7CisJ
dWludDMyX3QgbWNfY3B1aWRfbGV2ZWw7CisJdWludDMyX3QgbWNfZmFtaWx5OworCXVpbnQzMl90
IG1jX3ZlbmRvcjsKKwl1aW50MzJfdCBtY19tb2RlbDsKKwl1aW50MzJfdCBtY19zdGVwOworCWNo
YXIgbWNfdmVuZG9yaWRbMTZdOworCWNoYXIgbWNfYnJhbmRpZFs2NF07CisJdWludDMyX3QgbWNf
Y3B1X2NhcHNbTUNfTkNBUFNdOworCXVpbnQzMl90IG1jX2NhY2hlX3NpemU7CisJdWludDMyX3Qg
bWNfY2FjaGVfYWxpZ25tZW50OworCXVpbnQzMl90IG1jX25tc3J2YWxzOworCXN0cnVjdCBtY2lu
Zm9fbXNyIG1jX21zcnZhbHVlc1tfX01DX01TUl9BUlJBWVNJWkVdOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKG1jaW5mb19sb2dpY2FsX2NwdSk7CisKKy8qCisgKiBQcm90b3R5cGU6
CisgKiAgICB1aW50MzJfdCB4ODZfbWNpbmZvX25lbnRyaWVzKHN0cnVjdCBtY19pbmZvICptaSk7
CisgKi8KKyNkZWZpbmUgeDg2X21jaW5mb19uZW50cmllcyhfbWkpICAgIFwKKwkoKF9taSktPm1p
X25lbnRyaWVzKQorLyoKKyAqIFByb3RvdHlwZToKKyAqICAgIHN0cnVjdCBtY2luZm9fY29tbW9u
ICp4ODZfbWNpbmZvX2ZpcnN0KHN0cnVjdCBtY19pbmZvICptaSk7CisgKi8KKyNkZWZpbmUgeDg2
X21jaW5mb19maXJzdChfbWkpICAgICAgIFwKKwkoKHN0cnVjdCBtY2luZm9fY29tbW9uICopKF9t
aSktPm1pX2RhdGEpCisvKgorICogUHJvdG90eXBlOgorICogICAgc3RydWN0IG1jaW5mb19jb21t
b24gKng4Nl9tY2luZm9fbmV4dChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqbWljKTsKKyAqLworI2Rl
ZmluZSB4ODZfbWNpbmZvX25leHQoX21pYykgICAgICAgXAorCSgoc3RydWN0IG1jaW5mb19jb21t
b24gKikoKHVpbnQ4X3QgKikoX21pYykgKyAoX21pYyktPnNpemUpKQorCisvKgorICogUHJvdG90
eXBlOgorICogICAgdm9pZCB4ODZfbWNpbmZvX2xvb2t1cCh2b2lkICpyZXQsIHN0cnVjdCBtY19p
bmZvICptaSwgdWludDE2X3QgdHlwZSk7CisgKi8KK3N0YXRpYyBpbmxpbmUgdm9pZCB4ODZfbWNp
bmZvX2xvb2t1cChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKnJldCwKKwkJCQkgICAgIHN0cnVjdCBt
Y19pbmZvICptaSwgdWludDE2X3QgdHlwZSkKK3sKKwl1aW50MzJfdCBpOworCXN0cnVjdCBtY2lu
Zm9fY29tbW9uICptaWM7CisJYm9vbCBmb3VuZCA9IDA7CisKKwlpZiAoIXJldCB8fCAhbWkpCisJ
CXJldHVybjsKKworCW1pYyA9IHg4Nl9tY2luZm9fZmlyc3QobWkpOworCWZvciAoaSA9IDA7IGkg
PCB4ODZfbWNpbmZvX25lbnRyaWVzKG1pKTsgaSsrKSB7CisJCWlmIChtaWMtPnR5cGUgPT0gdHlw
ZSkgeworCQkJZm91bmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwkJbWljID0geDg2X21jaW5mb19u
ZXh0KG1pYyk7CisJfQorCisJKnJldCA9IGZvdW5kID8gbWljIDogTlVMTDsKK30KKworLyoKKyAq
IEZldGNoIG1hY2hpbmUgY2hlY2sgZGF0YSBmcm9tIGh5cGVydmlzb3IuCisgKi8KKyNkZWZpbmUg
WEVOX01DX2ZldGNoCQkxCitzdHJ1Y3QgeGVuX21jX2ZldGNoIHsKKwkvKgorCSAqIElOOiBYRU5f
TUNfTk9OVVJHRU5ULCBYRU5fTUNfVVJHRU5ULAorCSAqIFhFTl9NQ19BQ0sgaWYgYWNrJ2tpbmcg
YW4gZWFybGllciBmZXRjaAorCSAqIE9VVDogWEVOX01DX09LLCBYRU5fTUNfRkVUQ0hBSUxFRCwg
WEVOX01DX05PREFUQQorCSAqLworCXVpbnQzMl90IGZsYWdzOworCXVpbnQzMl90IF9wYWQwOwor
CS8qIE9VVDogaWQgZm9yIGFjaywgSU46IGlkIHdlIGFyZSBhY2snaW5nICovCisJdWludDY0X3Qg
ZmV0Y2hfaWQ7CisKKwkvKiBPVVQgdmFyaWFibGVzLiAqLworCUdVRVNUX0hBTkRMRShtY19pbmZv
KSBkYXRhOworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbl9tY19mZXRjaCk7CisK
KworLyoKKyAqIFRoaXMgdGVsbHMgdGhlIGh5cGVydmlzb3IgdG8gbm90aWZ5IGEgRG9tVSBhYm91
dCB0aGUgbWFjaGluZSBjaGVjayBlcnJvcgorICovCisjZGVmaW5lIFhFTl9NQ19ub3RpZnlkb21h
aW4JMgorc3RydWN0IHhlbl9tY19ub3RpZnlkb21haW4geworCS8qIElOIHZhcmlhYmxlcyAqLwor
CXVpbnQxNl90IG1jX2RvbWlkOyAvKiBUaGUgdW5wcml2aWxlZ2VkIGRvbWFpbiB0byBub3RpZnkg
Ki8KKwl1aW50MTZfdCBtY192Y3B1aWQ7IC8qIFRoZSB2Y3B1IGluIG1jX2RvbWlkIHRvIG5vdGlm
eSAqLworCisJLyogSU4vT1VUIHZhcmlhYmxlcyAqLworCXVpbnQzMl90IGZsYWdzOworfTsKK0RF
RklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbl9tY19ub3RpZnlkb21haW4pOworCisjZGVmaW5l
IFhFTl9NQ19waHlzY3B1aW5mbwkzCitzdHJ1Y3QgeGVuX21jX3BoeXNjcHVpbmZvIHsKKwkvKiBJ
Ti9PVVQgKi8KKwl1aW50MzJfdCBuY3B1czsKKwl1aW50MzJfdCBfcGFkMDsKKwkvKiBPVVQgKi8K
KwlHVUVTVF9IQU5ETEUobWNpbmZvX2xvZ2ljYWxfY3B1KSBpbmZvOworfTsKKworI2RlZmluZSBY
RU5fTUNfbXNyaW5qZWN0CTQKKyNkZWZpbmUgTUNfTVNSSU5KX01BWE1TUlMJOAorc3RydWN0IHhl
bl9tY19tc3JpbmplY3QgeworCS8qIElOICovCisJdWludDMyX3QgbWNpbmpfY3B1bnI7IC8qIHRh
cmdldCBwcm9jZXNzb3IgaWQgKi8KKwl1aW50MzJfdCBtY2lual9mbGFnczsgLyogc2VlIE1DX01T
UklOSl9GXyogYmVsb3cgKi8KKwl1aW50MzJfdCBtY2lual9jb3VudDsgLyogMCAuLiBjb3VudC0x
IGluIGFycmF5IGFyZSB2YWxpZCAqLworCXVpbnQzMl90IF9wYWQwOworCXN0cnVjdCBtY2luZm9f
bXNyIG1jaW5qX21zcltNQ19NU1JJTkpfTUFYTVNSU107Cit9OworCisvKiBGbGFncyBmb3IgbWNp
bmpfZmxhZ3MgYWJvdmU7IGJpdHMgMTYtMzEgYXJlIHJlc2VydmVkICovCisjZGVmaW5lIE1DX01T
UklOSl9GX0lOVEVSUE9TRQkweDEKKworI2RlZmluZSBYRU5fTUNfbWNlaW5qZWN0CTUKK3N0cnVj
dCB4ZW5fbWNfbWNlaW5qZWN0IHsKKwl1bnNpZ25lZCBpbnQgbWNlaW5qX2NwdW5yOyAvKiB0YXJn
ZXQgcHJvY2Vzc29yIGlkICovCit9OworCitzdHJ1Y3QgeGVuX21jIHsKKwl1aW50MzJfdCBjbWQ7
CisJdWludDMyX3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJ
T04gKi8KKwl1bmlvbiB7CisJCXN0cnVjdCB4ZW5fbWNfZmV0Y2ggICAgICAgIG1jX2ZldGNoOwor
CQlzdHJ1Y3QgeGVuX21jX25vdGlmeWRvbWFpbiBtY19ub3RpZnlkb21haW47CisJCXN0cnVjdCB4
ZW5fbWNfcGh5c2NwdWluZm8gIG1jX3BoeXNjcHVpbmZvOworCQlzdHJ1Y3QgeGVuX21jX21zcmlu
amVjdCAgICBtY19tc3JpbmplY3Q7CisJCXN0cnVjdCB4ZW5fbWNfbWNlaW5qZWN0ICAgIG1jX21j
ZWluamVjdDsKKwl9IHU7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jKTsK
KworI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIF9fWEVOX1BVQkxJQ19BUkNI
X1g4Nl9NQ0FfSF9fICovCi0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Apr 19 13:29:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 13:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKrQC-0004My-GU; Thu, 19 Apr 2012 13:29:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKrQB-0004Mp-3Z
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 13:29:15 +0000
Received: from [85.158.143.99:45110] by server-2.bemta-4.messagelabs.com id
	27/A2-17550-A23109F4; Thu, 19 Apr 2012 13:29:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334842151!24349681!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY3MjYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30405 invoked from network); 19 Apr 2012 13:29:12 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-216.messagelabs.com with SMTP;
	19 Apr 2012 13:29:12 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 19 Apr 2012 06:29:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="132876559"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 19 Apr 2012 06:29:10 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 19 Apr 2012 06:29:09 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 21:29:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: Ac0eMGTbbwDu17uMTQ2vQPuvK5oUmg==
Date: Thu, 19 Apr 2012 13:29:06 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 20 Apr 2012 05:08:38 +0800
Subject: [PATCH 1/3] Add mcelog support for xen platform

When MCA error occurs, it would be handled by xen hypervisor first,
and then the error information would be sent to dom0 for logging.

This patch gets error information from xen hypervisor and convert
xen format error into linux format mcelog. This logic is basically
self-contained, not much touching other kernel components.

So under xen platform when MCA error occurs, the error information
would be sent to dom0 and converted into native linux mcelog format.
By using tools like mcelog tool users could read specific error information=
,
like what they did under native linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    4 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  240 ++++++++++++++++++++++++
 include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 594 insertions(+), 3 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..15628d4 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 9424313..0f54241 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
           module will be called xen_acpi_processor  If you do not know wha=
t to choose,
           select M here. If the CPUFREQ drivers are built in, select Y her=
e.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default n
+	help
+	  Allow kernel fetching MCE error from Xen platform and
+	  converting it into Linux mcelog format for mcelog tools
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9adc5be..1d3e763 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..95ceb5e
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,240 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Driver for receiving and transferring machine check error infomation
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Author: Ke, Liping <liping.ke@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <asm/mce.h>
+
+#include <xen/interface/xen.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <xen/xen.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+#define XEN_MCELOG "xen_mcelog: "
+
+static struct mc_info g_mi;
+static struct mcinfo_logical_cpu *g_physinfo;
+static uint32_t ncpus;
+
+static DEFINE_SPINLOCK(mcelog_lock);
+
+static int convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	uint32_t i;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	if (unlikely(!mic)) {
+		pr_warning(XEN_MCELOG "Failed to find global error info\n");
+		return -ENODEV;
+	}
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+
+	for (i =3D 0; i < ncpus; i++)
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid)
+			break;
+	if (unlikely(i =3D=3D ncpus)) {
+		pr_warning(XEN_MCELOG "Failed to match cpu with apicid %d\n",
+			   m.apicid);
+		return -ENODEV;
+	}
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
+
+	mic =3D NULL;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+	if (unlikely(!mic)) {
+		pr_warning(XEN_MCELOG "Fail to find bank error info\n");
+		return -ENODEV;
+	}
+
+	do {
+		if ((!mic) || (mic->size =3D=3D 0) ||
+		    (mic->type !=3D MC_TYPE_GLOBAL   &&
+		     mic->type !=3D MC_TYPE_BANK     &&
+		     mic->type !=3D MC_TYPE_EXTENDED &&
+		     mic->type !=3D MC_TYPE_RECOVERY))
+			break;
+
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+
+	return 0;
+}
+
+static int mc_queue_handle(uint32_t flags)
+{
+	struct xen_mc mc_op;
+	int ret =3D 0;
+	unsigned long tmp;
+
+	spin_lock_irqsave(&mcelog_lock, tmp);
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
+	do {
+		mc_op.u.mc_fetch.flags =3D flags;
+		ret =3D HYPERVISOR_mca(&mc_op);
+		if (ret) {
+			pr_err(XEN_MCELOG "Failed to fetch %s error log\n",
+			       (flags =3D=3D XEN_MC_URGENT) ?
+			       "urgnet" : "nonurgent");
+			break;
+		}
+
+		if (mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+			break;
+		else {
+			ret =3D convert_log(&g_mi);
+			if (ret)
+				pr_warning(XEN_MCELOG
+					   "Failed to convert this error log, "
+					   "continue acking it anyway\n");
+
+			mc_op.u.mc_fetch.flags =3D flags | XEN_MC_ACK;
+			ret =3D HYPERVISOR_mca(&mc_op);
+			if (ret) {
+				pr_err(XEN_MCELOG
+				       "Failed to ack previous error log\n");
+				break;
+			}
+		}
+	} while (1);
+
+	spin_unlock_irqrestore(&mcelog_lock, tmp);
+
+	return ret;
+}
+
+/* virq handler for machine check error info*/
+static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
+{
+	int err;
+
+	/* urgent mc_info */
+	err =3D mc_queue_handle(XEN_MC_URGENT);
+	if (err)
+		pr_err(XEN_MCELOG
+		       "Failed to handle urgent mc_info queue, "
+		       "continue handling nonurgent mc_info queue anyway.\n");
+
+	/* nonurgent mc_info */
+	err =3D mc_queue_handle(XEN_MC_NONURGENT);
+	if (err)
+		pr_err(XEN_MCELOG
+		       "Failed to handle nonurgent mc_info queue.\n");
+
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	struct xen_mc mc_op;
+
+	memset(&mc_op, 0, sizeof(struct xen_mc));
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		pr_err(XEN_MCELOG "Failed to get CPU numbers\n");
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kcalloc(ncpus, sizeof(struct mcinfo_logical_cpu),
+			     GFP_KERNEL);
+	if (!g_physinfo)
+		return -ENOMEM;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		pr_err(XEN_MCELOG "Failed to get CPU info\n");
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+				       xen_mce_interrupt, 0, "mce", NULL);
+	if (ret < 0) {
+		pr_err(XEN_MCELOG "Failed to bind virq\n");
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return -ENODEV;
+}
+late_initcall(mcelog_init);
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f2561db
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,336 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Updated by Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/or
+ * sell copies of the Software, and to permit persons to whom the Software=
 is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT	0x1
+/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT		0x2
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK		0x4
+
+/* OUT: All is ok */
+#define XEN_MC_OK		0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED	0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA		0x2
+
+#ifndef __ASSEMBLY__
+/* vIRQ injected to Dom0 */
+#define VIRQ_MCA VIRQ_ARCH_0
+
+/*
+ * mc_info entry types
+ * mca machine check info are recorded in mc_info entries.
+ * when fetch mca info, it can use MC_TYPE_... to distinguish
+ * different mca info.
+ */
+#define MC_TYPE_GLOBAL		0
+#define MC_TYPE_BANK		1
+#define MC_TYPE_EXTENDED	2
+#define MC_TYPE_RECOVERY	3
+
+struct mcinfo_common {
+	uint16_t type; /* structure type */
+	uint16_t size; /* size of this struct in bytes */
+};
+
+#define MC_FLAG_CORRECTABLE	(1 << 0)
+#define MC_FLAG_UNCORRECTABLE	(1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+
+/* contains x86 global mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	uint16_t mc_domid; /* running domain at the time in error */
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains x86 bank mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr; /* bank address */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+struct mcinfo_msr {
+	uint64_t reg; /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/*
+ * Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/*
+ * Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ */
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	uint8_t action_flags;
+	uint8_t action_types;
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_MAXSIZE 768
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t flags;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_MSR_MCGCAP 0
+#define __MC_NMSRS 1
+#define MC_NCAPS 7
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	uint32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	uint32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+/*
+ * Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+	((_mi)->mi_nentries)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+	((struct mcinfo_common *)(_mi)->mi_data)
+/*
+ * Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/*
+ * Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
+				     struct mc_info *mi, uint16_t type)
+{
+	uint32_t i;
+	struct mcinfo_common *mic;
+	bool found =3D 0;
+
+	if (!ret || !mi)
+		return;
+
+	mic =3D x86_mcinfo_first(mi);
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+
+/*
+ * Fetch machine check data from hypervisor.
+ */
+#define XEN_MC_fetch		1
+struct xen_mc_fetch {
+	/*
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
+	 */
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/*
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain	2
+struct xen_mc_notifydomain {
+	/* IN variables */
+	uint16_t mc_domid; /* The unprivileged domain to notify */
+	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
+
+	/* IN/OUT variables */
+	uint32_t flags;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo	3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject	4
+#define MC_MSRINJ_MAXMSRS	8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr; /* target processor id */
+	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE	0x1
+
+#define XEN_MC_mceinject	5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr; /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-for-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-for-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-for-xen-platform.patch"; size=20832;
	creation-date="Thu, 19 Apr 2012 13:21:53 GMT";
	modification-date="Thu, 19 Apr 2012 21:16:56 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhZjQ0NjdiNmNmMDEwNGNlOThjYzE2MDQzOGQ4NjUyNTZjN2Q1NTYxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyMCBBcHIgMjAxMiAwNTowODozOCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8z
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZm9yIHhlbiBwbGF0Zm9ybQoKV2hlbiBNQ0EgZXJyb3Igb2Nj
dXJzLCBpdCB3b3VsZCBiZSBoYW5kbGVkIGJ5IHhlbiBoeXBlcnZpc29yIGZpcnN0LAphbmQgdGhl
biB0aGUgZXJyb3IgaW5mb3JtYXRpb24gd291bGQgYmUgc2VudCB0byBkb20wIGZvciBsb2dnaW5n
LgoKVGhpcyBwYXRjaCBnZXRzIGVycm9yIGluZm9ybWF0aW9uIGZyb20geGVuIGh5cGVydmlzb3Ig
YW5kIGNvbnZlcnQKeGVuIGZvcm1hdCBlcnJvciBpbnRvIGxpbnV4IGZvcm1hdCBtY2Vsb2cuIFRo
aXMgbG9naWMgaXMgYmFzaWNhbGx5CnNlbGYtY29udGFpbmVkLCBub3QgbXVjaCB0b3VjaGluZyBv
dGhlciBrZXJuZWwgY29tcG9uZW50cy4KClNvIHVuZGVyIHhlbiBwbGF0Zm9ybSB3aGVuIE1DQSBl
cnJvciBvY2N1cnMsIHRoZSBlcnJvciBpbmZvcm1hdGlvbgp3b3VsZCBiZSBzZW50IHRvIGRvbTAg
YW5kIGNvbnZlcnRlZCBpbnRvIG5hdGl2ZSBsaW51eCBtY2Vsb2cgZm9ybWF0LgpCeSB1c2luZyB0
b29scyBsaWtlIG1jZWxvZyB0b29sIHVzZXJzIGNvdWxkIHJlYWQgc3BlY2lmaWMgZXJyb3IgaW5m
b3JtYXRpb24sCmxpa2Ugd2hhdCB0aGV5IGRpZCB1bmRlciBuYXRpdmUgbGludXguCgpTaWduZWQt
b2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1i
eTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcs
IFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkg
Rml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogYXJjaC94
ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIHwgICAgOCArCiBhcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMgICAgICAgICAgICAgfCAgICA0ICstCiBkcml2ZXJzL3hlbi9LY29uZmlnICAgICAg
ICAgICAgICAgICAgfCAgICA4ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgICAg
ICB8ICAgIDEgKwogZHJpdmVycy94ZW4vbWNlbG9nLmMgICAgICAgICAgICAgICAgIHwgIDI0MCAr
KysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNhLmgg
ICAgICB8ICAzMzYgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogNiBmaWxlcyBj
aGFuZ2VkLCA1OTQgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEw
MDY0NCBkcml2ZXJzL3hlbi9tY2Vsb2cuYwogY3JlYXRlIG1vZGUgMTAwNjQ0IGluY2x1ZGUveGVu
L2ludGVyZmFjZS94ZW4tbWNhLmgKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94
ZW4vaHlwZXJjYWxsLmggYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgKaW5k
ZXggNTcyODg1Mi4uNTljMjI2ZCAxMDA2NDQKLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9hc20veGVu
L2h5cGVyY2FsbC5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaApA
QCAtNDgsNiArNDgsNyBAQAogI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2Uvc2NoZWQuaD4KICNpbmNs
dWRlIDx4ZW4vaW50ZXJmYWNlL3BoeXNkZXYuaD4KICNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3Bs
YXRmb3JtLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS94ZW4tbWNhLmg+CiAKIC8qCiAgKiBU
aGUgaHlwZXJjYWxsIGFzbXMgaGF2ZSB0byBtZWV0IHNldmVyYWwgY29uc3RyYWludHM6CkBAIC0z
MDIsNiArMzAzLDEzIEBAIEhZUEVSVklTT1Jfc2V0X3RpbWVyX29wKHU2NCB0aW1lb3V0KQogfQog
CiBzdGF0aWMgaW5saW5lIGludAorSFlQRVJWSVNPUl9tY2Eoc3RydWN0IHhlbl9tYyAqbWNfb3Ap
Cit7CisJbWNfb3AtPmludGVyZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lP
TjsKKwlyZXR1cm4gX2h5cGVyY2FsbDEoaW50LCBtY2EsIG1jX29wKTsKK30KKworc3RhdGljIGlu
bGluZSBpbnQKIEhZUEVSVklTT1JfZG9tMF9vcChzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wICpwbGF0
Zm9ybV9vcCkKIHsKIAlwbGF0Zm9ybV9vcC0+aW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5QRl9JTlRF
UkZBQ0VfVkVSU0lPTjsKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyBiL2Fy
Y2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwppbmRleCA0ZjUxYmViLi4xNTYyOGQ0IDEwMDY0NAotLS0g
YS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5j
CkBAIC0zMjksOSArMzI5LDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHhlbl9pbml0X2NwdWlkX21h
c2sodm9pZCkKIAl1bnNpZ25lZCBpbnQgeHNhdmVfbWFzazsKIAogCWNwdWlkX2xlYWYxX2VkeF9t
YXNrID0KLQkJfigoMSA8PCBYODZfRkVBVFVSRV9NQ0UpICB8ICAvKiBkaXNhYmxlIE1DRSAqLwot
CQkgICgxIDw8IFg4Nl9GRUFUVVJFX01DQSkgIHwgIC8qIGRpc2FibGUgTUNBICovCi0JCSAgKDEg
PDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlzYWJsZSBNVFJSICovCisJCX4oKDEgPDwgWDg2
X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlzYWJsZSBNVFJSICovCiAJCSAgKDEgPDwgWDg2X0ZFQVRV
UkVfQUNDKSk7ICAgLyogdGhlcm1hbCBtb25pdG9yaW5nICovCiAKIAlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vS2NvbmZpZyBiL2RyaXZlcnMveGVu
L0tjb25maWcKaW5kZXggOTQyNDMxMy4uMGY1NDI0MSAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4v
S2NvbmZpZworKysgYi9kcml2ZXJzL3hlbi9LY29uZmlnCkBAIC0xOTQsNCArMTk0LDEyIEBAIGNv
bmZpZyBYRU5fQUNQSV9QUk9DRVNTT1IKICAgICAgICAgICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQg
eGVuX2FjcGlfcHJvY2Vzc29yICBJZiB5b3UgZG8gbm90IGtub3cgd2hhdCB0byBjaG9vc2UsCiAg
ICAgICAgICAgc2VsZWN0IE0gaGVyZS4gSWYgdGhlIENQVUZSRVEgZHJpdmVycyBhcmUgYnVpbHQg
aW4sIHNlbGVjdCBZIGhlcmUuCiAKK2NvbmZpZyBYRU5fTUNFX0xPRworCWJvb2wgIlhlbiBwbGF0
Zm9ybSBtY2Vsb2ciCisJZGVwZW5kcyBvbiBYRU5fRE9NMCAmJiBYODZfNjQgJiYgWDg2X01DRQor
CWRlZmF1bHQgbgorCWhlbHAKKwkgIEFsbG93IGtlcm5lbCBmZXRjaGluZyBNQ0UgZXJyb3IgZnJv
bSBYZW4gcGxhdGZvcm0gYW5kCisJICBjb252ZXJ0aW5nIGl0IGludG8gTGludXggbWNlbG9nIGZv
cm1hdCBmb3IgbWNlbG9nIHRvb2xzCisKIGVuZG1lbnUKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggOWFkYzViZS4uMWQzZTc2MyAx
MDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZp
bGUKQEAgLTE0LDYgKzE0LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9HTlRERVYpCQkrPSB4ZW4tZ250
ZGV2Lm8KIG9iai0kKENPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DKQkrPSB4ZW4tZ250YWxsb2Mu
bwogb2JqLSQoQ09ORklHX1hFTkZTKQkJCSs9IHhlbmZzLwogb2JqLSQoQ09ORklHX1hFTl9TWVNf
SFlQRVJWSVNPUikJKz0gc3lzLWh5cGVydmlzb3Iubworb2JqLSQoQ09ORklHX1hFTl9NQ0VfTE9H
KQkJKz0gbWNlbG9nLm8KIG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNp
Lm8KIG9iai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lP
VExCX1hFTikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxv
Zy5jIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAw
MDAwMC4uOTVjZWI1ZQotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBA
IC0wLDAgKzEsMjQwIEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICog
RHJpdmVyIGZvciByZWNlaXZpbmcgYW5kIHRyYW5zZmVycmluZyBtYWNoaW5lIGNoZWNrIGVycm9y
IGluZm9tYXRpb24KKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24K
KyAqIEF1dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKiBBdXRo
b3I6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KKyAqIEF1dGhvcjog
S2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkg
aXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJz
aW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBv
ciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwg
b3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0
IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBn
cmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5Cisg
KiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNv
ZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2Fy
ZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJu
aXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9p
bml0Lmg+CisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwu
aD4KKyNpbmNsdWRlIDxsaW51eC9zbGFiLmg+CisjaW5jbHVkZSA8YXNtL21jZS5oPgorCisjaW5j
bHVkZSA8eGVuL2ludGVyZmFjZS94ZW4uaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CisjaW5j
bHVkZSA8eGVuL2ludGVyZmFjZS92Y3B1Lmg+CisjaW5jbHVkZSA8eGVuL3hlbi5oPgorI2luY2x1
ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+
CisKKyNkZWZpbmUgWEVOX01DRUxPRyAieGVuX21jZWxvZzogIgorCitzdGF0aWMgc3RydWN0IG1j
X2luZm8gZ19taTsKK3N0YXRpYyBzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1ICpnX3BoeXNpbmZv
Oworc3RhdGljIHVpbnQzMl90IG5jcHVzOworCitzdGF0aWMgREVGSU5FX1NQSU5MT0NLKG1jZWxv
Z19sb2NrKTsKKworc3RhdGljIGludCBjb252ZXJ0X2xvZyhzdHJ1Y3QgbWNfaW5mbyAqbWkpCit7
CisJc3RydWN0IG1jaW5mb19jb21tb24gKm1pYzsKKwlzdHJ1Y3QgbWNpbmZvX2dsb2JhbCAqbWNf
Z2xvYmFsOworCXN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuazsKKwlzdHJ1Y3QgbWNlIG07CisJ
dWludDMyX3QgaTsKKworCW1pYyA9IE5VTEw7CisJeDg2X21jaW5mb19sb29rdXAoJm1pYywgbWks
IE1DX1RZUEVfR0xPQkFMKTsKKwlpZiAodW5saWtlbHkoIW1pYykpIHsKKwkJcHJfd2FybmluZyhY
RU5fTUNFTE9HICJGYWlsZWQgdG8gZmluZCBnbG9iYWwgZXJyb3IgaW5mb1xuIik7CisJCXJldHVy
biAtRU5PREVWOworCX0KKworCW1jZV9zZXR1cCgmbSk7CisJbWNfZ2xvYmFsID0gKHN0cnVjdCBt
Y2luZm9fZ2xvYmFsICopbWljOworCW0ubWNnc3RhdHVzID0gbWNfZ2xvYmFsLT5tY19nc3RhdHVz
OworCW0uYXBpY2lkID0gbWNfZ2xvYmFsLT5tY19hcGljaWQ7CisKKwlmb3IgKGkgPSAwOyBpIDwg
bmNwdXM7IGkrKykKKwkJaWYgKGdfcGh5c2luZm9baV0ubWNfYXBpY2lkID09IG0uYXBpY2lkKQor
CQkJYnJlYWs7CisJaWYgKHVubGlrZWx5KGkgPT0gbmNwdXMpKSB7CisJCXByX3dhcm5pbmcoWEVO
X01DRUxPRyAiRmFpbGVkIHRvIG1hdGNoIGNwdSB3aXRoIGFwaWNpZCAlZFxuIiwKKwkJCSAgIG0u
YXBpY2lkKTsKKwkJcmV0dXJuIC1FTk9ERVY7CisJfQorCisJbS5zb2NrZXRpZCA9IGdfcGh5c2lu
Zm9baV0ubWNfY2hpcGlkOworCW0uY3B1ID0gbS5leHRjcHUgPSBnX3BoeXNpbmZvW2ldLm1jX2Nw
dW5yOworCW0uY3B1dmVuZG9yID0gKF9fdTgpZ19waHlzaW5mb1tpXS5tY192ZW5kb3I7CisJbS5t
Y2djYXAgPSBnX3BoeXNpbmZvW2ldLm1jX21zcnZhbHVlc1tfX01DX01TUl9NQ0dDQVBdLnZhbHVl
OworCisJbWljID0gTlVMTDsKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9C
QU5LKTsKKwlpZiAodW5saWtlbHkoIW1pYykpIHsKKwkJcHJfd2FybmluZyhYRU5fTUNFTE9HICJG
YWlsIHRvIGZpbmQgYmFuayBlcnJvciBpbmZvXG4iKTsKKwkJcmV0dXJuIC1FTk9ERVY7CisJfQor
CisJZG8geworCQlpZiAoKCFtaWMpIHx8IChtaWMtPnNpemUgPT0gMCkgfHwKKwkJICAgIChtaWMt
PnR5cGUgIT0gTUNfVFlQRV9HTE9CQUwgICAmJgorCQkgICAgIG1pYy0+dHlwZSAhPSBNQ19UWVBF
X0JBTksgICAgICYmCisJCSAgICAgbWljLT50eXBlICE9IE1DX1RZUEVfRVhURU5ERUQgJiYKKwkJ
ICAgICBtaWMtPnR5cGUgIT0gTUNfVFlQRV9SRUNPVkVSWSkpCisJCQlicmVhazsKKworCQlpZiAo
bWljLT50eXBlID09IE1DX1RZUEVfQkFOSykgeworCQkJbWNfYmFuayA9IChzdHJ1Y3QgbWNpbmZv
X2JhbmsgKiltaWM7CisJCQltLm1pc2MgPSBtY19iYW5rLT5tY19taXNjOworCQkJbS5zdGF0dXMg
PSBtY19iYW5rLT5tY19zdGF0dXM7CisJCQltLmFkZHIgPSBtY19iYW5rLT5tY19hZGRyOworCQkJ
bS50c2MgPSBtY19iYW5rLT5tY190c2M7CisJCQltLmJhbmsgPSBtY19iYW5rLT5tY19iYW5rOwor
CQkJbS5maW5pc2hlZCA9IDE7CisJCQkvKmxvZyB0aGlzIHJlY29yZCovCisJCQltY2VfbG9nKCZt
KTsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9IHdoaWxlICgxKTsKKwor
CXJldHVybiAwOworfQorCitzdGF0aWMgaW50IG1jX3F1ZXVlX2hhbmRsZSh1aW50MzJfdCBmbGFn
cykKK3sKKwlzdHJ1Y3QgeGVuX21jIG1jX29wOworCWludCByZXQgPSAwOworCXVuc2lnbmVkIGxv
bmcgdG1wOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJm1jZWxvZ19sb2NrLCB0bXApOworCisJbWNf
b3AuY21kID0gWEVOX01DX2ZldGNoOworCW1jX29wLmludGVyZmFjZV92ZXJzaW9uID0gWEVOX01D
QV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVuX2d1ZXN0X2hhbmRsZShtY19vcC51Lm1jX2Zl
dGNoLmRhdGEsICZnX21pKTsKKwlkbyB7CisJCW1jX29wLnUubWNfZmV0Y2guZmxhZ3MgPSBmbGFn
czsKKwkJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwkJaWYgKHJldCkgeworCQkJcHJf
ZXJyKFhFTl9NQ0VMT0cgIkZhaWxlZCB0byBmZXRjaCAlcyBlcnJvciBsb2dcbiIsCisJCQkgICAg
ICAgKGZsYWdzID09IFhFTl9NQ19VUkdFTlQpID8KKwkJCSAgICAgICAidXJnbmV0IiA6ICJub251
cmdlbnQiKTsKKwkJCWJyZWFrOworCQl9CisKKwkJaWYgKG1jX29wLnUubWNfZmV0Y2guZmxhZ3Mg
JiBYRU5fTUNfTk9EQVRBIHx8CisJCSAgICBtY19vcC51Lm1jX2ZldGNoLmZsYWdzICYgWEVOX01D
X0ZFVENIRkFJTEVEKQorCQkJYnJlYWs7CisJCWVsc2UgeworCQkJcmV0ID0gY29udmVydF9sb2co
JmdfbWkpOworCQkJaWYgKHJldCkKKwkJCQlwcl93YXJuaW5nKFhFTl9NQ0VMT0cKKwkJCQkJICAg
IkZhaWxlZCB0byBjb252ZXJ0IHRoaXMgZXJyb3IgbG9nLCAiCisJCQkJCSAgICJjb250aW51ZSBh
Y2tpbmcgaXQgYW55d2F5XG4iKTsKKworCQkJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IGZsYWdz
IHwgWEVOX01DX0FDSzsKKwkJCXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJCQlpZiAo
cmV0KSB7CisJCQkJcHJfZXJyKFhFTl9NQ0VMT0cKKwkJCQkgICAgICAgIkZhaWxlZCB0byBhY2sg
cHJldmlvdXMgZXJyb3IgbG9nXG4iKTsKKwkJCQlicmVhazsKKwkJCX0KKwkJfQorCX0gd2hpbGUg
KDEpOworCisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmbWNlbG9nX2xvY2ssIHRtcCk7CisKKwly
ZXR1cm4gcmV0OworfQorCisvKiB2aXJxIGhhbmRsZXIgZm9yIG1hY2hpbmUgY2hlY2sgZXJyb3Ig
aW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9p
ZCAqZGV2X2lkKQoreworCWludCBlcnI7CisKKwkvKiB1cmdlbnQgbWNfaW5mbyAqLworCWVyciA9
IG1jX3F1ZXVlX2hhbmRsZShYRU5fTUNfVVJHRU5UKTsKKwlpZiAoZXJyKQorCQlwcl9lcnIoWEVO
X01DRUxPRworCQkgICAgICAgIkZhaWxlZCB0byBoYW5kbGUgdXJnZW50IG1jX2luZm8gcXVldWUs
ICIKKwkJICAgICAgICJjb250aW51ZSBoYW5kbGluZyBub251cmdlbnQgbWNfaW5mbyBxdWV1ZSBh
bnl3YXkuXG4iKTsKKworCS8qIG5vbnVyZ2VudCBtY19pbmZvICovCisJZXJyID0gbWNfcXVldWVf
aGFuZGxlKFhFTl9NQ19OT05VUkdFTlQpOworCWlmIChlcnIpCisJCXByX2VycihYRU5fTUNFTE9H
CisJCSAgICAgICAiRmFpbGVkIHRvIGhhbmRsZSBub251cmdlbnQgbWNfaW5mbyBxdWV1ZS5cbiIp
OworCisJcmV0dXJuIElSUV9IQU5ETEVEOworfQorCitzdGF0aWMgaW50IGJpbmRfdmlycV9mb3Jf
bWNlKHZvaWQpCit7CisJaW50IHJldDsKKwlzdHJ1Y3QgeGVuX21jIG1jX29wOworCisJbWVtc2V0
KCZtY19vcCwgMCwgc2l6ZW9mKHN0cnVjdCB4ZW5fbWMpKTsKKworCS8qIEZldGNoIHBoeXNpY2Fs
IENQVSBOdW1iZXJzICovCisJbWNfb3AuY21kID0gWEVOX01DX3BoeXNjcHVpbmZvOworCW1jX29w
LmludGVyZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVu
X2d1ZXN0X2hhbmRsZShtY19vcC51Lm1jX3BoeXNjcHVpbmZvLmluZm8sIGdfcGh5c2luZm8pOwor
CXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJaWYgKHJldCkgeworCQlwcl9lcnIoWEVO
X01DRUxPRyAiRmFpbGVkIHRvIGdldCBDUFUgbnVtYmVyc1xuIik7CisJCXJldHVybiByZXQ7CisJ
fQorCisJLyogRmV0Y2ggZWFjaCBDUFUgUGh5c2ljYWwgSW5mbyBmb3IgbGF0ZXIgcmVmZXJlbmNl
Ki8KKwluY3B1cyA9IG1jX29wLnUubWNfcGh5c2NwdWluZm8ubmNwdXM7CisJZ19waHlzaW5mbyA9
IGtjYWxsb2MobmNwdXMsIHNpemVvZihzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1KSwKKwkJCSAg
ICAgR0ZQX0tFUk5FTCk7CisJaWYgKCFnX3BoeXNpbmZvKQorCQlyZXR1cm4gLUVOT01FTTsKKwlz
ZXRfeGVuX2d1ZXN0X2hhbmRsZShtY19vcC51Lm1jX3BoeXNjcHVpbmZvLmluZm8sIGdfcGh5c2lu
Zm8pOworCXJldCA9IEhZUEVSVklTT1JfbWNhKCZtY19vcCk7CisJaWYgKHJldCkgeworCQlwcl9l
cnIoWEVOX01DRUxPRyAiRmFpbGVkIHRvIGdldCBDUFUgaW5mb1xuIik7CisJCWtmcmVlKGdfcGh5
c2luZm8pOworCQlyZXR1cm4gcmV0OworCX0KKworCXJldCAgPSBiaW5kX3ZpcnFfdG9faXJxaGFu
ZGxlcihWSVJRX01DQSwgMCwKKwkJCQkgICAgICAgeGVuX21jZV9pbnRlcnJ1cHQsIDAsICJtY2Ui
LCBOVUxMKTsKKwlpZiAocmV0IDwgMCkgeworCQlwcl9lcnIoWEVOX01DRUxPRyAiRmFpbGVkIHRv
IGJpbmQgdmlycVxuIik7CisJCWtmcmVlKGdfcGh5c2luZm8pOworCQlyZXR1cm4gcmV0OworCX0K
KworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50IF9faW5pdCBtY2Vsb2dfaW5pdCh2b2lkKQor
eworCS8qIE9ubHkgRE9NMCBpcyByZXNwb25zaWJsZSBmb3IgTUNFIGxvZ2dpbmcgKi8KKwlpZiAo
eGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiBiaW5kX3ZpcnFfZm9yX21jZSgpOworCisJ
cmV0dXJuIC1FTk9ERVY7Cit9CitsYXRlX2luaXRjYWxsKG1jZWxvZ19pbml0KTsKZGlmZiAtLWdp
dCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNhLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLW1jYS5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmYyNTYxZGIK
LS0tIC9kZXYvbnVsbAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oCkBAIC0w
LDAgKzEsMzM2IEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBhcmNoLXg4Ni9tY2EuaAor
ICogR3Vlc3QgT1MgbWFjaGluZSBjaGVjayBpbnRlcmZhY2UgdG8geDg2IFhlbi4KKyAqCisgKiBD
b250cmlidXRlZCBieSBBZHZhbmNlZCBNaWNybyBEZXZpY2VzLCBJbmMuCisgKiBBdXRob3I6IENo
cmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CisgKgorICogVXBkYXRlZCBi
eSBJbnRlbCBDb3Jwb3JhdGlvbgorICogQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1
QGludGVsLmNvbT4KKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBncmFudGVkLCBmcmVlIG9m
IGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0aGlzIHNvZnR3
YXJlIGFuZCBhc3NvY2lhdGVkIGRvY3VtZW50YXRpb24gZmlsZXMgKHRoZSAiU29mdHdhcmUiKSwg
dG8KKyAqIGRlYWwgaW4gdGhlIFNvZnR3YXJlIHdpdGhvdXQgcmVzdHJpY3Rpb24sIGluY2x1ZGlu
ZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlCisgKiByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnks
IG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3IKKyAqIHNlbGwg
Y29waWVzIG9mIHRoZSBTb2Z0d2FyZSwgYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdob20gdGhl
IFNvZnR3YXJlIGlzCisgKiBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8gdGhlIGZvbGxv
d2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0
aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwgY29waWVz
IG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUgU09G
VFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lORCwg
RVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBUSEUg
V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM
QVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUKKyAq
IEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0sIERB
TUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04gT0YgQ09O
VFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0YgT1IgSU4g
Q09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSCisgKiBERUFM
SU5HUyBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2lmbmRlZiBfX1hFTl9QVUJMSUNfQVJDSF9Y
ODZfTUNBX0hfXworI2RlZmluZSBfX1hFTl9QVUJMSUNfQVJDSF9YODZfTUNBX0hfXworCisvKiBI
eXBlcmNhbGwgKi8KKyNkZWZpbmUgX19IWVBFUlZJU09SX21jYSBfX0hZUEVSVklTT1JfYXJjaF8w
CisKKyNkZWZpbmUgWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTgkweDAxZWNjMDAzCisKKy8qIElO
OiBEb20wIGNhbGxzIGh5cGVyY2FsbCB0byByZXRyaWV2ZSBub251cmdlbnQgZXJyb3IgbG9nIGVu
dHJ5ICovCisjZGVmaW5lIFhFTl9NQ19OT05VUkdFTlQJMHgxCisvKiBJTjogRG9tMCBjYWxscyBo
eXBlcmNhbGwgdG8gcmV0cmlldmUgdXJnZW50IGVycm9yIGxvZyBlbnRyeSAqLworI2RlZmluZSBY
RU5fTUNfVVJHRU5UCQkweDIKKy8qIElOOiBEb20wIGFja25vd2xlZGdlcyBwcmV2aW9zbHktZmV0
Y2hlZCBlcnJvciBsb2cgZW50cnkgKi8KKyNkZWZpbmUgWEVOX01DX0FDSwkJMHg0CisKKy8qIE9V
VDogQWxsIGlzIG9rICovCisjZGVmaW5lIFhFTl9NQ19PSwkJMHgwCisvKiBPVVQ6IERvbWFpbiBj
b3VsZCBub3QgZmV0Y2ggZGF0YS4gKi8KKyNkZWZpbmUgWEVOX01DX0ZFVENIRkFJTEVECTB4MQor
LyogT1VUOiBUaGVyZSB3YXMgbm8gbWFjaGluZSBjaGVjayBkYXRhIHRvIGZldGNoLiAqLworI2Rl
ZmluZSBYRU5fTUNfTk9EQVRBCQkweDIKKworI2lmbmRlZiBfX0FTU0VNQkxZX18KKy8qIHZJUlEg
aW5qZWN0ZWQgdG8gRG9tMCAqLworI2RlZmluZSBWSVJRX01DQSBWSVJRX0FSQ0hfMAorCisvKgor
ICogbWNfaW5mbyBlbnRyeSB0eXBlcworICogbWNhIG1hY2hpbmUgY2hlY2sgaW5mbyBhcmUgcmVj
b3JkZWQgaW4gbWNfaW5mbyBlbnRyaWVzLgorICogd2hlbiBmZXRjaCBtY2EgaW5mbywgaXQgY2Fu
IHVzZSBNQ19UWVBFXy4uLiB0byBkaXN0aW5ndWlzaAorICogZGlmZmVyZW50IG1jYSBpbmZvLgor
ICovCisjZGVmaW5lIE1DX1RZUEVfR0xPQkFMCQkwCisjZGVmaW5lIE1DX1RZUEVfQkFOSwkJMQor
I2RlZmluZSBNQ19UWVBFX0VYVEVOREVECTIKKyNkZWZpbmUgTUNfVFlQRV9SRUNPVkVSWQkzCisK
K3N0cnVjdCBtY2luZm9fY29tbW9uIHsKKwl1aW50MTZfdCB0eXBlOyAvKiBzdHJ1Y3R1cmUgdHlw
ZSAqLworCXVpbnQxNl90IHNpemU7IC8qIHNpemUgb2YgdGhpcyBzdHJ1Y3QgaW4gYnl0ZXMgKi8K
K307CisKKyNkZWZpbmUgTUNfRkxBR19DT1JSRUNUQUJMRQkoMSA8PCAwKQorI2RlZmluZSBNQ19G
TEFHX1VOQ09SUkVDVEFCTEUJKDEgPDwgMSkKKyNkZWZpbmUgTUNfRkxBR19SRUNPVkVSQUJMRQko
MSA8PCAyKQorI2RlZmluZSBNQ19GTEFHX1BPTExFRAkJKDEgPDwgMykKKyNkZWZpbmUgTUNfRkxB
R19SRVNFVAkJKDEgPDwgNCkKKyNkZWZpbmUgTUNfRkxBR19DTUNJCQkoMSA8PCA1KQorI2RlZmlu
ZSBNQ19GTEFHX01DRQkJKDEgPDwgNikKKworLyogY29udGFpbnMgeDg2IGdsb2JhbCBtYyBpbmZv
cm1hdGlvbiAqLworc3RydWN0IG1jaW5mb19nbG9iYWwgeworCXN0cnVjdCBtY2luZm9fY29tbW9u
IGNvbW1vbjsKKworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBydW5uaW5nIGRvbWFpbiBhdCB0aGUg
dGltZSBpbiBlcnJvciAqLworCXVpbnQxNl90IG1jX3ZjcHVpZDsgLyogdmlydHVhbCBjcHUgc2No
ZWR1bGVkIGZvciBtY19kb21pZCAqLworCXVpbnQzMl90IG1jX3NvY2tldGlkOyAvKiBwaHlzaWNh
bCBzb2NrZXQgb2YgdGhlIHBoeXNpY2FsIGNvcmUgKi8KKwl1aW50MTZfdCBtY19jb3JlaWQ7IC8q
IHBoeXNpY2FsIGltcGFjdGVkIGNvcmUgKi8KKwl1aW50MTZfdCBtY19jb3JlX3RocmVhZGlkOyAv
KiBjb3JlIHRocmVhZCBvZiBwaHlzaWNhbCBjb3JlICovCisJdWludDMyX3QgbWNfYXBpY2lkOwor
CXVpbnQzMl90IG1jX2ZsYWdzOworCXVpbnQ2NF90IG1jX2dzdGF0dXM7IC8qIGdsb2JhbCBzdGF0
dXMgKi8KK307CisKKy8qIGNvbnRhaW5zIHg4NiBiYW5rIG1jIGluZm9ybWF0aW9uICovCitzdHJ1
Y3QgbWNpbmZvX2JhbmsgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNvbW1vbjsKKworCXVpbnQx
Nl90IG1jX2Jhbms7IC8qIGJhbmsgbnIgKi8KKwl1aW50MTZfdCBtY19kb21pZDsgLyogZG9tYWlu
IHJlZmVyZW5jZWQgYnkgbWNfYWRkciBpZiB2YWxpZCAqLworCXVpbnQ2NF90IG1jX3N0YXR1czsg
LyogYmFuayBzdGF0dXMgKi8KKwl1aW50NjRfdCBtY19hZGRyOyAvKiBiYW5rIGFkZHJlc3MgKi8K
Kwl1aW50NjRfdCBtY19taXNjOworCXVpbnQ2NF90IG1jX2N0cmwyOworCXVpbnQ2NF90IG1jX3Rz
YzsKK307CisKK3N0cnVjdCBtY2luZm9fbXNyIHsKKwl1aW50NjRfdCByZWc7IC8qIE1TUiAqLwor
CXVpbnQ2NF90IHZhbHVlOyAvKiBNU1IgdmFsdWUgKi8KK307CisKKy8qIGNvbnRhaW5zIG1jIGlu
Zm9ybWF0aW9uIGZyb20gb3RoZXIgb3IgYWRkaXRpb25hbCBtYyBNU1JzICovCitzdHJ1Y3QgbWNp
bmZvX2V4dGVuZGVkIHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21tb247CisJdWludDMyX3Qg
bWNfbXNyczsgLyogTnVtYmVyIG9mIG1zciB3aXRoIHZhbGlkIHZhbHVlcy4gKi8KKwkvKgorCSAq
IEN1cnJlbnRseSBJbnRlbCBleHRlbmRlZCBNU1IgKDMyLzY0KSBpbmNsdWRlIGFsbCBncCByZWdp
c3RlcnMKKwkgKiBhbmQgRShSKUZMQUdTLCBFKFIpSVAsIEUoUilNSVNDLCB1cCB0byAxMS8xOSBv
ZiB0aGVtIG1pZ2h0IGJlCisJICogdXNlZnVsIGF0IHByZXNlbnQuIFNvIGV4cGFuZCB0aGlzIGFy
cmF5IHRvIDE2LzMyIHRvIGxlYXZlIHJvb20uCisJICovCisJc3RydWN0IG1jaW5mb19tc3IgbWNf
bXNyW3NpemVvZih2b2lkICopICogNF07Cit9OworCisvKiBSZWNvdmVyeSBBY3Rpb24gZmxhZ3Mu
IEdpdmluZyByZWNvdmVyeSByZXN1bHQgaW5mb3JtYXRpb24gdG8gRE9NMCAqLworCisvKiBYZW4g
dGFrZXMgc3VjY2Vzc2Z1bCByZWNvdmVyeSBhY3Rpb24sIHRoZSBlcnJvciBpcyByZWNvdmVyZWQg
Ki8KKyNkZWZpbmUgUkVDX0FDVElPTl9SRUNPVkVSRUQgKDB4MSA8PCAwKQorLyogTm8gYWN0aW9u
IGlzIHBlcmZvcm1lZCBieSBYRU4gKi8KKyNkZWZpbmUgUkVDX0FDVElPTl9OT05FICgweDEgPDwg
MSkKKy8qIEl0J3MgcG9zc2libGUgRE9NMCBtaWdodCB0YWtlIGFjdGlvbiBvd25lcnNoaXAgaW4g
c29tZSBjYXNlICovCisjZGVmaW5lIFJFQ19BQ1RJT05fTkVFRF9SRVNFVCAoMHgxIDw8IDIpCisK
Ky8qCisgKiBEaWZmZXJlbnQgUmVjb3ZlcnkgQWN0aW9uIHR5cGVzLCBpZiB0aGUgYWN0aW9uIGlz
IHBlcmZvcm1lZCBzdWNjZXNzZnVsbHksCisgKiBSRUNfQUNUSU9OX1JFQ09WRVJFRCBmbGFnIHdp
bGwgYmUgcmV0dXJuZWQuCisgKi8KKworLyogUGFnZSBPZmZsaW5lIEFjdGlvbiAqLworI2RlZmlu
ZSBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICgweDEgPDwgMCkKKy8qIENQVSBvZmZsaW5lIEFjdGlv
biAqLworI2RlZmluZSBNQ19BQ1RJT05fQ1BVX09GRkxJTkUgKDB4MSA8PCAxKQorLyogTDMgY2Fj
aGUgZGlzYWJsZSBBY3Rpb24gKi8KKyNkZWZpbmUgTUNfQUNUSU9OX0NBQ0hFX1NIUklOSyAoMHgx
IDw8IDIpCisKKy8qCisgKiBCZWxvdyBpbnRlcmZhY2UgdXNlZCBiZXR3ZWVuIFhFTi9ET00wIGZv
ciBwYXNzaW5nIFhFTidzIHJlY292ZXJ5IGFjdGlvbgorICogaW5mb3JtYXRpb24gdG8gRE9NMC4K
KyAqLworc3RydWN0IHBhZ2Vfb2ZmbGluZV9hY3Rpb24geworCS8qIFBhcmFtcyBmb3IgcGFzc2lu
ZyB0aGUgb2ZmbGluZWQgcGFnZSBudW1iZXIgdG8gRE9NMCAqLworCXVpbnQ2NF90IG1mbjsKKwl1
aW50NjRfdCBzdGF0dXM7Cit9OworCitzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIHsKKwkvKiBQ
YXJhbXMgZm9yIHBhc3NpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSBvZmZsaW5lZCBDUFUgdG8gRE9N
MCAqLworCXVpbnQzMl90IG1jX3NvY2tldGlkOworCXVpbnQxNl90IG1jX2NvcmVpZDsKKwl1aW50
MTZfdCBtY19jb3JlX3RocmVhZGlkOworfTsKKworI2RlZmluZSBNQVhfVU5JT05fU0laRSAxNgor
c3RydWN0IG1jaW5mb19yZWNvdmVyeSB7CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOwor
CXVpbnQxNl90IG1jX2Jhbms7IC8qIGJhbmsgbnIgKi8KKwl1aW50OF90IGFjdGlvbl9mbGFnczsK
Kwl1aW50OF90IGFjdGlvbl90eXBlczsKKwl1bmlvbiB7CisJCXN0cnVjdCBwYWdlX29mZmxpbmVf
YWN0aW9uIHBhZ2VfcmV0aXJlOworCQlzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIGNwdV9vZmZs
aW5lOworCQl1aW50OF90IHBhZFtNQVhfVU5JT05fU0laRV07CisJfSBhY3Rpb25faW5mbzsKK307
CisKKworI2RlZmluZSBNQ0lORk9fTUFYU0laRSA3NjgKK3N0cnVjdCBtY19pbmZvIHsKKwkvKiBO
dW1iZXIgb2YgbWNpbmZvXyogZW50cmllcyBpbiBtaV9kYXRhICovCisJdWludDMyX3QgbWlfbmVu
dHJpZXM7CisJdWludDMyX3QgZmxhZ3M7CisJdWludDY0X3QgbWlfZGF0YVsoTUNJTkZPX01BWFNJ
WkUgLSAxKSAvIDhdOworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKG1jX2luZm8pOwor
CisjZGVmaW5lIF9fTUNfTVNSX0FSUkFZU0laRSA4CisjZGVmaW5lIF9fTUNfTVNSX01DR0NBUCAw
CisjZGVmaW5lIF9fTUNfTk1TUlMgMQorI2RlZmluZSBNQ19OQ0FQUyA3CitzdHJ1Y3QgbWNpbmZv
X2xvZ2ljYWxfY3B1IHsKKwl1aW50MzJfdCBtY19jcHVucjsKKwl1aW50MzJfdCBtY19jaGlwaWQ7
CisJdWludDE2X3QgbWNfY29yZWlkOworCXVpbnQxNl90IG1jX3RocmVhZGlkOworCXVpbnQzMl90
IG1jX2FwaWNpZDsKKwl1aW50MzJfdCBtY19jbHVzdGVyaWQ7CisJdWludDMyX3QgbWNfbmNvcmVz
OworCXVpbnQzMl90IG1jX25jb3Jlc19hY3RpdmU7CisJdWludDMyX3QgbWNfbnRocmVhZHM7CisJ
dWludDMyX3QgbWNfY3B1aWRfbGV2ZWw7CisJdWludDMyX3QgbWNfZmFtaWx5OworCXVpbnQzMl90
IG1jX3ZlbmRvcjsKKwl1aW50MzJfdCBtY19tb2RlbDsKKwl1aW50MzJfdCBtY19zdGVwOworCWNo
YXIgbWNfdmVuZG9yaWRbMTZdOworCWNoYXIgbWNfYnJhbmRpZFs2NF07CisJdWludDMyX3QgbWNf
Y3B1X2NhcHNbTUNfTkNBUFNdOworCXVpbnQzMl90IG1jX2NhY2hlX3NpemU7CisJdWludDMyX3Qg
bWNfY2FjaGVfYWxpZ25tZW50OworCXVpbnQzMl90IG1jX25tc3J2YWxzOworCXN0cnVjdCBtY2lu
Zm9fbXNyIG1jX21zcnZhbHVlc1tfX01DX01TUl9BUlJBWVNJWkVdOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKG1jaW5mb19sb2dpY2FsX2NwdSk7CisKKy8qCisgKiBQcm90b3R5cGU6
CisgKiAgICB1aW50MzJfdCB4ODZfbWNpbmZvX25lbnRyaWVzKHN0cnVjdCBtY19pbmZvICptaSk7
CisgKi8KKyNkZWZpbmUgeDg2X21jaW5mb19uZW50cmllcyhfbWkpICAgIFwKKwkoKF9taSktPm1p
X25lbnRyaWVzKQorLyoKKyAqIFByb3RvdHlwZToKKyAqICAgIHN0cnVjdCBtY2luZm9fY29tbW9u
ICp4ODZfbWNpbmZvX2ZpcnN0KHN0cnVjdCBtY19pbmZvICptaSk7CisgKi8KKyNkZWZpbmUgeDg2
X21jaW5mb19maXJzdChfbWkpICAgICAgIFwKKwkoKHN0cnVjdCBtY2luZm9fY29tbW9uICopKF9t
aSktPm1pX2RhdGEpCisvKgorICogUHJvdG90eXBlOgorICogICAgc3RydWN0IG1jaW5mb19jb21t
b24gKng4Nl9tY2luZm9fbmV4dChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqbWljKTsKKyAqLworI2Rl
ZmluZSB4ODZfbWNpbmZvX25leHQoX21pYykgICAgICAgXAorCSgoc3RydWN0IG1jaW5mb19jb21t
b24gKikoKHVpbnQ4X3QgKikoX21pYykgKyAoX21pYyktPnNpemUpKQorCisvKgorICogUHJvdG90
eXBlOgorICogICAgdm9pZCB4ODZfbWNpbmZvX2xvb2t1cCh2b2lkICpyZXQsIHN0cnVjdCBtY19p
bmZvICptaSwgdWludDE2X3QgdHlwZSk7CisgKi8KK3N0YXRpYyBpbmxpbmUgdm9pZCB4ODZfbWNp
bmZvX2xvb2t1cChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKnJldCwKKwkJCQkgICAgIHN0cnVjdCBt
Y19pbmZvICptaSwgdWludDE2X3QgdHlwZSkKK3sKKwl1aW50MzJfdCBpOworCXN0cnVjdCBtY2lu
Zm9fY29tbW9uICptaWM7CisJYm9vbCBmb3VuZCA9IDA7CisKKwlpZiAoIXJldCB8fCAhbWkpCisJ
CXJldHVybjsKKworCW1pYyA9IHg4Nl9tY2luZm9fZmlyc3QobWkpOworCWZvciAoaSA9IDA7IGkg
PCB4ODZfbWNpbmZvX25lbnRyaWVzKG1pKTsgaSsrKSB7CisJCWlmIChtaWMtPnR5cGUgPT0gdHlw
ZSkgeworCQkJZm91bmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwkJbWljID0geDg2X21jaW5mb19u
ZXh0KG1pYyk7CisJfQorCisJKnJldCA9IGZvdW5kID8gbWljIDogTlVMTDsKK30KKworLyoKKyAq
IEZldGNoIG1hY2hpbmUgY2hlY2sgZGF0YSBmcm9tIGh5cGVydmlzb3IuCisgKi8KKyNkZWZpbmUg
WEVOX01DX2ZldGNoCQkxCitzdHJ1Y3QgeGVuX21jX2ZldGNoIHsKKwkvKgorCSAqIElOOiBYRU5f
TUNfTk9OVVJHRU5ULCBYRU5fTUNfVVJHRU5ULAorCSAqIFhFTl9NQ19BQ0sgaWYgYWNrJ2tpbmcg
YW4gZWFybGllciBmZXRjaAorCSAqIE9VVDogWEVOX01DX09LLCBYRU5fTUNfRkVUQ0hBSUxFRCwg
WEVOX01DX05PREFUQQorCSAqLworCXVpbnQzMl90IGZsYWdzOworCXVpbnQzMl90IF9wYWQwOwor
CS8qIE9VVDogaWQgZm9yIGFjaywgSU46IGlkIHdlIGFyZSBhY2snaW5nICovCisJdWludDY0X3Qg
ZmV0Y2hfaWQ7CisKKwkvKiBPVVQgdmFyaWFibGVzLiAqLworCUdVRVNUX0hBTkRMRShtY19pbmZv
KSBkYXRhOworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbl9tY19mZXRjaCk7CisK
KworLyoKKyAqIFRoaXMgdGVsbHMgdGhlIGh5cGVydmlzb3IgdG8gbm90aWZ5IGEgRG9tVSBhYm91
dCB0aGUgbWFjaGluZSBjaGVjayBlcnJvcgorICovCisjZGVmaW5lIFhFTl9NQ19ub3RpZnlkb21h
aW4JMgorc3RydWN0IHhlbl9tY19ub3RpZnlkb21haW4geworCS8qIElOIHZhcmlhYmxlcyAqLwor
CXVpbnQxNl90IG1jX2RvbWlkOyAvKiBUaGUgdW5wcml2aWxlZ2VkIGRvbWFpbiB0byBub3RpZnkg
Ki8KKwl1aW50MTZfdCBtY192Y3B1aWQ7IC8qIFRoZSB2Y3B1IGluIG1jX2RvbWlkIHRvIG5vdGlm
eSAqLworCisJLyogSU4vT1VUIHZhcmlhYmxlcyAqLworCXVpbnQzMl90IGZsYWdzOworfTsKK0RF
RklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbl9tY19ub3RpZnlkb21haW4pOworCisjZGVmaW5l
IFhFTl9NQ19waHlzY3B1aW5mbwkzCitzdHJ1Y3QgeGVuX21jX3BoeXNjcHVpbmZvIHsKKwkvKiBJ
Ti9PVVQgKi8KKwl1aW50MzJfdCBuY3B1czsKKwl1aW50MzJfdCBfcGFkMDsKKwkvKiBPVVQgKi8K
KwlHVUVTVF9IQU5ETEUobWNpbmZvX2xvZ2ljYWxfY3B1KSBpbmZvOworfTsKKworI2RlZmluZSBY
RU5fTUNfbXNyaW5qZWN0CTQKKyNkZWZpbmUgTUNfTVNSSU5KX01BWE1TUlMJOAorc3RydWN0IHhl
bl9tY19tc3JpbmplY3QgeworCS8qIElOICovCisJdWludDMyX3QgbWNpbmpfY3B1bnI7IC8qIHRh
cmdldCBwcm9jZXNzb3IgaWQgKi8KKwl1aW50MzJfdCBtY2lual9mbGFnczsgLyogc2VlIE1DX01T
UklOSl9GXyogYmVsb3cgKi8KKwl1aW50MzJfdCBtY2lual9jb3VudDsgLyogMCAuLiBjb3VudC0x
IGluIGFycmF5IGFyZSB2YWxpZCAqLworCXVpbnQzMl90IF9wYWQwOworCXN0cnVjdCBtY2luZm9f
bXNyIG1jaW5qX21zcltNQ19NU1JJTkpfTUFYTVNSU107Cit9OworCisvKiBGbGFncyBmb3IgbWNp
bmpfZmxhZ3MgYWJvdmU7IGJpdHMgMTYtMzEgYXJlIHJlc2VydmVkICovCisjZGVmaW5lIE1DX01T
UklOSl9GX0lOVEVSUE9TRQkweDEKKworI2RlZmluZSBYRU5fTUNfbWNlaW5qZWN0CTUKK3N0cnVj
dCB4ZW5fbWNfbWNlaW5qZWN0IHsKKwl1bnNpZ25lZCBpbnQgbWNlaW5qX2NwdW5yOyAvKiB0YXJn
ZXQgcHJvY2Vzc29yIGlkICovCit9OworCitzdHJ1Y3QgeGVuX21jIHsKKwl1aW50MzJfdCBjbWQ7
CisJdWludDMyX3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJ
T04gKi8KKwl1bmlvbiB7CisJCXN0cnVjdCB4ZW5fbWNfZmV0Y2ggICAgICAgIG1jX2ZldGNoOwor
CQlzdHJ1Y3QgeGVuX21jX25vdGlmeWRvbWFpbiBtY19ub3RpZnlkb21haW47CisJCXN0cnVjdCB4
ZW5fbWNfcGh5c2NwdWluZm8gIG1jX3BoeXNjcHVpbmZvOworCQlzdHJ1Y3QgeGVuX21jX21zcmlu
amVjdCAgICBtY19tc3JpbmplY3Q7CisJCXN0cnVjdCB4ZW5fbWNfbWNlaW5qZWN0ICAgIG1jX21j
ZWluamVjdDsKKwl9IHU7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jKTsK
KworI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIF9fWEVOX1BVQkxJQ19BUkNI
X1g4Nl9NQ0FfSF9fICovCi0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335154EFCSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Apr 19 13:30:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 13:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKrRK-0004Sn-7A; Thu, 19 Apr 2012 13:30:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKrRI-0004Se-RY
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 13:30:25 +0000
Received: from [193.109.254.147:53634] by server-8.bemta-14.messagelabs.com id
	DC/49-23244-073109F4; Thu, 19 Apr 2012 13:30:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334842221!2251598!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY3MjYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23334 invoked from network); 19 Apr 2012 13:30:22 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Apr 2012 13:30:22 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 19 Apr 2012 06:30:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="132876978"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 19 Apr 2012 06:30:21 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 19 Apr 2012 06:30:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 21:30:19 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 2/3] Register native mce handler as vMCE bounce back point
Thread-Index: Ac0eMI9iD+oSW/jqQkm/LrvBmMmVbg==
Date: Thu, 19 Apr 2012 13:30:17 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335154F12@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] Register native mce handler as vMCE bounce
	back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 8534a7b3fbd85410b35f0de26d09a48639a093a9 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 20 Apr 2012 05:09:55 +0800
Subject: [PATCH 2/3] Register native mce handler as vMCE bounce back point

When xen hypervisor inject vMCE to guest, use native mce handler to handle =
it

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 15628d4..346ba64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	/*
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
-	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * about.  Xen will handle faults like double_fault,
+	 * so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		/*
+		 * when xen hyeprvisor inject vMCE to guest,
+		 * use native mce handler to handle it
+		 */
+		;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch"
Content-Description: 0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch
Content-Disposition: attachment;
	filename="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch";
	size=1663; creation-date="Thu, 19 Apr 2012 13:21:53 GMT";
	modification-date="Thu, 19 Apr 2012 21:16:56 GMT"
Content-Transfer-Encoding: base64

RnJvbSA4NTM0YTdiM2ZiZDg1NDEwYjM1ZjBkZTI2ZDA5YTQ4NjM5YTA5M2E5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyMCBBcHIgMjAxMiAwNTowOTo1NSArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8z
XSBSZWdpc3RlciBuYXRpdmUgbWNlIGhhbmRsZXIgYXMgdk1DRSBib3VuY2UgYmFjayBwb2ludAoK
V2hlbiB4ZW4gaHlwZXJ2aXNvciBpbmplY3Qgdk1DRSB0byBndWVzdCwgdXNlIG5hdGl2ZSBtY2Ug
aGFuZGxlciB0byBoYW5kbGUgaXQKClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29u
Zy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBpbmcua2VAaW50
ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRl
bC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFy
ZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgfCAgIDEwICsr
KysrKystLS0KIDEgZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyBiL2FyY2gveDg2L3hlbi9l
bmxpZ2h0ZW4uYwppbmRleCAxNTYyOGQ0Li4zNDZiYTY0IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCkBAIC02MTQsOCAr
NjE0LDggQEAgc3RhdGljIGludCBjdnRfZ2F0ZV90b190cmFwKGludCB2ZWN0b3IsIGNvbnN0IGdh
dGVfZGVzYyAqdmFsLAogCS8qCiAJICogTG9vayBmb3Iga25vd24gdHJhcHMgdXNpbmcgSVNULCBh
bmQgc3Vic3RpdHV0ZSB0aGVtCiAJICogYXBwcm9wcmlhdGVseS4gIFRoZSBkZWJ1Z2dlciBvbmVz
IGFyZSB0aGUgb25seSBvbmVzIHdlIGNhcmUKLQkgKiBhYm91dC4gIFhlbiB3aWxsIGhhbmRsZSBm
YXVsdHMgbGlrZSBkb3VibGVfZmF1bHQgYW5kCi0JICogbWFjaGluZV9jaGVjaywgc28gd2Ugc2hv
dWxkIG5ldmVyIHNlZSB0aGVtLiAgV2FybiBpZgorCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxl
IGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVsdCwKKwkgKiBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRo
ZW0uICBXYXJuIGlmCiAJICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBo
YW5kbGVyLgogCSAqLwogCWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNjMw
LDcgKzYzMCwxMSBAQCBzdGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29u
c3QgZ2F0ZV9kZXNjICp2YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJ
fSBlbHNlIGlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0
dXJuIDA7CisJCS8qCisJCSAqIHdoZW4geGVuIGh5ZXBydmlzb3IgaW5qZWN0IHZNQ0UgdG8gZ3Vl
c3QsCisJCSAqIHVzZSBuYXRpdmUgbWNlIGhhbmRsZXIgdG8gaGFuZGxlIGl0CisJCSAqLworCQk7
CiAjZW5kaWYKIAl9IGVsc2UgewogCQkvKiBTb21lIG90aGVyIHRyYXAgdXNpbmcgSVNUPyAqLwot
LSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Apr 19 13:30:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 13:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKrRK-0004Sn-7A; Thu, 19 Apr 2012 13:30:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKrRI-0004Se-RY
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 13:30:25 +0000
Received: from [193.109.254.147:53634] by server-8.bemta-14.messagelabs.com id
	DC/49-23244-073109F4; Thu, 19 Apr 2012 13:30:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334842221!2251598!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY3MjYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23334 invoked from network); 19 Apr 2012 13:30:22 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Apr 2012 13:30:22 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 19 Apr 2012 06:30:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="132876978"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 19 Apr 2012 06:30:21 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 19 Apr 2012 06:30:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 21:30:19 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 2/3] Register native mce handler as vMCE bounce back point
Thread-Index: Ac0eMI9iD+oSW/jqQkm/LrvBmMmVbg==
Date: Thu, 19 Apr 2012 13:30:17 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335154F12@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] Register native mce handler as vMCE bounce
	back point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 8534a7b3fbd85410b35f0de26d09a48639a093a9 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 20 Apr 2012 05:09:55 +0800
Subject: [PATCH 2/3] Register native mce handler as vMCE bounce back point

When xen hypervisor inject vMCE to guest, use native mce handler to handle =
it

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 15628d4..346ba64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -614,8 +614,8 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	/*
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
-	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * about.  Xen will handle faults like double_fault,
+	 * so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -630,7 +630,11 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		/*
+		 * when xen hyeprvisor inject vMCE to guest,
+		 * use native mce handler to handle it
+		 */
+		;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch"
Content-Description: 0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch
Content-Disposition: attachment;
	filename="0002-Register-native-mce-handler-as-vMCE-bounce-back-poin.patch";
	size=1663; creation-date="Thu, 19 Apr 2012 13:21:53 GMT";
	modification-date="Thu, 19 Apr 2012 21:16:56 GMT"
Content-Transfer-Encoding: base64

RnJvbSA4NTM0YTdiM2ZiZDg1NDEwYjM1ZjBkZTI2ZDA5YTQ4NjM5YTA5M2E5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyMCBBcHIgMjAxMiAwNTowOTo1NSArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8z
XSBSZWdpc3RlciBuYXRpdmUgbWNlIGhhbmRsZXIgYXMgdk1DRSBib3VuY2UgYmFjayBwb2ludAoK
V2hlbiB4ZW4gaHlwZXJ2aXNvciBpbmplY3Qgdk1DRSB0byBndWVzdCwgdXNlIG5hdGl2ZSBtY2Ug
aGFuZGxlciB0byBoYW5kbGUgaXQKClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29u
Zy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBpbmcua2VAaW50
ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRl
bC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFy
ZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgfCAgIDEwICsr
KysrKystLS0KIDEgZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyBiL2FyY2gveDg2L3hlbi9l
bmxpZ2h0ZW4uYwppbmRleCAxNTYyOGQ0Li4zNDZiYTY0IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCkBAIC02MTQsOCAr
NjE0LDggQEAgc3RhdGljIGludCBjdnRfZ2F0ZV90b190cmFwKGludCB2ZWN0b3IsIGNvbnN0IGdh
dGVfZGVzYyAqdmFsLAogCS8qCiAJICogTG9vayBmb3Iga25vd24gdHJhcHMgdXNpbmcgSVNULCBh
bmQgc3Vic3RpdHV0ZSB0aGVtCiAJICogYXBwcm9wcmlhdGVseS4gIFRoZSBkZWJ1Z2dlciBvbmVz
IGFyZSB0aGUgb25seSBvbmVzIHdlIGNhcmUKLQkgKiBhYm91dC4gIFhlbiB3aWxsIGhhbmRsZSBm
YXVsdHMgbGlrZSBkb3VibGVfZmF1bHQgYW5kCi0JICogbWFjaGluZV9jaGVjaywgc28gd2Ugc2hv
dWxkIG5ldmVyIHNlZSB0aGVtLiAgV2FybiBpZgorCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxl
IGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVsdCwKKwkgKiBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRo
ZW0uICBXYXJuIGlmCiAJICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBo
YW5kbGVyLgogCSAqLwogCWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNjMw
LDcgKzYzMCwxMSBAQCBzdGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29u
c3QgZ2F0ZV9kZXNjICp2YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJ
fSBlbHNlIGlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0
dXJuIDA7CisJCS8qCisJCSAqIHdoZW4geGVuIGh5ZXBydmlzb3IgaW5qZWN0IHZNQ0UgdG8gZ3Vl
c3QsCisJCSAqIHVzZSBuYXRpdmUgbWNlIGhhbmRsZXIgdG8gaGFuZGxlIGl0CisJCSAqLworCQk7
CiAjZW5kaWYKIAl9IGVsc2UgewogCQkvKiBTb21lIG90aGVyIHRyYXAgdXNpbmcgSVNUPyAqLwot
LSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335154F12SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Apr 19 13:33:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 13:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKrU5-0004kP-QY; Thu, 19 Apr 2012 13:33:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKrU3-0004k6-Nl
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 13:33:16 +0000
Received: from [85.158.143.35:37325] by server-3.bemta-4.messagelabs.com id
	C5/F4-05853-B14109F4; Thu, 19 Apr 2012 13:33:15 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334842388!13160263!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY3MjYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15575 invoked from network); 19 Apr 2012 13:33:09 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 13:33:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 19 Apr 2012 06:33:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="90897483"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 19 Apr 2012 06:33:07 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 19 Apr 2012 06:33:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 21:33:04 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 3/3] Xen physical cpus interface
Thread-Index: Ac0eMPIz1b8pDRiwSFiwkpXixs4X8A==
Date: Thu, 19 Apr 2012 13:33:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335154F3E@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] Xen physical cpus interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From afdd30a7769e706e9be64f80d64136e2e267ecb9 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 20 Apr 2012 05:11:58 +0800
Subject: [PATCH 3/3] Xen physical cpus interface

Manage physical cpus in dom0, get physical cpus info and provide sys interf=
ace.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/xen/Makefile             |    1 +
 drivers/xen/pcpu.c               |  393 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   10 +-
 include/xen/interface/xen.h      |    1 +
 4 files changed, 404 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 1d3e763..d12d14d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
+obj-$(CONFIG_XEN_DOM0)			+=3D pcpu.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+=3D xen-acpi-processor.o
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..9295def
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,393 @@
+/*************************************************************************=
*****
+ * pcpu.c
+ * Management physical cpu in dom0, get pcpu info and provide sys interfac=
e
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/cpu.h>
+#include <linux/stat.h>
+#include <xen/xen.h>
+#include <xen/xenbus.h>
+#include <xen/events.h>
+#include <xen/interface/platform.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct device dev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static struct bus_type xen_pcpu_subsys =3D {
+	.name =3D "xen_cpu",
+	.dev_name =3D "xen_cpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+#define XEN_PCPU "xen_cpu: "
+
+struct xen_pcpus {
+	struct list_head list;
+};
+static struct xen_pcpus xen_pcpus;
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);
+
+static ssize_t show_apicid(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static DEVICE_ATTR(apic_id, S_IRUGO, show_apicid, NULL);
+static DEVICE_ATTR(acpi_id, S_IRUGO, show_acpiid, NULL);
+
+static bool xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+static void pcpu_online_status(struct xenpf_pcpuinfo *info,
+			       struct pcpu *pcpu)
+{
+	if (xen_pcpu_online(info->flags) &&
+	   !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
+	} else if (!xen_pcpu_online(info->flags) &&
+		    xen_pcpu_online(pcpu->flags)) {
+		/* The pcpu is offlined */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
+	}
+}
+
+static struct pcpu *get_pcpu(uint32_t xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static void pcpu_sys_remove(struct pcpu *pcpu)
+{
+	struct device *dev;
+
+	if (!pcpu)
+		return;
+
+	dev =3D &pcpu->dev;
+	if (dev->id)
+		device_remove_file(dev, &dev_attr_online);
+	device_remove_file(dev, &dev_attr_acpi_id);
+	device_remove_file(dev, &dev_attr_apic_id);
+	device_unregister(dev);
+}
+
+static void free_pcpu(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return;
+
+	pcpu_sys_remove(pcpu);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+}
+
+static int pcpu_sys_create(struct pcpu *pcpu)
+{
+	struct device *dev;
+	int err =3D -EINVAL;
+
+	if (!pcpu)
+		return err;
+
+	dev =3D &pcpu->dev;
+	dev->bus =3D &xen_pcpu_subsys;
+	dev->id =3D pcpu->xen_id;
+
+	err =3D device_register(dev);
+	if (err)
+		goto err1;
+
+	err =3D device_create_file(dev, &dev_attr_apic_id);
+	if (err)
+		goto err2;
+	err =3D device_create_file(dev, &dev_attr_acpi_id);
+	if (err)
+		goto err3;
+	/* Not open pcpu0 online access to user */
+	if (dev->id) {
+		err =3D device_create_file(dev, &dev_attr_online);
+		if (err)
+			goto err4;
+	}
+
+	return 0;
+
+err4:
+	device_remove_file(dev, &dev_attr_acpi_id);
+err3:
+	device_remove_file(dev, &dev_attr_apic_id);
+err2:
+	device_unregister(dev);
+err1:
+	return err;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+	int err;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return ERR_PTR(-ENODEV);
+
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	err =3D pcpu_sys_create(pcpu);
+	if (err) {
+		pr_warning(XEN_PCPU "Failed to register pcpu%d\n",
+			   info->xen_cpuid);
+		kfree(pcpu);
+		return ERR_PTR(-ENOENT);
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	return pcpu;
+}
+
+/*
+ * Caller should hold the pcpu lock
+ */
+static int _sync_pcpu(uint32_t cpu_num, uint32_t *ptr_max_cpu_num)
+{
+	int ret;
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	struct xen_platform_op op =3D {
+		.cmd                   =3D XENPF_get_cpuinfo,
+		.interface_version     =3D XENPF_INTERFACE_VERSION,
+		.u.pcpu_info.xen_cpuid =3D cpu_num,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	info =3D &op.u.pcpu_info;
+	if (ptr_max_cpu_num)
+		*ptr_max_cpu_num =3D info->max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		if (pcpu)
+			free_pcpu(pcpu);
+		return 0;
+	}
+
+	if (!pcpu) {
+		pcpu =3D init_pcpu(info);
+		if (IS_ERR_OR_NULL(pcpu))
+			return -ENODEV;
+	} else
+		pcpu_online_status(info, pcpu);
+
+	return 0;
+}
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	uint32_t cpu_num =3D 0, max_cpu_num =3D 0;
+	int err =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while (!err && (cpu_num <=3D max_cpu_num)) {
+		err =3D _sync_pcpu(cpu_num, &max_cpu_num);
+		cpu_num++;
+	}
+
+	if (err) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			free_pcpu(pcpu);
+		}
+	}
+
+	put_pcpu_lock();
+
+	return err;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	xen_sync_pcpus();
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int ret;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	ret =3D subsys_system_register(&xen_pcpu_subsys, NULL);
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
+		return ret;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+
+	ret =3D xen_sync_pcpus();
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
+		return ret;
+	}
+
+	ret =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
+				      xen_pcpu_interrupt, 0,
+				      "pcpu", NULL);
+	if (ret < 0) {
+		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");
+		return ret;
+	}
+
+	return 0;
+}
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 486653f..2c56d4f 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -298,7 +298,7 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
-#define XENPF_get_cpuinfo 55
+#define XENPF_get_cpuinfo	55
 struct xenpf_pcpuinfo {
 	/* IN */
 	uint32_t xen_cpuid;
@@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
=20
+#define XENPF_cpu_online	56
+#define XENPF_cpu_offline	57
+struct xenpf_cpu_ol {
+	uint32_t cpuid;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -330,6 +337,7 @@ struct xen_platform_op {
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..0801468 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0003-Xen-physical-cpus-interface.patch"
Content-Description: 0003-Xen-physical-cpus-interface.patch
Content-Disposition: attachment;
	filename="0003-Xen-physical-cpus-interface.patch"; size=12339;
	creation-date="Thu, 19 Apr 2012 13:21:53 GMT";
	modification-date="Thu, 19 Apr 2012 21:16:56 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhZmRkMzBhNzc2OWU3MDZlOWJlNjRmODBkNjQxMzZlMmUyNjdlY2I5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyMCBBcHIgMjAxMiAwNToxMTo1OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMy8z
XSBYZW4gcGh5c2ljYWwgY3B1cyBpbnRlcmZhY2UKCk1hbmFnZSBwaHlzaWNhbCBjcHVzIGluIGRv
bTAsIGdldCBwaHlzaWNhbCBjcHVzIGluZm8gYW5kIHByb3ZpZGUgc3lzIGludGVyZmFjZS4KClNp
Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+Ci0tLQogZHJp
dmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgfCAgICAxICsKIGRyaXZlcnMveGVuL3BjcHUu
YyAgICAgICAgICAgICAgIHwgIDM5MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggfCAgIDEwICstCiBpbmNsdWRl
L3hlbi9pbnRlcmZhY2UveGVuLmggICAgICB8ICAgIDEgKwogNCBmaWxlcyBjaGFuZ2VkLCA0MDQg
aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJz
L3hlbi9wY3B1LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9NYWtlZmlsZSBiL2RyaXZlcnMv
eGVuL01ha2VmaWxlCmluZGV4IDFkM2U3NjMuLmQxMmQxNGQgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMv
eGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxlCkBAIC0xOSw2ICsxOSw3IEBA
IG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNpLm8KIG9iai0kKENPTkZJ
R19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJCSs9IHN3
aW90bGIteGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubworb2JqLSQoQ09O
RklHX1hFTl9ET00wKQkJCSs9IHBjcHUubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO
RCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05GSUdfWEVOX1BSSVZDTUQpCQkrPSB4ZW4tcHJp
dmNtZC5vCiBvYmotJChDT05GSUdfWEVOX0FDUElfUFJPQ0VTU09SKQkrPSB4ZW4tYWNwaS1wcm9j
ZXNzb3IubwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vcGNwdS5jIGIvZHJpdmVycy94ZW4vcGNw
dS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjkyOTVkZWYKLS0tIC9kZXYv
bnVsbAorKysgYi9kcml2ZXJzL3hlbi9wY3B1LmMKQEAgLTAsMCArMSwzOTMgQEAKKy8qKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioKKyAqIHBjcHUuYworICogTWFuYWdlbWVudCBwaHlzaWNhbCBjcHUgaW4g
ZG9tMCwgZ2V0IHBjcHUgaW5mbyBhbmQgcHJvdmlkZSBzeXMgaW50ZXJmYWNlCisgKgorICogQ29w
eXJpZ2h0IChjKSAyMDEyIEludGVsIENvcnBvcmF0aW9uCisgKiBBdXRob3I6IExpdSwgSmluc29u
ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgorICogQXV0aG9yOiBKaWFuZywgWXVuaG9uZyA8eXVu
aG9uZy5qaWFuZ0BpbnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICogbW9kaWZ5IGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyCisgKiBh
cyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgb3IsIHdoZW4gZGlz
dHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgga2VybmVsIG9yIGluY29ycG9y
YXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywgc3ViamVjdCB0byB0aGUgZm9s
bG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJl
ZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBz
b3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRoZSBTb2Z0d2FyZSB3aXRo
b3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRhdGlvbiB0aGUgcmln
aHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1Ymxpc2gsIGRpc3RyaWJ1dGUs
IHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUsCisgKiBhbmQg
dG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUgaXMgZnVybmlzaGVkIHRvIGRv
IHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6CisgKgorICogVGhl
IGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ugc2hhbGwg
YmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3RhbnRpYWwgcG9ydGlvbnMgb2Yg
dGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiLCBX
SVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9SCisgKiBJTVBMSUVELCBJTkNM
VURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU
WSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFORCBOT05JTkZSSU5HRU1F
TlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBPUiBDT1BZUklHSFQgSE9MREVS
UyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBPVEhFUgorICogTElBQklMSVRZ
LCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9SVCBPUiBPVEhFUldJU0UsIEFS
SVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFNPRlRXQVJF
IE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRIRSBTT0ZUV0FSRS4KKyAqLwor
CisjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2su
aD4KKyNpbmNsdWRlIDxsaW51eC9jcHUuaD4KKyNpbmNsdWRlIDxsaW51eC9zdGF0Lmg+CisjaW5j
bHVkZSA8eGVuL3hlbi5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
ZXZlbnRzLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUg
PGFzbS94ZW4vaHlwZXJ2aXNvci5oPgorI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisK
K3N0cnVjdCBwY3B1IHsKKwlzdHJ1Y3QgbGlzdF9oZWFkIHBjcHVfbGlzdDsKKwlzdHJ1Y3QgZGV2
aWNlIGRldjsKKwl1aW50MzJfdCB4ZW5faWQ7CisJdWludDMyX3QgYXBpY19pZDsKKwl1aW50MzJf
dCBhY3BpX2lkOworCXVpbnQzMl90IGZsYWdzOworfTsKKworc3RhdGljIHN0cnVjdCBidXNfdHlw
ZSB4ZW5fcGNwdV9zdWJzeXMgPSB7CisJLm5hbWUgPSAieGVuX2NwdSIsCisJLmRldl9uYW1lID0g
Inhlbl9jcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9sb2NrKTsKKyNk
ZWZpbmUgZ2V0X3BjcHVfbG9jaygpIG11dGV4X2xvY2soJnhlbl9wY3B1X2xvY2spOworI2RlZmlu
ZSBwdXRfcGNwdV9sb2NrKCkgbXV0ZXhfdW5sb2NrKCZ4ZW5fcGNwdV9sb2NrKTsKKworI2RlZmlu
ZSBYRU5fUENQVSAieGVuX2NwdTogIgorCitzdHJ1Y3QgeGVuX3BjcHVzIHsKKwlzdHJ1Y3QgbGlz
dF9oZWFkIGxpc3Q7Cit9Oworc3RhdGljIHN0cnVjdCB4ZW5fcGNwdXMgeGVuX3BjcHVzOworCitz
dGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCByZXQ7CisJ
c3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZAkJCT0gWEVOUEZfY3B1X29mZmxp
bmUsCisJCS5pbnRlcmZhY2VfdmVyc2lvbgk9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCQku
dS5jcHVfb2wuY3B1aWQJCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7
CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vbmxpbmUsCisJCS5pbnRlcmZhY2VfdmVyc2lvbgk9IFhF
TlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCQkudS5jcHVfb2wuY3B1aWQJCT0geGVuX2lkLAorCX07
CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitz
dGF0aWMgc3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3QgZGV2aWNlICpkZXYsCisJCQkgICBzdHJ1
Y3QgZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwKKwkJCSAgIGNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3Qg
cGNwdSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIGRldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgISEoY3B1LT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX09O
TElORSkpOworfQorCitzdGF0aWMgc3NpemVfdCBfX3JlZiBzdG9yZV9vbmxpbmUoc3RydWN0IGRl
dmljZSAqZGV2LAorCQkJCSAgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsCisJCQkJICBj
b25zdCBjaGFyICpidWYsIHNpemVfdCBjb3VudCkKK3sKKwlzdHJ1Y3QgcGNwdSAqY3B1ID0gY29u
dGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIGRldik7CisJc3NpemVfdCByZXQ7CisKKwlzd2l0
Y2ggKGJ1ZlswXSkgeworCWNhc2UgJzAnOgorCQlyZXQgPSB4ZW5fcGNwdV9kb3duKGNwdS0+eGVu
X2lkKTsKKwkJYnJlYWs7CisJY2FzZSAnMSc6CisJCXJldCA9IHhlbl9wY3B1X3VwKGNwdS0+eGVu
X2lkKTsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcmV0ID0gLUVJTlZBTDsKKwl9CisKKwlpZiAo
cmV0ID49IDApCisJCXJldCA9IGNvdW50OworCXJldHVybiByZXQ7Cit9CitzdGF0aWMgREVWSUNF
X0FUVFIob25saW5lLCBTX0lSVUdPIHwgU19JV1VTUiwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGlu
ZSk7CisKK3N0YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBkZXZpY2UgKmRldiwKKwkJ
CSAgIHN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLAorCQkJICAgY2hhciAqYnVmKQorewor
CXN0cnVjdCBwY3B1ICpjcHUgPSBjb250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgZGV2KTsK
KworCXJldHVybiBzcHJpbnRmKGJ1ZiwgIiV1XG4iLCBjcHUtPmFwaWNfaWQpOworfQorCitzdGF0
aWMgc3NpemVfdCBzaG93X2FjcGlpZChzdHJ1Y3QgZGV2aWNlICpkZXYsCisJCQkgICBzdHJ1Y3Qg
ZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwKKwkJCSAgIGNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIGRldik7CisKKwlyZXR1cm4g
c3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hY3BpX2lkKTsKK30KK3N0YXRpYyBERVZJQ0VfQVRU
UihhcGljX2lkLCBTX0lSVUdPLCBzaG93X2FwaWNpZCwgTlVMTCk7CitzdGF0aWMgREVWSUNFX0FU
VFIoYWNwaV9pZCwgU19JUlVHTywgc2hvd19hY3BpaWQsIE5VTEwpOworCitzdGF0aWMgYm9vbCB4
ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7CisJcmV0dXJuICEhKGZsYWdzICYgWEVO
X1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworc3RhdGljIHZvaWQgcGNwdV9vbmxpbmVfc3RhdHVz
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICAgICBzdHJ1Y3QgcGNwdSAqcGNw
dSkKK3sKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJgorCSAgICF4ZW5fcGNw
dV9vbmxpbmUocGNwdS0+ZmxhZ3MpKSB7CisJCS8qIHRoZSBwY3B1IGlzIG9ubGluZWQgKi8KKwkJ
cGNwdS0+ZmxhZ3MgfD0gWEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgm
cGNwdS0+ZGV2LmtvYmosIEtPQkpfT05MSU5FKTsKKwl9IGVsc2UgaWYgKCF4ZW5fcGNwdV9vbmxp
bmUoaW5mby0+ZmxhZ3MpICYmCisJCSAgICB4ZW5fcGNwdV9vbmxpbmUocGNwdS0+ZmxhZ3MpKSB7
CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkICovCisJCXBjcHUtPmZsYWdzICY9IH5YRU5fUENQ
VV9GTEFHU19PTkxJTkU7CisJCWtvYmplY3RfdWV2ZW50KCZwY3B1LT5kZXYua29iaiwgS09CSl9P
RkZMSU5FKTsKKwl9Cit9CisKK3N0YXRpYyBzdHJ1Y3QgcGNwdSAqZ2V0X3BjcHUodWludDMyX3Qg
eGVuX2lkKQoreworCXN0cnVjdCBwY3B1ICpwY3B1ID0gTlVMTDsKKworCWxpc3RfZm9yX2VhY2hf
ZW50cnkocGNwdSwgJnhlbl9wY3B1cy5saXN0LCBwY3B1X2xpc3QpIHsKKwkJaWYgKHBjcHUtPnhl
bl9pZCA9PSB4ZW5faWQpCisJCQlyZXR1cm4gcGNwdTsKKwl9CisJcmV0dXJuIE5VTEw7Cit9CisK
K3N0YXRpYyB2b2lkIHBjcHVfc3lzX3JlbW92ZShzdHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlzdHJ1
Y3QgZGV2aWNlICpkZXY7CisKKwlpZiAoIXBjcHUpCisJCXJldHVybjsKKworCWRldiA9ICZwY3B1
LT5kZXY7CisJaWYgKGRldi0+aWQpCisJCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0
cl9vbmxpbmUpOworCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0cl9hY3BpX2lkKTsK
KwlkZXZpY2VfcmVtb3ZlX2ZpbGUoZGV2LCAmZGV2X2F0dHJfYXBpY19pZCk7CisJZGV2aWNlX3Vu
cmVnaXN0ZXIoZGV2KTsKK30KKworc3RhdGljIHZvaWQgZnJlZV9wY3B1KHN0cnVjdCBwY3B1ICpw
Y3B1KQoreworCWlmICghcGNwdSkKKwkJcmV0dXJuOworCisJcGNwdV9zeXNfcmVtb3ZlKHBjcHUp
OworCWxpc3RfZGVsKCZwY3B1LT5wY3B1X2xpc3QpOworCWtmcmVlKHBjcHUpOworfQorCitzdGF0
aWMgaW50IHBjcHVfc3lzX2NyZWF0ZShzdHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlzdHJ1Y3QgZGV2
aWNlICpkZXY7CisJaW50IGVyciA9IC1FSU5WQUw7CisKKwlpZiAoIXBjcHUpCisJCXJldHVybiBl
cnI7CisKKwlkZXYgPSAmcGNwdS0+ZGV2OworCWRldi0+YnVzID0gJnhlbl9wY3B1X3N1YnN5czsK
KwlkZXYtPmlkID0gcGNwdS0+eGVuX2lkOworCisJZXJyID0gZGV2aWNlX3JlZ2lzdGVyKGRldik7
CisJaWYgKGVycikKKwkJZ290byBlcnIxOworCisJZXJyID0gZGV2aWNlX2NyZWF0ZV9maWxlKGRl
diwgJmRldl9hdHRyX2FwaWNfaWQpOworCWlmIChlcnIpCisJCWdvdG8gZXJyMjsKKwllcnIgPSBk
ZXZpY2VfY3JlYXRlX2ZpbGUoZGV2LCAmZGV2X2F0dHJfYWNwaV9pZCk7CisJaWYgKGVycikKKwkJ
Z290byBlcnIzOworCS8qIE5vdCBvcGVuIHBjcHUwIG9ubGluZSBhY2Nlc3MgdG8gdXNlciAqLwor
CWlmIChkZXYtPmlkKSB7CisJCWVyciA9IGRldmljZV9jcmVhdGVfZmlsZShkZXYsICZkZXZfYXR0
cl9vbmxpbmUpOworCQlpZiAoZXJyKQorCQkJZ290byBlcnI0OworCX0KKworCXJldHVybiAwOwor
CitlcnI0OgorCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0cl9hY3BpX2lkKTsKK2Vy
cjM6CisJZGV2aWNlX3JlbW92ZV9maWxlKGRldiwgJmRldl9hdHRyX2FwaWNfaWQpOworZXJyMjoK
KwlkZXZpY2VfdW5yZWdpc3RlcihkZXYpOworZXJyMToKKwlyZXR1cm4gZXJyOworfQorCitzdGF0
aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShzdHJ1Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCit7
CisJc3RydWN0IHBjcHUgKnBjcHU7CisJaW50IGVycjsKKworCWlmIChpbmZvLT5mbGFncyAmIFhF
Tl9QQ1BVX0ZMQUdTX0lOVkFMSUQpCisJCXJldHVybiBFUlJfUFRSKC1FTk9ERVYpOworCisJcGNw
dSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwgR0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1
KQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKworCUlOSVRfTElTVF9IRUFEKCZwY3B1LT5w
Y3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsKKwlwY3B1LT5hcGlj
X2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+YWNwaV9pZDsKKwlw
Y3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJZXJyID0gcGNwdV9zeXNfY3JlYXRlKHBjcHUp
OworCWlmIChlcnIpIHsKKwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVkIHRvIHJlZ2lzdGVy
IHBjcHUlZFxuIiwKKwkJCSAgIGluZm8tPnhlbl9jcHVpZCk7CisJCWtmcmVlKHBjcHUpOworCQly
ZXR1cm4gRVJSX1BUUigtRU5PRU5UKTsKKwl9CisKKwlsaXN0X2FkZF90YWlsKCZwY3B1LT5wY3B1
X2xpc3QsICZ4ZW5fcGNwdXMubGlzdCk7CisJcmV0dXJuIHBjcHU7Cit9CisKKy8qCisgKiBDYWxs
ZXIgc2hvdWxkIGhvbGQgdGhlIHBjcHUgbG9jaworICovCitzdGF0aWMgaW50IF9zeW5jX3BjcHUo
dWludDMyX3QgY3B1X251bSwgdWludDMyX3QgKnB0cl9tYXhfY3B1X251bSkKK3sKKwlpbnQgcmV0
OworCXN0cnVjdCBwY3B1ICpwY3B1ID0gTlVMTDsKKwlzdHJ1Y3QgeGVucGZfcGNwdWluZm8gKmlu
Zm87CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgICAg
ICAgICA9IFhFTlBGX2dldF9jcHVpbmZvLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24gICAgID0gWEVO
UEZfSU5URVJGQUNFX1ZFUlNJT04sCisJCS51LnBjcHVfaW5mby54ZW5fY3B1aWQgPSBjcHVfbnVt
LAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0KQorCQly
ZXR1cm4gcmV0OworCisJaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKwlpZiAocHRyX21heF9jcHVf
bnVtKQorCQkqcHRyX21heF9jcHVfbnVtID0gaW5mby0+bWF4X3ByZXNlbnQ7CisKKwlwY3B1ID0g
Z2V0X3BjcHUoY3B1X251bSk7CisKKwlpZiAoaW5mby0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19J
TlZBTElEKSB7CisJCS8qIFRoZSBwY3B1IGhhcyBiZWVuIHJlbW92ZWQgKi8KKwkJaWYgKHBjcHUp
CisJCQlmcmVlX3BjcHUocGNwdSk7CisJCXJldHVybiAwOworCX0KKworCWlmICghcGNwdSkgewor
CQlwY3B1ID0gaW5pdF9wY3B1KGluZm8pOworCQlpZiAoSVNfRVJSX09SX05VTEwocGNwdSkpCisJ
CQlyZXR1cm4gLUVOT0RFVjsKKwl9IGVsc2UKKwkJcGNwdV9vbmxpbmVfc3RhdHVzKGluZm8sIHBj
cHUpOworCisJcmV0dXJuIDA7Cit9CisKKy8qCisgKiBTeW5jIGRvbTAncyBwY3B1IGluZm9ybWF0
aW9uIHdpdGggeGVuIGh5cGVydmlzb3IncworICovCitzdGF0aWMgaW50IHhlbl9zeW5jX3BjcHVz
KHZvaWQpCit7CisJLyoKKwkgKiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQgMCBpbiB4ZW4K
KwkgKi8KKwl1aW50MzJfdCBjcHVfbnVtID0gMCwgbWF4X2NwdV9udW0gPSAwOworCWludCBlcnIg
PSAwOworCXN0cnVjdCBsaXN0X2hlYWQgKmVsZW0sICp0bXA7CisJc3RydWN0IHBjcHUgKnBjcHU7
CisKKwlnZXRfcGNwdV9sb2NrKCk7CisKKwl3aGlsZSAoIWVyciAmJiAoY3B1X251bSA8PSBtYXhf
Y3B1X251bSkpIHsKKwkJZXJyID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2NwdV9udW0pOwor
CQljcHVfbnVtKys7CisJfQorCisJaWYgKGVycikgeworCQlsaXN0X2Zvcl9lYWNoX3NhZmUoZWxl
bSwgdG1wLCAmeGVuX3BjcHVzLmxpc3QpIHsKKwkJCXBjcHUgPSBsaXN0X2VudHJ5KGVsZW0sIHN0
cnVjdCBwY3B1LCBwY3B1X2xpc3QpOworCQkJZnJlZV9wY3B1KHBjcHUpOworCQl9CisJfQorCisJ
cHV0X3BjcHVfbG9jaygpOworCisJcmV0dXJuIGVycjsKK30KKworc3RhdGljIHZvaWQgeGVuX3Bj
cHVfZHBjKHN0cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKK3sKKwl4ZW5fc3luY19wY3B1cygpOwor
fQorc3RhdGljIERFQ0xBUkVfV09SSyh4ZW5fcGNwdV93b3JrLCB4ZW5fcGNwdV9kcGMpOworCitz
dGF0aWMgaXJxcmV0dXJuX3QgeGVuX3BjcHVfaW50ZXJydXB0KGludCBpcnEsIHZvaWQgKmRldl9p
ZCkKK3sKKwlzY2hlZHVsZV93b3JrKCZ4ZW5fcGNwdV93b3JrKTsKKwlyZXR1cm4gSVJRX0hBTkRM
RUQ7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1X2luaXQodm9pZCkKK3sKKwlpbnQg
cmV0OworCisJaWYgKCF4ZW5faW5pdGlhbF9kb21haW4oKSkKKwkJcmV0dXJuIC1FTk9ERVY7CisK
KwlyZXQgPSBzdWJzeXNfc3lzdGVtX3JlZ2lzdGVyKCZ4ZW5fcGNwdV9zdWJzeXMsIE5VTEwpOwor
CWlmIChyZXQpIHsKKwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVkIHRvIHJlZ2lzdGVyIHBj
cHUgc3Vic3lzXG4iKTsKKwkJcmV0dXJuIHJldDsKKwl9CisKKwlJTklUX0xJU1RfSEVBRCgmeGVu
X3BjcHVzLmxpc3QpOworCisJcmV0ID0geGVuX3N5bmNfcGNwdXMoKTsKKwlpZiAocmV0KSB7CisJ
CXByX3dhcm5pbmcoWEVOX1BDUFUgIkZhaWxlZCB0byBzeW5jIHBjcHUgaW5mb1xuIik7CisJCXJl
dHVybiByZXQ7CisJfQorCisJcmV0ID0gYmluZF92aXJxX3RvX2lycWhhbmRsZXIoVklSUV9QQ1BV
X1NUQVRFLCAwLAorCQkJCSAgICAgIHhlbl9wY3B1X2ludGVycnVwdCwgMCwKKwkJCQkgICAgICAi
cGNwdSIsIE5VTEwpOworCWlmIChyZXQgPCAwKSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZh
aWxlZCB0byBiaW5kIHBjcHUgdmlycVxuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0dXJu
IDA7Cit9CithcmNoX2luaXRjYWxsKHhlbl9wY3B1X2luaXQpOwpkaWZmIC0tZ2l0IGEvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaAppbmRleCA0ODY2NTNmLi4yYzU2ZDRmIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApA
QCAtMjk4LDcgKzI5OCw3IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9
OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8p
OwogCi0jZGVmaW5lIFhFTlBGX2dldF9jcHVpbmZvIDU1CisjZGVmaW5lIFhFTlBGX2dldF9jcHVp
bmZvCTU1CiBzdHJ1Y3QgeGVucGZfcGNwdWluZm8gewogCS8qIElOICovCiAJdWludDMyX3QgeGVu
X2NwdWlkOwpAQCAtMzE0LDYgKzMxNCwxMyBAQCBzdHJ1Y3QgeGVucGZfcGNwdWluZm8gewogfTsK
IERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvKTsKIAorI2RlZmluZSBY
RU5QRl9jcHVfb25saW5lCTU2CisjZGVmaW5lIFhFTlBGX2NwdV9vZmZsaW5lCTU3CitzdHJ1Y3Qg
eGVucGZfY3B1X29sIHsKKwl1aW50MzJfdCBjcHVpZDsKK307CitERUZJTkVfR1VFU1RfSEFORExF
X1NUUlVDVCh4ZW5wZl9jcHVfb2wpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50
MzJfdCBjbWQ7CiAJdWludDMyX3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFD
RV9WRVJTSU9OICovCkBAIC0zMzAsNiArMzM3LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7
CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGltZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0
IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZvIHNldF9wbWluZm87CiAJCXN0cnVjdCB4ZW5wZl9w
Y3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAg
ICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsK
IAl9IHU7CiB9OwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IGE4OTA4MDQuLjA4MDE0NjggMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Apr 19 13:33:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 13:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKrU5-0004kP-QY; Thu, 19 Apr 2012 13:33:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SKrU3-0004k6-Nl
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 13:33:16 +0000
Received: from [85.158.143.35:37325] by server-3.bemta-4.messagelabs.com id
	C5/F4-05853-B14109F4; Thu, 19 Apr 2012 13:33:15 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334842388!13160263!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY3MjYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15575 invoked from network); 19 Apr 2012 13:33:09 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 13:33:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 19 Apr 2012 06:33:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="90897483"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 19 Apr 2012 06:33:07 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 19 Apr 2012 06:33:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Thu, 19 Apr 2012 21:33:04 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 3/3] Xen physical cpus interface
Thread-Index: Ac0eMPIz1b8pDRiwSFiwkpXixs4X8A==
Date: Thu, 19 Apr 2012 13:33:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335154F3E@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] Xen physical cpus interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From afdd30a7769e706e9be64f80d64136e2e267ecb9 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 20 Apr 2012 05:11:58 +0800
Subject: [PATCH 3/3] Xen physical cpus interface

Manage physical cpus in dom0, get physical cpus info and provide sys interf=
ace.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/xen/Makefile             |    1 +
 drivers/xen/pcpu.c               |  393 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   10 +-
 include/xen/interface/xen.h      |    1 +
 4 files changed, 404 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 1d3e763..d12d14d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
+obj-$(CONFIG_XEN_DOM0)			+=3D pcpu.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+=3D xen-acpi-processor.o
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..9295def
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,393 @@
+/*************************************************************************=
*****
+ * pcpu.c
+ * Management physical cpu in dom0, get pcpu info and provide sys interfac=
e
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/cpu.h>
+#include <linux/stat.h>
+#include <xen/xen.h>
+#include <xen/xenbus.h>
+#include <xen/events.h>
+#include <xen/interface/platform.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct device dev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static struct bus_type xen_pcpu_subsys =3D {
+	.name =3D "xen_cpu",
+	.dev_name =3D "xen_cpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+#define XEN_PCPU "xen_cpu: "
+
+struct xen_pcpus {
+	struct list_head list;
+};
+static struct xen_pcpus xen_pcpus;
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);
+
+static ssize_t show_apicid(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static DEVICE_ATTR(apic_id, S_IRUGO, show_apicid, NULL);
+static DEVICE_ATTR(acpi_id, S_IRUGO, show_acpiid, NULL);
+
+static bool xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+static void pcpu_online_status(struct xenpf_pcpuinfo *info,
+			       struct pcpu *pcpu)
+{
+	if (xen_pcpu_online(info->flags) &&
+	   !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
+	} else if (!xen_pcpu_online(info->flags) &&
+		    xen_pcpu_online(pcpu->flags)) {
+		/* The pcpu is offlined */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
+	}
+}
+
+static struct pcpu *get_pcpu(uint32_t xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static void pcpu_sys_remove(struct pcpu *pcpu)
+{
+	struct device *dev;
+
+	if (!pcpu)
+		return;
+
+	dev =3D &pcpu->dev;
+	if (dev->id)
+		device_remove_file(dev, &dev_attr_online);
+	device_remove_file(dev, &dev_attr_acpi_id);
+	device_remove_file(dev, &dev_attr_apic_id);
+	device_unregister(dev);
+}
+
+static void free_pcpu(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return;
+
+	pcpu_sys_remove(pcpu);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+}
+
+static int pcpu_sys_create(struct pcpu *pcpu)
+{
+	struct device *dev;
+	int err =3D -EINVAL;
+
+	if (!pcpu)
+		return err;
+
+	dev =3D &pcpu->dev;
+	dev->bus =3D &xen_pcpu_subsys;
+	dev->id =3D pcpu->xen_id;
+
+	err =3D device_register(dev);
+	if (err)
+		goto err1;
+
+	err =3D device_create_file(dev, &dev_attr_apic_id);
+	if (err)
+		goto err2;
+	err =3D device_create_file(dev, &dev_attr_acpi_id);
+	if (err)
+		goto err3;
+	/* Not open pcpu0 online access to user */
+	if (dev->id) {
+		err =3D device_create_file(dev, &dev_attr_online);
+		if (err)
+			goto err4;
+	}
+
+	return 0;
+
+err4:
+	device_remove_file(dev, &dev_attr_acpi_id);
+err3:
+	device_remove_file(dev, &dev_attr_apic_id);
+err2:
+	device_unregister(dev);
+err1:
+	return err;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+	int err;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return ERR_PTR(-ENODEV);
+
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	err =3D pcpu_sys_create(pcpu);
+	if (err) {
+		pr_warning(XEN_PCPU "Failed to register pcpu%d\n",
+			   info->xen_cpuid);
+		kfree(pcpu);
+		return ERR_PTR(-ENOENT);
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	return pcpu;
+}
+
+/*
+ * Caller should hold the pcpu lock
+ */
+static int _sync_pcpu(uint32_t cpu_num, uint32_t *ptr_max_cpu_num)
+{
+	int ret;
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	struct xen_platform_op op =3D {
+		.cmd                   =3D XENPF_get_cpuinfo,
+		.interface_version     =3D XENPF_INTERFACE_VERSION,
+		.u.pcpu_info.xen_cpuid =3D cpu_num,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	info =3D &op.u.pcpu_info;
+	if (ptr_max_cpu_num)
+		*ptr_max_cpu_num =3D info->max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		if (pcpu)
+			free_pcpu(pcpu);
+		return 0;
+	}
+
+	if (!pcpu) {
+		pcpu =3D init_pcpu(info);
+		if (IS_ERR_OR_NULL(pcpu))
+			return -ENODEV;
+	} else
+		pcpu_online_status(info, pcpu);
+
+	return 0;
+}
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	uint32_t cpu_num =3D 0, max_cpu_num =3D 0;
+	int err =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while (!err && (cpu_num <=3D max_cpu_num)) {
+		err =3D _sync_pcpu(cpu_num, &max_cpu_num);
+		cpu_num++;
+	}
+
+	if (err) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			free_pcpu(pcpu);
+		}
+	}
+
+	put_pcpu_lock();
+
+	return err;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	xen_sync_pcpus();
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int ret;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	ret =3D subsys_system_register(&xen_pcpu_subsys, NULL);
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
+		return ret;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+
+	ret =3D xen_sync_pcpus();
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
+		return ret;
+	}
+
+	ret =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
+				      xen_pcpu_interrupt, 0,
+				      "pcpu", NULL);
+	if (ret < 0) {
+		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");
+		return ret;
+	}
+
+	return 0;
+}
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 486653f..2c56d4f 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -298,7 +298,7 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
-#define XENPF_get_cpuinfo 55
+#define XENPF_get_cpuinfo	55
 struct xenpf_pcpuinfo {
 	/* IN */
 	uint32_t xen_cpuid;
@@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
=20
+#define XENPF_cpu_online	56
+#define XENPF_cpu_offline	57
+struct xenpf_cpu_ol {
+	uint32_t cpuid;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -330,6 +337,7 @@ struct xen_platform_op {
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..0801468 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0003-Xen-physical-cpus-interface.patch"
Content-Description: 0003-Xen-physical-cpus-interface.patch
Content-Disposition: attachment;
	filename="0003-Xen-physical-cpus-interface.patch"; size=12339;
	creation-date="Thu, 19 Apr 2012 13:21:53 GMT";
	modification-date="Thu, 19 Apr 2012 21:16:56 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhZmRkMzBhNzc2OWU3MDZlOWJlNjRmODBkNjQxMzZlMmUyNjdlY2I5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyMCBBcHIgMjAxMiAwNToxMTo1OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMy8z
XSBYZW4gcGh5c2ljYWwgY3B1cyBpbnRlcmZhY2UKCk1hbmFnZSBwaHlzaWNhbCBjcHVzIGluIGRv
bTAsIGdldCBwaHlzaWNhbCBjcHVzIGluZm8gYW5kIHByb3ZpZGUgc3lzIGludGVyZmFjZS4KClNp
Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+Ci0tLQogZHJp
dmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgfCAgICAxICsKIGRyaXZlcnMveGVuL3BjcHUu
YyAgICAgICAgICAgICAgIHwgIDM5MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggfCAgIDEwICstCiBpbmNsdWRl
L3hlbi9pbnRlcmZhY2UveGVuLmggICAgICB8ICAgIDEgKwogNCBmaWxlcyBjaGFuZ2VkLCA0MDQg
aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJz
L3hlbi9wY3B1LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9NYWtlZmlsZSBiL2RyaXZlcnMv
eGVuL01ha2VmaWxlCmluZGV4IDFkM2U3NjMuLmQxMmQxNGQgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMv
eGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxlCkBAIC0xOSw2ICsxOSw3IEBA
IG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNpLm8KIG9iai0kKENPTkZJ
R19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJCSs9IHN3
aW90bGIteGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubworb2JqLSQoQ09O
RklHX1hFTl9ET00wKQkJCSs9IHBjcHUubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO
RCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05GSUdfWEVOX1BSSVZDTUQpCQkrPSB4ZW4tcHJp
dmNtZC5vCiBvYmotJChDT05GSUdfWEVOX0FDUElfUFJPQ0VTU09SKQkrPSB4ZW4tYWNwaS1wcm9j
ZXNzb3IubwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vcGNwdS5jIGIvZHJpdmVycy94ZW4vcGNw
dS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjkyOTVkZWYKLS0tIC9kZXYv
bnVsbAorKysgYi9kcml2ZXJzL3hlbi9wY3B1LmMKQEAgLTAsMCArMSwzOTMgQEAKKy8qKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioKKyAqIHBjcHUuYworICogTWFuYWdlbWVudCBwaHlzaWNhbCBjcHUgaW4g
ZG9tMCwgZ2V0IHBjcHUgaW5mbyBhbmQgcHJvdmlkZSBzeXMgaW50ZXJmYWNlCisgKgorICogQ29w
eXJpZ2h0IChjKSAyMDEyIEludGVsIENvcnBvcmF0aW9uCisgKiBBdXRob3I6IExpdSwgSmluc29u
ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgorICogQXV0aG9yOiBKaWFuZywgWXVuaG9uZyA8eXVu
aG9uZy5qaWFuZ0BpbnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICogbW9kaWZ5IGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyCisgKiBh
cyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgb3IsIHdoZW4gZGlz
dHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgga2VybmVsIG9yIGluY29ycG9y
YXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywgc3ViamVjdCB0byB0aGUgZm9s
bG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJl
ZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBz
b3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRoZSBTb2Z0d2FyZSB3aXRo
b3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRhdGlvbiB0aGUgcmln
aHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1Ymxpc2gsIGRpc3RyaWJ1dGUs
IHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUsCisgKiBhbmQg
dG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUgaXMgZnVybmlzaGVkIHRvIGRv
IHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6CisgKgorICogVGhl
IGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ugc2hhbGwg
YmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3RhbnRpYWwgcG9ydGlvbnMgb2Yg
dGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiLCBX
SVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9SCisgKiBJTVBMSUVELCBJTkNM
VURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU
WSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFORCBOT05JTkZSSU5HRU1F
TlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBPUiBDT1BZUklHSFQgSE9MREVS
UyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBPVEhFUgorICogTElBQklMSVRZ
LCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9SVCBPUiBPVEhFUldJU0UsIEFS
SVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFNPRlRXQVJF
IE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRIRSBTT0ZUV0FSRS4KKyAqLwor
CisjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2su
aD4KKyNpbmNsdWRlIDxsaW51eC9jcHUuaD4KKyNpbmNsdWRlIDxsaW51eC9zdGF0Lmg+CisjaW5j
bHVkZSA8eGVuL3hlbi5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
ZXZlbnRzLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUg
PGFzbS94ZW4vaHlwZXJ2aXNvci5oPgorI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisK
K3N0cnVjdCBwY3B1IHsKKwlzdHJ1Y3QgbGlzdF9oZWFkIHBjcHVfbGlzdDsKKwlzdHJ1Y3QgZGV2
aWNlIGRldjsKKwl1aW50MzJfdCB4ZW5faWQ7CisJdWludDMyX3QgYXBpY19pZDsKKwl1aW50MzJf
dCBhY3BpX2lkOworCXVpbnQzMl90IGZsYWdzOworfTsKKworc3RhdGljIHN0cnVjdCBidXNfdHlw
ZSB4ZW5fcGNwdV9zdWJzeXMgPSB7CisJLm5hbWUgPSAieGVuX2NwdSIsCisJLmRldl9uYW1lID0g
Inhlbl9jcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9sb2NrKTsKKyNk
ZWZpbmUgZ2V0X3BjcHVfbG9jaygpIG11dGV4X2xvY2soJnhlbl9wY3B1X2xvY2spOworI2RlZmlu
ZSBwdXRfcGNwdV9sb2NrKCkgbXV0ZXhfdW5sb2NrKCZ4ZW5fcGNwdV9sb2NrKTsKKworI2RlZmlu
ZSBYRU5fUENQVSAieGVuX2NwdTogIgorCitzdHJ1Y3QgeGVuX3BjcHVzIHsKKwlzdHJ1Y3QgbGlz
dF9oZWFkIGxpc3Q7Cit9Oworc3RhdGljIHN0cnVjdCB4ZW5fcGNwdXMgeGVuX3BjcHVzOworCitz
dGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCByZXQ7CisJ
c3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZAkJCT0gWEVOUEZfY3B1X29mZmxp
bmUsCisJCS5pbnRlcmZhY2VfdmVyc2lvbgk9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCQku
dS5jcHVfb2wuY3B1aWQJCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7
CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vbmxpbmUsCisJCS5pbnRlcmZhY2VfdmVyc2lvbgk9IFhF
TlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCQkudS5jcHVfb2wuY3B1aWQJCT0geGVuX2lkLAorCX07
CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitz
dGF0aWMgc3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3QgZGV2aWNlICpkZXYsCisJCQkgICBzdHJ1
Y3QgZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwKKwkJCSAgIGNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3Qg
cGNwdSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIGRldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgISEoY3B1LT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX09O
TElORSkpOworfQorCitzdGF0aWMgc3NpemVfdCBfX3JlZiBzdG9yZV9vbmxpbmUoc3RydWN0IGRl
dmljZSAqZGV2LAorCQkJCSAgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsCisJCQkJICBj
b25zdCBjaGFyICpidWYsIHNpemVfdCBjb3VudCkKK3sKKwlzdHJ1Y3QgcGNwdSAqY3B1ID0gY29u
dGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIGRldik7CisJc3NpemVfdCByZXQ7CisKKwlzd2l0
Y2ggKGJ1ZlswXSkgeworCWNhc2UgJzAnOgorCQlyZXQgPSB4ZW5fcGNwdV9kb3duKGNwdS0+eGVu
X2lkKTsKKwkJYnJlYWs7CisJY2FzZSAnMSc6CisJCXJldCA9IHhlbl9wY3B1X3VwKGNwdS0+eGVu
X2lkKTsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcmV0ID0gLUVJTlZBTDsKKwl9CisKKwlpZiAo
cmV0ID49IDApCisJCXJldCA9IGNvdW50OworCXJldHVybiByZXQ7Cit9CitzdGF0aWMgREVWSUNF
X0FUVFIob25saW5lLCBTX0lSVUdPIHwgU19JV1VTUiwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGlu
ZSk7CisKK3N0YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBkZXZpY2UgKmRldiwKKwkJ
CSAgIHN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLAorCQkJICAgY2hhciAqYnVmKQorewor
CXN0cnVjdCBwY3B1ICpjcHUgPSBjb250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgZGV2KTsK
KworCXJldHVybiBzcHJpbnRmKGJ1ZiwgIiV1XG4iLCBjcHUtPmFwaWNfaWQpOworfQorCitzdGF0
aWMgc3NpemVfdCBzaG93X2FjcGlpZChzdHJ1Y3QgZGV2aWNlICpkZXYsCisJCQkgICBzdHJ1Y3Qg
ZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwKKwkJCSAgIGNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIGRldik7CisKKwlyZXR1cm4g
c3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hY3BpX2lkKTsKK30KK3N0YXRpYyBERVZJQ0VfQVRU
UihhcGljX2lkLCBTX0lSVUdPLCBzaG93X2FwaWNpZCwgTlVMTCk7CitzdGF0aWMgREVWSUNFX0FU
VFIoYWNwaV9pZCwgU19JUlVHTywgc2hvd19hY3BpaWQsIE5VTEwpOworCitzdGF0aWMgYm9vbCB4
ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7CisJcmV0dXJuICEhKGZsYWdzICYgWEVO
X1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworc3RhdGljIHZvaWQgcGNwdV9vbmxpbmVfc3RhdHVz
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICAgICBzdHJ1Y3QgcGNwdSAqcGNw
dSkKK3sKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJgorCSAgICF4ZW5fcGNw
dV9vbmxpbmUocGNwdS0+ZmxhZ3MpKSB7CisJCS8qIHRoZSBwY3B1IGlzIG9ubGluZWQgKi8KKwkJ
cGNwdS0+ZmxhZ3MgfD0gWEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgm
cGNwdS0+ZGV2LmtvYmosIEtPQkpfT05MSU5FKTsKKwl9IGVsc2UgaWYgKCF4ZW5fcGNwdV9vbmxp
bmUoaW5mby0+ZmxhZ3MpICYmCisJCSAgICB4ZW5fcGNwdV9vbmxpbmUocGNwdS0+ZmxhZ3MpKSB7
CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkICovCisJCXBjcHUtPmZsYWdzICY9IH5YRU5fUENQ
VV9GTEFHU19PTkxJTkU7CisJCWtvYmplY3RfdWV2ZW50KCZwY3B1LT5kZXYua29iaiwgS09CSl9P
RkZMSU5FKTsKKwl9Cit9CisKK3N0YXRpYyBzdHJ1Y3QgcGNwdSAqZ2V0X3BjcHUodWludDMyX3Qg
eGVuX2lkKQoreworCXN0cnVjdCBwY3B1ICpwY3B1ID0gTlVMTDsKKworCWxpc3RfZm9yX2VhY2hf
ZW50cnkocGNwdSwgJnhlbl9wY3B1cy5saXN0LCBwY3B1X2xpc3QpIHsKKwkJaWYgKHBjcHUtPnhl
bl9pZCA9PSB4ZW5faWQpCisJCQlyZXR1cm4gcGNwdTsKKwl9CisJcmV0dXJuIE5VTEw7Cit9CisK
K3N0YXRpYyB2b2lkIHBjcHVfc3lzX3JlbW92ZShzdHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlzdHJ1
Y3QgZGV2aWNlICpkZXY7CisKKwlpZiAoIXBjcHUpCisJCXJldHVybjsKKworCWRldiA9ICZwY3B1
LT5kZXY7CisJaWYgKGRldi0+aWQpCisJCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0
cl9vbmxpbmUpOworCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0cl9hY3BpX2lkKTsK
KwlkZXZpY2VfcmVtb3ZlX2ZpbGUoZGV2LCAmZGV2X2F0dHJfYXBpY19pZCk7CisJZGV2aWNlX3Vu
cmVnaXN0ZXIoZGV2KTsKK30KKworc3RhdGljIHZvaWQgZnJlZV9wY3B1KHN0cnVjdCBwY3B1ICpw
Y3B1KQoreworCWlmICghcGNwdSkKKwkJcmV0dXJuOworCisJcGNwdV9zeXNfcmVtb3ZlKHBjcHUp
OworCWxpc3RfZGVsKCZwY3B1LT5wY3B1X2xpc3QpOworCWtmcmVlKHBjcHUpOworfQorCitzdGF0
aWMgaW50IHBjcHVfc3lzX2NyZWF0ZShzdHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlzdHJ1Y3QgZGV2
aWNlICpkZXY7CisJaW50IGVyciA9IC1FSU5WQUw7CisKKwlpZiAoIXBjcHUpCisJCXJldHVybiBl
cnI7CisKKwlkZXYgPSAmcGNwdS0+ZGV2OworCWRldi0+YnVzID0gJnhlbl9wY3B1X3N1YnN5czsK
KwlkZXYtPmlkID0gcGNwdS0+eGVuX2lkOworCisJZXJyID0gZGV2aWNlX3JlZ2lzdGVyKGRldik7
CisJaWYgKGVycikKKwkJZ290byBlcnIxOworCisJZXJyID0gZGV2aWNlX2NyZWF0ZV9maWxlKGRl
diwgJmRldl9hdHRyX2FwaWNfaWQpOworCWlmIChlcnIpCisJCWdvdG8gZXJyMjsKKwllcnIgPSBk
ZXZpY2VfY3JlYXRlX2ZpbGUoZGV2LCAmZGV2X2F0dHJfYWNwaV9pZCk7CisJaWYgKGVycikKKwkJ
Z290byBlcnIzOworCS8qIE5vdCBvcGVuIHBjcHUwIG9ubGluZSBhY2Nlc3MgdG8gdXNlciAqLwor
CWlmIChkZXYtPmlkKSB7CisJCWVyciA9IGRldmljZV9jcmVhdGVfZmlsZShkZXYsICZkZXZfYXR0
cl9vbmxpbmUpOworCQlpZiAoZXJyKQorCQkJZ290byBlcnI0OworCX0KKworCXJldHVybiAwOwor
CitlcnI0OgorCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0cl9hY3BpX2lkKTsKK2Vy
cjM6CisJZGV2aWNlX3JlbW92ZV9maWxlKGRldiwgJmRldl9hdHRyX2FwaWNfaWQpOworZXJyMjoK
KwlkZXZpY2VfdW5yZWdpc3RlcihkZXYpOworZXJyMToKKwlyZXR1cm4gZXJyOworfQorCitzdGF0
aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShzdHJ1Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCit7
CisJc3RydWN0IHBjcHUgKnBjcHU7CisJaW50IGVycjsKKworCWlmIChpbmZvLT5mbGFncyAmIFhF
Tl9QQ1BVX0ZMQUdTX0lOVkFMSUQpCisJCXJldHVybiBFUlJfUFRSKC1FTk9ERVYpOworCisJcGNw
dSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwgR0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1
KQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKworCUlOSVRfTElTVF9IRUFEKCZwY3B1LT5w
Y3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsKKwlwY3B1LT5hcGlj
X2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+YWNwaV9pZDsKKwlw
Y3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJZXJyID0gcGNwdV9zeXNfY3JlYXRlKHBjcHUp
OworCWlmIChlcnIpIHsKKwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVkIHRvIHJlZ2lzdGVy
IHBjcHUlZFxuIiwKKwkJCSAgIGluZm8tPnhlbl9jcHVpZCk7CisJCWtmcmVlKHBjcHUpOworCQly
ZXR1cm4gRVJSX1BUUigtRU5PRU5UKTsKKwl9CisKKwlsaXN0X2FkZF90YWlsKCZwY3B1LT5wY3B1
X2xpc3QsICZ4ZW5fcGNwdXMubGlzdCk7CisJcmV0dXJuIHBjcHU7Cit9CisKKy8qCisgKiBDYWxs
ZXIgc2hvdWxkIGhvbGQgdGhlIHBjcHUgbG9jaworICovCitzdGF0aWMgaW50IF9zeW5jX3BjcHUo
dWludDMyX3QgY3B1X251bSwgdWludDMyX3QgKnB0cl9tYXhfY3B1X251bSkKK3sKKwlpbnQgcmV0
OworCXN0cnVjdCBwY3B1ICpwY3B1ID0gTlVMTDsKKwlzdHJ1Y3QgeGVucGZfcGNwdWluZm8gKmlu
Zm87CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgICAg
ICAgICA9IFhFTlBGX2dldF9jcHVpbmZvLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24gICAgID0gWEVO
UEZfSU5URVJGQUNFX1ZFUlNJT04sCisJCS51LnBjcHVfaW5mby54ZW5fY3B1aWQgPSBjcHVfbnVt
LAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0KQorCQly
ZXR1cm4gcmV0OworCisJaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKwlpZiAocHRyX21heF9jcHVf
bnVtKQorCQkqcHRyX21heF9jcHVfbnVtID0gaW5mby0+bWF4X3ByZXNlbnQ7CisKKwlwY3B1ID0g
Z2V0X3BjcHUoY3B1X251bSk7CisKKwlpZiAoaW5mby0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19J
TlZBTElEKSB7CisJCS8qIFRoZSBwY3B1IGhhcyBiZWVuIHJlbW92ZWQgKi8KKwkJaWYgKHBjcHUp
CisJCQlmcmVlX3BjcHUocGNwdSk7CisJCXJldHVybiAwOworCX0KKworCWlmICghcGNwdSkgewor
CQlwY3B1ID0gaW5pdF9wY3B1KGluZm8pOworCQlpZiAoSVNfRVJSX09SX05VTEwocGNwdSkpCisJ
CQlyZXR1cm4gLUVOT0RFVjsKKwl9IGVsc2UKKwkJcGNwdV9vbmxpbmVfc3RhdHVzKGluZm8sIHBj
cHUpOworCisJcmV0dXJuIDA7Cit9CisKKy8qCisgKiBTeW5jIGRvbTAncyBwY3B1IGluZm9ybWF0
aW9uIHdpdGggeGVuIGh5cGVydmlzb3IncworICovCitzdGF0aWMgaW50IHhlbl9zeW5jX3BjcHVz
KHZvaWQpCit7CisJLyoKKwkgKiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQgMCBpbiB4ZW4K
KwkgKi8KKwl1aW50MzJfdCBjcHVfbnVtID0gMCwgbWF4X2NwdV9udW0gPSAwOworCWludCBlcnIg
PSAwOworCXN0cnVjdCBsaXN0X2hlYWQgKmVsZW0sICp0bXA7CisJc3RydWN0IHBjcHUgKnBjcHU7
CisKKwlnZXRfcGNwdV9sb2NrKCk7CisKKwl3aGlsZSAoIWVyciAmJiAoY3B1X251bSA8PSBtYXhf
Y3B1X251bSkpIHsKKwkJZXJyID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2NwdV9udW0pOwor
CQljcHVfbnVtKys7CisJfQorCisJaWYgKGVycikgeworCQlsaXN0X2Zvcl9lYWNoX3NhZmUoZWxl
bSwgdG1wLCAmeGVuX3BjcHVzLmxpc3QpIHsKKwkJCXBjcHUgPSBsaXN0X2VudHJ5KGVsZW0sIHN0
cnVjdCBwY3B1LCBwY3B1X2xpc3QpOworCQkJZnJlZV9wY3B1KHBjcHUpOworCQl9CisJfQorCisJ
cHV0X3BjcHVfbG9jaygpOworCisJcmV0dXJuIGVycjsKK30KKworc3RhdGljIHZvaWQgeGVuX3Bj
cHVfZHBjKHN0cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKK3sKKwl4ZW5fc3luY19wY3B1cygpOwor
fQorc3RhdGljIERFQ0xBUkVfV09SSyh4ZW5fcGNwdV93b3JrLCB4ZW5fcGNwdV9kcGMpOworCitz
dGF0aWMgaXJxcmV0dXJuX3QgeGVuX3BjcHVfaW50ZXJydXB0KGludCBpcnEsIHZvaWQgKmRldl9p
ZCkKK3sKKwlzY2hlZHVsZV93b3JrKCZ4ZW5fcGNwdV93b3JrKTsKKwlyZXR1cm4gSVJRX0hBTkRM
RUQ7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1X2luaXQodm9pZCkKK3sKKwlpbnQg
cmV0OworCisJaWYgKCF4ZW5faW5pdGlhbF9kb21haW4oKSkKKwkJcmV0dXJuIC1FTk9ERVY7CisK
KwlyZXQgPSBzdWJzeXNfc3lzdGVtX3JlZ2lzdGVyKCZ4ZW5fcGNwdV9zdWJzeXMsIE5VTEwpOwor
CWlmIChyZXQpIHsKKwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVkIHRvIHJlZ2lzdGVyIHBj
cHUgc3Vic3lzXG4iKTsKKwkJcmV0dXJuIHJldDsKKwl9CisKKwlJTklUX0xJU1RfSEVBRCgmeGVu
X3BjcHVzLmxpc3QpOworCisJcmV0ID0geGVuX3N5bmNfcGNwdXMoKTsKKwlpZiAocmV0KSB7CisJ
CXByX3dhcm5pbmcoWEVOX1BDUFUgIkZhaWxlZCB0byBzeW5jIHBjcHUgaW5mb1xuIik7CisJCXJl
dHVybiByZXQ7CisJfQorCisJcmV0ID0gYmluZF92aXJxX3RvX2lycWhhbmRsZXIoVklSUV9QQ1BV
X1NUQVRFLCAwLAorCQkJCSAgICAgIHhlbl9wY3B1X2ludGVycnVwdCwgMCwKKwkJCQkgICAgICAi
cGNwdSIsIE5VTEwpOworCWlmIChyZXQgPCAwKSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZh
aWxlZCB0byBiaW5kIHBjcHUgdmlycVxuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0dXJu
IDA7Cit9CithcmNoX2luaXRjYWxsKHhlbl9wY3B1X2luaXQpOwpkaWZmIC0tZ2l0IGEvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaAppbmRleCA0ODY2NTNmLi4yYzU2ZDRmIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApA
QCAtMjk4LDcgKzI5OCw3IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9
OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8p
OwogCi0jZGVmaW5lIFhFTlBGX2dldF9jcHVpbmZvIDU1CisjZGVmaW5lIFhFTlBGX2dldF9jcHVp
bmZvCTU1CiBzdHJ1Y3QgeGVucGZfcGNwdWluZm8gewogCS8qIElOICovCiAJdWludDMyX3QgeGVu
X2NwdWlkOwpAQCAtMzE0LDYgKzMxNCwxMyBAQCBzdHJ1Y3QgeGVucGZfcGNwdWluZm8gewogfTsK
IERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvKTsKIAorI2RlZmluZSBY
RU5QRl9jcHVfb25saW5lCTU2CisjZGVmaW5lIFhFTlBGX2NwdV9vZmZsaW5lCTU3CitzdHJ1Y3Qg
eGVucGZfY3B1X29sIHsKKwl1aW50MzJfdCBjcHVpZDsKK307CitERUZJTkVfR1VFU1RfSEFORExF
X1NUUlVDVCh4ZW5wZl9jcHVfb2wpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50
MzJfdCBjbWQ7CiAJdWludDMyX3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFD
RV9WRVJTSU9OICovCkBAIC0zMzAsNiArMzM3LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7
CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGltZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0
IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZvIHNldF9wbWluZm87CiAJCXN0cnVjdCB4ZW5wZl9w
Y3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAg
ICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsK
IAl9IHU7CiB9OwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IGE4OTA4MDQuLjA4MDE0NjggMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335154F3ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Apr 19 14:16:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 14:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKs8y-0005sG-HJ; Thu, 19 Apr 2012 14:15:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKs8x-0005sB-LP
	for Xen-devel@lists.xensource.com; Thu, 19 Apr 2012 14:15:31 +0000
Received: from [193.109.254.147:44956] by server-4.bemta-14.messagelabs.com id
	1B/F0-11570-30E109F4; Thu, 19 Apr 2012 14:15:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334844929!165690!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6152 invoked from network); 19 Apr 2012 14:15:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 14:15:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKs8t-00078X-Er; Thu, 19 Apr 2012 14:15:27 +0000
Date: Thu, 19 Apr 2012 15:15:27 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120419141527.GB23663@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120413182952.504e2775@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 18:29 -0700 on 13 Apr (1334341792), Mukesh Rathor wrote:
> I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
> can please look at it and give any comments. I tested it and seems to work
> ok.

I agree with what Ian's already said about this.  In particular: 

 - This should use the existing XENMEM_add_to_physmap interface rather
   than having a new operation.
 - AFAICT you're using set_mmio_p2m_entry and adding a new unmap
   operation just to avoid having the m2p updated.  Since you can't rely
   on the unmap always happening through the new call (and you don't
   enforce it anywhere), it would be better to add a new p2m_type
   just for non-grant foreign mappings.  Then you can gate the m2p
   updates in the existing code on the map being normal RAM, as is
   already done for p2m_is_grant().

Apart from that: 

> struct xen_add_to_foreign_pmap_batch {
>     domid_t foreign_domid;         /* IN: gmfn belongs to this domain */
>     int count;                     /* IN/OUT: number of contigous frames */

Please only add explicitly-sized fields to the public interface.  
(I understand that there's currently no call for a compat VM to make
this call, but even so).

>     unsigned long     gpfn;        /* IN: pfn in the current domain */
>     unsigned long     gmfn;        /* IN: from foreign domain */
>     int fpmap_flags;               /* future use */
> };


> /* add frames from foreign domain to current domain physmap. Similar to 
>  * XENMEM_add_to_physmap but the mfn frame is foreign, is being mapped into 
>  * current privileged domain, and is not removed from foreign domain. 
>  * Usage: libxl when creating guest in hybrid dom0 doing privcmd_ioctl_mmap
>  * Return: 0 success
>  */
> static long _add_foreign_to_pmap_batch(XEN_GUEST_HANDLE(void) arg)
> {
>     struct xen_add_to_foreign_pmap_batch pmapb;
>     unsigned long rc=0, i, prev_mfn, mfn = 0;
>     struct domain *fdom, *currd = current->domain;
>     p2m_type_t p2mt;
> 
>     if ( copy_from_guest(&pmapb, arg, 1) )
>         return -EFAULT;
> 
>     fdom = get_pg_owner(pmapb.foreign_domid);
> 
>     if ( fdom== NULL ) {
>         put_pg_owner(fdom);

Best not, if it's NULL. :)

>         return -EPERM;
>     }
> 
>     for (i=0; (rc == 0) && (i < pmapb.count); i++) {

This loop could do nearly 2^31 iterations; it needs to have a preemption
check to stop it locking up the hypervisor.  (If you switch to using
XENMEM_add_to_physmap, you'll get this for free.)

Also, I understand this is early code, but it will eventually have to
follow the coding style about whitespace.  There are hard tabs in a few
places below as well.  Can you train your text editor not to do that?

>         unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
>         mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));

This will need to use the new get_gfn()/put_gfn() interfaces.

> 	if ( !p2m_is_valid(p2mt) )
>             rc = -EINVAL;
> 
>         if ( !rc && !get_page_from_pagenr(mfn, fdom) )
>             rc = -EPERM;
> 
>         if (!rc) 
>             put_page(mfn_to_page(mfn));
>         else 
>             break;

That's a particularly confusing way of putting it.  Also, you'll need to
keep a reference to the foreign page until this mapping goes away;
otherwise the foreign domain could die and its memory be reused while
you still have this mapping.  You should take a PGT_writeable_page
typecount, too, if the foreign domain isn't in paging_mode_external
(like how get_page_from_l1e does for PV mappings).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 14:16:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 14:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKs8y-0005sG-HJ; Thu, 19 Apr 2012 14:15:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKs8x-0005sB-LP
	for Xen-devel@lists.xensource.com; Thu, 19 Apr 2012 14:15:31 +0000
Received: from [193.109.254.147:44956] by server-4.bemta-14.messagelabs.com id
	1B/F0-11570-30E109F4; Thu, 19 Apr 2012 14:15:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1334844929!165690!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6152 invoked from network); 19 Apr 2012 14:15:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 14:15:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKs8t-00078X-Er; Thu, 19 Apr 2012 14:15:27 +0000
Date: Thu, 19 Apr 2012 15:15:27 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120419141527.GB23663@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120413182952.504e2775@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 18:29 -0700 on 13 Apr (1334341792), Mukesh Rathor wrote:
> I wrote up some code to map/unmap pfn to mfn for hybrid. I wonder if anyone
> can please look at it and give any comments. I tested it and seems to work
> ok.

I agree with what Ian's already said about this.  In particular: 

 - This should use the existing XENMEM_add_to_physmap interface rather
   than having a new operation.
 - AFAICT you're using set_mmio_p2m_entry and adding a new unmap
   operation just to avoid having the m2p updated.  Since you can't rely
   on the unmap always happening through the new call (and you don't
   enforce it anywhere), it would be better to add a new p2m_type
   just for non-grant foreign mappings.  Then you can gate the m2p
   updates in the existing code on the map being normal RAM, as is
   already done for p2m_is_grant().

Apart from that: 

> struct xen_add_to_foreign_pmap_batch {
>     domid_t foreign_domid;         /* IN: gmfn belongs to this domain */
>     int count;                     /* IN/OUT: number of contigous frames */

Please only add explicitly-sized fields to the public interface.  
(I understand that there's currently no call for a compat VM to make
this call, but even so).

>     unsigned long     gpfn;        /* IN: pfn in the current domain */
>     unsigned long     gmfn;        /* IN: from foreign domain */
>     int fpmap_flags;               /* future use */
> };


> /* add frames from foreign domain to current domain physmap. Similar to 
>  * XENMEM_add_to_physmap but the mfn frame is foreign, is being mapped into 
>  * current privileged domain, and is not removed from foreign domain. 
>  * Usage: libxl when creating guest in hybrid dom0 doing privcmd_ioctl_mmap
>  * Return: 0 success
>  */
> static long _add_foreign_to_pmap_batch(XEN_GUEST_HANDLE(void) arg)
> {
>     struct xen_add_to_foreign_pmap_batch pmapb;
>     unsigned long rc=0, i, prev_mfn, mfn = 0;
>     struct domain *fdom, *currd = current->domain;
>     p2m_type_t p2mt;
> 
>     if ( copy_from_guest(&pmapb, arg, 1) )
>         return -EFAULT;
> 
>     fdom = get_pg_owner(pmapb.foreign_domid);
> 
>     if ( fdom== NULL ) {
>         put_pg_owner(fdom);

Best not, if it's NULL. :)

>         return -EPERM;
>     }
> 
>     for (i=0; (rc == 0) && (i < pmapb.count); i++) {

This loop could do nearly 2^31 iterations; it needs to have a preemption
check to stop it locking up the hypervisor.  (If you switch to using
XENMEM_add_to_physmap, you'll get this for free.)

Also, I understand this is early code, but it will eventually have to
follow the coding style about whitespace.  There are hard tabs in a few
places below as well.  Can you train your text editor not to do that?

>         unsigned long fgmfn = pmapb.gmfn+i, gpfn = pmapb.gpfn+i;
>         mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));

This will need to use the new get_gfn()/put_gfn() interfaces.

> 	if ( !p2m_is_valid(p2mt) )
>             rc = -EINVAL;
> 
>         if ( !rc && !get_page_from_pagenr(mfn, fdom) )
>             rc = -EPERM;
> 
>         if (!rc) 
>             put_page(mfn_to_page(mfn));
>         else 
>             break;

That's a particularly confusing way of putting it.  Also, you'll need to
keep a reference to the foreign page until this mapping goes away;
otherwise the foreign domain could die and its memory be reused while
you still have this mapping.  You should take a PGT_writeable_page
typecount, too, if the foreign domain isn't in paging_mode_external
(like how get_page_from_l1e does for PV mappings).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 14:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 14:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKsWo-0006HD-St; Thu, 19 Apr 2012 14:40:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKsWn-0006H8-Lb
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 14:40:09 +0000
Received: from [193.109.254.147:38874] by server-12.bemta-14.messagelabs.com
	id C8/82-05898-8C3209F4; Thu, 19 Apr 2012 14:40:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334846405!5389129!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc5MTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12266 invoked from network); 19 Apr 2012 14:40:06 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-13.tower-27.messagelabs.com with SMTP;
	19 Apr 2012 14:40:06 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id B11A730007B;
	Thu, 19 Apr 2012 07:40:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PnmnfdXDorQr+dPEBKiUg4hZAJ+3kRYVzumN/Rbp5/G2
	GcA60Xb87InyS5jtwEPzdFS4msnBLg7jqdncnKxs0IuyVHHE3hAMAoR5puYZLFV5
	yOSnvzFEIN2L19yijHaBCerz+kAnvalX/n+yzxcUzc1lIL1OFfTMDxG0ak91lkA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=X0NmeB6vd9aI2iW4sNHYizkz4Bo=; b=sKP6+qOv
	CpJ734iBbuAqq2U6bvwIKIhqlC+QwAs6jhx+MLiOtQ07Gjy1ytQUh5L2TpdEyJO6
	y6zWTOi5ZSOIqRchwGcBDvLqFaW3T+aKbwy+tWQew09Sw+kymazD9L6LHz1Yg8qQ
	vAjyyxES4qTAJz+49Kg2iI8KX9fkKneoqjo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id F03B2300074; 
	Thu, 19 Apr 2012 07:40:03 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Apr 2012 07:40:04 -0700
Message-ID: <ceeab60956682863a8d8c150d75cc073.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2710.1334825330.1399.xen-devel@lists.xen.org>
References: <mailman.2710.1334825330.1399.xen-devel@lists.xen.org>
Date: Thu, 19 Apr 2012 07:40:04 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: keir.xen@gmail.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-04-19 at 00:29 +0100, Mukesh Rathor wrote:
>> On Tue, 17 Apr 2012 10:05:28 +0100
>> Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>
>> > On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
>> > > On Mon, 16 Apr 2012 14:53:22 +0100
>> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >
>> > Sorry, I meant why a whole new subcall instead of a new
>> > XENMAPSPACE ;-)
>> >
>> > e.g. On ARM I did:
>> >
>> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> > index 86d02c8..b2adfbe 100644
>> > --- a/xen/include/public/memory.h
>> > +++ b/xen/include/public/memory.h
>> > @@ -212,11 +212,13 @@ struct xen_add_to_physmap {
>> >      uint16_t    size;
>> >
>> >      /* Source mapping space. */
>> > -#define XENMAPSPACE_shared_info 0 /* shared info page */
>> > -#define XENMAPSPACE_grant_table 1 /* grant table page */
>> > -#define XENMAPSPACE_gmfn        2 /* GMFN */
>> > -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
>> > -    unsigned int space;
>> > +#define XENMAPSPACE_shared_info  0 /* shared info page */
>> > +#define XENMAPSPACE_grant_table  1 /* grant table page */
>> > +#define XENMAPSPACE_gmfn         2 /* GMFN */
>> > +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
>> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
>> > +    uint16_t space;
>> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
>>
>>
>> Well, for several reasons, I didn't use it, mainly, it doesn't allow
>> for count. So requests have to come in one frame at a time.
>
> I've got it that way on ARM too at the moment but I was planning to make
> it behave like gmfn_range and use the size parameter to map multiple at
> a time (unless I've misunderstood what the gmfn_range variant does).
>
>>  Second, none of the common code can be used by my new request,
>
> I don't think that's an impediment to the API, XENMAPSPACE_gmfn_foreign
> is in pretty much the same position.
>
>>  because:
>>    - frame is not removed from foreign domain in my case
>>    - i don't want to update the m2p with new info.
>>
>> Anyways, I put it there for now. With ballooning change in dom0, I'm
>> now doing the hcall one frame at a time anyways. We can always enhance
>> in the future.
>>
>>         case XENMAPSPACE_gmfn_foreign:
>>         {
>>             rc = _add_foreign_to_pmap_batch(&xatp);
>>             rcu_unlock_domain(d);
>>             return rc;
>>         }
>>
>>
>> >> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void)
>> >> arg)
>>
>> >Can't XENMEM_remove_from_physmap be used here?
>>
>> Well, that calls guest_physmap_remove_page() which calls
>> p2m_remove_page which updates the M2P with INVALID_M2P_ENTRY. Whereas,
>> i just need to remove from the dom0 p2m and leave M2P as is (mfn to
>> domU gmfn). I could add a flag to the struct causing it to just call
>> set_p2m_entry() directly?
>
> Would it be useful to track the fact that a p2m entry is foreign
> somewhere? That would let you do the appropriate type of teardown etc
> without relying on the tools to get it right.
>
> Are there s/w bits available in the p2m entry itself on x86 or do we use
> them all already?

A few still available. We're at 14 types and EPT uses 4 bits.

NPT has even more room, unless it's sharing its p2m tables with iommu
tables -- in which case it can't really do fancy p2m typing. That would be
an unwelcome side-effect for a hybrid dom0 on amd, but I'm not aware of
how bad it would be.

The more general value here is to allow hvm backends arbitrary mapping
capabilities, correct? Right now all hvm backends/driver domains are
supposed to use grant table code (and there are p2m types for those).

A domain builder/checkpointing hvm domain would require equivalent
capabilities to those being discussed here, if I'm not mistaken.

So, a p2m_foreign_map would be the way to go.

My two cents
Andres


>
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 14:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 14:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKsWo-0006HD-St; Thu, 19 Apr 2012 14:40:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKsWn-0006H8-Lb
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 14:40:09 +0000
Received: from [193.109.254.147:38874] by server-12.bemta-14.messagelabs.com
	id C8/82-05898-8C3209F4; Thu, 19 Apr 2012 14:40:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334846405!5389129!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc5MTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12266 invoked from network); 19 Apr 2012 14:40:06 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-13.tower-27.messagelabs.com with SMTP;
	19 Apr 2012 14:40:06 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id B11A730007B;
	Thu, 19 Apr 2012 07:40:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PnmnfdXDorQr+dPEBKiUg4hZAJ+3kRYVzumN/Rbp5/G2
	GcA60Xb87InyS5jtwEPzdFS4msnBLg7jqdncnKxs0IuyVHHE3hAMAoR5puYZLFV5
	yOSnvzFEIN2L19yijHaBCerz+kAnvalX/n+yzxcUzc1lIL1OFfTMDxG0ak91lkA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=X0NmeB6vd9aI2iW4sNHYizkz4Bo=; b=sKP6+qOv
	CpJ734iBbuAqq2U6bvwIKIhqlC+QwAs6jhx+MLiOtQ07Gjy1ytQUh5L2TpdEyJO6
	y6zWTOi5ZSOIqRchwGcBDvLqFaW3T+aKbwy+tWQew09Sw+kymazD9L6LHz1Yg8qQ
	vAjyyxES4qTAJz+49Kg2iI8KX9fkKneoqjo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id F03B2300074; 
	Thu, 19 Apr 2012 07:40:03 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Apr 2012 07:40:04 -0700
Message-ID: <ceeab60956682863a8d8c150d75cc073.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2710.1334825330.1399.xen-devel@lists.xen.org>
References: <mailman.2710.1334825330.1399.xen-devel@lists.xen.org>
Date: Thu, 19 Apr 2012 07:40:04 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: keir.xen@gmail.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-04-19 at 00:29 +0100, Mukesh Rathor wrote:
>> On Tue, 17 Apr 2012 10:05:28 +0100
>> Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>
>> > On Tue, 2012-04-17 at 02:53 +0100, Mukesh Rathor wrote:
>> > > On Mon, 16 Apr 2012 14:53:22 +0100
>> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >
>> > Sorry, I meant why a whole new subcall instead of a new
>> > XENMAPSPACE ;-)
>> >
>> > e.g. On ARM I did:
>> >
>> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> > index 86d02c8..b2adfbe 100644
>> > --- a/xen/include/public/memory.h
>> > +++ b/xen/include/public/memory.h
>> > @@ -212,11 +212,13 @@ struct xen_add_to_physmap {
>> >      uint16_t    size;
>> >
>> >      /* Source mapping space. */
>> > -#define XENMAPSPACE_shared_info 0 /* shared info page */
>> > -#define XENMAPSPACE_grant_table 1 /* grant table page */
>> > -#define XENMAPSPACE_gmfn        2 /* GMFN */
>> > -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
>> > -    unsigned int space;
>> > +#define XENMAPSPACE_shared_info  0 /* shared info page */
>> > +#define XENMAPSPACE_grant_table  1 /* grant table page */
>> > +#define XENMAPSPACE_gmfn         2 /* GMFN */
>> > +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
>> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
>> > +    uint16_t space;
>> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
>>
>>
>> Well, for several reasons, I didn't use it, mainly, it doesn't allow
>> for count. So requests have to come in one frame at a time.
>
> I've got it that way on ARM too at the moment but I was planning to make
> it behave like gmfn_range and use the size parameter to map multiple at
> a time (unless I've misunderstood what the gmfn_range variant does).
>
>>  Second, none of the common code can be used by my new request,
>
> I don't think that's an impediment to the API, XENMAPSPACE_gmfn_foreign
> is in pretty much the same position.
>
>>  because:
>>    - frame is not removed from foreign domain in my case
>>    - i don't want to update the m2p with new info.
>>
>> Anyways, I put it there for now. With ballooning change in dom0, I'm
>> now doing the hcall one frame at a time anyways. We can always enhance
>> in the future.
>>
>>         case XENMAPSPACE_gmfn_foreign:
>>         {
>>             rc = _add_foreign_to_pmap_batch(&xatp);
>>             rcu_unlock_domain(d);
>>             return rc;
>>         }
>>
>>
>> >> static long noinline _rem_foreign_pmap_batch(XEN_GUEST_HANDLE(void)
>> >> arg)
>>
>> >Can't XENMEM_remove_from_physmap be used here?
>>
>> Well, that calls guest_physmap_remove_page() which calls
>> p2m_remove_page which updates the M2P with INVALID_M2P_ENTRY. Whereas,
>> i just need to remove from the dom0 p2m and leave M2P as is (mfn to
>> domU gmfn). I could add a flag to the struct causing it to just call
>> set_p2m_entry() directly?
>
> Would it be useful to track the fact that a p2m entry is foreign
> somewhere? That would let you do the appropriate type of teardown etc
> without relying on the tools to get it right.
>
> Are there s/w bits available in the p2m entry itself on x86 or do we use
> them all already?

A few still available. We're at 14 types and EPT uses 4 bits.

NPT has even more room, unless it's sharing its p2m tables with iommu
tables -- in which case it can't really do fancy p2m typing. That would be
an unwelcome side-effect for a hybrid dom0 on amd, but I'm not aware of
how bad it would be.

The more general value here is to allow hvm backends arbitrary mapping
capabilities, correct? Right now all hvm backends/driver domains are
supposed to use grant table code (and there are p2m types for those).

A domain builder/checkpointing hvm domain would require equivalent
capabilities to those being discussed here, if I'm not mistaken.

So, a p2m_foreign_map would be the way to go.

My two cents
Andres


>
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 14:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKshx-0006TQ-39; Thu, 19 Apr 2012 14:51:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKshv-0006TL-VC
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 14:51:40 +0000
Received: from [85.158.143.35:25320] by server-3.bemta-4.messagelabs.com id
	FA/01-05853-B76209F4; Thu, 19 Apr 2012 14:51:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334847098!10735917!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26922 invoked from network); 19 Apr 2012 14:51:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 14:51:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKshs-0007FC-ND; Thu, 19 Apr 2012 14:51:36 +0000
Date: Thu, 19 Apr 2012 15:51:36 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120419145136.GC23663@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
	<20120418161326.GQ7013@ocelot.phlegethon.org>
	<935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
	p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 09:25 -0700 on 18 Apr (1334741158), Andres Lagar-Cavilla wrote:
> > Nack, at least for now; we spent a fair amount of effort taking all this
> > emulation code out from under the shadow lock; serializing it under the
> > p2m lock would be unfortunate.  The other patches are less worrying,
> > since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
> > be avoided.
> >
> > The existing interlock between the shadow code and the p2m code prevents
> > any p2m modifications from happening when the shadow lock is held, so I
> > hope I can solve this by switching to unlocked lookups instead.  I'm
> > building a test kernel now to tell me exactly which lookps are to
> > blame.
> 
> FWIW, get_gfn_query for the target gfn of the PTE entry that is being
> checked in validate_gl?e entry, is the call that causes the panic this
> patch tries to fix.
> 
> As for the other two patches, sh_resync_l1 is the trigger (again,
> get_gfn_query on the gfn that is contained by the PTE being verified)

Thanks.  I've taken a sweep through mm/shadow, making the lookups into
unlocked ones wherever the paging_lock is already held.  With the
attached patch and your final patch to enable the locking, I can start
HVM guests without crashing Xen.  I haven't given it any more serious
testing yet.

Cheers,

Tim.
--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=shadow-vs-p2m

x86/mm/shadow: don't use locking p2m lookups with the paging lock held.

The existing interlock between shadow and p2m (where p2m table updates
are done under the paging lock) keeps us safe from the p2m changing
under our feet, and using the locking lookups is a violation of the
locking discipline (which says always to take the p2m lock first).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 6f89f15fd3c8 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c	Thu Apr 19 15:31:30 2012 +0100
+++ b/xen/arch/x86/mm/shadow/common.c	Thu Apr 19 15:48:30 2012 +0100
@@ -3676,7 +3676,7 @@ int shadow_track_dirty_vram(struct domai
 
         /* Iterate over VRAM to track dirty bits. */
         for ( i = 0; i < nr; i++ ) {
-            mfn_t mfn = get_gfn_query(d, begin_pfn + i, &t);
+            mfn_t mfn = get_gfn_query_unlocked(d, begin_pfn + i, &t);
             struct page_info *page;
             int dirty = 0;
             paddr_t sl1ma = dirty_vram->sl1ma[i];
@@ -3741,8 +3741,6 @@ int shadow_track_dirty_vram(struct domai
                 }
             }
 
-            put_gfn(d, begin_pfn + i);
-
             if ( dirty )
             {
                 dirty_vram->dirty_bitmap[i / 8] |= 1 << (i % 8);
diff -r 6f89f15fd3c8 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c	Thu Apr 19 15:31:30 2012 +0100
+++ b/xen/arch/x86/mm/shadow/multi.c	Thu Apr 19 15:48:30 2012 +0100
@@ -2266,7 +2266,7 @@ static int validate_gl4e(struct vcpu *v,
     if ( guest_l4e_get_flags(new_gl4e) & _PAGE_PRESENT )
     {
         gfn_t gl3gfn = guest_l4e_get_gfn(new_gl4e);
-        mfn_t gl3mfn = get_gfn_query(d, gl3gfn, &p2mt);
+        mfn_t gl3mfn = get_gfn_query_unlocked(d, gfn_x(gl3gfn), &p2mt);
         if ( p2m_is_ram(p2mt) )
             sl3mfn = get_shadow_status(v, gl3mfn, SH_type_l3_shadow);
         else if ( p2mt != p2m_populate_on_demand )
@@ -2276,7 +2276,6 @@ static int validate_gl4e(struct vcpu *v,
         if ( mfn_valid(sl3mfn) )
             shadow_resync_all(v);
 #endif
-        put_gfn(d, gfn_x(gl3gfn));
     }
     l4e_propagate_from_guest(v, new_gl4e, sl3mfn, &new_sl4e, ft_prefetch);
 
@@ -2324,7 +2323,7 @@ static int validate_gl3e(struct vcpu *v,
     if ( guest_l3e_get_flags(new_gl3e) & _PAGE_PRESENT )
     {
         gfn_t gl2gfn = guest_l3e_get_gfn(new_gl3e);
-        mfn_t gl2mfn = get_gfn_query(v->domain, gl2gfn, &p2mt);
+        mfn_t gl2mfn = get_gfn_query_unlocked(v->domain, gfn_x(gl2gfn), &p2mt);
         if ( p2m_is_ram(p2mt) )
             sl2mfn = get_shadow_status(v, gl2mfn, SH_type_l2_shadow);
         else if ( p2mt != p2m_populate_on_demand )
@@ -2334,7 +2333,6 @@ static int validate_gl3e(struct vcpu *v,
         if ( mfn_valid(sl2mfn) )
             shadow_resync_all(v);
 #endif
-        put_gfn(v->domain, gfn_x(gl2gfn));
     }
     l3e_propagate_from_guest(v, new_gl3e, sl2mfn, &new_sl3e, ft_prefetch);
     result |= shadow_set_l3e(v, sl3p, new_sl3e, sl3mfn);
@@ -2374,12 +2372,12 @@ static int validate_gl2e(struct vcpu *v,
         }
         else
         {
-            mfn_t gl1mfn = get_gfn_query(v->domain, gl1gfn, &p2mt);
+            mfn_t gl1mfn = get_gfn_query_unlocked(v->domain, gfn_x(gl1gfn),
+                                                  &p2mt);
             if ( p2m_is_ram(p2mt) )
                 sl1mfn = get_shadow_status(v, gl1mfn, SH_type_l1_shadow); 
             else if ( p2mt != p2m_populate_on_demand )
                 result |= SHADOW_SET_ERROR;
-            put_gfn(v->domain, gfn_x(gl1gfn));
         }
     }
     l2e_propagate_from_guest(v, new_gl2e, sl1mfn, &new_sl2e, ft_prefetch);
@@ -2505,11 +2503,9 @@ void sh_resync_l1(struct vcpu *v, mfn_t 
             shadow_l1e_t nsl1e;
 
             gfn = guest_l1e_get_gfn(gl1e);
-            gmfn = get_gfn_query(v->domain, gfn, &p2mt);
+            gmfn = get_gfn_query_unlocked(v->domain, gfn_x(gfn), &p2mt);
             l1e_propagate_from_guest(v, gl1e, gmfn, &nsl1e, ft_prefetch, p2mt);
             rc |= shadow_set_l1e(v, sl1p, nsl1e, p2mt, sl1mfn);
-
-            put_gfn(v->domain, gfn_x(gfn));
             *snpl1p = gl1e;
         }
     });
@@ -2830,7 +2826,7 @@ static void sh_prefetch(struct vcpu *v, 
 
         /* Look at the gfn that the l1e is pointing at */
         gfn = guest_l1e_get_gfn(gl1e);
-        gmfn = get_gfn_query(v->domain, gfn, &p2mt);
+        gmfn = get_gfn_query_unlocked(v->domain, gfn_x(gfn), &p2mt);
 
         /* Propagate the entry.  */
         l1e_propagate_from_guest(v, gl1e, gmfn, &sl1e, ft_prefetch, p2mt);
@@ -2840,8 +2836,6 @@ static void sh_prefetch(struct vcpu *v, 
         if ( snpl1p != NULL )
             snpl1p[i] = gl1e;
 #endif /* OOS */
-
-        put_gfn(v->domain, gfn_x(gfn));
     }
     if ( gl1p != NULL )
         sh_unmap_domain_page(gl1p);
@@ -4323,14 +4317,13 @@ sh_update_cr3(struct vcpu *v, int do_loc
             if ( guest_l3e_get_flags(gl3e[i]) & _PAGE_PRESENT )
             {
                 gl2gfn = guest_l3e_get_gfn(gl3e[i]);
-                gl2mfn = get_gfn_query(d, gl2gfn, &p2mt);
+                gl2mfn = get_gfn_query_unlocked(d, gfn_x(gl2gfn), &p2mt);
                 if ( p2m_is_ram(p2mt) )
                     sh_set_toplevel_shadow(v, i, gl2mfn, (i == 3) 
                                            ? SH_type_l2h_shadow 
                                            : SH_type_l2_shadow);
                 else
                     sh_set_toplevel_shadow(v, i, _mfn(INVALID_MFN), 0); 
-                put_gfn(d, gfn_x(gl2gfn));
             }
             else
                 sh_set_toplevel_shadow(v, i, _mfn(INVALID_MFN), 0); 
@@ -4748,9 +4741,8 @@ static void sh_pagetable_dying(struct vc
             /* retrieving the l2s */
             gl2a = guest_l3e_get_paddr(gl3e[i]);
             gfn = gl2a >> PAGE_SHIFT;
-            gmfn = get_gfn_query(v->domain, _gfn(gfn), &p2mt);
+            gmfn = get_gfn_query_unlocked(v->domain, gfn, &p2mt);
             smfn = shadow_hash_lookup(v, mfn_x(gmfn), SH_type_l2_pae_shadow);
-            put_gfn(v->domain, gfn);
         }
 
         if ( mfn_valid(smfn) )
diff -r 6f89f15fd3c8 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 19 15:31:30 2012 +0100
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 19 15:48:30 2012 +0100
@@ -360,6 +360,11 @@ void __put_gfn(struct p2m_domain *p2m, u
  * during a domain crash, or to peek at a p2m entry/type. Caller is not 
  * holding the p2m entry exclusively during or after calling this. 
  *
+ * This is also used in the shadow code whenever the paging lock is
+ * held -- in those cases, the caller is protected against concurrent
+ * p2m updates by the fact that shadow_write_p2m_entry() also takes
+ * the paging lock.
+ *
  * Note that an unlocked accessor only makes sense for a "query" lookup.
  * Any other type of query can cause a change in the p2m and may need to
  * perform locking.

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--ew6BAiZeqk4r7MaW--


From xen-devel-bounces@lists.xen.org Thu Apr 19 14:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKshx-0006TQ-39; Thu, 19 Apr 2012 14:51:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKshv-0006TL-VC
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 14:51:40 +0000
Received: from [85.158.143.35:25320] by server-3.bemta-4.messagelabs.com id
	FA/01-05853-B76209F4; Thu, 19 Apr 2012 14:51:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334847098!10735917!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26922 invoked from network); 19 Apr 2012 14:51:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 14:51:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKshs-0007FC-ND; Thu, 19 Apr 2012 14:51:36 +0000
Date: Thu, 19 Apr 2012 15:51:36 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120419145136.GC23663@ocelot.phlegethon.org>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
	<20120418161326.GQ7013@ocelot.phlegethon.org>
	<935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
	p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 09:25 -0700 on 18 Apr (1334741158), Andres Lagar-Cavilla wrote:
> > Nack, at least for now; we spent a fair amount of effort taking all this
> > emulation code out from under the shadow lock; serializing it under the
> > p2m lock would be unfortunate.  The other patches are less worrying,
> > since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
> > be avoided.
> >
> > The existing interlock between the shadow code and the p2m code prevents
> > any p2m modifications from happening when the shadow lock is held, so I
> > hope I can solve this by switching to unlocked lookups instead.  I'm
> > building a test kernel now to tell me exactly which lookps are to
> > blame.
> 
> FWIW, get_gfn_query for the target gfn of the PTE entry that is being
> checked in validate_gl?e entry, is the call that causes the panic this
> patch tries to fix.
> 
> As for the other two patches, sh_resync_l1 is the trigger (again,
> get_gfn_query on the gfn that is contained by the PTE being verified)

Thanks.  I've taken a sweep through mm/shadow, making the lookups into
unlocked ones wherever the paging_lock is already held.  With the
attached patch and your final patch to enable the locking, I can start
HVM guests without crashing Xen.  I haven't given it any more serious
testing yet.

Cheers,

Tim.
--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=shadow-vs-p2m

x86/mm/shadow: don't use locking p2m lookups with the paging lock held.

The existing interlock between shadow and p2m (where p2m table updates
are done under the paging lock) keeps us safe from the p2m changing
under our feet, and using the locking lookups is a violation of the
locking discipline (which says always to take the p2m lock first).

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 6f89f15fd3c8 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c	Thu Apr 19 15:31:30 2012 +0100
+++ b/xen/arch/x86/mm/shadow/common.c	Thu Apr 19 15:48:30 2012 +0100
@@ -3676,7 +3676,7 @@ int shadow_track_dirty_vram(struct domai
 
         /* Iterate over VRAM to track dirty bits. */
         for ( i = 0; i < nr; i++ ) {
-            mfn_t mfn = get_gfn_query(d, begin_pfn + i, &t);
+            mfn_t mfn = get_gfn_query_unlocked(d, begin_pfn + i, &t);
             struct page_info *page;
             int dirty = 0;
             paddr_t sl1ma = dirty_vram->sl1ma[i];
@@ -3741,8 +3741,6 @@ int shadow_track_dirty_vram(struct domai
                 }
             }
 
-            put_gfn(d, begin_pfn + i);
-
             if ( dirty )
             {
                 dirty_vram->dirty_bitmap[i / 8] |= 1 << (i % 8);
diff -r 6f89f15fd3c8 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c	Thu Apr 19 15:31:30 2012 +0100
+++ b/xen/arch/x86/mm/shadow/multi.c	Thu Apr 19 15:48:30 2012 +0100
@@ -2266,7 +2266,7 @@ static int validate_gl4e(struct vcpu *v,
     if ( guest_l4e_get_flags(new_gl4e) & _PAGE_PRESENT )
     {
         gfn_t gl3gfn = guest_l4e_get_gfn(new_gl4e);
-        mfn_t gl3mfn = get_gfn_query(d, gl3gfn, &p2mt);
+        mfn_t gl3mfn = get_gfn_query_unlocked(d, gfn_x(gl3gfn), &p2mt);
         if ( p2m_is_ram(p2mt) )
             sl3mfn = get_shadow_status(v, gl3mfn, SH_type_l3_shadow);
         else if ( p2mt != p2m_populate_on_demand )
@@ -2276,7 +2276,6 @@ static int validate_gl4e(struct vcpu *v,
         if ( mfn_valid(sl3mfn) )
             shadow_resync_all(v);
 #endif
-        put_gfn(d, gfn_x(gl3gfn));
     }
     l4e_propagate_from_guest(v, new_gl4e, sl3mfn, &new_sl4e, ft_prefetch);
 
@@ -2324,7 +2323,7 @@ static int validate_gl3e(struct vcpu *v,
     if ( guest_l3e_get_flags(new_gl3e) & _PAGE_PRESENT )
     {
         gfn_t gl2gfn = guest_l3e_get_gfn(new_gl3e);
-        mfn_t gl2mfn = get_gfn_query(v->domain, gl2gfn, &p2mt);
+        mfn_t gl2mfn = get_gfn_query_unlocked(v->domain, gfn_x(gl2gfn), &p2mt);
         if ( p2m_is_ram(p2mt) )
             sl2mfn = get_shadow_status(v, gl2mfn, SH_type_l2_shadow);
         else if ( p2mt != p2m_populate_on_demand )
@@ -2334,7 +2333,6 @@ static int validate_gl3e(struct vcpu *v,
         if ( mfn_valid(sl2mfn) )
             shadow_resync_all(v);
 #endif
-        put_gfn(v->domain, gfn_x(gl2gfn));
     }
     l3e_propagate_from_guest(v, new_gl3e, sl2mfn, &new_sl3e, ft_prefetch);
     result |= shadow_set_l3e(v, sl3p, new_sl3e, sl3mfn);
@@ -2374,12 +2372,12 @@ static int validate_gl2e(struct vcpu *v,
         }
         else
         {
-            mfn_t gl1mfn = get_gfn_query(v->domain, gl1gfn, &p2mt);
+            mfn_t gl1mfn = get_gfn_query_unlocked(v->domain, gfn_x(gl1gfn),
+                                                  &p2mt);
             if ( p2m_is_ram(p2mt) )
                 sl1mfn = get_shadow_status(v, gl1mfn, SH_type_l1_shadow); 
             else if ( p2mt != p2m_populate_on_demand )
                 result |= SHADOW_SET_ERROR;
-            put_gfn(v->domain, gfn_x(gl1gfn));
         }
     }
     l2e_propagate_from_guest(v, new_gl2e, sl1mfn, &new_sl2e, ft_prefetch);
@@ -2505,11 +2503,9 @@ void sh_resync_l1(struct vcpu *v, mfn_t 
             shadow_l1e_t nsl1e;
 
             gfn = guest_l1e_get_gfn(gl1e);
-            gmfn = get_gfn_query(v->domain, gfn, &p2mt);
+            gmfn = get_gfn_query_unlocked(v->domain, gfn_x(gfn), &p2mt);
             l1e_propagate_from_guest(v, gl1e, gmfn, &nsl1e, ft_prefetch, p2mt);
             rc |= shadow_set_l1e(v, sl1p, nsl1e, p2mt, sl1mfn);
-
-            put_gfn(v->domain, gfn_x(gfn));
             *snpl1p = gl1e;
         }
     });
@@ -2830,7 +2826,7 @@ static void sh_prefetch(struct vcpu *v, 
 
         /* Look at the gfn that the l1e is pointing at */
         gfn = guest_l1e_get_gfn(gl1e);
-        gmfn = get_gfn_query(v->domain, gfn, &p2mt);
+        gmfn = get_gfn_query_unlocked(v->domain, gfn_x(gfn), &p2mt);
 
         /* Propagate the entry.  */
         l1e_propagate_from_guest(v, gl1e, gmfn, &sl1e, ft_prefetch, p2mt);
@@ -2840,8 +2836,6 @@ static void sh_prefetch(struct vcpu *v, 
         if ( snpl1p != NULL )
             snpl1p[i] = gl1e;
 #endif /* OOS */
-
-        put_gfn(v->domain, gfn_x(gfn));
     }
     if ( gl1p != NULL )
         sh_unmap_domain_page(gl1p);
@@ -4323,14 +4317,13 @@ sh_update_cr3(struct vcpu *v, int do_loc
             if ( guest_l3e_get_flags(gl3e[i]) & _PAGE_PRESENT )
             {
                 gl2gfn = guest_l3e_get_gfn(gl3e[i]);
-                gl2mfn = get_gfn_query(d, gl2gfn, &p2mt);
+                gl2mfn = get_gfn_query_unlocked(d, gfn_x(gl2gfn), &p2mt);
                 if ( p2m_is_ram(p2mt) )
                     sh_set_toplevel_shadow(v, i, gl2mfn, (i == 3) 
                                            ? SH_type_l2h_shadow 
                                            : SH_type_l2_shadow);
                 else
                     sh_set_toplevel_shadow(v, i, _mfn(INVALID_MFN), 0); 
-                put_gfn(d, gfn_x(gl2gfn));
             }
             else
                 sh_set_toplevel_shadow(v, i, _mfn(INVALID_MFN), 0); 
@@ -4748,9 +4741,8 @@ static void sh_pagetable_dying(struct vc
             /* retrieving the l2s */
             gl2a = guest_l3e_get_paddr(gl3e[i]);
             gfn = gl2a >> PAGE_SHIFT;
-            gmfn = get_gfn_query(v->domain, _gfn(gfn), &p2mt);
+            gmfn = get_gfn_query_unlocked(v->domain, gfn, &p2mt);
             smfn = shadow_hash_lookup(v, mfn_x(gmfn), SH_type_l2_pae_shadow);
-            put_gfn(v->domain, gfn);
         }
 
         if ( mfn_valid(smfn) )
diff -r 6f89f15fd3c8 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 19 15:31:30 2012 +0100
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 19 15:48:30 2012 +0100
@@ -360,6 +360,11 @@ void __put_gfn(struct p2m_domain *p2m, u
  * during a domain crash, or to peek at a p2m entry/type. Caller is not 
  * holding the p2m entry exclusively during or after calling this. 
  *
+ * This is also used in the shadow code whenever the paging lock is
+ * held -- in those cases, the caller is protected against concurrent
+ * p2m updates by the fact that shadow_write_p2m_entry() also takes
+ * the paging lock.
+ *
  * Note that an unlocked accessor only makes sense for a "query" lookup.
  * Any other type of query can cause a change in the p2m and may need to
  * perform locking.

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--ew6BAiZeqk4r7MaW--


From xen-devel-bounces@lists.xen.org Thu Apr 19 15:07:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKsxD-0006tr-Rn; Thu, 19 Apr 2012 15:07:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1SKsxB-0006tm-OG
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 15:07:25 +0000
Received: from [193.109.254.147:51923] by server-11.bemta-14.messagelabs.com
	id 1B/5C-05858-D2A209F4; Thu, 19 Apr 2012 15:07:25 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334848043!5383159!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10384 invoked from network); 19 Apr 2012 15:07:24 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 15:07:24 -0000
Received: by yhoo21 with SMTP id o21so5351137yho.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 08:07:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=t+fEoXE0t4JKvTBuBLec6jb12UnsRatRxjJwB3V+xpo=;
	b=FkNQ/oFRtDSzOK5pC7RpSpcEXNsGuZSJfkiBf73rPPO/Rk2NRxeoD4dznFNIMSaAAs
	dIb/QaNSPQb/OmPnTGFjyhMs3UqzFnR9T98R2aHRLvn9ZXq3z9PcOcgKeToBYXj8B53b
	Q0PqS+6HWayTY9667zEKX8P+zdXUL8wrGCwQot38WTb8dm7R2IJcS1pBvBq9+NcOdgGT
	j7kfpGB/9pwJCe0oTaH05OayJaZ+vobSBzpFJ7apcFUvJkMmWQdTkfHIEaw7Lxc7SUvh
	G1lkAZckgwN5ezgBpUEgNleoziBhhw8joTPKHPB3+K+0gP5bW4lyfe6VTvK6oABSnQRu
	Nccg==
Received: by 10.50.6.166 with SMTP id c6mr280612iga.65.1334848042403;
	Thu, 19 Apr 2012 08:07:22 -0700 (PDT)
Received: from [192.168.7.211] ([206.223.182.18])
	by mx.google.com with ESMTPS id hq3sm56009400igc.0.2012.04.19.08.07.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 08:07:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120419145136.GC23663@ocelot.phlegethon.org>
Date: Thu, 19 Apr 2012 11:07:20 -0400
Message-Id: <BF64296E-B220-43A6-8724-C93DE39C88E8@gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
	<20120418161326.GQ7013@ocelot.phlegethon.org>
	<935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
	<20120419145136.GC23663@ocelot.phlegethon.org>
To: Tim Deegan <tim@xen.org>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkhBmK6EEj0ECS1ZwnnTdytxz33hzy/HyQeyI2UOSIsyxfWNMSLihbUKTJVJfSdWGK0ClRp
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
	p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 19, 2012, at 10:51 AM, Tim Deegan wrote:

> At 09:25 -0700 on 18 Apr (1334741158), Andres Lagar-Cavilla wrote:
>>> Nack, at least for now; we spent a fair amount of effort taking all this
>>> emulation code out from under the shadow lock; serializing it under the
>>> p2m lock would be unfortunate.  The other patches are less worrying,
>>> since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
>>> be avoided.
>>> 
>>> The existing interlock between the shadow code and the p2m code prevents
>>> any p2m modifications from happening when the shadow lock is held, so I
>>> hope I can solve this by switching to unlocked lookups instead.  I'm
>>> building a test kernel now to tell me exactly which lookps are to
>>> blame.
>> 
>> FWIW, get_gfn_query for the target gfn of the PTE entry that is being
>> checked in validate_gl?e entry, is the call that causes the panic this
>> patch tries to fix.
>> 
>> As for the other two patches, sh_resync_l1 is the trigger (again,
>> get_gfn_query on the gfn that is contained by the PTE being verified)
> 
> Thanks.  I've taken a sweep through mm/shadow, making the lookups into
> unlocked ones wherever the paging_lock is already held.  With the
> attached patch and your final patch to enable the locking, I can start
> HVM guests without crashing Xen.  I haven't given it any more serious
> testing yet.

It looks good to me. Thanks. 
Acked-by Andres Lagar-Cavilla <andres@lagarcavilla.org>

Andres
> 
> Cheers,
> 
> Tim.<shadow-vs-p2m.txt>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 15:07:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKsxD-0006tr-Rn; Thu, 19 Apr 2012 15:07:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1SKsxB-0006tm-OG
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 15:07:25 +0000
Received: from [193.109.254.147:51923] by server-11.bemta-14.messagelabs.com
	id 1B/5C-05858-D2A209F4; Thu, 19 Apr 2012 15:07:25 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334848043!5383159!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10384 invoked from network); 19 Apr 2012 15:07:24 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 15:07:24 -0000
Received: by yhoo21 with SMTP id o21so5351137yho.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 08:07:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=t+fEoXE0t4JKvTBuBLec6jb12UnsRatRxjJwB3V+xpo=;
	b=FkNQ/oFRtDSzOK5pC7RpSpcEXNsGuZSJfkiBf73rPPO/Rk2NRxeoD4dznFNIMSaAAs
	dIb/QaNSPQb/OmPnTGFjyhMs3UqzFnR9T98R2aHRLvn9ZXq3z9PcOcgKeToBYXj8B53b
	Q0PqS+6HWayTY9667zEKX8P+zdXUL8wrGCwQot38WTb8dm7R2IJcS1pBvBq9+NcOdgGT
	j7kfpGB/9pwJCe0oTaH05OayJaZ+vobSBzpFJ7apcFUvJkMmWQdTkfHIEaw7Lxc7SUvh
	G1lkAZckgwN5ezgBpUEgNleoziBhhw8joTPKHPB3+K+0gP5bW4lyfe6VTvK6oABSnQRu
	Nccg==
Received: by 10.50.6.166 with SMTP id c6mr280612iga.65.1334848042403;
	Thu, 19 Apr 2012 08:07:22 -0700 (PDT)
Received: from [192.168.7.211] ([206.223.182.18])
	by mx.google.com with ESMTPS id hq3sm56009400igc.0.2012.04.19.08.07.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 08:07:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120419145136.GC23663@ocelot.phlegethon.org>
Date: Thu, 19 Apr 2012 11:07:20 -0400
Message-Id: <BF64296E-B220-43A6-8724-C93DE39C88E8@gridcentric.ca>
References: <patchbomb.1334334138@xdev.gridcentric.ca>
	<964c6cbad92639029f4a.1334334141@xdev.gridcentric.ca>
	<20120418161326.GQ7013@ocelot.phlegethon.org>
	<935c1260b84ac992582032fd1b047409.squirrel@webmail.lagarcavilla.org>
	<20120419145136.GC23663@ocelot.phlegethon.org>
To: Tim Deegan <tim@xen.org>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkhBmK6EEj0ECS1ZwnnTdytxz33hzy/HyQeyI2UOSIsyxfWNMSLihbUKTJVJfSdWGK0ClRp
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential
	p2m/paging deadlock when emulating page table writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 19, 2012, at 10:51 AM, Tim Deegan wrote:

> At 09:25 -0700 on 18 Apr (1334741158), Andres Lagar-Cavilla wrote:
>>> Nack, at least for now; we spent a fair amount of effort taking all this
>>> emulation code out from under the shadow lock; serializing it under the
>>> p2m lock would be unfortunate.  The other patches are less worrying,
>>> since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
>>> be avoided.
>>> 
>>> The existing interlock between the shadow code and the p2m code prevents
>>> any p2m modifications from happening when the shadow lock is held, so I
>>> hope I can solve this by switching to unlocked lookups instead.  I'm
>>> building a test kernel now to tell me exactly which lookps are to
>>> blame.
>> 
>> FWIW, get_gfn_query for the target gfn of the PTE entry that is being
>> checked in validate_gl?e entry, is the call that causes the panic this
>> patch tries to fix.
>> 
>> As for the other two patches, sh_resync_l1 is the trigger (again,
>> get_gfn_query on the gfn that is contained by the PTE being verified)
> 
> Thanks.  I've taken a sweep through mm/shadow, making the lookups into
> unlocked ones wherever the paging_lock is already held.  With the
> attached patch and your final patch to enable the locking, I can start
> HVM guests without crashing Xen.  I haven't given it any more serious
> testing yet.

It looks good to me. Thanks. 
Acked-by Andres Lagar-Cavilla <andres@lagarcavilla.org>

Andres
> 
> Cheers,
> 
> Tim.<shadow-vs-p2m.txt>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 15:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKtQk-0007Ix-J0; Thu, 19 Apr 2012 15:37:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKtQi-0007Is-TI
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 15:37:57 +0000
Received: from [85.158.139.83:24946] by server-5.bemta-5.messagelabs.com id
	2E/35-13566-351309F4; Thu, 19 Apr 2012 15:37:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334849875!24625376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 625 invoked from network); 19 Apr 2012 15:37:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 15:37:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="12032292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 15:37:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 16:37:54 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKtQf-0001ik-Vy;
	Thu, 19 Apr 2012 15:37:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKtQf-00085w-BQ;
	Thu, 19 Apr 2012 16:37:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12725-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 16:37:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12725: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12725 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12725/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                932e9f352b5d685725076f21b237f7c7d804b29c
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 15:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKtQk-0007Ix-J0; Thu, 19 Apr 2012 15:37:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKtQi-0007Is-TI
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 15:37:57 +0000
Received: from [85.158.139.83:24946] by server-5.bemta-5.messagelabs.com id
	2E/35-13566-351309F4; Thu, 19 Apr 2012 15:37:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334849875!24625376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 625 invoked from network); 19 Apr 2012 15:37:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 15:37:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="12032292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 15:37:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 16:37:54 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKtQf-0001ik-Vy;
	Thu, 19 Apr 2012 15:37:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKtQf-00085w-BQ;
	Thu, 19 Apr 2012 16:37:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12725-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 16:37:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 12725: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12725 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12725/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12557
 test-i386-i386-pv             7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 12557
 test-amd64-i386-xl            7 debian-install            fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 12557
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-i386-i386-xl-winxpsp3    5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-win           5 xen-boot                     fail   never pass
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail   never pass
 test-amd64-i386-pv            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-i386-i386-xl             7 debian-install               fail   never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-pair          11 debian-install/dst_host      fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                932e9f352b5d685725076f21b237f7c7d804b29c
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 15:38:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:38:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKtR3-0007KA-6C; Thu, 19 Apr 2012 15:38:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKtR1-0007Jy-Ds
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 15:38:15 +0000
Received: from [193.109.254.147:49957] by server-7.bemta-14.messagelabs.com id
	3F/C2-01627-661309F4; Thu, 19 Apr 2012 15:38:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334849892!5400563!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MjA1NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18798 invoked from network); 19 Apr 2012 15:38:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 15:38:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JFc6fJ019014
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 15:38:07 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JFc5Pn001905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 15:38:06 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JFc5NQ023101; Thu, 19 Apr 2012 10:38:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 08:38:04 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 537F94032D; Thu, 19 Apr 2012 11:33:06 -0400 (EDT)
Date: Thu, 19 Apr 2012 11:33:06 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120419153306.GA2814@phenom.dumpdata.com>
References: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1204191232590.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204191232590.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F90315F.00A8,ss=1,re=0.000,fgs=0
Cc: konrad <konrad@localhost.localdomain>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/xenbus: Add quirk to deal with
 misconfigured backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 12:37:42PM +0100, Stefano Stabellini wrote:
> On Wed, 18 Apr 2012, Konrad Rzeszutek Wilk wrote:
> > From: konrad <konrad@localhost.localdomain>
> 
> wrong email address

Yeah :-)
> 
> 
> > A rather annoying and common case is when booting a PVonHVM guest
> > and exposing the PV KBD and PV VFB - as both of those do not
> > make any sense.
> 
> I would rather write: "as broken toolstacks don't always initialize the
> backends correctly."

OK.
> 
> 
> > The HVM guest is using the VGA driver and the emulated
> > keyboard for this. So we provide a very basic quirk framework
> > (can be expanded in the future) to not wait for 6 minutes for those devices
> > to initialize - they never wont.
> > 
> > To trigger this, put this in your guest config:
> > 
> > vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
> > 
> > instead of this:
> > vnc=1
> > vnclisten="0.0.0.0"
> > 
> > [v3: Split delay in non-essential (30 seconds) and essential
> >  devices per Ian and Stefano suggestion]
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>quirk
> > ---
> >  drivers/xen/xenbus/xenbus_probe_frontend.c |   69 +++++++++++++++++++++------
> >  1 files changed, 53 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> > index f20c5f1..7422913 100644
> > --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> > +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> > @@ -135,7 +135,7 @@ static int read_backend_details(struct xenbus_device *xendev)
> >  	return xenbus_read_otherend_details(xendev, "backend-id", "backend");
> >  }
> >  
> > -static int is_device_connecting(struct device *dev, void *data)
> > +static int is_device_connecting(struct device *dev, void *data, bool ignore_vkbd)
> >  {
> >  	struct xenbus_device *xendev = to_xenbus_device(dev);
> >  	struct device_driver *drv = data;
> > @@ -152,16 +152,41 @@ static int is_device_connecting(struct device *dev, void *data)
> >  	if (drv && (dev->driver != drv))
> >  		return 0;
> >  
> > +	if (ignore_vkbd) {
> 
> I would name the parameter ignore_nonessential, just to make it clearer
> that is not just about vkbd

OK.
> 
> 
> > +		/* With older QEMU, for PVonHVM guests the guest config files
> > +		 * could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0']
> > +		 * which is nonsensical as there is no PV FB (there can be
> > +		 * a PVKB) running as HVM guest. */
> > +
> > +		if ((strncmp(xendev->nodename, "device/vkbd", 11) == 0))
> > +			return 0;
> > +
> > +		if ((strncmp(xendev->nodename, "device/vfb", 10) == 0))
> > +			return 0;
> > +	}
> >  	xendrv = to_xenbus_driver(dev->driver);
> >  	return (xendev->state < XenbusStateConnected ||
> >  		(xendev->state == XenbusStateConnected &&
> >  		 xendrv->is_ready && !xendrv->is_ready(xendev)));
> >  }
> > +static int essential_device_connecting(struct device *dev, void *data)
> > +{
> > +	return is_device_connecting(dev, data, true /* ignore PVKB+PVDB */);
> > +}
> 
> the comment is wrong

Oh, PVKBD + PVFB. Right.

> 
> 
> > +static int non_essential_device_connecting(struct device *dev, void *data)
> > +{
> > +	return is_device_connecting(dev, data, false);
> > +}
> >  
> > -static int exists_connecting_device(struct device_driver *drv)
> > +static int exists_essential_connecting_device(struct device_driver *drv)
> >  {
> >  	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> > -				is_device_connecting);
> > +				essential_device_connecting);
> > +}
> > +static int exists_non_essential_connecting_device(struct device_driver *drv)
> > +{
> > +	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> > +				non_essential_device_connecting);
> >  }
> >  
> >  static int print_device_status(struct device *dev, void *data)
> > @@ -192,6 +217,23 @@ static int print_device_status(struct device *dev, void *data)
> >  /* We only wait for device setup after most initcalls have run. */
> >  static int ready_to_wait_for_devices;
> >  
> > +static bool wait_loop(unsigned long start, unsigned int max_delay,
> > +		     unsigned int *seconds_waited)
> > +{
> > +	if (time_after(jiffies, start + (*seconds_waited+5)*HZ)) {
> > +		if (!*seconds_waited)
> > +			printk(KERN_WARNING "XENBUS: Waiting for "
> > +			       "devices to initialise: ");
> > +		*seconds_waited += 5;
> > +		printk("%us...", max_delay - *seconds_waited);
> > +		if (*seconds_waited == max_delay)
> > +			return true;
> > +	}
> > +
> > +	schedule_timeout_interruptible(HZ/10);
> > +
> > +	return false;
> > +}
> >  /*
> >   * On a 5-minute timeout, wait for all devices currently configured.  We need
> >   * to do this to guarantee that the filesystems and / or network devices
> > @@ -215,19 +257,14 @@ static void wait_for_devices(struct xenbus_driver *xendrv)
> >  	if (!ready_to_wait_for_devices || !xen_domain())
> >  		return;
> >  
> > -	while (exists_connecting_device(drv)) {
> > -		if (time_after(jiffies, start + (seconds_waited+5)*HZ)) {
> > -			if (!seconds_waited)
> > -				printk(KERN_WARNING "XENBUS: Waiting for "
> > -				       "devices to initialise: ");
> > -			seconds_waited += 5;
> > -			printk("%us...", 300 - seconds_waited);
> > -			if (seconds_waited == 300)
> > -				break;
> > -		}
> > -
> > -		schedule_timeout_interruptible(HZ/10);
> > -	}
> > +	while (exists_non_essential_connecting_device(drv))
> > +		if (wait_loop(start, 30, &seconds_waited))
> > +			break;
> > +
> > +	/* Skips PVKB and PVFB check.*/
> > +	while (exists_essential_connecting_device(drv))
> > +		if (wait_loop(start, 270, &seconds_waited))
> > +			break;
> >  
> >  	if (seconds_waited)
> >  		printk("\n");
> > -- 
> > 1.7.7.5
> > 
> 
> Other than the comments I wrote above, I think the patch is good

Sweet. thx!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 15:38:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:38:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKtR3-0007KA-6C; Thu, 19 Apr 2012 15:38:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKtR1-0007Jy-Ds
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 15:38:15 +0000
Received: from [193.109.254.147:49957] by server-7.bemta-14.messagelabs.com id
	3F/C2-01627-661309F4; Thu, 19 Apr 2012 15:38:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1334849892!5400563!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MjA1NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18798 invoked from network); 19 Apr 2012 15:38:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 15:38:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JFc6fJ019014
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 15:38:07 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JFc5Pn001905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 15:38:06 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JFc5NQ023101; Thu, 19 Apr 2012 10:38:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 08:38:04 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 537F94032D; Thu, 19 Apr 2012 11:33:06 -0400 (EDT)
Date: Thu, 19 Apr 2012 11:33:06 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120419153306.GA2814@phenom.dumpdata.com>
References: <1334773144-2394-1-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1204191232590.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204191232590.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F90315F.00A8,ss=1,re=0.000,fgs=0
Cc: konrad <konrad@localhost.localdomain>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/xenbus: Add quirk to deal with
 misconfigured backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 12:37:42PM +0100, Stefano Stabellini wrote:
> On Wed, 18 Apr 2012, Konrad Rzeszutek Wilk wrote:
> > From: konrad <konrad@localhost.localdomain>
> 
> wrong email address

Yeah :-)
> 
> 
> > A rather annoying and common case is when booting a PVonHVM guest
> > and exposing the PV KBD and PV VFB - as both of those do not
> > make any sense.
> 
> I would rather write: "as broken toolstacks don't always initialize the
> backends correctly."

OK.
> 
> 
> > The HVM guest is using the VGA driver and the emulated
> > keyboard for this. So we provide a very basic quirk framework
> > (can be expanded in the future) to not wait for 6 minutes for those devices
> > to initialize - they never wont.
> > 
> > To trigger this, put this in your guest config:
> > 
> > vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
> > 
> > instead of this:
> > vnc=1
> > vnclisten="0.0.0.0"
> > 
> > [v3: Split delay in non-essential (30 seconds) and essential
> >  devices per Ian and Stefano suggestion]
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>quirk
> > ---
> >  drivers/xen/xenbus/xenbus_probe_frontend.c |   69 +++++++++++++++++++++------
> >  1 files changed, 53 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> > index f20c5f1..7422913 100644
> > --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> > +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> > @@ -135,7 +135,7 @@ static int read_backend_details(struct xenbus_device *xendev)
> >  	return xenbus_read_otherend_details(xendev, "backend-id", "backend");
> >  }
> >  
> > -static int is_device_connecting(struct device *dev, void *data)
> > +static int is_device_connecting(struct device *dev, void *data, bool ignore_vkbd)
> >  {
> >  	struct xenbus_device *xendev = to_xenbus_device(dev);
> >  	struct device_driver *drv = data;
> > @@ -152,16 +152,41 @@ static int is_device_connecting(struct device *dev, void *data)
> >  	if (drv && (dev->driver != drv))
> >  		return 0;
> >  
> > +	if (ignore_vkbd) {
> 
> I would name the parameter ignore_nonessential, just to make it clearer
> that is not just about vkbd

OK.
> 
> 
> > +		/* With older QEMU, for PVonHVM guests the guest config files
> > +		 * could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0']
> > +		 * which is nonsensical as there is no PV FB (there can be
> > +		 * a PVKB) running as HVM guest. */
> > +
> > +		if ((strncmp(xendev->nodename, "device/vkbd", 11) == 0))
> > +			return 0;
> > +
> > +		if ((strncmp(xendev->nodename, "device/vfb", 10) == 0))
> > +			return 0;
> > +	}
> >  	xendrv = to_xenbus_driver(dev->driver);
> >  	return (xendev->state < XenbusStateConnected ||
> >  		(xendev->state == XenbusStateConnected &&
> >  		 xendrv->is_ready && !xendrv->is_ready(xendev)));
> >  }
> > +static int essential_device_connecting(struct device *dev, void *data)
> > +{
> > +	return is_device_connecting(dev, data, true /* ignore PVKB+PVDB */);
> > +}
> 
> the comment is wrong

Oh, PVKBD + PVFB. Right.

> 
> 
> > +static int non_essential_device_connecting(struct device *dev, void *data)
> > +{
> > +	return is_device_connecting(dev, data, false);
> > +}
> >  
> > -static int exists_connecting_device(struct device_driver *drv)
> > +static int exists_essential_connecting_device(struct device_driver *drv)
> >  {
> >  	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> > -				is_device_connecting);
> > +				essential_device_connecting);
> > +}
> > +static int exists_non_essential_connecting_device(struct device_driver *drv)
> > +{
> > +	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
> > +				non_essential_device_connecting);
> >  }
> >  
> >  static int print_device_status(struct device *dev, void *data)
> > @@ -192,6 +217,23 @@ static int print_device_status(struct device *dev, void *data)
> >  /* We only wait for device setup after most initcalls have run. */
> >  static int ready_to_wait_for_devices;
> >  
> > +static bool wait_loop(unsigned long start, unsigned int max_delay,
> > +		     unsigned int *seconds_waited)
> > +{
> > +	if (time_after(jiffies, start + (*seconds_waited+5)*HZ)) {
> > +		if (!*seconds_waited)
> > +			printk(KERN_WARNING "XENBUS: Waiting for "
> > +			       "devices to initialise: ");
> > +		*seconds_waited += 5;
> > +		printk("%us...", max_delay - *seconds_waited);
> > +		if (*seconds_waited == max_delay)
> > +			return true;
> > +	}
> > +
> > +	schedule_timeout_interruptible(HZ/10);
> > +
> > +	return false;
> > +}
> >  /*
> >   * On a 5-minute timeout, wait for all devices currently configured.  We need
> >   * to do this to guarantee that the filesystems and / or network devices
> > @@ -215,19 +257,14 @@ static void wait_for_devices(struct xenbus_driver *xendrv)
> >  	if (!ready_to_wait_for_devices || !xen_domain())
> >  		return;
> >  
> > -	while (exists_connecting_device(drv)) {
> > -		if (time_after(jiffies, start + (seconds_waited+5)*HZ)) {
> > -			if (!seconds_waited)
> > -				printk(KERN_WARNING "XENBUS: Waiting for "
> > -				       "devices to initialise: ");
> > -			seconds_waited += 5;
> > -			printk("%us...", 300 - seconds_waited);
> > -			if (seconds_waited == 300)
> > -				break;
> > -		}
> > -
> > -		schedule_timeout_interruptible(HZ/10);
> > -	}
> > +	while (exists_non_essential_connecting_device(drv))
> > +		if (wait_loop(start, 30, &seconds_waited))
> > +			break;
> > +
> > +	/* Skips PVKB and PVFB check.*/
> > +	while (exists_essential_connecting_device(drv))
> > +		if (wait_loop(start, 270, &seconds_waited))
> > +			break;
> >  
> >  	if (seconds_waited)
> >  		printk("\n");
> > -- 
> > 1.7.7.5
> > 
> 
> Other than the comments I wrote above, I think the patch is good

Sweet. thx!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 15:53:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKtfX-0007qG-NR; Thu, 19 Apr 2012 15:53:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1SKtfW-0007qB-TT
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 15:53:15 +0000
Received: from [85.158.138.51:19999] by server-7.bemta-3.messagelabs.com id
	B4/4F-03078-AE4309F4; Thu, 19 Apr 2012 15:53:14 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334850791!18548662!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19490 invoked from network); 19 Apr 2012 15:53:13 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 15:53:13 -0000
Received: by qabg27 with SMTP id g27so1375561qab.9
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 08:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=L1JzyGdZB/G4/kZ0qFVF4iFpkrysI7CDLmJCl3B8prE=;
	b=nQe/14SdIfAvR5x2RIgScXTTomv03AtBL4E23GVRbrWik9unkqFj5Nv1zSR7D5aGg4
	fg/UH/KOrlrVgoAp0mV5srC3wEZvqRp279H/t9cDXpb/kou/BE18oezOwreJI2oNPvFu
	WjFQe4JnkSzAAN4X3uO7TqwihHVZrsmwPJYiWu1LwOKcqY5SvcLD+4ovYFKhhwBnOApK
	VxQj9v8AgsZKPUr0+zR4eup4FdmfVTJ92m3ZVEIPf9IxXxx2hKE8sCZb+DlGt/rFx095
	Crvl8nnpA3hnEPntpn9gooWIRTG6vBarBvnlIIfelVTKDhNq/KoKGsOZFVUfwye8+9sx
	gyKQ==
MIME-Version: 1.0
Received: by 10.224.199.202 with SMTP id et10mr3711742qab.60.1334850791481;
	Thu, 19 Apr 2012 08:53:11 -0700 (PDT)
Received: by 10.229.245.5 with HTTP; Thu, 19 Apr 2012 08:53:11 -0700 (PDT)
In-Reply-To: <20120314132705.GA3248@router-fw-old.local.net-space.pl>
References: <CA+ePHTDdZN8bvCtv0a9noqA6E0TURJ0A2JJPNzMpMerGrk1mNQ@mail.gmail.com>
	<20120314132705.GA3248@router-fw-old.local.net-space.pl>
Date: Thu, 19 Apr 2012 23:53:11 +0800
Message-ID: <CA+ePHTCTSrYoBSVys-PdsKW0hgCSSvHpu3-soF=oByfAc6wx9A@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to debug the minios in xen ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2268081605954366885=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2268081605954366885==
Content-Type: multipart/alternative; boundary=20cf300fb10141226304be0a2b84

--20cf300fb10141226304be0a2b84
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 14, 2012 at 9:27 PM, Daniel Kiper <dkiper@net-space.pl> wrote:

> On Tue, Mar 13, 2012 at 02:16:26PM +0800, ?????? wrote:
> > Hi,
> >     The minios source code is in extra/minios. After compiling, I got a
> > file called mini-os.gz, then I succeed to start a domainU by setting th=
e
> > kernerl to be mini-os.gz in config file 'minios.conf' as follow:
> > # Kernel image file.
> > kernel =3D "/home/test/minios.gz"
> >
> >     The command 'xm list' show:
> > Name                                        ID   Mem VCPUs      State
> > Time(s)
> > Domain-0                                     0  1220     2     r-----
> >  11527.3
> > minios-120                                   5   256     1     --p---
> > 1110.5
> >
> >     I got the gdbserver-xen later and run 'gdbserver-xen
> > 127.0.0.1:9999--attach 5'(5 is the domid). Next, run 'gdb
> > /path/to/minios/exefile', and
> > then 'bt' in gdb, but no stack info.
> >     thanks in advance for your help.
>
> Hmmm... I think that you forgot to connect to gdbserver-xen.
> Run following command from gdb: target remote :9999
> and do not forget compile mini-os with symbols.
>
> Daniel
>
Thanks=EF=BC=8CI'll have a try.
I'm not clear about compiling mini-os with symbols, does it make sense that
specifing the /path/to/minios-source in gdb cmd line and the gdb would find
the symbols infomation automatically?

--20cf300fb10141226304be0a2b84
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Mar 1=
4, 2012 at 9:27 PM, Daniel Kiper <span dir=3D"ltr">&lt;<a href=3D"mailto:dk=
iper@net-space.pl" target=3D"_blank">dkiper@net-space.pl</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Mar 13, 2012 at 02=
:16:26PM +0800, ?????? wrote:<br>
&gt; Hi,<br>
&gt; =C2=A0 =C2=A0 The minios source code is in extra/minios. After compili=
ng, I got a<br>
&gt; file called mini-os.gz, then I succeed to start a domainU by setting t=
he<br>
&gt; kernerl to be mini-os.gz in config file &#39;minios.conf&#39; as follo=
w:<br>
&gt; # Kernel image file.<br>
&gt; kernel =3D &quot;/home/test/minios.gz&quot;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The command &#39;xm list&#39; show:<br>
&gt; Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0ID =C2=A0 Mem VCPUs =C2=A0 =C2=A0 =C2=A0State<br>
&gt; Time(s)<br>
&gt; Domain-0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0=
1220 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 r-----<br>
&gt; =C2=A011527.3<br>
&gt; minios-120 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5 =C2=A0 256 =
=C2=A0 =C2=A0 1 =C2=A0 =C2=A0 --p---<br>
&gt; 1110.5<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 I got the gdbserver-xen later and run &#39;gdbserver-xen=
<br>
</div>&gt; 127.0.0.1:9999--attach 5&#39;(5 is the domid). Next, run &#39;gd=
b<br>
<div class=3D"im">&gt; /path/to/minios/exefile&#39;, and<br>
&gt; then &#39;bt&#39; in gdb, but no stack info.<br>
&gt; =C2=A0 =C2=A0 thanks in advance for your help.<br>
<br>
</div>Hmmm... I think that you forgot to connect to gdbserver-xen.<br>
Run following command from gdb: target remote :9999<br>
and do not forget compile mini-os with symbols.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Daniel<br>
</font></span></blockquote></div>Thanks=EF=BC=8CI&#39;ll have a try.</div><=
div class=3D"gmail_extra">I&#39;m not clear about compiling mini-os with sy=
mbols, does it make sense that specifing the /path/to/minios-source in gdb =
cmd line and the gdb would find the symbols infomation automatically?</div>

--20cf300fb10141226304be0a2b84--


--===============2268081605954366885==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2268081605954366885==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 15:53:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 15:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKtfX-0007qG-NR; Thu, 19 Apr 2012 15:53:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1SKtfW-0007qB-TT
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 15:53:15 +0000
Received: from [85.158.138.51:19999] by server-7.bemta-3.messagelabs.com id
	B4/4F-03078-AE4309F4; Thu, 19 Apr 2012 15:53:14 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334850791!18548662!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19490 invoked from network); 19 Apr 2012 15:53:13 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 15:53:13 -0000
Received: by qabg27 with SMTP id g27so1375561qab.9
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 08:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=L1JzyGdZB/G4/kZ0qFVF4iFpkrysI7CDLmJCl3B8prE=;
	b=nQe/14SdIfAvR5x2RIgScXTTomv03AtBL4E23GVRbrWik9unkqFj5Nv1zSR7D5aGg4
	fg/UH/KOrlrVgoAp0mV5srC3wEZvqRp279H/t9cDXpb/kou/BE18oezOwreJI2oNPvFu
	WjFQe4JnkSzAAN4X3uO7TqwihHVZrsmwPJYiWu1LwOKcqY5SvcLD+4ovYFKhhwBnOApK
	VxQj9v8AgsZKPUr0+zR4eup4FdmfVTJ92m3ZVEIPf9IxXxx2hKE8sCZb+DlGt/rFx095
	Crvl8nnpA3hnEPntpn9gooWIRTG6vBarBvnlIIfelVTKDhNq/KoKGsOZFVUfwye8+9sx
	gyKQ==
MIME-Version: 1.0
Received: by 10.224.199.202 with SMTP id et10mr3711742qab.60.1334850791481;
	Thu, 19 Apr 2012 08:53:11 -0700 (PDT)
Received: by 10.229.245.5 with HTTP; Thu, 19 Apr 2012 08:53:11 -0700 (PDT)
In-Reply-To: <20120314132705.GA3248@router-fw-old.local.net-space.pl>
References: <CA+ePHTDdZN8bvCtv0a9noqA6E0TURJ0A2JJPNzMpMerGrk1mNQ@mail.gmail.com>
	<20120314132705.GA3248@router-fw-old.local.net-space.pl>
Date: Thu, 19 Apr 2012 23:53:11 +0800
Message-ID: <CA+ePHTCTSrYoBSVys-PdsKW0hgCSSvHpu3-soF=oByfAc6wx9A@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to debug the minios in xen ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2268081605954366885=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2268081605954366885==
Content-Type: multipart/alternative; boundary=20cf300fb10141226304be0a2b84

--20cf300fb10141226304be0a2b84
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 14, 2012 at 9:27 PM, Daniel Kiper <dkiper@net-space.pl> wrote:

> On Tue, Mar 13, 2012 at 02:16:26PM +0800, ?????? wrote:
> > Hi,
> >     The minios source code is in extra/minios. After compiling, I got a
> > file called mini-os.gz, then I succeed to start a domainU by setting th=
e
> > kernerl to be mini-os.gz in config file 'minios.conf' as follow:
> > # Kernel image file.
> > kernel =3D "/home/test/minios.gz"
> >
> >     The command 'xm list' show:
> > Name                                        ID   Mem VCPUs      State
> > Time(s)
> > Domain-0                                     0  1220     2     r-----
> >  11527.3
> > minios-120                                   5   256     1     --p---
> > 1110.5
> >
> >     I got the gdbserver-xen later and run 'gdbserver-xen
> > 127.0.0.1:9999--attach 5'(5 is the domid). Next, run 'gdb
> > /path/to/minios/exefile', and
> > then 'bt' in gdb, but no stack info.
> >     thanks in advance for your help.
>
> Hmmm... I think that you forgot to connect to gdbserver-xen.
> Run following command from gdb: target remote :9999
> and do not forget compile mini-os with symbols.
>
> Daniel
>
Thanks=EF=BC=8CI'll have a try.
I'm not clear about compiling mini-os with symbols, does it make sense that
specifing the /path/to/minios-source in gdb cmd line and the gdb would find
the symbols infomation automatically?

--20cf300fb10141226304be0a2b84
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Mar 1=
4, 2012 at 9:27 PM, Daniel Kiper <span dir=3D"ltr">&lt;<a href=3D"mailto:dk=
iper@net-space.pl" target=3D"_blank">dkiper@net-space.pl</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Mar 13, 2012 at 02=
:16:26PM +0800, ?????? wrote:<br>
&gt; Hi,<br>
&gt; =C2=A0 =C2=A0 The minios source code is in extra/minios. After compili=
ng, I got a<br>
&gt; file called mini-os.gz, then I succeed to start a domainU by setting t=
he<br>
&gt; kernerl to be mini-os.gz in config file &#39;minios.conf&#39; as follo=
w:<br>
&gt; # Kernel image file.<br>
&gt; kernel =3D &quot;/home/test/minios.gz&quot;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The command &#39;xm list&#39; show:<br>
&gt; Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0ID =C2=A0 Mem VCPUs =C2=A0 =C2=A0 =C2=A0State<br>
&gt; Time(s)<br>
&gt; Domain-0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0=
1220 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 r-----<br>
&gt; =C2=A011527.3<br>
&gt; minios-120 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5 =C2=A0 256 =
=C2=A0 =C2=A0 1 =C2=A0 =C2=A0 --p---<br>
&gt; 1110.5<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 I got the gdbserver-xen later and run &#39;gdbserver-xen=
<br>
</div>&gt; 127.0.0.1:9999--attach 5&#39;(5 is the domid). Next, run &#39;gd=
b<br>
<div class=3D"im">&gt; /path/to/minios/exefile&#39;, and<br>
&gt; then &#39;bt&#39; in gdb, but no stack info.<br>
&gt; =C2=A0 =C2=A0 thanks in advance for your help.<br>
<br>
</div>Hmmm... I think that you forgot to connect to gdbserver-xen.<br>
Run following command from gdb: target remote :9999<br>
and do not forget compile mini-os with symbols.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Daniel<br>
</font></span></blockquote></div>Thanks=EF=BC=8CI&#39;ll have a try.</div><=
div class=3D"gmail_extra">I&#39;m not clear about compiling mini-os with sy=
mbols, does it make sense that specifing the /path/to/minios-source in gdb =
cmd line and the gdb would find the symbols infomation automatically?</div>

--20cf300fb10141226304be0a2b84--


--===============2268081605954366885==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2268081605954366885==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 16:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 16:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKu0n-0000OW-Eg; Thu, 19 Apr 2012 16:15:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singh.rahul.1983@gmail.com>) id 1SKu0m-0000OO-3P
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 16:15:12 +0000
Received: from [193.109.254.147:42989] by server-3.bemta-14.messagelabs.com id
	39/29-23274-F0A309F4; Thu, 19 Apr 2012 16:15:11 +0000
X-Env-Sender: singh.rahul.1983@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334852107!5342841!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24914 invoked from network); 19 Apr 2012 16:15:08 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 16:15:08 -0000
Received: by qcsc20 with SMTP id c20so6607327qcs.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 09:15:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:to:mime-version:x-mailer;
	bh=812XmWv7lWpf8naZbLlqMC8VUdWAeO0vjznovQxPJjo=;
	b=EbuivUFzxCauKUC4ZwJTcL8XcpMVY5G1ivZukVVKjSgGvCojT9GYCxb62mgyTQsEqi
	69nLXOnfvpIp14hRlEsp3ydIsc9+7Qa9k7AaLw+Aqv8mpf8k/gpIWsQLKyC0TrfvyT9h
	4//YbvhTJraGzDtrNGwd1gyk8yDDVEW5cOpgpQU7sLAXO7RpOOFw+R2c1vSP1+pfMh3o
	NAler23N8o06MUA5GrCRkBsT4ejjMUsUDtGikTGOY+cggdeZm1QeJB6huPBhiMLSm0dv
	3zN9zTGPatnK85QP4JZczq7hL+76u8w3JSaml3vVM0p3/0LcXJqEbO4Z9nkIlLmboi+G
	PIQA==
Received: by 10.224.181.69 with SMTP id bx5mr3855657qab.49.1334852107221;
	Thu, 19 Apr 2012 09:15:07 -0700 (PDT)
Received: from moblix.cs.umass.edu (moblix.cs.umass.edu. [128.119.245.142])
	by mx.google.com with ESMTPS id gy2sm5039868qab.10.2012.04.19.09.15.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 09:15:05 -0700 (PDT)
From: Rahul Singh <singh.rahul.1983@gmail.com>
Date: Thu, 19 Apr 2012 12:15:04 -0400
Message-Id: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1277151006610879404=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1277151006610879404==
Content-Type: multipart/alternative; boundary=Apple-Mail-8-62619066


--Apple-Mail-8-62619066
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,
I am trying to understand and change the network buffering that is being =
used by Remus, the HA solution present in Xen. =46rom what i understood =
from reading the code, Remus calls the postsuspend method of the =
BufferedNIC after it suspends the domain that sends TC_PLUG_CHECKPOINT =
message and start the buffering and then calls the commit method of =
BufferedNIC after it gets the acknowledgement that sends the =
TC_PLUG_RELEASE message and releases the buffered packets. I have the =
following doubts
1) How does remus ensure that the packets gets buffered for an entire =
epoch ?
2) If i comment out the lines in the "postsuspend" and "commit" lines of =
the BufferedNIC class that send the TC_PLUG_CHECKPOINT and =
TC_PLUG_RELEASE, i see that all the network packets are being buffered =
and i cannot ping the Remus-protected VM at all. Where is the packet  =
buffering happen if i comment out these 2 lines ?

Thanking you,
Rahul.=

--Apple-Mail-8-62619066
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="content" id="post-content-1421029"><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. From what i understood from reading the code, Remus 
calls the postsuspend method of the BufferedNIC after it suspends the 
domain that sends TC_PLUG_CHECKPOINT message and start the buffering and
 then calls the commit method of BufferedNIC after it gets the 
acknowledgement that sends the TC_PLUG_RELEASE message and releases the 
buffered packets. I have the following doubts<br>
1) How does remus ensure that the packets gets buffered for an entire epoch ?<br>
2) If i comment out the lines in the "postsuspend" and "commit" lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and 
TC_PLUG_RELEASE, i see that all the network packets are being buffered 
and i cannot ping the Remus-protected VM at all. Where is the packet 
buffering happen if i comment out these 2 lines ?</p><p>Thanking you,<br>
Rahul.</p></div></body></html>
--Apple-Mail-8-62619066--


--===============1277151006610879404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1277151006610879404==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 16:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 16:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKu0n-0000OW-Eg; Thu, 19 Apr 2012 16:15:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singh.rahul.1983@gmail.com>) id 1SKu0m-0000OO-3P
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 16:15:12 +0000
Received: from [193.109.254.147:42989] by server-3.bemta-14.messagelabs.com id
	39/29-23274-F0A309F4; Thu, 19 Apr 2012 16:15:11 +0000
X-Env-Sender: singh.rahul.1983@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334852107!5342841!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24914 invoked from network); 19 Apr 2012 16:15:08 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 16:15:08 -0000
Received: by qcsc20 with SMTP id c20so6607327qcs.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 09:15:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:to:mime-version:x-mailer;
	bh=812XmWv7lWpf8naZbLlqMC8VUdWAeO0vjznovQxPJjo=;
	b=EbuivUFzxCauKUC4ZwJTcL8XcpMVY5G1ivZukVVKjSgGvCojT9GYCxb62mgyTQsEqi
	69nLXOnfvpIp14hRlEsp3ydIsc9+7Qa9k7AaLw+Aqv8mpf8k/gpIWsQLKyC0TrfvyT9h
	4//YbvhTJraGzDtrNGwd1gyk8yDDVEW5cOpgpQU7sLAXO7RpOOFw+R2c1vSP1+pfMh3o
	NAler23N8o06MUA5GrCRkBsT4ejjMUsUDtGikTGOY+cggdeZm1QeJB6huPBhiMLSm0dv
	3zN9zTGPatnK85QP4JZczq7hL+76u8w3JSaml3vVM0p3/0LcXJqEbO4Z9nkIlLmboi+G
	PIQA==
Received: by 10.224.181.69 with SMTP id bx5mr3855657qab.49.1334852107221;
	Thu, 19 Apr 2012 09:15:07 -0700 (PDT)
Received: from moblix.cs.umass.edu (moblix.cs.umass.edu. [128.119.245.142])
	by mx.google.com with ESMTPS id gy2sm5039868qab.10.2012.04.19.09.15.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 09:15:05 -0700 (PDT)
From: Rahul Singh <singh.rahul.1983@gmail.com>
Date: Thu, 19 Apr 2012 12:15:04 -0400
Message-Id: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1277151006610879404=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1277151006610879404==
Content-Type: multipart/alternative; boundary=Apple-Mail-8-62619066


--Apple-Mail-8-62619066
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,
I am trying to understand and change the network buffering that is being =
used by Remus, the HA solution present in Xen. =46rom what i understood =
from reading the code, Remus calls the postsuspend method of the =
BufferedNIC after it suspends the domain that sends TC_PLUG_CHECKPOINT =
message and start the buffering and then calls the commit method of =
BufferedNIC after it gets the acknowledgement that sends the =
TC_PLUG_RELEASE message and releases the buffered packets. I have the =
following doubts
1) How does remus ensure that the packets gets buffered for an entire =
epoch ?
2) If i comment out the lines in the "postsuspend" and "commit" lines of =
the BufferedNIC class that send the TC_PLUG_CHECKPOINT and =
TC_PLUG_RELEASE, i see that all the network packets are being buffered =
and i cannot ping the Remus-protected VM at all. Where is the packet  =
buffering happen if i comment out these 2 lines ?

Thanking you,
Rahul.=

--Apple-Mail-8-62619066
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="content" id="post-content-1421029"><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. From what i understood from reading the code, Remus 
calls the postsuspend method of the BufferedNIC after it suspends the 
domain that sends TC_PLUG_CHECKPOINT message and start the buffering and
 then calls the commit method of BufferedNIC after it gets the 
acknowledgement that sends the TC_PLUG_RELEASE message and releases the 
buffered packets. I have the following doubts<br>
1) How does remus ensure that the packets gets buffered for an entire epoch ?<br>
2) If i comment out the lines in the "postsuspend" and "commit" lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and 
TC_PLUG_RELEASE, i see that all the network packets are being buffered 
and i cannot ping the Remus-protected VM at all. Where is the packet 
buffering happen if i comment out these 2 lines ?</p><p>Thanking you,<br>
Rahul.</p></div></body></html>
--Apple-Mail-8-62619066--


--===============1277151006610879404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1277151006610879404==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 17:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 17:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKuqe-0000wN-OP; Thu, 19 Apr 2012 17:08:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKuqc-0000wG-UW
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 17:08:47 +0000
Received: from [85.158.139.83:52589] by server-9.bemta-5.messagelabs.com id
	F1/CE-09826-E96409F4; Thu, 19 Apr 2012 17:08:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334855324!24638742!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 19 Apr 2012 17:08:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 17:08:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKuqX-0007ed-0a; Thu, 19 Apr 2012 17:08:41 +0000
Date: Thu, 19 Apr 2012 18:08:40 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120419170840.GD23663@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="zx4FCpZtqtKETZ7O"
Content-Disposition: inline
In-Reply-To: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Gianluca Guida <glguida@gmail.com>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
> After a hvm+shadow domain dies (either clean shutdown or merciless
> destroy), the domain is left in a zombie state with 1 (one) page left
> dangling with a single reference.

The reference is to the top-level pagetable that was pointed to by CR3
when the domain was killed.  This bug came in with:

 changeset:   23142:f5e8d152a565
 user:        Jan Beulich <jbeulich@novell.com>
 date:        Tue Apr 05 13:01:25 2011 +0100
 description: x86: split struct vcpu

where HVM domains no longer have vcpu_destroy_pagetables(v) called on
their VCPUs as they die.  Proposed fix attached.

Cheers,

Tim.

--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=guest-table-ref

x86: restore vcpu_destroy_pagetables() call on HVM domain teardown.

HVM vcpus that are using shadow pagetables have valid guest_table fields,
which need to be tidied up on domain teardown.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 29e4f8cefc5a -r e67b344afe8e xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Thu Apr 19 15:48:30 2012 +0100
+++ b/xen/arch/x86/domain.c	Thu Apr 19 18:04:29 2012 +0100
@@ -2105,13 +2105,14 @@ int domain_relinquish_resources(struct d
         /* Tear down paging-assistance stuff. */
         paging_teardown(d);
 
+        /* Drop the in-use references to page-table bases. */
+        for_each_vcpu ( d, v )
+            vcpu_destroy_pagetables(v);
+
         if ( !is_hvm_domain(d) )
         {
             for_each_vcpu ( d, v )
             {
-                /* Drop the in-use references to page-table bases. */
-                vcpu_destroy_pagetables(v);
-
                 /*
                  * Relinquish GDT mappings. No need for explicit unmapping of
                  * the LDT as it automatically gets squashed with the guest

--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--zx4FCpZtqtKETZ7O--


From xen-devel-bounces@lists.xen.org Thu Apr 19 17:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 17:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKuqe-0000wN-OP; Thu, 19 Apr 2012 17:08:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SKuqc-0000wG-UW
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 17:08:47 +0000
Received: from [85.158.139.83:52589] by server-9.bemta-5.messagelabs.com id
	F1/CE-09826-E96409F4; Thu, 19 Apr 2012 17:08:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334855324!24638742!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 19 Apr 2012 17:08:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 17:08:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SKuqX-0007ed-0a; Thu, 19 Apr 2012 17:08:41 +0000
Date: Thu, 19 Apr 2012 18:08:40 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120419170840.GD23663@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="zx4FCpZtqtKETZ7O"
Content-Disposition: inline
In-Reply-To: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Gianluca Guida <glguida@gmail.com>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
> After a hvm+shadow domain dies (either clean shutdown or merciless
> destroy), the domain is left in a zombie state with 1 (one) page left
> dangling with a single reference.

The reference is to the top-level pagetable that was pointed to by CR3
when the domain was killed.  This bug came in with:

 changeset:   23142:f5e8d152a565
 user:        Jan Beulich <jbeulich@novell.com>
 date:        Tue Apr 05 13:01:25 2011 +0100
 description: x86: split struct vcpu

where HVM domains no longer have vcpu_destroy_pagetables(v) called on
their VCPUs as they die.  Proposed fix attached.

Cheers,

Tim.

--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=guest-table-ref

x86: restore vcpu_destroy_pagetables() call on HVM domain teardown.

HVM vcpus that are using shadow pagetables have valid guest_table fields,
which need to be tidied up on domain teardown.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 29e4f8cefc5a -r e67b344afe8e xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Thu Apr 19 15:48:30 2012 +0100
+++ b/xen/arch/x86/domain.c	Thu Apr 19 18:04:29 2012 +0100
@@ -2105,13 +2105,14 @@ int domain_relinquish_resources(struct d
         /* Tear down paging-assistance stuff. */
         paging_teardown(d);
 
+        /* Drop the in-use references to page-table bases. */
+        for_each_vcpu ( d, v )
+            vcpu_destroy_pagetables(v);
+
         if ( !is_hvm_domain(d) )
         {
             for_each_vcpu ( d, v )
             {
-                /* Drop the in-use references to page-table bases. */
-                vcpu_destroy_pagetables(v);
-
                 /*
                  * Relinquish GDT mappings. No need for explicit unmapping of
                  * the LDT as it automatically gets squashed with the guest

--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--zx4FCpZtqtKETZ7O--


From xen-devel-bounces@lists.xen.org Thu Apr 19 18:54:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 18:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKwU2-0003PX-OL; Thu, 19 Apr 2012 18:53:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SKwU1-0003PS-5Q
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 18:53:33 +0000
Received: from [85.158.138.51:8223] by server-1.bemta-3.messagelabs.com id
	FA/EF-11491-C2F509F4; Thu, 19 Apr 2012 18:53:32 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334861610!18743837!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1878 invoked from network); 19 Apr 2012 18:53:31 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 18:53:31 -0000
Received: by qabg40 with SMTP id g40so94389qab.11
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 11:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=TCCHxoCUianTHZXbWLA+zTD4PImXSgosrjhGIp9oCcM=;
	b=Tb/bFjvrfp2tSTcHCeooTMswQ+u1Ydooia7ZSEuYbMkWOXvzDYy37QkUMz2Vmzl+gL
	PoyeDdFOvTdJI49u90Vfsea/CewlCpujsPyrqrGPtOt/aOEvIB/otNrm7gKqc0baq4e6
	NRjhtKgcoqUn5U0DKTBBiNVRrzygkGvtKcHE6+SxJbcSw5eS/kS+eWTxKhCXK0P071Ny
	9UYUu5qS3cqtFgMHEOmOupjnWZ+wLR/sxOUn7eEbGIkSg6rFqZGuribkvwmr3ysqXggc
	q+N/sUeDEfRyqkOOHW8T7bGjjw62zMsjbivWRSeFPxbAJmFM76B6t0y4jawL1yYjD+LV
	oFnw==
MIME-Version: 1.0
Received: by 10.224.211.9 with SMTP id gm9mr4596458qab.78.1334861609473; Thu,
	19 Apr 2012 11:53:29 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Thu, 19 Apr 2012 11:53:29 -0700 (PDT)
In-Reply-To: <CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
	<1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
	<CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
Date: Thu, 19 Apr 2012 11:53:29 -0700
Message-ID: <CAGU+auuMNdsTmtzW=eUzdjBQJp8w2Gpn0rVk2YVQBP_hsFzTAQ@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: andres@lagarcavilla.org
Cc: JBeulich@suse.com, ian.campbell@citrix.com, Santosh.Jodh@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 1:59 PM, AP <apxeng@gmail.com> wrote:
> On Tue, Apr 17, 2012 at 8:56 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>>>
>>> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>>>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>>>> told me to change all others while I was in there.
>>>
>>> Oh, right, I remember now.
>>>
>>> Given that reverting it for this case will still leave the same issue
>>> for the grant case (which I'd forgotten about) I suppose the appropriate
>>> workaround is to touch the alloca'd memory in the appropriate order in
>>> all cases (perhaps with an alloca helper macro).
>>
>> FWIW, I am very skeptical about this whole alloca business. It's very ve=
ry
>> dangerous, no surprise on the bug report. On my code I tend to map
>> arbitrarily-sized pfn arrays, and I've been thinking of disabling alloca.
>>
>> If your only safeguard is to put a loop that touches everything so the
>> stack gets allocated .... then what's your gain?
>>
>> Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
>> round_to_page_size(what_you_need)). That's likely the fastest way to get
>> the array in Linux. It isn't that slow either. And it's safe.
>
> I tried and it worked for me.
>
> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -34,16 +34,17 @@
> =A0#include <xen/memory.h>
> =A0#include <xen/sys/evtchn.h>
> =A0#include <xen/sys/gntdev.h>
> =A0#include <xen/sys/gntalloc.h>
>
> =A0#include "xenctrl.h"
> =A0#include "xenctrlosdep.h"
>
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_=
w))-1))
> =A0#define ERROR(_m, _a...)
> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
> =A0#define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR=
,_m \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " (%d =3D %s)", ## _a , errno, xc_str=
error(xch, errno))
>
> =A0static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
> =A0{
> =A0 =A0 int flags, saved_errno;
> =A0 =A0 int fd =3D open("/proc/xen/privcmd", O_RDWR);
> @@ -281,17 +282,24 @@ static void *linux_privcmd_map_foreign_b
> =A0 =A0 /* Command was not recognized, use fall back */
> =A0 =A0 else if ( rc < 0 && errno =3D=3D EINVAL && (int)num > 0 )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 /*
> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall b=
ack to
> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH.
> =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 privcmd_mmapbatch_t ioctlx;
> - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
> + =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((num * sizeof(*pfn=
)),
> XC_PAGE_SHIFT),
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PROT_READ | =
PROT_WRITE,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MAP_PRIVATE =
| MAP_ANON | MAP_POPULATE, -1, 0);
> + =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap of pfn array f=
ailed");
> + =A0 =A0 =A0 =A0 =A0 =A0return NULL;
> + =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 memcpy(pfn, arr, num * sizeof(*arr));
>
> =A0 =A0 =A0 =A0 ioctlx.num =3D num;
> =A0 =A0 =A0 =A0 ioctlx.dom =3D dom;
> =A0 =A0 =A0 =A0 ioctlx.addr =3D (unsigned long)addr;
> =A0 =A0 =A0 =A0 ioctlx.arr =3D pfn;
>
> @@ -323,16 +331,18 @@ static void *linux_privcmd_map_foreign_b
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -ENOENT;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 }
>
> + =A0 =A0 =A0 =A0munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT)=
);
> +
> =A0 =A0 =A0 =A0 if ( rc =3D=3D -ENOENT && i =3D=3D num )
> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D 0;
> =A0 =A0 =A0 =A0 else if ( rc )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 errno =3D -rc;
> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -1;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>

Just wondering what is the consensus on this? Is the mmap() method
acceptable? Should I go ahead and submit this as a patch?

Thanks,
AP

>> Andres
>>
>>>
>>> Ian.
>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>> Sent: Tuesday, April 17, 2012 12:56 AM
>>>> To: Ian Campbell; AP
>>>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>>>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>>>> causing segfault
>>>>
>>>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>>>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>>>> >> amounts of pages (in the GB range) from a guest in to Dom0
>>>> >
>>>> > Out of interest -- what are you doing this for?
>>>> >
>>>> >> =A0using
>>>> >> xc_map_foreign_bulk() I am hitting a segfault.
>>>> >>
>>>> >> Program received signal SIGSEGV, Segmentation fault.
>>>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x60505=
0,
>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>> arr=3D0x7ffff6bf5010,
>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>> >> 52 =A0 =A0 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src,=
 __len, __bos0
>>>> (__dest));
>>>> >> (gdb) bt
>>>> >> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>>> (xch=3D0x605050,
>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>> arr=3D0x7ffff6bf5010,
>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>> >> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized o=
ut>,
>>>> >> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<optim=
ized out>,
>>>> >> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at
>>>> >> xc_foreign_memory.c:79
>>>> >>
>>>> >> This was working for me with Xen 4.1.2. On comparing
>>>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>>>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>>>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>>>> >> blowing the stack with the call.
>>>> >
>>>> > I bet this is due to Linux's stack guard page. This means that if you
>>>> > try and increase the stack by more than ~1 page you skip entirely ov=
er
>>>> > the "next" stack page and into the guard.
>>>> >
>>>> > Does it help if after the alloca you add a loop which touches the
>>>> > first word of each page of the new buffer? Since the stack grows down
>>>> > you might actually need to do it backwards from the end of the array
>>>> > in order to start at the end which is nearest the existing stack?
>>>> > (it's before coffee o'clock so thinking about stack direction isn't =
my
>>>> > strong point yet...)
>>>>
>>>> This should really be done by the alloca() implementation itself -
>>>> anything else is a bug.
>>>>
>>>> > The switch to alloca was made recently in order to optimise the
>>>> > hotpath for a userspace I/O backend.
>>>>
>>>> Probably this should be made size-dependent ...
>>>>
>>>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>>>> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath
>>>> > operations should really be grant table ops, a backend shouldn't be
>>>> > relying on the privileges accorded to dom0 -- for one thing it should
>>>> > be expected to work in a driver domain.
>>>>
>>>> ... if this indeed turns out to be a hot path for something at all?
>>>>
>>>> Jan
>>>>
>>>> >> =A0If I replace the alloca() with malloc() the call goes through. W=
hat
>>>> >> is the way around this? Should I be using
>>>> >> xc_map_foreign_batch() instead, which I think is deprecated? Please
>>>> >> advice...
>>>> >>
>>>> >> Thanks,
>>>> >> AP
>>>> >>
>>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 18:54:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 18:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKwU2-0003PX-OL; Thu, 19 Apr 2012 18:53:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SKwU1-0003PS-5Q
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 18:53:33 +0000
Received: from [85.158.138.51:8223] by server-1.bemta-3.messagelabs.com id
	FA/EF-11491-C2F509F4; Thu, 19 Apr 2012 18:53:32 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334861610!18743837!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1878 invoked from network); 19 Apr 2012 18:53:31 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 18:53:31 -0000
Received: by qabg40 with SMTP id g40so94389qab.11
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 11:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=TCCHxoCUianTHZXbWLA+zTD4PImXSgosrjhGIp9oCcM=;
	b=Tb/bFjvrfp2tSTcHCeooTMswQ+u1Ydooia7ZSEuYbMkWOXvzDYy37QkUMz2Vmzl+gL
	PoyeDdFOvTdJI49u90Vfsea/CewlCpujsPyrqrGPtOt/aOEvIB/otNrm7gKqc0baq4e6
	NRjhtKgcoqUn5U0DKTBBiNVRrzygkGvtKcHE6+SxJbcSw5eS/kS+eWTxKhCXK0P071Ny
	9UYUu5qS3cqtFgMHEOmOupjnWZ+wLR/sxOUn7eEbGIkSg6rFqZGuribkvwmr3ysqXggc
	q+N/sUeDEfRyqkOOHW8T7bGjjw62zMsjbivWRSeFPxbAJmFM76B6t0y4jawL1yYjD+LV
	oFnw==
MIME-Version: 1.0
Received: by 10.224.211.9 with SMTP id gm9mr4596458qab.78.1334861609473; Thu,
	19 Apr 2012 11:53:29 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Thu, 19 Apr 2012 11:53:29 -0700 (PDT)
In-Reply-To: <CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
	<1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
	<CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
Date: Thu, 19 Apr 2012 11:53:29 -0700
Message-ID: <CAGU+auuMNdsTmtzW=eUzdjBQJp8w2Gpn0rVk2YVQBP_hsFzTAQ@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: andres@lagarcavilla.org
Cc: JBeulich@suse.com, ian.campbell@citrix.com, Santosh.Jodh@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 17, 2012 at 1:59 PM, AP <apxeng@gmail.com> wrote:
> On Tue, Apr 17, 2012 at 8:56 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>>>
>>> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>>>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>>>> told me to change all others while I was in there.
>>>
>>> Oh, right, I remember now.
>>>
>>> Given that reverting it for this case will still leave the same issue
>>> for the grant case (which I'd forgotten about) I suppose the appropriate
>>> workaround is to touch the alloca'd memory in the appropriate order in
>>> all cases (perhaps with an alloca helper macro).
>>
>> FWIW, I am very skeptical about this whole alloca business. It's very ve=
ry
>> dangerous, no surprise on the bug report. On my code I tend to map
>> arbitrarily-sized pfn arrays, and I've been thinking of disabling alloca.
>>
>> If your only safeguard is to put a loop that touches everything so the
>> stack gets allocated .... then what's your gain?
>>
>> Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
>> round_to_page_size(what_you_need)). That's likely the fastest way to get
>> the array in Linux. It isn't that slow either. And it's safe.
>
> I tried and it worked for me.
>
> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -34,16 +34,17 @@
> =A0#include <xen/memory.h>
> =A0#include <xen/sys/evtchn.h>
> =A0#include <xen/sys/gntdev.h>
> =A0#include <xen/sys/gntalloc.h>
>
> =A0#include "xenctrl.h"
> =A0#include "xenctrlosdep.h"
>
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_=
w))-1))
> =A0#define ERROR(_m, _a...)
> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
> =A0#define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR=
,_m \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " (%d =3D %s)", ## _a , errno, xc_str=
error(xch, errno))
>
> =A0static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
> =A0{
> =A0 =A0 int flags, saved_errno;
> =A0 =A0 int fd =3D open("/proc/xen/privcmd", O_RDWR);
> @@ -281,17 +282,24 @@ static void *linux_privcmd_map_foreign_b
> =A0 =A0 /* Command was not recognized, use fall back */
> =A0 =A0 else if ( rc < 0 && errno =3D=3D EINVAL && (int)num > 0 )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 /*
> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall b=
ack to
> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH.
> =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 privcmd_mmapbatch_t ioctlx;
> - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
> + =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((num * sizeof(*pfn=
)),
> XC_PAGE_SHIFT),
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PROT_READ | =
PROT_WRITE,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MAP_PRIVATE =
| MAP_ANON | MAP_POPULATE, -1, 0);
> + =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap of pfn array f=
ailed");
> + =A0 =A0 =A0 =A0 =A0 =A0return NULL;
> + =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 memcpy(pfn, arr, num * sizeof(*arr));
>
> =A0 =A0 =A0 =A0 ioctlx.num =3D num;
> =A0 =A0 =A0 =A0 ioctlx.dom =3D dom;
> =A0 =A0 =A0 =A0 ioctlx.addr =3D (unsigned long)addr;
> =A0 =A0 =A0 =A0 ioctlx.arr =3D pfn;
>
> @@ -323,16 +331,18 @@ static void *linux_privcmd_map_foreign_b
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -ENOENT;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 }
>
> + =A0 =A0 =A0 =A0munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT)=
);
> +
> =A0 =A0 =A0 =A0 if ( rc =3D=3D -ENOENT && i =3D=3D num )
> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D 0;
> =A0 =A0 =A0 =A0 else if ( rc )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 errno =3D -rc;
> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -1;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>

Just wondering what is the consensus on this? Is the mmap() method
acceptable? Should I go ahead and submit this as a patch?

Thanks,
AP

>> Andres
>>
>>>
>>> Ian.
>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>> Sent: Tuesday, April 17, 2012 12:56 AM
>>>> To: Ian Campbell; AP
>>>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>>>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>>>> causing segfault
>>>>
>>>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>>>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>>>> >> amounts of pages (in the GB range) from a guest in to Dom0
>>>> >
>>>> > Out of interest -- what are you doing this for?
>>>> >
>>>> >> =A0using
>>>> >> xc_map_foreign_bulk() I am hitting a segfault.
>>>> >>
>>>> >> Program received signal SIGSEGV, Segmentation fault.
>>>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=3D0x60505=
0,
>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>> arr=3D0x7ffff6bf5010,
>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>> >> 52 =A0 =A0 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src,=
 __len, __bos0
>>>> (__dest));
>>>> >> (gdb) bt
>>>> >> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>>> (xch=3D0x605050,
>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>> arr=3D0x7ffff6bf5010,
>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>> >> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized o=
ut>,
>>>> >> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<optim=
ized out>,
>>>> >> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at
>>>> >> xc_foreign_memory.c:79
>>>> >>
>>>> >> This was working for me with Xen 4.1.2. On comparing
>>>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>>>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>>>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>>>> >> blowing the stack with the call.
>>>> >
>>>> > I bet this is due to Linux's stack guard page. This means that if you
>>>> > try and increase the stack by more than ~1 page you skip entirely ov=
er
>>>> > the "next" stack page and into the guard.
>>>> >
>>>> > Does it help if after the alloca you add a loop which touches the
>>>> > first word of each page of the new buffer? Since the stack grows down
>>>> > you might actually need to do it backwards from the end of the array
>>>> > in order to start at the end which is nearest the existing stack?
>>>> > (it's before coffee o'clock so thinking about stack direction isn't =
my
>>>> > strong point yet...)
>>>>
>>>> This should really be done by the alloca() implementation itself -
>>>> anything else is a bug.
>>>>
>>>> > The switch to alloca was made recently in order to optimise the
>>>> > hotpath for a userspace I/O backend.
>>>>
>>>> Probably this should be made size-dependent ...
>>>>
>>>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>>>> > mmap doing on the hot path for the userspace I/O anyway? Most hotpath
>>>> > operations should really be grant table ops, a backend shouldn't be
>>>> > relying on the privileges accorded to dom0 -- for one thing it should
>>>> > be expected to work in a driver domain.
>>>>
>>>> ... if this indeed turns out to be a hot path for something at all?
>>>>
>>>> Jan
>>>>
>>>> >> =A0If I replace the alloca() with malloc() the call goes through. W=
hat
>>>> >> is the way around this? Should I be using
>>>> >> xc_map_foreign_batch() instead, which I think is deprecated? Please
>>>> >> advice...
>>>> >>
>>>> >> Thanks,
>>>> >> AP
>>>> >>
>>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 19:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 19:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKwhe-0003dD-Bf; Thu, 19 Apr 2012 19:07:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKwhc-0003d8-Qr
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 19:07:37 +0000
Received: from [85.158.138.51:43057] by server-2.bemta-3.messagelabs.com id
	E6/E5-09269-872609F4; Thu, 19 Apr 2012 19:07:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334862453!22789923!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjQy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12542 invoked from network); 19 Apr 2012 19:07:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 19:07:35 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JJ7NIa017669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 19:07:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JJ7KB0007917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 19:07:20 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JJ7GR9005844; Thu, 19 Apr 2012 14:07:16 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 12:07:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C946740280; Thu, 19 Apr 2012 15:02:17 -0400 (EDT)
Date: Thu, 19 Apr 2012 15:02:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419190217.GA29124@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F90626E.0044,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 15, 2012 at 02:09:31PM +0800, Lin Ming wrote:
> From: Ben Guthro <ben@guthro.net>
> 
> Map native ipi vector to xen vector.
> Implement apic ipi interface with xen_send_IPI_one.

I keep on getting this (so PV guest without any SMP support,
and with just PV frontend drivers):


echo "CONFIG_PARAVIRT_GUEST=y" > linux.config
echo "CONFIG_XEN=y" >> linux.config
echo "CONFIG_XEN_XENBUS_FRONTEND=m" >> linux.config
cat xen.config | grep FRONTEND >> linux.config
echo "# CONFIG_XEN_PRIVILEGED_GUEST is not set" >> linux.config
echo "# CONFIG_XEN_DOM0 is not set" >> linux.config
echo "# CONFIG_ACPI is not set" >> linux.config
echo "# CONFIG_PCI is not set" >> linux.config
echo "# CONFIG_XENFS is not set" >> linux.config
echo "# CONFIG_SMP is not set" >> linux.config


make -j$((4 * 2)) -C /home/konrad/ssd/konrad/xtt-compile/linux O=/home/konrad/ssd/konrad/xtt-compile/linux-build- defconfig
make[2]: Entering directory `/home/konrad/ssd/konrad/linux'
  GEN     /home/konrad/ssd/konrad/xtt-compile/linux-build-/Makefile
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config

cat linux.config >> linux-build-/.config

make -j4 ..

  LD      init/built-in.o
  LD      .tmp_vmlinux1
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5a8): undefined reference to `xen_send_IPI_allbutself'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5b3): undefined reference to `xen_send_IPI_mask_allbutself'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5be): undefined reference to `xen_send_IPI_mask'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5c9): undefined reference to `xen_send_IPI_all'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5d4): undefined reference to `xen_send_IPI_self'
make[2]: *** [.tmp_vmlinux1] Error 1
> 
> Signed-off-by: Ben Guthro <ben@guthro.net>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
> 
> Ben,
> 
> This patch was taken from part of your patch at:
> https://lkml.org/lkml/2012/2/10/681
> 
> Is it OK that I added your SOB?
> 
> I did some change to map native ipi vector to xen vector.
> Could you please review?
> 
> Thanks.
> 
>  arch/x86/xen/enlighten.c |    7 ++++
>  arch/x86/xen/smp.c       |   81 +++++++++++++++++++++++++++++++++++++++++++--
>  arch/x86/xen/smp.h       |   12 +++++++
>  3 files changed, 96 insertions(+), 4 deletions(-)
>  create mode 100644 arch/x86/xen/smp.h
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 4f51beb..be7dbc8 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -74,6 +74,7 @@
>  
>  #include "xen-ops.h"
>  #include "mmu.h"
> +#include "smp.h"
>  #include "multicalls.h"
>  
>  EXPORT_SYMBOL_GPL(hypercall_page);
> @@ -849,6 +850,12 @@ static void set_xen_basic_apic_ops(void)
>  	apic->icr_write = xen_apic_icr_write;
>  	apic->wait_icr_idle = xen_apic_wait_icr_idle;
>  	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
> +
> +	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
> +	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
> +	apic->send_IPI_mask = xen_send_IPI_mask;
> +	apic->send_IPI_all = xen_send_IPI_all;
> +	apic->send_IPI_self = xen_send_IPI_self;
>  }
>  
>  #endif
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 5fac691..2dc6628 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -465,8 +465,8 @@ static void xen_smp_send_reschedule(int cpu)
>  	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
>  }
>  
> -static void xen_send_IPI_mask(const struct cpumask *mask,
> -			      enum ipi_vector vector)
> +static void __xen_send_IPI_mask(const struct cpumask *mask,
> +			      int vector)
>  {
>  	unsigned cpu;
>  
> @@ -478,7 +478,7 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
>  {
>  	int cpu;
>  
> -	xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
> +	__xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
>  
>  	/* Make sure other vcpus get a chance to run if they need to. */
>  	for_each_cpu(cpu, mask) {
> @@ -491,10 +491,83 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
>  
>  static void xen_smp_send_call_function_single_ipi(int cpu)
>  {
> -	xen_send_IPI_mask(cpumask_of(cpu),
> +	__xen_send_IPI_mask(cpumask_of(cpu),
>  			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
>  }
>  
> +static inline int xen_map_vector(int vector)
> +{
> +	int xen_vector;
> +
> +	switch (vector) {
> +	case RESCHEDULE_VECTOR:
> +		xen_vector = XEN_RESCHEDULE_VECTOR;
> +		break;
> +	case CALL_FUNCTION_VECTOR:
> +		xen_vector = XEN_CALL_FUNCTION_VECTOR;
> +		break;
> +	case CALL_FUNCTION_SINGLE_VECTOR:
> +		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
> +		break;
> +	default:
> +		xen_vector = -1;
> +		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
> +			vector);
> +	}
> +
> +	return xen_vector;
> +}
> +
> +void xen_send_IPI_mask(const struct cpumask *mask,
> +			      int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		__xen_send_IPI_mask(mask, xen_vector);
> +}
> +
> +void xen_send_IPI_all(int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		__xen_send_IPI_mask(cpu_online_mask, xen_vector);
> +}
> +
> +void xen_send_IPI_self(int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		xen_send_IPI_one(smp_processor_id(), xen_vector);
> +}
> +
> +void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> +				int vector)
> +{
> +	unsigned cpu;
> +	unsigned int this_cpu = smp_processor_id();
> +
> +	if (!(num_online_cpus() > 1))
> +		return;
> +
> +	for_each_cpu_and(cpu, mask, cpu_online_mask) {
> +		if (this_cpu == cpu)
> +			continue;
> +
> +		xen_smp_send_call_function_single_ipi(cpu);
> +	}
> +}
> +
> +void xen_send_IPI_allbutself(int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
> +}
> +
>  static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
>  {
>  	irq_enter();
> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
> new file mode 100644
> index 0000000..8981a76
> --- /dev/null
> +++ b/arch/x86/xen/smp.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_SMP_H
> +
> +extern void xen_send_IPI_mask(const struct cpumask *mask,
> +			      int vector);
> +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> +				int vector);
> +extern void xen_send_IPI_allbutself(int vector);
> +extern void physflat_send_IPI_allbutself(int vector);
> +extern void xen_send_IPI_all(int vector);
> +extern void xen_send_IPI_self(int vector);
> +
> +#endif
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 19:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 19:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKwhe-0003dD-Bf; Thu, 19 Apr 2012 19:07:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKwhc-0003d8-Qr
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 19:07:37 +0000
Received: from [85.158.138.51:43057] by server-2.bemta-3.messagelabs.com id
	E6/E5-09269-872609F4; Thu, 19 Apr 2012 19:07:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334862453!22789923!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjQy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12542 invoked from network); 19 Apr 2012 19:07:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 19:07:35 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JJ7NIa017669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 19:07:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JJ7KB0007917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 19:07:20 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JJ7GR9005844; Thu, 19 Apr 2012 14:07:16 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 12:07:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C946740280; Thu, 19 Apr 2012 15:02:17 -0400 (EDT)
Date: Thu, 19 Apr 2012 15:02:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419190217.GA29124@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F90626E.0044,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 15, 2012 at 02:09:31PM +0800, Lin Ming wrote:
> From: Ben Guthro <ben@guthro.net>
> 
> Map native ipi vector to xen vector.
> Implement apic ipi interface with xen_send_IPI_one.

I keep on getting this (so PV guest without any SMP support,
and with just PV frontend drivers):


echo "CONFIG_PARAVIRT_GUEST=y" > linux.config
echo "CONFIG_XEN=y" >> linux.config
echo "CONFIG_XEN_XENBUS_FRONTEND=m" >> linux.config
cat xen.config | grep FRONTEND >> linux.config
echo "# CONFIG_XEN_PRIVILEGED_GUEST is not set" >> linux.config
echo "# CONFIG_XEN_DOM0 is not set" >> linux.config
echo "# CONFIG_ACPI is not set" >> linux.config
echo "# CONFIG_PCI is not set" >> linux.config
echo "# CONFIG_XENFS is not set" >> linux.config
echo "# CONFIG_SMP is not set" >> linux.config


make -j$((4 * 2)) -C /home/konrad/ssd/konrad/xtt-compile/linux O=/home/konrad/ssd/konrad/xtt-compile/linux-build- defconfig
make[2]: Entering directory `/home/konrad/ssd/konrad/linux'
  GEN     /home/konrad/ssd/konrad/xtt-compile/linux-build-/Makefile
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config

cat linux.config >> linux-build-/.config

make -j4 ..

  LD      init/built-in.o
  LD      .tmp_vmlinux1
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5a8): undefined reference to `xen_send_IPI_allbutself'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5b3): undefined reference to `xen_send_IPI_mask_allbutself'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5be): undefined reference to `xen_send_IPI_mask'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5c9): undefined reference to `xen_send_IPI_all'
arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0x5d4): undefined reference to `xen_send_IPI_self'
make[2]: *** [.tmp_vmlinux1] Error 1
> 
> Signed-off-by: Ben Guthro <ben@guthro.net>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
> 
> Ben,
> 
> This patch was taken from part of your patch at:
> https://lkml.org/lkml/2012/2/10/681
> 
> Is it OK that I added your SOB?
> 
> I did some change to map native ipi vector to xen vector.
> Could you please review?
> 
> Thanks.
> 
>  arch/x86/xen/enlighten.c |    7 ++++
>  arch/x86/xen/smp.c       |   81 +++++++++++++++++++++++++++++++++++++++++++--
>  arch/x86/xen/smp.h       |   12 +++++++
>  3 files changed, 96 insertions(+), 4 deletions(-)
>  create mode 100644 arch/x86/xen/smp.h
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 4f51beb..be7dbc8 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -74,6 +74,7 @@
>  
>  #include "xen-ops.h"
>  #include "mmu.h"
> +#include "smp.h"
>  #include "multicalls.h"
>  
>  EXPORT_SYMBOL_GPL(hypercall_page);
> @@ -849,6 +850,12 @@ static void set_xen_basic_apic_ops(void)
>  	apic->icr_write = xen_apic_icr_write;
>  	apic->wait_icr_idle = xen_apic_wait_icr_idle;
>  	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
> +
> +	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
> +	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
> +	apic->send_IPI_mask = xen_send_IPI_mask;
> +	apic->send_IPI_all = xen_send_IPI_all;
> +	apic->send_IPI_self = xen_send_IPI_self;
>  }
>  
>  #endif
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 5fac691..2dc6628 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -465,8 +465,8 @@ static void xen_smp_send_reschedule(int cpu)
>  	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
>  }
>  
> -static void xen_send_IPI_mask(const struct cpumask *mask,
> -			      enum ipi_vector vector)
> +static void __xen_send_IPI_mask(const struct cpumask *mask,
> +			      int vector)
>  {
>  	unsigned cpu;
>  
> @@ -478,7 +478,7 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
>  {
>  	int cpu;
>  
> -	xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
> +	__xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
>  
>  	/* Make sure other vcpus get a chance to run if they need to. */
>  	for_each_cpu(cpu, mask) {
> @@ -491,10 +491,83 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
>  
>  static void xen_smp_send_call_function_single_ipi(int cpu)
>  {
> -	xen_send_IPI_mask(cpumask_of(cpu),
> +	__xen_send_IPI_mask(cpumask_of(cpu),
>  			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
>  }
>  
> +static inline int xen_map_vector(int vector)
> +{
> +	int xen_vector;
> +
> +	switch (vector) {
> +	case RESCHEDULE_VECTOR:
> +		xen_vector = XEN_RESCHEDULE_VECTOR;
> +		break;
> +	case CALL_FUNCTION_VECTOR:
> +		xen_vector = XEN_CALL_FUNCTION_VECTOR;
> +		break;
> +	case CALL_FUNCTION_SINGLE_VECTOR:
> +		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
> +		break;
> +	default:
> +		xen_vector = -1;
> +		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
> +			vector);
> +	}
> +
> +	return xen_vector;
> +}
> +
> +void xen_send_IPI_mask(const struct cpumask *mask,
> +			      int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		__xen_send_IPI_mask(mask, xen_vector);
> +}
> +
> +void xen_send_IPI_all(int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		__xen_send_IPI_mask(cpu_online_mask, xen_vector);
> +}
> +
> +void xen_send_IPI_self(int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		xen_send_IPI_one(smp_processor_id(), xen_vector);
> +}
> +
> +void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> +				int vector)
> +{
> +	unsigned cpu;
> +	unsigned int this_cpu = smp_processor_id();
> +
> +	if (!(num_online_cpus() > 1))
> +		return;
> +
> +	for_each_cpu_and(cpu, mask, cpu_online_mask) {
> +		if (this_cpu == cpu)
> +			continue;
> +
> +		xen_smp_send_call_function_single_ipi(cpu);
> +	}
> +}
> +
> +void xen_send_IPI_allbutself(int vector)
> +{
> +	int xen_vector = xen_map_vector(vector);
> +
> +	if (xen_vector >= 0)
> +		xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
> +}
> +
>  static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
>  {
>  	irq_enter();
> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
> new file mode 100644
> index 0000000..8981a76
> --- /dev/null
> +++ b/arch/x86/xen/smp.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_SMP_H
> +
> +extern void xen_send_IPI_mask(const struct cpumask *mask,
> +			      int vector);
> +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> +				int vector);
> +extern void xen_send_IPI_allbutself(int vector);
> +extern void physflat_send_IPI_allbutself(int vector);
> +extern void xen_send_IPI_all(int vector);
> +extern void xen_send_IPI_self(int vector);
> +
> +#endif
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 19:16:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 19:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKwq0-0003ub-BC; Thu, 19 Apr 2012 19:16:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKwpy-0003uW-8E
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 19:16:14 +0000
Received: from [193.109.254.147:56331] by server-11.bemta-14.messagelabs.com
	id 65/90-05858-D74609F4; Thu, 19 Apr 2012 19:16:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334862970!5400150!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MjA1NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 19 Apr 2012 19:16:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 19:16:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JJG3F6032270
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 19:16:04 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JJG1sI029593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 19:16:01 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JJG0CL029562; Thu, 19 Apr 2012 14:16:00 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 12:16:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8FE3540280; Thu, 19 Apr 2012 15:11:01 -0400 (EDT)
Date: Thu, 19 Apr 2012 15:11:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419191101.GA22339@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
	<20120419190217.GA29124@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120419190217.GA29124@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F906475.0010,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 03:02:17PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 15, 2012 at 02:09:31PM +0800, Lin Ming wrote:
> > From: Ben Guthro <ben@guthro.net>
> > 
> > Map native ipi vector to xen vector.
> > Implement apic ipi interface with xen_send_IPI_one.
> 
> I keep on getting this (so PV guest without any SMP support,
> and with just PV frontend drivers):
> 
> 
> echo "CONFIG_PARAVIRT_GUEST=y" > linux.config
> echo "CONFIG_XEN=y" >> linux.config
> echo "CONFIG_XEN_XENBUS_FRONTEND=m" >> linux.config
> cat xen.config | grep FRONTEND >> linux.config
> echo "# CONFIG_XEN_PRIVILEGED_GUEST is not set" >> linux.config
> echo "# CONFIG_XEN_DOM0 is not set" >> linux.config
> echo "# CONFIG_ACPI is not set" >> linux.config
> echo "# CONFIG_PCI is not set" >> linux.config
> echo "# CONFIG_XENFS is not set" >> linux.config
> echo "# CONFIG_SMP is not set" >> linux.config
> 
> 
> make -j$((4 * 2)) -C /home/konrad/ssd/konrad/xtt-compile/linux O=/home/konrad/ssd/konrad/xtt-compile/linux-build- defconfig
> make[2]: Entering directory `/home/konrad/ssd/konrad/linux'
>   GEN     /home/konrad/ssd/konrad/xtt-compile/linux-build-/Makefile
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # configuration written to .config
> 
> cat linux.config >> linux-build-/.config
> 
> make -j4 ..
> 
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5a8): undefined reference to `xen_send_IPI_allbutself'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5b3): undefined reference to `xen_send_IPI_mask_allbutself'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5be): undefined reference to `xen_send_IPI_mask'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5c9): undefined reference to `xen_send_IPI_all'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5d4): undefined reference to `xen_send_IPI_self'
> make[2]: *** [.tmp_vmlinux1] Error 1

And this fixes it [feel free to squash it in the patch]


commit dc4e2feaef1d22f8c4a257755af52a0b24e55a54
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Apr 19 15:09:08 2012 -0400

    xen/smp: Fix compile issues if no CONFIG_SMP
    
    Fixes:
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5a8): undefined reference to `xen_send_IPI_allbutself'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5b3): undefined reference to `xen_send_IPI_mask_allbutself'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5be): undefined reference to `xen_send_IPI_mask'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5c9): undefined reference to `xen_send_IPI_all'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5d4): undefined reference to `xen_send_IPI_self'
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 20b3b23..9cf8f35 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -868,12 +868,13 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
-
+#ifdef CONFIG_SMP
 	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
 	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
 	apic->send_IPI_mask = xen_send_IPI_mask;
 	apic->send_IPI_all = xen_send_IPI_all;
 	apic->send_IPI_self = xen_send_IPI_self;
+#endif
 }
 
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 19:16:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 19:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKwq0-0003ub-BC; Thu, 19 Apr 2012 19:16:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKwpy-0003uW-8E
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 19:16:14 +0000
Received: from [193.109.254.147:56331] by server-11.bemta-14.messagelabs.com
	id 65/90-05858-D74609F4; Thu, 19 Apr 2012 19:16:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334862970!5400150!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MjA1NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 19 Apr 2012 19:16:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 19:16:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JJG3F6032270
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 19:16:04 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JJG1sI029593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 19:16:01 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JJG0CL029562; Thu, 19 Apr 2012 14:16:00 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 12:16:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8FE3540280; Thu, 19 Apr 2012 15:11:01 -0400 (EDT)
Date: Thu, 19 Apr 2012 15:11:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419191101.GA22339@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-2-git-send-email-mlin@ss.pku.edu.cn>
	<20120419190217.GA29124@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120419190217.GA29124@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F906475.0010,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 03:02:17PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 15, 2012 at 02:09:31PM +0800, Lin Ming wrote:
> > From: Ben Guthro <ben@guthro.net>
> > 
> > Map native ipi vector to xen vector.
> > Implement apic ipi interface with xen_send_IPI_one.
> 
> I keep on getting this (so PV guest without any SMP support,
> and with just PV frontend drivers):
> 
> 
> echo "CONFIG_PARAVIRT_GUEST=y" > linux.config
> echo "CONFIG_XEN=y" >> linux.config
> echo "CONFIG_XEN_XENBUS_FRONTEND=m" >> linux.config
> cat xen.config | grep FRONTEND >> linux.config
> echo "# CONFIG_XEN_PRIVILEGED_GUEST is not set" >> linux.config
> echo "# CONFIG_XEN_DOM0 is not set" >> linux.config
> echo "# CONFIG_ACPI is not set" >> linux.config
> echo "# CONFIG_PCI is not set" >> linux.config
> echo "# CONFIG_XENFS is not set" >> linux.config
> echo "# CONFIG_SMP is not set" >> linux.config
> 
> 
> make -j$((4 * 2)) -C /home/konrad/ssd/konrad/xtt-compile/linux O=/home/konrad/ssd/konrad/xtt-compile/linux-build- defconfig
> make[2]: Entering directory `/home/konrad/ssd/konrad/linux'
>   GEN     /home/konrad/ssd/konrad/xtt-compile/linux-build-/Makefile
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # configuration written to .config
> 
> cat linux.config >> linux-build-/.config
> 
> make -j4 ..
> 
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5a8): undefined reference to `xen_send_IPI_allbutself'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5b3): undefined reference to `xen_send_IPI_mask_allbutself'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5be): undefined reference to `xen_send_IPI_mask'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5c9): undefined reference to `xen_send_IPI_all'
> arch/x86/built-in.o: In function `xen_start_kernel':
> (.init.text+0x5d4): undefined reference to `xen_send_IPI_self'
> make[2]: *** [.tmp_vmlinux1] Error 1

And this fixes it [feel free to squash it in the patch]


commit dc4e2feaef1d22f8c4a257755af52a0b24e55a54
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Apr 19 15:09:08 2012 -0400

    xen/smp: Fix compile issues if no CONFIG_SMP
    
    Fixes:
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5a8): undefined reference to `xen_send_IPI_allbutself'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5b3): undefined reference to `xen_send_IPI_mask_allbutself'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5be): undefined reference to `xen_send_IPI_mask'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5c9): undefined reference to `xen_send_IPI_all'
    arch/x86/built-in.o: In function `xen_start_kernel':
    (.init.text+0x5d4): undefined reference to `xen_send_IPI_self'
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 20b3b23..9cf8f35 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -868,12 +868,13 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
-
+#ifdef CONFIG_SMP
 	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
 	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
 	apic->send_IPI_mask = xen_send_IPI_mask;
 	apic->send_IPI_all = xen_send_IPI_all;
 	apic->send_IPI_self = xen_send_IPI_self;
+#endif
 }
 
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 19:57:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 19:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxTU-0004av-9B; Thu, 19 Apr 2012 19:57:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKxTT-0004aq-CA
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 19:57:03 +0000
Received: from [85.158.143.35:50303] by server-3.bemta-4.messagelabs.com id
	B1/BD-05853-E0E609F4; Thu, 19 Apr 2012 19:57:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334865420!13213031!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjQy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2901 invoked from network); 19 Apr 2012 19:57:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 19:57:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JJuwHn032248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 19:56:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JJuvPg011296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 19:56:57 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JJuun2006356; Thu, 19 Apr 2012 14:56:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 12:56:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8617340280; Thu, 19 Apr 2012 15:51:58 -0400 (EDT)
Date: Thu, 19 Apr 2012 15:51:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Nitin Gupta <nitin.kobain@gmail.com>
Message-ID: <20120419195158.GA7204@phenom.dumpdata.com>
References: <CAESzvYSkCozGjRayO-kdZigA0LZawD+B=CibjpaT1ae00P0NMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAESzvYSkCozGjRayO-kdZigA0LZawD+B=CibjpaT1ae00P0NMQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F906E0B.0051,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen entry point and exit point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 02:18:07PM +0530, Nitin Gupta wrote:
> Hi,
> 
> I need to find the points where we enters into hypercall (for all the
> hypercalls) execution and from where we come out... from what i have
> understood entry-point is
> somewhere in arch/x86/x86_32/entry.S ...but  exactly where and what about
> exit point?

hypercall_page. The arch/x86/include/asm/xen/hypercall.h has the macros
for it.

When we come back it usually right after the call.
> 
>  --
> Nitin Gupta

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 19:57:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 19:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxTU-0004av-9B; Thu, 19 Apr 2012 19:57:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKxTT-0004aq-CA
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 19:57:03 +0000
Received: from [85.158.143.35:50303] by server-3.bemta-4.messagelabs.com id
	B1/BD-05853-E0E609F4; Thu, 19 Apr 2012 19:57:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334865420!13213031!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjQy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2901 invoked from network); 19 Apr 2012 19:57:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 19:57:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JJuwHn032248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 19:56:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JJuvPg011296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 19:56:57 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JJuun2006356; Thu, 19 Apr 2012 14:56:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 12:56:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8617340280; Thu, 19 Apr 2012 15:51:58 -0400 (EDT)
Date: Thu, 19 Apr 2012 15:51:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Nitin Gupta <nitin.kobain@gmail.com>
Message-ID: <20120419195158.GA7204@phenom.dumpdata.com>
References: <CAESzvYSkCozGjRayO-kdZigA0LZawD+B=CibjpaT1ae00P0NMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAESzvYSkCozGjRayO-kdZigA0LZawD+B=CibjpaT1ae00P0NMQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F906E0B.0051,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen entry point and exit point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 02:18:07PM +0530, Nitin Gupta wrote:
> Hi,
> 
> I need to find the points where we enters into hypercall (for all the
> hypercalls) execution and from where we come out... from what i have
> understood entry-point is
> somewhere in arch/x86/x86_32/entry.S ...but  exactly where and what about
> exit point?

hypercall_page. The arch/x86/include/asm/xen/hypercall.h has the macros
for it.

When we come back it usually right after the call.
> 
>  --
> Nitin Gupta

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 20:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 20:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxca-0004tM-9q; Thu, 19 Apr 2012 20:06:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKxcY-0004tH-UD
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 20:06:27 +0000
Received: from [85.158.143.35:64649] by server-2.bemta-4.messagelabs.com id
	8C/9A-17550-240709F4; Thu, 19 Apr 2012 20:06:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334865984!10774712!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzMwNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10719 invoked from network); 19 Apr 2012 20:06:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:06:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JK5Tdr018355
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 20:05:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JK5NZv003003
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 20:05:24 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JK5Lqn030116; Thu, 19 Apr 2012 15:05:21 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 13:05:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 859AA40280; Thu, 19 Apr 2012 16:00:23 -0400 (EDT)
Date: Thu, 19 Apr 2012 16:00:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419200023.GD28211@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
	<20120416203210.GD14982@phenom.dumpdata.com>
	<CAF1ivSZ8H2jp6sv=F8DXBAG9Wi87zCLh5Lbh+aeN66eJg_F1_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSZ8H2jp6sv=F8DXBAG9Wi87zCLh5Lbh+aeN66eJg_F1_Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F90700A.0100,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
> >> +{
> >> + =A0 =A0 irq_enter();
> >> + =A0 =A0 inc_irq_stat(apic_irq_work_irqs);
> >> + =A0 =A0 irq_work_run();
> >
> > I think this usually done the other way around:
> >
> > irq_work_run()
> > inc_irq_stat(apic_irq_work_irqs)
> >
> > Or is there an excellent reason for doing it this way?
> =

> Copy & paste from smp_irq_work_interrupt().
> But I think there is no much difference.
> =

> Anyway, I can change it if needed.

Please do. It looks at odds with the other usages in this file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 20:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 20:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxca-0004tM-9q; Thu, 19 Apr 2012 20:06:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SKxcY-0004tH-UD
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 20:06:27 +0000
Received: from [85.158.143.35:64649] by server-2.bemta-4.messagelabs.com id
	8C/9A-17550-240709F4; Thu, 19 Apr 2012 20:06:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334865984!10774712!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NzMwNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10719 invoked from network); 19 Apr 2012 20:06:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:06:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3JK5Tdr018355
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Apr 2012 20:05:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3JK5NZv003003
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Apr 2012 20:05:24 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3JK5Lqn030116; Thu, 19 Apr 2012 15:05:21 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 19 Apr 2012 13:05:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 859AA40280; Thu, 19 Apr 2012 16:00:23 -0400 (EDT)
Date: Thu, 19 Apr 2012 16:00:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120419200023.GD28211@phenom.dumpdata.com>
References: <1334470172-3861-1-git-send-email-mlin@ss.pku.edu.cn>
	<1334470172-3861-3-git-send-email-mlin@ss.pku.edu.cn>
	<20120416203210.GD14982@phenom.dumpdata.com>
	<CAF1ivSZ8H2jp6sv=F8DXBAG9Wi87zCLh5Lbh+aeN66eJg_F1_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSZ8H2jp6sv=F8DXBAG9Wi87zCLh5Lbh+aeN66eJg_F1_Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F90700A.0100,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> +static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
> >> +{
> >> + =A0 =A0 irq_enter();
> >> + =A0 =A0 inc_irq_stat(apic_irq_work_irqs);
> >> + =A0 =A0 irq_work_run();
> >
> > I think this usually done the other way around:
> >
> > irq_work_run()
> > inc_irq_stat(apic_irq_work_irqs)
> >
> > Or is there an excellent reason for doing it this way?
> =

> Copy & paste from smp_irq_work_interrupt().
> But I think there is no much difference.
> =

> Anyway, I can change it if needed.

Please do. It looks at odds with the other usages in this file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 20:10:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 20:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxfm-0005B0-Ta; Thu, 19 Apr 2012 20:09:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKxfl-0005Aq-5m
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 20:09:45 +0000
Received: from [85.158.143.35:17617] by server-1.bemta-4.messagelabs.com id
	FC/96-20925-801709F4; Thu, 19 Apr 2012 20:09:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334866183!12152334!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk1Nzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23661 invoked from network); 19 Apr 2012 20:09:43 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 20:09:43 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 9E0815EC07E;
	Thu, 19 Apr 2012 13:09:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=n3V6g6DaOu4KeP2s054k24JzjnkjY6WH+6AXCvagnP5t
	zQOKRXbJAMWKiZ0Zl/OL/NL9LcVTeqQt5JKAMjLLhBdGIbg8rCFFB9U+oK2JEviB
	5H4D9P92T8eDWmHGLgIiWkrAjxOIHv0KXyiAR3NXlq6VzR/RoYn0JwCrq58mRk0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=43pa3TzBFncUnKwZch0+VyJwNSs=; b=f0tlx0ls
	UsxWoPBHmqEhux8ODLzgV0jzAAo9W3TwKOLuBcTdft3gJX6OSBSo60blH5TYcBNY
	F5+tKKi0buQPd0ormWF6a3BlEKlkO+jjVKMmy9nyoac/MngMTLgUYpC6DMfasELI
	nRZD+9lVGnNuTRyOBDJG/nDnABmJRugDeVw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 6386A5EC080; 
	Thu, 19 Apr 2012 13:09:41 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Apr 2012 13:09:42 -0700
Message-ID: <4d451c8a7881c61bdd231109340351c8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAGU+auuMNdsTmtzW=eUzdjBQJp8w2Gpn0rVk2YVQBP_hsFzTAQ@mail.gmail.com>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
	<1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
	<CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
	<CAGU+auuMNdsTmtzW=eUzdjBQJp8w2Gpn0rVk2YVQBP_hsFzTAQ@mail.gmail.com>
Date: Thu, 19 Apr 2012 13:09:42 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "AP" <apxeng@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: jbeulich@suse.com, ian.campbell@citrix.com, santosh.jodh@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Tue, Apr 17, 2012 at 1:59 PM, AP <apxeng@gmail.com> wrote:
>> On Tue, Apr 17, 2012 at 8:56 AM, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>>>>
>>>> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>>>>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>>>>> told me to change all others while I was in there.
>>>>
>>>> Oh, right, I remember now.
>>>>
>>>> Given that reverting it for this case will still leave the same issue
>>>> for the grant case (which I'd forgotten about) I suppose the
>>>> appropriate
>>>> workaround is to touch the alloca'd memory in the appropriate order in
>>>> all cases (perhaps with an alloca helper macro).
>>>
>>> FWIW, I am very skeptical about this whole alloca business. It's very
>>> very
>>> dangerous, no surprise on the bug report. On my code I tend to map
>>> arbitrarily-sized pfn arrays, and I've been thinking of disabling
>>> alloca.
>>>
>>> If your only safeguard is to put a loop that touches everything so the
>>> stack gets allocated .... then what's your gain?
>>>
>>> Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
>>> round_to_page_size(what_you_need)). That's likely the fastest way to
>>> get
>>> the array in Linux. It isn't that slow either. And it's safe.
>>
>> I tried and it worked for me.
>>
>> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c
>> +++ b/tools/libxc/xc_linux_osdep.c
>> @@ -34,16 +34,17 @@
>> =A0#include <xen/memory.h>
>> =A0#include <xen/sys/evtchn.h>
>> =A0#include <xen/sys/gntdev.h>
>> =A0#include <xen/sys/gntalloc.h>
>>
>> =A0#include "xenctrl.h"
>> =A0#include "xenctrlosdep.h"
>>
>> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
>> ~((1UL<<(_w))-1))
>> =A0#define ERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>> =A0#define PERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " (%d =3D %s)", ## _a , errno, xc_st=
rerror(xch, errno))
>>
>> =A0static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
>> =A0{
>> =A0 =A0 int flags, saved_errno;
>> =A0 =A0 int fd =3D open("/proc/xen/privcmd", O_RDWR);
>> @@ -281,17 +282,24 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 /* Command was not recognized, use fall back */
>> =A0 =A0 else if ( rc < 0 && errno =3D=3D EINVAL && (int)num > 0 )
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 /*
>> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall =
back to
>> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH.
>> =A0 =A0 =A0 =A0 =A0*/
>> =A0 =A0 =A0 =A0 privcmd_mmapbatch_t ioctlx;
>> - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
>> + =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((num * sizeof(*pf=
n)),
>> XC_PAGE_SHIFT),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PROT_READ |=
 PROT_WRITE,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MAP_PRIVATE=
 | MAP_ANON | MAP_POPULATE,
>> -1, 0);
>> + =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap of pfn array =
failed");
>> + =A0 =A0 =A0 =A0 =A0 =A0return NULL;
>> + =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 memcpy(pfn, arr, num * sizeof(*arr));
>>
>> =A0 =A0 =A0 =A0 ioctlx.num =3D num;
>> =A0 =A0 =A0 =A0 ioctlx.dom =3D dom;
>> =A0 =A0 =A0 =A0 ioctlx.addr =3D (unsigned long)addr;
>> =A0 =A0 =A0 =A0 ioctlx.arr =3D pfn;
>>
>> @@ -323,16 +331,18 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -ENOENT;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
>> =A0 =A0 =A0 =A0 =A0 =A0 }
>> =A0 =A0 =A0 =A0 =A0 =A0 break;
>> =A0 =A0 =A0 =A0 }
>>
>> + =A0 =A0 =A0 =A0munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT=
));
>> +
>> =A0 =A0 =A0 =A0 if ( rc =3D=3D -ENOENT && i =3D=3D num )
>> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D 0;
>> =A0 =A0 =A0 =A0 else if ( rc )
>> =A0 =A0 =A0 =A0 {
>> =A0 =A0 =A0 =A0 =A0 =A0 errno =3D -rc;
>> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -1;
>> =A0 =A0 =A0 =A0 }
>> =A0 =A0 }
>>
>
> Just wondering what is the consensus on this? Is the mmap() method
> acceptable? Should I go ahead and submit this as a patch?

I think you should, and you should include my
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks,
Andres
>
> Thanks,
> AP
>
>>> Andres
>>>
>>>>
>>>> Ian.
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>>> Sent: Tuesday, April 17, 2012 12:56 AM
>>>>> To: Ian Campbell; AP
>>>>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>>>>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>>>>> causing segfault
>>>>>
>>>>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com>
>>>>> wrote:
>>>>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>>>>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>>>>> >> amounts of pages (in the GB range) from a guest in to Dom0
>>>>> >
>>>>> > Out of interest -- what are you doing this for?
>>>>> >
>>>>> >> =A0using
>>>>> >> xc_map_foreign_bulk() I am hitting a segfault.
>>>>> >>
>>>>> >> Program received signal SIGSEGV, Segmentation fault.
>>>>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>>>> (xch=3D0x605050,
>>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>>> arr=3D0x7ffff6bf5010,
>>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>>> >> 52 =A0 =A0 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src=
, __len,
>>>>> __bos0
>>>>> (__dest));
>>>>> >> (gdb) bt
>>>>> >> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>>>> (xch=3D0x605050,
>>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>>> arr=3D0x7ffff6bf5010,
>>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>>> >> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized
>>>>> out>,
>>>>> >> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<opti=
mized
>>>>> out>,
>>>>> >> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at
>>>>> >> xc_foreign_memory.c:79
>>>>> >>
>>>>> >> This was working for me with Xen 4.1.2. On comparing
>>>>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>>>>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>>>>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>>>>> >> blowing the stack with the call.
>>>>> >
>>>>> > I bet this is due to Linux's stack guard page. This means that if
>>>>> you
>>>>> > try and increase the stack by more than ~1 page you skip entirely
>>>>> over
>>>>> > the "next" stack page and into the guard.
>>>>> >
>>>>> > Does it help if after the alloca you add a loop which touches the
>>>>> > first word of each page of the new buffer? Since the stack grows
>>>>> down
>>>>> > you might actually need to do it backwards from the end of the
>>>>> array
>>>>> > in order to start at the end which is nearest the existing stack?
>>>>> > (it's before coffee o'clock so thinking about stack direction isn't
>>>>> my
>>>>> > strong point yet...)
>>>>>
>>>>> This should really be done by the alloca() implementation itself -
>>>>> anything else is a bug.
>>>>>
>>>>> > The switch to alloca was made recently in order to optimise the
>>>>> > hotpath for a userspace I/O backend.
>>>>>
>>>>> Probably this should be made size-dependent ...
>>>>>
>>>>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>>>>> > mmap doing on the hot path for the userspace I/O anyway? Most
>>>>> hotpath
>>>>> > operations should really be grant table ops, a backend shouldn't be
>>>>> > relying on the privileges accorded to dom0 -- for one thing it
>>>>> should
>>>>> > be expected to work in a driver domain.
>>>>>
>>>>> ... if this indeed turns out to be a hot path for something at all?
>>>>>
>>>>> Jan
>>>>>
>>>>> >> =A0If I replace the alloca() with malloc() the call goes through.
>>>>> What
>>>>> >> is the way around this? Should I be using
>>>>> >> xc_map_foreign_batch() instead, which I think is deprecated?
>>>>> Please
>>>>> >> advice...
>>>>> >>
>>>>> >> Thanks,
>>>>> >> AP
>>>>> >>
>>>
>>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 20:10:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 20:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxfm-0005B0-Ta; Thu, 19 Apr 2012 20:09:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKxfl-0005Aq-5m
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 20:09:45 +0000
Received: from [85.158.143.35:17617] by server-1.bemta-4.messagelabs.com id
	FC/96-20925-801709F4; Thu, 19 Apr 2012 20:09:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334866183!12152334!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk1Nzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23661 invoked from network); 19 Apr 2012 20:09:43 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 20:09:43 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 9E0815EC07E;
	Thu, 19 Apr 2012 13:09:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=n3V6g6DaOu4KeP2s054k24JzjnkjY6WH+6AXCvagnP5t
	zQOKRXbJAMWKiZ0Zl/OL/NL9LcVTeqQt5JKAMjLLhBdGIbg8rCFFB9U+oK2JEviB
	5H4D9P92T8eDWmHGLgIiWkrAjxOIHv0KXyiAR3NXlq6VzR/RoYn0JwCrq58mRk0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=43pa3TzBFncUnKwZch0+VyJwNSs=; b=f0tlx0ls
	UsxWoPBHmqEhux8ODLzgV0jzAAo9W3TwKOLuBcTdft3gJX6OSBSo60blH5TYcBNY
	F5+tKKi0buQPd0ormWF6a3BlEKlkO+jjVKMmy9nyoac/MngMTLgUYpC6DMfasELI
	nRZD+9lVGnNuTRyOBDJG/nDnABmJRugDeVw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 6386A5EC080; 
	Thu, 19 Apr 2012 13:09:41 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Apr 2012 13:09:42 -0700
Message-ID: <4d451c8a7881c61bdd231109340351c8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAGU+auuMNdsTmtzW=eUzdjBQJp8w2Gpn0rVk2YVQBP_hsFzTAQ@mail.gmail.com>
References: <mailman.2551.1334677052.1399.xen-devel@lists.xen.org>
	<1c5e5f57cce13b884b831aef9704d78d.squirrel@webmail.lagarcavilla.org>
	<CAGU+auufXjDgMZfckxk0mrCXgqx5n6PQa3kD59Cw+tHN=6vCXA@mail.gmail.com>
	<CAGU+auuMNdsTmtzW=eUzdjBQJp8w2Gpn0rVk2YVQBP_hsFzTAQ@mail.gmail.com>
Date: Thu, 19 Apr 2012 13:09:42 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "AP" <apxeng@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: jbeulich@suse.com, ian.campbell@citrix.com, santosh.jodh@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing
	segfault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Tue, Apr 17, 2012 at 1:59 PM, AP <apxeng@gmail.com> wrote:
>> On Tue, Apr 17, 2012 at 8:56 AM, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>>>>
>>>> On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
>>>>> I only cared about linux_gnttab_grant_map for user mode blkback. You
>>>>> told me to change all others while I was in there.
>>>>
>>>> Oh, right, I remember now.
>>>>
>>>> Given that reverting it for this case will still leave the same issue
>>>> for the grant case (which I'd forgotten about) I suppose the
>>>> appropriate
>>>> workaround is to touch the alloca'd memory in the appropriate order in
>>>> all cases (perhaps with an alloca helper macro).
>>>
>>> FWIW, I am very skeptical about this whole alloca business. It's very
>>> very
>>> dangerous, no surprise on the bug report. On my code I tend to map
>>> arbitrarily-sized pfn arrays, and I've been thinking of disabling
>>> alloca.
>>>
>>> If your only safeguard is to put a loop that touches everything so the
>>> stack gets allocated .... then what's your gain?
>>>
>>> Just mmap('/dev/zero', MAP_PRIVATE|MAP_POPULATE, PROT_WRITE,
>>> round_to_page_size(what_you_need)). That's likely the fastest way to
>>> get
>>> the array in Linux. It isn't that slow either. And it's safe.
>>
>> I tried and it worked for me.
>>
>> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c
>> +++ b/tools/libxc/xc_linux_osdep.c
>> @@ -34,16 +34,17 @@
>> =A0#include <xen/memory.h>
>> =A0#include <xen/sys/evtchn.h>
>> =A0#include <xen/sys/gntdev.h>
>> =A0#include <xen/sys/gntalloc.h>
>>
>> =A0#include "xenctrl.h"
>> =A0#include "xenctrlosdep.h"
>>
>> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
>> ~((1UL<<(_w))-1))
>> =A0#define ERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>> =A0#define PERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " (%d =3D %s)", ## _a , errno, xc_st=
rerror(xch, errno))
>>
>> =A0static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
>> =A0{
>> =A0 =A0 int flags, saved_errno;
>> =A0 =A0 int fd =3D open("/proc/xen/privcmd", O_RDWR);
>> @@ -281,17 +282,24 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 /* Command was not recognized, use fall back */
>> =A0 =A0 else if ( rc < 0 && errno =3D=3D EINVAL && (int)num > 0 )
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 /*
>> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall =
back to
>> =A0 =A0 =A0 =A0 =A0* IOCTL_PRIVCMD_MMAPBATCH.
>> =A0 =A0 =A0 =A0 =A0*/
>> =A0 =A0 =A0 =A0 privcmd_mmapbatch_t ioctlx;
>> - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
>> + =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((num * sizeof(*pf=
n)),
>> XC_PAGE_SHIFT),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PROT_READ |=
 PROT_WRITE,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MAP_PRIVATE=
 | MAP_ANON | MAP_POPULATE,
>> -1, 0);
>> + =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap of pfn array =
failed");
>> + =A0 =A0 =A0 =A0 =A0 =A0return NULL;
>> + =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 memcpy(pfn, arr, num * sizeof(*arr));
>>
>> =A0 =A0 =A0 =A0 ioctlx.num =3D num;
>> =A0 =A0 =A0 =A0 ioctlx.dom =3D dom;
>> =A0 =A0 =A0 =A0 ioctlx.addr =3D (unsigned long)addr;
>> =A0 =A0 =A0 =A0 ioctlx.arr =3D pfn;
>>
>> @@ -323,16 +331,18 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -ENOENT;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
>> =A0 =A0 =A0 =A0 =A0 =A0 }
>> =A0 =A0 =A0 =A0 =A0 =A0 break;
>> =A0 =A0 =A0 =A0 }
>>
>> + =A0 =A0 =A0 =A0munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT=
));
>> +
>> =A0 =A0 =A0 =A0 if ( rc =3D=3D -ENOENT && i =3D=3D num )
>> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D 0;
>> =A0 =A0 =A0 =A0 else if ( rc )
>> =A0 =A0 =A0 =A0 {
>> =A0 =A0 =A0 =A0 =A0 =A0 errno =3D -rc;
>> =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -1;
>> =A0 =A0 =A0 =A0 }
>> =A0 =A0 }
>>
>
> Just wondering what is the consensus on this? Is the mmap() method
> acceptable? Should I go ahead and submit this as a patch?

I think you should, and you should include my
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks,
Andres
>
> Thanks,
> AP
>
>>> Andres
>>>
>>>>
>>>> Ian.
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>>> Sent: Tuesday, April 17, 2012 12:56 AM
>>>>> To: Ian Campbell; AP
>>>>> Cc: Santosh Jodh; xen-devel@lists.xensource.com
>>>>> Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk
>>>>> causing segfault
>>>>>
>>>>> >>> On 17.04.12 at 09:27, Ian Campbell <Ian.Campbell@citrix.com>
>>>>> wrote:
>>>>> > On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
>>>>> >> On xen-unstable 25164:5bbda657a016, when I try to map in large
>>>>> >> amounts of pages (in the GB range) from a guest in to Dom0
>>>>> >
>>>>> > Out of interest -- what are you doing this for?
>>>>> >
>>>>> >> =A0using
>>>>> >> xc_map_foreign_bulk() I am hitting a segfault.
>>>>> >>
>>>>> >> Program received signal SIGSEGV, Segmentation fault.
>>>>> >> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>>>> (xch=3D0x605050,
>>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>>> arr=3D0x7ffff6bf5010,
>>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>>> >> 52 =A0 =A0 =A0 =A0 =A0return __builtin___memcpy_chk (__dest, __src=
, __len,
>>>>> __bos0
>>>>> (__dest));
>>>>> >> (gdb) bt
>>>>> >> #0 =A00x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk
>>>>> (xch=3D0x605050,
>>>>> >> =A0 =A0 h=3D<optimized out>, dom=3D2, prot=3D<optimized out>,
>>>>> arr=3D0x7ffff6bf5010,
>>>>> >> =A0 =A0 err=3D0x7ffff67f4010, num=3D<optimized out>)
>>>>> >> =A0 =A0 at /usr/include/x86_64-linux-gnu/bits/string3.h:52
>>>>> >> #1 =A00x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=3D<optimized
>>>>> out>,
>>>>> >> =A0 =A0 dom=3D<optimized out>, prot=3D<optimized out>, arr=3D<opti=
mized
>>>>> out>,
>>>>> >> =A0 =A0 err=3D<optimized out>, num=3D<optimized out>) at
>>>>> >> xc_foreign_memory.c:79
>>>>> >>
>>>>> >> This was working for me with Xen 4.1.2. On comparing
>>>>> >> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see
>>>>> >> that the pfn array in linux_privcmd_map_foreign_bulk() is being
>>>>> >> allocated using alloca() in unstable vs malloc() in 4.1.2. So I am
>>>>> >> blowing the stack with the call.
>>>>> >
>>>>> > I bet this is due to Linux's stack guard page. This means that if
>>>>> you
>>>>> > try and increase the stack by more than ~1 page you skip entirely
>>>>> over
>>>>> > the "next" stack page and into the guard.
>>>>> >
>>>>> > Does it help if after the alloca you add a loop which touches the
>>>>> > first word of each page of the new buffer? Since the stack grows
>>>>> down
>>>>> > you might actually need to do it backwards from the end of the
>>>>> array
>>>>> > in order to start at the end which is nearest the existing stack?
>>>>> > (it's before coffee o'clock so thinking about stack direction isn't
>>>>> my
>>>>> > strong point yet...)
>>>>>
>>>>> This should really be done by the alloca() implementation itself -
>>>>> anything else is a bug.
>>>>>
>>>>> > The switch to alloca was made recently in order to optimise the
>>>>> > hotpath for a userspace I/O backend.
>>>>>
>>>>> Probably this should be made size-dependent ...
>>>>>
>>>>> > BTW, Santosh, it didn't occur to me at the time but what is privcmd
>>>>> > mmap doing on the hot path for the userspace I/O anyway? Most
>>>>> hotpath
>>>>> > operations should really be grant table ops, a backend shouldn't be
>>>>> > relying on the privileges accorded to dom0 -- for one thing it
>>>>> should
>>>>> > be expected to work in a driver domain.
>>>>>
>>>>> ... if this indeed turns out to be a hot path for something at all?
>>>>>
>>>>> Jan
>>>>>
>>>>> >> =A0If I replace the alloca() with malloc() the call goes through.
>>>>> What
>>>>> >> is the way around this? Should I be using
>>>>> >> xc_map_foreign_batch() instead, which I think is deprecated?
>>>>> Please
>>>>> >> advice...
>>>>> >>
>>>>> >> Thanks,
>>>>> >> AP
>>>>> >>
>>>
>>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 20:11:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 20:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxgz-0005HG-HN; Thu, 19 Apr 2012 20:11:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKxgy-0005HA-50
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 20:11:00 +0000
Received: from [85.158.143.35:15372] by server-1.bemta-4.messagelabs.com id
	C5/57-20925-351709F4; Thu, 19 Apr 2012 20:10:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334866258!14063167!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE2NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2660 invoked from network); 19 Apr 2012 20:10:58 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-8.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 20:10:58 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id A7FE6604092;
	Thu, 19 Apr 2012 13:10:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c/FL5oTEZLYlo549Uref7Nmv9bC40FULjG0dOQlxRkiY
	dSj0TMVk+2abIDU72+o4Mblw5W7fDd9vewUdHF+ZTtMaNfPE0W67MJ4DoooIoEs/
	R7u3J7YkXGr+thR0rx/RCpM1OzcNxcPdcokWcSlRX5XwNaMCxNBcLxryC/x/sH0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Q+HpxmFFYKyI+LO0p+ybC8i3kYA=; b=XY9TNKap
	4Oo82ilmMAI27bpoHdfts3/6T22TG0Tpah4OQhRmzG9hG8UfmW0exFn9CQ6v96+S
	FtyX4MDErfb1j5aB3m2tZNf+W0pHIBXCG7NS4m3rSpQKZ3TvImJ8QrD+wmDKpMxZ
	+KVsyzYrXtrPboLManXDcbKJ2cB+iduZiKE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 511DE6040A9; 
	Thu, 19 Apr 2012 13:10:20 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Apr 2012 13:10:23 -0700
Message-ID: <40897fb396ee70446fe1d10f7a005641.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120419170840.GD23663@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
Date: Thu, 19 Apr 2012 13:10:23 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Gianluca Guida <glguida@gmail.com>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
>> After a hvm+shadow domain dies (either clean shutdown or merciless
>> destroy), the domain is left in a zombie state with 1 (one) page left
>> dangling with a single reference.
>
> The reference is to the top-level pagetable that was pointed to by CR3
> when the domain was killed.  This bug came in with:
>
>  changeset:   23142:f5e8d152a565
>  user:        Jan Beulich <jbeulich@novell.com>
>  date:        Tue Apr 05 13:01:25 2011 +0100
>  description: x86: split struct vcpu
>
> where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> their VCPUs as they die.  Proposed fix attached.
>
> Cheers,

Looks good. Thanks for tracing that down. Ack from my end.
Thanks
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 20:11:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 20:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKxgz-0005HG-HN; Thu, 19 Apr 2012 20:11:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SKxgy-0005HA-50
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 20:11:00 +0000
Received: from [85.158.143.35:15372] by server-1.bemta-4.messagelabs.com id
	C5/57-20925-351709F4; Thu, 19 Apr 2012 20:10:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1334866258!14063167!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE2NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2660 invoked from network); 19 Apr 2012 20:10:58 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-8.tower-21.messagelabs.com with SMTP;
	19 Apr 2012 20:10:58 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id A7FE6604092;
	Thu, 19 Apr 2012 13:10:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c/FL5oTEZLYlo549Uref7Nmv9bC40FULjG0dOQlxRkiY
	dSj0TMVk+2abIDU72+o4Mblw5W7fDd9vewUdHF+ZTtMaNfPE0W67MJ4DoooIoEs/
	R7u3J7YkXGr+thR0rx/RCpM1OzcNxcPdcokWcSlRX5XwNaMCxNBcLxryC/x/sH0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Q+HpxmFFYKyI+LO0p+ybC8i3kYA=; b=XY9TNKap
	4Oo82ilmMAI27bpoHdfts3/6T22TG0Tpah4OQhRmzG9hG8UfmW0exFn9CQ6v96+S
	FtyX4MDErfb1j5aB3m2tZNf+W0pHIBXCG7NS4m3rSpQKZ3TvImJ8QrD+wmDKpMxZ
	+KVsyzYrXtrPboLManXDcbKJ2cB+iduZiKE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 511DE6040A9; 
	Thu, 19 Apr 2012 13:10:20 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Apr 2012 13:10:23 -0700
Message-ID: <40897fb396ee70446fe1d10f7a005641.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120419170840.GD23663@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
Date: Thu, 19 Apr 2012 13:10:23 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Gianluca Guida <glguida@gmail.com>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
>> After a hvm+shadow domain dies (either clean shutdown or merciless
>> destroy), the domain is left in a zombie state with 1 (one) page left
>> dangling with a single reference.
>
> The reference is to the top-level pagetable that was pointed to by CR3
> when the domain was killed.  This bug came in with:
>
>  changeset:   23142:f5e8d152a565
>  user:        Jan Beulich <jbeulich@novell.com>
>  date:        Tue Apr 05 13:01:25 2011 +0100
>  description: x86: split struct vcpu
>
> where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> their VCPUs as they die.  Proposed fix attached.
>
> Cheers,

Looks good. Thanks for tracing that down. Ack from my end.
Thanks
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 21:03:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 21:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKyV6-0006Cu-Nt; Thu, 19 Apr 2012 21:02:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKyV5-0006Cp-MJ
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 21:02:48 +0000
Received: from [85.158.138.51:24806] by server-2.bemta-3.messagelabs.com id
	A2/56-09269-67D709F4; Thu, 19 Apr 2012 21:02:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334869366!21128299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29607 invoked from network); 19 Apr 2012 21:02:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 21:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,449,1330905600"; d="scan'208";a="12036474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 21:02:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 22:02:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKyV3-0003PG-FJ;
	Thu, 19 Apr 2012 21:02:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKyV3-0005OM-Du;
	Thu, 19 Apr 2012 22:02:45 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12726-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 22:02:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12726: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12726 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12726/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                2adb09687b4cd369983ba4533d6eab857262e1b9
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 2adb09687b4cd369983ba4533d6eab857262e1b9
Merge: ba0ed41... 592fe89...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 18 08:07:52 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 21:03:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 21:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKyV6-0006Cu-Nt; Thu, 19 Apr 2012 21:02:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKyV5-0006Cp-MJ
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 21:02:48 +0000
Received: from [85.158.138.51:24806] by server-2.bemta-3.messagelabs.com id
	A2/56-09269-67D709F4; Thu, 19 Apr 2012 21:02:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334869366!21128299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29607 invoked from network); 19 Apr 2012 21:02:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 21:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,449,1330905600"; d="scan'208";a="12036474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 21:02:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 22:02:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKyV3-0003PG-FJ;
	Thu, 19 Apr 2012 21:02:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKyV3-0005OM-Du;
	Thu, 19 Apr 2012 22:02:45 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12726-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 22:02:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12726: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12726 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12726/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install            fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-win7-amd64  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-i386-i386-xl-win         5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot                   fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   never pass
 test-amd64-i386-xl            7 debian-install               fail   never pass
 test-i386-i386-pv             7 debian-install               fail   never pass
 test-amd64-i386-xl-credit2    7 debian-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                2adb09687b4cd369983ba4533d6eab857262e1b9
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 2adb09687b4cd369983ba4533d6eab857262e1b9
Merge: ba0ed41... 592fe89...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 18 08:07:52 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 21:25:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 21:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKyqp-0006ZS-Pd; Thu, 19 Apr 2012 21:25:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SKyqo-0006ZN-HG
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 21:25:14 +0000
Received: from [193.109.254.147:5292] by server-6.bemta-14.messagelabs.com id
	1C/DC-02047-9B2809F4; Thu, 19 Apr 2012 21:25:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334870706!5395314!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8203 invoked from network); 19 Apr 2012 21:25:10 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 21:25:10 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q3JLP3dU031259
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 14:25:05 -0700
Received: by bkcji1 with SMTP id ji1so877802bkc.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 14:25:02 -0700 (PDT)
Received: by 10.204.157.12 with SMTP id z12mr1109299bkw.135.1334870702463;
	Thu, 19 Apr 2012 14:25:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.53.198 with HTTP; Thu, 19 Apr 2012 14:24:21 -0700 (PDT)
In-Reply-To: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
References: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Apr 2012 14:24:21 -0700
Message-ID: <CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
To: Rahul Singh <singh.rahul.1983@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5926651565637672730=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5926651565637672730==
Content-Type: multipart/alternative; boundary=00151747af8e0a9a4004be0ece59

--00151747af8e0a9a4004be0ece59
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <singh.rahul.1983@gmail.com>wrote:

> Hi,
> I am trying to understand and change the network buffering that is being
> used by Remus, the HA solution present in Xen. From what i understood from
> reading the code, Remus calls the postsuspend method of the BufferedNIC
> after it suspends the domain that sends TC_PLUG_CHECKPOINT message and
> start the buffering
>
for packets in the "next" epoch [the one that starts after the domain is
resumed]


>  and then calls the commit method of BufferedNIC after it gets the
> acknowledgement that sends the TC_PLUG_RELEASE message and releases the
> buffered packets.
>
of the previous current epoch [the one whose checkpoint was just committed
on the backup machine]


> I have the following doubts
> 1) How does remus ensure that the packets gets buffered for an entire
> epoch ?
>
I would suggest you go through the comments in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/sched/sch_plug.c;h=89f8fcf73f18f6e091881cc829861285c0c8f8b7;hb=HEAD
the sch_plug module in upstream linux.

> 2) If i comment out the lines in the "postsuspend" and "commit" lines of
> the BufferedNIC class that send the TC_PLUG_CHECKPOINT and TC_PLUG_RELEASE,
> i see that all the network packets are being buffered and i cannot ping the
> Remus-protected VM at all. Where is the packet buffering happen if i
> comment out these 2 lines ?
>

the module starts out in the buffered mode and releases packets only upon
receiving a RELEASE command.

hope that helps.

cheers
shriram


> Thanking you,
> Rahul.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--00151747af8e0a9a4004be0ece59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:singh.rahul.1983@gmail.com">singh.rahu=
l.1983@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. From what i understood from=
 reading the code, Remus=20
calls the postsuspend method of the BufferedNIC after it suspends the=20
domain that sends TC_PLUG_CHECKPOINT message and start the buffering</p></d=
iv></div></blockquote><div>for packets in the &quot;next&quot; epoch [the o=
ne that starts after the domain is resumed]<br>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p> and
 then calls the commit method of BufferedNIC after it gets the=20
acknowledgement that sends the TC_PLUG_RELEASE message and releases the=20
buffered packets. </p></div></div></blockquote><div>of the previous current=
 epoch [the one whose checkpoint was just committed on the backup machine]<=
br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0=
pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>I have the following doubts<br>
1) How does remus ensure that the packets gets buffered for an entire epoch=
 ?<br></p></div></div></blockquote><div>I would suggest you go through the =
comments in <br><a href=3D"http://git.kernel.org/?p=3Dlinux/kernel/git/torv=
alds/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091=
881cc829861285c0c8f8b7;hb=3DHEAD">http://git.kernel.org/?p=3Dlinux/kernel/g=
it/torvalds/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f1=
8f6e091881cc829861285c0c8f8b7;hb=3DHEAD</a><br>

the sch_plug module in upstream linux. <br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><div><p>
2) If i comment out the lines in the &quot;postsuspend&quot; and &quot;comm=
it&quot; lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and=20
TC_PLUG_RELEASE, i see that all the network packets are being buffered=20
and i cannot ping the Remus-protected VM at all. Where is the packet=20
buffering happen if i comment out these 2 lines ?</p></div></div></blockquo=
te><div><br>the module starts out in the buffered mode and releases packets=
 only upon receiving a RELEASE command.<br><br>hope that helps.<br><br>

cheers<br>shriram<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div style=3D"word-wrap:break-word"><div><p>Thanking you,<br>
Rahul.</p></div></div><br>_______________________________________________<b=
r>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br>

--00151747af8e0a9a4004be0ece59--


--===============5926651565637672730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5926651565637672730==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 21:25:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 21:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKyqp-0006ZS-Pd; Thu, 19 Apr 2012 21:25:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SKyqo-0006ZN-HG
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 21:25:14 +0000
Received: from [193.109.254.147:5292] by server-6.bemta-14.messagelabs.com id
	1C/DC-02047-9B2809F4; Thu, 19 Apr 2012 21:25:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334870706!5395314!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8203 invoked from network); 19 Apr 2012 21:25:10 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 21:25:10 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q3JLP3dU031259
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 14:25:05 -0700
Received: by bkcji1 with SMTP id ji1so877802bkc.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 14:25:02 -0700 (PDT)
Received: by 10.204.157.12 with SMTP id z12mr1109299bkw.135.1334870702463;
	Thu, 19 Apr 2012 14:25:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.53.198 with HTTP; Thu, 19 Apr 2012 14:24:21 -0700 (PDT)
In-Reply-To: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
References: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Apr 2012 14:24:21 -0700
Message-ID: <CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
To: Rahul Singh <singh.rahul.1983@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5926651565637672730=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5926651565637672730==
Content-Type: multipart/alternative; boundary=00151747af8e0a9a4004be0ece59

--00151747af8e0a9a4004be0ece59
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <singh.rahul.1983@gmail.com>wrote:

> Hi,
> I am trying to understand and change the network buffering that is being
> used by Remus, the HA solution present in Xen. From what i understood from
> reading the code, Remus calls the postsuspend method of the BufferedNIC
> after it suspends the domain that sends TC_PLUG_CHECKPOINT message and
> start the buffering
>
for packets in the "next" epoch [the one that starts after the domain is
resumed]


>  and then calls the commit method of BufferedNIC after it gets the
> acknowledgement that sends the TC_PLUG_RELEASE message and releases the
> buffered packets.
>
of the previous current epoch [the one whose checkpoint was just committed
on the backup machine]


> I have the following doubts
> 1) How does remus ensure that the packets gets buffered for an entire
> epoch ?
>
I would suggest you go through the comments in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/sched/sch_plug.c;h=89f8fcf73f18f6e091881cc829861285c0c8f8b7;hb=HEAD
the sch_plug module in upstream linux.

> 2) If i comment out the lines in the "postsuspend" and "commit" lines of
> the BufferedNIC class that send the TC_PLUG_CHECKPOINT and TC_PLUG_RELEASE,
> i see that all the network packets are being buffered and i cannot ping the
> Remus-protected VM at all. Where is the packet buffering happen if i
> comment out these 2 lines ?
>

the module starts out in the buffered mode and releases packets only upon
receiving a RELEASE command.

hope that helps.

cheers
shriram


> Thanking you,
> Rahul.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--00151747af8e0a9a4004be0ece59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:singh.rahul.1983@gmail.com">singh.rahu=
l.1983@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. From what i understood from=
 reading the code, Remus=20
calls the postsuspend method of the BufferedNIC after it suspends the=20
domain that sends TC_PLUG_CHECKPOINT message and start the buffering</p></d=
iv></div></blockquote><div>for packets in the &quot;next&quot; epoch [the o=
ne that starts after the domain is resumed]<br>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p> and
 then calls the commit method of BufferedNIC after it gets the=20
acknowledgement that sends the TC_PLUG_RELEASE message and releases the=20
buffered packets. </p></div></div></blockquote><div>of the previous current=
 epoch [the one whose checkpoint was just committed on the backup machine]<=
br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0=
pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>I have the following doubts<br>
1) How does remus ensure that the packets gets buffered for an entire epoch=
 ?<br></p></div></div></blockquote><div>I would suggest you go through the =
comments in <br><a href=3D"http://git.kernel.org/?p=3Dlinux/kernel/git/torv=
alds/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091=
881cc829861285c0c8f8b7;hb=3DHEAD">http://git.kernel.org/?p=3Dlinux/kernel/g=
it/torvalds/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f1=
8f6e091881cc829861285c0c8f8b7;hb=3DHEAD</a><br>

the sch_plug module in upstream linux. <br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><div><p>
2) If i comment out the lines in the &quot;postsuspend&quot; and &quot;comm=
it&quot; lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and=20
TC_PLUG_RELEASE, i see that all the network packets are being buffered=20
and i cannot ping the Remus-protected VM at all. Where is the packet=20
buffering happen if i comment out these 2 lines ?</p></div></div></blockquo=
te><div><br>the module starts out in the buffered mode and releases packets=
 only upon receiving a RELEASE command.<br><br>hope that helps.<br><br>

cheers<br>shriram<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div style=3D"word-wrap:break-word"><div><p>Thanking you,<br>
Rahul.</p></div></div><br>_______________________________________________<b=
r>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br>

--00151747af8e0a9a4004be0ece59--


--===============5926651565637672730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5926651565637672730==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 21:54:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 21:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKzIo-0006wv-Ey; Thu, 19 Apr 2012 21:54:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKzIm-0006wq-Q1
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 21:54:09 +0000
Received: from [85.158.138.51:2759] by server-2.bemta-3.messagelabs.com id
	4B/3E-09269-F79809F4; Thu, 19 Apr 2012 21:54:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334872446!18868914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9098 invoked from network); 19 Apr 2012 21:54:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 21:54:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,449,1330905600"; d="scan'208";a="12036932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 21:54:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 22:54:06 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKzIk-0003fZ-2I;
	Thu, 19 Apr 2012 21:54:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKzIk-00039R-1h;
	Thu, 19 Apr 2012 22:54:06 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12727-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 22:54:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12727: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12727 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12727/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12723

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7c777cb8f705
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 21:54:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 21:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKzIo-0006wv-Ey; Thu, 19 Apr 2012 21:54:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SKzIm-0006wq-Q1
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 21:54:09 +0000
Received: from [85.158.138.51:2759] by server-2.bemta-3.messagelabs.com id
	4B/3E-09269-F79809F4; Thu, 19 Apr 2012 21:54:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334872446!18868914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTEwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9098 invoked from network); 19 Apr 2012 21:54:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 21:54:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,449,1330905600"; d="scan'208";a="12036932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Apr 2012 21:54:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Apr 2012 22:54:06 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SKzIk-0003fZ-2I;
	Thu, 19 Apr 2012 21:54:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SKzIk-00039R-1h;
	Thu, 19 Apr 2012 22:54:06 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12727-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Apr 2012 22:54:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12727: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12727 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12727/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12723

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7c777cb8f705
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 22:17:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 22:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKzfB-0007Nk-Av; Thu, 19 Apr 2012 22:17:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singh.rahul.1983@gmail.com>) id 1SKzfA-0007NY-0q
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 22:17:16 +0000
Received: from [85.158.143.35:18688] by server-2.bemta-4.messagelabs.com id
	37/37-17550-BEE809F4; Thu, 19 Apr 2012 22:17:15 +0000
X-Env-Sender: singh.rahul.1983@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334873832!12162402!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20204 invoked from network); 19 Apr 2012 22:17:13 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 22:17:13 -0000
Received: by qcsc20 with SMTP id c20so6870069qcs.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 15:17:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to:x-mailer;
	bh=JJotImx/ddmXz6FvJY0C8mVlnM0ZO155HzXteHkW8ac=;
	b=PdJY53Ae2EmOqKosFZ+g+uaUVHKPr8taAzMBzx2CaUPPL59/c0b0coKg0MqNs0JLNo
	cbGX2UCN2zvGPf5LWTcE4FlnXrme8+Rzxi/iPCPgT6ZpCcpzXCb7MSSqr39beCNAoU4Z
	9z6CN9n5mmMQ9Hf0gy2xknfN0QXn5lXdgJjKkAP35qcwi5MiEsF0xPmwt3PTzTalAsvX
	bAViDTPeSujHp/AVZFNpdemLBpy0J21TJ5ymYjMMxCtW5d37yPQS+6Fok5hqC8bYfc58
	+Mlho4IVGr5HXcLS1BW4owRNFLfzHFJN0rMug2drTtRESTD4OkeM40u8tvp5mQ4266Xt
	tA0w==
Received: by 10.224.102.8 with SMTP id e8mr5463245qao.50.1334873831866;
	Thu, 19 Apr 2012 15:17:11 -0700 (PDT)
Received: from moblix.cs.umass.edu (moblix.cs.umass.edu. [128.119.245.142])
	by mx.google.com with ESMTPS id c3sm6683546qap.20.2012.04.19.15.17.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 15:17:10 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Rahul Singh <singh.rahul.1983@gmail.com>
In-Reply-To: <CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
Date: Thu, 19 Apr 2012 18:17:08 -0400
Message-Id: <9792753F-4FB1-4C89-9E42-E609B116851B@gmail.com>
References: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
	<CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
To: rshriram@cs.ubc.ca
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1022036466889103843=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1022036466889103843==
Content-Type: multipart/alternative; boundary=Apple-Mail-9-84343549


--Apple-Mail-9-84343549
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks for pointing me to the comments, Shriram. That was very helpful.

What i am unable to figure out is how does Remus tell the module to only =
release packets belonging to a given epoch ? I am looking at the =
BufferedNIC class in xen-unstable/tools/python/xen/remus/device.py and =
the postsuspend method calls self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) =
while the commit method calls self._sendqmsg(qdisc.TC_PLUG_RELEASE). =
Where is it telling that only packets of the last epoch should be =
released ?

Also, as you said that module starts out with buffering everything. So =
if i comment out the self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) but keep =
the self._sendqmsg(qdisc.TC_PLUG_RELEASE), there should be no network =
buffering at all, but i still see that all packets are buffered.

Thanking you,
Rahul.

On Apr 19, 2012, at 5:24 PM, Shriram Rajagopalan wrote:

> On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh =
<singh.rahul.1983@gmail.com> wrote:
> Hi,
> I am trying to understand and change the network buffering that is =
being used by Remus, the HA solution present in Xen. =46rom what i =
understood from reading the code, Remus calls the postsuspend method of =
the BufferedNIC after it suspends the domain that sends =
TC_PLUG_CHECKPOINT message and start the buffering
>=20
> for packets in the "next" epoch [the one that starts after the domain =
is resumed]
> =20
> and then calls the commit method of BufferedNIC after it gets the =
acknowledgement that sends the TC_PLUG_RELEASE message and releases the =
buffered packets.
>=20
> of the previous current epoch [the one whose checkpoint was just =
committed on the backup machine]
> =20
> I have the following doubts
> 1) How does remus ensure that the packets gets buffered for an entire =
epoch ?
>=20
> I would suggest you go through the comments in=20
> =
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dblo=
b;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829861285c0c8f8b7;hb=
=3DHEAD
> the sch_plug module in upstream linux.=20
> 2) If i comment out the lines in the "postsuspend" and "commit" lines =
of the BufferedNIC class that send the TC_PLUG_CHECKPOINT and =
TC_PLUG_RELEASE, i see that all the network packets are being buffered =
and i cannot ping the Remus-protected VM at all. Where is the packet =
buffering happen if i comment out these 2 lines ?
>=20
>=20
> the module starts out in the buffered mode and releases packets only =
upon receiving a RELEASE command.
>=20
> hope that helps.
>=20
> cheers
> shriram
> =20
> Thanking you,
> Rahul.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20
>=20


--Apple-Mail-9-84343549
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Thanks for pointing me to the comments, Shriram. That was very =
helpful.<div><br></div><div>What i am unable to figure out is how does =
Remus tell the module to only release packets belonging to a given epoch =
? I am looking at the BufferedNIC class in =
xen-unstable/tools/python/xen/remus/device.py and the postsuspend method =
calls&nbsp;self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) while the commit =
method calls&nbsp;self._sendqmsg(qdisc.TC_PLUG_RELEASE). Where is it =
telling that only packets of the last epoch should be released =
?</div><div><br></div><div>Also, as you said that module starts out with =
buffering everything. So if i comment out =
the&nbsp;self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) but keep =
the&nbsp;self._sendqmsg(qdisc.TC_PLUG_RELEASE), there should be no =
network buffering at all, but i still see that all packets are =
buffered.</div><div><br></div><div>Thanking =
you,</div><div>Rahul.</div><div><div><br><div><div>On Apr 19, 2012, at =
5:24 PM, Shriram Rajagopalan wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
class=3D"gmail_quote">On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <span =
dir=3D"ltr">&lt;<a =
href=3D"mailto:singh.rahul.1983@gmail.com">singh.rahul.1983@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. =46rom what i understood =
from reading the code, Remus=20
calls the postsuspend method of the BufferedNIC after it suspends the=20
domain that sends TC_PLUG_CHECKPOINT message and start the =
buffering</p></div></div></blockquote><div>for packets in the "next" =
epoch [the one that starts after the domain is =
resumed]<br>&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p> and
 then calls the commit method of BufferedNIC after it gets the=20
acknowledgement that sends the TC_PLUG_RELEASE message and releases the=20=

buffered packets. </p></div></div></blockquote><div>of the previous =
current epoch [the one whose checkpoint was just committed on the backup =
machine]<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>I have the following =
doubts<br>
1) How does remus ensure that the packets gets buffered for an entire =
epoch ?<br></p></div></div></blockquote><div>I would suggest you go =
through the comments in <br><a =
href=3D"http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git=
;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829861285c0c=
8f8b7;hb=3DHEAD">http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
x-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829=
861285c0c8f8b7;hb=3DHEAD</a><br>

the sch_plug module in upstream linux. <br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div><p>
2) If i comment out the lines in the "postsuspend" and "commit" lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and=20
TC_PLUG_RELEASE, i see that all the network packets are being buffered=20=

and i cannot ping the Remus-protected VM at all. Where is the packet=20
buffering happen if i comment out these 2 lines =
?</p></div></div></blockquote><div><br>the module starts out in the =
buffered mode and releases packets only upon receiving a RELEASE =
command.<br><br>hope that helps.<br><br>

cheers<br>shriram<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div><p>Thanking you,<br>
=
Rahul.</p></div></div><br>_______________________________________________<=
br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>=

<a href=3D"http://lists.xen.org/xen-devel" =
target=3D"_blank">http://lists.xen.org/xen-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></body></html>=

--Apple-Mail-9-84343549--


--===============1022036466889103843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1022036466889103843==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 22:17:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 22:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKzfB-0007Nk-Av; Thu, 19 Apr 2012 22:17:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singh.rahul.1983@gmail.com>) id 1SKzfA-0007NY-0q
	for xen-devel@lists.xen.org; Thu, 19 Apr 2012 22:17:16 +0000
Received: from [85.158.143.35:18688] by server-2.bemta-4.messagelabs.com id
	37/37-17550-BEE809F4; Thu, 19 Apr 2012 22:17:15 +0000
X-Env-Sender: singh.rahul.1983@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334873832!12162402!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20204 invoked from network); 19 Apr 2012 22:17:13 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 22:17:13 -0000
Received: by qcsc20 with SMTP id c20so6870069qcs.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 15:17:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to:x-mailer;
	bh=JJotImx/ddmXz6FvJY0C8mVlnM0ZO155HzXteHkW8ac=;
	b=PdJY53Ae2EmOqKosFZ+g+uaUVHKPr8taAzMBzx2CaUPPL59/c0b0coKg0MqNs0JLNo
	cbGX2UCN2zvGPf5LWTcE4FlnXrme8+Rzxi/iPCPgT6ZpCcpzXCb7MSSqr39beCNAoU4Z
	9z6CN9n5mmMQ9Hf0gy2xknfN0QXn5lXdgJjKkAP35qcwi5MiEsF0xPmwt3PTzTalAsvX
	bAViDTPeSujHp/AVZFNpdemLBpy0J21TJ5ymYjMMxCtW5d37yPQS+6Fok5hqC8bYfc58
	+Mlho4IVGr5HXcLS1BW4owRNFLfzHFJN0rMug2drTtRESTD4OkeM40u8tvp5mQ4266Xt
	tA0w==
Received: by 10.224.102.8 with SMTP id e8mr5463245qao.50.1334873831866;
	Thu, 19 Apr 2012 15:17:11 -0700 (PDT)
Received: from moblix.cs.umass.edu (moblix.cs.umass.edu. [128.119.245.142])
	by mx.google.com with ESMTPS id c3sm6683546qap.20.2012.04.19.15.17.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 15:17:10 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Rahul Singh <singh.rahul.1983@gmail.com>
In-Reply-To: <CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
Date: Thu, 19 Apr 2012 18:17:08 -0400
Message-Id: <9792753F-4FB1-4C89-9E42-E609B116851B@gmail.com>
References: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
	<CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
To: rshriram@cs.ubc.ca
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1022036466889103843=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1022036466889103843==
Content-Type: multipart/alternative; boundary=Apple-Mail-9-84343549


--Apple-Mail-9-84343549
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks for pointing me to the comments, Shriram. That was very helpful.

What i am unable to figure out is how does Remus tell the module to only =
release packets belonging to a given epoch ? I am looking at the =
BufferedNIC class in xen-unstable/tools/python/xen/remus/device.py and =
the postsuspend method calls self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) =
while the commit method calls self._sendqmsg(qdisc.TC_PLUG_RELEASE). =
Where is it telling that only packets of the last epoch should be =
released ?

Also, as you said that module starts out with buffering everything. So =
if i comment out the self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) but keep =
the self._sendqmsg(qdisc.TC_PLUG_RELEASE), there should be no network =
buffering at all, but i still see that all packets are buffered.

Thanking you,
Rahul.

On Apr 19, 2012, at 5:24 PM, Shriram Rajagopalan wrote:

> On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh =
<singh.rahul.1983@gmail.com> wrote:
> Hi,
> I am trying to understand and change the network buffering that is =
being used by Remus, the HA solution present in Xen. =46rom what i =
understood from reading the code, Remus calls the postsuspend method of =
the BufferedNIC after it suspends the domain that sends =
TC_PLUG_CHECKPOINT message and start the buffering
>=20
> for packets in the "next" epoch [the one that starts after the domain =
is resumed]
> =20
> and then calls the commit method of BufferedNIC after it gets the =
acknowledgement that sends the TC_PLUG_RELEASE message and releases the =
buffered packets.
>=20
> of the previous current epoch [the one whose checkpoint was just =
committed on the backup machine]
> =20
> I have the following doubts
> 1) How does remus ensure that the packets gets buffered for an entire =
epoch ?
>=20
> I would suggest you go through the comments in=20
> =
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dblo=
b;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829861285c0c8f8b7;hb=
=3DHEAD
> the sch_plug module in upstream linux.=20
> 2) If i comment out the lines in the "postsuspend" and "commit" lines =
of the BufferedNIC class that send the TC_PLUG_CHECKPOINT and =
TC_PLUG_RELEASE, i see that all the network packets are being buffered =
and i cannot ping the Remus-protected VM at all. Where is the packet =
buffering happen if i comment out these 2 lines ?
>=20
>=20
> the module starts out in the buffered mode and releases packets only =
upon receiving a RELEASE command.
>=20
> hope that helps.
>=20
> cheers
> shriram
> =20
> Thanking you,
> Rahul.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20
>=20


--Apple-Mail-9-84343549
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Thanks for pointing me to the comments, Shriram. That was very =
helpful.<div><br></div><div>What i am unable to figure out is how does =
Remus tell the module to only release packets belonging to a given epoch =
? I am looking at the BufferedNIC class in =
xen-unstable/tools/python/xen/remus/device.py and the postsuspend method =
calls&nbsp;self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) while the commit =
method calls&nbsp;self._sendqmsg(qdisc.TC_PLUG_RELEASE). Where is it =
telling that only packets of the last epoch should be released =
?</div><div><br></div><div>Also, as you said that module starts out with =
buffering everything. So if i comment out =
the&nbsp;self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) but keep =
the&nbsp;self._sendqmsg(qdisc.TC_PLUG_RELEASE), there should be no =
network buffering at all, but i still see that all packets are =
buffered.</div><div><br></div><div>Thanking =
you,</div><div>Rahul.</div><div><div><br><div><div>On Apr 19, 2012, at =
5:24 PM, Shriram Rajagopalan wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
class=3D"gmail_quote">On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <span =
dir=3D"ltr">&lt;<a =
href=3D"mailto:singh.rahul.1983@gmail.com">singh.rahul.1983@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. =46rom what i understood =
from reading the code, Remus=20
calls the postsuspend method of the BufferedNIC after it suspends the=20
domain that sends TC_PLUG_CHECKPOINT message and start the =
buffering</p></div></div></blockquote><div>for packets in the "next" =
epoch [the one that starts after the domain is =
resumed]<br>&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p> and
 then calls the commit method of BufferedNIC after it gets the=20
acknowledgement that sends the TC_PLUG_RELEASE message and releases the=20=

buffered packets. </p></div></div></blockquote><div>of the previous =
current epoch [the one whose checkpoint was just committed on the backup =
machine]<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>I have the following =
doubts<br>
1) How does remus ensure that the packets gets buffered for an entire =
epoch ?<br></p></div></div></blockquote><div>I would suggest you go =
through the comments in <br><a =
href=3D"http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git=
;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829861285c0c=
8f8b7;hb=3DHEAD">http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
x-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829=
861285c0c8f8b7;hb=3DHEAD</a><br>

the sch_plug module in upstream linux. <br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div><p>
2) If i comment out the lines in the "postsuspend" and "commit" lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and=20
TC_PLUG_RELEASE, i see that all the network packets are being buffered=20=

and i cannot ping the Remus-protected VM at all. Where is the packet=20
buffering happen if i comment out these 2 lines =
?</p></div></div></blockquote><div><br>the module starts out in the =
buffered mode and releases packets only upon receiving a RELEASE =
command.<br><br>hope that helps.<br><br>

cheers<br>shriram<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div><p>Thanking you,<br>
=
Rahul.</p></div></div><br>_______________________________________________<=
br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>=

<a href=3D"http://lists.xen.org/xen-devel" =
target=3D"_blank">http://lists.xen.org/xen-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></body></html>=

--Apple-Mail-9-84343549--


--===============1022036466889103843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1022036466889103843==--


From xen-devel-bounces@lists.xen.org Thu Apr 19 22:26:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 22:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKznP-0007mf-FL; Thu, 19 Apr 2012 22:25:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SKznN-0007mX-Ma
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 22:25:45 +0000
Received: from [85.158.143.99:34199] by server-2.bemta-4.messagelabs.com id
	6B/8C-17550-8E0909F4; Thu, 19 Apr 2012 22:25:44 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334874341!25873058!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13867 invoked from network); 19 Apr 2012 22:25:43 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 22:25:43 -0000
Received: by obbtb18 with SMTP id tb18so8830846obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 15:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=fHrT3OXz85uIxCjyM85pJ00H7Tz9hwZ8sP6ScdbWcnQ=;
	b=HTqNpwN8ILu0jZw1sHQ7Ue9JtW+4tAQev1U141+3e16lA44nG2e74QEJluWQa/Qhkx
	5Q5g5zU6rdxO4hh2nN7a/rtFqluwlRTCZV2NwIgJVvYbfS9dTeQUFc4ueXOWbiuvevmM
	ebGQdMmVbDEsvw+dSPLmyVQET24HqnDJYHrv8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=fHrT3OXz85uIxCjyM85pJ00H7Tz9hwZ8sP6ScdbWcnQ=;
	b=m1qGtB4xGxBPawhmV1RZSo7tfxsYLCSumqob+Fpc/O7NSBGSe18fSiRxCWpkNDAB7h
	CYb+ByzprV9ih6+zJWYKV05WvJfcbpcnlKD1NAmdtmkw2G6pRI/8JnC0JSaaZI62M+P9
	gxfB9NpBAwIxQBl8MQYUrf8BHENt+TiyWCtlxysAQKD7IwEqGNf3I5QMO97dRbbzbJGV
	3emKBhPpbWz2iAfLGnELbSB6i2vw0IzmImfasuLwjgu81v2p/efYT2BQuRjS+bmWgMq9
	AxomisPbLmKa8muZiZXqkaaIgAfFtKNTMq8z8c072bKoZXv3/78c9AqnfQ72F5OnTdk2
	SUqw==
Received: by 10.182.202.69 with SMTP id kg5mr5662848obc.35.1334874340881;
	Thu, 19 Apr 2012 15:25:40 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-73.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.73])
	by mx.google.com with ESMTPS id a8sm3587558oea.8.2012.04.19.15.25.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 15:25:40 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2f68aefc46c35ef5c0c309e10a1c30de363539fc
Message-Id: <2f68aefc46c35ef5c0c3.1334874293@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 19 Apr 2012 15:24:53 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnR+GYUIz16+1g18m814O3fyROhFuQmqCMpunUyASlvEjkj0VSLMlXggBkjWAyd1PJ+zhk/
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap().

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
@@ -39,6 +39,7 @@
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
 
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
@@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT),
+                              PROT_READ | PROT_WRITE,
+                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+        if ( pfn == MAP_FAILED )
+        {
+            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+            return NULL;
+        }
 
         memcpy(pfn, arr, num * sizeof(*arr));
 
@@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
             break;
         }
 
+        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
+
         if ( rc == -ENOENT && i == num )
             rc = 0;
         else if ( rc )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 19 22:26:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Apr 2012 22:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SKznP-0007mf-FL; Thu, 19 Apr 2012 22:25:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SKznN-0007mX-Ma
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 22:25:45 +0000
Received: from [85.158.143.99:34199] by server-2.bemta-4.messagelabs.com id
	6B/8C-17550-8E0909F4; Thu, 19 Apr 2012 22:25:44 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334874341!25873058!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13867 invoked from network); 19 Apr 2012 22:25:43 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Apr 2012 22:25:43 -0000
Received: by obbtb18 with SMTP id tb18so8830846obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 15:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=fHrT3OXz85uIxCjyM85pJ00H7Tz9hwZ8sP6ScdbWcnQ=;
	b=HTqNpwN8ILu0jZw1sHQ7Ue9JtW+4tAQev1U141+3e16lA44nG2e74QEJluWQa/Qhkx
	5Q5g5zU6rdxO4hh2nN7a/rtFqluwlRTCZV2NwIgJVvYbfS9dTeQUFc4ueXOWbiuvevmM
	ebGQdMmVbDEsvw+dSPLmyVQET24HqnDJYHrv8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=fHrT3OXz85uIxCjyM85pJ00H7Tz9hwZ8sP6ScdbWcnQ=;
	b=m1qGtB4xGxBPawhmV1RZSo7tfxsYLCSumqob+Fpc/O7NSBGSe18fSiRxCWpkNDAB7h
	CYb+ByzprV9ih6+zJWYKV05WvJfcbpcnlKD1NAmdtmkw2G6pRI/8JnC0JSaaZI62M+P9
	gxfB9NpBAwIxQBl8MQYUrf8BHENt+TiyWCtlxysAQKD7IwEqGNf3I5QMO97dRbbzbJGV
	3emKBhPpbWz2iAfLGnELbSB6i2vw0IzmImfasuLwjgu81v2p/efYT2BQuRjS+bmWgMq9
	AxomisPbLmKa8muZiZXqkaaIgAfFtKNTMq8z8c072bKoZXv3/78c9AqnfQ72F5OnTdk2
	SUqw==
Received: by 10.182.202.69 with SMTP id kg5mr5662848obc.35.1334874340881;
	Thu, 19 Apr 2012 15:25:40 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-73.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.73])
	by mx.google.com with ESMTPS id a8sm3587558oea.8.2012.04.19.15.25.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 15:25:40 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2f68aefc46c35ef5c0c309e10a1c30de363539fc
Message-Id: <2f68aefc46c35ef5c0c3.1334874293@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 19 Apr 2012 15:24:53 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnR+GYUIz16+1g18m814O3fyROhFuQmqCMpunUyASlvEjkj0VSLMlXggBkjWAyd1PJ+zhk/
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap().

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
@@ -39,6 +39,7 @@
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
 
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
@@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT),
+                              PROT_READ | PROT_WRITE,
+                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+        if ( pfn == MAP_FAILED )
+        {
+            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+            return NULL;
+        }
 
         memcpy(pfn, arr, num * sizeof(*arr));
 
@@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
             break;
         }
 
+        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
+
         if ( rc == -ENOENT && i == num )
             rc = 0;
         else if ( rc )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 00:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 00:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL1tA-0001W9-Bm; Fri, 20 Apr 2012 00:39:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SL1t9-0001W4-0m
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 00:39:51 +0000
Received: from [85.158.143.99:33897] by server-2.bemta-4.messagelabs.com id
	2B/2C-17550-650B09F4; Fri, 20 Apr 2012 00:39:50 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334882375!19191628!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20926 invoked from network); 20 Apr 2012 00:39:35 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 00:39:35 -0000
Received: by bkcji1 with SMTP id ji1so973956bkc.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 17:39:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=Un2DBIACGoYmBH3jDoDkavIoPznlS4ZEA+VBYD6X3uA=;
	b=hRmCnN0Mafth8kHH+S7pNQLsRrWlWszmFmbMolt8E2/8PyJeLj52yS/NpePGL/5HDg
	ProvI+KXDX8HqK8MIHbz20as8x15359Cy1/lD58tiaP4bgUX4uBT9dSIL9NzwrmrklYV
	G9862bwoWMG30Pa4gXlfTyhFjDvQgXuLT+gklXAQGZWMkbt3DUEZEtk48VfohvsZAl71
	kmd4KEeqdV93G51ubFJMvrHOHvXGero3BakIowegHP2wN7XY0qras7xOc18J+jwNSqF2
	6XVCi3uWSMwPEJRoGrVya0+KnNaB/Ivspo4yUABIh9Wl87cf9ecvIA0/uq58RcRB89gr
	clqw==
MIME-Version: 1.0
Received: by 10.205.117.15 with SMTP id fk15mr1246639bkc.133.1334882374072;
	Thu, 19 Apr 2012 17:39:34 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Thu, 19 Apr 2012 17:39:33 -0700 (PDT)
In-Reply-To: <4400B41FB768044EA720935D0808176C090BD76C@sausexdag02.amd.com>
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
	<4F7B66A3.3080802@amd.com>
	<CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
	<CACC+8CTGuZBhM7HJPiQSXwmkAe487iOz00AsnPZ6MB58nb8b1g@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD76C@sausexdag02.amd.com>
Date: Fri, 20 Apr 2012 02:39:33 +0200
Message-ID: <CACC+8CS3+5UYa=cOZXwuMzDqRxH6SDc-M=v13GpYpKz=5LZV2g@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: Wei Huang <wei.huang2@amd.com>, xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=0015174781feb93a3404be11855f
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--0015174781feb93a3404be11855f
Content-Type: multipart/alternative; boundary=0015174781feb93a2d04be11855d

--0015174781feb93a2d04be11855d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I was busy too, but finally i get around to test the patch, i have compile
it with just "make"
in xen-unstable.hg/tools/qemu-xen-traditional-dir-remote/
and then copy it over, but it wont start with gfx_passthru=3D1,

.......
IRQ type =3D INTx
pt_iomem_map: e_phys=3De0000000 maddr=3Db0000000 type=3D8 len=3D268435456 i=
ndex=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1020000 maddr=3Dfa4e0000 type=3D0 len=3D131072 inde=
x=3D2
first_map=3D1
pt_iomem_map: e_phys=3Df1060000 maddr=3Dfa4bc000 type=3D0 len=3D16384 index=
=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1064000 maddr=3Dfadfe000 type=3D0 len=3D8192 index=
=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1066000 maddr=3Dfa3f6000 type=3D0 len=3D4096 index=
=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1067000 maddr=3Dfa3fc000 type=3D0 len=3D4096 index=
=3D0
first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3D7000 len=3D256 index=3D4 first_map=
=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3D7000 len=3D256 index=3D4 first_map=
=3D0
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
ati_gfx_init: ATI GFX Guest Info:
       pio_index=3D0x00000004,       guest_pio_bar=3D0x0000c100
       mmio_bar1_index=3D0x00000000, guest_mmio_bar1=3D0xe0000000
       mmio_bar2_index=3D0x00000002, guest_mmio_bar2=3D0xf1020000
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw
state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro
state.


Best Regards,
Kristijan Lecnik

On Fri, Apr 13, 2012 at 5:33 PM, Huang2, Wei <Wei.Huang2@amd.com> wrote:

>  Hi Kristijan,****
>
> ** **
>
> Sorry, was busy recently. Stub domain failure is OK. I think Ian (or
> someone else) reported it before. You can do the following steps:****
>
> ** **
>
> **1.      **Apply the patch****
>
> **2.      **Go to xen-unstable.hg/tools/qemu-xen-traditional-dir-remote/
> and compile it****
>
> **3.      **You will get an un-stripped qemu-dm under i386-dm/****
>
> **4.      **Copy it to your destination to replace existing
> /usr/lib/xen/bin/qemu-dm file****
>
> ** **
>
> ** **
>
> -Wei****
>
> ** **
>
> *From:* Kristijan Le=C4=8Dnik [mailto:janez3k@gmail.com]
> *Sent:* Friday, April 13, 2012 6:57 AM
> *To:* Huang2, Wei
> *Subject:* Fwd: [Xen-devel] AMD/ATI patch for xen 4.2-unstable****
>
> ** **
>
> Hi,
>
> i am sorry to bother you, but did you manage to see my errors, with the
> new patch?
>
> Best Regards,
> Kristijan Lecnik****
>
> ---------- Forwarded message ----------
> From: *Kristijan Le=C4=8Dnik* <janez3k@gmail.com>
> Date: Sun, Apr 8, 2012 at 3:37 PM
> Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
> To: wei.huang2@amd.com
> Cc: xen-devel@lists.xen.org
>
>
> Hi,****
>
> ** **
>
> just try to compile with xen unstable 4.2 repo from 8.april 2012****
>
> ** **
>
> make --directory=3Darch/x86
> OBJ_DIR=3D/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || =
exit
> 1;****
>
> make[3]: Entering directory `/root/xen-unstable.hg/extras/mini-os/arch/x8=
6'
> ****
>
> make[3]: Nothing to be done for `all'.****
>
> make[3]: Leaving directory `/root/xen-unstable.hg/extras/mini-os/arch/x86=
'
> ****
>
> ld -r -nostdlib
> -L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
> elf_x86_64
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86/x86_64.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os_app.o
>  /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/blkfront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gntmap.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gnttab.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/hypervisor.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lock.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/main.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mm.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/netfront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/sched.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/ctype.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/math.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/printf.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/stack_chk_fail.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/string.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xmalloc.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/xenbus/xenbus.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/console.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xencons_ring.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xenbus.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwip.a
> -L/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64  -=
lc
> -o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o****
>
> objcopy -w -G xenos_* -G _start
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o****
>
> ld -nostdlib
> -L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
> elf_x86_64 -T arch/x86/minios-x86_64.lds
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o  -o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os****
>
> ld: warning: section `.bss' type changed to PROGBITS****
>
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
> `ati_hw_out':****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:82: undefined
> reference to `ioperm'****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:84: undefined
> reference to `ioperm'****
>
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
> `ati_hw_in':****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:72: undefined
> reference to `ioperm'****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:74: undefined
> reference to `ioperm'****
>
> make[2]: *** [/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os]
> Error 1****
>
> make[2]: Leaving directory `/root/xen-unstable.hg/extras/mini-os'****
>
> make[1]: *** [ioemu-stubdom] Error 2****
>
> make[1]: Leaving directory `/root/xen-unstable.hg/stubdom'****
>
> make: *** [install-stubdom] Error 2****
>
> ** **
>
> using linux kernel 3.3****
>
> ** **
>
> nm /usr/lib/libc.a |grep -i ioperm****
>
> ioperm.o:****
>
> 0000000000000000 T ioperm****
>
> ** **
>
> Best Regards,****
>
> Kristijan Lecnik****
>
> ** **
>
> ** **
>
> On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang <wei.huang2@amd.com> wrote:***=
*
>
> I just re-spin the patch, but haven't tested it yet. You want to try it
> (attached)? Make sure you are using AMD GPU as the primary.
>
> -Wei****
>
>
>
>
> On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote: ****
>
> Hi, ****
>
> ** **
>
> i am trying to apply AMD/ATI patch on xen4-2 unstable****
>
>
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN=
3jloS.txt
> ****
>
> ** **
>
> and there was some changes in code and the patch is unusable, is there a
> new patch. or can somebody help me to update the patch?****
>
> ** **
>
> make[4]: Entering directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
> ****
>
>   CC    i386-dm/pt-graphics.o****
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_register_vga_regions=E2=80=99:****
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:373:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:374:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_unregister_vga_regions=E2=80=99:****
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:396:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:397:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> make[4]: *** [pt-graphics.o] Error 1****
>
> make[4]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
> ****
>
> make[3]: *** [subdir-i386-dm] Error 2****
>
> make[3]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te'
> ****
>
> make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2****
>
> make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'**=
*
> *
>
> make[1]: *** [subdirs-install] Error 2****
>
> make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'**=
*
> *
>
> make: *** [install-tools] Error 2****
>
> ** **
>
>
> http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-=
pt-pci-host-read-write-td5016713.html
> ****
>
> ** **
>
> example:****
>
> ** **
>
> old syle:****
>
> vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);****
>
> ** **
>
> new syle:****
>
> vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);****
>
> ** **
>
> Best Regards,****
>
> Kristijan Le=C4=8Dnik****
>
> ** **
>
> ** **
>
> ** **
>

--0015174781feb93a2d04be11855d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I was busy too, but finally i get around to test the=
 patch, i have compile it with just &quot;make&quot; in=C2=A0xen-unstable.h=
g/tools/qemu-xen-traditional-dir-remote/</div><div>and then copy it over, b=
ut it wont start with=C2=A0gfx_passthru=3D1,</div>
<div><br></div><div>.......</div><div>IRQ type =3D INTx</div><div>pt_iomem_=
map: e_phys=3De0000000 maddr=3Db0000000 type=3D8 len=3D268435456 index=3D0 =
first_map=3D1</div><div>pt_iomem_map: e_phys=3Df1020000 maddr=3Dfa4e0000 ty=
pe=3D0 len=3D131072 index=3D2 first_map=3D1</div>
<div>pt_iomem_map: e_phys=3Df1060000 maddr=3Dfa4bc000 type=3D0 len=3D16384 =
index=3D0 first_map=3D1</div><div>pt_iomem_map: e_phys=3Df1064000 maddr=3Df=
adfe000 type=3D0 len=3D8192 index=3D0 first_map=3D1</div><div>pt_iomem_map:=
 e_phys=3Df1066000 maddr=3Dfa3f6000 type=3D0 len=3D4096 index=3D0 first_map=
=3D1</div>
<div>pt_iomem_map: e_phys=3Df1067000 maddr=3Dfa3fc000 type=3D0 len=3D4096 i=
ndex=3D0 first_map=3D1</div><div>pt_ioport_map: e_phys=3Dc100 pio_base=3D70=
00 len=3D256 index=3D4 first_map=3D1</div><div>pt_ioport_map: e_phys=3Dc100=
 pio_base=3D7000 len=3D256 index=3D4 first_map=3D0</div>
<div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled</div><div=
>ati_gfx_init: ATI GFX Guest Info:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0pio=
_index=3D0x00000004, =C2=A0 =C2=A0 =C2=A0 guest_pio_bar=3D0x0000c100</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0mmio_bar1_index=3D0x00000000, guest_mmio_bar=
1=3D0xe0000000</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0mmio_bar2_index=3D0x00000002, guest_mmio_ba=
r2=3D0xf1020000</div><div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write =
not handled</div><div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write not =
handled</div><div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write not hand=
led</div>
<div>platform_fixed_ioport: changed ro/rw state of ROM memory area. now is =
rw state.</div><div>platform_fixed_ioport: changed ro/rw state of ROM memor=
y area. now is ro state.</div><div>=C2=A0</div><div><br></div><div>Best Reg=
ards,</div>
<div>Kristijan Lecnik</div><div><br><div class=3D"gmail_quote">On Fri, Apr =
13, 2012 at 5:33 PM, Huang2, Wei <span dir=3D"ltr">&lt;<a href=3D"mailto:We=
i.Huang2@amd.com">Wei.Huang2@amd.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">






<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hi Kristijan,<u></u><u></=
u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Sorry, was busy recently.=
 Stub domain failure is OK. I think Ian (or someone else) reported it befor=
e. You can do the following steps:<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>1.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Apply the patch<u></=
u><u></u></span></p>
<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>2.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Go to xen-unstable.h=
g/tools/qemu-xen-traditional-dir-remote/ and compile it<u></u><u></u></span=
></p>

<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>3.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">You will get an un-s=
tripped qemu-dm under i386-dm/<u></u><u></u></span></p>
<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>4.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Copy it to your dest=
ination to replace existing /usr/lib/xen/bin/qemu-dm file<u></u><u></u></sp=
an></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">-Wei<u></u><u></u></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Kristija=
n Le=C4=8Dnik [mailto:<a href=3D"mailto:janez3k@gmail.com" target=3D"_blank=
">janez3k@gmail.com</a>]
<br>
<b>Sent:</b> Friday, April 13, 2012 6:57 AM<br>
<b>To:</b> Huang2, Wei<br>
<b>Subject:</b> Fwd: [Xen-devel] AMD/ATI patch for xen 4.2-unstable<u></u><=
u></u></span></p>
</div><div><div class=3D"h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<br>
<br>
i am sorry to bother you, but did you manage to see my errors, with the new=
 patch?<br>
<br>
Best Regards,<br>
Kristijan Lecnik<u></u><u></u></p>
<div>
<p class=3D"MsoNormal">---------- Forwarded message ----------<br>
From: <b>Kristijan Le=C4=8Dnik</b> &lt;<a href=3D"mailto:janez3k@gmail.com"=
 target=3D"_blank">janez3k@gmail.com</a>&gt;<br>
Date: Sun, Apr 8, 2012 at 3:37 PM<br>
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable<br>
To: <a href=3D"mailto:wei.huang2@amd.com" target=3D"_blank">wei.huang2@amd.=
com</a><br>
Cc: <a href=3D"mailto:xen-devel@lists.xen.org" target=3D"_blank">xen-devel@=
lists.xen.org</a><br>
<br>
<br>
Hi,<u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">just try to compile with xen unstable 4.2 repo from =
8.april 2012<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">make --directory=3Darch/x86 OBJ_DIR=3D/root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || exit 1;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Entering directory `/root/xen-unstable.hg/e=
xtras/mini-os/arch/x86&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Nothing to be done for `all&#39;.<u></u><u>=
</u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Leaving directory `/root/xen-unstable.hg/ex=
tras/mini-os/arch/x86&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">ld -r -nostdlib -L/root/xen-unstable.hg/stubdom/cros=
s-root-x86_64/x86_64-xen-elf/lib =C2=A0-m elf_x86_64 /root/xen-unstable.hg/=
stubdom/mini-os-x86_64-ioemu/arch/x86/x86_64.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/mini-os_app.o =C2=A0/root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/blkfront.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/gntmap.o /root/xen-unstable.hg/stubdom/mini-os-x86_6=
4-ioemu/gnttab.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/hypervi=
sor.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/lock.o /root/xen-unstable.hg/stubdom/m=
ini-os-x86_64-ioemu/main.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioe=
mu/mm.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/netfront.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o /root/xen-un=
stable.hg/stubdom/mini-os-x86_64-ioemu/sched.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/lib/ctype.o /root/xen-unstable.hg/stubdom/mini-os-x8=
6_64-ioemu/lib/math.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/li=
b/printf.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/stack_chk_fail.o /r=
oot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/string.o /root/xen-uns=
table.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o /root/xen-unstable.hg/stubd=
om/mini-os-x86_64-ioemu/lib/xmalloc.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/xenbus/xenbus.o /root/xen-unstable.hg/=
stubdom/mini-os-x86_64-ioemu/console/console.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/console/xencons_ring.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xenbus.o /root/=
xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwip.a -L/root/xen-unstable.hg=
/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64 =C2=A0-lc -o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o<u></u><u></u></p>

</div>
<div>
<p class=3D"MsoNormal">objcopy -w -G xenos_* -G _start /root/xen-unstable.h=
g/stubdom/mini-os-x86_64-ioemu/mini-os.o /root/xen-unstable.hg/stubdom/mini=
-os-x86_64-ioemu/mini-os.o<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">ld -nostdlib -L/root/xen-unstable.hg/stubdom/cross-r=
oot-x86_64/x86_64-xen-elf/lib =C2=A0-m elf_x86_64 -T arch/x86/minios-x86_64=
.lds /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o =C2=A0-o =
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os<u></u><u></u></p=
>

</div>
<div>
<p class=3D"MsoNormal">ld: warning: section `.bss&#39; type changed to PROG=
BITS<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/m=
ini-os.o: In function `ati_hw_out&#39;:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:82: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:84: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/m=
ini-os.o: In function `ati_hw_in&#39;:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:72: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:74: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: *** [/root/xen-unstable.hg/stubdom/mini-os-=
x86_64-ioemu/mini-os] Error 1<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: Leaving directory `/root/xen-unstable.hg/ex=
tras/mini-os&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: *** [ioemu-stubdom] Error 2<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: Leaving directory `/root/xen-unstable.hg/st=
ubdom&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make: *** [install-stubdom] Error 2<u></u><u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">using linux kernel 3.3<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">nm /usr/lib/libc.a |grep -i ioperm<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">ioperm.o:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">0000000000000000 T ioperm<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Best Regards,<u></u><u></u></p>
</div>
</div>
<div>
<p class=3D"MsoNormal">Kristijan Lecnik<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<p class=3D"MsoNormal">On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang &lt;<a hr=
ef=3D"mailto:wei.huang2@amd.com" target=3D"_blank">wei.huang2@amd.com</a>&g=
t; wrote:<u></u><u></u></p>
<div>
<p class=3D"MsoNormal">I just re-spin the patch, but haven&#39;t tested it =
yet. You want to try it (attached)? Make sure you are using AMD GPU as the =
primary.<span style=3D"color:#888888"><br>
<br>
-Wei</span><u></u><u></u></p>
<div>
<div>
<p class=3D"MsoNormal"><br>
<br>
<br>
On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote: <u></u><u></u></p>
<p class=3D"MsoNormal">Hi, <u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">i am trying to apply AMD/ATI patch on xen4-2 unstabl=
e<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://old-list-archives.xen.org/archives=
/html/xen-devel/2010-12/txtNwRlN3jloS.txt" target=3D"_blank">http://old-lis=
t-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN3jloS.txt</a><u>=
</u><u></u></p>

</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">and there was some changes in code and the patch is =
unusable, is there a new patch. or can somebody help me to update the patch=
?<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">make[4]: Entering directory `/root/xen-unstable.hg-I=
N_USE_PATCHED/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;<u></u><u><=
/u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o<u></u><=
u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c: In function =E2=80=98igd_register_vga_reg=
ions=E2=80=99:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:373: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:374: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c: In function =E2=80=98igd_unregister_vga_r=
egions=E2=80=99:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:396: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:397: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[4]: *** [pt-graphics.o] Error 1<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal">make[4]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;<u></u><u></=
u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: *** [subdir-i386-dm] Error 2<u></u><u></u><=
/p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools/qemu-xen-traditional-dir-remote&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: *** [subdir-install-qemu-xen-traditional-di=
r] Error 2<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: *** [subdirs-install] Error 2<u></u><u></u>=
</p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make: *** [install-tools] Error 2<u></u><u></u></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://xen.1045712.n5.nabble.com/PATCH-1-=
3-qemu-xen-Change-prototype-for-pt-pci-host-read-write-td5016713.html" targ=
et=3D"_blank">http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-pr=
ototype-for-pt-pci-host-read-write-td5016713.html</a><u></u><u></u></p>

</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">example:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">old syle:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);<u></u=
><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">new syle:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, =
2);<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Best Regards,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Kristijan Le=C4=8Dnik<u></u><u></u></p>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
</div>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
</div>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div></div></div>
</div>

</blockquote></div><br></div>

--0015174781feb93a2d04be11855d--
--0015174781feb93a3404be11855f
Content-Type: application/octet-stream; name="qemu-dm-win7.log.1"
Content-Disposition: attachment; filename="qemu-dm-win7.log.1"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h18ihjlg0

ZG9taWQ6IDMKU3RyaXAgb2ZmIGJsa3RhcCBzdWItdHlwZSBwcmVmaXggdG8gL3hlbi93aW43LnFj
b3cyIChkcnYgJ3Fjb3cyJykKVXNpbmcgZmlsZSAveGVuL3dpbjcucWNvdzIgaW4gcmVhZC13cml0
ZSBtb2RlCldhdGNoaW5nIC9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvMy9sb2dkaXJ0eS9j
bWQKV2F0Y2hpbmcgL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8zL2NvbW1hbmQKV2F0Y2hp
bmcgL2xvY2FsL2RvbWFpbi8zL2NwdQpjaGFyIGRldmljZSByZWRpcmVjdGVkIHRvIC9kZXYvcHRz
LzIKcWVtdV9tYXBfY2FjaGVfaW5pdCBucl9idWNrZXRzID0gMTAwMDAgc2l6ZSA0MTk0MzA0CnNo
YXJlZCBwYWdlIGF0IHBmbiBmZWZmZApidWZmZXJlZCBpbyBwYWdlIGF0IHBmbiBmZWZmYgpHdWVz
dCB1dWlkID0gZGIyZTE0ODQtMjExNS00YTJjLWJiODktYzhmOTliZmU1MDBkClJlZ2lzdGVyIHhl
biBwbGF0Zm9ybS4KRG9uZSByZWdpc3RlciBwbGF0Zm9ybS4KcGxhdGZvcm1fZml4ZWRfaW9wb3J0
OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBtZW1vcnkgYXJlYS4gbm93IGlzIHJ3IHN0YXRl
Lgp4c19yZWFkKC9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvMy94ZW5fZXh0ZW5kZWRfcG93
ZXJfbWdtdCk6IHJlYWQgZXJyb3IKTG9nLWRpcnR5OiBubyBjb21tYW5kIHlldC4KSS9PIHJlcXVl
c3Qgbm90IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXpl
OiAwCkkvTyByZXF1ZXN0IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBj
b3VudDogMCwgc2l6ZTogMAp2Y3B1LXNldDogd2F0Y2ggbm9kZSBlcnJvci4KSS9PIHJlcXVlc3Qg
bm90IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAw
CnhzX3JlYWQoL2xvY2FsL2RvbWFpbi8zL2xvZy10aHJvdHRsaW5nKTogcmVhZCBlcnJvcgpxZW11
OiBpZ25vcmluZyBub3QtdW5kZXJzdG9vZCBkcml2ZSBgL2xvY2FsL2RvbWFpbi8zL2xvZy10aHJv
dHRsaW5nJwptZWRpdW0gY2hhbmdlIHdhdGNoIG9uIGAvbG9jYWwvZG9tYWluLzMvbG9nLXRocm90
dGxpbmcnIC0gdW5rbm93biBkZXZpY2UsIGlnbm9yZWQKSS9PIHJlcXVlc3Qgbm90IHJlYWR5OiAw
LCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwCmRtLWNvbW1hbmQ6
IGhvdCBpbnNlcnQgcGFzcy10aHJvdWdoIHBjaSBkZXYgCnJlZ2lzdGVyX3JlYWxfZGV2aWNlOiBB
c3NpZ25pbmcgcmVhbCBwaHlzaWNhbCBkZXZpY2UgMDE6MDAuMCAuLi4KcHRfaW9tdWxfaW5pdDog
RXJyb3I6IHB0X2lvbXVsX2luaXQgY2FuJ3Qgb3BlbiBmaWxlIC9kZXYveGVuL3BjaV9pb211bDog
Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeTogMHgxOjB4MC4weDAKcHRfcmVnaXN0ZXJfcmVnaW9u
czogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgxMDAwMDAwMCBiYXNlX2FkZHI9MHhiMDAw
MDAwYykKcHRfcmVnaXN0ZXJfcmVnaW9uczogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgw
MDAyMDAwMCBiYXNlX2FkZHI9MHhmYTRlMDAwNCkKcHRfcmVnaXN0ZXJfcmVnaW9uczogSU8gcmVn
aW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMDEwMCBiYXNlX2FkZHI9MHgwMDAwNzAwMSkKcHRf
cmVnaXN0ZXJfcmVnaW9uczogRXhwYW5zaW9uIFJPTSByZWdpc3RlcmVkIChzaXplPTB4MDAwMjAw
MDAgYmFzZV9hZGRyPTB4ZmE0YzAwMDApCnB0X21zaV9zZXR1cDogbXNpIG1hcHBlZCB3aXRoIHBp
cnEgMzcKcGNpX2ludHg6IGludHg9MQpyZWdpc3Rlcl9yZWFsX2RldmljZTogUmVhbCBwaHlzaWNh
bCBkZXZpY2UgMDE6MDAuMCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWx5IQpJUlEgdHlwZSA9IE1TSS1J
TlR4CmRtLWNvbW1hbmQ6IGhvdCBpbnNlcnQgcGFzcy10aHJvdWdoIHBjaSBkZXYgCnJlZ2lzdGVy
X3JlYWxfZGV2aWNlOiBBc3NpZ25pbmcgcmVhbCBwaHlzaWNhbCBkZXZpY2UgMDE6MDAuMSAuLi4K
cHRfaW9tdWxfaW5pdDogRXJyb3I6IHB0X2lvbXVsX2luaXQgY2FuJ3Qgb3BlbiBmaWxlIC9kZXYv
eGVuL3BjaV9pb211bDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeTogMHgxOjB4MC4weDEKcHRf
cmVnaXN0ZXJfcmVnaW9uczogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwNDAwMCBi
YXNlX2FkZHI9MHhmYTRiYzAwNCkKcHRfbXNpX3NldHVwOiBtc2kgbWFwcGVkIHdpdGggcGlycSAz
NgpwY2lfaW50eDogaW50eD0yCnJlZ2lzdGVyX3JlYWxfZGV2aWNlOiBSZWFsIHBoeXNpY2FsIGRl
dmljZSAwMTowMC4xIHJlZ2lzdGVyZWQgc3VjY2Vzc2Z1bHkhCklSUSB0eXBlID0gTVNJLUlOVHgK
ZG0tY29tbWFuZDogaG90IGluc2VydCBwYXNzLXRocm91Z2ggcGNpIGRldiAKcmVnaXN0ZXJfcmVh
bF9kZXZpY2U6IEFzc2lnbmluZyByZWFsIHBoeXNpY2FsIGRldmljZSAwYTowMC4wIC4uLgpwdF9p
b211bF9pbml0OiBFcnJvcjogcHRfaW9tdWxfaW5pdCBjYW4ndCBvcGVuIGZpbGUgL2Rldi94ZW4v
cGNpX2lvbXVsOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5OiAweGE6MHgwLjB4MApwdF9yZWdp
c3Rlcl9yZWdpb25zOiBJTyByZWdpb24gcmVnaXN0ZXJlZCAoc2l6ZT0weDAwMDAyMDAwIGJhc2Vf
YWRkcj0weGZhZGZlMDA0KQpwdF9tc2l4X2luaXQ6IGdldCBNU0ktWCB0YWJsZSBiYXIgYmFzZSBm
YWRmZTAwMApwdF9tc2l4X2luaXQ6IHRhYmxlX29mZiA9IDEwMDAsIHRvdGFsX2VudHJpZXMgPSA4
CnB0X21zaXhfaW5pdDogbWFwcGluZyBwaHlzaWNhbCBNU0ktWCB0YWJsZSB0byA3ZmYxOWM2ZGUw
MDAKcHRfbXNpX3NldHVwOiBtc2kgbWFwcGVkIHdpdGggcGlycSAzNQpwY2lfaW50eDogaW50eD0x
CnJlZ2lzdGVyX3JlYWxfZGV2aWNlOiBSZWFsIHBoeXNpY2FsIGRldmljZSAwYTowMC4wIHJlZ2lz
dGVyZWQgc3VjY2Vzc2Z1bHkhCklSUSB0eXBlID0gTVNJLUlOVHgKZG0tY29tbWFuZDogaG90IGlu
c2VydCBwYXNzLXRocm91Z2ggcGNpIGRldiAKcmVnaXN0ZXJfcmVhbF9kZXZpY2U6IEFzc2lnbmlu
ZyByZWFsIHBoeXNpY2FsIGRldmljZSAwMDoxZC4wIC4uLgpwdF9pb211bF9pbml0OiBFcnJvcjog
cHRfaW9tdWxfaW5pdCBjYW4ndCBvcGVuIGZpbGUgL2Rldi94ZW4vcGNpX2lvbXVsOiBObyBzdWNo
IGZpbGUgb3IgZGlyZWN0b3J5OiAweDA6MHgxZC4weDAKcHRfcmVnaXN0ZXJfcmVnaW9uczogSU8g
cmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMDQwMCBiYXNlX2FkZHI9MHhmYTNmNjAwMCkK
cGNpX2ludHg6IGludHg9MQpyZWdpc3Rlcl9yZWFsX2RldmljZTogUmVhbCBwaHlzaWNhbCBkZXZp
Y2UgMDA6MWQuMCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWx5IQpJUlEgdHlwZSA9IElOVHgKZG0tY29t
bWFuZDogaG90IGluc2VydCBwYXNzLXRocm91Z2ggcGNpIGRldiAKcmVnaXN0ZXJfcmVhbF9kZXZp
Y2U6IEFzc2lnbmluZyByZWFsIHBoeXNpY2FsIGRldmljZSAwMDoxYS4wIC4uLgpwdF9pb211bF9p
bml0OiBFcnJvcjogcHRfaW9tdWxfaW5pdCBjYW4ndCBvcGVuIGZpbGUgL2Rldi94ZW4vcGNpX2lv
bXVsOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5OiAweDA6MHgxYS4weDAKcHRfcmVnaXN0ZXJf
cmVnaW9uczogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMDQwMCBiYXNlX2FkZHI9
MHhmYTNmYzAwMCkKcGNpX2ludHg6IGludHg9MQpyZWdpc3Rlcl9yZWFsX2RldmljZTogUmVhbCBw
aHlzaWNhbCBkZXZpY2UgMDA6MWEuMCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWx5IQpJUlEgdHlwZSA9
IElOVHgKcHRfaW9tZW1fbWFwOiBlX3BoeXM9ZTAwMDAwMDAgbWFkZHI9YjAwMDAwMDAgdHlwZT04
IGxlbj0yNjg0MzU0NTYgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb21lbV9tYXA6IGVfcGh5cz1m
MTAyMDAwMCBtYWRkcj1mYTRlMDAwMCB0eXBlPTAgbGVuPTEzMTA3MiBpbmRleD0yIGZpcnN0X21h
cD0xCnB0X2lvbWVtX21hcDogZV9waHlzPWYxMDYwMDAwIG1hZGRyPWZhNGJjMDAwIHR5cGU9MCBs
ZW49MTYzODQgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb21lbV9tYXA6IGVfcGh5cz1mMTA2NDAw
MCBtYWRkcj1mYWRmZTAwMCB0eXBlPTAgbGVuPTgxOTIgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9p
b21lbV9tYXA6IGVfcGh5cz1mMTA2NjAwMCBtYWRkcj1mYTNmNjAwMCB0eXBlPTAgbGVuPTQwOTYg
aW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb21lbV9tYXA6IGVfcGh5cz1mMTA2NzAwMCBtYWRkcj1m
YTNmYzAwMCB0eXBlPTAgbGVuPTQwOTYgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb3BvcnRfbWFw
OiBlX3BoeXM9YzEwMCBwaW9fYmFzZT03MDAwIGxlbj0yNTYgaW5kZXg9NCBmaXJzdF9tYXA9MQpw
dF9pb3BvcnRfbWFwOiBlX3BoeXM9YzEwMCBwaW9fYmFzZT03MDAwIGxlbj0yNTYgaW5kZXg9NCBm
aXJzdF9tYXA9MAphdGlfbGVnYWN5X2lvX3dyaXRlOiBFUlJPUjogcG9ydCAweDNjMyBJL08gd3Jp
dGUgbm90IGhhbmRsZWQKYXRpX2dmeF9pbml0OiBBVEkgR0ZYIEd1ZXN0IEluZm86CiAgICAgICBw
aW9faW5kZXg9MHgwMDAwMDAwNCwgICAgICAgZ3Vlc3RfcGlvX2Jhcj0weDAwMDBjMTAwCiAgICAg
ICBtbWlvX2JhcjFfaW5kZXg9MHgwMDAwMDAwMCwgZ3Vlc3RfbW1pb19iYXIxPTB4ZTAwMDAwMDAK
ICAgICAgIG1taW9fYmFyMl9pbmRleD0weDAwMDAwMDAyLCBndWVzdF9tbWlvX2JhcjI9MHhmMTAy
MDAwMAphdGlfbGVnYWN5X2lvX3dyaXRlOiBFUlJPUjogcG9ydCAweDNjMyBJL08gd3JpdGUgbm90
IGhhbmRsZWQKYXRpX2xlZ2FjeV9pb193cml0ZTogRVJST1I6IHBvcnQgMHgzYzMgSS9PIHdyaXRl
IG5vdCBoYW5kbGVkCmF0aV9sZWdhY3lfaW9fd3JpdGU6IEVSUk9SOiBwb3J0IDB4M2MzIEkvTyB3
cml0ZSBub3QgaGFuZGxlZApwbGF0Zm9ybV9maXhlZF9pb3BvcnQ6IGNoYW5nZWQgcm8vcncgc3Rh
dGUgb2YgUk9NIG1lbW9yeSBhcmVhLiBub3cgaXMgcncgc3RhdGUuCnBsYXRmb3JtX2ZpeGVkX2lv
cG9ydDogY2hhbmdlZCByby9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5vdyBpcyBybyBz
dGF0ZS4K
--0015174781feb93a3404be11855f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--0015174781feb93a3404be11855f--


From xen-devel-bounces@lists.xen.org Fri Apr 20 00:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 00:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL1tA-0001W9-Bm; Fri, 20 Apr 2012 00:39:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SL1t9-0001W4-0m
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 00:39:51 +0000
Received: from [85.158.143.99:33897] by server-2.bemta-4.messagelabs.com id
	2B/2C-17550-650B09F4; Fri, 20 Apr 2012 00:39:50 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334882375!19191628!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20926 invoked from network); 20 Apr 2012 00:39:35 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 00:39:35 -0000
Received: by bkcji1 with SMTP id ji1so973956bkc.32
	for <xen-devel@lists.xen.org>; Thu, 19 Apr 2012 17:39:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=Un2DBIACGoYmBH3jDoDkavIoPznlS4ZEA+VBYD6X3uA=;
	b=hRmCnN0Mafth8kHH+S7pNQLsRrWlWszmFmbMolt8E2/8PyJeLj52yS/NpePGL/5HDg
	ProvI+KXDX8HqK8MIHbz20as8x15359Cy1/lD58tiaP4bgUX4uBT9dSIL9NzwrmrklYV
	G9862bwoWMG30Pa4gXlfTyhFjDvQgXuLT+gklXAQGZWMkbt3DUEZEtk48VfohvsZAl71
	kmd4KEeqdV93G51ubFJMvrHOHvXGero3BakIowegHP2wN7XY0qras7xOc18J+jwNSqF2
	6XVCi3uWSMwPEJRoGrVya0+KnNaB/Ivspo4yUABIh9Wl87cf9ecvIA0/uq58RcRB89gr
	clqw==
MIME-Version: 1.0
Received: by 10.205.117.15 with SMTP id fk15mr1246639bkc.133.1334882374072;
	Thu, 19 Apr 2012 17:39:34 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Thu, 19 Apr 2012 17:39:33 -0700 (PDT)
In-Reply-To: <4400B41FB768044EA720935D0808176C090BD76C@sausexdag02.amd.com>
References: <CACC+8CS13Z8YqviP-rE0Vyi-uxSZwP5c_VUQhyCFHPo4YLB8wg@mail.gmail.com>
	<4F7B66A3.3080802@amd.com>
	<CACC+8CQOyeaijF-eUaCeOpiroCi6zS08UYh+LN+jYd9cR_XxUQ@mail.gmail.com>
	<CACC+8CTGuZBhM7HJPiQSXwmkAe487iOz00AsnPZ6MB58nb8b1g@mail.gmail.com>
	<4400B41FB768044EA720935D0808176C090BD76C@sausexdag02.amd.com>
Date: Fri, 20 Apr 2012 02:39:33 +0200
Message-ID: <CACC+8CS3+5UYa=cOZXwuMzDqRxH6SDc-M=v13GpYpKz=5LZV2g@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: Wei Huang <wei.huang2@amd.com>, xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=0015174781feb93a3404be11855f
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--0015174781feb93a3404be11855f
Content-Type: multipart/alternative; boundary=0015174781feb93a2d04be11855d

--0015174781feb93a2d04be11855d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I was busy too, but finally i get around to test the patch, i have compile
it with just "make"
in xen-unstable.hg/tools/qemu-xen-traditional-dir-remote/
and then copy it over, but it wont start with gfx_passthru=3D1,

.......
IRQ type =3D INTx
pt_iomem_map: e_phys=3De0000000 maddr=3Db0000000 type=3D8 len=3D268435456 i=
ndex=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1020000 maddr=3Dfa4e0000 type=3D0 len=3D131072 inde=
x=3D2
first_map=3D1
pt_iomem_map: e_phys=3Df1060000 maddr=3Dfa4bc000 type=3D0 len=3D16384 index=
=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1064000 maddr=3Dfadfe000 type=3D0 len=3D8192 index=
=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1066000 maddr=3Dfa3f6000 type=3D0 len=3D4096 index=
=3D0
first_map=3D1
pt_iomem_map: e_phys=3Df1067000 maddr=3Dfa3fc000 type=3D0 len=3D4096 index=
=3D0
first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3D7000 len=3D256 index=3D4 first_map=
=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3D7000 len=3D256 index=3D4 first_map=
=3D0
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
ati_gfx_init: ATI GFX Guest Info:
       pio_index=3D0x00000004,       guest_pio_bar=3D0x0000c100
       mmio_bar1_index=3D0x00000000, guest_mmio_bar1=3D0xe0000000
       mmio_bar2_index=3D0x00000002, guest_mmio_bar2=3D0xf1020000
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw
state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro
state.


Best Regards,
Kristijan Lecnik

On Fri, Apr 13, 2012 at 5:33 PM, Huang2, Wei <Wei.Huang2@amd.com> wrote:

>  Hi Kristijan,****
>
> ** **
>
> Sorry, was busy recently. Stub domain failure is OK. I think Ian (or
> someone else) reported it before. You can do the following steps:****
>
> ** **
>
> **1.      **Apply the patch****
>
> **2.      **Go to xen-unstable.hg/tools/qemu-xen-traditional-dir-remote/
> and compile it****
>
> **3.      **You will get an un-stripped qemu-dm under i386-dm/****
>
> **4.      **Copy it to your destination to replace existing
> /usr/lib/xen/bin/qemu-dm file****
>
> ** **
>
> ** **
>
> -Wei****
>
> ** **
>
> *From:* Kristijan Le=C4=8Dnik [mailto:janez3k@gmail.com]
> *Sent:* Friday, April 13, 2012 6:57 AM
> *To:* Huang2, Wei
> *Subject:* Fwd: [Xen-devel] AMD/ATI patch for xen 4.2-unstable****
>
> ** **
>
> Hi,
>
> i am sorry to bother you, but did you manage to see my errors, with the
> new patch?
>
> Best Regards,
> Kristijan Lecnik****
>
> ---------- Forwarded message ----------
> From: *Kristijan Le=C4=8Dnik* <janez3k@gmail.com>
> Date: Sun, Apr 8, 2012 at 3:37 PM
> Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable
> To: wei.huang2@amd.com
> Cc: xen-devel@lists.xen.org
>
>
> Hi,****
>
> ** **
>
> just try to compile with xen unstable 4.2 repo from 8.april 2012****
>
> ** **
>
> make --directory=3Darch/x86
> OBJ_DIR=3D/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || =
exit
> 1;****
>
> make[3]: Entering directory `/root/xen-unstable.hg/extras/mini-os/arch/x8=
6'
> ****
>
> make[3]: Nothing to be done for `all'.****
>
> make[3]: Leaving directory `/root/xen-unstable.hg/extras/mini-os/arch/x86=
'
> ****
>
> ld -r -nostdlib
> -L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
> elf_x86_64
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86/x86_64.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os_app.o
>  /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/blkfront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gntmap.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/gnttab.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/hypervisor.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lock.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/main.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mm.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/netfront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/sched.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/ctype.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/math.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/printf.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/stack_chk_fail.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/string.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xmalloc.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/xenbus/xenbus.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/console.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xencons_ring.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xenbus.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwip.a
> -L/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64  -=
lc
> -o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o****
>
> objcopy -w -G xenos_* -G _start
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o****
>
> ld -nostdlib
> -L/root/xen-unstable.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
> elf_x86_64 -T arch/x86/minios-x86_64.lds
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o  -o
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os****
>
> ld: warning: section `.bss' type changed to PROGBITS****
>
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
> `ati_hw_out':****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:82: undefined
> reference to `ioperm'****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:84: undefined
> reference to `ioperm'****
>
> /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o: In function
> `ati_hw_in':****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:72: undefined
> reference to `ioperm'****
>
> /root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c:74: undefined
> reference to `ioperm'****
>
> make[2]: *** [/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os]
> Error 1****
>
> make[2]: Leaving directory `/root/xen-unstable.hg/extras/mini-os'****
>
> make[1]: *** [ioemu-stubdom] Error 2****
>
> make[1]: Leaving directory `/root/xen-unstable.hg/stubdom'****
>
> make: *** [install-stubdom] Error 2****
>
> ** **
>
> using linux kernel 3.3****
>
> ** **
>
> nm /usr/lib/libc.a |grep -i ioperm****
>
> ioperm.o:****
>
> 0000000000000000 T ioperm****
>
> ** **
>
> Best Regards,****
>
> Kristijan Lecnik****
>
> ** **
>
> ** **
>
> On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang <wei.huang2@amd.com> wrote:***=
*
>
> I just re-spin the patch, but haven't tested it yet. You want to try it
> (attached)? Make sure you are using AMD GPU as the primary.
>
> -Wei****
>
>
>
>
> On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote: ****
>
> Hi, ****
>
> ** **
>
> i am trying to apply AMD/ATI patch on xen4-2 unstable****
>
>
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN=
3jloS.txt
> ****
>
> ** **
>
> and there was some changes in code and the patch is unusable, is there a
> new patch. or can somebody help me to update the patch?****
>
> ** **
>
> make[4]: Entering directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
> ****
>
>   CC    i386-dm/pt-graphics.o****
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_register_vga_regions=E2=80=99:****
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:373:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:374:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:
> In function =E2=80=98igd_unregister_vga_regions=E2=80=99:****
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:396:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> /root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir/hw/pt=
-graphics.c:397:
> error: too many arguments to function =E2=80=98pt_pci_host_read=E2=80=99*=
***
>
> make[4]: *** [pt-graphics.o] Error 1****
>
> make[4]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te/i386-dm'
> ****
>
> make[3]: *** [subdir-i386-dm] Error 2****
>
> make[3]: Leaving directory
> `/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-traditional-dir-remo=
te'
> ****
>
> make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2****
>
> make[2]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'**=
*
> *
>
> make[1]: *** [subdirs-install] Error 2****
>
> make[1]: Leaving directory `/root/xen-unstable.hg-IN_USE_PATCHED/tools'**=
*
> *
>
> make: *** [install-tools] Error 2****
>
> ** **
>
>
> http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-prototype-for-=
pt-pci-host-read-write-td5016713.html
> ****
>
> ** **
>
> example:****
>
> ** **
>
> old syle:****
>
> vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);****
>
> ** **
>
> new syle:****
>
> vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);****
>
> ** **
>
> Best Regards,****
>
> Kristijan Le=C4=8Dnik****
>
> ** **
>
> ** **
>
> ** **
>

--0015174781feb93a2d04be11855d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I was busy too, but finally i get around to test the=
 patch, i have compile it with just &quot;make&quot; in=C2=A0xen-unstable.h=
g/tools/qemu-xen-traditional-dir-remote/</div><div>and then copy it over, b=
ut it wont start with=C2=A0gfx_passthru=3D1,</div>
<div><br></div><div>.......</div><div>IRQ type =3D INTx</div><div>pt_iomem_=
map: e_phys=3De0000000 maddr=3Db0000000 type=3D8 len=3D268435456 index=3D0 =
first_map=3D1</div><div>pt_iomem_map: e_phys=3Df1020000 maddr=3Dfa4e0000 ty=
pe=3D0 len=3D131072 index=3D2 first_map=3D1</div>
<div>pt_iomem_map: e_phys=3Df1060000 maddr=3Dfa4bc000 type=3D0 len=3D16384 =
index=3D0 first_map=3D1</div><div>pt_iomem_map: e_phys=3Df1064000 maddr=3Df=
adfe000 type=3D0 len=3D8192 index=3D0 first_map=3D1</div><div>pt_iomem_map:=
 e_phys=3Df1066000 maddr=3Dfa3f6000 type=3D0 len=3D4096 index=3D0 first_map=
=3D1</div>
<div>pt_iomem_map: e_phys=3Df1067000 maddr=3Dfa3fc000 type=3D0 len=3D4096 i=
ndex=3D0 first_map=3D1</div><div>pt_ioport_map: e_phys=3Dc100 pio_base=3D70=
00 len=3D256 index=3D4 first_map=3D1</div><div>pt_ioport_map: e_phys=3Dc100=
 pio_base=3D7000 len=3D256 index=3D4 first_map=3D0</div>
<div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write not handled</div><div=
>ati_gfx_init: ATI GFX Guest Info:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0pio=
_index=3D0x00000004, =C2=A0 =C2=A0 =C2=A0 guest_pio_bar=3D0x0000c100</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0mmio_bar1_index=3D0x00000000, guest_mmio_bar=
1=3D0xe0000000</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0mmio_bar2_index=3D0x00000002, guest_mmio_ba=
r2=3D0xf1020000</div><div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write =
not handled</div><div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write not =
handled</div><div>ati_legacy_io_write: ERROR: port 0x3c3 I/O write not hand=
led</div>
<div>platform_fixed_ioport: changed ro/rw state of ROM memory area. now is =
rw state.</div><div>platform_fixed_ioport: changed ro/rw state of ROM memor=
y area. now is ro state.</div><div>=C2=A0</div><div><br></div><div>Best Reg=
ards,</div>
<div>Kristijan Lecnik</div><div><br><div class=3D"gmail_quote">On Fri, Apr =
13, 2012 at 5:33 PM, Huang2, Wei <span dir=3D"ltr">&lt;<a href=3D"mailto:We=
i.Huang2@amd.com">Wei.Huang2@amd.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">






<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hi Kristijan,<u></u><u></=
u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Sorry, was busy recently.=
 Stub domain failure is OK. I think Ian (or someone else) reported it befor=
e. You can do the following steps:<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>1.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Apply the patch<u></=
u><u></u></span></p>
<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>2.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Go to xen-unstable.h=
g/tools/qemu-xen-traditional-dir-remote/ and compile it<u></u><u></u></span=
></p>

<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>3.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">You will get an un-s=
tripped qemu-dm under i386-dm/<u></u><u></u></span></p>
<p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:#1f497d"><span>4.<span style=3D"font:7.0pt &quo=
t;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Copy it to your dest=
ination to replace existing /usr/lib/xen/bin/qemu-dm file<u></u><u></u></sp=
an></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">-Wei<u></u><u></u></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Kristija=
n Le=C4=8Dnik [mailto:<a href=3D"mailto:janez3k@gmail.com" target=3D"_blank=
">janez3k@gmail.com</a>]
<br>
<b>Sent:</b> Friday, April 13, 2012 6:57 AM<br>
<b>To:</b> Huang2, Wei<br>
<b>Subject:</b> Fwd: [Xen-devel] AMD/ATI patch for xen 4.2-unstable<u></u><=
u></u></span></p>
</div><div><div class=3D"h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<br>
<br>
i am sorry to bother you, but did you manage to see my errors, with the new=
 patch?<br>
<br>
Best Regards,<br>
Kristijan Lecnik<u></u><u></u></p>
<div>
<p class=3D"MsoNormal">---------- Forwarded message ----------<br>
From: <b>Kristijan Le=C4=8Dnik</b> &lt;<a href=3D"mailto:janez3k@gmail.com"=
 target=3D"_blank">janez3k@gmail.com</a>&gt;<br>
Date: Sun, Apr 8, 2012 at 3:37 PM<br>
Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable<br>
To: <a href=3D"mailto:wei.huang2@amd.com" target=3D"_blank">wei.huang2@amd.=
com</a><br>
Cc: <a href=3D"mailto:xen-devel@lists.xen.org" target=3D"_blank">xen-devel@=
lists.xen.org</a><br>
<br>
<br>
Hi,<u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">just try to compile with xen unstable 4.2 repo from =
8.april 2012<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">make --directory=3Darch/x86 OBJ_DIR=3D/root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/arch/x86 || exit 1;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Entering directory `/root/xen-unstable.hg/e=
xtras/mini-os/arch/x86&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Nothing to be done for `all&#39;.<u></u><u>=
</u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Leaving directory `/root/xen-unstable.hg/ex=
tras/mini-os/arch/x86&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">ld -r -nostdlib -L/root/xen-unstable.hg/stubdom/cros=
s-root-x86_64/x86_64-xen-elf/lib =C2=A0-m elf_x86_64 /root/xen-unstable.hg/=
stubdom/mini-os-x86_64-ioemu/arch/x86/x86_64.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/mini-os_app.o =C2=A0/root/xen-unstable.hg/stubdom/mi=
ni-os-x86_64-ioemu/blkfront.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/events.o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/fbfront.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/gntmap.o /root/xen-unstable.hg/stubdom/mini-os-x86_6=
4-ioemu/gnttab.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/hypervi=
sor.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/kernel.o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/lock.o /root/xen-unstable.hg/stubdom/m=
ini-os-x86_64-ioemu/main.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioe=
mu/mm.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/netfront.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/pcifront.o /root/xen-un=
stable.hg/stubdom/mini-os-x86_64-ioemu/sched.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/lib/ctype.o /root/xen-unstable.hg/stubdom/mini-os-x8=
6_64-ioemu/lib/math.o /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/li=
b/printf.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/stack_chk_fail.o /r=
oot/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/string.o /root/xen-uns=
table.hg/stubdom/mini-os-x86_64-ioemu/lib/sys.o /root/xen-unstable.hg/stubd=
om/mini-os-x86_64-ioemu/lib/xmalloc.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lib/xs.o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/xenbus/xenbus.o /root/xen-unstable.hg/=
stubdom/mini-os-x86_64-ioemu/console/console.o /root/xen-unstable.hg/stubdo=
m/mini-os-x86_64-ioemu/console/xencons_ring.o
 /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/console/xenbus.o /root/=
xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/lwip.a -L/root/xen-unstable.hg=
/stubdom/mini-os-x86_64-ioemu/arch/x86 -lx86_64 =C2=A0-lc -o /root/xen-unst=
able.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o<u></u><u></u></p>

</div>
<div>
<p class=3D"MsoNormal">objcopy -w -G xenos_* -G _start /root/xen-unstable.h=
g/stubdom/mini-os-x86_64-ioemu/mini-os.o /root/xen-unstable.hg/stubdom/mini=
-os-x86_64-ioemu/mini-os.o<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">ld -nostdlib -L/root/xen-unstable.hg/stubdom/cross-r=
oot-x86_64/x86_64-xen-elf/lib =C2=A0-m elf_x86_64 -T arch/x86/minios-x86_64=
.lds /root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os.o =C2=A0-o =
/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/mini-os<u></u><u></u></p=
>

</div>
<div>
<p class=3D"MsoNormal">ld: warning: section `.bss&#39; type changed to PROG=
BITS<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/m=
ini-os.o: In function `ati_hw_out&#39;:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:82: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:84: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/mini-os-x86_64-ioemu/m=
ini-os.o: In function `ati_hw_in&#39;:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:72: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg/stubdom/ioemu/hw/pt-graphics.c=
:74: undefined reference to `ioperm&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: *** [/root/xen-unstable.hg/stubdom/mini-os-=
x86_64-ioemu/mini-os] Error 1<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: Leaving directory `/root/xen-unstable.hg/ex=
tras/mini-os&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: *** [ioemu-stubdom] Error 2<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: Leaving directory `/root/xen-unstable.hg/st=
ubdom&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make: *** [install-stubdom] Error 2<u></u><u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">using linux kernel 3.3<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">nm /usr/lib/libc.a |grep -i ioperm<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">ioperm.o:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">0000000000000000 T ioperm<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Best Regards,<u></u><u></u></p>
</div>
</div>
<div>
<p class=3D"MsoNormal">Kristijan Lecnik<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<p class=3D"MsoNormal">On Tue, Apr 3, 2012 at 11:07 PM, Wei Huang &lt;<a hr=
ef=3D"mailto:wei.huang2@amd.com" target=3D"_blank">wei.huang2@amd.com</a>&g=
t; wrote:<u></u><u></u></p>
<div>
<p class=3D"MsoNormal">I just re-spin the patch, but haven&#39;t tested it =
yet. You want to try it (attached)? Make sure you are using AMD GPU as the =
primary.<span style=3D"color:#888888"><br>
<br>
-Wei</span><u></u><u></u></p>
<div>
<div>
<p class=3D"MsoNormal"><br>
<br>
<br>
On 04/01/2012 08:03 PM, Kristijan Le=C4=8Dnik wrote: <u></u><u></u></p>
<p class=3D"MsoNormal">Hi, <u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">i am trying to apply AMD/ATI patch on xen4-2 unstabl=
e<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://old-list-archives.xen.org/archives=
/html/xen-devel/2010-12/txtNwRlN3jloS.txt" target=3D"_blank">http://old-lis=
t-archives.xen.org/archives/html/xen-devel/2010-12/txtNwRlN3jloS.txt</a><u>=
</u><u></u></p>

</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">and there was some changes in code and the patch is =
unusable, is there a new patch. or can somebody help me to update the patch=
?<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">make[4]: Entering directory `/root/xen-unstable.hg-I=
N_USE_PATCHED/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;<u></u><u><=
/u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0 CC =C2=A0 =C2=A0i386-dm/pt-graphics.o<u></u><=
u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c: In function =E2=80=98igd_register_vga_reg=
ions=E2=80=99:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:373: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:374: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c: In function =E2=80=98igd_unregister_vga_r=
egions=E2=80=99:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:396: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">/root/xen-unstable.hg-IN_USE_PATCHED/tools/qemu-xen-=
traditional-dir/hw/pt-graphics.c:397: error: too many arguments to function=
 =E2=80=98pt_pci_host_read=E2=80=99<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[4]: *** [pt-graphics.o] Error 1<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal">make[4]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;<u></u><u></=
u></p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: *** [subdir-i386-dm] Error 2<u></u><u></u><=
/p>
</div>
<div>
<p class=3D"MsoNormal">make[3]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools/qemu-xen-traditional-dir-remote&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: *** [subdir-install-qemu-xen-traditional-di=
r] Error 2<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[2]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: *** [subdirs-install] Error 2<u></u><u></u>=
</p>
</div>
<div>
<p class=3D"MsoNormal">make[1]: Leaving directory `/root/xen-unstable.hg-IN=
_USE_PATCHED/tools&#39;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">make: *** [install-tools] Error 2<u></u><u></u></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://xen.1045712.n5.nabble.com/PATCH-1-=
3-qemu-xen-Change-prototype-for-pt-pci-host-read-write-td5016713.html" targ=
et=3D"_blank">http://xen.1045712.n5.nabble.com/PATCH-1-3-qemu-xen-Change-pr=
ototype-for-pt-pci-host-read-write-td5016713.html</a><u></u><u></u></p>

</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">example:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">old syle:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">vendor_id =3D pt_pci_host_read(0, 2, 0, 0, 2);<u></u=
><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">new syle:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, =
2);<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Best Regards,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Kristijan Le=C4=8Dnik<u></u><u></u></p>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
</div>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
</div>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div></div></div>
</div>

</blockquote></div><br></div>

--0015174781feb93a2d04be11855d--
--0015174781feb93a3404be11855f
Content-Type: application/octet-stream; name="qemu-dm-win7.log.1"
Content-Disposition: attachment; filename="qemu-dm-win7.log.1"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h18ihjlg0

ZG9taWQ6IDMKU3RyaXAgb2ZmIGJsa3RhcCBzdWItdHlwZSBwcmVmaXggdG8gL3hlbi93aW43LnFj
b3cyIChkcnYgJ3Fjb3cyJykKVXNpbmcgZmlsZSAveGVuL3dpbjcucWNvdzIgaW4gcmVhZC13cml0
ZSBtb2RlCldhdGNoaW5nIC9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvMy9sb2dkaXJ0eS9j
bWQKV2F0Y2hpbmcgL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8zL2NvbW1hbmQKV2F0Y2hp
bmcgL2xvY2FsL2RvbWFpbi8zL2NwdQpjaGFyIGRldmljZSByZWRpcmVjdGVkIHRvIC9kZXYvcHRz
LzIKcWVtdV9tYXBfY2FjaGVfaW5pdCBucl9idWNrZXRzID0gMTAwMDAgc2l6ZSA0MTk0MzA0CnNo
YXJlZCBwYWdlIGF0IHBmbiBmZWZmZApidWZmZXJlZCBpbyBwYWdlIGF0IHBmbiBmZWZmYgpHdWVz
dCB1dWlkID0gZGIyZTE0ODQtMjExNS00YTJjLWJiODktYzhmOTliZmU1MDBkClJlZ2lzdGVyIHhl
biBwbGF0Zm9ybS4KRG9uZSByZWdpc3RlciBwbGF0Zm9ybS4KcGxhdGZvcm1fZml4ZWRfaW9wb3J0
OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBtZW1vcnkgYXJlYS4gbm93IGlzIHJ3IHN0YXRl
Lgp4c19yZWFkKC9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvMy94ZW5fZXh0ZW5kZWRfcG93
ZXJfbWdtdCk6IHJlYWQgZXJyb3IKTG9nLWRpcnR5OiBubyBjb21tYW5kIHlldC4KSS9PIHJlcXVl
c3Qgbm90IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXpl
OiAwCkkvTyByZXF1ZXN0IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBj
b3VudDogMCwgc2l6ZTogMAp2Y3B1LXNldDogd2F0Y2ggbm9kZSBlcnJvci4KSS9PIHJlcXVlc3Qg
bm90IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAw
CnhzX3JlYWQoL2xvY2FsL2RvbWFpbi8zL2xvZy10aHJvdHRsaW5nKTogcmVhZCBlcnJvcgpxZW11
OiBpZ25vcmluZyBub3QtdW5kZXJzdG9vZCBkcml2ZSBgL2xvY2FsL2RvbWFpbi8zL2xvZy10aHJv
dHRsaW5nJwptZWRpdW0gY2hhbmdlIHdhdGNoIG9uIGAvbG9jYWwvZG9tYWluLzMvbG9nLXRocm90
dGxpbmcnIC0gdW5rbm93biBkZXZpY2UsIGlnbm9yZWQKSS9PIHJlcXVlc3Qgbm90IHJlYWR5OiAw
LCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwCmRtLWNvbW1hbmQ6
IGhvdCBpbnNlcnQgcGFzcy10aHJvdWdoIHBjaSBkZXYgCnJlZ2lzdGVyX3JlYWxfZGV2aWNlOiBB
c3NpZ25pbmcgcmVhbCBwaHlzaWNhbCBkZXZpY2UgMDE6MDAuMCAuLi4KcHRfaW9tdWxfaW5pdDog
RXJyb3I6IHB0X2lvbXVsX2luaXQgY2FuJ3Qgb3BlbiBmaWxlIC9kZXYveGVuL3BjaV9pb211bDog
Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeTogMHgxOjB4MC4weDAKcHRfcmVnaXN0ZXJfcmVnaW9u
czogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgxMDAwMDAwMCBiYXNlX2FkZHI9MHhiMDAw
MDAwYykKcHRfcmVnaXN0ZXJfcmVnaW9uczogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgw
MDAyMDAwMCBiYXNlX2FkZHI9MHhmYTRlMDAwNCkKcHRfcmVnaXN0ZXJfcmVnaW9uczogSU8gcmVn
aW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMDEwMCBiYXNlX2FkZHI9MHgwMDAwNzAwMSkKcHRf
cmVnaXN0ZXJfcmVnaW9uczogRXhwYW5zaW9uIFJPTSByZWdpc3RlcmVkIChzaXplPTB4MDAwMjAw
MDAgYmFzZV9hZGRyPTB4ZmE0YzAwMDApCnB0X21zaV9zZXR1cDogbXNpIG1hcHBlZCB3aXRoIHBp
cnEgMzcKcGNpX2ludHg6IGludHg9MQpyZWdpc3Rlcl9yZWFsX2RldmljZTogUmVhbCBwaHlzaWNh
bCBkZXZpY2UgMDE6MDAuMCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWx5IQpJUlEgdHlwZSA9IE1TSS1J
TlR4CmRtLWNvbW1hbmQ6IGhvdCBpbnNlcnQgcGFzcy10aHJvdWdoIHBjaSBkZXYgCnJlZ2lzdGVy
X3JlYWxfZGV2aWNlOiBBc3NpZ25pbmcgcmVhbCBwaHlzaWNhbCBkZXZpY2UgMDE6MDAuMSAuLi4K
cHRfaW9tdWxfaW5pdDogRXJyb3I6IHB0X2lvbXVsX2luaXQgY2FuJ3Qgb3BlbiBmaWxlIC9kZXYv
eGVuL3BjaV9pb211bDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeTogMHgxOjB4MC4weDEKcHRf
cmVnaXN0ZXJfcmVnaW9uczogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwNDAwMCBi
YXNlX2FkZHI9MHhmYTRiYzAwNCkKcHRfbXNpX3NldHVwOiBtc2kgbWFwcGVkIHdpdGggcGlycSAz
NgpwY2lfaW50eDogaW50eD0yCnJlZ2lzdGVyX3JlYWxfZGV2aWNlOiBSZWFsIHBoeXNpY2FsIGRl
dmljZSAwMTowMC4xIHJlZ2lzdGVyZWQgc3VjY2Vzc2Z1bHkhCklSUSB0eXBlID0gTVNJLUlOVHgK
ZG0tY29tbWFuZDogaG90IGluc2VydCBwYXNzLXRocm91Z2ggcGNpIGRldiAKcmVnaXN0ZXJfcmVh
bF9kZXZpY2U6IEFzc2lnbmluZyByZWFsIHBoeXNpY2FsIGRldmljZSAwYTowMC4wIC4uLgpwdF9p
b211bF9pbml0OiBFcnJvcjogcHRfaW9tdWxfaW5pdCBjYW4ndCBvcGVuIGZpbGUgL2Rldi94ZW4v
cGNpX2lvbXVsOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5OiAweGE6MHgwLjB4MApwdF9yZWdp
c3Rlcl9yZWdpb25zOiBJTyByZWdpb24gcmVnaXN0ZXJlZCAoc2l6ZT0weDAwMDAyMDAwIGJhc2Vf
YWRkcj0weGZhZGZlMDA0KQpwdF9tc2l4X2luaXQ6IGdldCBNU0ktWCB0YWJsZSBiYXIgYmFzZSBm
YWRmZTAwMApwdF9tc2l4X2luaXQ6IHRhYmxlX29mZiA9IDEwMDAsIHRvdGFsX2VudHJpZXMgPSA4
CnB0X21zaXhfaW5pdDogbWFwcGluZyBwaHlzaWNhbCBNU0ktWCB0YWJsZSB0byA3ZmYxOWM2ZGUw
MDAKcHRfbXNpX3NldHVwOiBtc2kgbWFwcGVkIHdpdGggcGlycSAzNQpwY2lfaW50eDogaW50eD0x
CnJlZ2lzdGVyX3JlYWxfZGV2aWNlOiBSZWFsIHBoeXNpY2FsIGRldmljZSAwYTowMC4wIHJlZ2lz
dGVyZWQgc3VjY2Vzc2Z1bHkhCklSUSB0eXBlID0gTVNJLUlOVHgKZG0tY29tbWFuZDogaG90IGlu
c2VydCBwYXNzLXRocm91Z2ggcGNpIGRldiAKcmVnaXN0ZXJfcmVhbF9kZXZpY2U6IEFzc2lnbmlu
ZyByZWFsIHBoeXNpY2FsIGRldmljZSAwMDoxZC4wIC4uLgpwdF9pb211bF9pbml0OiBFcnJvcjog
cHRfaW9tdWxfaW5pdCBjYW4ndCBvcGVuIGZpbGUgL2Rldi94ZW4vcGNpX2lvbXVsOiBObyBzdWNo
IGZpbGUgb3IgZGlyZWN0b3J5OiAweDA6MHgxZC4weDAKcHRfcmVnaXN0ZXJfcmVnaW9uczogSU8g
cmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMDQwMCBiYXNlX2FkZHI9MHhmYTNmNjAwMCkK
cGNpX2ludHg6IGludHg9MQpyZWdpc3Rlcl9yZWFsX2RldmljZTogUmVhbCBwaHlzaWNhbCBkZXZp
Y2UgMDA6MWQuMCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWx5IQpJUlEgdHlwZSA9IElOVHgKZG0tY29t
bWFuZDogaG90IGluc2VydCBwYXNzLXRocm91Z2ggcGNpIGRldiAKcmVnaXN0ZXJfcmVhbF9kZXZp
Y2U6IEFzc2lnbmluZyByZWFsIHBoeXNpY2FsIGRldmljZSAwMDoxYS4wIC4uLgpwdF9pb211bF9p
bml0OiBFcnJvcjogcHRfaW9tdWxfaW5pdCBjYW4ndCBvcGVuIGZpbGUgL2Rldi94ZW4vcGNpX2lv
bXVsOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5OiAweDA6MHgxYS4weDAKcHRfcmVnaXN0ZXJf
cmVnaW9uczogSU8gcmVnaW9uIHJlZ2lzdGVyZWQgKHNpemU9MHgwMDAwMDQwMCBiYXNlX2FkZHI9
MHhmYTNmYzAwMCkKcGNpX2ludHg6IGludHg9MQpyZWdpc3Rlcl9yZWFsX2RldmljZTogUmVhbCBw
aHlzaWNhbCBkZXZpY2UgMDA6MWEuMCByZWdpc3RlcmVkIHN1Y2Nlc3NmdWx5IQpJUlEgdHlwZSA9
IElOVHgKcHRfaW9tZW1fbWFwOiBlX3BoeXM9ZTAwMDAwMDAgbWFkZHI9YjAwMDAwMDAgdHlwZT04
IGxlbj0yNjg0MzU0NTYgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb21lbV9tYXA6IGVfcGh5cz1m
MTAyMDAwMCBtYWRkcj1mYTRlMDAwMCB0eXBlPTAgbGVuPTEzMTA3MiBpbmRleD0yIGZpcnN0X21h
cD0xCnB0X2lvbWVtX21hcDogZV9waHlzPWYxMDYwMDAwIG1hZGRyPWZhNGJjMDAwIHR5cGU9MCBs
ZW49MTYzODQgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb21lbV9tYXA6IGVfcGh5cz1mMTA2NDAw
MCBtYWRkcj1mYWRmZTAwMCB0eXBlPTAgbGVuPTgxOTIgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9p
b21lbV9tYXA6IGVfcGh5cz1mMTA2NjAwMCBtYWRkcj1mYTNmNjAwMCB0eXBlPTAgbGVuPTQwOTYg
aW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb21lbV9tYXA6IGVfcGh5cz1mMTA2NzAwMCBtYWRkcj1m
YTNmYzAwMCB0eXBlPTAgbGVuPTQwOTYgaW5kZXg9MCBmaXJzdF9tYXA9MQpwdF9pb3BvcnRfbWFw
OiBlX3BoeXM9YzEwMCBwaW9fYmFzZT03MDAwIGxlbj0yNTYgaW5kZXg9NCBmaXJzdF9tYXA9MQpw
dF9pb3BvcnRfbWFwOiBlX3BoeXM9YzEwMCBwaW9fYmFzZT03MDAwIGxlbj0yNTYgaW5kZXg9NCBm
aXJzdF9tYXA9MAphdGlfbGVnYWN5X2lvX3dyaXRlOiBFUlJPUjogcG9ydCAweDNjMyBJL08gd3Jp
dGUgbm90IGhhbmRsZWQKYXRpX2dmeF9pbml0OiBBVEkgR0ZYIEd1ZXN0IEluZm86CiAgICAgICBw
aW9faW5kZXg9MHgwMDAwMDAwNCwgICAgICAgZ3Vlc3RfcGlvX2Jhcj0weDAwMDBjMTAwCiAgICAg
ICBtbWlvX2JhcjFfaW5kZXg9MHgwMDAwMDAwMCwgZ3Vlc3RfbW1pb19iYXIxPTB4ZTAwMDAwMDAK
ICAgICAgIG1taW9fYmFyMl9pbmRleD0weDAwMDAwMDAyLCBndWVzdF9tbWlvX2JhcjI9MHhmMTAy
MDAwMAphdGlfbGVnYWN5X2lvX3dyaXRlOiBFUlJPUjogcG9ydCAweDNjMyBJL08gd3JpdGUgbm90
IGhhbmRsZWQKYXRpX2xlZ2FjeV9pb193cml0ZTogRVJST1I6IHBvcnQgMHgzYzMgSS9PIHdyaXRl
IG5vdCBoYW5kbGVkCmF0aV9sZWdhY3lfaW9fd3JpdGU6IEVSUk9SOiBwb3J0IDB4M2MzIEkvTyB3
cml0ZSBub3QgaGFuZGxlZApwbGF0Zm9ybV9maXhlZF9pb3BvcnQ6IGNoYW5nZWQgcm8vcncgc3Rh
dGUgb2YgUk9NIG1lbW9yeSBhcmVhLiBub3cgaXMgcncgc3RhdGUuCnBsYXRmb3JtX2ZpeGVkX2lv
cG9ydDogY2hhbmdlZCByby9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5vdyBpcyBybyBz
dGF0ZS4K
--0015174781feb93a3404be11855f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--0015174781feb93a3404be11855f--


From xen-devel-bounces@lists.xen.org Fri Apr 20 02:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 02:22:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL3Tn-0006sP-0v; Fri, 20 Apr 2012 02:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SL3Tl-0006sH-Qm
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 02:21:46 +0000
Received: from [85.158.138.51:50576] by server-2.bemta-3.messagelabs.com id
	03/1E-09269-838C09F4; Fri, 20 Apr 2012 02:21:44 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334888503!23000350!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6687 invoked from network); 20 Apr 2012 02:21:44 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 02:21:44 -0000
Received: from mail157-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 02:21:43 +0000
Received: from mail157-va3 (localhost [127.0.0.1])	by
	mail157-va3-R.bigfish.com (Postfix) with ESMTP id C970B3003A5;
	Fri, 20 Apr 2012 02:21:42 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail157-va3 (localhost.localdomain [127.0.0.1]) by mail157-va3
	(MessageSwitch) id 1334888500689927_4614;
	Fri, 20 Apr 2012 02:21:40 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.249])	by
	mail157-va3.bigfish.com (Postfix) with ESMTP id 92C61E00DC;
	Fri, 20 Apr 2012 02:21:40 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 02:21:36 +0000
X-WSS-ID: 0M2RAJY-02-1ZM-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2FD2EC8190;	Thu, 19 Apr 2012 21:21:34 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 19 Apr 2012 21:21:52 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 19 Apr 2012 21:21:34 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 19 Apr 2012
	22:21:33 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0E17849C58B; Fri, 20 Apr 2012
	03:21:33 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id EB1232D202B; Fri,
	20 Apr 2012 04:21:32 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
Message-ID: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Fri, 20 Apr 2012 04:21:17 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling
 is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1334875170 14400
# Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
# Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Wei Huang <wei.huang2@amd.com>
Tested-by: Wei Huang <wei.huang2@amd.com>

diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
@@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
 {
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
+    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
 
     general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
-    if ( enable )
+    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
+
+    if ( enable && !cpu_has_tsc_ratio ) {
         general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
+        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+    }
 
     vmcb_set_general1_intercepts(vmcb, general1_intercepts);
+    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
 }
 
 static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 02:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 02:22:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL3Tn-0006sP-0v; Fri, 20 Apr 2012 02:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SL3Tl-0006sH-Qm
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 02:21:46 +0000
Received: from [85.158.138.51:50576] by server-2.bemta-3.messagelabs.com id
	03/1E-09269-838C09F4; Fri, 20 Apr 2012 02:21:44 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1334888503!23000350!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6687 invoked from network); 20 Apr 2012 02:21:44 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 02:21:44 -0000
Received: from mail157-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 02:21:43 +0000
Received: from mail157-va3 (localhost [127.0.0.1])	by
	mail157-va3-R.bigfish.com (Postfix) with ESMTP id C970B3003A5;
	Fri, 20 Apr 2012 02:21:42 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail157-va3 (localhost.localdomain [127.0.0.1]) by mail157-va3
	(MessageSwitch) id 1334888500689927_4614;
	Fri, 20 Apr 2012 02:21:40 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.249])	by
	mail157-va3.bigfish.com (Postfix) with ESMTP id 92C61E00DC;
	Fri, 20 Apr 2012 02:21:40 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 02:21:36 +0000
X-WSS-ID: 0M2RAJY-02-1ZM-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2FD2EC8190;	Thu, 19 Apr 2012 21:21:34 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 19 Apr 2012 21:21:52 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 19 Apr 2012 21:21:34 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 19 Apr 2012
	22:21:33 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0E17849C58B; Fri, 20 Apr 2012
	03:21:33 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id EB1232D202B; Fri,
	20 Apr 2012 04:21:32 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
Message-ID: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Fri, 20 Apr 2012 04:21:17 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling
 is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1334875170 14400
# Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
# Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Wei Huang <wei.huang2@amd.com>
Tested-by: Wei Huang <wei.huang2@amd.com>

diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
@@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
 {
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
+    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
 
     general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
-    if ( enable )
+    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
+
+    if ( enable && !cpu_has_tsc_ratio ) {
         general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
+        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+    }
 
     vmcb_set_general1_intercepts(vmcb, general1_intercepts);
+    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
 }
 
 static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 03:07:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 03:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL4Br-0007L1-2Q; Fri, 20 Apr 2012 03:07:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SL4Bp-0007Kw-81
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 03:07:17 +0000
Received: from [85.158.138.51:25435] by server-5.bemta-3.messagelabs.com id
	74/60-17113-4E2D09F4; Fri, 20 Apr 2012 03:07:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334891235!22933615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTI0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3556 invoked from network); 20 Apr 2012 03:07:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 03:07:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,450,1330905600"; d="scan'208";a="12038370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 03:07:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 04:07:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SL4Bm-0005Z8-Kq;
	Fri, 20 Apr 2012 03:07:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SL4Bm-0001O6-IG;
	Fri, 20 Apr 2012 04:07:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12728-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 04:07:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12728: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12728 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12728/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12727

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12727
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  d1b0a8a84ccf
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 03:07:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 03:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL4Br-0007L1-2Q; Fri, 20 Apr 2012 03:07:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SL4Bp-0007Kw-81
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 03:07:17 +0000
Received: from [85.158.138.51:25435] by server-5.bemta-3.messagelabs.com id
	74/60-17113-4E2D09F4; Fri, 20 Apr 2012 03:07:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334891235!22933615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTI0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3556 invoked from network); 20 Apr 2012 03:07:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 03:07:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,450,1330905600"; d="scan'208";a="12038370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 03:07:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 04:07:14 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SL4Bm-0005Z8-Kq;
	Fri, 20 Apr 2012 03:07:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SL4Bm-0001O6-IG;
	Fri, 20 Apr 2012 04:07:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12728-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 04:07:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12728: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12728 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12728/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12727

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12727
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  d1b0a8a84ccf
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 03:58:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 03:58:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL4yY-0008GK-Qh; Fri, 20 Apr 2012 03:57:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SL4yX-0008GF-9R
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 03:57:37 +0000
Received: from [85.158.138.51:10001] by server-8.bemta-3.messagelabs.com id
	91/6B-24428-0BED09F4; Fri, 20 Apr 2012 03:57:36 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334894254!18607945!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15239 invoked from network); 20 Apr 2012 03:57:35 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 03:57:35 -0000
Received: from mail122-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 20 Apr 2012 03:57:33 +0000
Received: from mail122-va3 (localhost [127.0.0.1])	by
	mail122-va3-R.bigfish.com (Postfix) with ESMTP id 562B71404A1;
	Fri, 20 Apr 2012 03:57:33 +0000 (UTC)
X-SpamScore: -3
X-BigFish: VPS-3(zz9371I542Mzz1202hzz8275bh8275dhz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail122-va3 (localhost.localdomain [127.0.0.1]) by mail122-va3
	(MessageSwitch) id 1334894251366348_20942;
	Fri, 20 Apr 2012 03:57:31 +0000 (UTC)
Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.243])	by
	mail122-va3.bigfish.com (Postfix) with ESMTP id 4BDEB12026E;
	Fri, 20 Apr 2012 03:57:31 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 03:57:31 +0000
X-WSS-ID: 0M2REZS-01-7H0-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21635D10005;	Thu, 19 Apr 2012 22:57:28 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 19 Apr 2012 22:57:46 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag03.amd.com ([fe80::85b5:3838:d8b4:20ba%24]) with mapi id
	14.01.0323.003; Thu, 19 Apr 2012 22:57:29 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>, "JBeulich@suse.com"
	<JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: AQHNHpxPkEb3eUjtQUKe3vtM5npR3pajFheA
Date: Fri, 20 Apr 2012 03:57:28 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090DF431@sausexdag02.amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.224.13.73]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please also backport this patch to xen-4.1. Thanks.

-Wei

-----Original Message-----
From: Boris Ostrovsky [mailto:boris.ostrovsky@amd.com] 
Sent: Thursday, April 19, 2012 9:21 PM
To: JBeulich@suse.com; keir@xen.org
Cc: Ostrovsky, Boris; Huang2, Wei; xen-devel@lists.xensource.com
Subject: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1334875170 14400
# Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
# Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Wei Huang <wei.huang2@amd.com>
Tested-by: Wei Huang <wei.huang2@amd.com>

diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
@@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
 {
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
+    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
 
     general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
-    if ( enable )
+    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
+
+    if ( enable && !cpu_has_tsc_ratio ) {
         general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
+        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+    }
 
     vmcb_set_general1_intercepts(vmcb, general1_intercepts);
+    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
 }
 
 static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 03:58:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 03:58:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL4yY-0008GK-Qh; Fri, 20 Apr 2012 03:57:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SL4yX-0008GF-9R
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 03:57:37 +0000
Received: from [85.158.138.51:10001] by server-8.bemta-3.messagelabs.com id
	91/6B-24428-0BED09F4; Fri, 20 Apr 2012 03:57:36 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334894254!18607945!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15239 invoked from network); 20 Apr 2012 03:57:35 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 03:57:35 -0000
Received: from mail122-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 20 Apr 2012 03:57:33 +0000
Received: from mail122-va3 (localhost [127.0.0.1])	by
	mail122-va3-R.bigfish.com (Postfix) with ESMTP id 562B71404A1;
	Fri, 20 Apr 2012 03:57:33 +0000 (UTC)
X-SpamScore: -3
X-BigFish: VPS-3(zz9371I542Mzz1202hzz8275bh8275dhz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail122-va3 (localhost.localdomain [127.0.0.1]) by mail122-va3
	(MessageSwitch) id 1334894251366348_20942;
	Fri, 20 Apr 2012 03:57:31 +0000 (UTC)
Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.243])	by
	mail122-va3.bigfish.com (Postfix) with ESMTP id 4BDEB12026E;
	Fri, 20 Apr 2012 03:57:31 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 03:57:31 +0000
X-WSS-ID: 0M2REZS-01-7H0-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21635D10005;	Thu, 19 Apr 2012 22:57:28 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 19 Apr 2012 22:57:46 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag03.amd.com ([fe80::85b5:3838:d8b4:20ba%24]) with mapi id
	14.01.0323.003; Thu, 19 Apr 2012 22:57:29 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>, "JBeulich@suse.com"
	<JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: AQHNHpxPkEb3eUjtQUKe3vtM5npR3pajFheA
Date: Fri, 20 Apr 2012 03:57:28 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090DF431@sausexdag02.amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.224.13.73]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please also backport this patch to xen-4.1. Thanks.

-Wei

-----Original Message-----
From: Boris Ostrovsky [mailto:boris.ostrovsky@amd.com] 
Sent: Thursday, April 19, 2012 9:21 PM
To: JBeulich@suse.com; keir@xen.org
Cc: Ostrovsky, Boris; Huang2, Wei; xen-devel@lists.xensource.com
Subject: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1334875170 14400
# Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
# Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Wei Huang <wei.huang2@amd.com>
Tested-by: Wei Huang <wei.huang2@amd.com>

diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
@@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
 {
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
+    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
 
     general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
-    if ( enable )
+    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
+
+    if ( enable && !cpu_has_tsc_ratio ) {
         general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
+        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
+    }
 
     vmcb_set_general1_intercepts(vmcb, general1_intercepts);
+    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
 }
 
 static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 05:05:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 05:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL61S-0000j7-3p; Fri, 20 Apr 2012 05:04:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SL61Q-0000j2-VI
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 05:04:41 +0000
Received: from [85.158.143.35:47804] by server-1.bemta-4.messagelabs.com id
	FA/AB-20925-86EE09F4; Fri, 20 Apr 2012 05:04:40 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334898277!7930427!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11549 invoked from network); 20 Apr 2012 05:04:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 05:04:38 -0000
Received: by obbtb18 with SMTP id tb18so9318052obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 22:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=IEVFHscO+CrgyorhZuPLscfEkD12KqGc69beu6tSajE=;
	b=xOmZ+I3Mi1xJ0g56aHZQlqYKQPUWfl1oey03RY+GOy2YenHOnK8vxfcDqnvRWCn9md
	+C1rvArUQYzIof9fwUQT+oIbCfxjimmz8kxrBayqxPiCocU1SDm5/MoTTg0D1wxHGAhK
	9wJ0vlp++Z33eZXDWaunXNsTLqVs9bBkyj44s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to
	:x-gm-message-state;
	bh=IEVFHscO+CrgyorhZuPLscfEkD12KqGc69beu6tSajE=;
	b=SWijV0K9gzgiRB+pSnmqERLUeFc2VLl1WzgMjQoni2OhSh0Tr8xHIuLISa/j1i6AQy
	AOVR96p1FX7Z6NNV/Dzh/HbTBBfbM9oKJn/93j/rU0gdrEmy2ZUbiBwunDFBCSW8fORF
	f/8ROU/Cj/7wFGFRz8VGXR36DAUqCGpapQl27nLg5aefYUlUq9u6EmfUnSxS+g5Zky+m
	+CnPUMwvdpGcI8JCQXRhaXXiLU96Ft7p+Xd1Bj3n+edoU2Casb9V0+xMJMGHwhomRErc
	jrdb3WwvSRnGr2u6DQYATXC45DKEXqxo/JSMd4cWZ1O5eHqlxFUDpeaFUmRJlgIoe9/h
	ZzYA==
Received: by 10.60.14.136 with SMTP id p8mr6477365oec.68.1334898276858;
	Thu, 19 Apr 2012 22:04:36 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id h2sm5340319obn.20.2012.04.19.22.04.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 22:04:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f60377584f2d62e82d62a4ecb57f78e5f30b8640
Message-Id: <f60377584f2d62e82d62.1334898269@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 19 Apr 2012 22:04:29 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnwoPPgEpGybyvnoIGnkGIrlTqty+PmLLumrGHI3J8KRu/AWzmGAeFLFkQHHfL7l29DRwB6
Subject: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts
 to be injected in to the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If xc_hvm_inject_trap() is called on a software (user defined) interrupt, it causes the guest to crash with a vmentry failure. The following patch fixes this issue.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 9036d6f974de -r f60377584f2d xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 21:55:51 2012 -0700
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 22:01:50 2012 -0700
@@ -1374,6 +1374,13 @@ void vmx_inject_hw_exception(int trap, i
 
         type = X86_EVENTTYPE_SW_EXCEPTION;
         __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */
+        break;
+    default:
+        if ( trap > TRAP_last_reserved )
+        {
+            type = X86_EVENTTYPE_SW_EXCEPTION;
+            __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */
+        }
     }
 
     if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
diff -r 9036d6f974de -r f60377584f2d xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h	Thu Apr 19 21:55:51 2012 -0700
+++ b/xen/include/asm-x86/processor.h	Thu Apr 19 22:01:50 2012 -0700
@@ -111,6 +111,7 @@
 #define TRAP_alignment_check  17
 #define TRAP_machine_check    18
 #define TRAP_simd_error       19
+#define TRAP_last_reserved    31
 
 /* Set for entry via SYSCALL. Informs return code to use SYSRETQ not IRETQ. */
 /* NB. Same as VGCF_in_syscall. No bits in common with any other TRAP_ defn. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 05:05:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 05:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL61S-0000j7-3p; Fri, 20 Apr 2012 05:04:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SL61Q-0000j2-VI
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 05:04:41 +0000
Received: from [85.158.143.35:47804] by server-1.bemta-4.messagelabs.com id
	FA/AB-20925-86EE09F4; Fri, 20 Apr 2012 05:04:40 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334898277!7930427!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11549 invoked from network); 20 Apr 2012 05:04:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 05:04:38 -0000
Received: by obbtb18 with SMTP id tb18so9318052obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Apr 2012 22:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=IEVFHscO+CrgyorhZuPLscfEkD12KqGc69beu6tSajE=;
	b=xOmZ+I3Mi1xJ0g56aHZQlqYKQPUWfl1oey03RY+GOy2YenHOnK8vxfcDqnvRWCn9md
	+C1rvArUQYzIof9fwUQT+oIbCfxjimmz8kxrBayqxPiCocU1SDm5/MoTTg0D1wxHGAhK
	9wJ0vlp++Z33eZXDWaunXNsTLqVs9bBkyj44s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to
	:x-gm-message-state;
	bh=IEVFHscO+CrgyorhZuPLscfEkD12KqGc69beu6tSajE=;
	b=SWijV0K9gzgiRB+pSnmqERLUeFc2VLl1WzgMjQoni2OhSh0Tr8xHIuLISa/j1i6AQy
	AOVR96p1FX7Z6NNV/Dzh/HbTBBfbM9oKJn/93j/rU0gdrEmy2ZUbiBwunDFBCSW8fORF
	f/8ROU/Cj/7wFGFRz8VGXR36DAUqCGpapQl27nLg5aefYUlUq9u6EmfUnSxS+g5Zky+m
	+CnPUMwvdpGcI8JCQXRhaXXiLU96Ft7p+Xd1Bj3n+edoU2Casb9V0+xMJMGHwhomRErc
	jrdb3WwvSRnGr2u6DQYATXC45DKEXqxo/JSMd4cWZ1O5eHqlxFUDpeaFUmRJlgIoe9/h
	ZzYA==
Received: by 10.60.14.136 with SMTP id p8mr6477365oec.68.1334898276858;
	Thu, 19 Apr 2012 22:04:36 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id h2sm5340319obn.20.2012.04.19.22.04.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Apr 2012 22:04:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f60377584f2d62e82d62a4ecb57f78e5f30b8640
Message-Id: <f60377584f2d62e82d62.1334898269@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 19 Apr 2012 22:04:29 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnwoPPgEpGybyvnoIGnkGIrlTqty+PmLLumrGHI3J8KRu/AWzmGAeFLFkQHHfL7l29DRwB6
Subject: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts
 to be injected in to the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If xc_hvm_inject_trap() is called on a software (user defined) interrupt, it causes the guest to crash with a vmentry failure. The following patch fixes this issue.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 9036d6f974de -r f60377584f2d xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 21:55:51 2012 -0700
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 22:01:50 2012 -0700
@@ -1374,6 +1374,13 @@ void vmx_inject_hw_exception(int trap, i
 
         type = X86_EVENTTYPE_SW_EXCEPTION;
         __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */
+        break;
+    default:
+        if ( trap > TRAP_last_reserved )
+        {
+            type = X86_EVENTTYPE_SW_EXCEPTION;
+            __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */
+        }
     }
 
     if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
diff -r 9036d6f974de -r f60377584f2d xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h	Thu Apr 19 21:55:51 2012 -0700
+++ b/xen/include/asm-x86/processor.h	Thu Apr 19 22:01:50 2012 -0700
@@ -111,6 +111,7 @@
 #define TRAP_alignment_check  17
 #define TRAP_machine_check    18
 #define TRAP_simd_error       19
+#define TRAP_last_reserved    31
 
 /* Set for entry via SYSCALL. Informs return code to use SYSRETQ not IRETQ. */
 /* NB. Same as VGCF_in_syscall. No bits in common with any other TRAP_ defn. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 07:59:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 07:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8kN-0003BM-Bp; Fri, 20 Apr 2012 07:59:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SL8kL-0003BH-8P
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 07:59:13 +0000
Received: from [85.158.143.99:58545] by server-2.bemta-4.messagelabs.com id
	4D/0C-17550-057119F4; Fri, 20 Apr 2012 07:59:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334908751!24458942!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31060 invoked from network); 20 Apr 2012 07:59:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 07:59:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 08:59:11 +0100
Message-Id: <4F91336D020000780007EC66@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 08:59:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Tim Deegan" <tim@xen.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
In-Reply-To: <20120419170840.GD23663@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Gianluca Guida <glguida@gmail.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.04.12 at 19:08, Tim Deegan <tim@xen.org> wrote:
> At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
>> After a hvm+shadow domain dies (either clean shutdown or merciless
>> destroy), the domain is left in a zombie state with 1 (one) page left
>> dangling with a single reference.
> 
> The reference is to the top-level pagetable that was pointed to by CR3
> when the domain was killed.  This bug came in with:
> 
>  changeset:   23142:f5e8d152a565
>  user:        Jan Beulich <jbeulich@novell.com>
>  date:        Tue Apr 05 13:01:25 2011 +0100
>  description: x86: split struct vcpu
> 
> where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> their VCPUs as they die.  Proposed fix attached.

Acked-by: Jan Beulich <jbeulich@suse.com>

I'm sorry for that. Given that this had been quite some time back, I
can only guess that I got misguided by the fact that
arch_vcpu_reset() calls this for PV only (legitimately, i.e. not causing
any leak).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 07:59:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 07:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8kN-0003BM-Bp; Fri, 20 Apr 2012 07:59:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SL8kL-0003BH-8P
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 07:59:13 +0000
Received: from [85.158.143.99:58545] by server-2.bemta-4.messagelabs.com id
	4D/0C-17550-057119F4; Fri, 20 Apr 2012 07:59:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334908751!24458942!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31060 invoked from network); 20 Apr 2012 07:59:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 07:59:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 08:59:11 +0100
Message-Id: <4F91336D020000780007EC66@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 08:59:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Tim Deegan" <tim@xen.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
In-Reply-To: <20120419170840.GD23663@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Gianluca Guida <glguida@gmail.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.04.12 at 19:08, Tim Deegan <tim@xen.org> wrote:
> At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
>> After a hvm+shadow domain dies (either clean shutdown or merciless
>> destroy), the domain is left in a zombie state with 1 (one) page left
>> dangling with a single reference.
> 
> The reference is to the top-level pagetable that was pointed to by CR3
> when the domain was killed.  This bug came in with:
> 
>  changeset:   23142:f5e8d152a565
>  user:        Jan Beulich <jbeulich@novell.com>
>  date:        Tue Apr 05 13:01:25 2011 +0100
>  description: x86: split struct vcpu
> 
> where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> their VCPUs as they die.  Proposed fix attached.

Acked-by: Jan Beulich <jbeulich@suse.com>

I'm sorry for that. Given that this had been quite some time back, I
can only guess that I got misguided by the fact that
arch_vcpu_reset() calls this for PV only (legitimately, i.e. not causing
any leak).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8qy-0003mR-2P; Fri, 20 Apr 2012 08:06:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SL8qw-0003mM-QX
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 08:06:03 +0000
Received: from [85.158.139.83:50160] by server-9.bemta-5.messagelabs.com id
	F3/7C-09826-AE8119F4; Fri, 20 Apr 2012 08:06:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334909157!20737929!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7831 invoked from network); 20 Apr 2012 08:05:58 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 08:05:58 -0000
Received: by eekc13 with SMTP id c13so3437653eek.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 01:05:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=yWjklzh7LepIB6aYgQtGdp42nDo+m2DyjNpjxCwPX0M=;
	b=ZjPDjfoiCMjLpMTvTYh1tvmXgfM1GJh9OMw7T7MBsLUnM9D+PLwIyzXMbtPpr5uUuV
	Kz0R698cUU1TEFsAfZyDJoFy6VRA98O7cc9/nfWr526qYEWT7Cy7aEe7M2m+hi2PL2ZF
	YV9l8N8TQ0awseaUCxDcIyQsEX500pD62oPLlWhZ0VUvGo/Omba78f10CWC8863ZtdDI
	EZE/WVcauxq/igxO8ooCjHBoKlDjjsWfzIotHYqTuMZoWo4HUYcWBO1iZna/gX9JflvT
	g9U+dyyj8xgirI/HSJQEgu5pp8dGQhs/NiG0gMngu4zFX5C0lQJ7XvuLu+DXFOZRVOym
	EHeg==
Received: by 10.14.28.132 with SMTP id g4mr833531eea.96.1334909156449;
	Fri, 20 Apr 2012 01:05:56 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id m42sm22545303eef.0.2012.04.20.01.05.54
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 01:05:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 09:05:50 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, <JBeulich@suse.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBB6D76E.31192%keir.xen@gmail.com>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0ezGYtxMCjQE+aAkaBhY23xeky9w==
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Mime-version: 1.0
Cc: wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:

> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1334875170 14400
> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Wei Huang <wei.huang2@amd.com>
> Tested-by: Wei Huang <wei.huang2@amd.com>

Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
possible cross-CPU TSC skew.

 -- Keir

> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>  {
>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>  
>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
> -    if ( enable )
> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
> +
> +    if ( enable && !cpu_has_tsc_ratio ) {
>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
> +    }
>  
>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>  }
>  
>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:06:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8qy-0003mR-2P; Fri, 20 Apr 2012 08:06:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SL8qw-0003mM-QX
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 08:06:03 +0000
Received: from [85.158.139.83:50160] by server-9.bemta-5.messagelabs.com id
	F3/7C-09826-AE8119F4; Fri, 20 Apr 2012 08:06:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334909157!20737929!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7831 invoked from network); 20 Apr 2012 08:05:58 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 08:05:58 -0000
Received: by eekc13 with SMTP id c13so3437653eek.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 01:05:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=yWjklzh7LepIB6aYgQtGdp42nDo+m2DyjNpjxCwPX0M=;
	b=ZjPDjfoiCMjLpMTvTYh1tvmXgfM1GJh9OMw7T7MBsLUnM9D+PLwIyzXMbtPpr5uUuV
	Kz0R698cUU1TEFsAfZyDJoFy6VRA98O7cc9/nfWr526qYEWT7Cy7aEe7M2m+hi2PL2ZF
	YV9l8N8TQ0awseaUCxDcIyQsEX500pD62oPLlWhZ0VUvGo/Omba78f10CWC8863ZtdDI
	EZE/WVcauxq/igxO8ooCjHBoKlDjjsWfzIotHYqTuMZoWo4HUYcWBO1iZna/gX9JflvT
	g9U+dyyj8xgirI/HSJQEgu5pp8dGQhs/NiG0gMngu4zFX5C0lQJ7XvuLu+DXFOZRVOym
	EHeg==
Received: by 10.14.28.132 with SMTP id g4mr833531eea.96.1334909156449;
	Fri, 20 Apr 2012 01:05:56 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id m42sm22545303eef.0.2012.04.20.01.05.54
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 01:05:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 09:05:50 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, <JBeulich@suse.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBB6D76E.31192%keir.xen@gmail.com>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0ezGYtxMCjQE+aAkaBhY23xeky9w==
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Mime-version: 1.0
Cc: wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:

> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1334875170 14400
> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Wei Huang <wei.huang2@amd.com>
> Tested-by: Wei Huang <wei.huang2@amd.com>

Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
possible cross-CPU TSC skew.

 -- Keir

> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>  {
>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>  
>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
> -    if ( enable )
> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
> +
> +    if ( enable && !cpu_has_tsc_ratio ) {
>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
> +    }
>  
>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>  }
>  
>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:15:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8zP-00049N-Fa; Fri, 20 Apr 2012 08:14:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SL8zN-00049G-WD
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 08:14:46 +0000
Received: from [193.109.254.147:56971] by server-2.bemta-14.messagelabs.com id
	DD/68-19409-5FA119F4; Fri, 20 Apr 2012 08:14:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334909684!5482342!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24997 invoked from network); 20 Apr 2012 08:14:44 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 08:14:44 -0000
Received: by eekc13 with SMTP id c13so3441895eek.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 01:14:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/KRMa+OW7roq45zLWRUoXpmYsMsWP+51u4IiyCgSVLY=;
	b=aKHN1hFTpGefiVqlrRKKkjduKwrieZfi5S2knzBpMTVNRsZT0QGMBoCpMX2k9/7ym1
	CAh8BJflKZkUfM07THS7+jrrh2wylm2v/uWv0FxNIGQGFUjNgdtmhXiJ6yMBphJ1ScZB
	2e3QHvDqwGrS0K86Q2qLz19h3Wcd39miTgBg62imCxS/bQQAHi8GDbig2FUJ/QSnwLaj
	NT2EabfqW+eoGYJ4OcQ0hVWJwmGTkegTljO9qOsxfRUcnE2wzbZcXHWLiwkip8hgcQbv
	H3ZuqmmEZm7yyDSGeshZIz7HRrNBZ1OFCfoaUIgtcRlFsI1h22J8uX1VunlXjOw4ZF3S
	qUCA==
Received: by 10.213.34.20 with SMTP id j20mr446773ebd.73.1334909684225;
	Fri, 20 Apr 2012 01:14:44 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id z47sm22612805een.5.2012.04.20.01.14.42
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 01:14:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 09:14:32 +0100
From: Keir Fraser <keir@xen.org>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, <JBeulich@suse.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBB6D978.3E843%keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0ezGYtxMCjQE+aAkaBhY23xeky9wAATcio
In-Reply-To: <CBB6D76E.31192%keir.xen@gmail.com>
Mime-version: 1.0
Cc: wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 09:05, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
> 
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1334875170 14400
>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> 
>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> Acked-by: Wei Huang <wei.huang2@amd.com>
>> Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> possible cross-CPU TSC skew.

Oh, and apart from that, we're also in feature freeze for 4.2, and this
isn't a bug fix. Similarly, it's not really a candidate for the stable 4.1
branch either, at any time.

 -- Keir

>  -- Keir
> 
>> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
>> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
>> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
>> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>>  {
>>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>>  
>>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
>> -    if ( enable )
>> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
>> +
>> +    if ( enable && !cpu_has_tsc_ratio ) {
>>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
>> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
>> +    }
>>  
>>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
>> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>>  }
>>  
>>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:15:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8zP-00049N-Fa; Fri, 20 Apr 2012 08:14:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SL8zN-00049G-WD
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 08:14:46 +0000
Received: from [193.109.254.147:56971] by server-2.bemta-14.messagelabs.com id
	DD/68-19409-5FA119F4; Fri, 20 Apr 2012 08:14:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334909684!5482342!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24997 invoked from network); 20 Apr 2012 08:14:44 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 08:14:44 -0000
Received: by eekc13 with SMTP id c13so3441895eek.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 01:14:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/KRMa+OW7roq45zLWRUoXpmYsMsWP+51u4IiyCgSVLY=;
	b=aKHN1hFTpGefiVqlrRKKkjduKwrieZfi5S2knzBpMTVNRsZT0QGMBoCpMX2k9/7ym1
	CAh8BJflKZkUfM07THS7+jrrh2wylm2v/uWv0FxNIGQGFUjNgdtmhXiJ6yMBphJ1ScZB
	2e3QHvDqwGrS0K86Q2qLz19h3Wcd39miTgBg62imCxS/bQQAHi8GDbig2FUJ/QSnwLaj
	NT2EabfqW+eoGYJ4OcQ0hVWJwmGTkegTljO9qOsxfRUcnE2wzbZcXHWLiwkip8hgcQbv
	H3ZuqmmEZm7yyDSGeshZIz7HRrNBZ1OFCfoaUIgtcRlFsI1h22J8uX1VunlXjOw4ZF3S
	qUCA==
Received: by 10.213.34.20 with SMTP id j20mr446773ebd.73.1334909684225;
	Fri, 20 Apr 2012 01:14:44 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id z47sm22612805een.5.2012.04.20.01.14.42
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 01:14:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 09:14:32 +0100
From: Keir Fraser <keir@xen.org>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, <JBeulich@suse.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBB6D978.3E843%keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0ezGYtxMCjQE+aAkaBhY23xeky9wAATcio
In-Reply-To: <CBB6D76E.31192%keir.xen@gmail.com>
Mime-version: 1.0
Cc: wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 09:05, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
> 
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1334875170 14400
>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> 
>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> Acked-by: Wei Huang <wei.huang2@amd.com>
>> Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> possible cross-CPU TSC skew.

Oh, and apart from that, we're also in feature freeze for 4.2, and this
isn't a bug fix. Similarly, it's not really a candidate for the stable 4.1
branch either, at any time.

 -- Keir

>  -- Keir
> 
>> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
>> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
>> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
>> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>>  {
>>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>>  
>>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
>> -    if ( enable )
>> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
>> +
>> +    if ( enable && !cpu_has_tsc_ratio ) {
>>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
>> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
>> +    }
>>  
>>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
>> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>>  }
>>  
>>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:15:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8zo-0004AJ-9H; Fri, 20 Apr 2012 08:15:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SL8zm-0004A8-9u
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:15:10 +0000
Received: from [85.158.143.35:10477] by server-2.bemta-4.messagelabs.com id
	69/67-17550-D0B119F4; Fri, 20 Apr 2012 08:15:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334909707!10839453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8678 invoked from network); 20 Apr 2012 08:15:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:15:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 09:15:06 +0100
Message-Id: <4F913727020000780007EC7A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 09:15:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1334875170 14400
> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.

While the patch itself looks fine, I'm having difficulty to connect the
mentioning of TSC_MODE_ALWAYS_EMULATE to it - afaics all modes
are affected as long as they result in d->arch.vtsc to be set.

Jan

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Wei Huang <wei.huang2@amd.com>
> Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>  {
>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>  
>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
> -    if ( enable )
> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
> +
> +    if ( enable && !cpu_has_tsc_ratio ) {
>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
> +    }
>  
>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>  }
>  
>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:15:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL8zo-0004AJ-9H; Fri, 20 Apr 2012 08:15:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SL8zm-0004A8-9u
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:15:10 +0000
Received: from [85.158.143.35:10477] by server-2.bemta-4.messagelabs.com id
	69/67-17550-D0B119F4; Fri, 20 Apr 2012 08:15:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334909707!10839453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8678 invoked from network); 20 Apr 2012 08:15:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:15:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 09:15:06 +0100
Message-Id: <4F913727020000780007EC7A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 09:15:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1334875170 14400
> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.

While the patch itself looks fine, I'm having difficulty to connect the
mentioning of TSC_MODE_ALWAYS_EMULATE to it - afaics all modes
are affected as long as they result in d->arch.vtsc to be set.

Jan

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Wei Huang <wei.huang2@amd.com>
> Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>  {
>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>  
>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
> -    if ( enable )
> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
> +
> +    if ( enable && !cpu_has_tsc_ratio ) {
>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
> +    }
>  
>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>  }
>  
>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:16:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:16:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL916-0004Gv-P9; Fri, 20 Apr 2012 08:16:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SL915-0004Gf-Bl
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:16:31 +0000
Received: from [85.158.143.99:44153] by server-1.bemta-4.messagelabs.com id
	5D/37-20925-E5B119F4; Fri, 20 Apr 2012 08:16:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334909789!19213337!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20213 invoked from network); 20 Apr 2012 08:16:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:16:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SL913-000AFe-BR; Fri, 20 Apr 2012 08:16:29 +0000
Date: Fri, 20 Apr 2012 09:16:29 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120420081629.GB39206@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
	<20120418164351.GS7013@ocelot.phlegethon.org>
	<4F8EF575.6000002@newcastle.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8EF575.6000002@newcastle.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:10 +0100 on 18 Apr (1334772613), Francisco Rocha wrote:
> On 04/18/2012 05:43 PM, Tim Deegan wrote:
> >
> > At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > > Hi Tim,
> > >
> > > I was thinking about changing my approach.
> > >
> > > I think that for now I will leave those pages off because I am
> > > mostly interested in protecting other areas.
> > >
> > > Those accesses for now are inevitable to get the VM to properly
> > > operate. Now, the question is if it is possible to use page table
> > > entries to do what I want to do.
> > >
> > > The objective would be to use a bit flag that would determine if
> > > the pages are returned when a call to map_foreign_range is made.
> > > So, my final objective would be that only pages used for the three
> > > operations you describe are accessible to Dom0.
> > > Everything that is not BIOS and related, Qemu or PV backend
> > > drivers will not be returned.
> > >
> > > From what I see in the header files you use 12-bits from a 24-bit
> > > flag (x86_64). Can we do it? This would again take us to controlling
> > > access at get_page_from_l1e(), right?
> >
> > Are you talking about the count_info and type_info fields?  yes, I think
> > you can probably put a new flag or two in there.
> >
> I was thinking about the ones used in page table entries
> (_PAGE_PRESENT|RW, etc).

Oh.  That's probably not so suitable for access control since (a) there
may be more that one PTE pointing to the same page, even controlled by
different domains, and what if they have different flags? and (b) given
a page number you can't easily find a PTE that points to it to look at
the bits.

Th type_info and count_info fields, on the other hand, exist once per
page and are entirely under Xen's control.

> > Choosing which pages
> > qemu can map will be interesting, though -- it needs to map anything the
> > VM uses for I/O.  But maybe you can just define the things you protect
> > and declare taht they can't be used for I/O.  That sounds easier. :)
> >
> The objective is to protect the kernel and its data structures.
> That is why I was considering the flags I previously mentioned.
> There is one denominated _PAGE_GUEST_KERNEL.

That's part of the 64-bit PV interface; if the guest is 32-bit or HVM it
won't be used like that.  I think you'll have to modify the kernel to
explicitly tell Xen which pages are kernel ones (wih a hypercall) and
then remember that with a bit in the count_info/type_info.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:16:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:16:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL916-0004Gv-P9; Fri, 20 Apr 2012 08:16:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SL915-0004Gf-Bl
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:16:31 +0000
Received: from [85.158.143.99:44153] by server-1.bemta-4.messagelabs.com id
	5D/37-20925-E5B119F4; Fri, 20 Apr 2012 08:16:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334909789!19213337!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20213 invoked from network); 20 Apr 2012 08:16:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:16:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SL913-000AFe-BR; Fri, 20 Apr 2012 08:16:29 +0000
Date: Fri, 20 Apr 2012 09:16:29 +0100
From: Tim Deegan <tim@xen.org>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Message-ID: <20120420081629.GB39206@ocelot.phlegethon.org>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
	<20120418164351.GS7013@ocelot.phlegethon.org>
	<4F8EF575.6000002@newcastle.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8EF575.6000002@newcastle.ac.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:10 +0100 on 18 Apr (1334772613), Francisco Rocha wrote:
> On 04/18/2012 05:43 PM, Tim Deegan wrote:
> >
> > At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > > Hi Tim,
> > >
> > > I was thinking about changing my approach.
> > >
> > > I think that for now I will leave those pages off because I am
> > > mostly interested in protecting other areas.
> > >
> > > Those accesses for now are inevitable to get the VM to properly
> > > operate. Now, the question is if it is possible to use page table
> > > entries to do what I want to do.
> > >
> > > The objective would be to use a bit flag that would determine if
> > > the pages are returned when a call to map_foreign_range is made.
> > > So, my final objective would be that only pages used for the three
> > > operations you describe are accessible to Dom0.
> > > Everything that is not BIOS and related, Qemu or PV backend
> > > drivers will not be returned.
> > >
> > > From what I see in the header files you use 12-bits from a 24-bit
> > > flag (x86_64). Can we do it? This would again take us to controlling
> > > access at get_page_from_l1e(), right?
> >
> > Are you talking about the count_info and type_info fields?  yes, I think
> > you can probably put a new flag or two in there.
> >
> I was thinking about the ones used in page table entries
> (_PAGE_PRESENT|RW, etc).

Oh.  That's probably not so suitable for access control since (a) there
may be more that one PTE pointing to the same page, even controlled by
different domains, and what if they have different flags? and (b) given
a page number you can't easily find a PTE that points to it to look at
the bits.

Th type_info and count_info fields, on the other hand, exist once per
page and are entirely under Xen's control.

> > Choosing which pages
> > qemu can map will be interesting, though -- it needs to map anything the
> > VM uses for I/O.  But maybe you can just define the things you protect
> > and declare taht they can't be used for I/O.  That sounds easier. :)
> >
> The objective is to protect the kernel and its data structures.
> That is why I was considering the flags I previously mentioned.
> There is one denominated _PAGE_GUEST_KERNEL.

That's part of the 64-bit PV interface; if the guest is 32-bit or HVM it
won't be used like that.  I think you'll have to modify the kernel to
explicitly tell Xen which pages are kernel ones (wih a hypercall) and
then remember that with a bit in the count_info/type_info.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9TZ-0004op-D4; Fri, 20 Apr 2012 08:45:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SL9TX-0004ok-Ec
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:45:55 +0000
Received: from [193.109.254.147:15167] by server-3.bemta-14.messagelabs.com id
	76/DC-23274-242219F4; Fri, 20 Apr 2012 08:45:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334911554!3021883!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23162 invoked from network); 20 Apr 2012 08:45:54 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 08:45:54 -0000
Received: by eaaf11 with SMTP id f11so2529166eaa.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 01:45:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NBgr9vhKd9STR/3+eBZ8bxKmodLgEViIQGgVv+16NLg=;
	b=swflN3JEZeolfv3zM5QpUnWHvMMAv28ioH+phG0UZqdHQOYFpycB332tRDjo/Kl0rw
	agVowVySQLJOtjFDVwUzrYGv8KSkeBo5pIUAMRyBJ8j+fslHnUt0DJQoEgUA9mJPN5Dr
	SFR/uVukZY+P9BoEbldH8ectuCUF7tdao+9Sguh15H5lu/PImwBEwZ34y5k4quvnokmC
	K0TDzbqztr6Nl8Vrs9UORCYCW/b39dXM/1G6GjdnROP17v8LKfGM+VgZZn/9H50/n59k
	lYhLxiuROBbTvVrtNmiMBE++gzTLi9NVAV7GWXW201QUxyWe5yv3DAxPQC3j8hfpaMqj
	w40A==
Received: by 10.213.26.69 with SMTP id d5mr467739ebc.61.1334911553798;
	Fri, 20 Apr 2012 01:45:53 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id n55sm22978560eef.6.2012.04.20.01.45.52
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 01:45:53 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 09:45:42 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <CBB6E0C6.3E84F%keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0e0ffrkcNXY2TyYkuTWMDNgEFYaw==
In-Reply-To: <4F913727020000780007EC7A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.huang2@amd.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 09:15, "Jan Beulich" <JBeulich@suse.com> wrote:

>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> 
>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> 
> While the patch itself looks fine, I'm having difficulty to connect the
> mentioning of TSC_MODE_ALWAYS_EMULATE to it - afaics all modes
> are affected as long as they result in d->arch.vtsc to be set.

I think the real point of this patch is they *never* want to trap and
emulate RDTSC on these newer processors.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9TZ-0004op-D4; Fri, 20 Apr 2012 08:45:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SL9TX-0004ok-Ec
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:45:55 +0000
Received: from [193.109.254.147:15167] by server-3.bemta-14.messagelabs.com id
	76/DC-23274-242219F4; Fri, 20 Apr 2012 08:45:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334911554!3021883!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23162 invoked from network); 20 Apr 2012 08:45:54 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 08:45:54 -0000
Received: by eaaf11 with SMTP id f11so2529166eaa.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 01:45:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NBgr9vhKd9STR/3+eBZ8bxKmodLgEViIQGgVv+16NLg=;
	b=swflN3JEZeolfv3zM5QpUnWHvMMAv28ioH+phG0UZqdHQOYFpycB332tRDjo/Kl0rw
	agVowVySQLJOtjFDVwUzrYGv8KSkeBo5pIUAMRyBJ8j+fslHnUt0DJQoEgUA9mJPN5Dr
	SFR/uVukZY+P9BoEbldH8ectuCUF7tdao+9Sguh15H5lu/PImwBEwZ34y5k4quvnokmC
	K0TDzbqztr6Nl8Vrs9UORCYCW/b39dXM/1G6GjdnROP17v8LKfGM+VgZZn/9H50/n59k
	lYhLxiuROBbTvVrtNmiMBE++gzTLi9NVAV7GWXW201QUxyWe5yv3DAxPQC3j8hfpaMqj
	w40A==
Received: by 10.213.26.69 with SMTP id d5mr467739ebc.61.1334911553798;
	Fri, 20 Apr 2012 01:45:53 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id n55sm22978560eef.6.2012.04.20.01.45.52
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 01:45:53 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 09:45:42 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <CBB6E0C6.3E84F%keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0e0ffrkcNXY2TyYkuTWMDNgEFYaw==
In-Reply-To: <4F913727020000780007EC7A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.huang2@amd.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 09:15, "Jan Beulich" <JBeulich@suse.com> wrote:

>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> 
>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> 
> While the patch itself looks fine, I'm having difficulty to connect the
> mentioning of TSC_MODE_ALWAYS_EMULATE to it - afaics all modes
> are affected as long as they result in d->arch.vtsc to be set.

I think the real point of this patch is they *never* want to trap and
emulate RDTSC on these newer processors.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:52:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9Z7-0004wb-5a; Fri, 20 Apr 2012 08:51:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SL9Z5-0004wU-FS
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:51:39 +0000
Received: from [85.158.139.83:43839] by server-3.bemta-5.messagelabs.com id
	10/8D-25237-A93219F4; Fri, 20 Apr 2012 08:51:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334911897!17341155!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26516 invoked from network); 20 Apr 2012 08:51:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:51:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SL9Yz-000ALo-MH; Fri, 20 Apr 2012 08:51:33 +0000
Date: Fri, 20 Apr 2012 09:51:33 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120420085133.GD39206@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
	<4F91336D020000780007EC66@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F91336D020000780007EC66@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Gianluca Guida <glguida@gmail.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:59 +0100 on 20 Apr (1334912349), Jan Beulich wrote:
> >>> On 19.04.12 at 19:08, Tim Deegan <tim@xen.org> wrote:
> > At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
> >> After a hvm+shadow domain dies (either clean shutdown or merciless
> >> destroy), the domain is left in a zombie state with 1 (one) page left
> >> dangling with a single reference.
> > 
> > The reference is to the top-level pagetable that was pointed to by CR3
> > when the domain was killed.  This bug came in with:
> > 
> >  changeset:   23142:f5e8d152a565
> >  user:        Jan Beulich <jbeulich@novell.com>
> >  date:        Tue Apr 05 13:01:25 2011 +0100
> >  description: x86: split struct vcpu
> > 
> > where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> > their VCPUs as they die.  Proposed fix attached.
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm sorry for that. Given that this had been quite some time back, I
> can only guess that I got misguided by the fact that
> arch_vcpu_reset() calls this for PV only (legitimately, i.e. not causing
> any leak).

Yeah, it's not exactly clear.  Maybe after 4.2 I'll look at making it
more uniform.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:52:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9Z7-0004wb-5a; Fri, 20 Apr 2012 08:51:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SL9Z5-0004wU-FS
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:51:39 +0000
Received: from [85.158.139.83:43839] by server-3.bemta-5.messagelabs.com id
	10/8D-25237-A93219F4; Fri, 20 Apr 2012 08:51:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334911897!17341155!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26516 invoked from network); 20 Apr 2012 08:51:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:51:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SL9Yz-000ALo-MH; Fri, 20 Apr 2012 08:51:33 +0000
Date: Fri, 20 Apr 2012 09:51:33 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120420085133.GD39206@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
	<4F91336D020000780007EC66@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F91336D020000780007EC66@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Gianluca Guida <glguida@gmail.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:59 +0100 on 20 Apr (1334912349), Jan Beulich wrote:
> >>> On 19.04.12 at 19:08, Tim Deegan <tim@xen.org> wrote:
> > At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
> >> After a hvm+shadow domain dies (either clean shutdown or merciless
> >> destroy), the domain is left in a zombie state with 1 (one) page left
> >> dangling with a single reference.
> > 
> > The reference is to the top-level pagetable that was pointed to by CR3
> > when the domain was killed.  This bug came in with:
> > 
> >  changeset:   23142:f5e8d152a565
> >  user:        Jan Beulich <jbeulich@novell.com>
> >  date:        Tue Apr 05 13:01:25 2011 +0100
> >  description: x86: split struct vcpu
> > 
> > where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> > their VCPUs as they die.  Proposed fix attached.
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm sorry for that. Given that this had been quite some time back, I
> can only guess that I got misguided by the fact that
> arch_vcpu_reset() calls this for PV only (legitimately, i.e. not causing
> any leak).

Yeah, it's not exactly clear.  Maybe after 4.2 I'll look at making it
more uniform.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:54:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:54:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9bo-00052o-NL; Fri, 20 Apr 2012 08:54:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SL9bn-00052h-Ly
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:54:27 +0000
Received: from [85.158.143.99:36036] by server-3.bemta-4.messagelabs.com id
	17/02-05853-344219F4; Fri, 20 Apr 2012 08:54:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334912066!23951295!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13561 invoked from network); 20 Apr 2012 08:54:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:54:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 09:54:25 +0100
Message-Id: <4F914060020000780007EC9D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 09:54:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <f60377584f2d62e82d62.1334898269@vollum>
In-Reply-To: <f60377584f2d62e82d62.1334898269@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined)
 interrupts to be injected in to the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 07:04, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> If xc_hvm_inject_trap() is called on a software (user defined) interrupt, it 
> causes the guest to crash with a vmentry failure. The following patch fixes 
> this issue.
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r 9036d6f974de -r f60377584f2d xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 21:55:51 2012 -0700
> +++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 22:01:50 2012 -0700
> @@ -1374,6 +1374,13 @@ void vmx_inject_hw_exception(int trap, i
>  
>          type = X86_EVENTTYPE_SW_EXCEPTION;
>          __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */
> +        break;
> +    default:
> +        if ( trap > TRAP_last_reserved )
> +        {
> +            type = X86_EVENTTYPE_SW_EXCEPTION;
> +            __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */

I doubt this is generally correct, in particular for the use you appear
to desire: When the injection is not the result of an INT nn
instruction (which I would guess to be the case when coming from
libxc), you shouldn't set a non-zero instruction length. I believe this
is also wrong for the INT3 code above.

Additionally the problem should not be limited to injection coming
from libxc - injection originating from x86_emulate() should be
affected as much.

Jun, Eddie - I further wonder why #OF is not being handled according
to the documentation here either (should also result in
X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from
TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it
should be annotated with a comment saying why fall-through is
intended here). Nor does the documentation state that TRAP_debug
should ever result in X86_EVENTTYPE_SW_EXCEPTION.

Finally, the whole injection logic (including the patch here) doesn't
appear to cope with INT nn being used by a guest with nn < 32, nor
with any (pointless) prefixes used on INT3 or INT nn.

Jan

> +        }
>      }
>  
>      if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
> diff -r 9036d6f974de -r f60377584f2d xen/include/asm-x86/processor.h
> --- a/xen/include/asm-x86/processor.h	Thu Apr 19 21:55:51 2012 -0700
> +++ b/xen/include/asm-x86/processor.h	Thu Apr 19 22:01:50 2012 -0700
> @@ -111,6 +111,7 @@
>  #define TRAP_alignment_check  17
>  #define TRAP_machine_check    18
>  #define TRAP_simd_error       19
> +#define TRAP_last_reserved    31
>  
>  /* Set for entry via SYSCALL. Informs return code to use SYSRETQ not IRETQ. 
> */
>  /* NB. Same as VGCF_in_syscall. No bits in common with any other TRAP_ 
> defn. */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 08:54:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 08:54:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9bo-00052o-NL; Fri, 20 Apr 2012 08:54:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SL9bn-00052h-Ly
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 08:54:27 +0000
Received: from [85.158.143.99:36036] by server-3.bemta-4.messagelabs.com id
	17/02-05853-344219F4; Fri, 20 Apr 2012 08:54:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334912066!23951295!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13561 invoked from network); 20 Apr 2012 08:54:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 08:54:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 09:54:25 +0100
Message-Id: <4F914060020000780007EC9D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 09:54:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <f60377584f2d62e82d62.1334898269@vollum>
In-Reply-To: <f60377584f2d62e82d62.1334898269@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined)
 interrupts to be injected in to the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 07:04, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> If xc_hvm_inject_trap() is called on a software (user defined) interrupt, it 
> causes the guest to crash with a vmentry failure. The following patch fixes 
> this issue.
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r 9036d6f974de -r f60377584f2d xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 21:55:51 2012 -0700
> +++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 19 22:01:50 2012 -0700
> @@ -1374,6 +1374,13 @@ void vmx_inject_hw_exception(int trap, i
>  
>          type = X86_EVENTTYPE_SW_EXCEPTION;
>          __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */
> +        break;
> +    default:
> +        if ( trap > TRAP_last_reserved )
> +        {
> +            type = X86_EVENTTYPE_SW_EXCEPTION;
> +            __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */

I doubt this is generally correct, in particular for the use you appear
to desire: When the injection is not the result of an INT nn
instruction (which I would guess to be the case when coming from
libxc), you shouldn't set a non-zero instruction length. I believe this
is also wrong for the INT3 code above.

Additionally the problem should not be limited to injection coming
from libxc - injection originating from x86_emulate() should be
affected as much.

Jun, Eddie - I further wonder why #OF is not being handled according
to the documentation here either (should also result in
X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from
TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it
should be annotated with a comment saying why fall-through is
intended here). Nor does the documentation state that TRAP_debug
should ever result in X86_EVENTTYPE_SW_EXCEPTION.

Finally, the whole injection logic (including the patch here) doesn't
appear to cope with INT nn being used by a guest with nn < 32, nor
with any (pointless) prefixes used on INT3 or INT nn.

Jan

> +        }
>      }
>  
>      if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
> diff -r 9036d6f974de -r f60377584f2d xen/include/asm-x86/processor.h
> --- a/xen/include/asm-x86/processor.h	Thu Apr 19 21:55:51 2012 -0700
> +++ b/xen/include/asm-x86/processor.h	Thu Apr 19 22:01:50 2012 -0700
> @@ -111,6 +111,7 @@
>  #define TRAP_alignment_check  17
>  #define TRAP_machine_check    18
>  #define TRAP_simd_error       19
> +#define TRAP_last_reserved    31
>  
>  /* Set for entry via SYSCALL. Informs return code to use SYSRETQ not IRETQ. 
> */
>  /* NB. Same as VGCF_in_syscall. No bits in common with any other TRAP_ 
> defn. */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:03:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9kZ-0005I1-5u; Fri, 20 Apr 2012 09:03:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SL9kX-0005Hw-Ts
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:03:30 +0000
Received: from [85.158.143.99:47292] by server-1.bemta-4.messagelabs.com id
	8A/29-20925-166219F4; Fri, 20 Apr 2012 09:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334912607!14859240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTI0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 20 Apr 2012 09:03:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12042605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:03:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 10:03:25 +0100
Message-ID: <1334912603.28331.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Fri, 20 Apr 2012 10:03:23 +0100
In-Reply-To: <1334817587.11493.44.camel@dagon.hellion.org.uk>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>, M A Young <m.a.young@durham.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 07:39 +0100, Ian Campbell wrote:
> > > diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> > > --- a/tools/python/xen/xend/image.py    Mon Apr 16 17:57:00 2012 +0100
> > > +++ b/tools/python/xen/xend/image.py    Tue Apr 17 11:26:06 2012 +0100
> > > @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
> > >             if vifname:
> > >                 vifname = "tap-" + vifname
> > 
> > The above shouldn't it be:
> > 
> > vifname = "xentap-" + vifname
> 
> You are absolutely right, not sure how I missed that!
> 
> I'm out-of-office today but I'll resend later.

8<--------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334912375 -3600
# Node ID fbc0dc31b6d71bed654a05ea85ec56c34ac2ef21
# Parent  f28eea0efe1223277400ff5408b1e85df5efdeac
libxl/xend: name tap devices with a xentap prefix

This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)

Also add "xentap-" prefix to the tap device when an explicit name is given to
avoid a conflict with the vif device, which would otherwise have the same name.
Likewise correct the documentation for this option which suggested it applied
to HVM tap devices only.

Reported by Michael Young.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f28eea0efe12 -r fbc0dc31b6d7 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Fri Apr 20 09:59:12 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Fri Apr 20 09:59:35 2012 +0100
@@ -93,11 +93,14 @@ are:
 
 ### vifname
 
-This keyword is valid for HVM guest devices with `type=ioemu` only.
+Specifies the backend device name for the virtual device.
 
-Specifies the backend device name for an emulated device. The default
-is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
-is the device number.
+If the domain is an HVM domain then the associated emulated (tap)
+device will have a "xentap-" prefix added.
+
+The default name for the virtual device is `vifDOMID.DEVID` where
+`DOMID` is the guest domain ID and `DEVID` is the device
+number. Likewise the default tap name is `xentapDOMID.DEVID`.
 
 ### script
 
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/hotplug/Linux/vif-common.sh
--- a/tools/hotplug/Linux/vif-common.sh	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/hotplug/Linux/vif-common.sh	Fri Apr 20 09:59:35 2012 +0100
@@ -85,8 +85,8 @@ elif [ "$type_if" = tap ]; then
     : ${INTERFACE:?}
 
     # Get xenbus_path from device name.
-    # The name is built like that: "tap${domid}.${devid}".
-    dev_=${dev#tap}
+    # The name is built like that: "xentap${domid}.${devid}".
+    dev_=${dev#xentap}
     domid=${dev_%.*}
     devid=${dev_#*.}
 
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Fri Apr 20 09:59:35 2012 +0100
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blkt
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Apr 20 09:59:35 2012 +0100
@@ -212,9 +212,9 @@ static char ** libxl__build_device_model
                 char *ifname;
                 if (!vifs[i].ifname)
                     ifname = libxl__sprintf(gc,
-                                            "tap%d.%d", domid, vifs[i].devid);
+                                            "xentap%d.%d", domid, vifs[i].devid);
                 else
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
@@ -451,10 +451,10 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                    ifname = libxl__sprintf(gc, "xentap%d.%d",
                                             guest_domid, vifs[i].devid);
                 } else {
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 }
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/python/xen/xend/image.py	Fri Apr 20 09:59:35 2012 +0100
@@ -919,9 +919,9 @@ class HVMImageHandler(ImageHandler):
                        (nics, mac, model))
             vifname = devinfo.get('vifname')
             if vifname:
-                vifname = "tap-" + vifname
+                vifname = "xentap-" + vifname
             else:
-                vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1)
+                vifname = "xentap%d.%d" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
             ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
                        (nics, vifname, bridge))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:03:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9kZ-0005I1-5u; Fri, 20 Apr 2012 09:03:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SL9kX-0005Hw-Ts
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:03:30 +0000
Received: from [85.158.143.99:47292] by server-1.bemta-4.messagelabs.com id
	8A/29-20925-166219F4; Fri, 20 Apr 2012 09:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334912607!14859240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTI0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 20 Apr 2012 09:03:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12042605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:03:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 10:03:25 +0100
Message-ID: <1334912603.28331.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Fri, 20 Apr 2012 10:03:23 +0100
In-Reply-To: <1334817587.11493.44.camel@dagon.hellion.org.uk>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>, M A Young <m.a.young@durham.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 07:39 +0100, Ian Campbell wrote:
> > > diff -r 8d92d1f34921 -r de3e65d804cc tools/python/xen/xend/image.py
> > > --- a/tools/python/xen/xend/image.py    Mon Apr 16 17:57:00 2012 +0100
> > > +++ b/tools/python/xen/xend/image.py    Tue Apr 17 11:26:06 2012 +0100
> > > @@ -921,7 +921,7 @@ class HVMImageHandler(ImageHandler):
> > >             if vifname:
> > >                 vifname = "tap-" + vifname
> > 
> > The above shouldn't it be:
> > 
> > vifname = "xentap-" + vifname
> 
> You are absolutely right, not sure how I missed that!
> 
> I'm out-of-office today but I'll resend later.

8<--------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1334912375 -3600
# Node ID fbc0dc31b6d71bed654a05ea85ec56c34ac2ef21
# Parent  f28eea0efe1223277400ff5408b1e85df5efdeac
libxl/xend: name tap devices with a xentap prefix

This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)

Also add "xentap-" prefix to the tap device when an explicit name is given to
avoid a conflict with the vif device, which would otherwise have the same name.
Likewise correct the documentation for this option which suggested it applied
to HVM tap devices only.

Reported by Michael Young.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f28eea0efe12 -r fbc0dc31b6d7 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Fri Apr 20 09:59:12 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Fri Apr 20 09:59:35 2012 +0100
@@ -93,11 +93,14 @@ are:
 
 ### vifname
 
-This keyword is valid for HVM guest devices with `type=ioemu` only.
+Specifies the backend device name for the virtual device.
 
-Specifies the backend device name for an emulated device. The default
-is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
-is the device number.
+If the domain is an HVM domain then the associated emulated (tap)
+device will have a "xentap-" prefix added.
+
+The default name for the virtual device is `vifDOMID.DEVID` where
+`DOMID` is the guest domain ID and `DEVID` is the device
+number. Likewise the default tap name is `xentapDOMID.DEVID`.
 
 ### script
 
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/hotplug/Linux/vif-common.sh
--- a/tools/hotplug/Linux/vif-common.sh	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/hotplug/Linux/vif-common.sh	Fri Apr 20 09:59:35 2012 +0100
@@ -85,8 +85,8 @@ elif [ "$type_if" = tap ]; then
     : ${INTERFACE:?}
 
     # Get xenbus_path from device name.
-    # The name is built like that: "tap${domid}.${devid}".
-    dev_=${dev#tap}
+    # The name is built like that: "xentap${domid}.${devid}".
+    dev_=${dev#xentap}
     domid=${dev_%.*}
     devid=${dev_#*.}
 
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Fri Apr 20 09:59:35 2012 +0100
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blkt
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Apr 20 09:59:35 2012 +0100
@@ -212,9 +212,9 @@ static char ** libxl__build_device_model
                 char *ifname;
                 if (!vifs[i].ifname)
                     ifname = libxl__sprintf(gc,
-                                            "tap%d.%d", domid, vifs[i].devid);
+                                            "xentap%d.%d", domid, vifs[i].devid);
                 else
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
@@ -451,10 +451,10 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                    ifname = libxl__sprintf(gc, "xentap%d.%d",
                                             guest_domid, vifs[i].devid);
                 } else {
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 }
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
diff -r f28eea0efe12 -r fbc0dc31b6d7 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Fri Apr 20 09:59:12 2012 +0100
+++ b/tools/python/xen/xend/image.py	Fri Apr 20 09:59:35 2012 +0100
@@ -919,9 +919,9 @@ class HVMImageHandler(ImageHandler):
                        (nics, mac, model))
             vifname = devinfo.get('vifname')
             if vifname:
-                vifname = "tap-" + vifname
+                vifname = "xentap-" + vifname
             else:
-                vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1)
+                vifname = "xentap%d.%d" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
             ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
                        (nics, vifname, bridge))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:08:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9oh-0005R0-1E; Fri, 20 Apr 2012 09:07:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SL9oe-0005Qv-T7
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:07:45 +0000
Received: from [85.158.143.35:48465] by server-2.bemta-4.messagelabs.com id
	0D/A7-17550-067219F4; Fri, 20 Apr 2012 09:07:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334912862!12930277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20257 invoked from network); 20 Apr 2012 09:07:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12042713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:07:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 10:07:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SL9ob-0007n8-63;
	Fri, 20 Apr 2012 09:07:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SL9ob-0007vm-2j;
	Fri, 20 Apr 2012 10:07:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12729-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 10:07:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12729: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12729 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12729/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12727

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            9 guest-start                 fail pass in 12728
 test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop          fail pass in 12728
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2         fail pass in 12728

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12727
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12728 REGR. vs. 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12728 never pass

version targeted for testing:
 xen                  d1b0a8a84ccf
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:08:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SL9oh-0005R0-1E; Fri, 20 Apr 2012 09:07:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SL9oe-0005Qv-T7
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:07:45 +0000
Received: from [85.158.143.35:48465] by server-2.bemta-4.messagelabs.com id
	0D/A7-17550-067219F4; Fri, 20 Apr 2012 09:07:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334912862!12930277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20257 invoked from network); 20 Apr 2012 09:07:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12042713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:07:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 10:07:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SL9ob-0007n8-63;
	Fri, 20 Apr 2012 09:07:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SL9ob-0007vm-2j;
	Fri, 20 Apr 2012 10:07:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12729-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 10:07:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12729: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12729 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12729/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12727

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            9 guest-start                 fail pass in 12728
 test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop          fail pass in 12728
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2         fail pass in 12728

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12727
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12728 REGR. vs. 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12728 never pass

version targeted for testing:
 xen                  d1b0a8a84ccf
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:27:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLA7T-0005pt-FQ; Fri, 20 Apr 2012 09:27:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLA7R-0005ph-Qc
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:27:09 +0000
Received: from [85.158.139.83:54675] by server-12.bemta-5.messagelabs.com id
	6A/E9-05587-CEB219F4; Fri, 20 Apr 2012 09:27:08 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334914026!24698381!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4749 invoked from network); 20 Apr 2012 09:27:07 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-182.messagelabs.com with SMTP;
	20 Apr 2012 09:27:07 -0000
Received: from [192.168.1.200] (unknown [180.158.123.16])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 735E3DB970;
	Fri, 20 Apr 2012 17:26:51 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 20 Apr 2012 17:25:57 +0800
Message-ID: <1334913957.2863.1.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/apic: implement io apic read with hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
information instead of fabricated one.

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/xen/apic.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index aee16ab..f1f392d 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -1,14 +1,20 @@
 #include <linux/init.h>
 #include <asm/x86_init.h>
+#include <asm/apic.h>
+#include <xen/interface/physdev.h>
+#include <asm/xen/hypercall.h>
 
 unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
 {
-	if (reg == 0x1)
-		return 0x00170020;
-	else if (reg == 0x0)
-		return apic << 24;
+	struct physdev_apic apic_op;
+	int ret;
 
-	return 0xff;
+	apic_op.apic_physbase = mpc_ioapic_addr(apic);
+	apic_op.reg = reg;
+	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
+	if (ret)
+		return ret;
+	return apic_op.value;
 }
 
 void __init xen_init_apic(void)
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:27:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLA7T-0005pt-FQ; Fri, 20 Apr 2012 09:27:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLA7R-0005ph-Qc
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:27:09 +0000
Received: from [85.158.139.83:54675] by server-12.bemta-5.messagelabs.com id
	6A/E9-05587-CEB219F4; Fri, 20 Apr 2012 09:27:08 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334914026!24698381!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4749 invoked from network); 20 Apr 2012 09:27:07 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-182.messagelabs.com with SMTP;
	20 Apr 2012 09:27:07 -0000
Received: from [192.168.1.200] (unknown [180.158.123.16])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 735E3DB970;
	Fri, 20 Apr 2012 17:26:51 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 20 Apr 2012 17:25:57 +0800
Message-ID: <1334913957.2863.1.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/apic: implement io apic read with hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
information instead of fabricated one.

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/xen/apic.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index aee16ab..f1f392d 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -1,14 +1,20 @@
 #include <linux/init.h>
 #include <asm/x86_init.h>
+#include <asm/apic.h>
+#include <xen/interface/physdev.h>
+#include <asm/xen/hypercall.h>
 
 unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
 {
-	if (reg == 0x1)
-		return 0x00170020;
-	else if (reg == 0x0)
-		return apic << 24;
+	struct physdev_apic apic_op;
+	int ret;
 
-	return 0xff;
+	apic_op.apic_physbase = mpc_ioapic_addr(apic);
+	apic_op.reg = reg;
+	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
+	if (ret)
+		return ret;
+	return apic_op.value;
 }
 
 void __init xen_init_apic(void)
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:27:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLA7L-0005pO-2T; Fri, 20 Apr 2012 09:27:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLA7J-0005pJ-Ti
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:27:02 +0000
Received: from [193.109.254.147:15600] by server-7.bemta-14.messagelabs.com id
	8F/63-01627-5EB219F4; Fri, 20 Apr 2012 09:27:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334914020!5466171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13241 invoked from network); 20 Apr 2012 09:27:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:27:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12043232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:26:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 10:26:59 +0100
Message-ID: <1334914018.28331.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 20 Apr 2012 10:26:58 +0100
In-Reply-To: <20120419170840.GD23663@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Gianluca Guida <glguida@gmail.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 18:08 +0100, Tim Deegan wrote:
> At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
> > After a hvm+shadow domain dies (either clean shutdown or merciless
> > destroy), the domain is left in a zombie state with 1 (one) page left
> > dangling with a single reference.
> 
> The reference is to the top-level pagetable that was pointed to by CR3
> when the domain was killed.  This bug came in with:
> 
>  changeset:   23142:f5e8d152a565
>  user:        Jan Beulich <jbeulich@novell.com>
>  date:        Tue Apr 05 13:01:25 2011 +0100
>  description: x86: split struct vcpu
> 
> where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> their VCPUs as they die.  Proposed fix attached.

FTR this fixes the zombie domain issue I'd been seeing, AFAICT.

Thanks!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:27:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLA7L-0005pO-2T; Fri, 20 Apr 2012 09:27:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLA7J-0005pJ-Ti
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:27:02 +0000
Received: from [193.109.254.147:15600] by server-7.bemta-14.messagelabs.com id
	8F/63-01627-5EB219F4; Fri, 20 Apr 2012 09:27:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1334914020!5466171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13241 invoked from network); 20 Apr 2012 09:27:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:27:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12043232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:26:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 10:26:59 +0100
Message-ID: <1334914018.28331.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 20 Apr 2012 10:26:58 +0100
In-Reply-To: <20120419170840.GD23663@ocelot.phlegethon.org>
References: <b5856216c6c888126d40e9b32781ee52.squirrel@webmail.lagarcavilla.org>
	<20120419170840.GD23663@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Gianluca Guida <glguida@gmail.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re:  Shadow domains left zombie
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 18:08 +0100, Tim Deegan wrote:
> At 09:19 -0700 on 13 Apr (1334308772), Andres Lagar-Cavilla wrote:
> > After a hvm+shadow domain dies (either clean shutdown or merciless
> > destroy), the domain is left in a zombie state with 1 (one) page left
> > dangling with a single reference.
> 
> The reference is to the top-level pagetable that was pointed to by CR3
> when the domain was killed.  This bug came in with:
> 
>  changeset:   23142:f5e8d152a565
>  user:        Jan Beulich <jbeulich@novell.com>
>  date:        Tue Apr 05 13:01:25 2011 +0100
>  description: x86: split struct vcpu
> 
> where HVM domains no longer have vcpu_destroy_pagetables(v) called on
> their VCPUs as they die.  Proposed fix attached.

FTR this fixes the zombie domain issue I'd been seeing, AFAICT.

Thanks!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:30:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAA9-000603-2Z; Fri, 20 Apr 2012 09:29:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLAA7-0005zs-1b
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:29:55 +0000
Received: from [193.109.254.147:64022] by server-10.bemta-14.messagelabs.com
	id F8/DC-05847-29C219F4; Fri, 20 Apr 2012 09:29:54 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334914191!5528372!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 427 invoked from network); 20 Apr 2012 09:29:52 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-27.messagelabs.com with SMTP;
	20 Apr 2012 09:29:52 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 83E47DBC74
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 17:29:36 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so8397342vcb.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 02:29:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.9 with SMTP id eu9mr3465275vdb.28.1334914171909; Fri,
	20 Apr 2012 02:29:31 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Fri, 20 Apr 2012 02:29:31 -0700 (PDT)
In-Reply-To: <1334308092.2538.2.camel@hp6530s>
References: <1334308092.2538.2.camel@hp6530s>
Date: Fri, 20 Apr 2012 17:29:31 +0800
Message-ID: <CAF1ivSY4djjygrVYanVAZAdvoPrB9jDqw8pE=wnOA61on65Tbg@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 5:08 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> libxl__domain_build_info_setdefault may be called several times,
> so rtc_timeoffset can't be setted in it.
>
> Move rtc_timeoffset setting logic to libxl__build_pre.
>
> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>

Hi IanJ,

Would you take this one?

Thanks,
Lin Ming

> ---
> =A0tools/libxl/libxl_create.c | =A0 =A09 ---------
> =A0tools/libxl/libxl_dom.c =A0 =A0| =A0 17 +++++++++++++++--
> =A02 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..e706124 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *g=
c,
> =A0 =A0 =A0 =A0 b_info->target_memkb =3D b_info->max_memkb;
>
> =A0 =A0 libxl_defbool_setdefault(&b_info->localtime, false);
> - =A0 =A0if (libxl_defbool_val(b_info->localtime)) {
> - =A0 =A0 =A0 =A0time_t t;
> - =A0 =A0 =A0 =A0struct tm *tm;
> -
> - =A0 =A0 =A0 =A0t =3D time(NULL);
> - =A0 =A0 =A0 =A0tm =3D localtime(&t);
> -
> - =A0 =A0 =A0 =A0b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
> - =A0 =A0}
>
> =A0 =A0 libxl_defbool_setdefault(&b_info->disable_migrate, false);
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..91c4bd8 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> =A0 =A0 libxl_ctx *ctx =3D libxl__gc_owner(gc);
> =A0 =A0 int tsc_mode;
> =A0 =A0 char *xs_domid, *con_domid;
> + =A0 =A0uint32_t rtc_timeoffset;
> +
> =A0 =A0 xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> =A0 =A0 libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cp=
umap);
> =A0 =A0 xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_M=
AXMEM_CONSTANT);
> @@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> =A0 =A0 if (libxl_defbool_val(info->disable_migrate))
> =A0 =A0 =A0 =A0 xc_domain_disable_migrate(ctx->xch, domid);
>
> - =A0 =A0if (info->rtc_timeoffset)
> - =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, info->rtc_tim=
eoffset);
> + =A0 =A0rtc_timeoffset =3D info->rtc_timeoffset;
> + =A0 =A0if (libxl_defbool_val(info->localtime)) {
> + =A0 =A0 =A0 =A0time_t t;
> + =A0 =A0 =A0 =A0struct tm *tm;
> +
> + =A0 =A0 =A0 =A0t =3D time(NULL);
> + =A0 =A0 =A0 =A0tm =3D localtime(&t);
> +
> + =A0 =A0 =A0 =A0rtc_timeoffset +=3D tm->tm_gmtoff;
> + =A0 =A0}
> +
> + =A0 =A0if (rtc_timeoffset)
> + =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffse=
t);
>
> =A0 =A0 if (info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
> =A0 =A0 =A0 =A0 unsigned long shadow;
> --
> 1.7.2.5
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:30:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAA9-000603-2Z; Fri, 20 Apr 2012 09:29:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLAA7-0005zs-1b
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:29:55 +0000
Received: from [193.109.254.147:64022] by server-10.bemta-14.messagelabs.com
	id F8/DC-05847-29C219F4; Fri, 20 Apr 2012 09:29:54 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334914191!5528372!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 427 invoked from network); 20 Apr 2012 09:29:52 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-3.tower-27.messagelabs.com with SMTP;
	20 Apr 2012 09:29:52 -0000
Received: from mail-vx0-f173.google.com (mail-vx0-f173.google.com
	[209.85.220.173]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 83E47DBC74
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 17:29:36 +0800 (CST)
Received: by vcbfl11 with SMTP id fl11so8397342vcb.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 02:29:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.9 with SMTP id eu9mr3465275vdb.28.1334914171909; Fri,
	20 Apr 2012 02:29:31 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Fri, 20 Apr 2012 02:29:31 -0700 (PDT)
In-Reply-To: <1334308092.2538.2.camel@hp6530s>
References: <1334308092.2538.2.camel@hp6530s>
Date: Fri, 20 Apr 2012 17:29:31 +0800
Message-ID: <CAF1ivSY4djjygrVYanVAZAdvoPrB9jDqw8pE=wnOA61on65Tbg@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 13, 2012 at 5:08 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> libxl__domain_build_info_setdefault may be called several times,
> so rtc_timeoffset can't be setted in it.
>
> Move rtc_timeoffset setting logic to libxl__build_pre.
>
> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>

Hi IanJ,

Would you take this one?

Thanks,
Lin Ming

> ---
> =A0tools/libxl/libxl_create.c | =A0 =A09 ---------
> =A0tools/libxl/libxl_dom.c =A0 =A0| =A0 17 +++++++++++++++--
> =A02 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..e706124 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -127,15 +127,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *g=
c,
> =A0 =A0 =A0 =A0 b_info->target_memkb =3D b_info->max_memkb;
>
> =A0 =A0 libxl_defbool_setdefault(&b_info->localtime, false);
> - =A0 =A0if (libxl_defbool_val(b_info->localtime)) {
> - =A0 =A0 =A0 =A0time_t t;
> - =A0 =A0 =A0 =A0struct tm *tm;
> -
> - =A0 =A0 =A0 =A0t =3D time(NULL);
> - =A0 =A0 =A0 =A0tm =3D localtime(&t);
> -
> - =A0 =A0 =A0 =A0b_info->rtc_timeoffset +=3D tm->tm_gmtoff;
> - =A0 =A0}
>
> =A0 =A0 libxl_defbool_setdefault(&b_info->disable_migrate, false);
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..91c4bd8 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -65,6 +65,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> =A0 =A0 libxl_ctx *ctx =3D libxl__gc_owner(gc);
> =A0 =A0 int tsc_mode;
> =A0 =A0 char *xs_domid, *con_domid;
> + =A0 =A0uint32_t rtc_timeoffset;
> +
> =A0 =A0 xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> =A0 =A0 libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cp=
umap);
> =A0 =A0 xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_M=
AXMEM_CONSTANT);
> @@ -91,8 +93,19 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> =A0 =A0 if (libxl_defbool_val(info->disable_migrate))
> =A0 =A0 =A0 =A0 xc_domain_disable_migrate(ctx->xch, domid);
>
> - =A0 =A0if (info->rtc_timeoffset)
> - =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, info->rtc_tim=
eoffset);
> + =A0 =A0rtc_timeoffset =3D info->rtc_timeoffset;
> + =A0 =A0if (libxl_defbool_val(info->localtime)) {
> + =A0 =A0 =A0 =A0time_t t;
> + =A0 =A0 =A0 =A0struct tm *tm;
> +
> + =A0 =A0 =A0 =A0t =3D time(NULL);
> + =A0 =A0 =A0 =A0tm =3D localtime(&t);
> +
> + =A0 =A0 =A0 =A0rtc_timeoffset +=3D tm->tm_gmtoff;
> + =A0 =A0}
> +
> + =A0 =A0if (rtc_timeoffset)
> + =A0 =A0 =A0 =A0xc_domain_set_time_offset(ctx->xch, domid, rtc_timeoffse=
t);
>
> =A0 =A0 if (info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
> =A0 =A0 =A0 =A0 unsigned long shadow;
> --
> 1.7.2.5
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAB9-00064l-HW; Fri, 20 Apr 2012 09:30:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLAB9-00064Y-5Y
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:30:59 +0000
Received: from [85.158.139.83:2230] by server-8.bemta-5.messagelabs.com id
	D4/05-26964-2DC219F4; Fri, 20 Apr 2012 09:30:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334914246!24699254!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28583 invoked from network); 20 Apr 2012 09:30:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Apr 2012 09:30:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLAAv-00037O-AB
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 02:30:45 -0700
Date: Fri, 20 Apr 2012 02:30:45 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334914245310-5653764.post@n5.nabble.com>
In-Reply-To: <1334669694083-5646585.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I also try with qemu-xen-traditional instead of qemu-xen but nothing same
error, someone can help me please?
For now I not found howto/wiki/readme about xl cd-insert/cd-eject and all
pratical test is failed.
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5653764.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAB9-00064l-HW; Fri, 20 Apr 2012 09:30:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLAB9-00064Y-5Y
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:30:59 +0000
Received: from [85.158.139.83:2230] by server-8.bemta-5.messagelabs.com id
	D4/05-26964-2DC219F4; Fri, 20 Apr 2012 09:30:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334914246!24699254!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28583 invoked from network); 20 Apr 2012 09:30:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Apr 2012 09:30:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLAAv-00037O-AB
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 02:30:45 -0700
Date: Fri, 20 Apr 2012 02:30:45 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334914245310-5653764.post@n5.nabble.com>
In-Reply-To: <1334669694083-5646585.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I also try with qemu-xen-traditional instead of qemu-xen but nothing same
error, someone can help me please?
For now I not found howto/wiki/readme about xl cd-insert/cd-eject and all
pratical test is failed.
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5653764.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAKb-0006gc-J1; Fri, 20 Apr 2012 09:40:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SLAKZ-0006g0-K3
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:40:43 +0000
Received: from [85.158.139.83:11155] by server-10.bemta-5.messagelabs.com id
	A1/50-08260-A1F219F4; Fri, 20 Apr 2012 09:40:42 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334914841!24734334!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20807 invoked from network); 20 Apr 2012 09:40:41 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:40:41 -0000
Received: by bkcji1 with SMTP id ji1so1261570bkc.32
	for <multiple recipients>; Fri, 20 Apr 2012 02:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=/cScVXuptoXHbnQzOKjCbFUCs3h9gNA7mUmf/MdYUS8=;
	b=zWFm6ZJ/foPh1GXnXZ4dxnLwFKUEHXK5ArNGxicuqAMnU5E6gzUoStk14RSq8+1264
	Os52MGeHgssFm/h1xIsmp5BogkP3kBjJXn8WzgvPysNc37ceeWR26apozN3Pw7WRAZiB
	i4qkCvtJe9BfdFCipIf+9hLhoey2xUu/yJwR/Gquh1A8yIxdw3R3KxffoVFW8JhWm2Yl
	2mWRiHUFv7yFModMgFblyl5Zw2qeECaGRXjPBioeFR20f6Wk+V9axup3D1lpyrf/RfwK
	jR4O4/0MZVRnXKylQFrXCxOF2xvxysHYey7wf102F8dpQoY2/Mno7FRLu0CSIHZZgPhC
	BqZQ==
Received: by 10.204.154.209 with SMTP id p17mr1739196bkw.6.1334914840956;
	Fri, 20 Apr 2012 02:40:40 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id im9sm4885668bkc.5.2012.04.20.02.40.38
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 02:40:39 -0700 (PDT)
Message-ID: <4F912F15.2030202@xen.org>
Date: Fri, 20 Apr 2012 10:40:37 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, 
	xen-users@lists.xen.org, xen-api@lists.xen.org
Subject: [Xen-devel] Xen Documentation Day : April 23rd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

we have another Xen Documentation Day come up next Monday, April 23.

More information
- http://wiki.xen.org/wiki/Xen_Document_Days
- http://wiki.xen.org/wiki/Xen_Document_Days/TODO

For a list of items that need work, check out the community maintained 
TODO and wishlist. Of course, you can work on anything you like: the 
list just provides suggestions.

How do I participate?
- Join us on IRC: freenode channel #xendocday
- Tell people what you intend to work on (to avoid doing something 
somebody else is already working on)
- Fix some documentation
- Help others
- And above all: have fun!

See you on IRC!

Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAKb-0006gc-J1; Fri, 20 Apr 2012 09:40:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SLAKZ-0006g0-K3
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 09:40:43 +0000
Received: from [85.158.139.83:11155] by server-10.bemta-5.messagelabs.com id
	A1/50-08260-A1F219F4; Fri, 20 Apr 2012 09:40:42 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1334914841!24734334!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20807 invoked from network); 20 Apr 2012 09:40:41 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:40:41 -0000
Received: by bkcji1 with SMTP id ji1so1261570bkc.32
	for <multiple recipients>; Fri, 20 Apr 2012 02:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=/cScVXuptoXHbnQzOKjCbFUCs3h9gNA7mUmf/MdYUS8=;
	b=zWFm6ZJ/foPh1GXnXZ4dxnLwFKUEHXK5ArNGxicuqAMnU5E6gzUoStk14RSq8+1264
	Os52MGeHgssFm/h1xIsmp5BogkP3kBjJXn8WzgvPysNc37ceeWR26apozN3Pw7WRAZiB
	i4qkCvtJe9BfdFCipIf+9hLhoey2xUu/yJwR/Gquh1A8yIxdw3R3KxffoVFW8JhWm2Yl
	2mWRiHUFv7yFModMgFblyl5Zw2qeECaGRXjPBioeFR20f6Wk+V9axup3D1lpyrf/RfwK
	jR4O4/0MZVRnXKylQFrXCxOF2xvxysHYey7wf102F8dpQoY2/Mno7FRLu0CSIHZZgPhC
	BqZQ==
Received: by 10.204.154.209 with SMTP id p17mr1739196bkw.6.1334914840956;
	Fri, 20 Apr 2012 02:40:40 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id im9sm4885668bkc.5.2012.04.20.02.40.38
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 02:40:39 -0700 (PDT)
Message-ID: <4F912F15.2030202@xen.org>
Date: Fri, 20 Apr 2012 10:40:37 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, 
	xen-users@lists.xen.org, xen-api@lists.xen.org
Subject: [Xen-devel] Xen Documentation Day : April 23rd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

we have another Xen Documentation Day come up next Monday, April 23.

More information
- http://wiki.xen.org/wiki/Xen_Document_Days
- http://wiki.xen.org/wiki/Xen_Document_Days/TODO

For a list of items that need work, check out the community maintained 
TODO and wishlist. Of course, you can work on anything you like: the 
list just provides suggestions.

How do I participate?
- Join us on IRC: freenode channel #xendocday
- Tell people what you intend to work on (to avoid doing something 
somebody else is already working on)
- Fix some documentation
- Help others
- And above all: have fun!

See you on IRC!

Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:58:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAbn-0007Ta-0Z; Fri, 20 Apr 2012 09:58:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SLAbk-0007TV-Pt
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:58:28 +0000
Received: from [85.158.143.35:62081] by server-2.bemta-4.messagelabs.com id
	D7/3C-17550-443319F4; Fri, 20 Apr 2012 09:58:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334915906!7976189!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15161 invoked from network); 20 Apr 2012 09:58:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:58:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330923600"; d="scan'208";a="24358205"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 05:58:26 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Apr 2012
	05:58:25 -0400
Message-ID: <4F913340.4000202@citrix.com>
Date: Fri, 20 Apr 2012 10:58:24 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Lin Ming <mlin@ss.pku.edu.cn>
References: <1334913957.2863.1.camel@hp6530s>
In-Reply-To: <1334913957.2863.1.camel@hp6530s>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/12 10:25, Lin Ming wrote:
> Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> information instead of fabricated one.
>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
>  arch/x86/xen/apic.c |   16 +++++++++++-----
>  1 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> index aee16ab..f1f392d 100644
> --- a/arch/x86/xen/apic.c
> +++ b/arch/x86/xen/apic.c
> @@ -1,14 +1,20 @@
>  #include <linux/init.h>
>  #include <asm/x86_init.h>
> +#include <asm/apic.h>
> +#include <xen/interface/physdev.h>
> +#include <asm/xen/hypercall.h>
>  
>  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>  {
> -	if (reg == 0x1)
> -		return 0x00170020;
> -	else if (reg == 0x0)
> -		return apic << 24;
> +	struct physdev_apic apic_op;
> +	int ret;
>  
> -	return 0xff;
> +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> +	apic_op.reg = reg;
> +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> +	if (ret)
> +		return ret;
> +	return apic_op.value;

Hypercall ret errors are negative, yet this function is unsigned.  Given
that the previous function had no possible way to fail, perhaps on error
you should fake up the values as before.

>  }
>  
>  void __init xen_init_apic(void)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 09:58:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 09:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLAbn-0007Ta-0Z; Fri, 20 Apr 2012 09:58:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SLAbk-0007TV-Pt
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 09:58:28 +0000
Received: from [85.158.143.35:62081] by server-2.bemta-4.messagelabs.com id
	D7/3C-17550-443319F4; Fri, 20 Apr 2012 09:58:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1334915906!7976189!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15161 invoked from network); 20 Apr 2012 09:58:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 09:58:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330923600"; d="scan'208";a="24358205"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 05:58:26 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Apr 2012
	05:58:25 -0400
Message-ID: <4F913340.4000202@citrix.com>
Date: Fri, 20 Apr 2012 10:58:24 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Lin Ming <mlin@ss.pku.edu.cn>
References: <1334913957.2863.1.camel@hp6530s>
In-Reply-To: <1334913957.2863.1.camel@hp6530s>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/12 10:25, Lin Ming wrote:
> Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> information instead of fabricated one.
>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> ---
>  arch/x86/xen/apic.c |   16 +++++++++++-----
>  1 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> index aee16ab..f1f392d 100644
> --- a/arch/x86/xen/apic.c
> +++ b/arch/x86/xen/apic.c
> @@ -1,14 +1,20 @@
>  #include <linux/init.h>
>  #include <asm/x86_init.h>
> +#include <asm/apic.h>
> +#include <xen/interface/physdev.h>
> +#include <asm/xen/hypercall.h>
>  
>  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>  {
> -	if (reg == 0x1)
> -		return 0x00170020;
> -	else if (reg == 0x0)
> -		return apic << 24;
> +	struct physdev_apic apic_op;
> +	int ret;
>  
> -	return 0xff;
> +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> +	apic_op.reg = reg;
> +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> +	if (ret)
> +		return ret;
> +	return apic_op.value;

Hypercall ret errors are negative, yet this function is unsigned.  Given
that the previous function had no possible way to fail, perhaps on error
you should fake up the values as before.

>  }
>  
>  void __init xen_init_apic(void)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:13:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLApm-0007sR-GO; Fri, 20 Apr 2012 10:12:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SLApl-0007sM-06
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:12:57 +0000
Received: from [85.158.138.51:30653] by server-11.bemta-3.messagelabs.com id
	36/1A-18894-8A6319F4; Fri, 20 Apr 2012 10:12:56 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334916775!22878344!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10174 invoked from network); 20 Apr 2012 10:12:55 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:12:55 -0000
Received: by eaaf11 with SMTP id f11so2555866eaa.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 03:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UZB8s1NZc8GuTRNrZeC+QPXLrEJp9FNdsn0c6/60krQ=;
	b=ehlt10GOBQmAqQjUslTwRw7FukJysu8PFZHrg+8RDWgPQOT5OIN1KCM+O+feoqc3KK
	gxIOyRbV/KQbj/KBScgVXfLmck/Npj1PyqwfPaUt/5LxzW1QjcBBMLh574/aBboQvEXq
	ehcD/uNfqx2j8aMsXZ0Uys0SStdRaI2MVJDlHNSTuN8fXNcD0mPeD71e2+HZf0XoaBw9
	SrbpvmmmjB5IRVwwu01cD6lO5NgK/X7cdLpl8hfGS/f9mircvqWbONu4c27B7rtS+6jJ
	1HGoaWNGU92DyxftQmVPZmiTsrG8Uzj6EnXsq6YMh5l6kxmACCXYIv7LUM8qf3kGEzlj
	PFiQ==
Received: by 10.14.48.4 with SMTP id u4mr906420eeb.63.1334916774781;
	Fri, 20 Apr 2012 03:12:54 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id m42sm24063247eef.0.2012.04.20.03.12.52
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 03:12:54 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 11:12:47 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <CBB6F52F.3E87B%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined)
	interrupts to be injected in to the guest
Thread-Index: Ac0e3iJCGYVPVPTt70yQgyMCiaf+zQ==
In-Reply-To: <4F914060020000780007EC9D@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Eddie Dong <eddie.dong@intel.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined)
 interrupts to be injected in to the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> I doubt this is generally correct, in particular for the use you appear
> to desire: When the injection is not the result of an INT nn
> instruction (which I would guess to be the case when coming from
> libxc), you shouldn't set a non-zero instruction length. I believe this
> is also wrong for the INT3 code above.
> 
> Additionally the problem should not be limited to injection coming
> from libxc - injection originating from x86_emulate() should be
> affected as much.
> 
> Jun, Eddie - I further wonder why #OF is not being handled according
> to the documentation here either (should also result in
> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from
> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it
> should be annotated with a comment saying why fall-through is
> intended here). Nor does the documentation state that TRAP_debug
> should ever result in X86_EVENTTYPE_SW_EXCEPTION.
> 
> Finally, the whole injection logic (including the patch here) doesn't
> appear to cope with INT nn being used by a guest with nn < 32, nor
> with any (pointless) prefixes used on INT3 or INT nn.

Agreed, I applied the patch because at least it doesn't mess with any
existing logic for vectors < 32, but really this function is now an
overloaded mess. vmx_inject_hw_exception() should deal *only* with hw
exceptions, and a more general function should be provided for the more
general callers. Or something. It needs a bit of thought and is certainly
not 4.2 material now.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:13:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLApm-0007sR-GO; Fri, 20 Apr 2012 10:12:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SLApl-0007sM-06
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:12:57 +0000
Received: from [85.158.138.51:30653] by server-11.bemta-3.messagelabs.com id
	36/1A-18894-8A6319F4; Fri, 20 Apr 2012 10:12:56 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334916775!22878344!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10174 invoked from network); 20 Apr 2012 10:12:55 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:12:55 -0000
Received: by eaaf11 with SMTP id f11so2555866eaa.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 03:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UZB8s1NZc8GuTRNrZeC+QPXLrEJp9FNdsn0c6/60krQ=;
	b=ehlt10GOBQmAqQjUslTwRw7FukJysu8PFZHrg+8RDWgPQOT5OIN1KCM+O+feoqc3KK
	gxIOyRbV/KQbj/KBScgVXfLmck/Npj1PyqwfPaUt/5LxzW1QjcBBMLh574/aBboQvEXq
	ehcD/uNfqx2j8aMsXZ0Uys0SStdRaI2MVJDlHNSTuN8fXNcD0mPeD71e2+HZf0XoaBw9
	SrbpvmmmjB5IRVwwu01cD6lO5NgK/X7cdLpl8hfGS/f9mircvqWbONu4c27B7rtS+6jJ
	1HGoaWNGU92DyxftQmVPZmiTsrG8Uzj6EnXsq6YMh5l6kxmACCXYIv7LUM8qf3kGEzlj
	PFiQ==
Received: by 10.14.48.4 with SMTP id u4mr906420eeb.63.1334916774781;
	Fri, 20 Apr 2012 03:12:54 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id m42sm24063247eef.0.2012.04.20.03.12.52
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 03:12:54 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 11:12:47 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <CBB6F52F.3E87B%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined)
	interrupts to be injected in to the guest
Thread-Index: Ac0e3iJCGYVPVPTt70yQgyMCiaf+zQ==
In-Reply-To: <4F914060020000780007EC9D@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Eddie Dong <eddie.dong@intel.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined)
 interrupts to be injected in to the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/2012 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> I doubt this is generally correct, in particular for the use you appear
> to desire: When the injection is not the result of an INT nn
> instruction (which I would guess to be the case when coming from
> libxc), you shouldn't set a non-zero instruction length. I believe this
> is also wrong for the INT3 code above.
> 
> Additionally the problem should not be limited to injection coming
> from libxc - injection originating from x86_emulate() should be
> affected as much.
> 
> Jun, Eddie - I further wonder why #OF is not being handled according
> to the documentation here either (should also result in
> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from
> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it
> should be annotated with a comment saying why fall-through is
> intended here). Nor does the documentation state that TRAP_debug
> should ever result in X86_EVENTTYPE_SW_EXCEPTION.
> 
> Finally, the whole injection logic (including the patch here) doesn't
> appear to cope with INT nn being used by a guest with nn < 32, nor
> with any (pointless) prefixes used on INT3 or INT nn.

Agreed, I applied the patch because at least it doesn't mess with any
existing logic for vectors < 32, but really this function is now an
overloaded mess. vmx_inject_hw_exception() should deal *only* with hw
exceptions, and a more general function should be provided for the more
general callers. Or something. It needs a bit of thought and is certainly
not 4.2 material now.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:27:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLB3Z-00008b-8h; Fri, 20 Apr 2012 10:27:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLB3X-00008G-JA
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 10:27:11 +0000
Received: from [193.109.254.147:57226] by server-12.bemta-14.messagelabs.com
	id 44/20-05898-EF9319F4; Fri, 20 Apr 2012 10:27:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334917617!5458440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30882 invoked from network); 20 Apr 2012 10:26:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:26:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12044789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:26:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:26:53 +0100
Message-ID: <1334917612.28331.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 20 Apr 2012 11:26:52 +0100
In-Reply-To: <1334669694083-5646585.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 14:34 +0100, Fantu wrote:
> Someone can explain use of these commands? I ran tests with a hvm domU but
> with errors
> 
> For example:
> xl -v cd-insert XP hdc raw:/mnt/vm/iso/test.iso
> libxl: error: libxl.c:1647:libxl_cdrom_insert: Virtual device not found

What is your guest configuration? You need to have created it with an
empty virtual CDROM device (specifically hdc in the case you outline
above).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:27:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLB3Z-00008b-8h; Fri, 20 Apr 2012 10:27:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLB3X-00008G-JA
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 10:27:11 +0000
Received: from [193.109.254.147:57226] by server-12.bemta-14.messagelabs.com
	id 44/20-05898-EF9319F4; Fri, 20 Apr 2012 10:27:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334917617!5458440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30882 invoked from network); 20 Apr 2012 10:26:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:26:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12044789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:26:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:26:53 +0100
Message-ID: <1334917612.28331.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 20 Apr 2012 11:26:52 +0100
In-Reply-To: <1334669694083-5646585.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-17 at 14:34 +0100, Fantu wrote:
> Someone can explain use of these commands? I ran tests with a hvm domU but
> with errors
> 
> For example:
> xl -v cd-insert XP hdc raw:/mnt/vm/iso/test.iso
> libxl: error: libxl.c:1647:libxl_cdrom_insert: Virtual device not found

What is your guest configuration? You need to have created it with an
empty virtual CDROM device (specifically hdc in the case you outline
above).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:38:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBEZ-0000iC-F6; Fri, 20 Apr 2012 10:38:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLBEY-0000i6-B2
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:38:34 +0000
Received: from [85.158.139.83:20464] by server-10.bemta-5.messagelabs.com id
	21/ED-08260-9AC319F4; Fri, 20 Apr 2012 10:38:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334918312!24634640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10980 invoked from network); 20 Apr 2012 10:38:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:38:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12045093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:38:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 11:38:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLBEW-00007k-Ew; Fri, 20 Apr 2012 10:38:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLBEW-0005EH-AO;
	Fri, 20 Apr 2012 11:38:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.15528.270106.567037@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 11:38:32 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334912603.28331.2.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> libxl/xend: name tap devices with a xentap prefix
...
> Also add "xentap-" prefix to the tap device when an explicit name is
> given to avoid a conflict with the vif device, which would otherwise
> have the same name.  Likewise correct the documentation for this
> option which suggested it applied to HVM tap devices only.

This sounds like a good idea but of course the names of interfaces
on Linux have a fairly short (16 character) iirc length limit.  Are we
sure that this isn't going to break some existing setup where the name
is already using most of the available length ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:38:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBEZ-0000iC-F6; Fri, 20 Apr 2012 10:38:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLBEY-0000i6-B2
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:38:34 +0000
Received: from [85.158.139.83:20464] by server-10.bemta-5.messagelabs.com id
	21/ED-08260-9AC319F4; Fri, 20 Apr 2012 10:38:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334918312!24634640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10980 invoked from network); 20 Apr 2012 10:38:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:38:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="12045093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:38:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 11:38:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLBEW-00007k-Ew; Fri, 20 Apr 2012 10:38:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLBEW-0005EH-AO;
	Fri, 20 Apr 2012 11:38:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.15528.270106.567037@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 11:38:32 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334912603.28331.2.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> libxl/xend: name tap devices with a xentap prefix
...
> Also add "xentap-" prefix to the tap device when an explicit name is
> given to avoid a conflict with the vif device, which would otherwise
> have the same name.  Likewise correct the documentation for this
> option which suggested it applied to HVM tap devices only.

This sounds like a good idea but of course the names of interfaces
on Linux have a fairly short (16 character) iirc length limit.  Are we
sure that this isn't going to break some existing setup where the name
is already using most of the available length ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:48:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBO4-00012y-Il; Fri, 20 Apr 2012 10:48:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLBO3-00012t-Er
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:48:23 +0000
Received: from [85.158.143.99:47398] by server-1.bemta-4.messagelabs.com id
	22/7C-20925-6FE319F4; Fri, 20 Apr 2012 10:48:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334918902!19261687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20257 invoked from network); 20 Apr 2012 10:48:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:48:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:48:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:48:22 +0100
Message-ID: <1334918900.28331.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 11:48:20 +0100
In-Reply-To: <20369.15528.270106.567037@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 11:38 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > libxl/xend: name tap devices with a xentap prefix
> ...
> > Also add "xentap-" prefix to the tap device when an explicit name is
> > given to avoid a conflict with the vif device, which would otherwise
> > have the same name.  Likewise correct the documentation for this
> > option which suggested it applied to HVM tap devices only.
> 
> This sounds like a good idea but of course the names of interfaces
> on Linux have a fairly short (16 character) iirc length limit.

Oh, right, I'd forgotten that.

>   Are we
> sure that this isn't going to break some existing setup where the name
> is already using most of the available length ?

On the contrary I'm fairly sure it will break them... How common they
would be I can't say (other than my gut feeling being "not very").

Not sure what our options are here. Perhaps in the grant Unix tradition
of dropping vowels and random consonants "xtp-". Or perhaps "emu-" (for
emulated)?

This still adds a new 4 char prefix in the xl case but xend already had
that behaviour so hopefully people haven't come to rely on it in the
meantime.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:48:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBO4-00012y-Il; Fri, 20 Apr 2012 10:48:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLBO3-00012t-Er
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:48:23 +0000
Received: from [85.158.143.99:47398] by server-1.bemta-4.messagelabs.com id
	22/7C-20925-6FE319F4; Fri, 20 Apr 2012 10:48:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334918902!19261687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20257 invoked from network); 20 Apr 2012 10:48:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:48:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:48:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:48:22 +0100
Message-ID: <1334918900.28331.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 11:48:20 +0100
In-Reply-To: <20369.15528.270106.567037@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 11:38 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > libxl/xend: name tap devices with a xentap prefix
> ...
> > Also add "xentap-" prefix to the tap device when an explicit name is
> > given to avoid a conflict with the vif device, which would otherwise
> > have the same name.  Likewise correct the documentation for this
> > option which suggested it applied to HVM tap devices only.
> 
> This sounds like a good idea but of course the names of interfaces
> on Linux have a fairly short (16 character) iirc length limit.

Oh, right, I'd forgotten that.

>   Are we
> sure that this isn't going to break some existing setup where the name
> is already using most of the available length ?

On the contrary I'm fairly sure it will break them... How common they
would be I can't say (other than my gut feeling being "not very").

Not sure what our options are here. Perhaps in the grant Unix tradition
of dropping vowels and random consonants "xtp-". Or perhaps "emu-" (for
emulated)?

This still adds a new 4 char prefix in the xl case but xend already had
that behaviour so hopefully people haven't come to rely on it in the
meantime.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:51:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:51:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBR3-00018f-8c; Fri, 20 Apr 2012 10:51:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1SLBR2-00018Y-0l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 10:51:28 +0000
Received: from [193.109.254.147:52151] by server-8.bemta-14.messagelabs.com id
	05/E0-23244-FAF319F4; Fri, 20 Apr 2012 10:51:27 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334919085!5516239!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDkyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8088 invoked from network); 20 Apr 2012 10:51:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 10:51:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KApKt1000331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 10:51:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KApJrK023011
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 10:51:20 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KApJI2022048; Fri, 20 Apr 2012 05:51:19 -0500
Received: from elgon.mountain (/41.139.221.94)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 03:51:18 -0700
Date: Fri, 20 Apr 2012 13:51:12 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: stefano.stabellini@eu.citrix.com
Message-ID: <20120420105112.GA21487@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F913FA9.012B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgU3RlZmFubywKCkkgaGFkIGEgcXVlc3Rpb24gYWJvdXQgOGYyODU0Yzc0ZmY0OiAieGVuL3Ay
bTogbTJwX2ZpbmRfb3ZlcnJpZGU6IHVzZQpsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUiLgoKSSB0
aGluayB0aGVyZSBpcyBhIG1pc3VuZGVyc3RhbmRpbmcgYWJvdXQgd2hhdCB0aGUKbGlzdF9mb3Jf
ZWFjaF9lbnRyeV9zYWZlKCkgbWFjcm8gZG9lcy4gIEl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGgK
bG9ja2luZywgc28gdGhlIHNwaW5sb2NrIGlzIHN0aWxsIG5lZWRlZC4gIFdpdGhvdXQgdGhlIGxv
Y2sgLT5uZXh0IGNvdWxkCnBvaW50IHRvIGFuIGVsZW1lbnQgd2hpY2ggaGFzIGJlZW4gZGVsZXRl
ZCBpbiBhbm90aGVyIHRocmVhZC4gIFByb2JhYmx5CnRoZSBwYXRjaCBzaG91bGQgYmUgcmV2ZXJ0
ZWQuCgpBbHNvLCBpdCBpbnRyb2R1Y2VzIGEgR0NDIHdhcm5pbmc6CmFyY2gveDg2L3hlbi9wMm0u
Yzo4MTE6MTY6IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJsZSDigJhmbGFnc+KAmQoJWy1XdW51c2Vk
LXZhcmlhYmxlXQoKcmVnYXJkcywKZGFuIGNhcnBlbnRlcgoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:51:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:51:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBR3-00018f-8c; Fri, 20 Apr 2012 10:51:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1SLBR2-00018Y-0l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 10:51:28 +0000
Received: from [193.109.254.147:52151] by server-8.bemta-14.messagelabs.com id
	05/E0-23244-FAF319F4; Fri, 20 Apr 2012 10:51:27 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334919085!5516239!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDkyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8088 invoked from network); 20 Apr 2012 10:51:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 10:51:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KApKt1000331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 10:51:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KApJrK023011
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 10:51:20 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KApJI2022048; Fri, 20 Apr 2012 05:51:19 -0500
Received: from elgon.mountain (/41.139.221.94)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 03:51:18 -0700
Date: Fri, 20 Apr 2012 13:51:12 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: stefano.stabellini@eu.citrix.com
Message-ID: <20120420105112.GA21487@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F913FA9.012B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgU3RlZmFubywKCkkgaGFkIGEgcXVlc3Rpb24gYWJvdXQgOGYyODU0Yzc0ZmY0OiAieGVuL3Ay
bTogbTJwX2ZpbmRfb3ZlcnJpZGU6IHVzZQpsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUiLgoKSSB0
aGluayB0aGVyZSBpcyBhIG1pc3VuZGVyc3RhbmRpbmcgYWJvdXQgd2hhdCB0aGUKbGlzdF9mb3Jf
ZWFjaF9lbnRyeV9zYWZlKCkgbWFjcm8gZG9lcy4gIEl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGgK
bG9ja2luZywgc28gdGhlIHNwaW5sb2NrIGlzIHN0aWxsIG5lZWRlZC4gIFdpdGhvdXQgdGhlIGxv
Y2sgLT5uZXh0IGNvdWxkCnBvaW50IHRvIGFuIGVsZW1lbnQgd2hpY2ggaGFzIGJlZW4gZGVsZXRl
ZCBpbiBhbm90aGVyIHRocmVhZC4gIFByb2JhYmx5CnRoZSBwYXRjaCBzaG91bGQgYmUgcmV2ZXJ0
ZWQuCgpBbHNvLCBpdCBpbnRyb2R1Y2VzIGEgR0NDIHdhcm5pbmc6CmFyY2gveDg2L3hlbi9wMm0u
Yzo4MTE6MTY6IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJsZSDigJhmbGFnc+KAmQoJWy1XdW51c2Vk
LXZhcmlhYmxlXQoKcmVnYXJkcywKZGFuIGNhcnBlbnRlcgoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:54:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBTK-0001Fz-Q3; Fri, 20 Apr 2012 10:53:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLBTJ-0001Fk-4H
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 10:53:49 +0000
Received: from [85.158.139.83:29382] by server-9.bemta-5.messagelabs.com id
	A9/06-09826-930419F4; Fri, 20 Apr 2012 10:53:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334919224!22003108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31274 invoked from network); 20 Apr 2012 10:53:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045604"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:53:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 11:53:43 +0100
Date: Fri, 20 Apr 2012 11:58:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120417144318.GA28477@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204201141300.26786@kaball-desktop>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
	<20120417144318.GA28477@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 17, 2012 at 03:26:05PM +0100, Stefano Stabellini wrote:
> > On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> > > > This patch is a significant performance improvement for the
> > > > m2p_override: about 6% using the gntdev device.
> > > > 
> > > > Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> > > > __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> > > > is a great performance benefit because it means issuing one hypercall
> > > > total rather than two hypercall per page.
> > > > If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> > > > going to be batched together, otherwise they are issued one at a time.
> > > > 
> > > > Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> > > > m2p_add/remove_override calls forces paravirt_lazy_mode to
> > > > PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> > > > 
> > > > 
> > > > Changes in v3:
> > > > - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> > > > can be called in interrupt context.
> > > 
> > > This is with RHEL5 (somehow the pvops kernels don't trigger this):
> > 
> > Do you mean RHEL5 as a guest? Are you using blkback or qdisk?
> 
> blkback:
> 
> memory = 1024
> name = "RHEL5-64"
> hvm_loader="/usr/bin/pygrub"
> vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
> vcpus=2
> vif = [ ' mac=00:0F:4B:00:00:74,bridge=switch' ]
> disk = [ 'phy:/dev/guests/RHEL5-64,xvda,w' ]
> boot = "dnc"
> device_model = 'qemu-dm'
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> usb=1
> usbdevice='tablet'
> xen_platform_pci=1


The reason why I haven't seen this before is that my patch conflicts
with 13e461d2ac176f6a5b4a4ee4ce69b8e870fd0ea6 "xen/blkback: use
grant-table.c hypercall wrappers": gnttab_unmap_refs is called by
xen_blkbk_unmap in interrupt context again.

I am attaching a new version of this patch, based on your testing branch
(after reverting the current version of the patch).

Considering that the only places where the m2p functions are called are
gnttab_(un)map_refs now, it makes it easier to do the right thing with
hypercall batching and check whether it is safe to call
arch_enter_lazy_mmu_mode, so we don't have to worry about who calls what
when.

---


[PATCH v4] xen: enter/exit lazy_mmu_mode around m2p_override calls

This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.

Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL.  Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
going to be batched together, otherwise they are issued one at a time.

Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
m2p_add/remove_override calls forces paravirt_lazy_mode to
PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.

However it is not safe to call arch_enter_lazy_mmu_mode if we are in
interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
check for both conditions before doing so.

Changes in v4:
- rebased on 3.4-rc3: all the m2p_override users call gnttab_unmap_refs
and gnttab_map_refs;
- check whether we are in interrupt context and the lazy_mode we are in
before calling arch_enter/leave_lazy_mmu_mode.

Changes in v3:
- do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
can be called in interrupt context.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index e570c6f..a18a3e8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -38,6 +38,7 @@
 #include <linux/vmalloc.h>
 #include <linux/uaccess.h>
 #include <linux/io.h>
+#include <linux/hardirq.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -826,7 +827,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 	pte_t *pte;
 	unsigned long mfn;
 
@@ -837,6 +838,11 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
 		if (map_ops[i].status)
@@ -855,6 +861,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
@@ -862,7 +871,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count, bool clear_pte)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
 	if (ret)
@@ -871,12 +880,20 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:54:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBTK-0001Fz-Q3; Fri, 20 Apr 2012 10:53:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLBTJ-0001Fk-4H
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 10:53:49 +0000
Received: from [85.158.139.83:29382] by server-9.bemta-5.messagelabs.com id
	A9/06-09826-930419F4; Fri, 20 Apr 2012 10:53:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334919224!22003108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31274 invoked from network); 20 Apr 2012 10:53:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045604"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:53:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 11:53:43 +0100
Date: Fri, 20 Apr 2012 11:58:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120417144318.GA28477@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204201141300.26786@kaball-desktop>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
	<20120417144318.GA28477@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 17, 2012 at 03:26:05PM +0100, Stefano Stabellini wrote:
> > On Tue, 17 Apr 2012, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Apr 10, 2012 at 05:29:34PM +0100, Stefano Stabellini wrote:
> > > > This patch is a significant performance improvement for the
> > > > m2p_override: about 6% using the gntdev device.
> > > > 
> > > > Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> > > > __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> > > > is a great performance benefit because it means issuing one hypercall
> > > > total rather than two hypercall per page.
> > > > If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> > > > going to be batched together, otherwise they are issued one at a time.
> > > > 
> > > > Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> > > > m2p_add/remove_override calls forces paravirt_lazy_mode to
> > > > PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> > > > 
> > > > 
> > > > Changes in v3:
> > > > - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> > > > can be called in interrupt context.
> > > 
> > > This is with RHEL5 (somehow the pvops kernels don't trigger this):
> > 
> > Do you mean RHEL5 as a guest? Are you using blkback or qdisk?
> 
> blkback:
> 
> memory = 1024
> name = "RHEL5-64"
> hvm_loader="/usr/bin/pygrub"
> vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
> vcpus=2
> vif = [ ' mac=00:0F:4B:00:00:74,bridge=switch' ]
> disk = [ 'phy:/dev/guests/RHEL5-64,xvda,w' ]
> boot = "dnc"
> device_model = 'qemu-dm'
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> usb=1
> usbdevice='tablet'
> xen_platform_pci=1


The reason why I haven't seen this before is that my patch conflicts
with 13e461d2ac176f6a5b4a4ee4ce69b8e870fd0ea6 "xen/blkback: use
grant-table.c hypercall wrappers": gnttab_unmap_refs is called by
xen_blkbk_unmap in interrupt context again.

I am attaching a new version of this patch, based on your testing branch
(after reverting the current version of the patch).

Considering that the only places where the m2p functions are called are
gnttab_(un)map_refs now, it makes it easier to do the right thing with
hypercall batching and check whether it is safe to call
arch_enter_lazy_mmu_mode, so we don't have to worry about who calls what
when.

---


[PATCH v4] xen: enter/exit lazy_mmu_mode around m2p_override calls

This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.

Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL.  Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
going to be batched together, otherwise they are issued one at a time.

Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
m2p_add/remove_override calls forces paravirt_lazy_mode to
PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.

However it is not safe to call arch_enter_lazy_mmu_mode if we are in
interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
check for both conditions before doing so.

Changes in v4:
- rebased on 3.4-rc3: all the m2p_override users call gnttab_unmap_refs
and gnttab_map_refs;
- check whether we are in interrupt context and the lazy_mode we are in
before calling arch_enter/leave_lazy_mmu_mode.

Changes in v3:
- do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
can be called in interrupt context.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index e570c6f..a18a3e8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -38,6 +38,7 @@
 #include <linux/vmalloc.h>
 #include <linux/uaccess.h>
 #include <linux/io.h>
+#include <linux/hardirq.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -826,7 +827,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 	pte_t *pte;
 	unsigned long mfn;
 
@@ -837,6 +838,11 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
 		if (map_ops[i].status)
@@ -855,6 +861,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
@@ -862,7 +871,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count, bool clear_pte)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
 	if (ret)
@@ -871,12 +880,20 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:55:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBVA-0001M0-Av; Fri, 20 Apr 2012 10:55:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLBV8-0001Lr-Va
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:55:43 +0000
Received: from [85.158.143.99:14905] by server-1.bemta-4.messagelabs.com id
	2A/19-20925-EA0419F4; Fri, 20 Apr 2012 10:55:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334919340!24493195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30447 invoked from network); 20 Apr 2012 10:55:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:55:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:55:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 11:55:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLBV5-0000DX-49; Fri, 20 Apr 2012 10:55:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLBV5-0005FU-1x;
	Fri, 20 Apr 2012 11:55:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.16555.46229.798603@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 11:55:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334918900.28331.47.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> On Fri, 2012-04-20 at 11:38 +0100, Ian Jackson wrote:
> >   Are we
> > sure that this isn't going to break some existing setup where the name
> > is already using most of the available length ?
> 
> On the contrary I'm fairly sure it will break them... How common they
> would be I can't say (other than my gut feeling being "not very").
> 
> Not sure what our options are here. Perhaps in the grant Unix tradition
> of dropping vowels and random consonants "xtp-". Or perhaps "emu-" (for
> emulated)?

I'm not quite up to speed with all the context here but is the reason
that you're not suggesting "xen-" is that that's already used for
something else ?

> This still adds a new 4 char prefix in the xl case but xend already had
> that behaviour so hopefully people haven't come to rely on it in the
> meantime.

I think that's a fair enough assumption.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 10:55:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 10:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBVA-0001M0-Av; Fri, 20 Apr 2012 10:55:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLBV8-0001Lr-Va
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 10:55:43 +0000
Received: from [85.158.143.99:14905] by server-1.bemta-4.messagelabs.com id
	2A/19-20925-EA0419F4; Fri, 20 Apr 2012 10:55:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334919340!24493195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30447 invoked from network); 20 Apr 2012 10:55:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 10:55:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 10:55:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 11:55:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLBV5-0000DX-49; Fri, 20 Apr 2012 10:55:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLBV5-0005FU-1x;
	Fri, 20 Apr 2012 11:55:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.16555.46229.798603@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 11:55:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334918900.28331.47.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> On Fri, 2012-04-20 at 11:38 +0100, Ian Jackson wrote:
> >   Are we
> > sure that this isn't going to break some existing setup where the name
> > is already using most of the available length ?
> 
> On the contrary I'm fairly sure it will break them... How common they
> would be I can't say (other than my gut feeling being "not very").
> 
> Not sure what our options are here. Perhaps in the grant Unix tradition
> of dropping vowels and random consonants "xtp-". Or perhaps "emu-" (for
> emulated)?

I'm not quite up to speed with all the context here but is the reason
that you're not suggesting "xen-" is that that's already used for
something else ?

> This still adds a new 4 char prefix in the xl case but xend already had
> that behaviour so hopefully people haven't come to rely on it in the
> meantime.

I think that's a fair enough assumption.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:01:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBab-0001cX-3o; Fri, 20 Apr 2012 11:01:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLBaZ-0001cQ-Po
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 11:01:19 +0000
Received: from [85.158.143.35:28855] by server-1.bemta-4.messagelabs.com id
	DE/92-20925-FF1419F4; Fri, 20 Apr 2012 11:01:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334919678!10871628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12574 invoked from network); 20 Apr 2012 11:01:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 11:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:00:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 12:00:15 +0100
Message-ID: <1334919613.28331.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 12:00:13 +0100
In-Reply-To: <20369.16555.46229.798603@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > On Fri, 2012-04-20 at 11:38 +0100, Ian Jackson wrote:
> > >   Are we
> > > sure that this isn't going to break some existing setup where the name
> > > is already using most of the available length ?
> > 
> > On the contrary I'm fairly sure it will break them... How common they
> > would be I can't say (other than my gut feeling being "not very").
> > 
> > Not sure what our options are here. Perhaps in the grant Unix tradition
> > of dropping vowels and random consonants "xtp-". Or perhaps "emu-" (for
> > emulated)?
> 
> I'm not quite up to speed with all the context here but is the reason
> that you're not suggesting "xen-" is that that's already used for
> something else ?

This is to distinguish the vif device from the associated tap device,
which would otherwise both be called whatever the user gave as "vifname"
in their config, so for vifname=foo you would get foo (the PV one) and
xen-foo (the EMU one) which does the job but doesn't really distinguish
them.

Ian.

> 
> > This still adds a new 4 char prefix in the xl case but xend already had
> > that behaviour so hopefully people haven't come to rely on it in the
> > meantime.
> 
> I think that's a fair enough assumption.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:01:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBab-0001cX-3o; Fri, 20 Apr 2012 11:01:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLBaZ-0001cQ-Po
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 11:01:19 +0000
Received: from [85.158.143.35:28855] by server-1.bemta-4.messagelabs.com id
	DE/92-20925-FF1419F4; Fri, 20 Apr 2012 11:01:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334919678!10871628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12574 invoked from network); 20 Apr 2012 11:01:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 11:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:00:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 12:00:15 +0100
Message-ID: <1334919613.28331.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 12:00:13 +0100
In-Reply-To: <20369.16555.46229.798603@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > On Fri, 2012-04-20 at 11:38 +0100, Ian Jackson wrote:
> > >   Are we
> > > sure that this isn't going to break some existing setup where the name
> > > is already using most of the available length ?
> > 
> > On the contrary I'm fairly sure it will break them... How common they
> > would be I can't say (other than my gut feeling being "not very").
> > 
> > Not sure what our options are here. Perhaps in the grant Unix tradition
> > of dropping vowels and random consonants "xtp-". Or perhaps "emu-" (for
> > emulated)?
> 
> I'm not quite up to speed with all the context here but is the reason
> that you're not suggesting "xen-" is that that's already used for
> something else ?

This is to distinguish the vif device from the associated tap device,
which would otherwise both be called whatever the user gave as "vifname"
in their config, so for vifname=foo you would get foo (the PV one) and
xen-foo (the EMU one) which does the job but doesn't really distinguish
them.

Ian.

> 
> > This still adds a new 4 char prefix in the xl case but xend already had
> > that behaviour so hopefully people haven't come to rely on it in the
> > meantime.
> 
> I think that's a fair enough assumption.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:04:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBdg-0001l0-Sd; Fri, 20 Apr 2012 11:04:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLBdf-0001kv-P1
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 11:04:31 +0000
Received: from [85.158.138.51:6007] by server-6.bemta-3.messagelabs.com id
	FD/60-05145-EB2419F4; Fri, 20 Apr 2012 11:04:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334919869!22987900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25148 invoked from network); 20 Apr 2012 11:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 11:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:04:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 12:04:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLBdd-0000Gc-Hl; Fri, 20 Apr 2012 11:04:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLBdd-0005GQ-Gi;
	Fri, 20 Apr 2012 12:04:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.17085.330843.561841@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 12:04:29 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334919613.28331.53.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> > I'm not quite up to speed with all the context here but is the reason
> > that you're not suggesting "xen-" is that that's already used for
> > something else ?
> 
> This is to distinguish the vif device from the associated tap device,
> which would otherwise both be called whatever the user gave as "vifname"
> in their config, so for vifname=foo you would get foo (the PV one) and
> xen-foo (the EMU one) which does the job but doesn't really distinguish
> them.

Ah, I see.  This sounds like more a job for a suffix than a prefix so
if we can spare 4 chars I would suggest foo-emu.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:04:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBdg-0001l0-Sd; Fri, 20 Apr 2012 11:04:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLBdf-0001kv-P1
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 11:04:31 +0000
Received: from [85.158.138.51:6007] by server-6.bemta-3.messagelabs.com id
	FD/60-05145-EB2419F4; Fri, 20 Apr 2012 11:04:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334919869!22987900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25148 invoked from network); 20 Apr 2012 11:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 11:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12045953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:04:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 12:04:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLBdd-0000Gc-Hl; Fri, 20 Apr 2012 11:04:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLBdd-0005GQ-Gi;
	Fri, 20 Apr 2012 12:04:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.17085.330843.561841@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 12:04:29 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334919613.28331.53.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> > I'm not quite up to speed with all the context here but is the reason
> > that you're not suggesting "xen-" is that that's already used for
> > something else ?
> 
> This is to distinguish the vif device from the associated tap device,
> which would otherwise both be called whatever the user gave as "vifname"
> in their config, so for vifname=foo you would get foo (the PV one) and
> xen-foo (the EMU one) which does the job but doesn't really distinguish
> them.

Ah, I see.  This sounds like more a job for a suffix than a prefix so
if we can spare 4 chars I would suggest foo-emu.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:14:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBnG-00027d-Vo; Fri, 20 Apr 2012 11:14:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLBnF-00027Y-Hj
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:14:25 +0000
Received: from [85.158.138.51:37435] by server-1.bemta-3.messagelabs.com id
	A6/A9-11491-015419F4; Fri, 20 Apr 2012 11:14:24 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334920463!14088295!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4971 invoked from network); 20 Apr 2012 11:14:23 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-7.tower-174.messagelabs.com with SMTP;
	20 Apr 2012 11:14:23 -0000
Received: from [192.168.1.200] (unknown [180.158.123.16])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id A6783DB970;
	Fri, 20 Apr 2012 19:14:09 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <4F913340.4000202@citrix.com>
References: <1334913957.2863.1.camel@hp6530s>  <4F913340.4000202@citrix.com>
Date: Fri, 20 Apr 2012 19:13:16 +0800
Message-ID: <1334920396.2863.16.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
> On 20/04/12 10:25, Lin Ming wrote:
> > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> > information instead of fabricated one.
> >
> > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> > ---
> >  arch/x86/xen/apic.c |   16 +++++++++++-----
> >  1 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> > index aee16ab..f1f392d 100644
> > --- a/arch/x86/xen/apic.c
> > +++ b/arch/x86/xen/apic.c
> > @@ -1,14 +1,20 @@
> >  #include <linux/init.h>
> >  #include <asm/x86_init.h>
> > +#include <asm/apic.h>
> > +#include <xen/interface/physdev.h>
> > +#include <asm/xen/hypercall.h>
> >  
> >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> >  {
> > -	if (reg == 0x1)
> > -		return 0x00170020;
> > -	else if (reg == 0x0)
> > -		return apic << 24;
> > +	struct physdev_apic apic_op;
> > +	int ret;
> >  
> > -	return 0xff;
> > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> > +	apic_op.reg = reg;
> > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> > +	if (ret)
> > +		return ret;
> > +	return apic_op.value;
> 
> Hypercall ret errors are negative, yet this function is unsigned.  Given
> that the previous function had no possible way to fail, perhaps on error
> you should fake up the values as before.

How about return -1 on error?
The calling function can check -1 for error. 

unsigned int ret = apic_read(...);
if (ret == -1)
	//handle error.

Thanks,
Lin Ming



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:14:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBnG-00027d-Vo; Fri, 20 Apr 2012 11:14:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLBnF-00027Y-Hj
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:14:25 +0000
Received: from [85.158.138.51:37435] by server-1.bemta-3.messagelabs.com id
	A6/A9-11491-015419F4; Fri, 20 Apr 2012 11:14:24 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334920463!14088295!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4971 invoked from network); 20 Apr 2012 11:14:23 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-7.tower-174.messagelabs.com with SMTP;
	20 Apr 2012 11:14:23 -0000
Received: from [192.168.1.200] (unknown [180.158.123.16])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id A6783DB970;
	Fri, 20 Apr 2012 19:14:09 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <4F913340.4000202@citrix.com>
References: <1334913957.2863.1.camel@hp6530s>  <4F913340.4000202@citrix.com>
Date: Fri, 20 Apr 2012 19:13:16 +0800
Message-ID: <1334920396.2863.16.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
> On 20/04/12 10:25, Lin Ming wrote:
> > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> > information instead of fabricated one.
> >
> > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> > ---
> >  arch/x86/xen/apic.c |   16 +++++++++++-----
> >  1 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> > index aee16ab..f1f392d 100644
> > --- a/arch/x86/xen/apic.c
> > +++ b/arch/x86/xen/apic.c
> > @@ -1,14 +1,20 @@
> >  #include <linux/init.h>
> >  #include <asm/x86_init.h>
> > +#include <asm/apic.h>
> > +#include <xen/interface/physdev.h>
> > +#include <asm/xen/hypercall.h>
> >  
> >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> >  {
> > -	if (reg == 0x1)
> > -		return 0x00170020;
> > -	else if (reg == 0x0)
> > -		return apic << 24;
> > +	struct physdev_apic apic_op;
> > +	int ret;
> >  
> > -	return 0xff;
> > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> > +	apic_op.reg = reg;
> > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> > +	if (ret)
> > +		return ret;
> > +	return apic_op.value;
> 
> Hypercall ret errors are negative, yet this function is unsigned.  Given
> that the previous function had no possible way to fail, perhaps on error
> you should fake up the values as before.

How about return -1 on error?
The calling function can check -1 for error. 

unsigned int ret = apic_read(...);
if (ret == -1)
	//handle error.

Thanks,
Lin Ming



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBp6-0002Bw-HG; Fri, 20 Apr 2012 11:16:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLBp4-0002Bk-KX
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:16:18 +0000
Received: from [85.158.138.51:54139] by server-5.bemta-3.messagelabs.com id
	E9/73-17113-E75419F4; Fri, 20 Apr 2012 11:16:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334920572!23062386!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23350 invoked from network); 20 Apr 2012 11:16:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Apr 2012 11:16:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLBox-0004di-Uj
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 04:16:11 -0700
Date: Fri, 20 Apr 2012 04:16:11 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334920571945-5653963.post@n5.nabble.com>
In-Reply-To: <1334917612.28331.34.camel@zakaz.uk.xensource.com>
References: <1334669694083-5646585.post@n5.nabble.com>
	<1334917612.28331.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply.
What I must write for emply virtual cdrom? I tried 'hdc,ro,cdrom' but return
parsing error.

I also tried cd-eject with this configuration:
---------------------------------------
name='XP'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc,ro,cdrom']
#disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
boot='cd'
xen_platform_pci=1
viridian=1
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
#spice=1
#spicehost="0.0.0.0"
#spiceport=6000
#spicedisable_ticketing=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
stdvga=0
#device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
#videoram=128
#device_model_args=["-vga qxl"]
---------------------------------------

And return this error:
xl cd-eject XP hdc
command line: config parsing error in disk specification: unknown value for
format: near `hdc:cdrom' in `,hdc:cdrom,r'

xl cd-eject is not full compatible with new disk configuration? (the cdrom
added on xl configuration file is working)

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5653963.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBp6-0002Bw-HG; Fri, 20 Apr 2012 11:16:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLBp4-0002Bk-KX
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:16:18 +0000
Received: from [85.158.138.51:54139] by server-5.bemta-3.messagelabs.com id
	E9/73-17113-E75419F4; Fri, 20 Apr 2012 11:16:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334920572!23062386!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23350 invoked from network); 20 Apr 2012 11:16:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Apr 2012 11:16:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SLBox-0004di-Uj
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 04:16:11 -0700
Date: Fri, 20 Apr 2012 04:16:11 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1334920571945-5653963.post@n5.nabble.com>
In-Reply-To: <1334917612.28331.34.camel@zakaz.uk.xensource.com>
References: <1334669694083-5646585.post@n5.nabble.com>
	<1334917612.28331.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply.
What I must write for emply virtual cdrom? I tried 'hdc,ro,cdrom' but return
parsing error.

I also tried cd-eject with this configuration:
---------------------------------------
name='XP'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc,ro,cdrom']
#disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
boot='cd'
xen_platform_pci=1
viridian=1
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
#spice=1
#spicehost="0.0.0.0"
#spiceport=6000
#spicedisable_ticketing=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
stdvga=0
#device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
#videoram=128
#device_model_args=["-vga qxl"]
---------------------------------------

And return this error:
xl cd-eject XP hdc
command line: config parsing error in disk specification: unknown value for
format: near `hdc:cdrom' in `,hdc:cdrom,r'

xl cd-eject is not full compatible with new disk configuration? (the cdrom
added on xl configuration file is working)

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5653963.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBqw-0002JS-2U; Fri, 20 Apr 2012 11:18:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLBqv-0002JD-7p
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:18:13 +0000
Received: from [85.158.143.99:65436] by server-2.bemta-4.messagelabs.com id
	ED/86-17550-4F5419F4; Fri, 20 Apr 2012 11:18:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334920691!14752028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21162 invoked from network); 20 Apr 2012 11:18:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 11:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12046253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:18:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 12:18:11 +0100
Date: Fri, 20 Apr 2012 12:23:21 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dan Carpenter <dan.carpenter@oracle.com>
In-Reply-To: <20120420105112.GA21487@elgon.mountain>
Message-ID: <alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
References: <20120420105112.GA21487@elgon.mountain>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-287627120-1334921017=:26786"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-287627120-1334921017=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Fri, 20 Apr 2012, Dan Carpenter wrote:
> Hi Stefano,
> 
> I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> list_for_each_entry_safe".
> 
> I think there is a misunderstanding about what the
> list_for_each_entry_safe() macro does.  It has nothing to do with
> locking, so the spinlock is still needed.  Without the lock ->next could
> point to an element which has been deleted in another thread.  Probably
> the patch should be reverted.

I thought that list_for_each_entry_safe is safe against deletion, is it
not?
It doesn't matter whether we get up to date entries or old entries
here as long as walking through the list doesn't break if a concurrent
thread adds or removes items.


> Also, it introduces a GCC warning:
> arch/x86/xen/p2m.c:811:16: warning: unused variable ‘flags’
> 	[-Wunused-variable]

I think that Konrad didn't submit the latest version of the patch (v3),
that has a better description and also removes the flags variable:
http://marc.info/?l=linux-kernel&m=133407526406072&w=2
--8323329-287627120-1334921017=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-287627120-1334921017=:26786--


From xen-devel-bounces@lists.xen.org Fri Apr 20 11:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLBqw-0002JS-2U; Fri, 20 Apr 2012 11:18:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLBqv-0002JD-7p
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:18:13 +0000
Received: from [85.158.143.99:65436] by server-2.bemta-4.messagelabs.com id
	ED/86-17550-4F5419F4; Fri, 20 Apr 2012 11:18:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334920691!14752028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21162 invoked from network); 20 Apr 2012 11:18:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 11:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12046253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:18:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 12:18:11 +0100
Date: Fri, 20 Apr 2012 12:23:21 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dan Carpenter <dan.carpenter@oracle.com>
In-Reply-To: <20120420105112.GA21487@elgon.mountain>
Message-ID: <alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
References: <20120420105112.GA21487@elgon.mountain>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-287627120-1334921017=:26786"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-287627120-1334921017=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Fri, 20 Apr 2012, Dan Carpenter wrote:
> Hi Stefano,
> 
> I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> list_for_each_entry_safe".
> 
> I think there is a misunderstanding about what the
> list_for_each_entry_safe() macro does.  It has nothing to do with
> locking, so the spinlock is still needed.  Without the lock ->next could
> point to an element which has been deleted in another thread.  Probably
> the patch should be reverted.

I thought that list_for_each_entry_safe is safe against deletion, is it
not?
It doesn't matter whether we get up to date entries or old entries
here as long as walking through the list doesn't break if a concurrent
thread adds or removes items.


> Also, it introduces a GCC warning:
> arch/x86/xen/p2m.c:811:16: warning: unused variable ‘flags’
> 	[-Wunused-variable]

I think that Konrad didn't submit the latest version of the patch (v3),
that has a better description and also removes the flags variable:
http://marc.info/?l=linux-kernel&m=133407526406072&w=2
--8323329-287627120-1334921017=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-287627120-1334921017=:26786--


From xen-devel-bounces@lists.xen.org Fri Apr 20 11:33:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLC5e-0002ZM-Kx; Fri, 20 Apr 2012 11:33:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1SLC5d-0002ZH-Bh
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:33:25 +0000
Received: from [193.109.254.147:20200] by server-2.bemta-14.messagelabs.com id
	B9/E6-19409-489419F4; Fri, 20 Apr 2012 11:33:24 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334921602!5524133!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21548 invoked from network); 20 Apr 2012 11:33:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 11:33:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KBXIXt031943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 11:33:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KBXHbY022480
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 11:33:17 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KBXGar028399; Fri, 20 Apr 2012 06:33:16 -0500
Received: from mwanda (/41.139.221.94) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 04:33:16 -0700
Date: Fri, 20 Apr 2012 14:35:57 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120420113557.GJ27101@mwanda>
References: <20120420105112.GA21487@elgon.mountain>
	<alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F91497F.0059,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 12:23:21PM +0100, Stefano Stabellini wrote:
> On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > Hi Stefano,
> > 
> > I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> > list_for_each_entry_safe".
> > 
> > I think there is a misunderstanding about what the
> > list_for_each_entry_safe() macro does.  It has nothing to do with
> > locking, so the spinlock is still needed.  Without the lock ->next could
> > point to an element which has been deleted in another thread.  Probably
> > the patch should be reverted.
> 
> I thought that list_for_each_entry_safe is safe against deletion, is it
> not?
> It doesn't matter whether we get up to date entries or old entries
> here as long as walking through the list doesn't break if a concurrent
> thread adds or removes items.
> 

It's safe against deletion in the same thread.  But not against
deletion from another thread.

At the beginning of the loop it stores a pointer to the next
element.  If you delete the element you are on, no problem because
you already have a pointer to the next one.  But if another thread
deletes the next element, now you have a pointer which is wrong.

regards,
dan carpenter


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 11:33:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 11:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLC5e-0002ZM-Kx; Fri, 20 Apr 2012 11:33:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1SLC5d-0002ZH-Bh
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 11:33:25 +0000
Received: from [193.109.254.147:20200] by server-2.bemta-14.messagelabs.com id
	B9/E6-19409-489419F4; Fri, 20 Apr 2012 11:33:24 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334921602!5524133!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21548 invoked from network); 20 Apr 2012 11:33:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 11:33:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KBXIXt031943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 11:33:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KBXHbY022480
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 11:33:17 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KBXGar028399; Fri, 20 Apr 2012 06:33:16 -0500
Received: from mwanda (/41.139.221.94) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 04:33:16 -0700
Date: Fri, 20 Apr 2012 14:35:57 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120420113557.GJ27101@mwanda>
References: <20120420105112.GA21487@elgon.mountain>
	<alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F91497F.0059,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 12:23:21PM +0100, Stefano Stabellini wrote:
> On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > Hi Stefano,
> > 
> > I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> > list_for_each_entry_safe".
> > 
> > I think there is a misunderstanding about what the
> > list_for_each_entry_safe() macro does.  It has nothing to do with
> > locking, so the spinlock is still needed.  Without the lock ->next could
> > point to an element which has been deleted in another thread.  Probably
> > the patch should be reverted.
> 
> I thought that list_for_each_entry_safe is safe against deletion, is it
> not?
> It doesn't matter whether we get up to date entries or old entries
> here as long as walking through the list doesn't break if a concurrent
> thread adds or removes items.
> 

It's safe against deletion in the same thread.  But not against
deletion from another thread.

At the beginning of the loop it stores a pointer to the next
element.  If you delete the element you are on, no problem because
you already have a pointer to the next one.  But if another thread
deletes the next element, now you have a pointer which is wrong.

regards,
dan carpenter


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLD58-0003Kq-Ms; Fri, 20 Apr 2012 12:36:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLD57-0003Kk-0l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:36:57 +0000
Received: from [85.158.143.35:62092] by server-2.bemta-4.messagelabs.com id
	4B/F3-17550-868519F4; Fri, 20 Apr 2012 12:36:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334925415!13323450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18532 invoked from network); 20 Apr 2012 12:36:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12047868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 12:36:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 13:36:36 +0100
Message-ID: <1334925395.28331.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Date: Fri, 20 Apr 2012 13:36:35 +0100
In-Reply-To: <2f68aefc46c35ef5c0c3.1334874293@vollum>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagar-Cavilla <andres@lagarcavilla.org>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
> When mapping in large amounts of pages (in the GB range) from a guest
> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc
> client application. This is because the pfn array in
> linux_privcmd_map_foreign_bulk() is being allocated using alloca() and
> the subsequent memcpy causes the stack to blow. This patch replaces
> the alloca() with mmap().

The original reason for switching to alloca from malloc was because the
similar gntmap path was a hot path and it seemed like if it was
reasonable there it would be reasonable here too.

So I have a couple of questions...

Is it possible that we also introduced this same issue at the other
callsites which were changed in that patch or are there other
constraints on the size of the allocation which make it not a problem?

Where does this mmap approach fall in terms of performance relative to
just switching back to malloc? I presume that alloca is faster than
both, but if it doesn't work reliably then it's not an option.

If mmap and malloc have roughly equivalent performance properties, or
the fast one is still too slow for Santosh's use case, then maybe we
need to have a think about other options.

e.g. use alloca for small numbers of mappings and mmap/malloc for larger
ones. Or do large numbers of mappings in multiple batches.

Ian.

> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
> @@ -39,6 +39,7 @@
>  #include "xenctrl.h"
>  #include "xenctrlosdep.h"
>  
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
>  #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>  #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
>          privcmd_mmapbatch_t ioctlx;
> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT),
> +                              PROT_READ | PROT_WRITE,
> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +        if ( pfn == MAP_FAILED )
> +        {
> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> +            return NULL;
> +        }
>  
>          memcpy(pfn, arr, num * sizeof(*arr));
>  
> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
>              break;
>          }
>  
> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
> +
>          if ( rc == -ENOENT && i == num )
>              rc = 0;
>          else if ( rc )
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLD58-0003Kq-Ms; Fri, 20 Apr 2012 12:36:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLD57-0003Kk-0l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:36:57 +0000
Received: from [85.158.143.35:62092] by server-2.bemta-4.messagelabs.com id
	4B/F3-17550-868519F4; Fri, 20 Apr 2012 12:36:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334925415!13323450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18532 invoked from network); 20 Apr 2012 12:36:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208";a="12047868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 12:36:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 13:36:36 +0100
Message-ID: <1334925395.28331.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Date: Fri, 20 Apr 2012 13:36:35 +0100
In-Reply-To: <2f68aefc46c35ef5c0c3.1334874293@vollum>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagar-Cavilla <andres@lagarcavilla.org>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
> When mapping in large amounts of pages (in the GB range) from a guest
> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc
> client application. This is because the pfn array in
> linux_privcmd_map_foreign_bulk() is being allocated using alloca() and
> the subsequent memcpy causes the stack to blow. This patch replaces
> the alloca() with mmap().

The original reason for switching to alloca from malloc was because the
similar gntmap path was a hot path and it seemed like if it was
reasonable there it would be reasonable here too.

So I have a couple of questions...

Is it possible that we also introduced this same issue at the other
callsites which were changed in that patch or are there other
constraints on the size of the allocation which make it not a problem?

Where does this mmap approach fall in terms of performance relative to
just switching back to malloc? I presume that alloca is faster than
both, but if it doesn't work reliably then it's not an option.

If mmap and malloc have roughly equivalent performance properties, or
the fast one is still too slow for Santosh's use case, then maybe we
need to have a think about other options.

e.g. use alloca for small numbers of mappings and mmap/malloc for larger
ones. Or do large numbers of mappings in multiple batches.

Ian.

> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
> @@ -39,6 +39,7 @@
>  #include "xenctrl.h"
>  #include "xenctrlosdep.h"
>  
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
>  #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>  #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
>          privcmd_mmapbatch_t ioctlx;
> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT),
> +                              PROT_READ | PROT_WRITE,
> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +        if ( pfn == MAP_FAILED )
> +        {
> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> +            return NULL;
> +        }
>  
>          memcpy(pfn, arr, num * sizeof(*arr));
>  
> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
>              break;
>          }
>  
> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
> +
>          if ( rc == -ENOENT && i == num )
>              rc = 0;
>          else if ( rc )
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:39:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:39:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLD6f-0003OP-6Q; Fri, 20 Apr 2012 12:38:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLD6d-0003OI-Nu
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:38:31 +0000
Received: from [85.158.143.35:9223] by server-1.bemta-4.messagelabs.com id
	D1/DF-20925-7C8519F4; Fri, 20 Apr 2012 12:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334925510!13323733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25605 invoked from network); 20 Apr 2012 12:38:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12047897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 12:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 13:38:29 +0100
Message-ID: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Fri, 20 Apr 2012 13:38:28 +0100
In-Reply-To: <1334920396.2863.16.camel@hp6530s>
References: <1334913957.2863.1.camel@hp6530s>  <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
> On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
> > On 20/04/12 10:25, Lin Ming wrote:
> > > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> > > information instead of fabricated one.
> > >
> > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> > > ---
> > >  arch/x86/xen/apic.c |   16 +++++++++++-----
> > >  1 files changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> > > index aee16ab..f1f392d 100644
> > > --- a/arch/x86/xen/apic.c
> > > +++ b/arch/x86/xen/apic.c
> > > @@ -1,14 +1,20 @@
> > >  #include <linux/init.h>
> > >  #include <asm/x86_init.h>
> > > +#include <asm/apic.h>
> > > +#include <xen/interface/physdev.h>
> > > +#include <asm/xen/hypercall.h>
> > >  
> > >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> > >  {
> > > -	if (reg == 0x1)
> > > -		return 0x00170020;
> > > -	else if (reg == 0x0)
> > > -		return apic << 24;
> > > +	struct physdev_apic apic_op;
> > > +	int ret;
> > >  
> > > -	return 0xff;
> > > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> > > +	apic_op.reg = reg;
> > > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> > > +	if (ret)
> > > +		return ret;
> > > +	return apic_op.value;
> > 
> > Hypercall ret errors are negative, yet this function is unsigned.  Given
> > that the previous function had no possible way to fail, perhaps on error
> > you should fake up the values as before.
> 
> How about return -1 on error?
> The calling function can check -1 for error. 

Isn't -1 potentially (at least theoretically) a valid value to read from
one of these registers?

Under what circumstances can these hypercalls fail? Would a BUG_ON be
appropriate/

> unsigned int ret = apic_read(...);
> if (ret == -1)
> 	//handle error.
> 
> Thanks,
> Lin Ming
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:39:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:39:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLD6f-0003OP-6Q; Fri, 20 Apr 2012 12:38:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLD6d-0003OI-Nu
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:38:31 +0000
Received: from [85.158.143.35:9223] by server-1.bemta-4.messagelabs.com id
	D1/DF-20925-7C8519F4; Fri, 20 Apr 2012 12:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1334925510!13323733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25605 invoked from network); 20 Apr 2012 12:38:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12047897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 12:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 13:38:29 +0100
Message-ID: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Fri, 20 Apr 2012 13:38:28 +0100
In-Reply-To: <1334920396.2863.16.camel@hp6530s>
References: <1334913957.2863.1.camel@hp6530s>  <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
> On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
> > On 20/04/12 10:25, Lin Ming wrote:
> > > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> > > information instead of fabricated one.
> > >
> > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> > > ---
> > >  arch/x86/xen/apic.c |   16 +++++++++++-----
> > >  1 files changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> > > index aee16ab..f1f392d 100644
> > > --- a/arch/x86/xen/apic.c
> > > +++ b/arch/x86/xen/apic.c
> > > @@ -1,14 +1,20 @@
> > >  #include <linux/init.h>
> > >  #include <asm/x86_init.h>
> > > +#include <asm/apic.h>
> > > +#include <xen/interface/physdev.h>
> > > +#include <asm/xen/hypercall.h>
> > >  
> > >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> > >  {
> > > -	if (reg == 0x1)
> > > -		return 0x00170020;
> > > -	else if (reg == 0x0)
> > > -		return apic << 24;
> > > +	struct physdev_apic apic_op;
> > > +	int ret;
> > >  
> > > -	return 0xff;
> > > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> > > +	apic_op.reg = reg;
> > > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> > > +	if (ret)
> > > +		return ret;
> > > +	return apic_op.value;
> > 
> > Hypercall ret errors are negative, yet this function is unsigned.  Given
> > that the previous function had no possible way to fail, perhaps on error
> > you should fake up the values as before.
> 
> How about return -1 on error?
> The calling function can check -1 for error. 

Isn't -1 potentially (at least theoretically) a valid value to read from
one of these registers?

Under what circumstances can these hypercalls fail? Would a BUG_ON be
appropriate/

> unsigned int ret = apic_read(...);
> if (ret == -1)
> 	//handle error.
> 
> Thanks,
> Lin Ming
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDFM-0003n0-7K; Fri, 20 Apr 2012 12:47:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDFL-0003mv-GR
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 12:47:31 +0000
Received: from [85.158.138.51:58413] by server-7.bemta-3.messagelabs.com id
	7D/34-03078-2EA519F4; Fri, 20 Apr 2012 12:47:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334926049!23034682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11800 invoked from network); 20 Apr 2012 12:47:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:47:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 12:47:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 13:47:28 +0100
Message-ID: <1334926047.28331.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 20 Apr 2012 13:47:27 +0100
In-Reply-To: <52453437-855A-4024-B30D-7D5819E9927F@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
	<1334763014.23948.261.camel@zakaz.uk.xensource.com>
	<52453437-855A-4024-B30D-7D5819E9927F@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTE4IGF0IDE2OjQwICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gT24gMTggQXByIDIwMTIsIGF0IDE2OjMwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gCj4gPiBP
biBXZWQsIDIwMTItMDQtMTggYXQgMTQ6NDggKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToK
PiA+PiBPbiAxOCBBcHIgMjAxMiwgYXQgMTQ6MzEsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+Pgo+
ID4+Pj4gT2ssIEkgd2lsbCBhZGQgYW5kIGV4dHJhIHBhcmFtZXRlciB0byBsaWJ4bF9faW5pdGlh
dGVfZGV2aWNlX3JlbW92ZQo+ID4+Pj4gdGhhdAo+ID4+Pj4gdHVybnMgb24gb3Igb2ZmIHRoZSBk
ZXN0cnVjdGlvbiBvZiB0aGUgZnJvbnQgeGVuc3RvcmUgZW50cmllcy4gV2UKPiA+Pj4+IHdpbGwK
PiA+Pj4+IGZpcnN0IGNhbGwgaXQgd2l0aG91dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlm
IHRoYXQgZmFpbHMgd2UgCj4gPj4+PiB3aWxsCj4gPj4+PiBjYWxsIGxpYnhsX19pbml0aWF0ZV9k
ZXZpY2VfcmVtb3ZlIGZyb20gdGhlIGNhbGxiYWNrIHRoaXMgdGltZQo+ID4+Pj4gZm9yY2luZwo+
ID4+Pj4gdGhlIHJlbW92YWwgb2YgdGhlIGZyb250ZW5kLgo+ID4+Pgo+ID4+PiBJZiBsaWJ4bF9f
aW5pdGlhdGVfZGV2aWNlX3JlbW92ZSBmYWlscyB0aGVuIHlvdSBzaG91bGQgYmUgY2FsbGluZwo+
ID4+PiBsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX2Rlc3Ryb3ksIEkgdGhpbmssIHNvIG5vIG5lZWQg
Zm9yIGEgcGFyYW0gdG8KPiA+Pj4gX3JlbW92ZT8KPiA+Pgo+ID4+IE5vdCByZWFsbHnigKYgVGhh
dCdzIGhvdyBJIHRoaW5rIHRoZSByZW1vdmFsIHBhdGggc2hvdWxkIGJlOgo+ID4+Cj4gPj4gMS0g
V2FpdCBmb3IgYmFja2VuZCB0byB0dXJuIHRvIHN0YXRlIDYgLS0tLS0+IGlmIG9rIHRoZW4gZXhl
Y3V0ZQo+ID4+IGhvdHBsdWcsIGFuZCByZW1vdmUgZnJvbnQvYmFja2VuZAo+ID4+IDItIElmIHRp
bWVvdXQ6IG51a2UgZnJvbnRlbmQgYW5kIHdhaXQgZm9yIGJhY2tlbmQgc3RhdGUgNiAtLS0tLT4g
aWYgCj4gPj4gb2sKPiA+PiB0aGVuIGV4ZWN1dGUgaG90cGx1ZyBhbmQgcmVtb3ZlIGZyb250L2Jh
Y2sKPiA+PiAzLSBJZiB0aW1lb3V0OiBudWtlIGZyb250L2JhY2tlbmQKPiA+Cj4gPiBUaGF0IGNv
dWxkIHdvcmssIGJ1dCB3aGF0IGRvZXMgZG9pbmcgc3RlcCAyIGJ1eSB5b3U/IFdoeSBub3Qgc2tp
cAo+ID4gc3RyYWlnaHQgdG8gc3RlcCAzPwo+IAo+IGhvdHBsdWcgc2NyaXB0cyB1c3VhbGx5IHJl
cXVpcmUgdGhlIGRldmljZSB0byBiZSBvbiBzdGF0ZSA2IGZvciB0aGVtIHRvIAo+IHdvcmssIG51
a2luZyB0aGUgZnJvbnRlbmQgZm9yY2VzIHRoZSBiYWNrZW5kIGRpc2Nvbm5lY3Rpb24sIGFuZCBn
ZXRzIHVzIAo+IGEgc3RhdGUgNi4KCk9LLCB0aGF0IG1ha2VzIHNlbnNlLiBZb3UnZCBuZWVkIHRv
IGhhdmUgdHdvIGxldmVscyBvZiB0aW1lb3V0L2NhbGxiYWNrcwp0aG91Z2g/CgpJYW4uCgoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDFM-0003n0-7K; Fri, 20 Apr 2012 12:47:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDFL-0003mv-GR
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 12:47:31 +0000
Received: from [85.158.138.51:58413] by server-7.bemta-3.messagelabs.com id
	7D/34-03078-2EA519F4; Fri, 20 Apr 2012 12:47:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334926049!23034682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11800 invoked from network); 20 Apr 2012 12:47:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:47:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 12:47:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 13:47:28 +0100
Message-ID: <1334926047.28331.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 20 Apr 2012 13:47:27 +0100
In-Reply-To: <52453437-855A-4024-B30D-7D5819E9927F@citrix.com>
References: <1334677876-17704-1-git-send-email-roger.pau@citrix.com>
	<1334677876-17704-5-git-send-email-roger.pau@citrix.com>
	<1334742899.23948.180.camel@zakaz.uk.xensource.com>
	<B2A7EC75-BB61-4C26-88F0-E8C6B0EBA161@citrix.com>
	<1334752277.23948.233.camel@zakaz.uk.xensource.com>
	<2E99DF0A-25A4-4D34-8B66-22E42E75149B@citrix.com>
	<1334755904.23948.239.camel@zakaz.uk.xensource.com>
	<498AA913-FAC6-4819-A7F5-41212C606509@citrix.com>
	<1334763014.23948.261.camel@zakaz.uk.xensource.com>
	<52453437-855A-4024-B30D-7D5819E9927F@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTE4IGF0IDE2OjQwICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gT24gMTggQXByIDIwMTIsIGF0IDE2OjMwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gCj4gPiBP
biBXZWQsIDIwMTItMDQtMTggYXQgMTQ6NDggKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToK
PiA+PiBPbiAxOCBBcHIgMjAxMiwgYXQgMTQ6MzEsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+Pgo+
ID4+Pj4gT2ssIEkgd2lsbCBhZGQgYW5kIGV4dHJhIHBhcmFtZXRlciB0byBsaWJ4bF9faW5pdGlh
dGVfZGV2aWNlX3JlbW92ZQo+ID4+Pj4gdGhhdAo+ID4+Pj4gdHVybnMgb24gb3Igb2ZmIHRoZSBk
ZXN0cnVjdGlvbiBvZiB0aGUgZnJvbnQgeGVuc3RvcmUgZW50cmllcy4gV2UKPiA+Pj4+IHdpbGwK
PiA+Pj4+IGZpcnN0IGNhbGwgaXQgd2l0aG91dCByZW1vdmluZyB0aGUgZnJvbnRlZCwgYW5kIGlm
IHRoYXQgZmFpbHMgd2UgCj4gPj4+PiB3aWxsCj4gPj4+PiBjYWxsIGxpYnhsX19pbml0aWF0ZV9k
ZXZpY2VfcmVtb3ZlIGZyb20gdGhlIGNhbGxiYWNrIHRoaXMgdGltZQo+ID4+Pj4gZm9yY2luZwo+
ID4+Pj4gdGhlIHJlbW92YWwgb2YgdGhlIGZyb250ZW5kLgo+ID4+Pgo+ID4+PiBJZiBsaWJ4bF9f
aW5pdGlhdGVfZGV2aWNlX3JlbW92ZSBmYWlscyB0aGVuIHlvdSBzaG91bGQgYmUgY2FsbGluZwo+
ID4+PiBsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX2Rlc3Ryb3ksIEkgdGhpbmssIHNvIG5vIG5lZWQg
Zm9yIGEgcGFyYW0gdG8KPiA+Pj4gX3JlbW92ZT8KPiA+Pgo+ID4+IE5vdCByZWFsbHnigKYgVGhh
dCdzIGhvdyBJIHRoaW5rIHRoZSByZW1vdmFsIHBhdGggc2hvdWxkIGJlOgo+ID4+Cj4gPj4gMS0g
V2FpdCBmb3IgYmFja2VuZCB0byB0dXJuIHRvIHN0YXRlIDYgLS0tLS0+IGlmIG9rIHRoZW4gZXhl
Y3V0ZQo+ID4+IGhvdHBsdWcsIGFuZCByZW1vdmUgZnJvbnQvYmFja2VuZAo+ID4+IDItIElmIHRp
bWVvdXQ6IG51a2UgZnJvbnRlbmQgYW5kIHdhaXQgZm9yIGJhY2tlbmQgc3RhdGUgNiAtLS0tLT4g
aWYgCj4gPj4gb2sKPiA+PiB0aGVuIGV4ZWN1dGUgaG90cGx1ZyBhbmQgcmVtb3ZlIGZyb250L2Jh
Y2sKPiA+PiAzLSBJZiB0aW1lb3V0OiBudWtlIGZyb250L2JhY2tlbmQKPiA+Cj4gPiBUaGF0IGNv
dWxkIHdvcmssIGJ1dCB3aGF0IGRvZXMgZG9pbmcgc3RlcCAyIGJ1eSB5b3U/IFdoeSBub3Qgc2tp
cAo+ID4gc3RyYWlnaHQgdG8gc3RlcCAzPwo+IAo+IGhvdHBsdWcgc2NyaXB0cyB1c3VhbGx5IHJl
cXVpcmUgdGhlIGRldmljZSB0byBiZSBvbiBzdGF0ZSA2IGZvciB0aGVtIHRvIAo+IHdvcmssIG51
a2luZyB0aGUgZnJvbnRlbmQgZm9yY2VzIHRoZSBiYWNrZW5kIGRpc2Nvbm5lY3Rpb24sIGFuZCBn
ZXRzIHVzIAo+IGEgc3RhdGUgNi4KCk9LLCB0aGF0IG1ha2VzIHNlbnNlLiBZb3UnZCBuZWVkIHRv
IGhhdmUgdHdvIGxldmVscyBvZiB0aW1lb3V0L2NhbGxiYWNrcwp0aG91Z2g/CgpJYW4uCgoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:49:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDHA-0003r3-NI; Fri, 20 Apr 2012 12:49:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLDH9-0003qx-9D
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:49:23 +0000
Received: from [193.109.254.147:53572] by server-10.bemta-14.messagelabs.com
	id 41/DA-05847-25B519F4; Fri, 20 Apr 2012 12:49:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334926160!5538795!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzgzMzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24969 invoked from network); 20 Apr 2012 12:49:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:49:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24362296"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 08:49:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 08:49:20 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SLDH0-0001JI-CA; Fri, 20 Apr 2012 13:49:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Apr 2012 13:54:40 +0100
Message-ID: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/1] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

qemu-xen offers better disk performances than qemu-xen-traditional
because it supports Linux native AIO: use it for PV guests if it is
available.

Changes in v2:
- check for the existence of the qemu-xen binary before setting qemu-xen
as the default device model for PV guests.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   29 ++++++++++++++++++++++++-----
 1 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..b71524e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -71,9 +71,30 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->type != LIBXL_DOMAIN_TYPE_PV)
         return ERROR_INVAL;
 
-    if (!b_info->device_model_version)
-        b_info->device_model_version =
-            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (!b_info->device_model_version) {
+        if (b_info->type == LIBXL_DOMAIN_TYPE_HVM)
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+        else {
+            const char *dm;
+            struct stat buf;
+            int rc;
+
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+            dm = libxl__domain_device_model(gc, b_info);
+            rc = stat(dm, &buf);
+            /* qemu-xen unavailable, use qemu-xen-traditional */
+            if (rc != 0) {
+                LIBXL__LOG(CTX, XTL_VERBOSE, "setting device model to "
+                        "qemu-xen-traditional because qemu-xen is unavailable");
+                b_info->device_model_version =
+                    LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+            }
+        }
+    }
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
@@ -99,8 +120,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
-    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
-
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
         b_info->device_model_version !=
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:49:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDHA-0003r3-NI; Fri, 20 Apr 2012 12:49:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLDH9-0003qx-9D
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:49:23 +0000
Received: from [193.109.254.147:53572] by server-10.bemta-14.messagelabs.com
	id 41/DA-05847-25B519F4; Fri, 20 Apr 2012 12:49:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1334926160!5538795!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzgzMzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24969 invoked from network); 20 Apr 2012 12:49:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:49:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24362296"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 08:49:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 08:49:20 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SLDH0-0001JI-CA; Fri, 20 Apr 2012 13:49:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Apr 2012 13:54:40 +0100
Message-ID: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/1] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

qemu-xen offers better disk performances than qemu-xen-traditional
because it supports Linux native AIO: use it for PV guests if it is
available.

Changes in v2:
- check for the existence of the qemu-xen binary before setting qemu-xen
as the default device model for PV guests.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   29 ++++++++++++++++++++++++-----
 1 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..b71524e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -71,9 +71,30 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->type != LIBXL_DOMAIN_TYPE_PV)
         return ERROR_INVAL;
 
-    if (!b_info->device_model_version)
-        b_info->device_model_version =
-            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (!b_info->device_model_version) {
+        if (b_info->type == LIBXL_DOMAIN_TYPE_HVM)
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+        else {
+            const char *dm;
+            struct stat buf;
+            int rc;
+
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+            dm = libxl__domain_device_model(gc, b_info);
+            rc = stat(dm, &buf);
+            /* qemu-xen unavailable, use qemu-xen-traditional */
+            if (rc != 0) {
+                LIBXL__LOG(CTX, XTL_VERBOSE, "setting device model to "
+                        "qemu-xen-traditional because qemu-xen is unavailable");
+                b_info->device_model_version =
+                    LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+            }
+        }
+    }
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
@@ -99,8 +120,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
-    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
-
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
         b_info->device_model_version !=
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:52:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDK5-00040S-BZ; Fri, 20 Apr 2012 12:52:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SLDK3-00040I-Vq
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:52:24 +0000
Received: from [85.158.143.99:16938] by server-2.bemta-4.messagelabs.com id
	97/BB-17550-70C519F4; Fri, 20 Apr 2012 12:52:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334926342!23624765!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19626 invoked from network); 20 Apr 2012 12:52:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 12:52:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 13:52:21 +0100
Message-Id: <4F917823020000780007EDDF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 13:52:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 14:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
>> On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
>> > On 20/04/12 10:25, Lin Ming wrote:
>> > > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
>> > > information instead of fabricated one.
>> > >
>> > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>> > > ---
>> > >  arch/x86/xen/apic.c |   16 +++++++++++-----
>> > >  1 files changed, 11 insertions(+), 5 deletions(-)
>> > >
>> > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
>> > > index aee16ab..f1f392d 100644
>> > > --- a/arch/x86/xen/apic.c
>> > > +++ b/arch/x86/xen/apic.c
>> > > @@ -1,14 +1,20 @@
>> > >  #include <linux/init.h>
>> > >  #include <asm/x86_init.h>
>> > > +#include <asm/apic.h>
>> > > +#include <xen/interface/physdev.h>
>> > > +#include <asm/xen/hypercall.h>
>> > >  
>> > >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>> > >  {
>> > > -	if (reg == 0x1)
>> > > -		return 0x00170020;
>> > > -	else if (reg == 0x0)
>> > > -		return apic << 24;
>> > > +	struct physdev_apic apic_op;
>> > > +	int ret;
>> > >  
>> > > -	return 0xff;
>> > > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
>> > > +	apic_op.reg = reg;
>> > > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
>> > > +	if (ret)
>> > > +		return ret;
>> > > +	return apic_op.value;
>> > 
>> > Hypercall ret errors are negative, yet this function is unsigned.  Given
>> > that the previous function had no possible way to fail, perhaps on error
>> > you should fake up the values as before.
>> 
>> How about return -1 on error?
>> The calling function can check -1 for error. 
> 
> Isn't -1 potentially (at least theoretically) a valid value to read from
> one of these registers?
> 
> Under what circumstances can these hypercalls fail?

Only when the input is wrong (or it's not a privileged domain).

> Would a BUG_ON be appropriate/

Probably.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:52:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDK5-00040S-BZ; Fri, 20 Apr 2012 12:52:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SLDK3-00040I-Vq
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:52:24 +0000
Received: from [85.158.143.99:16938] by server-2.bemta-4.messagelabs.com id
	97/BB-17550-70C519F4; Fri, 20 Apr 2012 12:52:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334926342!23624765!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19626 invoked from network); 20 Apr 2012 12:52:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 12:52:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 13:52:21 +0100
Message-Id: <4F917823020000780007EDDF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 13:52:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 14:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
>> On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
>> > On 20/04/12 10:25, Lin Ming wrote:
>> > > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
>> > > information instead of fabricated one.
>> > >
>> > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>> > > ---
>> > >  arch/x86/xen/apic.c |   16 +++++++++++-----
>> > >  1 files changed, 11 insertions(+), 5 deletions(-)
>> > >
>> > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
>> > > index aee16ab..f1f392d 100644
>> > > --- a/arch/x86/xen/apic.c
>> > > +++ b/arch/x86/xen/apic.c
>> > > @@ -1,14 +1,20 @@
>> > >  #include <linux/init.h>
>> > >  #include <asm/x86_init.h>
>> > > +#include <asm/apic.h>
>> > > +#include <xen/interface/physdev.h>
>> > > +#include <asm/xen/hypercall.h>
>> > >  
>> > >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>> > >  {
>> > > -	if (reg == 0x1)
>> > > -		return 0x00170020;
>> > > -	else if (reg == 0x0)
>> > > -		return apic << 24;
>> > > +	struct physdev_apic apic_op;
>> > > +	int ret;
>> > >  
>> > > -	return 0xff;
>> > > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
>> > > +	apic_op.reg = reg;
>> > > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
>> > > +	if (ret)
>> > > +		return ret;
>> > > +	return apic_op.value;
>> > 
>> > Hypercall ret errors are negative, yet this function is unsigned.  Given
>> > that the previous function had no possible way to fail, perhaps on error
>> > you should fake up the values as before.
>> 
>> How about return -1 on error?
>> The calling function can check -1 for error. 
> 
> Isn't -1 potentially (at least theoretically) a valid value to read from
> one of these registers?
> 
> Under what circumstances can these hypercalls fail?

Only when the input is wrong (or it's not a privileged domain).

> Would a BUG_ON be appropriate/

Probably.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:53:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDL9-000465-Q7; Fri, 20 Apr 2012 12:53:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SLDL9-00045q-4o
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:53:31 +0000
Received: from [85.158.143.35:41972] by server-1.bemta-4.messagelabs.com id
	C0/47-20925-84C519F4; Fri, 20 Apr 2012 12:53:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334926406!10892420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM4Njc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31445 invoked from network); 20 Apr 2012 12:53:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:53:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24362419"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 08:53:25 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Apr 2012
	08:53:25 -0400
Message-ID: <4F915C43.4020207@citrix.com>
Date: Fri, 20 Apr 2012 13:53:23 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/12 13:38, Ian Campbell wrote:
> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
>> On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
>>> On 20/04/12 10:25, Lin Ming wrote:
>>>> Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
>>>> information instead of fabricated one.
>>>>
>>>> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>>>> ---
>>>>  arch/x86/xen/apic.c |   16 +++++++++++-----
>>>>  1 files changed, 11 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
>>>> index aee16ab..f1f392d 100644
>>>> --- a/arch/x86/xen/apic.c
>>>> +++ b/arch/x86/xen/apic.c
>>>> @@ -1,14 +1,20 @@
>>>>  #include <linux/init.h>
>>>>  #include <asm/x86_init.h>
>>>> +#include <asm/apic.h>
>>>> +#include <xen/interface/physdev.h>
>>>> +#include <asm/xen/hypercall.h>
>>>>  
>>>>  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>>>>  {
>>>> -	if (reg == 0x1)
>>>> -		return 0x00170020;
>>>> -	else if (reg == 0x0)
>>>> -		return apic << 24;
>>>> +	struct physdev_apic apic_op;
>>>> +	int ret;
>>>>  
>>>> -	return 0xff;
>>>> +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
>>>> +	apic_op.reg = reg;
>>>> +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +	return apic_op.value;
>>> Hypercall ret errors are negative, yet this function is unsigned.  Given
>>> that the previous function had no possible way to fail, perhaps on error
>>> you should fake up the values as before.
>> How about return -1 on error?
>> The calling function can check -1 for error. 
> Isn't -1 potentially (at least theoretically) a valid value to read from
> one of these registers?

Theoretically yes, but practically it would only be buggy hardware
returning -1.

>
> Under what circumstances can these hypercalls fail? Would a BUG_ON be
> appropriate/

-EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
be -EPERM).  The call into Xen itself will return 0 as a value if an
invalid physbase is passed in the hypercall.

So a BUG_ON() is not safe/sensible for domU.

>
>> unsigned int ret = apic_read(...);
>> if (ret == -1)
>> 	//handle error.
>>
>> Thanks,
>> Lin Ming
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 12:53:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 12:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDL9-000465-Q7; Fri, 20 Apr 2012 12:53:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SLDL9-00045q-4o
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 12:53:31 +0000
Received: from [85.158.143.35:41972] by server-1.bemta-4.messagelabs.com id
	C0/47-20925-84C519F4; Fri, 20 Apr 2012 12:53:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334926406!10892420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzM4Njc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31445 invoked from network); 20 Apr 2012 12:53:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 12:53:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24362419"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 08:53:25 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Apr 2012
	08:53:25 -0400
Message-ID: <4F915C43.4020207@citrix.com>
Date: Fri, 20 Apr 2012 13:53:23 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/12 13:38, Ian Campbell wrote:
> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
>> On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
>>> On 20/04/12 10:25, Lin Ming wrote:
>>>> Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
>>>> information instead of fabricated one.
>>>>
>>>> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>>>> ---
>>>>  arch/x86/xen/apic.c |   16 +++++++++++-----
>>>>  1 files changed, 11 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
>>>> index aee16ab..f1f392d 100644
>>>> --- a/arch/x86/xen/apic.c
>>>> +++ b/arch/x86/xen/apic.c
>>>> @@ -1,14 +1,20 @@
>>>>  #include <linux/init.h>
>>>>  #include <asm/x86_init.h>
>>>> +#include <asm/apic.h>
>>>> +#include <xen/interface/physdev.h>
>>>> +#include <asm/xen/hypercall.h>
>>>>  
>>>>  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>>>>  {
>>>> -	if (reg == 0x1)
>>>> -		return 0x00170020;
>>>> -	else if (reg == 0x0)
>>>> -		return apic << 24;
>>>> +	struct physdev_apic apic_op;
>>>> +	int ret;
>>>>  
>>>> -	return 0xff;
>>>> +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
>>>> +	apic_op.reg = reg;
>>>> +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +	return apic_op.value;
>>> Hypercall ret errors are negative, yet this function is unsigned.  Given
>>> that the previous function had no possible way to fail, perhaps on error
>>> you should fake up the values as before.
>> How about return -1 on error?
>> The calling function can check -1 for error. 
> Isn't -1 potentially (at least theoretically) a valid value to read from
> one of these registers?

Theoretically yes, but practically it would only be buggy hardware
returning -1.

>
> Under what circumstances can these hypercalls fail? Would a BUG_ON be
> appropriate/

-EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
be -EPERM).  The call into Xen itself will return 0 as a value if an
invalid physbase is passed in the hypercall.

So a BUG_ON() is not safe/sensible for domU.

>
>> unsigned int ret = apic_read(...);
>> if (ret == -1)
>> 	//handle error.
>>
>> Thanks,
>> Lin Ming
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:01:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDSU-0004Na-N6; Fri, 20 Apr 2012 13:01:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLDST-0004NV-Bm
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:01:05 +0000
Received: from [85.158.139.83:5695] by server-12.bemta-5.messagelabs.com id
	DF/CA-05587-01E519F4; Fri, 20 Apr 2012 13:01:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334926863!24747903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15482 invoked from network); 20 Apr 2012 13:01:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:01:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:01:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:01:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLDSR-0001Ke-9Q; Fri, 20 Apr 2012 13:01:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLDSR-0005Kd-8H;
	Fri, 20 Apr 2012 14:01:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.24079.242104.252793@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 14:01:03 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/1] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[PATCH 1/1] libxl: use qemu-xen with PV guests by default"):
> qemu-xen offers better disk performances than qemu-xen-traditional
> because it supports Linux native AIO: use it for PV guests if it is
> available.
...
> +            rc = stat(dm, &buf);
> +            /* qemu-xen unavailable, use qemu-xen-traditional */

Firstly, why not use access(2) rather than stat(2) ?

Secondly you ignore the errno value.  errnos other than ENOENT (or
perhaps ENOTDIR) should perhaps cause us to bomb out, and in any case
the errno value should be logged.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:01:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDSU-0004Na-N6; Fri, 20 Apr 2012 13:01:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLDST-0004NV-Bm
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:01:05 +0000
Received: from [85.158.139.83:5695] by server-12.bemta-5.messagelabs.com id
	DF/CA-05587-01E519F4; Fri, 20 Apr 2012 13:01:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1334926863!24747903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15482 invoked from network); 20 Apr 2012 13:01:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:01:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:01:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:01:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLDSR-0001Ke-9Q; Fri, 20 Apr 2012 13:01:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLDSR-0005Kd-8H;
	Fri, 20 Apr 2012 14:01:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.24079.242104.252793@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 14:01:03 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/1] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[PATCH 1/1] libxl: use qemu-xen with PV guests by default"):
> qemu-xen offers better disk performances than qemu-xen-traditional
> because it supports Linux native AIO: use it for PV guests if it is
> available.
...
> +            rc = stat(dm, &buf);
> +            /* qemu-xen unavailable, use qemu-xen-traditional */

Firstly, why not use access(2) rather than stat(2) ?

Secondly you ignore the errno value.  errnos other than ENOENT (or
perhaps ENOTDIR) should perhaps cause us to bomb out, and in any case
the errno value should be logged.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:13:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDds-0004k6-3E; Fri, 20 Apr 2012 13:12:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDdq-0004jz-Rt
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:12:50 +0000
Received: from [85.158.138.51:36731] by server-9.bemta-3.messagelabs.com id
	DC/33-26691-2D0619F4; Fri, 20 Apr 2012 13:12:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334927568!23021050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18448 invoked from network); 20 Apr 2012 13:12:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:12:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:12:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 14:12:48 +0100
Message-ID: <1334927566.28331.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Fri, 20 Apr 2012 14:12:46 +0100
In-Reply-To: <4F915C43.4020207@citrix.com>
References: <1334913957.2863.1.camel@hp6530s>  <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> >
> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> > appropriate/
> 
> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> be -EPERM).

So either the guest has called a hypercall which it is not permitted to
or it has called it with invalid parameters of one sort or another. Both
of these would be a code bug in the guest and therefore asserting that
no failure occurred is reasonable?

What could the caller do with the error other than log it and collapse?

> The call into Xen itself will return 0 as a value if an
> invalid physbase is passed in the hypercall.

> So a BUG_ON() is not safe/sensible for domU.

I think you have successfully argued that it is ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:13:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDds-0004k6-3E; Fri, 20 Apr 2012 13:12:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDdq-0004jz-Rt
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:12:50 +0000
Received: from [85.158.138.51:36731] by server-9.bemta-3.messagelabs.com id
	DC/33-26691-2D0619F4; Fri, 20 Apr 2012 13:12:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334927568!23021050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18448 invoked from network); 20 Apr 2012 13:12:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:12:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:12:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 14:12:48 +0100
Message-ID: <1334927566.28331.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Fri, 20 Apr 2012 14:12:46 +0100
In-Reply-To: <4F915C43.4020207@citrix.com>
References: <1334913957.2863.1.camel@hp6530s>  <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> >
> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> > appropriate/
> 
> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> be -EPERM).

So either the guest has called a hypercall which it is not permitted to
or it has called it with invalid parameters of one sort or another. Both
of these would be a code bug in the guest and therefore asserting that
no failure occurred is reasonable?

What could the caller do with the error other than log it and collapse?

> The call into Xen itself will return 0 as a value if an
> invalid physbase is passed in the hypercall.

> So a BUG_ON() is not safe/sensible for domU.

I think you have successfully argued that it is ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDlB-0004tj-2f; Fri, 20 Apr 2012 13:20:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SLDlA-0004td-7f
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:20:24 +0000
Received: from [85.158.143.35:45109] by server-3.bemta-4.messagelabs.com id
	35/34-05853-792619F4; Fri, 20 Apr 2012 13:20:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334928021!13877618!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1742 invoked from network); 20 Apr 2012 13:20:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="191316724"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:20:19 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Apr 2012
	09:20:19 -0400
Message-ID: <4F916291.2020105@citrix.com>
Date: Fri, 20 Apr 2012 14:20:17 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334927566.28331.80.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/12 14:12, Ian Campbell wrote:
> On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
>>> Under what circumstances can these hypercalls fail? Would a BUG_ON be
>>> appropriate/
>> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
>> be -EPERM).
> So either the guest has called a hypercall which it is not permitted to
> or it has called it with invalid parameters of one sort or another. Both
> of these would be a code bug in the guest and therefore asserting that
> no failure occurred is reasonable?
>
> What could the caller do with the error other than log it and collapse?
>
>> The call into Xen itself will return 0 as a value if an
>> invalid physbase is passed in the hypercall.
>> So a BUG_ON() is not safe/sensible for domU.
> I think you have successfully argued that it is ;-)
>
> Ian.
>

So I have.  -EMoreCoffee

Yes - I meant to say that BUG_ON() was ok for domU.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDlB-0004tj-2f; Fri, 20 Apr 2012 13:20:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1SLDlA-0004td-7f
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:20:24 +0000
Received: from [85.158.143.35:45109] by server-3.bemta-4.messagelabs.com id
	35/34-05853-792619F4; Fri, 20 Apr 2012 13:20:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1334928021!13877618!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDQ0NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1742 invoked from network); 20 Apr 2012 13:20:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="191316724"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:20:19 -0400
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Apr 2012
	09:20:19 -0400
Message-ID: <4F916291.2020105@citrix.com>
Date: Fri, 20 Apr 2012 14:20:17 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334927566.28331.80.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/04/12 14:12, Ian Campbell wrote:
> On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
>>> Under what circumstances can these hypercalls fail? Would a BUG_ON be
>>> appropriate/
>> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
>> be -EPERM).
> So either the guest has called a hypercall which it is not permitted to
> or it has called it with invalid parameters of one sort or another. Both
> of these would be a code bug in the guest and therefore asserting that
> no failure occurred is reasonable?
>
> What could the caller do with the error other than log it and collapse?
>
>> The call into Xen itself will return 0 as a value if an
>> invalid physbase is passed in the hypercall.
>> So a BUG_ON() is not safe/sensible for domU.
> I think you have successfully argued that it is ;-)
>
> Ian.
>

So I have.  -EMoreCoffee

Yes - I meant to say that BUG_ON() was ok for domU.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:22:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDmo-0004xw-J3; Fri, 20 Apr 2012 13:22:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDmn-0004xp-0T
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:22:05 +0000
Received: from [85.158.143.35:64109] by server-1.bemta-4.messagelabs.com id
	39/65-20925-CF2619F4; Fri, 20 Apr 2012 13:22:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334928122!13366053!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 20 Apr 2012 13:22:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:22:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:21:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 14:21:57 +0100
Message-ID: <1334928115.28331.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 14:21:55 +0100
In-Reply-To: <20369.17085.330843.561841@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> > > I'm not quite up to speed with all the context here but is the reason
> > > that you're not suggesting "xen-" is that that's already used for
> > > something else ?
> > 
> > This is to distinguish the vif device from the associated tap device,
> > which would otherwise both be called whatever the user gave as "vifname"
> > in their config, so for vifname=foo you would get foo (the PV one) and
> > xen-foo (the EMU one) which does the job but doesn't really distinguish
> > them.
> 
> Ah, I see.  This sounds like more a job for a suffix than a prefix so
> if we can spare 4 chars I would suggest foo-emu.

I agree.

This patch interacts a bit with Roger's hotplug series, I'll rebase on
top of his with this change when he reposts it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:22:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDmo-0004xw-J3; Fri, 20 Apr 2012 13:22:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDmn-0004xp-0T
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:22:05 +0000
Received: from [85.158.143.35:64109] by server-1.bemta-4.messagelabs.com id
	39/65-20925-CF2619F4; Fri, 20 Apr 2012 13:22:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334928122!13366053!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 20 Apr 2012 13:22:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:22:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12048967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:21:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 14:21:57 +0100
Message-ID: <1334928115.28331.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 14:21:55 +0100
In-Reply-To: <20369.17085.330843.561841@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> > > I'm not quite up to speed with all the context here but is the reason
> > > that you're not suggesting "xen-" is that that's already used for
> > > something else ?
> > 
> > This is to distinguish the vif device from the associated tap device,
> > which would otherwise both be called whatever the user gave as "vifname"
> > in their config, so for vifname=foo you would get foo (the PV one) and
> > xen-foo (the EMU one) which does the job but doesn't really distinguish
> > them.
> 
> Ah, I see.  This sounds like more a job for a suffix than a prefix so
> if we can spare 4 chars I would suggest foo-emu.

I agree.

This patch interacts a bit with Roger's hotplug series, I'll rebase on
top of his with this change when he reposts it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoR-00054W-TZ; Fri, 20 Apr 2012 13:23:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoP-00053m-T3
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:46 +0000
Received: from [85.158.143.35:21548] by server-3.bemta-4.messagelabs.com id
	93/6A-05853-163619F4; Fri, 20 Apr 2012 13:23:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11770 invoked from network); 20 Apr 2012 13:23:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363600"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-MP;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:28 +0100
Message-ID: <1334928211-29856-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a function which behaves like "xenstore-rm -t", and which will be used to
clean xenstore after unplug since we will be no longer executing
xen-hotplug-cleanup script, that used to do that for us.

Changes since v2:

 * Moved the function to libxl_xshelp.c and added the prototype to
   libxl_internal.h.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c   |    1 -
 tools/libxl/libxl_internal.h |    6 ++++++
 tools/libxl/libxl_xshelp.c   |   22 ++++++++++++++++++++++
 3 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..36d58cd 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9e15f95..020810a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -458,6 +458,12 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Perfrom recursive cleanup of xenstore path, from top to bottom
+ * just like xenstore-rm -t
+ */
+_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);
+
 
 /*
  * Event generation functions provided by the libxl event core to the
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 3ea8d08..0b1b844 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoR-00054W-TZ; Fri, 20 Apr 2012 13:23:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoP-00053m-T3
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:46 +0000
Received: from [85.158.143.35:21548] by server-3.bemta-4.messagelabs.com id
	93/6A-05853-163619F4; Fri, 20 Apr 2012 13:23:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11770 invoked from network); 20 Apr 2012 13:23:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363600"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-MP;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:28 +0100
Message-ID: <1334928211-29856-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a function which behaves like "xenstore-rm -t", and which will be used to
clean xenstore after unplug since we will be no longer executing
xen-hotplug-cleanup script, that used to do that for us.

Changes since v2:

 * Moved the function to libxl_xshelp.c and added the prototype to
   libxl_internal.h.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c   |    1 -
 tools/libxl/libxl_internal.h |    6 ++++++
 tools/libxl/libxl_xshelp.c   |   22 ++++++++++++++++++++++
 3 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..36d58cd 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9e15f95..020810a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -458,6 +458,12 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Perfrom recursive cleanup of xenstore path, from top to bottom
+ * just like xenstore-rm -t
+ */
+_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);
+
 
 /*
  * Event generation functions provided by the libxl event core to the
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 3ea8d08..0b1b844 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoQ-000542-2n; Fri, 20 Apr 2012 13:23:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoO-00053m-OX
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:44 +0000
Received: from [85.158.143.35:21420] by server-3.bemta-4.messagelabs.com id
	E4/5A-05853-063619F4; Fri, 20 Apr 2012 13:23:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11681 invoked from network); 20 Apr 2012 13:23:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363598"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Js	for xen-devel@lists.xen.org;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:26 +0100
Message-ID: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series removes the use of udev rules to call hotplug scripts when using
libxl. Scripts are directly called from the toolstack at the necessary points,
making use of the new event library and it's fork support.

Fixed Ian Campbell reviews and added support for named vifs using a custom 
constant as prefix (to be merged/mixed with Ian Campbell named interfaces 
patch). This series should be applied after Ian Jackson event fork and Ian 
Campbell support for named vifs.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoQ-000542-2n; Fri, 20 Apr 2012 13:23:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoO-00053m-OX
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:44 +0000
Received: from [85.158.143.35:21420] by server-3.bemta-4.messagelabs.com id
	E4/5A-05853-063619F4; Fri, 20 Apr 2012 13:23:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11681 invoked from network); 20 Apr 2012 13:23:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363598"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Js	for xen-devel@lists.xen.org;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:26 +0100
Message-ID: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series removes the use of udev rules to call hotplug scripts when using
libxl. Scripts are directly called from the toolstack at the necessary points,
making use of the new event library and it's fork support.

Fixed Ian Campbell reviews and added support for named vifs using a custom 
constant as prefix (to be merged/mixed with Ian Campbell named interfaces 
patch). This series should be applied after Ian Jackson event fork and Ian 
Campbell support for named vifs.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoU-00055V-6f; Fri, 20 Apr 2012 13:23:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoR-00054I-FU
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:48 +0000
Received: from [193.109.254.147:29819] by server-7.bemta-14.messagelabs.com id
	74/EC-01627-263619F4; Fri, 20 Apr 2012 13:23:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334928223!5493385!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzgzMzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19360 invoked from network); 20 Apr 2012 13:23:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363601"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Mw;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:29 +0100
Message-ID: <1334928211-29856-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

 * Added a check in xen-hotplug-common.sh, so scripts are only executed from
   udev when using xend. xl adds a disable_udev=y to xenstore private directory
   and with the modification of the udev rules every call from udev gets
   HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is passed
   and points to a value, the hotplug script is not executed.

I've also modified the python binding for pyxl_domain_destroy, that now take the
ao_how parameter, but I'm not really sure if it's done correctly, let's just say
that it compiles.

Changes since v3:

 * disable_udev is now stored in /libxl/backend/vbd/<domid>/<devid>/.

 * Passed NULL as ao_how in Python bindings.

Changes since v1:

 * Replaced the hotplug snippet that prevents execution from udev when
   necessary, and now we set the env var from udev rules instead of libxl.

 * Replaced the libxl_device_disk_add "if" with a "switch".

 * Removed libxl__xs_path_cleanup (replaced with xs_rm).

 * Fixed several spelling mistakes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules     |    6 +-
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 +
 tools/libxl/Makefile                      |    3 +-
 tools/libxl/libxl.c                       |  144 ++++++++++++++++++++++-----
 tools/libxl/libxl.h                       |    7 +-
 tools/libxl/libxl_create.c                |    4 +-
 tools/libxl/libxl_device.c                |  152 ++++++++++++++++++++++++++---
 tools/libxl/libxl_dm.c                    |    4 +-
 tools/libxl/libxl_hotplug.c               |   67 +++++++++++++
 tools/libxl/libxl_internal.h              |   46 ++++++++-
 tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++
 tools/libxl/libxl_pci.c                   |    5 +-
 tools/libxl/xl_cmdimpl.c                  |   14 ++--
 tools/python/xen/lowlevel/xl/xl.c         |    2 +-
 14 files changed, 516 insertions(+), 61 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 19bd0fa..19f3d27 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..d2aac3a 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts from udev if the domain
+# has been launched from libxl
+if [ -n "${HOTPLUG_GATE}" ] && \
+   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..0ac43bd 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f0372d0..eaa3095 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,11 +1317,14 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
+    flexarray_t *private;
     char *dev;
     libxl__device device;
     int major, minor, rc;
@@ -1330,10 +1337,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(20, 1);
     if (!back) {
         rc = ERROR_NOMEM;
-        goto out_free;
+        goto out_free_f;
+    }
+    private = flexarray_make(2, 1);
+    if (!private) {
+        rc = ERROR_NOMEM;
+        goto out_free_b;
     }
 
     if (disk->script) {
@@ -1361,6 +1373,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1391,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1416,18 +1438,38 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
+    /* compatibility addon to keep udev rules */
+    flexarray_append(private, "disable_udev");
+    flexarray_append(private, "y");
+
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                    libxl__xs_kvs_of_flexarray(gc, private, private->count));
+
+    switch(disk->backend) {
+    case LIBXL_DISK_BACKEND_PHY:
+    case LIBXL_DISK_BACKEND_TAP:
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+        break;
+    case LIBXL_DISK_BACKEND_QDISK:
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
 
     rc = 0;
 
 out_free:
+    flexarray_free(private);
+out_free_b:
     flexarray_free(back);
+out_free_f:
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1484,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1719,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1884,8 +1937,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
 
     /* FIXME: wait for plug */
     rc = 0;
@@ -1909,7 +1963,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2162,8 +2227,9 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
     }
 
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
     rc = 0;
 out_free:
     flexarray_free(back);
@@ -2233,8 +2299,9 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
     rc = 0;
 out_free:
     flexarray_free(back);
@@ -2256,7 +2323,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2366,8 +2444,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
     rc = 0;
 out_free:
     flexarray_free(front);
@@ -2389,7 +2468,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..6687e2e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -472,7 +472,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -601,7 +602,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 36d58cd..aa19fab 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -40,6 +40,13 @@ char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device)
                           device->domid, device->devid);
 }
 
+char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
+{
+    return libxl__sprintf(gc, "/libxl/backend/%s/%u/%d",
+                          libxl__device_kind_to_string(device->backend_kind),
+                          device->domid, device->devid);
+}
+
 int libxl__parse_backend_path(libxl__gc *gc,
                               const char *path,
                               libxl__device *dev)
@@ -59,16 +66,18 @@ int libxl__parse_backend_path(libxl__gc *gc,
 }
 
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+                             char **bents, char **fents, char **private)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    char *frontend_path, *backend_path;
+    char *frontend_path, *backend_path, *private_path;
     xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    struct xs_permissions private_perms[1];
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
+    private_path = libxl__device_private_path(gc, device);
 
     frontend_perms[0].id = device->domid;
     frontend_perms[0].perms = XS_PERM_NONE;
@@ -80,6 +89,9 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].id = device->domid;
     backend_perms[1].perms = XS_PERM_READ;
 
+    private_perms[0].id = device->backend_domid;
+    private_perms[0].perms = XS_PERM_NONE;
+
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
@@ -100,6 +112,14 @@ retry_transaction:
         libxl__xs_writev(gc, t, backend_path, bents);
     }
 
+    if (private) {
+        xs_rm(ctx->xsh, t, private_path);
+        xs_mkdir(ctx->xsh, t, private_path);
+        xs_set_permissions(ctx->xsh, t, private_path, private_perms,
+                           ARRAY_SIZE(private_perms));
+        libxl__xs_writev(gc, t, private_path, private);
+    }
+
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;
@@ -359,22 +379,71 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_private_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events were added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -391,7 +460,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -412,6 +480,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -419,7 +488,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -427,31 +496,77 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, libxl__device_private_path(gc, dev));
     return 0;
 }
 
-int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
+    return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
+}
+
+int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    char *pr_path = libxl__device_private_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, fe_path);
+    libxl__xs_path_cleanup(gc, pr_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -481,11 +596,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events were added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 15e24b9..4ce58f6 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -789,7 +789,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1047,7 +1047,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..2eace0c
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.pau@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 020810a..95d5c40 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -464,6 +465,37 @@ _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
  */
 _hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -743,13 +775,15 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+                             char **bents, char **fents, char **private);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_private_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -772,6 +806,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..7c107dc 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,120 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    flexarray_t *f_env;
+    char **env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return NULL;
+    }
+
+    f_env = flexarray_make(9, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, script);
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+
+    flexarray_set(f_env, nr++, NULL);
+
+    env = (char **) flexarray_contents(f_env);
+
+    return env;
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index e8b8839..fd79d1d 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -103,8 +103,9 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
     libxl__device_generic_add(gc, &device,
-                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
 
 out:
     if (back)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..0bc3ac2 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1306,7 +1306,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1867,7 +1867,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2354,7 +2354,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2628,7 +2628,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2861,7 +2861,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2979,7 +2979,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5026,7 +5026,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index c4f7c52..ce7a2b2 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
     int domid;
     if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, NULL) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoT-000555-Am; Fri, 20 Apr 2012 13:23:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoR-00054N-Or
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:48 +0000
Received: from [85.158.143.35:16931] by server-1.bemta-4.messagelabs.com id
	3C/48-20925-363619F4; Fri, 20 Apr 2012 13:23:47 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11814 invoked from network); 20 Apr 2012 13:23:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363602"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Qn;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:30 +0100
Message-ID: <1334928211-29856-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from libxl
	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

An exception has been introduced for tap devices, since hotplug scripts
should be called after the device model has been created, so the hotplug
call for those is done in do_domain_create after confirmation of the device
model startup. On the other hand, tap devices don't use teardown scripts,
so add another exception for that.

libxl__device_from_nic was moved to libxl_device.c, so it can be used
in libxl_create.c, and libxl__device_from_disk was also moved to maintain
the symmetry.

libxl__initiate_device_remove has been changed a little, to nuke the frontend
xenstore path before trying to perform device teardown, this allows for
uninitialized devices to be closed gracefully, specially vif interfaces added to
HVM machines and not used.

PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
LIBXL_NIC_TYPE_IOEMU regardless of the guest type.

A new global option, called disable_vif_scripts has been added to allow the user
decide if he wants to execute the hotplug scripts from xl or from udev. This has
been documented in the xl.conf man page.

Changes since v2:

 * Added fancy functions to fetch tap and vif names, now the prefix of the tap
   device has been saved in a constant, called TAP_DEVICE_PREFIX.

 * Wait for timeout before nuking frontend xenstore entries.

 * Changed disable_vif_scripts to disable_xl_vif_scripts, it's easier to
   understand.

 * Default nic type set by libxl__device_nic_setdefault is VIF now (was IOEMU).

 * Save nic type and udev script exection inside
   /libxl/devices/<domid>/nic/<devid>/ instead of saving it in the backend path.

Changes since v1:

 * Propagated changes from previous patch (disable_udev and libxl_device_nic_add
   switch).

 * Modified udev rules to add the new env variable.

 * Added support for named interfaces.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5                |    7 ++
 tools/examples/xl.conf                |    3 +
 tools/hotplug/Linux/xen-backend.rules |    6 +-
 tools/libxl/libxl.c                   |  125 +++++++++++++-----------------
 tools/libxl/libxl.h                   |    3 +-
 tools/libxl/libxl_create.c            |   22 +++++-
 tools/libxl/libxl_device.c            |  122 +++++++++++++++++++++++++++--
 tools/libxl/libxl_dm.c                |    2 +-
 tools/libxl/libxl_internal.h          |   18 ++++-
 tools/libxl/libxl_linux.c             |  137 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_types.idl           |    1 +
 tools/libxl/xl.c                      |    4 +
 tools/libxl/xl.h                      |    1 +
 tools/libxl/xl_cmdimpl.c              |    8 ++-
 14 files changed, 369 insertions(+), 90 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8bd45ea..da8f16f 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,13 @@ default.
 
 Default: C<1>
 
+=item B<disable_xl_vif_scripts=BOOLEAN>
+
+If enabled xl will not execute nic hotplug scripts itself, and instead
+relegate this task to udev.
+
+Default: C<0>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..172ff80 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# default caller of hotplug scripts for vif interfaces
+#disable_xl_vif_scripts=0
diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 19f3d27..5dca574 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="emu*", ACTION=="add", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index eaa3095..11d3b3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1277,46 +1277,6 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
                           libxl_device_disk *disk,
                           const libxl_asyncop_how *ao_how)
@@ -1483,7 +1443,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
@@ -1838,29 +1798,17 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
                                   libxl_xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
-        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
-    return 0;
-}
-
-static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
-                                  libxl_device_nic *nic,
-                                  libxl__device *device)
-{
-    device->backend_devid    = nic->devid;
-    device->backend_domid    = nic->backend_domid;
-    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
-    device->devid            = nic->devid;
-    device->domid            = domid;
-    device->kind             = LIBXL__DEVICE_KIND_VIF;
-
+        nic->nictype = LIBXL_NIC_TYPE_VIF;
     return 0;
 }
 
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
+    flexarray_t *private;
     libxl__device device;
     char *dompath, **l;
     unsigned int nb, rc;
@@ -1873,10 +1821,15 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
-        goto out_free;
+        goto out_free_f;
+    }
+    private = flexarray_make(4, 1);
+    if (!private) {
+        rc = ERROR_NOMEM;
+        goto out_free_b;
     }
 
     if (nic->devid == -1) {
@@ -1936,19 +1889,53 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
+
+    flexarray_append(private, "type");
+    flexarray_append(private, libxl__sprintf(gc, "%s", libxl_nic_type_to_string(
+                                                                nic->nictype)));
+    /* compatibility addon to keep udev rules */
+    if (!nic->disable_xl_vif_script) {
+        flexarray_append(private, "disable_udev");
+        flexarray_append(private, "y");
+    }
+
     libxl__device_generic_add(gc, &device,
-                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
-                            NULL);
+                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                    libxl__xs_kvs_of_flexarray(gc, private, private->count));
+
+    switch(nic->nictype) {
+    case LIBXL_NIC_TYPE_VIF:
+        if (!nic->disable_xl_vif_script) {
+            rc = libxl__initiate_device_add(egc, ao, &device);
+            if (rc) goto out_free;
+        } else {
+            libxl__ao_complete(egc, ao, 0);
+        }
+        break;
+    case LIBXL_NIC_TYPE_IOEMU:
+        /*
+         * Don't execute hotplug scripts for IOEMU interfaces yet,
+         * we need to launch the device model first.
+         * 
+         * This are actually launched from do_domain_create after the
+         * domain model has been started.
+        */
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
 
-    /* FIXME: wait for plug */
     rc = 0;
 out_free:
+    flexarray_free(private);
+out_free_b:
     flexarray_free(back);
+out_free_f:
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1962,7 +1949,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
@@ -2322,7 +2309,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
@@ -2467,7 +2454,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6687e2e..723c3aa 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -629,7 +629,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..023159b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
@@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                        "device model did not start: %d", ret);
             goto error_out;
         }
+        /* 
+         * Execute hotplug scripts for tap devices, this has to be done
+         * after the domain model has been started.
+        */
+        for (i = 0; i < d_config->num_vifs; i++) {
+            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
+                !d_config->vifs[i].disable_xl_vif_script) {
+                libxl__device device;
+                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
+                                             &device);
+                if (ret < 0) goto error_out;
+                ret = libxl__device_hotplug(gc, &device, CONNECT);
+                if (ret < 0) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                               "unable to launch hotplug script for device: "
+                               "%"PRIu32, device.devid);
+                    goto error_out;
+                }
+            }
+        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index aa19fab..7514290 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -47,6 +47,34 @@ char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
                           device->domid, device->devid);
 }
 
+char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_private_path(gc, dev);
+    char *ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                   be_path,
+                                                                   "vifname"));
+    if (!ifname) {
+        ifname = libxl__sprintf(gc, "vif%u.%d", dev->domid, dev->devid);
+    }
+
+    return ifname;
+}
+
+char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_private_path(gc, dev);
+    char *ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                   be_path,
+                                                                   "vifname"));
+    if (!ifname) {
+        ifname = libxl__sprintf(gc, TAP_DEVICE_PREFIX"%u.%d", dev->domid, dev->devid);
+    } else {
+        ifname = libxl__sprintf(gc, TAP_DEVICE_PREFIX"-%s", ifname);
+    }
+
+    return ifname;
+}
+
 int libxl__parse_backend_path(libxl__gc *gc,
                               const char *path,
                               libxl__device *dev)
@@ -269,6 +297,60 @@ char *libxl__device_disk_string_of_backend(libxl_disk_backend backend)
     }
 }
 
+int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                           libxl_device_nic *nic,
+                           libxl__device *device)
+{
+    device->backend_devid    = nic->devid;
+    device->backend_domid    = nic->backend_domid;
+    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
+    device->devid            = nic->devid;
+    device->domid            = domid;
+    device->kind             = LIBXL__DEVICE_KIND_VIF;
+
+    return 0;
+}
+
+int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                            libxl_device_disk *disk,
+                            libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
 int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor)
 {
     struct stat buf;
@@ -380,6 +462,7 @@ typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
     libxl__device *dev;
+    int force;
 } libxl__ao_device_remove;
 
 typedef struct {
@@ -406,6 +489,16 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     libxl__gc *gc = &aorm->ao->gc;
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
+    if (rc == ERROR_TIMEDOUT && !aorm->force) {
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unable to remove device %"PRIu32
+                                            ", destroying frontend to force "
+                                            "backend disconnection",
+                                            aorm->dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        libxl__initiate_device_remove(egc, aorm->ao, aorm->dev, 1);
+        return;
+    }
+
     rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
     if (rc)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
@@ -445,26 +538,34 @@ static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
  * libxl__ao_complete when necessary (if no events are added).
  */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
-                                  libxl__device *dev)
+                                  libxl__device *dev, int force)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
+    xs_transaction_t t = 0;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
     libxl__ao_device_remove *aorm = 0;
 
+    if (force)
+        libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+        /*
+         * Nuke frontend to force backend teardown
+         * It's not pretty, but it's the only way that seems to work for all
+         * types of backends
+         */
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
     if (!state)
         goto out_ok;
-    if (atoi(state) != 4) {
+    if (atoi(state) == XenbusStateClosed)
         libxl__device_destroy_tapdisk(gc, be_path);
         goto out_ok;
-    }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -475,12 +576,15 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
     aorm->dev = dev;
+    aorm->force = force;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -496,8 +600,8 @@ retry_transaction:
     return rc;
 
  out_ok:
+    if (t) xs_transaction_end(ctx->xsh, t, 0);
     rc = libxl__device_hotplug(gc, dev, DISCONNECT);
-    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
     libxl__xs_path_cleanup(gc, be_path);
     libxl__xs_path_cleanup(gc, libxl__device_private_path(gc, dev));
     return 0;
@@ -596,7 +700,7 @@ int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev, 0);
                 switch(rc) {
                 case 1:
                     events++;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4ce58f6..8cf9d9d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -794,7 +794,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 95d5c40..68c7514 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -84,6 +84,7 @@
 #define STUBDOM_CONSOLE_RESTORE 2
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
+#define TAP_DEVICE_PREFIX "emu"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -765,6 +766,12 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
 _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*);
+_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__device *device);
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                    libxl_device_disk *disk,
+                                    libxl__device *device);
 
 _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor);
 _hidden int libxl__device_disk_dev_number(const char *virtpath,
@@ -775,10 +782,13 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents, char **private);
+                                      char **bents, char **fents,
+                                      char **private);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
-_hidden char *libxl__device_private_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_private_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev);
+_hidden char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
@@ -803,8 +813,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
-                                          libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                          libxl__device *dev, int force);
 
 /* Arranges that dev will be added to the guest, and the
  * hotplug scripts will be executed (if necessary). When
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 7c107dc..745a11a 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -27,6 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
 }
 
 /* Hotplug scripts helpers */
+
+static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *snictype, *pr_path;
+    libxl_nic_type nictype;
+
+    pr_path = libxl__device_private_path(gc, dev);
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", pr_path, "type"));
+    if (!snictype) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
+                                          pr_path);
+        return -1;
+    }
+    if (libxl_nic_type_from_string(snictype, &nictype) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse nictype from %s",
+                                          pr_path);
+        return -1;
+    }
+
+    return nictype;
+}
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -44,7 +68,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    f_env = flexarray_make(9, 1);
+    f_env = flexarray_make(13, 1);
     if (!f_env) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "unable to create environment array");
@@ -63,6 +87,19 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
                   dev->domid, dev->devid));
     flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
     flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        switch (get_nic_type(gc, dev)) {
+        case LIBXL_NIC_TYPE_IOEMU:
+            flexarray_set(f_env, nr++, "INTERFACE");
+            flexarray_set(f_env, nr++, libxl__device_tap_name(gc, dev));
+        case LIBXL_NIC_TYPE_VIF:
+            flexarray_set(f_env, nr++, "vif");
+            flexarray_set(f_env, nr++, libxl__device_vif_name(gc, dev));
+            break;
+        default:
+            return NULL;
+        }
+    }
 
     flexarray_set(f_env, nr++, NULL);
 
@@ -126,6 +163,101 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+    flexarray_t *vif_args, *tap_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    nictype = get_nic_type(gc, dev);
+    if (nictype < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "error when fetching nic type");
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    vif_args = flexarray_make(4, 1);
+    if (!vif_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+    tap_args = flexarray_make(4, 1);
+    if (!tap_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    switch(nictype) {
+    case LIBXL_NIC_TYPE_IOEMU:
+        flexarray_set(tap_args, nr++, script);
+        flexarray_set(tap_args, nr++, action == CONNECT ? "add" : "remove");
+        flexarray_set(tap_args, nr++, libxl__sprintf(gc, "type_if=tap"));
+        flexarray_set(tap_args, nr++, NULL);
+        args = (char **) flexarray_contents(tap_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        free(args);
+        nr = 0;
+    case LIBXL_NIC_TYPE_VIF:
+        flexarray_set(vif_args, nr++, script);
+        flexarray_set(vif_args, nr++, action == CONNECT ? "online" : "offline");
+        flexarray_set(vif_args, nr++, libxl__sprintf(gc, "type_if=vif"));
+        flexarray_set(vif_args, nr++, NULL);
+        args = (char **) flexarray_contents(vif_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        break;
+    default:
+        /* Unknown network type */
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unknown network card type with "
+                                            "id %"PRIu32, dev->devid);
+        return 0;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -135,6 +267,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..0b2c832 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
     ("ifname", string),
     ("script", string),
     ("nictype", libxl_nic_type),
+    ("disable_xl_vif_script", integer),
     ])
 
 libxl_device_pci = Struct("device_pci", [
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..2f96468 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+int disable_xl_vif_scripts = 0;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    if (!xlu_cfg_get_long (config, "disable_xl_vif_scripts", &l, 0))
+        disable_xl_vif_scripts = l;
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..b60cd12 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -109,6 +109,7 @@ void postfork(void);
 
 /* global options */
 extern int autoballoon;
+extern int disable_xl_vif_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0bc3ac2..704d938 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -847,6 +847,12 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+            /*
+             * Disable nic network script calling, to allow the user
+             * to attach the nic backend from a different domain.
+             */
+            nic->disable_xl_vif_script = disable_xl_vif_scripts;
+
 	    if (default_bridge) {
 		free(nic->bridge);
 		nic->bridge = strdup(default_bridge);
@@ -4916,7 +4922,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoU-00055V-6f; Fri, 20 Apr 2012 13:23:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoR-00054I-FU
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:48 +0000
Received: from [193.109.254.147:29819] by server-7.bemta-14.messagelabs.com id
	74/EC-01627-263619F4; Fri, 20 Apr 2012 13:23:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334928223!5493385!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzgzMzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19360 invoked from network); 20 Apr 2012 13:23:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363601"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Mw;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:29 +0100
Message-ID: <1334928211-29856-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl
	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a rather big change, that adds the necessary machinery to perform
hotplug script calling from libxl for Linux. This patch launches the necessary
scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug
scripts).

Here's a list of the major changes introduced:

 * libxl_device_disk_add makes use of the new event library and takes the
   optional parameter libxl_asyncop_how, to choose how the operation has to be
   issued (sync or async).

 * libxl_device_disk_add waits for backend to switch to state 2 (XenbusInitWait)
   and then launches the hotplug script.

 * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
   calls libxl__initiate_device_remove, so we can disconnect the device and
   execute the necessary hotplug scripts instead of just deleting the backend
   entries. So libxl__devices_destroy now uses the event library, and so does
   libxl_domain_destroy.

 * Since libxl__devices_destroy calls multiple times
   libxl__initiate_device_remove, this function now returns a different value
   regarding the actions taken (if an event was added or not). The user has to
   call libxl__ao_complete after using this function if necessary.

 * The internal API for hotplug scripts has been added, which consists of one
   function; libxl__device_hotplug that takes the device and the action to
   execute.

 * Linux hotplug scripts are called by setting the necessary env variables to
   emulate udev rules, so there's no need to change them (although a rework to
   pass this as parameters insted of env variables would be suitable, so both
   NetBSD and Linux hotplug scripts take the same parameters).

 * Added a check in xen-hotplug-common.sh, so scripts are only executed from
   udev when using xend. xl adds a disable_udev=y to xenstore private directory
   and with the modification of the udev rules every call from udev gets
   HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is passed
   and points to a value, the hotplug script is not executed.

I've also modified the python binding for pyxl_domain_destroy, that now take the
ao_how parameter, but I'm not really sure if it's done correctly, let's just say
that it compiles.

Changes since v3:

 * disable_udev is now stored in /libxl/backend/vbd/<domid>/<devid>/.

 * Passed NULL as ao_how in Python bindings.

Changes since v1:

 * Replaced the hotplug snippet that prevents execution from udev when
   necessary, and now we set the env var from udev rules instead of libxl.

 * Replaced the libxl_device_disk_add "if" with a "switch".

 * Removed libxl__xs_path_cleanup (replaced with xs_rm).

 * Fixed several spelling mistakes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules     |    6 +-
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 +
 tools/libxl/Makefile                      |    3 +-
 tools/libxl/libxl.c                       |  144 ++++++++++++++++++++++-----
 tools/libxl/libxl.h                       |    7 +-
 tools/libxl/libxl_create.c                |    4 +-
 tools/libxl/libxl_device.c                |  152 ++++++++++++++++++++++++++---
 tools/libxl/libxl_dm.c                    |    4 +-
 tools/libxl/libxl_hotplug.c               |   67 +++++++++++++
 tools/libxl/libxl_internal.h              |   46 ++++++++-
 tools/libxl/libxl_linux.c                 |  117 ++++++++++++++++++++++
 tools/libxl/libxl_pci.c                   |    5 +-
 tools/libxl/xl_cmdimpl.c                  |   14 ++--
 tools/python/xen/lowlevel/xl/xl.c         |    2 +-
 14 files changed, 516 insertions(+), 61 deletions(-)
 create mode 100644 tools/libxl/libxl_hotplug.c

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 19bd0fa..19f3d27 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..d2aac3a 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts from udev if the domain
+# has been launched from libxl
+if [ -n "${HOTPLUG_GATE}" ] && \
+   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e5ea867..0ac43bd 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -53,7 +53,8 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.o \
+			$(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f0372d0..eaa3095 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1062,13 +1062,15 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
+    int rc_ao = 0;
 
     rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
@@ -1110,7 +1112,8 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    rc_ao = libxl__devices_destroy(egc, ao, domid);
+    if (rc_ao < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1133,9 +1136,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    if (rc_ao) return AO_ABORT(rc_ao);
+    return AO_INPROGRESS;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
@@ -1313,11 +1317,14 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
+    flexarray_t *private;
     char *dev;
     libxl__device device;
     int major, minor, rc;
@@ -1330,10 +1337,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(20, 1);
     if (!back) {
         rc = ERROR_NOMEM;
-        goto out_free;
+        goto out_free_f;
+    }
+    private = flexarray_make(2, 1);
+    if (!private) {
+        rc = ERROR_NOMEM;
+        goto out_free_b;
     }
 
     if (disk->script) {
@@ -1361,6 +1373,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1374,6 +1391,11 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
@@ -1416,18 +1438,38 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
+    /* compatibility addon to keep udev rules */
+    flexarray_append(private, "disable_udev");
+    flexarray_append(private, "y");
+
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                    libxl__xs_kvs_of_flexarray(gc, private, private->count));
+
+    switch(disk->backend) {
+    case LIBXL_DISK_BACKEND_PHY:
+    case LIBXL_DISK_BACKEND_TAP:
+        rc = libxl__initiate_device_add(egc, ao, &device);
+        if (rc) goto out_free;
+        break;
+    case LIBXL_DISK_BACKEND_QDISK:
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
 
     rc = 0;
 
 out_free:
+    flexarray_free(private);
+out_free_b:
     flexarray_free(back);
+out_free_f:
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1442,7 +1484,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -1666,11 +1719,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1884,8 +1937,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
 
     /* FIXME: wait for plug */
     rc = 0;
@@ -1909,7 +1963,18 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2162,8 +2227,9 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
     }
 
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
     rc = 0;
 out_free:
     flexarray_free(back);
@@ -2233,8 +2299,9 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
     rc = 0;
 out_free:
     flexarray_free(back);
@@ -2256,7 +2323,18 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
@@ -2366,8 +2444,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
     libxl__device_generic_add(gc, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
     rc = 0;
 out_free:
     flexarray_free(front);
@@ -2389,7 +2468,18 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     if (rc != 0) goto out;
 
     rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
+    switch(rc) {
+    case 1:
+        /* event added */
+        break;
+    case 0:
+        /* no event added */
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    default:
+        /* error */
+        goto out;
+    }
 
     return AO_INPROGRESS;
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..6687e2e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -472,7 +472,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
@@ -601,7 +602,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3675afe..de598ad 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -721,7 +721,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     return ret;
 }
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 36d58cd..aa19fab 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -40,6 +40,13 @@ char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device)
                           device->domid, device->devid);
 }
 
+char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
+{
+    return libxl__sprintf(gc, "/libxl/backend/%s/%u/%d",
+                          libxl__device_kind_to_string(device->backend_kind),
+                          device->domid, device->devid);
+}
+
 int libxl__parse_backend_path(libxl__gc *gc,
                               const char *path,
                               libxl__device *dev)
@@ -59,16 +66,18 @@ int libxl__parse_backend_path(libxl__gc *gc,
 }
 
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+                             char **bents, char **fents, char **private)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    char *frontend_path, *backend_path;
+    char *frontend_path, *backend_path, *private_path;
     xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    struct xs_permissions private_perms[1];
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
+    private_path = libxl__device_private_path(gc, device);
 
     frontend_perms[0].id = device->domid;
     frontend_perms[0].perms = XS_PERM_NONE;
@@ -80,6 +89,9 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].id = device->domid;
     backend_perms[1].perms = XS_PERM_READ;
 
+    private_perms[0].id = device->backend_domid;
+    private_perms[0].perms = XS_PERM_NONE;
+
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
@@ -100,6 +112,14 @@ retry_transaction:
         libxl__xs_writev(gc, t, backend_path, bents);
     }
 
+    if (private) {
+        xs_rm(ctx->xsh, t, private_path);
+        xs_mkdir(ctx->xsh, t, private_path);
+        xs_set_permissions(ctx->xsh, t, private_path, private_perms,
+                           ARRAY_SIZE(private_perms));
+        libxl__xs_writev(gc, t, private_path, private);
+    }
+
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;
@@ -359,22 +379,71 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
 typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
+    libxl__device *dev;
 } libxl__ao_device_remove;
 
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+    libxl__device *dev;
+} libxl__ao_device_add;
+
 static void device_remove_cleanup(libxl__gc *gc,
                                   libxl__ao_device_remove *aorm) {
     if (!aorm) return;
     libxl__ev_devstate_cancel(gc, &aorm->ds);
 }
 
+static void device_add_cleanup(libxl__gc *gc,
+                               libxl__ao_device_add *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
+
 static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
     libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
     libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev));
+    libxl__xs_path_cleanup(gc, libxl__device_private_path(gc, aorm->dev));
     libxl__ao_complete(egc, aorm->ao, rc);
     device_remove_cleanup(gc, aorm);
 }
 
+static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                int rc)
+{
+    libxl__ao_device_add *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    rc = libxl__device_hotplug(gc, aorm->dev, CONNECT);
+    if (rc)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
+                                          " device %"PRIu32, aorm->dev->devid);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    if (aorm)
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+    return;
+}
+
+/*
+ * Return codes:
+ * 1 Success and event(s) HAVE BEEN added
+ * 0 Success and NO events were added
+ * < 0 Error
+ *
+ * Since this function can be called several times, and several events
+ * can be added to the same context, the user has to call
+ * libxl__ao_complete when necessary (if no events are added).
+ */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
                                   libxl__device *dev)
 {
@@ -391,7 +460,6 @@ int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
         goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out_ok;
     }
 
@@ -412,6 +480,7 @@ retry_transaction:
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
+    aorm->dev = dev;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -419,7 +488,7 @@ retry_transaction:
                                  LIBXL_DESTROY_TIMEOUT * 1000);
     if (rc) goto out_fail;
 
-    return 0;
+    return 1;
 
  out_fail:
     assert(rc);
@@ -427,31 +496,77 @@ retry_transaction:
     return rc;
 
  out_ok:
-    libxl__ao_complete(egc, ao, 0);
+    rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, libxl__device_private_path(gc, dev));
     return 0;
 }
 
-int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
+                               libxl__device *dev)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    int rc = 0;
+    libxl__ao_device_add *aorm = 0;
+
+    if (atoi(state) == XenbusStateInitWait)
+        goto out_ok;
+
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    aorm->dev = dev;
+    libxl__ev_devstate_init(&aorm->ds);
+
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
+                                          PRIu32, dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        goto out_fail;
+    }
+
+    return 0;
+
+out_fail:
+    assert(rc);
+    device_add_cleanup(gc, aorm);
+    return rc;
+out_ok:
+    rc = libxl__device_hotplug(gc, dev, CONNECT);
+    libxl__ao_complete(egc, ao, 0);
+    return rc;
+}
+
+int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    char *pr_path = libxl__device_private_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, fe_path);
+    libxl__xs_path_cleanup(gc, pr_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
+    int i, j, events = 0, rc;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -481,11 +596,24 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                switch(rc) {
+                case 1:
+                    events++;
+                    break;
+                case 0:
+                    /* no events added */
+                    break;
+                default:
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Could not remove device "
+                                                      "%s", path);
+                }
             }
         }
     }
+    /* Check if any events were added */
+    if (!events)
+        libxl__ao_complete(egc, ao, 0);
 
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 15e24b9..4ce58f6 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -789,7 +789,7 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i], 0);
         if (ret)
             goto out_free;
     }
@@ -1047,7 +1047,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
+        ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
 
diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c
new file mode 100644
index 0000000..2eace0c
--- /dev/null
+++ b/tools/libxl/libxl_hotplug.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012
+ * Author Roger Pau Monne <roger.pau@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * Generic hotplug helpers
+ *
+ * This helpers are both used by Linux and NetBSD hotplug script
+ * dispatcher functions.
+ */
+
+static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status)
+{
+    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
+    EGC_GC;
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "hotplug child", pid, status);
+    }
+}
+
+int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
+{
+    int rc = 0;
+    pid_t pid = -1;
+    libxl__hotplug_state *hs;
+
+    hs = libxl__zalloc(gc, sizeof(*hs));
+
+    pid = libxl__ev_child_fork(gc, &hs->child, hotplug_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!pid) {
+        /* child */
+        signal(SIGCHLD, SIG_DFL);
+        libxl__exec(-1, -1, -1, arg0, args, env);
+    }
+out:
+    if (libxl__ev_child_inuse(&hs->child)) {
+        hs->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    return rc;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 020810a..95d5c40 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -464,6 +465,37 @@ _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
  */
 _hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);
 
+/*
+ * Hotplug handling
+ *
+ * Hotplug scripts are launched automatically by libxl at guest creation &
+ * shutdown/destroy.
+ */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+typedef struct libxl__hotplug_state libxl__hotplug_state;
+
+struct libxl__hotplug_state {
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+/*
+ * libxl__hotplug_exec is an internal function that should not be used
+ * directly, all hotplug script calls have to implement and use
+ * libxl__device_hotplug.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
+                                char **env);
 
 /*
  * Event generation functions provided by the libxl event core to the
@@ -743,13 +775,15 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+                             char **bents, char **fents, char **private);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_private_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao,
+                                   uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -772,6 +806,14 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 _hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
                                           libxl__device *dev);
 
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done, the ao will be completed. An error
+ * return from libxl__initiate_device_add means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_add(libxl__egc*, libxl__ao*,
+                                       libxl__device *dev);
+
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..7c107dc 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,120 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+/* Hotplug scripts helpers */
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    flexarray_t *f_env;
+    char **env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return NULL;
+    }
+
+    f_env = flexarray_make(9, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, script);
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+
+    flexarray_set(f_env, nr++, NULL);
+
+    env = (char **) flexarray_contents(f_env);
+
+    return env;
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    rc = libxl__hotplug_exec(gc, args[0], args, env);
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
+                                          "device %"PRIu32, dev->devid);
+        goto out_free;
+    }
+
+    rc = 0;
+
+out_free:
+    free(env);
+    free(args);
+    return rc;
+}
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index e8b8839..fd79d1d 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -103,8 +103,9 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
     libxl__device_generic_add(gc, &device,
-                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
+                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                            NULL);
 
 out:
     if (back)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..0bc3ac2 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1306,7 +1306,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1867,7 +1867,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2354,7 +2354,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2628,7 +2628,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -2861,7 +2861,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2979,7 +2979,7 @@ static void migrate_receive(int debug, int daemonize, int monitor)
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
@@ -5026,7 +5026,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index c4f7c52..ce7a2b2 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
     int domid;
     if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, NULL) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoR-00054O-G5; Fri, 20 Apr 2012 13:23:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoP-00053u-L9
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:45 +0000
Received: from [85.158.143.35:16768] by server-2.bemta-4.messagelabs.com id
	5B/1F-17550-063619F4; Fri, 20 Apr 2012 13:23:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11716 invoked from network); 20 Apr 2012 13:23:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363599"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Lq;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:27 +0100
Message-ID: <1334928211-29856-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 1/5] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..f0372d0 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index e25a767..15e24b9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -994,7 +994,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d524945..9e15f95 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -952,8 +952,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoR-00054O-G5; Fri, 20 Apr 2012 13:23:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoP-00053u-L9
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:45 +0000
Received: from [85.158.143.35:16768] by server-2.bemta-4.messagelabs.com id
	5B/1F-17550-063619F4; Fri, 20 Apr 2012 13:23:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11716 invoked from network); 20 Apr 2012 13:23:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363599"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Lq;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:27 +0100
Message-ID: <1334928211-29856-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 1/5] libxl: allow libxl__exec to take a
	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++--
 tools/libxl/libxl_dm.c         |    2 +-
 tools/libxl/libxl_exec.c       |    7 ++++++-
 tools/libxl/libxl_internal.h   |   13 ++++++++++++-
 5 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42ac89f..f0372d0 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1253,7 +1253,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..7120dad 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -113,12 +113,12 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index e25a767..15e24b9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -994,7 +994,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..be9e407 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -72,7 +72,7 @@ static void check_open_fds(const char *what)
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d524945..9e15f95 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -952,8 +952,19 @@ _hidden int libxl__spawn_check(libxl__gc *gc,
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
+/*
+ * env should be passed using the following format,
+ *
+ * env[0]: name of env variable
+ * env[1]: value of env variable
+ *
+ * So it efectively becomes something like:
+ * export env[0]=env[1]
+ *
+ * The last entry of the array always has to be NULL.
+ */
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoT-000555-Am; Fri, 20 Apr 2012 13:23:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDoR-00054N-Or
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:23:48 +0000
Received: from [85.158.143.35:16931] by server-1.bemta-4.messagelabs.com id
	3C/48-20925-363619F4; Fri, 20 Apr 2012 13:23:47 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334928221!12975581!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzYwMjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11814 invoked from network); 20 Apr 2012 13:23:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24363602"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-Qn;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:30 +0100
Message-ID: <1334928211-29856-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from libxl
	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the previous change already introduces most of needed machinery to call
hotplug scripts from libxl, this only adds the necessary bits to call this
scripts for vif interfaces also.

libxl_device_nic_add has been changed to make use of the new event
functionality, and the necessary vif hotplug code has been added. No changes
where needed in the teardown part, since it uses exactly the same code
introduced for vbd.

An exception has been introduced for tap devices, since hotplug scripts
should be called after the device model has been created, so the hotplug
call for those is done in do_domain_create after confirmation of the device
model startup. On the other hand, tap devices don't use teardown scripts,
so add another exception for that.

libxl__device_from_nic was moved to libxl_device.c, so it can be used
in libxl_create.c, and libxl__device_from_disk was also moved to maintain
the symmetry.

libxl__initiate_device_remove has been changed a little, to nuke the frontend
xenstore path before trying to perform device teardown, this allows for
uninitialized devices to be closed gracefully, specially vif interfaces added to
HVM machines and not used.

PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is
LIBXL_NIC_TYPE_IOEMU regardless of the guest type.

A new global option, called disable_vif_scripts has been added to allow the user
decide if he wants to execute the hotplug scripts from xl or from udev. This has
been documented in the xl.conf man page.

Changes since v2:

 * Added fancy functions to fetch tap and vif names, now the prefix of the tap
   device has been saved in a constant, called TAP_DEVICE_PREFIX.

 * Wait for timeout before nuking frontend xenstore entries.

 * Changed disable_vif_scripts to disable_xl_vif_scripts, it's easier to
   understand.

 * Default nic type set by libxl__device_nic_setdefault is VIF now (was IOEMU).

 * Save nic type and udev script exection inside
   /libxl/devices/<domid>/nic/<devid>/ instead of saving it in the backend path.

Changes since v1:

 * Propagated changes from previous patch (disable_udev and libxl_device_nic_add
   switch).

 * Modified udev rules to add the new env variable.

 * Added support for named interfaces.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5                |    7 ++
 tools/examples/xl.conf                |    3 +
 tools/hotplug/Linux/xen-backend.rules |    6 +-
 tools/libxl/libxl.c                   |  125 +++++++++++++-----------------
 tools/libxl/libxl.h                   |    3 +-
 tools/libxl/libxl_create.c            |   22 +++++-
 tools/libxl/libxl_device.c            |  122 +++++++++++++++++++++++++++--
 tools/libxl/libxl_dm.c                |    2 +-
 tools/libxl/libxl_internal.h          |   18 ++++-
 tools/libxl/libxl_linux.c             |  137 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_types.idl           |    1 +
 tools/libxl/xl.c                      |    4 +
 tools/libxl/xl.h                      |    1 +
 tools/libxl/xl_cmdimpl.c              |    8 ++-
 14 files changed, 369 insertions(+), 90 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8bd45ea..da8f16f 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,13 @@ default.
 
 Default: C<1>
 
+=item B<disable_xl_vif_scripts=BOOLEAN>
+
+If enabled xl will not execute nic hotplug scripts itself, and instead
+relegate this task to udev.
+
+Default: C<0>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..172ff80 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# default caller of hotplug scripts for vif interfaces
+#disable_xl_vif_scripts=0
diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 19f3d27..5dca574 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="emu*", ACTION=="add", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index eaa3095..11d3b3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1277,46 +1277,6 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
                           libxl_device_disk *disk,
                           const libxl_asyncop_how *ao_how)
@@ -1483,7 +1443,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
@@ -1838,29 +1798,17 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
                                   libxl_xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
-        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
-    return 0;
-}
-
-static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
-                                  libxl_device_nic *nic,
-                                  libxl__device *device)
-{
-    device->backend_devid    = nic->devid;
-    device->backend_domid    = nic->backend_domid;
-    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
-    device->devid            = nic->devid;
-    device->domid            = domid;
-    device->kind             = LIBXL__DEVICE_KIND_VIF;
-
+        nic->nictype = LIBXL_NIC_TYPE_VIF;
     return 0;
 }
 
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     flexarray_t *front;
     flexarray_t *back;
+    flexarray_t *private;
     libxl__device device;
     char *dompath, **l;
     unsigned int nb, rc;
@@ -1873,10 +1821,15 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         rc = ERROR_NOMEM;
         goto out;
     }
-    back = flexarray_make(16, 1);
+    back = flexarray_make(18, 1);
     if (!back) {
         rc = ERROR_NOMEM;
-        goto out_free;
+        goto out_free_f;
+    }
+    private = flexarray_make(4, 1);
+    if (!private) {
+        rc = ERROR_NOMEM;
+        goto out_free_b;
     }
 
     if (nic->devid == -1) {
@@ -1936,19 +1889,53 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
+
+    flexarray_append(private, "type");
+    flexarray_append(private, libxl__sprintf(gc, "%s", libxl_nic_type_to_string(
+                                                                nic->nictype)));
+    /* compatibility addon to keep udev rules */
+    if (!nic->disable_xl_vif_script) {
+        flexarray_append(private, "disable_udev");
+        flexarray_append(private, "y");
+    }
+
     libxl__device_generic_add(gc, &device,
-                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
-                            NULL);
+                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                    libxl__xs_kvs_of_flexarray(gc, private, private->count));
+
+    switch(nic->nictype) {
+    case LIBXL_NIC_TYPE_VIF:
+        if (!nic->disable_xl_vif_script) {
+            rc = libxl__initiate_device_add(egc, ao, &device);
+            if (rc) goto out_free;
+        } else {
+            libxl__ao_complete(egc, ao, 0);
+        }
+        break;
+    case LIBXL_NIC_TYPE_IOEMU:
+        /*
+         * Don't execute hotplug scripts for IOEMU interfaces yet,
+         * we need to launch the device model first.
+         * 
+         * This are actually launched from do_domain_create after the
+         * domain model has been started.
+        */
+    default:
+        libxl__ao_complete(egc, ao, 0);
+        break;
+    }
 
-    /* FIXME: wait for plug */
     rc = 0;
 out_free:
+    flexarray_free(private);
+out_free_b:
     flexarray_free(back);
+out_free_f:
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    if (rc) return AO_ABORT(rc);
+    return AO_INPROGRESS;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
@@ -1962,7 +1949,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
@@ -2322,7 +2309,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
@@ -2467,7 +2454,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(egc, ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device, 0);
     switch(rc) {
     case 1:
         /* event added */
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6687e2e..723c3aa 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -629,7 +629,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de598ad..023159b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -607,7 +607,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i], 0);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
@@ -685,6 +685,26 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                        "device model did not start: %d", ret);
             goto error_out;
         }
+        /* 
+         * Execute hotplug scripts for tap devices, this has to be done
+         * after the domain model has been started.
+        */
+        for (i = 0; i < d_config->num_vifs; i++) {
+            if (d_config->vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU &&
+                !d_config->vifs[i].disable_xl_vif_script) {
+                libxl__device device;
+                ret = libxl__device_from_nic(gc, domid, &d_config->vifs[i],
+                                             &device);
+                if (ret < 0) goto error_out;
+                ret = libxl__device_hotplug(gc, &device, CONNECT);
+                if (ret < 0) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                               "unable to launch hotplug script for device: "
+                               "%"PRIu32, device.devid);
+                    goto error_out;
+                }
+            }
+        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index aa19fab..7514290 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -47,6 +47,34 @@ char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
                           device->domid, device->devid);
 }
 
+char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_private_path(gc, dev);
+    char *ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                   be_path,
+                                                                   "vifname"));
+    if (!ifname) {
+        ifname = libxl__sprintf(gc, "vif%u.%d", dev->domid, dev->devid);
+    }
+
+    return ifname;
+}
+
+char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_private_path(gc, dev);
+    char *ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                   be_path,
+                                                                   "vifname"));
+    if (!ifname) {
+        ifname = libxl__sprintf(gc, TAP_DEVICE_PREFIX"%u.%d", dev->domid, dev->devid);
+    } else {
+        ifname = libxl__sprintf(gc, TAP_DEVICE_PREFIX"-%s", ifname);
+    }
+
+    return ifname;
+}
+
 int libxl__parse_backend_path(libxl__gc *gc,
                               const char *path,
                               libxl__device *dev)
@@ -269,6 +297,60 @@ char *libxl__device_disk_string_of_backend(libxl_disk_backend backend)
     }
 }
 
+int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                           libxl_device_nic *nic,
+                           libxl__device *device)
+{
+    device->backend_devid    = nic->devid;
+    device->backend_domid    = nic->backend_domid;
+    device->backend_kind     = LIBXL__DEVICE_KIND_VIF;
+    device->devid            = nic->devid;
+    device->domid            = domid;
+    device->kind             = LIBXL__DEVICE_KIND_VIF;
+
+    return 0;
+}
+
+int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                            libxl_device_disk *disk,
+                            libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
 int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor)
 {
     struct stat buf;
@@ -380,6 +462,7 @@ typedef struct {
     libxl__ao *ao;
     libxl__ev_devstate ds;
     libxl__device *dev;
+    int force;
 } libxl__ao_device_remove;
 
 typedef struct {
@@ -406,6 +489,16 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     libxl__gc *gc = &aorm->ao->gc;
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
+    if (rc == ERROR_TIMEDOUT && !aorm->force) {
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unable to remove device %"PRIu32
+                                            ", destroying frontend to force "
+                                            "backend disconnection",
+                                            aorm->dev->devid);
+        libxl__ev_devstate_cancel(gc, &aorm->ds);
+        libxl__initiate_device_remove(egc, aorm->ao, aorm->dev, 1);
+        return;
+    }
+
     rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
     if (rc)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for"
@@ -445,26 +538,34 @@ static void device_add_callback(libxl__egc *egc, libxl__ev_devstate *ds,
  * libxl__ao_complete when necessary (if no events are added).
  */
 int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
-                                  libxl__device *dev)
+                                  libxl__device *dev, int force)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
+    xs_transaction_t t = 0;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
     libxl__ao_device_remove *aorm = 0;
 
+    if (force)
+        libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
+        /*
+         * Nuke frontend to force backend teardown
+         * It's not pretty, but it's the only way that seems to work for all
+         * types of backends
+         */
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
     if (!state)
         goto out_ok;
-    if (atoi(state) != 4) {
+    if (atoi(state) == XenbusStateClosed)
         libxl__device_destroy_tapdisk(gc, be_path);
         goto out_ok;
-    }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -475,12 +576,15 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
     aorm = libxl__zalloc(gc, sizeof(*aorm));
     aorm->ao = ao;
     aorm->dev = dev;
+    aorm->force = force;
     libxl__ev_devstate_init(&aorm->ds);
 
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
@@ -496,8 +600,8 @@ retry_transaction:
     return rc;
 
  out_ok:
+    if (t) xs_transaction_end(ctx->xsh, t, 0);
     rc = libxl__device_hotplug(gc, dev, DISCONNECT);
-    libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, dev));
     libxl__xs_path_cleanup(gc, be_path);
     libxl__xs_path_cleanup(gc, libxl__device_private_path(gc, dev));
     return 0;
@@ -596,7 +700,7 @@ int libxl__devices_destroy(libxl__egc *egc, libxl__ao *ao, uint32_t domid)
                 dev.domid = domid;
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
-                rc = libxl__initiate_device_remove(egc, ao, &dev);
+                rc = libxl__initiate_device_remove(egc, ao, &dev, 0);
                 switch(rc) {
                 case 1:
                     events++;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4ce58f6..8cf9d9d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -794,7 +794,7 @@ retry_transaction:
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i], 0);
         if (ret)
             goto out_free;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 95d5c40..68c7514 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -84,6 +84,7 @@
 #define STUBDOM_CONSOLE_RESTORE 2
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
+#define TAP_DEVICE_PREFIX "emu"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -765,6 +766,12 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
 _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*);
+_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__device *device);
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                    libxl_device_disk *disk,
+                                    libxl__device *device);
 
 _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor);
 _hidden int libxl__device_disk_dev_number(const char *virtpath,
@@ -775,10 +782,13 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents, char **private);
+                                      char **bents, char **fents,
+                                      char **private);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
-_hidden char *libxl__device_private_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_private_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_vif_name(libxl__gc *gc, libxl__device *dev);
+_hidden char *libxl__device_tap_name(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
@@ -803,8 +813,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
-                                          libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                          libxl__device *dev, int force);
 
 /* Arranges that dev will be added to the guest, and the
  * hotplug scripts will be executed (if necessary). When
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 7c107dc..745a11a 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -27,6 +27,30 @@ int libxl__try_phy_backend(mode_t st_mode)
 }
 
 /* Hotplug scripts helpers */
+
+static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *snictype, *pr_path;
+    libxl_nic_type nictype;
+
+    pr_path = libxl__device_private_path(gc, dev);
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", pr_path, "type"));
+    if (!snictype) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read nictype from %s",
+                                          pr_path);
+        return -1;
+    }
+    if (libxl_nic_type_from_string(snictype, &nictype) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse nictype from %s",
+                                          pr_path);
+        return -1;
+    }
+
+    return nictype;
+}
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -44,7 +68,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    f_env = flexarray_make(9, 1);
+    f_env = flexarray_make(13, 1);
     if (!f_env) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "unable to create environment array");
@@ -63,6 +87,19 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
                   dev->domid, dev->devid));
     flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
     flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        switch (get_nic_type(gc, dev)) {
+        case LIBXL_NIC_TYPE_IOEMU:
+            flexarray_set(f_env, nr++, "INTERFACE");
+            flexarray_set(f_env, nr++, libxl__device_tap_name(gc, dev));
+        case LIBXL_NIC_TYPE_VIF:
+            flexarray_set(f_env, nr++, "vif");
+            flexarray_set(f_env, nr++, libxl__device_vif_name(gc, dev));
+            break;
+        default:
+            return NULL;
+        }
+    }
 
     flexarray_set(f_env, nr++, NULL);
 
@@ -126,6 +163,101 @@ out_free:
     return rc;
 }
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *what, *script;
+    char **args, **env;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+    flexarray_t *vif_args, *tap_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    nictype = get_nic_type(gc, dev);
+    if (nictype < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "error when fetching nic type");
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    vif_args = flexarray_make(4, 1);
+    if (!vif_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+    tap_args = flexarray_make(4, 1);
+    if (!tap_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    switch(nictype) {
+    case LIBXL_NIC_TYPE_IOEMU:
+        flexarray_set(tap_args, nr++, script);
+        flexarray_set(tap_args, nr++, action == CONNECT ? "add" : "remove");
+        flexarray_set(tap_args, nr++, libxl__sprintf(gc, "type_if=tap"));
+        flexarray_set(tap_args, nr++, NULL);
+        args = (char **) flexarray_contents(tap_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        free(args);
+        nr = 0;
+    case LIBXL_NIC_TYPE_VIF:
+        flexarray_set(vif_args, nr++, script);
+        flexarray_set(vif_args, nr++, action == CONNECT ? "online" : "offline");
+        flexarray_set(vif_args, nr++, libxl__sprintf(gc, "type_if=vif"));
+        flexarray_set(vif_args, nr++, NULL);
+        args = (char **) flexarray_contents(vif_args);
+        what = libxl__sprintf(gc, "%s %s", args[0],
+                              action == CONNECT ? "connect" : "disconnect");
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Calling hotplug script: %s %s %s",
+                   args[0], args[1], args[2]);
+        rc = libxl__hotplug_exec(gc, args[0], args, env);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts "
+                                              "for vif device %"PRIu32,
+                                              dev->devid);
+            goto out;
+        }
+        break;
+    default:
+        /* Unknown network type */
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "unknown network card type with "
+                                            "id %"PRIu32, dev->devid);
+        return 0;
+    }
+
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
@@ -135,6 +267,9 @@ int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
     case LIBXL__DEVICE_KIND_VBD:
         rc = libxl__hotplug_disk(gc, dev, action);
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
     default:
         rc = 0;
         break;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..0b2c832 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
     ("ifname", string),
     ("script", string),
     ("nictype", libxl_nic_type),
+    ("disable_xl_vif_script", integer),
     ])
 
 libxl_device_pci = Struct("device_pci", [
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..2f96468 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+int disable_xl_vif_scripts = 0;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    if (!xlu_cfg_get_long (config, "disable_xl_vif_scripts", &l, 0))
+        disable_xl_vif_scripts = l;
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..b60cd12 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -109,6 +109,7 @@ void postfork(void);
 
 /* global options */
 extern int autoballoon;
+extern int disable_xl_vif_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0bc3ac2..704d938 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -847,6 +847,12 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+            /*
+             * Disable nic network script calling, to allow the user
+             * to attach the nic backend from a different domain.
+             */
+            nic->disable_xl_vif_script = disable_xl_vif_scripts;
+
 	    if (default_bridge) {
 		free(nic->bridge);
 		nic->bridge = strdup(default_bridge);
@@ -4916,7 +4922,7 @@ int main_networkattach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:24:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:24:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoq-0005Ec-UN; Fri, 20 Apr 2012 13:24:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDop-0005Dr-5A
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:24:11 +0000
Received: from [85.158.143.35:27320] by server-2.bemta-4.messagelabs.com id
	70/CF-17550-A73619F4; Fri, 20 Apr 2012 13:24:10 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334928247!10897822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA2NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13937 invoked from network); 20 Apr 2012 13:24:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:24:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="191317262"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-RV;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:31 +0100
Message-ID: <1334928211-29856-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 5/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Changes since v1:

 * Indentation fixes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8cf9d9d..0f6c4cf 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,11 +216,18 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "nic,vlan=%d,macaddr=%s,model=%s",
+                                      vifs[i].devid, smac, vifs[i].model),
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
+                                      "script=%s,downscript=%s",
+                                      vifs[i].devid, ifname, vifs[i].bridge,
+                                      libxl_tapif_script(gc),
+                                      libxl_tapif_script(gc)),
+                                  NULL);
                 ioemu_vifs++;
             }
         }
@@ -462,10 +469,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].model, vifs[i].devid,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
-                flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
-                                                vifs[i].devid, ifname,
-                                                libxl_tapif_script(gc)));
+                flexarray_append(dm_args, libxl__sprintf(gc, 
+                                          "type=tap,id=net%d,ifname=%s,"
+                                          "script=%s,downscript=%s",
+                                          vifs[i].devid, ifname,
+                                          libxl_tapif_script(gc),
+                                          libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
         }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:24:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:24:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDoq-0005Ec-UN; Fri, 20 Apr 2012 13:24:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SLDop-0005Dr-5A
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:24:11 +0000
Received: from [85.158.143.35:27320] by server-2.bemta-4.messagelabs.com id
	70/CF-17550-A73619F4; Fri, 20 Apr 2012 13:24:10 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1334928247!10897822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA2NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13937 invoked from network); 20 Apr 2012 13:24:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:24:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="191317262"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 09:23:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 09:23:41 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SLDoK-0001oJ-RV;
	Fri, 20 Apr 2012 14:23:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 20 Apr 2012 14:23:31 +0100
Message-ID: <1334928211-29856-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 5/5] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Changes since v1:

 * Indentation fixes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8cf9d9d..0f6c4cf 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,11 +216,18 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "nic,vlan=%d,macaddr=%s,model=%s",
+                                      vifs[i].devid, smac, vifs[i].model),
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
+                                      "script=%s,downscript=%s",
+                                      vifs[i].devid, ifname, vifs[i].bridge,
+                                      libxl_tapif_script(gc),
+                                      libxl_tapif_script(gc)),
+                                  NULL);
                 ioemu_vifs++;
             }
         }
@@ -462,10 +469,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].model, vifs[i].devid,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
-                flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
-                                                vifs[i].devid, ifname,
-                                                libxl_tapif_script(gc)));
+                flexarray_append(dm_args, libxl__sprintf(gc, 
+                                          "type=tap,id=net%d,ifname=%s,"
+                                          "script=%s,downscript=%s",
+                                          vifs[i].devid, ifname,
+                                          libxl_tapif_script(gc),
+                                          libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
         }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDwv-00063I-2q; Fri, 20 Apr 2012 13:32:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLDwu-00063D-17
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:32:32 +0000
Received: from [193.109.254.147:29644] by server-10.bemta-14.messagelabs.com
	id 51/CF-05847-F65619F4; Fri, 20 Apr 2012 13:32:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334928720!5512405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32311 invoked from network); 20 Apr 2012 13:32:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:32:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12049238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:31:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:31:48 +0100
Date: Fri, 20 Apr 2012 14:36:59 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dan Carpenter <dan.carpenter@oracle.com>
In-Reply-To: <20120420113557.GJ27101@mwanda>
Message-ID: <alpine.DEB.2.00.1204201418400.26786@kaball-desktop>
References: <20120420105112.GA21487@elgon.mountain>
	<alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
	<20120420113557.GJ27101@mwanda>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Dan Carpenter wrote:
> On Fri, Apr 20, 2012 at 12:23:21PM +0100, Stefano Stabellini wrote:
> > On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > > Hi Stefano,
> > > 
> > > I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> > > list_for_each_entry_safe".
> > > 
> > > I think there is a misunderstanding about what the
> > > list_for_each_entry_safe() macro does.  It has nothing to do with
> > > locking, so the spinlock is still needed.  Without the lock ->next could
> > > point to an element which has been deleted in another thread.  Probably
> > > the patch should be reverted.
> > 
> > I thought that list_for_each_entry_safe is safe against deletion, is it
> > not?
> > It doesn't matter whether we get up to date entries or old entries
> > here as long as walking through the list doesn't break if a concurrent
> > thread adds or removes items.
> > 
> 
> It's safe against deletion in the same thread.  But not against
> deletion from another thread.
> 
> At the beginning of the loop it stores a pointer to the next
> element.  If you delete the element you are on, no problem because
> you already have a pointer to the next one.  But if another thread
> deletes the next element, now you have a pointer which is wrong.

The problem is not that the next element is wrong because we should be
able to cope with that.
The problem is that the next->next pointer would be set LIST_POISON1.

Maybe replacing our call to list_del with __list_del would be sufficient
to solve the problem?
Probably it is best to revert the patch at this stage.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDwv-00063I-2q; Fri, 20 Apr 2012 13:32:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLDwu-00063D-17
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:32:32 +0000
Received: from [193.109.254.147:29644] by server-10.bemta-14.messagelabs.com
	id 51/CF-05847-F65619F4; Fri, 20 Apr 2012 13:32:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1334928720!5512405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32311 invoked from network); 20 Apr 2012 13:32:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:32:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12049238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:31:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:31:48 +0100
Date: Fri, 20 Apr 2012 14:36:59 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dan Carpenter <dan.carpenter@oracle.com>
In-Reply-To: <20120420113557.GJ27101@mwanda>
Message-ID: <alpine.DEB.2.00.1204201418400.26786@kaball-desktop>
References: <20120420105112.GA21487@elgon.mountain>
	<alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
	<20120420113557.GJ27101@mwanda>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
	list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Dan Carpenter wrote:
> On Fri, Apr 20, 2012 at 12:23:21PM +0100, Stefano Stabellini wrote:
> > On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > > Hi Stefano,
> > > 
> > > I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> > > list_for_each_entry_safe".
> > > 
> > > I think there is a misunderstanding about what the
> > > list_for_each_entry_safe() macro does.  It has nothing to do with
> > > locking, so the spinlock is still needed.  Without the lock ->next could
> > > point to an element which has been deleted in another thread.  Probably
> > > the patch should be reverted.
> > 
> > I thought that list_for_each_entry_safe is safe against deletion, is it
> > not?
> > It doesn't matter whether we get up to date entries or old entries
> > here as long as walking through the list doesn't break if a concurrent
> > thread adds or removes items.
> > 
> 
> It's safe against deletion in the same thread.  But not against
> deletion from another thread.
> 
> At the beginning of the loop it stores a pointer to the next
> element.  If you delete the element you are on, no problem because
> you already have a pointer to the next one.  But if another thread
> deletes the next element, now you have a pointer which is wrong.

The problem is not that the next element is wrong because we should be
able to cope with that.
The problem is that the next->next pointer would be set LIST_POISON1.

Maybe replacing our call to list_del with __list_del would be sufficient
to solve the problem?
Probably it is best to revert the patch at this stage.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:33:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDxX-00065n-Gg; Fri, 20 Apr 2012 13:33:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDxW-00065b-D1
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:33:10 +0000
Received: from [85.158.143.99:50969] by server-2.bemta-4.messagelabs.com id
	4E/3F-17550-595619F4; Fri, 20 Apr 2012 13:33:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334928788!24213010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 20 Apr 2012 13:33:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:33:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12049278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:33:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 14:33:08 +0100
Message-ID: <1334928787.28331.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 20 Apr 2012 14:33:07 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [Fwd: [SeaBIOS] [ANNOUNCE] SeaBIOS 1.7.0]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I don't think we should consider switching to this new SeaBIOS version
for 4.2 now that we are in code freeze so I don't plan to propose doing
so (obviously ;-)).

Ian.

-------- Forwarded Message --------
From: Kevin O'Connor <kevin@koconnor.net>
To: seabios@seabios.org, qemu-devel@nongnu.org
Subject: [SeaBIOS] [ANNOUNCE] SeaBIOS 1.7.0
Date: Sat, 14 Apr 2012 22:48:55 -0400

The 1.7.0 version of SeaBIOS has now been released.  For more
information on the release, please see:

http://seabios.org/Releases


New in this release:

* Many enhancements to VGA BIOS code - it should now be feature complete with LGPL vgabios.
* Support for virtio-scsi.
* Improved USB drive (usb-msc) support.
* Several USB controller bug fixes and improvements.
* Runtime ACPI AML PCI hotplug construction.
* Support for running on i386 and i486 CPUs.
* Enhancements to PCI init when running on emulators.
* Several bug fixes


For information on obtaining SeaBIOS, please see:

http://seabios.org/Download

-Kevin

_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:33:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDxX-00065n-Gg; Fri, 20 Apr 2012 13:33:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLDxW-00065b-D1
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 13:33:10 +0000
Received: from [85.158.143.99:50969] by server-2.bemta-4.messagelabs.com id
	4E/3F-17550-595619F4; Fri, 20 Apr 2012 13:33:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334928788!24213010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 20 Apr 2012 13:33:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:33:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12049278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:33:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 14:33:08 +0100
Message-ID: <1334928787.28331.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 20 Apr 2012 14:33:07 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [Fwd: [SeaBIOS] [ANNOUNCE] SeaBIOS 1.7.0]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I don't think we should consider switching to this new SeaBIOS version
for 4.2 now that we are in code freeze so I don't plan to propose doing
so (obviously ;-)).

Ian.

-------- Forwarded Message --------
From: Kevin O'Connor <kevin@koconnor.net>
To: seabios@seabios.org, qemu-devel@nongnu.org
Subject: [SeaBIOS] [ANNOUNCE] SeaBIOS 1.7.0
Date: Sat, 14 Apr 2012 22:48:55 -0400

The 1.7.0 version of SeaBIOS has now been released.  For more
information on the release, please see:

http://seabios.org/Releases


New in this release:

* Many enhancements to VGA BIOS code - it should now be feature complete with LGPL vgabios.
* Support for virtio-scsi.
* Improved USB drive (usb-msc) support.
* Several USB controller bug fixes and improvements.
* Runtime ACPI AML PCI hotplug construction.
* Support for running on i386 and i486 CPUs.
* Enhancements to PCI init when running on emulators.
* Several bug fixes


For information on obtaining SeaBIOS, please see:

http://seabios.org/Download

-Kevin

_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:34:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:34:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDyH-0006Ak-Ub; Fri, 20 Apr 2012 13:33:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLDyG-0006AV-P4
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:33:56 +0000
Received: from [193.109.254.147:40666] by server-8.bemta-14.messagelabs.com id
	FD/7E-23244-4C5619F4; Fri, 20 Apr 2012 13:33:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334928835!3078965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16854 invoked from network); 20 Apr 2012 13:33:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:33:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12049295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:33:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:33:55 +0100
Date: Fri, 20 Apr 2012 14:39:06 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1204201437370.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"alevy@redhat.com" <alevy@redhat.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL BUILD FIX] build xc_hvm_inject_msi on Xen < 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony,
please pull:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git build_fix


this small patch series fixes the build breakage introduced by
f1dbf015dfb0aa7f66f710a1f1bc58b662951de2 with Xen < 4.2.

The problem is that xc_hvm_inject_msi is only defined from Xen 4.2
onwards so we need to provide a compatibility function for older Xen
versions.

Stefano Stabellini (2):
      xen,configure: detect Xen 4.2
      xen: add a dummy xc_hvm_inject_msi for Xen < 4.2

 configure       |   25 +++++++++++++++++++++++++
 hw/pc.c         |    2 +-
 hw/xen.h        |   10 ++++++++++
 hw/xen_common.h |   15 +++++++++++++++
 xen-all.c       |    2 +-
 5 files changed, 52 insertions(+), 2 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:34:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:34:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLDyH-0006Ak-Ub; Fri, 20 Apr 2012 13:33:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLDyG-0006AV-P4
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:33:56 +0000
Received: from [193.109.254.147:40666] by server-8.bemta-14.messagelabs.com id
	FD/7E-23244-4C5619F4; Fri, 20 Apr 2012 13:33:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1334928835!3078965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16854 invoked from network); 20 Apr 2012 13:33:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:33:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12049295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:33:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:33:55 +0100
Date: Fri, 20 Apr 2012 14:39:06 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1204201437370.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"alevy@redhat.com" <alevy@redhat.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PULL BUILD FIX] build xc_hvm_inject_msi on Xen < 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony,
please pull:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git build_fix


this small patch series fixes the build breakage introduced by
f1dbf015dfb0aa7f66f710a1f1bc58b662951de2 with Xen < 4.2.

The problem is that xc_hvm_inject_msi is only defined from Xen 4.2
onwards so we need to provide a compatibility function for older Xen
versions.

Stefano Stabellini (2):
      xen,configure: detect Xen 4.2
      xen: add a dummy xc_hvm_inject_msi for Xen < 4.2

 configure       |   25 +++++++++++++++++++++++++
 hw/pc.c         |    2 +-
 hw/xen.h        |   10 ++++++++++
 hw/xen_common.h |   15 +++++++++++++++
 xen-all.c       |    2 +-
 5 files changed, 52 insertions(+), 2 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:53:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEGs-0006gf-US; Fri, 20 Apr 2012 13:53:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEGq-0006ga-N8
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:53:08 +0000
Received: from [85.158.143.99:58666] by server-1.bemta-4.messagelabs.com id
	47/69-20925-44A619F4; Fri, 20 Apr 2012 13:53:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334929987!14912933!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 20 Apr 2012 13:53:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:53:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:53:06 +0100
Date: Fri, 20 Apr 2012 14:58:28 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.42906.867250.920616@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201458210.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42906.867250.920616@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/7] libxl:
 libxl__device_disk_local_attach return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
> > - make libxl_device_disk_local_attach/detach two internal functions;
> > 
> > - pass a gc rather than a ctx to them;
> > 
> > - introduce a new libxl_device_disk** parameter to
> > libxl__device_disk_local_attach, the parameter is allocated on the gc by
> > libxl__device_disk_local_attach. It is going to fill it with
> > informations about the new locally attached disk.  The new
> > libxl_device_disk should be passed to libxl_device_disk_local_detach
> > afterwards.
> 
> Mixing the changes up with teh code motion makes this quite hard to
> review.  Would it be easy to separate those out or should I do some
> kind of manual hack to compare the old and new code ?
 
I'll do that for you

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:53:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEGs-0006gf-US; Fri, 20 Apr 2012 13:53:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEGq-0006ga-N8
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:53:08 +0000
Received: from [85.158.143.99:58666] by server-1.bemta-4.messagelabs.com id
	47/69-20925-44A619F4; Fri, 20 Apr 2012 13:53:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334929987!14912933!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 20 Apr 2012 13:53:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:53:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:53:06 +0100
Date: Fri, 20 Apr 2012 14:58:28 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.42906.867250.920616@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201458210.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.42906.867250.920616@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/7] libxl:
 libxl__device_disk_local_attach return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 1/7] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
> > - make libxl_device_disk_local_attach/detach two internal functions;
> > 
> > - pass a gc rather than a ctx to them;
> > 
> > - introduce a new libxl_device_disk** parameter to
> > libxl__device_disk_local_attach, the parameter is allocated on the gc by
> > libxl__device_disk_local_attach. It is going to fill it with
> > informations about the new locally attached disk.  The new
> > libxl_device_disk should be passed to libxl_device_disk_local_detach
> > afterwards.
> 
> Mixing the changes up with teh code motion makes this quite hard to
> review.  Would it be easy to separate those out or should I do some
> kind of manual hack to compare the old and new code ?
 
I'll do that for you

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEIi-0006lo-Hp; Fri, 20 Apr 2012 13:55:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEIh-0006lf-97
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:55:03 +0000
Received: from [193.109.254.147:20804] by server-4.bemta-14.messagelabs.com id
	A9/7F-11570-6BA619F4; Fri, 20 Apr 2012 13:55:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334930101!5549519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7458 invoked from network); 20 Apr 2012 13:55:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:55:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:55:01 +0100
Date: Fri, 20 Apr 2012 15:00:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.43599.157767.127615@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201500170.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.43599.157767.127615@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/7] libxl: introduce
 libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 3/7] libxl: introduce libxl__device_disk_add_t"):
> > Introduce libxl__device_disk_add_t that takes an additional
> > xs_transaction_t paramter.
> > Implement libxl_device_disk_add using libxl__device_disk_add_t.
> > Move libxl__device_from_disk to libxl_internal.c.
> 
> Is this supposed to be "no functional change" ?  If so it would really
> help to say so.
 
yes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEIi-0006lo-Hp; Fri, 20 Apr 2012 13:55:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEIh-0006lf-97
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:55:03 +0000
Received: from [193.109.254.147:20804] by server-4.bemta-14.messagelabs.com id
	A9/7F-11570-6BA619F4; Fri, 20 Apr 2012 13:55:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334930101!5549519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7458 invoked from network); 20 Apr 2012 13:55:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:55:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:55:01 +0100
Date: Fri, 20 Apr 2012 15:00:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.43599.157767.127615@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201500170.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.43599.157767.127615@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/7] libxl: introduce
 libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 3/7] libxl: introduce libxl__device_disk_add_t"):
> > Introduce libxl__device_disk_add_t that takes an additional
> > xs_transaction_t paramter.
> > Implement libxl_device_disk_add using libxl__device_disk_add_t.
> > Move libxl__device_from_disk to libxl_internal.c.
> 
> Is this supposed to be "no functional change" ?  If so it would really
> help to say so.
 
yes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEME-0006xA-5w; Fri, 20 Apr 2012 13:58:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEMC-0006x0-EZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:58:40 +0000
Received: from [85.158.143.99:2869] by server-3.bemta-4.messagelabs.com id
	9B/46-05853-F8B619F4; Fri, 20 Apr 2012 13:58:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334930319!24217028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32299 invoked from network); 20 Apr 2012 13:58:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:58:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:58:39 +0100
Date: Fri, 20 Apr 2012 15:04:01 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.44206.42175.501006@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > Introduce a blkdev_start in xl.conf and pass it to
> > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > libxl__device_disk_local_attach.
> 
> Surely this should be passed in the domain config structure rather
> than being an adhoc parameter.

I don't think so, see below.

> If the problem with that is that it really ought to be host-global and
> come from xl.conf, then perhaps we need another config struct.  But
> really I think that's overkill.  There is nothing wrong with taking
> parameters from xl.conf and putting them in the libxl domain config.
 
Another host-global config struct is definitely overkill, but we cannot
really pass this parameter in the libxl domain config, because this
option has nothing to do with the domain config.
It would be confusing and incorrect.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 13:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 13:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEME-0006xA-5w; Fri, 20 Apr 2012 13:58:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEMC-0006x0-EZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 13:58:40 +0000
Received: from [85.158.143.99:2869] by server-3.bemta-4.messagelabs.com id
	9B/46-05853-F8B619F4; Fri, 20 Apr 2012 13:58:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1334930319!24217028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32299 invoked from network); 20 Apr 2012 13:58:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 13:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 13:58:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 14:58:39 +0100
Date: Fri, 20 Apr 2012 15:04:01 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.44206.42175.501006@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > Introduce a blkdev_start in xl.conf and pass it to
> > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > libxl__device_disk_local_attach.
> 
> Surely this should be passed in the domain config structure rather
> than being an adhoc parameter.

I don't think so, see below.

> If the problem with that is that it really ought to be host-global and
> come from xl.conf, then perhaps we need another config struct.  But
> really I think that's overkill.  There is nothing wrong with taking
> parameters from xl.conf and putting them in the libxl domain config.
 
Another host-global config struct is definitely overkill, but we cannot
really pass this parameter in the libxl domain config, because this
option has nothing to do with the domain config.
It would be confusing and incorrect.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:08:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEVW-0007Ch-FM; Fri, 20 Apr 2012 14:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLEVU-0007Cc-FH
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:08:16 +0000
Received: from [85.158.143.99:45068] by server-3.bemta-4.messagelabs.com id
	47/28-05853-FCD619F4; Fri, 20 Apr 2012 14:08:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334930894!19296257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31275 invoked from network); 20 Apr 2012 14:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:08:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 15:08:13 +0100
Message-ID: <1334930892.28331.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Apr 2012 15:08:12 +0100
In-Reply-To: <alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 15:04 +0100, Stefano Stabellini wrote:
> On Tue, 17 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > > Introduce a blkdev_start in xl.conf and pass it to
> > > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > > libxl__device_disk_local_attach.
> > 
> > Surely this should be passed in the domain config structure rather
> > than being an adhoc parameter.
> 
> I don't think so, see below.
> 
> > If the problem with that is that it really ought to be host-global and
> > come from xl.conf, then perhaps we need another config struct.  But
> > really I think that's overkill.  There is nothing wrong with taking
> > parameters from xl.conf and putting them in the libxl domain config.
>  
> Another host-global config struct is definitely overkill, but we cannot
> really pass this parameter in the libxl domain config, because this
> option has nothing to do with the domain config.
> It would be confusing and incorrect.

You could argue that "domain config" was actually as much about details
on how to build the guest as it was about the "domain config" as such.
Members of that struct like the device model version, xsm ssid, disable
migrate, cpupool id, etc could all be argued to fit into the same "grey
area".

In any case adding a new parameter for each global variable which a
function happens to need to look at is not a good API.

If you don't like domain config as a home for this then the "overkill"
option of a new config struct seems like a reasonable answer. It's
possible that it only seems like overkill now because we don't have many
of such things, but we might be thankful for it when we (inevitably)
have half a dozen.

Alternatively a variable in the ctx and functions to set/get it might
work, but that seems like a worse version of the global config struct to
me...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:08:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEVW-0007Ch-FM; Fri, 20 Apr 2012 14:08:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLEVU-0007Cc-FH
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:08:16 +0000
Received: from [85.158.143.99:45068] by server-3.bemta-4.messagelabs.com id
	47/28-05853-FCD619F4; Fri, 20 Apr 2012 14:08:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334930894!19296257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31275 invoked from network); 20 Apr 2012 14:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:08:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 15:08:13 +0100
Message-ID: <1334930892.28331.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Apr 2012 15:08:12 +0100
In-Reply-To: <alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 15:04 +0100, Stefano Stabellini wrote:
> On Tue, 17 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > > Introduce a blkdev_start in xl.conf and pass it to
> > > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > > libxl__device_disk_local_attach.
> > 
> > Surely this should be passed in the domain config structure rather
> > than being an adhoc parameter.
> 
> I don't think so, see below.
> 
> > If the problem with that is that it really ought to be host-global and
> > come from xl.conf, then perhaps we need another config struct.  But
> > really I think that's overkill.  There is nothing wrong with taking
> > parameters from xl.conf and putting them in the libxl domain config.
>  
> Another host-global config struct is definitely overkill, but we cannot
> really pass this parameter in the libxl domain config, because this
> option has nothing to do with the domain config.
> It would be confusing and incorrect.

You could argue that "domain config" was actually as much about details
on how to build the guest as it was about the "domain config" as such.
Members of that struct like the device model version, xsm ssid, disable
migrate, cpupool id, etc could all be argued to fit into the same "grey
area".

In any case adding a new parameter for each global variable which a
function happens to need to look at is not a good API.

If you don't like domain config as a home for this then the "overkill"
option of a new config struct seems like a reasonable answer. It's
possible that it only seems like overkill now because we don't have many
of such things, but we might be thankful for it when we (inevitably)
have half a dozen.

Alternatively a variable in the ctx and functions to set/get it might
work, but that seems like a worse version of the global config struct to
me...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEWE-0007GB-1M; Fri, 20 Apr 2012 14:09:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SLEWC-0007Fc-PZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:09:01 +0000
Received: from [193.109.254.147:2969] by server-5.bemta-14.messagelabs.com id
	5F/01-30733-CFD619F4; Fri, 20 Apr 2012 14:09:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334930938!5549329!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk1NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25593 invoked from network); 20 Apr 2012 14:08:59 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-14.tower-27.messagelabs.com with SMTP;
	20 Apr 2012 14:08:59 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 38587604076;
	Fri, 20 Apr 2012 07:08:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DZ+bqejBnvdHxJ14tg6pffj0bl7tdLYOxqikFn7cLN7e
	pEgG3toOsdle7EfI622MruL3fuO845RV4z/9zJonjzncDwlRSe4hfWbnWIqK+VJz
	Hs7KyTXtXw30zLhAX6hq9Dw/oL5M+W9//ZETpfRpT2WCpty5pVBgk+xKs0qO/EI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6bmji7ZbEfw+6CPULpQ5X5UXo44=; b=FwxVx2gr
	QZi8S4B+T3sly4EUzou6vdgCpv4Mu6wB2pqef2R71OONwoVkHdMDvr2RPWHLBeOj
	TUG8utdlKergSOPBS0fSL6o88ZUDDrz0PI1NliTGfu5wK0a/uJQezQmVkZNufzEs
	2wp16mvYaINIga/x6FoLAH8vxzafH6ifZOU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id A20DC604079; 
	Fri, 20 Apr 2012 07:08:57 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 20 Apr 2012 07:08:58 -0700
Message-ID: <260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1334925395.28331.61.camel@zakaz.uk.xensource.com>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
	<1334925395.28331.61.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 07:08:58 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
>> When mapping in large amounts of pages (in the GB range) from a guest
>> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc
>> client application. This is because the pfn array in
>> linux_privcmd_map_foreign_bulk() is being allocated using alloca() and
>> the subsequent memcpy causes the stack to blow. This patch replaces
>> the alloca() with mmap().
>
> The original reason for switching to alloca from malloc was because the
> similar gntmap path was a hot path and it seemed like if it was
> reasonable there it would be reasonable here too.
>
> So I have a couple of questions...
>
> Is it possible that we also introduced this same issue at the other
> callsites which were changed in that patch or are there other
> constraints on the size of the allocation which make it not a problem?

I don't know how arbitrary or large can the buffer sizes be in the other
callsites. It would seem that they can be large enough.
>
> Where does this mmap approach fall in terms of performance relative to
> just switching back to malloc? I presume that alloca is faster than
> both, but if it doesn't work reliably then it's not an option.

It's hard to dig out exactly how alloca is implemented, but it would seem
to simply move the stack pointer and return the old one (it's arguable
whether there is a buggy check for limits or a buggy lack of check against
the guard page going on -- man page says "behavior undefined"). So, if you
need new pages in the stack as a result of the stack pointer motion, those
pages will be demand allocated.

mmap just short circuits straight to page allocation. Note that malloc may
or may not wind up calling mmap if it needs more pages, depending on its
internal machinations.

MAP_POPULATE tells the mmap syscall to allocate right now, avoiding demand
allocation. Presumably this will batch all page allocations in the single
syscall, and avoid page faults down the line.

Short story, I suggested mmap with MAP_POPULATE because it will do the
allocation of pages in the most optimal fashion, even better than malloc
or alloca. But it's only worth if the buffer is big enough such that new
pages will need to be allocated.

I think a reasonable compromise would be to do alloca if the buffer is
less than one page (a fairly common case, single pfn buffers, etc), and do
mmap(MAP_POPULATE) for buffers larger than a page.

Andres

>
> If mmap and malloc have roughly equivalent performance properties, or
> the fast one is still too slow for Santosh's use case, then maybe we
> need to have a think about other options.
>
> e.g. use alloca for small numbers of mappings and mmap/malloc for larger
> ones. Or do large numbers of mappings in multiple batches.
>
> Ian.
>
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
>> +++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
>> @@ -39,6 +39,7 @@
>>  #include "xenctrl.h"
>>  #include "xenctrlosdep.h"
>>
>> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
>> ~((1UL<<(_w))-1))
>>  #define ERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>>  #define PERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
>> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
>>           * IOCTL_PRIVCMD_MMAPBATCH.
>>           */
>>          privcmd_mmapbatch_t ioctlx;
>> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
>> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
>> XC_PAGE_SHIFT),
>> +                              PROT_READ | PROT_WRITE,
>> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE,
>> -1, 0);
>> +        if ( pfn == MAP_FAILED )
>> +        {
>> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
>> +            return NULL;
>> +        }
>>
>>          memcpy(pfn, arr, num * sizeof(*arr));
>>
>> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
>>              break;
>>          }
>>
>> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
>> +
>>          if ( rc == -ENOENT && i == num )
>>              rc = 0;
>>          else if ( rc )
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEWE-0007GB-1M; Fri, 20 Apr 2012 14:09:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SLEWC-0007Fc-PZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:09:01 +0000
Received: from [193.109.254.147:2969] by server-5.bemta-14.messagelabs.com id
	5F/01-30733-CFD619F4; Fri, 20 Apr 2012 14:09:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1334930938!5549329!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk1NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25593 invoked from network); 20 Apr 2012 14:08:59 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-14.tower-27.messagelabs.com with SMTP;
	20 Apr 2012 14:08:59 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 38587604076;
	Fri, 20 Apr 2012 07:08:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DZ+bqejBnvdHxJ14tg6pffj0bl7tdLYOxqikFn7cLN7e
	pEgG3toOsdle7EfI622MruL3fuO845RV4z/9zJonjzncDwlRSe4hfWbnWIqK+VJz
	Hs7KyTXtXw30zLhAX6hq9Dw/oL5M+W9//ZETpfRpT2WCpty5pVBgk+xKs0qO/EI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6bmji7ZbEfw+6CPULpQ5X5UXo44=; b=FwxVx2gr
	QZi8S4B+T3sly4EUzou6vdgCpv4Mu6wB2pqef2R71OONwoVkHdMDvr2RPWHLBeOj
	TUG8utdlKergSOPBS0fSL6o88ZUDDrz0PI1NliTGfu5wK0a/uJQezQmVkZNufzEs
	2wp16mvYaINIga/x6FoLAH8vxzafH6ifZOU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id A20DC604079; 
	Fri, 20 Apr 2012 07:08:57 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 20 Apr 2012 07:08:58 -0700
Message-ID: <260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1334925395.28331.61.camel@zakaz.uk.xensource.com>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
	<1334925395.28331.61.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 07:08:58 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
>> When mapping in large amounts of pages (in the GB range) from a guest
>> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc
>> client application. This is because the pfn array in
>> linux_privcmd_map_foreign_bulk() is being allocated using alloca() and
>> the subsequent memcpy causes the stack to blow. This patch replaces
>> the alloca() with mmap().
>
> The original reason for switching to alloca from malloc was because the
> similar gntmap path was a hot path and it seemed like if it was
> reasonable there it would be reasonable here too.
>
> So I have a couple of questions...
>
> Is it possible that we also introduced this same issue at the other
> callsites which were changed in that patch or are there other
> constraints on the size of the allocation which make it not a problem?

I don't know how arbitrary or large can the buffer sizes be in the other
callsites. It would seem that they can be large enough.
>
> Where does this mmap approach fall in terms of performance relative to
> just switching back to malloc? I presume that alloca is faster than
> both, but if it doesn't work reliably then it's not an option.

It's hard to dig out exactly how alloca is implemented, but it would seem
to simply move the stack pointer and return the old one (it's arguable
whether there is a buggy check for limits or a buggy lack of check against
the guard page going on -- man page says "behavior undefined"). So, if you
need new pages in the stack as a result of the stack pointer motion, those
pages will be demand allocated.

mmap just short circuits straight to page allocation. Note that malloc may
or may not wind up calling mmap if it needs more pages, depending on its
internal machinations.

MAP_POPULATE tells the mmap syscall to allocate right now, avoiding demand
allocation. Presumably this will batch all page allocations in the single
syscall, and avoid page faults down the line.

Short story, I suggested mmap with MAP_POPULATE because it will do the
allocation of pages in the most optimal fashion, even better than malloc
or alloca. But it's only worth if the buffer is big enough such that new
pages will need to be allocated.

I think a reasonable compromise would be to do alloca if the buffer is
less than one page (a fairly common case, single pfn buffers, etc), and do
mmap(MAP_POPULATE) for buffers larger than a page.

Andres

>
> If mmap and malloc have roughly equivalent performance properties, or
> the fast one is still too slow for Santosh's use case, then maybe we
> need to have a think about other options.
>
> e.g. use alloca for small numbers of mappings and mmap/malloc for larger
> ones. Or do large numbers of mappings in multiple batches.
>
> Ian.
>
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
>> +++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
>> @@ -39,6 +39,7 @@
>>  #include "xenctrl.h"
>>  #include "xenctrlosdep.h"
>>
>> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
>> ~((1UL<<(_w))-1))
>>  #define ERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>>  #define PERROR(_m, _a...)
>> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
>> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
>>           * IOCTL_PRIVCMD_MMAPBATCH.
>>           */
>>          privcmd_mmapbatch_t ioctlx;
>> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
>> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
>> XC_PAGE_SHIFT),
>> +                              PROT_READ | PROT_WRITE,
>> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE,
>> -1, 0);
>> +        if ( pfn == MAP_FAILED )
>> +        {
>> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
>> +            return NULL;
>> +        }
>>
>>          memcpy(pfn, arr, num * sizeof(*arr));
>>
>> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
>>              break;
>>          }
>>
>> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
>> +
>>          if ( rc == -ENOENT && i == num )
>>              rc = 0;
>>          else if ( rc )
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:09:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEWZ-0007Kc-EQ; Fri, 20 Apr 2012 14:09:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEWX-0007KK-LT
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:09:21 +0000
Received: from [193.109.254.147:29572] by server-8.bemta-14.messagelabs.com id
	8C/0B-23244-01E619F4; Fri, 20 Apr 2012 14:09:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334930960!5501843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23378 invoked from network); 20 Apr 2012 14:09:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:09:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:09:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:09:20 +0100
Date: Fri, 20 Apr 2012 15:14:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.44544.739441.639648@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44544.739441.639648@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> > +        char *blkdev_start, xs_transaction_t t)
> > +{
> > +    int devid = 0;
> > +    char *vdev = libxl__strdup(gc, blkdev_start);
> > +    char *dompath = libxl__xs_get_dompath(gc, domid);
> > +
> > +    do {
> > +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> > +        if (libxl__xs_read(gc, t,
> > +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> > +                        dompath, devid)) == NULL)
> > +            return libxl__devid_to_vdev(gc, devid);
> 
> What if the error is not ENOENT ?

we should return NULL


> > +        vdev[strlen(vdev) - 1]++;
> > +    } while(vdev[strlen(vdev) - 1] <= 'z');
>               ^
> Missing whitespace.

OK

> > +_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);
> 
> I think the terminology here needs to be corrected.  "vdev" is the
> virtual device name supplied to libxl - a symbolic way of specifying a
> devid in a guest-independent way.
> 
> Whereas what we actually mean is the non-portable name in this guest
> OS for a device.  How about
>   libxl__devid_to_localdev
> ?

right, I think it would be a bit clearer

> 
> > +static char *encode_disk_name(char *ptr, unsigned int n)
> 
> There is no clearly defined upper bound on the buffer space needed by
> this function.

I know but this function is used as is in Linux where the stack is
even smaller. I'll add an upper bound anyway.


> > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> > index 9e0ed6d..c8977ac 100644
> > --- a/tools/libxl/libxl_netbsd.c
> > +++ b/tools/libxl/libxl_netbsd.c
> ...
> > +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> > +{
> > +    /* TODO */
> > +    return NULL;
> > +}
> 
> I guess this is going to be fixed in a future version of the patch ?

I don't think so: I don't know anything about netbsd and local_attach
doesn't work there anyway.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:09:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEWZ-0007Kc-EQ; Fri, 20 Apr 2012 14:09:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEWX-0007KK-LT
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:09:21 +0000
Received: from [193.109.254.147:29572] by server-8.bemta-14.messagelabs.com id
	8C/0B-23244-01E619F4; Fri, 20 Apr 2012 14:09:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1334930960!5501843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23378 invoked from network); 20 Apr 2012 14:09:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:09:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:09:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:09:20 +0100
Date: Fri, 20 Apr 2012 15:14:42 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.44544.739441.639648@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44544.739441.639648@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> > +        char *blkdev_start, xs_transaction_t t)
> > +{
> > +    int devid = 0;
> > +    char *vdev = libxl__strdup(gc, blkdev_start);
> > +    char *dompath = libxl__xs_get_dompath(gc, domid);
> > +
> > +    do {
> > +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> > +        if (libxl__xs_read(gc, t,
> > +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> > +                        dompath, devid)) == NULL)
> > +            return libxl__devid_to_vdev(gc, devid);
> 
> What if the error is not ENOENT ?

we should return NULL


> > +        vdev[strlen(vdev) - 1]++;
> > +    } while(vdev[strlen(vdev) - 1] <= 'z');
>               ^
> Missing whitespace.

OK

> > +_hidden char *libxl__devid_to_vdev(libxl__gc *gc, int devid);
> 
> I think the terminology here needs to be corrected.  "vdev" is the
> virtual device name supplied to libxl - a symbolic way of specifying a
> devid in a guest-independent way.
> 
> Whereas what we actually mean is the non-portable name in this guest
> OS for a device.  How about
>   libxl__devid_to_localdev
> ?

right, I think it would be a bit clearer

> 
> > +static char *encode_disk_name(char *ptr, unsigned int n)
> 
> There is no clearly defined upper bound on the buffer space needed by
> this function.

I know but this function is used as is in Linux where the stack is
even smaller. I'll add an upper bound anyway.


> > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> > index 9e0ed6d..c8977ac 100644
> > --- a/tools/libxl/libxl_netbsd.c
> > +++ b/tools/libxl/libxl_netbsd.c
> ...
> > +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> > +{
> > +    /* TODO */
> > +    return NULL;
> > +}
> 
> I guess this is going to be fixed in a future version of the patch ?

I don't think so: I don't know anything about netbsd and local_attach
doesn't work there anyway.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:15:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEcR-0007qg-AZ; Fri, 20 Apr 2012 14:15:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLEcP-0007qZ-5l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:15:25 +0000
Received: from [85.158.138.51:19400] by server-12.bemta-3.messagelabs.com id
	9C/18-29760-C7F619F4; Fri, 20 Apr 2012 14:15:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334931323!18985623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23991 invoked from network); 20 Apr 2012 14:15:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:15:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 15:15:23 +0100
Message-ID: <1334931321.28331.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Fri, 20 Apr 2012 15:15:21 +0100
In-Reply-To: <260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
	<1334925395.28331.61.camel@zakaz.uk.xensource.com>
	<260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 15:08 +0100, Andres Lagar-Cavilla wrote:
> > On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
> >> When mapping in large amounts of pages (in the GB range) from a guest
> >> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc
> >> client application. This is because the pfn array in
> >> linux_privcmd_map_foreign_bulk() is being allocated using alloca() and
> >> the subsequent memcpy causes the stack to blow. This patch replaces
> >> the alloca() with mmap().
> >
> > The original reason for switching to alloca from malloc was because the
> > similar gntmap path was a hot path and it seemed like if it was
> > reasonable there it would be reasonable here too.
> >
> > So I have a couple of questions...
> >
> > Is it possible that we also introduced this same issue at the other
> > callsites which were changed in that patch or are there other
> > constraints on the size of the allocation which make it not a problem?
> 
> I don't know how arbitrary or large can the buffer sizes be in the other
> callsites. It would seem that they can be large enough.
> >
> > Where does this mmap approach fall in terms of performance relative to
> > just switching back to malloc? I presume that alloca is faster than
> > both, but if it doesn't work reliably then it's not an option.
> 
> It's hard to dig out exactly how alloca is implemented, but it would seem
> to simply move the stack pointer and return the old one (it's arguable
> whether there is a buggy check for limits or a buggy lack of check against
> the guard page going on -- man page says "behavior undefined"). So, if you
> need new pages in the stack as a result of the stack pointer motion, those
> pages will be demand allocated.
> 
> mmap just short circuits straight to page allocation. Note that malloc may
> or may not wind up calling mmap if it needs more pages, depending on its
> internal machinations.
> 
> MAP_POPULATE tells the mmap syscall to allocate right now, avoiding demand
> allocation. Presumably this will batch all page allocations in the single
> syscall, and avoid page faults down the line.
> 
> Short story, I suggested mmap with MAP_POPULATE because it will do the
> allocation of pages in the most optimal fashion, even better than malloc
> or alloca. But it's only worth if the buffer is big enough such that new
> pages will need to be allocated.

I think in these cases the whole buffer will always be used, since they
are sized precisely for what they need to contain.

> I think a reasonable compromise would be to do alloca if the buffer is
> less than one page (a fairly common case, single pfn buffers, etc), and do
> mmap(MAP_POPULATE) for buffers larger than a page.

I agree.

Ian.

> 
> Andres
> 
> >
> > If mmap and malloc have roughly equivalent performance properties, or
> > the fast one is still too slow for Santosh's use case, then maybe we
> > need to have a think about other options.
> >
> > e.g. use alloca for small numbers of mappings and mmap/malloc for larger
> > ones. Or do large numbers of mappings in multiple batches.
> >
> > Ian.
> >
> >>
> >> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>
> >> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
> >> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
> >> +++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
> >> @@ -39,6 +39,7 @@
> >>  #include "xenctrl.h"
> >>  #include "xenctrlosdep.h"
> >>
> >> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
> >> ~((1UL<<(_w))-1))
> >>  #define ERROR(_m, _a...)
> >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
> >>  #define PERROR(_m, _a...)
> >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
> >>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> >> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
> >>           * IOCTL_PRIVCMD_MMAPBATCH.
> >>           */
> >>          privcmd_mmapbatch_t ioctlx;
> >> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> >> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
> >> XC_PAGE_SHIFT),
> >> +                              PROT_READ | PROT_WRITE,
> >> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE,
> >> -1, 0);
> >> +        if ( pfn == MAP_FAILED )
> >> +        {
> >> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> >> +            return NULL;
> >> +        }
> >>
> >>          memcpy(pfn, arr, num * sizeof(*arr));
> >>
> >> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
> >>              break;
> >>          }
> >>
> >> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
> >> +
> >>          if ( rc == -ENOENT && i == num )
> >>              rc = 0;
> >>          else if ( rc )
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >
> >
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:15:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEcR-0007qg-AZ; Fri, 20 Apr 2012 14:15:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLEcP-0007qZ-5l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:15:25 +0000
Received: from [85.158.138.51:19400] by server-12.bemta-3.messagelabs.com id
	9C/18-29760-C7F619F4; Fri, 20 Apr 2012 14:15:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1334931323!18985623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23991 invoked from network); 20 Apr 2012 14:15:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:15:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 15:15:23 +0100
Message-ID: <1334931321.28331.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Fri, 20 Apr 2012 15:15:21 +0100
In-Reply-To: <260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
	<1334925395.28331.61.camel@zakaz.uk.xensource.com>
	<260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
 linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 15:08 +0100, Andres Lagar-Cavilla wrote:
> > On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
> >> When mapping in large amounts of pages (in the GB range) from a guest
> >> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc
> >> client application. This is because the pfn array in
> >> linux_privcmd_map_foreign_bulk() is being allocated using alloca() and
> >> the subsequent memcpy causes the stack to blow. This patch replaces
> >> the alloca() with mmap().
> >
> > The original reason for switching to alloca from malloc was because the
> > similar gntmap path was a hot path and it seemed like if it was
> > reasonable there it would be reasonable here too.
> >
> > So I have a couple of questions...
> >
> > Is it possible that we also introduced this same issue at the other
> > callsites which were changed in that patch or are there other
> > constraints on the size of the allocation which make it not a problem?
> 
> I don't know how arbitrary or large can the buffer sizes be in the other
> callsites. It would seem that they can be large enough.
> >
> > Where does this mmap approach fall in terms of performance relative to
> > just switching back to malloc? I presume that alloca is faster than
> > both, but if it doesn't work reliably then it's not an option.
> 
> It's hard to dig out exactly how alloca is implemented, but it would seem
> to simply move the stack pointer and return the old one (it's arguable
> whether there is a buggy check for limits or a buggy lack of check against
> the guard page going on -- man page says "behavior undefined"). So, if you
> need new pages in the stack as a result of the stack pointer motion, those
> pages will be demand allocated.
> 
> mmap just short circuits straight to page allocation. Note that malloc may
> or may not wind up calling mmap if it needs more pages, depending on its
> internal machinations.
> 
> MAP_POPULATE tells the mmap syscall to allocate right now, avoiding demand
> allocation. Presumably this will batch all page allocations in the single
> syscall, and avoid page faults down the line.
> 
> Short story, I suggested mmap with MAP_POPULATE because it will do the
> allocation of pages in the most optimal fashion, even better than malloc
> or alloca. But it's only worth if the buffer is big enough such that new
> pages will need to be allocated.

I think in these cases the whole buffer will always be used, since they
are sized precisely for what they need to contain.

> I think a reasonable compromise would be to do alloca if the buffer is
> less than one page (a fairly common case, single pfn buffers, etc), and do
> mmap(MAP_POPULATE) for buffers larger than a page.

I agree.

Ian.

> 
> Andres
> 
> >
> > If mmap and malloc have roughly equivalent performance properties, or
> > the fast one is still too slow for Santosh's use case, then maybe we
> > need to have a think about other options.
> >
> > e.g. use alloca for small numbers of mappings and mmap/malloc for larger
> > ones. Or do large numbers of mappings in multiple batches.
> >
> > Ian.
> >
> >>
> >> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>
> >> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
> >> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
> >> +++ b/tools/libxc/xc_linux_osdep.c	Thu Apr 19 15:21:43 2012 -0700
> >> @@ -39,6 +39,7 @@
> >>  #include "xenctrl.h"
> >>  #include "xenctrlosdep.h"
> >>
> >> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
> >> ~((1UL<<(_w))-1))
> >>  #define ERROR(_m, _a...)
> >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
> >>  #define PERROR(_m, _a...)
> >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
> >>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> >> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
> >>           * IOCTL_PRIVCMD_MMAPBATCH.
> >>           */
> >>          privcmd_mmapbatch_t ioctlx;
> >> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> >> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
> >> XC_PAGE_SHIFT),
> >> +                              PROT_READ | PROT_WRITE,
> >> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE,
> >> -1, 0);
> >> +        if ( pfn == MAP_FAILED )
> >> +        {
> >> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> >> +            return NULL;
> >> +        }
> >>
> >>          memcpy(pfn, arr, num * sizeof(*arr));
> >>
> >> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
> >>              break;
> >>          }
> >>
> >> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
> >> +
> >>          if ( rc == -ENOENT && i == num )
> >>              rc = 0;
> >>          else if ( rc )
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >
> >
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEgW-0007yb-01; Fri, 20 Apr 2012 14:19:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEgV-0007yV-9e
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:19:39 +0000
Received: from [85.158.138.51:62731] by server-1.bemta-3.messagelabs.com id
	03/4B-11491-A70719F4; Fri, 20 Apr 2012 14:19:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334931577!23094803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32240 invoked from network); 20 Apr 2012 14:19:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:19:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:19:37 +0100
Date: Fri, 20 Apr 2012 15:24:59 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.44862.597858.180770@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44862.597858.180770@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Could you please avoid to remove so much context from your quotes? It
makes it very hard for me to read your emails.


On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> ...
> > +                    t = xs_transaction_start(ctx->xsh);
> 
> This transaction should be in the local variables block for the whole
> function, and initialised to 0.

I don't think I understand what you mean.
Do you mean moving xs_transaction_start outside the switch?
If so, why? It doesn't affect many of the other cases.


> > +                    /* use 0 as the domid of the toolstack domain for now */
> > +                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);
> 
> Should this 0 be abstracted into a #define or a variable ?

Yes, good idea.


> > +                    if (tmpdisk->vdev == NULL) {
> > +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                                "libxl__alloc_vdev failed\n");
> > +                        xs_transaction_end(ctx->xsh, t, 1);
> 
> And then all these xs_transaction_end calls turn into one call in the
> exit path.

So maybe you do mean moving the transaction outside the switch.
In that case I disagree: the transaction is only useful in a very
limited set of cases (just one at the moment), while most of the others
don't need it.


> > +                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);
> 
> Perhaps you'd like to use GCSPRINTF now that we have it.
> 
> >              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
> > -                       disk->pdev_path);
> 
> Perhaps you'd like to use LOG(DEBUG, ....") now that we have it ?
> 
> > -            dev = tmpdisk->pdev_path;
> > +    switch (disk->backend) {
> > +        case LIBXL_DISK_BACKEND_QDISK:
> > +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> 
> This replicates the logic earlier, which decided whether to use a
> qdisk.  I think it would be better to remember whether we did use a
> qdisk and detach it iff so.
 
There are cases in which we do use qdisk but we don't have to detach.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEgW-0007yb-01; Fri, 20 Apr 2012 14:19:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEgV-0007yV-9e
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:19:39 +0000
Received: from [85.158.138.51:62731] by server-1.bemta-3.messagelabs.com id
	03/4B-11491-A70719F4; Fri, 20 Apr 2012 14:19:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1334931577!23094803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32240 invoked from network); 20 Apr 2012 14:19:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12050908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:19:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:19:37 +0100
Date: Fri, 20 Apr 2012 15:24:59 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.44862.597858.180770@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44862.597858.180770@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Could you please avoid to remove so much context from your quotes? It
makes it very hard for me to read your emails.


On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> ...
> > +                    t = xs_transaction_start(ctx->xsh);
> 
> This transaction should be in the local variables block for the whole
> function, and initialised to 0.

I don't think I understand what you mean.
Do you mean moving xs_transaction_start outside the switch?
If so, why? It doesn't affect many of the other cases.


> > +                    /* use 0 as the domid of the toolstack domain for now */
> > +                    tmpdisk->vdev = libxl__alloc_vdev(gc, 0, blkdev_start, t);
> 
> Should this 0 be abstracted into a #define or a variable ?

Yes, good idea.


> > +                    if (tmpdisk->vdev == NULL) {
> > +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                                "libxl__alloc_vdev failed\n");
> > +                        xs_transaction_end(ctx->xsh, t, 1);
> 
> And then all these xs_transaction_end calls turn into one call in the
> exit path.

So maybe you do mean moving the transaction outside the switch.
In that case I disagree: the transaction is only useful in a very
limited set of cases (just one at the moment), while most of the others
don't need it.


> > +                dev = libxl__sprintf(gc, "/dev/%s", tmpdisk->vdev);
> 
> Perhaps you'd like to use GCSPRINTF now that we have it.
> 
> >              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
> > -                       disk->pdev_path);
> 
> Perhaps you'd like to use LOG(DEBUG, ....") now that we have it ?
> 
> > -            dev = tmpdisk->pdev_path;
> > +    switch (disk->backend) {
> > +        case LIBXL_DISK_BACKEND_QDISK:
> > +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> 
> This replicates the logic earlier, which decided whether to use a
> qdisk.  I think it would be better to remember whether we did use a
> qdisk and detach it iff so.
 
There are cases in which we do use qdisk but we don't have to detach.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:26:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEmn-00089K-TJ; Fri, 20 Apr 2012 14:26:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLEmm-00089F-RZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:26:09 +0000
Received: from [85.158.143.35:36429] by server-2.bemta-4.messagelabs.com id
	18/14-17550-002719F4; Fri, 20 Apr 2012 14:26:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334931967!17064235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10750 invoked from network); 20 Apr 2012 14:26:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:26:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:26:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:26:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLEjF-0001s9-GF; Fri, 20 Apr 2012 14:22:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLEjF-0005QB-FA;
	Fri, 20 Apr 2012 15:22:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.28965.454380.66771@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 15:22:29 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> On Tue, 17 Apr 2012, Ian Jackson wrote:
...
> > If the problem with that is that it really ought to be host-global and
> > come from xl.conf, then perhaps we need another config struct.  But
> > really I think that's overkill.  There is nothing wrong with taking
> > parameters from xl.conf and putting them in the libxl domain config.
>  
> Another host-global config struct is definitely overkill, but we cannot
> really pass this parameter in the libxl domain config, because this
> option has nothing to do with the domain config.
> It would be confusing and incorrect.

It's a parameter used during the domain setup.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:26:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEmn-00089K-TJ; Fri, 20 Apr 2012 14:26:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLEmm-00089F-RZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:26:09 +0000
Received: from [85.158.143.35:36429] by server-2.bemta-4.messagelabs.com id
	18/14-17550-002719F4; Fri, 20 Apr 2012 14:26:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1334931967!17064235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10750 invoked from network); 20 Apr 2012 14:26:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:26:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:26:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:26:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLEjF-0001s9-GF; Fri, 20 Apr 2012 14:22:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLEjF-0005QB-FA;
	Fri, 20 Apr 2012 15:22:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.28965.454380.66771@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 15:22:29 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> On Tue, 17 Apr 2012, Ian Jackson wrote:
...
> > If the problem with that is that it really ought to be host-global and
> > come from xl.conf, then perhaps we need another config struct.  But
> > really I think that's overkill.  There is nothing wrong with taking
> > parameters from xl.conf and putting them in the libxl domain config.
>  
> Another host-global config struct is definitely overkill, but we cannot
> really pass this parameter in the libxl domain config, because this
> option has nothing to do with the domain config.
> It would be confusing and incorrect.

It's a parameter used during the domain setup.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:29:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEpc-0008FH-Fw; Fri, 20 Apr 2012 14:29:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLEpa-0008F9-Jd
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:29:02 +0000
Received: from [85.158.138.51:56519] by server-5.bemta-3.messagelabs.com id
	9C/67-17113-DA2719F4; Fri, 20 Apr 2012 14:29:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334932140!18707750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2958 invoked from network); 20 Apr 2012 14:29:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:29:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:29:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLEpX-0001ud-Ms; Fri, 20 Apr 2012 14:28:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLEpX-0005Qi-M5;
	Fri, 20 Apr 2012 15:28:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.29355.670145.159299@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 15:28:59 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44544.739441.639648@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> On Tue, 17 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > > +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> > > +        if (libxl__xs_read(gc, t,
> > > +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> > > +                        dompath, devid)) == NULL)
> > > +            return libxl__devid_to_vdev(gc, devid);
> > 
> > What if the error is not ENOENT ?
> 
> we should return NULL

I don't think that's correct.  If, say, the error is EACCES, then the
domain creation should be aborted with a message about that, since the
system has been installed incorrectly.

Compare this situation with the recent pygrub failure, where
libfsimage+pygrub turned all errors of the form "something went wrong
loading this plugin" into "the kernel was not found"; so when a
completely empty .so was loaded as a plugin the result was not "OMG
WTF this is totally broken" but "sorry can't find your kernel in this
filesystem" (when really the problem is that pygrub+libfsimage knew
that the filesystem was one they were supposed to support but the
plugin for it was utterly broken).

This reminds me of our other recent discussion about error handling,
of receiving unexpected toolstack migration info.  In general any
unanticipated situation should be treated as a fatal error.  Only
anticipated situations should result in the software continuing in a
degraded manner.

> > > +static char *encode_disk_name(char *ptr, unsigned int n)
> > 
> > There is no clearly defined upper bound on the buffer space needed by
> > this function.
> 
> I know but this function is used as is in Linux where the stack is
> even smaller. I'll add an upper bound anyway.

At the very least a comment is needed to demonstrate that it's
correct, but a bound in the code would be better.  (Also I'm surprised
that you chose a recursive rather than iterative implementation of a
what is a base conversion routine...)

> > > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> > > index 9e0ed6d..c8977ac 100644
> > > --- a/tools/libxl/libxl_netbsd.c
> > > +++ b/tools/libxl/libxl_netbsd.c
> > ...
> > > +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> > > +{
> > > +    /* TODO */
> > > +    return NULL;
> > > +}
> > 
> > I guess this is going to be fixed in a future version of the patch ?
> 
> I don't think so: I don't know anything about netbsd and local_attach
> doesn't work there anyway.

What is the error behaviour if NULL is returned here ?  I forget the
rest of the patch, but once again we should make sure that we abort if
this situation occurs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:29:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEpc-0008FH-Fw; Fri, 20 Apr 2012 14:29:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLEpa-0008F9-Jd
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:29:02 +0000
Received: from [85.158.138.51:56519] by server-5.bemta-3.messagelabs.com id
	9C/67-17113-DA2719F4; Fri, 20 Apr 2012 14:29:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334932140!18707750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2958 invoked from network); 20 Apr 2012 14:29:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:29:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:29:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLEpX-0001ud-Ms; Fri, 20 Apr 2012 14:28:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLEpX-0005Qi-M5;
	Fri, 20 Apr 2012 15:28:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.29355.670145.159299@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 15:28:59 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44544.739441.639648@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> On Tue, 17 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > > +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> > > +        if (libxl__xs_read(gc, t,
> > > +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> > > +                        dompath, devid)) == NULL)
> > > +            return libxl__devid_to_vdev(gc, devid);
> > 
> > What if the error is not ENOENT ?
> 
> we should return NULL

I don't think that's correct.  If, say, the error is EACCES, then the
domain creation should be aborted with a message about that, since the
system has been installed incorrectly.

Compare this situation with the recent pygrub failure, where
libfsimage+pygrub turned all errors of the form "something went wrong
loading this plugin" into "the kernel was not found"; so when a
completely empty .so was loaded as a plugin the result was not "OMG
WTF this is totally broken" but "sorry can't find your kernel in this
filesystem" (when really the problem is that pygrub+libfsimage knew
that the filesystem was one they were supposed to support but the
plugin for it was utterly broken).

This reminds me of our other recent discussion about error handling,
of receiving unexpected toolstack migration info.  In general any
unanticipated situation should be treated as a fatal error.  Only
anticipated situations should result in the software continuing in a
degraded manner.

> > > +static char *encode_disk_name(char *ptr, unsigned int n)
> > 
> > There is no clearly defined upper bound on the buffer space needed by
> > this function.
> 
> I know but this function is used as is in Linux where the stack is
> even smaller. I'll add an upper bound anyway.

At the very least a comment is needed to demonstrate that it's
correct, but a bound in the code would be better.  (Also I'm surprised
that you chose a recursive rather than iterative implementation of a
what is a base conversion routine...)

> > > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> > > index 9e0ed6d..c8977ac 100644
> > > --- a/tools/libxl/libxl_netbsd.c
> > > +++ b/tools/libxl/libxl_netbsd.c
> > ...
> > > +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> > > +{
> > > +    /* TODO */
> > > +    return NULL;
> > > +}
> > 
> > I guess this is going to be fixed in a future version of the patch ?
> 
> I don't think so: I don't know anything about netbsd and local_attach
> doesn't work there anyway.

What is the error behaviour if NULL is returned here ?  I forget the
rest of the patch, but once again we should make sure that we abort if
this situation occurs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:30:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:30:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEqp-0008M0-4q; Fri, 20 Apr 2012 14:30:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEqo-0008Lo-GT
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:30:18 +0000
Received: from [85.158.138.51:18088] by server-7.bemta-3.messagelabs.com id
	55/6C-03078-9F2719F4; Fri, 20 Apr 2012 14:30:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334932216!21252852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6755 invoked from network); 20 Apr 2012 14:30:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:30:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:30:16 +0100
Date: Fri, 20 Apr 2012 15:35:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.45076.153077.759249@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201532230.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.45076.153077.759249@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach:
 wait for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach: wait for state "connected""):
> > In order to make sure that the block device is available and ready to be
> > used, wait for state "connected" in the backend before returning.
> ...
> > +        be_path = libxl__device_backend_path(gc, &device);
> > +        rc = libxl__wait_for_backend(gc, be_path, "4");
> 
> Ideally we shouldn't be introducing new calls to functions called
> "libxl__wait_for".  Although I appreciate you may not want to convert
> libxl__device_disk_local_attach and all its callers to use callbacks.

Indeed.

> > +        if (rc < 0) {
> > +            libxl__device_disk_local_detach(gc, tmpdisk);
> > +            return NULL;
> 
> Again, this is the "free something on every exit path" error handling
> style.  Surely we should have a "goto out" or "goto out_err" or
> something ?
 
Yep, I'll do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:30:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:30:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLEqp-0008M0-4q; Fri, 20 Apr 2012 14:30:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLEqo-0008Lo-GT
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:30:18 +0000
Received: from [85.158.138.51:18088] by server-7.bemta-3.messagelabs.com id
	55/6C-03078-9F2719F4; Fri, 20 Apr 2012 14:30:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1334932216!21252852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6755 invoked from network); 20 Apr 2012 14:30:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:30:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:30:16 +0100
Date: Fri, 20 Apr 2012 15:35:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20365.45076.153077.759249@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201532230.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.45076.153077.759249@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach:
 wait for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 17 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v3 7/7] libxl__device_disk_local_attach: wait for state "connected""):
> > In order to make sure that the block device is available and ready to be
> > used, wait for state "connected" in the backend before returning.
> ...
> > +        be_path = libxl__device_backend_path(gc, &device);
> > +        rc = libxl__wait_for_backend(gc, be_path, "4");
> 
> Ideally we shouldn't be introducing new calls to functions called
> "libxl__wait_for".  Although I appreciate you may not want to convert
> libxl__device_disk_local_attach and all its callers to use callbacks.

Indeed.

> > +        if (rc < 0) {
> > +            libxl__device_disk_local_detach(gc, tmpdisk);
> > +            return NULL;
> 
> Again, this is the "free something on every exit path" error handling
> style.  Surely we should have a "goto out" or "goto out_err" or
> something ?
 
Yep, I'll do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:37:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLExT-0000Ah-0V; Fri, 20 Apr 2012 14:37:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLExR-0000AZ-QP
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:37:10 +0000
Received: from [85.158.143.99:19916] by server-2.bemta-4.messagelabs.com id
	C7/64-17550-594719F4; Fri, 20 Apr 2012 14:37:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334932627!24503263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9145 invoked from network); 20 Apr 2012 14:37:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:37:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:37:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLExN-0001xI-JL; Fri, 20 Apr 2012 14:37:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLExN-0005R5-IU;
	Fri, 20 Apr 2012 15:37:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.29841.410190.50222@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 15:37:05 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44862.597858.180770@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> On Tue, 17 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> > ...
> > > +                    t = xs_transaction_start(ctx->xsh);
> > 
> > This transaction should be in the local variables block for the whole
> > function, and initialised to 0.
> 
> I don't think I understand what you mean.
> Do you mean moving xs_transaction_start outside the switch?
> If so, why? It doesn't affect many of the other cases.

No, I mean that the variable should be defined at the top of the
function and initialised to 0.

In general, any resource allocated in a function other than from the
gc should be held in a variable set and used like "resource" in this
example:

  int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
  {

      foo *resource = 0;
      int rc;

      blah blah blah;

      resource = xmumble_acquire_resource(wibble wombat);
      if (!resource) { rc = ERROR_FAIL; goto out; }

      blah blah blah;

      rc = 0;

    out:
      xmumble_free_resource(resource);
      return rc;
  }

> > > +                    if (tmpdisk->vdev == NULL) {
> > > +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > > +                                "libxl__alloc_vdev failed\n");
> > > +                        xs_transaction_end(ctx->xsh, t, 1);
> > 
> > And then all these xs_transaction_end calls turn into one call in the
> > exit path.
> 
> So maybe you do mean moving the transaction outside the switch.
> In that case I disagree: the transaction is only useful in a very
> limited set of cases (just one at the moment), while most of the others
> don't need it.

No, I mean only the calls which abort the transaction should be in the
"goto out" section.

So:

  int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
  {

      xs_transaction_t our_trans;
      int rc;

      blah blah blah;

      for (;;) {
          our_trans = xs_transaction_start(...);
          if (!our_trans) { rc = ERROR_FAIL; goto out; }

          blah blah blah;

          r = xs_transaction_end(CTX->xsh, our_trans, 0);
          our_trans = 0; /* it's ended either way */
          if (r shows it was successful) break;
          if (r not as expected) { rc = ERROR_FAIL; goto out; }
      }

      blah blah blah;

      rc = 0;

    out:
      if (our_trans) xs_transaction_end(CTX->xsh, our_trans, 1);
      return rc;
  }

The point is that the following invariant is maintained: we have a
transaction open, which needs to be ended, iff !!our_trans.

> > > -            dev = tmpdisk->pdev_path;
> > > +    switch (disk->backend) {
> > > +        case LIBXL_DISK_BACKEND_QDISK:
> > > +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> > 
> > This replicates the logic earlier, which decided whether to use a
> > qdisk.  I think it would be better to remember whether we did use a
> > qdisk and detach it iff so.
>  
> There are cases in which we do use qdisk but we don't have to detach.

I'm not sure I follow.  This is the attachment of the VM's disk for
the benefit of the bootloader.  When we are done with running the
bootloader we need to clean it up.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:37:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLExT-0000Ah-0V; Fri, 20 Apr 2012 14:37:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLExR-0000AZ-QP
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:37:10 +0000
Received: from [85.158.143.99:19916] by server-2.bemta-4.messagelabs.com id
	C7/64-17550-594719F4; Fri, 20 Apr 2012 14:37:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334932627!24503263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9145 invoked from network); 20 Apr 2012 14:37:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 14:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12051434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 14:37:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 15:37:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SLExN-0001xI-JL; Fri, 20 Apr 2012 14:37:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SLExN-0005R5-IU;
	Fri, 20 Apr 2012 15:37:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20369.29841.410190.50222@mariner.uk.xensource.com>
Date: Fri, 20 Apr 2012 15:37:05 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44862.597858.180770@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> On Tue, 17 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> > ...
> > > +                    t = xs_transaction_start(ctx->xsh);
> > 
> > This transaction should be in the local variables block for the whole
> > function, and initialised to 0.
> 
> I don't think I understand what you mean.
> Do you mean moving xs_transaction_start outside the switch?
> If so, why? It doesn't affect many of the other cases.

No, I mean that the variable should be defined at the top of the
function and initialised to 0.

In general, any resource allocated in a function other than from the
gc should be held in a variable set and used like "resource" in this
example:

  int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
  {

      foo *resource = 0;
      int rc;

      blah blah blah;

      resource = xmumble_acquire_resource(wibble wombat);
      if (!resource) { rc = ERROR_FAIL; goto out; }

      blah blah blah;

      rc = 0;

    out:
      xmumble_free_resource(resource);
      return rc;
  }

> > > +                    if (tmpdisk->vdev == NULL) {
> > > +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > > +                                "libxl__alloc_vdev failed\n");
> > > +                        xs_transaction_end(ctx->xsh, t, 1);
> > 
> > And then all these xs_transaction_end calls turn into one call in the
> > exit path.
> 
> So maybe you do mean moving the transaction outside the switch.
> In that case I disagree: the transaction is only useful in a very
> limited set of cases (just one at the moment), while most of the others
> don't need it.

No, I mean only the calls which abort the transaction should be in the
"goto out" section.

So:

  int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
  {

      xs_transaction_t our_trans;
      int rc;

      blah blah blah;

      for (;;) {
          our_trans = xs_transaction_start(...);
          if (!our_trans) { rc = ERROR_FAIL; goto out; }

          blah blah blah;

          r = xs_transaction_end(CTX->xsh, our_trans, 0);
          our_trans = 0; /* it's ended either way */
          if (r shows it was successful) break;
          if (r not as expected) { rc = ERROR_FAIL; goto out; }
      }

      blah blah blah;

      rc = 0;

    out:
      if (our_trans) xs_transaction_end(CTX->xsh, our_trans, 1);
      return rc;
  }

The point is that the following invariant is maintained: we have a
transaction open, which needs to be ended, iff !!our_trans.

> > > -            dev = tmpdisk->pdev_path;
> > > +    switch (disk->backend) {
> > > +        case LIBXL_DISK_BACKEND_QDISK:
> > > +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> > 
> > This replicates the logic earlier, which decided whether to use a
> > qdisk.  I think it would be better to remember whether we did use a
> > qdisk and detach it iff so.
>  
> There are cases in which we do use qdisk but we don't have to detach.

I'm not sure I follow.  This is the attachment of the VM's disk for
the benefit of the bootloader.  When we are done with running the
bootloader we need to clean it up.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:51:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:51:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFBC-0000xU-Qr; Fri, 20 Apr 2012 14:51:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLFBB-0000xO-H5
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:51:21 +0000
Received: from [85.158.138.51:15769] by server-10.bemta-3.messagelabs.com id
	19/19-29478-8E7719F4; Fri, 20 Apr 2012 14:51:20 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334933478!18711614!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4377 invoked from network); 20 Apr 2012 14:51:19 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-6.tower-174.messagelabs.com with SMTP;
	20 Apr 2012 14:51:19 -0000
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com
	[209.85.212.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 71367DF903
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 22:51:04 +0800 (CST)
Received: by vbbfq11 with SMTP id fq11so7748822vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 07:50:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.228 with SMTP id fb4mr4421467vdb.62.1334933457168; Fri,
	20 Apr 2012 07:50:57 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Fri, 20 Apr 2012 07:50:57 -0700 (PDT)
In-Reply-To: <1334927566.28331.80.camel@zakaz.uk.xensource.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 22:50:57 +0800
Message-ID: <CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
>> >
>> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
>> > appropriate/
>>
>> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
>> be -EPERM).
>
> So either the guest has called a hypercall which it is not permitted to
> or it has called it with invalid parameters of one sort or another. Both
> of these would be a code bug in the guest and therefore asserting that
> no failure occurred is reasonable?
>
> What could the caller do with the error other than log it and collapse?
>
>> The call into Xen itself will return 0 as a value if an
>> invalid physbase is passed in the hypercall.
>
>> So a BUG_ON() is not safe/sensible for domU.
>
> I think you have successfully argued that it is ;-)

BUG_ON is too severe. How about WARN_ON?

ret = hypercall(...)

if (ret) {
   WARN_ON(1);
   return -1;
}


>
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:51:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:51:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFBC-0000xU-Qr; Fri, 20 Apr 2012 14:51:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLFBB-0000xO-H5
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:51:21 +0000
Received: from [85.158.138.51:15769] by server-10.bemta-3.messagelabs.com id
	19/19-29478-8E7719F4; Fri, 20 Apr 2012 14:51:20 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334933478!18711614!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4377 invoked from network); 20 Apr 2012 14:51:19 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-6.tower-174.messagelabs.com with SMTP;
	20 Apr 2012 14:51:19 -0000
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com
	[209.85.212.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 71367DF903
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 22:51:04 +0800 (CST)
Received: by vbbfq11 with SMTP id fq11so7748822vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 07:50:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.228 with SMTP id fb4mr4421467vdb.62.1334933457168; Fri,
	20 Apr 2012 07:50:57 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Fri, 20 Apr 2012 07:50:57 -0700 (PDT)
In-Reply-To: <1334927566.28331.80.camel@zakaz.uk.xensource.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 22:50:57 +0800
Message-ID: <CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
>> >
>> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
>> > appropriate/
>>
>> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
>> be -EPERM).
>
> So either the guest has called a hypercall which it is not permitted to
> or it has called it with invalid parameters of one sort or another. Both
> of these would be a code bug in the guest and therefore asserting that
> no failure occurred is reasonable?
>
> What could the caller do with the error other than log it and collapse?
>
>> The call into Xen itself will return 0 as a value if an
>> invalid physbase is passed in the hypercall.
>
>> So a BUG_ON() is not safe/sensible for domU.
>
> I think you have successfully argued that it is ;-)

BUG_ON is too severe. How about WARN_ON?

ret = hypercall(...)

if (ret) {
   WARN_ON(1);
   return -1;
}


>
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:59:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFIp-0001FM-S0; Fri, 20 Apr 2012 14:59:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SLFIo-0001FH-9s
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:59:14 +0000
Received: from [85.158.143.99:48867] by server-3.bemta-4.messagelabs.com id
	32/87-05853-1C9719F4; Fri, 20 Apr 2012 14:59:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334933952!18180897!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6043 invoked from network); 20 Apr 2012 14:59:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 14:59:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 15:59:12 +0100
Message-Id: <4F9195DE020000780007EEB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 15:59:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
In-Reply-To: <CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 16:50, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
>>> >
>>> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
>>> > appropriate/
>>>
>>> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
>>> be -EPERM).
>>
>> So either the guest has called a hypercall which it is not permitted to
>> or it has called it with invalid parameters of one sort or another. Both
>> of these would be a code bug in the guest and therefore asserting that
>> no failure occurred is reasonable?
>>
>> What could the caller do with the error other than log it and collapse?
>>
>>> The call into Xen itself will return 0 as a value if an
>>> invalid physbase is passed in the hypercall.
>>
>>> So a BUG_ON() is not safe/sensible for domU.
>>
>> I think you have successfully argued that it is ;-)
> 
> BUG_ON is too severe. How about WARN_ON?
> 
> ret = hypercall(...)
> 
> if (ret) {
>    WARN_ON(1);
>    return -1;
> }

But if you go with this, please use the more modern

if (WARN_ON(ret))
	return -1;

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 14:59:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 14:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFIp-0001FM-S0; Fri, 20 Apr 2012 14:59:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SLFIo-0001FH-9s
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 14:59:14 +0000
Received: from [85.158.143.99:48867] by server-3.bemta-4.messagelabs.com id
	32/87-05853-1C9719F4; Fri, 20 Apr 2012 14:59:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334933952!18180897!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6043 invoked from network); 20 Apr 2012 14:59:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 14:59:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Apr 2012 15:59:12 +0100
Message-Id: <4F9195DE020000780007EEB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Apr 2012 15:59:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lin Ming" <mlin@ss.pku.edu.cn>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
In-Reply-To: <CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 16:50, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
>>> >
>>> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
>>> > appropriate/
>>>
>>> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
>>> be -EPERM).
>>
>> So either the guest has called a hypercall which it is not permitted to
>> or it has called it with invalid parameters of one sort or another. Both
>> of these would be a code bug in the guest and therefore asserting that
>> no failure occurred is reasonable?
>>
>> What could the caller do with the error other than log it and collapse?
>>
>>> The call into Xen itself will return 0 as a value if an
>>> invalid physbase is passed in the hypercall.
>>
>>> So a BUG_ON() is not safe/sensible for domU.
>>
>> I think you have successfully argued that it is ;-)
> 
> BUG_ON is too severe. How about WARN_ON?
> 
> ret = hypercall(...)
> 
> if (ret) {
>    WARN_ON(1);
>    return -1;
> }

But if you go with this, please use the more modern

if (WARN_ON(ret))
	return -1;

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:02:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFLy-0001Vv-4E; Fri, 20 Apr 2012 15:02:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SLFLw-0001Vi-7h
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:02:28 +0000
Received: from [85.158.138.51:26988] by server-11.bemta-3.messagelabs.com id
	BD/3D-18894-38A719F4; Fri, 20 Apr 2012 15:02:27 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334934144!22928247!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15065 invoked from network); 20 Apr 2012 15:02:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 15:02:26 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KF2KtV016678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 15:02:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KF2JtM001055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 15:02:19 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KF2JHG018460; Fri, 20 Apr 2012 10:02:19 -0500
MIME-Version: 1.0
Message-ID: <699116fb-992a-4ce2-8071-9bb7d6e43645@default>
Date: Fri, 20 Apr 2012 08:02:16 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>, Boris Ostrovsky
	<boris.ostrovsky@amd.com>, JBeulich@suse.com
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<CBB6D76E.31192%keir.xen@gmail.com>
In-Reply-To: <CBB6D76E.31192%keir.xen@gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F917A7D.0081,ss=1,re=0.000,fgs=0
Cc: wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by
> hardware
> 
> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
> 
> > # HG changeset patch
> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> > # Date 1334875170 14400
> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> >
> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> > Acked-by: Wei Huang <wei.huang2@amd.com>
> > Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> possible cross-CPU TSC skew.

Provided the hypervisor writes the "TSC-scale-register" with the same
value when any vcpu for any guest is scheduled, I don't think
there is any cross-CPU TSC skew.

But my recollection is that I had a concern that, to work properly
after migration, TSC scaling might need to implement:

	((B + cur_tsc) * scale ) + A

and AFAIK the feature only implements this for B==0.
Without the rest of the implementation in the hypervisor
and tools, it's hard to determine whether my concern is valid
or not.

Also, I don't recall the exact scaling process but
was also concerned that a guest kernel or userland
process approximating the passage of time by counting
TSC cycles, they might just estimate the value once at
boot (or application startup) and, due to the scaling,
post-migration ticks/second might later change enough
to be a problem.  However, this
is a generic problem with emulation as well, so the
concern is really: Does the TSC scaling use the same
multiplication precision as is available to emulation
in the hypervisor?

Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:02:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFLy-0001Vv-4E; Fri, 20 Apr 2012 15:02:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SLFLw-0001Vi-7h
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:02:28 +0000
Received: from [85.158.138.51:26988] by server-11.bemta-3.messagelabs.com id
	BD/3D-18894-38A719F4; Fri, 20 Apr 2012 15:02:27 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334934144!22928247!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15065 invoked from network); 20 Apr 2012 15:02:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 15:02:26 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KF2KtV016678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 15:02:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KF2JtM001055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 15:02:19 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KF2JHG018460; Fri, 20 Apr 2012 10:02:19 -0500
MIME-Version: 1.0
Message-ID: <699116fb-992a-4ce2-8071-9bb7d6e43645@default>
Date: Fri, 20 Apr 2012 08:02:16 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>, Boris Ostrovsky
	<boris.ostrovsky@amd.com>, JBeulich@suse.com
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<CBB6D76E.31192%keir.xen@gmail.com>
In-Reply-To: <CBB6D76E.31192%keir.xen@gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F917A7D.0081,ss=1,re=0.000,fgs=0
Cc: wei.huang2@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by
> hardware
> 
> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
> 
> > # HG changeset patch
> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> > # Date 1334875170 14400
> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> >
> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> > Acked-by: Wei Huang <wei.huang2@amd.com>
> > Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> possible cross-CPU TSC skew.

Provided the hypervisor writes the "TSC-scale-register" with the same
value when any vcpu for any guest is scheduled, I don't think
there is any cross-CPU TSC skew.

But my recollection is that I had a concern that, to work properly
after migration, TSC scaling might need to implement:

	((B + cur_tsc) * scale ) + A

and AFAIK the feature only implements this for B==0.
Without the rest of the implementation in the hypervisor
and tools, it's hard to determine whether my concern is valid
or not.

Also, I don't recall the exact scaling process but
was also concerned that a guest kernel or userland
process approximating the passage of time by counting
TSC cycles, they might just estimate the value once at
boot (or application startup) and, due to the scaling,
post-migration ticks/second might later change enough
to be a problem.  However, this
is a generic problem with emulation as well, so the
concern is really: Does the TSC scaling use the same
multiplication precision as is available to emulation
in the hypervisor?

Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFPZ-0001qj-Fq; Fri, 20 Apr 2012 15:06:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLFPY-0001qY-1l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:06:12 +0000
Received: from [85.158.143.35:15263] by server-1.bemta-4.messagelabs.com id
	49/E7-20925-36B719F4; Fri, 20 Apr 2012 15:06:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334934369!9785076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11258 invoked from network); 20 Apr 2012 15:06:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:06:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:06:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 16:06:09 +0100
Message-ID: <1334934367.28331.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Fri, 20 Apr 2012 16:06:07 +0100
In-Reply-To: <CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
References: <1334913957.2863.1.camel@hp6530s>	<4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 15:50 +0100, Lin Ming wrote:
> On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> >> >
> >> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> >> > appropriate/
> >>
> >> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> >> be -EPERM).
> >
> > So either the guest has called a hypercall which it is not permitted to
> > or it has called it with invalid parameters of one sort or another. Both
> > of these would be a code bug in the guest and therefore asserting that
> > no failure occurred is reasonable?
> >
> > What could the caller do with the error other than log it and collapse?
> >
> >> The call into Xen itself will return 0 as a value if an
> >> invalid physbase is passed in the hypercall.
> >
> >> So a BUG_ON() is not safe/sensible for domU.
> >
> > I think you have successfully argued that it is ;-)
> 
> BUG_ON is too severe.

Why? Under what circumstances can this be correctly called in a way
which would result in the hypercall failing?

>  How about WARN_ON?
> 
> ret = hypercall(...)
> 
> if (ret) {
>    WARN_ON(1);
>    return -1;
> }
> 
> 
> >
> > Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFPZ-0001qj-Fq; Fri, 20 Apr 2012 15:06:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLFPY-0001qY-1l
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:06:12 +0000
Received: from [85.158.143.35:15263] by server-1.bemta-4.messagelabs.com id
	49/E7-20925-36B719F4; Fri, 20 Apr 2012 15:06:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334934369!9785076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11258 invoked from network); 20 Apr 2012 15:06:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:06:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:06:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 16:06:09 +0100
Message-ID: <1334934367.28331.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Date: Fri, 20 Apr 2012 16:06:07 +0100
In-Reply-To: <CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
References: <1334913957.2863.1.camel@hp6530s>	<4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 15:50 +0100, Lin Ming wrote:
> On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> >> >
> >> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> >> > appropriate/
> >>
> >> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> >> be -EPERM).
> >
> > So either the guest has called a hypercall which it is not permitted to
> > or it has called it with invalid parameters of one sort or another. Both
> > of these would be a code bug in the guest and therefore asserting that
> > no failure occurred is reasonable?
> >
> > What could the caller do with the error other than log it and collapse?
> >
> >> The call into Xen itself will return 0 as a value if an
> >> invalid physbase is passed in the hypercall.
> >
> >> So a BUG_ON() is not safe/sensible for domU.
> >
> > I think you have successfully argued that it is ;-)
> 
> BUG_ON is too severe.

Why? Under what circumstances can this be correctly called in a way
which would result in the hypercall failing?

>  How about WARN_ON?
> 
> ret = hypercall(...)
> 
> if (ret) {
>    WARN_ON(1);
>    return -1;
> }
> 
> 
> >
> > Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:06:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFQ1-0001uF-Ta; Fri, 20 Apr 2012 15:06:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SLFPz-0001to-Oy
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:06:39 +0000
Received: from [85.158.143.99:37581] by server-1.bemta-4.messagelabs.com id
	5D/78-20925-F7B719F4; Fri, 20 Apr 2012 15:06:39 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334934398!19286973!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25622 invoked from network); 20 Apr 2012 15:06:38 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 15:06:38 -0000
Received: from mail109-am1-R.bigfish.com (10.3.201.236) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:06:37 +0000
Received: from mail109-am1 (localhost [127.0.0.1])	by
	mail109-am1-R.bigfish.com (Postfix) with ESMTP id C3DBD4C03B2;
	Fri, 20 Apr 2012 15:06:37 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI9371I542M1432N98dKzz1202hzz8275bhz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail109-am1 (localhost.localdomain [127.0.0.1]) by mail109-am1
	(MessageSwitch) id 1334934396810650_21643;
	Fri, 20 Apr 2012 15:06:36 +0000 (UTC)
Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.239])	by
	mail109-am1.bigfish.com (Postfix) with ESMTP id C0A8CA0077;
	Fri, 20 Apr 2012 15:06:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:06:30 +0000
X-WSS-ID: 0M2S9YS-01-A6D-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22DA6102816E;	Fri, 20 Apr 2012 10:06:27 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Apr 2012 10:06:46 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag05.amd.com ([fe80::40a5:9a38:e465:3002%15]) with mapi id
	14.01.0323.003; Fri, 20 Apr 2012 10:06:27 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: Keir Fraser <keir@xen.org>, "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>, 
	"JBeulich@suse.com" <JBeulich@suse.com>, Dan Magenheimer
	<dan.magenheimer@oracle.com>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: AQHNHpxPkEb3eUjtQUKe3vtM5npR3pajr2UAgAACbgCAAB6WgA==
Date: Fri, 20 Apr 2012 15:06:26 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090DFB9E@sausexdag02.amd.com>
References: <CBB6D76E.31192%keir.xen@gmail.com> <CBB6D978.3E843%keir@xen.org>
In-Reply-To: <CBB6D978.3E843%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.236.71.106]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Keir,

This patch is a bug fix for 23437:d7c755c25bb9 than new feature. It slipped my hand and Boris fixed it for me. The same applies to Xen-4.1.

===== Changeset 23437 =====

HVM/SVM: enable tsc scaling ratio for SVM

Future AMD CPUs support TSC scaling. It allows guests to have a
different TSC frequency from host system using this formula: guest_tsc
= host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR
contains a fixed-point number in 8.32 format (8 bits for integer part
and 32bits for fractional part). For instance 0x00000003_80000000
means tsc_ratio=3.5.

This patch enables TSC scaling ratio for SVM. With it, guest VMs don't
need take #VMEXIT to calculate a translated TSC value when it is
running under TSC emulation mode. This can substancially reduce the
rdtsc overhead.


-Wei

-----Original Message-----
From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
Sent: Friday, April 20, 2012 3:15 AM
To: Ostrovsky, Boris; JBeulich@suse.com; Dan Magenheimer
Cc: Huang2, Wei; xen-devel@lists.xensource.com
Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

On 20/04/2012 09:05, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
> 
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1334875170 14400
>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> 
>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> Acked-by: Wei Huang <wei.huang2@amd.com>
>> Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> possible cross-CPU TSC skew.

Oh, and apart from that, we're also in feature freeze for 4.2, and this
isn't a bug fix. Similarly, it's not really a candidate for the stable 4.1
branch either, at any time.

 -- Keir

>  -- Keir
> 
>> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
>> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
>> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
>> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>>  {
>>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>>  
>>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
>> -    if ( enable )
>> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
>> +
>> +    if ( enable && !cpu_has_tsc_ratio ) {
>>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
>> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
>> +    }
>>  
>>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
>> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>>  }
>>  
>>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
>> 
> 
> 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:06:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFQ1-0001uF-Ta; Fri, 20 Apr 2012 15:06:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SLFPz-0001to-Oy
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:06:39 +0000
Received: from [85.158.143.99:37581] by server-1.bemta-4.messagelabs.com id
	5D/78-20925-F7B719F4; Fri, 20 Apr 2012 15:06:39 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334934398!19286973!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25622 invoked from network); 20 Apr 2012 15:06:38 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 15:06:38 -0000
Received: from mail109-am1-R.bigfish.com (10.3.201.236) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:06:37 +0000
Received: from mail109-am1 (localhost [127.0.0.1])	by
	mail109-am1-R.bigfish.com (Postfix) with ESMTP id C3DBD4C03B2;
	Fri, 20 Apr 2012 15:06:37 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI9371I542M1432N98dKzz1202hzz8275bhz2dh668h839h944hd25hde6k)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail109-am1 (localhost.localdomain [127.0.0.1]) by mail109-am1
	(MessageSwitch) id 1334934396810650_21643;
	Fri, 20 Apr 2012 15:06:36 +0000 (UTC)
Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.239])	by
	mail109-am1.bigfish.com (Postfix) with ESMTP id C0A8CA0077;
	Fri, 20 Apr 2012 15:06:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:06:30 +0000
X-WSS-ID: 0M2S9YS-01-A6D-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22DA6102816E;	Fri, 20 Apr 2012 10:06:27 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Apr 2012 10:06:46 -0500
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag05.amd.com ([fe80::40a5:9a38:e465:3002%15]) with mapi id
	14.01.0323.003; Fri, 20 Apr 2012 10:06:27 -0500
From: "Huang2, Wei" <Wei.Huang2@amd.com>
To: Keir Fraser <keir@xen.org>, "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>, 
	"JBeulich@suse.com" <JBeulich@suse.com>, Dan Magenheimer
	<dan.magenheimer@oracle.com>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: AQHNHpxPkEb3eUjtQUKe3vtM5npR3pajr2UAgAACbgCAAB6WgA==
Date: Fri, 20 Apr 2012 15:06:26 +0000
Message-ID: <4400B41FB768044EA720935D0808176C090DFB9E@sausexdag02.amd.com>
References: <CBB6D76E.31192%keir.xen@gmail.com> <CBB6D978.3E843%keir@xen.org>
In-Reply-To: <CBB6D978.3E843%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.236.71.106]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Keir,

This patch is a bug fix for 23437:d7c755c25bb9 than new feature. It slipped my hand and Boris fixed it for me. The same applies to Xen-4.1.

===== Changeset 23437 =====

HVM/SVM: enable tsc scaling ratio for SVM

Future AMD CPUs support TSC scaling. It allows guests to have a
different TSC frequency from host system using this formula: guest_tsc
= host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR
contains a fixed-point number in 8.32 format (8 bits for integer part
and 32bits for fractional part). For instance 0x00000003_80000000
means tsc_ratio=3.5.

This patch enables TSC scaling ratio for SVM. With it, guest VMs don't
need take #VMEXIT to calculate a translated TSC value when it is
running under TSC emulation mode. This can substancially reduce the
rdtsc overhead.


-Wei

-----Original Message-----
From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
Sent: Friday, April 20, 2012 3:15 AM
To: Ostrovsky, Boris; JBeulich@suse.com; Dan Magenheimer
Cc: Huang2, Wei; xen-devel@lists.xensource.com
Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

On 20/04/2012 09:05, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
> 
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1334875170 14400
>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> 
>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> Acked-by: Wei Huang <wei.huang2@amd.com>
>> Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> possible cross-CPU TSC skew.

Oh, and apart from that, we're also in feature freeze for 4.2, and this
isn't a bug fix. Similarly, it's not really a candidate for the stable 4.1
branch either, at any time.

 -- Keir

>  -- Keir
> 
>> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
>> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
>> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
>> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>>  {
>>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>>  
>>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
>> -    if ( enable )
>> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
>> +
>> +    if ( enable && !cpu_has_tsc_ratio ) {
>>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
>> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
>> +    }
>>  
>>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
>> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>>  }
>>  
>>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
>> 
> 
> 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:08:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFRo-0002Ch-J0; Fri, 20 Apr 2012 15:08:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLFRn-0002CM-LH
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:08:31 +0000
Received: from [85.158.143.99:49386] by server-1.bemta-4.messagelabs.com id
	3D/8B-20925-EEB719F4; Fri, 20 Apr 2012 15:08:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334934509!19305260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4046 invoked from network); 20 Apr 2012 15:08:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:08:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:08:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 16:08:29 +0100
Date: Fri, 20 Apr 2012 16:13:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334738510.23948.145.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201613180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1334738510.23948.145.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter
 to libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 18 Apr 2012, Ian Campbell wrote:
> > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> > index c7e057d..05909c5 100644
> > --- a/tools/libxl/libxl_device.c
> > +++ b/tools/libxl/libxl_device.c
> > @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
> >      return libxl__device_kind_from_string(strkind, &dev->backend_kind);
> >  }
> >  
> > -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> > -                             char **bents, char **fents)
> > +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> > +        libxl__device *device, char **bents, char **fents)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> >      char *frontend_path, *backend_path;
> > -    xs_transaction_t t;
> >      struct xs_permissions frontend_perms[2];
> >      struct xs_permissions backend_perms[2];
> > +    int create_transaction = t == XBT_NULL;
> >  
> >      frontend_path = libxl__device_frontend_path(gc, device);
> >      backend_path = libxl__device_backend_path(gc, device);
> > @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> >      backend_perms[1].perms = XS_PERM_READ;
> >  
> >  retry_transaction:
> > -    t = xs_transaction_start(ctx->xsh);
> > +    if (create_transaction)
> > +        t = xs_transaction_start(ctx->xsh);
> >      /* FIXME: read frontend_path and check state before removing stuff */
> >  
> >      if (fents) {
> > @@ -101,13 +102,12 @@ retry_transaction:
> >      }
> >  
> >      if (!xs_transaction_end(ctx->xsh, t, 0)) {
> 
> Do we really want to end the transaction for caller provided t? (i.e.
> when create_transaction == False)
> 
> It would seem more expected to me to return to the caller and expect
> them to complete the transaction and perform error handling etc. If the
> caller doesn't have things of its own to do in the transaction then why
> does it have one in hand to pass in?

I think you are right, I'll change it.


> > -        if (errno == EAGAIN)
> > +        if (errno == EAGAIN && create_transaction)
> >              goto retry_transaction;
> >          else
> >              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
> >      }
> > -
> > -    return 0;
> > +    return ERROR_FAIL;
> 
> Where is the success exit path in this function now?

Good point, I'll fix that too.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:08:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFRo-0002Ch-J0; Fri, 20 Apr 2012 15:08:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLFRn-0002CM-LH
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:08:31 +0000
Received: from [85.158.143.99:49386] by server-1.bemta-4.messagelabs.com id
	3D/8B-20925-EEB719F4; Fri, 20 Apr 2012 15:08:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1334934509!19305260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4046 invoked from network); 20 Apr 2012 15:08:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:08:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:08:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 16:08:29 +0100
Date: Fri, 20 Apr 2012 16:13:52 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334738510.23948.145.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201613180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1334738510.23948.145.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/7] libxl: add a transaction parameter
 to libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 18 Apr 2012, Ian Campbell wrote:
> > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> > index c7e057d..05909c5 100644
> > --- a/tools/libxl/libxl_device.c
> > +++ b/tools/libxl/libxl_device.c
> > @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
> >      return libxl__device_kind_from_string(strkind, &dev->backend_kind);
> >  }
> >  
> > -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> > -                             char **bents, char **fents)
> > +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> > +        libxl__device *device, char **bents, char **fents)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> >      char *frontend_path, *backend_path;
> > -    xs_transaction_t t;
> >      struct xs_permissions frontend_perms[2];
> >      struct xs_permissions backend_perms[2];
> > +    int create_transaction = t == XBT_NULL;
> >  
> >      frontend_path = libxl__device_frontend_path(gc, device);
> >      backend_path = libxl__device_backend_path(gc, device);
> > @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> >      backend_perms[1].perms = XS_PERM_READ;
> >  
> >  retry_transaction:
> > -    t = xs_transaction_start(ctx->xsh);
> > +    if (create_transaction)
> > +        t = xs_transaction_start(ctx->xsh);
> >      /* FIXME: read frontend_path and check state before removing stuff */
> >  
> >      if (fents) {
> > @@ -101,13 +102,12 @@ retry_transaction:
> >      }
> >  
> >      if (!xs_transaction_end(ctx->xsh, t, 0)) {
> 
> Do we really want to end the transaction for caller provided t? (i.e.
> when create_transaction == False)
> 
> It would seem more expected to me to return to the caller and expect
> them to complete the transaction and perform error handling etc. If the
> caller doesn't have things of its own to do in the transaction then why
> does it have one in hand to pass in?

I think you are right, I'll change it.


> > -        if (errno == EAGAIN)
> > +        if (errno == EAGAIN && create_transaction)
> >              goto retry_transaction;
> >          else
> >              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
> >      }
> > -
> > -    return 0;
> > +    return ERROR_FAIL;
> 
> Where is the success exit path in this function now?

Good point, I'll fix that too.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFWO-0002nJ-AA; Fri, 20 Apr 2012 15:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLFWM-0002n4-O7
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:13:14 +0000
Received: from [85.158.143.99:19496] by server-3.bemta-4.messagelabs.com id
	72/BD-05853-A0D719F4; Fri, 20 Apr 2012 15:13:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334934793!13361686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22908 invoked from network); 20 Apr 2012 15:13:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:13:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:13:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 16:13:13 +0100
Message-ID: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <xensource.com@bloms.de>
Date: Fri, 20 Apr 2012 16:13:11 +0100
In-Reply-To: <20120420150012.GB3720@bloms.de>
References: <20120420150012.GB3720@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Dieter, 

thanks for the report.

It seems that support for this config file variable is not present in xl
at the moment. We should try and add this for 4.2 IMHO.

If you know a little bit of C (or are interested in learning) then this
should be a pretty simple thing to implement -- please let me know if
you want more details.

Ian.

On Fri, 2012-04-20 at 16:00 +0100, Dieter Bloms wrote:
> Hi,
> 
> I've installed xen-unstable 4.2 from actual git (last commit was
> 4dc7dbef5400f0608321d579aebb57f933e8f707).
> 
> When I start a domU with xm all is fine include the cpu_weight I
> configured in my domU config.
> 
> When I start the domU with xl then all my domU have the default
> cpu_weight of 256 instead of the configured one.
> 
> Was the name of cpu_weight being changed for xl command ?
> 
> My domU config looks like this:
> 
> --snip--
> name="vdrserver"
> description="vdrserver for my clients"
> memory=768
> maxmem=2048
> vcpus=1
> cpus="1"
> cpu_weight = 128
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> 
> localtime=0
> keymap="de"
> 
> builder="linux"
> bootloader="/usr/bin/pygrub"
> bootargs=""
> extra="console=hvc0 tmem cgroup_disable=memory independent_wallclock=1 iommu=soft"
> nographic=1
> keymap = 'de'
> 
> disk=[ 
>   'phy:/dev/mapper/xenimages-vdrserver,xvda1,w',
>   'phy:/dev/mapper/xenimages-swap_vdrserver,xvda2,w',
> ]
> vif=[ 'mac=00:00:00:00:00:80,bridge=br0', ]
> 
> pci = [ '06:00.0', '06:01.0', '00:12.2', '00:13.2']
> --snip--
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFWO-0002nJ-AA; Fri, 20 Apr 2012 15:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLFWM-0002n4-O7
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:13:14 +0000
Received: from [85.158.143.99:19496] by server-3.bemta-4.messagelabs.com id
	72/BD-05853-A0D719F4; Fri, 20 Apr 2012 15:13:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334934793!13361686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22908 invoked from network); 20 Apr 2012 15:13:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:13:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:13:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 16:13:13 +0100
Message-ID: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <xensource.com@bloms.de>
Date: Fri, 20 Apr 2012 16:13:11 +0100
In-Reply-To: <20120420150012.GB3720@bloms.de>
References: <20120420150012.GB3720@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Dieter, 

thanks for the report.

It seems that support for this config file variable is not present in xl
at the moment. We should try and add this for 4.2 IMHO.

If you know a little bit of C (or are interested in learning) then this
should be a pretty simple thing to implement -- please let me know if
you want more details.

Ian.

On Fri, 2012-04-20 at 16:00 +0100, Dieter Bloms wrote:
> Hi,
> 
> I've installed xen-unstable 4.2 from actual git (last commit was
> 4dc7dbef5400f0608321d579aebb57f933e8f707).
> 
> When I start a domU with xm all is fine include the cpu_weight I
> configured in my domU config.
> 
> When I start the domU with xl then all my domU have the default
> cpu_weight of 256 instead of the configured one.
> 
> Was the name of cpu_weight being changed for xl command ?
> 
> My domU config looks like this:
> 
> --snip--
> name="vdrserver"
> description="vdrserver for my clients"
> memory=768
> maxmem=2048
> vcpus=1
> cpus="1"
> cpu_weight = 128
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> 
> localtime=0
> keymap="de"
> 
> builder="linux"
> bootloader="/usr/bin/pygrub"
> bootargs=""
> extra="console=hvc0 tmem cgroup_disable=memory independent_wallclock=1 iommu=soft"
> nographic=1
> keymap = 'de'
> 
> disk=[ 
>   'phy:/dev/mapper/xenimages-vdrserver,xvda1,w',
>   'phy:/dev/mapper/xenimages-swap_vdrserver,xvda2,w',
> ]
> vif=[ 'mac=00:00:00:00:00:80,bridge=br0', ]
> 
> pci = [ '06:00.0', '06:01.0', '00:12.2', '00:13.2']
> --snip--
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:18:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFbY-0003Rp-F2; Fri, 20 Apr 2012 15:18:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SLFbW-0003RU-AF
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:18:34 +0000
Received: from [85.158.139.83:7338] by server-9.bemta-5.messagelabs.com id
	6B/9F-09826-94E719F4; Fri, 20 Apr 2012 15:18:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334935108!17414890!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16046 invoked from network); 20 Apr 2012 15:18:29 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:18:29 -0000
Received: by lbon10 with SMTP id n10so6644131lbo.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 08:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Md24IWpMKTzCqYM8xlaxN+6r6qRP6u2f6TvTh77l5x4=;
	b=PncBDQsa08UEnZtw2cKXd6nlfdGyX16Rv9wN8BbXawrW8gl2TFmSylYGF0aTjQUA2g
	YV0AptJO/RnlmLR7G8ZmZZl/w5nlNxBOf+K8f9knXB3pe7TX+S8ELYtUfIZshSySsdk2
	DpWPR33rpUPg/6n/T8I1wPslGQhP85PootD34=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=Md24IWpMKTzCqYM8xlaxN+6r6qRP6u2f6TvTh77l5x4=;
	b=J5yzf676jywpW+RuYym678UxbhFGcRHYbipFQ3u/kNo0FNo9fmpfrsKkcU8yytBmME
	Bh5UiB+PUvzLuqybi/KFl9RsncehbV52hQwnQTdS0yRUW9wnQTjqCAybKwNTRTsyeDuz
	JZ75lji3J1NUGTWWDNDoLqxg+uDWfiOYZIyV4cHt1FmR27c+PYqtSx6A9IVgwtwnq8pw
	1l4icb4XCL3nsZ1rp3WKeLCYhzeMDC9bl/r3vf4KnXPRdMqNWlb7o3q5elbmiqd/TyTL
	leGTFwdlZqkg91ap7QEeH/QXXcOVPDrBv+YYlZtkxavfcWmVq5esTpCsVtMGn/x8Rle2
	f7dg==
MIME-Version: 1.0
Received: by 10.112.47.69 with SMTP id b5mr3090869lbn.17.1334934739480; Fri,
	20 Apr 2012 08:12:19 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 20 Apr 2012 08:12:19 -0700 (PDT)
X-Originating-IP: [174.253.240.171]
Received: by 10.112.47.100 with HTTP; Fri, 20 Apr 2012 08:12:19 -0700 (PDT)
In-Reply-To: <1334931321.28331.97.camel@zakaz.uk.xensource.com>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
	<1334925395.28331.61.camel@zakaz.uk.xensource.com>
	<260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
	<1334931321.28331.97.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 08:12:19 -0700
Message-ID: <CAB10MZAVUoGRdcNGWf0V+k2zXgq9v3VBoKod++7iYXMojoEbcA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQk+zPBIBZNqK4wjUSk+spokOxEEthqlLrQt8l4tlZ7RJPrZoKEXd4QT3DT7WMLuMux+D6aZ
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
	linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4991420909014632144=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4991420909014632144==
Content-Type: multipart/alternative; boundary=bcaec555561ef1f1a304be1db629

--bcaec555561ef1f1a304be1db629
Content-Type: text/plain; charset=ISO-8859-1

On Apr 20, 2012 7:15 AM, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
> On Fri, 2012-04-20 at 15:08 +0100, Andres Lagar-Cavilla wrote:
> > > On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
> > >> When mapping in large amounts of pages (in the GB range) from a guest
> > >> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the
libxc
> > >> client application. This is because the pfn array in
> > >> linux_privcmd_map_foreign_bulk() is being allocated using alloca()
and
> > >> the subsequent memcpy causes the stack to blow. This patch replaces
> > >> the alloca() with mmap().
> > >
> > > The original reason for switching to alloca from malloc was because
the
> > > similar gntmap path was a hot path and it seemed like if it was
> > > reasonable there it would be reasonable here too.
> > >
> > > So I have a couple of questions...
> > >
> > > Is it possible that we also introduced this same issue at the other
> > > callsites which were changed in that patch or are there other
> > > constraints on the size of the allocation which make it not a problem?
> >
> > I don't know how arbitrary or large can the buffer sizes be in the other
> > callsites. It would seem that they can be large enough.
> > >
> > > Where does this mmap approach fall in terms of performance relative to
> > > just switching back to malloc? I presume that alloca is faster than
> > > both, but if it doesn't work reliably then it's not an option.
> >
> > It's hard to dig out exactly how alloca is implemented, but it would
seem
> > to simply move the stack pointer and return the old one (it's arguable
> > whether there is a buggy check for limits or a buggy lack of check
against
> > the guard page going on -- man page says "behavior undefined"). So, if
you
> > need new pages in the stack as a result of the stack pointer motion,
those
> > pages will be demand allocated.
> >
> > mmap just short circuits straight to page allocation. Note that malloc
may
> > or may not wind up calling mmap if it needs more pages, depending on its
> > internal machinations.
> >
> > MAP_POPULATE tells the mmap syscall to allocate right now, avoiding
demand
> > allocation. Presumably this will batch all page allocations in the
single
> > syscall, and avoid page faults down the line.
> >
> > Short story, I suggested mmap with MAP_POPULATE because it will do the
> > allocation of pages in the most optimal fashion, even better than malloc
> > or alloca. But it's only worth if the buffer is big enough such that new
> > pages will need to be allocated.
>
> I think in these cases the whole buffer will always be used, since they
> are sized precisely for what they need to contain.
>
> > I think a reasonable compromise would be to do alloca if the buffer is
> > less than one page (a fairly common case, single pfn buffers, etc), and
do
> > mmap(MAP_POPULATE) for buffers larger than a page.
>
> I agree.

Sounds good. I will send out a patch that does this.

> Ian.
>
> >
> > Andres
> >
> > >
> > > If mmap and malloc have roughly equivalent performance properties, or
> > > the fast one is still too slow for Santosh's use case, then maybe we
> > > need to have a think about other options.
> > >
> > > e.g. use alloca for small numbers of mappings and mmap/malloc for
larger
> > > ones. Or do large numbers of mappings in multiple batches.
> > >
> > > Ian.
> > >
> > >>
> > >> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> > >> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > >>
> > >> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
> > >> --- a/tools/libxc/xc_linux_osdep.c Wed Apr 18 16:49:55 2012 +0100
> > >> +++ b/tools/libxc/xc_linux_osdep.c Thu Apr 19 15:21:43 2012 -0700
> > >> @@ -39,6 +39,7 @@
> > >>  #include "xenctrl.h"
> > >>  #include "xenctrlosdep.h"
> > >>
> > >> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
> > >> ~((1UL<<(_w))-1))
> > >>  #define ERROR(_m, _a...)
> > >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
> > >>  #define PERROR(_m, _a...)
> > >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
> > >>                    " (%d = %s)", ## _a , errno, xc_strerror(xch,
errno))
> > >> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
> > >>           * IOCTL_PRIVCMD_MMAPBATCH.
> > >>           */
> > >>          privcmd_mmapbatch_t ioctlx;
> > >> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> > >> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
> > >> XC_PAGE_SHIFT),
> > >> +                              PROT_READ | PROT_WRITE,
> > >> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE,
> > >> -1, 0);
> > >> +        if ( pfn == MAP_FAILED )
> > >> +        {
> > >> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> > >> +            return NULL;
> > >> +        }
> > >>
> > >>          memcpy(pfn, arr, num * sizeof(*arr));
> > >>
> > >> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
> > >>              break;
> > >>          }
> > >>
> > >> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
> > >> +
> > >>          if ( rc == -ENOENT && i == num )
> > >>              rc = 0;
> > >>          else if ( rc )
> > >>
> > >> _______________________________________________
> > >> Xen-devel mailing list
> > >> Xen-devel@lists.xen.org
> > >> http://lists.xen.org/xen-devel
> > >
> > >
> > >
> >
> >
>
>

--bcaec555561ef1f1a304be1db629
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>On Apr 20, 2012 7:15 AM, &quot;Ian Campbell&quot; &lt;<a href=3D"mailto:=
Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, 2012-04-20 at 15:08 +0100, Andres Lagar-Cavilla wrote:<br>
&gt; &gt; &gt; On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil =
wrote:<br>
&gt; &gt; &gt;&gt; When mapping in large amounts of pages (in the GB range)=
 from a guest<br>
&gt; &gt; &gt;&gt; in to Dom0 using xc_map_foreign_bulk(), a segfault occur=
s in the libxc<br>
&gt; &gt; &gt;&gt; client application. This is because the pfn array in<br>
&gt; &gt; &gt;&gt; linux_privcmd_map_foreign_bulk() is being allocated usin=
g alloca() and<br>
&gt; &gt; &gt;&gt; the subsequent memcpy causes the stack to blow. This pat=
ch replaces<br>
&gt; &gt; &gt;&gt; the alloca() with mmap().<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The original reason for switching to alloca from malloc was =
because the<br>
&gt; &gt; &gt; similar gntmap path was a hot path and it seemed like if it =
was<br>
&gt; &gt; &gt; reasonable there it would be reasonable here too.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So I have a couple of questions...<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Is it possible that we also introduced this same issue at th=
e other<br>
&gt; &gt; &gt; callsites which were changed in that patch or are there othe=
r<br>
&gt; &gt; &gt; constraints on the size of the allocation which make it not =
a problem?<br>
&gt; &gt;<br>
&gt; &gt; I don&#39;t know how arbitrary or large can the buffer sizes be i=
n the other<br>
&gt; &gt; callsites. It would seem that they can be large enough.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Where does this mmap approach fall in terms of performance r=
elative to<br>
&gt; &gt; &gt; just switching back to malloc? I presume that alloca is fast=
er than<br>
&gt; &gt; &gt; both, but if it doesn&#39;t work reliably then it&#39;s not =
an option.<br>
&gt; &gt;<br>
&gt; &gt; It&#39;s hard to dig out exactly how alloca is implemented, but i=
t would seem<br>
&gt; &gt; to simply move the stack pointer and return the old one (it&#39;s=
 arguable<br>
&gt; &gt; whether there is a buggy check for limits or a buggy lack of chec=
k against<br>
&gt; &gt; the guard page going on -- man page says &quot;behavior undefined=
&quot;). So, if you<br>
&gt; &gt; need new pages in the stack as a result of the stack pointer moti=
on, those<br>
&gt; &gt; pages will be demand allocated.<br>
&gt; &gt;<br>
&gt; &gt; mmap just short circuits straight to page allocation. Note that m=
alloc may<br>
&gt; &gt; or may not wind up calling mmap if it needs more pages, depending=
 on its<br>
&gt; &gt; internal machinations.<br>
&gt; &gt;<br>
&gt; &gt; MAP_POPULATE tells the mmap syscall to allocate right now, avoidi=
ng demand<br>
&gt; &gt; allocation. Presumably this will batch all page allocations in th=
e single<br>
&gt; &gt; syscall, and avoid page faults down the line.<br>
&gt; &gt;<br>
&gt; &gt; Short story, I suggested mmap with MAP_POPULATE because it will d=
o the<br>
&gt; &gt; allocation of pages in the most optimal fashion, even better than=
 malloc<br>
&gt; &gt; or alloca. But it&#39;s only worth if the buffer is big enough su=
ch that new<br>
&gt; &gt; pages will need to be allocated.<br>
&gt;<br>
&gt; I think in these cases the whole buffer will always be used, since the=
y<br>
&gt; are sized precisely for what they need to contain.<br>
&gt;<br>
&gt; &gt; I think a reasonable compromise would be to do alloca if the buff=
er is<br>
&gt; &gt; less than one page (a fairly common case, single pfn buffers, etc=
), and do<br>
&gt; &gt; mmap(MAP_POPULATE) for buffers larger than a page.<br>
&gt;<br>
&gt; I agree.</p>
<p>Sounds good. I will send out a patch that does this.</p>
<p>&gt; Ian.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Andres<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If mmap and malloc have roughly equivalent performance prope=
rties, or<br>
&gt; &gt; &gt; the fast one is still too slow for Santosh&#39;s use case, t=
hen maybe we<br>
&gt; &gt; &gt; need to have a think about other options.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; e.g. use alloca for small numbers of mappings and mmap/mallo=
c for larger<br>
&gt; &gt; &gt; ones. Or do large numbers of mappings in multiple batches.<b=
r>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ian.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Signed-off-by: Aravindh Puthiyaparambil &lt;<a href=3D"m=
ailto:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt; &gt;&gt; Acked-by: Andres Lagar-Cavilla &lt;<a href=3D"mailto:and=
res@lagarcavilla.org">andres@lagarcavilla.org</a>&gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linu=
x_osdep.c<br>
&gt; &gt; &gt;&gt; --- a/tools/libxc/xc_linux_osdep.c Wed Apr 18 16:49:55 2=
012 +0100<br>
&gt; &gt; &gt;&gt; +++ b/tools/libxc/xc_linux_osdep.c Thu Apr 19 15:21:43 2=
012 -0700<br>
&gt; &gt; &gt;&gt; @@ -39,6 +39,7 @@<br>
&gt; &gt; &gt;&gt; =A0#include &quot;xenctrl.h&quot;<br>
&gt; &gt; &gt;&gt; =A0#include &quot;xenctrlosdep.h&quot;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL&lt;&l=
t;(_w))-1) &amp;<br>
&gt; &gt; &gt;&gt; ~((1UL&lt;&lt;(_w))-1))<br>
&gt; &gt; &gt;&gt; =A0#define ERROR(_m, _a...)<br>
&gt; &gt; &gt;&gt; xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a =
)<br>
&gt; &gt; &gt;&gt; =A0#define PERROR(_m, _a...)<br>
&gt; &gt; &gt;&gt; xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot; (%d =3D %s=
)&quot;, ## _a , errno, xc_strerror(xch, errno))<br>
&gt; &gt; &gt;&gt; @@ -286,7 +287,14 @@ static void *linux_privcmd_map_fore=
ign_b<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 * IOCTL_PRIVCMD_MMAPBATCH.<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 */<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0privcmd_mmapbatch_t ioctlx;<br>
&gt; &gt; &gt;&gt; - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(=
*pfn));<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((=
num * sizeof(*pfn)),<br>
&gt; &gt; &gt;&gt; XC_PAGE_SHIFT),<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0PROT_READ | PROT_WRITE,<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0MAP_PRIVATE | MAP_ANON | MAP_POPULATE,<br>
&gt; &gt; &gt;&gt; -1, 0);<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0{<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;xc_map_foreign_bul=
k: mmap of pfn array failed&quot;);<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0return NULL;<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0memcpy(pfn, arr, num * sizeof(*arr));=
<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; @@ -328,6 +336,8 @@ static void *linux_privcmd_map_forei=
gn_b<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0munmap(pfn, ROUNDUP((num * sizeof(*pfn)=
), XC_PAGE_SHIFT));<br>
&gt; &gt; &gt;&gt; +<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0if ( rc =3D=3D -ENOENT &amp;&amp; i =
=3D=3D num )<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D 0;<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0else if ( rc )<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; _______________________________________________<br>
&gt; &gt; &gt;&gt; Xen-devel mailing list<br>
&gt; &gt; &gt;&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lis=
ts.xen.org</a><br>
&gt; &gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel">http://lists.=
xen.org/xen-devel</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
</p>

--bcaec555561ef1f1a304be1db629--


--===============4991420909014632144==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4991420909014632144==--


From xen-devel-bounces@lists.xen.org Fri Apr 20 15:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:18:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFbY-0003Rp-F2; Fri, 20 Apr 2012 15:18:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SLFbW-0003RU-AF
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:18:34 +0000
Received: from [85.158.139.83:7338] by server-9.bemta-5.messagelabs.com id
	6B/9F-09826-94E719F4; Fri, 20 Apr 2012 15:18:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1334935108!17414890!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16046 invoked from network); 20 Apr 2012 15:18:29 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:18:29 -0000
Received: by lbon10 with SMTP id n10so6644131lbo.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 08:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Md24IWpMKTzCqYM8xlaxN+6r6qRP6u2f6TvTh77l5x4=;
	b=PncBDQsa08UEnZtw2cKXd6nlfdGyX16Rv9wN8BbXawrW8gl2TFmSylYGF0aTjQUA2g
	YV0AptJO/RnlmLR7G8ZmZZl/w5nlNxBOf+K8f9knXB3pe7TX+S8ELYtUfIZshSySsdk2
	DpWPR33rpUPg/6n/T8I1wPslGQhP85PootD34=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=Md24IWpMKTzCqYM8xlaxN+6r6qRP6u2f6TvTh77l5x4=;
	b=J5yzf676jywpW+RuYym678UxbhFGcRHYbipFQ3u/kNo0FNo9fmpfrsKkcU8yytBmME
	Bh5UiB+PUvzLuqybi/KFl9RsncehbV52hQwnQTdS0yRUW9wnQTjqCAybKwNTRTsyeDuz
	JZ75lji3J1NUGTWWDNDoLqxg+uDWfiOYZIyV4cHt1FmR27c+PYqtSx6A9IVgwtwnq8pw
	1l4icb4XCL3nsZ1rp3WKeLCYhzeMDC9bl/r3vf4KnXPRdMqNWlb7o3q5elbmiqd/TyTL
	leGTFwdlZqkg91ap7QEeH/QXXcOVPDrBv+YYlZtkxavfcWmVq5esTpCsVtMGn/x8Rle2
	f7dg==
MIME-Version: 1.0
Received: by 10.112.47.69 with SMTP id b5mr3090869lbn.17.1334934739480; Fri,
	20 Apr 2012 08:12:19 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 20 Apr 2012 08:12:19 -0700 (PDT)
X-Originating-IP: [174.253.240.171]
Received: by 10.112.47.100 with HTTP; Fri, 20 Apr 2012 08:12:19 -0700 (PDT)
In-Reply-To: <1334931321.28331.97.camel@zakaz.uk.xensource.com>
References: <2f68aefc46c35ef5c0c3.1334874293@vollum>
	<1334925395.28331.61.camel@zakaz.uk.xensource.com>
	<260d4d777fe1bf57d19fadc27c781343.squirrel@webmail.lagarcavilla.org>
	<1334931321.28331.97.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 08:12:19 -0700
Message-ID: <CAB10MZAVUoGRdcNGWf0V+k2zXgq9v3VBoKod++7iYXMojoEbcA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQk+zPBIBZNqK4wjUSk+spokOxEEthqlLrQt8l4tlZ7RJPrZoKEXd4QT3DT7WMLuMux+D6aZ
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Replace alloca() with mmap() in
	linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4991420909014632144=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4991420909014632144==
Content-Type: multipart/alternative; boundary=bcaec555561ef1f1a304be1db629

--bcaec555561ef1f1a304be1db629
Content-Type: text/plain; charset=ISO-8859-1

On Apr 20, 2012 7:15 AM, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
> On Fri, 2012-04-20 at 15:08 +0100, Andres Lagar-Cavilla wrote:
> > > On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil wrote:
> > >> When mapping in large amounts of pages (in the GB range) from a guest
> > >> in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the
libxc
> > >> client application. This is because the pfn array in
> > >> linux_privcmd_map_foreign_bulk() is being allocated using alloca()
and
> > >> the subsequent memcpy causes the stack to blow. This patch replaces
> > >> the alloca() with mmap().
> > >
> > > The original reason for switching to alloca from malloc was because
the
> > > similar gntmap path was a hot path and it seemed like if it was
> > > reasonable there it would be reasonable here too.
> > >
> > > So I have a couple of questions...
> > >
> > > Is it possible that we also introduced this same issue at the other
> > > callsites which were changed in that patch or are there other
> > > constraints on the size of the allocation which make it not a problem?
> >
> > I don't know how arbitrary or large can the buffer sizes be in the other
> > callsites. It would seem that they can be large enough.
> > >
> > > Where does this mmap approach fall in terms of performance relative to
> > > just switching back to malloc? I presume that alloca is faster than
> > > both, but if it doesn't work reliably then it's not an option.
> >
> > It's hard to dig out exactly how alloca is implemented, but it would
seem
> > to simply move the stack pointer and return the old one (it's arguable
> > whether there is a buggy check for limits or a buggy lack of check
against
> > the guard page going on -- man page says "behavior undefined"). So, if
you
> > need new pages in the stack as a result of the stack pointer motion,
those
> > pages will be demand allocated.
> >
> > mmap just short circuits straight to page allocation. Note that malloc
may
> > or may not wind up calling mmap if it needs more pages, depending on its
> > internal machinations.
> >
> > MAP_POPULATE tells the mmap syscall to allocate right now, avoiding
demand
> > allocation. Presumably this will batch all page allocations in the
single
> > syscall, and avoid page faults down the line.
> >
> > Short story, I suggested mmap with MAP_POPULATE because it will do the
> > allocation of pages in the most optimal fashion, even better than malloc
> > or alloca. But it's only worth if the buffer is big enough such that new
> > pages will need to be allocated.
>
> I think in these cases the whole buffer will always be used, since they
> are sized precisely for what they need to contain.
>
> > I think a reasonable compromise would be to do alloca if the buffer is
> > less than one page (a fairly common case, single pfn buffers, etc), and
do
> > mmap(MAP_POPULATE) for buffers larger than a page.
>
> I agree.

Sounds good. I will send out a patch that does this.

> Ian.
>
> >
> > Andres
> >
> > >
> > > If mmap and malloc have roughly equivalent performance properties, or
> > > the fast one is still too slow for Santosh's use case, then maybe we
> > > need to have a think about other options.
> > >
> > > e.g. use alloca for small numbers of mappings and mmap/malloc for
larger
> > > ones. Or do large numbers of mappings in multiple batches.
> > >
> > > Ian.
> > >
> > >>
> > >> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> > >> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > >>
> > >> diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linux_osdep.c
> > >> --- a/tools/libxc/xc_linux_osdep.c Wed Apr 18 16:49:55 2012 +0100
> > >> +++ b/tools/libxc/xc_linux_osdep.c Thu Apr 19 15:21:43 2012 -0700
> > >> @@ -39,6 +39,7 @@
> > >>  #include "xenctrl.h"
> > >>  #include "xenctrlosdep.h"
> > >>
> > >> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
> > >> ~((1UL<<(_w))-1))
> > >>  #define ERROR(_m, _a...)
> > >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
> > >>  #define PERROR(_m, _a...)
> > >> xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
> > >>                    " (%d = %s)", ## _a , errno, xc_strerror(xch,
errno))
> > >> @@ -286,7 +287,14 @@ static void *linux_privcmd_map_foreign_b
> > >>           * IOCTL_PRIVCMD_MMAPBATCH.
> > >>           */
> > >>          privcmd_mmapbatch_t ioctlx;
> > >> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> > >> +        xen_pfn_t *pfn = mmap(NULL, ROUNDUP((num * sizeof(*pfn)),
> > >> XC_PAGE_SHIFT),
> > >> +                              PROT_READ | PROT_WRITE,
> > >> +                              MAP_PRIVATE | MAP_ANON | MAP_POPULATE,
> > >> -1, 0);
> > >> +        if ( pfn == MAP_FAILED )
> > >> +        {
> > >> +            PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> > >> +            return NULL;
> > >> +        }
> > >>
> > >>          memcpy(pfn, arr, num * sizeof(*arr));
> > >>
> > >> @@ -328,6 +336,8 @@ static void *linux_privcmd_map_foreign_b
> > >>              break;
> > >>          }
> > >>
> > >> +        munmap(pfn, ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT));
> > >> +
> > >>          if ( rc == -ENOENT && i == num )
> > >>              rc = 0;
> > >>          else if ( rc )
> > >>
> > >> _______________________________________________
> > >> Xen-devel mailing list
> > >> Xen-devel@lists.xen.org
> > >> http://lists.xen.org/xen-devel
> > >
> > >
> > >
> >
> >
>
>

--bcaec555561ef1f1a304be1db629
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>On Apr 20, 2012 7:15 AM, &quot;Ian Campbell&quot; &lt;<a href=3D"mailto:=
Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, 2012-04-20 at 15:08 +0100, Andres Lagar-Cavilla wrote:<br>
&gt; &gt; &gt; On Thu, 2012-04-19 at 23:24 +0100, Aravindh Puthiyaparambil =
wrote:<br>
&gt; &gt; &gt;&gt; When mapping in large amounts of pages (in the GB range)=
 from a guest<br>
&gt; &gt; &gt;&gt; in to Dom0 using xc_map_foreign_bulk(), a segfault occur=
s in the libxc<br>
&gt; &gt; &gt;&gt; client application. This is because the pfn array in<br>
&gt; &gt; &gt;&gt; linux_privcmd_map_foreign_bulk() is being allocated usin=
g alloca() and<br>
&gt; &gt; &gt;&gt; the subsequent memcpy causes the stack to blow. This pat=
ch replaces<br>
&gt; &gt; &gt;&gt; the alloca() with mmap().<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The original reason for switching to alloca from malloc was =
because the<br>
&gt; &gt; &gt; similar gntmap path was a hot path and it seemed like if it =
was<br>
&gt; &gt; &gt; reasonable there it would be reasonable here too.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So I have a couple of questions...<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Is it possible that we also introduced this same issue at th=
e other<br>
&gt; &gt; &gt; callsites which were changed in that patch or are there othe=
r<br>
&gt; &gt; &gt; constraints on the size of the allocation which make it not =
a problem?<br>
&gt; &gt;<br>
&gt; &gt; I don&#39;t know how arbitrary or large can the buffer sizes be i=
n the other<br>
&gt; &gt; callsites. It would seem that they can be large enough.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Where does this mmap approach fall in terms of performance r=
elative to<br>
&gt; &gt; &gt; just switching back to malloc? I presume that alloca is fast=
er than<br>
&gt; &gt; &gt; both, but if it doesn&#39;t work reliably then it&#39;s not =
an option.<br>
&gt; &gt;<br>
&gt; &gt; It&#39;s hard to dig out exactly how alloca is implemented, but i=
t would seem<br>
&gt; &gt; to simply move the stack pointer and return the old one (it&#39;s=
 arguable<br>
&gt; &gt; whether there is a buggy check for limits or a buggy lack of chec=
k against<br>
&gt; &gt; the guard page going on -- man page says &quot;behavior undefined=
&quot;). So, if you<br>
&gt; &gt; need new pages in the stack as a result of the stack pointer moti=
on, those<br>
&gt; &gt; pages will be demand allocated.<br>
&gt; &gt;<br>
&gt; &gt; mmap just short circuits straight to page allocation. Note that m=
alloc may<br>
&gt; &gt; or may not wind up calling mmap if it needs more pages, depending=
 on its<br>
&gt; &gt; internal machinations.<br>
&gt; &gt;<br>
&gt; &gt; MAP_POPULATE tells the mmap syscall to allocate right now, avoidi=
ng demand<br>
&gt; &gt; allocation. Presumably this will batch all page allocations in th=
e single<br>
&gt; &gt; syscall, and avoid page faults down the line.<br>
&gt; &gt;<br>
&gt; &gt; Short story, I suggested mmap with MAP_POPULATE because it will d=
o the<br>
&gt; &gt; allocation of pages in the most optimal fashion, even better than=
 malloc<br>
&gt; &gt; or alloca. But it&#39;s only worth if the buffer is big enough su=
ch that new<br>
&gt; &gt; pages will need to be allocated.<br>
&gt;<br>
&gt; I think in these cases the whole buffer will always be used, since the=
y<br>
&gt; are sized precisely for what they need to contain.<br>
&gt;<br>
&gt; &gt; I think a reasonable compromise would be to do alloca if the buff=
er is<br>
&gt; &gt; less than one page (a fairly common case, single pfn buffers, etc=
), and do<br>
&gt; &gt; mmap(MAP_POPULATE) for buffers larger than a page.<br>
&gt;<br>
&gt; I agree.</p>
<p>Sounds good. I will send out a patch that does this.</p>
<p>&gt; Ian.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Andres<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If mmap and malloc have roughly equivalent performance prope=
rties, or<br>
&gt; &gt; &gt; the fast one is still too slow for Santosh&#39;s use case, t=
hen maybe we<br>
&gt; &gt; &gt; need to have a think about other options.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; e.g. use alloca for small numbers of mappings and mmap/mallo=
c for larger<br>
&gt; &gt; &gt; ones. Or do large numbers of mappings in multiple batches.<b=
r>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ian.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Signed-off-by: Aravindh Puthiyaparambil &lt;<a href=3D"m=
ailto:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt; &gt;&gt; Acked-by: Andres Lagar-Cavilla &lt;<a href=3D"mailto:and=
res@lagarcavilla.org">andres@lagarcavilla.org</a>&gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; diff -r 7c777cb8f705 -r 2f68aefc46c3 tools/libxc/xc_linu=
x_osdep.c<br>
&gt; &gt; &gt;&gt; --- a/tools/libxc/xc_linux_osdep.c Wed Apr 18 16:49:55 2=
012 +0100<br>
&gt; &gt; &gt;&gt; +++ b/tools/libxc/xc_linux_osdep.c Thu Apr 19 15:21:43 2=
012 -0700<br>
&gt; &gt; &gt;&gt; @@ -39,6 +39,7 @@<br>
&gt; &gt; &gt;&gt; =A0#include &quot;xenctrl.h&quot;<br>
&gt; &gt; &gt;&gt; =A0#include &quot;xenctrlosdep.h&quot;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL&lt;&l=
t;(_w))-1) &amp;<br>
&gt; &gt; &gt;&gt; ~((1UL&lt;&lt;(_w))-1))<br>
&gt; &gt; &gt;&gt; =A0#define ERROR(_m, _a...)<br>
&gt; &gt; &gt;&gt; xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a =
)<br>
&gt; &gt; &gt;&gt; =A0#define PERROR(_m, _a...)<br>
&gt; &gt; &gt;&gt; xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot; (%d =3D %s=
)&quot;, ## _a , errno, xc_strerror(xch, errno))<br>
&gt; &gt; &gt;&gt; @@ -286,7 +287,14 @@ static void *linux_privcmd_map_fore=
ign_b<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 * IOCTL_PRIVCMD_MMAPBATCH.<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 */<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0privcmd_mmapbatch_t ioctlx;<br>
&gt; &gt; &gt;&gt; - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(=
*pfn));<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D mmap(NULL, ROUNDUP((=
num * sizeof(*pfn)),<br>
&gt; &gt; &gt;&gt; XC_PAGE_SHIFT),<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0PROT_READ | PROT_WRITE,<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0MAP_PRIVATE | MAP_ANON | MAP_POPULATE,<br>
&gt; &gt; &gt;&gt; -1, 0);<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0{<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;xc_map_foreign_bul=
k: mmap of pfn array failed&quot;);<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0return NULL;<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0memcpy(pfn, arr, num * sizeof(*arr));=
<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; @@ -328,6 +336,8 @@ static void *linux_privcmd_map_forei=
gn_b<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; + =A0 =A0 =A0 =A0munmap(pfn, ROUNDUP((num * sizeof(*pfn)=
), XC_PAGE_SHIFT));<br>
&gt; &gt; &gt;&gt; +<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0if ( rc =3D=3D -ENOENT &amp;&amp; i =
=3D=3D num )<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D 0;<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0else if ( rc )<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; _______________________________________________<br>
&gt; &gt; &gt;&gt; Xen-devel mailing list<br>
&gt; &gt; &gt;&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lis=
ts.xen.org</a><br>
&gt; &gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel">http://lists.=
xen.org/xen-devel</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
</p>

--bcaec555561ef1f1a304be1db629--


--===============4991420909014632144==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4991420909014632144==--


From xen-devel-bounces@lists.xen.org Fri Apr 20 15:23:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFg4-0003j6-GP; Fri, 20 Apr 2012 15:23:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLFg2-0003ig-OG
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:23:14 +0000
Received: from [85.158.143.99:26870] by server-3.bemta-4.messagelabs.com id
	E8/9B-05853-16F719F4; Fri, 20 Apr 2012 15:23:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334935392!23650603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13249 invoked from network); 20 Apr 2012 15:23:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:23:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:23:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 16:23:12 +0100
Date: Fri, 20 Apr 2012 16:28:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20369.24079.242104.252793@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201628160.26786@kaball-desktop>
References: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20369.24079.242104.252793@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/1] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH 1/1] libxl: use qemu-xen with PV guests by default"):
> > qemu-xen offers better disk performances than qemu-xen-traditional
> > because it supports Linux native AIO: use it for PV guests if it is
> > available.
> ...
> > +            rc = stat(dm, &buf);
> > +            /* qemu-xen unavailable, use qemu-xen-traditional */
> 
> Firstly, why not use access(2) rather than stat(2) ?
> 
> Secondly you ignore the errno value.  errnos other than ENOENT (or
> perhaps ENOTDIR) should perhaps cause us to bomb out, and in any case
> the errno value should be logged.
 
you have two good points there, I'll resubmit.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:23:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFg4-0003j6-GP; Fri, 20 Apr 2012 15:23:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLFg2-0003ig-OG
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:23:14 +0000
Received: from [85.158.143.99:26870] by server-3.bemta-4.messagelabs.com id
	E8/9B-05853-16F719F4; Fri, 20 Apr 2012 15:23:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1334935392!23650603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13249 invoked from network); 20 Apr 2012 15:23:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:23:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12052787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:23:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 16:23:12 +0100
Date: Fri, 20 Apr 2012 16:28:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20369.24079.242104.252793@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204201628160.26786@kaball-desktop>
References: <1334926480-21094-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20369.24079.242104.252793@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/1] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH 1/1] libxl: use qemu-xen with PV guests by default"):
> > qemu-xen offers better disk performances than qemu-xen-traditional
> > because it supports Linux native AIO: use it for PV guests if it is
> > available.
> ...
> > +            rc = stat(dm, &buf);
> > +            /* qemu-xen unavailable, use qemu-xen-traditional */
> 
> Firstly, why not use access(2) rather than stat(2) ?
> 
> Secondly you ignore the errno value.  errnos other than ENOENT (or
> perhaps ENOTDIR) should perhaps cause us to bomb out, and in any case
> the errno value should be logged.
 
you have two good points there, I'll resubmit.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:24:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFhL-0003pa-WE; Fri, 20 Apr 2012 15:24:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLFhK-0003pM-9U
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:24:34 +0000
Received: from [85.158.143.35:52500] by server-2.bemta-4.messagelabs.com id
	4B/D8-17550-1BF719F4; Fri, 20 Apr 2012 15:24:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334935471!9788026!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14455 invoked from network); 20 Apr 2012 15:24:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24370687"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:24:31 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:24:31 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SLFhB-0003d8-O3; Fri, 20 Apr 2012 16:24:25 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Apr 2012 16:29:53 +0100
Message-ID: <1334935793-23912-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3] libxl: use qemu-xen with PV guests by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

qemu-xen offers better disk performances than qemu-xen-traditional
because it supports Linux native AIO: use it for PV guests if it is
available.

Changes in v3:
- use access instead of stat;
- log the errno.

Changes in v2:
- check for the existence of the qemu-xen binary before setting qemu-xen
as the default device model for PV guests.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   33 ++++++++++++++++++++++++++++-----
 1 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..f9c2a76 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -71,9 +71,34 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->type != LIBXL_DOMAIN_TYPE_PV)
         return ERROR_INVAL;
 
-    if (!b_info->device_model_version)
-        b_info->device_model_version =
-            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (!b_info->device_model_version) {
+        if (b_info->type == LIBXL_DOMAIN_TYPE_HVM)
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+        else {
+            const char *dm;
+            int rc;
+
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+            dm = libxl__domain_device_model(gc, b_info);
+            rc = access(dm, X_OK);
+            if (rc < 0) {
+                /* qemu-xen unavailable, use qemu-xen-traditional */
+                if (errno == ENOENT) {
+                    LIBXL__LOG_ERRNO(CTX, XTL_VERBOSE, "qemu-xen is unavailable"
+                            ", use qemu-xen-traditional instead");
+                    b_info->device_model_version =
+                        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+                } else {
+                    LIBXL__LOG_ERRNO(CTX, XTL_ERROR, "qemu-xen access error");
+                    return ERROR_FAIL;
+                }
+            }
+        }
+    }
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
@@ -99,8 +124,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
-    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
-
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
         b_info->device_model_version !=
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:24:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFhL-0003pa-WE; Fri, 20 Apr 2012 15:24:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SLFhK-0003pM-9U
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:24:34 +0000
Received: from [85.158.143.35:52500] by server-2.bemta-4.messagelabs.com id
	4B/D8-17550-1BF719F4; Fri, 20 Apr 2012 15:24:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1334935471!9788026!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14455 invoked from network); 20 Apr 2012 15:24:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208";a="24370687"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 11:24:31 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:24:31 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SLFhB-0003d8-O3; Fri, 20 Apr 2012 16:24:25 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Apr 2012 16:29:53 +0100
Message-ID: <1334935793-23912-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3] libxl: use qemu-xen with PV guests by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

qemu-xen offers better disk performances than qemu-xen-traditional
because it supports Linux native AIO: use it for PV guests if it is
available.

Changes in v3:
- use access instead of stat;
- log the errno.

Changes in v2:
- check for the existence of the qemu-xen binary before setting qemu-xen
as the default device model for PV guests.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_create.c |   33 ++++++++++++++++++++++++++++-----
 1 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..f9c2a76 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -71,9 +71,34 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->type != LIBXL_DOMAIN_TYPE_PV)
         return ERROR_INVAL;
 
-    if (!b_info->device_model_version)
-        b_info->device_model_version =
-            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (!b_info->device_model_version) {
+        if (b_info->type == LIBXL_DOMAIN_TYPE_HVM)
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+        else {
+            const char *dm;
+            int rc;
+
+            b_info->device_model_version =
+                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+            dm = libxl__domain_device_model(gc, b_info);
+            rc = access(dm, X_OK);
+            if (rc < 0) {
+                /* qemu-xen unavailable, use qemu-xen-traditional */
+                if (errno == ENOENT) {
+                    LIBXL__LOG_ERRNO(CTX, XTL_VERBOSE, "qemu-xen is unavailable"
+                            ", use qemu-xen-traditional instead");
+                    b_info->device_model_version =
+                        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+                } else {
+                    LIBXL__LOG_ERRNO(CTX, XTL_ERROR, "qemu-xen access error");
+                    return ERROR_FAIL;
+                }
+            }
+        }
+    }
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
@@ -99,8 +124,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
-    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
-
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
         b_info->device_model_version !=
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:26:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFj2-00041C-MZ; Fri, 20 Apr 2012 15:26:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SLFj1-00040q-D6
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:26:19 +0000
Received: from [85.158.143.35:64059] by server-1.bemta-4.messagelabs.com id
	7B/64-20925-A10819F4; Fri, 20 Apr 2012 15:26:18 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334935575!13386596!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11077 invoked from network); 20 Apr 2012 15:26:17 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:26:17 -0000
Received: by dajx4 with SMTP id x4so14047672daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 08:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=5aDB5tv6Xci9TXTz2XLF605UvPvFYZdBxq0dpEkp7AM=;
	b=gtm4eVgCzlnK4ueSn85tVZ5Hm5mHRmnNoKE80vJmvyk9nGn0hoWhydw5K6wnlcldNL
	wXAJZCpdmdUdevfkb+keGpgMvf8T/WkEipQCMdSK4x27aqXKkucWKGfwgH5UqLBM+0dU
	mbz9NLDog1Cx+9zIPrLwYhJrJaLFzKxNcBw2twm/DztM0NK575O7ci+HzzrbydQfhRv8
	UXddpbu1AO1VFkc8zWd9c8wIQieVkBUjmD2cFIkLims2iVgXKYSZY8xP7jYFmyIhFsXK
	3lUr7eHx6VKRzcRVnq5AtKaN1VeA0VGECWxv/0QmBnZd7dRMUhoZuJ78nkare4tYUA84
	x8DQ==
MIME-Version: 1.0
Received: by 10.68.201.169 with SMTP id kb9mr13391743pbc.146.1334935575468;
	Fri, 20 Apr 2012 08:26:15 -0700 (PDT)
Received: by 10.68.134.228 with HTTP; Fri, 20 Apr 2012 08:26:15 -0700 (PDT)
In-Reply-To: <1334928115.28331.81.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1334928115.28331.81.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 23:26:15 +0800
Message-ID: <CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 9:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering =
with openvpn"):
>> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
>> > > I'm not quite up to speed with all the context here but is the reason
>> > > that you're not suggesting "xen-" is that that's already used for
>> > > something else ?
>> >
>> > This is to distinguish the vif device from the associated tap device,
>> > which would otherwise both be called whatever the user gave as "vifnam=
e"
>> > in their config, so for vifname=3Dfoo you would get foo (the PV one) a=
nd
>> > xen-foo (the EMU one) which does the job but doesn't really distinguish
>> > them.
>>
>> Ah, I see. =A0This sounds like more a job for a suffix than a prefix so
>> if we can spare 4 chars I would suggest foo-emu.

So what is the final prefix/suffix here?  Is it "emu-"?  Sorry, need
to counter check :p

Question... vifname is limited to 16 characters?  If so, does the
configuration for xm/xl check for its allowable length?  I mean if a
user set vifname more than its allowable length in the domU
configuration, would xm/xl show error?

Sorry for asking as it isn't clear in manual... ...
http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
vifname

This keyword is valid for HVM guest devices with type=3Dioemu only.

Specifies the backend device name for an emulated device. The default
is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is the
device number.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

>
> I agree.
>
> This patch interacts a bit with Roger's hotplug series, I'll rebase on
> top of his with this change when he reposts it.

Looking forward for your reports ;)

>
> Ian.
>

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:26:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFj2-00041C-MZ; Fri, 20 Apr 2012 15:26:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SLFj1-00040q-D6
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:26:19 +0000
Received: from [85.158.143.35:64059] by server-1.bemta-4.messagelabs.com id
	7B/64-20925-A10819F4; Fri, 20 Apr 2012 15:26:18 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1334935575!13386596!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11077 invoked from network); 20 Apr 2012 15:26:17 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:26:17 -0000
Received: by dajx4 with SMTP id x4so14047672daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 08:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=5aDB5tv6Xci9TXTz2XLF605UvPvFYZdBxq0dpEkp7AM=;
	b=gtm4eVgCzlnK4ueSn85tVZ5Hm5mHRmnNoKE80vJmvyk9nGn0hoWhydw5K6wnlcldNL
	wXAJZCpdmdUdevfkb+keGpgMvf8T/WkEipQCMdSK4x27aqXKkucWKGfwgH5UqLBM+0dU
	mbz9NLDog1Cx+9zIPrLwYhJrJaLFzKxNcBw2twm/DztM0NK575O7ci+HzzrbydQfhRv8
	UXddpbu1AO1VFkc8zWd9c8wIQieVkBUjmD2cFIkLims2iVgXKYSZY8xP7jYFmyIhFsXK
	3lUr7eHx6VKRzcRVnq5AtKaN1VeA0VGECWxv/0QmBnZd7dRMUhoZuJ78nkare4tYUA84
	x8DQ==
MIME-Version: 1.0
Received: by 10.68.201.169 with SMTP id kb9mr13391743pbc.146.1334935575468;
	Fri, 20 Apr 2012 08:26:15 -0700 (PDT)
Received: by 10.68.134.228 with HTTP; Fri, 20 Apr 2012 08:26:15 -0700 (PDT)
In-Reply-To: <1334928115.28331.81.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1334928115.28331.81.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 23:26:15 +0800
Message-ID: <CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 9:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering =
with openvpn"):
>> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
>> > > I'm not quite up to speed with all the context here but is the reason
>> > > that you're not suggesting "xen-" is that that's already used for
>> > > something else ?
>> >
>> > This is to distinguish the vif device from the associated tap device,
>> > which would otherwise both be called whatever the user gave as "vifnam=
e"
>> > in their config, so for vifname=3Dfoo you would get foo (the PV one) a=
nd
>> > xen-foo (the EMU one) which does the job but doesn't really distinguish
>> > them.
>>
>> Ah, I see. =A0This sounds like more a job for a suffix than a prefix so
>> if we can spare 4 chars I would suggest foo-emu.

So what is the final prefix/suffix here?  Is it "emu-"?  Sorry, need
to counter check :p

Question... vifname is limited to 16 characters?  If so, does the
configuration for xm/xl check for its allowable length?  I mean if a
user set vifname more than its allowable length in the domU
configuration, would xm/xl show error?

Sorry for asking as it isn't clear in manual... ...
http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
vifname

This keyword is valid for HVM guest devices with type=3Dioemu only.

Specifies the backend device name for an emulated device. The default
is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is the
device number.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

>
> I agree.
>
> This patch interacts a bit with Roger's hotplug series, I'll rebase on
> top of his with this change when he reposts it.

Looking forward for your reports ;)

>
> Ian.
>

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:27:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFk8-00048L-5F; Fri, 20 Apr 2012 15:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SLFk6-00048A-Tg
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:27:27 +0000
Received: from [85.158.138.51:33998] by server-2.bemta-3.messagelabs.com id
	BA/BC-09269-E50819F4; Fri, 20 Apr 2012 15:27:26 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334935645!12064674!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12068 invoked from network); 20 Apr 2012 15:27:25 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.206)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 15:27:25 -0000
Received: from mail92-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:27:24 +0000
Received: from mail92-am1 (localhost [127.0.0.1])	by mail92-am1-R.bigfish.com
	(Postfix) with ESMTP id C2454320490;
	Fri, 20 Apr 2012 15:27:24 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail92-am1 (localhost.localdomain [127.0.0.1]) by mail92-am1
	(MessageSwitch) id 1334935642279542_29672;
	Fri, 20 Apr 2012 15:27:22 +0000 (UTC)
Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.253])	by
	mail92-am1.bigfish.com (Postfix) with ESMTP id 3E914C00B5;
	Fri, 20 Apr 2012 15:27:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:27:21 +0000
X-WSS-ID: 0M2SAXJ-01-BTA-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 291F6102815F;	Fri, 20 Apr 2012 10:27:19 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Apr 2012 10:27:37 -0500
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 10:27:18 -0500
Message-ID: <4F918056.3040200@amd.com>
Date: Fri, 20 Apr 2012 11:27:18 -0400
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CBB6E0C6.3E84F%keir@xen.org>
In-Reply-To: <CBB6E0C6.3E84F%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: wei.huang2@amd.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/20/12 04:45, Keir Fraser wrote:
> On 20/04/2012 09:15, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>>
>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>
>> While the patch itself looks fine, I'm having difficulty to connect the
>> mentioning of TSC_MODE_ALWAYS_EMULATE to it - afaics all modes
>> are affected as long as they result in d->arch.vtsc to be set.
>
> I think the real point of this patch is they *never* want to trap and
> emulate RDTSC on these newer processors.


Right. Mentioning TSC_MODE_ALWAYS_EMULATE explicitly wasn't probably a 
particularly good idea.

The reason I did that was because with TSC_MODE_DEFAULT guests (at least 
Linux guests) typically don't use TSC since TSC ends up being declared 
non-invariant.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:27:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFk8-00048L-5F; Fri, 20 Apr 2012 15:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SLFk6-00048A-Tg
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:27:27 +0000
Received: from [85.158.138.51:33998] by server-2.bemta-3.messagelabs.com id
	BA/BC-09269-E50819F4; Fri, 20 Apr 2012 15:27:26 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334935645!12064674!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12068 invoked from network); 20 Apr 2012 15:27:25 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.206)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 15:27:25 -0000
Received: from mail92-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:27:24 +0000
Received: from mail92-am1 (localhost [127.0.0.1])	by mail92-am1-R.bigfish.com
	(Postfix) with ESMTP id C2454320490;
	Fri, 20 Apr 2012 15:27:24 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail92-am1 (localhost.localdomain [127.0.0.1]) by mail92-am1
	(MessageSwitch) id 1334935642279542_29672;
	Fri, 20 Apr 2012 15:27:22 +0000 (UTC)
Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.253])	by
	mail92-am1.bigfish.com (Postfix) with ESMTP id 3E914C00B5;
	Fri, 20 Apr 2012 15:27:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 15:27:21 +0000
X-WSS-ID: 0M2SAXJ-01-BTA-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 291F6102815F;	Fri, 20 Apr 2012 10:27:19 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Apr 2012 10:27:37 -0500
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 10:27:18 -0500
Message-ID: <4F918056.3040200@amd.com>
Date: Fri, 20 Apr 2012 11:27:18 -0400
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CBB6E0C6.3E84F%keir@xen.org>
In-Reply-To: <CBB6E0C6.3E84F%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: wei.huang2@amd.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/20/12 04:45, Keir Fraser wrote:
> On 20/04/2012 09:15, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>>
>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>
>> While the patch itself looks fine, I'm having difficulty to connect the
>> mentioning of TSC_MODE_ALWAYS_EMULATE to it - afaics all modes
>> are affected as long as they result in d->arch.vtsc to be set.
>
> I think the real point of this patch is they *never* want to trap and
> emulate RDTSC on these newer processors.


Right. Mentioning TSC_MODE_ALWAYS_EMULATE explicitly wasn't probably a 
particularly good idea.

The reason I did that was because with TSC_MODE_DEFAULT guests (at least 
Linux guests) typically don't use TSC since TSC ends up being declared 
non-invariant.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFuW-0004QJ-Ig; Fri, 20 Apr 2012 15:38:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLFuU-0004QE-DA
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:38:10 +0000
Received: from [85.158.139.83:25655] by server-3.bemta-5.messagelabs.com id
	FA/7C-25237-1E2819F4; Fri, 20 Apr 2012 15:38:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334936288!24762560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15683 invoked from network); 20 Apr 2012 15:38:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:38:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12053273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 16:38:07 +0100
Message-ID: <1334936286.28331.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Fri, 20 Apr 2012 16:38:06 +0100
In-Reply-To: <CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1334928115.28331.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 16:26 +0100, Teck Choon Giam wrote:
> On Fri, Apr 20, 2012 at 9:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
> >> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> >> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> >> > > I'm not quite up to speed with all the context here but is the reason
> >> > > that you're not suggesting "xen-" is that that's already used for
> >> > > something else ?
> >> >
> >> > This is to distinguish the vif device from the associated tap device,
> >> > which would otherwise both be called whatever the user gave as "vifname"
> >> > in their config, so for vifname=foo you would get foo (the PV one) and
> >> > xen-foo (the EMU one) which does the job but doesn't really distinguish
> >> > them.
> >>
> >> Ah, I see.  This sounds like more a job for a suffix than a prefix so
> >> if we can spare 4 chars I would suggest foo-emu.
> 
> So what is the final prefix/suffix here?  Is it "emu-"?  Sorry, need
> to counter check :p

I think we have agreed on a "-emu" suffix.

> Question... vifname is limited to 16 characters?  If so, does the
> configuration for xm/xl check for its allowable length?  I mean if a
> user set vifname more than its allowable length in the domU
> configuration, would xm/xl show error?

I can't see any existing check for the length of the vif name.

It's a bit hard for us to do, consider a network driver domain running a
kernel which has a different, or no, limit here. libxl might not have
any idea what that name limit should be. We could pick an arbitrary
limit which is the smallest we know of, e.g. 12 chars (to allow +4), I
suppose.

BTW, the failure if your name is too long will be that the vif hotplug
script will fail to rename the device.

This limit has long existed and I don't recall ever having seen a report
about it, maybe the failure case is so obvious that people just fix it
and move on. I also expect that setting such a long name is rare...

> 
> Sorry for asking as it isn't clear in manual... ...
> http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html
> ================================
> vifname
> 
> This keyword is valid for HVM guest devices with type=ioemu only.
> 
> Specifies the backend device name for an emulated device. The default
> is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is the
> device number.
> ================================
> 
> >
> > I agree.
> >
> > This patch interacts a bit with Roger's hotplug series, I'll rebase on
> > top of his with this change when he reposts it.
> 
> Looking forward for your reports ;)
> 
> >
> > Ian.
> >
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFuW-0004QJ-Ig; Fri, 20 Apr 2012 15:38:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLFuU-0004QE-DA
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:38:10 +0000
Received: from [85.158.139.83:25655] by server-3.bemta-5.messagelabs.com id
	FA/7C-25237-1E2819F4; Fri, 20 Apr 2012 15:38:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1334936288!24762560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15683 invoked from network); 20 Apr 2012 15:38:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 15:38:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="12053273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 15:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 16:38:07 +0100
Message-ID: <1334936286.28331.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Fri, 20 Apr 2012 16:38:06 +0100
In-Reply-To: <CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1334928115.28331.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 16:26 +0100, Teck Choon Giam wrote:
> On Fri, Apr 20, 2012 at 9:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
> >> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> >> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> >> > > I'm not quite up to speed with all the context here but is the reason
> >> > > that you're not suggesting "xen-" is that that's already used for
> >> > > something else ?
> >> >
> >> > This is to distinguish the vif device from the associated tap device,
> >> > which would otherwise both be called whatever the user gave as "vifname"
> >> > in their config, so for vifname=foo you would get foo (the PV one) and
> >> > xen-foo (the EMU one) which does the job but doesn't really distinguish
> >> > them.
> >>
> >> Ah, I see.  This sounds like more a job for a suffix than a prefix so
> >> if we can spare 4 chars I would suggest foo-emu.
> 
> So what is the final prefix/suffix here?  Is it "emu-"?  Sorry, need
> to counter check :p

I think we have agreed on a "-emu" suffix.

> Question... vifname is limited to 16 characters?  If so, does the
> configuration for xm/xl check for its allowable length?  I mean if a
> user set vifname more than its allowable length in the domU
> configuration, would xm/xl show error?

I can't see any existing check for the length of the vif name.

It's a bit hard for us to do, consider a network driver domain running a
kernel which has a different, or no, limit here. libxl might not have
any idea what that name limit should be. We could pick an arbitrary
limit which is the smallest we know of, e.g. 12 chars (to allow +4), I
suppose.

BTW, the failure if your name is too long will be that the vif hotplug
script will fail to rename the device.

This limit has long existed and I don't recall ever having seen a report
about it, maybe the failure case is so obvious that people just fix it
and move on. I also expect that setting such a long name is rare...

> 
> Sorry for asking as it isn't clear in manual... ...
> http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html
> ================================
> vifname
> 
> This keyword is valid for HVM guest devices with type=ioemu only.
> 
> Specifies the backend device name for an emulated device. The default
> is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is the
> device number.
> ================================
> 
> >
> > I agree.
> >
> > This patch interacts a bit with Roger's hotplug series, I'll rebase on
> > top of his with this change when he reposts it.
> 
> Looking forward for your reports ;)
> 
> >
> > Ian.
> >
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFx4-0004fq-5S; Fri, 20 Apr 2012 15:40:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLFx2-0004fk-Il
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:40:48 +0000
Received: from [85.158.143.99:48316] by server-2.bemta-4.messagelabs.com id
	16/6D-17550-F73819F4; Fri, 20 Apr 2012 15:40:47 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334936445!24023154!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15816 invoked from network); 20 Apr 2012 15:40:46 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-216.messagelabs.com with SMTP;
	20 Apr 2012 15:40:46 -0000
Received: from [192.168.1.200] (unknown [180.158.123.16])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id C46BDDB970;
	Fri, 20 Apr 2012 23:40:18 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334934367.28331.99.camel@zakaz.uk.xensource.com>
References: <1334913957.2863.1.camel@hp6530s>	<4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
	<1334934367.28331.99.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 23:39:24 +0800
Message-ID: <1334936364.2863.24.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 16:06 +0100, Ian Campbell wrote:
> On Fri, 2012-04-20 at 15:50 +0100, Lin Ming wrote:
> > On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> > >> >
> > >> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> > >> > appropriate/
> > >>
> > >> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> > >> be -EPERM).
> > >
> > > So either the guest has called a hypercall which it is not permitted to
> > > or it has called it with invalid parameters of one sort or another. Both
> > > of these would be a code bug in the guest and therefore asserting that
> > > no failure occurred is reasonable?
> > >
> > > What could the caller do with the error other than log it and collapse?
> > >
> > >> The call into Xen itself will return 0 as a value if an
> > >> invalid physbase is passed in the hypercall.

Just checked ioapic_guest_read.
It will return -EINVAL if an invalid physbase is passed in.

> > >
> > >> So a BUG_ON() is not safe/sensible for domU.
> > >
> > > I think you have successfully argued that it is ;-)
> > 
> > BUG_ON is too severe.
> 
> Why? Under what circumstances can this be correctly called in a way
> which would result in the hypercall failing?

Is BUG_ON() reasonable if invalid physbase passed in?

> 
> >  How about WARN_ON?
> > 
> > ret = hypercall(...)
> > 
> > if (ret) {
> >    WARN_ON(1);
> >    return -1;
> > }
> > 
> > 
> > >
> > > Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 15:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 15:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLFx4-0004fq-5S; Fri, 20 Apr 2012 15:40:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SLFx2-0004fk-Il
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 15:40:48 +0000
Received: from [85.158.143.99:48316] by server-2.bemta-4.messagelabs.com id
	16/6D-17550-F73819F4; Fri, 20 Apr 2012 15:40:47 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-11.tower-216.messagelabs.com!1334936445!24023154!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15816 invoked from network); 20 Apr 2012 15:40:46 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-11.tower-216.messagelabs.com with SMTP;
	20 Apr 2012 15:40:46 -0000
Received: from [192.168.1.200] (unknown [180.158.123.16])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id C46BDDB970;
	Fri, 20 Apr 2012 23:40:18 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334934367.28331.99.camel@zakaz.uk.xensource.com>
References: <1334913957.2863.1.camel@hp6530s>	<4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
	<1334934367.28331.99.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Apr 2012 23:39:24 +0800
Message-ID: <1334936364.2863.24.camel@hp6530s>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 16:06 +0100, Ian Campbell wrote:
> On Fri, 2012-04-20 at 15:50 +0100, Lin Ming wrote:
> > On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> > >> >
> > >> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> > >> > appropriate/
> > >>
> > >> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> > >> be -EPERM).
> > >
> > > So either the guest has called a hypercall which it is not permitted to
> > > or it has called it with invalid parameters of one sort or another. Both
> > > of these would be a code bug in the guest and therefore asserting that
> > > no failure occurred is reasonable?
> > >
> > > What could the caller do with the error other than log it and collapse?
> > >
> > >> The call into Xen itself will return 0 as a value if an
> > >> invalid physbase is passed in the hypercall.

Just checked ioapic_guest_read.
It will return -EINVAL if an invalid physbase is passed in.

> > >
> > >> So a BUG_ON() is not safe/sensible for domU.
> > >
> > > I think you have successfully argued that it is ;-)
> > 
> > BUG_ON is too severe.
> 
> Why? Under what circumstances can this be correctly called in a way
> which would result in the hypercall failing?

Is BUG_ON() reasonable if invalid physbase passed in?

> 
> >  How about WARN_ON?
> > 
> > ret = hypercall(...)
> > 
> > if (ret) {
> >    WARN_ON(1);
> >    return -1;
> > }
> > 
> > 
> > >
> > > Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:06:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGLt-0005NE-EG; Fri, 20 Apr 2012 16:06:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGLs-0005N9-8o
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:06:28 +0000
Received: from [193.109.254.147:42233] by server-12.bemta-14.messagelabs.com
	id EB/F8-05898-389819F4; Fri, 20 Apr 2012 16:06:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334937984!5540032!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDkyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2100 invoked from network); 20 Apr 2012 16:06:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 16:06:26 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KG6Ktl001788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:06:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KG6IEc006723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:06:19 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KG6Ion000320; Fri, 20 Apr 2012 11:06:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:06:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1559740280; Fri, 20 Apr 2012 12:01:19 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:01:19 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120420160118.GA2291@phenom.dumpdata.com>
References: <20120420105112.GA21487@elgon.mountain>
	<alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
	<20120420113557.GJ27101@mwanda>
	<alpine.DEB.2.00.1204201418400.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204201418400.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F91897D.00A4,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
 list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 02:36:59PM +0100, Stefano Stabellini wrote:
> On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > On Fri, Apr 20, 2012 at 12:23:21PM +0100, Stefano Stabellini wrote:
> > > On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > > > Hi Stefano,
> > > > 
> > > > I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> > > > list_for_each_entry_safe".
> > > > 
> > > > I think there is a misunderstanding about what the
> > > > list_for_each_entry_safe() macro does.  It has nothing to do with
> > > > locking, so the spinlock is still needed.  Without the lock ->next could
> > > > point to an element which has been deleted in another thread.  Probably
> > > > the patch should be reverted.
> > > 
> > > I thought that list_for_each_entry_safe is safe against deletion, is it
> > > not?
> > > It doesn't matter whether we get up to date entries or old entries
> > > here as long as walking through the list doesn't break if a concurrent
> > > thread adds or removes items.
> > > 
> > 
> > It's safe against deletion in the same thread.  But not against
> > deletion from another thread.
> > 
> > At the beginning of the loop it stores a pointer to the next
> > element.  If you delete the element you are on, no problem because
> > you already have a pointer to the next one.  But if another thread
> > deletes the next element, now you have a pointer which is wrong.
> 
> The problem is not that the next element is wrong because we should be
> able to cope with that.
> The problem is that the next->next pointer would be set LIST_POISON1.
> 
> Maybe replacing our call to list_del with __list_del would be sufficient
> to solve the problem?
> Probably it is best to revert the patch at this stage.

ok, reverted.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:06:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGLt-0005NE-EG; Fri, 20 Apr 2012 16:06:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGLs-0005N9-8o
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:06:28 +0000
Received: from [193.109.254.147:42233] by server-12.bemta-14.messagelabs.com
	id EB/F8-05898-389819F4; Fri, 20 Apr 2012 16:06:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334937984!5540032!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDkyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2100 invoked from network); 20 Apr 2012 16:06:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 16:06:26 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KG6Ktl001788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:06:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KG6IEc006723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:06:19 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KG6Ion000320; Fri, 20 Apr 2012 11:06:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:06:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1559740280; Fri, 20 Apr 2012 12:01:19 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:01:19 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120420160118.GA2291@phenom.dumpdata.com>
References: <20120420105112.GA21487@elgon.mountain>
	<alpine.DEB.2.00.1204201213100.26786@kaball-desktop>
	<20120420113557.GJ27101@mwanda>
	<alpine.DEB.2.00.1204201418400.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204201418400.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F91897D.00A4,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] xen/p2m: m2p_find_override: use
 list_for_each_entry_safe
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 02:36:59PM +0100, Stefano Stabellini wrote:
> On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > On Fri, Apr 20, 2012 at 12:23:21PM +0100, Stefano Stabellini wrote:
> > > On Fri, 20 Apr 2012, Dan Carpenter wrote:
> > > > Hi Stefano,
> > > > 
> > > > I had a question about 8f2854c74ff4: "xen/p2m: m2p_find_override: use
> > > > list_for_each_entry_safe".
> > > > 
> > > > I think there is a misunderstanding about what the
> > > > list_for_each_entry_safe() macro does.  It has nothing to do with
> > > > locking, so the spinlock is still needed.  Without the lock ->next could
> > > > point to an element which has been deleted in another thread.  Probably
> > > > the patch should be reverted.
> > > 
> > > I thought that list_for_each_entry_safe is safe against deletion, is it
> > > not?
> > > It doesn't matter whether we get up to date entries or old entries
> > > here as long as walking through the list doesn't break if a concurrent
> > > thread adds or removes items.
> > > 
> > 
> > It's safe against deletion in the same thread.  But not against
> > deletion from another thread.
> > 
> > At the beginning of the loop it stores a pointer to the next
> > element.  If you delete the element you are on, no problem because
> > you already have a pointer to the next one.  But if another thread
> > deletes the next element, now you have a pointer which is wrong.
> 
> The problem is not that the next element is wrong because we should be
> able to cope with that.
> The problem is that the next->next pointer would be set LIST_POISON1.
> 
> Maybe replacing our call to list_del with __list_del would be sufficient
> to solve the problem?
> Probably it is best to revert the patch at this stage.

ok, reverted.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGPa-0005Vt-2y; Fri, 20 Apr 2012 16:10:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <minggr@gmail.com>) id 1SLGPY-0005Vj-Fg
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:10:16 +0000
Received: from [193.109.254.147:62030] by server-7.bemta-14.messagelabs.com id
	0C/28-01627-76A819F4; Fri, 20 Apr 2012 16:10:15 +0000
X-Env-Sender: minggr@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334938210!5540581!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12914 invoked from network); 20 Apr 2012 16:10:12 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:10:12 -0000
Received: by dajx4 with SMTP id x4so14099241daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:10:09 -0700 (PDT)
Received: by 10.68.211.42 with SMTP id mz10mr8260204pbc.148.1334938209762;
	Fri, 20 Apr 2012 09:10:09 -0700 (PDT)
Received: from chief-river.localdomain ([180.158.123.16])
	by mx.google.com with ESMTPS id qb8sm5722236pbb.12.2012.04.20.09.10.03
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:10:07 -0700 (PDT)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 21 Apr 2012 00:11:03 +0800
Message-Id: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH v2 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

v2: 
- fix compile issues if no CONFIG_SMP, Konrad Rzeszutek Wilk
- move inc_irq_stat after irq_work_run

These 2 patches fixed the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506

Both Steven and I tested it and "perf top" works well now.

The soft lockup code path is:

__irq_work_queue
  arch_irq_work_raise
    apic->send_IPI_self(IRQ_WORK_VECTOR);
      apic_send_IPI_self
        __default_send_IPI_shortcut
          __xapic_wait_icr_idle

static inline void __xapic_wait_icr_idle(void)
{
        while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
                cpu_relax();
}
The lockup happens at above while looop.

The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.

So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.

Ben Guthro (1):
      xen: implement apic ipi interface

Lin Ming (1):
      xen: implement IRQ_WORK_VECTOR handler

 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/enlighten.c          |    9 +++
 arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
 arch/x86/xen/smp.h                |   12 ++++
 4 files changed, 129 insertions(+), 4 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGPa-0005Vt-2y; Fri, 20 Apr 2012 16:10:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <minggr@gmail.com>) id 1SLGPY-0005Vj-Fg
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:10:16 +0000
Received: from [193.109.254.147:62030] by server-7.bemta-14.messagelabs.com id
	0C/28-01627-76A819F4; Fri, 20 Apr 2012 16:10:15 +0000
X-Env-Sender: minggr@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334938210!5540581!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12914 invoked from network); 20 Apr 2012 16:10:12 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:10:12 -0000
Received: by dajx4 with SMTP id x4so14099241daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:10:09 -0700 (PDT)
Received: by 10.68.211.42 with SMTP id mz10mr8260204pbc.148.1334938209762;
	Fri, 20 Apr 2012 09:10:09 -0700 (PDT)
Received: from chief-river.localdomain ([180.158.123.16])
	by mx.google.com with ESMTPS id qb8sm5722236pbb.12.2012.04.20.09.10.03
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:10:07 -0700 (PDT)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 21 Apr 2012 00:11:03 +0800
Message-Id: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH v2 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

v2: 
- fix compile issues if no CONFIG_SMP, Konrad Rzeszutek Wilk
- move inc_irq_stat after irq_work_run

These 2 patches fixed the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506

Both Steven and I tested it and "perf top" works well now.

The soft lockup code path is:

__irq_work_queue
  arch_irq_work_raise
    apic->send_IPI_self(IRQ_WORK_VECTOR);
      apic_send_IPI_self
        __default_send_IPI_shortcut
          __xapic_wait_icr_idle

static inline void __xapic_wait_icr_idle(void)
{
        while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
                cpu_relax();
}
The lockup happens at above while looop.

The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.

So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.

Ben Guthro (1):
      xen: implement apic ipi interface

Lin Ming (1):
      xen: implement IRQ_WORK_VECTOR handler

 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/enlighten.c          |    9 +++
 arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
 arch/x86/xen/smp.h                |   12 ++++
 4 files changed, 129 insertions(+), 4 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGPh-0005X0-34; Fri, 20 Apr 2012 16:10:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <minggr@gmail.com>) id 1SLGPf-0005WZ-FI
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:10:23 +0000
Received: from [85.158.138.51:6435] by server-2.bemta-3.messagelabs.com id
	5E/8A-09269-E6A819F4; Fri, 20 Apr 2012 16:10:22 +0000
X-Env-Sender: minggr@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334938219!23086924!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20281 invoked from network); 20 Apr 2012 16:10:21 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:10:21 -0000
Received: by dajx4 with SMTP id x4so14099426daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:10:19 -0700 (PDT)
Received: by 10.68.229.131 with SMTP id sq3mr567624pbc.106.1334938219144;
	Fri, 20 Apr 2012 09:10:19 -0700 (PDT)
Received: from chief-river.localdomain ([180.158.123.16])
	by mx.google.com with ESMTPS id qb8sm5722236pbb.12.2012.04.20.09.10.14
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:10:18 -0700 (PDT)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 21 Apr 2012 00:11:05 +0800
Message-Id: <1334938265-3844-3-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH v2 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/smp.c                |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index 1df3541..cc146d5 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -6,6 +6,7 @@ enum ipi_vector {
 	XEN_CALL_FUNCTION_VECTOR,
 	XEN_CALL_FUNCTION_SINGLE_VECTOR,
 	XEN_SPIN_UNLOCK_VECTOR,
+	XEN_IRQ_WORK_VECTOR,
 
 	XEN_NR_IPIS,
 };
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2dc6628..3ec3f8e 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
+#include <linux/irq_work.h>
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
@@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
 static DEFINE_PER_CPU(int, xen_resched_irq);
 static DEFINE_PER_CPU(int, xen_callfunc_irq);
 static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
+static DEFINE_PER_CPU(int, xen_irq_work);
 static DEFINE_PER_CPU(int, xen_debug_irq) = -1;
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
  * Reschedule call back.
@@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
 		goto fail;
 	per_cpu(xen_callfuncsingle_irq, cpu) = rc;
 
+	callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
+	rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
+				    cpu,
+				    xen_irq_work_interrupt,
+				    IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
+				    callfunc_name,
+				    NULL);
+	if (rc < 0)
+		goto fail;
+	per_cpu(xen_irq_work, cpu) = rc;
+
 	return 0;
 
  fail:
@@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
 	if (per_cpu(xen_callfuncsingle_irq, cpu) >= 0)
 		unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),
 				       NULL);
+	if (per_cpu(xen_irq_work, cpu) >= 0)
+		unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 
 	return rc;
 }
@@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
 	case CALL_FUNCTION_SINGLE_VECTOR:
 		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
 		break;
+	case IRQ_WORK_VECTOR:
+		xen_vector = XEN_IRQ_WORK_VECTOR;
+		break;
 	default:
 		xen_vector = -1;
 		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
@@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
+{
+	irq_enter();
+	irq_work_run();
+	inc_irq_stat(apic_irq_work_irqs);
+	irq_exit();
+
+	return IRQ_HANDLED;
+}
+
 static const struct smp_ops xen_smp_ops __initconst = {
 	.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
 	.smp_prepare_cpus = xen_smp_prepare_cpus,
@@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
 	unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu), NULL);
+	unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 	native_cpu_die(cpu);
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGPh-0005X0-34; Fri, 20 Apr 2012 16:10:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <minggr@gmail.com>) id 1SLGPf-0005WZ-FI
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:10:23 +0000
Received: from [85.158.138.51:6435] by server-2.bemta-3.messagelabs.com id
	5E/8A-09269-E6A819F4; Fri, 20 Apr 2012 16:10:22 +0000
X-Env-Sender: minggr@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1334938219!23086924!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20281 invoked from network); 20 Apr 2012 16:10:21 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:10:21 -0000
Received: by dajx4 with SMTP id x4so14099426daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:10:19 -0700 (PDT)
Received: by 10.68.229.131 with SMTP id sq3mr567624pbc.106.1334938219144;
	Fri, 20 Apr 2012 09:10:19 -0700 (PDT)
Received: from chief-river.localdomain ([180.158.123.16])
	by mx.google.com with ESMTPS id qb8sm5722236pbb.12.2012.04.20.09.10.14
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:10:18 -0700 (PDT)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 21 Apr 2012 00:11:05 +0800
Message-Id: <1334938265-3844-3-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH v2 2/2] xen: implement IRQ_WORK_VECTOR handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/smp.c                |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index 1df3541..cc146d5 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -6,6 +6,7 @@ enum ipi_vector {
 	XEN_CALL_FUNCTION_VECTOR,
 	XEN_CALL_FUNCTION_SINGLE_VECTOR,
 	XEN_SPIN_UNLOCK_VECTOR,
+	XEN_IRQ_WORK_VECTOR,
 
 	XEN_NR_IPIS,
 };
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2dc6628..3ec3f8e 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
+#include <linux/irq_work.h>
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
@@ -41,10 +42,12 @@ cpumask_var_t xen_cpu_initialized_map;
 static DEFINE_PER_CPU(int, xen_resched_irq);
 static DEFINE_PER_CPU(int, xen_callfunc_irq);
 static DEFINE_PER_CPU(int, xen_callfuncsingle_irq);
+static DEFINE_PER_CPU(int, xen_irq_work);
 static DEFINE_PER_CPU(int, xen_debug_irq) = -1;
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
  * Reschedule call back.
@@ -143,6 +146,17 @@ static int xen_smp_intr_init(unsigned int cpu)
 		goto fail;
 	per_cpu(xen_callfuncsingle_irq, cpu) = rc;
 
+	callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
+	rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
+				    cpu,
+				    xen_irq_work_interrupt,
+				    IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING,
+				    callfunc_name,
+				    NULL);
+	if (rc < 0)
+		goto fail;
+	per_cpu(xen_irq_work, cpu) = rc;
+
 	return 0;
 
  fail:
@@ -155,6 +169,8 @@ static int xen_smp_intr_init(unsigned int cpu)
 	if (per_cpu(xen_callfuncsingle_irq, cpu) >= 0)
 		unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu),
 				       NULL);
+	if (per_cpu(xen_irq_work, cpu) >= 0)
+		unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 
 	return rc;
 }
@@ -509,6 +525,9 @@ static inline int xen_map_vector(int vector)
 	case CALL_FUNCTION_SINGLE_VECTOR:
 		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
 		break;
+	case IRQ_WORK_VECTOR:
+		xen_vector = XEN_IRQ_WORK_VECTOR;
+		break;
 	default:
 		xen_vector = -1;
 		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
@@ -588,6 +607,16 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
+{
+	irq_enter();
+	irq_work_run();
+	inc_irq_stat(apic_irq_work_irqs);
+	irq_exit();
+
+	return IRQ_HANDLED;
+}
+
 static const struct smp_ops xen_smp_ops __initconst = {
 	.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
 	.smp_prepare_cpus = xen_smp_prepare_cpus,
@@ -634,6 +663,7 @@ static void xen_hvm_cpu_die(unsigned int cpu)
 	unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
 	unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu), NULL);
+	unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL);
 	native_cpu_die(cpu);
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:10:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGPe-0005WJ-G4; Fri, 20 Apr 2012 16:10:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <minggr@gmail.com>) id 1SLGPd-0005W6-C7
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:10:21 +0000
Received: from [193.109.254.147:33825] by server-3.bemta-14.messagelabs.com id
	CF/F3-23274-C6A819F4; Fri, 20 Apr 2012 16:10:20 +0000
X-Env-Sender: minggr@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334938210!5540581!2
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13035 invoked from network); 20 Apr 2012 16:10:15 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:10:15 -0000
Received: by mail-pz0-f41.google.com with SMTP id x4so14099241daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:10:14 -0700 (PDT)
Received: by 10.68.211.104 with SMTP id nb8mr14139363pbc.40.1334938214489;
	Fri, 20 Apr 2012 09:10:14 -0700 (PDT)
Received: from chief-river.localdomain ([180.158.123.16])
	by mx.google.com with ESMTPS id qb8sm5722236pbb.12.2012.04.20.09.10.10
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:10:13 -0700 (PDT)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 21 Apr 2012 00:11:04 +0800
Message-Id: <1334938265-3844-2-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH v2 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ben Guthro <ben@guthro.net>

Map native ipi vector to xen vector.
Implement apic ipi interface with xen_send_IPI_one.

Tested-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Ben Guthro <ben@guthro.net>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/xen/enlighten.c |    9 +++++
 arch/x86/xen/smp.c       |   81 +++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/smp.h       |   12 +++++++
 3 files changed, 98 insertions(+), 4 deletions(-)
 create mode 100644 arch/x86/xen/smp.h

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..1ed61c2 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -74,6 +74,7 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
+#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -849,6 +850,14 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+
+#ifdef CONFIG_SMP
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
+#endif
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..2dc6628 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -465,8 +465,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+static void __xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
 {
 	unsigned cpu;
 
@@ -478,7 +478,7 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 {
 	int cpu;
 
-	xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
+	__xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
 
 	/* Make sure other vcpus get a chance to run if they need to. */
 	for_each_cpu(cpu, mask) {
@@ -491,10 +491,83 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 
 static void xen_smp_send_call_function_single_ipi(int cpu)
 {
-	xen_send_IPI_mask(cpumask_of(cpu),
+	__xen_send_IPI_mask(cpumask_of(cpu),
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
+static inline int xen_map_vector(int vector)
+{
+	int xen_vector;
+
+	switch (vector) {
+	case RESCHEDULE_VECTOR:
+		xen_vector = XEN_RESCHEDULE_VECTOR;
+		break;
+	case CALL_FUNCTION_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_VECTOR;
+		break;
+	case CALL_FUNCTION_SINGLE_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
+		break;
+	default:
+		xen_vector = -1;
+		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
+			vector);
+	}
+
+	return xen_vector;
+}
+
+void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(mask, xen_vector);
+}
+
+void xen_send_IPI_all(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(cpu_online_mask, xen_vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_one(smp_processor_id(), xen_vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+
+	if (!(num_online_cpus() > 1))
+		return;
+
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
+}
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8981a76
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:10:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGPe-0005WJ-G4; Fri, 20 Apr 2012 16:10:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <minggr@gmail.com>) id 1SLGPd-0005W6-C7
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:10:21 +0000
Received: from [193.109.254.147:33825] by server-3.bemta-14.messagelabs.com id
	CF/F3-23274-C6A819F4; Fri, 20 Apr 2012 16:10:20 +0000
X-Env-Sender: minggr@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1334938210!5540581!2
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13035 invoked from network); 20 Apr 2012 16:10:15 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:10:15 -0000
Received: by mail-pz0-f41.google.com with SMTP id x4so14099241daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:10:14 -0700 (PDT)
Received: by 10.68.211.104 with SMTP id nb8mr14139363pbc.40.1334938214489;
	Fri, 20 Apr 2012 09:10:14 -0700 (PDT)
Received: from chief-river.localdomain ([180.158.123.16])
	by mx.google.com with ESMTPS id qb8sm5722236pbb.12.2012.04.20.09.10.10
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:10:13 -0700 (PDT)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sat, 21 Apr 2012 00:11:04 +0800
Message-Id: <1334938265-3844-2-git-send-email-mlin@ss.pku.edu.cn>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
References: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH v2 1/2] xen: implement apic ipi interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ben Guthro <ben@guthro.net>

Map native ipi vector to xen vector.
Implement apic ipi interface with xen_send_IPI_one.

Tested-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Ben Guthro <ben@guthro.net>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
 arch/x86/xen/enlighten.c |    9 +++++
 arch/x86/xen/smp.c       |   81 +++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/smp.h       |   12 +++++++
 3 files changed, 98 insertions(+), 4 deletions(-)
 create mode 100644 arch/x86/xen/smp.h

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..1ed61c2 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -74,6 +74,7 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
+#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -849,6 +850,14 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+
+#ifdef CONFIG_SMP
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
+#endif
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..2dc6628 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -465,8 +465,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+static void __xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
 {
 	unsigned cpu;
 
@@ -478,7 +478,7 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 {
 	int cpu;
 
-	xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
+	__xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR);
 
 	/* Make sure other vcpus get a chance to run if they need to. */
 	for_each_cpu(cpu, mask) {
@@ -491,10 +491,83 @@ static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 
 static void xen_smp_send_call_function_single_ipi(int cpu)
 {
-	xen_send_IPI_mask(cpumask_of(cpu),
+	__xen_send_IPI_mask(cpumask_of(cpu),
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
+static inline int xen_map_vector(int vector)
+{
+	int xen_vector;
+
+	switch (vector) {
+	case RESCHEDULE_VECTOR:
+		xen_vector = XEN_RESCHEDULE_VECTOR;
+		break;
+	case CALL_FUNCTION_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_VECTOR;
+		break;
+	case CALL_FUNCTION_SINGLE_VECTOR:
+		xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
+		break;
+	default:
+		xen_vector = -1;
+		printk(KERN_ERR "xen: vector 0x%x is not implemented\n",
+			vector);
+	}
+
+	return xen_vector;
+}
+
+void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(mask, xen_vector);
+}
+
+void xen_send_IPI_all(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		__xen_send_IPI_mask(cpu_online_mask, xen_vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_one(smp_processor_id(), xen_vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+
+	if (!(num_online_cpus() > 1))
+		return;
+
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	int xen_vector = xen_map_vector(vector);
+
+	if (xen_vector >= 0)
+		xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
+}
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8981a76
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGfZ-0006FG-Sg; Fri, 20 Apr 2012 16:26:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGfY-0006FB-4O
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:26:48 +0000
Received: from [85.158.143.99:30959] by server-2.bemta-4.messagelabs.com id
	A1/8E-17550-74E819F4; Fri, 20 Apr 2012 16:26:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334939205!24548089!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 20 Apr 2012 16:26:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 16:26:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGQbaX011644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:26:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGQZl8014723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:26:35 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGQYju017762; Fri, 20 Apr 2012 11:26:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:26:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DE2C44031D; Fri, 20 Apr 2012 12:21:34 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:21:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120420162134.GB28366@phenom.dumpdata.com>
References: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F918E3E.00AF,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH v2 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 21, 2012 at 12:11:03AM +0800, Lin Ming wrote:
> v2: 
> - fix compile issues if no CONFIG_SMP, Konrad Rzeszutek Wilk
> - move inc_irq_stat after irq_work_run

They look good to me (and they work nicely - thanks!)
so putting in the 3.5  queue.

> 
> These 2 patches fixed the "perf top" soft lockups under Xen
> reported by Steven at: https://lkml.org/lkml/2012/2/9/506
> 
> Both Steven and I tested it and "perf top" works well now.
> 
> The soft lockup code path is:
> 
> __irq_work_queue
>   arch_irq_work_raise
>     apic->send_IPI_self(IRQ_WORK_VECTOR);
>       apic_send_IPI_self
>         __default_send_IPI_shortcut
>           __xapic_wait_icr_idle
> 
> static inline void __xapic_wait_icr_idle(void)
> {
>         while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
>                 cpu_relax();
> }
> The lockup happens at above while looop.
> 
> The cause is that Xen has not implemented the APIC IPI interface yet.
> Xen has IPI interface: xen_send_IPI_one, but it's only used in
> xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
> xen_smp_send_call_function_single_ipi, etc.
> 
> So we need to implement Xen's APIC IPI interface as Ben's patch does.
> And implement Xen's IRQ_WORK_VECTOR handler.
> 
> Ben Guthro (1):
>       xen: implement apic ipi interface
> 
> Lin Ming (1):
>       xen: implement IRQ_WORK_VECTOR handler
> 
>  arch/x86/include/asm/xen/events.h |    1 +
>  arch/x86/xen/enlighten.c          |    9 +++
>  arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
>  arch/x86/xen/smp.h                |   12 ++++
>  4 files changed, 129 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGfZ-0006FG-Sg; Fri, 20 Apr 2012 16:26:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGfY-0006FB-4O
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:26:48 +0000
Received: from [85.158.143.99:30959] by server-2.bemta-4.messagelabs.com id
	A1/8E-17550-74E819F4; Fri, 20 Apr 2012 16:26:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334939205!24548089!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 20 Apr 2012 16:26:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 16:26:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGQbaX011644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:26:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGQZl8014723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:26:35 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGQYju017762; Fri, 20 Apr 2012 11:26:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:26:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DE2C44031D; Fri, 20 Apr 2012 12:21:34 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:21:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120420162134.GB28366@phenom.dumpdata.com>
References: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334938265-3844-1-git-send-email-mlin@ss.pku.edu.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F918E3E.00AF,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Noonan <steven@uplinklabs.net>, linux-kernel@vger.kernel.org,
	Marcus Granado <marcus.granado@citrix.com>,
	xen-devel@lists.xen.org, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH v2 0/2] fix "perf top" soft lockups under Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 21, 2012 at 12:11:03AM +0800, Lin Ming wrote:
> v2: 
> - fix compile issues if no CONFIG_SMP, Konrad Rzeszutek Wilk
> - move inc_irq_stat after irq_work_run

They look good to me (and they work nicely - thanks!)
so putting in the 3.5  queue.

> 
> These 2 patches fixed the "perf top" soft lockups under Xen
> reported by Steven at: https://lkml.org/lkml/2012/2/9/506
> 
> Both Steven and I tested it and "perf top" works well now.
> 
> The soft lockup code path is:
> 
> __irq_work_queue
>   arch_irq_work_raise
>     apic->send_IPI_self(IRQ_WORK_VECTOR);
>       apic_send_IPI_self
>         __default_send_IPI_shortcut
>           __xapic_wait_icr_idle
> 
> static inline void __xapic_wait_icr_idle(void)
> {
>         while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
>                 cpu_relax();
> }
> The lockup happens at above while looop.
> 
> The cause is that Xen has not implemented the APIC IPI interface yet.
> Xen has IPI interface: xen_send_IPI_one, but it's only used in
> xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
> xen_smp_send_call_function_single_ipi, etc.
> 
> So we need to implement Xen's APIC IPI interface as Ben's patch does.
> And implement Xen's IRQ_WORK_VECTOR handler.
> 
> Ben Guthro (1):
>       xen: implement apic ipi interface
> 
> Lin Ming (1):
>       xen: implement IRQ_WORK_VECTOR handler
> 
>  arch/x86/include/asm/xen/events.h |    1 +
>  arch/x86/xen/enlighten.c          |    9 +++
>  arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
>  arch/x86/xen/smp.h                |   12 ++++
>  4 files changed, 129 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:28:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGhI-0006JU-Fp; Fri, 20 Apr 2012 16:28:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SLGhH-0006JM-KK
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:28:35 +0000
Received: from [85.158.143.99:40241] by server-3.bemta-4.messagelabs.com id
	38/17-05853-2BE819F4; Fri, 20 Apr 2012 16:28:34 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334939312!26007949!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29403 invoked from network); 20 Apr 2012 16:28:33 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.208)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 16:28:33 -0000
Received: from mail21-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 16:28:32 +0000
Received: from mail21-am1 (localhost [127.0.0.1])	by mail21-am1-R.bigfish.com
	(Postfix) with ESMTP id 26C1D10010A;
	Fri, 20 Apr 2012 16:28:32 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail21-am1 (localhost.localdomain [127.0.0.1]) by mail21-am1
	(MessageSwitch) id 1334939309735865_18463;
	Fri, 20 Apr 2012 16:28:29 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.227])	by
	mail21-am1.bigfish.com (Postfix) with ESMTP id A63262E0043;
	Fri, 20 Apr 2012 16:28:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 16:28:25 +0000
X-WSS-ID: 0M2SDR7-02-18Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20AD2C8196;	Fri, 20 Apr 2012 11:28:18 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Apr 2012 11:28:40 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:28:21 -0500
Message-ID: <4F918CD2.7080307@amd.com>
Date: Fri, 20 Apr 2012 11:20:34 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Dan Magenheimer <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<CBB6D76E.31192%keir.xen@gmail.com>
	<699116fb-992a-4ce2-8071-9bb7d6e43645@default>
In-Reply-To: <699116fb-992a-4ce2-8071-9bb7d6e43645@default>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/20/2012 10:02 AM, Dan Magenheimer wrote:
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by
>> hardware
>>
>> On 20/04/2012 03:21, "Boris Ostrovsky"<boris.ostrovsky@amd.com>  wrote:
>>
>>> # HG changeset patch
>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>> # Date 1334875170 14400
>>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>>
>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>>
>>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>> Acked-by: Wei Huang<wei.huang2@amd.com>
>>> Tested-by: Wei Huang<wei.huang2@amd.com>
>> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
>> possible cross-CPU TSC skew.
> Provided the hypervisor writes the "TSC-scale-register" with the same
> value when any vcpu for any guest is scheduled, I don't think
> there is any cross-CPU TSC skew.
>
> But my recollection is that I had a concern that, to work properly
> after migration, TSC scaling might need to implement:
>
> 	((B + cur_tsc) * scale ) + A
Hi Dan,

Thanks for your review. I tried to interpret this formula as the following:

cur_tsc: Guest TSC before migration
B: time elapsed (overhead) during migration
scale: ratio of guest frequency/target host frequency
A: target host TSC

> and AFAIK the feature only implements this for B==0.
> Without the rest of the implementation in the hypervisor
> and tools, it's hard to determine whether my concern is valid
> or not.
If my interpretation above is correct, doesn't emulated TSC have the 
same problem of B == 0?
> Also, I don't recall the exact scaling process but
> was also concerned that a guest kernel or userland
> process approximating the passage of time by counting
> TSC cycles, they might just estimate the value once at
> boot (or application startup) and, due to the scaling,
> post-migration ticks/second might later change enough
> to be a problem.  However, this
> is a generic problem with emulation as well, so the
> concern is really: Does the TSC scaling use the same
> multiplication precision as is available to emulation
> in the hypervisor?
Hardware TSC scaling uses 8.32 format: 8 bits for integer part and 32 
bits for fraction. Is it enough for the precision from your experience? 
The details of TSC scaling spec can be found on page 554 of 
http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf.
> Dan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:28:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGhI-0006JU-Fp; Fri, 20 Apr 2012 16:28:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SLGhH-0006JM-KK
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:28:35 +0000
Received: from [85.158.143.99:40241] by server-3.bemta-4.messagelabs.com id
	38/17-05853-2BE819F4; Fri, 20 Apr 2012 16:28:34 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1334939312!26007949!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29403 invoked from network); 20 Apr 2012 16:28:33 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.208)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Apr 2012 16:28:33 -0000
Received: from mail21-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 16:28:32 +0000
Received: from mail21-am1 (localhost [127.0.0.1])	by mail21-am1-R.bigfish.com
	(Postfix) with ESMTP id 26C1D10010A;
	Fri, 20 Apr 2012 16:28:32 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail21-am1 (localhost.localdomain [127.0.0.1]) by mail21-am1
	(MessageSwitch) id 1334939309735865_18463;
	Fri, 20 Apr 2012 16:28:29 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.227])	by
	mail21-am1.bigfish.com (Postfix) with ESMTP id A63262E0043;
	Fri, 20 Apr 2012 16:28:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Apr 2012 16:28:25 +0000
X-WSS-ID: 0M2SDR7-02-18Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20AD2C8196;	Fri, 20 Apr 2012 11:28:18 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Apr 2012 11:28:40 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Apr 2012 11:28:21 -0500
Message-ID: <4F918CD2.7080307@amd.com>
Date: Fri, 20 Apr 2012 11:20:34 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Dan Magenheimer <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<CBB6D76E.31192%keir.xen@gmail.com>
	<699116fb-992a-4ce2-8071-9bb7d6e43645@default>
In-Reply-To: <699116fb-992a-4ce2-8071-9bb7d6e43645@default>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/20/2012 10:02 AM, Dan Magenheimer wrote:
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by
>> hardware
>>
>> On 20/04/2012 03:21, "Boris Ostrovsky"<boris.ostrovsky@amd.com>  wrote:
>>
>>> # HG changeset patch
>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>> # Date 1334875170 14400
>>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>>
>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>>
>>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>> Acked-by: Wei Huang<wei.huang2@amd.com>
>>> Tested-by: Wei Huang<wei.huang2@amd.com>
>> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
>> possible cross-CPU TSC skew.
> Provided the hypervisor writes the "TSC-scale-register" with the same
> value when any vcpu for any guest is scheduled, I don't think
> there is any cross-CPU TSC skew.
>
> But my recollection is that I had a concern that, to work properly
> after migration, TSC scaling might need to implement:
>
> 	((B + cur_tsc) * scale ) + A
Hi Dan,

Thanks for your review. I tried to interpret this formula as the following:

cur_tsc: Guest TSC before migration
B: time elapsed (overhead) during migration
scale: ratio of guest frequency/target host frequency
A: target host TSC

> and AFAIK the feature only implements this for B==0.
> Without the rest of the implementation in the hypervisor
> and tools, it's hard to determine whether my concern is valid
> or not.
If my interpretation above is correct, doesn't emulated TSC have the 
same problem of B == 0?
> Also, I don't recall the exact scaling process but
> was also concerned that a guest kernel or userland
> process approximating the passage of time by counting
> TSC cycles, they might just estimate the value once at
> boot (or application startup) and, due to the scaling,
> post-migration ticks/second might later change enough
> to be a problem.  However, this
> is a generic problem with emulation as well, so the
> concern is really: Does the TSC scaling use the same
> multiplication precision as is available to emulation
> in the hypervisor?
Hardware TSC scaling uses 8.32 format: 8 bits for integer part and 32 
bits for fraction. Is it enough for the precision from your experience? 
The details of TSC scaling spec can be found on page 554 of 
http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf.
> Dan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:33:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGlr-0006W5-6h; Fri, 20 Apr 2012 16:33:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGlp-0006Vw-Nx
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:33:18 +0000
Received: from [85.158.138.51:23460] by server-12.bemta-3.messagelabs.com id
	7D/AA-29760-CCF819F4; Fri, 20 Apr 2012 16:33:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334939594!12072771!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24488 invoked from network); 20 Apr 2012 16:33:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 16:33:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGX8AW018502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:33:09 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGX7vj018441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:33:07 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGX3MN019605; Fri, 20 Apr 2012 11:33:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:33:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CFE744031D; Fri, 20 Apr 2012 12:28:03 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:28:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120420162803.GA31062@phenom.dumpdata.com>
References: <4F7C63EE.6000703@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7C63EE.6000703@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090203.4F918FC6.001C,ss=1,re=0.000,fgs=0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 04, 2012 at 05:08:30PM +0200, Stefan Bader wrote:
> Hi Stefano,
> 
> quite a while back in time, you and Konrad had a discussion about some HVM setup
> problems via libvirt. One part was graphics and the problem seemed to be that
> when creating a new instance through xend for HVM, the use of vfb was wrong. It
> mostly does work but then also defines a vkbd which takes a long time in the
> xenbus setup to finally fail.

So, this patch http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=3066616ce23aad5719c23a0f21f32676402cb44b
fixes it in the kernel (and I remembered this time to stick stable@kernel.org on it).

It should eleviate some of the pains by making the timeout only 30 seconds when
vkbd is used, instead of the lengthy 6 minutes.

> 
> Because this was not a really fatal problem it did take a long time to actually
> get back to it. But now I had a look and found that libvirt indeed does use the
> vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> create guests). The decision is made based on the xend version number in the HVM
> case. Which would be wrong if I did understand your reply correctly.
> 
> I have been testing a patch to libvirt, which would not use a vfb definition
> whenever HVM is used (regardless of xend version). And it does seem to work (xm
> list -l however has a vfb device definition, but the same happens when creating
> the instance with a xm style config file that definitely has no vfb section in
> it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> to make sure the solution for libvirt is correct for even the current Xen version.
> 
> So in short, is this always correct?
> 
> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>    do not define a vfb device
> else /* PVM and xend version >= 3 */
>    define a vfb device
> 
> Thanks,
> Stefan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:33:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGlr-0006W5-6h; Fri, 20 Apr 2012 16:33:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGlp-0006Vw-Nx
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:33:18 +0000
Received: from [85.158.138.51:23460] by server-12.bemta-3.messagelabs.com id
	7D/AA-29760-CCF819F4; Fri, 20 Apr 2012 16:33:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334939594!12072771!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24488 invoked from network); 20 Apr 2012 16:33:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 16:33:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGX8AW018502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:33:09 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGX7vj018441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:33:07 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGX3MN019605; Fri, 20 Apr 2012 11:33:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:33:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CFE744031D; Fri, 20 Apr 2012 12:28:03 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:28:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120420162803.GA31062@phenom.dumpdata.com>
References: <4F7C63EE.6000703@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F7C63EE.6000703@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090203.4F918FC6.001C,ss=1,re=0.000,fgs=0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Correct format for HVM graphics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 04, 2012 at 05:08:30PM +0200, Stefan Bader wrote:
> Hi Stefano,
> 
> quite a while back in time, you and Konrad had a discussion about some HVM setup
> problems via libvirt. One part was graphics and the problem seemed to be that
> when creating a new instance through xend for HVM, the use of vfb was wrong. It
> mostly does work but then also defines a vkbd which takes a long time in the
> xenbus setup to finally fail.

So, this patch http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=3066616ce23aad5719c23a0f21f32676402cb44b
fixes it in the kernel (and I remembered this time to stick stable@kernel.org on it).

It should eleviate some of the pains by making the timeout only 30 seconds when
vkbd is used, instead of the lengthy 6 minutes.

> 
> Because this was not a really fatal problem it did take a long time to actually
> get back to it. But now I had a look and found that libvirt indeed does use the
> vfb form for both the xen-xm and xen-sxpr formats (the latter being used to
> create guests). The decision is made based on the xend version number in the HVM
> case. Which would be wrong if I did understand your reply correctly.
> 
> I have been testing a patch to libvirt, which would not use a vfb definition
> whenever HVM is used (regardless of xend version). And it does seem to work (xm
> list -l however has a vfb device definition, but the same happens when creating
> the instance with a xm style config file that definitely has no vfb section in
> it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want
> to make sure the solution for libvirt is correct for even the current Xen version.
> 
> So in short, is this always correct?
> 
> if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3))
>    do not define a vfb device
> else /* PVM and xend version >= 3 */
>    define a vfb device
> 
> Thanks,
> Stefan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGn6-0006aO-NK; Fri, 20 Apr 2012 16:34:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SLGn4-0006aI-BR
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:34:34 +0000
Received: from [193.109.254.147:60968] by server-4.bemta-14.messagelabs.com id
	70/82-11570-910919F4; Fri, 20 Apr 2012 16:34:33 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334939669!5563661!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12748 invoked from network); 20 Apr 2012 16:34:31 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:34:31 -0000
Received: by pbcuo5 with SMTP id uo5so1289420pbc.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=QHJLdL9wz4hU/+tnZmG1dfnTdT4XgedTJg9d4N5kOGE=;
	b=imWCQwR2fHtMtR9nTz2TZrQV9xMdTklv9rxhq16hMV9oXPYhYWRqfj6pnL87BlPqD5
	rg3MEnTCadqzfdpZITZ71Ds9Jl0N2DJEn2BewC3m00p76u1R47skVwp0nrncCa7yG0Ds
	unM+ZfjnBJZujraTnRzyG/h+XWeB4X0RGu1nCCXrFThgUthBCoJ+DJ1uJjj2Mqu0ykQU
	b+ch0FqZhDcQM/f6uAXeJo+GnDGsVye0ecaQ+bMU+J+CHThReF/zeTIgEPveKD5FkqWn
	b798Iu1oDUaIxmw81XWNp0YHkkwZ9tHlcb/ACilXPfVGjPg897e97qjN920CDfb1LzJm
	CHJw==
MIME-Version: 1.0
Received: by 10.68.136.161 with SMTP id qb1mr7137235pbb.104.1334939668810;
	Fri, 20 Apr 2012 09:34:28 -0700 (PDT)
Received: by 10.68.134.228 with HTTP; Fri, 20 Apr 2012 09:34:28 -0700 (PDT)
In-Reply-To: <1334936286.28331.113.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1334928115.28331.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
	<1334936286.28331.113.camel@zakaz.uk.xensource.com>
Date: Sat, 21 Apr 2012 00:34:28 +0800
Message-ID: <CAEwRVpOrhp6u6xRwJpP0gT5XrGWRZWe=zWiyWjrjKRB51Mp6Rg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 11:38 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Fri, 2012-04-20 at 16:26 +0100, Teck Choon Giam wrote:
>> On Fri, Apr 20, 2012 at 9:21 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
>> >> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interferi=
ng with openvpn"):
>> >> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
>> >> > > I'm not quite up to speed with all the context here but is the re=
ason
>> >> > > that you're not suggesting "xen-" is that that's already used for
>> >> > > something else ?
>> >> >
>> >> > This is to distinguish the vif device from the associated tap devic=
e,
>> >> > which would otherwise both be called whatever the user gave as "vif=
name"
>> >> > in their config, so for vifname=3Dfoo you would get foo (the PV one=
) and
>> >> > xen-foo (the EMU one) which does the job but doesn't really disting=
uish
>> >> > them.
>> >>
>> >> Ah, I see. =A0This sounds like more a job for a suffix than a prefix =
so
>> >> if we can spare 4 chars I would suggest foo-emu.
>>
>> So what is the final prefix/suffix here? =A0Is it "emu-"? =A0Sorry, need
>> to counter check :p
>
> I think we have agreed on a "-emu" suffix.

Thanks and I will update my backport to reflect this "-emu" instead of
"xentap-" as well then test ;)

>
>> Question... vifname is limited to 16 characters? =A0If so, does the
>> configuration for xm/xl check for its allowable length? =A0I mean if a
>> user set vifname more than its allowable length in the domU
>> configuration, would xm/xl show error?
>
> I can't see any existing check for the length of the vif name.
>
> It's a bit hard for us to do, consider a network driver domain running a
> kernel which has a different, or no, limit here. libxl might not have
> any idea what that name limit should be. We could pick an arbitrary
> limit which is the smallest we know of, e.g. 12 chars (to allow +4), I
> suppose.
>
> BTW, the failure if your name is too long will be that the vif hotplug
> script will fail to rename the device.

Ok, noted.

>
> This limit has long existed and I don't recall ever having seen a report
> about it, maybe the failure case is so obvious that people just fix it
> and move on. I also expect that setting such a long name is rare...

Yes, rare I agree but you know some _rare_ users... ... As long as the
error is obvious then I think this shouldn't be an issue.

Thanks for taking time to reply.

Kindest regards,
Giam Teck Choon


>
>>
>> Sorry for asking as it isn't clear in manual... ...
>> http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>> vifname
>>
>> This keyword is valid for HVM guest devices with type=3Dioemu only.
>>
>> Specifies the backend device name for an emulated device. The default
>> is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is the
>> device number.
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> >
>> > I agree.
>> >
>> > This patch interacts a bit with Roger's hotplug series, I'll rebase on
>> > top of his with this change when he reposts it.
>>
>> Looking forward for your reports ;)
>>
>> >
>> > Ian.
>> >
>>
>> Thanks.
>>
>> Kindest regards,
>> Giam Teck Choon
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGn6-0006aO-NK; Fri, 20 Apr 2012 16:34:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SLGn4-0006aI-BR
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 16:34:34 +0000
Received: from [193.109.254.147:60968] by server-4.bemta-14.messagelabs.com id
	70/82-11570-910919F4; Fri, 20 Apr 2012 16:34:33 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1334939669!5563661!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12748 invoked from network); 20 Apr 2012 16:34:31 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:34:31 -0000
Received: by pbcuo5 with SMTP id uo5so1289420pbc.32
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 09:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=QHJLdL9wz4hU/+tnZmG1dfnTdT4XgedTJg9d4N5kOGE=;
	b=imWCQwR2fHtMtR9nTz2TZrQV9xMdTklv9rxhq16hMV9oXPYhYWRqfj6pnL87BlPqD5
	rg3MEnTCadqzfdpZITZ71Ds9Jl0N2DJEn2BewC3m00p76u1R47skVwp0nrncCa7yG0Ds
	unM+ZfjnBJZujraTnRzyG/h+XWeB4X0RGu1nCCXrFThgUthBCoJ+DJ1uJjj2Mqu0ykQU
	b+ch0FqZhDcQM/f6uAXeJo+GnDGsVye0ecaQ+bMU+J+CHThReF/zeTIgEPveKD5FkqWn
	b798Iu1oDUaIxmw81XWNp0YHkkwZ9tHlcb/ACilXPfVGjPg897e97qjN920CDfb1LzJm
	CHJw==
MIME-Version: 1.0
Received: by 10.68.136.161 with SMTP id qb1mr7137235pbb.104.1334939668810;
	Fri, 20 Apr 2012 09:34:28 -0700 (PDT)
Received: by 10.68.134.228 with HTTP; Fri, 20 Apr 2012 09:34:28 -0700 (PDT)
In-Reply-To: <1334936286.28331.113.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1334928115.28331.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpO8Y==NkZGtx8O7FWTJYxMNwZcGQA-5ETTVz6erpnSzzA@mail.gmail.com>
	<1334936286.28331.113.camel@zakaz.uk.xensource.com>
Date: Sat, 21 Apr 2012 00:34:28 +0800
Message-ID: <CAEwRVpOrhp6u6xRwJpP0gT5XrGWRZWe=zWiyWjrjKRB51Mp6Rg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 11:38 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Fri, 2012-04-20 at 16:26 +0100, Teck Choon Giam wrote:
>> On Fri, Apr 20, 2012 at 9:21 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
>> >> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interferi=
ng with openvpn"):
>> >> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
>> >> > > I'm not quite up to speed with all the context here but is the re=
ason
>> >> > > that you're not suggesting "xen-" is that that's already used for
>> >> > > something else ?
>> >> >
>> >> > This is to distinguish the vif device from the associated tap devic=
e,
>> >> > which would otherwise both be called whatever the user gave as "vif=
name"
>> >> > in their config, so for vifname=3Dfoo you would get foo (the PV one=
) and
>> >> > xen-foo (the EMU one) which does the job but doesn't really disting=
uish
>> >> > them.
>> >>
>> >> Ah, I see. =A0This sounds like more a job for a suffix than a prefix =
so
>> >> if we can spare 4 chars I would suggest foo-emu.
>>
>> So what is the final prefix/suffix here? =A0Is it "emu-"? =A0Sorry, need
>> to counter check :p
>
> I think we have agreed on a "-emu" suffix.

Thanks and I will update my backport to reflect this "-emu" instead of
"xentap-" as well then test ;)

>
>> Question... vifname is limited to 16 characters? =A0If so, does the
>> configuration for xm/xl check for its allowable length? =A0I mean if a
>> user set vifname more than its allowable length in the domU
>> configuration, would xm/xl show error?
>
> I can't see any existing check for the length of the vif name.
>
> It's a bit hard for us to do, consider a network driver domain running a
> kernel which has a different, or no, limit here. libxl might not have
> any idea what that name limit should be. We could pick an arbitrary
> limit which is the smallest we know of, e.g. 12 chars (to allow +4), I
> suppose.
>
> BTW, the failure if your name is too long will be that the vif hotplug
> script will fail to rename the device.

Ok, noted.

>
> This limit has long existed and I don't recall ever having seen a report
> about it, maybe the failure case is so obvious that people just fix it
> and move on. I also expect that setting such a long name is rare...

Yes, rare I agree but you know some _rare_ users... ... As long as the
error is obvious then I think this shouldn't be an issue.

Thanks for taking time to reply.

Kindest regards,
Giam Teck Choon


>
>>
>> Sorry for asking as it isn't clear in manual... ...
>> http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>> vifname
>>
>> This keyword is valid for HVM guest devices with type=3Dioemu only.
>>
>> Specifies the backend device name for an emulated device. The default
>> is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is the
>> device number.
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> >
>> > I agree.
>> >
>> > This patch interacts a bit with Roger's hotplug series, I'll rebase on
>> > top of his with this change when he reposts it.
>>
>> Looking forward for your reports ;)
>>
>> >
>> > Ian.
>> >
>>
>> Thanks.
>>
>> Kindest regards,
>> Giam Teck Choon
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:47:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGz6-000722-2v; Fri, 20 Apr 2012 16:47:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGz4-00071x-DZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:46:58 +0000
Received: from [85.158.143.99:59306] by server-3.bemta-4.messagelabs.com id
	4A/47-05853-103919F4; Fri, 20 Apr 2012 16:46:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334940415!18195448!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDkyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9375 invoked from network); 20 Apr 2012 16:46:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 16:46:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGkpWa011276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:46:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGkoMu003324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:46:51 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGkoQX016342; Fri, 20 Apr 2012 11:46:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:46:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C7134031D; Fri, 20 Apr 2012 12:41:51 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:41:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120420164150.GC31062@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F9192FD.000E,ss=1,re=0.000,fgs=0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 01:38:28PM +0100, Ian Campbell wrote:
> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
> > On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
> > > On 20/04/12 10:25, Lin Ming wrote:
> > > > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> > > > information instead of fabricated one.
> > > >
> > > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> > > > ---
> > > >  arch/x86/xen/apic.c |   16 +++++++++++-----
> > > >  1 files changed, 11 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> > > > index aee16ab..f1f392d 100644
> > > > --- a/arch/x86/xen/apic.c
> > > > +++ b/arch/x86/xen/apic.c
> > > > @@ -1,14 +1,20 @@
> > > >  #include <linux/init.h>
> > > >  #include <asm/x86_init.h>
> > > > +#include <asm/apic.h>
> > > > +#include <xen/interface/physdev.h>
> > > > +#include <asm/xen/hypercall.h>
> > > >  
> > > >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> > > >  {
> > > > -	if (reg == 0x1)
> > > > -		return 0x00170020;
> > > > -	else if (reg == 0x0)
> > > > -		return apic << 24;
> > > > +	struct physdev_apic apic_op;
> > > > +	int ret;
> > > >  
> > > > -	return 0xff;
> > > > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> > > > +	apic_op.reg = reg;
> > > > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> > > > +	if (ret)
> > > > +		return ret;
> > > > +	return apic_op.value;
> > > 
> > > Hypercall ret errors are negative, yet this function is unsigned.  Given
> > > that the previous function had no possible way to fail, perhaps on error
> > > you should fake up the values as before.
> > 
> > How about return -1 on error?
> > The calling function can check -1 for error. 
> 
> Isn't -1 potentially (at least theoretically) a valid value to read from
> one of these registers?

Yeah, but then we are back to crashing at bootup (with dom0) :-)

Perhaps the fallback is to emulate (so retain some of the original code)
as we have been since .. uh 3.0?

> 
> Under what circumstances can these hypercalls fail? Would a BUG_ON be
> appropriate/
> 
> > unsigned int ret = apic_read(...);
> > if (ret == -1)
> > 	//handle error.
> > 
> > Thanks,
> > Lin Ming
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:47:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLGz6-000722-2v; Fri, 20 Apr 2012 16:47:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLGz4-00071x-DZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:46:58 +0000
Received: from [85.158.143.99:59306] by server-3.bemta-4.messagelabs.com id
	4A/47-05853-103919F4; Fri, 20 Apr 2012 16:46:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334940415!18195448!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDkyNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9375 invoked from network); 20 Apr 2012 16:46:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 16:46:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGkpWa011276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:46:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGkoMu003324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:46:51 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGkoQX016342; Fri, 20 Apr 2012 11:46:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:46:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C7134031D; Fri, 20 Apr 2012 12:41:51 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:41:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120420164150.GC31062@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334925508.28331.63.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F9192FD.000E,ss=1,re=0.000,fgs=0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Lin Ming <mlin@ss.pku.edu.cn>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 01:38:28PM +0100, Ian Campbell wrote:
> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
> > On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
> > > On 20/04/12 10:25, Lin Ming wrote:
> > > > Implements xen_io_apic_read with hypercall, so it returns proper IO-APIC
> > > > information instead of fabricated one.
> > > >
> > > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
> > > > ---
> > > >  arch/x86/xen/apic.c |   16 +++++++++++-----
> > > >  1 files changed, 11 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> > > > index aee16ab..f1f392d 100644
> > > > --- a/arch/x86/xen/apic.c
> > > > +++ b/arch/x86/xen/apic.c
> > > > @@ -1,14 +1,20 @@
> > > >  #include <linux/init.h>
> > > >  #include <asm/x86_init.h>
> > > > +#include <asm/apic.h>
> > > > +#include <xen/interface/physdev.h>
> > > > +#include <asm/xen/hypercall.h>
> > > >  
> > > >  unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> > > >  {
> > > > -	if (reg == 0x1)
> > > > -		return 0x00170020;
> > > > -	else if (reg == 0x0)
> > > > -		return apic << 24;
> > > > +	struct physdev_apic apic_op;
> > > > +	int ret;
> > > >  
> > > > -	return 0xff;
> > > > +	apic_op.apic_physbase = mpc_ioapic_addr(apic);
> > > > +	apic_op.reg = reg;
> > > > +	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
> > > > +	if (ret)
> > > > +		return ret;
> > > > +	return apic_op.value;
> > > 
> > > Hypercall ret errors are negative, yet this function is unsigned.  Given
> > > that the previous function had no possible way to fail, perhaps on error
> > > you should fake up the values as before.
> > 
> > How about return -1 on error?
> > The calling function can check -1 for error. 
> 
> Isn't -1 potentially (at least theoretically) a valid value to read from
> one of these registers?

Yeah, but then we are back to crashing at bootup (with dom0) :-)

Perhaps the fallback is to emulate (so retain some of the original code)
as we have been since .. uh 3.0?

> 
> Under what circumstances can these hypercalls fail? Would a BUG_ON be
> appropriate/
> 
> > unsigned int ret = apic_read(...);
> > if (ret == -1)
> > 	//handle error.
> > 
> > Thanks,
> > Lin Ming
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:48:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:48:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLH0b-00077l-Ow; Fri, 20 Apr 2012 16:48:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLH0Z-00077Z-PY
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:48:31 +0000
Received: from [193.109.254.147:57753] by server-3.bemta-14.messagelabs.com id
	77/E8-23274-F53919F4; Fri, 20 Apr 2012 16:48:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334940508!5577950!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9673 invoked from network); 20 Apr 2012 16:48:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 16:48:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGmPNh000481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:48:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGmOmH012979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:48:25 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGmOje000401; Fri, 20 Apr 2012 11:48:24 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:48:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 879544031D; Fri, 20 Apr 2012 12:43:25 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:43:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120420164325.GD31062@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
	<1334934367.28331.99.camel@zakaz.uk.xensource.com>
	<1334936364.2863.24.camel@hp6530s>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334936364.2863.24.camel@hp6530s>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F91935B.000B,ss=1,re=0.000,fgs=0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 11:39:24PM +0800, Lin Ming wrote:
> On Fri, 2012-04-20 at 16:06 +0100, Ian Campbell wrote:
> > On Fri, 2012-04-20 at 15:50 +0100, Lin Ming wrote:
> > > On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> > > >> >
> > > >> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> > > >> > appropriate/
> > > >>
> > > >> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> > > >> be -EPERM).
> > > >
> > > > So either the guest has called a hypercall which it is not permitted to
> > > > or it has called it with invalid parameters of one sort or another. Both
> > > > of these would be a code bug in the guest and therefore asserting that
> > > > no failure occurred is reasonable?
> > > >
> > > > What could the caller do with the error other than log it and collapse?
> > > >
> > > >> The call into Xen itself will return 0 as a value if an
> > > >> invalid physbase is passed in the hypercall.
> 
> Just checked ioapic_guest_read.
> It will return -EINVAL if an invalid physbase is passed in.
> 
> > > >
> > > >> So a BUG_ON() is not safe/sensible for domU.
> > > >
> > > > I think you have successfully argued that it is ;-)
> > > 
> > > BUG_ON is too severe.
> > 
> > Why? Under what circumstances can this be correctly called in a way
> > which would result in the hypercall failing?
> 
> Is BUG_ON() reasonable if invalid physbase passed in?

Just emulate the values in the error case. We don't _need_ them per say - except
to emulate some sensible values.

> 
> > 
> > >  How about WARN_ON?
> > > 
> > > ret = hypercall(...)
> > > 
> > > if (ret) {
> > >    WARN_ON(1);
> > >    return -1;
> > > }
> > > 
> > > 
> > > >
> > > > Ian.
> > 
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:48:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:48:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLH0b-00077l-Ow; Fri, 20 Apr 2012 16:48:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLH0Z-00077Z-PY
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:48:31 +0000
Received: from [193.109.254.147:57753] by server-3.bemta-14.messagelabs.com id
	77/E8-23274-F53919F4; Fri, 20 Apr 2012 16:48:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1334940508!5577950!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9673 invoked from network); 20 Apr 2012 16:48:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 16:48:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KGmPNh000481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 16:48:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KGmOmH012979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 16:48:25 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KGmOje000401; Fri, 20 Apr 2012 11:48:24 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 09:48:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 879544031D; Fri, 20 Apr 2012 12:43:25 -0400 (EDT)
Date: Fri, 20 Apr 2012 12:43:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120420164325.GD31062@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<4F915C43.4020207@citrix.com>
	<1334927566.28331.80.camel@zakaz.uk.xensource.com>
	<CAF1ivSaPshQf=BZ1gKLUq1yRF_MWeyjjVWkfv+E_jT+K5CFmAA@mail.gmail.com>
	<1334934367.28331.99.camel@zakaz.uk.xensource.com>
	<1334936364.2863.24.camel@hp6530s>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334936364.2863.24.camel@hp6530s>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F91935B.000B,ss=1,re=0.000,fgs=0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 11:39:24PM +0800, Lin Ming wrote:
> On Fri, 2012-04-20 at 16:06 +0100, Ian Campbell wrote:
> > On Fri, 2012-04-20 at 15:50 +0100, Lin Ming wrote:
> > > On Fri, Apr 20, 2012 at 9:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > On Fri, 2012-04-20 at 13:53 +0100, Andrew Cooper wrote:
> > > >> >
> > > >> > Under what circumstances can these hypercalls fail? Would a BUG_ON be
> > > >> > appropriate/
> > > >>
> > > >> -EFAULT, -EPERM, anything xsm_apic() could return (which looks only to
> > > >> be -EPERM).
> > > >
> > > > So either the guest has called a hypercall which it is not permitted to
> > > > or it has called it with invalid parameters of one sort or another. Both
> > > > of these would be a code bug in the guest and therefore asserting that
> > > > no failure occurred is reasonable?
> > > >
> > > > What could the caller do with the error other than log it and collapse?
> > > >
> > > >> The call into Xen itself will return 0 as a value if an
> > > >> invalid physbase is passed in the hypercall.
> 
> Just checked ioapic_guest_read.
> It will return -EINVAL if an invalid physbase is passed in.
> 
> > > >
> > > >> So a BUG_ON() is not safe/sensible for domU.
> > > >
> > > > I think you have successfully argued that it is ;-)
> > > 
> > > BUG_ON is too severe.
> > 
> > Why? Under what circumstances can this be correctly called in a way
> > which would result in the hypercall failing?
> 
> Is BUG_ON() reasonable if invalid physbase passed in?

Just emulate the values in the error case. We don't _need_ them per say - except
to emulate some sensible values.

> 
> > 
> > >  How about WARN_ON?
> > > 
> > > ret = hypercall(...)
> > > 
> > > if (ret) {
> > >    WARN_ON(1);
> > >    return -1;
> > > }
> > > 
> > > 
> > > >
> > > > Ian.
> > 
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:56:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLH89-0007MK-NQ; Fri, 20 Apr 2012 16:56:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SLH88-0007MF-22
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:56:20 +0000
Received: from [85.158.139.83:39711] by server-10.bemta-5.messagelabs.com id
	98/35-08260-335919F4; Fri, 20 Apr 2012 16:56:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334940977!24099117!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27702 invoked from network); 20 Apr 2012 16:56:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:56:18 -0000
Received: by werf13 with SMTP id f13so6571442wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 09:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XailDJ9cNOH08/twi5gZDhwWYZaZUC5z6lMo94j2tK4=;
	b=uoBzBEqH/BEc0QYKtrvJowtoBTt3hBJRHa2V6ZAm2c8RPAO0h1djk/OpjocTlvOlcv
	OeVsuCCjRJq228u0x/BwMKENMz22nO/i502KNeVD485YhbxXL7JTcI9eJoqGyiujpXpT
	pO0wzNyQ8ADVYtfSZjytYkKr2Srs3X61Z8hJjylkcCcZGsH/FUwQm9hn8Qxt/hMsGdLf
	ikyTitL7wc/8oysYeiQAu5T2We3p740R8sOFTYt4Efuyip2+V05urUCdG3UP7I7wmuX8
	bJS/S76X2T2rO994vRu8PIjRtgf4IJaBYPZ5Gi7CMuI9tax9YvmPN0vzWy3o8CYpdCJ6
	nYLw==
Received: by 10.180.104.230 with SMTP id gh6mr2697029wib.22.1334940977360;
	Fri, 20 Apr 2012 09:56:17 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id w10sm10595174wiy.3.2012.04.20.09.56.12
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:56:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 17:56:09 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Huang2, Wei" <Wei.Huang2@amd.com>,
	"Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBB753B9.3125C%keir.xen@gmail.com>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: AQHNHpxPkEb3eUjtQUKe3vtM5npR3pajr2UAgAACbgCAAB6WgIAAH1Wp
In-Reply-To: <4400B41FB768044EA720935D0808176C090DFB9E@sausexdag02.amd.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ah, okay. Well, depending on review feedback on list perhaps it can slip
into the schedule then. :-)


On 20/04/2012 16:06, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:

> Hi Keir,
> 
> This patch is a bug fix for 23437:d7c755c25bb9 than new feature. It slipped my
> hand and Boris fixed it for me. The same applies to Xen-4.1.
> 
> ===== Changeset 23437 =====
> 
> HVM/SVM: enable tsc scaling ratio for SVM
> 
> Future AMD CPUs support TSC scaling. It allows guests to have a
> different TSC frequency from host system using this formula: guest_tsc
> = host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR
> contains a fixed-point number in 8.32 format (8 bits for integer part
> and 32bits for fractional part). For instance 0x00000003_80000000
> means tsc_ratio=3.5.
> 
> This patch enables TSC scaling ratio for SVM. With it, guest VMs don't
> need take #VMEXIT to calculate a translated TSC value when it is
> running under TSC emulation mode. This can substancially reduce the
> rdtsc overhead.
> 
> 
> -Wei
> 
> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Friday, April 20, 2012 3:15 AM
> To: Ostrovsky, Boris; JBeulich@suse.com; Dan Magenheimer
> Cc: Huang2, Wei; xen-devel@lists.xensource.com
> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
> supported by hardware
> 
> On 20/04/2012 09:05, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
>> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
>> 
>>> # HG changeset patch
>>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>>> # Date 1334875170 14400
>>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>> 
>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>> 
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>>> Acked-by: Wei Huang <wei.huang2@amd.com>
>>> Tested-by: Wei Huang <wei.huang2@amd.com>
>> 
>> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
>> possible cross-CPU TSC skew.
> 
> Oh, and apart from that, we're also in feature freeze for 4.2, and this
> isn't a bug fix. Similarly, it's not really a candidate for the stable 4.1
> branch either, at any time.
> 
>  -- Keir
> 
>>  -- Keir
>> 
>>> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
>>> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
>>> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
>>> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>>>  {
>>>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>>> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>>>  
>>>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
>>> -    if ( enable )
>>> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
>>> +
>>> +    if ( enable && !cpu_has_tsc_ratio ) {
>>>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
>>> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
>>> +    }
>>>  
>>>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
>>> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>>>  }
>>>  
>>>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
>>> 
>> 
>> 
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 16:56:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 16:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLH89-0007MK-NQ; Fri, 20 Apr 2012 16:56:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SLH88-0007MF-22
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 16:56:20 +0000
Received: from [85.158.139.83:39711] by server-10.bemta-5.messagelabs.com id
	98/35-08260-335919F4; Fri, 20 Apr 2012 16:56:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1334940977!24099117!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27702 invoked from network); 20 Apr 2012 16:56:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 16:56:18 -0000
Received: by werf13 with SMTP id f13so6571442wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 09:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XailDJ9cNOH08/twi5gZDhwWYZaZUC5z6lMo94j2tK4=;
	b=uoBzBEqH/BEc0QYKtrvJowtoBTt3hBJRHa2V6ZAm2c8RPAO0h1djk/OpjocTlvOlcv
	OeVsuCCjRJq228u0x/BwMKENMz22nO/i502KNeVD485YhbxXL7JTcI9eJoqGyiujpXpT
	pO0wzNyQ8ADVYtfSZjytYkKr2Srs3X61Z8hJjylkcCcZGsH/FUwQm9hn8Qxt/hMsGdLf
	ikyTitL7wc/8oysYeiQAu5T2We3p740R8sOFTYt4Efuyip2+V05urUCdG3UP7I7wmuX8
	bJS/S76X2T2rO994vRu8PIjRtgf4IJaBYPZ5Gi7CMuI9tax9YvmPN0vzWy3o8CYpdCJ6
	nYLw==
Received: by 10.180.104.230 with SMTP id gh6mr2697029wib.22.1334940977360;
	Fri, 20 Apr 2012 09:56:17 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id w10sm10595174wiy.3.2012.04.20.09.56.12
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 09:56:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Apr 2012 17:56:09 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Huang2, Wei" <Wei.Huang2@amd.com>,
	"Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBB753B9.3125C%keir.xen@gmail.com>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: AQHNHpxPkEb3eUjtQUKe3vtM5npR3pajr2UAgAACbgCAAB6WgIAAH1Wp
In-Reply-To: <4400B41FB768044EA720935D0808176C090DFB9E@sausexdag02.amd.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ah, okay. Well, depending on review feedback on list perhaps it can slip
into the schedule then. :-)


On 20/04/2012 16:06, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:

> Hi Keir,
> 
> This patch is a bug fix for 23437:d7c755c25bb9 than new feature. It slipped my
> hand and Boris fixed it for me. The same applies to Xen-4.1.
> 
> ===== Changeset 23437 =====
> 
> HVM/SVM: enable tsc scaling ratio for SVM
> 
> Future AMD CPUs support TSC scaling. It allows guests to have a
> different TSC frequency from host system using this formula: guest_tsc
> = host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR
> contains a fixed-point number in 8.32 format (8 bits for integer part
> and 32bits for fractional part). For instance 0x00000003_80000000
> means tsc_ratio=3.5.
> 
> This patch enables TSC scaling ratio for SVM. With it, guest VMs don't
> need take #VMEXIT to calculate a translated TSC value when it is
> running under TSC emulation mode. This can substancially reduce the
> rdtsc overhead.
> 
> 
> -Wei
> 
> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Friday, April 20, 2012 3:15 AM
> To: Ostrovsky, Boris; JBeulich@suse.com; Dan Magenheimer
> Cc: Huang2, Wei; xen-devel@lists.xensource.com
> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
> supported by hardware
> 
> On 20/04/2012 09:05, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
>> On 20/04/2012 03:21, "Boris Ostrovsky" <boris.ostrovsky@amd.com> wrote:
>> 
>>> # HG changeset patch
>>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>>> # Date 1334875170 14400
>>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>> 
>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>> 
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>>> Acked-by: Wei Huang <wei.huang2@amd.com>
>>> Tested-by: Wei Huang <wei.huang2@amd.com>
>> 
>> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
>> possible cross-CPU TSC skew.
> 
> Oh, and apart from that, we're also in feature freeze for 4.2, and this
> isn't a bug fix. Similarly, it's not really a candidate for the stable 4.1
> branch either, at any time.
> 
>  -- Keir
> 
>>  -- Keir
>> 
>>> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
>>> --- a/xen/arch/x86/hvm/svm/svm.c Wed Apr 18 16:49:55 2012 +0100
>>> +++ b/xen/arch/x86/hvm/svm/svm.c Thu Apr 19 18:39:30 2012 -0400
>>> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>>>  {
>>>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>>> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>>>  
>>>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
>>> -    if ( enable )
>>> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
>>> +
>>> +    if ( enable && !cpu_has_tsc_ratio ) {
>>>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
>>> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
>>> +    }
>>>  
>>>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
>>> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>>>  }
>>>  
>>>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
>>> 
>> 
>> 
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 17:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 17:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLHRe-0008DH-5P; Fri, 20 Apr 2012 17:16:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SLHRd-0008Cn-BO
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 17:16:29 +0000
Received: from [193.109.254.147:63154] by server-4.bemta-14.messagelabs.com id
	CF/D6-11570-BE9919F4; Fri, 20 Apr 2012 17:16:27 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334942186!5579012!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28691 invoked from network); 20 Apr 2012 17:16:27 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 17:16:27 -0000
Received: by eeit10 with SMTP id t10so2719079eei.32
	for <multiple recipients>; Fri, 20 Apr 2012 10:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=YoOTErKoULE6DyteZ528o3Ip/skRLLdixA0OBftrtms=;
	b=dssaMbANR+e1HjmFv5UIxt2zuWHVgD9csC3Bhin6B//mwgkFjEUTarszRtH/I/RMdK
	dXceNqKh41qRcDIk1/Tmdqosh2d+MJYb4SWm7ZgiH7KzgZnyChcYRV7ulR/4VSNmiG6X
	ia30Fe58v+pGwiTZDHcgj3l6zfCX4EHscOisLPS3AGe2vWiABqeuwY9oEGmoLfrct8et
	sKLLBY5T8SaZ73pWGEbHHvw8AtArT+XFb0d0tdmYuT5ujVXbCicF7rAK08V67KVRHN3U
	ybOzgbYzdOdbjWgUUJwH2y8CNCyJPHQOPn4IhIA1a09mt27HYMJiTo5hJ2ORcwh3wr5G
	1aZg==
Received: by 10.14.96.203 with SMTP id r51mr1233813eef.24.1334942186515;
	Fri, 20 Apr 2012 10:16:26 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id e56sm29068809eea.11.2012.04.20.10.16.24
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:16:25 -0700 (PDT)
Message-ID: <4F9199E5.5080409@xen.org>
Date: Fri, 20 Apr 2012 18:16:21 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, 
 xen-api@lists.xen.org
Subject: [Xen-devel] IMPORTANT: Changes to XenSummit Format : Please vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

I have been talking to a number of the key contributors to the project 
regarding XenSummit and got feedback on the format of XenSummit. Please 
read, if you are active in the community and DO VOTE!

Cheers
Lars

Change of date in CFP!
======================
First I wanted to annouce that we are extending the CFP from May 1st to 
15th of June. Key community members felt that May 1 is too early. In 
particular because we have closed the CFP 5-6 weeks before the event in 
the past. Due to contractual issues June 15th is the last day we can do 
though.

Proposal! PLEASE READ!
======================
A number of vendors felt we should change the format of XenSummit to be 
more like the Linux Kernel Summit. I.e.
a) An invite only event for the top 20-30 developers of the project
b) The main focus would be around finding technical solutions and making 
decisions
I can see the merit of this, but it is too late to do this for all of 
XenSummit due to event contracts that havce been signed.

However we have a number of options, moving towards this:
1) Start half a day early and have an invite only XenDev Event event on 
Sunday afteroon
2) Cut XenSummit short by 1/2 day and append the XenDev event. This may 
incur some financial penalties for Xen.org and the overall ticket cost 
may have to be higher than in the past.
3) Do the invite only meeting in parallel with XenSummit. I have an 
additional large room on TUE the 27th, which we could use for this and I 
also have two break-out rooms and can allocate one of them to the XenDev 
event (these were intended for people sitting together and hacking on 
stuff and/or BoFs). There are several options: hold the XenDev event on
3.1) 26th afternoon
3.2) 27th morning
3.3) 27th afternoon

In my view option 1) and 3.1) have the advantage that we can report back 
to XenSummit, that nobody will miss key talks and that people can sit 
together in the break-out rooms.

Vote
====
Please vote by providing. Vote closes by the 27th. Vote by replying to 
this mail with ...
-1: none of the above (i.e. I dont want a XenDev event)
+1 for a DevMeeting on sunday (aka for proposal 1)
+1 for cutting XenSummit short (aka for proposal 2)
+1 for parallel 26th PM (aka proposal 3.1)
+1 for parallel 27th AM (aka proposal 3.2)
+1 for parallel 27th PM (aka proposal 3.3)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 17:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 17:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLHRe-0008DH-5P; Fri, 20 Apr 2012 17:16:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SLHRd-0008Cn-BO
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 17:16:29 +0000
Received: from [193.109.254.147:63154] by server-4.bemta-14.messagelabs.com id
	CF/D6-11570-BE9919F4; Fri, 20 Apr 2012 17:16:27 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334942186!5579012!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28691 invoked from network); 20 Apr 2012 17:16:27 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 17:16:27 -0000
Received: by eeit10 with SMTP id t10so2719079eei.32
	for <multiple recipients>; Fri, 20 Apr 2012 10:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=YoOTErKoULE6DyteZ528o3Ip/skRLLdixA0OBftrtms=;
	b=dssaMbANR+e1HjmFv5UIxt2zuWHVgD9csC3Bhin6B//mwgkFjEUTarszRtH/I/RMdK
	dXceNqKh41qRcDIk1/Tmdqosh2d+MJYb4SWm7ZgiH7KzgZnyChcYRV7ulR/4VSNmiG6X
	ia30Fe58v+pGwiTZDHcgj3l6zfCX4EHscOisLPS3AGe2vWiABqeuwY9oEGmoLfrct8et
	sKLLBY5T8SaZ73pWGEbHHvw8AtArT+XFb0d0tdmYuT5ujVXbCicF7rAK08V67KVRHN3U
	ybOzgbYzdOdbjWgUUJwH2y8CNCyJPHQOPn4IhIA1a09mt27HYMJiTo5hJ2ORcwh3wr5G
	1aZg==
Received: by 10.14.96.203 with SMTP id r51mr1233813eef.24.1334942186515;
	Fri, 20 Apr 2012 10:16:26 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id e56sm29068809eea.11.2012.04.20.10.16.24
	(version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:16:25 -0700 (PDT)
Message-ID: <4F9199E5.5080409@xen.org>
Date: Fri, 20 Apr 2012 18:16:21 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, 
 xen-api@lists.xen.org
Subject: [Xen-devel] IMPORTANT: Changes to XenSummit Format : Please vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

I have been talking to a number of the key contributors to the project 
regarding XenSummit and got feedback on the format of XenSummit. Please 
read, if you are active in the community and DO VOTE!

Cheers
Lars

Change of date in CFP!
======================
First I wanted to annouce that we are extending the CFP from May 1st to 
15th of June. Key community members felt that May 1 is too early. In 
particular because we have closed the CFP 5-6 weeks before the event in 
the past. Due to contractual issues June 15th is the last day we can do 
though.

Proposal! PLEASE READ!
======================
A number of vendors felt we should change the format of XenSummit to be 
more like the Linux Kernel Summit. I.e.
a) An invite only event for the top 20-30 developers of the project
b) The main focus would be around finding technical solutions and making 
decisions
I can see the merit of this, but it is too late to do this for all of 
XenSummit due to event contracts that havce been signed.

However we have a number of options, moving towards this:
1) Start half a day early and have an invite only XenDev Event event on 
Sunday afteroon
2) Cut XenSummit short by 1/2 day and append the XenDev event. This may 
incur some financial penalties for Xen.org and the overall ticket cost 
may have to be higher than in the past.
3) Do the invite only meeting in parallel with XenSummit. I have an 
additional large room on TUE the 27th, which we could use for this and I 
also have two break-out rooms and can allocate one of them to the XenDev 
event (these were intended for people sitting together and hacking on 
stuff and/or BoFs). There are several options: hold the XenDev event on
3.1) 26th afternoon
3.2) 27th morning
3.3) 27th afternoon

In my view option 1) and 3.1) have the advantage that we can report back 
to XenSummit, that nobody will miss key talks and that people can sit 
together in the break-out rooms.

Vote
====
Please vote by providing. Vote closes by the 27th. Vote by replying to 
this mail with ...
-1: none of the above (i.e. I dont want a XenDev event)
+1 for a DevMeeting on sunday (aka for proposal 1)
+1 for cutting XenSummit short (aka for proposal 2)
+1 for parallel 26th PM (aka proposal 3.1)
+1 for parallel 27th AM (aka proposal 3.2)
+1 for parallel 27th PM (aka proposal 3.3)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 17:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 17:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLHa8-00009Q-8H; Fri, 20 Apr 2012 17:25:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1SLHa6-00009J-Ch
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 17:25:14 +0000
Received: from [85.158.138.51:47331] by server-7.bemta-3.messagelabs.com id
	F1/5B-03078-9FB919F4; Fri, 20 Apr 2012 17:25:13 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334942710!23055434!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14857 invoked from network); 20 Apr 2012 17:25:11 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 17:25:11 -0000
Received: by dajx4 with SMTP id x4so14187124daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 10:25:09 -0700 (PDT)
Received: by 10.68.194.198 with SMTP id hy6mr14574836pbc.0.1334942709383;
	Fri, 20 Apr 2012 10:25:09 -0700 (PDT)
Received: from [25.67.79.194] ([74.198.150.194])
	by mx.google.com with ESMTPS id a9sm5865655pbo.48.2012.04.20.10.25.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Apr 2012 10:25:06 -0700 (PDT)
References: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
	<CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
	<9792753F-4FB1-4C89-9E42-E609B116851B@gmail.com>
In-Reply-To: <9792753F-4FB1-4C89-9E42-E609B116851B@gmail.com>
Mime-Version: 1.0 (1.0)
Message-Id: <C2C7E1BE-2AB8-45EE-B846-CB07E6074F7B@cs.ubc.ca>
X-Mailer: iPhone Mail (9B176)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 20 Apr 2012 10:25:01 -0700
To: Rahul Singh <singh.rahul.1983@gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8606842593294493873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8606842593294493873==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9


--Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2012-04-19, at 3:17 PM, Rahul Singh <singh.rahul.1983@gmail.com> wrote:

> Thanks for pointing me to the comments, Shriram. That was very helpful.
>=20
> What i am unable to figure out is how does Remus tell the module to only r=
elease packets belonging to a given epoch ? I am looking at the BufferedNIC c=
lass in xen-unstable/tools/python/xen/remus/device.py and the postsuspend me=
thod calls self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) while the commit method c=
alls self._sendqmsg(qdisc.TC_PLUG_RELEASE). Where is it telling that only pa=
ckets of the last epoch should be released ?
>=20

The release command tells the module that the packets of last epoch should b=
e released. (implicit). It is called after the checkpoint command for the ne=
xt epoch has been issued in the postsuspend phase.
There is an ASCII diagram on the modules header that shows the sequence.=20

> Also, as you said that module starts out with buffering everything. So if i=
 comment out the self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) but keep the self.=
_sendqmsg(qdisc.TC_PLUG_RELEASE), there should be no network buffering at al=
l, but i still see that all packets are buffered.

To understand this, you need to read the sch_plug.c source

>=20
> Thanking you,
> Rahul.
>=20
> On Apr 19, 2012, at 5:24 PM, Shriram Rajagopalan wrote:
>=20
>> On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <singh.rahul.1983@gmail.com>=
 wrote:
>> Hi,
>> I am trying to understand and change the network buffering that is being u=
sed by Remus, the HA solution present in Xen. =46rom what i understood from r=
eading the code, Remus calls the postsuspend method of the BufferedNIC after=
 it suspends the domain that sends TC_PLUG_CHECKPOINT message and start the b=
uffering
>>=20
>> for packets in the "next" epoch [the one that starts after the domain is r=
esumed]
>> =20
>> and then calls the commit method of BufferedNIC after it gets the acknowl=
edgement that sends the TC_PLUG_RELEASE message and releases the buffered pa=
ckets.=20
>>=20
>> of the previous current epoch [the one whose checkpoint was just committe=
d on the backup machine]
>> =20
>> I have the following doubts
>> 1) How does remus ensure that the packets gets buffered for an entire epo=
ch ?
>>=20
>> I would suggest you go through the comments in=20
>> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dbl=
ob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829861285c0c8f8b7;hb=3D=
HEAD
>> the sch_plug module in upstream linux.=20
>> 2) If i comment out the lines in the "postsuspend" and "commit" lines of t=
he BufferedNIC class that send the TC_PLUG_CHECKPOINT and  TC_PLUG_RELEASE, i=
 see that all the network packets are being buffered and i cannot ping the R=
emus-protected VM at all. Where is the packet buffering happen if i comment o=
ut these 2 lines ?
>>=20
>>=20
>> the module starts out in the buffered mode and releases packets only upon=
 receiving a RELEASE command.
>>=20
>> hope that helps.
>>=20
>> cheers
>> shriram
>> =20
>> Thanking you,
>> Rahul.
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>=20
>>=20
>=20

--Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body bgcolor=3D"#FFFFFF"><div><span class=3D"Apple-style=
-span" style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -we=
bkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composit=
ion-frame-color: rgba(77, 128, 180, 0.230469); ">On 2012-04-19, at 3:17 PM, R=
ahul Singh &lt;<a href=3D"mailto:singh.rahul.1983@gmail.com">singh.rahul.198=
3@gmail.com</a>&gt; wrote:</span></div><div><br></div><div></div><blockquote=
 type=3D"cite"><div>Thanks for pointing me to the comments, Shriram. That wa=
s very helpful.<div><br></div><div>What i am unable to figure out is how doe=
s Remus tell the module to only release packets belonging to a given epoch ?=
 I am looking at the BufferedNIC class in xen-unstable/tools/python/xen/remu=
s/device.py and the postsuspend method calls&nbsp;self._sendqmsg(qdisc.TC_PL=
UG_CHECKPOINT) while the commit method calls&nbsp;self._sendqmsg(qdisc.TC_PL=
UG_RELEASE). Where is it telling that only packets of the last epoch should b=
e released ?</div><div><br></div></div></blockquote><div><br></div>The relea=
se command tells the module that the packets of last epoch should be release=
d. (implicit). It is called after the checkpoint command for the next epoch h=
as been issued in the postsuspend phase.<div>There is an ASCII diagram on th=
e modules header that shows the sequence.&nbsp;</div><div><br><blockquote ty=
pe=3D"cite"><div><div>Also, as you said that module starts out with bufferin=
g everything. So if i comment out the&nbsp;self._sendqmsg(qdisc.TC_PLUG_CHEC=
KPOINT) but keep the&nbsp;self._sendqmsg(qdisc.TC_PLUG_RELEASE), there shoul=
d be no network buffering at all, but i still see that all packets are buffe=
red.</div></div></blockquote><div><br></div>To understand this, you need to r=
ead the sch_plug.c source</div><div><br><blockquote type=3D"cite"><div><div>=
<br></div><div>Thanking you,</div><div>Rahul.</div><div><div><br><div><div>O=
n Apr 19, 2012, at 5:24 PM, Shriram Rajagopalan wrote:</div><br class=3D"App=
le-interchange-newline"><blockquote type=3D"cite"><div class=3D"gmail_quote"=
>On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <span dir=3D"ltr">&lt;<a href=3D=
"mailto:singh.rahul.1983@gmail.com">singh.rahul.1983@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. =46rom what i understood fro=
m reading the code, Remus=20
calls the postsuspend method of the BufferedNIC after it suspends the=20
domain that sends TC_PLUG_CHECKPOINT message and start the buffering</p></di=
v></div></blockquote><div>for packets in the "next" epoch [the one that star=
ts after the domain is resumed]<br>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p> and
 then calls the commit method of BufferedNIC after it gets the=20
acknowledgement that sends the TC_PLUG_RELEASE message and releases the=20
buffered packets. </p></div></div></blockquote><div>of the previous current e=
poch [the one whose checkpoint was just committed on the backup machine]<br>=
&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0p=
t 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>I have the following doubts<br>
1) How does remus ensure that the packets gets buffered for an entire epoch ?=
<br></p></div></div></blockquote><div>I would suggest you go through the com=
ments in <br><a href=3D"http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds=
/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc=
829861285c0c8f8b7;hb=3DHEAD">http://git.kernel.org/?p=3Dlinux/kernel/git/tor=
valds/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091=
881cc829861285c0c8f8b7;hb=3DHEAD</a><br>

the sch_plug module in upstream linux. <br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div style=3D"word-wrap:break-word"><div><p>
2) If i comment out the lines in the "postsuspend" and "commit" lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and=20
TC_PLUG_RELEASE, i see that all the network packets are being buffered=20
and i cannot ping the Remus-protected VM at all. Where is the packet=20
buffering happen if i comment out these 2 lines ?</p></div></div></blockquot=
e><div><br>the module starts out in the buffered mode and releases packets o=
nly upon receiving a RELEASE command.<br><br>hope that helps.<br><br>

cheers<br>shriram<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-=
left:1ex"><div style=3D"word-wrap:break-word"><div><p>Thanking you,<br>
Rahul.</p></div></div><br>_______________________________________________<br=
>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xe=
n.org/xen-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></div></blockquote></div></body></html>=

--Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9--


--===============8606842593294493873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8606842593294493873==--


From xen-devel-bounces@lists.xen.org Fri Apr 20 17:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 17:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLHa8-00009Q-8H; Fri, 20 Apr 2012 17:25:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1SLHa6-00009J-Ch
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 17:25:14 +0000
Received: from [85.158.138.51:47331] by server-7.bemta-3.messagelabs.com id
	F1/5B-03078-9FB919F4; Fri, 20 Apr 2012 17:25:13 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1334942710!23055434!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14857 invoked from network); 20 Apr 2012 17:25:11 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 17:25:11 -0000
Received: by dajx4 with SMTP id x4so14187124daj.28
	for <xen-devel@lists.xen.org>; Fri, 20 Apr 2012 10:25:09 -0700 (PDT)
Received: by 10.68.194.198 with SMTP id hy6mr14574836pbc.0.1334942709383;
	Fri, 20 Apr 2012 10:25:09 -0700 (PDT)
Received: from [25.67.79.194] ([74.198.150.194])
	by mx.google.com with ESMTPS id a9sm5865655pbo.48.2012.04.20.10.25.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Apr 2012 10:25:06 -0700 (PDT)
References: <D9B8217D-3EB0-400E-A6A2-F22B3FB9C824@gmail.com>
	<CAP8mzPOPYzM8HsmVSFtZRJpRUYCurjWm3X-N7v8h8TFZLTu+jw@mail.gmail.com>
	<9792753F-4FB1-4C89-9E42-E609B116851B@gmail.com>
In-Reply-To: <9792753F-4FB1-4C89-9E42-E609B116851B@gmail.com>
Mime-Version: 1.0 (1.0)
Message-Id: <C2C7E1BE-2AB8-45EE-B846-CB07E6074F7B@cs.ubc.ca>
X-Mailer: iPhone Mail (9B176)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 20 Apr 2012 10:25:01 -0700
To: Rahul Singh <singh.rahul.1983@gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus' Network Buffering
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8606842593294493873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8606842593294493873==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9


--Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2012-04-19, at 3:17 PM, Rahul Singh <singh.rahul.1983@gmail.com> wrote:

> Thanks for pointing me to the comments, Shriram. That was very helpful.
>=20
> What i am unable to figure out is how does Remus tell the module to only r=
elease packets belonging to a given epoch ? I am looking at the BufferedNIC c=
lass in xen-unstable/tools/python/xen/remus/device.py and the postsuspend me=
thod calls self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) while the commit method c=
alls self._sendqmsg(qdisc.TC_PLUG_RELEASE). Where is it telling that only pa=
ckets of the last epoch should be released ?
>=20

The release command tells the module that the packets of last epoch should b=
e released. (implicit). It is called after the checkpoint command for the ne=
xt epoch has been issued in the postsuspend phase.
There is an ASCII diagram on the modules header that shows the sequence.=20

> Also, as you said that module starts out with buffering everything. So if i=
 comment out the self._sendqmsg(qdisc.TC_PLUG_CHECKPOINT) but keep the self.=
_sendqmsg(qdisc.TC_PLUG_RELEASE), there should be no network buffering at al=
l, but i still see that all packets are buffered.

To understand this, you need to read the sch_plug.c source

>=20
> Thanking you,
> Rahul.
>=20
> On Apr 19, 2012, at 5:24 PM, Shriram Rajagopalan wrote:
>=20
>> On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <singh.rahul.1983@gmail.com>=
 wrote:
>> Hi,
>> I am trying to understand and change the network buffering that is being u=
sed by Remus, the HA solution present in Xen. =46rom what i understood from r=
eading the code, Remus calls the postsuspend method of the BufferedNIC after=
 it suspends the domain that sends TC_PLUG_CHECKPOINT message and start the b=
uffering
>>=20
>> for packets in the "next" epoch [the one that starts after the domain is r=
esumed]
>> =20
>> and then calls the commit method of BufferedNIC after it gets the acknowl=
edgement that sends the TC_PLUG_RELEASE message and releases the buffered pa=
ckets.=20
>>=20
>> of the previous current epoch [the one whose checkpoint was just committe=
d on the backup machine]
>> =20
>> I have the following doubts
>> 1) How does remus ensure that the packets gets buffered for an entire epo=
ch ?
>>=20
>> I would suggest you go through the comments in=20
>> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dbl=
ob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc829861285c0c8f8b7;hb=3D=
HEAD
>> the sch_plug module in upstream linux.=20
>> 2) If i comment out the lines in the "postsuspend" and "commit" lines of t=
he BufferedNIC class that send the TC_PLUG_CHECKPOINT and  TC_PLUG_RELEASE, i=
 see that all the network packets are being buffered and i cannot ping the R=
emus-protected VM at all. Where is the packet buffering happen if i comment o=
ut these 2 lines ?
>>=20
>>=20
>> the module starts out in the buffered mode and releases packets only upon=
 receiving a RELEASE command.
>>=20
>> hope that helps.
>>=20
>> cheers
>> shriram
>> =20
>> Thanking you,
>> Rahul.
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>=20
>>=20
>=20

--Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body bgcolor=3D"#FFFFFF"><div><span class=3D"Apple-style=
-span" style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -we=
bkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composit=
ion-frame-color: rgba(77, 128, 180, 0.230469); ">On 2012-04-19, at 3:17 PM, R=
ahul Singh &lt;<a href=3D"mailto:singh.rahul.1983@gmail.com">singh.rahul.198=
3@gmail.com</a>&gt; wrote:</span></div><div><br></div><div></div><blockquote=
 type=3D"cite"><div>Thanks for pointing me to the comments, Shriram. That wa=
s very helpful.<div><br></div><div>What i am unable to figure out is how doe=
s Remus tell the module to only release packets belonging to a given epoch ?=
 I am looking at the BufferedNIC class in xen-unstable/tools/python/xen/remu=
s/device.py and the postsuspend method calls&nbsp;self._sendqmsg(qdisc.TC_PL=
UG_CHECKPOINT) while the commit method calls&nbsp;self._sendqmsg(qdisc.TC_PL=
UG_RELEASE). Where is it telling that only packets of the last epoch should b=
e released ?</div><div><br></div></div></blockquote><div><br></div>The relea=
se command tells the module that the packets of last epoch should be release=
d. (implicit). It is called after the checkpoint command for the next epoch h=
as been issued in the postsuspend phase.<div>There is an ASCII diagram on th=
e modules header that shows the sequence.&nbsp;</div><div><br><blockquote ty=
pe=3D"cite"><div><div>Also, as you said that module starts out with bufferin=
g everything. So if i comment out the&nbsp;self._sendqmsg(qdisc.TC_PLUG_CHEC=
KPOINT) but keep the&nbsp;self._sendqmsg(qdisc.TC_PLUG_RELEASE), there shoul=
d be no network buffering at all, but i still see that all packets are buffe=
red.</div></div></blockquote><div><br></div>To understand this, you need to r=
ead the sch_plug.c source</div><div><br><blockquote type=3D"cite"><div><div>=
<br></div><div>Thanking you,</div><div>Rahul.</div><div><div><br><div><div>O=
n Apr 19, 2012, at 5:24 PM, Shriram Rajagopalan wrote:</div><br class=3D"App=
le-interchange-newline"><blockquote type=3D"cite"><div class=3D"gmail_quote"=
>On Thu, Apr 19, 2012 at 9:15 AM, Rahul Singh <span dir=3D"ltr">&lt;<a href=3D=
"mailto:singh.rahul.1983@gmail.com">singh.rahul.1983@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>Hi,<br>
I am trying to understand and change the network buffering that is being
 used by Remus, the HA solution present in Xen. =46rom what i understood fro=
m reading the code, Remus=20
calls the postsuspend method of the BufferedNIC after it suspends the=20
domain that sends TC_PLUG_CHECKPOINT message and start the buffering</p></di=
v></div></blockquote><div>for packets in the "next" epoch [the one that star=
ts after the domain is resumed]<br>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p> and
 then calls the commit method of BufferedNIC after it gets the=20
acknowledgement that sends the TC_PLUG_RELEASE message and releases the=20
buffered packets. </p></div></div></blockquote><div>of the previous current e=
poch [the one whose checkpoint was just committed on the backup machine]<br>=
&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0p=
t 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div style=3D"word-wrap:break-word"><div><p>I have the following doubts<br>
1) How does remus ensure that the packets gets buffered for an entire epoch ?=
<br></p></div></div></blockquote><div>I would suggest you go through the com=
ments in <br><a href=3D"http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds=
/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091881cc=
829861285c0c8f8b7;hb=3DHEAD">http://git.kernel.org/?p=3Dlinux/kernel/git/tor=
valds/linux-2.6.git;a=3Dblob;f=3Dnet/sched/sch_plug.c;h=3D89f8fcf73f18f6e091=
881cc829861285c0c8f8b7;hb=3DHEAD</a><br>

the sch_plug module in upstream linux. <br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div style=3D"word-wrap:break-word"><div><p>
2) If i comment out the lines in the "postsuspend" and "commit" lines of
 the BufferedNIC class that send the TC_PLUG_CHECKPOINT and=20
TC_PLUG_RELEASE, i see that all the network packets are being buffered=20
and i cannot ping the Remus-protected VM at all. Where is the packet=20
buffering happen if i comment out these 2 lines ?</p></div></div></blockquot=
e><div><br>the module starts out in the buffered mode and releases packets o=
nly upon receiving a RELEASE command.<br><br>hope that helps.<br><br>

cheers<br>shriram<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-=
left:1ex"><div style=3D"word-wrap:break-word"><div><p>Thanking you,<br>
Rahul.</p></div></div><br>_______________________________________________<br=
>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xe=
n.org/xen-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></div></blockquote></div></body></html>=

--Apple-Mail-FC7847AB-FDB4-4BB3-AA15-15E068B63FB9--


--===============8606842593294493873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8606842593294493873==--


From xen-devel-bounces@lists.xen.org Fri Apr 20 17:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 17:25:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLHaR-0000AL-Ma; Fri, 20 Apr 2012 17:25:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SLHaP-0000AD-N1
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 17:25:33 +0000
Received: from [193.109.254.147:21567] by server-3.bemta-14.messagelabs.com id
	EC/7B-23274-C0C919F4; Fri, 20 Apr 2012 17:25:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334942722!5610813!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21720 invoked from network); 20 Apr 2012 17:25:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 17:25:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KHPHH8004723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 17:25:18 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KHPGiP006246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 17:25:17 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KHPGHV023808; Fri, 20 Apr 2012 12:25:16 -0500
MIME-Version: 1.0
Message-ID: <092e5985-1066-4897-871a-6e5cd0bf92c3@default>
Date: Fri, 20 Apr 2012 10:25:12 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: wei.huang2@amd.com
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<CBB6D76E.31192%keir.xen@gmail.com>
	<699116fb-992a-4ce2-8071-9bb7d6e43645@default>
	<4F918CD2.7080307@amd.com>
In-Reply-To: <4F918CD2.7080307@amd.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F919BFF.0043,ss=1,re=0.000,fgs=0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Wei Huang [mailto:wei.huang2@amd.com]
> Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by
> hardware
> 
> >>>
> >>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> >>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >>>
> >>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
> >>> Acked-by: Wei Huang<wei.huang2@amd.com>
> >>> Tested-by: Wei Huang<wei.huang2@amd.com>
> >> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> >> possible cross-CPU TSC skew.
> > Provided the hypervisor writes the "TSC-scale-register" with the same
> > value when any vcpu for any guest is scheduled, I don't think
> > there is any cross-CPU TSC skew.
> >
> > But my recollection is that I had a concern that, to work properly
> > after migration, TSC scaling might need to implement:
> >
> > 	((B + cur_tsc) * scale ) + A
> Hi Dan,
> 
> Thanks for your review. I tried to interpret this formula as the following:
> 
> cur_tsc: Guest TSC before migration
> B: time elapsed (overhead) during migration
> scale: ratio of guest frequency/target host frequency
> A: target host TSC

Hi Wei --

I have to admit I don't remember the details of the problem anymore
and can't mentally reproduce it right now.  If TSC scaling is deployed
(on Xen... I imagine it was designed to accommodate VMware)
and works as well as emulation but faster, great!  I just would hope
that there is a great deal of testing done before it becomes
the default because if problems do occur, they will be extremely
difficult to track down.

>> Without the rest of the implementation in the hypervisor
>> and tools, it's hard to determine whether my concern is valid
>> or not.
> If my interpretation above is correct, doesn't emulated TSC have the 
> same problem of B == 0?

That may be true.  But if the emulation code for HVM is broken and
must be fixed, that's a much easier change than a change to a
hardware instruction.

> Hardware TSC scaling uses 8.32 format: 8 bits for integer part and 32
> bits for fraction. Is it enough for the precision from your experience?
> The details of TSC scaling spec can be found on page 554 of
> http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf.

I didn't write the emulation scaling code for HVM... if it uses
a 32-bit scale factor, your 8+32 should be more precise.  If
it uses a 64-bit multiplier, it will be less precise.  OTOH,
the "how many TSC ticks per second" code in Xen may not be
precise anyway.

Keir/Jan, I still think it would be a good idea to implement a
global boot-time "never trust the hardware TSC" option (default off)
which would result in all guests always emulating TSC.
At least this would be a "baseline" and any problems with
it are due to hypervisor bugs.

Dan

P.S. About to be away from email for a few days.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 17:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 17:25:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLHaR-0000AL-Ma; Fri, 20 Apr 2012 17:25:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SLHaP-0000AD-N1
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 17:25:33 +0000
Received: from [193.109.254.147:21567] by server-3.bemta-14.messagelabs.com id
	EC/7B-23274-C0C919F4; Fri, 20 Apr 2012 17:25:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334942722!5610813!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21720 invoked from network); 20 Apr 2012 17:25:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 17:25:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KHPHH8004723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 17:25:18 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KHPGiP006246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 17:25:17 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KHPGHV023808; Fri, 20 Apr 2012 12:25:16 -0500
MIME-Version: 1.0
Message-ID: <092e5985-1066-4897-871a-6e5cd0bf92c3@default>
Date: Fri, 20 Apr 2012 10:25:12 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: wei.huang2@amd.com
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<CBB6D76E.31192%keir.xen@gmail.com>
	<699116fb-992a-4ce2-8071-9bb7d6e43645@default>
	<4F918CD2.7080307@amd.com>
In-Reply-To: <4F918CD2.7080307@amd.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F919BFF.0043,ss=1,re=0.000,fgs=0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Wei Huang [mailto:wei.huang2@amd.com]
> Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by
> hardware
> 
> >>>
> >>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> >>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >>>
> >>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
> >>> Acked-by: Wei Huang<wei.huang2@amd.com>
> >>> Tested-by: Wei Huang<wei.huang2@amd.com>
> >> Worth an ack/nack from Dan M I'd say. He'll probably have some comment about
> >> possible cross-CPU TSC skew.
> > Provided the hypervisor writes the "TSC-scale-register" with the same
> > value when any vcpu for any guest is scheduled, I don't think
> > there is any cross-CPU TSC skew.
> >
> > But my recollection is that I had a concern that, to work properly
> > after migration, TSC scaling might need to implement:
> >
> > 	((B + cur_tsc) * scale ) + A
> Hi Dan,
> 
> Thanks for your review. I tried to interpret this formula as the following:
> 
> cur_tsc: Guest TSC before migration
> B: time elapsed (overhead) during migration
> scale: ratio of guest frequency/target host frequency
> A: target host TSC

Hi Wei --

I have to admit I don't remember the details of the problem anymore
and can't mentally reproduce it right now.  If TSC scaling is deployed
(on Xen... I imagine it was designed to accommodate VMware)
and works as well as emulation but faster, great!  I just would hope
that there is a great deal of testing done before it becomes
the default because if problems do occur, they will be extremely
difficult to track down.

>> Without the rest of the implementation in the hypervisor
>> and tools, it's hard to determine whether my concern is valid
>> or not.
> If my interpretation above is correct, doesn't emulated TSC have the 
> same problem of B == 0?

That may be true.  But if the emulation code for HVM is broken and
must be fixed, that's a much easier change than a change to a
hardware instruction.

> Hardware TSC scaling uses 8.32 format: 8 bits for integer part and 32
> bits for fraction. Is it enough for the precision from your experience?
> The details of TSC scaling spec can be found on page 554 of
> http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf.

I didn't write the emulation scaling code for HVM... if it uses
a 32-bit scale factor, your 8+32 should be more precise.  If
it uses a 64-bit multiplier, it will be less precise.  OTOH,
the "how many TSC ticks per second" code in Xen may not be
precise anyway.

Keir/Jan, I still think it would be a good idea to implement a
global boot-time "never trust the hardware TSC" option (default off)
which would result in all guests always emulating TSC.
At least this would be a "baseline" and any problems with
it are due to hypervisor bugs.

Dan

P.S. About to be away from email for a few days.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:09:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIGU-0000la-Ix; Fri, 20 Apr 2012 18:09:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1SLIGT-0000lV-2p
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:09:01 +0000
Received: from [85.158.139.83:13976] by server-6.bemta-5.messagelabs.com id
	29/98-13222-C36A19F4; Fri, 20 Apr 2012 18:09:00 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334945338!20183731!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22342 invoked from network); 20 Apr 2012 18:08:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Apr 2012 18:08:59 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1608427Ab2DTSIy (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Fri, 20 Apr 2012 20:08:54 +0200
Date: Fri, 20 Apr 2012 20:08:54 +0200
From: Daniel Kiper <dkiper@net-space.pl>
To: aware.why@gmail.com
Message-ID: <20120420180854.GB24553@router-fw-old.local.net-space.pl>
References: <CA+ePHTDdZN8bvCtv0a9noqA6E0TURJ0A2JJPNzMpMerGrk1mNQ@mail.gmail.com>
	<20120314132705.GA3248@router-fw-old.local.net-space.pl>
	<CA+ePHTCTSrYoBSVys-PdsKW0hgCSSvHpu3-soF=oByfAc6wx9A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+ePHTCTSrYoBSVys-PdsKW0hgCSSvHpu3-soF=oByfAc6wx9A@mail.gmail.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com, Daniel Kiper <dkiper@net-space.pl>
Subject: Re: [Xen-devel] How to debug the minios in xen ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 11:53:11PM +0800, ?????? wrote:
> On Wed, Mar 14, 2012 at 9:27 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
>
> > On Tue, Mar 13, 2012 at 02:16:26PM +0800, ?????? wrote:
> > > Hi,
> > >     The minios source code is in extra/minios. After compiling, I got a
> > > file called mini-os.gz, then I succeed to start a domainU by setting the
> > > kernerl to be mini-os.gz in config file 'minios.conf' as follow:
> > > # Kernel image file.
> > > kernel = "/home/test/minios.gz"
> > >
> > >     The command 'xm list' show:
> > > Name                                        ID   Mem VCPUs      State
> > > Time(s)
> > > Domain-0                                     0  1220     2     r-----
> > >  11527.3
> > > minios-120                                   5   256     1     --p---
> > > 1110.5
> > >
> > >     I got the gdbserver-xen later and run 'gdbserver-xen
> > > 127.0.0.1:9999--attach 5'(5 is the domid). Next, run 'gdb
> > > /path/to/minios/exefile', and
> > > then 'bt' in gdb, but no stack info.
> > >     thanks in advance for your help.
> >
> > Hmmm... I think that you forgot to connect to gdbserver-xen.
> > Run following command from gdb: target remote :9999
> > and do not forget compile mini-os with symbols.
> >
> > Daniel
> >
> Thanks???I'll have a try.
> I'm not clear about compiling mini-os with symbols, does it make sense that
> specifing the /path/to/minios-source in gdb cmd line and the gdb would find
> the symbols infomation automatically?

It looks that minios is compiled with debug symbols by default
(I tested it on almost latest Xen Ver. 4.1 tree). It means that
if you pass path to mini-os executable to gdb everything should
work as expected.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:09:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIGU-0000la-Ix; Fri, 20 Apr 2012 18:09:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1SLIGT-0000lV-2p
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:09:01 +0000
Received: from [85.158.139.83:13976] by server-6.bemta-5.messagelabs.com id
	29/98-13222-C36A19F4; Fri, 20 Apr 2012 18:09:00 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-11.tower-182.messagelabs.com!1334945338!20183731!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22342 invoked from network); 20 Apr 2012 18:08:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Apr 2012 18:08:59 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1608427Ab2DTSIy (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Fri, 20 Apr 2012 20:08:54 +0200
Date: Fri, 20 Apr 2012 20:08:54 +0200
From: Daniel Kiper <dkiper@net-space.pl>
To: aware.why@gmail.com
Message-ID: <20120420180854.GB24553@router-fw-old.local.net-space.pl>
References: <CA+ePHTDdZN8bvCtv0a9noqA6E0TURJ0A2JJPNzMpMerGrk1mNQ@mail.gmail.com>
	<20120314132705.GA3248@router-fw-old.local.net-space.pl>
	<CA+ePHTCTSrYoBSVys-PdsKW0hgCSSvHpu3-soF=oByfAc6wx9A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+ePHTCTSrYoBSVys-PdsKW0hgCSSvHpu3-soF=oByfAc6wx9A@mail.gmail.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com, Daniel Kiper <dkiper@net-space.pl>
Subject: Re: [Xen-devel] How to debug the minios in xen ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 11:53:11PM +0800, ?????? wrote:
> On Wed, Mar 14, 2012 at 9:27 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
>
> > On Tue, Mar 13, 2012 at 02:16:26PM +0800, ?????? wrote:
> > > Hi,
> > >     The minios source code is in extra/minios. After compiling, I got a
> > > file called mini-os.gz, then I succeed to start a domainU by setting the
> > > kernerl to be mini-os.gz in config file 'minios.conf' as follow:
> > > # Kernel image file.
> > > kernel = "/home/test/minios.gz"
> > >
> > >     The command 'xm list' show:
> > > Name                                        ID   Mem VCPUs      State
> > > Time(s)
> > > Domain-0                                     0  1220     2     r-----
> > >  11527.3
> > > minios-120                                   5   256     1     --p---
> > > 1110.5
> > >
> > >     I got the gdbserver-xen later and run 'gdbserver-xen
> > > 127.0.0.1:9999--attach 5'(5 is the domid). Next, run 'gdb
> > > /path/to/minios/exefile', and
> > > then 'bt' in gdb, but no stack info.
> > >     thanks in advance for your help.
> >
> > Hmmm... I think that you forgot to connect to gdbserver-xen.
> > Run following command from gdb: target remote :9999
> > and do not forget compile mini-os with symbols.
> >
> > Daniel
> >
> Thanks???I'll have a try.
> I'm not clear about compiling mini-os with symbols, does it make sense that
> specifing the /path/to/minios-source in gdb cmd line and the gdb would find
> the symbols infomation automatically?

It looks that minios is compiled with debug symbols by default
(I tested it on almost latest Xen Ver. 4.1 tree). It means that
if you pass path to mini-os executable to gdb everything should
work as expected.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:22:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:22:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIT2-0001cX-Sy; Fri, 20 Apr 2012 18:22:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLIT1-0001cS-9u
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:21:59 +0000
Received: from [85.158.143.35:58835] by server-1.bemta-4.messagelabs.com id
	4E/64-20925-649A19F4; Fri, 20 Apr 2012 18:21:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334946117!12312823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11364 invoked from network); 20 Apr 2012 18:21:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 18:21:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="12056501"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 18:21:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 19:21:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SLISz-0003L4-4R;
	Fri, 20 Apr 2012 18:21:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SLISz-0000jj-44;
	Fri, 20 Apr 2012 19:21:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12731-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 19:21:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12731: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12731 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12731/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12678
 test-i386-i386-xl             5 xen-boot         fail in 12726 REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install   fail in 12726 REGR. vs. 12678

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 12726

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot             fail in 12726 never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot             fail in 12726 never pass
 test-i386-i386-xl-win         5 xen-boot              fail in 12726 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 12726 never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot          fail in 12726 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12726 never pass
 test-amd64-i386-xl-multivcpu  7 debian-install        fail in 12726 never pass
 test-amd64-i386-xl            7 debian-install        fail in 12726 never pass
 test-i386-i386-pv             7 debian-install        fail in 12726 never pass
 test-amd64-i386-xl-credit2    7 debian-install        fail in 12726 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12726 never pass
 test-i386-i386-win           16 leak-check/check      fail in 12726 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12726 never pass
 test-amd64-i386-pair          8 xen-boot/dst_host     fail in 12726 never pass
 test-amd64-i386-pair          7 xen-boot/src_host     fail in 12726 never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install        fail in 12726 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 12726 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12726 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 12726 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 12726 never pass

version targeted for testing:
 linux                2adb09687b4cd369983ba4533d6eab857262e1b9
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 2adb09687b4cd369983ba4533d6eab857262e1b9
Merge: ba0ed41... 592fe89...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 18 08:07:52 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:22:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:22:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIT2-0001cX-Sy; Fri, 20 Apr 2012 18:22:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLIT1-0001cS-9u
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:21:59 +0000
Received: from [85.158.143.35:58835] by server-1.bemta-4.messagelabs.com id
	4E/64-20925-649A19F4; Fri, 20 Apr 2012 18:21:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334946117!12312823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11364 invoked from network); 20 Apr 2012 18:21:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 18:21:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="12056501"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 18:21:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 19:21:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SLISz-0003L4-4R;
	Fri, 20 Apr 2012 18:21:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SLISz-0000jj-44;
	Fri, 20 Apr 2012 19:21:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12731-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 19:21:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 12731: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12731 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12731/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 12678
 test-i386-i386-xl             5 xen-boot         fail in 12726 REGR. vs. 12678
 test-amd64-i386-pv            7 debian-install   fail in 12726 REGR. vs. 12678

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 12726

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64  5 xen-boot             fail in 12726 never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot             fail in 12726 never pass
 test-i386-i386-xl-win         5 xen-boot              fail in 12726 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 12726 never pass
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot          fail in 12726 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12726 never pass
 test-amd64-i386-xl-multivcpu  7 debian-install        fail in 12726 never pass
 test-amd64-i386-xl            7 debian-install        fail in 12726 never pass
 test-i386-i386-pv             7 debian-install        fail in 12726 never pass
 test-amd64-i386-xl-credit2    7 debian-install        fail in 12726 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12726 never pass
 test-i386-i386-win           16 leak-check/check      fail in 12726 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 12726 never pass
 test-amd64-i386-pair          8 xen-boot/dst_host     fail in 12726 never pass
 test-amd64-i386-pair          7 xen-boot/src_host     fail in 12726 never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install        fail in 12726 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 12726 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12726 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 12726 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 12726 never pass

version targeted for testing:
 linux                2adb09687b4cd369983ba4533d6eab857262e1b9
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 2adb09687b4cd369983ba4533d6eab857262e1b9
Merge: ba0ed41... 592fe89...
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Apr 18 08:07:52 2012 +0200

    Merge branch 'linus'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIj9-000227-3A; Fri, 20 Apr 2012 18:38:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SLIj7-000220-SZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:38:38 +0000
Received: from [85.158.138.51:7891] by server-11.bemta-3.messagelabs.com id
	AD/88-18894-D2DA19F4; Fri, 20 Apr 2012 18:38:37 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334947114!18736602!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28709 invoked from network); 20 Apr 2012 18:38:35 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 18:38:35 -0000
Received: by yhkk6 with SMTP id k6so6539750yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 11:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=qz6ozx+vE3WA2NX6SAOI5F9Yc7o+/D85X8iMFci2zwA=;
	b=Wbd+FD+j/2dggbq/Fq+iC2VHcyl2hjbv6KJyeSVqa6F3D/4yw9KjqY+qioK62G7EDX
	t59lisUcRUvbuyKFEP86BAuNEbj1KI0VoUR2lpqU0JL5qjd+lTq6Lhf8w94ASltYHSWn
	lrBKgM9xo8GwBaU37g3xguUhy0Iz46iF/hspI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=qz6ozx+vE3WA2NX6SAOI5F9Yc7o+/D85X8iMFci2zwA=;
	b=cNDAKzqjjO8NKFz1JNBq2hZaUFgMq34fBhSSA2sbkXeHl4XxxYXzJCwC4pVpngzBys
	CH7sTX+xhwSjJFYKrpVGCbpKCZILtkJqnzvS0dFqJQLCpTalKpJL9bBU53ZnPhEuzD0J
	6lFtWoG+2VlB1XhMmsqjTlvf2HXq4dn10P0qnbGQ2/G8Tom6dTrdjf/XvrH3h+ftYuAR
	2F02miUDypnQu4yZEbKz2wUf+DC3Ykkz8bnSTW+cGKDtC35y1tzw5g/hAFPSwb6n5xSU
	hXc0JFL5qDlGpnU7eY+ZZ4WijPC96xm/u/edq6LYOkDqXpf/LEMda/xms6rF6s80UoVF
	IxAA==
Received: by 10.60.18.198 with SMTP id y6mr6025735oed.38.1334947113747;
	Fri, 20 Apr 2012 11:38:33 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id r8sm6019064oer.6.2012.04.20.11.38.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Apr 2012 11:38:32 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e62ab14d44afb1781a36edf7130fe71977202a60
Message-Id: <e62ab14d44afb1781a36.1334947081@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Fri, 20 Apr 2012 11:38:01 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQniLUesMBVj5mEtjlyGfVTgncD68Sq69/fsFrkkeX2CwhlLohDMC6ESvvtegLTXShk79D35
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH] [v2] libxc: Replace alloca() with mmap() for
 pfn array sizes greater than a page in linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.

Fix an error print with the correct function name.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7c777cb8f705 -r e62ab14d44af tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Fri Apr 20 11:36:02 2012 -0700
@@ -39,6 +39,7 @@
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
 
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
@@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
                 fd, 0);
     if ( addr == MAP_FAILED )
     {
-        PERROR("xc_map_foreign_batch: mmap failed");
+        PERROR("xc_map_foreign_bulk: mmap failed");
         return NULL;
     }
 
@@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn;
+        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
+
+        if ( pfn_arr_size <= XC_PAGE_SIZE )
+            pfn = alloca(num * sizeof(*pfn));
+        else
+        {
+            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
+                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+            if ( pfn == MAP_FAILED )
+            {
+                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+                return NULL;
+            }
+        }
 
         memcpy(pfn, arr, num * sizeof(*arr));
 
@@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
             break;
         }
 
+        if ( pfn_arr_size > XC_PAGE_SIZE )
+            munmap(pfn, pfn_arr_size);
+
         if ( rc == -ENOENT && i == num )
             rc = 0;
         else if ( rc )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIj9-000227-3A; Fri, 20 Apr 2012 18:38:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SLIj7-000220-SZ
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:38:38 +0000
Received: from [85.158.138.51:7891] by server-11.bemta-3.messagelabs.com id
	AD/88-18894-D2DA19F4; Fri, 20 Apr 2012 18:38:37 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334947114!18736602!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28709 invoked from network); 20 Apr 2012 18:38:35 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 18:38:35 -0000
Received: by yhkk6 with SMTP id k6so6539750yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 11:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=qz6ozx+vE3WA2NX6SAOI5F9Yc7o+/D85X8iMFci2zwA=;
	b=Wbd+FD+j/2dggbq/Fq+iC2VHcyl2hjbv6KJyeSVqa6F3D/4yw9KjqY+qioK62G7EDX
	t59lisUcRUvbuyKFEP86BAuNEbj1KI0VoUR2lpqU0JL5qjd+lTq6Lhf8w94ASltYHSWn
	lrBKgM9xo8GwBaU37g3xguUhy0Iz46iF/hspI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=qz6ozx+vE3WA2NX6SAOI5F9Yc7o+/D85X8iMFci2zwA=;
	b=cNDAKzqjjO8NKFz1JNBq2hZaUFgMq34fBhSSA2sbkXeHl4XxxYXzJCwC4pVpngzBys
	CH7sTX+xhwSjJFYKrpVGCbpKCZILtkJqnzvS0dFqJQLCpTalKpJL9bBU53ZnPhEuzD0J
	6lFtWoG+2VlB1XhMmsqjTlvf2HXq4dn10P0qnbGQ2/G8Tom6dTrdjf/XvrH3h+ftYuAR
	2F02miUDypnQu4yZEbKz2wUf+DC3Ykkz8bnSTW+cGKDtC35y1tzw5g/hAFPSwb6n5xSU
	hXc0JFL5qDlGpnU7eY+ZZ4WijPC96xm/u/edq6LYOkDqXpf/LEMda/xms6rF6s80UoVF
	IxAA==
Received: by 10.60.18.198 with SMTP id y6mr6025735oed.38.1334947113747;
	Fri, 20 Apr 2012 11:38:33 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id r8sm6019064oer.6.2012.04.20.11.38.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Apr 2012 11:38:32 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e62ab14d44afb1781a36edf7130fe71977202a60
Message-Id: <e62ab14d44afb1781a36.1334947081@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Fri, 20 Apr 2012 11:38:01 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQniLUesMBVj5mEtjlyGfVTgncD68Sq69/fsFrkkeX2CwhlLohDMC6ESvvtegLTXShk79D35
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH] [v2] libxc: Replace alloca() with mmap() for
 pfn array sizes greater than a page in linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.

Fix an error print with the correct function name.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7c777cb8f705 -r e62ab14d44af tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Fri Apr 20 11:36:02 2012 -0700
@@ -39,6 +39,7 @@
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
 
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
@@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
                 fd, 0);
     if ( addr == MAP_FAILED )
     {
-        PERROR("xc_map_foreign_batch: mmap failed");
+        PERROR("xc_map_foreign_bulk: mmap failed");
         return NULL;
     }
 
@@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn;
+        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
+
+        if ( pfn_arr_size <= XC_PAGE_SIZE )
+            pfn = alloca(num * sizeof(*pfn));
+        else
+        {
+            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
+                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+            if ( pfn == MAP_FAILED )
+            {
+                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+                return NULL;
+            }
+        }
 
         memcpy(pfn, arr, num * sizeof(*arr));
 
@@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
             break;
         }
 
+        if ( pfn_arr_size > XC_PAGE_SIZE )
+            munmap(pfn, pfn_arr_size);
+
         if ( rc == -ENOENT && i == num )
             rc = 0;
         else if ( rc )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:45:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIpb-0002On-0I; Fri, 20 Apr 2012 18:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLIpZ-0002OW-F6
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:45:17 +0000
Received: from [85.158.138.51:36941] by server-3.bemta-3.messagelabs.com id
	83/39-04048-CBEA19F4; Fri, 20 Apr 2012 18:45:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334947504!23054010!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25719 invoked from network); 20 Apr 2012 18:45:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 18:45:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KIj2Zh025903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 18:45:03 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KIj123012271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 18:45:01 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KIj1Vn031926; Fri, 20 Apr 2012 13:45:01 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 11:45:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C077D4032D; Fri, 20 Apr 2012 14:40:01 -0400 (EDT)
Date: Fri, 20 Apr 2012 14:40:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120420184001.GA447@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F91AEAF.0040,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 01:29:06PM +0000, Liu, Jinsong wrote:
> >From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 20 Apr 2012 05:08:38 +0800
> Subject: [PATCH 1/3] Add mcelog support for xen platform
> 
> When MCA error occurs, it would be handled by xen hypervisor first,
> and then the error information would be sent to dom0 for logging.

How do I test this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 18:45:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 18:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLIpb-0002On-0I; Fri, 20 Apr 2012 18:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLIpZ-0002OW-F6
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 18:45:17 +0000
Received: from [85.158.138.51:36941] by server-3.bemta-3.messagelabs.com id
	83/39-04048-CBEA19F4; Fri, 20 Apr 2012 18:45:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334947504!23054010!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgzMTA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25719 invoked from network); 20 Apr 2012 18:45:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 18:45:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KIj2Zh025903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 18:45:03 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KIj123012271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 18:45:01 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KIj1Vn031926; Fri, 20 Apr 2012 13:45:01 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 11:45:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C077D4032D; Fri, 20 Apr 2012 14:40:01 -0400 (EDT)
Date: Fri, 20 Apr 2012 14:40:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120420184001.GA447@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F91AEAF.0040,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 01:29:06PM +0000, Liu, Jinsong wrote:
> >From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 20 Apr 2012 05:08:38 +0800
> Subject: [PATCH 1/3] Add mcelog support for xen platform
> 
> When MCA error occurs, it would be handled by xen hypervisor first,
> and then the error information would be sent to dom0 for logging.

How do I test this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 19:14:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 19:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLJHr-0002vp-GJ; Fri, 20 Apr 2012 19:14:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLJHp-0002vk-Et
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 19:14:29 +0000
Received: from [193.109.254.147:49378] by server-12.bemta-14.messagelabs.com
	id A6/1A-05898-495B19F4; Fri, 20 Apr 2012 19:14:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334949266!5588917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8173 invoked from network); 20 Apr 2012 19:14:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 19:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="12057079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 19:14:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 20:14:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SLJHm-0003lP-3o;
	Fri, 20 Apr 2012 19:14:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SLJHl-0007qW-Su;
	Fri, 20 Apr 2012 20:14:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12732-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 20:14:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12732: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12732 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12732/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12727
 build-i386                    4 xen-build                 fail REGR. vs. 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 19:14:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 19:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLJHr-0002vp-GJ; Fri, 20 Apr 2012 19:14:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLJHp-0002vk-Et
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 19:14:29 +0000
Received: from [193.109.254.147:49378] by server-12.bemta-14.messagelabs.com
	id A6/1A-05898-495B19F4; Fri, 20 Apr 2012 19:14:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1334949266!5588917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTMwNQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8173 invoked from network); 20 Apr 2012 19:14:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 19:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="12057079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Apr 2012 19:14:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Apr 2012 20:14:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SLJHm-0003lP-3o;
	Fri, 20 Apr 2012 19:14:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SLJHl-0007qW-Su;
	Fri, 20 Apr 2012 20:14:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12732-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Apr 2012 20:14:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12732: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12732 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12732/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 12727
 build-i386                    4 xen-build                 fail REGR. vs. 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 19:21:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 19:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLJOd-000365-Hp; Fri, 20 Apr 2012 19:21:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SLJOc-00035z-17
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 19:21:30 +0000
Received: from [85.158.138.51:64520] by server-12.bemta-3.messagelabs.com id
	D8/8D-29760-837B19F4; Fri, 20 Apr 2012 19:21:28 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334949686!14153968!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNDA5MDI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17632 invoked from network); 20 Apr 2012 19:21:28 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 19:21:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="221612459"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2012 19:21:24 +0000
Received: from u080027117f7b4f7df600.sea31.amazon.com
	(vpn-10-50-165-218.dub4.amazon.com [10.50.165.218])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q3KJLIix014172; Fri, 20 Apr 2012 19:21:20 GMT
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 20 Apr 2012 19:21:12 +0000
Message-Id: <1334949673-25632-1-git-send-email-msw@amazon.com>
X-Mailer: git-send-email 1.7.2.5
Cc: Joe Jin <joe.jin@oracle.com>, Matt Wilson <msw@amazon.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC] [PATCH] add locking in statistics sysfs show
	functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The blkback code in the 2.6.18 tree has a patch to avoid a race condition
in the statistics sysfs routines. Is it no longer needed? The following
patch ports the change to 3.x.

Matt Wilson (1):
  xen/blkback: add locking in statistics sysfs show functions

 drivers/block/xen-blkback/xenbus.c |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 19:21:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 19:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLJOd-000365-Hp; Fri, 20 Apr 2012 19:21:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SLJOc-00035z-17
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 19:21:30 +0000
Received: from [85.158.138.51:64520] by server-12.bemta-3.messagelabs.com id
	D8/8D-29760-837B19F4; Fri, 20 Apr 2012 19:21:28 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334949686!14153968!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNDA5MDI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17632 invoked from network); 20 Apr 2012 19:21:28 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 19:21:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="221612459"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2012 19:21:24 +0000
Received: from u080027117f7b4f7df600.sea31.amazon.com
	(vpn-10-50-165-218.dub4.amazon.com [10.50.165.218])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q3KJLIix014172; Fri, 20 Apr 2012 19:21:20 GMT
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 20 Apr 2012 19:21:12 +0000
Message-Id: <1334949673-25632-1-git-send-email-msw@amazon.com>
X-Mailer: git-send-email 1.7.2.5
Cc: Joe Jin <joe.jin@oracle.com>, Matt Wilson <msw@amazon.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC] [PATCH] add locking in statistics sysfs show
	functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The blkback code in the 2.6.18 tree has a patch to avoid a race condition
in the statistics sysfs routines. Is it no longer needed? The following
patch ports the change to 3.x.

Matt Wilson (1):
  xen/blkback: add locking in statistics sysfs show functions

 drivers/block/xen-blkback/xenbus.c |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 19:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 19:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLJPN-00038o-VT; Fri, 20 Apr 2012 19:22:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SLJPM-00038a-DT
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 19:22:16 +0000
Received: from [85.158.143.99:44760] by server-3.bemta-4.messagelabs.com id
	B4/B2-05853-767B19F4; Fri, 20 Apr 2012 19:22:15 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334949732!18208616!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3MDE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4392 invoked from network); 20 Apr 2012 19:22:14 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 19:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="724611544"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2012 19:22:11 +0000
Received: from u080027117f7b4f7df600.sea31.amazon.com
	(vpn-10-50-165-218.dub4.amazon.com [10.50.165.218])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q3KJLIj0014172; Fri, 20 Apr 2012 19:22:08 GMT
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 20 Apr 2012 19:21:13 +0000
Message-Id: <1334949673-25632-2-git-send-email-msw@amazon.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334949673-25632-1-git-send-email-msw@amazon.com>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
Cc: Joe Jin <joe.jin@oracle.com>, Matt Wilson <msw@amazon.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in statistics
	sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a port of a patch in the XenoLinux 2.6.18 tree:
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56

Fix blkback sysfs race

Read blkback statistics info after remove vbd device(s) kernel
will crash.

Signed-off-by: Joe Jin <joe.jin@oracle.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
[Ported to Linux 3.x]
Signed-off-by: Matt Wilson <msw@amazon.com>
---
 drivers/block/xen-blkback/xenbus.c |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index da19506..74d4810 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -21,6 +21,8 @@
 #include <xen/grant_table.h>
 #include "common.h"
 
+static DEFINE_RWLOCK(sysfs_read_lock);
+
 struct backend_info {
 	struct xenbus_device	*dev;
 	struct xen_blkif	*blkif;
@@ -225,10 +227,20 @@ int __init xen_blkif_interface_init(void)
 				   struct device_attribute *attr,	\
 				   char *buf)				\
 	{								\
-		struct xenbus_device *dev = to_xenbus_device(_dev);	\
-		struct backend_info *be = dev_get_drvdata(&dev->dev);	\
+		ssize_t ret = -ENODEV;					\
+		struct xenbus_device *dev;				\
+		struct backend_info *be;				\
 									\
-		return sprintf(buf, format, ##args);			\
+		if (!get_device(_dev))					\
+			return ret;					\
+		dev = to_xenbus_device(_dev);				\
+		read_lock(&sysfs_read_lock);				\
+		be = (struct backend_info *) dev_get_drvdata(&dev->dev);\
+		if (be != NULL)						\
+			ret = sprintf(buf, format, ##args);		\
+		read_unlock(&sysfs_read_lock);				\
+		put_device(_dev);					\
+		return ret;						\
 	}								\
 	static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
 
@@ -353,6 +365,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
 
 	DPRINTK("");
 
+	write_lock(&sysfs_read_lock);
 	if (be->major || be->minor)
 		xenvbd_sysfs_delif(dev);
 
@@ -371,6 +384,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
 
 	kfree(be);
 	dev_set_drvdata(&dev->dev, NULL);
+	write_unlock(&sysfs_read_lock);
 	return 0;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 19:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 19:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLJPN-00038o-VT; Fri, 20 Apr 2012 19:22:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SLJPM-00038a-DT
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 19:22:16 +0000
Received: from [85.158.143.99:44760] by server-3.bemta-4.messagelabs.com id
	B4/B2-05853-767B19F4; Fri, 20 Apr 2012 19:22:15 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1334949732!18208616!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3MDE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4392 invoked from network); 20 Apr 2012 19:22:14 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Apr 2012 19:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="724611544"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2012 19:22:11 +0000
Received: from u080027117f7b4f7df600.sea31.amazon.com
	(vpn-10-50-165-218.dub4.amazon.com [10.50.165.218])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q3KJLIj0014172; Fri, 20 Apr 2012 19:22:08 GMT
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 20 Apr 2012 19:21:13 +0000
Message-Id: <1334949673-25632-2-git-send-email-msw@amazon.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1334949673-25632-1-git-send-email-msw@amazon.com>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
Cc: Joe Jin <joe.jin@oracle.com>, Matt Wilson <msw@amazon.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in statistics
	sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a port of a patch in the XenoLinux 2.6.18 tree:
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56

Fix blkback sysfs race

Read blkback statistics info after remove vbd device(s) kernel
will crash.

Signed-off-by: Joe Jin <joe.jin@oracle.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
[Ported to Linux 3.x]
Signed-off-by: Matt Wilson <msw@amazon.com>
---
 drivers/block/xen-blkback/xenbus.c |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index da19506..74d4810 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -21,6 +21,8 @@
 #include <xen/grant_table.h>
 #include "common.h"
 
+static DEFINE_RWLOCK(sysfs_read_lock);
+
 struct backend_info {
 	struct xenbus_device	*dev;
 	struct xen_blkif	*blkif;
@@ -225,10 +227,20 @@ int __init xen_blkif_interface_init(void)
 				   struct device_attribute *attr,	\
 				   char *buf)				\
 	{								\
-		struct xenbus_device *dev = to_xenbus_device(_dev);	\
-		struct backend_info *be = dev_get_drvdata(&dev->dev);	\
+		ssize_t ret = -ENODEV;					\
+		struct xenbus_device *dev;				\
+		struct backend_info *be;				\
 									\
-		return sprintf(buf, format, ##args);			\
+		if (!get_device(_dev))					\
+			return ret;					\
+		dev = to_xenbus_device(_dev);				\
+		read_lock(&sysfs_read_lock);				\
+		be = (struct backend_info *) dev_get_drvdata(&dev->dev);\
+		if (be != NULL)						\
+			ret = sprintf(buf, format, ##args);		\
+		read_unlock(&sysfs_read_lock);				\
+		put_device(_dev);					\
+		return ret;						\
 	}								\
 	static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
 
@@ -353,6 +365,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
 
 	DPRINTK("");
 
+	write_lock(&sysfs_read_lock);
 	if (be->major || be->minor)
 		xenvbd_sysfs_delif(dev);
 
@@ -371,6 +384,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
 
 	kfree(be);
 	dev_set_drvdata(&dev->dev, NULL);
+	write_unlock(&sysfs_read_lock);
 	return 0;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 20:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 20:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLK0p-0003op-PK; Fri, 20 Apr 2012 20:00:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SLK0o-0003ok-Ih
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 20:00:58 +0000
Received: from [193.109.254.147:11705] by server-8.bemta-14.messagelabs.com id
	11/CC-23244-970C19F4; Fri, 20 Apr 2012 20:00:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334952056!3125904!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE4MzYy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8877 invoked from network); 20 Apr 2012 20:00:57 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-27.messagelabs.com with SMTP;
	20 Apr 2012 20:00:57 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 20 Apr 2012 13:00:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="133488159"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 20 Apr 2012 13:00:55 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 20 Apr 2012 13:00:55 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Sat, 21 Apr 2012 04:00:53 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNHyT+bwDu17uMTQ2vQPuvK5oUmpakGzsg
Date: Fri, 20 Apr 2012 20:00:53 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335159293@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120420184001.GA447@phenom.dumpdata.com>
In-Reply-To: <20120420184001.GA447@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 19, 2012 at 01:29:06PM +0000, Liu, Jinsong wrote:
>>> From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00
>>> 2001 =

>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Fri, 20 Apr 2012 05:08:38 +0800
>> Subject: [PATCH 1/3] Add mcelog support for xen platform
>> =

>> When MCA error occurs, it would be handled by xen hypervisor first,
>> and then the error information would be sent to dom0 for logging.
> =

> How do I test this?

It can be tested by EINJ tool to inject an memory error, and by mcelog tool=
 to read error info, basically it need:

1. enable einj tools: load EINJ kernel module and mount debugfs;

2. set error type
# cat available_error_type (depend on your bios)
0x00000002=A0=A0=A0=A0=A0 Processor Uncorrectable non-fatal
0x00000008=A0=A0=A0=A0=A0 Memory Correctable
0x00000010=A0=A0=A0=A0=A0 Memory Uncorrectable non-fatal
# echo 0x8 > error_type

3. find a proper physical address for injection (usually use a free page li=
ke xen heap page)
=A0
4. set the injection address and mask
# echo address > param1
# echo mask > param2
=A0
5. inject error
# echo 1 > error_inject
=A0
6. use mcelog tool to read error info


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 20:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 20:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLK0p-0003op-PK; Fri, 20 Apr 2012 20:00:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SLK0o-0003ok-Ih
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 20:00:58 +0000
Received: from [193.109.254.147:11705] by server-8.bemta-14.messagelabs.com id
	11/CC-23244-970C19F4; Fri, 20 Apr 2012 20:00:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1334952056!3125904!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE4MzYy\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8877 invoked from network); 20 Apr 2012 20:00:57 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-27.messagelabs.com with SMTP;
	20 Apr 2012 20:00:57 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 20 Apr 2012 13:00:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="133488159"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 20 Apr 2012 13:00:55 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 20 Apr 2012 13:00:55 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.195]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.57]) with mapi id
	14.01.0355.002; Sat, 21 Apr 2012 04:00:53 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNHyT+bwDu17uMTQ2vQPuvK5oUmpakGzsg
Date: Fri, 20 Apr 2012 20:00:53 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335159293@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120420184001.GA447@phenom.dumpdata.com>
In-Reply-To: <20120420184001.GA447@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 19, 2012 at 01:29:06PM +0000, Liu, Jinsong wrote:
>>> From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00
>>> 2001 =

>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Fri, 20 Apr 2012 05:08:38 +0800
>> Subject: [PATCH 1/3] Add mcelog support for xen platform
>> =

>> When MCA error occurs, it would be handled by xen hypervisor first,
>> and then the error information would be sent to dom0 for logging.
> =

> How do I test this?

It can be tested by EINJ tool to inject an memory error, and by mcelog tool=
 to read error info, basically it need:

1. enable einj tools: load EINJ kernel module and mount debugfs;

2. set error type
# cat available_error_type (depend on your bios)
0x00000002=A0=A0=A0=A0=A0 Processor Uncorrectable non-fatal
0x00000008=A0=A0=A0=A0=A0 Memory Correctable
0x00000010=A0=A0=A0=A0=A0 Memory Uncorrectable non-fatal
# echo 0x8 > error_type

3. find a proper physical address for injection (usually use a free page li=
ke xen heap page)
=A0
4. set the injection address and mask
# echo address > param1
# echo mask > param2
=A0
5. inject error
# echo 1 > error_inject
=A0
6. use mcelog tool to read error info


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 20:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 20:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLKrn-0004VG-BF; Fri, 20 Apr 2012 20:55:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLKrl-0004Ux-Ag
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 20:55:41 +0000
Received: from [85.158.143.35:28389] by server-1.bemta-4.messagelabs.com id
	5E/55-20925-C4DC19F4; Fri, 20 Apr 2012 20:55:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334955337!12323972!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4892 invoked from network); 20 Apr 2012 20:55:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 20:55:39 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KKicnp000628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 20:55:35 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KJTcQa010695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 19:29:41 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KJTc5e009568; Fri, 20 Apr 2012 14:29:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 12:29:38 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A5574032D; Fri, 20 Apr 2012 15:24:39 -0400 (EDT)
Date: Fri, 20 Apr 2012 15:24:39 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120420192439.GA32170@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154F3E@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335154F3E@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F91CD48.0026,ss=1,re=1.599,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 01:33:03PM +0000, Liu, Jinsong wrote:
> >From afdd30a7769e706e9be64f80d64136e2e267ecb9 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 20 Apr 2012 05:11:58 +0800
> Subject: [PATCH 3/3] Xen physical cpus interface
> 
> Manage physical cpus in dom0, get physical cpus info and provide sys interface.

Anything that exposes SysFS attributes needs documentation in 
Documentation/ABI

Can you explain what this solves? And if there are any
userland applications that use this?


> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> ---
>  drivers/xen/Makefile             |    1 +
>  drivers/xen/pcpu.c               |  393 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   10 +-
>  include/xen/interface/xen.h      |    1 +
>  4 files changed, 404 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/xen/pcpu.c
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 1d3e763..d12d14d 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o
> +obj-$(CONFIG_XEN_DOM0)			+= pcpu.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> new file mode 100644
> index 0000000..9295def
> --- /dev/null
> +++ b/drivers/xen/pcpu.c
> @@ -0,0 +1,393 @@
> +/******************************************************************************
> + * pcpu.c
> + * Management physical cpu in dom0, get pcpu info and provide sys interface
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <linux/cpu.h>
> +#include <linux/stat.h>
> +#include <xen/xen.h>
> +#include <xen/xenbus.h>
> +#include <xen/events.h>
> +#include <xen/interface/platform.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +struct pcpu {
> +	struct list_head pcpu_list;
> +	struct device dev;
> +	uint32_t xen_id;

What is a 'xen_id'? Can you put a provide a comment
explaining the relationship between that and apic_id acpi_id
and flags?

Or better yet, just at the start of the structure have:

/*
 * @xen_id The ...
 * @apic_id ... so on.


> +	uint32_t apic_id;
> +	uint32_t acpi_id;
> +	uint32_t flags;
> +};
> +
> +static struct bus_type xen_pcpu_subsys = {

> +	.name = "xen_cpu",
> +	.dev_name = "xen_cpu",
> +};
> +
> +static DEFINE_MUTEX(xen_pcpu_lock);
> +#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);

Just use the mutex - no point of using the #define


> +#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
> +
> +#define XEN_PCPU "xen_cpu: "
> +
> +struct xen_pcpus {
> +	struct list_head list;

Uh, so it is just a list? 
> +};
> +static struct xen_pcpus xen_pcpus;

Can't you just do

static struct pcpu * xen_pcpus;

And then use that to add/remove items?

> +
> +static int xen_pcpu_down(uint32_t xen_id)
> +{
> +	int ret;
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_offline,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;

Just collapse it in:
	return HYPERVISOR_dom0_op..

> +}
> +
> +static int xen_pcpu_up(uint32_t xen_id)
> +{
> +	int ret;
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_online,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;

Ditto.

> +}
> +
> +static ssize_t show_online(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
> +}
> +
> +static ssize_t __ref store_online(struct device *dev,
> +				  struct device_attribute *attr,
> +				  const char *buf, size_t count)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +	ssize_t ret;
> +

Add:
	if (!capable(CAP_SYS_ADMIN))
		return -EPERM;


> +	switch (buf[0]) {

Use strict_strtoull pls.

> +	case '0':
> +		ret = xen_pcpu_down(cpu->xen_id);
> +		break;
> +	case '1':
> +		ret = xen_pcpu_up(cpu->xen_id);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	if (ret >= 0)
> +		ret = count;
> +	return ret;
> +}
> +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);

> +
> +static ssize_t show_apicid(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", cpu->apic_id);
> +}
> +
> +static ssize_t show_acpiid(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", cpu->acpi_id);
> +}
> +static DEVICE_ATTR(apic_id, S_IRUGO, show_apicid, NULL);
> +static DEVICE_ATTR(acpi_id, S_IRUGO, show_acpiid, NULL);

What benefit is there in exposing these values to the user?

> +
> +static bool xen_pcpu_online(uint32_t flags)
> +{
> +	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
> +}
> +
> +static void pcpu_online_status(struct xenpf_pcpuinfo *info,
> +			       struct pcpu *pcpu)
> +{
> +	if (xen_pcpu_online(info->flags) &&
> +	   !xen_pcpu_online(pcpu->flags)) {
> +		/* the pcpu is onlined */
> +		pcpu->flags |= XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
> +	} else if (!xen_pcpu_online(info->flags) &&
> +		    xen_pcpu_online(pcpu->flags)) {
> +		/* The pcpu is offlined */
> +		pcpu->flags &= ~XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
> +	}
> +}
> +
> +static struct pcpu *get_pcpu(uint32_t xen_id)
> +{
> +	struct pcpu *pcpu = NULL;
> +
> +	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
> +		if (pcpu->xen_id == xen_id)
> +			return pcpu;
> +	}
> +	return NULL;
> +}
> +
> +static void pcpu_sys_remove(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +
> +	if (!pcpu)
> +		return;
> +
> +	dev = &pcpu->dev;
> +	if (dev->id)
> +		device_remove_file(dev, &dev_attr_online);
> +	device_remove_file(dev, &dev_attr_acpi_id);
> +	device_remove_file(dev, &dev_attr_apic_id);
> +	device_unregister(dev);

So .. if you are using that, can't you use the .release
and define something like:

static void pcpu_release(struct device *dev)
{
	struct pcpu *pcpu = container_of(dev, struct pcpu, dev);

	list_del(&pcpu->pcpu_list);
	kfree(pcpu);
}
> +}
> +
> +static void free_pcpu(struct pcpu *pcpu)
> +{
> +	if (!pcpu)
> +		return;
> +
> +	pcpu_sys_remove(pcpu);

> +	list_del(&pcpu->pcpu_list);
> +	kfree(pcpu);

Those two shouldn't be there. They sould be part of the
release function.
> +}
> +
> +static int pcpu_sys_create(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +	int err = -EINVAL;
> +
> +	if (!pcpu)
> +		return err;
> +
> +	dev = &pcpu->dev;
> +	dev->bus = &xen_pcpu_subsys;
> +	dev->id = pcpu->xen_id;

And then here dev->release = &pcpu_release;

> +
> +	err = device_register(dev);
> +	if (err)
> +		goto err1;
> +
> +	err = device_create_file(dev, &dev_attr_apic_id);
> +	if (err)
> +		goto err2;
> +	err = device_create_file(dev, &dev_attr_acpi_id);
> +	if (err)
> +		goto err3;

Usually this is done with an array, like the drivers/xen/xen-balloon.c
..
But I am still not sure why these two parameters are needed?

> +	/* Not open pcpu0 online access to user */

Huh? You mean "Nobody can touch PCPU0" ?

Why? Why can they touch the other ones? And better yet,
what happens if one boots without "dom0_max_vcpus=X"
and powers of some of the CPUs?

> +	if (dev->id) {
> +		err = device_create_file(dev, &dev_attr_online);
> +		if (err)
> +			goto err4;
> +	}
> +
> +	return 0;
> +
> +err4:
> +	device_remove_file(dev, &dev_attr_acpi_id);
> +err3:
> +	device_remove_file(dev, &dev_attr_apic_id);
> +err2:
> +	device_unregister(dev);
> +err1:
> +	return err;
> +}
> +
> +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
> +{
> +	struct pcpu *pcpu;
> +	int err;
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID)
> +		return ERR_PTR(-ENODEV);
> +
> +	pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL);
> +	if (!pcpu)
> +		return ERR_PTR(-ENOMEM);
> +
> +	INIT_LIST_HEAD(&pcpu->pcpu_list);
> +	pcpu->xen_id = info->xen_cpuid;
> +	pcpu->apic_id = info->apic_id;
> +	pcpu->acpi_id = info->acpi_id;
> +	pcpu->flags = info->flags;
> +
> +	err = pcpu_sys_create(pcpu);
> +	if (err) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu%d\n",

Not %u?
> +			   info->xen_cpuid);
> +		kfree(pcpu);
> +		return ERR_PTR(-ENOENT);
> +	}
> +

Should this be protected by the mutex? [edit: I see now
that the calleer is suppose to hold on the lock.
Mention that please right before you do any list manipulations]


> +	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
> +	return pcpu;
> +}
> +
> +/*
> + * Caller should hold the pcpu lock

Provide full name of the mutex lock.
> + */
> +static int _sync_pcpu(uint32_t cpu_num, uint32_t *ptr_max_cpu_num)

Why the '_' in front of the name?

For parameters do:

uint32 cpu, uint32 *max_cpu

> +{
> +	int ret;
> +	struct pcpu *pcpu = NULL;
> +	struct xenpf_pcpuinfo *info;
> +	struct xen_platform_op op = {
> +		.cmd                   = XENPF_get_cpuinfo,
> +		.interface_version     = XENPF_INTERFACE_VERSION,
> +		.u.pcpu_info.xen_cpuid = cpu_num,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	info = &op.u.pcpu_info;
> +	if (ptr_max_cpu_num)
> +		*ptr_max_cpu_num = info->max_present;
> +
> +	pcpu = get_pcpu(cpu_num);
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
> +		/* The pcpu has been removed */
> +		if (pcpu)
> +			free_pcpu(pcpu);
> +		return 0;
> +	}
> +
> +	if (!pcpu) {
> +		pcpu = init_pcpu(info);
> +		if (IS_ERR_OR_NULL(pcpu))
> +			return -ENODEV;
> +	} else
> +		pcpu_online_status(info, pcpu);
> +
> +	return 0;
> +}
> +
> +/*
> + * Sync dom0's pcpu information with xen hypervisor's
> + */
> +static int xen_sync_pcpus(void)
> +{
> +	/*
> +	 * Boot cpu always have cpu_id 0 in xen
> +	 */
> +	uint32_t cpu_num = 0, max_cpu_num = 0;

Use 'cpu' and 'max_cpu'

> +	int err = 0;
> +	struct list_head *elem, *tmp;
> +	struct pcpu *pcpu;
> +
> +	get_pcpu_lock();
> +
> +	while (!err && (cpu_num <= max_cpu_num)) {
> +		err = _sync_pcpu(cpu_num, &max_cpu_num);
> +		cpu_num++;
> +	}
> +
> +	if (err) {
> +		list_for_each_safe(elem, tmp, &xen_pcpus.list) {

s/elem/pcpu/

> +			pcpu = list_entry(elem, struct pcpu, pcpu_list);

That you can remove once you make the xen_pcpus structure as I mentioned
above.

> +			free_pcpu(pcpu);
> +		}
> +	}
> +
> +	put_pcpu_lock();

Ah, so you are locking around here.
> +
> +	return err;
> +}
> +
> +static void xen_pcpu_dpc(struct work_struct *work)

s/dpc/workqueue/

> +{
> +	xen_sync_pcpus();
> +}
> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
> +
> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_pcpu_init(void)
> +{
> +	int ret;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	ret = subsys_system_register(&xen_pcpu_subsys, NULL);
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
> +		return ret;
> +	}
> +
> +	INIT_LIST_HEAD(&xen_pcpus.list);
> +
> +	ret = xen_sync_pcpus();
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
> +		return ret;
> +	}
> +
> +	ret = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
> +				      xen_pcpu_interrupt, 0,
> +				      "pcpu", NULL);

"xen-pcpu"

> +	if (ret < 0) {
> +		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");

Shouldn't you delete what 'xen_sync_pcpus' did?
Or is it OK to still work without the interrupts? What is the purpose
of that interrupt? How does it actually work - the hypervisor
decides when/where to turn off CPUs?

> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +arch_initcall(xen_pcpu_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 486653f..2c56d4f 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -298,7 +298,7 @@ struct xenpf_set_processor_pminfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
>  
> -#define XENPF_get_cpuinfo 55
> +#define XENPF_get_cpuinfo	55

Why?

>  struct xenpf_pcpuinfo {
>  	/* IN */
>  	uint32_t xen_cpuid;
> @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
>  
> +#define XENPF_cpu_online	56
> +#define XENPF_cpu_offline	57
> +struct xenpf_cpu_ol {
> +	uint32_t cpuid;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -330,6 +337,7 @@ struct xen_platform_op {
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
>  		struct xenpf_pcpuinfo          pcpu_info;
> +		struct xenpf_cpu_ol            cpu_ol;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index a890804..0801468 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -80,6 +80,7 @@
>  #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. */
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> +#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 20 20:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Apr 2012 20:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLKrn-0004VG-BF; Fri, 20 Apr 2012 20:55:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLKrl-0004Ux-Ag
	for xen-devel@lists.xensource.com; Fri, 20 Apr 2012 20:55:41 +0000
Received: from [85.158.143.35:28389] by server-1.bemta-4.messagelabs.com id
	5E/55-20925-C4DC19F4; Fri, 20 Apr 2012 20:55:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1334955337!12323972!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0MDUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4892 invoked from network); 20 Apr 2012 20:55:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Apr 2012 20:55:39 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3KKicnp000628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Apr 2012 20:55:35 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3KJTcQa010695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2012 19:29:41 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3KJTc5e009568; Fri, 20 Apr 2012 14:29:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 12:29:38 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A5574032D; Fri, 20 Apr 2012 15:24:39 -0400 (EDT)
Date: Fri, 20 Apr 2012 15:24:39 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120420192439.GA32170@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154F3E@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335154F3E@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F91CD48.0026,ss=1,re=1.599,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 01:33:03PM +0000, Liu, Jinsong wrote:
> >From afdd30a7769e706e9be64f80d64136e2e267ecb9 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 20 Apr 2012 05:11:58 +0800
> Subject: [PATCH 3/3] Xen physical cpus interface
> 
> Manage physical cpus in dom0, get physical cpus info and provide sys interface.

Anything that exposes SysFS attributes needs documentation in 
Documentation/ABI

Can you explain what this solves? And if there are any
userland applications that use this?


> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> ---
>  drivers/xen/Makefile             |    1 +
>  drivers/xen/pcpu.c               |  393 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   10 +-
>  include/xen/interface/xen.h      |    1 +
>  4 files changed, 404 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/xen/pcpu.c
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 1d3e763..d12d14d 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o
> +obj-$(CONFIG_XEN_DOM0)			+= pcpu.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> new file mode 100644
> index 0000000..9295def
> --- /dev/null
> +++ b/drivers/xen/pcpu.c
> @@ -0,0 +1,393 @@
> +/******************************************************************************
> + * pcpu.c
> + * Management physical cpu in dom0, get pcpu info and provide sys interface
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <linux/cpu.h>
> +#include <linux/stat.h>
> +#include <xen/xen.h>
> +#include <xen/xenbus.h>
> +#include <xen/events.h>
> +#include <xen/interface/platform.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +struct pcpu {
> +	struct list_head pcpu_list;
> +	struct device dev;
> +	uint32_t xen_id;

What is a 'xen_id'? Can you put a provide a comment
explaining the relationship between that and apic_id acpi_id
and flags?

Or better yet, just at the start of the structure have:

/*
 * @xen_id The ...
 * @apic_id ... so on.


> +	uint32_t apic_id;
> +	uint32_t acpi_id;
> +	uint32_t flags;
> +};
> +
> +static struct bus_type xen_pcpu_subsys = {

> +	.name = "xen_cpu",
> +	.dev_name = "xen_cpu",
> +};
> +
> +static DEFINE_MUTEX(xen_pcpu_lock);
> +#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);

Just use the mutex - no point of using the #define


> +#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
> +
> +#define XEN_PCPU "xen_cpu: "
> +
> +struct xen_pcpus {
> +	struct list_head list;

Uh, so it is just a list? 
> +};
> +static struct xen_pcpus xen_pcpus;

Can't you just do

static struct pcpu * xen_pcpus;

And then use that to add/remove items?

> +
> +static int xen_pcpu_down(uint32_t xen_id)
> +{
> +	int ret;
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_offline,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;

Just collapse it in:
	return HYPERVISOR_dom0_op..

> +}
> +
> +static int xen_pcpu_up(uint32_t xen_id)
> +{
> +	int ret;
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_online,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;

Ditto.

> +}
> +
> +static ssize_t show_online(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
> +}
> +
> +static ssize_t __ref store_online(struct device *dev,
> +				  struct device_attribute *attr,
> +				  const char *buf, size_t count)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +	ssize_t ret;
> +

Add:
	if (!capable(CAP_SYS_ADMIN))
		return -EPERM;


> +	switch (buf[0]) {

Use strict_strtoull pls.

> +	case '0':
> +		ret = xen_pcpu_down(cpu->xen_id);
> +		break;
> +	case '1':
> +		ret = xen_pcpu_up(cpu->xen_id);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	if (ret >= 0)
> +		ret = count;
> +	return ret;
> +}
> +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);

> +
> +static ssize_t show_apicid(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", cpu->apic_id);
> +}
> +
> +static ssize_t show_acpiid(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", cpu->acpi_id);
> +}
> +static DEVICE_ATTR(apic_id, S_IRUGO, show_apicid, NULL);
> +static DEVICE_ATTR(acpi_id, S_IRUGO, show_acpiid, NULL);

What benefit is there in exposing these values to the user?

> +
> +static bool xen_pcpu_online(uint32_t flags)
> +{
> +	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
> +}
> +
> +static void pcpu_online_status(struct xenpf_pcpuinfo *info,
> +			       struct pcpu *pcpu)
> +{
> +	if (xen_pcpu_online(info->flags) &&
> +	   !xen_pcpu_online(pcpu->flags)) {
> +		/* the pcpu is onlined */
> +		pcpu->flags |= XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
> +	} else if (!xen_pcpu_online(info->flags) &&
> +		    xen_pcpu_online(pcpu->flags)) {
> +		/* The pcpu is offlined */
> +		pcpu->flags &= ~XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
> +	}
> +}
> +
> +static struct pcpu *get_pcpu(uint32_t xen_id)
> +{
> +	struct pcpu *pcpu = NULL;
> +
> +	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
> +		if (pcpu->xen_id == xen_id)
> +			return pcpu;
> +	}
> +	return NULL;
> +}
> +
> +static void pcpu_sys_remove(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +
> +	if (!pcpu)
> +		return;
> +
> +	dev = &pcpu->dev;
> +	if (dev->id)
> +		device_remove_file(dev, &dev_attr_online);
> +	device_remove_file(dev, &dev_attr_acpi_id);
> +	device_remove_file(dev, &dev_attr_apic_id);
> +	device_unregister(dev);

So .. if you are using that, can't you use the .release
and define something like:

static void pcpu_release(struct device *dev)
{
	struct pcpu *pcpu = container_of(dev, struct pcpu, dev);

	list_del(&pcpu->pcpu_list);
	kfree(pcpu);
}
> +}
> +
> +static void free_pcpu(struct pcpu *pcpu)
> +{
> +	if (!pcpu)
> +		return;
> +
> +	pcpu_sys_remove(pcpu);

> +	list_del(&pcpu->pcpu_list);
> +	kfree(pcpu);

Those two shouldn't be there. They sould be part of the
release function.
> +}
> +
> +static int pcpu_sys_create(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +	int err = -EINVAL;
> +
> +	if (!pcpu)
> +		return err;
> +
> +	dev = &pcpu->dev;
> +	dev->bus = &xen_pcpu_subsys;
> +	dev->id = pcpu->xen_id;

And then here dev->release = &pcpu_release;

> +
> +	err = device_register(dev);
> +	if (err)
> +		goto err1;
> +
> +	err = device_create_file(dev, &dev_attr_apic_id);
> +	if (err)
> +		goto err2;
> +	err = device_create_file(dev, &dev_attr_acpi_id);
> +	if (err)
> +		goto err3;

Usually this is done with an array, like the drivers/xen/xen-balloon.c
..
But I am still not sure why these two parameters are needed?

> +	/* Not open pcpu0 online access to user */

Huh? You mean "Nobody can touch PCPU0" ?

Why? Why can they touch the other ones? And better yet,
what happens if one boots without "dom0_max_vcpus=X"
and powers of some of the CPUs?

> +	if (dev->id) {
> +		err = device_create_file(dev, &dev_attr_online);
> +		if (err)
> +			goto err4;
> +	}
> +
> +	return 0;
> +
> +err4:
> +	device_remove_file(dev, &dev_attr_acpi_id);
> +err3:
> +	device_remove_file(dev, &dev_attr_apic_id);
> +err2:
> +	device_unregister(dev);
> +err1:
> +	return err;
> +}
> +
> +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
> +{
> +	struct pcpu *pcpu;
> +	int err;
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID)
> +		return ERR_PTR(-ENODEV);
> +
> +	pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL);
> +	if (!pcpu)
> +		return ERR_PTR(-ENOMEM);
> +
> +	INIT_LIST_HEAD(&pcpu->pcpu_list);
> +	pcpu->xen_id = info->xen_cpuid;
> +	pcpu->apic_id = info->apic_id;
> +	pcpu->acpi_id = info->acpi_id;
> +	pcpu->flags = info->flags;
> +
> +	err = pcpu_sys_create(pcpu);
> +	if (err) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu%d\n",

Not %u?
> +			   info->xen_cpuid);
> +		kfree(pcpu);
> +		return ERR_PTR(-ENOENT);
> +	}
> +

Should this be protected by the mutex? [edit: I see now
that the calleer is suppose to hold on the lock.
Mention that please right before you do any list manipulations]


> +	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
> +	return pcpu;
> +}
> +
> +/*
> + * Caller should hold the pcpu lock

Provide full name of the mutex lock.
> + */
> +static int _sync_pcpu(uint32_t cpu_num, uint32_t *ptr_max_cpu_num)

Why the '_' in front of the name?

For parameters do:

uint32 cpu, uint32 *max_cpu

> +{
> +	int ret;
> +	struct pcpu *pcpu = NULL;
> +	struct xenpf_pcpuinfo *info;
> +	struct xen_platform_op op = {
> +		.cmd                   = XENPF_get_cpuinfo,
> +		.interface_version     = XENPF_INTERFACE_VERSION,
> +		.u.pcpu_info.xen_cpuid = cpu_num,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	info = &op.u.pcpu_info;
> +	if (ptr_max_cpu_num)
> +		*ptr_max_cpu_num = info->max_present;
> +
> +	pcpu = get_pcpu(cpu_num);
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
> +		/* The pcpu has been removed */
> +		if (pcpu)
> +			free_pcpu(pcpu);
> +		return 0;
> +	}
> +
> +	if (!pcpu) {
> +		pcpu = init_pcpu(info);
> +		if (IS_ERR_OR_NULL(pcpu))
> +			return -ENODEV;
> +	} else
> +		pcpu_online_status(info, pcpu);
> +
> +	return 0;
> +}
> +
> +/*
> + * Sync dom0's pcpu information with xen hypervisor's
> + */
> +static int xen_sync_pcpus(void)
> +{
> +	/*
> +	 * Boot cpu always have cpu_id 0 in xen
> +	 */
> +	uint32_t cpu_num = 0, max_cpu_num = 0;

Use 'cpu' and 'max_cpu'

> +	int err = 0;
> +	struct list_head *elem, *tmp;
> +	struct pcpu *pcpu;
> +
> +	get_pcpu_lock();
> +
> +	while (!err && (cpu_num <= max_cpu_num)) {
> +		err = _sync_pcpu(cpu_num, &max_cpu_num);
> +		cpu_num++;
> +	}
> +
> +	if (err) {
> +		list_for_each_safe(elem, tmp, &xen_pcpus.list) {

s/elem/pcpu/

> +			pcpu = list_entry(elem, struct pcpu, pcpu_list);

That you can remove once you make the xen_pcpus structure as I mentioned
above.

> +			free_pcpu(pcpu);
> +		}
> +	}
> +
> +	put_pcpu_lock();

Ah, so you are locking around here.
> +
> +	return err;
> +}
> +
> +static void xen_pcpu_dpc(struct work_struct *work)

s/dpc/workqueue/

> +{
> +	xen_sync_pcpus();
> +}
> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
> +
> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_pcpu_init(void)
> +{
> +	int ret;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	ret = subsys_system_register(&xen_pcpu_subsys, NULL);
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
> +		return ret;
> +	}
> +
> +	INIT_LIST_HEAD(&xen_pcpus.list);
> +
> +	ret = xen_sync_pcpus();
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
> +		return ret;
> +	}
> +
> +	ret = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
> +				      xen_pcpu_interrupt, 0,
> +				      "pcpu", NULL);

"xen-pcpu"

> +	if (ret < 0) {
> +		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");

Shouldn't you delete what 'xen_sync_pcpus' did?
Or is it OK to still work without the interrupts? What is the purpose
of that interrupt? How does it actually work - the hypervisor
decides when/where to turn off CPUs?

> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +arch_initcall(xen_pcpu_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 486653f..2c56d4f 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -298,7 +298,7 @@ struct xenpf_set_processor_pminfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
>  
> -#define XENPF_get_cpuinfo 55
> +#define XENPF_get_cpuinfo	55

Why?

>  struct xenpf_pcpuinfo {
>  	/* IN */
>  	uint32_t xen_cpuid;
> @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
>  
> +#define XENPF_cpu_online	56
> +#define XENPF_cpu_offline	57
> +struct xenpf_cpu_ol {
> +	uint32_t cpuid;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -330,6 +337,7 @@ struct xen_platform_op {
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
>  		struct xenpf_pcpuinfo          pcpu_info;
> +		struct xenpf_cpu_ol            cpu_ol;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index a890804..0801468 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -80,6 +80,7 @@
>  #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. */
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> +#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 00:59:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 00:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLOex-0007xP-2X; Sat, 21 Apr 2012 00:58:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SLOev-0007xK-8Z
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 00:58:41 +0000
Received: from [85.158.143.35:34493] by server-3.bemta-4.messagelabs.com id
	6D/E1-05853-046029F4; Sat, 21 Apr 2012 00:58:40 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334969918!13694005!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20108 invoked from network); 21 Apr 2012 00:58:39 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 00:58:39 -0000
Received: by obbtb18 with SMTP id tb18so10820828obb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 17:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=oqjyLfTD1MYlBlay+23rC+Vdc/ycs66Topo/y7YUMyw=;
	b=XG5hU0MdD27hKo2OaiNaDu7LrF0Pf0oyN5sDx/Xko5iWKj9HN2mwFjZa3SxU9HUSEa
	UHgfWFpPRyrYNPjEH/r+bL/rRm//lKHKAgEB2jWO9dNOCjE36Vic0uwMbooK9PniF9qq
	TIbU+lSlNdjkwxbOY5J37ig6J1KZsvjQdtSFE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to
	:x-gm-message-state;
	bh=oqjyLfTD1MYlBlay+23rC+Vdc/ycs66Topo/y7YUMyw=;
	b=asN6C9LF0c/lMFoff06H6GQlSh0fERydZ4CyhDE+SZzxlLDqw2XkFTepS48Gnr1bBD
	TZLF8k1ut1aFkruKgD4u72eokmQDsCTyhS+uWyvVA87zJs7HVSd2KNF5tyuFEoqIrY8Q
	yGvXNObtXiZZaVdsk+J5wk/iVTKmkUV9l8X25eA2wKiqDY+uvbzujpu2G9OIdpgU1o0i
	JmzHFPoqyahdyYAOsDB8yBh0ZmFPYUSoZa65aDMpkln7jO7CFERepalKZDOOuEZNYnsJ
	OxEh9qPVYSE7HAHwijacU9r7tSuJO+QMtPc/dL9AeSck7hQU0oJa+QqyvwORo7l5X/Zf
	X25Q==
Received: by 10.182.44.97 with SMTP id d1mr8203067obm.28.1334969918097;
	Fri, 20 Apr 2012 17:58:38 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-73.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.73])
	by mx.google.com with ESMTPS id d9sm8297227obz.6.2012.04.20.17.58.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Apr 2012 17:58:37 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: babbb3e0f4d3e5aa14cd689095f7526b901c7f68
Message-Id: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Fri, 20 Apr 2012 17:58:22 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQlZe9ORfhUNPAEE8kF8vyhO2JheXP2X6G/0eozpdi5nnZTMqyIyDfJzErAlzLG0Hwv6KxBe
Subject: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Apr 20 11:36:02 2012 -0700
+++ b/xen/arch/x86/domctl.c	Fri Apr 20 17:55:49 2012 -0700
@@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
         c.nat->user_regs.fs = sreg.sel;
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs = sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+            c.nat->gs_base_kernel = sreg.base;
+        else
+            c.nat->gs_base_user = sreg.base;
+#endif
     }
     else
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 00:59:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 00:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLOex-0007xP-2X; Sat, 21 Apr 2012 00:58:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SLOev-0007xK-8Z
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 00:58:41 +0000
Received: from [85.158.143.35:34493] by server-3.bemta-4.messagelabs.com id
	6D/E1-05853-046029F4; Sat, 21 Apr 2012 00:58:40 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1334969918!13694005!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20108 invoked from network); 21 Apr 2012 00:58:39 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 00:58:39 -0000
Received: by obbtb18 with SMTP id tb18so10820828obb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Apr 2012 17:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=oqjyLfTD1MYlBlay+23rC+Vdc/ycs66Topo/y7YUMyw=;
	b=XG5hU0MdD27hKo2OaiNaDu7LrF0Pf0oyN5sDx/Xko5iWKj9HN2mwFjZa3SxU9HUSEa
	UHgfWFpPRyrYNPjEH/r+bL/rRm//lKHKAgEB2jWO9dNOCjE36Vic0uwMbooK9PniF9qq
	TIbU+lSlNdjkwxbOY5J37ig6J1KZsvjQdtSFE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to
	:x-gm-message-state;
	bh=oqjyLfTD1MYlBlay+23rC+Vdc/ycs66Topo/y7YUMyw=;
	b=asN6C9LF0c/lMFoff06H6GQlSh0fERydZ4CyhDE+SZzxlLDqw2XkFTepS48Gnr1bBD
	TZLF8k1ut1aFkruKgD4u72eokmQDsCTyhS+uWyvVA87zJs7HVSd2KNF5tyuFEoqIrY8Q
	yGvXNObtXiZZaVdsk+J5wk/iVTKmkUV9l8X25eA2wKiqDY+uvbzujpu2G9OIdpgU1o0i
	JmzHFPoqyahdyYAOsDB8yBh0ZmFPYUSoZa65aDMpkln7jO7CFERepalKZDOOuEZNYnsJ
	OxEh9qPVYSE7HAHwijacU9r7tSuJO+QMtPc/dL9AeSck7hQU0oJa+QqyvwORo7l5X/Zf
	X25Q==
Received: by 10.182.44.97 with SMTP id d1mr8203067obm.28.1334969918097;
	Fri, 20 Apr 2012 17:58:38 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-73.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.73])
	by mx.google.com with ESMTPS id d9sm8297227obz.6.2012.04.20.17.58.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Apr 2012 17:58:37 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: babbb3e0f4d3e5aa14cd689095f7526b901c7f68
Message-Id: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Fri, 20 Apr 2012 17:58:22 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQlZe9ORfhUNPAEE8kF8vyhO2JheXP2X6G/0eozpdi5nnZTMqyIyDfJzErAlzLG0Hwv6KxBe
Subject: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Apr 20 11:36:02 2012 -0700
+++ b/xen/arch/x86/domctl.c	Fri Apr 20 17:55:49 2012 -0700
@@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
         c.nat->user_regs.fs = sreg.sel;
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs = sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+            c.nat->gs_base_kernel = sreg.base;
+        else
+            c.nat->gs_base_user = sreg.base;
+#endif
     }
     else
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 01:58:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 01:58:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLPZk-0003eM-TG; Sat, 21 Apr 2012 01:57:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLPZj-0003eH-Hn
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 01:57:23 +0000
Received: from [85.158.143.35:28209] by server-1.bemta-4.messagelabs.com id
	3C/DD-20925-204129F4; Sat, 21 Apr 2012 01:57:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334973441!13044089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30968 invoked from network); 21 Apr 2012 01:57:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 01:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,457,1330905600"; d="scan'208";a="12059387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Apr 2012 01:57:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 21 Apr 2012 02:57:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SLPZg-00061z-Tp;
	Sat, 21 Apr 2012 01:57:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SLPZd-00033v-Uk;
	Sat, 21 Apr 2012 02:57:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12733-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Apr 2012 02:57:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12733: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12733 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12733/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 12723
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=274e5accd62d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 274e5accd62d
+ branch=xen-unstable
+ revision=274e5accd62d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 274e5accd62d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 01:58:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 01:58:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLPZk-0003eM-TG; Sat, 21 Apr 2012 01:57:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SLPZj-0003eH-Hn
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 01:57:23 +0000
Received: from [85.158.143.35:28209] by server-1.bemta-4.messagelabs.com id
	3C/DD-20925-204129F4; Sat, 21 Apr 2012 01:57:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1334973441!13044089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30968 invoked from network); 21 Apr 2012 01:57:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 01:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,457,1330905600"; d="scan'208";a="12059387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Apr 2012 01:57:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 21 Apr 2012 02:57:21 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SLPZg-00061z-Tp;
	Sat, 21 Apr 2012 01:57:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SLPZd-00033v-Uk;
	Sat, 21 Apr 2012 02:57:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12733-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Apr 2012 02:57:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12733: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12733 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12733/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 12723
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  7c777cb8f705

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=274e5accd62d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 274e5accd62d
+ branch=xen-unstable
+ revision=274e5accd62d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 274e5accd62d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 04:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 04:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLRo7-0004gz-LO; Sat, 21 Apr 2012 04:20:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLRo6-0004gu-CY
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 04:20:22 +0000
Received: from [85.158.139.83:6560] by server-7.bemta-5.messagelabs.com id
	B2/29-16195-585329F4; Sat, 21 Apr 2012 04:20:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334982018!20945257!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NTM0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13565 invoked from network); 21 Apr 2012 04:20:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Apr 2012 04:20:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3L4JwlA007053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 21 Apr 2012 04:19:59 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3L4JujB019407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 21 Apr 2012 04:19:57 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3L4JtoM021869; Fri, 20 Apr 2012 23:19:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 21:19:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 17C694032D; Sat, 21 Apr 2012 00:14:55 -0400 (EDT)
Date: Sat, 21 Apr 2012 00:14:54 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>, tony.luck@intel.com, bp@amd64.org, 
	x86@kernel.org, linux-edac@vger.kernel.or
Message-ID: <20120421041454.GA29704@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F92356F.007D,ss=1,re=1.599,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 01:29:06PM +0000, Liu, Jinsong wrote:
> >From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 20 Apr 2012 05:08:38 +0800
> Subject: [PATCH 1/3] Add mcelog support for xen platform

Tony and Borislav,

Should this driver reside in arch/x86/kernel/cpu/mcheck?
I can keep it in drivers/xen, but I realized that perhaps it
should be in a different location?
> 
> When MCA error occurs, it would be handled by xen hypervisor first,
> and then the error information would be sent to dom0 for logging.
> 
> This patch gets error information from xen hypervisor and convert
> xen format error into linux format mcelog. This logic is basically
> self-contained, not much touching other kernel components.
> 
> So under xen platform when MCA error occurs, the error information
> would be sent to dom0 and converted into native linux mcelog format.
> By using tools like mcelog tool users could read specific error information,
> like what they did under native linux.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/include/asm/xen/hypercall.h |    8 +
>  arch/x86/xen/enlighten.c             |    4 +-
>  drivers/xen/Kconfig                  |    8 +
>  drivers/xen/Makefile                 |    1 +
>  drivers/xen/mcelog.c                 |  240 ++++++++++++++++++++++++
>  include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++++++
>  6 files changed, 594 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/xen/mcelog.c
>  create mode 100644 include/xen/interface/xen-mca.h
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 5728852..59c226d 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@
>  #include <xen/interface/sched.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/platform.h>
> +#include <xen/interface/xen-mca.h>
>  
>  /*
>   * The hypercall asms have to meet several constraints:
> @@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
>  }
>  
>  static inline int
> +HYPERVISOR_mca(struct xen_mc *mc_op)
> +{
> +	mc_op->interface_version = XEN_MCA_INTERFACE_VERSION;
> +	return _hypercall1(int, mca, mc_op);
> +}
> +
> +static inline int
>  HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
>  {
>  	platform_op->interface_version = XENPF_INTERFACE_VERSION;
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 4f51beb..15628d4 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
>  	unsigned int xsave_mask;
>  
>  	cpuid_leaf1_edx_mask =
> -		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> -		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> -		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 9424313..0f54241 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
>            module will be called xen_acpi_processor  If you do not know what to choose,
>            select M here. If the CPUFREQ drivers are built in, select Y here.
>  
> +config XEN_MCE_LOG
> +	bool "Xen platform mcelog"
> +	depends on XEN_DOM0 && X86_64 && X86_MCE
> +	default n
> +	help
> +	  Allow kernel fetching MCE error from Xen platform and
> +	  converting it into Linux mcelog format for mcelog tools
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 9adc5be..1d3e763 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+= xen-gntdev.o
>  obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+= xen-gntalloc.o
>  obj-$(CONFIG_XENFS)			+= xenfs/
>  obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
> +obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> new file mode 100644
> index 0000000..95ceb5e
> --- /dev/null
> +++ b/drivers/xen/mcelog.c
> @@ -0,0 +1,240 @@
> +/******************************************************************************
> + * mcelog.c
> + * Driver for receiving and transferring machine check error infomation
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + * Author: Ke, Liping <liping.ke@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <asm/mce.h>
> +
> +#include <xen/interface/xen.h>
> +#include <xen/events.h>
> +#include <xen/interface/vcpu.h>
> +#include <xen/xen.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/hypervisor.h>
> +
> +#define XEN_MCELOG "xen_mcelog: "
> +
> +static struct mc_info g_mi;
> +static struct mcinfo_logical_cpu *g_physinfo;
> +static uint32_t ncpus;
> +
> +static DEFINE_SPINLOCK(mcelog_lock);
> +
> +static int convert_log(struct mc_info *mi)
> +{
> +	struct mcinfo_common *mic;
> +	struct mcinfo_global *mc_global;
> +	struct mcinfo_bank *mc_bank;
> +	struct mce m;
> +	uint32_t i;
> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
> +	if (unlikely(!mic)) {
> +		pr_warning(XEN_MCELOG "Failed to find global error info\n");
> +		return -ENODEV;
> +	}
> +
> +	mce_setup(&m);
> +	mc_global = (struct mcinfo_global *)mic;
> +	m.mcgstatus = mc_global->mc_gstatus;
> +	m.apicid = mc_global->mc_apicid;
> +
> +	for (i = 0; i < ncpus; i++)
> +		if (g_physinfo[i].mc_apicid == m.apicid)
> +			break;
> +	if (unlikely(i == ncpus)) {
> +		pr_warning(XEN_MCELOG "Failed to match cpu with apicid %d\n",
> +			   m.apicid);
> +		return -ENODEV;
> +	}
> +
> +	m.socketid = g_physinfo[i].mc_chipid;
> +	m.cpu = m.extcpu = g_physinfo[i].mc_cpunr;
> +	m.cpuvendor = (__u8)g_physinfo[i].mc_vendor;
> +	m.mcgcap = g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
> +	if (unlikely(!mic)) {
> +		pr_warning(XEN_MCELOG "Fail to find bank error info\n");
> +		return -ENODEV;
> +	}
> +
> +	do {
> +		if ((!mic) || (mic->size == 0) ||
> +		    (mic->type != MC_TYPE_GLOBAL   &&
> +		     mic->type != MC_TYPE_BANK     &&
> +		     mic->type != MC_TYPE_EXTENDED &&
> +		     mic->type != MC_TYPE_RECOVERY))
> +			break;
> +
> +		if (mic->type == MC_TYPE_BANK) {
> +			mc_bank = (struct mcinfo_bank *)mic;
> +			m.misc = mc_bank->mc_misc;
> +			m.status = mc_bank->mc_status;
> +			m.addr = mc_bank->mc_addr;
> +			m.tsc = mc_bank->mc_tsc;
> +			m.bank = mc_bank->mc_bank;
> +			m.finished = 1;
> +			/*log this record*/
> +			mce_log(&m);
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	} while (1);
> +
> +	return 0;
> +}
> +
> +static int mc_queue_handle(uint32_t flags)
> +{
> +	struct xen_mc mc_op;
> +	int ret = 0;
> +	unsigned long tmp;
> +
> +	spin_lock_irqsave(&mcelog_lock, tmp);
> +
> +	mc_op.cmd = XEN_MC_fetch;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
> +	do {
> +		mc_op.u.mc_fetch.flags = flags;
> +		ret = HYPERVISOR_mca(&mc_op);
> +		if (ret) {
> +			pr_err(XEN_MCELOG "Failed to fetch %s error log\n",
> +			       (flags == XEN_MC_URGENT) ?
> +			       "urgnet" : "nonurgent");
> +			break;
> +		}
> +
> +		if (mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
> +			break;
> +		else {
> +			ret = convert_log(&g_mi);
> +			if (ret)
> +				pr_warning(XEN_MCELOG
> +					   "Failed to convert this error log, "
> +					   "continue acking it anyway\n");
> +
> +			mc_op.u.mc_fetch.flags = flags | XEN_MC_ACK;
> +			ret = HYPERVISOR_mca(&mc_op);
> +			if (ret) {
> +				pr_err(XEN_MCELOG
> +				       "Failed to ack previous error log\n");
> +				break;
> +			}
> +		}
> +	} while (1);
> +
> +	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +
> +	return ret;
> +}
> +
> +/* virq handler for machine check error info*/
> +static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
> +{
> +	int err;
> +
> +	/* urgent mc_info */
> +	err = mc_queue_handle(XEN_MC_URGENT);
> +	if (err)
> +		pr_err(XEN_MCELOG
> +		       "Failed to handle urgent mc_info queue, "
> +		       "continue handling nonurgent mc_info queue anyway.\n");
> +
> +	/* nonurgent mc_info */
> +	err = mc_queue_handle(XEN_MC_NONURGENT);
> +	if (err)
> +		pr_err(XEN_MCELOG
> +		       "Failed to handle nonurgent mc_info queue.\n");
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int bind_virq_for_mce(void)
> +{
> +	int ret;
> +	struct xen_mc mc_op;
> +
> +	memset(&mc_op, 0, sizeof(struct xen_mc));
> +
> +	/* Fetch physical CPU Numbers */
> +	mc_op.cmd = XEN_MC_physcpuinfo;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		pr_err(XEN_MCELOG "Failed to get CPU numbers\n");
> +		return ret;
> +	}
> +
> +	/* Fetch each CPU Physical Info for later reference*/
> +	ncpus = mc_op.u.mc_physcpuinfo.ncpus;
> +	g_physinfo = kcalloc(ncpus, sizeof(struct mcinfo_logical_cpu),
> +			     GFP_KERNEL);
> +	if (!g_physinfo)
> +		return -ENOMEM;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		pr_err(XEN_MCELOG "Failed to get CPU info\n");
> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	ret  = bind_virq_to_irqhandler(VIRQ_MCA, 0,
> +				       xen_mce_interrupt, 0, "mce", NULL);
> +	if (ret < 0) {
> +		pr_err(XEN_MCELOG "Failed to bind virq\n");
> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init mcelog_init(void)
> +{
> +	/* Only DOM0 is responsible for MCE logging */
> +	if (xen_initial_domain())
> +		return bind_virq_for_mce();
> +
> +	return -ENODEV;
> +}
> +late_initcall(mcelog_init);
> diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mca.h
> new file mode 100644
> index 0000000..f2561db
> --- /dev/null
> +++ b/include/xen/interface/xen-mca.h
> @@ -0,0 +1,336 @@
> +/******************************************************************************
> + * arch-x86/mca.h
> + * Guest OS machine check interface to x86 Xen.
> + *
> + * Contributed by Advanced Micro Devices, Inc.
> + * Author: Christoph Egger <Christoph.Egger@amd.com>
> + *
> + * Updated by Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
> +#define __XEN_PUBLIC_ARCH_X86_MCA_H__
> +
> +/* Hypercall */
> +#define __HYPERVISOR_mca __HYPERVISOR_arch_0
> +
> +#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
> +
> +/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
> +#define XEN_MC_NONURGENT	0x1
> +/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
> +#define XEN_MC_URGENT		0x2
> +/* IN: Dom0 acknowledges previosly-fetched error log entry */
> +#define XEN_MC_ACK		0x4
> +
> +/* OUT: All is ok */
> +#define XEN_MC_OK		0x0
> +/* OUT: Domain could not fetch data. */
> +#define XEN_MC_FETCHFAILED	0x1
> +/* OUT: There was no machine check data to fetch. */
> +#define XEN_MC_NODATA		0x2
> +
> +#ifndef __ASSEMBLY__
> +/* vIRQ injected to Dom0 */
> +#define VIRQ_MCA VIRQ_ARCH_0
> +
> +/*
> + * mc_info entry types
> + * mca machine check info are recorded in mc_info entries.
> + * when fetch mca info, it can use MC_TYPE_... to distinguish
> + * different mca info.
> + */
> +#define MC_TYPE_GLOBAL		0
> +#define MC_TYPE_BANK		1
> +#define MC_TYPE_EXTENDED	2
> +#define MC_TYPE_RECOVERY	3
> +
> +struct mcinfo_common {
> +	uint16_t type; /* structure type */
> +	uint16_t size; /* size of this struct in bytes */
> +};
> +
> +#define MC_FLAG_CORRECTABLE	(1 << 0)
> +#define MC_FLAG_UNCORRECTABLE	(1 << 1)
> +#define MC_FLAG_RECOVERABLE	(1 << 2)
> +#define MC_FLAG_POLLED		(1 << 3)
> +#define MC_FLAG_RESET		(1 << 4)
> +#define MC_FLAG_CMCI		(1 << 5)
> +#define MC_FLAG_MCE		(1 << 6)
> +
> +/* contains x86 global mc information */
> +struct mcinfo_global {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_domid; /* running domain at the time in error */
> +	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
> +	uint32_t mc_socketid; /* physical socket of the physical core */
> +	uint16_t mc_coreid; /* physical impacted core */
> +	uint16_t mc_core_threadid; /* core thread of physical core */
> +	uint32_t mc_apicid;
> +	uint32_t mc_flags;
> +	uint64_t mc_gstatus; /* global status */
> +};
> +
> +/* contains x86 bank mc information */
> +struct mcinfo_bank {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_bank; /* bank nr */
> +	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
> +	uint64_t mc_status; /* bank status */
> +	uint64_t mc_addr; /* bank address */
> +	uint64_t mc_misc;
> +	uint64_t mc_ctrl2;
> +	uint64_t mc_tsc;
> +};
> +
> +struct mcinfo_msr {
> +	uint64_t reg; /* MSR */
> +	uint64_t value; /* MSR value */
> +};
> +
> +/* contains mc information from other or additional mc MSRs */
> +struct mcinfo_extended {
> +	struct mcinfo_common common;
> +	uint32_t mc_msrs; /* Number of msr with valid values. */
> +	/*
> +	 * Currently Intel extended MSR (32/64) include all gp registers
> +	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
> +	 * useful at present. So expand this array to 16/32 to leave room.
> +	 */
> +	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
> +};
> +
> +/* Recovery Action flags. Giving recovery result information to DOM0 */
> +
> +/* Xen takes successful recovery action, the error is recovered */
> +#define REC_ACTION_RECOVERED (0x1 << 0)
> +/* No action is performed by XEN */
> +#define REC_ACTION_NONE (0x1 << 1)
> +/* It's possible DOM0 might take action ownership in some case */
> +#define REC_ACTION_NEED_RESET (0x1 << 2)
> +
> +/*
> + * Different Recovery Action types, if the action is performed successfully,
> + * REC_ACTION_RECOVERED flag will be returned.
> + */
> +
> +/* Page Offline Action */
> +#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
> +/* CPU offline Action */
> +#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
> +/* L3 cache disable Action */
> +#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
> +
> +/*
> + * Below interface used between XEN/DOM0 for passing XEN's recovery action
> + * information to DOM0.
> + */
> +struct page_offline_action {
> +	/* Params for passing the offlined page number to DOM0 */
> +	uint64_t mfn;
> +	uint64_t status;
> +};
> +
> +struct cpu_offline_action {
> +	/* Params for passing the identity of the offlined CPU to DOM0 */
> +	uint32_t mc_socketid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_core_threadid;
> +};
> +
> +#define MAX_UNION_SIZE 16
> +struct mcinfo_recovery {
> +	struct mcinfo_common common;
> +	uint16_t mc_bank; /* bank nr */
> +	uint8_t action_flags;
> +	uint8_t action_types;
> +	union {
> +		struct page_offline_action page_retire;
> +		struct cpu_offline_action cpu_offline;
> +		uint8_t pad[MAX_UNION_SIZE];
> +	} action_info;
> +};
> +
> +
> +#define MCINFO_MAXSIZE 768
> +struct mc_info {
> +	/* Number of mcinfo_* entries in mi_data */
> +	uint32_t mi_nentries;
> +	uint32_t flags;
> +	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mc_info);
> +
> +#define __MC_MSR_ARRAYSIZE 8
> +#define __MC_MSR_MCGCAP 0
> +#define __MC_NMSRS 1
> +#define MC_NCAPS 7
> +struct mcinfo_logical_cpu {
> +	uint32_t mc_cpunr;
> +	uint32_t mc_chipid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_threadid;
> +	uint32_t mc_apicid;
> +	uint32_t mc_clusterid;
> +	uint32_t mc_ncores;
> +	uint32_t mc_ncores_active;
> +	uint32_t mc_nthreads;
> +	uint32_t mc_cpuid_level;
> +	uint32_t mc_family;
> +	uint32_t mc_vendor;
> +	uint32_t mc_model;
> +	uint32_t mc_step;
> +	char mc_vendorid[16];
> +	char mc_brandid[64];
> +	uint32_t mc_cpu_caps[MC_NCAPS];
> +	uint32_t mc_cache_size;
> +	uint32_t mc_cache_alignment;
> +	uint32_t mc_nmsrvals;
> +	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
> +
> +/*
> + * Prototype:
> + *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
> + */
> +#define x86_mcinfo_nentries(_mi)    \
> +	((_mi)->mi_nentries)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
> + */
> +#define x86_mcinfo_first(_mi)       \
> +	((struct mcinfo_common *)(_mi)->mi_data)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
> + */
> +#define x86_mcinfo_next(_mic)       \
> +	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
> +
> +/*
> + * Prototype:
> + *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type);
> + */
> +static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
> +				     struct mc_info *mi, uint16_t type)
> +{
> +	uint32_t i;
> +	struct mcinfo_common *mic;
> +	bool found = 0;
> +
> +	if (!ret || !mi)
> +		return;
> +
> +	mic = x86_mcinfo_first(mi);
> +	for (i = 0; i < x86_mcinfo_nentries(mi); i++) {
> +		if (mic->type == type) {
> +			found = 1;
> +			break;
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	}
> +
> +	*ret = found ? mic : NULL;
> +}
> +
> +/*
> + * Fetch machine check data from hypervisor.
> + */
> +#define XEN_MC_fetch		1
> +struct xen_mc_fetch {
> +	/*
> +	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
> +	 * XEN_MC_ACK if ack'king an earlier fetch
> +	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
> +	 */
> +	uint32_t flags;
> +	uint32_t _pad0;
> +	/* OUT: id for ack, IN: id we are ack'ing */
> +	uint64_t fetch_id;
> +
> +	/* OUT variables. */
> +	GUEST_HANDLE(mc_info) data;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
> +
> +
> +/*
> + * This tells the hypervisor to notify a DomU about the machine check error
> + */
> +#define XEN_MC_notifydomain	2
> +struct xen_mc_notifydomain {
> +	/* IN variables */
> +	uint16_t mc_domid; /* The unprivileged domain to notify */
> +	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
> +
> +	/* IN/OUT variables */
> +	uint32_t flags;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
> +
> +#define XEN_MC_physcpuinfo	3
> +struct xen_mc_physcpuinfo {
> +	/* IN/OUT */
> +	uint32_t ncpus;
> +	uint32_t _pad0;
> +	/* OUT */
> +	GUEST_HANDLE(mcinfo_logical_cpu) info;
> +};
> +
> +#define XEN_MC_msrinject	4
> +#define MC_MSRINJ_MAXMSRS	8
> +struct xen_mc_msrinject {
> +	/* IN */
> +	uint32_t mcinj_cpunr; /* target processor id */
> +	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
> +	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
> +	uint32_t _pad0;
> +	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
> +};
> +
> +/* Flags for mcinj_flags above; bits 16-31 are reserved */
> +#define MC_MSRINJ_F_INTERPOSE	0x1
> +
> +#define XEN_MC_mceinject	5
> +struct xen_mc_mceinject {
> +	unsigned int mceinj_cpunr; /* target processor id */
> +};
> +
> +struct xen_mc {
> +	uint32_t cmd;
> +	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
> +	union {
> +		struct xen_mc_fetch        mc_fetch;
> +		struct xen_mc_notifydomain mc_notifydomain;
> +		struct xen_mc_physcpuinfo  mc_physcpuinfo;
> +		struct xen_mc_msrinject    mc_msrinject;
> +		struct xen_mc_mceinject    mc_mceinject;
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
> -- 
> 1.7.1


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 04:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 04:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLRo7-0004gz-LO; Sat, 21 Apr 2012 04:20:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SLRo6-0004gu-CY
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 04:20:22 +0000
Received: from [85.158.139.83:6560] by server-7.bemta-5.messagelabs.com id
	B2/29-16195-585329F4; Sat, 21 Apr 2012 04:20:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1334982018!20945257!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NTM0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13565 invoked from network); 21 Apr 2012 04:20:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Apr 2012 04:20:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3L4JwlA007053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 21 Apr 2012 04:19:59 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3L4JujB019407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 21 Apr 2012 04:19:57 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3L4JtoM021869; Fri, 20 Apr 2012 23:19:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Apr 2012 21:19:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 17C694032D; Sat, 21 Apr 2012 00:14:55 -0400 (EDT)
Date: Sat, 21 Apr 2012 00:14:54 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>, tony.luck@intel.com, bp@amd64.org, 
	x86@kernel.org, linux-edac@vger.kernel.or
Message-ID: <20120421041454.GA29704@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F92356F.007D,ss=1,re=1.599,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 19, 2012 at 01:29:06PM +0000, Liu, Jinsong wrote:
> >From af4467b6cf0104ce98cc160438d865256c7d5561 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 20 Apr 2012 05:08:38 +0800
> Subject: [PATCH 1/3] Add mcelog support for xen platform

Tony and Borislav,

Should this driver reside in arch/x86/kernel/cpu/mcheck?
I can keep it in drivers/xen, but I realized that perhaps it
should be in a different location?
> 
> When MCA error occurs, it would be handled by xen hypervisor first,
> and then the error information would be sent to dom0 for logging.
> 
> This patch gets error information from xen hypervisor and convert
> xen format error into linux format mcelog. This logic is basically
> self-contained, not much touching other kernel components.
> 
> So under xen platform when MCA error occurs, the error information
> would be sent to dom0 and converted into native linux mcelog format.
> By using tools like mcelog tool users could read specific error information,
> like what they did under native linux.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/include/asm/xen/hypercall.h |    8 +
>  arch/x86/xen/enlighten.c             |    4 +-
>  drivers/xen/Kconfig                  |    8 +
>  drivers/xen/Makefile                 |    1 +
>  drivers/xen/mcelog.c                 |  240 ++++++++++++++++++++++++
>  include/xen/interface/xen-mca.h      |  336 ++++++++++++++++++++++++++++++++++
>  6 files changed, 594 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/xen/mcelog.c
>  create mode 100644 include/xen/interface/xen-mca.h
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 5728852..59c226d 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@
>  #include <xen/interface/sched.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/platform.h>
> +#include <xen/interface/xen-mca.h>
>  
>  /*
>   * The hypercall asms have to meet several constraints:
> @@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
>  }
>  
>  static inline int
> +HYPERVISOR_mca(struct xen_mc *mc_op)
> +{
> +	mc_op->interface_version = XEN_MCA_INTERFACE_VERSION;
> +	return _hypercall1(int, mca, mc_op);
> +}
> +
> +static inline int
>  HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
>  {
>  	platform_op->interface_version = XENPF_INTERFACE_VERSION;
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 4f51beb..15628d4 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -329,9 +329,7 @@ static void __init xen_init_cpuid_mask(void)
>  	unsigned int xsave_mask;
>  
>  	cpuid_leaf1_edx_mask =
> -		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> -		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> -		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 9424313..0f54241 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -194,4 +194,12 @@ config XEN_ACPI_PROCESSOR
>            module will be called xen_acpi_processor  If you do not know what to choose,
>            select M here. If the CPUFREQ drivers are built in, select Y here.
>  
> +config XEN_MCE_LOG
> +	bool "Xen platform mcelog"
> +	depends on XEN_DOM0 && X86_64 && X86_MCE
> +	default n
> +	help
> +	  Allow kernel fetching MCE error from Xen platform and
> +	  converting it into Linux mcelog format for mcelog tools
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 9adc5be..1d3e763 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+= xen-gntdev.o
>  obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+= xen-gntalloc.o
>  obj-$(CONFIG_XENFS)			+= xenfs/
>  obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
> +obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> new file mode 100644
> index 0000000..95ceb5e
> --- /dev/null
> +++ b/drivers/xen/mcelog.c
> @@ -0,0 +1,240 @@
> +/******************************************************************************
> + * mcelog.c
> + * Driver for receiving and transferring machine check error infomation
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + * Author: Ke, Liping <liping.ke@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <asm/mce.h>
> +
> +#include <xen/interface/xen.h>
> +#include <xen/events.h>
> +#include <xen/interface/vcpu.h>
> +#include <xen/xen.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/hypervisor.h>
> +
> +#define XEN_MCELOG "xen_mcelog: "
> +
> +static struct mc_info g_mi;
> +static struct mcinfo_logical_cpu *g_physinfo;
> +static uint32_t ncpus;
> +
> +static DEFINE_SPINLOCK(mcelog_lock);
> +
> +static int convert_log(struct mc_info *mi)
> +{
> +	struct mcinfo_common *mic;
> +	struct mcinfo_global *mc_global;
> +	struct mcinfo_bank *mc_bank;
> +	struct mce m;
> +	uint32_t i;
> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
> +	if (unlikely(!mic)) {
> +		pr_warning(XEN_MCELOG "Failed to find global error info\n");
> +		return -ENODEV;
> +	}
> +
> +	mce_setup(&m);
> +	mc_global = (struct mcinfo_global *)mic;
> +	m.mcgstatus = mc_global->mc_gstatus;
> +	m.apicid = mc_global->mc_apicid;
> +
> +	for (i = 0; i < ncpus; i++)
> +		if (g_physinfo[i].mc_apicid == m.apicid)
> +			break;
> +	if (unlikely(i == ncpus)) {
> +		pr_warning(XEN_MCELOG "Failed to match cpu with apicid %d\n",
> +			   m.apicid);
> +		return -ENODEV;
> +	}
> +
> +	m.socketid = g_physinfo[i].mc_chipid;
> +	m.cpu = m.extcpu = g_physinfo[i].mc_cpunr;
> +	m.cpuvendor = (__u8)g_physinfo[i].mc_vendor;
> +	m.mcgcap = g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
> +
> +	mic = NULL;
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
> +	if (unlikely(!mic)) {
> +		pr_warning(XEN_MCELOG "Fail to find bank error info\n");
> +		return -ENODEV;
> +	}
> +
> +	do {
> +		if ((!mic) || (mic->size == 0) ||
> +		    (mic->type != MC_TYPE_GLOBAL   &&
> +		     mic->type != MC_TYPE_BANK     &&
> +		     mic->type != MC_TYPE_EXTENDED &&
> +		     mic->type != MC_TYPE_RECOVERY))
> +			break;
> +
> +		if (mic->type == MC_TYPE_BANK) {
> +			mc_bank = (struct mcinfo_bank *)mic;
> +			m.misc = mc_bank->mc_misc;
> +			m.status = mc_bank->mc_status;
> +			m.addr = mc_bank->mc_addr;
> +			m.tsc = mc_bank->mc_tsc;
> +			m.bank = mc_bank->mc_bank;
> +			m.finished = 1;
> +			/*log this record*/
> +			mce_log(&m);
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	} while (1);
> +
> +	return 0;
> +}
> +
> +static int mc_queue_handle(uint32_t flags)
> +{
> +	struct xen_mc mc_op;
> +	int ret = 0;
> +	unsigned long tmp;
> +
> +	spin_lock_irqsave(&mcelog_lock, tmp);
> +
> +	mc_op.cmd = XEN_MC_fetch;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_fetch.data, &g_mi);
> +	do {
> +		mc_op.u.mc_fetch.flags = flags;
> +		ret = HYPERVISOR_mca(&mc_op);
> +		if (ret) {
> +			pr_err(XEN_MCELOG "Failed to fetch %s error log\n",
> +			       (flags == XEN_MC_URGENT) ?
> +			       "urgnet" : "nonurgent");
> +			break;
> +		}
> +
> +		if (mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +		    mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
> +			break;
> +		else {
> +			ret = convert_log(&g_mi);
> +			if (ret)
> +				pr_warning(XEN_MCELOG
> +					   "Failed to convert this error log, "
> +					   "continue acking it anyway\n");
> +
> +			mc_op.u.mc_fetch.flags = flags | XEN_MC_ACK;
> +			ret = HYPERVISOR_mca(&mc_op);
> +			if (ret) {
> +				pr_err(XEN_MCELOG
> +				       "Failed to ack previous error log\n");
> +				break;
> +			}
> +		}
> +	} while (1);
> +
> +	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +
> +	return ret;
> +}
> +
> +/* virq handler for machine check error info*/
> +static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
> +{
> +	int err;
> +
> +	/* urgent mc_info */
> +	err = mc_queue_handle(XEN_MC_URGENT);
> +	if (err)
> +		pr_err(XEN_MCELOG
> +		       "Failed to handle urgent mc_info queue, "
> +		       "continue handling nonurgent mc_info queue anyway.\n");
> +
> +	/* nonurgent mc_info */
> +	err = mc_queue_handle(XEN_MC_NONURGENT);
> +	if (err)
> +		pr_err(XEN_MCELOG
> +		       "Failed to handle nonurgent mc_info queue.\n");
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int bind_virq_for_mce(void)
> +{
> +	int ret;
> +	struct xen_mc mc_op;
> +
> +	memset(&mc_op, 0, sizeof(struct xen_mc));
> +
> +	/* Fetch physical CPU Numbers */
> +	mc_op.cmd = XEN_MC_physcpuinfo;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		pr_err(XEN_MCELOG "Failed to get CPU numbers\n");
> +		return ret;
> +	}
> +
> +	/* Fetch each CPU Physical Info for later reference*/
> +	ncpus = mc_op.u.mc_physcpuinfo.ncpus;
> +	g_physinfo = kcalloc(ncpus, sizeof(struct mcinfo_logical_cpu),
> +			     GFP_KERNEL);
> +	if (!g_physinfo)
> +		return -ENOMEM;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		pr_err(XEN_MCELOG "Failed to get CPU info\n");
> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	ret  = bind_virq_to_irqhandler(VIRQ_MCA, 0,
> +				       xen_mce_interrupt, 0, "mce", NULL);
> +	if (ret < 0) {
> +		pr_err(XEN_MCELOG "Failed to bind virq\n");
> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init mcelog_init(void)
> +{
> +	/* Only DOM0 is responsible for MCE logging */
> +	if (xen_initial_domain())
> +		return bind_virq_for_mce();
> +
> +	return -ENODEV;
> +}
> +late_initcall(mcelog_init);
> diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mca.h
> new file mode 100644
> index 0000000..f2561db
> --- /dev/null
> +++ b/include/xen/interface/xen-mca.h
> @@ -0,0 +1,336 @@
> +/******************************************************************************
> + * arch-x86/mca.h
> + * Guest OS machine check interface to x86 Xen.
> + *
> + * Contributed by Advanced Micro Devices, Inc.
> + * Author: Christoph Egger <Christoph.Egger@amd.com>
> + *
> + * Updated by Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
> +#define __XEN_PUBLIC_ARCH_X86_MCA_H__
> +
> +/* Hypercall */
> +#define __HYPERVISOR_mca __HYPERVISOR_arch_0
> +
> +#define XEN_MCA_INTERFACE_VERSION	0x01ecc003
> +
> +/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
> +#define XEN_MC_NONURGENT	0x1
> +/* IN: Dom0 calls hypercall to retrieve urgent error log entry */
> +#define XEN_MC_URGENT		0x2
> +/* IN: Dom0 acknowledges previosly-fetched error log entry */
> +#define XEN_MC_ACK		0x4
> +
> +/* OUT: All is ok */
> +#define XEN_MC_OK		0x0
> +/* OUT: Domain could not fetch data. */
> +#define XEN_MC_FETCHFAILED	0x1
> +/* OUT: There was no machine check data to fetch. */
> +#define XEN_MC_NODATA		0x2
> +
> +#ifndef __ASSEMBLY__
> +/* vIRQ injected to Dom0 */
> +#define VIRQ_MCA VIRQ_ARCH_0
> +
> +/*
> + * mc_info entry types
> + * mca machine check info are recorded in mc_info entries.
> + * when fetch mca info, it can use MC_TYPE_... to distinguish
> + * different mca info.
> + */
> +#define MC_TYPE_GLOBAL		0
> +#define MC_TYPE_BANK		1
> +#define MC_TYPE_EXTENDED	2
> +#define MC_TYPE_RECOVERY	3
> +
> +struct mcinfo_common {
> +	uint16_t type; /* structure type */
> +	uint16_t size; /* size of this struct in bytes */
> +};
> +
> +#define MC_FLAG_CORRECTABLE	(1 << 0)
> +#define MC_FLAG_UNCORRECTABLE	(1 << 1)
> +#define MC_FLAG_RECOVERABLE	(1 << 2)
> +#define MC_FLAG_POLLED		(1 << 3)
> +#define MC_FLAG_RESET		(1 << 4)
> +#define MC_FLAG_CMCI		(1 << 5)
> +#define MC_FLAG_MCE		(1 << 6)
> +
> +/* contains x86 global mc information */
> +struct mcinfo_global {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_domid; /* running domain at the time in error */
> +	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
> +	uint32_t mc_socketid; /* physical socket of the physical core */
> +	uint16_t mc_coreid; /* physical impacted core */
> +	uint16_t mc_core_threadid; /* core thread of physical core */
> +	uint32_t mc_apicid;
> +	uint32_t mc_flags;
> +	uint64_t mc_gstatus; /* global status */
> +};
> +
> +/* contains x86 bank mc information */
> +struct mcinfo_bank {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_bank; /* bank nr */
> +	uint16_t mc_domid; /* domain referenced by mc_addr if valid */
> +	uint64_t mc_status; /* bank status */
> +	uint64_t mc_addr; /* bank address */
> +	uint64_t mc_misc;
> +	uint64_t mc_ctrl2;
> +	uint64_t mc_tsc;
> +};
> +
> +struct mcinfo_msr {
> +	uint64_t reg; /* MSR */
> +	uint64_t value; /* MSR value */
> +};
> +
> +/* contains mc information from other or additional mc MSRs */
> +struct mcinfo_extended {
> +	struct mcinfo_common common;
> +	uint32_t mc_msrs; /* Number of msr with valid values. */
> +	/*
> +	 * Currently Intel extended MSR (32/64) include all gp registers
> +	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
> +	 * useful at present. So expand this array to 16/32 to leave room.
> +	 */
> +	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
> +};
> +
> +/* Recovery Action flags. Giving recovery result information to DOM0 */
> +
> +/* Xen takes successful recovery action, the error is recovered */
> +#define REC_ACTION_RECOVERED (0x1 << 0)
> +/* No action is performed by XEN */
> +#define REC_ACTION_NONE (0x1 << 1)
> +/* It's possible DOM0 might take action ownership in some case */
> +#define REC_ACTION_NEED_RESET (0x1 << 2)
> +
> +/*
> + * Different Recovery Action types, if the action is performed successfully,
> + * REC_ACTION_RECOVERED flag will be returned.
> + */
> +
> +/* Page Offline Action */
> +#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
> +/* CPU offline Action */
> +#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
> +/* L3 cache disable Action */
> +#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
> +
> +/*
> + * Below interface used between XEN/DOM0 for passing XEN's recovery action
> + * information to DOM0.
> + */
> +struct page_offline_action {
> +	/* Params for passing the offlined page number to DOM0 */
> +	uint64_t mfn;
> +	uint64_t status;
> +};
> +
> +struct cpu_offline_action {
> +	/* Params for passing the identity of the offlined CPU to DOM0 */
> +	uint32_t mc_socketid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_core_threadid;
> +};
> +
> +#define MAX_UNION_SIZE 16
> +struct mcinfo_recovery {
> +	struct mcinfo_common common;
> +	uint16_t mc_bank; /* bank nr */
> +	uint8_t action_flags;
> +	uint8_t action_types;
> +	union {
> +		struct page_offline_action page_retire;
> +		struct cpu_offline_action cpu_offline;
> +		uint8_t pad[MAX_UNION_SIZE];
> +	} action_info;
> +};
> +
> +
> +#define MCINFO_MAXSIZE 768
> +struct mc_info {
> +	/* Number of mcinfo_* entries in mi_data */
> +	uint32_t mi_nentries;
> +	uint32_t flags;
> +	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mc_info);
> +
> +#define __MC_MSR_ARRAYSIZE 8
> +#define __MC_MSR_MCGCAP 0
> +#define __MC_NMSRS 1
> +#define MC_NCAPS 7
> +struct mcinfo_logical_cpu {
> +	uint32_t mc_cpunr;
> +	uint32_t mc_chipid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_threadid;
> +	uint32_t mc_apicid;
> +	uint32_t mc_clusterid;
> +	uint32_t mc_ncores;
> +	uint32_t mc_ncores_active;
> +	uint32_t mc_nthreads;
> +	uint32_t mc_cpuid_level;
> +	uint32_t mc_family;
> +	uint32_t mc_vendor;
> +	uint32_t mc_model;
> +	uint32_t mc_step;
> +	char mc_vendorid[16];
> +	char mc_brandid[64];
> +	uint32_t mc_cpu_caps[MC_NCAPS];
> +	uint32_t mc_cache_size;
> +	uint32_t mc_cache_alignment;
> +	uint32_t mc_nmsrvals;
> +	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
> +
> +/*
> + * Prototype:
> + *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
> + */
> +#define x86_mcinfo_nentries(_mi)    \
> +	((_mi)->mi_nentries)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
> + */
> +#define x86_mcinfo_first(_mi)       \
> +	((struct mcinfo_common *)(_mi)->mi_data)
> +/*
> + * Prototype:
> + *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
> + */
> +#define x86_mcinfo_next(_mic)       \
> +	((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
> +
> +/*
> + * Prototype:
> + *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type);
> + */
> +static inline void x86_mcinfo_lookup(struct mcinfo_common **ret,
> +				     struct mc_info *mi, uint16_t type)
> +{
> +	uint32_t i;
> +	struct mcinfo_common *mic;
> +	bool found = 0;
> +
> +	if (!ret || !mi)
> +		return;
> +
> +	mic = x86_mcinfo_first(mi);
> +	for (i = 0; i < x86_mcinfo_nentries(mi); i++) {
> +		if (mic->type == type) {
> +			found = 1;
> +			break;
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	}
> +
> +	*ret = found ? mic : NULL;
> +}
> +
> +/*
> + * Fetch machine check data from hypervisor.
> + */
> +#define XEN_MC_fetch		1
> +struct xen_mc_fetch {
> +	/*
> +	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
> +	 * XEN_MC_ACK if ack'king an earlier fetch
> +	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED, XEN_MC_NODATA
> +	 */
> +	uint32_t flags;
> +	uint32_t _pad0;
> +	/* OUT: id for ack, IN: id we are ack'ing */
> +	uint64_t fetch_id;
> +
> +	/* OUT variables. */
> +	GUEST_HANDLE(mc_info) data;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
> +
> +
> +/*
> + * This tells the hypervisor to notify a DomU about the machine check error
> + */
> +#define XEN_MC_notifydomain	2
> +struct xen_mc_notifydomain {
> +	/* IN variables */
> +	uint16_t mc_domid; /* The unprivileged domain to notify */
> +	uint16_t mc_vcpuid; /* The vcpu in mc_domid to notify */
> +
> +	/* IN/OUT variables */
> +	uint32_t flags;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
> +
> +#define XEN_MC_physcpuinfo	3
> +struct xen_mc_physcpuinfo {
> +	/* IN/OUT */
> +	uint32_t ncpus;
> +	uint32_t _pad0;
> +	/* OUT */
> +	GUEST_HANDLE(mcinfo_logical_cpu) info;
> +};
> +
> +#define XEN_MC_msrinject	4
> +#define MC_MSRINJ_MAXMSRS	8
> +struct xen_mc_msrinject {
> +	/* IN */
> +	uint32_t mcinj_cpunr; /* target processor id */
> +	uint32_t mcinj_flags; /* see MC_MSRINJ_F_* below */
> +	uint32_t mcinj_count; /* 0 .. count-1 in array are valid */
> +	uint32_t _pad0;
> +	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
> +};
> +
> +/* Flags for mcinj_flags above; bits 16-31 are reserved */
> +#define MC_MSRINJ_F_INTERPOSE	0x1
> +
> +#define XEN_MC_mceinject	5
> +struct xen_mc_mceinject {
> +	unsigned int mceinj_cpunr; /* target processor id */
> +};
> +
> +struct xen_mc {
> +	uint32_t cmd;
> +	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
> +	union {
> +		struct xen_mc_fetch        mc_fetch;
> +		struct xen_mc_notifydomain mc_notifydomain;
> +		struct xen_mc_physcpuinfo  mc_physcpuinfo;
> +		struct xen_mc_msrinject    mc_msrinject;
> +		struct xen_mc_mceinject    mc_mceinject;
> +	} u;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
> -- 
> 1.7.1


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 08:31:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 08:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLVir-0006cg-N9; Sat, 21 Apr 2012 08:31:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLVir-0006cY-0Y
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 08:31:13 +0000
Received: from [85.158.139.83:47863] by server-7.bemta-5.messagelabs.com id
	AC/9C-16195-050729F4; Sat, 21 Apr 2012 08:31:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334997071!20892160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTU3OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23885 invoked from network); 21 Apr 2012 08:31:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 08:31:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,459,1330905600"; d="scan'208";a="12060768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Apr 2012 08:31:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 21 Apr 2012 09:31:10 +0100
Message-ID: <1334997070.3900.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Date: Sat, 21 Apr 2012 09:31:10 +0100
In-Reply-To: <e62ab14d44afb1781a36.1334947081@vollum>
References: <e62ab14d44afb1781a36.1334947081@vollum>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v2] libxc: Replace alloca() with mmap()
 for pfn array sizes greater than a page in linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 19:38 +0100, Aravindh Puthiyaparambil wrote:
> When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.
> 
> Fix an error print with the correct function name.
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

Thanks. Did you rule out this bug at the  usage of alloca() in
linux_gnttab_grant_map? If not then I think that should be changed too.

> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 7c777cb8f705 -r e62ab14d44af tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/tools/libxc/xc_linux_osdep.c	Fri Apr 20 11:36:02 2012 -0700
> @@ -39,6 +39,7 @@
>  #include "xenctrl.h"
>  #include "xenctrlosdep.h"
>  
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
>  #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>  #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> @@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
>                  fd, 0);
>      if ( addr == MAP_FAILED )
>      {
> -        PERROR("xc_map_foreign_batch: mmap failed");
> +        PERROR("xc_map_foreign_bulk: mmap failed");
>          return NULL;
>      }
>  
> @@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
>          privcmd_mmapbatch_t ioctlx;
> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> +        xen_pfn_t *pfn;
> +        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
> +
> +        if ( pfn_arr_size <= XC_PAGE_SIZE )
> +            pfn = alloca(num * sizeof(*pfn));
> +        else
> +        {
> +            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
> +                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +            if ( pfn == MAP_FAILED )
> +            {
> +                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> +                return NULL;
> +            }
> +        }
>  
>          memcpy(pfn, arr, num * sizeof(*arr));
>  
> @@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
>              break;
>          }
>  
> +        if ( pfn_arr_size > XC_PAGE_SIZE )
> +            munmap(pfn, pfn_arr_size);
> +
>          if ( rc == -ENOENT && i == num )
>              rc = 0;
>          else if ( rc )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 08:31:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 08:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLVir-0006cg-N9; Sat, 21 Apr 2012 08:31:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLVir-0006cY-0Y
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 08:31:13 +0000
Received: from [85.158.139.83:47863] by server-7.bemta-5.messagelabs.com id
	AC/9C-16195-050729F4; Sat, 21 Apr 2012 08:31:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1334997071!20892160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTU3OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23885 invoked from network); 21 Apr 2012 08:31:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 08:31:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,459,1330905600"; d="scan'208";a="12060768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Apr 2012 08:31:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 21 Apr 2012 09:31:10 +0100
Message-ID: <1334997070.3900.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Date: Sat, 21 Apr 2012 09:31:10 +0100
In-Reply-To: <e62ab14d44afb1781a36.1334947081@vollum>
References: <e62ab14d44afb1781a36.1334947081@vollum>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v2] libxc: Replace alloca() with mmap()
 for pfn array sizes greater than a page in linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 19:38 +0100, Aravindh Puthiyaparambil wrote:
> When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.
> 
> Fix an error print with the correct function name.
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

Thanks. Did you rule out this bug at the  usage of alloca() in
linux_gnttab_grant_map? If not then I think that should be changed too.

> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 7c777cb8f705 -r e62ab14d44af tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/tools/libxc/xc_linux_osdep.c	Fri Apr 20 11:36:02 2012 -0700
> @@ -39,6 +39,7 @@
>  #include "xenctrl.h"
>  #include "xenctrlosdep.h"
>  
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
>  #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>  #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> @@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
>                  fd, 0);
>      if ( addr == MAP_FAILED )
>      {
> -        PERROR("xc_map_foreign_batch: mmap failed");
> +        PERROR("xc_map_foreign_bulk: mmap failed");
>          return NULL;
>      }
>  
> @@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
>          privcmd_mmapbatch_t ioctlx;
> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> +        xen_pfn_t *pfn;
> +        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
> +
> +        if ( pfn_arr_size <= XC_PAGE_SIZE )
> +            pfn = alloca(num * sizeof(*pfn));
> +        else
> +        {
> +            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
> +                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +            if ( pfn == MAP_FAILED )
> +            {
> +                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> +                return NULL;
> +            }
> +        }
>  
>          memcpy(pfn, arr, num * sizeof(*arr));
>  
> @@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
>              break;
>          }
>  
> +        if ( pfn_arr_size > XC_PAGE_SIZE )
> +            munmap(pfn, pfn_arr_size);
> +
>          if ( rc == -ENOENT && i == num )
>              rc = 0;
>          else if ( rc )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 11:05:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 11:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLY7Y-0007Xt-8C; Sat, 21 Apr 2012 11:04:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SLY7X-0007Xo-Bl
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 11:04:51 +0000
Received: from [85.158.143.99:52113] by server-1.bemta-4.messagelabs.com id
	C2/22-20925-254929F4; Sat, 21 Apr 2012 11:04:50 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335006289!23731920!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8714 invoked from network); 21 Apr 2012 11:04:49 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 11:04:49 -0000
Received: by eaal11 with SMTP id l11so3900576eaa.30
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Apr 2012 04:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=K5FfNF8GE7yFc8/L9jDay+KBUkwDH0GuHO/g7I0NTDY=;
	b=XPPIWnkxmJmk/wbbEZWcVQzdVEwAVsSu5egwJvfDxKdKi8cquSwRYca85ybBoUTiRv
	XyqcIAwVJg5DhW3URzv4iBma3QNoBmnh6zSkFafTQi5RW94KM7Yku+IsTl7++/Ci2B48
	83PykfF5OaLZzdYnAPdkv21CXLsfAl3DxtzXiVooY4t3hrC2bDZKDk91Benu4VzrNo1c
	iOYR4f7IIk8LGAmZym0deKV80FgxInh8v8kD/wCOTepJ02eFRt1PRG35Hsls16jCgumQ
	CMjuzLh1321M6j8tReo4sFRiRUwT69CucFvVVJ1PFY8rL2bfHASRdMKX7qyYYdn85mzO
	cDXQ==
MIME-Version: 1.0
Received: by 10.213.110.7 with SMTP id l7mr812201ebp.7.1335006288313; Sat, 21
	Apr 2012 04:04:48 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Sat, 21 Apr 2012 04:04:48 -0700 (PDT)
Date: Sat, 21 Apr 2012 07:04:48 -0400
Message-ID: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7764536702086503270=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7764536702086503270==
Content-Type: multipart/alternative; boundary=0015174766f8967c5f04be2e5fdc

--0015174766f8967c5f04be2e5fdc
Content-Type: text/plain; charset=ISO-8859-1

Hello list,

I am attempting to run openindiana 151a in xen (xen 2.4-unstable rev 24785,
patched with this patch <http://xen.markmail.org/thread/d7qhk4vzikgo5ofc>),
but when attempting to create the VM I get the following error:

*root@dom0:/$xl create /etc/xen/vm/oi.cfg*
*Parsing config file /etc/xen/vm/oi.cfg*
*libxl: error: libxl_create.c:494:do_domain_create: failed to run
bootloader: -3*


Here is my oi.cfg file:

* vif = [ 'bridge=eth0, mac=00:14:3e:00:8f:d8' ] *
*
*
* vcpus = 2*
* cpus = "2-3"*
* memory = 2048*
* name = "oi"*
*
*
* kernel = "/etc/xen/kernels/oi151a/unix"*
* ramdisk = "/etc/xen/kernels/oi151a/boot_archive"*
*
*
*# Pre install booting*
* extra = "/platform/i86xpv/kernel/amd64/unix -B console=ttya"*
* disk = [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
'phy:/dev/dom0/oi_boot,xvda,w' ]*
* bootloader = "/usr/bin/pygrub"*
*
*
*# Post install booting*
*# extra = "/platform/i86xpv/kernel/amd64/unix -B
zfs-bootfs=rpool/ROOT/openindiana,bootpath=/xpvd/xdf@51712:a"*
*# disk = [ 'phy:/dev/dom0/oi_boot,xvda,w' ]*
*
*
* on_shutdown = "destroy"*
* on_reboot = "restart"*
* on_crash = "destroy"*
*
*
* pci = [ '05:00.0' ]*



As a test, I checked if pygrub has any errors:

*root@dom0:/$pygrub /mnt/media/comp_files/os-iso/oi151a.iso *
*linux (kernel /var/run/xend/boot/boot_kernel.RomUm9)(ramdisk
/var/run/xend/boot/boot_ramdisk.WdnQsz)(args
"/platform/i86xpv/kernel/amd64/unix")*

I am assuming that pygrub can correctly handle the install media.



The irony is that I have managed to get this working once, but I was using
a regular file image for this VM boot_disk and the VM was horribly slow.
I re-installed my whole system on an LVM disk, which I understand is
recommended for better disk performance.

I would appreciate any suggestions.

Regards

Sandi

--0015174766f8967c5f04be2e5fdc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello list,<div><br></div><div>I am attempting to run openindiana 151a in x=
en (xen 2.4-unstable rev 24785, patched with <a href=3D"http://xen.markmail=
.org/thread/d7qhk4vzikgo5ofc" target=3D"_blank">this patch</a>), but when a=
ttempting to create the VM I get the following error:</div>

<div><br></div><div><div><i><font color=3D"#000066">root@dom0:/$xl create /=
etc/xen/vm/oi.cfg</font></i></div><div><i><font color=3D"#000066">Parsing c=
onfig file /etc/xen/vm/oi.cfg</font></i></div><div><i><font color=3D"#00006=
6">libxl: error: libxl_create.c:494:do_domain_create: failed to run bootloa=
der: -3</font></i></div>

</div><div><br></div><div><br></div><div>Here is my oi.cfg file:</div><div>=
<br></div><div><div><i><font color=3D"#000066">=A0vif =3D [ &#39;bridge=3De=
th0, mac=3D00:14:3e:00:8f:d8&#39; ]=A0</font></i></div><div><i><font color=
=3D"#000066"><br>

</font></i></div><div><i><font color=3D"#000066">=A0vcpus =3D 2</font></i><=
/div><div><i><font color=3D"#000066">=A0cpus =3D &quot;2-3&quot;</font></i>=
</div><div><i><font color=3D"#000066">=A0memory =3D 2048</font></i></div><d=
iv><i><font color=3D"#000066">=A0name =3D &quot;oi&quot;</font></i></div>

<div><i><font color=3D"#000066"><br></font></i></div><div><i><font color=3D=
"#000066">=A0kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot;</font></i>=
</div><div><i><font color=3D"#000066">=A0ramdisk =3D &quot;/etc/xen/kernels=
/oi151a/boot_archive&quot;</font></i></div>

<div><i><font color=3D"#000066"><br></font></i></div><div><i><font color=3D=
"#000066"># Pre install booting</font></i></div><div><i><font color=3D"#000=
066">=A0extra =3D &quot;/platform/i86xpv/kernel/amd64/unix -B console=3Dtty=
a&quot;</font></i></div>

<div><i><font color=3D"#000066">=A0disk =3D [ &#39;file:/mnt/media/comp_fil=
es/os-iso/oi151a.iso,xvdc:cdrom,r&#39; , &#39;phy:/dev/dom0/oi_boot,xvda,w&=
#39; ]</font></i></div><div><i><font color=3D"#000066">=A0bootloader =3D &q=
uot;/usr/bin/pygrub&quot;</font></i></div>

<div><i><font color=3D"#000066"><br></font></i></div><div><i><font color=3D=
"#000066"># Post install booting</font></i></div><div><i><font color=3D"#00=
0066"># extra =3D &quot;/platform/i86xpv/kernel/amd64/unix -B zfs-bootfs=3D=
rpool/ROOT/openindiana,bootpath=3D/xpvd/xdf@51712:a&quot;</font></i></div>

<div><i><font color=3D"#000066"># disk =3D [ &#39;phy:/dev/dom0/oi_boot,xvd=
a,w&#39; ]</font></i></div><div><i><font color=3D"#000066"><br></font></i><=
/div><div><i><font color=3D"#000066">=A0on_shutdown =3D &quot;destroy&quot;=
</font></i></div>

<div><i><font color=3D"#000066">=A0on_reboot =3D &quot;restart&quot;</font>=
</i></div><div><i><font color=3D"#000066">=A0on_crash =3D &quot;destroy&quo=
t;</font></i></div><div><i><font color=3D"#000066"><br></font></i></div><di=
v><i><font color=3D"#000066">=A0pci =3D [ &#39;05:00.0&#39; ]</font></i></d=
iv>

<div><br></div><div><br></div><div><br></div><div>As a test, I checked if p=
ygrub has any errors:</div></div><div><br></div><div><div><i><font color=3D=
"#000066">root@dom0:/$pygrub /mnt/media/comp_files/os-iso/oi151a.iso=A0</fo=
nt></i></div>

<div><i><font color=3D"#000066">linux (kernel /var/run/xend/boot/boot_kerne=
l.RomUm9)(ramdisk /var/run/xend/boot/boot_ramdisk.WdnQsz)(args &quot;/platf=
orm/i86xpv/kernel/amd64/unix&quot;)</font></i></div></div><div><br></div>

<div>I am=A0assuming=A0that pygrub can correctly handle the install media.<=
/div><div><br></div><div><br></div><div><br></div><div>The irony is that I =
have managed to get this working once, but I was using a regular file image=
 for this VM boot_disk and the VM was horribly slow. I=A0re-installed=A0my =
whole system on an LVM disk, which I understand is recommended for better d=
isk performance.</div>

<div><br></div><div>I would appreciate any suggestions.</div><div><br></div=
><div>Regards</div><div><br></div><div>Sandi</div>

--0015174766f8967c5f04be2e5fdc--


--===============7764536702086503270==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7764536702086503270==--


From xen-devel-bounces@lists.xen.org Sat Apr 21 11:05:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 11:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLY7Y-0007Xt-8C; Sat, 21 Apr 2012 11:04:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SLY7X-0007Xo-Bl
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 11:04:51 +0000
Received: from [85.158.143.99:52113] by server-1.bemta-4.messagelabs.com id
	C2/22-20925-254929F4; Sat, 21 Apr 2012 11:04:50 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335006289!23731920!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8714 invoked from network); 21 Apr 2012 11:04:49 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Apr 2012 11:04:49 -0000
Received: by eaal11 with SMTP id l11so3900576eaa.30
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Apr 2012 04:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=K5FfNF8GE7yFc8/L9jDay+KBUkwDH0GuHO/g7I0NTDY=;
	b=XPPIWnkxmJmk/wbbEZWcVQzdVEwAVsSu5egwJvfDxKdKi8cquSwRYca85ybBoUTiRv
	XyqcIAwVJg5DhW3URzv4iBma3QNoBmnh6zSkFafTQi5RW94KM7Yku+IsTl7++/Ci2B48
	83PykfF5OaLZzdYnAPdkv21CXLsfAl3DxtzXiVooY4t3hrC2bDZKDk91Benu4VzrNo1c
	iOYR4f7IIk8LGAmZym0deKV80FgxInh8v8kD/wCOTepJ02eFRt1PRG35Hsls16jCgumQ
	CMjuzLh1321M6j8tReo4sFRiRUwT69CucFvVVJ1PFY8rL2bfHASRdMKX7qyYYdn85mzO
	cDXQ==
MIME-Version: 1.0
Received: by 10.213.110.7 with SMTP id l7mr812201ebp.7.1335006288313; Sat, 21
	Apr 2012 04:04:48 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Sat, 21 Apr 2012 04:04:48 -0700 (PDT)
Date: Sat, 21 Apr 2012 07:04:48 -0400
Message-ID: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7764536702086503270=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7764536702086503270==
Content-Type: multipart/alternative; boundary=0015174766f8967c5f04be2e5fdc

--0015174766f8967c5f04be2e5fdc
Content-Type: text/plain; charset=ISO-8859-1

Hello list,

I am attempting to run openindiana 151a in xen (xen 2.4-unstable rev 24785,
patched with this patch <http://xen.markmail.org/thread/d7qhk4vzikgo5ofc>),
but when attempting to create the VM I get the following error:

*root@dom0:/$xl create /etc/xen/vm/oi.cfg*
*Parsing config file /etc/xen/vm/oi.cfg*
*libxl: error: libxl_create.c:494:do_domain_create: failed to run
bootloader: -3*


Here is my oi.cfg file:

* vif = [ 'bridge=eth0, mac=00:14:3e:00:8f:d8' ] *
*
*
* vcpus = 2*
* cpus = "2-3"*
* memory = 2048*
* name = "oi"*
*
*
* kernel = "/etc/xen/kernels/oi151a/unix"*
* ramdisk = "/etc/xen/kernels/oi151a/boot_archive"*
*
*
*# Pre install booting*
* extra = "/platform/i86xpv/kernel/amd64/unix -B console=ttya"*
* disk = [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
'phy:/dev/dom0/oi_boot,xvda,w' ]*
* bootloader = "/usr/bin/pygrub"*
*
*
*# Post install booting*
*# extra = "/platform/i86xpv/kernel/amd64/unix -B
zfs-bootfs=rpool/ROOT/openindiana,bootpath=/xpvd/xdf@51712:a"*
*# disk = [ 'phy:/dev/dom0/oi_boot,xvda,w' ]*
*
*
* on_shutdown = "destroy"*
* on_reboot = "restart"*
* on_crash = "destroy"*
*
*
* pci = [ '05:00.0' ]*



As a test, I checked if pygrub has any errors:

*root@dom0:/$pygrub /mnt/media/comp_files/os-iso/oi151a.iso *
*linux (kernel /var/run/xend/boot/boot_kernel.RomUm9)(ramdisk
/var/run/xend/boot/boot_ramdisk.WdnQsz)(args
"/platform/i86xpv/kernel/amd64/unix")*

I am assuming that pygrub can correctly handle the install media.



The irony is that I have managed to get this working once, but I was using
a regular file image for this VM boot_disk and the VM was horribly slow.
I re-installed my whole system on an LVM disk, which I understand is
recommended for better disk performance.

I would appreciate any suggestions.

Regards

Sandi

--0015174766f8967c5f04be2e5fdc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello list,<div><br></div><div>I am attempting to run openindiana 151a in x=
en (xen 2.4-unstable rev 24785, patched with <a href=3D"http://xen.markmail=
.org/thread/d7qhk4vzikgo5ofc" target=3D"_blank">this patch</a>), but when a=
ttempting to create the VM I get the following error:</div>

<div><br></div><div><div><i><font color=3D"#000066">root@dom0:/$xl create /=
etc/xen/vm/oi.cfg</font></i></div><div><i><font color=3D"#000066">Parsing c=
onfig file /etc/xen/vm/oi.cfg</font></i></div><div><i><font color=3D"#00006=
6">libxl: error: libxl_create.c:494:do_domain_create: failed to run bootloa=
der: -3</font></i></div>

</div><div><br></div><div><br></div><div>Here is my oi.cfg file:</div><div>=
<br></div><div><div><i><font color=3D"#000066">=A0vif =3D [ &#39;bridge=3De=
th0, mac=3D00:14:3e:00:8f:d8&#39; ]=A0</font></i></div><div><i><font color=
=3D"#000066"><br>

</font></i></div><div><i><font color=3D"#000066">=A0vcpus =3D 2</font></i><=
/div><div><i><font color=3D"#000066">=A0cpus =3D &quot;2-3&quot;</font></i>=
</div><div><i><font color=3D"#000066">=A0memory =3D 2048</font></i></div><d=
iv><i><font color=3D"#000066">=A0name =3D &quot;oi&quot;</font></i></div>

<div><i><font color=3D"#000066"><br></font></i></div><div><i><font color=3D=
"#000066">=A0kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot;</font></i>=
</div><div><i><font color=3D"#000066">=A0ramdisk =3D &quot;/etc/xen/kernels=
/oi151a/boot_archive&quot;</font></i></div>

<div><i><font color=3D"#000066"><br></font></i></div><div><i><font color=3D=
"#000066"># Pre install booting</font></i></div><div><i><font color=3D"#000=
066">=A0extra =3D &quot;/platform/i86xpv/kernel/amd64/unix -B console=3Dtty=
a&quot;</font></i></div>

<div><i><font color=3D"#000066">=A0disk =3D [ &#39;file:/mnt/media/comp_fil=
es/os-iso/oi151a.iso,xvdc:cdrom,r&#39; , &#39;phy:/dev/dom0/oi_boot,xvda,w&=
#39; ]</font></i></div><div><i><font color=3D"#000066">=A0bootloader =3D &q=
uot;/usr/bin/pygrub&quot;</font></i></div>

<div><i><font color=3D"#000066"><br></font></i></div><div><i><font color=3D=
"#000066"># Post install booting</font></i></div><div><i><font color=3D"#00=
0066"># extra =3D &quot;/platform/i86xpv/kernel/amd64/unix -B zfs-bootfs=3D=
rpool/ROOT/openindiana,bootpath=3D/xpvd/xdf@51712:a&quot;</font></i></div>

<div><i><font color=3D"#000066"># disk =3D [ &#39;phy:/dev/dom0/oi_boot,xvd=
a,w&#39; ]</font></i></div><div><i><font color=3D"#000066"><br></font></i><=
/div><div><i><font color=3D"#000066">=A0on_shutdown =3D &quot;destroy&quot;=
</font></i></div>

<div><i><font color=3D"#000066">=A0on_reboot =3D &quot;restart&quot;</font>=
</i></div><div><i><font color=3D"#000066">=A0on_crash =3D &quot;destroy&quo=
t;</font></i></div><div><i><font color=3D"#000066"><br></font></i></div><di=
v><i><font color=3D"#000066">=A0pci =3D [ &#39;05:00.0&#39; ]</font></i></d=
iv>

<div><br></div><div><br></div><div><br></div><div>As a test, I checked if p=
ygrub has any errors:</div></div><div><br></div><div><div><i><font color=3D=
"#000066">root@dom0:/$pygrub /mnt/media/comp_files/os-iso/oi151a.iso=A0</fo=
nt></i></div>

<div><i><font color=3D"#000066">linux (kernel /var/run/xend/boot/boot_kerne=
l.RomUm9)(ramdisk /var/run/xend/boot/boot_ramdisk.WdnQsz)(args &quot;/platf=
orm/i86xpv/kernel/amd64/unix&quot;)</font></i></div></div><div><br></div>

<div>I am=A0assuming=A0that pygrub can correctly handle the install media.<=
/div><div><br></div><div><br></div><div><br></div><div>The irony is that I =
have managed to get this working once, but I was using a regular file image=
 for this VM boot_disk and the VM was horribly slow. I=A0re-installed=A0my =
whole system on an LVM disk, which I understand is recommended for better d=
isk performance.</div>

<div><br></div><div>I would appreciate any suggestions.</div><div><br></div=
><div>Regards</div><div><br></div><div>Sandi</div>

--0015174766f8967c5f04be2e5fdc--


--===============7764536702086503270==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7764536702086503270==--


From xen-devel-bounces@lists.xen.org Sat Apr 21 13:15:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 13:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLa99-0008D2-0a; Sat, 21 Apr 2012 13:14:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bugs@humanleg.org.uk>) id 1SLa97-0008Cx-7M
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 13:14:37 +0000
Received: from [85.158.143.35:12206] by server-2.bemta-4.messagelabs.com id
	4B/52-17550-CB2B29F4; Sat, 21 Apr 2012 13:14:36 +0000
X-Env-Sender: bugs@humanleg.org.uk
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335014075!13988851!1
X-Originating-IP: [81.103.221.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15523 invoked from network); 21 Apr 2012 13:14:36 -0000
Received: from mtaout01-winn.ispmail.ntl.com (HELO
	mtaout01-winn.ispmail.ntl.com) (81.103.221.47)
	by server-15.tower-21.messagelabs.com with SMTP;
	21 Apr 2012 13:14:36 -0000
Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35])
	by mtaout01-winn.ispmail.ntl.com
	(InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id
	<20120421131435.CKJM22007.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>;
	Sat, 21 Apr 2012 14:14:35 +0100
Received: from leclerc.lan ([81.105.12.50]) by aamtaout03-winn.ispmail.ntl.com
	(InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id
	<20120421131434.EAIM13318.aamtaout03-winn.ispmail.ntl.com@leclerc.lan>;
	Sat, 21 Apr 2012 14:14:34 +0100
From: Robert Scott <bugs@humanleg.org.uk>
Organization: none
To: Jonathan Nieder <jrnieder@gmail.com>
Date: Sat, 21 Apr 2012 14:14:21 +0100
User-Agent: KMail/1.9.9
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<201204161905.13260.bugs@humanleg.org.uk>
	<20120417020433.GA15848@burratino>
In-Reply-To: <20120417020433.GA15848@burratino>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201204211414.30286.bugs@humanleg.org.uk>
X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g=
	c=1 sm=0 a=oafpOytrBa8A:10 a=l5_RjRQ6opQA:10 a=8nJEP1OIZ-IA:10
	a=hLW_Fef1W2nHZV0zz8kA:9 a=wPNLvfGTeEIA:10
	a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: bugs@humanleg.org.uk
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 17 April 2012, Jonathan Nieder wrote:
> Robert Scott wrote:
> > On Sunday 15 April 2012, Jonathan Nieder wrote:
> 
> >> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
> >> it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
> >> semantics in fixup_irqs()") will fix this.
> >
> > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.
> 
> Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
> same problem?  Can you get a log of the failure with
> "no_console_suspend" appended to the kernel command line, for example
> with a serial console or netconsole?

(back on 3.2.0-0.bpo.2-686-pae 3.2.12-1~bpo60+1*:)

eth0 seems to go down/come up to early/late to get anything useful from netconsole:

[  745.161322] PM: Syncing filesystems ... done.
[  747.088247] PM: Preparing system for mem sleep
[  747.187932] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  747.204325] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  747.220416] PM: Entering mem sleep
[  747.221085] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[  747.222247] sd 1:0:0:0: [sda] Stopping disk

(then nothing)

I may be able to hook up a usb-serial adaptor to try and get more info but it'll take me a bit longer what with all the rewiring fun as I don't have a null modem cable lying around.

> If someone has time to go through the steps in
> "Documentation/power/basic-pm-debugging.txt", that would also be useful.

"freezer", "devices", "platform", "processors", or "core" pm_test modes all work fine, naturally.


robert.

* I notice I accidentally copy/pasted the linux-modules version in a previous mail but you knew what I was talking about

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 13:15:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 13:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLa99-0008D2-0a; Sat, 21 Apr 2012 13:14:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bugs@humanleg.org.uk>) id 1SLa97-0008Cx-7M
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 13:14:37 +0000
Received: from [85.158.143.35:12206] by server-2.bemta-4.messagelabs.com id
	4B/52-17550-CB2B29F4; Sat, 21 Apr 2012 13:14:36 +0000
X-Env-Sender: bugs@humanleg.org.uk
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335014075!13988851!1
X-Originating-IP: [81.103.221.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15523 invoked from network); 21 Apr 2012 13:14:36 -0000
Received: from mtaout01-winn.ispmail.ntl.com (HELO
	mtaout01-winn.ispmail.ntl.com) (81.103.221.47)
	by server-15.tower-21.messagelabs.com with SMTP;
	21 Apr 2012 13:14:36 -0000
Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35])
	by mtaout01-winn.ispmail.ntl.com
	(InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id
	<20120421131435.CKJM22007.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>;
	Sat, 21 Apr 2012 14:14:35 +0100
Received: from leclerc.lan ([81.105.12.50]) by aamtaout03-winn.ispmail.ntl.com
	(InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id
	<20120421131434.EAIM13318.aamtaout03-winn.ispmail.ntl.com@leclerc.lan>;
	Sat, 21 Apr 2012 14:14:34 +0100
From: Robert Scott <bugs@humanleg.org.uk>
Organization: none
To: Jonathan Nieder <jrnieder@gmail.com>
Date: Sat, 21 Apr 2012 14:14:21 +0100
User-Agent: KMail/1.9.9
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<201204161905.13260.bugs@humanleg.org.uk>
	<20120417020433.GA15848@burratino>
In-Reply-To: <20120417020433.GA15848@burratino>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201204211414.30286.bugs@humanleg.org.uk>
X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g=
	c=1 sm=0 a=oafpOytrBa8A:10 a=l5_RjRQ6opQA:10 a=8nJEP1OIZ-IA:10
	a=hLW_Fef1W2nHZV0zz8kA:9 a=wPNLvfGTeEIA:10
	a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>, Lars Boegild Thomsen <lth@cow.dk>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: bugs@humanleg.org.uk
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 17 April 2012, Jonathan Nieder wrote:
> Robert Scott wrote:
> > On Sunday 15 April 2012, Jonathan Nieder wrote:
> 
> >> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how
> >> it goes?  I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable
> >> semantics in fixup_irqs()") will fix this.
> >
> > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.
> 
> Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
> same problem?  Can you get a log of the failure with
> "no_console_suspend" appended to the kernel command line, for example
> with a serial console or netconsole?

(back on 3.2.0-0.bpo.2-686-pae 3.2.12-1~bpo60+1*:)

eth0 seems to go down/come up to early/late to get anything useful from netconsole:

[  745.161322] PM: Syncing filesystems ... done.
[  747.088247] PM: Preparing system for mem sleep
[  747.187932] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  747.204325] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  747.220416] PM: Entering mem sleep
[  747.221085] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[  747.222247] sd 1:0:0:0: [sda] Stopping disk

(then nothing)

I may be able to hook up a usb-serial adaptor to try and get more info but it'll take me a bit longer what with all the rewiring fun as I don't have a null modem cable lying around.

> If someone has time to go through the steps in
> "Documentation/power/basic-pm-debugging.txt", that would also be useful.

"freezer", "devices", "platform", "processors", or "core" pm_test modes all work fine, naturally.


robert.

* I notice I accidentally copy/pasted the linux-modules version in a previous mail but you knew what I was talking about

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIZ-00034k-Pg; Sat, 21 Apr 2012 21:56:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxjL-0005RT-RS
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:13:28 +0000
Received: from [85.158.143.99:9247] by server-2.bemta-4.messagelabs.com id
	E7/DF-17550-7E1709F4; Thu, 19 Apr 2012 20:13:27 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334866402!19153561!1
X-Originating-IP: [202.81.31.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNjU4NDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16481 invoked from network); 19 Apr 2012 20:13:25 -0000
Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:13:25 -0000
Received: from /spool/local
	by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:05:37 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:05:35 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK6h9l1310796
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:06:43 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKDHAA011543
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:13:19 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKD5KH011319; Fri, 20 Apr 2012 06:13:11 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:42:59 +0530
Message-Id: <20120419201256.5411.59675.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-1618-0000-0000-00000158B471
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 2/12] x86/ticketlock: don't inline
	_spin_unlock when using paravirt spinlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 

The code size expands somewhat, and its better to just call
a function rather than inline it.

Thanks Jeremy for original version of ARCH_NOINLINE_SPIN_UNLOCK config patch, 
which is simplified.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1d14cc6..35eb2e4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -597,6 +597,7 @@ config PARAVIRT
 config PARAVIRT_SPINLOCKS
 	bool "Paravirtualization layer for spinlocks"
 	depends on PARAVIRT && SMP && EXPERIMENTAL
+	select UNINLINE_SPIN_UNLOCK
 	---help---
 	  Paravirtualized spinlocks allow a pvops backend to replace the
 	  spinlock implementation with something virtualization-friendly


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIf-000396-34; Sat, 21 Apr 2012 21:57:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SLFfz-0003iE-MD
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:23:11 +0000
Received: from [85.158.139.83:40493] by server-10.bemta-5.messagelabs.com id
	A0/93-08260-E5F719F4; Fri, 20 Apr 2012 15:23:10 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334935389!24686026!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12934 invoked from network); 20 Apr 2012 15:23:10 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 15:23:10 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 70A2F1C1414C;
	Fri, 20 Apr 2012 17:23:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:content-transfer-encoding:in-reply-to; s=selector1; bh=nQzzZ8eI
	LKlgJ4plM74e1hkI+Qc=; b=OSnyn8PnkG+4z+BONoRZSLD0E4EQnqRNMnmRYjLw
	kQYBZgOvyDzQZZwgO5l+xL7t6YB0K12hzRIEPUn6iJZ30liJw+cUozsD22gew6/r
	Btcxj4DQ/7/kNo2CghpoPKY0p0A4jrRBaBck6ZyaqLS5kXvINUET3lvDyOQIw3h0
	f2V8MYvYsg+TQHsCBiLltbWu65bI++Omuf2+CR4GxlOHqBwYLBAFGsxE62HwOF6K
	UvSChf3dYmBSJgJbyLQrdb2647wKXjRLzvIzqy5nAq7F+rIC7CgUwCyzZpsurLTv
	a3N2F9phl69MoxlwPPXElzrTrqOsyapAgTkV++1Hxd9t6OBqqam4rrlQHoY1jcQT
	3wyx+xcrvsk4Ln2s0FpyrnVhru2b2qZRlzkbxOmJz4nu85Ppal08juHH4zVi7BkI
	jDe+VvVxvWyIkm2kAX2x42WAvlQZKEqXNdrQn4Q8QTp754CZFkZpmUHEuQKhPoSq
	41Dk6CM0oLa40pC6nz6okCHlFUzdiU4GqRwuyQjSwQxIK7lMAHj7MWDCcLhpLrlQ
	Z1ZUP8y6m7eZBFmE+2WuL6QgJmUdiP209s27ECKTxOAqSPaPaLlYmoymr+wsKb//
	dARexz4JJnYSSNJi/r1JY5x003P9DM6IR/MlNCpbvXaqG++6y+ovZNauD+rQPgJo
	eow=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 0E7A41C14178; Fri, 20 Apr 2012 17:23:08 +0200 (CEST)
Date: Fri, 20 Apr 2012 17:23:08 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120420152308.GC3720@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Dieter Bloms <xensource.com@bloms.de>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I'am not a programmer, but will have a look at it the next days and let
you know if my skills are good enough.

On Fri, Apr 20, Ian Campbell wrote:

> Hi Dieter, =

> =

> thanks for the report.
> =

> It seems that support for this config file variable is not present in xl
> at the moment. We should try and add this for 4.2 IMHO.
> =

> If you know a little bit of C (or are interested in learning) then this
> should be a pretty simple thing to implement -- please let me know if
> you want more details.
> =

> Ian.
> =

> On Fri, 2012-04-20 at 16:00 +0100, Dieter Bloms wrote:
> > Hi,
> > =

> > I've installed xen-unstable 4.2 from actual git (last commit was
> > 4dc7dbef5400f0608321d579aebb57f933e8f707).
> > =

> > When I start a domU with xm all is fine include the cpu_weight I
> > configured in my domU config.
> > =

> > When I start the domU with xl then all my domU have the default
> > cpu_weight of 256 instead of the configured one.
> > =

> > Was the name of cpu_weight being changed for xl command ?
> > =

> > My domU config looks like this:
> > =

> > --snip--
> > name=3D"vdrserver"
> > description=3D"vdrserver for my clients"
> > memory=3D768
> > maxmem=3D2048
> > vcpus=3D1
> > cpus=3D"1"
> > cpu_weight =3D 128
> > on_poweroff=3D"destroy"
> > on_reboot=3D"restart"
> > on_crash=3D"destroy"
> > =

> > localtime=3D0
> > keymap=3D"de"
> > =

> > builder=3D"linux"
> > bootloader=3D"/usr/bin/pygrub"
> > bootargs=3D""
> > extra=3D"console=3Dhvc0 tmem cgroup_disable=3Dmemory independent_wallcl=
ock=3D1 iommu=3Dsoft"
> > nographic=3D1
> > keymap =3D 'de'
> > =

> > disk=3D[ =

> >   'phy:/dev/mapper/xenimages-vdrserver,xvda1,w',
> >   'phy:/dev/mapper/xenimages-swap_vdrserver,xvda2,w',
> > ]
> > vif=3D[ 'mac=3D00:00:00:00:00:80,bridge=3Dbr0', ]
> > =

> > pci =3D [ '06:00.0', '06:01.0', '00:12.2', '00:13.2']
> > --snip--
> > =

> > =

> =

> =


-- =

Gru=DF

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIf-00039X-Fc; Sat, 21 Apr 2012 21:57:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SLXoV-0007Td-G1
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 10:45:11 +0000
Received: from [193.109.254.147:3429] by server-4.bemta-14.messagelabs.com id
	B5/C9-11570-3BF829F4; Sat, 21 Apr 2012 10:45:07 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335005105!5678861!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3329 invoked from network); 21 Apr 2012 10:45:05 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-3.tower-27.messagelabs.com with SMTP;
	21 Apr 2012 10:45:05 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id B080CC0F0BA;
	Sat, 21 Apr 2012 12:45:04 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id sJ+AH25ru-if; Sat, 21 Apr 2012 12:45:04 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Sat, 21 Apr 2012 12:45:04 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 567CD49C222;
	Sat, 21 Apr 2012 11:45:04 +0100 (BST)
Date: Sat, 21 Apr 2012 12:45:02 +0200
From: Borislav Petkov <bp@amd64.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120421104502.GB17005@aftab.osrc.amd.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120421041454.GA29704@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:53 +0000
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	bp@amd64.org, tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

+ x86 people.

On Sat, Apr 21, 2012 at 12:14:54AM -0400, Konrad Rzeszutek Wilk wrote:
> Should this driver reside in arch/x86/kernel/cpu/mcheck?

The fact that you raise such a question is already loaded with problems,
see below.

> I can keep it in drivers/xen, but I realized that perhaps it
> should be in a different location?
> > 
> > When MCA error occurs, it would be handled by xen hypervisor first,
> > and then the error information would be sent to dom0 for logging.
> > 
> > This patch gets error information from xen hypervisor and convert
> > xen format error into linux format mcelog. This logic is basically
> > self-contained, not much touching other kernel components.

I have a problem with that statement above. This thing uses struct mce
and mce_log(), which are internal to x86, and whenever we want to change
anything there, we won't be able to because xen uses it too.

And this has happened already with the whole microcode loading debacle.

So, my suggestion is to copy the pieces you need and create your own xen
version of /dev/mcelog and add it to dom0 so that there's no hooking
into baremetal code and whenever a dom0 kernel is running, you can
reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
and not hook into the x86 versions.

Because, if you'd hooked into it, just imagine one fine day, when we
remove mcelog support, what screaming the xen people will be doing when
mcelog doesn't work anymore.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIY-00033w-4F; Sat, 21 Apr 2012 21:56:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <lth@cow.dk>)
	id 1SKRjm-0001EL-DF
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 10:03:46 +0000
Received: from [85.158.138.51:53093] by server-5.bemta-3.messagelabs.com id
	C6/E6-17113-1819E8F4; Wed, 18 Apr 2012 10:03:45 +0000
X-Env-Sender: lth@cow.dk
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334743423!22521993!1
X-Originating-IP: [95.166.183.192]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17390 invoked from network); 18 Apr 2012 10:03:44 -0000
Received: from 4607ds7-vby.0.fullrate.dk (HELO cow.netcompartner.com)
	(95.166.183.192)
	by server-16.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Apr 2012 10:03:44 -0000
Received: from [175.136.158.155] (helo=ncpws04.localnet)
	by cow.netcompartner.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77)
	(envelope-from <lth@cow.dk>)
	id 1SKRj7-0004sq-K2; Wed, 18 Apr 2012 12:03:06 +0200
From: Lars Boegild Thomsen <lth@cow.dk>
Organization: Call of the Wild BBS
To: Jonathan Nieder <jrnieder@gmail.com>
Date: Wed, 18 Apr 2012 18:03:00 +0800
User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; )
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<201204161905.13260.bugs@humanleg.org.uk>
	<20120417020433.GA15848@burratino>
In-Reply-To: <20120417020433.GA15848@burratino>
MIME-Version: 1.0
Message-Id: <201204181803.00383.lth@cow.dk>
X-Spam-Score: -2.9 (--)
X-Spam-Report: Spam detection software,
	running on the system "cow.netcompartner.com", has
	identified this incoming email as possible spam. The original message
	has been attached to this so you can view it (if it isn't spam) or
	label similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview: On Tuesday 17 April 2012 10:04:33 Jonathan Nieder
	wrote: >
	> Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid. > Alas.
	Does suspend-to-disk ("echo disk >/sys/power/state") have the > same
	problem?
	Can you get a log of the failure with > "no_console_suspend" appended
	to the kernel command line,
	for example > with a serial console or netconsole? [...] 
	Content analysis details:   (-2.9 points, 5.0 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
	[score: 0.0000]
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:53 +0000
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Robert Scott <bugs@humanleg.org.uk>, hpa@zytor.com,
	linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>,
	e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 17 April 2012 10:04:33 Jonathan Nieder wrote:
> > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.
> Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
> same problem?  Can you get a log of the failure with
> "no_console_suspend" appended to the kernel command line, for example
> with a serial console or netconsole?

Using a serial console is a bit of a problem on this netbook as it hasn't got 
a serial port.  Not sure how the netconsole works - will read up on that.

And no - suspend to disk works fine.

I have by the way experimentally switched to 32bit version and it's the same 
thing (originally I was running 64bit version but that really doesn't make 
sense on a netbook - except doing it because it could be done).

//Lars...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIf-000396-34; Sat, 21 Apr 2012 21:57:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SLFfz-0003iE-MD
	for xen-devel@lists.xen.org; Fri, 20 Apr 2012 15:23:11 +0000
Received: from [85.158.139.83:40493] by server-10.bemta-5.messagelabs.com id
	A0/93-08260-E5F719F4; Fri, 20 Apr 2012 15:23:10 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1334935389!24686026!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12934 invoked from network); 20 Apr 2012 15:23:10 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Apr 2012 15:23:10 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 70A2F1C1414C;
	Fri, 20 Apr 2012 17:23:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:content-transfer-encoding:in-reply-to; s=selector1; bh=nQzzZ8eI
	LKlgJ4plM74e1hkI+Qc=; b=OSnyn8PnkG+4z+BONoRZSLD0E4EQnqRNMnmRYjLw
	kQYBZgOvyDzQZZwgO5l+xL7t6YB0K12hzRIEPUn6iJZ30liJw+cUozsD22gew6/r
	Btcxj4DQ/7/kNo2CghpoPKY0p0A4jrRBaBck6ZyaqLS5kXvINUET3lvDyOQIw3h0
	f2V8MYvYsg+TQHsCBiLltbWu65bI++Omuf2+CR4GxlOHqBwYLBAFGsxE62HwOF6K
	UvSChf3dYmBSJgJbyLQrdb2647wKXjRLzvIzqy5nAq7F+rIC7CgUwCyzZpsurLTv
	a3N2F9phl69MoxlwPPXElzrTrqOsyapAgTkV++1Hxd9t6OBqqam4rrlQHoY1jcQT
	3wyx+xcrvsk4Ln2s0FpyrnVhru2b2qZRlzkbxOmJz4nu85Ppal08juHH4zVi7BkI
	jDe+VvVxvWyIkm2kAX2x42WAvlQZKEqXNdrQn4Q8QTp754CZFkZpmUHEuQKhPoSq
	41Dk6CM0oLa40pC6nz6okCHlFUzdiU4GqRwuyQjSwQxIK7lMAHj7MWDCcLhpLrlQ
	Z1ZUP8y6m7eZBFmE+2WuL6QgJmUdiP209s27ECKTxOAqSPaPaLlYmoymr+wsKb//
	dARexz4JJnYSSNJi/r1JY5x003P9DM6IR/MlNCpbvXaqG++6y+ovZNauD+rQPgJo
	eow=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 0E7A41C14178; Fri, 20 Apr 2012 17:23:08 +0200 (CEST)
Date: Fri, 20 Apr 2012 17:23:08 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120420152308.GC3720@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Dieter Bloms <xensource.com@bloms.de>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I'am not a programmer, but will have a look at it the next days and let
you know if my skills are good enough.

On Fri, Apr 20, Ian Campbell wrote:

> Hi Dieter, =

> =

> thanks for the report.
> =

> It seems that support for this config file variable is not present in xl
> at the moment. We should try and add this for 4.2 IMHO.
> =

> If you know a little bit of C (or are interested in learning) then this
> should be a pretty simple thing to implement -- please let me know if
> you want more details.
> =

> Ian.
> =

> On Fri, 2012-04-20 at 16:00 +0100, Dieter Bloms wrote:
> > Hi,
> > =

> > I've installed xen-unstable 4.2 from actual git (last commit was
> > 4dc7dbef5400f0608321d579aebb57f933e8f707).
> > =

> > When I start a domU with xm all is fine include the cpu_weight I
> > configured in my domU config.
> > =

> > When I start the domU with xl then all my domU have the default
> > cpu_weight of 256 instead of the configured one.
> > =

> > Was the name of cpu_weight being changed for xl command ?
> > =

> > My domU config looks like this:
> > =

> > --snip--
> > name=3D"vdrserver"
> > description=3D"vdrserver for my clients"
> > memory=3D768
> > maxmem=3D2048
> > vcpus=3D1
> > cpus=3D"1"
> > cpu_weight =3D 128
> > on_poweroff=3D"destroy"
> > on_reboot=3D"restart"
> > on_crash=3D"destroy"
> > =

> > localtime=3D0
> > keymap=3D"de"
> > =

> > builder=3D"linux"
> > bootloader=3D"/usr/bin/pygrub"
> > bootargs=3D""
> > extra=3D"console=3Dhvc0 tmem cgroup_disable=3Dmemory independent_wallcl=
ock=3D1 iommu=3Dsoft"
> > nographic=3D1
> > keymap =3D 'de'
> > =

> > disk=3D[ =

> >   'phy:/dev/mapper/xenimages-vdrserver,xvda1,w',
> >   'phy:/dev/mapper/xenimages-swap_vdrserver,xvda2,w',
> > ]
> > vif=3D[ 'mac=3D00:00:00:00:00:80,bridge=3Dbr0', ]
> > =

> > pci =3D [ '06:00.0', '06:01.0', '00:12.2', '00:13.2']
> > --snip--
> > =

> > =

> =

> =


-- =

Gru=DF

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIc-00036M-6U; Sat, 21 Apr 2012 21:56:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxle-0005Y1-Ek
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:15:50 +0000
Received: from [85.158.138.51:10080] by server-5.bemta-3.messagelabs.com id
	5D/B7-17113-572709F4; Thu, 19 Apr 2012 20:15:49 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334866544!22922786!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxNDUzMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4400 invoked from network); 19 Apr 2012 20:15:48 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:15:48 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 19:57:23 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 19:57:21 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK94xw1765618
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:09:04 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKFdN4030363
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:15:40 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFR1b030224; Fri, 20 Apr 2012 06:15:32 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:21 +0530
Message-Id: <20120419201518.5411.15215.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041909-9264-0000-0000-00000149C9B6
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 8/12] x86/pvticketlock: when
	paravirtualizing ticket locks, increment by 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Increment ticket head/tails by 2 rather than 1 to leave the LSB free
to store a "is in slowpath state" bit.  This halves the number
of possible CPUs for a given ticket size, but this shouldn't matter
in practice - kernels built for 32k+ CPU systems are probably
specially built for the hardware rather than a generic distro
kernel.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/spinlock.h       |   10 +++++-----
 arch/x86/include/asm/spinlock_types.h |   10 +++++++++-
 2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index ee4bbd4..60b7e83 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -81,7 +81,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
  */
 static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
 {
-	register struct __raw_tickets inc = { .tail = 1 };
+	register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC };
 
 	inc = xadd(&lock->tickets, inc);
 
@@ -107,7 +107,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 	if (old.tickets.head != old.tickets.tail)
 		return 0;
 
-	new.head_tail = old.head_tail + (1 << TICKET_SHIFT);
+	new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT);
 
 	/* cmpxchg is a full barrier, so nothing can move before it */
 	return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail;
@@ -115,9 +115,9 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 
 static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
 {
-	__ticket_t next = lock->tickets.head + 1;
+	__ticket_t next = lock->tickets.head + TICKET_LOCK_INC;
 
-	__add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX);
+	__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
 	__ticket_unlock_kick(lock, next);
 }
 
@@ -132,7 +132,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock)
 {
 	struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
 
-	return (__ticket_t)(tmp.tail - tmp.head) > 1;
+	return (__ticket_t)(tmp.tail - tmp.head) > TICKET_LOCK_INC;
 }
 #define arch_spin_is_contended	arch_spin_is_contended
 
diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h
index 83fd3c7..e96fcbd 100644
--- a/arch/x86/include/asm/spinlock_types.h
+++ b/arch/x86/include/asm/spinlock_types.h
@@ -3,7 +3,13 @@
 
 #include <linux/types.h>
 
-#if (CONFIG_NR_CPUS < 256)
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+#define __TICKET_LOCK_INC	2
+#else
+#define __TICKET_LOCK_INC	1
+#endif
+
+#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC))
 typedef u8  __ticket_t;
 typedef u16 __ticketpair_t;
 #else
@@ -11,6 +17,8 @@ typedef u16 __ticket_t;
 typedef u32 __ticketpair_t;
 #endif
 
+#define TICKET_LOCK_INC	((__ticket_t)__TICKET_LOCK_INC)
+
 #define TICKET_SHIFT	(sizeof(__ticket_t) * 8)
 
 typedef struct arch_spinlock {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIc-00036M-6U; Sat, 21 Apr 2012 21:56:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxle-0005Y1-Ek
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:15:50 +0000
Received: from [85.158.138.51:10080] by server-5.bemta-3.messagelabs.com id
	5D/B7-17113-572709F4; Thu, 19 Apr 2012 20:15:49 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1334866544!22922786!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxNDUzMzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4400 invoked from network); 19 Apr 2012 20:15:48 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:15:48 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 19:57:23 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 19:57:21 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK94xw1765618
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:09:04 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKFdN4030363
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:15:40 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFR1b030224; Fri, 20 Apr 2012 06:15:32 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:21 +0530
Message-Id: <20120419201518.5411.15215.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041909-9264-0000-0000-00000149C9B6
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 8/12] x86/pvticketlock: when
	paravirtualizing ticket locks, increment by 2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Increment ticket head/tails by 2 rather than 1 to leave the LSB free
to store a "is in slowpath state" bit.  This halves the number
of possible CPUs for a given ticket size, but this shouldn't matter
in practice - kernels built for 32k+ CPU systems are probably
specially built for the hardware rather than a generic distro
kernel.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/spinlock.h       |   10 +++++-----
 arch/x86/include/asm/spinlock_types.h |   10 +++++++++-
 2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index ee4bbd4..60b7e83 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -81,7 +81,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
  */
 static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
 {
-	register struct __raw_tickets inc = { .tail = 1 };
+	register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC };
 
 	inc = xadd(&lock->tickets, inc);
 
@@ -107,7 +107,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 	if (old.tickets.head != old.tickets.tail)
 		return 0;
 
-	new.head_tail = old.head_tail + (1 << TICKET_SHIFT);
+	new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT);
 
 	/* cmpxchg is a full barrier, so nothing can move before it */
 	return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail;
@@ -115,9 +115,9 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 
 static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
 {
-	__ticket_t next = lock->tickets.head + 1;
+	__ticket_t next = lock->tickets.head + TICKET_LOCK_INC;
 
-	__add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX);
+	__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
 	__ticket_unlock_kick(lock, next);
 }
 
@@ -132,7 +132,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock)
 {
 	struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
 
-	return (__ticket_t)(tmp.tail - tmp.head) > 1;
+	return (__ticket_t)(tmp.tail - tmp.head) > TICKET_LOCK_INC;
 }
 #define arch_spin_is_contended	arch_spin_is_contended
 
diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h
index 83fd3c7..e96fcbd 100644
--- a/arch/x86/include/asm/spinlock_types.h
+++ b/arch/x86/include/asm/spinlock_types.h
@@ -3,7 +3,13 @@
 
 #include <linux/types.h>
 
-#if (CONFIG_NR_CPUS < 256)
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+#define __TICKET_LOCK_INC	2
+#else
+#define __TICKET_LOCK_INC	1
+#endif
+
+#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC))
 typedef u8  __ticket_t;
 typedef u16 __ticketpair_t;
 #else
@@ -11,6 +17,8 @@ typedef u16 __ticket_t;
 typedef u32 __ticketpair_t;
 #endif
 
+#define TICKET_LOCK_INC	((__ticket_t)__TICKET_LOCK_INC)
+
 #define TICKET_SHIFT	(sizeof(__ticket_t) * 8)
 
 typedef struct arch_spinlock {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIc-00036c-K1; Sat, 21 Apr 2012 21:56:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxm3-0005Yc-V1
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:16:16 +0000
Received: from [85.158.139.83:63499] by server-6.bemta-5.messagelabs.com id
	FE/5E-13222-F82709F4; Thu, 19 Apr 2012 20:16:15 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334866570!24092126!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiAxMjgxMjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8384 invoked from network); 19 Apr 2012 20:16:13 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:16:13 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:13:29 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:13:26 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK9UYn1630436
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:09:30 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKG4JV015959
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:16:06 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFqYX015686; Fri, 20 Apr 2012 06:15:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:46 +0530
Message-Id: <20120419201543.5411.37767.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-5140-0000-0000-0000011AEB6C
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 9/12] split out rate limiting from
	jump_label.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andrew Jones <drjones@redhat.com>

Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting
for jump label disabling. The changes were made in the jump label code
in order to be more widely available and to keep things tidier. This is
all fine, except now jump_label.h includes linux/workqueue.h, which
makes it impossible to include jump_label.h from anything that
workqueue.h needs. For example, it's now impossible to include
jump_label.h from asm/spinlock.h, which is done in proposed
pv-ticketlock patches. This patch splits out the rate limiting related
changes from jump_label.h into a new file, jump_label_ratelimit.h, to
resolve the issue.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 include/linux/jump_label.h           |   26 +-------------------------
 include/linux/jump_label_ratelimit.h |   34 ++++++++++++++++++++++++++++++++++
 include/linux/perf_event.h           |    1 +
 kernel/jump_label.c                  |    1 +
 4 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index c513a40..8195227 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -49,7 +49,6 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
-#include <linux/workqueue.h>
 
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 
@@ -62,12 +61,6 @@ struct static_key {
 #endif
 };
 
-struct static_key_deferred {
-	struct static_key key;
-	unsigned long timeout;
-	struct delayed_work work;
-};
-
 # include <asm/jump_label.h>
 # define HAVE_JUMP_LABEL
 #endif	/* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry,
 extern int jump_label_text_reserved(void *start, void *end);
 extern void static_key_slow_inc(struct static_key *key);
 extern void static_key_slow_dec(struct static_key *key);
-extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
 extern void jump_label_apply_nops(struct module *mod);
-extern void
-jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
 
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 	{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
@@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void)
 {
 }
 
-struct static_key_deferred {
-	struct static_key  key;
-};
-
 static __always_inline bool static_key_false(struct static_key *key)
 {
 	if (unlikely(atomic_read(&key->enabled)) > 0)
@@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key)
 	atomic_dec(&key->enabled);
 }
 
-static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
-{
-	static_key_slow_dec(&key->key);
-}
-
 static inline int jump_label_text_reserved(void *start, void *end)
 {
 	return 0;
@@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 	return 0;
 }
 
-static inline void
-jump_label_rate_limit(struct static_key_deferred *key,
-		unsigned long rl)
-{
-}
-
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 		{ .enabled = ATOMIC_INIT(1) })
 #define STATIC_KEY_INIT_FALSE ((struct static_key) \
@@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key,
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
+static inline int atomic_read(const atomic_t *v);
 static inline bool static_key_enabled(struct static_key *key)
 {
 	return (atomic_read(&key->enabled) > 0);
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
new file mode 100644
index 0000000..1137883
--- /dev/null
+++ b/include/linux/jump_label_ratelimit.h
@@ -0,0 +1,34 @@
+#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H
+#define _LINUX_JUMP_LABEL_RATELIMIT_H
+
+#include <linux/jump_label.h>
+#include <linux/workqueue.h>
+
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+struct static_key_deferred {
+	struct static_key key;
+	unsigned long timeout;
+	struct delayed_work work;
+};
+#endif
+
+#ifdef HAVE_JUMP_LABEL
+extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void
+jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
+
+#else	/* !HAVE_JUMP_LABEL */
+struct static_key_deferred {
+	struct static_key  key;
+};
+static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
+{
+	static_key_slow_dec(&key->key);
+}
+static inline void
+jump_label_rate_limit(struct static_key_deferred *key,
+		unsigned long rl)
+{
+}
+#endif	/* HAVE_JUMP_LABEL */
+#endif	/* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index ddbb6a9..a0e6118 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -605,6 +605,7 @@ struct perf_guest_info_callbacks {
 #include <linux/cpu.h>
 #include <linux/irq_work.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 #include <linux/atomic.h>
 #include <linux/sysfs.h>
 #include <asm/local.h>
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 4304919..e17f8d6 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -13,6 +13,7 @@
 #include <linux/sort.h>
 #include <linux/err.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 
 #ifdef HAVE_JUMP_LABEL
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIc-00036c-K1; Sat, 21 Apr 2012 21:56:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxm3-0005Yc-V1
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:16:16 +0000
Received: from [85.158.139.83:63499] by server-6.bemta-5.messagelabs.com id
	FE/5E-13222-F82709F4; Thu, 19 Apr 2012 20:16:15 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1334866570!24092126!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiAxMjgxMjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8384 invoked from network); 19 Apr 2012 20:16:13 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:16:13 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:13:29 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:13:26 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK9UYn1630436
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:09:30 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKG4JV015959
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:16:06 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFqYX015686; Fri, 20 Apr 2012 06:15:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:46 +0530
Message-Id: <20120419201543.5411.37767.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-5140-0000-0000-0000011AEB6C
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 9/12] split out rate limiting from
	jump_label.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andrew Jones <drjones@redhat.com>

Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting
for jump label disabling. The changes were made in the jump label code
in order to be more widely available and to keep things tidier. This is
all fine, except now jump_label.h includes linux/workqueue.h, which
makes it impossible to include jump_label.h from anything that
workqueue.h needs. For example, it's now impossible to include
jump_label.h from asm/spinlock.h, which is done in proposed
pv-ticketlock patches. This patch splits out the rate limiting related
changes from jump_label.h into a new file, jump_label_ratelimit.h, to
resolve the issue.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 include/linux/jump_label.h           |   26 +-------------------------
 include/linux/jump_label_ratelimit.h |   34 ++++++++++++++++++++++++++++++++++
 include/linux/perf_event.h           |    1 +
 kernel/jump_label.c                  |    1 +
 4 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index c513a40..8195227 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -49,7 +49,6 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
-#include <linux/workqueue.h>
 
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 
@@ -62,12 +61,6 @@ struct static_key {
 #endif
 };
 
-struct static_key_deferred {
-	struct static_key key;
-	unsigned long timeout;
-	struct delayed_work work;
-};
-
 # include <asm/jump_label.h>
 # define HAVE_JUMP_LABEL
 #endif	/* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry,
 extern int jump_label_text_reserved(void *start, void *end);
 extern void static_key_slow_inc(struct static_key *key);
 extern void static_key_slow_dec(struct static_key *key);
-extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
 extern void jump_label_apply_nops(struct module *mod);
-extern void
-jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
 
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 	{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
@@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void)
 {
 }
 
-struct static_key_deferred {
-	struct static_key  key;
-};
-
 static __always_inline bool static_key_false(struct static_key *key)
 {
 	if (unlikely(atomic_read(&key->enabled)) > 0)
@@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key)
 	atomic_dec(&key->enabled);
 }
 
-static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
-{
-	static_key_slow_dec(&key->key);
-}
-
 static inline int jump_label_text_reserved(void *start, void *end)
 {
 	return 0;
@@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 	return 0;
 }
 
-static inline void
-jump_label_rate_limit(struct static_key_deferred *key,
-		unsigned long rl)
-{
-}
-
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 		{ .enabled = ATOMIC_INIT(1) })
 #define STATIC_KEY_INIT_FALSE ((struct static_key) \
@@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key,
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
+static inline int atomic_read(const atomic_t *v);
 static inline bool static_key_enabled(struct static_key *key)
 {
 	return (atomic_read(&key->enabled) > 0);
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
new file mode 100644
index 0000000..1137883
--- /dev/null
+++ b/include/linux/jump_label_ratelimit.h
@@ -0,0 +1,34 @@
+#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H
+#define _LINUX_JUMP_LABEL_RATELIMIT_H
+
+#include <linux/jump_label.h>
+#include <linux/workqueue.h>
+
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+struct static_key_deferred {
+	struct static_key key;
+	unsigned long timeout;
+	struct delayed_work work;
+};
+#endif
+
+#ifdef HAVE_JUMP_LABEL
+extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void
+jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
+
+#else	/* !HAVE_JUMP_LABEL */
+struct static_key_deferred {
+	struct static_key  key;
+};
+static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
+{
+	static_key_slow_dec(&key->key);
+}
+static inline void
+jump_label_rate_limit(struct static_key_deferred *key,
+		unsigned long rl)
+{
+}
+#endif	/* HAVE_JUMP_LABEL */
+#endif	/* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index ddbb6a9..a0e6118 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -605,6 +605,7 @@ struct perf_guest_info_callbacks {
 #include <linux/cpu.h>
 #include <linux/irq_work.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 #include <linux/atomic.h>
 #include <linux/sysfs.h>
 #include <asm/local.h>
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 4304919..e17f8d6 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -13,6 +13,7 @@
 #include <linux/sort.h>
 #include <linux/err.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 
 #ifdef HAVE_JUMP_LABEL
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIb-00035h-Ep; Sat, 21 Apr 2012 21:56:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxkt-0005WN-Dt
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:15:03 +0000
Received: from [85.158.143.99:20735] by server-1.bemta-4.messagelabs.com id
	E7/DA-20925-642709F4; Thu, 19 Apr 2012 20:15:02 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334866498!24374799!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAxNzQ3Nzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6856 invoked from network); 19 Apr 2012 20:15:01 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:15:01 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:44:57 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:44:54 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKEsQi4534406
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:44:54 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1jLnn021170
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 11:45:23 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1jEp1020775; Fri, 20 Apr 2012 11:45:19 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:44:39 +0530
Message-Id: <20120419201435.5411.86444.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-4790-0000-0000-00000242AC7F
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 6/12] xen/pvticketlocks: add xen_nopvspin
	parameter to disable xen pv ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/spinlock.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 982e64b..c9bf890 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -223,12 +223,26 @@ void xen_uninit_lock_cpu(int cpu)
 	unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
 }
 
+static bool xen_pvspin __initdata = true;
+
 void __init xen_init_spinlocks(void)
 {
+	if (!xen_pvspin) {
+		printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
+		return;
+	}
+
 	pv_lock_ops.lock_spinning = xen_lock_spinning;
 	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }
 
+static __init int xen_parse_nopvspin(char *arg)
+{
+	xen_pvspin = false;
+	return 0;
+}
+early_param("xen_nopvspin", xen_parse_nopvspin);
+
 #ifdef CONFIG_XEN_DEBUG_FS
 
 static struct dentry *d_spin_debug;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIe-00038A-8A; Sat, 21 Apr 2012 21:57:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxnB-0005Zz-7u
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:17:25 +0000
Received: from [85.158.143.99:46675] by server-3.bemta-4.messagelabs.com id
	B5/5D-05853-4D2709F4; Thu, 19 Apr 2012 20:17:24 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334866640!14658525!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzgyODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12149 invoked from network); 19 Apr 2012 20:17:22 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:17:22 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:47:19 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:47:16 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKHF7e4587636
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:47:15 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1l2fU018772
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 11:47:03 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1ksuE018395; Fri, 20 Apr 2012 11:46:59 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:47:00 +0530
Message-Id: <20120419201656.5411.94590.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-9574-0000-0000-000002458E71
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 12/12] xen: enable PV ticketlocks on HVM
	Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/smp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 9ac931b..2192f76 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -574,4 +574,5 @@ void __init xen_hvm_smp_init(void)
 	smp_ops.cpu_die = xen_hvm_cpu_die;
 	smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
 	smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi;
+	xen_init_spinlocks();
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIZ-00034k-Pg; Sat, 21 Apr 2012 21:56:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxjL-0005RT-RS
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:13:28 +0000
Received: from [85.158.143.99:9247] by server-2.bemta-4.messagelabs.com id
	E7/DF-17550-7E1709F4; Thu, 19 Apr 2012 20:13:27 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1334866402!19153561!1
X-Originating-IP: [202.81.31.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNjU4NDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16481 invoked from network); 19 Apr 2012 20:13:25 -0000
Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:13:25 -0000
Received: from /spool/local
	by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:05:37 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:05:35 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK6h9l1310796
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:06:43 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKDHAA011543
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:13:19 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKD5KH011319; Fri, 20 Apr 2012 06:13:11 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:42:59 +0530
Message-Id: <20120419201256.5411.59675.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-1618-0000-0000-00000158B471
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 2/12] x86/ticketlock: don't inline
	_spin_unlock when using paravirt spinlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 

The code size expands somewhat, and its better to just call
a function rather than inline it.

Thanks Jeremy for original version of ARCH_NOINLINE_SPIN_UNLOCK config patch, 
which is simplified.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1d14cc6..35eb2e4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -597,6 +597,7 @@ config PARAVIRT
 config PARAVIRT_SPINLOCKS
 	bool "Paravirtualization layer for spinlocks"
 	depends on PARAVIRT && SMP && EXPERIMENTAL
+	select UNINLINE_SPIN_UNLOCK
 	---help---
 	  Paravirtualized spinlocks allow a pvops backend to replace the
 	  spinlock implementation with something virtualization-friendly


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIe-00038A-8A; Sat, 21 Apr 2012 21:57:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxnB-0005Zz-7u
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:17:25 +0000
Received: from [85.158.143.99:46675] by server-3.bemta-4.messagelabs.com id
	B5/5D-05853-4D2709F4; Thu, 19 Apr 2012 20:17:24 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1334866640!14658525!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzgyODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12149 invoked from network); 19 Apr 2012 20:17:22 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:17:22 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:47:19 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:47:16 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKHF7e4587636
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:47:15 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1l2fU018772
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 11:47:03 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1ksuE018395; Fri, 20 Apr 2012 11:46:59 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:47:00 +0530
Message-Id: <20120419201656.5411.94590.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-9574-0000-0000-000002458E71
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 12/12] xen: enable PV ticketlocks on HVM
	Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/smp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 9ac931b..2192f76 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -574,4 +574,5 @@ void __init xen_hvm_smp_init(void)
 	smp_ops.cpu_die = xen_hvm_cpu_die;
 	smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
 	smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi;
+	xen_init_spinlocks();
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIf-00039X-Fc; Sat, 21 Apr 2012 21:57:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SLXoV-0007Td-G1
	for xen-devel@lists.xensource.com; Sat, 21 Apr 2012 10:45:11 +0000
Received: from [193.109.254.147:3429] by server-4.bemta-14.messagelabs.com id
	B5/C9-11570-3BF829F4; Sat, 21 Apr 2012 10:45:07 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335005105!5678861!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3329 invoked from network); 21 Apr 2012 10:45:05 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-3.tower-27.messagelabs.com with SMTP;
	21 Apr 2012 10:45:05 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id B080CC0F0BA;
	Sat, 21 Apr 2012 12:45:04 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id sJ+AH25ru-if; Sat, 21 Apr 2012 12:45:04 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Sat, 21 Apr 2012 12:45:04 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 567CD49C222;
	Sat, 21 Apr 2012 11:45:04 +0100 (BST)
Date: Sat, 21 Apr 2012 12:45:02 +0200
From: Borislav Petkov <bp@amd64.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120421104502.GB17005@aftab.osrc.amd.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120421041454.GA29704@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:53 +0000
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	bp@amd64.org, tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

+ x86 people.

On Sat, Apr 21, 2012 at 12:14:54AM -0400, Konrad Rzeszutek Wilk wrote:
> Should this driver reside in arch/x86/kernel/cpu/mcheck?

The fact that you raise such a question is already loaded with problems,
see below.

> I can keep it in drivers/xen, but I realized that perhaps it
> should be in a different location?
> > 
> > When MCA error occurs, it would be handled by xen hypervisor first,
> > and then the error information would be sent to dom0 for logging.
> > 
> > This patch gets error information from xen hypervisor and convert
> > xen format error into linux format mcelog. This logic is basically
> > self-contained, not much touching other kernel components.

I have a problem with that statement above. This thing uses struct mce
and mce_log(), which are internal to x86, and whenever we want to change
anything there, we won't be able to because xen uses it too.

And this has happened already with the whole microcode loading debacle.

So, my suggestion is to copy the pieces you need and create your own xen
version of /dev/mcelog and add it to dom0 so that there's no hooking
into baremetal code and whenever a dom0 kernel is running, you can
reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
and not hook into the x86 versions.

Because, if you'd hooked into it, just imagine one fine day, when we
remove mcelog support, what screaming the xen people will be doing when
mcelog doesn't work anymore.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIb-00035h-Ep; Sat, 21 Apr 2012 21:56:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxkt-0005WN-Dt
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:15:03 +0000
Received: from [85.158.143.99:20735] by server-1.bemta-4.messagelabs.com id
	E7/DA-20925-642709F4; Thu, 19 Apr 2012 20:15:02 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1334866498!24374799!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAxNzQ3Nzk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6856 invoked from network); 19 Apr 2012 20:15:01 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:15:01 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:44:57 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:44:54 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKEsQi4534406
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:44:54 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1jLnn021170
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 11:45:23 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1jEp1020775; Fri, 20 Apr 2012 11:45:19 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:44:39 +0530
Message-Id: <20120419201435.5411.86444.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-4790-0000-0000-00000242AC7F
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 6/12] xen/pvticketlocks: add xen_nopvspin
	parameter to disable xen pv ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/spinlock.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 982e64b..c9bf890 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -223,12 +223,26 @@ void xen_uninit_lock_cpu(int cpu)
 	unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
 }
 
+static bool xen_pvspin __initdata = true;
+
 void __init xen_init_spinlocks(void)
 {
+	if (!xen_pvspin) {
+		printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
+		return;
+	}
+
 	pv_lock_ops.lock_spinning = xen_lock_spinning;
 	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }
 
+static __init int xen_parse_nopvspin(char *arg)
+{
+	xen_pvspin = false;
+	return 0;
+}
+early_param("xen_nopvspin", xen_parse_nopvspin);
+
 #ifdef CONFIG_XEN_DEBUG_FS
 
 static struct dentry *d_spin_debug;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIY-00033w-4F; Sat, 21 Apr 2012 21:56:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <lth@cow.dk>)
	id 1SKRjm-0001EL-DF
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 10:03:46 +0000
Received: from [85.158.138.51:53093] by server-5.bemta-3.messagelabs.com id
	C6/E6-17113-1819E8F4; Wed, 18 Apr 2012 10:03:45 +0000
X-Env-Sender: lth@cow.dk
X-Msg-Ref: server-16.tower-174.messagelabs.com!1334743423!22521993!1
X-Originating-IP: [95.166.183.192]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17390 invoked from network); 18 Apr 2012 10:03:44 -0000
Received: from 4607ds7-vby.0.fullrate.dk (HELO cow.netcompartner.com)
	(95.166.183.192)
	by server-16.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Apr 2012 10:03:44 -0000
Received: from [175.136.158.155] (helo=ncpws04.localnet)
	by cow.netcompartner.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77)
	(envelope-from <lth@cow.dk>)
	id 1SKRj7-0004sq-K2; Wed, 18 Apr 2012 12:03:06 +0200
From: Lars Boegild Thomsen <lth@cow.dk>
Organization: Call of the Wild BBS
To: Jonathan Nieder <jrnieder@gmail.com>
Date: Wed, 18 Apr 2012 18:03:00 +0800
User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; )
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<201204161905.13260.bugs@humanleg.org.uk>
	<20120417020433.GA15848@burratino>
In-Reply-To: <20120417020433.GA15848@burratino>
MIME-Version: 1.0
Message-Id: <201204181803.00383.lth@cow.dk>
X-Spam-Score: -2.9 (--)
X-Spam-Report: Spam detection software,
	running on the system "cow.netcompartner.com", has
	identified this incoming email as possible spam. The original message
	has been attached to this so you can view it (if it isn't spam) or
	label similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview: On Tuesday 17 April 2012 10:04:33 Jonathan Nieder
	wrote: >
	> Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid. > Alas.
	Does suspend-to-disk ("echo disk >/sys/power/state") have the > same
	problem?
	Can you get a log of the failure with > "no_console_suspend" appended
	to the kernel command line,
	for example > with a serial console or netconsole? [...] 
	Content analysis details:   (-2.9 points, 5.0 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
	[score: 0.0000]
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:53 +0000
Cc: Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Robert Scott <bugs@humanleg.org.uk>, hpa@zytor.com,
	linux-kernel@vger.kernel.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>, mingo@redhat.com,
	Fengzhe Zhang <fengzhe.zhang@intel.com>,
	e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
	suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 17 April 2012 10:04:33 Jonathan Nieder wrote:
> > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.
> Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
> same problem?  Can you get a log of the failure with
> "no_console_suspend" appended to the kernel command line, for example
> with a serial console or netconsole?

Using a serial console is a bit of a problem on this netbook as it hasn't got 
a serial port.  Not sure how the netconsole works - will read up on that.

And no - suspend to disk works fine.

I have by the way experimentally switched to 32bit version and it's the same 
thing (originally I was running 64bit version but that really doesn't make 
sense on a netbook - except doing it because it could be done).

//Lars...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIa-00035A-KL; Sat, 21 Apr 2012 21:56:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxk7-0005U5-VN
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:14:16 +0000
Received: from [193.109.254.147:35145] by server-10.bemta-14.messagelabs.com
	id 41/43-05847-712709F4; Thu, 19 Apr 2012 20:14:15 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334866451!5446762!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNDU0NDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21985 invoked from network); 19 Apr 2012 20:14:14 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:14:14 -0000
Received: from /spool/local
	by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 19:56:26 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 19:56:23 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK7Uot1204408
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:07:30 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKE4JX024634
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:14:06 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKDruf024548; Fri, 20 Apr 2012 06:13:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:43:47 +0530
Message-Id: <20120419201343.5411.77666.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041909-5490-0000-0000-0000012F031A
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 4/12] xen: defer spinlock setup until
	boot CPU setup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

There's no need to do it at very early init, and doing it there
makes it impossible to use the jump_label machinery.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/smp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..9ac931b 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -207,6 +207,7 @@ static void __init xen_smp_prepare_boot_cpu(void)
 
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
+	xen_init_spinlocks();
 }
 
 static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
@@ -536,7 +537,6 @@ void __init xen_smp_init(void)
 {
 	smp_ops = xen_smp_ops;
 	xen_fill_possible_map();
-	xen_init_spinlocks();
 }
 
 static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIZ-00034Z-DD; Sat, 21 Apr 2012 21:56:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxjE-0005R1-L6
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:13:21 +0000
Received: from [85.158.139.83:44171] by server-6.bemta-5.messagelabs.com id
	B3/AB-13222-FD1709F4; Thu, 19 Apr 2012 20:13:19 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334866394!24623196!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNDU0NDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24023 invoked from network); 19 Apr 2012 20:13:18 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:13:18 -0000
Received: from /spool/local
	by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 19:55:24 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 19:55:11 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK6Hl22277474
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:06:17 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKCpmS028142
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:12:53 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKCeBN028070; Fri, 20 Apr 2012 06:12:45 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:42:33 +0530
Message-Id: <20120419201231.5411.98124.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041909-5490-0000-0000-0000012F02DC
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 1/12] x86/spinlock: replace pv spinlocks
	with pv ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Rather than outright replacing the entire spinlock implementation in
order to paravirtualize it, keep the ticket lock implementation but add
a couple of pvops hooks on the slow patch (long spin on lock, unlocking
a contended lock).

Ticket locks have a number of nice properties, but they also have some
surprising behaviours in virtual environments.  They enforce a strict
FIFO ordering on cpus trying to take a lock; however, if the hypervisor
scheduler does not schedule the cpus in the correct order, the system can
waste a huge amount of time spinning until the next cpu can take the lock.

(See Thomas Friebel's talk "Prevent Guests from Spinning Around"
http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)

To address this, we add two hooks:
 - __ticket_spin_lock which is called after the cpu has been
   spinning on the lock for a significant number of iterations but has
   failed to take the lock (presumably because the cpu holding the lock
   has been descheduled).  The lock_spinning pvop is expected to block
   the cpu until it has been kicked by the current lock holder.
 - __ticket_spin_unlock, which on releasing a contended lock
   (there are more cpus with tail tickets), it looks to see if the next
   cpu is blocked and wakes it if so.

When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub
functions causes all the extra code to go away.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/paravirt.h       |   32 ++++----------------
 arch/x86/include/asm/paravirt_types.h |   10 ++----
 arch/x86/include/asm/spinlock.h       |   53 ++++++++++++++++++++++++++------
 arch/x86/include/asm/spinlock_types.h |    4 --
 arch/x86/kernel/paravirt-spinlocks.c  |   15 +--------
 arch/x86/xen/spinlock.c               |    8 ++++-
 6 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index aa0f913..4bcd146 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -751,36 +751,16 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 
 #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
 
-static inline int arch_spin_is_locked(struct arch_spinlock *lock)
+static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
+							__ticket_t ticket)
 {
-	return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock);
+	PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket);
 }
 
-static inline int arch_spin_is_contended(struct arch_spinlock *lock)
+static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
+							__ticket_t ticket)
 {
-	return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock);
-}
-#define arch_spin_is_contended	arch_spin_is_contended
-
-static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
-{
-	PVOP_VCALL1(pv_lock_ops.spin_lock, lock);
-}
-
-static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock,
-						  unsigned long flags)
-{
-	PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags);
-}
-
-static __always_inline int arch_spin_trylock(struct arch_spinlock *lock)
-{
-	return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock);
-}
-
-static __always_inline void arch_spin_unlock(struct arch_spinlock *lock)
-{
-	PVOP_VCALL1(pv_lock_ops.spin_unlock, lock);
+	PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
 }
 
 #endif
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..005e24d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -327,13 +327,11 @@ struct pv_mmu_ops {
 };
 
 struct arch_spinlock;
+#include <asm/spinlock_types.h>
+
 struct pv_lock_ops {
-	int (*spin_is_locked)(struct arch_spinlock *lock);
-	int (*spin_is_contended)(struct arch_spinlock *lock);
-	void (*spin_lock)(struct arch_spinlock *lock);
-	void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long flags);
-	int (*spin_trylock)(struct arch_spinlock *lock);
-	void (*spin_unlock)(struct arch_spinlock *lock);
+	void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket);
+	void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
 };
 
 /* This contains all the paravirt structures: we get a convenient
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 76bfa2c..3e47608 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -37,6 +37,35 @@
 # define UNLOCK_LOCK_PREFIX
 #endif
 
+/* How long a lock should spin before we consider blocking */
+#define SPIN_THRESHOLD	(1 << 11)
+
+#ifndef CONFIG_PARAVIRT_SPINLOCKS
+
+static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
+							__ticket_t ticket)
+{
+}
+
+static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
+							 __ticket_t ticket)
+{
+}
+
+#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
+
+
+/*
+ * If a spinlock has someone waiting on it, then kick the appropriate
+ * waiting cpu.
+ */
+static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
+							__ticket_t next)
+{
+	if (unlikely(lock->tickets.tail != next))
+		____ticket_unlock_kick(lock, next);
+}
+
 /*
  * Ticket locks are conceptually two parts, one indicating the current head of
  * the queue, and the other indicating the current tail. The lock is acquired
@@ -50,19 +79,24 @@
  * in the high part, because a wide xadd increment of the low part would carry
  * up and contaminate the high part.
  */
-static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock)
+static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock)
 {
 	register struct __raw_tickets inc = { .tail = 1 };
 
 	inc = xadd(&lock->tickets, inc);
 
 	for (;;) {
-		if (inc.head == inc.tail)
-			break;
-		cpu_relax();
-		inc.head = ACCESS_ONCE(lock->tickets.head);
+		unsigned count = SPIN_THRESHOLD;
+
+		do {
+			if (inc.head == inc.tail)
+				goto out;
+			cpu_relax();
+			inc.head = ACCESS_ONCE(lock->tickets.head);
+		} while (--count);
+		__ticket_lock_spinning(lock, inc.tail);
 	}
-	barrier();		/* make sure nothing creeps before the lock is taken */
+out:	barrier();	/* make sure nothing creeps before the lock is taken */
 }
 
 static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
@@ -81,7 +115,10 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
 
 static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
 {
+	__ticket_t next = lock->tickets.head + 1;
+
 	__add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX);
+	__ticket_unlock_kick(lock, next);
 }
 
 static inline int __ticket_spin_is_locked(arch_spinlock_t *lock)
@@ -98,8 +135,6 @@ static inline int __ticket_spin_is_contended(arch_spinlock_t *lock)
 	return (__ticket_t)(tmp.tail - tmp.head) > 1;
 }
 
-#ifndef CONFIG_PARAVIRT_SPINLOCKS
-
 static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 {
 	return __ticket_spin_is_locked(lock);
@@ -132,8 +167,6 @@ static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock,
 	arch_spin_lock(lock);
 }
 
-#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
-
 static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
 {
 	while (arch_spin_is_locked(lock))
diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h
index ad0ad07..83fd3c7 100644
--- a/arch/x86/include/asm/spinlock_types.h
+++ b/arch/x86/include/asm/spinlock_types.h
@@ -1,10 +1,6 @@
 #ifndef _ASM_X86_SPINLOCK_TYPES_H
 #define _ASM_X86_SPINLOCK_TYPES_H
 
-#ifndef __LINUX_SPINLOCK_TYPES_H
-# error "please don't include this file directly"
-#endif
-
 #include <linux/types.h>
 
 #if (CONFIG_NR_CPUS < 256)
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 676b8c7..c2e010e 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -7,21 +7,10 @@
 
 #include <asm/paravirt.h>
 
-static inline void
-default_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags)
-{
-	arch_spin_lock(lock);
-}
-
 struct pv_lock_ops pv_lock_ops = {
 #ifdef CONFIG_SMP
-	.spin_is_locked = __ticket_spin_is_locked,
-	.spin_is_contended = __ticket_spin_is_contended,
-
-	.spin_lock = __ticket_spin_lock,
-	.spin_lock_flags = default_spin_lock_flags,
-	.spin_trylock = __ticket_spin_trylock,
-	.spin_unlock = __ticket_spin_unlock,
+	.lock_spinning = paravirt_nop,
+	.unlock_kick = paravirt_nop,
 #endif
 };
 EXPORT_SYMBOL(pv_lock_ops);
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 00461a4..f1f4540 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -138,6 +138,9 @@ struct xen_spinlock {
 	xen_spinners_t spinners;	/* count of waiting cpus */
 };
 
+static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
+
+#if 0
 static int xen_spin_is_locked(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
@@ -165,7 +168,6 @@ static int xen_spin_trylock(struct arch_spinlock *lock)
 	return old == 0;
 }
 
-static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
 static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
 
 /*
@@ -353,6 +355,7 @@ static void xen_spin_unlock(struct arch_spinlock *lock)
 	if (unlikely(xl->spinners))
 		xen_spin_unlock_slow(xl);
 }
+#endif
 
 static irqreturn_t dummy_handler(int irq, void *dev_id)
 {
@@ -389,13 +392,14 @@ void xen_uninit_lock_cpu(int cpu)
 void __init xen_init_spinlocks(void)
 {
 	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
-
+#if 0
 	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
 	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
 	pv_lock_ops.spin_lock = xen_spin_lock;
 	pv_lock_ops.spin_lock_flags = xen_spin_lock_flags;
 	pv_lock_ops.spin_trylock = xen_spin_trylock;
 	pv_lock_ops.spin_unlock = xen_spin_unlock;
+#endif
 }
 
 #ifdef CONFIG_XEN_DEBUG_FS


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiId-00037L-Eb; Sat, 21 Apr 2012 21:56:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxmR-0005ZE-Ni
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:16:40 +0000
Received: from [85.158.138.51:12736] by server-2.bemta-3.messagelabs.com id
	50/A1-09269-6A2709F4; Thu, 19 Apr 2012 20:16:38 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334866594!18576326!1
X-Originating-IP: [122.248.162.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMiA9PiAxNzcxOTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3653 invoked from network); 19 Apr 2012 20:16:37 -0000
Received: from e28smtp02.in.ibm.com (HELO e28smtp02.in.ibm.com) (122.248.162.2)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:16:37 -0000
Received: from /spool/local
	by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:46:33 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:46:30 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKGTxP4542572
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:46:29 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1k8b1018510
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 07:16:11 +0530
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1k0sn018139; Fri, 20 Apr 2012 07:16:05 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:46:12 +0530
Message-Id: <20120419201609.5411.66223.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-5816-0000-0000-000002348EA9
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 10/12] x86/ticketlock: add slowpath logic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Maintain a flag in the LSB of the ticket lock tail which indicates
whether anyone is in the lock slowpath and may need kicking when
the current holder unlocks.  The flags are set when the first locker
enters the slowpath, and cleared when unlocking to an empty queue (ie,
no contention).

In the specific implementation of lock_spinning(), make sure to set
the slowpath flags on the lock just before blocking.  We must do
this before the last-chance pickup test to prevent a deadlock
with the unlocker:

Unlocker			Locker
				test for lock pickup
					-> fail
unlock
test slowpath
	-> false
				set slowpath flags
				block

Whereas this works in any ordering:

Unlocker			Locker
				set slowpath flags
				test for lock pickup
					-> fail
				block
unlock
test slowpath
	-> true, kick

If the unlocker finds that the lock has the slowpath flag set but it is
actually uncontended (ie, head == tail, so nobody is waiting), then it
clears the slowpath flag.

The unlock code uses a locked add to update the head counter.  This also
acts as a full memory barrier so that its safe to subsequently
read back the slowflag state, knowing that the updated lock is visible
to the other CPUs.  If it were an unlocked add, then the flag read may
just be forwarded from the store buffer before it was visible to the other
CPUs, which could result in a deadlock.

Unfortunately this means we need to do a locked instruction when
unlocking with PV ticketlocks.  However, if PV ticketlocks are not
enabled, then the old non-locked "add" is the only unlocking code.

Note: this code relies on gcc making sure that unlikely() code is out of
line of the fastpath, which only happens when OPTIMIZE_SIZE=n.  If it
doesn't the generated code isn't too bad, but its definitely suboptimal.

Thanks to Srivatsa Vaddagiri for providing a bugfix to the original
version of this change, which has been folded in.
Thanks to Stephan Diestelhorst for commenting on some code which relied
on an inaccurate reading of the x86 memory ordering rules.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/paravirt.h       |    2 +-
 arch/x86/include/asm/spinlock.h       |   86 +++++++++++++++++++++++---------
 arch/x86/include/asm/spinlock_types.h |    2 +
 arch/x86/kernel/paravirt-spinlocks.c  |    3 +
 arch/x86/xen/spinlock.c               |    6 ++
 5 files changed, 74 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 9769096..af49670 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -757,7 +757,7 @@ static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
 	PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
 }
 
-static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
+static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
 							__ticket_t ticket)
 {
 	PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 60b7e83..e6881fd 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -1,11 +1,14 @@
 #ifndef _ASM_X86_SPINLOCK_H
 #define _ASM_X86_SPINLOCK_H
 
+#include <linux/jump_label.h>
 #include <linux/atomic.h>
 #include <asm/page.h>
 #include <asm/processor.h>
 #include <linux/compiler.h>
 #include <asm/paravirt.h>
+#include <asm/bitops.h>
+
 /*
  * Your basic SMP spinlocks, allowing only a single CPU anywhere
  *
@@ -40,32 +43,28 @@
 /* How long a lock should spin before we consider blocking */
 #define SPIN_THRESHOLD	(1 << 11)
 
-#ifndef CONFIG_PARAVIRT_SPINLOCKS
+extern struct static_key paravirt_ticketlocks_enabled;
+static __always_inline bool static_key_false(struct static_key *key);
 
-static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
-							__ticket_t ticket)
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
 {
+	set_bit(0, (volatile unsigned long *)&lock->tickets.tail);
 }
 
-static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
-							 __ticket_t ticket)
+#else  /* !CONFIG_PARAVIRT_SPINLOCKS */
+static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock,
+							__ticket_t ticket)
 {
 }
-
-#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
-
-
-/*
- * If a spinlock has someone waiting on it, then kick the appropriate
- * waiting cpu.
- */
-static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
-							__ticket_t next)
+static inline void __ticket_unlock_kick(arch_spinlock_t *lock,
+							__ticket_t ticket)
 {
-	if (unlikely(lock->tickets.tail != next))
-		____ticket_unlock_kick(lock, next);
 }
 
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
 /*
  * Ticket locks are conceptually two parts, one indicating the current head of
  * the queue, and the other indicating the current tail. The lock is acquired
@@ -79,20 +78,22 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
  * in the high part, because a wide xadd increment of the low part would carry
  * up and contaminate the high part.
  */
-static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
+static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
 {
 	register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC };
 
 	inc = xadd(&lock->tickets, inc);
+	if (likely(inc.head == inc.tail))
+		goto out;
 
+	inc.tail &= ~TICKET_SLOWPATH_FLAG;
 	for (;;) {
 		unsigned count = SPIN_THRESHOLD;
 
 		do {
-			if (inc.head == inc.tail)
+			if (ACCESS_ONCE(lock->tickets.head) == inc.tail)
 				goto out;
 			cpu_relax();
-			inc.head = ACCESS_ONCE(lock->tickets.head);
 		} while (--count);
 		__ticket_lock_spinning(lock, inc.tail);
 	}
@@ -104,7 +105,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 	arch_spinlock_t old, new;
 
 	old.tickets = ACCESS_ONCE(lock->tickets);
-	if (old.tickets.head != old.tickets.tail)
+	if (old.tickets.head != (old.tickets.tail & ~TICKET_SLOWPATH_FLAG))
 		return 0;
 
 	new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT);
@@ -113,12 +114,49 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 	return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail;
 }
 
+static inline void __ticket_unlock_slowpath(arch_spinlock_t *lock,
+					    arch_spinlock_t old)
+{
+	arch_spinlock_t new;
+
+	BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS);
+
+	/* Perform the unlock on the "before" copy */
+	old.tickets.head += TICKET_LOCK_INC;
+
+	/* Clear the slowpath flag */
+	new.head_tail = old.head_tail & ~(TICKET_SLOWPATH_FLAG << TICKET_SHIFT);
+
+	/*
+	 * If the lock is uncontended, clear the flag - use cmpxchg in
+	 * case it changes behind our back though.
+	 */
+	if (new.tickets.head != new.tickets.tail ||
+	    cmpxchg(&lock->head_tail, old.head_tail,
+					new.head_tail) != old.head_tail) {
+		/*
+		 * Lock still has someone queued for it, so wake up an
+		 * appropriate waiter.
+		 */
+		__ticket_unlock_kick(lock, old.tickets.head);
+	}
+}
+
 static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
 {
-	__ticket_t next = lock->tickets.head + TICKET_LOCK_INC;
+	if (TICKET_SLOWPATH_FLAG &&
+	    static_key_false(&paravirt_ticketlocks_enabled)) {
+		arch_spinlock_t prev;
+
+		prev = *lock;
+		add_smp(&lock->tickets.head, TICKET_LOCK_INC);
+
+		/* add_smp() is a full mb() */
 
-	__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
-	__ticket_unlock_kick(lock, next);
+		if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
+			__ticket_unlock_slowpath(lock, prev);
+	} else
+		__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
 }
 
 static inline int arch_spin_is_locked(arch_spinlock_t *lock)
diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h
index e96fcbd..4f1bea1 100644
--- a/arch/x86/include/asm/spinlock_types.h
+++ b/arch/x86/include/asm/spinlock_types.h
@@ -5,8 +5,10 @@
 
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 #define __TICKET_LOCK_INC	2
+#define TICKET_SLOWPATH_FLAG	((__ticket_t)1)
 #else
 #define __TICKET_LOCK_INC	1
+#define TICKET_SLOWPATH_FLAG	((__ticket_t)0)
 #endif
 
 #if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC))
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 4251c1d..bbb6c73 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -4,6 +4,7 @@
  */
 #include <linux/spinlock.h>
 #include <linux/module.h>
+#include <linux/jump_label.h>
 
 #include <asm/paravirt.h>
 
@@ -15,3 +16,5 @@ struct pv_lock_ops pv_lock_ops = {
 };
 EXPORT_SYMBOL(pv_lock_ops);
 
+struct static_key paravirt_ticketlocks_enabled = STATIC_KEY_INIT_FALSE;
+EXPORT_SYMBOL(paravirt_ticketlocks_enabled);
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index b0cdde1..e2f312f 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -157,6 +157,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 	/* Only check lock once pending cleared */
 	barrier();
 
+	/* Mark entry to slowpath before doing the pickup test to make
+	   sure we don't deadlock with an unlocker. */
+	__ticket_enter_slowpath(lock);
+
 	/* check again make sure it didn't become free while
 	   we weren't looking  */
 	if (ACCESS_ONCE(lock->tickets.head) == want) {
@@ -233,6 +237,8 @@ void __init xen_init_spinlocks(void)
 		return;
 	}
 
+	static_key_slow_inc(&paravirt_ticketlocks_enabled);
+
 	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning);
 	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIc-00036v-Vc; Sat, 21 Apr 2012 21:56:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxmM-0005Z1-Nv
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:16:35 +0000
Received: from [85.158.143.99:42793] by server-3.bemta-4.messagelabs.com id
	4D/BC-05853-2A2709F4; Thu, 19 Apr 2012 20:16:34 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334866589!14790466!1
X-Originating-IP: [202.81.31.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NyA9PiA5NTA1NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24040 invoked from network); 19 Apr 2012 20:16:32 -0000
Received: from e23smtp05.au.ibm.com (HELO e23smtp05.au.ibm.com) (202.81.31.147)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:16:32 -0000
Received: from /spool/local
	by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:11:50 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp05.au.ibm.com (202.81.31.211) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:11:48 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK9lqB2207922
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:09:47 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKG4JV015959
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:16:06 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFqYX015686; Fri, 20 Apr 2012 06:15:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:46 +0530
Message-Id: <20120419201543.5411.37767.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-1396-0000-0000-00000102CD48
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 9/12] split out rate limiting from
	jump_label.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andrew Jones <drjones@redhat.com>

Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting
for jump label disabling. The changes were made in the jump label code
in order to be more widely available and to keep things tidier. This is
all fine, except now jump_label.h includes linux/workqueue.h, which
makes it impossible to include jump_label.h from anything that
workqueue.h needs. For example, it's now impossible to include
jump_label.h from asm/spinlock.h, which is done in proposed
pv-ticketlock patches. This patch splits out the rate limiting related
changes from jump_label.h into a new file, jump_label_ratelimit.h, to
resolve the issue.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 include/linux/jump_label.h           |   26 +-------------------------
 include/linux/jump_label_ratelimit.h |   34 ++++++++++++++++++++++++++++++++++
 include/linux/perf_event.h           |    1 +
 kernel/jump_label.c                  |    1 +
 4 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index c513a40..8195227 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -49,7 +49,6 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
-#include <linux/workqueue.h>
 
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 
@@ -62,12 +61,6 @@ struct static_key {
 #endif
 };
 
-struct static_key_deferred {
-	struct static_key key;
-	unsigned long timeout;
-	struct delayed_work work;
-};
-
 # include <asm/jump_label.h>
 # define HAVE_JUMP_LABEL
 #endif	/* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry,
 extern int jump_label_text_reserved(void *start, void *end);
 extern void static_key_slow_inc(struct static_key *key);
 extern void static_key_slow_dec(struct static_key *key);
-extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
 extern void jump_label_apply_nops(struct module *mod);
-extern void
-jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
 
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 	{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
@@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void)
 {
 }
 
-struct static_key_deferred {
-	struct static_key  key;
-};
-
 static __always_inline bool static_key_false(struct static_key *key)
 {
 	if (unlikely(atomic_read(&key->enabled)) > 0)
@@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key)
 	atomic_dec(&key->enabled);
 }
 
-static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
-{
-	static_key_slow_dec(&key->key);
-}
-
 static inline int jump_label_text_reserved(void *start, void *end)
 {
 	return 0;
@@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 	return 0;
 }
 
-static inline void
-jump_label_rate_limit(struct static_key_deferred *key,
-		unsigned long rl)
-{
-}
-
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 		{ .enabled = ATOMIC_INIT(1) })
 #define STATIC_KEY_INIT_FALSE ((struct static_key) \
@@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key,
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
+static inline int atomic_read(const atomic_t *v);
 static inline bool static_key_enabled(struct static_key *key)
 {
 	return (atomic_read(&key->enabled) > 0);
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
new file mode 100644
index 0000000..1137883
--- /dev/null
+++ b/include/linux/jump_label_ratelimit.h
@@ -0,0 +1,34 @@
+#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H
+#define _LINUX_JUMP_LABEL_RATELIMIT_H
+
+#include <linux/jump_label.h>
+#include <linux/workqueue.h>
+
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+struct static_key_deferred {
+	struct static_key key;
+	unsigned long timeout;
+	struct delayed_work work;
+};
+#endif
+
+#ifdef HAVE_JUMP_LABEL
+extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void
+jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
+
+#else	/* !HAVE_JUMP_LABEL */
+struct static_key_deferred {
+	struct static_key  key;
+};
+static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
+{
+	static_key_slow_dec(&key->key);
+}
+static inline void
+jump_label_rate_limit(struct static_key_deferred *key,
+		unsigned long rl)
+{
+}
+#endif	/* HAVE_JUMP_LABEL */
+#endif	/* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index ddbb6a9..a0e6118 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -605,6 +605,7 @@ struct perf_guest_info_callbacks {
 #include <linux/cpu.h>
 #include <linux/irq_work.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 #include <linux/atomic.h>
 #include <linux/sysfs.h>
 #include <asm/local.h>
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 4304919..e17f8d6 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -13,6 +13,7 @@
 #include <linux/sort.h>
 #include <linux/err.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 
 #ifdef HAVE_JUMP_LABEL
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIZ-00034Z-DD; Sat, 21 Apr 2012 21:56:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxjE-0005R1-L6
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:13:21 +0000
Received: from [85.158.139.83:44171] by server-6.bemta-5.messagelabs.com id
	B3/AB-13222-FD1709F4; Thu, 19 Apr 2012 20:13:19 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1334866394!24623196!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNDU0NDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24023 invoked from network); 19 Apr 2012 20:13:18 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:13:18 -0000
Received: from /spool/local
	by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 19:55:24 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 19:55:11 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK6Hl22277474
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:06:17 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKCpmS028142
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:12:53 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKCeBN028070; Fri, 20 Apr 2012 06:12:45 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:42:33 +0530
Message-Id: <20120419201231.5411.98124.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041909-5490-0000-0000-0000012F02DC
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 1/12] x86/spinlock: replace pv spinlocks
	with pv ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Rather than outright replacing the entire spinlock implementation in
order to paravirtualize it, keep the ticket lock implementation but add
a couple of pvops hooks on the slow patch (long spin on lock, unlocking
a contended lock).

Ticket locks have a number of nice properties, but they also have some
surprising behaviours in virtual environments.  They enforce a strict
FIFO ordering on cpus trying to take a lock; however, if the hypervisor
scheduler does not schedule the cpus in the correct order, the system can
waste a huge amount of time spinning until the next cpu can take the lock.

(See Thomas Friebel's talk "Prevent Guests from Spinning Around"
http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)

To address this, we add two hooks:
 - __ticket_spin_lock which is called after the cpu has been
   spinning on the lock for a significant number of iterations but has
   failed to take the lock (presumably because the cpu holding the lock
   has been descheduled).  The lock_spinning pvop is expected to block
   the cpu until it has been kicked by the current lock holder.
 - __ticket_spin_unlock, which on releasing a contended lock
   (there are more cpus with tail tickets), it looks to see if the next
   cpu is blocked and wakes it if so.

When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub
functions causes all the extra code to go away.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/paravirt.h       |   32 ++++----------------
 arch/x86/include/asm/paravirt_types.h |   10 ++----
 arch/x86/include/asm/spinlock.h       |   53 ++++++++++++++++++++++++++------
 arch/x86/include/asm/spinlock_types.h |    4 --
 arch/x86/kernel/paravirt-spinlocks.c  |   15 +--------
 arch/x86/xen/spinlock.c               |    8 ++++-
 6 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index aa0f913..4bcd146 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -751,36 +751,16 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 
 #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
 
-static inline int arch_spin_is_locked(struct arch_spinlock *lock)
+static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
+							__ticket_t ticket)
 {
-	return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock);
+	PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket);
 }
 
-static inline int arch_spin_is_contended(struct arch_spinlock *lock)
+static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
+							__ticket_t ticket)
 {
-	return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock);
-}
-#define arch_spin_is_contended	arch_spin_is_contended
-
-static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
-{
-	PVOP_VCALL1(pv_lock_ops.spin_lock, lock);
-}
-
-static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock,
-						  unsigned long flags)
-{
-	PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags);
-}
-
-static __always_inline int arch_spin_trylock(struct arch_spinlock *lock)
-{
-	return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock);
-}
-
-static __always_inline void arch_spin_unlock(struct arch_spinlock *lock)
-{
-	PVOP_VCALL1(pv_lock_ops.spin_unlock, lock);
+	PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
 }
 
 #endif
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..005e24d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -327,13 +327,11 @@ struct pv_mmu_ops {
 };
 
 struct arch_spinlock;
+#include <asm/spinlock_types.h>
+
 struct pv_lock_ops {
-	int (*spin_is_locked)(struct arch_spinlock *lock);
-	int (*spin_is_contended)(struct arch_spinlock *lock);
-	void (*spin_lock)(struct arch_spinlock *lock);
-	void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long flags);
-	int (*spin_trylock)(struct arch_spinlock *lock);
-	void (*spin_unlock)(struct arch_spinlock *lock);
+	void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket);
+	void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
 };
 
 /* This contains all the paravirt structures: we get a convenient
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 76bfa2c..3e47608 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -37,6 +37,35 @@
 # define UNLOCK_LOCK_PREFIX
 #endif
 
+/* How long a lock should spin before we consider blocking */
+#define SPIN_THRESHOLD	(1 << 11)
+
+#ifndef CONFIG_PARAVIRT_SPINLOCKS
+
+static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
+							__ticket_t ticket)
+{
+}
+
+static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
+							 __ticket_t ticket)
+{
+}
+
+#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
+
+
+/*
+ * If a spinlock has someone waiting on it, then kick the appropriate
+ * waiting cpu.
+ */
+static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
+							__ticket_t next)
+{
+	if (unlikely(lock->tickets.tail != next))
+		____ticket_unlock_kick(lock, next);
+}
+
 /*
  * Ticket locks are conceptually two parts, one indicating the current head of
  * the queue, and the other indicating the current tail. The lock is acquired
@@ -50,19 +79,24 @@
  * in the high part, because a wide xadd increment of the low part would carry
  * up and contaminate the high part.
  */
-static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock)
+static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock)
 {
 	register struct __raw_tickets inc = { .tail = 1 };
 
 	inc = xadd(&lock->tickets, inc);
 
 	for (;;) {
-		if (inc.head == inc.tail)
-			break;
-		cpu_relax();
-		inc.head = ACCESS_ONCE(lock->tickets.head);
+		unsigned count = SPIN_THRESHOLD;
+
+		do {
+			if (inc.head == inc.tail)
+				goto out;
+			cpu_relax();
+			inc.head = ACCESS_ONCE(lock->tickets.head);
+		} while (--count);
+		__ticket_lock_spinning(lock, inc.tail);
 	}
-	barrier();		/* make sure nothing creeps before the lock is taken */
+out:	barrier();	/* make sure nothing creeps before the lock is taken */
 }
 
 static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
@@ -81,7 +115,10 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
 
 static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
 {
+	__ticket_t next = lock->tickets.head + 1;
+
 	__add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX);
+	__ticket_unlock_kick(lock, next);
 }
 
 static inline int __ticket_spin_is_locked(arch_spinlock_t *lock)
@@ -98,8 +135,6 @@ static inline int __ticket_spin_is_contended(arch_spinlock_t *lock)
 	return (__ticket_t)(tmp.tail - tmp.head) > 1;
 }
 
-#ifndef CONFIG_PARAVIRT_SPINLOCKS
-
 static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 {
 	return __ticket_spin_is_locked(lock);
@@ -132,8 +167,6 @@ static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock,
 	arch_spin_lock(lock);
 }
 
-#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
-
 static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
 {
 	while (arch_spin_is_locked(lock))
diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h
index ad0ad07..83fd3c7 100644
--- a/arch/x86/include/asm/spinlock_types.h
+++ b/arch/x86/include/asm/spinlock_types.h
@@ -1,10 +1,6 @@
 #ifndef _ASM_X86_SPINLOCK_TYPES_H
 #define _ASM_X86_SPINLOCK_TYPES_H
 
-#ifndef __LINUX_SPINLOCK_TYPES_H
-# error "please don't include this file directly"
-#endif
-
 #include <linux/types.h>
 
 #if (CONFIG_NR_CPUS < 256)
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 676b8c7..c2e010e 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -7,21 +7,10 @@
 
 #include <asm/paravirt.h>
 
-static inline void
-default_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags)
-{
-	arch_spin_lock(lock);
-}
-
 struct pv_lock_ops pv_lock_ops = {
 #ifdef CONFIG_SMP
-	.spin_is_locked = __ticket_spin_is_locked,
-	.spin_is_contended = __ticket_spin_is_contended,
-
-	.spin_lock = __ticket_spin_lock,
-	.spin_lock_flags = default_spin_lock_flags,
-	.spin_trylock = __ticket_spin_trylock,
-	.spin_unlock = __ticket_spin_unlock,
+	.lock_spinning = paravirt_nop,
+	.unlock_kick = paravirt_nop,
 #endif
 };
 EXPORT_SYMBOL(pv_lock_ops);
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 00461a4..f1f4540 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -138,6 +138,9 @@ struct xen_spinlock {
 	xen_spinners_t spinners;	/* count of waiting cpus */
 };
 
+static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
+
+#if 0
 static int xen_spin_is_locked(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
@@ -165,7 +168,6 @@ static int xen_spin_trylock(struct arch_spinlock *lock)
 	return old == 0;
 }
 
-static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
 static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
 
 /*
@@ -353,6 +355,7 @@ static void xen_spin_unlock(struct arch_spinlock *lock)
 	if (unlikely(xl->spinners))
 		xen_spin_unlock_slow(xl);
 }
+#endif
 
 static irqreturn_t dummy_handler(int irq, void *dev_id)
 {
@@ -389,13 +392,14 @@ void xen_uninit_lock_cpu(int cpu)
 void __init xen_init_spinlocks(void)
 {
 	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
-
+#if 0
 	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
 	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
 	pv_lock_ops.spin_lock = xen_spin_lock;
 	pv_lock_ops.spin_lock_flags = xen_spin_lock_flags;
 	pv_lock_ops.spin_trylock = xen_spin_trylock;
 	pv_lock_ops.spin_unlock = xen_spin_unlock;
+#endif
 }
 
 #ifdef CONFIG_XEN_DEBUG_FS


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIa-00035A-KL; Sat, 21 Apr 2012 21:56:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxk7-0005U5-VN
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:14:16 +0000
Received: from [193.109.254.147:35145] by server-10.bemta-14.messagelabs.com
	id 41/43-05847-712709F4; Thu, 19 Apr 2012 20:14:15 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1334866451!5446762!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNDU0NDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21985 invoked from network); 19 Apr 2012 20:14:14 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:14:14 -0000
Received: from /spool/local
	by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 19:56:26 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 19:56:23 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK7Uot1204408
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:07:30 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKE4JX024634
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:14:06 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKDruf024548; Fri, 20 Apr 2012 06:13:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:43:47 +0530
Message-Id: <20120419201343.5411.77666.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041909-5490-0000-0000-0000012F031A
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 4/12] xen: defer spinlock setup until
	boot CPU setup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

There's no need to do it at very early init, and doing it there
makes it impossible to use the jump_label machinery.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/smp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..9ac931b 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -207,6 +207,7 @@ static void __init xen_smp_prepare_boot_cpu(void)
 
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
+	xen_init_spinlocks();
 }
 
 static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
@@ -536,7 +537,6 @@ void __init xen_smp_init(void)
 {
 	smp_ops = xen_smp_ops;
 	xen_fill_possible_map();
-	xen_init_spinlocks();
 }
 
 static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiId-00037L-Eb; Sat, 21 Apr 2012 21:56:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxmR-0005ZE-Ni
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:16:40 +0000
Received: from [85.158.138.51:12736] by server-2.bemta-3.messagelabs.com id
	50/A1-09269-6A2709F4; Thu, 19 Apr 2012 20:16:38 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1334866594!18576326!1
X-Originating-IP: [122.248.162.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMiA9PiAxNzcxOTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3653 invoked from network); 19 Apr 2012 20:16:37 -0000
Received: from e28smtp02.in.ibm.com (HELO e28smtp02.in.ibm.com) (122.248.162.2)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:16:37 -0000
Received: from /spool/local
	by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:46:33 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:46:30 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKGTxP4542572
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:46:29 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1k8b1018510
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 07:16:11 +0530
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1k0sn018139; Fri, 20 Apr 2012 07:16:05 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:46:12 +0530
Message-Id: <20120419201609.5411.66223.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-5816-0000-0000-000002348EA9
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC V7 10/12] x86/ticketlock: add slowpath logic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Maintain a flag in the LSB of the ticket lock tail which indicates
whether anyone is in the lock slowpath and may need kicking when
the current holder unlocks.  The flags are set when the first locker
enters the slowpath, and cleared when unlocking to an empty queue (ie,
no contention).

In the specific implementation of lock_spinning(), make sure to set
the slowpath flags on the lock just before blocking.  We must do
this before the last-chance pickup test to prevent a deadlock
with the unlocker:

Unlocker			Locker
				test for lock pickup
					-> fail
unlock
test slowpath
	-> false
				set slowpath flags
				block

Whereas this works in any ordering:

Unlocker			Locker
				set slowpath flags
				test for lock pickup
					-> fail
				block
unlock
test slowpath
	-> true, kick

If the unlocker finds that the lock has the slowpath flag set but it is
actually uncontended (ie, head == tail, so nobody is waiting), then it
clears the slowpath flag.

The unlock code uses a locked add to update the head counter.  This also
acts as a full memory barrier so that its safe to subsequently
read back the slowflag state, knowing that the updated lock is visible
to the other CPUs.  If it were an unlocked add, then the flag read may
just be forwarded from the store buffer before it was visible to the other
CPUs, which could result in a deadlock.

Unfortunately this means we need to do a locked instruction when
unlocking with PV ticketlocks.  However, if PV ticketlocks are not
enabled, then the old non-locked "add" is the only unlocking code.

Note: this code relies on gcc making sure that unlikely() code is out of
line of the fastpath, which only happens when OPTIMIZE_SIZE=n.  If it
doesn't the generated code isn't too bad, but its definitely suboptimal.

Thanks to Srivatsa Vaddagiri for providing a bugfix to the original
version of this change, which has been folded in.
Thanks to Stephan Diestelhorst for commenting on some code which relied
on an inaccurate reading of the x86 memory ordering rules.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/paravirt.h       |    2 +-
 arch/x86/include/asm/spinlock.h       |   86 +++++++++++++++++++++++---------
 arch/x86/include/asm/spinlock_types.h |    2 +
 arch/x86/kernel/paravirt-spinlocks.c  |    3 +
 arch/x86/xen/spinlock.c               |    6 ++
 5 files changed, 74 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 9769096..af49670 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -757,7 +757,7 @@ static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
 	PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
 }
 
-static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
+static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
 							__ticket_t ticket)
 {
 	PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 60b7e83..e6881fd 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -1,11 +1,14 @@
 #ifndef _ASM_X86_SPINLOCK_H
 #define _ASM_X86_SPINLOCK_H
 
+#include <linux/jump_label.h>
 #include <linux/atomic.h>
 #include <asm/page.h>
 #include <asm/processor.h>
 #include <linux/compiler.h>
 #include <asm/paravirt.h>
+#include <asm/bitops.h>
+
 /*
  * Your basic SMP spinlocks, allowing only a single CPU anywhere
  *
@@ -40,32 +43,28 @@
 /* How long a lock should spin before we consider blocking */
 #define SPIN_THRESHOLD	(1 << 11)
 
-#ifndef CONFIG_PARAVIRT_SPINLOCKS
+extern struct static_key paravirt_ticketlocks_enabled;
+static __always_inline bool static_key_false(struct static_key *key);
 
-static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
-							__ticket_t ticket)
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
 {
+	set_bit(0, (volatile unsigned long *)&lock->tickets.tail);
 }
 
-static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
-							 __ticket_t ticket)
+#else  /* !CONFIG_PARAVIRT_SPINLOCKS */
+static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock,
+							__ticket_t ticket)
 {
 }
-
-#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
-
-
-/*
- * If a spinlock has someone waiting on it, then kick the appropriate
- * waiting cpu.
- */
-static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
-							__ticket_t next)
+static inline void __ticket_unlock_kick(arch_spinlock_t *lock,
+							__ticket_t ticket)
 {
-	if (unlikely(lock->tickets.tail != next))
-		____ticket_unlock_kick(lock, next);
 }
 
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
 /*
  * Ticket locks are conceptually two parts, one indicating the current head of
  * the queue, and the other indicating the current tail. The lock is acquired
@@ -79,20 +78,22 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
  * in the high part, because a wide xadd increment of the low part would carry
  * up and contaminate the high part.
  */
-static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
+static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
 {
 	register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC };
 
 	inc = xadd(&lock->tickets, inc);
+	if (likely(inc.head == inc.tail))
+		goto out;
 
+	inc.tail &= ~TICKET_SLOWPATH_FLAG;
 	for (;;) {
 		unsigned count = SPIN_THRESHOLD;
 
 		do {
-			if (inc.head == inc.tail)
+			if (ACCESS_ONCE(lock->tickets.head) == inc.tail)
 				goto out;
 			cpu_relax();
-			inc.head = ACCESS_ONCE(lock->tickets.head);
 		} while (--count);
 		__ticket_lock_spinning(lock, inc.tail);
 	}
@@ -104,7 +105,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 	arch_spinlock_t old, new;
 
 	old.tickets = ACCESS_ONCE(lock->tickets);
-	if (old.tickets.head != old.tickets.tail)
+	if (old.tickets.head != (old.tickets.tail & ~TICKET_SLOWPATH_FLAG))
 		return 0;
 
 	new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT);
@@ -113,12 +114,49 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 	return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail;
 }
 
+static inline void __ticket_unlock_slowpath(arch_spinlock_t *lock,
+					    arch_spinlock_t old)
+{
+	arch_spinlock_t new;
+
+	BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS);
+
+	/* Perform the unlock on the "before" copy */
+	old.tickets.head += TICKET_LOCK_INC;
+
+	/* Clear the slowpath flag */
+	new.head_tail = old.head_tail & ~(TICKET_SLOWPATH_FLAG << TICKET_SHIFT);
+
+	/*
+	 * If the lock is uncontended, clear the flag - use cmpxchg in
+	 * case it changes behind our back though.
+	 */
+	if (new.tickets.head != new.tickets.tail ||
+	    cmpxchg(&lock->head_tail, old.head_tail,
+					new.head_tail) != old.head_tail) {
+		/*
+		 * Lock still has someone queued for it, so wake up an
+		 * appropriate waiter.
+		 */
+		__ticket_unlock_kick(lock, old.tickets.head);
+	}
+}
+
 static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
 {
-	__ticket_t next = lock->tickets.head + TICKET_LOCK_INC;
+	if (TICKET_SLOWPATH_FLAG &&
+	    static_key_false(&paravirt_ticketlocks_enabled)) {
+		arch_spinlock_t prev;
+
+		prev = *lock;
+		add_smp(&lock->tickets.head, TICKET_LOCK_INC);
+
+		/* add_smp() is a full mb() */
 
-	__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
-	__ticket_unlock_kick(lock, next);
+		if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
+			__ticket_unlock_slowpath(lock, prev);
+	} else
+		__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
 }
 
 static inline int arch_spin_is_locked(arch_spinlock_t *lock)
diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h
index e96fcbd..4f1bea1 100644
--- a/arch/x86/include/asm/spinlock_types.h
+++ b/arch/x86/include/asm/spinlock_types.h
@@ -5,8 +5,10 @@
 
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 #define __TICKET_LOCK_INC	2
+#define TICKET_SLOWPATH_FLAG	((__ticket_t)1)
 #else
 #define __TICKET_LOCK_INC	1
+#define TICKET_SLOWPATH_FLAG	((__ticket_t)0)
 #endif
 
 #if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC))
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 4251c1d..bbb6c73 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -4,6 +4,7 @@
  */
 #include <linux/spinlock.h>
 #include <linux/module.h>
+#include <linux/jump_label.h>
 
 #include <asm/paravirt.h>
 
@@ -15,3 +16,5 @@ struct pv_lock_ops pv_lock_ops = {
 };
 EXPORT_SYMBOL(pv_lock_ops);
 
+struct static_key paravirt_ticketlocks_enabled = STATIC_KEY_INIT_FALSE;
+EXPORT_SYMBOL(paravirt_ticketlocks_enabled);
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index b0cdde1..e2f312f 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -157,6 +157,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 	/* Only check lock once pending cleared */
 	barrier();
 
+	/* Mark entry to slowpath before doing the pickup test to make
+	   sure we don't deadlock with an unlocker. */
+	__ticket_enter_slowpath(lock);
+
 	/* check again make sure it didn't become free while
 	   we weren't looking  */
 	if (ACCESS_ONCE(lock->tickets.head) == want) {
@@ -233,6 +237,8 @@ void __init xen_init_spinlocks(void)
 		return;
 	}
 
+	static_key_slow_inc(&paravirt_ticketlocks_enabled);
+
 	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning);
 	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIc-00036v-Vc; Sat, 21 Apr 2012 21:56:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxmM-0005Z1-Nv
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:16:35 +0000
Received: from [85.158.143.99:42793] by server-3.bemta-4.messagelabs.com id
	4D/BC-05853-2A2709F4; Thu, 19 Apr 2012 20:16:34 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1334866589!14790466!1
X-Originating-IP: [202.81.31.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NyA9PiA5NTA1NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24040 invoked from network); 19 Apr 2012 20:16:32 -0000
Received: from e23smtp05.au.ibm.com (HELO e23smtp05.au.ibm.com) (202.81.31.147)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:16:32 -0000
Received: from /spool/local
	by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:11:50 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp05.au.ibm.com (202.81.31.211) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:11:48 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK9lqB2207922
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:09:47 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKG4JV015959
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:16:06 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFqYX015686; Fri, 20 Apr 2012 06:15:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:46 +0530
Message-Id: <20120419201543.5411.37767.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-1396-0000-0000-00000102CD48
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 9/12] split out rate limiting from
	jump_label.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andrew Jones <drjones@redhat.com>

Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting
for jump label disabling. The changes were made in the jump label code
in order to be more widely available and to keep things tidier. This is
all fine, except now jump_label.h includes linux/workqueue.h, which
makes it impossible to include jump_label.h from anything that
workqueue.h needs. For example, it's now impossible to include
jump_label.h from asm/spinlock.h, which is done in proposed
pv-ticketlock patches. This patch splits out the rate limiting related
changes from jump_label.h into a new file, jump_label_ratelimit.h, to
resolve the issue.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 include/linux/jump_label.h           |   26 +-------------------------
 include/linux/jump_label_ratelimit.h |   34 ++++++++++++++++++++++++++++++++++
 include/linux/perf_event.h           |    1 +
 kernel/jump_label.c                  |    1 +
 4 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index c513a40..8195227 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -49,7 +49,6 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
-#include <linux/workqueue.h>
 
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 
@@ -62,12 +61,6 @@ struct static_key {
 #endif
 };
 
-struct static_key_deferred {
-	struct static_key key;
-	unsigned long timeout;
-	struct delayed_work work;
-};
-
 # include <asm/jump_label.h>
 # define HAVE_JUMP_LABEL
 #endif	/* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry,
 extern int jump_label_text_reserved(void *start, void *end);
 extern void static_key_slow_inc(struct static_key *key);
 extern void static_key_slow_dec(struct static_key *key);
-extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
 extern void jump_label_apply_nops(struct module *mod);
-extern void
-jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
 
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 	{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
@@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void)
 {
 }
 
-struct static_key_deferred {
-	struct static_key  key;
-};
-
 static __always_inline bool static_key_false(struct static_key *key)
 {
 	if (unlikely(atomic_read(&key->enabled)) > 0)
@@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key)
 	atomic_dec(&key->enabled);
 }
 
-static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
-{
-	static_key_slow_dec(&key->key);
-}
-
 static inline int jump_label_text_reserved(void *start, void *end)
 {
 	return 0;
@@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 	return 0;
 }
 
-static inline void
-jump_label_rate_limit(struct static_key_deferred *key,
-		unsigned long rl)
-{
-}
-
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 		{ .enabled = ATOMIC_INIT(1) })
 #define STATIC_KEY_INIT_FALSE ((struct static_key) \
@@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key,
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
+static inline int atomic_read(const atomic_t *v);
 static inline bool static_key_enabled(struct static_key *key)
 {
 	return (atomic_read(&key->enabled) > 0);
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
new file mode 100644
index 0000000..1137883
--- /dev/null
+++ b/include/linux/jump_label_ratelimit.h
@@ -0,0 +1,34 @@
+#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H
+#define _LINUX_JUMP_LABEL_RATELIMIT_H
+
+#include <linux/jump_label.h>
+#include <linux/workqueue.h>
+
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+struct static_key_deferred {
+	struct static_key key;
+	unsigned long timeout;
+	struct delayed_work work;
+};
+#endif
+
+#ifdef HAVE_JUMP_LABEL
+extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void
+jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
+
+#else	/* !HAVE_JUMP_LABEL */
+struct static_key_deferred {
+	struct static_key  key;
+};
+static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
+{
+	static_key_slow_dec(&key->key);
+}
+static inline void
+jump_label_rate_limit(struct static_key_deferred *key,
+		unsigned long rl)
+{
+}
+#endif	/* HAVE_JUMP_LABEL */
+#endif	/* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index ddbb6a9..a0e6118 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -605,6 +605,7 @@ struct perf_guest_info_callbacks {
 #include <linux/cpu.h>
 #include <linux/irq_work.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 #include <linux/atomic.h>
 #include <linux/sysfs.h>
 #include <asm/local.h>
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 4304919..e17f8d6 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -13,6 +13,7 @@
 #include <linux/sort.h>
 #include <linux/err.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 
 #ifdef HAVE_JUMP_LABEL
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIa-00034v-7Z; Sat, 21 Apr 2012 21:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxjh-0005SP-Vh
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:13:50 +0000
Received: from [85.158.143.99:13974] by server-1.bemta-4.messagelabs.com id
	75/0A-20925-DF1709F4; Thu, 19 Apr 2012 20:13:49 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334866425!24403080!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzgyODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11600 invoked from network); 19 Apr 2012 20:13:48 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:13:48 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:43:43 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:43:41 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKDf5E4448412
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:43:41 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1iG3r004207
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 11:44:18 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1i8qd003879; Fri, 20 Apr 2012 11:44:13 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:43:25 +0530
Message-Id: <20120419201322.5411.7158.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-9574-0000-0000-000002458C1F
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 3/12] x86/ticketlock: collapse a layer of
	functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Now that the paravirtualization layer doesn't exist at the spinlock
level any more, we can collapse the __ticket_ functions into the arch_
functions.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/spinlock.h |   35 +++++------------------------------
 1 files changed, 5 insertions(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 3e47608..ee4bbd4 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -79,7 +79,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
  * in the high part, because a wide xadd increment of the low part would carry
  * up and contaminate the high part.
  */
-static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock)
+static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
 {
 	register struct __raw_tickets inc = { .tail = 1 };
 
@@ -99,7 +99,7 @@ static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock)
 out:	barrier();	/* make sure nothing creeps before the lock is taken */
 }
 
-static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
+static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 {
 	arch_spinlock_t old, new;
 
@@ -113,7 +113,7 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
 	return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail;
 }
 
-static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
+static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
 {
 	__ticket_t next = lock->tickets.head + 1;
 
@@ -121,46 +121,21 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
 	__ticket_unlock_kick(lock, next);
 }
 
-static inline int __ticket_spin_is_locked(arch_spinlock_t *lock)
+static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 {
 	struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
 
 	return tmp.tail != tmp.head;
 }
 
-static inline int __ticket_spin_is_contended(arch_spinlock_t *lock)
+static inline int arch_spin_is_contended(arch_spinlock_t *lock)
 {
 	struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
 
 	return (__ticket_t)(tmp.tail - tmp.head) > 1;
 }
-
-static inline int arch_spin_is_locked(arch_spinlock_t *lock)
-{
-	return __ticket_spin_is_locked(lock);
-}
-
-static inline int arch_spin_is_contended(arch_spinlock_t *lock)
-{
-	return __ticket_spin_is_contended(lock);
-}
 #define arch_spin_is_contended	arch_spin_is_contended
 
-static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
-{
-	__ticket_spin_lock(lock);
-}
-
-static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
-{
-	return __ticket_spin_trylock(lock);
-}
-
-static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
-{
-	__ticket_spin_unlock(lock);
-}
-
 static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock,
 						  unsigned long flags)
 {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIa-00034v-7Z; Sat, 21 Apr 2012 21:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxjh-0005SP-Vh
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:13:50 +0000
Received: from [85.158.143.99:13974] by server-1.bemta-4.messagelabs.com id
	75/0A-20925-DF1709F4; Thu, 19 Apr 2012 20:13:49 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1334866425!24403080!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxNzgyODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11600 invoked from network); 19 Apr 2012 20:13:48 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:13:48 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:43:43 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:43:41 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKDf5E4448412
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:43:41 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1iG3r004207
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 11:44:18 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1i8qd003879; Fri, 20 Apr 2012 11:44:13 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:43:25 +0530
Message-Id: <20120419201322.5411.7158.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-9574-0000-0000-000002458C1F
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 3/12] x86/ticketlock: collapse a layer of
	functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Now that the paravirtualization layer doesn't exist at the spinlock
level any more, we can collapse the __ticket_ functions into the arch_
functions.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/spinlock.h |   35 +++++------------------------------
 1 files changed, 5 insertions(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 3e47608..ee4bbd4 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -79,7 +79,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
  * in the high part, because a wide xadd increment of the low part would carry
  * up and contaminate the high part.
  */
-static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock)
+static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
 {
 	register struct __raw_tickets inc = { .tail = 1 };
 
@@ -99,7 +99,7 @@ static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock)
 out:	barrier();	/* make sure nothing creeps before the lock is taken */
 }
 
-static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
+static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
 {
 	arch_spinlock_t old, new;
 
@@ -113,7 +113,7 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
 	return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail;
 }
 
-static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
+static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
 {
 	__ticket_t next = lock->tickets.head + 1;
 
@@ -121,46 +121,21 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
 	__ticket_unlock_kick(lock, next);
 }
 
-static inline int __ticket_spin_is_locked(arch_spinlock_t *lock)
+static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 {
 	struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
 
 	return tmp.tail != tmp.head;
 }
 
-static inline int __ticket_spin_is_contended(arch_spinlock_t *lock)
+static inline int arch_spin_is_contended(arch_spinlock_t *lock)
 {
 	struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
 
 	return (__ticket_t)(tmp.tail - tmp.head) > 1;
 }
-
-static inline int arch_spin_is_locked(arch_spinlock_t *lock)
-{
-	return __ticket_spin_is_locked(lock);
-}
-
-static inline int arch_spin_is_contended(arch_spinlock_t *lock)
-{
-	return __ticket_spin_is_contended(lock);
-}
 #define arch_spin_is_contended	arch_spin_is_contended
 
-static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
-{
-	__ticket_spin_lock(lock);
-}
-
-static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
-{
-	return __ticket_spin_trylock(lock);
-}
-
-static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
-{
-	__ticket_spin_unlock(lock);
-}
-
 static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock,
 						  unsigned long flags)
 {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIb-00035P-1V; Sat, 21 Apr 2012 21:56:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxkY-0005Vj-M9
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:14:43 +0000
Received: from [85.158.139.83:55673] by server-11.bemta-5.messagelabs.com id
	A0/FA-12959-132709F4; Thu, 19 Apr 2012 20:14:41 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334866476!21910782!1
X-Originating-IP: [202.81.31.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAyNDM2ODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29672 invoked from network); 19 Apr 2012 20:14:39 -0000
Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:14:39 -0000
Received: from /spool/local
	by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:05:25 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:05:23 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK7sIX2215990
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:07:54 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKEVFJ029945
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:14:32 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKEI7W029786; Fri, 20 Apr 2012 06:14:23 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:44:12 +0530
Message-Id: <20120419201409.5411.35328.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-6102-0000-0000-00000147F414
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 5/12] xen/pvticketlock: Xen
	implementation for PV ticket locks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Replace the old Xen implementation of PV spinlocks with and implementation
of xen_lock_spinning and xen_unlock_kick.

xen_lock_spinning simply registers the cpu in its entry in lock_waiting,
adds itself to the waiting_cpus set, and blocks on an event channel
until the channel becomes pending.

xen_unlock_kick searches the cpus in waiting_cpus looking for the one
which next wants this lock with the next ticket, if any.  If found,
it kicks it by making its event channel pending, which wakes it up.

We need to make sure interrupts are disabled while we're relying on the
contents of the per-cpu lock_waiting values, otherwise an interrupt
handler could come in, try to take some other lock, block, and overwrite
our values.

Raghu: use function + enum instead of macro, cmpxchg for zero status reset

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/spinlock.c |  344 +++++++++++------------------------------------
 1 files changed, 77 insertions(+), 267 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index f1f4540..982e64b 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -16,45 +16,46 @@
 #include "xen-ops.h"
 #include "debugfs.h"
 
+enum xen_contention_stat {
+	TAKEN_SLOW,
+	TAKEN_SLOW_PICKUP,
+	TAKEN_SLOW_SPURIOUS,
+	RELEASED_SLOW,
+	RELEASED_SLOW_KICKED,
+	NR_CONTENTION_STATS
+};
+
+
 #ifdef CONFIG_XEN_DEBUG_FS
 static struct xen_spinlock_stats
 {
-	u64 taken;
-	u32 taken_slow;
-	u32 taken_slow_nested;
-	u32 taken_slow_pickup;
-	u32 taken_slow_spurious;
-	u32 taken_slow_irqenable;
-
-	u64 released;
-	u32 released_slow;
-	u32 released_slow_kicked;
+	u32 contention_stats[NR_CONTENTION_STATS];
 
 #define HISTO_BUCKETS	30
-	u32 histo_spin_total[HISTO_BUCKETS+1];
-	u32 histo_spin_spinning[HISTO_BUCKETS+1];
 	u32 histo_spin_blocked[HISTO_BUCKETS+1];
 
-	u64 time_total;
-	u64 time_spinning;
 	u64 time_blocked;
 } spinlock_stats;
 
 static u8 zero_stats;
 
-static unsigned lock_timeout = 1 << 10;
-#define TIMEOUT lock_timeout
-
 static inline void check_zero(void)
 {
-	if (unlikely(zero_stats)) {
-		memset(&spinlock_stats, 0, sizeof(spinlock_stats));
-		zero_stats = 0;
+	u8 ret;
+	u8 old = ACCESS_ONCE(zero_stats);
+	if (unlikely(old)) {
+		ret = cmpxchg(&zero_stats, old, 0);
+		/* This ensures only one fellow resets the stat */
+		if (ret == old)
+			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
 	}
 }
 
-#define ADD_STATS(elem, val)			\
-	do { check_zero(); spinlock_stats.elem += (val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+	check_zero();
+	spinlock_stats.contention_stats[var] += val;
+}
 
 static inline u64 spin_time_start(void)
 {
@@ -73,22 +74,6 @@ static void __spin_time_accum(u64 delta, u32 *array)
 		array[HISTO_BUCKETS]++;
 }
 
-static inline void spin_time_accum_spinning(u64 start)
-{
-	u32 delta = xen_clocksource_read() - start;
-
-	__spin_time_accum(delta, spinlock_stats.histo_spin_spinning);
-	spinlock_stats.time_spinning += delta;
-}
-
-static inline void spin_time_accum_total(u64 start)
-{
-	u32 delta = xen_clocksource_read() - start;
-
-	__spin_time_accum(delta, spinlock_stats.histo_spin_total);
-	spinlock_stats.time_total += delta;
-}
-
 static inline void spin_time_accum_blocked(u64 start)
 {
 	u32 delta = xen_clocksource_read() - start;
@@ -98,19 +83,15 @@ static inline void spin_time_accum_blocked(u64 start)
 }
 #else  /* !CONFIG_XEN_DEBUG_FS */
 #define TIMEOUT			(1 << 10)
-#define ADD_STATS(elem, val)	do { (void)(val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+}
 
 static inline u64 spin_time_start(void)
 {
 	return 0;
 }
 
-static inline void spin_time_accum_total(u64 start)
-{
-}
-static inline void spin_time_accum_spinning(u64 start)
-{
-}
 static inline void spin_time_accum_blocked(u64 start)
 {
 }
@@ -133,230 +114,83 @@ typedef u16 xen_spinners_t;
 	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
 #endif
 
-struct xen_spinlock {
-	unsigned char lock;		/* 0 -> free; 1 -> locked */
-	xen_spinners_t spinners;	/* count of waiting cpus */
+struct xen_lock_waiting {
+	struct arch_spinlock *lock;
+	__ticket_t want;
 };
 
 static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
+static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting);
+static cpumask_t waiting_cpus;
 
-#if 0
-static int xen_spin_is_locked(struct arch_spinlock *lock)
+static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 {
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-
-	return xl->lock != 0;
-}
-
-static int xen_spin_is_contended(struct arch_spinlock *lock)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-
-	/* Not strictly true; this is only the count of contended
-	   lock-takers entering the slow path. */
-	return xl->spinners != 0;
-}
-
-static int xen_spin_trylock(struct arch_spinlock *lock)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-	u8 old = 1;
-
-	asm("xchgb %b0,%1"
-	    : "+q" (old), "+m" (xl->lock) : : "memory");
-
-	return old == 0;
-}
-
-static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
-
-/*
- * Mark a cpu as interested in a lock.  Returns the CPU's previous
- * lock of interest, in case we got preempted by an interrupt.
- */
-static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
-{
-	struct xen_spinlock *prev;
-
-	prev = __this_cpu_read(lock_spinners);
-	__this_cpu_write(lock_spinners, xl);
-
-	wmb();			/* set lock of interest before count */
-
-	inc_spinners(xl);
-
-	return prev;
-}
-
-/*
- * Mark a cpu as no longer interested in a lock.  Restores previous
- * lock of interest (NULL for none).
- */
-static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
-{
-	dec_spinners(xl);
-	wmb();			/* decrement count before restoring lock */
-	__this_cpu_write(lock_spinners, prev);
-}
-
-static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool irq_enable)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-	struct xen_spinlock *prev;
 	int irq = __this_cpu_read(lock_kicker_irq);
-	int ret;
+	struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting);
+	int cpu = smp_processor_id();
 	u64 start;
+	unsigned long flags;
 
 	/* If kicker interrupts not initialized yet, just spin */
 	if (irq == -1)
-		return 0;
+		return;
 
 	start = spin_time_start();
 
-	/* announce we're spinning */
-	prev = spinning_lock(xl);
-
-	ADD_STATS(taken_slow, 1);
-	ADD_STATS(taken_slow_nested, prev != NULL);
-
-	do {
-		unsigned long flags;
-
-		/* clear pending */
-		xen_clear_irq_pending(irq);
-
-		/* check again make sure it didn't become free while
-		   we weren't looking  */
-		ret = xen_spin_trylock(lock);
-		if (ret) {
-			ADD_STATS(taken_slow_pickup, 1);
-
-			/*
-			 * If we interrupted another spinlock while it
-			 * was blocking, make sure it doesn't block
-			 * without rechecking the lock.
-			 */
-			if (prev != NULL)
-				xen_set_irq_pending(irq);
-			goto out;
-		}
+	/*
+	 * Make sure an interrupt handler can't upset things in a
+	 * partially setup state.
+	 */
+	local_irq_save(flags);
 
-		flags = arch_local_save_flags();
-		if (irq_enable) {
-			ADD_STATS(taken_slow_irqenable, 1);
-			raw_local_irq_enable();
-		}
+	w->want = want;
+	smp_wmb();
+	w->lock = lock;
 
-		/*
-		 * Block until irq becomes pending.  If we're
-		 * interrupted at this point (after the trylock but
-		 * before entering the block), then the nested lock
-		 * handler guarantees that the irq will be left
-		 * pending if there's any chance the lock became free;
-		 * xen_poll_irq() returns immediately if the irq is
-		 * pending.
-		 */
-		xen_poll_irq(irq);
+	/* This uses set_bit, which atomic and therefore a barrier */
+	cpumask_set_cpu(cpu, &waiting_cpus);
+	add_stats(TAKEN_SLOW, 1);
 
-		raw_local_irq_restore(flags);
+	/* clear pending */
+	xen_clear_irq_pending(irq);
 
-		ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq));
-	} while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */
+	/* Only check lock once pending cleared */
+	barrier();
 
+	/* check again make sure it didn't become free while
+	   we weren't looking  */
+	if (ACCESS_ONCE(lock->tickets.head) == want) {
+		add_stats(TAKEN_SLOW_PICKUP, 1);
+		goto out;
+	}
+	/* Block until irq becomes pending (or perhaps a spurious wakeup) */
+	xen_poll_irq(irq);
+	add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq));
 	kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq));
-
 out:
-	unspinning_lock(xl, prev);
+	cpumask_clear_cpu(cpu, &waiting_cpus);
+	w->lock = NULL;
+	local_irq_restore(flags);
 	spin_time_accum_blocked(start);
-
-	return ret;
 }
 
-static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_enable)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-	unsigned timeout;
-	u8 oldval;
-	u64 start_spin;
-
-	ADD_STATS(taken, 1);
-
-	start_spin = spin_time_start();
-
-	do {
-		u64 start_spin_fast = spin_time_start();
-
-		timeout = TIMEOUT;
-
-		asm("1: xchgb %1,%0\n"
-		    "   testb %1,%1\n"
-		    "   jz 3f\n"
-		    "2: rep;nop\n"
-		    "   cmpb $0,%0\n"
-		    "   je 1b\n"
-		    "   dec %2\n"
-		    "   jnz 2b\n"
-		    "3:\n"
-		    : "+m" (xl->lock), "=q" (oldval), "+r" (timeout)
-		    : "1" (1)
-		    : "memory");
-
-		spin_time_accum_spinning(start_spin_fast);
-
-	} while (unlikely(oldval != 0 &&
-			  (TIMEOUT == ~0 || !xen_spin_lock_slow(lock, irq_enable))));
-
-	spin_time_accum_total(start_spin);
-}
-
-static void xen_spin_lock(struct arch_spinlock *lock)
-{
-	__xen_spin_lock(lock, false);
-}
-
-static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags)
-{
-	__xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
-}
-
-static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
+static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next)
 {
 	int cpu;
 
-	ADD_STATS(released_slow, 1);
+	add_stats(RELEASED_SLOW, 1);
 
-	for_each_online_cpu(cpu) {
-		/* XXX should mix up next cpu selection */
-		if (per_cpu(lock_spinners, cpu) == xl) {
-			ADD_STATS(released_slow_kicked, 1);
+	for_each_cpu(cpu, &waiting_cpus) {
+		const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu);
+
+		if (w->lock == lock && w->want == next) {
+			add_stats(RELEASED_SLOW_KICKED, 1);
 			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
 			break;
 		}
 	}
 }
 
-static void xen_spin_unlock(struct arch_spinlock *lock)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-
-	ADD_STATS(released, 1);
-
-	smp_wmb();		/* make sure no writes get moved after unlock */
-	xl->lock = 0;		/* release lock */
-
-	/*
-	 * Make sure unlock happens before checking for waiting
-	 * spinners.  We need a strong barrier to enforce the
-	 * write-read ordering to different memory locations, as the
-	 * CPU makes no implied guarantees about their ordering.
-	 */
-	mb();
-
-	if (unlikely(xl->spinners))
-		xen_spin_unlock_slow(xl);
-}
-#endif
-
 static irqreturn_t dummy_handler(int irq, void *dev_id)
 {
 	BUG();
@@ -391,15 +225,8 @@ void xen_uninit_lock_cpu(int cpu)
 
 void __init xen_init_spinlocks(void)
 {
-	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
-#if 0
-	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
-	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
-	pv_lock_ops.spin_lock = xen_spin_lock;
-	pv_lock_ops.spin_lock_flags = xen_spin_lock_flags;
-	pv_lock_ops.spin_trylock = xen_spin_trylock;
-	pv_lock_ops.spin_unlock = xen_spin_unlock;
-#endif
+	pv_lock_ops.lock_spinning = xen_lock_spinning;
+	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }
 
 #ifdef CONFIG_XEN_DEBUG_FS
@@ -417,42 +244,25 @@ static int __init xen_spinlock_debugfs(void)
 
 	debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats);
 
-	debugfs_create_u32("timeout", 0644, d_spin_debug, &lock_timeout);
-
-	debugfs_create_u64("taken", 0444, d_spin_debug, &spinlock_stats.taken);
 	debugfs_create_u32("taken_slow", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow);
-	debugfs_create_u32("taken_slow_nested", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_nested);
+			   &spinlock_stats.contention_stats[TAKEN_SLOW]);
 	debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_pickup);
+			   &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]);
 	debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_spurious);
-	debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_irqenable);
+			   &spinlock_stats.contention_stats[TAKEN_SLOW_SPURIOUS]);
 
-	debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.released);
 	debugfs_create_u32("released_slow", 0444, d_spin_debug,
-			   &spinlock_stats.released_slow);
+			   &spinlock_stats.contention_stats[RELEASED_SLOW]);
 	debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug,
-			   &spinlock_stats.released_slow_kicked);
+			   &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]);
 
-	debugfs_create_u64("time_spinning", 0444, d_spin_debug,
-			   &spinlock_stats.time_spinning);
 	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
 			   &spinlock_stats.time_blocked);
-	debugfs_create_u64("time_total", 0444, d_spin_debug,
-			   &spinlock_stats.time_total);
 
-	debugfs_create_u32_array("histo_total", 0444, d_spin_debug,
-				     spinlock_stats.histo_spin_total, HISTO_BUCKETS + 1);
-	debugfs_create_u32_array("histo_spinning", 0444, d_spin_debug,
-				     spinlock_stats.histo_spin_spinning, HISTO_BUCKETS + 1);
 	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
 				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
 
 	return 0;
 }
 fs_initcall(xen_spinlock_debugfs);
-
 #endif	/* CONFIG_XEN_DEBUG_FS */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIb-00035P-1V; Sat, 21 Apr 2012 21:56:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxkY-0005Vj-M9
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:14:43 +0000
Received: from [85.158.139.83:55673] by server-11.bemta-5.messagelabs.com id
	A0/FA-12959-132709F4; Thu, 19 Apr 2012 20:14:41 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1334866476!21910782!1
X-Originating-IP: [202.81.31.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAyNDM2ODM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29672 invoked from network); 19 Apr 2012 20:14:39 -0000
Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:14:39 -0000
Received: from /spool/local
	by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:05:25 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:05:23 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JK7sIX2215990
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:07:54 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKEVFJ029945
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:14:32 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKEI7W029786; Fri, 20 Apr 2012 06:14:23 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:44:12 +0530
Message-Id: <20120419201409.5411.35328.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-6102-0000-0000-00000147F414
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 5/12] xen/pvticketlock: Xen
	implementation for PV ticket locks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Replace the old Xen implementation of PV spinlocks with and implementation
of xen_lock_spinning and xen_unlock_kick.

xen_lock_spinning simply registers the cpu in its entry in lock_waiting,
adds itself to the waiting_cpus set, and blocks on an event channel
until the channel becomes pending.

xen_unlock_kick searches the cpus in waiting_cpus looking for the one
which next wants this lock with the next ticket, if any.  If found,
it kicks it by making its event channel pending, which wakes it up.

We need to make sure interrupts are disabled while we're relying on the
contents of the per-cpu lock_waiting values, otherwise an interrupt
handler could come in, try to take some other lock, block, and overwrite
our values.

Raghu: use function + enum instead of macro, cmpxchg for zero status reset

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/spinlock.c |  344 +++++++++++------------------------------------
 1 files changed, 77 insertions(+), 267 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index f1f4540..982e64b 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -16,45 +16,46 @@
 #include "xen-ops.h"
 #include "debugfs.h"
 
+enum xen_contention_stat {
+	TAKEN_SLOW,
+	TAKEN_SLOW_PICKUP,
+	TAKEN_SLOW_SPURIOUS,
+	RELEASED_SLOW,
+	RELEASED_SLOW_KICKED,
+	NR_CONTENTION_STATS
+};
+
+
 #ifdef CONFIG_XEN_DEBUG_FS
 static struct xen_spinlock_stats
 {
-	u64 taken;
-	u32 taken_slow;
-	u32 taken_slow_nested;
-	u32 taken_slow_pickup;
-	u32 taken_slow_spurious;
-	u32 taken_slow_irqenable;
-
-	u64 released;
-	u32 released_slow;
-	u32 released_slow_kicked;
+	u32 contention_stats[NR_CONTENTION_STATS];
 
 #define HISTO_BUCKETS	30
-	u32 histo_spin_total[HISTO_BUCKETS+1];
-	u32 histo_spin_spinning[HISTO_BUCKETS+1];
 	u32 histo_spin_blocked[HISTO_BUCKETS+1];
 
-	u64 time_total;
-	u64 time_spinning;
 	u64 time_blocked;
 } spinlock_stats;
 
 static u8 zero_stats;
 
-static unsigned lock_timeout = 1 << 10;
-#define TIMEOUT lock_timeout
-
 static inline void check_zero(void)
 {
-	if (unlikely(zero_stats)) {
-		memset(&spinlock_stats, 0, sizeof(spinlock_stats));
-		zero_stats = 0;
+	u8 ret;
+	u8 old = ACCESS_ONCE(zero_stats);
+	if (unlikely(old)) {
+		ret = cmpxchg(&zero_stats, old, 0);
+		/* This ensures only one fellow resets the stat */
+		if (ret == old)
+			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
 	}
 }
 
-#define ADD_STATS(elem, val)			\
-	do { check_zero(); spinlock_stats.elem += (val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+	check_zero();
+	spinlock_stats.contention_stats[var] += val;
+}
 
 static inline u64 spin_time_start(void)
 {
@@ -73,22 +74,6 @@ static void __spin_time_accum(u64 delta, u32 *array)
 		array[HISTO_BUCKETS]++;
 }
 
-static inline void spin_time_accum_spinning(u64 start)
-{
-	u32 delta = xen_clocksource_read() - start;
-
-	__spin_time_accum(delta, spinlock_stats.histo_spin_spinning);
-	spinlock_stats.time_spinning += delta;
-}
-
-static inline void spin_time_accum_total(u64 start)
-{
-	u32 delta = xen_clocksource_read() - start;
-
-	__spin_time_accum(delta, spinlock_stats.histo_spin_total);
-	spinlock_stats.time_total += delta;
-}
-
 static inline void spin_time_accum_blocked(u64 start)
 {
 	u32 delta = xen_clocksource_read() - start;
@@ -98,19 +83,15 @@ static inline void spin_time_accum_blocked(u64 start)
 }
 #else  /* !CONFIG_XEN_DEBUG_FS */
 #define TIMEOUT			(1 << 10)
-#define ADD_STATS(elem, val)	do { (void)(val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+}
 
 static inline u64 spin_time_start(void)
 {
 	return 0;
 }
 
-static inline void spin_time_accum_total(u64 start)
-{
-}
-static inline void spin_time_accum_spinning(u64 start)
-{
-}
 static inline void spin_time_accum_blocked(u64 start)
 {
 }
@@ -133,230 +114,83 @@ typedef u16 xen_spinners_t;
 	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
 #endif
 
-struct xen_spinlock {
-	unsigned char lock;		/* 0 -> free; 1 -> locked */
-	xen_spinners_t spinners;	/* count of waiting cpus */
+struct xen_lock_waiting {
+	struct arch_spinlock *lock;
+	__ticket_t want;
 };
 
 static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
+static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting);
+static cpumask_t waiting_cpus;
 
-#if 0
-static int xen_spin_is_locked(struct arch_spinlock *lock)
+static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 {
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-
-	return xl->lock != 0;
-}
-
-static int xen_spin_is_contended(struct arch_spinlock *lock)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-
-	/* Not strictly true; this is only the count of contended
-	   lock-takers entering the slow path. */
-	return xl->spinners != 0;
-}
-
-static int xen_spin_trylock(struct arch_spinlock *lock)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-	u8 old = 1;
-
-	asm("xchgb %b0,%1"
-	    : "+q" (old), "+m" (xl->lock) : : "memory");
-
-	return old == 0;
-}
-
-static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
-
-/*
- * Mark a cpu as interested in a lock.  Returns the CPU's previous
- * lock of interest, in case we got preempted by an interrupt.
- */
-static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
-{
-	struct xen_spinlock *prev;
-
-	prev = __this_cpu_read(lock_spinners);
-	__this_cpu_write(lock_spinners, xl);
-
-	wmb();			/* set lock of interest before count */
-
-	inc_spinners(xl);
-
-	return prev;
-}
-
-/*
- * Mark a cpu as no longer interested in a lock.  Restores previous
- * lock of interest (NULL for none).
- */
-static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
-{
-	dec_spinners(xl);
-	wmb();			/* decrement count before restoring lock */
-	__this_cpu_write(lock_spinners, prev);
-}
-
-static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool irq_enable)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-	struct xen_spinlock *prev;
 	int irq = __this_cpu_read(lock_kicker_irq);
-	int ret;
+	struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting);
+	int cpu = smp_processor_id();
 	u64 start;
+	unsigned long flags;
 
 	/* If kicker interrupts not initialized yet, just spin */
 	if (irq == -1)
-		return 0;
+		return;
 
 	start = spin_time_start();
 
-	/* announce we're spinning */
-	prev = spinning_lock(xl);
-
-	ADD_STATS(taken_slow, 1);
-	ADD_STATS(taken_slow_nested, prev != NULL);
-
-	do {
-		unsigned long flags;
-
-		/* clear pending */
-		xen_clear_irq_pending(irq);
-
-		/* check again make sure it didn't become free while
-		   we weren't looking  */
-		ret = xen_spin_trylock(lock);
-		if (ret) {
-			ADD_STATS(taken_slow_pickup, 1);
-
-			/*
-			 * If we interrupted another spinlock while it
-			 * was blocking, make sure it doesn't block
-			 * without rechecking the lock.
-			 */
-			if (prev != NULL)
-				xen_set_irq_pending(irq);
-			goto out;
-		}
+	/*
+	 * Make sure an interrupt handler can't upset things in a
+	 * partially setup state.
+	 */
+	local_irq_save(flags);
 
-		flags = arch_local_save_flags();
-		if (irq_enable) {
-			ADD_STATS(taken_slow_irqenable, 1);
-			raw_local_irq_enable();
-		}
+	w->want = want;
+	smp_wmb();
+	w->lock = lock;
 
-		/*
-		 * Block until irq becomes pending.  If we're
-		 * interrupted at this point (after the trylock but
-		 * before entering the block), then the nested lock
-		 * handler guarantees that the irq will be left
-		 * pending if there's any chance the lock became free;
-		 * xen_poll_irq() returns immediately if the irq is
-		 * pending.
-		 */
-		xen_poll_irq(irq);
+	/* This uses set_bit, which atomic and therefore a barrier */
+	cpumask_set_cpu(cpu, &waiting_cpus);
+	add_stats(TAKEN_SLOW, 1);
 
-		raw_local_irq_restore(flags);
+	/* clear pending */
+	xen_clear_irq_pending(irq);
 
-		ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq));
-	} while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */
+	/* Only check lock once pending cleared */
+	barrier();
 
+	/* check again make sure it didn't become free while
+	   we weren't looking  */
+	if (ACCESS_ONCE(lock->tickets.head) == want) {
+		add_stats(TAKEN_SLOW_PICKUP, 1);
+		goto out;
+	}
+	/* Block until irq becomes pending (or perhaps a spurious wakeup) */
+	xen_poll_irq(irq);
+	add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq));
 	kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq));
-
 out:
-	unspinning_lock(xl, prev);
+	cpumask_clear_cpu(cpu, &waiting_cpus);
+	w->lock = NULL;
+	local_irq_restore(flags);
 	spin_time_accum_blocked(start);
-
-	return ret;
 }
 
-static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_enable)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-	unsigned timeout;
-	u8 oldval;
-	u64 start_spin;
-
-	ADD_STATS(taken, 1);
-
-	start_spin = spin_time_start();
-
-	do {
-		u64 start_spin_fast = spin_time_start();
-
-		timeout = TIMEOUT;
-
-		asm("1: xchgb %1,%0\n"
-		    "   testb %1,%1\n"
-		    "   jz 3f\n"
-		    "2: rep;nop\n"
-		    "   cmpb $0,%0\n"
-		    "   je 1b\n"
-		    "   dec %2\n"
-		    "   jnz 2b\n"
-		    "3:\n"
-		    : "+m" (xl->lock), "=q" (oldval), "+r" (timeout)
-		    : "1" (1)
-		    : "memory");
-
-		spin_time_accum_spinning(start_spin_fast);
-
-	} while (unlikely(oldval != 0 &&
-			  (TIMEOUT == ~0 || !xen_spin_lock_slow(lock, irq_enable))));
-
-	spin_time_accum_total(start_spin);
-}
-
-static void xen_spin_lock(struct arch_spinlock *lock)
-{
-	__xen_spin_lock(lock, false);
-}
-
-static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags)
-{
-	__xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
-}
-
-static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
+static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next)
 {
 	int cpu;
 
-	ADD_STATS(released_slow, 1);
+	add_stats(RELEASED_SLOW, 1);
 
-	for_each_online_cpu(cpu) {
-		/* XXX should mix up next cpu selection */
-		if (per_cpu(lock_spinners, cpu) == xl) {
-			ADD_STATS(released_slow_kicked, 1);
+	for_each_cpu(cpu, &waiting_cpus) {
+		const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu);
+
+		if (w->lock == lock && w->want == next) {
+			add_stats(RELEASED_SLOW_KICKED, 1);
 			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
 			break;
 		}
 	}
 }
 
-static void xen_spin_unlock(struct arch_spinlock *lock)
-{
-	struct xen_spinlock *xl = (struct xen_spinlock *)lock;
-
-	ADD_STATS(released, 1);
-
-	smp_wmb();		/* make sure no writes get moved after unlock */
-	xl->lock = 0;		/* release lock */
-
-	/*
-	 * Make sure unlock happens before checking for waiting
-	 * spinners.  We need a strong barrier to enforce the
-	 * write-read ordering to different memory locations, as the
-	 * CPU makes no implied guarantees about their ordering.
-	 */
-	mb();
-
-	if (unlikely(xl->spinners))
-		xen_spin_unlock_slow(xl);
-}
-#endif
-
 static irqreturn_t dummy_handler(int irq, void *dev_id)
 {
 	BUG();
@@ -391,15 +225,8 @@ void xen_uninit_lock_cpu(int cpu)
 
 void __init xen_init_spinlocks(void)
 {
-	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
-#if 0
-	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
-	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
-	pv_lock_ops.spin_lock = xen_spin_lock;
-	pv_lock_ops.spin_lock_flags = xen_spin_lock_flags;
-	pv_lock_ops.spin_trylock = xen_spin_trylock;
-	pv_lock_ops.spin_unlock = xen_spin_unlock;
-#endif
+	pv_lock_ops.lock_spinning = xen_lock_spinning;
+	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }
 
 #ifdef CONFIG_XEN_DEBUG_FS
@@ -417,42 +244,25 @@ static int __init xen_spinlock_debugfs(void)
 
 	debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats);
 
-	debugfs_create_u32("timeout", 0644, d_spin_debug, &lock_timeout);
-
-	debugfs_create_u64("taken", 0444, d_spin_debug, &spinlock_stats.taken);
 	debugfs_create_u32("taken_slow", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow);
-	debugfs_create_u32("taken_slow_nested", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_nested);
+			   &spinlock_stats.contention_stats[TAKEN_SLOW]);
 	debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_pickup);
+			   &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]);
 	debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_spurious);
-	debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_irqenable);
+			   &spinlock_stats.contention_stats[TAKEN_SLOW_SPURIOUS]);
 
-	debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.released);
 	debugfs_create_u32("released_slow", 0444, d_spin_debug,
-			   &spinlock_stats.released_slow);
+			   &spinlock_stats.contention_stats[RELEASED_SLOW]);
 	debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug,
-			   &spinlock_stats.released_slow_kicked);
+			   &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]);
 
-	debugfs_create_u64("time_spinning", 0444, d_spin_debug,
-			   &spinlock_stats.time_spinning);
 	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
 			   &spinlock_stats.time_blocked);
-	debugfs_create_u64("time_total", 0444, d_spin_debug,
-			   &spinlock_stats.time_total);
 
-	debugfs_create_u32_array("histo_total", 0444, d_spin_debug,
-				     spinlock_stats.histo_spin_total, HISTO_BUCKETS + 1);
-	debugfs_create_u32_array("histo_spinning", 0444, d_spin_debug,
-				     spinlock_stats.histo_spin_spinning, HISTO_BUCKETS + 1);
 	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
 				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
 
 	return 0;
 }
 fs_initcall(xen_spinlock_debugfs);
-
 #endif	/* CONFIG_XEN_DEBUG_FS */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIe-00038e-Ls; Sat, 21 Apr 2012 21:57:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxw5-0005bK-Sv
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:26:38 +0000
Received: from [193.109.254.147:6108] by server-1.bemta-14.messagelabs.com id
	ED/17-29372-DF4709F4; Thu, 19 Apr 2012 20:26:37 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334867191!2311787!1
X-Originating-IP: [202.81.31.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MiA9PiAxNjg1Njc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22609 invoked from network); 19 Apr 2012 20:26:35 -0000
Received: from e23smtp09.au.ibm.com (HELO e23smtp09.au.ibm.com) (202.81.31.142)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:26:35 -0000
Received: from /spool/local
	by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 21:15:44 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 21:15:44 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKQQJK37224456
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:26:30 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKQPG3000944
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:26:26 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFqYX015686; Fri, 20 Apr 2012 06:15:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:46 +0530
Message-Id: <20120419201543.5411.37767.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041911-3568-0000-0000-000001925886
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 9/12] split out rate limiting from
	jump_label.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andrew Jones <drjones@redhat.com>

Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting
for jump label disabling. The changes were made in the jump label code
in order to be more widely available and to keep things tidier. This is
all fine, except now jump_label.h includes linux/workqueue.h, which
makes it impossible to include jump_label.h from anything that
workqueue.h needs. For example, it's now impossible to include
jump_label.h from asm/spinlock.h, which is done in proposed
pv-ticketlock patches. This patch splits out the rate limiting related
changes from jump_label.h into a new file, jump_label_ratelimit.h, to
resolve the issue.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 include/linux/jump_label.h           |   26 +-------------------------
 include/linux/jump_label_ratelimit.h |   34 ++++++++++++++++++++++++++++++++++
 include/linux/perf_event.h           |    1 +
 kernel/jump_label.c                  |    1 +
 4 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index c513a40..8195227 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -49,7 +49,6 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
-#include <linux/workqueue.h>
 
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 
@@ -62,12 +61,6 @@ struct static_key {
 #endif
 };
 
-struct static_key_deferred {
-	struct static_key key;
-	unsigned long timeout;
-	struct delayed_work work;
-};
-
 # include <asm/jump_label.h>
 # define HAVE_JUMP_LABEL
 #endif	/* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry,
 extern int jump_label_text_reserved(void *start, void *end);
 extern void static_key_slow_inc(struct static_key *key);
 extern void static_key_slow_dec(struct static_key *key);
-extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
 extern void jump_label_apply_nops(struct module *mod);
-extern void
-jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
 
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 	{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
@@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void)
 {
 }
 
-struct static_key_deferred {
-	struct static_key  key;
-};
-
 static __always_inline bool static_key_false(struct static_key *key)
 {
 	if (unlikely(atomic_read(&key->enabled)) > 0)
@@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key)
 	atomic_dec(&key->enabled);
 }
 
-static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
-{
-	static_key_slow_dec(&key->key);
-}
-
 static inline int jump_label_text_reserved(void *start, void *end)
 {
 	return 0;
@@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 	return 0;
 }
 
-static inline void
-jump_label_rate_limit(struct static_key_deferred *key,
-		unsigned long rl)
-{
-}
-
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 		{ .enabled = ATOMIC_INIT(1) })
 #define STATIC_KEY_INIT_FALSE ((struct static_key) \
@@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key,
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
+static inline int atomic_read(const atomic_t *v);
 static inline bool static_key_enabled(struct static_key *key)
 {
 	return (atomic_read(&key->enabled) > 0);
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
new file mode 100644
index 0000000..1137883
--- /dev/null
+++ b/include/linux/jump_label_ratelimit.h
@@ -0,0 +1,34 @@
+#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H
+#define _LINUX_JUMP_LABEL_RATELIMIT_H
+
+#include <linux/jump_label.h>
+#include <linux/workqueue.h>
+
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+struct static_key_deferred {
+	struct static_key key;
+	unsigned long timeout;
+	struct delayed_work work;
+};
+#endif
+
+#ifdef HAVE_JUMP_LABEL
+extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void
+jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
+
+#else	/* !HAVE_JUMP_LABEL */
+struct static_key_deferred {
+	struct static_key  key;
+};
+static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
+{
+	static_key_slow_dec(&key->key);
+}
+static inline void
+jump_label_rate_limit(struct static_key_deferred *key,
+		unsigned long rl)
+{
+}
+#endif	/* HAVE_JUMP_LABEL */
+#endif	/* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index ddbb6a9..a0e6118 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -605,6 +605,7 @@ struct perf_guest_info_callbacks {
 #include <linux/cpu.h>
 #include <linux/irq_work.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 #include <linux/atomic.h>
 #include <linux/sysfs.h>
 #include <asm/local.h>
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 4304919..e17f8d6 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -13,6 +13,7 @@
 #include <linux/sort.h>
 #include <linux/err.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 
 #ifdef HAVE_JUMP_LABEL
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIY-000345-HJ; Sat, 21 Apr 2012 21:56:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bxl1989@gmail.com>) id 1SKUgp-0006a3-Qc
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 13:12:55 +0000
Received: from [85.158.138.51:64965] by server-12.bemta-3.messagelabs.com id
	60/7B-29760-6DDBE8F4; Wed, 18 Apr 2012 13:12:54 +0000
X-Env-Sender: bxl1989@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334754773!22654134!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19793 invoked from network); 18 Apr 2012 13:12:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Apr 2012 13:12:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <bxl1989@gmail.com>) id 1SKUgm-0006Ak-Do
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 06:12:52 -0700
Date: Wed, 18 Apr 2012 06:12:52 -0700 (PDT)
From: bxl1989 <bxl1989@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334754772414-5649046.post@n5.nabble.com>
In-Reply-To: <1334732874701-5648377.post@n5.nabble.com>
References: <1334732874701-5648377.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:53 +0000
Subject: Re: [Xen-devel] make hypercall in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

please anyone help me! thans a lot

--
View this message in context: http://xen.1045712.n5.nabble.com/make-hypercall-in-domU-tp5648377p5649046.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIY-000345-HJ; Sat, 21 Apr 2012 21:56:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bxl1989@gmail.com>) id 1SKUgp-0006a3-Qc
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 13:12:55 +0000
Received: from [85.158.138.51:64965] by server-12.bemta-3.messagelabs.com id
	60/7B-29760-6DDBE8F4; Wed, 18 Apr 2012 13:12:54 +0000
X-Env-Sender: bxl1989@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1334754773!22654134!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19793 invoked from network); 18 Apr 2012 13:12:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Apr 2012 13:12:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <bxl1989@gmail.com>) id 1SKUgm-0006Ak-Do
	for xen-devel@lists.xensource.com; Wed, 18 Apr 2012 06:12:52 -0700
Date: Wed, 18 Apr 2012 06:12:52 -0700 (PDT)
From: bxl1989 <bxl1989@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1334754772414-5649046.post@n5.nabble.com>
In-Reply-To: <1334732874701-5648377.post@n5.nabble.com>
References: <1334732874701-5648377.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:53 +0000
Subject: Re: [Xen-devel] make hypercall in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

please anyone help me! thans a lot

--
View this message in context: http://xen.1045712.n5.nabble.com/make-hypercall-in-domU-tp5648377p5649046.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIe-00038e-Ls; Sat, 21 Apr 2012 21:57:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxw5-0005bK-Sv
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:26:38 +0000
Received: from [193.109.254.147:6108] by server-1.bemta-14.messagelabs.com id
	ED/17-29372-DF4709F4; Thu, 19 Apr 2012 20:26:37 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1334867191!2311787!1
X-Originating-IP: [202.81.31.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MiA9PiAxNjg1Njc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22609 invoked from network); 19 Apr 2012 20:26:35 -0000
Received: from e23smtp09.au.ibm.com (HELO e23smtp09.au.ibm.com) (202.81.31.142)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:26:35 -0000
Received: from /spool/local
	by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 21:15:44 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 21:15:44 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKQQJK37224456
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:26:30 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKQPG3000944
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:26:26 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKFqYX015686; Fri, 20 Apr 2012 06:15:58 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:46 +0530
Message-Id: <20120419201543.5411.37767.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041911-3568-0000-0000-000001925886
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 9/12] split out rate limiting from
	jump_label.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andrew Jones <drjones@redhat.com>

Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting
for jump label disabling. The changes were made in the jump label code
in order to be more widely available and to keep things tidier. This is
all fine, except now jump_label.h includes linux/workqueue.h, which
makes it impossible to include jump_label.h from anything that
workqueue.h needs. For example, it's now impossible to include
jump_label.h from asm/spinlock.h, which is done in proposed
pv-ticketlock patches. This patch splits out the rate limiting related
changes from jump_label.h into a new file, jump_label_ratelimit.h, to
resolve the issue.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 include/linux/jump_label.h           |   26 +-------------------------
 include/linux/jump_label_ratelimit.h |   34 ++++++++++++++++++++++++++++++++++
 include/linux/perf_event.h           |    1 +
 kernel/jump_label.c                  |    1 +
 4 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index c513a40..8195227 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -49,7 +49,6 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
-#include <linux/workqueue.h>
 
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 
@@ -62,12 +61,6 @@ struct static_key {
 #endif
 };
 
-struct static_key_deferred {
-	struct static_key key;
-	unsigned long timeout;
-	struct delayed_work work;
-};
-
 # include <asm/jump_label.h>
 # define HAVE_JUMP_LABEL
 #endif	/* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry,
 extern int jump_label_text_reserved(void *start, void *end);
 extern void static_key_slow_inc(struct static_key *key);
 extern void static_key_slow_dec(struct static_key *key);
-extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
 extern void jump_label_apply_nops(struct module *mod);
-extern void
-jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
 
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 	{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
@@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void)
 {
 }
 
-struct static_key_deferred {
-	struct static_key  key;
-};
-
 static __always_inline bool static_key_false(struct static_key *key)
 {
 	if (unlikely(atomic_read(&key->enabled)) > 0)
@@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key)
 	atomic_dec(&key->enabled);
 }
 
-static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
-{
-	static_key_slow_dec(&key->key);
-}
-
 static inline int jump_label_text_reserved(void *start, void *end)
 {
 	return 0;
@@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 	return 0;
 }
 
-static inline void
-jump_label_rate_limit(struct static_key_deferred *key,
-		unsigned long rl)
-{
-}
-
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
 		{ .enabled = ATOMIC_INIT(1) })
 #define STATIC_KEY_INIT_FALSE ((struct static_key) \
@@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key,
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
+static inline int atomic_read(const atomic_t *v);
 static inline bool static_key_enabled(struct static_key *key)
 {
 	return (atomic_read(&key->enabled) > 0);
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
new file mode 100644
index 0000000..1137883
--- /dev/null
+++ b/include/linux/jump_label_ratelimit.h
@@ -0,0 +1,34 @@
+#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H
+#define _LINUX_JUMP_LABEL_RATELIMIT_H
+
+#include <linux/jump_label.h>
+#include <linux/workqueue.h>
+
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+struct static_key_deferred {
+	struct static_key key;
+	unsigned long timeout;
+	struct delayed_work work;
+};
+#endif
+
+#ifdef HAVE_JUMP_LABEL
+extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void
+jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
+
+#else	/* !HAVE_JUMP_LABEL */
+struct static_key_deferred {
+	struct static_key  key;
+};
+static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
+{
+	static_key_slow_dec(&key->key);
+}
+static inline void
+jump_label_rate_limit(struct static_key_deferred *key,
+		unsigned long rl)
+{
+}
+#endif	/* HAVE_JUMP_LABEL */
+#endif	/* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index ddbb6a9..a0e6118 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -605,6 +605,7 @@ struct perf_guest_info_callbacks {
 #include <linux/cpu.h>
 #include <linux/irq_work.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 #include <linux/atomic.h>
 #include <linux/sysfs.h>
 #include <asm/local.h>
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 4304919..e17f8d6 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -13,6 +13,7 @@
 #include <linux/sort.h>
 #include <linux/err.h>
 #include <linux/static_key.h>
+#include <linux/jump_label_ratelimit.h>
 
 #ifdef HAVE_JUMP_LABEL
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIb-000364-R0; Sat, 21 Apr 2012 21:56:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxlE-0005X8-Pr
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:15:25 +0000
Received: from [85.158.138.51:6835] by server-6.bemta-3.messagelabs.com id
	58/B6-05145-B52709F4; Thu, 19 Apr 2012 20:15:23 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334866520!18751042!1
X-Originating-IP: [122.248.162.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxNzkyNTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21398 invoked from network); 19 Apr 2012 20:15:23 -0000
Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:15:23 -0000
Received: from /spool/local
	by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:45:19 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:45:17 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKFGwG4599912
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:45:16 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1it9P013719
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 07:14:58 +0530
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1iml9013475; Fri, 20 Apr 2012 07:14:53 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:00 +0530
Message-Id: <20120419201456.5411.85454.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-8256-0000-0000-0000020F82AF
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 7/12] x86/pvticketlock: use callee-save
	for lock_spinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Although the lock_spinning calls in the spinlock code are on the
uncommon path, their presence can cause the compiler to generate many
more register save/restores in the function pre/postamble, which is in
the fast path.  To avoid this, convert it to using the pvops callee-save
calling convention, which defers all the save/restores until the actual
function is called, keeping the fastpath clean.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/paravirt.h       |    2 +-
 arch/x86/include/asm/paravirt_types.h |    2 +-
 arch/x86/kernel/paravirt-spinlocks.c  |    2 +-
 arch/x86/xen/spinlock.c               |    3 ++-
 4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 4bcd146..9769096 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -754,7 +754,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
 							__ticket_t ticket)
 {
-	PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket);
+	PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
 }
 
 static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 005e24d..5e0c138 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -330,7 +330,7 @@ struct arch_spinlock;
 #include <asm/spinlock_types.h>
 
 struct pv_lock_ops {
-	void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket);
+	struct paravirt_callee_save lock_spinning;
 	void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
 };
 
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index c2e010e..4251c1d 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -9,7 +9,7 @@
 
 struct pv_lock_ops pv_lock_ops = {
 #ifdef CONFIG_SMP
-	.lock_spinning = paravirt_nop,
+	.lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop),
 	.unlock_kick = paravirt_nop,
 #endif
 };
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index c9bf890..b0cdde1 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -173,6 +173,7 @@ out:
 	local_irq_restore(flags);
 	spin_time_accum_blocked(start);
 }
+PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning);
 
 static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next)
 {
@@ -232,7 +233,7 @@ void __init xen_init_spinlocks(void)
 		return;
 	}
 
-	pv_lock_ops.lock_spinning = xen_lock_spinning;
+	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning);
 	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIb-000364-R0; Sat, 21 Apr 2012 21:56:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxlE-0005X8-Pr
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:15:25 +0000
Received: from [85.158.138.51:6835] by server-6.bemta-3.messagelabs.com id
	58/B6-05145-B52709F4; Thu, 19 Apr 2012 20:15:23 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1334866520!18751042!1
X-Originating-IP: [122.248.162.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxNzkyNTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21398 invoked from network); 19 Apr 2012 20:15:23 -0000
Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Apr 2012 20:15:23 -0000
Received: from /spool/local
	by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:45:19 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:45:17 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKFGwG4599912
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:45:16 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1it9P013719
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 07:14:58 +0530
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1iml9013475; Fri, 20 Apr 2012 07:14:53 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:45:00 +0530
Message-Id: <20120419201456.5411.85454.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-8256-0000-0000-0000020F82AF
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 7/12] x86/pvticketlock: use callee-save
	for lock_spinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Although the lock_spinning calls in the spinlock code are on the
uncommon path, their presence can cause the compiler to generate many
more register save/restores in the function pre/postamble, which is in
the fast path.  To avoid this, convert it to using the pvops callee-save
calling convention, which defers all the save/restores until the actual
function is called, keeping the fastpath clean.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Attilio Rao <attilio.rao@citrix.com> 
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/include/asm/paravirt.h       |    2 +-
 arch/x86/include/asm/paravirt_types.h |    2 +-
 arch/x86/kernel/paravirt-spinlocks.c  |    2 +-
 arch/x86/xen/spinlock.c               |    3 ++-
 4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 4bcd146..9769096 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -754,7 +754,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
 							__ticket_t ticket)
 {
-	PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket);
+	PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
 }
 
 static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock,
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 005e24d..5e0c138 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -330,7 +330,7 @@ struct arch_spinlock;
 #include <asm/spinlock_types.h>
 
 struct pv_lock_ops {
-	void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket);
+	struct paravirt_callee_save lock_spinning;
 	void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
 };
 
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index c2e010e..4251c1d 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -9,7 +9,7 @@
 
 struct pv_lock_ops pv_lock_ops = {
 #ifdef CONFIG_SMP
-	.lock_spinning = paravirt_nop,
+	.lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop),
 	.unlock_kick = paravirt_nop,
 #endif
 };
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index c9bf890..b0cdde1 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -173,6 +173,7 @@ out:
 	local_irq_restore(flags);
 	spin_time_accum_blocked(start);
 }
+PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning);
 
 static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next)
 {
@@ -232,7 +233,7 @@ void __init xen_init_spinlocks(void)
 		return;
 	}
 
-	pv_lock_ops.lock_spinning = xen_lock_spinning;
+	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning);
 	pv_lock_ops.unlock_kick = xen_unlock_kick;
 }
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiId-00037h-Rh; Sat, 21 Apr 2012 21:56:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxmr-0005Zf-5J
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:17:05 +0000
Received: from [85.158.143.99:45897] by server-3.bemta-4.messagelabs.com id
	52/0D-05853-0C2709F4; Thu, 19 Apr 2012 20:17:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334866618!13227195!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiAxMjgxMjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23368 invoked from network); 19 Apr 2012 20:17:02 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:17:02 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:14:16 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:14:13 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKAFlP2187274
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:10:15 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKGqwK029238
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:16:53 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKGeWJ029010; Fri, 20 Apr 2012 06:16:45 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:46:34 +0530
Message-Id: <20120419201631.5411.15263.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-5140-0000-0000-0000011AEB93
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 11/12] xen/pvticketlock: allow interrupts
	to be enabled while blocking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

If interrupts were enabled when taking the spinlock, we can leave them
enabled while blocking to get the lock.

If we can enable interrupts while waiting for the lock to become
available, and we take an interrupt before entering the poll,
and the handler takes a spinlock which ends up going into
the slow state (invalidating the per-cpu "lock" and "want" values),
then when the interrupt handler returns the event channel will
remain pending so the poll will return immediately, causing it to
return out to the main spinlock loop.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/spinlock.c |   46 ++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index e2f312f..d2ab57a 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -142,7 +142,20 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 	 * partially setup state.
 	 */
 	local_irq_save(flags);
-
+	/*
+	 * We don't really care if we're overwriting some other
+	 * (lock,want) pair, as that would mean that we're currently
+	 * in an interrupt context, and the outer context had
+	 * interrupts enabled.  That has already kicked the VCPU out
+	 * of xen_poll_irq(), so it will just return spuriously and
+	 * retry with newly setup (lock,want).
+	 *
+	 * The ordering protocol on this is that the "lock" pointer
+	 * may only be set non-NULL if the "want" ticket is correct.
+	 * If we're updating "want", we must first clear "lock".
+	 */
+	w->lock = NULL;
+	smp_wmb();
 	w->want = want;
 	smp_wmb();
 	w->lock = lock;
@@ -157,24 +170,43 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 	/* Only check lock once pending cleared */
 	barrier();
 
-	/* Mark entry to slowpath before doing the pickup test to make
-	   sure we don't deadlock with an unlocker. */
+	/*
+	 * Mark entry to slowpath before doing the pickup test to make
+	 * sure we don't deadlock with an unlocker.
+	 */
 	__ticket_enter_slowpath(lock);
 
-	/* check again make sure it didn't become free while
-	   we weren't looking  */
+	/*
+	 * check again make sure it didn't become free while
+	 * we weren't looking
+	 */
 	if (ACCESS_ONCE(lock->tickets.head) == want) {
 		add_stats(TAKEN_SLOW_PICKUP, 1);
 		goto out;
 	}
+
+	/* Allow interrupts while blocked */
+	local_irq_restore(flags);
+
+	/*
+	 * If an interrupt happens here, it will leave the wakeup irq
+	 * pending, which will cause xen_poll_irq() to return
+	 * immediately.
+	 */
+
 	/* Block until irq becomes pending (or perhaps a spurious wakeup) */
 	xen_poll_irq(irq);
 	add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq));
+
+	local_irq_save(flags);
+
 	kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq));
 out:
 	cpumask_clear_cpu(cpu, &waiting_cpus);
 	w->lock = NULL;
+
 	local_irq_restore(flags);
+
 	spin_time_accum_blocked(start);
 }
 PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning);
@@ -188,7 +220,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next)
 	for_each_cpu(cpu, &waiting_cpus) {
 		const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu);
 
-		if (w->lock == lock && w->want == next) {
+		/* Make sure we read lock before want */
+		if (ACCESS_ONCE(w->lock) == lock &&
+		    ACCESS_ONCE(w->want) == next) {
 			add_stats(RELEASED_SLOW_KICKED, 1);
 			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
 			break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiId-00037h-Rh; Sat, 21 Apr 2012 21:56:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxmr-0005Zf-5J
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:17:05 +0000
Received: from [85.158.143.99:45897] by server-3.bemta-4.messagelabs.com id
	52/0D-05853-0C2709F4; Thu, 19 Apr 2012 20:17:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1334866618!13227195!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiAxMjgxMjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23368 invoked from network); 19 Apr 2012 20:17:02 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:17:02 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 19 Apr 2012 20:14:16 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 19 Apr 2012 20:14:13 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKAFlP2187274
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:10:15 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3JKGqwK029238
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 06:16:53 +1000
Received: from [192.168.1.3] ([9.124.213.22])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3JKGeWJ029010; Fri, 20 Apr 2012 06:16:45 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:46:34 +0530
Message-Id: <20120419201631.5411.15263.sendpatchset@codeblue>
In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue>
References: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041910-5140-0000-0000-0000011AEB93
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 11/12] xen/pvticketlock: allow interrupts
	to be enabled while blocking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

If interrupts were enabled when taking the spinlock, we can leave them
enabled while blocking to get the lock.

If we can enable interrupts while waiting for the lock to become
available, and we take an interrupt before entering the poll,
and the handler takes a spinlock which ends up going into
the slow state (invalidating the per-cpu "lock" and "want" values),
then when the interrupt handler returns the event channel will
remain pending so the poll will return immediately, causing it to
return out to the main spinlock loop.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
 arch/x86/xen/spinlock.c |   46 ++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index e2f312f..d2ab57a 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -142,7 +142,20 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 	 * partially setup state.
 	 */
 	local_irq_save(flags);
-
+	/*
+	 * We don't really care if we're overwriting some other
+	 * (lock,want) pair, as that would mean that we're currently
+	 * in an interrupt context, and the outer context had
+	 * interrupts enabled.  That has already kicked the VCPU out
+	 * of xen_poll_irq(), so it will just return spuriously and
+	 * retry with newly setup (lock,want).
+	 *
+	 * The ordering protocol on this is that the "lock" pointer
+	 * may only be set non-NULL if the "want" ticket is correct.
+	 * If we're updating "want", we must first clear "lock".
+	 */
+	w->lock = NULL;
+	smp_wmb();
 	w->want = want;
 	smp_wmb();
 	w->lock = lock;
@@ -157,24 +170,43 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
 	/* Only check lock once pending cleared */
 	barrier();
 
-	/* Mark entry to slowpath before doing the pickup test to make
-	   sure we don't deadlock with an unlocker. */
+	/*
+	 * Mark entry to slowpath before doing the pickup test to make
+	 * sure we don't deadlock with an unlocker.
+	 */
 	__ticket_enter_slowpath(lock);
 
-	/* check again make sure it didn't become free while
-	   we weren't looking  */
+	/*
+	 * check again make sure it didn't become free while
+	 * we weren't looking
+	 */
 	if (ACCESS_ONCE(lock->tickets.head) == want) {
 		add_stats(TAKEN_SLOW_PICKUP, 1);
 		goto out;
 	}
+
+	/* Allow interrupts while blocked */
+	local_irq_restore(flags);
+
+	/*
+	 * If an interrupt happens here, it will leave the wakeup irq
+	 * pending, which will cause xen_poll_irq() to return
+	 * immediately.
+	 */
+
 	/* Block until irq becomes pending (or perhaps a spurious wakeup) */
 	xen_poll_irq(irq);
 	add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq));
+
+	local_irq_save(flags);
+
 	kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq));
 out:
 	cpumask_clear_cpu(cpu, &waiting_cpus);
 	w->lock = NULL;
+
 	local_irq_restore(flags);
+
 	spin_time_accum_blocked(start);
 }
 PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning);
@@ -188,7 +220,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next)
 	for_each_cpu(cpu, &waiting_cpus) {
 		const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu);
 
-		if (w->lock == lock && w->want == next) {
+		/* Make sure we read lock before want */
+		if (ACCESS_ONCE(w->lock) == lock &&
+		    ACCESS_ONCE(w->want) == next) {
 			add_stats(RELEASED_SLOW_KICKED, 1);
 			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
 			break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIY-00034N-VC; Sat, 21 Apr 2012 21:56:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxiY-0005Or-MJ
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:12:39 +0000
Received: from [85.158.138.51:54235] by server-7.bemta-3.messagelabs.com id
	C3/EE-03078-5B1709F4; Thu, 19 Apr 2012 20:12:37 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334866353!11927789!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA1MDc4Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28921 invoked from network); 19 Apr 2012 20:12:36 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:12:36 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:42:32 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:42:29 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKCSAd4571234
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:42:28 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1g8uM006237
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 07:12:10 +0530
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1g0Mq005578; Fri, 20 Apr 2012 07:12:05 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:42:12 +0530
Message-Id: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-8878-0000-0000-000002185B2F
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 0/12] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

This series replaces the existing paravirtualized spinlock mechanism
with a paravirtualized ticketlock mechanism. (targeted for 3.5 window)

Changes in V7:
 - Reabsed patches to 3.4-rc3
 - Added jumplabel split patch (originally from Andrew Jones rebased to
    3.4-rc3
 - jumplabel changes from Ingo and Jason taken and now using static_key_*
    instead of static_branch.
 - using UNINLINE_SPIN_UNLOCK (which was splitted as per suggestion from Linus)
 - This patch series is rebased on debugfs patch (that sould be already in
    Xen/linux-next https://lkml.org/lkml/2012/3/23/51)

Ticket locks have an inherent problem in a virtualized case, because
the vCPUs are scheduled rather than running concurrently (ignoring
gang scheduled vCPUs).  This can result in catastrophic performance
collapses when the vCPU scheduler doesn't schedule the correct "next"
vCPU, and ends up scheduling a vCPU which burns its entire timeslice
spinning.  (Note that this is not the same problem as lock-holder
preemption, which this series also addresses; that's also a problem,
but not catastrophic).

(See Thomas Friebel's talk "Prevent Guests from Spinning Around"
http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)

Currently we deal with this by having PV spinlocks, which adds a layer
of indirection in front of all the spinlock functions, and defining a
completely new implementation for Xen (and for other pvops users, but
there are none at present).

PV ticketlocks keeps the existing ticketlock implemenentation
(fastpath) as-is, but adds a couple of pvops for the slow paths:

- If a CPU has been waiting for a spinlock for SPIN_THRESHOLD
  iterations, then call out to the __ticket_lock_spinning() pvop,
  which allows a backend to block the vCPU rather than spinning.  This
  pvop can set the lock into "slowpath state".

- When releasing a lock, if it is in "slowpath state", the call
  __ticket_unlock_kick() to kick the next vCPU in line awake.  If the
  lock is no longer in contention, it also clears the slowpath flag.

The "slowpath state" is stored in the LSB of the within the lock tail
ticket.  This has the effect of reducing the max number of CPUs by
half (so, a "small ticket" can deal with 128 CPUs, and "large ticket"
32768).

This series provides a Xen implementation, KVM implementation will be
posted in next 2-3 days.

Overall, it results in a large reduction in code, it makes the native
and virtualized cases closer, and it removes a layer of indirection
around all the spinlock functions.

The fast path (taking an uncontended lock which isn't in "slowpath"
state) is optimal, identical to the non-paravirtualized case.

The inner part of ticket lock code becomes:
	inc = xadd(&lock->tickets, inc);
	inc.tail &= ~TICKET_SLOWPATH_FLAG;

	if (likely(inc.head == inc.tail))
		goto out;
	for (;;) {
		unsigned count = SPIN_THRESHOLD;
		do {
			if (ACCESS_ONCE(lock->tickets.head) == inc.tail)
				goto out;
			cpu_relax();
		} while (--count);
		__ticket_lock_spinning(lock, inc.tail);
	}
out:	barrier();
which results in:
	push   %rbp
	mov    %rsp,%rbp

	mov    $0x200,%eax
	lock xadd %ax,(%rdi)
	movzbl %ah,%edx
	cmp    %al,%dl
	jne    1f	# Slowpath if lock in contention

	pop    %rbp
	retq   

	### SLOWPATH START
1:	and    $-2,%edx
	movzbl %dl,%esi

2:	mov    $0x800,%eax
	jmp    4f

3:	pause  
	sub    $0x1,%eax
	je     5f

4:	movzbl (%rdi),%ecx
	cmp    %cl,%dl
	jne    3b

	pop    %rbp
	retq   

5:	callq  *__ticket_lock_spinning
	jmp    2b
	### SLOWPATH END

with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where
the fastpath case is straight through (taking the lock without
contention), and the spin loop is out of line:

	push   %rbp
	mov    %rsp,%rbp

	mov    $0x100,%eax
	lock xadd %ax,(%rdi)
	movzbl %ah,%edx
	cmp    %al,%dl
	jne    1f

	pop    %rbp
	retq   

	### SLOWPATH START
1:	pause  
	movzbl (%rdi),%eax
	cmp    %dl,%al
	jne    1b

	pop    %rbp
	retq   
	### SLOWPATH END

The unlock code is complicated by the need to both add to the lock's
"head" and fetch the slowpath flag from "tail".  This version of the
patch uses a locked add to do this, followed by a test to see if the
slowflag is set.  The lock prefix acts as a full memory barrier, so we
can be sure that other CPUs will have seen the unlock before we read
the flag (without the barrier the read could be fetched from the
store queue before it hits memory, which could result in a deadlock).

This is is all unnecessary complication if you're not using PV ticket
locks, it also uses the jump-label machinery to use the standard
"add"-based unlock in the non-PV case.

	if (TICKET_SLOWPATH_FLAG &&
	     static_key_false(&paravirt_ticketlocks_enabled))) {
		arch_spinlock_t prev;
		prev = *lock;
		add_smp(&lock->tickets.head, TICKET_LOCK_INC);

		/* add_smp() is a full mb() */
		if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
			__ticket_unlock_slowpath(lock, prev);
	} else
		__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
which generates:
	push   %rbp
	mov    %rsp,%rbp

	nop5	# replaced by 5-byte jmp 2f when PV enabled

	# non-PV unlock
	addb   $0x2,(%rdi)

1:	pop    %rbp
	retq   

### PV unlock ###
2:	movzwl (%rdi),%esi	# Fetch prev

	lock addb $0x2,(%rdi)	# Do unlock

	testb  $0x1,0x1(%rdi)	# Test flag
	je     1b		# Finished if not set

### Slow path ###
	add    $2,%sil		# Add "head" in old lock state
	mov    %esi,%edx
	and    $0xfe,%dh	# clear slowflag for comparison
	movzbl %dh,%eax
	cmp    %dl,%al		# If head == tail (uncontended)
	je     4f		# clear slowpath flag

	# Kick next CPU waiting for lock
3:	movzbl %sil,%esi
	callq  *pv_lock_ops.kick

	pop    %rbp
	retq   

	# Lock no longer contended - clear slowflag
4:	mov    %esi,%eax
	lock cmpxchg %dx,(%rdi)	# cmpxchg to clear flag
	cmp    %si,%ax
	jne    3b		# If clear failed, then kick

	pop    %rbp
	retq   

So when not using PV ticketlocks, the unlock sequence just has a
5-byte nop added to it, and the PV case is reasonable straightforward
aside from requiring a "lock add".

TODO: 1) remove CONFIG_PARAVIRT_SPINLOCK ?
      2) experiments on further optimization possibilities. (discussed in V6)

Results:
=======
various form of results based on V6 of the patch series are posted in following links
 https://lkml.org/lkml/2012/3/21/161
 https://lkml.org/lkml/2012/3/21/198

 kvm results:
 https://lkml.org/lkml/2012/3/23/50
 https://lkml.org/lkml/2012/4/5/73

Thoughts? Comments? Suggestions?

Jeremy Fitzhardinge (9):
  x86/spinlock: replace pv spinlocks with pv ticketlocks
  x86/ticketlock: collapse a layer of functions
  xen: defer spinlock setup until boot CPU setup
  xen/pvticketlock: Xen implementation for PV ticket locks
  xen/pvticketlocks: add xen_nopvspin parameter to disable xen pv
    ticketlocks
  x86/pvticketlock: use callee-save for lock_spinning
  x86/pvticketlock: when paravirtualizing ticket locks, increment by 2
  x86/ticketlock: add slowpath logic
  xen/pvticketlock: allow interrupts to be enabled while blocking

Raghavendra K T (1):
  x86/ticketlock: don't inline _spin_unlock when using paravirt
    spinlocks

Andrew Jones (1):
  split out rate limiting from jump_label.h

Stefano Stabellini (1):
 xen: enable PV ticketlocks on HVM Xen
---

V6 : https://lkml.org/lkml/2012/3/21/161

Changes in V6 posting: (Raghavendra K T)
 - Rebased to linux-3.3-rc6.
 - used function+enum in place of macro (better type checking) 
 - use cmpxchg while resetting zero status for possible race
	[suggested by Dave Hansen for KVM patches ]
 
 arch/x86/Kconfig                      |    1 +
 arch/x86/include/asm/paravirt.h       |   32 +---
 arch/x86/include/asm/paravirt_types.h |   10 +-
 arch/x86/include/asm/spinlock.h       |  128 ++++++++----
 arch/x86/include/asm/spinlock_types.h |   16 +-
 arch/x86/kernel/paravirt-spinlocks.c  |   18 +--
 arch/x86/xen/smp.c                    |    3 +-
 arch/x86/xen/spinlock.c               |  383 +++++++++++----------------------
 include/linux/jump_label.h            |   26 +---
 include/linux/jump_label_ratelimit.h  |   34 +++
 include/linux/perf_event.h            |    1 +
 kernel/jump_label.c                   |    1 +
 12 files changed, 279 insertions(+), 374 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 21 21:57:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Apr 2012 21:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLiIY-00034N-VC; Sat, 21 Apr 2012 21:56:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SKxiY-0005Or-MJ
	for xen-devel@lists.xensource.com; Thu, 19 Apr 2012 20:12:39 +0000
Received: from [85.158.138.51:54235] by server-7.bemta-3.messagelabs.com id
	C3/EE-03078-5B1709F4; Thu, 19 Apr 2012 20:12:37 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1334866353!11927789!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA1MDc4Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28921 invoked from network); 19 Apr 2012 20:12:36 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Apr 2012 20:12:36 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 20 Apr 2012 01:42:32 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Apr 2012 01:42:29 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3JKCSAd4571234
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 01:42:28 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3K1g8uM006237
	for <xen-devel@lists.xensource.com>; Fri, 20 Apr 2012 07:12:10 +0530
Received: from [192.168.1.3] ([9.124.213.22])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3K1g0Mq005578; Fri, 20 Apr 2012 07:12:05 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Date: Fri, 20 Apr 2012 01:42:12 +0530
Message-Id: <20120419201209.5411.43877.sendpatchset@codeblue>
x-cbid: 12041920-8878-0000-0000-000002185B2F
X-Mailman-Approved-At: Sat, 21 Apr 2012 21:56:52 +0000
Cc: Andrew Jones <drjones@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Xen-devel] [PATCH RFC V7 0/12] Paravirtualized ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

This series replaces the existing paravirtualized spinlock mechanism
with a paravirtualized ticketlock mechanism. (targeted for 3.5 window)

Changes in V7:
 - Reabsed patches to 3.4-rc3
 - Added jumplabel split patch (originally from Andrew Jones rebased to
    3.4-rc3
 - jumplabel changes from Ingo and Jason taken and now using static_key_*
    instead of static_branch.
 - using UNINLINE_SPIN_UNLOCK (which was splitted as per suggestion from Linus)
 - This patch series is rebased on debugfs patch (that sould be already in
    Xen/linux-next https://lkml.org/lkml/2012/3/23/51)

Ticket locks have an inherent problem in a virtualized case, because
the vCPUs are scheduled rather than running concurrently (ignoring
gang scheduled vCPUs).  This can result in catastrophic performance
collapses when the vCPU scheduler doesn't schedule the correct "next"
vCPU, and ends up scheduling a vCPU which burns its entire timeslice
spinning.  (Note that this is not the same problem as lock-holder
preemption, which this series also addresses; that's also a problem,
but not catastrophic).

(See Thomas Friebel's talk "Prevent Guests from Spinning Around"
http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)

Currently we deal with this by having PV spinlocks, which adds a layer
of indirection in front of all the spinlock functions, and defining a
completely new implementation for Xen (and for other pvops users, but
there are none at present).

PV ticketlocks keeps the existing ticketlock implemenentation
(fastpath) as-is, but adds a couple of pvops for the slow paths:

- If a CPU has been waiting for a spinlock for SPIN_THRESHOLD
  iterations, then call out to the __ticket_lock_spinning() pvop,
  which allows a backend to block the vCPU rather than spinning.  This
  pvop can set the lock into "slowpath state".

- When releasing a lock, if it is in "slowpath state", the call
  __ticket_unlock_kick() to kick the next vCPU in line awake.  If the
  lock is no longer in contention, it also clears the slowpath flag.

The "slowpath state" is stored in the LSB of the within the lock tail
ticket.  This has the effect of reducing the max number of CPUs by
half (so, a "small ticket" can deal with 128 CPUs, and "large ticket"
32768).

This series provides a Xen implementation, KVM implementation will be
posted in next 2-3 days.

Overall, it results in a large reduction in code, it makes the native
and virtualized cases closer, and it removes a layer of indirection
around all the spinlock functions.

The fast path (taking an uncontended lock which isn't in "slowpath"
state) is optimal, identical to the non-paravirtualized case.

The inner part of ticket lock code becomes:
	inc = xadd(&lock->tickets, inc);
	inc.tail &= ~TICKET_SLOWPATH_FLAG;

	if (likely(inc.head == inc.tail))
		goto out;
	for (;;) {
		unsigned count = SPIN_THRESHOLD;
		do {
			if (ACCESS_ONCE(lock->tickets.head) == inc.tail)
				goto out;
			cpu_relax();
		} while (--count);
		__ticket_lock_spinning(lock, inc.tail);
	}
out:	barrier();
which results in:
	push   %rbp
	mov    %rsp,%rbp

	mov    $0x200,%eax
	lock xadd %ax,(%rdi)
	movzbl %ah,%edx
	cmp    %al,%dl
	jne    1f	# Slowpath if lock in contention

	pop    %rbp
	retq   

	### SLOWPATH START
1:	and    $-2,%edx
	movzbl %dl,%esi

2:	mov    $0x800,%eax
	jmp    4f

3:	pause  
	sub    $0x1,%eax
	je     5f

4:	movzbl (%rdi),%ecx
	cmp    %cl,%dl
	jne    3b

	pop    %rbp
	retq   

5:	callq  *__ticket_lock_spinning
	jmp    2b
	### SLOWPATH END

with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where
the fastpath case is straight through (taking the lock without
contention), and the spin loop is out of line:

	push   %rbp
	mov    %rsp,%rbp

	mov    $0x100,%eax
	lock xadd %ax,(%rdi)
	movzbl %ah,%edx
	cmp    %al,%dl
	jne    1f

	pop    %rbp
	retq   

	### SLOWPATH START
1:	pause  
	movzbl (%rdi),%eax
	cmp    %dl,%al
	jne    1b

	pop    %rbp
	retq   
	### SLOWPATH END

The unlock code is complicated by the need to both add to the lock's
"head" and fetch the slowpath flag from "tail".  This version of the
patch uses a locked add to do this, followed by a test to see if the
slowflag is set.  The lock prefix acts as a full memory barrier, so we
can be sure that other CPUs will have seen the unlock before we read
the flag (without the barrier the read could be fetched from the
store queue before it hits memory, which could result in a deadlock).

This is is all unnecessary complication if you're not using PV ticket
locks, it also uses the jump-label machinery to use the standard
"add"-based unlock in the non-PV case.

	if (TICKET_SLOWPATH_FLAG &&
	     static_key_false(&paravirt_ticketlocks_enabled))) {
		arch_spinlock_t prev;
		prev = *lock;
		add_smp(&lock->tickets.head, TICKET_LOCK_INC);

		/* add_smp() is a full mb() */
		if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
			__ticket_unlock_slowpath(lock, prev);
	} else
		__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
which generates:
	push   %rbp
	mov    %rsp,%rbp

	nop5	# replaced by 5-byte jmp 2f when PV enabled

	# non-PV unlock
	addb   $0x2,(%rdi)

1:	pop    %rbp
	retq   

### PV unlock ###
2:	movzwl (%rdi),%esi	# Fetch prev

	lock addb $0x2,(%rdi)	# Do unlock

	testb  $0x1,0x1(%rdi)	# Test flag
	je     1b		# Finished if not set

### Slow path ###
	add    $2,%sil		# Add "head" in old lock state
	mov    %esi,%edx
	and    $0xfe,%dh	# clear slowflag for comparison
	movzbl %dh,%eax
	cmp    %dl,%al		# If head == tail (uncontended)
	je     4f		# clear slowpath flag

	# Kick next CPU waiting for lock
3:	movzbl %sil,%esi
	callq  *pv_lock_ops.kick

	pop    %rbp
	retq   

	# Lock no longer contended - clear slowflag
4:	mov    %esi,%eax
	lock cmpxchg %dx,(%rdi)	# cmpxchg to clear flag
	cmp    %si,%ax
	jne    3b		# If clear failed, then kick

	pop    %rbp
	retq   

So when not using PV ticketlocks, the unlock sequence just has a
5-byte nop added to it, and the PV case is reasonable straightforward
aside from requiring a "lock add".

TODO: 1) remove CONFIG_PARAVIRT_SPINLOCK ?
      2) experiments on further optimization possibilities. (discussed in V6)

Results:
=======
various form of results based on V6 of the patch series are posted in following links
 https://lkml.org/lkml/2012/3/21/161
 https://lkml.org/lkml/2012/3/21/198

 kvm results:
 https://lkml.org/lkml/2012/3/23/50
 https://lkml.org/lkml/2012/4/5/73

Thoughts? Comments? Suggestions?

Jeremy Fitzhardinge (9):
  x86/spinlock: replace pv spinlocks with pv ticketlocks
  x86/ticketlock: collapse a layer of functions
  xen: defer spinlock setup until boot CPU setup
  xen/pvticketlock: Xen implementation for PV ticket locks
  xen/pvticketlocks: add xen_nopvspin parameter to disable xen pv
    ticketlocks
  x86/pvticketlock: use callee-save for lock_spinning
  x86/pvticketlock: when paravirtualizing ticket locks, increment by 2
  x86/ticketlock: add slowpath logic
  xen/pvticketlock: allow interrupts to be enabled while blocking

Raghavendra K T (1):
  x86/ticketlock: don't inline _spin_unlock when using paravirt
    spinlocks

Andrew Jones (1):
  split out rate limiting from jump_label.h

Stefano Stabellini (1):
 xen: enable PV ticketlocks on HVM Xen
---

V6 : https://lkml.org/lkml/2012/3/21/161

Changes in V6 posting: (Raghavendra K T)
 - Rebased to linux-3.3-rc6.
 - used function+enum in place of macro (better type checking) 
 - use cmpxchg while resetting zero status for possible race
	[suggested by Dave Hansen for KVM patches ]
 
 arch/x86/Kconfig                      |    1 +
 arch/x86/include/asm/paravirt.h       |   32 +---
 arch/x86/include/asm/paravirt_types.h |   10 +-
 arch/x86/include/asm/spinlock.h       |  128 ++++++++----
 arch/x86/include/asm/spinlock_types.h |   16 +-
 arch/x86/kernel/paravirt-spinlocks.c  |   18 +--
 arch/x86/xen/smp.c                    |    3 +-
 arch/x86/xen/spinlock.c               |  383 +++++++++++----------------------
 include/linux/jump_label.h            |   26 +---
 include/linux/jump_label_ratelimit.h  |   34 +++
 include/linux/perf_event.h            |    1 +
 kernel/jump_label.c                   |    1 +
 12 files changed, 279 insertions(+), 374 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 22 15:23:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 15:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLyd0-00010X-Dp; Sun, 22 Apr 2012 15:23:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SLycz-00010S-2u
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 15:23:05 +0000
Received: from [85.158.138.51:2791] by server-8.bemta-3.messagelabs.com id
	8B/E2-24428-852249F4; Sun, 22 Apr 2012 15:23:04 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335108183!23107630!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13153 invoked from network); 22 Apr 2012 15:23:03 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 15:23:03 -0000
Received: by bkcji1 with SMTP id ji1so2554956bkc.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 08:23:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=80vMNZS25LiWNHa1mRdGOkgvfsCfBzWN16vqfbiojDw=;
	b=U1MxEWmibs94fIZ4NJWAt7i0FJ9SX9Ulm8TZynSSn7FCXUR/1az9+M+iLmiDxEVNtt
	KZdo20BYIJDttHaoT1cPeBmm3PUiOUOrGm7CIIuPJ03Br7T30wUgjIreeypzVkGyOEoQ
	k0/dklWXUY1PvRSEGE2Tjk0K2JFrcokBVvmEpnl7rTiWUQcczVUxH69rMBWj9It4Xxr7
	3/ht1UUsXPpTu20PpOieH3wlOHk/7UfyBLfojuRlVCFvm4lxTD0hdMABIRBNpuTLozLb
	PkFmuzq7kzpuyNA+rL0UIS7Qk+tfb25oiDsPVxB/Prel25WftUpXJCvwHAr26Af11hU1
	U7IQ==
MIME-Version: 1.0
Received: by 10.204.155.69 with SMTP id r5mr3952427bkw.67.1335108182858; Sun,
	22 Apr 2012 08:23:02 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Sun, 22 Apr 2012 08:23:02 -0700 (PDT)
Date: Sun, 22 Apr 2012 17:23:02 +0200
Message-ID: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4613476057352952341=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4613476057352952341==
Content-Type: multipart/alternative; boundary=0015175cfd18f9db2704be461842

--0015175cfd18f9db2704be461842
Content-Type: text/plain; charset=ISO-8859-1

Hi,

trying to compile but have problems:

+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://
xenbits.xensource.com/qemu-xen-unstable.git82db8de16530f016809264d3179823999d702849
qemu-xen-traditional-dir
Cloning into qemu-xen-traditional-dir-remote.tmp...
fatal: read error: Connection reset by peer

git down?

Best Regards,
Kristijan Lecnik

--0015175cfd18f9db2704be461842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>trying to compile but have problems:</div><div><br><=
/div><div><div>+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh=
 git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git">xenbi=
ts.xensource.com/qemu-xen-unstable.git</a> 82db8de16530f016809264d317982399=
9d702849 qemu-xen-traditional-dir</div>
<div>Cloning into qemu-xen-traditional-dir-remote.tmp...</div><div>fatal: r=
ead error: Connection reset by peer</div></div><div><br></div><div>git down=
?</div><div><br></div><div>Best Regards,</div><div>Kristijan Lecnik</div>

--0015175cfd18f9db2704be461842--


--===============4613476057352952341==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4613476057352952341==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 15:23:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 15:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLyd0-00010X-Dp; Sun, 22 Apr 2012 15:23:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SLycz-00010S-2u
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 15:23:05 +0000
Received: from [85.158.138.51:2791] by server-8.bemta-3.messagelabs.com id
	8B/E2-24428-852249F4; Sun, 22 Apr 2012 15:23:04 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335108183!23107630!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13153 invoked from network); 22 Apr 2012 15:23:03 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 15:23:03 -0000
Received: by bkcji1 with SMTP id ji1so2554956bkc.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 08:23:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=80vMNZS25LiWNHa1mRdGOkgvfsCfBzWN16vqfbiojDw=;
	b=U1MxEWmibs94fIZ4NJWAt7i0FJ9SX9Ulm8TZynSSn7FCXUR/1az9+M+iLmiDxEVNtt
	KZdo20BYIJDttHaoT1cPeBmm3PUiOUOrGm7CIIuPJ03Br7T30wUgjIreeypzVkGyOEoQ
	k0/dklWXUY1PvRSEGE2Tjk0K2JFrcokBVvmEpnl7rTiWUQcczVUxH69rMBWj9It4Xxr7
	3/ht1UUsXPpTu20PpOieH3wlOHk/7UfyBLfojuRlVCFvm4lxTD0hdMABIRBNpuTLozLb
	PkFmuzq7kzpuyNA+rL0UIS7Qk+tfb25oiDsPVxB/Prel25WftUpXJCvwHAr26Af11hU1
	U7IQ==
MIME-Version: 1.0
Received: by 10.204.155.69 with SMTP id r5mr3952427bkw.67.1335108182858; Sun,
	22 Apr 2012 08:23:02 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Sun, 22 Apr 2012 08:23:02 -0700 (PDT)
Date: Sun, 22 Apr 2012 17:23:02 +0200
Message-ID: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4613476057352952341=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4613476057352952341==
Content-Type: multipart/alternative; boundary=0015175cfd18f9db2704be461842

--0015175cfd18f9db2704be461842
Content-Type: text/plain; charset=ISO-8859-1

Hi,

trying to compile but have problems:

+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://
xenbits.xensource.com/qemu-xen-unstable.git82db8de16530f016809264d3179823999d702849
qemu-xen-traditional-dir
Cloning into qemu-xen-traditional-dir-remote.tmp...
fatal: read error: Connection reset by peer

git down?

Best Regards,
Kristijan Lecnik

--0015175cfd18f9db2704be461842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>trying to compile but have problems:</div><div><br><=
/div><div><div>+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh=
 git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git">xenbi=
ts.xensource.com/qemu-xen-unstable.git</a> 82db8de16530f016809264d317982399=
9d702849 qemu-xen-traditional-dir</div>
<div>Cloning into qemu-xen-traditional-dir-remote.tmp...</div><div>fatal: r=
ead error: Connection reset by peer</div></div><div><br></div><div>git down=
?</div><div><br></div><div>Best Regards,</div><div>Kristijan Lecnik</div>

--0015175cfd18f9db2704be461842--


--===============4613476057352952341==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4613476057352952341==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 15:25:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 15:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLyf1-00014Z-Vd; Sun, 22 Apr 2012 15:25:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SLyf0-00014R-5E
	for xen-devel@lists.xensource.com; Sun, 22 Apr 2012 15:25:10 +0000
Received: from [85.158.139.83:56025] by server-5.bemta-5.messagelabs.com id
	3C/51-13566-5D2249F4; Sun, 22 Apr 2012 15:25:09 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335108307!24265701!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY4OTQ2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19733 invoked from network); 22 Apr 2012 15:25:08 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-182.messagelabs.com with SMTP;
	22 Apr 2012 15:25:08 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 22 Apr 2012 08:25:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="133912225"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 22 Apr 2012 08:25:06 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 22 Apr 2012 08:25:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.5]) with mapi id
	14.01.0355.002; Sun, 22 Apr 2012 23:25:04 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Re-enable LTR/OBFF when device is owned by pciback
Thread-Index: Ac0gmp5i/wlDdGRQRxSMfF25/iWstQ==
Date: Sun, 22 Apr 2012 15:25:04 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 19834d1..82aac5b 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "reset device\n");
 	xen_pcibk_reset_device(dev);
 
+	/* set default value */
+	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
+	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */
+
+	/* Enable LTR and OBFF before do device assignment */
+	/* LTR(Latency tolerance reporting) allows devices to send messages to the
+	 * root complex indicating their latency tolerance for snooped & unsnooped
+	 * memory transactions. 
+	 */
+	pci_enable_ltr(dev);
+	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
+
+	/* OBFF (optimized buffer flush/fill), where supported, can help improve
+	 * energy efficiency by giving devices information about when interrupts and
+	 * other activity will have a reduced power impact.
+	 */
+	pci_enable_obff(dev, type);
+
 	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	return 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 22 15:25:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 15:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLyf1-00014Z-Vd; Sun, 22 Apr 2012 15:25:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SLyf0-00014R-5E
	for xen-devel@lists.xensource.com; Sun, 22 Apr 2012 15:25:10 +0000
Received: from [85.158.139.83:56025] by server-5.bemta-5.messagelabs.com id
	3C/51-13566-5D2249F4; Sun, 22 Apr 2012 15:25:09 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335108307!24265701!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY4OTQ2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19733 invoked from network); 22 Apr 2012 15:25:08 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-182.messagelabs.com with SMTP;
	22 Apr 2012 15:25:08 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 22 Apr 2012 08:25:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="133912225"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 22 Apr 2012 08:25:06 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 22 Apr 2012 08:25:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.5]) with mapi id
	14.01.0355.002; Sun, 22 Apr 2012 23:25:04 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Re-enable LTR/OBFF when device is owned by pciback
Thread-Index: Ac0gmp5i/wlDdGRQRxSMfF25/iWstQ==
Date: Sun, 22 Apr 2012 15:25:04 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 19834d1..82aac5b 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "reset device\n");
 	xen_pcibk_reset_device(dev);
 
+	/* set default value */
+	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
+	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */
+
+	/* Enable LTR and OBFF before do device assignment */
+	/* LTR(Latency tolerance reporting) allows devices to send messages to the
+	 * root complex indicating their latency tolerance for snooped & unsnooped
+	 * memory transactions. 
+	 */
+	pci_enable_ltr(dev);
+	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
+
+	/* OBFF (optimized buffer flush/fill), where supported, can help improve
+	 * energy efficiency by giving devices information about when interrupts and
+	 * other activity will have a reduced power impact.
+	 */
+	pci_enable_obff(dev, type);
+
 	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	return 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 22 15:53:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 15:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLz6M-0001MD-Cs; Sun, 22 Apr 2012 15:53:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SLz6K-0001M8-DX
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 15:53:24 +0000
Received: from [85.158.143.35:64631] by server-2.bemta-4.messagelabs.com id
	9C/F8-17550-379249F4; Sun, 22 Apr 2012 15:53:23 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335110003!13533474!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gNDQwODI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2475 invoked from network); 22 Apr 2012 15:53:23 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196) by server-11.tower-21.messagelabs.com with SMTP;
	22 Apr 2012 15:53:23 -0000
X-Originating-IP: 217.70.178.129
Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 301B81720A6
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 17:53:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id KO32T-x9crFJ for <xen-devel@lists.xen.org>;
	Sun, 22 Apr 2012 17:53:21 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 8F95E172092
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 17:53:21 +0200 (CEST)
Message-ID: <4F942971.2030803@de-bruyn.fr>
Date: Sun, 22 Apr 2012 17:53:21 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
In-Reply-To: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2FtZSBwcm9ibGVtIGhlcmUuLi4KClJlZ2FyZHMsCgpPbiAyMi4wNC4yMDEyIDE3OjIzLCBLcmlz
dGlqYW4gTGXEjW5payB3cm90ZToKPiBIaSwKPiAKPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2
ZSBwcm9ibGVtczoKPiAKPiArIC9yb290L3hlbi11bnN0YWJsZS5oZy1yZXYvdG9vbHMvLi4vc2Ny
aXB0cy9naXQtY2hlY2tvdXQuc2gKPiBnaXQ6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14
ZW4tdW5zdGFibGUuZ2l0Cj4gPGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4t
dW5zdGFibGUuZ2l0Pgo+IDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkg
cWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyCj4gQ2xvbmluZyBpbnRvIHFlbXUteGVuLXRyYWRpdGlv
bmFsLWRpci1yZW1vdGUudG1wLi4uCj4gZmF0YWw6IHJlYWQgZXJyb3I6IENvbm5lY3Rpb24gcmVz
ZXQgYnkgcGVlcgo+IAo+IGdpdCBkb3duPwo+IAo+IEJlc3QgUmVnYXJkcywKPiBLcmlzdGlqYW4g
TGVjbmlrCj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKCi0tIAotLQpBbGV4aXMgZGUgQlJV
WU4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Apr 22 15:53:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 15:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLz6M-0001MD-Cs; Sun, 22 Apr 2012 15:53:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SLz6K-0001M8-DX
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 15:53:24 +0000
Received: from [85.158.143.35:64631] by server-2.bemta-4.messagelabs.com id
	9C/F8-17550-379249F4; Sun, 22 Apr 2012 15:53:23 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335110003!13533474!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gNDQwODI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2475 invoked from network); 22 Apr 2012 15:53:23 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196) by server-11.tower-21.messagelabs.com with SMTP;
	22 Apr 2012 15:53:23 -0000
X-Originating-IP: 217.70.178.129
Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 301B81720A6
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 17:53:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id KO32T-x9crFJ for <xen-devel@lists.xen.org>;
	Sun, 22 Apr 2012 17:53:21 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 8F95E172092
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 17:53:21 +0200 (CEST)
Message-ID: <4F942971.2030803@de-bruyn.fr>
Date: Sun, 22 Apr 2012 17:53:21 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
In-Reply-To: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2FtZSBwcm9ibGVtIGhlcmUuLi4KClJlZ2FyZHMsCgpPbiAyMi4wNC4yMDEyIDE3OjIzLCBLcmlz
dGlqYW4gTGXEjW5payB3cm90ZToKPiBIaSwKPiAKPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2
ZSBwcm9ibGVtczoKPiAKPiArIC9yb290L3hlbi11bnN0YWJsZS5oZy1yZXYvdG9vbHMvLi4vc2Ny
aXB0cy9naXQtY2hlY2tvdXQuc2gKPiBnaXQ6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14
ZW4tdW5zdGFibGUuZ2l0Cj4gPGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4t
dW5zdGFibGUuZ2l0Pgo+IDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkg
cWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyCj4gQ2xvbmluZyBpbnRvIHFlbXUteGVuLXRyYWRpdGlv
bmFsLWRpci1yZW1vdGUudG1wLi4uCj4gZmF0YWw6IHJlYWQgZXJyb3I6IENvbm5lY3Rpb24gcmVz
ZXQgYnkgcGVlcgo+IAo+IGdpdCBkb3duPwo+IAo+IEJlc3QgUmVnYXJkcywKPiBLcmlzdGlqYW4g
TGVjbmlrCj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKCi0tIAotLQpBbGV4aXMgZGUgQlJV
WU4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Apr 22 16:26:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 16:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLzc3-0001zC-4l; Sun, 22 Apr 2012 16:26:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLzc2-0001z7-5L
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 16:26:10 +0000
Received: from [85.158.139.83:2687] by server-6.bemta-5.messagelabs.com id
	A6/47-13222-121349F4; Sun, 22 Apr 2012 16:26:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335111966!13682492!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzg2ODU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8851 invoked from network); 22 Apr 2012 16:26:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 16:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,462,1330923600"; d="scan'208";a="24406228"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Apr 2012 12:26:06 -0400
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Sun, 22 Apr 2012
	12:26:05 -0400
Message-ID: <1335111964.13299.2.camel@cthulhu.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kristijan =?UTF-8?Q?Le=C4=8Dnik?= <janez3k@gmail.com>
Date: Sun, 22 Apr 2012 17:26:04 +0100
In-Reply-To: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
References: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA0LTIyIGF0IDExOjIzIC0wNDAwLCBLcmlzdGlqYW4gTGXEjW5payB3cm90
ZToKPiBIaSwKPiAKPiAKPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBwcm9ibGVtczoKPiAK
PiAKPiArIC9yb290L3hlbi11bnN0YWJsZS5oZy1yZXYvdG9vbHMvLi4vc2NyaXB0cy9naXQtY2hl
Y2tvdXQuc2gKPiBnaXQ6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUu
Z2l0Cj4gODJkYjhkZTE2NTMwZjAxNjgwOTI2NGQzMTc5ODIzOTk5ZDcwMjg0OSBxZW11LXhlbi10
cmFkaXRpb25hbC1kaXIKPiBDbG9uaW5nIGludG8gcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyLXJl
bW90ZS50bXAuLi4KPiBmYXRhbDogcmVhZCBlcnJvcjogQ29ubmVjdGlvbiByZXNldCBieSBwZWVy
Cj4gCj4gCj4gZ2l0IGRvd24/CgpXZSBoYXZlIG9jY2FzaW9uYWwgcHJvYmxlbXMgd2l0aCBzdHVj
ayBnaXQgZGFlbW9uIHByb2Nlc3NlcyBhbGwgY29taW5nCmZvcm0gdGhlIHNhbWUgSVAgYWRkcmVz
cywgd2hpY2ggZXZlbnR1YWxseSB1c2UgdXAgdGhlIHF1b3RhIG9mIGNoaWxkCnByb2Nlc3Nlcy4g
SXQgc2VlbXMgdGhhdCB3ZSBoYXZlIGEgbmV3IHByb2JsZW1hdGljIElQIGFkZHJlc3MuCgpJJ3Zl
IGp1c3Qga2lsbGVkIGEgY291cGxlIG9mIGRvemVuIGdpdCBwcm9jZXNzZXMgd2hpY2ggaGFkIGJl
ZW4gcnVubmluZwpmb3Igc2V2ZXJhbCB3ZWVrcywgdGhpbmdzIHNob3VsZCBiZSBiYWNrIHRvIG5v
cm1hbC4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sun Apr 22 16:26:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 16:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLzc3-0001zC-4l; Sun, 22 Apr 2012 16:26:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SLzc2-0001z7-5L
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 16:26:10 +0000
Received: from [85.158.139.83:2687] by server-6.bemta-5.messagelabs.com id
	A6/47-13222-121349F4; Sun, 22 Apr 2012 16:26:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335111966!13682492!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzg2ODU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8851 invoked from network); 22 Apr 2012 16:26:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 16:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,462,1330923600"; d="scan'208";a="24406228"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Apr 2012 12:26:06 -0400
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Sun, 22 Apr 2012
	12:26:05 -0400
Message-ID: <1335111964.13299.2.camel@cthulhu.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kristijan =?UTF-8?Q?Le=C4=8Dnik?= <janez3k@gmail.com>
Date: Sun, 22 Apr 2012 17:26:04 +0100
In-Reply-To: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
References: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA0LTIyIGF0IDExOjIzIC0wNDAwLCBLcmlzdGlqYW4gTGXEjW5payB3cm90
ZToKPiBIaSwKPiAKPiAKPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBwcm9ibGVtczoKPiAK
PiAKPiArIC9yb290L3hlbi11bnN0YWJsZS5oZy1yZXYvdG9vbHMvLi4vc2NyaXB0cy9naXQtY2hl
Y2tvdXQuc2gKPiBnaXQ6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUu
Z2l0Cj4gODJkYjhkZTE2NTMwZjAxNjgwOTI2NGQzMTc5ODIzOTk5ZDcwMjg0OSBxZW11LXhlbi10
cmFkaXRpb25hbC1kaXIKPiBDbG9uaW5nIGludG8gcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyLXJl
bW90ZS50bXAuLi4KPiBmYXRhbDogcmVhZCBlcnJvcjogQ29ubmVjdGlvbiByZXNldCBieSBwZWVy
Cj4gCj4gCj4gZ2l0IGRvd24/CgpXZSBoYXZlIG9jY2FzaW9uYWwgcHJvYmxlbXMgd2l0aCBzdHVj
ayBnaXQgZGFlbW9uIHByb2Nlc3NlcyBhbGwgY29taW5nCmZvcm0gdGhlIHNhbWUgSVAgYWRkcmVz
cywgd2hpY2ggZXZlbnR1YWxseSB1c2UgdXAgdGhlIHF1b3RhIG9mIGNoaWxkCnByb2Nlc3Nlcy4g
SXQgc2VlbXMgdGhhdCB3ZSBoYXZlIGEgbmV3IHByb2JsZW1hdGljIElQIGFkZHJlc3MuCgpJJ3Zl
IGp1c3Qga2lsbGVkIGEgY291cGxlIG9mIGRvemVuIGdpdCBwcm9jZXNzZXMgd2hpY2ggaGFkIGJl
ZW4gcnVubmluZwpmb3Igc2V2ZXJhbCB3ZWVrcywgdGhpbmdzIHNob3VsZCBiZSBiYWNrIHRvIG5v
cm1hbC4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sun Apr 22 16:34:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 16:34:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLzk3-00028U-3s; Sun, 22 Apr 2012 16:34:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SLzk1-00028P-Oo
	for xen-devel@lists.xensource.com; Sun, 22 Apr 2012 16:34:25 +0000
Received: from [85.158.143.35:6481] by server-1.bemta-4.messagelabs.com id
	F6/5C-20925-113349F4; Sun, 22 Apr 2012 16:34:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335112463!6065021!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTM2MDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1464 invoked from network); 22 Apr 2012 16:34:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Apr 2012 16:34:24 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2CEF52F47;
	Sun, 22 Apr 2012 19:34:19 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B9B2420059; Sun, 22 Apr 2012 19:34:18 +0300 (EEST)
Date: Sun, 22 Apr 2012 19:34:18 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lars Boegild Thomsen <lth@cow.dk>
Message-ID: <20120422163418.GD2058@reaktio.net>
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<201204161905.13260.bugs@humanleg.org.uk>
	<20120417020433.GA15848@burratino> <201204181803.00383.lth@cow.dk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204181803.00383.lth@cow.dk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Robert Scott <bugs@humanleg.org.uk>,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Jonathan Nieder <jrnieder@gmail.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
 suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 18, 2012 at 06:03:00PM +0800, Lars Boegild Thomsen wrote:
> On Tuesday 17 April 2012 10:04:33 Jonathan Nieder wrote:
> > > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.
> > Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
> > same problem?  Can you get a log of the failure with
> > "no_console_suspend" appended to the kernel command line, for example
> > with a serial console or netconsole?
> 
> Using a serial console is a bit of a problem on this netbook as it hasn't got 
> a serial port.  Not sure how the netconsole works - will read up on that.
> 

You can get an ExpressCard Serial Card and use that..
or if the laptop has vPro then it has Serial Over LAN in the AMT chip.

http://wiki.xen.org/wiki/Xen_Serial_Console

-- Pasi

> And no - suspend to disk works fine.
> 
> I have by the way experimentally switched to 32bit version and it's the same 
> thing (originally I was running 64bit version but that really doesn't make 
> sense on a netbook - except doing it because it could be done).
> 
> //Lars...
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 22 16:34:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 16:34:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SLzk3-00028U-3s; Sun, 22 Apr 2012 16:34:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SLzk1-00028P-Oo
	for xen-devel@lists.xensource.com; Sun, 22 Apr 2012 16:34:25 +0000
Received: from [85.158.143.35:6481] by server-1.bemta-4.messagelabs.com id
	F6/5C-20925-113349F4; Sun, 22 Apr 2012 16:34:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335112463!6065021!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTM2MDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1464 invoked from network); 22 Apr 2012 16:34:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Apr 2012 16:34:24 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2CEF52F47;
	Sun, 22 Apr 2012 19:34:19 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B9B2420059; Sun, 22 Apr 2012 19:34:18 +0300 (EEST)
Date: Sun, 22 Apr 2012 19:34:18 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lars Boegild Thomsen <lth@cow.dk>
Message-ID: <20120422163418.GD2058@reaktio.net>
References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com>
	<201204161905.13260.bugs@humanleg.org.uk>
	<20120417020433.GA15848@burratino> <201204181803.00383.lth@cow.dk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204181803.00383.lth@cow.dk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Kevin Tian <kevin.tian@intel.com>, xen-devel@lists.xensource.com,
	Robert Scott <bugs@humanleg.org.uk>,
	Fengzhe Zhang <fengzhe.zhang@intel.com>, linux-kernel@vger.kernel.org,
	Jonathan Nieder <jrnieder@gmail.com>, mingo@redhat.com,
	hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net,
	Thomas Gleixner <tglx@linutronix.de>, "Liu,
	Chuansheng" <chuansheng.liu@intel.com>
Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from
 suspend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 18, 2012 at 06:03:00PM +0800, Lars Boegild Thomsen wrote:
> On Tuesday 17 April 2012 10:04:33 Jonathan Nieder wrote:
> > > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid.
> > Alas.  Does suspend-to-disk ("echo disk >/sys/power/state") have the
> > same problem?  Can you get a log of the failure with
> > "no_console_suspend" appended to the kernel command line, for example
> > with a serial console or netconsole?
> 
> Using a serial console is a bit of a problem on this netbook as it hasn't got 
> a serial port.  Not sure how the netconsole works - will read up on that.
> 

You can get an ExpressCard Serial Card and use that..
or if the laptop has vPro then it has Serial Over LAN in the AMT chip.

http://wiki.xen.org/wiki/Xen_Serial_Console

-- Pasi

> And no - suspend to disk works fine.
> 
> I have by the way experimentally switched to 32bit version and it's the same 
> thing (originally I was running 64bit version but that really doesn't make 
> sense on a netbook - except doing it because it could be done).
> 
> //Lars...
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 22 17:14:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 17:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM0Me-0002QL-E3; Sun, 22 Apr 2012 17:14:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SM0Mc-0002QG-53
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 17:14:18 +0000
Received: from [193.109.254.147:39727] by server-10.bemta-14.messagelabs.com
	id 90/5F-05847-96C349F4; Sun, 22 Apr 2012 17:14:17 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335114855!5703995!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17685 invoked from network); 22 Apr 2012 17:14:16 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 17:14:16 -0000
Received: by bkcji1 with SMTP id ji1so2594321bkc.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 10:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=K+I3IogvcYUl+MRQmOV/MamlOAzlhpeEcWfq9zu7mXI=;
	b=KFL3FZ/vufPF8DElyjT8IHNiYwfIMTEgAjD8nRJ8HQYPQ9VUKOdywmmwpGUHex2FKw
	FTKLk/zP9xCfZgKjLfJO9xv328SOrhW1fAgzet1Q3MzNYlaB+sQcjdHjoWdDNS0f66gD
	CDup+rXiIlVciLn9IzgO0pWCrbnWuBgHimCFFsgTRZ5Hj6XxUP4ugnkGSXCIoKG8VhdF
	FXcQ+WUGGwsCnPYKBPBPL+b+Dc3NRanhxLZfWdAhqmUvlIZ2Z3ADA6C9XbI7Sy+DoCw0
	V76n16WywXYGF389gnOWRXqHof4BDPH13Bb9grgb/pG47zY/jwm471X3WSm4r9FynSKp
	f1rw==
MIME-Version: 1.0
Received: by 10.204.133.205 with SMTP id g13mr4187524bkt.94.1335114855098;
	Sun, 22 Apr 2012 10:14:15 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Sun, 22 Apr 2012 10:14:15 -0700 (PDT)
In-Reply-To: <1335111964.13299.2.camel@cthulhu.hellion.org.uk>
References: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
	<1335111964.13299.2.camel@cthulhu.hellion.org.uk>
Date: Sun, 22 Apr 2012 19:14:15 +0200
Message-ID: <CACC+8CT3n-EkSEPRwqLPbTNj3SLCoc+Eo8zC3UuHyFPyxPHzcQ@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4522796888046779864=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4522796888046779864==
Content-Type: multipart/alternative; boundary=000e0cd73406ac29a704be47a610

--000e0cd73406ac29a704be47a610
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

still cant connect:

+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://
xenbits.xensource.com/qemu-xen-unstable.git82db8de16530f016809264d317982399=
9d702849
qemu-xen-traditional-dir
Cloning into qemu-xen-traditional-dir-remote.tmp...
xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused
fatal: unable to connect a socket (Connection refused)
make[1]: *** [qemu-xen-traditional-dir-find] Error 128

i am sorry to complain, don't have the time to play with xen other then
on weekend :)

Best Regards,
Kristijan Lecnik

On Sun, Apr 22, 2012 at 6:26 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

> On Sun, 2012-04-22 at 11:23 -0400, Kristijan Le=C4=8Dnik wrote:
> > Hi,
> >
> >
> > trying to compile but have problems:
> >
> >
> > + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh
> > git://xenbits.xensource.com/qemu-xen-unstable.git
> > 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir
> > Cloning into qemu-xen-traditional-dir-remote.tmp...
> > fatal: read error: Connection reset by peer
> >
> >
> > git down?
>
> We have occasional problems with stuck git daemon processes all coming
> form the same IP address, which eventually use up the quota of child
> processes. It seems that we have a new problematic IP address.
>
> I've just killed a couple of dozen git processes which had been running
> for several weeks, things should be back to normal.
>
> Ian.
>
>
>

--000e0cd73406ac29a704be47a610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>still cant connect:</div><div><br></div><div><div>+ =
/root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://<a href=3D=
"http://xenbits.xensource.com/qemu-xen-unstable.git">xenbits.xensource.com/=
qemu-xen-unstable.git</a> 82db8de16530f016809264d3179823999d702849 qemu-xen=
-traditional-dir</div>
<div>Cloning into qemu-xen-traditional-dir-remote.tmp...</div><div><a href=
=3D"http://xenbits.xensource.com">xenbits.xensource.com</a>[0: 50.57.170.24=
2]: errno=3DConnection refused</div><div>fatal: unable to connect a socket =
(Connection refused)</div>
<div>make[1]: *** [qemu-xen-traditional-dir-find] Error 128</div></div><div=
><br></div><div>i am sorry to complain, don&#39;t have the time to play wit=
h xen other then on=C2=A0weekend :)</div><div><br></div><div>Best Regards,<=
/div>
<div>Kristijan Lecnik</div><div><br><div class=3D"gmail_quote">On Sun, Apr =
22, 2012 at 6:26 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:I=
an.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Sun, 2012-04-22 at 11:23 -0400, =
Kristijan Le=C4=8Dnik wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; trying to compile but have problems:<br>
&gt;<br>
&gt;<br>
&gt; + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh<br>
&gt; git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" t=
arget=3D"_blank">xenbits.xensource.com/qemu-xen-unstable.git</a><br>
&gt; 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir<br>
&gt; Cloning into qemu-xen-traditional-dir-remote.tmp...<br>
&gt; fatal: read error: Connection reset by peer<br>
&gt;<br>
&gt;<br>
&gt; git down?<br>
<br>
</div></div>We have occasional problems with stuck git daemon processes all=
 coming<br>
form the same IP address, which eventually use up the quota of child<br>
processes. It seems that we have a new problematic IP address.<br>
<br>
I&#39;ve just killed a couple of dozen git processes which had been running=
<br>
for several weeks, things should be back to normal.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--000e0cd73406ac29a704be47a610--


--===============4522796888046779864==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4522796888046779864==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 17:14:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 17:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM0Me-0002QL-E3; Sun, 22 Apr 2012 17:14:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SM0Mc-0002QG-53
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 17:14:18 +0000
Received: from [193.109.254.147:39727] by server-10.bemta-14.messagelabs.com
	id 90/5F-05847-96C349F4; Sun, 22 Apr 2012 17:14:17 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335114855!5703995!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17685 invoked from network); 22 Apr 2012 17:14:16 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 17:14:16 -0000
Received: by bkcji1 with SMTP id ji1so2594321bkc.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 10:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=K+I3IogvcYUl+MRQmOV/MamlOAzlhpeEcWfq9zu7mXI=;
	b=KFL3FZ/vufPF8DElyjT8IHNiYwfIMTEgAjD8nRJ8HQYPQ9VUKOdywmmwpGUHex2FKw
	FTKLk/zP9xCfZgKjLfJO9xv328SOrhW1fAgzet1Q3MzNYlaB+sQcjdHjoWdDNS0f66gD
	CDup+rXiIlVciLn9IzgO0pWCrbnWuBgHimCFFsgTRZ5Hj6XxUP4ugnkGSXCIoKG8VhdF
	FXcQ+WUGGwsCnPYKBPBPL+b+Dc3NRanhxLZfWdAhqmUvlIZ2Z3ADA6C9XbI7Sy+DoCw0
	V76n16WywXYGF389gnOWRXqHof4BDPH13Bb9grgb/pG47zY/jwm471X3WSm4r9FynSKp
	f1rw==
MIME-Version: 1.0
Received: by 10.204.133.205 with SMTP id g13mr4187524bkt.94.1335114855098;
	Sun, 22 Apr 2012 10:14:15 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Sun, 22 Apr 2012 10:14:15 -0700 (PDT)
In-Reply-To: <1335111964.13299.2.camel@cthulhu.hellion.org.uk>
References: <CACC+8CTxnCJcqoJ1dkjaRUmzvz=7CVUE2PHjuw0hkbR=vCvpYA@mail.gmail.com>
	<1335111964.13299.2.camel@cthulhu.hellion.org.uk>
Date: Sun, 22 Apr 2012 19:14:15 +0200
Message-ID: <CACC+8CT3n-EkSEPRwqLPbTNj3SLCoc+Eo8zC3UuHyFPyxPHzcQ@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4522796888046779864=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4522796888046779864==
Content-Type: multipart/alternative; boundary=000e0cd73406ac29a704be47a610

--000e0cd73406ac29a704be47a610
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

still cant connect:

+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://
xenbits.xensource.com/qemu-xen-unstable.git82db8de16530f016809264d317982399=
9d702849
qemu-xen-traditional-dir
Cloning into qemu-xen-traditional-dir-remote.tmp...
xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused
fatal: unable to connect a socket (Connection refused)
make[1]: *** [qemu-xen-traditional-dir-find] Error 128

i am sorry to complain, don't have the time to play with xen other then
on weekend :)

Best Regards,
Kristijan Lecnik

On Sun, Apr 22, 2012 at 6:26 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

> On Sun, 2012-04-22 at 11:23 -0400, Kristijan Le=C4=8Dnik wrote:
> > Hi,
> >
> >
> > trying to compile but have problems:
> >
> >
> > + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh
> > git://xenbits.xensource.com/qemu-xen-unstable.git
> > 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir
> > Cloning into qemu-xen-traditional-dir-remote.tmp...
> > fatal: read error: Connection reset by peer
> >
> >
> > git down?
>
> We have occasional problems with stuck git daemon processes all coming
> form the same IP address, which eventually use up the quota of child
> processes. It seems that we have a new problematic IP address.
>
> I've just killed a couple of dozen git processes which had been running
> for several weeks, things should be back to normal.
>
> Ian.
>
>
>

--000e0cd73406ac29a704be47a610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>still cant connect:</div><div><br></div><div><div>+ =
/root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://<a href=3D=
"http://xenbits.xensource.com/qemu-xen-unstable.git">xenbits.xensource.com/=
qemu-xen-unstable.git</a> 82db8de16530f016809264d3179823999d702849 qemu-xen=
-traditional-dir</div>
<div>Cloning into qemu-xen-traditional-dir-remote.tmp...</div><div><a href=
=3D"http://xenbits.xensource.com">xenbits.xensource.com</a>[0: 50.57.170.24=
2]: errno=3DConnection refused</div><div>fatal: unable to connect a socket =
(Connection refused)</div>
<div>make[1]: *** [qemu-xen-traditional-dir-find] Error 128</div></div><div=
><br></div><div>i am sorry to complain, don&#39;t have the time to play wit=
h xen other then on=C2=A0weekend :)</div><div><br></div><div>Best Regards,<=
/div>
<div>Kristijan Lecnik</div><div><br><div class=3D"gmail_quote">On Sun, Apr =
22, 2012 at 6:26 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:I=
an.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Sun, 2012-04-22 at 11:23 -0400, =
Kristijan Le=C4=8Dnik wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; trying to compile but have problems:<br>
&gt;<br>
&gt;<br>
&gt; + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh<br>
&gt; git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" t=
arget=3D"_blank">xenbits.xensource.com/qemu-xen-unstable.git</a><br>
&gt; 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir<br>
&gt; Cloning into qemu-xen-traditional-dir-remote.tmp...<br>
&gt; fatal: read error: Connection reset by peer<br>
&gt;<br>
&gt;<br>
&gt; git down?<br>
<br>
</div></div>We have occasional problems with stuck git daemon processes all=
 coming<br>
form the same IP address, which eventually use up the quota of child<br>
processes. It seems that we have a new problematic IP address.<br>
<br>
I&#39;ve just killed a couple of dozen git processes which had been running=
<br>
for several weeks, things should be back to normal.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--000e0cd73406ac29a704be47a610--


--===============4522796888046779864==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4522796888046779864==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 17:29:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 17:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM0ay-0002aE-VF; Sun, 22 Apr 2012 17:29:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SM0ax-0002a9-5M
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 17:29:07 +0000
Received: from [85.158.139.83:32513] by server-1.bemta-5.messagelabs.com id
	8F/CE-28458-2EF349F4; Sun, 22 Apr 2012 17:29:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335115744!21075320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY3Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23491 invoked from network); 22 Apr 2012 17:29:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 17:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,462,1330905600"; d="scan'208,217";a="12066693"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Apr 2012 17:29:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Sun, 22 Apr 2012
	18:29:04 +0100
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?utf-8?B?S3Jpc3RpamFuIExlxI1uaWs=?= <janez3k@gmail.com>
Date: Sun, 22 Apr 2012 18:29:03 +0100
Thread-Topic: [Xen-devel] git down?
Thread-Index: Ac0gq4oFBBxskBt/QQ2fBHi6gTQeJgAAd+Jx
Message-ID: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8528037036056113393=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8528037036056113393==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_"

--_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2hvdWxkIGJlIGZpeGVkIG5vdy4gU29ycnkgZm9yIHRoZSBpbmNvbnZlbmllbmNlLg0KDQpLcmlz
dGlqYW4gTGXEjW5payA8amFuZXoza0BnbWFpbC5jb20+IHdyb3RlOg0KDQoNCg0KSGksDQoNCnN0
aWxsIGNhbnQgY29ubmVjdDoNCg0KKyAvcm9vdC94ZW4tdW5zdGFibGUuaGctcmV2L3Rvb2xzLy4u
L3NjcmlwdHMvZ2l0LWNoZWNrb3V0LnNoIGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11
LXhlbi11bnN0YWJsZS5naXQ8aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11
bnN0YWJsZS5naXQ+IDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkgcWVt
dS14ZW4tdHJhZGl0aW9uYWwtZGlyDQpDbG9uaW5nIGludG8gcWVtdS14ZW4tdHJhZGl0aW9uYWwt
ZGlyLXJlbW90ZS50bXAuLi4NCnhlbmJpdHMueGVuc291cmNlLmNvbTxodHRwOi8veGVuYml0cy54
ZW5zb3VyY2UuY29tPlswOiA1MC41Ny4xNzAuMjQyXTogZXJybm89Q29ubmVjdGlvbiByZWZ1c2Vk
DQpmYXRhbDogdW5hYmxlIHRvIGNvbm5lY3QgYSBzb2NrZXQgKENvbm5lY3Rpb24gcmVmdXNlZCkN
Cm1ha2VbMV06ICoqKiBbcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyLWZpbmRdIEVycm9yIDEyOA0K
DQppIGFtIHNvcnJ5IHRvIGNvbXBsYWluLCBkb24ndCBoYXZlIHRoZSB0aW1lIHRvIHBsYXkgd2l0
aCB4ZW4gb3RoZXIgdGhlbiBvbiB3ZWVrZW5kIDopDQoNCkJlc3QgUmVnYXJkcywNCktyaXN0aWph
biBMZWNuaWsNCg0KT24gU3VuLCBBcHIgMjIsIDIwMTIgYXQgNjoyNiBQTSwgSWFuIENhbXBiZWxs
IDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbTxtYWlsdG86SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+
PiB3cm90ZToNCk9uIFN1biwgMjAxMi0wNC0yMiBhdCAxMToyMyAtMDQwMCwgS3Jpc3RpamFuIExl
xI1uaWsgd3JvdGU6DQo+IEhpLA0KPg0KPg0KPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBw
cm9ibGVtczoNCj4NCj4NCj4gKyAvcm9vdC94ZW4tdW5zdGFibGUuaGctcmV2L3Rvb2xzLy4uL3Nj
cmlwdHMvZ2l0LWNoZWNrb3V0LnNoDQo+IGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11
LXhlbi11bnN0YWJsZS5naXQ8aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11
bnN0YWJsZS5naXQ+DQo+IDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkg
cWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyDQo+IENsb25pbmcgaW50byBxZW11LXhlbi10cmFkaXRp
b25hbC1kaXItcmVtb3RlLnRtcC4uLg0KPiBmYXRhbDogcmVhZCBlcnJvcjogQ29ubmVjdGlvbiBy
ZXNldCBieSBwZWVyDQo+DQo+DQo+IGdpdCBkb3duPw0KDQpXZSBoYXZlIG9jY2FzaW9uYWwgcHJv
YmxlbXMgd2l0aCBzdHVjayBnaXQgZGFlbW9uIHByb2Nlc3NlcyBhbGwgY29taW5nDQpmb3JtIHRo
ZSBzYW1lIElQIGFkZHJlc3MsIHdoaWNoIGV2ZW50dWFsbHkgdXNlIHVwIHRoZSBxdW90YSBvZiBj
aGlsZA0KcHJvY2Vzc2VzLiBJdCBzZWVtcyB0aGF0IHdlIGhhdmUgYSBuZXcgcHJvYmxlbWF0aWMg
SVAgYWRkcmVzcy4NCg0KSSd2ZSBqdXN0IGtpbGxlZCBhIGNvdXBsZSBvZiBkb3plbiBnaXQgcHJv
Y2Vzc2VzIHdoaWNoIGhhZCBiZWVuIHJ1bm5pbmcNCmZvciBzZXZlcmFsIHdlZWtzLCB0aGluZ3Mg
c2hvdWxkIGJlIGJhY2sgdG8gbm9ybWFsLg0KDQpJYW4uDQoNCg0KDQo=

--_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl
eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxwcmUgc3R5bGU9Indv
cmQtd3JhcDpicmVhay13b3JkOyBmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTpUYWhvbWE7
IGNvbG9yOmJsYWNrIj5TaG91bGQgYmUgZml4ZWQgbm93LiBTb3JyeSBmb3IgdGhlIGluY29udmVu
aWVuY2UuIAoKS3Jpc3RpamFuIExlxI1uaWsgJmx0O2phbmV6M2tAZ21haWwuY29tJmd0OyB3cm90
ZToKCjwvcHJlPg0KPGRpdj5IaSwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PnN0aWxsIGNhbnQg
Y29ubmVjdDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mIzQzOyAvcm9v
dC94ZW4tdW5zdGFibGUuaGctcmV2L3Rvb2xzLy4uL3NjcmlwdHMvZ2l0LWNoZWNrb3V0LnNoIGdp
dDovLzxhIGhyZWY9Imh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFi
bGUuZ2l0Ij54ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0PC9hPiA4
MmRiOGRlMTY1MzBmMDE2ODA5MjY0ZDMxNzk4MjM5OTlkNzAyODQ5IHFlbXUteGVuLXRyYWRpdGlv
bmFsLWRpcjwvZGl2Pg0KPGRpdj5DbG9uaW5nIGludG8gcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGly
LXJlbW90ZS50bXAuLi48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL3hlbmJpdHMueGVuc291
cmNlLmNvbSI+eGVuYml0cy54ZW5zb3VyY2UuY29tPC9hPlswOiA1MC41Ny4xNzAuMjQyXTogZXJy
bm89Q29ubmVjdGlvbiByZWZ1c2VkPC9kaXY+DQo8ZGl2PmZhdGFsOiB1bmFibGUgdG8gY29ubmVj
dCBhIHNvY2tldCAoQ29ubmVjdGlvbiByZWZ1c2VkKTwvZGl2Pg0KPGRpdj5tYWtlWzFdOiAqKiog
W3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci1maW5kXSBFcnJvciAxMjg8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+aSBhbSBzb3JyeSB0byBjb21wbGFpbiwgZG9uJ3QgaGF2
ZSB0aGUgdGltZSB0byBwbGF5IHdpdGggeGVuIG90aGVyIHRoZW4gb24mbmJzcDt3ZWVrZW5kIDop
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2
PktyaXN0aWphbiBMZWNuaWs8L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv
dGUiPk9uIFN1biwgQXByIDIyLCAyMDEyIGF0IDY6MjYgUE0sIElhbiBDYW1wYmVsbCA8c3BhbiBk
aXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOklhbi5DYW1wYmVsbEBjaXRyaXguY29tIj5J
YW4uQ2FtcGJlbGxAY2l0cml4LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2tx
dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt
bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IkhPRW5a
YiI+DQo8ZGl2IGNsYXNzPSJoNSI+T24gU3VuLCAyMDEyLTA0LTIyIGF0IDExOjIzIC0wNDAwLCBL
cmlzdGlqYW4gTGXEjW5payB3cm90ZTo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7
PGJyPg0KJmd0OyB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBwcm9ibGVtczo8YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgJiM0MzsgL3Jvb3QveGVuLXVuc3RhYmxlLmhnLXJldi90b29s
cy8uLi9zY3JpcHRzL2dpdC1jaGVja291dC5zaDxicj4NCiZndDsgZ2l0Oi8vPGEgaHJlZj0iaHR0
cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0YWJsZS5naXQiIHRhcmdldD0i
X2JsYW5rIj54ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0PC9hPjxi
cj4NCiZndDsgODJkYjhkZTE2NTMwZjAxNjgwOTI2NGQzMTc5ODIzOTk5ZDcwMjg0OSBxZW11LXhl
bi10cmFkaXRpb25hbC1kaXI8YnI+DQomZ3Q7IENsb25pbmcgaW50byBxZW11LXhlbi10cmFkaXRp
b25hbC1kaXItcmVtb3RlLnRtcC4uLjxicj4NCiZndDsgZmF0YWw6IHJlYWQgZXJyb3I6IENvbm5l
Y3Rpb24gcmVzZXQgYnkgcGVlcjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBnaXQgZG93
bj88YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KV2UgaGF2ZSBvY2Nhc2lvbmFsIHByb2JsZW1z
IHdpdGggc3R1Y2sgZ2l0IGRhZW1vbiBwcm9jZXNzZXMgYWxsIGNvbWluZzxicj4NCmZvcm0gdGhl
IHNhbWUgSVAgYWRkcmVzcywgd2hpY2ggZXZlbnR1YWxseSB1c2UgdXAgdGhlIHF1b3RhIG9mIGNo
aWxkPGJyPg0KcHJvY2Vzc2VzLiBJdCBzZWVtcyB0aGF0IHdlIGhhdmUgYSBuZXcgcHJvYmxlbWF0
aWMgSVAgYWRkcmVzcy48YnI+DQo8YnI+DQpJJ3ZlIGp1c3Qga2lsbGVkIGEgY291cGxlIG9mIGRv
emVuIGdpdCBwcm9jZXNzZXMgd2hpY2ggaGFkIGJlZW4gcnVubmluZzxicj4NCmZvciBzZXZlcmFs
IHdlZWtzLCB0aGluZ3Mgc2hvdWxkIGJlIGJhY2sgdG8gbm9ybWFsLjxicj4NCjxzcGFuIGNsYXNz
PSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+DQpJYW4uPGJyPg0KPGJyPg0KPGJy
Pg0KPC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_--


--===============8528037036056113393==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8528037036056113393==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 17:29:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 17:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM0ay-0002aE-VF; Sun, 22 Apr 2012 17:29:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SM0ax-0002a9-5M
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 17:29:07 +0000
Received: from [85.158.139.83:32513] by server-1.bemta-5.messagelabs.com id
	8F/CE-28458-2EF349F4; Sun, 22 Apr 2012 17:29:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335115744!21075320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY3Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23491 invoked from network); 22 Apr 2012 17:29:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 17:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,462,1330905600"; d="scan'208,217";a="12066693"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Apr 2012 17:29:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Sun, 22 Apr 2012
	18:29:04 +0100
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?utf-8?B?S3Jpc3RpamFuIExlxI1uaWs=?= <janez3k@gmail.com>
Date: Sun, 22 Apr 2012 18:29:03 +0100
Thread-Topic: [Xen-devel] git down?
Thread-Index: Ac0gq4oFBBxskBt/QQ2fBHi6gTQeJgAAd+Jx
Message-ID: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8528037036056113393=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8528037036056113393==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_"

--_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2hvdWxkIGJlIGZpeGVkIG5vdy4gU29ycnkgZm9yIHRoZSBpbmNvbnZlbmllbmNlLg0KDQpLcmlz
dGlqYW4gTGXEjW5payA8amFuZXoza0BnbWFpbC5jb20+IHdyb3RlOg0KDQoNCg0KSGksDQoNCnN0
aWxsIGNhbnQgY29ubmVjdDoNCg0KKyAvcm9vdC94ZW4tdW5zdGFibGUuaGctcmV2L3Rvb2xzLy4u
L3NjcmlwdHMvZ2l0LWNoZWNrb3V0LnNoIGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11
LXhlbi11bnN0YWJsZS5naXQ8aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11
bnN0YWJsZS5naXQ+IDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkgcWVt
dS14ZW4tdHJhZGl0aW9uYWwtZGlyDQpDbG9uaW5nIGludG8gcWVtdS14ZW4tdHJhZGl0aW9uYWwt
ZGlyLXJlbW90ZS50bXAuLi4NCnhlbmJpdHMueGVuc291cmNlLmNvbTxodHRwOi8veGVuYml0cy54
ZW5zb3VyY2UuY29tPlswOiA1MC41Ny4xNzAuMjQyXTogZXJybm89Q29ubmVjdGlvbiByZWZ1c2Vk
DQpmYXRhbDogdW5hYmxlIHRvIGNvbm5lY3QgYSBzb2NrZXQgKENvbm5lY3Rpb24gcmVmdXNlZCkN
Cm1ha2VbMV06ICoqKiBbcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyLWZpbmRdIEVycm9yIDEyOA0K
DQppIGFtIHNvcnJ5IHRvIGNvbXBsYWluLCBkb24ndCBoYXZlIHRoZSB0aW1lIHRvIHBsYXkgd2l0
aCB4ZW4gb3RoZXIgdGhlbiBvbiB3ZWVrZW5kIDopDQoNCkJlc3QgUmVnYXJkcywNCktyaXN0aWph
biBMZWNuaWsNCg0KT24gU3VuLCBBcHIgMjIsIDIwMTIgYXQgNjoyNiBQTSwgSWFuIENhbXBiZWxs
IDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbTxtYWlsdG86SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+
PiB3cm90ZToNCk9uIFN1biwgMjAxMi0wNC0yMiBhdCAxMToyMyAtMDQwMCwgS3Jpc3RpamFuIExl
xI1uaWsgd3JvdGU6DQo+IEhpLA0KPg0KPg0KPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBw
cm9ibGVtczoNCj4NCj4NCj4gKyAvcm9vdC94ZW4tdW5zdGFibGUuaGctcmV2L3Rvb2xzLy4uL3Nj
cmlwdHMvZ2l0LWNoZWNrb3V0LnNoDQo+IGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11
LXhlbi11bnN0YWJsZS5naXQ8aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11
bnN0YWJsZS5naXQ+DQo+IDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkg
cWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyDQo+IENsb25pbmcgaW50byBxZW11LXhlbi10cmFkaXRp
b25hbC1kaXItcmVtb3RlLnRtcC4uLg0KPiBmYXRhbDogcmVhZCBlcnJvcjogQ29ubmVjdGlvbiBy
ZXNldCBieSBwZWVyDQo+DQo+DQo+IGdpdCBkb3duPw0KDQpXZSBoYXZlIG9jY2FzaW9uYWwgcHJv
YmxlbXMgd2l0aCBzdHVjayBnaXQgZGFlbW9uIHByb2Nlc3NlcyBhbGwgY29taW5nDQpmb3JtIHRo
ZSBzYW1lIElQIGFkZHJlc3MsIHdoaWNoIGV2ZW50dWFsbHkgdXNlIHVwIHRoZSBxdW90YSBvZiBj
aGlsZA0KcHJvY2Vzc2VzLiBJdCBzZWVtcyB0aGF0IHdlIGhhdmUgYSBuZXcgcHJvYmxlbWF0aWMg
SVAgYWRkcmVzcy4NCg0KSSd2ZSBqdXN0IGtpbGxlZCBhIGNvdXBsZSBvZiBkb3plbiBnaXQgcHJv
Y2Vzc2VzIHdoaWNoIGhhZCBiZWVuIHJ1bm5pbmcNCmZvciBzZXZlcmFsIHdlZWtzLCB0aGluZ3Mg
c2hvdWxkIGJlIGJhY2sgdG8gbm9ybWFsLg0KDQpJYW4uDQoNCg0KDQo=

--_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl
eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxwcmUgc3R5bGU9Indv
cmQtd3JhcDpicmVhay13b3JkOyBmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTpUYWhvbWE7
IGNvbG9yOmJsYWNrIj5TaG91bGQgYmUgZml4ZWQgbm93LiBTb3JyeSBmb3IgdGhlIGluY29udmVu
aWVuY2UuIAoKS3Jpc3RpamFuIExlxI1uaWsgJmx0O2phbmV6M2tAZ21haWwuY29tJmd0OyB3cm90
ZToKCjwvcHJlPg0KPGRpdj5IaSwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PnN0aWxsIGNhbnQg
Y29ubmVjdDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mIzQzOyAvcm9v
dC94ZW4tdW5zdGFibGUuaGctcmV2L3Rvb2xzLy4uL3NjcmlwdHMvZ2l0LWNoZWNrb3V0LnNoIGdp
dDovLzxhIGhyZWY9Imh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFi
bGUuZ2l0Ij54ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0PC9hPiA4
MmRiOGRlMTY1MzBmMDE2ODA5MjY0ZDMxNzk4MjM5OTlkNzAyODQ5IHFlbXUteGVuLXRyYWRpdGlv
bmFsLWRpcjwvZGl2Pg0KPGRpdj5DbG9uaW5nIGludG8gcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGly
LXJlbW90ZS50bXAuLi48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL3hlbmJpdHMueGVuc291
cmNlLmNvbSI+eGVuYml0cy54ZW5zb3VyY2UuY29tPC9hPlswOiA1MC41Ny4xNzAuMjQyXTogZXJy
bm89Q29ubmVjdGlvbiByZWZ1c2VkPC9kaXY+DQo8ZGl2PmZhdGFsOiB1bmFibGUgdG8gY29ubmVj
dCBhIHNvY2tldCAoQ29ubmVjdGlvbiByZWZ1c2VkKTwvZGl2Pg0KPGRpdj5tYWtlWzFdOiAqKiog
W3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci1maW5kXSBFcnJvciAxMjg8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+aSBhbSBzb3JyeSB0byBjb21wbGFpbiwgZG9uJ3QgaGF2
ZSB0aGUgdGltZSB0byBwbGF5IHdpdGggeGVuIG90aGVyIHRoZW4gb24mbmJzcDt3ZWVrZW5kIDop
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2
PktyaXN0aWphbiBMZWNuaWs8L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv
dGUiPk9uIFN1biwgQXByIDIyLCAyMDEyIGF0IDY6MjYgUE0sIElhbiBDYW1wYmVsbCA8c3BhbiBk
aXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOklhbi5DYW1wYmVsbEBjaXRyaXguY29tIj5J
YW4uQ2FtcGJlbGxAY2l0cml4LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2tx
dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt
bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IkhPRW5a
YiI+DQo8ZGl2IGNsYXNzPSJoNSI+T24gU3VuLCAyMDEyLTA0LTIyIGF0IDExOjIzIC0wNDAwLCBL
cmlzdGlqYW4gTGXEjW5payB3cm90ZTo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7
PGJyPg0KJmd0OyB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBwcm9ibGVtczo8YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgJiM0MzsgL3Jvb3QveGVuLXVuc3RhYmxlLmhnLXJldi90b29s
cy8uLi9zY3JpcHRzL2dpdC1jaGVja291dC5zaDxicj4NCiZndDsgZ2l0Oi8vPGEgaHJlZj0iaHR0
cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0YWJsZS5naXQiIHRhcmdldD0i
X2JsYW5rIj54ZW5iaXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0PC9hPjxi
cj4NCiZndDsgODJkYjhkZTE2NTMwZjAxNjgwOTI2NGQzMTc5ODIzOTk5ZDcwMjg0OSBxZW11LXhl
bi10cmFkaXRpb25hbC1kaXI8YnI+DQomZ3Q7IENsb25pbmcgaW50byBxZW11LXhlbi10cmFkaXRp
b25hbC1kaXItcmVtb3RlLnRtcC4uLjxicj4NCiZndDsgZmF0YWw6IHJlYWQgZXJyb3I6IENvbm5l
Y3Rpb24gcmVzZXQgYnkgcGVlcjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBnaXQgZG93
bj88YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KV2UgaGF2ZSBvY2Nhc2lvbmFsIHByb2JsZW1z
IHdpdGggc3R1Y2sgZ2l0IGRhZW1vbiBwcm9jZXNzZXMgYWxsIGNvbWluZzxicj4NCmZvcm0gdGhl
IHNhbWUgSVAgYWRkcmVzcywgd2hpY2ggZXZlbnR1YWxseSB1c2UgdXAgdGhlIHF1b3RhIG9mIGNo
aWxkPGJyPg0KcHJvY2Vzc2VzLiBJdCBzZWVtcyB0aGF0IHdlIGhhdmUgYSBuZXcgcHJvYmxlbWF0
aWMgSVAgYWRkcmVzcy48YnI+DQo8YnI+DQpJJ3ZlIGp1c3Qga2lsbGVkIGEgY291cGxlIG9mIGRv
emVuIGdpdCBwcm9jZXNzZXMgd2hpY2ggaGFkIGJlZW4gcnVubmluZzxicj4NCmZvciBzZXZlcmFs
IHdlZWtzLCB0aGluZ3Mgc2hvdWxkIGJlIGJhY2sgdG8gbm9ybWFsLjxicj4NCjxzcGFuIGNsYXNz
PSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+DQpJYW4uPGJyPg0KPGJyPg0KPGJy
Pg0KPC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_kf3wo7nppdbvvcct1ropt4rp1335115737756emailandroidcom_--


--===============8528037036056113393==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8528037036056113393==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 17:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 17:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM0bm-0002ds-Pc; Sun, 22 Apr 2012 17:29:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SM0bl-0002dj-Bg
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 17:29:57 +0000
Received: from [85.158.143.35:58909] by server-1.bemta-4.messagelabs.com id
	3F/1B-20925-410449F4; Sun, 22 Apr 2012 17:29:56 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335115795!13574814!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24725 invoked from network); 22 Apr 2012 17:29:55 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 17:29:55 -0000
Received: by bkcji1 with SMTP id ji1so2600584bkc.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 10:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=h/gXdeLzqPUNTkI2/xZd/RqBTXjnlKP9AWqreEwvu/4=;
	b=dIWwYlkNNlXLf9AQH7kN5uNu+UPSSyw6psxKMWj2l54YpyuKuXd+TmzMFdeOuuf7bO
	aU9/O60Kqg4QevMpAltJsZewL4Nar3pCh5trsbgJ+dsfwmvDKABqRij+CQN4Dsia2ecu
	5RCs+PN9dMjcdgbo4eXtM5CLl6DVzkYf87A4sHdRORAY3x7ROJ+TP6thz3W3/mhu/lUn
	Vbos+lE8S3cV03Gj3E6+DY0Uxjzg4rVz2QowCEgm2wmNTUf+VChSu+iepHT/n/I/xEHz
	pGAVZKsSd2bcMpU+IWOrTBBmMcYRadSYPfq23+aA2v/Qv2oxEPlCS5AJoByptUUBZRgE
	2N2w==
MIME-Version: 1.0
Received: by 10.204.152.25 with SMTP id e25mr3984865bkw.55.1335115794813; Sun,
	22 Apr 2012 10:29:54 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Sun, 22 Apr 2012 10:29:54 -0700 (PDT)
In-Reply-To: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
References: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
Date: Sun, 22 Apr 2012 19:29:54 +0200
Message-ID: <CACC+8CRjXooy_ga8FGu+-EvajSY1ng7P3or4_JhJpLOjhGS3sw@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0464372365322617162=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0464372365322617162==
Content-Type: multipart/alternative; boundary=0015175cbae6af145c04be47de44

--0015175cbae6af145c04be47de44
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

works, thank you!

Best Regards,
Kristijan Lecnik

On Sun, Apr 22, 2012 at 7:29 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

>  Should be fixed now. Sorry for the inconvenience.
>
> Kristijan Le=C4=8Dnik <janez3k@gmail.com> wrote:
>
>
> Hi,
>
>  still cant connect:
>
>  + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://
> xenbits.xensource.com/qemu-xen-unstable.git82db8de16530f016809264d3179823=
999d702849 qemu-xen-traditional-dir
> Cloning into qemu-xen-traditional-dir-remote.tmp...
> xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused
> fatal: unable to connect a socket (Connection refused)
> make[1]: *** [qemu-xen-traditional-dir-find] Error 128
>
>  i am sorry to complain, don't have the time to play with xen other then
> on weekend :)
>
>  Best Regards,
> Kristijan Lecnik
>
> On Sun, Apr 22, 2012 at 6:26 PM, Ian Campbell <Ian.Campbell@citrix.com>wr=
ote:
>
>>  On Sun, 2012-04-22 at 11:23 -0400, Kristijan Le=C4=8Dnik wrote:
>> > Hi,
>> >
>> >
>> > trying to compile but have problems:
>> >
>> >
>> > + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh
>> > git://xenbits.xensource.com/qemu-xen-unstable.git
>> > 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir
>> > Cloning into qemu-xen-traditional-dir-remote.tmp...
>> > fatal: read error: Connection reset by peer
>> >
>> >
>> > git down?
>>
>>  We have occasional problems with stuck git daemon processes all coming
>> form the same IP address, which eventually use up the quota of child
>> processes. It seems that we have a new problematic IP address.
>>
>> I've just killed a couple of dozen git processes which had been running
>> for several weeks, things should be back to normal.
>>
>> Ian.
>>
>>
>>
>

--0015175cbae6af145c04be47de44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>works, thank you!<br><br>Best Regards,</div><div>Kri=
stijan Lecnik</div><div><br><div class=3D"gmail_quote">On Sun, Apr 22, 2012=
 at 7:29 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campb=
ell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">


<div>
<pre style=3D"font-size:10.0pt;font-family:Tahoma;word-wrap:break-word">Sho=
uld be fixed now. Sorry for the inconvenience.=20

Kristijan Le=C4=8Dnik &lt;<a href=3D"mailto:janez3k@gmail.com" target=3D"_b=
lank">janez3k@gmail.com</a>&gt; wrote:

</pre><div><div class=3D"h5">
<div>Hi,
<div><br>
</div>
<div>still cant connect:</div>
<div><br>
</div>
<div>
<div>+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://<a =
href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" target=3D"_blan=
k">xenbits.xensource.com/qemu-xen-unstable.git</a> 82db8de16530f016809264d3=
179823999d702849 qemu-xen-traditional-dir</div>

<div>Cloning into qemu-xen-traditional-dir-remote.tmp...</div>
<div><a href=3D"http://xenbits.xensource.com" target=3D"_blank">xenbits.xen=
source.com</a>[0: 50.57.170.242]: errno=3DConnection refused</div>
<div>fatal: unable to connect a socket (Connection refused)</div>
<div>make[1]: *** [qemu-xen-traditional-dir-find] Error 128</div>
</div>
<div><br>
</div>
<div>i am sorry to complain, don&#39;t have the time to play with xen other=
 then on=C2=A0weekend :)</div>
<div><br>
</div>
<div>Best Regards,</div>
<div>Kristijan Lecnik</div>
<div><br>
<div class=3D"gmail_quote">On Sun, Apr 22, 2012 at 6:26 PM, Ian Campbell <s=
pan dir=3D"ltr">
&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbe=
ll@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>
<div>On Sun, 2012-04-22 at 11:23 -0400, Kristijan Le=C4=8Dnik wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; trying to compile but have problems:<br>
&gt;<br>
&gt;<br>
&gt; + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh<br>
&gt; git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" t=
arget=3D"_blank">xenbits.xensource.com/qemu-xen-unstable.git</a><br>
&gt; 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir<br>
&gt; Cloning into qemu-xen-traditional-dir-remote.tmp...<br>
&gt; fatal: read error: Connection reset by peer<br>
&gt;<br>
&gt;<br>
&gt; git down?<br>
<br>
</div>
</div>
We have occasional problems with stuck git daemon processes all coming<br>
form the same IP address, which eventually use up the quota of child<br>
processes. It seems that we have a new problematic IP address.<br>
<br>
I&#39;ve just killed a couple of dozen git processes which had been running=
<br>
for several weeks, things should be back to normal.<br>
<span><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
</div></div></div>

</blockquote></div><br></div>

--0015175cbae6af145c04be47de44--


--===============0464372365322617162==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0464372365322617162==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 17:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 17:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM0bm-0002ds-Pc; Sun, 22 Apr 2012 17:29:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1SM0bl-0002dj-Bg
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 17:29:57 +0000
Received: from [85.158.143.35:58909] by server-1.bemta-4.messagelabs.com id
	3F/1B-20925-410449F4; Sun, 22 Apr 2012 17:29:56 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335115795!13574814!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24725 invoked from network); 22 Apr 2012 17:29:55 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 17:29:55 -0000
Received: by bkcji1 with SMTP id ji1so2600584bkc.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 10:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=h/gXdeLzqPUNTkI2/xZd/RqBTXjnlKP9AWqreEwvu/4=;
	b=dIWwYlkNNlXLf9AQH7kN5uNu+UPSSyw6psxKMWj2l54YpyuKuXd+TmzMFdeOuuf7bO
	aU9/O60Kqg4QevMpAltJsZewL4Nar3pCh5trsbgJ+dsfwmvDKABqRij+CQN4Dsia2ecu
	5RCs+PN9dMjcdgbo4eXtM5CLl6DVzkYf87A4sHdRORAY3x7ROJ+TP6thz3W3/mhu/lUn
	Vbos+lE8S3cV03Gj3E6+DY0Uxjzg4rVz2QowCEgm2wmNTUf+VChSu+iepHT/n/I/xEHz
	pGAVZKsSd2bcMpU+IWOrTBBmMcYRadSYPfq23+aA2v/Qv2oxEPlCS5AJoByptUUBZRgE
	2N2w==
MIME-Version: 1.0
Received: by 10.204.152.25 with SMTP id e25mr3984865bkw.55.1335115794813; Sun,
	22 Apr 2012 10:29:54 -0700 (PDT)
Received: by 10.204.174.81 with HTTP; Sun, 22 Apr 2012 10:29:54 -0700 (PDT)
In-Reply-To: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
References: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
Date: Sun, 22 Apr 2012 19:29:54 +0200
Message-ID: <CACC+8CRjXooy_ga8FGu+-EvajSY1ng7P3or4_JhJpLOjhGS3sw@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0464372365322617162=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0464372365322617162==
Content-Type: multipart/alternative; boundary=0015175cbae6af145c04be47de44

--0015175cbae6af145c04be47de44
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

works, thank you!

Best Regards,
Kristijan Lecnik

On Sun, Apr 22, 2012 at 7:29 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

>  Should be fixed now. Sorry for the inconvenience.
>
> Kristijan Le=C4=8Dnik <janez3k@gmail.com> wrote:
>
>
> Hi,
>
>  still cant connect:
>
>  + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://
> xenbits.xensource.com/qemu-xen-unstable.git82db8de16530f016809264d3179823=
999d702849 qemu-xen-traditional-dir
> Cloning into qemu-xen-traditional-dir-remote.tmp...
> xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused
> fatal: unable to connect a socket (Connection refused)
> make[1]: *** [qemu-xen-traditional-dir-find] Error 128
>
>  i am sorry to complain, don't have the time to play with xen other then
> on weekend :)
>
>  Best Regards,
> Kristijan Lecnik
>
> On Sun, Apr 22, 2012 at 6:26 PM, Ian Campbell <Ian.Campbell@citrix.com>wr=
ote:
>
>>  On Sun, 2012-04-22 at 11:23 -0400, Kristijan Le=C4=8Dnik wrote:
>> > Hi,
>> >
>> >
>> > trying to compile but have problems:
>> >
>> >
>> > + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh
>> > git://xenbits.xensource.com/qemu-xen-unstable.git
>> > 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir
>> > Cloning into qemu-xen-traditional-dir-remote.tmp...
>> > fatal: read error: Connection reset by peer
>> >
>> >
>> > git down?
>>
>>  We have occasional problems with stuck git daemon processes all coming
>> form the same IP address, which eventually use up the quota of child
>> processes. It seems that we have a new problematic IP address.
>>
>> I've just killed a couple of dozen git processes which had been running
>> for several weeks, things should be back to normal.
>>
>> Ian.
>>
>>
>>
>

--0015175cbae6af145c04be47de44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>works, thank you!<br><br>Best Regards,</div><div>Kri=
stijan Lecnik</div><div><br><div class=3D"gmail_quote">On Sun, Apr 22, 2012=
 at 7:29 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campb=
ell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">


<div>
<pre style=3D"font-size:10.0pt;font-family:Tahoma;word-wrap:break-word">Sho=
uld be fixed now. Sorry for the inconvenience.=20

Kristijan Le=C4=8Dnik &lt;<a href=3D"mailto:janez3k@gmail.com" target=3D"_b=
lank">janez3k@gmail.com</a>&gt; wrote:

</pre><div><div class=3D"h5">
<div>Hi,
<div><br>
</div>
<div>still cant connect:</div>
<div><br>
</div>
<div>
<div>+ /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh git://<a =
href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" target=3D"_blan=
k">xenbits.xensource.com/qemu-xen-unstable.git</a> 82db8de16530f016809264d3=
179823999d702849 qemu-xen-traditional-dir</div>

<div>Cloning into qemu-xen-traditional-dir-remote.tmp...</div>
<div><a href=3D"http://xenbits.xensource.com" target=3D"_blank">xenbits.xen=
source.com</a>[0: 50.57.170.242]: errno=3DConnection refused</div>
<div>fatal: unable to connect a socket (Connection refused)</div>
<div>make[1]: *** [qemu-xen-traditional-dir-find] Error 128</div>
</div>
<div><br>
</div>
<div>i am sorry to complain, don&#39;t have the time to play with xen other=
 then on=C2=A0weekend :)</div>
<div><br>
</div>
<div>Best Regards,</div>
<div>Kristijan Lecnik</div>
<div><br>
<div class=3D"gmail_quote">On Sun, Apr 22, 2012 at 6:26 PM, Ian Campbell <s=
pan dir=3D"ltr">
&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbe=
ll@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>
<div>On Sun, 2012-04-22 at 11:23 -0400, Kristijan Le=C4=8Dnik wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; trying to compile but have problems:<br>
&gt;<br>
&gt;<br>
&gt; + /root/xen-unstable.hg-rev/tools/../scripts/git-checkout.sh<br>
&gt; git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" t=
arget=3D"_blank">xenbits.xensource.com/qemu-xen-unstable.git</a><br>
&gt; 82db8de16530f016809264d3179823999d702849 qemu-xen-traditional-dir<br>
&gt; Cloning into qemu-xen-traditional-dir-remote.tmp...<br>
&gt; fatal: read error: Connection reset by peer<br>
&gt;<br>
&gt;<br>
&gt; git down?<br>
<br>
</div>
</div>
We have occasional problems with stuck git daemon processes all coming<br>
form the same IP address, which eventually use up the quota of child<br>
processes. It seems that we have a new problematic IP address.<br>
<br>
I&#39;ve just killed a couple of dozen git processes which had been running=
<br>
for several weeks, things should be back to normal.<br>
<span><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
</div></div></div>

</blockquote></div><br></div>

--0015175cbae6af145c04be47de44--


--===============0464372365322617162==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0464372365322617162==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 19:21:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 19:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM2LW-0004Cy-K7; Sun, 22 Apr 2012 19:21:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SM2LV-0004Cs-2E
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 19:21:17 +0000
Received: from [85.158.143.99:19785] by server-3.bemta-4.messagelabs.com id
	14/C3-05853-C2A549F4; Sun, 22 Apr 2012 19:21:16 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335122472!23842881!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 988 invoked from network); 22 Apr 2012 19:21:13 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 19:21:13 -0000
Received: by obbwd18 with SMTP id wd18so12029551obb.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 12:21:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=9Uc1jJw7OWKU2GOKTM6Wx5hYVgLFBjyF9hMe3vjddC0=;
	b=e3n5um/jBPzdRWCuZaGrhJrncN/KMrG5BxtSF2jOTiNro5rpl7ksNcQgwFQMH0iIRa
	uW8jM38GDA0xWD6y5oJYFvGbkW36/kG66sECnA6o1XpPcsq3JUK3m2o42s/inES2P1dK
	ZE6iBhFzdXmAOmLpk6BAsKx/9lQpeHXkZ32DPmb+XyOanRX4tqABk42Vt15N5SeGj68X
	E2RlxLzJ7Sia/6TwFabmzHMqyrJoCCL4ln5BpBqNJ1Ehy8LmeqsUfApHdLULR/O2haKe
	UxCaBgzoTCt3p1dGXgTRZxvumc5Hbt9uxKM9H9fS50puRI5xisEhXn8wNBv7dDKIGHl1
	gxuA==
MIME-Version: 1.0
Received: by 10.60.19.106 with SMTP id d10mr18828846oee.40.1335122470843; Sun,
	22 Apr 2012 12:21:10 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Sun, 22 Apr 2012 12:21:10 -0700 (PDT)
Date: Sun, 22 Apr 2012 16:21:10 -0300
Message-ID: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3903910243817190300=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3903910243817190300==
Content-Type: multipart/alternative; boundary=e89a8ff1c4a89b34b104be496c7d

--e89a8ff1c4a89b34b104be496c7d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi guys,

It's my first time here and in a mailing lists, I only participated in
forums before. Please, If I make a mistake you should advise me. Let's go!

I was reading "xencommons not start" in a Remus Forum in order to install
Remus.
Well=85 I followed the tutorial <
http://remusha.wikidot.com/configuring-and-installing-remus>, I reboot in
xen_unstable and I had a error message:

error: couldn't open file
error: you need to load the multiboot kernel first

then I redid tutorial after "Adapt Grub" and in a moment I do command:

# /etc/init.d/xend start
xencommons should be started first.

but I had done "/etc/init.d/xencommons start" before and no error message
returned !!!???

I also tried insert modules manually (coz in other mailing list said to put
some modules - see my setups after this mail) but I had:

# modprobe xen-evtchn
FATAL: Module xen_evtchn not found.

Please, help me
Thanks.

PS: I'm sorry to my English, coz I'm brazilian.

My setups are:

- fdisk

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          32      248832   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              32       30395   243889153    5  Extended
/dev/sda5              32       30395   243889152   8e  Linux LVM

- blkid

root@debian-02:/home/franca# blkid
/dev/sda5: UUID=3D"RVwX4M-56HI-Tu9q-CLkP-V0jx-Ft7W-b0bPHP" TYPE=3D"LVM2_mem=
ber"
/dev/sda1: UUID=3D"fcc01979-0cf3-4dbe-863a-ab32d2636fec" TYPE=3D"ext3"
/dev/mapper/debian--02-root: UUID=3D"da8b402b-b224-4552-80df-754339518e4d"
TYPE=3D"ext3"
/dev/mapper/debian--02-swap_1: UUID=3D"d5eb1ff7-b7d8-4b60-95e3-f4bb5ae32932=
"
TYPE=3D"swap"

My scripts are:

- 08_xen

#!/bin/sh
exec tail -n +3 $0
menuentry "Xen Unstable / Debian Squeeze kernel 2.6.32.40" {
### MY ATTEMPT
    insmod ext2
        set root=3D'(hd0,msdos1)'
        multiboot (hd0,msdos1)/boot/xen-4.2-unstable.gz dummy dom0_mem=3D51=
2M
        module (hd0,msdos1)/boot/vmlinuz-2.6.32.40 dummy
root=3DUUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec ro quiet console=3Dtty0
nomodeset
        module (hd0,msdos1)/boot/initrd.img-2.6.32.40

### MODEL Configuring and Installing Remus
        #insmod ext2
        #set root=3D'(hd0,1)'
        #multiboot (hd0,1)/boot/xen-4.2-unstable.gz dummy dom0_mem=3D512M
        #module (hd0,1)/boot/vmlinuz-2.6.32.40 dummy
root=3DUUID=3D8e339522-dab5-4a81-8066-c41cc3908a15 ro quiet console=3Dtty0
nomodeset
        #module (hd0,1)/boot/initrd.img-2.6.32.40

### MODEL UBUNTU FORUM
    #insmod part_msdos
    #insmod ext2
        #set root=3D(hd0,msdos1)
    #search --no-floppy --fs-uuid --set fcc01979-0cf3-4dbe-863a-ab32d2636fe=
c
        #multiboot /boot/xen-4.2-unstable.gz
        #module /boot/vmlinuz-2.6.32.40 root=3D/dev/sda1
        #module /boot/initrd.img-2.6.32.40
}

- modules

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

loop
xen-evtchn
xen-gntdev
xen-netback
xen-blkback
xenfs
blktap2

- fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID=3D as a more robust way to name device=
s
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/debian--02-root /               ext3    errors=3Dremount-ro
0       1
# /boot was on /dev/sda1 during installation
UUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec /boot           ext3
defaults        0       2
/dev/mapper/debian--02-swap_1 none            swap    sw
0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
none /proc/xen xenfs defaults 0 0

--e89a8ff1c4a89b34b104be496c7d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi guys,<br><br>It&#39;s my first time here and in a mailing lists, I only =
participated in forums before. Please, If I make a mistake you should advis=
e me. Let&#39;s go!<br><br>I was reading &quot;xencommons not start&quot; i=
n a Remus Forum in order to install Remus.<br>
Well=85 I followed the tutorial &lt;<a href=3D"http://remusha.wikidot.com/c=
onfiguring-and-installing-remus">http://remusha.wikidot.com/configuring-and=
-installing-remus</a>&gt;, I reboot in xen_unstable and I had a error messa=
ge:<br>
<br>error: couldn&#39;t open file<br>error: you need to load the multiboot =
kernel first<br><br>then I redid tutorial after &quot;Adapt Grub&quot; and =
in a moment I do command:<br><br># /etc/init.d/xend start<br>xencommons sho=
uld be started first.<br>
<br>but I had done &quot;/etc/init.d/xencommons start&quot; before and no e=
rror message returned !!!???<br><br>
I also tried insert modules manually (coz in other mailing list said to put=
 some modules - see my setups after this mail) but I had:<br>
<br>
# modprobe xen-evtchn<br>
FATAL: Module xen_evtchn not found.<br>
<br>
Please, help me<br>
Thanks.<br>
<br>
PS: I&#39;m sorry to my English, coz I&#39;m brazilian.<br>
<br>My setups are:<br><br>- fdisk<br><br>=A0=A0 Device Boot=A0=A0=A0=A0=A0 =
Start=A0=A0=A0=A0=A0=A0=A0=A0 End=A0=A0=A0=A0=A0 Blocks=A0=A0 Id=A0 System<=
br>/dev/sda1=A0=A0 *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 32=A0=A0=A0=A0=A0 248832=A0=A0 83=A0 Linux<br>Partition 1 does not e=
nd on cylinder boundary.<br>
/dev/sda2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 32=A0=A0=A0=A0=A0=A0 30395=
=A0=A0 243889153=A0=A0=A0 5=A0 Extended<br>/dev/sda5=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 32=A0=A0=A0=A0=A0=A0 30395=A0=A0 243889152=A0=A0 8e=A0 L=
inux LVM<br><br>- blkid<br><br>root@debian-02:/home/franca# blkid<br>/dev/s=
da5: UUID=3D&quot;RVwX4M-56HI-Tu9q-CLkP-V0jx-Ft7W-b0bPHP&quot; TYPE=3D&quot=
;LVM2_member&quot; <br>
/dev/sda1: UUID=3D&quot;fcc01979-0cf3-4dbe-863a-ab32d2636fec&quot; TYPE=3D&=
quot;ext3&quot; <br>/dev/mapper/debian--02-root: UUID=3D&quot;da8b402b-b224=
-4552-80df-754339518e4d&quot; TYPE=3D&quot;ext3&quot; <br>/dev/mapper/debia=
n--02-swap_1: UUID=3D&quot;d5eb1ff7-b7d8-4b60-95e3-f4bb5ae32932&quot; TYPE=
=3D&quot;swap&quot;<br>
<br>My scripts are:<br><br>- 08_xen<br><br>#!/bin/sh<br>exec tail -n +3 $0<=
br>menuentry &quot;Xen Unstable / Debian Squeeze kernel 2.6.32.40&quot; {<b=
r>### MY ATTEMPT<br>=A0=A0=A0 insmod ext2<br>=A0=A0=A0=A0=A0=A0=A0 set root=
=3D&#39;(hd0,msdos1)&#39;<br>
=A0=A0=A0=A0=A0=A0=A0 multiboot (hd0,msdos1)/boot/xen-4.2-unstable.gz dummy=
 dom0_mem=3D512M<br>=A0=A0=A0=A0=A0=A0=A0 module (hd0,msdos1)/boot/vmlinuz-=
2.6.32.40 dummy root=3DUUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec ro quiet=
 console=3Dtty0 nomodeset<br>=A0=A0=A0=A0=A0=A0=A0 module (hd0,msdos1)/boot=
/initrd.img-2.6.32.40<br>
<br>### MODEL Configuring and Installing Remus<br>=A0=A0=A0=A0=A0=A0=A0 #in=
smod ext2<br>=A0=A0=A0=A0=A0=A0=A0 #set root=3D&#39;(hd0,1)&#39;<br>=A0=A0=
=A0=A0=A0=A0=A0 #multiboot (hd0,1)/boot/xen-4.2-unstable.gz dummy dom0_mem=
=3D512M<br>=A0=A0=A0=A0=A0=A0=A0 #module (hd0,1)/boot/vmlinuz-2.6.32.40 dum=
my root=3DUUID=3D8e339522-dab5-4a81-8066-c41cc3908a15 ro quiet console=3Dtt=
y0 nomodeset<br>
=A0=A0=A0=A0=A0=A0=A0 #module (hd0,1)/boot/initrd.img-2.6.32.40<br><br>### =
MODEL UBUNTU FORUM<br>=A0=A0=A0 #insmod part_msdos<br>=A0=A0=A0 #insmod ext=
2<br>=A0=A0=A0=A0=A0=A0=A0 #set root=3D(hd0,msdos1)<br>=A0=A0=A0 #search --=
no-floppy --fs-uuid --set fcc01979-0cf3-4dbe-863a-ab32d2636fec<br>
=A0=A0=A0=A0=A0=A0=A0 #multiboot /boot/xen-4.2-unstable.gz<br>=A0=A0=A0=A0=
=A0=A0=A0 #module /boot/vmlinuz-2.6.32.40 root=3D/dev/sda1<br>=A0=A0=A0=A0=
=A0=A0=A0 #module /boot/initrd.img-2.6.32.40<br>}<br><br>- modules<br><br>#=
 /etc/modules: kernel modules to load at boot time.<br>
#<br># This file contains the names of kernel modules that should be loaded=
<br># at boot time, one per line. Lines beginning with &quot;#&quot; are ig=
nored.<br># Parameters can be specified after the module name.<br><br>loop<=
br>
xen-evtchn<br>xen-gntdev<br>xen-netback<br>xen-blkback<br>xenfs<br>blktap2<=
br><br>- fstab<br><br># /etc/fstab: static file system information.<br>#<br=
># Use &#39;blkid&#39; to print the universally unique identifier for a<br>
# device; this may be used with UUID=3D as a more robust way to name device=
s<br># that works even if disks are added and removed. See fstab(5).<br>#<b=
r># &lt;file system&gt; &lt;mount point&gt;=A0=A0 &lt;type&gt;=A0 &lt;optio=
ns&gt;=A0=A0=A0=A0=A0=A0 &lt;dump&gt;=A0 &lt;pass&gt;<br>
proc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /proc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 p=
roc=A0=A0=A0 defaults=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 0<br>/dev/ma=
pper/debian--02-root /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ext3=A0=A0=
=A0 errors=3Dremount-ro 0=A0=A0=A0=A0=A0=A0 1<br># /boot was on /dev/sda1 d=
uring installation<br>UUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec /boot=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ext3=A0=A0=A0 defaults=A0=A0=A0=A0=A0=A0=A0 0=
=A0=A0=A0=A0=A0=A0 2<br>
/dev/mapper/debian--02-swap_1 none=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 swap=A0=
=A0=A0 sw=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 0<br>/=
dev/scd0=A0=A0=A0=A0=A0=A0 /media/cdrom0=A0=A0 udf,iso9660 user,noauto=A0=
=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 0<br>none /proc/xen xenfs defaults 0 0<br>

--e89a8ff1c4a89b34b104be496c7d--


--===============3903910243817190300==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3903910243817190300==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 19:21:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 19:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM2LW-0004Cy-K7; Sun, 22 Apr 2012 19:21:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SM2LV-0004Cs-2E
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 19:21:17 +0000
Received: from [85.158.143.99:19785] by server-3.bemta-4.messagelabs.com id
	14/C3-05853-C2A549F4; Sun, 22 Apr 2012 19:21:16 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335122472!23842881!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 988 invoked from network); 22 Apr 2012 19:21:13 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Apr 2012 19:21:13 -0000
Received: by obbwd18 with SMTP id wd18so12029551obb.32
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 12:21:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=9Uc1jJw7OWKU2GOKTM6Wx5hYVgLFBjyF9hMe3vjddC0=;
	b=e3n5um/jBPzdRWCuZaGrhJrncN/KMrG5BxtSF2jOTiNro5rpl7ksNcQgwFQMH0iIRa
	uW8jM38GDA0xWD6y5oJYFvGbkW36/kG66sECnA6o1XpPcsq3JUK3m2o42s/inES2P1dK
	ZE6iBhFzdXmAOmLpk6BAsKx/9lQpeHXkZ32DPmb+XyOanRX4tqABk42Vt15N5SeGj68X
	E2RlxLzJ7Sia/6TwFabmzHMqyrJoCCL4ln5BpBqNJ1Ehy8LmeqsUfApHdLULR/O2haKe
	UxCaBgzoTCt3p1dGXgTRZxvumc5Hbt9uxKM9H9fS50puRI5xisEhXn8wNBv7dDKIGHl1
	gxuA==
MIME-Version: 1.0
Received: by 10.60.19.106 with SMTP id d10mr18828846oee.40.1335122470843; Sun,
	22 Apr 2012 12:21:10 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Sun, 22 Apr 2012 12:21:10 -0700 (PDT)
Date: Sun, 22 Apr 2012 16:21:10 -0300
Message-ID: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3903910243817190300=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3903910243817190300==
Content-Type: multipart/alternative; boundary=e89a8ff1c4a89b34b104be496c7d

--e89a8ff1c4a89b34b104be496c7d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi guys,

It's my first time here and in a mailing lists, I only participated in
forums before. Please, If I make a mistake you should advise me. Let's go!

I was reading "xencommons not start" in a Remus Forum in order to install
Remus.
Well=85 I followed the tutorial <
http://remusha.wikidot.com/configuring-and-installing-remus>, I reboot in
xen_unstable and I had a error message:

error: couldn't open file
error: you need to load the multiboot kernel first

then I redid tutorial after "Adapt Grub" and in a moment I do command:

# /etc/init.d/xend start
xencommons should be started first.

but I had done "/etc/init.d/xencommons start" before and no error message
returned !!!???

I also tried insert modules manually (coz in other mailing list said to put
some modules - see my setups after this mail) but I had:

# modprobe xen-evtchn
FATAL: Module xen_evtchn not found.

Please, help me
Thanks.

PS: I'm sorry to my English, coz I'm brazilian.

My setups are:

- fdisk

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          32      248832   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              32       30395   243889153    5  Extended
/dev/sda5              32       30395   243889152   8e  Linux LVM

- blkid

root@debian-02:/home/franca# blkid
/dev/sda5: UUID=3D"RVwX4M-56HI-Tu9q-CLkP-V0jx-Ft7W-b0bPHP" TYPE=3D"LVM2_mem=
ber"
/dev/sda1: UUID=3D"fcc01979-0cf3-4dbe-863a-ab32d2636fec" TYPE=3D"ext3"
/dev/mapper/debian--02-root: UUID=3D"da8b402b-b224-4552-80df-754339518e4d"
TYPE=3D"ext3"
/dev/mapper/debian--02-swap_1: UUID=3D"d5eb1ff7-b7d8-4b60-95e3-f4bb5ae32932=
"
TYPE=3D"swap"

My scripts are:

- 08_xen

#!/bin/sh
exec tail -n +3 $0
menuentry "Xen Unstable / Debian Squeeze kernel 2.6.32.40" {
### MY ATTEMPT
    insmod ext2
        set root=3D'(hd0,msdos1)'
        multiboot (hd0,msdos1)/boot/xen-4.2-unstable.gz dummy dom0_mem=3D51=
2M
        module (hd0,msdos1)/boot/vmlinuz-2.6.32.40 dummy
root=3DUUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec ro quiet console=3Dtty0
nomodeset
        module (hd0,msdos1)/boot/initrd.img-2.6.32.40

### MODEL Configuring and Installing Remus
        #insmod ext2
        #set root=3D'(hd0,1)'
        #multiboot (hd0,1)/boot/xen-4.2-unstable.gz dummy dom0_mem=3D512M
        #module (hd0,1)/boot/vmlinuz-2.6.32.40 dummy
root=3DUUID=3D8e339522-dab5-4a81-8066-c41cc3908a15 ro quiet console=3Dtty0
nomodeset
        #module (hd0,1)/boot/initrd.img-2.6.32.40

### MODEL UBUNTU FORUM
    #insmod part_msdos
    #insmod ext2
        #set root=3D(hd0,msdos1)
    #search --no-floppy --fs-uuid --set fcc01979-0cf3-4dbe-863a-ab32d2636fe=
c
        #multiboot /boot/xen-4.2-unstable.gz
        #module /boot/vmlinuz-2.6.32.40 root=3D/dev/sda1
        #module /boot/initrd.img-2.6.32.40
}

- modules

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

loop
xen-evtchn
xen-gntdev
xen-netback
xen-blkback
xenfs
blktap2

- fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID=3D as a more robust way to name device=
s
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/debian--02-root /               ext3    errors=3Dremount-ro
0       1
# /boot was on /dev/sda1 during installation
UUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec /boot           ext3
defaults        0       2
/dev/mapper/debian--02-swap_1 none            swap    sw
0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
none /proc/xen xenfs defaults 0 0

--e89a8ff1c4a89b34b104be496c7d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi guys,<br><br>It&#39;s my first time here and in a mailing lists, I only =
participated in forums before. Please, If I make a mistake you should advis=
e me. Let&#39;s go!<br><br>I was reading &quot;xencommons not start&quot; i=
n a Remus Forum in order to install Remus.<br>
Well=85 I followed the tutorial &lt;<a href=3D"http://remusha.wikidot.com/c=
onfiguring-and-installing-remus">http://remusha.wikidot.com/configuring-and=
-installing-remus</a>&gt;, I reboot in xen_unstable and I had a error messa=
ge:<br>
<br>error: couldn&#39;t open file<br>error: you need to load the multiboot =
kernel first<br><br>then I redid tutorial after &quot;Adapt Grub&quot; and =
in a moment I do command:<br><br># /etc/init.d/xend start<br>xencommons sho=
uld be started first.<br>
<br>but I had done &quot;/etc/init.d/xencommons start&quot; before and no e=
rror message returned !!!???<br><br>
I also tried insert modules manually (coz in other mailing list said to put=
 some modules - see my setups after this mail) but I had:<br>
<br>
# modprobe xen-evtchn<br>
FATAL: Module xen_evtchn not found.<br>
<br>
Please, help me<br>
Thanks.<br>
<br>
PS: I&#39;m sorry to my English, coz I&#39;m brazilian.<br>
<br>My setups are:<br><br>- fdisk<br><br>=A0=A0 Device Boot=A0=A0=A0=A0=A0 =
Start=A0=A0=A0=A0=A0=A0=A0=A0 End=A0=A0=A0=A0=A0 Blocks=A0=A0 Id=A0 System<=
br>/dev/sda1=A0=A0 *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 32=A0=A0=A0=A0=A0 248832=A0=A0 83=A0 Linux<br>Partition 1 does not e=
nd on cylinder boundary.<br>
/dev/sda2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 32=A0=A0=A0=A0=A0=A0 30395=
=A0=A0 243889153=A0=A0=A0 5=A0 Extended<br>/dev/sda5=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 32=A0=A0=A0=A0=A0=A0 30395=A0=A0 243889152=A0=A0 8e=A0 L=
inux LVM<br><br>- blkid<br><br>root@debian-02:/home/franca# blkid<br>/dev/s=
da5: UUID=3D&quot;RVwX4M-56HI-Tu9q-CLkP-V0jx-Ft7W-b0bPHP&quot; TYPE=3D&quot=
;LVM2_member&quot; <br>
/dev/sda1: UUID=3D&quot;fcc01979-0cf3-4dbe-863a-ab32d2636fec&quot; TYPE=3D&=
quot;ext3&quot; <br>/dev/mapper/debian--02-root: UUID=3D&quot;da8b402b-b224=
-4552-80df-754339518e4d&quot; TYPE=3D&quot;ext3&quot; <br>/dev/mapper/debia=
n--02-swap_1: UUID=3D&quot;d5eb1ff7-b7d8-4b60-95e3-f4bb5ae32932&quot; TYPE=
=3D&quot;swap&quot;<br>
<br>My scripts are:<br><br>- 08_xen<br><br>#!/bin/sh<br>exec tail -n +3 $0<=
br>menuentry &quot;Xen Unstable / Debian Squeeze kernel 2.6.32.40&quot; {<b=
r>### MY ATTEMPT<br>=A0=A0=A0 insmod ext2<br>=A0=A0=A0=A0=A0=A0=A0 set root=
=3D&#39;(hd0,msdos1)&#39;<br>
=A0=A0=A0=A0=A0=A0=A0 multiboot (hd0,msdos1)/boot/xen-4.2-unstable.gz dummy=
 dom0_mem=3D512M<br>=A0=A0=A0=A0=A0=A0=A0 module (hd0,msdos1)/boot/vmlinuz-=
2.6.32.40 dummy root=3DUUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec ro quiet=
 console=3Dtty0 nomodeset<br>=A0=A0=A0=A0=A0=A0=A0 module (hd0,msdos1)/boot=
/initrd.img-2.6.32.40<br>
<br>### MODEL Configuring and Installing Remus<br>=A0=A0=A0=A0=A0=A0=A0 #in=
smod ext2<br>=A0=A0=A0=A0=A0=A0=A0 #set root=3D&#39;(hd0,1)&#39;<br>=A0=A0=
=A0=A0=A0=A0=A0 #multiboot (hd0,1)/boot/xen-4.2-unstable.gz dummy dom0_mem=
=3D512M<br>=A0=A0=A0=A0=A0=A0=A0 #module (hd0,1)/boot/vmlinuz-2.6.32.40 dum=
my root=3DUUID=3D8e339522-dab5-4a81-8066-c41cc3908a15 ro quiet console=3Dtt=
y0 nomodeset<br>
=A0=A0=A0=A0=A0=A0=A0 #module (hd0,1)/boot/initrd.img-2.6.32.40<br><br>### =
MODEL UBUNTU FORUM<br>=A0=A0=A0 #insmod part_msdos<br>=A0=A0=A0 #insmod ext=
2<br>=A0=A0=A0=A0=A0=A0=A0 #set root=3D(hd0,msdos1)<br>=A0=A0=A0 #search --=
no-floppy --fs-uuid --set fcc01979-0cf3-4dbe-863a-ab32d2636fec<br>
=A0=A0=A0=A0=A0=A0=A0 #multiboot /boot/xen-4.2-unstable.gz<br>=A0=A0=A0=A0=
=A0=A0=A0 #module /boot/vmlinuz-2.6.32.40 root=3D/dev/sda1<br>=A0=A0=A0=A0=
=A0=A0=A0 #module /boot/initrd.img-2.6.32.40<br>}<br><br>- modules<br><br>#=
 /etc/modules: kernel modules to load at boot time.<br>
#<br># This file contains the names of kernel modules that should be loaded=
<br># at boot time, one per line. Lines beginning with &quot;#&quot; are ig=
nored.<br># Parameters can be specified after the module name.<br><br>loop<=
br>
xen-evtchn<br>xen-gntdev<br>xen-netback<br>xen-blkback<br>xenfs<br>blktap2<=
br><br>- fstab<br><br># /etc/fstab: static file system information.<br>#<br=
># Use &#39;blkid&#39; to print the universally unique identifier for a<br>
# device; this may be used with UUID=3D as a more robust way to name device=
s<br># that works even if disks are added and removed. See fstab(5).<br>#<b=
r># &lt;file system&gt; &lt;mount point&gt;=A0=A0 &lt;type&gt;=A0 &lt;optio=
ns&gt;=A0=A0=A0=A0=A0=A0 &lt;dump&gt;=A0 &lt;pass&gt;<br>
proc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /proc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 p=
roc=A0=A0=A0 defaults=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 0<br>/dev/ma=
pper/debian--02-root /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ext3=A0=A0=
=A0 errors=3Dremount-ro 0=A0=A0=A0=A0=A0=A0 1<br># /boot was on /dev/sda1 d=
uring installation<br>UUID=3Dfcc01979-0cf3-4dbe-863a-ab32d2636fec /boot=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ext3=A0=A0=A0 defaults=A0=A0=A0=A0=A0=A0=A0 0=
=A0=A0=A0=A0=A0=A0 2<br>
/dev/mapper/debian--02-swap_1 none=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 swap=A0=
=A0=A0 sw=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 0<br>/=
dev/scd0=A0=A0=A0=A0=A0=A0 /media/cdrom0=A0=A0 udf,iso9660 user,noauto=A0=
=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 0<br>none /proc/xen xenfs defaults 0 0<br>

--e89a8ff1c4a89b34b104be496c7d--


--===============3903910243817190300==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3903910243817190300==--


From xen-devel-bounces@lists.xen.org Sun Apr 22 21:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 21:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM4Ka-0004oP-8L; Sun, 22 Apr 2012 21:28:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SM4KY-0004oK-3D
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 21:28:26 +0000
Received: from [193.109.254.147:62102] by server-4.bemta-14.messagelabs.com id
	29/3C-11570-9F7749F4; Sun, 22 Apr 2012 21:28:25 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335130104!5770664!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gNDQwODI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10463 invoked from network); 22 Apr 2012 21:28:24 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196) by server-14.tower-27.messagelabs.com with SMTP;
	22 Apr 2012 21:28:24 -0000
X-Originating-IP: 217.70.178.147
Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 0FB591720D0
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 23:28:24 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter19-d.gandi.net (mfilter19-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id D+sazWIPfwxw for <xen-devel@lists.xen.org>;
	Sun, 22 Apr 2012 23:28:22 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 961DC1720EC
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 23:28:20 +0200 (CEST)
Message-ID: <4F9477F6.3060005@de-bruyn.fr>
Date: Sun, 22 Apr 2012 23:28:22 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
	<CACC+8CRjXooy_ga8FGu+-EvajSY1ng7P3or4_JhJpLOjhGS3sw@mail.gmail.com>
In-Reply-To: <CACC+8CRjXooy_ga8FGu+-EvajSY1ng7P3or4_JhJpLOjhGS3sw@mail.gmail.com>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

V29ya3MgZm9yIG1lIGFzIHdlbGwgOikgVGhhbmtzICEKCk9uIDIyLjA0LjIwMTIgMTk6MjksIEty
aXN0aWphbiBMZcSNbmlrIHdyb3RlOgo+IEhpLAo+IAo+IHdvcmtzLCB0aGFuayB5b3UhCj4gCj4g
QmVzdCBSZWdhcmRzLAo+IEtyaXN0aWphbiBMZWNuaWsKPiAKPiBPbiBTdW4sIEFwciAyMiwgMjAx
MiBhdCA3OjI5IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tCj4gPG1h
aWx0bzpJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4+IHdyb3RlOgo+IAo+ICAgICBTaG91bGQgYmUg
Zml4ZWQgbm93LiBTb3JyeSBmb3IgdGhlIGluY29udmVuaWVuY2UuIAo+IAo+ICAgICBLcmlzdGlq
YW4gTGXEjW5payA8amFuZXoza0BnbWFpbC5jb20gPG1haWx0bzpqYW5lejNrQGdtYWlsLmNvbT4+
IHdyb3RlOgo+IAo+IAo+ICAgICBIaSwKPiAKPiAgICAgc3RpbGwgY2FudCBjb25uZWN0Ogo+IAo+
ICAgICArIC9yb290L3hlbi11bnN0YWJsZS5oZy1yZXYvdG9vbHMvLi4vc2NyaXB0cy9naXQtY2hl
Y2tvdXQuc2gKPiAgICAgZ2l0Oi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3FlbXUteGVuLXVuc3Rh
YmxlLmdpdAo+ICAgICA8aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0
YWJsZS5naXQ+Cj4gICAgIDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkg
cWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyCj4gICAgIENsb25pbmcgaW50byBxZW11LXhlbi10cmFk
aXRpb25hbC1kaXItcmVtb3RlLnRtcC4uLgo+ICAgICB4ZW5iaXRzLnhlbnNvdXJjZS5jb20gPGh0
dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20+WzA6Cj4gICAgIDUwLjU3LjE3MC4yNDJdOiBlcnJu
bz1Db25uZWN0aW9uIHJlZnVzZWQKPiAgICAgZmF0YWw6IHVuYWJsZSB0byBjb25uZWN0IGEgc29j
a2V0IChDb25uZWN0aW9uIHJlZnVzZWQpCj4gICAgIG1ha2VbMV06ICoqKiBbcWVtdS14ZW4tdHJh
ZGl0aW9uYWwtZGlyLWZpbmRdIEVycm9yIDEyOAo+IAo+ICAgICBpIGFtIHNvcnJ5IHRvIGNvbXBs
YWluLCBkb24ndCBoYXZlIHRoZSB0aW1lIHRvIHBsYXkgd2l0aCB4ZW4gb3RoZXIKPiAgICAgdGhl
biBvbiB3ZWVrZW5kIDopCj4gCj4gICAgIEJlc3QgUmVnYXJkcywKPiAgICAgS3Jpc3RpamFuIExl
Y25pawo+IAo+ICAgICBPbiBTdW4sIEFwciAyMiwgMjAxMiBhdCA2OjI2IFBNLCBJYW4gQ2FtcGJl
bGwKPiAgICAgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tIDxtYWlsdG86SWFuLkNhbXBiZWxsQGNp
dHJpeC5jb20+PiB3cm90ZToKPiAKPiAgICAgICAgIE9uIFN1biwgMjAxMi0wNC0yMiBhdCAxMToy
MyAtMDQwMCwgS3Jpc3RpamFuIExlxI1uaWsgd3JvdGU6Cj4gICAgICAgICA+IEhpLAo+ICAgICAg
ICAgPgo+ICAgICAgICAgPgo+ICAgICAgICAgPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBw
cm9ibGVtczoKPiAgICAgICAgID4KPiAgICAgICAgID4KPiAgICAgICAgID4gKyAvcm9vdC94ZW4t
dW5zdGFibGUuaGctcmV2L3Rvb2xzLy4uL3NjcmlwdHMvZ2l0LWNoZWNrb3V0LnNoCj4gICAgICAg
ICA+IGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0YWJsZS5naXQKPiAg
ICAgICAgIDxodHRwOi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3FlbXUteGVuLXVuc3RhYmxlLmdp
dD4KPiAgICAgICAgID4gODJkYjhkZTE2NTMwZjAxNjgwOTI2NGQzMTc5ODIzOTk5ZDcwMjg0OSBx
ZW11LXhlbi10cmFkaXRpb25hbC1kaXIKPiAgICAgICAgID4gQ2xvbmluZyBpbnRvIHFlbXUteGVu
LXRyYWRpdGlvbmFsLWRpci1yZW1vdGUudG1wLi4uCj4gICAgICAgICA+IGZhdGFsOiByZWFkIGVy
cm9yOiBDb25uZWN0aW9uIHJlc2V0IGJ5IHBlZXIKPiAgICAgICAgID4KPiAgICAgICAgID4KPiAg
ICAgICAgID4gZ2l0IGRvd24/Cj4gCj4gICAgICAgICBXZSBoYXZlIG9jY2FzaW9uYWwgcHJvYmxl
bXMgd2l0aCBzdHVjayBnaXQgZGFlbW9uIHByb2Nlc3NlcyBhbGwKPiAgICAgICAgIGNvbWluZwo+
ICAgICAgICAgZm9ybSB0aGUgc2FtZSBJUCBhZGRyZXNzLCB3aGljaCBldmVudHVhbGx5IHVzZSB1
cCB0aGUgcXVvdGEgb2YgY2hpbGQKPiAgICAgICAgIHByb2Nlc3Nlcy4gSXQgc2VlbXMgdGhhdCB3
ZSBoYXZlIGEgbmV3IHByb2JsZW1hdGljIElQIGFkZHJlc3MuCj4gCj4gICAgICAgICBJJ3ZlIGp1
c3Qga2lsbGVkIGEgY291cGxlIG9mIGRvemVuIGdpdCBwcm9jZXNzZXMgd2hpY2ggaGFkIGJlZW4K
PiAgICAgICAgIHJ1bm5pbmcKPiAgICAgICAgIGZvciBzZXZlcmFsIHdlZWtzLCB0aGluZ3Mgc2hv
dWxkIGJlIGJhY2sgdG8gbm9ybWFsLgo+IAo+ICAgICAgICAgSWFuLgo+IAo+IAo+IAo+IAo+IAo+
IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVu
LWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCgotLSAKLS0KQWxleGlzIGRlIEJSVVlOCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Sun Apr 22 21:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Apr 2012 21:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM4Ka-0004oP-8L; Sun, 22 Apr 2012 21:28:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SM4KY-0004oK-3D
	for xen-devel@lists.xen.org; Sun, 22 Apr 2012 21:28:26 +0000
Received: from [193.109.254.147:62102] by server-4.bemta-14.messagelabs.com id
	29/3C-11570-9F7749F4; Sun, 22 Apr 2012 21:28:25 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335130104!5770664!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gNDQwODI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10463 invoked from network); 22 Apr 2012 21:28:24 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196) by server-14.tower-27.messagelabs.com with SMTP;
	22 Apr 2012 21:28:24 -0000
X-Originating-IP: 217.70.178.147
Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 0FB591720D0
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 23:28:24 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter19-d.gandi.net (mfilter19-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id D+sazWIPfwxw for <xen-devel@lists.xen.org>;
	Sun, 22 Apr 2012 23:28:22 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 961DC1720EC
	for <xen-devel@lists.xen.org>; Sun, 22 Apr 2012 23:28:20 +0200 (CEST)
Message-ID: <4F9477F6.3060005@de-bruyn.fr>
Date: Sun, 22 Apr 2012 23:28:22 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <kf3wo7nppdbvvcct1ropt4rp.1335115737756@email.android.com>
	<CACC+8CRjXooy_ga8FGu+-EvajSY1ng7P3or4_JhJpLOjhGS3sw@mail.gmail.com>
In-Reply-To: <CACC+8CRjXooy_ga8FGu+-EvajSY1ng7P3or4_JhJpLOjhGS3sw@mail.gmail.com>
Subject: Re: [Xen-devel] git down?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

V29ya3MgZm9yIG1lIGFzIHdlbGwgOikgVGhhbmtzICEKCk9uIDIyLjA0LjIwMTIgMTk6MjksIEty
aXN0aWphbiBMZcSNbmlrIHdyb3RlOgo+IEhpLAo+IAo+IHdvcmtzLCB0aGFuayB5b3UhCj4gCj4g
QmVzdCBSZWdhcmRzLAo+IEtyaXN0aWphbiBMZWNuaWsKPiAKPiBPbiBTdW4sIEFwciAyMiwgMjAx
MiBhdCA3OjI5IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tCj4gPG1h
aWx0bzpJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4+IHdyb3RlOgo+IAo+ICAgICBTaG91bGQgYmUg
Zml4ZWQgbm93LiBTb3JyeSBmb3IgdGhlIGluY29udmVuaWVuY2UuIAo+IAo+ICAgICBLcmlzdGlq
YW4gTGXEjW5payA8amFuZXoza0BnbWFpbC5jb20gPG1haWx0bzpqYW5lejNrQGdtYWlsLmNvbT4+
IHdyb3RlOgo+IAo+IAo+ICAgICBIaSwKPiAKPiAgICAgc3RpbGwgY2FudCBjb25uZWN0Ogo+IAo+
ICAgICArIC9yb290L3hlbi11bnN0YWJsZS5oZy1yZXYvdG9vbHMvLi4vc2NyaXB0cy9naXQtY2hl
Y2tvdXQuc2gKPiAgICAgZ2l0Oi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3FlbXUteGVuLXVuc3Rh
YmxlLmdpdAo+ICAgICA8aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0
YWJsZS5naXQ+Cj4gICAgIDgyZGI4ZGUxNjUzMGYwMTY4MDkyNjRkMzE3OTgyMzk5OWQ3MDI4NDkg
cWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyCj4gICAgIENsb25pbmcgaW50byBxZW11LXhlbi10cmFk
aXRpb25hbC1kaXItcmVtb3RlLnRtcC4uLgo+ICAgICB4ZW5iaXRzLnhlbnNvdXJjZS5jb20gPGh0
dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20+WzA6Cj4gICAgIDUwLjU3LjE3MC4yNDJdOiBlcnJu
bz1Db25uZWN0aW9uIHJlZnVzZWQKPiAgICAgZmF0YWw6IHVuYWJsZSB0byBjb25uZWN0IGEgc29j
a2V0IChDb25uZWN0aW9uIHJlZnVzZWQpCj4gICAgIG1ha2VbMV06ICoqKiBbcWVtdS14ZW4tdHJh
ZGl0aW9uYWwtZGlyLWZpbmRdIEVycm9yIDEyOAo+IAo+ICAgICBpIGFtIHNvcnJ5IHRvIGNvbXBs
YWluLCBkb24ndCBoYXZlIHRoZSB0aW1lIHRvIHBsYXkgd2l0aCB4ZW4gb3RoZXIKPiAgICAgdGhl
biBvbiB3ZWVrZW5kIDopCj4gCj4gICAgIEJlc3QgUmVnYXJkcywKPiAgICAgS3Jpc3RpamFuIExl
Y25pawo+IAo+ICAgICBPbiBTdW4sIEFwciAyMiwgMjAxMiBhdCA2OjI2IFBNLCBJYW4gQ2FtcGJl
bGwKPiAgICAgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tIDxtYWlsdG86SWFuLkNhbXBiZWxsQGNp
dHJpeC5jb20+PiB3cm90ZToKPiAKPiAgICAgICAgIE9uIFN1biwgMjAxMi0wNC0yMiBhdCAxMToy
MyAtMDQwMCwgS3Jpc3RpamFuIExlxI1uaWsgd3JvdGU6Cj4gICAgICAgICA+IEhpLAo+ICAgICAg
ICAgPgo+ICAgICAgICAgPgo+ICAgICAgICAgPiB0cnlpbmcgdG8gY29tcGlsZSBidXQgaGF2ZSBw
cm9ibGVtczoKPiAgICAgICAgID4KPiAgICAgICAgID4KPiAgICAgICAgID4gKyAvcm9vdC94ZW4t
dW5zdGFibGUuaGctcmV2L3Rvb2xzLy4uL3NjcmlwdHMvZ2l0LWNoZWNrb3V0LnNoCj4gICAgICAg
ICA+IGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0YWJsZS5naXQKPiAg
ICAgICAgIDxodHRwOi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3FlbXUteGVuLXVuc3RhYmxlLmdp
dD4KPiAgICAgICAgID4gODJkYjhkZTE2NTMwZjAxNjgwOTI2NGQzMTc5ODIzOTk5ZDcwMjg0OSBx
ZW11LXhlbi10cmFkaXRpb25hbC1kaXIKPiAgICAgICAgID4gQ2xvbmluZyBpbnRvIHFlbXUteGVu
LXRyYWRpdGlvbmFsLWRpci1yZW1vdGUudG1wLi4uCj4gICAgICAgICA+IGZhdGFsOiByZWFkIGVy
cm9yOiBDb25uZWN0aW9uIHJlc2V0IGJ5IHBlZXIKPiAgICAgICAgID4KPiAgICAgICAgID4KPiAg
ICAgICAgID4gZ2l0IGRvd24/Cj4gCj4gICAgICAgICBXZSBoYXZlIG9jY2FzaW9uYWwgcHJvYmxl
bXMgd2l0aCBzdHVjayBnaXQgZGFlbW9uIHByb2Nlc3NlcyBhbGwKPiAgICAgICAgIGNvbWluZwo+
ICAgICAgICAgZm9ybSB0aGUgc2FtZSBJUCBhZGRyZXNzLCB3aGljaCBldmVudHVhbGx5IHVzZSB1
cCB0aGUgcXVvdGEgb2YgY2hpbGQKPiAgICAgICAgIHByb2Nlc3Nlcy4gSXQgc2VlbXMgdGhhdCB3
ZSBoYXZlIGEgbmV3IHByb2JsZW1hdGljIElQIGFkZHJlc3MuCj4gCj4gICAgICAgICBJJ3ZlIGp1
c3Qga2lsbGVkIGEgY291cGxlIG9mIGRvemVuIGdpdCBwcm9jZXNzZXMgd2hpY2ggaGFkIGJlZW4K
PiAgICAgICAgIHJ1bm5pbmcKPiAgICAgICAgIGZvciBzZXZlcmFsIHdlZWtzLCB0aGluZ3Mgc2hv
dWxkIGJlIGJhY2sgdG8gbm9ybWFsLgo+IAo+ICAgICAgICAgSWFuLgo+IAo+IAo+IAo+IAo+IAo+
IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVu
LWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCgotLSAKLS0KQWxleGlzIGRlIEJSVVlOCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Mon Apr 23 02:24:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 02:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM8we-0002Ex-AF; Mon, 23 Apr 2012 02:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SM8wd-0002Es-9K
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 02:24:03 +0000
Received: from [85.158.143.35:58769] by server-1.bemta-4.messagelabs.com id
	B0/D2-20925-24DB49F4; Mon, 23 Apr 2012 02:24:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335147840!17292258!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUwODYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17563 invoked from network); 23 Apr 2012 02:24:01 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 02:24:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3N2NY1w003431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 02:23:35 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3N2NWWl002225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 02:23:33 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3N2NVp1020087; Sun, 22 Apr 2012 21:23:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 22 Apr 2012 19:23:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 601A24032D; Sun, 22 Apr 2012 22:18:27 -0400 (EDT)
Date: Sun, 22 Apr 2012 22:18:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120423021827.GA13840@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120421104502.GB17005@aftab.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > This patch gets error information from xen hypervisor and convert
> > > xen format error into linux format mcelog. This logic is basically
> > > self-contained, not much touching other kernel components.
> 
> I have a problem with that statement above. This thing uses struct mce
> and mce_log(), which are internal to x86, and whenever we want to change
> anything there, we won't be able to because xen uses it too.

Huh? You mean this:

       m.misc = mc_bank->mc_misc;
       m.status = mc_bank->mc_status;
       m.addr = mc_bank->mc_addr;
       m.tsc = mc_bank->mc_tsc;
       m.bank = mc_bank->mc_bank;
       m.finished = 1;
       /*log this record*/
       mce_log(&m);

?

This driver is not that much different from the APEI bridge to MCE code -
it just that instead of reading APEI blob data it reads it from an hypercall.

Taking this a step forward, If you change the 'mce_log' or the 'struct mce'
won't you have a problem with the APEI one b/c it uses it too?

The fix seems quite easy - you change the 'struct mce' and 'mce_log()'
along with the drivers that use it.

If you are worried about breaking something, then you can just send
the change to me or Liu to test it out before committing API changes
in the MCE code.


> 
> And this has happened already with the whole microcode loading debacle.

My recollection is that the existing microcode API had major issues that
could not fixed. The only fix was to make it be very early in the bootup
processes and that is what hpa would like developers to focus on.

> 
> So, my suggestion is to copy the pieces you need and create your own xen
> version of /dev/mcelog and add it to dom0 so that there's no hooking
> into baremetal code and whenever a dom0 kernel is running, you can
> reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
> and not hook into the x86 versions.
> 
> Because, if you'd hooked into it, just imagine one fine day, when we
> remove mcelog support, what screaming the xen people will be doing when
> mcelog doesn't work anymore.

You would have more screaming from the distro camp about removing
/dev/mcelog. But if that is your choice, I would send you an email
asking how I need to retool this driver to work with the new MCE gen2
code that you had in mind.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 02:24:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 02:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM8we-0002Ex-AF; Mon, 23 Apr 2012 02:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SM8wd-0002Es-9K
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 02:24:03 +0000
Received: from [85.158.143.35:58769] by server-1.bemta-4.messagelabs.com id
	B0/D2-20925-24DB49F4; Mon, 23 Apr 2012 02:24:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335147840!17292258!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUwODYw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17563 invoked from network); 23 Apr 2012 02:24:01 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 02:24:01 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3N2NY1w003431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 02:23:35 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3N2NWWl002225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 02:23:33 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3N2NVp1020087; Sun, 22 Apr 2012 21:23:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 22 Apr 2012 19:23:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 601A24032D; Sun, 22 Apr 2012 22:18:27 -0400 (EDT)
Date: Sun, 22 Apr 2012 22:18:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120423021827.GA13840@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120421104502.GB17005@aftab.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > This patch gets error information from xen hypervisor and convert
> > > xen format error into linux format mcelog. This logic is basically
> > > self-contained, not much touching other kernel components.
> 
> I have a problem with that statement above. This thing uses struct mce
> and mce_log(), which are internal to x86, and whenever we want to change
> anything there, we won't be able to because xen uses it too.

Huh? You mean this:

       m.misc = mc_bank->mc_misc;
       m.status = mc_bank->mc_status;
       m.addr = mc_bank->mc_addr;
       m.tsc = mc_bank->mc_tsc;
       m.bank = mc_bank->mc_bank;
       m.finished = 1;
       /*log this record*/
       mce_log(&m);

?

This driver is not that much different from the APEI bridge to MCE code -
it just that instead of reading APEI blob data it reads it from an hypercall.

Taking this a step forward, If you change the 'mce_log' or the 'struct mce'
won't you have a problem with the APEI one b/c it uses it too?

The fix seems quite easy - you change the 'struct mce' and 'mce_log()'
along with the drivers that use it.

If you are worried about breaking something, then you can just send
the change to me or Liu to test it out before committing API changes
in the MCE code.


> 
> And this has happened already with the whole microcode loading debacle.

My recollection is that the existing microcode API had major issues that
could not fixed. The only fix was to make it be very early in the bootup
processes and that is what hpa would like developers to focus on.

> 
> So, my suggestion is to copy the pieces you need and create your own xen
> version of /dev/mcelog and add it to dom0 so that there's no hooking
> into baremetal code and whenever a dom0 kernel is running, you can
> reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
> and not hook into the x86 versions.
> 
> Because, if you'd hooked into it, just imagine one fine day, when we
> remove mcelog support, what screaming the xen people will be doing when
> mcelog doesn't work anymore.

You would have more screaming from the distro camp about removing
/dev/mcelog. But if that is your choice, I would send you an email
asking how I need to retool this driver to work with the new MCE gen2
code that you had in mind.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 02:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 02:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM9Fa-0002Th-Ek; Mon, 23 Apr 2012 02:43:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SM9FZ-0002Tc-0g
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 02:43:37 +0000
Received: from [85.158.139.83:47163] by server-2.bemta-5.messagelabs.com id
	5C/25-17016-8D1C49F4; Mon, 23 Apr 2012 02:43:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335149013!17632831!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2MzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13792 invoked from network); 23 Apr 2012 02:43:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 02:43:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3N2hTRJ016280
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 02:43:31 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3N2hSFw018071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 02:43:28 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3N2hRJ8028720; Sun, 22 Apr 2012 21:43:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 22 Apr 2012 19:43:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C35284032D; Sun, 22 Apr 2012 22:38:23 -0400 (EDT)
Date: Sun, 22 Apr 2012 22:38:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Message-ID: <20120423023823.GC13840@phenom.dumpdata.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 03:25:04PM +0000, Hao, Xudong wrote:
> When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted.

Shouldn't they be reset when the device is de-assigned from the guest as well?
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
> index 19834d1..82aac5b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
>  	dev_dbg(&dev->dev, "reset device\n");
>  	xen_pcibk_reset_device(dev);
>  
> +	/* set default value */
> +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */


Please put them in the appropiate location - at the start of the 
function.

> +
> +	/* Enable LTR and OBFF before do device assignment */
> +	/* LTR(Latency tolerance reporting) allows devices to send messages to the
> +	 * root complex indicating their latency tolerance for snooped & unsnooped
> +	 * memory transactions. 
> +	 */
> +	pci_enable_ltr(dev);
> +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);

OK, but didn't you just come with up those values?

> +
> +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> +	 * energy efficiency by giving devices information about when interrupts and
> +	 * other activity will have a reduced power impact.
> +	 */
> +	pci_enable_obff(dev, type);
> +
>  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
>  	return 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 02:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 02:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM9Fa-0002Th-Ek; Mon, 23 Apr 2012 02:43:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SM9FZ-0002Tc-0g
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 02:43:37 +0000
Received: from [85.158.139.83:47163] by server-2.bemta-5.messagelabs.com id
	5C/25-17016-8D1C49F4; Mon, 23 Apr 2012 02:43:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335149013!17632831!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2MzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13792 invoked from network); 23 Apr 2012 02:43:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 02:43:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3N2hTRJ016280
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 02:43:31 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3N2hSFw018071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 02:43:28 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3N2hRJ8028720; Sun, 22 Apr 2012 21:43:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 22 Apr 2012 19:43:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C35284032D; Sun, 22 Apr 2012 22:38:23 -0400 (EDT)
Date: Sun, 22 Apr 2012 22:38:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Message-ID: <20120423023823.GC13840@phenom.dumpdata.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 03:25:04PM +0000, Hao, Xudong wrote:
> When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted.

Shouldn't they be reset when the device is de-assigned from the guest as well?
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
> index 19834d1..82aac5b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
>  	dev_dbg(&dev->dev, "reset device\n");
>  	xen_pcibk_reset_device(dev);
>  
> +	/* set default value */
> +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */


Please put them in the appropiate location - at the start of the 
function.

> +
> +	/* Enable LTR and OBFF before do device assignment */
> +	/* LTR(Latency tolerance reporting) allows devices to send messages to the
> +	 * root complex indicating their latency tolerance for snooped & unsnooped
> +	 * memory transactions. 
> +	 */
> +	pci_enable_ltr(dev);
> +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);

OK, but didn't you just come with up those values?

> +
> +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> +	 * energy efficiency by giving devices information about when interrupts and
> +	 * other activity will have a reduced power impact.
> +	 */
> +	pci_enable_obff(dev, type);
> +
>  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
>  	return 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 03:17:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 03:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM9lk-0003NC-PG; Mon, 23 Apr 2012 03:16:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SM9lj-0003N7-In
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 03:16:51 +0000
Received: from [85.158.143.99:19309] by server-1.bemta-4.messagelabs.com id
	D4/80-20925-2A9C49F4; Mon, 23 Apr 2012 03:16:50 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335151007!24725385!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY4OTgx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25468 invoked from network); 23 Apr 2012 03:16:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 03:16:49 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 22 Apr 2012 20:16:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134024141"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 22 Apr 2012 20:16:46 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 22 Apr 2012 20:16:46 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.5]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.213]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 11:16:41 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] Re-enable LTR/OBFF when device is owned by pciback
Thread-Index: AQHNIPsdcpLvNLd1TUqg+rjQm7tWB5ant7gg
Date: Mon, 23 Apr 2012 03:16:35 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD2FD51@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<20120423023823.GC13840@phenom.dumpdata.com>
In-Reply-To: <20120423023823.GC13840@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Monday, April 23, 2012 10:38 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [PATCH] Re-enable LTR/OBFF when device is owned by pciback
> 
> On Sun, Apr 22, 2012 at 03:25:04PM +0000, Hao, Xudong wrote:
> > When PCIE device which has LTR/OBFF capabilities is owned by pciback,
> LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that
> guest with device assigned can be benefitted.
> 
> Shouldn't they be reset when the device is de-assigned from the guest as well?

Yes, pci device will be reset when device is assigned to guest and de-assigned from guest. In pci_reset_function(), the ltr/obff is saved and restored, so nothing to consider the reset here. 
However, hiding device with pciback did not call reset function, and device is disabled, so we re-enable it here.

driver/pci/pci.c
    if (pcie_cap_has_devctl2(dev->pcie_type, flags))
        pci_read_config_word(dev, pos + PCI_EXP_DEVCTL2, &cap[i++]);


> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> >
> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
> > b/drivers/xen/xen-pciback/pci_stub.c
> > index 19834d1..82aac5b 100644
> > --- a/drivers/xen/xen-pciback/pci_stub.c
> > +++ b/drivers/xen/xen-pciback/pci_stub.c
> > @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
> >  	dev_dbg(&dev->dev, "reset device\n");
> >  	xen_pcibk_reset_device(dev);
> >
> > +	/* set default value */
> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
> > +value */
> 
> 
> Please put them in the appropiate location - at the start of the function.
> 

OK, I'll modify in next version.

> > +
> > +	/* Enable LTR and OBFF before do device assignment */
> > +	/* LTR(Latency tolerance reporting) allows devices to send messages to
> the
> > +	 * root complex indicating their latency tolerance for snooped &
> unsnooped
> > +	 * memory transactions.
> > +	 */
> > +	pci_enable_ltr(dev);
> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
> 
> OK, but didn't you just come with up those values?
> 

The value should be set by driver, but now seems no real device support these two feature, at least I don't know such a device, and no driver call ltr/obff function. 
I just set the max value as default here, any suggestion?

> > +
> > +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> > +	 * energy efficiency by giving devices information about when interrupts
> and
> > +	 * other activity will have a reduced power impact.
> > +	 */
> > +	pci_enable_obff(dev, type);
> > +
> >  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> >  	return 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 03:17:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 03:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SM9lk-0003NC-PG; Mon, 23 Apr 2012 03:16:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SM9lj-0003N7-In
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 03:16:51 +0000
Received: from [85.158.143.99:19309] by server-1.bemta-4.messagelabs.com id
	D4/80-20925-2A9C49F4; Mon, 23 Apr 2012 03:16:50 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335151007!24725385!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY4OTgx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25468 invoked from network); 23 Apr 2012 03:16:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 03:16:49 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 22 Apr 2012 20:16:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134024141"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 22 Apr 2012 20:16:46 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 22 Apr 2012 20:16:46 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.5]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.213]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 11:16:41 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] Re-enable LTR/OBFF when device is owned by pciback
Thread-Index: AQHNIPsdcpLvNLd1TUqg+rjQm7tWB5ant7gg
Date: Mon, 23 Apr 2012 03:16:35 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD2FD51@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<20120423023823.GC13840@phenom.dumpdata.com>
In-Reply-To: <20120423023823.GC13840@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Monday, April 23, 2012 10:38 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [PATCH] Re-enable LTR/OBFF when device is owned by pciback
> 
> On Sun, Apr 22, 2012 at 03:25:04PM +0000, Hao, Xudong wrote:
> > When PCIE device which has LTR/OBFF capabilities is owned by pciback,
> LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that
> guest with device assigned can be benefitted.
> 
> Shouldn't they be reset when the device is de-assigned from the guest as well?

Yes, pci device will be reset when device is assigned to guest and de-assigned from guest. In pci_reset_function(), the ltr/obff is saved and restored, so nothing to consider the reset here. 
However, hiding device with pciback did not call reset function, and device is disabled, so we re-enable it here.

driver/pci/pci.c
    if (pcie_cap_has_devctl2(dev->pcie_type, flags))
        pci_read_config_word(dev, pos + PCI_EXP_DEVCTL2, &cap[i++]);


> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> >
> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
> > b/drivers/xen/xen-pciback/pci_stub.c
> > index 19834d1..82aac5b 100644
> > --- a/drivers/xen/xen-pciback/pci_stub.c
> > +++ b/drivers/xen/xen-pciback/pci_stub.c
> > @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
> >  	dev_dbg(&dev->dev, "reset device\n");
> >  	xen_pcibk_reset_device(dev);
> >
> > +	/* set default value */
> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
> > +value */
> 
> 
> Please put them in the appropiate location - at the start of the function.
> 

OK, I'll modify in next version.

> > +
> > +	/* Enable LTR and OBFF before do device assignment */
> > +	/* LTR(Latency tolerance reporting) allows devices to send messages to
> the
> > +	 * root complex indicating their latency tolerance for snooped &
> unsnooped
> > +	 * memory transactions.
> > +	 */
> > +	pci_enable_ltr(dev);
> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
> 
> OK, but didn't you just come with up those values?
> 

The value should be set by driver, but now seems no real device support these two feature, at least I don't know such a device, and no driver call ltr/obff function. 
I just set the max value as default here, any suggestion?

> > +
> > +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> > +	 * energy efficiency by giving devices information about when interrupts
> and
> > +	 * other activity will have a reduced power impact.
> > +	 */
> > +	pci_enable_obff(dev, type);
> > +
> >  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> >  	return 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 06:05:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMCOP-0004Kj-IX; Mon, 23 Apr 2012 06:04:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMCON-0004Ke-GM
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 06:04:55 +0000
Received: from [85.158.139.83:41635] by server-4.bemta-5.messagelabs.com id
	3C/B3-10788-601F49F4; Mon, 23 Apr 2012 06:04:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335161092!13731965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15668 invoked from network); 23 Apr 2012 06:04:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 06:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12069211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 06:04:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 07:04:50 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMCOH-000602-SU;
	Mon, 23 Apr 2012 06:04:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMCOH-0008Ch-Oz;
	Mon, 23 Apr 2012 07:04:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12738-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Apr 2012 07:04:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12738: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12738 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12738/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12733

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  274e5accd62d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 06:05:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMCOP-0004Kj-IX; Mon, 23 Apr 2012 06:04:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMCON-0004Ke-GM
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 06:04:55 +0000
Received: from [85.158.139.83:41635] by server-4.bemta-5.messagelabs.com id
	3C/B3-10788-601F49F4; Mon, 23 Apr 2012 06:04:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335161092!13731965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15668 invoked from network); 23 Apr 2012 06:04:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 06:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12069211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 06:04:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 07:04:50 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMCOH-000602-SU;
	Mon, 23 Apr 2012 06:04:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMCOH-0008Ch-Oz;
	Mon, 23 Apr 2012 07:04:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12738-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Apr 2012 07:04:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12738: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12738 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12738/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12733

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  274e5accd62d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 06:12:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMCV2-0004Ul-EM; Mon, 23 Apr 2012 06:11:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SMCV0-0004Ue-R5
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 06:11:47 +0000
Received: from [85.158.143.99:64507] by server-2.bemta-4.messagelabs.com id
	86/9F-17550-2A2F49F4; Mon, 23 Apr 2012 06:11:46 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335161365!15022747!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26903 invoked from network); 23 Apr 2012 06:09:39 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-8.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 06:09:39 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 72B2FC0063B;
	Mon, 23 Apr 2012 08:09:24 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id WbdZfqR5MMYU; Mon, 23 Apr 2012 08:09:24 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Mon, 23 Apr 2012 08:09:24 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 0D7C449C2B0;
	Mon, 23 Apr 2012 07:09:24 +0100 (BST)
Date: Mon, 23 Apr 2012 08:09:21 +0200
From: Borislav Petkov <bp@amd64.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120423060921.GA29378@aftab.osrc.amd.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423021827.GA13840@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, tony.luck@intel.com,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 10:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > This patch gets error information from xen hypervisor and convert
> > > > xen format error into linux format mcelog. This logic is basically
> > > > self-contained, not much touching other kernel components.
> > 
> > I have a problem with that statement above. This thing uses struct mce
> > and mce_log(), which are internal to x86, and whenever we want to change
> > anything there, we won't be able to because xen uses it too.
> 
> Huh? You mean this:
> 
>        m.misc = mc_bank->mc_misc;
>        m.status = mc_bank->mc_status;
>        m.addr = mc_bank->mc_addr;
>        m.tsc = mc_bank->mc_tsc;
>        m.bank = mc_bank->mc_bank;
>        m.finished = 1;
>        /*log this record*/
>        mce_log(&m);
> 
> ?
> 
> This driver is not that much different from the APEI bridge to MCE code -
> it just that instead of reading APEI blob data it reads it from an hypercall.

Let me ask you this: is APEI a virtualization solution of some sort?

No, it is the old windoze RAS crap but I guess Linux has to support it
now too through BIOS. And x86 vendors will have to support it too.

So it is piece of the firmware we'd have to deal with too.

Now xen is a whole another deal - it is purely a piece of software.

> The fix seems quite easy - you change the 'struct mce' and 'mce_log()'
> along with the drivers that use it.

This is exactly what I have a problem with: having to take care of xen
too. "No, Boris, nope, we cannot take your new feature because it breaks
xen." and also "Have you tested this on xen too?" where the only thing I
do is _hardware_ enablement and improving software support for it. And
xen is not hardware...

[..]

> If you are worried about breaking something, then you can just send
> the change to me or Liu to test it out before committing API changes
> in the MCE code.

This probably sounds good now but I don't think code changes like
that ever run as smoothly. Whenever there's breakage, there'll always
be people screaming against it - I just don't want code that enables
hardware to be crippled and unable to change because it breaks
completely unrelated pieces - it is bad as it is now.

> > And this has happened already with the whole microcode loading debacle.
> 
> My recollection is that the existing microcode API had major issues that
> could not fixed. The only fix was to make it be very early in the bootup
> processes and that is what hpa would like developers to focus on.

That was one side of the problem. The other was, AFAICR, creating a xen
microcode driver which was "on the same level" as the hardware microcode
drivers, which was completely bull*.

The problem is xen growing stuff everywhere in arch/x86/ and this way,
maybe even unwillingly, crippling development of hardware-related
features. I know you're willing to help and I know you mean it well, but
there's always some other problem in practice.

Now I keep wondering, why don't you guys simply create your own mcelog
ring buffer and interface on the userspace tool side instead of hooking
into lowlevel kernel stuff? I mean, the code is there, you simply have
to copy it into arch/xen/ or whatever you have there. Why do you have to
hook into arch/x86/ instead of doing your own stuff?

> > So, my suggestion is to copy the pieces you need and create your own xen
> > version of /dev/mcelog and add it to dom0 so that there's no hooking
> > into baremetal code and whenever a dom0 kernel is running, you can
> > reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
> > and not hook into the x86 versions.
> > 
> > Because, if you'd hooked into it, just imagine one fine day, when we
> > remove mcelog support, what screaming the xen people will be doing when
> > mcelog doesn't work anymore.
> 
> You would have more screaming from the distro camp about removing
> /dev/mcelog.

How do you know that? Don't you think that we probably would've talked
to them already and made preparations for conversion first?

> But if that is your choice, I would send you an email asking how I
> need to retool this driver to work with the new MCE gen2 code that you
> had in mind.

As I said above, I'm very sceptical this will ever work, I guess I'd
have to live and see.

Now, with your own buffer solution, nothing breaks and all is happy,
a win-win, if you wish. I think this is much simpler and easier a
solution.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 06:12:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMCV2-0004Ul-EM; Mon, 23 Apr 2012 06:11:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SMCV0-0004Ue-R5
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 06:11:47 +0000
Received: from [85.158.143.99:64507] by server-2.bemta-4.messagelabs.com id
	86/9F-17550-2A2F49F4; Mon, 23 Apr 2012 06:11:46 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335161365!15022747!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26903 invoked from network); 23 Apr 2012 06:09:39 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-8.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 06:09:39 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 72B2FC0063B;
	Mon, 23 Apr 2012 08:09:24 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id WbdZfqR5MMYU; Mon, 23 Apr 2012 08:09:24 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Mon, 23 Apr 2012 08:09:24 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 0D7C449C2B0;
	Mon, 23 Apr 2012 07:09:24 +0100 (BST)
Date: Mon, 23 Apr 2012 08:09:21 +0200
From: Borislav Petkov <bp@amd64.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120423060921.GA29378@aftab.osrc.amd.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423021827.GA13840@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, tony.luck@intel.com,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 10:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > This patch gets error information from xen hypervisor and convert
> > > > xen format error into linux format mcelog. This logic is basically
> > > > self-contained, not much touching other kernel components.
> > 
> > I have a problem with that statement above. This thing uses struct mce
> > and mce_log(), which are internal to x86, and whenever we want to change
> > anything there, we won't be able to because xen uses it too.
> 
> Huh? You mean this:
> 
>        m.misc = mc_bank->mc_misc;
>        m.status = mc_bank->mc_status;
>        m.addr = mc_bank->mc_addr;
>        m.tsc = mc_bank->mc_tsc;
>        m.bank = mc_bank->mc_bank;
>        m.finished = 1;
>        /*log this record*/
>        mce_log(&m);
> 
> ?
> 
> This driver is not that much different from the APEI bridge to MCE code -
> it just that instead of reading APEI blob data it reads it from an hypercall.

Let me ask you this: is APEI a virtualization solution of some sort?

No, it is the old windoze RAS crap but I guess Linux has to support it
now too through BIOS. And x86 vendors will have to support it too.

So it is piece of the firmware we'd have to deal with too.

Now xen is a whole another deal - it is purely a piece of software.

> The fix seems quite easy - you change the 'struct mce' and 'mce_log()'
> along with the drivers that use it.

This is exactly what I have a problem with: having to take care of xen
too. "No, Boris, nope, we cannot take your new feature because it breaks
xen." and also "Have you tested this on xen too?" where the only thing I
do is _hardware_ enablement and improving software support for it. And
xen is not hardware...

[..]

> If you are worried about breaking something, then you can just send
> the change to me or Liu to test it out before committing API changes
> in the MCE code.

This probably sounds good now but I don't think code changes like
that ever run as smoothly. Whenever there's breakage, there'll always
be people screaming against it - I just don't want code that enables
hardware to be crippled and unable to change because it breaks
completely unrelated pieces - it is bad as it is now.

> > And this has happened already with the whole microcode loading debacle.
> 
> My recollection is that the existing microcode API had major issues that
> could not fixed. The only fix was to make it be very early in the bootup
> processes and that is what hpa would like developers to focus on.

That was one side of the problem. The other was, AFAICR, creating a xen
microcode driver which was "on the same level" as the hardware microcode
drivers, which was completely bull*.

The problem is xen growing stuff everywhere in arch/x86/ and this way,
maybe even unwillingly, crippling development of hardware-related
features. I know you're willing to help and I know you mean it well, but
there's always some other problem in practice.

Now I keep wondering, why don't you guys simply create your own mcelog
ring buffer and interface on the userspace tool side instead of hooking
into lowlevel kernel stuff? I mean, the code is there, you simply have
to copy it into arch/xen/ or whatever you have there. Why do you have to
hook into arch/x86/ instead of doing your own stuff?

> > So, my suggestion is to copy the pieces you need and create your own xen
> > version of /dev/mcelog and add it to dom0 so that there's no hooking
> > into baremetal code and whenever a dom0 kernel is running, you can
> > reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
> > and not hook into the x86 versions.
> > 
> > Because, if you'd hooked into it, just imagine one fine day, when we
> > remove mcelog support, what screaming the xen people will be doing when
> > mcelog doesn't work anymore.
> 
> You would have more screaming from the distro camp about removing
> /dev/mcelog.

How do you know that? Don't you think that we probably would've talked
to them already and made preparations for conversion first?

> But if that is your choice, I would send you an email asking how I
> need to retool this driver to work with the new MCE gen2 code that you
> had in mind.

As I said above, I'm very sceptical this will ever work, I guess I'd
have to live and see.

Now, with your own buffer solution, nothing breaks and all is happy,
a win-win, if you wish. I think this is much simpler and easier a
solution.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 06:37:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMCsn-0004gb-OP; Mon, 23 Apr 2012 06:36:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SMCsm-0004gW-7i
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 06:36:20 +0000
Received: from [193.109.254.147:20343] by server-6.bemta-14.messagelabs.com id
	F8/8A-02047-368F49F4; Mon, 23 Apr 2012 06:36:19 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335162978!5806838!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzAyMTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11432 invoked from network); 23 Apr 2012 06:36:18 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 06:36:18 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 8A7372FF6;
	Mon, 23 Apr 2012 09:36:17 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2F9CF20059; Mon, 23 Apr 2012 09:36:17 +0300 (EEST)
Date: Mon, 23 Apr 2012 09:36:17 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
Message-ID: <20120423063616.GE2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>    hi guys,
> =


Hello,

>    It's my first time here and in a mailing lists, I only participated in
>    forums before. Please, If I make a mistake you should advise me. Let's=
 go!
> =

>    I was reading "xencommons not start" in a Remus Forum in order to inst=
all
>    Remus.
>    Well* I followed the tutorial
>    <[1]http://remusha.wikidot.com/configuring-and-installing-remus>, I re=
boot
>    in xen_unstable and I had a error message:
> =

>    error: couldn't open file
>    error: you need to load the multiboot kernel first
> =

>    then I redid tutorial after "Adapt Grub" and in a moment I do command:
> =

>    # /etc/init.d/xend start
>    xencommons should be started first.
> =

>    but I had done "/etc/init.d/xencommons start" before and no error mess=
age
>    returned !!!???
> =

>    I also tried insert modules manually (coz in other mailing list said to
>    put some modules - see my setups after this mail) but I had:
> =

>    # modprobe xen-evtchn
>    FATAL: Module xen_evtchn not found.
> =


So xen event channel support is not compiled as a module? =

is it enabled at all in your dom0 kernel config? =


http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 06:37:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMCsn-0004gb-OP; Mon, 23 Apr 2012 06:36:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SMCsm-0004gW-7i
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 06:36:20 +0000
Received: from [193.109.254.147:20343] by server-6.bemta-14.messagelabs.com id
	F8/8A-02047-368F49F4; Mon, 23 Apr 2012 06:36:19 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335162978!5806838!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzAyMTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11432 invoked from network); 23 Apr 2012 06:36:18 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 06:36:18 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 8A7372FF6;
	Mon, 23 Apr 2012 09:36:17 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2F9CF20059; Mon, 23 Apr 2012 09:36:17 +0300 (EEST)
Date: Mon, 23 Apr 2012 09:36:17 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
Message-ID: <20120423063616.GE2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>    hi guys,
> =


Hello,

>    It's my first time here and in a mailing lists, I only participated in
>    forums before. Please, If I make a mistake you should advise me. Let's=
 go!
> =

>    I was reading "xencommons not start" in a Remus Forum in order to inst=
all
>    Remus.
>    Well* I followed the tutorial
>    <[1]http://remusha.wikidot.com/configuring-and-installing-remus>, I re=
boot
>    in xen_unstable and I had a error message:
> =

>    error: couldn't open file
>    error: you need to load the multiboot kernel first
> =

>    then I redid tutorial after "Adapt Grub" and in a moment I do command:
> =

>    # /etc/init.d/xend start
>    xencommons should be started first.
> =

>    but I had done "/etc/init.d/xencommons start" before and no error mess=
age
>    returned !!!???
> =

>    I also tried insert modules manually (coz in other mailing list said to
>    put some modules - see my setups after this mail) but I had:
> =

>    # modprobe xen-evtchn
>    FATAL: Module xen_evtchn not found.
> =


So xen event channel support is not compiled as a module? =

is it enabled at all in your dom0 kernel config? =


http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 06:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMD5F-0004sN-2P; Mon, 23 Apr 2012 06:49:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1SMD5D-0004sI-Rw
	for Xen-devel@lists.xensource.com; Mon, 23 Apr 2012 06:49:12 +0000
Received: from [85.158.139.83:41134] by server-12.bemta-5.messagelabs.com id
	F9/BD-05587-76BF49F4; Mon, 23 Apr 2012 06:49:11 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335163749!25033603!1
X-Originating-IP: [203.10.76.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21461 invoked from network); 23 Apr 2012 06:49:09 -0000
Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10)
	by server-5.tower-182.messagelabs.com with SMTP;
	23 Apr 2012 06:49:09 -0000
Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by members.tip.net.au (Postfix) with ESMTPSA id CB34E1640F2;
	Mon, 23 Apr 2012 16:49:04 +1000 (EST)
Date: Mon, 23 Apr 2012 16:48:59 +1000
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: linux-next@vger.kernel.org
Message-Id: <20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
In-Reply-To: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
References: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
X-Mailer: Sylpheed 3.2.0beta7 (GTK+ 2.24.10; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ben Dooks <ben-linux@fluff.org>, Rob Lee <rob.lee@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Xen-devel] linux-next: clean up time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0812671820655577438=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0812671820655577438==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J"

--Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

On Mon, 2 Apr 2012 11:20:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> w=
rote:
>
> Can people please clean up stuff in their trees that has been merged by
> their upstream.   This is especially useful where the upstream merged (or
> applied) a slightly different version of their tree.

There is still much cruft in the linux-next included trees ... The
following trees appear empty (relative to Linus' tree) but cause conflicts:

bjdooks-i2c
xen
dma-buf
cpuidle-cons

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPlPtbAAoJEECxmPOUX5FEoCsQAKT6k2HQFywvsFfXeOJcDKWb
uWGyArrjRt8RKSPbCVQuGrzkQkC7AFHINAigm/8YQ3hwJX7++z5MPmUhNgIjzdFN
ZFN5+FbMBDERI7yuiYXMapUjx/13nSntbanAlCT2+9Na3RKFdzXi2gz+VEbzOiYs
UmYuXIRgsuhBYiclG68wI+eotRv8GU5qbje06GrlRwBIGOgsBywtvRwc2pzfwGTT
Uc2xmb5+EIy3XLgmp/d03I9nuxoLihNdSPoOR228/LCgdIILBFb2D+ZihMa5yU6a
l9S4wMRI+E1dsLbmAHCHgEanoTxtXCfnjdRTKmFBtAzBV+eaAG4RB1BOCvqdFsRN
NDLFIcDC/WvbLymk31l1nx4rAFE9IiE1H0cyFy3lEKpTBlT9EVYc9H4/l7p0Q3JH
tKaAc9kDQCDCK1Fne/SMknEpvzcHRyjvjjvstNpMyfP4+9dhTeS3wprjWC7tvfoa
Kt5NyWvDf5Lll118xrXXEBQpGoys03orll1Fi3ki7i7kzPu+NdwTYqKQGVu2HxAi
P5WSvNVntJrp1vgHHsHGoujzMmj3o2jjXHuFwYwlcDTtQws6BsIaPW785FtoHGQ+
gEiQeykb0h/HRq7jEuzsfUtd+u6yLr5gwos1TBrnX13yA/1Qbe7R7WUidgwxy4E9
6kMnejc7wy0pTyJ0HGVD
=pV7+
-----END PGP SIGNATURE-----

--Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J--


--===============0812671820655577438==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0812671820655577438==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 06:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 06:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMD5F-0004sN-2P; Mon, 23 Apr 2012 06:49:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1SMD5D-0004sI-Rw
	for Xen-devel@lists.xensource.com; Mon, 23 Apr 2012 06:49:12 +0000
Received: from [85.158.139.83:41134] by server-12.bemta-5.messagelabs.com id
	F9/BD-05587-76BF49F4; Mon, 23 Apr 2012 06:49:11 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335163749!25033603!1
X-Originating-IP: [203.10.76.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21461 invoked from network); 23 Apr 2012 06:49:09 -0000
Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10)
	by server-5.tower-182.messagelabs.com with SMTP;
	23 Apr 2012 06:49:09 -0000
Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by members.tip.net.au (Postfix) with ESMTPSA id CB34E1640F2;
	Mon, 23 Apr 2012 16:49:04 +1000 (EST)
Date: Mon, 23 Apr 2012 16:48:59 +1000
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: linux-next@vger.kernel.org
Message-Id: <20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
In-Reply-To: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
References: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
X-Mailer: Sylpheed 3.2.0beta7 (GTK+ 2.24.10; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ben Dooks <ben-linux@fluff.org>, Rob Lee <rob.lee@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Xen-devel] linux-next: clean up time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0812671820655577438=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0812671820655577438==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J"

--Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

On Mon, 2 Apr 2012 11:20:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> w=
rote:
>
> Can people please clean up stuff in their trees that has been merged by
> their upstream.   This is especially useful where the upstream merged (or
> applied) a slightly different version of their tree.

There is still much cruft in the linux-next included trees ... The
following trees appear empty (relative to Linus' tree) but cause conflicts:

bjdooks-i2c
xen
dma-buf
cpuidle-cons

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPlPtbAAoJEECxmPOUX5FEoCsQAKT6k2HQFywvsFfXeOJcDKWb
uWGyArrjRt8RKSPbCVQuGrzkQkC7AFHINAigm/8YQ3hwJX7++z5MPmUhNgIjzdFN
ZFN5+FbMBDERI7yuiYXMapUjx/13nSntbanAlCT2+9Na3RKFdzXi2gz+VEbzOiYs
UmYuXIRgsuhBYiclG68wI+eotRv8GU5qbje06GrlRwBIGOgsBywtvRwc2pzfwGTT
Uc2xmb5+EIy3XLgmp/d03I9nuxoLihNdSPoOR228/LCgdIILBFb2D+ZihMa5yU6a
l9S4wMRI+E1dsLbmAHCHgEanoTxtXCfnjdRTKmFBtAzBV+eaAG4RB1BOCvqdFsRN
NDLFIcDC/WvbLymk31l1nx4rAFE9IiE1H0cyFy3lEKpTBlT9EVYc9H4/l7p0Q3JH
tKaAc9kDQCDCK1Fne/SMknEpvzcHRyjvjjvstNpMyfP4+9dhTeS3wprjWC7tvfoa
Kt5NyWvDf5Lll118xrXXEBQpGoys03orll1Fi3ki7i7kzPu+NdwTYqKQGVu2HxAi
P5WSvNVntJrp1vgHHsHGoujzMmj3o2jjXHuFwYwlcDTtQws6BsIaPW785FtoHGQ+
gEiQeykb0h/HRq7jEuzsfUtd+u6yLr5gwos1TBrnX13yA/1Qbe7R7WUidgwxy4E9
6kMnejc7wy0pTyJ0HGVD
=pV7+
-----END PGP SIGNATURE-----

--Signature=_Mon__23_Apr_2012_16_48_59_+1000_gS5ke6Py16BsgN4J--


--===============0812671820655577438==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0812671820655577438==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 07:37:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:37:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDox-0005Lz-91; Mon, 23 Apr 2012 07:36:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMDov-0005Lu-75
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:36:25 +0000
Received: from [85.158.138.51:28275] by server-10.bemta-3.messagelabs.com id
	53/61-29478-876059F4; Mon, 23 Apr 2012 07:36:24 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335166582!21503198!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NDcw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22561 invoked from network); 23 Apr 2012 07:36:23 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 07:36:23 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Apr 2012 00:36:22 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="91988776"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 00:36:21 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 00:36:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 15:36:18 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQ
Date: Mon, 23 Apr 2012 07:36:17 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
In-Reply-To: <CBB58FB0.3E7AC%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The p2m lock in __get_gfn_type_access() is the culprit. Here is the profiling data with 10 seconds:

(XEN) p2m_lock 1 lock:
(XEN)   lock:      190733(00000000:14CE5726), block:       67159(00000007:6AAA53F3)

Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is waiting for the p2m lock. And those data only for idle guest. The impaction is more seriously when run some workload inside guest. 
I noticed that this change was adding by cs 24770. And before it, we don't require the p2m lock in _get_gfn_type_access. So is this lock really necessary?

best regards
yang


> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Thursday, April 19, 2012 4:47 PM
> To: Tim Deegan; Zhang, Yang Z
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] lock in vhpet
> 
> On 19/04/2012 09:27, "Tim Deegan" <tim@xen.org> wrote:
> 
> > At 05:19 +0000 on 19 Apr (1334812779), Zhang, Yang Z wrote:
> >> There have no problem with this patch, it works well. But it cannot
> >> fix the win8 issue. It seems there has some other issues with hpet. I
> >> will look into it.  Thanks for your quick patch.
> >
> > The lock in hvm_get_guest_time() will still be serializing the hpet
> > reads.  But since it needs to update a shared variable, that will need
> > to haul cachelines around anyway.
> 
> Yes, that's true. You could try the attached hacky patch out of interest, to see
> what that lock is costing you in your scenario. But if we want consistent
> monotonically-increasing guest time, I suspect we can't get rid of the lock, so
> that's going to limit our scalability unavoidably. Shame.
> 
>  -- Keir
> 
> > Tim.
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:37:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:37:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDox-0005Lz-91; Mon, 23 Apr 2012 07:36:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMDov-0005Lu-75
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:36:25 +0000
Received: from [85.158.138.51:28275] by server-10.bemta-3.messagelabs.com id
	53/61-29478-876059F4; Mon, 23 Apr 2012 07:36:24 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335166582!21503198!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NDcw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22561 invoked from network); 23 Apr 2012 07:36:23 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 07:36:23 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Apr 2012 00:36:22 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="91988776"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 00:36:21 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 00:36:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 15:36:18 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQ
Date: Mon, 23 Apr 2012 07:36:17 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
In-Reply-To: <CBB58FB0.3E7AC%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The p2m lock in __get_gfn_type_access() is the culprit. Here is the profiling data with 10 seconds:

(XEN) p2m_lock 1 lock:
(XEN)   lock:      190733(00000000:14CE5726), block:       67159(00000007:6AAA53F3)

Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is waiting for the p2m lock. And those data only for idle guest. The impaction is more seriously when run some workload inside guest. 
I noticed that this change was adding by cs 24770. And before it, we don't require the p2m lock in _get_gfn_type_access. So is this lock really necessary?

best regards
yang


> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Thursday, April 19, 2012 4:47 PM
> To: Tim Deegan; Zhang, Yang Z
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] lock in vhpet
> 
> On 19/04/2012 09:27, "Tim Deegan" <tim@xen.org> wrote:
> 
> > At 05:19 +0000 on 19 Apr (1334812779), Zhang, Yang Z wrote:
> >> There have no problem with this patch, it works well. But it cannot
> >> fix the win8 issue. It seems there has some other issues with hpet. I
> >> will look into it.  Thanks for your quick patch.
> >
> > The lock in hvm_get_guest_time() will still be serializing the hpet
> > reads.  But since it needs to update a shared variable, that will need
> > to haul cachelines around anyway.
> 
> Yes, that's true. You could try the attached hacky patch out of interest, to see
> what that lock is costing you in your scenario. But if we want consistent
> monotonically-increasing guest time, I suspect we can't get rid of the lock, so
> that's going to limit our scalability unavoidably. Shame.
> 
>  -- Keir
> 
> > Tim.
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:42:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDuH-0005WR-Ns; Mon, 23 Apr 2012 07:41:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMDuF-0005WI-W8
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:41:56 +0000
Received: from [85.158.143.99:37371] by server-1.bemta-4.messagelabs.com id
	FF/ED-20925-3C7059F4; Mon, 23 Apr 2012 07:41:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335166913!13603788!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18040 invoked from network); 23 Apr 2012 07:41:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:41:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:41:53 +0100
Message-Id: <4F9523DD020000780007F339@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:41:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
In-Reply-To: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Fri Apr 20 11:36:02 2012 -0700
> +++ b/xen/arch/x86/domctl.c	Fri Apr 20 17:55:49 2012 -0700
> @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
>          c.nat->user_regs.fs = sreg.sel;
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs = sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +            c.nat->gs_base_kernel = sreg.base;
> +        else
> +            c.nat->gs_base_user = sreg.base;
> +#endif

If you do anything like this, do it completely please (i.e. fill all three
base address fields instead of just one).

Jan

>      }
>      else
>      {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:42:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDuH-0005WR-Ns; Mon, 23 Apr 2012 07:41:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMDuF-0005WI-W8
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:41:56 +0000
Received: from [85.158.143.99:37371] by server-1.bemta-4.messagelabs.com id
	FF/ED-20925-3C7059F4; Mon, 23 Apr 2012 07:41:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335166913!13603788!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18040 invoked from network); 23 Apr 2012 07:41:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:41:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:41:53 +0100
Message-Id: <4F9523DD020000780007F339@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:41:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
In-Reply-To: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Fri Apr 20 11:36:02 2012 -0700
> +++ b/xen/arch/x86/domctl.c	Fri Apr 20 17:55:49 2012 -0700
> @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
>          c.nat->user_regs.fs = sreg.sel;
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs = sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +            c.nat->gs_base_kernel = sreg.base;
> +        else
> +            c.nat->gs_base_user = sreg.base;
> +#endif

If you do anything like this, do it completely please (i.e. fill all three
base address fields instead of just one).

Jan

>      }
>      else
>      {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDvt-0005gB-7m; Mon, 23 Apr 2012 07:43:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMDvs-0005fz-4B
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:43:36 +0000
Received: from [85.158.143.99:47940] by server-2.bemta-4.messagelabs.com id
	73/79-17550-728059F4; Mon, 23 Apr 2012 07:43:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335167014!24470523!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10319 invoked from network); 23 Apr 2012 07:43:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:43:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:43:33 +0100
Message-Id: <4F952441020000780007F33C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:43:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yang Z Zhang" <yang.z.zhang@intel.com>,
	"Keir Fraser" <keir@xen.org>,"Tim Deegan" <tim@xen.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 09:36, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> The p2m lock in __get_gfn_type_access() is the culprit. Here is the profiling 
> data with 10 seconds:
> 
> (XEN) p2m_lock 1 lock:
> (XEN)   lock:      190733(00000000:14CE5726), block:       
> 67159(00000007:6AAA53F3)
> 
> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs blocked 
> 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is waiting for 
> the p2m lock. And those data only for idle guest. The impaction is more 
> seriously when run some workload inside guest. 
> I noticed that this change was adding by cs 24770. And before it, we don't 
> require the p2m lock in _get_gfn_type_access. So is this lock really 
> necessary?

Or shouldn't such a lock frequently taken on a read path be an rwlock
instead?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDvt-0005gB-7m; Mon, 23 Apr 2012 07:43:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMDvs-0005fz-4B
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:43:36 +0000
Received: from [85.158.143.99:47940] by server-2.bemta-4.messagelabs.com id
	73/79-17550-728059F4; Mon, 23 Apr 2012 07:43:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335167014!24470523!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10319 invoked from network); 23 Apr 2012 07:43:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:43:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:43:33 +0100
Message-Id: <4F952441020000780007F33C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:43:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yang Z Zhang" <yang.z.zhang@intel.com>,
	"Keir Fraser" <keir@xen.org>,"Tim Deegan" <tim@xen.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 09:36, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> The p2m lock in __get_gfn_type_access() is the culprit. Here is the profiling 
> data with 10 seconds:
> 
> (XEN) p2m_lock 1 lock:
> (XEN)   lock:      190733(00000000:14CE5726), block:       
> 67159(00000007:6AAA53F3)
> 
> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs blocked 
> 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is waiting for 
> the p2m lock. And those data only for idle guest. The impaction is more 
> seriously when run some workload inside guest. 
> I noticed that this change was adding by cs 24770. And before it, we don't 
> require the p2m lock in _get_gfn_type_access. So is this lock really 
> necessary?

Or shouldn't such a lock frequently taken on a read path be an rwlock
instead?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDyj-0005wA-4J; Mon, 23 Apr 2012 07:46:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SMDyh-0005vR-Gy
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:46:31 +0000
Received: from [85.158.143.99:2646] by server-3.bemta-4.messagelabs.com id
	1D/90-05853-6D8059F4; Mon, 23 Apr 2012 07:46:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335167189!24751520!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15327 invoked from network); 23 Apr 2012 07:46:29 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 07:46:29 -0000
Received: by bkty15 with SMTP id y15so131683bkt.32
	for <multiple recipients>; Mon, 23 Apr 2012 00:46:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=SFrW8gz0/9UghL1ZyBowlr0bL+R2IO/sBvPU6tRHl+o=;
	b=DOrn5F7cFH5aIBmLdF00B5Cf59fddhn/BkaeEvJdtp6xk+W4rCZoq7P07LHD6kn/MC
	0f7+2AEe7veB0+i+WHLVOBh2hnD7vtJxzPBhwlSkT9vWBfo6BIwkUbYuPyq3vJoHE7hF
	M9q/PIRuqucXGKxUG1GExOvYQIza/42rQ3gfo7G0IAzJjsjngp+tf7XVFNEPMNDSbHNT
	AHXl8f6NandJGq/K5ZQ67rUa6YVsEQo3xgeeMIpvL9m/TVPLP3OmXCpgaHlhrUF3SDwZ
	7eszn9oEzdot2xJDkoEpGQNQsKW567Mjnd5kXpkIdSp0E/KkIckW8r8N+aNsa0QkV3Eh
	wj7w==
Received: by 10.204.149.210 with SMTP id u18mr3828191bkv.34.1335167188788;
	Mon, 23 Apr 2012 00:46:28 -0700 (PDT)
Received: from [172.16.26.11] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id s16sm22870013bkt.3.2012.04.23.00.46.21
	(version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 00:46:25 -0700 (PDT)
Message-ID: <4F9508CA.7040709@xen.org>
Date: Mon, 23 Apr 2012 08:46:18 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	xen-api@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day Today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3416122211313843332=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3416122211313843332==
Content-Type: multipart/alternative;
 boundary="------------000500090705090002080306"

This is a multi-part message in MIME format.
--------------000500090705090002080306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Good Morning,
it is Xen Document Day today!
Join us on IRC: freenode channel *#xendocday*
More info: wiki.xen.org/wiki/Xen_Document_Day
TODO List: wiki.xen.org/wiki/Xen_Document_Days/TODO
Lars

--------------000500090705090002080306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Good Morning,<br>
    it is Xen Document Day today!<br>
    Join us on IRC: freenode channel <strong>#xendocday</strong><br>
    More info: wiki.xen.org/wiki/Xen_Document_Day<br>
    TODO List: wiki.xen.org/wiki/Xen_Document_Days/TODO<br>
    Lars<br>
  </body>
</html>

--------------000500090705090002080306--


--===============3416122211313843332==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3416122211313843332==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 07:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDyj-0005wA-4J; Mon, 23 Apr 2012 07:46:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SMDyh-0005vR-Gy
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:46:31 +0000
Received: from [85.158.143.99:2646] by server-3.bemta-4.messagelabs.com id
	1D/90-05853-6D8059F4; Mon, 23 Apr 2012 07:46:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335167189!24751520!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15327 invoked from network); 23 Apr 2012 07:46:29 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 07:46:29 -0000
Received: by bkty15 with SMTP id y15so131683bkt.32
	for <multiple recipients>; Mon, 23 Apr 2012 00:46:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=SFrW8gz0/9UghL1ZyBowlr0bL+R2IO/sBvPU6tRHl+o=;
	b=DOrn5F7cFH5aIBmLdF00B5Cf59fddhn/BkaeEvJdtp6xk+W4rCZoq7P07LHD6kn/MC
	0f7+2AEe7veB0+i+WHLVOBh2hnD7vtJxzPBhwlSkT9vWBfo6BIwkUbYuPyq3vJoHE7hF
	M9q/PIRuqucXGKxUG1GExOvYQIza/42rQ3gfo7G0IAzJjsjngp+tf7XVFNEPMNDSbHNT
	AHXl8f6NandJGq/K5ZQ67rUa6YVsEQo3xgeeMIpvL9m/TVPLP3OmXCpgaHlhrUF3SDwZ
	7eszn9oEzdot2xJDkoEpGQNQsKW567Mjnd5kXpkIdSp0E/KkIckW8r8N+aNsa0QkV3Eh
	wj7w==
Received: by 10.204.149.210 with SMTP id u18mr3828191bkv.34.1335167188788;
	Mon, 23 Apr 2012 00:46:28 -0700 (PDT)
Received: from [172.16.26.11] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id s16sm22870013bkt.3.2012.04.23.00.46.21
	(version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 00:46:25 -0700 (PDT)
Message-ID: <4F9508CA.7040709@xen.org>
Date: Mon, 23 Apr 2012 08:46:18 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	xen-api@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day Today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3416122211313843332=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3416122211313843332==
Content-Type: multipart/alternative;
 boundary="------------000500090705090002080306"

This is a multi-part message in MIME format.
--------------000500090705090002080306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Good Morning,
it is Xen Document Day today!
Join us on IRC: freenode channel *#xendocday*
More info: wiki.xen.org/wiki/Xen_Document_Day
TODO List: wiki.xen.org/wiki/Xen_Document_Days/TODO
Lars

--------------000500090705090002080306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Good Morning,<br>
    it is Xen Document Day today!<br>
    Join us on IRC: freenode channel <strong>#xendocday</strong><br>
    More info: wiki.xen.org/wiki/Xen_Document_Day<br>
    TODO List: wiki.xen.org/wiki/Xen_Document_Days/TODO<br>
    Lars<br>
  </body>
</html>

--------------000500090705090002080306--


--===============3416122211313843332==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3416122211313843332==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 07:47:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDzG-00063B-D1; Mon, 23 Apr 2012 07:47:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMDzE-00062X-Ob
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:47:05 +0000
Received: from [85.158.139.83:42499] by server-7.bemta-5.messagelabs.com id
	39/67-16195-7F8059F4; Mon, 23 Apr 2012 07:47:03 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335167221!25043241!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28587 invoked from network); 23 Apr 2012 07:47:02 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 07:47:02 -0000
Received: by lahe6 with SMTP id e6so10269332lah.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Zrf6nYrFZpOgH+zRkonngr971C5fC6KBn+oHNkF4arM=;
	b=hiZ733REbHCgfZIUj1FuJeOMmbqRgT4k8lYvT91u+P2nn5N+yGTUmx2J0tfrVDM+la
	h/xljhXpaf4Qwi2i3k1zPd+T++9x3X/aDdRdFyh5cBpw2+65FBfiXPhlOsE4ovEDG8IV
	7p+sIwl3gr2WUDR6K81dV4M0GBVhV+ZZys+98=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=Zrf6nYrFZpOgH+zRkonngr971C5fC6KBn+oHNkF4arM=;
	b=awdhywyvl39BsbIaAVxdLYdSs54T5vg7zqN+BPyWj7HmGuysMU01yPReAuAkOMEwvs
	KsALN7CX3/3OEb2hsQ646jv63y6qPc/3dZk75EmPvmH8m45bFvzGe0bkbO5OGlk+b7va
	XMOh3JJtSlphZuk5Sk2bZB55E1eFcb+/gAx2bYgKa3YkcsXk3tqER7/AmbpGsetLty9J
	0YsXImSyBEpSrHtvRjVyLFTTu15HARdeVA3XGqSXq6YPC4lbcAjzSdFfenSiLL/lH7yb
	mXBxYuMN4k5abhSGPOCN3ayH86AiH3TX1OUl7H4MCpTTypcKzn3dCrKy3lGvhc2njuUv
	Vu1Q==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr14221193lab.29.1335167220561;
	Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
X-Originating-IP: [174.234.78.60]
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
In-Reply-To: <4F9523DD020000780007F339@nat28.tlf.novell.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
	<4F9523DD020000780007F339@nat28.tlf.novell.com>
Date: Mon, 23 Apr 2012 00:47:00 -0700
Message-ID: <CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQkKcTmRu/adH/J5MMv92NUTKC2RtfdIfs90URbrCFtAcc0sIkSGRvC4+Lw+cnS2keK3Kqws
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2799580870972676955=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2799580870972676955==
Content-Type: multipart/alternative; boundary=bcaec54fbd3ce5b87904be53d74a

--bcaec54fbd3ce5b87904be53d74a
Content-Type: text/plain; charset=ISO-8859-1

On Apr 23, 2012 12:41 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.com>
wrote:
> > Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> >
> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >
> > diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
> > --- a/xen/arch/x86/domctl.c   Fri Apr 20 11:36:02 2012 -0700
> > +++ b/xen/arch/x86/domctl.c   Fri Apr 20 17:55:49 2012 -0700
> > @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
> >          c.nat->user_regs.fs = sreg.sel;
> >          hvm_get_segment_register(v, x86_seg_gs, &sreg);
> >          c.nat->user_regs.gs = sreg.sel;
> > +#ifdef __x86_64__
> > +        if ( ring_0(&c.nat->user_regs) )
> > +            c.nat->gs_base_kernel = sreg.base;
> > +        else
> > +            c.nat->gs_base_user = sreg.base;
> > +#endif
>
> If you do anything like this, do it completely please (i.e. fill all three
> base address fields instead of just one).
>

Sure. I was not sure if it was ok to add fields to the vcpu context
structure which is why I didn't do it across the board. I will do so and
resubmit.

Aravindh
> Jan
>
> >      }
> >      else
> >      {
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>
>

--bcaec54fbd3ce5b87904be53d74a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Apr 23, 2012 12:41 AM, &quot;Jan Beulich&quot; &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;&gt;&gt; On 21.04.12 at 02:58, Aravindh Puthiyaparambil &lt;<a hre=
f=3D"mailto:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt; wrote:<br>
&gt; &gt; Add GS base to the HVM VCPU context returned by xc_vcpu_getcontex=
t()<br>
&gt; &gt;<br>
&gt; &gt; Signed-off-by: Aravindh Puthiyaparambil &lt;<a href=3D"mailto:ara=
vindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt;<br>
&gt; &gt; diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c<br>
&gt; &gt; --- a/xen/arch/x86/domctl.c =A0 Fri Apr 20 11:36:02 2012 -0700<br=
>
&gt; &gt; +++ b/xen/arch/x86/domctl.c =A0 Fri Apr 20 17:55:49 2012 -0700<br=
>
&gt; &gt; @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,<b=
r>
&gt; &gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;user_regs.fs =3D sreg.sel;<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &amp;s=
reg);<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;<a href=3D"http://user_regs.gs">user=
_regs.gs</a> =3D sreg.sel;<br>
&gt; &gt; +#ifdef __x86_64__<br>
&gt; &gt; + =A0 =A0 =A0 =A0if ( ring_0(&amp;c.nat-&gt;user_regs) )<br>
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_kernel =3D sreg.base;<=
br>
&gt; &gt; + =A0 =A0 =A0 =A0else<br>
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_user =3D sreg.base;<br=
>
&gt; &gt; +#endif<br>
&gt;<br>
&gt; If you do anything like this, do it completely please (i.e. fill all t=
hree<br>
&gt; base address fields instead of just one).<br>
&gt;</p>
<p>Sure. I was not sure if it was ok to add fields to the vcpu context stru=
cture which is why I didn&#39;t do it across the board. I will do so and re=
submit.</p>
<p>Aravindh<br>
&gt; Jan<br>
&gt;<br>
&gt; &gt; =A0 =A0 =A0}<br>
&gt; &gt; =A0 =A0 =A0else<br>
&gt; &gt; =A0 =A0 =A0{<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Xen-devel mailing list<br>
&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.or=
g</a><br>
&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/x=
en-devel</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
</p>

--bcaec54fbd3ce5b87904be53d74a--


--===============2799580870972676955==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2799580870972676955==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 07:47:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMDzG-00063B-D1; Mon, 23 Apr 2012 07:47:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMDzE-00062X-Ob
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:47:05 +0000
Received: from [85.158.139.83:42499] by server-7.bemta-5.messagelabs.com id
	39/67-16195-7F8059F4; Mon, 23 Apr 2012 07:47:03 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335167221!25043241!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28587 invoked from network); 23 Apr 2012 07:47:02 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 07:47:02 -0000
Received: by lahe6 with SMTP id e6so10269332lah.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Zrf6nYrFZpOgH+zRkonngr971C5fC6KBn+oHNkF4arM=;
	b=hiZ733REbHCgfZIUj1FuJeOMmbqRgT4k8lYvT91u+P2nn5N+yGTUmx2J0tfrVDM+la
	h/xljhXpaf4Qwi2i3k1zPd+T++9x3X/aDdRdFyh5cBpw2+65FBfiXPhlOsE4ovEDG8IV
	7p+sIwl3gr2WUDR6K81dV4M0GBVhV+ZZys+98=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=Zrf6nYrFZpOgH+zRkonngr971C5fC6KBn+oHNkF4arM=;
	b=awdhywyvl39BsbIaAVxdLYdSs54T5vg7zqN+BPyWj7HmGuysMU01yPReAuAkOMEwvs
	KsALN7CX3/3OEb2hsQ646jv63y6qPc/3dZk75EmPvmH8m45bFvzGe0bkbO5OGlk+b7va
	XMOh3JJtSlphZuk5Sk2bZB55E1eFcb+/gAx2bYgKa3YkcsXk3tqER7/AmbpGsetLty9J
	0YsXImSyBEpSrHtvRjVyLFTTu15HARdeVA3XGqSXq6YPC4lbcAjzSdFfenSiLL/lH7yb
	mXBxYuMN4k5abhSGPOCN3ayH86AiH3TX1OUl7H4MCpTTypcKzn3dCrKy3lGvhc2njuUv
	Vu1Q==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr14221193lab.29.1335167220561;
	Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
X-Originating-IP: [174.234.78.60]
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 00:47:00 -0700 (PDT)
In-Reply-To: <4F9523DD020000780007F339@nat28.tlf.novell.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
	<4F9523DD020000780007F339@nat28.tlf.novell.com>
Date: Mon, 23 Apr 2012 00:47:00 -0700
Message-ID: <CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQkKcTmRu/adH/J5MMv92NUTKC2RtfdIfs90URbrCFtAcc0sIkSGRvC4+Lw+cnS2keK3Kqws
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2799580870972676955=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2799580870972676955==
Content-Type: multipart/alternative; boundary=bcaec54fbd3ce5b87904be53d74a

--bcaec54fbd3ce5b87904be53d74a
Content-Type: text/plain; charset=ISO-8859-1

On Apr 23, 2012 12:41 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.com>
wrote:
> > Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> >
> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >
> > diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
> > --- a/xen/arch/x86/domctl.c   Fri Apr 20 11:36:02 2012 -0700
> > +++ b/xen/arch/x86/domctl.c   Fri Apr 20 17:55:49 2012 -0700
> > @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
> >          c.nat->user_regs.fs = sreg.sel;
> >          hvm_get_segment_register(v, x86_seg_gs, &sreg);
> >          c.nat->user_regs.gs = sreg.sel;
> > +#ifdef __x86_64__
> > +        if ( ring_0(&c.nat->user_regs) )
> > +            c.nat->gs_base_kernel = sreg.base;
> > +        else
> > +            c.nat->gs_base_user = sreg.base;
> > +#endif
>
> If you do anything like this, do it completely please (i.e. fill all three
> base address fields instead of just one).
>

Sure. I was not sure if it was ok to add fields to the vcpu context
structure which is why I didn't do it across the board. I will do so and
resubmit.

Aravindh
> Jan
>
> >      }
> >      else
> >      {
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>
>

--bcaec54fbd3ce5b87904be53d74a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Apr 23, 2012 12:41 AM, &quot;Jan Beulich&quot; &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;&gt;&gt; On 21.04.12 at 02:58, Aravindh Puthiyaparambil &lt;<a hre=
f=3D"mailto:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt; wrote:<br>
&gt; &gt; Add GS base to the HVM VCPU context returned by xc_vcpu_getcontex=
t()<br>
&gt; &gt;<br>
&gt; &gt; Signed-off-by: Aravindh Puthiyaparambil &lt;<a href=3D"mailto:ara=
vindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt;<br>
&gt; &gt; diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c<br>
&gt; &gt; --- a/xen/arch/x86/domctl.c =A0 Fri Apr 20 11:36:02 2012 -0700<br=
>
&gt; &gt; +++ b/xen/arch/x86/domctl.c =A0 Fri Apr 20 17:55:49 2012 -0700<br=
>
&gt; &gt; @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,<b=
r>
&gt; &gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;user_regs.fs =3D sreg.sel;<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &amp;s=
reg);<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;<a href=3D"http://user_regs.gs">user=
_regs.gs</a> =3D sreg.sel;<br>
&gt; &gt; +#ifdef __x86_64__<br>
&gt; &gt; + =A0 =A0 =A0 =A0if ( ring_0(&amp;c.nat-&gt;user_regs) )<br>
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_kernel =3D sreg.base;<=
br>
&gt; &gt; + =A0 =A0 =A0 =A0else<br>
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_user =3D sreg.base;<br=
>
&gt; &gt; +#endif<br>
&gt;<br>
&gt; If you do anything like this, do it completely please (i.e. fill all t=
hree<br>
&gt; base address fields instead of just one).<br>
&gt;</p>
<p>Sure. I was not sure if it was ok to add fields to the vcpu context stru=
cture which is why I didn&#39;t do it across the board. I will do so and re=
submit.</p>
<p>Aravindh<br>
&gt; Jan<br>
&gt;<br>
&gt; &gt; =A0 =A0 =A0}<br>
&gt; &gt; =A0 =A0 =A0else<br>
&gt; &gt; =A0 =A0 =A0{<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Xen-devel mailing list<br>
&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.or=
g</a><br>
&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/x=
en-devel</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
</p>

--bcaec54fbd3ce5b87904be53d74a--


--===============2799580870972676955==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2799580870972676955==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 07:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SME2e-0006dK-Ok; Mon, 23 Apr 2012 07:50:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SME2d-0006d6-Mx
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:50:35 +0000
Received: from [85.158.143.99:30272] by server-3.bemta-4.messagelabs.com id
	D9/D6-05853-AC9059F4; Mon, 23 Apr 2012 07:50:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335167432!23896381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11662 invoked from network); 23 Apr 2012 07:50:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:50:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:50:32 +0100
Message-Id: <4F9525E4020000780007F350@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:50:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> When PCIE device which has LTR/OBFF capabilities is owned by pciback, 
> LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that 
> guest with device assigned can be benefitted.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
> b/drivers/xen/xen-pciback/pci_stub.c
> index 19834d1..82aac5b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct pci_dev 
> *dev)
>  	dev_dbg(&dev->dev, "reset device\n");
>  	xen_pcibk_reset_device(dev);
>  
> +	/* set default value */
> +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */
> +
> +	/* Enable LTR and OBFF before do device assignment */
> +	/* LTR(Latency tolerance reporting) allows devices to send messages to the
> +	 * root complex indicating their latency tolerance for snooped & unsnooped
> +	 * memory transactions. 
> +	 */
> +	pci_enable_ltr(dev);
> +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);

Wouldn't the guest kernel be able to do this itself, as it's just playing
with bits in the PCIE capability structure, or the LTR extended one?

If not, shouldn't you properly report (or at least log) errors here?

> +
> +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> +	 * energy efficiency by giving devices information about when interrupts and
> +	 * other activity will have a reduced power impact.
> +	 */
> +	pci_enable_obff(dev, type);

Similarly here.

Jan

> +
>  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
>  	return 0;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SME2e-0006dK-Ok; Mon, 23 Apr 2012 07:50:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SME2d-0006d6-Mx
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:50:35 +0000
Received: from [85.158.143.99:30272] by server-3.bemta-4.messagelabs.com id
	D9/D6-05853-AC9059F4; Mon, 23 Apr 2012 07:50:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335167432!23896381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11662 invoked from network); 23 Apr 2012 07:50:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:50:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:50:32 +0100
Message-Id: <4F9525E4020000780007F350@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:50:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> When PCIE device which has LTR/OBFF capabilities is owned by pciback, 
> LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that 
> guest with device assigned can be benefitted.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
> b/drivers/xen/xen-pciback/pci_stub.c
> index 19834d1..82aac5b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct pci_dev 
> *dev)
>  	dev_dbg(&dev->dev, "reset device\n");
>  	xen_pcibk_reset_device(dev);
>  
> +	/* set default value */
> +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */
> +
> +	/* Enable LTR and OBFF before do device assignment */
> +	/* LTR(Latency tolerance reporting) allows devices to send messages to the
> +	 * root complex indicating their latency tolerance for snooped & unsnooped
> +	 * memory transactions. 
> +	 */
> +	pci_enable_ltr(dev);
> +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);

Wouldn't the guest kernel be able to do this itself, as it's just playing
with bits in the PCIE capability structure, or the LTR extended one?

If not, shouldn't you properly report (or at least log) errors here?

> +
> +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> +	 * energy efficiency by giving devices information about when interrupts and
> +	 * other activity will have a reduced power impact.
> +	 */
> +	pci_enable_obff(dev, type);

Similarly here.

Jan

> +
>  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
>  	return 0;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:52:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SME4G-0006sq-8J; Mon, 23 Apr 2012 07:52:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SME4F-0006sX-C3
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:52:15 +0000
Received: from [85.158.143.35:38293] by server-1.bemta-4.messagelabs.com id
	3B/4D-20925-D2A059F4; Mon, 23 Apr 2012 07:52:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335167529!13601224!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25490 invoked from network); 23 Apr 2012 07:52:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:52:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:52:09 +0100
Message-Id: <4F952647020000780007F368@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:52:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<20120423023823.GC13840@phenom.dumpdata.com>
	<403610A45A2B5242BD291EDAE8B37D300FD2FD51@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD2FD51@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 05:16, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
>> On Sun, Apr 22, 2012 at 03:25:04PM +0000, Hao, Xudong wrote:
>> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
>> 
>> OK, but didn't you just come with up those values?
>> 
> 
> The value should be set by driver, but now seems no real device support 
> these two feature, at least I don't know such a device, and no driver call 
> ltr/obff function. 
> I just set the max value as default here, any suggestion?

Matching my previous reply - why don't you just let the guest do
this itself, should it so desire, thus allowing it to pick a suitable
value.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:52:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SME4G-0006sq-8J; Mon, 23 Apr 2012 07:52:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SME4F-0006sX-C3
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:52:15 +0000
Received: from [85.158.143.35:38293] by server-1.bemta-4.messagelabs.com id
	3B/4D-20925-D2A059F4; Mon, 23 Apr 2012 07:52:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335167529!13601224!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25490 invoked from network); 23 Apr 2012 07:52:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:52:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:52:09 +0100
Message-Id: <4F952647020000780007F368@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:52:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<20120423023823.GC13840@phenom.dumpdata.com>
	<403610A45A2B5242BD291EDAE8B37D300FD2FD51@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD2FD51@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 05:16, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
>> On Sun, Apr 22, 2012 at 03:25:04PM +0000, Hao, Xudong wrote:
>> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
>> 
>> OK, but didn't you just come with up those values?
>> 
> 
> The value should be set by driver, but now seems no real device support 
> these two feature, at least I don't know such a device, and no driver call 
> ltr/obff function. 
> I just set the max value as default here, any suggestion?

Matching my previous reply - why don't you just let the guest do
this itself, should it so desire, thus allowing it to pick a suitable
value.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:54:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SME5q-00074I-OR; Mon, 23 Apr 2012 07:53:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SME5o-00073v-Om
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:53:52 +0000
Received: from [85.158.143.35:12616] by server-2.bemta-4.messagelabs.com id
	99/88-17550-09A059F4; Mon, 23 Apr 2012 07:53:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335167631!8283460!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14227 invoked from network); 23 Apr 2012 07:53:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:53:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:53:51 +0100
Message-Id: <4F9526A9020000780007F36B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:53:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
	<4F9523DD020000780007F339@nat28.tlf.novell.com>
	<CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
In-Reply-To: <CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 09:47, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> On Apr 23, 2012 12:41 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>> >>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.com>
> wrote:
>> > Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
>> >
>> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> >
>> > diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
>> > --- a/xen/arch/x86/domctl.c   Fri Apr 20 11:36:02 2012 -0700
>> > +++ b/xen/arch/x86/domctl.c   Fri Apr 20 17:55:49 2012 -0700
>> > @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
>> >          c.nat->user_regs.fs = sreg.sel;
>> >          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>> >          c.nat->user_regs.gs = sreg.sel;
>> > +#ifdef __x86_64__
>> > +        if ( ring_0(&c.nat->user_regs) )
>> > +            c.nat->gs_base_kernel = sreg.base;
>> > +        else
>> > +            c.nat->gs_base_user = sreg.base;
>> > +#endif
>>
>> If you do anything like this, do it completely please (i.e. fill all three
>> base address fields instead of just one).
>>
> 
> Sure. I was not sure if it was ok to add fields to the vcpu context
> structure which is why I didn't do it across the board. I will do so and
> resubmit.

I don't see what fields you would need to add.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 07:54:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 07:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SME5q-00074I-OR; Mon, 23 Apr 2012 07:53:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SME5o-00073v-Om
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 07:53:52 +0000
Received: from [85.158.143.35:12616] by server-2.bemta-4.messagelabs.com id
	99/88-17550-09A059F4; Mon, 23 Apr 2012 07:53:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335167631!8283460!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14227 invoked from network); 23 Apr 2012 07:53:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 07:53:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Apr 2012 08:53:51 +0100
Message-Id: <4F9526A9020000780007F36B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Apr 2012 08:53:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
	<4F9523DD020000780007F339@nat28.tlf.novell.com>
	<CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
In-Reply-To: <CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 09:47, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> On Apr 23, 2012 12:41 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>> >>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.com>
> wrote:
>> > Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
>> >
>> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> >
>> > diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
>> > --- a/xen/arch/x86/domctl.c   Fri Apr 20 11:36:02 2012 -0700
>> > +++ b/xen/arch/x86/domctl.c   Fri Apr 20 17:55:49 2012 -0700
>> > @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
>> >          c.nat->user_regs.fs = sreg.sel;
>> >          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>> >          c.nat->user_regs.gs = sreg.sel;
>> > +#ifdef __x86_64__
>> > +        if ( ring_0(&c.nat->user_regs) )
>> > +            c.nat->gs_base_kernel = sreg.base;
>> > +        else
>> > +            c.nat->gs_base_user = sreg.base;
>> > +#endif
>>
>> If you do anything like this, do it completely please (i.e. fill all three
>> base address fields instead of just one).
>>
> 
> Sure. I was not sure if it was ok to add fields to the vcpu context
> structure which is why I didn't do it across the board. I will do so and
> resubmit.

I don't see what fields you would need to add.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMERI-00086w-Rb; Mon, 23 Apr 2012 08:16:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMERG-00086r-VD
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:16:03 +0000
Received: from [85.158.138.51:57975] by server-3.bemta-3.messagelabs.com id
	15/A7-04048-2CF059F4; Mon, 23 Apr 2012 08:16:02 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335168960!23233408!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NDcw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27526 invoked from network); 23 Apr 2012 08:16:01 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 08:16:01 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Apr 2012 01:15:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="91998618"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 01:15:59 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 01:15:59 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 16:15:57 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Tim Deegan
	<tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQ//+AYID//3K4kA==
Date: Mon, 23 Apr 2012 08:15:57 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F1224@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<4F952441020000780007F33C@nat28.tlf.novell.com>
In-Reply-To: <4F952441020000780007F33C@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, April 23, 2012 3:43 PM
> To: Zhang, Yang Z; Keir Fraser; Tim Deegan
> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] lock in vhpet
> 
> >>> On 23.04.12 at 09:36, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> > The p2m lock in __get_gfn_type_access() is the culprit. Here is the
> > profiling data with 10 seconds:
> >
> > (XEN) p2m_lock 1 lock:
> > (XEN)   lock:      190733(00000000:14CE5726), block:
> > 67159(00000007:6AAA53F3)
> >
> > Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
> > blocked
> > 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is
> > waiting for the p2m lock. And those data only for idle guest. The
> > impaction is more seriously when run some workload inside guest.
> > I noticed that this change was adding by cs 24770. And before it, we
> > don't require the p2m lock in _get_gfn_type_access. So is this lock
> > really necessary?
> 
> Or shouldn't such a lock frequently taken on a read path be an rwlock instead?
> 
Right. Using rwlock would make more sense. 

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMERI-00086w-Rb; Mon, 23 Apr 2012 08:16:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMERG-00086r-VD
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:16:03 +0000
Received: from [85.158.138.51:57975] by server-3.bemta-3.messagelabs.com id
	15/A7-04048-2CF059F4; Mon, 23 Apr 2012 08:16:02 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335168960!23233408!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NDcw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27526 invoked from network); 23 Apr 2012 08:16:01 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 08:16:01 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Apr 2012 01:15:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="91998618"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 01:15:59 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 01:15:59 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 16:15:57 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Tim Deegan
	<tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQ//+AYID//3K4kA==
Date: Mon, 23 Apr 2012 08:15:57 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F1224@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<4F952441020000780007F33C@nat28.tlf.novell.com>
In-Reply-To: <4F952441020000780007F33C@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, April 23, 2012 3:43 PM
> To: Zhang, Yang Z; Keir Fraser; Tim Deegan
> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] lock in vhpet
> 
> >>> On 23.04.12 at 09:36, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> > The p2m lock in __get_gfn_type_access() is the culprit. Here is the
> > profiling data with 10 seconds:
> >
> > (XEN) p2m_lock 1 lock:
> > (XEN)   lock:      190733(00000000:14CE5726), block:
> > 67159(00000007:6AAA53F3)
> >
> > Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
> > blocked
> > 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is
> > waiting for the p2m lock. And those data only for idle guest. The
> > impaction is more seriously when run some workload inside guest.
> > I noticed that this change was adding by cs 24770. And before it, we
> > don't require the p2m lock in _get_gfn_type_access. So is this lock
> > really necessary?
> 
> Or shouldn't such a lock frequently taken on a read path be an rwlock instead?
> 
Right. Using rwlock would make more sense. 

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMEVi-0008FK-Pd; Mon, 23 Apr 2012 08:20:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMEVg-0008Ej-Kg
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 08:20:36 +0000
Received: from [85.158.143.35:5008] by server-2.bemta-4.messagelabs.com id
	D9/E6-17550-3D0159F4; Mon, 23 Apr 2012 08:20:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335169234!10044061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15563 invoked from network); 23 Apr 2012 08:20:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:20:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12071322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 08:20:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:20:32 +0100
Message-ID: <1335169230.30700.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Mon, 23 Apr 2012 09:20:30 +0100
In-Reply-To: <4F9508CA.7040709@xen.org>
References: <4F9508CA.7040709@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [XenARM] Xen Document Day Today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 08:46 +0100, Lars Kurth wrote:
> Good Morning,
> it is Xen Document Day today!
> Join us on IRC: freenode channel #xendocday
> More info: wiki.xen.org/wiki/Xen_Document_Day

NB, the above should actually be:
http://wiki.xen.org/wiki/Xen_Document_Days
(extra "s" on the end)

> TODO List: wiki.xen.org/wiki/Xen_Document_Days/TODO
> Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMEVi-0008FK-Pd; Mon, 23 Apr 2012 08:20:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMEVg-0008Ej-Kg
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 08:20:36 +0000
Received: from [85.158.143.35:5008] by server-2.bemta-4.messagelabs.com id
	D9/E6-17550-3D0159F4; Mon, 23 Apr 2012 08:20:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335169234!10044061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15563 invoked from network); 23 Apr 2012 08:20:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:20:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12071322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 08:20:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:20:32 +0100
Message-ID: <1335169230.30700.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Mon, 23 Apr 2012 09:20:30 +0100
In-Reply-To: <4F9508CA.7040709@xen.org>
References: <4F9508CA.7040709@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [XenARM] Xen Document Day Today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 08:46 +0100, Lars Kurth wrote:
> Good Morning,
> it is Xen Document Day today!
> Join us on IRC: freenode channel #xendocday
> More info: wiki.xen.org/wiki/Xen_Document_Day

NB, the above should actually be:
http://wiki.xen.org/wiki/Xen_Document_Days
(extra "s" on the end)

> TODO List: wiki.xen.org/wiki/Xen_Document_Days/TODO
> Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:23:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMEXz-00006V-0b; Mon, 23 Apr 2012 08:22:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMEXx-00006K-ML
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:22:57 +0000
Received: from [193.109.254.147:40958] by server-11.bemta-14.messagelabs.com
	id 97/8A-05858-161159F4; Mon, 23 Apr 2012 08:22:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335169376!5773813!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21239 invoked from network); 23 Apr 2012 08:22:56 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:22:56 -0000
Received: by eaal11 with SMTP id l11so4468862eaa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 01:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=srx/P4eMAT7OBVzBdJuZkk1cCwhvQJNfgO3rvNalKfA=;
	b=eHQhhdBTKdM2MbtlzS3meyQFt5VRObDsrgO/kjzv7xS4+nT1djI3TEBqBy8D2Ho9VL
	hoZc2HB5589etxOXgD54iuNDdT1zeX4uyPaFwLaFCgFPOoSWTI2UG308JsBxbQXqTS/f
	hrgZYaUzhnmNeAmxBkeFNeQklhO6yXAkghbMoraqADSljxrcEo3hwG268XTX8NSUEagf
	ZhvqBe5GS1nuNcYoNKkV0Ng6DQoHrPWWM8NyEzpPi7cFpnyQc4iG0kRU9LQcKRDOMitc
	ZmqAP/yWF4BVHcwlvgWYNy2hRoDZl1qxRLBHEjgioSNPdLt0QlH7GbefOvE2+EPf9pz5
	ZBvw==
Received: by 10.213.31.136 with SMTP id y8mr1182325ebc.276.1335169375977;
	Mon, 23 Apr 2012 01:22:55 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id n56sm67685973eeb.4.2012.04.23.01.22.51
	(version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 01:22:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Apr 2012 09:22:46 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CBBACFE6.313F8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQ//+AYID//3K4kP/+4aFQ
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F1224@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/04/2012 09:15, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

>>> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>>> blocked
>>> 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is
>>> waiting for the p2m lock. And those data only for idle guest. The
>>> impaction is more seriously when run some workload inside guest.
>>> I noticed that this change was adding by cs 24770. And before it, we
>>> don't require the p2m lock in _get_gfn_type_access. So is this lock
>>> really necessary?
>> 
>> Or shouldn't such a lock frequently taken on a read path be an rwlock
>> instead?
>> 
> Right. Using rwlock would make more sense.

Interested to see if it would improve performance. My guess would be no.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:23:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMEXz-00006V-0b; Mon, 23 Apr 2012 08:22:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMEXx-00006K-ML
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:22:57 +0000
Received: from [193.109.254.147:40958] by server-11.bemta-14.messagelabs.com
	id 97/8A-05858-161159F4; Mon, 23 Apr 2012 08:22:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335169376!5773813!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21239 invoked from network); 23 Apr 2012 08:22:56 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:22:56 -0000
Received: by eaal11 with SMTP id l11so4468862eaa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 01:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=srx/P4eMAT7OBVzBdJuZkk1cCwhvQJNfgO3rvNalKfA=;
	b=eHQhhdBTKdM2MbtlzS3meyQFt5VRObDsrgO/kjzv7xS4+nT1djI3TEBqBy8D2Ho9VL
	hoZc2HB5589etxOXgD54iuNDdT1zeX4uyPaFwLaFCgFPOoSWTI2UG308JsBxbQXqTS/f
	hrgZYaUzhnmNeAmxBkeFNeQklhO6yXAkghbMoraqADSljxrcEo3hwG268XTX8NSUEagf
	ZhvqBe5GS1nuNcYoNKkV0Ng6DQoHrPWWM8NyEzpPi7cFpnyQc4iG0kRU9LQcKRDOMitc
	ZmqAP/yWF4BVHcwlvgWYNy2hRoDZl1qxRLBHEjgioSNPdLt0QlH7GbefOvE2+EPf9pz5
	ZBvw==
Received: by 10.213.31.136 with SMTP id y8mr1182325ebc.276.1335169375977;
	Mon, 23 Apr 2012 01:22:55 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id n56sm67685973eeb.4.2012.04.23.01.22.51
	(version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 01:22:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Apr 2012 09:22:46 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CBBACFE6.313F8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQ//+AYID//3K4kP/+4aFQ
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F1224@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/04/2012 09:15, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

>>> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>>> blocked
>>> 30 seconds with 10 sec's profiling. It means 18% of cpu cycle is
>>> waiting for the p2m lock. And those data only for idle guest. The
>>> impaction is more seriously when run some workload inside guest.
>>> I noticed that this change was adding by cs 24770. And before it, we
>>> don't require the p2m lock in _get_gfn_type_access. So is this lock
>>> really necessary?
>> 
>> Or shouldn't such a lock frequently taken on a read path be an rwlock
>> instead?
>> 
> Right. Using rwlock would make more sense.

Interested to see if it would improve performance. My guess would be no.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:42:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMEqd-00019k-0b; Mon, 23 Apr 2012 08:42:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMEqc-00019c-27
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:42:14 +0000
Received: from [85.158.143.35:17801] by server-2.bemta-4.messagelabs.com id
	A1/7F-17550-5E5159F4; Mon, 23 Apr 2012 08:42:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335170532!10047792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18912 invoked from network); 23 Apr 2012 08:42:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:42:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12071912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 08:41:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:41:58 +0100
Message-ID: <1335170516.30700.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Mon, 23 Apr 2012 09:41:56 +0100
In-Reply-To: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> [...]

>  kernel = "/etc/xen/kernels/oi151a/unix"
>  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"

I forget how this works -- do you need to comment these out while using
pygrub or are these paths inside the ISO?
[...]
>  disk =
> [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> 'phy:/dev/dom0/oi_boot,xvda,w' ]
>  bootloader = "/usr/bin/pygrub"

Sadly I don't think xl is currently capable of booting using pygrub from
a file:/// type device.

I expect this will be resolved by Stefano's "qdisk local attach" series
which was on the list last week.

In the meantime as a workaround you could try using losetup on the iso
and pointing xl at phy:/dev/loop$N.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:42:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMEqd-00019k-0b; Mon, 23 Apr 2012 08:42:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMEqc-00019c-27
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:42:14 +0000
Received: from [85.158.143.35:17801] by server-2.bemta-4.messagelabs.com id
	A1/7F-17550-5E5159F4; Mon, 23 Apr 2012 08:42:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335170532!10047792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18912 invoked from network); 23 Apr 2012 08:42:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:42:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12071912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 08:41:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:41:58 +0100
Message-ID: <1335170516.30700.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Mon, 23 Apr 2012 09:41:56 +0100
In-Reply-To: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> [...]

>  kernel = "/etc/xen/kernels/oi151a/unix"
>  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"

I forget how this works -- do you need to comment these out while using
pygrub or are these paths inside the ISO?
[...]
>  disk =
> [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> 'phy:/dev/dom0/oi_boot,xvda,w' ]
>  bootloader = "/usr/bin/pygrub"

Sadly I don't think xl is currently capable of booting using pygrub from
a file:/// type device.

I expect this will be resolved by Stefano's "qdisk local attach" series
which was on the list last week.

In the meantime as a workaround you could try using losetup on the iso
and pointing xl at phy:/dev/loop$N.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:43:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMErM-0001DI-Fa; Mon, 23 Apr 2012 08:43:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMErL-0001D7-2i
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:42:59 +0000
Received: from [85.158.143.35:23452] by server-1.bemta-4.messagelabs.com id
	80/F7-20925-216159F4; Mon, 23 Apr 2012 08:42:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335170550!13908704!2
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12521 invoked from network); 23 Apr 2012 08:42:56 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-12.tower-21.messagelabs.com with SMTP;
	23 Apr 2012 08:42:56 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp209.alice.it (8.6.023.02)
	id 4EF08A630DAE5F2E for xen-devel@lists.xensource.com;
	Mon, 23 Apr 2012 10:42:56 +0200
Message-ID: <4F95160D.90902@tiscali.it>
Date: Mon, 23 Apr 2012 10:42:53 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH v2] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3983606311669709054=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============3983606311669709054==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020909000207020300090706"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020909000207020300090706
Content-Type: multipart/mixed;
 boundary="------------030201080206060008070002"

This is a multi-part message in MIME format.
--------------030201080206060008070002
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1335169615 -7200
# Node ID b3375cbe809eb8398b75cd2b1590b957134e01f8
# Parent  274e5accd62db09a7f703400c8720f7fdd95551a
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 274e5accd62d -r b3375cbe809e Makefile
--- a/Makefile    ven apr 20 09:49:06 2012 +0100
+++ b/Makefile    lun apr 23 10:26:55 2012 +0200
@@ -220,13 +220,13 @@
  uninstall: D=3D$(DESTDIR)
  uninstall:
      [ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR)=20
$(D)$(XEN_CONFIG_DIR).old-`date +%s` || true
-    rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+    rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains=20
$(D)$(CONFIG_DIR)/init.d/xend
+    rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons=20
$(D)$(CONFIG_DIR)/init.d/xen-watchdog
      rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
      rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+    rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
      rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
      rm -rf $(D)/boot/*xen*
      rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +236,16 @@
      rm -rf $(D)$(BINDIR)/pygrub
      rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
      rm -rf $(D)$(BINDIR)/xsls
-    rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+    rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+    rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+    rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+    rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
      rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
      rm -rf $(D)$(INCLUDEDIR)/xen
+    rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+    rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
      rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-    rm -rf $(D)$(LIBDIR)/libxenstore*
+    rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
      rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
      rm -rf $(D)$(LIBDIR)/xen/
      rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +253,7 @@
      rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
      rm -rf $(D)$(SHAREDIR)/doc/xen
      rm -rf $(D)$(SHAREDIR)/xen
+    rm -rf $(D)$(SHAREDIR)/qemu-xen
      rm -rf $(D)$(MAN1DIR)/xen*
      rm -rf $(D)$(MAN8DIR)/xen*
      rm -rf $(D)/boot/tboot*


--------------030201080206060008070002
Content-Type: text/plain; charset=windows-1252;
 name="make_uninstall_updates.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="make_uninstall_updates.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1335169615 -7200
# Node ID b3375cbe809eb8398b75cd2b1590b957134e01f8
# Parent  274e5accd62db09a7f703400c8720f7fdd95551a
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 274e5accd62d -r b3375cbe809e Makefile
--- a/Makefile	ven apr 20 09:49:06 2012 +0100
+++ b/Makefile	lun apr 23 10:26:55 2012 +0200
@@ -220,13 +220,13 @@
 uninstall: D=3D$(DESTDIR)
 uninstall:
 	[ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR) $(D)$(XEN_C=
ONFIG_DIR).old-`date +%s` || true
-	rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+	rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains $(D)$(CONFIG_DIR)/init.d/xen=
d
+	rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons $(D)$(CONFIG_DIR)/init.d/xen=
-watchdog
 	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
 	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+	rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
 	rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
 	rm -rf $(D)/boot/*xen*
 	rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +236,16 @@
 	rm -rf $(D)$(BINDIR)/pygrub
 	rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
 	rm -rf $(D)$(BINDIR)/xsls
-	rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+	rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+	rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+	rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+	rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
 	rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
 	rm -rf $(D)$(INCLUDEDIR)/xen
+	rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+	rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
 	rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-	rm -rf $(D)$(LIBDIR)/libxenstore*
+	rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
 	rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
 	rm -rf $(D)$(LIBDIR)/xen/
 	rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +253,7 @@
 	rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
 	rm -rf $(D)$(SHAREDIR)/doc/xen
 	rm -rf $(D)$(SHAREDIR)/xen
+	rm -rf $(D)$(SHAREDIR)/qemu-xen
 	rm -rf $(D)$(MAN1DIR)/xen*
 	rm -rf $(D)$(MAN8DIR)/xen*
 	rm -rf $(D)/boot/tboot*

--------------030201080206060008070002--

--------------ms020909000207020300090706
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQyMzA4NDI1M1owIwYJKoZIhvcNAQkEMRYEFHHYv95FITERPdYI6nqhM6sY
kBVeMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBAZ+AZiDSA+9dmOp8X+Q+2KCf9XRmsah0ZZjPBxuzI
LWkKRDZINTxAMGr+uPG/4blUe4H0du4HSqIR4McWnxameaZDn3xf9fIO5NgV3R31AKVXmWjE
agaLZQQvW78kLZuzQNI62jS757Qaowuv6mxSAhzHqhHD7nuj3DX7GGq6MxKaAcc7x0GHQq4S
UkSEQY0gMH3CHQ4YEnjvPHJ9Mtjv2krSKg1Zc8rGeMPUmXIuYQCLlTHa6ILj07jeSsx5Epqe
t/l//24lNI6SF95rJgsC+QwPgcN6AZV/Vw0hhoHtTGpjRxjomlAB9NVuKhlwSKr0P3/pbtKX
IemXZb7W9fxcAAAAAAAA
--------------ms020909000207020300090706--


--===============3983606311669709054==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3983606311669709054==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 08:43:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMErM-0001DI-Fa; Mon, 23 Apr 2012 08:43:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMErL-0001D7-2i
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:42:59 +0000
Received: from [85.158.143.35:23452] by server-1.bemta-4.messagelabs.com id
	80/F7-20925-216159F4; Mon, 23 Apr 2012 08:42:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335170550!13908704!2
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12521 invoked from network); 23 Apr 2012 08:42:56 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-12.tower-21.messagelabs.com with SMTP;
	23 Apr 2012 08:42:56 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp209.alice.it (8.6.023.02)
	id 4EF08A630DAE5F2E for xen-devel@lists.xensource.com;
	Mon, 23 Apr 2012 10:42:56 +0200
Message-ID: <4F95160D.90902@tiscali.it>
Date: Mon, 23 Apr 2012 10:42:53 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH v2] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3983606311669709054=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============3983606311669709054==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020909000207020300090706"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020909000207020300090706
Content-Type: multipart/mixed;
 boundary="------------030201080206060008070002"

This is a multi-part message in MIME format.
--------------030201080206060008070002
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1335169615 -7200
# Node ID b3375cbe809eb8398b75cd2b1590b957134e01f8
# Parent  274e5accd62db09a7f703400c8720f7fdd95551a
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 274e5accd62d -r b3375cbe809e Makefile
--- a/Makefile    ven apr 20 09:49:06 2012 +0100
+++ b/Makefile    lun apr 23 10:26:55 2012 +0200
@@ -220,13 +220,13 @@
  uninstall: D=3D$(DESTDIR)
  uninstall:
      [ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR)=20
$(D)$(XEN_CONFIG_DIR).old-`date +%s` || true
-    rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+    rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains=20
$(D)$(CONFIG_DIR)/init.d/xend
+    rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons=20
$(D)$(CONFIG_DIR)/init.d/xen-watchdog
      rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
      rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-    rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
      rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+    rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
      rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
      rm -rf $(D)/boot/*xen*
      rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +236,16 @@
      rm -rf $(D)$(BINDIR)/pygrub
      rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
      rm -rf $(D)$(BINDIR)/xsls
-    rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+    rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+    rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+    rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+    rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
      rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
      rm -rf $(D)$(INCLUDEDIR)/xen
+    rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+    rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
      rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-    rm -rf $(D)$(LIBDIR)/libxenstore*
+    rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
      rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
      rm -rf $(D)$(LIBDIR)/xen/
      rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +253,7 @@
      rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
      rm -rf $(D)$(SHAREDIR)/doc/xen
      rm -rf $(D)$(SHAREDIR)/xen
+    rm -rf $(D)$(SHAREDIR)/qemu-xen
      rm -rf $(D)$(MAN1DIR)/xen*
      rm -rf $(D)$(MAN8DIR)/xen*
      rm -rf $(D)/boot/tboot*


--------------030201080206060008070002
Content-Type: text/plain; charset=windows-1252;
 name="make_uninstall_updates.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="make_uninstall_updates.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1335169615 -7200
# Node ID b3375cbe809eb8398b75cd2b1590b957134e01f8
# Parent  274e5accd62db09a7f703400c8720f7fdd95551a
Makefile: Some updates to uninstall

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r 274e5accd62d -r b3375cbe809e Makefile
--- a/Makefile	ven apr 20 09:49:06 2012 +0100
+++ b/Makefile	lun apr 23 10:26:55 2012 +0200
@@ -220,13 +220,13 @@
 uninstall: D=3D$(DESTDIR)
 uninstall:
 	[ -d $(D)$(XEN_CONFIG_DIR) ] && mv -f $(D)$(XEN_CONFIG_DIR) $(D)$(XEN_C=
ONFIG_DIR).old-`date +%s` || true
-	rm -rf $(D)$(CONFIG_DIR)/init.d/xend*
+	rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains $(D)$(CONFIG_DIR)/init.d/xen=
d
+	rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons $(D)$(CONFIG_DIR)/init.d/xen=
-watchdog
 	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xen-backend.rules
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
-	rm -f  $(D)$(CONFIG_DIR)/udev/xend.rules
 	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+	rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
 	rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
 	rm -rf $(D)/boot/*xen*
 	rm -rf $(D)/lib/modules/*xen*
@@ -236,11 +236,16 @@
 	rm -rf $(D)$(BINDIR)/pygrub
 	rm -rf $(D)$(BINDIR)/setsize $(D)$(BINDIR)/tbctl
 	rm -rf $(D)$(BINDIR)/xsls
-	rm -rf $(D)$(INCLUDEDIR)/xenctrl.h $(D)$(INCLUDEDIR)/xenguest.h
+	rm -rf $(D)$(BINDIR)/xenstore* $(D)$(BINDIR)/xentrace*
+	rm -rf $(D)$(BINDIR)/xen-detect $(D)$(BINDIR)/xencons
+	rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen
+	rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h
 	rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h
 	rm -rf $(D)$(INCLUDEDIR)/xen
+	rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl*
+	rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h
 	rm -rf $(D)$(LIBDIR)/libxenctrl* $(D)$(LIBDIR)/libxenguest*
-	rm -rf $(D)$(LIBDIR)/libxenstore*
+	rm -rf $(D)$(LIBDIR)/libxenstore* $(D)$(LIBDIR)/libxlutil*
 	rm -rf $(D)$(LIBDIR)/python/xen $(D)$(LIBDIR)/python/grub
 	rm -rf $(D)$(LIBDIR)/xen/
 	rm -rf $(D)$(LIBEXEC)/xen*
@@ -248,6 +253,7 @@
 	rm -rf $(D)$(SBINDIR)/xen* $(D)$(SBINDIR)/netfix $(D)$(SBINDIR)/xm
 	rm -rf $(D)$(SHAREDIR)/doc/xen
 	rm -rf $(D)$(SHAREDIR)/xen
+	rm -rf $(D)$(SHAREDIR)/qemu-xen
 	rm -rf $(D)$(MAN1DIR)/xen*
 	rm -rf $(D)$(MAN8DIR)/xen*
 	rm -rf $(D)/boot/tboot*

--------------030201080206060008070002--

--------------ms020909000207020300090706
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQyMzA4NDI1M1owIwYJKoZIhvcNAQkEMRYEFHHYv95FITERPdYI6nqhM6sY
kBVeMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBAZ+AZiDSA+9dmOp8X+Q+2KCf9XRmsah0ZZjPBxuzI
LWkKRDZINTxAMGr+uPG/4blUe4H0du4HSqIR4McWnxameaZDn3xf9fIO5NgV3R31AKVXmWjE
agaLZQQvW78kLZuzQNI62jS757Qaowuv6mxSAhzHqhHD7nuj3DX7GGq6MxKaAcc7x0GHQq4S
UkSEQY0gMH3CHQ4YEnjvPHJ9Mtjv2krSKg1Zc8rGeMPUmXIuYQCLlTHa6ILj07jeSsx5Epqe
t/l//24lNI6SF95rJgsC+QwPgcN6AZV/Vw0hhoHtTGpjRxjomlAB9NVuKhlwSKr0P3/pbtKX
IemXZb7W9fxcAAAAAAAA
--------------ms020909000207020300090706--


--===============3983606311669709054==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3983606311669709054==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 08:43:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMErN-0001Db-Sf; Mon, 23 Apr 2012 08:43:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SMErM-0001DE-7i
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:43:00 +0000
Received: from [85.158.143.99:38608] by server-2.bemta-4.messagelabs.com id
	45/C0-17550-316159F4; Mon, 23 Apr 2012 08:42:59 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335170577!24481950!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26866 invoked from network); 23 Apr 2012 08:42:58 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 08:42:58 -0000
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com
	[209.85.212.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 56FA7DBC9A
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 16:42:40 +0800 (CST)
Received: by vbbfq11 with SMTP id fq11so9574292vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 01:42:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.9 with SMTP id eu9mr13084805vdb.28.1335170556934; Mon,
	23 Apr 2012 01:42:36 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Mon, 23 Apr 2012 01:42:36 -0700 (PDT)
In-Reply-To: <20120420164150.GC31062@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
Date: Mon, 23 Apr 2012 16:42:36 +0800
Message-ID: <CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 21, 2012 at 12:41 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Apr 20, 2012 at 01:38:28PM +0100, Ian Campbell wrote:
>> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
>> > On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
>> > > On 20/04/12 10:25, Lin Ming wrote:
>> > > > Implements xen_io_apic_read with hypercall, so it returns proper I=
O-APIC
>> > > > information instead of fabricated one.
>> > > >
>> > > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>> > > > ---
>> > > > =A0arch/x86/xen/apic.c | =A0 16 +++++++++++-----
>> > > > =A01 files changed, 11 insertions(+), 5 deletions(-)
>> > > >
>> > > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
>> > > > index aee16ab..f1f392d 100644
>> > > > --- a/arch/x86/xen/apic.c
>> > > > +++ b/arch/x86/xen/apic.c
>> > > > @@ -1,14 +1,20 @@
>> > > > =A0#include <linux/init.h>
>> > > > =A0#include <asm/x86_init.h>
>> > > > +#include <asm/apic.h>
>> > > > +#include <xen/interface/physdev.h>
>> > > > +#include <asm/xen/hypercall.h>
>> > > >
>> > > > =A0unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>> > > > =A0{
>> > > > - =A0 =A0 =A0 if (reg =3D=3D 0x1)
>> > > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
>> > > > - =A0 =A0 =A0 else if (reg =3D=3D 0x0)
>> > > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>> > > > + =A0 =A0 =A0 struct physdev_apic apic_op;
>> > > > + =A0 =A0 =A0 int ret;
>> > > >
>> > > > - =A0 =A0 =A0 return 0xff;
>> > > > + =A0 =A0 =A0 apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
>> > > > + =A0 =A0 =A0 apic_op.reg =3D reg;
>> > > > + =A0 =A0 =A0 ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &=
apic_op);
>> > > > + =A0 =A0 =A0 if (ret)
>> > > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ret;
>> > > > + =A0 =A0 =A0 return apic_op.value;
>> > >
>> > > Hypercall ret errors are negative, yet this function is unsigned. =
=A0Given
>> > > that the previous function had no possible way to fail, perhaps on e=
rror
>> > > you should fake up the values as before.
>> >
>> > How about return -1 on error?
>> > The calling function can check -1 for error.
>>
>> Isn't -1 potentially (at least theoretically) a valid value to read from
>> one of these registers?
>
> Yeah, but then we are back to crashing at bootup (with dom0) :-)
>
> Perhaps the fallback is to emulate (so retain some of the original code)
> as we have been since .. uh 3.0?

Do you mean the return value of io_apic_read in 3.0?
It's 0xffffffff.

Lin Ming

>
>>
>> Under what circumstances can these hypercalls fail? Would a BUG_ON be
>> appropriate/
>>
>> > unsigned int ret =3D apic_read(...);
>> > if (ret =3D=3D -1)
>> > =A0 =A0 //handle error.
>> >
>> > Thanks,
>> > Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:43:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMErN-0001Db-Sf; Mon, 23 Apr 2012 08:43:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SMErM-0001DE-7i
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 08:43:00 +0000
Received: from [85.158.143.99:38608] by server-2.bemta-4.messagelabs.com id
	45/C0-17550-316159F4; Mon, 23 Apr 2012 08:42:59 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335170577!24481950!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26866 invoked from network); 23 Apr 2012 08:42:58 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 08:42:58 -0000
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com
	[209.85.212.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 56FA7DBC9A
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 16:42:40 +0800 (CST)
Received: by vbbfq11 with SMTP id fq11so9574292vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 01:42:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.9 with SMTP id eu9mr13084805vdb.28.1335170556934; Mon,
	23 Apr 2012 01:42:36 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Mon, 23 Apr 2012 01:42:36 -0700 (PDT)
In-Reply-To: <20120420164150.GC31062@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
Date: Mon, 23 Apr 2012 16:42:36 +0800
Message-ID: <CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 21, 2012 at 12:41 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Apr 20, 2012 at 01:38:28PM +0100, Ian Campbell wrote:
>> On Fri, 2012-04-20 at 12:13 +0100, Lin Ming wrote:
>> > On Fri, 2012-04-20 at 10:58 +0100, Andrew Cooper wrote:
>> > > On 20/04/12 10:25, Lin Ming wrote:
>> > > > Implements xen_io_apic_read with hypercall, so it returns proper I=
O-APIC
>> > > > information instead of fabricated one.
>> > > >
>> > > > Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
>> > > > ---
>> > > > =A0arch/x86/xen/apic.c | =A0 16 +++++++++++-----
>> > > > =A01 files changed, 11 insertions(+), 5 deletions(-)
>> > > >
>> > > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
>> > > > index aee16ab..f1f392d 100644
>> > > > --- a/arch/x86/xen/apic.c
>> > > > +++ b/arch/x86/xen/apic.c
>> > > > @@ -1,14 +1,20 @@
>> > > > =A0#include <linux/init.h>
>> > > > =A0#include <asm/x86_init.h>
>> > > > +#include <asm/apic.h>
>> > > > +#include <xen/interface/physdev.h>
>> > > > +#include <asm/xen/hypercall.h>
>> > > >
>> > > > =A0unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>> > > > =A0{
>> > > > - =A0 =A0 =A0 if (reg =3D=3D 0x1)
>> > > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
>> > > > - =A0 =A0 =A0 else if (reg =3D=3D 0x0)
>> > > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>> > > > + =A0 =A0 =A0 struct physdev_apic apic_op;
>> > > > + =A0 =A0 =A0 int ret;
>> > > >
>> > > > - =A0 =A0 =A0 return 0xff;
>> > > > + =A0 =A0 =A0 apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
>> > > > + =A0 =A0 =A0 apic_op.reg =3D reg;
>> > > > + =A0 =A0 =A0 ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &=
apic_op);
>> > > > + =A0 =A0 =A0 if (ret)
>> > > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ret;
>> > > > + =A0 =A0 =A0 return apic_op.value;
>> > >
>> > > Hypercall ret errors are negative, yet this function is unsigned. =
=A0Given
>> > > that the previous function had no possible way to fail, perhaps on e=
rror
>> > > you should fake up the values as before.
>> >
>> > How about return -1 on error?
>> > The calling function can check -1 for error.
>>
>> Isn't -1 potentially (at least theoretically) a valid value to read from
>> one of these registers?
>
> Yeah, but then we are back to crashing at bootup (with dom0) :-)
>
> Perhaps the fallback is to emulate (so retain some of the original code)
> as we have been since .. uh 3.0?

Do you mean the return value of io_apic_read in 3.0?
It's 0xffffffff.

Lin Ming

>
>>
>> Under what circumstances can these hypercalls fail? Would a BUG_ON be
>> appropriate/
>>
>> > unsigned int ret =3D apic_read(...);
>> > if (ret =3D=3D -1)
>> > =A0 =A0 //handle error.
>> >
>> > Thanks,
>> > Lin Ming

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:54:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMF22-0001jy-F2; Mon, 23 Apr 2012 08:54:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMF20-0001jW-Si
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 08:54:01 +0000
Received: from [85.158.139.83:50092] by server-11.bemta-5.messagelabs.com id
	CA/D6-12959-6A8159F4; Mon, 23 Apr 2012 08:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335171238!21148582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7568 invoked from network); 23 Apr 2012 08:53:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12072215"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 08:53:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:53:57 +0100
Message-ID: <1335171236.30700.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Mon, 23 Apr 2012 09:53:56 +0100
In-Reply-To: <4F9199E5.5080409@xen.org>
References: <4F9199E5.5080409@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [XenARM] IMPORTANT: Changes to XenSummit Format :
	Please vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 18:16 +0100, Lars Kurth wrote:
> Hi everybody,
> 
> I have been talking to a number of the key contributors to the project 
> regarding XenSummit and got feedback on the format of XenSummit. Please 
> read, if you are active in the community and DO VOTE!
> 
> Cheers
> Lars
> 
> Change of date in CFP!
> ======================
> First I wanted to annouce that we are extending the CFP from May 1st to 
> 15th of June. Key community members felt that May 1 is too early. In 
> particular because we have closed the CFP 5-6 weeks before the event in 
> the past. Due to contractual issues June 15th is the last day we can do 
> though.
> 
> Proposal! PLEASE READ!
> ======================
> A number of vendors felt we should change the format of XenSummit to be 
> more like the Linux Kernel Summit. I.e.
> a) An invite only event for the top 20-30 developers of the project
> b) The main focus would be around finding technical solutions and making 
> decisions

IMHO this sort of event would make a great addition to the XenSummit
program rather than a replacement for it. i.e. a single day before the
main event (which remains two days).

> I can see the merit of this, but it is too late to do this for all of 
> XenSummit due to event contracts that havce been signed.
>
> However we have a number of options, moving towards this:
> 1) Start half a day early and have an invite only XenDev Event event on 
> Sunday afteroon
> 2) Cut XenSummit short by 1/2 day and append the XenDev event. This may 
> incur some financial penalties for Xen.org and the overall ticket cost 
> may have to be higher than in the past.
> 3) Do the invite only meeting in parallel with XenSummit. I have an 
> additional large room on TUE the 27th, which we could use for this and I 
> also have two break-out rooms and can allocate one of them to the XenDev 
> event (these were intended for people sitting together and hacking on 
> stuff and/or BoFs). There are several options: hold the XenDev event on
> 3.1) 26th afternoon
> 3.2) 27th morning
> 3.3) 27th afternoon
> 
> In my view option 1) and 3.1) have the advantage that we can report back 
> to XenSummit, that nobody will miss key talks and that people can sit 
> together in the break-out rooms.
> 
> Vote
> ====
> Please vote by providing. Vote closes by the 27th. Vote by replying to 
> this mail with ...
> -1: none of the above (i.e. I dont want a XenDev event)
> +1 for a DevMeeting on sunday (aka for proposal 1)
> +1 for cutting XenSummit short (aka for proposal 2)
> +1 for parallel 26th PM (aka proposal 3.1)
> +1 for parallel 27th AM (aka proposal 3.2)
> +1 for parallel 27th PM (aka proposal 3.3)

Family commitments prevent me attending this year so I'll abstain on the
specifics of the date this time around and vote on the general
principal:
+1 for a XenDev event to precede each XenSummit

Sorry for making up my own tick box ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 08:54:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 08:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMF22-0001jy-F2; Mon, 23 Apr 2012 08:54:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMF20-0001jW-Si
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 08:54:01 +0000
Received: from [85.158.139.83:50092] by server-11.bemta-5.messagelabs.com id
	CA/D6-12959-6A8159F4; Mon, 23 Apr 2012 08:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335171238!21148582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7568 invoked from network); 23 Apr 2012 08:53:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 08:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12072215"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 08:53:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:53:57 +0100
Message-ID: <1335171236.30700.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Mon, 23 Apr 2012 09:53:56 +0100
In-Reply-To: <4F9199E5.5080409@xen.org>
References: <4F9199E5.5080409@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [XenARM] IMPORTANT: Changes to XenSummit Format :
	Please vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 18:16 +0100, Lars Kurth wrote:
> Hi everybody,
> 
> I have been talking to a number of the key contributors to the project 
> regarding XenSummit and got feedback on the format of XenSummit. Please 
> read, if you are active in the community and DO VOTE!
> 
> Cheers
> Lars
> 
> Change of date in CFP!
> ======================
> First I wanted to annouce that we are extending the CFP from May 1st to 
> 15th of June. Key community members felt that May 1 is too early. In 
> particular because we have closed the CFP 5-6 weeks before the event in 
> the past. Due to contractual issues June 15th is the last day we can do 
> though.
> 
> Proposal! PLEASE READ!
> ======================
> A number of vendors felt we should change the format of XenSummit to be 
> more like the Linux Kernel Summit. I.e.
> a) An invite only event for the top 20-30 developers of the project
> b) The main focus would be around finding technical solutions and making 
> decisions

IMHO this sort of event would make a great addition to the XenSummit
program rather than a replacement for it. i.e. a single day before the
main event (which remains two days).

> I can see the merit of this, but it is too late to do this for all of 
> XenSummit due to event contracts that havce been signed.
>
> However we have a number of options, moving towards this:
> 1) Start half a day early and have an invite only XenDev Event event on 
> Sunday afteroon
> 2) Cut XenSummit short by 1/2 day and append the XenDev event. This may 
> incur some financial penalties for Xen.org and the overall ticket cost 
> may have to be higher than in the past.
> 3) Do the invite only meeting in parallel with XenSummit. I have an 
> additional large room on TUE the 27th, which we could use for this and I 
> also have two break-out rooms and can allocate one of them to the XenDev 
> event (these were intended for people sitting together and hacking on 
> stuff and/or BoFs). There are several options: hold the XenDev event on
> 3.1) 26th afternoon
> 3.2) 27th morning
> 3.3) 27th afternoon
> 
> In my view option 1) and 3.1) have the advantage that we can report back 
> to XenSummit, that nobody will miss key talks and that people can sit 
> together in the break-out rooms.
> 
> Vote
> ====
> Please vote by providing. Vote closes by the 27th. Vote by replying to 
> this mail with ...
> -1: none of the above (i.e. I dont want a XenDev event)
> +1 for a DevMeeting on sunday (aka for proposal 1)
> +1 for cutting XenSummit short (aka for proposal 2)
> +1 for parallel 26th PM (aka proposal 3.1)
> +1 for parallel 27th AM (aka proposal 3.2)
> +1 for parallel 27th PM (aka proposal 3.3)

Family commitments prevent me attending this year so I'll abstain on the
specifics of the date this time around and vote on the general
principal:
+1 for a XenDev event to precede each XenSummit

Sorry for making up my own tick box ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 09:15:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 09:15:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMFMC-0002MA-2u; Mon, 23 Apr 2012 09:14:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMFMA-0002M5-Lf
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 09:14:50 +0000
Received: from [193.109.254.147:9799] by server-8.bemta-14.messagelabs.com id
	C5/E8-23244-A8D159F4; Mon, 23 Apr 2012 09:14:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335172489!5804240!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4951 invoked from network); 23 Apr 2012 09:14:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 09:14:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMFM5-0004ja-V8; Mon, 23 Apr 2012 09:14:45 +0000
Date: Mon, 23 Apr 2012 10:14:45 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120423091445.GA17920@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
> The p2m lock in __get_gfn_type_access() is the culprit. Here is the profiling data with 10 seconds:
> 
> (XEN) p2m_lock 1 lock:
> (XEN)   lock:      190733(00000000:14CE5726), block:       67159(00000007:6AAA53F3)
> 
> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
> is waiting for the p2m lock. And those data only for idle guest. The
> impaction is more seriously when run some workload inside guest.  I
> noticed that this change was adding by cs 24770. And before it, we
> don't require the p2m lock in _get_gfn_type_access. So is this lock
> really necessary?

Ugh; that certainly is a regression.  We used to be lock-free on p2m
lookups and losing that will be bad for perf in lots of ways.  IIRC the
original aim was to use fine-grained per-page locks for this -- there
should be no need to hold a per-domain lock during a normal read.
Andres, what happened to that code?

Making it an rwlock would be tricky as this interface doesn't
differenctiate readers from writers.  For the common case (no
sharing/paging/mem-access) it ought to be a win since there is hardly
any writing.  But it would be better to make this particular lock/unlock
go away.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 09:15:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 09:15:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMFMC-0002MA-2u; Mon, 23 Apr 2012 09:14:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMFMA-0002M5-Lf
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 09:14:50 +0000
Received: from [193.109.254.147:9799] by server-8.bemta-14.messagelabs.com id
	C5/E8-23244-A8D159F4; Mon, 23 Apr 2012 09:14:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335172489!5804240!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4951 invoked from network); 23 Apr 2012 09:14:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 09:14:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMFM5-0004ja-V8; Mon, 23 Apr 2012 09:14:45 +0000
Date: Mon, 23 Apr 2012 10:14:45 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120423091445.GA17920@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
> The p2m lock in __get_gfn_type_access() is the culprit. Here is the profiling data with 10 seconds:
> 
> (XEN) p2m_lock 1 lock:
> (XEN)   lock:      190733(00000000:14CE5726), block:       67159(00000007:6AAA53F3)
> 
> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
> is waiting for the p2m lock. And those data only for idle guest. The
> impaction is more seriously when run some workload inside guest.  I
> noticed that this change was adding by cs 24770. And before it, we
> don't require the p2m lock in _get_gfn_type_access. So is this lock
> really necessary?

Ugh; that certainly is a regression.  We used to be lock-free on p2m
lookups and losing that will be bad for perf in lots of ways.  IIRC the
original aim was to use fine-grained per-page locks for this -- there
should be no need to hold a per-domain lock during a normal read.
Andres, what happened to that code?

Making it an rwlock would be tricky as this interface doesn't
differenctiate readers from writers.  For the common case (no
sharing/paging/mem-access) it ought to be a win since there is hardly
any writing.  But it would be better to make this particular lock/unlock
go away.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 09:46:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 09:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMFqn-0002fV-VC; Mon, 23 Apr 2012 09:46:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMFql-0002fM-F3
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 09:46:28 +0000
Received: from [85.158.143.35:29642] by server-3.bemta-4.messagelabs.com id
	3A/70-05853-2F4259F4; Mon, 23 Apr 2012 09:46:26 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335174384!12217227!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22344 invoked from network); 23 Apr 2012 09:46:25 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 09:46:25 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 1FB961C14001;
	Mon, 23 Apr 2012 11:46:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=G7Tw8Wnaw2mZvZhNn9WejGe5nR8=; b=sq
	3z68nzexIf9ivTvnQdDOowAgPkVmqRy5lx1KJrrAx6yfBHDP2jtPT7GnuvR2EOrH
	Yko/SjgU0z6hmcqmV04uUo54+EjsSPKjYtszRFEqW4CX+jf7eNLrXjotUEWe6Isq
	lko7ZCYZinpCzbtMYq4eP0pG2E1P28VCFhW1cxhOA+ovbqwD4D/Ygpo0bmHpit7I
	Zzc7hZE8Cfiovh26ZAgziSpbc4tcmmLE2/ciY9ru9c2Onw5glsnK6LhrsLlPvG9s
	RgHnnZZtkHr4lv7p2ROtq0BRg/g6V6nMUhSS4KCSHiw+ENe5q9lJYenjjwWj9zOE
	d91ytga2/qM+vGJNjjsy5iHQZeddl/pMmJyhIaE6YNr19kE1U+4XPd1Y2/ELZkrG
	mNlmjuTEZZ+uDTxCVlSmyWheP6/5MCn/JrfqUWhp2SAREPfnYAYblgVRrL/Xq2oj
	mAI/hx7AacxlCBDHToxyXzaVK4Mh+alo9Gadn0tX0lYTn7kkCHODF6jN2I1THx9f
	gpKZYfMOOByUDhqZNnJyQvm6vrwvBNHTWUdsMTyZodJ4440e5z10IA7bJUz4r4Z4
	PnUg1PMwtd+hcf0d5rx5Lc7djdMmdhZ2XlMWpQrgFE7JwHdsRQxyGLnilKwsJ0M8
	KkzCfa5OHrKl4vmJq0StIX8WHadFe0zLT4AAMMyws=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id EC5501C14002; Mon, 23 Apr 2012 11:46:23 +0200 (CEST)
Date: Mon, 23 Apr 2012 11:46:23 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120423094623.GA13565@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5"
Content-Disposition: inline
In-Reply-To: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Dieter Bloms <xensource.com@bloms.de>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Ian,

I've made a little patch to set the cpu_weight for credit, credit2 and
sedf scheduler from the config file.

Btw.: for the sedf scheduler there seems to be some type mismatch. =20
The functions xc_sedf_domain_set and xc_sedf_domain_get expect the type
'uint16_t' for variables 'extratime' and 'weight' while the structure
'xen_domctl_sched_sedf' defines the type uint32_t for them.
I think they should be the same, or not ?

Anyway, I've tested this patch for the credit scheduler and it works so
far.


On Fri, Apr 20, Ian Campbell wrote:

> Hi Dieter,=20
>=20
> thanks for the report.
>=20
> It seems that support for this config file variable is not present in xl
> at the moment. We should try and add this for 4.2 IMHO.
>=20
> If you know a little bit of C (or are interested in learning) then this
> should be a pretty simple thing to implement -- please let me know if
> you want more details.
>=20
> Ian.
>=20
> On Fri, 2012-04-20 at 16:00 +0100, Dieter Bloms wrote:
> > Hi,
> >=20
> > I've installed xen-unstable 4.2 from actual git (last commit was
> > 4dc7dbef5400f0608321d579aebb57f933e8f707).
> >=20
> > When I start a domU with xm all is fine include the cpu_weight I
> > configured in my domU config.
> >=20
> > When I start the domU with xl then all my domU have the default
> > cpu_weight of 256 instead of the configured one.
> >=20
> > Was the name of cpu_weight being changed for xl command ?
> >=20
> > My domU config looks like this:
> >=20
> > --snip--
> > name=3D"vdrserver"
> > description=3D"vdrserver for my clients"
> > memory=3D768
> > maxmem=3D2048
> > vcpus=3D1
> > cpus=3D"1"
> > cpu_weight =3D 128
> > on_poweroff=3D"destroy"
> > on_reboot=3D"restart"
> > on_crash=3D"destroy"
> >=20
> > localtime=3D0
> > keymap=3D"de"
> >=20
> > builder=3D"linux"
> > bootloader=3D"/usr/bin/pygrub"
> > bootargs=3D""
> > extra=3D"console=3Dhvc0 tmem cgroup_disable=3Dmemory independent_wallcl=
ock=3D1 iommu=3Dsoft"
> > nographic=3D1
> > keymap =3D 'de'
> >=20
> > disk=3D[=20
> >   'phy:/dev/mapper/xenimages-vdrserver,xvda1,w',
> >   'phy:/dev/mapper/xenimages-swap_vdrserver,xvda2,w',
> > ]
> > vif=3D[ 'mac=3D00:00:00:00:00:80,bridge=3Dbr0', ]
> >=20
> > pci =3D [ '06:00.0', '06:01.0', '00:12.2', '00:13.2']
> > --snip--
> >=20
> >=20
>=20
>=20
>=20
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

--=20
Gru=DF

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--bg08WKrSYDhXBjb5
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..706e282 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -110,6 +110,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         return ERROR_INVAL;
     }
 
+    if (!b_info->weight)
+        b_info->weight = 256;
+    if (!b_info->cap)
+        b_info->cap = 0;
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..f858a42 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -65,9 +65,38 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
     char *xs_domid, *con_domid;
+    libxl_scheduler sched;
+    struct xen_domctl_scheduler_op sched_op;
+
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
+
+    sched = libxl_get_scheduler (ctx);
+    
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      xc_sedf_domain_get (ctx->xch, domid, &(sched_op.u.sedf.period), &(sched_op.u.sedf.slice), &(sched_op.u.sedf.latency), (uint16_t *) &(sched_op.u.sedf.extratime), (uint16_t *) &(sched_op.u.sedf.weight));
+      sched_op.u.sedf.weight = info->weight;
+      xc_sedf_domain_set (ctx->xch, domid, sched_op.u.sedf.period, sched_op.u.sedf.slice, sched_op.u.sedf.latency, (uint16_t) sched_op.u.sedf.extratime, (uint16_t) sched_op.u.sedf.weight);
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+//      struct xen_domctl_sched_credit sdom;
+      sched_op.u.credit.weight = info->weight;
+      sched_op.u.credit.cap = info->cap;
+      xc_sched_credit_domain_set(ctx->xch, domid, &(sched_op.u.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      sched_op.u.credit2.weight = info->weight;
+      xc_sched_credit2_domain_set(ctx->xch, domid, &(sched_op.u.credit2));
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      break;
+    default:
+        abort();
+    }
+
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..f185d4c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -232,6 +232,8 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("weight",          integer),
+    ("cap",             integer),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..d7dcb84 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,11 @@ static void parse_config_data(const char *configfile_filename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->weight = l;
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->cap = l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;

--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bg08WKrSYDhXBjb5--


From xen-devel-bounces@lists.xen.org Mon Apr 23 09:46:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 09:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMFqn-0002fV-VC; Mon, 23 Apr 2012 09:46:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMFql-0002fM-F3
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 09:46:28 +0000
Received: from [85.158.143.35:29642] by server-3.bemta-4.messagelabs.com id
	3A/70-05853-2F4259F4; Mon, 23 Apr 2012 09:46:26 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335174384!12217227!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22344 invoked from network); 23 Apr 2012 09:46:25 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 09:46:25 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 1FB961C14001;
	Mon, 23 Apr 2012 11:46:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=G7Tw8Wnaw2mZvZhNn9WejGe5nR8=; b=sq
	3z68nzexIf9ivTvnQdDOowAgPkVmqRy5lx1KJrrAx6yfBHDP2jtPT7GnuvR2EOrH
	Yko/SjgU0z6hmcqmV04uUo54+EjsSPKjYtszRFEqW4CX+jf7eNLrXjotUEWe6Isq
	lko7ZCYZinpCzbtMYq4eP0pG2E1P28VCFhW1cxhOA+ovbqwD4D/Ygpo0bmHpit7I
	Zzc7hZE8Cfiovh26ZAgziSpbc4tcmmLE2/ciY9ru9c2Onw5glsnK6LhrsLlPvG9s
	RgHnnZZtkHr4lv7p2ROtq0BRg/g6V6nMUhSS4KCSHiw+ENe5q9lJYenjjwWj9zOE
	d91ytga2/qM+vGJNjjsy5iHQZeddl/pMmJyhIaE6YNr19kE1U+4XPd1Y2/ELZkrG
	mNlmjuTEZZ+uDTxCVlSmyWheP6/5MCn/JrfqUWhp2SAREPfnYAYblgVRrL/Xq2oj
	mAI/hx7AacxlCBDHToxyXzaVK4Mh+alo9Gadn0tX0lYTn7kkCHODF6jN2I1THx9f
	gpKZYfMOOByUDhqZNnJyQvm6vrwvBNHTWUdsMTyZodJ4440e5z10IA7bJUz4r4Z4
	PnUg1PMwtd+hcf0d5rx5Lc7djdMmdhZ2XlMWpQrgFE7JwHdsRQxyGLnilKwsJ0M8
	KkzCfa5OHrKl4vmJq0StIX8WHadFe0zLT4AAMMyws=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id EC5501C14002; Mon, 23 Apr 2012 11:46:23 +0200 (CEST)
Date: Mon, 23 Apr 2012 11:46:23 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120423094623.GA13565@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5"
Content-Disposition: inline
In-Reply-To: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Dieter Bloms <xensource.com@bloms.de>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Ian,

I've made a little patch to set the cpu_weight for credit, credit2 and
sedf scheduler from the config file.

Btw.: for the sedf scheduler there seems to be some type mismatch. =20
The functions xc_sedf_domain_set and xc_sedf_domain_get expect the type
'uint16_t' for variables 'extratime' and 'weight' while the structure
'xen_domctl_sched_sedf' defines the type uint32_t for them.
I think they should be the same, or not ?

Anyway, I've tested this patch for the credit scheduler and it works so
far.


On Fri, Apr 20, Ian Campbell wrote:

> Hi Dieter,=20
>=20
> thanks for the report.
>=20
> It seems that support for this config file variable is not present in xl
> at the moment. We should try and add this for 4.2 IMHO.
>=20
> If you know a little bit of C (or are interested in learning) then this
> should be a pretty simple thing to implement -- please let me know if
> you want more details.
>=20
> Ian.
>=20
> On Fri, 2012-04-20 at 16:00 +0100, Dieter Bloms wrote:
> > Hi,
> >=20
> > I've installed xen-unstable 4.2 from actual git (last commit was
> > 4dc7dbef5400f0608321d579aebb57f933e8f707).
> >=20
> > When I start a domU with xm all is fine include the cpu_weight I
> > configured in my domU config.
> >=20
> > When I start the domU with xl then all my domU have the default
> > cpu_weight of 256 instead of the configured one.
> >=20
> > Was the name of cpu_weight being changed for xl command ?
> >=20
> > My domU config looks like this:
> >=20
> > --snip--
> > name=3D"vdrserver"
> > description=3D"vdrserver for my clients"
> > memory=3D768
> > maxmem=3D2048
> > vcpus=3D1
> > cpus=3D"1"
> > cpu_weight =3D 128
> > on_poweroff=3D"destroy"
> > on_reboot=3D"restart"
> > on_crash=3D"destroy"
> >=20
> > localtime=3D0
> > keymap=3D"de"
> >=20
> > builder=3D"linux"
> > bootloader=3D"/usr/bin/pygrub"
> > bootargs=3D""
> > extra=3D"console=3Dhvc0 tmem cgroup_disable=3Dmemory independent_wallcl=
ock=3D1 iommu=3Dsoft"
> > nographic=3D1
> > keymap =3D 'de'
> >=20
> > disk=3D[=20
> >   'phy:/dev/mapper/xenimages-vdrserver,xvda1,w',
> >   'phy:/dev/mapper/xenimages-swap_vdrserver,xvda2,w',
> > ]
> > vif=3D[ 'mac=3D00:00:00:00:00:80,bridge=3Dbr0', ]
> >=20
> > pci =3D [ '06:00.0', '06:01.0', '00:12.2', '00:13.2']
> > --snip--
> >=20
> >=20
>=20
>=20
>=20
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

--=20
Gru=DF

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--bg08WKrSYDhXBjb5
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e63c7bd..706e282 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -110,6 +110,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         return ERROR_INVAL;
     }
 
+    if (!b_info->weight)
+        b_info->weight = 256;
+    if (!b_info->cap)
+        b_info->cap = 0;
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..f858a42 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -65,9 +65,38 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
     char *xs_domid, *con_domid;
+    libxl_scheduler sched;
+    struct xen_domctl_scheduler_op sched_op;
+
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
+
+    sched = libxl_get_scheduler (ctx);
+    
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      xc_sedf_domain_get (ctx->xch, domid, &(sched_op.u.sedf.period), &(sched_op.u.sedf.slice), &(sched_op.u.sedf.latency), (uint16_t *) &(sched_op.u.sedf.extratime), (uint16_t *) &(sched_op.u.sedf.weight));
+      sched_op.u.sedf.weight = info->weight;
+      xc_sedf_domain_set (ctx->xch, domid, sched_op.u.sedf.period, sched_op.u.sedf.slice, sched_op.u.sedf.latency, (uint16_t) sched_op.u.sedf.extratime, (uint16_t) sched_op.u.sedf.weight);
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+//      struct xen_domctl_sched_credit sdom;
+      sched_op.u.credit.weight = info->weight;
+      sched_op.u.credit.cap = info->cap;
+      xc_sched_credit_domain_set(ctx->xch, domid, &(sched_op.u.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      sched_op.u.credit2.weight = info->weight;
+      xc_sched_credit2_domain_set(ctx->xch, domid, &(sched_op.u.credit2));
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      break;
+    default:
+        abort();
+    }
+
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..f185d4c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -232,6 +232,8 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("weight",          integer),
+    ("cap",             integer),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..d7dcb84 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,11 @@ static void parse_config_data(const char *configfile_filename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->weight = l;
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->cap = l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;

--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bg08WKrSYDhXBjb5--


From xen-devel-bounces@lists.xen.org Mon Apr 23 10:03:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 10:03:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMG6Q-0003Ea-FJ; Mon, 23 Apr 2012 10:02:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMG6P-0003EU-6R
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 10:02:37 +0000
Received: from [85.158.143.99:31182] by server-3.bemta-4.messagelabs.com id
	E0/11-05853-CB8259F4; Mon, 23 Apr 2012 10:02:36 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335175355!15062156!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6306 invoked from network); 23 Apr 2012 10:02:35 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-8.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 10:02:35 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id CC74AD34747
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 12:02:34 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 2fN962HcCexa for <xen-devel@lists.xen.org>;
	Mon, 23 Apr 2012 12:02:28 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 7A096D3462F
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 12:02:28 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 12:02:27 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201204231202.27731.tobias.geiger@vido.info>
Subject: [Xen-devel] Degregated I/O Performance since 3.4 - Regression in
	3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello!

i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4 
tested) as Dom0 Kernel;

With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers 
(gplpv_Vista2008x64_0.11.0.357.msi); 
With 3.4 it drops to about a third of that.

Xen Version is xen-unstable: 
xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c

Disk config line is:
disk = [ '/dev/vg_ssd/win7system,,hda' ] 
- it uses blkback.

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 10:03:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 10:03:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMG6Q-0003Ea-FJ; Mon, 23 Apr 2012 10:02:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMG6P-0003EU-6R
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 10:02:37 +0000
Received: from [85.158.143.99:31182] by server-3.bemta-4.messagelabs.com id
	E0/11-05853-CB8259F4; Mon, 23 Apr 2012 10:02:36 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335175355!15062156!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6306 invoked from network); 23 Apr 2012 10:02:35 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-8.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 10:02:35 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id CC74AD34747
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 12:02:34 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 2fN962HcCexa for <xen-devel@lists.xen.org>;
	Mon, 23 Apr 2012 12:02:28 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 7A096D3462F
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 12:02:28 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 12:02:27 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201204231202.27731.tobias.geiger@vido.info>
Subject: [Xen-devel] Degregated I/O Performance since 3.4 - Regression in
	3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello!

i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4 
tested) as Dom0 Kernel;

With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers 
(gplpv_Vista2008x64_0.11.0.357.msi); 
With 3.4 it drops to about a third of that.

Xen Version is xen-unstable: 
xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c

Disk config line is:
disk = [ '/dev/vg_ssd/win7system,,hda' ] 
- it uses blkback.

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 10:24:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 10:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMGQv-0003Tk-Ku; Mon, 23 Apr 2012 10:23:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMGQu-0003Td-8Y
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 10:23:48 +0000
Received: from [193.109.254.147:31846] by server-7.bemta-14.messagelabs.com id
	24/F7-01627-3BD259F4; Mon, 23 Apr 2012 10:23:47 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335176626!5854728!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4307 invoked from network); 23 Apr 2012 10:23:46 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-8.tower-27.messagelabs.com with SMTP;
	23 Apr 2012 10:23:46 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 69B32D34747;
	Mon, 23 Apr 2012 12:23:46 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id vFehoJrSC1fE; Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 0C698D3462F;
	Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 12:23:39 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201109090950.05043.muehlenhoff@univention.de>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
	<4F819645.4060404@vido.info>
In-Reply-To: <4F819645.4060404@vido.info>
MIME-Version: 1.0
Message-Id: <201204231223.40078.tobias.geiger@vido.info>
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

just FYI: since i updated my nearly one-year old xen-unstable checkout, it 
turned out that my strange GPL-PV Performance issue went away: 
With (gplpv_Vista2008x64_0.11.0.357.msi) i get much better performance with 
GPLPV than without - regardless of PCI-Passthrough.

What i observed though: I get about exactly "half" the performance (Disk-IO) 
in my PV-HVM than i get in my Dom0: In Dom0 i read/write with about 300mb/s , 
in DomU its about 150mb/s;
Also (but not exactly messured) i noticed double the RTT value when pinging 
the DomU in comparsion to the RTT when pinging Dom0;

I wonder what it makes perform more or less exactly "half" as Dom0 ?

Greetings
Tobias

Am Sonntag, 8. April 2012, 15:44:37 schrieb Tobias Geiger:
> Hi James,
> 
> I used "http://www.heise.de/download/as-ssd-benchmark.html" (sorry -
> german website), but i remember similar results with the famous "HD Tune
> Pro" tool...
> 
> Nowhere here DRBD is involved - sorry; the disk line refers to a phy lvm
> disk which is directly on a block device (ssd).
> 
> But i can test with debug build if you still think this (what?) is an
> issue here - tell me if you want to see that!
> 
> Greetings - and happy Easter!
> Tobias
> 
> Am 06.04.2012 12:56, schrieb James Harper:
> >> glad you ask - because just yesterday i re-tested the 357-version of the
> >> drivers under Windows7 64bit HVM guest - here are the results:
> >> 
> >> (everyting in mb/s)
> >> 
> >> W/O gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 311.8
> >> Seq. writing:  106.3
> >> 4k    reading: 10.2
> >> 4k    writing:   9.3
> >> 4k64thread reading: 11.1
> >> 4k64threads writing: 10.9
> >> 
> >> 
> >> WITH gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 98.8
> >> Seq. writing:  31.6
> >> 4k    reading: 12.0
> >> 4k    writing:  19.3
> >> 4k64thread reading: 15.4
> >> 4k64threads writing: 29.6
> >> 
> >> 
> >> WITH gplpv-drivers and WITHOUT pci-passthrough:
> >> 
> >> Seq. reading: 104.4
> >> Seq. writing:   85.2
> >> 4k    reading:  12.7
> >> 4k    writing:   20.4
> >> 4k64thread reading: 16.6
> >> 4k64threads writing: 32.6
> >> 
> >> 
> >> Strange thing is, that even without pci-passthrough the performance with
> >> gplpv is'nt that much better compared to w/o gplpv but with
> >> pci-passthrough - well it is overall a bit better, but just a bit, and
> >> seq. read performance is much worse...
> >> i haven't made a test without gplpv and without passthrough at the same
> >> time - tell me if you want to see how that performs.
> >> 
> >> Greetings!
> >> Tobias
> >> 
> >> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this
> >> tests.
> > 
> > What are you testing this with? I just ran some tests with iometer under
> > 2008R2 and it reminded me of something... DRBD *hates* having
> > outstanding writes to the same block, and complains about it, so gplpv
> > serialises such requests (stalling the queue until the first request is
> > complete). This almost never happens in production but iometer sends
> > such requests frequently, which will significantly impact performance.
> > 
> > You can test with the debug build to see if this is happening with
> > whatever you are testing with - you'll see messages like "Concurrent
> > outstanding write detected". Be aware though that qemu will rate limit
> > writes to the debug log so if it happens a lot (like under iometer) it
> > will slow to a crawl.
> > 
> > James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 10:24:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 10:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMGQv-0003Tk-Ku; Mon, 23 Apr 2012 10:23:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMGQu-0003Td-8Y
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 10:23:48 +0000
Received: from [193.109.254.147:31846] by server-7.bemta-14.messagelabs.com id
	24/F7-01627-3BD259F4; Mon, 23 Apr 2012 10:23:47 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335176626!5854728!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4307 invoked from network); 23 Apr 2012 10:23:46 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-8.tower-27.messagelabs.com with SMTP;
	23 Apr 2012 10:23:46 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 69B32D34747;
	Mon, 23 Apr 2012 12:23:46 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id vFehoJrSC1fE; Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 0C698D3462F;
	Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 12:23:39 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201109090950.05043.muehlenhoff@univention.de>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
	<4F819645.4060404@vido.info>
In-Reply-To: <4F819645.4060404@vido.info>
MIME-Version: 1.0
Message-Id: <201204231223.40078.tobias.geiger@vido.info>
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

just FYI: since i updated my nearly one-year old xen-unstable checkout, it 
turned out that my strange GPL-PV Performance issue went away: 
With (gplpv_Vista2008x64_0.11.0.357.msi) i get much better performance with 
GPLPV than without - regardless of PCI-Passthrough.

What i observed though: I get about exactly "half" the performance (Disk-IO) 
in my PV-HVM than i get in my Dom0: In Dom0 i read/write with about 300mb/s , 
in DomU its about 150mb/s;
Also (but not exactly messured) i noticed double the RTT value when pinging 
the DomU in comparsion to the RTT when pinging Dom0;

I wonder what it makes perform more or less exactly "half" as Dom0 ?

Greetings
Tobias

Am Sonntag, 8. April 2012, 15:44:37 schrieb Tobias Geiger:
> Hi James,
> 
> I used "http://www.heise.de/download/as-ssd-benchmark.html" (sorry -
> german website), but i remember similar results with the famous "HD Tune
> Pro" tool...
> 
> Nowhere here DRBD is involved - sorry; the disk line refers to a phy lvm
> disk which is directly on a block device (ssd).
> 
> But i can test with debug build if you still think this (what?) is an
> issue here - tell me if you want to see that!
> 
> Greetings - and happy Easter!
> Tobias
> 
> Am 06.04.2012 12:56, schrieb James Harper:
> >> glad you ask - because just yesterday i re-tested the 357-version of the
> >> drivers under Windows7 64bit HVM guest - here are the results:
> >> 
> >> (everyting in mb/s)
> >> 
> >> W/O gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 311.8
> >> Seq. writing:  106.3
> >> 4k    reading: 10.2
> >> 4k    writing:   9.3
> >> 4k64thread reading: 11.1
> >> 4k64threads writing: 10.9
> >> 
> >> 
> >> WITH gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 98.8
> >> Seq. writing:  31.6
> >> 4k    reading: 12.0
> >> 4k    writing:  19.3
> >> 4k64thread reading: 15.4
> >> 4k64threads writing: 29.6
> >> 
> >> 
> >> WITH gplpv-drivers and WITHOUT pci-passthrough:
> >> 
> >> Seq. reading: 104.4
> >> Seq. writing:   85.2
> >> 4k    reading:  12.7
> >> 4k    writing:   20.4
> >> 4k64thread reading: 16.6
> >> 4k64threads writing: 32.6
> >> 
> >> 
> >> Strange thing is, that even without pci-passthrough the performance with
> >> gplpv is'nt that much better compared to w/o gplpv but with
> >> pci-passthrough - well it is overall a bit better, but just a bit, and
> >> seq. read performance is much worse...
> >> i haven't made a test without gplpv and without passthrough at the same
> >> time - tell me if you want to see how that performs.
> >> 
> >> Greetings!
> >> Tobias
> >> 
> >> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this
> >> tests.
> > 
> > What are you testing this with? I just ran some tests with iometer under
> > 2008R2 and it reminded me of something... DRBD *hates* having
> > outstanding writes to the same block, and complains about it, so gplpv
> > serialises such requests (stalling the queue until the first request is
> > complete). This almost never happens in production but iometer sends
> > such requests frequently, which will significantly impact performance.
> > 
> > You can test with the debug build to see if this is happening with
> > whatever you are testing with - you'll see messages like "Concurrent
> > outstanding write detected". Be aware though that qemu will rate limit
> > writes to the debug log so if it happens a lot (like under iometer) it
> > will slow to a crawl.
> > 
> > James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 10:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 10:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMGR1-0003U5-1U; Mon, 23 Apr 2012 10:23:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMGQz-0003Tu-9d
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:23:53 +0000
Received: from [85.158.143.35:3253] by server-3.bemta-4.messagelabs.com id
	E9/6B-05853-8BD259F4; Mon, 23 Apr 2012 10:23:52 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335176626!11197562!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9369 invoked from network); 23 Apr 2012 10:23:46 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-21.messagelabs.com with SMTP;
	23 Apr 2012 10:23:46 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 69B32D34747;
	Mon, 23 Apr 2012 12:23:46 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id vFehoJrSC1fE; Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 0C698D3462F;
	Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 12:23:39 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201109090950.05043.muehlenhoff@univention.de>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
	<4F819645.4060404@vido.info>
In-Reply-To: <4F819645.4060404@vido.info>
MIME-Version: 1.0
Message-Id: <201204231223.40078.tobias.geiger@vido.info>
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

just FYI: since i updated my nearly one-year old xen-unstable checkout, it 
turned out that my strange GPL-PV Performance issue went away: 
With (gplpv_Vista2008x64_0.11.0.357.msi) i get much better performance with 
GPLPV than without - regardless of PCI-Passthrough.

What i observed though: I get about exactly "half" the performance (Disk-IO) 
in my PV-HVM than i get in my Dom0: In Dom0 i read/write with about 300mb/s , 
in DomU its about 150mb/s;
Also (but not exactly messured) i noticed double the RTT value when pinging 
the DomU in comparsion to the RTT when pinging Dom0;

I wonder what it makes perform more or less exactly "half" as Dom0 ?

Greetings
Tobias

Am Sonntag, 8. April 2012, 15:44:37 schrieb Tobias Geiger:
> Hi James,
> 
> I used "http://www.heise.de/download/as-ssd-benchmark.html" (sorry -
> german website), but i remember similar results with the famous "HD Tune
> Pro" tool...
> 
> Nowhere here DRBD is involved - sorry; the disk line refers to a phy lvm
> disk which is directly on a block device (ssd).
> 
> But i can test with debug build if you still think this (what?) is an
> issue here - tell me if you want to see that!
> 
> Greetings - and happy Easter!
> Tobias
> 
> Am 06.04.2012 12:56, schrieb James Harper:
> >> glad you ask - because just yesterday i re-tested the 357-version of the
> >> drivers under Windows7 64bit HVM guest - here are the results:
> >> 
> >> (everyting in mb/s)
> >> 
> >> W/O gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 311.8
> >> Seq. writing:  106.3
> >> 4k    reading: 10.2
> >> 4k    writing:   9.3
> >> 4k64thread reading: 11.1
> >> 4k64threads writing: 10.9
> >> 
> >> 
> >> WITH gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 98.8
> >> Seq. writing:  31.6
> >> 4k    reading: 12.0
> >> 4k    writing:  19.3
> >> 4k64thread reading: 15.4
> >> 4k64threads writing: 29.6
> >> 
> >> 
> >> WITH gplpv-drivers and WITHOUT pci-passthrough:
> >> 
> >> Seq. reading: 104.4
> >> Seq. writing:   85.2
> >> 4k    reading:  12.7
> >> 4k    writing:   20.4
> >> 4k64thread reading: 16.6
> >> 4k64threads writing: 32.6
> >> 
> >> 
> >> Strange thing is, that even without pci-passthrough the performance with
> >> gplpv is'nt that much better compared to w/o gplpv but with
> >> pci-passthrough - well it is overall a bit better, but just a bit, and
> >> seq. read performance is much worse...
> >> i haven't made a test without gplpv and without passthrough at the same
> >> time - tell me if you want to see how that performs.
> >> 
> >> Greetings!
> >> Tobias
> >> 
> >> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this
> >> tests.
> > 
> > What are you testing this with? I just ran some tests with iometer under
> > 2008R2 and it reminded me of something... DRBD *hates* having
> > outstanding writes to the same block, and complains about it, so gplpv
> > serialises such requests (stalling the queue until the first request is
> > complete). This almost never happens in production but iometer sends
> > such requests frequently, which will significantly impact performance.
> > 
> > You can test with the debug build to see if this is happening with
> > whatever you are testing with - you'll see messages like "Concurrent
> > outstanding write detected". Be aware though that qemu will rate limit
> > writes to the debug log so if it happens a lot (like under iometer) it
> > will slow to a crawl.
> > 
> > James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 10:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 10:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMGR1-0003U5-1U; Mon, 23 Apr 2012 10:23:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMGQz-0003Tu-9d
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:23:53 +0000
Received: from [85.158.143.35:3253] by server-3.bemta-4.messagelabs.com id
	E9/6B-05853-8BD259F4; Mon, 23 Apr 2012 10:23:52 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335176626!11197562!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9369 invoked from network); 23 Apr 2012 10:23:46 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-21.messagelabs.com with SMTP;
	23 Apr 2012 10:23:46 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 69B32D34747;
	Mon, 23 Apr 2012 12:23:46 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id vFehoJrSC1fE; Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 0C698D3462F;
	Mon, 23 Apr 2012 12:23:41 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 12:23:39 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201109090950.05043.muehlenhoff@univention.de>
	<6035A0D088A63A46850C3988ED045A4B1AF5E131@BITCOM1.int.sbss.com.au>
	<4F819645.4060404@vido.info>
In-Reply-To: <4F819645.4060404@vido.info>
MIME-Version: 1.0
Message-Id: <201204231223.40078.tobias.geiger@vido.info>
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Signed GPLPV drivers available for download
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

just FYI: since i updated my nearly one-year old xen-unstable checkout, it 
turned out that my strange GPL-PV Performance issue went away: 
With (gplpv_Vista2008x64_0.11.0.357.msi) i get much better performance with 
GPLPV than without - regardless of PCI-Passthrough.

What i observed though: I get about exactly "half" the performance (Disk-IO) 
in my PV-HVM than i get in my Dom0: In Dom0 i read/write with about 300mb/s , 
in DomU its about 150mb/s;
Also (but not exactly messured) i noticed double the RTT value when pinging 
the DomU in comparsion to the RTT when pinging Dom0;

I wonder what it makes perform more or less exactly "half" as Dom0 ?

Greetings
Tobias

Am Sonntag, 8. April 2012, 15:44:37 schrieb Tobias Geiger:
> Hi James,
> 
> I used "http://www.heise.de/download/as-ssd-benchmark.html" (sorry -
> german website), but i remember similar results with the famous "HD Tune
> Pro" tool...
> 
> Nowhere here DRBD is involved - sorry; the disk line refers to a phy lvm
> disk which is directly on a block device (ssd).
> 
> But i can test with debug build if you still think this (what?) is an
> issue here - tell me if you want to see that!
> 
> Greetings - and happy Easter!
> Tobias
> 
> Am 06.04.2012 12:56, schrieb James Harper:
> >> glad you ask - because just yesterday i re-tested the 357-version of the
> >> drivers under Windows7 64bit HVM guest - here are the results:
> >> 
> >> (everyting in mb/s)
> >> 
> >> W/O gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 311.8
> >> Seq. writing:  106.3
> >> 4k    reading: 10.2
> >> 4k    writing:   9.3
> >> 4k64thread reading: 11.1
> >> 4k64threads writing: 10.9
> >> 
> >> 
> >> WITH gplpv-drivers and WITH pci-passthrough:
> >> 
> >> Seq. reading: 98.8
> >> Seq. writing:  31.6
> >> 4k    reading: 12.0
> >> 4k    writing:  19.3
> >> 4k64thread reading: 15.4
> >> 4k64threads writing: 29.6
> >> 
> >> 
> >> WITH gplpv-drivers and WITHOUT pci-passthrough:
> >> 
> >> Seq. reading: 104.4
> >> Seq. writing:   85.2
> >> 4k    reading:  12.7
> >> 4k    writing:   20.4
> >> 4k64thread reading: 16.6
> >> 4k64threads writing: 32.6
> >> 
> >> 
> >> Strange thing is, that even without pci-passthrough the performance with
> >> gplpv is'nt that much better compared to w/o gplpv but with
> >> pci-passthrough - well it is overall a bit better, but just a bit, and
> >> seq. read performance is much worse...
> >> i haven't made a test without gplpv and without passthrough at the same
> >> time - tell me if you want to see how that performs.
> >> 
> >> Greetings!
> >> Tobias
> >> 
> >> P.S.: i'm using phy backend pointing to a LVM device on an SSD for this
> >> tests.
> > 
> > What are you testing this with? I just ran some tests with iometer under
> > 2008R2 and it reminded me of something... DRBD *hates* having
> > outstanding writes to the same block, and complains about it, so gplpv
> > serialises such requests (stalling the queue until the first request is
> > complete). This almost never happens in production but iometer sends
> > such requests frequently, which will significantly impact performance.
> > 
> > You can test with the debug build to see if this is happening with
> > whatever you are testing with - you'll see messages like "Concurrent
> > outstanding write detected". Be aware though that qemu will rate limit
> > writes to the debug log so if it happens a lot (like under iometer) it
> > will slow to a crawl.
> > 
> > James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 11:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 11:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMHMy-00041F-2C; Mon, 23 Apr 2012 11:23:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMHMw-000417-0Y
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 11:23:46 +0000
Received: from [193.109.254.147:45891] by server-4.bemta-14.messagelabs.com id
	F4/67-11570-1CB359F4; Mon, 23 Apr 2012 11:23:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335180224!5849635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21816 invoked from network); 23 Apr 2012 11:23:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 11:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12076427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:23:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 12:23:44 +0100
Date: Mon, 23 Apr 2012 12:29:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335170516.30700.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Sandi Romih <romihs.forums@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 23 Apr 2012, Ian Campbell wrote:
> On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> > [...]
> 
> >  kernel = "/etc/xen/kernels/oi151a/unix"
> >  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
> 
> I forget how this works -- do you need to comment these out while using
> pygrub or are these paths inside the ISO?
> [...]
> >  disk =
> > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > 'phy:/dev/dom0/oi_boot,xvda,w' ]
> >  bootloader = "/usr/bin/pygrub"
> 
> Sadly I don't think xl is currently capable of booting using pygrub from
> a file:/// type device.
 
> I expect this will be resolved by Stefano's "qdisk local attach" series
> which was on the list last week.

Actually, even without my patch series, xl should be able to boot a PV
guest using pygrub if (and only if) the disk is a raw file.


> In the meantime as a workaround you could try using losetup on the iso
> and pointing xl at phy:/dev/loop$N.

that should also work

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 11:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 11:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMHMy-00041F-2C; Mon, 23 Apr 2012 11:23:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMHMw-000417-0Y
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 11:23:46 +0000
Received: from [193.109.254.147:45891] by server-4.bemta-14.messagelabs.com id
	F4/67-11570-1CB359F4; Mon, 23 Apr 2012 11:23:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335180224!5849635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21816 invoked from network); 23 Apr 2012 11:23:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 11:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12076427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:23:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 12:23:44 +0100
Date: Mon, 23 Apr 2012 12:29:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335170516.30700.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Sandi Romih <romihs.forums@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 23 Apr 2012, Ian Campbell wrote:
> On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> > [...]
> 
> >  kernel = "/etc/xen/kernels/oi151a/unix"
> >  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
> 
> I forget how this works -- do you need to comment these out while using
> pygrub or are these paths inside the ISO?
> [...]
> >  disk =
> > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > 'phy:/dev/dom0/oi_boot,xvda,w' ]
> >  bootloader = "/usr/bin/pygrub"
> 
> Sadly I don't think xl is currently capable of booting using pygrub from
> a file:/// type device.
 
> I expect this will be resolved by Stefano's "qdisk local attach" series
> which was on the list last week.

Actually, even without my patch series, xl should be able to boot a PV
guest using pygrub if (and only if) the disk is a raw file.


> In the meantime as a workaround you could try using losetup on the iso
> and pointing xl at phy:/dev/loop$N.

that should also work

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 11:32:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 11:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMHUU-0004AI-WC; Mon, 23 Apr 2012 11:31:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMHUT-0004AD-QX
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 11:31:34 +0000
Received: from [85.158.143.35:29307] by server-3.bemta-4.messagelabs.com id
	31/CB-05853-59D359F4; Mon, 23 Apr 2012 11:31:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335180692!13289888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14969 invoked from network); 23 Apr 2012 11:31:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 11:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12076554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:30:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 12:30:29 +0100
Message-ID: <1335180628.4347.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 23 Apr 2012 12:30:28 +0100
In-Reply-To: <alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Sandi Romih <romihs.forums@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 12:29 +0100, Stefano Stabellini wrote:
> On Mon, 23 Apr 2012, Ian Campbell wrote:
> > On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> > > [...]
> > 
> > >  kernel = "/etc/xen/kernels/oi151a/unix"
> > >  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
> > 
> > I forget how this works -- do you need to comment these out while using
> > pygrub or are these paths inside the ISO?
> > [...]
> > >  disk =
> > > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > > 'phy:/dev/dom0/oi_boot,xvda,w' ]
> > >  bootloader = "/usr/bin/pygrub"
> > 
> > Sadly I don't think xl is currently capable of booting using pygrub from
> > a file:/// type device.
>  
> > I expect this will be resolved by Stefano's "qdisk local attach" series
> > which was on the list last week.
> 
> Actually, even without my patch series, xl should be able to boot a PV
> guest using pygrub if (and only if) the disk is a raw file.

Yes, I've just realised that while editing
http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer as part of the dos day -- it seems to work for me at least.

Perhaps the issue here is the use of kernel= and ramdisk= instead of
bootloader_args? (see the new CD install section of that Debian install
guide for an example of the sort of thing which works for me)

Ian.

> 
> 
> > In the meantime as a workaround you could try using losetup on the iso
> > and pointing xl at phy:/dev/loop$N.
> 
> that should also work



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 11:32:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 11:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMHUU-0004AI-WC; Mon, 23 Apr 2012 11:31:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMHUT-0004AD-QX
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 11:31:34 +0000
Received: from [85.158.143.35:29307] by server-3.bemta-4.messagelabs.com id
	31/CB-05853-59D359F4; Mon, 23 Apr 2012 11:31:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335180692!13289888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14969 invoked from network); 23 Apr 2012 11:31:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 11:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12076554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:30:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 12:30:29 +0100
Message-ID: <1335180628.4347.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 23 Apr 2012 12:30:28 +0100
In-Reply-To: <alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Sandi Romih <romihs.forums@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 12:29 +0100, Stefano Stabellini wrote:
> On Mon, 23 Apr 2012, Ian Campbell wrote:
> > On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> > > [...]
> > 
> > >  kernel = "/etc/xen/kernels/oi151a/unix"
> > >  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
> > 
> > I forget how this works -- do you need to comment these out while using
> > pygrub or are these paths inside the ISO?
> > [...]
> > >  disk =
> > > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > > 'phy:/dev/dom0/oi_boot,xvda,w' ]
> > >  bootloader = "/usr/bin/pygrub"
> > 
> > Sadly I don't think xl is currently capable of booting using pygrub from
> > a file:/// type device.
>  
> > I expect this will be resolved by Stefano's "qdisk local attach" series
> > which was on the list last week.
> 
> Actually, even without my patch series, xl should be able to boot a PV
> guest using pygrub if (and only if) the disk is a raw file.

Yes, I've just realised that while editing
http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer as part of the dos day -- it seems to work for me at least.

Perhaps the issue here is the use of kernel= and ramdisk= instead of
bootloader_args? (see the new CD install section of that Debian install
guide for an example of the sort of thing which works for me)

Ian.

> 
> 
> > In the meantime as a workaround you could try using losetup on the iso
> > and pointing xl at phy:/dev/loop$N.
> 
> that should also work



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 11:48:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 11:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMHk4-0004NM-GQ; Mon, 23 Apr 2012 11:47:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMHk3-0004NH-Jo
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 11:47:39 +0000
Received: from [85.158.143.35:28270] by server-1.bemta-4.messagelabs.com id
	CA/57-20925-A51459F4; Mon, 23 Apr 2012 11:47:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335181657!6178560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13291 invoked from network); 23 Apr 2012 11:47:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 11:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12077068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:47:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 12:47:20 +0100
Date: Mon, 23 Apr 2012 12:53:03 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204231202.27731.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 23 Apr 2012, Tobias Geiger wrote:
> Hello!
> 
> i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4 
> tested) as Dom0 Kernel;
> 
> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers 
> (gplpv_Vista2008x64_0.11.0.357.msi); 
> With 3.4 it drops to about a third of that.
> 
> Xen Version is xen-unstable: 
> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
> 
> Disk config line is:
> disk = [ '/dev/vg_ssd/win7system,,hda' ] 
> - it uses blkback.

I fail to see what could be the cause of the issue: nothing on the
blkback side should affect performances significantly.
You could try reverting the four patches to blkback that were applied
between 3.3 and 3.4-rc3 just to make sure it is not a blkback
regression:

$ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
Daniel De Graaf (2):
      xen/blkback: use grant-table.c hypercall wrappers
      xen/blkback: Enable blkback on HVM guests

Konrad Rzeszutek Wilk (2):
      xen/blkback: Squash the discard support for 'file' and 'phy' type.
      xen/blkback: Make optional features be really optional.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 11:48:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 11:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMHk4-0004NM-GQ; Mon, 23 Apr 2012 11:47:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMHk3-0004NH-Jo
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 11:47:39 +0000
Received: from [85.158.143.35:28270] by server-1.bemta-4.messagelabs.com id
	CA/57-20925-A51459F4; Mon, 23 Apr 2012 11:47:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335181657!6178560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13291 invoked from network); 23 Apr 2012 11:47:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 11:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12077068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:47:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 12:47:20 +0100
Date: Mon, 23 Apr 2012 12:53:03 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204231202.27731.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 23 Apr 2012, Tobias Geiger wrote:
> Hello!
> 
> i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4 
> tested) as Dom0 Kernel;
> 
> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers 
> (gplpv_Vista2008x64_0.11.0.357.msi); 
> With 3.4 it drops to about a third of that.
> 
> Xen Version is xen-unstable: 
> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
> 
> Disk config line is:
> disk = [ '/dev/vg_ssd/win7system,,hda' ] 
> - it uses blkback.

I fail to see what could be the cause of the issue: nothing on the
blkback side should affect performances significantly.
You could try reverting the four patches to blkback that were applied
between 3.3 and 3.4-rc3 just to make sure it is not a blkback
regression:

$ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
Daniel De Graaf (2):
      xen/blkback: use grant-table.c hypercall wrappers
      xen/blkback: Enable blkback on HVM guests

Konrad Rzeszutek Wilk (2):
      xen/blkback: Squash the discard support for 'file' and 'phy' type.
      xen/blkback: Make optional features be really optional.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 12:05:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 12:05:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMI0U-0004hT-0B; Mon, 23 Apr 2012 12:04:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMI0S-0004hN-3l
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 12:04:36 +0000
Received: from [85.158.138.51:15755] by server-2.bemta-3.messagelabs.com id
	5C/F2-09269-355459F4; Mon, 23 Apr 2012 12:04:35 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335182674!23226416!1
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22480 invoked from network); 23 Apr 2012 12:04:34 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-16.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 12:04:34 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp209.alice.it (8.6.023.02)
	id 4EF08A630DB4D3CC for xen-devel@lists.xensource.com;
	Mon, 23 Apr 2012 13:59:32 +0200
Message-ID: <4F954422.1010803@tiscali.it>
Date: Mon, 23 Apr 2012 13:59:30 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4466017206610696006=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4466017206610696006==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030801010909020607080504"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030801010909020607080504
Content-Type: multipart/mixed;
 boundary="------------000602000903050603000403"

This is a multi-part message in MIME format.
--------------000602000903050603000403
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1335181425 -7200
# Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
# Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
tools: Improve make deb
- Remove version from installed package name
- Add conffiles to manage main config files on package update
- Add/remove of main services (xencommons, xendomains)

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
--- a/tools/misc/mkdeb    lun apr 23 10:26:55 2012 +0200
+++ b/tools/misc/mkdeb    lun apr 23 13:43:45 2012 +0200
@@ -33,7 +33,7 @@
  # Fill in the debian boilerplate
  mkdir -p deb/DEBIAN
  cat >deb/DEBIAN/control <<EOF
-Package: xen-upstream-$version
+Package: xen-upstream
  Source: xen-upstream
  Version: $version
  Architecture: $arch
@@ -47,9 +47,27 @@
   the output of a xen "make dist" wrapped in a .deb to make it easy to
   uninstall.
  EOF
+cat >deb/DEBIAN/conffiles <<EOF
+/etc/xen/xl.conf
+/etc/xen/xend-config.sxp
+/etc/default/xendomains
+/etc/default/xencommons
+EOF
+cat >deb/DEBIAN/postinst <<EOF
+#!/bin/bash -e
+insserv xencommons &&
+insserv xendomains
+EOF
+cat >deb/DEBIAN/postrm <<EOF
+#!/bin/bash -e
+update-rc.d xendomains remove >/dev/null
+update-rc.d xencommons remove >/dev/null
+EOF

  # Package it up
  chown -R root:root deb
+chmod +x deb/DEBIAN/postinst
+chmod +x deb/DEBIAN/postrm
  dpkg --build deb xen-upstream-$version.deb

  # Tidy up after ourselves


--------------000602000903050603000403
Content-Type: text/plain; charset=windows-1252;
 name="improve_make_deb.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="improve_make_deb.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1335181425 -7200
# Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
# Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
tools: Improve make deb
- Remove version from installed package name
- Add conffiles to manage main config files on package update
- Add/remove of main services (xencommons, xendomains)

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
--- a/tools/misc/mkdeb	lun apr 23 10:26:55 2012 +0200
+++ b/tools/misc/mkdeb	lun apr 23 13:43:45 2012 +0200
@@ -33,7 +33,7 @@
 # Fill in the debian boilerplate
 mkdir -p deb/DEBIAN
 cat >deb/DEBIAN/control <<EOF
-Package: xen-upstream-$version
+Package: xen-upstream
 Source: xen-upstream
 Version: $version
 Architecture: $arch
@@ -47,9 +47,27 @@
  the output of a xen "make dist" wrapped in a .deb to make it easy to
  uninstall.
 EOF
+cat >deb/DEBIAN/conffiles <<EOF
+/etc/xen/xl.conf
+/etc/xen/xend-config.sxp
+/etc/default/xendomains
+/etc/default/xencommons
+EOF
+cat >deb/DEBIAN/postinst <<EOF
+#!/bin/bash -e
+insserv xencommons &&
+insserv xendomains
+EOF
+cat >deb/DEBIAN/postrm <<EOF
+#!/bin/bash -e
+update-rc.d xendomains remove >/dev/null
+update-rc.d xencommons remove >/dev/null
+EOF
=20
 # Package it up
 chown -R root:root deb
+chmod +x deb/DEBIAN/postinst
+chmod +x deb/DEBIAN/postrm
 dpkg --build deb xen-upstream-$version.deb
=20
 # Tidy up after ourselves

--------------000602000903050603000403--

--------------ms030801010909020607080504
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQyMzExNTkzMFowIwYJKoZIhvcNAQkEMRYEFFEMwbKxUUhLHEJEfBIitQ72
0pSvMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQAzE64d+eOGXQDBVJU2Onbc7G2B2gUge9jB65SfSewa
GfAEi/N4CekZ+XjUmgX+heZfjkOaVZBlGBBs4DdN8/j6hFehF5ZMW53LdyNdgG//z2rFHP4l
8qolCP1tsmPCw/RwK3xSB6lDMPnfp9TsbOI50UM/wfwwtYAbN49fIEQCeWDciLzEGuggq94e
daw7AyuNClP9YMHJrlpcqdhF+h0x2p9W1PP4nQ6z/jKWUyGrJHx2B84XR6slxvkq/3G5klKG
FgzbTKoE7mWz8eWQMZ7IrwdT5WvE0ShYsTpQ4+8YlEkvl5AnKE/p4FFnEYNnfb0GfGIfvQQc
6O8Sq3gKPtpmAAAAAAAA
--------------ms030801010909020607080504--


--===============4466017206610696006==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4466017206610696006==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 12:05:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 12:05:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMI0U-0004hT-0B; Mon, 23 Apr 2012 12:04:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMI0S-0004hN-3l
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 12:04:36 +0000
Received: from [85.158.138.51:15755] by server-2.bemta-3.messagelabs.com id
	5C/F2-09269-355459F4; Mon, 23 Apr 2012 12:04:35 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335182674!23226416!1
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22480 invoked from network); 23 Apr 2012 12:04:34 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-16.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 12:04:34 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp209.alice.it (8.6.023.02)
	id 4EF08A630DB4D3CC for xen-devel@lists.xensource.com;
	Mon, 23 Apr 2012 13:59:32 +0200
Message-ID: <4F954422.1010803@tiscali.it>
Date: Mon, 23 Apr 2012 13:59:30 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4466017206610696006=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4466017206610696006==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030801010909020607080504"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030801010909020607080504
Content-Type: multipart/mixed;
 boundary="------------000602000903050603000403"

This is a multi-part message in MIME format.
--------------000602000903050603000403
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Fabio Fantoni
# Date 1335181425 -7200
# Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
# Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
tools: Improve make deb
- Remove version from installed package name
- Add conffiles to manage main config files on package update
- Add/remove of main services (xencommons, xendomains)

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
--- a/tools/misc/mkdeb    lun apr 23 10:26:55 2012 +0200
+++ b/tools/misc/mkdeb    lun apr 23 13:43:45 2012 +0200
@@ -33,7 +33,7 @@
  # Fill in the debian boilerplate
  mkdir -p deb/DEBIAN
  cat >deb/DEBIAN/control <<EOF
-Package: xen-upstream-$version
+Package: xen-upstream
  Source: xen-upstream
  Version: $version
  Architecture: $arch
@@ -47,9 +47,27 @@
   the output of a xen "make dist" wrapped in a .deb to make it easy to
   uninstall.
  EOF
+cat >deb/DEBIAN/conffiles <<EOF
+/etc/xen/xl.conf
+/etc/xen/xend-config.sxp
+/etc/default/xendomains
+/etc/default/xencommons
+EOF
+cat >deb/DEBIAN/postinst <<EOF
+#!/bin/bash -e
+insserv xencommons &&
+insserv xendomains
+EOF
+cat >deb/DEBIAN/postrm <<EOF
+#!/bin/bash -e
+update-rc.d xendomains remove >/dev/null
+update-rc.d xencommons remove >/dev/null
+EOF

  # Package it up
  chown -R root:root deb
+chmod +x deb/DEBIAN/postinst
+chmod +x deb/DEBIAN/postrm
  dpkg --build deb xen-upstream-$version.deb

  # Tidy up after ourselves


--------------000602000903050603000403
Content-Type: text/plain; charset=windows-1252;
 name="improve_make_deb.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="improve_make_deb.patch"

# HG changeset patch
# User Fabio Fantoni
# Date 1335181425 -7200
# Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
# Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
tools: Improve make deb
- Remove version from installed package name
- Add conffiles to manage main config files on package update
- Add/remove of main services (xencommons, xendomains)

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
--- a/tools/misc/mkdeb	lun apr 23 10:26:55 2012 +0200
+++ b/tools/misc/mkdeb	lun apr 23 13:43:45 2012 +0200
@@ -33,7 +33,7 @@
 # Fill in the debian boilerplate
 mkdir -p deb/DEBIAN
 cat >deb/DEBIAN/control <<EOF
-Package: xen-upstream-$version
+Package: xen-upstream
 Source: xen-upstream
 Version: $version
 Architecture: $arch
@@ -47,9 +47,27 @@
  the output of a xen "make dist" wrapped in a .deb to make it easy to
  uninstall.
 EOF
+cat >deb/DEBIAN/conffiles <<EOF
+/etc/xen/xl.conf
+/etc/xen/xend-config.sxp
+/etc/default/xendomains
+/etc/default/xencommons
+EOF
+cat >deb/DEBIAN/postinst <<EOF
+#!/bin/bash -e
+insserv xencommons &&
+insserv xendomains
+EOF
+cat >deb/DEBIAN/postrm <<EOF
+#!/bin/bash -e
+update-rc.d xendomains remove >/dev/null
+update-rc.d xencommons remove >/dev/null
+EOF
=20
 # Package it up
 chown -R root:root deb
+chmod +x deb/DEBIAN/postinst
+chmod +x deb/DEBIAN/postrm
 dpkg --build deb xen-upstream-$version.deb
=20
 # Tidy up after ourselves

--------------000602000903050603000403--

--------------ms030801010909020607080504
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQyMzExNTkzMFowIwYJKoZIhvcNAQkEMRYEFFEMwbKxUUhLHEJEfBIitQ72
0pSvMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQAzE64d+eOGXQDBVJU2Onbc7G2B2gUge9jB65SfSewa
GfAEi/N4CekZ+XjUmgX+heZfjkOaVZBlGBBs4DdN8/j6hFehF5ZMW53LdyNdgG//z2rFHP4l
8qolCP1tsmPCw/RwK3xSB6lDMPnfp9TsbOI50UM/wfwwtYAbN49fIEQCeWDciLzEGuggq94e
daw7AyuNClP9YMHJrlpcqdhF+h0x2p9W1PP4nQ6z/jKWUyGrJHx2B84XR6slxvkq/3G5klKG
FgzbTKoE7mWz8eWQMZ7IrwdT5WvE0ShYsTpQ4+8YlEkvl5AnKE/p4FFnEYNnfb0GfGIfvQQc
6O8Sq3gKPtpmAAAAAAAA
--------------ms030801010909020607080504--


--===============4466017206610696006==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4466017206610696006==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 12:05:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 12:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMI0k-0004iT-DT; Mon, 23 Apr 2012 12:04:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMI0j-0004iE-3t
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 12:04:53 +0000
Received: from [193.109.254.147:25374] by server-5.bemta-14.messagelabs.com id
	ED/29-30733-465459F4; Mon, 23 Apr 2012 12:04:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335182684!5875508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 380 invoked from network); 23 Apr 2012 12:04:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 12:04:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12077506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 12:04:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 13:04:43 +0100
Message-ID: <1335182682.4347.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Mon, 23 Apr 2012 13:04:42 +0100
In-Reply-To: <20120423094623.GA13565@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	Dieter Bloms <xensource.com@bloms.de>, George.Dunlap@citrix.com,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(xen-users to BCC, this seems like a devel thing for now)

On Mon, 2012-04-23 at 10:46 +0100, Dieter Bloms wrote:
> Hello Ian,
> 
> I've made a little patch to set the cpu_weight for credit, credit2 and
> sedf scheduler from the config file.

Awesome, thank you!

> Btw.: for the sedf scheduler there seems to be some type mismatch.  
> The functions xc_sedf_domain_set and xc_sedf_domain_get expect the type
> 'uint16_t' for variables 'extratime' and 'weight' while the structure
> 'xen_domctl_sched_sedf' defines the type uint32_t for them.
> I think they should be the same, or not ?

I'm not clear enough on the scheduling stuff to be able to say one way
or another. I'd be inclined to suggest that if this needs to change for
some reason then we should leave it for post 4.2.

> Anyway, I've tested this patch for the credit scheduler and it works so
> far.

Cool. One thing which we need in order to able to apply a patch is a
"Signed-off-by" per the DCO as described in
http://wiki.xen.org/wiki/SubmittingXenPatches. 

I've also a few minor comments on the patch itself below.

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..706e282 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -110,6 +110,10 @@ int libxl__domain_build_info_setdefault(libxl__gc
> *gc,
>          return ERROR_INVAL;
>      }
>  
> +    if (!b_info->weight)
> +        b_info->weight = 256;

I suppose that weight=0 does not make sense and therefore 0 is available
as a discriminating value meaning "the default".

> +    if (!b_info->cap)
> +        b_info->cap = 0;

!b_info->cap means that b_info_cap is already 0, although I guess this
serves as a more explicit indication of the default.

>      if (!b_info->max_vcpus)
>          b_info->max_vcpus = 1;
>      if (!b_info->cur_vcpus)
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..f858a42 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -65,9 +65,38 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
>      char *xs_domid, *con_domid;
> +    libxl_scheduler sched;
> +    struct xen_domctl_scheduler_op sched_op;
> +
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,
> &info->cpumap);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT);
> +
> +    sched = libxl_get_scheduler (ctx);
> +    
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      xc_sedf_domain_get (ctx->xch, domid, &(sched_op.u.sedf.period),
> &(sched_op.u.sedf.slice), &(sched_op.u.sedf.latency), (uint16_t *)
> &(sched_op.u.sedf.extratime), (uint16_t *) &(sched_op.u.sedf.weight));
> +      sched_op.u.sedf.weight = info->weight;
> +      xc_sedf_domain_set (ctx->xch, domid, sched_op.u.sedf.period,
> sched_op.u.sedf.slice, sched_op.u.sedf.latency, (uint16_t)
> sched_op.u.sedf.extratime, (uint16_t) sched_op.u.sedf.weight);

Wow, that's a pretty sucky interface at the libxc level! Anyway no need
for you to fix it here but please do wrap your lines to <80 columns for
readability.

> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +//      struct xen_domctl_sched_credit sdom;

Please don't leave commented out code in place.

> +      sched_op.u.credit.weight = info->weight;
> +      sched_op.u.credit.cap = info->cap;
> +      xc_sched_credit_domain_set(ctx->xch, domid,
> &(sched_op.u.credit));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT2:
> +      sched_op.u.credit2.weight = info->weight;
> +      xc_sched_credit2_domain_set(ctx->xch, domid,
> &(sched_op.u.credit2));
> +      break;
> +    case LIBXL_SCHEDULER_ARINC653:
> +      /* not implemented */
> +      break;
> +    default:
> +        abort();
> +    }
> +
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
>          xc_domain_set_memmap_limit(ctx->xch, domid,
>                  (info->max_memkb + info->u.pv.slack_memkb));
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..f185d4c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -232,6 +232,8 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
>      ("cur_vcpus",       integer),
> +    ("weight",          integer),
> +    ("cap",             integer),

Are these values common parameters to all schedulers? Do they always
have the same meaning/units/etc?

I wonder if perhaps including each of libxl_sched_*_params in build_info
might be a preferable interface? I would probably cleanup the above code
in build_pre too since you could just call the appropriate
libxl_sched_*_params_set.

Ideally libxl_sched_*_params would be in a union in
libxl_domain_build_info but that would require that xl could easily
determine which scheduler was going to be used for the domain, having a
non-union here would keep things somewhat simpler from that PoV.

I've CC'd George and Dario for their thoughts on this interface. We
should try and keep it simple so that we can get this into 4.2. 

>      ("cpumap",          libxl_cpumap),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       MemKB),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 5703512..d7dcb84 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -587,6 +587,11 @@ static void parse_config_data(const char
> *configfile_filename_report,
>      libxl_domain_build_info_init_type(b_info, c_info->type);
>  
>      /* the following is the actual config parsing with overriding
> values in the structures */
> +    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
> +        b_info->weight = l;
> +    if (!xlu_cfg_get_long (config, "cap", &l, 0))
> +        b_info->cap = l;
> +
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
>          b_info->cur_vcpus = (1 << l) - 1;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 12:05:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 12:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMI0k-0004iT-DT; Mon, 23 Apr 2012 12:04:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMI0j-0004iE-3t
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 12:04:53 +0000
Received: from [193.109.254.147:25374] by server-5.bemta-14.messagelabs.com id
	ED/29-30733-465459F4; Mon, 23 Apr 2012 12:04:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335182684!5875508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 380 invoked from network); 23 Apr 2012 12:04:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 12:04:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12077506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 12:04:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 13:04:43 +0100
Message-ID: <1335182682.4347.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Mon, 23 Apr 2012 13:04:42 +0100
In-Reply-To: <20120423094623.GA13565@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	Dieter Bloms <xensource.com@bloms.de>, George.Dunlap@citrix.com,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(xen-users to BCC, this seems like a devel thing for now)

On Mon, 2012-04-23 at 10:46 +0100, Dieter Bloms wrote:
> Hello Ian,
> 
> I've made a little patch to set the cpu_weight for credit, credit2 and
> sedf scheduler from the config file.

Awesome, thank you!

> Btw.: for the sedf scheduler there seems to be some type mismatch.  
> The functions xc_sedf_domain_set and xc_sedf_domain_get expect the type
> 'uint16_t' for variables 'extratime' and 'weight' while the structure
> 'xen_domctl_sched_sedf' defines the type uint32_t for them.
> I think they should be the same, or not ?

I'm not clear enough on the scheduling stuff to be able to say one way
or another. I'd be inclined to suggest that if this needs to change for
some reason then we should leave it for post 4.2.

> Anyway, I've tested this patch for the credit scheduler and it works so
> far.

Cool. One thing which we need in order to able to apply a patch is a
"Signed-off-by" per the DCO as described in
http://wiki.xen.org/wiki/SubmittingXenPatches. 

I've also a few minor comments on the patch itself below.

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e63c7bd..706e282 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -110,6 +110,10 @@ int libxl__domain_build_info_setdefault(libxl__gc
> *gc,
>          return ERROR_INVAL;
>      }
>  
> +    if (!b_info->weight)
> +        b_info->weight = 256;

I suppose that weight=0 does not make sense and therefore 0 is available
as a discriminating value meaning "the default".

> +    if (!b_info->cap)
> +        b_info->cap = 0;

!b_info->cap means that b_info_cap is already 0, although I guess this
serves as a more explicit indication of the default.

>      if (!b_info->max_vcpus)
>          b_info->max_vcpus = 1;
>      if (!b_info->cur_vcpus)
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..f858a42 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -65,9 +65,38 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
>      char *xs_domid, *con_domid;
> +    libxl_scheduler sched;
> +    struct xen_domctl_scheduler_op sched_op;
> +
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,
> &info->cpumap);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT);
> +
> +    sched = libxl_get_scheduler (ctx);
> +    
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      xc_sedf_domain_get (ctx->xch, domid, &(sched_op.u.sedf.period),
> &(sched_op.u.sedf.slice), &(sched_op.u.sedf.latency), (uint16_t *)
> &(sched_op.u.sedf.extratime), (uint16_t *) &(sched_op.u.sedf.weight));
> +      sched_op.u.sedf.weight = info->weight;
> +      xc_sedf_domain_set (ctx->xch, domid, sched_op.u.sedf.period,
> sched_op.u.sedf.slice, sched_op.u.sedf.latency, (uint16_t)
> sched_op.u.sedf.extratime, (uint16_t) sched_op.u.sedf.weight);

Wow, that's a pretty sucky interface at the libxc level! Anyway no need
for you to fix it here but please do wrap your lines to <80 columns for
readability.

> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +//      struct xen_domctl_sched_credit sdom;

Please don't leave commented out code in place.

> +      sched_op.u.credit.weight = info->weight;
> +      sched_op.u.credit.cap = info->cap;
> +      xc_sched_credit_domain_set(ctx->xch, domid,
> &(sched_op.u.credit));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT2:
> +      sched_op.u.credit2.weight = info->weight;
> +      xc_sched_credit2_domain_set(ctx->xch, domid,
> &(sched_op.u.credit2));
> +      break;
> +    case LIBXL_SCHEDULER_ARINC653:
> +      /* not implemented */
> +      break;
> +    default:
> +        abort();
> +    }
> +
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
>          xc_domain_set_memmap_limit(ctx->xch, domid,
>                  (info->max_memkb + info->u.pv.slack_memkb));
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..f185d4c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -232,6 +232,8 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
>      ("cur_vcpus",       integer),
> +    ("weight",          integer),
> +    ("cap",             integer),

Are these values common parameters to all schedulers? Do they always
have the same meaning/units/etc?

I wonder if perhaps including each of libxl_sched_*_params in build_info
might be a preferable interface? I would probably cleanup the above code
in build_pre too since you could just call the appropriate
libxl_sched_*_params_set.

Ideally libxl_sched_*_params would be in a union in
libxl_domain_build_info but that would require that xl could easily
determine which scheduler was going to be used for the domain, having a
non-union here would keep things somewhat simpler from that PoV.

I've CC'd George and Dario for their thoughts on this interface. We
should try and keep it simple so that we can get this into 4.2. 

>      ("cpumap",          libxl_cpumap),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       MemKB),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 5703512..d7dcb84 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -587,6 +587,11 @@ static void parse_config_data(const char
> *configfile_filename_report,
>      libxl_domain_build_info_init_type(b_info, c_info->type);
>  
>      /* the following is the actual config parsing with overriding
> values in the structures */
> +    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
> +        b_info->weight = l;
> +    if (!xlu_cfg_get_long (config, "cap", &l, 0))
> +        b_info->cap = l;
> +
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
>          b_info->cur_vcpus = (1 << l) - 1;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 12:13:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 12:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMI8e-00053g-Gh; Mon, 23 Apr 2012 12:13:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SMI8c-00053b-NI
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 12:13:02 +0000
Received: from [193.109.254.147:23835] by server-2.bemta-14.messagelabs.com id
	E8/DE-19409-E47459F4; Mon, 23 Apr 2012 12:13:02 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335183180!5859305!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gODQ2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17911 invoked from network); 23 Apr 2012 12:13:01 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 12:13:01 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 294C520AEB;
	Mon, 23 Apr 2012 08:13:00 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Mon, 23 Apr 2012 08:13:00 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=um
	P8eg6kE9PVkDpWqnPi0eN7dgo=; b=jTFe/dig6t5DlVTyzMfv3oPuLjorSWe2jH
	LExK8X+EX0+pSRBNw/1SbH/ziFfJQEorV+/1m3ju1EGq6/+bCm1uVZUd8A5mAzSP
	+OcLCXnZF4qaao1QjOoF9PqZezVfS1BiAe6aWtuKT9Z6OGmLc6QDRr7VO7majZSE
	ZVhjr5D50=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=umP8
	eg6kE9PVkDpWqnPi0eN7dgo=; b=m9ehFhMt3tti2SkvleYFjVQFbiD61EDmzYMx
	Omb4pswR5eM0qYLWfwRvMzEne1NJ9dgRyZDoZlIB6qK79WLHmaaamEmdwZoIydK1
	I3R4ulKVXHa/jEmK1IoeUELAYYyH4LSkJnq6iW75J/9+4lRWR3IxrowQfro5L6mq
	RmYwDiw=
X-Sasl-enc: pqoW4u6IngTe0y0y9TEoeki7iY4LKRS3z3RJucz7HWr3 1335183179
Received: from [10.137.2.11] (87-207-224-106.dynamic.chello.pl
	[87.207.224.106])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 2F143483520;
	Mon, 23 Apr 2012 08:12:58 -0400 (EDT)
Message-ID: <4F954747.9030305@invisiblethingslab.com>
Date: Mon, 23 Apr 2012 14:12:55 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
X-Enigmail-Version: 1.4.1
Cc: Joanna Rutkowska <joanna@invisiblethingslab.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0310570530062075745=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0310570530062075745==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigCA6CD1C5DE90D86A1939D40F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCA6CD1C5DE90D86A1939D40F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 20.04.2012 15:23, Roger Pau Monne wrote:
> This series removes the use of udev rules to call hotplug scripts when =
using
> libxl. Scripts are directly called from the toolstack at the necessary =
points,
> making use of the new event library and it's fork support.

What about non-dom0 backends? There will be no simple way to execute scri=
pt
there by libxl without help from udev...

In Qubes-OS we heavily use network backend in domU: dom0 have no network =
at
all, all NICs are attached (as PCI device) to some domU - called NetVM, w=
here
network backend resides.

Also vbd backend in domU is used - eg to boot HVM from iso, which is stor=
ed in
some domU.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigCA6CD1C5DE90D86A1939D40F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPlUdHAAoJENuP0xzK19cs/IAH/1p2BhFwNBonXmKnFLWCjcBt
xT4o/mIT6P8kUfafbYKV/3pMC9xB48kMDk4z3f5mqygtL3pmhkS7Ttrbe/F3wqzA
JQXR+kD0srypVZyebOebgWSUGE4LYbfW6EqVwjalotHJwCnfY2FNDr8PNaOfu5tD
Nk6RMxaWQQAKi4xPX8VvncXCk4odbEqeZMZ+GZW1b93skVzC+L/Si1oSx4TmmFgz
pS1gRU0GHMPLjkQSzybkyhKpRsFirYGbvyUSZAU1p8f4mzJMVi0JOuFq9uzgRlx9
d0+K7A3uz+QzkUkAzAtka+Ztot3K0fNd4VdEcvO7WnOhnrcrFT/G+B6Cdj+O7p4=
=cgCd
-----END PGP SIGNATURE-----

--------------enigCA6CD1C5DE90D86A1939D40F--


--===============0310570530062075745==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0310570530062075745==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 12:13:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 12:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMI8e-00053g-Gh; Mon, 23 Apr 2012 12:13:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SMI8c-00053b-NI
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 12:13:02 +0000
Received: from [193.109.254.147:23835] by server-2.bemta-14.messagelabs.com id
	E8/DE-19409-E47459F4; Mon, 23 Apr 2012 12:13:02 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335183180!5859305!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gODQ2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17911 invoked from network); 23 Apr 2012 12:13:01 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 12:13:01 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 294C520AEB;
	Mon, 23 Apr 2012 08:13:00 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Mon, 23 Apr 2012 08:13:00 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=um
	P8eg6kE9PVkDpWqnPi0eN7dgo=; b=jTFe/dig6t5DlVTyzMfv3oPuLjorSWe2jH
	LExK8X+EX0+pSRBNw/1SbH/ziFfJQEorV+/1m3ju1EGq6/+bCm1uVZUd8A5mAzSP
	+OcLCXnZF4qaao1QjOoF9PqZezVfS1BiAe6aWtuKT9Z6OGmLc6QDRr7VO7majZSE
	ZVhjr5D50=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=umP8
	eg6kE9PVkDpWqnPi0eN7dgo=; b=m9ehFhMt3tti2SkvleYFjVQFbiD61EDmzYMx
	Omb4pswR5eM0qYLWfwRvMzEne1NJ9dgRyZDoZlIB6qK79WLHmaaamEmdwZoIydK1
	I3R4ulKVXHa/jEmK1IoeUELAYYyH4LSkJnq6iW75J/9+4lRWR3IxrowQfro5L6mq
	RmYwDiw=
X-Sasl-enc: pqoW4u6IngTe0y0y9TEoeki7iY4LKRS3z3RJucz7HWr3 1335183179
Received: from [10.137.2.11] (87-207-224-106.dynamic.chello.pl
	[87.207.224.106])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 2F143483520;
	Mon, 23 Apr 2012 08:12:58 -0400 (EDT)
Message-ID: <4F954747.9030305@invisiblethingslab.com>
Date: Mon, 23 Apr 2012 14:12:55 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
X-Enigmail-Version: 1.4.1
Cc: Joanna Rutkowska <joanna@invisiblethingslab.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0310570530062075745=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0310570530062075745==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigCA6CD1C5DE90D86A1939D40F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCA6CD1C5DE90D86A1939D40F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 20.04.2012 15:23, Roger Pau Monne wrote:
> This series removes the use of udev rules to call hotplug scripts when =
using
> libxl. Scripts are directly called from the toolstack at the necessary =
points,
> making use of the new event library and it's fork support.

What about non-dom0 backends? There will be no simple way to execute scri=
pt
there by libxl without help from udev...

In Qubes-OS we heavily use network backend in domU: dom0 have no network =
at
all, all NICs are attached (as PCI device) to some domU - called NetVM, w=
here
network backend resides.

Also vbd backend in domU is used - eg to boot HVM from iso, which is stor=
ed in
some domU.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigCA6CD1C5DE90D86A1939D40F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPlUdHAAoJENuP0xzK19cs/IAH/1p2BhFwNBonXmKnFLWCjcBt
xT4o/mIT6P8kUfafbYKV/3pMC9xB48kMDk4z3f5mqygtL3pmhkS7Ttrbe/F3wqzA
JQXR+kD0srypVZyebOebgWSUGE4LYbfW6EqVwjalotHJwCnfY2FNDr8PNaOfu5tD
Nk6RMxaWQQAKi4xPX8VvncXCk4odbEqeZMZ+GZW1b93skVzC+L/Si1oSx4TmmFgz
pS1gRU0GHMPLjkQSzybkyhKpRsFirYGbvyUSZAU1p8f4mzJMVi0JOuFq9uzgRlx9
d0+K7A3uz+QzkUkAzAtka+Ztot3K0fNd4VdEcvO7WnOhnrcrFT/G+B6Cdj+O7p4=
=cgCd
-----END PGP SIGNATURE-----

--------------enigCA6CD1C5DE90D86A1939D40F--


--===============0310570530062075745==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0310570530062075745==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 13:31:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJMG-0005Ud-40; Mon, 23 Apr 2012 13:31:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMJME-0005UV-6z
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 13:31:10 +0000
Received: from [85.158.143.35:15056] by server-3.bemta-4.messagelabs.com id
	93/D2-05853-D99559F4; Mon, 23 Apr 2012 13:31:09 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335187867!6110133!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27849 invoked from network); 23 Apr 2012 13:31:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 13:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330923600"; d="scan'208";a="191585566"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 09:31:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:31:06 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMJMA-00006u-HX;
	Mon, 23 Apr 2012 14:31:06 +0100
Message-ID: <4F955999.3030500@citrix.com>
Date: Mon, 23 Apr 2012 14:31:05 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
In-Reply-To: <4F954747.9030305@invisiblethingslab.com>
Cc: Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TWFyZWsgTWFyY3p5a293c2tpIGVzY3JpYmnDszoKPiBPbiAyMC4wNC4yMDEyIDE1OjIzLCBSb2dl
ciBQYXUgTW9ubmUgd3JvdGU6Cj4+IFRoaXMgc2VyaWVzIHJlbW92ZXMgdGhlIHVzZSBvZiB1ZGV2
IHJ1bGVzIHRvIGNhbGwgaG90cGx1ZyBzY3JpcHRzIHdoZW4gdXNpbmcKPj4gbGlieGwuIFNjcmlw
dHMgYXJlIGRpcmVjdGx5IGNhbGxlZCBmcm9tIHRoZSB0b29sc3RhY2sgYXQgdGhlIG5lY2Vzc2Fy
eSBwb2ludHMsCj4+IG1ha2luZyB1c2Ugb2YgdGhlIG5ldyBldmVudCBsaWJyYXJ5IGFuZCBpdCdz
IGZvcmsgc3VwcG9ydC4KPgo+IFdoYXQgYWJvdXQgbm9uLWRvbTAgYmFja2VuZHM/IFRoZXJlIHdp
bGwgYmUgbm8gc2ltcGxlIHdheSB0byBleGVjdXRlIHNjcmlwdAo+IHRoZXJlIGJ5IGxpYnhsIHdp
dGhvdXQgaGVscCBmcm9tIHVkZXYuLi4KCkEgbmV3IGNvbmZpZyBvcHRpb24gaGFzIGJlZW4gYWRk
ZWQgb24gdGhpcyBzZXJpZXMgCihkaXNhYmxlX3hsX3ZpZl9zY3JpcHRzKSB0aGF0IGFsbG93cyB0
aGUgdXNlciB0byBrZWVwIGV4ZWN1dGluZyB2aWYgCnNjcmlwdHMgZnJvbSB1ZGV2LCBzbyB0aGlz
IGZ1bmN0aW9uYWxpdHkgaXMgbm90IGxvc3QuCgo+IEluIFF1YmVzLU9TIHdlIGhlYXZpbHkgdXNl
IG5ldHdvcmsgYmFja2VuZCBpbiBkb21VOiBkb20wIGhhdmUgbm8gbmV0d29yayBhdAo+IGFsbCwg
YWxsIE5JQ3MgYXJlIGF0dGFjaGVkIChhcyBQQ0kgZGV2aWNlKSB0byBzb21lIGRvbVUgLSBjYWxs
ZWQgTmV0Vk0sIHdoZXJlCj4gbmV0d29yayBiYWNrZW5kIHJlc2lkZXMuCgpUaGVyZSBzaG91bGQg
YmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQsIHlvdSB3aWxsIGp1c3QgbmVlZCB0byB1c2UgdGhlIG5l
dyAKb3B0aW9uLgoKPiBBbHNvIHZiZCBiYWNrZW5kIGluIGRvbVUgaXMgdXNlZCAtIGVnIHRvIGJv
b3QgSFZNIGZyb20gaXNvLCB3aGljaCBpcyBzdG9yZWQgaW4KPiBzb21lIGRvbVUuCgpJIGRpZG4n
dCBrbm93IHlvdSB3aGVyZSBhYmxlIHRvIHVzZSB2YmQgZnJvbSBkcml2ZXIgZG9tYWlucyB3aXRo
IHhsLCBpZiAKc28gSSB3aWxsIGhhdmUgdG8gYWRkIGEgc2ltaWxhciBvcHRpb24gZm9yIHZiZCBk
ZXZpY2VzIAooZGlzYWJsZV94bF92YmRfc2NyaXB0cykuCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 23 13:31:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJMG-0005Ud-40; Mon, 23 Apr 2012 13:31:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMJME-0005UV-6z
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 13:31:10 +0000
Received: from [85.158.143.35:15056] by server-3.bemta-4.messagelabs.com id
	93/D2-05853-D99559F4; Mon, 23 Apr 2012 13:31:09 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335187867!6110133!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDM2OTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27849 invoked from network); 23 Apr 2012 13:31:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 13:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330923600"; d="scan'208";a="191585566"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 09:31:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 09:31:06 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMJMA-00006u-HX;
	Mon, 23 Apr 2012 14:31:06 +0100
Message-ID: <4F955999.3030500@citrix.com>
Date: Mon, 23 Apr 2012 14:31:05 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
In-Reply-To: <4F954747.9030305@invisiblethingslab.com>
Cc: Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TWFyZWsgTWFyY3p5a293c2tpIGVzY3JpYmnDszoKPiBPbiAyMC4wNC4yMDEyIDE1OjIzLCBSb2dl
ciBQYXUgTW9ubmUgd3JvdGU6Cj4+IFRoaXMgc2VyaWVzIHJlbW92ZXMgdGhlIHVzZSBvZiB1ZGV2
IHJ1bGVzIHRvIGNhbGwgaG90cGx1ZyBzY3JpcHRzIHdoZW4gdXNpbmcKPj4gbGlieGwuIFNjcmlw
dHMgYXJlIGRpcmVjdGx5IGNhbGxlZCBmcm9tIHRoZSB0b29sc3RhY2sgYXQgdGhlIG5lY2Vzc2Fy
eSBwb2ludHMsCj4+IG1ha2luZyB1c2Ugb2YgdGhlIG5ldyBldmVudCBsaWJyYXJ5IGFuZCBpdCdz
IGZvcmsgc3VwcG9ydC4KPgo+IFdoYXQgYWJvdXQgbm9uLWRvbTAgYmFja2VuZHM/IFRoZXJlIHdp
bGwgYmUgbm8gc2ltcGxlIHdheSB0byBleGVjdXRlIHNjcmlwdAo+IHRoZXJlIGJ5IGxpYnhsIHdp
dGhvdXQgaGVscCBmcm9tIHVkZXYuLi4KCkEgbmV3IGNvbmZpZyBvcHRpb24gaGFzIGJlZW4gYWRk
ZWQgb24gdGhpcyBzZXJpZXMgCihkaXNhYmxlX3hsX3ZpZl9zY3JpcHRzKSB0aGF0IGFsbG93cyB0
aGUgdXNlciB0byBrZWVwIGV4ZWN1dGluZyB2aWYgCnNjcmlwdHMgZnJvbSB1ZGV2LCBzbyB0aGlz
IGZ1bmN0aW9uYWxpdHkgaXMgbm90IGxvc3QuCgo+IEluIFF1YmVzLU9TIHdlIGhlYXZpbHkgdXNl
IG5ldHdvcmsgYmFja2VuZCBpbiBkb21VOiBkb20wIGhhdmUgbm8gbmV0d29yayBhdAo+IGFsbCwg
YWxsIE5JQ3MgYXJlIGF0dGFjaGVkIChhcyBQQ0kgZGV2aWNlKSB0byBzb21lIGRvbVUgLSBjYWxs
ZWQgTmV0Vk0sIHdoZXJlCj4gbmV0d29yayBiYWNrZW5kIHJlc2lkZXMuCgpUaGVyZSBzaG91bGQg
YmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQsIHlvdSB3aWxsIGp1c3QgbmVlZCB0byB1c2UgdGhlIG5l
dyAKb3B0aW9uLgoKPiBBbHNvIHZiZCBiYWNrZW5kIGluIGRvbVUgaXMgdXNlZCAtIGVnIHRvIGJv
b3QgSFZNIGZyb20gaXNvLCB3aGljaCBpcyBzdG9yZWQgaW4KPiBzb21lIGRvbVUuCgpJIGRpZG4n
dCBrbm93IHlvdSB3aGVyZSBhYmxlIHRvIHVzZSB2YmQgZnJvbSBkcml2ZXIgZG9tYWlucyB3aXRo
IHhsLCBpZiAKc28gSSB3aWxsIGhhdmUgdG8gYWRkIGEgc2ltaWxhciBvcHRpb24gZm9yIHZiZCBk
ZXZpY2VzIAooZGlzYWJsZV94bF92YmRfc2NyaXB0cykuCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 23 13:41:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:41:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJVJ-0005hF-6g; Mon, 23 Apr 2012 13:40:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMJVH-0005h9-8M
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 13:40:31 +0000
Received: from [85.158.143.99:56048] by server-1.bemta-4.messagelabs.com id
	7D/89-20925-CCB559F4; Mon, 23 Apr 2012 13:40:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335188427!24846399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28377 invoked from network); 23 Apr 2012 13:40:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 13:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12080301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 13:40:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 14:40:26 +0100
Message-ID: <1335188425.4347.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: bxl1989 <bxl1989@gmail.com>
Date: Mon, 23 Apr 2012 14:40:25 +0100
In-Reply-To: <1334754772414-5649046.post@n5.nabble.com>
References: <1334732874701-5648377.post@n5.nabble.com>
	<1334754772414-5649046.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make hypercall in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 14:12 +0100, bxl1989 wrote:
> please anyone help me! thans a lot

I'm afraid your message does not contain any specifics about what it is
you are asking so it is very unlikely that anyone will be able to help
you. It seems like maybe you are replying to an previous message but
there is no context (e..g quoted material) to point me in the right
direction nor can I find a previous post from you on this list in my
inbox.

Please read http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions and
consider asking your question in a different way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 13:41:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:41:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJVJ-0005hF-6g; Mon, 23 Apr 2012 13:40:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMJVH-0005h9-8M
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 13:40:31 +0000
Received: from [85.158.143.99:56048] by server-1.bemta-4.messagelabs.com id
	7D/89-20925-CCB559F4; Mon, 23 Apr 2012 13:40:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335188427!24846399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28377 invoked from network); 23 Apr 2012 13:40:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 13:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="12080301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 13:40:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 14:40:26 +0100
Message-ID: <1335188425.4347.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: bxl1989 <bxl1989@gmail.com>
Date: Mon, 23 Apr 2012 14:40:25 +0100
In-Reply-To: <1334754772414-5649046.post@n5.nabble.com>
References: <1334732874701-5648377.post@n5.nabble.com>
	<1334754772414-5649046.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make hypercall in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-18 at 14:12 +0100, bxl1989 wrote:
> please anyone help me! thans a lot

I'm afraid your message does not contain any specifics about what it is
you are asking so it is very unlikely that anyone will be able to help
you. It seems like maybe you are replying to an previous message but
there is no context (e..g quoted material) to point me in the right
direction nor can I find a previous post from you on this list in my
inbox.

Please read http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions and
consider asking your question in a different way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 13:48:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJcC-0005s0-8Q; Mon, 23 Apr 2012 13:47:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SMJcA-0005ru-Ie
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 13:47:38 +0000
Received: from [193.109.254.147:62162] by server-5.bemta-14.messagelabs.com id
	9C/CB-30733-97D559F4; Mon, 23 Apr 2012 13:47:37 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335188856!5859680!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gODQ2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11208 invoked from network); 23 Apr 2012 13:47:37 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 13:47:37 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 27634207F8;
	Mon, 23 Apr 2012 09:47:36 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute5.internal (MEProxy); Mon, 23 Apr 2012 09:47:36 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=op
	sMTLCH4h5PVPYQqlyNIHbKmlo=; b=LRNi8++oAnNgGaTN97o9bZrg7hQ6gnzkLZ
	gcQ8tchw1EEvD3Ol2p7jYFPJluGBUS9yQ38geo5MP5KDb5nxtASrN9+dD7kxiD1O
	MQcmX7ygEn44hBuRwwAlP1645jxx+jn+e1K481oM/0REpkrsNZhH3WX5y4vXYrcn
	6l4SRjdYI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=opsM
	TLCH4h5PVPYQqlyNIHbKmlo=; b=i+mnuYp+3bkL28oIbzlXM95I5SadGRXYscHR
	yAxeBUqI5c21H7cz50XX1Bly/qKgg70dmR0ZH6yyQMK1O02cMhfDZndulQ0Th6HT
	zKUNLs9YsKBlN6wKmqYyySE7r8+lJxcTCMrs49GzvKIygsATadsQjIvSi1GV9UxJ
	EuvG89o=
X-Sasl-enc: aV/tEoEyu3CNZmF3rftLVSkfrQN+d4FX8FJqDYldjVcn 1335188855
Received: from [10.137.2.11] (87-207-224-106.dynamic.chello.pl
	[87.207.224.106])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 814CC8E026B;
	Mon, 23 Apr 2012 09:47:35 -0400 (EDT)
Message-ID: <4F955D74.8060602@invisiblethingslab.com>
Date: Mon, 23 Apr 2012 15:47:32 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
	<4F955999.3030500@citrix.com>
In-Reply-To: <4F955999.3030500@citrix.com>
X-Enigmail-Version: 1.4.1
Cc: Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4993532945491766084=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============4993532945491766084==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9EB1A250486AD74FA46E96B0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9EB1A250486AD74FA46E96B0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23.04.2012 15:31, Roger Pau Monne wrote:
> Marek Marczykowski escribi=C3=B3:
>> On 20.04.2012 15:23, Roger Pau Monne wrote:
>>> This series removes the use of udev rules to call hotplug scripts whe=
n using
>>> libxl. Scripts are directly called from the toolstack at the necessar=
y points,
>>> making use of the new event library and it's fork support.
>>
>> What about non-dom0 backends? There will be no simple way to execute s=
cript
>> there by libxl without help from udev...
>=20
> A new config option has been added on this series (disable_xl_vif_scrip=
ts)
> that allows the user to keep executing vif scripts from udev, so this
> functionality is not lost.
>=20
>> In Qubes-OS we heavily use network backend in domU: dom0 have no netwo=
rk at
>> all, all NICs are attached (as PCI device) to some domU - called NetVM=
, where
>> network backend resides.
>=20
> There should be no problem with that, you will just need to use the new=
 option.
>=20
>> Also vbd backend in domU is used - eg to boot HVM from iso, which is s=
tored in
>> some domU.
>=20
> I didn't know you where able to use vbd from driver domains with xl, if=
 so I
> will have to add a similar option for vbd devices (disable_xl_vbd_scrip=
ts).

When starting domU using xl create, I needed to slightly modify disk conf=
ig
syntax in xl_cmdimpl.c to add backend field (still using xen 4.1, backend=

added as the end of disk spec). But everything else worked fine. Especial=
ly xl
block-attach, which allow to specify backend domain.
So disable_xl_vbd_scripts option will be helpful.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig9EB1A250486AD74FA46E96B0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPlV10AAoJENuP0xzK19csTXIH/0oNC1Ay/6uFqY/BFS3Uy1pj
OSRwELqlS8RxNUVcQlzzjtDeQLB4MYNPAPvJyvZa8gRjg5zb/ZVqBEEcZpK63E8L
Bj67Kb/bZSav2M/BtFrD/ojZOe5v2WAYn0Zf93AC5iJ6cSeWctPHorU6TAJJZSor
Pm/bkD3q0sE77IemlWqHnvyezvPFfe8NaZXu347X+z/kiEK+E5jvY0Z5N+qvkwMP
yqVtLDDm1Pi4e2PChq3tvZ3nE8TiNh6ZByOtwKoeYklumGzqOnQAiS8UiVpDnEA/
vZQHp6pjmHEDozFPevDQ3lK6s5Ius55Qqn4gRastQMyfzCpru4oT29EXe23S1vY=
=lnnc
-----END PGP SIGNATURE-----

--------------enig9EB1A250486AD74FA46E96B0--


--===============4993532945491766084==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4993532945491766084==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 13:48:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJcC-0005s0-8Q; Mon, 23 Apr 2012 13:47:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SMJcA-0005ru-Ie
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 13:47:38 +0000
Received: from [193.109.254.147:62162] by server-5.bemta-14.messagelabs.com id
	9C/CB-30733-97D559F4; Mon, 23 Apr 2012 13:47:37 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335188856!5859680!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gODQ2Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11208 invoked from network); 23 Apr 2012 13:47:37 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 13:47:37 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 27634207F8;
	Mon, 23 Apr 2012 09:47:36 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute5.internal (MEProxy); Mon, 23 Apr 2012 09:47:36 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=op
	sMTLCH4h5PVPYQqlyNIHbKmlo=; b=LRNi8++oAnNgGaTN97o9bZrg7hQ6gnzkLZ
	gcQ8tchw1EEvD3Ol2p7jYFPJluGBUS9yQ38geo5MP5KDb5nxtASrN9+dD7kxiD1O
	MQcmX7ygEn44hBuRwwAlP1645jxx+jn+e1K481oM/0REpkrsNZhH3WX5y4vXYrcn
	6l4SRjdYI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=opsM
	TLCH4h5PVPYQqlyNIHbKmlo=; b=i+mnuYp+3bkL28oIbzlXM95I5SadGRXYscHR
	yAxeBUqI5c21H7cz50XX1Bly/qKgg70dmR0ZH6yyQMK1O02cMhfDZndulQ0Th6HT
	zKUNLs9YsKBlN6wKmqYyySE7r8+lJxcTCMrs49GzvKIygsATadsQjIvSi1GV9UxJ
	EuvG89o=
X-Sasl-enc: aV/tEoEyu3CNZmF3rftLVSkfrQN+d4FX8FJqDYldjVcn 1335188855
Received: from [10.137.2.11] (87-207-224-106.dynamic.chello.pl
	[87.207.224.106])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 814CC8E026B;
	Mon, 23 Apr 2012 09:47:35 -0400 (EDT)
Message-ID: <4F955D74.8060602@invisiblethingslab.com>
Date: Mon, 23 Apr 2012 15:47:32 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
	<4F955999.3030500@citrix.com>
In-Reply-To: <4F955999.3030500@citrix.com>
X-Enigmail-Version: 1.4.1
Cc: Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4993532945491766084=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============4993532945491766084==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9EB1A250486AD74FA46E96B0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9EB1A250486AD74FA46E96B0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23.04.2012 15:31, Roger Pau Monne wrote:
> Marek Marczykowski escribi=C3=B3:
>> On 20.04.2012 15:23, Roger Pau Monne wrote:
>>> This series removes the use of udev rules to call hotplug scripts whe=
n using
>>> libxl. Scripts are directly called from the toolstack at the necessar=
y points,
>>> making use of the new event library and it's fork support.
>>
>> What about non-dom0 backends? There will be no simple way to execute s=
cript
>> there by libxl without help from udev...
>=20
> A new config option has been added on this series (disable_xl_vif_scrip=
ts)
> that allows the user to keep executing vif scripts from udev, so this
> functionality is not lost.
>=20
>> In Qubes-OS we heavily use network backend in domU: dom0 have no netwo=
rk at
>> all, all NICs are attached (as PCI device) to some domU - called NetVM=
, where
>> network backend resides.
>=20
> There should be no problem with that, you will just need to use the new=
 option.
>=20
>> Also vbd backend in domU is used - eg to boot HVM from iso, which is s=
tored in
>> some domU.
>=20
> I didn't know you where able to use vbd from driver domains with xl, if=
 so I
> will have to add a similar option for vbd devices (disable_xl_vbd_scrip=
ts).

When starting domU using xl create, I needed to slightly modify disk conf=
ig
syntax in xl_cmdimpl.c to add backend field (still using xen 4.1, backend=

added as the end of disk spec). But everything else worked fine. Especial=
ly xl
block-attach, which allow to specify backend domain.
So disable_xl_vbd_scripts option will be helpful.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig9EB1A250486AD74FA46E96B0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPlV10AAoJENuP0xzK19csTXIH/0oNC1Ay/6uFqY/BFS3Uy1pj
OSRwELqlS8RxNUVcQlzzjtDeQLB4MYNPAPvJyvZa8gRjg5zb/ZVqBEEcZpK63E8L
Bj67Kb/bZSav2M/BtFrD/ojZOe5v2WAYn0Zf93AC5iJ6cSeWctPHorU6TAJJZSor
Pm/bkD3q0sE77IemlWqHnvyezvPFfe8NaZXu347X+z/kiEK+E5jvY0Z5N+qvkwMP
yqVtLDDm1Pi4e2PChq3tvZ3nE8TiNh6ZByOtwKoeYklumGzqOnQAiS8UiVpDnEA/
vZQHp6pjmHEDozFPevDQ3lK6s5Ius55Qqn4gRastQMyfzCpru4oT29EXe23S1vY=
=lnnc
-----END PGP SIGNATURE-----

--------------enig9EB1A250486AD74FA46E96B0--


--===============4993532945491766084==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4993532945491766084==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 13:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJnj-00061x-J8; Mon, 23 Apr 2012 13:59:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1SMJni-00061s-0a
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 13:59:34 +0000
Received: from [85.158.138.51:19741] by server-10.bemta-3.messagelabs.com id
	55/AC-29478-540659F4; Mon, 23 Apr 2012 13:59:33 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335189564!23376066!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gODQ2Mw==\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogNTI4Nzk4NSAo
	YWJhbmRvbmVkOiB0aGVpbnZpc2libGV0aGlu\nZ3MuYmxvZ3Nwb3QuY29tKQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25487 invoked from network); 23 Apr 2012 13:59:25 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 13:59:25 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 902C520CEE;
	Mon, 23 Apr 2012 09:59:24 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Mon, 23 Apr 2012 09:59:24 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=u6
	QS30h7iJl/9O93vfJ6hTXpJU8=; b=d5zqVvx1M600WV2g7fXdGi8Iibb022HS9A
	hXdba44XgGSzJ8gSDEFsZUzcQnZ2iWZ1uRmM0cshWKSjYkC+mvXto8rb7h+aG6Lk
	FU3275uATcBuus8kl/29Jj7qpcRk8v715JRa7nFjV4NB3Xbunz8+tc6ZCvjKiVXU
	9blw1z+SQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=u6QS
	30h7iJl/9O93vfJ6hTXpJU8=; b=qstFMbuCAv5oC42s2f7n0LyvBjhaIEayQFHT
	i+XTL/5gnMKLg5KPmvHpp+6ZjYqbRgzoVJOwyQNXFv+rYUXxSf4AipWAogKdrP4j
	fKaBB5K4rirNTxEeni7alzTg8QRjUz2dN9tt470iV+vjMQJqhs4nOX3j+yeGbmsP
	M5EbzF8=
X-Sasl-enc: dH0uFV5qYa+5EJk4nJzmBGerMugrp8KAiWcWKoIUcf+O 1335189564
Received: from [10.137.2.24] (afmj246.neoplus.adsl.tpnet.pl [178.42.61.246])
	by mail.messagingengine.com (Postfix) with ESMTPSA id B4082482439;
	Mon, 23 Apr 2012 09:59:23 -0400 (EDT)
Message-ID: <4F956038.9090004@invisiblethingslab.com>
Date: Mon, 23 Apr 2012 15:59:20 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
	<4F955999.3030500@citrix.com>
	<4F955D74.8060602@invisiblethingslab.com>
In-Reply-To: <4F955D74.8060602@invisiblethingslab.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] Non-dom0 block backends (was: Re: [PATCH v3 0/5] libxl:
 call hotplug scripts from libxl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8894937155297097642=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8894937155297097642==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigDD19693315AF6622E2FD3E7A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDD19693315AF6622E2FD3E7A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 04/23/12 15:47, Marek Marczykowski wrote:
/.../
>>> >> Also vbd backend in domU is used - eg to boot HVM from iso, which =
is stored in
>>> >> some domU.
>> >=20
>> > I didn't know you where able to use vbd from driver domains with xl,=
 if so I
>> > will have to add a similar option for vbd devices (disable_xl_vbd_sc=
ripts).
> When starting domU using xl create, I needed to slightly modify disk co=
nfig
> syntax in xl_cmdimpl.c to add backend field (still using xen 4.1, backe=
nd
> added as the end of disk spec). But everything else worked fine. Especi=
ally xl
> block-attach, which allow to specify backend domain.
> So disable_xl_vbd_scripts option will be helpful.

On a side note: some cool applications of this:

1) We can have a UsbVM, which has assigned all the USB controllers (pci
attach), which greatly minimizes threats from various USB attacks [1] on
the overall system. Now, if one plugs a USB disk, those disks can be
made available to other domains, without the need for Dom0 to plug them
(so no need to parse their, untrusted, partition tables, or other fs
metadata).

2) We can store various installation ISOs, e.g. that cool new "hacker"
Linux distro ISO, and pass it to an HVM domain (for installation)
directly from the VM where we downloaded it (e.g.
"untrusted-internet-browsing-vm") without the need to store it first on
the Dom0 fs.

joanna.

[1]
http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.ht=
ml


--------------enigDD19693315AF6622E2FD3E7A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPlWA4AAoJEDaIqHeRBUM0/2MIAKQtTTs1b031mHNsSF1hLdw+
ufImJx9x8UKANmV6rRS7pAamUVshgB/LxOuzU/2dfyodOmquKHkpKqRMCl1vy7Oy
5FuDFcK75uxyQT59dNOLRYeB1kLovE5vIFL9v2ysmdE9NLgK27OhM/rI5Wlu7zw3
x2btzXTa0MxWNEGCr7zQ+2IPgCqvVs09CS00OSbg6ChE+XCsh7AAmAZ4RkVbDGrf
t1h2TkwZRzo/5A/gCXS21CBs4TjUksV6sftwyZ+9jWoGBE0XgHzuuIwqn7/zp8RM
CMCiC/FCw8gcWmGL4TLwcWvZYCHxxxM5cdqOdYXrAvrTnvaxu9kyQDS64ueMv/I=
=coAg
-----END PGP SIGNATURE-----

--------------enigDD19693315AF6622E2FD3E7A--


--===============8894937155297097642==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8894937155297097642==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 13:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 13:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJnj-00061x-J8; Mon, 23 Apr 2012 13:59:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1SMJni-00061s-0a
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 13:59:34 +0000
Received: from [85.158.138.51:19741] by server-10.bemta-3.messagelabs.com id
	55/AC-29478-540659F4; Mon, 23 Apr 2012 13:59:33 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335189564!23376066!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gODQ2Mw==\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogNTI4Nzk4NSAo
	YWJhbmRvbmVkOiB0aGVpbnZpc2libGV0aGlu\nZ3MuYmxvZ3Nwb3QuY29tKQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25487 invoked from network); 23 Apr 2012 13:59:25 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 13:59:25 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 902C520CEE;
	Mon, 23 Apr 2012 09:59:24 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Mon, 23 Apr 2012 09:59:24 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=u6
	QS30h7iJl/9O93vfJ6hTXpJU8=; b=d5zqVvx1M600WV2g7fXdGi8Iibb022HS9A
	hXdba44XgGSzJ8gSDEFsZUzcQnZ2iWZ1uRmM0cshWKSjYkC+mvXto8rb7h+aG6Lk
	FU3275uATcBuus8kl/29Jj7qpcRk8v715JRa7nFjV4NB3Xbunz8+tc6ZCvjKiVXU
	9blw1z+SQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=u6QS
	30h7iJl/9O93vfJ6hTXpJU8=; b=qstFMbuCAv5oC42s2f7n0LyvBjhaIEayQFHT
	i+XTL/5gnMKLg5KPmvHpp+6ZjYqbRgzoVJOwyQNXFv+rYUXxSf4AipWAogKdrP4j
	fKaBB5K4rirNTxEeni7alzTg8QRjUz2dN9tt470iV+vjMQJqhs4nOX3j+yeGbmsP
	M5EbzF8=
X-Sasl-enc: dH0uFV5qYa+5EJk4nJzmBGerMugrp8KAiWcWKoIUcf+O 1335189564
Received: from [10.137.2.24] (afmj246.neoplus.adsl.tpnet.pl [178.42.61.246])
	by mail.messagingengine.com (Postfix) with ESMTPSA id B4082482439;
	Mon, 23 Apr 2012 09:59:23 -0400 (EDT)
Message-ID: <4F956038.9090004@invisiblethingslab.com>
Date: Mon, 23 Apr 2012 15:59:20 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
	<4F955999.3030500@citrix.com>
	<4F955D74.8060602@invisiblethingslab.com>
In-Reply-To: <4F955D74.8060602@invisiblethingslab.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] Non-dom0 block backends (was: Re: [PATCH v3 0/5] libxl:
 call hotplug scripts from libxl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8894937155297097642=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8894937155297097642==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigDD19693315AF6622E2FD3E7A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDD19693315AF6622E2FD3E7A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 04/23/12 15:47, Marek Marczykowski wrote:
/.../
>>> >> Also vbd backend in domU is used - eg to boot HVM from iso, which =
is stored in
>>> >> some domU.
>> >=20
>> > I didn't know you where able to use vbd from driver domains with xl,=
 if so I
>> > will have to add a similar option for vbd devices (disable_xl_vbd_sc=
ripts).
> When starting domU using xl create, I needed to slightly modify disk co=
nfig
> syntax in xl_cmdimpl.c to add backend field (still using xen 4.1, backe=
nd
> added as the end of disk spec). But everything else worked fine. Especi=
ally xl
> block-attach, which allow to specify backend domain.
> So disable_xl_vbd_scripts option will be helpful.

On a side note: some cool applications of this:

1) We can have a UsbVM, which has assigned all the USB controllers (pci
attach), which greatly minimizes threats from various USB attacks [1] on
the overall system. Now, if one plugs a USB disk, those disks can be
made available to other domains, without the need for Dom0 to plug them
(so no need to parse their, untrusted, partition tables, or other fs
metadata).

2) We can store various installation ISOs, e.g. that cool new "hacker"
Linux distro ISO, and pass it to an HVM domain (for installation)
directly from the VM where we downloaded it (e.g.
"untrusted-internet-browsing-vm") without the need to store it first on
the Dom0 fs.

joanna.

[1]
http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.ht=
ml


--------------enigDD19693315AF6622E2FD3E7A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPlWA4AAoJEDaIqHeRBUM0/2MIAKQtTTs1b031mHNsSF1hLdw+
ufImJx9x8UKANmV6rRS7pAamUVshgB/LxOuzU/2dfyodOmquKHkpKqRMCl1vy7Oy
5FuDFcK75uxyQT59dNOLRYeB1kLovE5vIFL9v2ysmdE9NLgK27OhM/rI5Wlu7zw3
x2btzXTa0MxWNEGCr7zQ+2IPgCqvVs09CS00OSbg6ChE+XCsh7AAmAZ4RkVbDGrf
t1h2TkwZRzo/5A/gCXS21CBs4TjUksV6sftwyZ+9jWoGBE0XgHzuuIwqn7/zp8RM
CMCiC/FCw8gcWmGL4TLwcWvZYCHxxxM5cdqOdYXrAvrTnvaxu9kyQDS64ueMv/I=
=coAg
-----END PGP SIGNATURE-----

--------------enigDD19693315AF6622E2FD3E7A--


--===============8894937155297097642==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8894937155297097642==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 14:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJrb-0006C9-8q; Mon, 23 Apr 2012 14:03:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMJrZ-0006C4-M2
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 14:03:33 +0000
Received: from [85.158.143.99:56976] by server-2.bemta-4.messagelabs.com id
	3B/90-17550-431659F4; Mon, 23 Apr 2012 14:03:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335189811!24333392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23332 invoked from network); 23 Apr 2012 14:03:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 14:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12081443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 14:02:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 15:02:32 +0100
Message-ID: <1335189749.4347.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 23 Apr 2012 15:02:29 +0100
In-Reply-To: <4F955999.3030500@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com> <4F955999.3030500@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
 libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA0LTIzIGF0IDE0OjMxICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gTWFyZWsgTWFyY3p5a293c2tpIGVzY3JpYmnDszoKPiA+IE9uIDIwLjA0LjIwMTIgMTU6MjMs
IFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiA+PiBUaGlzIHNlcmllcyByZW1vdmVzIHRoZSB1c2Ug
b2YgdWRldiBydWxlcyB0byBjYWxsIGhvdHBsdWcgc2NyaXB0cyB3aGVuIHVzaW5nCj4gPj4gbGli
eGwuIFNjcmlwdHMgYXJlIGRpcmVjdGx5IGNhbGxlZCBmcm9tIHRoZSB0b29sc3RhY2sgYXQgdGhl
IG5lY2Vzc2FyeSBwb2ludHMsCj4gPj4gbWFraW5nIHVzZSBvZiB0aGUgbmV3IGV2ZW50IGxpYnJh
cnkgYW5kIGl0J3MgZm9yayBzdXBwb3J0Lgo+ID4KPiA+IFdoYXQgYWJvdXQgbm9uLWRvbTAgYmFj
a2VuZHM/IFRoZXJlIHdpbGwgYmUgbm8gc2ltcGxlIHdheSB0byBleGVjdXRlIHNjcmlwdAo+ID4g
dGhlcmUgYnkgbGlieGwgd2l0aG91dCBoZWxwIGZyb20gdWRldi4uLgo+IAo+IEEgbmV3IGNvbmZp
ZyBvcHRpb24gaGFzIGJlZW4gYWRkZWQgb24gdGhpcyBzZXJpZXMgCj4gKGRpc2FibGVfeGxfdmlm
X3NjcmlwdHMpIHRoYXQgYWxsb3dzIHRoZSB1c2VyIHRvIGtlZXAgZXhlY3V0aW5nIHZpZiAKPiBz
Y3JpcHRzIGZyb20gdWRldiwgc28gdGhpcyBmdW5jdGlvbmFsaXR5IGlzIG5vdCBsb3N0LgoKSW4g
dGhlIGxvbmcgdGVybSAoZS5nLiBmb3IgNC4zKSB3ZSBpbnRlbmQgdG8gb3ZlcmhhdWwgdGhpcyBp
biBhIHdheQp3aGljaCBtYWtlcyBkcml2ZXIgZG9tYWlucyB3b3JrIHdpdGhvdXQgdWRldiBhdCBh
bGwsIHNlZSAiRHJpdmVyIGRvbWFpbnMKY29tbXVuaWNhdGlvbiBwcm90b2NvbCBwcm9wb3NhbCIg
cG9zdGVkIGJ5IElhbiBKYWNrc29uIHNldmVyYWwgd2Vla3MgYWdvCi0tIGl0IHdvdWxkIGJlIGdv
b2QgdG8gY29uZmlybSB0aGF0IHRoZSBzY2hlbWUgcHJvcG9zZWQgdGhlcmUgd29ya3Mgd2VsbApm
b3IgUXViZXMtT1MgdG9vLgoKSW4gdGhlIHNob3J0IHRlcm0gKGkuZS4gNC4yKSB3ZSBmZWx0IGl0
IHdhcyB0b28gbGF0ZSB0byBiZSBtYWtpbmcgdGhlc2UKc29ydHMgb2YgY2hhbmdlcyAoZS5nLiBp
bXBsZW1lbnRpbmcgdGhhdCBjb21wbGV0ZSBwcm90b2NvbCkgYW5kCnRoZXJlZm9yZSB0aGUgY29t
cHJvbWlzZSBpcyB0aGF0IHhsIHdpbGwgZXhlY3V0ZSB0aGUgc2NyaXB0cyBvbmx5IGluIHRoZQpj
YXNlIHRoYXQgZG9tMCBpcyBhbHNvIHRoZSBiYWNrZW5kIGRvbWFpbiB3aGlsZSBmb3IgZHJpdmVy
IGRvbWFpbnMgd2UKcmV0YWluIHRoZSBwcmUtNC4yIGJlaGF2aW91ciBvZiBleGVjdXRpbmcgdGhl
IGhvdHBsdWcgc2NyaXB0cyB2aWEgdWRldgppbnNpZGUgdGhlIGRyaXZlciBkb21haW4uIFRoaXMg
d2FzIG5lY2Vzc2FyeSBpbiBvcmRlciB0byBmaXggdGhpbmdzIHN1Y2gKYXMgdGVhcmRvd24gb2Yg
ZGlza3Mgb24gTmV0QlNEIGFuZCB0ZWFyZG93biBvZiBOSUNzIG9uIG9wZW52c3dpdGNoCihjdXJy
ZW50bHkgYm90aCBhcmUgYnJva2VuIGV2ZW4gd2l0aCBiYWNrZW5kID0gZG9tMCBkdWUgdG8gc2hv
cnQgY29taW5ncwppbiB0aGUgcHJldmlvdXMgYXBwcm9hY2gpIHdoaWxlIG5vdCByZWdyZXNzaW5n
IHRoZSBkcml2ZXIgZG9tYWluIHVzZQpjYXNlLgoKQnkgZGVmYXVsdCBkbyB3ZSB3cml0ZSB0aGUg
eGVuc3RvcmUga2V5IHRvIHN1cHByZXNzIHVkZXYgcnVubmluZyB0aGUKc2NyaXB0cyByZWdhcmRs
ZXNzIG9mIHdoaWNoIGRvbWFpbiB0aGUgYmFja2VuZCBpcyBpbiBvciBvbmx5IGZvcgpiYWNrZW5k
PTA/IE9yIGlzIGl0IG5lY2Vzc2FyeSB0byB1c2UgdGhlIG92ZXJyaWRlIGNvbmZpZyBvcHRpb24g
Zm9yCmRyaXZlciBkb21haW4/CgpJYW4uCgo+ID4gSW4gUXViZXMtT1Mgd2UgaGVhdmlseSB1c2Ug
bmV0d29yayBiYWNrZW5kIGluIGRvbVU6IGRvbTAgaGF2ZSBubyBuZXR3b3JrIGF0Cj4gPiBhbGws
IGFsbCBOSUNzIGFyZSBhdHRhY2hlZCAoYXMgUENJIGRldmljZSkgdG8gc29tZSBkb21VIC0gY2Fs
bGVkIE5ldFZNLCB3aGVyZQo+ID4gbmV0d29yayBiYWNrZW5kIHJlc2lkZXMuCj4gCj4gVGhlcmUg
c2hvdWxkIGJlIG5vIHByb2JsZW0gd2l0aCB0aGF0LCB5b3Ugd2lsbCBqdXN0IG5lZWQgdG8gdXNl
IHRoZSBuZXcgCj4gb3B0aW9uLgo+IAo+ID4gQWxzbyB2YmQgYmFja2VuZCBpbiBkb21VIGlzIHVz
ZWQgLSBlZyB0byBib290IEhWTSBmcm9tIGlzbywgd2hpY2ggaXMgc3RvcmVkIGluCj4gPiBzb21l
IGRvbVUuCj4gCj4gSSBkaWRuJ3Qga25vdyB5b3Ugd2hlcmUgYWJsZSB0byB1c2UgdmJkIGZyb20g
ZHJpdmVyIGRvbWFpbnMgd2l0aCB4bCwgaWYgCj4gc28gSSB3aWxsIGhhdmUgdG8gYWRkIGEgc2lt
aWxhciBvcHRpb24gZm9yIHZiZCBkZXZpY2VzIAo+IChkaXNhYmxlX3hsX3ZiZF9zY3JpcHRzKS4K
PiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Apr 23 14:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMJrb-0006C9-8q; Mon, 23 Apr 2012 14:03:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMJrZ-0006C4-M2
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 14:03:33 +0000
Received: from [85.158.143.99:56976] by server-2.bemta-4.messagelabs.com id
	3B/90-17550-431659F4; Mon, 23 Apr 2012 14:03:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335189811!24333392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23332 invoked from network); 23 Apr 2012 14:03:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 14:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12081443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 14:02:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 15:02:32 +0100
Message-ID: <1335189749.4347.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 23 Apr 2012 15:02:29 +0100
In-Reply-To: <4F955999.3030500@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com> <4F955999.3030500@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
 libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA0LTIzIGF0IDE0OjMxICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gTWFyZWsgTWFyY3p5a293c2tpIGVzY3JpYmnDszoKPiA+IE9uIDIwLjA0LjIwMTIgMTU6MjMs
IFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiA+PiBUaGlzIHNlcmllcyByZW1vdmVzIHRoZSB1c2Ug
b2YgdWRldiBydWxlcyB0byBjYWxsIGhvdHBsdWcgc2NyaXB0cyB3aGVuIHVzaW5nCj4gPj4gbGli
eGwuIFNjcmlwdHMgYXJlIGRpcmVjdGx5IGNhbGxlZCBmcm9tIHRoZSB0b29sc3RhY2sgYXQgdGhl
IG5lY2Vzc2FyeSBwb2ludHMsCj4gPj4gbWFraW5nIHVzZSBvZiB0aGUgbmV3IGV2ZW50IGxpYnJh
cnkgYW5kIGl0J3MgZm9yayBzdXBwb3J0Lgo+ID4KPiA+IFdoYXQgYWJvdXQgbm9uLWRvbTAgYmFj
a2VuZHM/IFRoZXJlIHdpbGwgYmUgbm8gc2ltcGxlIHdheSB0byBleGVjdXRlIHNjcmlwdAo+ID4g
dGhlcmUgYnkgbGlieGwgd2l0aG91dCBoZWxwIGZyb20gdWRldi4uLgo+IAo+IEEgbmV3IGNvbmZp
ZyBvcHRpb24gaGFzIGJlZW4gYWRkZWQgb24gdGhpcyBzZXJpZXMgCj4gKGRpc2FibGVfeGxfdmlm
X3NjcmlwdHMpIHRoYXQgYWxsb3dzIHRoZSB1c2VyIHRvIGtlZXAgZXhlY3V0aW5nIHZpZiAKPiBz
Y3JpcHRzIGZyb20gdWRldiwgc28gdGhpcyBmdW5jdGlvbmFsaXR5IGlzIG5vdCBsb3N0LgoKSW4g
dGhlIGxvbmcgdGVybSAoZS5nLiBmb3IgNC4zKSB3ZSBpbnRlbmQgdG8gb3ZlcmhhdWwgdGhpcyBp
biBhIHdheQp3aGljaCBtYWtlcyBkcml2ZXIgZG9tYWlucyB3b3JrIHdpdGhvdXQgdWRldiBhdCBh
bGwsIHNlZSAiRHJpdmVyIGRvbWFpbnMKY29tbXVuaWNhdGlvbiBwcm90b2NvbCBwcm9wb3NhbCIg
cG9zdGVkIGJ5IElhbiBKYWNrc29uIHNldmVyYWwgd2Vla3MgYWdvCi0tIGl0IHdvdWxkIGJlIGdv
b2QgdG8gY29uZmlybSB0aGF0IHRoZSBzY2hlbWUgcHJvcG9zZWQgdGhlcmUgd29ya3Mgd2VsbApm
b3IgUXViZXMtT1MgdG9vLgoKSW4gdGhlIHNob3J0IHRlcm0gKGkuZS4gNC4yKSB3ZSBmZWx0IGl0
IHdhcyB0b28gbGF0ZSB0byBiZSBtYWtpbmcgdGhlc2UKc29ydHMgb2YgY2hhbmdlcyAoZS5nLiBp
bXBsZW1lbnRpbmcgdGhhdCBjb21wbGV0ZSBwcm90b2NvbCkgYW5kCnRoZXJlZm9yZSB0aGUgY29t
cHJvbWlzZSBpcyB0aGF0IHhsIHdpbGwgZXhlY3V0ZSB0aGUgc2NyaXB0cyBvbmx5IGluIHRoZQpj
YXNlIHRoYXQgZG9tMCBpcyBhbHNvIHRoZSBiYWNrZW5kIGRvbWFpbiB3aGlsZSBmb3IgZHJpdmVy
IGRvbWFpbnMgd2UKcmV0YWluIHRoZSBwcmUtNC4yIGJlaGF2aW91ciBvZiBleGVjdXRpbmcgdGhl
IGhvdHBsdWcgc2NyaXB0cyB2aWEgdWRldgppbnNpZGUgdGhlIGRyaXZlciBkb21haW4uIFRoaXMg
d2FzIG5lY2Vzc2FyeSBpbiBvcmRlciB0byBmaXggdGhpbmdzIHN1Y2gKYXMgdGVhcmRvd24gb2Yg
ZGlza3Mgb24gTmV0QlNEIGFuZCB0ZWFyZG93biBvZiBOSUNzIG9uIG9wZW52c3dpdGNoCihjdXJy
ZW50bHkgYm90aCBhcmUgYnJva2VuIGV2ZW4gd2l0aCBiYWNrZW5kID0gZG9tMCBkdWUgdG8gc2hv
cnQgY29taW5ncwppbiB0aGUgcHJldmlvdXMgYXBwcm9hY2gpIHdoaWxlIG5vdCByZWdyZXNzaW5n
IHRoZSBkcml2ZXIgZG9tYWluIHVzZQpjYXNlLgoKQnkgZGVmYXVsdCBkbyB3ZSB3cml0ZSB0aGUg
eGVuc3RvcmUga2V5IHRvIHN1cHByZXNzIHVkZXYgcnVubmluZyB0aGUKc2NyaXB0cyByZWdhcmRs
ZXNzIG9mIHdoaWNoIGRvbWFpbiB0aGUgYmFja2VuZCBpcyBpbiBvciBvbmx5IGZvcgpiYWNrZW5k
PTA/IE9yIGlzIGl0IG5lY2Vzc2FyeSB0byB1c2UgdGhlIG92ZXJyaWRlIGNvbmZpZyBvcHRpb24g
Zm9yCmRyaXZlciBkb21haW4/CgpJYW4uCgo+ID4gSW4gUXViZXMtT1Mgd2UgaGVhdmlseSB1c2Ug
bmV0d29yayBiYWNrZW5kIGluIGRvbVU6IGRvbTAgaGF2ZSBubyBuZXR3b3JrIGF0Cj4gPiBhbGws
IGFsbCBOSUNzIGFyZSBhdHRhY2hlZCAoYXMgUENJIGRldmljZSkgdG8gc29tZSBkb21VIC0gY2Fs
bGVkIE5ldFZNLCB3aGVyZQo+ID4gbmV0d29yayBiYWNrZW5kIHJlc2lkZXMuCj4gCj4gVGhlcmUg
c2hvdWxkIGJlIG5vIHByb2JsZW0gd2l0aCB0aGF0LCB5b3Ugd2lsbCBqdXN0IG5lZWQgdG8gdXNl
IHRoZSBuZXcgCj4gb3B0aW9uLgo+IAo+ID4gQWxzbyB2YmQgYmFja2VuZCBpbiBkb21VIGlzIHVz
ZWQgLSBlZyB0byBib290IEhWTSBmcm9tIGlzbywgd2hpY2ggaXMgc3RvcmVkIGluCj4gPiBzb21l
IGRvbVUuCj4gCj4gSSBkaWRuJ3Qga25vdyB5b3Ugd2hlcmUgYWJsZSB0byB1c2UgdmJkIGZyb20g
ZHJpdmVyIGRvbWFpbnMgd2l0aCB4bCwgaWYgCj4gc28gSSB3aWxsIGhhdmUgdG8gYWRkIGEgc2lt
aWxhciBvcHRpb24gZm9yIHZiZCBkZXZpY2VzIAo+IChkaXNhYmxlX3hsX3ZiZF9zY3JpcHRzKS4K
PiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Apr 23 14:21:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:21:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMK8c-0006Tf-VK; Mon, 23 Apr 2012 14:21:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMK8b-0006TS-Io
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 14:21:09 +0000
Received: from [193.109.254.147:8066] by server-12.bemta-14.messagelabs.com id
	B9/C2-05898-455659F4; Mon, 23 Apr 2012 14:21:08 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335190864!5870358!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26909 invoked from network); 23 Apr 2012 14:21:06 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Apr 2012 14:21:06 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMK8W-0005Vd-1h
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:21:04 -0700
Date: Mon, 23 Apr 2012 07:21:04 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335190864041-5659521.post@n5.nabble.com>
In-Reply-To: <1334920571945-5653963.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
	<1334917612.28331.34.camel@zakaz.uk.xensource.com>
	<1334920571945-5653963.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> Thanks for reply.
> What I must write for emply virtual cdrom? I tried 'hdc,ro,cdrom' but
> return parsing error.
> 
> I also tried cd-eject with this configuration:
> ---------------------------------------
> name='XP'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc,ro,cdrom']
> #disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> boot='cd'
> xen_platform_pci=1
> viridian=1
> device_model_version="qemu-xen"
> #device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #spice=1
> #spicehost="0.0.0.0"
> #spiceport=6000
> #spicedisable_ticketing=1
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> stdvga=0
> #device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
> #videoram=128
> #device_model_args=["-vga qxl"]
> ---------------------------------------
> 
> And return this error:
> xl cd-eject XP hdc
> command line: config parsing error in disk specification: unknown value
> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
> 
> xl cd-eject is not full compatible with new disk configuration? (the cdrom
> added on xl configuration file is working)
> 

I Try also with:
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc:cdrom,r']
But always same error on eject:
xl cd-eject XP hdc
command line: config parsing error in disk specification: unknown value for
format: near `hdc:cdrom' in `,hdc:cdrom,r'

Seem not refer to domU configuration files but xl bug

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5659521.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 14:21:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:21:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMK8c-0006Tf-VK; Mon, 23 Apr 2012 14:21:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMK8b-0006TS-Io
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 14:21:09 +0000
Received: from [193.109.254.147:8066] by server-12.bemta-14.messagelabs.com id
	B9/C2-05898-455659F4; Mon, 23 Apr 2012 14:21:08 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335190864!5870358!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26909 invoked from network); 23 Apr 2012 14:21:06 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Apr 2012 14:21:06 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMK8W-0005Vd-1h
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:21:04 -0700
Date: Mon, 23 Apr 2012 07:21:04 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335190864041-5659521.post@n5.nabble.com>
In-Reply-To: <1334920571945-5653963.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
	<1334917612.28331.34.camel@zakaz.uk.xensource.com>
	<1334920571945-5653963.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> Thanks for reply.
> What I must write for emply virtual cdrom? I tried 'hdc,ro,cdrom' but
> return parsing error.
> 
> I also tried cd-eject with this configuration:
> ---------------------------------------
> name='XP'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc,ro,cdrom']
> #disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> boot='cd'
> xen_platform_pci=1
> viridian=1
> device_model_version="qemu-xen"
> #device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #spice=1
> #spicehost="0.0.0.0"
> #spiceport=6000
> #spicedisable_ticketing=1
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> stdvga=0
> #device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
> #videoram=128
> #device_model_args=["-vga qxl"]
> ---------------------------------------
> 
> And return this error:
> xl cd-eject XP hdc
> command line: config parsing error in disk specification: unknown value
> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
> 
> xl cd-eject is not full compatible with new disk configuration? (the cdrom
> added on xl configuration file is working)
> 

I Try also with:
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc:cdrom,r']
But always same error on eject:
xl cd-eject XP hdc
command line: config parsing error in disk specification: unknown value for
format: near `hdc:cdrom' in `,hdc:cdrom,r'

Seem not refer to domU configuration files but xl bug

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5659521.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 14:23:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKAb-0006Xw-I5; Mon, 23 Apr 2012 14:23:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SMKAZ-0006Xm-KB
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 14:23:11 +0000
Received: from [85.158.143.99:36966] by server-2.bemta-4.messagelabs.com id
	04/B4-17550-EC5659F4; Mon, 23 Apr 2012 14:23:10 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335190989!15249340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20883 invoked from network); 23 Apr 2012 14:23:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 14:23:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; 
   d="scan'";a="12082320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 14:22:52 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 15:22:52 +0100
Message-ID: <1335190962.3122.10.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Apr 2012 16:22:42 +0200
In-Reply-To: <1335182682.4347.15.camel@zakaz.uk.xensource.com>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dieter Bloms <xensource.com@bloms.de>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2488772583394686957=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2488772583394686957==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-O/1aVUApPgk2DxkScTqr"

--=-O/1aVUApPgk2DxkScTqr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-04-23 at 13:04 +0100, Ian Campbell wrote:=20
> > I've made a little patch to set the cpu_weight for credit, credit2 and
> > sedf scheduler from the config file.
>=20
> Awesome, thank you!
>=20
Agreed, nice work and thank you for doing it!

> > Btw.: for the sedf scheduler there seems to be some type mismatch. =20
> > The functions xc_sedf_domain_set and xc_sedf_domain_get expect the type
> > 'uint16_t' for variables 'extratime' and 'weight' while the structure
> > 'xen_domctl_sched_sedf' defines the type uint32_t for them.
> > I think they should be the same, or not ?
>=20
> I'm not clear enough on the scheduling stuff to be able to say one way
> or another. I'd be inclined to suggest that if this needs to change for
> some reason then we should leave it for post 4.2.
>=20
In Xen's SEDF code weight is a 'short', while extratime is nothing more
than a boolean flag (it can store only the EXTRA_AWARE flag). So I think
it would be worth looking at this, but I agree we ca defer that for now,
especially considering the whole SEDF interface might need some
restructuring! :-/

> >      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> >      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,
> > &info->cpumap);
> >      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> > LIBXL_MAXMEM_CONSTANT);
> > +
> > +    sched =3D libxl_get_scheduler (ctx);
> > +   =20
> > +    switch (sched) {
> > +    case LIBXL_SCHEDULER_SEDF:
> > +      xc_sedf_domain_get (ctx->xch, domid, &(sched_op.u.sedf.period),
> > &(sched_op.u.sedf.slice), &(sched_op.u.sedf.latency), (uint16_t *)
> > &(sched_op.u.sedf.extratime), (uint16_t *) &(sched_op.u.sedf.weight));
> > +      sched_op.u.sedf.weight =3D info->weight;
> > +      xc_sedf_domain_set (ctx->xch, domid, sched_op.u.sedf.period,
> > sched_op.u.sedf.slice, sched_op.u.sedf.latency, (uint16_t)
> > sched_op.u.sedf.extratime, (uint16_t) sched_op.u.sedf.weight);
>=20
> Wow, that's a pretty sucky interface at the libxc level! Anyway no need
> for you to fix it here but please do wrap your lines to <80 columns for
> readability.
>=20
Indeed! I really think we have to do something about this, but that
definitely will happen post-release. :-)

> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 5cf9708..f185d4c 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -232,6 +232,8 @@ MemKB =3D UInt(64, init_val =3D "LIBXL_MEMKB_DEFAUL=
T")
> >  libxl_domain_build_info =3D Struct("domain_build_info",[
> >      ("max_vcpus",       integer),
> >      ("cur_vcpus",       integer),
> > +    ("weight",          integer),
> > +    ("cap",             integer),
>=20
> Are these values common parameters to all schedulers? Do they always
> have the same meaning/units/etc?
>=20
Maybe weight is, but still, I think having some mechanism for specifying
the full set of parameter of a specific scheduler is to be preferred...

> I wonder if perhaps including each of libxl_sched_*_params in build_info
> might be a preferable interface? I would probably cleanup the above code
> in build_pre too since you could just call the appropriate
> libxl_sched_*_params_set.
>=20
... Exactly, that's much better looking to me.

> Ideally libxl_sched_*_params would be in a union in
> libxl_domain_build_info but that would require that xl could easily
> determine which scheduler was going to be used for the domain, having a
> non-union here would keep things somewhat simpler from that PoV.
>=20
Yes, again, I agree that a union will be even better, but maybe not so
much a big deal for now (we can turn it into an union later, right? Or
you think there will be some API implications?)

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-O/1aVUApPgk2DxkScTqr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+VZbIACgkQk4XaBE3IOsQr6QCfRH22XlfzvX0wMWINceq9gmXP
RpgAoIaWN32GxCjiMtvIVCRq8gGWxlFg
=U+kJ
-----END PGP SIGNATURE-----

--=-O/1aVUApPgk2DxkScTqr--


--===============2488772583394686957==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2488772583394686957==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 14:23:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKAb-0006Xw-I5; Mon, 23 Apr 2012 14:23:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SMKAZ-0006Xm-KB
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 14:23:11 +0000
Received: from [85.158.143.99:36966] by server-2.bemta-4.messagelabs.com id
	04/B4-17550-EC5659F4; Mon, 23 Apr 2012 14:23:10 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335190989!15249340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20883 invoked from network); 23 Apr 2012 14:23:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 14:23:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; 
   d="scan'";a="12082320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 14:22:52 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 15:22:52 +0100
Message-ID: <1335190962.3122.10.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Apr 2012 16:22:42 +0200
In-Reply-To: <1335182682.4347.15.camel@zakaz.uk.xensource.com>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dieter Bloms <xensource.com@bloms.de>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2488772583394686957=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2488772583394686957==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-O/1aVUApPgk2DxkScTqr"

--=-O/1aVUApPgk2DxkScTqr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-04-23 at 13:04 +0100, Ian Campbell wrote:=20
> > I've made a little patch to set the cpu_weight for credit, credit2 and
> > sedf scheduler from the config file.
>=20
> Awesome, thank you!
>=20
Agreed, nice work and thank you for doing it!

> > Btw.: for the sedf scheduler there seems to be some type mismatch. =20
> > The functions xc_sedf_domain_set and xc_sedf_domain_get expect the type
> > 'uint16_t' for variables 'extratime' and 'weight' while the structure
> > 'xen_domctl_sched_sedf' defines the type uint32_t for them.
> > I think they should be the same, or not ?
>=20
> I'm not clear enough on the scheduling stuff to be able to say one way
> or another. I'd be inclined to suggest that if this needs to change for
> some reason then we should leave it for post 4.2.
>=20
In Xen's SEDF code weight is a 'short', while extratime is nothing more
than a boolean flag (it can store only the EXTRA_AWARE flag). So I think
it would be worth looking at this, but I agree we ca defer that for now,
especially considering the whole SEDF interface might need some
restructuring! :-/

> >      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> >      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,
> > &info->cpumap);
> >      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> > LIBXL_MAXMEM_CONSTANT);
> > +
> > +    sched =3D libxl_get_scheduler (ctx);
> > +   =20
> > +    switch (sched) {
> > +    case LIBXL_SCHEDULER_SEDF:
> > +      xc_sedf_domain_get (ctx->xch, domid, &(sched_op.u.sedf.period),
> > &(sched_op.u.sedf.slice), &(sched_op.u.sedf.latency), (uint16_t *)
> > &(sched_op.u.sedf.extratime), (uint16_t *) &(sched_op.u.sedf.weight));
> > +      sched_op.u.sedf.weight =3D info->weight;
> > +      xc_sedf_domain_set (ctx->xch, domid, sched_op.u.sedf.period,
> > sched_op.u.sedf.slice, sched_op.u.sedf.latency, (uint16_t)
> > sched_op.u.sedf.extratime, (uint16_t) sched_op.u.sedf.weight);
>=20
> Wow, that's a pretty sucky interface at the libxc level! Anyway no need
> for you to fix it here but please do wrap your lines to <80 columns for
> readability.
>=20
Indeed! I really think we have to do something about this, but that
definitely will happen post-release. :-)

> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 5cf9708..f185d4c 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -232,6 +232,8 @@ MemKB =3D UInt(64, init_val =3D "LIBXL_MEMKB_DEFAUL=
T")
> >  libxl_domain_build_info =3D Struct("domain_build_info",[
> >      ("max_vcpus",       integer),
> >      ("cur_vcpus",       integer),
> > +    ("weight",          integer),
> > +    ("cap",             integer),
>=20
> Are these values common parameters to all schedulers? Do they always
> have the same meaning/units/etc?
>=20
Maybe weight is, but still, I think having some mechanism for specifying
the full set of parameter of a specific scheduler is to be preferred...

> I wonder if perhaps including each of libxl_sched_*_params in build_info
> might be a preferable interface? I would probably cleanup the above code
> in build_pre too since you could just call the appropriate
> libxl_sched_*_params_set.
>=20
... Exactly, that's much better looking to me.

> Ideally libxl_sched_*_params would be in a union in
> libxl_domain_build_info but that would require that xl could easily
> determine which scheduler was going to be used for the domain, having a
> non-union here would keep things somewhat simpler from that PoV.
>=20
Yes, again, I agree that a union will be even better, but maybe not so
much a big deal for now (we can turn it into an union later, right? Or
you think there will be some API implications?)

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-O/1aVUApPgk2DxkScTqr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+VZbIACgkQk4XaBE3IOsQr6QCfRH22XlfzvX0wMWINceq9gmXP
RpgAoIaWN32GxCjiMtvIVCRq8gGWxlFg
=U+kJ
-----END PGP SIGNATURE-----

--=-O/1aVUApPgk2DxkScTqr--


--===============2488772583394686957==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2488772583394686957==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 14:49:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:49:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKZk-0006tD-0v; Mon, 23 Apr 2012 14:49:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMKZi-0006t5-1i
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 14:49:10 +0000
Received: from [85.158.138.51:20693] by server-11.bemta-3.messagelabs.com id
	33/4F-18894-5EB659F4; Mon, 23 Apr 2012 14:49:09 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335192546!23385648!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21718 invoked from network); 23 Apr 2012 14:49:08 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Apr 2012 14:49:08 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMKZe-0001em-2p
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:49:06 -0700
Date: Mon, 23 Apr 2012 07:49:06 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335192546080-5659590.post@n5.nabble.com>
In-Reply-To: <1335190864041-5659521.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
	<1334917612.28331.34.camel@zakaz.uk.xensource.com>
	<1334920571945-5653963.post@n5.nabble.com>
	<1335190864041-5659521.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Fantu wrote
>> 
>> Thanks for reply.
>> What I must write for emply virtual cdrom? I tried 'hdc,ro,cdrom' but
>> return parsing error.
>> 
>> I also tried cd-eject with this configuration:
>> ---------------------------------------
>> name='XP'
>> builder="hvm"
>> memory=1024
>> vcpus=2
>> hap=1
>> pae=1
>> acpi=1
>> apic=1
>> nx=1
>> vif=['bridge=xenbr0']
>> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc,ro,cdrom']
>> #disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>> boot='cd'
>> xen_platform_pci=1
>> viridian=1
>> device_model_version="qemu-xen"
>> #device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> vnc=1
>> vncunused=1
>> vnclisten="0.0.0.0"
>> keymap="it"
>> #spice=1
>> #spicehost="0.0.0.0"
>> #spiceport=6000
>> #spicedisable_ticketing=1
>> on_poweroff="destroy"
>> on_reboot="restart"
>> on_crash="destroy"
>> stdvga=0
>> #device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
>> #videoram=128
>> #device_model_args=["-vga qxl"]
>> ---------------------------------------
>> 
>> And return this error:
>> xl cd-eject XP hdc
>> command line: config parsing error in disk specification: unknown value
>> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
>> 
>> xl cd-eject is not full compatible with new disk configuration? (the
>> cdrom added on xl configuration file is working)
>> 
> 
> I Try also with:
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc:cdrom,r']
> But always same error on eject:
> xl cd-eject XP hdc
> command line: config parsing error in disk specification: unknown value
> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
> 
> Seem not refer to domU configuration files but xl bug
> 

Probably I have found the bug, on xl_cmdimpl.c on main_cd_eject function:
cd_insert(p, virtdev, NULL);
It gives error, probably not compatible with new disk configuration parsing.
I tried to modify cd_insert function but without success.
Someone can fix this bug please?

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5659590.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 14:49:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 14:49:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKZk-0006tD-0v; Mon, 23 Apr 2012 14:49:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMKZi-0006t5-1i
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 14:49:10 +0000
Received: from [85.158.138.51:20693] by server-11.bemta-3.messagelabs.com id
	33/4F-18894-5EB659F4; Mon, 23 Apr 2012 14:49:09 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335192546!23385648!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21718 invoked from network); 23 Apr 2012 14:49:08 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Apr 2012 14:49:08 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMKZe-0001em-2p
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 07:49:06 -0700
Date: Mon, 23 Apr 2012 07:49:06 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335192546080-5659590.post@n5.nabble.com>
In-Reply-To: <1335190864041-5659521.post@n5.nabble.com>
References: <1334669694083-5646585.post@n5.nabble.com>
	<1334917612.28331.34.camel@zakaz.uk.xensource.com>
	<1334920571945-5653963.post@n5.nabble.com>
	<1335190864041-5659521.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl cd-insert / xl cd-eject on xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Fantu wrote
>> 
>> Thanks for reply.
>> What I must write for emply virtual cdrom? I tried 'hdc,ro,cdrom' but
>> return parsing error.
>> 
>> I also tried cd-eject with this configuration:
>> ---------------------------------------
>> name='XP'
>> builder="hvm"
>> memory=1024
>> vcpus=2
>> hap=1
>> pae=1
>> acpi=1
>> apic=1
>> nx=1
>> vif=['bridge=xenbr0']
>> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc,ro,cdrom']
>> #disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>> boot='cd'
>> xen_platform_pci=1
>> viridian=1
>> device_model_version="qemu-xen"
>> #device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>> vnc=1
>> vncunused=1
>> vnclisten="0.0.0.0"
>> keymap="it"
>> #spice=1
>> #spicehost="0.0.0.0"
>> #spiceport=6000
>> #spicedisable_ticketing=1
>> on_poweroff="destroy"
>> on_reboot="restart"
>> on_crash="destroy"
>> stdvga=0
>> #device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
>> #videoram=128
>> #device_model_args=["-vga qxl"]
>> ---------------------------------------
>> 
>> And return this error:
>> xl cd-eject XP hdc
>> command line: config parsing error in disk specification: unknown value
>> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
>> 
>> xl cd-eject is not full compatible with new disk configuration? (the
>> cdrom added on xl configuration file is working)
>> 
> 
> I Try also with:
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw','/mnt/vm/iso/test.iso,raw,hdc:cdrom,r']
> But always same error on eject:
> xl cd-eject XP hdc
> command line: config parsing error in disk specification: unknown value
> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
> 
> Seem not refer to domU configuration files but xl bug
> 

Probably I have found the bug, on xl_cmdimpl.c on main_cd_eject function:
cd_insert(p, virtdev, NULL);
It gives error, probably not compatible with new disk configuration parsing.
I tried to modify cd_insert function but without success.
Someone can fix this bug please?

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cd-insert-xl-cd-eject-on-xen-unstable-tp5646585p5659590.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:11:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKvK-00079N-4k; Mon, 23 Apr 2012 15:11:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMKvJ-00079I-92
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:11:29 +0000
Received: from [193.109.254.147:29948] by server-2.bemta-14.messagelabs.com id
	5F/A3-19409-021759F4; Mon, 23 Apr 2012 15:11:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335193885!225428!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDYxMTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10936 invoked from network); 23 Apr 2012 15:11:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:11:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330923600"; d="scan'208";a="191609963"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:11:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 11:11:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMKv2-0001ZF-1m;
	Mon, 23 Apr 2012 16:11:12 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 16:11:02 +0100
Message-ID: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is
	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prevent xl from doing any operation if xend daemon is running. That prevents
bugs that happened when xl and xend raced to close a domain.

Cc: george.dunlap@eu.citrix.com
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/xl.c         |   18 +++++++++++++++++-
 tools/libxl/xl_cmdimpl.c |    4 ++--
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..dc434cd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -32,8 +32,11 @@
 #include "libxlutil.h"
 #include "xl.h"
 
+#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
+
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
+int force_execution;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
@@ -103,8 +106,9 @@ int main(int argc, char **argv)
     char *config_file;
     void *config_data = 0;
     int config_len = 0;
+    const char *locks[] = XEND_LOCK;
 
-    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
+    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
         switch (opt) {
         case 'v':
             if (minmsglevel > 0) minmsglevel--;
@@ -112,6 +116,9 @@ int main(int argc, char **argv)
         case 'N':
             dryrun_only = 1;
             break;
+        case 'f':
+            force_execution = 1;
+            break;
         default:
             fprintf(stderr, "unknown global option\n");
             exit(2);
@@ -126,6 +133,15 @@ int main(int argc, char **argv)
     }
     opterr = 0;
 
+    for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
+        if (!access(locks[i], F_OK) && !force_execution) {
+            fprintf(stderr, "xend is running, which prevents xl from working "
+                            "correctly. If you still want to force the "
+                            "execution of xl please use the -f option\n");
+            exit(2);
+        }
+    }
+
     logger = xtl_createlogger_stdiostream(stderr, minmsglevel,  0);
     if (!logger) exit(1);
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..65bc6d6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1909,7 +1909,7 @@ void help(const char *command)
     struct cmd_spec *cmd;
 
     if (!command || !strcmp(command, "help")) {
-        printf("Usage xl [-vN] <subcommand> [args]\n\n");
+        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
         printf("xl full list of subcommands:\n\n");
         for (i = 0; i < cmdtable_len; i++) {
             printf(" %-19s ", cmd_table[i].cmd_name);
@@ -1920,7 +1920,7 @@ void help(const char *command)
     } else {
         cmd = cmdtable_lookup(command);
         if (cmd) {
-            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
+            printf("Usage: xl [-vf%s] %s %s\n\n%s.\n\n",
                    cmd->can_dryrun ? "N" : "",
                    cmd->cmd_name,
                    cmd->cmd_usage,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:11:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKvK-00079N-4k; Mon, 23 Apr 2012 15:11:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMKvJ-00079I-92
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:11:29 +0000
Received: from [193.109.254.147:29948] by server-2.bemta-14.messagelabs.com id
	5F/A3-19409-021759F4; Mon, 23 Apr 2012 15:11:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335193885!225428!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDYxMTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10936 invoked from network); 23 Apr 2012 15:11:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:11:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330923600"; d="scan'208";a="191609963"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:11:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 11:11:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMKv2-0001ZF-1m;
	Mon, 23 Apr 2012 16:11:12 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 23 Apr 2012 16:11:02 +0100
Message-ID: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is
	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prevent xl from doing any operation if xend daemon is running. That prevents
bugs that happened when xl and xend raced to close a domain.

Cc: george.dunlap@eu.citrix.com
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/xl.c         |   18 +++++++++++++++++-
 tools/libxl/xl_cmdimpl.c |    4 ++--
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..dc434cd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -32,8 +32,11 @@
 #include "libxlutil.h"
 #include "xl.h"
 
+#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
+
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
+int force_execution;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
@@ -103,8 +106,9 @@ int main(int argc, char **argv)
     char *config_file;
     void *config_data = 0;
     int config_len = 0;
+    const char *locks[] = XEND_LOCK;
 
-    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
+    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
         switch (opt) {
         case 'v':
             if (minmsglevel > 0) minmsglevel--;
@@ -112,6 +116,9 @@ int main(int argc, char **argv)
         case 'N':
             dryrun_only = 1;
             break;
+        case 'f':
+            force_execution = 1;
+            break;
         default:
             fprintf(stderr, "unknown global option\n");
             exit(2);
@@ -126,6 +133,15 @@ int main(int argc, char **argv)
     }
     opterr = 0;
 
+    for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
+        if (!access(locks[i], F_OK) && !force_execution) {
+            fprintf(stderr, "xend is running, which prevents xl from working "
+                            "correctly. If you still want to force the "
+                            "execution of xl please use the -f option\n");
+            exit(2);
+        }
+    }
+
     logger = xtl_createlogger_stdiostream(stderr, minmsglevel,  0);
     if (!logger) exit(1);
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..65bc6d6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1909,7 +1909,7 @@ void help(const char *command)
     struct cmd_spec *cmd;
 
     if (!command || !strcmp(command, "help")) {
-        printf("Usage xl [-vN] <subcommand> [args]\n\n");
+        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
         printf("xl full list of subcommands:\n\n");
         for (i = 0; i < cmdtable_len; i++) {
             printf(" %-19s ", cmd_table[i].cmd_name);
@@ -1920,7 +1920,7 @@ void help(const char *command)
     } else {
         cmd = cmdtable_lookup(command);
         if (cmd) {
-            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
+            printf("Usage: xl [-vf%s] %s %s\n\n%s.\n\n",
                    cmd->can_dryrun ? "N" : "",
                    cmd->cmd_name,
                    cmd->cmd_usage,
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:13:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKwQ-0007C2-JR; Mon, 23 Apr 2012 15:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMKwP-0007Bv-Ay
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:12:37 +0000
Received: from [193.109.254.147:61818] by server-11.bemta-14.messagelabs.com
	id D6/2F-05858-461759F4; Mon, 23 Apr 2012 15:12:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335193954!5880445!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23645 invoked from network); 23 Apr 2012 15:12:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:12:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFC4w5008438
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:12:07 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFC3td001485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:12:03 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFC281014563; Mon, 23 Apr 2012 10:12:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:12:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 693EF4032D; Mon, 23 Apr 2012 11:06:57 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:06:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120423150657.GA24481@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423060921.GA29378@aftab.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > This driver is not that much different from the APEI bridge to MCE code -
> > it just that instead of reading APEI blob data it reads it from an hypercall.
> 
> Let me ask you this: is APEI a virtualization solution of some sort?
> 
> No, it is the old windoze RAS crap but I guess Linux has to support it
> now too through BIOS. And x86 vendors will have to support it too.
> 
> So it is piece of the firmware we'd have to deal with too.
> 
> Now xen is a whole another deal - it is purely a piece of software.

Perfect. Software is more elastic than hardware - so the Xen ABI
for the MCE can be changed then to reflect the new format if required.
> 
> > The fix seems quite easy - you change the 'struct mce' and 'mce_log()'
> > along with the drivers that use it.
> 
> This is exactly what I have a problem with: having to take care of xen
> too. "No, Boris, nope, we cannot take your new feature because it breaks
> xen." and also "Have you tested this on xen too?" where the only thing I
> do is _hardware_ enablement and improving software support for it. And
> xen is not hardware...

Delegate testing to sub-maintainers. In this case that would be me
and Liu.

> 
> [..]
> 
> > If you are worried about breaking something, then you can just send
> > the change to me or Liu to test it out before committing API changes
> > in the MCE code.
> 
> This probably sounds good now but I don't think code changes like
> that ever run as smoothly. Whenever there's breakage, there'll always
> be people screaming against it - I just don't want code that enables

Right, regressions are bad.

> hardware to be crippled and unable to change because it breaks
> completely unrelated pieces - it is bad as it is now.

Can you point me to the existing examples of MCE's badness?

I remember the Greg KK's patches to the dynamic vs static and per-cpu
initialization - but that wasn't due to the MCE API. I think that
was due to Key Sievens transition from SysFS subsystem API to device API
patches that broke bunch of stuff.

> 
> > > And this has happened already with the whole microcode loading debacle.
> > 
> > My recollection is that the existing microcode API had major issues that
> > could not fixed. The only fix was to make it be very early in the bootup
> > processes and that is what hpa would like developers to focus on.
> 
> That was one side of the problem. The other was, AFAICR, creating a xen
> microcode driver which was "on the same level" as the hardware microcode
> drivers, which was completely bull*.

I think of Xen as the hypervisors on PowerPC boxes - for certain operations
you have to use hypercalls to do some hardware operations.

> 
> The problem is xen growing stuff everywhere in arch/x86/ and this way,
> maybe even unwillingly, crippling development of hardware-related
> features. I know you're willing to help and I know you mean it well, but
> there's always some other problem in practice.

I am not sure I see why we cannot fix the practical problems as they pop
up?

> 
> Now I keep wondering, why don't you guys simply create your own mcelog
> ring buffer and interface on the userspace tool side instead of hooking
> into lowlevel kernel stuff? I mean, the code is there, you simply have
> to copy it into arch/xen/ or whatever you have there. Why do you have to

Nowadays the kernel can transition to run under lguest, KVM, Xen or
baremetal as a single binary image instead of multiple compiled
kernels for a specific virtualization framework. As such, there is
no 'arch/xen,lguest,kvm', instead there is alternative_asm that patches
the low-level calls (set_pte, load_cr3, spinlock, time, etc), for the
appropiate virtualization (or CPU if done under baremetal) offering. Hence
the arch/x86 has expanded to support baremtal and virtualization
extensions in it (called paravirt_ops).

> hook into arch/x86/ instead of doing your own stuff?

I think what you are suggesting is to _not_ reuse existing APIs. That
seems counter-intuive to general software development. There are
exceptions of course - when the existing API needs to change a lot
(or needs to be thrown out), and there is this one little driver that
keeps on using the old interface and can't change - at that point I can
see the purpose of forking it. But until then - using existing APIs is
the way to go.

And I (along with Liu) will keep the Xen MCE driver evolving as it
needs to conform to the new kernel mcheck API.

> 
> > > So, my suggestion is to copy the pieces you need and create your own xen
> > > version of /dev/mcelog and add it to dom0 so that there's no hooking
> > > into baremetal code and whenever a dom0 kernel is running, you can
> > > reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
> > > and not hook into the x86 versions.
> > > 
> > > Because, if you'd hooked into it, just imagine one fine day, when we
> > > remove mcelog support, what screaming the xen people will be doing when
> > > mcelog doesn't work anymore.
> > 
> > You would have more screaming from the distro camp about removing
> > /dev/mcelog.
> 
> How do you know that? Don't you think that we probably would've talked
> to them already and made preparations for conversion first?

I was Googling around for it and I couldn't find anything that says
MCE is removed (which could be very well the fault of my poor
Googling-skills) and its replacement user-space program. Please do
point me to the URL so I can get some idea of what is brewing.

The one thing I saw was this https://lkml.org/lkml/2012/3/2/312 which
pointed to the /dev/mcelog struct changing (which then got NACK-ed), but
nothing about the internal 'struct mce' being dropped from drivers?

I couldn't find anything in the Documentation/feature-removal-schedule.txt 

There are hints of ras_printk and  /sys/devices/system/ras/agent but
they are related to printk (and I see that mce_log would use it too), but
that just seems to [from a driver perspective] to be the output code-paths
[like the MCE decoders] - and it allows to output to be put in a trace
buffer as well - instead of just in /dev/mcelog.

If the distros choose to stop using /dev/mcelog and use another mechanism
(and the MCE check drivers still do their job of collecting the data and
sending it downstream), then I don't see why "screaming the xen people will
be doing" - as they still get the MCE errors - in whatever way the distros
has choosen to present it.

> 
> > But if that is your choice, I would send you an email asking how I
> > need to retool this driver to work with the new MCE gen2 code that you
> > had in mind.
> 
> As I said above, I'm very sceptical this will ever work, I guess I'd
> have to live and see.
> 
> Now, with your own buffer solution, nothing breaks and all is happy,
> a win-win, if you wish. I think this is much simpler and easier a
> solution.

Not sure what you mean by 'own buffer solution'. Are you talking about
using the trace_mce_record or the ras_printk instead of the mce_log?
I would think that is the job of the MCE decoders?

Please keep in mind that this driver is not trying to decode anything -
it just lifting raw events, massaging them a bit, and sending them
downstream. Similar to how the APEI does it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:13:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMKwQ-0007C2-JR; Mon, 23 Apr 2012 15:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMKwP-0007Bv-Ay
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:12:37 +0000
Received: from [193.109.254.147:61818] by server-11.bemta-14.messagelabs.com
	id D6/2F-05858-461759F4; Mon, 23 Apr 2012 15:12:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335193954!5880445!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23645 invoked from network); 23 Apr 2012 15:12:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:12:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFC4w5008438
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:12:07 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFC3td001485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:12:03 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFC281014563; Mon, 23 Apr 2012 10:12:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:12:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 693EF4032D; Mon, 23 Apr 2012 11:06:57 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:06:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120423150657.GA24481@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423060921.GA29378@aftab.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > This driver is not that much different from the APEI bridge to MCE code -
> > it just that instead of reading APEI blob data it reads it from an hypercall.
> 
> Let me ask you this: is APEI a virtualization solution of some sort?
> 
> No, it is the old windoze RAS crap but I guess Linux has to support it
> now too through BIOS. And x86 vendors will have to support it too.
> 
> So it is piece of the firmware we'd have to deal with too.
> 
> Now xen is a whole another deal - it is purely a piece of software.

Perfect. Software is more elastic than hardware - so the Xen ABI
for the MCE can be changed then to reflect the new format if required.
> 
> > The fix seems quite easy - you change the 'struct mce' and 'mce_log()'
> > along with the drivers that use it.
> 
> This is exactly what I have a problem with: having to take care of xen
> too. "No, Boris, nope, we cannot take your new feature because it breaks
> xen." and also "Have you tested this on xen too?" where the only thing I
> do is _hardware_ enablement and improving software support for it. And
> xen is not hardware...

Delegate testing to sub-maintainers. In this case that would be me
and Liu.

> 
> [..]
> 
> > If you are worried about breaking something, then you can just send
> > the change to me or Liu to test it out before committing API changes
> > in the MCE code.
> 
> This probably sounds good now but I don't think code changes like
> that ever run as smoothly. Whenever there's breakage, there'll always
> be people screaming against it - I just don't want code that enables

Right, regressions are bad.

> hardware to be crippled and unable to change because it breaks
> completely unrelated pieces - it is bad as it is now.

Can you point me to the existing examples of MCE's badness?

I remember the Greg KK's patches to the dynamic vs static and per-cpu
initialization - but that wasn't due to the MCE API. I think that
was due to Key Sievens transition from SysFS subsystem API to device API
patches that broke bunch of stuff.

> 
> > > And this has happened already with the whole microcode loading debacle.
> > 
> > My recollection is that the existing microcode API had major issues that
> > could not fixed. The only fix was to make it be very early in the bootup
> > processes and that is what hpa would like developers to focus on.
> 
> That was one side of the problem. The other was, AFAICR, creating a xen
> microcode driver which was "on the same level" as the hardware microcode
> drivers, which was completely bull*.

I think of Xen as the hypervisors on PowerPC boxes - for certain operations
you have to use hypercalls to do some hardware operations.

> 
> The problem is xen growing stuff everywhere in arch/x86/ and this way,
> maybe even unwillingly, crippling development of hardware-related
> features. I know you're willing to help and I know you mean it well, but
> there's always some other problem in practice.

I am not sure I see why we cannot fix the practical problems as they pop
up?

> 
> Now I keep wondering, why don't you guys simply create your own mcelog
> ring buffer and interface on the userspace tool side instead of hooking
> into lowlevel kernel stuff? I mean, the code is there, you simply have
> to copy it into arch/xen/ or whatever you have there. Why do you have to

Nowadays the kernel can transition to run under lguest, KVM, Xen or
baremetal as a single binary image instead of multiple compiled
kernels for a specific virtualization framework. As such, there is
no 'arch/xen,lguest,kvm', instead there is alternative_asm that patches
the low-level calls (set_pte, load_cr3, spinlock, time, etc), for the
appropiate virtualization (or CPU if done under baremetal) offering. Hence
the arch/x86 has expanded to support baremtal and virtualization
extensions in it (called paravirt_ops).

> hook into arch/x86/ instead of doing your own stuff?

I think what you are suggesting is to _not_ reuse existing APIs. That
seems counter-intuive to general software development. There are
exceptions of course - when the existing API needs to change a lot
(or needs to be thrown out), and there is this one little driver that
keeps on using the old interface and can't change - at that point I can
see the purpose of forking it. But until then - using existing APIs is
the way to go.

And I (along with Liu) will keep the Xen MCE driver evolving as it
needs to conform to the new kernel mcheck API.

> 
> > > So, my suggestion is to copy the pieces you need and create your own xen
> > > version of /dev/mcelog and add it to dom0 so that there's no hooking
> > > into baremetal code and whenever a dom0 kernel is running, you can
> > > reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
> > > and not hook into the x86 versions.
> > > 
> > > Because, if you'd hooked into it, just imagine one fine day, when we
> > > remove mcelog support, what screaming the xen people will be doing when
> > > mcelog doesn't work anymore.
> > 
> > You would have more screaming from the distro camp about removing
> > /dev/mcelog.
> 
> How do you know that? Don't you think that we probably would've talked
> to them already and made preparations for conversion first?

I was Googling around for it and I couldn't find anything that says
MCE is removed (which could be very well the fault of my poor
Googling-skills) and its replacement user-space program. Please do
point me to the URL so I can get some idea of what is brewing.

The one thing I saw was this https://lkml.org/lkml/2012/3/2/312 which
pointed to the /dev/mcelog struct changing (which then got NACK-ed), but
nothing about the internal 'struct mce' being dropped from drivers?

I couldn't find anything in the Documentation/feature-removal-schedule.txt 

There are hints of ras_printk and  /sys/devices/system/ras/agent but
they are related to printk (and I see that mce_log would use it too), but
that just seems to [from a driver perspective] to be the output code-paths
[like the MCE decoders] - and it allows to output to be put in a trace
buffer as well - instead of just in /dev/mcelog.

If the distros choose to stop using /dev/mcelog and use another mechanism
(and the MCE check drivers still do their job of collecting the data and
sending it downstream), then I don't see why "screaming the xen people will
be doing" - as they still get the MCE errors - in whatever way the distros
has choosen to present it.

> 
> > But if that is your choice, I would send you an email asking how I
> > need to retool this driver to work with the new MCE gen2 code that you
> > had in mind.
> 
> As I said above, I'm very sceptical this will ever work, I guess I'd
> have to live and see.
> 
> Now, with your own buffer solution, nothing breaks and all is happy,
> a win-win, if you wish. I think this is much simpler and easier a
> solution.

Not sure what you mean by 'own buffer solution'. Are you talking about
using the trace_mce_record or the ras_printk instead of the mce_log?
I would think that is the job of the MCE decoders?

Please keep in mind that this driver is not trying to decode anything -
it just lifting raw events, massaging them a bit, and sending them
downstream. Similar to how the APEI does it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SML0L-0007Nn-9I; Mon, 23 Apr 2012 15:16:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SML0J-0007Nc-0C
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:16:39 +0000
Received: from [193.109.254.147:30700] by server-4.bemta-14.messagelabs.com id
	8B/F5-11570-652759F4; Mon, 23 Apr 2012 15:16:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335194195!5944991!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2NjA2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11167 invoked from network); 23 Apr 2012 15:16:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:16:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFGSFj028609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:16:29 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFGRwc013951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:16:28 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFGR8l025013; Mon, 23 Apr 2012 10:16:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:16:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 869DD4032D; Mon, 23 Apr 2012 11:11:23 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:11:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120423151123.GC24481@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> > How about return -1 on error?
> >> > The calling function can check -1 for error.
> >>
> >> Isn't -1 potentially (at least theoretically) a valid value to read fr=
om
> >> one of these registers?
> >
> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
> >
> > Perhaps the fallback is to emulate (so retain some of the original code)
> > as we have been since .. uh 3.0?
> =

> Do you mean the return value of io_apic_read in 3.0?

No. I meant that we would continue to emulate. The improvement
is that now we do:

=A0 =A0 =A0 if (reg =3D=3D 0x1)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
=A0 =A0 =A0 else if (reg =3D=3D 0x0)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;

instead of 0xfdfdfdfd.

> It's 0xffffffff.

Now it is 0xfdfdfdfd.

I am suggesting that instead of BUG_ON(), we fallback to do returning
an emulatated IO_APIC values - like the ones that this original patch
cooked up..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SML0L-0007Nn-9I; Mon, 23 Apr 2012 15:16:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SML0J-0007Nc-0C
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:16:39 +0000
Received: from [193.109.254.147:30700] by server-4.bemta-14.messagelabs.com id
	8B/F5-11570-652759F4; Mon, 23 Apr 2012 15:16:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335194195!5944991!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2NjA2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11167 invoked from network); 23 Apr 2012 15:16:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:16:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFGSFj028609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:16:29 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFGRwc013951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:16:28 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFGR8l025013; Mon, 23 Apr 2012 10:16:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:16:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 869DD4032D; Mon, 23 Apr 2012 11:11:23 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:11:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120423151123.GC24481@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> > How about return -1 on error?
> >> > The calling function can check -1 for error.
> >>
> >> Isn't -1 potentially (at least theoretically) a valid value to read fr=
om
> >> one of these registers?
> >
> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
> >
> > Perhaps the fallback is to emulate (so retain some of the original code)
> > as we have been since .. uh 3.0?
> =

> Do you mean the return value of io_apic_read in 3.0?

No. I meant that we would continue to emulate. The improvement
is that now we do:

=A0 =A0 =A0 if (reg =3D=3D 0x1)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
=A0 =A0 =A0 else if (reg =3D=3D 0x0)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;

instead of 0xfdfdfdfd.

> It's 0xffffffff.

Now it is 0xfdfdfdfd.

I am suggesting that instead of BUG_ON(), we fallback to do returning
an emulatated IO_APIC values - like the ones that this original patch
cooked up..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:25:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SML8j-0007Zq-AN; Mon, 23 Apr 2012 15:25:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SML8i-0007Zl-FN
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:25:20 +0000
Received: from [85.158.143.35:59707] by server-2.bemta-4.messagelabs.com id
	1B/99-17550-F54759F4; Mon, 23 Apr 2012 15:25:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335194717!12630118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11985 invoked from network); 23 Apr 2012 15:25:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084264"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:25:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:25:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SML8f-00039V-1e; Mon, 23 Apr 2012 15:25:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SML8e-0001hn-Sl;
	Mon, 23 Apr 2012 16:25:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.29788.772445.467842@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:25:16 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0fb728d56baeaed476d2.1333477788@kodo2>
References: <0fb728d56baeaed476d2.1333477788@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] xl: Don't require a config file for cpupools"):
> Since the key information can be fairly simply put on the command-line,
> there's no need to require an actual config file.

Thanks.  Just a few tiny coding style nits.  I agree with Ian
Campbell's comments, and also:

> -    const char *filename = NULL;
> +    const char *filename = NULL, *config_src=NULL;

This has inconsistent use of whitespace.

> +    if (filename)
> +    {

This should have { on the same line as the if.

> +        if (libxl_read_file_contents(ctx, filename, (void **)&config_data,
> +                                     &config_len)) {
> +            fprintf(stderr, "Failed to read config file: %s: %s\n",
> +                    filename, strerror(errno));
> +            return -ERROR_FAIL;
> +        }
> +        config_src=filename;

We put spaces around "=".  (Here and a few lines further on.)

> +    }
> +    else

And on the same line as the else.  And having { } for the if, I think
putting { } for the else block would be more conventional.

> -    printf("Using config file \"%s\"\n", filename);
> +    printf("Using config file \"%s\"\n", config_src);

This will print
   Using config file "command line"
which is rather an odd message.  Perhaps change the string to
`<command line>' and remove the quotes ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:25:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SML8j-0007Zq-AN; Mon, 23 Apr 2012 15:25:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SML8i-0007Zl-FN
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:25:20 +0000
Received: from [85.158.143.35:59707] by server-2.bemta-4.messagelabs.com id
	1B/99-17550-F54759F4; Mon, 23 Apr 2012 15:25:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335194717!12630118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11985 invoked from network); 23 Apr 2012 15:25:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084264"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:25:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:25:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SML8f-00039V-1e; Mon, 23 Apr 2012 15:25:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SML8e-0001hn-Sl;
	Mon, 23 Apr 2012 16:25:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.29788.772445.467842@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:25:16 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0fb728d56baeaed476d2.1333477788@kodo2>
References: <0fb728d56baeaed476d2.1333477788@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] xl: Don't require a config file for cpupools"):
> Since the key information can be fairly simply put on the command-line,
> there's no need to require an actual config file.

Thanks.  Just a few tiny coding style nits.  I agree with Ian
Campbell's comments, and also:

> -    const char *filename = NULL;
> +    const char *filename = NULL, *config_src=NULL;

This has inconsistent use of whitespace.

> +    if (filename)
> +    {

This should have { on the same line as the if.

> +        if (libxl_read_file_contents(ctx, filename, (void **)&config_data,
> +                                     &config_len)) {
> +            fprintf(stderr, "Failed to read config file: %s: %s\n",
> +                    filename, strerror(errno));
> +            return -ERROR_FAIL;
> +        }
> +        config_src=filename;

We put spaces around "=".  (Here and a few lines further on.)

> +    }
> +    else

And on the same line as the else.  And having { } for the if, I think
putting { } for the else block would be more conventional.

> -    printf("Using config file \"%s\"\n", filename);
> +    printf("Using config file \"%s\"\n", config_src);

This will print
   Using config file "command line"
which is rather an odd message.  Perhaps change the string to
`<command line>' and remove the quotes ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:26:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SML9Z-0007cN-PA; Mon, 23 Apr 2012 15:26:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SML9X-0007cC-Mc
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:26:12 +0000
Received: from [85.158.139.83:62224] by server-6.bemta-5.messagelabs.com id
	73/59-13222-294759F4; Mon, 23 Apr 2012 15:26:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335194769!22390337!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxOTMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23963 invoked from network); 23 Apr 2012 15:26:10 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.74) by server-4.tower-182.messagelabs.com with SMTP;
	23 Apr 2012 15:26:10 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id DB3CB714075;
	Mon, 23 Apr 2012 08:26:08 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aohEPU7OSQCfLiyxNKXtIHseVkr7JEDkd9IWnSMx3lT3
	oMh/+32I2HRTjGGQSeUeE6jaj4iy0tM4y1bwyuofL8xxllF0iiT7667QAnm0RwG9
	QiwPskwbjPB7zZV6ydBeZyEBy11Gbt+1J33QP2uHJs4C6j0cLgXLONi8qj6XPCI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Sc+dWeI9+0tLhJM6HVmNFUWxHUY=; b=BmvcXjm+
	wunoYdAsjyIJAj2xcMHrsDUlvxkWuYg5T3vgg1r5Eo90csZuhShnPAKp8gdSACW9
	reV3Nvy/3iYAhu6BpQpka8VgHIJ6BQFtMbDhIStfSjjNW+Z4hUbHx7po9UDLcjtb
	ERjSIM+byETJb13da4BxaiqRdnjApJIbNpA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id B317471406A; 
	Mon, 23 Apr 2012 08:26:07 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Apr 2012 08:26:08 -0700
Message-ID: <c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120423091445.GA17920@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
Date: Mon, 23 Apr 2012 08:26:08 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
>> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
>> profiling data with 10 seconds:
>>
>> (XEN) p2m_lock 1 lock:
>> (XEN)   lock:      190733(00000000:14CE5726), block:
>> 67159(00000007:6AAA53F3)
>>
>> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
>> is waiting for the p2m lock. And those data only for idle guest. The
>> impaction is more seriously when run some workload inside guest.  I
>> noticed that this change was adding by cs 24770. And before it, we
>> don't require the p2m lock in _get_gfn_type_access. So is this lock
>> really necessary?
>
> Ugh; that certainly is a regression.  We used to be lock-free on p2m
> lookups and losing that will be bad for perf in lots of ways.  IIRC the
> original aim was to use fine-grained per-page locks for this -- there
> should be no need to hold a per-domain lock during a normal read.
> Andres, what happened to that code?

The fine-grained p2m locking code is stashed somewhere and untested.
Obviously not meant for 4.2. I don't think it'll be useful here: all vcpus
are hitting the same gfn for the hpet mmio address.

Thanks for the report Yang, it would be great to understand at which call
sites the p2m lock is contended, so we can try to alleviate contention at
the right place.

Looking closely at the code, it would seem the only get_gfn in
hvmemul_do_io is called on ram_gpa == 0 (?!). Shouldn't ram_gpa underlie
the target mmio address for emulation?

Notwithstanding the above, we've optimized p2m access on hvmemul_do_io to
have as brief a critical section as possible: get_gfn, get_page, put_gfn,
work, put_page later.

So contention might arise from (bogusly) doing get_gfn(0) by every vcpu
(when it should instead be get_gfn(hpet_gfn)). The only way to alleviate
that contention is to use get_gfn_query_unlocked, and that will be unsafe
against paging or sharing. I am very skeptical this is causing the
slowdown you see, since you're not using paging or sharing. The critical
section protected by the p2m lock is literally one cmpxchg.

The other source of contention might come from hvmemul_rep_movs, which
holds the p2m lock for the duration of the mmio operation. I can optimize
that one using the get_gfn/get_page/put_gfn pattern mentioned above.

The third source of contention might be the __hvm_copy to/from the target
address of the hpet value read/written. That one can be slightly optimized
by doing the memcpy outside of the scope of the p2m lock.

>
> Making it an rwlock would be tricky as this interface doesn't
> differenctiate readers from writers.  For the common case (no
> sharing/paging/mem-access) it ought to be a win since there is hardly
> any writing.  But it would be better to make this particular lock/unlock
> go away.
>

We had a discussion about rwlocks way back when. It's impossible (or
nearly so) to tell when an access might upgrade to write privileges.
Deadlock has a high likelihood.

Andres

> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:26:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SML9Z-0007cN-PA; Mon, 23 Apr 2012 15:26:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SML9X-0007cC-Mc
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:26:12 +0000
Received: from [85.158.139.83:62224] by server-6.bemta-5.messagelabs.com id
	73/59-13222-294759F4; Mon, 23 Apr 2012 15:26:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335194769!22390337!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxOTMxNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23963 invoked from network); 23 Apr 2012 15:26:10 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.74) by server-4.tower-182.messagelabs.com with SMTP;
	23 Apr 2012 15:26:10 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id DB3CB714075;
	Mon, 23 Apr 2012 08:26:08 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aohEPU7OSQCfLiyxNKXtIHseVkr7JEDkd9IWnSMx3lT3
	oMh/+32I2HRTjGGQSeUeE6jaj4iy0tM4y1bwyuofL8xxllF0iiT7667QAnm0RwG9
	QiwPskwbjPB7zZV6ydBeZyEBy11Gbt+1J33QP2uHJs4C6j0cLgXLONi8qj6XPCI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Sc+dWeI9+0tLhJM6HVmNFUWxHUY=; b=BmvcXjm+
	wunoYdAsjyIJAj2xcMHrsDUlvxkWuYg5T3vgg1r5Eo90csZuhShnPAKp8gdSACW9
	reV3Nvy/3iYAhu6BpQpka8VgHIJ6BQFtMbDhIStfSjjNW+Z4hUbHx7po9UDLcjtb
	ERjSIM+byETJb13da4BxaiqRdnjApJIbNpA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id B317471406A; 
	Mon, 23 Apr 2012 08:26:07 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Apr 2012 08:26:08 -0700
Message-ID: <c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120423091445.GA17920@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
Date: Mon, 23 Apr 2012 08:26:08 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
>> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
>> profiling data with 10 seconds:
>>
>> (XEN) p2m_lock 1 lock:
>> (XEN)   lock:      190733(00000000:14CE5726), block:
>> 67159(00000007:6AAA53F3)
>>
>> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
>> is waiting for the p2m lock. And those data only for idle guest. The
>> impaction is more seriously when run some workload inside guest.  I
>> noticed that this change was adding by cs 24770. And before it, we
>> don't require the p2m lock in _get_gfn_type_access. So is this lock
>> really necessary?
>
> Ugh; that certainly is a regression.  We used to be lock-free on p2m
> lookups and losing that will be bad for perf in lots of ways.  IIRC the
> original aim was to use fine-grained per-page locks for this -- there
> should be no need to hold a per-domain lock during a normal read.
> Andres, what happened to that code?

The fine-grained p2m locking code is stashed somewhere and untested.
Obviously not meant for 4.2. I don't think it'll be useful here: all vcpus
are hitting the same gfn for the hpet mmio address.

Thanks for the report Yang, it would be great to understand at which call
sites the p2m lock is contended, so we can try to alleviate contention at
the right place.

Looking closely at the code, it would seem the only get_gfn in
hvmemul_do_io is called on ram_gpa == 0 (?!). Shouldn't ram_gpa underlie
the target mmio address for emulation?

Notwithstanding the above, we've optimized p2m access on hvmemul_do_io to
have as brief a critical section as possible: get_gfn, get_page, put_gfn,
work, put_page later.

So contention might arise from (bogusly) doing get_gfn(0) by every vcpu
(when it should instead be get_gfn(hpet_gfn)). The only way to alleviate
that contention is to use get_gfn_query_unlocked, and that will be unsafe
against paging or sharing. I am very skeptical this is causing the
slowdown you see, since you're not using paging or sharing. The critical
section protected by the p2m lock is literally one cmpxchg.

The other source of contention might come from hvmemul_rep_movs, which
holds the p2m lock for the duration of the mmio operation. I can optimize
that one using the get_gfn/get_page/put_gfn pattern mentioned above.

The third source of contention might be the __hvm_copy to/from the target
address of the hpet value read/written. That one can be slightly optimized
by doing the memcpy outside of the scope of the p2m lock.

>
> Making it an rwlock would be tricky as this interface doesn't
> differenctiate readers from writers.  For the common case (no
> sharing/paging/mem-access) it ought to be a win since there is hardly
> any writing.  But it would be better to make this particular lock/unlock
> go away.
>

We had a discussion about rwlocks way back when. It's impossible (or
nearly so) to tell when an access might upgrade to write privileges.
Deadlock has a high likelihood.

Andres

> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:27:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:27:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLAn-0007jd-Fg; Mon, 23 Apr 2012 15:27:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMLAm-0007jT-JZ
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:27:28 +0000
Received: from [85.158.143.99:13367] by server-2.bemta-4.messagelabs.com id
	15/CC-17550-FD4759F4; Mon, 23 Apr 2012 15:27:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335194846!23982636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21498 invoked from network); 23 Apr 2012 15:27:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 16:26:24 +0100
Message-ID: <1335194783.4347.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 23 Apr 2012 16:26:23 +0100
In-Reply-To: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 16:11 +0100, Roger Pau Monne wrote:
> @@ -112,6 +116,9 @@ int main(int argc, char **argv)
>          case 'N':
>              dryrun_only = 1;
>              break;
> +        case 'f':
> +            force_execution = 1;
> +            break;
>          default:
>              fprintf(stderr, "unknown global option\n");
>              exit(2);

Needs a matching docs patch to add the option to the manpage. Otherwise:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> @@ -126,6 +133,15 @@ int main(int argc, char **argv)
>      }
>      opterr = 0;
>  
> +    for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
> +        if (!access(locks[i], F_OK) && !force_execution) {
> +            fprintf(stderr, "xend is running, which prevents xl from working "
> +                            "correctly. If you still want to force the "
> +                            "execution of xl please use the -f option\n");

You might as well wrap the output text to 80 columns (I didn't count, I
assume this isn't...)

> +            exit(2);
> +        }
> +    }
> +


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:27:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:27:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLAn-0007jd-Fg; Mon, 23 Apr 2012 15:27:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMLAm-0007jT-JZ
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:27:28 +0000
Received: from [85.158.143.99:13367] by server-2.bemta-4.messagelabs.com id
	15/CC-17550-FD4759F4; Mon, 23 Apr 2012 15:27:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335194846!23982636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21498 invoked from network); 23 Apr 2012 15:27:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 16:26:24 +0100
Message-ID: <1335194783.4347.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 23 Apr 2012 16:26:23 +0100
In-Reply-To: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 16:11 +0100, Roger Pau Monne wrote:
> @@ -112,6 +116,9 @@ int main(int argc, char **argv)
>          case 'N':
>              dryrun_only = 1;
>              break;
> +        case 'f':
> +            force_execution = 1;
> +            break;
>          default:
>              fprintf(stderr, "unknown global option\n");
>              exit(2);

Needs a matching docs patch to add the option to the manpage. Otherwise:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> @@ -126,6 +133,15 @@ int main(int argc, char **argv)
>      }
>      opterr = 0;
>  
> +    for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
> +        if (!access(locks[i], F_OK) && !force_execution) {
> +            fprintf(stderr, "xend is running, which prevents xl from working "
> +                            "correctly. If you still want to force the "
> +                            "execution of xl please use the -f option\n");

You might as well wrap the output text to 80 columns (I didn't count, I
assume this isn't...)

> +            exit(2);
> +        }
> +    }
> +


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:27:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLAv-0007kY-SK; Mon, 23 Apr 2012 15:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1SMLAu-0007kM-Jd
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:27:36 +0000
Received: from [193.109.254.147:52496] by server-8.bemta-14.messagelabs.com id
	FE/C1-23244-7E4759F4; Mon, 23 Apr 2012 15:27:35 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335194854!5917663!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjcyNTI3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18024 invoked from network); 23 Apr 2012 15:27:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-27.messagelabs.com with SMTP;
	23 Apr 2012 15:27:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Apr 2012 08:27:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="135697709"
Received: from orsmsx605.amr.corp.intel.com ([10.22.226.10])
	by orsmga002.jf.intel.com with ESMTP; 23 Apr 2012 08:27:33 -0700
Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by
	orsmsx605.amr.corp.intel.com (10.22.226.10) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 08:27:33 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.88]) by
	ORSMSX152.amr.corp.intel.com ([169.254.8.220]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 08:27:33 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@amd64.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YMj31i2PR/lkqeiia+nqwVVJaljggAgAL9hUA=
Date: Mon, 23 Apr 2012 15:27:32 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
In-Reply-To: <20120421104502.GB17005@aftab.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "H. Peter
	Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Because, if you'd hooked into it, just imagine one fine day, when we
> remove mcelog support, what screaming the xen people will be doing when
> mcelog doesn't work anymore.

Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
fields could be added) ... and you don't want to have your hypervisor to
have to know which version of Linux it is talking to.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:27:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLAv-0007kY-SK; Mon, 23 Apr 2012 15:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1SMLAu-0007kM-Jd
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:27:36 +0000
Received: from [193.109.254.147:52496] by server-8.bemta-14.messagelabs.com id
	FE/C1-23244-7E4759F4; Mon, 23 Apr 2012 15:27:35 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335194854!5917663!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjcyNTI3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18024 invoked from network); 23 Apr 2012 15:27:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-27.messagelabs.com with SMTP;
	23 Apr 2012 15:27:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Apr 2012 08:27:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="135697709"
Received: from orsmsx605.amr.corp.intel.com ([10.22.226.10])
	by orsmga002.jf.intel.com with ESMTP; 23 Apr 2012 08:27:33 -0700
Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by
	orsmsx605.amr.corp.intel.com (10.22.226.10) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 08:27:33 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.88]) by
	ORSMSX152.amr.corp.intel.com ([169.254.8.220]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 08:27:33 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@amd64.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YMj31i2PR/lkqeiia+nqwVVJaljggAgAL9hUA=
Date: Mon, 23 Apr 2012 15:27:32 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
In-Reply-To: <20120421104502.GB17005@aftab.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "H. Peter
	Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Because, if you'd hooked into it, just imagine one fine day, when we
> remove mcelog support, what screaming the xen people will be doing when
> mcelog doesn't work anymore.

Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
fields could be added) ... and you don't want to have your hypervisor to
have to know which version of Linux it is talking to.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:29:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLCc-0007xD-DK; Mon, 23 Apr 2012 15:29:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMLCa-0007wa-F9
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:29:20 +0000
Received: from [85.158.139.83:31788] by server-8.bemta-5.messagelabs.com id
	8A/8B-26964-D45759F4; Mon, 23 Apr 2012 15:29:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335194954!25100335!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2NjA2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14403 invoked from network); 23 Apr 2012 15:29:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:29:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFT9JJ012937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:29:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFT8U6008136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:29:09 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFT81d029285; Mon, 23 Apr 2012 10:29:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:29:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B99AE4032D; Mon, 23 Apr 2012 11:24:04 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:24:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120423152404.GD24481@phenom.dumpdata.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > Hello!
> > 
> > i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4 
> > tested) as Dom0 Kernel;
> > 
> > With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers 
> > (gplpv_Vista2008x64_0.11.0.357.msi); 
> > With 3.4 it drops to about a third of that.
> > 
> > Xen Version is xen-unstable: 
> > xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
> > 
> > Disk config line is:
> > disk = [ '/dev/vg_ssd/win7system,,hda' ] 
> > - it uses blkback.
> 
> I fail to see what could be the cause of the issue: nothing on the
> blkback side should affect performances significantly.
> You could try reverting the four patches to blkback that were applied
> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
> regression:
> 
> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> Daniel De Graaf (2):
>       xen/blkback: use grant-table.c hypercall wrappers

Hm.. Perhaps this patch fixes it a possible perf (I would think that
the compiler would have kept the result of the first call to vaddr(req, i)
somewhere.. but not sure) lost with the mentioned patch:

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..65dbadc 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req *req)
 	int ret;
 
 	for (i = 0; i < req->nr_pages; i++) {
+		unsigned long addr;
 		handle = pending_handle(req, i);
 		if (handle == BLKBACK_INVALID_HANDLE)
 			continue;
-		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
+		addr = vaddr(req, i);
+		gnttab_set_unmap_op(&unmap[invcount], addr,
 				    GNTMAP_host_map, handle);
 		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
-		pages[invcount] = virt_to_page(vaddr(req, i));
+		pages[invcount] = virt_to_page(addr);
 		invcount++;
 	}
 
>       xen/blkback: Enable blkback on HVM guests
> 
> Konrad Rzeszutek Wilk (2):
>       xen/blkback: Squash the discard support for 'file' and 'phy' type.
>       xen/blkback: Make optional features be really optional.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:29:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLCc-0007xD-DK; Mon, 23 Apr 2012 15:29:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMLCa-0007wa-F9
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:29:20 +0000
Received: from [85.158.139.83:31788] by server-8.bemta-5.messagelabs.com id
	8A/8B-26964-D45759F4; Mon, 23 Apr 2012 15:29:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335194954!25100335!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2NjA2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14403 invoked from network); 23 Apr 2012 15:29:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:29:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFT9JJ012937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:29:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFT8U6008136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:29:09 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFT81d029285; Mon, 23 Apr 2012 10:29:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:29:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B99AE4032D; Mon, 23 Apr 2012 11:24:04 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:24:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120423152404.GD24481@phenom.dumpdata.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > Hello!
> > 
> > i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4 
> > tested) as Dom0 Kernel;
> > 
> > With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers 
> > (gplpv_Vista2008x64_0.11.0.357.msi); 
> > With 3.4 it drops to about a third of that.
> > 
> > Xen Version is xen-unstable: 
> > xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
> > 
> > Disk config line is:
> > disk = [ '/dev/vg_ssd/win7system,,hda' ] 
> > - it uses blkback.
> 
> I fail to see what could be the cause of the issue: nothing on the
> blkback side should affect performances significantly.
> You could try reverting the four patches to blkback that were applied
> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
> regression:
> 
> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> Daniel De Graaf (2):
>       xen/blkback: use grant-table.c hypercall wrappers

Hm.. Perhaps this patch fixes it a possible perf (I would think that
the compiler would have kept the result of the first call to vaddr(req, i)
somewhere.. but not sure) lost with the mentioned patch:

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..65dbadc 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req *req)
 	int ret;
 
 	for (i = 0; i < req->nr_pages; i++) {
+		unsigned long addr;
 		handle = pending_handle(req, i);
 		if (handle == BLKBACK_INVALID_HANDLE)
 			continue;
-		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
+		addr = vaddr(req, i);
+		gnttab_set_unmap_op(&unmap[invcount], addr,
 				    GNTMAP_host_map, handle);
 		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
-		pages[invcount] = virt_to_page(vaddr(req, i));
+		pages[invcount] = virt_to_page(addr);
 		invcount++;
 	}
 
>       xen/blkback: Enable blkback on HVM guests
> 
> Konrad Rzeszutek Wilk (2):
>       xen/blkback: Squash the discard support for 'file' and 'phy' type.
>       xen/blkback: Make optional features be really optional.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:33:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLGq-0008IX-49; Mon, 23 Apr 2012 15:33:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMLGo-0008IP-6b
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:33:42 +0000
Received: from [85.158.143.35:53180] by server-1.bemta-4.messagelabs.com id
	CD/27-20925-556759F4; Mon, 23 Apr 2012 15:33:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335195221!13988304!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7745 invoked from network); 23 Apr 2012 15:33:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:33:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:33:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:33:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMLGm-0003CN-E8; Mon, 23 Apr 2012 15:33:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMLGm-0005w3-9E;
	Mon, 23 Apr 2012 16:33:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.30292.162693.913028@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:33:40 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-3-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup"):
> Add a function which behaves like "xenstore-rm -t", and which will be used to
> clean xenstore after unplug since we will be no longer executing
> xen-hotplug-cleanup script, that used to do that for us.

This is all rather odd.  I hadn't previously noticed the existence of
xenstore-rm -t.

With the C xenstored, the RM command will delete a whole directory
tree, regardless of its contents.  This is documented in
docs/misc/xenstore.txt.

The comment in xs.c near xs_rm, which says that directories must be
empty, seems to be wrong.

What does oxenstored do ?  I'm tempted to say that it should follow
the C xenstored behaviour.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:33:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLGq-0008IX-49; Mon, 23 Apr 2012 15:33:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMLGo-0008IP-6b
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:33:42 +0000
Received: from [85.158.143.35:53180] by server-1.bemta-4.messagelabs.com id
	CD/27-20925-556759F4; Mon, 23 Apr 2012 15:33:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335195221!13988304!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7745 invoked from network); 23 Apr 2012 15:33:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:33:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:33:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:33:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMLGm-0003CN-E8; Mon, 23 Apr 2012 15:33:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMLGm-0005w3-9E;
	Mon, 23 Apr 2012 16:33:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.30292.162693.913028@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:33:40 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-3-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup"):
> Add a function which behaves like "xenstore-rm -t", and which will be used to
> clean xenstore after unplug since we will be no longer executing
> xen-hotplug-cleanup script, that used to do that for us.

This is all rather odd.  I hadn't previously noticed the existence of
xenstore-rm -t.

With the C xenstored, the RM command will delete a whole directory
tree, regardless of its contents.  This is documented in
docs/misc/xenstore.txt.

The comment in xs.c near xs_rm, which says that directories must be
empty, seems to be wrong.

What does oxenstored do ?  I'm tempted to say that it should follow
the C xenstored behaviour.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:38:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:38:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLL3-0008Rh-Tz; Mon, 23 Apr 2012 15:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMLL3-0008Rb-5b
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:38:05 +0000
Received: from [85.158.143.99:11624] by server-1.bemta-4.messagelabs.com id
	8C/0D-20925-A57759F4; Mon, 23 Apr 2012 15:38:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335195479!24839103!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25523 invoked from network); 23 Apr 2012 15:38:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:38:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFbTQF009806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:37:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFbSJP025150
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:37:28 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFbR1k000636; Mon, 23 Apr 2012 10:37:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:37:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1793D4032D; Mon, 23 Apr 2012 11:32:23 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:32:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luck, Tony" <tony.luck@intel.com>
Message-ID: <20120423153222.GE24481@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 03:27:32PM +0000, Luck, Tony wrote:
> > Because, if you'd hooked into it, just imagine one fine day, when we
> > remove mcelog support, what screaming the xen people will be doing when
> > mcelog doesn't work anymore.
> 
> Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
> fields could be added) ... and you don't want to have your hypervisor to
> have to know which version of Linux it is talking to.

I am having a hard time seeing how this is different from 'struct mce'
changing and the hardware remaining the same?

Can't the MCE check drivers deal with that - I mean that is their purpose -
to extract some "blob" of data from the hardware, massage it in the software
structure, and send its way. If you add some more fields in the software
structure - either the hardware can provide it or not. If not, it will have
to emulate it. This would be the same case with this driver.

This driver is _not_ doing a strict bit-by-bit copy of 'struct mcinfo'
to 'struct mce'. It is plucking the right bits and setting them in
'struct mce'.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:38:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:38:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLL3-0008Rh-Tz; Mon, 23 Apr 2012 15:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMLL3-0008Rb-5b
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:38:05 +0000
Received: from [85.158.143.99:11624] by server-1.bemta-4.messagelabs.com id
	8C/0D-20925-A57759F4; Mon, 23 Apr 2012 15:38:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335195479!24839103!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25523 invoked from network); 23 Apr 2012 15:38:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:38:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NFbTQF009806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 15:37:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NFbSJP025150
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 15:37:28 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NFbR1k000636; Mon, 23 Apr 2012 10:37:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 08:37:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1793D4032D; Mon, 23 Apr 2012 11:32:23 -0400 (EDT)
Date: Mon, 23 Apr 2012 11:32:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luck, Tony" <tony.luck@intel.com>
Message-ID: <20120423153222.GE24481@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 03:27:32PM +0000, Luck, Tony wrote:
> > Because, if you'd hooked into it, just imagine one fine day, when we
> > remove mcelog support, what screaming the xen people will be doing when
> > mcelog doesn't work anymore.
> 
> Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
> fields could be added) ... and you don't want to have your hypervisor to
> have to know which version of Linux it is talking to.

I am having a hard time seeing how this is different from 'struct mce'
changing and the hardware remaining the same?

Can't the MCE check drivers deal with that - I mean that is their purpose -
to extract some "blob" of data from the hardware, massage it in the software
structure, and send its way. If you add some more fields in the software
structure - either the hardware can provide it or not. If not, it will have
to emulate it. This would be the same case with this driver.

This driver is _not_ doing a strict bit-by-bit copy of 'struct mcinfo'
to 'struct mce'. It is plucking the right bits and setting them in
'struct mce'.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:38:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLLV-0008Ti-BB; Mon, 23 Apr 2012 15:38:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMLLT-0008TU-IQ
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:38:31 +0000
Received: from [85.158.138.51:45795] by server-11.bemta-3.messagelabs.com id
	B4/94-18894-677759F4; Mon, 23 Apr 2012 15:38:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335195510!19046906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31661 invoked from network); 23 Apr 2012 15:38:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:37:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:37:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMLKo-0003Dk-OE; Mon, 23 Apr 2012 15:37:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMLKo-0005wv-M7;
	Mon, 23 Apr 2012 16:37:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.30542.669565.492586@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:37:50 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-2-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/5] libxl: allow libxl__exec to take
	a	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 1/5] libxl: allow libxl__exec to take a parameter containing the env variables"):
> Add another parameter to libxl__exec call that contains the
> environment variables to use when performing the execvp call.

This looks OK to me.  However, shouldn't this be const char** ?

>      struct termios termattr;
> +    char *env[] = {"TERM", "vt100", NULL};

We don't compile with -Wwrite-strings but if we did this would
trigger.  Also it needs spaces inside { } I think.

> +    if (env != NULL) {
> +        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
> +            setenv(env[i], env[i+1], 1);

setenv can fail.  If it does you should probably check errno and
probably call libxl__alloc_failed.

> +/*
> + * env should be passed using the following format,
> + *
> + * env[0]: name of env variable
> + * env[1]: value of env variable

You need to mention that it may have more than one setting!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:38:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLLV-0008Ti-BB; Mon, 23 Apr 2012 15:38:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMLLT-0008TU-IQ
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:38:31 +0000
Received: from [85.158.138.51:45795] by server-11.bemta-3.messagelabs.com id
	B4/94-18894-677759F4; Mon, 23 Apr 2012 15:38:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335195510!19046906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31661 invoked from network); 23 Apr 2012 15:38:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:37:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:37:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMLKo-0003Dk-OE; Mon, 23 Apr 2012 15:37:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMLKo-0005wv-M7;
	Mon, 23 Apr 2012 16:37:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.30542.669565.492586@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:37:50 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-2-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/5] libxl: allow libxl__exec to take
	a	parameter containing the env variables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 1/5] libxl: allow libxl__exec to take a parameter containing the env variables"):
> Add another parameter to libxl__exec call that contains the
> environment variables to use when performing the execvp call.

This looks OK to me.  However, shouldn't this be const char** ?

>      struct termios termattr;
> +    char *env[] = {"TERM", "vt100", NULL};

We don't compile with -Wwrite-strings but if we did this would
trigger.  Also it needs spaces inside { } I think.

> +    if (env != NULL) {
> +        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
> +            setenv(env[i], env[i+1], 1);

setenv can fail.  If it does you should probably check errno and
probably call libxl__alloc_failed.

> +/*
> + * env should be passed using the following format,
> + *
> + * env[0]: name of env variable
> + * env[1]: value of env variable

You need to mention that it may have more than one setting!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLLt-000058-OW; Mon, 23 Apr 2012 15:38:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMLLs-00004t-Gx
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:38:56 +0000
Received: from [85.158.138.51:47749] by server-3.bemta-3.messagelabs.com id
	8A/3A-04048-F87759F4; Mon, 23 Apr 2012 15:38:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335195535!23394373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25968 invoked from network); 23 Apr 2012 15:38:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:38:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:38:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:38:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMLLq-0003Fh-3X; Mon, 23 Apr 2012 15:38:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMLLq-0005xC-2c;
	Mon, 23 Apr 2012 16:38:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.30605.900319.295957@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:38:53 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-6-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-6-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 5/5] libxl: add "downscript=no" to Qemu
	call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 5/5] libxl: add "downscript=no" to Qemu call"):
> Currently we only pass script=no to Qemu, to avoid calling any scripts when
> attaching a tap interface, but we should also pass downscript=no to avoid Qemu
> trying to execute a script when disconnecting the interface. This prevents the
> following harmless error message:
> 
> /etc/qemu-ifdown: could not launch network script
> 
> Changes since v1:
> 
>  * Indentation fixes.

This looks plausible but can you please split out the indentation
change from the functional change ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLLt-000058-OW; Mon, 23 Apr 2012 15:38:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMLLs-00004t-Gx
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:38:56 +0000
Received: from [85.158.138.51:47749] by server-3.bemta-3.messagelabs.com id
	8A/3A-04048-F87759F4; Mon, 23 Apr 2012 15:38:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335195535!23394373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25968 invoked from network); 23 Apr 2012 15:38:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:38:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12084753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 15:38:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 16:38:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMLLq-0003Fh-3X; Mon, 23 Apr 2012 15:38:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMLLq-0005xC-2c;
	Mon, 23 Apr 2012 16:38:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.30605.900319.295957@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 16:38:53 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-6-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-6-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 5/5] libxl: add "downscript=no" to Qemu
	call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 5/5] libxl: add "downscript=no" to Qemu call"):
> Currently we only pass script=no to Qemu, to avoid calling any scripts when
> attaching a tap interface, but we should also pass downscript=no to avoid Qemu
> trying to execute a script when disconnecting the interface. This prevents the
> following harmless error message:
> 
> /etc/qemu-ifdown: could not launch network script
> 
> Changes since v1:
> 
>  * Indentation fixes.

This looks plausible but can you please split out the indentation
change from the functional change ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:41:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLO9-0000Or-E8; Mon, 23 Apr 2012 15:41:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMLO8-0000Oe-Cu
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:41:16 +0000
Received: from [85.158.143.99:28612] by server-1.bemta-4.messagelabs.com id
	AF/41-20925-B18759F4; Mon, 23 Apr 2012 15:41:15 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335195674!24328683!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 718 invoked from network); 23 Apr 2012 15:41:14 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:41:14 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 9F0771C14001;
	Mon, 23 Apr 2012 17:41:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=JwpH6O/EB6grfp5p+amv5a+REDY=; b=Va
	AECmeC+N/FADH/EfAKJEekqSRwPv3Y9yAmKfakm6L0BkfdGY0ZHdV+WRlFOIfZ6q
	MawVMU95F34Bh5JxwI6e3xg8fYcWKqH+4oRvXLSYWw4Oe/BEjgxbNfOvH4CpYTAK
	14YxlDjx6Yxqb4Qwkn84xdGiOXLFJblvdKTjE/99myLxF1ZY9P0JQpbzAb0GtDN8
	uUuf1HXOUWq4YXMHdgfhUOvwoNuYSFfOzsHf4HNTYHkBQgDwRQ8mDE5vQL4N9HEI
	kHfKRwobJ3Taz/7ZZtxV2rNGItOTOWB5SiQAyFYy9zYXKgxiHbBWXm6+H/MbtPjY
	uA+WbqDHWBw/osegFJzjE86lM6QY3L1vulfbirAAOH7lPwSNn88lE/9l9Cs+qGNJ
	A45Vf1C/TXxou+Eb0flbegONkIhPnaQy9u3Zfq3ljALncN9j+UjWb6IKEHUkoRIi
	aEqyqdK0lfgQ4p9JCOOm8S+pMBadIOHuAS/WX7t0NTMiR4kSmqiHn0bE2QKUG3lE
	OEqk5e6GNmIjOQWVjo7RAyj8ouJ8d+jJGLkLuXoI5j2TbukwJQflmnh2jIqxPIus
	yvIN7GKR+1HvS+YYAyuB/xGVHUvjhSdnFsfuTaawZl0DVQGH0mc6QMMqzc+WjI6x
	uJ6bHbusvAU17FZSUofdIZr0/nRuKxWPxSTtKAZLg=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 77D4B1C14002; Mon, 23 Apr 2012 17:41:13 +0200 (CEST)
Date: Mon, 23 Apr 2012 17:41:13 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20120423154112.GA15320@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335190962.3122.10.camel@Abyss>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

> Maybe weight is, but still, I think having some mechanism for specifying
> the full set of parameter of a specific scheduler is to be preferred...
> 
> > I wonder if perhaps including each of libxl_sched_*_params in build_info
> > might be a preferable interface? I would probably cleanup the above code
> > in build_pre too since you could just call the appropriate
> > libxl_sched_*_params_set.
> > 
> ... Exactly, that's much better looking to me.

that's a good hint.

> > Ideally libxl_sched_*_params would be in a union in
> > libxl_domain_build_info but that would require that xl could easily
> > determine which scheduler was going to be used for the domain, having a
> > non-union here would keep things somewhat simpler from that PoV.
> > 
> Yes, again, I agree that a union will be even better, but maybe not so
> much a big deal for now (we can turn it into an union later, right? Or
> you think there will be some API implications?)

ok, I see the point and will change it to a union.
I checked out the source with git not hg, may I produce a diff with git
and send it via mail ?


-- 
Best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:41:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLO9-0000Or-E8; Mon, 23 Apr 2012 15:41:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMLO8-0000Oe-Cu
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:41:16 +0000
Received: from [85.158.143.99:28612] by server-1.bemta-4.messagelabs.com id
	AF/41-20925-B18759F4; Mon, 23 Apr 2012 15:41:15 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335195674!24328683!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 718 invoked from network); 23 Apr 2012 15:41:14 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 15:41:14 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 9F0771C14001;
	Mon, 23 Apr 2012 17:41:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=JwpH6O/EB6grfp5p+amv5a+REDY=; b=Va
	AECmeC+N/FADH/EfAKJEekqSRwPv3Y9yAmKfakm6L0BkfdGY0ZHdV+WRlFOIfZ6q
	MawVMU95F34Bh5JxwI6e3xg8fYcWKqH+4oRvXLSYWw4Oe/BEjgxbNfOvH4CpYTAK
	14YxlDjx6Yxqb4Qwkn84xdGiOXLFJblvdKTjE/99myLxF1ZY9P0JQpbzAb0GtDN8
	uUuf1HXOUWq4YXMHdgfhUOvwoNuYSFfOzsHf4HNTYHkBQgDwRQ8mDE5vQL4N9HEI
	kHfKRwobJ3Taz/7ZZtxV2rNGItOTOWB5SiQAyFYy9zYXKgxiHbBWXm6+H/MbtPjY
	uA+WbqDHWBw/osegFJzjE86lM6QY3L1vulfbirAAOH7lPwSNn88lE/9l9Cs+qGNJ
	A45Vf1C/TXxou+Eb0flbegONkIhPnaQy9u3Zfq3ljALncN9j+UjWb6IKEHUkoRIi
	aEqyqdK0lfgQ4p9JCOOm8S+pMBadIOHuAS/WX7t0NTMiR4kSmqiHn0bE2QKUG3lE
	OEqk5e6GNmIjOQWVjo7RAyj8ouJ8d+jJGLkLuXoI5j2TbukwJQflmnh2jIqxPIus
	yvIN7GKR+1HvS+YYAyuB/xGVHUvjhSdnFsfuTaawZl0DVQGH0mc6QMMqzc+WjI6x
	uJ6bHbusvAU17FZSUofdIZr0/nRuKxWPxSTtKAZLg=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 77D4B1C14002; Mon, 23 Apr 2012 17:41:13 +0200 (CEST)
Date: Mon, 23 Apr 2012 17:41:13 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20120423154112.GA15320@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335190962.3122.10.camel@Abyss>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

> Maybe weight is, but still, I think having some mechanism for specifying
> the full set of parameter of a specific scheduler is to be preferred...
> 
> > I wonder if perhaps including each of libxl_sched_*_params in build_info
> > might be a preferable interface? I would probably cleanup the above code
> > in build_pre too since you could just call the appropriate
> > libxl_sched_*_params_set.
> > 
> ... Exactly, that's much better looking to me.

that's a good hint.

> > Ideally libxl_sched_*_params would be in a union in
> > libxl_domain_build_info but that would require that xl could easily
> > determine which scheduler was going to be used for the domain, having a
> > non-union here would keep things somewhat simpler from that PoV.
> > 
> Yes, again, I agree that a union will be even better, but maybe not so
> much a big deal for now (we can turn it into an union later, right? Or
> you think there will be some API implications?)

ok, I see the point and will change it to a union.
I checked out the source with git not hg, may I produce a diff with git
and send it via mail ?


-- 
Best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:44:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:44:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLQg-0000d1-5O; Mon, 23 Apr 2012 15:43:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SMLQf-0000cr-1t
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:43:53 +0000
Received: from [85.158.143.99:61611] by server-2.bemta-4.messagelabs.com id
	B1/03-17550-8B8759F4; Mon, 23 Apr 2012 15:43:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335195831!19624649!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5MDgw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17285 invoked from network); 23 Apr 2012 15:43:52 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 15:43:52 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 23 Apr 2012 08:43:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92134983"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 08:43:50 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 08:43:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 23:43:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>, Borislav Petkov <bp@amd64.org>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YME+T8UaKT7UOvaY1icgqRWJaljggAgAL9hUCAAAEvAA==
Date: Mon, 23 Apr 2012 15:43:47 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Luck, Tony wrote:
>> Because, if you'd hooked into it, just imagine one fine day, when we
>> remove mcelog support, what screaming the xen people will be doing
>> when mcelog doesn't work anymore.
> 
> Agreed. Even before we get to deleting mcelog, "struct mce" can
> change (new fields could be added) ... and you don't want to have
> your hypervisor to have to know which version of Linux it is talking
> to. 
> 

Hmm, adding new fields block neither native nor xen -- xen just ignore new added fields, that would be no problem for xen:
/* Fields are zero when not available */
struct mce {
	...
}

and, hypervisor only record error into its mc_info cookie (in its own format), it doesn't care what's dom0's version and how dom0 translate it -- that's dom0's business. The role of hypervisor is virtual 'platform', just like h/w platform don't care what linux version runs over it.


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:44:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:44:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLQg-0000d1-5O; Mon, 23 Apr 2012 15:43:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SMLQf-0000cr-1t
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 15:43:53 +0000
Received: from [85.158.143.99:61611] by server-2.bemta-4.messagelabs.com id
	B1/03-17550-8B8759F4; Mon, 23 Apr 2012 15:43:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335195831!19624649!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5MDgw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17285 invoked from network); 23 Apr 2012 15:43:52 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 15:43:52 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 23 Apr 2012 08:43:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92134983"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 08:43:50 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 08:43:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 23:43:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>, Borislav Petkov <bp@amd64.org>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YME+T8UaKT7UOvaY1icgqRWJaljggAgAL9hUCAAAEvAA==
Date: Mon, 23 Apr 2012 15:43:47 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Luck, Tony wrote:
>> Because, if you'd hooked into it, just imagine one fine day, when we
>> remove mcelog support, what screaming the xen people will be doing
>> when mcelog doesn't work anymore.
> 
> Agreed. Even before we get to deleting mcelog, "struct mce" can
> change (new fields could be added) ... and you don't want to have
> your hypervisor to have to know which version of Linux it is talking
> to. 
> 

Hmm, adding new fields block neither native nor xen -- xen just ignore new added fields, that would be no problem for xen:
/* Fields are zero when not available */
struct mce {
	...
}

and, hypervisor only record error into its mc_info cookie (in its own format), it doesn't care what's dom0's version and how dom0 translate it -- that's dom0's business. The role of hypervisor is virtual 'platform', just like h/w platform don't care what linux version runs over it.


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:44:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:44:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLR4-0000et-Iy; Mon, 23 Apr 2012 15:44:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMLR2-0000ei-RM
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:44:17 +0000
Received: from [85.158.139.83:58857] by server-10.bemta-5.messagelabs.com id
	6F/62-08260-0D8759F4; Mon, 23 Apr 2012 15:44:16 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335195853!17760103!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDYxMTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5455 invoked from network); 23 Apr 2012 15:44:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330923600"; d="scan'208";a="191618582"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:42:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 11:42:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMLPX-00021r-Hh;
	Mon, 23 Apr 2012 16:42:43 +0100
Message-ID: <4F957872.3080502@citrix.com>
Date: Mon, 23 Apr 2012 16:42:42 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
	<20373.30292.162693.913028@mariner.uk.xensource.com>
In-Reply-To: <20373.30292.162693.913028@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_=
path_cleanup"):
>> Add a function which behaves like "xenstore-rm -t", and which will be us=
ed to
>> clean xenstore after unplug since we will be no longer executing
>> xen-hotplug-cleanup script, that used to do that for us.
>
> This is all rather odd.  I hadn't previously noticed the existence of
> xenstore-rm -t.
>
> With the C xenstored, the RM command will delete a whole directory
> tree, regardless of its contents.  This is documented in
> docs/misc/xenstore.txt.

This is a recursive delete, from top to bottom, let me put an example =

which will make this clear, since probably the title is wrong. Imagine =

you have the following xenstore entry:

/foo/bar/baz =3D 123

If you do a:

xenstore-rm /foo/bar/baz

the following will remain in xenstore:

/foo/bar

What this function does is clean empty folders that contained the =

deleted entry, so using this function on /foo/bar/baz would have cleaned =

the whole directory.

> The comment in xs.c near xs_rm, which says that directories must be
> empty, seems to be wrong.
>
> What does oxenstored do ?  I'm tempted to say that it should follow
> the C xenstored behaviour.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 15:44:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 15:44:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLR4-0000et-Iy; Mon, 23 Apr 2012 15:44:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMLR2-0000ei-RM
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 15:44:17 +0000
Received: from [85.158.139.83:58857] by server-10.bemta-5.messagelabs.com id
	6F/62-08260-0D8759F4; Mon, 23 Apr 2012 15:44:16 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335195853!17760103!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDYxMTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5455 invoked from network); 23 Apr 2012 15:44:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 15:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330923600"; d="scan'208";a="191618582"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 11:42:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 11:42:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMLPX-00021r-Hh;
	Mon, 23 Apr 2012 16:42:43 +0100
Message-ID: <4F957872.3080502@citrix.com>
Date: Mon, 23 Apr 2012 16:42:42 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
	<20373.30292.162693.913028@mariner.uk.xensource.com>
In-Reply-To: <20373.30292.162693.913028@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_=
path_cleanup"):
>> Add a function which behaves like "xenstore-rm -t", and which will be us=
ed to
>> clean xenstore after unplug since we will be no longer executing
>> xen-hotplug-cleanup script, that used to do that for us.
>
> This is all rather odd.  I hadn't previously noticed the existence of
> xenstore-rm -t.
>
> With the C xenstored, the RM command will delete a whole directory
> tree, regardless of its contents.  This is documented in
> docs/misc/xenstore.txt.

This is a recursive delete, from top to bottom, let me put an example =

which will make this clear, since probably the title is wrong. Imagine =

you have the following xenstore entry:

/foo/bar/baz =3D 123

If you do a:

xenstore-rm /foo/bar/baz

the following will remain in xenstore:

/foo/bar

What this function does is clean empty folders that contained the =

deleted entry, so using this function on /foo/bar/baz would have cleaned =

the whole directory.

> The comment in xs.c near xs_rm, which says that directories must be
> empty, seems to be wrong.
>
> What does oxenstored do ?  I'm tempted to say that it should follow
> the C xenstored behaviour.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:00:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLgK-0001H6-AZ; Mon, 23 Apr 2012 16:00:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SMLgJ-000196-BV
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:00:03 +0000
Received: from [193.109.254.147:51405] by server-1.bemta-14.messagelabs.com id
	99/A5-29372-28C759F4; Mon, 23 Apr 2012 16:00:02 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335196801!5889181!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21470 invoked from network); 23 Apr 2012 16:00:01 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-9.tower-27.messagelabs.com with SMTP;
	23 Apr 2012 16:00:01 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id D1BFDC01726;
	Mon, 23 Apr 2012 18:00:00 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id V8qKaMIIqI3d; Mon, 23 Apr 2012 18:00:00 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Mon, 23 Apr 2012 18:00:00 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 6523649C2B0;
	Mon, 23 Apr 2012 17:00:00 +0100 (BST)
Date: Mon, 23 Apr 2012 17:59:57 +0200
From: Borislav Petkov <bp@amd64.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120423155957.GA6147@aftab.osrc.amd.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
	<20120423150657.GA24481@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423150657.GA24481@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 11:06:57AM -0400, Konrad Rzeszutek Wilk wrote:
> > > This driver is not that much different from the APEI bridge to MCE code -
> > > it just that instead of reading APEI blob data it reads it from an hypercall.
> > 
> > Let me ask you this: is APEI a virtualization solution of some sort?
> > 
> > No, it is the old windoze RAS crap but I guess Linux has to support it
> > now too through BIOS. And x86 vendors will have to support it too.
> > 
> > So it is piece of the firmware we'd have to deal with too.
> > 
> > Now xen is a whole another deal - it is purely a piece of software.
> 
> Perfect. Software is more elastic than hardware - so the Xen ABI
> for the MCE can be changed then to reflect the new format if required.

And this "elastic" piece of software is yet another thing I have to deal
with when working on MCE which is strictly doing _hardware_ support. And
I don't want to do that - if you hook in the mce_log() interface, you're
practically becoming yet another user of it which I have to account for
when doing changes to the core MCE code.

[..]

> Delegate testing to sub-maintainers. In this case that would be me and
> Liu.

Ok, just purely hypothetically, what happens if there's no one to update
this code anymore? What if Oracle or Citrix or whoever it is, is not
interested in maintaining xen anymore, or those drivers or whatever?
I'm stuck with users of this which I can't shake off because there's no
upstream development. Oh, and then there's the distros which already
have their installs and they'd never update their setup because it works
and why touch it... and so on and so on...

[..]

> > The problem is xen growing stuff everywhere in arch/x86/ and this way,
> > maybe even unwillingly, crippling development of hardware-related
> > features. I know you're willing to help and I know you mean it well, but
> > there's always some other problem in practice.
> 
> I am not sure I see why we cannot fix the practical problems as they pop
> up?

See above.

[..]

> > hook into arch/x86/ instead of doing your own stuff?
> 
> I think what you are suggesting is to _not_ reuse existing APIs. That
> seems counter-intuive to general software development. There are
> exceptions of course - when the existing API needs to change a lot
> (or needs to be thrown out), and there is this one little driver that
> keeps on using the old interface and can't change - at that point I can
> see the purpose of forking it. But until then - using existing APIs is
> the way to go.

I just love it when guys left and right start teaching me about stuff,
it's like I even begged for it...

You're not reusing the existing API because mce_log is not an API to
anything - it is an internal x86 MCE logging thing to put a struct mce
into a static ring buffer.

The API is /dev/mcelog and there you should interface, not hook into
internal stuff and cripple it from developing any further.

[snip more senseless drivel]

> > Now, with your own buffer solution, nothing breaks and all is happy,
> > a win-win, if you wish. I think this is much simpler and easier a
> > solution.
> 
> Not sure what you mean by 'own buffer solution'. Are you talking about
> using the trace_mce_record or the ras_printk instead of the mce_log?
> I would think that is the job of the MCE decoders?

No, I mean to copy the mce_log() code along with the functions that
create the char device /dev/mcelog - mce_chrdev_*.

Btw, you'd probably be done with it if you'd taken the time to do that
instead of arguing your cause.

> Please keep in mind that this driver is not trying to decode anything -

I know that.

> it just lifting raw events, massaging them a bit, and sending them
> downstream. Similar to how the APEI does it.

Please stop talking about APEI - I told you why it doesn't apply here in
a previous mail.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:00:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLgK-0001H6-AZ; Mon, 23 Apr 2012 16:00:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SMLgJ-000196-BV
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:00:03 +0000
Received: from [193.109.254.147:51405] by server-1.bemta-14.messagelabs.com id
	99/A5-29372-28C759F4; Mon, 23 Apr 2012 16:00:02 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335196801!5889181!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21470 invoked from network); 23 Apr 2012 16:00:01 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-9.tower-27.messagelabs.com with SMTP;
	23 Apr 2012 16:00:01 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id D1BFDC01726;
	Mon, 23 Apr 2012 18:00:00 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id V8qKaMIIqI3d; Mon, 23 Apr 2012 18:00:00 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Mon, 23 Apr 2012 18:00:00 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 6523649C2B0;
	Mon, 23 Apr 2012 17:00:00 +0100 (BST)
Date: Mon, 23 Apr 2012 17:59:57 +0200
From: Borislav Petkov <bp@amd64.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120423155957.GA6147@aftab.osrc.amd.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
	<20120423150657.GA24481@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423150657.GA24481@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 11:06:57AM -0400, Konrad Rzeszutek Wilk wrote:
> > > This driver is not that much different from the APEI bridge to MCE code -
> > > it just that instead of reading APEI blob data it reads it from an hypercall.
> > 
> > Let me ask you this: is APEI a virtualization solution of some sort?
> > 
> > No, it is the old windoze RAS crap but I guess Linux has to support it
> > now too through BIOS. And x86 vendors will have to support it too.
> > 
> > So it is piece of the firmware we'd have to deal with too.
> > 
> > Now xen is a whole another deal - it is purely a piece of software.
> 
> Perfect. Software is more elastic than hardware - so the Xen ABI
> for the MCE can be changed then to reflect the new format if required.

And this "elastic" piece of software is yet another thing I have to deal
with when working on MCE which is strictly doing _hardware_ support. And
I don't want to do that - if you hook in the mce_log() interface, you're
practically becoming yet another user of it which I have to account for
when doing changes to the core MCE code.

[..]

> Delegate testing to sub-maintainers. In this case that would be me and
> Liu.

Ok, just purely hypothetically, what happens if there's no one to update
this code anymore? What if Oracle or Citrix or whoever it is, is not
interested in maintaining xen anymore, or those drivers or whatever?
I'm stuck with users of this which I can't shake off because there's no
upstream development. Oh, and then there's the distros which already
have their installs and they'd never update their setup because it works
and why touch it... and so on and so on...

[..]

> > The problem is xen growing stuff everywhere in arch/x86/ and this way,
> > maybe even unwillingly, crippling development of hardware-related
> > features. I know you're willing to help and I know you mean it well, but
> > there's always some other problem in practice.
> 
> I am not sure I see why we cannot fix the practical problems as they pop
> up?

See above.

[..]

> > hook into arch/x86/ instead of doing your own stuff?
> 
> I think what you are suggesting is to _not_ reuse existing APIs. That
> seems counter-intuive to general software development. There are
> exceptions of course - when the existing API needs to change a lot
> (or needs to be thrown out), and there is this one little driver that
> keeps on using the old interface and can't change - at that point I can
> see the purpose of forking it. But until then - using existing APIs is
> the way to go.

I just love it when guys left and right start teaching me about stuff,
it's like I even begged for it...

You're not reusing the existing API because mce_log is not an API to
anything - it is an internal x86 MCE logging thing to put a struct mce
into a static ring buffer.

The API is /dev/mcelog and there you should interface, not hook into
internal stuff and cripple it from developing any further.

[snip more senseless drivel]

> > Now, with your own buffer solution, nothing breaks and all is happy,
> > a win-win, if you wish. I think this is much simpler and easier a
> > solution.
> 
> Not sure what you mean by 'own buffer solution'. Are you talking about
> using the trace_mce_record or the ras_printk instead of the mce_log?
> I would think that is the job of the MCE decoders?

No, I mean to copy the mce_log() code along with the functions that
create the char device /dev/mcelog - mce_chrdev_*.

Btw, you'd probably be done with it if you'd taken the time to do that
instead of arguing your cause.

> Please keep in mind that this driver is not trying to decode anything -

I know that.

> it just lifting raw events, massaging them a bit, and sending them
> downstream. Similar to how the APEI does it.

Please stop talking about APEI - I told you why it doesn't apply here in
a previous mail.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLms-0001ps-J2; Mon, 23 Apr 2012 16:06:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Julia.Lawall@lip6.fr>) id 1SLtYC-0007au-Fq
	for xen-devel@lists.xensource.com; Sun, 22 Apr 2012 09:57:48 +0000
Received: from [85.158.139.83:53417] by server-12.bemta-5.messagelabs.com id
	B9/C0-05587-B16D39F4; Sun, 22 Apr 2012 09:57:47 +0000
X-Env-Sender: Julia.Lawall@lip6.fr
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335088666!24845641!1
X-Originating-IP: [130.225.96.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21979 invoked from network); 22 Apr 2012 09:57:46 -0000
Received: from mgw2.diku.dk (HELO mgw2.diku.dk) (130.225.96.92)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Apr 2012 09:57:46 -0000
Received: from localhost (localhost [127.0.0.1])
	by mgw2.diku.dk (Postfix) with ESMTP id DE57D19BC72;
	Sun, 22 Apr 2012 11:57:45 +0200 (CEST)
Received: from mgw2.diku.dk ([127.0.0.1])
	by localhost (mgw2.diku.dk [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 04942-06; Sun, 22 Apr 2012 11:57:40 +0200 (CEST)
Received: from palace.topps.diku.dk (palace.ekstranet.diku.dk [192.38.115.202])
	by mgw2.diku.dk (Postfix) with ESMTP id C7BC619BC67;
	Sun, 22 Apr 2012 11:57:40 +0200 (CEST)
From: Julia Lawall <Julia.Lawall@lip6.fr>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sun, 22 Apr 2012 11:57:40 +0200
Message-Id: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
X-Mailer: git-send-email 1.7.3.4
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:06:49 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-fbdev@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] drivers/video/xen-fbfront.c: add missing
	cleanup code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Julia Lawall <Julia.Lawall@lip6.fr>

The operations in the subsequent error-handling code appear to be also
useful here.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
Not tested.

 drivers/video/xen-fbfront.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cb4529c..b0bd59c 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -458,8 +458,13 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 	xenfb_init_shared_page(info, fb_info);
 
 	ret = xenfb_connect_backend(dev, info);
-	if (ret < 0)
+	if (ret < 0) {
+		fb_deferred_io_cleanup(fb_info);
+		fb_dealloc_cmap(&fb_info->cmap);
+		framebuffer_release(fb_info);
+		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
 		goto error;
+	}
 
 	ret = register_framebuffer(fb_info);
 	if (ret) {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLms-0001ps-J2; Mon, 23 Apr 2012 16:06:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Julia.Lawall@lip6.fr>) id 1SLtYC-0007au-Fq
	for xen-devel@lists.xensource.com; Sun, 22 Apr 2012 09:57:48 +0000
Received: from [85.158.139.83:53417] by server-12.bemta-5.messagelabs.com id
	B9/C0-05587-B16D39F4; Sun, 22 Apr 2012 09:57:47 +0000
X-Env-Sender: Julia.Lawall@lip6.fr
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335088666!24845641!1
X-Originating-IP: [130.225.96.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21979 invoked from network); 22 Apr 2012 09:57:46 -0000
Received: from mgw2.diku.dk (HELO mgw2.diku.dk) (130.225.96.92)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Apr 2012 09:57:46 -0000
Received: from localhost (localhost [127.0.0.1])
	by mgw2.diku.dk (Postfix) with ESMTP id DE57D19BC72;
	Sun, 22 Apr 2012 11:57:45 +0200 (CEST)
Received: from mgw2.diku.dk ([127.0.0.1])
	by localhost (mgw2.diku.dk [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 04942-06; Sun, 22 Apr 2012 11:57:40 +0200 (CEST)
Received: from palace.topps.diku.dk (palace.ekstranet.diku.dk [192.38.115.202])
	by mgw2.diku.dk (Postfix) with ESMTP id C7BC619BC67;
	Sun, 22 Apr 2012 11:57:40 +0200 (CEST)
From: Julia Lawall <Julia.Lawall@lip6.fr>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sun, 22 Apr 2012 11:57:40 +0200
Message-Id: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
X-Mailer: git-send-email 1.7.3.4
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:06:49 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-fbdev@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] drivers/video/xen-fbfront.c: add missing
	cleanup code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Julia Lawall <Julia.Lawall@lip6.fr>

The operations in the subsequent error-handling code appear to be also
useful here.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
Not tested.

 drivers/video/xen-fbfront.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cb4529c..b0bd59c 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -458,8 +458,13 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 	xenfb_init_shared_page(info, fb_info);
 
 	ret = xenfb_connect_backend(dev, info);
-	if (ret < 0)
+	if (ret < 0) {
+		fb_deferred_io_cleanup(fb_info);
+		fb_dealloc_cmap(&fb_info->cmap);
+		framebuffer_release(fb_info);
+		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
 		goto error;
+	}
 
 	ret = register_framebuffer(fb_info);
 	if (ret) {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLng-0001wy-8I; Mon, 23 Apr 2012 16:07:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMGRp-0003ZZ-G3
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:24:45 +0000
Received: from [85.158.143.99:58730] by server-3.bemta-4.messagelabs.com id
	A8/FC-05853-CED259F4; Mon, 23 Apr 2012 10:24:44 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335176582!23926849!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA1NDEyNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6328 invoked from network); 23 Apr 2012 10:24:34 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 10:24:34 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:31:33 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:31:06 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA0NC03182812
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:30:24 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFUqPX004909
	for <xen-devel@lists.xensource.com>; Tue, 24 Apr 2012 01:30:53 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFUpma004901; Tue, 24 Apr 2012 01:30:51 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	KVM <kvm@vger.kernel.org>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, 
	Virtualization <virtualization@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:13 +0530
Message-Id: <20120423100013.30893.36752.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-8878-0000-0000-0000022461A2
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V6 3/5] kvm guest : Add configuration
	support to enable debug information for KVM Guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 35eb2e4..a9ec0da 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -584,6 +584,15 @@ config KVM_GUEST
 	  This option enables various optimizations for running under the KVM
 	  hypervisor.
 
+config KVM_DEBUG_FS
+	bool "Enable debug information for KVM Guests in debugfs"
+	depends on KVM_GUEST && DEBUG_FS
+	default n
+	---help---
+	  This option enables collection of various statistics for KVM guest.
+   	  Statistics are displayed in debugfs filesystem. Enabling this option
+	  may incur significant overhead.
+
 source "arch/x86/lguest/Kconfig"
 
 config PARAVIRT


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLng-0001wy-8I; Mon, 23 Apr 2012 16:07:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMGRp-0003ZZ-G3
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:24:45 +0000
Received: from [85.158.143.99:58730] by server-3.bemta-4.messagelabs.com id
	A8/FC-05853-CED259F4; Mon, 23 Apr 2012 10:24:44 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335176582!23926849!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA1NDEyNA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6328 invoked from network); 23 Apr 2012 10:24:34 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 10:24:34 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:31:33 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:31:06 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA0NC03182812
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:30:24 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFUqPX004909
	for <xen-devel@lists.xensource.com>; Tue, 24 Apr 2012 01:30:53 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFUpma004901; Tue, 24 Apr 2012 01:30:51 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	KVM <kvm@vger.kernel.org>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, 
	Virtualization <virtualization@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:13 +0530
Message-Id: <20120423100013.30893.36752.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-8878-0000-0000-0000022461A2
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V6 3/5] kvm guest : Add configuration
	support to enable debug information for KVM Guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 35eb2e4..a9ec0da 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -584,6 +584,15 @@ config KVM_GUEST
 	  This option enables various optimizations for running under the KVM
 	  hypervisor.
 
+config KVM_DEBUG_FS
+	bool "Enable debug information for KVM Guests in debugfs"
+	depends on KVM_GUEST && DEBUG_FS
+	default n
+	---help---
+	  This option enables collection of various statistics for KVM guest.
+   	  Statistics are displayed in debugfs filesystem. Enabling this option
+	  may incur significant overhead.
+
 source "arch/x86/lguest/Kconfig"
 
 config PARAVIRT


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLne-0001vp-4J; Mon, 23 Apr 2012 16:07:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMG4E-0003CR-IX
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:00:22 +0000
Received: from [85.158.143.35:11277] by server-1.bemta-4.messagelabs.com id
	4C/52-20925-538259F4; Mon, 23 Apr 2012 10:00:21 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335175213!14176585!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxNDM5NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25573 invoked from network); 23 Apr 2012 10:00:20 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:00:20 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 09:41:36 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 09:41:35 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA02mX16908348
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:03 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NA01Y9030183
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:02 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3N9xvqt029956; Mon, 23 Apr 2012 19:59:57 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, 
	Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:29:47 +0530
Message-Id: <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042223-9264-0000-0000-000001514867
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to
	KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>

KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
    
The presence of these hypercalls is indicated to guest via
KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index e35b3a8..3252339 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -597,6 +597,9 @@ void kvm_sal_emul(struct kvm_vcpu *vcpu);
 struct kvm *kvm_arch_alloc_vm(void);
 void kvm_arch_free_vm(struct kvm *kvm);
 
+static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+}
 #endif /* __ASSEMBLY__*/
 
 #endif
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 52eb9c1..28446de 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -498,4 +498,8 @@ struct kvm_vcpu_arch {
 #define KVM_MMIO_REG_QPR	0x0040
 #define KVM_MMIO_REG_FQPR	0x0060
 
+static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+}
+
 #endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 7343872..c47f874 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -256,4 +256,8 @@ struct kvm_arch{
 };
 
 extern int sie64a(struct kvm_s390_sie_block *, u64 *);
+static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+}
+
 #endif
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index e216ba0..dad475b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
 		u64 length;
 		u64 status;
 	} osvw;
+	/* pv related host specific info */
+	struct {
+		int pv_unhalted;
+	} pv;
 };
 
 struct kvm_lpage_info {
@@ -967,4 +971,6 @@ int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
 void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
 void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
 
+void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu);
+
 #endif /* _ASM_X86_KVM_HOST_H */
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 734c376..5b647ea 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -16,12 +16,14 @@
 #define KVM_FEATURE_CLOCKSOURCE		0
 #define KVM_FEATURE_NOP_IO_DELAY	1
 #define KVM_FEATURE_MMU_OP		2
+
 /* This indicates that the new set of kvmclock msrs
  * are available. The use of 0x11 and 0x12 is deprecated
  */
 #define KVM_FEATURE_CLOCKSOURCE2        3
 #define KVM_FEATURE_ASYNC_PF		4
 #define KVM_FEATURE_STEAL_TIME		5
+#define KVM_FEATURE_PV_UNHALT		6
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 9fed5be..7c93806 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
 			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
 			     (1 << KVM_FEATURE_ASYNC_PF) |
-			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
+			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
+			     (1 << KVM_FEATURE_PV_UNHALT);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4044ce0..7fc9be6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_ASYNC_PF:
 	case KVM_CAP_GET_TSC_KHZ:
 	case KVM_CAP_PCI_2_3:
+	case KVM_CAP_PV_UNHALT:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -4993,6 +4994,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+/*
+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
+ *
+ * @apicid - apicid of vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
+{
+	struct kvm_vcpu *vcpu = NULL;
+	int i;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		if (!kvm_apic_present(vcpu))
+			continue;
+
+		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
+			break;
+	}
+	if (vcpu) {
+		/*
+		 * Setting unhalt flag here can result in spurious runnable
+		 * state when unhalt reset does not happen in vcpu_block.
+		 * But that is harmless since that should soon result in halt.
+		 */
+		vcpu->arch.pv.pv_unhalted = 1;
+		/* We need everybody see unhalt before vcpu unblocks */
+		smp_mb();
+		kvm_vcpu_kick(vcpu);
+	}
+}
+
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 {
 	unsigned long nr, a0, a1, a2, a3, ret;
@@ -5026,6 +5057,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 	case KVM_HC_VAPIC_POLL_IRQ:
 		ret = 0;
 		break;
+	case KVM_HC_KICK_CPU:
+		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
+		ret = 0;
+		break;
 	default:
 		ret = -KVM_ENOSYS;
 		break;
@@ -6128,6 +6163,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
 	BUG_ON(vcpu->kvm == NULL);
 	kvm = vcpu->kvm;
 
+	kvm_arch_vcpu_reset_pv_unhalted(vcpu);
 	vcpu->arch.emulate_ctxt.ops = &emulate_ops;
 	if (!irqchip_in_kernel(kvm) || kvm_vcpu_is_bsp(vcpu))
 		vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
@@ -6398,11 +6434,17 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
 		!vcpu->arch.apf.halted)
 		|| !list_empty_careful(&vcpu->async_pf.done)
 		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
+		|| vcpu->arch.pv.pv_unhalted
 		|| atomic_read(&vcpu->arch.nmi_queued) ||
 		(kvm_arch_interrupt_allowed(vcpu) &&
 		 kvm_cpu_has_interrupt(vcpu));
 }
 
+void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.pv.pv_unhalted = 0;
+}
+
 void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
 {
 	int me;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 6c322a9..a189f02 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -589,6 +589,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_S390_UCONTROL 73
 #define KVM_CAP_SYNC_REGS 74
 #define KVM_CAP_PCI_2_3 75
+#define KVM_CAP_PV_UNHALT 76
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index ff476dd..38226e1 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_KICK_CPU			5
 
 /*
  * hypercalls use architecture specific
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 42b7393..edf56d4 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
 		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
 
 		if (kvm_arch_vcpu_runnable(vcpu)) {
+			/*
+			 * This is the only safe place to reset unhalt flag.
+			 * otherwise it results in loosing the notification
+			 * which eventually can result in vcpu hangs.
+			 */
+			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
+			/* preventing reordering should be enough here */
+			barrier();
 			kvm_make_request(KVM_REQ_UNHALT, vcpu);
 			break;
 		}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLne-0001vp-4J; Mon, 23 Apr 2012 16:07:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMG4E-0003CR-IX
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:00:22 +0000
Received: from [85.158.143.35:11277] by server-1.bemta-4.messagelabs.com id
	4C/52-20925-538259F4; Mon, 23 Apr 2012 10:00:21 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335175213!14176585!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxNDM5NjU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25573 invoked from network); 23 Apr 2012 10:00:20 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:00:20 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 09:41:36 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 09:41:35 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA02mX16908348
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:03 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NA01Y9030183
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:02 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3N9xvqt029956; Mon, 23 Apr 2012 19:59:57 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, 
	Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:29:47 +0530
Message-Id: <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042223-9264-0000-0000-000001514867
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to
	KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>

KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
    
The presence of these hypercalls is indicated to guest via
KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index e35b3a8..3252339 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -597,6 +597,9 @@ void kvm_sal_emul(struct kvm_vcpu *vcpu);
 struct kvm *kvm_arch_alloc_vm(void);
 void kvm_arch_free_vm(struct kvm *kvm);
 
+static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+}
 #endif /* __ASSEMBLY__*/
 
 #endif
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 52eb9c1..28446de 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -498,4 +498,8 @@ struct kvm_vcpu_arch {
 #define KVM_MMIO_REG_QPR	0x0040
 #define KVM_MMIO_REG_FQPR	0x0060
 
+static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+}
+
 #endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 7343872..c47f874 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -256,4 +256,8 @@ struct kvm_arch{
 };
 
 extern int sie64a(struct kvm_s390_sie_block *, u64 *);
+static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+}
+
 #endif
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index e216ba0..dad475b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
 		u64 length;
 		u64 status;
 	} osvw;
+	/* pv related host specific info */
+	struct {
+		int pv_unhalted;
+	} pv;
 };
 
 struct kvm_lpage_info {
@@ -967,4 +971,6 @@ int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
 void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
 void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
 
+void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu);
+
 #endif /* _ASM_X86_KVM_HOST_H */
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 734c376..5b647ea 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -16,12 +16,14 @@
 #define KVM_FEATURE_CLOCKSOURCE		0
 #define KVM_FEATURE_NOP_IO_DELAY	1
 #define KVM_FEATURE_MMU_OP		2
+
 /* This indicates that the new set of kvmclock msrs
  * are available. The use of 0x11 and 0x12 is deprecated
  */
 #define KVM_FEATURE_CLOCKSOURCE2        3
 #define KVM_FEATURE_ASYNC_PF		4
 #define KVM_FEATURE_STEAL_TIME		5
+#define KVM_FEATURE_PV_UNHALT		6
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 9fed5be..7c93806 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
 			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
 			     (1 << KVM_FEATURE_ASYNC_PF) |
-			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
+			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
+			     (1 << KVM_FEATURE_PV_UNHALT);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4044ce0..7fc9be6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_ASYNC_PF:
 	case KVM_CAP_GET_TSC_KHZ:
 	case KVM_CAP_PCI_2_3:
+	case KVM_CAP_PV_UNHALT:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -4993,6 +4994,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+/*
+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
+ *
+ * @apicid - apicid of vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
+{
+	struct kvm_vcpu *vcpu = NULL;
+	int i;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		if (!kvm_apic_present(vcpu))
+			continue;
+
+		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
+			break;
+	}
+	if (vcpu) {
+		/*
+		 * Setting unhalt flag here can result in spurious runnable
+		 * state when unhalt reset does not happen in vcpu_block.
+		 * But that is harmless since that should soon result in halt.
+		 */
+		vcpu->arch.pv.pv_unhalted = 1;
+		/* We need everybody see unhalt before vcpu unblocks */
+		smp_mb();
+		kvm_vcpu_kick(vcpu);
+	}
+}
+
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 {
 	unsigned long nr, a0, a1, a2, a3, ret;
@@ -5026,6 +5057,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 	case KVM_HC_VAPIC_POLL_IRQ:
 		ret = 0;
 		break;
+	case KVM_HC_KICK_CPU:
+		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
+		ret = 0;
+		break;
 	default:
 		ret = -KVM_ENOSYS;
 		break;
@@ -6128,6 +6163,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
 	BUG_ON(vcpu->kvm == NULL);
 	kvm = vcpu->kvm;
 
+	kvm_arch_vcpu_reset_pv_unhalted(vcpu);
 	vcpu->arch.emulate_ctxt.ops = &emulate_ops;
 	if (!irqchip_in_kernel(kvm) || kvm_vcpu_is_bsp(vcpu))
 		vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
@@ -6398,11 +6434,17 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
 		!vcpu->arch.apf.halted)
 		|| !list_empty_careful(&vcpu->async_pf.done)
 		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
+		|| vcpu->arch.pv.pv_unhalted
 		|| atomic_read(&vcpu->arch.nmi_queued) ||
 		(kvm_arch_interrupt_allowed(vcpu) &&
 		 kvm_cpu_has_interrupt(vcpu));
 }
 
+void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.pv.pv_unhalted = 0;
+}
+
 void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
 {
 	int me;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 6c322a9..a189f02 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -589,6 +589,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_S390_UCONTROL 73
 #define KVM_CAP_SYNC_REGS 74
 #define KVM_CAP_PCI_2_3 75
+#define KVM_CAP_PV_UNHALT 76
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index ff476dd..38226e1 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_KICK_CPU			5
 
 /*
  * hypercalls use architecture specific
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 42b7393..edf56d4 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
 		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
 
 		if (kvm_arch_vcpu_runnable(vcpu)) {
+			/*
+			 * This is the only safe place to reset unhalt flag.
+			 * otherwise it results in loosing the notification
+			 * which eventually can result in vcpu hangs.
+			 */
+			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
+			/* preventing reordering should be enough here */
+			barrier();
 			kvm_make_request(KVM_REQ_UNHALT, vcpu);
 			break;
 		}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLnf-0001wV-BV; Mon, 23 Apr 2012 16:07:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMGCb-0003Ne-CG
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:09:01 +0000
Received: from [85.158.143.35:17233] by server-1.bemta-4.messagelabs.com id
	07/C3-20925-C3A259F4; Mon, 23 Apr 2012 10:09:00 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335175735!13661995!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiA5ODk2OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32411 invoked from network); 23 Apr 2012 10:08:58 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:08:58 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:38:54 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:38:52 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA7Nn12793472
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:38:51 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFTrK8001451
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:59:55 +0530
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFTrMp001444; Mon, 23 Apr 2012 20:59:53 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:02 +0530
Message-Id: <20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-2674-0000-0000-00000422D65A
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 2/5] kvm : Fold pv_unhalt flag into
	GET_MP_STATE ioctl to aid migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6faa550..7354c1b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
 int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
 				    struct kvm_mp_state *mp_state)
 {
-	mp_state->mp_state = vcpu->arch.mp_state;
+	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED &&
+				vcpu->arch.pv.pv_unhalted) ?
+	KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
 	return 0;
 }
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLnf-0001wV-BV; Mon, 23 Apr 2012 16:07:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMGCb-0003Ne-CG
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:09:01 +0000
Received: from [85.158.143.35:17233] by server-1.bemta-4.messagelabs.com id
	07/C3-20925-C3A259F4; Mon, 23 Apr 2012 10:09:00 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335175735!13661995!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiA5ODk2OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32411 invoked from network); 23 Apr 2012 10:08:58 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:08:58 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:38:54 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:38:52 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA7Nn12793472
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:38:51 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFTrK8001451
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:59:55 +0530
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFTrMp001444; Mon, 23 Apr 2012 20:59:53 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:02 +0530
Message-Id: <20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-2674-0000-0000-00000422D65A
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 2/5] kvm : Fold pv_unhalt flag into
	GET_MP_STATE ioctl to aid migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6faa550..7354c1b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
 int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
 				    struct kvm_mp_state *mp_state)
 {
-	mp_state->mp_state = vcpu->arch.mp_state;
+	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED &&
+				vcpu->arch.pv.pv_unhalted) ?
+	KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
 	return 0;
 }
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLnf-0001wh-PK; Mon, 23 Apr 2012 16:07:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMGCr-0003O7-R2
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:09:18 +0000
Received: from [193.109.254.147:6035] by server-12.bemta-14.messagelabs.com id
	94/4A-05898-D4A259F4; Mon, 23 Apr 2012 10:09:17 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335175753!5847651!1
X-Originating-IP: [122.248.162.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOCA9PiA2OTU2Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10639 invoked from network); 23 Apr 2012 10:09:16 -0000
Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:09:16 -0000
Received: from /spool/local
	by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:39:12 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp08.in.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:39:10 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA6QPR2986210
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:37:54 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFUOPg004960
	for <xen-devel@lists.xensource.com>; Tue, 24 Apr 2012 01:30:25 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFUOOK004928; Tue, 24 Apr 2012 01:30:24 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:29:37 +0530
Message-Id: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-2000-0000-0000-00000736A64F
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V6 0/5] kvm : Paravirt-spinlock support for
	KVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The 5-patch series to follow this email extends KVM-hypervisor and Linux guest
running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's 
implementation.

One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick
another vcpu out of halt state.
The blocking of vcpu is done using halt() in (lock_spinning) slowpath.

Note: 1) patch is based on 3.4-rc3 + ticketlock patches in 
	https://lkml.org/lkml/2012/4/19/335 

 [ The patches are targeted for 3.5 window ]

Changes in V6:
- Rebased to 3.4-rc3
- Removed debugfs changes patch which should now be in Xen/linux-next.
  (https://lkml.org/lkml/2012/3/30/687)
- Removed PV_UNHALT_MSR since currently we don't need guest communication,
  and made pv_unhalt folded to GET_MP_STATE (Marcello, Avi[long back])
- Take jumplabel changes from Ingo/Jason into use (static_key_slow_inc usage)
- Added inline to spinlock_init in non PARAVIRT case
- Move arch specific code to arch/x86 and add stubs to other archs (Marcello)
- Added more comments on pv_unhalt usage etc (Marcello)

Changes in V5:
- rebased to 3.3-rc6
- added PV_UNHALT_MSR that would help in live migration (Avi)
- removed PV_LOCK_KICK vcpu request and pv_unhalt flag (re)added.
- Changed hypercall documentaion (Alex).
- mode_t changed to umode_t in debugfs.
- MSR related documentation added.
- rename PV_LOCK_KICK to PV_UNHALT. 
- host and guest patches not mixed. (Marcelo, Alex)
- kvm_kick_cpu now takes cpu so it can be used by flush_tlb_ipi_other 
   paravirtualization (Nikunj)
- coding style changes in variable declarion etc (Srikar)

Changes in V4:
- reabsed to 3.2.0 pre.
- use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching (Avi)
- fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
  changes for UNHALT path to make pv ticket spinlock migration friendly(Avi, Marcello)
- Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
  and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
- Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
- cumulative variable type changed (int ==> u32) in add_stat (Konrad)
- remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case

Changes in V3:
- rebased to 3.2-rc1
- use halt() instead of wait for kick hypercall.
- modify kick hyper call to do wakeup halted vcpu.
- hook kvm_spinlock_init to smp_prepare_cpus call (moved the call out of head##.c).
- fix the potential race when zero_stat is read.
- export debugfs_create_32 and add documentation to API.
- use static inline and enum instead of ADDSTAT macro. 
- add  barrier() in after setting kick_vcpu.
- empty static inline function for kvm_spinlock_init.
- combine the patches one and two readuce overhead.
- make KVM_DEBUGFS depends on DEBUGFS.
- include debugfs header unconditionally.

Changes in V2:
- rebased patchesto -rc9
- synchronization related changes based on Jeremy's changes 
 (Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>) pointed by 
 Stephan Diestelhorst <stephan.diestelhorst@amd.com>
- enabling 32 bit guests
- splitted patches into two more chunks

Results:
results for PLE / non PLE machine were posted for V5 patches in
 https://lkml.org/lkml/2012/3/23/50
 https://lkml.org/lkml/2012/4/5/73

Current series is giving similar results but more formal results will
be posted in next couple of days.
      
Interestingly with current patchset I do not see CPU stalls observed in vanilla.

TODO: 1) remove CONFIG_PARAVIRT_SPINLOCK ?
      2) experiments on further optimization possibilities.
		(discussed in V6 of ticketlock) 
      3) possible debugfs cleanups (combining common code of Xen/KVM)

Let me know if you have any sugestion/comments...
---
 V5 kernel changes:
 https://lkml.org/lkml/2012/3/23/50
 Qemu changes for V5:
 http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04455.html 

 V4 kernel changes:
 https://lkml.org/lkml/2012/1/14/66

 Qemu changes for V4:
 http://www.mail-archive.com/kvm@vger.kernel.org/msg66450.html

 V3 kernel Changes:
 https://lkml.org/lkml/2011/11/30/62
 V2 kernel changes : 
 https://lkml.org/lkml/2011/10/23/207

 Previous discussions : (posted by Srivatsa V).
 https://lkml.org/lkml/2010/7/26/24
 https://lkml.org/lkml/2011/1/19/212
 
 Qemu patch for V3:
 http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html
 
Srivatsa Vaddagiri (3): 
  Add a hypercall to KVM hypervisor to support pv-ticketlocks
  Added configuration support to enable debug information for KVM Guests
  pv-ticketlock support for linux guests running on KVM hypervisor

Raghavendra K T (2):
  Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration
  Add documentation on Hypercalls and features used for PV spinlock

 Documentation/virtual/kvm/api.txt        |    7 +
 Documentation/virtual/kvm/cpuid.txt      |    4 +
 Documentation/virtual/kvm/hypercalls.txt |   59 +++++++
 arch/ia64/include/asm/kvm_host.h         |    3 +
 arch/powerpc/include/asm/kvm_host.h      |    4 +
 arch/s390/include/asm/kvm_host.h         |    4 +
 arch/x86/Kconfig                         |    9 +
 arch/x86/include/asm/kvm_host.h          |    6 +
 arch/x86/include/asm/kvm_para.h          |   16 ++-
 arch/x86/kernel/kvm.c                    |  254 ++++++++++++++++++++++++++++++
 arch/x86/kvm/cpuid.c                     |    3 +-
 arch/x86/kvm/x86.c                       |   46 ++++++-
 include/linux/kvm.h                      |    1 +
 include/linux/kvm_para.h                 |    1 +
 virt/kvm/kvm_main.c                      |    8 +
 15 files changed, 421 insertions(+), 4 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLnf-0001wh-PK; Mon, 23 Apr 2012 16:07:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMGCr-0003O7-R2
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:09:18 +0000
Received: from [193.109.254.147:6035] by server-12.bemta-14.messagelabs.com id
	94/4A-05898-D4A259F4; Mon, 23 Apr 2012 10:09:17 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335175753!5847651!1
X-Originating-IP: [122.248.162.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOCA9PiA2OTU2Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10639 invoked from network); 23 Apr 2012 10:09:16 -0000
Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:09:16 -0000
Received: from /spool/local
	by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:39:12 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp08.in.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:39:10 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA6QPR2986210
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:37:54 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFUOPg004960
	for <xen-devel@lists.xensource.com>; Tue, 24 Apr 2012 01:30:25 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFUOOK004928; Tue, 24 Apr 2012 01:30:24 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:29:37 +0530
Message-Id: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-2000-0000-0000-00000736A64F
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V6 0/5] kvm : Paravirt-spinlock support for
	KVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The 5-patch series to follow this email extends KVM-hypervisor and Linux guest
running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's 
implementation.

One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick
another vcpu out of halt state.
The blocking of vcpu is done using halt() in (lock_spinning) slowpath.

Note: 1) patch is based on 3.4-rc3 + ticketlock patches in 
	https://lkml.org/lkml/2012/4/19/335 

 [ The patches are targeted for 3.5 window ]

Changes in V6:
- Rebased to 3.4-rc3
- Removed debugfs changes patch which should now be in Xen/linux-next.
  (https://lkml.org/lkml/2012/3/30/687)
- Removed PV_UNHALT_MSR since currently we don't need guest communication,
  and made pv_unhalt folded to GET_MP_STATE (Marcello, Avi[long back])
- Take jumplabel changes from Ingo/Jason into use (static_key_slow_inc usage)
- Added inline to spinlock_init in non PARAVIRT case
- Move arch specific code to arch/x86 and add stubs to other archs (Marcello)
- Added more comments on pv_unhalt usage etc (Marcello)

Changes in V5:
- rebased to 3.3-rc6
- added PV_UNHALT_MSR that would help in live migration (Avi)
- removed PV_LOCK_KICK vcpu request and pv_unhalt flag (re)added.
- Changed hypercall documentaion (Alex).
- mode_t changed to umode_t in debugfs.
- MSR related documentation added.
- rename PV_LOCK_KICK to PV_UNHALT. 
- host and guest patches not mixed. (Marcelo, Alex)
- kvm_kick_cpu now takes cpu so it can be used by flush_tlb_ipi_other 
   paravirtualization (Nikunj)
- coding style changes in variable declarion etc (Srikar)

Changes in V4:
- reabsed to 3.2.0 pre.
- use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching (Avi)
- fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
  changes for UNHALT path to make pv ticket spinlock migration friendly(Avi, Marcello)
- Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
  and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
- Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
- cumulative variable type changed (int ==> u32) in add_stat (Konrad)
- remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case

Changes in V3:
- rebased to 3.2-rc1
- use halt() instead of wait for kick hypercall.
- modify kick hyper call to do wakeup halted vcpu.
- hook kvm_spinlock_init to smp_prepare_cpus call (moved the call out of head##.c).
- fix the potential race when zero_stat is read.
- export debugfs_create_32 and add documentation to API.
- use static inline and enum instead of ADDSTAT macro. 
- add  barrier() in after setting kick_vcpu.
- empty static inline function for kvm_spinlock_init.
- combine the patches one and two readuce overhead.
- make KVM_DEBUGFS depends on DEBUGFS.
- include debugfs header unconditionally.

Changes in V2:
- rebased patchesto -rc9
- synchronization related changes based on Jeremy's changes 
 (Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>) pointed by 
 Stephan Diestelhorst <stephan.diestelhorst@amd.com>
- enabling 32 bit guests
- splitted patches into two more chunks

Results:
results for PLE / non PLE machine were posted for V5 patches in
 https://lkml.org/lkml/2012/3/23/50
 https://lkml.org/lkml/2012/4/5/73

Current series is giving similar results but more formal results will
be posted in next couple of days.
      
Interestingly with current patchset I do not see CPU stalls observed in vanilla.

TODO: 1) remove CONFIG_PARAVIRT_SPINLOCK ?
      2) experiments on further optimization possibilities.
		(discussed in V6 of ticketlock) 
      3) possible debugfs cleanups (combining common code of Xen/KVM)

Let me know if you have any sugestion/comments...
---
 V5 kernel changes:
 https://lkml.org/lkml/2012/3/23/50
 Qemu changes for V5:
 http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04455.html 

 V4 kernel changes:
 https://lkml.org/lkml/2012/1/14/66

 Qemu changes for V4:
 http://www.mail-archive.com/kvm@vger.kernel.org/msg66450.html

 V3 kernel Changes:
 https://lkml.org/lkml/2011/11/30/62
 V2 kernel changes : 
 https://lkml.org/lkml/2011/10/23/207

 Previous discussions : (posted by Srivatsa V).
 https://lkml.org/lkml/2010/7/26/24
 https://lkml.org/lkml/2011/1/19/212
 
 Qemu patch for V3:
 http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html
 
Srivatsa Vaddagiri (3): 
  Add a hypercall to KVM hypervisor to support pv-ticketlocks
  Added configuration support to enable debug information for KVM Guests
  pv-ticketlock support for linux guests running on KVM hypervisor

Raghavendra K T (2):
  Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration
  Add documentation on Hypercalls and features used for PV spinlock

 Documentation/virtual/kvm/api.txt        |    7 +
 Documentation/virtual/kvm/cpuid.txt      |    4 +
 Documentation/virtual/kvm/hypercalls.txt |   59 +++++++
 arch/ia64/include/asm/kvm_host.h         |    3 +
 arch/powerpc/include/asm/kvm_host.h      |    4 +
 arch/s390/include/asm/kvm_host.h         |    4 +
 arch/x86/Kconfig                         |    9 +
 arch/x86/include/asm/kvm_host.h          |    6 +
 arch/x86/include/asm/kvm_para.h          |   16 ++-
 arch/x86/kernel/kvm.c                    |  254 ++++++++++++++++++++++++++++++
 arch/x86/kvm/cpuid.c                     |    3 +-
 arch/x86/kvm/x86.c                       |   46 ++++++-
 include/linux/kvm.h                      |    1 +
 include/linux/kvm_para.h                 |    1 +
 virt/kvm/kvm_main.c                      |    8 +
 15 files changed, 421 insertions(+), 4 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLne-0001w4-Hy; Mon, 23 Apr 2012 16:07:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMG4a-0003Co-AI
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:00:44 +0000
Received: from [85.158.139.83:28722] by server-1.bemta-5.messagelabs.com id
	66/AF-28458-B48259F4; Mon, 23 Apr 2012 10:00:43 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335175239!25031870!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiA5OTI0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27623 invoked from network); 23 Apr 2012 10:00:42 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 10:00:42 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:30:38 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:30:37 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA0aup4091932
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:30:36 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFV395005746
	for <xen-devel@lists.xensource.com>; Tue, 24 Apr 2012 01:31:05 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFV3g7005707; Tue, 24 Apr 2012 01:31:03 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:23 +0530
Message-Id: <20120423100023.30893.53020.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-2674-0000-0000-00000422CD99
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 4/5] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>

During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PV_UNHALT) to support pv-ticketlocks. If so,
 support for pv-ticketlocks is registered via pv_lock_ops.

Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 5b647ea..77266d3 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -195,10 +195,20 @@ void kvm_async_pf_task_wait(u32 token);
 void kvm_async_pf_task_wake(u32 token);
 u32 kvm_read_and_reset_pf_reason(void);
 extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* !CONFIG_PARAVIRT_SPINLOCKS */
+static inline void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
 #define kvm_async_pf_task_wait(T) do {} while(0)
 #define kvm_async_pf_task_wake(T) do {} while(0)
+
 static inline u32 kvm_read_and_reset_pf_reason(void)
 {
 	return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b8ba6e4..98f0378 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -33,6 +33,7 @@
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/kprobes.h>
+#include <linux/debugfs.h>
 #include <asm/timer.h>
 #include <asm/cpu.h>
 #include <asm/traps.h>
@@ -368,6 +369,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
 #endif
 	kvm_guest_cpu_init();
 	native_smp_prepare_boot_cpu();
+	kvm_spinlock_init();
 }
 
 static void __cpuinit kvm_guest_cpu_online(void *dummy)
@@ -450,3 +452,255 @@ static __init int activate_jump_labels(void)
 	return 0;
 }
 arch_initcall(activate_jump_labels);
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+enum kvm_contention_stat {
+	TAKEN_SLOW,
+	TAKEN_SLOW_PICKUP,
+	RELEASED_SLOW,
+	RELEASED_SLOW_KICKED,
+	NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+#define HISTO_BUCKETS	30
+
+static struct kvm_spinlock_stats
+{
+	u32 contention_stats[NR_CONTENTION_STATS];
+	u32 histo_spin_blocked[HISTO_BUCKETS+1];
+	u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+	u8 ret;
+	u8 old;
+
+	old = ACCESS_ONCE(zero_stats);
+	if (unlikely(old)) {
+		ret = cmpxchg(&zero_stats, old, 0);
+		/* This ensures only one fellow resets the stat */
+		if (ret == old)
+			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
+	}
+}
+
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+	check_zero();
+	spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+	return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+	unsigned index;
+
+	index = ilog2(delta);
+	check_zero();
+
+	if (index < HISTO_BUCKETS)
+		array[index]++;
+	else
+		array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+	u32 delta;
+
+	delta = sched_clock() - start;
+	__spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+	spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+	d_kvm_debug = debugfs_create_dir("kvm", NULL);
+	if (!d_kvm_debug)
+		printk(KERN_WARNING "Could not create 'kvm' debugfs directory\n");
+
+	return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+	struct dentry *d_kvm;
+
+	d_kvm = kvm_init_debugfs();
+	if (d_kvm == NULL)
+		return -ENOMEM;
+
+	d_spin_debug = debugfs_create_dir("spinlocks", d_kvm);
+
+	debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats);
+
+	debugfs_create_u32("taken_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW]);
+	debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]);
+
+	debugfs_create_u32("released_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW]);
+	debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]);
+
+	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
+			   &spinlock_stats.time_blocked);
+
+	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
+		     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
+
+	return 0;
+}
+fs_initcall(kvm_spinlock_debugfs);
+#else  /* !CONFIG_KVM_DEBUG_FS */
+#define TIMEOUT			(1 << 10)
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+}
+
+static inline u64 spin_time_start(void)
+{
+	return 0;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+}
+#endif  /* CONFIG_KVM_DEBUG_FS */
+
+struct kvm_lock_waiting {
+	struct arch_spinlock *lock;
+	__ticket_t want;
+};
+
+/* cpus 'waiting' on a spinlock to become available */
+static cpumask_t waiting_cpus;
+
+/* Track spinlock on which a cpu is waiting */
+static DEFINE_PER_CPU(struct kvm_lock_waiting, lock_waiting);
+
+static void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
+{
+	struct kvm_lock_waiting *w;
+	int cpu;
+	u64 start;
+	unsigned long flags;
+
+	w = &__get_cpu_var(lock_waiting);
+	cpu = smp_processor_id();
+	start = spin_time_start();
+
+	/*
+	 * Make sure an interrupt handler can't upset things in a
+	 * partially setup state.
+	 */
+	local_irq_save(flags);
+
+	/*
+	 * The ordering protocol on this is that the "lock" pointer
+	 * may only be set non-NULL if the "want" ticket is correct.
+	 * If we're updating "want", we must first clear "lock".
+	 */
+	w->lock = NULL;
+	smp_wmb();
+	w->want = want;
+	smp_wmb();
+	w->lock = lock;
+
+	add_stats(TAKEN_SLOW, 1);
+
+	/*
+	 * This uses set_bit, which is atomic but we should not rely on its
+	 * reordering gurantees. So barrier is needed after this call.
+	 */
+	cpumask_set_cpu(cpu, &waiting_cpus);
+
+	barrier();
+
+	/*
+	 * Mark entry to slowpath before doing the pickup test to make
+	 * sure we don't deadlock with an unlocker.
+	 */
+	__ticket_enter_slowpath(lock);
+
+	/*
+	 * check again make sure it didn't become free while
+	 * we weren't looking.
+	 */
+	if (ACCESS_ONCE(lock->tickets.head) == want) {
+		add_stats(TAKEN_SLOW_PICKUP, 1);
+		goto out;
+	}
+
+	/* Allow interrupts while blocked */
+	local_irq_restore(flags);
+
+	/* halt until it's our turn and kicked. */
+	halt();
+
+	local_irq_save(flags);
+out:
+	cpumask_clear_cpu(cpu, &waiting_cpus);
+	w->lock = NULL;
+	local_irq_restore(flags);
+	spin_time_accum_blocked(start);
+}
+PV_CALLEE_SAVE_REGS_THUNK(kvm_lock_spinning);
+
+/* Kick a cpu by its apicid*/
+static inline void kvm_kick_cpu(int cpu)
+{
+	int apicid;
+
+	apicid = per_cpu(x86_cpu_to_apicid, cpu);
+	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
+}
+
+/* Kick vcpu waiting on @lock->head to reach value @ticket */
+static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
+{
+	int cpu;
+
+	add_stats(RELEASED_SLOW, 1);
+	for_each_cpu(cpu, &waiting_cpus) {
+		const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu);
+		if (ACCESS_ONCE(w->lock) == lock &&
+		    ACCESS_ONCE(w->want) == ticket) {
+			add_stats(RELEASED_SLOW_KICKED, 1);
+			kvm_kick_cpu(cpu);
+			break;
+		}
+	}
+}
+
+/*
+ * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
+ */
+void __init kvm_spinlock_init(void)
+{
+	if (!kvm_para_available())
+		return;
+	/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
+	if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
+		return;
+
+	static_key_slow_inc(&paravirt_ticketlocks_enabled);
+
+	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(kvm_lock_spinning);
+	pv_lock_ops.unlock_kick = kvm_unlock_kick;
+}
+#endif	/* CONFIG_PARAVIRT_SPINLOCKS */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLne-0001w4-Hy; Mon, 23 Apr 2012 16:07:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMG4a-0003Co-AI
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:00:44 +0000
Received: from [85.158.139.83:28722] by server-1.bemta-5.messagelabs.com id
	66/AF-28458-B48259F4; Mon, 23 Apr 2012 10:00:43 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335175239!25031870!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiA5OTI0NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27623 invoked from network); 23 Apr 2012 10:00:42 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 10:00:42 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 15:30:38 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 15:30:37 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA0aup4091932
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 15:30:36 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NFV395005746
	for <xen-devel@lists.xensource.com>; Tue, 24 Apr 2012 01:31:05 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NFV3g7005707; Tue, 24 Apr 2012 01:31:03 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:23 +0530
Message-Id: <20120423100023.30893.53020.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042310-2674-0000-0000-00000422CD99
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 4/5] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>

During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PV_UNHALT) to support pv-ticketlocks. If so,
 support for pv-ticketlocks is registered via pv_lock_ops.

Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 5b647ea..77266d3 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -195,10 +195,20 @@ void kvm_async_pf_task_wait(u32 token);
 void kvm_async_pf_task_wake(u32 token);
 u32 kvm_read_and_reset_pf_reason(void);
 extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* !CONFIG_PARAVIRT_SPINLOCKS */
+static inline void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
 #define kvm_async_pf_task_wait(T) do {} while(0)
 #define kvm_async_pf_task_wake(T) do {} while(0)
+
 static inline u32 kvm_read_and_reset_pf_reason(void)
 {
 	return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b8ba6e4..98f0378 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -33,6 +33,7 @@
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/kprobes.h>
+#include <linux/debugfs.h>
 #include <asm/timer.h>
 #include <asm/cpu.h>
 #include <asm/traps.h>
@@ -368,6 +369,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
 #endif
 	kvm_guest_cpu_init();
 	native_smp_prepare_boot_cpu();
+	kvm_spinlock_init();
 }
 
 static void __cpuinit kvm_guest_cpu_online(void *dummy)
@@ -450,3 +452,255 @@ static __init int activate_jump_labels(void)
 	return 0;
 }
 arch_initcall(activate_jump_labels);
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+enum kvm_contention_stat {
+	TAKEN_SLOW,
+	TAKEN_SLOW_PICKUP,
+	RELEASED_SLOW,
+	RELEASED_SLOW_KICKED,
+	NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+#define HISTO_BUCKETS	30
+
+static struct kvm_spinlock_stats
+{
+	u32 contention_stats[NR_CONTENTION_STATS];
+	u32 histo_spin_blocked[HISTO_BUCKETS+1];
+	u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+	u8 ret;
+	u8 old;
+
+	old = ACCESS_ONCE(zero_stats);
+	if (unlikely(old)) {
+		ret = cmpxchg(&zero_stats, old, 0);
+		/* This ensures only one fellow resets the stat */
+		if (ret == old)
+			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
+	}
+}
+
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+	check_zero();
+	spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+	return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+	unsigned index;
+
+	index = ilog2(delta);
+	check_zero();
+
+	if (index < HISTO_BUCKETS)
+		array[index]++;
+	else
+		array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+	u32 delta;
+
+	delta = sched_clock() - start;
+	__spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+	spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+	d_kvm_debug = debugfs_create_dir("kvm", NULL);
+	if (!d_kvm_debug)
+		printk(KERN_WARNING "Could not create 'kvm' debugfs directory\n");
+
+	return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+	struct dentry *d_kvm;
+
+	d_kvm = kvm_init_debugfs();
+	if (d_kvm == NULL)
+		return -ENOMEM;
+
+	d_spin_debug = debugfs_create_dir("spinlocks", d_kvm);
+
+	debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats);
+
+	debugfs_create_u32("taken_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW]);
+	debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]);
+
+	debugfs_create_u32("released_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW]);
+	debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]);
+
+	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
+			   &spinlock_stats.time_blocked);
+
+	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
+		     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
+
+	return 0;
+}
+fs_initcall(kvm_spinlock_debugfs);
+#else  /* !CONFIG_KVM_DEBUG_FS */
+#define TIMEOUT			(1 << 10)
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+}
+
+static inline u64 spin_time_start(void)
+{
+	return 0;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+}
+#endif  /* CONFIG_KVM_DEBUG_FS */
+
+struct kvm_lock_waiting {
+	struct arch_spinlock *lock;
+	__ticket_t want;
+};
+
+/* cpus 'waiting' on a spinlock to become available */
+static cpumask_t waiting_cpus;
+
+/* Track spinlock on which a cpu is waiting */
+static DEFINE_PER_CPU(struct kvm_lock_waiting, lock_waiting);
+
+static void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
+{
+	struct kvm_lock_waiting *w;
+	int cpu;
+	u64 start;
+	unsigned long flags;
+
+	w = &__get_cpu_var(lock_waiting);
+	cpu = smp_processor_id();
+	start = spin_time_start();
+
+	/*
+	 * Make sure an interrupt handler can't upset things in a
+	 * partially setup state.
+	 */
+	local_irq_save(flags);
+
+	/*
+	 * The ordering protocol on this is that the "lock" pointer
+	 * may only be set non-NULL if the "want" ticket is correct.
+	 * If we're updating "want", we must first clear "lock".
+	 */
+	w->lock = NULL;
+	smp_wmb();
+	w->want = want;
+	smp_wmb();
+	w->lock = lock;
+
+	add_stats(TAKEN_SLOW, 1);
+
+	/*
+	 * This uses set_bit, which is atomic but we should not rely on its
+	 * reordering gurantees. So barrier is needed after this call.
+	 */
+	cpumask_set_cpu(cpu, &waiting_cpus);
+
+	barrier();
+
+	/*
+	 * Mark entry to slowpath before doing the pickup test to make
+	 * sure we don't deadlock with an unlocker.
+	 */
+	__ticket_enter_slowpath(lock);
+
+	/*
+	 * check again make sure it didn't become free while
+	 * we weren't looking.
+	 */
+	if (ACCESS_ONCE(lock->tickets.head) == want) {
+		add_stats(TAKEN_SLOW_PICKUP, 1);
+		goto out;
+	}
+
+	/* Allow interrupts while blocked */
+	local_irq_restore(flags);
+
+	/* halt until it's our turn and kicked. */
+	halt();
+
+	local_irq_save(flags);
+out:
+	cpumask_clear_cpu(cpu, &waiting_cpus);
+	w->lock = NULL;
+	local_irq_restore(flags);
+	spin_time_accum_blocked(start);
+}
+PV_CALLEE_SAVE_REGS_THUNK(kvm_lock_spinning);
+
+/* Kick a cpu by its apicid*/
+static inline void kvm_kick_cpu(int cpu)
+{
+	int apicid;
+
+	apicid = per_cpu(x86_cpu_to_apicid, cpu);
+	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
+}
+
+/* Kick vcpu waiting on @lock->head to reach value @ticket */
+static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
+{
+	int cpu;
+
+	add_stats(RELEASED_SLOW, 1);
+	for_each_cpu(cpu, &waiting_cpus) {
+		const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu);
+		if (ACCESS_ONCE(w->lock) == lock &&
+		    ACCESS_ONCE(w->want) == ticket) {
+			add_stats(RELEASED_SLOW_KICKED, 1);
+			kvm_kick_cpu(cpu);
+			break;
+		}
+	}
+}
+
+/*
+ * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
+ */
+void __init kvm_spinlock_init(void)
+{
+	if (!kvm_para_available())
+		return;
+	/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
+	if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
+		return;
+
+	static_key_slow_inc(&paravirt_ticketlocks_enabled);
+
+	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(kvm_lock_spinning);
+	pv_lock_ops.unlock_kick = kvm_unlock_kick;
+}
+#endif	/* CONFIG_PARAVIRT_SPINLOCKS */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLne-0001wJ-V4; Mon, 23 Apr 2012 16:07:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMG4q-0003DC-7K
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:01:00 +0000
Received: from [85.158.143.35:16869] by server-3.bemta-4.messagelabs.com id
	64/8D-05853-B58259F4; Mon, 23 Apr 2012 10:00:59 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335175254!13272160!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNjk4NTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26967 invoked from network); 23 Apr 2012 10:00:58 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:00:58 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 09:55:49 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 09:55:46 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA0nHG34734276
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:49 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NA0mCp012612
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:49 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NA0i7K012519; Mon, 23 Apr 2012 20:00:44 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, 
	Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:34 +0530
Message-Id: <20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042223-7014-0000-0000-000000F74425
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 

KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in paravirtual spinlock
enabled guest.

KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled
in guest. support in host is queried via
ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PV_UNHALT)

Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 6386f8c..7e2eba0 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1119,6 +1119,13 @@ support.  Instead it is reported via
 if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
 feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
 
+Paravirtualized ticket spinlocks can be enabled in guest by checking whether
+support exists in host via,
+
+  ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PV_UNHALT)
+
+if this call return true, guest can use the feature.
+
 4.47 KVM_PPC_GET_PVINFO
 
 Capability: KVM_CAP_PPC_GET_PVINFO
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 8820685..062dff9 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
 KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
                                    ||       || writing to msr 0x4b564d02
 ------------------------------------------------------------------------------
+KVM_FEATURE_PV_UNHALT              ||     6 || guest checks this feature bit
+                                   ||       || before enabling paravirtualized
+                                   ||       || spinlock support.
+------------------------------------------------------------------------------
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
                                    ||       || per-cpu warps are expected in
                                    ||       || kvmclock.
diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
new file mode 100644
index 0000000..c9e8b9c
--- /dev/null
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -0,0 +1,59 @@
+KVM Hypercalls Documentation
+===========================
+Template for documentation is
+The documenenation for hypercalls should inlcude
+1. Hypercall name, value.
+2. Architecture(s)
+3. status (deprecated, obsolete, active)
+4. Purpose
+
+
+1. KVM_HC_VAPIC_POLL_IRQ
+------------------------
+value: 1
+Architecture: x86
+Purpose:
+
+2. KVM_HC_MMU_OP
+------------------------
+value: 2
+Architecture: x86
+status: deprecated.
+Purpose: Support MMU operations such as writing to PTE,
+flushing TLB, release PT.
+
+3. KVM_HC_FEATURES
+------------------------
+value: 3
+Architecture: PPC
+Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid
+used to enumerate which hypercalls are available. On PPC, either device tree
+based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration
+mechanism (which is this hypercall) can be used.
+
+4. KVM_HC_PPC_MAP_MAGIC_PAGE
+------------------------
+value: 4
+Architecture: PPC
+Purpose: To enable communication between the hypervisor and guest there is a
+shared page that contains parts of supervisor visible register state.
+The guest can map this shared page to access its supervisor register through
+memory using this hypercall.
+
+5. KVM_HC_KICK_CPU
+------------------------
+value: 5
+Architecture: x86
+Purpose: Hypercall used to wakeup a vcpu from HLT state
+
+Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
+kernel mode for an event to occur (ex: a spinlock to become available) can
+execute HLT instruction once it has busy-waited for more than a threshold
+time-interval. Execution of HLT instruction would cause the hypervisor to put
+the vcpu to sleep until occurence of an appropriate event. Another vcpu of the
+same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
+specifying APIC ID of the vcpu to be wokenup.
+
+TODO:
+1. more information on input and output needed?
+2. Add more detail to purpose of hypercalls.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLne-0001wJ-V4; Mon, 23 Apr 2012 16:07:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SMG4q-0003DC-7K
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 10:01:00 +0000
Received: from [85.158.143.35:16869] by server-3.bemta-4.messagelabs.com id
	64/8D-05853-B58259F4; Mon, 23 Apr 2012 10:00:59 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335175254!13272160!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNjk4NTQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26967 invoked from network); 23 Apr 2012 10:00:58 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 10:00:58 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 23 Apr 2012 09:55:49 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 23 Apr 2012 09:55:46 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3NA0nHG34734276
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:49 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3NA0mCp012612
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 20:00:49 +1000
Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.112])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3NA0i7K012519; Mon, 23 Apr 2012 20:00:44 +1000
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, KVM <kvm@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, 
	Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Date: Mon, 23 Apr 2012 15:30:34 +0530
Message-Id: <20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
x-cbid: 12042223-7014-0000-0000-000000F74425
X-Mailman-Approved-At: Mon, 23 Apr 2012 16:07:36 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: [Xen-devel] [PATCH RFC V6 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 

KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in paravirtual spinlock
enabled guest.

KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled
in guest. support in host is queried via
ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PV_UNHALT)

Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 6386f8c..7e2eba0 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1119,6 +1119,13 @@ support.  Instead it is reported via
 if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
 feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
 
+Paravirtualized ticket spinlocks can be enabled in guest by checking whether
+support exists in host via,
+
+  ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PV_UNHALT)
+
+if this call return true, guest can use the feature.
+
 4.47 KVM_PPC_GET_PVINFO
 
 Capability: KVM_CAP_PPC_GET_PVINFO
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 8820685..062dff9 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
 KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
                                    ||       || writing to msr 0x4b564d02
 ------------------------------------------------------------------------------
+KVM_FEATURE_PV_UNHALT              ||     6 || guest checks this feature bit
+                                   ||       || before enabling paravirtualized
+                                   ||       || spinlock support.
+------------------------------------------------------------------------------
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
                                    ||       || per-cpu warps are expected in
                                    ||       || kvmclock.
diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
new file mode 100644
index 0000000..c9e8b9c
--- /dev/null
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -0,0 +1,59 @@
+KVM Hypercalls Documentation
+===========================
+Template for documentation is
+The documenenation for hypercalls should inlcude
+1. Hypercall name, value.
+2. Architecture(s)
+3. status (deprecated, obsolete, active)
+4. Purpose
+
+
+1. KVM_HC_VAPIC_POLL_IRQ
+------------------------
+value: 1
+Architecture: x86
+Purpose:
+
+2. KVM_HC_MMU_OP
+------------------------
+value: 2
+Architecture: x86
+status: deprecated.
+Purpose: Support MMU operations such as writing to PTE,
+flushing TLB, release PT.
+
+3. KVM_HC_FEATURES
+------------------------
+value: 3
+Architecture: PPC
+Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid
+used to enumerate which hypercalls are available. On PPC, either device tree
+based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration
+mechanism (which is this hypercall) can be used.
+
+4. KVM_HC_PPC_MAP_MAGIC_PAGE
+------------------------
+value: 4
+Architecture: PPC
+Purpose: To enable communication between the hypervisor and guest there is a
+shared page that contains parts of supervisor visible register state.
+The guest can map this shared page to access its supervisor register through
+memory using this hypercall.
+
+5. KVM_HC_KICK_CPU
+------------------------
+value: 5
+Architecture: x86
+Purpose: Hypercall used to wakeup a vcpu from HLT state
+
+Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
+kernel mode for an event to occur (ex: a spinlock to become available) can
+execute HLT instruction once it has busy-waited for more than a threshold
+time-interval. Execution of HLT instruction would cause the hypervisor to put
+the vcpu to sleep until occurence of an appropriate event. Another vcpu of the
+same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
+specifying APIC ID of the vcpu to be wokenup.
+
+TODO:
+1. more information on input and output needed?
+2. Add more detail to purpose of hypercalls.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLnq-00023X-Sl; Mon, 23 Apr 2012 16:07:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SMLno-000216-NG
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:07:49 +0000
Received: from [85.158.138.51:6377] by server-1.bemta-3.messagelabs.com id
	16/82-11491-35E759F4; Mon, 23 Apr 2012 16:07:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335197266!19051630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11075 invoked from network); 23 Apr 2012 16:07:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; 
	d="asc'?scan'208";a="12085573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:07:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 17:07:46 +0100
Message-ID: <1335197251.22133.5.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Mon, 23 Apr 2012 18:07:31 +0200
In-Reply-To: <20120423154112.GA15320@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0481999361673471092=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0481999361673471092==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-PQmv3g0QsTxO+SE7pG2e"

--=-PQmv3g0QsTxO+SE7pG2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-04-23 at 16:41 +0100, Dieter Bloms wrote:
> ok, I see the point and will change it to a union.
>
Cool!

> I checked out the source with git not hg, may I produce a diff with git
> and send it via mail ?
>=20
I think you should. Either use something automatic like git `send-email'
or just produce the diff and then inline or attach, following also the
other instructions Ian pointed you to (on the wiki)... Was it this you
were asking?

Regads,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-PQmv3g0QsTxO+SE7pG2e
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+VfkMACgkQk4XaBE3IOsShHwCfXpacx9TuPv6bMt+yrA4aPVd0
sa4An1ZOK9HUl4RpL8FZ2pAvp7pLamRw
=LFHm
-----END PGP SIGNATURE-----

--=-PQmv3g0QsTxO+SE7pG2e--


--===============0481999361673471092==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0481999361673471092==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 16:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLnq-00023X-Sl; Mon, 23 Apr 2012 16:07:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SMLno-000216-NG
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:07:49 +0000
Received: from [85.158.138.51:6377] by server-1.bemta-3.messagelabs.com id
	16/82-11491-35E759F4; Mon, 23 Apr 2012 16:07:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335197266!19051630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11075 invoked from network); 23 Apr 2012 16:07:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; 
	d="asc'?scan'208";a="12085573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:07:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 17:07:46 +0100
Message-ID: <1335197251.22133.5.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Mon, 23 Apr 2012 18:07:31 +0200
In-Reply-To: <20120423154112.GA15320@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0481999361673471092=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0481999361673471092==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-PQmv3g0QsTxO+SE7pG2e"

--=-PQmv3g0QsTxO+SE7pG2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-04-23 at 16:41 +0100, Dieter Bloms wrote:
> ok, I see the point and will change it to a union.
>
Cool!

> I checked out the source with git not hg, may I produce a diff with git
> and send it via mail ?
>=20
I think you should. Either use something automatic like git `send-email'
or just produce the diff and then inline or attach, following also the
other instructions Ian pointed you to (on the wiki)... Was it this you
were asking?

Regads,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-PQmv3g0QsTxO+SE7pG2e
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+VfkMACgkQk4XaBE3IOsShHwCfXpacx9TuPv6bMt+yrA4aPVd0
sa4An1ZOK9HUl4RpL8FZ2pAvp7pLamRw
=LFHm
-----END PGP SIGNATURE-----

--=-PQmv3g0QsTxO+SE7pG2e--


--===============0481999361673471092==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0481999361673471092==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 16:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLtl-0003Is-VZ; Mon, 23 Apr 2012 16:13:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SMLtk-0003Id-7n
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:13:56 +0000
Received: from [85.158.139.83:7969] by server-8.bemta-5.messagelabs.com id
	87/DA-26964-3CF759F4; Mon, 23 Apr 2012 16:13:55 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335197631!22398025!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12387 invoked from network); 23 Apr 2012 16:13:52 -0000
Received: from mail-gy0-f173.google.com (HELO mail-gy0-f173.google.com)
	(209.85.160.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:13:52 -0000
Received: by ghrr14 with SMTP id r14so7420958ghr.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 09:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=CnKP6SJIv64xYY765IAbti606Yfgd4OdwKluRZb/b9U=;
	b=t5aFnIsj4w+xxPfr062WkHu0PkJo7nngcPA83y7rJaTOMJcTgqvjOAruQ/O9wnl73h
	QHP09lI0GB7ub4tlAxLisMfzpAeSRjQO9PNUJHsbsyRm/uQBCP6rGdpfnGHTMdr2TbHk
	defS68NT9h0eud43MGxtaC/otX68l7Jy+nFyJz0P9pJqc+hCRTioj/n46/w0Jqy/XCwS
	IAEfNIjCmIJvST4oAqji0YozdVdC8pfDs1ZPijE0PSeTpZnakFd17yx8DoTFjRqwFWvn
	j8mSF98GdXS8sHkC5dYzu/1Af6kGgLT1aXaCZYlgGJavjA3MqWQKRwABgNjRC9V5Ri8H
	18VA==
MIME-Version: 1.0
Received: by 10.60.12.162 with SMTP id z2mr15693858oeb.47.1335197630193; Mon,
	23 Apr 2012 09:13:50 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Mon, 23 Apr 2012 09:13:49 -0700 (PDT)
In-Reply-To: <20120423063616.GE2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
Date: Mon, 23 Apr 2012 13:13:49 -0300
Message-ID: <CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4726630449669378702=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4726630449669378702==
Content-Type: multipart/alternative; boundary=e89a8f83a03b73df4004be5aec38

--e89a8f83a03b73df4004be5aec38
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Pasi,

thank you for reply.

I'm using Debian Squeeze, and I'm compiling Xen from source (.tar.gz). I
ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.

Notice: I couldn't run in xen_unstable or dom0 then I returned to install
environment (Debian Squeeze)

My attempt with modules and now with xenstored command (oxenstored command
works) was in Debian Squeeze. In this case I think I can't load these
modules or run this command, but I'm not sure. Then your questions can not
be in this scope. What do you think?

Thanks, Eduardo

Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <pasik@iki.fi> escreveu:

> On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
> >    hi guys,
> >
>
> Hello,
>
> >    It's my first time here and in a mailing lists, I only participated =
in
> >    forums before. Please, If I make a mistake you should advise me.
> Let's go!
> >
> >    I was reading "xencommons not start" in a Remus Forum in order to
> install
> >    Remus.
> >    Well* I followed the tutorial
> >    <[1]http://remusha.wikidot.com/configuring-and-installing-remus>, I
> reboot
> >    in xen_unstable and I had a error message:
> >
> >    error: couldn't open file
> >    error: you need to load the multiboot kernel first
> >
> >    then I redid tutorial after "Adapt Grub" and in a moment I do comman=
d:
> >
> >    # /etc/init.d/xend start
> >    xencommons should be started first.
> >
> >    but I had done "/etc/init.d/xencommons start" before and no error
> message
> >    returned !!!???
> >
> >    I also tried insert modules manually (coz in other mailing list said
> to
> >    put some modules - see my setups after this mail) but I had:
> >
> >    # modprobe xen-evtchn
> >    FATAL: Module xen_evtchn not found.
> >
>
> So xen event channel support is not compiled as a module?
> is it enabled at all in your dom0 kernel config?
>
> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>
> -- Pasi
>
>
>

--e89a8f83a03b73df4004be5aec38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Hi Pasi,<br><br>thank you for reply.<br><br>I&#3=
9;m using Debian Squeeze, and I&#39;m compiling Xen from source (.tar.gz). =
I ran &quot;make install-tools PYTHON_PREFIX_ARG=3D&quot; to install Xen.<b=
r>
<br>Notice: I couldn&#39;t run in xen_unstable or dom0 then I returned to i=
nstall environment (Debian Squeeze)<br><br>My attempt with modules and now =
with xenstored command (oxenstored command works) was in Debian Squeeze. In=
 this case I think I can&#39;t load these modules or run this command,  but=
 I&#39;m not sure. Then your questions can not be in this scope. What do yo=
u think?<br>
<br>Thanks, Eduardo<br><br><div class=3D"gmail_quote">Em 23 de abril de 201=
2 03:36, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@=
iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt;</span> escreveu:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wrote:<br=
>
&gt; =A0 =A0hi guys,<br>
&gt;<br>
<br>
Hello,<br>
<div class=3D"im"><br>
&gt; =A0 =A0It&#39;s my first time here and in a mailing lists, I only part=
icipated in<br>
&gt; =A0 =A0forums before. Please, If I make a mistake you should advise me=
. Let&#39;s go!<br>
&gt;<br>
&gt; =A0 =A0I was reading &quot;xencommons not start&quot; in a Remus Forum=
 in order to install<br>
&gt; =A0 =A0Remus.<br>
</div>&gt; =A0 =A0Well* I followed the tutorial<br>
&gt; =A0 =A0&lt;[1]<a href=3D"http://remusha.wikidot.com/configuring-and-in=
stalling-remus" target=3D"_blank">http://remusha.wikidot.com/configuring-an=
d-installing-remus</a>&gt;, I reboot<br>
<div class=3D"im">&gt; =A0 =A0in xen_unstable and I had a error message:<br=
>
&gt;<br>
&gt; =A0 =A0error: couldn&#39;t open file<br>
&gt; =A0 =A0error: you need to load the multiboot kernel first<br>
&gt;<br>
&gt; =A0 =A0then I redid tutorial after &quot;Adapt Grub&quot; and in a mom=
ent I do command:<br>
&gt;<br>
&gt; =A0 =A0# /etc/init.d/xend start<br>
&gt; =A0 =A0xencommons should be started first.<br>
&gt;<br>
&gt; =A0 =A0but I had done &quot;/etc/init.d/xencommons start&quot; before =
and no error message<br>
&gt; =A0 =A0returned !!!???<br>
&gt;<br>
&gt; =A0 =A0I also tried insert modules manually (coz in other mailing list=
 said to<br>
&gt; =A0 =A0put some modules - see my setups after this mail) but I had:<br=
>
&gt;<br>
&gt; =A0 =A0# modprobe xen-evtchn<br>
&gt; =A0 =A0FATAL: Module xen_evtchn not found.<br>
&gt;<br>
<br>
</div>So xen event channel support is not compiled as a module?<br>
is it enabled at all in your dom0 kernel config?<br>
<br>
<a href=3D"http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails=
.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xen_Common_Problems#Startin=
g_xend_fails.3F</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- Pasi<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--e89a8f83a03b73df4004be5aec38--


--===============4726630449669378702==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4726630449669378702==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 16:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLtl-0003Is-VZ; Mon, 23 Apr 2012 16:13:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SMLtk-0003Id-7n
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:13:56 +0000
Received: from [85.158.139.83:7969] by server-8.bemta-5.messagelabs.com id
	87/DA-26964-3CF759F4; Mon, 23 Apr 2012 16:13:55 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335197631!22398025!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12387 invoked from network); 23 Apr 2012 16:13:52 -0000
Received: from mail-gy0-f173.google.com (HELO mail-gy0-f173.google.com)
	(209.85.160.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:13:52 -0000
Received: by ghrr14 with SMTP id r14so7420958ghr.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 09:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=CnKP6SJIv64xYY765IAbti606Yfgd4OdwKluRZb/b9U=;
	b=t5aFnIsj4w+xxPfr062WkHu0PkJo7nngcPA83y7rJaTOMJcTgqvjOAruQ/O9wnl73h
	QHP09lI0GB7ub4tlAxLisMfzpAeSRjQO9PNUJHsbsyRm/uQBCP6rGdpfnGHTMdr2TbHk
	defS68NT9h0eud43MGxtaC/otX68l7Jy+nFyJz0P9pJqc+hCRTioj/n46/w0Jqy/XCwS
	IAEfNIjCmIJvST4oAqji0YozdVdC8pfDs1ZPijE0PSeTpZnakFd17yx8DoTFjRqwFWvn
	j8mSF98GdXS8sHkC5dYzu/1Af6kGgLT1aXaCZYlgGJavjA3MqWQKRwABgNjRC9V5Ri8H
	18VA==
MIME-Version: 1.0
Received: by 10.60.12.162 with SMTP id z2mr15693858oeb.47.1335197630193; Mon,
	23 Apr 2012 09:13:50 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Mon, 23 Apr 2012 09:13:49 -0700 (PDT)
In-Reply-To: <20120423063616.GE2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
Date: Mon, 23 Apr 2012 13:13:49 -0300
Message-ID: <CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4726630449669378702=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4726630449669378702==
Content-Type: multipart/alternative; boundary=e89a8f83a03b73df4004be5aec38

--e89a8f83a03b73df4004be5aec38
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Pasi,

thank you for reply.

I'm using Debian Squeeze, and I'm compiling Xen from source (.tar.gz). I
ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.

Notice: I couldn't run in xen_unstable or dom0 then I returned to install
environment (Debian Squeeze)

My attempt with modules and now with xenstored command (oxenstored command
works) was in Debian Squeeze. In this case I think I can't load these
modules or run this command, but I'm not sure. Then your questions can not
be in this scope. What do you think?

Thanks, Eduardo

Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <pasik@iki.fi> escreveu:

> On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
> >    hi guys,
> >
>
> Hello,
>
> >    It's my first time here and in a mailing lists, I only participated =
in
> >    forums before. Please, If I make a mistake you should advise me.
> Let's go!
> >
> >    I was reading "xencommons not start" in a Remus Forum in order to
> install
> >    Remus.
> >    Well* I followed the tutorial
> >    <[1]http://remusha.wikidot.com/configuring-and-installing-remus>, I
> reboot
> >    in xen_unstable and I had a error message:
> >
> >    error: couldn't open file
> >    error: you need to load the multiboot kernel first
> >
> >    then I redid tutorial after "Adapt Grub" and in a moment I do comman=
d:
> >
> >    # /etc/init.d/xend start
> >    xencommons should be started first.
> >
> >    but I had done "/etc/init.d/xencommons start" before and no error
> message
> >    returned !!!???
> >
> >    I also tried insert modules manually (coz in other mailing list said
> to
> >    put some modules - see my setups after this mail) but I had:
> >
> >    # modprobe xen-evtchn
> >    FATAL: Module xen_evtchn not found.
> >
>
> So xen event channel support is not compiled as a module?
> is it enabled at all in your dom0 kernel config?
>
> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>
> -- Pasi
>
>
>

--e89a8f83a03b73df4004be5aec38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Hi Pasi,<br><br>thank you for reply.<br><br>I&#3=
9;m using Debian Squeeze, and I&#39;m compiling Xen from source (.tar.gz). =
I ran &quot;make install-tools PYTHON_PREFIX_ARG=3D&quot; to install Xen.<b=
r>
<br>Notice: I couldn&#39;t run in xen_unstable or dom0 then I returned to i=
nstall environment (Debian Squeeze)<br><br>My attempt with modules and now =
with xenstored command (oxenstored command works) was in Debian Squeeze. In=
 this case I think I can&#39;t load these modules or run this command,  but=
 I&#39;m not sure. Then your questions can not be in this scope. What do yo=
u think?<br>
<br>Thanks, Eduardo<br><br><div class=3D"gmail_quote">Em 23 de abril de 201=
2 03:36, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@=
iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt;</span> escreveu:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wrote:<br=
>
&gt; =A0 =A0hi guys,<br>
&gt;<br>
<br>
Hello,<br>
<div class=3D"im"><br>
&gt; =A0 =A0It&#39;s my first time here and in a mailing lists, I only part=
icipated in<br>
&gt; =A0 =A0forums before. Please, If I make a mistake you should advise me=
. Let&#39;s go!<br>
&gt;<br>
&gt; =A0 =A0I was reading &quot;xencommons not start&quot; in a Remus Forum=
 in order to install<br>
&gt; =A0 =A0Remus.<br>
</div>&gt; =A0 =A0Well* I followed the tutorial<br>
&gt; =A0 =A0&lt;[1]<a href=3D"http://remusha.wikidot.com/configuring-and-in=
stalling-remus" target=3D"_blank">http://remusha.wikidot.com/configuring-an=
d-installing-remus</a>&gt;, I reboot<br>
<div class=3D"im">&gt; =A0 =A0in xen_unstable and I had a error message:<br=
>
&gt;<br>
&gt; =A0 =A0error: couldn&#39;t open file<br>
&gt; =A0 =A0error: you need to load the multiboot kernel first<br>
&gt;<br>
&gt; =A0 =A0then I redid tutorial after &quot;Adapt Grub&quot; and in a mom=
ent I do command:<br>
&gt;<br>
&gt; =A0 =A0# /etc/init.d/xend start<br>
&gt; =A0 =A0xencommons should be started first.<br>
&gt;<br>
&gt; =A0 =A0but I had done &quot;/etc/init.d/xencommons start&quot; before =
and no error message<br>
&gt; =A0 =A0returned !!!???<br>
&gt;<br>
&gt; =A0 =A0I also tried insert modules manually (coz in other mailing list=
 said to<br>
&gt; =A0 =A0put some modules - see my setups after this mail) but I had:<br=
>
&gt;<br>
&gt; =A0 =A0# modprobe xen-evtchn<br>
&gt; =A0 =A0FATAL: Module xen_evtchn not found.<br>
&gt;<br>
<br>
</div>So xen event channel support is not compiled as a module?<br>
is it enabled at all in your dom0 kernel config?<br>
<br>
<a href=3D"http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails=
.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xen_Common_Problems#Startin=
g_xend_fails.3F</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- Pasi<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--e89a8f83a03b73df4004be5aec38--


--===============4726630449669378702==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4726630449669378702==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 16:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLwv-0003Ti-KI; Mon, 23 Apr 2012 16:17:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SMLwt-0003Ta-R6
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:17:12 +0000
Received: from [85.158.143.99:34691] by server-3.bemta-4.messagelabs.com id
	3F/F7-05853-780859F4; Mon, 23 Apr 2012 16:17:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335197829!26335575!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5MDgw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30681 invoked from network); 23 Apr 2012 16:17:10 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 16:17:10 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 23 Apr 2012 09:17:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134250431"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 23 Apr 2012 09:17:06 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 09:17:05 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.5]) with mapi id
	14.01.0355.002; Tue, 24 Apr 2012 00:17:03 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Borislav Petkov <bp@amd64.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNIRekE+T8UaKT7UOvaY1icgqRWJaoiIsA
Date: Mon, 23 Apr 2012 16:17:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335168E54@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
In-Reply-To: <20120423060921.GA29378@aftab.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	Jan Beulich <jbeulich@suse.com>, "H. Peter
	Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> 
>> This driver is not that much different from the APEI bridge to MCE
>> code - 
>> it just that instead of reading APEI blob data it reads it from an
>> hypercall. 
> 
> Let me ask you this: is APEI a virtualization solution of some sort?
> 
> No, it is the old windoze RAS crap but I guess Linux has to support it
> now too through BIOS. And x86 vendors will have to support it too.
> 
> So it is piece of the firmware we'd have to deal with too.
> 
> Now xen is a whole another deal - it is purely a piece of software.

But the role of xen (in fact, including other virtual solution like lguest/kvm) is virtual 'platform', equal to native h/w 'platform'.

> 
> Now I keep wondering, why don't you guys simply create your own mcelog
> ring buffer and interface on the userspace tool side instead of
> hooking into lowlevel kernel stuff? I mean, the code is there, you
> simply have to copy it into arch/xen/ or whatever you have there. Why
> do you have to hook into arch/x86/ instead of doing your own stuff?
> 
>>> So, my suggestion is to copy the pieces you need and create your
>>> own xen version of /dev/mcelog and add it to dom0 so that there's
>>> no hooking into baremetal code and whenever a dom0 kernel is
>>> running, you can reroute the mcelog userspace tool to read
>>> /dev/xen_mcelog or whatever and not hook into the x86 versions.

That would make distro camp confusing -- i.e. SLES10/11 unifiedly use /dev/mcelog for both native and xen mcelog, w/ almost same dom0 mcelog logic as this patch.

>>> 
>>> Because, if you'd hooked into it, just imagine one fine day, when we
>>> remove mcelog support, what screaming the xen people will be doing
>>> when mcelog doesn't work anymore.
>> 
>> You would have more screaming from the distro camp about removing
>> /dev/mcelog.
> 
> How do you know that? Don't you think that we probably would've talked
> to them already and made preparations for conversion first?

I guess Novell Suse doubt this.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLwv-0003Ti-KI; Mon, 23 Apr 2012 16:17:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1SMLwt-0003Ta-R6
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:17:12 +0000
Received: from [85.158.143.99:34691] by server-3.bemta-4.messagelabs.com id
	3F/F7-05853-780859F4; Mon, 23 Apr 2012 16:17:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335197829!26335575!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5MDgw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30681 invoked from network); 23 Apr 2012 16:17:10 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	23 Apr 2012 16:17:10 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 23 Apr 2012 09:17:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134250431"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 23 Apr 2012 09:17:06 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 09:17:05 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.5]) with mapi id
	14.01.0355.002; Tue, 24 Apr 2012 00:17:03 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Borislav Petkov <bp@amd64.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNIRekE+T8UaKT7UOvaY1icgqRWJaoiIsA
Date: Mon, 23 Apr 2012 16:17:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335168E54@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
In-Reply-To: <20120423060921.GA29378@aftab.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	Jan Beulich <jbeulich@suse.com>, "H. Peter
	Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> 
>> This driver is not that much different from the APEI bridge to MCE
>> code - 
>> it just that instead of reading APEI blob data it reads it from an
>> hypercall. 
> 
> Let me ask you this: is APEI a virtualization solution of some sort?
> 
> No, it is the old windoze RAS crap but I guess Linux has to support it
> now too through BIOS. And x86 vendors will have to support it too.
> 
> So it is piece of the firmware we'd have to deal with too.
> 
> Now xen is a whole another deal - it is purely a piece of software.

But the role of xen (in fact, including other virtual solution like lguest/kvm) is virtual 'platform', equal to native h/w 'platform'.

> 
> Now I keep wondering, why don't you guys simply create your own mcelog
> ring buffer and interface on the userspace tool side instead of
> hooking into lowlevel kernel stuff? I mean, the code is there, you
> simply have to copy it into arch/xen/ or whatever you have there. Why
> do you have to hook into arch/x86/ instead of doing your own stuff?
> 
>>> So, my suggestion is to copy the pieces you need and create your
>>> own xen version of /dev/mcelog and add it to dom0 so that there's
>>> no hooking into baremetal code and whenever a dom0 kernel is
>>> running, you can reroute the mcelog userspace tool to read
>>> /dev/xen_mcelog or whatever and not hook into the x86 versions.

That would make distro camp confusing -- i.e. SLES10/11 unifiedly use /dev/mcelog for both native and xen mcelog, w/ almost same dom0 mcelog logic as this patch.

>>> 
>>> Because, if you'd hooked into it, just imagine one fine day, when we
>>> remove mcelog support, what screaming the xen people will be doing
>>> when mcelog doesn't work anymore.
>> 
>> You would have more screaming from the distro camp about removing
>> /dev/mcelog.
> 
> How do you know that? Don't you think that we probably would've talked
> to them already and made preparations for conversion first?

I guess Novell Suse doubt this.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLx3-0003UX-0K; Mon, 23 Apr 2012 16:17:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1SMLx1-0003U9-QC
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:17:20 +0000
Received: from [85.158.138.51:33483] by server-4.bemta-3.messagelabs.com id
	3F/2A-15341-D80859F4; Mon, 23 Apr 2012 16:17:17 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335197835!23440096!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxMDQwMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21750 invoked from network); 23 Apr 2012 16:17:16 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 16:17:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 23 Apr 2012 09:17:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="157154835"
Received: from orsmsx605.amr.corp.intel.com ([10.22.226.10])
	by fmsmga002.fm.intel.com with ESMTP; 23 Apr 2012 09:17:15 -0700
Received: from orsmsx101.amr.corp.intel.com (10.22.225.128) by
	orsmsx605.amr.corp.intel.com (10.22.226.10) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 09:17:14 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.88]) by
	ORSMSX101.amr.corp.intel.com ([169.254.8.159]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 09:17:14 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YMj31i2PR/lkqeiia+nqwVVJaljggAgAL9hUCAAHdtAP//ln5w
Date: Mon, 23 Apr 2012 16:17:14 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F170EF914@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<20120423153222.GE24481@phenom.dumpdata.com>
In-Reply-To: <20120423153222.GE24481@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This driver is _not_ doing a strict bit-by-bit copy of 'struct mcinfo'
> to 'struct mce'. It is plucking the right bits and setting them in
> 'struct mce'.

That isn't any worse that what we currently have ... but what we currently
have is ugly, and doing more ugly things just because we did them before
generally isn't a winning argument on the mailing lists.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLx3-0003UX-0K; Mon, 23 Apr 2012 16:17:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1SMLx1-0003U9-QC
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:17:20 +0000
Received: from [85.158.138.51:33483] by server-4.bemta-3.messagelabs.com id
	3F/2A-15341-D80859F4; Mon, 23 Apr 2012 16:17:17 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335197835!23440096!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxMDQwMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21750 invoked from network); 23 Apr 2012 16:17:16 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 16:17:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 23 Apr 2012 09:17:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="157154835"
Received: from orsmsx605.amr.corp.intel.com ([10.22.226.10])
	by fmsmga002.fm.intel.com with ESMTP; 23 Apr 2012 09:17:15 -0700
Received: from orsmsx101.amr.corp.intel.com (10.22.225.128) by
	orsmsx605.amr.corp.intel.com (10.22.226.10) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 09:17:14 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.88]) by
	ORSMSX101.amr.corp.intel.com ([169.254.8.159]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 09:17:14 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YMj31i2PR/lkqeiia+nqwVVJaljggAgAL9hUCAAHdtAP//ln5w
Date: Mon, 23 Apr 2012 16:17:14 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F170EF914@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<20120423153222.GE24481@phenom.dumpdata.com>
In-Reply-To: <20120423153222.GE24481@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This driver is _not_ doing a strict bit-by-bit copy of 'struct mcinfo'
> to 'struct mce'. It is plucking the right bits and setting them in
> 'struct mce'.

That isn't any worse that what we currently have ... but what we currently
have is ugly, and doing more ugly things just because we did them before
generally isn't a winning argument on the mailing lists.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:18:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLxb-0003a5-Do; Mon, 23 Apr 2012 16:17:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMLxa-0003Zq-HP
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:17:54 +0000
Received: from [193.109.254.147:10421] by server-6.bemta-14.messagelabs.com id
	B0/97-02047-1B0859F4; Mon, 23 Apr 2012 16:17:53 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335197870!5868955!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25344 invoked from network); 23 Apr 2012 16:17:52 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:17:52 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NGHXPh028845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 09:17:34 -0700
Message-ID: <4F958098.1050402@zytor.com>
Date: Mon, 23 Apr 2012 09:17:28 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Luck, Tony" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
X-Enigmail-Version: 1.4
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 08:27 AM, Luck, Tony wrote:
>> Because, if you'd hooked into it, just imagine one fine day, when we
>> remove mcelog support, what screaming the xen people will be doing when
>> mcelog doesn't work anymore.
> 
> Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
> fields could be added) ... and you don't want to have your hypervisor to
> have to know which version of Linux it is talking to.

This is a great example on the fundamental problem with Xen, or rather
the approach that Xen has taken of grabbing random kernel internals and
claiming them as APIs (or, in some cases even as ABIs.)  A lot of these
have had problems that are now very nearly unfixable, and that has
seriously stalled out the ability of evolve the Linux kernel in some
areas.  Note that the cost of this is borne by the development
community, not by the Xen maintainers.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:18:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMLxb-0003a5-Do; Mon, 23 Apr 2012 16:17:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMLxa-0003Zq-HP
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:17:54 +0000
Received: from [193.109.254.147:10421] by server-6.bemta-14.messagelabs.com id
	B0/97-02047-1B0859F4; Mon, 23 Apr 2012 16:17:53 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335197870!5868955!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25344 invoked from network); 23 Apr 2012 16:17:52 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:17:52 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NGHXPh028845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 09:17:34 -0700
Message-ID: <4F958098.1050402@zytor.com>
Date: Mon, 23 Apr 2012 09:17:28 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Luck, Tony" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
X-Enigmail-Version: 1.4
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 08:27 AM, Luck, Tony wrote:
>> Because, if you'd hooked into it, just imagine one fine day, when we
>> remove mcelog support, what screaming the xen people will be doing when
>> mcelog doesn't work anymore.
> 
> Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
> fields could be added) ... and you don't want to have your hypervisor to
> have to know which version of Linux it is talking to.

This is a great example on the fundamental problem with Xen, or rather
the approach that Xen has taken of grabbing random kernel internals and
claiming them as APIs (or, in some cases even as ABIs.)  A lot of these
have had problems that are now very nearly unfixable, and that has
seriously stalled out the ability of evolve the Linux kernel in some
areas.  Note that the cost of this is borne by the development
community, not by the Xen maintainers.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM3Y-0003zC-BH; Mon, 23 Apr 2012 16:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SMM3W-0003z2-Sc
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:24:03 +0000
Received: from [85.158.143.99:5003] by server-2.bemta-4.messagelabs.com id
	B3/76-17550-222859F4; Mon, 23 Apr 2012 16:24:02 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335198240!24845095!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzA2OTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14028 invoked from network); 23 Apr 2012 16:24:01 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:24:01 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 180BF11CB;
	Mon, 23 Apr 2012 19:24:00 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7653320059; Mon, 23 Apr 2012 19:23:59 +0300 (EEST)
Date: Mon, 23 Apr 2012 19:23:59 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
Message-ID: <20120423162359.GG2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>    Hi Pasi,
> =

>    thank you for reply.
> =

>    I'm using Debian Squeeze, and I'm compiling Xen from source (.tar.gz).=
 I
>    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
> =

>    Notice: I couldn't run in xen_unstable or dom0 then I returned to inst=
all
>    environment (Debian Squeeze)
> =

>    My attempt with modules and now with xenstored command (oxenstored com=
mand
>    works) was in Debian Squeeze. In this case I think I can't load these
>    modules or run this command, but I'm not sure. Then your questions can=
 not
>    be in this scope. What do you think?
> =


I was talking about dom0 Linux kernel, not about Xen.

-- Pasi


>    Thanks, Eduardo
> =

>    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> es=
creveu:
> =

>      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wr=
ote:
>      >    hi guys,
>      >
> =

>      Hello,
>      >    It's my first time here and in a mailing lists, I only particip=
ated
>      in
>      >    forums before. Please, If I make a mistake you should advise me.
>      Let's go!
>      >
>      >    I was reading "xencommons not start" in a Remus Forum in order =
to
>      install
>      >    Remus.
>      >    Well* I followed the tutorial
>      >
>       <[1][2]http://remusha.wikidot.com/configuring-and-installing-remus>=
, I
>      reboot
>      >    in xen_unstable and I had a error message:
>      >
>      >    error: couldn't open file
>      >    error: you need to load the multiboot kernel first
>      >
>      >    then I redid tutorial after "Adapt Grub" and in a moment I do
>      command:
>      >
>      >    # /etc/init.d/xend start
>      >    xencommons should be started first.
>      >
>      >    but I had done "/etc/init.d/xencommons start" before and no err=
or
>      message
>      >    returned !!!???
>      >
>      >    I also tried insert modules manually (coz in other mailing list
>      said to
>      >    put some modules - see my setups after this mail) but I had:
>      >
>      >    # modprobe xen-evtchn
>      >    FATAL: Module xen_evtchn not found.
>      >
> =

>      So xen event channel support is not compiled as a module?
>      is it enabled at all in your dom0 kernel config?
> =

>      [3]http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.=
3F
>      -- Pasi
> =

> References
> =

>    Visible links
>    1. mailto:pasik@iki.fi
>    2. http://remusha.wikidot.com/configuring-and-installing-remus
>    3. http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM3Y-0003zC-BH; Mon, 23 Apr 2012 16:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SMM3W-0003z2-Sc
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:24:03 +0000
Received: from [85.158.143.99:5003] by server-2.bemta-4.messagelabs.com id
	B3/76-17550-222859F4; Mon, 23 Apr 2012 16:24:02 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335198240!24845095!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzA2OTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14028 invoked from network); 23 Apr 2012 16:24:01 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:24:01 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 180BF11CB;
	Mon, 23 Apr 2012 19:24:00 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7653320059; Mon, 23 Apr 2012 19:23:59 +0300 (EEST)
Date: Mon, 23 Apr 2012 19:23:59 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
Message-ID: <20120423162359.GG2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>    Hi Pasi,
> =

>    thank you for reply.
> =

>    I'm using Debian Squeeze, and I'm compiling Xen from source (.tar.gz).=
 I
>    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
> =

>    Notice: I couldn't run in xen_unstable or dom0 then I returned to inst=
all
>    environment (Debian Squeeze)
> =

>    My attempt with modules and now with xenstored command (oxenstored com=
mand
>    works) was in Debian Squeeze. In this case I think I can't load these
>    modules or run this command, but I'm not sure. Then your questions can=
 not
>    be in this scope. What do you think?
> =


I was talking about dom0 Linux kernel, not about Xen.

-- Pasi


>    Thanks, Eduardo
> =

>    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> es=
creveu:
> =

>      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a wr=
ote:
>      >    hi guys,
>      >
> =

>      Hello,
>      >    It's my first time here and in a mailing lists, I only particip=
ated
>      in
>      >    forums before. Please, If I make a mistake you should advise me.
>      Let's go!
>      >
>      >    I was reading "xencommons not start" in a Remus Forum in order =
to
>      install
>      >    Remus.
>      >    Well* I followed the tutorial
>      >
>       <[1][2]http://remusha.wikidot.com/configuring-and-installing-remus>=
, I
>      reboot
>      >    in xen_unstable and I had a error message:
>      >
>      >    error: couldn't open file
>      >    error: you need to load the multiboot kernel first
>      >
>      >    then I redid tutorial after "Adapt Grub" and in a moment I do
>      command:
>      >
>      >    # /etc/init.d/xend start
>      >    xencommons should be started first.
>      >
>      >    but I had done "/etc/init.d/xencommons start" before and no err=
or
>      message
>      >    returned !!!???
>      >
>      >    I also tried insert modules manually (coz in other mailing list
>      said to
>      >    put some modules - see my setups after this mail) but I had:
>      >
>      >    # modprobe xen-evtchn
>      >    FATAL: Module xen_evtchn not found.
>      >
> =

>      So xen event channel support is not compiled as a module?
>      is it enabled at all in your dom0 kernel config?
> =

>      [3]http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.=
3F
>      -- Pasi
> =

> References
> =

>    Visible links
>    1. mailto:pasik@iki.fi
>    2. http://remusha.wikidot.com/configuring-and-installing-remus
>    3. http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM3Y-0003zJ-NA; Mon, 23 Apr 2012 16:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1SMM3X-0003z7-Rl
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:24:03 +0000
Received: from [85.158.143.35:32538] by server-3.bemta-4.messagelabs.com id
	B0/40-05853-322859F4; Mon, 23 Apr 2012 16:24:03 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335198241!13732331!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY4OTE1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13381 invoked from network); 23 Apr 2012 16:24:02 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Apr 2012 16:24:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 23 Apr 2012 09:24:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92150009"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 09:24:01 -0700
Received: from orsmsx106.amr.corp.intel.com (10.22.225.133) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 09:24:00 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.88]) by
	ORSMSX106.amr.corp.intel.com ([169.254.5.6]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 09:24:00 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@amd64.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YMj31i2PR/lkqeiia+nqwVVJaljggAgAKXIICAAECDgIAAljWAgAAOzoD//4+fQA==
Date: Mon, 23 Apr 2012 16:23:59 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F170EF92E@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
	<20120423150657.GA24481@phenom.dumpdata.com>
	<20120423155957.GA6147@aftab.osrc.amd.com>
In-Reply-To: <20120423155957.GA6147@aftab.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "H. Peter
	Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Perfect. Software is more elastic than hardware - so the Xen ABI
> for the MCE can be changed then to reflect the new format if required.

To developers working upstream in open source projects ... yes, software
does look like it is easy to change.  But in the long term software is
very difficult to change. Enterprise versions for Linux now come with
up to ten years of support ... and they are expected to be updated with
support for new hardware for much of their support lifetime. So what goes
into upstream now will be a support burden for somebody until around 2022.

So please look at the suggestions that Boris has provided, and think about
if there is a cleaner, more maintainable way to pass error data around.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM3Y-0003zJ-NA; Mon, 23 Apr 2012 16:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1SMM3X-0003z7-Rl
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:24:03 +0000
Received: from [85.158.143.35:32538] by server-3.bemta-4.messagelabs.com id
	B0/40-05853-322859F4; Mon, 23 Apr 2012 16:24:03 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335198241!13732331!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY4OTE1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13381 invoked from network); 23 Apr 2012 16:24:02 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Apr 2012 16:24:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 23 Apr 2012 09:24:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92150009"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Apr 2012 09:24:01 -0700
Received: from orsmsx106.amr.corp.intel.com (10.22.225.133) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 09:24:00 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.88]) by
	ORSMSX106.amr.corp.intel.com ([169.254.5.6]) with mapi id
	14.01.0355.002; Mon, 23 Apr 2012 09:24:00 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@amd64.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
Thread-Index: AQHNH3YMj31i2PR/lkqeiia+nqwVVJaljggAgAKXIICAAECDgIAAljWAgAAOzoD//4+fQA==
Date: Mon, 23 Apr 2012 16:23:59 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F170EF92E@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
	<20120423150657.GA24481@phenom.dumpdata.com>
	<20120423155957.GA6147@aftab.osrc.amd.com>
In-Reply-To: <20120423155957.GA6147@aftab.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "H. Peter
	Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Perfect. Software is more elastic than hardware - so the Xen ABI
> for the MCE can be changed then to reflect the new format if required.

To developers working upstream in open source projects ... yes, software
does look like it is easy to change.  But in the long term software is
very difficult to change. Enterprise versions for Linux now come with
up to ten years of support ... and they are expected to be updated with
support for new hardware for much of their support lifetime. So what goes
into upstream now will be a support burden for somebody until around 2022.

So please look at the suggestions that Boris has provided, and think about
if there is a cleaner, more maintainable way to pass error data around.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:25:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM4i-00049B-B4; Mon, 23 Apr 2012 16:25:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMM4h-00048w-4w
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:25:15 +0000
Received: from [193.109.254.147:22728] by server-5.bemta-14.messagelabs.com id
	0B/EC-30733-A62859F4; Mon, 23 Apr 2012 16:25:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335198311!238000!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzg3MjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 23 Apr 2012 16:25:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330923600"; d="scan'208";a="24436837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 12:25:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 12:25:11 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMM4c-0002i8-MN;
	Mon, 23 Apr 2012 17:25:10 +0100
Message-ID: <4F958265.9020107@citrix.com>
Date: Mon, 23 Apr 2012 17:25:09 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
	<4F955999.3030500@citrix.com>
	<1335189749.4347.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335189749.4347.27.camel@zakaz.uk.xensource.com>
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBNb24sIDIwMTItMDQtMjMgYXQgMTQ6MzEgKzAx
MDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gTWFyZWsgTWFyY3p5a293c2tpIGVzY3JpYmnD
szoKPj4+IE9uIDIwLjA0LjIwMTIgMTU6MjMsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+PiBU
aGlzIHNlcmllcyByZW1vdmVzIHRoZSB1c2Ugb2YgdWRldiBydWxlcyB0byBjYWxsIGhvdHBsdWcg
c2NyaXB0cyB3aGVuIHVzaW5nCj4+Pj4gbGlieGwuIFNjcmlwdHMgYXJlIGRpcmVjdGx5IGNhbGxl
ZCBmcm9tIHRoZSB0b29sc3RhY2sgYXQgdGhlIG5lY2Vzc2FyeSBwb2ludHMsCj4+Pj4gbWFraW5n
IHVzZSBvZiB0aGUgbmV3IGV2ZW50IGxpYnJhcnkgYW5kIGl0J3MgZm9yayBzdXBwb3J0Lgo+Pj4g
V2hhdCBhYm91dCBub24tZG9tMCBiYWNrZW5kcz8gVGhlcmUgd2lsbCBiZSBubyBzaW1wbGUgd2F5
IHRvIGV4ZWN1dGUgc2NyaXB0Cj4+PiB0aGVyZSBieSBsaWJ4bCB3aXRob3V0IGhlbHAgZnJvbSB1
ZGV2Li4uCj4+IEEgbmV3IGNvbmZpZyBvcHRpb24gaGFzIGJlZW4gYWRkZWQgb24gdGhpcyBzZXJp
ZXMKPj4gKGRpc2FibGVfeGxfdmlmX3NjcmlwdHMpIHRoYXQgYWxsb3dzIHRoZSB1c2VyIHRvIGtl
ZXAgZXhlY3V0aW5nIHZpZgo+PiBzY3JpcHRzIGZyb20gdWRldiwgc28gdGhpcyBmdW5jdGlvbmFs
aXR5IGlzIG5vdCBsb3N0Lgo+Cj4gSW4gdGhlIGxvbmcgdGVybSAoZS5nLiBmb3IgNC4zKSB3ZSBp
bnRlbmQgdG8gb3ZlcmhhdWwgdGhpcyBpbiBhIHdheQo+IHdoaWNoIG1ha2VzIGRyaXZlciBkb21h
aW5zIHdvcmsgd2l0aG91dCB1ZGV2IGF0IGFsbCwgc2VlICJEcml2ZXIgZG9tYWlucwo+IGNvbW11
bmljYXRpb24gcHJvdG9jb2wgcHJvcG9zYWwiIHBvc3RlZCBieSBJYW4gSmFja3NvbiBzZXZlcmFs
IHdlZWtzIGFnbwo+IC0tIGl0IHdvdWxkIGJlIGdvb2QgdG8gY29uZmlybSB0aGF0IHRoZSBzY2hl
bWUgcHJvcG9zZWQgdGhlcmUgd29ya3Mgd2VsbAo+IGZvciBRdWJlcy1PUyB0b28uCj4KPiBJbiB0
aGUgc2hvcnQgdGVybSAoaS5lLiA0LjIpIHdlIGZlbHQgaXQgd2FzIHRvbyBsYXRlIHRvIGJlIG1h
a2luZyB0aGVzZQo+IHNvcnRzIG9mIGNoYW5nZXMgKGUuZy4gaW1wbGVtZW50aW5nIHRoYXQgY29t
cGxldGUgcHJvdG9jb2wpIGFuZAo+IHRoZXJlZm9yZSB0aGUgY29tcHJvbWlzZSBpcyB0aGF0IHhs
IHdpbGwgZXhlY3V0ZSB0aGUgc2NyaXB0cyBvbmx5IGluIHRoZQo+IGNhc2UgdGhhdCBkb20wIGlz
IGFsc28gdGhlIGJhY2tlbmQgZG9tYWluIHdoaWxlIGZvciBkcml2ZXIgZG9tYWlucyB3ZQo+IHJl
dGFpbiB0aGUgcHJlLTQuMiBiZWhhdmlvdXIgb2YgZXhlY3V0aW5nIHRoZSBob3RwbHVnIHNjcmlw
dHMgdmlhIHVkZXYKPiBpbnNpZGUgdGhlIGRyaXZlciBkb21haW4uIFRoaXMgd2FzIG5lY2Vzc2Fy
eSBpbiBvcmRlciB0byBmaXggdGhpbmdzIHN1Y2gKPiBhcyB0ZWFyZG93biBvZiBkaXNrcyBvbiBO
ZXRCU0QgYW5kIHRlYXJkb3duIG9mIE5JQ3Mgb24gb3BlbnZzd2l0Y2gKPiAoY3VycmVudGx5IGJv
dGggYXJlIGJyb2tlbiBldmVuIHdpdGggYmFja2VuZCA9IGRvbTAgZHVlIHRvIHNob3J0IGNvbWlu
Z3MKPiBpbiB0aGUgcHJldmlvdXMgYXBwcm9hY2gpIHdoaWxlIG5vdCByZWdyZXNzaW5nIHRoZSBk
cml2ZXIgZG9tYWluIHVzZQo+IGNhc2UuCj4KPiBCeSBkZWZhdWx0IGRvIHdlIHdyaXRlIHRoZSB4
ZW5zdG9yZSBrZXkgdG8gc3VwcHJlc3MgdWRldiBydW5uaW5nIHRoZQo+IHNjcmlwdHMgcmVnYXJk
bGVzcyBvZiB3aGljaCBkb21haW4gdGhlIGJhY2tlbmQgaXMgaW4gb3Igb25seSBmb3IKPiBiYWNr
ZW5kPTA/CgpGb3IgdmJkIGRldmljZXMgd2Ugd3JpdGUgaXQgZXZlcnl0aW1lLCBmb3IgdmlmcyBk
ZXZpY2VzIHdlIHdyaXRlIGl0IGlmIApkaXNhYmxlX3hsX3ZpZl9zY3JpcHRzIGlzIG5vdCBzZXQu
Cgo+IE9yIGlzIGl0IG5lY2Vzc2FyeSB0byB1c2UgdGhlIG92ZXJyaWRlIGNvbmZpZyBvcHRpb24g
Zm9yCj4gZHJpdmVyIGRvbWFpbj8KClNvIHRoZSBuZXcgcHJvcG9zYWwgaXMgdG8gYWRkIGEgZGlz
YWJsZV94bF92YmRfc2NyaXB0cyBhbmQgdG8gZGV0ZWN0IGlmIAp0aGUgZGV2aWNlIGJhY2tlbmQg
aXMgZGlmZmVyZW50IHRoYW4gZG9tMCwgaWYgaXQgaXMgaW4gZmFjdCBkaWZmZXJlbnQgCnRoYW4g
ZG9tMCBkb24ndCBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsICh0aGlzIHdpbGwgb25s
eSB3b3JrIGZvciAKdmlmcywgYmVjYXVzZSB0aGVyZSdzIG5vIHN1cHBvcnQgZm9yIHNldHRpbmcg
dGhlIGRldmljZSBkb21haW4gZm9yIHZiZCAKZGV2aWNlcyB5ZXQpLgoKPiBJYW4uCj4KPj4+IElu
IFF1YmVzLU9TIHdlIGhlYXZpbHkgdXNlIG5ldHdvcmsgYmFja2VuZCBpbiBkb21VOiBkb20wIGhh
dmUgbm8gbmV0d29yayBhdAo+Pj4gYWxsLCBhbGwgTklDcyBhcmUgYXR0YWNoZWQgKGFzIFBDSSBk
ZXZpY2UpIHRvIHNvbWUgZG9tVSAtIGNhbGxlZCBOZXRWTSwgd2hlcmUKPj4+IG5ldHdvcmsgYmFj
a2VuZCByZXNpZGVzLgo+PiBUaGVyZSBzaG91bGQgYmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQsIHlv
dSB3aWxsIGp1c3QgbmVlZCB0byB1c2UgdGhlIG5ldwo+PiBvcHRpb24uCj4+Cj4+PiBBbHNvIHZi
ZCBiYWNrZW5kIGluIGRvbVUgaXMgdXNlZCAtIGVnIHRvIGJvb3QgSFZNIGZyb20gaXNvLCB3aGlj
aCBpcyBzdG9yZWQgaW4KPj4+IHNvbWUgZG9tVS4KPj4gSSBkaWRuJ3Qga25vdyB5b3Ugd2hlcmUg
YWJsZSB0byB1c2UgdmJkIGZyb20gZHJpdmVyIGRvbWFpbnMgd2l0aCB4bCwgaWYKPj4gc28gSSB3
aWxsIGhhdmUgdG8gYWRkIGEgc2ltaWxhciBvcHRpb24gZm9yIHZiZCBkZXZpY2VzCj4+IChkaXNh
YmxlX3hsX3ZiZF9zY3JpcHRzKS4KPj4KPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwo+PiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPgo+CgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:25:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM4i-00049B-B4; Mon, 23 Apr 2012 16:25:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMM4h-00048w-4w
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:25:15 +0000
Received: from [193.109.254.147:22728] by server-5.bemta-14.messagelabs.com id
	0B/EC-30733-A62859F4; Mon, 23 Apr 2012 16:25:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335198311!238000!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzg3MjQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 23 Apr 2012 16:25:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330923600"; d="scan'208";a="24436837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 12:25:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 12:25:11 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMM4c-0002i8-MN;
	Mon, 23 Apr 2012 17:25:10 +0100
Message-ID: <4F958265.9020107@citrix.com>
Date: Mon, 23 Apr 2012 17:25:09 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com>
	<4F955999.3030500@citrix.com>
	<1335189749.4347.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335189749.4347.27.camel@zakaz.uk.xensource.com>
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
	libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBNb24sIDIwMTItMDQtMjMgYXQgMTQ6MzEgKzAx
MDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gTWFyZWsgTWFyY3p5a293c2tpIGVzY3JpYmnD
szoKPj4+IE9uIDIwLjA0LjIwMTIgMTU6MjMsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+PiBU
aGlzIHNlcmllcyByZW1vdmVzIHRoZSB1c2Ugb2YgdWRldiBydWxlcyB0byBjYWxsIGhvdHBsdWcg
c2NyaXB0cyB3aGVuIHVzaW5nCj4+Pj4gbGlieGwuIFNjcmlwdHMgYXJlIGRpcmVjdGx5IGNhbGxl
ZCBmcm9tIHRoZSB0b29sc3RhY2sgYXQgdGhlIG5lY2Vzc2FyeSBwb2ludHMsCj4+Pj4gbWFraW5n
IHVzZSBvZiB0aGUgbmV3IGV2ZW50IGxpYnJhcnkgYW5kIGl0J3MgZm9yayBzdXBwb3J0Lgo+Pj4g
V2hhdCBhYm91dCBub24tZG9tMCBiYWNrZW5kcz8gVGhlcmUgd2lsbCBiZSBubyBzaW1wbGUgd2F5
IHRvIGV4ZWN1dGUgc2NyaXB0Cj4+PiB0aGVyZSBieSBsaWJ4bCB3aXRob3V0IGhlbHAgZnJvbSB1
ZGV2Li4uCj4+IEEgbmV3IGNvbmZpZyBvcHRpb24gaGFzIGJlZW4gYWRkZWQgb24gdGhpcyBzZXJp
ZXMKPj4gKGRpc2FibGVfeGxfdmlmX3NjcmlwdHMpIHRoYXQgYWxsb3dzIHRoZSB1c2VyIHRvIGtl
ZXAgZXhlY3V0aW5nIHZpZgo+PiBzY3JpcHRzIGZyb20gdWRldiwgc28gdGhpcyBmdW5jdGlvbmFs
aXR5IGlzIG5vdCBsb3N0Lgo+Cj4gSW4gdGhlIGxvbmcgdGVybSAoZS5nLiBmb3IgNC4zKSB3ZSBp
bnRlbmQgdG8gb3ZlcmhhdWwgdGhpcyBpbiBhIHdheQo+IHdoaWNoIG1ha2VzIGRyaXZlciBkb21h
aW5zIHdvcmsgd2l0aG91dCB1ZGV2IGF0IGFsbCwgc2VlICJEcml2ZXIgZG9tYWlucwo+IGNvbW11
bmljYXRpb24gcHJvdG9jb2wgcHJvcG9zYWwiIHBvc3RlZCBieSBJYW4gSmFja3NvbiBzZXZlcmFs
IHdlZWtzIGFnbwo+IC0tIGl0IHdvdWxkIGJlIGdvb2QgdG8gY29uZmlybSB0aGF0IHRoZSBzY2hl
bWUgcHJvcG9zZWQgdGhlcmUgd29ya3Mgd2VsbAo+IGZvciBRdWJlcy1PUyB0b28uCj4KPiBJbiB0
aGUgc2hvcnQgdGVybSAoaS5lLiA0LjIpIHdlIGZlbHQgaXQgd2FzIHRvbyBsYXRlIHRvIGJlIG1h
a2luZyB0aGVzZQo+IHNvcnRzIG9mIGNoYW5nZXMgKGUuZy4gaW1wbGVtZW50aW5nIHRoYXQgY29t
cGxldGUgcHJvdG9jb2wpIGFuZAo+IHRoZXJlZm9yZSB0aGUgY29tcHJvbWlzZSBpcyB0aGF0IHhs
IHdpbGwgZXhlY3V0ZSB0aGUgc2NyaXB0cyBvbmx5IGluIHRoZQo+IGNhc2UgdGhhdCBkb20wIGlz
IGFsc28gdGhlIGJhY2tlbmQgZG9tYWluIHdoaWxlIGZvciBkcml2ZXIgZG9tYWlucyB3ZQo+IHJl
dGFpbiB0aGUgcHJlLTQuMiBiZWhhdmlvdXIgb2YgZXhlY3V0aW5nIHRoZSBob3RwbHVnIHNjcmlw
dHMgdmlhIHVkZXYKPiBpbnNpZGUgdGhlIGRyaXZlciBkb21haW4uIFRoaXMgd2FzIG5lY2Vzc2Fy
eSBpbiBvcmRlciB0byBmaXggdGhpbmdzIHN1Y2gKPiBhcyB0ZWFyZG93biBvZiBkaXNrcyBvbiBO
ZXRCU0QgYW5kIHRlYXJkb3duIG9mIE5JQ3Mgb24gb3BlbnZzd2l0Y2gKPiAoY3VycmVudGx5IGJv
dGggYXJlIGJyb2tlbiBldmVuIHdpdGggYmFja2VuZCA9IGRvbTAgZHVlIHRvIHNob3J0IGNvbWlu
Z3MKPiBpbiB0aGUgcHJldmlvdXMgYXBwcm9hY2gpIHdoaWxlIG5vdCByZWdyZXNzaW5nIHRoZSBk
cml2ZXIgZG9tYWluIHVzZQo+IGNhc2UuCj4KPiBCeSBkZWZhdWx0IGRvIHdlIHdyaXRlIHRoZSB4
ZW5zdG9yZSBrZXkgdG8gc3VwcHJlc3MgdWRldiBydW5uaW5nIHRoZQo+IHNjcmlwdHMgcmVnYXJk
bGVzcyBvZiB3aGljaCBkb21haW4gdGhlIGJhY2tlbmQgaXMgaW4gb3Igb25seSBmb3IKPiBiYWNr
ZW5kPTA/CgpGb3IgdmJkIGRldmljZXMgd2Ugd3JpdGUgaXQgZXZlcnl0aW1lLCBmb3IgdmlmcyBk
ZXZpY2VzIHdlIHdyaXRlIGl0IGlmIApkaXNhYmxlX3hsX3ZpZl9zY3JpcHRzIGlzIG5vdCBzZXQu
Cgo+IE9yIGlzIGl0IG5lY2Vzc2FyeSB0byB1c2UgdGhlIG92ZXJyaWRlIGNvbmZpZyBvcHRpb24g
Zm9yCj4gZHJpdmVyIGRvbWFpbj8KClNvIHRoZSBuZXcgcHJvcG9zYWwgaXMgdG8gYWRkIGEgZGlz
YWJsZV94bF92YmRfc2NyaXB0cyBhbmQgdG8gZGV0ZWN0IGlmIAp0aGUgZGV2aWNlIGJhY2tlbmQg
aXMgZGlmZmVyZW50IHRoYW4gZG9tMCwgaWYgaXQgaXMgaW4gZmFjdCBkaWZmZXJlbnQgCnRoYW4g
ZG9tMCBkb24ndCBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsICh0aGlzIHdpbGwgb25s
eSB3b3JrIGZvciAKdmlmcywgYmVjYXVzZSB0aGVyZSdzIG5vIHN1cHBvcnQgZm9yIHNldHRpbmcg
dGhlIGRldmljZSBkb21haW4gZm9yIHZiZCAKZGV2aWNlcyB5ZXQpLgoKPiBJYW4uCj4KPj4+IElu
IFF1YmVzLU9TIHdlIGhlYXZpbHkgdXNlIG5ldHdvcmsgYmFja2VuZCBpbiBkb21VOiBkb20wIGhh
dmUgbm8gbmV0d29yayBhdAo+Pj4gYWxsLCBhbGwgTklDcyBhcmUgYXR0YWNoZWQgKGFzIFBDSSBk
ZXZpY2UpIHRvIHNvbWUgZG9tVSAtIGNhbGxlZCBOZXRWTSwgd2hlcmUKPj4+IG5ldHdvcmsgYmFj
a2VuZCByZXNpZGVzLgo+PiBUaGVyZSBzaG91bGQgYmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQsIHlv
dSB3aWxsIGp1c3QgbmVlZCB0byB1c2UgdGhlIG5ldwo+PiBvcHRpb24uCj4+Cj4+PiBBbHNvIHZi
ZCBiYWNrZW5kIGluIGRvbVUgaXMgdXNlZCAtIGVnIHRvIGJvb3QgSFZNIGZyb20gaXNvLCB3aGlj
aCBpcyBzdG9yZWQgaW4KPj4+IHNvbWUgZG9tVS4KPj4gSSBkaWRuJ3Qga25vdyB5b3Ugd2hlcmUg
YWJsZSB0byB1c2UgdmJkIGZyb20gZHJpdmVyIGRvbWFpbnMgd2l0aCB4bCwgaWYKPj4gc28gSSB3
aWxsIGhhdmUgdG8gYWRkIGEgc2ltaWxhciBvcHRpb24gZm9yIHZiZCBkZXZpY2VzCj4+IChkaXNh
YmxlX3hsX3ZiZF9zY3JpcHRzKS4KPj4KPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwo+PiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPgo+CgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:27:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM6R-0004Ja-Ss; Mon, 23 Apr 2012 16:27:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMM6Q-0004JS-Vo
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:27:03 +0000
Received: from [85.158.139.83:31341] by server-9.bemta-5.messagelabs.com id
	99/42-09826-6D2859F4; Mon, 23 Apr 2012 16:27:02 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335198419!24584579!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4361 invoked from network); 23 Apr 2012 16:27:00 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 16:27:00 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NGQlZ0031538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 09:26:48 -0700
Message-ID: <4F9582C2.6020009@zytor.com>
Date: Mon, 23 Apr 2012 09:26:42 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "Luck, Tony" <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 08:43 AM, Liu, Jinsong wrote:
> 
> and, hypervisor only record error into its mc_info cookie (in its
> own format), it doesn't care what's dom0's version and how dom0 translate it
> -- that's dom0's business. The role of hypervisor is virtual 'platform',
> just like h/w platform don't care what linux version runs over it.
> 

And this is the *OTHER* problem with Xen.  A platform is only a platform
if it is documented.  There are a number of PV hypervisors which *are*
documented in detail, but Xen is not one of them.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:27:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMM6R-0004Ja-Ss; Mon, 23 Apr 2012 16:27:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMM6Q-0004JS-Vo
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:27:03 +0000
Received: from [85.158.139.83:31341] by server-9.bemta-5.messagelabs.com id
	99/42-09826-6D2859F4; Mon, 23 Apr 2012 16:27:02 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335198419!24584579!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4361 invoked from network); 23 Apr 2012 16:27:00 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 16:27:00 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NGQlZ0031538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 09:26:48 -0700
Message-ID: <4F9582C2.6020009@zytor.com>
Date: Mon, 23 Apr 2012 09:26:42 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "Luck, Tony" <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 08:43 AM, Liu, Jinsong wrote:
> 
> and, hypervisor only record error into its mc_info cookie (in its
> own format), it doesn't care what's dom0's version and how dom0 translate it
> -- that's dom0's business. The role of hypervisor is virtual 'platform',
> just like h/w platform don't care what linux version runs over it.
> 

And this is the *OTHER* problem with Xen.  A platform is only a platform
if it is documented.  There are a number of PV hypervisors which *are*
documented in detail, but Xen is not one of them.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:45:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMOQ-0004kG-LA; Mon, 23 Apr 2012 16:45:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SMMOP-0004k1-CX
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:45:37 +0000
Received: from [85.158.143.99:38998] by server-1.bemta-4.messagelabs.com id
	0B/E0-20925-037859F4; Mon, 23 Apr 2012 16:45:36 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335199532!24848140!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16353 invoked from network); 23 Apr 2012 16:45:34 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:45:34 -0000
Received: by yhoo21 with SMTP id o21so7499018yho.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 09:45:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=3lLkJI+k3b2dfvrs5R0SFZLWD/lr09fea4zlg4olUXI=;
	b=gwktx3RogWPCvq6eJzUlx1ARTD+2gs9ZyhpS451smPjLGdB46BR54RVPhuu/0MS1EX
	99lHzqsKmcdShUqFgyLaDIb+nrGohY7WtNjDN5FWAt5gUPKZxuvnI2WQB1BaGR2//6rr
	QAHGA3hDnV7sOJhU9yCygNV/jOefwnVM9ZqlfAman4X71U9eLOWxmLvwsewb3RQkaG6g
	hPO5OELoL7EWsk198otFVNU6+Fk7SIfIbIYjHzIZFJOCDBoTK2hiX550nrwweHW5tWBb
	6wTbIBZAajpAtJGn7Cu6TRAAbL4PL3Ilz826MkeRellIUGayW6SbeseEEKSlW+8kUPV6
	DJwQ==
MIME-Version: 1.0
Received: by 10.60.12.162 with SMTP id z2mr15826444oeb.47.1335199531691; Mon,
	23 Apr 2012 09:45:31 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Mon, 23 Apr 2012 09:45:31 -0700 (PDT)
In-Reply-To: <20120423162359.GG2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
	<20120423162359.GG2058@reaktio.net>
Date: Mon, 23 Apr 2012 13:45:31 -0300
Message-ID: <CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4892842479460830476=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4892842479460830476==
Content-Type: multipart/alternative; boundary=e89a8f83a03bca6d6604be5b5d74

--e89a8f83a03bca6d6604be5b5d74
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi

I didn't think this. I'll be in my job tomorrow an I'll reply there.

Thank you

Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <pasik@iki.fi> escreveu:

> On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
> >    Hi Pasi,
> >
> >    thank you for reply.
> >
> >    I'm using Debian Squeeze, and I'm compiling Xen from source
> (.tar.gz). I
> >    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
> >
> >    Notice: I couldn't run in xen_unstable or dom0 then I returned to
> install
> >    environment (Debian Squeeze)
> >
> >    My attempt with modules and now with xenstored command (oxenstored
> command
> >    works) was in Debian Squeeze. In this case I think I can't load thes=
e
> >    modules or run this command, but I'm not sure. Then your questions
> can not
> >    be in this scope. What do you think?
> >
>
> I was talking about dom0 Linux kernel, not about Xen.
>
> -- Pasi
>
>
> >    Thanks, Eduardo
> >
> >    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
> escreveu:
> >
> >      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a =
wrote:
> >      >    hi guys,
> >      >
> >
> >      Hello,
> >      >    It's my first time here and in a mailing lists, I only
> participated
> >      in
> >      >    forums before. Please, If I make a mistake you should advise
> me.
> >      Let's go!
> >      >
> >      >    I was reading "xencommons not start" in a Remus Forum in orde=
r
> to
> >      install
> >      >    Remus.
> >      >    Well* I followed the tutorial
> >      >
> >       <[1][2]http://remusha.wikidot.com/configuring-and-installing-remu=
s>,
> I
> >      reboot
> >      >    in xen_unstable and I had a error message:
> >      >
> >      >    error: couldn't open file
> >      >    error: you need to load the multiboot kernel first
> >      >
> >      >    then I redid tutorial after "Adapt Grub" and in a moment I do
> >      command:
> >      >
> >      >    # /etc/init.d/xend start
> >      >    xencommons should be started first.
> >      >
> >      >    but I had done "/etc/init.d/xencommons start" before and no
> error
> >      message
> >      >    returned !!!???
> >      >
> >      >    I also tried insert modules manually (coz in other mailing li=
st
> >      said to
> >      >    put some modules - see my setups after this mail) but I had:
> >      >
> >      >    # modprobe xen-evtchn
> >      >    FATAL: Module xen_evtchn not found.
> >      >
> >
> >      So xen event channel support is not compiled as a module?
> >      is it enabled at all in your dom0 kernel config?
> >
> >      [3]
> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
> >      -- Pasi
> >
> > References
> >
> >    Visible links
> >    1. mailto:pasik@iki.fi
> >    2. http://remusha.wikidot.com/configuring-and-installing-remus
> >    3.
> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>

--e89a8f83a03bca6d6604be5b5d74
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Pasi<br><br>I didn&#39;t think this. I&#39;ll be=
 in my job tomorrow an I&#39;ll reply there.<br><br>Thank you<br><br><div c=
lass=3D"gmail_quote">Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@i=
ki.fi</a>&gt;</span> escreveu:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, Apr 23, 2012 at 01=
:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:<br>
&gt; =A0 =A0Hi Pasi,<br>
&gt;<br>
&gt; =A0 =A0thank you for reply.<br>
&gt;<br>
&gt; =A0 =A0I&#39;m using Debian Squeeze, and I&#39;m compiling Xen from so=
urce (.tar.gz). I<br>
&gt; =A0 =A0ran &quot;make install-tools PYTHON_PREFIX_ARG=3D&quot; to inst=
all Xen.<br>
&gt;<br>
&gt; =A0 =A0Notice: I couldn&#39;t run in xen_unstable or dom0 then I retur=
ned to install<br>
&gt; =A0 =A0environment (Debian Squeeze)<br>
&gt;<br>
&gt; =A0 =A0My attempt with modules and now with xenstored command (oxensto=
red command<br>
&gt; =A0 =A0works) was in Debian Squeeze. In this case I think I can&#39;t =
load these<br>
&gt; =A0 =A0modules or run this command, but I&#39;m not sure. Then your qu=
estions can not<br>
&gt; =A0 =A0be in this scope. What do you think?<br>
&gt;<br>
<br>
</div>I was talking about dom0 Linux kernel, not about Xen.<br>
<br>
-- Pasi<br>
<br>
<br>
&gt; =A0 =A0Thanks, Eduardo<br>
&gt;<br>
&gt; =A0 =A0Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen &lt;[1]<a hre=
f=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; escreveu:<br>
<div class=3D"im">&gt;<br>
&gt; =A0 =A0 =A0On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fr=
an=E7a wrote:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0hi guys,<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0Hello,<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0It&#39;s my first time here and in a mailing li=
sts, I only participated<br>
&gt; =A0 =A0 =A0in<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0forums before. Please, If I make a mistake you =
should advise me.<br>
&gt; =A0 =A0 =A0Let&#39;s go!<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I was reading &quot;xencommons not start&quot; =
in a Remus Forum in order to<br>
&gt; =A0 =A0 =A0install<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Remus.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Well* I followed the tutorial<br>
&gt; =A0 =A0 =A0&gt;<br>
</div>&gt; =A0 =A0 =A0 &lt;[1][2]<a href=3D"http://remusha.wikidot.com/conf=
iguring-and-installing-remus" target=3D"_blank">http://remusha.wikidot.com/=
configuring-and-installing-remus</a>&gt;, I<br>
<div class=3D"im">&gt; =A0 =A0 =A0reboot<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0in xen_unstable and I had a error message:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: couldn&#39;t open file<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: you need to load the multiboot kernel fi=
rst<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0then I redid tutorial after &quot;Adapt Grub&qu=
ot; and in a moment I do<br>
&gt; =A0 =A0 =A0command:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# /etc/init.d/xend start<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0xencommons should be started first.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0but I had done &quot;/etc/init.d/xencommons sta=
rt&quot; before and no error<br>
&gt; =A0 =A0 =A0message<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0returned !!!???<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I also tried insert modules manually (coz in ot=
her mailing list<br>
&gt; =A0 =A0 =A0said to<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0put some modules - see my setups after this mai=
l) but I had:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# modprobe xen-evtchn<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0FATAL: Module xen_evtchn not found.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0So xen event channel support is not compiled as a module?<b=
r>
&gt; =A0 =A0 =A0is it enabled at all in your dom0 kernel config?<br>
&gt;<br>
</div>&gt; =A0 =A0 =A0[3]<a href=3D"http://wiki.xen.org/wiki/Xen_Common_Pro=
blems#Starting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xe=
n_Common_Problems#Starting_xend_fails.3F</a><br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
&gt; =A0 =A02. <a href=3D"http://remusha.wikidot.com/configuring-and-instal=
ling-remus" target=3D"_blank">http://remusha.wikidot.com/configuring-and-in=
stalling-remus</a><br>
&gt; =A0 =A03. <a href=3D"http://wiki.xen.org/wiki/Xen_Common_Problems#Star=
ting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xen_Common_P=
roblems#Starting_xend_fails.3F</a><br>
</blockquote></div><br></div>

--e89a8f83a03bca6d6604be5b5d74--


--===============4892842479460830476==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4892842479460830476==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 16:45:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMOQ-0004kG-LA; Mon, 23 Apr 2012 16:45:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SMMOP-0004k1-CX
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:45:37 +0000
Received: from [85.158.143.99:38998] by server-1.bemta-4.messagelabs.com id
	0B/E0-20925-037859F4; Mon, 23 Apr 2012 16:45:36 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335199532!24848140!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16353 invoked from network); 23 Apr 2012 16:45:34 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:45:34 -0000
Received: by yhoo21 with SMTP id o21so7499018yho.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 09:45:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=3lLkJI+k3b2dfvrs5R0SFZLWD/lr09fea4zlg4olUXI=;
	b=gwktx3RogWPCvq6eJzUlx1ARTD+2gs9ZyhpS451smPjLGdB46BR54RVPhuu/0MS1EX
	99lHzqsKmcdShUqFgyLaDIb+nrGohY7WtNjDN5FWAt5gUPKZxuvnI2WQB1BaGR2//6rr
	QAHGA3hDnV7sOJhU9yCygNV/jOefwnVM9ZqlfAman4X71U9eLOWxmLvwsewb3RQkaG6g
	hPO5OELoL7EWsk198otFVNU6+Fk7SIfIbIYjHzIZFJOCDBoTK2hiX550nrwweHW5tWBb
	6wTbIBZAajpAtJGn7Cu6TRAAbL4PL3Ilz826MkeRellIUGayW6SbeseEEKSlW+8kUPV6
	DJwQ==
MIME-Version: 1.0
Received: by 10.60.12.162 with SMTP id z2mr15826444oeb.47.1335199531691; Mon,
	23 Apr 2012 09:45:31 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Mon, 23 Apr 2012 09:45:31 -0700 (PDT)
In-Reply-To: <20120423162359.GG2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
	<20120423162359.GG2058@reaktio.net>
Date: Mon, 23 Apr 2012 13:45:31 -0300
Message-ID: <CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4892842479460830476=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4892842479460830476==
Content-Type: multipart/alternative; boundary=e89a8f83a03bca6d6604be5b5d74

--e89a8f83a03bca6d6604be5b5d74
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi

I didn't think this. I'll be in my job tomorrow an I'll reply there.

Thank you

Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <pasik@iki.fi> escreveu:

> On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
> >    Hi Pasi,
> >
> >    thank you for reply.
> >
> >    I'm using Debian Squeeze, and I'm compiling Xen from source
> (.tar.gz). I
> >    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
> >
> >    Notice: I couldn't run in xen_unstable or dom0 then I returned to
> install
> >    environment (Debian Squeeze)
> >
> >    My attempt with modules and now with xenstored command (oxenstored
> command
> >    works) was in Debian Squeeze. In this case I think I can't load thes=
e
> >    modules or run this command, but I'm not sure. Then your questions
> can not
> >    be in this scope. What do you think?
> >
>
> I was talking about dom0 Linux kernel, not about Xen.
>
> -- Pasi
>
>
> >    Thanks, Eduardo
> >
> >    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
> escreveu:
> >
> >      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a =
wrote:
> >      >    hi guys,
> >      >
> >
> >      Hello,
> >      >    It's my first time here and in a mailing lists, I only
> participated
> >      in
> >      >    forums before. Please, If I make a mistake you should advise
> me.
> >      Let's go!
> >      >
> >      >    I was reading "xencommons not start" in a Remus Forum in orde=
r
> to
> >      install
> >      >    Remus.
> >      >    Well* I followed the tutorial
> >      >
> >       <[1][2]http://remusha.wikidot.com/configuring-and-installing-remu=
s>,
> I
> >      reboot
> >      >    in xen_unstable and I had a error message:
> >      >
> >      >    error: couldn't open file
> >      >    error: you need to load the multiboot kernel first
> >      >
> >      >    then I redid tutorial after "Adapt Grub" and in a moment I do
> >      command:
> >      >
> >      >    # /etc/init.d/xend start
> >      >    xencommons should be started first.
> >      >
> >      >    but I had done "/etc/init.d/xencommons start" before and no
> error
> >      message
> >      >    returned !!!???
> >      >
> >      >    I also tried insert modules manually (coz in other mailing li=
st
> >      said to
> >      >    put some modules - see my setups after this mail) but I had:
> >      >
> >      >    # modprobe xen-evtchn
> >      >    FATAL: Module xen_evtchn not found.
> >      >
> >
> >      So xen event channel support is not compiled as a module?
> >      is it enabled at all in your dom0 kernel config?
> >
> >      [3]
> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
> >      -- Pasi
> >
> > References
> >
> >    Visible links
> >    1. mailto:pasik@iki.fi
> >    2. http://remusha.wikidot.com/configuring-and-installing-remus
> >    3.
> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>

--e89a8f83a03bca6d6604be5b5d74
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Pasi<br><br>I didn&#39;t think this. I&#39;ll be=
 in my job tomorrow an I&#39;ll reply there.<br><br>Thank you<br><br><div c=
lass=3D"gmail_quote">Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@i=
ki.fi</a>&gt;</span> escreveu:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, Apr 23, 2012 at 01=
:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:<br>
&gt; =A0 =A0Hi Pasi,<br>
&gt;<br>
&gt; =A0 =A0thank you for reply.<br>
&gt;<br>
&gt; =A0 =A0I&#39;m using Debian Squeeze, and I&#39;m compiling Xen from so=
urce (.tar.gz). I<br>
&gt; =A0 =A0ran &quot;make install-tools PYTHON_PREFIX_ARG=3D&quot; to inst=
all Xen.<br>
&gt;<br>
&gt; =A0 =A0Notice: I couldn&#39;t run in xen_unstable or dom0 then I retur=
ned to install<br>
&gt; =A0 =A0environment (Debian Squeeze)<br>
&gt;<br>
&gt; =A0 =A0My attempt with modules and now with xenstored command (oxensto=
red command<br>
&gt; =A0 =A0works) was in Debian Squeeze. In this case I think I can&#39;t =
load these<br>
&gt; =A0 =A0modules or run this command, but I&#39;m not sure. Then your qu=
estions can not<br>
&gt; =A0 =A0be in this scope. What do you think?<br>
&gt;<br>
<br>
</div>I was talking about dom0 Linux kernel, not about Xen.<br>
<br>
-- Pasi<br>
<br>
<br>
&gt; =A0 =A0Thanks, Eduardo<br>
&gt;<br>
&gt; =A0 =A0Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen &lt;[1]<a hre=
f=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; escreveu:<br>
<div class=3D"im">&gt;<br>
&gt; =A0 =A0 =A0On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fr=
an=E7a wrote:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0hi guys,<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0Hello,<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0It&#39;s my first time here and in a mailing li=
sts, I only participated<br>
&gt; =A0 =A0 =A0in<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0forums before. Please, If I make a mistake you =
should advise me.<br>
&gt; =A0 =A0 =A0Let&#39;s go!<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I was reading &quot;xencommons not start&quot; =
in a Remus Forum in order to<br>
&gt; =A0 =A0 =A0install<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Remus.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Well* I followed the tutorial<br>
&gt; =A0 =A0 =A0&gt;<br>
</div>&gt; =A0 =A0 =A0 &lt;[1][2]<a href=3D"http://remusha.wikidot.com/conf=
iguring-and-installing-remus" target=3D"_blank">http://remusha.wikidot.com/=
configuring-and-installing-remus</a>&gt;, I<br>
<div class=3D"im">&gt; =A0 =A0 =A0reboot<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0in xen_unstable and I had a error message:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: couldn&#39;t open file<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: you need to load the multiboot kernel fi=
rst<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0then I redid tutorial after &quot;Adapt Grub&qu=
ot; and in a moment I do<br>
&gt; =A0 =A0 =A0command:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# /etc/init.d/xend start<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0xencommons should be started first.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0but I had done &quot;/etc/init.d/xencommons sta=
rt&quot; before and no error<br>
&gt; =A0 =A0 =A0message<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0returned !!!???<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I also tried insert modules manually (coz in ot=
her mailing list<br>
&gt; =A0 =A0 =A0said to<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0put some modules - see my setups after this mai=
l) but I had:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# modprobe xen-evtchn<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0FATAL: Module xen_evtchn not found.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0So xen event channel support is not compiled as a module?<b=
r>
&gt; =A0 =A0 =A0is it enabled at all in your dom0 kernel config?<br>
&gt;<br>
</div>&gt; =A0 =A0 =A0[3]<a href=3D"http://wiki.xen.org/wiki/Xen_Common_Pro=
blems#Starting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xe=
n_Common_Problems#Starting_xend_fails.3F</a><br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
&gt; =A0 =A02. <a href=3D"http://remusha.wikidot.com/configuring-and-instal=
ling-remus" target=3D"_blank">http://remusha.wikidot.com/configuring-and-in=
stalling-remus</a><br>
&gt; =A0 =A03. <a href=3D"http://wiki.xen.org/wiki/Xen_Common_Problems#Star=
ting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xen_Common_P=
roblems#Starting_xend_fails.3F</a><br>
</blockquote></div><br></div>

--e89a8f83a03bca6d6604be5b5d74--


--===============4892842479460830476==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4892842479460830476==--


From xen-devel-bounces@lists.xen.org Mon Apr 23 16:49:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMRT-0004rD-8c; Mon, 23 Apr 2012 16:48:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMRR-0004r4-It
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:48:46 +0000
Received: from [85.158.143.99:63243] by server-2.bemta-4.messagelabs.com id
	EF/B1-17550-CE7859F4; Mon, 23 Apr 2012 16:48:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335199722!23993268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6613 invoked from network); 23 Apr 2012 16:48:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:48:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:48:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:48:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMQx-0003lY-PJ; Mon, 23 Apr 2012 16:48:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMQx-00061N-OL;
	Mon, 23 Apr 2012 17:48:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.34767.584624.953798@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:48:15 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-4-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
	libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for this mammoth patch.  My comments are below.

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd"):
> This is a rather big change, that adds the necessary machinery to perform
> hotplug script calling from libxl for Linux. This patch launches the necessary
> scripts to attach and detach PHY and TAP backend types (Qemu doesn't
> use hotplug scripts).
> 
> Here's a list of the major changes introduced:

Can you please wrap your commit messages to no more than 75
characters ?  Some vcs's indent them.  And of course they get indented
when we reply leading to wrap damage.

>  * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
>    calls libxl__initiate_device_remove, so we can disconnect the device and
>    execute the necessary hotplug scripts instead of just deleting the backend
>    entries. So libxl__devices_destroy now uses the event library, and so does
>    libxl_domain_destroy.

So we no longer have any function which will synchronously and
immediately destroy a domain and throw away everything to do with it.
Is it actually the case that you think such a function cannot be
provided ?

>  * Added a check in xen-hotplug-common.sh, so scripts are only executed from
>    udev when using xend. xl adds a disable_udev=y to xenstore private directory
>    and with the modification of the udev rules every call from udev gets
>    HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is passed
>    and points to a value, the hotplug script is not executed.

WDYM "points to a value"?  Did you just mean "is set to a nonempty
value" ?  I'm not convinced by the name of this variable.  Shouldn't
it have Xen in the name, and specify its own sense ?  Eg,
XEN_HOTPLUG_DISABLE or something ?

> +SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
...
> +# Hack to prevent the execution of hotplug scripts from udev if the domain
> +# has been launched from libxl
> +if [ -n "${HOTPLUG_GATE}" ] && \
> +   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
> +    exit 0
> +fi

Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
like the idea of being able to pass some random other xenstore path.

Also: this xenstore path should be a relative path, ie one relative to
the xenstore home of domain running this part of the tools.  That way
the scripts can be easily and automatically disabled for dom0 and
enabled in driver domains.

> +    /* compatibility addon to keep udev rules */
> +    flexarray_append(private, "disable_udev");
> +    flexarray_append(private, "y");

We would normally use "1" for true in xenstore.

>      libxl__device_generic_add(gc, &device,
> -                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> +                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
> +                    libxl__xs_kvs_of_flexarray(gc, private, private->count));
> +
> +    switch(disk->backend) {
> +    case LIBXL_DISK_BACKEND_PHY:
> +    case LIBXL_DISK_BACKEND_TAP:
> +        rc = libxl__initiate_device_add(egc, ao, &device);
> +        if (rc) goto out_free;
> +        break;
> +    case LIBXL_DISK_BACKEND_QDISK:
> +    default:
> +        libxl__ao_complete(egc, ao, 0);
> +        break;
> +    }

Does this really need no confirmation from qemu ?

>  out_free:
> +    flexarray_free(private);
> +out_free_b:
>      flexarray_free(back);
> +out_free_f:
>      flexarray_free(front);

It would be much better to allocate these from the gc somehow.
Failing that, perhaps we could initialise them to NULL and free
them iff necessary on the exit path:

  out:
      ...
      if (back)  flexarray_free(back);
      if (front) flexarray_free(front);
etc.

>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
> @@ -1442,7 +1484,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>      if (rc != 0) goto out;
>  
>      rc = libxl__initiate_device_remove(egc, ao, &device);
> -    if (rc) goto out;
> +    switch(rc) {
> +    case 1:
> +        /* event added */

I think this terminology "event added" is confusingly wrong.  What you
mean is "event queued", I think.  You should change this everywhere.
But before you do that, please see what I write below about your
approach to libxl__initiate_device_remove.

> @@ -1666,11 +1719,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>      ret = 0;
>  
>      libxl_device_disk_remove(ctx, domid, disks + i, 0);
> -    libxl_device_disk_add(ctx, domid, disk);
> +    libxl_device_disk_add(ctx, domid, disk, 0);

This needs a /* fixme-ao */ because inside-libxl callers are not
allowed to invent an ao_how*, even NULL.  You need to mark every
occurrence of these that way.

> @@ -1884,8 +1937,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>      flexarray_append(front, libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
>      libxl__device_generic_add(gc, &device,
> -                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> +                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
> +                            NULL);

Likewise.  Also unintentional indentation change ?  (In several more
places, too.)

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 3675afe..de598ad 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>      store_libxl_entry(gc, domid, &d_config->b_info);
>  
>      for (i = 0; i < d_config->num_disks; i++) {
> -        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
> +        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);

Here in xl simply passing 0 is correct.

> +char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
> +{
> +    return libxl__sprintf(gc, "/libxl/backend/%s/%u/%d",
> +                          libxl__device_kind_to_string(device->backend_kind),
> +                          device->domid, device->devid);
> +}

Did you want to use GCSPRINTF ?

> +    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);

This is not correct.  You need to do something more with the exit
status of the hotplug script than simply throwing it away as you do in
hotplug_exited.  libxl__device_hotplug needs to take a callback from
the caller so that it can notify the caller when the hotplug script
has exited.

You need to not allow the ao to complete until the hotplug script has
exited.  Otherwise you will enter hotplug_exited after the
libxl__hotplug_state has been destroyed with the ao.

If it's too slow and you need to time out, you need to send the
hotplug script a signal, and then wait for it to exit.  If necessary
that signal could be SIGKILL; SIGKILL can be relied on to cause the
hotplug script to actually terminate and thus the hotplug_exited
callback to occur.

> +/*
> + * Return codes:
> + * 1 Success and event(s) HAVE BEEN added
> + * 0 Success and NO events were added
> + * < 0 Error
> + *
> + * Since this function can be called several times, and several events
> + * can be added to the same context, the user has to call
> + * libxl__ao_complete when necessary (if no events are added).
> + */
>  int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>                                    libxl__device *dev)

This comment should be in the header file near the declaration.
And indeed if you had put it there you would have discovered another
comment already there describing the old behaviour, which you have now
left behind as an erroneous comment.

And I think the new interface is entirely wrong.  How does the caller
know when to complete the ao if libxl__initiate_device_remove never
calls back ?

You need to split this into two functions: one with the current
interface which is a simple wrapper, used for all the existing call
sites, and one which never completes any ao but which always makes a
callback when the operation is complete.  That callback should be used
by the caller of libxl__initiate_device_remove to do whatever it needs
to, which might include completing the ao.

At the moment, AFAICT from reading your code, the caller's ao will be
completed by the first nontrivial device remove to complete, ie a bug.

> -int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
> +int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
> +                               libxl__device *dev)
...
> +    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
> +                                 state_path, XenbusStateInitWait,
> +                                 LIBXL_INIT_TIMEOUT * 1000);
> +    if (rc) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
> +                                          PRIu32, dev->devid);
> +        libxl__ev_devstate_cancel(gc, &aorm->ds);

This cancel is not necessary, because device_add_cleanup will do
this.  (Or at least it should do; I haven't checked.)

> +        goto out_fail;
> +    }
> +
> +    return 0;
> +
> +out_fail:
> +    assert(rc);
> +    device_add_cleanup(gc, aorm);
> +    return rc;
> +out_ok:

^ blank line needed after the return.

> +    rc = libxl__device_hotplug(gc, dev, CONNECT);
> +    libxl__ao_complete(egc, ao, 0);
> +    return rc;
> +}

Some of my comments about initiate_device_remove's callback probably
apply here too.  In particular, I have found it is often better to
make a callback-queueing function always call the callback right away,
recursively, on the error path.  The result is that the function can
return void, which simplifies callers considerably.

Whichever way you do it you do need to document your choices about
reentrancy.

> +static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
> +                           pid_t pid, int status)
> +{
> +    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
> +    EGC_GC;
> +
> +    if (status) {
> +        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
> +                                                  : LIBXL__LOG_WARNING,
> +                                      "hotplug child", pid, status);
> +    }

As I say, this needs to make a callback.

> +int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
> +{

It would be better IMO to call this function "launch" or something,
since it doesn't actually call exec in the parent (which is what I
think a function called "exec" should do).

> +    libxl__hotplug_state *hs;
> +
> +    hs = libxl__zalloc(gc, sizeof(*hs));

How about
    GCNEW(hs)
?

> +    if (!pid) {
> +        /* child */
> +        signal(SIGCHLD, SIG_DFL);

What is this for ?  Is the problem that children of libxl otherwise
inherit a weird SIGCHLD disposition ?  If so you need to fix this in
libxl__exec, probably in a separate patch - and you probably need to
sort out sigprocmask too in case the libxl caller has set up something
weird.  This is something that ought to go in a new patch.

> +    if (libxl__ev_child_inuse(&hs->child)) {
> +        hs->rc = rc;

Under what circumstances will rc!=0 here ?  Surely that is the success
path?  It might be easier simply to have "out:" be only the error
path.  The success path always has _inuse and the failure path never
does.

> +/* Action to pass to hotplug caller functions */
> +typedef enum {
> +    CONNECT = 1,
> +    DISCONNECT = 2
> +} libxl__hotplug_action;

These names are rather too generic, I think.

> +typedef struct libxl__hotplug_state libxl__hotplug_state;
> +
> +struct libxl__hotplug_state {
> +    /* public, result, caller may only read in callback */
> +    int rc;
> +    /* private for implementation */
> +    libxl__ev_child child;
> +};

And this is where the callback member ought to go, in the public
part, with a note saying it should be set by the caller.

Is there any provision for timeout here ?  Would here be a good place
to do the timeout, rather than higher up the stack ?

Also you might find it better to move the args and env and so forth
into the hotplug_state.  That way, for example, you can actually
produce a useful message when the script fails.

> +/*
> + * libxl__hotplug_exec is an internal function that should not be used
> + * directly, all hotplug script calls have to implement and use
> + * libxl__device_hotplug.
> + */
> +_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
> +                                  libxl__hotplug_action action);
> +_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
> +                                char **env);

Why does libxl__hotplug_exec need to be declared here at all then ?
Could it be static in libxl_hotplug.c ?

> +/* Hotplug scripts helpers */
> +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);

Why not use CTX ?  For that matter, if you use my new LOG macros you
don't need to refer to CTX at all.

> +    script = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
> +    if (!script) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
> +                                          be_path);

You need to log the errno.

> +    f_env = flexarray_make(9, 1);
> +    if (!f_env) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "unable to create environment array");
> +        return NULL;
> +    }

Isn't this an allocation failure which should be dealt with by
libxl__alloc_failed ?

> +    flexarray_set(f_env, nr++, "XENBUS_TYPE");
> +    flexarray_set(f_env, nr++, (char *)
> +                  libxl__device_kind_to_string(dev->backend_kind));

Why is the cast needed ?

> +    flexarray_set(f_env, nr++, "XENBUS_PATH");
> +    flexarray_set(f_env, nr++,
> +                  libxl__sprintf(gc, "backend/%s/%u/%d",
> +                  libxl__device_kind_to_string(dev->backend_kind),
> +                  dev->domid, dev->devid));

GCSPRINTF might help shorten this ?

For that matter, you've called libxl__device_kind_to_string twice.
Calling it only once would make this easier to read.

I won't comment any more on places where I think GCSPRINTF,
LOG/LOGE/LOGEV and CTX might usefully replace what you have written.

> +    env = get_hotplug_env(gc, dev);
> +    if (!env)
> +        return -1;

Surely this should never fail as it just results in allocation failure ?

This function seems to be supposed to return an rc value, so return -1
is wrong.

> +    args = (char **) flexarray_contents(f_args);

Why is the cast needed ?

> +    what = libxl__sprintf(gc, "%s %s", args[0],
> +                          action == CONNECT ? "connect" : "disconnect");

Surely

  action == CONNECT ? "connect" :
  action == DISCONNECT ? "disconnect" : abort()

?

> +    rc = libxl__hotplug_exec(gc, args[0], args, env);
> +    if (rc) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
> +                                          "device %"PRIu32, dev->devid);

libxl__hotplug_exec ought to do all the logging.  That means that all
the information needed to do so should be passed to it, including the
domid (which you don't currently log) and the device id.  That should
probably be filled in by its caller in the libxl__hotplug_state
struct.

> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> index c4f7c52..ce7a2b2 100644
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
>      int domid;
>      if ( !PyArg_ParseTuple(args, "i", &domid) )
>          return NULL;
> -    if ( libxl_domain_destroy(self->ctx, domid) ) {
> +    if ( libxl_domain_destroy(self->ctx, domid, NULL) ) {

I think this is correct.  Or, at least, we don't currently provide any
asynchronous capability in the Python code and I don't mind not doing
so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:49:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMRT-0004rD-8c; Mon, 23 Apr 2012 16:48:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMRR-0004r4-It
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:48:46 +0000
Received: from [85.158.143.99:63243] by server-2.bemta-4.messagelabs.com id
	EF/B1-17550-CE7859F4; Mon, 23 Apr 2012 16:48:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335199722!23993268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6613 invoked from network); 23 Apr 2012 16:48:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:48:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:48:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:48:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMQx-0003lY-PJ; Mon, 23 Apr 2012 16:48:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMQx-00061N-OL;
	Mon, 23 Apr 2012 17:48:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.34767.584624.953798@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:48:15 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-4-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
	libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for this mammoth patch.  My comments are below.

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd"):
> This is a rather big change, that adds the necessary machinery to perform
> hotplug script calling from libxl for Linux. This patch launches the necessary
> scripts to attach and detach PHY and TAP backend types (Qemu doesn't
> use hotplug scripts).
> 
> Here's a list of the major changes introduced:

Can you please wrap your commit messages to no more than 75
characters ?  Some vcs's indent them.  And of course they get indented
when we reply leading to wrap damage.

>  * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
>    calls libxl__initiate_device_remove, so we can disconnect the device and
>    execute the necessary hotplug scripts instead of just deleting the backend
>    entries. So libxl__devices_destroy now uses the event library, and so does
>    libxl_domain_destroy.

So we no longer have any function which will synchronously and
immediately destroy a domain and throw away everything to do with it.
Is it actually the case that you think such a function cannot be
provided ?

>  * Added a check in xen-hotplug-common.sh, so scripts are only executed from
>    udev when using xend. xl adds a disable_udev=y to xenstore private directory
>    and with the modification of the udev rules every call from udev gets
>    HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is passed
>    and points to a value, the hotplug script is not executed.

WDYM "points to a value"?  Did you just mean "is set to a nonempty
value" ?  I'm not convinced by the name of this variable.  Shouldn't
it have Xen in the name, and specify its own sense ?  Eg,
XEN_HOTPLUG_DISABLE or something ?

> +SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
...
> +# Hack to prevent the execution of hotplug scripts from udev if the domain
> +# has been launched from libxl
> +if [ -n "${HOTPLUG_GATE}" ] && \
> +   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
> +    exit 0
> +fi

Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
like the idea of being able to pass some random other xenstore path.

Also: this xenstore path should be a relative path, ie one relative to
the xenstore home of domain running this part of the tools.  That way
the scripts can be easily and automatically disabled for dom0 and
enabled in driver domains.

> +    /* compatibility addon to keep udev rules */
> +    flexarray_append(private, "disable_udev");
> +    flexarray_append(private, "y");

We would normally use "1" for true in xenstore.

>      libxl__device_generic_add(gc, &device,
> -                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> +                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
> +                    libxl__xs_kvs_of_flexarray(gc, private, private->count));
> +
> +    switch(disk->backend) {
> +    case LIBXL_DISK_BACKEND_PHY:
> +    case LIBXL_DISK_BACKEND_TAP:
> +        rc = libxl__initiate_device_add(egc, ao, &device);
> +        if (rc) goto out_free;
> +        break;
> +    case LIBXL_DISK_BACKEND_QDISK:
> +    default:
> +        libxl__ao_complete(egc, ao, 0);
> +        break;
> +    }

Does this really need no confirmation from qemu ?

>  out_free:
> +    flexarray_free(private);
> +out_free_b:
>      flexarray_free(back);
> +out_free_f:
>      flexarray_free(front);

It would be much better to allocate these from the gc somehow.
Failing that, perhaps we could initialise them to NULL and free
them iff necessary on the exit path:

  out:
      ...
      if (back)  flexarray_free(back);
      if (front) flexarray_free(front);
etc.

>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
> @@ -1442,7 +1484,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>      if (rc != 0) goto out;
>  
>      rc = libxl__initiate_device_remove(egc, ao, &device);
> -    if (rc) goto out;
> +    switch(rc) {
> +    case 1:
> +        /* event added */

I think this terminology "event added" is confusingly wrong.  What you
mean is "event queued", I think.  You should change this everywhere.
But before you do that, please see what I write below about your
approach to libxl__initiate_device_remove.

> @@ -1666,11 +1719,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>      ret = 0;
>  
>      libxl_device_disk_remove(ctx, domid, disks + i, 0);
> -    libxl_device_disk_add(ctx, domid, disk);
> +    libxl_device_disk_add(ctx, domid, disk, 0);

This needs a /* fixme-ao */ because inside-libxl callers are not
allowed to invent an ao_how*, even NULL.  You need to mark every
occurrence of these that way.

> @@ -1884,8 +1937,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>      flexarray_append(front, libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
>      libxl__device_generic_add(gc, &device,
> -                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> +                            libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                            libxl__xs_kvs_of_flexarray(gc, front, front->count),
> +                            NULL);

Likewise.  Also unintentional indentation change ?  (In several more
places, too.)

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 3675afe..de598ad 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>      store_libxl_entry(gc, domid, &d_config->b_info);
>  
>      for (i = 0; i < d_config->num_disks; i++) {
> -        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
> +        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i], 0);

Here in xl simply passing 0 is correct.

> +char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
> +{
> +    return libxl__sprintf(gc, "/libxl/backend/%s/%u/%d",
> +                          libxl__device_kind_to_string(device->backend_kind),
> +                          device->domid, device->devid);
> +}

Did you want to use GCSPRINTF ?

> +    rc = libxl__device_hotplug(gc, aorm->dev, DISCONNECT);

This is not correct.  You need to do something more with the exit
status of the hotplug script than simply throwing it away as you do in
hotplug_exited.  libxl__device_hotplug needs to take a callback from
the caller so that it can notify the caller when the hotplug script
has exited.

You need to not allow the ao to complete until the hotplug script has
exited.  Otherwise you will enter hotplug_exited after the
libxl__hotplug_state has been destroyed with the ao.

If it's too slow and you need to time out, you need to send the
hotplug script a signal, and then wait for it to exit.  If necessary
that signal could be SIGKILL; SIGKILL can be relied on to cause the
hotplug script to actually terminate and thus the hotplug_exited
callback to occur.

> +/*
> + * Return codes:
> + * 1 Success and event(s) HAVE BEEN added
> + * 0 Success and NO events were added
> + * < 0 Error
> + *
> + * Since this function can be called several times, and several events
> + * can be added to the same context, the user has to call
> + * libxl__ao_complete when necessary (if no events are added).
> + */
>  int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>                                    libxl__device *dev)

This comment should be in the header file near the declaration.
And indeed if you had put it there you would have discovered another
comment already there describing the old behaviour, which you have now
left behind as an erroneous comment.

And I think the new interface is entirely wrong.  How does the caller
know when to complete the ao if libxl__initiate_device_remove never
calls back ?

You need to split this into two functions: one with the current
interface which is a simple wrapper, used for all the existing call
sites, and one which never completes any ao but which always makes a
callback when the operation is complete.  That callback should be used
by the caller of libxl__initiate_device_remove to do whatever it needs
to, which might include completing the ao.

At the moment, AFAICT from reading your code, the caller's ao will be
completed by the first nontrivial device remove to complete, ie a bug.

> -int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
> +int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
> +                               libxl__device *dev)
...
> +    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_add_callback,
> +                                 state_path, XenbusStateInitWait,
> +                                 LIBXL_INIT_TIMEOUT * 1000);
> +    if (rc) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device %"
> +                                          PRIu32, dev->devid);
> +        libxl__ev_devstate_cancel(gc, &aorm->ds);

This cancel is not necessary, because device_add_cleanup will do
this.  (Or at least it should do; I haven't checked.)

> +        goto out_fail;
> +    }
> +
> +    return 0;
> +
> +out_fail:
> +    assert(rc);
> +    device_add_cleanup(gc, aorm);
> +    return rc;
> +out_ok:

^ blank line needed after the return.

> +    rc = libxl__device_hotplug(gc, dev, CONNECT);
> +    libxl__ao_complete(egc, ao, 0);
> +    return rc;
> +}

Some of my comments about initiate_device_remove's callback probably
apply here too.  In particular, I have found it is often better to
make a callback-queueing function always call the callback right away,
recursively, on the error path.  The result is that the function can
return void, which simplifies callers considerably.

Whichever way you do it you do need to document your choices about
reentrancy.

> +static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
> +                           pid_t pid, int status)
> +{
> +    libxl__hotplug_state *hs = CONTAINER_OF(child, *hs, child);
> +    EGC_GC;
> +
> +    if (status) {
> +        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
> +                                                  : LIBXL__LOG_WARNING,
> +                                      "hotplug child", pid, status);
> +    }

As I say, this needs to make a callback.

> +int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **env)
> +{

It would be better IMO to call this function "launch" or something,
since it doesn't actually call exec in the parent (which is what I
think a function called "exec" should do).

> +    libxl__hotplug_state *hs;
> +
> +    hs = libxl__zalloc(gc, sizeof(*hs));

How about
    GCNEW(hs)
?

> +    if (!pid) {
> +        /* child */
> +        signal(SIGCHLD, SIG_DFL);

What is this for ?  Is the problem that children of libxl otherwise
inherit a weird SIGCHLD disposition ?  If so you need to fix this in
libxl__exec, probably in a separate patch - and you probably need to
sort out sigprocmask too in case the libxl caller has set up something
weird.  This is something that ought to go in a new patch.

> +    if (libxl__ev_child_inuse(&hs->child)) {
> +        hs->rc = rc;

Under what circumstances will rc!=0 here ?  Surely that is the success
path?  It might be easier simply to have "out:" be only the error
path.  The success path always has _inuse and the failure path never
does.

> +/* Action to pass to hotplug caller functions */
> +typedef enum {
> +    CONNECT = 1,
> +    DISCONNECT = 2
> +} libxl__hotplug_action;

These names are rather too generic, I think.

> +typedef struct libxl__hotplug_state libxl__hotplug_state;
> +
> +struct libxl__hotplug_state {
> +    /* public, result, caller may only read in callback */
> +    int rc;
> +    /* private for implementation */
> +    libxl__ev_child child;
> +};

And this is where the callback member ought to go, in the public
part, with a note saying it should be set by the caller.

Is there any provision for timeout here ?  Would here be a good place
to do the timeout, rather than higher up the stack ?

Also you might find it better to move the args and env and so forth
into the hotplug_state.  That way, for example, you can actually
produce a useful message when the script fails.

> +/*
> + * libxl__hotplug_exec is an internal function that should not be used
> + * directly, all hotplug script calls have to implement and use
> + * libxl__device_hotplug.
> + */
> +_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
> +                                  libxl__hotplug_action action);
> +_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
> +                                char **env);

Why does libxl__hotplug_exec need to be declared here at all then ?
Could it be static in libxl_hotplug.c ?

> +/* Hotplug scripts helpers */
> +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);

Why not use CTX ?  For that matter, if you use my new LOG macros you
don't need to refer to CTX at all.

> +    script = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
> +    if (!script) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
> +                                          be_path);

You need to log the errno.

> +    f_env = flexarray_make(9, 1);
> +    if (!f_env) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "unable to create environment array");
> +        return NULL;
> +    }

Isn't this an allocation failure which should be dealt with by
libxl__alloc_failed ?

> +    flexarray_set(f_env, nr++, "XENBUS_TYPE");
> +    flexarray_set(f_env, nr++, (char *)
> +                  libxl__device_kind_to_string(dev->backend_kind));

Why is the cast needed ?

> +    flexarray_set(f_env, nr++, "XENBUS_PATH");
> +    flexarray_set(f_env, nr++,
> +                  libxl__sprintf(gc, "backend/%s/%u/%d",
> +                  libxl__device_kind_to_string(dev->backend_kind),
> +                  dev->domid, dev->devid));

GCSPRINTF might help shorten this ?

For that matter, you've called libxl__device_kind_to_string twice.
Calling it only once would make this easier to read.

I won't comment any more on places where I think GCSPRINTF,
LOG/LOGE/LOGEV and CTX might usefully replace what you have written.

> +    env = get_hotplug_env(gc, dev);
> +    if (!env)
> +        return -1;

Surely this should never fail as it just results in allocation failure ?

This function seems to be supposed to return an rc value, so return -1
is wrong.

> +    args = (char **) flexarray_contents(f_args);

Why is the cast needed ?

> +    what = libxl__sprintf(gc, "%s %s", args[0],
> +                          action == CONNECT ? "connect" : "disconnect");

Surely

  action == CONNECT ? "connect" :
  action == DISCONNECT ? "disconnect" : abort()

?

> +    rc = libxl__hotplug_exec(gc, args[0], args, env);
> +    if (rc) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scripts for "
> +                                          "device %"PRIu32, dev->devid);

libxl__hotplug_exec ought to do all the logging.  That means that all
the information needed to do so should be passed to it, including the
domid (which you don't currently log) and the device id.  That should
probably be filled in by its caller in the libxl__hotplug_state
struct.

> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> index c4f7c52..ce7a2b2 100644
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
>      int domid;
>      if ( !PyArg_ParseTuple(args, "i", &domid) )
>          return NULL;
> -    if ( libxl_domain_destroy(self->ctx, domid) ) {
> +    if ( libxl_domain_destroy(self->ctx, domid, NULL) ) {

I think this is correct.  Or, at least, we don't currently provide any
asynchronous capability in the Python code and I don't mind not doing
so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:49:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMSH-0004w9-Uu; Mon, 23 Apr 2012 16:49:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMSH-0004w0-7M
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:49:37 +0000
Received: from [193.109.254.147:5956] by server-2.bemta-14.messagelabs.com id
	7E/4C-19409-028859F4; Mon, 23 Apr 2012 16:49:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335199776!5913753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28935 invoked from network); 23 Apr 2012 16:49:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:49:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:49:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMSF-0003lz-L8; Mon, 23 Apr 2012 16:49:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMSF-00061b-KK;
	Mon, 23 Apr 2012 17:49:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.34847.574893.779560@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:49:35 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F957872.3080502@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
	<20373.30292.162693.913028@mariner.uk.xensource.com>
	<4F957872.3080502@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__x=
s_path_cleanup"):
> Ian Jackson escribi=F3:
> > With the C xenstored, the RM command will delete a whole directory
> > tree, regardless of its contents.  This is documented in
> > docs/misc/xenstore.txt.
> =

> This is a recursive delete, from top to bottom, let me put an example =

> which will make this clear, since probably the title is wrong. Imagine =

> you have the following xenstore entry:
> =

> /foo/bar/baz =3D 123
> =

> If you do a:
> =

> xenstore-rm /foo/bar/baz
> =

> the following will remain in xenstore:
> =

> /foo/bar
> =

> What this function does is clean empty folders that contained the =

> deleted entry, so using this function on /foo/bar/baz would have cleaned =

> the whole directory.

Oh!  This was quite unclear to me and I didn't read your code closely
enough to spot this.  I'll go back and read your patch again.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:49:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMSH-0004w9-Uu; Mon, 23 Apr 2012 16:49:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMSH-0004w0-7M
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:49:37 +0000
Received: from [193.109.254.147:5956] by server-2.bemta-14.messagelabs.com id
	7E/4C-19409-028859F4; Mon, 23 Apr 2012 16:49:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335199776!5913753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28935 invoked from network); 23 Apr 2012 16:49:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:49:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:49:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMSF-0003lz-L8; Mon, 23 Apr 2012 16:49:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMSF-00061b-KK;
	Mon, 23 Apr 2012 17:49:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.34847.574893.779560@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:49:35 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F957872.3080502@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
	<20373.30292.162693.913028@mariner.uk.xensource.com>
	<4F957872.3080502@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__x=
s_path_cleanup"):
> Ian Jackson escribi=F3:
> > With the C xenstored, the RM command will delete a whole directory
> > tree, regardless of its contents.  This is documented in
> > docs/misc/xenstore.txt.
> =

> This is a recursive delete, from top to bottom, let me put an example =

> which will make this clear, since probably the title is wrong. Imagine =

> you have the following xenstore entry:
> =

> /foo/bar/baz =3D 123
> =

> If you do a:
> =

> xenstore-rm /foo/bar/baz
> =

> the following will remain in xenstore:
> =

> /foo/bar
> =

> What this function does is clean empty folders that contained the =

> deleted entry, so using this function on /foo/bar/baz would have cleaned =

> the whole directory.

Oh!  This was quite unclear to me and I didn't read your code closely
enough to spot this.  I'll go back and read your patch again.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:52:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMV2-00058x-HV; Mon, 23 Apr 2012 16:52:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMV0-00058k-Tu
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:52:27 +0000
Received: from [193.109.254.147:47770] by server-12.bemta-14.messagelabs.com
	id 98/B5-05898-AC8859F4; Mon, 23 Apr 2012 16:52:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335199945!5914077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3607 invoked from network); 23 Apr 2012 16:52:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:52:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:52:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:52:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMUz-0003n3-9Y; Mon, 23 Apr 2012 16:52:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMUz-00061n-8c;
	Mon, 23 Apr 2012 17:52:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.35017.147406.379559@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:52:25 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-3-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup"):
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index c7e057d..36d58cd 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
>      return -1;
>  }
>  
> -

Unrelated whitespace change.

> +/*
> + * Perfrom recursive cleanup of xenstore path, from top to bottom
> + * just like xenstore-rm -t
> + */
> +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);

I think, following my confusion, that this needs some better
documentation comment.

> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index 3ea8d08..0b1b844 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
>      return s;
>  }
>  
> +int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    unsigned int nb = 0;
> +    char *last;
> +
> +    if (!path)
> +        return 0;
> +
> +    xs_rm(ctx->xsh, XBT_NULL, path);
> +
> +    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {

If the path is relative, this won't work correctly.

Also this whole thing needs to take place in a transaction, or it is
racy.  Probably a transaction supplied by the caller, in which case
you should assert it.

> +        *last = '\0';
> +        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
> +            continue;

If this fails, it should be a fatal error; we should not just blunder
on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:52:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMV2-00058x-HV; Mon, 23 Apr 2012 16:52:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMV0-00058k-Tu
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:52:27 +0000
Received: from [193.109.254.147:47770] by server-12.bemta-14.messagelabs.com
	id 98/B5-05898-AC8859F4; Mon, 23 Apr 2012 16:52:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335199945!5914077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3607 invoked from network); 23 Apr 2012 16:52:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:52:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:52:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:52:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMUz-0003n3-9Y; Mon, 23 Apr 2012 16:52:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMUz-00061n-8c;
	Mon, 23 Apr 2012 17:52:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.35017.147406.379559@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:52:25 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-3-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup"):
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index c7e057d..36d58cd 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
>      return -1;
>  }
>  
> -

Unrelated whitespace change.

> +/*
> + * Perfrom recursive cleanup of xenstore path, from top to bottom
> + * just like xenstore-rm -t
> + */
> +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);

I think, following my confusion, that this needs some better
documentation comment.

> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index 3ea8d08..0b1b844 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
>      return s;
>  }
>  
> +int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    unsigned int nb = 0;
> +    char *last;
> +
> +    if (!path)
> +        return 0;
> +
> +    xs_rm(ctx->xsh, XBT_NULL, path);
> +
> +    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {

If the path is relative, this won't work correctly.

Also this whole thing needs to take place in a transaction, or it is
racy.  Probably a transaction supplied by the caller, in which case
you should assert it.

> +        *last = '\0';
> +        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
> +            continue;

If this fails, it should be a fatal error; we should not just blunder
on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:57:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMZP-0005Li-8w; Mon, 23 Apr 2012 16:56:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMZN-0005LW-6V
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:56:57 +0000
Received: from [85.158.143.99:31240] by server-1.bemta-4.messagelabs.com id
	B4/7B-20925-8D9859F4; Mon, 23 Apr 2012 16:56:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335200214!21528624!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28751 invoked from network); 23 Apr 2012 16:56:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:56:55 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NGuY9O006698
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 16:56:35 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NGuXrK027182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 16:56:34 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NGuWlP006153; Mon, 23 Apr 2012 11:56:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 09:56:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 49CA24032D; Mon, 23 Apr 2012 12:51:28 -0400 (EDT)
Date: Mon, 23 Apr 2012 12:51:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luck, Tony" <tony.luck@intel.com>
Message-ID: <20120423165128.GA22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<20120423153222.GE24481@phenom.dumpdata.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF914@ORSMSX104.amr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF914@ORSMSX104.amr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 04:17:14PM +0000, Luck, Tony wrote:
> > This driver is _not_ doing a strict bit-by-bit copy of 'struct mcinfo'
> > to 'struct mce'. It is plucking the right bits and setting them in
> > 'struct mce'.
> 
> That isn't any worse that what we currently have ... but what we currently
> have is ugly, and doing more ugly things just because we did them before
> generally isn't a winning argument on the mailing lists.

Heh.

Until about an hour ago I did not know that what is there is considered
'ugly' and you guys had thoughts of how to make it nicer. That is good.
And the driver isn't set in stone by only using those function - it can
change.

I am not sure if I have stated, but providing this driver in my mind
is an implicit contract that I, as the sub-maintainer, will keep it
in lock-step with mce.h cleanups. That is after all, the job of a
(sub)-maintainer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:57:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMZP-0005Li-8w; Mon, 23 Apr 2012 16:56:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMZN-0005LW-6V
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:56:57 +0000
Received: from [85.158.143.99:31240] by server-1.bemta-4.messagelabs.com id
	B4/7B-20925-8D9859F4; Mon, 23 Apr 2012 16:56:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335200214!21528624!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28751 invoked from network); 23 Apr 2012 16:56:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:56:55 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NGuY9O006698
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 16:56:35 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NGuXrK027182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 16:56:34 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NGuWlP006153; Mon, 23 Apr 2012 11:56:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 09:56:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 49CA24032D; Mon, 23 Apr 2012 12:51:28 -0400 (EDT)
Date: Mon, 23 Apr 2012 12:51:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luck, Tony" <tony.luck@intel.com>
Message-ID: <20120423165128.GA22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<20120423153222.GE24481@phenom.dumpdata.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF914@ORSMSX104.amr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F170EF914@ORSMSX104.amr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 04:17:14PM +0000, Luck, Tony wrote:
> > This driver is _not_ doing a strict bit-by-bit copy of 'struct mcinfo'
> > to 'struct mce'. It is plucking the right bits and setting them in
> > 'struct mce'.
> 
> That isn't any worse that what we currently have ... but what we currently
> have is ugly, and doing more ugly things just because we did them before
> generally isn't a winning argument on the mailing lists.

Heh.

Until about an hour ago I did not know that what is there is considered
'ugly' and you guys had thoughts of how to make it nicer. That is good.
And the driver isn't set in stone by only using those function - it can
change.

I am not sure if I have stated, but providing this driver in my mind
is an implicit contract that I, as the sub-maintainer, will keep it
in lock-step with mce.h cleanups. That is after all, the job of a
(sub)-maintainer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:59:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMbu-0005SQ-9g; Mon, 23 Apr 2012 16:59:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMbt-0005SB-5a
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:59:33 +0000
Received: from [85.158.143.35:48660] by server-2.bemta-4.messagelabs.com id
	8F/DB-17550-47A859F4; Mon, 23 Apr 2012 16:59:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335200369!13300056!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24849 invoked from network); 23 Apr 2012 16:59:30 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:59:30 -0000
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227])
	by acsinet14.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NGxSfp028964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 16:59:28 GMT
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NGx6q8009572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 16:59:06 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NGx50w000992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 16:59:06 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NGx5tH001746; Mon, 23 Apr 2012 11:59:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 09:59:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 45D814032D; Mon, 23 Apr 2012 12:54:01 -0400 (EDT)
Date: Mon, 23 Apr 2012 12:54:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120423165401.GB22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
	<20120423150657.GA24481@phenom.dumpdata.com>
	<20120423155957.GA6147@aftab.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423155957.GA6147@aftab.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > Now xen is a whole another deal - it is purely a piece of software.
> > 
> > Perfect. Software is more elastic than hardware - so the Xen ABI
> > for the MCE can be changed then to reflect the new format if required.
> 
> And this "elastic" piece of software is yet another thing I have to deal
> with when working on MCE which is strictly doing _hardware_ support. And
> I don't want to do that - if you hook in the mce_log() interface, you're
> practically becoming yet another user of it which I have to account for
> when doing changes to the core MCE code.

Or you can delegate.
> 
> [..]
> 
> > Delegate testing to sub-maintainers. In this case that would be me and
> > Liu.
> 
> Ok, just purely hypothetically, what happens if there's no one to update
> this code anymore? What if Oracle or Citrix or whoever it is, is not
> interested in maintaining xen anymore, or those drivers or whatever?
> I'm stuck with users of this which I can't shake off because there's no
> upstream development. Oh, and then there's the distros which already
> have their installs and they'd never update their setup because it works
> and why touch it... and so on and so on...

In case I get hit by a bus and nobody steps up from the Xen community shortly
after that or Intel is not interested anymore in this driver, then you:
 1) mark it as CONFIG_BROKEN
 2) wait some time until somebody elects themselves as the maintainer.
 3) And if that does not become true, then you do 'git rm ..'. 

Distros are in the business of providing maintainship services. That is
after all how they make their money. The Kconfig by default is set to 'n'
and the wording can be written further to inhibit folks from using.

But I do follow Fedora Core and Ubuntu bugs that have the word 'xen' in
them to fix the issues they encounter. You are probably doing the same
thing (s/xen/mce)- so why don't you point the sub-maintainer to the
distro bug so he/she can fix it?


.. snip..
> > I am not sure I see why we cannot fix the practical problems as they pop
> > up?
> 
> See above.
> 
> [..]
> 
> > > hook into arch/x86/ instead of doing your own stuff?
> > 
> > I think what you are suggesting is to _not_ reuse existing APIs. That
> > seems counter-intuive to general software development. There are
> > exceptions of course - when the existing API needs to change a lot
> > (or needs to be thrown out), and there is this one little driver that
> > keeps on using the old interface and can't change - at that point I can
> > see the purpose of forking it. But until then - using existing APIs is
> > the way to go.
> 
> I just love it when guys left and right start teaching me about stuff,
> it's like I even begged for it...
> 
> You're not reusing the existing API because mce_log is not an API to
> anything - it is an internal x86 MCE logging thing to put a struct mce
> into a static ring buffer.
> 
> The API is /dev/mcelog and there you should interface, not hook into
> internal stuff and cripple it from developing any further.

I mentioned on a couple of occasions that we would be keeping the implementation
in lock-step and testing as neccessary. And if you choose to omit this
driver and asked us to develop the appropiate patch, we can surely
do that too.

> 
> [snip more senseless drivel]
> 
> > > Now, with your own buffer solution, nothing breaks and all is happy,
> > > a win-win, if you wish. I think this is much simpler and easier a
> > > solution.
> > 
> > Not sure what you mean by 'own buffer solution'. Are you talking about
> > using the trace_mce_record or the ras_printk instead of the mce_log?
> > I would think that is the job of the MCE decoders?
> 
> No, I mean to copy the mce_log() code along with the functions that
> create the char device /dev/mcelog - mce_chrdev_*.
> 
> Btw, you'd probably be done with it if you'd taken the time to do that
> instead of arguing your cause.

I am not advocating that we stick a ground in stone and say: "this is
how mce_log(x)" from now on MUST be used. If that is impression left by
my wording - my mistake. I would want the driver to change to adhere
to the new function calls/structures.

> 
> > Please keep in mind that this driver is not trying to decode anything -
> 
> I know that.
> 
> > it just lifting raw events, massaging them a bit, and sending them
> > downstream. Similar to how the APEI does it.
> 
> Please stop talking about APEI - I told you why it doesn't apply here in
> a previous mail.

Right, b/c it is hardware and is set in stone.
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> Advanced Micro Devices GmbH
> Einsteinring 24, 85609 Dornach
> GM: Alberto Bozzo
> Reg: Dornach, Landkreis Muenchen
> HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:59:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMbu-0005SQ-9g; Mon, 23 Apr 2012 16:59:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMbt-0005SB-5a
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 16:59:33 +0000
Received: from [85.158.143.35:48660] by server-2.bemta-4.messagelabs.com id
	8F/DB-17550-47A859F4; Mon, 23 Apr 2012 16:59:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335200369!13300056!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24849 invoked from network); 23 Apr 2012 16:59:30 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 16:59:30 -0000
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227])
	by acsinet14.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NGxSfp028964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 23 Apr 2012 16:59:28 GMT
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NGx6q8009572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 16:59:06 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NGx50w000992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 16:59:06 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NGx5tH001746; Mon, 23 Apr 2012 11:59:05 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 09:59:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 45D814032D; Mon, 23 Apr 2012 12:54:01 -0400 (EDT)
Date: Mon, 23 Apr 2012 12:54:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120423165401.GB22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<20120423021827.GA13840@phenom.dumpdata.com>
	<20120423060921.GA29378@aftab.osrc.amd.com>
	<20120423150657.GA24481@phenom.dumpdata.com>
	<20120423155957.GA6147@aftab.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423155957.GA6147@aftab.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > Now xen is a whole another deal - it is purely a piece of software.
> > 
> > Perfect. Software is more elastic than hardware - so the Xen ABI
> > for the MCE can be changed then to reflect the new format if required.
> 
> And this "elastic" piece of software is yet another thing I have to deal
> with when working on MCE which is strictly doing _hardware_ support. And
> I don't want to do that - if you hook in the mce_log() interface, you're
> practically becoming yet another user of it which I have to account for
> when doing changes to the core MCE code.

Or you can delegate.
> 
> [..]
> 
> > Delegate testing to sub-maintainers. In this case that would be me and
> > Liu.
> 
> Ok, just purely hypothetically, what happens if there's no one to update
> this code anymore? What if Oracle or Citrix or whoever it is, is not
> interested in maintaining xen anymore, or those drivers or whatever?
> I'm stuck with users of this which I can't shake off because there's no
> upstream development. Oh, and then there's the distros which already
> have their installs and they'd never update their setup because it works
> and why touch it... and so on and so on...

In case I get hit by a bus and nobody steps up from the Xen community shortly
after that or Intel is not interested anymore in this driver, then you:
 1) mark it as CONFIG_BROKEN
 2) wait some time until somebody elects themselves as the maintainer.
 3) And if that does not become true, then you do 'git rm ..'. 

Distros are in the business of providing maintainship services. That is
after all how they make their money. The Kconfig by default is set to 'n'
and the wording can be written further to inhibit folks from using.

But I do follow Fedora Core and Ubuntu bugs that have the word 'xen' in
them to fix the issues they encounter. You are probably doing the same
thing (s/xen/mce)- so why don't you point the sub-maintainer to the
distro bug so he/she can fix it?


.. snip..
> > I am not sure I see why we cannot fix the practical problems as they pop
> > up?
> 
> See above.
> 
> [..]
> 
> > > hook into arch/x86/ instead of doing your own stuff?
> > 
> > I think what you are suggesting is to _not_ reuse existing APIs. That
> > seems counter-intuive to general software development. There are
> > exceptions of course - when the existing API needs to change a lot
> > (or needs to be thrown out), and there is this one little driver that
> > keeps on using the old interface and can't change - at that point I can
> > see the purpose of forking it. But until then - using existing APIs is
> > the way to go.
> 
> I just love it when guys left and right start teaching me about stuff,
> it's like I even begged for it...
> 
> You're not reusing the existing API because mce_log is not an API to
> anything - it is an internal x86 MCE logging thing to put a struct mce
> into a static ring buffer.
> 
> The API is /dev/mcelog and there you should interface, not hook into
> internal stuff and cripple it from developing any further.

I mentioned on a couple of occasions that we would be keeping the implementation
in lock-step and testing as neccessary. And if you choose to omit this
driver and asked us to develop the appropiate patch, we can surely
do that too.

> 
> [snip more senseless drivel]
> 
> > > Now, with your own buffer solution, nothing breaks and all is happy,
> > > a win-win, if you wish. I think this is much simpler and easier a
> > > solution.
> > 
> > Not sure what you mean by 'own buffer solution'. Are you talking about
> > using the trace_mce_record or the ras_printk instead of the mce_log?
> > I would think that is the job of the MCE decoders?
> 
> No, I mean to copy the mce_log() code along with the functions that
> create the char device /dev/mcelog - mce_chrdev_*.
> 
> Btw, you'd probably be done with it if you'd taken the time to do that
> instead of arguing your cause.

I am not advocating that we stick a ground in stone and say: "this is
how mce_log(x)" from now on MUST be used. If that is impression left by
my wording - my mistake. I would want the driver to change to adhere
to the new function calls/structures.

> 
> > Please keep in mind that this driver is not trying to decode anything -
> 
> I know that.
> 
> > it just lifting raw events, massaging them a bit, and sending them
> > downstream. Similar to how the APEI does it.
> 
> Please stop talking about APEI - I told you why it doesn't apply here in
> a previous mail.

Right, b/c it is hardware and is set in stone.
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> Advanced Micro Devices GmbH
> Einsteinring 24, 85609 Dornach
> GM: Alberto Bozzo
> Reg: Dornach, Landkreis Muenchen
> HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:59:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMbt-0005SJ-S4; Mon, 23 Apr 2012 16:59:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMbr-0005S6-OA
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:59:31 +0000
Received: from [85.158.139.83:15312] by server-9.bemta-5.messagelabs.com id
	A4/38-09826-27A859F4; Mon, 23 Apr 2012 16:59:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335200369!22403745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5284 invoked from network); 23 Apr 2012 16:59:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:59:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:59:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMbo-0003p7-8d; Mon, 23 Apr 2012 16:59:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMbo-00062I-7l;
	Mon, 23 Apr 2012 17:59:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.35440.226796.301582@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:59:28 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-5-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
	libxl	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from libxl for vif"):
> As the previous change already introduces most of needed machinery to call
> hotplug scripts from libxl, this only adds the necessary bits to call this
> scripts for vif interfaces also.

I have read this only cursorily, given my comments on the previous
patch, but:

> +    char *ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
> +                                                                   be_path,
> +                                                                   "vifname"));

Probably all of these functions need to take a xenstore transaction to
deal with concurrency properly.

You need to avoid assuming that NULL from libxl__xs_* means what you
think it means.  It might be better to invent a new wrapper which you
could use like this
    rc = libxl__xs_read_that_actually_works(gc, trans, path, &result);
    if (rc) goto out;
    if (!result) {
        /* code for if thing doesn't exist */
    }

GCSPRINTF might avoid the weird wrapping.

> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..0b2c832 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
>      ("ifname", string),
>      ("script", string),
>      ("nictype", libxl_nic_type),
> +    ("disable_xl_vif_script", integer),
>      ])

We shouldn't have config options of the form "disable_...".  They
should all be phrased as "enable" or in this case "run".  And I'm not
convinced by "xl", but since there isn't any patch to the xl domain
configuration doc for this new option I'm not sure.  Of course
documentation is needed...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 16:59:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 16:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMbt-0005SJ-S4; Mon, 23 Apr 2012 16:59:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMMbr-0005S6-OA
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 16:59:31 +0000
Received: from [85.158.139.83:15312] by server-9.bemta-5.messagelabs.com id
	A4/38-09826-27A859F4; Mon, 23 Apr 2012 16:59:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335200369!22403745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5284 invoked from network); 23 Apr 2012 16:59:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 16:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12086553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 16:59:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 17:59:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMMbo-0003p7-8d; Mon, 23 Apr 2012 16:59:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMMbo-00062I-7l;
	Mon, 23 Apr 2012 17:59:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20373.35440.226796.301582@mariner.uk.xensource.com>
Date: Mon, 23 Apr 2012 17:59:28 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334928211-29856-5-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
	libxl	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from libxl for vif"):
> As the previous change already introduces most of needed machinery to call
> hotplug scripts from libxl, this only adds the necessary bits to call this
> scripts for vif interfaces also.

I have read this only cursorily, given my comments on the previous
patch, but:

> +    char *ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
> +                                                                   be_path,
> +                                                                   "vifname"));

Probably all of these functions need to take a xenstore transaction to
deal with concurrency properly.

You need to avoid assuming that NULL from libxl__xs_* means what you
think it means.  It might be better to invent a new wrapper which you
could use like this
    rc = libxl__xs_read_that_actually_works(gc, trans, path, &result);
    if (rc) goto out;
    if (!result) {
        /* code for if thing doesn't exist */
    }

GCSPRINTF might avoid the weird wrapping.

> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..0b2c832 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
>      ("ifname", string),
>      ("script", string),
>      ("nictype", libxl_nic_type),
> +    ("disable_xl_vif_script", integer),
>      ])

We shouldn't have config options of the form "disable_...".  They
should all be phrased as "enable" or in this case "run".  And I'm not
convinced by "xl", but since there isn't any patch to the xl domain
configuration doc for this new option I'm not sure.  Of course
documentation is needed...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:07:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:07:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMj2-0005op-8z; Mon, 23 Apr 2012 17:06:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1SMMj1-0005ok-36
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 17:06:55 +0000
Received: from [85.158.143.35:27991] by server-3.bemta-4.messagelabs.com id
	72/2E-05853-E2C859F4; Mon, 23 Apr 2012 17:06:54 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335200811!10140907!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24172 invoked from network); 23 Apr 2012 17:06:53 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:06:53 -0000
Received: by yhoo21 with SMTP id o21so7525318yho.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 10:06:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=ryje7Ly1gRQNgvA8yrzbxNILQGhdX3wufHC8rhOY/K8=;
	b=kxhprtwUmyQVYIOvfbYDbpq4jfBcxCTOOF0RaKEDoGYL5WwAlr6Xp0rMVjFwut+jL0
	qRtJgEMxgyVemUBpmsuYL5gkoh9WioFv9PeE3rGuyawzs4Vew5ORXpHrIV895kL684Dj
	yFuI0WJoJh5+gDH1yCSwfeLVSFSbPL966JJ1KHN9eF5DM0ZZG//2/CAKKe1iugiz3AkU
	sZOgx8P+SnI0S6zAG3lAS+OO3OA+NeVMpFkQKfqIXynmjHYdo42pNfjSnMAIyd+IgqLs
	HN1OooirjN42TrEiJwrBx7Z70Tc3ygm13HMhJc9v99wezwwuVVmjqu7eZKN9W0Xzwaov
	YNlQ==
Received: by 10.50.51.197 with SMTP id m5mr7232688igo.38.1335200810591;
	Mon, 23 Apr 2012 10:06:50 -0700 (PDT)
Received: from [192.168.7.211] ([206.223.182.18])
	by mx.google.com with ESMTPS id md6sm26953146igc.0.2012.04.23.10.06.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Apr 2012 10:06:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <11cfdcc14635fc08a5fc012de2fbcc0e.squirrel@webmail.lagarcavilla.org>
Date: Mon, 23 Apr 2012 13:06:51 -0400
Message-Id: <89BAAC1F-C8DE-461F-A41B-2F03D6F14151@gridcentric.ca>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
	<20120405101544.GD14774@ocelot.phlegethon.org>
	<11cfdcc14635fc08a5fc012de2fbcc0e.squirrel@webmail.lagarcavilla.org>
To: andres@lagarcavilla.org
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnbXk1y4/coQwZO89LSC3VQoQV8BPQAIqdQEKH6kakR/VXz5BCNX3fKQ/Zr23uYYPewQ3hP
Cc: ian.jackson@citrix.com, adin@gridcentric.ca, Tim Deegan <tim@xen.org>,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 12, 2012, at 10:18 AM, Andres Lagar-Cavilla wrote:

>> At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
>>> Document the sharing libxc interface, including failure conditions,
>>> meaning of
>>> stats, and internal semantics/behavior.
>>> 
>>> Also remove a stale debug call.
>>> 
>>> Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits.
>>> Both
>>> patches touch the tools. Patch #2 is entirely documentation comments.
>>> 
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> 
>> Acked-by: Tim Deegan <tim@xen.org>
> 
> Ping? Ian & Ian?
> Thanks,
> Andres

New weekly ping :)
Thanks,
Andres

> 
>> 
>> Cheers,
>> 
>> Tim.
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:07:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:07:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMj2-0005op-8z; Mon, 23 Apr 2012 17:06:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1SMMj1-0005ok-36
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 17:06:55 +0000
Received: from [85.158.143.35:27991] by server-3.bemta-4.messagelabs.com id
	72/2E-05853-E2C859F4; Mon, 23 Apr 2012 17:06:54 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335200811!10140907!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24172 invoked from network); 23 Apr 2012 17:06:53 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:06:53 -0000
Received: by yhoo21 with SMTP id o21so7525318yho.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 10:06:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=ryje7Ly1gRQNgvA8yrzbxNILQGhdX3wufHC8rhOY/K8=;
	b=kxhprtwUmyQVYIOvfbYDbpq4jfBcxCTOOF0RaKEDoGYL5WwAlr6Xp0rMVjFwut+jL0
	qRtJgEMxgyVemUBpmsuYL5gkoh9WioFv9PeE3rGuyawzs4Vew5ORXpHrIV895kL684Dj
	yFuI0WJoJh5+gDH1yCSwfeLVSFSbPL966JJ1KHN9eF5DM0ZZG//2/CAKKe1iugiz3AkU
	sZOgx8P+SnI0S6zAG3lAS+OO3OA+NeVMpFkQKfqIXynmjHYdo42pNfjSnMAIyd+IgqLs
	HN1OooirjN42TrEiJwrBx7Z70Tc3ygm13HMhJc9v99wezwwuVVmjqu7eZKN9W0Xzwaov
	YNlQ==
Received: by 10.50.51.197 with SMTP id m5mr7232688igo.38.1335200810591;
	Mon, 23 Apr 2012 10:06:50 -0700 (PDT)
Received: from [192.168.7.211] ([206.223.182.18])
	by mx.google.com with ESMTPS id md6sm26953146igc.0.2012.04.23.10.06.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Apr 2012 10:06:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <11cfdcc14635fc08a5fc012de2fbcc0e.squirrel@webmail.lagarcavilla.org>
Date: Mon, 23 Apr 2012 13:06:51 -0400
Message-Id: <89BAAC1F-C8DE-461F-A41B-2F03D6F14151@gridcentric.ca>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
	<20120405101544.GD14774@ocelot.phlegethon.org>
	<11cfdcc14635fc08a5fc012de2fbcc0e.squirrel@webmail.lagarcavilla.org>
To: andres@lagarcavilla.org
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnbXk1y4/coQwZO89LSC3VQoQV8BPQAIqdQEKH6kakR/VXz5BCNX3fKQ/Zr23uYYPewQ3hP
Cc: ian.jackson@citrix.com, adin@gridcentric.ca, Tim Deegan <tim@xen.org>,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 12, 2012, at 10:18 AM, Andres Lagar-Cavilla wrote:

>> At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
>>> Document the sharing libxc interface, including failure conditions,
>>> meaning of
>>> stats, and internal semantics/behavior.
>>> 
>>> Also remove a stale debug call.
>>> 
>>> Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits.
>>> Both
>>> patches touch the tools. Patch #2 is entirely documentation comments.
>>> 
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> 
>> Acked-by: Tim Deegan <tim@xen.org>
> 
> Ping? Ian & Ian?
> Thanks,
> Andres

New weekly ping :)
Thanks,
Andres

> 
>> 
>> Cheers,
>> 
>> Tim.
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMl7-0005w9-2S; Mon, 23 Apr 2012 17:09:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMl5-0005w2-2L
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:09:03 +0000
Received: from [193.109.254.147:17386] by server-1.bemta-14.messagelabs.com id
	23/92-29372-EAC859F4; Mon, 23 Apr 2012 17:09:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335200940!5916146!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29337 invoked from network); 23 Apr 2012 17:09:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:09:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NH8YAN022322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 17:08:37 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NH8X48020545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 17:08:34 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NH8Wxs005807; Mon, 23 Apr 2012 12:08:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 10:08:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 10E584032D; Mon, 23 Apr 2012 13:03:28 -0400 (EDT)
Date: Mon, 23 Apr 2012 13:03:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120423170327.GC22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<4F958098.1050402@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F958098.1050402@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "Luck, Tony" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote:
> On 04/23/2012 08:27 AM, Luck, Tony wrote:
> >> Because, if you'd hooked into it, just imagine one fine day, when we
> >> remove mcelog support, what screaming the xen people will be doing when
> >> mcelog doesn't work anymore.
> > 
> > Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
> > fields could be added) ... and you don't want to have your hypervisor to
> > have to know which version of Linux it is talking to.
> 
> This is a great example on the fundamental problem with Xen, or rather
> the approach that Xen has taken of grabbing random kernel internals and
> claiming them as APIs (or, in some cases even as ABIs.)  A lot of these

I am _not_ claiming that. If I left you with that impression from my
responses - my fault for not getting my point across (the sleep deprevation
is probably not helping either).

I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST
remain the same from now on. No. I am saying that the driver will be
changed lock-step as Tony and Boris see fit in changing the functions.

And currently the way the existing MCE drivers do this - is by using
mce_log. This driver does is too - since the in-tree drivers do it this way.
When they change to use a different mechanism - this driver will as well.

> have had problems that are now very nearly unfixable, and that has
> seriously stalled out the ability of evolve the Linux kernel in some
> areas.  Note that the cost of this is borne by the development
> community, not by the Xen maintainers.

The ones I know that you are unhappy about are the MMU paravirt interfaces
and I did mention to you that once some prototype work is done and
it showed success, I will work on removing said support.

Why don't you send me your unhappy list so that is on my radar as well please?

> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMl7-0005w9-2S; Mon, 23 Apr 2012 17:09:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMl5-0005w2-2L
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:09:03 +0000
Received: from [193.109.254.147:17386] by server-1.bemta-14.messagelabs.com id
	23/92-29372-EAC859F4; Mon, 23 Apr 2012 17:09:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335200940!5916146!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29337 invoked from network); 23 Apr 2012 17:09:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:09:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NH8YAN022322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 17:08:37 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NH8X48020545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 17:08:34 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NH8Wxs005807; Mon, 23 Apr 2012 12:08:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 10:08:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 10E584032D; Mon, 23 Apr 2012 13:03:28 -0400 (EDT)
Date: Mon, 23 Apr 2012 13:03:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120423170327.GC22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<4F958098.1050402@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F958098.1050402@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "Luck, Tony" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote:
> On 04/23/2012 08:27 AM, Luck, Tony wrote:
> >> Because, if you'd hooked into it, just imagine one fine day, when we
> >> remove mcelog support, what screaming the xen people will be doing when
> >> mcelog doesn't work anymore.
> > 
> > Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
> > fields could be added) ... and you don't want to have your hypervisor to
> > have to know which version of Linux it is talking to.
> 
> This is a great example on the fundamental problem with Xen, or rather
> the approach that Xen has taken of grabbing random kernel internals and
> claiming them as APIs (or, in some cases even as ABIs.)  A lot of these

I am _not_ claiming that. If I left you with that impression from my
responses - my fault for not getting my point across (the sleep deprevation
is probably not helping either).

I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST
remain the same from now on. No. I am saying that the driver will be
changed lock-step as Tony and Boris see fit in changing the functions.

And currently the way the existing MCE drivers do this - is by using
mce_log. This driver does is too - since the in-tree drivers do it this way.
When they change to use a different mechanism - this driver will as well.

> have had problems that are now very nearly unfixable, and that has
> seriously stalled out the ability of evolve the Linux kernel in some
> areas.  Note that the cost of this is borne by the development
> community, not by the Xen maintainers.

The ones I know that you are unhappy about are the MMU paravirt interfaces
and I did mention to you that once some prototype work is done and
it showed success, I will work on removing said support.

Why don't you send me your unhappy list so that is on my radar as well please?

> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:10:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMmb-000643-Hz; Mon, 23 Apr 2012 17:10:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMma-00063g-4U
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:10:36 +0000
Received: from [85.158.139.83:50028] by server-11.bemta-5.messagelabs.com id
	49/7C-12959-B0D859F4; Mon, 23 Apr 2012 17:10:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335201033!24441371!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2NjA2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8681 invoked from network); 23 Apr 2012 17:10:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:10:34 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NHADCl010106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 17:10:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NHACM7023433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 17:10:13 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NHACXl016523; Mon, 23 Apr 2012 12:10:12 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 10:10:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F04264032D; Mon, 23 Apr 2012 13:05:07 -0400 (EDT)
Date: Mon, 23 Apr 2012 13:05:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120423170507.GD22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
	<4F9582C2.6020009@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9582C2.6020009@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "Luck, Tony" <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 09:26:42AM -0700, H. Peter Anvin wrote:
> On 04/23/2012 08:43 AM, Liu, Jinsong wrote:
> > 
> > and, hypervisor only record error into its mc_info cookie (in its
> > own format), it doesn't care what's dom0's version and how dom0 translate it
> > -- that's dom0's business. The role of hypervisor is virtual 'platform',
> > just like h/w platform don't care what linux version runs over it.
> > 
> 
> And this is the *OTHER* problem with Xen.  A platform is only a platform
> if it is documented.  There are a number of PV hypervisors which *are*
> documented in detail, but Xen is not one of them.

And slowly we are working on that. As I mentioned to you, we are in process
of documenting those calls so that there is a document similar to an SDM.
It takes time though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:10:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMmb-000643-Hz; Mon, 23 Apr 2012 17:10:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMma-00063g-4U
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:10:36 +0000
Received: from [85.158.139.83:50028] by server-11.bemta-5.messagelabs.com id
	49/7C-12959-B0D859F4; Mon, 23 Apr 2012 17:10:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335201033!24441371!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg2NjA2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8681 invoked from network); 23 Apr 2012 17:10:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:10:34 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NHADCl010106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 17:10:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NHACM7023433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 17:10:13 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NHACXl016523; Mon, 23 Apr 2012 12:10:12 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 10:10:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F04264032D; Mon, 23 Apr 2012 13:05:07 -0400 (EDT)
Date: Mon, 23 Apr 2012 13:05:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120423170507.GD22364@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
	<4F9582C2.6020009@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9582C2.6020009@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "Luck, Tony" <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 09:26:42AM -0700, H. Peter Anvin wrote:
> On 04/23/2012 08:43 AM, Liu, Jinsong wrote:
> > 
> > and, hypervisor only record error into its mc_info cookie (in its
> > own format), it doesn't care what's dom0's version and how dom0 translate it
> > -- that's dom0's business. The role of hypervisor is virtual 'platform',
> > just like h/w platform don't care what linux version runs over it.
> > 
> 
> And this is the *OTHER* problem with Xen.  A platform is only a platform
> if it is documented.  There are a number of PV hypervisors which *are*
> documented in detail, but Xen is not one of them.

And slowly we are working on that. As I mentioned to you, we are in process
of documenting those calls so that there is a document similar to an SDM.
It takes time though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:16:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:16:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMs7-0006PB-FT; Mon, 23 Apr 2012 17:16:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMs6-0006Os-JN
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 17:16:18 +0000
Received: from [85.158.138.51:45023] by server-10.bemta-3.messagelabs.com id
	2D/32-29478-06E859F4; Mon, 23 Apr 2012 17:16:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335201374!23379647!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18013 invoked from network); 23 Apr 2012 17:16:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 17:16:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NHGAJp032111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 17:16:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NHG9MD006646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 17:16:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NHGAwh014409; Mon, 23 Apr 2012 12:16:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 10:16:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EA11A4032D; Mon, 23 Apr 2012 13:11:04 -0400 (EDT)
Date: Mon, 23 Apr 2012 13:11:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120423171104.GA24378@phenom.dumpdata.com>
References: <4F9199E5.5080409@xen.org>
	<1335171236.30700.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335171236.30700.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-API] [XenARM] IMPORTANT: Changes to XenSummit
 Format : Please vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 09:53:56AM +0100, Ian Campbell wrote:
> On Fri, 2012-04-20 at 18:16 +0100, Lars Kurth wrote:
> > Hi everybody,
> > 
> > I have been talking to a number of the key contributors to the project 
> > regarding XenSummit and got feedback on the format of XenSummit. Please 
> > read, if you are active in the community and DO VOTE!
> > 
> > Cheers
> > Lars
> > 
> > Change of date in CFP!
> > ======================
> > First I wanted to annouce that we are extending the CFP from May 1st to 
> > 15th of June. Key community members felt that May 1 is too early. In 
> > particular because we have closed the CFP 5-6 weeks before the event in 
> > the past. Due to contractual issues June 15th is the last day we can do 
> > though.
> > 
> > Proposal! PLEASE READ!
> > ======================
> > A number of vendors felt we should change the format of XenSummit to be 
> > more like the Linux Kernel Summit. I.e.
> > a) An invite only event for the top 20-30 developers of the project
> > b) The main focus would be around finding technical solutions and making 
> > decisions
> 
> IMHO this sort of event would make a great addition to the XenSummit
> program rather than a replacement for it. i.e. a single day before the
> main event (which remains two days).
> 
> > I can see the merit of this, but it is too late to do this for all of 
> > XenSummit due to event contracts that havce been signed.
> >
> > However we have a number of options, moving towards this:
> > 1) Start half a day early and have an invite only XenDev Event event on 
> > Sunday afteroon
> > 2) Cut XenSummit short by 1/2 day and append the XenDev event. This may 
> > incur some financial penalties for Xen.org and the overall ticket cost 
> > may have to be higher than in the past.
> > 3) Do the invite only meeting in parallel with XenSummit. I have an 
> > additional large room on TUE the 27th, which we could use for this and I 
> > also have two break-out rooms and can allocate one of them to the XenDev 
> > event (these were intended for people sitting together and hacking on 
> > stuff and/or BoFs). There are several options: hold the XenDev event on
> > 3.1) 26th afternoon
> > 3.2) 27th morning
> > 3.3) 27th afternoon
> > 
> > In my view option 1) and 3.1) have the advantage that we can report back 
> > to XenSummit, that nobody will miss key talks and that people can sit 
> > together in the break-out rooms.
> > 
> > Vote
> > ====
> > Please vote by providing. Vote closes by the 27th. Vote by replying to 
> > this mail with ...
> > -1: none of the above (i.e. I dont want a XenDev event)
> > +1 for a DevMeeting on sunday (aka for proposal 1)
> > +1 for cutting XenSummit short (aka for proposal 2)
> > +1 for parallel 26th PM (aka proposal 3.1)
> > +1 for parallel 27th AM (aka proposal 3.2)
> > +1 for parallel 27th PM (aka proposal 3.3)
> 
> Family commitments prevent me attending this year so I'll abstain on the
> specifics of the date this time around and vote on the general
> principal:
> +1 for a XenDev event to precede each XenSummit

+1 for that. Even if it means just hitting the local <favorite coffeeshop>
if the crowd is small.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:16:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:16:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMs7-0006PB-FT; Mon, 23 Apr 2012 17:16:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMMs6-0006Os-JN
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 17:16:18 +0000
Received: from [85.158.138.51:45023] by server-10.bemta-3.messagelabs.com id
	2D/32-29478-06E859F4; Mon, 23 Apr 2012 17:16:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335201374!23379647!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4ODE2Nw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18013 invoked from network); 23 Apr 2012 17:16:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Apr 2012 17:16:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3NHGAJp032111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Apr 2012 17:16:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3NHG9MD006646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Apr 2012 17:16:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3NHGAwh014409; Mon, 23 Apr 2012 12:16:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 10:16:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EA11A4032D; Mon, 23 Apr 2012 13:11:04 -0400 (EDT)
Date: Mon, 23 Apr 2012 13:11:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120423171104.GA24378@phenom.dumpdata.com>
References: <4F9199E5.5080409@xen.org>
	<1335171236.30700.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335171236.30700.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-API] [XenARM] IMPORTANT: Changes to XenSummit
 Format : Please vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 09:53:56AM +0100, Ian Campbell wrote:
> On Fri, 2012-04-20 at 18:16 +0100, Lars Kurth wrote:
> > Hi everybody,
> > 
> > I have been talking to a number of the key contributors to the project 
> > regarding XenSummit and got feedback on the format of XenSummit. Please 
> > read, if you are active in the community and DO VOTE!
> > 
> > Cheers
> > Lars
> > 
> > Change of date in CFP!
> > ======================
> > First I wanted to annouce that we are extending the CFP from May 1st to 
> > 15th of June. Key community members felt that May 1 is too early. In 
> > particular because we have closed the CFP 5-6 weeks before the event in 
> > the past. Due to contractual issues June 15th is the last day we can do 
> > though.
> > 
> > Proposal! PLEASE READ!
> > ======================
> > A number of vendors felt we should change the format of XenSummit to be 
> > more like the Linux Kernel Summit. I.e.
> > a) An invite only event for the top 20-30 developers of the project
> > b) The main focus would be around finding technical solutions and making 
> > decisions
> 
> IMHO this sort of event would make a great addition to the XenSummit
> program rather than a replacement for it. i.e. a single day before the
> main event (which remains two days).
> 
> > I can see the merit of this, but it is too late to do this for all of 
> > XenSummit due to event contracts that havce been signed.
> >
> > However we have a number of options, moving towards this:
> > 1) Start half a day early and have an invite only XenDev Event event on 
> > Sunday afteroon
> > 2) Cut XenSummit short by 1/2 day and append the XenDev event. This may 
> > incur some financial penalties for Xen.org and the overall ticket cost 
> > may have to be higher than in the past.
> > 3) Do the invite only meeting in parallel with XenSummit. I have an 
> > additional large room on TUE the 27th, which we could use for this and I 
> > also have two break-out rooms and can allocate one of them to the XenDev 
> > event (these were intended for people sitting together and hacking on 
> > stuff and/or BoFs). There are several options: hold the XenDev event on
> > 3.1) 26th afternoon
> > 3.2) 27th morning
> > 3.3) 27th afternoon
> > 
> > In my view option 1) and 3.1) have the advantage that we can report back 
> > to XenSummit, that nobody will miss key talks and that people can sit 
> > together in the break-out rooms.
> > 
> > Vote
> > ====
> > Please vote by providing. Vote closes by the 27th. Vote by replying to 
> > this mail with ...
> > -1: none of the above (i.e. I dont want a XenDev event)
> > +1 for a DevMeeting on sunday (aka for proposal 1)
> > +1 for cutting XenSummit short (aka for proposal 2)
> > +1 for parallel 26th PM (aka proposal 3.1)
> > +1 for parallel 27th AM (aka proposal 3.2)
> > +1 for parallel 27th PM (aka proposal 3.3)
> 
> Family commitments prevent me attending this year so I'll abstain on the
> specifics of the date this time around and vote on the general
> principal:
> +1 for a XenDev event to precede each XenSummit

+1 for that. Even if it means just hitting the local <favorite coffeeshop>
if the crowd is small.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:19:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:19:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMuu-0006a4-3p; Mon, 23 Apr 2012 17:19:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMMur-0006Zu-RF
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:19:10 +0000
Received: from [85.158.138.51:40168] by server-9.bemta-3.messagelabs.com id
	F6/B5-26691-D0F859F4; Mon, 23 Apr 2012 17:19:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335201547!23428209!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMDcwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19529 invoked from network); 23 Apr 2012 17:19:08 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 17:19:08 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 4647D300095;
	Mon, 23 Apr 2012 10:18:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=p+8YYscySsG30na9gi5I5rohUqUd4TfxP0c6A+4Z8OzA
	SOXPlYADQAr/q4Mp+pRkwlyJQ93zp8oyw1qcdn4msJN7nKJkSuaeZvhgD58hf1I2
	V00ovSkZOls5Cooxh47+V3ec4aBIy/V9sWXXAH+H7/EkJQHzQRmsmCP4siLdB6E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=mKpYanWwgIZIpC8s9Ex5nzmQcVM=; b=B3HfSvk5
	JbZ4/6fjMnsI77e5nEdTEYGRhUU0gLxBLZ7nhyzaznbCGfBEtfq2s7IgbfF+lU8/
	sKNbFX3ZjxGgZYZ5XNjixaxEyVv7RVygeGOdmsdCOxlByWC3vwskDMATTGJYj2H/
	KY/O1Rjh1+uhz9+gPugXktUjU8abWrMAltc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 35413300080; 
	Mon, 23 Apr 2012 10:18:38 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Apr 2012 10:18:40 -0700
Message-ID: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120423091445.GA17920@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
Date: Mon, 23 Apr 2012 10:18:40 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
>> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
>> profiling data with 10 seconds:
>>
>> (XEN) p2m_lock 1 lock:
>> (XEN)   lock:      190733(00000000:14CE5726), block:
>> 67159(00000007:6AAA53F3)
>>
>> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
>> is waiting for the p2m lock. And those data only for idle guest. The
>> impaction is more seriously when run some workload inside guest.  I
>> noticed that this change was adding by cs 24770. And before it, we
>> don't require the p2m lock in _get_gfn_type_access. So is this lock
>> really necessary?
>
> Ugh; that certainly is a regression.  We used to be lock-free on p2m
> lookups and losing that will be bad for perf in lots of ways.  IIRC the
> original aim was to use fine-grained per-page locks for this -- there
> should be no need to hold a per-domain lock during a normal read.
> Andres, what happened to that code?

Sigh, scratch a lot of nonsense I just spewed on the "hpet gfn". No actual
page backing that one, no concerns.

Still is the case that ram_gpa is zero in many cases going into
hvmemul_do_io. There really is no point in doing a get_page(get_gfn(0)).
How about the following (there's more email after this patch):
# HG changeset patch
# Parent ccc64793187f7d9c926343a1cd4ae822a4364bd1
x86/emulation: No need to get_gfn on zero ram_gpa.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r ccc64793187f xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -60,33 +60,37 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    mfn_t ram_mfn = _mfn(INVALID_MFN);
     int rc;

-    /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
-    if ( p2m_is_paging(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn);
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
-        return X86EMUL_RETRY;
-    }
-    if ( p2m_is_shared(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn);
-        return X86EMUL_RETRY;
-    }
-
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
+    /* Many callers pass a stub zero ram_gpa addresses. */
+    if ( ram_gfn != 0 )
+    {
+        /* Check for paged out page */
+        ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+        if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, ram_gfn);
+            put_gfn(curr->domain, ram_gfn);
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
             return X86EMUL_RETRY;
         }
-    put_gfn(curr->domain, ram_gfn);
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(curr->domain, ram_gfn);
+            return X86EMUL_RETRY;
+        }
+
+        /* Maintain a ref on the mfn to ensure liveness. Put the gfn
+         * to avoid potential deadlock wrt event channel lock, later. */
+        if ( mfn_valid(mfn_x(ram_mfn)) )
+            if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
+                 curr->domain) )
+            {
+                put_gfn(curr->domain, ram_gfn);
+                return X86EMUL_RETRY;
+            }
+        put_gfn(curr->domain, ram_gfn);
+    }

     /*
      * Weird-sized accesses have undefined behaviour: we discard writes


If contention is coming in from the emul_rep_movs path, then that might be
taken care of with the following:
# HG changeset patch
# Parent 18b694840961cb6e3934628b23902a7979f00bac
x86/emulate: Relieve contention of p2m lock in emulation of rep movs.

get_two_gfns is used to query the source and target physical addresses of the
emulated rep movs. It is not necessary to hold onto the two gfn's for the
duration of the emulation: further calls down the line will do the
appropriate
unsahring or paging in, and unwind correctly on failure.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 18b694840961 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -714,25 +714,23 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;

+    /* The query on the gfns is to establish the need for mmio. In the
two mmio
+     * cases, a proper get_gfn for the "other" gfn will be enacted, with
paging in
+     * or unsharing if necessary. In the memmove case, the gfn might
change given
+     * the bytes mov'ed, and, again, proper get_gfn's will be enacted in
+     * __hvm_copy. */
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
                  P2M_ALLOC, &tg);
-
+    put_two_gfns(&tg);
+
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }

     if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }

     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa,
bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +745,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }

     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +754,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this
fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }

     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +765,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);

     xfree(buf);
-    put_two_gfns(&tg);

     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;


Let me know if any of this helps
Thanks,
Andres

>
> Making it an rwlock would be tricky as this interface doesn't
> differenctiate readers from writers.  For the common case (no
> sharing/paging/mem-access) it ought to be a win since there is hardly
> any writing.  But it would be better to make this particular lock/unlock
> go away.
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:19:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:19:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMuu-0006a4-3p; Mon, 23 Apr 2012 17:19:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMMur-0006Zu-RF
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:19:10 +0000
Received: from [85.158.138.51:40168] by server-9.bemta-3.messagelabs.com id
	F6/B5-26691-D0F859F4; Mon, 23 Apr 2012 17:19:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335201547!23428209!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMDcwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19529 invoked from network); 23 Apr 2012 17:19:08 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 17:19:08 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 4647D300095;
	Mon, 23 Apr 2012 10:18:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=p+8YYscySsG30na9gi5I5rohUqUd4TfxP0c6A+4Z8OzA
	SOXPlYADQAr/q4Mp+pRkwlyJQ93zp8oyw1qcdn4msJN7nKJkSuaeZvhgD58hf1I2
	V00ovSkZOls5Cooxh47+V3ec4aBIy/V9sWXXAH+H7/EkJQHzQRmsmCP4siLdB6E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=mKpYanWwgIZIpC8s9Ex5nzmQcVM=; b=B3HfSvk5
	JbZ4/6fjMnsI77e5nEdTEYGRhUU0gLxBLZ7nhyzaznbCGfBEtfq2s7IgbfF+lU8/
	sKNbFX3ZjxGgZYZ5XNjixaxEyVv7RVygeGOdmsdCOxlByWC3vwskDMATTGJYj2H/
	KY/O1Rjh1+uhz9+gPugXktUjU8abWrMAltc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 35413300080; 
	Mon, 23 Apr 2012 10:18:38 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Apr 2012 10:18:40 -0700
Message-ID: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120423091445.GA17920@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
Date: Mon, 23 Apr 2012 10:18:40 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
>> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
>> profiling data with 10 seconds:
>>
>> (XEN) p2m_lock 1 lock:
>> (XEN)   lock:      190733(00000000:14CE5726), block:
>> 67159(00000007:6AAA53F3)
>>
>> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
>> is waiting for the p2m lock. And those data only for idle guest. The
>> impaction is more seriously when run some workload inside guest.  I
>> noticed that this change was adding by cs 24770. And before it, we
>> don't require the p2m lock in _get_gfn_type_access. So is this lock
>> really necessary?
>
> Ugh; that certainly is a regression.  We used to be lock-free on p2m
> lookups and losing that will be bad for perf in lots of ways.  IIRC the
> original aim was to use fine-grained per-page locks for this -- there
> should be no need to hold a per-domain lock during a normal read.
> Andres, what happened to that code?

Sigh, scratch a lot of nonsense I just spewed on the "hpet gfn". No actual
page backing that one, no concerns.

Still is the case that ram_gpa is zero in many cases going into
hvmemul_do_io. There really is no point in doing a get_page(get_gfn(0)).
How about the following (there's more email after this patch):
# HG changeset patch
# Parent ccc64793187f7d9c926343a1cd4ae822a4364bd1
x86/emulation: No need to get_gfn on zero ram_gpa.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r ccc64793187f xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -60,33 +60,37 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    mfn_t ram_mfn = _mfn(INVALID_MFN);
     int rc;

-    /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
-    if ( p2m_is_paging(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn);
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
-        return X86EMUL_RETRY;
-    }
-    if ( p2m_is_shared(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn);
-        return X86EMUL_RETRY;
-    }
-
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
+    /* Many callers pass a stub zero ram_gpa addresses. */
+    if ( ram_gfn != 0 )
+    {
+        /* Check for paged out page */
+        ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+        if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, ram_gfn);
+            put_gfn(curr->domain, ram_gfn);
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
             return X86EMUL_RETRY;
         }
-    put_gfn(curr->domain, ram_gfn);
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(curr->domain, ram_gfn);
+            return X86EMUL_RETRY;
+        }
+
+        /* Maintain a ref on the mfn to ensure liveness. Put the gfn
+         * to avoid potential deadlock wrt event channel lock, later. */
+        if ( mfn_valid(mfn_x(ram_mfn)) )
+            if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
+                 curr->domain) )
+            {
+                put_gfn(curr->domain, ram_gfn);
+                return X86EMUL_RETRY;
+            }
+        put_gfn(curr->domain, ram_gfn);
+    }

     /*
      * Weird-sized accesses have undefined behaviour: we discard writes


If contention is coming in from the emul_rep_movs path, then that might be
taken care of with the following:
# HG changeset patch
# Parent 18b694840961cb6e3934628b23902a7979f00bac
x86/emulate: Relieve contention of p2m lock in emulation of rep movs.

get_two_gfns is used to query the source and target physical addresses of the
emulated rep movs. It is not necessary to hold onto the two gfn's for the
duration of the emulation: further calls down the line will do the
appropriate
unsahring or paging in, and unwind correctly on failure.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 18b694840961 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -714,25 +714,23 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;

+    /* The query on the gfns is to establish the need for mmio. In the
two mmio
+     * cases, a proper get_gfn for the "other" gfn will be enacted, with
paging in
+     * or unsharing if necessary. In the memmove case, the gfn might
change given
+     * the bytes mov'ed, and, again, proper get_gfn's will be enacted in
+     * __hvm_copy. */
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
                  P2M_ALLOC, &tg);
-
+    put_two_gfns(&tg);
+
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }

     if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }

     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa,
bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +745,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }

     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +754,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this
fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }

     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +765,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);

     xfree(buf);
-    put_two_gfns(&tg);

     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;


Let me know if any of this helps
Thanks,
Andres

>
> Making it an rwlock would be tricky as this interface doesn't
> differenctiate readers from writers.  For the common case (no
> sharing/paging/mem-access) it ought to be a win since there is hardly
> any writing.  But it would be better to make this particular lock/unlock
> go away.
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMuw-0006aO-G4; Mon, 23 Apr 2012 17:19:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMMuv-0006aG-Kp
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:19:13 +0000
Received: from [193.109.254.147:7252] by server-12.bemta-14.messagelabs.com id
	98/A4-05898-01F859F4; Mon, 23 Apr 2012 17:19:12 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335201550!5894541!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18824 invoked from network); 23 Apr 2012 17:19:11 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:19:11 -0000
Received: from [22.173.189.117] (mf30536d0.tmodns.net [208.54.5.243])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NHIq8W010808
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 23 Apr 2012 10:18:56 -0700
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<4F958098.1050402@zytor.com>
	<20120423170327.GC22364@phenom.dumpdata.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <20120423170327.GC22364@phenom.dumpdata.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 23 Apr 2012 10:16:16 -0700
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <45d73970-bf49-4695-8fe6-6f3c19e1097f@email.android.com>
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "Luck, Tony" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My biggest beefs are page table manipulation, all the extra ugliness in kernel entry and exit, and lack of clear initialization semantics.  Additionally, any pvop which has unclear semantics - especially anything which is a nop on native and has zero documentation.

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

>On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote:
>> On 04/23/2012 08:27 AM, Luck, Tony wrote:
>> >> Because, if you'd hooked into it, just imagine one fine day, when
>we
>> >> remove mcelog support, what screaming the xen people will be doing
>when
>> >> mcelog doesn't work anymore.
>> > 
>> > Agreed. Even before we get to deleting mcelog, "struct mce" can
>change (new
>> > fields could be added) ... and you don't want to have your
>hypervisor to
>> > have to know which version of Linux it is talking to.
>> 
>> This is a great example on the fundamental problem with Xen, or
>rather
>> the approach that Xen has taken of grabbing random kernel internals
>and
>> claiming them as APIs (or, in some cases even as ABIs.)  A lot of
>these
>
>I am _not_ claiming that. If I left you with that impression from my
>responses - my fault for not getting my point across (the sleep
>deprevation
>is probably not helping either).
>
>I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST
>remain the same from now on. No. I am saying that the driver will be
>changed lock-step as Tony and Boris see fit in changing the functions.
>
>And currently the way the existing MCE drivers do this - is by using
>mce_log. This driver does is too - since the in-tree drivers do it this
>way.
>When they change to use a different mechanism - this driver will as
>well.
>
>> have had problems that are now very nearly unfixable, and that has
>> seriously stalled out the ability of evolve the Linux kernel in some
>> areas.  Note that the cost of this is borne by the development
>> community, not by the Xen maintainers.
>
>The ones I know that you are unhappy about are the MMU paravirt
>interfaces
>and I did mention to you that once some prototype work is done and
>it showed success, I will work on removing said support.
>
>Why don't you send me your unhappy list so that is on my radar as well
>please?
>
>> 
>> 	-hpa
>> 
>> -- 
>> H. Peter Anvin, Intel Open Source Technology Center
>> I work for Intel.  I don't speak on their behalf.
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMMuw-0006aO-G4; Mon, 23 Apr 2012 17:19:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMMuv-0006aG-Kp
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:19:13 +0000
Received: from [193.109.254.147:7252] by server-12.bemta-14.messagelabs.com id
	98/A4-05898-01F859F4; Mon, 23 Apr 2012 17:19:12 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335201550!5894541!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18824 invoked from network); 23 Apr 2012 17:19:11 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:19:11 -0000
Received: from [22.173.189.117] (mf30536d0.tmodns.net [208.54.5.243])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NHIq8W010808
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 23 Apr 2012 10:18:56 -0700
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<4F958098.1050402@zytor.com>
	<20120423170327.GC22364@phenom.dumpdata.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <20120423170327.GC22364@phenom.dumpdata.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 23 Apr 2012 10:16:16 -0700
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <45d73970-bf49-4695-8fe6-6f3c19e1097f@email.android.com>
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "Luck, Tony" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My biggest beefs are page table manipulation, all the extra ugliness in kernel entry and exit, and lack of clear initialization semantics.  Additionally, any pvop which has unclear semantics - especially anything which is a nop on native and has zero documentation.

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

>On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote:
>> On 04/23/2012 08:27 AM, Luck, Tony wrote:
>> >> Because, if you'd hooked into it, just imagine one fine day, when
>we
>> >> remove mcelog support, what screaming the xen people will be doing
>when
>> >> mcelog doesn't work anymore.
>> > 
>> > Agreed. Even before we get to deleting mcelog, "struct mce" can
>change (new
>> > fields could be added) ... and you don't want to have your
>hypervisor to
>> > have to know which version of Linux it is talking to.
>> 
>> This is a great example on the fundamental problem with Xen, or
>rather
>> the approach that Xen has taken of grabbing random kernel internals
>and
>> claiming them as APIs (or, in some cases even as ABIs.)  A lot of
>these
>
>I am _not_ claiming that. If I left you with that impression from my
>responses - my fault for not getting my point across (the sleep
>deprevation
>is probably not helping either).
>
>I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST
>remain the same from now on. No. I am saying that the driver will be
>changed lock-step as Tony and Boris see fit in changing the functions.
>
>And currently the way the existing MCE drivers do this - is by using
>mce_log. This driver does is too - since the in-tree drivers do it this
>way.
>When they change to use a different mechanism - this driver will as
>well.
>
>> have had problems that are now very nearly unfixable, and that has
>> seriously stalled out the ability of evolve the Linux kernel in some
>> areas.  Note that the cost of this is borne by the development
>> community, not by the Xen maintainers.
>
>The ones I know that you are unhappy about are the MMU paravirt
>interfaces
>and I did mention to you that once some prototype work is done and
>it showed success, I will work on removing said support.
>
>Why don't you send me your unhappy list so that is on my radar as well
>please?
>
>> 
>> 	-hpa
>> 
>> -- 
>> H. Peter Anvin, Intel Open Source Technology Center
>> I work for Intel.  I don't speak on their behalf.
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:25:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN0b-0006x2-Hd; Mon, 23 Apr 2012 17:25:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMN0a-0006wx-0I
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:25:04 +0000
Received: from [193.109.254.147:52328] by server-5.bemta-14.messagelabs.com id
	C5/1F-30733-F60959F4; Mon, 23 Apr 2012 17:25:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335201902!731147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28018 invoked from network); 23 Apr 2012 17:25:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:25:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:25:01 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMN0X-0003yF-PJ;
	Mon, 23 Apr 2012 17:25:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMN0X-0003V3-Ni;
	Mon, 23 Apr 2012 18:25:01 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12739-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Apr 2012 18:25:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12739: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12739 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12739/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:25:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN0b-0006x2-Hd; Mon, 23 Apr 2012 17:25:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMN0a-0006wx-0I
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:25:04 +0000
Received: from [193.109.254.147:52328] by server-5.bemta-14.messagelabs.com id
	C5/1F-30733-F60959F4; Mon, 23 Apr 2012 17:25:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335201902!731147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28018 invoked from network); 23 Apr 2012 17:25:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:25:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:25:01 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMN0X-0003yF-PJ;
	Mon, 23 Apr 2012 17:25:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMN0X-0003V3-Ni;
	Mon, 23 Apr 2012 18:25:01 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12739-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Apr 2012 18:25:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12739: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12739 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12739/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl            5 xen-boot                     fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN1q-00070y-0i; Mon, 23 Apr 2012 17:26:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMN1o-00070j-FT
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:26:20 +0000
Received: from [85.158.139.83:32442] by server-9.bemta-5.messagelabs.com id
	C9/4A-09826-BB0959F4; Mon, 23 Apr 2012 17:26:19 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335201976!24442862!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9110 invoked from network); 23 Apr 2012 17:26:18 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:26:18 -0000
Received: from [22.173.189.117] (mf30536d0.tmodns.net [208.54.5.243])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NHPebW013019
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 23 Apr 2012 10:26:04 -0700
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
	<4F9582C2.6020009@zytor.com>
	<20120423170507.GD22364@phenom.dumpdata.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <20120423170507.GD22364@phenom.dumpdata.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 23 Apr 2012 10:23:55 -0700
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <f6e39d21-e5d9-4558-b3a4-11437b664951@email.android.com>
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "Luck, Tony" <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I know.  It is very frustrating to me that this comes now rather than before Xen was merged, but changing the past is hard.  At least you are trying to fix it.

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

>On Mon, Apr 23, 2012 at 09:26:42AM -0700, H. Peter Anvin wrote:
>> On 04/23/2012 08:43 AM, Liu, Jinsong wrote:
>> > 
>> > and, hypervisor only record error into its mc_info cookie (in its
>> > own format), it doesn't care what's dom0's version and how dom0
>translate it
>> > -- that's dom0's business. The role of hypervisor is virtual
>'platform',
>> > just like h/w platform don't care what linux version runs over it.
>> > 
>> 
>> And this is the *OTHER* problem with Xen.  A platform is only a
>platform
>> if it is documented.  There are a number of PV hypervisors which
>*are*
>> documented in detail, but Xen is not one of them.
>
>And slowly we are working on that. As I mentioned to you, we are in
>process
>of documenting those calls so that there is a document similar to an
>SDM.
>It takes time though.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN1q-00070y-0i; Mon, 23 Apr 2012 17:26:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1SMN1o-00070j-FT
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:26:20 +0000
Received: from [85.158.139.83:32442] by server-9.bemta-5.messagelabs.com id
	C9/4A-09826-BB0959F4; Mon, 23 Apr 2012 17:26:19 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335201976!24442862!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9110 invoked from network); 23 Apr 2012 17:26:18 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 17:26:18 -0000
Received: from [22.173.189.117] (mf30536d0.tmodns.net [208.54.5.243])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q3NHPebW013019
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 23 Apr 2012 10:26:04 -0700
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<3908561D78D1C84285E8C5FCA982C28F170EF841@ORSMSX104.amr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335168D26@SHSMSX101.ccr.corp.intel.com>
	<4F9582C2.6020009@zytor.com>
	<20120423170507.GD22364@phenom.dumpdata.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <20120423170507.GD22364@phenom.dumpdata.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 23 Apr 2012 10:23:55 -0700
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <f6e39d21-e5d9-4558-b3a4-11437b664951@email.android.com>
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, "Luck, Tony" <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I know.  It is very frustrating to me that this comes now rather than before Xen was merged, but changing the past is hard.  At least you are trying to fix it.

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

>On Mon, Apr 23, 2012 at 09:26:42AM -0700, H. Peter Anvin wrote:
>> On 04/23/2012 08:43 AM, Liu, Jinsong wrote:
>> > 
>> > and, hypervisor only record error into its mc_info cookie (in its
>> > own format), it doesn't care what's dom0's version and how dom0
>translate it
>> > -- that's dom0's business. The role of hypervisor is virtual
>'platform',
>> > just like h/w platform don't care what linux version runs over it.
>> > 
>> 
>> And this is the *OTHER* problem with Xen.  A platform is only a
>platform
>> if it is documented.  There are a number of PV hypervisors which
>*are*
>> documented in detail, but Xen is not one of them.
>
>And slowly we are working on that. As I mentioned to you, we are in
>process
>of documenting those calls so that there is a document similar to an
>SDM.
>It takes time though.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:34:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN9f-0007Hx-0L; Mon, 23 Apr 2012 17:34:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMN9e-0007Hs-AJ
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:34:26 +0000
Received: from [85.158.143.99:37835] by server-1.bemta-4.messagelabs.com id
	88/5A-20925-1A2959F4; Mon, 23 Apr 2012 17:34:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335202465!24365085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8289 invoked from network); 23 Apr 2012 17:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:34:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:34:24 +0100
Date: Mon, 23 Apr 2012 18:40:20 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334930892.28331.95.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231618590.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
	<1334930892.28331.95.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Campbell wrote:
> On Fri, 2012-04-20 at 15:04 +0100, Stefano Stabellini wrote:
> > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > > > Introduce a blkdev_start in xl.conf and pass it to
> > > > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > > > libxl__device_disk_local_attach.
> > > 
> > > Surely this should be passed in the domain config structure rather
> > > than being an adhoc parameter.
> > 
> > I don't think so, see below.
> > 
> > > If the problem with that is that it really ought to be host-global and
> > > come from xl.conf, then perhaps we need another config struct.  But
> > > really I think that's overkill.  There is nothing wrong with taking
> > > parameters from xl.conf and putting them in the libxl domain config.
> >  
> > Another host-global config struct is definitely overkill, but we cannot
> > really pass this parameter in the libxl domain config, because this
> > option has nothing to do with the domain config.
> > It would be confusing and incorrect.
> 
> You could argue that "domain config" was actually as much about details
> on how to build the guest as it was about the "domain config" as such.
> Members of that struct like the device model version, xsm ssid, disable
> migrate, cpupool id, etc could all be argued to fit into the same "grey
> area".

What about a new libxl_domain_build_info parameter?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:34:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN9f-0007Hx-0L; Mon, 23 Apr 2012 17:34:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMN9e-0007Hs-AJ
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:34:26 +0000
Received: from [85.158.143.99:37835] by server-1.bemta-4.messagelabs.com id
	88/5A-20925-1A2959F4; Mon, 23 Apr 2012 17:34:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335202465!24365085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8289 invoked from network); 23 Apr 2012 17:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:34:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:34:24 +0100
Date: Mon, 23 Apr 2012 18:40:20 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1334930892.28331.95.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231618590.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
	<1334930892.28331.95.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Campbell wrote:
> On Fri, 2012-04-20 at 15:04 +0100, Stefano Stabellini wrote:
> > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > > > Introduce a blkdev_start in xl.conf and pass it to
> > > > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > > > libxl__device_disk_local_attach.
> > > 
> > > Surely this should be passed in the domain config structure rather
> > > than being an adhoc parameter.
> > 
> > I don't think so, see below.
> > 
> > > If the problem with that is that it really ought to be host-global and
> > > come from xl.conf, then perhaps we need another config struct.  But
> > > really I think that's overkill.  There is nothing wrong with taking
> > > parameters from xl.conf and putting them in the libxl domain config.
> >  
> > Another host-global config struct is definitely overkill, but we cannot
> > really pass this parameter in the libxl domain config, because this
> > option has nothing to do with the domain config.
> > It would be confusing and incorrect.
> 
> You could argue that "domain config" was actually as much about details
> on how to build the guest as it was about the "domain config" as such.
> Members of that struct like the device model version, xsm ssid, disable
> migrate, cpupool id, etc could all be argued to fit into the same "grey
> area".

What about a new libxl_domain_build_info parameter?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:34:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN9w-0007J0-E9; Mon, 23 Apr 2012 17:34:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMN9v-0007Iq-DO
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:34:43 +0000
Received: from [85.158.143.35:35252] by server-1.bemta-4.messagelabs.com id
	CA/8A-20925-2B2959F4; Mon, 23 Apr 2012 17:34:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335202482!13740326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY3MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17223 invoked from network); 23 Apr 2012 17:34:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:34:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:34:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:34:41 +0100
Date: Mon, 23 Apr 2012 18:40:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20369.29355.670145.159299@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231720110.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44544.739441.639648@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
	<20369.29355.670145.159299@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > > > +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> > > > +        if (libxl__xs_read(gc, t,
> > > > +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> > > > +                        dompath, devid)) == NULL)
> > > > +            return libxl__devid_to_vdev(gc, devid);
> > > 
> > > What if the error is not ENOENT ?
> > 
> > we should return NULL
> 
> I don't think that's correct.  If, say, the error is EACCES, then the
> domain creation should be aborted with a message about that, since the
> system has been installed incorrectly.
> 
> Compare this situation with the recent pygrub failure, where
> libfsimage+pygrub turned all errors of the form "something went wrong
> loading this plugin" into "the kernel was not found"; so when a
> completely empty .so was loaded as a plugin the result was not "OMG
> WTF this is totally broken" but "sorry can't find your kernel in this
> filesystem" (when really the problem is that pygrub+libfsimage knew
> that the filesystem was one they were supposed to support but the
> plugin for it was utterly broken).
> 
> This reminds me of our other recent discussion about error handling,
> of receiving unexpected toolstack migration info.  In general any
> unanticipated situation should be treated as a fatal error.  Only
> anticipated situations should result in the software continuing in a
> degraded manner.

NULL is an abort condition and libxl__device_disk_local_attach prints a
useful message.


> > > > +static char *encode_disk_name(char *ptr, unsigned int n)
> > > 
> > > There is no clearly defined upper bound on the buffer space needed by
> > > this function.
> > 
> > I know but this function is used as is in Linux where the stack is
> > even smaller. I'll add an upper bound anyway.
> 
> At the very least a comment is needed to demonstrate that it's
> correct, but a bound in the code would be better.  (Also I'm surprised
> that you chose a recursive rather than iterative implementation of a
> what is a base conversion routine...)

OK

> > > > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> > > > index 9e0ed6d..c8977ac 100644
> > > > --- a/tools/libxl/libxl_netbsd.c
> > > > +++ b/tools/libxl/libxl_netbsd.c
> > > ...
> > > > +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> > > > +{
> > > > +    /* TODO */
> > > > +    return NULL;
> > > > +}
> > > 
> > > I guess this is going to be fixed in a future version of the patch ?
> > 
> > I don't think so: I don't know anything about netbsd and local_attach
> > doesn't work there anyway.
> 
> What is the error behaviour if NULL is returned here ?  I forget the
> rest of the patch, but once again we should make sure that we abort if
> this situation occurs.

NULL is returned by libxl__alloc_vdev, then it is the same as before:
eventually the domain creation terminates with an fatal error.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:34:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMN9w-0007J0-E9; Mon, 23 Apr 2012 17:34:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMN9v-0007Iq-DO
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:34:43 +0000
Received: from [85.158.143.35:35252] by server-1.bemta-4.messagelabs.com id
	CA/8A-20925-2B2959F4; Mon, 23 Apr 2012 17:34:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335202482!13740326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY3MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17223 invoked from network); 23 Apr 2012 17:34:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:34:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:34:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:34:41 +0100
Date: Mon, 23 Apr 2012 18:40:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20369.29355.670145.159299@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231720110.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44544.739441.639648@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201505500.26786@kaball-desktop>
	<20369.29355.670145.159299@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 5/7] libxl: introduce libxl__alloc_vdev"):
> > > > +        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
> > > > +        if (libxl__xs_read(gc, t,
> > > > +                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
> > > > +                        dompath, devid)) == NULL)
> > > > +            return libxl__devid_to_vdev(gc, devid);
> > > 
> > > What if the error is not ENOENT ?
> > 
> > we should return NULL
> 
> I don't think that's correct.  If, say, the error is EACCES, then the
> domain creation should be aborted with a message about that, since the
> system has been installed incorrectly.
> 
> Compare this situation with the recent pygrub failure, where
> libfsimage+pygrub turned all errors of the form "something went wrong
> loading this plugin" into "the kernel was not found"; so when a
> completely empty .so was loaded as a plugin the result was not "OMG
> WTF this is totally broken" but "sorry can't find your kernel in this
> filesystem" (when really the problem is that pygrub+libfsimage knew
> that the filesystem was one they were supposed to support but the
> plugin for it was utterly broken).
> 
> This reminds me of our other recent discussion about error handling,
> of receiving unexpected toolstack migration info.  In general any
> unanticipated situation should be treated as a fatal error.  Only
> anticipated situations should result in the software continuing in a
> degraded manner.

NULL is an abort condition and libxl__device_disk_local_attach prints a
useful message.


> > > > +static char *encode_disk_name(char *ptr, unsigned int n)
> > > 
> > > There is no clearly defined upper bound on the buffer space needed by
> > > this function.
> > 
> > I know but this function is used as is in Linux where the stack is
> > even smaller. I'll add an upper bound anyway.
> 
> At the very least a comment is needed to demonstrate that it's
> correct, but a bound in the code would be better.  (Also I'm surprised
> that you chose a recursive rather than iterative implementation of a
> what is a base conversion routine...)

OK

> > > > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> > > > index 9e0ed6d..c8977ac 100644
> > > > --- a/tools/libxl/libxl_netbsd.c
> > > > +++ b/tools/libxl/libxl_netbsd.c
> > > ...
> > > > +char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
> > > > +{
> > > > +    /* TODO */
> > > > +    return NULL;
> > > > +}
> > > 
> > > I guess this is going to be fixed in a future version of the patch ?
> > 
> > I don't think so: I don't know anything about netbsd and local_attach
> > doesn't work there anyway.
> 
> What is the error behaviour if NULL is returned here ?  I forget the
> rest of the patch, but once again we should make sure that we abort if
> this situation occurs.

NULL is returned by libxl__alloc_vdev, then it is the same as before:
eventually the domain creation terminates with an fatal error.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMNA9-0007Kn-Un; Mon, 23 Apr 2012 17:34:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMNA8-0007KU-MD
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:34:56 +0000
Received: from [193.109.254.147:54398] by server-11.bemta-14.messagelabs.com
	id 68/85-05858-0C2959F4; Mon, 23 Apr 2012 17:34:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335202495!5901250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32748 invoked from network); 23 Apr 2012 17:34:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:34:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:34:55 +0100
Date: Mon, 23 Apr 2012 18:40:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20369.29841.410190.50222@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231729300.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44862.597858.180770@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
	<20369.29841.410190.50222@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> > > ...
> > > > +                    t = xs_transaction_start(ctx->xsh);
> > > 
> > > This transaction should be in the local variables block for the whole
> > > function, and initialised to 0.
> > 
> > I don't think I understand what you mean.
> > Do you mean moving xs_transaction_start outside the switch?
> > If so, why? It doesn't affect many of the other cases.
> 
> No, I mean that the variable should be defined at the top of the
> function and initialised to 0.
> 
> In general, any resource allocated in a function other than from the
> gc should be held in a variable set and used like "resource" in this
> example:
> 
>   int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
>   {
> 
>       foo *resource = 0;
>       int rc;
> 
>       blah blah blah;
> 
>       resource = xmumble_acquire_resource(wibble wombat);
>       if (!resource) { rc = ERROR_FAIL; goto out; }
> 
>       blah blah blah;
> 
>       rc = 0;
> 
>     out:
>       xmumble_free_resource(resource);
>       return rc;
>   }

After reading the rest of this email, I can see why this would be a
useful change to make.


> > > > +                    if (tmpdisk->vdev == NULL) {
> > > > +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > > > +                                "libxl__alloc_vdev failed\n");
> > > > +                        xs_transaction_end(ctx->xsh, t, 1);
> > > 
> > > And then all these xs_transaction_end calls turn into one call in the
> > > exit path.
> > 
> > So maybe you do mean moving the transaction outside the switch.
> > In that case I disagree: the transaction is only useful in a very
> > limited set of cases (just one at the moment), while most of the others
> > don't need it.
> 
> No, I mean only the calls which abort the transaction should be in the
> "goto out" section.
> 
> So:
> 
>   int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
>   {
> 
>       xs_transaction_t our_trans;
>       int rc;
> 
>       blah blah blah;
> 
>       for (;;) {
>           our_trans = xs_transaction_start(...);
>           if (!our_trans) { rc = ERROR_FAIL; goto out; }
> 
>           blah blah blah;
> 
>           r = xs_transaction_end(CTX->xsh, our_trans, 0);
>           our_trans = 0; /* it's ended either way */
>           if (r shows it was successful) break;
>           if (r not as expected) { rc = ERROR_FAIL; goto out; }
>       }
> 
>       blah blah blah;
> 
>       rc = 0;
> 
>     out:
>       if (our_trans) xs_transaction_end(CTX->xsh, our_trans, 1);
>       return rc;
>   }
> 
> The point is that the following invariant is maintained: we have a
> transaction open, which needs to be ended, iff !!our_trans.

OK


> > > > -            dev = tmpdisk->pdev_path;
> > > > +    switch (disk->backend) {
> > > > +        case LIBXL_DISK_BACKEND_QDISK:
> > > > +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> > > 
> > > This replicates the logic earlier, which decided whether to use a
> > > qdisk.  I think it would be better to remember whether we did use a
> > > qdisk and detach it iff so.
> >  
> > There are cases in which we do use qdisk but we don't have to detach.
> 
> I'm not sure I follow.  This is the attachment of the VM's disk for
> the benefit of the bootloader.  When we are done with running the
> bootloader we need to clean it up.
 
Sorry I didn't understand what you meant earlier.
I'll use another why to figure out if we need to remove the disk
that is not dependent on the format or the policy that we used earlier.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 17:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 17:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMNA9-0007Kn-Un; Mon, 23 Apr 2012 17:34:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMNA8-0007KU-MD
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 17:34:56 +0000
Received: from [193.109.254.147:54398] by server-11.bemta-14.messagelabs.com
	id 68/85-05858-0C2959F4; Mon, 23 Apr 2012 17:34:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335202495!5901250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32748 invoked from network); 23 Apr 2012 17:34:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 17:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="12087360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 17:34:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Apr 2012 18:34:55 +0100
Date: Mon, 23 Apr 2012 18:40:50 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20369.29841.410190.50222@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231729300.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44862.597858.180770@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201520020.26786@kaball-desktop>
	<20369.29841.410190.50222@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 20 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 6/7] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> > > ...
> > > > +                    t = xs_transaction_start(ctx->xsh);
> > > 
> > > This transaction should be in the local variables block for the whole
> > > function, and initialised to 0.
> > 
> > I don't think I understand what you mean.
> > Do you mean moving xs_transaction_start outside the switch?
> > If so, why? It doesn't affect many of the other cases.
> 
> No, I mean that the variable should be defined at the top of the
> function and initialised to 0.
> 
> In general, any resource allocated in a function other than from the
> gc should be held in a variable set and used like "resource" in this
> example:
> 
>   int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
>   {
> 
>       foo *resource = 0;
>       int rc;
> 
>       blah blah blah;
> 
>       resource = xmumble_acquire_resource(wibble wombat);
>       if (!resource) { rc = ERROR_FAIL; goto out; }
> 
>       blah blah blah;
> 
>       rc = 0;
> 
>     out:
>       xmumble_free_resource(resource);
>       return rc;
>   }

After reading the rest of this email, I can see why this would be a
useful change to make.


> > > > +                    if (tmpdisk->vdev == NULL) {
> > > > +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > > > +                                "libxl__alloc_vdev failed\n");
> > > > +                        xs_transaction_end(ctx->xsh, t, 1);
> > > 
> > > And then all these xs_transaction_end calls turn into one call in the
> > > exit path.
> > 
> > So maybe you do mean moving the transaction outside the switch.
> > In that case I disagree: the transaction is only useful in a very
> > limited set of cases (just one at the moment), while most of the others
> > don't need it.
> 
> No, I mean only the calls which abort the transaction should be in the
> "goto out" section.
> 
> So:
> 
>   int libxl__do_something_requiring_xmumble_resource(libxl__gc *gc, flibble)
>   {
> 
>       xs_transaction_t our_trans;
>       int rc;
> 
>       blah blah blah;
> 
>       for (;;) {
>           our_trans = xs_transaction_start(...);
>           if (!our_trans) { rc = ERROR_FAIL; goto out; }
> 
>           blah blah blah;
> 
>           r = xs_transaction_end(CTX->xsh, our_trans, 0);
>           our_trans = 0; /* it's ended either way */
>           if (r shows it was successful) break;
>           if (r not as expected) { rc = ERROR_FAIL; goto out; }
>       }
> 
>       blah blah blah;
> 
>       rc = 0;
> 
>     out:
>       if (our_trans) xs_transaction_end(CTX->xsh, our_trans, 1);
>       return rc;
>   }
> 
> The point is that the following invariant is maintained: we have a
> transaction open, which needs to be ended, iff !!our_trans.

OK


> > > > -            dev = tmpdisk->pdev_path;
> > > > +    switch (disk->backend) {
> > > > +        case LIBXL_DISK_BACKEND_QDISK:
> > > > +            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> > > 
> > > This replicates the logic earlier, which decided whether to use a
> > > qdisk.  I think it would be better to remember whether we did use a
> > > qdisk and detach it iff so.
> >  
> > There are cases in which we do use qdisk but we don't have to detach.
> 
> I'm not sure I follow.  This is the attachment of the VM's disk for
> the benefit of the bootloader.  When we are done with running the
> bootloader we need to clean it up.
 
Sorry I didn't understand what you meant earlier.
I'll use another why to figure out if we need to remove the disk
that is not dependent on the format or the policy that we used earlier.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 18:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 18:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMNfg-0007vd-R9; Mon, 23 Apr 2012 18:07:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SMNff-0007vY-NX
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 18:07:31 +0000
Received: from [85.158.138.51:17307] by server-5.bemta-3.messagelabs.com id
	A7/5E-17113-26A959F4; Mon, 23 Apr 2012 18:07:30 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335204449!23333922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21013 invoked from network); 23 Apr 2012 18:07:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 18:07:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,468,1330905600"; d="scan'208";a="12087715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 18:07:28 +0000
Received: from [127.0.1.1] (10.80.3.206) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 19:07:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8470671d407f4f74b499fec40d6fe8bac2aadb46
Message-ID: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
User-Agent: Mercurial-patchbomb/2.1
Date: Mon, 23 Apr 2012 19:07:23 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
To: xen-devel@lists.xensource.com
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit test
 for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The memory hotplug code was masking the hotplugged memory start address and comparing to a shifted version of COMPAT MPT size but not doing the same for the end address.
This patch applies the same shifting and masking to the end address and reapplies the mask if the end address has been clamped.

diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct
     int err = 0;
 
     smap = info->spfn & (~((1UL << (L2_PAGETABLE_SHIFT - 2)) -1));
+    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
+                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
 
     /*
      * Notice: For hot-added memory, only range below m2p_compat_vstart
@@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct
     if   ((smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2)) )
         return 0;
 
-    if (epfn > (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
-        epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
-
-    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
-                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
+    if (emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2))
+    {
+        emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
+    	emap = emap & ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1);
+    }
 
     va = HIRO_COMPAT_MPT_VIRT_START +
          smap * sizeof(*compat_machine_to_phys_mapping);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 18:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 18:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMNfg-0007vd-R9; Mon, 23 Apr 2012 18:07:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SMNff-0007vY-NX
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 18:07:31 +0000
Received: from [85.158.138.51:17307] by server-5.bemta-3.messagelabs.com id
	A7/5E-17113-26A959F4; Mon, 23 Apr 2012 18:07:30 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335204449!23333922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY4NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21013 invoked from network); 23 Apr 2012 18:07:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 18:07:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,468,1330905600"; d="scan'208";a="12087715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Apr 2012 18:07:28 +0000
Received: from [127.0.1.1] (10.80.3.206) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Apr 2012 19:07:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8470671d407f4f74b499fec40d6fe8bac2aadb46
Message-ID: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
User-Agent: Mercurial-patchbomb/2.1
Date: Mon, 23 Apr 2012 19:07:23 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
To: xen-devel@lists.xensource.com
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit test
 for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The memory hotplug code was masking the hotplugged memory start address and comparing to a shifted version of COMPAT MPT size but not doing the same for the end address.
This patch applies the same shifting and masking to the end address and reapplies the mask if the end address has been clamped.

diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct
     int err = 0;
 
     smap = info->spfn & (~((1UL << (L2_PAGETABLE_SHIFT - 2)) -1));
+    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
+                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
 
     /*
      * Notice: For hot-added memory, only range below m2p_compat_vstart
@@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct
     if   ((smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2)) )
         return 0;
 
-    if (epfn > (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
-        epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
-
-    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
-                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
+    if (emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2))
+    {
+        emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
+    	emap = emap & ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1);
+    }
 
     va = HIRO_COMPAT_MPT_VIRT_START +
          smap * sizeof(*compat_machine_to_phys_mapping);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 19:11:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 19:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMOf9-00007r-P6; Mon, 23 Apr 2012 19:11:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMOf8-00007k-94
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 19:11:02 +0000
Received: from [85.158.143.35:64109] by server-3.bemta-4.messagelabs.com id
	13/FE-05853-549A59F4; Mon, 23 Apr 2012 19:11:01 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335208260!6247038!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14817 invoked from network); 23 Apr 2012 19:11:01 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 19:11:01 -0000
Received: by lahe6 with SMTP id e6so10885929lah.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 12:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=5QgmzMv6oCCWIAX/qrmv/P/OxGDqMBVX6qmANtWhl+o=;
	b=Jhin1HbkJ2qo0+ps6kZjV5EfPgo0EkOdNspPR9n2/gFxiY6bbn2MTjAh/3DQcAu2NH
	S88EGMIG/e4YqDoNDDI1Jlzx0ninXC0pZ2sclDLIaGMx07JNPknnJQc7phZ4gMdMgkdF
	1N1ICxd+jGLDcPyxsh/77m9mw82SG+B1zqY7I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=5QgmzMv6oCCWIAX/qrmv/P/OxGDqMBVX6qmANtWhl+o=;
	b=NBVK6HONveyXvCIrvy0ElwfgOK2z1uNGw+a5FjXqX5UkBumsB8PJKaTSdnUW1FDMOz
	vY8VTLe+JRO5EHX9gVdzsJELEB4UYcu23ShzwbnNerPESasJZnImk6gObbRme6gNyHp3
	g24FiHQ9xLA3ZvNBAXaZs29N4r06NW2QFtJ1cxyWcRbeREOU+gSkI8l1m1V1T67Yd1ZA
	m5cmAtfzsy38ZlFhyF/Ue5fRlz8FKXlN/gqTLg+kl/QQuWvl01H5tlH3wOd6RdYvOfve
	Czg3cOcxB5OmlQOPVnAF3bg1+3aMr78koh8bfDNcGWL6KDVFbT0Qob5mBGC0LfvYsp3d
	mxhw==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr8425448lbm.31.1335208260139; Mon,
	23 Apr 2012 12:11:00 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 12:11:00 -0700 (PDT)
X-Originating-IP: [108.92.21.169]
In-Reply-To: <4F9526A9020000780007F36B@nat28.tlf.novell.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
	<4F9523DD020000780007F339@nat28.tlf.novell.com>
	<CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
	<4F9526A9020000780007F36B@nat28.tlf.novell.com>
Date: Mon, 23 Apr 2012 12:11:00 -0700
Message-ID: <CAB10MZBUPC2AyZ5CCzEOCezq+pefiqZ_SyWCb7JWVDWhJnA=TA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQmM3YFuovhQTsUkzOV7hUs/0y71CefXZ9gIpenS687L40bXxfoOglV6/fBA6VFZ0Yyd6MZh
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 12:53 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.04.12 at 09:47, Aravindh Puthiyaparambil <aravindh@virtuata.com>=
 wrote:
>> On Apr 23, 2012 12:41 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>
>>> >>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.c=
om>
>> wrote:
>>> > Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
>>> >
>>> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>> >
>>> > diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
>>> > --- a/xen/arch/x86/domctl.c =A0 Fri Apr 20 11:36:02 2012 -0700
>>> > +++ b/xen/arch/x86/domctl.c =A0 Fri Apr 20 17:55:49 2012 -0700
>>> > @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
>>> > =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>>> > =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>> > =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>>> > +#ifdef __x86_64__
>>> > + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>> > + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>> > + =A0 =A0 =A0 =A0else
>>> > + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>> > +#endif
>>>
>>> If you do anything like this, do it completely please (i.e. fill all th=
ree
>>> base address fields instead of just one).
>>>
>>
>> Sure. I was not sure if it was ok to add fields to the vcpu context
>> structure which is why I didn't do it across the board. I will do so and
>> resubmit.
>
> I don't see what fields you would need to add.

Don't I need to add ss_base, cs_base, es_base, ds_base to
vcpu_guest_context? I am assuming both 32-bit and 64-bit cases.

Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 19:11:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 19:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMOf9-00007r-P6; Mon, 23 Apr 2012 19:11:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMOf8-00007k-94
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 19:11:02 +0000
Received: from [85.158.143.35:64109] by server-3.bemta-4.messagelabs.com id
	13/FE-05853-549A59F4; Mon, 23 Apr 2012 19:11:01 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335208260!6247038!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14817 invoked from network); 23 Apr 2012 19:11:01 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 19:11:01 -0000
Received: by lahe6 with SMTP id e6so10885929lah.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 12:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=5QgmzMv6oCCWIAX/qrmv/P/OxGDqMBVX6qmANtWhl+o=;
	b=Jhin1HbkJ2qo0+ps6kZjV5EfPgo0EkOdNspPR9n2/gFxiY6bbn2MTjAh/3DQcAu2NH
	S88EGMIG/e4YqDoNDDI1Jlzx0ninXC0pZ2sclDLIaGMx07JNPknnJQc7phZ4gMdMgkdF
	1N1ICxd+jGLDcPyxsh/77m9mw82SG+B1zqY7I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=5QgmzMv6oCCWIAX/qrmv/P/OxGDqMBVX6qmANtWhl+o=;
	b=NBVK6HONveyXvCIrvy0ElwfgOK2z1uNGw+a5FjXqX5UkBumsB8PJKaTSdnUW1FDMOz
	vY8VTLe+JRO5EHX9gVdzsJELEB4UYcu23ShzwbnNerPESasJZnImk6gObbRme6gNyHp3
	g24FiHQ9xLA3ZvNBAXaZs29N4r06NW2QFtJ1cxyWcRbeREOU+gSkI8l1m1V1T67Yd1ZA
	m5cmAtfzsy38ZlFhyF/Ue5fRlz8FKXlN/gqTLg+kl/QQuWvl01H5tlH3wOd6RdYvOfve
	Czg3cOcxB5OmlQOPVnAF3bg1+3aMr78koh8bfDNcGWL6KDVFbT0Qob5mBGC0LfvYsp3d
	mxhw==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr8425448lbm.31.1335208260139; Mon,
	23 Apr 2012 12:11:00 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 12:11:00 -0700 (PDT)
X-Originating-IP: [108.92.21.169]
In-Reply-To: <4F9526A9020000780007F36B@nat28.tlf.novell.com>
References: <babbb3e0f4d3e5aa14cd.1334969902@vollum>
	<4F9523DD020000780007F339@nat28.tlf.novell.com>
	<CAB10MZBAKeNx1-=GKvhhAgTX4dSyRT_7yCgimVx4-ZEkuyrRgw@mail.gmail.com>
	<4F9526A9020000780007F36B@nat28.tlf.novell.com>
Date: Mon, 23 Apr 2012 12:11:00 -0700
Message-ID: <CAB10MZBUPC2AyZ5CCzEOCezq+pefiqZ_SyWCb7JWVDWhJnA=TA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQmM3YFuovhQTsUkzOV7hUs/0y71CefXZ9gIpenS687L40bXxfoOglV6/fBA6VFZ0Yyd6MZh
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 12:53 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.04.12 at 09:47, Aravindh Puthiyaparambil <aravindh@virtuata.com>=
 wrote:
>> On Apr 23, 2012 12:41 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>
>>> >>> On 21.04.12 at 02:58, Aravindh Puthiyaparambil <aravindh@virtuata.c=
om>
>> wrote:
>>> > Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
>>> >
>>> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>> >
>>> > diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c
>>> > --- a/xen/arch/x86/domctl.c =A0 Fri Apr 20 11:36:02 2012 -0700
>>> > +++ b/xen/arch/x86/domctl.c =A0 Fri Apr 20 17:55:49 2012 -0700
>>> > @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,
>>> > =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>>> > =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>> > =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>>> > +#ifdef __x86_64__
>>> > + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>> > + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>> > + =A0 =A0 =A0 =A0else
>>> > + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>> > +#endif
>>>
>>> If you do anything like this, do it completely please (i.e. fill all th=
ree
>>> base address fields instead of just one).
>>>
>>
>> Sure. I was not sure if it was ok to add fields to the vcpu context
>> structure which is why I didn't do it across the board. I will do so and
>> resubmit.
>
> I don't see what fields you would need to add.

Don't I need to add ss_base, cs_base, es_base, ds_base to
vcpu_guest_context? I am assuming both 32-bit and 64-bit cases.

Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 19:18:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 19:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMOmM-0000Uw-Lj; Mon, 23 Apr 2012 19:18:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMOmL-0000Uq-Bw
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 19:18:29 +0000
Received: from [85.158.139.83:57338] by server-5.bemta-5.messagelabs.com id
	68/97-13566-40BA59F4; Mon, 23 Apr 2012 19:18:28 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335208707!21186415!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23365 invoked from network); 23 Apr 2012 19:18:27 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 19:18:27 -0000
Received: by lagr15 with SMTP id r15so9815886lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 12:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZGbFeMrR3PTyHCcMNTOG4x7mN4MZ7PVvFDvI0hfbscA=;
	b=M51HKWQp8gNDzNorsMe1aNEP9I7hT7rDdZSA8dkS4kg/2hiCE5MB5HzeMndhy0OkMr
	BeEmg4o+9xTZyrYbOO7iiFuttQam+KFAcaFwdY0MTC+4UGzhC912xDySvWzWsChKscgI
	RUN5T5R0X+vSYScePBAGoul265zfEnAc6o648=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=ZGbFeMrR3PTyHCcMNTOG4x7mN4MZ7PVvFDvI0hfbscA=;
	b=jkJa7omD/RGJ0EcUgH0Y7J4+kYFcBCdh8JDAjzQnynRIzZqWw0Diek15qEORzMKqxC
	IsofL2UhYnlQ6OywWbxLVrKZQs0+vicyO131AQWSWL2yj5i4y00ddnfAzdLGd/ERR2N7
	o8GlQeGTvSb2RXVv5paZZPoueG6DU4ykOTvYZ0SlnoO/9esXSidKl4RZCh+i+Gv3sRiJ
	X1edQkgbP+I9GvQoKvTMSELEdDGHYYmU7LCxetMqqRe5SWxdxxrsc+vbdIfF2yvV8Lsm
	IPUwxkolbZkMWO3nu9iq62eQsA23nXyyd78U6Q9CVYVq7DeIOTZYe2ORqlquo0aNKsPi
	wTiA==
MIME-Version: 1.0
Received: by 10.152.148.101 with SMTP id tr5mr4815260lab.36.1335208707185;
	Mon, 23 Apr 2012 12:18:27 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 12:18:27 -0700 (PDT)
X-Originating-IP: [108.92.21.169]
In-Reply-To: <1334997070.3900.4.camel@dagon.hellion.org.uk>
References: <e62ab14d44afb1781a36.1334947081@vollum>
	<1334997070.3900.4.camel@dagon.hellion.org.uk>
Date: Mon, 23 Apr 2012 12:18:27 -0700
Message-ID: <CAB10MZDV1EsqjVbRDJHK6KyWhndmJB3DXjkoToF=ueLB4sVcJw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQmClVOSIFb2LmyYFP2ruMiyW3/YTNVP0YUQZYJsZcDULaciyeNpi5oUdcrs3+92EBc6Aln8
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v2] libxc: Replace alloca() with mmap()
 for pfn array sizes greater than a page in linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 21, 2012 at 1:31 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Fri, 2012-04-20 at 19:38 +0100, Aravindh Puthiyaparambil wrote:
>> When mapping in large amounts of pages (in the GB range) from a guest in=
 to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client=
 application. This is because the pfn array in linux_privcmd_map_foreign_bu=
lk() is being allocated using alloca() and the subsequent memcpy causes the=
 stack to blow. This patch replaces the alloca() with mmap() for pfn array =
sizes greater than a page.
>>
>> Fix an error print with the correct function name.
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>
> Thanks. Did you rule out this bug at the =A0usage of alloca() in
> linux_gnttab_grant_map? If not then I think that should be changed too.

Yes, you right. It could happen with linux_gnttab_grant_map() also. I
will fix that and resubmit.

Thanks,
Aravindh

>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 7c777cb8f705 -r e62ab14d44af tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c =A0 =A0Wed Apr 18 16:49:55 2012 +0100
>> +++ b/tools/libxc/xc_linux_osdep.c =A0 =A0Fri Apr 20 11:36:02 2012 -0700
>> @@ -39,6 +39,7 @@
>> =A0#include "xenctrl.h"
>> =A0#include "xenctrlosdep.h"
>>
>> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(=
_w))-1))
>> =A0#define ERROR(_m, _a...) =A0xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ER=
ROR,_m , ## _a )
>> =A0#define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERRO=
R,_m \
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0" (%d =3D %s)", ## _a , errno, xc=
_strerror(xch, errno))
>> @@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fd, 0);
>> =A0 =A0 =A0if ( addr =3D=3D MAP_FAILED )
>> =A0 =A0 =A0{
>> - =A0 =A0 =A0 =A0PERROR("xc_map_foreign_batch: mmap failed");
>> + =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap failed");
>> =A0 =A0 =A0 =A0 =A0return NULL;
>> =A0 =A0 =A0}
>>
>> @@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 * IOCTL_PRIVCMD_MMAPBATCH.
>> =A0 =A0 =A0 =A0 =A0 */
>> =A0 =A0 =A0 =A0 =A0privcmd_mmapbatch_t ioctlx;
>> - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
>> + =A0 =A0 =A0 =A0xen_pfn_t *pfn;
>> + =A0 =A0 =A0 =A0unsigned int pfn_arr_size =3D ROUNDUP((num * sizeof(*pf=
n)), XC_PAGE_SHIFT);
>> +
>> + =A0 =A0 =A0 =A0if ( pfn_arr_size <=3D XC_PAGE_SIZE )
>> + =A0 =A0 =A0 =A0 =A0 =A0pfn =3D alloca(num * sizeof(*pfn));
>> + =A0 =A0 =A0 =A0else
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0pfn =3D mmap(NULL, pfn_arr_size, PROT_READ | PR=
OT_WRITE,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MAP_PRIVATE | MAP_ANON | M=
AP_POPULATE, -1, 0);
>> + =A0 =A0 =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )
>> + =A0 =A0 =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap of pf=
n array failed");
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL;
>> + =A0 =A0 =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 =A0memcpy(pfn, arr, num * sizeof(*arr));
>>
>> @@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> + =A0 =A0 =A0 =A0if ( pfn_arr_size > XC_PAGE_SIZE )
>> + =A0 =A0 =A0 =A0 =A0 =A0munmap(pfn, pfn_arr_size);
>> +
>> =A0 =A0 =A0 =A0 =A0if ( rc =3D=3D -ENOENT && i =3D=3D num )
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D 0;
>> =A0 =A0 =A0 =A0 =A0else if ( rc )
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 19:18:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 19:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMOmM-0000Uw-Lj; Mon, 23 Apr 2012 19:18:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMOmL-0000Uq-Bw
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 19:18:29 +0000
Received: from [85.158.139.83:57338] by server-5.bemta-5.messagelabs.com id
	68/97-13566-40BA59F4; Mon, 23 Apr 2012 19:18:28 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335208707!21186415!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23365 invoked from network); 23 Apr 2012 19:18:27 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 19:18:27 -0000
Received: by lagr15 with SMTP id r15so9815886lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 12:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZGbFeMrR3PTyHCcMNTOG4x7mN4MZ7PVvFDvI0hfbscA=;
	b=M51HKWQp8gNDzNorsMe1aNEP9I7hT7rDdZSA8dkS4kg/2hiCE5MB5HzeMndhy0OkMr
	BeEmg4o+9xTZyrYbOO7iiFuttQam+KFAcaFwdY0MTC+4UGzhC912xDySvWzWsChKscgI
	RUN5T5R0X+vSYScePBAGoul265zfEnAc6o648=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=ZGbFeMrR3PTyHCcMNTOG4x7mN4MZ7PVvFDvI0hfbscA=;
	b=jkJa7omD/RGJ0EcUgH0Y7J4+kYFcBCdh8JDAjzQnynRIzZqWw0Diek15qEORzMKqxC
	IsofL2UhYnlQ6OywWbxLVrKZQs0+vicyO131AQWSWL2yj5i4y00ddnfAzdLGd/ERR2N7
	o8GlQeGTvSb2RXVv5paZZPoueG6DU4ykOTvYZ0SlnoO/9esXSidKl4RZCh+i+Gv3sRiJ
	X1edQkgbP+I9GvQoKvTMSELEdDGHYYmU7LCxetMqqRe5SWxdxxrsc+vbdIfF2yvV8Lsm
	IPUwxkolbZkMWO3nu9iq62eQsA23nXyyd78U6Q9CVYVq7DeIOTZYe2ORqlquo0aNKsPi
	wTiA==
MIME-Version: 1.0
Received: by 10.152.148.101 with SMTP id tr5mr4815260lab.36.1335208707185;
	Mon, 23 Apr 2012 12:18:27 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 12:18:27 -0700 (PDT)
X-Originating-IP: [108.92.21.169]
In-Reply-To: <1334997070.3900.4.camel@dagon.hellion.org.uk>
References: <e62ab14d44afb1781a36.1334947081@vollum>
	<1334997070.3900.4.camel@dagon.hellion.org.uk>
Date: Mon, 23 Apr 2012 12:18:27 -0700
Message-ID: <CAB10MZDV1EsqjVbRDJHK6KyWhndmJB3DXjkoToF=ueLB4sVcJw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQmClVOSIFb2LmyYFP2ruMiyW3/YTNVP0YUQZYJsZcDULaciyeNpi5oUdcrs3+92EBc6Aln8
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v2] libxc: Replace alloca() with mmap()
 for pfn array sizes greater than a page in linux_privcmd_map_foreign_bulk()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Apr 21, 2012 at 1:31 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Fri, 2012-04-20 at 19:38 +0100, Aravindh Puthiyaparambil wrote:
>> When mapping in large amounts of pages (in the GB range) from a guest in=
 to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client=
 application. This is because the pfn array in linux_privcmd_map_foreign_bu=
lk() is being allocated using alloca() and the subsequent memcpy causes the=
 stack to blow. This patch replaces the alloca() with mmap() for pfn array =
sizes greater than a page.
>>
>> Fix an error print with the correct function name.
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>
> Thanks. Did you rule out this bug at the =A0usage of alloca() in
> linux_gnttab_grant_map? If not then I think that should be changed too.

Yes, you right. It could happen with linux_gnttab_grant_map() also. I
will fix that and resubmit.

Thanks,
Aravindh

>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 7c777cb8f705 -r e62ab14d44af tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c =A0 =A0Wed Apr 18 16:49:55 2012 +0100
>> +++ b/tools/libxc/xc_linux_osdep.c =A0 =A0Fri Apr 20 11:36:02 2012 -0700
>> @@ -39,6 +39,7 @@
>> =A0#include "xenctrl.h"
>> =A0#include "xenctrlosdep.h"
>>
>> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(=
_w))-1))
>> =A0#define ERROR(_m, _a...) =A0xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ER=
ROR,_m , ## _a )
>> =A0#define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERRO=
R,_m \
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0" (%d =3D %s)", ## _a , errno, xc=
_strerror(xch, errno))
>> @@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fd, 0);
>> =A0 =A0 =A0if ( addr =3D=3D MAP_FAILED )
>> =A0 =A0 =A0{
>> - =A0 =A0 =A0 =A0PERROR("xc_map_foreign_batch: mmap failed");
>> + =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap failed");
>> =A0 =A0 =A0 =A0 =A0return NULL;
>> =A0 =A0 =A0}
>>
>> @@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 * IOCTL_PRIVCMD_MMAPBATCH.
>> =A0 =A0 =A0 =A0 =A0 */
>> =A0 =A0 =A0 =A0 =A0privcmd_mmapbatch_t ioctlx;
>> - =A0 =A0 =A0 =A0xen_pfn_t *pfn =3D alloca(num * sizeof(*pfn));
>> + =A0 =A0 =A0 =A0xen_pfn_t *pfn;
>> + =A0 =A0 =A0 =A0unsigned int pfn_arr_size =3D ROUNDUP((num * sizeof(*pf=
n)), XC_PAGE_SHIFT);
>> +
>> + =A0 =A0 =A0 =A0if ( pfn_arr_size <=3D XC_PAGE_SIZE )
>> + =A0 =A0 =A0 =A0 =A0 =A0pfn =3D alloca(num * sizeof(*pfn));
>> + =A0 =A0 =A0 =A0else
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0pfn =3D mmap(NULL, pfn_arr_size, PROT_READ | PR=
OT_WRITE,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MAP_PRIVATE | MAP_ANON | M=
AP_POPULATE, -1, 0);
>> + =A0 =A0 =A0 =A0 =A0 =A0if ( pfn =3D=3D MAP_FAILED )
>> + =A0 =A0 =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR("xc_map_foreign_bulk: mmap of pf=
n array failed");
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL;
>> + =A0 =A0 =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 =A0memcpy(pfn, arr, num * sizeof(*arr));
>>
>> @@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> + =A0 =A0 =A0 =A0if ( pfn_arr_size > XC_PAGE_SIZE )
>> + =A0 =A0 =A0 =A0 =A0 =A0munmap(pfn, pfn_arr_size);
>> +
>> =A0 =A0 =A0 =A0 =A0if ( rc =3D=3D -ENOENT && i =3D=3D num )
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D 0;
>> =A0 =A0 =A0 =A0 =A0else if ( rc )
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 19:35:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 19:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMP2j-0000kV-9N; Mon, 23 Apr 2012 19:35:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMP2g-0000kQ-Fl
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 19:35:23 +0000
Received: from [85.158.138.51:29184] by server-9.bemta-3.messagelabs.com id
	70/F9-26691-9FEA59F4; Mon, 23 Apr 2012 19:35:21 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335209719!23341447!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1325 invoked from network); 23 Apr 2012 19:35:19 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 19:35:19 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 075911C14001;
	Mon, 23 Apr 2012 21:35:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=PZVBDLVpp77byE6vKrDUTLNWAIQ=; b=rz
	91qK84hZH/LWXQnGm14nEgqt+SqIiE76jczrqenNi48onKMU0no3wHsQnksshaWL
	9ehnOd2tauVAu+YZQ0uaJdXXDMt3XUrPPYSAXW4MOc5Na8MVb7QfHEz0r7HuoPv3
	GBZMqLoiMXsb9aeH6rLWQp9hZBPSJsV2hprtbFu4D1YYPckIDzPPu4Pxp/Nws7GB
	ZnjqHeajAclj+Pu7DC5yC/Q2eS0Mvgj22E2jUhkwT1ywxDUbxFMS3InRFlPxj/OK
	XEOYCxzB2CiH4bR7MTIVK/T5BQFoGEeGeYWmSRewBKOvW0MYBdFXxKqpHmPlYjEy
	T/8npmDPBNd0Jns8yRB5SPYBEN0t/Rrf5vGdA6sMJ4ohcM2nIsaE3noeU+YGm7LH
	c9PEXmPqJScjjtXLoKWzfOgrlsq1VWDQoLiJxkkRtiFH8d72UL2WVCYuWrcseqXv
	A4aeYTgdJNQwXj/UG/ls20NVg4GwFVlsoqFUk4XQh8Bme4u910kIrrWciEvQP6Oi
	2qkBM3SzydPbmVc7vMf3G8jleSuYDeCz0oPHX3TwYwsfYyUUg30Hh+sKGGiW9vKh
	n0RBXAUR4ltmmmS5Piy1Gxo4KvGlVhDAE6rdm86NohNp6LTyWDejXPX+oGzZVZvf
	r1N0mmsjvak8+rQWfS0WlbDi3kvSMWkrB6SAl1Wk4=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id B4ED21C14002; Mon, 23 Apr 2012 21:35:18 +0200 (CEST)
Date: Mon, 23 Apr 2012 21:35:18 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20120423193518.GA16134@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="lEGEL1/lMxI0MVQ2"
Content-Disposition: inline
In-Reply-To: <1335197251.22133.5.camel@Solace>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--lEGEL1/lMxI0MVQ2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,


On Mon, Apr 23, Dario Faggioli wrote:

> > I checked out the source with git not hg, may I produce a diff with git
> > and send it via mail ?
> >=20
> I think you should. Either use something automatic like git `send-email'
> or just produce the diff and then inline or attach, following also the
> other instructions Ian pointed you to (on the wiki)... Was it this you
> were asking?

yes.

ok, second try ;)
I hope this fit more your needs.

I've defined a new union in the libxl_domain_build_info structure.
For this I had to move some structure definition like
libxl_sched_credit_domain more to the top.
I named the union 'us' for union scheduler, because the letter 'u' was
already used for the type of domain.


--=20
Best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--lEGEL1/lMxI0MVQ2
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"
Content-Transfer-Encoding: quoted-printable

libxl: set domain scheduling parameters while creating the dom

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..38acff4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char *dom_path, *vm_path;
     xs_transaction_t t;
     char **ents, **hvm_ents;
+    libxl_scheduler sched;
     int i;
=20
+    sched =3D libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      break;
+    default:
+        abort();
+    }
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid !=3D NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..c1cdc3c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,27 @@ libxl_domain_create_info =3D Struct("domain_create_inf=
o",[
=20
 MemKB =3D UInt(64, init_val =3D "LIBXL_MEMKB_DEFAULT")
=20
+libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain =3D Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +277,13 @@ libxl_domain_build_info =3D Struct("domain_build_info"=
,[
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
=20
+    ("us", KeyedUnion(None, libxl_scheduler, "sched",
+                 [("credit", libxl_sched_credit_domain),
+                 ("credit2", libxl_sched_credit2_domain),
+                 ("sedf", libxl_sched_sedf_domain),
+                 ("arinc653", libxl_sched_arinc653_domain),
+                 ], keyvar_init_val =3D "-1")),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_typ=
e),
@@ -417,28 +445,12 @@ libxl_cputopology =3D Struct("cputopology", [
     ("node", uint32),
     ], dir=3DDIR_OUT)
=20
-libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
=20
 libxl_sched_credit_params =3D Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
     ], dispose_fn=3DNone)
=20
-libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type =3D Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..db51ca6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,23 @@ static void parse_config_data(const char *configfile_f=
ilename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
=20
     /* the following is the actual config parsing with overriding values i=
n the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->us.credit.weight =3D l;
+        b_info->us.credit2.weight =3D l;
+        b_info->us.sedf.weight =3D l;
+
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->us.credit.cap =3D l;
+
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->us.sedf.period =3D l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus =3D l;
         b_info->cur_vcpus =3D (1 << l) - 1;

--lEGEL1/lMxI0MVQ2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--lEGEL1/lMxI0MVQ2--


From xen-devel-bounces@lists.xen.org Mon Apr 23 19:35:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 19:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMP2j-0000kV-9N; Mon, 23 Apr 2012 19:35:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMP2g-0000kQ-Fl
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 19:35:23 +0000
Received: from [85.158.138.51:29184] by server-9.bemta-3.messagelabs.com id
	70/F9-26691-9FEA59F4; Mon, 23 Apr 2012 19:35:21 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335209719!23341447!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1325 invoked from network); 23 Apr 2012 19:35:19 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Apr 2012 19:35:19 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 075911C14001;
	Mon, 23 Apr 2012 21:35:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=PZVBDLVpp77byE6vKrDUTLNWAIQ=; b=rz
	91qK84hZH/LWXQnGm14nEgqt+SqIiE76jczrqenNi48onKMU0no3wHsQnksshaWL
	9ehnOd2tauVAu+YZQ0uaJdXXDMt3XUrPPYSAXW4MOc5Na8MVb7QfHEz0r7HuoPv3
	GBZMqLoiMXsb9aeH6rLWQp9hZBPSJsV2hprtbFu4D1YYPckIDzPPu4Pxp/Nws7GB
	ZnjqHeajAclj+Pu7DC5yC/Q2eS0Mvgj22E2jUhkwT1ywxDUbxFMS3InRFlPxj/OK
	XEOYCxzB2CiH4bR7MTIVK/T5BQFoGEeGeYWmSRewBKOvW0MYBdFXxKqpHmPlYjEy
	T/8npmDPBNd0Jns8yRB5SPYBEN0t/Rrf5vGdA6sMJ4ohcM2nIsaE3noeU+YGm7LH
	c9PEXmPqJScjjtXLoKWzfOgrlsq1VWDQoLiJxkkRtiFH8d72UL2WVCYuWrcseqXv
	A4aeYTgdJNQwXj/UG/ls20NVg4GwFVlsoqFUk4XQh8Bme4u910kIrrWciEvQP6Oi
	2qkBM3SzydPbmVc7vMf3G8jleSuYDeCz0oPHX3TwYwsfYyUUg30Hh+sKGGiW9vKh
	n0RBXAUR4ltmmmS5Piy1Gxo4KvGlVhDAE6rdm86NohNp6LTyWDejXPX+oGzZVZvf
	r1N0mmsjvak8+rQWfS0WlbDi3kvSMWkrB6SAl1Wk4=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id B4ED21C14002; Mon, 23 Apr 2012 21:35:18 +0200 (CEST)
Date: Mon, 23 Apr 2012 21:35:18 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20120423193518.GA16134@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="lEGEL1/lMxI0MVQ2"
Content-Disposition: inline
In-Reply-To: <1335197251.22133.5.camel@Solace>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--lEGEL1/lMxI0MVQ2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,


On Mon, Apr 23, Dario Faggioli wrote:

> > I checked out the source with git not hg, may I produce a diff with git
> > and send it via mail ?
> >=20
> I think you should. Either use something automatic like git `send-email'
> or just produce the diff and then inline or attach, following also the
> other instructions Ian pointed you to (on the wiki)... Was it this you
> were asking?

yes.

ok, second try ;)
I hope this fit more your needs.

I've defined a new union in the libxl_domain_build_info structure.
For this I had to move some structure definition like
libxl_sched_credit_domain more to the top.
I named the union 'us' for union scheduler, because the letter 'u' was
already used for the type of domain.


--=20
Best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--lEGEL1/lMxI0MVQ2
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"
Content-Transfer-Encoding: quoted-printable

libxl: set domain scheduling parameters while creating the dom

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..38acff4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char *dom_path, *vm_path;
     xs_transaction_t t;
     char **ents, **hvm_ents;
+    libxl_scheduler sched;
     int i;
=20
+    sched =3D libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      break;
+    default:
+        abort();
+    }
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid !=3D NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..c1cdc3c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,27 @@ libxl_domain_create_info =3D Struct("domain_create_inf=
o",[
=20
 MemKB =3D UInt(64, init_val =3D "LIBXL_MEMKB_DEFAULT")
=20
+libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain =3D Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +277,13 @@ libxl_domain_build_info =3D Struct("domain_build_info"=
,[
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
=20
+    ("us", KeyedUnion(None, libxl_scheduler, "sched",
+                 [("credit", libxl_sched_credit_domain),
+                 ("credit2", libxl_sched_credit2_domain),
+                 ("sedf", libxl_sched_sedf_domain),
+                 ("arinc653", libxl_sched_arinc653_domain),
+                 ], keyvar_init_val =3D "-1")),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_typ=
e),
@@ -417,28 +445,12 @@ libxl_cputopology =3D Struct("cputopology", [
     ("node", uint32),
     ], dir=3DDIR_OUT)
=20
-libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
=20
 libxl_sched_credit_params =3D Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
     ], dispose_fn=3DNone)
=20
-libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type =3D Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..db51ca6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,23 @@ static void parse_config_data(const char *configfile_f=
ilename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
=20
     /* the following is the actual config parsing with overriding values i=
n the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->us.credit.weight =3D l;
+        b_info->us.credit2.weight =3D l;
+        b_info->us.sedf.weight =3D l;
+
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->us.credit.cap =3D l;
+
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->us.sedf.period =3D l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus =3D l;
         b_info->cur_vcpus =3D (1 << l) - 1;

--lEGEL1/lMxI0MVQ2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--lEGEL1/lMxI0MVQ2--


From xen-devel-bounces@lists.xen.org Mon Apr 23 20:54:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 20:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMQGe-0001Mz-NS; Mon, 23 Apr 2012 20:53:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMQGc-0001Mt-Qi
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 20:53:51 +0000
Received: from [85.158.138.51:50431] by server-4.bemta-3.messagelabs.com id
	72/60-15341-D51C59F4; Mon, 23 Apr 2012 20:53:49 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335214428!23446837!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1843 invoked from network); 23 Apr 2012 20:53:48 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 20:53:48 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 11382D34747;
	Mon, 23 Apr 2012 22:53:48 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id dlsVXFtFHie9; Mon, 23 Apr 2012 22:53:45 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 68C99D3462F;
	Mon, 23 Apr 2012 22:53:45 +0200 (CEST)
Message-ID: <4F95C158.7030703@vido.info>
Date: Mon, 23 Apr 2012 22:53:44 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
	<20120423152404.GD24481@phenom.dumpdata.com>
In-Reply-To: <20120423152404.GD24481@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
>>> Hello!
>>>
>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4
>>> tested) as Dom0 Kernel;
>>>
>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
>>> (gplpv_Vista2008x64_0.11.0.357.msi);
>>> With 3.4 it drops to about a third of that.
>>>
>>> Xen Version is xen-unstable:
>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
>>>
>>> Disk config line is:
>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
>>> - it uses blkback.
>> I fail to see what could be the cause of the issue: nothing on the
>> blkback side should affect performances significantly.
>> You could try reverting the four patches to blkback that were applied
>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
>> regression:
>>
>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
>> Daniel De Graaf (2):
>>        xen/blkback: use grant-table.c hypercall wrappers
> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> the compiler would have kept the result of the first call to vaddr(req, i)
> somewhere.. but not sure) lost with the mentioned patch:
>
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..65dbadc 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req *req)
>   	int ret;
>
>   	for (i = 0; i<  req->nr_pages; i++) {
> +		unsigned long addr;
>   		handle = pending_handle(req, i);
>   		if (handle == BLKBACK_INVALID_HANDLE)
>   			continue;
> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> +		addr = vaddr(req, i);
> +		gnttab_set_unmap_op(&unmap[invcount], addr,
>   				    GNTMAP_host_map, handle);
>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> -		pages[invcount] = virt_to_page(vaddr(req, i));
> +		pages[invcount] = virt_to_page(addr);
>   		invcount++;
>   	}
>
>>        xen/blkback: Enable blkback on HVM guests
>>
>> Konrad Rzeszutek Wilk (2):
>>        xen/blkback: Squash the discard support for 'file' and 'phy' type.
>>        xen/blkback: Make optional features be really optional.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
that made it even worse :)
Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
Read "only" down to 40mb/s (with 3.3: ~140mb/s)

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 20:54:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 20:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMQGe-0001Mz-NS; Mon, 23 Apr 2012 20:53:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMQGc-0001Mt-Qi
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 20:53:51 +0000
Received: from [85.158.138.51:50431] by server-4.bemta-3.messagelabs.com id
	72/60-15341-D51C59F4; Mon, 23 Apr 2012 20:53:49 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335214428!23446837!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1843 invoked from network); 23 Apr 2012 20:53:48 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-174.messagelabs.com with SMTP;
	23 Apr 2012 20:53:48 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 11382D34747;
	Mon, 23 Apr 2012 22:53:48 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id dlsVXFtFHie9; Mon, 23 Apr 2012 22:53:45 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 68C99D3462F;
	Mon, 23 Apr 2012 22:53:45 +0200 (CEST)
Message-ID: <4F95C158.7030703@vido.info>
Date: Mon, 23 Apr 2012 22:53:44 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
	<20120423152404.GD24481@phenom.dumpdata.com>
In-Reply-To: <20120423152404.GD24481@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
>>> Hello!
>>>
>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4
>>> tested) as Dom0 Kernel;
>>>
>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
>>> (gplpv_Vista2008x64_0.11.0.357.msi);
>>> With 3.4 it drops to about a third of that.
>>>
>>> Xen Version is xen-unstable:
>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
>>>
>>> Disk config line is:
>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
>>> - it uses blkback.
>> I fail to see what could be the cause of the issue: nothing on the
>> blkback side should affect performances significantly.
>> You could try reverting the four patches to blkback that were applied
>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
>> regression:
>>
>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
>> Daniel De Graaf (2):
>>        xen/blkback: use grant-table.c hypercall wrappers
> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> the compiler would have kept the result of the first call to vaddr(req, i)
> somewhere.. but not sure) lost with the mentioned patch:
>
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..65dbadc 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req *req)
>   	int ret;
>
>   	for (i = 0; i<  req->nr_pages; i++) {
> +		unsigned long addr;
>   		handle = pending_handle(req, i);
>   		if (handle == BLKBACK_INVALID_HANDLE)
>   			continue;
> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> +		addr = vaddr(req, i);
> +		gnttab_set_unmap_op(&unmap[invcount], addr,
>   				    GNTMAP_host_map, handle);
>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> -		pages[invcount] = virt_to_page(vaddr(req, i));
> +		pages[invcount] = virt_to_page(addr);
>   		invcount++;
>   	}
>
>>        xen/blkback: Enable blkback on HVM guests
>>
>> Konrad Rzeszutek Wilk (2):
>>        xen/blkback: Squash the discard support for 'file' and 'phy' type.
>>        xen/blkback: Make optional features be really optional.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
that made it even worse :)
Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
Read "only" down to 40mb/s (with 3.3: ~140mb/s)

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 21:05:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 21:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMQR2-0001YK-Sr; Mon, 23 Apr 2012 21:04:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMQR2-0001YF-9I
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 21:04:36 +0000
Received: from [85.158.138.51:56304] by server-11.bemta-3.messagelabs.com id
	3A/61-18894-3E3C59F4; Mon, 23 Apr 2012 21:04:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335215074!23477745!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12120 invoked from network); 23 Apr 2012 21:04:34 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 21:04:34 -0000
Received: by wibhq7 with SMTP id hq7so3933826wib.14
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 14:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KGlkUzNOkVOgaVx32Ah4oB1vjwYP2HI4O2PRVBrX/9Q=;
	b=mZC4to2HjCjPCoAIdHuxJrGWncg0u1Vp8JJYKkhwq+kZjj6x2Wk+4Bps84d5U8kVHv
	EsMr31p2Ffvw5YnPsV3X7fD6GE35GevSXqLbimEjKYfoHyE9Nfj0ipiIh0oqLwuRfJlh
	dNV3Y2lhMcNGKIyH49DbioI6K5SBsMlPnfxFTWtLmJHouxbRd1rdBK8Jtr1+b6I8VbKD
	veQTeRmn4Gl7fxvg65UnLqY22XmmgY6MPoEe6FGllPAERWGEAmepIhHGR5rSHl/yUSqL
	Smyj1t9kvewE0LhagtoSkWuncpnf++SqR6SXwU1BCV5kHwOhD1k9TTDeZvvWel5zc+s8
	3Yiw==
Received: by 10.216.194.102 with SMTP id l80mr10964272wen.1.1335215073647;
	Mon, 23 Apr 2012 14:04:33 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104]) by mx.google.com with ESMTPS id
	ev10sm25077717wid.10.2012.04.23.14.04.32
	(version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 14:04:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Apr 2012 22:04:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CBBB826F.31605%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
Thread-Index: Ac0hlK1NDD+Dz62NyUiqAFzygkOYtg==
In-Reply-To: <CAB10MZBUPC2AyZ5CCzEOCezq+pefiqZ_SyWCb7JWVDWhJnA=TA@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/04/2012 20:11, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

>>>>> +#ifdef __x86_64__
>>>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>>>> + =A0 =A0 =A0 =A0else
>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>>>> +#endif
>>>> =

>>>> If you do anything like this, do it completely please (i.e. fill all t=
hree
>>>> base address fields instead of just one).
>>>> =

>>> =

>>> Sure. I was not sure if it was ok to add fields to the vcpu context
>>> structure which is why I didn't do it across the board. I will do so and
>>> resubmit.
>> =

>> I don't see what fields you would need to add.
> =

> Don't I need to add ss_base, cs_base, es_base, ds_base to
> vcpu_guest_context? I am assuming both 32-bit and 64-bit cases.

Only the existing (x86_64-only) fs_base, gs_base_kernel, gs_base_user fields
need be filled in. All other base addresses are zero in 64-bit mode, and in
32-bit mode the base addresses are obtained from the GDT/LDT when the
segment register is loaded, and so do not need to be stored in the
vcpu_context.

 -- Keir

> Aravindh
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 21:05:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 21:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMQR2-0001YK-Sr; Mon, 23 Apr 2012 21:04:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMQR2-0001YF-9I
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 21:04:36 +0000
Received: from [85.158.138.51:56304] by server-11.bemta-3.messagelabs.com id
	3A/61-18894-3E3C59F4; Mon, 23 Apr 2012 21:04:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335215074!23477745!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12120 invoked from network); 23 Apr 2012 21:04:34 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 21:04:34 -0000
Received: by wibhq7 with SMTP id hq7so3933826wib.14
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 14:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KGlkUzNOkVOgaVx32Ah4oB1vjwYP2HI4O2PRVBrX/9Q=;
	b=mZC4to2HjCjPCoAIdHuxJrGWncg0u1Vp8JJYKkhwq+kZjj6x2Wk+4Bps84d5U8kVHv
	EsMr31p2Ffvw5YnPsV3X7fD6GE35GevSXqLbimEjKYfoHyE9Nfj0ipiIh0oqLwuRfJlh
	dNV3Y2lhMcNGKIyH49DbioI6K5SBsMlPnfxFTWtLmJHouxbRd1rdBK8Jtr1+b6I8VbKD
	veQTeRmn4Gl7fxvg65UnLqY22XmmgY6MPoEe6FGllPAERWGEAmepIhHGR5rSHl/yUSqL
	Smyj1t9kvewE0LhagtoSkWuncpnf++SqR6SXwU1BCV5kHwOhD1k9TTDeZvvWel5zc+s8
	3Yiw==
Received: by 10.216.194.102 with SMTP id l80mr10964272wen.1.1335215073647;
	Mon, 23 Apr 2012 14:04:33 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104]) by mx.google.com with ESMTPS id
	ev10sm25077717wid.10.2012.04.23.14.04.32
	(version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 14:04:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Apr 2012 22:04:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CBBB826F.31605%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
Thread-Index: Ac0hlK1NDD+Dz62NyUiqAFzygkOYtg==
In-Reply-To: <CAB10MZBUPC2AyZ5CCzEOCezq+pefiqZ_SyWCb7JWVDWhJnA=TA@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/04/2012 20:11, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

>>>>> +#ifdef __x86_64__
>>>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>>>> + =A0 =A0 =A0 =A0else
>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>>>> +#endif
>>>> =

>>>> If you do anything like this, do it completely please (i.e. fill all t=
hree
>>>> base address fields instead of just one).
>>>> =

>>> =

>>> Sure. I was not sure if it was ok to add fields to the vcpu context
>>> structure which is why I didn't do it across the board. I will do so and
>>> resubmit.
>> =

>> I don't see what fields you would need to add.
> =

> Don't I need to add ss_base, cs_base, es_base, ds_base to
> vcpu_guest_context? I am assuming both 32-bit and 64-bit cases.

Only the existing (x86_64-only) fs_base, gs_base_kernel, gs_base_user fields
need be filled in. All other base addresses are zero in 64-bit mode, and in
32-bit mode the base addresses are obtained from the GDT/LDT when the
segment register is loaded, and so do not need to be stored in the
vcpu_context.

 -- Keir

> Aravindh
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 21:14:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 21:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMQa6-0001lP-31; Mon, 23 Apr 2012 21:13:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SMQa4-0001lK-N4
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 21:13:56 +0000
Received: from [85.158.139.83:50968] by server-11.bemta-5.messagelabs.com id
	F7/3C-12959-316C59F4; Mon, 23 Apr 2012 21:13:55 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335215634!20866537!1
X-Originating-IP: [98.138.229.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 23 Apr 2012 21:13:55 -0000
Received: from nm33-vm5.bullet.mail.ne1.yahoo.com (HELO
	nm33-vm5.bullet.mail.ne1.yahoo.com) (98.138.229.69)
	by server-14.tower-182.messagelabs.com with SMTP;
	23 Apr 2012 21:13:55 -0000
Received: from [98.138.90.53] by nm33.bullet.mail.ne1.yahoo.com with NNFMP;
	23 Apr 2012 21:13:53 -0000
Received: from [98.138.87.12] by tm6.bullet.mail.ne1.yahoo.com with NNFMP;
	23 Apr 2012 21:13:53 -0000
Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP;
	23 Apr 2012 21:13:53 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 725316.72119.bm@omp1012.mail.ne1.yahoo.com
Received: (qmail 83981 invoked by uid 60001); 23 Apr 2012 21:13:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1335215633; bh=rthnR2K8HALI3qc9LHGkG8vlxuS6dwxICpeZ5ZRi3Aw=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=ou10Io3mRlNCS6PYScw7O8Z1ViTeW54WT8scfNRFN9nfuwgMjYvIFbLZSeLTsuST7JqYcmyxHbeVP4tG/J3YO7t8BHLbPX7E06Cp1fR/SpI0Cbhg/tfFg9Wp5S0YhiIA0daxsjfqJM+pMg+0Jk1IK81cMHbKNAQrcFPfV2GkRE4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=10WmB8ArKncc6Y7EHntcy9ncXHD/tZbtTQ1Q0QPxI6aGysZMfNXnq6wwloyneu62lJxxHUDyXtyqiNWNGMbqpKkU73w2/c2zVnDMewI87evojx5oxNNl3QdiPgeN2kYVDewmJePgeoYTpbKAYgK5CcjNdx+yHerOPfU4AwYdEYo=;
X-YMail-OSG: EsMBHykVM1nvf5Wk3ckc4bMdcyP1b3mw5gchML5g8dunAbh
	DOamG0UecK1SfKs7cOtrdYMomqGZoXROOcBa3knNmH52DS37AZ9maZ8ccgFF
	BIj8G5Zv6l5kyZ5rvUWKMXT6GHsoPJm6HP5ewRJRtaAnUuzNBz4khgC0kdPQ
	dwqs656GHdO8Ez.a_Gm_XbFvU7zRMJ9yK.byyEeO9ewS1zGPS9exe_Lbhac1
	.RKDe2uUUgr_6VNHmDa._m6rAvyIAGjUpTtzWdFjnCbuCYBcEUA5iW3.vh.9
	xT0jWJqahJc6iRPGNTLL4sLwC0uFeKsgNkc691TXniyWY4N0MicfkBGpfMhU
	yTg0PscHImsAv1NmLSJ8m3_jkYs2ytMDwdIeNKgv16zCZwhZWUtI_2f82ksx
	q4B6Oc4dmsoU.5z7frnoxmCEeq3kvBGS6N0H1QeYK4U2r_CmjgA3BaVhvKV3
	pi3.LMM9peDo-
Received: from [128.173.237.43] by web124503.mail.ne1.yahoo.com via HTTP;
	Mon, 23 Apr 2012 14:13:53 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
Message-ID: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
Date: Mon, 23 Apr 2012 14:13:53 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Question about grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

I have a question regarding a grant table. I have a case when I have some s=
hared (between domains) pages mapped to the user space. I created a special=
 driver which implements mmap(). That, in turns, will execute gnttab_map_re=
fs(). This all works fine until I want to do something like exec().

After I do exec(), I want to mmap() the *same* pages (i.e. using the same g=
rant references) to some new user address space which is chosen by mmap(). =
During exec(), it will invalidate user address space, and=A0 release() from=
 mmu_notifier will be called. This means, that my driver will execute gntta=
b_unmap_refs. After exec() succeeded, I invoke mmap() again which will do g=
nttab_map_refs().

At this point I get kernel errors like this:
[=A0 198.939095] BUG: Bad page map in process a.out=A0 pte:80000002457f1167=
 pmd:245094067
[=A0 198.939099] page:ffffea000915fc40 count:1 mapcount:-1 mapping:=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 (null) index:0xffff8802d958f720
[=A0 198.939102] page flags: 0x8000000000000814(referenced|dirty|private)
[=A0 198.939109] addr:00007fd302f40000 vm_flags:000e00fb anon_vma:=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 (null) mapping:ffff8802d782f760 index:0
[=A0 198.939124] vma->vm_ops->fault: 0x0
[=A0 198.939128] vma->vm_file->f_op->mmap: syscall_driver_mmap+0x0/0xc9 [sy=
scall_driver]


So, I have two questions in this regard:
1. Does gnttab_unmap_refs removes grant references, so that I cannot use th=
em any longer? What would be proper way to preserve grant references but at=
 the same time unmap from the current user address space shared pages?

2. What happens to the counters like count, mapcount when I do gnttab_map_r=
efs() and gnntab_unmap_refs()?

Thanks,
Ruslan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 21:14:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 21:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMQa6-0001lP-31; Mon, 23 Apr 2012 21:13:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SMQa4-0001lK-N4
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 21:13:56 +0000
Received: from [85.158.139.83:50968] by server-11.bemta-5.messagelabs.com id
	F7/3C-12959-316C59F4; Mon, 23 Apr 2012 21:13:55 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335215634!20866537!1
X-Originating-IP: [98.138.229.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 23 Apr 2012 21:13:55 -0000
Received: from nm33-vm5.bullet.mail.ne1.yahoo.com (HELO
	nm33-vm5.bullet.mail.ne1.yahoo.com) (98.138.229.69)
	by server-14.tower-182.messagelabs.com with SMTP;
	23 Apr 2012 21:13:55 -0000
Received: from [98.138.90.53] by nm33.bullet.mail.ne1.yahoo.com with NNFMP;
	23 Apr 2012 21:13:53 -0000
Received: from [98.138.87.12] by tm6.bullet.mail.ne1.yahoo.com with NNFMP;
	23 Apr 2012 21:13:53 -0000
Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP;
	23 Apr 2012 21:13:53 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 725316.72119.bm@omp1012.mail.ne1.yahoo.com
Received: (qmail 83981 invoked by uid 60001); 23 Apr 2012 21:13:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1335215633; bh=rthnR2K8HALI3qc9LHGkG8vlxuS6dwxICpeZ5ZRi3Aw=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=ou10Io3mRlNCS6PYScw7O8Z1ViTeW54WT8scfNRFN9nfuwgMjYvIFbLZSeLTsuST7JqYcmyxHbeVP4tG/J3YO7t8BHLbPX7E06Cp1fR/SpI0Cbhg/tfFg9Wp5S0YhiIA0daxsjfqJM+pMg+0Jk1IK81cMHbKNAQrcFPfV2GkRE4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=10WmB8ArKncc6Y7EHntcy9ncXHD/tZbtTQ1Q0QPxI6aGysZMfNXnq6wwloyneu62lJxxHUDyXtyqiNWNGMbqpKkU73w2/c2zVnDMewI87evojx5oxNNl3QdiPgeN2kYVDewmJePgeoYTpbKAYgK5CcjNdx+yHerOPfU4AwYdEYo=;
X-YMail-OSG: EsMBHykVM1nvf5Wk3ckc4bMdcyP1b3mw5gchML5g8dunAbh
	DOamG0UecK1SfKs7cOtrdYMomqGZoXROOcBa3knNmH52DS37AZ9maZ8ccgFF
	BIj8G5Zv6l5kyZ5rvUWKMXT6GHsoPJm6HP5ewRJRtaAnUuzNBz4khgC0kdPQ
	dwqs656GHdO8Ez.a_Gm_XbFvU7zRMJ9yK.byyEeO9ewS1zGPS9exe_Lbhac1
	.RKDe2uUUgr_6VNHmDa._m6rAvyIAGjUpTtzWdFjnCbuCYBcEUA5iW3.vh.9
	xT0jWJqahJc6iRPGNTLL4sLwC0uFeKsgNkc691TXniyWY4N0MicfkBGpfMhU
	yTg0PscHImsAv1NmLSJ8m3_jkYs2ytMDwdIeNKgv16zCZwhZWUtI_2f82ksx
	q4B6Oc4dmsoU.5z7frnoxmCEeq3kvBGS6N0H1QeYK4U2r_CmjgA3BaVhvKV3
	pi3.LMM9peDo-
Received: from [128.173.237.43] by web124503.mail.ne1.yahoo.com via HTTP;
	Mon, 23 Apr 2012 14:13:53 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
Message-ID: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
Date: Mon, 23 Apr 2012 14:13:53 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Question about grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

I have a question regarding a grant table. I have a case when I have some s=
hared (between domains) pages mapped to the user space. I created a special=
 driver which implements mmap(). That, in turns, will execute gnttab_map_re=
fs(). This all works fine until I want to do something like exec().

After I do exec(), I want to mmap() the *same* pages (i.e. using the same g=
rant references) to some new user address space which is chosen by mmap(). =
During exec(), it will invalidate user address space, and=A0 release() from=
 mmu_notifier will be called. This means, that my driver will execute gntta=
b_unmap_refs. After exec() succeeded, I invoke mmap() again which will do g=
nttab_map_refs().

At this point I get kernel errors like this:
[=A0 198.939095] BUG: Bad page map in process a.out=A0 pte:80000002457f1167=
 pmd:245094067
[=A0 198.939099] page:ffffea000915fc40 count:1 mapcount:-1 mapping:=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 (null) index:0xffff8802d958f720
[=A0 198.939102] page flags: 0x8000000000000814(referenced|dirty|private)
[=A0 198.939109] addr:00007fd302f40000 vm_flags:000e00fb anon_vma:=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 (null) mapping:ffff8802d782f760 index:0
[=A0 198.939124] vma->vm_ops->fault: 0x0
[=A0 198.939128] vma->vm_file->f_op->mmap: syscall_driver_mmap+0x0/0xc9 [sy=
scall_driver]


So, I have two questions in this regard:
1. Does gnttab_unmap_refs removes grant references, so that I cannot use th=
em any longer? What would be proper way to preserve grant references but at=
 the same time unmap from the current user address space shared pages?

2. What happens to the counters like count, mapcount when I do gnttab_map_r=
efs() and gnntab_unmap_refs()?

Thanks,
Ruslan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 22:12:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 22:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMRU0-0002Hu-Ux; Mon, 23 Apr 2012 22:11:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMRTz-0002Hp-Lt
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 22:11:43 +0000
Received: from [193.109.254.147:39382] by server-8.bemta-14.messagelabs.com id
	67/71-23244-E93D59F4; Mon, 23 Apr 2012 22:11:42 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335219101!5988262!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26673 invoked from network); 23 Apr 2012 22:11:42 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 22:11:42 -0000
Received: by lboi15 with SMTP id i15so24942lbo.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 15:11:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=s7mnohCQyGbdxxKShhZtXp3Nh3chDu0okDsj92kizus=;
	b=2jq256ugvem+LE4fTKkA88bNYSPpBLbBiy9R31s/dUOZnEZyvj3Z5N3iQanZT2LUGY
	TfjvPxhd0QEuCEZdZeyT3gaWThLf1ENDxpDD0EPmHv0jkd6HveGEvLT64azlus3zeGQG
	UK85fhziNd1uJwdu9x+k2jTmoT2YsgrQKhH/4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=s7mnohCQyGbdxxKShhZtXp3Nh3chDu0okDsj92kizus=;
	b=enJ5VCo7D0wJNhrRS1wivw4HagL9YfI7EYTjjIQym36P2a1j9IibUKkUhk1MbwlnqX
	dRvjjvAhMjZvVehVMShpGxBm6D3ooIfHtDQoznRVR0RkMEXlH18NW3LeYNdcM+LAAZ4j
	aiivM1t2t5e5NX32wcxw64JrkFBhoyh6SS24cszfOo3J/hqB3lQD77wpeo65Nxv3ugEP
	XvSpEPhC/W38KgYTF96Jl5jYIqUlXes7RQZDcszCY3opS9pL+o6fje++p9R3ULSpux7x
	w6apntkFlJUwKBttMx+k2PPWW/E/emjt+VQTGxX0qMUbnFYuqz/u+ZFgwK+60l3JHNd1
	yM8Q==
MIME-Version: 1.0
Received: by 10.112.47.69 with SMTP id b5mr8310170lbn.17.1335219100988; Mon,
	23 Apr 2012 15:11:40 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 15:11:40 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <CBBB826F.31605%keir.xen@gmail.com>
References: <CAB10MZBUPC2AyZ5CCzEOCezq+pefiqZ_SyWCb7JWVDWhJnA=TA@mail.gmail.com>
	<CBBB826F.31605%keir.xen@gmail.com>
Date: Mon, 23 Apr 2012 15:11:40 -0700
Message-ID: <CAB10MZCs64H0EZ3+ZurRNs0f4Z_bqqXhp8UE2bLOA7uOT5_W0A@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Keir Fraser <keir.xen@gmail.com>
X-Gm-Message-State: ALoCoQn6lUoef5wphupBdoF228i8p/72Rsebj1/cSUL1tTp8eB+VD6Veg+F8CdrTM5Y98Ci608rQ
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 2:04 PM, Keir Fraser <keir.xen@gmail.com> wrote:
> On 23/04/2012 20:11, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
>
>>>>>> +#ifdef __x86_64__
>>>>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>>>>> + =A0 =A0 =A0 =A0else
>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>>>>> +#endif
>>>>>
>>>>> If you do anything like this, do it completely please (i.e. fill all =
three
>>>>> base address fields instead of just one).
>>>>>
>>>>
>>>> Sure. I was not sure if it was ok to add fields to the vcpu context
>>>> structure which is why I didn't do it across the board. I will do so a=
nd
>>>> resubmit.
>>>
>>> I don't see what fields you would need to add.
>>
>> Don't I need to add ss_base, cs_base, es_base, ds_base to
>> vcpu_guest_context? I am assuming both 32-bit and 64-bit cases.
>
> Only the existing (x86_64-only) fs_base, gs_base_kernel, gs_base_user fie=
lds
> need be filled in. All other base addresses are zero in 64-bit mode, and =
in
> 32-bit mode the base addresses are obtained from the GDT/LDT when the
> segment register is loaded, and so do not need to be stored in the
> vcpu_context.

Understood. I will resubmit with fs_based filled in.

Aravindh

> =A0-- Keir
>
>> Aravindh
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 22:12:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 22:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMRU0-0002Hu-Ux; Mon, 23 Apr 2012 22:11:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMRTz-0002Hp-Lt
	for xen-devel@lists.xen.org; Mon, 23 Apr 2012 22:11:43 +0000
Received: from [193.109.254.147:39382] by server-8.bemta-14.messagelabs.com id
	67/71-23244-E93D59F4; Mon, 23 Apr 2012 22:11:42 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335219101!5988262!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26673 invoked from network); 23 Apr 2012 22:11:42 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 22:11:42 -0000
Received: by lboi15 with SMTP id i15so24942lbo.32
	for <xen-devel@lists.xen.org>; Mon, 23 Apr 2012 15:11:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=s7mnohCQyGbdxxKShhZtXp3Nh3chDu0okDsj92kizus=;
	b=2jq256ugvem+LE4fTKkA88bNYSPpBLbBiy9R31s/dUOZnEZyvj3Z5N3iQanZT2LUGY
	TfjvPxhd0QEuCEZdZeyT3gaWThLf1ENDxpDD0EPmHv0jkd6HveGEvLT64azlus3zeGQG
	UK85fhziNd1uJwdu9x+k2jTmoT2YsgrQKhH/4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=s7mnohCQyGbdxxKShhZtXp3Nh3chDu0okDsj92kizus=;
	b=enJ5VCo7D0wJNhrRS1wivw4HagL9YfI7EYTjjIQym36P2a1j9IibUKkUhk1MbwlnqX
	dRvjjvAhMjZvVehVMShpGxBm6D3ooIfHtDQoznRVR0RkMEXlH18NW3LeYNdcM+LAAZ4j
	aiivM1t2t5e5NX32wcxw64JrkFBhoyh6SS24cszfOo3J/hqB3lQD77wpeo65Nxv3ugEP
	XvSpEPhC/W38KgYTF96Jl5jYIqUlXes7RQZDcszCY3opS9pL+o6fje++p9R3ULSpux7x
	w6apntkFlJUwKBttMx+k2PPWW/E/emjt+VQTGxX0qMUbnFYuqz/u+ZFgwK+60l3JHNd1
	yM8Q==
MIME-Version: 1.0
Received: by 10.112.47.69 with SMTP id b5mr8310170lbn.17.1335219100988; Mon,
	23 Apr 2012 15:11:40 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Mon, 23 Apr 2012 15:11:40 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <CBBB826F.31605%keir.xen@gmail.com>
References: <CAB10MZBUPC2AyZ5CCzEOCezq+pefiqZ_SyWCb7JWVDWhJnA=TA@mail.gmail.com>
	<CBBB826F.31605%keir.xen@gmail.com>
Date: Mon, 23 Apr 2012 15:11:40 -0700
Message-ID: <CAB10MZCs64H0EZ3+ZurRNs0f4Z_bqqXhp8UE2bLOA7uOT5_W0A@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Keir Fraser <keir.xen@gmail.com>
X-Gm-Message-State: ALoCoQn6lUoef5wphupBdoF228i8p/72Rsebj1/cSUL1tTp8eB+VD6Veg+F8CdrTM5Y98Ci608rQ
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Add GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 2:04 PM, Keir Fraser <keir.xen@gmail.com> wrote:
> On 23/04/2012 20:11, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
>
>>>>>> +#ifdef __x86_64__
>>>>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>>>>> + =A0 =A0 =A0 =A0else
>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>>>>> +#endif
>>>>>
>>>>> If you do anything like this, do it completely please (i.e. fill all =
three
>>>>> base address fields instead of just one).
>>>>>
>>>>
>>>> Sure. I was not sure if it was ok to add fields to the vcpu context
>>>> structure which is why I didn't do it across the board. I will do so a=
nd
>>>> resubmit.
>>>
>>> I don't see what fields you would need to add.
>>
>> Don't I need to add ss_base, cs_base, es_base, ds_base to
>> vcpu_guest_context? I am assuming both 32-bit and 64-bit cases.
>
> Only the existing (x86_64-only) fs_base, gs_base_kernel, gs_base_user fie=
lds
> need be filled in. All other base addresses are zero in 64-bit mode, and =
in
> 32-bit mode the base addresses are obtained from the GDT/LDT when the
> segment register is loaded, and so do not need to be stored in the
> vcpu_context.

Understood. I will resubmit with fs_based filled in.

Aravindh

> =A0-- Keir
>
>> Aravindh
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 22:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 22:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMRdc-0002RG-3Y; Mon, 23 Apr 2012 22:21:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMRda-0002RB-Q7
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 22:21:39 +0000
Received: from [85.158.139.83:14284] by server-8.bemta-5.messagelabs.com id
	FD/7F-26964-2F5D59F4; Mon, 23 Apr 2012 22:21:38 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335219695!25137757!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 615 invoked from network); 23 Apr 2012 22:21:36 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 22:21:36 -0000
Received: by obbtb18 with SMTP id tb18so59741obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 15:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=QmleYi5f/9C8xU0+4PjU2IzmJYw2tVksgAfB7Lnm4Gc=;
	b=nZnlDGVCiHNzGFQnEi5DrD2daQQUfZlqRNaCSuEYL2mGLJKJv5VEyFfnqGkbl3Jipm
	jIljW1o1izjLDKxOwD6JBfSMaPNFLoX86/LABdbpZRFKfXTmRj6x0/PWWwkUbkQA7q+j
	LGxPdJ0QppM/KmBGm9mEwwcmB2z1D7b/jhnrc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=QmleYi5f/9C8xU0+4PjU2IzmJYw2tVksgAfB7Lnm4Gc=;
	b=VuxuGQw7oia5LDejtSZljwMz6rEfn61C43MNR0KBztFnO3TGbC3grp+gGvVR9juTAc
	tM4B64fkyK3FE4wVc3Dvb14T9i47BzE/q5q23wvvXLnD+eS+ml0Ohob6ZQ/Ky/SRGYu8
	7tRXqoK8CHjsz6FkWYFeyE5pTWDiSFDDpA2l36paf13iPSM1XCdrpTyP1GvSHeji7X0u
	GWfhFbBeHzn25rT1B0l7QN4O8C0R/8vVQQZHuSghZoI4TOvSO9u/x75ZJF0YgQ/XC2wA
	C2Ved0ZwRnUh9pWdAkWS9GrnqSGiG1Y/ZbO6AgNhWSFe5u5z4qoE3E+5akPjYVkvyOxP
	ee0Q==
Received: by 10.182.113.106 with SMTP id ix10mr25263004obb.26.1335219695165;
	Mon, 23 Apr 2012 15:21:35 -0700 (PDT)
Received: from [127.0.1.1] (108-92-21-169.uvs.sntcca.sbcglobal.net.
	[108.92.21.169])
	by mx.google.com with ESMTPS id n9sm14430307oen.2.2012.04.23.15.21.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Apr 2012 15:21:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6ef297a3761f3061d2e8126f6beee567dfcb646e
Message-Id: <6ef297a3761f3061d2e8.1335219661@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 23 Apr 2012 15:21:01 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnBk1xOTqtB4EsJxCpK5ajtWaFK2Ky9wlG5AgW4fVgeurGLNfBmOULGPGbAa8gXxSYhh+0y
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap() for
 array sizes greater than a page in xc_linux_osdep.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.

Fix an error print with the correct function name.

Do the same for the map array in linux_gnttab_grant_map()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 274e5accd62d -r 6ef297a3761f tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Fri Apr 20 09:49:06 2012 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Mon Apr 23 15:16:34 2012 -0700
@@ -39,6 +39,7 @@
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
 
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
@@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
                 fd, 0);
     if ( addr == MAP_FAILED )
     {
-        PERROR("xc_map_foreign_batch: mmap failed");
+        PERROR("xc_map_foreign_bulk: mmap failed");
         return NULL;
     }
 
@@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn;
+        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
+
+        if ( pfn_arr_size <= XC_PAGE_SIZE )
+            pfn = alloca(num * sizeof(*pfn));
+        else
+        {
+            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
+                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+            if ( pfn == MAP_FAILED )
+            {
+                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+                return NULL;
+            }
+        }
 
         memcpy(pfn, arr, num * sizeof(*arr));
 
@@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
             break;
         }
 
+        if ( pfn_arr_size > XC_PAGE_SIZE )
+            munmap(pfn, pfn_arr_size);
+
         if ( rc == -ENOENT && i == num )
             rc = 0;
         else if ( rc )
@@ -549,6 +567,9 @@ static void *linux_gnttab_grant_map(xc_g
 {
     int fd = (int)h;
     struct ioctl_gntdev_map_grant_ref *map;
+    unsigned int map_size = ROUNDUP((sizeof(*map) + (count - 1) *
+                                    sizeof(struct ioctl_gntdev_map_grant_ref)),
+                                    XC_PAGE_SHIFT);
     void *addr = NULL;
     int domids_stride = 1;
     int i;
@@ -556,8 +577,19 @@ static void *linux_gnttab_grant_map(xc_g
     if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
         domids_stride = 0;
 
-    map = alloca(sizeof(*map) +
-                 (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
+    if ( map_size <= XC_PAGE_SIZE )
+        map = alloca(sizeof(*map) +
+                     (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
+    else
+    {
+        map = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
+                   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+        if ( map == MAP_FAILED )
+        {
+            PERROR("linux_gnttab_grant_map: mmap of map failed");
+            return NULL;
+        }
+    }
 
     for ( i = 0; i < count; i++ )
     {
@@ -628,6 +660,8 @@ static void *linux_gnttab_grant_map(xc_g
     }
 
  out:
+    if ( map_size > XC_PAGE_SIZE )
+        munmap(map, map_size);
 
     return addr;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 22:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 22:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMRdc-0002RG-3Y; Mon, 23 Apr 2012 22:21:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMRda-0002RB-Q7
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 22:21:39 +0000
Received: from [85.158.139.83:14284] by server-8.bemta-5.messagelabs.com id
	FD/7F-26964-2F5D59F4; Mon, 23 Apr 2012 22:21:38 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335219695!25137757!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 615 invoked from network); 23 Apr 2012 22:21:36 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 22:21:36 -0000
Received: by obbtb18 with SMTP id tb18so59741obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 15:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=QmleYi5f/9C8xU0+4PjU2IzmJYw2tVksgAfB7Lnm4Gc=;
	b=nZnlDGVCiHNzGFQnEi5DrD2daQQUfZlqRNaCSuEYL2mGLJKJv5VEyFfnqGkbl3Jipm
	jIljW1o1izjLDKxOwD6JBfSMaPNFLoX86/LABdbpZRFKfXTmRj6x0/PWWwkUbkQA7q+j
	LGxPdJ0QppM/KmBGm9mEwwcmB2z1D7b/jhnrc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=QmleYi5f/9C8xU0+4PjU2IzmJYw2tVksgAfB7Lnm4Gc=;
	b=VuxuGQw7oia5LDejtSZljwMz6rEfn61C43MNR0KBztFnO3TGbC3grp+gGvVR9juTAc
	tM4B64fkyK3FE4wVc3Dvb14T9i47BzE/q5q23wvvXLnD+eS+ml0Ohob6ZQ/Ky/SRGYu8
	7tRXqoK8CHjsz6FkWYFeyE5pTWDiSFDDpA2l36paf13iPSM1XCdrpTyP1GvSHeji7X0u
	GWfhFbBeHzn25rT1B0l7QN4O8C0R/8vVQQZHuSghZoI4TOvSO9u/x75ZJF0YgQ/XC2wA
	C2Ved0ZwRnUh9pWdAkWS9GrnqSGiG1Y/ZbO6AgNhWSFe5u5z4qoE3E+5akPjYVkvyOxP
	ee0Q==
Received: by 10.182.113.106 with SMTP id ix10mr25263004obb.26.1335219695165;
	Mon, 23 Apr 2012 15:21:35 -0700 (PDT)
Received: from [127.0.1.1] (108-92-21-169.uvs.sntcca.sbcglobal.net.
	[108.92.21.169])
	by mx.google.com with ESMTPS id n9sm14430307oen.2.2012.04.23.15.21.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Apr 2012 15:21:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6ef297a3761f3061d2e8126f6beee567dfcb646e
Message-Id: <6ef297a3761f3061d2e8.1335219661@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 23 Apr 2012 15:21:01 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnBk1xOTqtB4EsJxCpK5ajtWaFK2Ky9wlG5AgW4fVgeurGLNfBmOULGPGbAa8gXxSYhh+0y
Cc: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap() for
 array sizes greater than a page in xc_linux_osdep.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.

Fix an error print with the correct function name.

Do the same for the map array in linux_gnttab_grant_map()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 274e5accd62d -r 6ef297a3761f tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Fri Apr 20 09:49:06 2012 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Mon Apr 23 15:16:34 2012 -0700
@@ -39,6 +39,7 @@
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
 
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
@@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
                 fd, 0);
     if ( addr == MAP_FAILED )
     {
-        PERROR("xc_map_foreign_batch: mmap failed");
+        PERROR("xc_map_foreign_bulk: mmap failed");
         return NULL;
     }
 
@@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
         privcmd_mmapbatch_t ioctlx;
-        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
+        xen_pfn_t *pfn;
+        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
+
+        if ( pfn_arr_size <= XC_PAGE_SIZE )
+            pfn = alloca(num * sizeof(*pfn));
+        else
+        {
+            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
+                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+            if ( pfn == MAP_FAILED )
+            {
+                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
+                return NULL;
+            }
+        }
 
         memcpy(pfn, arr, num * sizeof(*arr));
 
@@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
             break;
         }
 
+        if ( pfn_arr_size > XC_PAGE_SIZE )
+            munmap(pfn, pfn_arr_size);
+
         if ( rc == -ENOENT && i == num )
             rc = 0;
         else if ( rc )
@@ -549,6 +567,9 @@ static void *linux_gnttab_grant_map(xc_g
 {
     int fd = (int)h;
     struct ioctl_gntdev_map_grant_ref *map;
+    unsigned int map_size = ROUNDUP((sizeof(*map) + (count - 1) *
+                                    sizeof(struct ioctl_gntdev_map_grant_ref)),
+                                    XC_PAGE_SHIFT);
     void *addr = NULL;
     int domids_stride = 1;
     int i;
@@ -556,8 +577,19 @@ static void *linux_gnttab_grant_map(xc_g
     if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
         domids_stride = 0;
 
-    map = alloca(sizeof(*map) +
-                 (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
+    if ( map_size <= XC_PAGE_SIZE )
+        map = alloca(sizeof(*map) +
+                     (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
+    else
+    {
+        map = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
+                   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+        if ( map == MAP_FAILED )
+        {
+            PERROR("linux_gnttab_grant_map: mmap of map failed");
+            return NULL;
+        }
+    }
 
     for ( i = 0; i < count; i++ )
     {
@@ -628,6 +660,8 @@ static void *linux_gnttab_grant_map(xc_g
     }
 
  out:
+    if ( map_size > XC_PAGE_SIZE )
+        munmap(map, map_size);
 
     return addr;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 23:17:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 23:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMSUl-00038M-4S; Mon, 23 Apr 2012 23:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMSUk-00038G-5y
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 23:16:34 +0000
Received: from [85.158.143.35:25936] by server-2.bemta-4.messagelabs.com id
	2B/09-17550-1D2E59F4; Mon, 23 Apr 2012 23:16:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335222991!14584643!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31994 invoked from network); 23 Apr 2012 23:16:32 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 23:16:32 -0000
Received: by obbtb18 with SMTP id tb18so125209obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 16:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=wYd3qJY1dbJ2Kj+v7+Y+HRhBLr46L4I/nLwJJd5zlbc=;
	b=4sPyxD0Dn5VkG6AxBoXbHPqTUzqnSA4Ut1Rlp/kCrXCykSGAx7srq5zK0W3/hoUFEq
	Z41YQsxFQSo9niMImWk7/VqEJWjS2xaYlAOOAtNycwUKv4v61bjjYQ77lJTcsLNaV79l
	0DmYXj9D+r5hGuqNtBkfrQIRAQzLNAM4MXxbM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to
	:x-gm-message-state;
	bh=wYd3qJY1dbJ2Kj+v7+Y+HRhBLr46L4I/nLwJJd5zlbc=;
	b=naNodmxGrhGG/0+/u0g1Ss341G6OYtsBEsKojSLLOFx5WHjQV/zvoY3w+dbvs6asLV
	2dmdFSeXLgKDvMoLjaYhF4Bc6ODBqmrB9sAmslXS73ElDwYBRyH1OqGKdq2whlWy+xcV
	mpJjIxh8rRbG84I+nDD1aUo3MYijizOCg7PPsKpfQw9dvF9qkQnf+a7XXgVIJgml0mUl
	n+7WG8MaVEKAwfYwAIkxllTxygulDe2yNdIPbseRL98yHJmRnbbT2FXjVKuLRQZ4m/Z0
	QaIT3PVlQqF86TTEdjjySzc9HpeTf+CAYp1y/JgbCWF37bh1ilHRWJRzwkxSMeu+U+k9
	h2TQ==
Received: by 10.60.0.201 with SMTP id 9mr24585439oeg.59.1335222990665;
	Mon, 23 Apr 2012 16:16:30 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-73.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.73])
	by mx.google.com with ESMTPS id c6sm14543821oec.13.2012.04.23.16.16.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Apr 2012 16:16:29 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f7a1633867bfeb30f83d94530ab57044c307f13e
Message-Id: <f7a1633867bfeb30f83d.1335222981@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 23 Apr 2012 16:16:21 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQlb3pMf/B+Ad29iwQla/OBim0FRJJkb7FtBUC09yUiAg9jb9TF8z8OaRAGh4zmdqlyHXGB6
Subject: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/arch/x86/domctl.c	Mon Apr 23 16:12:50 2012 -0700
@@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
         c.nat->user_regs.es = sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs = sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base = sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs = sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+            c.nat->gs_base_kernel = sreg.base;
+        else
+            c.nat->gs_base_user = sreg.base;
+#endif
     }
     else
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 23 23:17:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Apr 2012 23:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMSUl-00038M-4S; Mon, 23 Apr 2012 23:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMSUk-00038G-5y
	for xen-devel@lists.xensource.com; Mon, 23 Apr 2012 23:16:34 +0000
Received: from [85.158.143.35:25936] by server-2.bemta-4.messagelabs.com id
	2B/09-17550-1D2E59F4; Mon, 23 Apr 2012 23:16:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335222991!14584643!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31994 invoked from network); 23 Apr 2012 23:16:32 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Apr 2012 23:16:32 -0000
Received: by obbtb18 with SMTP id tb18so125209obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Apr 2012 16:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=wYd3qJY1dbJ2Kj+v7+Y+HRhBLr46L4I/nLwJJd5zlbc=;
	b=4sPyxD0Dn5VkG6AxBoXbHPqTUzqnSA4Ut1Rlp/kCrXCykSGAx7srq5zK0W3/hoUFEq
	Z41YQsxFQSo9niMImWk7/VqEJWjS2xaYlAOOAtNycwUKv4v61bjjYQ77lJTcsLNaV79l
	0DmYXj9D+r5hGuqNtBkfrQIRAQzLNAM4MXxbM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to
	:x-gm-message-state;
	bh=wYd3qJY1dbJ2Kj+v7+Y+HRhBLr46L4I/nLwJJd5zlbc=;
	b=naNodmxGrhGG/0+/u0g1Ss341G6OYtsBEsKojSLLOFx5WHjQV/zvoY3w+dbvs6asLV
	2dmdFSeXLgKDvMoLjaYhF4Bc6ODBqmrB9sAmslXS73ElDwYBRyH1OqGKdq2whlWy+xcV
	mpJjIxh8rRbG84I+nDD1aUo3MYijizOCg7PPsKpfQw9dvF9qkQnf+a7XXgVIJgml0mUl
	n+7WG8MaVEKAwfYwAIkxllTxygulDe2yNdIPbseRL98yHJmRnbbT2FXjVKuLRQZ4m/Z0
	QaIT3PVlQqF86TTEdjjySzc9HpeTf+CAYp1y/JgbCWF37bh1ilHRWJRzwkxSMeu+U+k9
	h2TQ==
Received: by 10.60.0.201 with SMTP id 9mr24585439oeg.59.1335222990665;
	Mon, 23 Apr 2012 16:16:30 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-73.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.73])
	by mx.google.com with ESMTPS id c6sm14543821oec.13.2012.04.23.16.16.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Apr 2012 16:16:29 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f7a1633867bfeb30f83d94530ab57044c307f13e
Message-Id: <f7a1633867bfeb30f83d.1335222981@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 23 Apr 2012 16:16:21 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQlb3pMf/B+Ad29iwQla/OBim0FRJJkb7FtBUC09yUiAg9jb9TF8z8OaRAGh4zmdqlyHXGB6
Subject: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/arch/x86/domctl.c	Mon Apr 23 16:12:50 2012 -0700
@@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
         c.nat->user_regs.es = sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs = sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base = sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs = sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+            c.nat->gs_base_kernel = sreg.base;
+        else
+            c.nat->gs_base_user = sreg.base;
+#endif
     }
     else
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 01:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 01:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMUhC-0008C6-H2; Tue, 24 Apr 2012 01:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SMUhB-0008C1-Bm
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 01:37:33 +0000
Received: from [85.158.143.99:64234] by server-2.bemta-4.messagelabs.com id
	9D/0B-17550-CD3069F4; Tue, 24 Apr 2012 01:37:32 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335231449!15311630!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg3OTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 389 invoked from network); 24 Apr 2012 01:37:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 01:37:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3O1bHoI024842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 01:37:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3O1bG2n002723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 01:37:16 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3O1bFpQ020494; Mon, 23 Apr 2012 20:37:16 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 18:37:15 -0700
Date: Mon, 23 Apr 2012 18:37:09 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120423183709.5636656f@mantra.us.oracle.com>
In-Reply-To: <20120419141527.GB23663@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 19 Apr 2012 15:15:27 +0100
Tim Deegan <tim@xen.org> wrote:

> At 18:29 -0700 on 13 Apr (1334341792), Mukesh Rathor wrote:
>  - AFAICT you're using set_mmio_p2m_entry and adding a new unmap
>    operation just to avoid having the m2p updated.  Since you can't
> rely on the unmap always happening through the new call (and you don't
>    enforce it anywhere), it would be better to add a new p2m_type
>    just for non-grant foreign mappings.  Then you can gate the m2p
>    updates in the existing code on the map being normal RAM, as is
>    already done for p2m_is_grant().
 
Hi Tim,

The variants of get_page* are confusing me, so wanna double check with 
you.  I should be able to do something like following, right?


/* add frames from foreign domain to current domain physmap. Similar to 
 * XENMEM_add_to_physmap but the frame is foreign being mapped into current,
 * and is not removed from foreign domain.  */
static long noinline _add_foreign_to_pmap_batch(struct xen_add_to_physmap *xpmp)
{
    unsigned long rc, prev_mfn, mfn = 0;
    struct domain *fdom, *currd = current->domain;
    unsigned long fgmfn = xpmp->idx, gpfn = xpmp->gpfn;
    p2m_type_t p2mt;

    if ( (fdom = get_pg_owner(xpmp->foreign_domid)) == NULL ) {
        return -EPERM;
    }

    mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));
    if ( !p2m_is_valid(p2mt) ) {
        put_pg_owner(fdom);
        return -EINVAL;
    }
    if ( (rc=get_page_and_type_from_pagenr(mfn, PGT_writable_page,fdom,0,0)) ) {
        put_pg_owner(fdom);
        return rc;
    }

    /* Remove previously mapped page if it was present. */
    prev_mfn = gmfn_to_mfn(currd, gpfn);
    if ( mfn_valid(prev_mfn) )
    {
        if ( is_xen_heap_mfn(prev_mfn) )
            /* Xen heap frames are simply unhooked from this phys slot */
            guest_physmap_remove_page(currd, gpfn, prev_mfn, 0);
        else
            /* Normal domain memory is freed, to avoid leaking memory. */
            guest_remove_page(currd, gpfn);
    }
    
    if (set_foreign_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn) == 0) {
        printk("guest_physmap_add_page failed. gpfn:%lx mfn:%lx fgmfn:%lx\n", 
             gpfn, mfn, fgmfn);
        rc = -EINVAL;      ??????????????
    }

    put_pg_owner(fdom);
    return rc;
}

/* Returns: True for success. 0 for failure */
int
set_foreign_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn)
{
    int rc = 0;
    p2m_type_t ot;
    mfn_t omfn;

    if ( !paging_mode_translate(p2m->domain) )
        return 0;

    omfn = gfn_to_mfn_query(p2m, gfn, &ot);
    if (mfn_valid(omfn)) {
        gdprintk(XENLOG_ERR, "Already mapped mfn %lx at gfn:%lx\n", omfn, gfn);
        set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
    }

    P2M_DEBUG("set foreign %lx %lx\n", gfn, mfn_x(mfn));
    p2m_lock(p2m);
    rc = set_p2m_entry(p2m, gfn, mfn, 0, p2m_map_foreign, p2m->default_access);
    audit_p2m(p2m, 1);
    p2m_unlock(p2m);
    if ( rc == 0 )
        gdprintk(XENLOG_ERR,
            "set_foreign_p2m_entry: set_p2m_entry failed! gfn:%lx mfn=%08lx\n",
            gfn, mfn_x(gfn_to_mfn(p2m, gfn, &ot)));
    return rc;
}



thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 01:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 01:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMUhC-0008C6-H2; Tue, 24 Apr 2012 01:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SMUhB-0008C1-Bm
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 01:37:33 +0000
Received: from [85.158.143.99:64234] by server-2.bemta-4.messagelabs.com id
	9D/0B-17550-CD3069F4; Tue, 24 Apr 2012 01:37:32 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335231449!15311630!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg3OTg2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 389 invoked from network); 24 Apr 2012 01:37:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 01:37:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3O1bHoI024842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 01:37:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3O1bG2n002723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 01:37:16 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3O1bFpQ020494; Mon, 23 Apr 2012 20:37:16 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Apr 2012 18:37:15 -0700
Date: Mon, 23 Apr 2012 18:37:09 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120423183709.5636656f@mantra.us.oracle.com>
In-Reply-To: <20120419141527.GB23663@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 19 Apr 2012 15:15:27 +0100
Tim Deegan <tim@xen.org> wrote:

> At 18:29 -0700 on 13 Apr (1334341792), Mukesh Rathor wrote:
>  - AFAICT you're using set_mmio_p2m_entry and adding a new unmap
>    operation just to avoid having the m2p updated.  Since you can't
> rely on the unmap always happening through the new call (and you don't
>    enforce it anywhere), it would be better to add a new p2m_type
>    just for non-grant foreign mappings.  Then you can gate the m2p
>    updates in the existing code on the map being normal RAM, as is
>    already done for p2m_is_grant().
 
Hi Tim,

The variants of get_page* are confusing me, so wanna double check with 
you.  I should be able to do something like following, right?


/* add frames from foreign domain to current domain physmap. Similar to 
 * XENMEM_add_to_physmap but the frame is foreign being mapped into current,
 * and is not removed from foreign domain.  */
static long noinline _add_foreign_to_pmap_batch(struct xen_add_to_physmap *xpmp)
{
    unsigned long rc, prev_mfn, mfn = 0;
    struct domain *fdom, *currd = current->domain;
    unsigned long fgmfn = xpmp->idx, gpfn = xpmp->gpfn;
    p2m_type_t p2mt;

    if ( (fdom = get_pg_owner(xpmp->foreign_domid)) == NULL ) {
        return -EPERM;
    }

    mfn = mfn_x(gfn_to_mfn_query(p2m_get_hostp2m(fdom), fgmfn, &p2mt));
    if ( !p2m_is_valid(p2mt) ) {
        put_pg_owner(fdom);
        return -EINVAL;
    }
    if ( (rc=get_page_and_type_from_pagenr(mfn, PGT_writable_page,fdom,0,0)) ) {
        put_pg_owner(fdom);
        return rc;
    }

    /* Remove previously mapped page if it was present. */
    prev_mfn = gmfn_to_mfn(currd, gpfn);
    if ( mfn_valid(prev_mfn) )
    {
        if ( is_xen_heap_mfn(prev_mfn) )
            /* Xen heap frames are simply unhooked from this phys slot */
            guest_physmap_remove_page(currd, gpfn, prev_mfn, 0);
        else
            /* Normal domain memory is freed, to avoid leaking memory. */
            guest_remove_page(currd, gpfn);
    }
    
    if (set_foreign_p2m_entry(p2m_get_hostp2m(currd), gpfn, mfn) == 0) {
        printk("guest_physmap_add_page failed. gpfn:%lx mfn:%lx fgmfn:%lx\n", 
             gpfn, mfn, fgmfn);
        rc = -EINVAL;      ??????????????
    }

    put_pg_owner(fdom);
    return rc;
}

/* Returns: True for success. 0 for failure */
int
set_foreign_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn)
{
    int rc = 0;
    p2m_type_t ot;
    mfn_t omfn;

    if ( !paging_mode_translate(p2m->domain) )
        return 0;

    omfn = gfn_to_mfn_query(p2m, gfn, &ot);
    if (mfn_valid(omfn)) {
        gdprintk(XENLOG_ERR, "Already mapped mfn %lx at gfn:%lx\n", omfn, gfn);
        set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
    }

    P2M_DEBUG("set foreign %lx %lx\n", gfn, mfn_x(mfn));
    p2m_lock(p2m);
    rc = set_p2m_entry(p2m, gfn, mfn, 0, p2m_map_foreign, p2m->default_access);
    audit_p2m(p2m, 1);
    p2m_unlock(p2m);
    if ( rc == 0 )
        gdprintk(XENLOG_ERR,
            "set_foreign_p2m_entry: set_p2m_entry failed! gfn:%lx mfn=%08lx\n",
            gfn, mfn_x(gfn_to_mfn(p2m, gfn, &ot)));
    return rc;
}



thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 02:51:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 02:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMVqH-0000bl-55; Tue, 24 Apr 2012 02:51:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMVqF-0000bg-4X
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 02:50:59 +0000
Received: from [85.158.139.83:57606] by server-8.bemta-5.messagelabs.com id
	72/D1-26964-215169F4; Tue, 24 Apr 2012 02:50:58 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335235855!21219107!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwMTQz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18546 invoked from network); 24 Apr 2012 02:50:57 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 02:50:57 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 23 Apr 2012 19:50:14 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134462618"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 23 Apr 2012 19:50:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 19:50:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Tue, 24 Apr 2012 10:49:59 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
Thread-Index: AQHNISXIc8j5BFQpcEi9A9wrjU2645apPZlA
Date: Tue, 24 Apr 2012 02:49:58 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
In-Reply-To: <4F9525E4020000780007F350@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, April 23, 2012 3:50 PM
> To: Hao, Xudong
> Cc: xen-devel; konrad.wilk@oracle.com
> Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
> pciback
> 
> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> > When PCIE device which has LTR/OBFF capabilities is owned by pciback,
> > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF,
> > so that guest with device assigned can be benefitted.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> >
> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
> > b/drivers/xen/xen-pciback/pci_stub.c
> > index 19834d1..82aac5b 100644
> > --- a/drivers/xen/xen-pciback/pci_stub.c
> > +++ b/drivers/xen/xen-pciback/pci_stub.c
> > @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct
> > pci_dev
> > *dev)
> >  	dev_dbg(&dev->dev, "reset device\n");
> >  	xen_pcibk_reset_device(dev);
> >
> > +	/* set default value */
> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
> > +value */
> > +
> > +	/* Enable LTR and OBFF before do device assignment */
> > +	/* LTR(Latency tolerance reporting) allows devices to send messages to
> the
> > +	 * root complex indicating their latency tolerance for snooped &
> unsnooped
> > +	 * memory transactions.
> > +	 */
> > +	pci_enable_ltr(dev);
> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
> 
> Wouldn't the guest kernel be able to do this itself, as it's just playing with bits in
> the PCIE capability structure, or the LTR extended one?
> 
> If not, shouldn't you properly report (or at least log) errors here?
> 

There are two reasons I want to enable ltr/obff in host but not in guest.
1) ltr/obff is not only for one device, enabling them need to enable the whole pci bus, include root port, upstream and downstream port. It's complex to let guest enable the whole path.
2) LTR/obff are PCIE device capabilities2, current qemu did not support exposing PCIe capabilities2 to guest.

Yes, I'll add error report log here.

Thanks,
-Xudong

> > +
> > +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> > +	 * energy efficiency by giving devices information about when interrupts
> and
> > +	 * other activity will have a reduced power impact.
> > +	 */
> > +	pci_enable_obff(dev, type);
> 
> Similarly here.
> 
> Jan
> 
> > +
> >  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> >  	return 0;
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 02:51:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 02:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMVqH-0000bl-55; Tue, 24 Apr 2012 02:51:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMVqF-0000bg-4X
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 02:50:59 +0000
Received: from [85.158.139.83:57606] by server-8.bemta-5.messagelabs.com id
	72/D1-26964-215169F4; Tue, 24 Apr 2012 02:50:58 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335235855!21219107!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwMTQz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18546 invoked from network); 24 Apr 2012 02:50:57 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 02:50:57 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 23 Apr 2012 19:50:14 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134462618"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 23 Apr 2012 19:50:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 23 Apr 2012 19:50:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Tue, 24 Apr 2012 10:49:59 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
Thread-Index: AQHNISXIc8j5BFQpcEi9A9wrjU2645apPZlA
Date: Tue, 24 Apr 2012 02:49:58 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
In-Reply-To: <4F9525E4020000780007F350@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, April 23, 2012 3:50 PM
> To: Hao, Xudong
> Cc: xen-devel; konrad.wilk@oracle.com
> Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
> pciback
> 
> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> > When PCIE device which has LTR/OBFF capabilities is owned by pciback,
> > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF,
> > so that guest with device assigned can be benefitted.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> >
> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
> > b/drivers/xen/xen-pciback/pci_stub.c
> > index 19834d1..82aac5b 100644
> > --- a/drivers/xen/xen-pciback/pci_stub.c
> > +++ b/drivers/xen/xen-pciback/pci_stub.c
> > @@ -334,6 +334,14 @@ static int __devinit pcistub_init_device(struct
> > pci_dev
> > *dev)
> >  	dev_dbg(&dev->dev, "reset device\n");
> >  	xen_pcibk_reset_device(dev);
> >
> > +	/* set default value */
> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
> > +value */
> > +
> > +	/* Enable LTR and OBFF before do device assignment */
> > +	/* LTR(Latency tolerance reporting) allows devices to send messages to
> the
> > +	 * root complex indicating their latency tolerance for snooped &
> unsnooped
> > +	 * memory transactions.
> > +	 */
> > +	pci_enable_ltr(dev);
> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
> 
> Wouldn't the guest kernel be able to do this itself, as it's just playing with bits in
> the PCIE capability structure, or the LTR extended one?
> 
> If not, shouldn't you properly report (or at least log) errors here?
> 

There are two reasons I want to enable ltr/obff in host but not in guest.
1) ltr/obff is not only for one device, enabling them need to enable the whole pci bus, include root port, upstream and downstream port. It's complex to let guest enable the whole path.
2) LTR/obff are PCIE device capabilities2, current qemu did not support exposing PCIe capabilities2 to guest.

Yes, I'll add error report log here.

Thanks,
-Xudong

> > +
> > +	/* OBFF (optimized buffer flush/fill), where supported, can help improve
> > +	 * energy efficiency by giving devices information about when interrupts
> and
> > +	 * other activity will have a reduced power impact.
> > +	 */
> > +	pci_enable_obff(dev, type);
> 
> Similarly here.
> 
> Jan
> 
> > +
> >  	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> >  	return 0;
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 06:06:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 06:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMYsi-0001wU-32; Tue, 24 Apr 2012 06:05:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SMYsf-0001wP-Vp
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 06:05:42 +0000
Received: from [85.158.143.35:11054] by server-1.bemta-4.messagelabs.com id
	01/44-20925-5B2469F4; Tue, 24 Apr 2012 06:05:41 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335247540!13796341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY3MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28325 invoked from network); 24 Apr 2012 06:05:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 06:05:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,471,1330905600"; 
   d="scan'";a="12095394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:05:36 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 07:05:35 +0100
Message-ID: <1335247525.2397.4.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Tue, 24 Apr 2012 08:05:25 +0200
In-Reply-To: <20120423193518.GA16134@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5339534880613852458=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5339534880613852458==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-E3WSTiFY8y3v3zJjGelK"

--=-E3WSTiFY8y3v3zJjGelK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-04-23 at 20:35 +0100, Dieter Bloms wrote:=20
> ok, second try ;)
> I hope this fit more your needs.
>=20
This really looks much better to me!

> I've defined a new union in the libxl_domain_build_info structure.
> For this I had to move some structure definition like
> libxl_sched_credit_domain more to the top.
>
That's fine.

What might be missing is some documentation in docs/man/xl.cfg.pod.5,
explaining about the new options... :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-E3WSTiFY8y3v3zJjGelK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+WQqYACgkQk4XaBE3IOsQIVACfemGIQmIVHgPeM2K8Ml1zSxdk
ZA0AnRvlT26XCwYfmhXb62ABRvuhjKRg
=hB8o
-----END PGP SIGNATURE-----

--=-E3WSTiFY8y3v3zJjGelK--


--===============5339534880613852458==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5339534880613852458==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 06:06:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 06:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMYsi-0001wU-32; Tue, 24 Apr 2012 06:05:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SMYsf-0001wP-Vp
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 06:05:42 +0000
Received: from [85.158.143.35:11054] by server-1.bemta-4.messagelabs.com id
	01/44-20925-5B2469F4; Tue, 24 Apr 2012 06:05:41 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335247540!13796341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTY3MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28325 invoked from network); 24 Apr 2012 06:05:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 06:05:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,471,1330905600"; 
   d="scan'";a="12095394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:05:36 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 07:05:35 +0100
Message-ID: <1335247525.2397.4.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Tue, 24 Apr 2012 08:05:25 +0200
In-Reply-To: <20120423193518.GA16134@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5339534880613852458=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5339534880613852458==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-E3WSTiFY8y3v3zJjGelK"

--=-E3WSTiFY8y3v3zJjGelK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-04-23 at 20:35 +0100, Dieter Bloms wrote:=20
> ok, second try ;)
> I hope this fit more your needs.
>=20
This really looks much better to me!

> I've defined a new union in the libxl_domain_build_info structure.
> For this I had to move some structure definition like
> libxl_sched_credit_domain more to the top.
>
That's fine.

What might be missing is some documentation in docs/man/xl.cfg.pod.5,
explaining about the new options... :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-E3WSTiFY8y3v3zJjGelK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+WQqYACgkQk4XaBE3IOsQIVACfemGIQmIVHgPeM2K8Ml1zSxdk
ZA0AnRvlT26XCwYfmhXb62ABRvuhjKRg
=hB8o
-----END PGP SIGNATURE-----

--=-E3WSTiFY8y3v3zJjGelK--


--===============5339534880613852458==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5339534880613852458==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 06:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 06:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMZ4P-0002AU-BH; Tue, 24 Apr 2012 06:17:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMZ4N-0002AP-Pu
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 06:17:48 +0000
Received: from [85.158.143.35:12325] by server-3.bemta-4.messagelabs.com id
	0F/30-05853-B85469F4; Tue, 24 Apr 2012 06:17:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335248265!8448644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26887 invoked from network); 24 Apr 2012 06:17:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 06:17:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,471,1330905600"; d="scan'208";a="12095524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:17:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 07:17:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMZ4L-0001ko-1r;
	Tue, 24 Apr 2012 06:17:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMZ4K-0004df-TX;
	Tue, 24 Apr 2012 07:17:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12740-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 07:17:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12740: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12740 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12740/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12738

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12738 like 12733

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  274e5accd62d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 06:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 06:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMZ4P-0002AU-BH; Tue, 24 Apr 2012 06:17:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMZ4N-0002AP-Pu
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 06:17:48 +0000
Received: from [85.158.143.35:12325] by server-3.bemta-4.messagelabs.com id
	0F/30-05853-B85469F4; Tue, 24 Apr 2012 06:17:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335248265!8448644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26887 invoked from network); 24 Apr 2012 06:17:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 06:17:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,471,1330905600"; d="scan'208";a="12095524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:17:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 07:17:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMZ4L-0001ko-1r;
	Tue, 24 Apr 2012 06:17:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMZ4K-0004df-TX;
	Tue, 24 Apr 2012 07:17:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12740-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 07:17:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12740: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12740 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12740/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12738

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12738 like 12733

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  274e5accd62d
baseline version:
 xen                  274e5accd62d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 06:50:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 06:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMZYz-0002Qs-0A; Tue, 24 Apr 2012 06:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMZYx-0002Qm-SF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 06:49:24 +0000
Received: from [85.158.138.51:24657] by server-8.bemta-3.messagelabs.com id
	C1/50-24428-3FC469F4; Tue, 24 Apr 2012 06:49:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335250161!14539775!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28636 invoked from network); 24 Apr 2012 06:49:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 06:49:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 07:49:22 +0100
Message-Id: <4F96690D020000780007F810@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 07:49:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 04:49, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> > +	/* set default value */
>> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
>> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */
>> > +
>> > +	/* Enable LTR and OBFF before do device assignment */
>> > +	/* LTR(Latency tolerance reporting) allows devices to send messages to the
>> > +	 * root complex indicating their latency tolerance for snooped & unsnooped
>> > +	 * memory transactions.
>> > +	 */
>> > +	pci_enable_ltr(dev);
>> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
>> 
>> Wouldn't the guest kernel be able to do this itself, as it's just playing 
> with bits in
>> the PCIE capability structure, or the LTR extended one?
> 
> There are two reasons I want to enable ltr/obff in host but not in guest.
> 1) ltr/obff is not only for one device, enabling them need to enable the 
> whole pci bus, include root port, upstream and downstream port. It's complex 
> to let guest enable the whole path.

Then it would still be more clean to extend the pciif, allowing the guest
to request enabling, or even better snoop the writes to the capabilities/
LTR structures in pciback.

> 2) LTR/obff are PCIE device capabilities2, current qemu did not support 
> exposing PCIe capabilities2 to guest.

Mostly the same here, except that adding support for these capabilities
is obviously going to be needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 06:50:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 06:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMZYz-0002Qs-0A; Tue, 24 Apr 2012 06:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMZYx-0002Qm-SF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 06:49:24 +0000
Received: from [85.158.138.51:24657] by server-8.bemta-3.messagelabs.com id
	C1/50-24428-3FC469F4; Tue, 24 Apr 2012 06:49:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335250161!14539775!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28636 invoked from network); 24 Apr 2012 06:49:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 06:49:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 07:49:22 +0100
Message-Id: <4F96690D020000780007F810@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 07:49:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 04:49, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> > +	/* set default value */
>> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
>> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max value */
>> > +
>> > +	/* Enable LTR and OBFF before do device assignment */
>> > +	/* LTR(Latency tolerance reporting) allows devices to send messages to the
>> > +	 * root complex indicating their latency tolerance for snooped & unsnooped
>> > +	 * memory transactions.
>> > +	 */
>> > +	pci_enable_ltr(dev);
>> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
>> 
>> Wouldn't the guest kernel be able to do this itself, as it's just playing 
> with bits in
>> the PCIE capability structure, or the LTR extended one?
> 
> There are two reasons I want to enable ltr/obff in host but not in guest.
> 1) ltr/obff is not only for one device, enabling them need to enable the 
> whole pci bus, include root port, upstream and downstream port. It's complex 
> to let guest enable the whole path.

Then it would still be more clean to extend the pciif, allowing the guest
to request enabling, or even better snoop the writes to the capabilities/
LTR structures in pciback.

> 2) LTR/obff are PCIE device capabilities2, current qemu did not support 
> exposing PCIe capabilities2 to guest.

Mostly the same here, except that adding support for these capabilities
is obviously going to be needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:22:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMa48-0002st-Jb; Tue, 24 Apr 2012 07:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMa47-0002so-4Q
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:21:35 +0000
Received: from [85.158.139.83:48315] by server-3.bemta-5.messagelabs.com id
	F6/1C-25237-E74569F4; Tue, 24 Apr 2012 07:21:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335252093!25222790!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5927 invoked from network); 24 Apr 2012 07:21:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:21:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:21:36 +0100
Message-Id: <4F967099020000780007F81F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:21:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
In-Reply-To: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit
 test for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 20:07, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
> The memory hotplug code was masking the hotplugged memory start address and 
> comparing to a shifted version of COMPAT MPT size but not doing the same for 
> the end address.
> This patch applies the same shifting and masking to the end address and 
> reapplies the mask if the end address has been clamped.

This lacks a Signed-off-by tag in any case.

I'm not, however, seeing what is being fixed here:
RDWR_COMPAT_MPT_VIRT_{START,END} are both aligned to a
1Gb boundary, so I'm not immediately seeing how the adjustment
would result in any changed behavior.

Also, assuming I'm overlooking something and the patch is indeed
needed (and hence you'll resubmit), please fix the indentation to
not use hard tabs, and adjust the lines you change anyway to
match Xen's coding style.

Jan

> diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct
>      int err = 0;
>  
>      smap = info->spfn & (~((1UL << (L2_PAGETABLE_SHIFT - 2)) -1));
> +    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
> +                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
>  
>      /*
>       * Notice: For hot-added memory, only range below m2p_compat_vstart
> @@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct
>      if   ((smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 
> 2)) )
>          return 0;
>  
> -    if (epfn > (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
> -        epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
> -
> -    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
> -                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
> +    if (emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2))
> +    {
> +        emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
> +    	emap = emap & ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1);
> +    }
>  
>      va = HIRO_COMPAT_MPT_VIRT_START +
>           smap * sizeof(*compat_machine_to_phys_mapping);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:22:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMa48-0002st-Jb; Tue, 24 Apr 2012 07:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMa47-0002so-4Q
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:21:35 +0000
Received: from [85.158.139.83:48315] by server-3.bemta-5.messagelabs.com id
	F6/1C-25237-E74569F4; Tue, 24 Apr 2012 07:21:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335252093!25222790!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5927 invoked from network); 24 Apr 2012 07:21:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:21:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:21:36 +0100
Message-Id: <4F967099020000780007F81F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:21:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
In-Reply-To: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit
 test for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 20:07, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
> The memory hotplug code was masking the hotplugged memory start address and 
> comparing to a shifted version of COMPAT MPT size but not doing the same for 
> the end address.
> This patch applies the same shifting and masking to the end address and 
> reapplies the mask if the end address has been clamped.

This lacks a Signed-off-by tag in any case.

I'm not, however, seeing what is being fixed here:
RDWR_COMPAT_MPT_VIRT_{START,END} are both aligned to a
1Gb boundary, so I'm not immediately seeing how the adjustment
would result in any changed behavior.

Also, assuming I'm overlooking something and the patch is indeed
needed (and hence you'll resubmit), please fix the indentation to
not use hard tabs, and adjust the lines you change anyway to
match Xen's coding style.

Jan

> diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct
>      int err = 0;
>  
>      smap = info->spfn & (~((1UL << (L2_PAGETABLE_SHIFT - 2)) -1));
> +    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
> +                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
>  
>      /*
>       * Notice: For hot-added memory, only range below m2p_compat_vstart
> @@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct
>      if   ((smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 
> 2)) )
>          return 0;
>  
> -    if (epfn > (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
> -        epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
> -
> -    emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &
> -                ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1) );
> +    if (emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2))
> +    {
> +        emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
> +    	emap = emap & ~((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1);
> +    }
>  
>      va = HIRO_COMPAT_MPT_VIRT_START +
>           smap * sizeof(*compat_machine_to_phys_mapping);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:28:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMaAE-00031N-Ic; Tue, 24 Apr 2012 07:27:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMaAD-00031H-5a
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:27:53 +0000
Received: from [85.158.139.83:3143] by server-2.bemta-5.messagelabs.com id
	9D/78-17016-8F5569F4; Tue, 24 Apr 2012 07:27:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335252470!25113234!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4971 invoked from network); 24 Apr 2012 07:27:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:27:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:27:55 +0100
Message-Id: <4F96720E020000780007F82E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:27:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Tobias Geiger" <tobias.geiger@vido.info>
References: <201204231202.27731.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
	<20120423152404.GD24481@phenom.dumpdata.com>
	<4F95C158.7030703@vido.info>
In-Reply-To: <4F95C158.7030703@vido.info>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
>> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
>>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
>>>> Hello!
>>>>
>>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4
>>>> tested) as Dom0 Kernel;
>>>>
>>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
>>>> (gplpv_Vista2008x64_0.11.0.357.msi);
>>>> With 3.4 it drops to about a third of that.
>>>>
>>>> Xen Version is xen-unstable:
>>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
>>>>
>>>> Disk config line is:
>>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
>>>> - it uses blkback.
>>> I fail to see what could be the cause of the issue: nothing on the
>>> blkback side should affect performances significantly.
>>> You could try reverting the four patches to blkback that were applied
>>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
>>> regression:
>>>
>>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
>>> Daniel De Graaf (2):
>>>        xen/blkback: use grant-table.c hypercall wrappers
>> Hm.. Perhaps this patch fixes it a possible perf (I would think that
>> the compiler would have kept the result of the first call to vaddr(req, i)
>> somewhere.. but not sure) lost with the mentioned patch:
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
>> index 73f196c..65dbadc 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req *req)
>>   	int ret;
>>
>>   	for (i = 0; i<  req->nr_pages; i++) {
>> +		unsigned long addr;
>>   		handle = pending_handle(req, i);
>>   		if (handle == BLKBACK_INVALID_HANDLE)
>>   			continue;
>> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
>> +		addr = vaddr(req, i);
>> +		gnttab_set_unmap_op(&unmap[invcount], addr,
>>   				    GNTMAP_host_map, handle);
>>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
>> -		pages[invcount] = virt_to_page(vaddr(req, i));
>> +		pages[invcount] = virt_to_page(addr);
>>   		invcount++;
>>   	}
>>
>>>        xen/blkback: Enable blkback on HVM guests
>>>
>>> Konrad Rzeszutek Wilk (2):
>>>        xen/blkback: Squash the discard support for 'file' and 'phy' type.
>>>        xen/blkback: Make optional features be really optional.
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org 
>>> http://lists.xen.org/xen-devel 
> that made it even worse :)
> Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> Read "only" down to 40mb/s (with 3.3: ~140mb/s)

I doubt this patch can have any meaningful positive or negative
performance effect at all - are you sure you're doing comparable
runs? After all this is all just about a few arithmetic operations
and an array access, which I'd expect to hide in the noise.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:28:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMaAE-00031N-Ic; Tue, 24 Apr 2012 07:27:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMaAD-00031H-5a
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:27:53 +0000
Received: from [85.158.139.83:3143] by server-2.bemta-5.messagelabs.com id
	9D/78-17016-8F5569F4; Tue, 24 Apr 2012 07:27:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335252470!25113234!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4971 invoked from network); 24 Apr 2012 07:27:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:27:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:27:55 +0100
Message-Id: <4F96720E020000780007F82E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:27:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Tobias Geiger" <tobias.geiger@vido.info>
References: <201204231202.27731.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204231240440.26786@kaball-desktop>
	<20120423152404.GD24481@phenom.dumpdata.com>
	<4F95C158.7030703@vido.info>
In-Reply-To: <4F95C158.7030703@vido.info>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
>> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
>>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
>>>> Hello!
>>>>
>>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3 and rc4
>>>> tested) as Dom0 Kernel;
>>>>
>>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
>>>> (gplpv_Vista2008x64_0.11.0.357.msi);
>>>> With 3.4 it drops to about a third of that.
>>>>
>>>> Xen Version is xen-unstable:
>>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100 25209:e6b20ec1824c
>>>>
>>>> Disk config line is:
>>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
>>>> - it uses blkback.
>>> I fail to see what could be the cause of the issue: nothing on the
>>> blkback side should affect performances significantly.
>>> You could try reverting the four patches to blkback that were applied
>>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
>>> regression:
>>>
>>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
>>> Daniel De Graaf (2):
>>>        xen/blkback: use grant-table.c hypercall wrappers
>> Hm.. Perhaps this patch fixes it a possible perf (I would think that
>> the compiler would have kept the result of the first call to vaddr(req, i)
>> somewhere.. but not sure) lost with the mentioned patch:
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
>> index 73f196c..65dbadc 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req *req)
>>   	int ret;
>>
>>   	for (i = 0; i<  req->nr_pages; i++) {
>> +		unsigned long addr;
>>   		handle = pending_handle(req, i);
>>   		if (handle == BLKBACK_INVALID_HANDLE)
>>   			continue;
>> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
>> +		addr = vaddr(req, i);
>> +		gnttab_set_unmap_op(&unmap[invcount], addr,
>>   				    GNTMAP_host_map, handle);
>>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
>> -		pages[invcount] = virt_to_page(vaddr(req, i));
>> +		pages[invcount] = virt_to_page(addr);
>>   		invcount++;
>>   	}
>>
>>>        xen/blkback: Enable blkback on HVM guests
>>>
>>> Konrad Rzeszutek Wilk (2):
>>>        xen/blkback: Squash the discard support for 'file' and 'phy' type.
>>>        xen/blkback: Make optional features be really optional.
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org 
>>> http://lists.xen.org/xen-devel 
> that made it even worse :)
> Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> Read "only" down to 40mb/s (with 3.3: ~140mb/s)

I doubt this patch can have any meaningful positive or negative
performance effect at all - are you sure you're doing comparable
runs? After all this is all just about a few arithmetic operations
and an array access, which I'd expect to hide in the noise.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:53:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMaYS-0003LX-As; Tue, 24 Apr 2012 07:52:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMaYQ-0003LS-GB
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:52:54 +0000
Received: from [85.158.143.35:17248] by server-1.bemta-4.messagelabs.com id
	69/7A-20925-5DB569F4; Tue, 24 Apr 2012 07:52:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335253973!13378695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15949 invoked from network); 24 Apr 2012 07:52:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:52:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:53:06 +0100
Message-Id: <4F9677E9020000780007F840@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:52:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <f7a1633867bfeb30f83d.1335222981@vollum>
In-Reply-To: <f7a1633867bfeb30f83d.1335222981@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 01:16, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Mon Apr 23 15:16:34 2012 -0700
> +++ b/xen/arch/x86/domctl.c	Mon Apr 23 16:12:50 2012 -0700
> @@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
>          c.nat->user_regs.es = sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs = sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base = sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs = sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +            c.nat->gs_base_kernel = sreg.base;
> +        else
> +            c.nat->gs_base_user = sreg.base;
> +#endif

Which still leaves one of gs_base_* unfilled in all cases. You'll need
to get ahold of vmcb->kerngsbase (AMD/SVM) or
v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
as a new function table entry, or pay the price of calling
->save_cpu_ctxt(). But you will need to pay extra attention to
the case of the subject vCPU being current.

>      }
>      else
>      {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:53:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMaYS-0003LX-As; Tue, 24 Apr 2012 07:52:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMaYQ-0003LS-GB
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:52:54 +0000
Received: from [85.158.143.35:17248] by server-1.bemta-4.messagelabs.com id
	69/7A-20925-5DB569F4; Tue, 24 Apr 2012 07:52:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335253973!13378695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15949 invoked from network); 24 Apr 2012 07:52:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:52:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:53:06 +0100
Message-Id: <4F9677E9020000780007F840@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:52:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <f7a1633867bfeb30f83d.1335222981@vollum>
In-Reply-To: <f7a1633867bfeb30f83d.1335222981@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 01:16, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Mon Apr 23 15:16:34 2012 -0700
> +++ b/xen/arch/x86/domctl.c	Mon Apr 23 16:12:50 2012 -0700
> @@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
>          c.nat->user_regs.es = sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs = sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base = sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs = sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +            c.nat->gs_base_kernel = sreg.base;
> +        else
> +            c.nat->gs_base_user = sreg.base;
> +#endif

Which still leaves one of gs_base_* unfilled in all cases. You'll need
to get ahold of vmcb->kerngsbase (AMD/SVM) or
v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
as a new function table entry, or pay the price of calling
->save_cpu_ctxt(). But you will need to pay extra attention to
the case of the subject vCPU being current.

>      }
>      else
>      {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:58:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMadT-0003Sk-1n; Tue, 24 Apr 2012 07:58:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMadQ-0003Sa-VF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:58:05 +0000
Received: from [85.158.143.35:54084] by server-3.bemta-4.messagelabs.com id
	A2/68-05853-C0D569F4; Tue, 24 Apr 2012 07:58:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335254283!12723122!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2069 invoked from network); 24 Apr 2012 07:58:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:58:23 +0100
Message-Id: <4F967928020000780007F84A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:58:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ruslan Nikolaev" <nruslan_devel@yahoo.com>
References: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
In-Reply-To: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question about grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 23:13, Ruslan Nikolaev <nruslan_devel@yahoo.com> wrote:
> Hi
> 
> I have a question regarding a grant table. I have a case when I have some 
> shared (between domains) pages mapped to the user space. I created a special 
> driver which implements mmap(). That, in turns, will execute 
> gnttab_map_refs(). This all works fine until I want to do something like 
> exec().
> 
> After I do exec(), I want to mmap() the *same* pages (i.e. using the same 
> grant references) to some new user address space which is chosen by mmap(). 
> During exec(), it will invalidate user address space, and  release() from 
> mmu_notifier will be called. This means, that my driver will execute 
> gnttab_unmap_refs. After exec() succeeded, I invoke mmap() again which will 
> do gnttab_map_refs().
> 
> At this point I get kernel errors like this:
> [  198.939095] BUG: Bad page map in process a.out  pte:80000002457f1167 
> pmd:245094067
> [  198.939099] page:ffffea000915fc40 count:1 mapcount:-1 mapping:          
> (null) index:0xffff8802d958f720
> [  198.939102] page flags: 0x8000000000000814(referenced|dirty|private)
> [  198.939109] addr:00007fd302f40000 vm_flags:000e00fb anon_vma:          
> (null) mapping:ffff8802d782f760 index:0
> [  198.939124] vma->vm_ops->fault: 0x0
> [  198.939128] vma->vm_file->f_op->mmap: syscall_driver_mmap+0x0/0xc9 
> [syscall_driver]

This I cannot spot in the upstream kernel (and you also didn't indicate
that you use something different), so I think you need to start
investigation at that end.

Jan

> So, I have two questions in this regard:
> 1. Does gnttab_unmap_refs removes grant references, so that I cannot use 
> them any longer? What would be proper way to preserve grant references but at 
> the same time unmap from the current user address space shared pages?
> 
> 2. What happens to the counters like count, mapcount when I do 
> gnttab_map_refs() and gnntab_unmap_refs()?
> 
> Thanks,
> Ruslan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 07:58:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 07:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMadT-0003Sk-1n; Tue, 24 Apr 2012 07:58:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMadQ-0003Sa-VF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 07:58:05 +0000
Received: from [85.158.143.35:54084] by server-3.bemta-4.messagelabs.com id
	A2/68-05853-C0D569F4; Tue, 24 Apr 2012 07:58:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335254283!12723122!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Mzg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2069 invoked from network); 24 Apr 2012 07:58:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 07:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 08:58:23 +0100
Message-Id: <4F967928020000780007F84A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 08:58:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ruslan Nikolaev" <nruslan_devel@yahoo.com>
References: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
In-Reply-To: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question about grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.04.12 at 23:13, Ruslan Nikolaev <nruslan_devel@yahoo.com> wrote:
> Hi
> 
> I have a question regarding a grant table. I have a case when I have some 
> shared (between domains) pages mapped to the user space. I created a special 
> driver which implements mmap(). That, in turns, will execute 
> gnttab_map_refs(). This all works fine until I want to do something like 
> exec().
> 
> After I do exec(), I want to mmap() the *same* pages (i.e. using the same 
> grant references) to some new user address space which is chosen by mmap(). 
> During exec(), it will invalidate user address space, and  release() from 
> mmu_notifier will be called. This means, that my driver will execute 
> gnttab_unmap_refs. After exec() succeeded, I invoke mmap() again which will 
> do gnttab_map_refs().
> 
> At this point I get kernel errors like this:
> [  198.939095] BUG: Bad page map in process a.out  pte:80000002457f1167 
> pmd:245094067
> [  198.939099] page:ffffea000915fc40 count:1 mapcount:-1 mapping:          
> (null) index:0xffff8802d958f720
> [  198.939102] page flags: 0x8000000000000814(referenced|dirty|private)
> [  198.939109] addr:00007fd302f40000 vm_flags:000e00fb anon_vma:          
> (null) mapping:ffff8802d782f760 index:0
> [  198.939124] vma->vm_ops->fault: 0x0
> [  198.939128] vma->vm_file->f_op->mmap: syscall_driver_mmap+0x0/0xc9 
> [syscall_driver]

This I cannot spot in the upstream kernel (and you also didn't indicate
that you use something different), so I think you need to start
investigation at that end.

Jan

> So, I have two questions in this regard:
> 1. Does gnttab_unmap_refs removes grant references, so that I cannot use 
> them any longer? What would be proper way to preserve grant references but at 
> the same time unmap from the current user address space shared pages?
> 
> 2. What happens to the counters like count, mapcount when I do 
> gnttab_map_refs() and gnntab_unmap_refs()?
> 
> Thanks,
> Ruslan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:28:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:28:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMb63-0004De-MD; Tue, 24 Apr 2012 08:27:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi@firstfloor.org>) id 1SMb62-0004DZ-Gk
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 08:27:38 +0000
Received: from [85.158.143.35:55164] by server-3.bemta-4.messagelabs.com id
	7B/63-05853-9F3669F4; Tue, 24 Apr 2012 08:27:37 +0000
X-Env-Sender: andi@firstfloor.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335256056!6319334!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMzAzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15269 invoked from network); 24 Apr 2012 08:27:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 08:27:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 24 Apr 2012 01:27:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="145181392"
Received: from tassilo.jf.intel.com ([10.7.201.151])
	by fmsmga001.fm.intel.com with ESMTP; 24 Apr 2012 01:27:35 -0700
Received: by tassilo.jf.intel.com (Postfix, from userid 501)
	id C6E2C240F9A; Tue, 24 Apr 2012 01:27:35 -0700 (PDT)
From: Andi Kleen <andi@firstfloor.org>
To: Borislav Petkov <bp@amd64.org>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
Date: Tue, 24 Apr 2012 01:27:35 -0700
In-Reply-To: <20120421104502.GB17005@aftab.osrc.amd.com> (Borislav Petkov's
	message of "Sat, 21 Apr 2012 12:45:02 +0200")
Message-ID: <m2aa21o7pk.fsf@firstfloor.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	torvalds@linux-foundation.org, Ingo Molnar <mingo@kernel.org>,
	linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Borislav Petkov <bp@amd64.org> writes:

> Because, if you'd hooked into it, just imagine one fine day, when we
> remove mcelog support, what screaming the xen people will be doing when
> mcelog doesn't work anymore.

That's simple. /dev/mcelog is a widely used user space ABI and Linux
does never remove widely used user space ABIs, so this can never happen.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:28:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:28:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMb63-0004De-MD; Tue, 24 Apr 2012 08:27:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi@firstfloor.org>) id 1SMb62-0004DZ-Gk
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 08:27:38 +0000
Received: from [85.158.143.35:55164] by server-3.bemta-4.messagelabs.com id
	7B/63-05853-9F3669F4; Tue, 24 Apr 2012 08:27:37 +0000
X-Env-Sender: andi@firstfloor.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335256056!6319334!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMxMzAzOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15269 invoked from network); 24 Apr 2012 08:27:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 08:27:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 24 Apr 2012 01:27:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="145181392"
Received: from tassilo.jf.intel.com ([10.7.201.151])
	by fmsmga001.fm.intel.com with ESMTP; 24 Apr 2012 01:27:35 -0700
Received: by tassilo.jf.intel.com (Postfix, from userid 501)
	id C6E2C240F9A; Tue, 24 Apr 2012 01:27:35 -0700 (PDT)
From: Andi Kleen <andi@firstfloor.org>
To: Borislav Petkov <bp@amd64.org>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
Date: Tue, 24 Apr 2012 01:27:35 -0700
In-Reply-To: <20120421104502.GB17005@aftab.osrc.amd.com> (Borislav Petkov's
	message of "Sat, 21 Apr 2012 12:45:02 +0200")
Message-ID: <m2aa21o7pk.fsf@firstfloor.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	tony.luck@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	torvalds@linux-foundation.org, Ingo Molnar <mingo@kernel.org>,
	linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Borislav Petkov <bp@amd64.org> writes:

> Because, if you'd hooked into it, just imagine one fine day, when we
> remove mcelog support, what screaming the xen people will be doing when
> mcelog doesn't work anymore.

That's simple. /dev/mcelog is a widely used user space ABI and Linux
does never remove widely used user space ABIs, so this can never happen.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:37:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbFb-0004Ny-Uv; Tue, 24 Apr 2012 08:37:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMbFa-0004Nt-5r
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 08:37:30 +0000
Received: from [85.158.139.83:36995] by server-5.bemta-5.messagelabs.com id
	2A/E8-13566-946669F4; Tue, 24 Apr 2012 08:37:29 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335256646!22489474!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12270 invoked from network); 24 Apr 2012 08:37:27 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 08:37:27 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 17766102107DF
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 01:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id uawGqMm6CkhI for <xen-devel@lists.xen.org>;
	Tue, 24 Apr 2012 01:37:23 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 1A923102107D5
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 01:37:23 -0700 (PDT)
From: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 01:37:20 -0700
Message-Id: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello!

I was asking for help on the Freenode channel, and I was pointed here.

I have a situation where, using xl, I can create a functional PV domU, with or without pv-grub, but I cannot access the console.   Firing up xend and using xm works without trouble.    Since xend and company is being deprecated, I would like to transition to using the xl toolstack.

The system is an Arch Linux system running under VMWare Fusion-- I normally build and test packages this way before I test them on my dev hardware as my dev hardware is a rather loud HP server.   I'm compiling Xen in a package, based off of the one in AUR but with some changes (the AUR package doesn't compile pv-grub, for instance).   It's Xen 4.1.2, and my linux kernel is the standard Arch Linux kernel  version 3.3.2, and it is very near the stock kernel.   Clearly, I have done no HVM testing yet.


Here's what it looks like when I try xl:
__START__
[root@xentest2012 noauto]# xl create -c finnix.cfg 
Parsing config file finnix.cfg
Unable to attach console
Daemon running with PID 851
[root@xentest2012 noauto]# xl console finnix
Unable to attach console
[root@xentest2012 noauto]# ls
domutest.cfg  finnix.cfg
[root@xentest2012 noauto]# xl create -c domutest.cfg 
Parsing config file domutest.cfg
xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel
Unable to attach console
Daemon running with PID 916
[root@xentest2012 noauto]# xl console domutest
Unable to attach console
[root@xentest2012 noauto]# 
__END__

Firing up xend, it works just as you would expect.


Here are the configuration files:

finnix.cfg:
__START__
kernel = "/var/finnix/linux64"
ramdisk = "/var/finnix/initrd.xz"
name = "finnix"
memory = "128"
disk = [ 'file:/var/finnix/finnix-104.iso,xvda,r', ]
vif = [ 'bridge=outer0', ]
__END__

domutest.cfg:
__START__
kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
extra = "(hd0)/boot/grub/menu.lst"

memory = 512
vcpus  = 4
name   = "domutest"
disk   = [ "phy:/dev/xtG0/domutest-root,xvda1,w",
           "phy:/dev/xtG0/domutest-swap,xvda2,w" ]
vif     = [ "bridge=outer0" ]
vfb    = [ "type=vnc,vnclisten=0.0.0.0,vncdisplay=5,vncpasswd=smeghead" ]
__END__

I can see finnix ask for a DHCP address, and I can connect to domutest using the VNC vfb and use it as normal, so I've concluded that the domUs are running.


And now for some other information:

xen-hotplug.log
__START__
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
__END__

qemu-dm-finnix.log   
__START__
domid: 1
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
/home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
/home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603: Created /var/run/tap directory
Could not open /var/run/tap/qemu-read-1
char device redirected to /dev/pts/2
xs_read(): target get error. /local/domain/1/target.
(qemu) (qemu) 
__END__

qemu-dm-domutest.log 
__START__
domid: 2
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
/home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
Could not open /var/run/tap/qemu-read-2
char device redirected to /dev/pts/3
xs_read(): target get error. /local/domain/2/target.
Key lost : keysym=0xffe7(65511)
Key lost : keysym=0xffe7(65511)
__END__



Here's running xl create on domutest with the -v option:
__START__
[root@xentest2012 noauto]# xl -v create -c domutest.cfg 
Parsing config file domutest.cfg
domainbuilder: detail: xc_dom_allocate: cmdline="(hd0)/boot/grub/menu.lst", features="(null)"
domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz"
domainbuilder: detail: xc_dom_malloc_filemap    : 1130 kB
domainbuilder: detail: xc_dom_malloc            : 14779 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x11a833 -> 0xe6effa
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, caps xen-3.0-x86_64 xen-3.0-x86_32p 
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kerne
l
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ff60
xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ff60
xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPE
RCALL_PAGE=0x2,LOADER=generic"
xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
xc: detail: elf_xen_parse_guest_info: LOADER="generic"
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail:     virt_base        = 0x0
xc: detail:     elf_paddr_offset = 0x0
xc: detail:     virt_offset      = 0x0
xc: detail:     virt_kstart      = 0x0
xc: detail:     virt_kend        = 0x99ff60
xc: detail:     virt_entry       = 0x0
xc: detail:     p2m_base         = 0xffffffffffffffff
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ff60
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc            : 1024 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 -> 0x9a0000  (pfn 0x0 + 0x9a0 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x9a0 at 0x7f18be2e9000
xc: detail: elf_load_binary: phdr 0 at 0x0x7f18be2e9000 -> 0x0x7f18bec88f60
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x9a0000 -> 0xaa0000  (pfn 0x9a0 + 0x100 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x9a0+0x100 at 0x7f18be1e9000
domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xaa0000 (pfn 0xaa0)
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xaa1000 (pfn 0xaa1)
domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xaa2000 (pfn 0xaa2)
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s
)
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s
)
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s
)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s
)
domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xaa3000 -> 0xaac000  (pfn 0xaa3 + 0x9 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa3+0x9 at 0x7f18be1e0000
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xaac000 (pfn 0xaac)
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xaad000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000
domainbuilder: detail: clear_page: pfn 0xaa2, mfn 0x5dd0c
domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x5dd0d
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa0+0x1 at 0x7f18be1df000
domainbuilder: detail: start_info_x86_64: called
domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 15870 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 1130 kB
domainbuilder: detail:       domU mmap          : 10920 kB
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0x587bb
domainbuilder: detail: shared_info_x86_64: called
domainbuilder: detail: vcpu_x86_64: called
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa3 mfn 0x5dd0b
domainbuilder: detail: launch_vm: called, ctxt=0x7fffa9ec8e90
domainbuilder: detail: xc_dom_release: called
Unable to attach console
Daemon running with PID 1395
__END__

And the output of xl info:
__START__
host                   : xentest2012
release                : 3.3.2-1-ARCH
version                : #1 SMP PREEMPT Sat Apr 14 09:48:37 CEST 2012
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 1
threads_per_core       : 1
cpu_mhz                : 2403
hw_caps                : 0febfbff:20100800:00000000:00000940:80002201:00000000:00000001:00000000
virt_caps              :
total_memory           : 2047
free_memory            : 870
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .2
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=512M loglvl=all guest_loglvl=all com1=115200,8n1 console=com1
cc_compiler            : gcc version 4.7.0 20120414 (prerelease) (GCC) 
cc_compile_by          : sam
cc_compile_domain      : (none)
cc_compile_date        : Sun Apr 22 19:02:17 PDT 2012
xend_config_format     : 4
__END__

The xl logs have a single line in them:

xl-domutest.log:
Waiting for domain domutest (domid 6) to die [pid 1696]

xl-finnix.log :
Waiting for domain finnix (domid 7) to die [pid 1763]


That's what I've got.   Any pointers would help.   Thanks!


-Sam
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:37:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbFb-0004Ny-Uv; Tue, 24 Apr 2012 08:37:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMbFa-0004Nt-5r
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 08:37:30 +0000
Received: from [85.158.139.83:36995] by server-5.bemta-5.messagelabs.com id
	2A/E8-13566-946669F4; Tue, 24 Apr 2012 08:37:29 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335256646!22489474!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12270 invoked from network); 24 Apr 2012 08:37:27 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 08:37:27 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 17766102107DF
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 01:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id uawGqMm6CkhI for <xen-devel@lists.xen.org>;
	Tue, 24 Apr 2012 01:37:23 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 1A923102107D5
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 01:37:23 -0700 (PDT)
From: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 01:37:20 -0700
Message-Id: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello!

I was asking for help on the Freenode channel, and I was pointed here.

I have a situation where, using xl, I can create a functional PV domU, with or without pv-grub, but I cannot access the console.   Firing up xend and using xm works without trouble.    Since xend and company is being deprecated, I would like to transition to using the xl toolstack.

The system is an Arch Linux system running under VMWare Fusion-- I normally build and test packages this way before I test them on my dev hardware as my dev hardware is a rather loud HP server.   I'm compiling Xen in a package, based off of the one in AUR but with some changes (the AUR package doesn't compile pv-grub, for instance).   It's Xen 4.1.2, and my linux kernel is the standard Arch Linux kernel  version 3.3.2, and it is very near the stock kernel.   Clearly, I have done no HVM testing yet.


Here's what it looks like when I try xl:
__START__
[root@xentest2012 noauto]# xl create -c finnix.cfg 
Parsing config file finnix.cfg
Unable to attach console
Daemon running with PID 851
[root@xentest2012 noauto]# xl console finnix
Unable to attach console
[root@xentest2012 noauto]# ls
domutest.cfg  finnix.cfg
[root@xentest2012 noauto]# xl create -c domutest.cfg 
Parsing config file domutest.cfg
xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel
Unable to attach console
Daemon running with PID 916
[root@xentest2012 noauto]# xl console domutest
Unable to attach console
[root@xentest2012 noauto]# 
__END__

Firing up xend, it works just as you would expect.


Here are the configuration files:

finnix.cfg:
__START__
kernel = "/var/finnix/linux64"
ramdisk = "/var/finnix/initrd.xz"
name = "finnix"
memory = "128"
disk = [ 'file:/var/finnix/finnix-104.iso,xvda,r', ]
vif = [ 'bridge=outer0', ]
__END__

domutest.cfg:
__START__
kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
extra = "(hd0)/boot/grub/menu.lst"

memory = 512
vcpus  = 4
name   = "domutest"
disk   = [ "phy:/dev/xtG0/domutest-root,xvda1,w",
           "phy:/dev/xtG0/domutest-swap,xvda2,w" ]
vif     = [ "bridge=outer0" ]
vfb    = [ "type=vnc,vnclisten=0.0.0.0,vncdisplay=5,vncpasswd=smeghead" ]
__END__

I can see finnix ask for a DHCP address, and I can connect to domutest using the VNC vfb and use it as normal, so I've concluded that the domUs are running.


And now for some other information:

xen-hotplug.log
__START__
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
__END__

qemu-dm-finnix.log   
__START__
domid: 1
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
/home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
/home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603: Created /var/run/tap directory
Could not open /var/run/tap/qemu-read-1
char device redirected to /dev/pts/2
xs_read(): target get error. /local/domain/1/target.
(qemu) (qemu) 
__END__

qemu-dm-domutest.log 
__START__
domid: 2
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
/home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
Could not open /var/run/tap/qemu-read-2
char device redirected to /dev/pts/3
xs_read(): target get error. /local/domain/2/target.
Key lost : keysym=0xffe7(65511)
Key lost : keysym=0xffe7(65511)
__END__



Here's running xl create on domutest with the -v option:
__START__
[root@xentest2012 noauto]# xl -v create -c domutest.cfg 
Parsing config file domutest.cfg
domainbuilder: detail: xc_dom_allocate: cmdline="(hd0)/boot/grub/menu.lst", features="(null)"
domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz"
domainbuilder: detail: xc_dom_malloc_filemap    : 1130 kB
domainbuilder: detail: xc_dom_malloc            : 14779 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x11a833 -> 0xe6effa
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, caps xen-3.0-x86_64 xen-3.0-x86_32p 
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kerne
l
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ff60
xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ff60
xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPE
RCALL_PAGE=0x2,LOADER=generic"
xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
xc: detail: elf_xen_parse_guest_info: LOADER="generic"
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail:     virt_base        = 0x0
xc: detail:     elf_paddr_offset = 0x0
xc: detail:     virt_offset      = 0x0
xc: detail:     virt_kstart      = 0x0
xc: detail:     virt_kend        = 0x99ff60
xc: detail:     virt_entry       = 0x0
xc: detail:     p2m_base         = 0xffffffffffffffff
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ff60
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc            : 1024 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 -> 0x9a0000  (pfn 0x0 + 0x9a0 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x9a0 at 0x7f18be2e9000
xc: detail: elf_load_binary: phdr 0 at 0x0x7f18be2e9000 -> 0x0x7f18bec88f60
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x9a0000 -> 0xaa0000  (pfn 0x9a0 + 0x100 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x9a0+0x100 at 0x7f18be1e9000
domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xaa0000 (pfn 0xaa0)
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xaa1000 (pfn 0xaa1)
domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xaa2000 (pfn 0xaa2)
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s
)
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s
)
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s
)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s
)
domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xaa3000 -> 0xaac000  (pfn 0xaa3 + 0x9 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa3+0x9 at 0x7f18be1e0000
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xaac000 (pfn 0xaac)
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xaad000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000
domainbuilder: detail: clear_page: pfn 0xaa2, mfn 0x5dd0c
domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x5dd0d
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa0+0x1 at 0x7f18be1df000
domainbuilder: detail: start_info_x86_64: called
domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 15870 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 1130 kB
domainbuilder: detail:       domU mmap          : 10920 kB
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0x587bb
domainbuilder: detail: shared_info_x86_64: called
domainbuilder: detail: vcpu_x86_64: called
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa3 mfn 0x5dd0b
domainbuilder: detail: launch_vm: called, ctxt=0x7fffa9ec8e90
domainbuilder: detail: xc_dom_release: called
Unable to attach console
Daemon running with PID 1395
__END__

And the output of xl info:
__START__
host                   : xentest2012
release                : 3.3.2-1-ARCH
version                : #1 SMP PREEMPT Sat Apr 14 09:48:37 CEST 2012
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 1
threads_per_core       : 1
cpu_mhz                : 2403
hw_caps                : 0febfbff:20100800:00000000:00000940:80002201:00000000:00000001:00000000
virt_caps              :
total_memory           : 2047
free_memory            : 870
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .2
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=512M loglvl=all guest_loglvl=all com1=115200,8n1 console=com1
cc_compiler            : gcc version 4.7.0 20120414 (prerelease) (GCC) 
cc_compile_by          : sam
cc_compile_domain      : (none)
cc_compile_date        : Sun Apr 22 19:02:17 PDT 2012
xend_config_format     : 4
__END__

The xl logs have a single line in them:

xl-domutest.log:
Waiting for domain domutest (domid 6) to die [pid 1696]

xl-finnix.log :
Waiting for domain finnix (domid 7) to die [pid 1763]


That's what I've got.   Any pointers would help.   Thanks!


-Sam
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:42:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbKP-0004Zq-Ma; Tue, 24 Apr 2012 08:42:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbKO-0004Zl-PR
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 08:42:29 +0000
Received: from [85.158.138.51:42950] by server-4.bemta-3.messagelabs.com id
	CE/D1-15341-477669F4; Tue, 24 Apr 2012 08:42:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335256947!23543721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3186 invoked from network); 24 Apr 2012 08:42:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 08:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12098363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 08:42:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:42:14 +0100
Message-ID: <1335256933.4347.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Date: Tue, 24 Apr 2012 09:42:13 +0100
In-Reply-To: <6ef297a3761f3061d2e8.1335219661@vollum>
References: <6ef297a3761f3061d2e8.1335219661@vollum>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap()
 for array sizes greater than a page in xc_linux_osdep.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 23:21 +0100, Aravindh Puthiyaparambil wrote:
> When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.
> 
> Fix an error print with the correct function name.
> 
> Do the same for the map array in linux_gnttab_grant_map()
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


> 
> diff -r 274e5accd62d -r 6ef297a3761f tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Fri Apr 20 09:49:06 2012 +0100
> +++ b/tools/libxc/xc_linux_osdep.c	Mon Apr 23 15:16:34 2012 -0700
> @@ -39,6 +39,7 @@
>  #include "xenctrl.h"
>  #include "xenctrlosdep.h"
>  
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
>  #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>  #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> @@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
>                  fd, 0);
>      if ( addr == MAP_FAILED )
>      {
> -        PERROR("xc_map_foreign_batch: mmap failed");
> +        PERROR("xc_map_foreign_bulk: mmap failed");
>          return NULL;
>      }
>  
> @@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
>          privcmd_mmapbatch_t ioctlx;
> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> +        xen_pfn_t *pfn;
> +        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
> +
> +        if ( pfn_arr_size <= XC_PAGE_SIZE )
> +            pfn = alloca(num * sizeof(*pfn));
> +        else
> +        {
> +            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
> +                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +            if ( pfn == MAP_FAILED )
> +            {
> +                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> +                return NULL;
> +            }
> +        }
>  
>          memcpy(pfn, arr, num * sizeof(*arr));
>  
> @@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
>              break;
>          }
>  
> +        if ( pfn_arr_size > XC_PAGE_SIZE )
> +            munmap(pfn, pfn_arr_size);
> +
>          if ( rc == -ENOENT && i == num )
>              rc = 0;
>          else if ( rc )
> @@ -549,6 +567,9 @@ static void *linux_gnttab_grant_map(xc_g
>  {
>      int fd = (int)h;
>      struct ioctl_gntdev_map_grant_ref *map;
> +    unsigned int map_size = ROUNDUP((sizeof(*map) + (count - 1) *
> +                                    sizeof(struct ioctl_gntdev_map_grant_ref)),
> +                                    XC_PAGE_SHIFT);
>      void *addr = NULL;
>      int domids_stride = 1;
>      int i;
> @@ -556,8 +577,19 @@ static void *linux_gnttab_grant_map(xc_g
>      if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
>          domids_stride = 0;
>  
> -    map = alloca(sizeof(*map) +
> -                 (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
> +    if ( map_size <= XC_PAGE_SIZE )
> +        map = alloca(sizeof(*map) +
> +                     (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
> +    else
> +    {
> +        map = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
> +                   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +        if ( map == MAP_FAILED )
> +        {
> +            PERROR("linux_gnttab_grant_map: mmap of map failed");
> +            return NULL;
> +        }
> +    }
>  
>      for ( i = 0; i < count; i++ )
>      {
> @@ -628,6 +660,8 @@ static void *linux_gnttab_grant_map(xc_g
>      }
>  
>   out:
> +    if ( map_size > XC_PAGE_SIZE )
> +        munmap(map, map_size);
>  
>      return addr;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:42:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbKP-0004Zq-Ma; Tue, 24 Apr 2012 08:42:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbKO-0004Zl-PR
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 08:42:29 +0000
Received: from [85.158.138.51:42950] by server-4.bemta-3.messagelabs.com id
	CE/D1-15341-477669F4; Tue, 24 Apr 2012 08:42:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335256947!23543721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3186 invoked from network); 24 Apr 2012 08:42:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 08:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12098363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 08:42:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:42:14 +0100
Message-ID: <1335256933.4347.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Date: Tue, 24 Apr 2012 09:42:13 +0100
In-Reply-To: <6ef297a3761f3061d2e8.1335219661@vollum>
References: <6ef297a3761f3061d2e8.1335219661@vollum>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap()
 for array sizes greater than a page in xc_linux_osdep.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 23:21 +0100, Aravindh Puthiyaparambil wrote:
> When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.
> 
> Fix an error print with the correct function name.
> 
> Do the same for the map array in linux_gnttab_grant_map()
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


> 
> diff -r 274e5accd62d -r 6ef297a3761f tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Fri Apr 20 09:49:06 2012 +0100
> +++ b/tools/libxc/xc_linux_osdep.c	Mon Apr 23 15:16:34 2012 -0700
> @@ -39,6 +39,7 @@
>  #include "xenctrl.h"
>  #include "xenctrlosdep.h"
>  
> +#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
>  #define ERROR(_m, _a...)  xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m , ## _a )
>  #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
>                    " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> @@ -258,7 +259,7 @@ static void *linux_privcmd_map_foreign_b
>                  fd, 0);
>      if ( addr == MAP_FAILED )
>      {
> -        PERROR("xc_map_foreign_batch: mmap failed");
> +        PERROR("xc_map_foreign_bulk: mmap failed");
>          return NULL;
>      }
>  
> @@ -286,7 +287,21 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
>          privcmd_mmapbatch_t ioctlx;
> -        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
> +        xen_pfn_t *pfn;
> +        unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), XC_PAGE_SHIFT);
> +
> +        if ( pfn_arr_size <= XC_PAGE_SIZE )
> +            pfn = alloca(num * sizeof(*pfn));
> +        else
> +        {
> +            pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
> +                       MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +            if ( pfn == MAP_FAILED )
> +            {
> +                PERROR("xc_map_foreign_bulk: mmap of pfn array failed");
> +                return NULL;
> +            }
> +        }
>  
>          memcpy(pfn, arr, num * sizeof(*arr));
>  
> @@ -328,6 +343,9 @@ static void *linux_privcmd_map_foreign_b
>              break;
>          }
>  
> +        if ( pfn_arr_size > XC_PAGE_SIZE )
> +            munmap(pfn, pfn_arr_size);
> +
>          if ( rc == -ENOENT && i == num )
>              rc = 0;
>          else if ( rc )
> @@ -549,6 +567,9 @@ static void *linux_gnttab_grant_map(xc_g
>  {
>      int fd = (int)h;
>      struct ioctl_gntdev_map_grant_ref *map;
> +    unsigned int map_size = ROUNDUP((sizeof(*map) + (count - 1) *
> +                                    sizeof(struct ioctl_gntdev_map_grant_ref)),
> +                                    XC_PAGE_SHIFT);
>      void *addr = NULL;
>      int domids_stride = 1;
>      int i;
> @@ -556,8 +577,19 @@ static void *linux_gnttab_grant_map(xc_g
>      if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
>          domids_stride = 0;
>  
> -    map = alloca(sizeof(*map) +
> -                 (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
> +    if ( map_size <= XC_PAGE_SIZE )
> +        map = alloca(sizeof(*map) +
> +                     (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
> +    else
> +    {
> +        map = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
> +                   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
> +        if ( map == MAP_FAILED )
> +        {
> +            PERROR("linux_gnttab_grant_map: mmap of map failed");
> +            return NULL;
> +        }
> +    }
>  
>      for ( i = 0; i < count; i++ )
>      {
> @@ -628,6 +660,8 @@ static void *linux_gnttab_grant_map(xc_g
>      }
>  
>   out:
> +    if ( map_size > XC_PAGE_SIZE )
> +        munmap(map, map_size);
>  
>      return addr;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMba1-0004pr-Eo; Tue, 24 Apr 2012 08:58:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMba0-0004pm-8F
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 08:58:36 +0000
Received: from [193.109.254.147:29928] by server-9.bemta-14.messagelabs.com id
	79/78-05787-B3B669F4; Tue, 24 Apr 2012 08:58:35 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335257913!335914!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5NTIz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1287 invoked from network); 24 Apr 2012 08:58:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 08:58:35 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Apr 2012 01:58:32 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134566480"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 01:58:32 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 01:58:31 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Tue, 24 Apr 2012 16:58:29 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>, Tim Deegan
	<tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEA==
Date: Tue, 24 Apr 2012 08:58:29 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Tuesday, April 24, 2012 1:19 AM
> 
> Let me know if any of this helps
No, it not works. 

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 08:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 08:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMba1-0004pr-Eo; Tue, 24 Apr 2012 08:58:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMba0-0004pm-8F
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 08:58:36 +0000
Received: from [193.109.254.147:29928] by server-9.bemta-14.messagelabs.com id
	79/78-05787-B3B669F4; Tue, 24 Apr 2012 08:58:35 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335257913!335914!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5NTIz\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1287 invoked from network); 24 Apr 2012 08:58:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 08:58:35 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Apr 2012 01:58:32 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134566480"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 01:58:32 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 01:58:31 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Tue, 24 Apr 2012 16:58:29 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>, Tim Deegan
	<tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEA==
Date: Tue, 24 Apr 2012 08:58:29 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Tuesday, April 24, 2012 1:19 AM
> 
> Let me know if any of this helps
No, it not works. 

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:16:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbqq-00055B-DN; Tue, 24 Apr 2012 09:16:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMbqp-000556-1A
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:15:59 +0000
Received: from [85.158.138.51:28291] by server-5.bemta-3.messagelabs.com id
	FE/0E-17113-E4F669F4; Tue, 24 Apr 2012 09:15:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335258956!23479588!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25408 invoked from network); 24 Apr 2012 09:15:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:15:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMbqf-0009Ld-Qx; Tue, 24 Apr 2012 09:15:49 +0000
Date: Tue, 24 Apr 2012 10:15:49 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120424091549.GA34721@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:26 -0700 on 23 Apr (1335169568), Andres Lagar-Cavilla wrote:
> > At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
> >> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
> >> profiling data with 10 seconds:
> >>
> >> (XEN) p2m_lock 1 lock:
> >> (XEN)   lock:      190733(00000000:14CE5726), block:
> >> 67159(00000007:6AAA53F3)
> >>
> >> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
> >> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
> >> is waiting for the p2m lock. And those data only for idle guest. The
> >> impaction is more seriously when run some workload inside guest.  I
> >> noticed that this change was adding by cs 24770. And before it, we
> >> don't require the p2m lock in _get_gfn_type_access. So is this lock
> >> really necessary?
> >
> > Ugh; that certainly is a regression.  We used to be lock-free on p2m
> > lookups and losing that will be bad for perf in lots of ways.  IIRC the
> > original aim was to use fine-grained per-page locks for this -- there
> > should be no need to hold a per-domain lock during a normal read.
> > Andres, what happened to that code?
> 
> The fine-grained p2m locking code is stashed somewhere and untested.
> Obviously not meant for 4.2. I don't think it'll be useful here: all vcpus
> are hitting the same gfn for the hpet mmio address.

We'll have to do _something_ for 4.2 if it's introducing an 18% CPU
overhead in an otherwise idle VM.

In any case I think this means I probably shouldn't take the patch that
turns on this locking for shadow VMs.  They do a lot more p2m lookups. 

> The other source of contention might come from hvmemul_rep_movs, which
> holds the p2m lock for the duration of the mmio operation. I can optimize
> that one using the get_gfn/get_page/put_gfn pattern mentioned above.

But wouldn't that be unsafe?  What if the p2m changes during the
operation?  Or, conversely, could you replace all uses of the lock in
p2m lookups with get_page() on the result and still get what you need?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:16:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbqq-00055B-DN; Tue, 24 Apr 2012 09:16:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMbqp-000556-1A
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:15:59 +0000
Received: from [85.158.138.51:28291] by server-5.bemta-3.messagelabs.com id
	FE/0E-17113-E4F669F4; Tue, 24 Apr 2012 09:15:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335258956!23479588!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25408 invoked from network); 24 Apr 2012 09:15:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:15:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMbqf-0009Ld-Qx; Tue, 24 Apr 2012 09:15:49 +0000
Date: Tue, 24 Apr 2012 10:15:49 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120424091549.GA34721@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:26 -0700 on 23 Apr (1335169568), Andres Lagar-Cavilla wrote:
> > At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
> >> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
> >> profiling data with 10 seconds:
> >>
> >> (XEN) p2m_lock 1 lock:
> >> (XEN)   lock:      190733(00000000:14CE5726), block:
> >> 67159(00000007:6AAA53F3)
> >>
> >> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
> >> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
> >> is waiting for the p2m lock. And those data only for idle guest. The
> >> impaction is more seriously when run some workload inside guest.  I
> >> noticed that this change was adding by cs 24770. And before it, we
> >> don't require the p2m lock in _get_gfn_type_access. So is this lock
> >> really necessary?
> >
> > Ugh; that certainly is a regression.  We used to be lock-free on p2m
> > lookups and losing that will be bad for perf in lots of ways.  IIRC the
> > original aim was to use fine-grained per-page locks for this -- there
> > should be no need to hold a per-domain lock during a normal read.
> > Andres, what happened to that code?
> 
> The fine-grained p2m locking code is stashed somewhere and untested.
> Obviously not meant for 4.2. I don't think it'll be useful here: all vcpus
> are hitting the same gfn for the hpet mmio address.

We'll have to do _something_ for 4.2 if it's introducing an 18% CPU
overhead in an otherwise idle VM.

In any case I think this means I probably shouldn't take the patch that
turns on this locking for shadow VMs.  They do a lot more p2m lookups. 

> The other source of contention might come from hvmemul_rep_movs, which
> holds the p2m lock for the duration of the mmio operation. I can optimize
> that one using the get_gfn/get_page/put_gfn pattern mentioned above.

But wouldn't that be unsafe?  What if the p2m changes during the
operation?  Or, conversely, could you replace all uses of the lock in
p2m lookups with get_page() on the result and still get what you need?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:17:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbrW-00057F-R6; Tue, 24 Apr 2012 09:16:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbrV-000578-Ml
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:16:41 +0000
Received: from [85.158.138.51:35021] by server-11.bemta-3.messagelabs.com id
	E6/F3-18894-87F669F4; Tue, 24 Apr 2012 09:16:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335259000!23540576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7773 invoked from network); 24 Apr 2012 09:16:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:16:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:16:39 +0100
Message-ID: <1335258998.4347.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 10:16:38 +0100
In-Reply-To: <20373.34767.584624.953798@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 17:48 +0100, Ian Jackson wrote:
> >  * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
> >    calls libxl__initiate_device_remove, so we can disconnect the device and
> >    execute the necessary hotplug scripts instead of just deleting the backend
> >    entries. So libxl__devices_destroy now uses the event library, and so does
> >    libxl_domain_destroy.
> 
> So we no longer have any function which will synchronously and
> immediately destroy a domain and throw away everything to do with it.
> Is it actually the case that you think such a function cannot be
> provided ?

The difference between remove and destroy is documented in libxl.h and
this patch does not change those definitions:

 * libxl_device_<type>_remove(ctx, domid, device):
 *
 *   Removes the given device from the specified domain by performing
 *   an orderly unplug with guest co-operation. This requires that the
 *   guest is running.
 *
 *   This method is currently synchronous and therefore can block
 *   while interacting with the guest.
 *
 * libxl_device_<type>_destroy(ctx, domid, device):
 *
 *   Removes the given device from the specified domain without guest
 *   co-operation. It is guest specific what affect this will have on
 *   a running guest.
 *
 *   This function does not interact with the guest and therefore
 *   cannot block on the guest.

These descriptions must be updated to refer to the new async behaviour.

Does the new implementation of destroy meet these requirements (modulo
now being asynchronous)?

The documentation does not currently mention blocking on the backend
domain, could you please add a comment which describes what the new
requirements are in this respect. Likewise hotplug scripts are not
mentioned in these docs.

In principal I think I am happy with the possibility to block
temporarily with a timeout on a backend domain but ultimately we need a
timeout and a fallback to the "just kill it" mode.

What happens here in 4.3 when we split the hotplug state out according
to whatever becomes of the "Driver domains communication protocol
proposal" thread? At that point the hotplug script state will be
separate from the backend state and we can go back to the "just nuke it"
mode, can't we? Would there be a regression vs. xend for us to stick
with the nuke it mode for 4.2 and fix this properly in 4.3?

I think it is important in the context of this patch to be clear about
what is the desired long term behaviour compared with the short term
behaviour being implemented for 4.2 is. We should also be clear about
what is being done now in order to address xl regressions vs xend. We
should also be clear about what is just papering over an issue for 4.2
vs what the proper fix in 4.3 will be. We also need to know what is
actually new functionality or behaviour (i.e. not fixing an xl vs xend
regression). IOW we need to have clear descriptions of the reasons for
the changes not just what the changes.

I think all the above need to be written down explicitly in either the
commit message or the introductory email, otherwise the review of this
series is just going to continue to go round in circles -- the reasoning
behind these changes is just too complex for a reviewer (even one who is
familiar with all this stuff already) to hold in their head.

> > +SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
> ...
> > +# Hack to prevent the execution of hotplug scripts from udev if the domain
> > +# has been launched from libxl
> > +if [ -n "${HOTPLUG_GATE}" ] && \
> > +   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
> > +    exit 0
> > +fi
> 
> Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
> like the idea of being able to pass some random other xenstore path.
> 
> Also: this xenstore path should be a relative path, ie one relative to
> the xenstore home of domain running this part of the tools.  That way
> the scripts can be easily and automatically disabled for dom0 and
> enabled in driver domains.

XENBUS_PATH contains elements for both the back- and frontend domains as
well as the specific device.

Or do you think the key should be global per-(backend-domain rather than
per-device?

> > +/* Action to pass to hotplug caller functions */
> > +typedef enum {
> > +    CONNECT = 1,
> > +    DISCONNECT = 2
> > +} libxl__hotplug_action;
> 
> These names are rather too generic, I think.

enums should also be declared in lixl_types_internal.idl

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:17:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbrW-00057F-R6; Tue, 24 Apr 2012 09:16:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbrV-000578-Ml
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:16:41 +0000
Received: from [85.158.138.51:35021] by server-11.bemta-3.messagelabs.com id
	E6/F3-18894-87F669F4; Tue, 24 Apr 2012 09:16:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335259000!23540576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7773 invoked from network); 24 Apr 2012 09:16:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:16:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:16:39 +0100
Message-ID: <1335258998.4347.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 10:16:38 +0100
In-Reply-To: <20373.34767.584624.953798@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 17:48 +0100, Ian Jackson wrote:
> >  * libxl__devices_destroy no longer calls libxl__device_destroy, and instead
> >    calls libxl__initiate_device_remove, so we can disconnect the device and
> >    execute the necessary hotplug scripts instead of just deleting the backend
> >    entries. So libxl__devices_destroy now uses the event library, and so does
> >    libxl_domain_destroy.
> 
> So we no longer have any function which will synchronously and
> immediately destroy a domain and throw away everything to do with it.
> Is it actually the case that you think such a function cannot be
> provided ?

The difference between remove and destroy is documented in libxl.h and
this patch does not change those definitions:

 * libxl_device_<type>_remove(ctx, domid, device):
 *
 *   Removes the given device from the specified domain by performing
 *   an orderly unplug with guest co-operation. This requires that the
 *   guest is running.
 *
 *   This method is currently synchronous and therefore can block
 *   while interacting with the guest.
 *
 * libxl_device_<type>_destroy(ctx, domid, device):
 *
 *   Removes the given device from the specified domain without guest
 *   co-operation. It is guest specific what affect this will have on
 *   a running guest.
 *
 *   This function does not interact with the guest and therefore
 *   cannot block on the guest.

These descriptions must be updated to refer to the new async behaviour.

Does the new implementation of destroy meet these requirements (modulo
now being asynchronous)?

The documentation does not currently mention blocking on the backend
domain, could you please add a comment which describes what the new
requirements are in this respect. Likewise hotplug scripts are not
mentioned in these docs.

In principal I think I am happy with the possibility to block
temporarily with a timeout on a backend domain but ultimately we need a
timeout and a fallback to the "just kill it" mode.

What happens here in 4.3 when we split the hotplug state out according
to whatever becomes of the "Driver domains communication protocol
proposal" thread? At that point the hotplug script state will be
separate from the backend state and we can go back to the "just nuke it"
mode, can't we? Would there be a regression vs. xend for us to stick
with the nuke it mode for 4.2 and fix this properly in 4.3?

I think it is important in the context of this patch to be clear about
what is the desired long term behaviour compared with the short term
behaviour being implemented for 4.2 is. We should also be clear about
what is being done now in order to address xl regressions vs xend. We
should also be clear about what is just papering over an issue for 4.2
vs what the proper fix in 4.3 will be. We also need to know what is
actually new functionality or behaviour (i.e. not fixing an xl vs xend
regression). IOW we need to have clear descriptions of the reasons for
the changes not just what the changes.

I think all the above need to be written down explicitly in either the
commit message or the introductory email, otherwise the review of this
series is just going to continue to go round in circles -- the reasoning
behind these changes is just too complex for a reviewer (even one who is
familiar with all this stuff already) to hold in their head.

> > +SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{HOTPLUG_GATE}="/libxl/$env{XENBUS_PATH}/disable_udev", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
> ...
> > +# Hack to prevent the execution of hotplug scripts from udev if the domain
> > +# has been launched from libxl
> > +if [ -n "${HOTPLUG_GATE}" ] && \
> > +   `xenstore-read "$HOTPLUG_GATE" >/dev/null 2>&1`; then
> > +    exit 0
> > +fi
> 
> Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
> like the idea of being able to pass some random other xenstore path.
> 
> Also: this xenstore path should be a relative path, ie one relative to
> the xenstore home of domain running this part of the tools.  That way
> the scripts can be easily and automatically disabled for dom0 and
> enabled in driver domains.

XENBUS_PATH contains elements for both the back- and frontend domains as
well as the specific device.

Or do you think the key should be global per-(backend-domain rather than
per-device?

> > +/* Action to pass to hotplug caller functions */
> > +typedef enum {
> > +    CONNECT = 1,
> > +    DISCONNECT = 2
> > +} libxl__hotplug_action;
> 
> These names are rather too generic, I think.

enums should also be declared in lixl_types_internal.idl

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:17:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:17:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbrh-00058E-83; Tue, 24 Apr 2012 09:16:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMbrf-000580-9R
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:16:51 +0000
Received: from [85.158.143.99:59831] by server-1.bemta-4.messagelabs.com id
	37/7E-20925-28F669F4; Tue, 24 Apr 2012 09:16:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335259009!25015006!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25614 invoked from network); 24 Apr 2012 09:16:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:16:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMbra-0009M1-Oc; Tue, 24 Apr 2012 09:16:46 +0000
Date: Tue, 24 Apr 2012 10:16:46 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120424091646.GB34721@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> > -----Original Message-----
> > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > Sent: Tuesday, April 24, 2012 1:19 AM
> > 
> > Let me know if any of this helps
> No, it not works. 

Do you mean that it doesn't help with the CPU overhead, or that it's
broken in some other way?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:17:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:17:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbrh-00058E-83; Tue, 24 Apr 2012 09:16:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMbrf-000580-9R
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:16:51 +0000
Received: from [85.158.143.99:59831] by server-1.bemta-4.messagelabs.com id
	37/7E-20925-28F669F4; Tue, 24 Apr 2012 09:16:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335259009!25015006!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25614 invoked from network); 24 Apr 2012 09:16:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:16:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMbra-0009M1-Oc; Tue, 24 Apr 2012 09:16:46 +0000
Date: Tue, 24 Apr 2012 10:16:46 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120424091646.GB34721@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> > -----Original Message-----
> > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > Sent: Tuesday, April 24, 2012 1:19 AM
> > 
> > Let me know if any of this helps
> No, it not works. 

Do you mean that it doesn't help with the CPU overhead, or that it's
broken in some other way?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:18:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:18:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbtD-0005Ia-OS; Tue, 24 Apr 2012 09:18:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbtC-0005IO-78
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:18:26 +0000
Received: from [193.109.254.147:57259] by server-7.bemta-14.messagelabs.com id
	0A/1E-01627-1EF669F4; Tue, 24 Apr 2012 09:18:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335259101!340122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8365 invoked from network); 24 Apr 2012 09:18:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:18:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:18:21 +0100
Message-ID: <1335259100.4347.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 24 Apr 2012 10:18:20 +0100
In-Reply-To: <4F958265.9020107@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com> <4F955999.3030500@citrix.com>
	<1335189749.4347.27.camel@zakaz.uk.xensource.com>
	<4F958265.9020107@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
 libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA0LTIzIGF0IDE3OjI1ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiA+IE9uIE1vbiwgMjAxMi0wNC0yMyBhdCAxNDoz
MSArMDEwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+ID4+IE1hcmVrIE1hcmN6eWtvd3NraSBl
c2NyaWJpw7M6Cj4gPj4+IE9uIDIwLjA0LjIwMTIgMTU6MjMsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+Pj4+IFRoaXMgc2VyaWVzIHJlbW92ZXMgdGhlIHVzZSBvZiB1ZGV2IHJ1bGVzIHRvIGNh
bGwgaG90cGx1ZyBzY3JpcHRzIHdoZW4gdXNpbmcKPiA+Pj4+IGxpYnhsLiBTY3JpcHRzIGFyZSBk
aXJlY3RseSBjYWxsZWQgZnJvbSB0aGUgdG9vbHN0YWNrIGF0IHRoZSBuZWNlc3NhcnkgcG9pbnRz
LAo+ID4+Pj4gbWFraW5nIHVzZSBvZiB0aGUgbmV3IGV2ZW50IGxpYnJhcnkgYW5kIGl0J3MgZm9y
ayBzdXBwb3J0Lgo+ID4+PiBXaGF0IGFib3V0IG5vbi1kb20wIGJhY2tlbmRzPyBUaGVyZSB3aWxs
IGJlIG5vIHNpbXBsZSB3YXkgdG8gZXhlY3V0ZSBzY3JpcHQKPiA+Pj4gdGhlcmUgYnkgbGlieGwg
d2l0aG91dCBoZWxwIGZyb20gdWRldi4uLgo+ID4+IEEgbmV3IGNvbmZpZyBvcHRpb24gaGFzIGJl
ZW4gYWRkZWQgb24gdGhpcyBzZXJpZXMKPiA+PiAoZGlzYWJsZV94bF92aWZfc2NyaXB0cykgdGhh
dCBhbGxvd3MgdGhlIHVzZXIgdG8ga2VlcCBleGVjdXRpbmcgdmlmCj4gPj4gc2NyaXB0cyBmcm9t
IHVkZXYsIHNvIHRoaXMgZnVuY3Rpb25hbGl0eSBpcyBub3QgbG9zdC4KPiA+Cj4gPiBJbiB0aGUg
bG9uZyB0ZXJtIChlLmcuIGZvciA0LjMpIHdlIGludGVuZCB0byBvdmVyaGF1bCB0aGlzIGluIGEg
d2F5Cj4gPiB3aGljaCBtYWtlcyBkcml2ZXIgZG9tYWlucyB3b3JrIHdpdGhvdXQgdWRldiBhdCBh
bGwsIHNlZSAiRHJpdmVyIGRvbWFpbnMKPiA+IGNvbW11bmljYXRpb24gcHJvdG9jb2wgcHJvcG9z
YWwiIHBvc3RlZCBieSBJYW4gSmFja3NvbiBzZXZlcmFsIHdlZWtzIGFnbwo+ID4gLS0gaXQgd291
bGQgYmUgZ29vZCB0byBjb25maXJtIHRoYXQgdGhlIHNjaGVtZSBwcm9wb3NlZCB0aGVyZSB3b3Jr
cyB3ZWxsCj4gPiBmb3IgUXViZXMtT1MgdG9vLgo+ID4KPiA+IEluIHRoZSBzaG9ydCB0ZXJtIChp
LmUuIDQuMikgd2UgZmVsdCBpdCB3YXMgdG9vIGxhdGUgdG8gYmUgbWFraW5nIHRoZXNlCj4gPiBz
b3J0cyBvZiBjaGFuZ2VzIChlLmcuIGltcGxlbWVudGluZyB0aGF0IGNvbXBsZXRlIHByb3RvY29s
KSBhbmQKPiA+IHRoZXJlZm9yZSB0aGUgY29tcHJvbWlzZSBpcyB0aGF0IHhsIHdpbGwgZXhlY3V0
ZSB0aGUgc2NyaXB0cyBvbmx5IGluIHRoZQo+ID4gY2FzZSB0aGF0IGRvbTAgaXMgYWxzbyB0aGUg
YmFja2VuZCBkb21haW4gd2hpbGUgZm9yIGRyaXZlciBkb21haW5zIHdlCj4gPiByZXRhaW4gdGhl
IHByZS00LjIgYmVoYXZpb3VyIG9mIGV4ZWN1dGluZyB0aGUgaG90cGx1ZyBzY3JpcHRzIHZpYSB1
ZGV2Cj4gPiBpbnNpZGUgdGhlIGRyaXZlciBkb21haW4uIFRoaXMgd2FzIG5lY2Vzc2FyeSBpbiBv
cmRlciB0byBmaXggdGhpbmdzIHN1Y2gKPiA+IGFzIHRlYXJkb3duIG9mIGRpc2tzIG9uIE5ldEJT
RCBhbmQgdGVhcmRvd24gb2YgTklDcyBvbiBvcGVudnN3aXRjaAo+ID4gKGN1cnJlbnRseSBib3Ro
IGFyZSBicm9rZW4gZXZlbiB3aXRoIGJhY2tlbmQgPSBkb20wIGR1ZSB0byBzaG9ydCBjb21pbmdz
Cj4gPiBpbiB0aGUgcHJldmlvdXMgYXBwcm9hY2gpIHdoaWxlIG5vdCByZWdyZXNzaW5nIHRoZSBk
cml2ZXIgZG9tYWluIHVzZQo+ID4gY2FzZS4KPiA+Cj4gPiBCeSBkZWZhdWx0IGRvIHdlIHdyaXRl
IHRoZSB4ZW5zdG9yZSBrZXkgdG8gc3VwcHJlc3MgdWRldiBydW5uaW5nIHRoZQo+ID4gc2NyaXB0
cyByZWdhcmRsZXNzIG9mIHdoaWNoIGRvbWFpbiB0aGUgYmFja2VuZCBpcyBpbiBvciBvbmx5IGZv
cgo+ID4gYmFja2VuZD0wPwo+IAo+IEZvciB2YmQgZGV2aWNlcyB3ZSB3cml0ZSBpdCBldmVyeXRp
bWUsIGZvciB2aWZzIGRldmljZXMgd2Ugd3JpdGUgaXQgaWYgCj4gZGlzYWJsZV94bF92aWZfc2Ny
aXB0cyBpcyBub3Qgc2V0Lgo+IAo+ID4gT3IgaXMgaXQgbmVjZXNzYXJ5IHRvIHVzZSB0aGUgb3Zl
cnJpZGUgY29uZmlnIG9wdGlvbiBmb3IKPiA+IGRyaXZlciBkb21haW4/Cj4gCj4gU28gdGhlIG5l
dyBwcm9wb3NhbCBpcyB0byBhZGQgYSBkaXNhYmxlX3hsX3ZiZF9zY3JpcHRzIGFuZCB0byBkZXRl
Y3QgaWYgCj4gdGhlIGRldmljZSBiYWNrZW5kIGlzIGRpZmZlcmVudCB0aGFuIGRvbTAsIGlmIGl0
IGlzIGluIGZhY3QgZGlmZmVyZW50IAo+IHRoYW4gZG9tMCBkb24ndCBleGVjdXRlIGhvdHBsdWcg
c2NyaXB0cyBmcm9tIHhsICh0aGlzIHdpbGwgb25seSB3b3JrIGZvciAKPiB2aWZzLCBiZWNhdXNl
IHRoZXJlJ3Mgbm8gc3VwcG9ydCBmb3Igc2V0dGluZyB0aGUgZGV2aWNlIGRvbWFpbiBmb3IgdmJk
IAo+IGRldmljZXMgeWV0KS4KCklmIHdlIGNhbiBkZXRlY3QgSSBkb24ndCBzZWUgd2h5IHdlIHNo
b3VsZG4ndCwgdW5sZXNzIGl0IHR1cm5zIG91dCB0bwphZGQgY29tcGxleGl0eSB3aGljaCB3ZSB3
YW50IHRvIGRlZmVyIHVudGlsIDQuMy4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:18:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:18:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbtD-0005Ia-OS; Tue, 24 Apr 2012 09:18:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbtC-0005IO-78
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:18:26 +0000
Received: from [193.109.254.147:57259] by server-7.bemta-14.messagelabs.com id
	0A/1E-01627-1EF669F4; Tue, 24 Apr 2012 09:18:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335259101!340122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8365 invoked from network); 24 Apr 2012 09:18:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:18:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:18:21 +0100
Message-ID: <1335259100.4347.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 24 Apr 2012 10:18:20 +0100
In-Reply-To: <4F958265.9020107@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<4F954747.9030305@invisiblethingslab.com> <4F955999.3030500@citrix.com>
	<1335189749.4347.27.camel@zakaz.uk.xensource.com>
	<4F958265.9020107@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 0/5] libxl: call hotplug scripts from
 libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA0LTIzIGF0IDE3OjI1ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiA+IE9uIE1vbiwgMjAxMi0wNC0yMyBhdCAxNDoz
MSArMDEwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+ID4+IE1hcmVrIE1hcmN6eWtvd3NraSBl
c2NyaWJpw7M6Cj4gPj4+IE9uIDIwLjA0LjIwMTIgMTU6MjMsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+Pj4+IFRoaXMgc2VyaWVzIHJlbW92ZXMgdGhlIHVzZSBvZiB1ZGV2IHJ1bGVzIHRvIGNh
bGwgaG90cGx1ZyBzY3JpcHRzIHdoZW4gdXNpbmcKPiA+Pj4+IGxpYnhsLiBTY3JpcHRzIGFyZSBk
aXJlY3RseSBjYWxsZWQgZnJvbSB0aGUgdG9vbHN0YWNrIGF0IHRoZSBuZWNlc3NhcnkgcG9pbnRz
LAo+ID4+Pj4gbWFraW5nIHVzZSBvZiB0aGUgbmV3IGV2ZW50IGxpYnJhcnkgYW5kIGl0J3MgZm9y
ayBzdXBwb3J0Lgo+ID4+PiBXaGF0IGFib3V0IG5vbi1kb20wIGJhY2tlbmRzPyBUaGVyZSB3aWxs
IGJlIG5vIHNpbXBsZSB3YXkgdG8gZXhlY3V0ZSBzY3JpcHQKPiA+Pj4gdGhlcmUgYnkgbGlieGwg
d2l0aG91dCBoZWxwIGZyb20gdWRldi4uLgo+ID4+IEEgbmV3IGNvbmZpZyBvcHRpb24gaGFzIGJl
ZW4gYWRkZWQgb24gdGhpcyBzZXJpZXMKPiA+PiAoZGlzYWJsZV94bF92aWZfc2NyaXB0cykgdGhh
dCBhbGxvd3MgdGhlIHVzZXIgdG8ga2VlcCBleGVjdXRpbmcgdmlmCj4gPj4gc2NyaXB0cyBmcm9t
IHVkZXYsIHNvIHRoaXMgZnVuY3Rpb25hbGl0eSBpcyBub3QgbG9zdC4KPiA+Cj4gPiBJbiB0aGUg
bG9uZyB0ZXJtIChlLmcuIGZvciA0LjMpIHdlIGludGVuZCB0byBvdmVyaGF1bCB0aGlzIGluIGEg
d2F5Cj4gPiB3aGljaCBtYWtlcyBkcml2ZXIgZG9tYWlucyB3b3JrIHdpdGhvdXQgdWRldiBhdCBh
bGwsIHNlZSAiRHJpdmVyIGRvbWFpbnMKPiA+IGNvbW11bmljYXRpb24gcHJvdG9jb2wgcHJvcG9z
YWwiIHBvc3RlZCBieSBJYW4gSmFja3NvbiBzZXZlcmFsIHdlZWtzIGFnbwo+ID4gLS0gaXQgd291
bGQgYmUgZ29vZCB0byBjb25maXJtIHRoYXQgdGhlIHNjaGVtZSBwcm9wb3NlZCB0aGVyZSB3b3Jr
cyB3ZWxsCj4gPiBmb3IgUXViZXMtT1MgdG9vLgo+ID4KPiA+IEluIHRoZSBzaG9ydCB0ZXJtIChp
LmUuIDQuMikgd2UgZmVsdCBpdCB3YXMgdG9vIGxhdGUgdG8gYmUgbWFraW5nIHRoZXNlCj4gPiBz
b3J0cyBvZiBjaGFuZ2VzIChlLmcuIGltcGxlbWVudGluZyB0aGF0IGNvbXBsZXRlIHByb3RvY29s
KSBhbmQKPiA+IHRoZXJlZm9yZSB0aGUgY29tcHJvbWlzZSBpcyB0aGF0IHhsIHdpbGwgZXhlY3V0
ZSB0aGUgc2NyaXB0cyBvbmx5IGluIHRoZQo+ID4gY2FzZSB0aGF0IGRvbTAgaXMgYWxzbyB0aGUg
YmFja2VuZCBkb21haW4gd2hpbGUgZm9yIGRyaXZlciBkb21haW5zIHdlCj4gPiByZXRhaW4gdGhl
IHByZS00LjIgYmVoYXZpb3VyIG9mIGV4ZWN1dGluZyB0aGUgaG90cGx1ZyBzY3JpcHRzIHZpYSB1
ZGV2Cj4gPiBpbnNpZGUgdGhlIGRyaXZlciBkb21haW4uIFRoaXMgd2FzIG5lY2Vzc2FyeSBpbiBv
cmRlciB0byBmaXggdGhpbmdzIHN1Y2gKPiA+IGFzIHRlYXJkb3duIG9mIGRpc2tzIG9uIE5ldEJT
RCBhbmQgdGVhcmRvd24gb2YgTklDcyBvbiBvcGVudnN3aXRjaAo+ID4gKGN1cnJlbnRseSBib3Ro
IGFyZSBicm9rZW4gZXZlbiB3aXRoIGJhY2tlbmQgPSBkb20wIGR1ZSB0byBzaG9ydCBjb21pbmdz
Cj4gPiBpbiB0aGUgcHJldmlvdXMgYXBwcm9hY2gpIHdoaWxlIG5vdCByZWdyZXNzaW5nIHRoZSBk
cml2ZXIgZG9tYWluIHVzZQo+ID4gY2FzZS4KPiA+Cj4gPiBCeSBkZWZhdWx0IGRvIHdlIHdyaXRl
IHRoZSB4ZW5zdG9yZSBrZXkgdG8gc3VwcHJlc3MgdWRldiBydW5uaW5nIHRoZQo+ID4gc2NyaXB0
cyByZWdhcmRsZXNzIG9mIHdoaWNoIGRvbWFpbiB0aGUgYmFja2VuZCBpcyBpbiBvciBvbmx5IGZv
cgo+ID4gYmFja2VuZD0wPwo+IAo+IEZvciB2YmQgZGV2aWNlcyB3ZSB3cml0ZSBpdCBldmVyeXRp
bWUsIGZvciB2aWZzIGRldmljZXMgd2Ugd3JpdGUgaXQgaWYgCj4gZGlzYWJsZV94bF92aWZfc2Ny
aXB0cyBpcyBub3Qgc2V0Lgo+IAo+ID4gT3IgaXMgaXQgbmVjZXNzYXJ5IHRvIHVzZSB0aGUgb3Zl
cnJpZGUgY29uZmlnIG9wdGlvbiBmb3IKPiA+IGRyaXZlciBkb21haW4/Cj4gCj4gU28gdGhlIG5l
dyBwcm9wb3NhbCBpcyB0byBhZGQgYSBkaXNhYmxlX3hsX3ZiZF9zY3JpcHRzIGFuZCB0byBkZXRl
Y3QgaWYgCj4gdGhlIGRldmljZSBiYWNrZW5kIGlzIGRpZmZlcmVudCB0aGFuIGRvbTAsIGlmIGl0
IGlzIGluIGZhY3QgZGlmZmVyZW50IAo+IHRoYW4gZG9tMCBkb24ndCBleGVjdXRlIGhvdHBsdWcg
c2NyaXB0cyBmcm9tIHhsICh0aGlzIHdpbGwgb25seSB3b3JrIGZvciAKPiB2aWZzLCBiZWNhdXNl
IHRoZXJlJ3Mgbm8gc3VwcG9ydCBmb3Igc2V0dGluZyB0aGUgZGV2aWNlIGRvbWFpbiBmb3IgdmJk
IAo+IGRldmljZXMgeWV0KS4KCklmIHdlIGNhbiBkZXRlY3QgSSBkb24ndCBzZWUgd2h5IHdlIHNo
b3VsZG4ndCwgdW5sZXNzIGl0IHR1cm5zIG91dCB0bwphZGQgY29tcGxleGl0eSB3aGljaCB3ZSB3
YW50IHRvIGRlZmVyIHVudGlsIDQuMy4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:19:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbtj-0005NQ-65; Tue, 24 Apr 2012 09:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbth-0005N2-Ji
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:18:57 +0000
Received: from [193.109.254.147:21640] by server-4.bemta-14.messagelabs.com id
	9D/66-11570-000769F4; Tue, 24 Apr 2012 09:18:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335259136!5975888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4692 invoked from network); 24 Apr 2012 09:18:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:18:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:18:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:18:55 +0100
Message-ID: <1335259134.4347.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 10:18:54 +0100
In-Reply-To: <20373.35440.226796.301582@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
	<20373.35440.226796.301582@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
 libxl	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 17:59 +0100, Ian Jackson wrote:

> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 5cf9708..0b2c832 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
> >      ("ifname", string),
> >      ("script", string),
> >      ("nictype", libxl_nic_type),
> > +    ("disable_xl_vif_script", integer),
> >      ])
> 
> We shouldn't have config options of the form "disable_...".  They
> should all be phrased as "enable" or in this case "run".  And I'm not
> convinced by "xl", but since there isn't any patch to the xl domain
> configuration doc for this new option I'm not sure.  Of course
> documentation is needed...

Also this should either be a bool, or perhaps a libxl_defbool if we want
to do auto detection.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:19:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbtj-0005NQ-65; Tue, 24 Apr 2012 09:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbth-0005N2-Ji
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:18:57 +0000
Received: from [193.109.254.147:21640] by server-4.bemta-14.messagelabs.com id
	9D/66-11570-000769F4; Tue, 24 Apr 2012 09:18:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335259136!5975888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4692 invoked from network); 24 Apr 2012 09:18:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:18:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:18:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:18:55 +0100
Message-ID: <1335259134.4347.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 10:18:54 +0100
In-Reply-To: <20373.35440.226796.301582@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
	<20373.35440.226796.301582@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
 libxl	for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 17:59 +0100, Ian Jackson wrote:

> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 5cf9708..0b2c832 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -343,6 +343,7 @@ libxl_device_nic = Struct("device_nic", [
> >      ("ifname", string),
> >      ("script", string),
> >      ("nictype", libxl_nic_type),
> > +    ("disable_xl_vif_script", integer),
> >      ])
> 
> We shouldn't have config options of the form "disable_...".  They
> should all be phrased as "enable" or in this case "run".  And I'm not
> convinced by "xl", but since there isn't any patch to the xl domain
> configuration doc for this new option I'm not sure.  Of course
> documentation is needed...

Also this should either be a bool, or perhaps a libxl_defbool if we want
to do auto detection.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:19:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbuL-0005TM-Kn; Tue, 24 Apr 2012 09:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMbuK-0005T1-KH
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:19:36 +0000
Received: from [85.158.143.99:21013] by server-1.bemta-4.messagelabs.com id
	F1/F3-20925-720769F4; Tue, 24 Apr 2012 09:19:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335259173!24430238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4431 invoked from network); 24 Apr 2012 09:19:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:19:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 10:19:32 +0100
Message-Id: <4F968C41020000780007F86C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 10:19:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
 "Keir Fraser" <keir@xen.org>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
> 
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

As there were no -rc1's so far anyway, I'd like to additionally propose
the first hunk of 25168:d5f9005dfc4a for 4.1.

Further candidates, though more involved in terms of what
they change, appear to be 25191:a95fc7decc83,
25195:a06e6cdeafe3, and 25196:375fa55c7a6c.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:19:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbuL-0005TM-Kn; Tue, 24 Apr 2012 09:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMbuK-0005T1-KH
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:19:36 +0000
Received: from [85.158.143.99:21013] by server-1.bemta-4.messagelabs.com id
	F1/F3-20925-720769F4; Tue, 24 Apr 2012 09:19:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335259173!24430238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4431 invoked from network); 24 Apr 2012 09:19:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:19:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 10:19:32 +0100
Message-Id: <4F968C41020000780007F86C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 10:19:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
 "Keir Fraser" <keir@xen.org>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
> 
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

As there were no -rc1's so far anyway, I'd like to additionally propose
the first hunk of 25168:d5f9005dfc4a for 4.1.

Further candidates, though more involved in terms of what
they change, appear to be 25191:a95fc7decc83,
25195:a06e6cdeafe3, and 25196:375fa55c7a6c.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:21:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbvV-0005fg-4D; Tue, 24 Apr 2012 09:20:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbvS-0005fJ-R9
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:20:47 +0000
Received: from [85.158.138.51:14151] by server-2.bemta-3.messagelabs.com id
	3B/E4-09269-D60769F4; Tue, 24 Apr 2012 09:20:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335259245!14568428!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27874 invoked from network); 24 Apr 2012 09:20:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:20:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:20:44 +0100
Message-ID: <1335259243.4347.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 10:20:43 +0100
In-Reply-To: <alpine.DEB.2.00.1204231618590.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
	<1334930892.28331.95.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231618590.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 18:40 +0100, Stefano Stabellini wrote:
> On Fri, 20 Apr 2012, Ian Campbell wrote:
> > On Fri, 2012-04-20 at 15:04 +0100, Stefano Stabellini wrote:
> > > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > > > > Introduce a blkdev_start in xl.conf and pass it to
> > > > > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > > > > libxl__device_disk_local_attach.
> > > > 
> > > > Surely this should be passed in the domain config structure rather
> > > > than being an adhoc parameter.
> > > 
> > > I don't think so, see below.
> > > 
> > > > If the problem with that is that it really ought to be host-global and
> > > > come from xl.conf, then perhaps we need another config struct.  But
> > > > really I think that's overkill.  There is nothing wrong with taking
> > > > parameters from xl.conf and putting them in the libxl domain config.
> > >  
> > > Another host-global config struct is definitely overkill, but we cannot
> > > really pass this parameter in the libxl domain config, because this
> > > option has nothing to do with the domain config.
> > > It would be confusing and incorrect.
> > 
> > You could argue that "domain config" was actually as much about details
> > on how to build the guest as it was about the "domain config" as such.
> > Members of that struct like the device model version, xsm ssid, disable
> > migrate, cpupool id, etc could all be argued to fit into the same "grey
> > area".
> 
> What about a new libxl_domain_build_info parameter?

Sure, when I say "domain config" I think I probably mean
"libxl_domain_config or one of the member therein"...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:21:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMbvV-0005fg-4D; Tue, 24 Apr 2012 09:20:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMbvS-0005fJ-R9
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:20:47 +0000
Received: from [85.158.138.51:14151] by server-2.bemta-3.messagelabs.com id
	3B/E4-09269-D60769F4; Tue, 24 Apr 2012 09:20:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335259245!14568428!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg1NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27874 invoked from network); 24 Apr 2012 09:20:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12099898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:20:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 10:20:44 +0100
Message-ID: <1335259243.4347.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 10:20:43 +0100
In-Reply-To: <alpine.DEB.2.00.1204231618590.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204161848030.26786@kaball-desktop>
	<1334601190-14187-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20365.44206.42175.501006@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204201501530.26786@kaball-desktop>
	<1334930892.28331.95.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231618590.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start
 parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 18:40 +0100, Stefano Stabellini wrote:
> On Fri, 20 Apr 2012, Ian Campbell wrote:
> > On Fri, 2012-04-20 at 15:04 +0100, Stefano Stabellini wrote:
> > > On Tue, 17 Apr 2012, Ian Jackson wrote:
> > > > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter"):
> > > > > Introduce a blkdev_start in xl.conf and pass it to
> > > > > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > > > > libxl__device_disk_local_attach.
> > > > 
> > > > Surely this should be passed in the domain config structure rather
> > > > than being an adhoc parameter.
> > > 
> > > I don't think so, see below.
> > > 
> > > > If the problem with that is that it really ought to be host-global and
> > > > come from xl.conf, then perhaps we need another config struct.  But
> > > > really I think that's overkill.  There is nothing wrong with taking
> > > > parameters from xl.conf and putting them in the libxl domain config.
> > >  
> > > Another host-global config struct is definitely overkill, but we cannot
> > > really pass this parameter in the libxl domain config, because this
> > > option has nothing to do with the domain config.
> > > It would be confusing and incorrect.
> > 
> > You could argue that "domain config" was actually as much about details
> > on how to build the guest as it was about the "domain config" as such.
> > Members of that struct like the device model version, xsm ssid, disable
> > migrate, cpupool id, etc could all be argued to fit into the same "grey
> > area".
> 
> What about a new libxl_domain_build_info parameter?

Sure, when I say "domain config" I think I probably mean
"libxl_domain_config or one of the member therein"...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMc5c-00065L-Io; Tue, 24 Apr 2012 09:31:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMc5b-00065G-Hk
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:31:15 +0000
Received: from [85.158.143.35:3372] by server-3.bemta-4.messagelabs.com id
	22/88-05853-2E2769F4; Tue, 24 Apr 2012 09:31:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335259873!17522133!1
X-Originating-IP: [82.57.200.102]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22457 invoked from network); 24 Apr 2012 09:31:14 -0000
Received: from smtp206.alice.it (HELO smtp206.alice.it) (82.57.200.102)
	by server-14.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 09:31:14 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp206.alice.it (8.6.023.02)
	id 4F1836AD0B3C99CA; Tue, 24 Apr 2012 11:31:13 +0200
Message-ID: <4F9672DD.2080902@tiscali.it>
Date: Tue, 24 Apr 2012 11:31:09 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, ian.Campbell@citrix.com, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Cdrom empty not working with new disk configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8219922187862546331=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8219922187862546331==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070100040602060500080906"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070100040602060500080906
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

With new xl disk configuration is not possible set empty cdrom

disk=3D['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']

xl create /etc/xen/XP.cfg
Parsing config file /etc/xen/XP.cfg
libxl: error: libxl_device.c:197:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb failed to stat: : No such file or directory
libxl: error: libxl_dm.c:1045:libxl__destroy_device_model: Couldn't find =

device model's pid: No such file or directory
libxl: error: libxl.c:1094:libxl_domain_destroy:=20
libxl__destroy_device_model failed for 8

Now xl cd-insert/cd-eject are not working
xl cd-insert is not possible without empty cdrom and cd-eject fail for=20
error on setting of empty cdrom

xl cd-eject XP hdc
command line: config parsing error in disk specification: unknown value=20
for format: near `hdc:cdrom' in `,hdc:cdrom,r'

Tips on how to solve the problem?

Thanks for any reply and sorry for bad english


--------------ms070100040602060500080906
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQyNDA5MzEwOVowIwYJKoZIhvcNAQkEMRYEFA61hM+p6gWRchpcc1sNSZIw
tGSpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQAztBeCdEzTN32kV0l4yl2BaU6TYw4xjreQLcN+Squd
cg+P8Ub0aq276JXnPbKdKvAbXw4TSIpXVvnzFGOYgRDZlGQ1iDEeK3R3iRTJm9HIfu/h70cH
LHh09aYXYkFZ3Kc730a7HnsYFD86T2JftMdABd5EnzdhMfylp62m3jRsPqb13rHN9cXda9EJ
1uCPK1wgSvKGEQXZEpXStuEVeoIfn2g5P5CMgtAGOu5bwK8Bg/v8pkE5iqg0sdfWwfobAN/g
chhR/5X4wz/rJxyXUuLjywr/ghoqiEcSwBsIL6cgk+OlSU4nfa0/nCLxXFByxLk0bSbc6brM
5CtN0pCCQZl6AAAAAAAA
--------------ms070100040602060500080906--


--===============8219922187862546331==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8219922187862546331==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 09:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMc5c-00065L-Io; Tue, 24 Apr 2012 09:31:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMc5b-00065G-Hk
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:31:15 +0000
Received: from [85.158.143.35:3372] by server-3.bemta-4.messagelabs.com id
	22/88-05853-2E2769F4; Tue, 24 Apr 2012 09:31:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335259873!17522133!1
X-Originating-IP: [82.57.200.102]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22457 invoked from network); 24 Apr 2012 09:31:14 -0000
Received: from smtp206.alice.it (HELO smtp206.alice.it) (82.57.200.102)
	by server-14.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 09:31:14 -0000
Received: from [192.168.178.50] (82.60.21.220) by smtp206.alice.it (8.6.023.02)
	id 4F1836AD0B3C99CA; Tue, 24 Apr 2012 11:31:13 +0200
Message-ID: <4F9672DD.2080902@tiscali.it>
Date: Tue, 24 Apr 2012 11:31:09 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, ian.Campbell@citrix.com, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Cdrom empty not working with new disk configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8219922187862546331=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8219922187862546331==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070100040602060500080906"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070100040602060500080906
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

With new xl disk configuration is not possible set empty cdrom

disk=3D['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']

xl create /etc/xen/XP.cfg
Parsing config file /etc/xen/XP.cfg
libxl: error: libxl_device.c:197:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb failed to stat: : No such file or directory
libxl: error: libxl_dm.c:1045:libxl__destroy_device_model: Couldn't find =

device model's pid: No such file or directory
libxl: error: libxl.c:1094:libxl_domain_destroy:=20
libxl__destroy_device_model failed for 8

Now xl cd-insert/cd-eject are not working
xl cd-insert is not possible without empty cdrom and cd-eject fail for=20
error on setting of empty cdrom

xl cd-eject XP hdc
command line: config parsing error in disk specification: unknown value=20
for format: near `hdc:cdrom' in `,hdc:cdrom,r'

Tips on how to solve the problem?

Thanks for any reply and sorry for bad english


--------------ms070100040602060500080906
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDQyNDA5MzEwOVowIwYJKoZIhvcNAQkEMRYEFA61hM+p6gWRchpcc1sNSZIw
tGSpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQAztBeCdEzTN32kV0l4yl2BaU6TYw4xjreQLcN+Squd
cg+P8Ub0aq276JXnPbKdKvAbXw4TSIpXVvnzFGOYgRDZlGQ1iDEeK3R3iRTJm9HIfu/h70cH
LHh09aYXYkFZ3Kc730a7HnsYFD86T2JftMdABd5EnzdhMfylp62m3jRsPqb13rHN9cXda9EJ
1uCPK1wgSvKGEQXZEpXStuEVeoIfn2g5P5CMgtAGOu5bwK8Bg/v8pkE5iqg0sdfWwfobAN/g
chhR/5X4wz/rJxyXUuLjywr/ghoqiEcSwBsIL6cgk+OlSU4nfa0/nCLxXFByxLk0bSbc6brM
5CtN0pCCQZl6AAAAAAAA
--------------ms070100040602060500080906--


--===============8219922187862546331==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8219922187862546331==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 09:36:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:36:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcAi-0006Di-Cn; Tue, 24 Apr 2012 09:36:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMcAg-0006Dc-Ul
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:36:31 +0000
Received: from [85.158.138.51:64284] by server-9.bemta-3.messagelabs.com id
	CD/8E-26691-E14769F4; Tue, 24 Apr 2012 09:36:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335260189!23340019!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 24 Apr 2012 09:36:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:36:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMcAc-0009Pt-IO; Tue, 24 Apr 2012 09:36:26 +0000
Date: Tue, 24 Apr 2012 10:36:26 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120424093626.GC34721@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423183709.5636656f@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> On Thu, 19 Apr 2012 15:15:27 +0100
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:29 -0700 on 13 Apr (1334341792), Mukesh Rathor wrote:
> >  - AFAICT you're using set_mmio_p2m_entry and adding a new unmap
> >    operation just to avoid having the m2p updated.  Since you can't
> > rely on the unmap always happening through the new call (and you don't
> >    enforce it anywhere), it would be better to add a new p2m_type
> >    just for non-grant foreign mappings.  Then you can gate the m2p
> >    updates in the existing code on the map being normal RAM, as is
> >    already done for p2m_is_grant().
>  
> Hi Tim,
> 
> The variants of get_page* are confusing me, so wanna double check with 
> you.  I should be able to do something like following, right?
> 

[...]

>     if ( (rc=get_page_and_type_from_pagenr(mfn, PGT_writable_page,fdom,0,0)) ) {
>         put_pg_owner(fdom);
>         return rc;
>     }

Yes, but: 

 - You should use get_page_from_pagenr() if fdom is paging_mode_external()
   and reference/copy the comment in get_page_from_l1e() to explain why:

    /* Foreign mappings into guests in shadow external mode don't       
     * contribute to writeable mapping refcounts.  (This allows the
     * qemu-dm helper process in dom0 to map the domain's memory without
     * messing up the count of "real" writable mappings.) */

 - You should drop the refcount (and typecount, if you took one) if the 
   mapping fails.

 - You need to make sure that _any_ path that removes the mapping drops
   the ref/type (_after_ any TLB flushes have happened, please!)  Maybe
   the best way to do that is in ept_set_entry() for EPT and
   paging_write_p2m_entry() for NPT/shadow. 

 - You need to handle the p2m teardown path as well.  I think the best
   way to do that is to hoist the relinquish_shared_pages() loop 
   up into a new function in p2m.c, and add your put_page[_and_type] 
   calls in there. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:36:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:36:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcAi-0006Di-Cn; Tue, 24 Apr 2012 09:36:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMcAg-0006Dc-Ul
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:36:31 +0000
Received: from [85.158.138.51:64284] by server-9.bemta-3.messagelabs.com id
	CD/8E-26691-E14769F4; Tue, 24 Apr 2012 09:36:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335260189!23340019!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 24 Apr 2012 09:36:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 09:36:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMcAc-0009Pt-IO; Tue, 24 Apr 2012 09:36:26 +0000
Date: Tue, 24 Apr 2012 10:36:26 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120424093626.GC34721@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423183709.5636656f@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> On Thu, 19 Apr 2012 15:15:27 +0100
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:29 -0700 on 13 Apr (1334341792), Mukesh Rathor wrote:
> >  - AFAICT you're using set_mmio_p2m_entry and adding a new unmap
> >    operation just to avoid having the m2p updated.  Since you can't
> > rely on the unmap always happening through the new call (and you don't
> >    enforce it anywhere), it would be better to add a new p2m_type
> >    just for non-grant foreign mappings.  Then you can gate the m2p
> >    updates in the existing code on the map being normal RAM, as is
> >    already done for p2m_is_grant().
>  
> Hi Tim,
> 
> The variants of get_page* are confusing me, so wanna double check with 
> you.  I should be able to do something like following, right?
> 

[...]

>     if ( (rc=get_page_and_type_from_pagenr(mfn, PGT_writable_page,fdom,0,0)) ) {
>         put_pg_owner(fdom);
>         return rc;
>     }

Yes, but: 

 - You should use get_page_from_pagenr() if fdom is paging_mode_external()
   and reference/copy the comment in get_page_from_l1e() to explain why:

    /* Foreign mappings into guests in shadow external mode don't       
     * contribute to writeable mapping refcounts.  (This allows the
     * qemu-dm helper process in dom0 to map the domain's memory without
     * messing up the count of "real" writable mappings.) */

 - You should drop the refcount (and typecount, if you took one) if the 
   mapping fails.

 - You need to make sure that _any_ path that removes the mapping drops
   the ref/type (_after_ any TLB flushes have happened, please!)  Maybe
   the best way to do that is in ept_set_entry() for EPT and
   paging_write_p2m_entry() for NPT/shadow. 

 - You need to handle the p2m teardown path as well.  I think the best
   way to do that is to hoist the relinquish_shared_pages() loop 
   up into a new function in p2m.c, and add your put_page[_and_type] 
   calls in there. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcCf-0006K4-Tu; Tue, 24 Apr 2012 09:38:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SMcCe-0006Jw-DP
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:38:32 +0000
Received: from [193.109.254.147:26641] by server-11.bemta-14.messagelabs.com
	id 8D/1F-05858-794769F4; Tue, 24 Apr 2012 09:38:31 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335260311!6066020!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gNDA4NTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 493 invoked from network); 24 Apr 2012 09:38:31 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195) by server-3.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 09:38:31 -0000
X-Originating-IP: 217.70.178.146
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id A5A86A810D;
	Tue, 24 Apr 2012 11:38:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 0XEJzEFsNF0j; Tue, 24 Apr 2012 11:38:29 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C5EC3A809F;
	Tue, 24 Apr 2012 11:38:28 +0200 (CEST)
Message-ID: <4F967494.8070009@de-bruyn.fr>
Date: Tue, 24 Apr 2012 11:38:28 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Cc: rshriram@cs.ubc.ca
Subject: [Xen-devel] xen-tools ioemu-remote missing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Everybody,

I am trying to install Xen / Remus with the remusha wiki, but after a
make tools, the tools/ioemu-remote directory is missing. I have tried
several times.

Is that a bug or the directory is no longer existing ? Is this wiki out
of date ?

Thanks for your help.

Regards,

--
Alexis de BRUYN

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcCf-0006K4-Tu; Tue, 24 Apr 2012 09:38:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SMcCe-0006Jw-DP
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 09:38:32 +0000
Received: from [193.109.254.147:26641] by server-11.bemta-14.messagelabs.com
	id 8D/1F-05858-794769F4; Tue, 24 Apr 2012 09:38:31 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335260311!6066020!1
X-Originating-IP: [217.70.183.195]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTUgPT4gNDA4NTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 493 invoked from network); 24 Apr 2012 09:38:31 -0000
Received: from relay3-d.mail.gandi.net (HELO relay3-d.mail.gandi.net)
	(217.70.183.195) by server-3.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 09:38:31 -0000
X-Originating-IP: 217.70.178.146
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id A5A86A810D;
	Tue, 24 Apr 2012 11:38:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 0XEJzEFsNF0j; Tue, 24 Apr 2012 11:38:29 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C5EC3A809F;
	Tue, 24 Apr 2012 11:38:28 +0200 (CEST)
Message-ID: <4F967494.8070009@de-bruyn.fr>
Date: Tue, 24 Apr 2012 11:38:28 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Cc: rshriram@cs.ubc.ca
Subject: [Xen-devel] xen-tools ioemu-remote missing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Everybody,

I am trying to install Xen / Remus with the remusha wiki, but after a
make tools, the tools/ioemu-remote directory is missing. I have tried
several times.

Is that a bug or the directory is no longer existing ? Is this wiki out
of date ?

Thanks for your help.

Regards,

--
Alexis de BRUYN

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:53:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcRH-0006Zj-GZ; Tue, 24 Apr 2012 09:53:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMcRG-0006Ze-Fn
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:53:38 +0000
Received: from [85.158.138.51:63403] by server-5.bemta-3.messagelabs.com id
	E7/E4-17113-128769F4; Tue, 24 Apr 2012 09:53:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335261216!23479831!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30297 invoked from network); 24 Apr 2012 09:53:36 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:53:36 -0000
Received: by eeit10 with SMTP id t10so120958eei.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 02:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=mdpLo7f71QNsvFvI5BYwvgfRB8rEdBj8Y7RmbEEW/2g=;
	b=LU7P26d0yH0hDDUkRnSRWHMxcO7vRLNidRI65Eeg2Va7WMhnenomsK20CkSndGGLbS
	JIq8VcMvGQYG4oYcLiJ5uUBfxL9vDefUgd3xiK8PnZD+shFic/QI4t3Mw17ec3RbZD7k
	ll06r/ivu4kOD5dmzwOxE8cq4lKQUAkC5mZoumceGOOqId9VE3GJNYQE3HOvl8adwA5B
	XeQMZaJPKBJkDwTnE2pQ5Za28BeoGog0tqPB+Oj1mNWNRmBdB5pHeaGk7qLdnsGslV9z
	8exydcQyX1e1CAkmxYWG/4XwB4QsTioeGQRGIUsx/GBk3zdf8vNu/xJUr6TkJws6lJAQ
	3STg==
Received: by 10.14.188.141 with SMTP id a13mr3052599een.56.1335261216359;
	Tue, 24 Apr 2012 02:53:36 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id d54sm85023602eei.9.2012.04.24.02.53.35
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 02:53:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 24 Apr 2012 10:53:33 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CBBC36AD.3EAA0%keir@xen.org>
Thread-Topic: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
Thread-Index: Ac0iABwT22XVyMkXO0i5CiXPianlNw==
In-Reply-To: <4F968C41020000780007F86C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/2012 10:19, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> The time has come for another round of stable releases.
>> 
>> Please send (or resend) any outstanding backport requests for 4.0.4 and
>> 4.1.3 before Friday 20 April.
> 
> As there were no -rc1's so far anyway, I'd like to additionally propose
> the first hunk of 25168:d5f9005dfc4a for 4.1.

I've now done this.

> Further candidates, though more involved in terms of what
> they change, appear to be 25191:a95fc7decc83,
> 25195:a06e6cdeafe3, and 25196:375fa55c7a6c.

Maybe. They're quite big though.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 09:53:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 09:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcRH-0006Zj-GZ; Tue, 24 Apr 2012 09:53:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMcRG-0006Ze-Fn
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 09:53:38 +0000
Received: from [85.158.138.51:63403] by server-5.bemta-3.messagelabs.com id
	E7/E4-17113-128769F4; Tue, 24 Apr 2012 09:53:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335261216!23479831!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30297 invoked from network); 24 Apr 2012 09:53:36 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 09:53:36 -0000
Received: by eeit10 with SMTP id t10so120958eei.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 02:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=mdpLo7f71QNsvFvI5BYwvgfRB8rEdBj8Y7RmbEEW/2g=;
	b=LU7P26d0yH0hDDUkRnSRWHMxcO7vRLNidRI65Eeg2Va7WMhnenomsK20CkSndGGLbS
	JIq8VcMvGQYG4oYcLiJ5uUBfxL9vDefUgd3xiK8PnZD+shFic/QI4t3Mw17ec3RbZD7k
	ll06r/ivu4kOD5dmzwOxE8cq4lKQUAkC5mZoumceGOOqId9VE3GJNYQE3HOvl8adwA5B
	XeQMZaJPKBJkDwTnE2pQ5Za28BeoGog0tqPB+Oj1mNWNRmBdB5pHeaGk7qLdnsGslV9z
	8exydcQyX1e1CAkmxYWG/4XwB4QsTioeGQRGIUsx/GBk3zdf8vNu/xJUr6TkJws6lJAQ
	3STg==
Received: by 10.14.188.141 with SMTP id a13mr3052599een.56.1335261216359;
	Tue, 24 Apr 2012 02:53:36 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id d54sm85023602eei.9.2012.04.24.02.53.35
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 02:53:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 24 Apr 2012 10:53:33 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CBBC36AD.3EAA0%keir@xen.org>
Thread-Topic: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
Thread-Index: Ac0iABwT22XVyMkXO0i5CiXPianlNw==
In-Reply-To: <4F968C41020000780007F86C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/2012 10:19, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> The time has come for another round of stable releases.
>> 
>> Please send (or resend) any outstanding backport requests for 4.0.4 and
>> 4.1.3 before Friday 20 April.
> 
> As there were no -rc1's so far anyway, I'd like to additionally propose
> the first hunk of 25168:d5f9005dfc4a for 4.1.

I've now done this.

> Further candidates, though more involved in terms of what
> they change, appear to be 25191:a95fc7decc83,
> 25195:a06e6cdeafe3, and 25196:375fa55c7a6c.

Maybe. They're quite big though.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:01:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcYZ-0006mu-E7; Tue, 24 Apr 2012 10:01:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SMcYX-0006mp-Dr
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:01:09 +0000
Received: from [85.158.139.83:54030] by server-2.bemta-5.messagelabs.com id
	B5/93-17016-4E9769F4; Tue, 24 Apr 2012 10:01:08 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335261666!22508277!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIwNzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1680 invoked from network); 24 Apr 2012 10:01:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 10:01:07 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3O9xREj003373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 05:59:27 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3O9xNXe014262; Tue, 24 Apr 2012 05:59:24 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 3C4B518D495; Tue, 24 Apr 2012 12:59:23 +0300 (IDT)
Date: Tue, 24 Apr 2012 12:59:23 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120424095923.GS15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> 
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
> index e35b3a8..3252339 100644
> --- a/arch/ia64/include/asm/kvm_host.h
> +++ b/arch/ia64/include/asm/kvm_host.h
> @@ -597,6 +597,9 @@ void kvm_sal_emul(struct kvm_vcpu *vcpu);
>  struct kvm *kvm_arch_alloc_vm(void);
>  void kvm_arch_free_vm(struct kvm *kvm);
>  
> +static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +}
>  #endif /* __ASSEMBLY__*/
>  
>  #endif
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 52eb9c1..28446de 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -498,4 +498,8 @@ struct kvm_vcpu_arch {
>  #define KVM_MMIO_REG_QPR	0x0040
>  #define KVM_MMIO_REG_FQPR	0x0060
>  
> +static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +}
> +
>  #endif /* __POWERPC_KVM_HOST_H__ */
> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
> index 7343872..c47f874 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -256,4 +256,8 @@ struct kvm_arch{
>  };
>  
>  extern int sie64a(struct kvm_s390_sie_block *, u64 *);
> +static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +}
> +
>  #endif
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index e216ba0..dad475b 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
>  		u64 length;
>  		u64 status;
>  	} osvw;
> +	/* pv related host specific info */
> +	struct {
> +		int pv_unhalted;
> +	} pv;
>  };
>  
>  struct kvm_lpage_info {
> @@ -967,4 +971,6 @@ int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
>  void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
>  void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
>  
> +void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu);
> +
>  #endif /* _ASM_X86_KVM_HOST_H */
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..5b647ea 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
>  #define KVM_FEATURE_CLOCKSOURCE		0
>  #define KVM_FEATURE_NOP_IO_DELAY	1
>  #define KVM_FEATURE_MMU_OP		2
> +
>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_PV_UNHALT		6
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 9fed5be..7c93806 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
>  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
>  			     (1 << KVM_FEATURE_ASYNC_PF) |
> -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> +			     (1 << KVM_FEATURE_PV_UNHALT);
>  
>  		if (sched_info_on())
>  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 4044ce0..7fc9be6 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
>  	case KVM_CAP_PCI_2_3:
> +	case KVM_CAP_PV_UNHALT:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:
> @@ -4993,6 +4994,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>  	return 1;
>  }
>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		/*
> +		 * Setting unhalt flag here can result in spurious runnable
> +		 * state when unhalt reset does not happen in vcpu_block.
> +		 * But that is harmless since that should soon result in halt.
> +		 */
> +		vcpu->arch.pv.pv_unhalted = 1;
> +		/* We need everybody see unhalt before vcpu unblocks */
> +		smp_mb();
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
can use one of reserved delivery modes as PV delivery mode. We will
disallow guest to trigger it through apic interface, so this will not be
part of ABI and can be changed at will.

> +
>  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  {
>  	unsigned long nr, a0, a1, a2, a3, ret;
> @@ -5026,6 +5057,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  	case KVM_HC_VAPIC_POLL_IRQ:
>  		ret = 0;
>  		break;
> +	case KVM_HC_KICK_CPU:
> +		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
> +		ret = 0;
> +		break;
>  	default:
>  		ret = -KVM_ENOSYS;
>  		break;
> @@ -6128,6 +6163,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
>  	BUG_ON(vcpu->kvm == NULL);
>  	kvm = vcpu->kvm;
>  
> +	kvm_arch_vcpu_reset_pv_unhalted(vcpu);
>  	vcpu->arch.emulate_ctxt.ops = &emulate_ops;
>  	if (!irqchip_in_kernel(kvm) || kvm_vcpu_is_bsp(vcpu))
>  		vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
> @@ -6398,11 +6434,17 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>  		!vcpu->arch.apf.halted)
>  		|| !list_empty_careful(&vcpu->async_pf.done)
>  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| vcpu->arch.pv.pv_unhalted
>  		|| atomic_read(&vcpu->arch.nmi_queued) ||
>  		(kvm_arch_interrupt_allowed(vcpu) &&
>  		 kvm_cpu_has_interrupt(vcpu));
>  }
>  
> +void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +	vcpu->arch.pv.pv_unhalted = 0;
> +}
> +
>  void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
>  {
>  	int me;
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index 6c322a9..a189f02 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -589,6 +589,7 @@ struct kvm_ppc_pvinfo {
>  #define KVM_CAP_S390_UCONTROL 73
>  #define KVM_CAP_SYNC_REGS 74
>  #define KVM_CAP_PCI_2_3 75
> +#define KVM_CAP_PV_UNHALT 76
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> index ff476dd..38226e1 100644
> --- a/include/linux/kvm_para.h
> +++ b/include/linux/kvm_para.h
> @@ -19,6 +19,7 @@
>  #define KVM_HC_MMU_OP			2
>  #define KVM_HC_FEATURES			3
>  #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
> +#define KVM_HC_KICK_CPU			5
>  
>  /*
>   * hypercalls use architecture specific
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 42b7393..edf56d4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>  
>  		if (kvm_arch_vcpu_runnable(vcpu)) {
> +			/*
> +			 * This is the only safe place to reset unhalt flag.
> +			 * otherwise it results in loosing the notification
> +			 * which eventually can result in vcpu hangs.
> +			 */
Why this is the only safe place? Why clearing it in kvm/x86.c just after
call to kvm_vcpu_block() if KVM_REQ_UNHALT is set is not safe enough?

> +			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
> +			/* preventing reordering should be enough here */
> +			barrier();
>  			kvm_make_request(KVM_REQ_UNHALT, vcpu);
>  			break;
>  		}

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:01:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcYZ-0006mu-E7; Tue, 24 Apr 2012 10:01:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SMcYX-0006mp-Dr
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:01:09 +0000
Received: from [85.158.139.83:54030] by server-2.bemta-5.messagelabs.com id
	B5/93-17016-4E9769F4; Tue, 24 Apr 2012 10:01:08 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335261666!22508277!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIwNzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1680 invoked from network); 24 Apr 2012 10:01:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 10:01:07 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3O9xREj003373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 05:59:27 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3O9xNXe014262; Tue, 24 Apr 2012 05:59:24 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 3C4B518D495; Tue, 24 Apr 2012 12:59:23 +0300 (IDT)
Date: Tue, 24 Apr 2012 12:59:23 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120424095923.GS15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> 
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
> index e35b3a8..3252339 100644
> --- a/arch/ia64/include/asm/kvm_host.h
> +++ b/arch/ia64/include/asm/kvm_host.h
> @@ -597,6 +597,9 @@ void kvm_sal_emul(struct kvm_vcpu *vcpu);
>  struct kvm *kvm_arch_alloc_vm(void);
>  void kvm_arch_free_vm(struct kvm *kvm);
>  
> +static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +}
>  #endif /* __ASSEMBLY__*/
>  
>  #endif
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 52eb9c1..28446de 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -498,4 +498,8 @@ struct kvm_vcpu_arch {
>  #define KVM_MMIO_REG_QPR	0x0040
>  #define KVM_MMIO_REG_FQPR	0x0060
>  
> +static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +}
> +
>  #endif /* __POWERPC_KVM_HOST_H__ */
> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
> index 7343872..c47f874 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -256,4 +256,8 @@ struct kvm_arch{
>  };
>  
>  extern int sie64a(struct kvm_s390_sie_block *, u64 *);
> +static inline void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +}
> +
>  #endif
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index e216ba0..dad475b 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
>  		u64 length;
>  		u64 status;
>  	} osvw;
> +	/* pv related host specific info */
> +	struct {
> +		int pv_unhalted;
> +	} pv;
>  };
>  
>  struct kvm_lpage_info {
> @@ -967,4 +971,6 @@ int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
>  void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
>  void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
>  
> +void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu);
> +
>  #endif /* _ASM_X86_KVM_HOST_H */
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..5b647ea 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
>  #define KVM_FEATURE_CLOCKSOURCE		0
>  #define KVM_FEATURE_NOP_IO_DELAY	1
>  #define KVM_FEATURE_MMU_OP		2
> +
>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_PV_UNHALT		6
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 9fed5be..7c93806 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -408,7 +408,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
>  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
>  			     (1 << KVM_FEATURE_ASYNC_PF) |
> -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> +			     (1 << KVM_FEATURE_PV_UNHALT);
>  
>  		if (sched_info_on())
>  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 4044ce0..7fc9be6 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
>  	case KVM_CAP_PCI_2_3:
> +	case KVM_CAP_PV_UNHALT:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:
> @@ -4993,6 +4994,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>  	return 1;
>  }
>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		/*
> +		 * Setting unhalt flag here can result in spurious runnable
> +		 * state when unhalt reset does not happen in vcpu_block.
> +		 * But that is harmless since that should soon result in halt.
> +		 */
> +		vcpu->arch.pv.pv_unhalted = 1;
> +		/* We need everybody see unhalt before vcpu unblocks */
> +		smp_mb();
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
can use one of reserved delivery modes as PV delivery mode. We will
disallow guest to trigger it through apic interface, so this will not be
part of ABI and can be changed at will.

> +
>  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  {
>  	unsigned long nr, a0, a1, a2, a3, ret;
> @@ -5026,6 +5057,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>  	case KVM_HC_VAPIC_POLL_IRQ:
>  		ret = 0;
>  		break;
> +	case KVM_HC_KICK_CPU:
> +		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
> +		ret = 0;
> +		break;
>  	default:
>  		ret = -KVM_ENOSYS;
>  		break;
> @@ -6128,6 +6163,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
>  	BUG_ON(vcpu->kvm == NULL);
>  	kvm = vcpu->kvm;
>  
> +	kvm_arch_vcpu_reset_pv_unhalted(vcpu);
>  	vcpu->arch.emulate_ctxt.ops = &emulate_ops;
>  	if (!irqchip_in_kernel(kvm) || kvm_vcpu_is_bsp(vcpu))
>  		vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
> @@ -6398,11 +6434,17 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>  		!vcpu->arch.apf.halted)
>  		|| !list_empty_careful(&vcpu->async_pf.done)
>  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| vcpu->arch.pv.pv_unhalted
>  		|| atomic_read(&vcpu->arch.nmi_queued) ||
>  		(kvm_arch_interrupt_allowed(vcpu) &&
>  		 kvm_cpu_has_interrupt(vcpu));
>  }
>  
> +void kvm_arch_vcpu_reset_pv_unhalted(struct kvm_vcpu *vcpu)
> +{
> +	vcpu->arch.pv.pv_unhalted = 0;
> +}
> +
>  void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
>  {
>  	int me;
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index 6c322a9..a189f02 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -589,6 +589,7 @@ struct kvm_ppc_pvinfo {
>  #define KVM_CAP_S390_UCONTROL 73
>  #define KVM_CAP_SYNC_REGS 74
>  #define KVM_CAP_PCI_2_3 75
> +#define KVM_CAP_PV_UNHALT 76
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> index ff476dd..38226e1 100644
> --- a/include/linux/kvm_para.h
> +++ b/include/linux/kvm_para.h
> @@ -19,6 +19,7 @@
>  #define KVM_HC_MMU_OP			2
>  #define KVM_HC_FEATURES			3
>  #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
> +#define KVM_HC_KICK_CPU			5
>  
>  /*
>   * hypercalls use architecture specific
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 42b7393..edf56d4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>  
>  		if (kvm_arch_vcpu_runnable(vcpu)) {
> +			/*
> +			 * This is the only safe place to reset unhalt flag.
> +			 * otherwise it results in loosing the notification
> +			 * which eventually can result in vcpu hangs.
> +			 */
Why this is the only safe place? Why clearing it in kvm/x86.c just after
call to kvm_vcpu_block() if KVM_REQ_UNHALT is set is not safe enough?

> +			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
> +			/* preventing reordering should be enough here */
> +			barrier();
>  			kvm_make_request(KVM_REQ_UNHALT, vcpu);
>  			break;
>  		}

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcZb-0006rF-4l; Tue, 24 Apr 2012 10:02:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SMcZZ-0006r6-6n
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:02:13 +0000
Received: from [193.109.254.147:8074] by server-7.bemta-14.messagelabs.com id
	BA/75-01627-42A769F4; Tue, 24 Apr 2012 10:02:12 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335261730!6041061!1
X-Originating-IP: [98.138.90.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9038 invoked from network); 24 Apr 2012 10:02:11 -0000
Received: from nm25.bullet.mail.ne1.yahoo.com (HELO
	nm25.bullet.mail.ne1.yahoo.com) (98.138.90.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 10:02:11 -0000
Received: from [98.138.90.55] by nm25.bullet.mail.ne1.yahoo.com with NNFMP;
	24 Apr 2012 10:02:10 -0000
Received: from [98.138.89.171] by tm8.bullet.mail.ne1.yahoo.com with NNFMP;
	24 Apr 2012 10:02:10 -0000
Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP;
	24 Apr 2012 10:02:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 335992.516.bm@omp1027.mail.ne1.yahoo.com
Received: (qmail 16480 invoked by uid 60001); 24 Apr 2012 10:02:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1335261730; bh=9WLnZ8sJxkLPiX35QmrfFose8YbMQ7rFyMqRiAEg+MM=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=CgmM+f+mRkBa/x0+WtYedu5kkkY3y5ThYcBIflnkaFLIJhKXX7QFh0uWJdlouQhkRQZPL4AIqxfcMoj7T2/rBSCx/9hs+CQkYxW25wJuYn3CKhWm/ntuhVSOVSIWhgPMWeVYTKFsVJs1OamNbmR30HqbKzFG/Bkbdrgy1+QVM5k=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=wNtfP3hJ13pUo50LpLozwHIz63G99HNq6opeBG84evVKWR/84gSOItWSDPcPT7cgvwvrXfvWTOv2l5MTeBuILUPYPTe5z/VqMLOFzqcuyoL/cLN7qLiak2+XcE2pvmTSZ7/RMlYFIdoLHlzo+ddnSWqUYoLNGuzRQ7iF+I3yh3o=;
X-YMail-OSG: .e9CW8YVM1lMoRLrvpThL8VNhGorKe9O3PabZJjAeA.Afis
	ZknLmF4kYD_Kn0ec2bk8oYNegaH7vnQwlLHglf_ZLrfhO.wjL9RsAzcm.n9w
	p2uNWfVQZEu2L7aqcRpLLYS3AheG9WAsIIL.yb9H9ZrWJciKgg5pCki_p6nH
	OSbwbuCtuhnGUm5oc9G1p9QsA3oT2JLrveX7DaM7s0dmTFjpSUrNsJfSXm6r
	dAD9kDtPVQKVfatO1hjofCGSESGxOZZ1mCYHXjSEMx1fULUn0RKtlZvuTKo0
	2wQKruqJGHIauWym3R3yle_SUtEJJawPasrNS6zX.wm8662z1L0yfQTTnDU3
	l1gozkyQ49hPkes3C03z1sk.N7Kqq0bD5COot9WonzjFKhA.ydt3gBrxffSh
	rI_V1Q3ClulBRsX9v86Q5UG14vuhJold0ORhJgMc0OORmA6S4mVVwUfQuh8s
	XwXkrmhYgbpxA0UdweE.J2jTI7toMUQ--
Received: from [98.249.4.104] by web124502.mail.ne1.yahoo.com via HTTP;
	Tue, 24 Apr 2012 03:02:10 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
	<4F967928020000780007F84A@nat28.tlf.novell.com>
Message-ID: <1335261730.11784.YahooMailNeo@web124502.mail.ne1.yahoo.com>
Date: Tue, 24 Apr 2012 03:02:10 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <4F967928020000780007F84A@nat28.tlf.novell.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Question about grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ok. Can you tell what 'clear_pte' for gnttab_unmap_refs exactly do?

Ruslan.



----- Original Message -----
From: Jan Beulich <JBeulich@suse.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Sent: Tuesday, April 24, 2012 3:58 AM
Subject: Re: [Xen-devel] Question about grant table

>>> On 23.04.12 at 23:13, Ruslan Nikolaev <nruslan_devel@yahoo.com> wrote:
> Hi
> =

> I have a question regarding a grant table. I have a case when I have some =

> shared (between domains) pages mapped to the user space. I created a spec=
ial =

> driver which implements mmap(). That, in turns, will execute =

> gnttab_map_refs(). This all works fine until I want to do something like =

> exec().
> =

> After I do exec(), I want to mmap() the *same* pages (i.e. using the same =

> grant references) to some new user address space which is chosen by mmap(=
). =

> During exec(), it will invalidate user address space, and=A0 release() fr=
om =

> mmu_notifier will be called. This means, that my driver will execute =

> gnttab_unmap_refs. After exec() succeeded, I invoke mmap() again which wi=
ll =

> do gnttab_map_refs().
> =

> At this point I get kernel errors like this:
> [=A0 198.939095] BUG: Bad page map in process a.out=A0 pte:80000002457f11=
67 =

> pmd:245094067
> [=A0 198.939099] page:ffffea000915fc40 count:1 mapcount:-1 mapping:=A0 =
=A0 =A0 =A0 =A0 =

> (null) index:0xffff8802d958f720
> [=A0 198.939102] page flags: 0x8000000000000814(referenced|dirty|private)
> [=A0 198.939109] addr:00007fd302f40000 vm_flags:000e00fb anon_vma:=A0 =A0=
 =A0 =A0 =A0 =

> (null) mapping:ffff8802d782f760 index:0
> [=A0 198.939124] vma->vm_ops->fault: 0x0
> [=A0 198.939128] vma->vm_file->f_op->mmap: syscall_driver_mmap+0x0/0xc9 =

> [syscall_driver]

This I cannot spot in the upstream kernel (and you also didn't indicate
that you use something different), so I think you need to start
investigation at that end.

Jan

> So, I have two questions in this regard:
> 1. Does gnttab_unmap_refs removes grant references, so that I cannot use =

> them any longer? What would be proper way to preserve grant references bu=
t at =

> the same time unmap from the current user address space shared pages?
> =

> 2. What happens to the counters like count, mapcount when I do =

> gnttab_map_refs() and gnntab_unmap_refs()?
> =

> Thanks,
> Ruslan
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org =

> http://lists.xen.org/xen-devel =





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcZb-0006rF-4l; Tue, 24 Apr 2012 10:02:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nruslan_devel@yahoo.com>) id 1SMcZZ-0006r6-6n
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:02:13 +0000
Received: from [193.109.254.147:8074] by server-7.bemta-14.messagelabs.com id
	BA/75-01627-42A769F4; Tue, 24 Apr 2012 10:02:12 +0000
X-Env-Sender: nruslan_devel@yahoo.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335261730!6041061!1
X-Originating-IP: [98.138.90.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9038 invoked from network); 24 Apr 2012 10:02:11 -0000
Received: from nm25.bullet.mail.ne1.yahoo.com (HELO
	nm25.bullet.mail.ne1.yahoo.com) (98.138.90.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 10:02:11 -0000
Received: from [98.138.90.55] by nm25.bullet.mail.ne1.yahoo.com with NNFMP;
	24 Apr 2012 10:02:10 -0000
Received: from [98.138.89.171] by tm8.bullet.mail.ne1.yahoo.com with NNFMP;
	24 Apr 2012 10:02:10 -0000
Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP;
	24 Apr 2012 10:02:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 335992.516.bm@omp1027.mail.ne1.yahoo.com
Received: (qmail 16480 invoked by uid 60001); 24 Apr 2012 10:02:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1335261730; bh=9WLnZ8sJxkLPiX35QmrfFose8YbMQ7rFyMqRiAEg+MM=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=CgmM+f+mRkBa/x0+WtYedu5kkkY3y5ThYcBIflnkaFLIJhKXX7QFh0uWJdlouQhkRQZPL4AIqxfcMoj7T2/rBSCx/9hs+CQkYxW25wJuYn3CKhWm/ntuhVSOVSIWhgPMWeVYTKFsVJs1OamNbmR30HqbKzFG/Bkbdrgy1+QVM5k=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=wNtfP3hJ13pUo50LpLozwHIz63G99HNq6opeBG84evVKWR/84gSOItWSDPcPT7cgvwvrXfvWTOv2l5MTeBuILUPYPTe5z/VqMLOFzqcuyoL/cLN7qLiak2+XcE2pvmTSZ7/RMlYFIdoLHlzo+ddnSWqUYoLNGuzRQ7iF+I3yh3o=;
X-YMail-OSG: .e9CW8YVM1lMoRLrvpThL8VNhGorKe9O3PabZJjAeA.Afis
	ZknLmF4kYD_Kn0ec2bk8oYNegaH7vnQwlLHglf_ZLrfhO.wjL9RsAzcm.n9w
	p2uNWfVQZEu2L7aqcRpLLYS3AheG9WAsIIL.yb9H9ZrWJciKgg5pCki_p6nH
	OSbwbuCtuhnGUm5oc9G1p9QsA3oT2JLrveX7DaM7s0dmTFjpSUrNsJfSXm6r
	dAD9kDtPVQKVfatO1hjofCGSESGxOZZ1mCYHXjSEMx1fULUn0RKtlZvuTKo0
	2wQKruqJGHIauWym3R3yle_SUtEJJawPasrNS6zX.wm8662z1L0yfQTTnDU3
	l1gozkyQ49hPkes3C03z1sk.N7Kqq0bD5COot9WonzjFKhA.ydt3gBrxffSh
	rI_V1Q3ClulBRsX9v86Q5UG14vuhJold0ORhJgMc0OORmA6S4mVVwUfQuh8s
	XwXkrmhYgbpxA0UdweE.J2jTI7toMUQ--
Received: from [98.249.4.104] by web124502.mail.ne1.yahoo.com via HTTP;
	Tue, 24 Apr 2012 03:02:10 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <1335215633.81955.YahooMailNeo@web124503.mail.ne1.yahoo.com>
	<4F967928020000780007F84A@nat28.tlf.novell.com>
Message-ID: <1335261730.11784.YahooMailNeo@web124502.mail.ne1.yahoo.com>
Date: Tue, 24 Apr 2012 03:02:10 -0700 (PDT)
From: Ruslan Nikolaev <nruslan_devel@yahoo.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <4F967928020000780007F84A@nat28.tlf.novell.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Question about grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ok. Can you tell what 'clear_pte' for gnttab_unmap_refs exactly do?

Ruslan.



----- Original Message -----
From: Jan Beulich <JBeulich@suse.com>
To: Ruslan Nikolaev <nruslan_devel@yahoo.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Sent: Tuesday, April 24, 2012 3:58 AM
Subject: Re: [Xen-devel] Question about grant table

>>> On 23.04.12 at 23:13, Ruslan Nikolaev <nruslan_devel@yahoo.com> wrote:
> Hi
> =

> I have a question regarding a grant table. I have a case when I have some =

> shared (between domains) pages mapped to the user space. I created a spec=
ial =

> driver which implements mmap(). That, in turns, will execute =

> gnttab_map_refs(). This all works fine until I want to do something like =

> exec().
> =

> After I do exec(), I want to mmap() the *same* pages (i.e. using the same =

> grant references) to some new user address space which is chosen by mmap(=
). =

> During exec(), it will invalidate user address space, and=A0 release() fr=
om =

> mmu_notifier will be called. This means, that my driver will execute =

> gnttab_unmap_refs. After exec() succeeded, I invoke mmap() again which wi=
ll =

> do gnttab_map_refs().
> =

> At this point I get kernel errors like this:
> [=A0 198.939095] BUG: Bad page map in process a.out=A0 pte:80000002457f11=
67 =

> pmd:245094067
> [=A0 198.939099] page:ffffea000915fc40 count:1 mapcount:-1 mapping:=A0 =
=A0 =A0 =A0 =A0 =

> (null) index:0xffff8802d958f720
> [=A0 198.939102] page flags: 0x8000000000000814(referenced|dirty|private)
> [=A0 198.939109] addr:00007fd302f40000 vm_flags:000e00fb anon_vma:=A0 =A0=
 =A0 =A0 =A0 =

> (null) mapping:ffff8802d782f760 index:0
> [=A0 198.939124] vma->vm_ops->fault: 0x0
> [=A0 198.939128] vma->vm_file->f_op->mmap: syscall_driver_mmap+0x0/0xc9 =

> [syscall_driver]

This I cannot spot in the upstream kernel (and you also didn't indicate
that you use something different), so I think you need to start
investigation at that end.

Jan

> So, I have two questions in this regard:
> 1. Does gnttab_unmap_refs removes grant references, so that I cannot use =

> them any longer? What would be proper way to preserve grant references bu=
t at =

> the same time unmap from the current user address space shared pages?
> =

> 2. What happens to the counters like count, mapcount when I do =

> gnttab_map_refs() and gnntab_unmap_refs()?
> =

> Thanks,
> Ruslan
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org =

> http://lists.xen.org/xen-devel =





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:14:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMckm-00079q-Vo; Tue, 24 Apr 2012 10:13:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMckl-00079f-9c
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:13:47 +0000
Received: from [193.109.254.147:4407] by server-9.bemta-14.messagelabs.com id
	76/E9-05787-ADC769F4; Tue, 24 Apr 2012 10:13:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335262425!3578666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25454 invoked from network); 24 Apr 2012 10:13:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:13:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:13:45 +0100
Message-ID: <1335262424.4347.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
Date: Tue, 24 Apr 2012 11:13:44 +0100
In-Reply-To: <4F967494.8070009@de-bruyn.fr>
References: <4F967494.8070009@de-bruyn.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-tools ioemu-remote missing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 10:38 +0100, Alexis de BRUYN [Mailinglists] wrote:
> Hi Everybody,
> 
> I am trying to install Xen / Remus with the remusha wiki, but after a
> make tools, the tools/ioemu-remote directory is missing. I have tried
> several times.

This is now called qemu-xen-traditional-dir-remote.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:14:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMckm-00079q-Vo; Tue, 24 Apr 2012 10:13:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMckl-00079f-9c
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:13:47 +0000
Received: from [193.109.254.147:4407] by server-9.bemta-14.messagelabs.com id
	76/E9-05787-ADC769F4; Tue, 24 Apr 2012 10:13:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335262425!3578666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25454 invoked from network); 24 Apr 2012 10:13:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:13:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:13:45 +0100
Message-ID: <1335262424.4347.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
Date: Tue, 24 Apr 2012 11:13:44 +0100
In-Reply-To: <4F967494.8070009@de-bruyn.fr>
References: <4F967494.8070009@de-bruyn.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-tools ioemu-remote missing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 10:38 +0100, Alexis de BRUYN [Mailinglists] wrote:
> Hi Everybody,
> 
> I am trying to install Xen / Remus with the remusha wiki, but after a
> make tools, the tools/ioemu-remote directory is missing. I have tried
> several times.

This is now called qemu-xen-traditional-dir-remote.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:15:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcmc-0007JV-Il; Tue, 24 Apr 2012 10:15:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMcmb-0007JJ-6C
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:15:41 +0000
Received: from [85.158.139.83:13664] by server-10.bemta-5.messagelabs.com id
	84/1D-08260-C4D769F4; Tue, 24 Apr 2012 10:15:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335262539!21281540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 788 invoked from network); 24 Apr 2012 10:15:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:15:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:15:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMch0-0003QR-NE; Tue, 24 Apr 2012 10:09:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMch0-0006iK-JW;
	Tue, 24 Apr 2012 11:09:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.31730.484142.339795@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 11:09:54 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335258998.4347.59.camel@zakaz.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> I think it is important in the context of this patch to be clear about
> what is the desired long term behaviour compared with the short term
> behaviour being implemented for 4.2 is. We should also be clear about
> what is being done now in order to address xl regressions vs xend. We
> should also be clear about what is just papering over an issue for 4.2
> vs what the proper fix in 4.3 will be. We also need to know what is
> actually new functionality or behaviour (i.e. not fixing an xl vs xend
> regression). IOW we need to have clear descriptions of the reasons for
> the changes not just what the changes.

Yes.

> I think all the above need to be written down explicitly in either the
> commit message or the introductory email, otherwise the review of this
> series is just going to continue to go round in circles -- the reasoning
> behind these changes is just too complex for a reviewer (even one who is
> familiar with all this stuff already) to hold in their head.

Quite...

> > Also: this xenstore path should be a relative path, ie one relative to
> > the xenstore home of domain running this part of the tools.  That way
> > the scripts can be easily and automatically disabled for dom0 and
> > enabled in driver domains.
> 
> XENBUS_PATH contains elements for both the back- and frontend domains as
> well as the specific device.
> 
> Or do you think the key should be global per-(backend-domain rather than
> per-device?

The latter.

> > These names are rather too generic, I think.
> 
> enums should also be declared in lixl_types_internal.idl

Surely an enum which doesn't escape from inside libxl and which never
needs to be printed can just be an enum ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:15:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcmc-0007JV-Il; Tue, 24 Apr 2012 10:15:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMcmb-0007JJ-6C
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:15:41 +0000
Received: from [85.158.139.83:13664] by server-10.bemta-5.messagelabs.com id
	84/1D-08260-C4D769F4; Tue, 24 Apr 2012 10:15:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335262539!21281540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 788 invoked from network); 24 Apr 2012 10:15:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:15:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:15:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMch0-0003QR-NE; Tue, 24 Apr 2012 10:09:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMch0-0006iK-JW;
	Tue, 24 Apr 2012 11:09:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.31730.484142.339795@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 11:09:54 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335258998.4347.59.camel@zakaz.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> I think it is important in the context of this patch to be clear about
> what is the desired long term behaviour compared with the short term
> behaviour being implemented for 4.2 is. We should also be clear about
> what is being done now in order to address xl regressions vs xend. We
> should also be clear about what is just papering over an issue for 4.2
> vs what the proper fix in 4.3 will be. We also need to know what is
> actually new functionality or behaviour (i.e. not fixing an xl vs xend
> regression). IOW we need to have clear descriptions of the reasons for
> the changes not just what the changes.

Yes.

> I think all the above need to be written down explicitly in either the
> commit message or the introductory email, otherwise the review of this
> series is just going to continue to go round in circles -- the reasoning
> behind these changes is just too complex for a reviewer (even one who is
> familiar with all this stuff already) to hold in their head.

Quite...

> > Also: this xenstore path should be a relative path, ie one relative to
> > the xenstore home of domain running this part of the tools.  That way
> > the scripts can be easily and automatically disabled for dom0 and
> > enabled in driver domains.
> 
> XENBUS_PATH contains elements for both the back- and frontend domains as
> well as the specific device.
> 
> Or do you think the key should be global per-(backend-domain rather than
> per-device?

The latter.

> > These names are rather too generic, I think.
> 
> enums should also be declared in lixl_types_internal.idl

Surely an enum which doesn't escape from inside libxl and which never
needs to be printed can just be an enum ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:17:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMco7-0007UO-39; Tue, 24 Apr 2012 10:17:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMco5-0007U4-VF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:17:14 +0000
Received: from [85.158.143.99:24798] by server-3.bemta-4.messagelabs.com id
	CB/C8-05853-9AD769F4; Tue, 24 Apr 2012 10:17:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335262632!26446233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23172 invoked from network); 24 Apr 2012 10:17:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:17:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:17:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:17:11 +0100
Message-ID: <1335262630.4347.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 11:17:10 +0100
In-Reply-To: <20374.31730.484142.339795@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:09 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):

> > > Also: this xenstore path should be a relative path, ie one relative to
> > > the xenstore home of domain running this part of the tools.  That way
> > > the scripts can be easily and automatically disabled for dom0 and
> > > enabled in driver domains.
> > 
> > XENBUS_PATH contains elements for both the back- and frontend domains as
> > well as the specific device.
> > 
> > Or do you think the key should be global per-(backend-domain rather than
> > per-device?
> 
> The latter.

So /libxl/$XENBUS_PATH is ok then?

> > > These names are rather too generic, I think.
> > 
> > enums should also be declared in lixl_types_internal.idl
> 
> Surely an enum which doesn't escape from inside libxl and which never
> needs to be printed can just be an enum ?

Sure.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:17:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMco7-0007UO-39; Tue, 24 Apr 2012 10:17:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMco5-0007U4-VF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:17:14 +0000
Received: from [85.158.143.99:24798] by server-3.bemta-4.messagelabs.com id
	CB/C8-05853-9AD769F4; Tue, 24 Apr 2012 10:17:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335262632!26446233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23172 invoked from network); 24 Apr 2012 10:17:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:17:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:17:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:17:11 +0100
Message-ID: <1335262630.4347.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 11:17:10 +0100
In-Reply-To: <20374.31730.484142.339795@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:09 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):

> > > Also: this xenstore path should be a relative path, ie one relative to
> > > the xenstore home of domain running this part of the tools.  That way
> > > the scripts can be easily and automatically disabled for dom0 and
> > > enabled in driver domains.
> > 
> > XENBUS_PATH contains elements for both the back- and frontend domains as
> > well as the specific device.
> > 
> > Or do you think the key should be global per-(backend-domain rather than
> > per-device?
> 
> The latter.

So /libxl/$XENBUS_PATH is ok then?

> > > These names are rather too generic, I think.
> > 
> > enums should also be declared in lixl_types_internal.idl
> 
> Surely an enum which doesn't escape from inside libxl and which never
> needs to be printed can just be an enum ?

Sure.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:22:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMct4-0007nz-Sy; Tue, 24 Apr 2012 10:22:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMct3-0007ns-Fl
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:22:21 +0000
Received: from [193.109.254.147:6336] by server-6.bemta-14.messagelabs.com id
	FA/72-02047-CDE769F4; Tue, 24 Apr 2012 10:22:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335262939!3577877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4007 invoked from network); 24 Apr 2012 10:22:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:21:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:21:17 +0100
Message-ID: <1335262875.4347.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 24 Apr 2012 11:21:15 +0100
In-Reply-To: <4F9672DD.2080902@tiscali.it>
References: <4F9672DD.2080902@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Cdrom empty not working with new disk configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 10:31 +0100, Fabio Fantoni wrote:
> With new xl disk configuration is not possible set empty cdrom
> 
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> 
> xl create /etc/xen/XP.cfg
> Parsing config file /etc/xen/XP.cfg
> libxl: error: libxl_device.c:197:libxl__device_disk_set_backend: Disk 
> vdev=hdb failed to stat: : No such file or directory
> libxl: error: libxl_dm.c:1045:libxl__destroy_device_model: Couldn't find 
> device model's pid: No such file or directory
> libxl: error: libxl.c:1094:libxl_domain_destroy: 
> libxl__destroy_device_model failed for 8
> 
> Now xl cd-insert/cd-eject are not working
> xl cd-insert is not possible without empty cdrom and cd-eject fail for 
> error on setting of empty cdrom
> 
> xl cd-eject XP hdc
> command line: config parsing error in disk specification: unknown value 
> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
> 
> Tips on how to solve the problem?

I couldn't get this to work either. I'll include this in the bug list
for 4.2.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:22:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMct4-0007nz-Sy; Tue, 24 Apr 2012 10:22:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMct3-0007ns-Fl
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:22:21 +0000
Received: from [193.109.254.147:6336] by server-6.bemta-14.messagelabs.com id
	FA/72-02047-CDE769F4; Tue, 24 Apr 2012 10:22:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335262939!3577877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4007 invoked from network); 24 Apr 2012 10:22:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:21:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:21:17 +0100
Message-ID: <1335262875.4347.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 24 Apr 2012 11:21:15 +0100
In-Reply-To: <4F9672DD.2080902@tiscali.it>
References: <4F9672DD.2080902@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Cdrom empty not working with new disk configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 10:31 +0100, Fabio Fantoni wrote:
> With new xl disk configuration is not possible set empty cdrom
> 
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> 
> xl create /etc/xen/XP.cfg
> Parsing config file /etc/xen/XP.cfg
> libxl: error: libxl_device.c:197:libxl__device_disk_set_backend: Disk 
> vdev=hdb failed to stat: : No such file or directory
> libxl: error: libxl_dm.c:1045:libxl__destroy_device_model: Couldn't find 
> device model's pid: No such file or directory
> libxl: error: libxl.c:1094:libxl_domain_destroy: 
> libxl__destroy_device_model failed for 8
> 
> Now xl cd-insert/cd-eject are not working
> xl cd-insert is not possible without empty cdrom and cd-eject fail for 
> error on setting of empty cdrom
> 
> xl cd-eject XP hdc
> command line: config parsing error in disk specification: unknown value 
> for format: near `hdc:cdrom' in `,hdc:cdrom,r'
> 
> Tips on how to solve the problem?

I couldn't get this to work either. I'll include this in the bug list
for 4.2.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:28:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcyw-0007zg-Mm; Tue, 24 Apr 2012 10:28:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMcyu-0007za-OI
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:28:24 +0000
Received: from [193.109.254.147:32999] by server-9.bemta-14.messagelabs.com id
	4C/98-05787-840869F4; Tue, 24 Apr 2012 10:28:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335263303!3582142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26401 invoked from network); 24 Apr 2012 10:28:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:28:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:27:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:27:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMcy8-0003gH-3A; Tue, 24 Apr 2012 10:27:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMcy8-0006je-2C;
	Tue, 24 Apr 2012 11:27:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.32791.895351.745797@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 11:27:35 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335262630.4347.73.camel@zakaz.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> On Tue, 2012-04-24 at 11:09 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> 
> > > XENBUS_PATH contains elements for both the back- and frontend domains as
> > > well as the specific device.
> > > 
> > > Or do you think the key should be global per-(backend-domain rather than
> > > per-device?
> > 
> > The latter.
> 
> So /libxl/$XENBUS_PATH is ok then?

?

I was suggesting that the key should be global, and XENBUS_PATH
contains too much.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:28:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcyw-0007zg-Mm; Tue, 24 Apr 2012 10:28:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMcyu-0007za-OI
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:28:24 +0000
Received: from [193.109.254.147:32999] by server-9.bemta-14.messagelabs.com id
	4C/98-05787-840869F4; Tue, 24 Apr 2012 10:28:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335263303!3582142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26401 invoked from network); 24 Apr 2012 10:28:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:28:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:27:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:27:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMcy8-0003gH-3A; Tue, 24 Apr 2012 10:27:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMcy8-0006je-2C;
	Tue, 24 Apr 2012 11:27:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.32791.895351.745797@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 11:27:35 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335262630.4347.73.camel@zakaz.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> On Tue, 2012-04-24 at 11:09 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> 
> > > XENBUS_PATH contains elements for both the back- and frontend domains as
> > > well as the specific device.
> > > 
> > > Or do you think the key should be global per-(backend-domain rather than
> > > per-device?
> > 
> > The latter.
> 
> So /libxl/$XENBUS_PATH is ok then?

?

I was suggesting that the key should be global, and XENBUS_PATH
contains too much.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:29:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcza-00082b-47; Tue, 24 Apr 2012 10:29:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMczZ-00082R-2x
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:29:05 +0000
Received: from [85.158.139.83:23524] by server-3.bemta-5.messagelabs.com id
	8F/E7-25237-070869F4; Tue, 24 Apr 2012 10:29:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263343!24698718!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6658 invoked from network); 24 Apr 2012 10:29:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:29:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:29:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:29:03 +0100
Message-ID: <1335263341.4347.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 11:29:01 +0100
In-Reply-To: <20374.32791.895351.745797@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:27 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> > On Tue, 2012-04-24 at 11:09 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> > 
> > > > XENBUS_PATH contains elements for both the back- and frontend domains as
> > > > well as the specific device.
> > > > 
> > > > Or do you think the key should be global per-(backend-domain rather than
> > > > per-device?
> > > 
> > > The latter.
> > 
> > So /libxl/$XENBUS_PATH is ok then?
> 
> ?
> 
> I was suggesting that the key should be global, and XENBUS_PATH
> contains too much.

Ah, I saw "latter" and read the last bit of my sentence "per-device", my
mistake.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:29:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMcza-00082b-47; Tue, 24 Apr 2012 10:29:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMczZ-00082R-2x
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:29:05 +0000
Received: from [85.158.139.83:23524] by server-3.bemta-5.messagelabs.com id
	8F/E7-25237-070869F4; Tue, 24 Apr 2012 10:29:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263343!24698718!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6658 invoked from network); 24 Apr 2012 10:29:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:29:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12101932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:29:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:29:03 +0100
Message-ID: <1335263341.4347.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 11:29:01 +0100
In-Reply-To: <20374.32791.895351.745797@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:27 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> > On Tue, 2012-04-24 at 11:09 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> > 
> > > > XENBUS_PATH contains elements for both the back- and frontend domains as
> > > > well as the specific device.
> > > > 
> > > > Or do you think the key should be global per-(backend-domain rather than
> > > > per-device?
> > > 
> > > The latter.
> > 
> > So /libxl/$XENBUS_PATH is ok then?
> 
> ?
> 
> I was suggesting that the key should be global, and XENBUS_PATH
> contains too much.

Ah, I saw "latter" and read the last bit of my sentence "per-device", my
mistake.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:31:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd1c-0008HN-BC; Tue, 24 Apr 2012 10:31:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMd1a-0008H5-S9
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:31:11 +0000
Received: from [193.109.254.147:11141] by server-6.bemta-14.messagelabs.com id
	15/D9-02047-EE0869F4; Tue, 24 Apr 2012 10:31:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335263467!6031043!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8914 invoked from network); 24 Apr 2012 10:31:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:31:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:31:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:31:07 +0100
Date: Tue, 24 Apr 2012 11:37:00 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> Hello!
> 
> I was asking for help on the Freenode channel, and I was pointed here.
> 
> I have a situation where, using xl, I can create a functional PV domU, with or without pv-grub, but I cannot access the console.   Firing up xend and using xm works without trouble.    Since xend and company is being deprecated, I would like to transition to using the xl toolstack.
> 
> The system is an Arch Linux system running under VMWare Fusion-- I normally build and test packages this way before I test them on my dev hardware as my dev hardware is a rather loud HP server.   I'm compiling Xen in a package, based off of the one in AUR but with some changes (the AUR package doesn't compile pv-grub, for instance).   It's Xen 4.1.2, and my linux kernel is the standard Arch Linux kernel  version 3.3.2, and it is very near the stock kernel.   Clearly, I have done no HVM testing yet.
> 
> 
> Here's what it looks like when I try xl:
> __START__
> [root@xentest2012 noauto]# xl create -c finnix.cfg
> Parsing config file finnix.cfg
> Unable to attach console
> Daemon running with PID 851
> [root@xentest2012 noauto]# xl console finnix
> Unable to attach console
> [root@xentest2012 noauto]# ls
> domutest.cfg  finnix.cfg
> [root@xentest2012 noauto]# xl create -c domutest.cfg
> Parsing config file domutest.cfg
> xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel
> Unable to attach console
> Daemon running with PID 916
> [root@xentest2012 noauto]# xl console domutest
> Unable to attach console
> [root@xentest2012 noauto]#
> __END__
> 
> Firing up xend, it works just as you would expect.
> 
> 
> Here are the configuration files:
> 
> finnix.cfg:
> __START__
> kernel = "/var/finnix/linux64"
> ramdisk = "/var/finnix/initrd.xz"
> name = "finnix"
> memory = "128"
> disk = [ 'file:/var/finnix/finnix-104.iso,xvda,r', ]
> vif = [ 'bridge=outer0', ]
> __END__
> 
> domutest.cfg:
> __START__
> kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
> extra = "(hd0)/boot/grub/menu.lst"
> 
> memory = 512
> vcpus  = 4
> name   = "domutest"
> disk   = [ "phy:/dev/xtG0/domutest-root,xvda1,w",
>            "phy:/dev/xtG0/domutest-swap,xvda2,w" ]
> vif     = [ "bridge=outer0" ]
> vfb    = [ "type=vnc,vnclisten=0.0.0.0,vncdisplay=5,vncpasswd=smeghead" ]
> __END__
> 
> I can see finnix ask for a DHCP address, and I can connect to domutest using the VNC vfb and use it as normal, so I've concluded that the domUs are running.
> 
> 
> That's what I've got.   Any pointers would help.   Thanks!

I couldn't find any clues in the logs you posted. Maybe the output of
xenstore-ls would be useful.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:31:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd1c-0008HN-BC; Tue, 24 Apr 2012 10:31:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMd1a-0008H5-S9
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:31:11 +0000
Received: from [193.109.254.147:11141] by server-6.bemta-14.messagelabs.com id
	15/D9-02047-EE0869F4; Tue, 24 Apr 2012 10:31:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335263467!6031043!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8914 invoked from network); 24 Apr 2012 10:31:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:31:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:31:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:31:07 +0100
Date: Tue, 24 Apr 2012 11:37:00 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> Hello!
> 
> I was asking for help on the Freenode channel, and I was pointed here.
> 
> I have a situation where, using xl, I can create a functional PV domU, with or without pv-grub, but I cannot access the console.   Firing up xend and using xm works without trouble.    Since xend and company is being deprecated, I would like to transition to using the xl toolstack.
> 
> The system is an Arch Linux system running under VMWare Fusion-- I normally build and test packages this way before I test them on my dev hardware as my dev hardware is a rather loud HP server.   I'm compiling Xen in a package, based off of the one in AUR but with some changes (the AUR package doesn't compile pv-grub, for instance).   It's Xen 4.1.2, and my linux kernel is the standard Arch Linux kernel  version 3.3.2, and it is very near the stock kernel.   Clearly, I have done no HVM testing yet.
> 
> 
> Here's what it looks like when I try xl:
> __START__
> [root@xentest2012 noauto]# xl create -c finnix.cfg
> Parsing config file finnix.cfg
> Unable to attach console
> Daemon running with PID 851
> [root@xentest2012 noauto]# xl console finnix
> Unable to attach console
> [root@xentest2012 noauto]# ls
> domutest.cfg  finnix.cfg
> [root@xentest2012 noauto]# xl create -c domutest.cfg
> Parsing config file domutest.cfg
> xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel
> Unable to attach console
> Daemon running with PID 916
> [root@xentest2012 noauto]# xl console domutest
> Unable to attach console
> [root@xentest2012 noauto]#
> __END__
> 
> Firing up xend, it works just as you would expect.
> 
> 
> Here are the configuration files:
> 
> finnix.cfg:
> __START__
> kernel = "/var/finnix/linux64"
> ramdisk = "/var/finnix/initrd.xz"
> name = "finnix"
> memory = "128"
> disk = [ 'file:/var/finnix/finnix-104.iso,xvda,r', ]
> vif = [ 'bridge=outer0', ]
> __END__
> 
> domutest.cfg:
> __START__
> kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
> extra = "(hd0)/boot/grub/menu.lst"
> 
> memory = 512
> vcpus  = 4
> name   = "domutest"
> disk   = [ "phy:/dev/xtG0/domutest-root,xvda1,w",
>            "phy:/dev/xtG0/domutest-swap,xvda2,w" ]
> vif     = [ "bridge=outer0" ]
> vfb    = [ "type=vnc,vnclisten=0.0.0.0,vncdisplay=5,vncpasswd=smeghead" ]
> __END__
> 
> I can see finnix ask for a DHCP address, and I can connect to domutest using the VNC vfb and use it as normal, so I've concluded that the domUs are running.
> 
> 
> That's what I've got.   Any pointers would help.   Thanks!

I couldn't find any clues in the logs you posted. Maybe the output of
xenstore-ls would be useful.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:32:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd2M-0008QO-VH; Tue, 24 Apr 2012 10:31:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMd2L-0008Ps-5Y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:31:57 +0000
Received: from [85.158.143.35:51103] by server-3.bemta-4.messagelabs.com id
	88/D4-05853-C11869F4; Tue, 24 Apr 2012 10:31:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335263510!12405127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4436 invoked from network); 24 Apr 2012 10:31:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:31:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:31:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:31:49 +0100
Message-ID: <1335263508.4347.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 11:31:48 +0100
In-Reply-To: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 09:37 +0100, Sam Mulvey wrote:
> Hello!
> 
> I was asking for help on the Freenode channel, and I was pointed here.
> 
> I have a situation where, using xl, I can create a functional PV domU,
> with or without pv-grub, but I cannot access the console.   Firing up
> xend and using xm works without trouble.    Since xend and company is
> being deprecated, I would like to transition to using the xl
> toolstack.

Thanks, it's good to see people trying the transition.

Are you able to try xen-unstable? A lot of this stuff (particularly
relating to pv consoles and pygrub etc) is much improved in the 4.2
version of xl and if not then we should be much more able to fix things
there than in 4.1 (where I suspect any fix would be far too invasive for
a stable backport).

Thanks,
Ian.

> The system is an Arch Linux system running under VMWare Fusion-- I
> normally build and test packages this way before I test them on my dev
> hardware as my dev hardware is a rather loud HP server.   I'm
> compiling Xen in a package, based off of the one in AUR but with some
> changes (the AUR package doesn't compile pv-grub, for instance).
> It's Xen 4.1.2, and my linux kernel is the standard Arch Linux kernel
> version 3.3.2, and it is very near the stock kernel.   Clearly, I have
> done no HVM testing yet.
> 
> 
> Here's what it looks like when I try xl:
> __START__
> [root@xentest2012 noauto]# xl create -c finnix.cfg
> Parsing config file finnix.cfg
> Unable to attach console
> Daemon running with PID 851
> [root@xentest2012 noauto]# xl console finnix
> Unable to attach console
> [root@xentest2012 noauto]# ls
> domutest.cfg  finnix.cfg
> [root@xentest2012 noauto]# xl create -c domutest.cfg
> Parsing config file domutest.cfg
> xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel
> Unable to attach console
> Daemon running with PID 916
> [root@xentest2012 noauto]# xl console domutest
> Unable to attach console
> [root@xentest2012 noauto]#
> __END__
> 
> Firing up xend, it works just as you would expect.
> 
> 
> Here are the configuration files:
> 
> finnix.cfg:
> __START__
> kernel = "/var/finnix/linux64"
> ramdisk = "/var/finnix/initrd.xz"
> name = "finnix"
> memory = "128"
> disk = [ 'file:/var/finnix/finnix-104.iso,xvda,r', ]
> vif = [ 'bridge=outer0', ]
> __END__
> 
> domutest.cfg:
> __START__
> kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
> extra = "(hd0)/boot/grub/menu.lst"
> 
> memory = 512
> vcpus  = 4
> name   = "domutest"
> disk   = [ "phy:/dev/xtG0/domutest-root,xvda1,w",
>            "phy:/dev/xtG0/domutest-swap,xvda2,w" ]
> vif     = [ "bridge=outer0" ]
> vfb    = [ "type=vnc,vnclisten=0.0.0.0,vncdisplay=5,vncpasswd=smeghead" ]
> __END__
> 
> I can see finnix ask for a DHCP address, and I can connect to domutest using the VNC vfb and use it as normal, so I've concluded that the domUs are running.
> 
> 
> And now for some other information:
> 
> xen-hotplug.log
> __START__
> RTNETLINK answers: Operation not supported
> RTNETLINK answers: Operation not supported
> __END__
> 
> qemu-dm-finnix.log
> __START__
> domid: 1
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
> /home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603: Created /var/run/tap directory
> Could not open /var/run/tap/qemu-read-1
> char device redirected to /dev/pts/2
> xs_read(): target get error. /local/domain/1/target.
> (qemu) (qemu)
> __END__
> 
> qemu-dm-domutest.log
> __START__
> domid: 2
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
> Could not open /var/run/tap/qemu-read-2
> char device redirected to /dev/pts/3
> xs_read(): target get error. /local/domain/2/target.
> Key lost : keysym=0xffe7(65511)
> Key lost : keysym=0xffe7(65511)
> __END__
> 
> 
> 
> Here's running xl create on domutest with the -v option:
> __START__
> [root@xentest2012 noauto]# xl -v create -c domutest.cfg
> Parsing config file domutest.cfg
> domainbuilder: detail: xc_dom_allocate: cmdline="(hd0)/boot/grub/menu.lst", features="(null)"
> domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz"
> domainbuilder: detail: xc_dom_malloc_filemap    : 1130 kB
> domainbuilder: detail: xc_dom_malloc            : 14779 kB
> domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x11a833 -> 0xe6effa
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, caps xen-3.0-x86_64 xen-3.0-x86_32p
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ...
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
> xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kerne
> l
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
> domainbuilder: detail: loader probe OK
> xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ff60
> xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ff60
> xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPE
> RCALL_PAGE=0x2,LOADER=generic"
> xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
> xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
> xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
> xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
> xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
> xc: detail: elf_xen_parse_guest_info: LOADER="generic"
> xc: detail: elf_xen_addr_calc_check: addresses:
> xc: detail:     virt_base        = 0x0
> xc: detail:     elf_paddr_offset = 0x0
> xc: detail:     virt_offset      = 0x0
> xc: detail:     virt_kstart      = 0x0
> xc: detail:     virt_kend        = 0x99ff60
> xc: detail:     virt_entry       = 0x0
> xc: detail:     p2m_base         = 0xffffffffffffffff
> domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ff60
> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each
> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
> domainbuilder: detail: xc_dom_boot_mem_init: called
> domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
> domainbuilder: detail: xc_dom_malloc            : 1024 kB
> domainbuilder: detail: xc_dom_build_image: called
> domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 -> 0x9a0000  (pfn 0x0 + 0x9a0 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x9a0 at 0x7f18be2e9000
> xc: detail: elf_load_binary: phdr 0 at 0x0x7f18be2e9000 -> 0x0x7f18bec88f60
> domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x9a0000 -> 0xaa0000  (pfn 0x9a0 + 0x100 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x9a0+0x100 at 0x7f18be1e9000
> domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xaa0000 (pfn 0xaa0)
> domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xaa1000 (pfn 0xaa1)
> domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xaa2000 (pfn 0xaa2)
> domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s
> )
> domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s
> )
> domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s
> )
> domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s
> )
> domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xaa3000 -> 0xaac000  (pfn 0xaa3 + 0x9 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa3+0x9 at 0x7f18be1e0000
> domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xaac000 (pfn 0xaac)
> domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xaad000
> domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
> domainbuilder: detail: xc_dom_boot_image: called
> domainbuilder: detail: arch_setup_bootearly: doing nothing
> domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches
> domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
> domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000
> domainbuilder: detail: clear_page: pfn 0xaa2, mfn 0x5dd0c
> domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x5dd0d
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa0+0x1 at 0x7f18be1df000
> domainbuilder: detail: start_info_x86_64: called
> domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2
> domainbuilder: detail: domain builder memory footprint
> domainbuilder: detail:    allocated
> domainbuilder: detail:       malloc             : 15870 kB
> domainbuilder: detail:       anon mmap          : 0 bytes
> domainbuilder: detail:    mapped
> domainbuilder: detail:       file mmap          : 1130 kB
> domainbuilder: detail:       domU mmap          : 10920 kB
> domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0x587bb
> domainbuilder: detail: shared_info_x86_64: called
> domainbuilder: detail: vcpu_x86_64: called
> domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa3 mfn 0x5dd0b
> domainbuilder: detail: launch_vm: called, ctxt=0x7fffa9ec8e90
> domainbuilder: detail: xc_dom_release: called
> Unable to attach console
> Daemon running with PID 1395
> __END__
> 
> And the output of xl info:
> __START__
> host                   : xentest2012
> release                : 3.3.2-1-ARCH
> version                : #1 SMP PREEMPT Sat Apr 14 09:48:37 CEST 2012
> machine                : x86_64
> nr_cpus                : 4
> nr_nodes               : 1
> cores_per_socket       : 1
> threads_per_core       : 1
> cpu_mhz                : 2403
> hw_caps                : 0febfbff:20100800:00000000:00000940:80002201:00000000:00000001:00000000
> virt_caps              :
> total_memory           : 2047
> free_memory            : 870
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 1
> xen_extra              : .2
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : dom0_mem=512M loglvl=all guest_loglvl=all com1=115200,8n1 console=com1
> cc_compiler            : gcc version 4.7.0 20120414 (prerelease) (GCC)
> cc_compile_by          : sam
> cc_compile_domain      : (none)
> cc_compile_date        : Sun Apr 22 19:02:17 PDT 2012
> xend_config_format     : 4
> __END__
> 
> The xl logs have a single line in them:
> 
> xl-domutest.log:
> Waiting for domain domutest (domid 6) to die [pid 1696]
> 
> xl-finnix.log :
> Waiting for domain finnix (domid 7) to die [pid 1763]
> 
> 
> That's what I've got.   Any pointers would help.   Thanks!
> 
> 
> -Sam
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:32:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd2M-0008QO-VH; Tue, 24 Apr 2012 10:31:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMd2L-0008Ps-5Y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:31:57 +0000
Received: from [85.158.143.35:51103] by server-3.bemta-4.messagelabs.com id
	88/D4-05853-C11869F4; Tue, 24 Apr 2012 10:31:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335263510!12405127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4436 invoked from network); 24 Apr 2012 10:31:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:31:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:31:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 11:31:49 +0100
Message-ID: <1335263508.4347.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 11:31:48 +0100
In-Reply-To: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 09:37 +0100, Sam Mulvey wrote:
> Hello!
> 
> I was asking for help on the Freenode channel, and I was pointed here.
> 
> I have a situation where, using xl, I can create a functional PV domU,
> with or without pv-grub, but I cannot access the console.   Firing up
> xend and using xm works without trouble.    Since xend and company is
> being deprecated, I would like to transition to using the xl
> toolstack.

Thanks, it's good to see people trying the transition.

Are you able to try xen-unstable? A lot of this stuff (particularly
relating to pv consoles and pygrub etc) is much improved in the 4.2
version of xl and if not then we should be much more able to fix things
there than in 4.1 (where I suspect any fix would be far too invasive for
a stable backport).

Thanks,
Ian.

> The system is an Arch Linux system running under VMWare Fusion-- I
> normally build and test packages this way before I test them on my dev
> hardware as my dev hardware is a rather loud HP server.   I'm
> compiling Xen in a package, based off of the one in AUR but with some
> changes (the AUR package doesn't compile pv-grub, for instance).
> It's Xen 4.1.2, and my linux kernel is the standard Arch Linux kernel
> version 3.3.2, and it is very near the stock kernel.   Clearly, I have
> done no HVM testing yet.
> 
> 
> Here's what it looks like when I try xl:
> __START__
> [root@xentest2012 noauto]# xl create -c finnix.cfg
> Parsing config file finnix.cfg
> Unable to attach console
> Daemon running with PID 851
> [root@xentest2012 noauto]# xl console finnix
> Unable to attach console
> [root@xentest2012 noauto]# ls
> domutest.cfg  finnix.cfg
> [root@xentest2012 noauto]# xl create -c domutest.cfg
> Parsing config file domutest.cfg
> xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel
> Unable to attach console
> Daemon running with PID 916
> [root@xentest2012 noauto]# xl console domutest
> Unable to attach console
> [root@xentest2012 noauto]#
> __END__
> 
> Firing up xend, it works just as you would expect.
> 
> 
> Here are the configuration files:
> 
> finnix.cfg:
> __START__
> kernel = "/var/finnix/linux64"
> ramdisk = "/var/finnix/initrd.xz"
> name = "finnix"
> memory = "128"
> disk = [ 'file:/var/finnix/finnix-104.iso,xvda,r', ]
> vif = [ 'bridge=outer0', ]
> __END__
> 
> domutest.cfg:
> __START__
> kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
> extra = "(hd0)/boot/grub/menu.lst"
> 
> memory = 512
> vcpus  = 4
> name   = "domutest"
> disk   = [ "phy:/dev/xtG0/domutest-root,xvda1,w",
>            "phy:/dev/xtG0/domutest-swap,xvda2,w" ]
> vif     = [ "bridge=outer0" ]
> vfb    = [ "type=vnc,vnclisten=0.0.0.0,vncdisplay=5,vncpasswd=smeghead" ]
> __END__
> 
> I can see finnix ask for a DHCP address, and I can connect to domutest using the VNC vfb and use it as normal, so I've concluded that the domUs are running.
> 
> 
> And now for some other information:
> 
> xen-hotplug.log
> __START__
> RTNETLINK answers: Operation not supported
> RTNETLINK answers: Operation not supported
> __END__
> 
> qemu-dm-finnix.log
> __START__
> domid: 1
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
> /home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603: Created /var/run/tap directory
> Could not open /var/run/tap/qemu-read-1
> char device redirected to /dev/pts/2
> xs_read(): target get error. /local/domain/1/target.
> (qemu) (qemu)
> __END__
> 
> qemu-dm-domutest.log
> __START__
> domid: 2
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
> Could not open /var/run/tap/qemu-read-2
> char device redirected to /dev/pts/3
> xs_read(): target get error. /local/domain/2/target.
> Key lost : keysym=0xffe7(65511)
> Key lost : keysym=0xffe7(65511)
> __END__
> 
> 
> 
> Here's running xl create on domutest with the -v option:
> __START__
> [root@xentest2012 noauto]# xl -v create -c domutest.cfg
> Parsing config file domutest.cfg
> domainbuilder: detail: xc_dom_allocate: cmdline="(hd0)/boot/grub/menu.lst", features="(null)"
> domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz"
> domainbuilder: detail: xc_dom_malloc_filemap    : 1130 kB
> domainbuilder: detail: xc_dom_malloc            : 14779 kB
> domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x11a833 -> 0xe6effa
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, caps xen-3.0-x86_64 xen-3.0-x86_32p
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ...
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
> xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kerne
> l
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
> domainbuilder: detail: loader probe OK
> xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ff60
> xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ff60
> xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPE
> RCALL_PAGE=0x2,LOADER=generic"
> xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
> xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
> xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
> xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
> xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
> xc: detail: elf_xen_parse_guest_info: LOADER="generic"
> xc: detail: elf_xen_addr_calc_check: addresses:
> xc: detail:     virt_base        = 0x0
> xc: detail:     elf_paddr_offset = 0x0
> xc: detail:     virt_offset      = 0x0
> xc: detail:     virt_kstart      = 0x0
> xc: detail:     virt_kend        = 0x99ff60
> xc: detail:     virt_entry       = 0x0
> xc: detail:     p2m_base         = 0xffffffffffffffff
> domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ff60
> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each
> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
> domainbuilder: detail: xc_dom_boot_mem_init: called
> domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
> domainbuilder: detail: xc_dom_malloc            : 1024 kB
> domainbuilder: detail: xc_dom_build_image: called
> domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 -> 0x9a0000  (pfn 0x0 + 0x9a0 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x9a0 at 0x7f18be2e9000
> xc: detail: elf_load_binary: phdr 0 at 0x0x7f18be2e9000 -> 0x0x7f18bec88f60
> domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x9a0000 -> 0xaa0000  (pfn 0x9a0 + 0x100 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x9a0+0x100 at 0x7f18be1e9000
> domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xaa0000 (pfn 0xaa0)
> domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xaa1000 (pfn 0xaa1)
> domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xaa2000 (pfn 0xaa2)
> domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s
> )
> domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s
> )
> domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s
> )
> domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s
> )
> domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xaa3000 -> 0xaac000  (pfn 0xaa3 + 0x9 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa3+0x9 at 0x7f18be1e0000
> domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xaac000 (pfn 0xaac)
> domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xaad000
> domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
> domainbuilder: detail: xc_dom_boot_image: called
> domainbuilder: detail: arch_setup_bootearly: doing nothing
> domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches
> domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
> domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000
> domainbuilder: detail: clear_page: pfn 0xaa2, mfn 0x5dd0c
> domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x5dd0d
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa0+0x1 at 0x7f18be1df000
> domainbuilder: detail: start_info_x86_64: called
> domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2
> domainbuilder: detail: domain builder memory footprint
> domainbuilder: detail:    allocated
> domainbuilder: detail:       malloc             : 15870 kB
> domainbuilder: detail:       anon mmap          : 0 bytes
> domainbuilder: detail:    mapped
> domainbuilder: detail:       file mmap          : 1130 kB
> domainbuilder: detail:       domU mmap          : 10920 kB
> domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0x587bb
> domainbuilder: detail: shared_info_x86_64: called
> domainbuilder: detail: vcpu_x86_64: called
> domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa3 mfn 0x5dd0b
> domainbuilder: detail: launch_vm: called, ctxt=0x7fffa9ec8e90
> domainbuilder: detail: xc_dom_release: called
> Unable to attach console
> Daemon running with PID 1395
> __END__
> 
> And the output of xl info:
> __START__
> host                   : xentest2012
> release                : 3.3.2-1-ARCH
> version                : #1 SMP PREEMPT Sat Apr 14 09:48:37 CEST 2012
> machine                : x86_64
> nr_cpus                : 4
> nr_nodes               : 1
> cores_per_socket       : 1
> threads_per_core       : 1
> cpu_mhz                : 2403
> hw_caps                : 0febfbff:20100800:00000000:00000940:80002201:00000000:00000001:00000000
> virt_caps              :
> total_memory           : 2047
> free_memory            : 870
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 1
> xen_extra              : .2
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : dom0_mem=512M loglvl=all guest_loglvl=all com1=115200,8n1 console=com1
> cc_compiler            : gcc version 4.7.0 20120414 (prerelease) (GCC)
> cc_compile_by          : sam
> cc_compile_domain      : (none)
> cc_compile_date        : Sun Apr 22 19:02:17 PDT 2012
> xend_config_format     : 4
> __END__
> 
> The xl logs have a single line in them:
> 
> xl-domutest.log:
> Waiting for domain domutest (domid 6) to die [pid 1696]
> 
> xl-finnix.log :
> Waiting for domain finnix (domid 7) to die [pid 1763]
> 
> 
> That's what I've got.   Any pointers would help.   Thanks!
> 
> 
> -Sam
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:32:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd2z-00005q-Kr; Tue, 24 Apr 2012 10:32:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SMd2y-00004v-0x
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:32:36 +0000
Received: from [85.158.138.51:22509] by server-6.bemta-3.messagelabs.com id
	92/FE-05145-141869F4; Tue, 24 Apr 2012 10:32:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335263552!14584964!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25920 invoked from network); 24 Apr 2012 10:32:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:32:33 -0000
Received: by bkty15 with SMTP id y15so464586bkt.32
	for <multiple recipients>; Tue, 24 Apr 2012 03:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=PUQgzotWf9ALMoEzuDJ+ob5k+5xgz7EmAI2Vd7R4+8k=;
	b=mQ2zQKXSJKjPq+0CHiF8svsJB/hCCWcefvUHLe6goGx4ambhmF6xeP6p3rcBTYQ5Hj
	GTsqFBYsVguXSsdBOT+rVvin15BEUqqPO+3zu+H61j/1eac13CWSbl/DfCcxD+gDGnKw
	8wvGYXDROO0cpKpm+Daq/4jGORWFx0ko01FA+Tlslwy1GyR295SvNZq66S0PfNEXiQvj
	IwRixzq9+zerwdtUyoScMXluBVDgUCUFhbgzf2Wmp60um4sHQQRGOUQN1XSsX5u3ayf/
	oki74Jkd0LGKtpq8Xmoo/j9u+mYC5pVndJtDEUW07uK8w9mN+foVo5Pmag6IxtIgwLj6
	jxJw==
Received: by 10.204.149.210 with SMTP id u18mr965382bkv.34.1335263552144;
	Tue, 24 Apr 2012 03:32:32 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id
	zx16sm30843660bkb.13.2012.04.24.03.32.29
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 03:32:30 -0700 (PDT)
Message-ID: <4F96813C.6030108@xen.org>
Date: Tue, 24 Apr 2012 11:32:28 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, 
 xen-api@lists.xen.org
References: <4F9199E5.5080409@xen.org>
In-Reply-To: <4F9199E5.5080409@xen.org>
Subject: Re: [Xen-devel] IMPORTANT: Changes to XenSummit Format : Please
	vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I got a number of votes so far: votes are still open until Friday

let me summarize votes so far:
- 5 votes for sunday (option 1)
- 2 votes for a parallel session on the 26th PM (option 3.1)
- 1 vote for cutting XenSummit short (option 2)

Regards
Lars

On 20/04/2012 18:16, Lars Kurth wrote:
> Hi everybody,
>
> I have been talking to a number of the key contributors to the project 
> regarding XenSummit and got feedback on the format of XenSummit. 
> Please read, if you are active in the community and DO VOTE!
>
> Cheers
> Lars
>
> Change of date in CFP!
> ======================
> First I wanted to annouce that we are extending the CFP from May 1st 
> to 15th of June. Key community members felt that May 1 is too early. 
> In particular because we have closed the CFP 5-6 weeks before the 
> event in the past. Due to contractual issues June 15th is the last day 
> we can do though.
>
> Proposal! PLEASE READ!
> ======================
> A number of vendors felt we should change the format of XenSummit to 
> be more like the Linux Kernel Summit. I.e.
> a) An invite only event for the top 20-30 developers of the project
> b) The main focus would be around finding technical solutions and 
> making decisions
> I can see the merit of this, but it is too late to do this for all of 
> XenSummit due to event contracts that havce been signed.
>
> However we have a number of options, moving towards this:
> 1) Start half a day early and have an invite only XenDev Event event 
> on Sunday afteroon
> 2) Cut XenSummit short by 1/2 day and append the XenDev event. This 
> may incur some financial penalties for Xen.org and the overall ticket 
> cost may have to be higher than in the past.
> 3) Do the invite only meeting in parallel with XenSummit. I have an 
> additional large room on TUE the 27th, which we could use for this and 
> I also have two break-out rooms and can allocate one of them to the 
> XenDev event (these were intended for people sitting together and 
> hacking on stuff and/or BoFs). There are several options: hold the 
> XenDev event on
> 3.1) 26th afternoon
> 3.2) 27th morning
> 3.3) 27th afternoon
>
> In my view option 1) and 3.1) have the advantage that we can report 
> back to XenSummit, that nobody will miss key talks and that people can 
> sit together in the break-out rooms.
>
> Vote
> ====
> Please vote by providing. Vote closes by the 27th. Vote by replying to 
> this mail with ...
> -1: none of the above (i.e. I dont want a XenDev event)
> +1 for a DevMeeting on sunday (aka for proposal 1)
> +1 for cutting XenSummit short (aka for proposal 2)
> +1 for parallel 26th PM (aka proposal 3.1)
> +1 for parallel 27th AM (aka proposal 3.2)
> +1 for parallel 27th PM (aka proposal 3.3)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:32:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd2z-00005q-Kr; Tue, 24 Apr 2012 10:32:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SMd2y-00004v-0x
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:32:36 +0000
Received: from [85.158.138.51:22509] by server-6.bemta-3.messagelabs.com id
	92/FE-05145-141869F4; Tue, 24 Apr 2012 10:32:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335263552!14584964!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25920 invoked from network); 24 Apr 2012 10:32:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:32:33 -0000
Received: by bkty15 with SMTP id y15so464586bkt.32
	for <multiple recipients>; Tue, 24 Apr 2012 03:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=PUQgzotWf9ALMoEzuDJ+ob5k+5xgz7EmAI2Vd7R4+8k=;
	b=mQ2zQKXSJKjPq+0CHiF8svsJB/hCCWcefvUHLe6goGx4ambhmF6xeP6p3rcBTYQ5Hj
	GTsqFBYsVguXSsdBOT+rVvin15BEUqqPO+3zu+H61j/1eac13CWSbl/DfCcxD+gDGnKw
	8wvGYXDROO0cpKpm+Daq/4jGORWFx0ko01FA+Tlslwy1GyR295SvNZq66S0PfNEXiQvj
	IwRixzq9+zerwdtUyoScMXluBVDgUCUFhbgzf2Wmp60um4sHQQRGOUQN1XSsX5u3ayf/
	oki74Jkd0LGKtpq8Xmoo/j9u+mYC5pVndJtDEUW07uK8w9mN+foVo5Pmag6IxtIgwLj6
	jxJw==
Received: by 10.204.149.210 with SMTP id u18mr965382bkv.34.1335263552144;
	Tue, 24 Apr 2012 03:32:32 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id
	zx16sm30843660bkb.13.2012.04.24.03.32.29
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 03:32:30 -0700 (PDT)
Message-ID: <4F96813C.6030108@xen.org>
Date: Tue, 24 Apr 2012 11:32:28 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-arm@lists.xen.org, 
 xen-api@lists.xen.org
References: <4F9199E5.5080409@xen.org>
In-Reply-To: <4F9199E5.5080409@xen.org>
Subject: Re: [Xen-devel] IMPORTANT: Changes to XenSummit Format : Please
	vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I got a number of votes so far: votes are still open until Friday

let me summarize votes so far:
- 5 votes for sunday (option 1)
- 2 votes for a parallel session on the 26th PM (option 3.1)
- 1 vote for cutting XenSummit short (option 2)

Regards
Lars

On 20/04/2012 18:16, Lars Kurth wrote:
> Hi everybody,
>
> I have been talking to a number of the key contributors to the project 
> regarding XenSummit and got feedback on the format of XenSummit. 
> Please read, if you are active in the community and DO VOTE!
>
> Cheers
> Lars
>
> Change of date in CFP!
> ======================
> First I wanted to annouce that we are extending the CFP from May 1st 
> to 15th of June. Key community members felt that May 1 is too early. 
> In particular because we have closed the CFP 5-6 weeks before the 
> event in the past. Due to contractual issues June 15th is the last day 
> we can do though.
>
> Proposal! PLEASE READ!
> ======================
> A number of vendors felt we should change the format of XenSummit to 
> be more like the Linux Kernel Summit. I.e.
> a) An invite only event for the top 20-30 developers of the project
> b) The main focus would be around finding technical solutions and 
> making decisions
> I can see the merit of this, but it is too late to do this for all of 
> XenSummit due to event contracts that havce been signed.
>
> However we have a number of options, moving towards this:
> 1) Start half a day early and have an invite only XenDev Event event 
> on Sunday afteroon
> 2) Cut XenSummit short by 1/2 day and append the XenDev event. This 
> may incur some financial penalties for Xen.org and the overall ticket 
> cost may have to be higher than in the past.
> 3) Do the invite only meeting in parallel with XenSummit. I have an 
> additional large room on TUE the 27th, which we could use for this and 
> I also have two break-out rooms and can allocate one of them to the 
> XenDev event (these were intended for people sitting together and 
> hacking on stuff and/or BoFs). There are several options: hold the 
> XenDev event on
> 3.1) 26th afternoon
> 3.2) 27th morning
> 3.3) 27th afternoon
>
> In my view option 1) and 3.1) have the advantage that we can report 
> back to XenSummit, that nobody will miss key talks and that people can 
> sit together in the break-out rooms.
>
> Vote
> ====
> Please vote by providing. Vote closes by the 27th. Vote by replying to 
> this mail with ...
> -1: none of the above (i.e. I dont want a XenDev event)
> +1 for a DevMeeting on sunday (aka for proposal 1)
> +1 for cutting XenSummit short (aka for proposal 2)
> +1 for parallel 26th PM (aka proposal 3.1)
> +1 for parallel 27th AM (aka proposal 3.2)
> +1 for parallel 27th PM (aka proposal 3.3)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:34:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd4z-0000TD-7P; Tue, 24 Apr 2012 10:34:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SMd4y-0000T0-5Z
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:34:40 +0000
Received: from [85.158.139.83:16512] by server-5.bemta-5.messagelabs.com id
	2D/37-13566-FB1869F4; Tue, 24 Apr 2012 10:34:39 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335263678!24551554!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gNDQwOTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7332 invoked from network); 24 Apr 2012 10:34:38 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196) by server-9.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 10:34:38 -0000
X-Originating-IP: 217.70.178.145
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 93CCA1720AE;
	Tue, 24 Apr 2012 12:34:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter17-d.gandi.net (mfilter17-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id RtJqEoY6TxFR; Tue, 24 Apr 2012 12:34:37 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A37431720AA;
	Tue, 24 Apr 2012 12:34:36 +0200 (CEST)
Message-ID: <4F9681BC.2000501@de-bruyn.fr>
Date: Tue, 24 Apr 2012 12:34:36 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F967494.8070009@de-bruyn.fr>
	<1335262424.4347.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335262424.4347.71.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-tools ioemu-remote missing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thank you Ian.

Regards,

On 24.04.2012 12:13, Ian Campbell wrote:
> On Tue, 2012-04-24 at 10:38 +0100, Alexis de BRUYN [Mailinglists] wrote:
>> Hi Everybody,
>>
>> I am trying to install Xen / Remus with the remusha wiki, but after a
>> make tools, the tools/ioemu-remote directory is missing. I have tried
>> several times.
> 
> This is now called qemu-xen-traditional-dir-remote.
> 
> Ian.
> 
> 

-- 
--
Alexis de BRUYN

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:34:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd4z-0000TD-7P; Tue, 24 Apr 2012 10:34:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alexis.mailinglist@de-bruyn.fr>) id 1SMd4y-0000T0-5Z
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:34:40 +0000
Received: from [85.158.139.83:16512] by server-5.bemta-5.messagelabs.com id
	2D/37-13566-FB1869F4; Tue, 24 Apr 2012 10:34:39 +0000
X-Env-Sender: alexis.mailinglist@de-bruyn.fr
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335263678!24551554!1
X-Originating-IP: [217.70.183.196]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjE3LjcwLjE4My4xOTYgPT4gNDQwOTc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7332 invoked from network); 24 Apr 2012 10:34:38 -0000
Received: from relay4-d.mail.gandi.net (HELO relay4-d.mail.gandi.net)
	(217.70.183.196) by server-9.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 10:34:38 -0000
X-Originating-IP: 217.70.178.145
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 93CCA1720AE;
	Tue, 24 Apr 2012 12:34:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter17-d.gandi.net (mfilter17-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id RtJqEoY6TxFR; Tue, 24 Apr 2012 12:34:37 +0200 (CEST)
X-Originating-IP: 85.171.129.56
Received: from [192.168.0.3] (85-171-129-56.rev.numericable.fr [85.171.129.56])
	(Authenticated sender: alexis.mailinglist@de-bruyn.fr)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A37431720AA;
	Tue, 24 Apr 2012 12:34:36 +0200 (CEST)
Message-ID: <4F9681BC.2000501@de-bruyn.fr>
Date: Tue, 24 Apr 2012 12:34:36 +0200
From: "Alexis de BRUYN [Mailinglists]" <alexis.mailinglist@de-bruyn.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F967494.8070009@de-bruyn.fr>
	<1335262424.4347.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335262424.4347.71.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-tools ioemu-remote missing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thank you Ian.

Regards,

On 24.04.2012 12:13, Ian Campbell wrote:
> On Tue, 2012-04-24 at 10:38 +0100, Alexis de BRUYN [Mailinglists] wrote:
>> Hi Everybody,
>>
>> I am trying to install Xen / Remus with the remusha wiki, but after a
>> make tools, the tools/ioemu-remote directory is missing. I have tried
>> several times.
> 
> This is now called qemu-xen-traditional-dir-remote.
> 
> Ian.
> 
> 

-- 
--
Alexis de BRUYN

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd7j-0000gk-QZ; Tue, 24 Apr 2012 10:37:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMd7i-0000gd-S9
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:37:31 +0000
Received: from [85.158.143.35:29815] by server-3.bemta-4.messagelabs.com id
	B1/00-05853-A62869F4; Tue, 24 Apr 2012 10:37:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335263848!17537213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9135 invoked from network); 24 Apr 2012 10:37:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:37:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:37:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:37:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMd7f-0003kV-Qq; Tue, 24 Apr 2012 10:37:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMd7f-0006kw-Pz;
	Tue, 24 Apr 2012 11:37:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.33383.748153.64321@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 11:37:27 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335263341.4347.75.camel@zakaz.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
	<1335263341.4347.75.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> On Tue, 2012-04-24 at 11:27 +0100, Ian Jackson wrote:
> > I was suggesting that the key should be global, and XENBUS_PATH
> > contains too much.
> 
> Ah, I saw "latter" and read the last bit of my sentence "per-device", my
> mistake.

Right.

The reason I think it should be global is that this is a transitional
bodge to make driver domains continue to work pending a proper
sorting-out in 4.3.  So there is no need to make it fully general.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd7j-0000gk-QZ; Tue, 24 Apr 2012 10:37:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMd7i-0000gd-S9
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 10:37:31 +0000
Received: from [85.158.143.35:29815] by server-3.bemta-4.messagelabs.com id
	B1/00-05853-A62869F4; Tue, 24 Apr 2012 10:37:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335263848!17537213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9135 invoked from network); 24 Apr 2012 10:37:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:37:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:37:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:37:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMd7f-0003kV-Qq; Tue, 24 Apr 2012 10:37:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMd7f-0006kw-Pz;
	Tue, 24 Apr 2012 11:37:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.33383.748153.64321@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 11:37:27 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335263341.4347.75.camel@zakaz.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
	<1335263341.4347.75.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl	for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from libxl	for vbd"):
> On Tue, 2012-04-24 at 11:27 +0100, Ian Jackson wrote:
> > I was suggesting that the key should be global, and XENBUS_PATH
> > contains too much.
> 
> Ah, I saw "latter" and read the last bit of my sentence "per-device", my
> mistake.

Right.

The reason I think it should be global is that this is a transitional
bodge to make driver domains continue to work pending a proper
sorting-out in 4.3.  So there is no need to make it fully general.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:39:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd9X-0000pw-BB; Tue, 24 Apr 2012 10:39:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMd9V-0000ph-8y
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:39:21 +0000
Received: from [193.109.254.147:58801] by server-1.bemta-14.messagelabs.com id
	C2/5C-29372-8D2869F4; Tue, 24 Apr 2012 10:39:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335263959!6047748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8016 invoked from network); 24 Apr 2012 10:39:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:39:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:39:19 +0100
Date: Tue, 24 Apr 2012 11:45:22 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/8] qdisk local attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch implements local_attach support for QDISK: that means that
you can use qcow2 as disk format for your PV guests disks and use
pygrub to retrieve the kernel and initrd in dom0.

The idea is that we start a QEMU instance at boot time to listen to
local_attach requests. When libxl_device_disk_local_attach is called on
a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk
so that blkfront in dom0 will create a new xvd device for it.
Then pygrub can be pointed at this device to retrieve kernel and
initrd.


Changes in v4:
- split the first patch into 2 patches: the first is a simple move, the
  second one adds a new parameter;
- libxl__device_generic_add: do not end the transaction is the caller
  provided it;
- libxl__device_generic_add: fix success exit path;
- pass blkdev_start in libxl_domain_build_info;
- rename libxl__devid_to_vdev to libxl__devid_to_localdev;
- introduce upper bound for encode_disk_name;
- improve error handling and exit paths in libxl__alloc_vdev and
  libxl__device_disk_local_attach.


Changes in v3:
- libxl__device_disk_local_attach: wait for the backend to be
"connected" before returning.


Changes in v2:
- make libxl_device_disk_local_(de)attach internal functions;
- allocate the new disk in libxl_device_disk_local_attatch on the GC;
- remove libxl__device_generic_add_t, add a transaction parameter to
libxl__device_generic_add instead;
- add a new patch to introduce a blkdev_start option to xl.conf;
- reimplement libxl__alloc_vdev checking for the frontend path and
starting from blkdev_start;
- introduce a Linux specific libxl__devid_to_vdev function based on last
Jan's patch to blkfront.



Stefano Stabellini (8):
      libxl: make libxl_device_disk_local_attach/detach internal functions
      libxl: libxl__device_disk_local_attach return a new libxl_device_disk
      libxl: add a transaction parameter to libxl__device_generic_add
      libxl: introduce libxl__device_disk_add_t
      xl/libxl: add a blkdev_start parameter
      libxl: introduce libxl__alloc_vdev
      xl/libxl: implement QDISK libxl_device_disk_local_attach
      libxl__device_disk_local_attach: wait for state "connected"

 tools/examples/xl.conf                          |    3 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl.c                             |  232 +----------------
 tools/libxl/libxl.h                             |    7 -
 tools/libxl/libxl_bootloader.c                  |   11 +-
 tools/libxl/libxl_create.c                      |    3 +
 tools/libxl/libxl_device.c                      |   17 +-
 tools/libxl/libxl_internal.c                    |  316 +++++++++++++++++++++++
 tools/libxl/libxl_internal.h                    |   25 ++-
 tools/libxl/libxl_linux.c                       |   45 ++++
 tools/libxl/libxl_netbsd.c                      |    6 +
 tools/libxl/libxl_pci.c                         |    2 +-
 tools/libxl/libxl_types.idl                     |    1 +
 tools/libxl/xl.c                                |    3 +
 tools/libxl/xl.h                                |    1 +
 tools/libxl/xl_cmdimpl.c                        |    2 +
 17 files changed, 432 insertions(+), 248 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:39:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMd9X-0000pw-BB; Tue, 24 Apr 2012 10:39:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMd9V-0000ph-8y
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:39:21 +0000
Received: from [193.109.254.147:58801] by server-1.bemta-14.messagelabs.com id
	C2/5C-29372-8D2869F4; Tue, 24 Apr 2012 10:39:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335263959!6047748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8016 invoked from network); 24 Apr 2012 10:39:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:39:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:39:19 +0100
Date: Tue, 24 Apr 2012 11:45:22 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/8] qdisk local attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch implements local_attach support for QDISK: that means that
you can use qcow2 as disk format for your PV guests disks and use
pygrub to retrieve the kernel and initrd in dom0.

The idea is that we start a QEMU instance at boot time to listen to
local_attach requests. When libxl_device_disk_local_attach is called on
a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk
so that blkfront in dom0 will create a new xvd device for it.
Then pygrub can be pointed at this device to retrieve kernel and
initrd.


Changes in v4:
- split the first patch into 2 patches: the first is a simple move, the
  second one adds a new parameter;
- libxl__device_generic_add: do not end the transaction is the caller
  provided it;
- libxl__device_generic_add: fix success exit path;
- pass blkdev_start in libxl_domain_build_info;
- rename libxl__devid_to_vdev to libxl__devid_to_localdev;
- introduce upper bound for encode_disk_name;
- improve error handling and exit paths in libxl__alloc_vdev and
  libxl__device_disk_local_attach.


Changes in v3:
- libxl__device_disk_local_attach: wait for the backend to be
"connected" before returning.


Changes in v2:
- make libxl_device_disk_local_(de)attach internal functions;
- allocate the new disk in libxl_device_disk_local_attatch on the GC;
- remove libxl__device_generic_add_t, add a transaction parameter to
libxl__device_generic_add instead;
- add a new patch to introduce a blkdev_start option to xl.conf;
- reimplement libxl__alloc_vdev checking for the frontend path and
starting from blkdev_start;
- introduce a Linux specific libxl__devid_to_vdev function based on last
Jan's patch to blkfront.



Stefano Stabellini (8):
      libxl: make libxl_device_disk_local_attach/detach internal functions
      libxl: libxl__device_disk_local_attach return a new libxl_device_disk
      libxl: add a transaction parameter to libxl__device_generic_add
      libxl: introduce libxl__device_disk_add_t
      xl/libxl: add a blkdev_start parameter
      libxl: introduce libxl__alloc_vdev
      xl/libxl: implement QDISK libxl_device_disk_local_attach
      libxl__device_disk_local_attach: wait for state "connected"

 tools/examples/xl.conf                          |    3 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl.c                             |  232 +----------------
 tools/libxl/libxl.h                             |    7 -
 tools/libxl/libxl_bootloader.c                  |   11 +-
 tools/libxl/libxl_create.c                      |    3 +
 tools/libxl/libxl_device.c                      |   17 +-
 tools/libxl/libxl_internal.c                    |  316 +++++++++++++++++++++++
 tools/libxl/libxl_internal.h                    |   25 ++-
 tools/libxl/libxl_linux.c                       |   45 ++++
 tools/libxl/libxl_netbsd.c                      |    6 +
 tools/libxl/libxl_pci.c                         |    2 +-
 tools/libxl/libxl_types.idl                     |    1 +
 tools/libxl/xl.c                                |    3 +
 tools/libxl/xl.h                                |    1 +
 tools/libxl/xl_cmdimpl.c                        |    2 +
 17 files changed, 432 insertions(+), 248 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAA-0000vc-Ae; Tue, 24 Apr 2012 10:40:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdA8-0000v0-WE
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:01 +0000
Received: from [85.158.138.51:32693] by server-4.bemta-3.messagelabs.com id
	E0/16-15341-003869F4; Tue, 24 Apr 2012 10:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335263997!23569859!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32213 invoked from network); 24 Apr 2012 10:39:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760376"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-I8; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:53 +0100
Message-ID: <1335264358-20182-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/8] libxl: add a transaction parameter to
	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
XBT_NULL, allocate a proper one.

Update all the callers.

Changes in v4:
- libxl__device_generic_add: do not end the transaction is the caller
provided it;
- libxl__device_generic_add: fix success exit path.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   10 +++++-----
 tools/libxl/libxl_device.c   |   17 +++++++++++------
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_pci.c      |    2 +-
 4 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e645d2a..85082eb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -1795,7 +1795,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -2073,7 +2073,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
     }
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2144,7 +2144,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2277,7 +2277,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
                           libxl__sprintf(gc, "%d", vfb->backend_domid));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..88cdc7d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
-int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *frontend_path, *backend_path;
-    xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    int create_transaction = t == XBT_NULL;
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
@@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].perms = XS_PERM_READ;
 
 retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
+    if (create_transaction)
+        t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
 
     if (fents) {
@@ -100,13 +101,17 @@ retry_transaction:
         libxl__xs_writev(gc, t, backend_path, bents);
     }
 
+    if (!create_transaction)
+        return 0;
+
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;
-        else
+        else {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
+            return ERROR_FAIL;
+        }
     }
-
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2f1cf0f..00856e0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -681,8 +681,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
-_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index e8b8839..202a101 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAA-0000vc-Ae; Tue, 24 Apr 2012 10:40:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdA8-0000v0-WE
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:01 +0000
Received: from [85.158.138.51:32693] by server-4.bemta-3.messagelabs.com id
	E0/16-15341-003869F4; Tue, 24 Apr 2012 10:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335263997!23569859!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32213 invoked from network); 24 Apr 2012 10:39:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760376"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-I8; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:53 +0100
Message-ID: <1335264358-20182-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/8] libxl: add a transaction parameter to
	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
XBT_NULL, allocate a proper one.

Update all the callers.

Changes in v4:
- libxl__device_generic_add: do not end the transaction is the caller
provided it;
- libxl__device_generic_add: fix success exit path.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   10 +++++-----
 tools/libxl/libxl_device.c   |   17 +++++++++++------
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_pci.c      |    2 +-
 4 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e645d2a..85082eb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -1795,7 +1795,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
@@ -2073,7 +2073,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
     }
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2144,7 +2144,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
@@ -2277,7 +2277,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
                           libxl__sprintf(gc, "%d", vfb->backend_domid));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c7e057d..88cdc7d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
-int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents)
+int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *frontend_path, *backend_path;
-    xs_transaction_t t;
     struct xs_permissions frontend_perms[2];
     struct xs_permissions backend_perms[2];
+    int create_transaction = t == XBT_NULL;
 
     frontend_path = libxl__device_frontend_path(gc, device);
     backend_path = libxl__device_backend_path(gc, device);
@@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
     backend_perms[1].perms = XS_PERM_READ;
 
 retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
+    if (create_transaction)
+        t = xs_transaction_start(ctx->xsh);
     /* FIXME: read frontend_path and check state before removing stuff */
 
     if (fents) {
@@ -100,13 +101,17 @@ retry_transaction:
         libxl__xs_writev(gc, t, backend_path, bents);
     }
 
+    if (!create_transaction)
+        return 0;
+
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;
-        else
+        else {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
+            return ERROR_FAIL;
+        }
     }
-
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2f1cf0f..00856e0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -681,8 +681,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                                       libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
-_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
-                             char **bents, char **fents);
+_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
+        libxl__device *device, char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index e8b8839..202a101 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0));
     flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(gc, &device,
+    libxl__device_generic_add(gc, XBT_NULL, &device,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAC-0000wL-5K; Tue, 24 Apr 2012 10:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAA-0000vG-2Y
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:02 +0000
Received: from [85.158.138.51:34673] by server-5.bemta-3.messagelabs.com id
	AB/7F-17113-103869F4; Tue, 24 Apr 2012 10:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335263997!23569859!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32285 invoked from network); 24 Apr 2012 10:40:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760377"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-Fl; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:51 +0100
Message-ID: <1335264358-20182-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 1/8] libxl: make
	libxl_device_disk_local_attach/detach internal functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c            |   73 ----------------------------------------
 tools/libxl/libxl.h            |    7 ----
 tools/libxl/libxl_bootloader.c |    4 +-
 tools/libxl/libxl_internal.c   |   72 +++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    9 +++++
 5 files changed, 83 insertions(+), 82 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..e645d2a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1664,79 +1664,6 @@ out:
     return ret;
 }
 
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    char *dev = NULL;
-    char *ret = NULL;
-    int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
-    }
-
- out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    GC_FREE;
-    return ret;
-}
-
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
-}
-
 /******************************************************************************/
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..779c8dd 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -618,13 +618,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
  */
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
-
 /* Network Interfaces */
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..977c6d3 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -386,7 +386,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk);
     if (!diskpath) {
         goto out_close;
     }
@@ -453,7 +453,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     rc = 0;
 out_close:
     if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
+        libxl__device_disk_local_detach(gc, disk);
         free(diskpath);
     }
     if (fifo_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index b89aef7..1f428b2 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,78 @@ out:
     return rc;
 }
 
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)
+{
+    libxl_ctx *ctx = gc->owner;
+    char *dev = NULL;
+    char *ret = NULL;
+    int rc;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
+                       disk->pdev_path);
+            dev = disk->pdev_path;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            switch (disk->format) {
+            case LIBXL_DISK_FORMAT_RAW:
+                /* optimise away the early tapdisk attach in this case */
+                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
+                           " tap disk %s directly (ie without using blktap)",
+                           disk->pdev_path);
+                dev = disk->pdev_path;
+                break;
+            case LIBXL_DISK_FORMAT_VHD:
+                dev = libxl__blktap_devpath(gc, disk->pdev_path,
+                                            disk->format);
+                break;
+            case LIBXL_DISK_FORMAT_QCOW:
+            case LIBXL_DISK_FORMAT_QCOW2:
+                abort(); /* prevented by libxl__device_disk_set_backend */
+            default:
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unrecognized disk format: %d", disk->format);
+                break;
+            }
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
+                           " attach a qdisk image if the format is not raw");
+                break;
+            }
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
+                       disk->pdev_path);
+            dev = disk->pdev_path;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
+                "type: %d", disk->backend);
+            break;
+    }
+
+ out:
+    if (dev != NULL)
+        ret = strdup(dev);
+    return ret;
+}
+
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
+{
+    /* Nothing to do for PHYSTYPE_PHY. */
+
+    /*
+     * For other device types assume that the blktap2 process is
+     * needed by the soon to be started domain and do nothing.
+     */
+
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..6927aef 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,15 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+/*
+ * Make a disk available in this (the control) domain. Returns path to
+ * a device.
+ */
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        libxl_device_disk *disk);
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk);
+
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAC-0000wL-5K; Tue, 24 Apr 2012 10:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAA-0000vG-2Y
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:02 +0000
Received: from [85.158.138.51:34673] by server-5.bemta-3.messagelabs.com id
	AB/7F-17113-103869F4; Tue, 24 Apr 2012 10:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335263997!23569859!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32285 invoked from network); 24 Apr 2012 10:40:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760377"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-Fl; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:51 +0100
Message-ID: <1335264358-20182-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 1/8] libxl: make
	libxl_device_disk_local_attach/detach internal functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c            |   73 ----------------------------------------
 tools/libxl/libxl.h            |    7 ----
 tools/libxl/libxl_bootloader.c |    4 +-
 tools/libxl/libxl_internal.c   |   72 +++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    9 +++++
 5 files changed, 83 insertions(+), 82 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 60dbfdc..e645d2a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1664,79 +1664,6 @@ out:
     return ret;
 }
 
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    char *dev = NULL;
-    char *ret = NULL;
-    int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
-    }
-
- out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    GC_FREE;
-    return ret;
-}
-
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
-{
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
-}
-
 /******************************************************************************/
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index edbca53..779c8dd 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -618,13 +618,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
  */
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk);
-int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
-
 /* Network Interfaces */
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..977c6d3 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -386,7 +386,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk);
     if (!diskpath) {
         goto out_close;
     }
@@ -453,7 +453,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     rc = 0;
 out_close:
     if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
+        libxl__device_disk_local_detach(gc, disk);
         free(diskpath);
     }
     if (fifo_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index b89aef7..1f428b2 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,78 @@ out:
     return rc;
 }
 
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)
+{
+    libxl_ctx *ctx = gc->owner;
+    char *dev = NULL;
+    char *ret = NULL;
+    int rc;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
+                       disk->pdev_path);
+            dev = disk->pdev_path;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            switch (disk->format) {
+            case LIBXL_DISK_FORMAT_RAW:
+                /* optimise away the early tapdisk attach in this case */
+                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
+                           " tap disk %s directly (ie without using blktap)",
+                           disk->pdev_path);
+                dev = disk->pdev_path;
+                break;
+            case LIBXL_DISK_FORMAT_VHD:
+                dev = libxl__blktap_devpath(gc, disk->pdev_path,
+                                            disk->format);
+                break;
+            case LIBXL_DISK_FORMAT_QCOW:
+            case LIBXL_DISK_FORMAT_QCOW2:
+                abort(); /* prevented by libxl__device_disk_set_backend */
+            default:
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unrecognized disk format: %d", disk->format);
+                break;
+            }
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
+                           " attach a qdisk image if the format is not raw");
+                break;
+            }
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
+                       disk->pdev_path);
+            dev = disk->pdev_path;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
+                "type: %d", disk->backend);
+            break;
+    }
+
+ out:
+    if (dev != NULL)
+        ret = strdup(dev);
+    return ret;
+}
+
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
+{
+    /* Nothing to do for PHYSTYPE_PHY. */
+
+    /*
+     * For other device types assume that the blktap2 process is
+     * needed by the soon to be started domain and do nothing.
+     */
+
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..6927aef 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,15 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+/*
+ * Make a disk available in this (the control) domain. Returns path to
+ * a device.
+ */
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        libxl_device_disk *disk);
+_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
+        libxl_device_disk *disk);
+
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAB-0000w7-Om; Tue, 24 Apr 2012 10:40:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdA9-0000uz-JV
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:01 +0000
Received: from [85.158.139.83:64326] by server-4.bemta-5.messagelabs.com id
	0D/B2-10788-103869F4; Tue, 24 Apr 2012 10:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263997!24701260!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24982 invoked from network); 24 Apr 2012 10:40:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466051"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:57 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-LV; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:57 +0100
Message-ID: <1335264358-20182-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 7/8] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Spawn a QEMU instance at boot time to handle disk local attach
requests.

- Implement libxl_device_disk_local_attach for QDISKs in terms of a
regular disk attach with the frontend and backend running in the same
domain.


Changes on v4:
- improve error handling and exit paths in libxl__device_disk_local_attach.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl_internal.c                    |   63 +++++++++++++++++++----
 tools/libxl/libxl_internal.h                    |    2 +
 4 files changed, 60 insertions(+), 11 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons
index 6543204..0f3b9ad 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -12,3 +12,6 @@
 
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
+
+# qemu path and log file
+#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 2f81ea2..9dda6e2 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -104,6 +104,9 @@ do_start () {
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
 	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting QEMU as disk backend for dom0
+	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ac73070..bb75491 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -510,6 +510,7 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
     int rc;
+    xs_transaction_t t = XBT_NULL;
     libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
     if (tmpdisk == NULL) goto out;
 
@@ -554,13 +555,40 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
+                do {
+                    t = xs_transaction_start(ctx->xsh);
+                    if (t == XBT_NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "failed to start a xenstore transaction");
+                        goto out;
+                    }
+                    tmpdisk->vdev = libxl__alloc_vdev(gc,
+                            LIBXL_TOOLSTACK_DOMID, blkdev_start, t);
+                    if (tmpdisk->vdev == NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl__alloc_vdev failed\n");
+                        goto out;
+                    }
+                    if (libxl__device_disk_add_t(gc, LIBXL_TOOLSTACK_DOMID,
+                                t, tmpdisk)) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl_device_disk_add failed\n");
+                        goto out;
+                    }
+                    rc = xs_transaction_end(ctx->xsh, t, 0);
+                } while (rc == 0 && errno == EAGAIN);
+                t = XBT_NULL;
+                if (rc == 0) {
+                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                            "xenstore transaction failed");
+                    goto out;
+                }
+                dev = GCSPRINTF("/dev/%s", tmpdisk->vdev);
+            } else {
+                dev = tmpdisk->pdev_path;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = tmpdisk->pdev_path;
+                       dev);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
@@ -569,17 +597,30 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
     }
 
  out:
+    if (t != XBT_NULL)
+        xs_transaction_end(ctx->xsh, t, 1);
     return dev;
 }
 
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->vdev != NULL) {
+                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
+                        disk, 0);
+                return libxl_device_disk_destroy(gc->owner,
+                        LIBXL_TOOLSTACK_DOMID, disk);
+            }
+            break;
+        default:
+            /*
+             * Nothing to do for PHYSTYPE_PHY.
+             * For other device types assume that the blktap2 process is
+             * needed by the soon to be started domain and do nothing.
+             */
+            break;
+    }
 
     return 0;
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ed145ab..dfd7b49 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -77,6 +77,8 @@
 #define LIBXL_PV_EXTRA_MEMORY 1024
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
+/* use 0 as the domid of the toolstack domain for now */
+#define LIBXL_TOOLSTACK_DOMID 0
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAB-0000w7-Om; Tue, 24 Apr 2012 10:40:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdA9-0000uz-JV
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:01 +0000
Received: from [85.158.139.83:64326] by server-4.bemta-5.messagelabs.com id
	0D/B2-10788-103869F4; Tue, 24 Apr 2012 10:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263997!24701260!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24982 invoked from network); 24 Apr 2012 10:40:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466051"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:57 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-LV; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:57 +0100
Message-ID: <1335264358-20182-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 7/8] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Spawn a QEMU instance at boot time to handle disk local attach
requests.

- Implement libxl_device_disk_local_attach for QDISKs in terms of a
regular disk attach with the frontend and backend running in the same
domain.


Changes on v4:
- improve error handling and exit paths in libxl__device_disk_local_attach.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons |    3 +
 tools/hotplug/Linux/init.d/xencommons           |    3 +
 tools/libxl/libxl_internal.c                    |   63 +++++++++++++++++++----
 tools/libxl/libxl_internal.h                    |    2 +
 4 files changed, 60 insertions(+), 11 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons
index 6543204..0f3b9ad 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -12,3 +12,6 @@
 
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
+
+# qemu path and log file
+#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 2f81ea2..9dda6e2 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -104,6 +104,9 @@ do_start () {
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
 	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting QEMU as disk backend for dom0
+	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ac73070..bb75491 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -510,6 +510,7 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
     int rc;
+    xs_transaction_t t = XBT_NULL;
     libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
     if (tmpdisk == NULL) goto out;
 
@@ -554,13 +555,40 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
+                do {
+                    t = xs_transaction_start(ctx->xsh);
+                    if (t == XBT_NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "failed to start a xenstore transaction");
+                        goto out;
+                    }
+                    tmpdisk->vdev = libxl__alloc_vdev(gc,
+                            LIBXL_TOOLSTACK_DOMID, blkdev_start, t);
+                    if (tmpdisk->vdev == NULL) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl__alloc_vdev failed\n");
+                        goto out;
+                    }
+                    if (libxl__device_disk_add_t(gc, LIBXL_TOOLSTACK_DOMID,
+                                t, tmpdisk)) {
+                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                                "libxl_device_disk_add failed\n");
+                        goto out;
+                    }
+                    rc = xs_transaction_end(ctx->xsh, t, 0);
+                } while (rc == 0 && errno == EAGAIN);
+                t = XBT_NULL;
+                if (rc == 0) {
+                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                            "xenstore transaction failed");
+                    goto out;
+                }
+                dev = GCSPRINTF("/dev/%s", tmpdisk->vdev);
+            } else {
+                dev = tmpdisk->pdev_path;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = tmpdisk->pdev_path;
+                       dev);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
@@ -569,17 +597,30 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
     }
 
  out:
+    if (t != XBT_NULL)
+        xs_transaction_end(ctx->xsh, t, 1);
     return dev;
 }
 
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_QDISK:
+            if (disk->vdev != NULL) {
+                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
+                        disk, 0);
+                return libxl_device_disk_destroy(gc->owner,
+                        LIBXL_TOOLSTACK_DOMID, disk);
+            }
+            break;
+        default:
+            /*
+             * Nothing to do for PHYSTYPE_PHY.
+             * For other device types assume that the blktap2 process is
+             * needed by the soon to be started domain and do nothing.
+             */
+            break;
+    }
 
     return 0;
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ed145ab..dfd7b49 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -77,6 +77,8 @@
 #define LIBXL_PV_EXTRA_MEMORY 1024
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
+/* use 0 as the domid of the toolstack domain for now */
+#define LIBXL_TOOLSTACK_DOMID 0
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdA9-0000vR-Uo; Tue, 24 Apr 2012 10:40:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdA8-0000uz-Gx
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:00 +0000
Received: from [85.158.139.83:64209] by server-4.bemta-5.messagelabs.com id
	DF/A2-10788-FF2869F4; Tue, 24 Apr 2012 10:39:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263997!24701260!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24886 invoked from network); 24 Apr 2012 10:39:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466049"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:57 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-Ky; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:56 +0100
Message-ID: <1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__alloc_vdev: find a spare virtual block device in the
domain passed as argument.

Changes in v4:
- rename libxl__devid_to_vdev to libxl__devid_to_localdev;
- introduce upper bound for encode_disk_name;
- better error handling;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   22 ++++++++++++++++++++
 tools/libxl/libxl_internal.h |    2 +
 tools/libxl/libxl_linux.c    |   45 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   |    6 +++++
 4 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index f467572..ac73070 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -480,6 +480,28 @@ out:
     return rc;
 }
 
+static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
+        char *blkdev_start, xs_transaction_t t)
+{
+    int devid = 0;
+    char *vdev = libxl__strdup(gc, blkdev_start);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
+
+    do {
+        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
+        if (libxl__xs_read(gc, t,
+                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
+                        dompath, devid)) == NULL) {
+            if (errno == ENOENT)
+                return libxl__devid_to_localdev(gc, devid);
+            else
+                return NULL;
+        }
+        vdev[strlen(vdev) - 1]++;
+    } while (vdev[strlen(vdev) - 1] <= 'z');
+    return NULL;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 97775fb..ed145ab 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -761,6 +761,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+_hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..cb596a9 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,48 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+#define EXT_SHIFT 28
+#define EXTENDED (1<<EXT_SHIFT)
+#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED))
+#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
+
+/* same as in Linux */
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+    if (n >= 26)
+        ptr = encode_disk_name(ptr, n / 26 - 1);
+    *ptr = 'a' + n % 26;
+    return ptr + 1;
+}
+
+char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
+{
+    int minor;
+    int offset;
+    int nr_parts;
+    char *ptr = NULL;
+    char *ret = libxl__zalloc(gc, 32);
+
+    if (!VDEV_IS_EXTENDED(devid)) {
+        minor = devid & 0xff;
+        nr_parts = 16;
+    } else {
+        minor = BLKIF_MINOR_EXT(devid);
+        nr_parts = 256;
+    }
+    offset = minor / nr_parts;
+
+	/* arbitrary upper bound */
+	if (offset > 676)
+		return NULL;
+
+    strcpy(ret, "xvd");
+    ptr = encode_disk_name(ret + 3, offset);
+    if (minor % nr_parts == 0)
+        *ptr = 0;
+    else
+        snprintf(ptr, ret + 32 - ptr,
+                "%d", minor & (nr_parts - 1));
+    return ret;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 9e0ed6d..dbf5f71 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 0;
 }
+
+char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
+{
+    /* TODO */
+    return NULL;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdA9-0000vR-Uo; Tue, 24 Apr 2012 10:40:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdA8-0000uz-Gx
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:00 +0000
Received: from [85.158.139.83:64209] by server-4.bemta-5.messagelabs.com id
	DF/A2-10788-FF2869F4; Tue, 24 Apr 2012 10:39:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263997!24701260!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24886 invoked from network); 24 Apr 2012 10:39:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466049"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:57 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-Ky; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:56 +0100
Message-ID: <1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__alloc_vdev: find a spare virtual block device in the
domain passed as argument.

Changes in v4:
- rename libxl__devid_to_vdev to libxl__devid_to_localdev;
- introduce upper bound for encode_disk_name;
- better error handling;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   22 ++++++++++++++++++++
 tools/libxl/libxl_internal.h |    2 +
 tools/libxl/libxl_linux.c    |   45 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   |    6 +++++
 4 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index f467572..ac73070 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -480,6 +480,28 @@ out:
     return rc;
 }
 
+static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
+        char *blkdev_start, xs_transaction_t t)
+{
+    int devid = 0;
+    char *vdev = libxl__strdup(gc, blkdev_start);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
+
+    do {
+        devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
+        if (libxl__xs_read(gc, t,
+                    libxl__sprintf(gc, "%s/device/vbd/%d/backend",
+                        dompath, devid)) == NULL) {
+            if (errno == ENOENT)
+                return libxl__devid_to_localdev(gc, devid);
+            else
+                return NULL;
+        }
+        vdev[strlen(vdev) - 1]++;
+    } while (vdev[strlen(vdev) - 1] <= 'z');
+    return NULL;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 97775fb..ed145ab 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -761,6 +761,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+_hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 925248b..cb596a9 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -25,3 +25,48 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 1;
 }
+
+#define EXT_SHIFT 28
+#define EXTENDED (1<<EXT_SHIFT)
+#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED))
+#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
+
+/* same as in Linux */
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+    if (n >= 26)
+        ptr = encode_disk_name(ptr, n / 26 - 1);
+    *ptr = 'a' + n % 26;
+    return ptr + 1;
+}
+
+char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
+{
+    int minor;
+    int offset;
+    int nr_parts;
+    char *ptr = NULL;
+    char *ret = libxl__zalloc(gc, 32);
+
+    if (!VDEV_IS_EXTENDED(devid)) {
+        minor = devid & 0xff;
+        nr_parts = 16;
+    } else {
+        minor = BLKIF_MINOR_EXT(devid);
+        nr_parts = 256;
+    }
+    offset = minor / nr_parts;
+
+	/* arbitrary upper bound */
+	if (offset > 676)
+		return NULL;
+
+    strcpy(ret, "xvd");
+    ptr = encode_disk_name(ret + 3, offset);
+    if (minor % nr_parts == 0)
+        *ptr = 0;
+    else
+        snprintf(ptr, ret + 32 - ptr,
+                "%d", minor & (nr_parts - 1));
+    return ret;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 9e0ed6d..dbf5f71 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode)
 
     return 0;
 }
+
+char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
+{
+    /* TODO */
+    return NULL;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAE-0000xl-Oe; Tue, 24 Apr 2012 10:40:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAA-0000vX-Mf
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:03 +0000
Received: from [85.158.138.51:32930] by server-12.bemta-3.messagelabs.com id
	00/DF-29760-103869F4; Tue, 24 Apr 2012 10:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335263997!23569859!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32412 invoked from network); 24 Apr 2012 10:40:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760378"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:57 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-JG; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:55 +0100
Message-ID: <1335264358-20182-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 5/8] xl/libxl: add a blkdev_start parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a blkdev_start in xl.conf and a corresponding string in
libxl_domain_build_info.

blkdev_start specifies the first block device to be used for temporary
block device allocations by the toolstack.

Changes in v4:
- pass blkdev_start in libxl_domain_build_info.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/examples/xl.conf         |    3 +++
 tools/libxl/libxl_bootloader.c |    3 ++-
 tools/libxl/libxl_create.c     |    3 +++
 tools/libxl/libxl_internal.c   |    3 ++-
 tools/libxl/libxl_internal.h   |    3 ++-
 tools/libxl/libxl_types.idl    |    1 +
 tools/libxl/xl.c               |    3 +++
 tools/libxl/xl.h               |    1 +
 tools/libxl/xl_cmdimpl.c       |    2 ++
 9 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..ebf057c 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# first block device to be used for temporary VM disk mounts
+#blkdev_start="xvda"
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 83cac78..123b06e 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -387,7 +387,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk,
+            info->blkdev_start);
     if (!diskpath) {
         rc = ERROR_FAIL;
         goto out_close;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f9c2a76..5b97047 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -100,6 +100,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
+    if (b_info->blkdev_start == NULL)
+        b_info->blkdev_start = strdup("xvda");
+
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
             switch (b_info->device_model_version) {
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index f348529..f467572 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -482,7 +482,8 @@ out:
 
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk)
+        libxl_device_disk **new_disk,
+        char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2708cc5..97775fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1013,7 +1013,8 @@ _hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk);
+        libxl_device_disk **new_disk,
+        char *blkdev_start);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..24d2322 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -242,6 +242,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
+    ("blkdev_start",    string),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..4596c4f 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+char *blkdev_start;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile,
             fprintf(stderr, "invalid default output format \"%s\"\n", buf);
         }
     }
+    if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0))
+        blkdev_start = strdup(buf);
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..dba2c94 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -113,6 +113,7 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 extern char *default_bridge;
+extern char *blkdev_start;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..12a0934 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -585,6 +585,8 @@ static void parse_config_data(const char *configfile_filename_report,
 
     libxl_domain_build_info_init(b_info);
     libxl_domain_build_info_init_type(b_info, c_info->type);
+    if (blkdev_start)
+        b_info->blkdev_start = strdup(blkdev_start);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAE-0000xl-Oe; Tue, 24 Apr 2012 10:40:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAA-0000vX-Mf
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:03 +0000
Received: from [85.158.138.51:32930] by server-12.bemta-3.messagelabs.com id
	00/DF-29760-103869F4; Tue, 24 Apr 2012 10:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335263997!23569859!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32412 invoked from network); 24 Apr 2012 10:40:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760378"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:57 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-JG; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:55 +0100
Message-ID: <1335264358-20182-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 5/8] xl/libxl: add a blkdev_start parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a blkdev_start in xl.conf and a corresponding string in
libxl_domain_build_info.

blkdev_start specifies the first block device to be used for temporary
block device allocations by the toolstack.

Changes in v4:
- pass blkdev_start in libxl_domain_build_info.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/examples/xl.conf         |    3 +++
 tools/libxl/libxl_bootloader.c |    3 ++-
 tools/libxl/libxl_create.c     |    3 +++
 tools/libxl/libxl_internal.c   |    3 ++-
 tools/libxl/libxl_internal.h   |    3 ++-
 tools/libxl/libxl_types.idl    |    1 +
 tools/libxl/xl.c               |    3 +++
 tools/libxl/xl.h               |    1 +
 tools/libxl/xl_cmdimpl.c       |    2 ++
 9 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 56d3b3b..ebf057c 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -12,3 +12,6 @@
 
 # default output format used by "xl list -l"
 #output_format="json"
+
+# first block device to be used for temporary VM disk mounts
+#blkdev_start="xvda"
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 83cac78..123b06e 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -387,7 +387,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk,
+            info->blkdev_start);
     if (!diskpath) {
         rc = ERROR_FAIL;
         goto out_close;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f9c2a76..5b97047 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -100,6 +100,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
     }
 
+    if (b_info->blkdev_start == NULL)
+        b_info->blkdev_start = strdup("xvda");
+
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
             switch (b_info->device_model_version) {
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index f348529..f467572 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -482,7 +482,8 @@ out:
 
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk)
+        libxl_device_disk **new_disk,
+        char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2708cc5..97775fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1013,7 +1013,8 @@ _hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
-        libxl_device_disk **new_disk);
+        libxl_device_disk **new_disk,
+        char *blkdev_start);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..24d2322 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -242,6 +242,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
+    ("blkdev_start",    string),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..4596c4f 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -35,6 +35,7 @@
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
 int autoballoon = 1;
+char *blkdev_start;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile,
             fprintf(stderr, "invalid default output format \"%s\"\n", buf);
         }
     }
+    if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0))
+        blkdev_start = strdup(buf);
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..dba2c94 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -113,6 +113,7 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 extern char *default_bridge;
+extern char *blkdev_start;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c9e9943..12a0934 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -585,6 +585,8 @@ static void parse_config_data(const char *configfile_filename_report,
 
     libxl_domain_build_info_init(b_info);
     libxl_domain_build_info_init_type(b_info, c_info->type);
+    if (blkdev_start)
+        b_info->blkdev_start = strdup(blkdev_start);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAF-0000y4-58; Tue, 24 Apr 2012 10:40:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAB-0000vz-Pg
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:04 +0000
Received: from [85.158.139.83:64485] by server-7.bemta-5.messagelabs.com id
	A1/D3-16195-303869F4; Tue, 24 Apr 2012 10:40:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335264000!25223855!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25790 invoked from network); 24 Apr 2012 10:40:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760379"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-GM; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:52 +0100
Message-ID: <1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 2/8] libxl: libxl__device_disk_local_attach
	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new libxl_device_disk** parameter to
libxl__device_disk_local_attach, the parameter is allocated on the gc by
libxl__device_disk_local_attach. It is going to fill it with
informations about the new locally attached disk.  The new
libxl_device_disk should be passed to libxl_device_disk_local_detach
afterwards.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_bootloader.c |   10 ++++----
 tools/libxl/libxl_internal.c   |   47 +++++++++++++++++++++++----------------
 tools/libxl/libxl_internal.h   |    3 +-
 3 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 977c6d3..83cac78 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    libxl_device_disk *tmpdisk = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
     if (!diskpath) {
+        rc = ERROR_FAIL;
         goto out_close;
     }
 
@@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     rc = 0;
 out_close:
-    if (diskpath) {
-        libxl__device_disk_local_detach(gc, disk);
-        free(diskpath);
-    }
+    if (tmpdisk)
+        libxl__device_disk_local_detach(gc, tmpdisk);
     if (fifo_fd > -1)
         close(fifo_fd);
     if (bootloader_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 1f428b2..3af77e7 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,64 +323,73 @@ out:
     return rc;
 }
 
-_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
-    char *ret = NULL;
     int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
+    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
+    if (tmpdisk == NULL) goto out;
+
+    *new_disk = tmpdisk;
+    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));
+    if (disk->pdev_path != NULL)
+        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
+    if (disk->script != NULL)
+        tmpdisk->script = libxl__strdup(gc, disk->script);
+    tmpdisk->vdev = NULL;
+
+    rc = libxl__device_disk_setdefault(gc, tmpdisk);
     if (rc) goto out;
 
-    switch (disk->backend) {
+    switch (tmpdisk->backend) {
         case LIBXL_DISK_BACKEND_PHY:
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
+                       tmpdisk->pdev_path);
+            dev = tmpdisk->pdev_path;
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
+            switch (tmpdisk->format) {
             case LIBXL_DISK_FORMAT_RAW:
                 /* optimise away the early tapdisk attach in this case */
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
                            " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
+                           tmpdisk->pdev_path);
+                dev = tmpdisk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
+                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
+                                            tmpdisk->format);
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
             case LIBXL_DISK_FORMAT_QCOW2:
                 abort(); /* prevented by libxl__device_disk_set_backend */
             default:
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
+                           "unrecognized disk format: %d", tmpdisk->format);
                 break;
             }
             break;
         case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
                            " attach a qdisk image if the format is not raw");
                 break;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
                        disk->pdev_path);
-            dev = disk->pdev_path;
+            dev = tmpdisk->pdev_path;
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
+                "type: %d", tmpdisk->backend);
             break;
     }
 
  out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    return ret;
+    return dev;
 }
 
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6927aef..2f1cf0f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1006,7 +1006,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
  * a device.
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
-        libxl_device_disk *disk);
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAF-0000y4-58; Tue, 24 Apr 2012 10:40:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAB-0000vz-Pg
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:04 +0000
Received: from [85.158.139.83:64485] by server-7.bemta-5.messagelabs.com id
	A1/D3-16195-303869F4; Tue, 24 Apr 2012 10:40:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335264000!25223855!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25790 invoked from network); 24 Apr 2012 10:40:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="191760379"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-GM; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:52 +0100
Message-ID: <1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 2/8] libxl: libxl__device_disk_local_attach
	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new libxl_device_disk** parameter to
libxl__device_disk_local_attach, the parameter is allocated on the gc by
libxl__device_disk_local_attach. It is going to fill it with
informations about the new locally attached disk.  The new
libxl_device_disk should be passed to libxl_device_disk_local_detach
afterwards.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_bootloader.c |   10 ++++----
 tools/libxl/libxl_internal.c   |   47 +++++++++++++++++++++++----------------
 tools/libxl/libxl_internal.h   |    3 +-
 3 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 977c6d3..83cac78 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    libxl_device_disk *tmpdisk = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    diskpath = libxl__device_disk_local_attach(gc, disk);
+    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
     if (!diskpath) {
+        rc = ERROR_FAIL;
         goto out_close;
     }
 
@@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     rc = 0;
 out_close:
-    if (diskpath) {
-        libxl__device_disk_local_detach(gc, disk);
-        free(diskpath);
-    }
+    if (tmpdisk)
+        libxl__device_disk_local_detach(gc, tmpdisk);
     if (fifo_fd > -1)
         close(fifo_fd);
     if (bootloader_fd > -1)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 1f428b2..3af77e7 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,64 +323,73 @@ out:
     return rc;
 }
 
-_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)
+_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk)
 {
     libxl_ctx *ctx = gc->owner;
     char *dev = NULL;
-    char *ret = NULL;
     int rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
+    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
+    if (tmpdisk == NULL) goto out;
+
+    *new_disk = tmpdisk;
+    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));
+    if (disk->pdev_path != NULL)
+        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
+    if (disk->script != NULL)
+        tmpdisk->script = libxl__strdup(gc, disk->script);
+    tmpdisk->vdev = NULL;
+
+    rc = libxl__device_disk_setdefault(gc, tmpdisk);
     if (rc) goto out;
 
-    switch (disk->backend) {
+    switch (tmpdisk->backend) {
         case LIBXL_DISK_BACKEND_PHY:
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
+                       tmpdisk->pdev_path);
+            dev = tmpdisk->pdev_path;
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
+            switch (tmpdisk->format) {
             case LIBXL_DISK_FORMAT_RAW:
                 /* optimise away the early tapdisk attach in this case */
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
                            " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
+                           tmpdisk->pdev_path);
+                dev = tmpdisk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
+                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
+                                            tmpdisk->format);
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
             case LIBXL_DISK_FORMAT_QCOW2:
                 abort(); /* prevented by libxl__device_disk_set_backend */
             default:
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
+                           "unrecognized disk format: %d", tmpdisk->format);
                 break;
             }
             break;
         case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
+            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
                            " attach a qdisk image if the format is not raw");
                 break;
             }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
                        disk->pdev_path);
-            dev = disk->pdev_path;
+            dev = tmpdisk->pdev_path;
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
+                "type: %d", tmpdisk->backend);
             break;
     }
 
  out:
-    if (dev != NULL)
-        ret = strdup(dev);
-    return ret;
+    return dev;
 }
 
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6927aef..2f1cf0f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1006,7 +1006,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
  * a device.
  */
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
-        libxl_device_disk *disk);
+        const libxl_device_disk *disk,
+        libxl_device_disk **new_disk);
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
         libxl_device_disk *disk);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAF-0000yL-JL; Tue, 24 Apr 2012 10:40:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAB-0000v7-SV
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:04 +0000
Received: from [85.158.139.83:9432] by server-9.bemta-5.messagelabs.com id
	36/3B-09826-003869F4; Tue, 24 Apr 2012 10:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263997!24701260!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24917 invoked from network); 24 Apr 2012 10:39:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466050"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-Ih; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:54 +0100
Message-ID: <1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__device_disk_add_t that takes an additional
xs_transaction_t paramter.
Implement libxl_device_disk_add using libxl__device_disk_add_t.
Move libxl__device_from_disk to libxl_internal.c.
No functional change.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |  151 +----------------------------------------
 tools/libxl/libxl_internal.c |  157 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++
 3 files changed, 164 insertions(+), 150 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 85082eb..0d7c0f6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
-    flexarray_t *front;
-    flexarray_t *back;
-    char *dev;
-    libxl__device device;
-    int major, minor, rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
-
-    if (disk->script) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
-                   " not yet supported, sorry");
-        rc = ERROR_INVAL;
-        goto out_free;
-    }
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        goto out_free;
-    }
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            dev = disk->pdev_path;
-    do_backend_phy:
-            libxl__device_physdisk_major_minor(dev, &major, &minor);
-            flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
-
-            flexarray_append(back, "params");
-            flexarray_append(back, dev);
-
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-            if (!dev) {
-                rc = ERROR_FAIL;
-                goto out_free;
-            }
-            flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                libxl__device_disk_string_of_format(disk->format),
-                disk->pdev_path));
-
-            /* now create a phy device to export the device to the guest */
-            goto do_backend_phy;
-        case LIBXL_DISK_BACKEND_QDISK:
-            flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
-            rc = ERROR_INVAL;
-            goto out_free;
-    }
-
-    flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
-    flexarray_append(back, "online");
-    flexarray_append(back, "1");
-    flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
-    flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "dev");
-    flexarray_append(back, disk->vdev);
-    flexarray_append(back, "type");
-    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
-    flexarray_append(back, "mode");
-    flexarray_append(back, disk->readwrite ? "w" : "r");
-    flexarray_append(back, "device-type");
-    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
-
-    flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
-    flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
-    flexarray_append(front, "device-type");
-    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
-
-    libxl__device_generic_add(gc, XBT_NULL, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
-
-    rc = 0;
-
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
-out:
+    int rc = libxl__device_disk_add_t(gc, domid, XBT_NULL, disk);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 3af77e7..f348529 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,163 @@ out:
     return rc;
 }
 
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    char *dev;
+    libxl__device device;
+    int major, minor, rc;
+    libxl_ctx *ctx = gc->owner;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out_free;
+    }
+
+    if (disk->script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
+                   " not yet supported, sorry");
+        rc = ERROR_INVAL;
+        goto out_free;
+    }
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        goto out_free;
+    }
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            dev = disk->pdev_path;
+    do_backend_phy:
+            libxl__device_physdisk_major_minor(dev, &major, &minor);
+            flexarray_append(back, "physical-device");
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
+
+            flexarray_append(back, "params");
+            flexarray_append(back, dev);
+
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+            if (!dev) {
+                rc = ERROR_FAIL;
+                goto out_free;
+            }
+            flexarray_append(back, "tapdisk-params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                libxl__device_disk_string_of_format(disk->format),
+                disk->pdev_path));
+
+            /* now create a phy device to export the device to the guest */
+            goto do_backend_phy;
+        case LIBXL_DISK_BACKEND_QDISK:
+            flexarray_append(back, "params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
+            rc = ERROR_INVAL;
+            goto out_free;
+    }
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "removable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, "bootable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "dev");
+    flexarray_append(back, disk->vdev);
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
+    flexarray_append(back, "mode");
+    flexarray_append(back, disk->readwrite ? "w" : "r");
+    flexarray_append(back, "device-type");
+    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "virtual-device");
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, "device-type");
+    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
+
+    libxl__device_generic_add(gc, t, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+
+    rc = 0;
+
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    return rc;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 00856e0..2708cc5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device);
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk);
 /*
  * Make a disk available in this (the control) domain. Returns path to
  * a device.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAF-0000yL-JL; Tue, 24 Apr 2012 10:40:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAB-0000v7-SV
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:04 +0000
Received: from [85.158.139.83:9432] by server-9.bemta-5.messagelabs.com id
	36/3B-09826-003869F4; Tue, 24 Apr 2012 10:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335263997!24701260!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24917 invoked from network); 24 Apr 2012 10:39:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466050"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:39:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:39:56 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-Ih; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:54 +0100
Message-ID: <1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce libxl__device_disk_add_t that takes an additional
xs_transaction_t paramter.
Implement libxl_device_disk_add using libxl__device_disk_add_t.
Move libxl__device_from_disk to libxl_internal.c.
No functional change.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl.c          |  151 +----------------------------------------
 tools/libxl/libxl_internal.c |  157 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++
 3 files changed, 164 insertions(+), 150 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 85082eb..0d7c0f6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
     return rc;
 }
 
-static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
-                                   libxl_device_disk *disk,
-                                   libxl__device *device)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int devid;
-
-    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
-    if (devid==-1) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        return ERROR_INVAL;
-    }
-
-    device->backend_domid = disk->backend_domid;
-    device->backend_devid = devid;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
-                       disk->backend);
-            return ERROR_INVAL;
-    }
-
-    device->domid = domid;
-    device->devid = devid;
-    device->kind  = LIBXL__DEVICE_KIND_VBD;
-
-    return 0;
-}
-
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
-    flexarray_t *front;
-    flexarray_t *back;
-    char *dev;
-    libxl__device device;
-    int major, minor, rc;
-
-    rc = libxl__device_disk_setdefault(gc, disk);
-    if (rc) goto out;
-
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
-
-    if (disk->script) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
-                   " not yet supported, sorry");
-        rc = ERROR_INVAL;
-        goto out_free;
-    }
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
-               " virtual disk identifier %s", disk->vdev);
-        goto out_free;
-    }
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            dev = disk->pdev_path;
-    do_backend_phy:
-            libxl__device_physdisk_major_minor(dev, &major, &minor);
-            flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
-
-            flexarray_append(back, "params");
-            flexarray_append(back, dev);
-
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-            if (!dev) {
-                rc = ERROR_FAIL;
-                goto out_free;
-            }
-            flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                libxl__device_disk_string_of_format(disk->format),
-                disk->pdev_path));
-
-            /* now create a phy device to export the device to the guest */
-            goto do_backend_phy;
-        case LIBXL_DISK_BACKEND_QDISK:
-            flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
-                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
-            rc = ERROR_INVAL;
-            goto out_free;
-    }
-
-    flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
-    flexarray_append(back, "online");
-    flexarray_append(back, "1");
-    flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
-    flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(back, "dev");
-    flexarray_append(back, disk->vdev);
-    flexarray_append(back, "type");
-    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
-    flexarray_append(back, "mode");
-    flexarray_append(back, disk->readwrite ? "w" : "r");
-    flexarray_append(back, "device-type");
-    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
-
-    flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
-    flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
-    flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
-    flexarray_append(front, "device-type");
-    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
-
-    libxl__device_generic_add(gc, XBT_NULL, &device,
-                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
-
-    rc = 0;
-
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
-out:
+    int rc = libxl__device_disk_add_t(gc, domid, XBT_NULL, disk);
     GC_FREE;
     return rc;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 3af77e7..f348529 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -323,6 +323,163 @@ out:
     return rc;
 }
 
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int devid;
+
+    devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+    if (devid==-1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        return ERROR_INVAL;
+    }
+
+    device->backend_domid = disk->backend_domid;
+    device->backend_devid = devid;
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            break;
+        case LIBXL_DISK_BACKEND_QDISK:
+            device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
+                       disk->backend);
+            return ERROR_INVAL;
+    }
+
+    device->domid = domid;
+    device->devid = devid;
+    device->kind  = LIBXL__DEVICE_KIND_VBD;
+
+    return 0;
+}
+
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    char *dev;
+    libxl__device device;
+    int major, minor, rc;
+    libxl_ctx *ctx = gc->owner;
+
+    rc = libxl__device_disk_setdefault(gc, disk);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out_free;
+    }
+
+    if (disk->script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
+                   " not yet supported, sorry");
+        rc = ERROR_INVAL;
+        goto out_free;
+    }
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
+               " virtual disk identifier %s", disk->vdev);
+        goto out_free;
+    }
+
+    switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
+            dev = disk->pdev_path;
+    do_backend_phy:
+            libxl__device_physdisk_major_minor(dev, &major, &minor);
+            flexarray_append(back, "physical-device");
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
+
+            flexarray_append(back, "params");
+            flexarray_append(back, dev);
+
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            break;
+        case LIBXL_DISK_BACKEND_TAP:
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+            if (!dev) {
+                rc = ERROR_FAIL;
+                goto out_free;
+            }
+            flexarray_append(back, "tapdisk-params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                libxl__device_disk_string_of_format(disk->format),
+                disk->pdev_path));
+
+            /* now create a phy device to export the device to the guest */
+            goto do_backend_phy;
+        case LIBXL_DISK_BACKEND_QDISK:
+            flexarray_append(back, "params");
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                          libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
+            rc = ERROR_INVAL;
+            goto out_free;
+    }
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "removable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, "bootable");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(back, "dev");
+    flexarray_append(back, disk->vdev);
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend));
+    flexarray_append(back, "mode");
+    flexarray_append(back, disk->readwrite ? "w" : "r");
+    flexarray_append(back, "device-type");
+    flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "virtual-device");
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, "device-type");
+    flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
+
+    libxl__device_generic_add(gc, t, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
+
+    rc = 0;
+
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    return rc;
+}
+
 _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         const libxl_device_disk *disk,
         libxl_device_disk **new_disk)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 00856e0..2708cc5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1001,6 +1001,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc,
  */
 _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 
+
+_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_disk *disk,
+                                   libxl__device *device);
+_hidden int libxl__device_disk_add_t(libxl__gc *gc, uint32_t domid,
+        xs_transaction_t t, libxl_device_disk *disk);
 /*
  * Make a disk available in this (the control) domain. Returns path to
  * a device.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAF-0000ye-VT; Tue, 24 Apr 2012 10:40:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAD-0000wy-Ex
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:05 +0000
Received: from [85.158.139.83:64702] by server-2.bemta-5.messagelabs.com id
	D1/52-17016-403869F4; Tue, 24 Apr 2012 10:40:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335264002!21356094!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18183 invoked from network); 24 Apr 2012 10:40:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466059"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:40:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:40:02 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-NL; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:58 +0100
Message-ID: <1335264358-20182-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 8/8] libxl__device_disk_local_attach: wait
	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to make sure that the block device is available and ready to be
used, wait for state "connected" in the backend before returning.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Changes in v4:
- improve exit paths.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index bb75491..98a67d6 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -508,8 +508,9 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
-    char *dev = NULL;
+    char *dev = NULL, *be_path = NULL;
     int rc;
+    libxl__device device;
     xs_transaction_t t = XBT_NULL;
     libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
     if (tmpdisk == NULL) goto out;
@@ -596,10 +597,23 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
     }
 
+    if (tmpdisk->vdev != NULL) {
+        rc = libxl__device_from_disk(gc, 0, tmpdisk, &device);
+        if (rc < 0)
+            goto out_wait_err;
+        be_path = libxl__device_backend_path(gc, &device);
+        rc = libxl__wait_for_backend(gc, be_path, "4");
+        if (rc < 0)
+            goto out_wait_err;
+    }
+
  out:
     if (t != XBT_NULL)
         xs_transaction_end(ctx->xsh, t, 1);
     return dev;
+ out_wait_err:
+    libxl__device_disk_local_detach(gc, tmpdisk);
+    return NULL;
 }
 
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:40:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdAF-0000ye-VT; Tue, 24 Apr 2012 10:40:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdAD-0000wy-Ex
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:40:05 +0000
Received: from [85.158.139.83:64702] by server-2.bemta-5.messagelabs.com id
	D1/52-17016-403869F4; Tue, 24 Apr 2012 10:40:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335264002!21356094!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18183 invoked from network); 24 Apr 2012 10:40:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:40:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466059"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 06:40:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 06:40:02 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMd9z-0001Te-NL; Tue, 24 Apr 2012 11:39:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 11:45:58 +0100
Message-ID: <1335264358-20182-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 8/8] libxl__device_disk_local_attach: wait
	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to make sure that the block device is available and ready to be
used, wait for state "connected" in the backend before returning.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Changes in v4:
- improve exit paths.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index bb75491..98a67d6 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -508,8 +508,9 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
         char *blkdev_start)
 {
     libxl_ctx *ctx = gc->owner;
-    char *dev = NULL;
+    char *dev = NULL, *be_path = NULL;
     int rc;
+    libxl__device device;
     xs_transaction_t t = XBT_NULL;
     libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
     if (tmpdisk == NULL) goto out;
@@ -596,10 +597,23 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
             break;
     }
 
+    if (tmpdisk->vdev != NULL) {
+        rc = libxl__device_from_disk(gc, 0, tmpdisk, &device);
+        if (rc < 0)
+            goto out_wait_err;
+        be_path = libxl__device_backend_path(gc, &device);
+        rc = libxl__wait_for_backend(gc, be_path, "4");
+        if (rc < 0)
+            goto out_wait_err;
+    }
+
  out:
     if (t != XBT_NULL)
         xs_transaction_end(ctx->xsh, t, 1);
     return dev;
+ out_wait_err:
+    libxl__device_disk_local_detach(gc, tmpdisk);
+    return NULL;
 }
 
 _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:50:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdJw-0002Zj-VF; Tue, 24 Apr 2012 10:50:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdJu-0002Ze-R4
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:50:07 +0000
Received: from [85.158.143.99:27728] by server-2.bemta-4.messagelabs.com id
	56/8A-17550-E55869F4; Tue, 24 Apr 2012 10:50:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335264596!13816150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18998 invoked from network); 24 Apr 2012 10:50:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:50:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:49:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:49:50 +0100
Date: Tue, 24 Apr 2012 11:55:43 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120417144318.GA28477@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204241153380.26786@kaball-desktop>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
	<20120417144318.GA28477@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4] xen: enter/exit lazy_mmu_mode around
	m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.

Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL.  Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
going to be batched together, otherwise they are issued one at a time.

Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
m2p_add/remove_override calls forces paravirt_lazy_mode to
PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.

However it is not safe to call arch_enter_lazy_mmu_mode if we are in
interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
check for both conditions before doing so.

Changes in v4:
- rebased on 3.4-rc4: all the m2p_override users call gnttab_unmap_refs
and gnttab_map_refs;
- check whether we are in interrupt context and the lazy_mode we are in
before calling arch_enter/leave_lazy_mmu_mode.

Changes in v3:
- do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
can be called in interrupt context.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index e570c6f..a18a3e8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -38,6 +38,7 @@
 #include <linux/vmalloc.h>
 #include <linux/uaccess.h>
 #include <linux/io.h>
+#include <linux/hardirq.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -826,7 +827,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 	pte_t *pte;
 	unsigned long mfn;
 
@@ -837,6 +838,11 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
 		if (map_ops[i].status)
@@ -855,6 +861,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
@@ -862,7 +871,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count, bool clear_pte)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
 	if (ret)
@@ -871,12 +880,20 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 10:50:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 10:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdJw-0002Zj-VF; Tue, 24 Apr 2012 10:50:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdJu-0002Ze-R4
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 10:50:07 +0000
Received: from [85.158.143.99:27728] by server-2.bemta-4.messagelabs.com id
	56/8A-17550-E55869F4; Tue, 24 Apr 2012 10:50:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335264596!13816150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18998 invoked from network); 24 Apr 2012 10:50:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 10:50:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12102636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 10:49:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 11:49:50 +0100
Date: Tue, 24 Apr 2012 11:55:43 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120417144318.GA28477@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1204241153380.26786@kaball-desktop>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
	<20120417144318.GA28477@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4] xen: enter/exit lazy_mmu_mode around
	m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.

Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL.  Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
going to be batched together, otherwise they are issued one at a time.

Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
m2p_add/remove_override calls forces paravirt_lazy_mode to
PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.

However it is not safe to call arch_enter_lazy_mmu_mode if we are in
interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
check for both conditions before doing so.

Changes in v4:
- rebased on 3.4-rc4: all the m2p_override users call gnttab_unmap_refs
and gnttab_map_refs;
- check whether we are in interrupt context and the lazy_mode we are in
before calling arch_enter/leave_lazy_mmu_mode.

Changes in v3:
- do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
can be called in interrupt context.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index e570c6f..a18a3e8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -38,6 +38,7 @@
 #include <linux/vmalloc.h>
 #include <linux/uaccess.h>
 #include <linux/io.h>
+#include <linux/hardirq.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -826,7 +827,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 	pte_t *pte;
 	unsigned long mfn;
 
@@ -837,6 +838,11 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
 		if (map_ops[i].status)
@@ -855,6 +861,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
@@ -862,7 +871,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count, bool clear_pte)
 {
-	int i, ret;
+	int i, ret, lazy = 0;
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
 	if (ret)
@@ -871,12 +880,20 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
+	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+		arch_enter_lazy_mmu_mode();
+		lazy = 1;
+	}
+
 	for (i = 0; i < count; i++) {
 		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
 
+	if (lazy)
+		arch_leave_lazy_mmu_mode();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:21:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdoS-0002yk-Tj; Tue, 24 Apr 2012 11:21:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdoQ-0002yf-Rx
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:21:39 +0000
Received: from [85.158.138.51:62901] by server-5.bemta-3.messagelabs.com id
	09/77-17113-2CC869F4; Tue, 24 Apr 2012 11:21:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335266495!23396297!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4443 invoked from network); 24 Apr 2012 11:21:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 11:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466685"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 07:21:29 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 07:21:29 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMdis-000210-4h; Tue, 24 Apr 2012 12:15:54 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 24 Apr 2012 12:22:01 +0100
Message-ID: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use the BDRV_O_CACHE_* flags instead.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 4a6d89c..3e4a47b 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -48,7 +48,6 @@
 
 /* ------------------------------------------------------------- */
 
-static int syncwrite    = 0;
 static int batch_maps   = 0;
 
 static int max_requests = 32;
@@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
             ioreq->presync = 1;
             return 0;
         }
-        if (!syncwrite) {
-            ioreq->postsync = 1;
-        }
+        ioreq->postsync = 1;
         /* fall through */
     case BLKIF_OP_WRITE:
         ioreq->prot = PROT_READ; /* from memory */
-        if (syncwrite) {
-            ioreq->postsync = 1;
-        }
         break;
     default:
         xen_be_printf(&blkdev->xendev, 0, "error: unknown operation (%d)\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:21:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMdoS-0002yk-Tj; Tue, 24 Apr 2012 11:21:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMdoQ-0002yf-Rx
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:21:39 +0000
Received: from [85.158.138.51:62901] by server-5.bemta-3.messagelabs.com id
	09/77-17113-2CC869F4; Tue, 24 Apr 2012 11:21:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335266495!23396297!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4443 invoked from network); 24 Apr 2012 11:21:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 11:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330923600"; d="scan'208";a="24466685"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 07:21:29 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 07:21:29 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMdis-000210-4h; Tue, 24 Apr 2012 12:15:54 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 24 Apr 2012 12:22:01 +0100
Message-ID: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use the BDRV_O_CACHE_* flags instead.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 4a6d89c..3e4a47b 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -48,7 +48,6 @@
 
 /* ------------------------------------------------------------- */
 
-static int syncwrite    = 0;
 static int batch_maps   = 0;
 
 static int max_requests = 32;
@@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
             ioreq->presync = 1;
             return 0;
         }
-        if (!syncwrite) {
-            ioreq->postsync = 1;
-        }
+        ioreq->postsync = 1;
         /* fall through */
     case BLKIF_OP_WRITE:
         ioreq->prot = PROT_READ; /* from memory */
-        if (syncwrite) {
-            ioreq->postsync = 1;
-        }
         break;
     default:
         xen_be_printf(&blkdev->xendev, 0, "error: unknown operation (%d)\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMe0i-0003AC-78; Tue, 24 Apr 2012 11:34:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kwolf@redhat.com>) id 1SMe0g-0003A7-Kr
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:34:18 +0000
Received: from [85.158.143.99:34417] by server-3.bemta-4.messagelabs.com id
	81/CB-05853-ABF869F4; Tue, 24 Apr 2012 11:34:18 +0000
X-Env-Sender: kwolf@redhat.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335267256!24972543!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIwNzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7086 invoked from network); 24 Apr 2012 11:34:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 11:34:16 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3OBXp57000489
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 07:33:51 -0400
Received: from dhcp-5-188.str.redhat.com (dhcp-5-175.str.redhat.com
	[10.32.5.175])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3OBXn2O015315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 07:33:50 -0400
Message-ID: <4F969080.9000801@redhat.com>
Date: Tue, 24 Apr 2012 13:37:36 +0200
From: Kevin Wolf <kwolf@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 13:22, schrieb Stefano Stabellini:
> Use the BDRV_O_CACHE_* flags instead.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Doesn't apply to qemu.git because...

> ---
>  hw/xen_disk.c |    8 +-------
>  1 files changed, 1 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 4a6d89c..3e4a47b 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -48,7 +48,6 @@
>  
>  /* ------------------------------------------------------------- */
>  
> -static int syncwrite    = 0;
>  static int batch_maps   = 0;
>  
>  static int max_requests = 32;
> @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
>              ioreq->presync = 1;
>              return 0;
>          }
> -        if (!syncwrite) {
> -            ioreq->postsync = 1;

...this is ioreq->presync = ioreq->postsync = 1;

And while we're at it, the commit message could mention that there was
no way to set this flag anyway, so we're just removing dead code.

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMe0i-0003AC-78; Tue, 24 Apr 2012 11:34:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kwolf@redhat.com>) id 1SMe0g-0003A7-Kr
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:34:18 +0000
Received: from [85.158.143.99:34417] by server-3.bemta-4.messagelabs.com id
	81/CB-05853-ABF869F4; Tue, 24 Apr 2012 11:34:18 +0000
X-Env-Sender: kwolf@redhat.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335267256!24972543!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIwNzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7086 invoked from network); 24 Apr 2012 11:34:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 11:34:16 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3OBXp57000489
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 07:33:51 -0400
Received: from dhcp-5-188.str.redhat.com (dhcp-5-175.str.redhat.com
	[10.32.5.175])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3OBXn2O015315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 07:33:50 -0400
Message-ID: <4F969080.9000801@redhat.com>
Date: Tue, 24 Apr 2012 13:37:36 +0200
From: Kevin Wolf <kwolf@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 13:22, schrieb Stefano Stabellini:
> Use the BDRV_O_CACHE_* flags instead.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Doesn't apply to qemu.git because...

> ---
>  hw/xen_disk.c |    8 +-------
>  1 files changed, 1 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 4a6d89c..3e4a47b 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -48,7 +48,6 @@
>  
>  /* ------------------------------------------------------------- */
>  
> -static int syncwrite    = 0;
>  static int batch_maps   = 0;
>  
>  static int max_requests = 32;
> @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
>              ioreq->presync = 1;
>              return 0;
>          }
> -        if (!syncwrite) {
> -            ioreq->postsync = 1;

...this is ioreq->presync = ioreq->postsync = 1;

And while we're at it, the commit message could mention that there was
no way to set this flag anyway, so we're just removing dead code.

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMe8K-0003NO-5u; Tue, 24 Apr 2012 11:42:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMe8I-0003NI-Cx
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 11:42:10 +0000
Received: from [85.158.143.35:61041] by server-2.bemta-4.messagelabs.com id
	BE/0B-17550-191969F4; Tue, 24 Apr 2012 11:42:09 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335267725!12770793!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24617 invoked from network); 24 Apr 2012 11:42:07 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 11:42:07 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 849111020F2FE;
	Tue, 24 Apr 2012 04:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 8UabhYqi1ugs; Tue, 24 Apr 2012 04:42:02 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id D0D9A1020F2F4;
	Tue, 24 Apr 2012 04:42:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 04:42:01 -0700
Message-Id: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0607081926851638795=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0607081926851638795==
Content-Type: multipart/alternative; boundary="Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6"


--Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 3:37 AM, Stefano Stabellini wrote:

> I couldn't find any clues in the logs you posted. Maybe the output of
> xenstore-ls would be useful.


Done and done.

tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   name = "Domain-0"
   memory = ""
    target = "523904"
    static-max = "4294967292"
    freemem-slack = "314505"
   backend = ""
    console = ""
     1 = ""
      0 = ""
       frontend = "/local/domain/1/console"
       frontend-id = "1"
       online = "0"
       state = "5"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
     2 = ""
      0 = ""
       frontend = "/local/domain/2/console"
       frontend-id = "2"
       online = "0"
       state = "5"
       domain = "domutest"
       protocol = "vt100"
       hotplug-status = "connected"
     3 = ""
      0 = ""
       frontend = "/local/domain/3/console"
       frontend-id = "3"
       online = "0"
       state = "5"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
     4 = ""
      0 = ""
       frontend = "/local/domain/4/console"
       frontend-id = "4"
       online = "0"
       state = "5"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
     5 = ""
      0 = ""
       frontend = "/local/domain/5/console"
       frontend-id = "5"
       online = "0"
       state = "5"
       domain = "domutest"
       protocol = "vt100"
       hotplug-status = "connected"
     6 = ""
      0 = ""
       frontend = "/local/domain/6/console"
       frontend-id = "6"
       online = "1"
       state = "4"
       domain = "domutest"
       protocol = "vt100"
       hotplug-status = "connected"
     7 = ""
      0 = ""
       frontend = "/local/domain/7/console"
       frontend-id = "7"
       online = "1"
       state = "4"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
    vfb = ""
     5 = ""
      0 = ""
       frontend = "/local/domain/5/device/vfb/0"
       frontend-id = "5"
       online = "0"
       state = "5"
       domain = "domutest"
       vnc = "1"
       vnclisten = "0.0.0.0"
       vncpasswd = ""
       vncdisplay = "5"
       vncunused = "1"
       sdl = "0"
       opengl = "0"
       feature-resize = "1"
       hotplug-status = "connected"
       request-update = "1"
     6 = ""
      0 = ""
       frontend = "/local/domain/6/device/vfb/0"
       frontend-id = "6"
       online = "1"
       state = "4"
       domain = "domutest"
       vnc = "1"
       vnclisten = "0.0.0.0"
       vncpasswd = ""
       vncdisplay = "5"
       vncunused = "1"
       sdl = "0"
       opengl = "0"
       feature-resize = "1"
       hotplug-status = "connected"
       request-update = "1"
    vkbd = ""
     5 = ""
      0 = ""
       frontend = "/local/domain/5/device/vkbd/0"
       frontend-id = "5"
       online = "0"
       state = "5"
       domain = "domutest"
       feature-abs-pointer = "1"
       hotplug-status = "connected"
     6 = ""
      0 = ""
       frontend = "/local/domain/6/device/vkbd/0"
       frontend-id = "6"
       online = "1"
       state = "4"
       domain = "domutest"
       feature-abs-pointer = "1"
       hotplug-status = "connected"
    vbd = ""
     6 = ""
      51713 = ""
       frontend = "/local/domain/6/device/vbd/51713"
       physical-device = "fe:2"
       params = "/dev/xtG0/domutest-root"
       frontend-id = "6"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "4"
       dev = "xvda1"
       type = "phy"
       mode = "w"
       feature-flush-cache = "0"
       discard-secure = "0"
       feature-discard = "0"
       feature-barrier = "0"
       sectors = "6291456"
       info = "0"
       sector-size = "512"
      51714 = ""
       frontend = "/local/domain/6/device/vbd/51714"
       physical-device = "fe:3"
       params = "/dev/xtG0/domutest-swap"
       frontend-id = "6"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "4"
       dev = "xvda2"
       type = "phy"
       mode = "w"
       feature-flush-cache = "0"
       discard-secure = "0"
       feature-discard = "0"
       feature-barrier = "0"
       sectors = "1048576"
       info = "0"
       sector-size = "512"
    vif = ""
     6 = ""
      0 = ""
       frontend = "/local/domain/6/device/vif/0"
       frontend-id = "6"
       online = "1"
       state = "4"
       script = "/etc/xen/scripts/vif-bridge"
       mac = "00:16:3e:0c:49:8e"
       bridge = "outer0"
       handle = "0"
       feature-sg = "1"
       feature-gso-tcpv4 = "1"
       feature-rx-copy = "1"
       feature-rx-flip = "0"
       hotplug-status = "connected"
     7 = ""
      0 = ""
       frontend = "/local/domain/7/device/vif/0"
       frontend-id = "7"
       online = "1"
       state = "2"
       script = "/etc/xen/scripts/vif-bridge"
       mac = "00:16:3e:10:6a:f4"
       bridge = "outer0"
       handle = "0"
       feature-sg = "1"
       feature-gso-tcpv4 = "1"
       feature-rx-copy = "1"
       feature-rx-flip = "0"
       hotplug-status = "connected"
    qdisk = ""
     7 = ""
      51712 = ""
       frontend = "/local/domain/7/device/vbd/51712"
       params = "aio:/var/finnix/finnix-104.iso"
       frontend-id = "7"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "2"
       dev = "xvda"
       type = "tap"
       mode = "r"
       feature-barrier = "1"
       info = "4"
       sector-size = "512"
       sectors = "237712"
       hotplug-status = "connected"
   device-model = ""
    6 = ""
     disable_pf = "1"
     state = "running"
    7 = ""
     disable_pf = "1"
     state = "running"
  6 = ""
   vm = "/vm/d7ea3f07-f491-493f-8989-749d7a76a4f4"
   name = "domutest"
   control = ""
    shutdown = ""
    platform-feature-multiprocessor-suspend = "1"
   device = ""
    suspend = ""
     event-channel = ""
    vbd = ""
     51713 = ""
      backend = "/local/domain/0/backend/vbd/6/51713"
      backend-id = "0"
      state = "4"
      virtual-device = "51713"
      device-type = "disk"
      ring-ref = "8"
      event-channel = "23"
      protocol = "x86_64-abi"
     51714 = ""
      backend = "/local/domain/0/backend/vbd/6/51714"
      backend-id = "0"
      state = "4"
      virtual-device = "51714"
      device-type = "disk"
      ring-ref = "9"
      event-channel = "24"
      protocol = "x86_64-abi"
    vif = ""
     0 = ""
      backend = "/local/domain/0/backend/vif/6/0"
      backend-id = "0"
      state = "4"
      handle = "0"
      mac = "00:16:3e:0c:49:8e"
      tx-ring-ref = "10"
      rx-ring-ref = "11"
      event-channel = "25"
      request-rx-copy = "1"
      feature-rx-notify = "1"
      feature-sg = "1"
      feature-gso-tcpv4 = "1"
    vfb = ""
     0 = ""
      backend = "/local/domain/0/backend/vfb/6/0"
      backend-id = "0"
      state = "4"
      page-ref = "367826"
      event-channel = "27"
      protocol = "x86_64-abi"
      feature-update = "1"
    vkbd = ""
     0 = ""
      backend = "/local/domain/0/backend/vkbd/6/0"
      backend-id = "0"
      state = "4"
      request-abs-pointer = "1"
      page-ref = "284662"
      page-gref = "14"
      event-channel = "26"
   data = ""
   cpu = ""
    0 = ""
     availability = "online"
    1 = ""
     availability = "online"
    2 = ""
     availability = "online"
    3 = ""
     availability = "online"
   memory = ""
    static-max = "524288"
    target = "524288"
    videoram = "0"
   error = ""
   drivers = ""
   attr = ""
   messages = ""
   domid = "6"
   store = ""
    port = "1"
    ring-ref = "369971"
   console = ""
    backend = "/local/domain/0/backend/console/6/0"
    backend-id = "0"
    limit = "1048576"
    type = "ioemu"
    output = "pty"
    port = "2"
    ring-ref = "369970"
    tty = "/dev/pts/2"
    vnc-port = "5905"
    vnc-listen = "0.0.0.0"
    vnc-pass = ""
   image = ""
    device-model-pid = "1684"
  7 = ""
   vm = "/vm/bf8f3948-e089-44fd-88be-140479840e93"
   name = "finnix"
   control = ""
    shutdown = ""
    platform-feature-multiprocessor-suspend = "1"
   device = ""
    suspend = ""
     event-channel = ""
    vbd = ""
     51712 = ""
      backend = "/local/domain/0/backend/qdisk/7/51712"
      backend-id = "0"
      state = "1"
      virtual-device = "51712"
      device-type = "disk"
    vif = ""
     0 = ""
      backend = "/local/domain/0/backend/vif/7/0"
      backend-id = "0"
      state = "1"
      handle = "0"
      mac = "00:16:3e:10:6a:f4"
   data = ""
   cpu = ""
    0 = ""
     availability = "online"
   memory = ""
    static-max = "131072"
    target = "131072"
    videoram = "0"
   error = ""
   drivers = ""
   attr = ""
   messages = ""
   domid = "7"
   store = ""
    port = "1"
    ring-ref = "265286"
   console = ""
    backend = "/local/domain/0/backend/console/7/0"
    backend-id = "0"
    limit = "1048576"
    type = "ioemu"
    output = "pty"
    port = "2"
    ring-ref = "265285"
    tty = "/dev/pts/3"
   image = ""
    device-model-pid = "1725"
vm = ""
 d7ea3f07-f491-493f-8989-749d7a76a4f4 = ""
  uuid = "d7ea3f07-f491-493f-8989-749d7a76a4f4"
  name = "domutest"
  pool_name = "Pool-0"
  image = ""
   ostype = "linux"
   kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
   cmdline = "(hd0)/boot/grub/menu.lst"
  start_time = "1335231372.76"
  vncpasswd = "\000"
 bf8f3948-e089-44fd-88be-140479840e93 = ""
  uuid = "bf8f3948-e089-44fd-88be-140479840e93"
  name = "finnix"
  pool_name = "Pool-0"
  image = ""
   ostype = "linux"
   kernel = "/var/finnix/linux64"
   ramdisk = "/var/finnix/initrd.xz"
   cmdline = ""
  start_time = "1335231379.11"


--Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 3:37 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">I couldn't =
find any clues in the logs you posted. Maybe the output =
of<br>xenstore-ls would be =
useful.</span></blockquote></div><br><div><br></div><div>Done and =
done.</div><div><br></div><div><div>tool =3D =
""</div><div>&nbsp;xenstored =3D ""</div><div>local =3D =
""</div><div>&nbsp;domain =3D ""</div><div>&nbsp; 0 =3D =
""</div><div>&nbsp; &nbsp;name =3D "Domain-0"</div><div>&nbsp; =
&nbsp;memory =3D ""</div><div>&nbsp; &nbsp; target =3D =
"523904"</div><div>&nbsp; &nbsp; static-max =3D =
"4294967292"</div><div>&nbsp; &nbsp; freemem-slack =3D =
"314505"</div><div>&nbsp; &nbsp;backend =3D ""</div><div>&nbsp; &nbsp; =
console =3D ""</div><div>&nbsp; &nbsp; &nbsp;1 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/1/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "finnix"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;2 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D "/local/domain/2/console"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "2"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;domain =3D =
"domutest"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;protocol =3D =
"vt100"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;3 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/3/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "3"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "finnix"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;4 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D "/local/domain/4/console"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "4"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;domain =3D =
"finnix"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;protocol =3D =
"vt100"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;5 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/5/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;6 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D "/local/domain/6/console"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;domain =3D =
"domutest"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;protocol =3D =
"vt100"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;7 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/7/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "7"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "finnix"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; vfb =3D =
""</div><div>&nbsp; &nbsp; &nbsp;5 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/5/device/vfb/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;vnc =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vnclisten =3D =
"0.0.0.0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncpasswd =3D =
""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncdisplay =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncunused =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sdl =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;opengl =3D "0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-resize =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;request-update =3D "1"</div><div>&nbsp; &nbsp; &nbsp;6 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vfb/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;vnc =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vnclisten =3D =
"0.0.0.0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncpasswd =3D =
""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncdisplay =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncunused =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sdl =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;opengl =3D "0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-resize =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;request-update =3D "1"</div><div>&nbsp; &nbsp; vkbd =3D =
""</div><div>&nbsp; &nbsp; &nbsp;5 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/5/device/vkbd/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-abs-pointer =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;6 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vkbd/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-abs-pointer =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; vbd =3D =
""</div><div>&nbsp; &nbsp; &nbsp;6 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
51713 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vbd/51713"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;physical-device =3D "fe:2"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;params =3D "/dev/xtG0/domutest-root"</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;removable =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bootable =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;dev =3D "xvda1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;type =3D "phy"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mode =3D =
"w"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-flush-cache =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;discard-secure =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-discard =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-barrier =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sectors =3D =
"6291456"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;info =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sector-size =3D =
"512"</div><div>&nbsp; &nbsp; &nbsp; 51714 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vbd/51714"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;physical-device =3D "fe:3"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;params =3D "/dev/xtG0/domutest-swap"</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;removable =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bootable =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;dev =3D "xvda2"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;type =3D "phy"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mode =3D =
"w"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-flush-cache =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;discard-secure =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-discard =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-barrier =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sectors =3D =
"1048576"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;info =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sector-size =3D =
"512"</div><div>&nbsp; &nbsp; vif =3D ""</div><div>&nbsp; &nbsp; &nbsp;6 =
=3D ""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vif/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;script =3D =
"/etc/xen/scripts/vif-bridge"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mac =3D=
 "00:16:3e:0c:49:8e"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bridge =3D =
"outer0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;handle =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-sg =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-gso-tcpv4 =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-copy =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-flip =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;7 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/7/device/vif/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "7"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "2"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;script =3D =
"/etc/xen/scripts/vif-bridge"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mac =3D=
 "00:16:3e:10:6a:f4"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bridge =3D =
"outer0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;handle =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-sg =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-gso-tcpv4 =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-copy =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-flip =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; qdisk =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;7 =3D ""</div><div>&nbsp; &nbsp; &nbsp; 51712 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/7/device/vbd/51712"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;params =3D "aio:/var/finnix/finnix-104.iso"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "7"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;removable =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bootable =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "2"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;dev =3D "xvda"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;type =3D "tap"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mode =3D =
"r"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-barrier =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;info =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;sector-size =3D "512"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;sectors =3D "237712"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp;device-model =
=3D ""</div><div>&nbsp; &nbsp; 6 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;disable_pf =3D "1"</div><div>&nbsp; &nbsp; &nbsp;state =3D =
"running"</div><div>&nbsp; &nbsp; 7 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;disable_pf =3D "1"</div><div>&nbsp; &nbsp; &nbsp;state =3D =
"running"</div><div>&nbsp; 6 =3D ""</div><div>&nbsp; &nbsp;vm =3D =
"/vm/d7ea3f07-f491-493f-8989-749d7a76a4f4"</div><div>&nbsp; &nbsp;name =3D=
 "domutest"</div><div>&nbsp; &nbsp;control =3D ""</div><div>&nbsp; =
&nbsp; shutdown =3D ""</div><div>&nbsp; &nbsp; =
platform-feature-multiprocessor-suspend =3D "1"</div><div>&nbsp; =
&nbsp;device =3D ""</div><div>&nbsp; &nbsp; suspend =3D =
""</div><div>&nbsp; &nbsp; &nbsp;event-channel =3D ""</div><div>&nbsp; =
&nbsp; vbd =3D ""</div><div>&nbsp; &nbsp; &nbsp;51713 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vbd/6/51713"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; virtual-device =3D =
"51713"</div><div>&nbsp; &nbsp; &nbsp; device-type =3D =
"disk"</div><div>&nbsp; &nbsp; &nbsp; ring-ref =3D "8"</div><div>&nbsp; =
&nbsp; &nbsp; event-channel =3D "23"</div><div>&nbsp; &nbsp; &nbsp; =
protocol =3D "x86_64-abi"</div><div>&nbsp; &nbsp; &nbsp;51714 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vbd/6/51714"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; virtual-device =3D =
"51714"</div><div>&nbsp; &nbsp; &nbsp; device-type =3D =
"disk"</div><div>&nbsp; &nbsp; &nbsp; ring-ref =3D "9"</div><div>&nbsp; =
&nbsp; &nbsp; event-channel =3D "24"</div><div>&nbsp; &nbsp; &nbsp; =
protocol =3D "x86_64-abi"</div><div>&nbsp; &nbsp; vif =3D =
""</div><div>&nbsp; &nbsp; &nbsp;0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
backend =3D "/local/domain/0/backend/vif/6/0"</div><div>&nbsp; &nbsp; =
&nbsp; backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; handle =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; mac =3D "00:16:3e:0c:49:8e"</div><div>&nbsp; &nbsp; &nbsp; =
tx-ring-ref =3D "10"</div><div>&nbsp; &nbsp; &nbsp; rx-ring-ref =3D =
"11"</div><div>&nbsp; &nbsp; &nbsp; event-channel =3D =
"25"</div><div>&nbsp; &nbsp; &nbsp; request-rx-copy =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; feature-rx-notify =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; feature-sg =3D "1"</div><div>&nbsp; =
&nbsp; &nbsp; feature-gso-tcpv4 =3D "1"</div><div>&nbsp; &nbsp; vfb =3D =
""</div><div>&nbsp; &nbsp; &nbsp;0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
backend =3D "/local/domain/0/backend/vfb/6/0"</div><div>&nbsp; &nbsp; =
&nbsp; backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; page-ref =3D =
"367826"</div><div>&nbsp; &nbsp; &nbsp; event-channel =3D =
"27"</div><div>&nbsp; &nbsp; &nbsp; protocol =3D =
"x86_64-abi"</div><div>&nbsp; &nbsp; &nbsp; feature-update =3D =
"1"</div><div>&nbsp; &nbsp; vkbd =3D ""</div><div>&nbsp; &nbsp; &nbsp;0 =
=3D ""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vkbd/6/0"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; request-abs-pointer =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; page-ref =3D =
"284662"</div><div>&nbsp; &nbsp; &nbsp; page-gref =3D =
"14"</div><div>&nbsp; &nbsp; &nbsp; event-channel =3D =
"26"</div><div>&nbsp; &nbsp;data =3D ""</div><div>&nbsp; &nbsp;cpu =3D =
""</div><div>&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;availability =3D "online"</div><div>&nbsp; &nbsp; 1 =3D =
""</div><div>&nbsp; &nbsp; &nbsp;availability =3D =
"online"</div><div>&nbsp; &nbsp; 2 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;availability =3D "online"</div><div>&nbsp; &nbsp; 3 =3D =
""</div><div>&nbsp; &nbsp; &nbsp;availability =3D =
"online"</div><div>&nbsp; &nbsp;memory =3D ""</div><div>&nbsp; &nbsp; =
static-max =3D "524288"</div><div>&nbsp; &nbsp; target =3D =
"524288"</div><div>&nbsp; &nbsp; videoram =3D "0"</div><div>&nbsp; =
&nbsp;error =3D ""</div><div>&nbsp; &nbsp;drivers =3D =
""</div><div>&nbsp; &nbsp;attr =3D ""</div><div>&nbsp; &nbsp;messages =3D =
""</div><div>&nbsp; &nbsp;domid =3D "6"</div><div>&nbsp; &nbsp;store =3D =
""</div><div>&nbsp; &nbsp; port =3D "1"</div><div>&nbsp; &nbsp; ring-ref =
=3D "369971"</div><div>&nbsp; &nbsp;console =3D ""</div><div>&nbsp; =
&nbsp; backend =3D =
"/local/domain/0/backend/console/6/0"</div><div>&nbsp; &nbsp; backend-id =
=3D "0"</div><div>&nbsp; &nbsp; limit =3D "1048576"</div><div>&nbsp; =
&nbsp; type =3D "ioemu"</div><div>&nbsp; &nbsp; output =3D =
"pty"</div><div>&nbsp; &nbsp; port =3D "2"</div><div>&nbsp; &nbsp; =
ring-ref =3D "369970"</div><div>&nbsp; &nbsp; tty =3D =
"/dev/pts/2"</div><div>&nbsp; &nbsp; vnc-port =3D =
"5905"</div><div>&nbsp; &nbsp; vnc-listen =3D "0.0.0.0"</div><div>&nbsp; =
&nbsp; vnc-pass =3D ""</div><div>&nbsp; &nbsp;image =3D =
""</div><div>&nbsp; &nbsp; device-model-pid =3D "1684"</div><div>&nbsp; =
7 =3D ""</div><div>&nbsp; &nbsp;vm =3D =
"/vm/bf8f3948-e089-44fd-88be-140479840e93"</div><div>&nbsp; &nbsp;name =3D=
 "finnix"</div><div>&nbsp; &nbsp;control =3D ""</div><div>&nbsp; &nbsp; =
shutdown =3D ""</div><div>&nbsp; &nbsp; =
platform-feature-multiprocessor-suspend =3D "1"</div><div>&nbsp; =
&nbsp;device =3D ""</div><div>&nbsp; &nbsp; suspend =3D =
""</div><div>&nbsp; &nbsp; &nbsp;event-channel =3D ""</div><div>&nbsp; =
&nbsp; vbd =3D ""</div><div>&nbsp; &nbsp; &nbsp;51712 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/qdisk/7/51712"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; virtual-device =3D =
"51712"</div><div>&nbsp; &nbsp; &nbsp; device-type =3D =
"disk"</div><div>&nbsp; &nbsp; vif =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vif/7/0"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; handle =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; mac =3D "00:16:3e:10:6a:f4"</div><div>&nbsp; &nbsp;data =3D =
""</div><div>&nbsp; &nbsp;cpu =3D ""</div><div>&nbsp; &nbsp; 0 =3D =
""</div><div>&nbsp; &nbsp; &nbsp;availability =3D =
"online"</div><div>&nbsp; &nbsp;memory =3D ""</div><div>&nbsp; &nbsp; =
static-max =3D "131072"</div><div>&nbsp; &nbsp; target =3D =
"131072"</div><div>&nbsp; &nbsp; videoram =3D "0"</div><div>&nbsp; =
&nbsp;error =3D ""</div><div>&nbsp; &nbsp;drivers =3D =
""</div><div>&nbsp; &nbsp;attr =3D ""</div><div>&nbsp; &nbsp;messages =3D =
""</div><div>&nbsp; &nbsp;domid =3D "7"</div><div>&nbsp; &nbsp;store =3D =
""</div><div>&nbsp; &nbsp; port =3D "1"</div><div>&nbsp; &nbsp; ring-ref =
=3D "265286"</div><div>&nbsp; &nbsp;console =3D ""</div><div>&nbsp; =
&nbsp; backend =3D =
"/local/domain/0/backend/console/7/0"</div><div>&nbsp; &nbsp; backend-id =
=3D "0"</div><div>&nbsp; &nbsp; limit =3D "1048576"</div><div>&nbsp; =
&nbsp; type =3D "ioemu"</div><div>&nbsp; &nbsp; output =3D =
"pty"</div><div>&nbsp; &nbsp; port =3D "2"</div><div>&nbsp; &nbsp; =
ring-ref =3D "265285"</div><div>&nbsp; &nbsp; tty =3D =
"/dev/pts/3"</div><div>&nbsp; &nbsp;image =3D ""</div><div>&nbsp; &nbsp; =
device-model-pid =3D "1725"</div><div>vm =3D =
""</div><div>&nbsp;d7ea3f07-f491-493f-8989-749d7a76a4f4 =3D =
""</div><div>&nbsp; uuid =3D =
"d7ea3f07-f491-493f-8989-749d7a76a4f4"</div><div>&nbsp; name =3D =
"domutest"</div><div>&nbsp; pool_name =3D "Pool-0"</div><div>&nbsp; =
image =3D ""</div><div>&nbsp; &nbsp;ostype =3D "linux"</div><div>&nbsp; =
&nbsp;kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"</div><div>&nbsp; =
&nbsp;cmdline =3D "(hd0)/boot/grub/menu.lst"</div><div>&nbsp; start_time =
=3D "1335231372.76"</div><div>&nbsp; vncpasswd =3D =
"\000"</div><div>&nbsp;bf8f3948-e089-44fd-88be-140479840e93 =3D =
""</div><div>&nbsp; uuid =3D =
"bf8f3948-e089-44fd-88be-140479840e93"</div><div>&nbsp; name =3D =
"finnix"</div><div>&nbsp; pool_name =3D "Pool-0"</div><div>&nbsp; image =
=3D ""</div><div>&nbsp; &nbsp;ostype =3D "linux"</div><div>&nbsp; =
&nbsp;kernel =3D "/var/finnix/linux64"</div><div>&nbsp; &nbsp;ramdisk =3D =
"/var/finnix/initrd.xz"</div><div>&nbsp; &nbsp;cmdline =3D =
""</div><div>&nbsp; start_time =3D =
"1335231379.11"</div></div><div><br></div></body></html>=

--Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6--


--===============0607081926851638795==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0607081926851638795==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 11:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMe8K-0003NO-5u; Tue, 24 Apr 2012 11:42:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMe8I-0003NI-Cx
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 11:42:10 +0000
Received: from [85.158.143.35:61041] by server-2.bemta-4.messagelabs.com id
	BE/0B-17550-191969F4; Tue, 24 Apr 2012 11:42:09 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335267725!12770793!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24617 invoked from network); 24 Apr 2012 11:42:07 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 11:42:07 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 849111020F2FE;
	Tue, 24 Apr 2012 04:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 8UabhYqi1ugs; Tue, 24 Apr 2012 04:42:02 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id D0D9A1020F2F4;
	Tue, 24 Apr 2012 04:42:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 04:42:01 -0700
Message-Id: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0607081926851638795=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0607081926851638795==
Content-Type: multipart/alternative; boundary="Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6"


--Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 3:37 AM, Stefano Stabellini wrote:

> I couldn't find any clues in the logs you posted. Maybe the output of
> xenstore-ls would be useful.


Done and done.

tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   name = "Domain-0"
   memory = ""
    target = "523904"
    static-max = "4294967292"
    freemem-slack = "314505"
   backend = ""
    console = ""
     1 = ""
      0 = ""
       frontend = "/local/domain/1/console"
       frontend-id = "1"
       online = "0"
       state = "5"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
     2 = ""
      0 = ""
       frontend = "/local/domain/2/console"
       frontend-id = "2"
       online = "0"
       state = "5"
       domain = "domutest"
       protocol = "vt100"
       hotplug-status = "connected"
     3 = ""
      0 = ""
       frontend = "/local/domain/3/console"
       frontend-id = "3"
       online = "0"
       state = "5"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
     4 = ""
      0 = ""
       frontend = "/local/domain/4/console"
       frontend-id = "4"
       online = "0"
       state = "5"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
     5 = ""
      0 = ""
       frontend = "/local/domain/5/console"
       frontend-id = "5"
       online = "0"
       state = "5"
       domain = "domutest"
       protocol = "vt100"
       hotplug-status = "connected"
     6 = ""
      0 = ""
       frontend = "/local/domain/6/console"
       frontend-id = "6"
       online = "1"
       state = "4"
       domain = "domutest"
       protocol = "vt100"
       hotplug-status = "connected"
     7 = ""
      0 = ""
       frontend = "/local/domain/7/console"
       frontend-id = "7"
       online = "1"
       state = "4"
       domain = "finnix"
       protocol = "vt100"
       hotplug-status = "connected"
    vfb = ""
     5 = ""
      0 = ""
       frontend = "/local/domain/5/device/vfb/0"
       frontend-id = "5"
       online = "0"
       state = "5"
       domain = "domutest"
       vnc = "1"
       vnclisten = "0.0.0.0"
       vncpasswd = ""
       vncdisplay = "5"
       vncunused = "1"
       sdl = "0"
       opengl = "0"
       feature-resize = "1"
       hotplug-status = "connected"
       request-update = "1"
     6 = ""
      0 = ""
       frontend = "/local/domain/6/device/vfb/0"
       frontend-id = "6"
       online = "1"
       state = "4"
       domain = "domutest"
       vnc = "1"
       vnclisten = "0.0.0.0"
       vncpasswd = ""
       vncdisplay = "5"
       vncunused = "1"
       sdl = "0"
       opengl = "0"
       feature-resize = "1"
       hotplug-status = "connected"
       request-update = "1"
    vkbd = ""
     5 = ""
      0 = ""
       frontend = "/local/domain/5/device/vkbd/0"
       frontend-id = "5"
       online = "0"
       state = "5"
       domain = "domutest"
       feature-abs-pointer = "1"
       hotplug-status = "connected"
     6 = ""
      0 = ""
       frontend = "/local/domain/6/device/vkbd/0"
       frontend-id = "6"
       online = "1"
       state = "4"
       domain = "domutest"
       feature-abs-pointer = "1"
       hotplug-status = "connected"
    vbd = ""
     6 = ""
      51713 = ""
       frontend = "/local/domain/6/device/vbd/51713"
       physical-device = "fe:2"
       params = "/dev/xtG0/domutest-root"
       frontend-id = "6"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "4"
       dev = "xvda1"
       type = "phy"
       mode = "w"
       feature-flush-cache = "0"
       discard-secure = "0"
       feature-discard = "0"
       feature-barrier = "0"
       sectors = "6291456"
       info = "0"
       sector-size = "512"
      51714 = ""
       frontend = "/local/domain/6/device/vbd/51714"
       physical-device = "fe:3"
       params = "/dev/xtG0/domutest-swap"
       frontend-id = "6"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "4"
       dev = "xvda2"
       type = "phy"
       mode = "w"
       feature-flush-cache = "0"
       discard-secure = "0"
       feature-discard = "0"
       feature-barrier = "0"
       sectors = "1048576"
       info = "0"
       sector-size = "512"
    vif = ""
     6 = ""
      0 = ""
       frontend = "/local/domain/6/device/vif/0"
       frontend-id = "6"
       online = "1"
       state = "4"
       script = "/etc/xen/scripts/vif-bridge"
       mac = "00:16:3e:0c:49:8e"
       bridge = "outer0"
       handle = "0"
       feature-sg = "1"
       feature-gso-tcpv4 = "1"
       feature-rx-copy = "1"
       feature-rx-flip = "0"
       hotplug-status = "connected"
     7 = ""
      0 = ""
       frontend = "/local/domain/7/device/vif/0"
       frontend-id = "7"
       online = "1"
       state = "2"
       script = "/etc/xen/scripts/vif-bridge"
       mac = "00:16:3e:10:6a:f4"
       bridge = "outer0"
       handle = "0"
       feature-sg = "1"
       feature-gso-tcpv4 = "1"
       feature-rx-copy = "1"
       feature-rx-flip = "0"
       hotplug-status = "connected"
    qdisk = ""
     7 = ""
      51712 = ""
       frontend = "/local/domain/7/device/vbd/51712"
       params = "aio:/var/finnix/finnix-104.iso"
       frontend-id = "7"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "2"
       dev = "xvda"
       type = "tap"
       mode = "r"
       feature-barrier = "1"
       info = "4"
       sector-size = "512"
       sectors = "237712"
       hotplug-status = "connected"
   device-model = ""
    6 = ""
     disable_pf = "1"
     state = "running"
    7 = ""
     disable_pf = "1"
     state = "running"
  6 = ""
   vm = "/vm/d7ea3f07-f491-493f-8989-749d7a76a4f4"
   name = "domutest"
   control = ""
    shutdown = ""
    platform-feature-multiprocessor-suspend = "1"
   device = ""
    suspend = ""
     event-channel = ""
    vbd = ""
     51713 = ""
      backend = "/local/domain/0/backend/vbd/6/51713"
      backend-id = "0"
      state = "4"
      virtual-device = "51713"
      device-type = "disk"
      ring-ref = "8"
      event-channel = "23"
      protocol = "x86_64-abi"
     51714 = ""
      backend = "/local/domain/0/backend/vbd/6/51714"
      backend-id = "0"
      state = "4"
      virtual-device = "51714"
      device-type = "disk"
      ring-ref = "9"
      event-channel = "24"
      protocol = "x86_64-abi"
    vif = ""
     0 = ""
      backend = "/local/domain/0/backend/vif/6/0"
      backend-id = "0"
      state = "4"
      handle = "0"
      mac = "00:16:3e:0c:49:8e"
      tx-ring-ref = "10"
      rx-ring-ref = "11"
      event-channel = "25"
      request-rx-copy = "1"
      feature-rx-notify = "1"
      feature-sg = "1"
      feature-gso-tcpv4 = "1"
    vfb = ""
     0 = ""
      backend = "/local/domain/0/backend/vfb/6/0"
      backend-id = "0"
      state = "4"
      page-ref = "367826"
      event-channel = "27"
      protocol = "x86_64-abi"
      feature-update = "1"
    vkbd = ""
     0 = ""
      backend = "/local/domain/0/backend/vkbd/6/0"
      backend-id = "0"
      state = "4"
      request-abs-pointer = "1"
      page-ref = "284662"
      page-gref = "14"
      event-channel = "26"
   data = ""
   cpu = ""
    0 = ""
     availability = "online"
    1 = ""
     availability = "online"
    2 = ""
     availability = "online"
    3 = ""
     availability = "online"
   memory = ""
    static-max = "524288"
    target = "524288"
    videoram = "0"
   error = ""
   drivers = ""
   attr = ""
   messages = ""
   domid = "6"
   store = ""
    port = "1"
    ring-ref = "369971"
   console = ""
    backend = "/local/domain/0/backend/console/6/0"
    backend-id = "0"
    limit = "1048576"
    type = "ioemu"
    output = "pty"
    port = "2"
    ring-ref = "369970"
    tty = "/dev/pts/2"
    vnc-port = "5905"
    vnc-listen = "0.0.0.0"
    vnc-pass = ""
   image = ""
    device-model-pid = "1684"
  7 = ""
   vm = "/vm/bf8f3948-e089-44fd-88be-140479840e93"
   name = "finnix"
   control = ""
    shutdown = ""
    platform-feature-multiprocessor-suspend = "1"
   device = ""
    suspend = ""
     event-channel = ""
    vbd = ""
     51712 = ""
      backend = "/local/domain/0/backend/qdisk/7/51712"
      backend-id = "0"
      state = "1"
      virtual-device = "51712"
      device-type = "disk"
    vif = ""
     0 = ""
      backend = "/local/domain/0/backend/vif/7/0"
      backend-id = "0"
      state = "1"
      handle = "0"
      mac = "00:16:3e:10:6a:f4"
   data = ""
   cpu = ""
    0 = ""
     availability = "online"
   memory = ""
    static-max = "131072"
    target = "131072"
    videoram = "0"
   error = ""
   drivers = ""
   attr = ""
   messages = ""
   domid = "7"
   store = ""
    port = "1"
    ring-ref = "265286"
   console = ""
    backend = "/local/domain/0/backend/console/7/0"
    backend-id = "0"
    limit = "1048576"
    type = "ioemu"
    output = "pty"
    port = "2"
    ring-ref = "265285"
    tty = "/dev/pts/3"
   image = ""
    device-model-pid = "1725"
vm = ""
 d7ea3f07-f491-493f-8989-749d7a76a4f4 = ""
  uuid = "d7ea3f07-f491-493f-8989-749d7a76a4f4"
  name = "domutest"
  pool_name = "Pool-0"
  image = ""
   ostype = "linux"
   kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
   cmdline = "(hd0)/boot/grub/menu.lst"
  start_time = "1335231372.76"
  vncpasswd = "\000"
 bf8f3948-e089-44fd-88be-140479840e93 = ""
  uuid = "bf8f3948-e089-44fd-88be-140479840e93"
  name = "finnix"
  pool_name = "Pool-0"
  image = ""
   ostype = "linux"
   kernel = "/var/finnix/linux64"
   ramdisk = "/var/finnix/initrd.xz"
   cmdline = ""
  start_time = "1335231379.11"


--Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 3:37 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">I couldn't =
find any clues in the logs you posted. Maybe the output =
of<br>xenstore-ls would be =
useful.</span></blockquote></div><br><div><br></div><div>Done and =
done.</div><div><br></div><div><div>tool =3D =
""</div><div>&nbsp;xenstored =3D ""</div><div>local =3D =
""</div><div>&nbsp;domain =3D ""</div><div>&nbsp; 0 =3D =
""</div><div>&nbsp; &nbsp;name =3D "Domain-0"</div><div>&nbsp; =
&nbsp;memory =3D ""</div><div>&nbsp; &nbsp; target =3D =
"523904"</div><div>&nbsp; &nbsp; static-max =3D =
"4294967292"</div><div>&nbsp; &nbsp; freemem-slack =3D =
"314505"</div><div>&nbsp; &nbsp;backend =3D ""</div><div>&nbsp; &nbsp; =
console =3D ""</div><div>&nbsp; &nbsp; &nbsp;1 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/1/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "finnix"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;2 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D "/local/domain/2/console"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "2"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;domain =3D =
"domutest"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;protocol =3D =
"vt100"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;3 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/3/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "3"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "finnix"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;4 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D "/local/domain/4/console"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "4"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;domain =3D =
"finnix"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;protocol =3D =
"vt100"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;5 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/5/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;6 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D "/local/domain/6/console"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;domain =3D =
"domutest"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;protocol =3D =
"vt100"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;7 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/7/console"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "7"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "finnix"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;protocol =3D "vt100"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; vfb =3D =
""</div><div>&nbsp; &nbsp; &nbsp;5 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/5/device/vfb/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;vnc =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vnclisten =3D =
"0.0.0.0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncpasswd =3D =
""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncdisplay =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncunused =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sdl =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;opengl =3D "0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-resize =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;request-update =3D "1"</div><div>&nbsp; &nbsp; &nbsp;6 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vfb/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;vnc =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vnclisten =3D =
"0.0.0.0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncpasswd =3D =
""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncdisplay =3D =
"5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;vncunused =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sdl =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;opengl =3D "0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-resize =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;request-update =3D "1"</div><div>&nbsp; &nbsp; vkbd =3D =
""</div><div>&nbsp; &nbsp; &nbsp;5 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/5/device/vkbd/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "5"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "5"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-abs-pointer =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; &nbsp;6 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vkbd/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;domain =3D "domutest"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;feature-abs-pointer =3D "1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp; vbd =3D =
""</div><div>&nbsp; &nbsp; &nbsp;6 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
51713 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vbd/51713"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;physical-device =3D "fe:2"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;params =3D "/dev/xtG0/domutest-root"</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;removable =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bootable =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;dev =3D "xvda1"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;type =3D "phy"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mode =3D =
"w"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-flush-cache =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;discard-secure =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-discard =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-barrier =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sectors =3D =
"6291456"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;info =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sector-size =3D =
"512"</div><div>&nbsp; &nbsp; &nbsp; 51714 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vbd/51714"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;physical-device =3D "fe:3"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;params =3D "/dev/xtG0/domutest-swap"</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;removable =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bootable =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;dev =3D "xvda2"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;type =3D "phy"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mode =3D =
"w"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-flush-cache =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;discard-secure =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-discard =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-barrier =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sectors =3D =
"1048576"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;info =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;sector-size =3D =
"512"</div><div>&nbsp; &nbsp; vif =3D ""</div><div>&nbsp; &nbsp; &nbsp;6 =
=3D ""</div><div>&nbsp; &nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;frontend =3D =
"/local/domain/6/device/vif/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "6"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;script =3D =
"/etc/xen/scripts/vif-bridge"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mac =3D=
 "00:16:3e:0c:49:8e"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bridge =3D =
"outer0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;handle =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-sg =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-gso-tcpv4 =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-copy =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-flip =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; &nbsp;7 =3D ""</div><div>&nbsp; =
&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/7/device/vif/0"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;frontend-id =3D "7"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;online =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "2"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;script =3D =
"/etc/xen/scripts/vif-bridge"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mac =3D=
 "00:16:3e:10:6a:f4"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bridge =3D =
"outer0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;handle =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-sg =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-gso-tcpv4 =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-copy =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-rx-flip =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;hotplug-status =3D =
"connected"</div><div>&nbsp; &nbsp; qdisk =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;7 =3D ""</div><div>&nbsp; &nbsp; &nbsp; 51712 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; &nbsp;frontend =3D =
"/local/domain/7/device/vbd/51712"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;params =3D "aio:/var/finnix/finnix-104.iso"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;frontend-id =3D "7"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;online =3D "1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;removable =3D =
"0"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bootable =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;state =3D "2"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;dev =3D "xvda"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;type =3D "tap"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mode =3D =
"r"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;feature-barrier =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; &nbsp;info =3D "4"</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp;sector-size =3D "512"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;sectors =3D "237712"</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp;hotplug-status =3D "connected"</div><div>&nbsp; &nbsp;device-model =
=3D ""</div><div>&nbsp; &nbsp; 6 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;disable_pf =3D "1"</div><div>&nbsp; &nbsp; &nbsp;state =3D =
"running"</div><div>&nbsp; &nbsp; 7 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;disable_pf =3D "1"</div><div>&nbsp; &nbsp; &nbsp;state =3D =
"running"</div><div>&nbsp; 6 =3D ""</div><div>&nbsp; &nbsp;vm =3D =
"/vm/d7ea3f07-f491-493f-8989-749d7a76a4f4"</div><div>&nbsp; &nbsp;name =3D=
 "domutest"</div><div>&nbsp; &nbsp;control =3D ""</div><div>&nbsp; =
&nbsp; shutdown =3D ""</div><div>&nbsp; &nbsp; =
platform-feature-multiprocessor-suspend =3D "1"</div><div>&nbsp; =
&nbsp;device =3D ""</div><div>&nbsp; &nbsp; suspend =3D =
""</div><div>&nbsp; &nbsp; &nbsp;event-channel =3D ""</div><div>&nbsp; =
&nbsp; vbd =3D ""</div><div>&nbsp; &nbsp; &nbsp;51713 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vbd/6/51713"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; virtual-device =3D =
"51713"</div><div>&nbsp; &nbsp; &nbsp; device-type =3D =
"disk"</div><div>&nbsp; &nbsp; &nbsp; ring-ref =3D "8"</div><div>&nbsp; =
&nbsp; &nbsp; event-channel =3D "23"</div><div>&nbsp; &nbsp; &nbsp; =
protocol =3D "x86_64-abi"</div><div>&nbsp; &nbsp; &nbsp;51714 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vbd/6/51714"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; virtual-device =3D =
"51714"</div><div>&nbsp; &nbsp; &nbsp; device-type =3D =
"disk"</div><div>&nbsp; &nbsp; &nbsp; ring-ref =3D "9"</div><div>&nbsp; =
&nbsp; &nbsp; event-channel =3D "24"</div><div>&nbsp; &nbsp; &nbsp; =
protocol =3D "x86_64-abi"</div><div>&nbsp; &nbsp; vif =3D =
""</div><div>&nbsp; &nbsp; &nbsp;0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
backend =3D "/local/domain/0/backend/vif/6/0"</div><div>&nbsp; &nbsp; =
&nbsp; backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; handle =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; mac =3D "00:16:3e:0c:49:8e"</div><div>&nbsp; &nbsp; &nbsp; =
tx-ring-ref =3D "10"</div><div>&nbsp; &nbsp; &nbsp; rx-ring-ref =3D =
"11"</div><div>&nbsp; &nbsp; &nbsp; event-channel =3D =
"25"</div><div>&nbsp; &nbsp; &nbsp; request-rx-copy =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; feature-rx-notify =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; feature-sg =3D "1"</div><div>&nbsp; =
&nbsp; &nbsp; feature-gso-tcpv4 =3D "1"</div><div>&nbsp; &nbsp; vfb =3D =
""</div><div>&nbsp; &nbsp; &nbsp;0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; =
backend =3D "/local/domain/0/backend/vfb/6/0"</div><div>&nbsp; &nbsp; =
&nbsp; backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; page-ref =3D =
"367826"</div><div>&nbsp; &nbsp; &nbsp; event-channel =3D =
"27"</div><div>&nbsp; &nbsp; &nbsp; protocol =3D =
"x86_64-abi"</div><div>&nbsp; &nbsp; &nbsp; feature-update =3D =
"1"</div><div>&nbsp; &nbsp; vkbd =3D ""</div><div>&nbsp; &nbsp; &nbsp;0 =
=3D ""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vkbd/6/0"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"4"</div><div>&nbsp; &nbsp; &nbsp; request-abs-pointer =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; page-ref =3D =
"284662"</div><div>&nbsp; &nbsp; &nbsp; page-gref =3D =
"14"</div><div>&nbsp; &nbsp; &nbsp; event-channel =3D =
"26"</div><div>&nbsp; &nbsp;data =3D ""</div><div>&nbsp; &nbsp;cpu =3D =
""</div><div>&nbsp; &nbsp; 0 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;availability =3D "online"</div><div>&nbsp; &nbsp; 1 =3D =
""</div><div>&nbsp; &nbsp; &nbsp;availability =3D =
"online"</div><div>&nbsp; &nbsp; 2 =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;availability =3D "online"</div><div>&nbsp; &nbsp; 3 =3D =
""</div><div>&nbsp; &nbsp; &nbsp;availability =3D =
"online"</div><div>&nbsp; &nbsp;memory =3D ""</div><div>&nbsp; &nbsp; =
static-max =3D "524288"</div><div>&nbsp; &nbsp; target =3D =
"524288"</div><div>&nbsp; &nbsp; videoram =3D "0"</div><div>&nbsp; =
&nbsp;error =3D ""</div><div>&nbsp; &nbsp;drivers =3D =
""</div><div>&nbsp; &nbsp;attr =3D ""</div><div>&nbsp; &nbsp;messages =3D =
""</div><div>&nbsp; &nbsp;domid =3D "6"</div><div>&nbsp; &nbsp;store =3D =
""</div><div>&nbsp; &nbsp; port =3D "1"</div><div>&nbsp; &nbsp; ring-ref =
=3D "369971"</div><div>&nbsp; &nbsp;console =3D ""</div><div>&nbsp; =
&nbsp; backend =3D =
"/local/domain/0/backend/console/6/0"</div><div>&nbsp; &nbsp; backend-id =
=3D "0"</div><div>&nbsp; &nbsp; limit =3D "1048576"</div><div>&nbsp; =
&nbsp; type =3D "ioemu"</div><div>&nbsp; &nbsp; output =3D =
"pty"</div><div>&nbsp; &nbsp; port =3D "2"</div><div>&nbsp; &nbsp; =
ring-ref =3D "369970"</div><div>&nbsp; &nbsp; tty =3D =
"/dev/pts/2"</div><div>&nbsp; &nbsp; vnc-port =3D =
"5905"</div><div>&nbsp; &nbsp; vnc-listen =3D "0.0.0.0"</div><div>&nbsp; =
&nbsp; vnc-pass =3D ""</div><div>&nbsp; &nbsp;image =3D =
""</div><div>&nbsp; &nbsp; device-model-pid =3D "1684"</div><div>&nbsp; =
7 =3D ""</div><div>&nbsp; &nbsp;vm =3D =
"/vm/bf8f3948-e089-44fd-88be-140479840e93"</div><div>&nbsp; &nbsp;name =3D=
 "finnix"</div><div>&nbsp; &nbsp;control =3D ""</div><div>&nbsp; &nbsp; =
shutdown =3D ""</div><div>&nbsp; &nbsp; =
platform-feature-multiprocessor-suspend =3D "1"</div><div>&nbsp; =
&nbsp;device =3D ""</div><div>&nbsp; &nbsp; suspend =3D =
""</div><div>&nbsp; &nbsp; &nbsp;event-channel =3D ""</div><div>&nbsp; =
&nbsp; vbd =3D ""</div><div>&nbsp; &nbsp; &nbsp;51712 =3D =
""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/qdisk/7/51712"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; virtual-device =3D =
"51712"</div><div>&nbsp; &nbsp; &nbsp; device-type =3D =
"disk"</div><div>&nbsp; &nbsp; vif =3D ""</div><div>&nbsp; &nbsp; =
&nbsp;0 =3D ""</div><div>&nbsp; &nbsp; &nbsp; backend =3D =
"/local/domain/0/backend/vif/7/0"</div><div>&nbsp; &nbsp; &nbsp; =
backend-id =3D "0"</div><div>&nbsp; &nbsp; &nbsp; state =3D =
"1"</div><div>&nbsp; &nbsp; &nbsp; handle =3D "0"</div><div>&nbsp; =
&nbsp; &nbsp; mac =3D "00:16:3e:10:6a:f4"</div><div>&nbsp; &nbsp;data =3D =
""</div><div>&nbsp; &nbsp;cpu =3D ""</div><div>&nbsp; &nbsp; 0 =3D =
""</div><div>&nbsp; &nbsp; &nbsp;availability =3D =
"online"</div><div>&nbsp; &nbsp;memory =3D ""</div><div>&nbsp; &nbsp; =
static-max =3D "131072"</div><div>&nbsp; &nbsp; target =3D =
"131072"</div><div>&nbsp; &nbsp; videoram =3D "0"</div><div>&nbsp; =
&nbsp;error =3D ""</div><div>&nbsp; &nbsp;drivers =3D =
""</div><div>&nbsp; &nbsp;attr =3D ""</div><div>&nbsp; &nbsp;messages =3D =
""</div><div>&nbsp; &nbsp;domid =3D "7"</div><div>&nbsp; &nbsp;store =3D =
""</div><div>&nbsp; &nbsp; port =3D "1"</div><div>&nbsp; &nbsp; ring-ref =
=3D "265286"</div><div>&nbsp; &nbsp;console =3D ""</div><div>&nbsp; =
&nbsp; backend =3D =
"/local/domain/0/backend/console/7/0"</div><div>&nbsp; &nbsp; backend-id =
=3D "0"</div><div>&nbsp; &nbsp; limit =3D "1048576"</div><div>&nbsp; =
&nbsp; type =3D "ioemu"</div><div>&nbsp; &nbsp; output =3D =
"pty"</div><div>&nbsp; &nbsp; port =3D "2"</div><div>&nbsp; &nbsp; =
ring-ref =3D "265285"</div><div>&nbsp; &nbsp; tty =3D =
"/dev/pts/3"</div><div>&nbsp; &nbsp;image =3D ""</div><div>&nbsp; &nbsp; =
device-model-pid =3D "1725"</div><div>vm =3D =
""</div><div>&nbsp;d7ea3f07-f491-493f-8989-749d7a76a4f4 =3D =
""</div><div>&nbsp; uuid =3D =
"d7ea3f07-f491-493f-8989-749d7a76a4f4"</div><div>&nbsp; name =3D =
"domutest"</div><div>&nbsp; pool_name =3D "Pool-0"</div><div>&nbsp; =
image =3D ""</div><div>&nbsp; &nbsp;ostype =3D "linux"</div><div>&nbsp; =
&nbsp;kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"</div><div>&nbsp; =
&nbsp;cmdline =3D "(hd0)/boot/grub/menu.lst"</div><div>&nbsp; start_time =
=3D "1335231372.76"</div><div>&nbsp; vncpasswd =3D =
"\000"</div><div>&nbsp;bf8f3948-e089-44fd-88be-140479840e93 =3D =
""</div><div>&nbsp; uuid =3D =
"bf8f3948-e089-44fd-88be-140479840e93"</div><div>&nbsp; name =3D =
"finnix"</div><div>&nbsp; pool_name =3D "Pool-0"</div><div>&nbsp; image =
=3D ""</div><div>&nbsp; &nbsp;ostype =3D "linux"</div><div>&nbsp; =
&nbsp;kernel =3D "/var/finnix/linux64"</div><div>&nbsp; &nbsp;ramdisk =3D =
"/var/finnix/initrd.xz"</div><div>&nbsp; &nbsp;cmdline =3D =
""</div><div>&nbsp; start_time =3D =
"1335231379.11"</div></div><div><br></div></body></html>=

--Apple-Mail=_36AAAC0B-FC7D-42C8-A53D-D0E2D3571AB6--


--===============0607081926851638795==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0607081926851638795==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 11:49:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:49:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeFK-0003YG-9C; Tue, 24 Apr 2012 11:49:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMeFH-0003YA-To
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:49:24 +0000
Received: from [85.158.139.83:41811] by server-12.bemta-5.messagelabs.com id
	A8/6F-05587-343969F4; Tue, 24 Apr 2012 11:49:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335268162!21371672!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 696 invoked from network); 24 Apr 2012 11:49:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 11:49:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12104019"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 11:49:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 12:49:22 +0100
Date: Tue, 24 Apr 2012 12:55:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Kevin Wolf <kwolf@redhat.com>
In-Reply-To: <4F969080.9000801@redhat.com>
Message-ID: <alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F969080.9000801@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Kevin Wolf wrote:
> Am 24.04.2012 13:22, schrieb Stefano Stabellini:
> > Use the BDRV_O_CACHE_* flags instead.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Doesn't apply to qemu.git because...
> 
> > ---
> >  hw/xen_disk.c |    8 +-------
> >  1 files changed, 1 insertions(+), 7 deletions(-)
> > 
> > diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > index 4a6d89c..3e4a47b 100644
> > --- a/hw/xen_disk.c
> > +++ b/hw/xen_disk.c
> > @@ -48,7 +48,6 @@
> >  
> >  /* ------------------------------------------------------------- */
> >  
> > -static int syncwrite    = 0;
> >  static int batch_maps   = 0;
> >  
> >  static int max_requests = 32;
> > @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
> >              ioreq->presync = 1;
> >              return 0;
> >          }
> > -        if (!syncwrite) {
> > -            ioreq->postsync = 1;
> 
> ...this is ioreq->presync = ioreq->postsync = 1;

That's because it is based on top of the following two patches:

xen_disk: use bdrv_aio_flush instead of bdrv_flush
http://marc.info/?l=qemu-devel&m=133434258008959&w=2

xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
http://marc.info/?l=qemu-devel&m=133459581417878&w=2

I have just sent a pull request for them
(http://marc.info/?l=qemu-devel&m=133526669019403) after leaving lying
around for a while.
Next time do you want me to send xen_disk specific pull request to you
instead? Sorry if I shouldn't have sent the pull request directly...


> And while we're at it, the commit message could mention that there was
> no way to set this flag anyway, so we're just removing dead code.

good point

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:49:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:49:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeFK-0003YG-9C; Tue, 24 Apr 2012 11:49:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMeFH-0003YA-To
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:49:24 +0000
Received: from [85.158.139.83:41811] by server-12.bemta-5.messagelabs.com id
	A8/6F-05587-343969F4; Tue, 24 Apr 2012 11:49:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335268162!21371672!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 696 invoked from network); 24 Apr 2012 11:49:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 11:49:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="12104019"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 11:49:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 12:49:22 +0100
Date: Tue, 24 Apr 2012 12:55:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Kevin Wolf <kwolf@redhat.com>
In-Reply-To: <4F969080.9000801@redhat.com>
Message-ID: <alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F969080.9000801@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Kevin Wolf wrote:
> Am 24.04.2012 13:22, schrieb Stefano Stabellini:
> > Use the BDRV_O_CACHE_* flags instead.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Doesn't apply to qemu.git because...
> 
> > ---
> >  hw/xen_disk.c |    8 +-------
> >  1 files changed, 1 insertions(+), 7 deletions(-)
> > 
> > diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > index 4a6d89c..3e4a47b 100644
> > --- a/hw/xen_disk.c
> > +++ b/hw/xen_disk.c
> > @@ -48,7 +48,6 @@
> >  
> >  /* ------------------------------------------------------------- */
> >  
> > -static int syncwrite    = 0;
> >  static int batch_maps   = 0;
> >  
> >  static int max_requests = 32;
> > @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
> >              ioreq->presync = 1;
> >              return 0;
> >          }
> > -        if (!syncwrite) {
> > -            ioreq->postsync = 1;
> 
> ...this is ioreq->presync = ioreq->postsync = 1;

That's because it is based on top of the following two patches:

xen_disk: use bdrv_aio_flush instead of bdrv_flush
http://marc.info/?l=qemu-devel&m=133434258008959&w=2

xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
http://marc.info/?l=qemu-devel&m=133459581417878&w=2

I have just sent a pull request for them
(http://marc.info/?l=qemu-devel&m=133526669019403) after leaving lying
around for a while.
Next time do you want me to send xen_disk specific pull request to you
instead? Sorry if I shouldn't have sent the pull request directly...


> And while we're at it, the commit message could mention that there was
> no way to set this flag anyway, so we're just removing dead code.

good point

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:56:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeLT-0003hX-5c; Tue, 24 Apr 2012 11:55:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMeLR-0003hP-KM
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 11:55:45 +0000
Received: from [85.158.143.99:15903] by server-3.bemta-4.messagelabs.com id
	9A/A4-05853-1C4969F4; Tue, 24 Apr 2012 11:55:45 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335268542!24462467!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12408 invoked from network); 24 Apr 2012 11:55:43 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 11:55:43 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 380B81020F2FE;
	Tue, 24 Apr 2012 04:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 88xhQISmb4Kl; Tue, 24 Apr 2012 04:55:37 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 637BB1020F2F4;
	Tue, 24 Apr 2012 04:55:37 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <1335263508.4347.78.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 04:55:36 -0700
Message-Id: <D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7619265216416283668=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7619265216416283668==
Content-Type: multipart/alternative; boundary="Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB"


--Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 3:31 AM, Ian Campbell wrote:

> Thanks, it's good to see people trying the transition.
>=20
> Are you able to try xen-unstable? A lot of this stuff (particularly
> relating to pv consoles and pygrub etc) is much improved in the 4.2
> version of xl and if not then we should be much more able to fix =
things
> there than in 4.1 (where I suspect any fix would be far too invasive =
for
> a stable backport).
>=20
> Thanks,
> Ian.

I can.   There's a couple things that have occurred to me that I'd like =
to try out, but I can certainly give it a try.

The packages I'm working on are eventually destined for a production =
server.    I started out on this process when my production machine =
started crashing when I'd load up on domUs.  You can see =
<http://www.gossamer-threads.com/lists/xen/users/241986> for more info =
on that one.   That's running a pull from mercurial from some months ago =
before 4.1.2 was released, so I thought I would make fresh go of Xen, =
and if I still had the problem I'd feel better about filing bug reports.

So for the purposes of production blah, I thought I'd use the stable =
releases, but if tracking unstable is preferable, I can do that.

-Sam=

--Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 3:31 AM, Ian Campbell =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Thanks, it's =
good to see people trying the transition.<br><br>Are you able to try =
xen-unstable? A lot of this stuff (particularly<br>relating to pv =
consoles and pygrub etc) is much improved in the 4.2<br>version of xl =
and if not then we should be much more able to fix things<br>there than =
in 4.1 (where I suspect any fix would be far too invasive for<br>a =
stable =
backport).<br><br>Thanks,<br>Ian.<br></span></blockquote></div><br><div>I =
can. &nbsp; There's a couple things that have occurred to me that I'd =
like to try out, but I can certainly give it a =
try.</div><div><br></div><div>The packages I'm working on are eventually =
destined for a production server. &nbsp; &nbsp;I started out on this =
process when my production machine started crashing when I'd load up on =
domUs. &nbsp;You can see &lt;<a =
href=3D"http://www.gossamer-threads.com/lists/xen/users/241986">http://www=
.gossamer-threads.com/lists/xen/users/241986</a>&gt; for more info on =
that one. &nbsp; That's running a pull from mercurial from some months =
ago before 4.1.2 was released, so I thought I would make fresh go of =
Xen, and if I still had the problem I'd feel better about filing bug =
reports.</div><div><br></div><div>So for the purposes of production =
blah, I thought I'd use the stable releases, but if tracking unstable is =
preferable, I can do =
that.</div><div><br></div><div>-Sam</div></body></html>=

--Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB--


--===============7619265216416283668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7619265216416283668==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 11:56:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeLT-0003hX-5c; Tue, 24 Apr 2012 11:55:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMeLR-0003hP-KM
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 11:55:45 +0000
Received: from [85.158.143.99:15903] by server-3.bemta-4.messagelabs.com id
	9A/A4-05853-1C4969F4; Tue, 24 Apr 2012 11:55:45 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335268542!24462467!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12408 invoked from network); 24 Apr 2012 11:55:43 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 11:55:43 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 380B81020F2FE;
	Tue, 24 Apr 2012 04:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 88xhQISmb4Kl; Tue, 24 Apr 2012 04:55:37 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 637BB1020F2F4;
	Tue, 24 Apr 2012 04:55:37 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <1335263508.4347.78.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 04:55:36 -0700
Message-Id: <D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7619265216416283668=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7619265216416283668==
Content-Type: multipart/alternative; boundary="Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB"


--Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 3:31 AM, Ian Campbell wrote:

> Thanks, it's good to see people trying the transition.
>=20
> Are you able to try xen-unstable? A lot of this stuff (particularly
> relating to pv consoles and pygrub etc) is much improved in the 4.2
> version of xl and if not then we should be much more able to fix =
things
> there than in 4.1 (where I suspect any fix would be far too invasive =
for
> a stable backport).
>=20
> Thanks,
> Ian.

I can.   There's a couple things that have occurred to me that I'd like =
to try out, but I can certainly give it a try.

The packages I'm working on are eventually destined for a production =
server.    I started out on this process when my production machine =
started crashing when I'd load up on domUs.  You can see =
<http://www.gossamer-threads.com/lists/xen/users/241986> for more info =
on that one.   That's running a pull from mercurial from some months ago =
before 4.1.2 was released, so I thought I would make fresh go of Xen, =
and if I still had the problem I'd feel better about filing bug reports.

So for the purposes of production blah, I thought I'd use the stable =
releases, but if tracking unstable is preferable, I can do that.

-Sam=

--Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 3:31 AM, Ian Campbell =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Thanks, it's =
good to see people trying the transition.<br><br>Are you able to try =
xen-unstable? A lot of this stuff (particularly<br>relating to pv =
consoles and pygrub etc) is much improved in the 4.2<br>version of xl =
and if not then we should be much more able to fix things<br>there than =
in 4.1 (where I suspect any fix would be far too invasive for<br>a =
stable =
backport).<br><br>Thanks,<br>Ian.<br></span></blockquote></div><br><div>I =
can. &nbsp; There's a couple things that have occurred to me that I'd =
like to try out, but I can certainly give it a =
try.</div><div><br></div><div>The packages I'm working on are eventually =
destined for a production server. &nbsp; &nbsp;I started out on this =
process when my production machine started crashing when I'd load up on =
domUs. &nbsp;You can see &lt;<a =
href=3D"http://www.gossamer-threads.com/lists/xen/users/241986">http://www=
.gossamer-threads.com/lists/xen/users/241986</a>&gt; for more info on =
that one. &nbsp; That's running a pull from mercurial from some months =
ago before 4.1.2 was released, so I thought I would make fresh go of =
Xen, and if I still had the problem I'd feel better about filing bug =
reports.</div><div><br></div><div>So for the purposes of production =
blah, I thought I'd use the stable releases, but if tracking unstable is =
preferable, I can do =
that.</div><div><br></div><div>-Sam</div></body></html>=

--Apple-Mail=_82FC141A-EF9A-4D1A-B07D-9E98B4B9F9FB--


--===============7619265216416283668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7619265216416283668==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 11:57:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:57:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeMl-0003lQ-MC; Tue, 24 Apr 2012 11:57:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kwolf@redhat.com>) id 1SMeMk-0003lF-8z
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:57:06 +0000
Received: from [85.158.138.51:7358] by server-7.bemta-3.messagelabs.com id
	23/99-03078-115969F4; Tue, 24 Apr 2012 11:57:05 +0000
X-Env-Sender: kwolf@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335268623!23369043!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIwNzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3822 invoked from network); 24 Apr 2012 11:57:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 11:57:04 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3OBv0me002459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 07:57:00 -0400
Received: from dhcp-5-188.str.redhat.com (dhcp-5-175.str.redhat.com
	[10.32.5.175])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3OBuwnh020664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 07:56:59 -0400
Message-ID: <4F9695ED.8010402@redhat.com>
Date: Tue, 24 Apr 2012 14:00:45 +0200
From: Kevin Wolf <kwolf@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F969080.9000801@redhat.com>
	<alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 13:55, schrieb Stefano Stabellini:
> On Tue, 24 Apr 2012, Kevin Wolf wrote:
>> Am 24.04.2012 13:22, schrieb Stefano Stabellini:
>>> Use the BDRV_O_CACHE_* flags instead.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> Doesn't apply to qemu.git because...
>>
>>> ---
>>>  hw/xen_disk.c |    8 +-------
>>>  1 files changed, 1 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>>> index 4a6d89c..3e4a47b 100644
>>> --- a/hw/xen_disk.c
>>> +++ b/hw/xen_disk.c
>>> @@ -48,7 +48,6 @@
>>>  
>>>  /* ------------------------------------------------------------- */
>>>  
>>> -static int syncwrite    = 0;
>>>  static int batch_maps   = 0;
>>>  
>>>  static int max_requests = 32;
>>> @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
>>>              ioreq->presync = 1;
>>>              return 0;
>>>          }
>>> -        if (!syncwrite) {
>>> -            ioreq->postsync = 1;
>>
>> ...this is ioreq->presync = ioreq->postsync = 1;
> 
> That's because it is based on top of the following two patches:
> 
> xen_disk: use bdrv_aio_flush instead of bdrv_flush
> http://marc.info/?l=qemu-devel&m=133434258008959&w=2
> 
> xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
> http://marc.info/?l=qemu-devel&m=133459581417878&w=2
> 
> I have just sent a pull request for them
> (http://marc.info/?l=qemu-devel&m=133526669019403) after leaving lying
> around for a while.
> Next time do you want me to send xen_disk specific pull request to you
> instead? Sorry if I shouldn't have sent the pull request directly...

I see. I wasn't aware that you're doing pull requests, but it isn't a
problem. It just means that you should probably do a pull request for
this one as well instead of expecting that I pick it up. But you can
have my Acked-by, if you like.

Should I ignore xen_disk patches from now on for the block branch and
assume that you pick them up?

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 11:57:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 11:57:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeMl-0003lQ-MC; Tue, 24 Apr 2012 11:57:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kwolf@redhat.com>) id 1SMeMk-0003lF-8z
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 11:57:06 +0000
Received: from [85.158.138.51:7358] by server-7.bemta-3.messagelabs.com id
	23/99-03078-115969F4; Tue, 24 Apr 2012 11:57:05 +0000
X-Env-Sender: kwolf@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335268623!23369043!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIwNzE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3822 invoked from network); 24 Apr 2012 11:57:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 11:57:04 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3OBv0me002459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 07:57:00 -0400
Received: from dhcp-5-188.str.redhat.com (dhcp-5-175.str.redhat.com
	[10.32.5.175])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3OBuwnh020664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 07:56:59 -0400
Message-ID: <4F9695ED.8010402@redhat.com>
Date: Tue, 24 Apr 2012 14:00:45 +0200
From: Kevin Wolf <kwolf@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F969080.9000801@redhat.com>
	<alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 13:55, schrieb Stefano Stabellini:
> On Tue, 24 Apr 2012, Kevin Wolf wrote:
>> Am 24.04.2012 13:22, schrieb Stefano Stabellini:
>>> Use the BDRV_O_CACHE_* flags instead.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> Doesn't apply to qemu.git because...
>>
>>> ---
>>>  hw/xen_disk.c |    8 +-------
>>>  1 files changed, 1 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>>> index 4a6d89c..3e4a47b 100644
>>> --- a/hw/xen_disk.c
>>> +++ b/hw/xen_disk.c
>>> @@ -48,7 +48,6 @@
>>>  
>>>  /* ------------------------------------------------------------- */
>>>  
>>> -static int syncwrite    = 0;
>>>  static int batch_maps   = 0;
>>>  
>>>  static int max_requests = 32;
>>> @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq)
>>>              ioreq->presync = 1;
>>>              return 0;
>>>          }
>>> -        if (!syncwrite) {
>>> -            ioreq->postsync = 1;
>>
>> ...this is ioreq->presync = ioreq->postsync = 1;
> 
> That's because it is based on top of the following two patches:
> 
> xen_disk: use bdrv_aio_flush instead of bdrv_flush
> http://marc.info/?l=qemu-devel&m=133434258008959&w=2
> 
> xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
> http://marc.info/?l=qemu-devel&m=133459581417878&w=2
> 
> I have just sent a pull request for them
> (http://marc.info/?l=qemu-devel&m=133526669019403) after leaving lying
> around for a while.
> Next time do you want me to send xen_disk specific pull request to you
> instead? Sorry if I shouldn't have sent the pull request directly...

I see. I wasn't aware that you're doing pull requests, but it isn't a
problem. It just means that you should probably do a pull request for
this one as well instead of expecting that I pick it up. But you can
have my Acked-by, if you like.

Should I ignore xen_disk patches from now on for the block branch and
assume that you pick them up?

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:10:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeZ7-0004Be-Pe; Tue, 24 Apr 2012 12:09:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMeZ6-0004BZ-Sb
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:09:53 +0000
Received: from [193.109.254.147:10313] by server-12.bemta-14.messagelabs.com
	id 54/B9-05898-018969F4; Tue, 24 Apr 2012 12:09:52 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335269391!3596877!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 394 invoked from network); 24 Apr 2012 12:09:51 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 12:09:51 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 28E6FD34715;
	Tue, 24 Apr 2012 14:09:51 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 0T744XtqHe+j; Tue, 24 Apr 2012 14:09:45 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id E031DD341B3;
	Tue, 24 Apr 2012 14:09:44 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Jan Beulich" <JBeulich@suse.com>
Date: Tue, 24 Apr 2012 14:09:43 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F95C158.7030703@vido.info>
	<4F96720E020000780007F82E@nat28.tlf.novell.com>
In-Reply-To: <4F96720E020000780007F82E@nat28.tlf.novell.com>
MIME-Version: 1.0
Message-Id: <201204241409.44044.tobias.geiger@vido.info>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> >>>> Hello!
> >>>> 
> >>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3
> >>>> and rc4 tested) as Dom0 Kernel;
> >>>> 
> >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> >>>> With 3.4 it drops to about a third of that.
> >>>> 
> >>>> Xen Version is xen-unstable:
> >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> >>>> 25209:e6b20ec1824c
> >>>> 
> >>>> Disk config line is:
> >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> >>>> - it uses blkback.
> >>> 
> >>> I fail to see what could be the cause of the issue: nothing on the
> >>> blkback side should affect performances significantly.
> >>> You could try reverting the four patches to blkback that were applied
> >>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
> >>> regression:
> >>> 
> >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> >>> 
> >>> Daniel De Graaf (2):
> >>>        xen/blkback: use grant-table.c hypercall wrappers
> >> 
> >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> >> the compiler would have kept the result of the first call to vaddr(req,
> >> i) somewhere.. but not sure) lost with the mentioned patch:
> >> 
> >> diff --git a/drivers/block/xen-blkback/blkback.c
> > 
> > b/drivers/block/xen-blkback/blkback.c
> > 
> >> index 73f196c..65dbadc 100644
> >> --- a/drivers/block/xen-blkback/blkback.c
> >> +++ b/drivers/block/xen-blkback/blkback.c
> >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> >> *req)
> >> 
> >>   	int ret;
> >>   	
> >>   	for (i = 0; i<  req->nr_pages; i++) {
> >> 
> >> +		unsigned long addr;
> >> 
> >>   		handle = pending_handle(req, i);
> >>   		if (handle == BLKBACK_INVALID_HANDLE)
> >>   		
> >>   			continue;
> >> 
> >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> >> +		addr = vaddr(req, i);
> >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> >> 
> >>   				    GNTMAP_host_map, handle);
> >>   		
> >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> >> 
> >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> >> +		pages[invcount] = virt_to_page(addr);
> >> 
> >>   		invcount++;
> >>   	
> >>   	}
> >>   	
> >>>        xen/blkback: Enable blkback on HVM guests
> >>> 
> >>> Konrad Rzeszutek Wilk (2):
> >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> >>>        type. xen/blkback: Make optional features be really optional.
> >>> 
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> > 
> > that made it even worse :)
> > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> 
> I doubt this patch can have any meaningful positive or negative
> performance effect at all - are you sure you're doing comparable
> runs? After all this is all just about a few arithmetic operations
> and an array access, which I'd expect to hide in the noise.
> 
> Jan

I redid the test; 

a) with 3.3.0 kernel 
b) with 3.4.0-rc4
c) with 3.40-rc4 and above patch

everything else remained the same, i.e. test-program and test-scenario was not 
changed and started after about 5min of domu bootup (so that no strange 
bootup-effects become relevant); same phy-backend (lvm on ssd), same everything 
else; so i cant see what else except the used dom0 kernel is causing this 
issue; but here are the numbers:

a) read: 135mb/s write: 142mb/s
b) read: 39mb/s  write: 39mb/s
c) read: 40mb/s  write: 40mb/s

Only thing that may become relevant is the difference in kernel-config betwen 
3.3 and 3.4 - here's the diff :
http://pastebin.com/raw.php?i=Dy71Fegq

Jan, it seems you're right: The patch doesn't add extra performance regression 
- i guess i had an i/o intensive task running in dom0 while doing the 
benchmark yesterday, so that the write performance got so bad. sorry for that.

Still there's a significant performance penalty from 3.3 to 3.4 

Greetings
Tobias





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:10:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMeZ7-0004Be-Pe; Tue, 24 Apr 2012 12:09:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMeZ6-0004BZ-Sb
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:09:53 +0000
Received: from [193.109.254.147:10313] by server-12.bemta-14.messagelabs.com
	id 54/B9-05898-018969F4; Tue, 24 Apr 2012 12:09:52 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335269391!3596877!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 394 invoked from network); 24 Apr 2012 12:09:51 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 12:09:51 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 28E6FD34715;
	Tue, 24 Apr 2012 14:09:51 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 0T744XtqHe+j; Tue, 24 Apr 2012 14:09:45 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id E031DD341B3;
	Tue, 24 Apr 2012 14:09:44 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Jan Beulich" <JBeulich@suse.com>
Date: Tue, 24 Apr 2012 14:09:43 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F95C158.7030703@vido.info>
	<4F96720E020000780007F82E@nat28.tlf.novell.com>
In-Reply-To: <4F96720E020000780007F82E@nat28.tlf.novell.com>
MIME-Version: 1.0
Message-Id: <201204241409.44044.tobias.geiger@vido.info>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> >>>> Hello!
> >>>> 
> >>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3
> >>>> and rc4 tested) as Dom0 Kernel;
> >>>> 
> >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> >>>> With 3.4 it drops to about a third of that.
> >>>> 
> >>>> Xen Version is xen-unstable:
> >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> >>>> 25209:e6b20ec1824c
> >>>> 
> >>>> Disk config line is:
> >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> >>>> - it uses blkback.
> >>> 
> >>> I fail to see what could be the cause of the issue: nothing on the
> >>> blkback side should affect performances significantly.
> >>> You could try reverting the four patches to blkback that were applied
> >>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
> >>> regression:
> >>> 
> >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> >>> 
> >>> Daniel De Graaf (2):
> >>>        xen/blkback: use grant-table.c hypercall wrappers
> >> 
> >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> >> the compiler would have kept the result of the first call to vaddr(req,
> >> i) somewhere.. but not sure) lost with the mentioned patch:
> >> 
> >> diff --git a/drivers/block/xen-blkback/blkback.c
> > 
> > b/drivers/block/xen-blkback/blkback.c
> > 
> >> index 73f196c..65dbadc 100644
> >> --- a/drivers/block/xen-blkback/blkback.c
> >> +++ b/drivers/block/xen-blkback/blkback.c
> >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> >> *req)
> >> 
> >>   	int ret;
> >>   	
> >>   	for (i = 0; i<  req->nr_pages; i++) {
> >> 
> >> +		unsigned long addr;
> >> 
> >>   		handle = pending_handle(req, i);
> >>   		if (handle == BLKBACK_INVALID_HANDLE)
> >>   		
> >>   			continue;
> >> 
> >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> >> +		addr = vaddr(req, i);
> >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> >> 
> >>   				    GNTMAP_host_map, handle);
> >>   		
> >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> >> 
> >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> >> +		pages[invcount] = virt_to_page(addr);
> >> 
> >>   		invcount++;
> >>   	
> >>   	}
> >>   	
> >>>        xen/blkback: Enable blkback on HVM guests
> >>> 
> >>> Konrad Rzeszutek Wilk (2):
> >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> >>>        type. xen/blkback: Make optional features be really optional.
> >>> 
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> > 
> > that made it even worse :)
> > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> 
> I doubt this patch can have any meaningful positive or negative
> performance effect at all - are you sure you're doing comparable
> runs? After all this is all just about a few arithmetic operations
> and an array access, which I'd expect to hide in the noise.
> 
> Jan

I redid the test; 

a) with 3.3.0 kernel 
b) with 3.4.0-rc4
c) with 3.40-rc4 and above patch

everything else remained the same, i.e. test-program and test-scenario was not 
changed and started after about 5min of domu bootup (so that no strange 
bootup-effects become relevant); same phy-backend (lvm on ssd), same everything 
else; so i cant see what else except the used dom0 kernel is causing this 
issue; but here are the numbers:

a) read: 135mb/s write: 142mb/s
b) read: 39mb/s  write: 39mb/s
c) read: 40mb/s  write: 40mb/s

Only thing that may become relevant is the difference in kernel-config betwen 
3.3 and 3.4 - here's the diff :
http://pastebin.com/raw.php?i=Dy71Fegq

Jan, it seems you're right: The patch doesn't add extra performance regression 
- i guess i had an i/o intensive task running in dom0 while doing the 
benchmark yesterday, so that the write performance got so bad. sorry for that.

Still there's a significant performance penalty from 3.3 to 3.4 

Greetings
Tobias





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:14:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:14:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMedE-0004JT-JJ; Tue, 24 Apr 2012 12:14:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMedC-0004JO-TH
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:14:07 +0000
Received: from [85.158.143.35:59299] by server-2.bemta-4.messagelabs.com id
	A3/C5-17550-E09969F4; Tue, 24 Apr 2012 12:14:06 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335269644!13867785!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30407 invoked from network); 24 Apr 2012 12:14:05 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 12:14:05 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id C42771C14001;
	Tue, 24 Apr 2012 14:14:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=IsR89APf37dPeLKG8MSZcsmhXj8=; b=D/
	vUbZjGp9zuYyI2ZLyHZ3vAyUowu/D/lRCyqTxEooQRwlxGqxOm7/NAintSG1TfcK
	1UMff4jl/W7nhyaOdydeUR14T9R+GkyAhHNLBtXXgo2a2nTuOa7CNANSI2Ey03jU
	+yPC+nNzzl92AUOvXjND5hWjA2s70QMhxPE7NCS1bs2mUkOaYFo+Ar7FU0vFC+eU
	cawaSjC4kh+ei/F32uanYN3TzebAhgj93RWRsEEzwsJ5/rnhVM3eTSr85BoA4DTr
	35Tbx7joZV3awgP72eYBvnGvuDiy1N8PJO21cFhDtbQAaanbr5sQ605qeh/br54m
	CSCMF8qcdD12Yn4Ko9srLqg1bsLs2ulHVO79/DwYafNZoCKWXdesDSZWXQpGAMZj
	v5FsPc/krz8zNIxM3zAGSxdsz5uKgN0xBHXmvRPybAjJgJ7WigVDOft2FoBHtIfE
	kR1V1qmHqYDR36qR084rqjiI4sWscycjuhaOhmnWXkJEwgRJFdhC74df/8U4aeg2
	JY506MsW4N12qJZoTdkC0/LGVkdy0eI6K3mFj3so2CVqTKJsWAa4K72oi0cdMgq/
	mTNpjbemIK4LGatbbluxTZyrcIjzhc3Z8NCoFn/xc3FwYcUJQcbHMU1+FwBBj9aH
	gjARleUfImvjVrVKhYmASl3srK3hvuNws7/eWR2Nk=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 8BD681C14002; Tue, 24 Apr 2012 14:14:03 +0200 (CEST)
Date: Tue, 24 Apr 2012 14:14:03 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20120424121402.GA19331@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline
In-Reply-To: <1335247525.2397.4.camel@Abyss>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,


On Tue, Apr 24, Dario Faggioli wrote:

> What might be missing is some documentation in docs/man/xl.cfg.pod.5,
> explaining about the new options... :-)

I've added a little documentation, so now I hope it is ok.


-- 
best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--KsGdsel6WgEHnImy
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"

libxl: set domain scheduling parameters while creating the dom

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index e2cd251..4060933 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use. Default behavior is
 (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
 
+=item B<cpu-weight="weight of cpu (default 256)">
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host.
+Legal weights range from 1 to 65535 and the default is 256.
+Can be set for credit, credit2 and sedf scheduler.
+
+=item B<cap="max amount of cpu (default 0)">
+
+The cap optionally fixes the maximum amount of CPU a domain will be
+able to consume, even if the host system has idle CPU cycles.
+The cap is expressed in percentage of one physical CPU:
+100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc.
+The default, 0, means there is no upper cap.
+Can be set for the credit and credit2 scheduler.
+
+=item B<period="time in nanoseconds (default 0)">
+
+The normal EDF scheduling usage in nanoseconds. This means every period
+the domain gets cpu time defined in slice.
+Can be set for sedf scheduler.
+
+=item B<slice="time in nanoseconds (default 0)">
+
+The normal EDF scheduling usage in nanoseconds. it defines the time 
+a domain get every period time.
+Can be set for sedf scheduler.
+
+=item B<latency=" (default 0)">
+
+Scaled period if domain is doing heavy I/O.
+Can be set for sedf scheduler.
+
+=item B<extratime="BOOLEAN (default 0)">
+
+Flag for allowing domain to run in extra time.
+Can be set for sedf scheduler.
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..38acff4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char *dom_path, *vm_path;
     xs_transaction_t t;
     char **ents, **hvm_ents;
+    libxl_scheduler sched;
     int i;
 
+    sched = libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      break;
+    default:
+        abort();
+    }
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..c1cdc3c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,27 @@ libxl_domain_create_info = Struct("domain_create_info",[
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +277,13 @@ libxl_domain_build_info = Struct("domain_build_info",[
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
 
+    ("us", KeyedUnion(None, libxl_scheduler, "sched",
+                 [("credit", libxl_sched_credit_domain),
+                 ("credit2", libxl_sched_credit2_domain),
+                 ("sedf", libxl_sched_sedf_domain),
+                 ("arinc653", libxl_sched_arinc653_domain),
+                 ], keyvar_init_val = "-1")),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_type),
@@ -417,28 +445,12 @@ libxl_cputopology = Struct("cputopology", [
     ("node", uint32),
     ], dir=DIR_OUT)
 
-libxl_sched_credit_domain = Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
 
 libxl_sched_credit_params = Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
     ], dispose_fn=None)
 
-libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..db51ca6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,23 @@ static void parse_config_data(const char *configfile_filename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->us.credit.weight = l;
+        b_info->us.credit2.weight = l;
+        b_info->us.sedf.weight = l;
+
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->us.credit.cap = l;
+
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->us.sedf.period = l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->us.sedf.period = l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->us.sedf.period = l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->us.sedf.period = l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;

--KsGdsel6WgEHnImy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--KsGdsel6WgEHnImy--


From xen-devel-bounces@lists.xen.org Tue Apr 24 12:14:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:14:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMedE-0004JT-JJ; Tue, 24 Apr 2012 12:14:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMedC-0004JO-TH
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:14:07 +0000
Received: from [85.158.143.35:59299] by server-2.bemta-4.messagelabs.com id
	A3/C5-17550-E09969F4; Tue, 24 Apr 2012 12:14:06 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335269644!13867785!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30407 invoked from network); 24 Apr 2012 12:14:05 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 12:14:05 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id C42771C14001;
	Tue, 24 Apr 2012 14:14:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=IsR89APf37dPeLKG8MSZcsmhXj8=; b=D/
	vUbZjGp9zuYyI2ZLyHZ3vAyUowu/D/lRCyqTxEooQRwlxGqxOm7/NAintSG1TfcK
	1UMff4jl/W7nhyaOdydeUR14T9R+GkyAhHNLBtXXgo2a2nTuOa7CNANSI2Ey03jU
	+yPC+nNzzl92AUOvXjND5hWjA2s70QMhxPE7NCS1bs2mUkOaYFo+Ar7FU0vFC+eU
	cawaSjC4kh+ei/F32uanYN3TzebAhgj93RWRsEEzwsJ5/rnhVM3eTSr85BoA4DTr
	35Tbx7joZV3awgP72eYBvnGvuDiy1N8PJO21cFhDtbQAaanbr5sQ605qeh/br54m
	CSCMF8qcdD12Yn4Ko9srLqg1bsLs2ulHVO79/DwYafNZoCKWXdesDSZWXQpGAMZj
	v5FsPc/krz8zNIxM3zAGSxdsz5uKgN0xBHXmvRPybAjJgJ7WigVDOft2FoBHtIfE
	kR1V1qmHqYDR36qR084rqjiI4sWscycjuhaOhmnWXkJEwgRJFdhC74df/8U4aeg2
	JY506MsW4N12qJZoTdkC0/LGVkdy0eI6K3mFj3so2CVqTKJsWAa4K72oi0cdMgq/
	mTNpjbemIK4LGatbbluxTZyrcIjzhc3Z8NCoFn/xc3FwYcUJQcbHMU1+FwBBj9aH
	gjARleUfImvjVrVKhYmASl3srK3hvuNws7/eWR2Nk=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 8BD681C14002; Tue, 24 Apr 2012 14:14:03 +0200 (CEST)
Date: Tue, 24 Apr 2012 14:14:03 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20120424121402.GA19331@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline
In-Reply-To: <1335247525.2397.4.camel@Abyss>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,


On Tue, Apr 24, Dario Faggioli wrote:

> What might be missing is some documentation in docs/man/xl.cfg.pod.5,
> explaining about the new options... :-)

I've added a little documentation, so now I hope it is ok.


-- 
best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--KsGdsel6WgEHnImy
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"

libxl: set domain scheduling parameters while creating the dom

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index e2cd251..4060933 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use. Default behavior is
 (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
 
+=item B<cpu-weight="weight of cpu (default 256)">
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host.
+Legal weights range from 1 to 65535 and the default is 256.
+Can be set for credit, credit2 and sedf scheduler.
+
+=item B<cap="max amount of cpu (default 0)">
+
+The cap optionally fixes the maximum amount of CPU a domain will be
+able to consume, even if the host system has idle CPU cycles.
+The cap is expressed in percentage of one physical CPU:
+100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc.
+The default, 0, means there is no upper cap.
+Can be set for the credit and credit2 scheduler.
+
+=item B<period="time in nanoseconds (default 0)">
+
+The normal EDF scheduling usage in nanoseconds. This means every period
+the domain gets cpu time defined in slice.
+Can be set for sedf scheduler.
+
+=item B<slice="time in nanoseconds (default 0)">
+
+The normal EDF scheduling usage in nanoseconds. it defines the time 
+a domain get every period time.
+Can be set for sedf scheduler.
+
+=item B<latency=" (default 0)">
+
+Scaled period if domain is doing heavy I/O.
+Can be set for sedf scheduler.
+
+=item B<extratime="BOOLEAN (default 0)">
+
+Flag for allowing domain to run in extra time.
+Can be set for sedf scheduler.
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..38acff4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char *dom_path, *vm_path;
     xs_transaction_t t;
     char **ents, **hvm_ents;
+    libxl_scheduler sched;
     int i;
 
+    sched = libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      break;
+    default:
+        abort();
+    }
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..c1cdc3c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,27 @@ libxl_domain_create_info = Struct("domain_create_info",[
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +277,13 @@ libxl_domain_build_info = Struct("domain_build_info",[
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
 
+    ("us", KeyedUnion(None, libxl_scheduler, "sched",
+                 [("credit", libxl_sched_credit_domain),
+                 ("credit2", libxl_sched_credit2_domain),
+                 ("sedf", libxl_sched_sedf_domain),
+                 ("arinc653", libxl_sched_arinc653_domain),
+                 ], keyvar_init_val = "-1")),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_type),
@@ -417,28 +445,12 @@ libxl_cputopology = Struct("cputopology", [
     ("node", uint32),
     ], dir=DIR_OUT)
 
-libxl_sched_credit_domain = Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
 
 libxl_sched_credit_params = Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
     ], dispose_fn=None)
 
-libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..db51ca6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,23 @@ static void parse_config_data(const char *configfile_filename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->us.credit.weight = l;
+        b_info->us.credit2.weight = l;
+        b_info->us.sedf.weight = l;
+
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->us.credit.cap = l;
+
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->us.sedf.period = l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->us.sedf.period = l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->us.sedf.period = l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->us.sedf.period = l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;

--KsGdsel6WgEHnImy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--KsGdsel6WgEHnImy--


From xen-devel-bounces@lists.xen.org Tue Apr 24 12:38:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:38:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMf03-0004jd-Po; Tue, 24 Apr 2012 12:37:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMf02-0004jV-ER
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 12:37:42 +0000
Received: from [193.109.254.147:47570] by server-2.bemta-14.messagelabs.com id
	DC/15-19409-59E969F4; Tue, 24 Apr 2012 12:37:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335271061!6108103!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16494 invoked from network); 24 Apr 2012 12:37:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:37:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12105219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:37:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 13:37:40 +0100
Date: Tue, 24 Apr 2012 13:43:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Kevin Wolf <kwolf@redhat.com>
In-Reply-To: <4F9695ED.8010402@redhat.com>
Message-ID: <alpine.DEB.2.00.1204241340430.26786@kaball-desktop>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F969080.9000801@redhat.com>
	<alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
	<4F9695ED.8010402@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Kevin Wolf wrote:
> > That's because it is based on top of the following two patches:
> > 
> > xen_disk: use bdrv_aio_flush instead of bdrv_flush
> > http://marc.info/?l=qemu-devel&m=133434258008959&w=2
> > 
> > xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
> > http://marc.info/?l=qemu-devel&m=133459581417878&w=2
> > 
> > I have just sent a pull request for them
> > (http://marc.info/?l=qemu-devel&m=133526669019403) after leaving lying
> > around for a while.
> > Next time do you want me to send xen_disk specific pull request to you
> > instead? Sorry if I shouldn't have sent the pull request directly...
> 
> I see. I wasn't aware that you're doing pull requests, but it isn't a
> problem. It just means that you should probably do a pull request for
> this one as well instead of expecting that I pick it up. But you can
> have my Acked-by, if you like.
> 
> Should I ignore xen_disk patches from now on for the block branch and
> assume that you pick them up?

I am happy to issue pull requests for xen_disk patches, but I still
welcome your reviews :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:38:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:38:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMf03-0004jd-Po; Tue, 24 Apr 2012 12:37:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMf02-0004jV-ER
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 12:37:42 +0000
Received: from [193.109.254.147:47570] by server-2.bemta-14.messagelabs.com id
	DC/15-19409-59E969F4; Tue, 24 Apr 2012 12:37:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335271061!6108103!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16494 invoked from network); 24 Apr 2012 12:37:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:37:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12105219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:37:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 13:37:40 +0100
Date: Tue, 24 Apr 2012 13:43:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Kevin Wolf <kwolf@redhat.com>
In-Reply-To: <4F9695ED.8010402@redhat.com>
Message-ID: <alpine.DEB.2.00.1204241340430.26786@kaball-desktop>
References: <1335266521-20875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F969080.9000801@redhat.com>
	<alpine.DEB.2.00.1204241246510.26786@kaball-desktop>
	<4F9695ED.8010402@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen_disk: remove syncwrite option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Kevin Wolf wrote:
> > That's because it is based on top of the following two patches:
> > 
> > xen_disk: use bdrv_aio_flush instead of bdrv_flush
> > http://marc.info/?l=qemu-devel&m=133434258008959&w=2
> > 
> > xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
> > http://marc.info/?l=qemu-devel&m=133459581417878&w=2
> > 
> > I have just sent a pull request for them
> > (http://marc.info/?l=qemu-devel&m=133526669019403) after leaving lying
> > around for a while.
> > Next time do you want me to send xen_disk specific pull request to you
> > instead? Sorry if I shouldn't have sent the pull request directly...
> 
> I see. I wasn't aware that you're doing pull requests, but it isn't a
> problem. It just means that you should probably do a pull request for
> this one as well instead of expecting that I pick it up. But you can
> have my Acked-by, if you like.
> 
> Should I ignore xen_disk patches from now on for the block branch and
> assume that you pick them up?

I am happy to issue pull requests for xen_disk patches, but I still
welcome your reviews :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:47:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMf9b-00050J-9b; Tue, 24 Apr 2012 12:47:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMf9Z-00050C-5m
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:47:33 +0000
Received: from [85.158.139.83:64387] by server-11.bemta-5.messagelabs.com id
	8C/C8-12959-4E0A69F4; Tue, 24 Apr 2012 12:47:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335271650!24581074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13937 invoked from network); 24 Apr 2012 12:47:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:47:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12105758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:46:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 13:46:37 +0100
Date: Tue, 24 Apr 2012 13:52:31 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204241409.44044.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F95C158.7030703@vido.info>
	<4F96720E020000780007F82E@nat28.tlf.novell.com>
	<201204241409.44044.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Tobias Geiger wrote:
> Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> > >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> > >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> > >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > >>>> Hello!
> > >>>> 
> > >>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3
> > >>>> and rc4 tested) as Dom0 Kernel;
> > >>>> 
> > >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> > >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> > >>>> With 3.4 it drops to about a third of that.
> > >>>> 
> > >>>> Xen Version is xen-unstable:
> > >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> > >>>> 25209:e6b20ec1824c
> > >>>> 
> > >>>> Disk config line is:
> > >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> > >>>> - it uses blkback.
> > >>> 
> > >>> I fail to see what could be the cause of the issue: nothing on the
> > >>> blkback side should affect performances significantly.
> > >>> You could try reverting the four patches to blkback that were applied
> > >>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
> > >>> regression:
> > >>> 
> > >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> > >>> 
> > >>> Daniel De Graaf (2):
> > >>>        xen/blkback: use grant-table.c hypercall wrappers
> > >> 
> > >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> > >> the compiler would have kept the result of the first call to vaddr(req,
> > >> i) somewhere.. but not sure) lost with the mentioned patch:
> > >> 
> > >> diff --git a/drivers/block/xen-blkback/blkback.c
> > > 
> > > b/drivers/block/xen-blkback/blkback.c
> > > 
> > >> index 73f196c..65dbadc 100644
> > >> --- a/drivers/block/xen-blkback/blkback.c
> > >> +++ b/drivers/block/xen-blkback/blkback.c
> > >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> > >> *req)
> > >> 
> > >>   	int ret;
> > >>   	
> > >>   	for (i = 0; i<  req->nr_pages; i++) {
> > >> 
> > >> +		unsigned long addr;
> > >> 
> > >>   		handle = pending_handle(req, i);
> > >>   		if (handle == BLKBACK_INVALID_HANDLE)
> > >>   		
> > >>   			continue;
> > >> 
> > >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> > >> +		addr = vaddr(req, i);
> > >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> > >> 
> > >>   				    GNTMAP_host_map, handle);
> > >>   		
> > >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> > >> 
> > >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> > >> +		pages[invcount] = virt_to_page(addr);
> > >> 
> > >>   		invcount++;
> > >>   	
> > >>   	}
> > >>   	
> > >>>        xen/blkback: Enable blkback on HVM guests
> > >>> 
> > >>> Konrad Rzeszutek Wilk (2):
> > >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> > >>>        type. xen/blkback: Make optional features be really optional.
> > >>> 
> > >>> _______________________________________________
> > >>> Xen-devel mailing list
> > >>> Xen-devel@lists.xen.org
> > >>> http://lists.xen.org/xen-devel
> > > 
> > > that made it even worse :)
> > > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> > 
> > I doubt this patch can have any meaningful positive or negative
> > performance effect at all - are you sure you're doing comparable
> > runs? After all this is all just about a few arithmetic operations
> > and an array access, which I'd expect to hide in the noise.
> > 
> > Jan
> 
> I redid the test; 
> 
> a) with 3.3.0 kernel 
> b) with 3.4.0-rc4
> c) with 3.40-rc4 and above patch
> 
> everything else remained the same, i.e. test-program and test-scenario was not 
> changed and started after about 5min of domu bootup (so that no strange 
> bootup-effects become relevant); same phy-backend (lvm on ssd), same everything 
> else; so i cant see what else except the used dom0 kernel is causing this 
> issue; but here are the numbers:
> 
> a) read: 135mb/s write: 142mb/s
> b) read: 39mb/s  write: 39mb/s
> c) read: 40mb/s  write: 40mb/s
> 
> Only thing that may become relevant is the difference in kernel-config betwen 
> 3.3 and 3.4 - here's the diff :
> http://pastebin.com/raw.php?i=Dy71Fegq
> 
> Jan, it seems you're right: The patch doesn't add extra performance regression 
> - i guess i had an i/o intensive task running in dom0 while doing the 
> benchmark yesterday, so that the write performance got so bad. sorry for that.
> 
> Still there's a significant performance penalty from 3.3 to 3.4 

Could you please try to revert the following commits?

git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
git revert -n 9846ff10af12f9e7caac696737db6c990592a74a

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:47:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMf9b-00050J-9b; Tue, 24 Apr 2012 12:47:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMf9Z-00050C-5m
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:47:33 +0000
Received: from [85.158.139.83:64387] by server-11.bemta-5.messagelabs.com id
	8C/C8-12959-4E0A69F4; Tue, 24 Apr 2012 12:47:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335271650!24581074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13937 invoked from network); 24 Apr 2012 12:47:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:47:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12105758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:46:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 13:46:37 +0100
Date: Tue, 24 Apr 2012 13:52:31 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204241409.44044.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F95C158.7030703@vido.info>
	<4F96720E020000780007F82E@nat28.tlf.novell.com>
	<201204241409.44044.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Tobias Geiger wrote:
> Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> > >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> > >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> > >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > >>>> Hello!
> > >>>> 
> > >>>> i noticed a considerable drop in I/O Performance when using 3.4 (rc3
> > >>>> and rc4 tested) as Dom0 Kernel;
> > >>>> 
> > >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> > >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> > >>>> With 3.4 it drops to about a third of that.
> > >>>> 
> > >>>> Xen Version is xen-unstable:
> > >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> > >>>> 25209:e6b20ec1824c
> > >>>> 
> > >>>> Disk config line is:
> > >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> > >>>> - it uses blkback.
> > >>> 
> > >>> I fail to see what could be the cause of the issue: nothing on the
> > >>> blkback side should affect performances significantly.
> > >>> You could try reverting the four patches to blkback that were applied
> > >>> between 3.3 and 3.4-rc3 just to make sure it is not a blkback
> > >>> regression:
> > >>> 
> > >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> > >>> 
> > >>> Daniel De Graaf (2):
> > >>>        xen/blkback: use grant-table.c hypercall wrappers
> > >> 
> > >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> > >> the compiler would have kept the result of the first call to vaddr(req,
> > >> i) somewhere.. but not sure) lost with the mentioned patch:
> > >> 
> > >> diff --git a/drivers/block/xen-blkback/blkback.c
> > > 
> > > b/drivers/block/xen-blkback/blkback.c
> > > 
> > >> index 73f196c..65dbadc 100644
> > >> --- a/drivers/block/xen-blkback/blkback.c
> > >> +++ b/drivers/block/xen-blkback/blkback.c
> > >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> > >> *req)
> > >> 
> > >>   	int ret;
> > >>   	
> > >>   	for (i = 0; i<  req->nr_pages; i++) {
> > >> 
> > >> +		unsigned long addr;
> > >> 
> > >>   		handle = pending_handle(req, i);
> > >>   		if (handle == BLKBACK_INVALID_HANDLE)
> > >>   		
> > >>   			continue;
> > >> 
> > >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> > >> +		addr = vaddr(req, i);
> > >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> > >> 
> > >>   				    GNTMAP_host_map, handle);
> > >>   		
> > >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> > >> 
> > >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> > >> +		pages[invcount] = virt_to_page(addr);
> > >> 
> > >>   		invcount++;
> > >>   	
> > >>   	}
> > >>   	
> > >>>        xen/blkback: Enable blkback on HVM guests
> > >>> 
> > >>> Konrad Rzeszutek Wilk (2):
> > >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> > >>>        type. xen/blkback: Make optional features be really optional.
> > >>> 
> > >>> _______________________________________________
> > >>> Xen-devel mailing list
> > >>> Xen-devel@lists.xen.org
> > >>> http://lists.xen.org/xen-devel
> > > 
> > > that made it even worse :)
> > > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> > 
> > I doubt this patch can have any meaningful positive or negative
> > performance effect at all - are you sure you're doing comparable
> > runs? After all this is all just about a few arithmetic operations
> > and an array access, which I'd expect to hide in the noise.
> > 
> > Jan
> 
> I redid the test; 
> 
> a) with 3.3.0 kernel 
> b) with 3.4.0-rc4
> c) with 3.40-rc4 and above patch
> 
> everything else remained the same, i.e. test-program and test-scenario was not 
> changed and started after about 5min of domu bootup (so that no strange 
> bootup-effects become relevant); same phy-backend (lvm on ssd), same everything 
> else; so i cant see what else except the used dom0 kernel is causing this 
> issue; but here are the numbers:
> 
> a) read: 135mb/s write: 142mb/s
> b) read: 39mb/s  write: 39mb/s
> c) read: 40mb/s  write: 40mb/s
> 
> Only thing that may become relevant is the difference in kernel-config betwen 
> 3.3 and 3.4 - here's the diff :
> http://pastebin.com/raw.php?i=Dy71Fegq
> 
> Jan, it seems you're right: The patch doesn't add extra performance regression 
> - i guess i had an i/o intensive task running in dom0 while doing the 
> benchmark yesterday, so that the write performance got so bad. sorry for that.
> 
> Still there's a significant performance penalty from 3.3 to 3.4 

Could you please try to revert the following commits?

git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
git revert -n 9846ff10af12f9e7caac696737db6c990592a74a

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfFo-0005BI-4y; Tue, 24 Apr 2012 12:54:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfFn-0005BC-6P
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:53:59 +0000
Received: from [85.158.138.51:49729] by server-11.bemta-3.messagelabs.com id
	24/53-18894-662A69F4; Tue, 24 Apr 2012 12:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335272037!23597343!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6983 invoked from network); 24 Apr 2012 12:53:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:53:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12105924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:53:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:53:32 +0100
Message-ID: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 24 Apr 2012 13:53:31 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt
bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv
bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg
ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQoJCQkJCQk8PCBXRSBBUkUgSEVSRQpNaWQvTGF0ZSBB
cHJpbCAgLS0gRmlyc3QgcmVsZWFzZSBjYW5kaWRhdGUJPDwgU0VFIEJFTE9XCldlZWtseSAgICAg
ICAgICAtLSBSQ04rMSB1bnRpbCBpdCBpcyByZWFkeQoKTXkgaW5pdGlhbCBndWVzc3RpbWF0ZSBm
b3Igc3RhcnRpbmcgUkNzIGFwcGVhcnMgdG8gaGF2ZSBiZWVuIHNvbWV3aGF0Cm9wdGltaXN0aWMu
IEkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIHJlZHVjZWQgYXQgbGVhc3QgdGhlIGJsb2NrZXJzIGxp
c3RzCnJhdGhlciBzaWduaWZpY2FudGx5IGJlZm9yZSB3ZSBzdGFydCB0aGlua2luZyBvZiBkb2lu
ZyBSQ3MuCgpBIGZhaXJseSBsYXJnZSBwcm9wb3J0aW9uIG9mIHRoZSBsaXN0IGhhcyBiZWVuIHBv
c3RlZCBhdCBsZWFzdCBvbmNlLCBhbmQKbXVjaCBvZiBpdCBzZWVtcyByZWFkeSAob3IgYWxtb3N0
IHJlYWR5KSB0byBnbyBpbi4gVGhlcmUgYXJlIGhvd2V2ZXIKc3RpbGwgc29tZSBzbWFsbGVyIGl0
ZW1zIHdoaWNoIGFyZSB1bmNsYWltZWQuIEJhc2VkIG9uIGZlZWRiYWNrIGZyb20KdGhvc2Ugd2hv
IGFyZSB3b3JraW5nIG9uIHRoZSBiaWdnZXIgb3V0c3RhbmRpbmcgaXRlbXMgaXQgc2VlbXMgbGlr
ZSBtb3N0Cm9mIHRoZW0gb3VnaHQgdG8gYmUgcmVhZHkgdG8gbGFuZCBpbiB0aGUgbmV4dCBmZXcg
d2Vla3MuCgpPbiB0aGF0IGJhc2lzIEkgdGhpbmsgZG9pbmcgYSBmaXJzdCByZWxlYXNlIGNhbmRp
ZGF0ZSBpbiBNaWQvTGF0ZSBNYXkgaXMKbW9yZSByZWFsaXN0aWMuIEknbGwgcmVmbGVjdCB0aGF0
IGluIG5leHQgd2Vla3MgdXBkYXRlCgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVy
IHRoZSByZWxlYXNlIHBsYW4gYSBzdHJvbmcgY2FzZSB3aWxsCm5vdyBoYXZlIHRvIGJlIG1hZGUg
YXMgdG8gd2h5IG5ldyBpdGVtcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3QsCmVzcGVjaWFs
bHkgYXMgYSBibG9ja2VyLCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpoeXBlcnZpc29y
LCBibG9ja2VyczoKICAgICAgKiBbQlVHXSBab21iaWUgZHJpdmVyIGRvbWFpbnMuICBUaGVyZSdz
IGEgYnVnIHdoZXJlIFBWIGd1ZXN0cyB3aXRoCiAgICAgICAgZGV2aWNlcyBwYXNzZWQgdGhyb3Vn
aCB3aXRoIHhsIGhhbmcgYXJvdW5kIGFzICJ6b21iaWVzIiwgd2l0aAogICAgICAgIG9uZSBvdXRz
dGFuZGluZyBwYWdlIHJlZmVyZW5jZS4gIEkgdGhpbmsgdGhpcyBzaG91bGQgcmVhbGx5IGJlIGEK
ICAgICAgICBibG9ja2VyLiBJJ20gd29ya2luZyBvbiB0aGlzIGF0IHRoZSBtb21lbnQgKEdlb3Jn
ZSBEdW5sYXApLgogICAgICAgICAgICAgICogT25lIG9mIHNldmVyYWwgcmVjZW50IHJlcG9ydHMg
b2YgWm9tYmllIGRvbWFpbnMsIHdoaWNoCiAgICAgICAgICAgICAgICBtYXkgb3IgbWF5IG5vdCBi
ZSBhbGwgcmVsYXRlZC4KICAgICAgICAgICAgICAqIExpc3QgYXMgaHlwZXJ2aXNvciBmb3Igbm93
LCBidXQgbWF5IHR1cm4gb3V0IHRvIGJlIGEKICAgICAgICAgICAgICAgIHRvb2xzIGlzc3VlLgog
ICAgICAgIEZpeGVkIChET05FLCBUaW0gRGVlZ2FuKQogICAgICAqIFBlcmZvcm1hbmNlIHJlZ3Jl
c3Npb24gZHVlIHRvIGNvbnRlbnRpb24gb24gcDJtIGxvY2suIChUaW0sCiAgICAgICAgQW5kcmVz
KQogCnRvb2xzLCBibG9ja2VyczoKICAgICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxk
IGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKICAgICAgICB3aGljaCBkb3duc3RyZWFt
J3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCiAgICAgICAg
dGhpcyBhcmU6CiAgICAgICAgICAgICAgKiBTYWZlIGZvcmsgdnMuIGZkIGhhbmRsaW5nIGhvb2tz
LiBJbnZvbHZlcyBBUEkgY2hhbmdlcwogICAgICAgICAgICAgICAgKElhbiBKLCBwYXRjaGVzIHBv
c3RlZCkKICAgICAgICAgICAgICAqIGxpYnhsX3dhaXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dh
aXRfZm9yX21lbW9yeV90YXJnZXQuCiAgICAgICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4g
b3ZlcmhhdWwsIHJlbGF0ZWQgdG8KICAgICAgICAgICAgICAgIGxvY2tpbmcvc2VyaWFsaXphdGlv
biBvdmVyIGRvbWFpbiBjcmVhdGUgKGRlZmVycmVkIHRvCiAgICAgICAgICAgICAgICA0LjMpLiBJ
YW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMgaW50ZXJmYWNlIGJlaW5nCiAgICAgICAgICAgICAg
ICBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVyIHRvIDQuMy4KICAgICAgICAgICAgICAq
IGxpYnhsX3tGT099X2V4ZWMuIFNob3VsZCByZXR1cm4gYSBkYXRhIHN0cnVjdHVyZQogICAgICAg
ICAgICAgICAgZGVjbGFyaW5nIHdoYXQgdG8gZG8sIG5vdCBmb3JrIGFuZCBleGVjIHRoZW1zZWx2
ZXMuCiAgICAgICAgICAgICAgICBIb3dldmVyIHdlIGNhbiBkZWZlciB0aGlzIHVudGlsIDQuMyAo
dGhlcmVmb3JlIERPTkUgd2l0aAogICAgICAgICAgICAgICAgbm8gd29yaykuCiAgICAgICAgICAg
ICAgKiBsaWJ4bF8qX3BhdGguIE1ham9yaXR5IG1hZGUgaW50ZXJuYWwsIG9ubHkgY29uZmlnZGly
IGFuZAogICAgICAgICAgICAgICAgbG9ja2RpciByZW1haW4gcHVibGljICh1c2VkIGJ5IHhsKS4g
R29vZCBlbm91Z2g/CiAgICAgICAgICAgICAgKiBJbnRlcmZhY2VzIHdoaWNoIG1heSBuZWVkIHRv
IGJlIGFzeW5jOgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fc3VzcGVuZC4g
UHJvYmFibHkgbmVlZCB0byBtb3ZlCiAgICAgICAgICAgICAgICAgICAgICAgIHhjX2RvbWFpbl9z
YXZlIGludG8gYSBzZXBhcmF0ZSBwcm9jZXNzLCBhcyBwZXIKICAgICAgICAgICAgICAgICAgICAg
ICAgPDIwMzY2LjQwMTgzLjQxMDM4OC40NDc2MzBAbWFyaW5lci51ay54ZW5zb3VyY2UuY29tPi4g
TGlrZWx5IG5lZWQgdG8gZG8gdGhlIHNhbWUgZm9yIHhjX2RvbWFpbl9yZXN0b3JlIHRvby4gSSdt
IG5vdCBzdXJlIGlmIElhbkogaXMgd29ya2luZyAob3IgcGxhbm5pbmcgdG8gd29yayBvbikgdGhp
cy4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZG9tYWluX2NyZWF0ZV97bmV3LHJlc3Rv
cmV9IC0tIElhbkogaGFzCiAgICAgICAgICAgICAgICAgICAgICAgIHBhdGNoZXMgYXMgcGFydCBv
ZiBldmVudCBzZXJpZXMuCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9jb3Jl
X2R1bXAuIENhbiB0YWtlIGEgZHVtbXkgYW9faG93CiAgICAgICAgICAgICAgICAgICAgICAgIGFu
ZCByZW1haW4gc3luY2hyb25vdXMgaW50ZXJuYWxseS4gKElhbkMsIHBhdGNoCiAgICAgICAgICAg
ICAgICAgICAgICAgIHBvc3RlZCkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZGV2aWNl
X3tkaXNrLG5pYyx2a2IsYWRkfV9hZGQgKGFuZAogICAgICAgICAgICAgICAgICAgICAgICByZW1v
dmU/KS4gUm9nZXIgUGF1IE1vbm7DqSBmaXhlcyBkaXNrIGFzIHBhcnQgb2YKICAgICAgICAgICAg
ICAgICAgICAgICAgaG90cGx1ZyBzY3JpcHQgc2VyaWVzIGFuZCBhZGRzIGluZnJhc3RydWN0dXJl
CiAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoIHNob3VsZCBtYWtlIHRoZSBvdGhlcnMgdHJp
dmlhbC4gKFJvZ2VyCiAgICAgICAgICAgICAgICAgICAgICAgIGludmVzdGlnYXRpbmcpCiAgICAg
ICAgICAgICAgICAgICAgICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25j
ZQogICAgICAgICAgICAgICAgICAgICAgICBkaXNrX3thZGQscmVtb3ZlfSBkb25lLCBJYW5KIHRv
IGxvb2sgYXQgKG9yCiAgICAgICAgICAgICAgICAgICAgICAgIGRvaW5nIHNvPykuCiAgICAgICAg
ICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV9kaXNrX2xvY2FsX3thdHRhY2gsZGV0YWNofS4g
QmVjb21lCiAgICAgICAgICAgICAgICAgICAgICAgIGludGVybmFsIGFzIHBhcnQgb2YgU3RlZmFu
bydzIGRvbWFpbiAwIGRpc2sKICAgICAgICAgICAgICAgICAgICAgICAgYXR0YWNoIHNlcmllcyAo
cGF0Y2hlcyBwb3N0ZWQpCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV9wY2lf
e2FkZCxyZW1vdmV9LiBSb2dlcgogICAgICAgICAgICAgICAgICAgICAgICBpbnZlc3RpZ2F0aW5n
IGFsb25nIHdpdGggb3RoZXIgYWRkLHJlbW92ZQogICAgICAgICAgICAgICAgICAgICAgICBmdW5j
dGlvbnMuCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX3hlbl90bWVtXyouIEFsbCBmdW5j
dGlvbnMgYXJlICJmYXN0IiBhbmQKICAgICAgICAgICAgICAgICAgICAgICAgdGhlcmVmb3JlIG5v
IGFzeW5jIG5lZWRlZC4gRXhjZXB0aW9uIGlzCiAgICAgICAgICAgICAgICAgICAgICAgIHRtZW1f
ZGVzdHJveSB3aGljaCBEYW4gTWFnZW5oZWltZXIgc2F5cyBpcwogICAgICAgICAgICAgICAgICAg
ICAgICBvYnNvbGV0ZSBhbmQgY2FuIGp1c3QgYmUgcmVtb3ZlZC4gKElhbiBDLCBwYXRjaAogICAg
ICAgICAgICAgICAgICAgICAgICBwb3N0ZWQgdG8gcmVtb3ZlIHRtZW1fZGVzdHJveSkKICAgICAg
ICAgICAgICAgICAgICAgICogbGlieGxfZm9yayAtLSBJYW5KJ3MgZXZlbnQgc2VyaWVzIHdpbGwg
cmVtb3ZlCiAgICAgICAgICAgICAgICAgICAgICAgIGFsbCB1c2VycyBvZiB0aGlzLgogICAgICAq
IFtCVUddIE1hbnVhbGx5IGJhbGxvb25pbmcgZG9tMC4gIHhsIG1lbS1zZXQgMCBbZm9vXSBmYWls
cyB3aXRoCiAgICAgICAgImxpYnhsOiBlcnJvcjogbGlieGwuYzoyNTY5OmxpYnhsX3NldF9tZW1v
cnlfdGFyZ2V0OiBjYW5ub3QgZ2V0CiAgICAgICAgbWVtb3J5IGluZm8gZnJvbSAvbG9jYWwvZG9t
YWluLzAvbWVtb3J5L3N0YXRpYy1tYXg6IE5vIHN1Y2ggZmlsZQogICAgICAgIG9yIGRpcmVjdG9y
eSIuIFRoaXMgbWlnaHQgYmUgc3VpdGFibGUgZm9yIGFuIGVudGh1c2lhc3RpYwogICAgICAgIG9u
LWxvb2tlci4gKEdlb3JnZSBEdW5sYXAsIGluIHRoZSBhYnNlbmNlIG9mIHNhaWQgb25sb29rZXIp
CiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgogICAgICAgICAgICAgICogW0JVR10g
Y2Fubm90IGNyZWF0ZSBhbiBlbXB0eSBDRC1ST00gZHJpdmVyIG9uIEhWTSBndWVzdCwKICAgICAg
ICAgICAgICAgIHJlcG9ydGVkIGJ5IEZhYmlvIEZhbnRvbmkgaW4KICAgICAgICAgICAgICAgIDw0
Rjk2NzJERC4yMDgwOTAyQHRpc2NhbGkuaXQ+CiAgICAgICAgICAgICAgKiBbQlVHXSBkb2VzIG5v
dCBob25vdXIgc2NoZWR1bGVyIHdlaWdodCBwYXJhbXMsIHJlcG9ydGVkCiAgICAgICAgICAgICAg
ICBieSBEaWV0ZXIgQmxvbXMgaW4gPDIwMTIwNDIzMTkzNTE4LkdBMTYxMzRAYmxvbXMuZGU+LAog
ICAgICAgICAgICAgICAgRGlldGVyIGhhcyBwb3N0ZWQgYSBwYXRjaC4KICAgICAgKiBNb3JlIGZv
cm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgogICAg
ICAgIHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAt
cmMxIHRvCiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAgICAgICAgICog
eGwgdG8gcmVmdXNlIHRvIHJ1biBpZiB4ZW5kIGlzIHJ1bm5pZywgUm9nZXIgUGF1IE1vbm7DqQog
ICAgICAgICAgICAgICAgKHBhdGNoIHBvc3RlZCkKICAgICAgKiBEb21haW4gMCBibG9jayBhdHRh
Y2ggJiBnZW5lcmFsIGhvdHBsdWcgd2hlbiB1c2luZyBxZGlzayBiYWNrZW5kCiAgICAgICAgKG5l
ZWQgdG8gc3RhcnQgcWVtdSBhcyBuZWNlc3NhcnkgZXRjKSAoU3RlZmFubyBTLCBwYXRjaGVzCiAg
ICAgICAgcG9zdGVkKQogICAgICAqIGZpbGU6Ly8gYmFja2VuZCBwZXJmb3JtYW5jZS4KICAgICAg
ICAgICAgICAqIHFlbXUteGVuLXRyYWRpdGlvbmFsIGFuZCB1cHN0cmVhbSBxZW11LXhlbiBwZXJm
b3JtYW5jZQogICAgICAgICAgICAgICAgaGFzIGJlZW4gaW1wcm92ZWQgYW5kIGlzIG5vdyBzYXRp
c2ZhY3RvcnkuCiAgICAgICAgICAgICAgKiBYZW4gNC4yIHdpbGwgcHJlZmVyIGJsa3RhcDIgaWYg
YSBrZXJuZWwgbW9kdWxlIGlzCiAgICAgICAgICAgICAgICBhdmFpbGFibGUgKGUuZy4gb2xkZXIg
ZG9tMCBrZXJuZWwgb3IgREtNUyBwcm92aWRlZAogICAgICAgICAgICAgICAga2VybmVsIG1vZHVs
ZSkgYW5kIHdpbGwgZmFsbGJhY2sgdG8gcWVtdSBxZGlzayBpZiBubwogICAgICAgICAgICAgICAg
YmxrdGFwMiBpcyBhdmFpbGFibGUuCiAgICAgICAgICAgICAgKiBUaGVyZSB3aWxsIGJlIG5vIHVz
ZXJzcGFjZSAiYmxrdGFwMyIgZm9yIFhlbiA0LjIKICAgICAgKiBJbXByb3ZlZCBIb3RwbHVnIHNj
cmlwdCBzdXBwb3J0IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzCiAgICAgICAgcG9zdGVkKQog
ICAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNj
cmlwdCAoUm9nZXIKICAgICAgICBQYXUgTW9ubsOpKQoKaHlwZXJ2aXNvciwgbmljZSB0byBoYXZl
OgogICAgICAqIHNvbGlkIGltcGxlbWVudGF0aW9uIG9mIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVu
dHMgKHVzaW5nIHdvcmsKICAgICAgICBxdWV1ZXMpIChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcg
ZXQgYWwgLS0gcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICAgICAgICAgKiAiVGhlIGxhc3QgcGF0Y2gg
dG8gdXNlIGEgd2FpdHF1ZXVlIGluCiAgICAgICAgICAgICAgICBfX2dldF9nZm5fdHlwZV9hY2Nl
c3MoKSBmcm9tIFRpbSB3b3Jrcy4gIEhvd2V2ZXIsIHRoZXJlCiAgICAgICAgICAgICAgICBhcmUg
YSBmZXcgdXNlcnMgd2hvIGNhbGwgX19nZXRfZ2ZuX3R5cGVfYWNjZXNzIHdpdGggdGhlCiAgICAg
ICAgICAgICAgICBkb21haW5fbG9jayBoZWxkLiBUaGlzIHBhcnQgbmVlZHMgdG8gYmUgYWRkcmVz
c2VkIGluCiAgICAgICAgICAgICAgICBzb21lIHdheS4iCiAgICAgICAgICAgICAgKiBEZWZlcnJl
ZCB1bnRpbCA0LjMKICAgICAgKiBTaGFyaW5nIHN1cHBvcnQgZm9yIEFNRCAoVGltLCBBbmRyZXMp
LCBpbiwgbWFya2VkIGFzCiAgICAgICAgZXhwZXJpbWVudGFsIChzbywgRE9ORSwgYXMgZmFyIGFz
IDQuMiBpcyBjb25jZXJuZWQpLgogICAgICAqIFBvRCBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudHMg
KEdlb3JnZSBEdW5sYXApCgp0b29scywgbmljZSB0byBoYXZlOgogICAgICAqIENvbmZpZ3VyZS9j
b250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZywgbG90cyBvZgogICAgICAg
IGRpc2N1c3Npb24gYXJvdW5kIGludGVyZmFjZSwgZ2VuZXJhbCBjb25zZW5zdXMgcmVhY2hlZCBv
biB3aGF0CiAgICAgICAgaXQgc2hvdWxkIGxvb2sgbGlrZS4gT2xhZiBoYXMgbGV0IG1lIGtub3cg
dGhhdCBoZSBpcyBwcm9iYWJseQogICAgICAgIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgdG8gZG8g
dGhpcyBmb3IgNC4yLCB3aWxsIGxpa2VseSBzbGlwIHRvCiAgICAgICAgNC4zIHVubGVzcyBzb21l
b25lIGVsc2Ugd2FudCB0byBwaWNrIHVwIHRoYXQgd29yaykKICAgICAgICAgICAgICAqIFdpbGwg
ZGVmZXIgdW50aWwgNC4zLgogICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgog
ICAgICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCAoQW50
aG9ueSBQZXJhcmQsCiAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCiAgICAgICAgICAgICAg
KiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KICAg
ICAgICAgICAgICAgIFN0YWJlbGxpbmksIHFlbXUgcGF0Y2hlcyBhcHBsaWVkLCB3YWl0aW5nIGZv
ciBsaWJ4bCBldGMKICAgICAgICAgICAgICAgIHNpZGUgd2hpY2ggaGFzIGJlZW4gcmVjZW50bHkg
cmVwb3N0ZWQpCiAgICAgICogTmVzdGVkLXZpcnR1YWxpc2F0aW9uLiBDdXJyZW50bHkgImV4cGVy
aW1lbnRhbCIuIExpa2VseSB0bwogICAgICAgIHJlbGVhc2UgdGhhdCB3YXkuCiAgICAgICAgICAg
ICAgKiBOZXN0ZWQgU1ZNLiBUZXN0ZWQgaW4gYSB2YXJpZXR5IG9mIGNvbmZpZ3VyYXRpb25zIGJ1
dAogICAgICAgICAgICAgICAgc3RpbGwgc29tZSBpc3N1ZXMgd2l0aCB0aGUgbW9zdCBpbXBvcnRh
bnQgdXNlIGNhc2UgKHc3CiAgICAgICAgICAgICAgICBYUCBtb2RlKSBbMF0gIChDaHJpc3RvcGgg
RWdnZXIpCiAgICAgICAgICAgICAgKiBOZXN0ZWQgVk1YLiBOZWVkcyBuZXN0ZWQgRVBUIHRvIGJl
IGdlbnVpbmVseSB1c2VmdWwuCiAgICAgICAgICAgICAgICBOZWVkIG1vcmUgZGF0YSBvbiB0ZXN0
ZWRuZXNzIGV0YyAoSW50ZWwpCiAgICAgICAgRE9ORSwgYXQgbGVhc3QgYXMgZmFyIGFzIDQuMiBp
cyBjb25jZXJuZWQuCiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5
IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQogICAgICAgIChTaHJpcmFtLCB3YWl0aW5nIG9uIGxp
YnhsIHNpZGUgb2YgcWVtdSB1cHN0cmVhbSBzYXZlL3Jlc3RvcmUpCiAgICAgICogeGwgY29tcGF0
aWJpbGl0eSB3aXRoIHhtOgogICAgICAgICAgICAgICogeGwgc3VwcG9ydCBmb3IgYXV0b3NwYXdu
aW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKICAgICAgICAgICAgICAgIG90aGVyd2lzZSkg
KEdvbmNhbG8gR29tZXMsIHdhaXRpbmcgb24gbmV3IHZlcnNpb24gb2YKICAgICAgICAgICAgICAg
IHBhdGNoZXMpCiAgICAgICAgICAgICAgKiBzdXBwb3J0IGZvciB2aWYgInJhdGUiIHBhcmFtZXRl
ciAoTWF0aGlldSBHYWduw6ksIGZpcnN0CiAgICAgICAgICAgICAgICBwYXJ0IGFwcGxpZWQpCgpb
MF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9t
c2cwMDg4My5odG1sCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfFo-0005BI-4y; Tue, 24 Apr 2012 12:54:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfFn-0005BC-6P
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:53:59 +0000
Received: from [85.158.138.51:49729] by server-11.bemta-3.messagelabs.com id
	24/53-18894-662A69F4; Tue, 24 Apr 2012 12:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335272037!23597343!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6983 invoked from network); 24 Apr 2012 12:53:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:53:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12105924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:53:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:53:32 +0100
Message-ID: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 24 Apr 2012 13:53:31 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt
bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv
bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg
ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQoJCQkJCQk8PCBXRSBBUkUgSEVSRQpNaWQvTGF0ZSBB
cHJpbCAgLS0gRmlyc3QgcmVsZWFzZSBjYW5kaWRhdGUJPDwgU0VFIEJFTE9XCldlZWtseSAgICAg
ICAgICAtLSBSQ04rMSB1bnRpbCBpdCBpcyByZWFkeQoKTXkgaW5pdGlhbCBndWVzc3RpbWF0ZSBm
b3Igc3RhcnRpbmcgUkNzIGFwcGVhcnMgdG8gaGF2ZSBiZWVuIHNvbWV3aGF0Cm9wdGltaXN0aWMu
IEkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIHJlZHVjZWQgYXQgbGVhc3QgdGhlIGJsb2NrZXJzIGxp
c3RzCnJhdGhlciBzaWduaWZpY2FudGx5IGJlZm9yZSB3ZSBzdGFydCB0aGlua2luZyBvZiBkb2lu
ZyBSQ3MuCgpBIGZhaXJseSBsYXJnZSBwcm9wb3J0aW9uIG9mIHRoZSBsaXN0IGhhcyBiZWVuIHBv
c3RlZCBhdCBsZWFzdCBvbmNlLCBhbmQKbXVjaCBvZiBpdCBzZWVtcyByZWFkeSAob3IgYWxtb3N0
IHJlYWR5KSB0byBnbyBpbi4gVGhlcmUgYXJlIGhvd2V2ZXIKc3RpbGwgc29tZSBzbWFsbGVyIGl0
ZW1zIHdoaWNoIGFyZSB1bmNsYWltZWQuIEJhc2VkIG9uIGZlZWRiYWNrIGZyb20KdGhvc2Ugd2hv
IGFyZSB3b3JraW5nIG9uIHRoZSBiaWdnZXIgb3V0c3RhbmRpbmcgaXRlbXMgaXQgc2VlbXMgbGlr
ZSBtb3N0Cm9mIHRoZW0gb3VnaHQgdG8gYmUgcmVhZHkgdG8gbGFuZCBpbiB0aGUgbmV4dCBmZXcg
d2Vla3MuCgpPbiB0aGF0IGJhc2lzIEkgdGhpbmsgZG9pbmcgYSBmaXJzdCByZWxlYXNlIGNhbmRp
ZGF0ZSBpbiBNaWQvTGF0ZSBNYXkgaXMKbW9yZSByZWFsaXN0aWMuIEknbGwgcmVmbGVjdCB0aGF0
IGluIG5leHQgd2Vla3MgdXBkYXRlCgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVy
IHRoZSByZWxlYXNlIHBsYW4gYSBzdHJvbmcgY2FzZSB3aWxsCm5vdyBoYXZlIHRvIGJlIG1hZGUg
YXMgdG8gd2h5IG5ldyBpdGVtcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3QsCmVzcGVjaWFs
bHkgYXMgYSBibG9ja2VyLCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpoeXBlcnZpc29y
LCBibG9ja2VyczoKICAgICAgKiBbQlVHXSBab21iaWUgZHJpdmVyIGRvbWFpbnMuICBUaGVyZSdz
IGEgYnVnIHdoZXJlIFBWIGd1ZXN0cyB3aXRoCiAgICAgICAgZGV2aWNlcyBwYXNzZWQgdGhyb3Vn
aCB3aXRoIHhsIGhhbmcgYXJvdW5kIGFzICJ6b21iaWVzIiwgd2l0aAogICAgICAgIG9uZSBvdXRz
dGFuZGluZyBwYWdlIHJlZmVyZW5jZS4gIEkgdGhpbmsgdGhpcyBzaG91bGQgcmVhbGx5IGJlIGEK
ICAgICAgICBibG9ja2VyLiBJJ20gd29ya2luZyBvbiB0aGlzIGF0IHRoZSBtb21lbnQgKEdlb3Jn
ZSBEdW5sYXApLgogICAgICAgICAgICAgICogT25lIG9mIHNldmVyYWwgcmVjZW50IHJlcG9ydHMg
b2YgWm9tYmllIGRvbWFpbnMsIHdoaWNoCiAgICAgICAgICAgICAgICBtYXkgb3IgbWF5IG5vdCBi
ZSBhbGwgcmVsYXRlZC4KICAgICAgICAgICAgICAqIExpc3QgYXMgaHlwZXJ2aXNvciBmb3Igbm93
LCBidXQgbWF5IHR1cm4gb3V0IHRvIGJlIGEKICAgICAgICAgICAgICAgIHRvb2xzIGlzc3VlLgog
ICAgICAgIEZpeGVkIChET05FLCBUaW0gRGVlZ2FuKQogICAgICAqIFBlcmZvcm1hbmNlIHJlZ3Jl
c3Npb24gZHVlIHRvIGNvbnRlbnRpb24gb24gcDJtIGxvY2suIChUaW0sCiAgICAgICAgQW5kcmVz
KQogCnRvb2xzLCBibG9ja2VyczoKICAgICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxk
IGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKICAgICAgICB3aGljaCBkb3duc3RyZWFt
J3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCiAgICAgICAg
dGhpcyBhcmU6CiAgICAgICAgICAgICAgKiBTYWZlIGZvcmsgdnMuIGZkIGhhbmRsaW5nIGhvb2tz
LiBJbnZvbHZlcyBBUEkgY2hhbmdlcwogICAgICAgICAgICAgICAgKElhbiBKLCBwYXRjaGVzIHBv
c3RlZCkKICAgICAgICAgICAgICAqIGxpYnhsX3dhaXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dh
aXRfZm9yX21lbW9yeV90YXJnZXQuCiAgICAgICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4g
b3ZlcmhhdWwsIHJlbGF0ZWQgdG8KICAgICAgICAgICAgICAgIGxvY2tpbmcvc2VyaWFsaXphdGlv
biBvdmVyIGRvbWFpbiBjcmVhdGUgKGRlZmVycmVkIHRvCiAgICAgICAgICAgICAgICA0LjMpLiBJ
YW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMgaW50ZXJmYWNlIGJlaW5nCiAgICAgICAgICAgICAg
ICBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVyIHRvIDQuMy4KICAgICAgICAgICAgICAq
IGxpYnhsX3tGT099X2V4ZWMuIFNob3VsZCByZXR1cm4gYSBkYXRhIHN0cnVjdHVyZQogICAgICAg
ICAgICAgICAgZGVjbGFyaW5nIHdoYXQgdG8gZG8sIG5vdCBmb3JrIGFuZCBleGVjIHRoZW1zZWx2
ZXMuCiAgICAgICAgICAgICAgICBIb3dldmVyIHdlIGNhbiBkZWZlciB0aGlzIHVudGlsIDQuMyAo
dGhlcmVmb3JlIERPTkUgd2l0aAogICAgICAgICAgICAgICAgbm8gd29yaykuCiAgICAgICAgICAg
ICAgKiBsaWJ4bF8qX3BhdGguIE1ham9yaXR5IG1hZGUgaW50ZXJuYWwsIG9ubHkgY29uZmlnZGly
IGFuZAogICAgICAgICAgICAgICAgbG9ja2RpciByZW1haW4gcHVibGljICh1c2VkIGJ5IHhsKS4g
R29vZCBlbm91Z2g/CiAgICAgICAgICAgICAgKiBJbnRlcmZhY2VzIHdoaWNoIG1heSBuZWVkIHRv
IGJlIGFzeW5jOgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fc3VzcGVuZC4g
UHJvYmFibHkgbmVlZCB0byBtb3ZlCiAgICAgICAgICAgICAgICAgICAgICAgIHhjX2RvbWFpbl9z
YXZlIGludG8gYSBzZXBhcmF0ZSBwcm9jZXNzLCBhcyBwZXIKICAgICAgICAgICAgICAgICAgICAg
ICAgPDIwMzY2LjQwMTgzLjQxMDM4OC40NDc2MzBAbWFyaW5lci51ay54ZW5zb3VyY2UuY29tPi4g
TGlrZWx5IG5lZWQgdG8gZG8gdGhlIHNhbWUgZm9yIHhjX2RvbWFpbl9yZXN0b3JlIHRvby4gSSdt
IG5vdCBzdXJlIGlmIElhbkogaXMgd29ya2luZyAob3IgcGxhbm5pbmcgdG8gd29yayBvbikgdGhp
cy4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZG9tYWluX2NyZWF0ZV97bmV3LHJlc3Rv
cmV9IC0tIElhbkogaGFzCiAgICAgICAgICAgICAgICAgICAgICAgIHBhdGNoZXMgYXMgcGFydCBv
ZiBldmVudCBzZXJpZXMuCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9jb3Jl
X2R1bXAuIENhbiB0YWtlIGEgZHVtbXkgYW9faG93CiAgICAgICAgICAgICAgICAgICAgICAgIGFu
ZCByZW1haW4gc3luY2hyb25vdXMgaW50ZXJuYWxseS4gKElhbkMsIHBhdGNoCiAgICAgICAgICAg
ICAgICAgICAgICAgIHBvc3RlZCkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZGV2aWNl
X3tkaXNrLG5pYyx2a2IsYWRkfV9hZGQgKGFuZAogICAgICAgICAgICAgICAgICAgICAgICByZW1v
dmU/KS4gUm9nZXIgUGF1IE1vbm7DqSBmaXhlcyBkaXNrIGFzIHBhcnQgb2YKICAgICAgICAgICAg
ICAgICAgICAgICAgaG90cGx1ZyBzY3JpcHQgc2VyaWVzIGFuZCBhZGRzIGluZnJhc3RydWN0dXJl
CiAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoIHNob3VsZCBtYWtlIHRoZSBvdGhlcnMgdHJp
dmlhbC4gKFJvZ2VyCiAgICAgICAgICAgICAgICAgICAgICAgIGludmVzdGlnYXRpbmcpCiAgICAg
ICAgICAgICAgICAgICAgICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25j
ZQogICAgICAgICAgICAgICAgICAgICAgICBkaXNrX3thZGQscmVtb3ZlfSBkb25lLCBJYW5KIHRv
IGxvb2sgYXQgKG9yCiAgICAgICAgICAgICAgICAgICAgICAgIGRvaW5nIHNvPykuCiAgICAgICAg
ICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV9kaXNrX2xvY2FsX3thdHRhY2gsZGV0YWNofS4g
QmVjb21lCiAgICAgICAgICAgICAgICAgICAgICAgIGludGVybmFsIGFzIHBhcnQgb2YgU3RlZmFu
bydzIGRvbWFpbiAwIGRpc2sKICAgICAgICAgICAgICAgICAgICAgICAgYXR0YWNoIHNlcmllcyAo
cGF0Y2hlcyBwb3N0ZWQpCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV9wY2lf
e2FkZCxyZW1vdmV9LiBSb2dlcgogICAgICAgICAgICAgICAgICAgICAgICBpbnZlc3RpZ2F0aW5n
IGFsb25nIHdpdGggb3RoZXIgYWRkLHJlbW92ZQogICAgICAgICAgICAgICAgICAgICAgICBmdW5j
dGlvbnMuCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX3hlbl90bWVtXyouIEFsbCBmdW5j
dGlvbnMgYXJlICJmYXN0IiBhbmQKICAgICAgICAgICAgICAgICAgICAgICAgdGhlcmVmb3JlIG5v
IGFzeW5jIG5lZWRlZC4gRXhjZXB0aW9uIGlzCiAgICAgICAgICAgICAgICAgICAgICAgIHRtZW1f
ZGVzdHJveSB3aGljaCBEYW4gTWFnZW5oZWltZXIgc2F5cyBpcwogICAgICAgICAgICAgICAgICAg
ICAgICBvYnNvbGV0ZSBhbmQgY2FuIGp1c3QgYmUgcmVtb3ZlZC4gKElhbiBDLCBwYXRjaAogICAg
ICAgICAgICAgICAgICAgICAgICBwb3N0ZWQgdG8gcmVtb3ZlIHRtZW1fZGVzdHJveSkKICAgICAg
ICAgICAgICAgICAgICAgICogbGlieGxfZm9yayAtLSBJYW5KJ3MgZXZlbnQgc2VyaWVzIHdpbGwg
cmVtb3ZlCiAgICAgICAgICAgICAgICAgICAgICAgIGFsbCB1c2VycyBvZiB0aGlzLgogICAgICAq
IFtCVUddIE1hbnVhbGx5IGJhbGxvb25pbmcgZG9tMC4gIHhsIG1lbS1zZXQgMCBbZm9vXSBmYWls
cyB3aXRoCiAgICAgICAgImxpYnhsOiBlcnJvcjogbGlieGwuYzoyNTY5OmxpYnhsX3NldF9tZW1v
cnlfdGFyZ2V0OiBjYW5ub3QgZ2V0CiAgICAgICAgbWVtb3J5IGluZm8gZnJvbSAvbG9jYWwvZG9t
YWluLzAvbWVtb3J5L3N0YXRpYy1tYXg6IE5vIHN1Y2ggZmlsZQogICAgICAgIG9yIGRpcmVjdG9y
eSIuIFRoaXMgbWlnaHQgYmUgc3VpdGFibGUgZm9yIGFuIGVudGh1c2lhc3RpYwogICAgICAgIG9u
LWxvb2tlci4gKEdlb3JnZSBEdW5sYXAsIGluIHRoZSBhYnNlbmNlIG9mIHNhaWQgb25sb29rZXIp
CiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgogICAgICAgICAgICAgICogW0JVR10g
Y2Fubm90IGNyZWF0ZSBhbiBlbXB0eSBDRC1ST00gZHJpdmVyIG9uIEhWTSBndWVzdCwKICAgICAg
ICAgICAgICAgIHJlcG9ydGVkIGJ5IEZhYmlvIEZhbnRvbmkgaW4KICAgICAgICAgICAgICAgIDw0
Rjk2NzJERC4yMDgwOTAyQHRpc2NhbGkuaXQ+CiAgICAgICAgICAgICAgKiBbQlVHXSBkb2VzIG5v
dCBob25vdXIgc2NoZWR1bGVyIHdlaWdodCBwYXJhbXMsIHJlcG9ydGVkCiAgICAgICAgICAgICAg
ICBieSBEaWV0ZXIgQmxvbXMgaW4gPDIwMTIwNDIzMTkzNTE4LkdBMTYxMzRAYmxvbXMuZGU+LAog
ICAgICAgICAgICAgICAgRGlldGVyIGhhcyBwb3N0ZWQgYSBwYXRjaC4KICAgICAgKiBNb3JlIGZv
cm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgogICAg
ICAgIHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAt
cmMxIHRvCiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAgICAgICAgICog
eGwgdG8gcmVmdXNlIHRvIHJ1biBpZiB4ZW5kIGlzIHJ1bm5pZywgUm9nZXIgUGF1IE1vbm7DqQog
ICAgICAgICAgICAgICAgKHBhdGNoIHBvc3RlZCkKICAgICAgKiBEb21haW4gMCBibG9jayBhdHRh
Y2ggJiBnZW5lcmFsIGhvdHBsdWcgd2hlbiB1c2luZyBxZGlzayBiYWNrZW5kCiAgICAgICAgKG5l
ZWQgdG8gc3RhcnQgcWVtdSBhcyBuZWNlc3NhcnkgZXRjKSAoU3RlZmFubyBTLCBwYXRjaGVzCiAg
ICAgICAgcG9zdGVkKQogICAgICAqIGZpbGU6Ly8gYmFja2VuZCBwZXJmb3JtYW5jZS4KICAgICAg
ICAgICAgICAqIHFlbXUteGVuLXRyYWRpdGlvbmFsIGFuZCB1cHN0cmVhbSBxZW11LXhlbiBwZXJm
b3JtYW5jZQogICAgICAgICAgICAgICAgaGFzIGJlZW4gaW1wcm92ZWQgYW5kIGlzIG5vdyBzYXRp
c2ZhY3RvcnkuCiAgICAgICAgICAgICAgKiBYZW4gNC4yIHdpbGwgcHJlZmVyIGJsa3RhcDIgaWYg
YSBrZXJuZWwgbW9kdWxlIGlzCiAgICAgICAgICAgICAgICBhdmFpbGFibGUgKGUuZy4gb2xkZXIg
ZG9tMCBrZXJuZWwgb3IgREtNUyBwcm92aWRlZAogICAgICAgICAgICAgICAga2VybmVsIG1vZHVs
ZSkgYW5kIHdpbGwgZmFsbGJhY2sgdG8gcWVtdSBxZGlzayBpZiBubwogICAgICAgICAgICAgICAg
YmxrdGFwMiBpcyBhdmFpbGFibGUuCiAgICAgICAgICAgICAgKiBUaGVyZSB3aWxsIGJlIG5vIHVz
ZXJzcGFjZSAiYmxrdGFwMyIgZm9yIFhlbiA0LjIKICAgICAgKiBJbXByb3ZlZCBIb3RwbHVnIHNj
cmlwdCBzdXBwb3J0IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzCiAgICAgICAgcG9zdGVkKQog
ICAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNj
cmlwdCAoUm9nZXIKICAgICAgICBQYXUgTW9ubsOpKQoKaHlwZXJ2aXNvciwgbmljZSB0byBoYXZl
OgogICAgICAqIHNvbGlkIGltcGxlbWVudGF0aW9uIG9mIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVu
dHMgKHVzaW5nIHdvcmsKICAgICAgICBxdWV1ZXMpIChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcg
ZXQgYWwgLS0gcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICAgICAgICAgKiAiVGhlIGxhc3QgcGF0Y2gg
dG8gdXNlIGEgd2FpdHF1ZXVlIGluCiAgICAgICAgICAgICAgICBfX2dldF9nZm5fdHlwZV9hY2Nl
c3MoKSBmcm9tIFRpbSB3b3Jrcy4gIEhvd2V2ZXIsIHRoZXJlCiAgICAgICAgICAgICAgICBhcmUg
YSBmZXcgdXNlcnMgd2hvIGNhbGwgX19nZXRfZ2ZuX3R5cGVfYWNjZXNzIHdpdGggdGhlCiAgICAg
ICAgICAgICAgICBkb21haW5fbG9jayBoZWxkLiBUaGlzIHBhcnQgbmVlZHMgdG8gYmUgYWRkcmVz
c2VkIGluCiAgICAgICAgICAgICAgICBzb21lIHdheS4iCiAgICAgICAgICAgICAgKiBEZWZlcnJl
ZCB1bnRpbCA0LjMKICAgICAgKiBTaGFyaW5nIHN1cHBvcnQgZm9yIEFNRCAoVGltLCBBbmRyZXMp
LCBpbiwgbWFya2VkIGFzCiAgICAgICAgZXhwZXJpbWVudGFsIChzbywgRE9ORSwgYXMgZmFyIGFz
IDQuMiBpcyBjb25jZXJuZWQpLgogICAgICAqIFBvRCBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudHMg
KEdlb3JnZSBEdW5sYXApCgp0b29scywgbmljZSB0byBoYXZlOgogICAgICAqIENvbmZpZ3VyZS9j
b250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZywgbG90cyBvZgogICAgICAg
IGRpc2N1c3Npb24gYXJvdW5kIGludGVyZmFjZSwgZ2VuZXJhbCBjb25zZW5zdXMgcmVhY2hlZCBv
biB3aGF0CiAgICAgICAgaXQgc2hvdWxkIGxvb2sgbGlrZS4gT2xhZiBoYXMgbGV0IG1lIGtub3cg
dGhhdCBoZSBpcyBwcm9iYWJseQogICAgICAgIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgdG8gZG8g
dGhpcyBmb3IgNC4yLCB3aWxsIGxpa2VseSBzbGlwIHRvCiAgICAgICAgNC4zIHVubGVzcyBzb21l
b25lIGVsc2Ugd2FudCB0byBwaWNrIHVwIHRoYXQgd29yaykKICAgICAgICAgICAgICAqIFdpbGwg
ZGVmZXIgdW50aWwgNC4zLgogICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgog
ICAgICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCAoQW50
aG9ueSBQZXJhcmQsCiAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCiAgICAgICAgICAgICAg
KiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KICAg
ICAgICAgICAgICAgIFN0YWJlbGxpbmksIHFlbXUgcGF0Y2hlcyBhcHBsaWVkLCB3YWl0aW5nIGZv
ciBsaWJ4bCBldGMKICAgICAgICAgICAgICAgIHNpZGUgd2hpY2ggaGFzIGJlZW4gcmVjZW50bHkg
cmVwb3N0ZWQpCiAgICAgICogTmVzdGVkLXZpcnR1YWxpc2F0aW9uLiBDdXJyZW50bHkgImV4cGVy
aW1lbnRhbCIuIExpa2VseSB0bwogICAgICAgIHJlbGVhc2UgdGhhdCB3YXkuCiAgICAgICAgICAg
ICAgKiBOZXN0ZWQgU1ZNLiBUZXN0ZWQgaW4gYSB2YXJpZXR5IG9mIGNvbmZpZ3VyYXRpb25zIGJ1
dAogICAgICAgICAgICAgICAgc3RpbGwgc29tZSBpc3N1ZXMgd2l0aCB0aGUgbW9zdCBpbXBvcnRh
bnQgdXNlIGNhc2UgKHc3CiAgICAgICAgICAgICAgICBYUCBtb2RlKSBbMF0gIChDaHJpc3RvcGgg
RWdnZXIpCiAgICAgICAgICAgICAgKiBOZXN0ZWQgVk1YLiBOZWVkcyBuZXN0ZWQgRVBUIHRvIGJl
IGdlbnVpbmVseSB1c2VmdWwuCiAgICAgICAgICAgICAgICBOZWVkIG1vcmUgZGF0YSBvbiB0ZXN0
ZWRuZXNzIGV0YyAoSW50ZWwpCiAgICAgICAgRE9ORSwgYXQgbGVhc3QgYXMgZmFyIGFzIDQuMiBp
cyBjb25jZXJuZWQuCiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5
IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQogICAgICAgIChTaHJpcmFtLCB3YWl0aW5nIG9uIGxp
YnhsIHNpZGUgb2YgcWVtdSB1cHN0cmVhbSBzYXZlL3Jlc3RvcmUpCiAgICAgICogeGwgY29tcGF0
aWJpbGl0eSB3aXRoIHhtOgogICAgICAgICAgICAgICogeGwgc3VwcG9ydCBmb3IgYXV0b3NwYXdu
aW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKICAgICAgICAgICAgICAgIG90aGVyd2lzZSkg
KEdvbmNhbG8gR29tZXMsIHdhaXRpbmcgb24gbmV3IHZlcnNpb24gb2YKICAgICAgICAgICAgICAg
IHBhdGNoZXMpCiAgICAgICAgICAgICAgKiBzdXBwb3J0IGZvciB2aWYgInJhdGUiIHBhcmFtZXRl
ciAoTWF0aGlldSBHYWduw6ksIGZpcnN0CiAgICAgICAgICAgICAgICBwYXJ0IGFwcGxpZWQpCgpb
MF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9t
c2cwMDg4My5odG1sCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:54:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfGJ-0005Dr-OS; Tue, 24 Apr 2012 12:54:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SMfGI-0005De-E2
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:54:30 +0000
Received: from [85.158.138.51:57228] by server-12.bemta-3.messagelabs.com id
	12/AC-29760-582A69F4; Tue, 24 Apr 2012 12:54:29 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335272066!14613229!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 795 invoked from network); 24 Apr 2012 12:54:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:54:28 -0000
Received: by obbwd18 with SMTP id wd18so1216246obb.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 05:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jTngAjK631kbRwQDXMiDkhvqGBgCEPf1amwjfpPDQyE=;
	b=N54yEforUAmeIte+XO1rx174UI6mogqVZNtFvyGcziD9oHcAWxmWYR4tT1lqVQNW0l
	NcC/5X7Nz/NxX2uzo+LMVtkf6xDK2Z4imoux1chMm3YVe58xdPvCv2GBtaNEn0Gc/wPs
	2n/g2ULp+1EJ0JVXqGJtGEtnOdySzpCpKvG3GmOCOFv61yfXbhzwzZNsgt2T0mx5uFOI
	NNkwY3Rrd/KMxZv+FazBAVFvl6ndRlEkKCHt9dLsMdwTpcvaq1CpGiJujEISEE3POQ1k
	NissKGnd/qOQNNsnFQJVGAy3fFdqAcD87mqm6HhOFZwOLBUyyzcqY3vBnfOknFLgDnJ9
	Y5TQ==
MIME-Version: 1.0
Received: by 10.182.36.99 with SMTP id p3mr2733467obj.47.1335272066519; Tue,
	24 Apr 2012 05:54:26 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Tue, 24 Apr 2012 05:54:26 -0700 (PDT)
In-Reply-To: <CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
	<20120423162359.GG2058@reaktio.net>
	<CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
Date: Tue, 24 Apr 2012 09:54:26 -0300
Message-ID: <CAJP76_B35EVJGEoXSP9K7=1y=7yrjNH1ofe5-WqSDggY9ow53Q@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3689357105362085809=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3689357105362085809==
Content-Type: multipart/alternative; boundary=f46d0445178734118504be6c41ee

--f46d0445178734118504be6c41ee
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,

I didn't really understand when You said "I was talking about dom0 Linux
kernel, not about Xen", coz I understand you must be in xen to access dom0.
Look: in my grub2 I have these options in grub2:

Xen Unstable / Debian Squeeze kernel 2.6.32.40
Debian GNU/Linux, with Linux 2.6.32.40
Debian GNU/Linux, with Linux 2.6.32-5-686

I select first option and the system returns:

error: couldn't open file
error: you need to load the multiboot kernel first

The second option is in graphical environment but keyboard and mouse don't
work there. I thought You said to enter within this option (but I think
this option is not important)

And the third option is my environment where I compiled and installed xen
and Debian GNU/Linux, with Linux 2.6.32.40.
Here I do command "# /etc/init.d/xend start" and the system returns
"xencommons should be started first", but I had done
"/etc/init.d/xencommons start" before and no error message returned !!!???

and then... what do you think?

Eduardo


Em 23 de abril de 2012 13:45, Jos=E9 Eduardo Fran=E7a <jefranca@gmail.com>e=
screveu:

> Pasi
>
> I didn't think this. I'll be in my job tomorrow an I'll reply there.
>
> Thank you
>
> Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <pasik@iki.fi> escreveu=
:
>
> On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>> >    Hi Pasi,
>> >
>> >    thank you for reply.
>> >
>> >    I'm using Debian Squeeze, and I'm compiling Xen from source
>> (.tar.gz). I
>> >    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
>> >
>> >    Notice: I couldn't run in xen_unstable or dom0 then I returned to
>> install
>> >    environment (Debian Squeeze)
>> >
>> >    My attempt with modules and now with xenstored command (oxenstored
>> command
>> >    works) was in Debian Squeeze. In this case I think I can't load the=
se
>> >    modules or run this command, but I'm not sure. Then your questions
>> can not
>> >    be in this scope. What do you think?
>> >
>>
>> I was talking about dom0 Linux kernel, not about Xen.
>>
>> -- Pasi
>>
>>
>> >    Thanks, Eduardo
>> >
>> >    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>> escreveu:
>> >
>> >      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a
>> wrote:
>> >      >    hi guys,
>> >      >
>> >
>> >      Hello,
>> >      >    It's my first time here and in a mailing lists, I only
>> participated
>> >      in
>> >      >    forums before. Please, If I make a mistake you should advise
>> me.
>> >      Let's go!
>> >      >
>> >      >    I was reading "xencommons not start" in a Remus Forum in
>> order to
>> >      install
>> >      >    Remus.
>> >      >    Well* I followed the tutorial
>> >      >
>> >       <[1][2]
>> http://remusha.wikidot.com/configuring-and-installing-remus>, I
>> >      reboot
>> >      >    in xen_unstable and I had a error message:
>> >      >
>> >      >    error: couldn't open file
>> >      >    error: you need to load the multiboot kernel first
>> >      >
>> >      >    then I redid tutorial after "Adapt Grub" and in a moment I d=
o
>> >      command:
>> >      >
>> >      >    # /etc/init.d/xend start
>> >      >    xencommons should be started first.
>> >      >
>> >      >    but I had done "/etc/init.d/xencommons start" before and no
>> error
>> >      message
>> >      >    returned !!!???
>> >      >
>> >      >    I also tried insert modules manually (coz in other mailing
>> list
>> >      said to
>> >      >    put some modules - see my setups after this mail) but I had:
>> >      >
>> >      >    # modprobe xen-evtchn
>> >      >    FATAL: Module xen_evtchn not found.
>> >      >
>> >
>> >      So xen event channel support is not compiled as a module?
>> >      is it enabled at all in your dom0 kernel config?
>> >
>> >      [3]
>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>> >      -- Pasi
>> >
>> > References
>> >
>> >    Visible links
>> >    1. mailto:pasik@iki.fi
>> >    2. http://remusha.wikidot.com/configuring-and-installing-remus
>> >    3.
>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>>
>
>

--f46d0445178734118504be6c41ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Pasi,<br><br>I didn&#39;t really understand when=
 You said &quot;I was talking about dom0 Linux kernel, not about Xen&quot;,=
 coz I understand you must be in xen to access dom0.<br>Look: in my grub2 I=
 have these options in grub2:<br>
<br>Xen Unstable / Debian Squeeze kernel 2.6.32.40<br>Debian GNU/Linux, wit=
h Linux 2.6.32.40<br>Debian GNU/Linux, with Linux 2.6.32-5-686<br><br>I sel=
ect first option and the system returns:<br><br>error: couldn&#39;t open fi=
le<br>
error: you need to load the multiboot kernel first<br><br>The second option=
 is in graphical environment but keyboard and mouse don&#39;t work there. I=
 thought You said to enter within this option (but I think this option is n=
ot important)<br>
<br>And the third option is my environment where I compiled and installed x=
en and Debian GNU/Linux, with Linux 2.6.32.40.<br>Here I do command &quot;#=
 /etc/init.d/xend start&quot; and the system returns &quot;xencommons shoul=
d be started first&quot;, but I had done &quot;/etc/init.d/xencommons start=
&quot; before and no error message returned !!!???<br>
<br>and then... what do you think?<br><br>Eduardo<br><br><br><div class=3D"=
gmail_quote">Em 23 de abril de 2012 13:45, Jos=E9 Eduardo Fran=E7a <span di=
r=3D"ltr">&lt;<a href=3D"mailto:jefranca@gmail.com" target=3D"_blank">jefra=
nca@gmail.com</a>&gt;</span> escreveu:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_extra">Pasi<br><br>I did=
n&#39;t think this. I&#39;ll be in my job tomorrow an I&#39;ll reply there.=
<br>
<br>Thank you<br><br><div class=3D"gmail_quote">Em 23 de abril de 2012 13:2=
3, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi=
" target=3D"_blank">pasik@iki.fi</a>&gt;</span> escreveu:<div><div class=3D=
"h5"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Mon, Apr 23, 2012 at 01:13:49PM -030=
0, Jos=E9 Eduardo Fran=E7a wrote:<br>
&gt; =A0 =A0Hi Pasi,<br>
&gt;<br>
&gt; =A0 =A0thank you for reply.<br>
&gt;<br>
&gt; =A0 =A0I&#39;m using Debian Squeeze, and I&#39;m compiling Xen from so=
urce (.tar.gz). I<br>
&gt; =A0 =A0ran &quot;make install-tools PYTHON_PREFIX_ARG=3D&quot; to inst=
all Xen.<br>
&gt;<br>
&gt; =A0 =A0Notice: I couldn&#39;t run in xen_unstable or dom0 then I retur=
ned to install<br>
&gt; =A0 =A0environment (Debian Squeeze)<br>
&gt;<br>
&gt; =A0 =A0My attempt with modules and now with xenstored command (oxensto=
red command<br>
&gt; =A0 =A0works) was in Debian Squeeze. In this case I think I can&#39;t =
load these<br>
&gt; =A0 =A0modules or run this command, but I&#39;m not sure. Then your qu=
estions can not<br>
&gt; =A0 =A0be in this scope. What do you think?<br>
&gt;<br>
<br>
</div>I was talking about dom0 Linux kernel, not about Xen.<br>
<br>
-- Pasi<br>
<br>
<br>
&gt; =A0 =A0Thanks, Eduardo<br>
&gt;<br>
&gt; =A0 =A0Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen &lt;[1]<a hre=
f=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; escreveu:<=
br>
<div>&gt;<br>
&gt; =A0 =A0 =A0On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fr=
an=E7a wrote:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0hi guys,<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0Hello,<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0It&#39;s my first time here and in a mailing li=
sts, I only participated<br>
&gt; =A0 =A0 =A0in<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0forums before. Please, If I make a mistake you =
should advise me.<br>
&gt; =A0 =A0 =A0Let&#39;s go!<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I was reading &quot;xencommons not start&quot; =
in a Remus Forum in order to<br>
&gt; =A0 =A0 =A0install<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Remus.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Well* I followed the tutorial<br>
&gt; =A0 =A0 =A0&gt;<br>
</div>&gt; =A0 =A0 =A0 &lt;[1][2]<a href=3D"http://remusha.wikidot.com/conf=
iguring-and-installing-remus" target=3D"_blank">http://remusha.wikidot.com/=
configuring-and-installing-remus</a>&gt;, I<br>
<div>&gt; =A0 =A0 =A0reboot<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0in xen_unstable and I had a error message:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: couldn&#39;t open file<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: you need to load the multiboot kernel fi=
rst<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0then I redid tutorial after &quot;Adapt Grub&qu=
ot; and in a moment I do<br>
&gt; =A0 =A0 =A0command:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# /etc/init.d/xend start<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0xencommons should be started first.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0but I had done &quot;/etc/init.d/xencommons sta=
rt&quot; before and no error<br>
&gt; =A0 =A0 =A0message<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0returned !!!???<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I also tried insert modules manually (coz in ot=
her mailing list<br>
&gt; =A0 =A0 =A0said to<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0put some modules - see my setups after this mai=
l) but I had:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# modprobe xen-evtchn<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0FATAL: Module xen_evtchn not found.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0So xen event channel support is not compiled as a module?<b=
r>
&gt; =A0 =A0 =A0is it enabled at all in your dom0 kernel config?<br>
&gt;<br>
</div>&gt; =A0 =A0 =A0[3]<a href=3D"http://wiki.xen.org/wiki/Xen_Common_Pro=
blems#Starting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xe=
n_Common_Problems#Starting_xend_fails.3F</a><br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pas=
ik@iki.fi</a><br>
&gt; =A0 =A02. <a href=3D"http://remusha.wikidot.com/configuring-and-instal=
ling-remus" target=3D"_blank">http://remusha.wikidot.com/configuring-and-in=
stalling-remus</a><br>
&gt; =A0 =A03. <a href=3D"http://wiki.xen.org/wiki/Xen_Common_Problems#Star=
ting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xen_Common_P=
roblems#Starting_xend_fails.3F</a><br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>

--f46d0445178734118504be6c41ee--


--===============3689357105362085809==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3689357105362085809==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 12:54:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfGJ-0005Dr-OS; Tue, 24 Apr 2012 12:54:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jefranca@gmail.com>) id 1SMfGI-0005De-E2
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:54:30 +0000
Received: from [85.158.138.51:57228] by server-12.bemta-3.messagelabs.com id
	12/AC-29760-582A69F4; Tue, 24 Apr 2012 12:54:29 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335272066!14613229!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 795 invoked from network); 24 Apr 2012 12:54:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:54:28 -0000
Received: by obbwd18 with SMTP id wd18so1216246obb.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 05:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=jTngAjK631kbRwQDXMiDkhvqGBgCEPf1amwjfpPDQyE=;
	b=N54yEforUAmeIte+XO1rx174UI6mogqVZNtFvyGcziD9oHcAWxmWYR4tT1lqVQNW0l
	NcC/5X7Nz/NxX2uzo+LMVtkf6xDK2Z4imoux1chMm3YVe58xdPvCv2GBtaNEn0Gc/wPs
	2n/g2ULp+1EJ0JVXqGJtGEtnOdySzpCpKvG3GmOCOFv61yfXbhzwzZNsgt2T0mx5uFOI
	NNkwY3Rrd/KMxZv+FazBAVFvl6ndRlEkKCHt9dLsMdwTpcvaq1CpGiJujEISEE3POQ1k
	NissKGnd/qOQNNsnFQJVGAy3fFdqAcD87mqm6HhOFZwOLBUyyzcqY3vBnfOknFLgDnJ9
	Y5TQ==
MIME-Version: 1.0
Received: by 10.182.36.99 with SMTP id p3mr2733467obj.47.1335272066519; Tue,
	24 Apr 2012 05:54:26 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Tue, 24 Apr 2012 05:54:26 -0700 (PDT)
In-Reply-To: <CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
	<20120423162359.GG2058@reaktio.net>
	<CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
Date: Tue, 24 Apr 2012 09:54:26 -0300
Message-ID: <CAJP76_B35EVJGEoXSP9K7=1y=7yrjNH1ofe5-WqSDggY9ow53Q@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3689357105362085809=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3689357105362085809==
Content-Type: multipart/alternative; boundary=f46d0445178734118504be6c41ee

--f46d0445178734118504be6c41ee
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,

I didn't really understand when You said "I was talking about dom0 Linux
kernel, not about Xen", coz I understand you must be in xen to access dom0.
Look: in my grub2 I have these options in grub2:

Xen Unstable / Debian Squeeze kernel 2.6.32.40
Debian GNU/Linux, with Linux 2.6.32.40
Debian GNU/Linux, with Linux 2.6.32-5-686

I select first option and the system returns:

error: couldn't open file
error: you need to load the multiboot kernel first

The second option is in graphical environment but keyboard and mouse don't
work there. I thought You said to enter within this option (but I think
this option is not important)

And the third option is my environment where I compiled and installed xen
and Debian GNU/Linux, with Linux 2.6.32.40.
Here I do command "# /etc/init.d/xend start" and the system returns
"xencommons should be started first", but I had done
"/etc/init.d/xencommons start" before and no error message returned !!!???

and then... what do you think?

Eduardo


Em 23 de abril de 2012 13:45, Jos=E9 Eduardo Fran=E7a <jefranca@gmail.com>e=
screveu:

> Pasi
>
> I didn't think this. I'll be in my job tomorrow an I'll reply there.
>
> Thank you
>
> Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <pasik@iki.fi> escreveu=
:
>
> On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>> >    Hi Pasi,
>> >
>> >    thank you for reply.
>> >
>> >    I'm using Debian Squeeze, and I'm compiling Xen from source
>> (.tar.gz). I
>> >    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
>> >
>> >    Notice: I couldn't run in xen_unstable or dom0 then I returned to
>> install
>> >    environment (Debian Squeeze)
>> >
>> >    My attempt with modules and now with xenstored command (oxenstored
>> command
>> >    works) was in Debian Squeeze. In this case I think I can't load the=
se
>> >    modules or run this command, but I'm not sure. Then your questions
>> can not
>> >    be in this scope. What do you think?
>> >
>>
>> I was talking about dom0 Linux kernel, not about Xen.
>>
>> -- Pasi
>>
>>
>> >    Thanks, Eduardo
>> >
>> >    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>> escreveu:
>> >
>> >      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fran=E7a
>> wrote:
>> >      >    hi guys,
>> >      >
>> >
>> >      Hello,
>> >      >    It's my first time here and in a mailing lists, I only
>> participated
>> >      in
>> >      >    forums before. Please, If I make a mistake you should advise
>> me.
>> >      Let's go!
>> >      >
>> >      >    I was reading "xencommons not start" in a Remus Forum in
>> order to
>> >      install
>> >      >    Remus.
>> >      >    Well* I followed the tutorial
>> >      >
>> >       <[1][2]
>> http://remusha.wikidot.com/configuring-and-installing-remus>, I
>> >      reboot
>> >      >    in xen_unstable and I had a error message:
>> >      >
>> >      >    error: couldn't open file
>> >      >    error: you need to load the multiboot kernel first
>> >      >
>> >      >    then I redid tutorial after "Adapt Grub" and in a moment I d=
o
>> >      command:
>> >      >
>> >      >    # /etc/init.d/xend start
>> >      >    xencommons should be started first.
>> >      >
>> >      >    but I had done "/etc/init.d/xencommons start" before and no
>> error
>> >      message
>> >      >    returned !!!???
>> >      >
>> >      >    I also tried insert modules manually (coz in other mailing
>> list
>> >      said to
>> >      >    put some modules - see my setups after this mail) but I had:
>> >      >
>> >      >    # modprobe xen-evtchn
>> >      >    FATAL: Module xen_evtchn not found.
>> >      >
>> >
>> >      So xen event channel support is not compiled as a module?
>> >      is it enabled at all in your dom0 kernel config?
>> >
>> >      [3]
>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>> >      -- Pasi
>> >
>> > References
>> >
>> >    Visible links
>> >    1. mailto:pasik@iki.fi
>> >    2. http://remusha.wikidot.com/configuring-and-installing-remus
>> >    3.
>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>>
>
>

--f46d0445178734118504be6c41ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Pasi,<br><br>I didn&#39;t really understand when=
 You said &quot;I was talking about dom0 Linux kernel, not about Xen&quot;,=
 coz I understand you must be in xen to access dom0.<br>Look: in my grub2 I=
 have these options in grub2:<br>
<br>Xen Unstable / Debian Squeeze kernel 2.6.32.40<br>Debian GNU/Linux, wit=
h Linux 2.6.32.40<br>Debian GNU/Linux, with Linux 2.6.32-5-686<br><br>I sel=
ect first option and the system returns:<br><br>error: couldn&#39;t open fi=
le<br>
error: you need to load the multiboot kernel first<br><br>The second option=
 is in graphical environment but keyboard and mouse don&#39;t work there. I=
 thought You said to enter within this option (but I think this option is n=
ot important)<br>
<br>And the third option is my environment where I compiled and installed x=
en and Debian GNU/Linux, with Linux 2.6.32.40.<br>Here I do command &quot;#=
 /etc/init.d/xend start&quot; and the system returns &quot;xencommons shoul=
d be started first&quot;, but I had done &quot;/etc/init.d/xencommons start=
&quot; before and no error message returned !!!???<br>
<br>and then... what do you think?<br><br>Eduardo<br><br><br><div class=3D"=
gmail_quote">Em 23 de abril de 2012 13:45, Jos=E9 Eduardo Fran=E7a <span di=
r=3D"ltr">&lt;<a href=3D"mailto:jefranca@gmail.com" target=3D"_blank">jefra=
nca@gmail.com</a>&gt;</span> escreveu:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_extra">Pasi<br><br>I did=
n&#39;t think this. I&#39;ll be in my job tomorrow an I&#39;ll reply there.=
<br>
<br>Thank you<br><br><div class=3D"gmail_quote">Em 23 de abril de 2012 13:2=
3, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi=
" target=3D"_blank">pasik@iki.fi</a>&gt;</span> escreveu:<div><div class=3D=
"h5"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Mon, Apr 23, 2012 at 01:13:49PM -030=
0, Jos=E9 Eduardo Fran=E7a wrote:<br>
&gt; =A0 =A0Hi Pasi,<br>
&gt;<br>
&gt; =A0 =A0thank you for reply.<br>
&gt;<br>
&gt; =A0 =A0I&#39;m using Debian Squeeze, and I&#39;m compiling Xen from so=
urce (.tar.gz). I<br>
&gt; =A0 =A0ran &quot;make install-tools PYTHON_PREFIX_ARG=3D&quot; to inst=
all Xen.<br>
&gt;<br>
&gt; =A0 =A0Notice: I couldn&#39;t run in xen_unstable or dom0 then I retur=
ned to install<br>
&gt; =A0 =A0environment (Debian Squeeze)<br>
&gt;<br>
&gt; =A0 =A0My attempt with modules and now with xenstored command (oxensto=
red command<br>
&gt; =A0 =A0works) was in Debian Squeeze. In this case I think I can&#39;t =
load these<br>
&gt; =A0 =A0modules or run this command, but I&#39;m not sure. Then your qu=
estions can not<br>
&gt; =A0 =A0be in this scope. What do you think?<br>
&gt;<br>
<br>
</div>I was talking about dom0 Linux kernel, not about Xen.<br>
<br>
-- Pasi<br>
<br>
<br>
&gt; =A0 =A0Thanks, Eduardo<br>
&gt;<br>
&gt; =A0 =A0Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen &lt;[1]<a hre=
f=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; escreveu:<=
br>
<div>&gt;<br>
&gt; =A0 =A0 =A0On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fr=
an=E7a wrote:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0hi guys,<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0Hello,<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0It&#39;s my first time here and in a mailing li=
sts, I only participated<br>
&gt; =A0 =A0 =A0in<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0forums before. Please, If I make a mistake you =
should advise me.<br>
&gt; =A0 =A0 =A0Let&#39;s go!<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I was reading &quot;xencommons not start&quot; =
in a Remus Forum in order to<br>
&gt; =A0 =A0 =A0install<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Remus.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Well* I followed the tutorial<br>
&gt; =A0 =A0 =A0&gt;<br>
</div>&gt; =A0 =A0 =A0 &lt;[1][2]<a href=3D"http://remusha.wikidot.com/conf=
iguring-and-installing-remus" target=3D"_blank">http://remusha.wikidot.com/=
configuring-and-installing-remus</a>&gt;, I<br>
<div>&gt; =A0 =A0 =A0reboot<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0in xen_unstable and I had a error message:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: couldn&#39;t open file<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0error: you need to load the multiboot kernel fi=
rst<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0then I redid tutorial after &quot;Adapt Grub&qu=
ot; and in a moment I do<br>
&gt; =A0 =A0 =A0command:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# /etc/init.d/xend start<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0xencommons should be started first.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0but I had done &quot;/etc/init.d/xencommons sta=
rt&quot; before and no error<br>
&gt; =A0 =A0 =A0message<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0returned !!!???<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I also tried insert modules manually (coz in ot=
her mailing list<br>
&gt; =A0 =A0 =A0said to<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0put some modules - see my setups after this mai=
l) but I had:<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0# modprobe xen-evtchn<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0FATAL: Module xen_evtchn not found.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0So xen event channel support is not compiled as a module?<b=
r>
&gt; =A0 =A0 =A0is it enabled at all in your dom0 kernel config?<br>
&gt;<br>
</div>&gt; =A0 =A0 =A0[3]<a href=3D"http://wiki.xen.org/wiki/Xen_Common_Pro=
blems#Starting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xe=
n_Common_Problems#Starting_xend_fails.3F</a><br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pas=
ik@iki.fi</a><br>
&gt; =A0 =A02. <a href=3D"http://remusha.wikidot.com/configuring-and-instal=
ling-remus" target=3D"_blank">http://remusha.wikidot.com/configuring-and-in=
stalling-remus</a><br>
&gt; =A0 =A03. <a href=3D"http://wiki.xen.org/wiki/Xen_Common_Problems#Star=
ting_xend_fails.3F" target=3D"_blank">http://wiki.xen.org/wiki/Xen_Common_P=
roblems#Starting_xend_fails.3F</a><br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>

--f46d0445178734118504be6c41ee--


--===============3689357105362085809==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3689357105362085809==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 12:57:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfIV-0005N7-Ap; Tue, 24 Apr 2012 12:56:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfIT-0005Ms-2p
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:56:45 +0000
Received: from [193.109.254.147:6131] by server-9.bemta-14.messagelabs.com id
	05/63-05787-C03A69F4; Tue, 24 Apr 2012 12:56:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335272203!6064307!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1944 invoked from network); 24 Apr 2012 12:56:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:56:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:56:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 13:56:43 +0100
Date: Tue, 24 Apr 2012 14:02:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1406459635-1335272495=:26786"
Content-ID: <alpine.DEB.2.00.1204241401370.26786@kaball-desktop>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-1406459635-1335272495=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1204241401371.26786@kaball-desktop>

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> tool = ""
>  xenstored = ""
> local = ""
>  domain = ""
>   0 = ""
>    name = "Domain-0"
>    memory = ""
>     target = "523904"
>     static-max = "4294967292"
>     freemem-slack = "314505"
>    backend = ""
>     console = ""
>      1 = ""
>       0 = ""
>        frontend = "/local/domain/1/console"
>        frontend-id = "1"
>        online = "0"
>        state = "5"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      2 = ""
>       0 = ""
>        frontend = "/local/domain/2/console"
>        frontend-id = "2"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      3 = ""
>       0 = ""
>        frontend = "/local/domain/3/console"
>        frontend-id = "3"
>        online = "0"
>        state = "5"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      4 = ""
>       0 = ""
>        frontend = "/local/domain/4/console"
>        frontend-id = "4"
>        online = "0"
>        state = "5"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      5 = ""
>       0 = ""
>        frontend = "/local/domain/5/console"
>        frontend-id = "5"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/console"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        domain = "domutest"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      7 = ""
>       0 = ""
>        frontend = "/local/domain/7/console"
>        frontend-id = "7"
>        online = "1"
>        state = "4"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>     vfb = ""
>      5 = ""
>       0 = ""
>        frontend = "/local/domain/5/device/vfb/0"
>        frontend-id = "5"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        vnc = "1"
>        vnclisten = "0.0.0.0"
>        vncpasswd = ""
>        vncdisplay = "5"
>        vncunused = "1"
>        sdl = "0"
>        opengl = "0"
>        feature-resize = "1"
>        hotplug-status = "connected"
>        request-update = "1"
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/device/vfb/0"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        domain = "domutest"
>        vnc = "1"
>        vnclisten = "0.0.0.0"
>        vncpasswd = ""
>        vncdisplay = "5"
>        vncunused = "1"
>        sdl = "0"
>        opengl = "0"
>        feature-resize = "1"
>        hotplug-status = "connected"
>        request-update = "1"
>     vkbd = ""
>      5 = ""
>       0 = ""
>        frontend = "/local/domain/5/device/vkbd/0"
>        frontend-id = "5"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        feature-abs-pointer = "1"
>        hotplug-status = "connected"
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/device/vkbd/0"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        domain = "domutest"
>        feature-abs-pointer = "1"
>        hotplug-status = "connected"
>     vbd = ""
>      6 = ""
>       51713 = ""
>        frontend = "/local/domain/6/device/vbd/51713"
>        physical-device = "fe:2"
>        params = "/dev/xtG0/domutest-root"
>        frontend-id = "6"
>        online = "1"
>        removable = "0"
>        bootable = "1"
>        state = "4"
>        dev = "xvda1"
>        type = "phy"
>        mode = "w"
>        feature-flush-cache = "0"
>        discard-secure = "0"
>        feature-discard = "0"
>        feature-barrier = "0"
>        sectors = "6291456"
>        info = "0"
>        sector-size = "512"
>       51714 = ""
>        frontend = "/local/domain/6/device/vbd/51714"
>        physical-device = "fe:3"
>        params = "/dev/xtG0/domutest-swap"
>        frontend-id = "6"
>        online = "1"
>        removable = "0"
>        bootable = "1"
>        state = "4"
>        dev = "xvda2"
>        type = "phy"
>        mode = "w"
>        feature-flush-cache = "0"
>        discard-secure = "0"
>        feature-discard = "0"
>        feature-barrier = "0"
>        sectors = "1048576"
>        info = "0"
>        sector-size = "512"
>     vif = ""
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/device/vif/0"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        script = "/etc/xen/scripts/vif-bridge"
>        mac = "00:16:3e:0c:49:8e"
>        bridge = "outer0"
>        handle = "0"
>        feature-sg = "1"
>        feature-gso-tcpv4 = "1"
>        feature-rx-copy = "1"
>        feature-rx-flip = "0"
>        hotplug-status = "connected"
>      7 = ""
>       0 = ""
>        frontend = "/local/domain/7/device/vif/0"
>        frontend-id = "7"
>        online = "1"
>        state = "2"
>        script = "/etc/xen/scripts/vif-bridge"
>        mac = "00:16:3e:10:6a:f4"
>        bridge = "outer0"
>        handle = "0"
>        feature-sg = "1"
>        feature-gso-tcpv4 = "1"
>        feature-rx-copy = "1"
>        feature-rx-flip = "0"
>        hotplug-status = "connected"
>     qdisk = ""
>      7 = ""
>       51712 = ""
>        frontend = "/local/domain/7/device/vbd/51712"
>        params = "aio:/var/finnix/finnix-104.iso"
>        frontend-id = "7"
>        online = "1"
>        removable = "0"
>        bootable = "1"
>        state = "2"
>        dev = "xvda"
>        type = "tap"
>        mode = "r"
>        feature-barrier = "1"
>        info = "4"
>        sector-size = "512"
>        sectors = "237712"
>        hotplug-status = "connected"
>    device-model = ""
>     6 = ""
>      disable_pf = "1"
>      state = "running"
>     7 = ""
>      disable_pf = "1"
>      state = "running"
>   6 = ""
>    vm = "/vm/d7ea3f07-f491-493f-8989-749d7a76a4f4"
>    name = "domutest"
>    control = ""
>     shutdown = ""
>     platform-feature-multiprocessor-suspend = "1"
>    device = ""
>     suspend = ""
>      event-channel = ""
>     vbd = ""
>      51713 = ""
>       backend = "/local/domain/0/backend/vbd/6/51713"
>       backend-id = "0"
>       state = "4"
>       virtual-device = "51713"
>       device-type = "disk"
>       ring-ref = "8"
>       event-channel = "23"
>       protocol = "x86_64-abi"
>      51714 = ""
>       backend = "/local/domain/0/backend/vbd/6/51714"
>       backend-id = "0"
>       state = "4"
>       virtual-device = "51714"
>       device-type = "disk"
>       ring-ref = "9"
>       event-channel = "24"
>       protocol = "x86_64-abi"
>     vif = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vif/6/0"
>       backend-id = "0"
>       state = "4"
>       handle = "0"
>       mac = "00:16:3e:0c:49:8e"
>       tx-ring-ref = "10"
>       rx-ring-ref = "11"
>       event-channel = "25"
>       request-rx-copy = "1"
>       feature-rx-notify = "1"
>       feature-sg = "1"
>       feature-gso-tcpv4 = "1"
>     vfb = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vfb/6/0"
>       backend-id = "0"
>       state = "4"
>       page-ref = "367826"
>       event-channel = "27"
>       protocol = "x86_64-abi"
>       feature-update = "1"
>     vkbd = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vkbd/6/0"
>       backend-id = "0"
>       state = "4"
>       request-abs-pointer = "1"
>       page-ref = "284662"
>       page-gref = "14"
>       event-channel = "26"
>    data = ""
>    cpu = ""
>     0 = ""
>      availability = "online"
>     1 = ""
>      availability = "online"
>     2 = ""
>      availability = "online"
>     3 = ""
>      availability = "online"
>    memory = ""
>     static-max = "524288"
>     target = "524288"
>     videoram = "0"
>    error = ""
>    drivers = ""
>    attr = ""
>    messages = ""
>    domid = "6"
>    store = ""
>     port = "1"
>     ring-ref = "369971"
>    console = ""
>     backend = "/local/domain/0/backend/console/6/0"
>     backend-id = "0"
>     limit = "1048576"
>     type = "ioemu"
>     output = "pty"
>     port = "2"
>     ring-ref = "369970"
>     tty = "/dev/pts/2"
>     vnc-port = "5905"
>     vnc-listen = "0.0.0.0"
>     vnc-pass = ""
>    image = ""
>     device-model-pid = "1684"
>   7 = ""
>    vm = "/vm/bf8f3948-e089-44fd-88be-140479840e93"
>    name = "finnix"
>    control = ""
>     shutdown = ""
>     platform-feature-multiprocessor-suspend = "1"
>    device = ""
>     suspend = ""
>      event-channel = ""
>     vbd = ""
>      51712 = ""
>       backend = "/local/domain/0/backend/qdisk/7/51712"
>       backend-id = "0"
>       state = "1"
>       virtual-device = "51712"
>       device-type = "disk"
>     vif = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vif/7/0"
>       backend-id = "0"
>       state = "1"
>       handle = "0"
>       mac = "00:16:3e:10:6a:f4"
>    data = ""
>    cpu = ""
>     0 = ""
>      availability = "online"
>    memory = ""
>     static-max = "131072"
>     target = "131072"
>     videoram = "0"
>    error = ""
>    drivers = ""
>    attr = ""
>    messages = ""
>    domid = "7"
>    store = ""
>     port = "1"
>     ring-ref = "265286"
>    console = ""
>     backend = "/local/domain/0/backend/console/7/0"
>     backend-id = "0"
>     limit = "1048576"
>     type = "ioemu"
>     output = "pty"
>     port = "2"
>     ring-ref = "265285"
>     tty = "/dev/pts/3"
>    image = ""
>     device-model-pid = "1725"
> vm = ""
>  d7ea3f07-f491-493f-8989-749d7a76a4f4 = ""
>   uuid = "d7ea3f07-f491-493f-8989-749d7a76a4f4"
>   name = "domutest"
>   pool_name = "Pool-0"
>   image = ""
>    ostype = "linux"
>    kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
>    cmdline = "(hd0)/boot/grub/menu.lst"
>   start_time = "1335231372.76"
>   vncpasswd = "\000"
>  bf8f3948-e089-44fd-88be-140479840e93 = ""
>   uuid = "bf8f3948-e089-44fd-88be-140479840e93"
>   name = "finnix"
>   pool_name = "Pool-0"
>   image = ""
>    ostype = "linux"
>    kernel = "/var/finnix/linux64"
>    ramdisk = "/var/finnix/initrd.xz"
>    cmdline = ""
>   start_time = "1335231379.11"

According to xenstore the console is connected for both domains and you
should be able to access them using /dev/pts/2 and /dev/pts/3.
The only issue I can see is that the disk for "finnix" is not
connected. Maybe an disk open error?
--8323329-1406459635-1335272495=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-1406459635-1335272495=:26786--


From xen-devel-bounces@lists.xen.org Tue Apr 24 12:57:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfIV-0005N7-Ap; Tue, 24 Apr 2012 12:56:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfIT-0005Ms-2p
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:56:45 +0000
Received: from [193.109.254.147:6131] by server-9.bemta-14.messagelabs.com id
	05/63-05787-C03A69F4; Tue, 24 Apr 2012 12:56:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335272203!6064307!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1944 invoked from network); 24 Apr 2012 12:56:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:56:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:56:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 13:56:43 +0100
Date: Tue, 24 Apr 2012 14:02:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1406459635-1335272495=:26786"
Content-ID: <alpine.DEB.2.00.1204241401370.26786@kaball-desktop>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-1406459635-1335272495=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1204241401371.26786@kaball-desktop>

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> tool = ""
>  xenstored = ""
> local = ""
>  domain = ""
>   0 = ""
>    name = "Domain-0"
>    memory = ""
>     target = "523904"
>     static-max = "4294967292"
>     freemem-slack = "314505"
>    backend = ""
>     console = ""
>      1 = ""
>       0 = ""
>        frontend = "/local/domain/1/console"
>        frontend-id = "1"
>        online = "0"
>        state = "5"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      2 = ""
>       0 = ""
>        frontend = "/local/domain/2/console"
>        frontend-id = "2"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      3 = ""
>       0 = ""
>        frontend = "/local/domain/3/console"
>        frontend-id = "3"
>        online = "0"
>        state = "5"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      4 = ""
>       0 = ""
>        frontend = "/local/domain/4/console"
>        frontend-id = "4"
>        online = "0"
>        state = "5"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      5 = ""
>       0 = ""
>        frontend = "/local/domain/5/console"
>        frontend-id = "5"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/console"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        domain = "domutest"
>        protocol = "vt100"
>        hotplug-status = "connected"
>      7 = ""
>       0 = ""
>        frontend = "/local/domain/7/console"
>        frontend-id = "7"
>        online = "1"
>        state = "4"
>        domain = "finnix"
>        protocol = "vt100"
>        hotplug-status = "connected"
>     vfb = ""
>      5 = ""
>       0 = ""
>        frontend = "/local/domain/5/device/vfb/0"
>        frontend-id = "5"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        vnc = "1"
>        vnclisten = "0.0.0.0"
>        vncpasswd = ""
>        vncdisplay = "5"
>        vncunused = "1"
>        sdl = "0"
>        opengl = "0"
>        feature-resize = "1"
>        hotplug-status = "connected"
>        request-update = "1"
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/device/vfb/0"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        domain = "domutest"
>        vnc = "1"
>        vnclisten = "0.0.0.0"
>        vncpasswd = ""
>        vncdisplay = "5"
>        vncunused = "1"
>        sdl = "0"
>        opengl = "0"
>        feature-resize = "1"
>        hotplug-status = "connected"
>        request-update = "1"
>     vkbd = ""
>      5 = ""
>       0 = ""
>        frontend = "/local/domain/5/device/vkbd/0"
>        frontend-id = "5"
>        online = "0"
>        state = "5"
>        domain = "domutest"
>        feature-abs-pointer = "1"
>        hotplug-status = "connected"
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/device/vkbd/0"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        domain = "domutest"
>        feature-abs-pointer = "1"
>        hotplug-status = "connected"
>     vbd = ""
>      6 = ""
>       51713 = ""
>        frontend = "/local/domain/6/device/vbd/51713"
>        physical-device = "fe:2"
>        params = "/dev/xtG0/domutest-root"
>        frontend-id = "6"
>        online = "1"
>        removable = "0"
>        bootable = "1"
>        state = "4"
>        dev = "xvda1"
>        type = "phy"
>        mode = "w"
>        feature-flush-cache = "0"
>        discard-secure = "0"
>        feature-discard = "0"
>        feature-barrier = "0"
>        sectors = "6291456"
>        info = "0"
>        sector-size = "512"
>       51714 = ""
>        frontend = "/local/domain/6/device/vbd/51714"
>        physical-device = "fe:3"
>        params = "/dev/xtG0/domutest-swap"
>        frontend-id = "6"
>        online = "1"
>        removable = "0"
>        bootable = "1"
>        state = "4"
>        dev = "xvda2"
>        type = "phy"
>        mode = "w"
>        feature-flush-cache = "0"
>        discard-secure = "0"
>        feature-discard = "0"
>        feature-barrier = "0"
>        sectors = "1048576"
>        info = "0"
>        sector-size = "512"
>     vif = ""
>      6 = ""
>       0 = ""
>        frontend = "/local/domain/6/device/vif/0"
>        frontend-id = "6"
>        online = "1"
>        state = "4"
>        script = "/etc/xen/scripts/vif-bridge"
>        mac = "00:16:3e:0c:49:8e"
>        bridge = "outer0"
>        handle = "0"
>        feature-sg = "1"
>        feature-gso-tcpv4 = "1"
>        feature-rx-copy = "1"
>        feature-rx-flip = "0"
>        hotplug-status = "connected"
>      7 = ""
>       0 = ""
>        frontend = "/local/domain/7/device/vif/0"
>        frontend-id = "7"
>        online = "1"
>        state = "2"
>        script = "/etc/xen/scripts/vif-bridge"
>        mac = "00:16:3e:10:6a:f4"
>        bridge = "outer0"
>        handle = "0"
>        feature-sg = "1"
>        feature-gso-tcpv4 = "1"
>        feature-rx-copy = "1"
>        feature-rx-flip = "0"
>        hotplug-status = "connected"
>     qdisk = ""
>      7 = ""
>       51712 = ""
>        frontend = "/local/domain/7/device/vbd/51712"
>        params = "aio:/var/finnix/finnix-104.iso"
>        frontend-id = "7"
>        online = "1"
>        removable = "0"
>        bootable = "1"
>        state = "2"
>        dev = "xvda"
>        type = "tap"
>        mode = "r"
>        feature-barrier = "1"
>        info = "4"
>        sector-size = "512"
>        sectors = "237712"
>        hotplug-status = "connected"
>    device-model = ""
>     6 = ""
>      disable_pf = "1"
>      state = "running"
>     7 = ""
>      disable_pf = "1"
>      state = "running"
>   6 = ""
>    vm = "/vm/d7ea3f07-f491-493f-8989-749d7a76a4f4"
>    name = "domutest"
>    control = ""
>     shutdown = ""
>     platform-feature-multiprocessor-suspend = "1"
>    device = ""
>     suspend = ""
>      event-channel = ""
>     vbd = ""
>      51713 = ""
>       backend = "/local/domain/0/backend/vbd/6/51713"
>       backend-id = "0"
>       state = "4"
>       virtual-device = "51713"
>       device-type = "disk"
>       ring-ref = "8"
>       event-channel = "23"
>       protocol = "x86_64-abi"
>      51714 = ""
>       backend = "/local/domain/0/backend/vbd/6/51714"
>       backend-id = "0"
>       state = "4"
>       virtual-device = "51714"
>       device-type = "disk"
>       ring-ref = "9"
>       event-channel = "24"
>       protocol = "x86_64-abi"
>     vif = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vif/6/0"
>       backend-id = "0"
>       state = "4"
>       handle = "0"
>       mac = "00:16:3e:0c:49:8e"
>       tx-ring-ref = "10"
>       rx-ring-ref = "11"
>       event-channel = "25"
>       request-rx-copy = "1"
>       feature-rx-notify = "1"
>       feature-sg = "1"
>       feature-gso-tcpv4 = "1"
>     vfb = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vfb/6/0"
>       backend-id = "0"
>       state = "4"
>       page-ref = "367826"
>       event-channel = "27"
>       protocol = "x86_64-abi"
>       feature-update = "1"
>     vkbd = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vkbd/6/0"
>       backend-id = "0"
>       state = "4"
>       request-abs-pointer = "1"
>       page-ref = "284662"
>       page-gref = "14"
>       event-channel = "26"
>    data = ""
>    cpu = ""
>     0 = ""
>      availability = "online"
>     1 = ""
>      availability = "online"
>     2 = ""
>      availability = "online"
>     3 = ""
>      availability = "online"
>    memory = ""
>     static-max = "524288"
>     target = "524288"
>     videoram = "0"
>    error = ""
>    drivers = ""
>    attr = ""
>    messages = ""
>    domid = "6"
>    store = ""
>     port = "1"
>     ring-ref = "369971"
>    console = ""
>     backend = "/local/domain/0/backend/console/6/0"
>     backend-id = "0"
>     limit = "1048576"
>     type = "ioemu"
>     output = "pty"
>     port = "2"
>     ring-ref = "369970"
>     tty = "/dev/pts/2"
>     vnc-port = "5905"
>     vnc-listen = "0.0.0.0"
>     vnc-pass = ""
>    image = ""
>     device-model-pid = "1684"
>   7 = ""
>    vm = "/vm/bf8f3948-e089-44fd-88be-140479840e93"
>    name = "finnix"
>    control = ""
>     shutdown = ""
>     platform-feature-multiprocessor-suspend = "1"
>    device = ""
>     suspend = ""
>      event-channel = ""
>     vbd = ""
>      51712 = ""
>       backend = "/local/domain/0/backend/qdisk/7/51712"
>       backend-id = "0"
>       state = "1"
>       virtual-device = "51712"
>       device-type = "disk"
>     vif = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vif/7/0"
>       backend-id = "0"
>       state = "1"
>       handle = "0"
>       mac = "00:16:3e:10:6a:f4"
>    data = ""
>    cpu = ""
>     0 = ""
>      availability = "online"
>    memory = ""
>     static-max = "131072"
>     target = "131072"
>     videoram = "0"
>    error = ""
>    drivers = ""
>    attr = ""
>    messages = ""
>    domid = "7"
>    store = ""
>     port = "1"
>     ring-ref = "265286"
>    console = ""
>     backend = "/local/domain/0/backend/console/7/0"
>     backend-id = "0"
>     limit = "1048576"
>     type = "ioemu"
>     output = "pty"
>     port = "2"
>     ring-ref = "265285"
>     tty = "/dev/pts/3"
>    image = ""
>     device-model-pid = "1725"
> vm = ""
>  d7ea3f07-f491-493f-8989-749d7a76a4f4 = ""
>   uuid = "d7ea3f07-f491-493f-8989-749d7a76a4f4"
>   name = "domutest"
>   pool_name = "Pool-0"
>   image = ""
>    ostype = "linux"
>    kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
>    cmdline = "(hd0)/boot/grub/menu.lst"
>   start_time = "1335231372.76"
>   vncpasswd = "\000"
>  bf8f3948-e089-44fd-88be-140479840e93 = ""
>   uuid = "bf8f3948-e089-44fd-88be-140479840e93"
>   name = "finnix"
>   pool_name = "Pool-0"
>   image = ""
>    ostype = "linux"
>    kernel = "/var/finnix/linux64"
>    ramdisk = "/var/finnix/initrd.xz"
>    cmdline = ""
>   start_time = "1335231379.11"

According to xenstore the console is connected for both domains and you
should be able to access them using /dev/pts/2 and /dev/pts/3.
The only issue I can see is that the disk for "finnix" is not
connected. Maybe an disk open error?
--8323329-1406459635-1335272495=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-1406459635-1335272495=:26786--


From xen-devel-bounces@lists.xen.org Tue Apr 24 12:57:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfJ0-0005QZ-OX; Tue, 24 Apr 2012 12:57:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfIz-0005QL-7U
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:57:17 +0000
Received: from [85.158.143.35:34314] by server-1.bemta-4.messagelabs.com id
	EE/D1-20925-C23A69F4; Tue, 24 Apr 2012 12:57:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335272235!11408568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28255 invoked from network); 24 Apr 2012 12:57:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:57:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:57:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:57:15 +0100
Message-ID: <1335272234.4347.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 13:57:14 +0100
In-Reply-To: <D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
	<D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 12:55 +0100, Sam Mulvey wrote:
> 
> On Apr 24, 2012, at 3:31 AM, Ian Campbell wrote:
> 
> > Thanks, it's good to see people trying the transition.
> > 
> > Are you able to try xen-unstable? A lot of this stuff (particularly
> > relating to pv consoles and pygrub etc) is much improved in the 4.2
> > version of xl and if not then we should be much more able to fix
> > things
> > there than in 4.1 (where I suspect any fix would be far too invasive
> > for
> > a stable backport).
> > 
> > Thanks,
> > Ian.
> 
> I can.   There's a couple things that have occurred to me that I'd
> like to try out, but I can certainly give it a try.

Thanks.

> The packages I'm working on are eventually destined for a production
> server.    I started out on this process when my production machine
> started crashing when I'd load up on domUs.  You can see
> <http://www.gossamer-threads.com/lists/xen/users/241986> for more info
> on that one.   That's running a pull from mercurial from some months
> ago before 4.1.2 was released,

Are you sure? The stack trace indicates that this is "Xen-4.2-unstable"
not 4.1.x. (note to self, we really ought to print the hg cset in the
panic log if it is available...)

>  so I thought I would make fresh go of Xen, and if I still had the
> problem I'd feel better about filing bug reports.
> 
> 
> So for the purposes of production blah, I thought I'd use the stable
> releases, but if tracking unstable is preferable, I can do that.

For your production uses I think the best advice right now would be to
use 4.1 with xend (unless Stefano can diagnose your xl console issue in
the other subthread). However it would also be useful to evaluate your
use case using xen-unstable and xl so that we can be reasonably sure
that when 4.2 is released you will be able to deploy that without issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 12:57:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 12:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfJ0-0005QZ-OX; Tue, 24 Apr 2012 12:57:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfIz-0005QL-7U
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:57:17 +0000
Received: from [85.158.143.35:34314] by server-1.bemta-4.messagelabs.com id
	EE/D1-20925-C23A69F4; Tue, 24 Apr 2012 12:57:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335272235!11408568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28255 invoked from network); 24 Apr 2012 12:57:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 12:57:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:57:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:57:15 +0100
Message-ID: <1335272234.4347.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 13:57:14 +0100
In-Reply-To: <D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
	<D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 12:55 +0100, Sam Mulvey wrote:
> 
> On Apr 24, 2012, at 3:31 AM, Ian Campbell wrote:
> 
> > Thanks, it's good to see people trying the transition.
> > 
> > Are you able to try xen-unstable? A lot of this stuff (particularly
> > relating to pv consoles and pygrub etc) is much improved in the 4.2
> > version of xl and if not then we should be much more able to fix
> > things
> > there than in 4.1 (where I suspect any fix would be far too invasive
> > for
> > a stable backport).
> > 
> > Thanks,
> > Ian.
> 
> I can.   There's a couple things that have occurred to me that I'd
> like to try out, but I can certainly give it a try.

Thanks.

> The packages I'm working on are eventually destined for a production
> server.    I started out on this process when my production machine
> started crashing when I'd load up on domUs.  You can see
> <http://www.gossamer-threads.com/lists/xen/users/241986> for more info
> on that one.   That's running a pull from mercurial from some months
> ago before 4.1.2 was released,

Are you sure? The stack trace indicates that this is "Xen-4.2-unstable"
not 4.1.x. (note to self, we really ought to print the hg cset in the
panic log if it is available...)

>  so I thought I would make fresh go of Xen, and if I still had the
> problem I'd feel better about filing bug reports.
> 
> 
> So for the purposes of production blah, I thought I'd use the stable
> releases, but if tracking unstable is preferable, I can do that.

For your production uses I think the best advice right now would be to
use 4.1 with xend (unless Stefano can diagnose your xl console issue in
the other subthread). However it would also be useful to evaluate your
use case using xen-unstable and xl so that we can be reasonably sure
that when 4.2 is released you will be able to deploy that without issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:00:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfLU-0005gS-HH; Tue, 24 Apr 2012 12:59:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SMfLS-0005gE-Uf
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:59:51 +0000
Received: from [85.158.138.51:63840] by server-4.bemta-3.messagelabs.com id
	D5/4D-15341-6C3A69F4; Tue, 24 Apr 2012 12:59:50 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335272388!19479091!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjI4MTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13375 invoked from network); 24 Apr 2012 12:59:49 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 12:59:49 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 5609027DC;
	Tue, 24 Apr 2012 15:59:48 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E216220059; Tue, 24 Apr 2012 15:59:47 +0300 (EEST)
Date: Tue, 24 Apr 2012 15:59:47 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
Message-ID: <20120424125947.GH2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
	<20120423162359.GG2058@reaktio.net>
	<CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
	<CAJP76_B35EVJGEoXSP9K7=1y=7yrjNH1ofe5-WqSDggY9ow53Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJP76_B35EVJGEoXSP9K7=1y=7yrjNH1ofe5-WqSDggY9ow53Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 09:54:26AM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>    Pasi,
> =


This thread really belongs to xen-users mailinglist (added to CC).
So let's drop xen-devel from the CC list in the replies..


>    I didn't really understand when You said "I was talking about dom0 Lin=
ux
>    kernel, not about Xen", coz I understand you must be in xen to access
>    dom0.
>    Look: in my grub2 I have these options in grub2:
> =

>    Xen Unstable / Debian Squeeze kernel 2.6.32.40
>    Debian GNU/Linux, with Linux 2.6.32.40
>    Debian GNU/Linux, with Linux 2.6.32-5-686
> =


Please paste the entries from your grub.cfg

>    I select first option and the system returns:
> =

>    error: couldn't open file
>    error: you need to load the multiboot kernel first
> =


So the grub entry is broken. Please fix it.

>    The second option is in graphical environment but keyboard and mouse d=
on't
>    work there. I thought You said to enter within this option (but I think
>    this option is not important)
> =


Of course you need to boot to Xen to be able to use Xen.
I recommend using just the text-only modes.

>    And the third option is my environment where I compiled and installed =
xen
>    and Debian GNU/Linux, with Linux 2.6.32.40.
>    Here I do command "# /etc/init.d/xend start" and the system returns
>    "xencommons should be started first", but I had done
>    "/etc/init.d/xencommons start" before and no error message returned !!=
!???
> =


Did you realize Xen is the hypervisor (xen.gz), and in addition to Xen
you also need Xen-enabled Linux dom0 kernel ? =


http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F


>    and then... what do you think?
> =



-- Pasi


>    Eduardo
> =

>    Em 23 de abril de 2012 13:45, Jos=E9 Eduardo Fran=E7a <[1]jefranca@gma=
il.com>
>    escreveu:
> =

>      Pasi
> =

>      I didn't think this. I'll be in my job tomorrow an I'll reply there.
> =

>      Thank you
> =

>      Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <[2]pasik@iki.fi>
>      escreveu:
> =

>        On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a =
wrote:
>        >    Hi Pasi,
>        >
>        >    thank you for reply.
>        >
>        >    I'm using Debian Squeeze, and I'm compiling Xen from source
>        (.tar.gz). I
>        >    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
>        >
>        >    Notice: I couldn't run in xen_unstable or dom0 then I returne=
d to
>        install
>        >    environment (Debian Squeeze)
>        >
>        >    My attempt with modules and now with xenstored command
>        (oxenstored command
>        >    works) was in Debian Squeeze. In this case I think I can't lo=
ad
>        these
>        >    modules or run this command, but I'm not sure. Then your
>        questions can not
>        >    be in this scope. What do you think?
>        >
> =

>        I was talking about dom0 Linux kernel, not about Xen.
> =

>        -- Pasi
> =

>        >    Thanks, Eduardo
>        >
>        >    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen
>        <[1][3]pasik@iki.fi> escreveu:
>        >
>        >      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fr=
an=E7a
>        wrote:
>        >      >    hi guys,
>        >      >
>        >
>        >      Hello,
>        >      >    It's my first time here and in a mailing lists, I only
>        participated
>        >      in
>        >      >    forums before. Please, If I make a mistake you should
>        advise me.
>        >      Let's go!
>        >      >
>        >      >    I was reading "xencommons not start" in a Remus Forum =
in
>        order to
>        >      install
>        >      >    Remus.
>        >      >    Well* I followed the tutorial
>        >      >
>        >
>        <[1][2][4]http://remusha.wikidot.com/configuring-and-installing-re=
mus>,
>        I
>        >      reboot
>        >      >    in xen_unstable and I had a error message:
>        >      >
>        >      >    error: couldn't open file
>        >      >    error: you need to load the multiboot kernel first
>        >      >
>        >      >    then I redid tutorial after "Adapt Grub" and in a mome=
nt I
>        do
>        >      command:
>        >      >
>        >      >    # /etc/init.d/xend start
>        >      >    xencommons should be started first.
>        >      >
>        >      >    but I had done "/etc/init.d/xencommons start" before a=
nd
>        no error
>        >      message
>        >      >    returned !!!???
>        >      >
>        >      >    I also tried insert modules manually (coz in other mai=
ling
>        list
>        >      said to
>        >      >    put some modules - see my setups after this mail) but I
>        had:
>        >      >
>        >      >    # modprobe xen-evtchn
>        >      >    FATAL: Module xen_evtchn not found.
>        >      >
>        >
>        >      So xen event channel support is not compiled as a module?
>        >      is it enabled at all in your dom0 kernel config?
>        >
>        >
>         [3][5]http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_=
fails.3F
>        >      -- Pasi
>        >
>        > References
>        >
>        >    Visible links
>        >    1. mailto:[6]pasik@iki.fi
>        >    2. [7]http://remusha.wikidot.com/configuring-and-installing-r=
emus
>        >    3.
>        [8]http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fail=
s.3F
> =

> References
> =

>    Visible links
>    1. mailto:jefranca@gmail.com
>    2. mailto:pasik@iki.fi
>    3. mailto:pasik@iki.fi
>    4. http://remusha.wikidot.com/configuring-and-installing-remus
>    5. http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>    6. mailto:pasik@iki.fi
>    7. http://remusha.wikidot.com/configuring-and-installing-remus
>    8. http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:00:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfLU-0005gS-HH; Tue, 24 Apr 2012 12:59:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SMfLS-0005gE-Uf
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 12:59:51 +0000
Received: from [85.158.138.51:63840] by server-4.bemta-3.messagelabs.com id
	D5/4D-15341-6C3A69F4; Tue, 24 Apr 2012 12:59:50 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335272388!19479091!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjI4MTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13375 invoked from network); 24 Apr 2012 12:59:49 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 12:59:49 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 5609027DC;
	Tue, 24 Apr 2012 15:59:48 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E216220059; Tue, 24 Apr 2012 15:59:47 +0300 (EEST)
Date: Tue, 24 Apr 2012 15:59:47 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= <jefranca@gmail.com>
Message-ID: <20120424125947.GH2058@reaktio.net>
References: <CAJP76_Ck25E22z342s9RskhbAVDSKdRZdK=HV+6vb2K_E4yjOQ@mail.gmail.com>
	<20120423063616.GE2058@reaktio.net>
	<CAJP76_CNBp0EOOKcwFtHf0A6nX=tY47MhYODE1SS-fJnmoHtBg@mail.gmail.com>
	<20120423162359.GG2058@reaktio.net>
	<CAJP76_Caha-+MUU05pzdHRxkxSAxeUVuCDozftsOTaysSDCcYA@mail.gmail.com>
	<CAJP76_B35EVJGEoXSP9K7=1y=7yrjNH1ofe5-WqSDggY9ow53Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJP76_B35EVJGEoXSP9K7=1y=7yrjNH1ofe5-WqSDggY9ow53Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen doesn't boot on grub2 or xend doesn't start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 09:54:26AM -0300, Jos=E9 Eduardo Fran=E7a wrote:
>    Pasi,
> =


This thread really belongs to xen-users mailinglist (added to CC).
So let's drop xen-devel from the CC list in the replies..


>    I didn't really understand when You said "I was talking about dom0 Lin=
ux
>    kernel, not about Xen", coz I understand you must be in xen to access
>    dom0.
>    Look: in my grub2 I have these options in grub2:
> =

>    Xen Unstable / Debian Squeeze kernel 2.6.32.40
>    Debian GNU/Linux, with Linux 2.6.32.40
>    Debian GNU/Linux, with Linux 2.6.32-5-686
> =


Please paste the entries from your grub.cfg

>    I select first option and the system returns:
> =

>    error: couldn't open file
>    error: you need to load the multiboot kernel first
> =


So the grub entry is broken. Please fix it.

>    The second option is in graphical environment but keyboard and mouse d=
on't
>    work there. I thought You said to enter within this option (but I think
>    this option is not important)
> =


Of course you need to boot to Xen to be able to use Xen.
I recommend using just the text-only modes.

>    And the third option is my environment where I compiled and installed =
xen
>    and Debian GNU/Linux, with Linux 2.6.32.40.
>    Here I do command "# /etc/init.d/xend start" and the system returns
>    "xencommons should be started first", but I had done
>    "/etc/init.d/xencommons start" before and no error message returned !!=
!???
> =


Did you realize Xen is the hypervisor (xen.gz), and in addition to Xen
you also need Xen-enabled Linux dom0 kernel ? =


http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F


>    and then... what do you think?
> =



-- Pasi


>    Eduardo
> =

>    Em 23 de abril de 2012 13:45, Jos=E9 Eduardo Fran=E7a <[1]jefranca@gma=
il.com>
>    escreveu:
> =

>      Pasi
> =

>      I didn't think this. I'll be in my job tomorrow an I'll reply there.
> =

>      Thank you
> =

>      Em 23 de abril de 2012 13:23, Pasi K=E4rkk=E4inen <[2]pasik@iki.fi>
>      escreveu:
> =

>        On Mon, Apr 23, 2012 at 01:13:49PM -0300, Jos=E9 Eduardo Fran=E7a =
wrote:
>        >    Hi Pasi,
>        >
>        >    thank you for reply.
>        >
>        >    I'm using Debian Squeeze, and I'm compiling Xen from source
>        (.tar.gz). I
>        >    ran "make install-tools PYTHON_PREFIX_ARG=3D" to install Xen.
>        >
>        >    Notice: I couldn't run in xen_unstable or dom0 then I returne=
d to
>        install
>        >    environment (Debian Squeeze)
>        >
>        >    My attempt with modules and now with xenstored command
>        (oxenstored command
>        >    works) was in Debian Squeeze. In this case I think I can't lo=
ad
>        these
>        >    modules or run this command, but I'm not sure. Then your
>        questions can not
>        >    be in this scope. What do you think?
>        >
> =

>        I was talking about dom0 Linux kernel, not about Xen.
> =

>        -- Pasi
> =

>        >    Thanks, Eduardo
>        >
>        >    Em 23 de abril de 2012 03:36, Pasi K=E4rkk=E4inen
>        <[1][3]pasik@iki.fi> escreveu:
>        >
>        >      On Sun, Apr 22, 2012 at 04:21:10PM -0300, Jos=E9 Eduardo Fr=
an=E7a
>        wrote:
>        >      >    hi guys,
>        >      >
>        >
>        >      Hello,
>        >      >    It's my first time here and in a mailing lists, I only
>        participated
>        >      in
>        >      >    forums before. Please, If I make a mistake you should
>        advise me.
>        >      Let's go!
>        >      >
>        >      >    I was reading "xencommons not start" in a Remus Forum =
in
>        order to
>        >      install
>        >      >    Remus.
>        >      >    Well* I followed the tutorial
>        >      >
>        >
>        <[1][2][4]http://remusha.wikidot.com/configuring-and-installing-re=
mus>,
>        I
>        >      reboot
>        >      >    in xen_unstable and I had a error message:
>        >      >
>        >      >    error: couldn't open file
>        >      >    error: you need to load the multiboot kernel first
>        >      >
>        >      >    then I redid tutorial after "Adapt Grub" and in a mome=
nt I
>        do
>        >      command:
>        >      >
>        >      >    # /etc/init.d/xend start
>        >      >    xencommons should be started first.
>        >      >
>        >      >    but I had done "/etc/init.d/xencommons start" before a=
nd
>        no error
>        >      message
>        >      >    returned !!!???
>        >      >
>        >      >    I also tried insert modules manually (coz in other mai=
ling
>        list
>        >      said to
>        >      >    put some modules - see my setups after this mail) but I
>        had:
>        >      >
>        >      >    # modprobe xen-evtchn
>        >      >    FATAL: Module xen_evtchn not found.
>        >      >
>        >
>        >      So xen event channel support is not compiled as a module?
>        >      is it enabled at all in your dom0 kernel config?
>        >
>        >
>         [3][5]http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_=
fails.3F
>        >      -- Pasi
>        >
>        > References
>        >
>        >    Visible links
>        >    1. mailto:[6]pasik@iki.fi
>        >    2. [7]http://remusha.wikidot.com/configuring-and-installing-r=
emus
>        >    3.
>        [8]http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fail=
s.3F
> =

> References
> =

>    Visible links
>    1. mailto:jefranca@gmail.com
>    2. mailto:pasik@iki.fi
>    3. mailto:pasik@iki.fi
>    4. http://remusha.wikidot.com/configuring-and-installing-remus
>    5. http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>    6. mailto:pasik@iki.fi
>    7. http://remusha.wikidot.com/configuring-and-installing-remus
>    8. http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:02:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfNS-0005w2-Ou; Tue, 24 Apr 2012 13:01:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfNR-0005vt-Iz
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:01:53 +0000
Received: from [85.158.143.99:2037] by server-1.bemta-4.messagelabs.com id
	8B/1B-20925-044A69F4; Tue, 24 Apr 2012 13:01:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335272512!24710037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3513 invoked from network); 24 Apr 2012 13:01:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:01:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:01:51 +0100
Date: Tue, 24 Apr 2012 14:07:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: xen_disk backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series is a set of xen_disk improvements backports from
upstream QEMU:

Stefano Stabellini (3):
      xen: handle backend deletion from xenstore
      xen_disk: use bdrv_aio_flush instead of bdrv_flush
      xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

 hw/xen_backend.c |   17 +++++++++--------
 hw/xen_disk.c    |   27 ++++++++++++++++-----------
 2 files changed, 25 insertions(+), 19 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:02:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfNS-0005w2-Ou; Tue, 24 Apr 2012 13:01:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfNR-0005vt-Iz
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:01:53 +0000
Received: from [85.158.143.99:2037] by server-1.bemta-4.messagelabs.com id
	8B/1B-20925-044A69F4; Tue, 24 Apr 2012 13:01:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335272512!24710037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3513 invoked from network); 24 Apr 2012 13:01:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:01:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:01:51 +0100
Date: Tue, 24 Apr 2012 14:07:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: xen_disk backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series is a set of xen_disk improvements backports from
upstream QEMU:

Stefano Stabellini (3):
      xen: handle backend deletion from xenstore
      xen_disk: use bdrv_aio_flush instead of bdrv_flush
      xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

 hw/xen_backend.c |   17 +++++++++--------
 hw/xen_disk.c    |   27 ++++++++++++++++-----------
 2 files changed, 25 insertions(+), 19 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:03:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:03:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfON-00063O-Kz; Tue, 24 Apr 2012 13:02:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfOM-000630-Ju
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:02:50 +0000
Received: from [85.158.138.51:40795] by server-3.bemta-3.messagelabs.com id
	A3/02-04048-974A69F4; Tue, 24 Apr 2012 13:02:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335272566!23417105!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1529 invoked from network); 24 Apr 2012 13:02:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:02:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330923600"; d="scan'208";a="24468876"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:02:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:02:46 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMfOC-0003dK-N7; Tue, 24 Apr 2012 14:02:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 14:08:48 +0100
Message-ID: <1335272929-22967-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] xen_disk: use bdrv_aio_flush instead of
	bdrv_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index f9ef062..900f456 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -382,8 +382,6 @@ static void qemu_aio_complete(void *opaque, int ret)
     ioreq->aio_inflight--;
     if (ioreq->aio_inflight > 0)
         return;
-    if (ioreq->postsync)
-	bdrv_flush(ioreq->blkdev->bs);
 
     ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
     ioreq_unmap(ioreq);
@@ -398,9 +396,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
     if (ioreq->req.nr_segments && ioreq_map(ioreq) == -1)
 	goto err;
 
-    ioreq->aio_inflight++;
-    if (ioreq->presync)
-	bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
+    if (ioreq->presync) {
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+    }
 
     switch (ioreq->req.operation) {
     case BLKIF_OP_READ:
@@ -422,8 +421,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 	/* unknown operation (shouldn't happen -- parse catches this) */
 	goto err;
     }
-
-    qemu_aio_complete(ioreq, 0);
+    if (ioreq->postsync) {
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+    }
 
     return 0;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:03:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:03:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfON-00063O-Kz; Tue, 24 Apr 2012 13:02:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfOM-000630-Ju
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:02:50 +0000
Received: from [85.158.138.51:40795] by server-3.bemta-3.messagelabs.com id
	A3/02-04048-974A69F4; Tue, 24 Apr 2012 13:02:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335272566!23417105!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1529 invoked from network); 24 Apr 2012 13:02:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:02:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330923600"; d="scan'208";a="24468876"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:02:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:02:46 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMfOC-0003dK-N7; Tue, 24 Apr 2012 14:02:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 14:08:48 +0100
Message-ID: <1335272929-22967-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] xen_disk: use bdrv_aio_flush instead of
	bdrv_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index f9ef062..900f456 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -382,8 +382,6 @@ static void qemu_aio_complete(void *opaque, int ret)
     ioreq->aio_inflight--;
     if (ioreq->aio_inflight > 0)
         return;
-    if (ioreq->postsync)
-	bdrv_flush(ioreq->blkdev->bs);
 
     ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
     ioreq_unmap(ioreq);
@@ -398,9 +396,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
     if (ioreq->req.nr_segments && ioreq_map(ioreq) == -1)
 	goto err;
 
-    ioreq->aio_inflight++;
-    if (ioreq->presync)
-	bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
+    if (ioreq->presync) {
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+    }
 
     switch (ioreq->req.operation) {
     case BLKIF_OP_READ:
@@ -422,8 +421,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 	/* unknown operation (shouldn't happen -- parse catches this) */
 	goto err;
     }
-
-    qemu_aio_complete(ioreq, 0);
+    if (ioreq->postsync) {
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+    }
 
     return 0;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:03:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfOO-00063X-22; Tue, 24 Apr 2012 13:02:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfON-000631-4D
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:02:51 +0000
Received: from [85.158.138.51:14015] by server-1.bemta-3.messagelabs.com id
	61/5C-11491-A74A69F4; Tue, 24 Apr 2012 13:02:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335272566!23417105!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1582 invoked from network); 24 Apr 2012 13:02:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:02:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330923600"; d="scan'208";a="24468877"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:02:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:02:46 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMfOC-0003dK-Nf; Tue, 24 Apr 2012 14:02:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 14:08:49 +0100
Message-ID: <1335272929-22967-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] xen_disk: implement
	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 hw/xen_disk.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 900f456..8181af9 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -181,13 +181,13 @@ static int ioreq_parse(struct ioreq *ioreq)
     case BLKIF_OP_READ:
 	ioreq->prot = PROT_WRITE; /* to memory */
 	break;
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments) {
             ioreq->presync = 1;
             return 0;
         }
 	if (!syncwrite)
-	    ioreq->presync = ioreq->postsync = 1;
+        ioreq->postsync = 1;
 	/* fall through */
     case BLKIF_OP_WRITE:
 	ioreq->prot = PROT_READ; /* from memory */
@@ -333,7 +333,7 @@ static int ioreq_runio_qemu_sync(struct ioreq *ioreq)
 	}
 	break;
     case BLKIF_OP_WRITE:
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments)
             break;
 	pos = ioreq->start;
@@ -669,7 +669,7 @@ static int blk_init(struct XenDevice *xendev)
 		  blkdev->file_size, blkdev->file_size >> 20);
 
     /* fill info */
-    xenstore_write_be_int(&blkdev->xendev, "feature-barrier", have_barriers);
+    xenstore_write_be_int(&blkdev->xendev, "feature-flush-cache", 1);
     xenstore_write_be_int(&blkdev->xendev, "info",            info);
     xenstore_write_be_int(&blkdev->xendev, "sector-size",     blkdev->file_blk);
     xenstore_write_be_int(&blkdev->xendev, "sectors",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:03:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfOO-00063X-22; Tue, 24 Apr 2012 13:02:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfON-000631-4D
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:02:51 +0000
Received: from [85.158.138.51:14015] by server-1.bemta-3.messagelabs.com id
	61/5C-11491-A74A69F4; Tue, 24 Apr 2012 13:02:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335272566!23417105!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1582 invoked from network); 24 Apr 2012 13:02:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:02:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330923600"; d="scan'208";a="24468877"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:02:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:02:46 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMfOC-0003dK-Nf; Tue, 24 Apr 2012 14:02:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 14:08:49 +0100
Message-ID: <1335272929-22967-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] xen_disk: implement
	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 hw/xen_disk.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 900f456..8181af9 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -181,13 +181,13 @@ static int ioreq_parse(struct ioreq *ioreq)
     case BLKIF_OP_READ:
 	ioreq->prot = PROT_WRITE; /* to memory */
 	break;
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments) {
             ioreq->presync = 1;
             return 0;
         }
 	if (!syncwrite)
-	    ioreq->presync = ioreq->postsync = 1;
+        ioreq->postsync = 1;
 	/* fall through */
     case BLKIF_OP_WRITE:
 	ioreq->prot = PROT_READ; /* from memory */
@@ -333,7 +333,7 @@ static int ioreq_runio_qemu_sync(struct ioreq *ioreq)
 	}
 	break;
     case BLKIF_OP_WRITE:
-    case BLKIF_OP_WRITE_BARRIER:
+    case BLKIF_OP_FLUSH_DISKCACHE:
         if (!ioreq->req.nr_segments)
             break;
 	pos = ioreq->start;
@@ -669,7 +669,7 @@ static int blk_init(struct XenDevice *xendev)
 		  blkdev->file_size, blkdev->file_size >> 20);
 
     /* fill info */
-    xenstore_write_be_int(&blkdev->xendev, "feature-barrier", have_barriers);
+    xenstore_write_be_int(&blkdev->xendev, "feature-flush-cache", 1);
     xenstore_write_be_int(&blkdev->xendev, "info",            info);
     xenstore_write_be_int(&blkdev->xendev, "sector-size",     blkdev->file_blk);
     xenstore_write_be_int(&blkdev->xendev, "sectors",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:03:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfON-000639-7k; Tue, 24 Apr 2012 13:02:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfOL-00062q-KN
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:02:49 +0000
Received: from [85.158.138.51:40722] by server-7.bemta-3.messagelabs.com id
	A4/9F-03078-874A69F4; Tue, 24 Apr 2012 13:02:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335272566!23417105!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1438 invoked from network); 24 Apr 2012 13:02:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:02:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330923600"; d="scan'208";a="24468875"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:02:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:02:46 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMfOC-0003dK-Mb; Tue, 24 Apr 2012 14:02:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 14:08:47 +0100
Message-ID: <1335272929-22967-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] xen: handle backend deletion from xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_backend.c |   17 +++++++++--------
 hw/xen_disk.c    |    4 ++++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 64dc93a..11e09fc 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -561,7 +561,7 @@ static void xenstore_update_be(char *watch, char *type, int dom,
 			       struct XenDevOps *ops)
 {
     struct XenDevice *xendev;
-    char path[XEN_BUFSIZE], *dom0;
+    char path[XEN_BUFSIZE], *dom0, *bepath;
     unsigned int len, dev;
 
     dom0 = xs_get_domain_path(xenstore, 0);
@@ -577,15 +577,16 @@ static void xenstore_update_be(char *watch, char *type, int dom,
     if (dev == -1)
 	return;
 
-    if (0) {
-	/* FIXME: detect devices being deleted from xenstore ... */
-	xen_be_del_xendev(dom, dev);
-    }
-
     xendev = xen_be_get_xendev(type, dom, dev, ops);
     if (xendev != NULL) {
-	xen_be_backend_changed(xendev, path);
-	xen_be_check_state(xendev);
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+            xen_be_check_state(xendev);
+        }
     }
 }
 
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 5db58ac..f9ef062 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -758,6 +758,10 @@ static int blk_free(struct XenDevice *xendev)
     struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
     struct ioreq *ioreq;
 
+    if (blkdev->bs || blkdev->sring) {
+        blk_disconnect(xendev);
+    }
+
     while (!LIST_EMPTY(&blkdev->freelist)) {
 	ioreq = LIST_FIRST(&blkdev->freelist);
         LIST_REMOVE(ioreq, list);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:03:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfON-000639-7k; Tue, 24 Apr 2012 13:02:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMfOL-00062q-KN
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:02:49 +0000
Received: from [85.158.138.51:40722] by server-7.bemta-3.messagelabs.com id
	A4/9F-03078-874A69F4; Tue, 24 Apr 2012 13:02:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335272566!23417105!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1438 invoked from network); 24 Apr 2012 13:02:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:02:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330923600"; d="scan'208";a="24468875"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 09:02:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 09:02:46 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SMfOC-0003dK-Mb; Tue, 24 Apr 2012 14:02:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 24 Apr 2012 14:08:47 +0100
Message-ID: <1335272929-22967-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] xen: handle backend deletion from xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_backend.c |   17 +++++++++--------
 hw/xen_disk.c    |    4 ++++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 64dc93a..11e09fc 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -561,7 +561,7 @@ static void xenstore_update_be(char *watch, char *type, int dom,
 			       struct XenDevOps *ops)
 {
     struct XenDevice *xendev;
-    char path[XEN_BUFSIZE], *dom0;
+    char path[XEN_BUFSIZE], *dom0, *bepath;
     unsigned int len, dev;
 
     dom0 = xs_get_domain_path(xenstore, 0);
@@ -577,15 +577,16 @@ static void xenstore_update_be(char *watch, char *type, int dom,
     if (dev == -1)
 	return;
 
-    if (0) {
-	/* FIXME: detect devices being deleted from xenstore ... */
-	xen_be_del_xendev(dom, dev);
-    }
-
     xendev = xen_be_get_xendev(type, dom, dev, ops);
     if (xendev != NULL) {
-	xen_be_backend_changed(xendev, path);
-	xen_be_check_state(xendev);
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            xen_be_backend_changed(xendev, path);
+            xen_be_check_state(xendev);
+        }
     }
 }
 
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 5db58ac..f9ef062 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -758,6 +758,10 @@ static int blk_free(struct XenDevice *xendev)
     struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
     struct ioreq *ioreq;
 
+    if (blkdev->bs || blkdev->sring) {
+        blk_disconnect(xendev);
+    }
+
     while (!LIST_EMPTY(&blkdev->freelist)) {
 	ioreq = LIST_FIRST(&blkdev->freelist);
         LIST_REMOVE(ioreq, list);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfUf-0006mT-W9; Tue, 24 Apr 2012 13:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfUe-0006mO-EY
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:09:20 +0000
Received: from [85.158.143.99:38529] by server-2.bemta-4.messagelabs.com id
	1D/99-17550-FF5A69F4; Tue, 24 Apr 2012 13:09:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335272959!18666147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16287 invoked from network); 24 Apr 2012 13:09:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106345"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:09:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:09:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfUR-0005Q4-9s; Tue, 24 Apr 2012 13:09:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfUR-0006re-8w;
	Tue, 24 Apr 2012 14:09:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.42483.262223.837852@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:09:07 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F95160D.90902@tiscali.it>
References: <4F95160D.90902@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] [PATCH v2] Makefile: Some updates to uninstall"):
> Makefile: Some updates to uninstall
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

I have applied this, TBH without more inspection than needed to
convince myself it won't rm -rf /.

But I think this uninstall target is never tested and I would be
surprised if any of the developers use it.  So I think that it's
unlikely to ever be reliable.  Perhaps it would be better to remove it
entirely.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfUf-0006mT-W9; Tue, 24 Apr 2012 13:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfUe-0006mO-EY
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:09:20 +0000
Received: from [85.158.143.99:38529] by server-2.bemta-4.messagelabs.com id
	1D/99-17550-FF5A69F4; Tue, 24 Apr 2012 13:09:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335272959!18666147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16287 invoked from network); 24 Apr 2012 13:09:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106345"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:09:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:09:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfUR-0005Q4-9s; Tue, 24 Apr 2012 13:09:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfUR-0006re-8w;
	Tue, 24 Apr 2012 14:09:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.42483.262223.837852@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:09:07 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F95160D.90902@tiscali.it>
References: <4F95160D.90902@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] Makefile: Some updates to uninstall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] [PATCH v2] Makefile: Some updates to uninstall"):
> Makefile: Some updates to uninstall
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

I have applied this, TBH without more inspection than needed to
convince myself it won't rm -rf /.

But I think this uninstall target is never tested and I would be
surprised if any of the developers use it.  So I think that it's
unlikely to ever be reliable.  Perhaps it would be better to remove it
entirely.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:09:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfV5-0006oJ-Db; Tue, 24 Apr 2012 13:09:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfV2-0006o1-VX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:09:45 +0000
Received: from [85.158.143.35:30502] by server-3.bemta-4.messagelabs.com id
	06/90-05853-816A69F4; Tue, 24 Apr 2012 13:09:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335272982!13491549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17131 invoked from network); 24 Apr 2012 13:09:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:09:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:09:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:09:41 +0100
Message-ID: <1335272980.4347.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Tue, 24 Apr 2012 14:09:40 +0100
In-Reply-To: <20120424121402.GA19331@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 13:14 +0100, Dieter Bloms wrote:
> libxl: set domain scheduling parameters while creating the dom
> 
> the domain specific scheduling parameters like cpu_weight, cap,
> slice, ...
> will be set during creating the domain, so this parameters can be
> defined
> in the domain config file
> 
> Signed-off-by: Dieter Bloms <dieter@bloms.de>
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index e2cd251..4060933 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use.
> Default behavior is
>  (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
>  will run on cpus 2 and 3).
>  
> +=item B<cpu-weight="weight of cpu (default 256)">

I think you mean cpu_weight rather than cpu-weight.

The typography in this file isn't exactly strict but it seems that we
normally put the default in the text rather than in the header and use a
SHOUTY name for the value. e.g.

        =item B<cpu_weight=WEIGHT>
        
        Specifies the weight of the domain. A domain with a weight of
        512 will get twice as much CPU as a domain with a weight of 256
        on a contended host. Legal weights range from 1 to 65535 and the
        default is 256. Can be set for credit, credit2 and sedf
        scheduler.

This also avoids the ambiguous use of " in the title, since depending on
the item the quotes may be a required part of the syntax but not in this
case.

[...]
> +=item B<latency=" (default 0)">

=item B<latency=N>

I think you missed the value here.

[...]
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..38acff4 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t
> domid,
>      char *dom_path, *vm_path;
>      xs_transaction_t t;
>      char **ents, **hvm_ents;
> +    libxl_scheduler sched;
>      int i;
>  
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT2:
> +      libxl_sched_credit2_domain_set(ctx, domid,
> &(info->us.credit2));
> +      break;
> +    case LIBXL_SCHEDULER_ARINC653:
> +      /* not implemented */
> +      break;
> +    default:
> +        abort();
> +    }
> +
>      libxl_cpuid_apply_policy(ctx, domid);
>      if (info->cpuid != NULL)
>          libxl_cpuid_set(ctx, domid, info->cpuid);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..c1cdc3c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -224,6 +224,27 @@ libxl_domain_create_info =
> Struct("domain_create_info",[
>  
>  MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
>  
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> +    ("weight", integer),
> +    ("cap", integer),
> +    ])
> +
> +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
> +    ("weight", integer),
> +    ])
> +
> +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
> +    ("period", integer),
> +    ("slice", integer),
> +    ("latency", integer),
> +    ("extratime", integer),
> +    ("weight", integer),
> +    ])
> +
> +libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
> +    ("weight", integer),
> +    ])
> +
>  # Instances of libxl_file_reference contained in this struct which
>  # have been mapped (with libxl_file_reference_map) will be unmapped
>  # by libxl_domain_build/restore. If either of these are never called
> @@ -256,6 +277,13 @@ libxl_domain_build_info =
> Struct("domain_build_info",[
>      # extra parameters pass directly to qemu for HVM guest, NULL
> terminated
>      ("extra_hvm",        libxl_string_list),
>  
> +    ("us", KeyedUnion(None, libxl_scheduler, "sched",
> +                 [("credit", libxl_sched_credit_domain),
> +                 ("credit2", libxl_sched_credit2_domain),
> +                 ("sedf", libxl_sched_sedf_domain),
> +                 ("arinc653", libxl_sched_arinc653_domain),
> +                 ], keyvar_init_val = "-1")),

I don't think a KeyedUnion is right here, since the user of libxl
doesn't really have a choice about which scheduler is in user (that's
set at boot time or via cpupool interfaces).

You could use a Union, but below I'll make an argument that perhaps a
Struct would be better.

[...]
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 5703512..db51ca6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -587,6 +587,23 @@ static void parse_config_data(const char
> *configfile_filename_report,
>      libxl_domain_build_info_init_type(b_info, c_info->type);
>  
>      /* the following is the actual config parsing with overriding
> values in the structures */
> +    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
> +        b_info->us.credit.weight = l;
> +        b_info->us.credit2.weight = l;
> +        b_info->us.sedf.weight = l;

You need {} here otherwise only the credit setting is associated with
the if.

However, since b_info->us is a union this is actually setting the same
value into different places in overlapping memory (since all member of a
union occupy the same storage). One solution would be to use
libxl_get_scheduler to get the scheduler and fill in only the correct
option, but then that gets complex when you have to deal with cpupools
etc.

I think you should make "us" a Struct and call it sched_params or
something along those lines. It's just simpler all around, libxl can
internally figure out which set of parms to use (as you do correctly in
this patch).

Does the above make sense?

Ian.


> +    if (!xlu_cfg_get_long (config, "cap", &l, 0))
> +        b_info->us.credit.cap = l;
> +
> +    if (!xlu_cfg_get_long (config, "period", &l, 0))
> +        b_info->us.sedf.period = l;
> +    if (!xlu_cfg_get_long (config, "slice", &l, 0))
> +        b_info->us.sedf.period = l;
> +    if (!xlu_cfg_get_long (config, "latency", &l, 0))
> +        b_info->us.sedf.period = l;
> +    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
> +        b_info->us.sedf.period = l;
> +
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
>          b_info->cur_vcpus = (1 << l) - 1;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:09:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfV5-0006oJ-Db; Tue, 24 Apr 2012 13:09:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfV2-0006o1-VX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:09:45 +0000
Received: from [85.158.143.35:30502] by server-3.bemta-4.messagelabs.com id
	06/90-05853-816A69F4; Tue, 24 Apr 2012 13:09:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335272982!13491549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17131 invoked from network); 24 Apr 2012 13:09:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:09:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:09:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:09:41 +0100
Message-ID: <1335272980.4347.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Tue, 24 Apr 2012 14:09:40 +0100
In-Reply-To: <20120424121402.GA19331@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 13:14 +0100, Dieter Bloms wrote:
> libxl: set domain scheduling parameters while creating the dom
> 
> the domain specific scheduling parameters like cpu_weight, cap,
> slice, ...
> will be set during creating the domain, so this parameters can be
> defined
> in the domain config file
> 
> Signed-off-by: Dieter Bloms <dieter@bloms.de>
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index e2cd251..4060933 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use.
> Default behavior is
>  (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
>  will run on cpus 2 and 3).
>  
> +=item B<cpu-weight="weight of cpu (default 256)">

I think you mean cpu_weight rather than cpu-weight.

The typography in this file isn't exactly strict but it seems that we
normally put the default in the text rather than in the header and use a
SHOUTY name for the value. e.g.

        =item B<cpu_weight=WEIGHT>
        
        Specifies the weight of the domain. A domain with a weight of
        512 will get twice as much CPU as a domain with a weight of 256
        on a contended host. Legal weights range from 1 to 65535 and the
        default is 256. Can be set for credit, credit2 and sedf
        scheduler.

This also avoids the ambiguous use of " in the title, since depending on
the item the quotes may be a required part of the syntax but not in this
case.

[...]
> +=item B<latency=" (default 0)">

=item B<latency=N>

I think you missed the value here.

[...]
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..38acff4 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t
> domid,
>      char *dom_path, *vm_path;
>      xs_transaction_t t;
>      char **ents, **hvm_ents;
> +    libxl_scheduler sched;
>      int i;
>  
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT2:
> +      libxl_sched_credit2_domain_set(ctx, domid,
> &(info->us.credit2));
> +      break;
> +    case LIBXL_SCHEDULER_ARINC653:
> +      /* not implemented */
> +      break;
> +    default:
> +        abort();
> +    }
> +
>      libxl_cpuid_apply_policy(ctx, domid);
>      if (info->cpuid != NULL)
>          libxl_cpuid_set(ctx, domid, info->cpuid);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..c1cdc3c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -224,6 +224,27 @@ libxl_domain_create_info =
> Struct("domain_create_info",[
>  
>  MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
>  
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> +    ("weight", integer),
> +    ("cap", integer),
> +    ])
> +
> +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
> +    ("weight", integer),
> +    ])
> +
> +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
> +    ("period", integer),
> +    ("slice", integer),
> +    ("latency", integer),
> +    ("extratime", integer),
> +    ("weight", integer),
> +    ])
> +
> +libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
> +    ("weight", integer),
> +    ])
> +
>  # Instances of libxl_file_reference contained in this struct which
>  # have been mapped (with libxl_file_reference_map) will be unmapped
>  # by libxl_domain_build/restore. If either of these are never called
> @@ -256,6 +277,13 @@ libxl_domain_build_info =
> Struct("domain_build_info",[
>      # extra parameters pass directly to qemu for HVM guest, NULL
> terminated
>      ("extra_hvm",        libxl_string_list),
>  
> +    ("us", KeyedUnion(None, libxl_scheduler, "sched",
> +                 [("credit", libxl_sched_credit_domain),
> +                 ("credit2", libxl_sched_credit2_domain),
> +                 ("sedf", libxl_sched_sedf_domain),
> +                 ("arinc653", libxl_sched_arinc653_domain),
> +                 ], keyvar_init_val = "-1")),

I don't think a KeyedUnion is right here, since the user of libxl
doesn't really have a choice about which scheduler is in user (that's
set at boot time or via cpupool interfaces).

You could use a Union, but below I'll make an argument that perhaps a
Struct would be better.

[...]
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 5703512..db51ca6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -587,6 +587,23 @@ static void parse_config_data(const char
> *configfile_filename_report,
>      libxl_domain_build_info_init_type(b_info, c_info->type);
>  
>      /* the following is the actual config parsing with overriding
> values in the structures */
> +    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
> +        b_info->us.credit.weight = l;
> +        b_info->us.credit2.weight = l;
> +        b_info->us.sedf.weight = l;

You need {} here otherwise only the credit setting is associated with
the if.

However, since b_info->us is a union this is actually setting the same
value into different places in overlapping memory (since all member of a
union occupy the same storage). One solution would be to use
libxl_get_scheduler to get the scheduler and fill in only the correct
option, but then that gets complex when you have to deal with cpupools
etc.

I think you should make "us" a Struct and call it sched_params or
something along those lines. It's just simpler all around, libxl can
internally figure out which set of parms to use (as you do correctly in
this patch).

Does the above make sense?

Ian.


> +    if (!xlu_cfg_get_long (config, "cap", &l, 0))
> +        b_info->us.credit.cap = l;
> +
> +    if (!xlu_cfg_get_long (config, "period", &l, 0))
> +        b_info->us.sedf.period = l;
> +    if (!xlu_cfg_get_long (config, "slice", &l, 0))
> +        b_info->us.sedf.period = l;
> +    if (!xlu_cfg_get_long (config, "latency", &l, 0))
> +        b_info->us.sedf.period = l;
> +    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
> +        b_info->us.sedf.period = l;
> +
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
>          b_info->cur_vcpus = (1 << l) - 1;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfam-0007Gc-4n; Tue, 24 Apr 2012 13:15:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfak-0007GO-H0
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:15:38 +0000
Received: from [193.109.254.147:49993] by server-8.bemta-14.messagelabs.com id
	6B/D1-23244-977A69F4; Tue, 24 Apr 2012 13:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335273323!3612070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8735 invoked from network); 24 Apr 2012 13:15:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:15:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:15:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:15:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfaU-0005VN-Ko; Tue, 24 Apr 2012 13:15:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfaU-0006sG-Jk;
	Tue, 24 Apr 2012 14:15:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.42858.598595.230007@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:15:22 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F954422.1010803@tiscali.it>
References: <4F954422.1010803@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] [PATCH] tools: Improve make deb"):
> tools: Improve make deb

I'm rather unconvinced by this, in general.  The logical conclusion
would be for us to end up with machinery which attempts to make a
fully featured package.  I think this task is best left to a distro.

The "make deb" target is there to provide something convenient for
development and testing.

On to the individual changes:

> - Remove version from installed package name

Why ?

> - Add conffiles to manage main config files on package update

I would be inclined to take this if it were presented on its own.  The
effect can be useful during testing, and a dpkg purge will easily undo
it.

> - Add/remove of main services (xencommons, xendomains)

I think this is a bad idea, for the reasons I explain above.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfam-0007Gc-4n; Tue, 24 Apr 2012 13:15:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfak-0007GO-H0
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:15:38 +0000
Received: from [193.109.254.147:49993] by server-8.bemta-14.messagelabs.com id
	6B/D1-23244-977A69F4; Tue, 24 Apr 2012 13:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335273323!3612070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8735 invoked from network); 24 Apr 2012 13:15:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:15:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:15:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:15:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfaU-0005VN-Ko; Tue, 24 Apr 2012 13:15:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfaU-0006sG-Jk;
	Tue, 24 Apr 2012 14:15:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.42858.598595.230007@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:15:22 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F954422.1010803@tiscali.it>
References: <4F954422.1010803@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] [PATCH] tools: Improve make deb"):
> tools: Improve make deb

I'm rather unconvinced by this, in general.  The logical conclusion
would be for us to end up with machinery which attempts to make a
fully featured package.  I think this task is best left to a distro.

The "make deb" target is there to provide something convenient for
development and testing.

On to the individual changes:

> - Remove version from installed package name

Why ?

> - Add conffiles to manage main config files on package update

I would be inclined to take this if it were presented on its own.  The
effect can be useful during testing, and a dpkg purge will easily undo
it.

> - Add/remove of main services (xencommons, xendomains)

I think this is a bad idea, for the reasons I explain above.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:17:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfcc-0007Qx-Lo; Tue, 24 Apr 2012 13:17:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfcb-0007Ql-LK
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:17:33 +0000
Received: from [193.109.254.147:34681] by server-4.bemta-14.messagelabs.com id
	F4/B0-11570-CE7A69F4; Tue, 24 Apr 2012 13:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335273452!3612622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19104 invoked from network); 24 Apr 2012 13:17:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:17:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:17:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:17:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfcZ-0005WQ-PA; Tue, 24 Apr 2012 13:17:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfcZ-0006si-O5;
	Tue, 24 Apr 2012 14:17:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.42987.732159.638716@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:17:31 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend
	is	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: prevent xl from running if xend is running."):
> Prevent xl from doing any operation if xend daemon is running. That prevents
> bugs that happened when xl and xend raced to close a domain.

Can we somehow limit this to commands that actually change things ?
Having xl as a diagnostic tool even for xend-based systems is useful.

> +        if (!access(locks[i], F_OK) && !force_execution) {
> +            fprintf(stderr, "xend is running, which prevents xl from working "
> +                            "correctly. If you still want to force the "
> +                            "execution of xl please use the -f option\n");
> +            exit(2);
> +        }

If access fails with an unexpected error code (EACCES? EIO?) this will
blunder on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:17:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfcc-0007Qx-Lo; Tue, 24 Apr 2012 13:17:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfcb-0007Ql-LK
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:17:33 +0000
Received: from [193.109.254.147:34681] by server-4.bemta-14.messagelabs.com id
	F4/B0-11570-CE7A69F4; Tue, 24 Apr 2012 13:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335273452!3612622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19104 invoked from network); 24 Apr 2012 13:17:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:17:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:17:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:17:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfcZ-0005WQ-PA; Tue, 24 Apr 2012 13:17:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfcZ-0006si-O5;
	Tue, 24 Apr 2012 14:17:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.42987.732159.638716@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:17:31 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend
	is	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: prevent xl from running if xend is running."):
> Prevent xl from doing any operation if xend daemon is running. That prevents
> bugs that happened when xl and xend raced to close a domain.

Can we somehow limit this to commands that actually change things ?
Having xl as a diagnostic tool even for xend-based systems is useful.

> +        if (!access(locks[i], F_OK) && !force_execution) {
> +            fprintf(stderr, "xend is running, which prevents xl from working "
> +                            "correctly. If you still want to force the "
> +                            "execution of xl please use the -f option\n");
> +            exit(2);
> +        }

If access fails with an unexpected error code (EACCES? EIO?) this will
blunder on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:19:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfe7-0007Yu-5g; Tue, 24 Apr 2012 13:19:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfe5-0007Yi-R9
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:19:06 +0000
Received: from [85.158.139.83:38111] by server-6.bemta-5.messagelabs.com id
	99/89-13222-948A69F4; Tue, 24 Apr 2012 13:19:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335273540!25258403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18707 invoked from network); 24 Apr 2012 13:19:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:18:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:18:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfds-0005Ws-To; Tue, 24 Apr 2012 13:18:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfds-0006sv-Sx;
	Tue, 24 Apr 2012 14:18:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43068.882959.571687@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:18:52 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335194783.4347.34.camel@zakaz.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<1335194783.4347.34.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is running."):
> On Mon, 2012-04-23 at 16:11 +0100, Roger Pau Monne wrote:
...
> > +    for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
> > +        if (!access(locks[i], F_OK) && !force_execution) {
> > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > +                            "correctly. If you still want to force the "
> > +                            "execution of xl please use the -f option\n");
> 
> You might as well wrap the output text to 80 columns (I didn't count, I
> assume this isn't...)

It should be.  The best way to do this is probably something like
this:

+            fprintf(stderr,
+ "xend is running, which prevents xl from working correctly.\n"
+ "If you still want to force the execution of xl please use the -f\n"
+ "option\n"
+                    );

(adjust to taste)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:19:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfe7-0007Yu-5g; Tue, 24 Apr 2012 13:19:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfe5-0007Yi-R9
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:19:06 +0000
Received: from [85.158.139.83:38111] by server-6.bemta-5.messagelabs.com id
	99/89-13222-948A69F4; Tue, 24 Apr 2012 13:19:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335273540!25258403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18707 invoked from network); 24 Apr 2012 13:19:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:18:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:18:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfds-0005Ws-To; Tue, 24 Apr 2012 13:18:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfds-0006sv-Sx;
	Tue, 24 Apr 2012 14:18:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43068.882959.571687@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:18:52 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335194783.4347.34.camel@zakaz.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<1335194783.4347.34.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is running."):
> On Mon, 2012-04-23 at 16:11 +0100, Roger Pau Monne wrote:
...
> > +    for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
> > +        if (!access(locks[i], F_OK) && !force_execution) {
> > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > +                            "correctly. If you still want to force the "
> > +                            "execution of xl please use the -f option\n");
> 
> You might as well wrap the output text to 80 columns (I didn't count, I
> assume this isn't...)

It should be.  The best way to do this is probably something like
this:

+            fprintf(stderr,
+ "xend is running, which prevents xl from working correctly.\n"
+ "If you still want to force the execution of xl please use the -f\n"
+ "option\n"
+                    );

(adjust to taste)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:22:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfhB-0007oY-Pk; Tue, 24 Apr 2012 13:22:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfh9-0007oB-IQ
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:22:15 +0000
Received: from [85.158.143.35:23068] by server-2.bemta-4.messagelabs.com id
	F5/82-17550-609A69F4; Tue, 24 Apr 2012 13:22:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335273734!13449600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32502 invoked from network); 24 Apr 2012 13:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106702"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:22:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:22:13 +0100
Message-ID: <1335273732.4347.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 24 Apr 2012 14:22:12 +0100
In-Reply-To: <4F954422.1010803@tiscali.it>
References: <4F954422.1010803@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 12:59 +0100, Fabio Fantoni wrote:
> # HG changeset patch
> # User Fabio Fantoni
> # Date 1335181425 -7200
> # Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
> # Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
> tools: Improve make deb
> - Remove version from installed package name

Why? It seems to be common practice in Debian to include the version in
the package name for packages such as kernels and hypervisors.

> - Add conffiles to manage main config files on package update
> - Add/remove of main services (xencommons, xendomains)

I don't have any particular objection to doing this but I think we need
to be clear about what the purpose of Xen's "deb" target is.

It is intended as a convenience to developers (and perhaps some subset
of users), to allow them to do a reasonably clean "uninstall" of Xen
installed from source. It is not really intended to provide anything
more than that.

In particular the packages may not be fully policy compliant and we do
not plan to support things such as upgrades and the like. It also may
well be the case the installing the .deb is not sufficient to get a
working Xen system (i.e. you may still need to do much of the manual
configuration which is needed if you are building from source). If users
want a good, well supported package, well integrated, policy compliant
package for their distro then they should get it from the experts --
i.e. from the distro.

I'm just concerned that with these patches you may be trying to turn
this simple convenience functionality into something which you think is
suitable for end user consumption, which is something we need to think
carefully about since there is a maintenance (and expectation) burden
imposed by doing that.

> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
> --- a/tools/misc/mkdeb    lun apr 23 10:26:55 2012 +0200
> +++ b/tools/misc/mkdeb    lun apr 23 13:43:45 2012 +0200
> @@ -33,7 +33,7 @@
>   # Fill in the debian boilerplate
>   mkdir -p deb/DEBIAN
>   cat >deb/DEBIAN/control <<EOF
> -Package: xen-upstream-$version
> +Package: xen-upstream
>   Source: xen-upstream
>   Version: $version
>   Architecture: $arch
> @@ -47,9 +47,27 @@
>    the output of a xen "make dist" wrapped in a .deb to make it easy to
>    uninstall.
>   EOF
> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF
> +cat >deb/DEBIAN/postinst <<EOF
> +#!/bin/bash -e
> +insserv xencommons &&
> +insserv xendomains
> +EOF
> +cat >deb/DEBIAN/postrm <<EOF
> +#!/bin/bash -e
> +update-rc.d xendomains remove >/dev/null
> +update-rc.d xencommons remove >/dev/null
> +EOF

Calling inserv directly on install and update-rc.d on remove seems like
it is probably wrong. I suspect update-rc.d "add" is what you want.

> 
>   # Package it up
>   chown -R root:root deb
> +chmod +x deb/DEBIAN/postinst
> +chmod +x deb/DEBIAN/postrm
>   dpkg --build deb xen-upstream-$version.deb
> 
>   # Tidy up after ourselves
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:22:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfhB-0007oY-Pk; Tue, 24 Apr 2012 13:22:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfh9-0007oB-IQ
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:22:15 +0000
Received: from [85.158.143.35:23068] by server-2.bemta-4.messagelabs.com id
	F5/82-17550-609A69F4; Tue, 24 Apr 2012 13:22:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335273734!13449600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32502 invoked from network); 24 Apr 2012 13:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106702"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:22:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:22:13 +0100
Message-ID: <1335273732.4347.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 24 Apr 2012 14:22:12 +0100
In-Reply-To: <4F954422.1010803@tiscali.it>
References: <4F954422.1010803@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-23 at 12:59 +0100, Fabio Fantoni wrote:
> # HG changeset patch
> # User Fabio Fantoni
> # Date 1335181425 -7200
> # Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
> # Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
> tools: Improve make deb
> - Remove version from installed package name

Why? It seems to be common practice in Debian to include the version in
the package name for packages such as kernels and hypervisors.

> - Add conffiles to manage main config files on package update
> - Add/remove of main services (xencommons, xendomains)

I don't have any particular objection to doing this but I think we need
to be clear about what the purpose of Xen's "deb" target is.

It is intended as a convenience to developers (and perhaps some subset
of users), to allow them to do a reasonably clean "uninstall" of Xen
installed from source. It is not really intended to provide anything
more than that.

In particular the packages may not be fully policy compliant and we do
not plan to support things such as upgrades and the like. It also may
well be the case the installing the .deb is not sufficient to get a
working Xen system (i.e. you may still need to do much of the manual
configuration which is needed if you are building from source). If users
want a good, well supported package, well integrated, policy compliant
package for their distro then they should get it from the experts --
i.e. from the distro.

I'm just concerned that with these patches you may be trying to turn
this simple convenience functionality into something which you think is
suitable for end user consumption, which is something we need to think
carefully about since there is a maintenance (and expectation) burden
imposed by doing that.

> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
> --- a/tools/misc/mkdeb    lun apr 23 10:26:55 2012 +0200
> +++ b/tools/misc/mkdeb    lun apr 23 13:43:45 2012 +0200
> @@ -33,7 +33,7 @@
>   # Fill in the debian boilerplate
>   mkdir -p deb/DEBIAN
>   cat >deb/DEBIAN/control <<EOF
> -Package: xen-upstream-$version
> +Package: xen-upstream
>   Source: xen-upstream
>   Version: $version
>   Architecture: $arch
> @@ -47,9 +47,27 @@
>    the output of a xen "make dist" wrapped in a .deb to make it easy to
>    uninstall.
>   EOF
> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF
> +cat >deb/DEBIAN/postinst <<EOF
> +#!/bin/bash -e
> +insserv xencommons &&
> +insserv xendomains
> +EOF
> +cat >deb/DEBIAN/postrm <<EOF
> +#!/bin/bash -e
> +update-rc.d xendomains remove >/dev/null
> +update-rc.d xencommons remove >/dev/null
> +EOF

Calling inserv directly on install and update-rc.d on remove seems like
it is probably wrong. I suspect update-rc.d "add" is what you want.

> 
>   # Package it up
>   chown -R root:root deb
> +chmod +x deb/DEBIAN/postinst
> +chmod +x deb/DEBIAN/postrm
>   dpkg --build deb xen-upstream-$version.deb
> 
>   # Tidy up after ourselves
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:25:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfjp-0007y4-Dn; Tue, 24 Apr 2012 13:25:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfjo-0007xz-Ni
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:25:00 +0000
Received: from [85.158.139.83:3903] by server-7.bemta-5.messagelabs.com id
	B6/58-16195-BA9A69F4; Tue, 24 Apr 2012 13:24:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335273898!24588599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29189 invoked from network); 24 Apr 2012 13:24:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:24:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:24:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:24:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfjl-0005Yg-IL; Tue, 24 Apr 2012 13:24:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfjl-0006tT-HN;
	Tue, 24 Apr 2012 14:24:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43433.379674.977454@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:24:57 +0100
To: Dieter Bloms <dieter@bloms.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120424121402.GA19331@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dieter Bloms writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> On Tue, Apr 24, Dario Faggioli wrote:
> > What might be missing is some documentation in docs/man/xl.cfg.pod.5,
> > explaining about the new options... :-)
> 
> I've added a little documentation, so now I hope it is ok.

This is better, thanks.  I have some comments.

> +=item B<cpu-weight="weight of cpu (default 256)">

I'm not qualified to review the documented semantics here.

> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..38acff4 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT2:
> +      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
> +      break;
> +    case LIBXL_SCHEDULER_ARINC653:
> +      /* not implemented */
> +      break;
> +    default:
> +        abort();
> +    }

This is a very repetitive piece of code.  Can't it be autogenerated
somehow by the idl compiler ?  Ian C ?

Also, we use 4-character indents and you have used 2.  (If this were
the only thing that needed changing I would fix it when I committed.)

> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..c1cdc3c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -224,6 +224,27 @@ libxl_domain_create_info = Struct("domain_create_info",[
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> +    ("weight", integer),
> +    ("cap", integer),
> +    ])

You seem to have just moved many of these about ?  That's just because
the idl file doesn't support forward declarations, right ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:25:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfjp-0007y4-Dn; Tue, 24 Apr 2012 13:25:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfjo-0007xz-Ni
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:25:00 +0000
Received: from [85.158.139.83:3903] by server-7.bemta-5.messagelabs.com id
	B6/58-16195-BA9A69F4; Tue, 24 Apr 2012 13:24:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335273898!24588599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29189 invoked from network); 24 Apr 2012 13:24:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:24:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:24:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:24:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfjl-0005Yg-IL; Tue, 24 Apr 2012 13:24:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfjl-0006tT-HN;
	Tue, 24 Apr 2012 14:24:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43433.379674.977454@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:24:57 +0100
To: Dieter Bloms <dieter@bloms.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120424121402.GA19331@bloms.de>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dieter Bloms writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> On Tue, Apr 24, Dario Faggioli wrote:
> > What might be missing is some documentation in docs/man/xl.cfg.pod.5,
> > explaining about the new options... :-)
> 
> I've added a little documentation, so now I hope it is ok.

This is better, thanks.  I have some comments.

> +=item B<cpu-weight="weight of cpu (default 256)">

I'm not qualified to review the documented semantics here.

> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 0bdd654..38acff4 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT2:
> +      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
> +      break;
> +    case LIBXL_SCHEDULER_ARINC653:
> +      /* not implemented */
> +      break;
> +    default:
> +        abort();
> +    }

This is a very repetitive piece of code.  Can't it be autogenerated
somehow by the idl compiler ?  Ian C ?

Also, we use 4-character indents and you have used 2.  (If this were
the only thing that needed changing I would fix it when I committed.)

> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5cf9708..c1cdc3c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -224,6 +224,27 @@ libxl_domain_create_info = Struct("domain_create_info",[
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> +    ("weight", integer),
> +    ("cap", integer),
> +    ])

You seem to have just moved many of these about ?  That's just because
the idl file doesn't support forward declarations, right ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfmP-000893-WA; Tue, 24 Apr 2012 13:27:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfmO-00088r-Hs
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:27:40 +0000
Received: from [85.158.143.99:20816] by server-2.bemta-4.messagelabs.com id
	5D/EC-17550-B4AA69F4; Tue, 24 Apr 2012 13:27:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335274059!26484404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28873 invoked from network); 24 Apr 2012 13:27:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:27:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:27:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:27:38 +0100
Message-ID: <1335274056.4347.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:27:36 +0100
In-Reply-To: <20374.43433.379674.977454@mariner.uk.xensource.com>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>	<20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>	<20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>	<20120424121402.GA19331@bloms.de>
	<20374.43433.379674.977454@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:24 +0100, Ian Jackson wrote:
> Dieter Bloms writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> > On Tue, Apr 24, Dario Faggioli wrote:
> > > What might be missing is some documentation in docs/man/xl.cfg.pod.5,
> > > explaining about the new options... :-)
> > 
> > I've added a little documentation, so now I hope it is ok.
> 
> This is better, thanks.  I have some comments.
> 
> > +=item B<cpu-weight="weight of cpu (default 256)">
> 
> I'm not qualified to review the documented semantics here.
> 
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index 0bdd654..38acff4 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
> > +    sched = libxl_get_scheduler (ctx);
> > +    switch (sched) {
> > +    case LIBXL_SCHEDULER_SEDF:
> > +      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
> > +      break;
> > +    case LIBXL_SCHEDULER_CREDIT:
> > +      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
> > +      break;
> > +    case LIBXL_SCHEDULER_CREDIT2:
> > +      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
> > +      break;
> > +    case LIBXL_SCHEDULER_ARINC653:
> > +      /* not implemented */
> > +      break;
> > +    default:
> > +        abort();
> > +    }
> 
> This is a very repetitive piece of code.  Can't it be autogenerated
> somehow by the idl compiler ?  Ian C ?

Not without a bunch more plumbing in the infrastructure, which would
probably heavily outweigh the code here...

A compromise might be to make this a libxl__sched_set_params(gc, domid,
&info->us), so at least it wouldn't be repeated again somewhere.

> Also, we use 4-character indents and you have used 2.  (If this were
> the only thing that needed changing I would fix it when I committed.)
> 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 5cf9708..c1cdc3c 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -224,6 +224,27 @@ libxl_domain_create_info = Struct("domain_create_info",[
> > +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> > +    ("weight", integer),
> > +    ("cap", integer),
> > +    ])
> 
> You seem to have just moved many of these about ?

I think he said as much in his commit message? Oh, it was actually in
the comment of hte previous posting:
> I've defined a new union in the libxl_domain_build_info structure.
> For this I had to move some structure definition like
> libxl_sched_credit_domain more to the top.


>   That's just because
> the idl file doesn't support forward declarations, right ?
> 
> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfmP-000893-WA; Tue, 24 Apr 2012 13:27:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfmO-00088r-Hs
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:27:40 +0000
Received: from [85.158.143.99:20816] by server-2.bemta-4.messagelabs.com id
	5D/EC-17550-B4AA69F4; Tue, 24 Apr 2012 13:27:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335274059!26484404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28873 invoked from network); 24 Apr 2012 13:27:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:27:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:27:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:27:38 +0100
Message-ID: <1335274056.4347.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:27:36 +0100
In-Reply-To: <20374.43433.379674.977454@mariner.uk.xensource.com>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>	<20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>	<20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>	<20120424121402.GA19331@bloms.de>
	<20374.43433.379674.977454@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:24 +0100, Ian Jackson wrote:
> Dieter Bloms writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> > On Tue, Apr 24, Dario Faggioli wrote:
> > > What might be missing is some documentation in docs/man/xl.cfg.pod.5,
> > > explaining about the new options... :-)
> > 
> > I've added a little documentation, so now I hope it is ok.
> 
> This is better, thanks.  I have some comments.
> 
> > +=item B<cpu-weight="weight of cpu (default 256)">
> 
> I'm not qualified to review the documented semantics here.
> 
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index 0bdd654..38acff4 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -124,8 +124,27 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
> > +    sched = libxl_get_scheduler (ctx);
> > +    switch (sched) {
> > +    case LIBXL_SCHEDULER_SEDF:
> > +      libxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
> > +      break;
> > +    case LIBXL_SCHEDULER_CREDIT:
> > +      libxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
> > +      break;
> > +    case LIBXL_SCHEDULER_CREDIT2:
> > +      libxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2));
> > +      break;
> > +    case LIBXL_SCHEDULER_ARINC653:
> > +      /* not implemented */
> > +      break;
> > +    default:
> > +        abort();
> > +    }
> 
> This is a very repetitive piece of code.  Can't it be autogenerated
> somehow by the idl compiler ?  Ian C ?

Not without a bunch more plumbing in the infrastructure, which would
probably heavily outweigh the code here...

A compromise might be to make this a libxl__sched_set_params(gc, domid,
&info->us), so at least it wouldn't be repeated again somewhere.

> Also, we use 4-character indents and you have used 2.  (If this were
> the only thing that needed changing I would fix it when I committed.)
> 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 5cf9708..c1cdc3c 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -224,6 +224,27 @@ libxl_domain_create_info = Struct("domain_create_info",[
> > +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> > +    ("weight", integer),
> > +    ("cap", integer),
> > +    ])
> 
> You seem to have just moved many of these about ?

I think he said as much in his commit message? Oh, it was actually in
the comment of hte previous posting:
> I've defined a new union in the libxl_domain_build_info structure.
> For this I had to move some structure definition like
> libxl_sched_credit_domain more to the top.


>   That's just because
> the idl file doesn't support forward declarations, right ?
> 
> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:29:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfng-0008Fc-FM; Tue, 24 Apr 2012 13:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMfnf-0008FQ-4j
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:28:59 +0000
Received: from [85.158.143.99:57768] by server-2.bemta-4.messagelabs.com id
	B2/5F-17550-A9AA69F4; Tue, 24 Apr 2012 13:28:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335274137!15281499!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14933 invoked from network); 24 Apr 2012 13:28:57 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 13:28:57 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id E18C7604079;
	Tue, 24 Apr 2012 06:28:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=X6x/wVWAf4vomuoZ5dY9grgR6yOZNSXU6RfufUeYVw4T
	qt+3Qu/YOqHYfgstDBzfAymC2zMFDTg4+U4LLd+HipQoaaSCkJr+377pPbJOW8if
	gMqKVx1M9SNFwAaQ8sqjHh4C2QbgoXTqhTdYlnrxMFf4ZOEdhUGSJCrG5EePehk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=dw0gZH2QDml2H6SogNAK/OFKIcE=; b=cWCj2+01
	hPWajAx0etrpv9zdPwI9TafWCK0Ezf7FoGaUy5G+RWa+qywJWYBE/ayWcFJORzdG
	bDzc0HameRXu6zdud4VWbX0WxY4ciNDTdczWk71+0/e4U8rIhTHKaahufHJuM3f3
	VwIXq7iKUZhYdswcwWyMZdpK8lS2IVIKwmA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 5BACE604078; 
	Tue, 24 Apr 2012 06:28:56 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 06:28:56 -0700
Message-ID: <37a26e60a3ba063166129c8b7e4ca93f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120424091549.GA34721@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
	<20120424091549.GA34721@ocelot.phlegethon.org>
Date: Tue, 24 Apr 2012 06:28:56 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 08:26 -0700 on 23 Apr (1335169568), Andres Lagar-Cavilla wrote:
>> > At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
>> >> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
>> >> profiling data with 10 seconds:
>> >>
>> >> (XEN) p2m_lock 1 lock:
>> >> (XEN)   lock:      190733(00000000:14CE5726), block:
>> >> 67159(00000007:6AAA53F3)
>> >>
>> >> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>> >> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
>> >> is waiting for the p2m lock. And those data only for idle guest. The
>> >> impaction is more seriously when run some workload inside guest.  I
>> >> noticed that this change was adding by cs 24770. And before it, we
>> >> don't require the p2m lock in _get_gfn_type_access. So is this lock
>> >> really necessary?
>> >
>> > Ugh; that certainly is a regression.  We used to be lock-free on p2m
>> > lookups and losing that will be bad for perf in lots of ways.  IIRC
>> the
>> > original aim was to use fine-grained per-page locks for this -- there
>> > should be no need to hold a per-domain lock during a normal read.
>> > Andres, what happened to that code?
>>
>> The fine-grained p2m locking code is stashed somewhere and untested.
>> Obviously not meant for 4.2. I don't think it'll be useful here: all
>> vcpus
>> are hitting the same gfn for the hpet mmio address.
>
> We'll have to do _something_ for 4.2 if it's introducing an 18% CPU
> overhead in an otherwise idle VM.

An hpet mmio read or write hits get_gfn twice: one for gfn zero at the
beginning of hvmemul_do_io, the other during hvm copy. The patch I sent to
Yang yesterday removes the bogus first get_gfn. The second one has to
perform a locked query.

Yang, is there any possibility to get more information here? The ability
to identify the call site that contends for the p2m lock would be crucial.
Even something as crude as sampling vcpu stack traces by hitting 'd'
repeatedly on the serial line, and seeing what sticks out frequently.

>
> In any case I think this means I probably shouldn't take the patch that
> turns on this locking for shadow VMs.  They do a lot more p2m lookups.
>
>> The other source of contention might come from hvmemul_rep_movs, which
>> holds the p2m lock for the duration of the mmio operation. I can
>> optimize
>> that one using the get_gfn/get_page/put_gfn pattern mentioned above.
>
> But wouldn't that be unsafe?  What if the p2m changes during the
> operation?  Or, conversely, could you replace all uses of the lock in
> p2m lookups with get_page() on the result and still get what you need?

I've been thinking of wrapping the pattern into a handy p2m accessor. I
see this pattern repeating itself for hvm_copy, tss/segment entry, page
table walking, nested hvm, etc, in which the consumer wants to map the
result of the translation. By the time you finish with a get_gfn_unshare,
most possible p2m transformations will have been taken care of (PoD-alloc,
page in, unshare). By taking a reference to the underlying page, paging
out is prevented, and then the vcpu can safely let go of the p2m lock.

Conceivably guest_physmap_remove_page and guest_physmap_add_entry can
still come in and change the p2m entry.

Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:29:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfng-0008Fc-FM; Tue, 24 Apr 2012 13:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMfnf-0008FQ-4j
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:28:59 +0000
Received: from [85.158.143.99:57768] by server-2.bemta-4.messagelabs.com id
	B2/5F-17550-A9AA69F4; Tue, 24 Apr 2012 13:28:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335274137!15281499!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14933 invoked from network); 24 Apr 2012 13:28:57 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 13:28:57 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id E18C7604079;
	Tue, 24 Apr 2012 06:28:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=X6x/wVWAf4vomuoZ5dY9grgR6yOZNSXU6RfufUeYVw4T
	qt+3Qu/YOqHYfgstDBzfAymC2zMFDTg4+U4LLd+HipQoaaSCkJr+377pPbJOW8if
	gMqKVx1M9SNFwAaQ8sqjHh4C2QbgoXTqhTdYlnrxMFf4ZOEdhUGSJCrG5EePehk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=dw0gZH2QDml2H6SogNAK/OFKIcE=; b=cWCj2+01
	hPWajAx0etrpv9zdPwI9TafWCK0Ezf7FoGaUy5G+RWa+qywJWYBE/ayWcFJORzdG
	bDzc0HameRXu6zdud4VWbX0WxY4ciNDTdczWk71+0/e4U8rIhTHKaahufHJuM3f3
	VwIXq7iKUZhYdswcwWyMZdpK8lS2IVIKwmA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 5BACE604078; 
	Tue, 24 Apr 2012 06:28:56 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 06:28:56 -0700
Message-ID: <37a26e60a3ba063166129c8b7e4ca93f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120424091549.GA34721@ocelot.phlegethon.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<c35696b09a3d055f365b8acd3b2ad1a2.squirrel@webmail.lagarcavilla.org>
	<20120424091549.GA34721@ocelot.phlegethon.org>
Date: Tue, 24 Apr 2012 06:28:56 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 08:26 -0700 on 23 Apr (1335169568), Andres Lagar-Cavilla wrote:
>> > At 07:36 +0000 on 23 Apr (1335166577), Zhang, Yang Z wrote:
>> >> The p2m lock in __get_gfn_type_access() is the culprit. Here is the
>> >> profiling data with 10 seconds:
>> >>
>> >> (XEN) p2m_lock 1 lock:
>> >> (XEN)   lock:      190733(00000000:14CE5726), block:
>> >> 67159(00000007:6AAA53F3)
>> >>
>> >> Those data is collected when win8 guest(16 vcpus) is idle. 16 VCPUs
>> >> blocked 30 seconds with 10 sec's profiling. It means 18% of cpu cycle
>> >> is waiting for the p2m lock. And those data only for idle guest. The
>> >> impaction is more seriously when run some workload inside guest.  I
>> >> noticed that this change was adding by cs 24770. And before it, we
>> >> don't require the p2m lock in _get_gfn_type_access. So is this lock
>> >> really necessary?
>> >
>> > Ugh; that certainly is a regression.  We used to be lock-free on p2m
>> > lookups and losing that will be bad for perf in lots of ways.  IIRC
>> the
>> > original aim was to use fine-grained per-page locks for this -- there
>> > should be no need to hold a per-domain lock during a normal read.
>> > Andres, what happened to that code?
>>
>> The fine-grained p2m locking code is stashed somewhere and untested.
>> Obviously not meant for 4.2. I don't think it'll be useful here: all
>> vcpus
>> are hitting the same gfn for the hpet mmio address.
>
> We'll have to do _something_ for 4.2 if it's introducing an 18% CPU
> overhead in an otherwise idle VM.

An hpet mmio read or write hits get_gfn twice: one for gfn zero at the
beginning of hvmemul_do_io, the other during hvm copy. The patch I sent to
Yang yesterday removes the bogus first get_gfn. The second one has to
perform a locked query.

Yang, is there any possibility to get more information here? The ability
to identify the call site that contends for the p2m lock would be crucial.
Even something as crude as sampling vcpu stack traces by hitting 'd'
repeatedly on the serial line, and seeing what sticks out frequently.

>
> In any case I think this means I probably shouldn't take the patch that
> turns on this locking for shadow VMs.  They do a lot more p2m lookups.
>
>> The other source of contention might come from hvmemul_rep_movs, which
>> holds the p2m lock for the duration of the mmio operation. I can
>> optimize
>> that one using the get_gfn/get_page/put_gfn pattern mentioned above.
>
> But wouldn't that be unsafe?  What if the p2m changes during the
> operation?  Or, conversely, could you replace all uses of the lock in
> p2m lookups with get_page() on the result and still get what you need?

I've been thinking of wrapping the pattern into a handy p2m accessor. I
see this pattern repeating itself for hvm_copy, tss/segment entry, page
table walking, nested hvm, etc, in which the consumer wants to map the
result of the translation. By the time you finish with a get_gfn_unshare,
most possible p2m transformations will have been taken care of (PoD-alloc,
page in, unshare). By taking a reference to the underlying page, paging
out is prevented, and then the vcpu can safely let go of the p2m lock.

Conceivably guest_physmap_remove_page and guest_physmap_add_entry can
still come in and change the p2m entry.

Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfpD-0008OI-5k; Tue, 24 Apr 2012 13:30:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfpC-0008O6-L7
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:30:34 +0000
Received: from [85.158.143.35:34441] by server-2.bemta-4.messagelabs.com id
	ED/02-17550-AFAA69F4; Tue, 24 Apr 2012 13:30:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335274226!6384504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2772 invoked from network); 24 Apr 2012 13:30:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:30:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:30:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:30:25 +0100
Message-ID: <1335274224.4347.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:30:24 +0100
In-Reply-To: <20374.42987.732159.638716@mariner.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: prevent xl from running if xend is running."):
> > Prevent xl from doing any operation if xend daemon is running. That prevents
> > bugs that happened when xl and xend raced to close a domain.
> 
> Can we somehow limit this to commands that actually change things ?
> Having xl as a diagnostic tool even for xend-based systems is useful.

Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).

> > +        if (!access(locks[i], F_OK) && !force_execution) {
> > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > +                            "correctly. If you still want to force the "
> > +                            "execution of xl please use the -f option\n");
> > +            exit(2);
> > +        }
> 
> If access fails with an unexpected error code (EACCES? EIO?) this will
> blunder on.

It'll fail whether the error code is expected or not, won't it?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfpD-0008OI-5k; Tue, 24 Apr 2012 13:30:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMfpC-0008O6-L7
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:30:34 +0000
Received: from [85.158.143.35:34441] by server-2.bemta-4.messagelabs.com id
	ED/02-17550-AFAA69F4; Tue, 24 Apr 2012 13:30:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335274226!6384504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2772 invoked from network); 24 Apr 2012 13:30:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:30:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:30:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:30:25 +0100
Message-ID: <1335274224.4347.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:30:24 +0100
In-Reply-To: <20374.42987.732159.638716@mariner.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: prevent xl from running if xend is running."):
> > Prevent xl from doing any operation if xend daemon is running. That prevents
> > bugs that happened when xl and xend raced to close a domain.
> 
> Can we somehow limit this to commands that actually change things ?
> Having xl as a diagnostic tool even for xend-based systems is useful.

Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).

> > +        if (!access(locks[i], F_OK) && !force_execution) {
> > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > +                            "correctly. If you still want to force the "
> > +                            "execution of xl please use the -f option\n");
> > +            exit(2);
> > +        }
> 
> If access fails with an unexpected error code (EACCES? EIO?) this will
> blunder on.

It'll fail whether the error code is expected or not, won't it?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfpX-0008RR-Jj; Tue, 24 Apr 2012 13:30:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1SMfpW-0008R8-5U
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:30:54 +0000
Received: from [193.109.254.147:61995] by server-5.bemta-14.messagelabs.com id
	78/5F-30733-D0BA69F4; Tue, 24 Apr 2012 13:30:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335274251!399850!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12878 invoked from network); 24 Apr 2012 13:30:52 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Apr 2012 13:30:52 -0000
Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:53198
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1SMfkn-0004sS-Cd; Tue, 24 Apr 2012 15:26:01 +0200
Date: Tue, 24 Apr 2012 15:30:49 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <442643696.20120424153049@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
References: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8gSWFuLAoKVHVlc2RheSwgQXByaWwgMjQsIDIwMTIsIDI6NTM6MzEgUE0sIHlvdSB3cm90
ZToKCj4gUGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKPiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAzL21zZzAwNzkzLmh0bWwKCj4gVGhlIHRpbWUgbGlu
ZSBpcyBhcyBmb2xsb3dzOgoKPiAxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBk
b3duCj4gMiBBcHJpbCAgICAgICAgIC0tIEZlYXR1cmUgRnJlZXplCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKPiBNaWQvTGF0
ZSBBcHJpbCAgLS0gRmlyc3QgcmVsZWFzZSBjYW5kaWRhdGUgICAgICA8PCBTRUUgQkVMT1cKPiBX
ZWVrbHkgICAgICAgICAgLS0gUkNOKzEgdW50aWwgaXQgaXMgcmVhZHkKCj4gTXkgaW5pdGlhbCBn
dWVzc3RpbWF0ZSBmb3Igc3RhcnRpbmcgUkNzIGFwcGVhcnMgdG8gaGF2ZSBiZWVuIHNvbWV3aGF0
Cj4gb3B0aW1pc3RpYy4gSSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgcmVkdWNlZCBhdCBsZWFzdCB0
aGUgYmxvY2tlcnMgbGlzdHMKPiByYXRoZXIgc2lnbmlmaWNhbnRseSBiZWZvcmUgd2Ugc3RhcnQg
dGhpbmtpbmcgb2YgZG9pbmcgUkNzLgoKSXMgdGhlcmUgYW55IGxpc3Qvb3ZlcnZpZXcgYXMgdG8g
dGhlIHN0YXRlIG9mIGZlYXR1cmUgcGFyaXR5IGJldHdlZW4geG0veGVuZCBhbmQgeGwvbGlieGwg
PwooYm90aCBpbiB0aGUgc2Vuc2Ugb2YgY29tbWFuZHMgdG8geGwsIGFzIG9mIHBhcnNpbmcgYW5k
IGJ1aWxkaW5nIGEgZG9tYWluIGZyb20gdGhlIG9wdGlvbnMgc3BlY2lmaWVkIGluIGEgZG9tYWlu
IC5jZmcpCgpUaGlzIHdlZWsgaSBub3RpY2VkIHRoYXQgc29tZW9uZSBlbHNlIG5vdGljZWQgdGhh
dCBjcHVfd2VpZ2h0ICYgY28gLmNmZyBvcHRpb25zIHdoZXJlIG1pc3Npbmcgc3VwcG9ydCBhbmQg
cHJvdmlkZWQgcGF0Y2hlcywgYnV0IHRoZXNlIHNlZW0gbGlrZSBwcmV0dHkgYmFzaWMgY29uZmln
IG9wdGlvbnMuClRoaXMgcmFpc2VzIHRoZSBxdWVzdGlvbiBpZiB0aGVyZSBhcmUgbW9yZSBwcmV0
dHkgYmFzaWMgb3B0aW9ucyBzdGlsbCBtaXNzaW5nIGFuZCBpbiB3aGF0IHdheSB3aWxsIHRoZXkg
YmUgaGFuZGxlZCBkdXJpbmcgdGhlIFJDJ3MgPwooc2luY2UgdGhlcmUgaXMgYSBnb29kIGNoYW5j
ZSBtb3JlIHdpbGwgcG9wIHVwIHdoZW4gbW9yZSB1c2VycyBzdGFydCB0ZXN0aW5nKQoKQXJlIHBh
dGNoZXMgZm9yIG5vdCB0byBleG90aWMgYW5kL29yIGludmFzaXZlIG9wdGlvbnMgc3RpbGwgYWNj
ZXB0YWJsZSA/Ck9yIHdpbGwgdGhleSBoYXZlIHRvIHdhaXQgZm9yIGEgNC4yLjEgd2hpY2ggY291
bGQgZm9sbG93IHVwIHByZXR0eSBzaG9ydCB0aGVuID8KCihwcm9iYWJseSBoYXJkIHRvIGdpdmUg
YSBoYXJkIHJ1bGUgb2YgdGh1bWIsIGJ1dCBwZXJoYXBzIHNvbWV0aGluZyB0byBkbyBhIGxpdHRs
ZSB0aGlua2luZyBhYm91dCB3aGF0IGNvdWxkIGhhcHBlbikKCgoKPiBBIGZhaXJseSBsYXJnZSBw
cm9wb3J0aW9uIG9mIHRoZSBsaXN0IGhhcyBiZWVuIHBvc3RlZCBhdCBsZWFzdCBvbmNlLCBhbmQK
PiBtdWNoIG9mIGl0IHNlZW1zIHJlYWR5IChvciBhbG1vc3QgcmVhZHkpIHRvIGdvIGluLiBUaGVy
ZSBhcmUgaG93ZXZlcgo+IHN0aWxsIHNvbWUgc21hbGxlciBpdGVtcyB3aGljaCBhcmUgdW5jbGFp
bWVkLiBCYXNlZCBvbiBmZWVkYmFjayBmcm9tCj4gdGhvc2Ugd2hvIGFyZSB3b3JraW5nIG9uIHRo
ZSBiaWdnZXIgb3V0c3RhbmRpbmcgaXRlbXMgaXQgc2VlbXMgbGlrZSBtb3N0Cj4gb2YgdGhlbSBv
dWdodCB0byBiZSByZWFkeSB0byBsYW5kIGluIHRoZSBuZXh0IGZldyB3ZWVrcy4KCj4gT24gdGhh
dCBiYXNpcyBJIHRoaW5rIGRvaW5nIGEgZmlyc3QgcmVsZWFzZSBjYW5kaWRhdGUgaW4gTWlkL0xh
dGUgTWF5IGlzCj4gbW9yZSByZWFsaXN0aWMuIEknbGwgcmVmbGVjdCB0aGF0IGluIG5leHQgd2Vl
a3MgdXBkYXRlCgo+IFRoZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLiBQZXIgdGhlIHJlbGVh
c2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwKPiBub3cgaGF2ZSB0byBiZSBtYWRlIGFzIHRvIHdo
eSBuZXcgaXRlbXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0LAo+IGVzcGVjaWFsbHkgYXMg
YSBibG9ja2VyLCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgo+IGh5cGVydmlzb3IsIGJs
b2NrZXJzOgo+ICAgICAgICogW0JVR10gWm9tYmllIGRyaXZlciBkb21haW5zLiAgVGhlcmUncyBh
IGJ1ZyB3aGVyZSBQViBndWVzdHMgd2l0aAo+ICAgICAgICAgZGV2aWNlcyBwYXNzZWQgdGhyb3Vn
aCB3aXRoIHhsIGhhbmcgYXJvdW5kIGFzICJ6b21iaWVzIiwgd2l0aAo+ICAgICAgICAgb25lIG91
dHN0YW5kaW5nIHBhZ2UgcmVmZXJlbmNlLiAgSSB0aGluayB0aGlzIHNob3VsZCByZWFsbHkgYmUg
YQo+ICAgICAgICAgYmxvY2tlci4gSSdtIHdvcmtpbmcgb24gdGhpcyBhdCB0aGUgbW9tZW50IChH
ZW9yZ2UgRHVubGFwKS4KPiAgICAgICAgICAgICAgICogT25lIG9mIHNldmVyYWwgcmVjZW50IHJl
cG9ydHMgb2YgWm9tYmllIGRvbWFpbnMsIHdoaWNoCj4gICAgICAgICAgICAgICAgIG1heSBvciBt
YXkgbm90IGJlIGFsbCByZWxhdGVkLgo+ICAgICAgICAgICAgICAgKiBMaXN0IGFzIGh5cGVydmlz
b3IgZm9yIG5vdywgYnV0IG1heSB0dXJuIG91dCB0byBiZSBhCj4gICAgICAgICAgICAgICAgIHRv
b2xzIGlzc3VlLgo+ICAgICAgICAgRml4ZWQgKERPTkUsIFRpbSBEZWVnYW4pCj4gICAgICAgKiBQ
ZXJmb3JtYW5jZSByZWdyZXNzaW9uIGR1ZSB0byBjb250ZW50aW9uIG9uIHAybSBsb2NrLiAoVGlt
LAo+ICAgICAgICAgQW5kcmVzKQo+ICAKPiB0b29scywgYmxvY2tlcnM6Cj4gICAgICAgKiBsaWJ4
bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkK
PiAgICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBub3QgY2hh
bmdpbmcuIEFzcGVjdHMgb2YKPiAgICAgICAgIHRoaXMgYXJlOgo+ICAgICAgICAgICAgICAgKiBT
YWZlIGZvcmsgdnMuIGZkIGhhbmRsaW5nIGhvb2tzLiBJbnZvbHZlcyBBUEkgY2hhbmdlcwo+ICAg
ICAgICAgICAgICAgICAoSWFuIEosIHBhdGNoZXMgcG9zdGVkKQo+ICAgICAgICAgICAgICAgKiBs
aWJ4bF93YWl0X2Zvcl9mcmVlX21lbW9yeS9saWJ4bF93YWl0X2Zvcl9tZW1vcnlfdGFyZ2V0Lgo+
ICAgICAgICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8K
PiAgICAgICAgICAgICAgICAgbG9ja2luZy9zZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0
ZSAoZGVmZXJyZWQgdG8KPiAgICAgICAgICAgICAgICAgNC4zKS4gSWFuSiB0byBhZGQgbm90ZSBh
Ym91dCB0aGlzIGludGVyZmFjZSBiZWluZwo+ICAgICAgICAgICAgICAgICBzdWJzdGFuZGFyZCBi
dXQgb3RoZXJ3aXNlIGRlZmVyIHRvIDQuMy4KPiAgICAgICAgICAgICAgICogbGlieGxfe0ZPT31f
ZXhlYy4gU2hvdWxkIHJldHVybiBhIGRhdGEgc3RydWN0dXJlCj4gICAgICAgICAgICAgICAgIGRl
Y2xhcmluZyB3aGF0IHRvIGRvLCBub3QgZm9yayBhbmQgZXhlYyB0aGVtc2VsdmVzLgo+ICAgICAg
ICAgICAgICAgICBIb3dldmVyIHdlIGNhbiBkZWZlciB0aGlzIHVudGlsIDQuMyAodGhlcmVmb3Jl
IERPTkUgd2l0aAo+ICAgICAgICAgICAgICAgICBubyB3b3JrKS4KPiAgICAgICAgICAgICAgICog
bGlieGxfKl9wYXRoLiBNYWpvcml0eSBtYWRlIGludGVybmFsLCBvbmx5IGNvbmZpZ2RpciBhbmQK
PiAgICAgICAgICAgICAgICAgbG9ja2RpciByZW1haW4gcHVibGljICh1c2VkIGJ5IHhsKS4gR29v
ZCBlbm91Z2g/Cj4gICAgICAgICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5lZWQgdG8g
YmUgYXN5bmM6Cj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZG9tYWluX3N1c3BlbmQu
IFByb2JhYmx5IG5lZWQgdG8gbW92ZQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHhjX2RvbWFp
bl9zYXZlIGludG8gYSBzZXBhcmF0ZSBwcm9jZXNzLCBhcyBwZXIKPiAgICAgICAgICAgICAgICAg
ICAgICAgICA8MjAzNjYuNDAxODMuNDEwMzg4LjQ0NzYzMEBtYXJpbmVyLnVrLnhlbnNvdXJjZS5j
b20+LiBMaWtlbHkgbmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgeGNfZG9tYWluX3Jlc3RvcmUgdG9v
LiBJJ20gbm90IHN1cmUgaWYgSWFuSiBpcyB3b3JraW5nIChvciBwbGFubmluZyB0byB3b3JrIG9u
KSB0aGlzLgo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9jcmVhdGVfe25l
dyxyZXN0b3JlfSAtLSBJYW5KIGhhcwo+ICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGNoZXMg
YXMgcGFydCBvZiBldmVudCBzZXJpZXMuCj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxf
ZG9tYWluX2NvcmVfZHVtcC4gQ2FuIHRha2UgYSBkdW1teSBhb19ob3cKPiAgICAgICAgICAgICAg
ICAgICAgICAgICBhbmQgcmVtYWluIHN5bmNocm9ub3VzIGludGVybmFsbHkuIChJYW5DLCBwYXRj
aAo+ICAgICAgICAgICAgICAgICAgICAgICAgIHBvc3RlZCkKPiAgICAgICAgICAgICAgICAgICAg
ICAgKiBsaWJ4bF9kZXZpY2Vfe2Rpc2ssbmljLHZrYixhZGR9X2FkZCAoYW5kCj4gICAgICAgICAg
ICAgICAgICAgICAgICAgcmVtb3ZlPykuIFJvZ2VyIFBhdSBNb25uw6kgZml4ZXMgZGlzayBhcyBw
YXJ0IG9mCj4gICAgICAgICAgICAgICAgICAgICAgICAgaG90cGx1ZyBzY3JpcHQgc2VyaWVzIGFu
ZCBhZGRzIGluZnJhc3RydWN0dXJlCj4gICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggc2hv
dWxkIG1ha2UgdGhlIG90aGVycyB0cml2aWFsLiAoUm9nZXIKPiAgICAgICAgICAgICAgICAgICAg
ICAgICBpbnZlc3RpZ2F0aW5nKQo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2Nkcm9t
X2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGRp
c2tfe2FkZCxyZW1vdmV9IGRvbmUsIElhbkogdG8gbG9vayBhdCAob3IKPiAgICAgICAgICAgICAg
ICAgICAgICAgICBkb2luZyBzbz8pLgo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2Rl
dmljZV9kaXNrX2xvY2FsX3thdHRhY2gsZGV0YWNofS4gQmVjb21lCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgaW50ZXJuYWwgYXMgcGFydCBvZiBTdGVmYW5vJ3MgZG9tYWluIDAgZGlzawo+ICAg
ICAgICAgICAgICAgICAgICAgICAgIGF0dGFjaCBzZXJpZXMgKHBhdGNoZXMgcG9zdGVkKQo+ICAg
ICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV9wY2lfe2FkZCxyZW1vdmV9LiBSb2dl
cgo+ICAgICAgICAgICAgICAgICAgICAgICAgIGludmVzdGlnYXRpbmcgYWxvbmcgd2l0aCBvdGhl
ciBhZGQscmVtb3ZlCj4gICAgICAgICAgICAgICAgICAgICAgICAgZnVuY3Rpb25zLgo+ICAgICAg
ICAgICAgICAgICAgICAgICAqIGxpYnhsX3hlbl90bWVtXyouIEFsbCBmdW5jdGlvbnMgYXJlICJm
YXN0IiBhbmQKPiAgICAgICAgICAgICAgICAgICAgICAgICB0aGVyZWZvcmUgbm8gYXN5bmMgbmVl
ZGVkLiBFeGNlcHRpb24gaXMKPiAgICAgICAgICAgICAgICAgICAgICAgICB0bWVtX2Rlc3Ryb3kg
d2hpY2ggRGFuIE1hZ2VuaGVpbWVyIHNheXMgaXMKPiAgICAgICAgICAgICAgICAgICAgICAgICBv
YnNvbGV0ZSBhbmQgY2FuIGp1c3QgYmUgcmVtb3ZlZC4gKElhbiBDLCBwYXRjaAo+ICAgICAgICAg
ICAgICAgICAgICAgICAgIHBvc3RlZCB0byByZW1vdmUgdG1lbV9kZXN0cm95KQo+ICAgICAgICAg
ICAgICAgICAgICAgICAqIGxpYnhsX2ZvcmsgLS0gSWFuSidzIGV2ZW50IHNlcmllcyB3aWxsIHJl
bW92ZQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGFsbCB1c2VycyBvZiB0aGlzLgo+ICAgICAg
ICogW0JVR10gTWFudWFsbHkgYmFsbG9vbmluZyBkb20wLiAgeGwgbWVtLXNldCAwIFtmb29dIGZh
aWxzIHdpdGgKPiAgICAgICAgICJsaWJ4bDogZXJyb3I6IGxpYnhsLmM6MjU2OTpsaWJ4bF9zZXRf
bWVtb3J5X3RhcmdldDogY2Fubm90IGdldAo+ICAgICAgICAgbWVtb3J5IGluZm8gZnJvbSAvbG9j
YWwvZG9tYWluLzAvbWVtb3J5L3N0YXRpYy1tYXg6IE5vIHN1Y2ggZmlsZQo+ICAgICAgICAgb3Ig
ZGlyZWN0b3J5Ii4gVGhpcyBtaWdodCBiZSBzdWl0YWJsZSBmb3IgYW4gZW50aHVzaWFzdGljCj4g
ICAgICAgICBvbi1sb29rZXIuIChHZW9yZ2UgRHVubGFwLCBpbiB0aGUgYWJzZW5jZSBvZiBzYWlk
IG9ubG9va2VyKQo+ICAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgo+ICAgICAgICAg
ICAgICAgKiBbQlVHXSBjYW5ub3QgY3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZXIgb24gSFZN
IGd1ZXN0LAo+ICAgICAgICAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGluCj4g
ICAgICAgICAgICAgICAgIDw0Rjk2NzJERC4yMDgwOTAyQHRpc2NhbGkuaXQ+Cj4gICAgICAgICAg
ICAgICAqIFtCVUddIGRvZXMgbm90IGhvbm91ciBzY2hlZHVsZXIgd2VpZ2h0IHBhcmFtcywgcmVw
b3J0ZWQKPiAgICAgICAgICAgICAgICAgYnkgRGlldGVyIEJsb21zIGluIDwyMDEyMDQyMzE5MzUx
OC5HQTE2MTM0QGJsb21zLmRlPiwKPiAgICAgICAgICAgICAgICAgRGlldGVyIGhhcyBwb3N0ZWQg
YSBwYXRjaC4KPiAgICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBh
Z2UgcGF0Y2hlcyBhbHJlYWR5IGluCj4gICAgICAgICB0cmVlLiBOZWVkcyByZWxlYXNlIG5vdGlu
ZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQgLXJjMSB0bwo+ICAgICAgICAgcmVtaW5kIHBlb3Bs
ZSB0byB0ZXN0IHhsLgo+ICAgICAgICAgICAgICAgKiB4bCB0byByZWZ1c2UgdG8gcnVuIGlmIHhl
bmQgaXMgcnVubmlnLCBSb2dlciBQYXUgTW9ubsOpCj4gICAgICAgICAgICAgICAgIChwYXRjaCBw
b3N0ZWQpCj4gICAgICAgKiBEb21haW4gMCBibG9jayBhdHRhY2ggJiBnZW5lcmFsIGhvdHBsdWcg
d2hlbiB1c2luZyBxZGlzayBiYWNrZW5kCj4gICAgICAgICAobmVlZCB0byBzdGFydCBxZW11IGFz
IG5lY2Vzc2FyeSBldGMpIChTdGVmYW5vIFMsIHBhdGNoZXMKPiAgICAgICAgIHBvc3RlZCkKPiAg
ICAgICAqIGZpbGU6Ly8gYmFja2VuZCBwZXJmb3JtYW5jZS4KPiAgICAgICAgICAgICAgICogcWVt
dS14ZW4tdHJhZGl0aW9uYWwgYW5kIHVwc3RyZWFtIHFlbXUteGVuIHBlcmZvcm1hbmNlCj4gICAg
ICAgICAgICAgICAgIGhhcyBiZWVuIGltcHJvdmVkIGFuZCBpcyBub3cgc2F0aXNmYWN0b3J5Lgo+
ICAgICAgICAgICAgICAgKiBYZW4gNC4yIHdpbGwgcHJlZmVyIGJsa3RhcDIgaWYgYSBrZXJuZWwg
bW9kdWxlIGlzCj4gICAgICAgICAgICAgICAgIGF2YWlsYWJsZSAoZS5nLiBvbGRlciBkb20wIGtl
cm5lbCBvciBES01TIHByb3ZpZGVkCj4gICAgICAgICAgICAgICAgIGtlcm5lbCBtb2R1bGUpIGFu
ZCB3aWxsIGZhbGxiYWNrIHRvIHFlbXUgcWRpc2sgaWYgbm8KPiAgICAgICAgICAgICAgICAgYmxr
dGFwMiBpcyBhdmFpbGFibGUuCj4gICAgICAgICAgICAgICAqIFRoZXJlIHdpbGwgYmUgbm8gdXNl
cnNwYWNlICJibGt0YXAzIiBmb3IgWGVuIDQuMgo+ICAgICAgICogSW1wcm92ZWQgSG90cGx1ZyBz
Y3JpcHQgc3VwcG9ydCAoUm9nZXIgUGF1IE1vbm7DqSwgcGF0Y2hlcwo+ICAgICAgICAgcG9zdGVk
KQo+ICAgICAgICogQmxvY2sgc2NyaXB0IHN1cHBvcnQgLS0gZm9sbG93cyBvbiBmcm9tIGhvdHBs
dWcgc2NyaXB0IChSb2dlcgo+ICAgICAgICAgUGF1IE1vbm7DqSkKCj4gaHlwZXJ2aXNvciwgbmlj
ZSB0byBoYXZlOgo+ICAgICAgICogc29saWQgaW1wbGVtZW50YXRpb24gb2Ygc2hhcmluZy9wYWdp
bmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawo+ICAgICAgICAgcXVldWVzKSAoVGltIERlZWdhbiwg
T2xhZiBIZXJyaW5nIGV0IGFsIC0tIHBhdGNoZXMgcG9zdGVkKQo+ICAgICAgICAgICAgICAgKiAi
VGhlIGxhc3QgcGF0Y2ggdG8gdXNlIGEgd2FpdHF1ZXVlIGluCj4gICAgICAgICAgICAgICAgIF9f
Z2V0X2dmbl90eXBlX2FjY2VzcygpIGZyb20gVGltIHdvcmtzLiAgSG93ZXZlciwgdGhlcmUKPiAg
ICAgICAgICAgICAgICAgYXJlIGEgZmV3IHVzZXJzIHdobyBjYWxsIF9fZ2V0X2dmbl90eXBlX2Fj
Y2VzcyB3aXRoIHRoZQo+ICAgICAgICAgICAgICAgICBkb21haW5fbG9jayBoZWxkLiBUaGlzIHBh
cnQgbmVlZHMgdG8gYmUgYWRkcmVzc2VkIGluCj4gICAgICAgICAgICAgICAgIHNvbWUgd2F5LiIK
PiAgICAgICAgICAgICAgICogRGVmZXJyZWQgdW50aWwgNC4zCj4gICAgICAgKiBTaGFyaW5nIHN1
cHBvcnQgZm9yIEFNRCAoVGltLCBBbmRyZXMpLCBpbiwgbWFya2VkIGFzCj4gICAgICAgICBleHBl
cmltZW50YWwgKHNvLCBET05FLCBhcyBmYXIgYXMgNC4yIGlzIGNvbmNlcm5lZCkuCj4gICAgICAg
KiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwKQoKPiB0b29scywg
bmljZSB0byBoYXZlOgo+ICAgICAgICogQ29uZmlndXJlL2NvbnRyb2wgcGFnaW5nIHZpYSB4bC9s
aWJ4bCAoT2xhZiBIZXJyaW5nLCBsb3RzIG9mCj4gICAgICAgICBkaXNjdXNzaW9uIGFyb3VuZCBp
bnRlcmZhY2UsIGdlbmVyYWwgY29uc2Vuc3VzIHJlYWNoZWQgb24gd2hhdAo+ICAgICAgICAgaXQg
c2hvdWxkIGxvb2sgbGlrZS4gT2xhZiBoYXMgbGV0IG1lIGtub3cgdGhhdCBoZSBpcyBwcm9iYWJs
eQo+ICAgICAgICAgbm90IGdvaW5nIHRvIGhhdmUgdGltZSB0byBkbyB0aGlzIGZvciA0LjIsIHdp
bGwgbGlrZWx5IHNsaXAgdG8KPiAgICAgICAgIDQuMyB1bmxlc3Mgc29tZW9uZSBlbHNlIHdhbnQg
dG8gcGljayB1cCB0aGF0IHdvcmspCj4gICAgICAgICAgICAgICAqIFdpbGwgZGVmZXIgdW50aWwg
NC4zLgo+ICAgICAgICogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gICAgICAgICAg
ICAgICAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVy
YXJkLAo+ICAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCj4gICAgICAgICAgICAgICAqIFVw
c3RyZWFtIHFlbXUgc2F2ZSByZXN0b3JlIChBbnRob255IFBlcmFyZCwgU3RlZmFubwo+ICAgICAg
ICAgICAgICAgICBTdGFiZWxsaW5pLCBxZW11IHBhdGNoZXMgYXBwbGllZCwgd2FpdGluZyBmb3Ig
bGlieGwgZXRjCj4gICAgICAgICAgICAgICAgIHNpZGUgd2hpY2ggaGFzIGJlZW4gcmVjZW50bHkg
cmVwb3N0ZWQpCj4gICAgICAgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24uIEN1cnJlbnRseSAiZXhw
ZXJpbWVudGFsIi4gTGlrZWx5IHRvCj4gICAgICAgICByZWxlYXNlIHRoYXQgd2F5Lgo+ICAgICAg
ICAgICAgICAgKiBOZXN0ZWQgU1ZNLiBUZXN0ZWQgaW4gYSB2YXJpZXR5IG9mIGNvbmZpZ3VyYXRp
b25zIGJ1dAo+ICAgICAgICAgICAgICAgICBzdGlsbCBzb21lIGlzc3VlcyB3aXRoIHRoZSBtb3N0
IGltcG9ydGFudCB1c2UgY2FzZSAodzcKPiAgICAgICAgICAgICAgICAgWFAgbW9kZSkgWzBdICAo
Q2hyaXN0b3BoIEVnZ2VyKQo+ICAgICAgICAgICAgICAgKiBOZXN0ZWQgVk1YLiBOZWVkcyBuZXN0
ZWQgRVBUIHRvIGJlIGdlbnVpbmVseSB1c2VmdWwuCj4gICAgICAgICAgICAgICAgIE5lZWQgbW9y
ZSBkYXRhIG9uIHRlc3RlZG5lc3MgZXRjIChJbnRlbCkKPiAgICAgICAgIERPTkUsIGF0IGxlYXN0
IGFzIGZhciBhcyA0LjIgaXMgY29uY2VybmVkLgo+ICAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0
IGZvciBSZW11cyAobWVtb3J5IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQo+ICAgICAgICAgKFNo
cmlyYW0sIHdhaXRpbmcgb24gbGlieGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9y
ZSkKPiAgICAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPiAgICAgICAgICAgICAgICog
eGwgc3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKPiAg
ICAgICAgICAgICAgICAgb3RoZXJ3aXNlKSAoR29uY2FsbyBHb21lcywgd2FpdGluZyBvbiBuZXcg
dmVyc2lvbiBvZgo+ICAgICAgICAgICAgICAgICBwYXRjaGVzKQo+ICAgICAgICAgICAgICAgKiBz
dXBwb3J0IGZvciB2aWYgInJhdGUiIHBhcmFtZXRlciAoTWF0aGlldSBHYWduw6ksIGZpcnN0Cj4g
ICAgICAgICAgICAgICAgIHBhcnQgYXBwbGllZCkKCj4gWzBdIGh0dHA6Ly9saXN0cy54ZW4ub3Jn
L2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMvbXNnMDA4ODMuaHRtbAoKCgoKCgotLSAK
QmVzdCByZWdhcmRzLAogU2FuZGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1haWx0bzps
aW51eEBlaWtlbGVuYm9vbS5pdAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfpX-0008RR-Jj; Tue, 24 Apr 2012 13:30:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1SMfpW-0008R8-5U
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:30:54 +0000
Received: from [193.109.254.147:61995] by server-5.bemta-14.messagelabs.com id
	78/5F-30733-D0BA69F4; Tue, 24 Apr 2012 13:30:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335274251!399850!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12878 invoked from network); 24 Apr 2012 13:30:52 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Apr 2012 13:30:52 -0000
Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:53198
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1SMfkn-0004sS-Cd; Tue, 24 Apr 2012 15:26:01 +0200
Date: Tue, 24 Apr 2012 15:30:49 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <442643696.20120424153049@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
References: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8gSWFuLAoKVHVlc2RheSwgQXByaWwgMjQsIDIwMTIsIDI6NTM6MzEgUE0sIHlvdSB3cm90
ZToKCj4gUGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKPiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAzL21zZzAwNzkzLmh0bWwKCj4gVGhlIHRpbWUgbGlu
ZSBpcyBhcyBmb2xsb3dzOgoKPiAxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBk
b3duCj4gMiBBcHJpbCAgICAgICAgIC0tIEZlYXR1cmUgRnJlZXplCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKPiBNaWQvTGF0
ZSBBcHJpbCAgLS0gRmlyc3QgcmVsZWFzZSBjYW5kaWRhdGUgICAgICA8PCBTRUUgQkVMT1cKPiBX
ZWVrbHkgICAgICAgICAgLS0gUkNOKzEgdW50aWwgaXQgaXMgcmVhZHkKCj4gTXkgaW5pdGlhbCBn
dWVzc3RpbWF0ZSBmb3Igc3RhcnRpbmcgUkNzIGFwcGVhcnMgdG8gaGF2ZSBiZWVuIHNvbWV3aGF0
Cj4gb3B0aW1pc3RpYy4gSSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgcmVkdWNlZCBhdCBsZWFzdCB0
aGUgYmxvY2tlcnMgbGlzdHMKPiByYXRoZXIgc2lnbmlmaWNhbnRseSBiZWZvcmUgd2Ugc3RhcnQg
dGhpbmtpbmcgb2YgZG9pbmcgUkNzLgoKSXMgdGhlcmUgYW55IGxpc3Qvb3ZlcnZpZXcgYXMgdG8g
dGhlIHN0YXRlIG9mIGZlYXR1cmUgcGFyaXR5IGJldHdlZW4geG0veGVuZCBhbmQgeGwvbGlieGwg
PwooYm90aCBpbiB0aGUgc2Vuc2Ugb2YgY29tbWFuZHMgdG8geGwsIGFzIG9mIHBhcnNpbmcgYW5k
IGJ1aWxkaW5nIGEgZG9tYWluIGZyb20gdGhlIG9wdGlvbnMgc3BlY2lmaWVkIGluIGEgZG9tYWlu
IC5jZmcpCgpUaGlzIHdlZWsgaSBub3RpY2VkIHRoYXQgc29tZW9uZSBlbHNlIG5vdGljZWQgdGhh
dCBjcHVfd2VpZ2h0ICYgY28gLmNmZyBvcHRpb25zIHdoZXJlIG1pc3Npbmcgc3VwcG9ydCBhbmQg
cHJvdmlkZWQgcGF0Y2hlcywgYnV0IHRoZXNlIHNlZW0gbGlrZSBwcmV0dHkgYmFzaWMgY29uZmln
IG9wdGlvbnMuClRoaXMgcmFpc2VzIHRoZSBxdWVzdGlvbiBpZiB0aGVyZSBhcmUgbW9yZSBwcmV0
dHkgYmFzaWMgb3B0aW9ucyBzdGlsbCBtaXNzaW5nIGFuZCBpbiB3aGF0IHdheSB3aWxsIHRoZXkg
YmUgaGFuZGxlZCBkdXJpbmcgdGhlIFJDJ3MgPwooc2luY2UgdGhlcmUgaXMgYSBnb29kIGNoYW5j
ZSBtb3JlIHdpbGwgcG9wIHVwIHdoZW4gbW9yZSB1c2VycyBzdGFydCB0ZXN0aW5nKQoKQXJlIHBh
dGNoZXMgZm9yIG5vdCB0byBleG90aWMgYW5kL29yIGludmFzaXZlIG9wdGlvbnMgc3RpbGwgYWNj
ZXB0YWJsZSA/Ck9yIHdpbGwgdGhleSBoYXZlIHRvIHdhaXQgZm9yIGEgNC4yLjEgd2hpY2ggY291
bGQgZm9sbG93IHVwIHByZXR0eSBzaG9ydCB0aGVuID8KCihwcm9iYWJseSBoYXJkIHRvIGdpdmUg
YSBoYXJkIHJ1bGUgb2YgdGh1bWIsIGJ1dCBwZXJoYXBzIHNvbWV0aGluZyB0byBkbyBhIGxpdHRs
ZSB0aGlua2luZyBhYm91dCB3aGF0IGNvdWxkIGhhcHBlbikKCgoKPiBBIGZhaXJseSBsYXJnZSBw
cm9wb3J0aW9uIG9mIHRoZSBsaXN0IGhhcyBiZWVuIHBvc3RlZCBhdCBsZWFzdCBvbmNlLCBhbmQK
PiBtdWNoIG9mIGl0IHNlZW1zIHJlYWR5IChvciBhbG1vc3QgcmVhZHkpIHRvIGdvIGluLiBUaGVy
ZSBhcmUgaG93ZXZlcgo+IHN0aWxsIHNvbWUgc21hbGxlciBpdGVtcyB3aGljaCBhcmUgdW5jbGFp
bWVkLiBCYXNlZCBvbiBmZWVkYmFjayBmcm9tCj4gdGhvc2Ugd2hvIGFyZSB3b3JraW5nIG9uIHRo
ZSBiaWdnZXIgb3V0c3RhbmRpbmcgaXRlbXMgaXQgc2VlbXMgbGlrZSBtb3N0Cj4gb2YgdGhlbSBv
dWdodCB0byBiZSByZWFkeSB0byBsYW5kIGluIHRoZSBuZXh0IGZldyB3ZWVrcy4KCj4gT24gdGhh
dCBiYXNpcyBJIHRoaW5rIGRvaW5nIGEgZmlyc3QgcmVsZWFzZSBjYW5kaWRhdGUgaW4gTWlkL0xh
dGUgTWF5IGlzCj4gbW9yZSByZWFsaXN0aWMuIEknbGwgcmVmbGVjdCB0aGF0IGluIG5leHQgd2Vl
a3MgdXBkYXRlCgo+IFRoZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLiBQZXIgdGhlIHJlbGVh
c2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwKPiBub3cgaGF2ZSB0byBiZSBtYWRlIGFzIHRvIHdo
eSBuZXcgaXRlbXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0LAo+IGVzcGVjaWFsbHkgYXMg
YSBibG9ja2VyLCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgo+IGh5cGVydmlzb3IsIGJs
b2NrZXJzOgo+ICAgICAgICogW0JVR10gWm9tYmllIGRyaXZlciBkb21haW5zLiAgVGhlcmUncyBh
IGJ1ZyB3aGVyZSBQViBndWVzdHMgd2l0aAo+ICAgICAgICAgZGV2aWNlcyBwYXNzZWQgdGhyb3Vn
aCB3aXRoIHhsIGhhbmcgYXJvdW5kIGFzICJ6b21iaWVzIiwgd2l0aAo+ICAgICAgICAgb25lIG91
dHN0YW5kaW5nIHBhZ2UgcmVmZXJlbmNlLiAgSSB0aGluayB0aGlzIHNob3VsZCByZWFsbHkgYmUg
YQo+ICAgICAgICAgYmxvY2tlci4gSSdtIHdvcmtpbmcgb24gdGhpcyBhdCB0aGUgbW9tZW50IChH
ZW9yZ2UgRHVubGFwKS4KPiAgICAgICAgICAgICAgICogT25lIG9mIHNldmVyYWwgcmVjZW50IHJl
cG9ydHMgb2YgWm9tYmllIGRvbWFpbnMsIHdoaWNoCj4gICAgICAgICAgICAgICAgIG1heSBvciBt
YXkgbm90IGJlIGFsbCByZWxhdGVkLgo+ICAgICAgICAgICAgICAgKiBMaXN0IGFzIGh5cGVydmlz
b3IgZm9yIG5vdywgYnV0IG1heSB0dXJuIG91dCB0byBiZSBhCj4gICAgICAgICAgICAgICAgIHRv
b2xzIGlzc3VlLgo+ICAgICAgICAgRml4ZWQgKERPTkUsIFRpbSBEZWVnYW4pCj4gICAgICAgKiBQ
ZXJmb3JtYW5jZSByZWdyZXNzaW9uIGR1ZSB0byBjb250ZW50aW9uIG9uIHAybSBsb2NrLiAoVGlt
LAo+ICAgICAgICAgQW5kcmVzKQo+ICAKPiB0b29scywgYmxvY2tlcnM6Cj4gICAgICAgKiBsaWJ4
bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkK
PiAgICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBub3QgY2hh
bmdpbmcuIEFzcGVjdHMgb2YKPiAgICAgICAgIHRoaXMgYXJlOgo+ICAgICAgICAgICAgICAgKiBT
YWZlIGZvcmsgdnMuIGZkIGhhbmRsaW5nIGhvb2tzLiBJbnZvbHZlcyBBUEkgY2hhbmdlcwo+ICAg
ICAgICAgICAgICAgICAoSWFuIEosIHBhdGNoZXMgcG9zdGVkKQo+ICAgICAgICAgICAgICAgKiBs
aWJ4bF93YWl0X2Zvcl9mcmVlX21lbW9yeS9saWJ4bF93YWl0X2Zvcl9tZW1vcnlfdGFyZ2V0Lgo+
ICAgICAgICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8K
PiAgICAgICAgICAgICAgICAgbG9ja2luZy9zZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0
ZSAoZGVmZXJyZWQgdG8KPiAgICAgICAgICAgICAgICAgNC4zKS4gSWFuSiB0byBhZGQgbm90ZSBh
Ym91dCB0aGlzIGludGVyZmFjZSBiZWluZwo+ICAgICAgICAgICAgICAgICBzdWJzdGFuZGFyZCBi
dXQgb3RoZXJ3aXNlIGRlZmVyIHRvIDQuMy4KPiAgICAgICAgICAgICAgICogbGlieGxfe0ZPT31f
ZXhlYy4gU2hvdWxkIHJldHVybiBhIGRhdGEgc3RydWN0dXJlCj4gICAgICAgICAgICAgICAgIGRl
Y2xhcmluZyB3aGF0IHRvIGRvLCBub3QgZm9yayBhbmQgZXhlYyB0aGVtc2VsdmVzLgo+ICAgICAg
ICAgICAgICAgICBIb3dldmVyIHdlIGNhbiBkZWZlciB0aGlzIHVudGlsIDQuMyAodGhlcmVmb3Jl
IERPTkUgd2l0aAo+ICAgICAgICAgICAgICAgICBubyB3b3JrKS4KPiAgICAgICAgICAgICAgICog
bGlieGxfKl9wYXRoLiBNYWpvcml0eSBtYWRlIGludGVybmFsLCBvbmx5IGNvbmZpZ2RpciBhbmQK
PiAgICAgICAgICAgICAgICAgbG9ja2RpciByZW1haW4gcHVibGljICh1c2VkIGJ5IHhsKS4gR29v
ZCBlbm91Z2g/Cj4gICAgICAgICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5lZWQgdG8g
YmUgYXN5bmM6Cj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZG9tYWluX3N1c3BlbmQu
IFByb2JhYmx5IG5lZWQgdG8gbW92ZQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHhjX2RvbWFp
bl9zYXZlIGludG8gYSBzZXBhcmF0ZSBwcm9jZXNzLCBhcyBwZXIKPiAgICAgICAgICAgICAgICAg
ICAgICAgICA8MjAzNjYuNDAxODMuNDEwMzg4LjQ0NzYzMEBtYXJpbmVyLnVrLnhlbnNvdXJjZS5j
b20+LiBMaWtlbHkgbmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgeGNfZG9tYWluX3Jlc3RvcmUgdG9v
LiBJJ20gbm90IHN1cmUgaWYgSWFuSiBpcyB3b3JraW5nIChvciBwbGFubmluZyB0byB3b3JrIG9u
KSB0aGlzLgo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9jcmVhdGVfe25l
dyxyZXN0b3JlfSAtLSBJYW5KIGhhcwo+ICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGNoZXMg
YXMgcGFydCBvZiBldmVudCBzZXJpZXMuCj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxf
ZG9tYWluX2NvcmVfZHVtcC4gQ2FuIHRha2UgYSBkdW1teSBhb19ob3cKPiAgICAgICAgICAgICAg
ICAgICAgICAgICBhbmQgcmVtYWluIHN5bmNocm9ub3VzIGludGVybmFsbHkuIChJYW5DLCBwYXRj
aAo+ICAgICAgICAgICAgICAgICAgICAgICAgIHBvc3RlZCkKPiAgICAgICAgICAgICAgICAgICAg
ICAgKiBsaWJ4bF9kZXZpY2Vfe2Rpc2ssbmljLHZrYixhZGR9X2FkZCAoYW5kCj4gICAgICAgICAg
ICAgICAgICAgICAgICAgcmVtb3ZlPykuIFJvZ2VyIFBhdSBNb25uw6kgZml4ZXMgZGlzayBhcyBw
YXJ0IG9mCj4gICAgICAgICAgICAgICAgICAgICAgICAgaG90cGx1ZyBzY3JpcHQgc2VyaWVzIGFu
ZCBhZGRzIGluZnJhc3RydWN0dXJlCj4gICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggc2hv
dWxkIG1ha2UgdGhlIG90aGVycyB0cml2aWFsLiAoUm9nZXIKPiAgICAgICAgICAgICAgICAgICAg
ICAgICBpbnZlc3RpZ2F0aW5nKQo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2Nkcm9t
X2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGRp
c2tfe2FkZCxyZW1vdmV9IGRvbmUsIElhbkogdG8gbG9vayBhdCAob3IKPiAgICAgICAgICAgICAg
ICAgICAgICAgICBkb2luZyBzbz8pLgo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2Rl
dmljZV9kaXNrX2xvY2FsX3thdHRhY2gsZGV0YWNofS4gQmVjb21lCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgaW50ZXJuYWwgYXMgcGFydCBvZiBTdGVmYW5vJ3MgZG9tYWluIDAgZGlzawo+ICAg
ICAgICAgICAgICAgICAgICAgICAgIGF0dGFjaCBzZXJpZXMgKHBhdGNoZXMgcG9zdGVkKQo+ICAg
ICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV9wY2lfe2FkZCxyZW1vdmV9LiBSb2dl
cgo+ICAgICAgICAgICAgICAgICAgICAgICAgIGludmVzdGlnYXRpbmcgYWxvbmcgd2l0aCBvdGhl
ciBhZGQscmVtb3ZlCj4gICAgICAgICAgICAgICAgICAgICAgICAgZnVuY3Rpb25zLgo+ICAgICAg
ICAgICAgICAgICAgICAgICAqIGxpYnhsX3hlbl90bWVtXyouIEFsbCBmdW5jdGlvbnMgYXJlICJm
YXN0IiBhbmQKPiAgICAgICAgICAgICAgICAgICAgICAgICB0aGVyZWZvcmUgbm8gYXN5bmMgbmVl
ZGVkLiBFeGNlcHRpb24gaXMKPiAgICAgICAgICAgICAgICAgICAgICAgICB0bWVtX2Rlc3Ryb3kg
d2hpY2ggRGFuIE1hZ2VuaGVpbWVyIHNheXMgaXMKPiAgICAgICAgICAgICAgICAgICAgICAgICBv
YnNvbGV0ZSBhbmQgY2FuIGp1c3QgYmUgcmVtb3ZlZC4gKElhbiBDLCBwYXRjaAo+ICAgICAgICAg
ICAgICAgICAgICAgICAgIHBvc3RlZCB0byByZW1vdmUgdG1lbV9kZXN0cm95KQo+ICAgICAgICAg
ICAgICAgICAgICAgICAqIGxpYnhsX2ZvcmsgLS0gSWFuSidzIGV2ZW50IHNlcmllcyB3aWxsIHJl
bW92ZQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGFsbCB1c2VycyBvZiB0aGlzLgo+ICAgICAg
ICogW0JVR10gTWFudWFsbHkgYmFsbG9vbmluZyBkb20wLiAgeGwgbWVtLXNldCAwIFtmb29dIGZh
aWxzIHdpdGgKPiAgICAgICAgICJsaWJ4bDogZXJyb3I6IGxpYnhsLmM6MjU2OTpsaWJ4bF9zZXRf
bWVtb3J5X3RhcmdldDogY2Fubm90IGdldAo+ICAgICAgICAgbWVtb3J5IGluZm8gZnJvbSAvbG9j
YWwvZG9tYWluLzAvbWVtb3J5L3N0YXRpYy1tYXg6IE5vIHN1Y2ggZmlsZQo+ICAgICAgICAgb3Ig
ZGlyZWN0b3J5Ii4gVGhpcyBtaWdodCBiZSBzdWl0YWJsZSBmb3IgYW4gZW50aHVzaWFzdGljCj4g
ICAgICAgICBvbi1sb29rZXIuIChHZW9yZ2UgRHVubGFwLCBpbiB0aGUgYWJzZW5jZSBvZiBzYWlk
IG9ubG9va2VyKQo+ICAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgo+ICAgICAgICAg
ICAgICAgKiBbQlVHXSBjYW5ub3QgY3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZXIgb24gSFZN
IGd1ZXN0LAo+ICAgICAgICAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGluCj4g
ICAgICAgICAgICAgICAgIDw0Rjk2NzJERC4yMDgwOTAyQHRpc2NhbGkuaXQ+Cj4gICAgICAgICAg
ICAgICAqIFtCVUddIGRvZXMgbm90IGhvbm91ciBzY2hlZHVsZXIgd2VpZ2h0IHBhcmFtcywgcmVw
b3J0ZWQKPiAgICAgICAgICAgICAgICAgYnkgRGlldGVyIEJsb21zIGluIDwyMDEyMDQyMzE5MzUx
OC5HQTE2MTM0QGJsb21zLmRlPiwKPiAgICAgICAgICAgICAgICAgRGlldGVyIGhhcyBwb3N0ZWQg
YSBwYXRjaC4KPiAgICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBh
Z2UgcGF0Y2hlcyBhbHJlYWR5IGluCj4gICAgICAgICB0cmVlLiBOZWVkcyByZWxlYXNlIG5vdGlu
ZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQgLXJjMSB0bwo+ICAgICAgICAgcmVtaW5kIHBlb3Bs
ZSB0byB0ZXN0IHhsLgo+ICAgICAgICAgICAgICAgKiB4bCB0byByZWZ1c2UgdG8gcnVuIGlmIHhl
bmQgaXMgcnVubmlnLCBSb2dlciBQYXUgTW9ubsOpCj4gICAgICAgICAgICAgICAgIChwYXRjaCBw
b3N0ZWQpCj4gICAgICAgKiBEb21haW4gMCBibG9jayBhdHRhY2ggJiBnZW5lcmFsIGhvdHBsdWcg
d2hlbiB1c2luZyBxZGlzayBiYWNrZW5kCj4gICAgICAgICAobmVlZCB0byBzdGFydCBxZW11IGFz
IG5lY2Vzc2FyeSBldGMpIChTdGVmYW5vIFMsIHBhdGNoZXMKPiAgICAgICAgIHBvc3RlZCkKPiAg
ICAgICAqIGZpbGU6Ly8gYmFja2VuZCBwZXJmb3JtYW5jZS4KPiAgICAgICAgICAgICAgICogcWVt
dS14ZW4tdHJhZGl0aW9uYWwgYW5kIHVwc3RyZWFtIHFlbXUteGVuIHBlcmZvcm1hbmNlCj4gICAg
ICAgICAgICAgICAgIGhhcyBiZWVuIGltcHJvdmVkIGFuZCBpcyBub3cgc2F0aXNmYWN0b3J5Lgo+
ICAgICAgICAgICAgICAgKiBYZW4gNC4yIHdpbGwgcHJlZmVyIGJsa3RhcDIgaWYgYSBrZXJuZWwg
bW9kdWxlIGlzCj4gICAgICAgICAgICAgICAgIGF2YWlsYWJsZSAoZS5nLiBvbGRlciBkb20wIGtl
cm5lbCBvciBES01TIHByb3ZpZGVkCj4gICAgICAgICAgICAgICAgIGtlcm5lbCBtb2R1bGUpIGFu
ZCB3aWxsIGZhbGxiYWNrIHRvIHFlbXUgcWRpc2sgaWYgbm8KPiAgICAgICAgICAgICAgICAgYmxr
dGFwMiBpcyBhdmFpbGFibGUuCj4gICAgICAgICAgICAgICAqIFRoZXJlIHdpbGwgYmUgbm8gdXNl
cnNwYWNlICJibGt0YXAzIiBmb3IgWGVuIDQuMgo+ICAgICAgICogSW1wcm92ZWQgSG90cGx1ZyBz
Y3JpcHQgc3VwcG9ydCAoUm9nZXIgUGF1IE1vbm7DqSwgcGF0Y2hlcwo+ICAgICAgICAgcG9zdGVk
KQo+ICAgICAgICogQmxvY2sgc2NyaXB0IHN1cHBvcnQgLS0gZm9sbG93cyBvbiBmcm9tIGhvdHBs
dWcgc2NyaXB0IChSb2dlcgo+ICAgICAgICAgUGF1IE1vbm7DqSkKCj4gaHlwZXJ2aXNvciwgbmlj
ZSB0byBoYXZlOgo+ICAgICAgICogc29saWQgaW1wbGVtZW50YXRpb24gb2Ygc2hhcmluZy9wYWdp
bmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawo+ICAgICAgICAgcXVldWVzKSAoVGltIERlZWdhbiwg
T2xhZiBIZXJyaW5nIGV0IGFsIC0tIHBhdGNoZXMgcG9zdGVkKQo+ICAgICAgICAgICAgICAgKiAi
VGhlIGxhc3QgcGF0Y2ggdG8gdXNlIGEgd2FpdHF1ZXVlIGluCj4gICAgICAgICAgICAgICAgIF9f
Z2V0X2dmbl90eXBlX2FjY2VzcygpIGZyb20gVGltIHdvcmtzLiAgSG93ZXZlciwgdGhlcmUKPiAg
ICAgICAgICAgICAgICAgYXJlIGEgZmV3IHVzZXJzIHdobyBjYWxsIF9fZ2V0X2dmbl90eXBlX2Fj
Y2VzcyB3aXRoIHRoZQo+ICAgICAgICAgICAgICAgICBkb21haW5fbG9jayBoZWxkLiBUaGlzIHBh
cnQgbmVlZHMgdG8gYmUgYWRkcmVzc2VkIGluCj4gICAgICAgICAgICAgICAgIHNvbWUgd2F5LiIK
PiAgICAgICAgICAgICAgICogRGVmZXJyZWQgdW50aWwgNC4zCj4gICAgICAgKiBTaGFyaW5nIHN1
cHBvcnQgZm9yIEFNRCAoVGltLCBBbmRyZXMpLCBpbiwgbWFya2VkIGFzCj4gICAgICAgICBleHBl
cmltZW50YWwgKHNvLCBET05FLCBhcyBmYXIgYXMgNC4yIGlzIGNvbmNlcm5lZCkuCj4gICAgICAg
KiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwKQoKPiB0b29scywg
bmljZSB0byBoYXZlOgo+ICAgICAgICogQ29uZmlndXJlL2NvbnRyb2wgcGFnaW5nIHZpYSB4bC9s
aWJ4bCAoT2xhZiBIZXJyaW5nLCBsb3RzIG9mCj4gICAgICAgICBkaXNjdXNzaW9uIGFyb3VuZCBp
bnRlcmZhY2UsIGdlbmVyYWwgY29uc2Vuc3VzIHJlYWNoZWQgb24gd2hhdAo+ICAgICAgICAgaXQg
c2hvdWxkIGxvb2sgbGlrZS4gT2xhZiBoYXMgbGV0IG1lIGtub3cgdGhhdCBoZSBpcyBwcm9iYWJs
eQo+ICAgICAgICAgbm90IGdvaW5nIHRvIGhhdmUgdGltZSB0byBkbyB0aGlzIGZvciA0LjIsIHdp
bGwgbGlrZWx5IHNsaXAgdG8KPiAgICAgICAgIDQuMyB1bmxlc3Mgc29tZW9uZSBlbHNlIHdhbnQg
dG8gcGljayB1cCB0aGF0IHdvcmspCj4gICAgICAgICAgICAgICAqIFdpbGwgZGVmZXIgdW50aWwg
NC4zLgo+ICAgICAgICogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gICAgICAgICAg
ICAgICAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVy
YXJkLAo+ICAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCj4gICAgICAgICAgICAgICAqIFVw
c3RyZWFtIHFlbXUgc2F2ZSByZXN0b3JlIChBbnRob255IFBlcmFyZCwgU3RlZmFubwo+ICAgICAg
ICAgICAgICAgICBTdGFiZWxsaW5pLCBxZW11IHBhdGNoZXMgYXBwbGllZCwgd2FpdGluZyBmb3Ig
bGlieGwgZXRjCj4gICAgICAgICAgICAgICAgIHNpZGUgd2hpY2ggaGFzIGJlZW4gcmVjZW50bHkg
cmVwb3N0ZWQpCj4gICAgICAgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24uIEN1cnJlbnRseSAiZXhw
ZXJpbWVudGFsIi4gTGlrZWx5IHRvCj4gICAgICAgICByZWxlYXNlIHRoYXQgd2F5Lgo+ICAgICAg
ICAgICAgICAgKiBOZXN0ZWQgU1ZNLiBUZXN0ZWQgaW4gYSB2YXJpZXR5IG9mIGNvbmZpZ3VyYXRp
b25zIGJ1dAo+ICAgICAgICAgICAgICAgICBzdGlsbCBzb21lIGlzc3VlcyB3aXRoIHRoZSBtb3N0
IGltcG9ydGFudCB1c2UgY2FzZSAodzcKPiAgICAgICAgICAgICAgICAgWFAgbW9kZSkgWzBdICAo
Q2hyaXN0b3BoIEVnZ2VyKQo+ICAgICAgICAgICAgICAgKiBOZXN0ZWQgVk1YLiBOZWVkcyBuZXN0
ZWQgRVBUIHRvIGJlIGdlbnVpbmVseSB1c2VmdWwuCj4gICAgICAgICAgICAgICAgIE5lZWQgbW9y
ZSBkYXRhIG9uIHRlc3RlZG5lc3MgZXRjIChJbnRlbCkKPiAgICAgICAgIERPTkUsIGF0IGxlYXN0
IGFzIGZhciBhcyA0LjIgaXMgY29uY2VybmVkLgo+ICAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0
IGZvciBSZW11cyAobWVtb3J5IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQo+ICAgICAgICAgKFNo
cmlyYW0sIHdhaXRpbmcgb24gbGlieGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9y
ZSkKPiAgICAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPiAgICAgICAgICAgICAgICog
eGwgc3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKPiAg
ICAgICAgICAgICAgICAgb3RoZXJ3aXNlKSAoR29uY2FsbyBHb21lcywgd2FpdGluZyBvbiBuZXcg
dmVyc2lvbiBvZgo+ICAgICAgICAgICAgICAgICBwYXRjaGVzKQo+ICAgICAgICAgICAgICAgKiBz
dXBwb3J0IGZvciB2aWYgInJhdGUiIHBhcmFtZXRlciAoTWF0aGlldSBHYWduw6ksIGZpcnN0Cj4g
ICAgICAgICAgICAgICAgIHBhcnQgYXBwbGllZCkKCj4gWzBdIGh0dHA6Ly9saXN0cy54ZW4ub3Jn
L2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMvbXNnMDA4ODMuaHRtbAoKCgoKCgotLSAK
QmVzdCByZWdhcmRzLAogU2FuZGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1haWx0bzps
aW51eEBlaWtlbGVuYm9vbS5pdAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:32:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfqO-00007d-3F; Tue, 24 Apr 2012 13:31:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfqM-00007K-QC
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:31:46 +0000
Received: from [85.158.143.35:8193] by server-3.bemta-4.messagelabs.com id
	1B/6C-05853-24BA69F4; Tue, 24 Apr 2012 13:31:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335274305!14704182!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32742 invoked from network); 24 Apr 2012 13:31:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:31:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:31:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfqK-0005au-OQ; Tue, 24 Apr 2012 13:31:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfqK-0006wq-NV;
	Tue, 24 Apr 2012 14:31:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43840.714854.970812@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:31:44 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335256933.4347.36.camel@zakaz.uk.xensource.com>
References: <6ef297a3761f3061d2e8.1335219661@vollum>
	<1335256933.4347.36.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap()
 for array sizes greater than a page in xc_linux_osdep.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap() for array sizes greater than a page in xc_linux_osdep.c"):
> On Mon, 2012-04-23 at 23:21 +0100, Aravindh Puthiyaparambil wrote:
> > When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.
> > 
> > Fix an error print with the correct function name.
> > 
> > Do the same for the map array in linux_gnttab_grant_map()
> > 
> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> > Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:32:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfqO-00007d-3F; Tue, 24 Apr 2012 13:31:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfqM-00007K-QC
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:31:46 +0000
Received: from [85.158.143.35:8193] by server-3.bemta-4.messagelabs.com id
	1B/6C-05853-24BA69F4; Tue, 24 Apr 2012 13:31:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335274305!14704182!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32742 invoked from network); 24 Apr 2012 13:31:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12106999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:31:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:31:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfqK-0005au-OQ; Tue, 24 Apr 2012 13:31:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfqK-0006wq-NV;
	Tue, 24 Apr 2012 14:31:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43840.714854.970812@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:31:44 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335256933.4347.36.camel@zakaz.uk.xensource.com>
References: <6ef297a3761f3061d2e8.1335219661@vollum>
	<1335256933.4347.36.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap()
 for array sizes greater than a page in xc_linux_osdep.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] [v3] libxc: Replace alloca() with mmap() for array sizes greater than a page in xc_linux_osdep.c"):
> On Mon, 2012-04-23 at 23:21 +0100, Aravindh Puthiyaparambil wrote:
> > When mapping in large amounts of pages (in the GB range) from a guest in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc client application. This is because the pfn array in linux_privcmd_map_foreign_bulk() is being allocated using alloca() and the subsequent memcpy causes the stack to blow. This patch replaces the alloca() with mmap() for pfn array sizes greater than a page.
> > 
> > Fix an error print with the correct function name.
> > 
> > Do the same for the map array in linux_gnttab_grant_map()
> > 
> > Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> > Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:33:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:33:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfre-0000Iq-1X; Tue, 24 Apr 2012 13:33:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfrd-0000IM-10
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:33:05 +0000
Received: from [85.158.138.51:17120] by server-7.bemta-3.messagelabs.com id
	54/74-03078-09BA69F4; Tue, 24 Apr 2012 13:33:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335274382!19205142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24384 invoked from network); 24 Apr 2012 13:33:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:33:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:33:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:33:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfra-0005bT-6V; Tue, 24 Apr 2012 13:33:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfra-0006x3-5b;
	Tue, 24 Apr 2012 14:33:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43918.161473.320182@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:33:02 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335274056.4347.136.camel@zakaz.uk.xensource.com>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<20374.43433.379674.977454@mariner.uk.xensource.com>
	<1335274056.4347.136.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> On Tue, 2012-04-24 at 14:24 +0100, Ian Jackson wrote:
> > This is a very repetitive piece of code.  Can't it be autogenerated
> > somehow by the idl compiler ?  Ian C ?
> 
> Not without a bunch more plumbing in the infrastructure, which would
> probably heavily outweigh the code here...

Fair enough.

> A compromise might be to make this a libxl__sched_set_params(gc, domid,
> &info->us), so at least it wouldn't be repeated again somewhere.

That would be nice but I wouldn't insist on it until it was necessary
to avoid a second copy.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:33:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:33:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfre-0000Iq-1X; Tue, 24 Apr 2012 13:33:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfrd-0000IM-10
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:33:05 +0000
Received: from [85.158.138.51:17120] by server-7.bemta-3.messagelabs.com id
	54/74-03078-09BA69F4; Tue, 24 Apr 2012 13:33:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335274382!19205142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24384 invoked from network); 24 Apr 2012 13:33:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:33:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:33:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:33:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfra-0005bT-6V; Tue, 24 Apr 2012 13:33:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfra-0006x3-5b;
	Tue, 24 Apr 2012 14:33:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43918.161473.320182@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:33:02 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335274056.4347.136.camel@zakaz.uk.xensource.com>
References: <20120420150012.GB3720@bloms.de>
	<1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<20374.43433.379674.977454@mariner.uk.xensource.com>
	<1335274056.4347.136.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> On Tue, 2012-04-24 at 14:24 +0100, Ian Jackson wrote:
> > This is a very repetitive piece of code.  Can't it be autogenerated
> > somehow by the idl compiler ?  Ian C ?
> 
> Not without a bunch more plumbing in the infrastructure, which would
> probably heavily outweigh the code here...

Fair enough.

> A compromise might be to make this a libxl__sched_set_params(gc, domid,
> &info->us), so at least it wouldn't be repeated again somewhere.

That would be nice but I wouldn't insist on it until it was necessary
to avoid a second copy.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:33:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:33:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfrd-0000Ie-M2; Tue, 24 Apr 2012 13:33:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMfrd-0000IB-3Z
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:33:05 +0000
Received: from [193.109.254.147:45906] by server-12.bemta-14.messagelabs.com
	id 9B/56-05898-F8BA69F4; Tue, 24 Apr 2012 13:33:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335274381!6035928!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1048 invoked from network); 24 Apr 2012 13:33:02 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:33:02 -0000
Received: by qcsc20 with SMTP id c20so444011qcs.32
	for <multiple recipients>; Tue, 24 Apr 2012 06:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=8FfiVNcAiax2gMhvwg09FFBalQxYmPalPvtbg2mdPlI=;
	b=DHzFySSPW8uIk4bDFc2eMRPe+6MOKuOxL7SlFMuIgBbaK39mIhcYG6oc+6bImx8MXs
	brwq8oiILHBqtLqHwj1UUJPP9A0y+yNrpFgmJfm9HJ2VB8ngtOU7vxKtokG3TIL0xXaj
	lUCEv2/wfslDrFwycZNFIYcsW4b3RVtazSpKZtml6NwNNtCmRHXqkKflP0MPJys+HO1A
	VyFFRcwRc38n+p569tQnwNI7kEqEfpG9JqDPdy0KSdCSARhyL2Dp15ySxqDNJkAfYC+P
	9WA8xucxESX+LzDlOs5N9ywvVkWhz+HnTlKwmKVmPWA6/yqpBbJfuwNaCkVu4ZKAcja/
	CCtQ==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr16400028qao.23.1335274381317;
	Tue, 24 Apr 2012 06:33:01 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Tue, 24 Apr 2012 06:33:01 -0700 (PDT)
In-Reply-To: <4F96813C.6030108@xen.org>
References: <4F9199E5.5080409@xen.org>
	<4F96813C.6030108@xen.org>
Date: Tue, 24 Apr 2012 14:33:01 +0100
X-Google-Sender-Auth: 53dzhvF9NxgwZG6j2Yoh1Eo1pKA
Message-ID: <CAFLBxZbwECZnAnko1y3Ec4C2kj9eofJ+tF-fA+3LjVgBXgJR7Q@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: lars.kurth@xen.org
Cc: xen-arm@lists.xen.org, xen-api@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IMPORTANT: Changes to XenSummit Format : Please
	vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 11:32 AM, Lars Kurth <lars.kurth@xen.org> wrote:
> I got a number of votes so far: votes are still open until Friday
>
> let me summarize votes so far:
> - 5 votes for sunday (option 1)
+1=6 votes for Sunday
> - 2 votes for a parallel session on the 26th PM (option 3.1)
> - 1 vote for cutting XenSummit short (option 2)
>
> Regards
> Lars
>
>
> On 20/04/2012 18:16, Lars Kurth wrote:
>>
>> Hi everybody,
>>
>> I have been talking to a number of the key contributors to the project
>> regarding XenSummit and got feedback on the format of XenSummit. Please
>> read, if you are active in the community and DO VOTE!
>>
>> Cheers
>> Lars
>>
>> Change of date in CFP!
>> ======================
>> First I wanted to annouce that we are extending the CFP from May 1st to
>> 15th of June. Key community members felt that May 1 is too early. In
>> particular because we have closed the CFP 5-6 weeks before the event in the
>> past. Due to contractual issues June 15th is the last day we can do though.
>>
>> Proposal! PLEASE READ!
>> ======================
>> A number of vendors felt we should change the format of XenSummit to be
>> more like the Linux Kernel Summit. I.e.
>> a) An invite only event for the top 20-30 developers of the project
>> b) The main focus would be around finding technical solutions and making
>> decisions
>> I can see the merit of this, but it is too late to do this for all of
>> XenSummit due to event contracts that havce been signed.
>>
>> However we have a number of options, moving towards this:
>> 1) Start half a day early and have an invite only XenDev Event event on
>> Sunday afteroon
>> 2) Cut XenSummit short by 1/2 day and append the XenDev event. This may
>> incur some financial penalties for Xen.org and the overall ticket cost may
>> have to be higher than in the past.
>> 3) Do the invite only meeting in parallel with XenSummit. I have an
>> additional large room on TUE the 27th, which we could use for this and I
>> also have two break-out rooms and can allocate one of them to the XenDev
>> event (these were intended for people sitting together and hacking on stuff
>> and/or BoFs). There are several options: hold the XenDev event on
>> 3.1) 26th afternoon
>> 3.2) 27th morning
>> 3.3) 27th afternoon
>>
>> In my view option 1) and 3.1) have the advantage that we can report back
>> to XenSummit, that nobody will miss key talks and that people can sit
>> together in the break-out rooms.
>>
>> Vote
>> ====
>> Please vote by providing. Vote closes by the 27th. Vote by replying to
>> this mail with ...
>> -1: none of the above (i.e. I dont want a XenDev event)
>> +1 for a DevMeeting on sunday (aka for proposal 1)
>> +1 for cutting XenSummit short (aka for proposal 2)
>> +1 for parallel 26th PM (aka proposal 3.1)
>> +1 for parallel 27th AM (aka proposal 3.2)
>> +1 for parallel 27th PM (aka proposal 3.3)
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:33:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:33:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfrd-0000Ie-M2; Tue, 24 Apr 2012 13:33:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMfrd-0000IB-3Z
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:33:05 +0000
Received: from [193.109.254.147:45906] by server-12.bemta-14.messagelabs.com
	id 9B/56-05898-F8BA69F4; Tue, 24 Apr 2012 13:33:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335274381!6035928!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1048 invoked from network); 24 Apr 2012 13:33:02 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:33:02 -0000
Received: by qcsc20 with SMTP id c20so444011qcs.32
	for <multiple recipients>; Tue, 24 Apr 2012 06:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=8FfiVNcAiax2gMhvwg09FFBalQxYmPalPvtbg2mdPlI=;
	b=DHzFySSPW8uIk4bDFc2eMRPe+6MOKuOxL7SlFMuIgBbaK39mIhcYG6oc+6bImx8MXs
	brwq8oiILHBqtLqHwj1UUJPP9A0y+yNrpFgmJfm9HJ2VB8ngtOU7vxKtokG3TIL0xXaj
	lUCEv2/wfslDrFwycZNFIYcsW4b3RVtazSpKZtml6NwNNtCmRHXqkKflP0MPJys+HO1A
	VyFFRcwRc38n+p569tQnwNI7kEqEfpG9JqDPdy0KSdCSARhyL2Dp15ySxqDNJkAfYC+P
	9WA8xucxESX+LzDlOs5N9ywvVkWhz+HnTlKwmKVmPWA6/yqpBbJfuwNaCkVu4ZKAcja/
	CCtQ==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr16400028qao.23.1335274381317;
	Tue, 24 Apr 2012 06:33:01 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Tue, 24 Apr 2012 06:33:01 -0700 (PDT)
In-Reply-To: <4F96813C.6030108@xen.org>
References: <4F9199E5.5080409@xen.org>
	<4F96813C.6030108@xen.org>
Date: Tue, 24 Apr 2012 14:33:01 +0100
X-Google-Sender-Auth: 53dzhvF9NxgwZG6j2Yoh1Eo1pKA
Message-ID: <CAFLBxZbwECZnAnko1y3Ec4C2kj9eofJ+tF-fA+3LjVgBXgJR7Q@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: lars.kurth@xen.org
Cc: xen-arm@lists.xen.org, xen-api@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IMPORTANT: Changes to XenSummit Format : Please
	vote!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 11:32 AM, Lars Kurth <lars.kurth@xen.org> wrote:
> I got a number of votes so far: votes are still open until Friday
>
> let me summarize votes so far:
> - 5 votes for sunday (option 1)
+1=6 votes for Sunday
> - 2 votes for a parallel session on the 26th PM (option 3.1)
> - 1 vote for cutting XenSummit short (option 2)
>
> Regards
> Lars
>
>
> On 20/04/2012 18:16, Lars Kurth wrote:
>>
>> Hi everybody,
>>
>> I have been talking to a number of the key contributors to the project
>> regarding XenSummit and got feedback on the format of XenSummit. Please
>> read, if you are active in the community and DO VOTE!
>>
>> Cheers
>> Lars
>>
>> Change of date in CFP!
>> ======================
>> First I wanted to annouce that we are extending the CFP from May 1st to
>> 15th of June. Key community members felt that May 1 is too early. In
>> particular because we have closed the CFP 5-6 weeks before the event in the
>> past. Due to contractual issues June 15th is the last day we can do though.
>>
>> Proposal! PLEASE READ!
>> ======================
>> A number of vendors felt we should change the format of XenSummit to be
>> more like the Linux Kernel Summit. I.e.
>> a) An invite only event for the top 20-30 developers of the project
>> b) The main focus would be around finding technical solutions and making
>> decisions
>> I can see the merit of this, but it is too late to do this for all of
>> XenSummit due to event contracts that havce been signed.
>>
>> However we have a number of options, moving towards this:
>> 1) Start half a day early and have an invite only XenDev Event event on
>> Sunday afteroon
>> 2) Cut XenSummit short by 1/2 day and append the XenDev event. This may
>> incur some financial penalties for Xen.org and the overall ticket cost may
>> have to be higher than in the past.
>> 3) Do the invite only meeting in parallel with XenSummit. I have an
>> additional large room on TUE the 27th, which we could use for this and I
>> also have two break-out rooms and can allocate one of them to the XenDev
>> event (these were intended for people sitting together and hacking on stuff
>> and/or BoFs). There are several options: hold the XenDev event on
>> 3.1) 26th afternoon
>> 3.2) 27th morning
>> 3.3) 27th afternoon
>>
>> In my view option 1) and 3.1) have the advantage that we can report back
>> to XenSummit, that nobody will miss key talks and that people can sit
>> together in the break-out rooms.
>>
>> Vote
>> ====
>> Please vote by providing. Vote closes by the 27th. Vote by replying to
>> this mail with ...
>> -1: none of the above (i.e. I dont want a XenDev event)
>> +1 for a DevMeeting on sunday (aka for proposal 1)
>> +1 for cutting XenSummit short (aka for proposal 2)
>> +1 for parallel 26th PM (aka proposal 3.1)
>> +1 for parallel 27th AM (aka proposal 3.2)
>> +1 for parallel 27th PM (aka proposal 3.3)
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfsw-0000XX-ME; Tue, 24 Apr 2012 13:34:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfsv-0000XI-0o
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:34:25 +0000
Received: from [85.158.143.35:49793] by server-3.bemta-4.messagelabs.com id
	C6/61-05853-0EBA69F4; Tue, 24 Apr 2012 13:34:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335274463!6385420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20329 invoked from network); 24 Apr 2012 13:34:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:34:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:34:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:34:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfss-0005bw-JL; Tue, 24 Apr 2012 13:34:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfss-0006xC-IU;
	Tue, 24 Apr 2012 14:34:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43998.471725.415493@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:34:22 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335274224.4347.138.camel@zakaz.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> > Can we somehow limit this to commands that actually change things ?
> > Having xl as a diagnostic tool even for xend-based systems is useful.
> 
> Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).

Yes, something like that.

> > > +        if (!access(locks[i], F_OK) && !force_execution) {
> > > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > > +                            "correctly. If you still want to force the "
> > > +                            "execution of xl please use the -f option\n");
> > > +            exit(2);
> > > +        }
> > 
> > If access fails with an unexpected error code (EACCES? EIO?) this will
> > blunder on.
> 
> It'll fail whether the error code is expected or not, won't it?

I think if access fails with EIO, it will return -1, and the if
condition will not be satisfied (!-1 = 0), so the fprintf and exit
will not be taken.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMfsw-0000XX-ME; Tue, 24 Apr 2012 13:34:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMfsv-0000XI-0o
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:34:25 +0000
Received: from [85.158.143.35:49793] by server-3.bemta-4.messagelabs.com id
	C6/61-05853-0EBA69F4; Tue, 24 Apr 2012 13:34:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335274463!6385420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20329 invoked from network); 24 Apr 2012 13:34:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:34:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:34:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:34:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMfss-0005bw-JL; Tue, 24 Apr 2012 13:34:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMfss-0006xC-IU;
	Tue, 24 Apr 2012 14:34:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.43998.471725.415493@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:34:22 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335274224.4347.138.camel@zakaz.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> > Can we somehow limit this to commands that actually change things ?
> > Having xl as a diagnostic tool even for xend-based systems is useful.
> 
> Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).

Yes, something like that.

> > > +        if (!access(locks[i], F_OK) && !force_execution) {
> > > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > > +                            "correctly. If you still want to force the "
> > > +                            "execution of xl please use the -f option\n");
> > > +            exit(2);
> > > +        }
> > 
> > If access fails with an unexpected error code (EACCES? EIO?) this will
> > blunder on.
> 
> It'll fail whether the error code is expected or not, won't it?

I think if access fails with EIO, it will return -1, and the if
condition will not be satisfied (!-1 = 0), so the fprintf and exit
will not be taken.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:42:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMg0D-0000zU-Rj; Tue, 24 Apr 2012 13:41:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMg0C-0000zP-K4
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:41:56 +0000
Received: from [85.158.139.83:58556] by server-10.bemta-5.messagelabs.com id
	CA/79-08260-3ADA69F4; Tue, 24 Apr 2012 13:41:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335274915!25262969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1250 invoked from network); 24 Apr 2012 13:41:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:41:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:41:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMg0A-0005eG-TW; Tue, 24 Apr 2012 13:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMg0A-0006xd-SW;
	Tue, 24 Apr 2012 14:41:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.44450.870790.881237@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:41:54 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334747100.23948.202.camel@zakaz.uk.xensource.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
	<1334747100.23948.202.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> I'm tempted to suggest that we remove this support -- having plain text
> passwords in xenstore (thankfully with perms set somewhat sanely) just
> doesn't seem like a Good Thing to me...

It isn't a good thing.  But currently we have the following three
options:

(a) allow access to anyone who can reach the vnc server's TCP port;

(b) make noninteractive invocation of vnc clients (including
    screenshot utilities, and automatic invocation of the client
    by xl) impossible;

(c) put a plaintext password in the config file (or the xl/xm
    command line) and copy it to xenstore.

I don't think we should abolish (c) until we have another way of
avoiding the problems of (a) and (b).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:42:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMg0D-0000zU-Rj; Tue, 24 Apr 2012 13:41:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMg0C-0000zP-K4
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:41:56 +0000
Received: from [85.158.139.83:58556] by server-10.bemta-5.messagelabs.com id
	CA/79-08260-3ADA69F4; Tue, 24 Apr 2012 13:41:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335274915!25262969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1250 invoked from network); 24 Apr 2012 13:41:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:41:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:41:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMg0A-0005eG-TW; Tue, 24 Apr 2012 13:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMg0A-0006xd-SW;
	Tue, 24 Apr 2012 14:41:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.44450.870790.881237@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:41:54 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334747100.23948.202.camel@zakaz.uk.xensource.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
	<1334747100.23948.202.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> I'm tempted to suggest that we remove this support -- having plain text
> passwords in xenstore (thankfully with perms set somewhat sanely) just
> doesn't seem like a Good Thing to me...

It isn't a good thing.  But currently we have the following three
options:

(a) allow access to anyone who can reach the vnc server's TCP port;

(b) make noninteractive invocation of vnc clients (including
    screenshot utilities, and automatic invocation of the client
    by xl) impossible;

(c) put a plaintext password in the config file (or the xl/xm
    command line) and copy it to xenstore.

I don't think we should abolish (c) until we have another way of
avoiding the problems of (a) and (b).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:46:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMg4M-0001B8-Iz; Tue, 24 Apr 2012 13:46:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMg4K-0001Ax-Oa
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:46:12 +0000
Received: from [85.158.143.35:42630] by server-2.bemta-4.messagelabs.com id
	51/30-17550-3AEA69F4; Tue, 24 Apr 2012 13:46:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335275169!12796051!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18019 invoked from network); 24 Apr 2012 13:46:10 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:46:10 -0000
Received: by qcsp15 with SMTP id p15so450137qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 06:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=bjP1UnF2gsqjqbJQU1SgmtlU/MQolSQ7AOeliE7lKS8=;
	b=ZD0O7abtME2BFX/6MrRyMHhT12R+VyV5batCSCdEDDTc0q3K5OKOK7Q0AIHA+WAvZG
	atqSB+3D4mdSno1XhmsdmXnoMtdKsb8IxLMRE2m3c0QYnraKY4wxpi/uNrkZJOwhZ8Fn
	ovkU8yKxR2gE6B3YNXDCGdKYfW4MDIRYkhv4X7+RhNn3OgMn6d8hp5XzV0SRRaCoW9+s
	V16rR1Y/K83R1PuqCrX2D+QowMCgcZ77xRiEdOwwKHdnyi6Wovq6tGXaWxj6/keDN1a6
	K2mvpMVwKFLiVtETWgjYF4QbZn1zqW2bh91m5dRvRcH9RG/MafrtrVI8dHQDdSIYWTvv
	ZStA==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr16446379qao.23.1335275168993;
	Tue, 24 Apr 2012 06:46:08 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Tue, 24 Apr 2012 06:46:08 -0700 (PDT)
In-Reply-To: <1335273732.4347.130.camel@zakaz.uk.xensource.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:46:08 +0100
X-Google-Sender-Auth: arXawqdD1a7yUBeNUmgyrsMXefY
Message-ID: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> - Add conffiles to manage main config files on package update
>> - Add/remove of main services (xencommons, xendomains)
>
> I don't have any particular objection to doing this but I think we need
> to be clear about what the purpose of Xen's "deb" target is.
>
> It is intended as a convenience to developers (and perhaps some subset
> of users), to allow them to do a reasonably clean "uninstall" of Xen
> installed from source. It is not really intended to provide anything
> more than that.
>
> In particular the packages may not be fully policy compliant and we do
> not plan to support things such as upgrades and the like. It also may
> well be the case the installing the .deb is not sufficient to get a
> working Xen system (i.e. you may still need to do much of the manual
> configuration which is needed if you are building from source). If users
> want a good, well supported package, well integrated, policy compliant
> package for their distro then they should get it from the experts --
> i.e. from the distro.
>
> I'm just concerned that with these patches you may be trying to turn
> this simple convenience functionality into something which you think is
> suitable for end user consumption, which is something we need to think
> carefully about since there is a maintenance (and expectation) burden
> imposed by doing that.

I think in an ideal world, "make deb" (or "make rpm") would be used by
exactly the same people who at the moment do "make install" -- that
is, fairly technical end-users who have the knowledge to muck about
with their system; they need to take the responsibility to not shoot
themselves in the foot (or to bandage it up properly if they do).  I
think it's fairly likely that this will be the case, as long as we set
the expectations properly in the documentation and so on.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:46:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMg4M-0001B8-Iz; Tue, 24 Apr 2012 13:46:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMg4K-0001Ax-Oa
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:46:12 +0000
Received: from [85.158.143.35:42630] by server-2.bemta-4.messagelabs.com id
	51/30-17550-3AEA69F4; Tue, 24 Apr 2012 13:46:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335275169!12796051!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18019 invoked from network); 24 Apr 2012 13:46:10 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:46:10 -0000
Received: by qcsp15 with SMTP id p15so450137qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 06:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=bjP1UnF2gsqjqbJQU1SgmtlU/MQolSQ7AOeliE7lKS8=;
	b=ZD0O7abtME2BFX/6MrRyMHhT12R+VyV5batCSCdEDDTc0q3K5OKOK7Q0AIHA+WAvZG
	atqSB+3D4mdSno1XhmsdmXnoMtdKsb8IxLMRE2m3c0QYnraKY4wxpi/uNrkZJOwhZ8Fn
	ovkU8yKxR2gE6B3YNXDCGdKYfW4MDIRYkhv4X7+RhNn3OgMn6d8hp5XzV0SRRaCoW9+s
	V16rR1Y/K83R1PuqCrX2D+QowMCgcZ77xRiEdOwwKHdnyi6Wovq6tGXaWxj6/keDN1a6
	K2mvpMVwKFLiVtETWgjYF4QbZn1zqW2bh91m5dRvRcH9RG/MafrtrVI8dHQDdSIYWTvv
	ZStA==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr16446379qao.23.1335275168993;
	Tue, 24 Apr 2012 06:46:08 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Tue, 24 Apr 2012 06:46:08 -0700 (PDT)
In-Reply-To: <1335273732.4347.130.camel@zakaz.uk.xensource.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:46:08 +0100
X-Google-Sender-Auth: arXawqdD1a7yUBeNUmgyrsMXefY
Message-ID: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> - Add conffiles to manage main config files on package update
>> - Add/remove of main services (xencommons, xendomains)
>
> I don't have any particular objection to doing this but I think we need
> to be clear about what the purpose of Xen's "deb" target is.
>
> It is intended as a convenience to developers (and perhaps some subset
> of users), to allow them to do a reasonably clean "uninstall" of Xen
> installed from source. It is not really intended to provide anything
> more than that.
>
> In particular the packages may not be fully policy compliant and we do
> not plan to support things such as upgrades and the like. It also may
> well be the case the installing the .deb is not sufficient to get a
> working Xen system (i.e. you may still need to do much of the manual
> configuration which is needed if you are building from source). If users
> want a good, well supported package, well integrated, policy compliant
> package for their distro then they should get it from the experts --
> i.e. from the distro.
>
> I'm just concerned that with these patches you may be trying to turn
> this simple convenience functionality into something which you think is
> suitable for end user consumption, which is something we need to think
> carefully about since there is a maintenance (and expectation) burden
> imposed by doing that.

I think in an ideal world, "make deb" (or "make rpm") would be used by
exactly the same people who at the moment do "make install" -- that
is, fairly technical end-users who have the knowledge to muck about
with their system; they need to take the responsibility to not shoot
themselves in the foot (or to bandage it up properly if they do).  I
think it's fairly likely that this will be the case, as long as we set
the expectations properly in the documentation and so on.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMg4a-0001CI-0n; Tue, 24 Apr 2012 13:46:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMg4X-0001Bl-3a
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:46:26 +0000
Received: from [85.158.143.99:5589] by server-3.bemta-4.messagelabs.com id
	69/39-05853-0BEA69F4; Tue, 24 Apr 2012 13:46:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335275183!13851320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7219 invoked from network); 24 Apr 2012 13:46:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:46:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:46:22 +0100
Message-ID: <1335275181.4347.140.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:46:21 +0100
In-Reply-To: <1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run
 bootloader via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Change initiate_domain_create to properly use libxl__bootloader_run
> rather than improperly calling libxl_run_bootloader with NULL ao_how.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

[...]
> +    /* convenience aliases */
> +    uint32_t domid = dcs->guest_domid;
> +    libxl_domain_config *d_config = dcs->guest_config;
> +    int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *state = &dcs->build_state;
> +    libxl_ctx *ctx = CTX;

I commented on a previous patch about const in these blocks of
"convenience aliases" and I think you were going to scope them all out,
but since there has been a bit of a gap in my review of this series I
might as well mention it again.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMg4a-0001CI-0n; Tue, 24 Apr 2012 13:46:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMg4X-0001Bl-3a
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:46:26 +0000
Received: from [85.158.143.99:5589] by server-3.bemta-4.messagelabs.com id
	69/39-05853-0BEA69F4; Tue, 24 Apr 2012 13:46:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335275183!13851320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7219 invoked from network); 24 Apr 2012 13:46:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:46:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:46:22 +0100
Message-ID: <1335275181.4347.140.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:46:21 +0100
In-Reply-To: <1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run
 bootloader via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Change initiate_domain_create to properly use libxl__bootloader_run
> rather than improperly calling libxl_run_bootloader with NULL ao_how.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

[...]
> +    /* convenience aliases */
> +    uint32_t domid = dcs->guest_domid;
> +    libxl_domain_config *d_config = dcs->guest_config;
> +    int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *state = &dcs->build_state;
> +    libxl_ctx *ctx = CTX;

I commented on a previous patch about const in these blocks of
"convenience aliases" and I think you were going to scope them all out,
but since there has been a bit of a gap in my review of this series I
might as well mention it again.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgCe-0001XJ-38; Tue, 24 Apr 2012 13:54:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMgCc-0001XB-SA
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:54:47 +0000
Received: from [193.109.254.147:30844] by server-8.bemta-14.messagelabs.com id
	88/24-23244-6A0B69F4; Tue, 24 Apr 2012 13:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335275685!6077017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 24 Apr 2012 13:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:54:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:54:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgCS-0005s2-OM; Tue, 24 Apr 2012 13:54:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgCS-0007vX-Ab;
	Tue, 24 Apr 2012 14:54:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.45212.207530.727278@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:54:36 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335275181.4347.140.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
	<1335275181.4347.140.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run
 bootloader via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run bootloader via callback"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > Change initiate_domain_create to properly use libxl__bootloader_run
> > rather than improperly calling libxl_run_bootloader with NULL ao_how.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> [...]
> > +    /* convenience aliases */
> > +    uint32_t domid = dcs->guest_domid;
> > +    libxl_domain_config *d_config = dcs->guest_config;
> > +    int restore_fd = dcs->restore_fd;
> >      libxl__domain_build_state *state = &dcs->build_state;
> > +    libxl_ctx *ctx = CTX;
> 
> I commented on a previous patch about const in these blocks of
> "convenience aliases" and I think you were going to scope them all out,
> but since there has been a bit of a gap in my review of this series I
> might as well mention it again.

I will arrange to constify them all.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgCe-0001XJ-38; Tue, 24 Apr 2012 13:54:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMgCc-0001XB-SA
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 13:54:47 +0000
Received: from [193.109.254.147:30844] by server-8.bemta-14.messagelabs.com id
	88/24-23244-6A0B69F4; Tue, 24 Apr 2012 13:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335275685!6077017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 24 Apr 2012 13:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:54:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:54:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgCS-0005s2-OM; Tue, 24 Apr 2012 13:54:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgCS-0007vX-Ab;
	Tue, 24 Apr 2012 14:54:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.45212.207530.727278@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:54:36 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335275181.4347.140.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-19-git-send-email-ian.jackson@eu.citrix.com>
	<1335275181.4347.140.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run
 bootloader via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 18/24] libxl: make libxl_create run bootloader via callback"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > Change initiate_domain_create to properly use libxl__bootloader_run
> > rather than improperly calling libxl_run_bootloader with NULL ao_how.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> [...]
> > +    /* convenience aliases */
> > +    uint32_t domid = dcs->guest_domid;
> > +    libxl_domain_config *d_config = dcs->guest_config;
> > +    int restore_fd = dcs->restore_fd;
> >      libxl__domain_build_state *state = &dcs->build_state;
> > +    libxl_ctx *ctx = CTX;
> 
> I commented on a previous patch about const in these blocks of
> "convenience aliases" and I think you were going to scope them all out,
> but since there has been a bit of a gap in my review of this series I
> might as well mention it again.

I will arrange to constify them all.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:56:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgEG-0001bS-Je; Tue, 24 Apr 2012 13:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMgEF-0001bK-LV
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:56:27 +0000
Received: from [85.158.143.35:27265] by server-1.bemta-4.messagelabs.com id
	24/25-20925-901B69F4; Tue, 24 Apr 2012 13:56:25 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335275782!12798222!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29802 invoked from network); 24 Apr 2012 13:56:24 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:56:24 -0000
Received: by qafl39 with SMTP id l39so87173qaf.9
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 06:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=+RUevmGDFFiDGYEOfI2wPLX0GvueM5Y5tYGjhWWNeQg=;
	b=Mz/tcXQ0Bpfa4erGmgjCPwcsRQu0py1WroEPWxAt6QWehCC81djNfTtSU7FcyCUpkd
	7kUdtFgMQYhFXeeQEoiQYk0z31v+mFMrqZZVbvso9efAmhkdJXq/OGyxEa6EZQTHOUqr
	+jcnFKkohZRuq2h0n6tcNkIvRgXH7MNoMbZXBoIDz04eY+Aqdeo6yUkWQTEz27cm8L0v
	xjs3aEywdPr9X+IjAMWWD8YJbYneHaPCTHR9JTiS1iwMn+tEWFtHNrVH4Fp1RDohGK1X
	WZAuBtNVI8DvOGaqgm/IoW207qzaHDX6e2I/nj7W9g9x30UUMIbBb/MaQRVslcwv/YXn
	2FLg==
MIME-Version: 1.0
Received: by 10.224.211.72 with SMTP id gn8mr1449639qab.10.1335275782410; Tue,
	24 Apr 2012 06:56:22 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Tue, 24 Apr 2012 06:56:22 -0700 (PDT)
In-Reply-To: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
Date: Tue, 24 Apr 2012 14:56:22 +0100
X-Google-Sender-Auth: nulX-M9MKvSSagLIv2hn9-fEVdY
Message-ID: <CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>>> - Add conffiles to manage main config files on package update
>>> - Add/remove of main services (xencommons, xendomains)
>>
>> I don't have any particular objection to doing this but I think we need
>> to be clear about what the purpose of Xen's "deb" target is.
>>
>> It is intended as a convenience to developers (and perhaps some subset
>> of users), to allow them to do a reasonably clean "uninstall" of Xen
>> installed from source. It is not really intended to provide anything
>> more than that.
>>
>> In particular the packages may not be fully policy compliant and we do
>> not plan to support things such as upgrades and the like. It also may
>> well be the case the installing the .deb is not sufficient to get a
>> working Xen system (i.e. you may still need to do much of the manual
>> configuration which is needed if you are building from source). If users
>> want a good, well supported package, well integrated, policy compliant
>> package for their distro then they should get it from the experts --
>> i.e. from the distro.
>>
>> I'm just concerned that with these patches you may be trying to turn
>> this simple convenience functionality into something which you think is
>> suitable for end user consumption, which is something we need to think
>> carefully about since there is a maintenance (and expectation) burden
>> imposed by doing that.
>
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do). =A0I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.

[Remembering to cc everyone]

Is there a way to add a banner to the install / package description
saying something like, "Warning: This is a custom build of Xen; it is
not an officially supported Debian package.  Please do not
distribute."  Would that make sure no one is confused about the
resulting package?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:56:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgEG-0001bS-Je; Tue, 24 Apr 2012 13:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMgEF-0001bK-LV
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:56:27 +0000
Received: from [85.158.143.35:27265] by server-1.bemta-4.messagelabs.com id
	24/25-20925-901B69F4; Tue, 24 Apr 2012 13:56:25 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335275782!12798222!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29802 invoked from network); 24 Apr 2012 13:56:24 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:56:24 -0000
Received: by qafl39 with SMTP id l39so87173qaf.9
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 06:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=+RUevmGDFFiDGYEOfI2wPLX0GvueM5Y5tYGjhWWNeQg=;
	b=Mz/tcXQ0Bpfa4erGmgjCPwcsRQu0py1WroEPWxAt6QWehCC81djNfTtSU7FcyCUpkd
	7kUdtFgMQYhFXeeQEoiQYk0z31v+mFMrqZZVbvso9efAmhkdJXq/OGyxEa6EZQTHOUqr
	+jcnFKkohZRuq2h0n6tcNkIvRgXH7MNoMbZXBoIDz04eY+Aqdeo6yUkWQTEz27cm8L0v
	xjs3aEywdPr9X+IjAMWWD8YJbYneHaPCTHR9JTiS1iwMn+tEWFtHNrVH4Fp1RDohGK1X
	WZAuBtNVI8DvOGaqgm/IoW207qzaHDX6e2I/nj7W9g9x30UUMIbBb/MaQRVslcwv/YXn
	2FLg==
MIME-Version: 1.0
Received: by 10.224.211.72 with SMTP id gn8mr1449639qab.10.1335275782410; Tue,
	24 Apr 2012 06:56:22 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Tue, 24 Apr 2012 06:56:22 -0700 (PDT)
In-Reply-To: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
Date: Tue, 24 Apr 2012 14:56:22 +0100
X-Google-Sender-Auth: nulX-M9MKvSSagLIv2hn9-fEVdY
Message-ID: <CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>>> - Add conffiles to manage main config files on package update
>>> - Add/remove of main services (xencommons, xendomains)
>>
>> I don't have any particular objection to doing this but I think we need
>> to be clear about what the purpose of Xen's "deb" target is.
>>
>> It is intended as a convenience to developers (and perhaps some subset
>> of users), to allow them to do a reasonably clean "uninstall" of Xen
>> installed from source. It is not really intended to provide anything
>> more than that.
>>
>> In particular the packages may not be fully policy compliant and we do
>> not plan to support things such as upgrades and the like. It also may
>> well be the case the installing the .deb is not sufficient to get a
>> working Xen system (i.e. you may still need to do much of the manual
>> configuration which is needed if you are building from source). If users
>> want a good, well supported package, well integrated, policy compliant
>> package for their distro then they should get it from the experts --
>> i.e. from the distro.
>>
>> I'm just concerned that with these patches you may be trying to turn
>> this simple convenience functionality into something which you think is
>> suitable for end user consumption, which is something we need to think
>> carefully about since there is a maintenance (and expectation) burden
>> imposed by doing that.
>
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do). =A0I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.

[Remembering to cc everyone]

Is there a way to add a banner to the install / package description
saying something like, "Warning: This is a custom build of Xen; it is
not an officially supported Debian package.  Please do not
distribute."  Would that make sure no one is confused about the
resulting package?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:57:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:57:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgFS-0001gd-2D; Tue, 24 Apr 2012 13:57:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMgFQ-0001gV-8Y
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:57:40 +0000
Received: from [85.158.138.51:22683] by server-3.bemta-3.messagelabs.com id
	69/0D-04048-351B69F4; Tue, 24 Apr 2012 13:57:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335275858!23429165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21150 invoked from network); 24 Apr 2012 13:57:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:56:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:56:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgEO-0005w2-8o; Tue, 24 Apr 2012 13:56:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgEO-0001d2-7E;
	Tue, 24 Apr 2012 14:56:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.45332.196951.828384@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:56:36 +0100
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
References: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-access: Check return values and clean
	up on	errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Aravindh Puthiyaparambil writes ("[Xen-devel] [PATCH] xen-access: Check return values and clean up on errors during init"):
> Check the return values of the libxc mem_access calls.
> Free allocated structures (platform_info, domain_info) on errors
> during initialization and exit
> Unbind VIRQ, close event channel and connection to Xen on errors
> during initialization
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

I'm afraid this patch has been wordwrapped at your end, so it doesn't
apply.

Can you resend a fixed version, or send also as an attachment ?

BTW the intent here looks reasonable and it's just a test program so
I've not reviewed it in as much detail as I might do changes to the
core code.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 13:57:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 13:57:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgFS-0001gd-2D; Tue, 24 Apr 2012 13:57:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMgFQ-0001gV-8Y
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 13:57:40 +0000
Received: from [85.158.138.51:22683] by server-3.bemta-3.messagelabs.com id
	69/0D-04048-351B69F4; Tue, 24 Apr 2012 13:57:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335275858!23429165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21150 invoked from network); 24 Apr 2012 13:57:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 13:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:56:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 14:56:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgEO-0005w2-8o; Tue, 24 Apr 2012 13:56:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgEO-0001d2-7E;
	Tue, 24 Apr 2012 14:56:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.45332.196951.828384@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 14:56:36 +0100
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
References: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-access: Check return values and clean
	up on	errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Aravindh Puthiyaparambil writes ("[Xen-devel] [PATCH] xen-access: Check return values and clean up on errors during init"):
> Check the return values of the libxc mem_access calls.
> Free allocated structures (platform_info, domain_info) on errors
> during initialization and exit
> Unbind VIRQ, close event channel and connection to Xen on errors
> during initialization
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

I'm afraid this patch has been wordwrapped at your end, so it doesn't
apply.

Can you resend a fixed version, or send also as an attachment ?

BTW the intent here looks reasonable and it's just a test program so
I've not reviewed it in as much detail as I might do changes to the
core code.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:01:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgIc-0001xm-Ly; Tue, 24 Apr 2012 14:00:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgIa-0001xX-SJ
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:00:57 +0000
Received: from [193.109.254.147:23954] by server-9.bemta-14.messagelabs.com id
	EB/75-05787-812B69F4; Tue, 24 Apr 2012 14:00:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335276038!6060959!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17580 invoked from network); 24 Apr 2012 14:00:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:00:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:59:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:59:35 +0100
Message-ID: <1335275974.4347.148.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:59:34 +0100
In-Reply-To: <1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for
 long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> This will be used for reporting, during domain creation, that the
> console is ready.

I think of progress as being 1%, 2%, 3%...10% etc type stuff. I guess
progress in the sense you mean here could be thought of as "milestones"?

> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 2f559d5..3795654 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
>  {
>      EGC_GC;
>      libxl_event *ev, *ev_tmp;
> +    libxl__aop_occurred *aop, *aop_tmp;
> 
>      LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
>          LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
>          CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
>      }

Are the BSD FOREACH_SAFE functions safe against manipulation from other
threads?

I only ask because Stefano was surprised that this wasn't the case for
the Linux macros, in that context "SAFE" just means you can delete the
element in this thread (like you do here) but that if another thread is
also manipulating the same list.

Quoting Dan in<20120420113557.GJ27101@mwanda>:
> It's safe against deletion in the same thread.  But not against
> deletion from another thread.
> 
> At the beginning of the loop it stores a pointer to the next
> element.  If you delete the element you are on, no problem because
> you already have a pointer to the next one.  But if another thread
> deletes the next element, now you have a pointer which is wrong.

By my reading these macros suffer from the same and therefore a bunch
more locking is needed. I hope I'm mistaken...

> 
> +    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
> +        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
> +        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
> +
> +        CTX_LOCK;
> +        aop->ao->progress_reports_outstanding--;
> +        libxl__ao_complete_check_progress_reports(egc, aop->ao);
> +        CTX_UNLOCK;
> +
> +        free(aop);
> +    }
> +
>      libxl__ao *ao, *ao_tmp;
>      LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
>                               entry_for_callback, ao_tmp) {
> @@ -1285,6 +1298,7 @@ void libxl__ao_abort(libxl__ao *ao)
>      assert(ao->magic == LIBXL__AO_MAGIC);
>      assert(ao->in_initiator);
>      assert(!ao->complete);
> +    assert(!ao->progress_reports_outstanding);
>      libxl__ao__destroy(CTX, ao);
>  }
> 
> @@ -1295,6 +1309,23 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
>      ao->complete = 1;
>      ao->rc = rc;
> 
> +    libxl__ao_complete_check_progress_reports(egc, ao);
> +}
> +
> +void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
> +{
> +    /* We don't consider an ao complete if it has any outstanding
> +     * callbacks.  These callbacks might be outstanding on other
> +     * threads, queued up in the other threads' egc's.  Those threads
> +     * will, after making the callback, take out the lock again,
> +     * decrememt progress_reports_outstanding, and call us again.

          decrement

> +     */
> +
> +    assert(ao->progress_reports_outstanding >= 0);
> +
> +    if (!ao->complete || ao->progress_reports_outstanding)
> +        return;
> +
>      if (ao->poller) {
>          assert(ao->in_initiator);
>          if (!ao->constructing)
> @@ -1316,34 +1347,6 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
>          libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
>  }
> 
> @@ -1401,6 +1404,69 @@ int libxl__ao_inprogress(libxl__ao *ao)
>  }
> 
> 
> +/* progress reporting */
> +
> +/* The application indicates a desire to ignore events by passing NULL
> + * for how.  But we want to copy *how.  So we have this dummy function
> + * whose address is stored in callback if the app passed how==NULL. */
> +static void dummy_asyncprogress_callback_ignore
> +  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
> +
> +void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
> +                               const libxl_asyncprogress_how *from_app) {
> +    if (from_app)
> +        *in_state = *from_app;
> +    else
> +        in_state->callback = dummy_asyncprogress_callback_ignore;
> +}
> +
> +void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
> +        const libxl_asyncprogress_how *how, libxl_event *ev)
> +{
> +    ev->for_user = how->for_event;
> +    if (how->callback == dummy_asyncprogress_callback_ignore) {
> +        /* ignore */
> +    } else if (how->callback) {
> +        libxl__aop_occurred *aop = libxl__zalloc(0, sizeof(*aop));
> +        ao->progress_reports_outstanding++;

Locking for this increment happens in the caller? (later: found the
comment which confirms this now).

> +        aop->ao = ao;
> +        aop->ev = ev;
> +        aop->how = how;
> +    } else {
> +        libxl__event_occurred(egc, ev);
> +    }
> +}
> +
> +
> +libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
> +                            const libxl_asyncop_how *how)

AFAICT this function has just moved and not changed, right?

> +{
> +    libxl__ao *ao;
> +
> +    ao = calloc(1, sizeof(*ao));
> +    if (!ao) goto out;
> +
> +    ao->magic = LIBXL__AO_MAGIC;
> +    ao->constructing = 1;
> +    ao->in_initiator = 1;
> +    ao->poller = 0;
> +    ao->domid = domid;
> +    LIBXL_INIT_GC(ao->gc, ctx);
> +
> +    if (how) {
> +        ao->how = *how;
> +    } else {
> +        ao->poller = libxl__poller_get(ctx);
> +        if (!ao->poller) goto out;
> +    }
> +    return ao;
> +
> + out:
> +    if (ao) libxl__ao__destroy(ctx, ao);
> +    return NULL;
> +}
> +
> +
>  /*
>   * Local variables:
>   * mode: C
[...]

My only concern is about the locking of the list walks -- but if that is
an issue it will also be there in existing code so I think it can all be
fixed in one go later. Hence:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:01:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgIc-0001xm-Ly; Tue, 24 Apr 2012 14:00:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgIa-0001xX-SJ
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:00:57 +0000
Received: from [193.109.254.147:23954] by server-9.bemta-14.messagelabs.com id
	EB/75-05787-812B69F4; Tue, 24 Apr 2012 14:00:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335276038!6060959!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17580 invoked from network); 24 Apr 2012 14:00:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:00:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:59:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:59:35 +0100
Message-ID: <1335275974.4347.148.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 14:59:34 +0100
In-Reply-To: <1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for
 long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> This will be used for reporting, during domain creation, that the
> console is ready.

I think of progress as being 1%, 2%, 3%...10% etc type stuff. I guess
progress in the sense you mean here could be thought of as "milestones"?

> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 2f559d5..3795654 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
>  {
>      EGC_GC;
>      libxl_event *ev, *ev_tmp;
> +    libxl__aop_occurred *aop, *aop_tmp;
> 
>      LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
>          LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
>          CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
>      }

Are the BSD FOREACH_SAFE functions safe against manipulation from other
threads?

I only ask because Stefano was surprised that this wasn't the case for
the Linux macros, in that context "SAFE" just means you can delete the
element in this thread (like you do here) but that if another thread is
also manipulating the same list.

Quoting Dan in<20120420113557.GJ27101@mwanda>:
> It's safe against deletion in the same thread.  But not against
> deletion from another thread.
> 
> At the beginning of the loop it stores a pointer to the next
> element.  If you delete the element you are on, no problem because
> you already have a pointer to the next one.  But if another thread
> deletes the next element, now you have a pointer which is wrong.

By my reading these macros suffer from the same and therefore a bunch
more locking is needed. I hope I'm mistaken...

> 
> +    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
> +        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
> +        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
> +
> +        CTX_LOCK;
> +        aop->ao->progress_reports_outstanding--;
> +        libxl__ao_complete_check_progress_reports(egc, aop->ao);
> +        CTX_UNLOCK;
> +
> +        free(aop);
> +    }
> +
>      libxl__ao *ao, *ao_tmp;
>      LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
>                               entry_for_callback, ao_tmp) {
> @@ -1285,6 +1298,7 @@ void libxl__ao_abort(libxl__ao *ao)
>      assert(ao->magic == LIBXL__AO_MAGIC);
>      assert(ao->in_initiator);
>      assert(!ao->complete);
> +    assert(!ao->progress_reports_outstanding);
>      libxl__ao__destroy(CTX, ao);
>  }
> 
> @@ -1295,6 +1309,23 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
>      ao->complete = 1;
>      ao->rc = rc;
> 
> +    libxl__ao_complete_check_progress_reports(egc, ao);
> +}
> +
> +void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
> +{
> +    /* We don't consider an ao complete if it has any outstanding
> +     * callbacks.  These callbacks might be outstanding on other
> +     * threads, queued up in the other threads' egc's.  Those threads
> +     * will, after making the callback, take out the lock again,
> +     * decrememt progress_reports_outstanding, and call us again.

          decrement

> +     */
> +
> +    assert(ao->progress_reports_outstanding >= 0);
> +
> +    if (!ao->complete || ao->progress_reports_outstanding)
> +        return;
> +
>      if (ao->poller) {
>          assert(ao->in_initiator);
>          if (!ao->constructing)
> @@ -1316,34 +1347,6 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
>          libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
>  }
> 
> @@ -1401,6 +1404,69 @@ int libxl__ao_inprogress(libxl__ao *ao)
>  }
> 
> 
> +/* progress reporting */
> +
> +/* The application indicates a desire to ignore events by passing NULL
> + * for how.  But we want to copy *how.  So we have this dummy function
> + * whose address is stored in callback if the app passed how==NULL. */
> +static void dummy_asyncprogress_callback_ignore
> +  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
> +
> +void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
> +                               const libxl_asyncprogress_how *from_app) {
> +    if (from_app)
> +        *in_state = *from_app;
> +    else
> +        in_state->callback = dummy_asyncprogress_callback_ignore;
> +}
> +
> +void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
> +        const libxl_asyncprogress_how *how, libxl_event *ev)
> +{
> +    ev->for_user = how->for_event;
> +    if (how->callback == dummy_asyncprogress_callback_ignore) {
> +        /* ignore */
> +    } else if (how->callback) {
> +        libxl__aop_occurred *aop = libxl__zalloc(0, sizeof(*aop));
> +        ao->progress_reports_outstanding++;

Locking for this increment happens in the caller? (later: found the
comment which confirms this now).

> +        aop->ao = ao;
> +        aop->ev = ev;
> +        aop->how = how;
> +    } else {
> +        libxl__event_occurred(egc, ev);
> +    }
> +}
> +
> +
> +libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
> +                            const libxl_asyncop_how *how)

AFAICT this function has just moved and not changed, right?

> +{
> +    libxl__ao *ao;
> +
> +    ao = calloc(1, sizeof(*ao));
> +    if (!ao) goto out;
> +
> +    ao->magic = LIBXL__AO_MAGIC;
> +    ao->constructing = 1;
> +    ao->in_initiator = 1;
> +    ao->poller = 0;
> +    ao->domid = domid;
> +    LIBXL_INIT_GC(ao->gc, ctx);
> +
> +    if (how) {
> +        ao->how = *how;
> +    } else {
> +        ao->poller = libxl__poller_get(ctx);
> +        if (!ao->poller) goto out;
> +    }
> +    return ao;
> +
> + out:
> +    if (ao) libxl__ao__destroy(ctx, ao);
> +    return NULL;
> +}
> +
> +
>  /*
>   * Local variables:
>   * mode: C
[...]

My only concern is about the locking of the list walks -- but if that is
an issue it will also be there in existing code so I think it can all be
fixed in one go later. Hence:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:01:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgJG-00022T-7X; Tue, 24 Apr 2012 14:01:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgJF-00022E-93
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:01:37 +0000
Received: from [85.158.138.51:60708] by server-9.bemta-3.messagelabs.com id
	AD/CE-26691-042B69F4; Tue, 24 Apr 2012 14:01:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335276095!23611941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5486 invoked from network); 24 Apr 2012 14:01:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:01:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:01:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:01:34 +0100
Message-ID: <1335276093.4347.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:01:33 +0100
In-Reply-To: <1334596686-8479-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/24] libxl: remove malloc failure handling
 from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Change to use libxl__zalloc, where allocation failure is fatal.
> 
> Also remove a spurious semicolon from the helper macro.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:01:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgJG-00022T-7X; Tue, 24 Apr 2012 14:01:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgJF-00022E-93
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:01:37 +0000
Received: from [85.158.138.51:60708] by server-9.bemta-3.messagelabs.com id
	AD/CE-26691-042B69F4; Tue, 24 Apr 2012 14:01:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335276095!23611941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5486 invoked from network); 24 Apr 2012 14:01:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:01:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:01:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:01:34 +0100
Message-ID: <1335276093.4347.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:01:33 +0100
In-Reply-To: <1334596686-8479-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/24] libxl: remove malloc failure handling
 from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Change to use libxl__zalloc, where allocation failure is fatal.
> 
> Also remove a spurious semicolon from the helper macro.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:02:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgKO-00029X-Mm; Tue, 24 Apr 2012 14:02:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SMgKM-00029K-Pq
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:02:47 +0000
Received: from [85.158.138.51:13667] by server-8.bemta-3.messagelabs.com id
	93/F8-24428-582B69F4; Tue, 24 Apr 2012 14:02:45 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335276164!23481980!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6262 invoked from network); 24 Apr 2012 14:02:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 14:02:45 -0000
Received: from [83.211.178.104] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77381963; Tue, 24 Apr 2012 16:02:43 +0200
Message-ID: <1335276153.9483.8.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <dunlapg@umich.edu>
Date: Tue, 24 Apr 2012 16:02:33 +0200
In-Reply-To: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0737018945102795528=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0737018945102795528==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-gUp/7W2goHgPn3aI5Baw"


--=-gUp/7W2goHgPn3aI5Baw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:=20
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
>=20
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).
>
I see and share Ian's feelings, but I agree with George. :-P
For what it counts, I happen to use kernel-package (make-kpkg) on Debian
systems to build my kernel because it's nice and easy tool to have
package(s) for my very own system.

Trying putting it the other way around, let's say I'd be sad if
make-kpkg weren't there, although I _never_ever_ wanted to distribute to
any kind of users the packages I produced with it.

Does this look close enough to this situation here? (If no, sorry for
the interference :-( ).

> I think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.
>=20
Agreed  again.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-gUp/7W2goHgPn3aI5Baw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+WsnkACgkQk4XaBE3IOsTHGgCeL7p10RLyHoBROpITK0WRsso1
xVcAnA4CqKus7xMKpXhp0GIbD9+kgb1C
=fZ4N
-----END PGP SIGNATURE-----

--=-gUp/7W2goHgPn3aI5Baw--



--===============0737018945102795528==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0737018945102795528==--



From xen-devel-bounces@lists.xen.org Tue Apr 24 14:02:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgKO-00029X-Mm; Tue, 24 Apr 2012 14:02:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SMgKM-00029K-Pq
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:02:47 +0000
Received: from [85.158.138.51:13667] by server-8.bemta-3.messagelabs.com id
	93/F8-24428-582B69F4; Tue, 24 Apr 2012 14:02:45 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335276164!23481980!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6262 invoked from network); 24 Apr 2012 14:02:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 14:02:45 -0000
Received: from [83.211.178.104] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 77381963; Tue, 24 Apr 2012 16:02:43 +0200
Message-ID: <1335276153.9483.8.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <dunlapg@umich.edu>
Date: Tue, 24 Apr 2012 16:02:33 +0200
In-Reply-To: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) 
Mime-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0737018945102795528=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0737018945102795528==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-gUp/7W2goHgPn3aI5Baw"


--=-gUp/7W2goHgPn3aI5Baw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:=20
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
>=20
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).
>
I see and share Ian's feelings, but I agree with George. :-P
For what it counts, I happen to use kernel-package (make-kpkg) on Debian
systems to build my kernel because it's nice and easy tool to have
package(s) for my very own system.

Trying putting it the other way around, let's say I'd be sad if
make-kpkg weren't there, although I _never_ever_ wanted to distribute to
any kind of users the packages I produced with it.

Does this look close enough to this situation here? (If no, sorry for
the interference :-( ).

> I think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.
>=20
Agreed  again.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-gUp/7W2goHgPn3aI5Baw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+WsnkACgkQk4XaBE3IOsTHGgCeL7p10RLyHoBROpITK0WRsso1
xVcAnA4CqKus7xMKpXhp0GIbD9+kgb1C
=fZ4N
-----END PGP SIGNATURE-----

--=-gUp/7W2goHgPn3aI5Baw--



--===============0737018945102795528==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0737018945102795528==--



From xen-devel-bounces@lists.xen.org Tue Apr 24 14:05:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgMs-0002MG-9R; Tue, 24 Apr 2012 14:05:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgMr-0002M8-2P
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:05:21 +0000
Received: from [193.109.254.147:15063] by server-10.bemta-14.messagelabs.com
	id C4/83-05847-023B69F4; Tue, 24 Apr 2012 14:05:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335276313!6080008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5911 invoked from network); 24 Apr 2012 14:05:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:05:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:05:12 +0100
Message-ID: <1335276311.4347.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:05:11 +0100
In-Reply-To: <1334596686-8479-22-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-22-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/24] libxl: convert console callback to
 libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Remove the old console callback.  (Its reentrancy properties were
> troublesome: in principle, the event loop might be reentered during
> the callback, and the libxl__domain_create_state swept out from under
> the feet of the domain creation.)
> 
> As a side effect of the new code arrangements, the console callback
> for non-bootloader-using PV guests now occurs near the end of domain
> creation, in the same place as for HVM guests, rather than near the
> start.
> 
> The new arrangements should in principle mean that by the time the
> console is described as ready by the callback, the xenstore key is
> indeed ready.  So in the future the timeout might be removed from
> the console client.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:05:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgMs-0002MG-9R; Tue, 24 Apr 2012 14:05:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgMr-0002M8-2P
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:05:21 +0000
Received: from [193.109.254.147:15063] by server-10.bemta-14.messagelabs.com
	id C4/83-05847-023B69F4; Tue, 24 Apr 2012 14:05:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335276313!6080008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5911 invoked from network); 24 Apr 2012 14:05:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:05:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:05:12 +0100
Message-ID: <1335276311.4347.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:05:11 +0100
In-Reply-To: <1334596686-8479-22-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-22-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/24] libxl: convert console callback to
 libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Remove the old console callback.  (Its reentrancy properties were
> troublesome: in principle, the event loop might be reentered during
> the callback, and the libxl__domain_create_state swept out from under
> the feet of the domain creation.)
> 
> As a side effect of the new code arrangements, the console callback
> for non-bootloader-using PV guests now occurs near the end of domain
> creation, in the same place as for HVM guests, rather than near the
> start.
> 
> The new arrangements should in principle mean that by the time the
> console is described as ready by the callback, the xenstore key is
> indeed ready.  So in the future the timeout might be removed from
> the console client.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:07:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:07:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgOB-0002Tn-Pk; Tue, 24 Apr 2012 14:06:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgOA-0002Tb-M1
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:06:42 +0000
Received: from [85.158.139.83:49604] by server-11.bemta-5.messagelabs.com id
	D2/51-12959-173B69F4; Tue, 24 Apr 2012 14:06:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335276400!22559441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9203 invoked from network); 24 Apr 2012 14:06:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:06:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:06:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:06:40 +0100
Message-ID: <1335276399.4347.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:06:39 +0100
In-Reply-To: <1334596686-8479-23-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-23-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/24] libxl: clarify definition of "slow"
 operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Update the comment in libxl_internal.h to be clearer about which
> application-facing libxl operations need to take an ao_how.
> 
> Reported-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++------
>  1 files changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index b77a891..fb4dee8 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1399,17 +1399,34 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>  /*
>   * Machinery for asynchronous operations ("ao")
>   *
> - * All "slow" functions (includes anything that might block on a
> - * guest or an external script) need to use the asynchronous
> - * operation ("ao") machinery.  The function should take a parameter
> - * const libxl_asyncop_how *ao_how and must start with a call to
> - * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
> - * inside libxl, because they can cause reentrancy callbacks.
> + * All "slow" functions (see below for the exact definition) need to
> + * use the asynchronous operation ("ao") machinery.  The function
> + * should take a parameter const libxl_asyncop_how *ao_how and must
> + * start with a call to AO_INITIATOR_ENTRY.  These functions MAY NOT
> + * be called from inside libxl, because they can cause reentrancy
> + * callbacks.
>   *
>   * For the same reason functions taking an ao_how may make themselves
>   * an egc with EGC_INIT (and they will generally want to, to be able
>   * to immediately complete an ao during its setup).
>   *
> + *
> + * "Slow" functions includes any that might block on a guest or an
> + * external script.  More broadly, it includes any operations which
> + * are sufficiently slow that an application might reasonably want to
> + * initiate them, and then carry on doing something else, while the
> + * operation completes.  That is, a "fast" function must be fast
> + * enough that we do not mind blocking all other management operations
> + * on the same host while it completes.
> + *
> + * There are certain primitive functions which make a libxl operation
> + * necessarily "slow" for API reasons.  These are:
> + *  - awaiting xenstore watches (although read-modify-write xenstore
> + *    transactions are OK for fast functions)
> + *  - spawning subprocesses
> + *  - anything with a timeout
> + *
> + *
>   * Lifecycle of an ao:
>   *
>   * - Created by libxl__ao_create (or the AO_CREATE convenience macro).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:07:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:07:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgOB-0002Tn-Pk; Tue, 24 Apr 2012 14:06:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgOA-0002Tb-M1
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:06:42 +0000
Received: from [85.158.139.83:49604] by server-11.bemta-5.messagelabs.com id
	D2/51-12959-173B69F4; Tue, 24 Apr 2012 14:06:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335276400!22559441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9203 invoked from network); 24 Apr 2012 14:06:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:06:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12107987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:06:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:06:40 +0100
Message-ID: <1335276399.4347.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:06:39 +0100
In-Reply-To: <1334596686-8479-23-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-23-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/24] libxl: clarify definition of "slow"
 operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Update the comment in libxl_internal.h to be clearer about which
> application-facing libxl operations need to take an ao_how.
> 
> Reported-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++------
>  1 files changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index b77a891..fb4dee8 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1399,17 +1399,34 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>  /*
>   * Machinery for asynchronous operations ("ao")
>   *
> - * All "slow" functions (includes anything that might block on a
> - * guest or an external script) need to use the asynchronous
> - * operation ("ao") machinery.  The function should take a parameter
> - * const libxl_asyncop_how *ao_how and must start with a call to
> - * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
> - * inside libxl, because they can cause reentrancy callbacks.
> + * All "slow" functions (see below for the exact definition) need to
> + * use the asynchronous operation ("ao") machinery.  The function
> + * should take a parameter const libxl_asyncop_how *ao_how and must
> + * start with a call to AO_INITIATOR_ENTRY.  These functions MAY NOT
> + * be called from inside libxl, because they can cause reentrancy
> + * callbacks.
>   *
>   * For the same reason functions taking an ao_how may make themselves
>   * an egc with EGC_INIT (and they will generally want to, to be able
>   * to immediately complete an ao during its setup).
>   *
> + *
> + * "Slow" functions includes any that might block on a guest or an
> + * external script.  More broadly, it includes any operations which
> + * are sufficiently slow that an application might reasonably want to
> + * initiate them, and then carry on doing something else, while the
> + * operation completes.  That is, a "fast" function must be fast
> + * enough that we do not mind blocking all other management operations
> + * on the same host while it completes.
> + *
> + * There are certain primitive functions which make a libxl operation
> + * necessarily "slow" for API reasons.  These are:
> + *  - awaiting xenstore watches (although read-modify-write xenstore
> + *    transactions are OK for fast functions)
> + *  - spawning subprocesses
> + *  - anything with a timeout
> + *
> + *
>   * Lifecycle of an ao:
>   *
>   * - Created by libxl__ao_create (or the AO_CREATE convenience macro).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:07:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgP0-0002ZC-8S; Tue, 24 Apr 2012 14:07:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMgOy-0002Ys-CY
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:07:32 +0000
Received: from [85.158.143.99:8391] by server-3.bemta-4.messagelabs.com id
	40/B2-05853-3A3B69F4; Tue, 24 Apr 2012 14:07:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335276449!25030078!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28186 invoked from network); 24 Apr 2012 14:07:30 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-15.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 14:07:30 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id A842BD34715;
	Tue, 24 Apr 2012 16:07:28 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Tw1HBH7kLaCz; Tue, 24 Apr 2012 16:07:25 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id D0FC7D341B3;
	Tue, 24 Apr 2012 16:07:25 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:07:24 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201204241607.24864.tobias.geiger@vido.info>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Dienstag, 24. April 2012, 14:52:31 schrieb Stefano Stabellini:
> On Tue, 24 Apr 2012, Tobias Geiger wrote:
> > Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> > > >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > > > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> > > >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> > > >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > > >>>> Hello!
> > > >>>> 
> > > >>>> i noticed a considerable drop in I/O Performance when using 3.4
> > > >>>> (rc3 and rc4 tested) as Dom0 Kernel;
> > > >>>> 
> > > >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> > > >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> > > >>>> With 3.4 it drops to about a third of that.
> > > >>>> 
> > > >>>> Xen Version is xen-unstable:
> > > >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> > > >>>> 25209:e6b20ec1824c
> > > >>>> 
> > > >>>> Disk config line is:
> > > >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> > > >>>> - it uses blkback.
> > > >>> 
> > > >>> I fail to see what could be the cause of the issue: nothing on the
> > > >>> blkback side should affect performances significantly.
> > > >>> You could try reverting the four patches to blkback that were
> > > >>> applied between 3.3 and 3.4-rc3 just to make sure it is not a
> > > >>> blkback regression:
> > > >>> 
> > > >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> > > >>> 
> > > >>> Daniel De Graaf (2):
> > > >>>        xen/blkback: use grant-table.c hypercall wrappers
> > > >> 
> > > >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> > > >> the compiler would have kept the result of the first call to
> > > >> vaddr(req, i) somewhere.. but not sure) lost with the mentioned
> > > >> patch:
> > > >> 
> > > >> diff --git a/drivers/block/xen-blkback/blkback.c
> > > > 
> > > > b/drivers/block/xen-blkback/blkback.c
> > > > 
> > > >> index 73f196c..65dbadc 100644
> > > >> --- a/drivers/block/xen-blkback/blkback.c
> > > >> +++ b/drivers/block/xen-blkback/blkback.c
> > > >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> > > >> *req)
> > > >> 
> > > >>   	int ret;
> > > >>   	
> > > >>   	for (i = 0; i<  req->nr_pages; i++) {
> > > >> 
> > > >> +		unsigned long addr;
> > > >> 
> > > >>   		handle = pending_handle(req, i);
> > > >>   		if (handle == BLKBACK_INVALID_HANDLE)
> > > >>   		
> > > >>   			continue;
> > > >> 
> > > >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> > > >> +		addr = vaddr(req, i);
> > > >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> > > >> 
> > > >>   				    GNTMAP_host_map, handle);
> > > >>   		
> > > >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> > > >> 
> > > >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> > > >> +		pages[invcount] = virt_to_page(addr);
> > > >> 
> > > >>   		invcount++;
> > > >>   	
> > > >>   	}
> > > >>   	
> > > >>>        xen/blkback: Enable blkback on HVM guests
> > > >>> 
> > > >>> Konrad Rzeszutek Wilk (2):
> > > >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> > > >>>        type. xen/blkback: Make optional features be really
> > > >>>        optional.
> > > >>> 
> > > >>> _______________________________________________
> > > >>> Xen-devel mailing list
> > > >>> Xen-devel@lists.xen.org
> > > >>> http://lists.xen.org/xen-devel
> > > > 
> > > > that made it even worse :)
> > > > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > > > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> > > 
> > > I doubt this patch can have any meaningful positive or negative
> > > performance effect at all - are you sure you're doing comparable
> > > runs? After all this is all just about a few arithmetic operations
> > > and an array access, which I'd expect to hide in the noise.
> > > 
> > > Jan
> > 
> > I redid the test;
> > 
> > a) with 3.3.0 kernel
> > b) with 3.4.0-rc4
> > c) with 3.40-rc4 and above patch
> > 
> > everything else remained the same, i.e. test-program and test-scenario
> > was not changed and started after about 5min of domu bootup (so that no
> > strange bootup-effects become relevant); same phy-backend (lvm on ssd),
> > same everything else; so i cant see what else except the used dom0
> > kernel is causing this issue; but here are the numbers:
> > 
> > a) read: 135mb/s write: 142mb/s
> > b) read: 39mb/s  write: 39mb/s
> > c) read: 40mb/s  write: 40mb/s
> > 
> > Only thing that may become relevant is the difference in kernel-config
> > betwen 3.3 and 3.4 - here's the diff :
> > http://pastebin.com/raw.php?i=Dy71Fegq
> > 
> > Jan, it seems you're right: The patch doesn't add extra performance
> > regression - i guess i had an i/o intensive task running in dom0 while
> > doing the benchmark yesterday, so that the write performance got so bad.
> > sorry for that.
> > 
> > Still there's a significant performance penalty from 3.3 to 3.4
> 
> Could you please try to revert the following commits?
> 
> git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
> git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
> git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
> git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
> git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
> git revert -n 9846ff10af12f9e7caac696737db6c990592a74a

after reverting said 6 commits (thanks for the ids of these - had difficulties 
to find them), the performance is back to normal.

should i try to circle it down to one of this 6, or do you have a hint on 
which it might be?

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:07:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgP0-0002ZC-8S; Tue, 24 Apr 2012 14:07:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMgOy-0002Ys-CY
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:07:32 +0000
Received: from [85.158.143.99:8391] by server-3.bemta-4.messagelabs.com id
	40/B2-05853-3A3B69F4; Tue, 24 Apr 2012 14:07:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335276449!25030078!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28186 invoked from network); 24 Apr 2012 14:07:30 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-15.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 14:07:30 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id A842BD34715;
	Tue, 24 Apr 2012 16:07:28 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Tw1HBH7kLaCz; Tue, 24 Apr 2012 16:07:25 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id D0FC7D341B3;
	Tue, 24 Apr 2012 16:07:25 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:07:24 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201204241607.24864.tobias.geiger@vido.info>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Dienstag, 24. April 2012, 14:52:31 schrieb Stefano Stabellini:
> On Tue, 24 Apr 2012, Tobias Geiger wrote:
> > Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> > > >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > > > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> > > >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> > > >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > > >>>> Hello!
> > > >>>> 
> > > >>>> i noticed a considerable drop in I/O Performance when using 3.4
> > > >>>> (rc3 and rc4 tested) as Dom0 Kernel;
> > > >>>> 
> > > >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> > > >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> > > >>>> With 3.4 it drops to about a third of that.
> > > >>>> 
> > > >>>> Xen Version is xen-unstable:
> > > >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> > > >>>> 25209:e6b20ec1824c
> > > >>>> 
> > > >>>> Disk config line is:
> > > >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> > > >>>> - it uses blkback.
> > > >>> 
> > > >>> I fail to see what could be the cause of the issue: nothing on the
> > > >>> blkback side should affect performances significantly.
> > > >>> You could try reverting the four patches to blkback that were
> > > >>> applied between 3.3 and 3.4-rc3 just to make sure it is not a
> > > >>> blkback regression:
> > > >>> 
> > > >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> > > >>> 
> > > >>> Daniel De Graaf (2):
> > > >>>        xen/blkback: use grant-table.c hypercall wrappers
> > > >> 
> > > >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> > > >> the compiler would have kept the result of the first call to
> > > >> vaddr(req, i) somewhere.. but not sure) lost with the mentioned
> > > >> patch:
> > > >> 
> > > >> diff --git a/drivers/block/xen-blkback/blkback.c
> > > > 
> > > > b/drivers/block/xen-blkback/blkback.c
> > > > 
> > > >> index 73f196c..65dbadc 100644
> > > >> --- a/drivers/block/xen-blkback/blkback.c
> > > >> +++ b/drivers/block/xen-blkback/blkback.c
> > > >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> > > >> *req)
> > > >> 
> > > >>   	int ret;
> > > >>   	
> > > >>   	for (i = 0; i<  req->nr_pages; i++) {
> > > >> 
> > > >> +		unsigned long addr;
> > > >> 
> > > >>   		handle = pending_handle(req, i);
> > > >>   		if (handle == BLKBACK_INVALID_HANDLE)
> > > >>   		
> > > >>   			continue;
> > > >> 
> > > >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> > > >> +		addr = vaddr(req, i);
> > > >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> > > >> 
> > > >>   				    GNTMAP_host_map, handle);
> > > >>   		
> > > >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> > > >> 
> > > >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> > > >> +		pages[invcount] = virt_to_page(addr);
> > > >> 
> > > >>   		invcount++;
> > > >>   	
> > > >>   	}
> > > >>   	
> > > >>>        xen/blkback: Enable blkback on HVM guests
> > > >>> 
> > > >>> Konrad Rzeszutek Wilk (2):
> > > >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> > > >>>        type. xen/blkback: Make optional features be really
> > > >>>        optional.
> > > >>> 
> > > >>> _______________________________________________
> > > >>> Xen-devel mailing list
> > > >>> Xen-devel@lists.xen.org
> > > >>> http://lists.xen.org/xen-devel
> > > > 
> > > > that made it even worse :)
> > > > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > > > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> > > 
> > > I doubt this patch can have any meaningful positive or negative
> > > performance effect at all - are you sure you're doing comparable
> > > runs? After all this is all just about a few arithmetic operations
> > > and an array access, which I'd expect to hide in the noise.
> > > 
> > > Jan
> > 
> > I redid the test;
> > 
> > a) with 3.3.0 kernel
> > b) with 3.4.0-rc4
> > c) with 3.40-rc4 and above patch
> > 
> > everything else remained the same, i.e. test-program and test-scenario
> > was not changed and started after about 5min of domu bootup (so that no
> > strange bootup-effects become relevant); same phy-backend (lvm on ssd),
> > same everything else; so i cant see what else except the used dom0
> > kernel is causing this issue; but here are the numbers:
> > 
> > a) read: 135mb/s write: 142mb/s
> > b) read: 39mb/s  write: 39mb/s
> > c) read: 40mb/s  write: 40mb/s
> > 
> > Only thing that may become relevant is the difference in kernel-config
> > betwen 3.3 and 3.4 - here's the diff :
> > http://pastebin.com/raw.php?i=Dy71Fegq
> > 
> > Jan, it seems you're right: The patch doesn't add extra performance
> > regression - i guess i had an i/o intensive task running in dom0 while
> > doing the benchmark yesterday, so that the write performance got so bad.
> > sorry for that.
> > 
> > Still there's a significant performance penalty from 3.3 to 3.4
> 
> Could you please try to revert the following commits?
> 
> git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
> git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
> git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
> git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
> git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
> git revert -n 9846ff10af12f9e7caac696737db6c990592a74a

after reverting said 6 commits (thanks for the ids of these - had difficulties 
to find them), the performance is back to normal.

should i try to circle it down to one of this 6, or do you have a hint on 
which it might be?

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:10:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgRx-0002pm-0i; Tue, 24 Apr 2012 14:10:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMgRv-0002pe-Qz
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:10:36 +0000
Received: from [85.158.139.83:8354] by server-7.bemta-5.messagelabs.com id
	B0/05-16195-A54B69F4; Tue, 24 Apr 2012 14:10:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335276633!25309395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20561 invoked from network); 24 Apr 2012 14:10:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:10:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:10:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:10:33 +0100
Date: Tue, 24 Apr 2012 15:16:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204241607.24864.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204241516160.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Tobias Geiger wrote:
> Am Dienstag, 24. April 2012, 14:52:31 schrieb Stefano Stabellini:
> > On Tue, 24 Apr 2012, Tobias Geiger wrote:
> > > Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> > > > >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > > > > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> > > > >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> > > > >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > > > >>>> Hello!
> > > > >>>> 
> > > > >>>> i noticed a considerable drop in I/O Performance when using 3.4
> > > > >>>> (rc3 and rc4 tested) as Dom0 Kernel;
> > > > >>>> 
> > > > >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> > > > >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> > > > >>>> With 3.4 it drops to about a third of that.
> > > > >>>> 
> > > > >>>> Xen Version is xen-unstable:
> > > > >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> > > > >>>> 25209:e6b20ec1824c
> > > > >>>> 
> > > > >>>> Disk config line is:
> > > > >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> > > > >>>> - it uses blkback.
> > > > >>> 
> > > > >>> I fail to see what could be the cause of the issue: nothing on the
> > > > >>> blkback side should affect performances significantly.
> > > > >>> You could try reverting the four patches to blkback that were
> > > > >>> applied between 3.3 and 3.4-rc3 just to make sure it is not a
> > > > >>> blkback regression:
> > > > >>> 
> > > > >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> > > > >>> 
> > > > >>> Daniel De Graaf (2):
> > > > >>>        xen/blkback: use grant-table.c hypercall wrappers
> > > > >> 
> > > > >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> > > > >> the compiler would have kept the result of the first call to
> > > > >> vaddr(req, i) somewhere.. but not sure) lost with the mentioned
> > > > >> patch:
> > > > >> 
> > > > >> diff --git a/drivers/block/xen-blkback/blkback.c
> > > > > 
> > > > > b/drivers/block/xen-blkback/blkback.c
> > > > > 
> > > > >> index 73f196c..65dbadc 100644
> > > > >> --- a/drivers/block/xen-blkback/blkback.c
> > > > >> +++ b/drivers/block/xen-blkback/blkback.c
> > > > >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> > > > >> *req)
> > > > >> 
> > > > >>   	int ret;
> > > > >>   	
> > > > >>   	for (i = 0; i<  req->nr_pages; i++) {
> > > > >> 
> > > > >> +		unsigned long addr;
> > > > >> 
> > > > >>   		handle = pending_handle(req, i);
> > > > >>   		if (handle == BLKBACK_INVALID_HANDLE)
> > > > >>   		
> > > > >>   			continue;
> > > > >> 
> > > > >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> > > > >> +		addr = vaddr(req, i);
> > > > >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> > > > >> 
> > > > >>   				    GNTMAP_host_map, handle);
> > > > >>   		
> > > > >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> > > > >> 
> > > > >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> > > > >> +		pages[invcount] = virt_to_page(addr);
> > > > >> 
> > > > >>   		invcount++;
> > > > >>   	
> > > > >>   	}
> > > > >>   	
> > > > >>>        xen/blkback: Enable blkback on HVM guests
> > > > >>> 
> > > > >>> Konrad Rzeszutek Wilk (2):
> > > > >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> > > > >>>        type. xen/blkback: Make optional features be really
> > > > >>>        optional.
> > > > >>> 
> > > > >>> _______________________________________________
> > > > >>> Xen-devel mailing list
> > > > >>> Xen-devel@lists.xen.org
> > > > >>> http://lists.xen.org/xen-devel
> > > > > 
> > > > > that made it even worse :)
> > > > > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > > > > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> > > > 
> > > > I doubt this patch can have any meaningful positive or negative
> > > > performance effect at all - are you sure you're doing comparable
> > > > runs? After all this is all just about a few arithmetic operations
> > > > and an array access, which I'd expect to hide in the noise.
> > > > 
> > > > Jan
> > > 
> > > I redid the test;
> > > 
> > > a) with 3.3.0 kernel
> > > b) with 3.4.0-rc4
> > > c) with 3.40-rc4 and above patch
> > > 
> > > everything else remained the same, i.e. test-program and test-scenario
> > > was not changed and started after about 5min of domu bootup (so that no
> > > strange bootup-effects become relevant); same phy-backend (lvm on ssd),
> > > same everything else; so i cant see what else except the used dom0
> > > kernel is causing this issue; but here are the numbers:
> > > 
> > > a) read: 135mb/s write: 142mb/s
> > > b) read: 39mb/s  write: 39mb/s
> > > c) read: 40mb/s  write: 40mb/s
> > > 
> > > Only thing that may become relevant is the difference in kernel-config
> > > betwen 3.3 and 3.4 - here's the diff :
> > > http://pastebin.com/raw.php?i=Dy71Fegq
> > > 
> > > Jan, it seems you're right: The patch doesn't add extra performance
> > > regression - i guess i had an i/o intensive task running in dom0 while
> > > doing the benchmark yesterday, so that the write performance got so bad.
> > > sorry for that.
> > > 
> > > Still there's a significant performance penalty from 3.3 to 3.4
> > 
> > Could you please try to revert the following commits?
> > 
> > git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
> > git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
> > git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
> > git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
> > git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
> > git revert -n 9846ff10af12f9e7caac696737db6c990592a74a
> 
> after reverting said 6 commits (thanks for the ids of these - had difficulties 
> to find them), the performance is back to normal.
> 
> should i try to circle it down to one of this 6, or do you have a hint on 
> which it might be?

that would be great :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:10:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgRx-0002pm-0i; Tue, 24 Apr 2012 14:10:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMgRv-0002pe-Qz
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:10:36 +0000
Received: from [85.158.139.83:8354] by server-7.bemta-5.messagelabs.com id
	B0/05-16195-A54B69F4; Tue, 24 Apr 2012 14:10:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335276633!25309395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20561 invoked from network); 24 Apr 2012 14:10:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:10:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:10:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:10:33 +0100
Date: Tue, 24 Apr 2012 15:16:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204241607.24864.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204241516160.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012, Tobias Geiger wrote:
> Am Dienstag, 24. April 2012, 14:52:31 schrieb Stefano Stabellini:
> > On Tue, 24 Apr 2012, Tobias Geiger wrote:
> > > Am Dienstag, 24. April 2012, 09:27:42 schrieb Jan Beulich:
> > > > >>> On 23.04.12 at 22:53, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > > > > Am 23.04.2012 17:24, schrieb Konrad Rzeszutek Wilk:
> > > > >> On Mon, Apr 23, 2012 at 12:53:03PM +0100, Stefano Stabellini wrote:
> > > > >>> On Mon, 23 Apr 2012, Tobias Geiger wrote:
> > > > >>>> Hello!
> > > > >>>> 
> > > > >>>> i noticed a considerable drop in I/O Performance when using 3.4
> > > > >>>> (rc3 and rc4 tested) as Dom0 Kernel;
> > > > >>>> 
> > > > >>>> With 3.3 i get over 100mb/s in a HVM DomU (win64) with PV Drivers
> > > > >>>> (gplpv_Vista2008x64_0.11.0.357.msi);
> > > > >>>> With 3.4 it drops to about a third of that.
> > > > >>>> 
> > > > >>>> Xen Version is xen-unstable:
> > > > >>>> xen_changeset          : Tue Apr 17 19:13:52 2012 +0100
> > > > >>>> 25209:e6b20ec1824c
> > > > >>>> 
> > > > >>>> Disk config line is:
> > > > >>>> disk = [ '/dev/vg_ssd/win7system,,hda' ]
> > > > >>>> - it uses blkback.
> > > > >>> 
> > > > >>> I fail to see what could be the cause of the issue: nothing on the
> > > > >>> blkback side should affect performances significantly.
> > > > >>> You could try reverting the four patches to blkback that were
> > > > >>> applied between 3.3 and 3.4-rc3 just to make sure it is not a
> > > > >>> blkback regression:
> > > > >>> 
> > > > >>> $ git shortlog v3.3..v3.4-rc3 drivers/block/xen-blkback
> > > > >>> 
> > > > >>> Daniel De Graaf (2):
> > > > >>>        xen/blkback: use grant-table.c hypercall wrappers
> > > > >> 
> > > > >> Hm.. Perhaps this patch fixes it a possible perf (I would think that
> > > > >> the compiler would have kept the result of the first call to
> > > > >> vaddr(req, i) somewhere.. but not sure) lost with the mentioned
> > > > >> patch:
> > > > >> 
> > > > >> diff --git a/drivers/block/xen-blkback/blkback.c
> > > > > 
> > > > > b/drivers/block/xen-blkback/blkback.c
> > > > > 
> > > > >> index 73f196c..65dbadc 100644
> > > > >> --- a/drivers/block/xen-blkback/blkback.c
> > > > >> +++ b/drivers/block/xen-blkback/blkback.c
> > > > >> @@ -327,13 +327,15 @@ static void xen_blkbk_unmap(struct pending_req
> > > > >> *req)
> > > > >> 
> > > > >>   	int ret;
> > > > >>   	
> > > > >>   	for (i = 0; i<  req->nr_pages; i++) {
> > > > >> 
> > > > >> +		unsigned long addr;
> > > > >> 
> > > > >>   		handle = pending_handle(req, i);
> > > > >>   		if (handle == BLKBACK_INVALID_HANDLE)
> > > > >>   		
> > > > >>   			continue;
> > > > >> 
> > > > >> -		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
> > > > >> +		addr = vaddr(req, i);
> > > > >> +		gnttab_set_unmap_op(&unmap[invcount], addr,
> > > > >> 
> > > > >>   				    GNTMAP_host_map, handle);
> > > > >>   		
> > > > >>   		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> > > > >> 
> > > > >> -		pages[invcount] = virt_to_page(vaddr(req, i));
> > > > >> +		pages[invcount] = virt_to_page(addr);
> > > > >> 
> > > > >>   		invcount++;
> > > > >>   	
> > > > >>   	}
> > > > >>   	
> > > > >>>        xen/blkback: Enable blkback on HVM guests
> > > > >>> 
> > > > >>> Konrad Rzeszutek Wilk (2):
> > > > >>>        xen/blkback: Squash the discard support for 'file' and 'phy'
> > > > >>>        type. xen/blkback: Make optional features be really
> > > > >>>        optional.
> > > > >>> 
> > > > >>> _______________________________________________
> > > > >>> Xen-devel mailing list
> > > > >>> Xen-devel@lists.xen.org
> > > > >>> http://lists.xen.org/xen-devel
> > > > > 
> > > > > that made it even worse :)
> > > > > Write Performance is down to about 7mb/s (with 3.3: ~130mb/s)
> > > > > Read "only" down to 40mb/s (with 3.3: ~140mb/s)
> > > > 
> > > > I doubt this patch can have any meaningful positive or negative
> > > > performance effect at all - are you sure you're doing comparable
> > > > runs? After all this is all just about a few arithmetic operations
> > > > and an array access, which I'd expect to hide in the noise.
> > > > 
> > > > Jan
> > > 
> > > I redid the test;
> > > 
> > > a) with 3.3.0 kernel
> > > b) with 3.4.0-rc4
> > > c) with 3.40-rc4 and above patch
> > > 
> > > everything else remained the same, i.e. test-program and test-scenario
> > > was not changed and started after about 5min of domu bootup (so that no
> > > strange bootup-effects become relevant); same phy-backend (lvm on ssd),
> > > same everything else; so i cant see what else except the used dom0
> > > kernel is causing this issue; but here are the numbers:
> > > 
> > > a) read: 135mb/s write: 142mb/s
> > > b) read: 39mb/s  write: 39mb/s
> > > c) read: 40mb/s  write: 40mb/s
> > > 
> > > Only thing that may become relevant is the difference in kernel-config
> > > betwen 3.3 and 3.4 - here's the diff :
> > > http://pastebin.com/raw.php?i=Dy71Fegq
> > > 
> > > Jan, it seems you're right: The patch doesn't add extra performance
> > > regression - i guess i had an i/o intensive task running in dom0 while
> > > doing the benchmark yesterday, so that the write performance got so bad.
> > > sorry for that.
> > > 
> > > Still there's a significant performance penalty from 3.3 to 3.4
> > 
> > Could you please try to revert the following commits?
> > 
> > git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
> > git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
> > git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
> > git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
> > git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
> > git revert -n 9846ff10af12f9e7caac696737db6c990592a74a
> 
> after reverting said 6 commits (thanks for the ids of these - had difficulties 
> to find them), the performance is back to normal.
> 
> should i try to circle it down to one of this 6, or do you have a hint on 
> which it might be?

that would be great :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:12:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgTZ-0002xL-GY; Tue, 24 Apr 2012 14:12:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgTY-0002x8-95
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:12:16 +0000
Received: from [85.158.139.83:33759] by server-5.bemta-5.messagelabs.com id
	D3/2D-13566-FB4B69F4; Tue, 24 Apr 2012 14:12:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335276734!25270133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19515 invoked from network); 24 Apr 2012 14:12:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:12:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:12:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:12:13 +0100
Message-ID: <1335276732.4347.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:12:12 +0100
In-Reply-To: <1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> is now moved elsewhere, as follows:
> 
> * The "logging version of fork", which is what it was billed as, is now
>   xl_fork, which also dies on failure.
> 
> * Closing the xenstore handle in the child is now done in
>   libxl__ev_child_fork, which is the only remaining place where fork
>   is called in libxl.
> 
> * We provide a new function libxl__ev_child_xenstore_reopen for
>   in-libxl children to make the ctx useable for xenstore again.
> 
> * Consequently libxl__spawn_record_pid now no longer needs to mess
>   about with its own xenstore handle.  As a bonus it can now just use
>   libxl__xs_write.
> 
> Also, since we have now converted all the forkers in libxl, we can
> always honour the fork_replacement childproc hook - so do so.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_exec.c     |   35 ++++++++++++++++-------------------
>  tools/libxl/libxl_fork.c     |   25 ++++++++++++++++++++++++-
>  tools/libxl/libxl_internal.h |    5 +++++
>  tools/libxl/libxl_utils.c    |   21 ---------------------
>  tools/libxl/libxl_utils.h    |    3 +--
>  tools/libxl/xl.c             |   12 ++++++++++++
>  tools/libxl/xl.h             |    1 +
>  tools/libxl/xl_cmdimpl.c     |    5 ++---
>  8 files changed, 61 insertions(+), 46 deletions(-)
> 
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index d44b702..d681736 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
>  
> @@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
>  
>      /* we are now the middle process */
>  
> -    child = fork();
> +    pid_t (*fork_replacement)(void*) =
> +        CTX->childproc_hooks
> +        ? CTX->childproc_hooks->fork_replacement
> +        : 0;
> +    child =
> +        fork_replacement
> +        ? fork_replacement(CTX->childproc_user)
> +        : fork();

A helper function or macro would be useful here?

> +
>      if (child == -1)
>          exit(255);
>      if (!child) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index fb4dee8..3e90ac4 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -627,6 +627,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
>  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
>                  { return childw_out->pid >= 0; }
>  
> +/* Useable (only) in the child to once more make the ctx useable for
> + * xenstore operations.

Specifically "the child" is the middle child of a spawn? Otherwise the
constraint must be something like "before any threads are created in the
new process", or something like that?

>   logs failure in the form "what: <error
> + * message>". */
> +_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what);
> +
>  
>  /*
>   * Other event-handling support provided by the libxl event core to


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:12:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgTZ-0002xL-GY; Tue, 24 Apr 2012 14:12:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgTY-0002x8-95
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:12:16 +0000
Received: from [85.158.139.83:33759] by server-5.bemta-5.messagelabs.com id
	D3/2D-13566-FB4B69F4; Tue, 24 Apr 2012 14:12:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335276734!25270133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19515 invoked from network); 24 Apr 2012 14:12:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:12:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:12:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:12:13 +0100
Message-ID: <1335276732.4347.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:12:12 +0100
In-Reply-To: <1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> is now moved elsewhere, as follows:
> 
> * The "logging version of fork", which is what it was billed as, is now
>   xl_fork, which also dies on failure.
> 
> * Closing the xenstore handle in the child is now done in
>   libxl__ev_child_fork, which is the only remaining place where fork
>   is called in libxl.
> 
> * We provide a new function libxl__ev_child_xenstore_reopen for
>   in-libxl children to make the ctx useable for xenstore again.
> 
> * Consequently libxl__spawn_record_pid now no longer needs to mess
>   about with its own xenstore handle.  As a bonus it can now just use
>   libxl__xs_write.
> 
> Also, since we have now converted all the forkers in libxl, we can
> always honour the fork_replacement childproc hook - so do so.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_exec.c     |   35 ++++++++++++++++-------------------
>  tools/libxl/libxl_fork.c     |   25 ++++++++++++++++++++++++-
>  tools/libxl/libxl_internal.h |    5 +++++
>  tools/libxl/libxl_utils.c    |   21 ---------------------
>  tools/libxl/libxl_utils.h    |    3 +--
>  tools/libxl/xl.c             |   12 ++++++++++++
>  tools/libxl/xl.h             |    1 +
>  tools/libxl/xl_cmdimpl.c     |    5 ++---
>  8 files changed, 61 insertions(+), 46 deletions(-)
> 
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index d44b702..d681736 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
>  
> @@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
>  
>      /* we are now the middle process */
>  
> -    child = fork();
> +    pid_t (*fork_replacement)(void*) =
> +        CTX->childproc_hooks
> +        ? CTX->childproc_hooks->fork_replacement
> +        : 0;
> +    child =
> +        fork_replacement
> +        ? fork_replacement(CTX->childproc_user)
> +        : fork();

A helper function or macro would be useful here?

> +
>      if (child == -1)
>          exit(255);
>      if (!child) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index fb4dee8..3e90ac4 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -627,6 +627,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
>  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
>                  { return childw_out->pid >= 0; }
>  
> +/* Useable (only) in the child to once more make the ctx useable for
> + * xenstore operations.

Specifically "the child" is the middle child of a spawn? Otherwise the
constraint must be something like "before any threads are created in the
new process", or something like that?

>   logs failure in the form "what: <error
> + * message>". */
> +_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what);
> +
>  
>  /*
>   * Other event-handling support provided by the libxl event core to


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:18:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgZU-0003Ek-D8; Tue, 24 Apr 2012 14:18:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgZT-0003Ef-5P
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:18:23 +0000
Received: from [193.109.254.147:32687] by server-1.bemta-14.messagelabs.com id
	19/76-29372-E26B69F4; Tue, 24 Apr 2012 14:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335277101!6046189!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 24 Apr 2012 14:18:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:18:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:18:21 +0100
Message-ID: <1335277100.4347.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:18:20 +0100
In-Reply-To: <1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 991f16e..e43aedc 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -585,6 +585,37 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
>  }
>  
>  /*
> + * domain death/destruction
> + */
> +
> +static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w,
> +                            const char *watch_path, const char *event_path)
> +{
> +    libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch);
> +    EGC_GC;
> +    const char *p = libxl__xs_read(gc, XBT_NULL, watch_path);
> +    if (p) return;
> +
> +    if (errno!=ENOENT) {
> +        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
> +                              " for domain deatch check", errno, 0);

                                              detach

> +        return;
> +    }
> +
> +    LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)",
> +        dc->what, dc->domid, watch_path);
> +    dc->callback(egc, dc);
> +}
> +
> +int libxl__domaindeathcheck_start(libxl__gc *gc,
> +                                  libxl__domaindeathcheck *dc)
> +{
> +    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
> +    return libxl__ev_xswatch_register(gc, &dc->watch,
> +                                      domaindeathcheck_callback, path);

So we are watching for the toolstack (possibly the same one as we are
running in) to destroy the domain and therefore nuke the xs directory --
does that actually work?

Specifically in the case of xl running the bootloader -- is xl in any
position to handle a domain death during domain build? Isn't it doing
the create synchronously?

(note, I'm not actually 100% sure what might be wrong with this, it just
strikes me as odd...)

Wouldn't using the @releaseDomain watch be more reliable?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:18:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgZU-0003Ek-D8; Tue, 24 Apr 2012 14:18:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgZT-0003Ef-5P
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:18:23 +0000
Received: from [193.109.254.147:32687] by server-1.bemta-14.messagelabs.com id
	19/76-29372-E26B69F4; Tue, 24 Apr 2012 14:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335277101!6046189!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 24 Apr 2012 14:18:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:18:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:18:21 +0100
Message-ID: <1335277100.4347.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:18:20 +0100
In-Reply-To: <1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 991f16e..e43aedc 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -585,6 +585,37 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
>  }
>  
>  /*
> + * domain death/destruction
> + */
> +
> +static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w,
> +                            const char *watch_path, const char *event_path)
> +{
> +    libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch);
> +    EGC_GC;
> +    const char *p = libxl__xs_read(gc, XBT_NULL, watch_path);
> +    if (p) return;
> +
> +    if (errno!=ENOENT) {
> +        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
> +                              " for domain deatch check", errno, 0);

                                              detach

> +        return;
> +    }
> +
> +    LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)",
> +        dc->what, dc->domid, watch_path);
> +    dc->callback(egc, dc);
> +}
> +
> +int libxl__domaindeathcheck_start(libxl__gc *gc,
> +                                  libxl__domaindeathcheck *dc)
> +{
> +    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
> +    return libxl__ev_xswatch_register(gc, &dc->watch,
> +                                      domaindeathcheck_callback, path);

So we are watching for the toolstack (possibly the same one as we are
running in) to destroy the domain and therefore nuke the xs directory --
does that actually work?

Specifically in the case of xl running the bootloader -- is xl in any
position to handle a domain death during domain build? Isn't it doing
the create synchronously?

(note, I'm not actually 100% sure what might be wrong with this, it just
strikes me as odd...)

Wouldn't using the @releaseDomain watch be more reliable?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:20:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgbN-0003J8-UD; Tue, 24 Apr 2012 14:20:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgbM-0003J0-9J
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:20:20 +0000
Received: from [85.158.139.83:54269] by server-12.bemta-5.messagelabs.com id
	F7/B0-05587-3A6B69F4; Tue, 24 Apr 2012 14:20:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335277218!25311298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2057 invoked from network); 24 Apr 2012 14:20:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:20:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:20:17 +0100
Message-ID: <1335277215.4347.161.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <dunlapg@umich.edu>
Date: Tue, 24 Apr 2012 15:20:15 +0100
In-Reply-To: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> - Add conffiles to manage main config files on package update
> >> - Add/remove of main services (xencommons, xendomains)
> >
> > I don't have any particular objection to doing this but I think we need
> > to be clear about what the purpose of Xen's "deb" target is.
> >
> > It is intended as a convenience to developers (and perhaps some subset
> > of users), to allow them to do a reasonably clean "uninstall" of Xen
> > installed from source. It is not really intended to provide anything
> > more than that.
> >
> > In particular the packages may not be fully policy compliant and we do
> > not plan to support things such as upgrades and the like. It also may
> > well be the case the installing the .deb is not sufficient to get a
> > working Xen system (i.e. you may still need to do much of the manual
> > configuration which is needed if you are building from source). If users
> > want a good, well supported package, well integrated, policy compliant
> > package for their distro then they should get it from the experts --
> > i.e. from the distro.
> >
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
> 
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).  I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.

That seems reasonable, but much of the functionality being added here
isn't done by "make install", is it?

I'm not actually sure about the update-rc.d but the conf file handling
is clearly not part of "make install"

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:20:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgbN-0003J8-UD; Tue, 24 Apr 2012 14:20:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgbM-0003J0-9J
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:20:20 +0000
Received: from [85.158.139.83:54269] by server-12.bemta-5.messagelabs.com id
	F7/B0-05587-3A6B69F4; Tue, 24 Apr 2012 14:20:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335277218!25311298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2057 invoked from network); 24 Apr 2012 14:20:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:20:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:20:17 +0100
Message-ID: <1335277215.4347.161.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <dunlapg@umich.edu>
Date: Tue, 24 Apr 2012 15:20:15 +0100
In-Reply-To: <CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> - Add conffiles to manage main config files on package update
> >> - Add/remove of main services (xencommons, xendomains)
> >
> > I don't have any particular objection to doing this but I think we need
> > to be clear about what the purpose of Xen's "deb" target is.
> >
> > It is intended as a convenience to developers (and perhaps some subset
> > of users), to allow them to do a reasonably clean "uninstall" of Xen
> > installed from source. It is not really intended to provide anything
> > more than that.
> >
> > In particular the packages may not be fully policy compliant and we do
> > not plan to support things such as upgrades and the like. It also may
> > well be the case the installing the .deb is not sufficient to get a
> > working Xen system (i.e. you may still need to do much of the manual
> > configuration which is needed if you are building from source). If users
> > want a good, well supported package, well integrated, policy compliant
> > package for their distro then they should get it from the experts --
> > i.e. from the distro.
> >
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
> 
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).  I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.

That seems reasonable, but much of the functionality being added here
isn't done by "make install", is it?

I'm not actually sure about the update-rc.d but the conf file handling
is clearly not part of "make install"

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:22:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgd4-0003QI-FU; Tue, 24 Apr 2012 14:22:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgd3-0003Q6-5F
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:22:05 +0000
Received: from [193.109.254.147:30316] by server-2.bemta-14.messagelabs.com id
	5F/F0-19409-C07B69F4; Tue, 24 Apr 2012 14:22:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335277323!410975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12662 invoked from network); 24 Apr 2012 14:22:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:22:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:22:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:22:03 +0100
Message-ID: <1335277321.4347.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:22:01 +0100
In-Reply-To: <CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
	<CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:56 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> > On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> - Add conffiles to manage main config files on package update
> >>> - Add/remove of main services (xencommons, xendomains)
> >>
> >> I don't have any particular objection to doing this but I think we need
> >> to be clear about what the purpose of Xen's "deb" target is.
> >>
> >> It is intended as a convenience to developers (and perhaps some subset
> >> of users), to allow them to do a reasonably clean "uninstall" of Xen
> >> installed from source. It is not really intended to provide anything
> >> more than that.
> >>
> >> In particular the packages may not be fully policy compliant and we do
> >> not plan to support things such as upgrades and the like. It also may
> >> well be the case the installing the .deb is not sufficient to get a
> >> working Xen system (i.e. you may still need to do much of the manual
> >> configuration which is needed if you are building from source). If users
> >> want a good, well supported package, well integrated, policy compliant
> >> package for their distro then they should get it from the experts --
> >> i.e. from the distro.
> >>
> >> I'm just concerned that with these patches you may be trying to turn
> >> this simple convenience functionality into something which you think is
> >> suitable for end user consumption, which is something we need to think
> >> carefully about since there is a maintenance (and expectation) burden
> >> imposed by doing that.
> >
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do).  I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
> 
> [Remembering to cc everyone]
> 
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package.  Please do not
> distribute."  Would that make sure no one is confused about the
> resulting package?

tools/misc/mkdeb can inject whatever it likes into the description.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:22:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgd4-0003QI-FU; Tue, 24 Apr 2012 14:22:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgd3-0003Q6-5F
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:22:05 +0000
Received: from [193.109.254.147:30316] by server-2.bemta-14.messagelabs.com id
	5F/F0-19409-C07B69F4; Tue, 24 Apr 2012 14:22:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335277323!410975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12662 invoked from network); 24 Apr 2012 14:22:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:22:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:22:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:22:03 +0100
Message-ID: <1335277321.4347.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:22:01 +0100
In-Reply-To: <CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
	<CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:56 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> > On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> - Add conffiles to manage main config files on package update
> >>> - Add/remove of main services (xencommons, xendomains)
> >>
> >> I don't have any particular objection to doing this but I think we need
> >> to be clear about what the purpose of Xen's "deb" target is.
> >>
> >> It is intended as a convenience to developers (and perhaps some subset
> >> of users), to allow them to do a reasonably clean "uninstall" of Xen
> >> installed from source. It is not really intended to provide anything
> >> more than that.
> >>
> >> In particular the packages may not be fully policy compliant and we do
> >> not plan to support things such as upgrades and the like. It also may
> >> well be the case the installing the .deb is not sufficient to get a
> >> working Xen system (i.e. you may still need to do much of the manual
> >> configuration which is needed if you are building from source). If users
> >> want a good, well supported package, well integrated, policy compliant
> >> package for their distro then they should get it from the experts --
> >> i.e. from the distro.
> >>
> >> I'm just concerned that with these patches you may be trying to turn
> >> this simple convenience functionality into something which you think is
> >> suitable for end user consumption, which is something we need to think
> >> carefully about since there is a maintenance (and expectation) burden
> >> imposed by doing that.
> >
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do).  I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
> 
> [Remembering to cc everyone]
> 
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package.  Please do not
> distribute."  Would that make sure no one is confused about the
> resulting package?

tools/misc/mkdeb can inject whatever it likes into the description.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:27:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:27:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMghs-0003eQ-7G; Tue, 24 Apr 2012 14:27:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMghr-0003eJ-5y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:27:03 +0000
Received: from [193.109.254.147:54022] by server-10.bemta-14.messagelabs.com
	id C2/7A-05847-638B69F4; Tue, 24 Apr 2012 14:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335277621!3628526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25700 invoked from network); 24 Apr 2012 14:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:27:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgho-00065u-LK; Tue, 24 Apr 2012 14:27:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgho-0007Yf-KO;
	Tue, 24 Apr 2012 15:27:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.47156.616718.181384@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:27:00 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335276732.4347.155.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> > is now moved elsewhere, as follows:
...
> >  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> >                  { return childw_out->pid >= 0; }
> >  
> > +/* Useable (only) in the child to once more make the ctx useable for
> > + * xenstore operations.
> 
> Specifically "the child" is the middle child of a spawn? Otherwise the
> constraint must be something like "before any threads are created in the
> new process", or something like that?

The fact that raw fork() may be used in the child created by
libxl__ev_child_inuse isn't documented.  It would be possible to
document this but the set of restrictions on the behaviours of the
middle child and any resulting grandchildren are rather complex.

I think it might be better to draw a veil over this and leave it as a
special piece of knowledge implicit in the implementation of
libxl__spawn_*.

In practice the use of _xenstore_reopen in the middle child is fine
provided that the middle child doesn't then fork _and_ then use
libxl's xenstore functions in both the middle child and the
grandchild.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:27:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:27:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMghs-0003eQ-7G; Tue, 24 Apr 2012 14:27:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMghr-0003eJ-5y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:27:03 +0000
Received: from [193.109.254.147:54022] by server-10.bemta-14.messagelabs.com
	id C2/7A-05847-638B69F4; Tue, 24 Apr 2012 14:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335277621!3628526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25700 invoked from network); 24 Apr 2012 14:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:27:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgho-00065u-LK; Tue, 24 Apr 2012 14:27:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgho-0007Yf-KO;
	Tue, 24 Apr 2012 15:27:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.47156.616718.181384@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:27:00 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335276732.4347.155.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> > is now moved elsewhere, as follows:
...
> >  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> >                  { return childw_out->pid >= 0; }
> >  
> > +/* Useable (only) in the child to once more make the ctx useable for
> > + * xenstore operations.
> 
> Specifically "the child" is the middle child of a spawn? Otherwise the
> constraint must be something like "before any threads are created in the
> new process", or something like that?

The fact that raw fork() may be used in the child created by
libxl__ev_child_inuse isn't documented.  It would be possible to
document this but the set of restrictions on the behaviours of the
middle child and any resulting grandchildren are rather complex.

I think it might be better to draw a veil over this and leave it as a
special piece of knowledge implicit in the implementation of
libxl__spawn_*.

In practice the use of _xenstore_reopen in the middle child is fine
provided that the middle child doesn't then fork _and_ then use
libxl's xenstore functions in both the middle child and the
grandchild.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:30:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgl3-0003mk-0b; Tue, 24 Apr 2012 14:30:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgl1-0003ma-5d
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:30:19 +0000
Received: from [85.158.139.83:23142] by server-4.bemta-5.messagelabs.com id
	46/B4-10788-AF8B69F4; Tue, 24 Apr 2012 14:30:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335277817!24748709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9860 invoked from network); 24 Apr 2012 14:30:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:30:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:30:16 +0100
Message-ID: <1335277815.4347.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 24 Apr 2012 15:30:15 +0100
In-Reply-To: <442643696.20120424153049@eikelenboom.it>
References: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
	<442643696.20120424153049@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:30 +0100, Sander Eikelenboom wrote:
> Hello Ian,
> 
> Tuesday, April 24, 2012, 2:53:31 PM, you wrote:
> 
> > Plan for a 4.2 release:
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> 
> > The time line is as follows:
> 
> > 19 March        -- TODO list locked down
> > 2 April         -- Feature Freeze
> >                                                 << WE ARE HERE
> > Mid/Late April  -- First release candidate      << SEE BELOW
> > Weekly          -- RCN+1 until it is ready
> 
> > My initial guesstimate for starting RCs appears to have been somewhat
> > optimistic. I think we need to have reduced at least the blockers lists
> > rather significantly before we start thinking of doing RCs.
> 
> Is there any list/overview as to the state of feature parity between xm/xend and xl/libxl ?

Other than what's included in this list, I don't believe there is at the
moment.

> (both in the sense of commands to xl, as of parsing and building a
> domain from the options specified in a domain .cfg)

Extracting those things for xl is pretty trivial -- the hard thing is
figuring out what options xend has/had, or more importantly which ones
of those people actually use (since we clearly aren't intending to
replicate every feature of xend without reference to the utility of or
demand for those features).

If you can provide a list of xend features which you think are essential
(or even just the subset which you are interested in) then I'd be happy
to correlate it with xl and add the disjunction to the list.

> This week i noticed that someone else noticed that cpu_weight &
> co .cfg options where missing support and provided patches, but these
> seem like pretty basic config options.

I'd say there were not "basic" but they certainly aren't "super
advanced" either.

> This raises the question if there are more pretty basic options still
> missing and in what way will they be handled during the RC's ?

I think we will have to handle that on a case by case basis. Some
(many?) of them will be trivial and will likely be no-brainers to
include at least during the early RCs.

> (since there is a good chance more will pop up when more users start
> testing)
> 
> Are patches for not to exotic and/or invasive options still
> acceptable ?
> Or will they have to wait for a 4.2.1 which could follow up pretty
> short then ?

We'd have to balance their exoticness against their invasiveness and
make a judgement call. Obviously a horribly complex patch for a little
used feature will get a different reception to a simple patch for a
feature which everyone uses...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:30:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgl3-0003mk-0b; Tue, 24 Apr 2012 14:30:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgl1-0003ma-5d
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:30:19 +0000
Received: from [85.158.139.83:23142] by server-4.bemta-5.messagelabs.com id
	46/B4-10788-AF8B69F4; Tue, 24 Apr 2012 14:30:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335277817!24748709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9860 invoked from network); 24 Apr 2012 14:30:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12108848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:30:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:30:16 +0100
Message-ID: <1335277815.4347.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 24 Apr 2012 15:30:15 +0100
In-Reply-To: <442643696.20120424153049@eikelenboom.it>
References: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
	<442643696.20120424153049@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:30 +0100, Sander Eikelenboom wrote:
> Hello Ian,
> 
> Tuesday, April 24, 2012, 2:53:31 PM, you wrote:
> 
> > Plan for a 4.2 release:
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> 
> > The time line is as follows:
> 
> > 19 March        -- TODO list locked down
> > 2 April         -- Feature Freeze
> >                                                 << WE ARE HERE
> > Mid/Late April  -- First release candidate      << SEE BELOW
> > Weekly          -- RCN+1 until it is ready
> 
> > My initial guesstimate for starting RCs appears to have been somewhat
> > optimistic. I think we need to have reduced at least the blockers lists
> > rather significantly before we start thinking of doing RCs.
> 
> Is there any list/overview as to the state of feature parity between xm/xend and xl/libxl ?

Other than what's included in this list, I don't believe there is at the
moment.

> (both in the sense of commands to xl, as of parsing and building a
> domain from the options specified in a domain .cfg)

Extracting those things for xl is pretty trivial -- the hard thing is
figuring out what options xend has/had, or more importantly which ones
of those people actually use (since we clearly aren't intending to
replicate every feature of xend without reference to the utility of or
demand for those features).

If you can provide a list of xend features which you think are essential
(or even just the subset which you are interested in) then I'd be happy
to correlate it with xl and add the disjunction to the list.

> This week i noticed that someone else noticed that cpu_weight &
> co .cfg options where missing support and provided patches, but these
> seem like pretty basic config options.

I'd say there were not "basic" but they certainly aren't "super
advanced" either.

> This raises the question if there are more pretty basic options still
> missing and in what way will they be handled during the RC's ?

I think we will have to handle that on a case by case basis. Some
(many?) of them will be trivial and will likely be no-brainers to
include at least during the early RCs.

> (since there is a good chance more will pop up when more users start
> testing)
> 
> Are patches for not to exotic and/or invasive options still
> acceptable ?
> Or will they have to wait for a 4.2.1 which could follow up pretty
> short then ?

We'd have to balance their exoticness against their invasiveness and
make a judgement call. Obviously a horribly complex patch for a little
used feature will get a different reception to a simple patch for a
feature which everyone uses...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgoA-0003vb-KZ; Tue, 24 Apr 2012 14:33:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMgo8-0003vR-Rt
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:33:33 +0000
Received: from [85.158.138.51:4917] by server-11.bemta-3.messagelabs.com id
	ED/B2-18894-BB9B69F4; Tue, 24 Apr 2012 14:33:31 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335278010!23400638!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8347 invoked from network); 24 Apr 2012 14:33:30 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 14:33:30 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 1C18E1C14001;
	Tue, 24 Apr 2012 16:33:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=NZhhudbAyVZquU19Kfe+fx6pigY=; b=VR
	acVb07PHkderD8MQDp5HJtGRz9eMF97RuTpM0+CCWadqkHWmVfkFDLIfy/Tx4kGV
	o86wjmbsuz8gqBOunWkyiEYzqcgSPqYsAXRWqq25QnDX2d7sgKnVYrQ0DloBPPZL
	DPrXwYvaM7eXaohtxwgNrhZms7l30z3CiiHb1qZA6b4CMkgxG3zzr7XJ5WqbRDbN
	OPQTRWRXypa56ENj7q0Um3IK6Sc/uysDIM3VRCu3OFs7xrPDc/HI81DYrWXX1VyS
	V/XB/68l4EjTusIyk/NcR0S3uoMqC7NU/Cud52UFo3sG/zyqASOtIiOLxy60cGMr
	xgJaWHHDlxxyz34KAvPBWEBgBVHSSbbseC/VQPDjoiThM+d6U7MHNW+8an9O8sNO
	0BGghk+8AheOtbOS6AmhAU6rT+XdXnGqiJrLiyiwgW+Qe/x5mmPv6sp6MYg9/2kN
	NvV93zOqduMuWlV0eVW8lYQjWZssWnMsVYeF7pQeMe0p+/rjLnypy4DrvPk1KvCp
	S49qxFsadjSg9+wu93FFLUrg/B9voMoB9fITe07crc6n/2zvzo7cREPm01IhVmgJ
	DSOwOW1hMaJIRKsPuayGEj7ETP/9yCLtpxhUIeOgWnnVFLNTLmBALlxbS18Jy5PB
	n7k+F3a8BPbOEOzULA79d97IrEcugOwCxbN9jeGo8=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id DFC8D1C14002; Tue, 24 Apr 2012 16:33:29 +0200 (CEST)
Date: Tue, 24 Apr 2012 16:33:29 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120424143329.GB19331@bloms.de>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="XMCwj5IQnwKtuyBG"
Content-Disposition: inline
In-Reply-To: <1335272980.4347.122.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--XMCwj5IQnwKtuyBG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Apr 24, Ian Campbell wrote:

> I think you mean cpu_weight rather than cpu-weight.

yes of course, fixed.

> =3Ditem B<latency=3DN>
>=20
> I think you missed the value here.

I don't know the value for it, so I added N as you suggested.

> > +    ("us", KeyedUnion(None, libxl_scheduler, "sched",
> > +                 [("credit", libxl_sched_credit_domain),
> > +                 ("credit2", libxl_sched_credit2_domain),
> > +                 ("sedf", libxl_sched_sedf_domain),
> > +                 ("arinc653", libxl_sched_arinc653_domain),
> > +                 ], keyvar_init_val =3D "-1")),
>=20
> I don't think a KeyedUnion is right here, since the user of libxl
> doesn't really have a choice about which scheduler is in user (that's
> set at boot time or via cpupool interfaces).
>=20
> You could use a Union, but below I'll make an argument that perhaps a
> Struct would be better.

Hm, but when I don't use a union with the structure for each scheduler I
have to create a structure depend of scheduler at runtime, because the
functions libxl_sched_XXXXXX_domain_set use there own structure for
their scheduler.

I've create a new function libxl__sched_set_params, which set the params
depend on the scheduler as you suggested.

I'am not a software developer, so please be forbear with me.

Here my next try.

--=20
Best regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--XMCwj5IQnwKtuyBG
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"
Content-Transfer-Encoding: quoted-printable

libxl: set domain scheduling parameters while creating the dom

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index e2cd251..b0c8064 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use. Defaul=
t behavior is
 (all vcpus will run on cpus 0,2,3,5), or `cpus=3D["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
=20
+=3Ditem B<cpu_weight=3DWEIGHT>
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host.
+Legal weights range from 1 to 65535 and the default is 256.
+Can be set for credit, credit2 and sedf scheduler.
+
+=3Ditem B<cap=3DN>
+
+The cap optionally fixes the maximum amount of CPU a domain will be
+able to consume, even if the host system has idle CPU cycles.
+The cap is expressed in percentage of one physical CPU:
+100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc.
+The default, 0, means there is no upper cap.
+Can be set for the credit and credit2 scheduler.
+
+=3Ditem B<period=3DNANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. This means every period
+the domain gets cpu time defined in slice.
+Can be set for sedf scheduler.
+
+=3Ditem B<slice=3DNANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. it defines the time=20
+a domain get every period time.
+Can be set for sedf scheduler.
+
+=3Ditem B<latency=3DN>
+
+Scaled period if domain is doing heavy I/O.
+Can be set for sedf scheduler.
+
+=3Ditem B<extratime=3DBOOLEAN>
+
+Flag for allowing domain to run in extra time.
+Can be set for sedf scheduler.
+
 =3Ditem B<memory=3DMBYTES>
=20
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..654da78 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -42,6 +42,33 @@ libxl_domain_type libxl__domain_type(libxl__gc *gc, uint=
32_t domid)
         return LIBXL_DOMAIN_TYPE_PV;
 }
=20
+int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_domain_bu=
ild_info *info)
+{
+    libxl_ctx *ctx =3D libxl__gc_owner(gc);
+    libxl_scheduler sched;
+    int ret;
+
+    sched =3D libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      ret=3Dlibxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      ret=3Dlibxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      ret=3Dlibxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2)=
);
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      ret=3D0;
+      break;
+    default:
+      ret=3D-1;
+    }
+    return ret;
+}
+
 int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
@@ -126,6 +153,8 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents, **hvm_ents;
     int i;
=20
+    libxl__sched_set_params (gc, domid, info);
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid !=3D NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..bfcdff4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -617,6 +617,7 @@ int libxl__atfork_init(libxl_ctx *ctx);
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid=
);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_d=
omain_build_info *info);
 #define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
     libxl__domain_type((gc), (domid)) =3D=3D LIBXL_DOMAIN_TYPE_##type
 typedef struct {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..c1cdc3c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,27 @@ libxl_domain_create_info =3D Struct("domain_create_inf=
o",[
=20
 MemKB =3D UInt(64, init_val =3D "LIBXL_MEMKB_DEFAULT")
=20
+libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain =3D Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +277,13 @@ libxl_domain_build_info =3D Struct("domain_build_info"=
,[
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
=20
+    ("us", KeyedUnion(None, libxl_scheduler, "sched",
+                 [("credit", libxl_sched_credit_domain),
+                 ("credit2", libxl_sched_credit2_domain),
+                 ("sedf", libxl_sched_sedf_domain),
+                 ("arinc653", libxl_sched_arinc653_domain),
+                 ], keyvar_init_val =3D "-1")),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_typ=
e),
@@ -417,28 +445,12 @@ libxl_cputopology =3D Struct("cputopology", [
     ("node", uint32),
     ], dir=3DDIR_OUT)
=20
-libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
=20
 libxl_sched_credit_params =3D Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
     ], dispose_fn=3DNone)
=20
-libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type =3D Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..811f1ac 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,24 @@ static void parse_config_data(const char *configfile_f=
ilename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
=20
     /* the following is the actual config parsing with overriding values i=
n the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) {
+        b_info->us.credit.weight =3D l;
+        b_info->us.credit2.weight =3D l;
+        b_info->us.sedf.weight =3D l;
+    }
+
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->us.credit.cap =3D l;
+
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->us.sedf.period =3D l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus =3D l;
         b_info->cur_vcpus =3D (1 << l) - 1;

--XMCwj5IQnwKtuyBG
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--XMCwj5IQnwKtuyBG--


From xen-devel-bounces@lists.xen.org Tue Apr 24 14:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgoA-0003vb-KZ; Tue, 24 Apr 2012 14:33:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMgo8-0003vR-Rt
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:33:33 +0000
Received: from [85.158.138.51:4917] by server-11.bemta-3.messagelabs.com id
	ED/B2-18894-BB9B69F4; Tue, 24 Apr 2012 14:33:31 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335278010!23400638!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8347 invoked from network); 24 Apr 2012 14:33:30 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 14:33:30 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 1C18E1C14001;
	Tue, 24 Apr 2012 16:33:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=NZhhudbAyVZquU19Kfe+fx6pigY=; b=VR
	acVb07PHkderD8MQDp5HJtGRz9eMF97RuTpM0+CCWadqkHWmVfkFDLIfy/Tx4kGV
	o86wjmbsuz8gqBOunWkyiEYzqcgSPqYsAXRWqq25QnDX2d7sgKnVYrQ0DloBPPZL
	DPrXwYvaM7eXaohtxwgNrhZms7l30z3CiiHb1qZA6b4CMkgxG3zzr7XJ5WqbRDbN
	OPQTRWRXypa56ENj7q0Um3IK6Sc/uysDIM3VRCu3OFs7xrPDc/HI81DYrWXX1VyS
	V/XB/68l4EjTusIyk/NcR0S3uoMqC7NU/Cud52UFo3sG/zyqASOtIiOLxy60cGMr
	xgJaWHHDlxxyz34KAvPBWEBgBVHSSbbseC/VQPDjoiThM+d6U7MHNW+8an9O8sNO
	0BGghk+8AheOtbOS6AmhAU6rT+XdXnGqiJrLiyiwgW+Qe/x5mmPv6sp6MYg9/2kN
	NvV93zOqduMuWlV0eVW8lYQjWZssWnMsVYeF7pQeMe0p+/rjLnypy4DrvPk1KvCp
	S49qxFsadjSg9+wu93FFLUrg/B9voMoB9fITe07crc6n/2zvzo7cREPm01IhVmgJ
	DSOwOW1hMaJIRKsPuayGEj7ETP/9yCLtpxhUIeOgWnnVFLNTLmBALlxbS18Jy5PB
	n7k+F3a8BPbOEOzULA79d97IrEcugOwCxbN9jeGo8=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id DFC8D1C14002; Tue, 24 Apr 2012 16:33:29 +0200 (CEST)
Date: Tue, 24 Apr 2012 16:33:29 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120424143329.GB19331@bloms.de>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="XMCwj5IQnwKtuyBG"
Content-Disposition: inline
In-Reply-To: <1335272980.4347.122.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--XMCwj5IQnwKtuyBG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Apr 24, Ian Campbell wrote:

> I think you mean cpu_weight rather than cpu-weight.

yes of course, fixed.

> =3Ditem B<latency=3DN>
>=20
> I think you missed the value here.

I don't know the value for it, so I added N as you suggested.

> > +    ("us", KeyedUnion(None, libxl_scheduler, "sched",
> > +                 [("credit", libxl_sched_credit_domain),
> > +                 ("credit2", libxl_sched_credit2_domain),
> > +                 ("sedf", libxl_sched_sedf_domain),
> > +                 ("arinc653", libxl_sched_arinc653_domain),
> > +                 ], keyvar_init_val =3D "-1")),
>=20
> I don't think a KeyedUnion is right here, since the user of libxl
> doesn't really have a choice about which scheduler is in user (that's
> set at boot time or via cpupool interfaces).
>=20
> You could use a Union, but below I'll make an argument that perhaps a
> Struct would be better.

Hm, but when I don't use a union with the structure for each scheduler I
have to create a structure depend of scheduler at runtime, because the
functions libxl_sched_XXXXXX_domain_set use there own structure for
their scheduler.

I've create a new function libxl__sched_set_params, which set the params
depend on the scheduler as you suggested.

I'am not a software developer, so please be forbear with me.

Here my next try.

--=20
Best regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--XMCwj5IQnwKtuyBG
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"
Content-Transfer-Encoding: quoted-printable

libxl: set domain scheduling parameters while creating the dom

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index e2cd251..b0c8064 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use. Defaul=
t behavior is
 (all vcpus will run on cpus 0,2,3,5), or `cpus=3D["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
=20
+=3Ditem B<cpu_weight=3DWEIGHT>
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host.
+Legal weights range from 1 to 65535 and the default is 256.
+Can be set for credit, credit2 and sedf scheduler.
+
+=3Ditem B<cap=3DN>
+
+The cap optionally fixes the maximum amount of CPU a domain will be
+able to consume, even if the host system has idle CPU cycles.
+The cap is expressed in percentage of one physical CPU:
+100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc.
+The default, 0, means there is no upper cap.
+Can be set for the credit and credit2 scheduler.
+
+=3Ditem B<period=3DNANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. This means every period
+the domain gets cpu time defined in slice.
+Can be set for sedf scheduler.
+
+=3Ditem B<slice=3DNANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. it defines the time=20
+a domain get every period time.
+Can be set for sedf scheduler.
+
+=3Ditem B<latency=3DN>
+
+Scaled period if domain is doing heavy I/O.
+Can be set for sedf scheduler.
+
+=3Ditem B<extratime=3DBOOLEAN>
+
+Flag for allowing domain to run in extra time.
+Can be set for sedf scheduler.
+
 =3Ditem B<memory=3DMBYTES>
=20
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..654da78 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -42,6 +42,33 @@ libxl_domain_type libxl__domain_type(libxl__gc *gc, uint=
32_t domid)
         return LIBXL_DOMAIN_TYPE_PV;
 }
=20
+int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_domain_bu=
ild_info *info)
+{
+    libxl_ctx *ctx =3D libxl__gc_owner(gc);
+    libxl_scheduler sched;
+    int ret;
+
+    sched =3D libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      ret=3Dlibxl_sched_sedf_domain_set(ctx, domid, &(info->us.sedf));
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      ret=3Dlibxl_sched_credit_domain_set(ctx, domid, &(info->us.credit));
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      ret=3Dlibxl_sched_credit2_domain_set(ctx, domid, &(info->us.credit2)=
);
+      break;
+    case LIBXL_SCHEDULER_ARINC653:
+      /* not implemented */
+      ret=3D0;
+      break;
+    default:
+      ret=3D-1;
+    }
+    return ret;
+}
+
 int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
@@ -126,6 +153,8 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents, **hvm_ents;
     int i;
=20
+    libxl__sched_set_params (gc, domid, info);
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid !=3D NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..bfcdff4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -617,6 +617,7 @@ int libxl__atfork_init(libxl_ctx *ctx);
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid=
);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_d=
omain_build_info *info);
 #define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
     libxl__domain_type((gc), (domid)) =3D=3D LIBXL_DOMAIN_TYPE_##type
 typedef struct {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..c1cdc3c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,27 @@ libxl_domain_create_info =3D Struct("domain_create_inf=
o",[
=20
 MemKB =3D UInt(64, init_val =3D "LIBXL_MEMKB_DEFAULT")
=20
+libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain =3D Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +277,13 @@ libxl_domain_build_info =3D Struct("domain_build_info"=
,[
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
=20
+    ("us", KeyedUnion(None, libxl_scheduler, "sched",
+                 [("credit", libxl_sched_credit_domain),
+                 ("credit2", libxl_sched_credit2_domain),
+                 ("sedf", libxl_sched_sedf_domain),
+                 ("arinc653", libxl_sched_arinc653_domain),
+                 ], keyvar_init_val =3D "-1")),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_typ=
e),
@@ -417,28 +445,12 @@ libxl_cputopology =3D Struct("cputopology", [
     ("node", uint32),
     ], dir=3DDIR_OUT)
=20
-libxl_sched_credit_domain =3D Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
=20
 libxl_sched_credit_params =3D Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
     ], dispose_fn=3DNone)
=20
-libxl_sched_credit2_domain =3D Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain =3D Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type =3D Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..811f1ac 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,24 @@ static void parse_config_data(const char *configfile_f=
ilename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
=20
     /* the following is the actual config parsing with overriding values i=
n the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) {
+        b_info->us.credit.weight =3D l;
+        b_info->us.credit2.weight =3D l;
+        b_info->us.sedf.weight =3D l;
+    }
+
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->us.credit.cap =3D l;
+
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->us.sedf.period =3D l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->us.sedf.period =3D l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus =3D l;
         b_info->cur_vcpus =3D (1 << l) - 1;

--XMCwj5IQnwKtuyBG
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--XMCwj5IQnwKtuyBG--


From xen-devel-bounces@lists.xen.org Tue Apr 24 14:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgpl-00041Q-8z; Tue, 24 Apr 2012 14:35:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMgpj-00041G-Hw
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:35:11 +0000
Received: from [193.109.254.147:63026] by server-6.bemta-14.messagelabs.com id
	8C/BD-02047-E1AB69F4; Tue, 24 Apr 2012 14:35:10 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335278105!6068736!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2344 invoked from network); 24 Apr 2012 14:35:07 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 14:35:07 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 299C91020F354;
	Tue, 24 Apr 2012 07:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id kQoWCH_KhyEd; Tue, 24 Apr 2012 07:35:04 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id EDAF71020F352;
	Tue, 24 Apr 2012 07:35:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 07:35:03 -0700
Message-Id: <FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4004715053443085720=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4004715053443085720==
Content-Type: multipart/alternative; boundary="Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93"


--Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 6:02 AM, Stefano Stabellini wrote:

> According to xenstore the console is connected for both domains and =
you
> should be able to access them using /dev/pts/2 and /dev/pts/3.
> The only issue I can see is that the disk for "finnix" is not
> connected. Maybe an disk open error?

Sure enough, you are right in both cases.   Connecting to the pty with =
screen gives me access to the console.  =20

domutest is an archlinux instance which is using a LVM partition appears =
to work.   The finnix domU is using an ISO file and it does not appear =
to find it on boot up and I can't force it to find it, so running "xl =
create" doesn't work in that mode as well as I thought it had.     =
Running it with xend/xm, it works fine

Anything I should be looking at next?

-Sam=

--Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 6:02 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">According to =
xenstore the console is connected for both domains and you<br>should be =
able to access them using /dev/pts/2 and /dev/pts/3.<br>The only issue I =
can see is that the disk for "finnix" is not<br>connected. Maybe an disk =
open error?</span></blockquote><br></div><div>Sure enough, you are right =
in both cases. &nbsp; Connecting to the pty with screen gives me access =
to the console. &nbsp;&nbsp;</div><div><br></div><div>domutest is an =
archlinux instance which is using a LVM partition appears to work. =
&nbsp; The finnix domU is using an ISO file and it does not appear to =
find it on boot up and I can't force it to find it, so running "xl =
create" doesn't work in that mode as well as I thought it had. &nbsp; =
&nbsp; Running it with xend/xm, it works =
fine</div><div><br></div><div>Anything I should be looking at =
next?</div><div><br></div><div>-Sam</div></body></html>=

--Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93--


--===============4004715053443085720==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4004715053443085720==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 14:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgpl-00041Q-8z; Tue, 24 Apr 2012 14:35:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMgpj-00041G-Hw
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:35:11 +0000
Received: from [193.109.254.147:63026] by server-6.bemta-14.messagelabs.com id
	8C/BD-02047-E1AB69F4; Tue, 24 Apr 2012 14:35:10 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335278105!6068736!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2344 invoked from network); 24 Apr 2012 14:35:07 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 14:35:07 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 299C91020F354;
	Tue, 24 Apr 2012 07:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id kQoWCH_KhyEd; Tue, 24 Apr 2012 07:35:04 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id EDAF71020F352;
	Tue, 24 Apr 2012 07:35:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 07:35:03 -0700
Message-Id: <FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4004715053443085720=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4004715053443085720==
Content-Type: multipart/alternative; boundary="Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93"


--Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 6:02 AM, Stefano Stabellini wrote:

> According to xenstore the console is connected for both domains and =
you
> should be able to access them using /dev/pts/2 and /dev/pts/3.
> The only issue I can see is that the disk for "finnix" is not
> connected. Maybe an disk open error?

Sure enough, you are right in both cases.   Connecting to the pty with =
screen gives me access to the console.  =20

domutest is an archlinux instance which is using a LVM partition appears =
to work.   The finnix domU is using an ISO file and it does not appear =
to find it on boot up and I can't force it to find it, so running "xl =
create" doesn't work in that mode as well as I thought it had.     =
Running it with xend/xm, it works fine

Anything I should be looking at next?

-Sam=

--Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 6:02 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">According to =
xenstore the console is connected for both domains and you<br>should be =
able to access them using /dev/pts/2 and /dev/pts/3.<br>The only issue I =
can see is that the disk for "finnix" is not<br>connected. Maybe an disk =
open error?</span></blockquote><br></div><div>Sure enough, you are right =
in both cases. &nbsp; Connecting to the pty with screen gives me access =
to the console. &nbsp;&nbsp;</div><div><br></div><div>domutest is an =
archlinux instance which is using a LVM partition appears to work. =
&nbsp; The finnix domU is using an ISO file and it does not appear to =
find it on boot up and I can't force it to find it, so running "xl =
create" doesn't work in that mode as well as I thought it had. &nbsp; =
&nbsp; Running it with xend/xm, it works =
fine</div><div><br></div><div>Anything I should be looking at =
next?</div><div><br></div><div>-Sam</div></body></html>=

--Apple-Mail=_EB56DAFB-A482-465F-84AE-06CDFCC05B93--


--===============4004715053443085720==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4004715053443085720==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 14:39:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:39:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgth-0004EO-5n; Tue, 24 Apr 2012 14:39:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMgtf-0004EI-73
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:39:15 +0000
Received: from [85.158.139.83:40970] by server-2.bemta-5.messagelabs.com id
	20/CF-17016-21BB69F4; Tue, 24 Apr 2012 14:39:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335278352!25202373!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14813 invoked from network); 24 Apr 2012 14:39:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Apr 2012 14:39:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMgtc-000858-4l
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 07:39:12 -0700
Date: Tue, 24 Apr 2012 07:39:12 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335278352136-5662227.post@n5.nabble.com>
In-Reply-To: <20374.42858.598595.230007@mariner.uk.xensource.com>
References: <4F954422.1010803@tiscali.it>
	<20374.42858.598595.230007@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Jackson-2 wrote
> 
> Fabio Fantoni writes ("[Xen-devel] [PATCH] tools: Improve make deb"):
>> tools: Improve make deb
> 
> I'm rather unconvinced by this, in general.  The logical conclusion
> would be for us to end up with machinery which attempts to make a
> fully featured package.  I think this task is best left to a distro.
> 
> The "make deb" target is there to provide something convenient for
> development and testing.
> 
> On to the individual changes:
> 
>> - Remove version from installed package name
> 
> Why ?
> 
>> - Add conffiles to manage main config files on package update
> 
> I would be inclined to take this if it were presented on its own.  The
> effect can be useful during testing, and a dpkg purge will easily undo
> it.
> 
>> - Add/remove of main services (xencommons, xendomains)
> 
> I think this is a bad idea, for the reasons I explain above.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
Yes, I know it's for development and testing, these small changes are
significant help.
The most important thing and that certainly no one would object to which the
management of configuration files, mantain configurations changes and report
any changes on the basic config do in development.
About package name it is correct to remove version from it, as is already on
his dedicated field and the creation of deb takes care of everything.
If version is mantained on package name any new version of the same package
will be treathed as differente one (not different version).
About services I added only basic, not all, I thought it was a good idea but
if not I will remove it

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-Improve-make-deb-tp5659234p5662227.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:39:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:39:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgth-0004EO-5n; Tue, 24 Apr 2012 14:39:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMgtf-0004EI-73
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:39:15 +0000
Received: from [85.158.139.83:40970] by server-2.bemta-5.messagelabs.com id
	20/CF-17016-21BB69F4; Tue, 24 Apr 2012 14:39:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335278352!25202373!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14813 invoked from network); 24 Apr 2012 14:39:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Apr 2012 14:39:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SMgtc-000858-4l
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 07:39:12 -0700
Date: Tue, 24 Apr 2012 07:39:12 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335278352136-5662227.post@n5.nabble.com>
In-Reply-To: <20374.42858.598595.230007@mariner.uk.xensource.com>
References: <4F954422.1010803@tiscali.it>
	<20374.42858.598595.230007@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Jackson-2 wrote
> 
> Fabio Fantoni writes ("[Xen-devel] [PATCH] tools: Improve make deb"):
>> tools: Improve make deb
> 
> I'm rather unconvinced by this, in general.  The logical conclusion
> would be for us to end up with machinery which attempts to make a
> fully featured package.  I think this task is best left to a distro.
> 
> The "make deb" target is there to provide something convenient for
> development and testing.
> 
> On to the individual changes:
> 
>> - Remove version from installed package name
> 
> Why ?
> 
>> - Add conffiles to manage main config files on package update
> 
> I would be inclined to take this if it were presented on its own.  The
> effect can be useful during testing, and a dpkg purge will easily undo
> it.
> 
>> - Add/remove of main services (xencommons, xendomains)
> 
> I think this is a bad idea, for the reasons I explain above.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
Yes, I know it's for development and testing, these small changes are
significant help.
The most important thing and that certainly no one would object to which the
management of configuration files, mantain configurations changes and report
any changes on the basic config do in development.
About package name it is correct to remove version from it, as is already on
his dedicated field and the creation of deb takes care of everything.
If version is mantained on package name any new version of the same package
will be treathed as differente one (not different version).
About services I added only basic, not all, I thought it was a good idea but
if not I will remove it

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-Improve-make-deb-tp5659234p5662227.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:39:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgtt-0004Fk-Ih; Tue, 24 Apr 2012 14:39:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMgts-0004FD-24
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:39:28 +0000
Received: from [85.158.138.51:32743] by server-6.bemta-3.messagelabs.com id
	6B/7D-05145-F1BB69F4; Tue, 24 Apr 2012 14:39:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335278366!23538754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2775 invoked from network); 24 Apr 2012 14:39:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:39:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:38:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:38:52 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgtI-00069z-PQ; Tue, 24 Apr 2012 14:38:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgtI-0007bP-OU;
	Tue, 24 Apr 2012 15:38:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.47868.746605.101511@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:38:52 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335277100.4347.159.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
	<1335277100.4347.159.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation when domain dioes"):
> > +        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
> > +                              " for domain deatch check", errno, 0);
> 
>                                               detach

Fixed.

> > +int libxl__domaindeathcheck_start(libxl__gc *gc,
> > +                                  libxl__domaindeathcheck *dc)
> > +{
> > +    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
> > +    return libxl__ev_xswatch_register(gc, &dc->watch,
> > +                                      domaindeathcheck_callback, path);
> 
> So we are watching for the toolstack (possibly the same one as we are
> running in) to destroy the domain and therefore nuke the xs directory --
> does that actually work?

Yes.  And, yes.

> Specifically in the case of xl running the bootloader -- is xl in any
> position to handle a domain death during domain build? Isn't it doing
> the create synchronously?

The copy of xl which is trying to create the domain is indeed not
capable of initiating destruction.  But another copy of xl might
destroy the domain.

In my tests I found that if one runs, in one window, "xl create -c",
and then when that command is sat at the bootloader prompt (which
might be indefinitely), runs "xl destroy <name of guest>", before my
patch the xl create continues to sit and wait for the bootloader.  (If
the bootloader is then told to continue, the xl create will of course
bomb out since its domain has vanished.)

This is bad not just because it is poor UX, but also because after "xl
destroy" it ought to be possible to run "xl create" without any
difficulty - however the bootloader from the previous incarnation
still has the disk open.  It's also bad because it leaks the
bootloader until the bootloader times out (which might be
indefinitely).

After applying my patch, running "xl destroy" while the create is
waiting for the bootloader causes the creation to be immediately
aborted, as one would hope.

> Wouldn't using the @releaseDomain watch be more reliable?

It would be more complicated.  We don't have a general internal-facing
facility for "has this domain been destroyed", and turning
@releaseDomain watch events into information about specific domains is
complicated because the @releaseDomain event doesn't contain the
domid.

And it is not necessary because, if the domain is destroyed then
either (a) the entries in xenstore have already been deleted, in which
case the test here works or (b) they have not in which case something
has gone very badly wrong and we are going to leak those xenstore
entries, in which case trying to avoid leaking other stuff seems
futile.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:39:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgtt-0004Fk-Ih; Tue, 24 Apr 2012 14:39:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMgts-0004FD-24
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:39:28 +0000
Received: from [85.158.138.51:32743] by server-6.bemta-3.messagelabs.com id
	6B/7D-05145-F1BB69F4; Tue, 24 Apr 2012 14:39:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335278366!23538754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2775 invoked from network); 24 Apr 2012 14:39:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:39:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:38:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:38:52 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMgtI-00069z-PQ; Tue, 24 Apr 2012 14:38:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMgtI-0007bP-OU;
	Tue, 24 Apr 2012 15:38:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.47868.746605.101511@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:38:52 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335277100.4347.159.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
	<1335277100.4347.159.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation when domain dioes"):
> > +        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
> > +                              " for domain deatch check", errno, 0);
> 
>                                               detach

Fixed.

> > +int libxl__domaindeathcheck_start(libxl__gc *gc,
> > +                                  libxl__domaindeathcheck *dc)
> > +{
> > +    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
> > +    return libxl__ev_xswatch_register(gc, &dc->watch,
> > +                                      domaindeathcheck_callback, path);
> 
> So we are watching for the toolstack (possibly the same one as we are
> running in) to destroy the domain and therefore nuke the xs directory --
> does that actually work?

Yes.  And, yes.

> Specifically in the case of xl running the bootloader -- is xl in any
> position to handle a domain death during domain build? Isn't it doing
> the create synchronously?

The copy of xl which is trying to create the domain is indeed not
capable of initiating destruction.  But another copy of xl might
destroy the domain.

In my tests I found that if one runs, in one window, "xl create -c",
and then when that command is sat at the bootloader prompt (which
might be indefinitely), runs "xl destroy <name of guest>", before my
patch the xl create continues to sit and wait for the bootloader.  (If
the bootloader is then told to continue, the xl create will of course
bomb out since its domain has vanished.)

This is bad not just because it is poor UX, but also because after "xl
destroy" it ought to be possible to run "xl create" without any
difficulty - however the bootloader from the previous incarnation
still has the disk open.  It's also bad because it leaks the
bootloader until the bootloader times out (which might be
indefinitely).

After applying my patch, running "xl destroy" while the create is
waiting for the bootloader causes the creation to be immediately
aborted, as one would hope.

> Wouldn't using the @releaseDomain watch be more reliable?

It would be more complicated.  We don't have a general internal-facing
facility for "has this domain been destroyed", and turning
@releaseDomain watch events into information about specific domains is
complicated because the @releaseDomain event doesn't contain the
domid.

And it is not necessary because, if the domain is destroyed then
either (a) the entries in xenstore have already been deleted, in which
case the test here works or (b) they have not in which case something
has gone very badly wrong and we are going to leak those xenstore
entries, in which case trying to avoid leaking other stuff seems
futile.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgvA-0004Rg-9v; Tue, 24 Apr 2012 14:40:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgv9-0004RS-6W
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:40:47 +0000
Received: from [193.109.254.147:18657] by server-1.bemta-14.messagelabs.com id
	28/4A-29372-E6BB69F4; Tue, 24 Apr 2012 14:40:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335278442!6087629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9419 invoked from network); 24 Apr 2012 14:40:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:40:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:40:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:40:41 +0100
Message-ID: <1335278440.4347.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:40:40 +0100
In-Reply-To: <20374.43998.471725.415493@mariner.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:34 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> > On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> > > Can we somehow limit this to commands that actually change things ?
> > > Having xl as a diagnostic tool even for xend-based systems is useful.
> > 
> > Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
> 
> Yes, something like that.
> 
> > > > +        if (!access(locks[i], F_OK) && !force_execution) {
> > > > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > > > +                            "correctly. If you still want to force the "
> > > > +                            "execution of xl please use the -f option\n");
> > > > +            exit(2);
> > > > +        }
> > > 
> > > If access fails with an unexpected error code (EACCES? EIO?) this will
> > > blunder on.
> > 
> > It'll fail whether the error code is expected or not, won't it?
> 
> I think if access fails with EIO, it will return -1, and the if
> condition will not be satisfied (!-1 = 0), so the fprintf and exit
> will not be taken.

Oh, I was confused because the "good" case here is actually that access
fails...

You could consider this to be a best effort check for xend. IOW we try
and look but if we can't tell then we assume it is not.

It's not terribly robust to just blunder on, but on the other hand being
more robust has a bigger risk of false positives, e.g. failing to start
xl because /var/lock/subsys/ does not exist isn't especially helpful
either (the EACCESS return code doesn't distinguish that
from /var/lock/subsys/xend not existing).

If you are getting EIO or something like that then that's a problem, but
arguably not one which is especially related to whether xend is running
or not and you are bound to get another later on.

You could do a bunch more complex checking (e.g. check the base
directory first) but it seems like overkill for what is supposed to be a
simply sanity check.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgvA-0004Rg-9v; Tue, 24 Apr 2012 14:40:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgv9-0004RS-6W
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:40:47 +0000
Received: from [193.109.254.147:18657] by server-1.bemta-14.messagelabs.com id
	28/4A-29372-E6BB69F4; Tue, 24 Apr 2012 14:40:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335278442!6087629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9419 invoked from network); 24 Apr 2012 14:40:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:40:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:40:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:40:41 +0100
Message-ID: <1335278440.4347.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:40:40 +0100
In-Reply-To: <20374.43998.471725.415493@mariner.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:34 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> > On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> > > Can we somehow limit this to commands that actually change things ?
> > > Having xl as a diagnostic tool even for xend-based systems is useful.
> > 
> > Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
> 
> Yes, something like that.
> 
> > > > +        if (!access(locks[i], F_OK) && !force_execution) {
> > > > +            fprintf(stderr, "xend is running, which prevents xl from working "
> > > > +                            "correctly. If you still want to force the "
> > > > +                            "execution of xl please use the -f option\n");
> > > > +            exit(2);
> > > > +        }
> > > 
> > > If access fails with an unexpected error code (EACCES? EIO?) this will
> > > blunder on.
> > 
> > It'll fail whether the error code is expected or not, won't it?
> 
> I think if access fails with EIO, it will return -1, and the if
> condition will not be satisfied (!-1 = 0), so the fprintf and exit
> will not be taken.

Oh, I was confused because the "good" case here is actually that access
fails...

You could consider this to be a best effort check for xend. IOW we try
and look but if we can't tell then we assume it is not.

It's not terribly robust to just blunder on, but on the other hand being
more robust has a bigger risk of false positives, e.g. failing to start
xl because /var/lock/subsys/ does not exist isn't especially helpful
either (the EACCESS return code doesn't distinguish that
from /var/lock/subsys/xend not existing).

If you are getting EIO or something like that then that's a problem, but
arguably not one which is especially related to whether xend is running
or not and you are bound to get another later on.

You could do a bunch more complex checking (e.g. check the base
directory first) but it seems like overkill for what is supposed to be a
simply sanity check.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:43:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:43:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgxK-0004h8-RS; Tue, 24 Apr 2012 14:43:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgxI-0004gu-Sf
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:43:01 +0000
Received: from [193.109.254.147:30804] by server-11.bemta-14.messagelabs.com
	id 8E/B9-05858-4FBB69F4; Tue, 24 Apr 2012 14:43:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335278579!6070321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23623 invoked from network); 24 Apr 2012 14:42:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:42:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:42:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:42:59 +0100
Message-ID: <1335278578.4347.181.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:42:58 +0100
In-Reply-To: <20374.44450.870790.881237@mariner.uk.xensource.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
	<1334747100.23948.202.camel@zakaz.uk.xensource.com>
	<20374.44450.870790.881237@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> > I'm tempted to suggest that we remove this support -- having plain text
> > passwords in xenstore (thankfully with perms set somewhat sanely) just
> > doesn't seem like a Good Thing to me...
> 
> It isn't a good thing.  But currently we have the following three
> options:
> 
> (a) allow access to anyone who can reach the vnc server's TCP port;
> 
> (b) make noninteractive invocation of vnc clients (including
>     screenshot utilities, and automatic invocation of the client
>     by xl) impossible;
> 
> (c) put a plaintext password in the config file (or the xl/xm
>     command line) and copy it to xenstore.
> 
> I don't think we should abolish (c) until we have another way of
> avoiding the problems of (a) and (b).

Fair enough.

I should revisit my vnc TLS patches (with client cert support) for 4.3.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:43:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:43:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgxK-0004h8-RS; Tue, 24 Apr 2012 14:43:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMgxI-0004gu-Sf
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:43:01 +0000
Received: from [193.109.254.147:30804] by server-11.bemta-14.messagelabs.com
	id 8E/B9-05858-4FBB69F4; Tue, 24 Apr 2012 14:43:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335278579!6070321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23623 invoked from network); 24 Apr 2012 14:42:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:42:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:42:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:42:59 +0100
Message-ID: <1335278578.4347.181.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:42:58 +0100
In-Reply-To: <20374.44450.870790.881237@mariner.uk.xensource.com>
References: <1334600151-22282-1-git-send-email-anthony.perard@citrix.com>
	<1334676652.23948.112.camel@zakaz.uk.xensource.com>
	<4F8D902A.2080607@citrix.com>
	<1334747100.23948.202.camel@zakaz.uk.xensource.com>
	<20374.44450.870790.881237@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 14:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Query VNC listening port through QMP"):
> > I'm tempted to suggest that we remove this support -- having plain text
> > passwords in xenstore (thankfully with perms set somewhat sanely) just
> > doesn't seem like a Good Thing to me...
> 
> It isn't a good thing.  But currently we have the following three
> options:
> 
> (a) allow access to anyone who can reach the vnc server's TCP port;
> 
> (b) make noninteractive invocation of vnc clients (including
>     screenshot utilities, and automatic invocation of the client
>     by xl) impossible;
> 
> (c) put a plaintext password in the config file (or the xl/xm
>     command line) and copy it to xenstore.
> 
> I don't think we should abolish (c) until we have another way of
> avoiding the problems of (a) and (b).

Fair enough.

I should revisit my vnc TLS patches (with client cert support) for 4.3.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgyh-0004pE-Bd; Tue, 24 Apr 2012 14:44:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SMgyf-0004p5-HE
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:44:25 +0000
Received: from [193.109.254.147:60084] by server-6.bemta-14.messagelabs.com id
	00/B5-02047-84CB69F4; Tue, 24 Apr 2012 14:44:24 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335278655!6070590!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28813 invoked from network); 24 Apr 2012 14:44:16 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-16.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 14:44:16 -0000
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com
	[209.85.216.50]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 05B64DBC50
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 22:43:56 +0800 (CST)
Received: by qafl39 with SMTP id l39so136602qaf.9
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 07:43:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.111.74 with SMTP id r10mr5118701qcp.122.1335278633215;
	Tue, 24 Apr 2012 07:43:53 -0700 (PDT)
Received: by 10.229.68.170 with HTTP; Tue, 24 Apr 2012 07:43:53 -0700 (PDT)
In-Reply-To: <20120423151123.GC24481@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
Date: Tue, 24 Apr 2012 22:43:53 +0800
Message-ID: <CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 11:11 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> >> > How about return -1 on error?
>> >> > The calling function can check -1 for error.
>> >>
>> >> Isn't -1 potentially (at least theoretically) a valid value to read f=
rom
>> >> one of these registers?
>> >
>> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
>> >
>> > Perhaps the fallback is to emulate (so retain some of the original cod=
e)
>> > as we have been since .. uh 3.0?
>>
>> Do you mean the return value of io_apic_read in 3.0?
>
> No. I meant that we would continue to emulate. The improvement
> is that now we do:
>
> =A0 =A0 =A0 if (reg =3D=3D 0x1)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
> =A0 =A0 =A0 else if (reg =3D=3D 0x0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>
> instead of 0xfdfdfdfd.
>
>> It's 0xffffffff.
>
> Now it is 0xfdfdfdfd.
>
> I am suggesting that instead of BUG_ON(), we fallback to do returning
> an emulatated IO_APIC values - like the ones that this original patch
> cooked up..

But we still need to return some value if the register is not emulated.

How about below?

unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
{
        struct physdev_apic apic_op;
        int ret;

        apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
        apic_op.reg =3D reg;
        ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
        if (!ret)
                return apic_op.value;

        /* emulate register */
        if (reg =3D=3D 0x1)
                return 0x00170020;
        else if (reg =3D=3D 0x0)
                return apic << 24;
        else
                return -1;
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMgyh-0004pE-Bd; Tue, 24 Apr 2012 14:44:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SMgyf-0004p5-HE
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:44:25 +0000
Received: from [193.109.254.147:60084] by server-6.bemta-14.messagelabs.com id
	00/B5-02047-84CB69F4; Tue, 24 Apr 2012 14:44:24 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335278655!6070590!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28813 invoked from network); 24 Apr 2012 14:44:16 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-16.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 14:44:16 -0000
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com
	[209.85.216.50]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 05B64DBC50
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 22:43:56 +0800 (CST)
Received: by qafl39 with SMTP id l39so136602qaf.9
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 07:43:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.111.74 with SMTP id r10mr5118701qcp.122.1335278633215;
	Tue, 24 Apr 2012 07:43:53 -0700 (PDT)
Received: by 10.229.68.170 with HTTP; Tue, 24 Apr 2012 07:43:53 -0700 (PDT)
In-Reply-To: <20120423151123.GC24481@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
Date: Tue, 24 Apr 2012 22:43:53 +0800
Message-ID: <CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 11:11 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> >> > How about return -1 on error?
>> >> > The calling function can check -1 for error.
>> >>
>> >> Isn't -1 potentially (at least theoretically) a valid value to read f=
rom
>> >> one of these registers?
>> >
>> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
>> >
>> > Perhaps the fallback is to emulate (so retain some of the original cod=
e)
>> > as we have been since .. uh 3.0?
>>
>> Do you mean the return value of io_apic_read in 3.0?
>
> No. I meant that we would continue to emulate. The improvement
> is that now we do:
>
> =A0 =A0 =A0 if (reg =3D=3D 0x1)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
> =A0 =A0 =A0 else if (reg =3D=3D 0x0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>
> instead of 0xfdfdfdfd.
>
>> It's 0xffffffff.
>
> Now it is 0xfdfdfdfd.
>
> I am suggesting that instead of BUG_ON(), we fallback to do returning
> an emulatated IO_APIC values - like the ones that this original patch
> cooked up..

But we still need to return some value if the register is not emulated.

How about below?

unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
{
        struct physdev_apic apic_op;
        int ret;

        apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
        apic_op.reg =3D reg;
        ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
        if (!ret)
                return apic_op.value;

        /* emulate register */
        if (reg =3D=3D 0x1)
                return 0x00170020;
        else if (reg =3D=3D 0x0)
                return apic << 24;
        else
                return -1;
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:47:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh1c-000534-Un; Tue, 24 Apr 2012 14:47:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMh1b-00052r-H1
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:47:27 +0000
Received: from [85.158.138.51:22935] by server-2.bemta-3.messagelabs.com id
	00/23-09269-EFCB69F4; Tue, 24 Apr 2012 14:47:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335278845!23568999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8365 invoked from network); 24 Apr 2012 14:47:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:47:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:47:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:47:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMh1Z-0006Ci-AV; Tue, 24 Apr 2012 14:47:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMh1Z-0007cX-86;
	Tue, 24 Apr 2012 15:47:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.48381.57194.304369@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:47:25 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335278440.4347.180.camel@zakaz.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> You could consider this to be a best effort check for xend. IOW we try
> and look but if we can't tell then we assume it is not.

I guess.

> It's not terribly robust to just blunder on, but on the other hand being
> more robust has a bigger risk of false positives, e.g. failing to start
> xl because /var/lock/subsys/ does not exist isn't especially helpful
> either (the EACCESS return code doesn't distinguish that
> from /var/lock/subsys/xend not existing).

EACCES would happen only if the permissions prevented us from
looking.  If /var/lock/subsys doesn't exist we'll get ENOENT, the
"good" error return.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:47:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh1c-000534-Un; Tue, 24 Apr 2012 14:47:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMh1b-00052r-H1
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:47:27 +0000
Received: from [85.158.138.51:22935] by server-2.bemta-3.messagelabs.com id
	00/23-09269-EFCB69F4; Tue, 24 Apr 2012 14:47:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335278845!23568999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8365 invoked from network); 24 Apr 2012 14:47:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:47:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:47:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:47:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMh1Z-0006Ci-AV; Tue, 24 Apr 2012 14:47:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMh1Z-0007cX-86;
	Tue, 24 Apr 2012 15:47:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.48381.57194.304369@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:47:25 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335278440.4347.180.camel@zakaz.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> You could consider this to be a best effort check for xend. IOW we try
> and look but if we can't tell then we assume it is not.

I guess.

> It's not terribly robust to just blunder on, but on the other hand being
> more robust has a bigger risk of false positives, e.g. failing to start
> xl because /var/lock/subsys/ does not exist isn't especially helpful
> either (the EACCESS return code doesn't distinguish that
> from /var/lock/subsys/xend not existing).

EACCES would happen only if the permissions prevented us from
looking.  If /var/lock/subsys doesn't exist we'll get ENOENT, the
"good" error return.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:49:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:49:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh3e-0005BE-Fj; Tue, 24 Apr 2012 14:49:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMh3d-0005B3-Ie
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:49:33 +0000
Received: from [85.158.138.51:55692] by server-7.bemta-3.messagelabs.com id
	6D/9C-03078-C7DB69F4; Tue, 24 Apr 2012 14:49:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335278972!23569420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16406 invoked from network); 24 Apr 2012 14:49:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:48:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:48:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMh32-0006DL-Cx; Tue, 24 Apr 2012 14:48:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMh32-0007dz-C0;
	Tue, 24 Apr 2012 15:48:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.48472.358639.805260@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:48:56 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334935793-23912-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1334935793-23912-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3] libxl: use qemu-xen with PV guests by default"):
> qemu-xen offers better disk performances than qemu-xen-traditional
> because it supports Linux native AIO: use it for PV guests if it is
> available.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:49:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:49:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh3e-0005BE-Fj; Tue, 24 Apr 2012 14:49:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMh3d-0005B3-Ie
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:49:33 +0000
Received: from [85.158.138.51:55692] by server-7.bemta-3.messagelabs.com id
	6D/9C-03078-C7DB69F4; Tue, 24 Apr 2012 14:49:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335278972!23569420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16406 invoked from network); 24 Apr 2012 14:49:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:48:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:48:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMh32-0006DL-Cx; Tue, 24 Apr 2012 14:48:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMh32-0007dz-C0;
	Tue, 24 Apr 2012 15:48:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.48472.358639.805260@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:48:56 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334935793-23912-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1334935793-23912-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3] libxl: use qemu-xen with PV guests by
	default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v3] libxl: use qemu-xen with PV guests by default"):
> qemu-xen offers better disk performances than qemu-xen-traditional
> because it supports Linux native AIO: use it for PV guests if it is
> available.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:51:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh54-0005Ha-Vo; Tue, 24 Apr 2012 14:51:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMh52-0005HP-VP
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:51:01 +0000
Received: from [193.109.254.147:22392] by server-5.bemta-14.messagelabs.com id
	D4/57-30733-4DDB69F4; Tue, 24 Apr 2012 14:51:00 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335279048!3633653!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16737 invoked from network); 24 Apr 2012 14:50:50 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 14:50:50 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 3EBC41020F354;
	Tue, 24 Apr 2012 07:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 3SnQg_pGwPmV; Tue, 24 Apr 2012 07:50:47 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 0C9C91020F32A;
	Tue, 24 Apr 2012 07:50:47 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <1335272234.4347.112.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 07:50:46 -0700
Message-Id: <10922B30-C8E3-44BB-9535-D7147B080EBC@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
	<D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
	<1335272234.4347.112.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> Are you sure? The stack trace indicates that this is "Xen-4.2-unstable"
> not 4.1.x. (note to self, we really ought to print the hg cset in the
> panic log if it is available=85)

Not that sure.   I was working on this last October, and it looks like 4.1.=
2 was released right around the time I wrapped up the last set of packages.=
   I was working with 4.1.1, and then I switched to unstable when I ran int=
o trouble getting HVM going.

> =

>> so I thought I would make fresh go of Xen, and if I still had the
>> problem I'd feel better about filing bug reports.
>> =

>> =

>> So for the purposes of production blah, I thought I'd use the stable
>> releases, but if tracking unstable is preferable, I can do that.
> =

> For your production uses I think the best advice right now would be to
> use 4.1 with xend (unless Stefano can diagnose your xl console issue in
> the other subthread). However it would also be useful to evaluate your
> use case using xen-unstable and xl so that we can be reasonably sure
> that when 4.2 is released you will be able to deploy that without issue.


Suits me.   I may take this opportunity to work on the Xen wiki page for Ar=
ch Linux to document start-to-finish domU configuration, so having it ready=
 to roll for 4.2 will be helpful.   I've also been submitting patches to ma=
ke the Xen init scripts fit in Arch's somewhat non-standard init.  =



-Sam
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:51:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh54-0005Ha-Vo; Tue, 24 Apr 2012 14:51:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMh52-0005HP-VP
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:51:01 +0000
Received: from [193.109.254.147:22392] by server-5.bemta-14.messagelabs.com id
	D4/57-30733-4DDB69F4; Tue, 24 Apr 2012 14:51:00 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335279048!3633653!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16737 invoked from network); 24 Apr 2012 14:50:50 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 14:50:50 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 3EBC41020F354;
	Tue, 24 Apr 2012 07:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 3SnQg_pGwPmV; Tue, 24 Apr 2012 07:50:47 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 0C9C91020F32A;
	Tue, 24 Apr 2012 07:50:47 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <1335272234.4347.112.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 07:50:46 -0700
Message-Id: <10922B30-C8E3-44BB-9535-D7147B080EBC@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
	<D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
	<1335272234.4347.112.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> Are you sure? The stack trace indicates that this is "Xen-4.2-unstable"
> not 4.1.x. (note to self, we really ought to print the hg cset in the
> panic log if it is available=85)

Not that sure.   I was working on this last October, and it looks like 4.1.=
2 was released right around the time I wrapped up the last set of packages.=
   I was working with 4.1.1, and then I switched to unstable when I ran int=
o trouble getting HVM going.

> =

>> so I thought I would make fresh go of Xen, and if I still had the
>> problem I'd feel better about filing bug reports.
>> =

>> =

>> So for the purposes of production blah, I thought I'd use the stable
>> releases, but if tracking unstable is preferable, I can do that.
> =

> For your production uses I think the best advice right now would be to
> use 4.1 with xend (unless Stefano can diagnose your xl console issue in
> the other subthread). However it would also be useful to evaluate your
> use case using xen-unstable and xl so that we can be reasonably sure
> that when 4.2 is released you will be able to deploy that without issue.


Suits me.   I may take this opportunity to work on the Xen wiki page for Ar=
ch Linux to document start-to-finish domU configuration, so having it ready=
 to roll for 4.2 will be helpful.   I've also been submitting patches to ma=
ke the Xen init scripts fit in Arch's somewhat non-standard init.  =



-Sam
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:51:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh5X-0005Kw-Co; Tue, 24 Apr 2012 14:51:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMh5W-0005Kk-22
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:51:30 +0000
Received: from [193.109.254.147:17534] by server-12.bemta-14.messagelabs.com
	id 0F/C7-05898-1FDB69F4; Tue, 24 Apr 2012 14:51:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335279088!905540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21861 invoked from network); 24 Apr 2012 14:51:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:51:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:51:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:51:28 +0100
Message-ID: <1335279087.4347.186.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Tue, 24 Apr 2012 15:51:27 +0100
In-Reply-To: <20120424143329.GB19331@bloms.de>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:33 +0100, Dieter Bloms wrote:
> Hi,
> 
> On Tue, Apr 24, Ian Campbell wrote:
> 
> > I think you mean cpu_weight rather than cpu-weight.
> 
> yes of course, fixed.
> 
> > =item B<latency=N>
> > 
> > I think you missed the value here.
> 
> I don't know the value for it, so I added N as you suggested.
> 
> > > +    ("us", KeyedUnion(None, libxl_scheduler, "sched",
> > > +                 [("credit", libxl_sched_credit_domain),
> > > +                 ("credit2", libxl_sched_credit2_domain),
> > > +                 ("sedf", libxl_sched_sedf_domain),
> > > +                 ("arinc653", libxl_sched_arinc653_domain),
> > > +                 ], keyvar_init_val = "-1")),
> > 
> > I don't think a KeyedUnion is right here, since the user of libxl
> > doesn't really have a choice about which scheduler is in user (that's
> > set at boot time or via cpupool interfaces).
> > 
> > You could use a Union, but below I'll make an argument that perhaps a
> > Struct would be better.
> 
> Hm, but when I don't use a union with the structure for each scheduler I
> have to create a structure depend of scheduler at runtime, because the
> functions libxl_sched_XXXXXX_domain_set use there own structure for
> their scheduler.

I mean create a single struct with all of the options in it, from which
libxl will select the appropriate set of parameters (much like the code
you have now does. You don't need to decide the content of that struct
at runtime.

The IDL patch is below, other than changing "us" to "sched_params" I
think most of the rest of your patch remains the same.

> I've create a new function libxl__sched_set_params, which set the params
> depend on the scheduler as you suggested.
> 
> I'am not a software developer, so please be forbear with me.

That's ok, thanks for doing this!

You add a struct for arinc635 but don't actually do anything with it,
you may as well leave it out for now?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:51:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh5X-0005Kw-Co; Tue, 24 Apr 2012 14:51:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMh5W-0005Kk-22
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:51:30 +0000
Received: from [193.109.254.147:17534] by server-12.bemta-14.messagelabs.com
	id 0F/C7-05898-1FDB69F4; Tue, 24 Apr 2012 14:51:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335279088!905540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21861 invoked from network); 24 Apr 2012 14:51:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:51:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:51:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:51:28 +0100
Message-ID: <1335279087.4347.186.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Tue, 24 Apr 2012 15:51:27 +0100
In-Reply-To: <20120424143329.GB19331@bloms.de>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:33 +0100, Dieter Bloms wrote:
> Hi,
> 
> On Tue, Apr 24, Ian Campbell wrote:
> 
> > I think you mean cpu_weight rather than cpu-weight.
> 
> yes of course, fixed.
> 
> > =item B<latency=N>
> > 
> > I think you missed the value here.
> 
> I don't know the value for it, so I added N as you suggested.
> 
> > > +    ("us", KeyedUnion(None, libxl_scheduler, "sched",
> > > +                 [("credit", libxl_sched_credit_domain),
> > > +                 ("credit2", libxl_sched_credit2_domain),
> > > +                 ("sedf", libxl_sched_sedf_domain),
> > > +                 ("arinc653", libxl_sched_arinc653_domain),
> > > +                 ], keyvar_init_val = "-1")),
> > 
> > I don't think a KeyedUnion is right here, since the user of libxl
> > doesn't really have a choice about which scheduler is in user (that's
> > set at boot time or via cpupool interfaces).
> > 
> > You could use a Union, but below I'll make an argument that perhaps a
> > Struct would be better.
> 
> Hm, but when I don't use a union with the structure for each scheduler I
> have to create a structure depend of scheduler at runtime, because the
> functions libxl_sched_XXXXXX_domain_set use there own structure for
> their scheduler.

I mean create a single struct with all of the options in it, from which
libxl will select the appropriate set of parameters (much like the code
you have now does. You don't need to decide the content of that struct
at runtime.

The IDL patch is below, other than changing "us" to "sched_params" I
think most of the rest of your patch remains the same.

> I've create a new function libxl__sched_set_params, which set the params
> depend on the scheduler as you suggested.
> 
> I'am not a software developer, so please be forbear with me.

That's ok, thanks for doing this!

You add a struct for arinc635 but don't actually do anything with it,
you may as well leave it out for now?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:52:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh64-0005Pr-RT; Tue, 24 Apr 2012 14:52:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMh63-0005Pf-Vu
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:52:04 +0000
Received: from [85.158.138.51:21365] by server-9.bemta-3.messagelabs.com id
	75/F7-26691-31EB69F4; Tue, 24 Apr 2012 14:52:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335279122!23549706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 24 Apr 2012 14:52:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:52:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:52:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:52:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMh61-0006EP-Ts; Tue, 24 Apr 2012 14:52:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMh61-0007eA-Sc;
	Tue, 24 Apr 2012 15:52:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.48657.874915.219128@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:52:01 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 5/8] xl/libxl: add a blkdev_start
	parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 5/8] xl/libxl: add a blkdev_start parameter"):
> Introduce a blkdev_start in xl.conf and a corresponding string in
> libxl_domain_build_info.
...
> +        libxl_device_disk **new_disk,
> +        char *blkdev_start)

Shouldn't this be  const char *  ?

You should mention in the commit message that in this patch the value
is still ignored - ie, it will be used later.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:52:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMh64-0005Pr-RT; Tue, 24 Apr 2012 14:52:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMh63-0005Pf-Vu
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:52:04 +0000
Received: from [85.158.138.51:21365] by server-9.bemta-3.messagelabs.com id
	75/F7-26691-31EB69F4; Tue, 24 Apr 2012 14:52:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335279122!23549706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 24 Apr 2012 14:52:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:52:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:52:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:52:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMh61-0006EP-Ts; Tue, 24 Apr 2012 14:52:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMh61-0007eA-Sc;
	Tue, 24 Apr 2012 15:52:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.48657.874915.219128@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:52:01 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 5/8] xl/libxl: add a blkdev_start
	parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 5/8] xl/libxl: add a blkdev_start parameter"):
> Introduce a blkdev_start in xl.conf and a corresponding string in
> libxl_domain_build_info.
...
> +        libxl_device_disk **new_disk,
> +        char *blkdev_start)

Shouldn't this be  const char *  ?

You should mention in the commit message that in this patch the value
is still ignored - ie, it will be used later.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:58:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhBt-0005st-1Q; Tue, 24 Apr 2012 14:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhBr-0005so-Hg
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:58:03 +0000
Received: from [85.158.143.35:51041] by server-3.bemta-4.messagelabs.com id
	3B/ED-05853-A7FB69F4; Tue, 24 Apr 2012 14:58:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335279481!13867699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30741 invoked from network); 24 Apr 2012 14:58:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:58:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:58:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:58:00 +0100
Message-ID: <1335279479.4347.190.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 15:57:59 +0100
In-Reply-To: <10922B30-C8E3-44BB-9535-D7147B080EBC@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
	<D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
	<1335272234.4347.112.camel@zakaz.uk.xensource.com>
	<10922B30-C8E3-44BB-9535-D7147B080EBC@tacomatelematics.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:50 +0100, Sam Mulvey wrote:
> I may take this opportunity to work on the Xen wiki page for Arch
> Linux to document start-to-finish domU configuration, so having it
> ready to roll for 4.2 will be helpful.

That would be really great!

This is the page linked from http://wiki.xen.org/wiki/Distro_Resources ?
(you just missed a Xen document day yesterday, not that writing docs
should be restricted to one day a month ;-))

>    I've also been submitting patches to make the Xen init scripts fit
> in Arch's somewhat non-standard init.  

Sounds good, I guess you've been submitting them to Arch rather than
here (or else I've been asleep at the wheel again)?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:58:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhBt-0005st-1Q; Tue, 24 Apr 2012 14:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhBr-0005so-Hg
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:58:03 +0000
Received: from [85.158.143.35:51041] by server-3.bemta-4.messagelabs.com id
	3B/ED-05853-A7FB69F4; Tue, 24 Apr 2012 14:58:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335279481!13867699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30741 invoked from network); 24 Apr 2012 14:58:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:58:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:58:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:58:00 +0100
Message-ID: <1335279479.4347.190.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sam Mulvey <sam@tacomatelematics.com>
Date: Tue, 24 Apr 2012 15:57:59 +0100
In-Reply-To: <10922B30-C8E3-44BB-9535-D7147B080EBC@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<1335263508.4347.78.camel@zakaz.uk.xensource.com>
	<D56E58DB-86ED-4165-A4A8-AFE83CB7DB44@tacomatelematics.com>
	<1335272234.4347.112.camel@zakaz.uk.xensource.com>
	<10922B30-C8E3-44BB-9535-D7147B080EBC@tacomatelematics.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:50 +0100, Sam Mulvey wrote:
> I may take this opportunity to work on the Xen wiki page for Arch
> Linux to document start-to-finish domU configuration, so having it
> ready to roll for 4.2 will be helpful.

That would be really great!

This is the page linked from http://wiki.xen.org/wiki/Distro_Resources ?
(you just missed a Xen document day yesterday, not that writing docs
should be restricted to one day a month ;-))

>    I've also been submitting patches to make the Xen init scripts fit
> in Arch's somewhat non-standard init.  

Sounds good, I guess you've been submitting them to Arch rather than
here (or else I've been asleep at the wheel again)?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:58:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhCB-0005uD-EQ; Tue, 24 Apr 2012 14:58:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhCA-0005u3-BS
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:58:22 +0000
Received: from [85.158.138.51:45558] by server-1.bemta-3.messagelabs.com id
	53/6B-11491-D8FB69F4; Tue, 24 Apr 2012 14:58:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335279500!23608263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14707 invoked from network); 24 Apr 2012 14:58:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:58:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:58:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:58:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhC8-0006Hw-8i; Tue, 24 Apr 2012 14:58:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhC8-0007ej-7j;
	Tue, 24 Apr 2012 15:58:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.49036.91434.25461@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:58:20 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> Introduce libxl__alloc_vdev: find a spare virtual block device in the
> domain passed as argument.
...
> +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> +        char *blkdev_start, xs_transaction_t t)
> +{

If this function is ever called with domid != our own, this will
malfunction, because ...

> +            if (errno == ENOENT)
> +                return libxl__devid_to_localdev(gc, devid);

... libxl__devid_to_localdev only answers the question about the
current domain.

This needs to be mentioned in a documentation comment by the function,
at the very least.  Does your series invoke it with a domid other than
our own ?

> +            else
> +                return NULL;
> +        }
> +        vdev[strlen(vdev) - 1]++;
> +    } while (vdev[strlen(vdev) - 1] <= 'z');

There is a scaling limit here of not starting more than 26 domains
simultaneously.  Is that acceptable ?  I'm tempted to suggest not.
Note that "simultaneously" includes the case where all 27 of them are
simply sat waiting for someone to press "return" on a pygrub prompt.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 14:58:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 14:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhCB-0005uD-EQ; Tue, 24 Apr 2012 14:58:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhCA-0005u3-BS
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 14:58:22 +0000
Received: from [85.158.138.51:45558] by server-1.bemta-3.messagelabs.com id
	53/6B-11491-D8FB69F4; Tue, 24 Apr 2012 14:58:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335279500!23608263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14707 invoked from network); 24 Apr 2012 14:58:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:58:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:58:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 15:58:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhC8-0006Hw-8i; Tue, 24 Apr 2012 14:58:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhC8-0007ej-7j;
	Tue, 24 Apr 2012 15:58:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.49036.91434.25461@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 15:58:20 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> Introduce libxl__alloc_vdev: find a spare virtual block device in the
> domain passed as argument.
...
> +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> +        char *blkdev_start, xs_transaction_t t)
> +{

If this function is ever called with domid != our own, this will
malfunction, because ...

> +            if (errno == ENOENT)
> +                return libxl__devid_to_localdev(gc, devid);

... libxl__devid_to_localdev only answers the question about the
current domain.

This needs to be mentioned in a documentation comment by the function,
at the very least.  Does your series invoke it with a domid other than
our own ?

> +            else
> +                return NULL;
> +        }
> +        vdev[strlen(vdev) - 1]++;
> +    } while (vdev[strlen(vdev) - 1] <= 'z');

There is a scaling limit here of not starting more than 26 domains
simultaneously.  Is that acceptable ?  I'm tempted to suggest not.
Note that "simultaneously" includes the case where all 27 of them are
simply sat waiting for someone to press "return" on a pygrub prompt.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:00:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhDU-00060y-UD; Tue, 24 Apr 2012 14:59:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhDT-00060s-CY
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:59:43 +0000
Received: from [85.158.143.35:4920] by server-1.bemta-4.messagelabs.com id
	F0/26-20925-EDFB69F4; Tue, 24 Apr 2012 14:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335279581!13513288!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12393 invoked from network); 24 Apr 2012 14:59:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:59:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:59:40 +0100
Message-ID: <1335279579.4347.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:59:39 +0100
In-Reply-To: <20374.48381.57194.304369@mariner.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
	<20374.48381.57194.304369@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> > You could consider this to be a best effort check for xend. IOW we try
> > and look but if we can't tell then we assume it is not.
> 
> I guess.
> 
> > It's not terribly robust to just blunder on, but on the other hand being
> > more robust has a bigger risk of false positives, e.g. failing to start
> > xl because /var/lock/subsys/ does not exist isn't especially helpful
> > either (the EACCESS return code doesn't distinguish that
> > from /var/lock/subsys/xend not existing).
> 
> EACCES would happen only if the permissions prevented us from
> looking.  If /var/lock/subsys doesn't exist we'll get ENOENT, the
> "good" error return.

Oh, right.

Well, not starting because the perms on /var/lock/subsys are too tight
(e.g. selinux restricting it to initscripts only? unrealistic maybe)
seems unhelpful too.

(I admit this isn't as compelling as my previous example).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:00:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhDU-00060y-UD; Tue, 24 Apr 2012 14:59:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhDT-00060s-CY
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 14:59:43 +0000
Received: from [85.158.143.35:4920] by server-1.bemta-4.messagelabs.com id
	F0/26-20925-EDFB69F4; Tue, 24 Apr 2012 14:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335279581!13513288!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Mzg3OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12393 invoked from network); 24 Apr 2012 14:59:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 14:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:59:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 15:59:40 +0100
Message-ID: <1335279579.4347.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 15:59:39 +0100
In-Reply-To: <20374.48381.57194.304369@mariner.uk.xensource.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
	<20374.48381.57194.304369@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is running."):
> > You could consider this to be a best effort check for xend. IOW we try
> > and look but if we can't tell then we assume it is not.
> 
> I guess.
> 
> > It's not terribly robust to just blunder on, but on the other hand being
> > more robust has a bigger risk of false positives, e.g. failing to start
> > xl because /var/lock/subsys/ does not exist isn't especially helpful
> > either (the EACCESS return code doesn't distinguish that
> > from /var/lock/subsys/xend not existing).
> 
> EACCES would happen only if the permissions prevented us from
> looking.  If /var/lock/subsys doesn't exist we'll get ENOENT, the
> "good" error return.

Oh, right.

Well, not starting because the perms on /var/lock/subsys are too tight
(e.g. selinux restricting it to initscripts only? unrealistic maybe)
seems unhelpful too.

(I admit this isn't as compelling as my previous example).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:02:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhGE-0006FU-H7; Tue, 24 Apr 2012 15:02:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhGC-0006FD-D9
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:02:32 +0000
Received: from [85.158.138.51:49804] by server-6.bemta-3.messagelabs.com id
	01/FC-05145-780C69F4; Tue, 24 Apr 2012 15:02:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335279750!23406254!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8367 invoked from network); 24 Apr 2012 15:02:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:02:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:02:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:02:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhG9-0006JG-UQ; Tue, 24 Apr 2012 15:02:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhG9-0007fM-TX;
	Tue, 24 Apr 2012 16:02:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.49285.902510.115655@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:02:29 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 2/8] libxl:
	libxl__device_disk_local_attach	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
...
> +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
> +        const libxl_device_disk *disk,
> +        libxl_device_disk **new_disk)
>  {
>      libxl_ctx *ctx = gc->owner;
>      char *dev = NULL;
> -    char *ret = NULL;
>      int rc;
> -
> -    rc = libxl__device_disk_setdefault(gc, disk);
> +    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
> +    if (tmpdisk == NULL) goto out;

libxl__zalloc is guaranteed not to fail, nowadays.

> -    switch (disk->backend) {
> +    switch (tmpdisk->backend) {

Did you see my comment about arranging for "disk" to be the new
structure and renaming the formal parameter ?  That would (a) remove a
bunch of useless stuff from the diff (b) probably make the code
clearer anyway, since nothing inside this function should be using the
actually-passed libxl_device_disk* other than the code whose purpose
is to make a copy of it.

If you resend with that change I will find it much easier to review
this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:02:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhGE-0006FU-H7; Tue, 24 Apr 2012 15:02:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhGC-0006FD-D9
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:02:32 +0000
Received: from [85.158.138.51:49804] by server-6.bemta-3.messagelabs.com id
	01/FC-05145-780C69F4; Tue, 24 Apr 2012 15:02:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335279750!23406254!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8367 invoked from network); 24 Apr 2012 15:02:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:02:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:02:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:02:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhG9-0006JG-UQ; Tue, 24 Apr 2012 15:02:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhG9-0007fM-TX;
	Tue, 24 Apr 2012 16:02:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.49285.902510.115655@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:02:29 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 2/8] libxl:
	libxl__device_disk_local_attach	return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"):
...
> +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
> +        const libxl_device_disk *disk,
> +        libxl_device_disk **new_disk)
>  {
>      libxl_ctx *ctx = gc->owner;
>      char *dev = NULL;
> -    char *ret = NULL;
>      int rc;
> -
> -    rc = libxl__device_disk_setdefault(gc, disk);
> +    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
> +    if (tmpdisk == NULL) goto out;

libxl__zalloc is guaranteed not to fail, nowadays.

> -    switch (disk->backend) {
> +    switch (tmpdisk->backend) {

Did you see my comment about arranging for "disk" to be the new
structure and renaming the formal parameter ?  That would (a) remove a
bunch of useless stuff from the diff (b) probably make the code
clearer anyway, since nothing inside this function should be using the
actually-passed libxl_device_disk* other than the code whose purpose
is to make a copy of it.

If you resend with that change I will find it much easier to review
this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:04:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhHV-0006Nc-1G; Tue, 24 Apr 2012 15:03:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1SMhHU-0006NS-7C
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:03:52 +0000
Received: from [193.109.254.147:29563] by server-10.bemta-14.messagelabs.com
	id 9D/FE-05847-7D0C69F4; Tue, 24 Apr 2012 15:03:51 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335279830!6141640!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28650 invoked from network); 24 Apr 2012 15:03:50 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Apr 2012 15:03:50 -0000
Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:54659
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1SMhCm-0005KA-7d; Tue, 24 Apr 2012 16:59:00 +0200
Date: Tue, 24 Apr 2012 17:03:48 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1238850878.20120424170348@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335277815.4347.170.camel@zakaz.uk.xensource.com>
References: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
	<442643696.20120424153049@eikelenboom.it>
	<1335277815.4347.170.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tuesday, April 24, 2012, 4:30:15 PM, you wrote:

> On Tue, 2012-04-24 at 14:30 +0100, Sander Eikelenboom wrote:
>> Hello Ian,
>> 
>> Tuesday, April 24, 2012, 2:53:31 PM, you wrote:
>> 
>> > Plan for a 4.2 release:
>> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>> 
>> > The time line is as follows:
>> 
>> > 19 March        -- TODO list locked down
>> > 2 April         -- Feature Freeze
>> >                                                 << WE ARE HERE
>> > Mid/Late April  -- First release candidate      << SEE BELOW
>> > Weekly          -- RCN+1 until it is ready
>> 
>> > My initial guesstimate for starting RCs appears to have been somewhat
>> > optimistic. I think we need to have reduced at least the blockers lists
>> > rather significantly before we start thinking of doing RCs.
>> 
>> Is there any list/overview as to the state of feature parity between xm/xend and xl/libxl ?

> Other than what's included in this list, I don't believe there is at the
> moment.

>> (both in the sense of commands to xl, as of parsing and building a
>> domain from the options specified in a domain .cfg)

> Extracting those things for xl is pretty trivial -- the hard thing is
> figuring out what options xend has/had, or more importantly which ones
> of those people actually use (since we clearly aren't intending to
> replicate every feature of xend without reference to the utility of or
> demand for those features).

> If you can provide a list of xend features which you think are essential
> (or even just the subset which you are interested in) then I'd be happy
> to correlate it with xl and add the disjunction to the list.

I don't think besides the cpu_weight, assigning/pinning of vcpu's to domains and pci passthrough i'm using any "special" config options.
Mostly using pv-guests though, perhaps there are more options people could be missing on HVM domains.
So i think for myself everything is covered, but perhaps something will pop up when i start testing the RC's.

>> This week i noticed that someone else noticed that cpu_weight &
>> co .cfg options where missing support and provided patches, but these
>> seem like pretty basic config options.

> I'd say there were not "basic" but they certainly aren't "super
> advanced" either.

That's why i said "pretty basic", but for pv-guests besides setting domainname, nr of vcpus, memory, disks and kernel/ramdisk, it would be pretty much the next thing someone could want i guess.

>> This raises the question if there are more pretty basic options still
>> missing and in what way will they be handled during the RC's ?

> I think we will have to handle that on a case by case basis. Some
> (many?) of them will be trivial and will likely be no-brainers to
> include at least during the early RCs.

Good to know !

>> (since there is a good chance more will pop up when more users start
>> testing)
>> 
>> Are patches for not to exotic and/or invasive options still
>> acceptable ?
>> Or will they have to wait for a 4.2.1 which could follow up pretty
>> short then ?

> We'd have to balance their exoticness against their invasiveness and
> make a judgement call. Obviously a horribly complex patch for a little
> used feature will get a different reception to a simple patch for a
> feature which everyone uses...

> Ian.





-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:04:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhHV-0006Nc-1G; Tue, 24 Apr 2012 15:03:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1SMhHU-0006NS-7C
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:03:52 +0000
Received: from [193.109.254.147:29563] by server-10.bemta-14.messagelabs.com
	id 9D/FE-05847-7D0C69F4; Tue, 24 Apr 2012 15:03:51 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335279830!6141640!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28650 invoked from network); 24 Apr 2012 15:03:50 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Apr 2012 15:03:50 -0000
Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:54659
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1SMhCm-0005KA-7d; Tue, 24 Apr 2012 16:59:00 +0200
Date: Tue, 24 Apr 2012 17:03:48 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1238850878.20120424170348@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335277815.4347.170.camel@zakaz.uk.xensource.com>
References: <1335272011.4347.108.camel@zakaz.uk.xensource.com>
	<442643696.20120424153049@eikelenboom.it>
	<1335277815.4347.170.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tuesday, April 24, 2012, 4:30:15 PM, you wrote:

> On Tue, 2012-04-24 at 14:30 +0100, Sander Eikelenboom wrote:
>> Hello Ian,
>> 
>> Tuesday, April 24, 2012, 2:53:31 PM, you wrote:
>> 
>> > Plan for a 4.2 release:
>> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>> 
>> > The time line is as follows:
>> 
>> > 19 March        -- TODO list locked down
>> > 2 April         -- Feature Freeze
>> >                                                 << WE ARE HERE
>> > Mid/Late April  -- First release candidate      << SEE BELOW
>> > Weekly          -- RCN+1 until it is ready
>> 
>> > My initial guesstimate for starting RCs appears to have been somewhat
>> > optimistic. I think we need to have reduced at least the blockers lists
>> > rather significantly before we start thinking of doing RCs.
>> 
>> Is there any list/overview as to the state of feature parity between xm/xend and xl/libxl ?

> Other than what's included in this list, I don't believe there is at the
> moment.

>> (both in the sense of commands to xl, as of parsing and building a
>> domain from the options specified in a domain .cfg)

> Extracting those things for xl is pretty trivial -- the hard thing is
> figuring out what options xend has/had, or more importantly which ones
> of those people actually use (since we clearly aren't intending to
> replicate every feature of xend without reference to the utility of or
> demand for those features).

> If you can provide a list of xend features which you think are essential
> (or even just the subset which you are interested in) then I'd be happy
> to correlate it with xl and add the disjunction to the list.

I don't think besides the cpu_weight, assigning/pinning of vcpu's to domains and pci passthrough i'm using any "special" config options.
Mostly using pv-guests though, perhaps there are more options people could be missing on HVM domains.
So i think for myself everything is covered, but perhaps something will pop up when i start testing the RC's.

>> This week i noticed that someone else noticed that cpu_weight &
>> co .cfg options where missing support and provided patches, but these
>> seem like pretty basic config options.

> I'd say there were not "basic" but they certainly aren't "super
> advanced" either.

That's why i said "pretty basic", but for pv-guests besides setting domainname, nr of vcpus, memory, disks and kernel/ramdisk, it would be pretty much the next thing someone could want i guess.

>> This raises the question if there are more pretty basic options still
>> missing and in what way will they be handled during the RC's ?

> I think we will have to handle that on a case by case basis. Some
> (many?) of them will be trivial and will likely be no-brainers to
> include at least during the early RCs.

Good to know !

>> (since there is a good chance more will pop up when more users start
>> testing)
>> 
>> Are patches for not to exotic and/or invasive options still
>> acceptable ?
>> Or will they have to wait for a 4.2.1 which could follow up pretty
>> short then ?

> We'd have to balance their exoticness against their invasiveness and
> make a judgement call. Obviously a horribly complex patch for a little
> used feature will get a different reception to a simple patch for a
> feature which everyone uses...

> Ian.





-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:05:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhIV-0006TI-GC; Tue, 24 Apr 2012 15:04:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhIT-0006T5-Ur
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:04:54 +0000
Received: from [85.158.143.35:5954] by server-1.bemta-4.messagelabs.com id
	B7/8F-20925-511C69F4; Tue, 24 Apr 2012 15:04:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335279891!10306263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30193 invoked from network); 24 Apr 2012 15:04:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:04:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:04:37 +0100
Message-ID: <1335279876.4347.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:04:36 +0100
In-Reply-To: <20374.49036.91434.25461@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20374.49036.91434.25461@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:58 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> > Introduce libxl__alloc_vdev: find a spare virtual block device in the
> > domain passed as argument.
> ...
> > +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> > +        char *blkdev_start, xs_transaction_t t)
> > +{
> 
> If this function is ever called with domid != our own, this will
> malfunction, because ...
> 
> > +            if (errno == ENOENT)
> > +                return libxl__devid_to_localdev(gc, devid);
> 
> ... libxl__devid_to_localdev only answers the question about the
> current domain.
> 
> This needs to be mentioned in a documentation comment by the function,
> at the very least.  Does your series invoke it with a domid other than
> our own ?
> 
> > +            else
> > +                return NULL;
> > +        }
> > +        vdev[strlen(vdev) - 1]++;
> > +    } while (vdev[strlen(vdev) - 1] <= 'z');
> 
> There is a scaling limit here of not starting more than 26 domains
> simultaneously.  Is that acceptable ?  I'm tempted to suggest not.

While I agree we also need to start being pragmatic about ever getting
4.2 out the door...

If it's a trivial job to support aa, ab etc then lets do it, if not then
lets leave it for 4.3?

> Note that "simultaneously" includes the case where all 27 of them are
> simply sat waiting for someone to press "return" on a pygrub prompt.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:05:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhIV-0006TI-GC; Tue, 24 Apr 2012 15:04:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhIT-0006T5-Ur
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:04:54 +0000
Received: from [85.158.143.35:5954] by server-1.bemta-4.messagelabs.com id
	B7/8F-20925-511C69F4; Tue, 24 Apr 2012 15:04:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335279891!10306263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30193 invoked from network); 24 Apr 2012 15:04:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:04:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:04:37 +0100
Message-ID: <1335279876.4347.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:04:36 +0100
In-Reply-To: <20374.49036.91434.25461@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20374.49036.91434.25461@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:58 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> > Introduce libxl__alloc_vdev: find a spare virtual block device in the
> > domain passed as argument.
> ...
> > +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> > +        char *blkdev_start, xs_transaction_t t)
> > +{
> 
> If this function is ever called with domid != our own, this will
> malfunction, because ...
> 
> > +            if (errno == ENOENT)
> > +                return libxl__devid_to_localdev(gc, devid);
> 
> ... libxl__devid_to_localdev only answers the question about the
> current domain.
> 
> This needs to be mentioned in a documentation comment by the function,
> at the very least.  Does your series invoke it with a domid other than
> our own ?
> 
> > +            else
> > +                return NULL;
> > +        }
> > +        vdev[strlen(vdev) - 1]++;
> > +    } while (vdev[strlen(vdev) - 1] <= 'z');
> 
> There is a scaling limit here of not starting more than 26 domains
> simultaneously.  Is that acceptable ?  I'm tempted to suggest not.

While I agree we also need to start being pragmatic about ever getting
4.2 out the door...

If it's a trivial job to support aa, ab etc then lets do it, if not then
lets leave it for 4.3?

> Note that "simultaneously" includes the case where all 27 of them are
> simply sat waiting for someone to press "return" on a pygrub prompt.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhJD-0006YT-Vo; Tue, 24 Apr 2012 15:05:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhJB-0006Y8-OX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:05:38 +0000
Received: from [85.158.139.83:17861] by server-12.bemta-5.messagelabs.com id
	0A/A9-05587-041C69F4; Tue, 24 Apr 2012 15:05:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335279935!22571514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23347 invoked from network); 24 Apr 2012 15:05:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:05:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:05:34 +0100
Message-ID: <1335279933.4347.196.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:05:33 +0100
In-Reply-To: <20374.47156.616718.181384@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
	<20374.47156.616718.181384@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:27 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> > On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > > Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> > > is now moved elsewhere, as follows:
> ...
> > >  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> > >                  { return childw_out->pid >= 0; }
> > >  
> > > +/* Useable (only) in the child to once more make the ctx useable for
> > > + * xenstore operations.
> > 
> > Specifically "the child" is the middle child of a spawn? Otherwise the
> > constraint must be something like "before any threads are created in the
> > new process", or something like that?
> 
> The fact that raw fork() may be used in the child created by
> libxl__ev_child_inuse isn't documented.  It would be possible to
> document this but the set of restrictions on the behaviours of the
> middle child and any resulting grandchildren are rather complex.
> 
> I think it might be better to draw a veil over this and leave it as a
> special piece of knowledge implicit in the implementation of
> libxl__spawn_*.

OK.

> In practice the use of _xenstore_reopen in the middle child is fine
> provided that the middle child doesn't then fork _and_ then use
> libxl's xenstore functions in both the middle child and the
> grandchild.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhJD-0006YT-Vo; Tue, 24 Apr 2012 15:05:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhJB-0006Y8-OX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:05:38 +0000
Received: from [85.158.139.83:17861] by server-12.bemta-5.messagelabs.com id
	0A/A9-05587-041C69F4; Tue, 24 Apr 2012 15:05:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335279935!22571514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23347 invoked from network); 24 Apr 2012 15:05:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:05:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:05:34 +0100
Message-ID: <1335279933.4347.196.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:05:33 +0100
In-Reply-To: <20374.47156.616718.181384@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
	<20374.47156.616718.181384@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:27 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> > On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > > Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> > > is now moved elsewhere, as follows:
> ...
> > >  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> > >                  { return childw_out->pid >= 0; }
> > >  
> > > +/* Useable (only) in the child to once more make the ctx useable for
> > > + * xenstore operations.
> > 
> > Specifically "the child" is the middle child of a spawn? Otherwise the
> > constraint must be something like "before any threads are created in the
> > new process", or something like that?
> 
> The fact that raw fork() may be used in the child created by
> libxl__ev_child_inuse isn't documented.  It would be possible to
> document this but the set of restrictions on the behaviours of the
> middle child and any resulting grandchildren are rather complex.
> 
> I think it might be better to draw a veil over this and leave it as a
> special piece of knowledge implicit in the implementation of
> libxl__spawn_*.

OK.

> In practice the use of _xenstore_reopen in the middle child is fine
> provided that the middle child doesn't then fork _and_ then use
> libxl's xenstore functions in both the middle child and the
> grandchild.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:07:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:07:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhLE-0006lm-Ga; Tue, 24 Apr 2012 15:07:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhLD-0006ld-Hk
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:07:43 +0000
Received: from [85.158.138.51:24123] by server-10.bemta-3.messagelabs.com id
	A6/FC-29478-EB1C69F4; Tue, 24 Apr 2012 15:07:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335280061!14639023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11740 invoked from network); 24 Apr 2012 15:07:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:07:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:07:41 +0100
Message-ID: <1335280060.4347.197.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:07:40 +0100
In-Reply-To: <1335279933.4347.196.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
	<20374.47156.616718.181384@mariner.uk.xensource.com>
	<1335279933.4347.196.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 16:05 +0100, Ian Campbell wrote:
> On Tue, 2012-04-24 at 15:27 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> > > On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > > > Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> > > > is now moved elsewhere, as follows:
> > ...
> > > >  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> > > >                  { return childw_out->pid >= 0; }
> > > >  
> > > > +/* Useable (only) in the child to once more make the ctx useable for
> > > > + * xenstore operations.
> > > 
> > > Specifically "the child" is the middle child of a spawn? Otherwise the
> > > constraint must be something like "before any threads are created in the
> > > new process", or something like that?
> > 
> > The fact that raw fork() may be used in the child created by
> > libxl__ev_child_inuse isn't documented.  It would be possible to
> > document this but the set of restrictions on the behaviours of the
> > middle child and any resulting grandchildren are rather complex.
> > 
> > I think it might be better to draw a veil over this and leave it as a
> > special piece of knowledge implicit in the implementation of
> > libxl__spawn_*.
> 
> OK.

Looking back at my review, my only other comment was just a suggestion
which you can implenment if you want, which means that OK ->

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> > In practice the use of _xenstore_reopen in the middle child is fine
> > provided that the middle child doesn't then fork _and_ then use
> > libxl's xenstore functions in both the middle child and the
> > grandchild.
> > 
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:07:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:07:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhLE-0006lm-Ga; Tue, 24 Apr 2012 15:07:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhLD-0006ld-Hk
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:07:43 +0000
Received: from [85.158.138.51:24123] by server-10.bemta-3.messagelabs.com id
	A6/FC-29478-EB1C69F4; Tue, 24 Apr 2012 15:07:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335280061!14639023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11740 invoked from network); 24 Apr 2012 15:07:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12109999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:07:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:07:41 +0100
Message-ID: <1335280060.4347.197.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:07:40 +0100
In-Reply-To: <1335279933.4347.196.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
	<20374.47156.616718.181384@mariner.uk.xensource.com>
	<1335279933.4347.196.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 16:05 +0100, Ian Campbell wrote:
> On Tue, 2012-04-24 at 15:27 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> > > On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > > > Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> > > > is now moved elsewhere, as follows:
> > ...
> > > >  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> > > >                  { return childw_out->pid >= 0; }
> > > >  
> > > > +/* Useable (only) in the child to once more make the ctx useable for
> > > > + * xenstore operations.
> > > 
> > > Specifically "the child" is the middle child of a spawn? Otherwise the
> > > constraint must be something like "before any threads are created in the
> > > new process", or something like that?
> > 
> > The fact that raw fork() may be used in the child created by
> > libxl__ev_child_inuse isn't documented.  It would be possible to
> > document this but the set of restrictions on the behaviours of the
> > middle child and any resulting grandchildren are rather complex.
> > 
> > I think it might be better to draw a veil over this and leave it as a
> > special piece of knowledge implicit in the implementation of
> > libxl__spawn_*.
> 
> OK.

Looking back at my review, my only other comment was just a suggestion
which you can implenment if you want, which means that OK ->

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> > In practice the use of _xenstore_reopen in the middle child is fine
> > provided that the middle child doesn't then fork _and_ then use
> > libxl's xenstore functions in both the middle child and the
> > grandchild.
> > 
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhM6-0006tk-4V; Tue, 24 Apr 2012 15:08:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhM4-0006tL-Dh
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:08:36 +0000
Received: from [85.158.143.35:28190] by server-2.bemta-4.messagelabs.com id
	77/E2-17550-3F1C69F4; Tue, 24 Apr 2012 15:08:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335280115!11434544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3789 invoked from network); 24 Apr 2012 15:08:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:08:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:08:34 +0100
Message-ID: <1335280113.4347.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:08:33 +0100
In-Reply-To: <20374.47868.746605.101511@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
	<1335277100.4347.159.camel@zakaz.uk.xensource.com>
	<20374.47868.746605.101511@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:38 +0100, Ian Jackson wrote:
> if the domain is destroyed then
> either (a) the entries in xenstore have already been deleted, in which
> case the test here works or (b) they have not in which case something
> has gone very badly wrong and we are going to leak those xenstore
> entries, in which case trying to avoid leaking other stuff seems
> futile.

I'm convinced. Maybe write that in a comment?

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhM6-0006tk-4V; Tue, 24 Apr 2012 15:08:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhM4-0006tL-Dh
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:08:36 +0000
Received: from [85.158.143.35:28190] by server-2.bemta-4.messagelabs.com id
	77/E2-17550-3F1C69F4; Tue, 24 Apr 2012 15:08:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335280115!11434544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3789 invoked from network); 24 Apr 2012 15:08:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:08:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:08:34 +0100
Message-ID: <1335280113.4347.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:08:33 +0100
In-Reply-To: <20374.47868.746605.101511@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
	<1335277100.4347.159.camel@zakaz.uk.xensource.com>
	<20374.47868.746605.101511@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 15:38 +0100, Ian Jackson wrote:
> if the domain is destroyed then
> either (a) the entries in xenstore have already been deleted, in which
> case the test here works or (b) they have not in which case something
> has gone very badly wrong and we are going to leak those xenstore
> entries, in which case trying to avoid leaking other stuff seems
> futile.

I'm convinced. Maybe write that in a comment?

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMb-0006zX-Bu; Tue, 24 Apr 2012 15:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMZ-0006yn-TA
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:08 +0000
Received: from [85.158.143.35:30656] by server-2.bemta-4.messagelabs.com id
	C2/B3-17550-312C69F4; Tue, 24 Apr 2012 15:09:07 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335280146!17591580!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24489 invoked from network); 24 Apr 2012 15:09:06 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-14.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 15:09:06 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 2430823AD5; Tue, 24 Apr 2012 11:17:32 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 04A3A23ADA;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 5C2CD281A7; Tue, 24 Apr 2012 11:09:02 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 656262a43421881ee9b2cf9288023089b30060dc
Message-Id: <656262a43421881ee9b2.1335280030@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:10 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 v3 RESEND] xl: cleanup indentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdp
dCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwot
LS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jCkBAIC04NDcsMTAgKzg0NywxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShj
b25zdCBjaGFyCiAgICAgICAgICAgICAgICAgbmljLT5zY3JpcHQgPSBzdHJkdXAoZGVmYXVsdF92
aWZzY3JpcHQpOwogICAgICAgICAgICAgfQogCi0JICAgIGlmIChkZWZhdWx0X2JyaWRnZSkgewot
CQlmcmVlKG5pYy0+YnJpZGdlKTsKLQkJbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwotCSAgICB9CisgICAgICAgICAgICBpZiAoZGVmYXVsdF9icmlkZ2UpIHsKKyAgICAgICAg
ICAgICAgICBmcmVlKG5pYy0+YnJpZGdlKTsKKyAgICAgICAgICAgICAgICBuaWMtPmJyaWRnZSA9
IHN0cmR1cChkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIHAg
PSBzdHJ0b2soYnVmMiwgIiwiKTsKICAgICAgICAgICAgIGlmICghcCkKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMb-0006zX-Bu; Tue, 24 Apr 2012 15:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMZ-0006yn-TA
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:08 +0000
Received: from [85.158.143.35:30656] by server-2.bemta-4.messagelabs.com id
	C2/B3-17550-312C69F4; Tue, 24 Apr 2012 15:09:07 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335280146!17591580!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24489 invoked from network); 24 Apr 2012 15:09:06 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-14.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 15:09:06 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 2430823AD5; Tue, 24 Apr 2012 11:17:32 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 04A3A23ADA;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 5C2CD281A7; Tue, 24 Apr 2012 11:09:02 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 656262a43421881ee9b2cf9288023089b30060dc
Message-Id: <656262a43421881ee9b2.1335280030@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:10 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 v3 RESEND] xl: cleanup indentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U2lnbmVkLW9mZi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdp
dCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwot
LS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jCkBAIC04NDcsMTAgKzg0NywxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShj
b25zdCBjaGFyCiAgICAgICAgICAgICAgICAgbmljLT5zY3JpcHQgPSBzdHJkdXAoZGVmYXVsdF92
aWZzY3JpcHQpOwogICAgICAgICAgICAgfQogCi0JICAgIGlmIChkZWZhdWx0X2JyaWRnZSkgewot
CQlmcmVlKG5pYy0+YnJpZGdlKTsKLQkJbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwotCSAgICB9CisgICAgICAgICAgICBpZiAoZGVmYXVsdF9icmlkZ2UpIHsKKyAgICAgICAg
ICAgICAgICBmcmVlKG5pYy0+YnJpZGdlKTsKKyAgICAgICAgICAgICAgICBuaWMtPmJyaWRnZSA9
IHN0cmR1cChkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIHAg
PSBzdHJ0b2soYnVmMiwgIiwiKTsKICAgICAgICAgICAgIGlmICghcCkKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMa-0006zI-Vh; Tue, 24 Apr 2012 15:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMZ-0006yi-G6
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:07 +0000
Received: from [85.158.143.35:30632] by server-3.bemta-4.messagelabs.com id
	FA/22-05853-212C69F4; Tue, 24 Apr 2012 15:09:06 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335280145!13515244!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29359 invoked from network); 24 Apr 2012 15:09:06 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 15:09:06 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id DE35723C73; Tue, 24 Apr 2012 11:17:32 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 98A8723AD5;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id C34E2281AA; Tue, 24 Apr 2012 11:09:02 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: b17fc6cfbd884d2f9ddf643b954bcb3ce6236364
Message-Id: <b17fc6cfbd884d2f9ddf.1335280031@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:11 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 v3 RESEND] xl: xl network-attach -N (dry
	run) option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIGRyeXJ1biBmb3IgdGVzdGluZyBhbmQgZGVidWdnaW5nIHB1cnBvc2VzLgoKU2lnbmVkLW9m
Zi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC00
OTE2LDYgKzQ5MTYsMTYgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIH0KICAgICB9CisKKyAgICBpZiAoZHJ5
cnVuX29ubHkpIHsKKyAgICAgICAgY2hhciAqanNvbiA9IGxpYnhsX2RldmljZV9uaWNfdG9fanNv
bihjdHgsICZuaWMpOworICAgICAgICBwcmludGYoInZpZjogJXNcbiIsIGpzb24pOworICAgICAg
ICBmcmVlKGpzb24pOworICAgICAgICBsaWJ4bF9kZXZpY2VfbmljX2Rpc3Bvc2UoJm5pYyk7Cisg
ICAgICAgIGlmIChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3IoInN0
ZG91dCIpOyBleGl0KC0xKTsgfQorICAgICAgICByZXR1cm4gMDsKKyAgICB9CisKICAgICBpZiAo
bGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYykpIHsKICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJsaWJ4bF9kZXZpY2VfbmljX2FkZCBmYWlsZWQuXG4iKTsKICAgICAgICAgcmV0
dXJuIDE7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jIGIvdG9vbHMvbGli
eGwveGxfY21kdGFibGUuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jCisrKyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMKQEAgLTI4OCw3ICsyODgsNyBAQCBzdHJ1Y3QgY21kX3Nw
ZWMgY21kX3RhYmxlW10gPSB7CiAgICAgICAiIiwKICAgICB9LAogICAgIHsgIm5ldHdvcmstYXR0
YWNoIiwKLSAgICAgICZtYWluX25ldHdvcmthdHRhY2gsIDAsCisgICAgICAmbWFpbl9uZXR3b3Jr
YXR0YWNoLCAxLAogICAgICAgIkNyZWF0ZSBhIG5ldyB2aXJ0dWFsIG5ldHdvcmsgZGV2aWNlIiwK
ICAgICAgICI8RG9tYWluPiBbdHlwZT08dHlwZT5dIFttYWM9PG1hYz5dIFticmlkZ2U9PGJyaWRn
ZT5dICIKICAgICAgICJbaXA9PGlwPl0gW3NjcmlwdD08c2NyaXB0Pl0gW2JhY2tlbmQ9PEJhY2tE
b21haW4+XSBbdmlmbmFtZT08bmFtZT5dICIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMa-0006zI-Vh; Tue, 24 Apr 2012 15:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMZ-0006yi-G6
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:07 +0000
Received: from [85.158.143.35:30632] by server-3.bemta-4.messagelabs.com id
	FA/22-05853-212C69F4; Tue, 24 Apr 2012 15:09:06 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335280145!13515244!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29359 invoked from network); 24 Apr 2012 15:09:06 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 15:09:06 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id DE35723C73; Tue, 24 Apr 2012 11:17:32 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.5 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 98A8723AD5;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id C34E2281AA; Tue, 24 Apr 2012 11:09:02 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: b17fc6cfbd884d2f9ddf643b954bcb3ce6236364
Message-Id: <b17fc6cfbd884d2f9ddf.1335280031@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:11 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 v3 RESEND] xl: xl network-attach -N (dry
	run) option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIGRyeXJ1biBmb3IgdGVzdGluZyBhbmQgZGVidWdnaW5nIHB1cnBvc2VzLgoKU2lnbmVkLW9m
Zi1ieTogTWF0aGlldSBHYWduw6kgPG1nYWduZUBpd2ViLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBTdGVmYW5vIFN0YWJlbGxp
bmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC00
OTE2LDYgKzQ5MTYsMTYgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIH0KICAgICB9CisKKyAgICBpZiAoZHJ5
cnVuX29ubHkpIHsKKyAgICAgICAgY2hhciAqanNvbiA9IGxpYnhsX2RldmljZV9uaWNfdG9fanNv
bihjdHgsICZuaWMpOworICAgICAgICBwcmludGYoInZpZjogJXNcbiIsIGpzb24pOworICAgICAg
ICBmcmVlKGpzb24pOworICAgICAgICBsaWJ4bF9kZXZpY2VfbmljX2Rpc3Bvc2UoJm5pYyk7Cisg
ICAgICAgIGlmIChmZXJyb3Ioc3Rkb3V0KSB8fCBmZmx1c2goc3Rkb3V0KSkgeyBwZXJyb3IoInN0
ZG91dCIpOyBleGl0KC0xKTsgfQorICAgICAgICByZXR1cm4gMDsKKyAgICB9CisKICAgICBpZiAo
bGlieGxfZGV2aWNlX25pY19hZGQoY3R4LCBkb21pZCwgJm5pYykpIHsKICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJsaWJ4bF9kZXZpY2VfbmljX2FkZCBmYWlsZWQuXG4iKTsKICAgICAgICAgcmV0
dXJuIDE7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jIGIvdG9vbHMvbGli
eGwveGxfY21kdGFibGUuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWR0YWJsZS5jCisrKyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMKQEAgLTI4OCw3ICsyODgsNyBAQCBzdHJ1Y3QgY21kX3Nw
ZWMgY21kX3RhYmxlW10gPSB7CiAgICAgICAiIiwKICAgICB9LAogICAgIHsgIm5ldHdvcmstYXR0
YWNoIiwKLSAgICAgICZtYWluX25ldHdvcmthdHRhY2gsIDAsCisgICAgICAmbWFpbl9uZXR3b3Jr
YXR0YWNoLCAxLAogICAgICAgIkNyZWF0ZSBhIG5ldyB2aXJ0dWFsIG5ldHdvcmsgZGV2aWNlIiwK
ICAgICAgICI8RG9tYWluPiBbdHlwZT08dHlwZT5dIFttYWM9PG1hYz5dIFticmlkZ2U9PGJyaWRn
ZT5dICIKICAgICAgICJbaXA9PGlwPl0gW3NjcmlwdD08c2NyaXB0Pl0gW2JhY2tlbmQ9PEJhY2tE
b21haW4+XSBbdmlmbmFtZT08bmFtZT5dICIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMa-0006z9-If; Tue, 24 Apr 2012 15:09:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMZ-0006yg-6O
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:07 +0000
Received: from [85.158.138.51:15157] by server-12.bemta-3.messagelabs.com id
	15/F6-29760-212C69F4; Tue, 24 Apr 2012 15:09:06 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335280145!14639272!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16803 invoked from network); 24 Apr 2012 15:09:05 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 15:09:05 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id BCC1023A79; Tue, 24 Apr 2012 11:17:32 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,TW_CF autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 9370523A79;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 2C471281A8; Tue, 24 Apr 2012 11:09:01 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:09 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 v3 RESEND] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch series implements the required plumbering for vif rate limiting in libxl/xl.

The first patch (already applied) fixes trivial indentation issues and introduces no functional changes.

The second patch (already applied) implements dry-run for `xl network-attach` for debugging and testing purposes.

The third patch adds the required plumbering in libxl/xl to add vif rate limiting support. It uses the `rate` option syntax from xm/xend, ensuring full backward compatiblity.

The final patch adds the "check-xl-vif-parse" test script which tests various `rate` syntax.

Changes in v3:
- Move xlu_cfg_init from parse_vif_rate to main_networkattach
- Add xlu_cfg_destroy to main_networkattach
- Use %"PRIuXX" instead of %llu and %lu

Changes in v2:
- Don't default to unlimited in case of overflow/underflow or invalid syntax in rate
- Add error handling
- Remove use of matches in regex which weren't used anyway
- Add docs about the syntax
- Add note in docs explaining that limitations are netback implementation specific
- Modify test cases according to new behavior

--
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMa-0006z9-If; Tue, 24 Apr 2012 15:09:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMZ-0006yg-6O
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:07 +0000
Received: from [85.158.138.51:15157] by server-12.bemta-3.messagelabs.com id
	15/F6-29760-212C69F4; Tue, 24 Apr 2012 15:09:06 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335280145!14639272!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16803 invoked from network); 24 Apr 2012 15:09:05 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-7.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 15:09:05 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id BCC1023A79; Tue, 24 Apr 2012 11:17:32 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,
	MIME_8BIT_HEADER,TW_CF autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 9370523A79;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 2C471281A8; Tue, 24 Apr 2012 11:09:01 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:09 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 v3 RESEND] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch series implements the required plumbering for vif rate limiting in libxl/xl.

The first patch (already applied) fixes trivial indentation issues and introduces no functional changes.

The second patch (already applied) implements dry-run for `xl network-attach` for debugging and testing purposes.

The third patch adds the required plumbering in libxl/xl to add vif rate limiting support. It uses the `rate` option syntax from xm/xend, ensuring full backward compatiblity.

The final patch adds the "check-xl-vif-parse" test script which tests various `rate` syntax.

Changes in v3:
- Move xlu_cfg_init from parse_vif_rate to main_networkattach
- Add xlu_cfg_destroy to main_networkattach
- Use %"PRIuXX" instead of %llu and %lu

Changes in v2:
- Don't default to unlimited in case of overflow/underflow or invalid syntax in rate
- Add error handling
- Remove use of matches in regex which weren't used anyway
- Add docs about the syntax
- Add note in docs explaining that limitations are netback implementation specific
- Modify test cases according to new behavior

--
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMe-00070u-5C; Tue, 24 Apr 2012 15:09:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMb-0006zT-N9
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:10 +0000
Received: from [193.109.254.147:63055] by server-4.bemta-14.messagelabs.com id
	68/D4-11570-512C69F4; Tue, 24 Apr 2012 15:09:09 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335280147!6075511!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2818 invoked from network); 24 Apr 2012 15:09:07 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-4.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 15:09:07 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id A757623C72; Tue, 24 Apr 2012 11:17:34 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: **
X-Spam-Status: No, score=2.3 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_64,
	J_CHICKENPOX_81,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME,TW_BX,TW_CF,
	TW_IB autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 3D8CE23C2E;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 228F8281AB; Tue, 24 Apr 2012 11:09:03 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 4130bb154f3436a9adf45a05462bee2baea41f36
Message-Id: <4130bb154f3436a9adf4.1335280032@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:12 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 v3 RESEND] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIGByYXRlYCBrZXl3b3JkIHNwZWNpZmllcyB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgb3V0Z29p
bmcgdHJhZmZpYwp3aWxsIGJlIGxpbWl0ZWQgdG8uIFRoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29y
ZCBpcyBub3Qgc3BlY2lmaWVkCmlzIHVubGltaXRlZC4KClRoZSBgcmF0ZWAga2V5d29yZCBzdXBw
b3J0cyBhbiBvcHRpb25hbCByZXBsZW5pc2htZW50IGludGVydmFsCnBhcmFtZXRlciBmb3Igc3Bl
Y2lmeWluZyB0aGUgZ3JhbnVsYXJpdHkgb2YgY3JlZGl0IHJlcGxlbmlzaG1lbnQuCkl0IGRldGVy
bWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQK
aXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMuCgpGb3IgZXhhbXBs
ZToKCiAgICAgICAgJ3JhdGU9MTBNYi9zJwogICAgICAgICdyYXRlPTI1MEtCL3MnCiAgICAgICAg
J3JhdGU9MU1CL3NAMjBtcycKClNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2FnbmVA
aXdlYi5jb20+CkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rv
d24gYi9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCi0tLSBhL2Rv
Y3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24KKysrIGIvZG9jcy9taXNj
L3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgpAQCAtMTIyLDUgKzEyMiwzNCBAQCBT
cGVjaWZpZXMgdGhlIGJhY2tlbmQgZG9tYWluIHdoaWNoIHRoaXMgCiBkZWZhdWx0cyB0byBkb21h
aW4gMC4gU3BlY2lmeWluZyBhbm90aGVyIGRvbWFpbiByZXF1aXJlcyBzZXR0aW5nIHVwIGEKIGRy
aXZlciBkb21haW4gd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4K
IAorIyMjIHJhdGUKKworU3BlY2lmaWVzIHRoZSByYXRlIGF0IHdoaWNoIHRoZSBvdXRnb2luZyB0
cmFmZmljIHdpbGwgYmUgbGltaXRlZCB0by4KK1RoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29yZCBp
cyBub3Qgc3BlY2lmaWVkIGlzIHVubGltaXRlZC4KKworVGhlIHJhdGUgbWF5IGJlIHNwZWNpZmll
ZCBhcyAiPFJBVEU+L3MiIG9yIG9wdGlvbmFsbHkgIjxSQVRFPi9zQDxJTlRFUlZBTD4iLgorCisg
ICogYFJBVEVgIGlzIGluIGJ5dGVzIGFuZCBjYW4gYWNjZXB0IHN1ZmZpeGVzOgorICAgICAgKiBH
QiwgTUIsIEtCLCBCIGZvciBieXRlcy4KKyAgICAgICogR2IsIE1iLCBLYiwgYiBmb3IgYml0cy4K
KyAgKiBgSU5URVJWQUxgIGlzIGluIG1pY3Jvc2Vjb25kcyBhbmQgY2FuIGFjY2VwdCBzdWZmaXhl
czogbXMsIHVzLCBzLgorICAgIEl0IGRldGVybWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0
aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQKKyAgICBpcyByZXBsZW5pc2hlZC4gVGhlIGRlZmF1
bHQgaXMgNTBtcy4KKworVmlmIHJhdGUgbGltaXRpbmcgaXMgY3JlZGl0LWJhc2VkLiBJdCBtZWFu
cyB0aGF0IGZvciAiMU1CL3NAMjBtcyIsIHRoZQorYXZhaWxhYmxlIGNyZWRpdCB3aWxsIGJlIGVx
dWl2YWxlbnQgb2YgdGhlIHRyYWZmaWMgeW91IHdvdWxkIGhhdmUgZG9uZQorYXQgIjFNQi9zIiBk
dXJpbmcgMjBtcy4gVGhpcyB3aWxsIHJlc3VsdHMgaW4gYSBjcmVkaXQgb2YgMjAsMDAwIGJ5dGVz
CityZXBsZW5pc2hlZCBldmVyeSAyMCwwMDAgdXMuCisKK0ZvciBleGFtcGxlOgorCisgICAgICAg
ICdyYXRlPTEwTWIvcycgLS0gbWVhbmluZyB1cCB0byAxMCBtZWdhYml0cyBldmVyeSBzZWNvbmQK
KyAgICAgICAgJ3JhdGU9MjUwS0IvcycgLS0gbWVhbmluZyB1cCB0byAyNTAga2lsb2J5dGVzIGV2
ZXJ5IHNlY29uZAorICAgICAgICAncmF0ZT0xTUIvc0AyMG1zJyAtLSBtZWFuaW5nIDIwLDAwMCBi
eXRlcyBpbiBldmVyeSAyMCBtaWxsaXNlY29uZCBwZXJpb2QKKworTk9URTogVGhlIGFjdHVhbCB1
bmRlcmx5aW5nIGxpbWl0cyBvZiByYXRlIGxpbWl0aW5nIGFyZSBkZXBlbmRlbnQKK29uIHRoZSB1
bmRlcmx5aW5nIG5ldGJhY2sgaW1wbGVtZW50YXRpb24uCisKKwogW291aV06IGh0dHA6Ly9lbi53
aWtpcGVkaWEub3JnL3dpa2kvT3JnYW5pemF0aW9uYWxseV9VbmlxdWVfSWRlbnRpZmllcgogW25l
dF06IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Ib3N0Q29uZmlndXJhdGlvbi9OZXR3b3JraW5n
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9NYWtlZmlsZSBiL3Rvb2xzL2xpYnhsL01ha2VmaWxl
Ci0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCkBA
IC02MSw3ICs2MSw3IEBAIExJQlhMX09CSlMgKz0gX2xpYnhsX3R5cGVzLm8gbGlieGxfZmxhc2sK
IEFVVE9JTkNTPSBsaWJ4bHVfY2ZnX3kuaCBsaWJ4bHVfY2ZnX2wuaCBfbGlieGxfbGlzdC5oCiBB
VVRPU1JDUz0gbGlieGx1X2NmZ195LmMgbGlieGx1X2NmZ19sLmMKIExJQlhMVV9PQkpTID0gbGli
eGx1X2NmZ195Lm8gbGlieGx1X2NmZ19sLm8gbGlieGx1X2NmZy5vIFwKLQlsaWJ4bHVfZGlza19s
Lm8gbGlieGx1X2Rpc2subyBsaWJ4bHVfcGNpLm8KKwlsaWJ4bHVfZGlza19sLm8gbGlieGx1X2Rp
c2subyBsaWJ4bHVfdmlmLm8gbGlieGx1X3BjaS5vCiAkKExJQlhMVV9PQkpTKTogQ0ZMQUdTICs9
ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICMgRm9yIHhlbnRvb2xsb2cuaAogCiBDTElFTlRTID0geGwg
dGVzdGlkbApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xp
YnhsLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGwuYworKysgYi90b29scy9saWJ4bC9saWJ4bC5j
CkBAIC0xODU0LDYgKzE4NTQsMTMgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRkKGxpYnhsX2N0
eCAqY3R4LAogICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2Ms
IG5pYy0+aXApKTsKICAgICB9CiAKKyAgICBpZiAobmljLT5yYXRlX2ludGVydmFsX3VzZWNzID4g
MCkgeworICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJyYXRlIik7CisgICAgICAgIGZs
ZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3NwcmludGYoZ2MsICIlIlBSSXU2NCIsJSJQUkl1
MzIiIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2lu
dGVydmFsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pYy0+cmF0ZV9pbnRlcnZhbF91
c2VjcykpOworICAgIH0KKwogICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgImJyaWRnZSIpOwog
ICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5icmlkZ2Up
KTsKICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJoYW5kbGUiKTsKZGlmZiAtLWdpdCBhL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCkBAIC0zNDMsNiArMzQzLDggQEAgbGlieGxfZGV2aWNlX25pYyA9IFN0cnVjdCgi
ZGV2aWNlX25pYyIsIAogICAgICgiaWZuYW1lIiwgc3RyaW5nKSwKICAgICAoInNjcmlwdCIsIHN0
cmluZyksCiAgICAgKCJuaWN0eXBlIiwgbGlieGxfbmljX3R5cGUpLAorICAgICgicmF0ZV9ieXRl
c19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAorICAgICgicmF0ZV9pbnRlcnZhbF91c2VjcyIsIHVp
bnQzMiksCiAgICAgXSkKIAogbGlieGxfZGV2aWNlX3BjaSA9IFN0cnVjdCgiZGV2aWNlX3BjaSIs
IFsKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oIGIvdG9vbHMvbGli
eGwvbGlieGx1X2ludGVybmFsLmgKLS0tIGEvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgK
KysrIGIvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgKQEAgLTE3LDkgKzE3LDExIEBACiAj
ZGVmaW5lIExJQlhMVV9JTlRFUk5BTF9ICiAKICNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUg
PHN0ZGxpYi5oPgogI2luY2x1ZGUgPGVycm5vLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5j
bHVkZSA8YXNzZXJ0Lmg+CisjaW5jbHVkZSA8cmVnZXguaD4KIAogI2RlZmluZSBYTFVfQ29uZmln
TGlzdCBYTFVfQ29uZmlnU2V0dGluZwogCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bHVf
dmlmLmMgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0t
IC9kZXYvbnVsbAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKQEAgLTAsMCArMSwxNDEg
QEAKKyNpbmNsdWRlICJsaWJ4bF9vc2RlcHMuaCIgLyogbXVzdCBjb21lIGJlZm9yZSBhbnkgb3Ro
ZXIgaGVhZGVycyAqLworI2luY2x1ZGUgImxpYnhsdV9pbnRlcm5hbC5oIgorCitzdGF0aWMgY29u
c3QgY2hhciAqdmlmX2J5dGVzX3Blcl9zZWNfcmUgPSAiXlswLTldK1tHTUtdP1tCYl0vcyQiOwor
c3RhdGljIGNvbnN0IGNoYXIgKnZpZl9pbnRlcm5hbF91c2VjX3JlID0gIl5bMC05XStbbXVdP3M/
JCI7CisKK3N0YXRpYyB2b2lkIHhsdV9fdmlmX2VycihYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKm1zZywgY29uc3QgY2hhciAqcmF0ZSkgeworICAgIGZwcmludGYoY2ZnLT5yZXBvcnQsCisg
ICAgICAgICAgICAiJXM6IGNvbmZpZyBwYXJzaW5nIGVycm9yIGluIHZpZjogJXMgaW4gYCVzJ1xu
IiwKKyAgICAgICAgICAgIGNmZy0+ZmlsZW5hbWUsIG1zZywgcmF0ZSk7Cit9CisKK3N0YXRpYyBp
bnQgdmlmX3BhcnNlX3JhdGVfYnl0ZXNfcGVyX3NlYyhYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKmJ5dGVzLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2
NF90ICpieXRlc19wZXJfc2VjKQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRt
cCA9IDA7CisgICAgY29uc3QgY2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29t
cCgmcmVjLCB2aWZfYnl0ZXNfcGVyX3NlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7Cisg
ICAgaWYgKHJlZ2V4ZWMoJnJlYywgYnl0ZXMsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9f
dmlmX2VycihjZmcsICJpbnZhbGlkIHJhdGUiLCBieXRlcyk7CisgICAgICAgIHJjID0gRUlOVkFM
OworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gYnl0ZXM7CisgICAgdG1wID0g
c3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8IHRtcCA+IFVJ
TlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcs
ICJyYXRlIG92ZXJmbG93IiwgYnl0ZXMpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgaWYgKCpwID09ICdHJykKKyAgICAgICB0bXAgKj0g
MTAwMCAqIDEwMDAgKiAxMDAwOworICAgIGVsc2UgaWYgKCpwID09ICdNJykKKyAgICAgICB0bXAg
Kj0gMTAwMCAqIDEwMDA7CisgICAgZWxzZSBpZiAoKnAgPT0gJ0snKQorICAgICAgIHRtcCAqPSAx
MDAwOworICAgIGlmICgqcCA9PSAnYicgfHwgKihwKzEpID09ICdiJykKKyAgICAgICB0bXAgLz0g
ODsKKworICAgICpieXRlc19wZXJfc2VjID0gdG1wOworCitvdXQ6CisgICAgcmVnZnJlZSgmcmVj
KTsKKyAgICByZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBpbnQgdmlmX3BhcnNlX3JhdGVfaW50ZXJ2
YWxfdXNlY3MoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICppbnRlcnZhbCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgKmludGVydmFsX3VzZWNz
KQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRtcCA9IDA7CisgICAgY29uc3Qg
Y2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29tcCgmcmVjLCB2aWZfaW50ZXJu
YWxfdXNlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7CisgICAgaWYgKHJlZ2V4ZWMoJnJl
YywgaW50ZXJ2YWwsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJp
bnZhbGlkIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwiLCBpbnRlcnZhbCk7CisgICAgICAgIHJjID0g
RUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gaW50ZXJ2YWw7Cisg
ICAgdG1wID0gc3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8
IHRtcCA+IFVJTlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlm
X2VycihjZmcsICJyZXBsZW5pc2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOwor
ICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAg
aWYgKCpwID09ICdzJyB8fCAqcCA9PSAnXDAnKQorICAgICAgICB0bXAgKj0gMTAwMCAqIDEwMDA7
CisgICAgZWxzZSBpZiAoKnAgPT0gJ20nKQorICAgICAgICB0bXAgKj0gMTAwMDsKKworICAgIGlm
ICh0bXAgPiBVSU5UMzJfTUFYKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJyZXBsZW5p
c2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOworICAgICAgICByYyA9IEVPVkVS
RkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAgKmludGVydmFsX3VzZWNzID0g
KHVpbnQzMl90KSB0bXA7CisKK291dDoKKyAgICByZWdmcmVlKCZyZWMpOworICAgIHJldHVybiBy
YzsKK30KKworaW50IHhsdV92aWZfcGFyc2VfcmF0ZShYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKnJhdGUsIGxpYnhsX2RldmljZV9uaWMgKm5pYykKK3sKKyAgICB1aW50NjRfdCBieXRlc19w
ZXJfc2VjID0gMDsKKyAgICB1aW50NjRfdCBieXRlc19wZXJfaW50ZXJ2YWwgPSAwOworICAgIHVp
bnQzMl90IGludGVydmFsX3VzZWNzID0gNTAwMDBVTDsgLyogRGVmYXVsdCB0byA1MG1zICovCisg
ICAgY2hhciAqcmF0ZXRvaywgKnRtcHJhdGU7CisgICAgaW50IHJjID0gMDsKKworICAgIHRtcHJh
dGUgPSBzdHJkdXAocmF0ZSk7CisgICAgaWYgKCFzdHJjbXAodG1wcmF0ZSwiIikpIHsKKyAgICAg
ICAgeGx1X192aWZfZXJyKGNmZywgIm5vIHJhdGUgc3BlY2lmaWVkIiwgcmF0ZSk7CisgICAgICAg
IHJjID0gRUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICByYXRldG9rID0g
c3RydG9rKHRtcHJhdGUsICJAIik7CisgICAgcmMgPSB2aWZfcGFyc2VfcmF0ZV9ieXRlc19wZXJf
c2VjKGNmZywgcmF0ZXRvaywgJmJ5dGVzX3Blcl9zZWMpOworICAgIGlmIChyYykgZ290byBvdXQ7
CisKKyAgICByYXRldG9rID0gc3RydG9rKE5VTEwsICJAIik7CisgICAgaWYgKHJhdGV0b2sgIT0g
TlVMTCkgeworICAgICAgICByYyA9IHZpZl9wYXJzZV9yYXRlX2ludGVydmFsX3VzZWNzKGNmZywg
cmF0ZXRvaywgJmludGVydmFsX3VzZWNzKTsKKyAgICAgICAgaWYgKHJjKSBnb3RvIG91dDsKKyAg
ICB9CisKKyAgICBpZiAoaW50ZXJ2YWxfdXNlY3MgIT0gMCAmJiAoYnl0ZXNfcGVyX3NlYyA+IChV
SU5UNjRfTUFYIC8gaW50ZXJ2YWxfdXNlY3MpKSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2Zn
LCAicmF0ZSBvdmVyZmxvdyIsIHJhdGUpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgYnl0ZXNfcGVyX2ludGVydmFsID0KKyAgICAgICAg
KCgodWludDY0X3QpIGJ5dGVzX3Blcl9zZWMgKiAodWludDY0X3QpIGludGVydmFsX3VzZWNzKSAv
IDEwMDAwMDBVTCk7CisKKyAgICBuaWMtPnJhdGVfaW50ZXJ2YWxfdXNlY3MgPSBpbnRlcnZhbF91
c2VjczsKKyAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsID0gYnl0ZXNfcGVyX2ludGVy
dmFsOworCitvdXQ6CisgICAgZnJlZSh0bXByYXRlKTsKKyAgICByZXR1cm4gcmM7Cit9CisKKy8q
CisgKiBMb2NhbCB2YXJpYWJsZXM6CisgKiBtb2RlOiBDCisgKiBjLWJhc2ljLW9mZnNldDogNAor
ICogaW5kZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8KZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL2xpYnhsdXRpbC5oIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGx1dGlsLmgKKysrIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKQEAgLTk0LDYg
Kzk0LDEzIEBAIGludCB4bHVfZGlza19wYXJzZShYTFVfQ29uZmlnICpjZmcsIGludCAKIGludCB4
bHVfcGNpX3BhcnNlX2JkZihYTFVfQ29uZmlnICpjZmcsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRl
diwgY29uc3QgY2hhciAqc3RyKTsKIAogCisvKgorICogVmlmIHJhdGUgcGFyc2luZy4KKyAqLwor
CitpbnQgeGx1X3ZpZl9wYXJzZV9yYXRlKFhMVV9Db25maWcgKmNmZywgY29uc3QgY2hhciAqcmF0
ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfZGV2aWNlX25pYyAqbmljKTsKKwogI2Vu
ZGlmIC8qIExJQlhMVVRJTF9IICovCiAKIC8qCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9j
bWRpbXBsLmMgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtNDAzLDYgKzQwMywx
OSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9kaXNrX2NvbmZpZyhYTFVfQ29uZmlnCiAgICAgcGFyc2Vf
ZGlza19jb25maWdfbXVsdGlzdHJpbmcoY29uZmlnLCAxLCAmc3BlYywgZGlzayk7CiB9CiAKK3N0
YXRpYyB2b2lkIHBhcnNlX3ZpZl9yYXRlKFhMVV9Db25maWcgKipjb25maWcsIGNvbnN0IGNoYXIg
KnJhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZpY2VfbmljICpuaWMp
Cit7CisgICAgaW50IGU7CisKKyAgICBlID0geGx1X3ZpZl9wYXJzZV9yYXRlKCpjb25maWcsIHJh
dGUsIG5pYyk7CisgICAgaWYgKGUgPT0gRUlOVkFMIHx8IGUgPT0gRU9WRVJGTE9XKSBleGl0KC0x
KTsKKyAgICBpZiAoZSkgeworICAgICAgICBmcHJpbnRmKHN0ZGVyciwieGx1X3ZpZl9wYXJzZV9y
YXRlIGZhaWxlZDogJXNcbiIsc3RyZXJyb3IoZXJybm8pKTsKKyAgICAgICAgZXhpdCgtMSk7Cisg
ICAgfQorfQorCiBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJpbmdfbGlzdChjb25z
dCBjaGFyICpzdHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
b25zdCBjaGFyICpkZWxpbSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX3N0cmluZ19saXN0ICpwc2wpCkBAIC05MDYsNyArOTE5LDcgQEAgc3RhdGljIHZv
aWQgcGFyc2VfY29uZmlnX2RhdGEoY29uc3QgY2hhcgogICAgICAgICAgICAgICAgICAgICAgICAg
bmljLT5iYWNrZW5kX2RvbWlkID0gMDsKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAg
ICAgICAgIH0gZWxzZSBpZiAoIXN0cmNtcChwLCAicmF0ZSIpKSB7Ci0gICAgICAgICAgICAgICAg
ICAgIGZwcmludGYoc3RkZXJyLCAidGhlIHJhdGUgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJl
bnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKKyAgICAgICAgICAgICAgICAgICAgcGFyc2VfdmlmX3Jh
dGUoJmNvbmZpZywgKHAyICsgMSksIG5pYyk7CiAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICgh
c3RyY21wKHAsICJhY2NlbCIpKSB7CiAgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJy
LCAidGhlIGFjY2VsIHBhcmFtZXRlciBmb3IgdmlmcyBpcyBjdXJyZW50bHkgbm90IHN1cHBvcnRl
ZFxuIik7CiAgICAgICAgICAgICAgICAgfQpAQCAtNDg1NSw2ICs0ODY4LDcgQEAgaW50IG1haW5f
bmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAqKgogewogICAgIGludCBvcHQ7CiAgICAgbGli
eGxfZGV2aWNlX25pYyBuaWM7CisgICAgWExVX0NvbmZpZyAqY29uZmlnID0gMDsKICAgICBjaGFy
ICplbmRwdHIsICpvcGFyZzsKICAgICBjb25zdCBjaGFyICp0b2s7CiAgICAgaW50IGk7CkBAIC00
ODcyLDYgKzQ4ODYsMTMgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIiVzIGlzIGFuIGludmFsaWQgZG9tYWluIGlkZW50
aWZpZXJcbiIsIGFyZ3Zbb3B0aW5kXSk7CiAgICAgICAgIHJldHVybiAxOwogICAgIH0KKworICAg
IGNvbmZpZz0geGx1X2NmZ19pbml0KHN0ZGVyciwgImNvbW1hbmQgbGluZSIpOworICAgIGlmICgh
Y29uZmlnKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRmFpbGVkIHRvIGFsbG9jYXRlIGZv
ciBjb25maWd1cmF0aW9uXG4iKTsKKyAgICAgICAgcmV0dXJuIDE7CisgICAgfQorCiAgICAgbGli
eGxfZGV2aWNlX25pY19pbml0KCZuaWMpOwogICAgIGZvciAoYXJndiArPSBvcHRpbmQrMSwgYXJn
YyAtPSBvcHRpbmQrMTsgYXJnYyA+IDA7ICsrYXJndiwgLS1hcmdjKSB7CiAgICAgICAgIGlmIChN
QVRDSF9PUFRJT04oInR5cGUiLCAqYXJndiwgb3BhcmcpKSB7CkBAIC00OTEwLDYgKzQ5MzEsNyBA
QCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCiAgICAgICAgIH0gZWxz
ZSBpZiAoTUFUQ0hfT1BUSU9OKCJtb2RlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgICAg
IHJlcGxhY2Vfc3RyaW5nKCZuaWMubW9kZWwsIG9wYXJnKTsKICAgICAgICAgfSBlbHNlIGlmIChN
QVRDSF9PUFRJT04oInJhdGUiLCAqYXJndiwgb3BhcmcpKSB7CisgICAgICAgICAgICBwYXJzZV92
aWZfcmF0ZSgmY29uZmlnLCBvcGFyZywgJm5pYyk7CiAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hf
T1BUSU9OKCJhY2NlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgfSBlbHNlIHsKICAgICAg
ICAgICAgIGZwcmludGYoc3RkZXJyLCAidW5yZWNvZ25pemVkIGFyZ3VtZW50IGAlcydcbiIsICph
cmd2KTsKQEAgLTQ5MzEsNiArNDk1Myw3IEBAIGludCBtYWluX25ldHdvcmthdHRhY2goaW50IGFy
Z2MsIGNoYXIgKioKICAgICAgICAgcmV0dXJuIDE7CiAgICAgfQogICAgIGxpYnhsX2RldmljZV9u
aWNfZGlzcG9zZSgmbmljKTsKKyAgICB4bHVfY2ZnX2Rlc3Ryb3koY29uZmlnKTsKICAgICByZXR1
cm4gMDsKIH0KIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMe-00070u-5C; Tue, 24 Apr 2012 15:09:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMb-0006zT-N9
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:10 +0000
Received: from [193.109.254.147:63055] by server-4.bemta-14.messagelabs.com id
	68/D4-11570-512C69F4; Tue, 24 Apr 2012 15:09:09 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335280147!6075511!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2818 invoked from network); 24 Apr 2012 15:09:07 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-4.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 15:09:07 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id A757623C72; Tue, 24 Apr 2012 11:17:34 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: **
X-Spam-Status: No, score=2.3 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_64,
	J_CHICKENPOX_81,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME,TW_BX,TW_CF,
	TW_IB autolearn=no version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 3D8CE23C2E;
	Tue, 24 Apr 2012 11:17:30 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 228F8281AB; Tue, 24 Apr 2012 11:09:03 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: 4130bb154f3436a9adf45a05462bee2baea41f36
Message-Id: <4130bb154f3436a9adf4.1335280032@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:12 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 v3 RESEND] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIGByYXRlYCBrZXl3b3JkIHNwZWNpZmllcyB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgb3V0Z29p
bmcgdHJhZmZpYwp3aWxsIGJlIGxpbWl0ZWQgdG8uIFRoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29y
ZCBpcyBub3Qgc3BlY2lmaWVkCmlzIHVubGltaXRlZC4KClRoZSBgcmF0ZWAga2V5d29yZCBzdXBw
b3J0cyBhbiBvcHRpb25hbCByZXBsZW5pc2htZW50IGludGVydmFsCnBhcmFtZXRlciBmb3Igc3Bl
Y2lmeWluZyB0aGUgZ3JhbnVsYXJpdHkgb2YgY3JlZGl0IHJlcGxlbmlzaG1lbnQuCkl0IGRldGVy
bWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQK
aXMgcmVwbGVuaXNoZWQuIFRoZSBkZWZhdWx0IGludGVydmFsIGlzIDUwbXMuCgpGb3IgZXhhbXBs
ZToKCiAgICAgICAgJ3JhdGU9MTBNYi9zJwogICAgICAgICdyYXRlPTI1MEtCL3MnCiAgICAgICAg
J3JhdGU9MU1CL3NAMjBtcycKClNpZ25lZC1vZmYtYnk6IE1hdGhpZXUgR2FnbsOpIDxtZ2FnbmVA
aXdlYi5jb20+CkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rv
d24gYi9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCi0tLSBhL2Rv
Y3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24KKysrIGIvZG9jcy9taXNj
L3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgpAQCAtMTIyLDUgKzEyMiwzNCBAQCBT
cGVjaWZpZXMgdGhlIGJhY2tlbmQgZG9tYWluIHdoaWNoIHRoaXMgCiBkZWZhdWx0cyB0byBkb21h
aW4gMC4gU3BlY2lmeWluZyBhbm90aGVyIGRvbWFpbiByZXF1aXJlcyBzZXR0aW5nIHVwIGEKIGRy
aXZlciBkb21haW4gd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4K
IAorIyMjIHJhdGUKKworU3BlY2lmaWVzIHRoZSByYXRlIGF0IHdoaWNoIHRoZSBvdXRnb2luZyB0
cmFmZmljIHdpbGwgYmUgbGltaXRlZCB0by4KK1RoZSBkZWZhdWx0IGlmIHRoaXMga2V5d29yZCBp
cyBub3Qgc3BlY2lmaWVkIGlzIHVubGltaXRlZC4KKworVGhlIHJhdGUgbWF5IGJlIHNwZWNpZmll
ZCBhcyAiPFJBVEU+L3MiIG9yIG9wdGlvbmFsbHkgIjxSQVRFPi9zQDxJTlRFUlZBTD4iLgorCisg
ICogYFJBVEVgIGlzIGluIGJ5dGVzIGFuZCBjYW4gYWNjZXB0IHN1ZmZpeGVzOgorICAgICAgKiBH
QiwgTUIsIEtCLCBCIGZvciBieXRlcy4KKyAgICAgICogR2IsIE1iLCBLYiwgYiBmb3IgYml0cy4K
KyAgKiBgSU5URVJWQUxgIGlzIGluIG1pY3Jvc2Vjb25kcyBhbmQgY2FuIGFjY2VwdCBzdWZmaXhl
czogbXMsIHVzLCBzLgorICAgIEl0IGRldGVybWluZXMgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0
aGUgdmlmIHRyYW5zbWlzc2lvbiBjcmVkaXQKKyAgICBpcyByZXBsZW5pc2hlZC4gVGhlIGRlZmF1
bHQgaXMgNTBtcy4KKworVmlmIHJhdGUgbGltaXRpbmcgaXMgY3JlZGl0LWJhc2VkLiBJdCBtZWFu
cyB0aGF0IGZvciAiMU1CL3NAMjBtcyIsIHRoZQorYXZhaWxhYmxlIGNyZWRpdCB3aWxsIGJlIGVx
dWl2YWxlbnQgb2YgdGhlIHRyYWZmaWMgeW91IHdvdWxkIGhhdmUgZG9uZQorYXQgIjFNQi9zIiBk
dXJpbmcgMjBtcy4gVGhpcyB3aWxsIHJlc3VsdHMgaW4gYSBjcmVkaXQgb2YgMjAsMDAwIGJ5dGVz
CityZXBsZW5pc2hlZCBldmVyeSAyMCwwMDAgdXMuCisKK0ZvciBleGFtcGxlOgorCisgICAgICAg
ICdyYXRlPTEwTWIvcycgLS0gbWVhbmluZyB1cCB0byAxMCBtZWdhYml0cyBldmVyeSBzZWNvbmQK
KyAgICAgICAgJ3JhdGU9MjUwS0IvcycgLS0gbWVhbmluZyB1cCB0byAyNTAga2lsb2J5dGVzIGV2
ZXJ5IHNlY29uZAorICAgICAgICAncmF0ZT0xTUIvc0AyMG1zJyAtLSBtZWFuaW5nIDIwLDAwMCBi
eXRlcyBpbiBldmVyeSAyMCBtaWxsaXNlY29uZCBwZXJpb2QKKworTk9URTogVGhlIGFjdHVhbCB1
bmRlcmx5aW5nIGxpbWl0cyBvZiByYXRlIGxpbWl0aW5nIGFyZSBkZXBlbmRlbnQKK29uIHRoZSB1
bmRlcmx5aW5nIG5ldGJhY2sgaW1wbGVtZW50YXRpb24uCisKKwogW291aV06IGh0dHA6Ly9lbi53
aWtpcGVkaWEub3JnL3dpa2kvT3JnYW5pemF0aW9uYWxseV9VbmlxdWVfSWRlbnRpZmllcgogW25l
dF06IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Ib3N0Q29uZmlndXJhdGlvbi9OZXR3b3JraW5n
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9NYWtlZmlsZSBiL3Rvb2xzL2xpYnhsL01ha2VmaWxl
Ci0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCkBA
IC02MSw3ICs2MSw3IEBAIExJQlhMX09CSlMgKz0gX2xpYnhsX3R5cGVzLm8gbGlieGxfZmxhc2sK
IEFVVE9JTkNTPSBsaWJ4bHVfY2ZnX3kuaCBsaWJ4bHVfY2ZnX2wuaCBfbGlieGxfbGlzdC5oCiBB
VVRPU1JDUz0gbGlieGx1X2NmZ195LmMgbGlieGx1X2NmZ19sLmMKIExJQlhMVV9PQkpTID0gbGli
eGx1X2NmZ195Lm8gbGlieGx1X2NmZ19sLm8gbGlieGx1X2NmZy5vIFwKLQlsaWJ4bHVfZGlza19s
Lm8gbGlieGx1X2Rpc2subyBsaWJ4bHVfcGNpLm8KKwlsaWJ4bHVfZGlza19sLm8gbGlieGx1X2Rp
c2subyBsaWJ4bHVfdmlmLm8gbGlieGx1X3BjaS5vCiAkKExJQlhMVV9PQkpTKTogQ0ZMQUdTICs9
ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICMgRm9yIHhlbnRvb2xsb2cuaAogCiBDTElFTlRTID0geGwg
dGVzdGlkbApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xp
YnhsLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGwuYworKysgYi90b29scy9saWJ4bC9saWJ4bC5j
CkBAIC0xODU0LDYgKzE4NTQsMTMgQEAgaW50IGxpYnhsX2RldmljZV9uaWNfYWRkKGxpYnhsX2N0
eCAqY3R4LAogICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2Ms
IG5pYy0+aXApKTsKICAgICB9CiAKKyAgICBpZiAobmljLT5yYXRlX2ludGVydmFsX3VzZWNzID4g
MCkgeworICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJyYXRlIik7CisgICAgICAgIGZs
ZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3NwcmludGYoZ2MsICIlIlBSSXU2NCIsJSJQUkl1
MzIiIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2lu
dGVydmFsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pYy0+cmF0ZV9pbnRlcnZhbF91
c2VjcykpOworICAgIH0KKwogICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgImJyaWRnZSIpOwog
ICAgIGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5icmlkZ2Up
KTsKICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJoYW5kbGUiKTsKZGlmZiAtLWdpdCBhL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCkBAIC0zNDMsNiArMzQzLDggQEAgbGlieGxfZGV2aWNlX25pYyA9IFN0cnVjdCgi
ZGV2aWNlX25pYyIsIAogICAgICgiaWZuYW1lIiwgc3RyaW5nKSwKICAgICAoInNjcmlwdCIsIHN0
cmluZyksCiAgICAgKCJuaWN0eXBlIiwgbGlieGxfbmljX3R5cGUpLAorICAgICgicmF0ZV9ieXRl
c19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAorICAgICgicmF0ZV9pbnRlcnZhbF91c2VjcyIsIHVp
bnQzMiksCiAgICAgXSkKIAogbGlieGxfZGV2aWNlX3BjaSA9IFN0cnVjdCgiZGV2aWNlX3BjaSIs
IFsKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9pbnRlcm5hbC5oIGIvdG9vbHMvbGli
eGwvbGlieGx1X2ludGVybmFsLmgKLS0tIGEvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgK
KysrIGIvdG9vbHMvbGlieGwvbGlieGx1X2ludGVybmFsLmgKQEAgLTE3LDkgKzE3LDExIEBACiAj
ZGVmaW5lIExJQlhMVV9JTlRFUk5BTF9ICiAKICNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUg
PHN0ZGxpYi5oPgogI2luY2x1ZGUgPGVycm5vLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5j
bHVkZSA8YXNzZXJ0Lmg+CisjaW5jbHVkZSA8cmVnZXguaD4KIAogI2RlZmluZSBYTFVfQ29uZmln
TGlzdCBYTFVfQ29uZmlnU2V0dGluZwogCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bHVf
dmlmLmMgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0t
IC9kZXYvbnVsbAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfdmlmLmMKQEAgLTAsMCArMSwxNDEg
QEAKKyNpbmNsdWRlICJsaWJ4bF9vc2RlcHMuaCIgLyogbXVzdCBjb21lIGJlZm9yZSBhbnkgb3Ro
ZXIgaGVhZGVycyAqLworI2luY2x1ZGUgImxpYnhsdV9pbnRlcm5hbC5oIgorCitzdGF0aWMgY29u
c3QgY2hhciAqdmlmX2J5dGVzX3Blcl9zZWNfcmUgPSAiXlswLTldK1tHTUtdP1tCYl0vcyQiOwor
c3RhdGljIGNvbnN0IGNoYXIgKnZpZl9pbnRlcm5hbF91c2VjX3JlID0gIl5bMC05XStbbXVdP3M/
JCI7CisKK3N0YXRpYyB2b2lkIHhsdV9fdmlmX2VycihYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKm1zZywgY29uc3QgY2hhciAqcmF0ZSkgeworICAgIGZwcmludGYoY2ZnLT5yZXBvcnQsCisg
ICAgICAgICAgICAiJXM6IGNvbmZpZyBwYXJzaW5nIGVycm9yIGluIHZpZjogJXMgaW4gYCVzJ1xu
IiwKKyAgICAgICAgICAgIGNmZy0+ZmlsZW5hbWUsIG1zZywgcmF0ZSk7Cit9CisKK3N0YXRpYyBp
bnQgdmlmX3BhcnNlX3JhdGVfYnl0ZXNfcGVyX3NlYyhYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKmJ5dGVzLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2
NF90ICpieXRlc19wZXJfc2VjKQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRt
cCA9IDA7CisgICAgY29uc3QgY2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29t
cCgmcmVjLCB2aWZfYnl0ZXNfcGVyX3NlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7Cisg
ICAgaWYgKHJlZ2V4ZWMoJnJlYywgYnl0ZXMsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9f
dmlmX2VycihjZmcsICJpbnZhbGlkIHJhdGUiLCBieXRlcyk7CisgICAgICAgIHJjID0gRUlOVkFM
OworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gYnl0ZXM7CisgICAgdG1wID0g
c3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8IHRtcCA+IFVJ
TlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcs
ICJyYXRlIG92ZXJmbG93IiwgYnl0ZXMpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgaWYgKCpwID09ICdHJykKKyAgICAgICB0bXAgKj0g
MTAwMCAqIDEwMDAgKiAxMDAwOworICAgIGVsc2UgaWYgKCpwID09ICdNJykKKyAgICAgICB0bXAg
Kj0gMTAwMCAqIDEwMDA7CisgICAgZWxzZSBpZiAoKnAgPT0gJ0snKQorICAgICAgIHRtcCAqPSAx
MDAwOworICAgIGlmICgqcCA9PSAnYicgfHwgKihwKzEpID09ICdiJykKKyAgICAgICB0bXAgLz0g
ODsKKworICAgICpieXRlc19wZXJfc2VjID0gdG1wOworCitvdXQ6CisgICAgcmVnZnJlZSgmcmVj
KTsKKyAgICByZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBpbnQgdmlmX3BhcnNlX3JhdGVfaW50ZXJ2
YWxfdXNlY3MoWExVX0NvbmZpZyAqY2ZnLCBjb25zdCBjaGFyICppbnRlcnZhbCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgKmludGVydmFsX3VzZWNz
KQoreworICAgIHJlZ2V4X3QgcmVjOworICAgIHVpbnQ2NF90IHRtcCA9IDA7CisgICAgY29uc3Qg
Y2hhciAqcDsKKyAgICBpbnQgcmMgPSAwOworCisgICAgcmVnY29tcCgmcmVjLCB2aWZfaW50ZXJu
YWxfdXNlY19yZSwgUkVHX0VYVEVOREVEfFJFR19OT1NVQik7CisgICAgaWYgKHJlZ2V4ZWMoJnJl
YywgaW50ZXJ2YWwsIDAsIE5VTEwsIDApKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJp
bnZhbGlkIHJlcGxlbmlzaG1lbnQgaW50ZXJ2YWwiLCBpbnRlcnZhbCk7CisgICAgICAgIHJjID0g
RUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICBwID0gaW50ZXJ2YWw7Cisg
ICAgdG1wID0gc3RydG91bGwocCwgKGNoYXIqKikmcCwgMCk7CisgICAgaWYgKHRtcCA9PSAwIHx8
IHRtcCA+IFVJTlQzMl9NQVggfHwgZXJybm8gPT0gRVJBTkdFKSB7CisgICAgICAgIHhsdV9fdmlm
X2VycihjZmcsICJyZXBsZW5pc2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOwor
ICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAg
aWYgKCpwID09ICdzJyB8fCAqcCA9PSAnXDAnKQorICAgICAgICB0bXAgKj0gMTAwMCAqIDEwMDA7
CisgICAgZWxzZSBpZiAoKnAgPT0gJ20nKQorICAgICAgICB0bXAgKj0gMTAwMDsKKworICAgIGlm
ICh0bXAgPiBVSU5UMzJfTUFYKSB7CisgICAgICAgIHhsdV9fdmlmX2VycihjZmcsICJyZXBsZW5p
c2htZW50IGludGVydmFsIG92ZXJmbG93IiwgaW50ZXJ2YWwpOworICAgICAgICByYyA9IEVPVkVS
RkxPVzsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCisgICAgKmludGVydmFsX3VzZWNzID0g
KHVpbnQzMl90KSB0bXA7CisKK291dDoKKyAgICByZWdmcmVlKCZyZWMpOworICAgIHJldHVybiBy
YzsKK30KKworaW50IHhsdV92aWZfcGFyc2VfcmF0ZShYTFVfQ29uZmlnICpjZmcsIGNvbnN0IGNo
YXIgKnJhdGUsIGxpYnhsX2RldmljZV9uaWMgKm5pYykKK3sKKyAgICB1aW50NjRfdCBieXRlc19w
ZXJfc2VjID0gMDsKKyAgICB1aW50NjRfdCBieXRlc19wZXJfaW50ZXJ2YWwgPSAwOworICAgIHVp
bnQzMl90IGludGVydmFsX3VzZWNzID0gNTAwMDBVTDsgLyogRGVmYXVsdCB0byA1MG1zICovCisg
ICAgY2hhciAqcmF0ZXRvaywgKnRtcHJhdGU7CisgICAgaW50IHJjID0gMDsKKworICAgIHRtcHJh
dGUgPSBzdHJkdXAocmF0ZSk7CisgICAgaWYgKCFzdHJjbXAodG1wcmF0ZSwiIikpIHsKKyAgICAg
ICAgeGx1X192aWZfZXJyKGNmZywgIm5vIHJhdGUgc3BlY2lmaWVkIiwgcmF0ZSk7CisgICAgICAg
IHJjID0gRUlOVkFMOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKKyAgICByYXRldG9rID0g
c3RydG9rKHRtcHJhdGUsICJAIik7CisgICAgcmMgPSB2aWZfcGFyc2VfcmF0ZV9ieXRlc19wZXJf
c2VjKGNmZywgcmF0ZXRvaywgJmJ5dGVzX3Blcl9zZWMpOworICAgIGlmIChyYykgZ290byBvdXQ7
CisKKyAgICByYXRldG9rID0gc3RydG9rKE5VTEwsICJAIik7CisgICAgaWYgKHJhdGV0b2sgIT0g
TlVMTCkgeworICAgICAgICByYyA9IHZpZl9wYXJzZV9yYXRlX2ludGVydmFsX3VzZWNzKGNmZywg
cmF0ZXRvaywgJmludGVydmFsX3VzZWNzKTsKKyAgICAgICAgaWYgKHJjKSBnb3RvIG91dDsKKyAg
ICB9CisKKyAgICBpZiAoaW50ZXJ2YWxfdXNlY3MgIT0gMCAmJiAoYnl0ZXNfcGVyX3NlYyA+IChV
SU5UNjRfTUFYIC8gaW50ZXJ2YWxfdXNlY3MpKSkgeworICAgICAgICB4bHVfX3ZpZl9lcnIoY2Zn
LCAicmF0ZSBvdmVyZmxvdyIsIHJhdGUpOworICAgICAgICByYyA9IEVPVkVSRkxPVzsKKyAgICAg
ICAgZ290byBvdXQ7CisgICAgfQorCisgICAgYnl0ZXNfcGVyX2ludGVydmFsID0KKyAgICAgICAg
KCgodWludDY0X3QpIGJ5dGVzX3Blcl9zZWMgKiAodWludDY0X3QpIGludGVydmFsX3VzZWNzKSAv
IDEwMDAwMDBVTCk7CisKKyAgICBuaWMtPnJhdGVfaW50ZXJ2YWxfdXNlY3MgPSBpbnRlcnZhbF91
c2VjczsKKyAgICBuaWMtPnJhdGVfYnl0ZXNfcGVyX2ludGVydmFsID0gYnl0ZXNfcGVyX2ludGVy
dmFsOworCitvdXQ6CisgICAgZnJlZSh0bXByYXRlKTsKKyAgICByZXR1cm4gcmM7Cit9CisKKy8q
CisgKiBMb2NhbCB2YXJpYWJsZXM6CisgKiBtb2RlOiBDCisgKiBjLWJhc2ljLW9mZnNldDogNAor
ICogaW5kZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8KZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhsL2xpYnhsdXRpbC5oIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGx1dGlsLmgKKysrIGIvdG9vbHMvbGlieGwvbGlieGx1dGlsLmgKQEAgLTk0LDYg
Kzk0LDEzIEBAIGludCB4bHVfZGlza19wYXJzZShYTFVfQ29uZmlnICpjZmcsIGludCAKIGludCB4
bHVfcGNpX3BhcnNlX2JkZihYTFVfQ29uZmlnICpjZmcsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRl
diwgY29uc3QgY2hhciAqc3RyKTsKIAogCisvKgorICogVmlmIHJhdGUgcGFyc2luZy4KKyAqLwor
CitpbnQgeGx1X3ZpZl9wYXJzZV9yYXRlKFhMVV9Db25maWcgKmNmZywgY29uc3QgY2hhciAqcmF0
ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfZGV2aWNlX25pYyAqbmljKTsKKwogI2Vu
ZGlmIC8qIExJQlhMVVRJTF9IICovCiAKIC8qCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9j
bWRpbXBsLmMgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtNDAzLDYgKzQwMywx
OSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9kaXNrX2NvbmZpZyhYTFVfQ29uZmlnCiAgICAgcGFyc2Vf
ZGlza19jb25maWdfbXVsdGlzdHJpbmcoY29uZmlnLCAxLCAmc3BlYywgZGlzayk7CiB9CiAKK3N0
YXRpYyB2b2lkIHBhcnNlX3ZpZl9yYXRlKFhMVV9Db25maWcgKipjb25maWcsIGNvbnN0IGNoYXIg
KnJhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZpY2VfbmljICpuaWMp
Cit7CisgICAgaW50IGU7CisKKyAgICBlID0geGx1X3ZpZl9wYXJzZV9yYXRlKCpjb25maWcsIHJh
dGUsIG5pYyk7CisgICAgaWYgKGUgPT0gRUlOVkFMIHx8IGUgPT0gRU9WRVJGTE9XKSBleGl0KC0x
KTsKKyAgICBpZiAoZSkgeworICAgICAgICBmcHJpbnRmKHN0ZGVyciwieGx1X3ZpZl9wYXJzZV9y
YXRlIGZhaWxlZDogJXNcbiIsc3RyZXJyb3IoZXJybm8pKTsKKyAgICAgICAgZXhpdCgtMSk7Cisg
ICAgfQorfQorCiBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJpbmdfbGlzdChjb25z
dCBjaGFyICpzdHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
b25zdCBjaGFyICpkZWxpbSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX3N0cmluZ19saXN0ICpwc2wpCkBAIC05MDYsNyArOTE5LDcgQEAgc3RhdGljIHZv
aWQgcGFyc2VfY29uZmlnX2RhdGEoY29uc3QgY2hhcgogICAgICAgICAgICAgICAgICAgICAgICAg
bmljLT5iYWNrZW5kX2RvbWlkID0gMDsKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAg
ICAgICAgIH0gZWxzZSBpZiAoIXN0cmNtcChwLCAicmF0ZSIpKSB7Ci0gICAgICAgICAgICAgICAg
ICAgIGZwcmludGYoc3RkZXJyLCAidGhlIHJhdGUgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJl
bnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKKyAgICAgICAgICAgICAgICAgICAgcGFyc2VfdmlmX3Jh
dGUoJmNvbmZpZywgKHAyICsgMSksIG5pYyk7CiAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICgh
c3RyY21wKHAsICJhY2NlbCIpKSB7CiAgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJy
LCAidGhlIGFjY2VsIHBhcmFtZXRlciBmb3IgdmlmcyBpcyBjdXJyZW50bHkgbm90IHN1cHBvcnRl
ZFxuIik7CiAgICAgICAgICAgICAgICAgfQpAQCAtNDg1NSw2ICs0ODY4LDcgQEAgaW50IG1haW5f
bmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAqKgogewogICAgIGludCBvcHQ7CiAgICAgbGli
eGxfZGV2aWNlX25pYyBuaWM7CisgICAgWExVX0NvbmZpZyAqY29uZmlnID0gMDsKICAgICBjaGFy
ICplbmRwdHIsICpvcGFyZzsKICAgICBjb25zdCBjaGFyICp0b2s7CiAgICAgaW50IGk7CkBAIC00
ODcyLDYgKzQ4ODYsMTMgQEAgaW50IG1haW5fbmV0d29ya2F0dGFjaChpbnQgYXJnYywgY2hhciAq
KgogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIiVzIGlzIGFuIGludmFsaWQgZG9tYWluIGlkZW50
aWZpZXJcbiIsIGFyZ3Zbb3B0aW5kXSk7CiAgICAgICAgIHJldHVybiAxOwogICAgIH0KKworICAg
IGNvbmZpZz0geGx1X2NmZ19pbml0KHN0ZGVyciwgImNvbW1hbmQgbGluZSIpOworICAgIGlmICgh
Y29uZmlnKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRmFpbGVkIHRvIGFsbG9jYXRlIGZv
ciBjb25maWd1cmF0aW9uXG4iKTsKKyAgICAgICAgcmV0dXJuIDE7CisgICAgfQorCiAgICAgbGli
eGxfZGV2aWNlX25pY19pbml0KCZuaWMpOwogICAgIGZvciAoYXJndiArPSBvcHRpbmQrMSwgYXJn
YyAtPSBvcHRpbmQrMTsgYXJnYyA+IDA7ICsrYXJndiwgLS1hcmdjKSB7CiAgICAgICAgIGlmIChN
QVRDSF9PUFRJT04oInR5cGUiLCAqYXJndiwgb3BhcmcpKSB7CkBAIC00OTEwLDYgKzQ5MzEsNyBA
QCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqCiAgICAgICAgIH0gZWxz
ZSBpZiAoTUFUQ0hfT1BUSU9OKCJtb2RlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgICAg
IHJlcGxhY2Vfc3RyaW5nKCZuaWMubW9kZWwsIG9wYXJnKTsKICAgICAgICAgfSBlbHNlIGlmIChN
QVRDSF9PUFRJT04oInJhdGUiLCAqYXJndiwgb3BhcmcpKSB7CisgICAgICAgICAgICBwYXJzZV92
aWZfcmF0ZSgmY29uZmlnLCBvcGFyZywgJm5pYyk7CiAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hf
T1BUSU9OKCJhY2NlbCIsICphcmd2LCBvcGFyZykpIHsKICAgICAgICAgfSBlbHNlIHsKICAgICAg
ICAgICAgIGZwcmludGYoc3RkZXJyLCAidW5yZWNvZ25pemVkIGFyZ3VtZW50IGAlcydcbiIsICph
cmd2KTsKQEAgLTQ5MzEsNiArNDk1Myw3IEBAIGludCBtYWluX25ldHdvcmthdHRhY2goaW50IGFy
Z2MsIGNoYXIgKioKICAgICAgICAgcmV0dXJuIDE7CiAgICAgfQogICAgIGxpYnhsX2RldmljZV9u
aWNfZGlzcG9zZSgmbmljKTsKKyAgICB4bHVfY2ZnX2Rlc3Ryb3koY29uZmlnKTsKICAgICByZXR1
cm4gMDsKIH0KIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMd-00070c-OH; Tue, 24 Apr 2012 15:09:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMb-0006zO-KS
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:09 +0000
Received: from [85.158.139.83:62379] by server-12.bemta-5.messagelabs.com id
	0B/F6-05587-412C69F4; Tue, 24 Apr 2012 15:09:08 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335280147!21411542!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16647 invoked from network); 24 Apr 2012 15:09:07 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-6.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 15:09:07 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 830D6245B9; Tue, 24 Apr 2012 11:17:34 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: *
X-Spam-Status: No, score=1.2 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_22,
	J_CHICKENPOX_43,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no 
	version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 4316423C72;
	Tue, 24 Apr 2012 11:17:31 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 693D2281AC; Tue, 24 Apr 2012 11:09:03 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: cf61db286077f7b098665d3315bc3fb4e89a4816
Message-Id: <cf61db286077f7b09866.1335280033@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:13 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 v3 RESEND] xl: add "check-xl-vif-parse"
	test script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyB0ZXN0IHNjcmlwdCBydW5zICJ4bCAtTiBuZXR3b3JrLWF0dGFjaCAwIDxmb29iYXI+IiBh
Z2FpbnN0IHZhcmlvdXMKcmF0ZSBzeW50YXggYW5kIGNoZWNrcyB0aGF0IHRoZSBvdXRwdXQgaXMg
YXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIu
Y29tPgpBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UgYi90b29scy9saWJ4bC9j
aGVjay14bC12aWYtcGFyc2UKbmV3IGZpbGUgbW9kZSAxMDA3NTUKLS0tIC9kZXYvbnVsbAorKysg
Yi90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UKQEAgLTAsMCArMSwyMDkgQEAKKyMhL2Jp
bi9iYXNoCisKK3NldCAtZQorCitpZiBbIC14IC4veGwgXSA7IHRoZW4KKyAgICBleHBvcnQgTERf
TElCUkFSWV9QQVRIPS4KKyAgICBYTD0uL3hsCitlbHNlCisgICAgWEw9eGwKK2ZpCisKK2ZwcmVm
aXg9dG1wLmNoZWNrLXhsLXZpZi1wYXJzZQorCitleHBlY3RlZCAoKSB7CisgICAgY2F0ID4kZnBy
ZWZpeC5leHBlY3RlZAorfQorCitmYWlsdXJlcz0wCisKK29uZSAoKSB7CisgICAgZXhwZWN0ZWRf
cmM9JDE7IHNoaWZ0CisgICAgcHJpbnRmICJ0ZXN0IGNhc2UgJXMuLi5cbiIgIiQqIgorICAgIHNl
dCArZQorICAgICR7WEx9IC1OIG5ldHdvcmstYXR0YWNoIDAgIiRAIiA8L2Rldi9udWxsID4kZnBy
ZWZpeC5hY3R1YWwgMj4vZGV2L251bGwKKyAgICBhY3R1YWxfcmM9JD8KKyAgICBkaWZmIC11ICRm
cHJlZml4LmV4cGVjdGVkICRmcHJlZml4LmFjdHVhbAorICAgIGRpZmZfcmM9JD8KKyAgICBzZXQg
LWUKKyAgICBpZiBbICRhY3R1YWxfcmMgIT0gJGV4cGVjdGVkX3JjIF0gfHwgWyAkZGlmZl9yYyAh
PSAwIF07IHRoZW4KKyAgICAgICAgZWNobyA+JjIgInRlc3QgY2FzZSBcYCQqJyBmYWlsZWQgKCRh
Y3R1YWxfcmMgJGRpZmZfcmMpIgorICAgICAgICBmYWlsdXJlcz0kKCggJGZhaWx1cmVzICsgMSAp
KQorICAgIGZpCit9CisKK2NvbXBsZXRlICgpIHsKKyAgICBpZiBbICIkZmFpbHVyZXMiID0gMCBd
OyB0aGVuCisgICAgICAgIGVjaG8gYWxsIG9rLjsgZXhpdCAwCisgICAgZWxzZQorICAgICAgICBl
Y2hvICIkZmFpbHVyZXMgdGVzdHMgZmFpbGVkLiI7IGV4aXQgMQorICAgIGZpCit9CisKK2U9MjU1
CisKKworIy0tLS0tLS0tLS0gdGVzdCBkYXRhIC0tLS0tLS0tLS0KKworIyB0ZXN0IGludmFsaWQg
dmlmIGNvbmZpZworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lIDEgZm9vCisKKyMgdGVzdCBpbnZh
bGlkIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDwvZGV2L251bGwKK29uZSAkZSByYXRlPWZvbworb25l
ICRlIHJhdGU9Zm9vCitvbmUgJGUgcmF0ZT0xME1CCitvbmUgJGUgcmF0ZT0xME1CL20KK29uZSAk
ZSByYXRlPTEwWkIKK29uZSAkZSByYXRlPTEwWkIvcworb25lICRlIHJhdGU9MTBaQi9tCisKKyMg
dGVzdCBiL3MgYW5kIEIvcyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAg
ImJhY2tlbmRfZG9taWQiOiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAg
Im1vZGVsIjogbnVsbCwKKyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAi
OiBudWxsLAorICAgICJicmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJz
Y3JpcHQiOiBudWxsLAorICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJf
aW50ZXJ2YWwiOiAxMDAwMDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQor
CitFTkQKKworb25lIDAgcmF0ZT0xNjAwMDAwMGIvcworb25lIDAgcmF0ZT0xNjAwMDAwMGIvc0A1
MG1zCitvbmUgMCByYXRlPTIwMDAwMDBCL3MKK29uZSAwIHJhdGU9MjAwMDAwMEIvc0A1MG1zCisK
KyMgdGVzdCBLYi9zIGFuZCBLQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsK
KyAgICAiYmFja2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwK
KyAgICAibW9kZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAg
ICJpcCI6IG51bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisg
ICAgInNjcmlwdCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVz
X3Blcl9pbnRlcnZhbCI6IDEwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9
CisKK0VORAorb25lIDAgcmF0ZT0xNktiL3MKK29uZSAwIHJhdGU9MTZLYi9zQDUwbXMKK29uZSAw
IHJhdGU9MktCL3MKK29uZSAwIHJhdGU9MktCL3NANTBtcworCisjIHRlc3QgTWIvcyBhbmQgTUIv
cyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAgImJhY2tlbmRfZG9taWQi
OiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAgIm1vZGVsIjogbnVsbCwK
KyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAiOiBudWxsLAorICAgICJi
cmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJzY3JpcHQiOiBudWxsLAor
ICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiOiAxMDAw
MDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJh
dGU9MTZNYi9zCitvbmUgMCByYXRlPTE2TWIvc0A1MG1zCitvbmUgMCByYXRlPTJNQi9zCitvbmUg
MCByYXRlPTJNQi9zQDUwbXMKKworIyB0ZXN0IEdiL3MgYW5kIEdCL3MgcmF0ZSB1bml0cworZXhw
ZWN0ZWQgPDxFTkQKK3ZpZjogeworICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQi
OiAwLAorICAgICJtdHUiOiAwLAorICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDow
MDowMDowMDowMDowMCIsCisgICAgImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAg
ICAiaWZuYW1lIjogbnVsbCwKKyAgICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51
bGwsCisgICAgInJhdGVfYnl0ZXNfcGVyX2ludGVydmFsIjogNTAwMDAwMDAsCisgICAgInJhdGVf
aW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJhdGU9OEdiL3MKK29uZSAw
IHJhdGU9OEdiL3NANTBtcworb25lIDAgcmF0ZT0xR0Ivcworb25lIDAgcmF0ZT0xR0Ivc0A1MG1z
CisKKyMgdGVzdCByYXRlIG92ZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0
ZT00Mjk0OTY3Mjk2Yi9zCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk2S2Ivcworb25lICRlIHJhdGU9
NDI5NDk2NzI5Nk1iL3MKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTZHYi9zCisKKyMgdGVzdCByYXRl
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MEIvcworCisjIHRl
c3QgaW52YWxpZCByZXBsZW5pc2htZW50IGludGVydmFsCitleHBlY3RlZCA8L2Rldi9udWxsCitv
bmUgJGUgcmF0ZT0xME1iL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1iL3NAMTBoCitvbmUgJGUgcmF0
ZT0xME1CL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1CL3NAMTBoCisKKyMgdGVzdCByZXBsZW5pc2ht
ZW50IGludGVydmFsIGluIHNlY29uZHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsKKyAgICAiYmFj
a2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwKKyAgICAibW9k
ZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAgICJpcCI6IG51
bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisgICAgInNjcmlw
dCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVzX3Blcl9pbnRl
cnZhbCI6IDEwMDAwMDAwLAorICAgICJyYXRlX2ludGVydmFsX3VzZWNzIjogMTAwMDAwMAorfQor
CitFTkQKK29uZSAwIHJhdGU9ODBNYi9zQDFzCitvbmUgMCByYXRlPTEwTUIvc0AxcworCisjIHRl
c3QgcmVwbGVuaXNobWVudCBpbnRlcnZhbCBvdmVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAor
b25lICRlIHJhdGU9MUIvc0A0Mjk0OTY3Mjk2dXMKK29uZSAkZSByYXRlPTFCL3NANDI5NDk2OG1z
CitvbmUgJGUgcmF0ZT0xQi9zQDQyOTVzCisKKyMgdGVzdCByZXBsZW5pc2htZW50IGludGVydmFs
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MUIvc0AwdXMKKwor
IyB0ZXN0IHJhdGUgbGltaXRpbmcgcmVzdWx0aW5nIGluIG92ZXJmbG93CitleHBlY3RlZCA8L2Rl
di9udWxsCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk1R0Ivc0A1dXMKK29uZSAkZSByYXRlPTQyOTZN
Qi9zQDQyOTRzCisKK2NvbXBsZXRlCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhMd-00070c-OH; Tue, 24 Apr 2012 15:09:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1SMhMb-0006zO-KS
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:09:09 +0000
Received: from [85.158.139.83:62379] by server-12.bemta-5.messagelabs.com id
	0B/F6-05587-412C69F4; Tue, 24 Apr 2012 15:09:08 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335280147!21411542!1
X-Originating-IP: [64.15.155.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16647 invoked from network); 24 Apr 2012 15:09:07 -0000
Received: from calavera.ca (HELO manny.calavera.ca) (64.15.155.165)
	by server-6.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 15:09:07 -0000
Received: by manny.calavera.ca (Postfix, from userid 101)
	id 830D6245B9; Tue, 24 Apr 2012 11:17:34 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on manny.calavera.ca
X-Spam-Level: *
X-Spam-Status: No, score=1.2 required=3.5 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, J_CHICKENPOX_22,
	J_CHICKENPOX_43,MIME_8BIT_HEADER,MIME_BASE64_NO_NAME autolearn=no 
	version=3.1.7
Received: from mgagne.users.dev.iweb.com (palpatine.privatedns.com
	[209.172.32.36])
	by manny.calavera.ca (Postfix) with ESMTP id 4316423C72;
	Tue, 24 Apr 2012 11:17:31 -0400 (EDT)
Received: by mgagne.users.dev.iweb.com (Postfix, from userid 501)
	id 693D2281AC; Tue, 24 Apr 2012 11:09:03 -0400 (EDT)
MIME-Version: 1.0
X-Mercurial-Node: cf61db286077f7b098665d3315bc3fb4e89a4816
Message-Id: <cf61db286077f7b09866.1335280033@mgagne.users.dev.iweb.com>
In-Reply-To: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
References: <patchbomb.1335280029@mgagne.users.dev.iweb.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 24 Apr 2012 11:07:13 -0400
From: =?iso-8859-1?q?Mathieu_Gagn=E9?= <mgagne@iweb.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 v3 RESEND] xl: add "check-xl-vif-parse"
	test script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhpcyB0ZXN0IHNjcmlwdCBydW5zICJ4bCAtTiBuZXR3b3JrLWF0dGFjaCAwIDxmb29iYXI+IiBh
Z2FpbnN0IHZhcmlvdXMKcmF0ZSBzeW50YXggYW5kIGNoZWNrcyB0aGF0IHRoZSBvdXRwdXQgaXMg
YXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBNYXRoaWV1IEdhZ27DqSA8bWdhZ25lQGl3ZWIu
Y29tPgpBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UgYi90b29scy9saWJ4bC9j
aGVjay14bC12aWYtcGFyc2UKbmV3IGZpbGUgbW9kZSAxMDA3NTUKLS0tIC9kZXYvbnVsbAorKysg
Yi90b29scy9saWJ4bC9jaGVjay14bC12aWYtcGFyc2UKQEAgLTAsMCArMSwyMDkgQEAKKyMhL2Jp
bi9iYXNoCisKK3NldCAtZQorCitpZiBbIC14IC4veGwgXSA7IHRoZW4KKyAgICBleHBvcnQgTERf
TElCUkFSWV9QQVRIPS4KKyAgICBYTD0uL3hsCitlbHNlCisgICAgWEw9eGwKK2ZpCisKK2ZwcmVm
aXg9dG1wLmNoZWNrLXhsLXZpZi1wYXJzZQorCitleHBlY3RlZCAoKSB7CisgICAgY2F0ID4kZnBy
ZWZpeC5leHBlY3RlZAorfQorCitmYWlsdXJlcz0wCisKK29uZSAoKSB7CisgICAgZXhwZWN0ZWRf
cmM9JDE7IHNoaWZ0CisgICAgcHJpbnRmICJ0ZXN0IGNhc2UgJXMuLi5cbiIgIiQqIgorICAgIHNl
dCArZQorICAgICR7WEx9IC1OIG5ldHdvcmstYXR0YWNoIDAgIiRAIiA8L2Rldi9udWxsID4kZnBy
ZWZpeC5hY3R1YWwgMj4vZGV2L251bGwKKyAgICBhY3R1YWxfcmM9JD8KKyAgICBkaWZmIC11ICRm
cHJlZml4LmV4cGVjdGVkICRmcHJlZml4LmFjdHVhbAorICAgIGRpZmZfcmM9JD8KKyAgICBzZXQg
LWUKKyAgICBpZiBbICRhY3R1YWxfcmMgIT0gJGV4cGVjdGVkX3JjIF0gfHwgWyAkZGlmZl9yYyAh
PSAwIF07IHRoZW4KKyAgICAgICAgZWNobyA+JjIgInRlc3QgY2FzZSBcYCQqJyBmYWlsZWQgKCRh
Y3R1YWxfcmMgJGRpZmZfcmMpIgorICAgICAgICBmYWlsdXJlcz0kKCggJGZhaWx1cmVzICsgMSAp
KQorICAgIGZpCit9CisKK2NvbXBsZXRlICgpIHsKKyAgICBpZiBbICIkZmFpbHVyZXMiID0gMCBd
OyB0aGVuCisgICAgICAgIGVjaG8gYWxsIG9rLjsgZXhpdCAwCisgICAgZWxzZQorICAgICAgICBl
Y2hvICIkZmFpbHVyZXMgdGVzdHMgZmFpbGVkLiI7IGV4aXQgMQorICAgIGZpCit9CisKK2U9MjU1
CisKKworIy0tLS0tLS0tLS0gdGVzdCBkYXRhIC0tLS0tLS0tLS0KKworIyB0ZXN0IGludmFsaWQg
dmlmIGNvbmZpZworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lIDEgZm9vCisKKyMgdGVzdCBpbnZh
bGlkIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDwvZGV2L251bGwKK29uZSAkZSByYXRlPWZvbworb25l
ICRlIHJhdGU9Zm9vCitvbmUgJGUgcmF0ZT0xME1CCitvbmUgJGUgcmF0ZT0xME1CL20KK29uZSAk
ZSByYXRlPTEwWkIKK29uZSAkZSByYXRlPTEwWkIvcworb25lICRlIHJhdGU9MTBaQi9tCisKKyMg
dGVzdCBiL3MgYW5kIEIvcyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAg
ImJhY2tlbmRfZG9taWQiOiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAg
Im1vZGVsIjogbnVsbCwKKyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAi
OiBudWxsLAorICAgICJicmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJz
Y3JpcHQiOiBudWxsLAorICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJf
aW50ZXJ2YWwiOiAxMDAwMDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQor
CitFTkQKKworb25lIDAgcmF0ZT0xNjAwMDAwMGIvcworb25lIDAgcmF0ZT0xNjAwMDAwMGIvc0A1
MG1zCitvbmUgMCByYXRlPTIwMDAwMDBCL3MKK29uZSAwIHJhdGU9MjAwMDAwMEIvc0A1MG1zCisK
KyMgdGVzdCBLYi9zIGFuZCBLQi9zIHJhdGUgdW5pdHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsK
KyAgICAiYmFja2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwK
KyAgICAibW9kZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAg
ICJpcCI6IG51bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisg
ICAgInNjcmlwdCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVz
X3Blcl9pbnRlcnZhbCI6IDEwMCwKKyAgICAicmF0ZV9pbnRlcnZhbF91c2VjcyI6IDUwMDAwCit9
CisKK0VORAorb25lIDAgcmF0ZT0xNktiL3MKK29uZSAwIHJhdGU9MTZLYi9zQDUwbXMKK29uZSAw
IHJhdGU9MktCL3MKK29uZSAwIHJhdGU9MktCL3NANTBtcworCisjIHRlc3QgTWIvcyBhbmQgTUIv
cyByYXRlIHVuaXRzCitleHBlY3RlZCA8PEVORAordmlmOiB7CisgICAgImJhY2tlbmRfZG9taWQi
OiAwLAorICAgICJkZXZpZCI6IDAsCisgICAgIm10dSI6IDAsCisgICAgIm1vZGVsIjogbnVsbCwK
KyAgICAibWFjIjogIjAwOjAwOjAwOjAwOjAwOjAwIiwKKyAgICAiaXAiOiBudWxsLAorICAgICJi
cmlkZ2UiOiBudWxsLAorICAgICJpZm5hbWUiOiBudWxsLAorICAgICJzY3JpcHQiOiBudWxsLAor
ICAgICJuaWN0eXBlIjogbnVsbCwKKyAgICAicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiOiAxMDAw
MDAsCisgICAgInJhdGVfaW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJh
dGU9MTZNYi9zCitvbmUgMCByYXRlPTE2TWIvc0A1MG1zCitvbmUgMCByYXRlPTJNQi9zCitvbmUg
MCByYXRlPTJNQi9zQDUwbXMKKworIyB0ZXN0IEdiL3MgYW5kIEdCL3MgcmF0ZSB1bml0cworZXhw
ZWN0ZWQgPDxFTkQKK3ZpZjogeworICAgICJiYWNrZW5kX2RvbWlkIjogMCwKKyAgICAiZGV2aWQi
OiAwLAorICAgICJtdHUiOiAwLAorICAgICJtb2RlbCI6IG51bGwsCisgICAgIm1hYyI6ICIwMDow
MDowMDowMDowMDowMCIsCisgICAgImlwIjogbnVsbCwKKyAgICAiYnJpZGdlIjogbnVsbCwKKyAg
ICAiaWZuYW1lIjogbnVsbCwKKyAgICAic2NyaXB0IjogbnVsbCwKKyAgICAibmljdHlwZSI6IG51
bGwsCisgICAgInJhdGVfYnl0ZXNfcGVyX2ludGVydmFsIjogNTAwMDAwMDAsCisgICAgInJhdGVf
aW50ZXJ2YWxfdXNlY3MiOiA1MDAwMAorfQorCitFTkQKK29uZSAwIHJhdGU9OEdiL3MKK29uZSAw
IHJhdGU9OEdiL3NANTBtcworb25lIDAgcmF0ZT0xR0Ivcworb25lIDAgcmF0ZT0xR0Ivc0A1MG1z
CisKKyMgdGVzdCByYXRlIG92ZXJmbG93CitleHBlY3RlZCA8L2Rldi9udWxsCitvbmUgJGUgcmF0
ZT00Mjk0OTY3Mjk2Yi9zCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk2S2Ivcworb25lICRlIHJhdGU9
NDI5NDk2NzI5Nk1iL3MKK29uZSAkZSByYXRlPTQyOTQ5NjcyOTZHYi9zCisKKyMgdGVzdCByYXRl
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MEIvcworCisjIHRl
c3QgaW52YWxpZCByZXBsZW5pc2htZW50IGludGVydmFsCitleHBlY3RlZCA8L2Rldi9udWxsCitv
bmUgJGUgcmF0ZT0xME1iL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1iL3NAMTBoCitvbmUgJGUgcmF0
ZT0xME1CL3NAZm9vCitvbmUgJGUgcmF0ZT0xME1CL3NAMTBoCisKKyMgdGVzdCByZXBsZW5pc2ht
ZW50IGludGVydmFsIGluIHNlY29uZHMKK2V4cGVjdGVkIDw8RU5ECit2aWY6IHsKKyAgICAiYmFj
a2VuZF9kb21pZCI6IDAsCisgICAgImRldmlkIjogMCwKKyAgICAibXR1IjogMCwKKyAgICAibW9k
ZWwiOiBudWxsLAorICAgICJtYWMiOiAiMDA6MDA6MDA6MDA6MDA6MDAiLAorICAgICJpcCI6IG51
bGwsCisgICAgImJyaWRnZSI6IG51bGwsCisgICAgImlmbmFtZSI6IG51bGwsCisgICAgInNjcmlw
dCI6IG51bGwsCisgICAgIm5pY3R5cGUiOiBudWxsLAorICAgICJyYXRlX2J5dGVzX3Blcl9pbnRl
cnZhbCI6IDEwMDAwMDAwLAorICAgICJyYXRlX2ludGVydmFsX3VzZWNzIjogMTAwMDAwMAorfQor
CitFTkQKK29uZSAwIHJhdGU9ODBNYi9zQDFzCitvbmUgMCByYXRlPTEwTUIvc0AxcworCisjIHRl
c3QgcmVwbGVuaXNobWVudCBpbnRlcnZhbCBvdmVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAor
b25lICRlIHJhdGU9MUIvc0A0Mjk0OTY3Mjk2dXMKK29uZSAkZSByYXRlPTFCL3NANDI5NDk2OG1z
CitvbmUgJGUgcmF0ZT0xQi9zQDQyOTVzCisKKyMgdGVzdCByZXBsZW5pc2htZW50IGludGVydmFs
IHVuZGVyZmxvdworZXhwZWN0ZWQgPC9kZXYvbnVsbAorb25lICRlIHJhdGU9MUIvc0AwdXMKKwor
IyB0ZXN0IHJhdGUgbGltaXRpbmcgcmVzdWx0aW5nIGluIG92ZXJmbG93CitleHBlY3RlZCA8L2Rl
di9udWxsCitvbmUgJGUgcmF0ZT00Mjk0OTY3Mjk1R0Ivc0A1dXMKK29uZSAkZSByYXRlPTQyOTZN
Qi9zQDQyOTRzCisKK2NvbXBsZXRlCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhU3-00084t-2Z; Tue, 24 Apr 2012 15:16:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhU1-00084k-R3
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:16:50 +0000
Received: from [193.109.254.147:51409] by server-10.bemta-14.messagelabs.com
	id EA/0E-05847-1E3C69F4; Tue, 24 Apr 2012 15:16:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335280595!3647698!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20243 invoked from network); 24 Apr 2012 15:16:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:16:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:16:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:16:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhTn-0006Ni-5J; Tue, 24 Apr 2012 15:16:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhTn-0007hB-4E;
	Tue, 24 Apr 2012 16:16:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50130.965539.944040@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:16:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335279876.4347.195.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20374.49036.91434.25461@mariner.uk.xensource.com>
	<1335279876.4347.195.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> On Tue, 2012-04-24 at 15:58 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> > > +    } while (vdev[strlen(vdev) - 1] <= 'z');
> > 
> > There is a scaling limit here of not starting more than 26 domains
> > simultaneously.  Is that acceptable ?  I'm tempted to suggest not.
> 
> While I agree we also need to start being pragmatic about ever getting
> 4.2 out the door...
> 
> If it's a trivial job to support aa, ab etc then lets do it, if not then
> lets leave it for 4.3?

The problem is because the code is trying to avoid too much knowledge
of the devid scheme; in particular, it's trying to avoid introducing
the inverse function to libxl__device_disk_dev_number.  Although it
/does/ depend intimately on the details of
libxl__device_disk_dev_number.

It is arguably a bug that libxl__device_disk_dev_number combines the
parsing of vdev strings with the composition of disk/partition numbers
into devids.  But we can avoid needing to decompose it by passing
libxl__device_disk_dev_number a format which is easier to create than
one with a base-26-encoded disk number.

What I would do is:
  * call libxl__device_disk_dev_number once on blkdev_start with
    non-null arguments for pdisk and ppartition; check that
    the partition is 0.
  * loop incrementing the disk value
  * on each iteration,
    - generate a vdev = GCSPRINTF("d%d", disk);
    - use libxl__device_disk_dev_number on that vdev to get the devid
    - check whether this devid is available

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhU3-00084t-2Z; Tue, 24 Apr 2012 15:16:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhU1-00084k-R3
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:16:50 +0000
Received: from [193.109.254.147:51409] by server-10.bemta-14.messagelabs.com
	id EA/0E-05847-1E3C69F4; Tue, 24 Apr 2012 15:16:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335280595!3647698!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20243 invoked from network); 24 Apr 2012 15:16:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:16:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:16:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:16:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhTn-0006Ni-5J; Tue, 24 Apr 2012 15:16:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhTn-0007hB-4E;
	Tue, 24 Apr 2012 16:16:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50130.965539.944040@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:16:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335279876.4347.195.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20374.49036.91434.25461@mariner.uk.xensource.com>
	<1335279876.4347.195.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> On Tue, 2012-04-24 at 15:58 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev"):
> > > +    } while (vdev[strlen(vdev) - 1] <= 'z');
> > 
> > There is a scaling limit here of not starting more than 26 domains
> > simultaneously.  Is that acceptable ?  I'm tempted to suggest not.
> 
> While I agree we also need to start being pragmatic about ever getting
> 4.2 out the door...
> 
> If it's a trivial job to support aa, ab etc then lets do it, if not then
> lets leave it for 4.3?

The problem is because the code is trying to avoid too much knowledge
of the devid scheme; in particular, it's trying to avoid introducing
the inverse function to libxl__device_disk_dev_number.  Although it
/does/ depend intimately on the details of
libxl__device_disk_dev_number.

It is arguably a bug that libxl__device_disk_dev_number combines the
parsing of vdev strings with the composition of disk/partition numbers
into devids.  But we can avoid needing to decompose it by passing
libxl__device_disk_dev_number a format which is easier to create than
one with a base-26-encoded disk number.

What I would do is:
  * call libxl__device_disk_dev_number once on blkdev_start with
    non-null arguments for pdisk and ppartition; check that
    the partition is 0.
  * loop incrementing the disk value
  * on each iteration,
    - generate a vdev = GCSPRINTF("d%d", disk);
    - use libxl__device_disk_dev_number on that vdev to get the devid
    - check whether this devid is available

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:17:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhU4-00085F-FT; Tue, 24 Apr 2012 15:16:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhU3-00084v-HX
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:16:51 +0000
Received: from [193.109.254.147:51549] by server-9.bemta-14.messagelabs.com id
	3D/76-05787-2E3C69F4; Tue, 24 Apr 2012 15:16:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335280595!3647698!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20570 invoked from network); 24 Apr 2012 15:16:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:16:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:16:41 +0100
Message-ID: <1335280600.4347.201.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:16:40 +0100
In-Reply-To: <1335264358-20182-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/8] libxl: make
 libxl_device_disk_local_attach/detach internal functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:45 +0100, Stefano Stabellini wrote:

No functional change other than ctx->gc?

> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index b89aef7..1f428b2 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -323,6 +323,78 @@ out:
>      return rc;
>  }
>  
> +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)

Strictly the hidden is only needed on the prototype. I guess there's no
harm having it here too (but you know what linkers are like...)

> +{
[...]
> +}

Looking at the callers this could possibly be a gc'd string, and perhaps
const in the return here. That's for another day though I think.

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:17:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhU4-00085F-FT; Tue, 24 Apr 2012 15:16:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhU3-00084v-HX
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:16:51 +0000
Received: from [193.109.254.147:51549] by server-9.bemta-14.messagelabs.com id
	3D/76-05787-2E3C69F4; Tue, 24 Apr 2012 15:16:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335280595!3647698!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20570 invoked from network); 24 Apr 2012 15:16:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:16:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:16:41 +0100
Message-ID: <1335280600.4347.201.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:16:40 +0100
In-Reply-To: <1335264358-20182-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/8] libxl: make
 libxl_device_disk_local_attach/detach internal functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:45 +0100, Stefano Stabellini wrote:

No functional change other than ctx->gc?

> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index b89aef7..1f428b2 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -323,6 +323,78 @@ out:
>      return rc;
>  }
>  
> +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)

Strictly the hidden is only needed on the prototype. I guess there's no
harm having it here too (but you know what linkers are like...)

> +{
[...]
> +}

Looking at the callers this could possibly be a gc'd string, and perhaps
const in the return here. That's for another day though I think.

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:17:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhUB-00086V-Sx; Tue, 24 Apr 2012 15:16:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMhUA-000867-Ji
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:16:58 +0000
Received: from [85.158.143.99:26823] by server-2.bemta-4.messagelabs.com id
	58/DF-17550-9E3C69F4; Tue, 24 Apr 2012 15:16:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335280615!19801695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8210 invoked from network); 24 Apr 2012 15:16:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 15:16:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 16:16:54 +0100
Message-Id: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 16:17:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9AB44EE8.1__="
Cc: Eddie Dong <eddie.dong@intel.com>
Subject: [Xen-devel] [PATCH] nested vmx: fix instruction decode segment
	limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part9AB44EE8.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- no limit check in 64-bit mode (is not special in any way)
- limit check is needed in compatibility mode
- canonical address check should instead be performed in 64-bit mode
- the last accessed byte must be within limits, not the first byte past
  the accessed range

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -319,7 +319,7 @@ static int decode_vmx_inst(struct cpu_us
 {
     struct vcpu *v =3D current;
     union vmx_inst_info info;
-    struct segment_register seg;
+    struct segment_register seg, cs;
     unsigned long base, index, seg_base, disp, offset;
     int scale, size;
=20
@@ -342,6 +342,11 @@ static int decode_vmx_inst(struct cpu_us
         hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
         seg_base =3D seg.base;
=20
+        if ( hvm_long_mode_enabled(v) )
+            hvm_get_segment_register(v, x86_seg_cs, &cs);
+        else
+            memset(&cs, 0, sizeof(cs));
+
         base =3D info.fields.base_reg_invalid ? 0 :
             reg_read(regs, info.fields.base_reg);
=20
@@ -355,8 +360,10 @@ static int decode_vmx_inst(struct cpu_us
         size =3D 1 << (info.fields.addr_size + 1);
=20
         offset =3D base + index * scale + disp;
-        if ( (offset > seg.limit || offset + size > seg.limit) &&
-            (!hvm_long_mode_enabled(v) || info.fields.segment =3D=3D =
VMX_SREG_GS) )
+        if ( cs.attr.fields.l ?
+             (!is_canonical_address(offset) ||
+              !is_canonical_address(offset + size - 1)) :
+             (offset + size - 1 < offset || offset + size - 1 > seg.limit)=
 )
             goto gp_fault;
=20
         if ( poperandS !=3D NULL &&




--=__Part9AB44EE8.1__=
Content-Type: text/plain; name="vmx-nested-decode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vmx-nested-decode.patch"

nested vmx: fix instruction decode segment limit check=0A=0A- no limit =
check in 64-bit mode (is not special in any way)=0A- limit check is needed =
in compatibility mode=0A- canonical address check should instead be =
performed in 64-bit mode=0A- the last accessed byte must be within limits, =
not the first byte past=0A  the accessed range=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ =
b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ -319,7 +319,7 @@ static int decode_vmx_i=
nst(struct cpu_us=0A {=0A     struct vcpu *v =3D current;=0A     union =
vmx_inst_info info;=0A-    struct segment_register seg;=0A+    struct =
segment_register seg, cs;=0A     unsigned long base, index, seg_base, =
disp, offset;=0A     int scale, size;=0A =0A@@ -342,6 +342,11 @@ static =
int decode_vmx_inst(struct cpu_us=0A         hvm_get_segment_register(v, =
sreg_to_index[info.fields.segment], &seg);=0A         seg_base =3D =
seg.base;=0A =0A+        if ( hvm_long_mode_enabled(v) )=0A+            =
hvm_get_segment_register(v, x86_seg_cs, &cs);=0A+        else=0A+          =
  memset(&cs, 0, sizeof(cs));=0A+=0A         base =3D info.fields.base_reg_=
invalid ? 0 :=0A             reg_read(regs, info.fields.base_reg);=0A =
=0A@@ -355,8 +360,10 @@ static int decode_vmx_inst(struct cpu_us=0A        =
 size =3D 1 << (info.fields.addr_size + 1);=0A =0A         offset =3D base =
+ index * scale + disp;=0A-        if ( (offset > seg.limit || offset + =
size > seg.limit) &&=0A-            (!hvm_long_mode_enabled(v) || =
info.fields.segment =3D=3D VMX_SREG_GS) )=0A+        if ( cs.attr.fields.l =
?=0A+             (!is_canonical_address(offset) ||=0A+              =
!is_canonical_address(offset + size - 1)) :=0A+             (offset + size =
- 1 < offset || offset + size - 1 > seg.limit) )=0A             goto =
gp_fault;=0A =0A         if ( poperandS !=3D NULL &&=0A
--=__Part9AB44EE8.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part9AB44EE8.1__=--


From xen-devel-bounces@lists.xen.org Tue Apr 24 15:17:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhUB-00086V-Sx; Tue, 24 Apr 2012 15:16:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMhUA-000867-Ji
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:16:58 +0000
Received: from [85.158.143.99:26823] by server-2.bemta-4.messagelabs.com id
	58/DF-17550-9E3C69F4; Tue, 24 Apr 2012 15:16:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335280615!19801695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8210 invoked from network); 24 Apr 2012 15:16:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 15:16:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 16:16:54 +0100
Message-Id: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 16:17:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9AB44EE8.1__="
Cc: Eddie Dong <eddie.dong@intel.com>
Subject: [Xen-devel] [PATCH] nested vmx: fix instruction decode segment
	limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part9AB44EE8.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- no limit check in 64-bit mode (is not special in any way)
- limit check is needed in compatibility mode
- canonical address check should instead be performed in 64-bit mode
- the last accessed byte must be within limits, not the first byte past
  the accessed range

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -319,7 +319,7 @@ static int decode_vmx_inst(struct cpu_us
 {
     struct vcpu *v =3D current;
     union vmx_inst_info info;
-    struct segment_register seg;
+    struct segment_register seg, cs;
     unsigned long base, index, seg_base, disp, offset;
     int scale, size;
=20
@@ -342,6 +342,11 @@ static int decode_vmx_inst(struct cpu_us
         hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
         seg_base =3D seg.base;
=20
+        if ( hvm_long_mode_enabled(v) )
+            hvm_get_segment_register(v, x86_seg_cs, &cs);
+        else
+            memset(&cs, 0, sizeof(cs));
+
         base =3D info.fields.base_reg_invalid ? 0 :
             reg_read(regs, info.fields.base_reg);
=20
@@ -355,8 +360,10 @@ static int decode_vmx_inst(struct cpu_us
         size =3D 1 << (info.fields.addr_size + 1);
=20
         offset =3D base + index * scale + disp;
-        if ( (offset > seg.limit || offset + size > seg.limit) &&
-            (!hvm_long_mode_enabled(v) || info.fields.segment =3D=3D =
VMX_SREG_GS) )
+        if ( cs.attr.fields.l ?
+             (!is_canonical_address(offset) ||
+              !is_canonical_address(offset + size - 1)) :
+             (offset + size - 1 < offset || offset + size - 1 > seg.limit)=
 )
             goto gp_fault;
=20
         if ( poperandS !=3D NULL &&




--=__Part9AB44EE8.1__=
Content-Type: text/plain; name="vmx-nested-decode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vmx-nested-decode.patch"

nested vmx: fix instruction decode segment limit check=0A=0A- no limit =
check in 64-bit mode (is not special in any way)=0A- limit check is needed =
in compatibility mode=0A- canonical address check should instead be =
performed in 64-bit mode=0A- the last accessed byte must be within limits, =
not the first byte past=0A  the accessed range=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ =
b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ -319,7 +319,7 @@ static int decode_vmx_i=
nst(struct cpu_us=0A {=0A     struct vcpu *v =3D current;=0A     union =
vmx_inst_info info;=0A-    struct segment_register seg;=0A+    struct =
segment_register seg, cs;=0A     unsigned long base, index, seg_base, =
disp, offset;=0A     int scale, size;=0A =0A@@ -342,6 +342,11 @@ static =
int decode_vmx_inst(struct cpu_us=0A         hvm_get_segment_register(v, =
sreg_to_index[info.fields.segment], &seg);=0A         seg_base =3D =
seg.base;=0A =0A+        if ( hvm_long_mode_enabled(v) )=0A+            =
hvm_get_segment_register(v, x86_seg_cs, &cs);=0A+        else=0A+          =
  memset(&cs, 0, sizeof(cs));=0A+=0A         base =3D info.fields.base_reg_=
invalid ? 0 :=0A             reg_read(regs, info.fields.base_reg);=0A =
=0A@@ -355,8 +360,10 @@ static int decode_vmx_inst(struct cpu_us=0A        =
 size =3D 1 << (info.fields.addr_size + 1);=0A =0A         offset =3D base =
+ index * scale + disp;=0A-        if ( (offset > seg.limit || offset + =
size > seg.limit) &&=0A-            (!hvm_long_mode_enabled(v) || =
info.fields.segment =3D=3D VMX_SREG_GS) )=0A+        if ( cs.attr.fields.l =
?=0A+             (!is_canonical_address(offset) ||=0A+              =
!is_canonical_address(offset + size - 1)) :=0A+             (offset + size =
- 1 < offset || offset + size - 1 > seg.limit) )=0A             goto =
gp_fault;=0A =0A         if ( poperandS !=3D NULL &&=0A
--=__Part9AB44EE8.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part9AB44EE8.1__=--


From xen-devel-bounces@lists.xen.org Tue Apr 24 15:18:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:18:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhVz-0008QC-EO; Tue, 24 Apr 2012 15:18:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhVx-0008Pm-SN
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:18:50 +0000
Received: from [85.158.143.35:42986] by server-2.bemta-4.messagelabs.com id
	58/D2-17550-954C69F4; Tue, 24 Apr 2012 15:18:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335280728!11435758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26343 invoked from network); 24 Apr 2012 15:18:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:18:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:18:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhVv-0006Og-TK; Tue, 24 Apr 2012 15:18:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhVv-0007hh-SM;
	Tue, 24 Apr 2012 16:18:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50263.866899.407892@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:18:47 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-8-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 8/8] libxl__device_disk_local_attach:
	wait	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 8/8] libxl__device_disk_local_attach: wait for state "connected""):
> In order to make sure that the block device is available and ready to be
> used, wait for state "connected" in the backend before returning.
...
> Changes in v4:
> - improve exit paths.
...
> +    if (tmpdisk->vdev != NULL) {
> +        rc = libxl__device_from_disk(gc, 0, tmpdisk, &device);
> +        if (rc < 0)
> +            goto out_wait_err;

This still seems to have two error exit paths:

>   out:
>      if (t != XBT_NULL)
>          xs_transaction_end(ctx->xsh, t, 1);
>      return dev;
> + out_wait_err:
> +    libxl__device_disk_local_detach(gc, tmpdisk);
> +    return NULL;

Previously "out" was both a success and error exit path AFAICT.

I really don't care very much whether you want to combine the success
and error exit paths.  But there should be only one error exit path.
So please no "goto out_<some particular thing>_err".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:18:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:18:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhVz-0008QC-EO; Tue, 24 Apr 2012 15:18:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhVx-0008Pm-SN
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:18:50 +0000
Received: from [85.158.143.35:42986] by server-2.bemta-4.messagelabs.com id
	58/D2-17550-954C69F4; Tue, 24 Apr 2012 15:18:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335280728!11435758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjYwOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26343 invoked from network); 24 Apr 2012 15:18:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:18:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:18:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhVv-0006Og-TK; Tue, 24 Apr 2012 15:18:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhVv-0007hh-SM;
	Tue, 24 Apr 2012 16:18:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50263.866899.407892@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:18:47 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-8-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 8/8] libxl__device_disk_local_attach:
	wait	for state "connected"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 8/8] libxl__device_disk_local_attach: wait for state "connected""):
> In order to make sure that the block device is available and ready to be
> used, wait for state "connected" in the backend before returning.
...
> Changes in v4:
> - improve exit paths.
...
> +    if (tmpdisk->vdev != NULL) {
> +        rc = libxl__device_from_disk(gc, 0, tmpdisk, &device);
> +        if (rc < 0)
> +            goto out_wait_err;

This still seems to have two error exit paths:

>   out:
>      if (t != XBT_NULL)
>          xs_transaction_end(ctx->xsh, t, 1);
>      return dev;
> + out_wait_err:
> +    libxl__device_disk_local_detach(gc, tmpdisk);
> +    return NULL;

Previously "out" was both a success and error exit path AFAICT.

I really don't care very much whether you want to combine the success
and error exit paths.  But there should be only one error exit path.
So please no "goto out_<some particular thing>_err".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:23:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:23:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhZu-0000Yo-Tp; Tue, 24 Apr 2012 15:22:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhZt-0000Ya-DE
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:22:53 +0000
Received: from [85.158.143.99:13859] by server-3.bemta-4.messagelabs.com id
	8C/28-05853-C45C69F4; Tue, 24 Apr 2012 15:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335280971!25044298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16328 invoked from network); 24 Apr 2012 15:22:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:22:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:22:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:22:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhZq-0006Q2-TI; Tue, 24 Apr 2012 15:22:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhZq-0007ih-SR;
	Tue, 24 Apr 2012 16:22:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50506.869984.497578@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:22:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335276732.4347.155.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > -    child = fork();
> > +    pid_t (*fork_replacement)(void*) =
> > +        CTX->childproc_hooks
> > +        ? CTX->childproc_hooks->fork_replacement
> > +        : 0;
> > +    child =
> > +        fork_replacement
> > +        ? fork_replacement(CTX->childproc_user)
> > +        : fork();
> 
> A helper function or macro would be useful here?

There is exactly one call site for this, since no-one else in libxl is
allowed to call fork (except libxl__spawn_*, in the child as
previously discussed, and there it doesn't want to use the hook).

If you think it would be clearer I'm happy to make it into a
sub-function.  But IMO libxl__ev_child_fork is already quite short so
I don't see much point further splitting it up.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:23:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:23:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhZu-0000Yo-Tp; Tue, 24 Apr 2012 15:22:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhZt-0000Ya-DE
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:22:53 +0000
Received: from [85.158.143.99:13859] by server-3.bemta-4.messagelabs.com id
	8C/28-05853-C45C69F4; Tue, 24 Apr 2012 15:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335280971!25044298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16328 invoked from network); 24 Apr 2012 15:22:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:22:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:22:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:22:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhZq-0006Q2-TI; Tue, 24 Apr 2012 15:22:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhZq-0007ih-SR;
	Tue, 24 Apr 2012 16:22:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50506.869984.497578@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:22:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335276732.4347.155.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > -    child = fork();
> > +    pid_t (*fork_replacement)(void*) =
> > +        CTX->childproc_hooks
> > +        ? CTX->childproc_hooks->fork_replacement
> > +        : 0;
> > +    child =
> > +        fork_replacement
> > +        ? fork_replacement(CTX->childproc_user)
> > +        : fork();
> 
> A helper function or macro would be useful here?

There is exactly one call site for this, since no-one else in libxl is
allowed to call fork (except libxl__spawn_*, in the child as
previously discussed, and there it doesn't want to use the hook).

If you think it would be clearer I'm happy to make it into a
sub-function.  But IMO libxl__ev_child_fork is already quite short so
I don't see much point further splitting it up.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:25:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhcO-0000jT-I2; Tue, 24 Apr 2012 15:25:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhcN-0000jN-Ki
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:25:27 +0000
Received: from [85.158.143.99:29202] by server-2.bemta-4.messagelabs.com id
	81/DC-17550-6E5C69F4; Tue, 24 Apr 2012 15:25:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335281125!24502807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17816 invoked from network); 24 Apr 2012 15:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:25:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:25:24 +0100
Message-ID: <1335281123.4347.208.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:25:23 +0100
In-Reply-To: <1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 2/8] libxl:
 libxl__device_disk_local_attach return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:45 +0100, Stefano Stabellini wrote:
> Introduce a new libxl_device_disk** parameter to
> libxl__device_disk_local_attach, the parameter is allocated on the gc by
> libxl__device_disk_local_attach. It is going to fill it with
> informations about the new locally attached disk.  The new
> libxl_device_disk should be passed to libxl_device_disk_local_detach
> afterwards.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_bootloader.c |   10 ++++----
>  tools/libxl/libxl_internal.c   |   47 +++++++++++++++++++++++----------------
>  tools/libxl/libxl_internal.h   |    3 +-
>  3 files changed, 35 insertions(+), 25 deletions(-)
> 
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index 977c6d3..83cac78 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>      char *fifo = NULL;
>      char *diskpath = NULL;
>      char **args = NULL;
> +    libxl_device_disk *tmpdisk = NULL;
>  
>      char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
>      char *tempdir;
> @@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
>  
> -    diskpath = libxl__device_disk_local_attach(gc, disk);
> +    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
>      if (!diskpath) {
> +        rc = ERROR_FAIL;
>          goto out_close;
>      }
>  
> @@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>  
>      rc = 0;
>  out_close:
> -    if (diskpath) {
> -        libxl__device_disk_local_detach(gc, disk);
> -        free(diskpath);
> -    }
> +    if (tmpdisk)
> +        libxl__device_disk_local_detach(gc, tmpdisk);
>      if (fifo_fd > -1)
>          close(fifo_fd);
>      if (bootloader_fd > -1)
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index 1f428b2..3af77e7 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -323,64 +323,73 @@ out:
>      return rc;
>  }
>  
> -_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)
> +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
> +        const libxl_device_disk *disk,
> +        libxl_device_disk **new_disk)
>  {
>      libxl_ctx *ctx = gc->owner;
>      char *dev = NULL;
> -    char *ret = NULL;
>      int rc;
> -
> -    rc = libxl__device_disk_setdefault(gc, disk);
> +    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
> +    if (tmpdisk == NULL) goto out;
> +
> +    *new_disk = tmpdisk;

It would be good practice to not do this until we have succeeded, or do
you expect the caller to clean this up on error, even if the disk is
half constructed? I'd suggest that it ought be up to this function to
unwind on failure not the called.

tmpdisk isn't actually temporary, it's actually the result of this
function and lives for a fair while afterwards, perhaps loopdisk? or
dom0disk? or was this the patch where IanJ suggested renaming the param
disk (e.g. to guest_disk) and then using disk for this one? (That's
actually a good idea)

> +    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));

You don't actually need zalloc if you immediately memcpy over the whole
thing. Minor thing though.

> +    if (disk->pdev_path != NULL)
> +        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
> +    if (disk->script != NULL)
> +        tmpdisk->script = libxl__strdup(gc, disk->script);
> +    tmpdisk->vdev = NULL;
> +
> +    rc = libxl__device_disk_setdefault(gc, tmpdisk);
>      if (rc) goto out;
>  
> -    switch (disk->backend) {
> +    switch (tmpdisk->backend) {
>          case LIBXL_DISK_BACKEND_PHY:
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
> -                       disk->pdev_path);
> -            dev = disk->pdev_path;
> +                       tmpdisk->pdev_path);
> +            dev = tmpdisk->pdev_path;
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> -            switch (disk->format) {
> +            switch (tmpdisk->format) {
>              case LIBXL_DISK_FORMAT_RAW:
>                  /* optimise away the early tapdisk attach in this case */
>                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
>                             " tap disk %s directly (ie without using blktap)",
> -                           disk->pdev_path);
> -                dev = disk->pdev_path;
> +                           tmpdisk->pdev_path);
> +                dev = tmpdisk->pdev_path;
>                  break;
>              case LIBXL_DISK_FORMAT_VHD:
> -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> -                                            disk->format);
> +                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
> +                                            tmpdisk->format);
>                  break;
>              case LIBXL_DISK_FORMAT_QCOW:
>              case LIBXL_DISK_FORMAT_QCOW2:
>                  abort(); /* prevented by libxl__device_disk_set_backend */
>              default:
>                  LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> -                           "unrecognized disk format: %d", disk->format);
> +                           "unrecognized disk format: %d", tmpdisk->format);
>                  break;
>              }
>              break;
>          case LIBXL_DISK_BACKEND_QDISK:
> -            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> +            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
>                  LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
>                             " attach a qdisk image if the format is not raw");
>                  break;
>              }
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
>                         disk->pdev_path);
> -            dev = disk->pdev_path;
> +            dev = tmpdisk->pdev_path;
>              break;
>          default:
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
> -                "type: %d", disk->backend);
> +                "type: %d", tmpdisk->backend);
>              break;
>      }
>  
>   out:
> -    if (dev != NULL)
> -        ret = strdup(dev);
> -    return ret;
> +    return dev;
>  }
>  
>  _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 6927aef..2f1cf0f 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1006,7 +1006,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
>   * a device.
>   */
>  _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
> -        libxl_device_disk *disk);
> +        const libxl_device_disk *disk,
> +        libxl_device_disk **new_disk);
>  _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
>          libxl_device_disk *disk);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:25:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhcO-0000jT-I2; Tue, 24 Apr 2012 15:25:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhcN-0000jN-Ki
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:25:27 +0000
Received: from [85.158.143.99:29202] by server-2.bemta-4.messagelabs.com id
	81/DC-17550-6E5C69F4; Tue, 24 Apr 2012 15:25:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335281125!24502807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17816 invoked from network); 24 Apr 2012 15:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:25:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:25:24 +0100
Message-ID: <1335281123.4347.208.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:25:23 +0100
In-Reply-To: <1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 2/8] libxl:
 libxl__device_disk_local_attach return a new libxl_device_disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 11:45 +0100, Stefano Stabellini wrote:
> Introduce a new libxl_device_disk** parameter to
> libxl__device_disk_local_attach, the parameter is allocated on the gc by
> libxl__device_disk_local_attach. It is going to fill it with
> informations about the new locally attached disk.  The new
> libxl_device_disk should be passed to libxl_device_disk_local_detach
> afterwards.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_bootloader.c |   10 ++++----
>  tools/libxl/libxl_internal.c   |   47 +++++++++++++++++++++++----------------
>  tools/libxl/libxl_internal.h   |    3 +-
>  3 files changed, 35 insertions(+), 25 deletions(-)
> 
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index 977c6d3..83cac78 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>      char *fifo = NULL;
>      char *diskpath = NULL;
>      char **args = NULL;
> +    libxl_device_disk *tmpdisk = NULL;
>  
>      char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
>      char *tempdir;
> @@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
>  
> -    diskpath = libxl__device_disk_local_attach(gc, disk);
> +    diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk);
>      if (!diskpath) {
> +        rc = ERROR_FAIL;
>          goto out_close;
>      }
>  
> @@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>  
>      rc = 0;
>  out_close:
> -    if (diskpath) {
> -        libxl__device_disk_local_detach(gc, disk);
> -        free(diskpath);
> -    }
> +    if (tmpdisk)
> +        libxl__device_disk_local_detach(gc, tmpdisk);
>      if (fifo_fd > -1)
>          close(fifo_fd);
>      if (bootloader_fd > -1)
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index 1f428b2..3af77e7 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -323,64 +323,73 @@ out:
>      return rc;
>  }
>  
> -_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk)
> +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
> +        const libxl_device_disk *disk,
> +        libxl_device_disk **new_disk)
>  {
>      libxl_ctx *ctx = gc->owner;
>      char *dev = NULL;
> -    char *ret = NULL;
>      int rc;
> -
> -    rc = libxl__device_disk_setdefault(gc, disk);
> +    libxl_device_disk *tmpdisk = libxl__zalloc(gc, sizeof(libxl_device_disk));
> +    if (tmpdisk == NULL) goto out;
> +
> +    *new_disk = tmpdisk;

It would be good practice to not do this until we have succeeded, or do
you expect the caller to clean this up on error, even if the disk is
half constructed? I'd suggest that it ought be up to this function to
unwind on failure not the called.

tmpdisk isn't actually temporary, it's actually the result of this
function and lives for a fair while afterwards, perhaps loopdisk? or
dom0disk? or was this the patch where IanJ suggested renaming the param
disk (e.g. to guest_disk) and then using disk for this one? (That's
actually a good idea)

> +    memcpy(tmpdisk, disk, sizeof(libxl_device_disk));

You don't actually need zalloc if you immediately memcpy over the whole
thing. Minor thing though.

> +    if (disk->pdev_path != NULL)
> +        tmpdisk->pdev_path = libxl__strdup(gc, disk->pdev_path);
> +    if (disk->script != NULL)
> +        tmpdisk->script = libxl__strdup(gc, disk->script);
> +    tmpdisk->vdev = NULL;
> +
> +    rc = libxl__device_disk_setdefault(gc, tmpdisk);
>      if (rc) goto out;
>  
> -    switch (disk->backend) {
> +    switch (tmpdisk->backend) {
>          case LIBXL_DISK_BACKEND_PHY:
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
> -                       disk->pdev_path);
> -            dev = disk->pdev_path;
> +                       tmpdisk->pdev_path);
> +            dev = tmpdisk->pdev_path;
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> -            switch (disk->format) {
> +            switch (tmpdisk->format) {
>              case LIBXL_DISK_FORMAT_RAW:
>                  /* optimise away the early tapdisk attach in this case */
>                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
>                             " tap disk %s directly (ie without using blktap)",
> -                           disk->pdev_path);
> -                dev = disk->pdev_path;
> +                           tmpdisk->pdev_path);
> +                dev = tmpdisk->pdev_path;
>                  break;
>              case LIBXL_DISK_FORMAT_VHD:
> -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> -                                            disk->format);
> +                dev = libxl__blktap_devpath(gc, tmpdisk->pdev_path,
> +                                            tmpdisk->format);
>                  break;
>              case LIBXL_DISK_FORMAT_QCOW:
>              case LIBXL_DISK_FORMAT_QCOW2:
>                  abort(); /* prevented by libxl__device_disk_set_backend */
>              default:
>                  LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> -                           "unrecognized disk format: %d", disk->format);
> +                           "unrecognized disk format: %d", tmpdisk->format);
>                  break;
>              }
>              break;
>          case LIBXL_DISK_BACKEND_QDISK:
> -            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
> +            if (tmpdisk->format != LIBXL_DISK_FORMAT_RAW) {
>                  LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
>                             " attach a qdisk image if the format is not raw");
>                  break;
>              }
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
>                         disk->pdev_path);
> -            dev = disk->pdev_path;
> +            dev = tmpdisk->pdev_path;
>              break;
>          default:
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
> -                "type: %d", disk->backend);
> +                "type: %d", tmpdisk->backend);
>              break;
>      }
>  
>   out:
> -    if (dev != NULL)
> -        ret = strdup(dev);
> -    return ret;
> +    return dev;
>  }
>  
>  _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 6927aef..2f1cf0f 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1006,7 +1006,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
>   * a device.
>   */
>  _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
> -        libxl_device_disk *disk);
> +        const libxl_device_disk *disk,
> +        libxl_device_disk **new_disk);
>  _hidden int libxl__device_disk_local_detach(libxl__gc *gc,
>          libxl_device_disk *disk);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:26:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhdN-0000pk-6o; Tue, 24 Apr 2012 15:26:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhdK-0000pR-Vf
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:26:27 +0000
Received: from [85.158.138.51:4240] by server-4.bemta-3.messagelabs.com id
	1A/C0-15341-226C69F4; Tue, 24 Apr 2012 15:26:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335281185!23576040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20005 invoked from network); 24 Apr 2012 15:26:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:26:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:26:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:26:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhdJ-0006R5-0C; Tue, 24 Apr 2012 15:26:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhdI-0007kC-Vf;
	Tue, 24 Apr 2012 16:26:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50720.969869.401349@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:26:24 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335280113.4347.198.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
	<1335277100.4347.159.camel@zakaz.uk.xensource.com>
	<20374.47868.746605.101511@mariner.uk.xensource.com>
	<1335280113.4347.198.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation when domain dioes"):
> On Tue, 2012-04-24 at 15:38 +0100, Ian Jackson wrote:
> > if the domain is destroyed then
> > either (a) the entries in xenstore have already been deleted, in which
> > case the test here works or (b) they have not in which case something
> > has gone very badly wrong and we are going to leak those xenstore
> > entries, in which case trying to avoid leaking other stuff seems
> > futile.
> 
> I'm convinced. Maybe write that in a comment?

Good idea, willdo.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ta.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:26:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhdN-0000pk-6o; Tue, 24 Apr 2012 15:26:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhdK-0000pR-Vf
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:26:27 +0000
Received: from [85.158.138.51:4240] by server-4.bemta-3.messagelabs.com id
	1A/C0-15341-226C69F4; Tue, 24 Apr 2012 15:26:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335281185!23576040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20005 invoked from network); 24 Apr 2012 15:26:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:26:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:26:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:26:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhdJ-0006R5-0C; Tue, 24 Apr 2012 15:26:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhdI-0007kC-Vf;
	Tue, 24 Apr 2012 16:26:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.50720.969869.401349@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:26:24 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335280113.4347.198.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-25-git-send-email-ian.jackson@eu.citrix.com>
	<1335277100.4347.159.camel@zakaz.uk.xensource.com>
	<20374.47868.746605.101511@mariner.uk.xensource.com>
	<1335280113.4347.198.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation
 when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 24/24] libxl: aborting bootloader invocation when domain dioes"):
> On Tue, 2012-04-24 at 15:38 +0100, Ian Jackson wrote:
> > if the domain is destroyed then
> > either (a) the entries in xenstore have already been deleted, in which
> > case the test here works or (b) they have not in which case something
> > has gone very badly wrong and we are going to leak those xenstore
> > entries, in which case trying to avoid leaking other stuff seems
> > futile.
> 
> I'm convinced. Maybe write that in a comment?

Good idea, willdo.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ta.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhjf-0001SU-OO; Tue, 24 Apr 2012 15:32:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhje-0001SL-ND
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:32:58 +0000
Received: from [85.158.139.83:39052] by server-11.bemta-5.messagelabs.com id
	C2/E4-12959-7A7C69F4; Tue, 24 Apr 2012 15:32:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335281574!17941927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16641 invoked from network); 24 Apr 2012 15:32:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:32:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:32:54 +0100
Message-ID: <1335281572.4347.214.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:32:52 +0100
In-Reply-To: <20374.50506.869984.497578@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
	<20374.50506.869984.497578@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 16:22 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> > On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > > -    child = fork();
> > > +    pid_t (*fork_replacement)(void*) =
> > > +        CTX->childproc_hooks
> > > +        ? CTX->childproc_hooks->fork_replacement
> > > +        : 0;
> > > +    child =
> > > +        fork_replacement
> > > +        ? fork_replacement(CTX->childproc_user)
> > > +        : fork();
> > 
> > A helper function or macro would be useful here?
> 
> There is exactly one call site for this, since no-one else in libxl is
> allowed to call fork (except libxl__spawn_*, in the child as
> previously discussed, and there it doesn't want to use the hook).

> If you think it would be clearer I'm happy to make it into a
> sub-function.  But IMO libxl__ev_child_fork is already quite short so
> I don't see much point further splitting it up.

I guess I was just a bit slow on the parse of these two statements which
made me think a function might have a name which helped me, but your
explanation about it being the only possible callsite makes sense so I
think you can leave it as is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhjf-0001SU-OO; Tue, 24 Apr 2012 15:32:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMhje-0001SL-ND
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 15:32:58 +0000
Received: from [85.158.139.83:39052] by server-11.bemta-5.messagelabs.com id
	C2/E4-12959-7A7C69F4; Tue, 24 Apr 2012 15:32:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335281574!17941927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16641 invoked from network); 24 Apr 2012 15:32:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:32:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 16:32:54 +0100
Message-ID: <1335281572.4347.214.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:32:52 +0100
In-Reply-To: <20374.50506.869984.497578@mariner.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-24-git-send-email-ian.jackson@eu.citrix.com>
	<1335276732.4347.155.camel@zakaz.uk.xensource.com>
	<20374.50506.869984.497578@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 16:22 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups"):
> > On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > > -    child = fork();
> > > +    pid_t (*fork_replacement)(void*) =
> > > +        CTX->childproc_hooks
> > > +        ? CTX->childproc_hooks->fork_replacement
> > > +        : 0;
> > > +    child =
> > > +        fork_replacement
> > > +        ? fork_replacement(CTX->childproc_user)
> > > +        : fork();
> > 
> > A helper function or macro would be useful here?
> 
> There is exactly one call site for this, since no-one else in libxl is
> allowed to call fork (except libxl__spawn_*, in the child as
> previously discussed, and there it doesn't want to use the hook).

> If you think it would be clearer I'm happy to make it into a
> sub-function.  But IMO libxl__ev_child_fork is already quite short so
> I don't see much point further splitting it up.

I guess I was just a bit slow on the parse of these two statements which
made me think a function might have a name which helped me, but your
explanation about it being the only possible callsite makes sense so I
think you can leave it as is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:34:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhlL-0001Zc-8c; Tue, 24 Apr 2012 15:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhlJ-0001ZX-RY
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:34:42 +0000
Received: from [85.158.143.35:49863] by server-1.bemta-4.messagelabs.com id
	CB/6D-20925-118C69F4; Tue, 24 Apr 2012 15:34:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335281679!10311247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7975 invoked from network); 24 Apr 2012 15:34:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:34:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:34:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:34:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhkr-0006Te-MA; Tue, 24 Apr 2012 15:34:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhkr-0007ko-LL;
	Tue, 24 Apr 2012 16:34:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.51189.648228.606353@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:34:13 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 3/8] libxl: add a transaction parameter
	to	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 3/8] libxl: add a transaction parameter to libxl__device_generic_add"):
> Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
> XBT_NULL, allocate a proper one.
...
> -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> -                             char **bents, char **fents)
> +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> +        libxl__device *device, char **bents, char **fents)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      char *frontend_path, *backend_path;
> -    xs_transaction_t t;
>      struct xs_permissions frontend_perms[2];
>      struct xs_permissions backend_perms[2];
> +    int create_transaction = t == XBT_NULL;

This works.

Another way to do it is to have a separate variable,
something like this:
   xs_transaction_t our_transaction = t;
and then later
   if (!t) {
       our_transaction = t = xs_transaction_start....
       if (!t) error handling;
   }
and when you commit it set our_transaction to 0 and on error exit
   if (our_transaction)
       xs_transaction_end(..., our_transaction, 1);

I suggest this just because you may prefer to avoid separate boolean
sentinel variables - I know I do.


There is a difficulty in general with this function, which is that it
contains an enormous number of unchecked xenstore operations.  I'm not
saying you need to fix this now, but if at a later point this were to
be fixed, the function would need to get a proper error exit path
which would have to destroy the transaction iff it was created.

I mention this for completeness but you may want to transpose it into
a comment somehow.


Anyway,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:34:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhlL-0001Zc-8c; Tue, 24 Apr 2012 15:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhlJ-0001ZX-RY
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:34:42 +0000
Received: from [85.158.143.35:49863] by server-1.bemta-4.messagelabs.com id
	CB/6D-20925-118C69F4; Tue, 24 Apr 2012 15:34:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335281679!10311247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7975 invoked from network); 24 Apr 2012 15:34:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:34:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="12110800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:34:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:34:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhkr-0006Te-MA; Tue, 24 Apr 2012 15:34:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhkr-0007ko-LL;
	Tue, 24 Apr 2012 16:34:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.51189.648228.606353@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:34:13 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 3/8] libxl: add a transaction parameter
	to	libxl__device_generic_add
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 3/8] libxl: add a transaction parameter to libxl__device_generic_add"):
> Add a xs_transaction_t parameter to libxl__device_generic_add, if it is
> XBT_NULL, allocate a proper one.
...
> -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
> -                             char **bents, char **fents)
> +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
> +        libxl__device *device, char **bents, char **fents)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      char *frontend_path, *backend_path;
> -    xs_transaction_t t;
>      struct xs_permissions frontend_perms[2];
>      struct xs_permissions backend_perms[2];
> +    int create_transaction = t == XBT_NULL;

This works.

Another way to do it is to have a separate variable,
something like this:
   xs_transaction_t our_transaction = t;
and then later
   if (!t) {
       our_transaction = t = xs_transaction_start....
       if (!t) error handling;
   }
and when you commit it set our_transaction to 0 and on error exit
   if (our_transaction)
       xs_transaction_end(..., our_transaction, 1);

I suggest this just because you may prefer to avoid separate boolean
sentinel variables - I know I do.


There is a difficulty in general with this function, which is that it
contains an enormous number of unchecked xenstore operations.  I'm not
saying you need to fix this now, but if at a later point this were to
be fixed, the function would need to get a proper error exit path
which would have to destroy the transaction iff it was created.

I mention this for completeness but you may want to transpose it into
a comment somehow.


Anyway,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:40:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhqW-0001zw-Ma; Tue, 24 Apr 2012 15:40:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhqV-0001zm-Uw
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:40:04 +0000
Received: from [85.158.143.99:54888] by server-3.bemta-4.messagelabs.com id
	32/92-05853-359C69F4; Tue, 24 Apr 2012 15:40:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335282002!19821287!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11665 invoked from network); 24 Apr 2012 15:40:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12110913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:39:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:39:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhqN-0006VQ-1Y; Tue, 24 Apr 2012 15:39:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhqN-0007l4-0Y;
	Tue, 24 Apr 2012 16:39:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.51531.1906.733090@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:39:55 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 7/8] xl/libxl: implement
	QDISK	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index ac73070..bb75491 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -510,6 +510,7 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
...
> +                    if (tmpdisk->vdev == NULL) {
> +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                                "libxl__alloc_vdev failed\n");

LIBXL__LOG doesn't need an additional "\n".  You have several of
these.  Also you may prefer my new LOG convenience macro which is a
lot less verbose - look, no wrapping needed:
                           LOG(ERROR, "libxl__alloc_vdev failed);

> +    switch (disk->backend) {
> +        case LIBXL_DISK_BACKEND_QDISK:
> +            if (disk->vdev != NULL) {
> +                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
> +                        disk, 0);
> +                return libxl_device_disk_destroy(gc->owner,
> +                        LIBXL_TOOLSTACK_DOMID, disk);
> +            }
> +            break;
> +        default:
> +            /*
> +             * Nothing to do for PHYSTYPE_PHY.
> +             * For other device types assume that the blktap2 process is
> +             * needed by the soon to be started domain and do nothing.
> +             */
> +            break;

I guess what I meant with my previous comment is that it might be
better to have _local_attach return some kind of context/state struct,
bigger than the libxl__device_disk*, that would be passed to _detach.

But this will do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:40:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhqW-0001zw-Ma; Tue, 24 Apr 2012 15:40:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhqV-0001zm-Uw
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:40:04 +0000
Received: from [85.158.143.99:54888] by server-3.bemta-4.messagelabs.com id
	32/92-05853-359C69F4; Tue, 24 Apr 2012 15:40:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335282002!19821287!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11665 invoked from network); 24 Apr 2012 15:40:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12110913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:39:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:39:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhqN-0006VQ-1Y; Tue, 24 Apr 2012 15:39:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhqN-0007l4-0Y;
	Tue, 24 Apr 2012 16:39:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.51531.1906.733090@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:39:55 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 7/8] xl/libxl: implement
	QDISK	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index ac73070..bb75491 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -510,6 +510,7 @@ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
...
> +                    if (tmpdisk->vdev == NULL) {
> +                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                                "libxl__alloc_vdev failed\n");

LIBXL__LOG doesn't need an additional "\n".  You have several of
these.  Also you may prefer my new LOG convenience macro which is a
lot less verbose - look, no wrapping needed:
                           LOG(ERROR, "libxl__alloc_vdev failed);

> +    switch (disk->backend) {
> +        case LIBXL_DISK_BACKEND_QDISK:
> +            if (disk->vdev != NULL) {
> +                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
> +                        disk, 0);
> +                return libxl_device_disk_destroy(gc->owner,
> +                        LIBXL_TOOLSTACK_DOMID, disk);
> +            }
> +            break;
> +        default:
> +            /*
> +             * Nothing to do for PHYSTYPE_PHY.
> +             * For other device types assume that the blktap2 process is
> +             * needed by the soon to be started domain and do nothing.
> +             */
> +            break;

I guess what I meant with my previous comment is that it might be
better to have _local_attach return some kind of context/state struct,
bigger than the libxl__device_disk*, that would be passed to _detach.

But this will do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhsV-0002Ff-RB; Tue, 24 Apr 2012 15:42:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhsV-0002FU-6J
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:42:07 +0000
Received: from [85.158.143.35:25257] by server-1.bemta-4.messagelabs.com id
	EE/C8-20925-EC9C69F4; Tue, 24 Apr 2012 15:42:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335282126!13475662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27939 invoked from network); 24 Apr 2012 15:42:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:42:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12110964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:42:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:42:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhsT-0006W8-KR; Tue, 24 Apr 2012 15:42:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhsT-0007lM-IQ;
	Tue, 24 Apr 2012 16:42:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.51661.526651.289834@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:42:05 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce
	libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"):
> Introduce libxl__device_disk_add_t that takes an additional
> xs_transaction_t paramter.

Names ending "_t" are reserved for the implementation.  But you can
just call the internal function libxl__device_disk_add.  I think it's
fine to internal and external functions which differ only in _ and
parameters, provided that there is no nontrivial functionality in the
external function.

Apart from that it's rather hard to review because this patch seems to
have an awful lot of code motion mixed up with other changes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhsV-0002Ff-RB; Tue, 24 Apr 2012 15:42:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhsV-0002FU-6J
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:42:07 +0000
Received: from [85.158.143.35:25257] by server-1.bemta-4.messagelabs.com id
	EE/C8-20925-EC9C69F4; Tue, 24 Apr 2012 15:42:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335282126!13475662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27939 invoked from network); 24 Apr 2012 15:42:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:42:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12110964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:42:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:42:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMhsT-0006W8-KR; Tue, 24 Apr 2012 15:42:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMhsT-0007lM-IQ;
	Tue, 24 Apr 2012 16:42:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.51661.526651.289834@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:42:05 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce
	libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"):
> Introduce libxl__device_disk_add_t that takes an additional
> xs_transaction_t paramter.

Names ending "_t" are reserved for the implementation.  But you can
just call the internal function libxl__device_disk_add.  I think it's
fine to internal and external functions which differ only in _ and
parameters, provided that there is no nontrivial functionality in the
external function.

Apart from that it's rather hard to review because this patch seems to
have an awful lot of code motion mixed up with other changes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:45:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhvn-0002eU-Fb; Tue, 24 Apr 2012 15:45:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhvl-0002eH-PK
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:45:30 +0000
Received: from [85.158.143.35:38955] by server-1.bemta-4.messagelabs.com id
	18/FD-20925-99AC69F4; Tue, 24 Apr 2012 15:45:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335282328!8560273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12954 invoked from network); 24 Apr 2012 15:45:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:45:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:45:28 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMhvk-0006XF-2f;
	Tue, 24 Apr 2012 15:45:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMhvk-00064y-1Q;
	Tue, 24 Apr 2012 16:45:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12741-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:45:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12741: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12741 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12741/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12708

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  f5f1e6ef9782
baseline version:
 xen                  494aa5ecd2e1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=f5f1e6ef9782
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing f5f1e6ef9782
+ branch=xen-4.1-testing
+ revision=f5f1e6ef9782
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r f5f1e6ef9782 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:45:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMhvn-0002eU-Fb; Tue, 24 Apr 2012 15:45:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMhvl-0002eH-PK
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:45:30 +0000
Received: from [85.158.143.35:38955] by server-1.bemta-4.messagelabs.com id
	18/FD-20925-99AC69F4; Tue, 24 Apr 2012 15:45:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335282328!8560273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQzOQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12954 invoked from network); 24 Apr 2012 15:45:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:45:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:45:28 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMhvk-0006XF-2f;
	Tue, 24 Apr 2012 15:45:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMhvk-00064y-1Q;
	Tue, 24 Apr 2012 16:45:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12741-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 16:45:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12741: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12741 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12741/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12708

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  f5f1e6ef9782
baseline version:
 xen                  494aa5ecd2e1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=f5f1e6ef9782
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing f5f1e6ef9782
+ branch=xen-4.1-testing
+ revision=f5f1e6ef9782
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r f5f1e6ef9782 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:54:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMi4F-00035E-OT; Tue, 24 Apr 2012 15:54:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMi4D-000356-Pv
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:54:13 +0000
Received: from [85.158.138.51:45915] by server-7.bemta-3.messagelabs.com id
	BA/9F-03078-3ACC69F4; Tue, 24 Apr 2012 15:54:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335282850!19231255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8983 invoked from network); 24 Apr 2012 15:54:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:54:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:53:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:53:08 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMi3A-0006Zs-KO; Tue, 24 Apr 2012 15:53:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMi3A-0007mQ-JX;
	Tue, 24 Apr 2012 16:53:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52324.593264.465997@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:53:08 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: xen_disk backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: xen_disk backports"):
> Stefano Stabellini (3):
>       xen: handle backend deletion from xenstore
>       xen_disk: use bdrv_aio_flush instead of bdrv_flush
>       xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

Thanks, they all look sensible, and you can put my ack on them:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

But can you please repost with some commit messages which contain a
reference to the corresponding upstream commit for each one ?  That
will make future archaeology much much easier.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:54:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMi4F-00035E-OT; Tue, 24 Apr 2012 15:54:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMi4D-000356-Pv
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:54:13 +0000
Received: from [85.158.138.51:45915] by server-7.bemta-3.messagelabs.com id
	BA/9F-03078-3ACC69F4; Tue, 24 Apr 2012 15:54:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335282850!19231255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8983 invoked from network); 24 Apr 2012 15:54:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:54:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:53:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:53:08 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMi3A-0006Zs-KO; Tue, 24 Apr 2012 15:53:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMi3A-0007mQ-JX;
	Tue, 24 Apr 2012 16:53:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52324.593264.465997@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:53:08 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
References: <alpine.DEB.2.00.1204241404180.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: xen_disk backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: xen_disk backports"):
> Stefano Stabellini (3):
>       xen: handle backend deletion from xenstore
>       xen_disk: use bdrv_aio_flush instead of bdrv_flush
>       xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

Thanks, they all look sensible, and you can put my ack on them:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

But can you please repost with some commit messages which contain a
reference to the corresponding upstream commit for each one ?  That
will make future archaeology much much easier.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:54:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMi4e-00036w-5m; Tue, 24 Apr 2012 15:54:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMi4c-00036j-Up
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:54:39 +0000
Received: from [85.158.139.83:27872] by server-8.bemta-5.messagelabs.com id
	45/E1-26964-EBCC69F4; Tue, 24 Apr 2012 15:54:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335282877!24764070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10218 invoked from network); 24 Apr 2012 15:54:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:54:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:54:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMi4Y-0006aF-OH; Tue, 24 Apr 2012 15:54:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMi4Y-0007mk-NO;
	Tue, 24 Apr 2012 16:54:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52410.711578.975401@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:54:34 +0100
To: George Dunlap <George.Dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
	<CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> [Remembering to cc everyone]
> 
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package.  Please do not
> distribute."  Would that make sure no one is confused about the
> resulting package?

Yes, that would be straightforward and a good idea.  It should go into
the Description.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 15:54:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 15:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMi4e-00036w-5m; Tue, 24 Apr 2012 15:54:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMi4c-00036j-Up
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 15:54:39 +0000
Received: from [85.158.139.83:27872] by server-8.bemta-5.messagelabs.com id
	45/E1-26964-EBCC69F4; Tue, 24 Apr 2012 15:54:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335282877!24764070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10218 invoked from network); 24 Apr 2012 15:54:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 15:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 15:54:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 16:54:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMi4Y-0006aF-OH; Tue, 24 Apr 2012 15:54:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMi4Y-0007mk-NO;
	Tue, 24 Apr 2012 16:54:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52410.711578.975401@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 16:54:34 +0100
To: George Dunlap <George.Dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
	<CAFLBxZY8zgz0QbyFe87DVKucaWxRbqPmO_TG7U+_CEoxwEK67w@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> [Remembering to cc everyone]
> 
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package.  Please do not
> distribute."  Would that make sure no one is confused about the
> resulting package?

Yes, that would be straightforward and a good idea.  It should go into
the Description.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:01:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:01:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiBK-0003qw-6P; Tue, 24 Apr 2012 16:01:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiBI-0003qr-Mm
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:01:32 +0000
Received: from [85.158.143.99:58149] by server-2.bemta-4.messagelabs.com id
	24/72-17550-C5EC69F4; Tue, 24 Apr 2012 16:01:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335283291!24533300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29927 invoked from network); 24 Apr 2012 16:01:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:01:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:00:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:00:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiAG-0006dp-41; Tue, 24 Apr 2012 16:00:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiAG-0007n4-2n;
	Tue, 24 Apr 2012 17:00:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52764.72484.930673@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:00:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335277215.4347.161.camel@zakaz.uk.xensource.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
	<1335277215.4347.161.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <dunlapg@umich.edu>,
	xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
...
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do).  I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
> 
> That seems reasonable, but much of the functionality being added here
> isn't done by "make install", is it?
> 
> I'm not actually sure about the update-rc.d but the conf file handling
> is clearly not part of "make install"

Arguably this is a bug in "make install".  The "make install" of many
other upstream projects completely fails to overwrite any existing
config files.

So I'm convinced that enabling dpkg's conffile handling for the config
files is the right thing to do.

However, the way this is done in Fabio's patch ...

> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF

... is not good.  We should mark as a conffile exactly every (plain)
file installed in /etc.  This should be done with a simple "find"
rune.

Having considered the ramifications, I'm also convinced that it is
correct for the package name to /not/ contain the version number.  The
key question from a dpkg semantics point of view is this: would it
ever make sense to coinstall two different versions ?  If it would
then they must have different names.  If not then they should not.

Now the packages made by "make deb" claim, entirely for themselves,
various paths.  Attempting to coinstall two of them is going to go
very badly: firstly a dpkg file conflict, and then if you override
that, a mess where you have mostly overwritten the old package but
parts of it remain.

So I think if you say "dpkg -i thing_i_just_built.deb" it should
replace the thing you installed previously with the new one.  The old
one is definitely not going to work any more anyway and any pieces
of it that remain are just luck.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:01:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:01:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiBK-0003qw-6P; Tue, 24 Apr 2012 16:01:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiBI-0003qr-Mm
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:01:32 +0000
Received: from [85.158.143.99:58149] by server-2.bemta-4.messagelabs.com id
	24/72-17550-C5EC69F4; Tue, 24 Apr 2012 16:01:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335283291!24533300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29927 invoked from network); 24 Apr 2012 16:01:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:01:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:00:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:00:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiAG-0006dp-41; Tue, 24 Apr 2012 16:00:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiAG-0007n4-2n;
	Tue, 24 Apr 2012 17:00:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52764.72484.930673@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:00:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335277215.4347.161.camel@zakaz.uk.xensource.com>
References: <4F954422.1010803@tiscali.it>
	<1335273732.4347.130.camel@zakaz.uk.xensource.com>
	<CAFLBxZZNNPg5OQeu87jnX6H0sdNEpSS80KHRG_6nEiZofkfmxw@mail.gmail.com>
	<1335277215.4347.161.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <dunlapg@umich.edu>,
	xen-devel <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
...
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do).  I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
> 
> That seems reasonable, but much of the functionality being added here
> isn't done by "make install", is it?
> 
> I'm not actually sure about the update-rc.d but the conf file handling
> is clearly not part of "make install"

Arguably this is a bug in "make install".  The "make install" of many
other upstream projects completely fails to overwrite any existing
config files.

So I'm convinced that enabling dpkg's conffile handling for the config
files is the right thing to do.

However, the way this is done in Fabio's patch ...

> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF

... is not good.  We should mark as a conffile exactly every (plain)
file installed in /etc.  This should be done with a simple "find"
rune.

Having considered the ramifications, I'm also convinced that it is
correct for the package name to /not/ contain the version number.  The
key question from a dpkg semantics point of view is this: would it
ever make sense to coinstall two different versions ?  If it would
then they must have different names.  If not then they should not.

Now the packages made by "make deb" claim, entirely for themselves,
various paths.  Attempting to coinstall two of them is going to go
very badly: firstly a dpkg file conflict, and then if you override
that, a mess where you have mostly overwritten the old package but
parts of it remain.

So I think if you say "dpkg -i thing_i_just_built.deb" it should
replace the thing you installed previously with the new one.  The old
one is definitely not going to work any more anyway and any pieces
of it that remain are just luck.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiC3-0003tk-0K; Tue, 24 Apr 2012 16:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SMiC2-0003tc-1b
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:02:18 +0000
Received: from [85.158.143.35:20577] by server-2.bemta-4.messagelabs.com id
	FB/73-17550-98EC69F4; Tue, 24 Apr 2012 16:02:17 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335283335!14733581!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13662 invoked from network); 24 Apr 2012 16:02:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:02:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="24478648"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:02:04 -0400
Received: from [10.80.3.206] (10.80.3.206) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 24 Apr 2012
	12:02:04 -0400
Message-ID: <4F96CE7A.2030906@citrix.com>
Date: Tue, 24 Apr 2012 17:02:02 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
	<4F967099020000780007F81F@nat28.tlf.novell.com>
In-Reply-To: <4F967099020000780007F81F@nat28.tlf.novell.com>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit
 test for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/12 08:21, Jan Beulich wrote:
>>>> On 23.04.12 at 20:07, Malcolm Crossley<malcolm.crossley@citrix.com>  wrote:
>> The memory hotplug code was masking the hotplugged memory start address and
>> comparing to a shifted version of COMPAT MPT size but not doing the same for
>> the end address.
>> This patch applies the same shifting and masking to the end address and
>> reapplies the mask if the end address has been clamped.
> This lacks a Signed-off-by tag in any case.
>
> I'm not, however, seeing what is being fixed here:
> RDWR_COMPAT_MPT_VIRT_{START,END} are both aligned to a
> 1Gb boundary, so I'm not immediately seeing how the adjustment
> would result in any changed behavior.
>
> Also, assuming I'm overlooking something and the patch is indeed
> needed (and hence you'll resubmit), please fix the indentation to
> not use hard tabs, and adjust the lines you change anyway to
> match Xen's coding style.
>
> Jan
I didn't include a signed off by because it's an RFC patch and I wasn't completely sure the change was required.
I kept the code style of the existing code around the patch but I will update it to Xen coding style in the future
and it was my mistake for using hard tabs and my editor has been reconfigured so it won't happen in the future.

The key fix is the patch is that epfn is being compared to (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)
without a 2 bit shift.

This means that epfn is being compared to the size of the RDWR_COMPAT_MPT table instead of the maximum number of
entries the RDWR_COMPAT_MPT table can contain. This could result in the end regions of hotplugged memory being
inaccessible when using the RDWR_COMPAT_MPT table.

I also moved the epfn masking to occur before the comparison to RDWR_COMPAT_MPT to be consistent with the
spfn comparison code.

I can split the patch for to make the changes clearer if you want?

Malcolm

>> diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c
>> --- a/xen/arch/x86/x86_64/mm.c
>> +++ b/xen/arch/x86/x86_64/mm.c
>> @@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct
>>       int err = 0;
>>
>>       smap = info->spfn&  (~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) -1));
>> +    emap = ( (epfn + ((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1 ))&
>> +                ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1) );
>>
>>       /*
>>        * Notice: For hot-added memory, only range below m2p_compat_vstart
>> @@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct
>>       if   ((smap>  ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>
>> 2)) )
>>           return 0;
>>
>> -    if (epfn>  (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
>> -        epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2;
>> -
>> -    emap = ( (epfn + ((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1 ))&
>> -                ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1) );
>> +    if (emap>  ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2))
>> +    {
>> +        emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2;
>> +    	emap = emap&  ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1);
>> +    }
>>
>>       va = HIRO_COMPAT_MPT_VIRT_START +
>>            smap * sizeof(*compat_machine_to_phys_mapping);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiC3-0003tk-0K; Tue, 24 Apr 2012 16:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SMiC2-0003tc-1b
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:02:18 +0000
Received: from [85.158.143.35:20577] by server-2.bemta-4.messagelabs.com id
	FB/73-17550-98EC69F4; Tue, 24 Apr 2012 16:02:17 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335283335!14733581!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzY3ODg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13662 invoked from network); 24 Apr 2012 16:02:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:02:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="24478648"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:02:04 -0400
Received: from [10.80.3.206] (10.80.3.206) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 24 Apr 2012
	12:02:04 -0400
Message-ID: <4F96CE7A.2030906@citrix.com>
Date: Tue, 24 Apr 2012 17:02:02 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
	<4F967099020000780007F81F@nat28.tlf.novell.com>
In-Reply-To: <4F967099020000780007F81F@nat28.tlf.novell.com>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit
 test for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/12 08:21, Jan Beulich wrote:
>>>> On 23.04.12 at 20:07, Malcolm Crossley<malcolm.crossley@citrix.com>  wrote:
>> The memory hotplug code was masking the hotplugged memory start address and
>> comparing to a shifted version of COMPAT MPT size but not doing the same for
>> the end address.
>> This patch applies the same shifting and masking to the end address and
>> reapplies the mask if the end address has been clamped.
> This lacks a Signed-off-by tag in any case.
>
> I'm not, however, seeing what is being fixed here:
> RDWR_COMPAT_MPT_VIRT_{START,END} are both aligned to a
> 1Gb boundary, so I'm not immediately seeing how the adjustment
> would result in any changed behavior.
>
> Also, assuming I'm overlooking something and the patch is indeed
> needed (and hence you'll resubmit), please fix the indentation to
> not use hard tabs, and adjust the lines you change anyway to
> match Xen's coding style.
>
> Jan
I didn't include a signed off by because it's an RFC patch and I wasn't completely sure the change was required.
I kept the code style of the existing code around the patch but I will update it to Xen coding style in the future
and it was my mistake for using hard tabs and my editor has been reconfigured so it won't happen in the future.

The key fix is the patch is that epfn is being compared to (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)
without a 2 bit shift.

This means that epfn is being compared to the size of the RDWR_COMPAT_MPT table instead of the maximum number of
entries the RDWR_COMPAT_MPT table can contain. This could result in the end regions of hotplugged memory being
inaccessible when using the RDWR_COMPAT_MPT table.

I also moved the epfn masking to occur before the comparison to RDWR_COMPAT_MPT to be consistent with the
spfn comparison code.

I can split the patch for to make the changes clearer if you want?

Malcolm

>> diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c
>> --- a/xen/arch/x86/x86_64/mm.c
>> +++ b/xen/arch/x86/x86_64/mm.c
>> @@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct
>>       int err = 0;
>>
>>       smap = info->spfn&  (~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) -1));
>> +    emap = ( (epfn + ((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1 ))&
>> +                ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1) );
>>
>>       /*
>>        * Notice: For hot-added memory, only range below m2p_compat_vstart
>> @@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct
>>       if   ((smap>  ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>
>> 2)) )
>>           return 0;
>>
>> -    if (epfn>  (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
>> -        epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2;
>> -
>> -    emap = ( (epfn + ((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1 ))&
>> -                ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1) );
>> +    if (emap>  ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2))
>> +    {
>> +        emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2;
>> +    	emap = emap&  ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1);
>> +    }
>>
>>       va = HIRO_COMPAT_MPT_VIRT_START +
>>            smap * sizeof(*compat_machine_to_phys_mapping);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:03:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiDA-0003zp-FL; Tue, 24 Apr 2012 16:03:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiD8-0003zc-MO
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:03:26 +0000
Received: from [193.109.254.147:51405] by server-10.bemta-14.messagelabs.com
	id 4A/D8-05847-ECEC69F4; Tue, 24 Apr 2012 16:03:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335283405!3647180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3824 invoked from network); 24 Apr 2012 16:03:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:03:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111581"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:02:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:02:24 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiC7-0006ee-Tw; Tue, 24 Apr 2012 16:02:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiC7-0007nV-T1;
	Tue, 24 Apr 2012 17:02:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52879.886051.266867@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:02:23 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>, <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20374.51661.526651.289834@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20374.51661.526651.289834@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v4 4/8] libxl:
	introduce	libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"):
> Stefano Stabellini writes ("[Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"):
> > Introduce libxl__device_disk_add_t that takes an additional
> > xs_transaction_t paramter.
> 
> Names ending "_t" are reserved for the implementation.

Sorry, I was unclear.  I meant the C language implementation.  So
libxl may not introduce anything called "..._t".

>  But you can just call the internal function libxl__device_disk_add.
> I think it's fine to internal and external functions which differ
> only in _ and parameters, provided that there is no nontrivial
> functionality in the external function.
> 
> Apart from that it's rather hard to review because this patch seems to
> have an awful lot of code motion mixed up with other changes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:03:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiDA-0003zp-FL; Tue, 24 Apr 2012 16:03:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiD8-0003zc-MO
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:03:26 +0000
Received: from [193.109.254.147:51405] by server-10.bemta-14.messagelabs.com
	id 4A/D8-05847-ECEC69F4; Tue, 24 Apr 2012 16:03:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335283405!3647180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3824 invoked from network); 24 Apr 2012 16:03:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:03:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111581"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:02:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:02:24 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiC7-0006ee-Tw; Tue, 24 Apr 2012 16:02:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiC7-0007nV-T1;
	Tue, 24 Apr 2012 17:02:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52879.886051.266867@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:02:23 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>, <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20374.51661.526651.289834@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204231810140.26786@kaball-desktop>
	<1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<20374.51661.526651.289834@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v4 4/8] libxl:
	introduce	libxl__device_disk_add_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"):
> Stefano Stabellini writes ("[Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"):
> > Introduce libxl__device_disk_add_t that takes an additional
> > xs_transaction_t paramter.
> 
> Names ending "_t" are reserved for the implementation.

Sorry, I was unclear.  I meant the C language implementation.  So
libxl may not introduce anything called "..._t".

>  But you can just call the internal function libxl__device_disk_add.
> I think it's fine to internal and external functions which differ
> only in _ and parameters, provided that there is no nontrivial
> functionality in the external function.
> 
> Apart from that it's rather hard to review because this patch seems to
> have an awful lot of code motion mixed up with other changes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:12:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiLC-0004RU-E9; Tue, 24 Apr 2012 16:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMiLA-0004RN-Rq
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:11:45 +0000
Received: from [85.158.138.51:53521] by server-2.bemta-3.messagelabs.com id
	B3/62-09269-FB0D69F4; Tue, 24 Apr 2012 16:11:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335283903!21779783!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18224 invoked from network); 24 Apr 2012 16:11:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 16:11:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 17:11:42 +0100
Message-Id: <4F96ECEF020000780007FB36@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 17:11:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
	<4F967099020000780007F81F@nat28.tlf.novell.com>
	<4F96CE7A.2030906@citrix.com>
In-Reply-To: <4F96CE7A.2030906@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit
 test for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 18:02, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
> The key fix is the patch is that epfn is being compared to 
> (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)
> without a 2 bit shift.

Ah, okay, that was well hidden among all the other changes you did,
and at least I wasn't able to decode this from the patch description.

> This means that epfn is being compared to the size of the RDWR_COMPAT_MPT 
> table instead of the maximum number of
> entries the RDWR_COMPAT_MPT table can contain. This could result in the end 
> regions of hotplugged memory being
> inaccessible when using the RDWR_COMPAT_MPT table.
> 
> I also moved the epfn masking to occur before the comparison to 
> RDWR_COMPAT_MPT to be consistent with the
> spfn comparison code.
> 
> I can split the patch for to make the changes clearer if you want?

I'm really not certain all the other changes really matter in any way,
so I'd really like to ask for a patch just adding the missing shift.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:12:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiLC-0004RU-E9; Tue, 24 Apr 2012 16:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMiLA-0004RN-Rq
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:11:45 +0000
Received: from [85.158.138.51:53521] by server-2.bemta-3.messagelabs.com id
	B3/62-09269-FB0D69F4; Tue, 24 Apr 2012 16:11:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335283903!21779783!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NTY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18224 invoked from network); 24 Apr 2012 16:11:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 16:11:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Apr 2012 17:11:42 +0100
Message-Id: <4F96ECEF020000780007FB36@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Apr 2012 17:11:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500>
	<4F967099020000780007F81F@nat28.tlf.novell.com>
	<4F96CE7A.2030906@citrix.com>
In-Reply-To: <4F96CE7A.2030906@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [RFC] xen: Fix memory hotplug end limit
 test for updating compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 18:02, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
> The key fix is the patch is that epfn is being compared to 
> (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)
> without a 2 bit shift.

Ah, okay, that was well hidden among all the other changes you did,
and at least I wasn't able to decode this from the patch description.

> This means that epfn is being compared to the size of the RDWR_COMPAT_MPT 
> table instead of the maximum number of
> entries the RDWR_COMPAT_MPT table can contain. This could result in the end 
> regions of hotplugged memory being
> inaccessible when using the RDWR_COMPAT_MPT table.
> 
> I also moved the epfn masking to occur before the comparison to 
> RDWR_COMPAT_MPT to be consistent with the
> spfn comparison code.
> 
> I can split the patch for to make the changes clearer if you want?

I'm really not certain all the other changes really matter in any way,
so I'd really like to ask for a patch just adding the missing shift.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:12:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiLk-0004Tw-Rd; Tue, 24 Apr 2012 16:12:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiLj-0004Tm-Pm
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:12:19 +0000
Received: from [85.158.143.99:54459] by server-3.bemta-4.messagelabs.com id
	1C/A1-05853-3E0D69F4; Tue, 24 Apr 2012 16:12:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335283938!25092595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22309 invoked from network); 24 Apr 2012 16:12:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:12:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:12:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:12:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiCu-0006f1-Pj; Tue, 24 Apr 2012 16:03:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiCu-0007ni-Om;
	Tue, 24 Apr 2012 17:03:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52925.940533.95590@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:03:09 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335279087.4347.186.camel@zakaz.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> I mean create a single struct with all of the options in it, from which
> libxl will select the appropriate set of parameters (much like the code
> you have now does. You don't need to decide the content of that struct
> at runtime.
> 
> The IDL patch is below, other than changing "us" to "sched_params" I
> think most of the rest of your patch remains the same.

Missing attachment ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:12:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiLk-0004Tw-Rd; Tue, 24 Apr 2012 16:12:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiLj-0004Tm-Pm
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:12:19 +0000
Received: from [85.158.143.99:54459] by server-3.bemta-4.messagelabs.com id
	1C/A1-05853-3E0D69F4; Tue, 24 Apr 2012 16:12:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335283938!25092595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22309 invoked from network); 24 Apr 2012 16:12:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:12:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12111965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:12:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:12:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiCu-0006f1-Pj; Tue, 24 Apr 2012 16:03:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiCu-0007ni-Om;
	Tue, 24 Apr 2012 17:03:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.52925.940533.95590@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:03:09 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335279087.4347.186.camel@zakaz.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> I mean create a single struct with all of the options in it, from which
> libxl will select the appropriate set of parameters (much like the code
> you have now does. You don't need to decide the content of that struct
> at runtime.
> 
> The IDL patch is below, other than changing "us" to "sched_params" I
> think most of the rest of your patch remains the same.

Missing attachment ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiNQ-0004bg-CZ; Tue, 24 Apr 2012 16:14:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiNO-0004bQ-Rf
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:14:03 +0000
Received: from [85.158.138.51:10587] by server-3.bemta-3.messagelabs.com id
	67/D6-04048-A41D69F4; Tue, 24 Apr 2012 16:14:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335284040!23505324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16400 invoked from network); 24 Apr 2012 16:14:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:14:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112032"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:14:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:14:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiNM-0006ih-Ds; Tue, 24 Apr 2012 16:14:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiNM-000853-Cn;
	Tue, 24 Apr 2012 17:14:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.53576.383924.683761@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:14:00 +0100
To: Mathieu =?iso-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v3] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mathieu Gagn=E9 writes ("[Xen-devel] [PATCH 0 of 4 v3] xl: add support for =
vif rate limiting"):
> The first patch (already applied) fixes trivial indentation issues
> and introduces no functional changes.

In general it is not necessary or desirable to repost patches which
have already been applied :-).  (But it's largely harmless.)

> The third patch adds the required plumbering in libxl/xl to add vif rate =
limiting support. It uses the `rate` option syntax from xm/xend, ensuring f=
ull backward compatiblity.
> =

> The final patch adds the "check-xl-vif-parse" test script which tests var=
ious `rate` syntax.

I have applied these two, thanks.

I added what I think are suitable .hgignore and .gitignore entries for
the results of the new test script.  Next time it would be helpful if
you were to do that.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiNQ-0004bg-CZ; Tue, 24 Apr 2012 16:14:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiNO-0004bQ-Rf
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:14:03 +0000
Received: from [85.158.138.51:10587] by server-3.bemta-3.messagelabs.com id
	67/D6-04048-A41D69F4; Tue, 24 Apr 2012 16:14:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335284040!23505324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16400 invoked from network); 24 Apr 2012 16:14:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:14:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112032"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:14:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:14:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiNM-0006ih-Ds; Tue, 24 Apr 2012 16:14:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiNM-000853-Cn;
	Tue, 24 Apr 2012 17:14:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.53576.383924.683761@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:14:00 +0100
To: Mathieu =?iso-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
References: <patchbomb.1334634682@mgagne.users.dev.iweb.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v3] xl: add support for vif rate
	limiting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mathieu Gagn=E9 writes ("[Xen-devel] [PATCH 0 of 4 v3] xl: add support for =
vif rate limiting"):
> The first patch (already applied) fixes trivial indentation issues
> and introduces no functional changes.

In general it is not necessary or desirable to repost patches which
have already been applied :-).  (But it's largely harmless.)

> The third patch adds the required plumbering in libxl/xl to add vif rate =
limiting support. It uses the `rate` option syntax from xm/xend, ensuring f=
ull backward compatiblity.
> =

> The final patch adds the "check-xl-vif-parse" test script which tests var=
ious `rate` syntax.

I have applied these two, thanks.

I added what I think are suitable .hgignore and .gitignore entries for
the results of the new test script.  Next time it would be helpful if
you were to do that.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:15:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiOv-0004oE-2u; Tue, 24 Apr 2012 16:15:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMiOt-0004o2-29
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:15:35 +0000
Received: from [85.158.143.99:2416] by server-1.bemta-4.messagelabs.com id
	D1/C5-20925-6A1D69F4; Tue, 24 Apr 2012 16:15:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335284133!19826961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3796 invoked from network); 24 Apr 2012 16:15:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:15:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:15:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 17:15:33 +0100
Message-ID: <1335284131.4347.216.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 17:15:31 +0100
In-Reply-To: <20374.52925.940533.95590@mariner.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>	<20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>	<20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 17:03 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> > I mean create a single struct with all of the options in it, from which
> > libxl will select the appropriate set of parameters (much like the code
> > you have now does. You don't need to decide the content of that struct
> > at runtime.
> > 
> > The IDL patch is below, other than changing "us" to "sched_params" I
> > think most of the rest of your patch remains the same.
> 
> Missing attachment ?

Yes, sorry.

Here it is:

diff -r aef90d90eb3b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Apr 24 16:53:00 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Apr 24 17:15:12 2012 +0100
@@ -224,6 +224,32 @@ libxl_domain_create_info = Struct("domai
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit_params = Struct("sched_credit_params", [
+    ("tslice_ms", integer),
+    ("ratelimit_us", integer),
+    ], dispose_fn=None)
+
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +282,12 @@ libxl_domain_build_info = Struct("domain
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
 
+    ("sched_params",     Struct(None, [("credit", libxl_sched_credit_domain),
+                                       ("credit2", libxl_sched_credit2_domain),
+                                       ("sedf", libxl_sched_sedf_domain),
+                                       ("arinc653", libxl_sched_arinc653_domain),
+                                       ]))
+    ,    
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_type),
@@ -417,28 +449,6 @@ libxl_cputopology = Struct("cputopology"
     ("node", uint32),
     ], dir=DIR_OUT)
 
-libxl_sched_credit_domain = Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
-
-libxl_sched_credit_params = Struct("sched_credit_params", [
-    ("tslice_ms", integer),
-    ("ratelimit_us", integer),
-    ], dispose_fn=None)
-
-libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:15:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiOv-0004oE-2u; Tue, 24 Apr 2012 16:15:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMiOt-0004o2-29
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:15:35 +0000
Received: from [85.158.143.99:2416] by server-1.bemta-4.messagelabs.com id
	D1/C5-20925-6A1D69F4; Tue, 24 Apr 2012 16:15:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335284133!19826961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3796 invoked from network); 24 Apr 2012 16:15:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:15:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:15:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 17:15:33 +0100
Message-ID: <1335284131.4347.216.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 17:15:31 +0100
In-Reply-To: <20374.52925.940533.95590@mariner.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>	<20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>	<20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 17:03 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> > I mean create a single struct with all of the options in it, from which
> > libxl will select the appropriate set of parameters (much like the code
> > you have now does. You don't need to decide the content of that struct
> > at runtime.
> > 
> > The IDL patch is below, other than changing "us" to "sched_params" I
> > think most of the rest of your patch remains the same.
> 
> Missing attachment ?

Yes, sorry.

Here it is:

diff -r aef90d90eb3b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Apr 24 16:53:00 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Apr 24 17:15:12 2012 +0100
@@ -224,6 +224,32 @@ libxl_domain_create_info = Struct("domai
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
+    ("weight", integer),
+    ("cap", integer),
+    ])
+
+libxl_sched_credit_params = Struct("sched_credit_params", [
+    ("tslice_ms", integer),
+    ("ratelimit_us", integer),
+    ], dispose_fn=None)
+
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
+    ("weight", integer),
+    ])
+
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ])
+
+libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
+    ("weight", integer),
+    ])
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -256,6 +282,12 @@ libxl_domain_build_info = Struct("domain
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
 
+    ("sched_params",     Struct(None, [("credit", libxl_sched_credit_domain),
+                                       ("credit2", libxl_sched_credit2_domain),
+                                       ("sedf", libxl_sched_sedf_domain),
+                                       ("arinc653", libxl_sched_arinc653_domain),
+                                       ]))
+    ,    
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_type),
@@ -417,28 +449,6 @@ libxl_cputopology = Struct("cputopology"
     ("node", uint32),
     ], dir=DIR_OUT)
 
-libxl_sched_credit_domain = Struct("sched_credit_domain", [
-    ("weight", integer),
-    ("cap", integer),
-    ])
-
-libxl_sched_credit_params = Struct("sched_credit_params", [
-    ("tslice_ms", integer),
-    ("ratelimit_us", integer),
-    ], dispose_fn=None)
-
-libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
-    ("weight", integer),
-    ])
-
-libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
-    ("period", integer),
-    ("slice", integer),
-    ("latency", integer),
-    ("extratime", integer),
-    ("weight", integer),
-    ])
-
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:20:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiTH-00056I-S9; Tue, 24 Apr 2012 16:20:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiTG-00056C-DF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:20:06 +0000
Received: from [85.158.139.83:3852] by server-11.bemta-5.messagelabs.com id
	19/C5-12959-5B2D69F4; Tue, 24 Apr 2012 16:20:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335284404!21025587!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4678 invoked from network); 24 Apr 2012 16:20:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:20:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:20:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:20:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiTE-0006mY-8q; Tue, 24 Apr 2012 16:20:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiTE-00085i-7i;
	Tue, 24 Apr 2012 17:20:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.53940.224705.242658@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:20:04 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335284131.4347.216.camel@zakaz.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> diff -r aef90d90eb3b tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Tue Apr 24 16:53:00 2012 +0100
> +++ b/tools/libxl/libxl_types.idl	Tue Apr 24 17:15:12 2012 +0100
...
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> +    ("weight", integer),
...
...
> +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
> +    ("weight", integer),
...
> +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
...
> +    ("weight", integer),
> +    ])
> +
> +libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
> +    ("weight", integer),
> +    ])
...
> +    ("sched_params",     Struct(None, [("credit", libxl_sched_credit_domain),
> +                                       ("credit2", libxl_sched_credit2_domain),
> +                                       ("sedf", libxl_sched_sedf_domain),
> +                                       ("arinc653", libxl_sched_arinc653_domain),
> +                                       ]))

The resulting sched_params structure contains four subfields called
"weight", all of which mean (roughly, obviously) the same thing and
all of which are to be set from the same "weight" xl configuration
parameter.  Is this really the most sensible way to do things ?

Perhaps it would be better to have a single sched_params struct which
contained all the parameters needed for any scheduler, and simply have
them ignored by libxl for schedulers we're not using.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:20:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiTH-00056I-S9; Tue, 24 Apr 2012 16:20:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiTG-00056C-DF
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:20:06 +0000
Received: from [85.158.139.83:3852] by server-11.bemta-5.messagelabs.com id
	19/C5-12959-5B2D69F4; Tue, 24 Apr 2012 16:20:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335284404!21025587!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4678 invoked from network); 24 Apr 2012 16:20:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:20:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:20:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:20:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiTE-0006mY-8q; Tue, 24 Apr 2012 16:20:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiTE-00085i-7i;
	Tue, 24 Apr 2012 17:20:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.53940.224705.242658@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:20:04 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335284131.4347.216.camel@zakaz.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss> <20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> diff -r aef90d90eb3b tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Tue Apr 24 16:53:00 2012 +0100
> +++ b/tools/libxl/libxl_types.idl	Tue Apr 24 17:15:12 2012 +0100
...
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> +    ("weight", integer),
...
...
> +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
> +    ("weight", integer),
...
> +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
...
> +    ("weight", integer),
> +    ])
> +
> +libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
> +    ("weight", integer),
> +    ])
...
> +    ("sched_params",     Struct(None, [("credit", libxl_sched_credit_domain),
> +                                       ("credit2", libxl_sched_credit2_domain),
> +                                       ("sedf", libxl_sched_sedf_domain),
> +                                       ("arinc653", libxl_sched_arinc653_domain),
> +                                       ]))

The resulting sched_params structure contains four subfields called
"weight", all of which mean (roughly, obviously) the same thing and
all of which are to be set from the same "weight" xl configuration
parameter.  Is this really the most sensible way to do things ?

Perhaps it would be better to have a single sched_params struct which
contained all the parameters needed for any scheduler, and simply have
them ignored by libxl for schedulers we're not using.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:25:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiYM-0005F6-Mv; Tue, 24 Apr 2012 16:25:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiYL-0005Ez-3a
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:25:21 +0000
Received: from [85.158.138.51:28503] by server-9.bemta-3.messagelabs.com id
	B0/D3-26691-0F3D69F4; Tue, 24 Apr 2012 16:25:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335284719!19519760!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22466 invoked from network); 24 Apr 2012 16:25:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:25:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:25:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:25:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiYI-0006pq-Im; Tue, 24 Apr 2012 16:25:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiYI-000865-Hm;
	Tue, 24 Apr 2012 17:25:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54254.482250.200623@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:25:18 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
	<115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] configure: Check for flex"=
):
> El 15/04/2012, a las 19:43, Jean Guyader escribi=F3:
> > libxl require the command flex to be present.
> > Verify in the configure script that the flex
> > command exsits.
> > =

> > Signed-off-by: Jean Guyader <jean.guyader@gmail.com>
> =

> =

> I've already sent a patch for this, detecting and setting Flex and Bison =
at configure, and printing a pretty error message if libxl needs them and t=
hey are not found:
> =

> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00923.html

(I'm afraid that patch is still in my (enormous) backlog, but:)

I'm not very convinced that that patch is an improvement.  All it
does, effectively, is change the error message from "flex: not found"
to a custom one which effectively says "I couldn't find flex".

If flex is not available, and the timestamps indicate the file needs
to be rebuilt, we have two choices, corresponding to two possible
situations:
  1. Assume that the problem is simply timestamp skew, and allow
     the build to continue without regenerating the file (although
     we should probably print a warning)
  2. Assume that the user has edited (or patched) the flex source
     code, and stop with an error

Of these I think 1. is preferable.  In the latter case, if the user
edited it themselves they will hopefully be reading the make output
and see the warning; whereas if the user applied a patch, the patch
should update the flex output too.

In practice we update these files rarely and of course we always
commit a corresponding change.  So doing 1. will only adversely affect
a small minority of developers.  Whereas doing 2. seems to cause
regular annoyance to many people who don't necessarily know what's
going on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:25:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiYM-0005F6-Mv; Tue, 24 Apr 2012 16:25:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiYL-0005Ez-3a
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:25:21 +0000
Received: from [85.158.138.51:28503] by server-9.bemta-3.messagelabs.com id
	B0/D3-26691-0F3D69F4; Tue, 24 Apr 2012 16:25:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335284719!19519760!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22466 invoked from network); 24 Apr 2012 16:25:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:25:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:25:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:25:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiYI-0006pq-Im; Tue, 24 Apr 2012 16:25:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiYI-000865-Hm;
	Tue, 24 Apr 2012 17:25:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54254.482250.200623@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:25:18 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
	<115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] configure: Check for flex"=
):
> El 15/04/2012, a las 19:43, Jean Guyader escribi=F3:
> > libxl require the command flex to be present.
> > Verify in the configure script that the flex
> > command exsits.
> > =

> > Signed-off-by: Jean Guyader <jean.guyader@gmail.com>
> =

> =

> I've already sent a patch for this, detecting and setting Flex and Bison =
at configure, and printing a pretty error message if libxl needs them and t=
hey are not found:
> =

> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00923.html

(I'm afraid that patch is still in my (enormous) backlog, but:)

I'm not very convinced that that patch is an improvement.  All it
does, effectively, is change the error message from "flex: not found"
to a custom one which effectively says "I couldn't find flex".

If flex is not available, and the timestamps indicate the file needs
to be rebuilt, we have two choices, corresponding to two possible
situations:
  1. Assume that the problem is simply timestamp skew, and allow
     the build to continue without regenerating the file (although
     we should probably print a warning)
  2. Assume that the user has edited (or patched) the flex source
     code, and stop with an error

Of these I think 1. is preferable.  In the latter case, if the user
edited it themselves they will hopefully be reading the make output
and see the warning; whereas if the user applied a patch, the patch
should update the flex output too.

In practice we update these files rarely and of course we always
commit a corresponding change.  So doing 1. will only adversely affect
a small minority of developers.  Whereas doing 2. seems to cause
regular annoyance to many people who don't necessarily know what's
going on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:28:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:28:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiay-0005M2-B7; Tue, 24 Apr 2012 16:28:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMiaw-0005Lp-9y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:28:02 +0000
Received: from [85.158.138.51:46374] by server-2.bemta-3.messagelabs.com id
	EA/BC-09269-194D69F4; Tue, 24 Apr 2012 16:28:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335284880!23456410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24146 invoked from network); 24 Apr 2012 16:28:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:28:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:28:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 17:28:00 +0100
Message-ID: <1335284879.4347.221.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 17:27:59 +0100
In-Reply-To: <20374.53940.224705.242658@mariner.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>	<20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>	<20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 17:20 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> > diff -r aef90d90eb3b tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Tue Apr 24 16:53:00 2012 +0100
> > +++ b/tools/libxl/libxl_types.idl	Tue Apr 24 17:15:12 2012 +0100
> ...
> > +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> > +    ("weight", integer),
> ...
> ...
> > +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
> > +    ("weight", integer),
> ...
> > +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
> ...
> > +    ("weight", integer),
> > +    ])
> > +
> > +libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
> > +    ("weight", integer),
> > +    ])
> ...
> > +    ("sched_params",     Struct(None, [("credit", libxl_sched_credit_domain),
> > +                                       ("credit2", libxl_sched_credit2_domain),
> > +                                       ("sedf", libxl_sched_sedf_domain),
> > +                                       ("arinc653", libxl_sched_arinc653_domain),
> > +                                       ]))
> 
> The resulting sched_params structure contains four subfields called
> "weight", all of which mean (roughly, obviously) the same thing and
> all of which are to be set from the same "weight" xl configuration
> parameter.  Is this really the most sensible way to do things ?

Perhaps not, but it would imply major surgery to the other scheduler
interfaces to do it some other way (since these same structs are used
for libxl_sched_*_{set,get}.

I'm not 100% sure that "weight" has the same meaning for each scheduler
either. It's at least plausible that I might want one weight for a
doamin if the scheduler is credit and something else if it is sedf.

> Perhaps it would be better to have a single sched_params struct which
> contained all the parameters needed for any scheduler, and simply have
> them ignored by libxl for schedulers we're not using.

You'd need to reconstitute each of the split structs in order to call
libxl_sched_FOO_set internally, I don't think I want to ask Dieter to
take on that much bigger job.

Modulo this IDL bit Dieter's patch looks quite nice.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:28:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:28:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiay-0005M2-B7; Tue, 24 Apr 2012 16:28:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMiaw-0005Lp-9y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:28:02 +0000
Received: from [85.158.138.51:46374] by server-2.bemta-3.messagelabs.com id
	EA/BC-09269-194D69F4; Tue, 24 Apr 2012 16:28:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335284880!23456410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24146 invoked from network); 24 Apr 2012 16:28:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:28:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:28:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 17:28:00 +0100
Message-ID: <1335284879.4347.221.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 17:27:59 +0100
In-Reply-To: <20374.53940.224705.242658@mariner.uk.xensource.com>
References: <1334934791.28331.101.camel@zakaz.uk.xensource.com>
	<20120423094623.GA13565@bloms.de>
	<1335182682.4347.15.camel@zakaz.uk.xensource.com>
	<1335190962.3122.10.camel@Abyss>	<20120423154112.GA15320@bloms.de>
	<1335197251.22133.5.camel@Solace>	<20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss>	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 17:20 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> > diff -r aef90d90eb3b tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Tue Apr 24 16:53:00 2012 +0100
> > +++ b/tools/libxl/libxl_types.idl	Tue Apr 24 17:15:12 2012 +0100
> ...
> > +libxl_sched_credit_domain = Struct("sched_credit_domain", [
> > +    ("weight", integer),
> ...
> ...
> > +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
> > +    ("weight", integer),
> ...
> > +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
> ...
> > +    ("weight", integer),
> > +    ])
> > +
> > +libxl_sched_arinc653_domain = Struct("sched_arinc653_domain", [
> > +    ("weight", integer),
> > +    ])
> ...
> > +    ("sched_params",     Struct(None, [("credit", libxl_sched_credit_domain),
> > +                                       ("credit2", libxl_sched_credit2_domain),
> > +                                       ("sedf", libxl_sched_sedf_domain),
> > +                                       ("arinc653", libxl_sched_arinc653_domain),
> > +                                       ]))
> 
> The resulting sched_params structure contains four subfields called
> "weight", all of which mean (roughly, obviously) the same thing and
> all of which are to be set from the same "weight" xl configuration
> parameter.  Is this really the most sensible way to do things ?

Perhaps not, but it would imply major surgery to the other scheduler
interfaces to do it some other way (since these same structs are used
for libxl_sched_*_{set,get}.

I'm not 100% sure that "weight" has the same meaning for each scheduler
either. It's at least plausible that I might want one weight for a
doamin if the scheduler is credit and something else if it is sedf.

> Perhaps it would be better to have a single sched_params struct which
> contained all the parameters needed for any scheduler, and simply have
> them ignored by libxl for schedulers we're not using.

You'd need to reconstitute each of the split structs in order to call
libxl_sched_FOO_set internally, I don't think I want to ask Dieter to
take on that much bigger job.

Modulo this IDL bit Dieter's patch looks quite nice.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMibV-0005PZ-PN; Tue, 24 Apr 2012 16:28:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMibU-0005PE-Ge
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:28:36 +0000
Received: from [85.158.143.99:17933] by server-1.bemta-4.messagelabs.com id
	1A/54-20925-3B4D69F4; Tue, 24 Apr 2012 16:28:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335284912!21701928!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30697 invoked from network); 24 Apr 2012 16:28:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 16:28:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OGSRr0022349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 16:28:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OGSQ55019060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 16:28:27 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OGSQoI010369; Tue, 24 Apr 2012 11:28:26 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 09:28:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1EB9B40327; Tue, 24 Apr 2012 12:23:22 -0400 (EDT)
Date: Tue, 24 Apr 2012 12:23:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120424162321.GH3213@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
	<CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 10:43:53PM +0800, Lin Ming wrote:
> On Mon, Apr 23, 2012 at 11:11 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> >> >> > How about return -1 on error?
> >> >> > The calling function can check -1 for error.
> >> >>
> >> >> Isn't -1 potentially (at least theoretically) a valid value to read=
 from
> >> >> one of these registers?
> >> >
> >> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
> >> >
> >> > Perhaps the fallback is to emulate (so retain some of the original c=
ode)
> >> > as we have been since .. uh 3.0?
> >>
> >> Do you mean the return value of io_apic_read in 3.0?
> >
> > No. I meant that we would continue to emulate. The improvement
> > is that now we do:
> >
> > =A0 =A0 =A0 if (reg =3D=3D 0x1)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
> > =A0 =A0 =A0 else if (reg =3D=3D 0x0)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
> >
> > instead of 0xfdfdfdfd.
> >
> >> It's 0xffffffff.
> >
> > Now it is 0xfdfdfdfd.
> >
> > I am suggesting that instead of BUG_ON(), we fallback to do returning
> > an emulatated IO_APIC values - like the ones that this original patch
> > cooked up..
> =

> But we still need to return some value if the register is not emulated.

Right. 0xfd;
> =

> How about below?


Almost perfect.
> =

> unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> {
>         struct physdev_apic apic_op;
>         int ret;
> =

>         apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
>         apic_op.reg =3D reg;
>         ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
>         if (!ret)
>                 return apic_op.value;
> =

>         /* emulate register */
>         if (reg =3D=3D 0x1)
>                 return 0x00170020;
>         else if (reg =3D=3D 0x0)
>                 return apic << 24;
>         else
>                 return -1;

	return 0xfd;
> }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMibV-0005PZ-PN; Tue, 24 Apr 2012 16:28:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMibU-0005PE-Ge
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:28:36 +0000
Received: from [85.158.143.99:17933] by server-1.bemta-4.messagelabs.com id
	1A/54-20925-3B4D69F4; Tue, 24 Apr 2012 16:28:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335284912!21701928!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30697 invoked from network); 24 Apr 2012 16:28:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 16:28:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OGSRr0022349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 16:28:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OGSQ55019060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 16:28:27 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OGSQoI010369; Tue, 24 Apr 2012 11:28:26 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 09:28:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1EB9B40327; Tue, 24 Apr 2012 12:23:22 -0400 (EDT)
Date: Tue, 24 Apr 2012 12:23:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120424162321.GH3213@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
	<CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 10:43:53PM +0800, Lin Ming wrote:
> On Mon, Apr 23, 2012 at 11:11 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> >> >> > How about return -1 on error?
> >> >> > The calling function can check -1 for error.
> >> >>
> >> >> Isn't -1 potentially (at least theoretically) a valid value to read=
 from
> >> >> one of these registers?
> >> >
> >> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
> >> >
> >> > Perhaps the fallback is to emulate (so retain some of the original c=
ode)
> >> > as we have been since .. uh 3.0?
> >>
> >> Do you mean the return value of io_apic_read in 3.0?
> >
> > No. I meant that we would continue to emulate. The improvement
> > is that now we do:
> >
> > =A0 =A0 =A0 if (reg =3D=3D 0x1)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
> > =A0 =A0 =A0 else if (reg =3D=3D 0x0)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
> >
> > instead of 0xfdfdfdfd.
> >
> >> It's 0xffffffff.
> >
> > Now it is 0xfdfdfdfd.
> >
> > I am suggesting that instead of BUG_ON(), we fallback to do returning
> > an emulatated IO_APIC values - like the ones that this original patch
> > cooked up..
> =

> But we still need to return some value if the register is not emulated.

Right. 0xfd;
> =

> How about below?


Almost perfect.
> =

> unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> {
>         struct physdev_apic apic_op;
>         int ret;
> =

>         apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
>         apic_op.reg =3D reg;
>         ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
>         if (!ret)
>                 return apic_op.value;
> =

>         /* emulate register */
>         if (reg =3D=3D 0x1)
>                 return 0x00170020;
>         else if (reg =3D=3D 0x0)
>                 return apic << 24;
>         else
>                 return -1;

	return 0xfd;
> }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMidZ-0005cy-Bz; Tue, 24 Apr 2012 16:30:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMidX-0005cY-IZ
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:30:43 +0000
Received: from [85.158.139.83:55659] by server-4.bemta-5.messagelabs.com id
	10/8E-10788-235D69F4; Tue, 24 Apr 2012 16:30:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335285042!25334504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23431 invoked from network); 24 Apr 2012 16:30:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:30:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:30:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:30:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMidV-0006wu-G1; Tue, 24 Apr 2012 16:30:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMidV-00007C-Di;
	Tue, 24 Apr 2012 17:30:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54577.227896.260551@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:30:41 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334584686.14560.187.camel@zakaz.uk.xensource.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
> > Move this hardcoded options from Config.mk to config/Tools.mk and add the
> > appropiate configure options.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMidZ-0005cy-Bz; Tue, 24 Apr 2012 16:30:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMidX-0005cY-IZ
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:30:43 +0000
Received: from [85.158.139.83:55659] by server-4.bemta-5.messagelabs.com id
	10/8E-10788-235D69F4; Tue, 24 Apr 2012 16:30:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335285042!25334504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23431 invoked from network); 24 Apr 2012 16:30:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:30:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:30:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:30:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMidV-0006wu-G1; Tue, 24 Apr 2012 16:30:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMidV-00007C-Di;
	Tue, 24 Apr 2012 17:30:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54577.227896.260551@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:30:41 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334584686.14560.187.camel@zakaz.uk.xensource.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
> > Move this hardcoded options from Config.mk to config/Tools.mk and add the
> > appropiate configure options.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:33:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiff-0005r9-50; Tue, 24 Apr 2012 16:32:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMifd-0005qr-Co
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:32:53 +0000
Received: from [193.109.254.147:5360] by server-7.bemta-14.messagelabs.com id
	7C/54-01627-4B5D69F4; Tue, 24 Apr 2012 16:32:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335285172!6108247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25959 invoked from network); 24 Apr 2012 16:32:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:32:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:32:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMifb-0006xk-DD; Tue, 24 Apr 2012 16:32:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMifb-0000CI-6y;
	Tue, 24 Apr 2012 17:32:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54707.152942.237216@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:32:51 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334595483.14560.249.camel@zakaz.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
	<20364.18772.529397.220632@mariner.uk.xensource.com>
	<1334595483.14560.249.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how
	to	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> libxl: add a dummy ao_how to libxl_domain_core_dump

Unfortunately this depends on my __attribute__((unused)) patch which
isn't in tree yet...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:33:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiff-0005r9-50; Tue, 24 Apr 2012 16:32:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMifd-0005qr-Co
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:32:53 +0000
Received: from [193.109.254.147:5360] by server-7.bemta-14.messagelabs.com id
	7C/54-01627-4B5D69F4; Tue, 24 Apr 2012 16:32:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335285172!6108247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25959 invoked from network); 24 Apr 2012 16:32:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:32:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:32:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMifb-0006xk-DD; Tue, 24 Apr 2012 16:32:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMifb-0000CI-6y;
	Tue, 24 Apr 2012 17:32:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54707.152942.237216@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:32:51 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334595483.14560.249.camel@zakaz.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
	<20364.18772.529397.220632@mariner.uk.xensource.com>
	<1334595483.14560.249.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how
	to	libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> libxl: add a dummy ao_how to libxl_domain_core_dump

Unfortunately this depends on my __attribute__((unused)) patch which
isn't in tree yet...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:34:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMigq-0005xu-K7; Tue, 24 Apr 2012 16:34:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMigp-0005xm-JM
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:34:07 +0000
Received: from [85.158.143.99:21136] by server-3.bemta-4.messagelabs.com id
	97/7B-05853-EF5D69F4; Tue, 24 Apr 2012 16:34:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335285246!18700853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29642 invoked from network); 24 Apr 2012 16:34:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:34:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:34:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 17:34:05 +0100
Message-ID: <1335285244.4347.222.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 17:34:04 +0100
In-Reply-To: <20374.54707.152942.237216@mariner.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
	<20364.18772.529397.220632@mariner.uk.xensource.com>
	<1334595483.14560.249.camel@zakaz.uk.xensource.com>
	<20374.54707.152942.237216@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
 libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 17:32 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > libxl: add a dummy ao_how to libxl_domain_core_dump
> 
> Unfortunately this depends on my __attribute__((unused)) patch which
> isn't in tree yet...

Right, I said just below the commit message:
> Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not
> used"

;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:34:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMigq-0005xu-K7; Tue, 24 Apr 2012 16:34:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMigp-0005xm-JM
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:34:07 +0000
Received: from [85.158.143.99:21136] by server-3.bemta-4.messagelabs.com id
	97/7B-05853-EF5D69F4; Tue, 24 Apr 2012 16:34:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335285246!18700853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29642 invoked from network); 24 Apr 2012 16:34:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:34:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:34:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 17:34:05 +0100
Message-ID: <1335285244.4347.222.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 17:34:04 +0100
In-Reply-To: <20374.54707.152942.237216@mariner.uk.xensource.com>
References: <a20c43492fbff622aa97.1334587406@cosworth.uk.xensource.com>
	<20364.16337.971144.457146@mariner.uk.xensource.com>
	<1334591807.14560.220.camel@zakaz.uk.xensource.com>
	<20364.18772.529397.220632@mariner.uk.xensource.com>
	<1334595483.14560.249.camel@zakaz.uk.xensource.com>
	<20374.54707.152942.237216@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to
 libxl_domain_core_dump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 17:32 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"):
> > libxl: add a dummy ao_how to libxl_domain_core_dump
> 
> Unfortunately this depends on my __attribute__((unused)) patch which
> isn't in tree yet...

Right, I said just below the commit message:
> Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not
> used"

;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:35:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMihn-00064B-3o; Tue, 24 Apr 2012 16:35:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMihl-00063s-Po
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:35:06 +0000
Received: from [85.158.138.51:31597] by server-10.bemta-3.messagelabs.com id
	2E/37-29478-836D69F4; Tue, 24 Apr 2012 16:35:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335285304!23508264!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25722 invoked from network); 24 Apr 2012 16:35:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:35:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:35:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:35:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMihj-0006yT-G4; Tue, 24 Apr 2012 16:35:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMihj-0001LN-92;
	Tue, 24 Apr 2012 17:35:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54837.623282.707578@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:35:01 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <86afad50-a6a2-4b10-b2e3-f675215d003d@default>
References: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
	<86afad50-a6a2-4b10-b2e3-f675215d003d@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and
 associated xl command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and associated xl command"):
> > From: Ian Campbell [mailto:ian.campbell@citrix.com]
> > Subject: [PATCH] libxl: Remove libxl_tmem_destroy and associated xl command
> > 
> > 
> > Accordingly remove this interface from libxl and xl but don't touch libxc or
> > the hypervisor.
> > 
> > This is the only libxl_tmem_* function which might potentially have required
> > conversion to be asynchronous and which therefore might have been a potential
> > API stability concern.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks for handling this!
> 
> Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:35:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMihn-00064B-3o; Tue, 24 Apr 2012 16:35:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMihl-00063s-Po
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:35:06 +0000
Received: from [85.158.138.51:31597] by server-10.bemta-3.messagelabs.com id
	2E/37-29478-836D69F4; Tue, 24 Apr 2012 16:35:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335285304!23508264!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25722 invoked from network); 24 Apr 2012 16:35:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:35:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:35:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:35:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMihj-0006yT-G4; Tue, 24 Apr 2012 16:35:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMihj-0001LN-92;
	Tue, 24 Apr 2012 17:35:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54837.623282.707578@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:35:01 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <86afad50-a6a2-4b10-b2e3-f675215d003d@default>
References: <bf46871ecfeee48a8685.1334588483@cosworth.uk.xensource.com>
	<86afad50-a6a2-4b10-b2e3-f675215d003d@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and
 associated xl command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] libxl: Remove libxl_tmem_destroy and associated xl command"):
> > From: Ian Campbell [mailto:ian.campbell@citrix.com]
> > Subject: [PATCH] libxl: Remove libxl_tmem_destroy and associated xl command
> > 
> > 
> > Accordingly remove this interface from libxl and xl but don't touch libxc or
> > the hypervisor.
> > 
> > This is the only libxl_tmem_* function which might potentially have required
> > conversion to be asynchronous and which therefore might have been a potential
> > API stability concern.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks for handling this!
> 
> Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:36:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiiS-00069R-KB; Tue, 24 Apr 2012 16:35:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMiiQ-000692-BS
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:35:46 +0000
Received: from [193.109.254.147:47175] by server-2.bemta-14.messagelabs.com id
	A5/51-19409-166D69F4; Tue, 24 Apr 2012 16:35:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335285343!3652233!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5MTAyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30050 invoked from network); 24 Apr 2012 16:35:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 16:35:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OGZWi5032694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 16:35:35 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OGZWcY013476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 16:35:32 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OGZVWc015814; Tue, 24 Apr 2012 11:35:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 09:35:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B0E440327; Tue, 24 Apr 2012 12:30:27 -0400 (EDT)
Date: Tue, 24 Apr 2012 12:30:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120424163027.GI3213@phenom.dumpdata.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204241607.24864.tobias.geiger@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > I redid the test;
> > > 
> > > a) with 3.3.0 kernel
> > > b) with 3.4.0-rc4
> > > c) with 3.40-rc4 and above patch
> > > 
> > > everything else remained the same, i.e. test-program and test-scenario
> > > was not changed and started after about 5min of domu bootup (so that no
> > > strange bootup-effects become relevant); same phy-backend (lvm on ssd),
> > > same everything else; so i cant see what else except the used dom0
> > > kernel is causing this issue; but here are the numbers:
> > > 
> > > a) read: 135mb/s write: 142mb/s
> > > b) read: 39mb/s  write: 39mb/s
> > > c) read: 40mb/s  write: 40mb/s
> > > 
> > > Only thing that may become relevant is the difference in kernel-config
> > > betwen 3.3 and 3.4 - here's the diff :
> > > http://pastebin.com/raw.php?i=Dy71Fegq
> > > 
> > > Jan, it seems you're right: The patch doesn't add extra performance
> > > regression - i guess i had an i/o intensive task running in dom0 while
> > > doing the benchmark yesterday, so that the write performance got so bad.
> > > sorry for that.
> > > 
> > > Still there's a significant performance penalty from 3.3 to 3.4
> > 
> > Could you please try to revert the following commits?
> > 
> > git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
No way
> > git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5

Startup.
> > git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f

Hm, this is just during startup.
> > git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595

No way.


> > git revert -n 4f14faaab4ee46a046b6baff85644be199de718c

Perhaps? But I am not seeing it.

> > git revert -n 9846ff10af12f9e7caac696737db6c990592a74a

Perhaps?
> 
> after reverting said 6 commits (thanks for the ids of these - had difficulties 
> to find them), the performance is back to normal.
> 
> should i try to circle it down to one of this 6, or do you have a hint on 
> which it might be?

I think either off these: 4f14faaab4ee46a046b6baff85644be199de718c
9846ff10af12f9e7caac696737db6c990592a74a might be the culprit.

Try the 9846ff10 first.

> 
> Greetings
> Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:36:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiiS-00069R-KB; Tue, 24 Apr 2012 16:35:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMiiQ-000692-BS
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:35:46 +0000
Received: from [193.109.254.147:47175] by server-2.bemta-14.messagelabs.com id
	A5/51-19409-166D69F4; Tue, 24 Apr 2012 16:35:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335285343!3652233!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5MTAyNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30050 invoked from network); 24 Apr 2012 16:35:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 16:35:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OGZWi5032694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 16:35:35 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OGZWcY013476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 16:35:32 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OGZVWc015814; Tue, 24 Apr 2012 11:35:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 09:35:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B0E440327; Tue, 24 Apr 2012 12:30:27 -0400 (EDT)
Date: Tue, 24 Apr 2012 12:30:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120424163027.GI3213@phenom.dumpdata.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204241607.24864.tobias.geiger@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > I redid the test;
> > > 
> > > a) with 3.3.0 kernel
> > > b) with 3.4.0-rc4
> > > c) with 3.40-rc4 and above patch
> > > 
> > > everything else remained the same, i.e. test-program and test-scenario
> > > was not changed and started after about 5min of domu bootup (so that no
> > > strange bootup-effects become relevant); same phy-backend (lvm on ssd),
> > > same everything else; so i cant see what else except the used dom0
> > > kernel is causing this issue; but here are the numbers:
> > > 
> > > a) read: 135mb/s write: 142mb/s
> > > b) read: 39mb/s  write: 39mb/s
> > > c) read: 40mb/s  write: 40mb/s
> > > 
> > > Only thing that may become relevant is the difference in kernel-config
> > > betwen 3.3 and 3.4 - here's the diff :
> > > http://pastebin.com/raw.php?i=Dy71Fegq
> > > 
> > > Jan, it seems you're right: The patch doesn't add extra performance
> > > regression - i guess i had an i/o intensive task running in dom0 while
> > > doing the benchmark yesterday, so that the write performance got so bad.
> > > sorry for that.
> > > 
> > > Still there's a significant performance penalty from 3.3 to 3.4
> > 
> > Could you please try to revert the following commits?
> > 
> > git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
No way
> > git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5

Startup.
> > git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f

Hm, this is just during startup.
> > git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595

No way.


> > git revert -n 4f14faaab4ee46a046b6baff85644be199de718c

Perhaps? But I am not seeing it.

> > git revert -n 9846ff10af12f9e7caac696737db6c990592a74a

Perhaps?
> 
> after reverting said 6 commits (thanks for the ids of these - had difficulties 
> to find them), the performance is back to normal.
> 
> should i try to circle it down to one of this 6, or do you have a hint on 
> which it might be?

I think either off these: 4f14faaab4ee46a046b6baff85644be199de718c
9846ff10af12f9e7caac696737db6c990592a74a might be the culprit.

Try the 9846ff10 first.

> 
> Greetings
> Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMijU-0006IJ-2n; Tue, 24 Apr 2012 16:36:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMijS-0006Hu-O6
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:36:50 +0000
Received: from [85.158.139.83:11245] by server-11.bemta-5.messagelabs.com id
	B8/E0-12959-F96D69F4; Tue, 24 Apr 2012 16:36:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335285406!24770124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 24 Apr 2012 16:36:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:36:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:36:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:36:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMijO-0006z4-AP; Tue, 24 Apr 2012 16:36:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMijO-00026F-9U;
	Tue, 24 Apr 2012 17:36:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54942.132249.434292@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:36:46 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334591484.14560.219.camel@zakaz.uk.xensource.com>
References: <20120416154210.GA6338@wavehammer.waldi.eu.org>
	<1334591484.14560.219.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] Rename public xenstore headers"):
> On Mon, 2012-04-16 at 16:42 +0100, Bastian Blank wrote:
> > The xenstore header xs.h is producing conflicts with other software[1].
> > 
> > xs is a too short identifier and does not matche the library. Renaming
> > the headers to xenstore.h and xenstore_lib.h is the easiest way to make
> > them easy recognizable and prevent furthe problems.
> 
> Thanks Bastian.
> 
> This needs a Signed-off-by from you, per the DCO at
> http://wiki.xen.org/wiki/SubmittingXenPatches
> 
> For my part:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I agree.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I can't see a good way to do this in a compatible manner for out of tree
> users[0], so I think if we are going to make this change then we should
> make a freeze exception and do it in 4.2 (i.e. rip the plaster off
> quickly rather than have distros solve this their own way while waiting
> for 4.3).

Yes.

> [0] apart perhaps from having /usr/include/xen-compat/xs.h and
> suggesting that people can use -I/usr/include/xen-compat as a bandaid,
> but at that point they may as well just sed their code, since they may
> need to support 4.1 anyhow.

I think this would be a useful thing to add.  Providing that would
mean that with -I/usr/include/xen-compat, the same code could compile
against both 4.1 and 4.2, if it said <xs.h>.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMijU-0006IJ-2n; Tue, 24 Apr 2012 16:36:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMijS-0006Hu-O6
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:36:50 +0000
Received: from [85.158.139.83:11245] by server-11.bemta-5.messagelabs.com id
	B8/E0-12959-F96D69F4; Tue, 24 Apr 2012 16:36:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335285406!24770124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 24 Apr 2012 16:36:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:36:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:36:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:36:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMijO-0006z4-AP; Tue, 24 Apr 2012 16:36:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMijO-00026F-9U;
	Tue, 24 Apr 2012 17:36:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.54942.132249.434292@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:36:46 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334591484.14560.219.camel@zakaz.uk.xensource.com>
References: <20120416154210.GA6338@wavehammer.waldi.eu.org>
	<1334591484.14560.219.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] Rename public xenstore headers"):
> On Mon, 2012-04-16 at 16:42 +0100, Bastian Blank wrote:
> > The xenstore header xs.h is producing conflicts with other software[1].
> > 
> > xs is a too short identifier and does not matche the library. Renaming
> > the headers to xenstore.h and xenstore_lib.h is the easiest way to make
> > them easy recognizable and prevent furthe problems.
> 
> Thanks Bastian.
> 
> This needs a Signed-off-by from you, per the DCO at
> http://wiki.xen.org/wiki/SubmittingXenPatches
> 
> For my part:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I agree.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I can't see a good way to do this in a compatible manner for out of tree
> users[0], so I think if we are going to make this change then we should
> make a freeze exception and do it in 4.2 (i.e. rip the plaster off
> quickly rather than have distros solve this their own way while waiting
> for 4.3).

Yes.

> [0] apart perhaps from having /usr/include/xen-compat/xs.h and
> suggesting that people can use -I/usr/include/xen-compat as a bandaid,
> but at that point they may as well just sed their code, since they may
> need to support 4.1 anyhow.

I think this would be a useful thing to add.  Providing that would
mean that with -I/usr/include/xen-compat, the same code could compile
against both 4.1 and 4.2, if it said <xs.h>.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:43:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMipM-0006et-TW; Tue, 24 Apr 2012 16:42:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMipL-0006eo-Jn
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:42:55 +0000
Received: from [85.158.143.35:30339] by server-2.bemta-4.messagelabs.com id
	F9/22-17550-E08D69F4; Tue, 24 Apr 2012 16:42:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335285774!14739669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6215 invoked from network); 24 Apr 2012 16:42:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:42:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:42:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:42:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMipK-00070x-03; Tue, 24 Apr 2012 16:42:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMipJ-0004Lq-8G;
	Tue, 24 Apr 2012 17:42:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55307.996637.992911@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:42:51 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1204131207250.15151@kaball-desktop>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204131207250.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
> On Thu, 12 Apr 2012, Ian Campbell wrote:
> > The time has come for another round of stable releases.
> > 
> > Please send (or resend) any outstanding backport requests for 4.0.4 and
> > 4.1.3 before Friday 20 April.
> > 
> > Note that 4.0.4 will likely be the last release in the 4.0.x branch.
> 
> For 4.1.x:
> 
> 289eb8848224efb649dc42a9bb3c086553cc2922 qemu-xen-traditional: QDISK fixes
> f8d95ca183c7d6072c2871588bde1fef7c601e22 qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
> bbe85879171f78463f777c1e47273de24d8a64ce qemu-xen-traditional: use O_DIRECT to open disk images for IDE

These are not yet in -unstable.  I will backport them when they are
provided we get a test push with them...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:43:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMipM-0006et-TW; Tue, 24 Apr 2012 16:42:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMipL-0006eo-Jn
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:42:55 +0000
Received: from [85.158.143.35:30339] by server-2.bemta-4.messagelabs.com id
	F9/22-17550-E08D69F4; Tue, 24 Apr 2012 16:42:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335285774!14739669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6215 invoked from network); 24 Apr 2012 16:42:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:42:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:42:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:42:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMipK-00070x-03; Tue, 24 Apr 2012 16:42:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMipJ-0004Lq-8G;
	Tue, 24 Apr 2012 17:42:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55307.996637.992911@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:42:51 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1204131207250.15151@kaball-desktop>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204131207250.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
 releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
> On Thu, 12 Apr 2012, Ian Campbell wrote:
> > The time has come for another round of stable releases.
> > 
> > Please send (or resend) any outstanding backport requests for 4.0.4 and
> > 4.1.3 before Friday 20 April.
> > 
> > Note that 4.0.4 will likely be the last release in the 4.0.x branch.
> 
> For 4.1.x:
> 
> 289eb8848224efb649dc42a9bb3c086553cc2922 qemu-xen-traditional: QDISK fixes
> f8d95ca183c7d6072c2871588bde1fef7c601e22 qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
> bbe85879171f78463f777c1e47273de24d8a64ce qemu-xen-traditional: use O_DIRECT to open disk images for IDE

These are not yet in -unstable.  I will backport them when they are
provided we get a test push with them...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:43:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMipb-0006gK-AI; Tue, 24 Apr 2012 16:43:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMipZ-0006fn-6c
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:43:09 +0000
Received: from [193.109.254.147:30828] by server-12.bemta-14.messagelabs.com
	id C7/93-05898-C18D69F4; Tue, 24 Apr 2012 16:43:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335285786!3661810!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20622 invoked from network); 24 Apr 2012 16:43:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:43:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191832116"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:35:36 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 12:35:35 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMiiF-0007Ug-AW;
	Tue, 24 Apr 2012 17:35:35 +0100
Message-ID: <4F96D658.1050604@citrix.com>
Date: Tue, 24 Apr 2012 17:35:36 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
	<115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
	<20374.54254.482250.200623@mariner.uk.xensource.com>
In-Reply-To: <20374.54254.482250.200623@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] configure: Check for fle=
x"):
>> El 15/04/2012, a las 19:43, Jean Guyader escribi=F3:
>>> libxl require the command flex to be present.
>>> Verify in the configure script that the flex
>>> command exsits.
>>>
>>> Signed-off-by: Jean Guyader<jean.guyader@gmail.com>
>>
>> I've already sent a patch for this, detecting and setting Flex and Bison=
 at configure, and printing a pretty error message if libxl needs them and =
they are not found:
>>
>> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00923.html
>
> (I'm afraid that patch is still in my (enormous) backlog, but:)
>
> I'm not very convinced that that patch is an improvement.  All it
> does, effectively, is change the error message from "flex: not found"
> to a custom one which effectively says "I couldn't find flex".

It also adds automatic detection of flex/bison from configure, so if the =

user has those installed, and they are needed, the compilation will not =

fail (without this patch the compilation will just fail).

> If flex is not available, and the timestamps indicate the file needs
> to be rebuilt, we have two choices, corresponding to two possible
> situations:
>    1. Assume that the problem is simply timestamp skew, and allow
>       the build to continue without regenerating the file (although
>       we should probably print a warning)
>    2. Assume that the user has edited (or patched) the flex source
>       code, and stop with an error
>
> Of these I think 1. is preferable.  In the latter case, if the user
> edited it themselves they will hopefully be reading the make output
> and see the warning; whereas if the user applied a patch, the patch
> should update the flex output too.
>
> In practice we update these files rarely and of course we always
> commit a corresponding change.  So doing 1. will only adversely affect
> a small minority of developers.  Whereas doing 2. seems to cause
> regular annoyance to many people who don't necessarily know what's
> going on.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:43:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMipb-0006gK-AI; Tue, 24 Apr 2012 16:43:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMipZ-0006fn-6c
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:43:09 +0000
Received: from [193.109.254.147:30828] by server-12.bemta-14.messagelabs.com
	id C7/93-05898-C18D69F4; Tue, 24 Apr 2012 16:43:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335285786!3661810!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20622 invoked from network); 24 Apr 2012 16:43:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:43:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191832116"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:35:36 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 12:35:35 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMiiF-0007Ug-AW;
	Tue, 24 Apr 2012 17:35:35 +0100
Message-ID: <4F96D658.1050604@citrix.com>
Date: Tue, 24 Apr 2012 17:35:36 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334515390-29941-1-git-send-email-jean.guyader@gmail.com>
	<115C65E3-769A-405D-A075-CB0D15AA6086@citrix.com>
	<20374.54254.482250.200623@mariner.uk.xensource.com>
In-Reply-To: <20374.54254.482250.200623@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] configure: Check for flex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] configure: Check for fle=
x"):
>> El 15/04/2012, a las 19:43, Jean Guyader escribi=F3:
>>> libxl require the command flex to be present.
>>> Verify in the configure script that the flex
>>> command exsits.
>>>
>>> Signed-off-by: Jean Guyader<jean.guyader@gmail.com>
>>
>> I've already sent a patch for this, detecting and setting Flex and Bison=
 at configure, and printing a pretty error message if libxl needs them and =
they are not found:
>>
>> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00923.html
>
> (I'm afraid that patch is still in my (enormous) backlog, but:)
>
> I'm not very convinced that that patch is an improvement.  All it
> does, effectively, is change the error message from "flex: not found"
> to a custom one which effectively says "I couldn't find flex".

It also adds automatic detection of flex/bison from configure, so if the =

user has those installed, and they are needed, the compilation will not =

fail (without this patch the compilation will just fail).

> If flex is not available, and the timestamps indicate the file needs
> to be rebuilt, we have two choices, corresponding to two possible
> situations:
>    1. Assume that the problem is simply timestamp skew, and allow
>       the build to continue without regenerating the file (although
>       we should probably print a warning)
>    2. Assume that the user has edited (or patched) the flex source
>       code, and stop with an error
>
> Of these I think 1. is preferable.  In the latter case, if the user
> edited it themselves they will hopefully be reading the make output
> and see the warning; whereas if the user applied a patch, the patch
> should update the flex output too.
>
> In practice we update these files rarely and of course we always
> commit a corresponding change.  So doing 1. will only adversely affect
> a small minority of developers.  Whereas doing 2. seems to cause
> regular annoyance to many people who don't necessarily know what's
> going on.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiqR-0006lq-Qh; Tue, 24 Apr 2012 16:44:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiqQ-0006lb-Lr
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:44:02 +0000
Received: from [85.158.139.83:49155] by server-9.bemta-5.messagelabs.com id
	FD/B3-09826-158D69F4; Tue, 24 Apr 2012 16:44:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335285840!25294729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14733 invoked from network); 24 Apr 2012 16:44:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:44:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:44:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:44:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiqO-00071M-3J; Tue, 24 Apr 2012 16:44:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiqN-0005uQ-RS;
	Tue, 24 Apr 2012 17:43:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55375.731329.295389@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:43:59 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
	<CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3
	stable	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
> On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > The time has come for another round of stable releases.
> >
> > Please send (or resend) any outstanding backport requests for 4.0.4 and
> > 4.1.3 before Friday 20 April.
> 
> I don't know whether can non-commit xen-unstable be considered for
> backport so I am trying since deadline is before coming Friday 20
> April 2012.
> 
> libxl/xend: name tap devices with a xentap prefix

Yes, I think this is OK in principle but we should wait for the
patches to actually go into -unstable and be tested there, before we
apply them to earlier trees.

IIRC we are waiting for a repost of the -unstable version ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiqR-0006lq-Qh; Tue, 24 Apr 2012 16:44:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiqQ-0006lb-Lr
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:44:02 +0000
Received: from [85.158.139.83:49155] by server-9.bemta-5.messagelabs.com id
	FD/B3-09826-158D69F4; Tue, 24 Apr 2012 16:44:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335285840!25294729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14733 invoked from network); 24 Apr 2012 16:44:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:44:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:44:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:44:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiqO-00071M-3J; Tue, 24 Apr 2012 16:44:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiqN-0005uQ-RS;
	Tue, 24 Apr 2012 17:43:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55375.731329.295389@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:43:59 +0100
To: Teck Choon Giam <giamteckchoon@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
	<CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3
	stable	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Teck Choon Giam writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
> On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > The time has come for another round of stable releases.
> >
> > Please send (or resend) any outstanding backport requests for 4.0.4 and
> > 4.1.3 before Friday 20 April.
> 
> I don't know whether can non-commit xen-unstable be considered for
> backport so I am trying since deadline is before coming Friday 20
> April 2012.
> 
> libxl/xend: name tap devices with a xentap prefix

Yes, I think this is OK in principle but we should wait for the
patches to actually go into -unstable and be tested there, before we
apply them to earlier trees.

IIRC we are waiting for a repost of the -unstable version ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMisY-00071g-II; Tue, 24 Apr 2012 16:46:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMisW-00071L-O5
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:46:12 +0000
Received: from [85.158.143.35:47409] by server-2.bemta-4.messagelabs.com id
	0E/05-17550-4D8D69F4; Tue, 24 Apr 2012 16:46:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335285971!13484945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14643 invoked from network); 24 Apr 2012 16:46:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:46:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:46:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMisV-000722-4R; Tue, 24 Apr 2012 16:46:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMisV-0006GP-15;
	Tue, 24 Apr 2012 17:46:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55506.937354.654834@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:46:10 +0100
To: Lin Ming <mlin@ss.pku.edu.cn>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334308092.2538.2.camel@hp6530s>
References: <1334308092.2538.2.camel@hp6530s>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lin Ming writes ("[Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting"):
> libxl__domain_build_info_setdefault may be called several times,
> so rtc_timeoffset can't be setted in it.
> 
> Move rtc_timeoffset setting logic to libxl__build_pre.
> 
> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMisY-00071g-II; Tue, 24 Apr 2012 16:46:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMisW-00071L-O5
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:46:12 +0000
Received: from [85.158.143.35:47409] by server-2.bemta-4.messagelabs.com id
	0E/05-17550-4D8D69F4; Tue, 24 Apr 2012 16:46:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335285971!13484945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MzY0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14643 invoked from network); 24 Apr 2012 16:46:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:46:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:46:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMisV-000722-4R; Tue, 24 Apr 2012 16:46:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMisV-0006GP-15;
	Tue, 24 Apr 2012 17:46:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55506.937354.654834@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:46:10 +0100
To: Lin Ming <mlin@ss.pku.edu.cn>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334308092.2538.2.camel@hp6530s>
References: <1334308092.2538.2.camel@hp6530s>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lin Ming writes ("[Xen-devel] [PATCH] libxl: fix rtc_timeoffset setting"):
> libxl__domain_build_info_setdefault may be called several times,
> so rtc_timeoffset can't be setted in it.
> 
> Move rtc_timeoffset setting logic to libxl__build_pre.
> 
> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMitj-0007E8-18; Tue, 24 Apr 2012 16:47:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMith-0007Dp-30
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:47:25 +0000
Received: from [193.109.254.147:45774] by server-3.bemta-14.messagelabs.com id
	ED/AB-23274-C19D69F4; Tue, 24 Apr 2012 16:47:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335286043!6119939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23072 invoked from network); 24 Apr 2012 16:47:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:47:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:47:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMitf-00072Z-Em; Tue, 24 Apr 2012 16:47:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMitf-0006I1-Dq;
	Tue, 24 Apr 2012 17:47:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55579.415116.357831@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:47:23 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334311360-32847-1-git-send-email-roger.pau@citrix.com>
References: <1334311360-32847-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: zhihao wang <accept.acm@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl/build: print a pretty message
	if	flex/bison are needed but not found
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl/build: print a pretty message if flex/bison are needed but not found"):
> This patchs adds better support for both Flex and Bison, which might be needed
> to compile libxl. Now configure script sets BISON and FLEX Makefile vars if
> bison and flex are found, but doesn't complain if they are not found.

Please see my recent comments in response to Jean Guyader's related
patch.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMitj-0007E8-18; Tue, 24 Apr 2012 16:47:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMith-0007Dp-30
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:47:25 +0000
Received: from [193.109.254.147:45774] by server-3.bemta-14.messagelabs.com id
	ED/AB-23274-C19D69F4; Tue, 24 Apr 2012 16:47:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335286043!6119939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23072 invoked from network); 24 Apr 2012 16:47:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:47:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:47:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMitf-00072Z-Em; Tue, 24 Apr 2012 16:47:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMitf-0006I1-Dq;
	Tue, 24 Apr 2012 17:47:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55579.415116.357831@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:47:23 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334311360-32847-1-git-send-email-roger.pau@citrix.com>
References: <1334311360-32847-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: zhihao wang <accept.acm@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl/build: print a pretty message
	if	flex/bison are needed but not found
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl/build: print a pretty message if flex/bison are needed but not found"):
> This patchs adds better support for both Flex and Bison, which might be needed
> to compile libxl. Now configure script sets BISON and FLEX Makefile vars if
> bison and flex are found, but doesn't complain if they are not found.

Please see my recent comments in response to Jean Guyader's related
patch.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:48:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:48:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiul-0007NR-G4; Tue, 24 Apr 2012 16:48:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiuk-0007NA-5s
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:48:30 +0000
Received: from [193.109.254.147:58813] by server-12.bemta-14.messagelabs.com
	id 70/47-05898-D59D69F4; Tue, 24 Apr 2012 16:48:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335286108!6092007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29686 invoked from network); 24 Apr 2012 16:48:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:48:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:48:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiui-000731-CP; Tue, 24 Apr 2012 16:48:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiui-0006IB-BU;
	Tue, 24 Apr 2012 17:48:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55644.341772.906042@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:48:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, Roger Pau Monne
	<roger.pau@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20374.54577.227896.260551@mariner.uk.xensource.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
	<20374.54577.227896.260551@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> > On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
> > > Move this hardcoded options from Config.mk to config/Tools.mk and add the
> > > appropiate configure options.
> > > 
> > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Oh, I forgot to mention: you didn't say in your commit message that I
should run ./autogen.sh.  But I did anyway.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:48:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:48:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiul-0007NR-G4; Tue, 24 Apr 2012 16:48:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiuk-0007NA-5s
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:48:30 +0000
Received: from [193.109.254.147:58813] by server-12.bemta-14.messagelabs.com
	id 70/47-05898-D59D69F4; Tue, 24 Apr 2012 16:48:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335286108!6092007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29686 invoked from network); 24 Apr 2012 16:48:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:48:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:48:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiui-000731-CP; Tue, 24 Apr 2012 16:48:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiui-0006IB-BU;
	Tue, 24 Apr 2012 17:48:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55644.341772.906042@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:48:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, Roger Pau Monne
	<roger.pau@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20374.54577.227896.260551@mariner.uk.xensource.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
	<20374.54577.227896.260551@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> > On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
> > > Move this hardcoded options from Config.mk to config/Tools.mk and add the
> > > appropiate configure options.
> > > 
> > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Oh, I forgot to mention: you didn't say in your commit message that I
should run ./autogen.sh.  But I did anyway.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:50:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiwm-0007a6-22; Tue, 24 Apr 2012 16:50:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMiwl-0007Zv-27
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:50:35 +0000
Received: from [193.109.254.147:36632] by server-10.bemta-14.messagelabs.com
	id B0/AB-05847-AD9D69F4; Tue, 24 Apr 2012 16:50:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335286216!6092585!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14779 invoked from network); 24 Apr 2012 16:50:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:50:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191834785"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:50:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 12:50:15 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMiwP-0007g6-Ib;
	Tue, 24 Apr 2012 17:50:15 +0100
Message-ID: <4F96D9C6.8070005@citrix.com>
Date: Tue, 24 Apr 2012 17:50:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
	<20374.54577.227896.260551@mariner.uk.xensource.com>
	<20374.55644.341772.906042@mariner.uk.xensource.com>
In-Reply-To: <20374.55644.341772.906042@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios =
and seabios and configure options"):
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombio=
s and seabios and configure options"):
>>> On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
>>>> Move this hardcoded options from Config.mk to config/Tools.mk and add =
the
>>>> appropiate configure options.
>>>>
>>>> Signed-off-by: Roger Pau Monne<roger.pau@citrix.com>
>>> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
>
> Oh, I forgot to mention: you didn't say in your commit message that I
> should run ./autogen.sh.  But I did anyway.
>
> Ian.

Thanks and sorry for that. I'm not going to add autoconf output to my =

patches, since it tends to make them harder to apply, specially if you =

apply some other change in between.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:50:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiwm-0007a6-22; Tue, 24 Apr 2012 16:50:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMiwl-0007Zv-27
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:50:35 +0000
Received: from [193.109.254.147:36632] by server-10.bemta-14.messagelabs.com
	id B0/AB-05847-AD9D69F4; Tue, 24 Apr 2012 16:50:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335286216!6092585!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14779 invoked from network); 24 Apr 2012 16:50:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:50:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191834785"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 12:50:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 12:50:15 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMiwP-0007g6-Ib;
	Tue, 24 Apr 2012 17:50:15 +0100
Message-ID: <4F96D9C6.8070005@citrix.com>
Date: Tue, 24 Apr 2012 17:50:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
	<20374.54577.227896.260551@mariner.uk.xensource.com>
	<20374.55644.341772.906042@mariner.uk.xensource.com>
In-Reply-To: <20374.55644.341772.906042@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios =
and seabios and configure options"):
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombio=
s and seabios and configure options"):
>>> On Mon, 2012-04-16 at 14:36 +0100, Roger Pau Monne wrote:
>>>> Move this hardcoded options from Config.mk to config/Tools.mk and add =
the
>>>> appropiate configure options.
>>>>
>>>> Signed-off-by: Roger Pau Monne<roger.pau@citrix.com>
>>> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
>
> Oh, I forgot to mention: you didn't say in your commit message that I
> should run ./autogen.sh.  But I did anyway.
>
> Ian.

Thanks and sorry for that. I'm not going to add autoconf output to my =

patches, since it tends to make them harder to apply, specially if you =

apply some other change in between.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:52:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiyU-0007jJ-Iw; Tue, 24 Apr 2012 16:52:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiyT-0007j6-1L
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:52:21 +0000
Received: from [85.158.143.35:18043] by server-2.bemta-4.messagelabs.com id
	84/BA-17550-44AD69F4; Tue, 24 Apr 2012 16:52:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335286339!14740844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29890 invoked from network); 24 Apr 2012 16:52:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112975"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:52:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiyR-00074O-Jg; Tue, 24 Apr 2012 16:52:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiyR-0006Id-I2;
	Tue, 24 Apr 2012 17:52:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55875.545082.935901@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:52:19 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1334317324-18422-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
	<1334317324-18422-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 3/3] libxl_qmp: remove libxl__qmp_migrate,
 introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[PATCH v8 3/3] libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save"):
> Following the recent changes to upstream Qemu, the best monitor command
> to suit or needs is "xen-save-devices-state" rather than "migrate".
> This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
> instead, that uses "xen-save-devices-state".
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

You've dropped my ack on this patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:52:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMiyU-0007jJ-Iw; Tue, 24 Apr 2012 16:52:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMiyT-0007j6-1L
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:52:21 +0000
Received: from [85.158.143.35:18043] by server-2.bemta-4.messagelabs.com id
	84/BA-17550-44AD69F4; Tue, 24 Apr 2012 16:52:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335286339!14740844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29890 invoked from network); 24 Apr 2012 16:52:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112975"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:52:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMiyR-00074O-Jg; Tue, 24 Apr 2012 16:52:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMiyR-0006Id-I2;
	Tue, 24 Apr 2012 17:52:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55875.545082.935901@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:52:19 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1334317324-18422-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1204131238070.15151@kaball-desktop>
	<1334317324-18422-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 3/3] libxl_qmp: remove libxl__qmp_migrate,
 introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[PATCH v8 3/3] libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save"):
> Following the recent changes to upstream Qemu, the best monitor command
> to suit or needs is "xen-save-devices-state" rather than "migrate".
> This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
> instead, that uses "xen-save-devices-state".
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

You've dropped my ack on this patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMizJ-0007oU-0T; Tue, 24 Apr 2012 16:53:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMizH-0007oF-NN
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:53:11 +0000
Received: from [85.158.138.51:49931] by server-2.bemta-3.messagelabs.com id
	A5/E1-09269-67AD69F4; Tue, 24 Apr 2012 16:53:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335286390!23510465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15625 invoked from network); 24 Apr 2012 16:53:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:53:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:53:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMizF-00074b-Gs; Tue, 24 Apr 2012 16:53:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMizF-0006Ip-Fs;
	Tue, 24 Apr 2012 17:53:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55925.480168.824107@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:53:09 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F96D9C6.8070005@citrix.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
	<20374.54577.227896.260551@mariner.uk.xensource.com>
	<20374.55644.341772.906042@mariner.uk.xensource.com>
	<4F96D9C6.8070005@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> Thanks and sorry for that. I'm not going to add autoconf output to my 
> patches, since it tends to make them harder to apply, specially if you 
> apply some other change in between.

That's fine.  I don't mind whether you include the autoconf output in
the patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMizJ-0007oU-0T; Tue, 24 Apr 2012 16:53:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMizH-0007oF-NN
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:53:11 +0000
Received: from [85.158.138.51:49931] by server-2.bemta-3.messagelabs.com id
	A5/E1-09269-67AD69F4; Tue, 24 Apr 2012 16:53:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335286390!23510465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15625 invoked from network); 24 Apr 2012 16:53:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12112990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:53:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:53:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMizF-00074b-Gs; Tue, 24 Apr 2012 16:53:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMizF-0006Ip-Fs;
	Tue, 24 Apr 2012 17:53:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.55925.480168.824107@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 17:53:09 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F96D9C6.8070005@citrix.com>
References: <1334583375-5877-1-git-send-email-roger.pau@citrix.com>
	<1334584686.14560.187.camel@zakaz.uk.xensource.com>
	<20374.54577.227896.260551@mariner.uk.xensource.com>
	<20374.55644.341772.906042@mariner.uk.xensource.com>
	<4F96D9C6.8070005@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: add ovmf,
 rombios and seabios and configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] autoconf: add ovmf, rombios and seabios and configure options"):
> Thanks and sorry for that. I'm not going to add autoconf output to my 
> patches, since it tends to make them harder to apply, specially if you 
> apply some other change in between.

That's fine.  I don't mind whether you include the autoconf output in
the patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:54:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:54:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj03-0007u6-FA; Tue, 24 Apr 2012 16:53:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMj01-0007tq-Rz
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:53:58 +0000
Received: from [85.158.138.51:56607] by server-5.bemta-3.messagelabs.com id
	7B/B5-17113-5AAD69F4; Tue, 24 Apr 2012 16:53:57 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335286436!19239671!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20676 invoked from network); 24 Apr 2012 16:53:56 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:53:56 -0000
Received: by lbom4 with SMTP id m4so267970lbo.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 09:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=PRLdP2QiPtGRWuG0m8+eJsGOVJ6Afe8nH8zyySpTRVg=;
	b=5dr8/KBHt6W1BtdnUjPbubxwfS3koezg9ClXHN+jMFs1Yy4YYQp8QaB4Gx9fzOKIbm
	dpNjDBGLfm9m37G7EKNawQuWS7+7VFpJaD3qPqRR/kqknGxBi7VjTARfbdCp3jexuMBP
	5glLz9HqMLI5DeZHjPVIL1bWvx8Z7tQnA8TcM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=PRLdP2QiPtGRWuG0m8+eJsGOVJ6Afe8nH8zyySpTRVg=;
	b=nVG9BmW1JBZNNT1+3p0m4BnGKyDsE9qMTC83jT92xUufzwRLKKyI8SlYCdRVcWWJYl
	un53MoMwueO75pjPLbXWTQpuOGWtyKO1EHzqo4yBpumgzt5z3TtRZ8EfXE8PMO7vYFiM
	CbrrOR43lLCXpxUZynRQjLrmUZ4LYY2wVNmiKv7T/V5JChqePgKC5kpro04JEHJv4HeU
	NtQCuyvy0w+Gq7SZaeAkypIbQaQ9LzSCShk4HwRMjSCk0a2whEopFw5OBjVCGKUWMi+Y
	i6N2v0ao/VlSwRFLTZWaiQRwN1fnr0f+NP8UgEnDjfdHhNA4m5Q8pB/tKEoN+5UjBdsr
	A84A==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr19695707lab.29.1335286114280;
	Tue, 24 Apr 2012 09:48:34 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 09:48:34 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <20374.45332.196951.828384@mariner.uk.xensource.com>
References: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
	<20374.45332.196951.828384@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 09:48:34 -0700
Message-ID: <CAB10MZB9zzmpkUyDACweN9i1ZvBCPEf6yp9CkDLvwVBWWS0s8g@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQlw0a321Ini4kfnchqjqUPXNqO1SqauJy+Z3uhcV3Ap5p7u11sD9K1x6NNTFpptUdw4643r
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-access: Check return values and clean
 up on errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 6:56 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Aravindh Puthiyaparambil writes ("[Xen-devel] [PATCH] xen-access: Check return values and clean up on errors during init"):
>> Check the return values of the libxc mem_access calls.
>> Free allocated structures (platform_info, domain_info) on errors
>> during initialization and exit
>> Unbind VIRQ, close event channel and connection to Xen on errors
>> during initialization
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>
> I'm afraid this patch has been wordwrapped at your end, so it doesn't
> apply.
>
> Can you resend a fixed version, or send also as an attachment ?

Sorry about that. I will patchbomb it this time.

> BTW the intent here looks reasonable and it's just a test program so
> I've not reviewed it in as much detail as I might do changes to the
> core code.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Aravindh

> Thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:54:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:54:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj03-0007u6-FA; Tue, 24 Apr 2012 16:53:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMj01-0007tq-Rz
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 16:53:58 +0000
Received: from [85.158.138.51:56607] by server-5.bemta-3.messagelabs.com id
	7B/B5-17113-5AAD69F4; Tue, 24 Apr 2012 16:53:57 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335286436!19239671!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20676 invoked from network); 24 Apr 2012 16:53:56 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:53:56 -0000
Received: by lbom4 with SMTP id m4so267970lbo.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 09:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=PRLdP2QiPtGRWuG0m8+eJsGOVJ6Afe8nH8zyySpTRVg=;
	b=5dr8/KBHt6W1BtdnUjPbubxwfS3koezg9ClXHN+jMFs1Yy4YYQp8QaB4Gx9fzOKIbm
	dpNjDBGLfm9m37G7EKNawQuWS7+7VFpJaD3qPqRR/kqknGxBi7VjTARfbdCp3jexuMBP
	5glLz9HqMLI5DeZHjPVIL1bWvx8Z7tQnA8TcM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=PRLdP2QiPtGRWuG0m8+eJsGOVJ6Afe8nH8zyySpTRVg=;
	b=nVG9BmW1JBZNNT1+3p0m4BnGKyDsE9qMTC83jT92xUufzwRLKKyI8SlYCdRVcWWJYl
	un53MoMwueO75pjPLbXWTQpuOGWtyKO1EHzqo4yBpumgzt5z3TtRZ8EfXE8PMO7vYFiM
	CbrrOR43lLCXpxUZynRQjLrmUZ4LYY2wVNmiKv7T/V5JChqePgKC5kpro04JEHJv4HeU
	NtQCuyvy0w+Gq7SZaeAkypIbQaQ9LzSCShk4HwRMjSCk0a2whEopFw5OBjVCGKUWMi+Y
	i6N2v0ao/VlSwRFLTZWaiQRwN1fnr0f+NP8UgEnDjfdHhNA4m5Q8pB/tKEoN+5UjBdsr
	A84A==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr19695707lab.29.1335286114280;
	Tue, 24 Apr 2012 09:48:34 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 09:48:34 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <20374.45332.196951.828384@mariner.uk.xensource.com>
References: <CAB10MZDy6ox77VpgCgOJZfv15owUq74e8eB7o2-xkixq6EMmTg@mail.gmail.com>
	<20374.45332.196951.828384@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 09:48:34 -0700
Message-ID: <CAB10MZB9zzmpkUyDACweN9i1ZvBCPEf6yp9CkDLvwVBWWS0s8g@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQlw0a321Ini4kfnchqjqUPXNqO1SqauJy+Z3uhcV3Ap5p7u11sD9K1x6NNTFpptUdw4643r
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-access: Check return values and clean
 up on errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 6:56 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Aravindh Puthiyaparambil writes ("[Xen-devel] [PATCH] xen-access: Check return values and clean up on errors during init"):
>> Check the return values of the libxc mem_access calls.
>> Free allocated structures (platform_info, domain_info) on errors
>> during initialization and exit
>> Unbind VIRQ, close event channel and connection to Xen on errors
>> during initialization
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>
> I'm afraid this patch has been wordwrapped at your end, so it doesn't
> apply.
>
> Can you resend a fixed version, or send also as an attachment ?

Sorry about that. I will patchbomb it this time.

> BTW the intent here looks reasonable and it's just a test program so
> I've not reviewed it in as much detail as I might do changes to the
> core code.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Aravindh

> Thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 16:57:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj3P-0008GX-5M; Tue, 24 Apr 2012 16:57:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMj3N-0008GM-Bo
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:57:25 +0000
Received: from [193.109.254.147:37200] by server-11.bemta-14.messagelabs.com
	id 07/6E-05858-47BD69F4; Tue, 24 Apr 2012 16:57:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335286644!6093378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31311 invoked from network); 24 Apr 2012 16:57:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:57:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:57:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:57:23 +0100
Date: Tue, 24 Apr 2012 18:03:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-560489631-1335286560=:26786"
Content-ID: <alpine.DEB.2.00.1204241757280.26786@kaball-desktop>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-560489631-1335286560=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1204241757281.26786@kaball-desktop>

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> On Apr 24, 2012, at 6:02 AM, Stefano Stabellini wrote:
> 
>       According to xenstore the console is connected for both domains and you
>       should be able to access them using /dev/pts/2 and /dev/pts/3.
>       The only issue I can see is that the disk for "finnix" is not
>       connected. Maybe an disk open error?
> 
> 
> Sure enough, you are right in both cases.   Connecting to the pty with screen gives me access to the console.   

That means there is still a bug in xl or xenconsole because "xl console"
should work.


> domutest is an archlinux instance which is using a LVM partition appears to work.   The finnix domU is using an ISO file
> and it does not appear to find it on boot up and I can't force it to find it, so running "xl create" doesn't work in that
> mode as well as I thought it had.     Running it with xend/xm, it works fine
> 
> Anything I should be looking at next?

Is the file you are trying to open on NFS by any chance?
My guess is that the file open is failing, maybe because of an opening flag.
We need to add some tracing to xen_disk.c in qemu to find out.
Could you please apply the appended patch to the qemu tree and then post
the qemu log file again?

---


diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 6aebb77..5c4828d 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -584,6 +584,7 @@ static int blk_init(struct XenDevice *xendev)
     int mode, qflags, have_barriers, info = 0;
     char *h = NULL;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     /* read xenstore entries */
     if (blkdev->params == NULL) {
 	blkdev->params = xenstore_read_be_str(&blkdev->xendev, "params");
@@ -598,6 +599,7 @@ static int blk_init(struct XenDevice *xendev)
 	    blkdev->filename  = blkdev->params;
 	}
     }
+    printf("DEBUG %s %d filename=%s\n",__func__,__LINE__,blkdev->filename);
     if (!strcmp("aio", blkdev->fileproto))
         blkdev->fileproto = "raw";
     if (blkdev->mode == NULL)
@@ -608,6 +610,7 @@ static int blk_init(struct XenDevice *xendev)
 	blkdev->dev = xenstore_read_be_str(&blkdev->xendev, "dev");
     if (blkdev->devtype == NULL)
 	blkdev->devtype = xenstore_read_be_str(&blkdev->xendev, "device-type");
+    printf("DEBUG %s %d protocol=%s\n",__func__,__LINE__,blkdev->fileproto);
 
     /* do we have all we need? */
     if (blkdev->params == NULL ||
@@ -616,6 +619,7 @@ static int blk_init(struct XenDevice *xendev)
 	blkdev->dev == NULL)
 	return -1;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     /* read-only ? */
     if (strcmp(blkdev->mode, "w") == 0) {
 	mode   = O_RDWR;
@@ -630,6 +634,7 @@ static int blk_init(struct XenDevice *xendev)
     if (blkdev->devtype && !strcmp(blkdev->devtype, "cdrom"))
 	info  |= VDISK_CDROM;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     /* init qemu block driver */
     blkdev->index = (blkdev->xendev.dev - 202 * 256) / 16;
     blkdev->index = drive_get_index(IF_XEN, 0, blkdev->index);
@@ -640,6 +645,7 @@ static int blk_init(struct XenDevice *xendev)
 	if (blkdev->bs) {
 	    if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
                            bdrv_find_format(blkdev->fileproto)) != 0) {
+                printf("DEBUG %s %d errno=%d\n",__func__,__LINE__,errno);
 		bdrv_delete(blkdev->bs);
 		blkdev->bs = NULL;
 	    }
@@ -651,6 +657,7 @@ static int blk_init(struct XenDevice *xendev)
         xen_be_printf(&blkdev->xendev, 2, "get configured bdrv (cmdline setup)\n");
 	blkdev->bs = drives_table[blkdev->index].bdrv;
     }
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     blkdev->file_blk  = BLOCK_SIZE;
     blkdev->file_size = bdrv_getlength(blkdev->bs);
     if (blkdev->file_size < 0) {
--8323329-560489631-1335286560=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-560489631-1335286560=:26786--


From xen-devel-bounces@lists.xen.org Tue Apr 24 16:57:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 16:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj3P-0008GX-5M; Tue, 24 Apr 2012 16:57:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMj3N-0008GM-Bo
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 16:57:25 +0000
Received: from [193.109.254.147:37200] by server-11.bemta-14.messagelabs.com
	id 07/6E-05858-47BD69F4; Tue, 24 Apr 2012 16:57:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335286644!6093378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31311 invoked from network); 24 Apr 2012 16:57:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 16:57:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 16:57:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 17:57:23 +0100
Date: Tue, 24 Apr 2012 18:03:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-560489631-1335286560=:26786"
Content-ID: <alpine.DEB.2.00.1204241757280.26786@kaball-desktop>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-560489631-1335286560=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1204241757281.26786@kaball-desktop>

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> On Apr 24, 2012, at 6:02 AM, Stefano Stabellini wrote:
> 
>       According to xenstore the console is connected for both domains and you
>       should be able to access them using /dev/pts/2 and /dev/pts/3.
>       The only issue I can see is that the disk for "finnix" is not
>       connected. Maybe an disk open error?
> 
> 
> Sure enough, you are right in both cases.   Connecting to the pty with screen gives me access to the console.   

That means there is still a bug in xl or xenconsole because "xl console"
should work.


> domutest is an archlinux instance which is using a LVM partition appears to work.   The finnix domU is using an ISO file
> and it does not appear to find it on boot up and I can't force it to find it, so running "xl create" doesn't work in that
> mode as well as I thought it had.     Running it with xend/xm, it works fine
> 
> Anything I should be looking at next?

Is the file you are trying to open on NFS by any chance?
My guess is that the file open is failing, maybe because of an opening flag.
We need to add some tracing to xen_disk.c in qemu to find out.
Could you please apply the appended patch to the qemu tree and then post
the qemu log file again?

---


diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 6aebb77..5c4828d 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -584,6 +584,7 @@ static int blk_init(struct XenDevice *xendev)
     int mode, qflags, have_barriers, info = 0;
     char *h = NULL;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     /* read xenstore entries */
     if (blkdev->params == NULL) {
 	blkdev->params = xenstore_read_be_str(&blkdev->xendev, "params");
@@ -598,6 +599,7 @@ static int blk_init(struct XenDevice *xendev)
 	    blkdev->filename  = blkdev->params;
 	}
     }
+    printf("DEBUG %s %d filename=%s\n",__func__,__LINE__,blkdev->filename);
     if (!strcmp("aio", blkdev->fileproto))
         blkdev->fileproto = "raw";
     if (blkdev->mode == NULL)
@@ -608,6 +610,7 @@ static int blk_init(struct XenDevice *xendev)
 	blkdev->dev = xenstore_read_be_str(&blkdev->xendev, "dev");
     if (blkdev->devtype == NULL)
 	blkdev->devtype = xenstore_read_be_str(&blkdev->xendev, "device-type");
+    printf("DEBUG %s %d protocol=%s\n",__func__,__LINE__,blkdev->fileproto);
 
     /* do we have all we need? */
     if (blkdev->params == NULL ||
@@ -616,6 +619,7 @@ static int blk_init(struct XenDevice *xendev)
 	blkdev->dev == NULL)
 	return -1;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     /* read-only ? */
     if (strcmp(blkdev->mode, "w") == 0) {
 	mode   = O_RDWR;
@@ -630,6 +634,7 @@ static int blk_init(struct XenDevice *xendev)
     if (blkdev->devtype && !strcmp(blkdev->devtype, "cdrom"))
 	info  |= VDISK_CDROM;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     /* init qemu block driver */
     blkdev->index = (blkdev->xendev.dev - 202 * 256) / 16;
     blkdev->index = drive_get_index(IF_XEN, 0, blkdev->index);
@@ -640,6 +645,7 @@ static int blk_init(struct XenDevice *xendev)
 	if (blkdev->bs) {
 	    if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
                            bdrv_find_format(blkdev->fileproto)) != 0) {
+                printf("DEBUG %s %d errno=%d\n",__func__,__LINE__,errno);
 		bdrv_delete(blkdev->bs);
 		blkdev->bs = NULL;
 	    }
@@ -651,6 +657,7 @@ static int blk_init(struct XenDevice *xendev)
         xen_be_printf(&blkdev->xendev, 2, "get configured bdrv (cmdline setup)\n");
 	blkdev->bs = drives_table[blkdev->index].bdrv;
     }
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     blkdev->file_blk  = BLOCK_SIZE;
     blkdev->file_size = bdrv_getlength(blkdev->bs);
     if (blkdev->file_size < 0) {
--8323329-560489631-1335286560=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-560489631-1335286560=:26786--


From xen-devel-bounces@lists.xen.org Tue Apr 24 17:04:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:04:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj9i-0008Vo-67; Tue, 24 Apr 2012 17:03:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMj9h-0008Vj-6a
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:03:57 +0000
Received: from [85.158.143.35:18310] by server-1.bemta-4.messagelabs.com id
	FD/17-20925-CFCD69F4; Tue, 24 Apr 2012 17:03:56 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335287033!13529295!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6970 invoked from network); 24 Apr 2012 17:03:55 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:03:55 -0000
Received: by pbcwz12 with SMTP id wz12so368511pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 10:03:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=eStvnWi+JDQeDR7PiEWAFnElka03JHqxLXYQjOINvzI=;
	b=OCWs4QRVwiIEvBDDE9hUB06rjtqjBqBLfYm89/OhySJ6Wu5YHS3JUQglRJPNxfQ27q
	JL4SRQdN0B/i/lwqM0lUrbmyb9VenHbGoJ8XnPgrg0SKkCozKGTDveOW8Z6VPHJgDQsJ
	zw5vFOkqzqfs7bplmuqHuERzPxdAyn2f8qYTs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=eStvnWi+JDQeDR7PiEWAFnElka03JHqxLXYQjOINvzI=;
	b=XITKEjwSr/1YrEPSdL/gJhvI9XDlXW1AjahECv/DctwLSyl6ZZN1WFn8ZcSU0G1gNB
	O3GcV0jlQRJCZLNhDjJlLjiJUBH/AypDqBKVjlf5WFKSVljW2zkIn9fMxrroERLYBOEO
	2Ykmlx/ne9fitBZE9teB8gybM/Q+9HyzBMYqpuiOVwvugf4v8t7Tft8K0IXxzHG1XRW4
	Y8/XbrY7P2Pm0YEvBDoO/VxwSO6p66BIjiZNu+w29zveN5dYRjvuQ2Krv0l1LLRCUfDW
	TONwy4T7cZp+TExFQqRR5TXirIy3dTc3YroEYduN8I8At7JvLxpB4HH91wHurccg5A9G
	3Vzg==
Received: by 10.68.130.40 with SMTP id ob8mr5272922pbb.84.1335287033246;
	Tue, 24 Apr 2012 10:03:53 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id q5sm17876774pbp.28.2012.04.24.10.03.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Apr 2012 10:03:52 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: d18da69e1f58d17676a04b6e4e0004204a467403
Message-Id: <d18da69e1f58d17676a0.1335287006@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 24 Apr 2012 10:03:26 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQn0F67dfqOzZ5p4cUYgC7Zwz22c/e0KNNJsv2b+GzUvPiK+PREdN/bw7kOe5ZP7/RYOLExH
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] [resend] xen-access: Check return values and
 clean up on errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check the return values of the libxc mem_access calls.
Free allocated structures (platform_info, domain_info) on errors during initialization and exit.
Unbind VIRQ, close event channel and connection to Xen on errors during initialization

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r ea47068fa7a2 -r d18da69e1f58 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c	Mon Apr 23 22:32:48 2012 -0700
+++ b/tools/tests/xen-access/xen-access.c	Tue Apr 24 10:01:59 2012 -0700
@@ -29,6 +29,7 @@
 #include <inttypes.h>
 #include <stdlib.h>
 #include <stdarg.h>
+#include <stdbool.h>
 #include <time.h>
 #include <signal.h>
 #include <unistd.h>
@@ -120,6 +121,7 @@ typedef struct xenaccess {
 } xenaccess_t;
 
 static int interrupted;
+bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;
 
 static void close_handler(int sig)
 {
@@ -167,9 +169,68 @@ int xc_wait_for_event_or_timeout(xc_inte
     return -errno;
 }
 
+int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
+{
+    int rc;
+
+    if ( xenaccess == NULL )
+        return 0;
+
+    /* Tear down domain xenaccess in Xen */
+    if ( xenaccess->mem_event.ring_page )
+        munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
+
+    if ( mem_access_enable )
+    {
+        rc = xc_mem_access_disable(xenaccess->xc_handle,
+                                   xenaccess->mem_event.domain_id);
+        if ( rc != 0 )
+        {
+            ERROR("Error tearing down domain xenaccess in xen");
+        }
+    }
+
+    /* Unbind VIRQ */
+    if ( evtchn_bind )
+    {
+        rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
+                              xenaccess->mem_event.port);
+        if ( rc != 0 )
+        {
+            ERROR("Error unbinding event port");
+        }
+    }
+
+    /* Close event channel */
+    if ( evtchn_open )
+    {
+        rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
+        if ( rc != 0 )
+        {
+            ERROR("Error closing event channel");
+        }
+    }
+
+    /* Close connection to Xen */
+    rc = xc_interface_close(xenaccess->xc_handle);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing connection to xen");
+    }
+    xenaccess->xc_handle = NULL;
+
+    if ( xenaccess->platform_info )
+        free(xenaccess->platform_info);
+    if ( xenaccess->domain_info )
+        free(xenaccess->domain_info);
+    free(xenaccess);
+
+    return 0;
+}
+
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
-    xenaccess_t *xenaccess;
+    xenaccess_t *xenaccess = 0;
     xc_interface *xch;
     int rc;
     unsigned long ring_pfn, mmap_pfn;
@@ -242,6 +303,7 @@ xenaccess_t *xenaccess_init(xc_interface
         }
         goto err;
     }
+    mem_access_enable = 1;
 
     /* Open event channel */
     xenaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
@@ -250,6 +312,7 @@ xenaccess_t *xenaccess_init(xc_interface
         ERROR("Failed to open event channel");
         goto err;
     }
+    evtchn_open = 1;
 
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
@@ -260,7 +323,7 @@ xenaccess_t *xenaccess_init(xc_interface
         ERROR("Failed to bind event channel");
         goto err;
     }
-
+    evtchn_bind = 1;
     xenaccess->mem_event.port = rc;
 
     /* Initialise ring */
@@ -314,64 +377,12 @@ xenaccess_t *xenaccess_init(xc_interface
     return xenaccess;
 
  err:
-    if ( xenaccess )
-    {
-        if ( xenaccess->mem_event.ring_page )
-        {
-            munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-        }
-
-        free(xenaccess->platform_info);
-        free(xenaccess->domain_info);
-        free(xenaccess);
-    }
+    xenaccess_teardown(xch, xenaccess);
 
  err_iface:
     return NULL;
 }
 
-int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
-{
-    int rc;
-
-    if ( xenaccess == NULL )
-        return 0;
-
-    /* Tear down domain xenaccess in Xen */
-    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-    rc = xc_mem_access_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id);
-    if ( rc != 0 )
-    {
-        ERROR("Error tearing down domain xenaccess in xen");
-    }
-
-    /* Unbind VIRQ */
-    rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle, xenaccess->mem_event.port);
-    if ( rc != 0 )
-    {
-        ERROR("Error unbinding event port");
-    }
-    xenaccess->mem_event.port = -1;
-
-    /* Close event channel */
-    rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing event channel");
-    }
-    xenaccess->mem_event.xce_handle = NULL;
-
-    /* Close connection to Xen */
-    rc = xc_interface_close(xenaccess->xc_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing connection to xen");
-    }
-    xenaccess->xc_handle = NULL;
-
-    return 0;
-}
-
 int get_request(mem_event_t *mem_event, mem_event_request_t *req)
 {
     mem_event_back_ring_t *back_ring;
@@ -530,16 +541,39 @@ int main(int argc, char *argv[])
     sigaction(SIGALRM, &act, NULL);
 
     /* Set whether the access listener is required */
-    xc_domain_set_access_required(xch, domain_id, required);
+    rc = xc_domain_set_access_required(xch, domain_id, required);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting mem_access listener required\n", rc);
+        goto exit;
+    }
 
     /* Set the default access type and convert all pages to it */
     rc = xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0);
-    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0, xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting default mem access type\n", rc);
+        goto exit;
+    }
+
+    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0,
+                               xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting all memory to access type %d\n", rc,
+              default_access);
+        goto exit;
+    }
 
     if ( int3 )
         rc = xc_set_hvm_param(xch, domain_id, HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_sync);
     else
         rc = xc_set_hvm_param(xch, domain_id, HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_disabled);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting int3 mem_event\n", rc);
+        goto exit;
+    }
 
     /* Wait for access */
     for (;;)
@@ -587,6 +621,12 @@ int main(int argc, char *argv[])
             switch (req.reason) {
             case MEM_EVENT_REASON_VIOLATION:
                 rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
+                if (rc < 0)
+                {
+                    ERROR("Error %d getting mem_access event\n", rc);
+                    interrupted = -1;
+                    continue;
+                }
 
                 printf("PAGE ACCESS: %c%c%c for GFN %"PRIx64" (offset %06"
                        PRIx64") gla %016"PRIx64" (vcpu %d)\n",
@@ -599,7 +639,17 @@ int main(int argc, char *argv[])
                        req.vcpu_id);
 
                 if ( default_access != after_first_access )
-                    rc = xc_hvm_set_mem_access(xch, domain_id, after_first_access, req.gfn, 1);
+                {
+                    rc = xc_hvm_set_mem_access(xch, domain_id,
+                                               after_first_access, req.gfn, 1);
+                    if (rc < 0)
+                    {
+                        ERROR("Error %d setting gfn to access_type %d\n", rc,
+                              after_first_access);
+                        interrupted = -1;
+                        continue;
+                    }
+                }
 
 
                 rsp.gfn = req.gfn;
@@ -613,6 +663,12 @@ int main(int argc, char *argv[])
 
                 /* Reinject */
                 rc = xc_hvm_inject_trap(xch, domain_id, req.vcpu_id, 3, -1, 0);
+                if (rc < 0)
+                {
+                    ERROR("Error %d injecting int3\n", rc);
+                    interrupted = -1;
+                    continue;
+                }
 
                 break;
             default:
@@ -633,6 +689,7 @@ int main(int argc, char *argv[])
     }
     DPRINTF("xenaccess shut down on signal %d\n", interrupted);
 
+exit:
     /* Tear down domain xenaccess */
     rc1 = xenaccess_teardown(xch, xenaccess);
     if ( rc1 != 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:04:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:04:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj9i-0008Vo-67; Tue, 24 Apr 2012 17:03:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMj9h-0008Vj-6a
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:03:57 +0000
Received: from [85.158.143.35:18310] by server-1.bemta-4.messagelabs.com id
	FD/17-20925-CFCD69F4; Tue, 24 Apr 2012 17:03:56 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335287033!13529295!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6970 invoked from network); 24 Apr 2012 17:03:55 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:03:55 -0000
Received: by pbcwz12 with SMTP id wz12so368511pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 10:03:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=eStvnWi+JDQeDR7PiEWAFnElka03JHqxLXYQjOINvzI=;
	b=OCWs4QRVwiIEvBDDE9hUB06rjtqjBqBLfYm89/OhySJ6Wu5YHS3JUQglRJPNxfQ27q
	JL4SRQdN0B/i/lwqM0lUrbmyb9VenHbGoJ8XnPgrg0SKkCozKGTDveOW8Z6VPHJgDQsJ
	zw5vFOkqzqfs7bplmuqHuERzPxdAyn2f8qYTs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=eStvnWi+JDQeDR7PiEWAFnElka03JHqxLXYQjOINvzI=;
	b=XITKEjwSr/1YrEPSdL/gJhvI9XDlXW1AjahECv/DctwLSyl6ZZN1WFn8ZcSU0G1gNB
	O3GcV0jlQRJCZLNhDjJlLjiJUBH/AypDqBKVjlf5WFKSVljW2zkIn9fMxrroERLYBOEO
	2Ykmlx/ne9fitBZE9teB8gybM/Q+9HyzBMYqpuiOVwvugf4v8t7Tft8K0IXxzHG1XRW4
	Y8/XbrY7P2Pm0YEvBDoO/VxwSO6p66BIjiZNu+w29zveN5dYRjvuQ2Krv0l1LLRCUfDW
	TONwy4T7cZp+TExFQqRR5TXirIy3dTc3YroEYduN8I8At7JvLxpB4HH91wHurccg5A9G
	3Vzg==
Received: by 10.68.130.40 with SMTP id ob8mr5272922pbb.84.1335287033246;
	Tue, 24 Apr 2012 10:03:53 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id q5sm17876774pbp.28.2012.04.24.10.03.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Apr 2012 10:03:52 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: d18da69e1f58d17676a04b6e4e0004204a467403
Message-Id: <d18da69e1f58d17676a0.1335287006@vollum>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 24 Apr 2012 10:03:26 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQn0F67dfqOzZ5p4cUYgC7Zwz22c/e0KNNJsv2b+GzUvPiK+PREdN/bw7kOe5ZP7/RYOLExH
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] [resend] xen-access: Check return values and
 clean up on errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check the return values of the libxc mem_access calls.
Free allocated structures (platform_info, domain_info) on errors during initialization and exit.
Unbind VIRQ, close event channel and connection to Xen on errors during initialization

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r ea47068fa7a2 -r d18da69e1f58 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c	Mon Apr 23 22:32:48 2012 -0700
+++ b/tools/tests/xen-access/xen-access.c	Tue Apr 24 10:01:59 2012 -0700
@@ -29,6 +29,7 @@
 #include <inttypes.h>
 #include <stdlib.h>
 #include <stdarg.h>
+#include <stdbool.h>
 #include <time.h>
 #include <signal.h>
 #include <unistd.h>
@@ -120,6 +121,7 @@ typedef struct xenaccess {
 } xenaccess_t;
 
 static int interrupted;
+bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;
 
 static void close_handler(int sig)
 {
@@ -167,9 +169,68 @@ int xc_wait_for_event_or_timeout(xc_inte
     return -errno;
 }
 
+int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
+{
+    int rc;
+
+    if ( xenaccess == NULL )
+        return 0;
+
+    /* Tear down domain xenaccess in Xen */
+    if ( xenaccess->mem_event.ring_page )
+        munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
+
+    if ( mem_access_enable )
+    {
+        rc = xc_mem_access_disable(xenaccess->xc_handle,
+                                   xenaccess->mem_event.domain_id);
+        if ( rc != 0 )
+        {
+            ERROR("Error tearing down domain xenaccess in xen");
+        }
+    }
+
+    /* Unbind VIRQ */
+    if ( evtchn_bind )
+    {
+        rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle,
+                              xenaccess->mem_event.port);
+        if ( rc != 0 )
+        {
+            ERROR("Error unbinding event port");
+        }
+    }
+
+    /* Close event channel */
+    if ( evtchn_open )
+    {
+        rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
+        if ( rc != 0 )
+        {
+            ERROR("Error closing event channel");
+        }
+    }
+
+    /* Close connection to Xen */
+    rc = xc_interface_close(xenaccess->xc_handle);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing connection to xen");
+    }
+    xenaccess->xc_handle = NULL;
+
+    if ( xenaccess->platform_info )
+        free(xenaccess->platform_info);
+    if ( xenaccess->domain_info )
+        free(xenaccess->domain_info);
+    free(xenaccess);
+
+    return 0;
+}
+
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
-    xenaccess_t *xenaccess;
+    xenaccess_t *xenaccess = 0;
     xc_interface *xch;
     int rc;
     unsigned long ring_pfn, mmap_pfn;
@@ -242,6 +303,7 @@ xenaccess_t *xenaccess_init(xc_interface
         }
         goto err;
     }
+    mem_access_enable = 1;
 
     /* Open event channel */
     xenaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
@@ -250,6 +312,7 @@ xenaccess_t *xenaccess_init(xc_interface
         ERROR("Failed to open event channel");
         goto err;
     }
+    evtchn_open = 1;
 
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
@@ -260,7 +323,7 @@ xenaccess_t *xenaccess_init(xc_interface
         ERROR("Failed to bind event channel");
         goto err;
     }
-
+    evtchn_bind = 1;
     xenaccess->mem_event.port = rc;
 
     /* Initialise ring */
@@ -314,64 +377,12 @@ xenaccess_t *xenaccess_init(xc_interface
     return xenaccess;
 
  err:
-    if ( xenaccess )
-    {
-        if ( xenaccess->mem_event.ring_page )
-        {
-            munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-        }
-
-        free(xenaccess->platform_info);
-        free(xenaccess->domain_info);
-        free(xenaccess);
-    }
+    xenaccess_teardown(xch, xenaccess);
 
  err_iface:
     return NULL;
 }
 
-int xenaccess_teardown(xc_interface *xch, xenaccess_t *xenaccess)
-{
-    int rc;
-
-    if ( xenaccess == NULL )
-        return 0;
-
-    /* Tear down domain xenaccess in Xen */
-    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
-    rc = xc_mem_access_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id);
-    if ( rc != 0 )
-    {
-        ERROR("Error tearing down domain xenaccess in xen");
-    }
-
-    /* Unbind VIRQ */
-    rc = xc_evtchn_unbind(xenaccess->mem_event.xce_handle, xenaccess->mem_event.port);
-    if ( rc != 0 )
-    {
-        ERROR("Error unbinding event port");
-    }
-    xenaccess->mem_event.port = -1;
-
-    /* Close event channel */
-    rc = xc_evtchn_close(xenaccess->mem_event.xce_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing event channel");
-    }
-    xenaccess->mem_event.xce_handle = NULL;
-
-    /* Close connection to Xen */
-    rc = xc_interface_close(xenaccess->xc_handle);
-    if ( rc != 0 )
-    {
-        ERROR("Error closing connection to xen");
-    }
-    xenaccess->xc_handle = NULL;
-
-    return 0;
-}
-
 int get_request(mem_event_t *mem_event, mem_event_request_t *req)
 {
     mem_event_back_ring_t *back_ring;
@@ -530,16 +541,39 @@ int main(int argc, char *argv[])
     sigaction(SIGALRM, &act, NULL);
 
     /* Set whether the access listener is required */
-    xc_domain_set_access_required(xch, domain_id, required);
+    rc = xc_domain_set_access_required(xch, domain_id, required);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting mem_access listener required\n", rc);
+        goto exit;
+    }
 
     /* Set the default access type and convert all pages to it */
     rc = xc_hvm_set_mem_access(xch, domain_id, default_access, ~0ull, 0);
-    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0, xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting default mem access type\n", rc);
+        goto exit;
+    }
+
+    rc = xc_hvm_set_mem_access(xch, domain_id, default_access, 0,
+                               xenaccess->domain_info->max_pages);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting all memory to access type %d\n", rc,
+              default_access);
+        goto exit;
+    }
 
     if ( int3 )
         rc = xc_set_hvm_param(xch, domain_id, HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_sync);
     else
         rc = xc_set_hvm_param(xch, domain_id, HVM_PARAM_MEMORY_EVENT_INT3, HVMPME_mode_disabled);
+    if ( rc < 0 )
+    {
+        ERROR("Error %d setting int3 mem_event\n", rc);
+        goto exit;
+    }
 
     /* Wait for access */
     for (;;)
@@ -587,6 +621,12 @@ int main(int argc, char *argv[])
             switch (req.reason) {
             case MEM_EVENT_REASON_VIOLATION:
                 rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
+                if (rc < 0)
+                {
+                    ERROR("Error %d getting mem_access event\n", rc);
+                    interrupted = -1;
+                    continue;
+                }
 
                 printf("PAGE ACCESS: %c%c%c for GFN %"PRIx64" (offset %06"
                        PRIx64") gla %016"PRIx64" (vcpu %d)\n",
@@ -599,7 +639,17 @@ int main(int argc, char *argv[])
                        req.vcpu_id);
 
                 if ( default_access != after_first_access )
-                    rc = xc_hvm_set_mem_access(xch, domain_id, after_first_access, req.gfn, 1);
+                {
+                    rc = xc_hvm_set_mem_access(xch, domain_id,
+                                               after_first_access, req.gfn, 1);
+                    if (rc < 0)
+                    {
+                        ERROR("Error %d setting gfn to access_type %d\n", rc,
+                              after_first_access);
+                        interrupted = -1;
+                        continue;
+                    }
+                }
 
 
                 rsp.gfn = req.gfn;
@@ -613,6 +663,12 @@ int main(int argc, char *argv[])
 
                 /* Reinject */
                 rc = xc_hvm_inject_trap(xch, domain_id, req.vcpu_id, 3, -1, 0);
+                if (rc < 0)
+                {
+                    ERROR("Error %d injecting int3\n", rc);
+                    interrupted = -1;
+                    continue;
+                }
 
                 break;
             default:
@@ -633,6 +689,7 @@ int main(int argc, char *argv[])
     }
     DPRINTF("xenaccess shut down on signal %d\n", interrupted);
 
+exit:
     /* Tear down domain xenaccess */
     rc1 = xenaccess_teardown(xch, xenaccess);
     if ( rc1 != 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:04:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:04:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj9w-000052-JS; Tue, 24 Apr 2012 17:04:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMj9v-0008WN-3l
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:04:11 +0000
Received: from [193.109.254.147:44568] by server-12.bemta-14.messagelabs.com
	id 66/10-05898-A0DD69F4; Tue, 24 Apr 2012 17:04:10 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335287049!6075611!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14550 invoked from network); 24 Apr 2012 17:04:09 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 17:04:09 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 857BCD34715;
	Tue, 24 Apr 2012 19:04:09 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id cNd2xriN1kvB; Tue, 24 Apr 2012 19:04:04 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id A2543D341B3;
	Tue, 24 Apr 2012 19:04:04 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Tue, 24 Apr 2012 19:04:03 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201204241904.03726.tobias.geiger@vido.info>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

i'm not sure if i understood the new acpi xen cpufreq driver - here's the 
output when loading  xen_acpi_processor module in linux 3.4:

dom0 dmesg:

[   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
[   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
[   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
[   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
[   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
[   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
[   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14



xl dmesg:

(XEN) Monitor-Mwait will be used to enter C1 state
(XEN) Monitor-Mwait will be used to enter C3 state
(XEN) no cpu_id for acpi_id 8
(XEN) no cpu_id for acpi_id 9
(XEN) no cpu_id for acpi_id 10
(XEN) no cpu_id for acpi_id 11
(XEN) no cpu_id for acpi_id 12
(XEN) no cpu_id for acpi_id 13
(XEN) no cpu_id for acpi_id 14


here the according kernel config:

pc:~# zcat /proc/config.gz | grep FREQ
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=m
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_PM_DEVFREQ is not set

and of course:
CONFIG_XEN_ACPI_PROCESSOR=m

xl info:
nr_cpus                : 8
max_cpu_id             : 15
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2


Greetings and thanks for clarification!
Tobias


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:04:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:04:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMj9w-000052-JS; Tue, 24 Apr 2012 17:04:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMj9v-0008WN-3l
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:04:11 +0000
Received: from [193.109.254.147:44568] by server-12.bemta-14.messagelabs.com
	id 66/10-05898-A0DD69F4; Tue, 24 Apr 2012 17:04:10 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335287049!6075611!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14550 invoked from network); 24 Apr 2012 17:04:09 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 17:04:09 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 857BCD34715;
	Tue, 24 Apr 2012 19:04:09 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id cNd2xriN1kvB; Tue, 24 Apr 2012 19:04:04 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id A2543D341B3;
	Tue, 24 Apr 2012 19:04:04 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xen.org
Date: Tue, 24 Apr 2012 19:04:03 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201204241904.03726.tobias.geiger@vido.info>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

i'm not sure if i understood the new acpi xen cpufreq driver - here's the 
output when loading  xen_acpi_processor module in linux 3.4:

dom0 dmesg:

[   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
[   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
[   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
[   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
[   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
[   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
[   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14



xl dmesg:

(XEN) Monitor-Mwait will be used to enter C1 state
(XEN) Monitor-Mwait will be used to enter C3 state
(XEN) no cpu_id for acpi_id 8
(XEN) no cpu_id for acpi_id 9
(XEN) no cpu_id for acpi_id 10
(XEN) no cpu_id for acpi_id 11
(XEN) no cpu_id for acpi_id 12
(XEN) no cpu_id for acpi_id 13
(XEN) no cpu_id for acpi_id 14


here the according kernel config:

pc:~# zcat /proc/config.gz | grep FREQ
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=m
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_PM_DEVFREQ is not set

and of course:
CONFIG_XEN_ACPI_PROCESSOR=m

xl info:
nr_cpus                : 8
max_cpu_id             : 15
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2


Greetings and thanks for clarification!
Tobias


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:08:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:08:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjDQ-0000IW-7y; Tue, 24 Apr 2012 17:07:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMjDO-0000IJ-IY
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:07:46 +0000
Received: from [193.109.254.147:15440] by server-4.bemta-14.messagelabs.com id
	09/3C-11570-1EDD69F4; Tue, 24 Apr 2012 17:07:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335287264!6122554!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25790 invoked from network); 24 Apr 2012 17:07:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:07:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="24481962"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:07:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:07:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMjDL-0007xT-5H;
	Tue, 24 Apr 2012 18:07:43 +0100
Message-ID: <4F96DDE0.3020708@citrix.com>
Date: Tue, 24 Apr 2012 18:07:44 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
In-Reply-To: <20374.43998.471725.415493@mariner.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from runn=
ing if xend	is running."):
>> On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
>>> Can we somehow limit this to commands that actually change things ?
>>> Having xl as a diagnostic tool even for xend-based systems is useful.
>> Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
>
> Yes, something like that.

Do you mean to add a new "-f" option to each command that performs =

modifications, or modifying the cmd_spec struct to add something like =

"int modifies", and check that before trying to execute the command?

>
>>>> +        if (!access(locks[i], F_OK)&&  !force_execution) {
>>>> +            fprintf(stderr, "xend is running, which prevents xl from =
working "
>>>> +                            "correctly. If you still want to force th=
e "
>>>> +                            "execution of xl please use the -f option=
\n");
>>>> +            exit(2);
>>>> +        }
>>> If access fails with an unexpected error code (EACCES? EIO?) this will
>>> blunder on.
>> It'll fail whether the error code is expected or not, won't it?
>
> I think if access fails with EIO, it will return -1, and the if
> condition will not be satisfied (!-1 =3D 0), so the fprintf and exit
> will not be taken.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:08:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:08:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjDQ-0000IW-7y; Tue, 24 Apr 2012 17:07:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMjDO-0000IJ-IY
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:07:46 +0000
Received: from [193.109.254.147:15440] by server-4.bemta-14.messagelabs.com id
	09/3C-11570-1EDD69F4; Tue, 24 Apr 2012 17:07:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335287264!6122554!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzkwNzc=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25790 invoked from network); 24 Apr 2012 17:07:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:07:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="24481962"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:07:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:07:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMjDL-0007xT-5H;
	Tue, 24 Apr 2012 18:07:43 +0100
Message-ID: <4F96DDE0.3020708@citrix.com>
Date: Tue, 24 Apr 2012 18:07:44 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
In-Reply-To: <20374.43998.471725.415493@mariner.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from runn=
ing if xend	is running."):
>> On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
>>> Can we somehow limit this to commands that actually change things ?
>>> Having xl as a diagnostic tool even for xend-based systems is useful.
>> Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
>
> Yes, something like that.

Do you mean to add a new "-f" option to each command that performs =

modifications, or modifying the cmd_spec struct to add something like =

"int modifies", and check that before trying to execute the command?

>
>>>> +        if (!access(locks[i], F_OK)&&  !force_execution) {
>>>> +            fprintf(stderr, "xend is running, which prevents xl from =
working "
>>>> +                            "correctly. If you still want to force th=
e "
>>>> +                            "execution of xl please use the -f option=
\n");
>>>> +            exit(2);
>>>> +        }
>>> If access fails with an unexpected error code (EACCES? EIO?) this will
>>> blunder on.
>> It'll fail whether the error code is expected or not, won't it?
>
> I think if access fails with EIO, it will return -1, and the if
> condition will not be satisfied (!-1 =3D 0), so the fprintf and exit
> will not be taken.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjGO-0000bJ-Sw; Tue, 24 Apr 2012 17:10:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjGN-0000b8-Ee
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:10:51 +0000
Received: from [85.158.143.99:31343] by server-3.bemta-4.messagelabs.com id
	B6/DE-05853-99ED69F4; Tue, 24 Apr 2012 17:10:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335287449!25100026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15509 invoked from network); 24 Apr 2012 17:10:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:10:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:10:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:10:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjGK-0007AH-Cw; Tue, 24 Apr 2012 17:10:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjGK-0006L5-C6;
	Tue, 24 Apr 2012 18:10:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.56984.362620.464163@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:10:48 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F96DDE0.3020708@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<4F96DDE0.3020708@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from run=
ning if xend	is running."):
> Ian Jackson escribi=F3:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from ru=
nning if xend	is running."):
> >> On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> >>> Can we somehow limit this to commands that actually change things ?
> >>> Having xl as a diagnostic tool even for xend-based systems is useful.
> >> Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
> >
> > Yes, something like that.
> =

> Do you mean to add a new "-f" option to each command that performs =

> modifications, or modifying the cmd_spec struct to add something like =

> "int modifies", and check that before trying to execute the command?

The latter.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjGO-0000bJ-Sw; Tue, 24 Apr 2012 17:10:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjGN-0000b8-Ee
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:10:51 +0000
Received: from [85.158.143.99:31343] by server-3.bemta-4.messagelabs.com id
	B6/DE-05853-99ED69F4; Tue, 24 Apr 2012 17:10:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335287449!25100026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15509 invoked from network); 24 Apr 2012 17:10:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:10:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:10:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:10:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjGK-0007AH-Cw; Tue, 24 Apr 2012 17:10:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjGK-0006L5-C6;
	Tue, 24 Apr 2012 18:10:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.56984.362620.464163@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:10:48 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F96DDE0.3020708@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<4F96DDE0.3020708@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from run=
ning if xend	is running."):
> Ian Jackson escribi=F3:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from ru=
nning if xend	is running."):
> >> On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> >>> Can we somehow limit this to commands that actually change things ?
> >>> Having xl as a diagnostic tool even for xend-based systems is useful.
> >> Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
> >
> > Yes, something like that.
> =

> Do you mean to add a new "-f" option to each command that performs =

> modifications, or modifying the cmd_spec struct to add something like =

> "int modifies", and check that before trying to execute the command?

The latter.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:16:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjM3-0000mJ-MF; Tue, 24 Apr 2012 17:16:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjM2-0000mE-Ky
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:16:42 +0000
Received: from [85.158.143.35:22964] by server-1.bemta-4.messagelabs.com id
	49/D1-20925-9FFD69F4; Tue, 24 Apr 2012 17:16:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335287800!14441386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18569 invoked from network); 24 Apr 2012 17:16:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:16:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:16:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:16:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjLz-0007CZ-SK; Tue, 24 Apr 2012 17:16:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjLz-0006Me-RM;
	Tue, 24 Apr 2012 18:16:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.57335.827446.368581@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:16:39 +0100
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F88373C.6050007@amd.com>
References: <4F88373C.6050007@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error w/o MEMSHR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] fix build error w/o MEMSHR"):
> 
> Do not include memshr.h when MEMSHR is not defined.
> Fixes build error when MEMSHR is disabled.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:16:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjM3-0000mJ-MF; Tue, 24 Apr 2012 17:16:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjM2-0000mE-Ky
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:16:42 +0000
Received: from [85.158.143.35:22964] by server-1.bemta-4.messagelabs.com id
	49/D1-20925-9FFD69F4; Tue, 24 Apr 2012 17:16:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335287800!14441386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18569 invoked from network); 24 Apr 2012 17:16:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:16:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:16:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:16:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjLz-0007CZ-SK; Tue, 24 Apr 2012 17:16:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjLz-0006Me-RM;
	Tue, 24 Apr 2012 18:16:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.57335.827446.368581@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:16:39 +0100
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F88373C.6050007@amd.com>
References: <4F88373C.6050007@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error w/o MEMSHR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] fix build error w/o MEMSHR"):
> 
> Do not include memshr.h when MEMSHR is not defined.
> Fixes build error when MEMSHR is disabled.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:18:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjNM-0000qH-IK; Tue, 24 Apr 2012 17:18:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjNK-0000q8-Le
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:18:02 +0000
Received: from [85.158.138.51:27797] by server-4.bemta-3.messagelabs.com id
	36/F4-15341-940E69F4; Tue, 24 Apr 2012 17:18:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335287881!23641979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28048 invoked from network); 24 Apr 2012 17:18:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:18:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:18:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjNI-0007DE-Og; Tue, 24 Apr 2012 17:18:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjNI-0006Nl-NG;
	Tue, 24 Apr 2012 18:18:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.57416.706329.634540@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:18:00 +0100
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
In-Reply-To: <d18da69e1f58d17676a0.1335287006@vollum>
References: <d18da69e1f58d17676a0.1335287006@vollum>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [resend] xen-access: Check return values
 and clean up on errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Aravindh Puthiyaparambil writes ("[PATCH] [resend] xen-access: Check return values and clean up on errors during init"):
> Check the return values of the libxc mem_access calls.
> Free allocated structures (platform_info, domain_info) on errors during initialization and exit.
> Unbind VIRQ, close event channel and connection to Xen on errors during initialization
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:18:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjNM-0000qH-IK; Tue, 24 Apr 2012 17:18:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjNK-0000q8-Le
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:18:02 +0000
Received: from [85.158.138.51:27797] by server-4.bemta-3.messagelabs.com id
	36/F4-15341-940E69F4; Tue, 24 Apr 2012 17:18:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335287881!23641979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28048 invoked from network); 24 Apr 2012 17:18:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:18:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:18:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjNI-0007DE-Og; Tue, 24 Apr 2012 17:18:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjNI-0006Nl-NG;
	Tue, 24 Apr 2012 18:18:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.57416.706329.634540@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:18:00 +0100
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
In-Reply-To: <d18da69e1f58d17676a0.1335287006@vollum>
References: <d18da69e1f58d17676a0.1335287006@vollum>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [resend] xen-access: Check return values
 and clean up on errors during init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Aravindh Puthiyaparambil writes ("[PATCH] [resend] xen-access: Check return values and clean up on errors during init"):
> Check the return values of the libxc mem_access calls.
> Free allocated structures (platform_info, domain_info) on errors during initialization and exit.
> Unbind VIRQ, close event channel and connection to Xen on errors during initialization
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:18:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjNt-0000u6-47; Tue, 24 Apr 2012 17:18:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjNs-0000tw-4f
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:18:36 +0000
Received: from [85.158.138.51:53504] by server-9.bemta-3.messagelabs.com id
	D8/30-26691-B60E69F4; Tue, 24 Apr 2012 17:18:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335287914!23562823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26962 invoked from network); 24 Apr 2012 17:18:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:18:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:18:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:18:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjNq-0007DR-F2; Tue, 24 Apr 2012 17:18:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjNq-0006Nx-Dr;
	Tue, 24 Apr 2012 18:18:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.57450.417199.89376@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:18:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F8836C9.9080502@amd.com>
References: <4F8836C9.9080502@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> 
> Pass PYTHON down to seabios, so seabios will
> use same python binary as whole xen tree does.
> Fixes build error on NetBSD.

Ian, does this look sensible to you ?

> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> ----------------------------------------------------------------------
> diff -r ab552da976a3 tools/firmware/Makefile
> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>  	false ; \
>  	fi
>  endif
> -	$(MAKE) subdirs-$@
> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>  
>  
>  .PHONY: install
> 
> ----------------------------------------------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:18:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjNt-0000u6-47; Tue, 24 Apr 2012 17:18:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjNs-0000tw-4f
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:18:36 +0000
Received: from [85.158.138.51:53504] by server-9.bemta-3.messagelabs.com id
	D8/30-26691-B60E69F4; Tue, 24 Apr 2012 17:18:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335287914!23562823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26962 invoked from network); 24 Apr 2012 17:18:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:18:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12113614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:18:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:18:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjNq-0007DR-F2; Tue, 24 Apr 2012 17:18:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjNq-0006Nx-Dr;
	Tue, 24 Apr 2012 18:18:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.57450.417199.89376@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:18:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F8836C9.9080502@amd.com>
References: <4F8836C9.9080502@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> 
> Pass PYTHON down to seabios, so seabios will
> use same python binary as whole xen tree does.
> Fixes build error on NetBSD.

Ian, does this look sensible to you ?

> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> ----------------------------------------------------------------------
> diff -r ab552da976a3 tools/firmware/Makefile
> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>  	false ; \
>  	fi
>  endif
> -	$(MAKE) subdirs-$@
> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>  
>  
>  .PHONY: install
> 
> ----------------------------------------------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:24:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjTZ-0001Dz-UF; Tue, 24 Apr 2012 17:24:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMjTY-0001Du-Ce
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:24:28 +0000
Received: from [193.109.254.147:41330] by server-3.bemta-14.messagelabs.com id
	93/CE-23274-BC1E69F4; Tue, 24 Apr 2012 17:24:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335288266!6124365!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 999 invoked from network); 24 Apr 2012 17:24:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 17:24:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMjTU-000AxE-BX; Tue, 24 Apr 2012 17:24:24 +0000
Date: Tue, 24 Apr 2012 18:24:24 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120424172424.GD34721@ocelot.phlegethon.org>
References: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] nested vmx: fix instruction decode segment
	limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 16:17 +0100 on 24 Apr (1335284232), Jan Beulich wrote:
> - no limit check in 64-bit mode (is not special in any way)
> - limit check is needed in compatibility mode
> - canonical address check should instead be performed in 64-bit mode
> - the last accessed byte must be within limits, not the first byte past
>   the accessed range
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -319,7 +319,7 @@ static int decode_vmx_inst(struct cpu_us
>  {
>      struct vcpu *v = current;
>      union vmx_inst_info info;
> -    struct segment_register seg;
> +    struct segment_register seg, cs;
>      unsigned long base, index, seg_base, disp, offset;
>      int scale, size;
>  
> @@ -342,6 +342,11 @@ static int decode_vmx_inst(struct cpu_us
>          hvm_get_segment_register(v, sreg_to_index[info.fields.segment], &seg);
>          seg_base = seg.base;
>  
> +        if ( hvm_long_mode_enabled(v) )
> +            hvm_get_segment_register(v, x86_seg_cs, &cs);
> +        else
> +            memset(&cs, 0, sizeof(cs));
> +

I found this a bit confusing - maybe you could extract the attr.fields.l
bit into a bool here instead of zeroing the struct and extracting it later?

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:24:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjTZ-0001Dz-UF; Tue, 24 Apr 2012 17:24:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMjTY-0001Du-Ce
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:24:28 +0000
Received: from [193.109.254.147:41330] by server-3.bemta-14.messagelabs.com id
	93/CE-23274-BC1E69F4; Tue, 24 Apr 2012 17:24:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335288266!6124365!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 999 invoked from network); 24 Apr 2012 17:24:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 17:24:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMjTU-000AxE-BX; Tue, 24 Apr 2012 17:24:24 +0000
Date: Tue, 24 Apr 2012 18:24:24 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120424172424.GD34721@ocelot.phlegethon.org>
References: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] nested vmx: fix instruction decode segment
	limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 16:17 +0100 on 24 Apr (1335284232), Jan Beulich wrote:
> - no limit check in 64-bit mode (is not special in any way)
> - limit check is needed in compatibility mode
> - canonical address check should instead be performed in 64-bit mode
> - the last accessed byte must be within limits, not the first byte past
>   the accessed range
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -319,7 +319,7 @@ static int decode_vmx_inst(struct cpu_us
>  {
>      struct vcpu *v = current;
>      union vmx_inst_info info;
> -    struct segment_register seg;
> +    struct segment_register seg, cs;
>      unsigned long base, index, seg_base, disp, offset;
>      int scale, size;
>  
> @@ -342,6 +342,11 @@ static int decode_vmx_inst(struct cpu_us
>          hvm_get_segment_register(v, sreg_to_index[info.fields.segment], &seg);
>          seg_base = seg.base;
>  
> +        if ( hvm_long_mode_enabled(v) )
> +            hvm_get_segment_register(v, x86_seg_cs, &cs);
> +        else
> +            memset(&cs, 0, sizeof(cs));
> +

I found this a bit confusing - maybe you could extract the attr.fields.l
bit into a bool here instead of zeroing the struct and extracting it later?

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:34:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjcd-0001Y2-Ok; Tue, 24 Apr 2012 17:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMjcc-0001Xr-2i
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:33:50 +0000
Received: from [85.158.138.51:16038] by server-2.bemta-3.messagelabs.com id
	A9/04-09269-DF3E69F4; Tue, 24 Apr 2012 17:33:49 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335288827!23564406!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2141 invoked from network); 24 Apr 2012 17:33:48 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:33:48 -0000
Received: by lboi15 with SMTP id i15so849262lbo.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 10:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ukPV4pOmlEczKBFlj7xrKNUdQw1VzBljAq17y3J/qCo=;
	b=CNJuUSMhjRszH405V7N3cBPh8pt4vdhYeLPQU+KrQs5wei5UDuzCK9n9SVwDeZMZ5X
	u+1hylS3opws139qc6u7D1zZPnrZGvwjKx9nuHPJ6LRkBU+QQ7+Ju4mTivKLtloeD90L
	gWyDk9QpzT+r3RySUaVof++mQsz6gD4nF7RKQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=ukPV4pOmlEczKBFlj7xrKNUdQw1VzBljAq17y3J/qCo=;
	b=G3sRvelAJ4AMyHtm8gHMcYKGZ7B+HvT3i0eAFolOD/aELVGiDDR6tO0n2h8h1US292
	gIGdwy2mw7KYbhRbZ3RXii7/7LfBPjTdSEKD4HsaRc2xrYpQvWFbCPEYJEj/8agpFIlF
	S68ghJ3W4Cj7juy43nwTo61xl2fFQjWDBjV/Rf44b4Er+1kY7vtzTh4F1MC5QYuQPu+i
	UtAeISRvmyzi/phKUbqoksux/n2LzQlJsRd19F/Wyxho77oXpS78qyA6ts53sTfEzLEf
	jsFkZmVReDIwMspPDvba2IIO4bYlGU3yQelxSymSgEmVVv4yP4A99AhOpMr3YvkegN6E
	Cq5w==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr19840391lab.29.1335288827319;
	Tue, 24 Apr 2012 10:33:47 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 10:33:47 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <4F9677E9020000780007F840@nat28.tlf.novell.com>
References: <f7a1633867bfeb30f83d.1335222981@vollum>
	<4F9677E9020000780007F840@nat28.tlf.novell.com>
Date: Tue, 24 Apr 2012 10:33:47 -0700
Message-ID: <CAB10MZDmn4oKDmR_uCzsAWbakh-SgMGUvFk9L0zWKTWd03tSSw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQkvysR9GjbpC+zidz6vv34MpsKxy/NYg4ZmKp19WjUwADeFL12f+1x/oZS+DCmzzKVy+vzM
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 24.04.12 at 01:16, Aravindh Puthiyaparambil <aravindh@virtuata.com>=
 wrote:
>> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontex=
t()
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>
>> diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c =A0 Mon Apr 23 15:16:34 2012 -0700
>> +++ b/xen/arch/x86/domctl.c =A0 Mon Apr 23 16:12:50 2012 -0700
>> @@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>> +#endif
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>> + =A0 =A0 =A0 =A0else
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>> +#endif
>
> Which still leaves one of gs_base_* unfilled in all cases. You'll need
> to get ahold of vmcb->kerngsbase (AMD/SVM) or
> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
> as a new function table entry, or pay the price of calling
> ->save_cpu_ctxt(). But you will need to pay extra attention to
> the case of the subject vCPU being current.

OK, I will try introducing a new wrapper that will return
vmcb->kerngsbase /  v->arch.hvm_vmx.shadow_gs.

Thanks,
Aravindh

>> =A0 =A0 =A0}
>> =A0 =A0 =A0else
>> =A0 =A0 =A0{
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:34:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjcd-0001Y2-Ok; Tue, 24 Apr 2012 17:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMjcc-0001Xr-2i
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:33:50 +0000
Received: from [85.158.138.51:16038] by server-2.bemta-3.messagelabs.com id
	A9/04-09269-DF3E69F4; Tue, 24 Apr 2012 17:33:49 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335288827!23564406!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2141 invoked from network); 24 Apr 2012 17:33:48 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:33:48 -0000
Received: by lboi15 with SMTP id i15so849262lbo.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 10:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ukPV4pOmlEczKBFlj7xrKNUdQw1VzBljAq17y3J/qCo=;
	b=CNJuUSMhjRszH405V7N3cBPh8pt4vdhYeLPQU+KrQs5wei5UDuzCK9n9SVwDeZMZ5X
	u+1hylS3opws139qc6u7D1zZPnrZGvwjKx9nuHPJ6LRkBU+QQ7+Ju4mTivKLtloeD90L
	gWyDk9QpzT+r3RySUaVof++mQsz6gD4nF7RKQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=ukPV4pOmlEczKBFlj7xrKNUdQw1VzBljAq17y3J/qCo=;
	b=G3sRvelAJ4AMyHtm8gHMcYKGZ7B+HvT3i0eAFolOD/aELVGiDDR6tO0n2h8h1US292
	gIGdwy2mw7KYbhRbZ3RXii7/7LfBPjTdSEKD4HsaRc2xrYpQvWFbCPEYJEj/8agpFIlF
	S68ghJ3W4Cj7juy43nwTo61xl2fFQjWDBjV/Rf44b4Er+1kY7vtzTh4F1MC5QYuQPu+i
	UtAeISRvmyzi/phKUbqoksux/n2LzQlJsRd19F/Wyxho77oXpS78qyA6ts53sTfEzLEf
	jsFkZmVReDIwMspPDvba2IIO4bYlGU3yQelxSymSgEmVVv4yP4A99AhOpMr3YvkegN6E
	Cq5w==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr19840391lab.29.1335288827319;
	Tue, 24 Apr 2012 10:33:47 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 10:33:47 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <4F9677E9020000780007F840@nat28.tlf.novell.com>
References: <f7a1633867bfeb30f83d.1335222981@vollum>
	<4F9677E9020000780007F840@nat28.tlf.novell.com>
Date: Tue, 24 Apr 2012 10:33:47 -0700
Message-ID: <CAB10MZDmn4oKDmR_uCzsAWbakh-SgMGUvFk9L0zWKTWd03tSSw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQkvysR9GjbpC+zidz6vv34MpsKxy/NYg4ZmKp19WjUwADeFL12f+1x/oZS+DCmzzKVy+vzM
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 24.04.12 at 01:16, Aravindh Puthiyaparambil <aravindh@virtuata.com>=
 wrote:
>> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontex=
t()
>>
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>
>> diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c =A0 Mon Apr 23 15:16:34 2012 -0700
>> +++ b/xen/arch/x86/domctl.c =A0 Mon Apr 23 16:12:50 2012 -0700
>> @@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>> +#endif
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>> + =A0 =A0 =A0 =A0else
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>> +#endif
>
> Which still leaves one of gs_base_* unfilled in all cases. You'll need
> to get ahold of vmcb->kerngsbase (AMD/SVM) or
> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
> as a new function table entry, or pay the price of calling
> ->save_cpu_ctxt(). But you will need to pay extra attention to
> the case of the subject vCPU being current.

OK, I will try introducing a new wrapper that will return
vmcb->kerngsbase /  v->arch.hvm_vmx.shadow_gs.

Thanks,
Aravindh

>> =A0 =A0 =A0}
>> =A0 =A0 =A0else
>> =A0 =A0 =A0{
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:35:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjdd-0001cS-7M; Tue, 24 Apr 2012 17:34:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMjdb-0001cE-DW
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:34:51 +0000
Received: from [85.158.138.51:50896] by server-7.bemta-3.messagelabs.com id
	78/51-03078-A34E69F4; Tue, 24 Apr 2012 17:34:50 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335288887!23463935!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21594 invoked from network); 24 Apr 2012 17:34:49 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 17:34:49 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 7E4DD102106B5;
	Tue, 24 Apr 2012 10:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Uu8MwTstGeBH; Tue, 24 Apr 2012 10:34:45 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 5C0CB102106B3;
	Tue, 24 Apr 2012 10:34:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 10:34:44 -0700
Message-Id: <009D2723-CC93-4AD1-9399-9EDBC288F883@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8139716831691071089=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8139716831691071089==
Content-Type: multipart/alternative; boundary="Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C"


--Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Apr 24, 2012, at 10:03 AM, Stefano Stabellini wrote:

> Is the file you are trying to open on NFS by any chance?

No, it's an XFS filesystem on an LVM partition.

> My guess is that the file open is failing, maybe because of an opening =
flag.
> We need to add some tracing to xen_disk.c in qemu to find out.
> Could you please apply the appended patch to the qemu tree and then =
post
> the qemu log file again?

The patch didn't take=85 I can make the changes by hand, but I want to =
make sure I'm using the right things.   So far I'm using the 4.1.2 =
tarball.  Is there a different tree I should be using?

-Sam


--Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 10:03 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Is the file =
you are trying to open on NFS by any =
chance?<br></span></blockquote><div><br></div><div>No, it's an XFS =
filesystem on an LVM partition.</div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">My guess is =
that the file open is failing, maybe because of an opening flag.<br>We =
need to add some tracing to xen_disk.c in qemu to find out.<br>Could you =
please apply the appended patch to the qemu tree and then post<br>the =
qemu log file again?<br></span></blockquote><br></div><div>The patch =
didn't take=85 I can make the changes by hand, but I want to make sure =
I'm using the right things. &nbsp; So far I'm using the 4.1.2 tarball. =
&nbsp;Is there a different tree I should be =
using?</div><div><br></div><div>-Sam</div><br></body></html>=

--Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C--


--===============8139716831691071089==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8139716831691071089==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 17:35:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjdd-0001cS-7M; Tue, 24 Apr 2012 17:34:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMjdb-0001cE-DW
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:34:51 +0000
Received: from [85.158.138.51:50896] by server-7.bemta-3.messagelabs.com id
	78/51-03078-A34E69F4; Tue, 24 Apr 2012 17:34:50 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335288887!23463935!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21594 invoked from network); 24 Apr 2012 17:34:49 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 17:34:49 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 7E4DD102106B5;
	Tue, 24 Apr 2012 10:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Uu8MwTstGeBH; Tue, 24 Apr 2012 10:34:45 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 5C0CB102106B3;
	Tue, 24 Apr 2012 10:34:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 10:34:44 -0700
Message-Id: <009D2723-CC93-4AD1-9399-9EDBC288F883@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8139716831691071089=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8139716831691071089==
Content-Type: multipart/alternative; boundary="Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C"


--Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Apr 24, 2012, at 10:03 AM, Stefano Stabellini wrote:

> Is the file you are trying to open on NFS by any chance?

No, it's an XFS filesystem on an LVM partition.

> My guess is that the file open is failing, maybe because of an opening =
flag.
> We need to add some tracing to xen_disk.c in qemu to find out.
> Could you please apply the appended patch to the qemu tree and then =
post
> the qemu log file again?

The patch didn't take=85 I can make the changes by hand, but I want to =
make sure I'm using the right things.   So far I'm using the 4.1.2 =
tarball.  Is there a different tree I should be using?

-Sam


--Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 10:03 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Is the file =
you are trying to open on NFS by any =
chance?<br></span></blockquote><div><br></div><div>No, it's an XFS =
filesystem on an LVM partition.</div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">My guess is =
that the file open is failing, maybe because of an opening flag.<br>We =
need to add some tracing to xen_disk.c in qemu to find out.<br>Could you =
please apply the appended patch to the qemu tree and then post<br>the =
qemu log file again?<br></span></blockquote><br></div><div>The patch =
didn't take=85 I can make the changes by hand, but I want to make sure =
I'm using the right things. &nbsp; So far I'm using the 4.1.2 tarball. =
&nbsp;Is there a different tree I should be =
using?</div><div><br></div><div>-Sam</div><br></body></html>=

--Apple-Mail=_931B7104-EC8E-4AAA-B3A7-90D446AAAD8C--


--===============8139716831691071089==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8139716831691071089==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 17:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjhD-0001r3-TB; Tue, 24 Apr 2012 17:38:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjhC-0001qw-Ec
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:38:34 +0000
Received: from [85.158.143.99:28196] by server-3.bemta-4.messagelabs.com id
	2F/85-05853-915E69F4; Tue, 24 Apr 2012 17:38:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335289112!25103092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26669 invoked from network); 24 Apr 2012 17:38:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:38:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:38:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:38:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjhA-0007KA-4e; Tue, 24 Apr 2012 17:38:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjhA-0001IX-2A;
	Tue, 24 Apr 2012 18:38:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58648.17367.532619@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:38:32 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1204111636260.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
	<20345.55876.979344.17338@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204111636260.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance
 improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> On Mon, 2 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> > > Hi all,
> > > this small patch series enables the O_DIRECT flag to open disk images
> > > for both the IDE and xen_disk interface.
> > > Also it includes few fixes for xen_disk.
> > > 
> > > Stefano Stabellini (3):
> > >       qemu-xen-traditional: use O_DIRECT to open disk images for IDE
> > >       qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
> > >       qemu-xen-traditional: QDISK fixes
> > 
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> 
> Could you please backport these patches to qemu-xen-4.1-testing?

Done.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjhD-0001r3-TB; Tue, 24 Apr 2012 17:38:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjhC-0001qw-Ec
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:38:34 +0000
Received: from [85.158.143.99:28196] by server-3.bemta-4.messagelabs.com id
	2F/85-05853-915E69F4; Tue, 24 Apr 2012 17:38:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335289112!25103092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26669 invoked from network); 24 Apr 2012 17:38:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:38:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:38:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:38:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjhA-0007KA-4e; Tue, 24 Apr 2012 17:38:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjhA-0001IX-2A;
	Tue, 24 Apr 2012 18:38:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58648.17367.532619@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:38:32 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1204111636260.15151@kaball-desktop>
References: <alpine.DEB.2.00.1203231445220.15151@kaball-desktop>
	<20345.55876.979344.17338@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1204111636260.15151@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance
 improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> On Mon, 2 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] qemu-xen-traditional: disk performance improvements"):
> > > Hi all,
> > > this small patch series enables the O_DIRECT flag to open disk images
> > > for both the IDE and xen_disk interface.
> > > Also it includes few fixes for xen_disk.
> > > 
> > > Stefano Stabellini (3):
> > >       qemu-xen-traditional: use O_DIRECT to open disk images for IDE
> > >       qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
> > >       qemu-xen-traditional: QDISK fixes
> > 
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> 
> Could you please backport these patches to qemu-xen-4.1-testing?

Done.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:40:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjig-00020q-CT; Tue, 24 Apr 2012 17:40:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjie-0001zs-RI
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:40:04 +0000
Received: from [85.158.139.83:39977] by server-12.bemta-5.messagelabs.com id
	B9/D3-05587-375E69F4; Tue, 24 Apr 2012 17:40:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335289202!25342678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9105 invoked from network); 24 Apr 2012 17:40:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:40:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:39:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:39:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMji2-0007KR-Ac; Tue, 24 Apr 2012 17:39:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMji2-0001Jh-9m;
	Tue, 24 Apr 2012 18:39:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58702.288208.310108@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:39:26 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120330140640.GA90203@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> tools: Fix FPU save area definition in xen-hvmctx
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Tim Deegan <tim@xen.org>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:40:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjig-00020q-CT; Tue, 24 Apr 2012 17:40:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjie-0001zs-RI
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:40:04 +0000
Received: from [85.158.139.83:39977] by server-12.bemta-5.messagelabs.com id
	B9/D3-05587-375E69F4; Tue, 24 Apr 2012 17:40:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335289202!25342678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9105 invoked from network); 24 Apr 2012 17:40:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:40:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:39:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:39:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMji2-0007KR-Ac; Tue, 24 Apr 2012 17:39:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMji2-0001Jh-9m;
	Tue, 24 Apr 2012 18:39:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58702.288208.310108@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:39:26 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120330140640.GA90203@ocelot.phlegethon.org>
References: <769fb4057e369d7e102b.1333115107@probook.site>
	<20120330140640.GA90203@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] [PATCH] tools/misc: fix array access in xen-hvmctx.c"):
> tools: Fix FPU save area definition in xen-hvmctx
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Tim Deegan <tim@xen.org>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:40:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjj4-00025W-Qg; Tue, 24 Apr 2012 17:40:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjj3-00025A-Do
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:40:29 +0000
Received: from [85.158.138.51:48928] by server-4.bemta-3.messagelabs.com id
	49/5D-15341-C85E69F4; Tue, 24 Apr 2012 17:40:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335289227!21790870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9701 invoked from network); 24 Apr 2012 17:40:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:40:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:40:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjj1-0007Km-AX; Tue, 24 Apr 2012 17:40:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjj1-0001QL-90;
	Tue, 24 Apr 2012 18:40:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58763.263611.246716@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:40:27 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
References: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: mark internal functions hidden"):
> libxl: mark internal functions hidden
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:40:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjj4-00025W-Qg; Tue, 24 Apr 2012 17:40:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjj3-00025A-Do
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:40:29 +0000
Received: from [85.158.138.51:48928] by server-4.bemta-3.messagelabs.com id
	49/5D-15341-C85E69F4; Tue, 24 Apr 2012 17:40:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335289227!21790870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9701 invoked from network); 24 Apr 2012 17:40:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:40:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:40:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjj1-0007Km-AX; Tue, 24 Apr 2012 17:40:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjj1-0001QL-90;
	Tue, 24 Apr 2012 18:40:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58763.263611.246716@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:40:27 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
References: <ce1c73db77fb1264de40.1334219414@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: mark internal functions hidden
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: mark internal functions hidden"):
> libxl: mark internal functions hidden
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:40:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjjN-00029H-84; Tue, 24 Apr 2012 17:40:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjjL-000284-Qa
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:40:47 +0000
Received: from [85.158.143.35:44058] by server-2.bemta-4.messagelabs.com id
	DE/53-17550-F95E69F4; Tue, 24 Apr 2012 17:40:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335289245!8572699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26815 invoked from network); 24 Apr 2012 17:40:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:40:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:40:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjjJ-0007Kt-3x; Tue, 24 Apr 2012 17:40:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjjJ-0001QP-2w;
	Tue, 24 Apr 2012 18:40:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58781.78396.485753@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:40:45 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334068916-1486-1-git-send-email-roger.pau@citrix.com>
References: <1334068916-1486-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: remove poller from list
	in	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: remove poller from list in libxl__poller_get"):
> Remove poller from the list once it has been requested. To be merged with Ian
> Jackson series.

This has indeed now been committed as part of my series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:40:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjjN-00029H-84; Tue, 24 Apr 2012 17:40:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjjL-000284-Qa
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:40:47 +0000
Received: from [85.158.143.35:44058] by server-2.bemta-4.messagelabs.com id
	DE/53-17550-F95E69F4; Tue, 24 Apr 2012 17:40:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335289245!8572699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26815 invoked from network); 24 Apr 2012 17:40:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:40:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:40:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjjJ-0007Kt-3x; Tue, 24 Apr 2012 17:40:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjjJ-0001QP-2w;
	Tue, 24 Apr 2012 18:40:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.58781.78396.485753@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:40:45 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334068916-1486-1-git-send-email-roger.pau@citrix.com>
References: <1334068916-1486-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: remove poller from list
	in	libxl__poller_get
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: remove poller from list in libxl__poller_get"):
> Remove poller from the list once it has been requested. To be merged with Ian
> Jackson series.

This has indeed now been committed as part of my series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjjl-0002Fa-QW; Tue, 24 Apr 2012 17:41:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMjjk-0002Eu-4G
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:41:12 +0000
Received: from [85.158.138.51:53283] by server-2.bemta-3.messagelabs.com id
	99/CB-09269-7B5E69F4; Tue, 24 Apr 2012 17:41:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335289269!19528319!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14411 invoked from network); 24 Apr 2012 17:41:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 17:41:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OHf7oT020748
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 17:41:08 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OHf6RY029212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 17:41:07 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OHf6b0032210; Tue, 24 Apr 2012 12:41:06 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 10:41:06 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B8B6D40327; Tue, 24 Apr 2012 13:36:01 -0400 (EDT)
Date: Tue, 24 Apr 2012 13:36:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120424173601.GA27353@phenom.dumpdata.com>
References: <201204241904.03726.tobias.geiger@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204241904.03726.tobias.geiger@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 07:04:03PM +0200, Tobias Geiger wrote:
> Hi,
> 
> i'm not sure if i understood the new acpi xen cpufreq driver - here's the 
> output when loading  xen_acpi_processor module in linux 3.4:
> 
> dom0 dmesg:
> 
> [   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
> [   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
> [   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
> [   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
> [   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
> [   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
> [   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14
> 
> 
> 
> xl dmesg:
> 
> (XEN) Monitor-Mwait will be used to enter C1 state
> (XEN) Monitor-Mwait will be used to enter C3 state
> (XEN) no cpu_id for acpi_id 8
> (XEN) no cpu_id for acpi_id 9
> (XEN) no cpu_id for acpi_id 10
> (XEN) no cpu_id for acpi_id 11
> (XEN) no cpu_id for acpi_id 12
> (XEN) no cpu_id for acpi_id 13
> (XEN) no cpu_id for acpi_id 14
> 
> 
> here the according kernel config:
> 
> pc:~# zcat /proc/config.gz | grep FREQ
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_TABLE=y
> CONFIG_CPU_FREQ_STAT=m
> # CONFIG_CPU_FREQ_STAT_DETAILS is not set
> # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
> CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> CONFIG_CPU_FREQ_GOV_USERSPACE=m
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
> CONFIG_X86_PCC_CPUFREQ=m
> CONFIG_X86_ACPI_CPUFREQ=m
> # CONFIG_PM_DEVFREQ is not set
> 
> and of course:
> CONFIG_XEN_ACPI_PROCESSOR=m
> 
> xl info:
> nr_cpus                : 8
> max_cpu_id             : 15
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 2

Can you include your xl dmesg and dmesg and as well
the /sys/firmware/acpi/tables/DSDT and /sys/firmware/acpi/tables/SSDT*
files please?

Does xenpm work properly?

> 
> 
> Greetings and thanks for clarification!
> Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjjl-0002Fa-QW; Tue, 24 Apr 2012 17:41:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SMjjk-0002Eu-4G
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:41:12 +0000
Received: from [85.158.138.51:53283] by server-2.bemta-3.messagelabs.com id
	99/CB-09269-7B5E69F4; Tue, 24 Apr 2012 17:41:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335289269!19528319!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14411 invoked from network); 24 Apr 2012 17:41:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 17:41:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OHf7oT020748
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 17:41:08 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OHf6RY029212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 17:41:07 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OHf6b0032210; Tue, 24 Apr 2012 12:41:06 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 10:41:06 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B8B6D40327; Tue, 24 Apr 2012 13:36:01 -0400 (EDT)
Date: Tue, 24 Apr 2012 13:36:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120424173601.GA27353@phenom.dumpdata.com>
References: <201204241904.03726.tobias.geiger@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201204241904.03726.tobias.geiger@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 07:04:03PM +0200, Tobias Geiger wrote:
> Hi,
> 
> i'm not sure if i understood the new acpi xen cpufreq driver - here's the 
> output when loading  xen_acpi_processor module in linux 3.4:
> 
> dom0 dmesg:
> 
> [   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
> [   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
> [   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
> [   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
> [   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
> [   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
> [   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14
> 
> 
> 
> xl dmesg:
> 
> (XEN) Monitor-Mwait will be used to enter C1 state
> (XEN) Monitor-Mwait will be used to enter C3 state
> (XEN) no cpu_id for acpi_id 8
> (XEN) no cpu_id for acpi_id 9
> (XEN) no cpu_id for acpi_id 10
> (XEN) no cpu_id for acpi_id 11
> (XEN) no cpu_id for acpi_id 12
> (XEN) no cpu_id for acpi_id 13
> (XEN) no cpu_id for acpi_id 14
> 
> 
> here the according kernel config:
> 
> pc:~# zcat /proc/config.gz | grep FREQ
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_TABLE=y
> CONFIG_CPU_FREQ_STAT=m
> # CONFIG_CPU_FREQ_STAT_DETAILS is not set
> # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
> CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> CONFIG_CPU_FREQ_GOV_USERSPACE=m
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
> CONFIG_X86_PCC_CPUFREQ=m
> CONFIG_X86_ACPI_CPUFREQ=m
> # CONFIG_PM_DEVFREQ is not set
> 
> and of course:
> CONFIG_XEN_ACPI_PROCESSOR=m
> 
> xl info:
> nr_cpus                : 8
> max_cpu_id             : 15
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 2

Can you include your xl dmesg and dmesg and as well
the /sys/firmware/acpi/tables/DSDT and /sys/firmware/acpi/tables/SSDT*
files please?

Does xenpm work properly?

> 
> 
> Greetings and thanks for clarification!
> Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:50:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjsv-00030T-Hz; Tue, 24 Apr 2012 17:50:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjsu-00030J-PG
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:50:40 +0000
Received: from [85.158.143.35:56619] by server-3.bemta-4.messagelabs.com id
	00/3E-05853-0F7E69F4; Tue, 24 Apr 2012 17:50:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335289836!14445026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25238 invoked from network); 24 Apr 2012 17:50:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:50:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:50:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:50:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjsq-0007Pv-5J; Tue, 24 Apr 2012 17:50:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjsp-0007NW-Up;
	Tue, 24 Apr 2012 18:50:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59371.842543.119859@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:50:35 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
References: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] autoconf: use python-config when present,
	if not switch to distutils
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] autoconf: use python-config when present, if not switch to distutils"):
> Use python-config utility when possible, and if it is not present switch to
> distutils.
> 
> Should fix the bug reported by Olaf Hering on SuSE.
> 
> Rerun autoconf after applying the patch.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> Cc: Olaf Hering <olaf@aepfle.de>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:50:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjsv-00030T-Hz; Tue, 24 Apr 2012 17:50:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjsu-00030J-PG
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:50:40 +0000
Received: from [85.158.143.35:56619] by server-3.bemta-4.messagelabs.com id
	00/3E-05853-0F7E69F4; Tue, 24 Apr 2012 17:50:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335289836!14445026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDY0Mg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25238 invoked from network); 24 Apr 2012 17:50:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:50:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:50:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:50:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjsq-0007Pv-5J; Tue, 24 Apr 2012 17:50:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjsp-0007NW-Up;
	Tue, 24 Apr 2012 18:50:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59371.842543.119859@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:50:35 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
References: <1334075928-5045-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] autoconf: use python-config when present,
	if not switch to distutils
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] autoconf: use python-config when present, if not switch to distutils"):
> Use python-config utility when possible, and if it is not present switch to
> distutils.
> 
> Should fix the bug reported by Olaf Hering on SuSE.
> 
> Rerun autoconf after applying the patch.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> Cc: Olaf Hering <olaf@aepfle.de>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:52:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjui-00039v-QD; Tue, 24 Apr 2012 17:52:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjug-00039V-Sq
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:52:31 +0000
Received: from [85.158.138.51:51684] by server-10.bemta-3.messagelabs.com id
	B8/0B-29478-D58E69F4; Tue, 24 Apr 2012 17:52:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335289948!12597206!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21631 invoked from network); 24 Apr 2012 17:52:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:52:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114366"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:52:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:52:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjue-0007Qb-7x; Tue, 24 Apr 2012 17:52:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjue-0007Wv-66;
	Tue, 24 Apr 2012 18:52:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59484.96465.582502@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:52:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334218561.12209.253.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334218561.12209.253.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> libxl: make most libxl_FOO_path() functions internal.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:52:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjui-00039v-QD; Tue, 24 Apr 2012 17:52:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjug-00039V-Sq
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:52:31 +0000
Received: from [85.158.138.51:51684] by server-10.bemta-3.messagelabs.com id
	B8/0B-29478-D58E69F4; Tue, 24 Apr 2012 17:52:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335289948!12597206!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21631 invoked from network); 24 Apr 2012 17:52:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:52:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114366"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:52:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:52:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjue-0007Qb-7x; Tue, 24 Apr 2012 17:52:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjue-0007Wv-66;
	Tue, 24 Apr 2012 18:52:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59484.96465.582502@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:52:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1334218561.12209.253.camel@dagon.hellion.org.uk>
References: <1333362402.25602.36.camel@zakaz.uk.xensource.com>
	<20357.44324.27939.514126@mariner.uk.xensource.com>
	<1334216141.12209.236.camel@dagon.hellion.org.uk>
	<1334218561.12209.253.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 Release Plan / TODO"):
> libxl: make most libxl_FOO_path() functions internal.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:52:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjuq-0003BF-73; Tue, 24 Apr 2012 17:52:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjup-0003Av-Cp
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:52:39 +0000
Received: from [85.158.139.83:35899] by server-1.bemta-5.messagelabs.com id
	0D/B6-28458-668E69F4; Tue, 24 Apr 2012 17:52:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335289957!25302602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18594 invoked from network); 24 Apr 2012 17:52:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:52:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:52:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:52:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjun-0007Qh-FJ; Tue, 24 Apr 2012 17:52:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjun-0007Wz-Da;
	Tue, 24 Apr 2012 18:52:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59493.408279.534518@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:52:37 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c53f124c8c448ea43d75.1333631683@kodo2>
References: <c53f124c8c448ea43d75.1333631683@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl,
	cpupools: Create empty pool if no cpus are specified
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] xl, cpupools: Create empty pool if no cpus are specified"):
> This patch changes the behavior of "xl cpupool-create" to create an empty
> pool if no cpus are specified.  I believe this interface to be more expected
> and more script-friendly.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:52:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjuq-0003BF-73; Tue, 24 Apr 2012 17:52:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjup-0003Av-Cp
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:52:39 +0000
Received: from [85.158.139.83:35899] by server-1.bemta-5.messagelabs.com id
	0D/B6-28458-668E69F4; Tue, 24 Apr 2012 17:52:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335289957!25302602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18594 invoked from network); 24 Apr 2012 17:52:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:52:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:52:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:52:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjun-0007Qh-FJ; Tue, 24 Apr 2012 17:52:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjun-0007Wz-Da;
	Tue, 24 Apr 2012 18:52:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59493.408279.534518@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:52:37 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c53f124c8c448ea43d75.1333631683@kodo2>
References: <c53f124c8c448ea43d75.1333631683@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl,
	cpupools: Create empty pool if no cpus are specified
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] xl, cpupools: Create empty pool if no cpus are specified"):
> This patch changes the behavior of "xl cpupool-create" to create an empty
> pool if no cpus are specified.  I believe this interface to be more expected
> and more script-friendly.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:52:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjuz-0003Da-Kt; Tue, 24 Apr 2012 17:52:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjuy-0003D5-9d
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:52:48 +0000
Received: from [85.158.139.83:36397] by server-4.bemta-5.messagelabs.com id
	ED/10-10788-F68E69F4; Tue, 24 Apr 2012 17:52:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335289966!21036516!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24861 invoked from network); 24 Apr 2012 17:52:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:52:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:52:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:52:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjuw-0007Qk-K6; Tue, 24 Apr 2012 17:52:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjuw-0007X3-J2;
	Tue, 24 Apr 2012 18:52:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59502.576124.642441@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:52:46 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <41ff0907f4a07f1bfa1b.1333634835@kodo2>
References: <41ff0907f4a07f1bfa1b.1333634835@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] [v2] xl: Don't require a config file
	for	cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] [v2] xl: Don't require a config file for cpupools"):
> Since the key information can be fairly simply put on the command-line,
> there's no need to require an actual config file.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:52:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjuz-0003Da-Kt; Tue, 24 Apr 2012 17:52:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjuy-0003D5-9d
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 17:52:48 +0000
Received: from [85.158.139.83:36397] by server-4.bemta-5.messagelabs.com id
	ED/10-10788-F68E69F4; Tue, 24 Apr 2012 17:52:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335289966!21036516!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24861 invoked from network); 24 Apr 2012 17:52:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:52:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:52:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:52:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjuw-0007Qk-K6; Tue, 24 Apr 2012 17:52:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjuw-0007X3-J2;
	Tue, 24 Apr 2012 18:52:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59502.576124.642441@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:52:46 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <41ff0907f4a07f1bfa1b.1333634835@kodo2>
References: <41ff0907f4a07f1bfa1b.1333634835@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] [v2] xl: Don't require a config file
	for	cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] [v2] xl: Don't require a config file for cpupools"):
> Since the key information can be fairly simply put on the command-line,
> there's no need to require an actual config file.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:57:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjzK-0003v7-F7; Tue, 24 Apr 2012 17:57:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjzI-0003us-G4
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:57:16 +0000
Received: from [85.158.143.35:34989] by server-1.bemta-4.messagelabs.com id
	EA/CF-20925-B79E69F4; Tue, 24 Apr 2012 17:57:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335290234!6336280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32555 invoked from network); 24 Apr 2012 17:57:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:57:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:57:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:57:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjzF-0007S4-Q6; Tue, 24 Apr 2012 17:57:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjzF-0007XV-OX;
	Tue, 24 Apr 2012 18:57:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59769.738590.656156@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:57:13 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> RFC: libxl: move definition of libxl_domain_config into the IDL
> 
> This requires adding a new Array type to the IDL.
> 
> DO NOT APPLY. This is 4.3 material.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> +  idl.Array.len_var contains an idl.Field which is added to the parent
> +  idl.Aggregate and will contain the length of the array.

Why does the Array not automatically invent a "num_<foo>" field ?
Surely there is no benefit to having non-systematically named (or
typed) array count fields ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:57:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMjzK-0003v7-F7; Tue, 24 Apr 2012 17:57:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMjzI-0003us-G4
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:57:16 +0000
Received: from [85.158.143.35:34989] by server-1.bemta-4.messagelabs.com id
	EA/CF-20925-B79E69F4; Tue, 24 Apr 2012 17:57:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335290234!6336280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDEzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32555 invoked from network); 24 Apr 2012 17:57:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:57:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:57:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:57:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMjzF-0007S4-Q6; Tue, 24 Apr 2012 17:57:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMjzF-0007XV-OX;
	Tue, 24 Apr 2012 18:57:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59769.738590.656156@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:57:13 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> RFC: libxl: move definition of libxl_domain_config into the IDL
> 
> This requires adding a new Array type to the IDL.
> 
> DO NOT APPLY. This is 4.3 material.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> +  idl.Array.len_var contains an idl.Field which is added to the parent
> +  idl.Aggregate and will contain the length of the array.

Why does the Array not automatically invent a "num_<foo>" field ?
Surely there is no benefit to having non-systematically named (or
typed) array count fields ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:58:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:58:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk07-0003zI-Tj; Tue, 24 Apr 2012 17:58:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk06-0003z7-J2
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:58:06 +0000
Received: from [85.158.143.35:37595] by server-2.bemta-4.messagelabs.com id
	18/0F-17550-DA9E69F4; Tue, 24 Apr 2012 17:58:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335290285!14748077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10497 invoked from network); 24 Apr 2012 17:58:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:58:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:58:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk04-0007SP-PM; Tue, 24 Apr 2012 17:58:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk04-0007gf-OY;
	Tue, 24 Apr 2012 18:58:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59820.578074.902872@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:58:04 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: provide
	libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> libxl: provide libxl_domain_config_init.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:58:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:58:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk07-0003zI-Tj; Tue, 24 Apr 2012 17:58:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk06-0003z7-J2
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:58:06 +0000
Received: from [85.158.143.35:37595] by server-2.bemta-4.messagelabs.com id
	18/0F-17550-DA9E69F4; Tue, 24 Apr 2012 17:58:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335290285!14748077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NDQ1MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10497 invoked from network); 24 Apr 2012 17:58:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 17:58:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 18:58:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk04-0007SP-PM; Tue, 24 Apr 2012 17:58:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk04-0007gf-OY;
	Tue, 24 Apr 2012 18:58:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59820.578074.902872@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 18:58:04 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: provide
	libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> libxl: provide libxl_domain_config_init.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:58:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk0L-00041h-Az; Tue, 24 Apr 2012 17:58:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMk0K-00041Q-CI
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:58:20 +0000
Received: from [85.158.143.35:50872] by server-2.bemta-4.messagelabs.com id
	D3/3F-17550-BB9E69F4; Tue, 24 Apr 2012 17:58:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335290297!17614441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA4MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25664 invoked from network); 24 Apr 2012 17:58:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:58:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191851188"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:58:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:58:16 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMk0G-0000DI-3N;
	Tue, 24 Apr 2012 18:58:16 +0100
Message-ID: <4F96E9B9.6080407@citrix.com>
Date: Tue, 24 Apr 2012 18:58:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
	<20374.48381.57194.304369@mariner.uk.xensource.com>
	<1335279579.4347.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335279579.4347.191.camel@zakaz.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBUdWUsIDIwMTItMDQtMjQgYXQgMTU6NDcgKzAx
MDAsIElhbiBKYWNrc29uIHdyb3RlOgo+PiBJYW4gQ2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4t
ZGV2ZWxdIFtQQVRDSF0gbGlieGw6IHByZXZlbnQgeGwgZnJvbSBydW5uaW5nIGlmIHhlbmQJaXMg
cnVubmluZy4iKToKPj4+IFlvdSBjb3VsZCBjb25zaWRlciB0aGlzIHRvIGJlIGEgYmVzdCBlZmZv
cnQgY2hlY2sgZm9yIHhlbmQuIElPVyB3ZSB0cnkKPj4+IGFuZCBsb29rIGJ1dCBpZiB3ZSBjYW4n
dCB0ZWxsIHRoZW4gd2UgYXNzdW1lIGl0IGlzIG5vdC4KPj4gSSBndWVzcy4KPj4KPj4+IEl0J3Mg
bm90IHRlcnJpYmx5IHJvYnVzdCB0byBqdXN0IGJsdW5kZXIgb24sIGJ1dCBvbiB0aGUgb3RoZXIg
aGFuZCBiZWluZwo+Pj4gbW9yZSByb2J1c3QgaGFzIGEgYmlnZ2VyIHJpc2sgb2YgZmFsc2UgcG9z
aXRpdmVzLCBlLmcuIGZhaWxpbmcgdG8gc3RhcnQKPj4+IHhsIGJlY2F1c2UgL3Zhci9sb2NrL3N1
YnN5cy8gZG9lcyBub3QgZXhpc3QgaXNuJ3QgZXNwZWNpYWxseSBoZWxwZnVsCj4+PiBlaXRoZXIg
KHRoZSBFQUNDRVNTIHJldHVybiBjb2RlIGRvZXNuJ3QgZGlzdGluZ3Vpc2ggdGhhdAo+Pj4gZnJv
bSAvdmFyL2xvY2svc3Vic3lzL3hlbmQgbm90IGV4aXN0aW5nKS4KPj4gRUFDQ0VTIHdvdWxkIGhh
cHBlbiBvbmx5IGlmIHRoZSBwZXJtaXNzaW9ucyBwcmV2ZW50ZWQgdXMgZnJvbQo+PiBsb29raW5n
LiAgSWYgL3Zhci9sb2NrL3N1YnN5cyBkb2Vzbid0IGV4aXN0IHdlJ2xsIGdldCBFTk9FTlQsIHRo
ZQo+PiAiZ29vZCIgZXJyb3IgcmV0dXJuLgo+Cj4gT2gsIHJpZ2h0Lgo+Cj4gV2VsbCwgbm90IHN0
YXJ0aW5nIGJlY2F1c2UgdGhlIHBlcm1zIG9uIC92YXIvbG9jay9zdWJzeXMgYXJlIHRvbyB0aWdo
dAo+IChlLmcuIHNlbGludXggcmVzdHJpY3RpbmcgaXQgdG8gaW5pdHNjcmlwdHMgb25seT8gdW5y
ZWFsaXN0aWMgbWF5YmUpCj4gc2VlbXMgdW5oZWxwZnVsIHRvby4KPgo+IChJIGFkbWl0IHRoaXMg
aXNuJ3QgYXMgY29tcGVsbGluZyBhcyBteSBwcmV2aW91cyBleGFtcGxlKS4KPgo+IElhbi4KPgoK
V2hhdCBoYXZlIHdlIGRlY2lkZWQgYXQgdGhlIGVuZD8gU2hvdWxkIEkgZG8gYW4gaW52ZXJzZSBj
aGVjaywgYW5kIHJ1biAKb25seSBpZiBhY2Nlc3MoLi4uKSAhPSAwICYmIGVycm5vID09IEVOT0VO
VD8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 24 17:58:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 17:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk0L-00041h-Az; Tue, 24 Apr 2012 17:58:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMk0K-00041Q-CI
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 17:58:20 +0000
Received: from [85.158.143.35:50872] by server-2.bemta-4.messagelabs.com id
	D3/3F-17550-BB9E69F4; Tue, 24 Apr 2012 17:58:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335290297!17614441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDA4MzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25664 invoked from network); 24 Apr 2012 17:58:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 17:58:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191851188"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 13:58:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 13:58:16 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMk0G-0000DI-3N;
	Tue, 24 Apr 2012 18:58:16 +0100
Message-ID: <4F96E9B9.6080407@citrix.com>
Date: Tue, 24 Apr 2012 18:58:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
	<20374.48381.57194.304369@mariner.uk.xensource.com>
	<1335279579.4347.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335279579.4347.191.camel@zakaz.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBUdWUsIDIwMTItMDQtMjQgYXQgMTU6NDcgKzAx
MDAsIElhbiBKYWNrc29uIHdyb3RlOgo+PiBJYW4gQ2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4t
ZGV2ZWxdIFtQQVRDSF0gbGlieGw6IHByZXZlbnQgeGwgZnJvbSBydW5uaW5nIGlmIHhlbmQJaXMg
cnVubmluZy4iKToKPj4+IFlvdSBjb3VsZCBjb25zaWRlciB0aGlzIHRvIGJlIGEgYmVzdCBlZmZv
cnQgY2hlY2sgZm9yIHhlbmQuIElPVyB3ZSB0cnkKPj4+IGFuZCBsb29rIGJ1dCBpZiB3ZSBjYW4n
dCB0ZWxsIHRoZW4gd2UgYXNzdW1lIGl0IGlzIG5vdC4KPj4gSSBndWVzcy4KPj4KPj4+IEl0J3Mg
bm90IHRlcnJpYmx5IHJvYnVzdCB0byBqdXN0IGJsdW5kZXIgb24sIGJ1dCBvbiB0aGUgb3RoZXIg
aGFuZCBiZWluZwo+Pj4gbW9yZSByb2J1c3QgaGFzIGEgYmlnZ2VyIHJpc2sgb2YgZmFsc2UgcG9z
aXRpdmVzLCBlLmcuIGZhaWxpbmcgdG8gc3RhcnQKPj4+IHhsIGJlY2F1c2UgL3Zhci9sb2NrL3N1
YnN5cy8gZG9lcyBub3QgZXhpc3QgaXNuJ3QgZXNwZWNpYWxseSBoZWxwZnVsCj4+PiBlaXRoZXIg
KHRoZSBFQUNDRVNTIHJldHVybiBjb2RlIGRvZXNuJ3QgZGlzdGluZ3Vpc2ggdGhhdAo+Pj4gZnJv
bSAvdmFyL2xvY2svc3Vic3lzL3hlbmQgbm90IGV4aXN0aW5nKS4KPj4gRUFDQ0VTIHdvdWxkIGhh
cHBlbiBvbmx5IGlmIHRoZSBwZXJtaXNzaW9ucyBwcmV2ZW50ZWQgdXMgZnJvbQo+PiBsb29raW5n
LiAgSWYgL3Zhci9sb2NrL3N1YnN5cyBkb2Vzbid0IGV4aXN0IHdlJ2xsIGdldCBFTk9FTlQsIHRo
ZQo+PiAiZ29vZCIgZXJyb3IgcmV0dXJuLgo+Cj4gT2gsIHJpZ2h0Lgo+Cj4gV2VsbCwgbm90IHN0
YXJ0aW5nIGJlY2F1c2UgdGhlIHBlcm1zIG9uIC92YXIvbG9jay9zdWJzeXMgYXJlIHRvbyB0aWdo
dAo+IChlLmcuIHNlbGludXggcmVzdHJpY3RpbmcgaXQgdG8gaW5pdHNjcmlwdHMgb25seT8gdW5y
ZWFsaXN0aWMgbWF5YmUpCj4gc2VlbXMgdW5oZWxwZnVsIHRvby4KPgo+IChJIGFkbWl0IHRoaXMg
aXNuJ3QgYXMgY29tcGVsbGluZyBhcyBteSBwcmV2aW91cyBleGFtcGxlKS4KPgo+IElhbi4KPgoK
V2hhdCBoYXZlIHdlIGRlY2lkZWQgYXQgdGhlIGVuZD8gU2hvdWxkIEkgZG8gYW4gaW52ZXJzZSBj
aGVjaywgYW5kIHJ1biAKb25seSBpZiBhY2Nlc3MoLi4uKSAhPSAwICYmIGVycm5vID09IEVOT0VO
VD8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:00:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk27-0004Jp-Rw; Tue, 24 Apr 2012 18:00:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk26-0004JX-8g
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:00:10 +0000
Received: from [85.158.143.35:2923] by server-2.bemta-4.messagelabs.com id
	C1/A0-17550-92AE69F4; Tue, 24 Apr 2012 18:00:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335290408!12486564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7133 invoked from network); 24 Apr 2012 18:00:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:00:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:00:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:00:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk20-0007T7-MK; Tue, 24 Apr 2012 18:00:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk20-0007hH-L3;
	Tue, 24 Apr 2012 19:00:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59940.607143.114201@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:00:04 +0100
To: George Dunlap <dunlapg@umich.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] Driver domains communication protoco=
l proposal"):
> On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> w=
rote:
> > =A0vdi
> > =A0 =A0 This host's intent to access a specific target.
> > =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
> > =A0 =A0 Possible states: inactive/active.
> > =A0 =A0 Abstract operations: prepare, activate, deactivate, unprepare.
> =

> VDI as used by XenServer seems to mean "virtual disk instance", and as
> such is actually persistent.  I don't quite understand what it's
> supposed to mean here, and how it differs from VBD (which in XenServer
> terminology means "virtual block device").

One "vdi" in this sense can support multiple "vbd"s.  A "vbd"
represents an attachment to a domain (or some other kind of provision
for use) whereas a "vdi" is a preparatory thing.

Feel free to suggest different terminology.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:00:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk27-0004Jp-Rw; Tue, 24 Apr 2012 18:00:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk26-0004JX-8g
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:00:10 +0000
Received: from [85.158.143.35:2923] by server-2.bemta-4.messagelabs.com id
	C1/A0-17550-92AE69F4; Tue, 24 Apr 2012 18:00:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335290408!12486564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7133 invoked from network); 24 Apr 2012 18:00:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:00:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:00:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:00:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk20-0007T7-MK; Tue, 24 Apr 2012 18:00:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk20-0007hH-L3;
	Tue, 24 Apr 2012 19:00:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59940.607143.114201@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:00:04 +0100
To: George Dunlap <dunlapg@umich.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] Driver domains communication protoco=
l proposal"):
> On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> w=
rote:
> > =A0vdi
> > =A0 =A0 This host's intent to access a specific target.
> > =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
> > =A0 =A0 Possible states: inactive/active.
> > =A0 =A0 Abstract operations: prepare, activate, deactivate, unprepare.
> =

> VDI as used by XenServer seems to mean "virtual disk instance", and as
> such is actually persistent.  I don't quite understand what it's
> supposed to mean here, and how it differs from VBD (which in XenServer
> terminology means "virtual block device").

One "vdi" in this sense can support multiple "vbd"s.  A "vbd"
represents an attachment to a domain (or some other kind of provision
for use) whereas a "vdi" is a preparatory thing.

Feel free to suggest different terminology.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:01:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk2s-0004SA-G4; Tue, 24 Apr 2012 18:00:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk2r-0004Rr-5Y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:00:57 +0000
Received: from [193.109.254.147:19912] by server-6.bemta-14.messagelabs.com id
	DC/7D-02047-85AE69F4; Tue, 24 Apr 2012 18:00:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335290455!6100539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12316 invoked from network); 24 Apr 2012 18:00:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:00:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:00:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:00:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk2p-0007TO-AD; Tue, 24 Apr 2012 18:00:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk2p-0007hR-9O;
	Tue, 24 Apr 2012 19:00:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59991.278304.64133@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:00:55 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F96E9B9.6080407@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
	<20374.48381.57194.304369@mariner.uk.xensource.com>
	<1335279579.4347.191.camel@zakaz.uk.xensource.com>
	<4F96E9B9.6080407@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from run=
ning if xend	is running."):
> Ian Campbell escribi=F3:
> > Well, not starting because the perms on /var/lock/subsys are too tight
> > (e.g. selinux restricting it to initscripts only? unrealistic maybe)
> > seems unhelpful too.
...
> What have we decided at the end? Should I do an inverse check, and run =

> only if access(...) !=3D 0 && errno =3D=3D ENOENT?

Ian and I don't seem to be entirely in agreement, but in this case I
can live with the "best effort" error handling as in your most recent
patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:01:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk2s-0004SA-G4; Tue, 24 Apr 2012 18:00:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk2r-0004Rr-5Y
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:00:57 +0000
Received: from [193.109.254.147:19912] by server-6.bemta-14.messagelabs.com id
	DC/7D-02047-85AE69F4; Tue, 24 Apr 2012 18:00:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335290455!6100539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12316 invoked from network); 24 Apr 2012 18:00:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:00:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:00:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:00:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk2p-0007TO-AD; Tue, 24 Apr 2012 18:00:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk2p-0007hR-9O;
	Tue, 24 Apr 2012 19:00:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.59991.278304.64133@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:00:55 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F96E9B9.6080407@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
	<1335278440.4347.180.camel@zakaz.uk.xensource.com>
	<20374.48381.57194.304369@mariner.uk.xensource.com>
	<1335279579.4347.191.camel@zakaz.uk.xensource.com>
	<4F96E9B9.6080407@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend	is
 running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from run=
ning if xend	is running."):
> Ian Campbell escribi=F3:
> > Well, not starting because the perms on /var/lock/subsys are too tight
> > (e.g. selinux restricting it to initscripts only? unrealistic maybe)
> > seems unhelpful too.
...
> What have we decided at the end? Should I do an inverse check, and run =

> only if access(...) !=3D 0 && errno =3D=3D ENOENT?

Ian and I don't seem to be entirely in agreement, but in this case I
can live with the "best effort" error handling as in your most recent
patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:02:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk4S-0004gq-0Q; Tue, 24 Apr 2012 18:02:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk4Q-0004gb-Bn
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 18:02:34 +0000
Received: from [85.158.143.35:19960] by server-3.bemta-4.messagelabs.com id
	E4/37-05853-9BAE69F4; Tue, 24 Apr 2012 18:02:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335290552!8575018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2342 invoked from network); 24 Apr 2012 18:02:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:02:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:02:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:02:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk4O-0007U4-Ek; Tue, 24 Apr 2012 18:02:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk4O-0007hq-DI;
	Tue, 24 Apr 2012 19:02:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.60088.396314.671522@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:02:32 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> <Porting from xen 4.1, patch on Xen unstable 25138>

I'm afraid that 25138 was out of date even when you posted your
revised patch, and it still doesn't apply.

Are you working with the staging tree ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:02:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk4S-0004gq-0Q; Tue, 24 Apr 2012 18:02:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk4Q-0004gb-Bn
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 18:02:34 +0000
Received: from [85.158.143.35:19960] by server-3.bemta-4.messagelabs.com id
	E4/37-05853-9BAE69F4; Tue, 24 Apr 2012 18:02:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335290552!8575018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2342 invoked from network); 24 Apr 2012 18:02:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:02:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:02:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:02:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk4O-0007U4-Ek; Tue, 24 Apr 2012 18:02:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk4O-0007hq-DI;
	Tue, 24 Apr 2012 19:02:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.60088.396314.671522@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:02:32 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> <Porting from xen 4.1, patch on Xen unstable 25138>

I'm afraid that 25138 was out of date even when you posted your
revised patch, and it still doesn't apply.

Are you working with the staging tree ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:08:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk9k-0004zQ-QI; Tue, 24 Apr 2012 18:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk9i-0004zL-Mm
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:08:02 +0000
Received: from [85.158.138.51:12205] by server-2.bemta-3.messagelabs.com id
	D1/47-09269-10CE69F4; Tue, 24 Apr 2012 18:08:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335290881!12598911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28772 invoked from network); 24 Apr 2012 18:08:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:08:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:08:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:08:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk9g-0007Vp-SV; Tue, 24 Apr 2012 18:08:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk9g-0000Pd-RH;
	Tue, 24 Apr 2012 19:08:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.60416.709615.674968@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:08:00 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120405101544.GD14774@ocelot.phlegethon.org>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
	<20120405101544.GD14774@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, ian.campbell@citrix.com,
	andres@gridcentric.ca, xen-devel@lists.xen.org,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation"):
> At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
> > Document the sharing libxc interface, including failure conditions, meaning of
> > stats, and internal semantics/behavior.
> > 
> > Also remove a stale debug call.
> > 
> > Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits. Both
> > patches touch the tools. Patch #2 is entirely documentation comments.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Thanks, I have committed both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:08:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMk9k-0004zQ-QI; Tue, 24 Apr 2012 18:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMk9i-0004zL-Mm
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:08:02 +0000
Received: from [85.158.138.51:12205] by server-2.bemta-3.messagelabs.com id
	D1/47-09269-10CE69F4; Tue, 24 Apr 2012 18:08:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335290881!12598911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28772 invoked from network); 24 Apr 2012 18:08:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:08:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:08:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:08:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMk9g-0007Vp-SV; Tue, 24 Apr 2012 18:08:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMk9g-0000Pd-RH;
	Tue, 24 Apr 2012 19:08:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.60416.709615.674968@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:08:00 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120405101544.GD14774@ocelot.phlegethon.org>
References: <patchbomb.1333393862@xdev.gridcentric.ca>
	<20120405101544.GD14774@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, ian.campbell@citrix.com,
	andres@gridcentric.ca, xen-devel@lists.xen.org,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] [PATCH 0 of 2] Sharing Documentation"):
> At 15:11 -0400 on 02 Apr (1333379462), Andres Lagar-Cavilla wrote:
> > Document the sharing libxc interface, including failure conditions, meaning of
> > stats, and internal semantics/behavior.
> > 
> > Also remove a stale debug call.
> > 
> > Patch #2 depends on patch #1. Patch #1 touches hypervisor x86/mm bits. Both
> > patches touch the tools. Patch #2 is entirely documentation comments.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Thanks, I have committed both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:09:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMkBF-00055A-9v; Tue, 24 Apr 2012 18:09:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMkBE-00054u-6M
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:09:36 +0000
Received: from [193.109.254.147:18305] by server-11.bemta-14.messagelabs.com
	id A5/50-05858-F5CE69F4; Tue, 24 Apr 2012 18:09:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335290973!6136886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15848 invoked from network); 24 Apr 2012 18:09:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191853002"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:05:27 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:05:26 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMk7B-0000Jo-Un;
	Tue, 24 Apr 2012 19:05:25 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 24 Apr 2012 19:05:22 +0100
Message-ID: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, ian.jackson@eu.citrix.com,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend is
	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prevent xl from doing any operation if xend daemon is running. That
prevents bugs that happened when xl and xend raced to close a domain.

Changes since v1:

 * Add documentation to xl man page.

 * Permit the execution of commands that don't modify anything.

 * Indent error message.

Cc: george.dunlap@eu.citrix.com
Cc: ian.jackson@eu.citrix.com
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.pod.1         |    6 ++
 tools/libxl/xl.c          |   22 +++++++-
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    4 +-
 tools/libxl/xl_cmdtable.c |  132 ++++++++++++++++++++++----------------------
 5 files changed, 96 insertions(+), 69 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e5324fb..e829697 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -75,6 +75,12 @@ Verbose.
 
 Dry run: do not actually execute the command.
 
+=item B<-f>
+
+Force execution: xl will refuse to run some commands if it detects that xend is
+also running, this option will force the execution of those commands, even
+though it is unsafe.
+
 =back
 
 =head1 DOMAIN SUBCOMMANDS
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..720bb66 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -32,8 +32,11 @@
 #include "libxlutil.h"
 #include "xl.h"
 
+#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
+
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
+int force_execution;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
@@ -103,8 +106,9 @@ int main(int argc, char **argv)
     char *config_file;
     void *config_data = 0;
     int config_len = 0;
+    const char *locks[] = XEND_LOCK;
 
-    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
+    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
         switch (opt) {
         case 'v':
             if (minmsglevel > 0) minmsglevel--;
@@ -112,6 +116,9 @@ int main(int argc, char **argv)
         case 'N':
             dryrun_only = 1;
             break;
+        case 'f':
+            force_execution = 1;
+            break;
         default:
             fprintf(stderr, "unknown global option\n");
             exit(2);
@@ -162,6 +169,19 @@ int main(int argc, char **argv)
             ret = 1;
             goto xit;
         }
+        if (cspec->modifies) {
+            for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
+                if (!access(locks[i], F_OK) && !force_execution) {
+                    fprintf(stderr,
+"xend is running, which prevents xl from working correctly.\n"
+"If you still want to force the execution of xl please use the -f\n"
+"option.\n"
+                            );
+                    ret = 1;
+                    goto xit;
+                }
+            }
+        }
         ret = cspec->cmd_impl(argc, argv);
     } else if (!strcmp(cmd, "help")) {
         help(argv[1]);
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0a3d628..5ddd2da 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -21,6 +21,7 @@ struct cmd_spec {
     char *cmd_name;
     int (*cmd_impl)(int argc, char **argv);
     int can_dryrun;
+    int modifies;
     char *cmd_desc;
     char *cmd_usage;
     char *cmd_option;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..65bc6d6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1909,7 +1909,7 @@ void help(const char *command)
     struct cmd_spec *cmd;
 
     if (!command || !strcmp(command, "help")) {
-        printf("Usage xl [-vN] <subcommand> [args]\n\n");
+        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
         printf("xl full list of subcommands:\n\n");
         for (i = 0; i < cmdtable_len; i++) {
             printf(" %-19s ", cmd_table[i].cmd_name);
@@ -1920,7 +1920,7 @@ void help(const char *command)
     } else {
         cmd = cmdtable_lookup(command);
         if (cmd) {
-            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
+            printf("Usage: xl [-vf%s] %s %s\n\n%s.\n\n",
                    cmd->can_dryrun ? "N" : "",
                    cmd->cmd_name,
                    cmd->cmd_usage,
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index f461a2a..5509126 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -19,7 +19,7 @@
 
 struct cmd_spec cmd_table[] = {
     { "create",
-      &main_create, 1,
+      &main_create, 1, 1,
       "Create a domain from config file <filename>",
       "<ConfigFile> [options] [vars]",
       "-h                      Print this help.\n"
@@ -33,7 +33,7 @@ struct cmd_spec cmd_table[] = {
       "-e                      Do not wait in the background for the death of the domain."
     },
     { "config-update",
-      &main_config_update, 1,
+      &main_config_update, 1, 1,
       "Update a running domain's saved configuration, used when rebuilding "
       "the domain after reboot",
       "<Domain> <ConfigFile> [options] [vars]",
@@ -42,7 +42,7 @@ struct cmd_spec cmd_table[] = {
       "-d                      Enable debug messages.\n"
     },
     { "list",
-      &main_list, 0,
+      &main_list, 0, 0,
       "List information about all/some domains",
       "[options] [Domain]\n",
       "-l, --long              Output all VM details\n"
@@ -50,12 +50,12 @@ struct cmd_spec cmd_table[] = {
       "-Z, --context           Prints out security context"
     },
     { "destroy",
-      &main_destroy, 0,
+      &main_destroy, 0, 1,
       "Terminate a domain immediately",
       "<Domain>",
     },
     { "shutdown",
-      &main_shutdown, 0,
+      &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-w                      Wait for guest to shutdown.\n"
     },
     { "reboot",
-      &main_reboot, 0,
+      &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -72,44 +72,44 @@ struct cmd_spec cmd_table[] = {
       "                        no PV drivers.\n"
     },
     { "pci-attach",
-      &main_pciattach, 0,
+      &main_pciattach, 0, 1,
       "Insert a new pass-through pci device",
       "<Domain> <BDF> [Virtual Slot]",
     },
     { "pci-detach",
-      &main_pcidetach, 0,
+      &main_pcidetach, 0, 1,
       "Remove a domain's pass-through pci device",
       "<Domain> <BDF>",
     },
     { "pci-list",
-      &main_pcilist, 0,
+      &main_pcilist, 0, 0,
       "List pass-through pci devices for a domain",
       "<Domain>",
     },
     { "pci-list-assignable-devices",
-      &main_pcilist_assignable, 0,
+      &main_pcilist_assignable, 0, 0,
       "List all the assignable pci devices",
       "",
     },
     { "pause",
-      &main_pause, 0,
+      &main_pause, 0, 1,
       "Pause execution of a domain",
       "<Domain>",
     },
     { "unpause",
-      &main_unpause, 0,
+      &main_unpause, 0, 1,
       "Unpause a paused domain",
       "<Domain>",
     },
     { "console",
-      &main_console, 0,
+      &main_console, 0, 0,
       "Attach to domain's console",
       "[options] <Domain>\n"
       "-t <type>       console type, pv or serial\n"
       "-n <number>     console number"
     },
     { "vncviewer",
-      &main_vncviewer, 0,
+      &main_vncviewer, 0, 0,
       "Attach to domain's VNC server.",
       "[options] <Domain>\n"
       "--autopass               Pass VNC password to viewer via stdin and\n"
@@ -117,14 +117,14 @@ struct cmd_spec cmd_table[] = {
       "--vncviewer-autopass     (consistency alias for --autopass)"
     },
     { "save",
-      &main_save, 0,
+      &main_save, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <CheckpointFile> [<ConfigFile>]",
       "-h  Print this help.\n"
       "-c  Leave domain running after creating the snapshot."
     },
     { "migrate",
-      &main_migrate, 0,
+      &main_migrate, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <host>",
       "-h              Print this help.\n"
@@ -136,12 +136,12 @@ struct cmd_spec cmd_table[] = {
       "                of the domain."
     },
     { "dump-core",
-      &main_dump_core, 0,
+      &main_dump_core, 0, 1,
       "Core dump a domain",
       "<Domain> <filename>"
     },
     { "restore",
-      &main_restore, 0,
+      &main_restore, 0, 1,
       "Restore a domain from a saved state",
       "[options] [<ConfigFile>] <CheckpointFile>",
       "-h  Print this help.\n"
@@ -150,68 +150,68 @@ struct cmd_spec cmd_table[] = {
       "-d  Enable debug messages."
     },
     { "migrate-receive",
-      &main_migrate_receive, 0,
+      &main_migrate_receive, 0, 1,
       "Restore a domain from a saved state",
       "- for internal use only",
     },
     { "cd-insert",
-      &main_cd_insert, 0,
+      &main_cd_insert, 0, 1,
       "Insert a cdrom into a guest's cd drive",
       "<Domain> <VirtualDevice> <type:path>",
     },
     { "cd-eject",
-      &main_cd_eject, 0,
+      &main_cd_eject, 0, 1,
       "Eject a cdrom from a guest's cd drive",
       "<Domain> <VirtualDevice>",
     },
     { "mem-max",
-      &main_memmax, 0,
+      &main_memmax, 0, 1,
       "Set the maximum amount reservation for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "mem-set",
-      &main_memset, 0,
+      &main_memset, 0, 1,
       "Set the current memory usage for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "button-press",
-      &main_button_press, 0,
+      &main_button_press, 0, 1,
       "Indicate an ACPI button press to the domain",
       "<Domain> <Button>",
       "<Button> may be 'power' or 'sleep'."
     },
     { "vcpu-list",
-      &main_vcpulist, 0,
+      &main_vcpulist, 0, 0,
       "List the VCPUs for all/some domains",
       "[Domain, ...]",
     },
     { "vcpu-pin",
-      &main_vcpupin, 0,
+      &main_vcpupin, 0, 1,
       "Set which CPUs a VCPU can use",
       "<Domain> <VCPU|all> <CPUs|all>",
     },
     { "vcpu-set",
-      &main_vcpuset, 0,
+      &main_vcpuset, 0, 1,
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
     { "list-vm",
-      &main_list_vm, 0,
+      &main_list_vm, 0, 0,
       "List the VMs,without DOM0",
       "",
     },
     { "info",
-      &main_info, 0,
+      &main_info, 0, 0,
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
     { "sharing",
-      &main_sharing, 0,
+      &main_sharing, 0, 0,
       "Get information about page sharing",
       "[Domain]", 
     },
     { "sched-credit",
-      &main_sched_credit, 0,
+      &main_sched_credit, 0, 1,
       "Get/set credit scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
@@ -223,7 +223,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
-      &main_sched_credit2, 0,
+      &main_sched_credit2, 0, 1,
       "Get/set credit2 scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -231,7 +231,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "sched-sedf",
-      &main_sched_sedf, 0,
+      &main_sched_sedf, 0, 1,
       "Get/set sedf scheduler parameters",
       "[options]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -247,109 +247,109 @@ struct cmd_spec cmd_table[] = {
       "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
-      &main_domid, 0,
+      &main_domid, 0, 0,
       "Convert a domain name to domain id",
       "<DomainName>",
     },
     { "domname",
-      &main_domname, 0,
+      &main_domname, 0, 0,
       "Convert a domain id to domain name",
       "<DomainId>",
     },
     { "rename",
-      &main_rename, 0,
+      &main_rename, 0, 1,
       "Rename a domain",
       "<Domain> <NewDomainName>",
     },
     { "trigger",
-      &main_trigger, 0,
+      &main_trigger, 0, 1,
       "Send a trigger to a domain",
       "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
     },
     { "sysrq",
-      &main_sysrq, 0,
+      &main_sysrq, 0, 1,
       "Send a sysrq to a domain",
       "<Domain> <letter>",
     },
     { "debug-keys",
-      &main_debug_keys, 0,
+      &main_debug_keys, 0, 1,
       "Send debug keys to Xen",
       "<Keys>",
     },
     { "dmesg",
-      &main_dmesg, 0,
+      &main_dmesg, 0, 0,
       "Read and/or clear dmesg buffer",
       "[-c]",
       "  -c                        Clear dmesg buffer as well as printing it",
     },
     { "top",
-      &main_top, 0,
+      &main_top, 0, 0,
       "Monitor a host and the domains in real time",
       "",
     },
     { "network-attach",
-      &main_networkattach, 0,
+      &main_networkattach, 0, 1,
       "Create a new virtual network device",
       "<Domain> [type=<type>] [mac=<mac>] [bridge=<bridge>] "
       "[ip=<ip>] [script=<script>] [backend=<BackDomain>] [vifname=<name>] "
       "[rate=<rate>] [model=<model>] [accel=<accel>]",
     },
     { "network-list",
-      &main_networklist, 0,
+      &main_networklist, 0, 0,
       "List virtual network interfaces for a domain",
       "<Domain(s)>",
     },
     { "network-detach",
-      &main_networkdetach, 0,
+      &main_networkdetach, 0, 1,
       "Destroy a domain's virtual network device",
       "<Domain> <DevId|mac>",
     },
     { "block-attach",
-      &main_blockattach, 1,
+      &main_blockattach, 1, 1,
       "Create a new virtual block device",
       "<Domain> <disk-spec-component(s)>...",
     },
     { "block-list",
-      &main_blocklist, 0,
+      &main_blocklist, 0, 0,
       "List virtual block devices for a domain",
       "<Domain(s)>",
     },
     { "block-detach",
-      &main_blockdetach, 0,
+      &main_blockdetach, 0, 1,
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
     { "uptime",
-      &main_uptime, 0,
+      &main_uptime, 0, 0,
       "Print uptime for all/some domains",
       "[-s] [Domain]",
     },
     { "tmem-list",
-      &main_tmem_list, 0,
+      &main_tmem_list, 0, 0,
       "List tmem pools",
       "[-l] [<Domain>|-a]",
       "  -l                             List tmem stats",
     },
     { "tmem-freeze",
-      &main_tmem_freeze, 0,
+      &main_tmem_freeze, 0, 1,
       "Freeze tmem pools",
       "[<Domain>|-a]",
       "  -a                             Freeze all tmem",
     },
     { "tmem-destroy",
-      &main_tmem_destroy, 0,
+      &main_tmem_destroy, 0, 1,
       "Destroy tmem pools",
       "[<Domain>|-a]",
       "  -a                             Destroy all tmem",
     },
     { "tmem-thaw",
-      &main_tmem_thaw, 0,
+      &main_tmem_thaw, 0, 1,
       "Thaw tmem pools",
       "[<Domain>|-a]",
       "  -a                             Thaw all tmem",
     },
     { "tmem-set",
-      &main_tmem_set, 0,
+      &main_tmem_set, 0, 1,
       "Change tmem settings",
       "[<Domain>|-a] [-w[=WEIGHT]|-c[=CAP]|-p[=COMPRESS]]",
       "  -a                             Operate on all tmem\n"
@@ -358,7 +358,7 @@ struct cmd_spec cmd_table[] = {
       "  -p COMPRESS                    Compress (int)",
     },
     { "tmem-shared-auth",
-      &main_tmem_shared_auth, 0,
+      &main_tmem_shared_auth, 0, 1,
       "De/authenticate shared tmem pool",
       "[<Domain>|-a] [-u[=UUID] [-A[=AUTH]",
       "  -a                             Authenticate for all tmem pools\n"
@@ -367,12 +367,12 @@ struct cmd_spec cmd_table[] = {
       "  -A AUTH                        0=auth,1=deauth",
     },
     { "tmem-freeable",
-      &main_tmem_freeable, 0,
+      &main_tmem_freeable, 0, 0,
       "Get information about how much freeable memory (MB) is in-use by tmem",
       "",
     },
     { "cpupool-create",
-      &main_cpupoolcreate, 1,
+      &main_cpupoolcreate, 1, 1,
       "Create a CPU pool based an ConfigFile",
       "[options] <ConfigFile> [vars]",
       "-h, --help                   Print this help.\n"
@@ -381,53 +381,53 @@ struct cmd_spec cmd_table[] = {
       "                              (deprecated in favour of global -N option)."
     },
     { "cpupool-list",
-      &main_cpupoollist, 0,
+      &main_cpupoollist, 0, 0,
       "List CPU pools on host",
       "[-c|--cpus] [<CPU Pool>]",
       "-c, --cpus                     Output list of CPUs used by a pool"
     },
     { "cpupool-destroy",
-      &main_cpupooldestroy, 0,
+      &main_cpupooldestroy, 0, 1,
       "Deactivates a CPU pool",
       "<CPU Pool>",
     },
     { "cpupool-rename",
-      &main_cpupoolrename, 0,
+      &main_cpupoolrename, 0, 1,
       "Renames a CPU pool",
       "<CPU Pool> <new name>",
     },
     { "cpupool-cpu-add",
-      &main_cpupoolcpuadd, 0,
+      &main_cpupoolcpuadd, 0, 1,
       "Adds a CPU to a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-cpu-remove",
-      &main_cpupoolcpuremove, 0,
+      &main_cpupoolcpuremove, 0, 1,
       "Removes a CPU from a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-migrate",
-      &main_cpupoolmigrate, 0,
+      &main_cpupoolmigrate, 0, 1,
       "Moves a domain into a CPU pool",
       "<Domain> <CPU Pool>",
     },
     { "cpupool-numa-split",
-      &main_cpupoolnumasplit, 0,
+      &main_cpupoolnumasplit, 0, 1,
       "Splits up the machine into one CPU pool per NUMA node",
       "",
     },
     { "getenforce",
-      &main_getenforce, 0,
+      &main_getenforce, 0, 0,
       "Returns the current enforcing mode of the Flask Xen security module",
       "",
     },
     { "setenforce",
-      &main_setenforce, 0,
+      &main_setenforce, 0, 1,
       "Sets the current enforcing mode of the Flask Xen security module",
       "<1|0|Enforcing|Permissive>",
     },
     { "loadpolicy",
-      &main_loadpolicy, 0,
+      &main_loadpolicy, 0, 1,
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:09:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMkBF-00055A-9v; Tue, 24 Apr 2012 18:09:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMkBE-00054u-6M
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:09:36 +0000
Received: from [193.109.254.147:18305] by server-11.bemta-14.messagelabs.com
	id A5/50-05858-F5CE69F4; Tue, 24 Apr 2012 18:09:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335290973!6136886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15848 invoked from network); 24 Apr 2012 18:09:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330923600"; d="scan'208";a="191853002"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 14:05:27 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Apr 2012 14:05:26 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMk7B-0000Jo-Un;
	Tue, 24 Apr 2012 19:05:25 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 24 Apr 2012 19:05:22 +0100
Message-ID: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, ian.jackson@eu.citrix.com,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend is
	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prevent xl from doing any operation if xend daemon is running. That
prevents bugs that happened when xl and xend raced to close a domain.

Changes since v1:

 * Add documentation to xl man page.

 * Permit the execution of commands that don't modify anything.

 * Indent error message.

Cc: george.dunlap@eu.citrix.com
Cc: ian.jackson@eu.citrix.com
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.pod.1         |    6 ++
 tools/libxl/xl.c          |   22 +++++++-
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    4 +-
 tools/libxl/xl_cmdtable.c |  132 ++++++++++++++++++++++----------------------
 5 files changed, 96 insertions(+), 69 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e5324fb..e829697 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -75,6 +75,12 @@ Verbose.
 
 Dry run: do not actually execute the command.
 
+=item B<-f>
+
+Force execution: xl will refuse to run some commands if it detects that xend is
+also running, this option will force the execution of those commands, even
+though it is unsafe.
+
 =back
 
 =head1 DOMAIN SUBCOMMANDS
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 2b14814..720bb66 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -32,8 +32,11 @@
 #include "libxlutil.h"
 #include "xl.h"
 
+#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
+
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
+int force_execution;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
@@ -103,8 +106,9 @@ int main(int argc, char **argv)
     char *config_file;
     void *config_data = 0;
     int config_len = 0;
+    const char *locks[] = XEND_LOCK;
 
-    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
+    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
         switch (opt) {
         case 'v':
             if (minmsglevel > 0) minmsglevel--;
@@ -112,6 +116,9 @@ int main(int argc, char **argv)
         case 'N':
             dryrun_only = 1;
             break;
+        case 'f':
+            force_execution = 1;
+            break;
         default:
             fprintf(stderr, "unknown global option\n");
             exit(2);
@@ -162,6 +169,19 @@ int main(int argc, char **argv)
             ret = 1;
             goto xit;
         }
+        if (cspec->modifies) {
+            for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
+                if (!access(locks[i], F_OK) && !force_execution) {
+                    fprintf(stderr,
+"xend is running, which prevents xl from working correctly.\n"
+"If you still want to force the execution of xl please use the -f\n"
+"option.\n"
+                            );
+                    ret = 1;
+                    goto xit;
+                }
+            }
+        }
         ret = cspec->cmd_impl(argc, argv);
     } else if (!strcmp(cmd, "help")) {
         help(argv[1]);
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0a3d628..5ddd2da 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -21,6 +21,7 @@ struct cmd_spec {
     char *cmd_name;
     int (*cmd_impl)(int argc, char **argv);
     int can_dryrun;
+    int modifies;
     char *cmd_desc;
     char *cmd_usage;
     char *cmd_option;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6f4dd09..65bc6d6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1909,7 +1909,7 @@ void help(const char *command)
     struct cmd_spec *cmd;
 
     if (!command || !strcmp(command, "help")) {
-        printf("Usage xl [-vN] <subcommand> [args]\n\n");
+        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
         printf("xl full list of subcommands:\n\n");
         for (i = 0; i < cmdtable_len; i++) {
             printf(" %-19s ", cmd_table[i].cmd_name);
@@ -1920,7 +1920,7 @@ void help(const char *command)
     } else {
         cmd = cmdtable_lookup(command);
         if (cmd) {
-            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
+            printf("Usage: xl [-vf%s] %s %s\n\n%s.\n\n",
                    cmd->can_dryrun ? "N" : "",
                    cmd->cmd_name,
                    cmd->cmd_usage,
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index f461a2a..5509126 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -19,7 +19,7 @@
 
 struct cmd_spec cmd_table[] = {
     { "create",
-      &main_create, 1,
+      &main_create, 1, 1,
       "Create a domain from config file <filename>",
       "<ConfigFile> [options] [vars]",
       "-h                      Print this help.\n"
@@ -33,7 +33,7 @@ struct cmd_spec cmd_table[] = {
       "-e                      Do not wait in the background for the death of the domain."
     },
     { "config-update",
-      &main_config_update, 1,
+      &main_config_update, 1, 1,
       "Update a running domain's saved configuration, used when rebuilding "
       "the domain after reboot",
       "<Domain> <ConfigFile> [options] [vars]",
@@ -42,7 +42,7 @@ struct cmd_spec cmd_table[] = {
       "-d                      Enable debug messages.\n"
     },
     { "list",
-      &main_list, 0,
+      &main_list, 0, 0,
       "List information about all/some domains",
       "[options] [Domain]\n",
       "-l, --long              Output all VM details\n"
@@ -50,12 +50,12 @@ struct cmd_spec cmd_table[] = {
       "-Z, --context           Prints out security context"
     },
     { "destroy",
-      &main_destroy, 0,
+      &main_destroy, 0, 1,
       "Terminate a domain immediately",
       "<Domain>",
     },
     { "shutdown",
-      &main_shutdown, 0,
+      &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-w                      Wait for guest to shutdown.\n"
     },
     { "reboot",
-      &main_reboot, 0,
+      &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -72,44 +72,44 @@ struct cmd_spec cmd_table[] = {
       "                        no PV drivers.\n"
     },
     { "pci-attach",
-      &main_pciattach, 0,
+      &main_pciattach, 0, 1,
       "Insert a new pass-through pci device",
       "<Domain> <BDF> [Virtual Slot]",
     },
     { "pci-detach",
-      &main_pcidetach, 0,
+      &main_pcidetach, 0, 1,
       "Remove a domain's pass-through pci device",
       "<Domain> <BDF>",
     },
     { "pci-list",
-      &main_pcilist, 0,
+      &main_pcilist, 0, 0,
       "List pass-through pci devices for a domain",
       "<Domain>",
     },
     { "pci-list-assignable-devices",
-      &main_pcilist_assignable, 0,
+      &main_pcilist_assignable, 0, 0,
       "List all the assignable pci devices",
       "",
     },
     { "pause",
-      &main_pause, 0,
+      &main_pause, 0, 1,
       "Pause execution of a domain",
       "<Domain>",
     },
     { "unpause",
-      &main_unpause, 0,
+      &main_unpause, 0, 1,
       "Unpause a paused domain",
       "<Domain>",
     },
     { "console",
-      &main_console, 0,
+      &main_console, 0, 0,
       "Attach to domain's console",
       "[options] <Domain>\n"
       "-t <type>       console type, pv or serial\n"
       "-n <number>     console number"
     },
     { "vncviewer",
-      &main_vncviewer, 0,
+      &main_vncviewer, 0, 0,
       "Attach to domain's VNC server.",
       "[options] <Domain>\n"
       "--autopass               Pass VNC password to viewer via stdin and\n"
@@ -117,14 +117,14 @@ struct cmd_spec cmd_table[] = {
       "--vncviewer-autopass     (consistency alias for --autopass)"
     },
     { "save",
-      &main_save, 0,
+      &main_save, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <CheckpointFile> [<ConfigFile>]",
       "-h  Print this help.\n"
       "-c  Leave domain running after creating the snapshot."
     },
     { "migrate",
-      &main_migrate, 0,
+      &main_migrate, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <host>",
       "-h              Print this help.\n"
@@ -136,12 +136,12 @@ struct cmd_spec cmd_table[] = {
       "                of the domain."
     },
     { "dump-core",
-      &main_dump_core, 0,
+      &main_dump_core, 0, 1,
       "Core dump a domain",
       "<Domain> <filename>"
     },
     { "restore",
-      &main_restore, 0,
+      &main_restore, 0, 1,
       "Restore a domain from a saved state",
       "[options] [<ConfigFile>] <CheckpointFile>",
       "-h  Print this help.\n"
@@ -150,68 +150,68 @@ struct cmd_spec cmd_table[] = {
       "-d  Enable debug messages."
     },
     { "migrate-receive",
-      &main_migrate_receive, 0,
+      &main_migrate_receive, 0, 1,
       "Restore a domain from a saved state",
       "- for internal use only",
     },
     { "cd-insert",
-      &main_cd_insert, 0,
+      &main_cd_insert, 0, 1,
       "Insert a cdrom into a guest's cd drive",
       "<Domain> <VirtualDevice> <type:path>",
     },
     { "cd-eject",
-      &main_cd_eject, 0,
+      &main_cd_eject, 0, 1,
       "Eject a cdrom from a guest's cd drive",
       "<Domain> <VirtualDevice>",
     },
     { "mem-max",
-      &main_memmax, 0,
+      &main_memmax, 0, 1,
       "Set the maximum amount reservation for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "mem-set",
-      &main_memset, 0,
+      &main_memset, 0, 1,
       "Set the current memory usage for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "button-press",
-      &main_button_press, 0,
+      &main_button_press, 0, 1,
       "Indicate an ACPI button press to the domain",
       "<Domain> <Button>",
       "<Button> may be 'power' or 'sleep'."
     },
     { "vcpu-list",
-      &main_vcpulist, 0,
+      &main_vcpulist, 0, 0,
       "List the VCPUs for all/some domains",
       "[Domain, ...]",
     },
     { "vcpu-pin",
-      &main_vcpupin, 0,
+      &main_vcpupin, 0, 1,
       "Set which CPUs a VCPU can use",
       "<Domain> <VCPU|all> <CPUs|all>",
     },
     { "vcpu-set",
-      &main_vcpuset, 0,
+      &main_vcpuset, 0, 1,
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
     { "list-vm",
-      &main_list_vm, 0,
+      &main_list_vm, 0, 0,
       "List the VMs,without DOM0",
       "",
     },
     { "info",
-      &main_info, 0,
+      &main_info, 0, 0,
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
     { "sharing",
-      &main_sharing, 0,
+      &main_sharing, 0, 0,
       "Get information about page sharing",
       "[Domain]", 
     },
     { "sched-credit",
-      &main_sched_credit, 0,
+      &main_sched_credit, 0, 1,
       "Get/set credit scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
@@ -223,7 +223,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
-      &main_sched_credit2, 0,
+      &main_sched_credit2, 0, 1,
       "Get/set credit2 scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -231,7 +231,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "sched-sedf",
-      &main_sched_sedf, 0,
+      &main_sched_sedf, 0, 1,
       "Get/set sedf scheduler parameters",
       "[options]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -247,109 +247,109 @@ struct cmd_spec cmd_table[] = {
       "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
-      &main_domid, 0,
+      &main_domid, 0, 0,
       "Convert a domain name to domain id",
       "<DomainName>",
     },
     { "domname",
-      &main_domname, 0,
+      &main_domname, 0, 0,
       "Convert a domain id to domain name",
       "<DomainId>",
     },
     { "rename",
-      &main_rename, 0,
+      &main_rename, 0, 1,
       "Rename a domain",
       "<Domain> <NewDomainName>",
     },
     { "trigger",
-      &main_trigger, 0,
+      &main_trigger, 0, 1,
       "Send a trigger to a domain",
       "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
     },
     { "sysrq",
-      &main_sysrq, 0,
+      &main_sysrq, 0, 1,
       "Send a sysrq to a domain",
       "<Domain> <letter>",
     },
     { "debug-keys",
-      &main_debug_keys, 0,
+      &main_debug_keys, 0, 1,
       "Send debug keys to Xen",
       "<Keys>",
     },
     { "dmesg",
-      &main_dmesg, 0,
+      &main_dmesg, 0, 0,
       "Read and/or clear dmesg buffer",
       "[-c]",
       "  -c                        Clear dmesg buffer as well as printing it",
     },
     { "top",
-      &main_top, 0,
+      &main_top, 0, 0,
       "Monitor a host and the domains in real time",
       "",
     },
     { "network-attach",
-      &main_networkattach, 0,
+      &main_networkattach, 0, 1,
       "Create a new virtual network device",
       "<Domain> [type=<type>] [mac=<mac>] [bridge=<bridge>] "
       "[ip=<ip>] [script=<script>] [backend=<BackDomain>] [vifname=<name>] "
       "[rate=<rate>] [model=<model>] [accel=<accel>]",
     },
     { "network-list",
-      &main_networklist, 0,
+      &main_networklist, 0, 0,
       "List virtual network interfaces for a domain",
       "<Domain(s)>",
     },
     { "network-detach",
-      &main_networkdetach, 0,
+      &main_networkdetach, 0, 1,
       "Destroy a domain's virtual network device",
       "<Domain> <DevId|mac>",
     },
     { "block-attach",
-      &main_blockattach, 1,
+      &main_blockattach, 1, 1,
       "Create a new virtual block device",
       "<Domain> <disk-spec-component(s)>...",
     },
     { "block-list",
-      &main_blocklist, 0,
+      &main_blocklist, 0, 0,
       "List virtual block devices for a domain",
       "<Domain(s)>",
     },
     { "block-detach",
-      &main_blockdetach, 0,
+      &main_blockdetach, 0, 1,
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
     { "uptime",
-      &main_uptime, 0,
+      &main_uptime, 0, 0,
       "Print uptime for all/some domains",
       "[-s] [Domain]",
     },
     { "tmem-list",
-      &main_tmem_list, 0,
+      &main_tmem_list, 0, 0,
       "List tmem pools",
       "[-l] [<Domain>|-a]",
       "  -l                             List tmem stats",
     },
     { "tmem-freeze",
-      &main_tmem_freeze, 0,
+      &main_tmem_freeze, 0, 1,
       "Freeze tmem pools",
       "[<Domain>|-a]",
       "  -a                             Freeze all tmem",
     },
     { "tmem-destroy",
-      &main_tmem_destroy, 0,
+      &main_tmem_destroy, 0, 1,
       "Destroy tmem pools",
       "[<Domain>|-a]",
       "  -a                             Destroy all tmem",
     },
     { "tmem-thaw",
-      &main_tmem_thaw, 0,
+      &main_tmem_thaw, 0, 1,
       "Thaw tmem pools",
       "[<Domain>|-a]",
       "  -a                             Thaw all tmem",
     },
     { "tmem-set",
-      &main_tmem_set, 0,
+      &main_tmem_set, 0, 1,
       "Change tmem settings",
       "[<Domain>|-a] [-w[=WEIGHT]|-c[=CAP]|-p[=COMPRESS]]",
       "  -a                             Operate on all tmem\n"
@@ -358,7 +358,7 @@ struct cmd_spec cmd_table[] = {
       "  -p COMPRESS                    Compress (int)",
     },
     { "tmem-shared-auth",
-      &main_tmem_shared_auth, 0,
+      &main_tmem_shared_auth, 0, 1,
       "De/authenticate shared tmem pool",
       "[<Domain>|-a] [-u[=UUID] [-A[=AUTH]",
       "  -a                             Authenticate for all tmem pools\n"
@@ -367,12 +367,12 @@ struct cmd_spec cmd_table[] = {
       "  -A AUTH                        0=auth,1=deauth",
     },
     { "tmem-freeable",
-      &main_tmem_freeable, 0,
+      &main_tmem_freeable, 0, 0,
       "Get information about how much freeable memory (MB) is in-use by tmem",
       "",
     },
     { "cpupool-create",
-      &main_cpupoolcreate, 1,
+      &main_cpupoolcreate, 1, 1,
       "Create a CPU pool based an ConfigFile",
       "[options] <ConfigFile> [vars]",
       "-h, --help                   Print this help.\n"
@@ -381,53 +381,53 @@ struct cmd_spec cmd_table[] = {
       "                              (deprecated in favour of global -N option)."
     },
     { "cpupool-list",
-      &main_cpupoollist, 0,
+      &main_cpupoollist, 0, 0,
       "List CPU pools on host",
       "[-c|--cpus] [<CPU Pool>]",
       "-c, --cpus                     Output list of CPUs used by a pool"
     },
     { "cpupool-destroy",
-      &main_cpupooldestroy, 0,
+      &main_cpupooldestroy, 0, 1,
       "Deactivates a CPU pool",
       "<CPU Pool>",
     },
     { "cpupool-rename",
-      &main_cpupoolrename, 0,
+      &main_cpupoolrename, 0, 1,
       "Renames a CPU pool",
       "<CPU Pool> <new name>",
     },
     { "cpupool-cpu-add",
-      &main_cpupoolcpuadd, 0,
+      &main_cpupoolcpuadd, 0, 1,
       "Adds a CPU to a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-cpu-remove",
-      &main_cpupoolcpuremove, 0,
+      &main_cpupoolcpuremove, 0, 1,
       "Removes a CPU from a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-migrate",
-      &main_cpupoolmigrate, 0,
+      &main_cpupoolmigrate, 0, 1,
       "Moves a domain into a CPU pool",
       "<Domain> <CPU Pool>",
     },
     { "cpupool-numa-split",
-      &main_cpupoolnumasplit, 0,
+      &main_cpupoolnumasplit, 0, 1,
       "Splits up the machine into one CPU pool per NUMA node",
       "",
     },
     { "getenforce",
-      &main_getenforce, 0,
+      &main_getenforce, 0, 0,
       "Returns the current enforcing mode of the Flask Xen security module",
       "",
     },
     { "setenforce",
-      &main_setenforce, 0,
+      &main_setenforce, 0, 1,
       "Sets the current enforcing mode of the Flask Xen security module",
       "<1|0|Enforcing|Permissive>",
     },
     { "loadpolicy",
-      &main_loadpolicy, 0,
+      &main_loadpolicy, 0, 1,
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMkBJ-000569-SP; Tue, 24 Apr 2012 18:09:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMkBI-00055h-KX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:09:40 +0000
Received: from [85.158.139.83:54280] by server-3.bemta-5.messagelabs.com id
	59/8D-25237-36CE69F4; Tue, 24 Apr 2012 18:09:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335290979!25232867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4111 invoked from network); 24 Apr 2012 18:09:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:09:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:08:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:08:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMkAG-0007W3-KI; Tue, 24 Apr 2012 18:08:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMkAG-0000Ps-GO;
	Tue, 24 Apr 2012 19:08:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.60449.668898.21825@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:08:33 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v2] libxl: prevent xl from running if xend is running."):
> Prevent xl from doing any operation if xend daemon is running. That
> prevents bugs that happened when xl and xend raced to close a domain.

Thanks, but I'm afraid this needs a refresh.  I recommend you wait
until tomorrow.  I'm nearly at the end of my huge queue...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMkBJ-000569-SP; Tue, 24 Apr 2012 18:09:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMkBI-00055h-KX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:09:40 +0000
Received: from [85.158.139.83:54280] by server-3.bemta-5.messagelabs.com id
	59/8D-25237-36CE69F4; Tue, 24 Apr 2012 18:09:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335290979!25232867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4111 invoked from network); 24 Apr 2012 18:09:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 18:09:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12114567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 18:08:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 19:08:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMkAG-0007W3-KI; Tue, 24 Apr 2012 18:08:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMkAG-0000Ps-GO;
	Tue, 24 Apr 2012 19:08:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20374.60449.668898.21825@mariner.uk.xensource.com>
Date: Tue, 24 Apr 2012 19:08:33 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v2] libxl: prevent xl from running if xend is running."):
> Prevent xl from doing any operation if xend daemon is running. That
> prevents bugs that happened when xl and xend raced to close a domain.

Thanks, but I'm afraid this needs a refresh.  I recommend you wait
until tomorrow.  I'm nearly at the end of my huge queue...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:26:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:26:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMkRl-0005e0-Ig; Tue, 24 Apr 2012 18:26:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMkRh-0005dv-B4
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:26:40 +0000
Received: from [85.158.143.99:36124] by server-2.bemta-4.messagelabs.com id
	1A/E2-17550-C50F69F4; Tue, 24 Apr 2012 18:26:36 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335291995!19825143!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25860 invoked from network); 24 Apr 2012 18:26:35 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 18:26:35 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 2A5901C14001;
	Tue, 24 Apr 2012 20:26:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:content-transfer-encoding:in-reply-to; s=selector1; bh=WT+rAweu
	uB8m+vPiSazDZvuTm58=; b=fXRIwzCcIrHPNEd4Jc8HS4Sniv/tgKti38H9SY4g
	C1rFgIoqe48ZTxu6E5LHLCTnUtPzkc485Le4VeTZbbpbK3JKD/vigly+XAqvcoqt
	RBsTc0Tzcf10sZtbSwdTwLkv7Zr51Aj67xtDHN30Np3n94v+MAdT7Gt7flZQTBQ4
	iK9h/ngBhBlmV2clp32m2gmTyR+U/YKDxSgmH1kAugd5u866ndJpwqpN4KNyESXR
	IGgJRD429OiXeJ3ZCXq1LPfO1oU9+UMLA5dkZvh+b6x/FUyUGvYBZYFbLEf8L8+k
	c55Buq8j8M9Tf/aRcZVLMLOPCFK3+360EEqCN2hUcXNjtUQR+GIrjOqRZC0zH8RI
	wDgsQAvyXiNbpqaDmvEFfogNOMlDY84CmPEs/kbicCIbvyZlftSMlSfrNgfaiABa
	2+tLhOTfocQFvNS4Sg1iVXDuEzOh+rznNkonJ2Y9M9T5sGDQE7tqxejeLtQb6hGz
	pQFsbMlqkBaDZ7Mf7cd78NdgM1Rbw17or4ZX84AaQZQE1KiXrRfiQo1E+Khop8FA
	ttsdnJyaREqiGgD/fsjV2HGaRw75JI0YeAzpyXGFQbEh6mE0puLBgFc/NLF3tA/Q
	70q43iIS5JzdjwpBfG24BochT+9UzTN9cWWBsJjM5KtFC199mbEoAz36WZJaLPxG
	pi8=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id E19E81C14002; Tue, 24 Apr 2012 20:26:33 +0200 (CEST)
Date: Tue, 24 Apr 2012 20:26:33 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120424182633.GA20286@bloms.de>
References: <1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20374.53940.224705.242658@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Tue, Apr 24, Ian Jackson wrote:

> Perhaps it would be better to have a single sched_params struct which
> contained all the parameters needed for any scheduler, and simply have
> them ignored by libxl for schedulers we're not using.

my first version has this type of design and then someone said that this
was not a good design and I have to use union with libxl_sched_*_params.

Anyway I think it is a good design to have one struct with all parameters
and I'am willing to implement it.


-- =

Gru=DF

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 18:26:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 18:26:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMkRl-0005e0-Ig; Tue, 24 Apr 2012 18:26:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMkRh-0005dv-B4
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 18:26:40 +0000
Received: from [85.158.143.99:36124] by server-2.bemta-4.messagelabs.com id
	1A/E2-17550-C50F69F4; Tue, 24 Apr 2012 18:26:36 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335291995!19825143!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25860 invoked from network); 24 Apr 2012 18:26:35 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 18:26:35 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 2A5901C14001;
	Tue, 24 Apr 2012 20:26:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:content-transfer-encoding:in-reply-to; s=selector1; bh=WT+rAweu
	uB8m+vPiSazDZvuTm58=; b=fXRIwzCcIrHPNEd4Jc8HS4Sniv/tgKti38H9SY4g
	C1rFgIoqe48ZTxu6E5LHLCTnUtPzkc485Le4VeTZbbpbK3JKD/vigly+XAqvcoqt
	RBsTc0Tzcf10sZtbSwdTwLkv7Zr51Aj67xtDHN30Np3n94v+MAdT7Gt7flZQTBQ4
	iK9h/ngBhBlmV2clp32m2gmTyR+U/YKDxSgmH1kAugd5u866ndJpwqpN4KNyESXR
	IGgJRD429OiXeJ3ZCXq1LPfO1oU9+UMLA5dkZvh+b6x/FUyUGvYBZYFbLEf8L8+k
	c55Buq8j8M9Tf/aRcZVLMLOPCFK3+360EEqCN2hUcXNjtUQR+GIrjOqRZC0zH8RI
	wDgsQAvyXiNbpqaDmvEFfogNOMlDY84CmPEs/kbicCIbvyZlftSMlSfrNgfaiABa
	2+tLhOTfocQFvNS4Sg1iVXDuEzOh+rznNkonJ2Y9M9T5sGDQE7tqxejeLtQb6hGz
	pQFsbMlqkBaDZ7Mf7cd78NdgM1Rbw17or4ZX84AaQZQE1KiXrRfiQo1E+Khop8FA
	ttsdnJyaREqiGgD/fsjV2HGaRw75JI0YeAzpyXGFQbEh6mE0puLBgFc/NLF3tA/Q
	70q43iIS5JzdjwpBfG24BochT+9UzTN9cWWBsJjM5KtFC199mbEoAz36WZJaLPxG
	pi8=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id E19E81C14002; Tue, 24 Apr 2012 20:26:33 +0200 (CEST)
Date: Tue, 24 Apr 2012 20:26:33 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120424182633.GA20286@bloms.de>
References: <1335197251.22133.5.camel@Solace> <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20374.53940.224705.242658@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Tue, Apr 24, Ian Jackson wrote:

> Perhaps it would be better to have a single sched_params struct which
> contained all the parameters needed for any scheduler, and simply have
> them ignored by libxl for schedulers we're not using.

my first version has this type of design and then someone said that this
was not a good design and I have to use union with libxl_sched_*_params.

Anyway I think it is a good design to have one struct with all parameters
and I'am willing to implement it.


-- =

Gru=DF

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:11:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMl8H-0006GA-F6; Tue, 24 Apr 2012 19:10:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMl8G-0006Fd-L5
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:10:36 +0000
Received: from [85.158.139.83:9260] by server-3.bemta-5.messagelabs.com id
	B5/FF-25237-BAAF69F4; Tue, 24 Apr 2012 19:10:35 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335294633!17967408!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30216 invoked from network); 24 Apr 2012 19:10:34 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 19:10:34 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id EF529102106EC;
	Tue, 24 Apr 2012 12:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 9Wix1dYxCdA3; Tue, 24 Apr 2012 12:10:30 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id B2F73102106EB;
	Tue, 24 Apr 2012 12:10:30 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 12:10:29 -0700
Message-Id: <BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7762630374162023468=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7762630374162023468==
Content-Type: multipart/alternative; boundary="Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6"


--Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 10:03 AM, Stefano Stabellini wrote:

> Could you please apply the appended patch to the qemu tree and then =
post
> the qemu log file again?


Meanwhile, here's said log with patch applied:

[root@xentest2012 xen]# more qemu-dm-finnix.log=20
domid: 1
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram =
set to 4M.
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:628
: Init blktap pipes
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:603
: Created /var/run/tap directory
Could not open /var/run/tap/qemu-read-1
char device redirected to /dev/pts/2
DEBUG blk_init 587
DEBUG blk_init 602 filename=3D/var/finnix/finnix-104.iso
DEBUG blk_init 613 protocol=3Draw
DEBUG blk_init 622
DEBUG blk_init 636
DEBUG blk_init 659
xs_read(): target get error. /local/domain/1/target.
(qemu) (qemu)=20


-Sam=

--Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 10:03 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Could you =
please apply the appended patch to the qemu tree and then post<br>the =
qemu log file =
again?<br></span></blockquote></div><br><div><br></div><div>Meanwhile, =
here's said log with patch =
applied:</div><div><br></div><div><div>[root@xentest2012 xen]# more =
qemu-dm-finnix.log&nbsp;</div><div>domid: 1</div><div>Warning: vlan 0 is =
not connected to host network</div><div>-videoram option does not work =
with cirrus vga device model. Videoram set to =
4M.</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen=
/hw/xen_blktap.c:628</div><div>: Init blktap =
pipes</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-x=
en/hw/xen_blktap.c:603</div><div>: Created /var/run/tap =
directory</div><div>Could not open =
/var/run/tap/qemu-read-1</div><div>char device redirected to =
/dev/pts/2</div><div>DEBUG blk_init 587</div><div>DEBUG blk_init 602 =
filename=3D/var/finnix/finnix-104.iso</div><div>DEBUG blk_init 613 =
protocol=3Draw</div><div>DEBUG blk_init 622</div><div>DEBUG blk_init =
636</div><div>DEBUG blk_init 659</div><div>xs_read(): target get error. =
/local/domain/1/target.</div><div>(qemu) =
(qemu)&nbsp;</div></div><div><br></div><div><br></div><div>-Sam</div></bod=
y></html>=

--Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6--


--===============7762630374162023468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7762630374162023468==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 19:11:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMl8H-0006GA-F6; Tue, 24 Apr 2012 19:10:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SMl8G-0006Fd-L5
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:10:36 +0000
Received: from [85.158.139.83:9260] by server-3.bemta-5.messagelabs.com id
	B5/FF-25237-BAAF69F4; Tue, 24 Apr 2012 19:10:35 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335294633!17967408!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30216 invoked from network); 24 Apr 2012 19:10:34 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 19:10:34 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id EF529102106EC;
	Tue, 24 Apr 2012 12:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 9Wix1dYxCdA3; Tue, 24 Apr 2012 12:10:30 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id B2F73102106EB;
	Tue, 24 Apr 2012 12:10:30 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
Date: Tue, 24 Apr 2012 12:10:29 -0700
Message-Id: <BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7762630374162023468=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7762630374162023468==
Content-Type: multipart/alternative; boundary="Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6"


--Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 24, 2012, at 10:03 AM, Stefano Stabellini wrote:

> Could you please apply the appended patch to the qemu tree and then =
post
> the qemu log file again?


Meanwhile, here's said log with patch applied:

[root@xentest2012 xen]# more qemu-dm-finnix.log=20
domid: 1
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram =
set to 4M.
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:628
: Init blktap pipes
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:603
: Created /var/run/tap directory
Could not open /var/run/tap/qemu-read-1
char device redirected to /dev/pts/2
DEBUG blk_init 587
DEBUG blk_init 602 filename=3D/var/finnix/finnix-104.iso
DEBUG blk_init 613 protocol=3Draw
DEBUG blk_init 622
DEBUG blk_init 636
DEBUG blk_init 659
xs_read(): target get error. /local/domain/1/target.
(qemu) (qemu)=20


-Sam=

--Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 24, 2012, at 10:03 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Could you =
please apply the appended patch to the qemu tree and then post<br>the =
qemu log file =
again?<br></span></blockquote></div><br><div><br></div><div>Meanwhile, =
here's said log with patch =
applied:</div><div><br></div><div><div>[root@xentest2012 xen]# more =
qemu-dm-finnix.log&nbsp;</div><div>domid: 1</div><div>Warning: vlan 0 is =
not connected to host network</div><div>-videoram option does not work =
with cirrus vga device model. Videoram set to =
4M.</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen=
/hw/xen_blktap.c:628</div><div>: Init blktap =
pipes</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-x=
en/hw/xen_blktap.c:603</div><div>: Created /var/run/tap =
directory</div><div>Could not open =
/var/run/tap/qemu-read-1</div><div>char device redirected to =
/dev/pts/2</div><div>DEBUG blk_init 587</div><div>DEBUG blk_init 602 =
filename=3D/var/finnix/finnix-104.iso</div><div>DEBUG blk_init 613 =
protocol=3Draw</div><div>DEBUG blk_init 622</div><div>DEBUG blk_init =
636</div><div>DEBUG blk_init 659</div><div>xs_read(): target get error. =
/local/domain/1/target.</div><div>(qemu) =
(qemu)&nbsp;</div></div><div><br></div><div><br></div><div>-Sam</div></bod=
y></html>=

--Apple-Mail=_B7C17A5C-AFFA-4B63-A74B-2ED70623A7F6--


--===============7762630374162023468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7762630374162023468==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 19:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlCA-0006NI-4q; Tue, 24 Apr 2012 19:14:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlC8-0006N3-Ch
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:14:36 +0000
Received: from [85.158.138.51:34802] by server-9.bemta-3.messagelabs.com id
	88/A1-26691-B9BF69F4; Tue, 24 Apr 2012 19:14:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335294874!23619768!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMjE2MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28088 invoked from network); 24 Apr 2012 19:14:34 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.119) by server-2.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 19:14:34 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 0D4191A808B;
	Tue, 24 Apr 2012 12:14:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CulHyJJTPwyDchixExnripkwE4r0YW/g2QsyXW8oOC3W
	5tk+QYOlca63jvoqfUjhzEYGuHlNN0ROCu8f44UBXyEDtIg1D+i6tq1brC/PuMg5
	i/lhg45BtyDY7wbekElBNHwDxmi1rNJ+pOK/vYfx7FdVhx7uJ2qn2r225vMyFyE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=oYS3oaoHYkGM+2hDqzXD8Zh6LaY=; b=PhDaCeWWkd0
	nlg6qOrG021KuW0JmMQch9IVk0OyANLRZYp7VN/xs3xTvGsv4jIwj963+0w86TdN
	OBrfMYqKZNA1fHzV/by63lkJSLMts5JGbfgZ8K/5JNI53byqRDPOUNhKtai6t/Zs
	9FsjZETYuX9+xo+piVgZnQBDiM1TRW7c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 9474A1A8063; 
	Tue, 24 Apr 2012 12:14:33 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5be9a05f17fd38f9c09f7e8cc73e240646b5613e
Message-Id: <5be9a05f17fd38f9c09f.1335295218@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335295217@xdev.gridcentric.ca>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:20:18 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 2] x86/mem_sharing: Fix saved mfns stat for
 failed unsharing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


If unsharing fails, the decrease of the nr_saved_mfns stat was not being
undone. This would result in an underflow of the stat, as the retry would later
decrease the counter again.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8a6f6d38cb84 -r 5be9a05f17fd xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1205,6 +1205,8 @@ int __mem_sharing_unshare_page(struct do
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
+        /* Undo dec of nr_saved_mfns, as the retry will decrease again. */
+        atomic_inc(&nr_saved_mfns);
         mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         /* Caller is responsible for placing an event

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlCA-0006NI-4q; Tue, 24 Apr 2012 19:14:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlC8-0006N3-Ch
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:14:36 +0000
Received: from [85.158.138.51:34802] by server-9.bemta-3.messagelabs.com id
	88/A1-26691-B9BF69F4; Tue, 24 Apr 2012 19:14:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335294874!23619768!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMjE2MTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28088 invoked from network); 24 Apr 2012 19:14:34 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.119) by server-2.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 19:14:34 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 0D4191A808B;
	Tue, 24 Apr 2012 12:14:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CulHyJJTPwyDchixExnripkwE4r0YW/g2QsyXW8oOC3W
	5tk+QYOlca63jvoqfUjhzEYGuHlNN0ROCu8f44UBXyEDtIg1D+i6tq1brC/PuMg5
	i/lhg45BtyDY7wbekElBNHwDxmi1rNJ+pOK/vYfx7FdVhx7uJ2qn2r225vMyFyE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=oYS3oaoHYkGM+2hDqzXD8Zh6LaY=; b=PhDaCeWWkd0
	nlg6qOrG021KuW0JmMQch9IVk0OyANLRZYp7VN/xs3xTvGsv4jIwj963+0w86TdN
	OBrfMYqKZNA1fHzV/by63lkJSLMts5JGbfgZ8K/5JNI53byqRDPOUNhKtai6t/Zs
	9FsjZETYuX9+xo+piVgZnQBDiM1TRW7c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 9474A1A8063; 
	Tue, 24 Apr 2012 12:14:33 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5be9a05f17fd38f9c09f7e8cc73e240646b5613e
Message-Id: <5be9a05f17fd38f9c09f.1335295218@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335295217@xdev.gridcentric.ca>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:20:18 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 2] x86/mem_sharing: Fix saved mfns stat for
 failed unsharing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


If unsharing fails, the decrease of the nr_saved_mfns stat was not being
undone. This would result in an underflow of the stat, as the retry would later
decrease the counter again.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8a6f6d38cb84 -r 5be9a05f17fd xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1205,6 +1205,8 @@ int __mem_sharing_unshare_page(struct do
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
+        /* Undo dec of nr_saved_mfns, as the retry will decrease again. */
+        atomic_inc(&nr_saved_mfns);
         mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         /* Caller is responsible for placing an event

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlCA-0006NT-Gf; Tue, 24 Apr 2012 19:14:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlC8-0006N2-CX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:14:36 +0000
Received: from [85.158.139.83:39248] by server-7.bemta-5.messagelabs.com id
	66/4E-16195-B9BF69F4; Tue, 24 Apr 2012 19:14:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335294874!24638911!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjIyNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12642 invoked from network); 24 Apr 2012 19:14:34 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 19:14:34 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 54A0E1A8076;
	Tue, 24 Apr 2012 12:14:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=aXNXTkQqWgxETcdupkso8s
	pn8PMbGZRcv4Oz2Qx6x4u4x+TSoTn/+9x30ija9RXza35ydLMkRLrtucoFFqTjT4
	CGslq/qwpENf8b8TJDEQH+EFE/Kz+fWt1i6JGwwlvtkQa3qS/CqR4KD5zL4Kft+W
	xMVTOok+j9Ei7oK4FIz6E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=EAS2TJkF0mMt
	wBkTJ/RtsIPqX4g=; b=c6XffWMs/AA6nu3L+GPpnfE7O0w/FA6/stwsvnItXkFm
	5uZBBWlv3M/Uo4ggHSc/68Y9uAmew4i2hZ2qH2OG2gRVWCVuC4clfVcSByA+KZMb
	+X4Aoj1JXmNeQZkyz+1PO1uaLVFwFE8pgccppNx/uLX/PDKDZa4o2MMhFAwzz9s=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id C92271A8063; 
	Tue, 24 Apr 2012 12:14:32 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335295217@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:20:17 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 2] Sharing bug fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Two small sharing bug fixes:

- Stats were going out of sync if unshare failed with ENOMEM.
- The test for a hole in the physmap in sharing_add_to_physmap was incomplete.
 This latter patch adds feedback from Tim Deegan.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_sharing.c |  2 ++
 xen/arch/x86/mm/mem_sharing.c |  7 ++++---
 xen/include/asm-x86/p2m.h     |  8 ++++++++
 3 files changed, 14 insertions(+), 3 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlCA-0006NT-Gf; Tue, 24 Apr 2012 19:14:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlC8-0006N2-CX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:14:36 +0000
Received: from [85.158.139.83:39248] by server-7.bemta-5.messagelabs.com id
	66/4E-16195-B9BF69F4; Tue, 24 Apr 2012 19:14:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335294874!24638911!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjIyNDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12642 invoked from network); 24 Apr 2012 19:14:34 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 19:14:34 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 54A0E1A8076;
	Tue, 24 Apr 2012 12:14:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=aXNXTkQqWgxETcdupkso8s
	pn8PMbGZRcv4Oz2Qx6x4u4x+TSoTn/+9x30ija9RXza35ydLMkRLrtucoFFqTjT4
	CGslq/qwpENf8b8TJDEQH+EFE/Kz+fWt1i6JGwwlvtkQa3qS/CqR4KD5zL4Kft+W
	xMVTOok+j9Ei7oK4FIz6E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=EAS2TJkF0mMt
	wBkTJ/RtsIPqX4g=; b=c6XffWMs/AA6nu3L+GPpnfE7O0w/FA6/stwsvnItXkFm
	5uZBBWlv3M/Uo4ggHSc/68Y9uAmew4i2hZ2qH2OG2gRVWCVuC4clfVcSByA+KZMb
	+X4Aoj1JXmNeQZkyz+1PO1uaLVFwFE8pgccppNx/uLX/PDKDZa4o2MMhFAwzz9s=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id C92271A8063; 
	Tue, 24 Apr 2012 12:14:32 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335295217@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:20:17 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 2] Sharing bug fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Two small sharing bug fixes:

- Stats were going out of sync if unshare failed with ENOMEM.
- The test for a hole in the physmap in sharing_add_to_physmap was incomplete.
 This latter patch adds feedback from Tim Deegan.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_sharing.c |  2 ++
 xen/arch/x86/mm/mem_sharing.c |  7 ++++---
 xen/include/asm-x86/p2m.h     |  8 ++++++++
 3 files changed, 14 insertions(+), 3 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlCB-0006Nj-T2; Tue, 24 Apr 2012 19:14:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlC9-0006NG-QX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:14:38 +0000
Received: from [85.158.138.51:34861] by server-1.bemta-3.messagelabs.com id
	7B/5E-11491-C9BF69F4; Tue, 24 Apr 2012 19:14:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335294875!23524075!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMDc4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13080 invoked from network); 24 Apr 2012 19:14:35 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 19:14:35 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id BAB9E1A808D;
	Tue, 24 Apr 2012 12:14:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=aHybriTVLnTZC0NfUS2F2IbbH9tlTZZHxYPlseLVYLBz
	8EZ/ExtfDWNSt5J4hMUUClakaP68JiALAw2tmrJNCblXydxFNXbZoeIcL2x1erKx
	oS5J4kvpeM+5kP7bhGuxzwknuY4qWrnWG6BA+hKTbENC4Dj50MSr/w5k2O4CN+s=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=T0UBglPzlRA91IxHvAPvYelK448=; b=WJpX3RnsMhD
	c1S30brCJ85Tp/qG/DTXxWHkboe9bY+kbViDIcvo7aZoauw9GRYfKLTG1lSy0k5G
	mdtR6hJZgng5UC8sF7eRzr/Ys2uSFizGI1Qz/O07jD+KzUJ2fq7tnLnL+J5tc9aN
	fbtqceV4hP5Rx9nZA8ZnK4B3825Rg7Ws=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 3DD2E1A8063; 
	Tue, 24 Apr 2012 12:14:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 51646b89b1822fe74ffb62c62fa5b4af6bc9d3a3
Message-Id: <51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335295217@xdev.gridcentric.ca>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:20:19 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 2] x86/mem_sharing: Rectify test for
 "empty" physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  7 ++++---
 xen/include/asm-x86/p2m.h     |  8 ++++++++
 2 files changed, 12 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5be9a05f17fd -r 51646b89b182 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
     if ( spage->sharing->handle != sh )
         goto err_unlock;
 
-    /* Make sure the target page is a hole in the physmap */
-    if ( mfn_valid(cmfn) ||
-         (!(p2m_is_ram(cmfn_type))) )
+    /* Make sure the target page is a hole in the physmap. These are typically
+     * p2m_mmio_dm, but also accept p2m_invalid and paged out pages. See the
+     * definition of p2m_is_hole in p2m.h. */
+    if ( !p2m_is_hole(cmfn_type) || mfn_valid(cmfn) )
     {
         ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
diff -r 5be9a05f17fd -r 51646b89b182 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -133,6 +133,13 @@ typedef unsigned int p2m_query_t;
                        | p2m_to_mask(p2m_ram_paging_in)       \
                        | p2m_to_mask(p2m_ram_shared))
 
+/* Types that represent a physmap hole that is ok to replace with a shared
+ * entry */
+#define P2M_HOLE_TYPES (p2m_to_mask(p2m_mmio_dm)        \
+                       | p2m_to_mask(p2m_invalid)       \
+                       | p2m_to_mask(p2m_ram_paging_in) \
+                       | p2m_to_mask(p2m_ram_paged))
+
 /* Grant mapping types, which map to a real machine frame in another
  * VM */
 #define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw)  \
@@ -173,6 +180,7 @@ typedef unsigned int p2m_query_t;
 
 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
+#define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
 #define p2m_is_magic(_t) (p2m_to_mask(_t) & P2M_MAGIC_TYPES)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlCB-0006Nj-T2; Tue, 24 Apr 2012 19:14:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlC9-0006NG-QX
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:14:38 +0000
Received: from [85.158.138.51:34861] by server-1.bemta-3.messagelabs.com id
	7B/5E-11491-C9BF69F4; Tue, 24 Apr 2012 19:14:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335294875!23524075!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMDc4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13080 invoked from network); 24 Apr 2012 19:14:35 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 19:14:35 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id BAB9E1A808D;
	Tue, 24 Apr 2012 12:14:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=aHybriTVLnTZC0NfUS2F2IbbH9tlTZZHxYPlseLVYLBz
	8EZ/ExtfDWNSt5J4hMUUClakaP68JiALAw2tmrJNCblXydxFNXbZoeIcL2x1erKx
	oS5J4kvpeM+5kP7bhGuxzwknuY4qWrnWG6BA+hKTbENC4Dj50MSr/w5k2O4CN+s=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=T0UBglPzlRA91IxHvAPvYelK448=; b=WJpX3RnsMhD
	c1S30brCJ85Tp/qG/DTXxWHkboe9bY+kbViDIcvo7aZoauw9GRYfKLTG1lSy0k5G
	mdtR6hJZgng5UC8sF7eRzr/Ys2uSFizGI1Qz/O07jD+KzUJ2fq7tnLnL+J5tc9aN
	fbtqceV4hP5Rx9nZA8ZnK4B3825Rg7Ws=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 3DD2E1A8063; 
	Tue, 24 Apr 2012 12:14:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 51646b89b1822fe74ffb62c62fa5b4af6bc9d3a3
Message-Id: <51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335295217@xdev.gridcentric.ca>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:20:19 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 2] x86/mem_sharing: Rectify test for
 "empty" physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  7 ++++---
 xen/include/asm-x86/p2m.h     |  8 ++++++++
 2 files changed, 12 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5be9a05f17fd -r 51646b89b182 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
     if ( spage->sharing->handle != sh )
         goto err_unlock;
 
-    /* Make sure the target page is a hole in the physmap */
-    if ( mfn_valid(cmfn) ||
-         (!(p2m_is_ram(cmfn_type))) )
+    /* Make sure the target page is a hole in the physmap. These are typically
+     * p2m_mmio_dm, but also accept p2m_invalid and paged out pages. See the
+     * definition of p2m_is_hole in p2m.h. */
+    if ( !p2m_is_hole(cmfn_type) || mfn_valid(cmfn) )
     {
         ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
diff -r 5be9a05f17fd -r 51646b89b182 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -133,6 +133,13 @@ typedef unsigned int p2m_query_t;
                        | p2m_to_mask(p2m_ram_paging_in)       \
                        | p2m_to_mask(p2m_ram_shared))
 
+/* Types that represent a physmap hole that is ok to replace with a shared
+ * entry */
+#define P2M_HOLE_TYPES (p2m_to_mask(p2m_mmio_dm)        \
+                       | p2m_to_mask(p2m_invalid)       \
+                       | p2m_to_mask(p2m_ram_paging_in) \
+                       | p2m_to_mask(p2m_ram_paged))
+
 /* Grant mapping types, which map to a real machine frame in another
  * VM */
 #define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw)  \
@@ -173,6 +180,7 @@ typedef unsigned int p2m_query_t;
 
 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
+#define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
 #define p2m_is_magic(_t) (p2m_to_mask(_t) & P2M_MAGIC_TYPES)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:25:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlM3-0006p3-0S; Tue, 24 Apr 2012 19:24:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SMlM1-0006ox-Mi
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 19:24:49 +0000
Received: from [85.158.138.51:27736] by server-7.bemta-3.messagelabs.com id
	CE/CA-03078-00EF69F4; Tue, 24 Apr 2012 19:24:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335295486!23525017!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4872 invoked from network); 24 Apr 2012 19:24:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 19:24:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OJOiLb006994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 19:24:45 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OJOib1008617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 19:24:44 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OJOh4x014253; Tue, 24 Apr 2012 14:24:44 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 12:24:43 -0700
Date: Tue, 24 Apr 2012 12:24:34 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>
Message-ID: <20120424122434.5bf077e7@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] get_page*, paging modes, shadow paging...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Tim,

The get_page*, paging modes, etc... have gotten pretty complex. It
would be tremendously helpful if you can please talk about this a bit
at xen summit. Could do it in parallel session, or main, doesn't
matter. Just going over these in introductory manner, would be great
help and highly appreciated. Are you coming to the xen summit?

Thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:25:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlM3-0006p3-0S; Tue, 24 Apr 2012 19:24:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SMlM1-0006ox-Mi
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 19:24:49 +0000
Received: from [85.158.138.51:27736] by server-7.bemta-3.messagelabs.com id
	CE/CA-03078-00EF69F4; Tue, 24 Apr 2012 19:24:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335295486!23525017!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4872 invoked from network); 24 Apr 2012 19:24:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 19:24:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3OJOiLb006994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 19:24:45 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3OJOib1008617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 19:24:44 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3OJOh4x014253; Tue, 24 Apr 2012 14:24:44 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 12:24:43 -0700
Date: Tue, 24 Apr 2012 12:24:34 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>
Message-ID: <20120424122434.5bf077e7@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] get_page*, paging modes, shadow paging...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Tim,

The get_page*, paging modes, etc... have gotten pretty complex. It
would be tremendously helpful if you can please talk about this a bit
at xen summit. Could do it in parallel session, or main, doesn't
matter. Just going over these in introductory manner, would be great
help and highly appreciated. Are you coming to the xen summit?

Thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPk-0006yd-RB; Tue, 24 Apr 2012 19:28:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPj-0006yQ-Mz
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:39 +0000
Received: from [85.158.143.99:24806] by server-2.bemta-4.messagelabs.com id
	6F/57-17550-7EEF69F4; Tue, 24 Apr 2012 19:28:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335295717!25071982!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19790 invoked from network); 24 Apr 2012 19:28:37 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 19:28:37 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 5ECBE76C072;
	Tue, 24 Apr 2012 12:28:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=eROu8z/1dIpL68q0Kn1Cbr
	RT+w3yQrmjJQxtwfr+THfQPX4tKu8jWG3u4JdkmWNzZhALcUFcudtdm08IQheVA/
	R8zqX1H6N3P62GHMPm4in+enEG/HUFZ6A/dJcw2DgSuvJBduKE2w+WDl1fNF90Y6
	pw6oIfCK7UCt9aB50uoQ8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=gYvgWqF3Js/K
	eFhnxooJbzVoBTE=; b=GhG4G/HAvUCr00JVA1wi8YodCMYJN107VZPQwO7sXuMq
	5pt+XsO534iN1nLDAsDZO+3yht5XX7DfQdfVONwM9XBO1ThkKBBqcC5DifkpkLCB
	R8kFlcwbyuiexGmHFxhvXJ0LPisn8CkrJ08ujDQBTQupx4g9+XbAnYOlzzWpfMQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 77B8076C06E; 
	Tue, 24 Apr 2012 12:28:35 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:10 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 3] x86/mm: Relieve contention of p2m lock
 on three hot paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series is motivated by recent scalability issues reported by Yhan Z Zang
from Intel.

The general pattern used is to perform a synchronized p2m query to take care of
paging in, PoD allocation or unsharing, and then take a reference to the
underlying page. The reference ensures the page can be safely mapped by the
caller as it won't be paged out. The p2m lock can then be relased and not held
while actual work is performed on the page. This reduces p2m locked critical
sections to a minimum.

The pattern is applied to page table walking and emulation of rep movs. By
checking for the bogus zero ram_gpa value on the general emulation function, we
also reduce contention derived from the p2m lock for that hot path.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/hap/guest_walk.c |   6 ++++-
 xen/arch/x86/hvm/emulate.c       |  27 +++++++---------------
 xen/arch/x86/hvm/emulate.c       |  48 +++++++++++++++++++++------------------
 3 files changed, 40 insertions(+), 41 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPk-0006yd-RB; Tue, 24 Apr 2012 19:28:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPj-0006yQ-Mz
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:39 +0000
Received: from [85.158.143.99:24806] by server-2.bemta-4.messagelabs.com id
	6F/57-17550-7EEF69F4; Tue, 24 Apr 2012 19:28:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335295717!25071982!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19790 invoked from network); 24 Apr 2012 19:28:37 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 19:28:37 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 5ECBE76C072;
	Tue, 24 Apr 2012 12:28:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=eROu8z/1dIpL68q0Kn1Cbr
	RT+w3yQrmjJQxtwfr+THfQPX4tKu8jWG3u4JdkmWNzZhALcUFcudtdm08IQheVA/
	R8zqX1H6N3P62GHMPm4in+enEG/HUFZ6A/dJcw2DgSuvJBduKE2w+WDl1fNF90Y6
	pw6oIfCK7UCt9aB50uoQ8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=gYvgWqF3Js/K
	eFhnxooJbzVoBTE=; b=GhG4G/HAvUCr00JVA1wi8YodCMYJN107VZPQwO7sXuMq
	5pt+XsO534iN1nLDAsDZO+3yht5XX7DfQdfVONwM9XBO1ThkKBBqcC5DifkpkLCB
	R8kFlcwbyuiexGmHFxhvXJ0LPisn8CkrJ08ujDQBTQupx4g9+XbAnYOlzzWpfMQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 77B8076C06E; 
	Tue, 24 Apr 2012 12:28:35 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:10 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 3] x86/mm: Relieve contention of p2m lock
 on three hot paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series is motivated by recent scalability issues reported by Yhan Z Zang
from Intel.

The general pattern used is to perform a synchronized p2m query to take care of
paging in, PoD allocation or unsharing, and then take a reference to the
underlying page. The reference ensures the page can be safely mapped by the
caller as it won't be paged out. The p2m lock can then be relased and not held
while actual work is performed on the page. This reduces p2m locked critical
sections to a minimum.

The pattern is applied to page table walking and emulation of rep movs. By
checking for the bogus zero ram_gpa value on the general emulation function, we
also reduce contention derived from the p2m lock for that hot path.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/hap/guest_walk.c |   6 ++++-
 xen/arch/x86/hvm/emulate.c       |  27 +++++++---------------
 xen/arch/x86/hvm/emulate.c       |  48 +++++++++++++++++++++------------------
 3 files changed, 40 insertions(+), 41 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPn-0006zB-0T; Tue, 24 Apr 2012 19:28:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPl-0006yk-QR
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:42 +0000
Received: from [85.158.143.35:4152] by server-1.bemta-4.messagelabs.com id
	B9/08-20925-9EEF69F4; Tue, 24 Apr 2012 19:28:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335295719!10338085!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE2NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32496 invoked from network); 24 Apr 2012 19:28:40 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 19:28:40 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 84E2C76C06E;
	Tue, 24 Apr 2012 12:28:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=qpYEfyj6Sw3gWaSA/0dR8OchB2R1+EdFfq5r+ZQuoSe8
	kbgf+WLXpaRuCqZHxqJH29J7ZKeT4nE7WQucvShIGl+8o0vlB2pZ7DMG3j3PYYTE
	cYV5LlYmCZcVVfO9WErA1yYxVYvlk4ugV+uyGUOJCHnfVMHr574OIJMPaR3p9Mk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=cYFleBHuTBe+pokw6Wn7dlPnskg=; b=l+GbqBzyHmv
	/oS4Hzre+FKsfGPXCqYTzc/Oi5lqGjlDKFki9Kjj5mWYI8CpIiOVSJ0HlPqNYW/F
	jDMUw0ZSk6DpfRCHGn2JPau2dTMOF1Ux+ncUxji5xkB2g6U1y5vt00H/yZxyLVZu
	Hr09cL0A0uuC/mA8Sqqvnxkvw4VjzVxc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id C334276C07C; 
	Tue, 24 Apr 2012 12:28:37 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2ffc676120b8b1e4c456435778df3df3ae7e1cd1
Message-Id: <2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296050@xdev.gridcentric.ca>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:12 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 3] x86/emulate: Relieve contention of p2m
 lock in emulation of rep movs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/emulate.c |  27 +++++++++------------------
 1 files changed, 9 insertions(+), 18 deletions(-)


get_two_gfns is used to query the source and target physical addresses of the
emulated rep movs. It is not necessary to hold onto the two gfn's for the
duration of the emulation: further calls down the line will do the appropriate
unsharing or paging in, and unwind correctly on failure.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 58fd70123787 -r 2ffc676120b8 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -714,25 +714,23 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
+    /* The query on the gfns is to establish the need for mmio. In the two mmio
+     * cases, a proper get_gfn for the "other" gfn will be enacted, with paging in
+     * or unsharing if necessary. In the memmove case, the gfn might change given
+     * the bytes mov'ed, and, again, proper get_gfn's will be enacted in
+     * __hvm_copy. */ 
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
                  P2M_ALLOC, &tg);
-
+    put_two_gfns(&tg);
+  
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +745,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +754,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +765,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPn-0006zB-0T; Tue, 24 Apr 2012 19:28:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPl-0006yk-QR
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:42 +0000
Received: from [85.158.143.35:4152] by server-1.bemta-4.messagelabs.com id
	B9/08-20925-9EEF69F4; Tue, 24 Apr 2012 19:28:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335295719!10338085!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE2NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32496 invoked from network); 24 Apr 2012 19:28:40 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 19:28:40 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 84E2C76C06E;
	Tue, 24 Apr 2012 12:28:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=qpYEfyj6Sw3gWaSA/0dR8OchB2R1+EdFfq5r+ZQuoSe8
	kbgf+WLXpaRuCqZHxqJH29J7ZKeT4nE7WQucvShIGl+8o0vlB2pZ7DMG3j3PYYTE
	cYV5LlYmCZcVVfO9WErA1yYxVYvlk4ugV+uyGUOJCHnfVMHr574OIJMPaR3p9Mk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=cYFleBHuTBe+pokw6Wn7dlPnskg=; b=l+GbqBzyHmv
	/oS4Hzre+FKsfGPXCqYTzc/Oi5lqGjlDKFki9Kjj5mWYI8CpIiOVSJ0HlPqNYW/F
	jDMUw0ZSk6DpfRCHGn2JPau2dTMOF1Ux+ncUxji5xkB2g6U1y5vt00H/yZxyLVZu
	Hr09cL0A0uuC/mA8Sqqvnxkvw4VjzVxc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id C334276C07C; 
	Tue, 24 Apr 2012 12:28:37 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2ffc676120b8b1e4c456435778df3df3ae7e1cd1
Message-Id: <2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296050@xdev.gridcentric.ca>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:12 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 3] x86/emulate: Relieve contention of p2m
 lock in emulation of rep movs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/emulate.c |  27 +++++++++------------------
 1 files changed, 9 insertions(+), 18 deletions(-)


get_two_gfns is used to query the source and target physical addresses of the
emulated rep movs. It is not necessary to hold onto the two gfn's for the
duration of the emulation: further calls down the line will do the appropriate
unsharing or paging in, and unwind correctly on failure.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 58fd70123787 -r 2ffc676120b8 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -714,25 +714,23 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
+    /* The query on the gfns is to establish the need for mmio. In the two mmio
+     * cases, a proper get_gfn for the "other" gfn will be enacted, with paging in
+     * or unsharing if necessary. In the memmove case, the gfn might change given
+     * the bytes mov'ed, and, again, proper get_gfn's will be enacted in
+     * __hvm_copy. */ 
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
                  P2M_ALLOC, &tg);
-
+    put_two_gfns(&tg);
+  
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +745,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +754,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +765,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPm-0006z3-Km; Tue, 24 Apr 2012 19:28:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPl-0006yQ-Dh
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:41 +0000
Received: from [85.158.143.35:22974] by server-2.bemta-4.messagelabs.com id
	A4/67-17550-9EEF69F4; Tue, 24 Apr 2012 19:28:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335295719!12494145!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTkwMTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29634 invoked from network); 24 Apr 2012 19:28:40 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.177) by server-3.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 19:28:40 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 4C9A876C079;
	Tue, 24 Apr 2012 12:28:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=u6LttD4NjxvJnfJIwtWx0tkSFYeOWvasmjaFUiZgf4pP
	dnqr5gB+odyF/ze07Sa/h0GlR1R5LrFIbcNQgbtfRzS4bJVAmHHhzFMflKDMyZfE
	mOyVgYJy04l82slNJKD+GOA/j0EfvvzpYlRGil0U4RR23xaX/E8JbFhwGoZC7Tc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=JGfiK8V8dp2X5t5ERUoHE6xHnv4=; b=FgUwOBrUCJF
	u0rVIPAF43DwTG9WdTQWOUOfx9VCcBq603JBj1RzBXvimaRL0jrhb/L3Ijl8GgCh
	1WLnQoLfGxBUtr6jckUPUifVfd8cJ8Vc8tYMbvSKY4EAoz3nEjAiNzCuXLVhJ3a/
	h8gWfscxmmSspRuTCIg0iCp4+1y2JI6Y=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id B050C76C07C; 
	Tue, 24 Apr 2012 12:28:38 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 7a7443e80b9906908dfae87a49d87d7411d18f96
Message-Id: <7a7443e80b9906908dfa.1335296053@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296050@xdev.gridcentric.ca>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:13 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 3] x86/emulation: No need to get_gfn on
	zero ram_gpa
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/emulate.c |  48 ++++++++++++++++++++++++---------------------
 1 files changed, 26 insertions(+), 22 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2ffc676120b8 -r 7a7443e80b99 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -60,33 +60,37 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    mfn_t ram_mfn = _mfn(INVALID_MFN);
     int rc;
 
-    /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
-    if ( p2m_is_paging(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn); 
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
-        return X86EMUL_RETRY;
-    }
-    if ( p2m_is_shared(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn); 
-        return X86EMUL_RETRY;
-    }
-
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
+    /* Many callers pass a stub zero ram_gpa address. */
+    if ( ram_gfn != 0 )
+    { 
+        /* Check for paged out page */
+        ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+        if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, ram_gfn);
+            put_gfn(curr->domain, ram_gfn); 
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
             return X86EMUL_RETRY;
         }
-    put_gfn(curr->domain, ram_gfn);
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(curr->domain, ram_gfn); 
+            return X86EMUL_RETRY;
+        }
+
+        /* Maintain a ref on the mfn to ensure liveness. Put the gfn
+         * to avoid potential deadlock wrt event channel lock, later. */
+        if ( mfn_valid(mfn_x(ram_mfn)) )
+            if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
+                 curr->domain) )
+            {
+                put_gfn(curr->domain, ram_gfn);
+                return X86EMUL_RETRY;
+            }
+        put_gfn(curr->domain, ram_gfn);
+    }
 
     /*
      * Weird-sized accesses have undefined behaviour: we discard writes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPm-0006z3-Km; Tue, 24 Apr 2012 19:28:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPl-0006yQ-Dh
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:41 +0000
Received: from [85.158.143.35:22974] by server-2.bemta-4.messagelabs.com id
	A4/67-17550-9EEF69F4; Tue, 24 Apr 2012 19:28:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335295719!12494145!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTkwMTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29634 invoked from network); 24 Apr 2012 19:28:40 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.177) by server-3.tower-21.messagelabs.com with SMTP;
	24 Apr 2012 19:28:40 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 4C9A876C079;
	Tue, 24 Apr 2012 12:28:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=u6LttD4NjxvJnfJIwtWx0tkSFYeOWvasmjaFUiZgf4pP
	dnqr5gB+odyF/ze07Sa/h0GlR1R5LrFIbcNQgbtfRzS4bJVAmHHhzFMflKDMyZfE
	mOyVgYJy04l82slNJKD+GOA/j0EfvvzpYlRGil0U4RR23xaX/E8JbFhwGoZC7Tc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=JGfiK8V8dp2X5t5ERUoHE6xHnv4=; b=FgUwOBrUCJF
	u0rVIPAF43DwTG9WdTQWOUOfx9VCcBq603JBj1RzBXvimaRL0jrhb/L3Ijl8GgCh
	1WLnQoLfGxBUtr6jckUPUifVfd8cJ8Vc8tYMbvSKY4EAoz3nEjAiNzCuXLVhJ3a/
	h8gWfscxmmSspRuTCIg0iCp4+1y2JI6Y=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id B050C76C07C; 
	Tue, 24 Apr 2012 12:28:38 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 7a7443e80b9906908dfae87a49d87d7411d18f96
Message-Id: <7a7443e80b9906908dfa.1335296053@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296050@xdev.gridcentric.ca>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:13 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 3] x86/emulation: No need to get_gfn on
	zero ram_gpa
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/emulate.c |  48 ++++++++++++++++++++++++---------------------
 1 files changed, 26 insertions(+), 22 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2ffc676120b8 -r 7a7443e80b99 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -60,33 +60,37 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    mfn_t ram_mfn = _mfn(INVALID_MFN);
     int rc;
 
-    /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
-    if ( p2m_is_paging(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn); 
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
-        return X86EMUL_RETRY;
-    }
-    if ( p2m_is_shared(p2mt) )
-    {
-        put_gfn(curr->domain, ram_gfn); 
-        return X86EMUL_RETRY;
-    }
-
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
+    /* Many callers pass a stub zero ram_gpa address. */
+    if ( ram_gfn != 0 )
+    { 
+        /* Check for paged out page */
+        ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+        if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, ram_gfn);
+            put_gfn(curr->domain, ram_gfn); 
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
             return X86EMUL_RETRY;
         }
-    put_gfn(curr->domain, ram_gfn);
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(curr->domain, ram_gfn); 
+            return X86EMUL_RETRY;
+        }
+
+        /* Maintain a ref on the mfn to ensure liveness. Put the gfn
+         * to avoid potential deadlock wrt event channel lock, later. */
+        if ( mfn_valid(mfn_x(ram_mfn)) )
+            if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
+                 curr->domain) )
+            {
+                put_gfn(curr->domain, ram_gfn);
+                return X86EMUL_RETRY;
+            }
+        put_gfn(curr->domain, ram_gfn);
+    }
 
     /*
      * Weird-sized accesses have undefined behaviour: we discard writes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPm-0006yw-7m; Tue, 24 Apr 2012 19:28:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPk-0006yR-02
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:40 +0000
Received: from [85.158.138.51:36643] by server-7.bemta-3.messagelabs.com id
	35/3E-03078-7EEF69F4; Tue, 24 Apr 2012 19:28:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335295718!23525385!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjA4NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19514 invoked from network); 24 Apr 2012 19:28:38 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-8.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 19:28:38 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8F16476C079;
	Tue, 24 Apr 2012 12:28:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=dhQT3xE8+A9rf4eXgEtwQgJ8WuGmhxZeJDIq1vbUn8EK
	vAp6JFnIBNDwmsCoIQ2kPXd3NHN5kCxBytomd6XlHjxdT/x4LZ4N/CGWAFy+t1Wv
	IE9QDJxI73SuGxSrttFbxYpTDmrPfNHULX+1pCXrjWR4KnoTmRpEq7Y9el4iD70=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=hd0+ebKFJu8lw/p0FXn2HniJxXk=; b=Vab+Anw0FPf
	1UcdvqYAqmE4kRvq+iA1FW4jDKKe+e9CauytJDqJV5m6ShE9s72UCbInU49bXKbB
	qrizE+qjnyVAppKQ65H+5L+2eUxTfHZTiiIoUpB897V7LVKufrtxt537gegOv4XD
	b+rOlrkXGtxgaP6uvZiRxz24TSCt7ZeQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 9B51976C06E; 
	Tue, 24 Apr 2012 12:28:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 58fd70123787dd0063fe096b72dfb802be9554a7
Message-Id: <58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296050@xdev.gridcentric.ca>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:11 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 3] x86/mm: Relieve contention for p2m lock
	in gva_to_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/hap/guest_walk.c |  6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)


We don't need to hold the p2m lock for the duration of the guest walk. We need
to ensure livenes of the top level page.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 34c7e6be9265 -r 58fd70123787 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -52,6 +52,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 {
     uint32_t missing;
     mfn_t top_mfn;
+    struct page_info *top_page;
     void *top_map;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
@@ -85,13 +86,16 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 
     /* Map the top-level table and call the tree-walker */
     ASSERT(mfn_valid(mfn_x(top_mfn)));
+    top_page = mfn_to_page(mfn_x(top_mfn));
+    ASSERT(get_page(top_page, p2m->domain));
+    __put_gfn(p2m, top_gfn);
     top_map = map_domain_page(mfn_x(top_mfn));
 #if GUEST_PAGING_LEVELS == 3
     top_map += (cr3 & ~(PAGE_MASK | 31));
 #endif
     missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map);
     unmap_domain_page(top_map);
-    __put_gfn(p2m, top_gfn);
+    put_page(top_page);
 
     /* Interpret the answer */
     if ( missing == 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:28:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlPm-0006yw-7m; Tue, 24 Apr 2012 19:28:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMlPk-0006yR-02
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:28:40 +0000
Received: from [85.158.138.51:36643] by server-7.bemta-3.messagelabs.com id
	35/3E-03078-7EEF69F4; Tue, 24 Apr 2012 19:28:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335295718!23525385!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjA4NjY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19514 invoked from network); 24 Apr 2012 19:28:38 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-8.tower-174.messagelabs.com with SMTP;
	24 Apr 2012 19:28:38 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8F16476C079;
	Tue, 24 Apr 2012 12:28:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=dhQT3xE8+A9rf4eXgEtwQgJ8WuGmhxZeJDIq1vbUn8EK
	vAp6JFnIBNDwmsCoIQ2kPXd3NHN5kCxBytomd6XlHjxdT/x4LZ4N/CGWAFy+t1Wv
	IE9QDJxI73SuGxSrttFbxYpTDmrPfNHULX+1pCXrjWR4KnoTmRpEq7Y9el4iD70=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=hd0+ebKFJu8lw/p0FXn2HniJxXk=; b=Vab+Anw0FPf
	1UcdvqYAqmE4kRvq+iA1FW4jDKKe+e9CauytJDqJV5m6ShE9s72UCbInU49bXKbB
	qrizE+qjnyVAppKQ65H+5L+2eUxTfHZTiiIoUpB897V7LVKufrtxt537gegOv4XD
	b+rOlrkXGtxgaP6uvZiRxz24TSCt7ZeQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 9B51976C06E; 
	Tue, 24 Apr 2012 12:28:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 58fd70123787dd0063fe096b72dfb802be9554a7
Message-Id: <58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296050@xdev.gridcentric.ca>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:34:11 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 3] x86/mm: Relieve contention for p2m lock
	in gva_to_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/hap/guest_walk.c |  6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)


We don't need to hold the p2m lock for the duration of the guest walk. We need
to ensure livenes of the top level page.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 34c7e6be9265 -r 58fd70123787 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -52,6 +52,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 {
     uint32_t missing;
     mfn_t top_mfn;
+    struct page_info *top_page;
     void *top_map;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
@@ -85,13 +86,16 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 
     /* Map the top-level table and call the tree-walker */
     ASSERT(mfn_valid(mfn_x(top_mfn)));
+    top_page = mfn_to_page(mfn_x(top_mfn));
+    ASSERT(get_page(top_page, p2m->domain));
+    __put_gfn(p2m, top_gfn);
     top_map = map_domain_page(mfn_x(top_mfn));
 #if GUEST_PAGING_LEVELS == 3
     top_map += (cr3 & ~(PAGE_MASK | 31));
 #endif
     missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map);
     unmap_domain_page(top_map);
-    __put_gfn(p2m, top_gfn);
+    put_page(top_page);
 
     /* Interpret the answer */
     if ( missing == 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:34:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlUk-0007Wp-Q8; Tue, 24 Apr 2012 19:33:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1SMlUi-0007Wj-Lx
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:33:48 +0000
Received: from [85.158.138.51:60115] by server-11.bemta-3.messagelabs.com id
	EF/29-18894-B10079F4; Tue, 24 Apr 2012 19:33:47 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335296025!12606957!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29939 invoked from network); 24 Apr 2012 19:33:47 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 19:33:47 -0000
Received: by yenr5 with SMTP id r5so820489yen.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 12:33:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=JEJzDxOHQkW8LGocIsa+Ii5ccggpu58Vz7F5iLABhpo=;
	b=QNz5i12iVHBraOCFN3X2xsvFedEj9Y7CWaNzhBwmZBd+y+ljC1OJ3ipC7md1XHCG0G
	EEnkElLzW0J8MpvCqBYB1UXR3X36bfBLTO7ngqMwmHc5S+ZOkzIvCNuO0KL5XLCxiyY7
	bCvIrxJnM1FnNNlvFExe189HGWVJAW5Xp3ezyNjZIdtnxMCWWavtIhQFRjhb/aFE+6Du
	JNnmoxz2jUU4mYgZaifGysez7OuSo7b3SO2SANlVuiqWMHL/EWQU/NoZx5XjBvzsdK8I
	FlEHdvkZjHDyXowSVOPwJNQDeuk0VDm7F8xu5f31dEi+RjGaXcx3ludvIMA+ijEVguK8
	inqg==
Received: by 10.50.153.132 with SMTP id vg4mr11580410igb.2.1335296025099;
	Tue, 24 Apr 2012 12:33:45 -0700 (PDT)
Received: from [192.168.7.211] ([206.223.182.18])
	by mx.google.com with ESMTPS id iu5sm36573560igc.14.2012.04.24.12.33.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Apr 2012 12:33:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1278bd7674af27a3858dae12a5f16d65.squirrel@webmail.lagarcavilla.org>
Date: Tue, 24 Apr 2012 15:33:43 -0400
Message-Id: <5DCFDB70-F723-4FB3-97F1-BCC217377A4C@gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
	<20120418153530.GM7013@ocelot.phlegethon.org>
	<1278bd7674af27a3858dae12a5f16d65.squirrel@webmail.lagarcavilla.org>
To: andres@lagarcavilla.org
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQm0hQrQgNGyJ70OamnVuic1Ey0vXZ0J5j9QbcAi+rUS9rBudTINuJ8srRnY70Buio9T+7WY
Cc: adin@gridcentric.ca, keir.xen@gmail.com, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages
	with many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 18, 2012, at 12:18 PM, Andres Lagar-Cavilla wrote:

>> At 10:16 -0400 on 12 Apr (1334225774), Andres Lagar-Cavilla wrote:
>>> xen/arch/x86/mm/mem_sharing.c     |  170
>>> +++++++++++++++++++++++++++++++++++--
>>> xen/include/asm-x86/mem_sharing.h |   13 ++-
>>> 2 files changed, 169 insertions(+), 14 deletions(-)
>>> 
>>> 
>>> For shared frames that have many references, the doubly-linked list used
>>> to
>>> store the rmap results in costly scans during unshare operations. To
>>> alleviate
>>> the overhead, replace the linked list by a hash table. However, hash
>>> tables are
>>> space-intensive, so only use them for pages that have "many" (arbitrary
>>> threshold) references.
>>> 
>>> Unsharing is heaviliy exercised during domain destroy. In experimental
>>> testing,
>>> for a domain that points over 100 thousand pages to the same shared
>>> frame,
>>> domain destruction dropped from over 7 minutes(!) to less than two
>>> seconds.
>> 
>> If you're adding a new datastructure, would it be better to use a tree,
>> since the keys are easily sorted?  Xen already has include/xen/rbtree.h.
>> It would have a higher per-entry overhead but you wouldn't need to keep
>> the list datastructure as well for the light-sharing case.
> 
> My main concern is space. A regular case we deal with is four hundred
> thousand shared frames, most with roughly a hundred <domid,gfn>s they
> back, some with over a hundred thousand, a few with less than ten
> thousand. That's a lot of heap memory for rb trees and nodes! I find O(n)
> on less than 256 to be easily tolerable, as well as spending an extra page
> only when we're saving thousands.

I've looked into rb and my initial opinion stands. I'm confident I'm getting a better space/search-big-O tradeoff with my hash table instead of an rb tree. I have not, however, conducted a thorough profiling, given the time constraints for 4.2. That is certainly doable after that window closes.

I will resubmit the series taking into account your comment about splitting the initial patch.

Thanks!
Andres

> 
> 
> Nevertheless I'll look into rb tree. Whose only consumer is tmem, if I'm
> not mistaken. It doesn't seem like pool objects grow to contain so many
> pages, but I could be wrong.
> 
> Andres
>> 
>> Tim.
>> 
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:34:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlUk-0007Wp-Q8; Tue, 24 Apr 2012 19:33:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1SMlUi-0007Wj-Lx
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:33:48 +0000
Received: from [85.158.138.51:60115] by server-11.bemta-3.messagelabs.com id
	EF/29-18894-B10079F4; Tue, 24 Apr 2012 19:33:47 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335296025!12606957!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29939 invoked from network); 24 Apr 2012 19:33:47 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 19:33:47 -0000
Received: by yenr5 with SMTP id r5so820489yen.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 12:33:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=JEJzDxOHQkW8LGocIsa+Ii5ccggpu58Vz7F5iLABhpo=;
	b=QNz5i12iVHBraOCFN3X2xsvFedEj9Y7CWaNzhBwmZBd+y+ljC1OJ3ipC7md1XHCG0G
	EEnkElLzW0J8MpvCqBYB1UXR3X36bfBLTO7ngqMwmHc5S+ZOkzIvCNuO0KL5XLCxiyY7
	bCvIrxJnM1FnNNlvFExe189HGWVJAW5Xp3ezyNjZIdtnxMCWWavtIhQFRjhb/aFE+6Du
	JNnmoxz2jUU4mYgZaifGysez7OuSo7b3SO2SANlVuiqWMHL/EWQU/NoZx5XjBvzsdK8I
	FlEHdvkZjHDyXowSVOPwJNQDeuk0VDm7F8xu5f31dEi+RjGaXcx3ludvIMA+ijEVguK8
	inqg==
Received: by 10.50.153.132 with SMTP id vg4mr11580410igb.2.1335296025099;
	Tue, 24 Apr 2012 12:33:45 -0700 (PDT)
Received: from [192.168.7.211] ([206.223.182.18])
	by mx.google.com with ESMTPS id iu5sm36573560igc.14.2012.04.24.12.33.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Apr 2012 12:33:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1278bd7674af27a3858dae12a5f16d65.squirrel@webmail.lagarcavilla.org>
Date: Tue, 24 Apr 2012 15:33:43 -0400
Message-Id: <5DCFDB70-F723-4FB3-97F1-BCC217377A4C@gridcentric.ca>
References: <patchbomb.1334240171@xdev.gridcentric.ca>
	<7b606c043208d98d218b.1334240174@xdev.gridcentric.ca>
	<20120418153530.GM7013@ocelot.phlegethon.org>
	<1278bd7674af27a3858dae12a5f16d65.squirrel@webmail.lagarcavilla.org>
To: andres@lagarcavilla.org
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQm0hQrQgNGyJ70OamnVuic1Ey0vXZ0J5j9QbcAi+rUS9rBudTINuJ8srRnY70Buio9T+7WY
Cc: adin@gridcentric.ca, keir.xen@gmail.com, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages
	with many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Apr 18, 2012, at 12:18 PM, Andres Lagar-Cavilla wrote:

>> At 10:16 -0400 on 12 Apr (1334225774), Andres Lagar-Cavilla wrote:
>>> xen/arch/x86/mm/mem_sharing.c     |  170
>>> +++++++++++++++++++++++++++++++++++--
>>> xen/include/asm-x86/mem_sharing.h |   13 ++-
>>> 2 files changed, 169 insertions(+), 14 deletions(-)
>>> 
>>> 
>>> For shared frames that have many references, the doubly-linked list used
>>> to
>>> store the rmap results in costly scans during unshare operations. To
>>> alleviate
>>> the overhead, replace the linked list by a hash table. However, hash
>>> tables are
>>> space-intensive, so only use them for pages that have "many" (arbitrary
>>> threshold) references.
>>> 
>>> Unsharing is heaviliy exercised during domain destroy. In experimental
>>> testing,
>>> for a domain that points over 100 thousand pages to the same shared
>>> frame,
>>> domain destruction dropped from over 7 minutes(!) to less than two
>>> seconds.
>> 
>> If you're adding a new datastructure, would it be better to use a tree,
>> since the keys are easily sorted?  Xen already has include/xen/rbtree.h.
>> It would have a higher per-entry overhead but you wouldn't need to keep
>> the list datastructure as well for the light-sharing case.
> 
> My main concern is space. A regular case we deal with is four hundred
> thousand shared frames, most with roughly a hundred <domid,gfn>s they
> back, some with over a hundred thousand, a few with less than ten
> thousand. That's a lot of heap memory for rb trees and nodes! I find O(n)
> on less than 256 to be easily tolerable, as well as spending an extra page
> only when we're saving thousands.

I've looked into rb and my initial opinion stands. I'm confident I'm getting a better space/search-big-O tradeoff with my hash table instead of an rb tree. I have not, however, conducted a thorough profiling, given the time constraints for 4.2. That is certainly doable after that window closes.

I will resubmit the series taking into account your comment about splitting the initial patch.

Thanks!
Andres

> 
> 
> Nevertheless I'll look into rb tree. Whose only consumer is tmem, if I'm
> not mistaken. It doesn't seem like pool objects grow to contain so many
> pages, but I could be wrong.
> 
> Andres
>> 
>> Tim.
>> 
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:35:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlWL-0007cQ-Tq; Tue, 24 Apr 2012 19:35:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMlWK-0007br-0S
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:35:28 +0000
Received: from [193.109.254.147:37296] by server-1.bemta-14.messagelabs.com id
	89/37-29372-F70079F4; Tue, 24 Apr 2012 19:35:27 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335296125!6127676!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8077 invoked from network); 24 Apr 2012 19:35:26 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 19:35:26 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 467E31C14001;
	Tue, 24 Apr 2012 21:35:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=Qhxt6XA8prhQqOzskFiD4VqddDg=; b=kF
	VdB4Kalo+PZUVN+aw9KiruyJboJNIQbo4KtDX+wtZbydg3eIJSH2HZq19C4/JVU3
	HeNkSggdz9uT/DUwTKLeETSQoq6qxyM52Xb3gkwC8Z+Tn5ZK4g02ABIg/zjpT0EV
	nI5apVPnjiykq2/R2vQGKwyGHo0rMQLEHqDDBRkWwJaD/bXHTWRVLQ3SWSE134ZP
	E6+39nA5470odHUOYOcR4MlcSLXSLwf1OtgzyheCb9KB4S66334v/jQc41Yin+iK
	xAUas3oMt/7kVqUUnVpb24idNNbvwy2tOaDPxiJAf7qFOZ/t1Hx/bIVoLbqAVb/T
	UyCz2Yt1s0fv8nOnKET7qU1f7a1ZyEMAd/l/D1vZNlLyb+8z1q6+Aw5JBtFJ6B+z
	jz/Z9noIt1aMl+Ygdwt/R1j7XusX1aXh29CBoKiJ/fTi/s5GvR/zDBYXCKiuMxSI
	XZJ5JUkAhJ6sG3rqUzW3YU7RYOgN/2Jn6q7FljEQjEXyZMRFXuRUArTreaKT1xyz
	enh8o3iq8/ftVbQb4f8j1G6lydi/PpiZXCnXGKegkoxLYxnLXoMaaOfPrqFuOnWy
	YsPGnKwmE7B1wQrXAkumVoe9mGUjTR65jFy+95izFsm57TIeee7kg4fTYMGJusSD
	w9IKnrpxnAUBEvMFeHQQz01NthGRByxS9UifnUocQ=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 296D01C14002; Tue, 24 Apr 2012 21:35:25 +0200 (CEST)
Date: Tue, 24 Apr 2012 21:35:25 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dieter Bloms <dieter@bloms.de>
Message-ID: <20120424193524.GA20565@bloms.de>
References: <20120423193518.GA16134@bloms.de> <1335247525.2397.4.camel@Abyss>
	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
	<20120424182633.GA20286@bloms.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK"
Content-Disposition: inline
In-Reply-To: <20120424182633.GA20286@bloms.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

On Tue, Apr 24, Dieter Bloms wrote:

> Hi,
> 
> On Tue, Apr 24, Ian Jackson wrote:
> 
> > Perhaps it would be better to have a single sched_params struct which
> > contained all the parameters needed for any scheduler, and simply have
> > them ignored by libxl for schedulers we're not using.

...

> Anyway I think it is a good design to have one struct with all parameters
> and I'am willing to implement it.

I've made a new patch.
Maybe it fit all your needs.


-- 
best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--YZ5djTAD1cGYuMQK
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"

libxl: set domain scheduling parameters while creating the domU

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index e2cd251..b0c8064 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use. Default behavior is
 (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
 
+=item B<cpu_weight=WEIGHT>
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host.
+Legal weights range from 1 to 65535 and the default is 256.
+Can be set for credit, credit2 and sedf scheduler.
+
+=item B<cap=N>
+
+The cap optionally fixes the maximum amount of CPU a domain will be
+able to consume, even if the host system has idle CPU cycles.
+The cap is expressed in percentage of one physical CPU:
+100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc.
+The default, 0, means there is no upper cap.
+Can be set for the credit and credit2 scheduler.
+
+=item B<period=NANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. This means every period
+the domain gets cpu time defined in slice.
+Can be set for sedf scheduler.
+
+=item B<slice=NANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. it defines the time 
+a domain get every period time.
+Can be set for sedf scheduler.
+
+=item B<latency=N>
+
+Scaled period if domain is doing heavy I/O.
+Can be set for sedf scheduler.
+
+=item B<extratime=BOOLEAN>
+
+Flag for allowing domain to run in extra time.
+Can be set for sedf scheduler.
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..55b033a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -42,6 +42,40 @@ libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
         return LIBXL_DOMAIN_TYPE_PV;
 }
 
+int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl_scheduler sched;
+    libxl_sched_sedf_domain sedf_info;
+    libxl_sched_credit_domain credit_info;
+    libxl_sched_credit2_domain credit2_info;
+    int ret;
+
+    sched = libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      sedf_info.period = scparams->period;
+      sedf_info.slice = scparams->slice;
+      sedf_info.latency = scparams->latency;
+      sedf_info.extratime = scparams->extratime;
+      sedf_info.weight = scparams->weight;
+      ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      credit_info.weight = scparams->weight;
+      credit_info.cap = scparams->cap;
+      ret=libxl_sched_credit_domain_set(ctx, domid, &credit_info);
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      credit2_info.weight = scparams->weight;
+      ret=libxl_sched_credit2_domain_set(ctx, domid, &credit2_info);
+      break;
+    default:
+      ret=-1;
+    }
+    return ret;
+}
+
 int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -126,6 +160,8 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents, **hvm_ents;
     int i;
 
+    libxl__sched_set_params (gc, domid, &(info->sched_params));
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..2b76b0e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -617,6 +617,7 @@ int libxl__atfork_init(libxl_ctx *ctx);
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams);
 #define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..7789327 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,17 @@ libxl_domain_create_info = Struct("domain_create_info",[
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
+libxl_sched_params = Struct("sched_params",[
+    ("weight",       integer),
+    ("cap",          integer),
+    ("tslice_ms",    integer),
+    ("ratelimit_us", integer),
+    ("period",       integer),
+    ("slice",        integer),
+    ("latency",      integer),
+    ("extratime",    integer),
+    ], dir=DIR_IN)
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -255,6 +266,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("extra_pv",         libxl_string_list),
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
+    #  parameters for all type of scheduler
+    ("sched_params",     libxl_sched_params),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..8e67307 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,23 @@ static void parse_config_data(const char *configfile_filename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->sched_params.weight = l;
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->sched_params.cap = l;
+    if (!xlu_cfg_get_long (config, "tslice_ms", &l, 0))
+        b_info->sched_params.tslice_ms = l;
+    if (!xlu_cfg_get_long (config, "ratelimit_us", &l, 0))
+        b_info->sched_params.ratelimit_us = l;
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->sched_params.period = l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->sched_params.period = l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->sched_params.period = l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->sched_params.period = l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;

--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--YZ5djTAD1cGYuMQK--


From xen-devel-bounces@lists.xen.org Tue Apr 24 19:35:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlWL-0007cQ-Tq; Tue, 24 Apr 2012 19:35:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SMlWK-0007br-0S
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:35:28 +0000
Received: from [193.109.254.147:37296] by server-1.bemta-14.messagelabs.com id
	89/37-29372-F70079F4; Tue, 24 Apr 2012 19:35:27 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335296125!6127676!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8077 invoked from network); 24 Apr 2012 19:35:26 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 19:35:26 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 467E31C14001;
	Tue, 24 Apr 2012 21:35:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=Qhxt6XA8prhQqOzskFiD4VqddDg=; b=kF
	VdB4Kalo+PZUVN+aw9KiruyJboJNIQbo4KtDX+wtZbydg3eIJSH2HZq19C4/JVU3
	HeNkSggdz9uT/DUwTKLeETSQoq6qxyM52Xb3gkwC8Z+Tn5ZK4g02ABIg/zjpT0EV
	nI5apVPnjiykq2/R2vQGKwyGHo0rMQLEHqDDBRkWwJaD/bXHTWRVLQ3SWSE134ZP
	E6+39nA5470odHUOYOcR4MlcSLXSLwf1OtgzyheCb9KB4S66334v/jQc41Yin+iK
	xAUas3oMt/7kVqUUnVpb24idNNbvwy2tOaDPxiJAf7qFOZ/t1Hx/bIVoLbqAVb/T
	UyCz2Yt1s0fv8nOnKET7qU1f7a1ZyEMAd/l/D1vZNlLyb+8z1q6+Aw5JBtFJ6B+z
	jz/Z9noIt1aMl+Ygdwt/R1j7XusX1aXh29CBoKiJ/fTi/s5GvR/zDBYXCKiuMxSI
	XZJ5JUkAhJ6sG3rqUzW3YU7RYOgN/2Jn6q7FljEQjEXyZMRFXuRUArTreaKT1xyz
	enh8o3iq8/ftVbQb4f8j1G6lydi/PpiZXCnXGKegkoxLYxnLXoMaaOfPrqFuOnWy
	YsPGnKwmE7B1wQrXAkumVoe9mGUjTR65jFy+95izFsm57TIeee7kg4fTYMGJusSD
	w9IKnrpxnAUBEvMFeHQQz01NthGRByxS9UifnUocQ=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 296D01C14002; Tue, 24 Apr 2012 21:35:25 +0200 (CEST)
Date: Tue, 24 Apr 2012 21:35:25 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Dieter Bloms <dieter@bloms.de>
Message-ID: <20120424193524.GA20565@bloms.de>
References: <20120423193518.GA16134@bloms.de> <1335247525.2397.4.camel@Abyss>
	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
	<20120424182633.GA20286@bloms.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK"
Content-Disposition: inline
In-Reply-To: <20120424182633.GA20286@bloms.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

On Tue, Apr 24, Dieter Bloms wrote:

> Hi,
> 
> On Tue, Apr 24, Ian Jackson wrote:
> 
> > Perhaps it would be better to have a single sched_params struct which
> > contained all the parameters needed for any scheduler, and simply have
> > them ignored by libxl for schedulers we're not using.

...

> Anyway I think it is a good design to have one struct with all parameters
> and I'am willing to implement it.

I've made a new patch.
Maybe it fit all your needs.


-- 
best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--YZ5djTAD1cGYuMQK
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="add_support_for_cpu_weight_config_in_xl.diff"

libxl: set domain scheduling parameters while creating the domU

the domain specific scheduling parameters like cpu_weight, cap, slice, ...
will be set during creating the domain, so this parameters can be defined
in the domain config file

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index e2cd251..b0c8064 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -112,6 +112,44 @@ List of which cpus the guest is allowed to use. Default behavior is
 (all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus
 will run on cpus 2 and 3).
 
+=item B<cpu_weight=WEIGHT>
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host.
+Legal weights range from 1 to 65535 and the default is 256.
+Can be set for credit, credit2 and sedf scheduler.
+
+=item B<cap=N>
+
+The cap optionally fixes the maximum amount of CPU a domain will be
+able to consume, even if the host system has idle CPU cycles.
+The cap is expressed in percentage of one physical CPU:
+100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc.
+The default, 0, means there is no upper cap.
+Can be set for the credit and credit2 scheduler.
+
+=item B<period=NANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. This means every period
+the domain gets cpu time defined in slice.
+Can be set for sedf scheduler.
+
+=item B<slice=NANOSECONDS>
+
+The normal EDF scheduling usage in nanoseconds. it defines the time 
+a domain get every period time.
+Can be set for sedf scheduler.
+
+=item B<latency=N>
+
+Scaled period if domain is doing heavy I/O.
+Can be set for sedf scheduler.
+
+=item B<extratime=BOOLEAN>
+
+Flag for allowing domain to run in extra time.
+Can be set for sedf scheduler.
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0bdd654..55b033a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -42,6 +42,40 @@ libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
         return LIBXL_DOMAIN_TYPE_PV;
 }
 
+int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl_scheduler sched;
+    libxl_sched_sedf_domain sedf_info;
+    libxl_sched_credit_domain credit_info;
+    libxl_sched_credit2_domain credit2_info;
+    int ret;
+
+    sched = libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      sedf_info.period = scparams->period;
+      sedf_info.slice = scparams->slice;
+      sedf_info.latency = scparams->latency;
+      sedf_info.extratime = scparams->extratime;
+      sedf_info.weight = scparams->weight;
+      ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      credit_info.weight = scparams->weight;
+      credit_info.cap = scparams->cap;
+      ret=libxl_sched_credit_domain_set(ctx, domid, &credit_info);
+      break;
+    case LIBXL_SCHEDULER_CREDIT2:
+      credit2_info.weight = scparams->weight;
+      ret=libxl_sched_credit2_domain_set(ctx, domid, &credit2_info);
+      break;
+    default:
+      ret=-1;
+    }
+    return ret;
+}
+
 int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -126,6 +160,8 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
     char **ents, **hvm_ents;
     int i;
 
+    libxl__sched_set_params (gc, domid, &(info->sched_params));
+
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a4b933b..2b76b0e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -617,6 +617,7 @@ int libxl__atfork_init(libxl_ctx *ctx);
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams);
 #define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5cf9708..7789327 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,17 @@ libxl_domain_create_info = Struct("domain_create_info",[
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
+libxl_sched_params = Struct("sched_params",[
+    ("weight",       integer),
+    ("cap",          integer),
+    ("tslice_ms",    integer),
+    ("ratelimit_us", integer),
+    ("period",       integer),
+    ("slice",        integer),
+    ("latency",      integer),
+    ("extratime",    integer),
+    ], dir=DIR_IN)
+
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
 # by libxl_domain_build/restore. If either of these are never called
@@ -255,6 +266,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("extra_pv",         libxl_string_list),
     # extra parameters pass directly to qemu for HVM guest, NULL terminated
     ("extra_hvm",        libxl_string_list),
+    #  parameters for all type of scheduler
+    ("sched_params",     libxl_sched_params),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..8e67307 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -587,6 +587,23 @@ static void parse_config_data(const char *configfile_filename_report,
     libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+        b_info->sched_params.weight = l;
+    if (!xlu_cfg_get_long (config, "cap", &l, 0))
+        b_info->sched_params.cap = l;
+    if (!xlu_cfg_get_long (config, "tslice_ms", &l, 0))
+        b_info->sched_params.tslice_ms = l;
+    if (!xlu_cfg_get_long (config, "ratelimit_us", &l, 0))
+        b_info->sched_params.ratelimit_us = l;
+    if (!xlu_cfg_get_long (config, "period", &l, 0))
+        b_info->sched_params.period = l;
+    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        b_info->sched_params.period = l;
+    if (!xlu_cfg_get_long (config, "latency", &l, 0))
+        b_info->sched_params.period = l;
+    if (!xlu_cfg_get_long (config, "extratime", &l, 0))
+        b_info->sched_params.period = l;
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;

--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--YZ5djTAD1cGYuMQK--


From xen-devel-bounces@lists.xen.org Tue Apr 24 19:35:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlWJ-0007bm-AZ; Tue, 24 Apr 2012 19:35:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMlWH-0007bf-Rt
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:35:26 +0000
Received: from [85.158.143.99:49041] by server-1.bemta-4.messagelabs.com id
	53/FB-20925-D70079F4; Tue, 24 Apr 2012 19:35:25 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335296123!19830610!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6493 invoked from network); 24 Apr 2012 19:35:24 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 19:35:24 -0000
Received: by lboi15 with SMTP id i15so957618lbo.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 12:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=l1LaLeIHykssBZJE3b2FGqpCICI0cU8wSFxNdtDK02s=;
	b=bKDqUBgAk01QP3Cq426ZPR5UVLjQALYzs8XWuK8L4S6izFNyM+7PQMAqpdxWPrsNWU
	mQ1d0cwtwdKVHmqz67j/YpUM6kz3EjbOAUG4iA7RDLvjJOgiL/Op1ivl/d7SNNSCnEzp
	fzArDH+tAuzihAzzVEiyNu1Vzqt/JTyc3twkI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=l1LaLeIHykssBZJE3b2FGqpCICI0cU8wSFxNdtDK02s=;
	b=Ra3KYJ+ZLwYjDapTgNIirf63rfk8Hu8GIyzljX7ToC7gdppDnnMStq6mXx+8Sd3GP6
	h61nQ+UktBSEhG3Q+WcaKatE+X9NLyyb9hEWIC3IqGh/HoQpQG+3u3C3szRTbk2IlDb1
	6LRKxXmorHsUsiLEvbdpjvTH+rsTj3BotBppkELuQsIb1sYBhUD2/YMVHtS1jAAN+hdl
	hd3bCg8xzkgGpOmM/Dk6RFYu+n1sO1RSfLwhXCvn+YrZLj0U/5QE3Whnxx/RPdKUCeI0
	0kesXpBzEKUBDYps/hgGAo4tJ2A/P4as4glyzH+JaBGCDAZzP3ojRmpxNXLV2juHGamR
	DLdA==
MIME-Version: 1.0
Received: by 10.112.30.1 with SMTP id o1mr10397409lbh.3.1335296123380; Tue, 24
	Apr 2012 12:35:23 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 12:35:23 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CAB10MZDmn4oKDmR_uCzsAWbakh-SgMGUvFk9L0zWKTWd03tSSw@mail.gmail.com>
References: <f7a1633867bfeb30f83d.1335222981@vollum>
	<4F9677E9020000780007F840@nat28.tlf.novell.com>
	<CAB10MZDmn4oKDmR_uCzsAWbakh-SgMGUvFk9L0zWKTWd03tSSw@mail.gmail.com>
Date: Tue, 24 Apr 2012 12:35:23 -0700
Message-ID: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlM4jejbK406rssJyqSw0uLuTge+GgvnCH1i4ToPQXTRfuIICBRlV/LHFCOjluGLeedKE45
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 24.04.12 at 01:16, Aravindh Puthiyaparambil <aravindh@virtuata.com=
> wrote:
>>> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getconte=
xt()
>>>
>>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>>
>>> diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
>>> --- a/xen/arch/x86/domctl.c =A0 Mon Apr 23 15:16:34 2012 -0700
>>> +++ b/xen/arch/x86/domctl.c =A0 Mon Apr 23 16:12:50 2012 -0700
>>> @@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>>> +#endif
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>> + =A0 =A0 =A0 =A0else
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>> +#endif
>>
>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>> as a new function table entry, or pay the price of calling
>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>> the case of the subject vCPU being current.
>
> OK, I will try introducing a new wrapper that will return
> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.

Jan,

How does this look?
PS: Come submission time, I will send it out as two separate patches.

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
         hvm_get_segment_register(v, x86_seg_ss, &sreg);
         c.nat->user_regs.ss =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_ds, &sreg);
         c.nat->user_regs.ds =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_es, &sreg);
         c.nat->user_regs.es =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs =3D sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base =3D sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs =3D sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+        {
+            c.nat->gs_base_kernel =3D sreg.base;
+            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
+        }
+        else
+        {
+            c.nat->gs_base_user =3D sreg.base;
+            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
+        }
+#endif
     }
     else
     {
         c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
         c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
         for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
             c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
 #ifdef CONFIG_COMPAT
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -640,16 +640,25 @@ static void svm_set_segment_register(str
     default:
         BUG();
     }

     if ( sync )
         svm_vmload(vmcb);
 }

+#ifdef __x86_64__
+static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
+
+    return vmcb->kerngsbase;
+}
+#endif
+
 static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;

     if ( !paging_mode_hap(v->domain) )
         return 0;

     vmcb_set_g_pat(vmcb, gpat);
@@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D svm_vcpu_destroy,
     .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
     .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
     .get_interrupt_shadow =3D svm_get_interrupt_shadow,
     .set_interrupt_shadow =3D svm_set_interrupt_shadow,
     .guest_x86_mode       =3D svm_guest_x86_mode,
     .get_segment_register =3D svm_get_segment_register,
     .set_segment_register =3D svm_set_segment_register,
+    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
     .update_host_cr3      =3D svm_update_host_cr3,
     .update_guest_cr      =3D svm_update_guest_cr,
     .update_guest_efer    =3D svm_update_guest_efer,
     .set_guest_pat        =3D svm_set_guest_pat,
     .get_guest_pat        =3D svm_get_guest_pat,
     .set_tsc_offset       =3D svm_set_tsc_offset,
     .inject_exception     =3D svm_inject_exception,
     .init_hypercall_page  =3D svm_init_hypercall_page,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
         break;
     default:
         BUG();
     }

     vmx_vmcs_exit(v);
 }

+#ifdef __x86_64__
+static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
+{
+    return v->arch.hvm_vmx.shadow_gs;
+}
+#endif
+
 static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
         return 0;

     vmx_vmcs_enter(v);
     __vmwrite(GUEST_PAT, gpat);
 #ifdef __i386__
@@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D vmx_vcpu_destroy,
     .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
     .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
     .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
     .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
     .guest_x86_mode       =3D vmx_guest_x86_mode,
     .get_segment_register =3D vmx_get_segment_register,
     .set_segment_register =3D vmx_set_segment_register,
+    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
     .update_host_cr3      =3D vmx_update_host_cr3,
     .update_guest_cr      =3D vmx_update_guest_cr,
     .update_guest_efer    =3D vmx_update_guest_efer,
     .set_guest_pat        =3D vmx_set_guest_pat,
     .get_guest_pat        =3D vmx_get_guest_pat,
     .set_tsc_offset       =3D vmx_set_tsc_offset,
     .inject_exception     =3D vmx_inject_exception,
     .init_hypercall_page  =3D vmx_init_hypercall_page,
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -101,16 +101,19 @@ struct hvm_function_table {
     /* Examine specifics of the guest state. */
     unsigned int (*get_interrupt_shadow)(struct vcpu *v);
     void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shadow);
     int (*guest_x86_mode)(struct vcpu *v);
     void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
     void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
+#ifdef __x86_64__
+    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
+#endif

     /*
      * Re-set the value of CR3 that Xen runs on when handling VM exits.
      */
     void (*update_host_cr3)(struct vcpu *v);

     /*
      * Called to inform HVM layer that a guest CRn or EFER has changed.
@@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,

 static inline void
 hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
                          struct segment_register *reg)
 {
     hvm_funcs.set_segment_register(v, seg, reg);
 }

+#ifdef __x86_64__
+static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
+{
+    return hvm_funcs.get_shadow_gs_base(v);
+}
+#endif
+
 #define is_viridian_domain(_d)                                            =
 \
  (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))

 void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
                                    unsigned int *ecx, unsigned int *edx);
 void hvm_migrate_timers(struct vcpu *v);
 void hvm_do_resume(struct vcpu *v);
 void hvm_migrate_pirqs(struct vcpu *v);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:35:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlWJ-0007bm-AZ; Tue, 24 Apr 2012 19:35:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMlWH-0007bf-Rt
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:35:26 +0000
Received: from [85.158.143.99:49041] by server-1.bemta-4.messagelabs.com id
	53/FB-20925-D70079F4; Tue, 24 Apr 2012 19:35:25 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335296123!19830610!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6493 invoked from network); 24 Apr 2012 19:35:24 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 19:35:24 -0000
Received: by lboi15 with SMTP id i15so957618lbo.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 12:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=l1LaLeIHykssBZJE3b2FGqpCICI0cU8wSFxNdtDK02s=;
	b=bKDqUBgAk01QP3Cq426ZPR5UVLjQALYzs8XWuK8L4S6izFNyM+7PQMAqpdxWPrsNWU
	mQ1d0cwtwdKVHmqz67j/YpUM6kz3EjbOAUG4iA7RDLvjJOgiL/Op1ivl/d7SNNSCnEzp
	fzArDH+tAuzihAzzVEiyNu1Vzqt/JTyc3twkI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=l1LaLeIHykssBZJE3b2FGqpCICI0cU8wSFxNdtDK02s=;
	b=Ra3KYJ+ZLwYjDapTgNIirf63rfk8Hu8GIyzljX7ToC7gdppDnnMStq6mXx+8Sd3GP6
	h61nQ+UktBSEhG3Q+WcaKatE+X9NLyyb9hEWIC3IqGh/HoQpQG+3u3C3szRTbk2IlDb1
	6LRKxXmorHsUsiLEvbdpjvTH+rsTj3BotBppkELuQsIb1sYBhUD2/YMVHtS1jAAN+hdl
	hd3bCg8xzkgGpOmM/Dk6RFYu+n1sO1RSfLwhXCvn+YrZLj0U/5QE3Whnxx/RPdKUCeI0
	0kesXpBzEKUBDYps/hgGAo4tJ2A/P4as4glyzH+JaBGCDAZzP3ojRmpxNXLV2juHGamR
	DLdA==
MIME-Version: 1.0
Received: by 10.112.30.1 with SMTP id o1mr10397409lbh.3.1335296123380; Tue, 24
	Apr 2012 12:35:23 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 12:35:23 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CAB10MZDmn4oKDmR_uCzsAWbakh-SgMGUvFk9L0zWKTWd03tSSw@mail.gmail.com>
References: <f7a1633867bfeb30f83d.1335222981@vollum>
	<4F9677E9020000780007F840@nat28.tlf.novell.com>
	<CAB10MZDmn4oKDmR_uCzsAWbakh-SgMGUvFk9L0zWKTWd03tSSw@mail.gmail.com>
Date: Tue, 24 Apr 2012 12:35:23 -0700
Message-ID: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlM4jejbK406rssJyqSw0uLuTge+GgvnCH1i4ToPQXTRfuIICBRlV/LHFCOjluGLeedKE45
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 24.04.12 at 01:16, Aravindh Puthiyaparambil <aravindh@virtuata.com=
> wrote:
>>> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getconte=
xt()
>>>
>>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>>
>>> diff -r 6ef297a3761f -r f7a1633867bf xen/arch/x86/domctl.c
>>> --- a/xen/arch/x86/domctl.c =A0 Mon Apr 23 15:16:34 2012 -0700
>>> +++ b/xen/arch/x86/domctl.c =A0 Mon Apr 23 16:12:50 2012 -0700
>>> @@ -1590,8 +1590,17 @@ void arch_get_info_guest(struct vcpu *v,
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>>> +#endif
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>> + =A0 =A0 =A0 =A0else
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>> +#endif
>>
>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>> as a new function table entry, or pay the price of calling
>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>> the case of the subject vCPU being current.
>
> OK, I will try introducing a new wrapper that will return
> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.

Jan,

How does this look?
PS: Come submission time, I will send it out as two separate patches.

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
         hvm_get_segment_register(v, x86_seg_ss, &sreg);
         c.nat->user_regs.ss =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_ds, &sreg);
         c.nat->user_regs.ds =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_es, &sreg);
         c.nat->user_regs.es =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs =3D sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base =3D sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs =3D sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+        {
+            c.nat->gs_base_kernel =3D sreg.base;
+            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
+        }
+        else
+        {
+            c.nat->gs_base_user =3D sreg.base;
+            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
+        }
+#endif
     }
     else
     {
         c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
         c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
         for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
             c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
 #ifdef CONFIG_COMPAT
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -640,16 +640,25 @@ static void svm_set_segment_register(str
     default:
         BUG();
     }

     if ( sync )
         svm_vmload(vmcb);
 }

+#ifdef __x86_64__
+static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
+
+    return vmcb->kerngsbase;
+}
+#endif
+
 static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;

     if ( !paging_mode_hap(v->domain) )
         return 0;

     vmcb_set_g_pat(vmcb, gpat);
@@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D svm_vcpu_destroy,
     .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
     .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
     .get_interrupt_shadow =3D svm_get_interrupt_shadow,
     .set_interrupt_shadow =3D svm_set_interrupt_shadow,
     .guest_x86_mode       =3D svm_guest_x86_mode,
     .get_segment_register =3D svm_get_segment_register,
     .set_segment_register =3D svm_set_segment_register,
+    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
     .update_host_cr3      =3D svm_update_host_cr3,
     .update_guest_cr      =3D svm_update_guest_cr,
     .update_guest_efer    =3D svm_update_guest_efer,
     .set_guest_pat        =3D svm_set_guest_pat,
     .get_guest_pat        =3D svm_get_guest_pat,
     .set_tsc_offset       =3D svm_set_tsc_offset,
     .inject_exception     =3D svm_inject_exception,
     .init_hypercall_page  =3D svm_init_hypercall_page,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
         break;
     default:
         BUG();
     }

     vmx_vmcs_exit(v);
 }

+#ifdef __x86_64__
+static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
+{
+    return v->arch.hvm_vmx.shadow_gs;
+}
+#endif
+
 static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
         return 0;

     vmx_vmcs_enter(v);
     __vmwrite(GUEST_PAT, gpat);
 #ifdef __i386__
@@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D vmx_vcpu_destroy,
     .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
     .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
     .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
     .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
     .guest_x86_mode       =3D vmx_guest_x86_mode,
     .get_segment_register =3D vmx_get_segment_register,
     .set_segment_register =3D vmx_set_segment_register,
+    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
     .update_host_cr3      =3D vmx_update_host_cr3,
     .update_guest_cr      =3D vmx_update_guest_cr,
     .update_guest_efer    =3D vmx_update_guest_efer,
     .set_guest_pat        =3D vmx_set_guest_pat,
     .get_guest_pat        =3D vmx_get_guest_pat,
     .set_tsc_offset       =3D vmx_set_tsc_offset,
     .inject_exception     =3D vmx_inject_exception,
     .init_hypercall_page  =3D vmx_init_hypercall_page,
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -101,16 +101,19 @@ struct hvm_function_table {
     /* Examine specifics of the guest state. */
     unsigned int (*get_interrupt_shadow)(struct vcpu *v);
     void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shadow);
     int (*guest_x86_mode)(struct vcpu *v);
     void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
     void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
+#ifdef __x86_64__
+    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
+#endif

     /*
      * Re-set the value of CR3 that Xen runs on when handling VM exits.
      */
     void (*update_host_cr3)(struct vcpu *v);

     /*
      * Called to inform HVM layer that a guest CRn or EFER has changed.
@@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,

 static inline void
 hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
                          struct segment_register *reg)
 {
     hvm_funcs.set_segment_register(v, seg, reg);
 }

+#ifdef __x86_64__
+static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
+{
+    return hvm_funcs.get_shadow_gs_base(v);
+}
+#endif
+
 #define is_viridian_domain(_d)                                            =
 \
  (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))

 void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
                                    unsigned int *ecx, unsigned int *edx);
 void hvm_migrate_timers(struct vcpu *v);
 void hvm_do_resume(struct vcpu *v);
 void hvm_migrate_pirqs(struct vcpu *v);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleS-0008EP-6R; Tue, 24 Apr 2012 19:43:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleQ-0008Dr-P5
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:51 +0000
Received: from [193.109.254.147:34381] by server-2.bemta-14.messagelabs.com id
	B3/12-19409-672079F4; Tue, 24 Apr 2012 19:43:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335296628!944381!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTkwMTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5225 invoked from network); 24 Apr 2012 19:43:49 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 19:43:49 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5F03B1A808E;
	Tue, 24 Apr 2012 12:43:48 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TtLBPetY9bp2+Ctm+6lBVh+JTy1Y7BPZh65vhfxMgBov
	AH8va7gv6z03h9Nyl00m1FYcmeOrfhy6asHtGZ3xujQYrZwIic4iDsmY58cWHmJL
	uClYeulA2Ub1h7HAZGmuiZvpqH/UOrKWJfFsvYoRDQA8WCbiOSqKCeGC8wO2oXI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=FF2S6YXGXu4jhQvu8Q0ULfqkEvs=; b=Q8JB6vMmxoI
	HdZ9ICyJhC6zcmlp3xHJkk7UUM1vsoAvVhHl6wxd0VnWYZfMUv304/qMYmEVoPxk
	MJyhmaBLctFSd74U9NE8innWDb7DAnAt3yqVyLjWetTZt8la6Td/O66+2EH3Zo24
	1PIMmxi4i+dLAOxzE9/O5pudYbktIxNE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 8D0631A808B; 
	Tue, 24 Apr 2012 12:43:47 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8a6f6d38cb845a1af07b237dd1fb952863eeec67
Message-Id: <8a6f6d38cb845a1af07b.1335296903@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:23 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages with
 many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 2 files changed, 169 insertions(+), 14 deletions(-)


For shared frames that have many references, the doubly-linked list used to
store the rmap results in costly scans during unshare operations. To alleviate
the overhead, replace the linked list by a hash table. However, hash tables are
space-intensive, so only use them for pages that have "many" (arbitrary
threshold) references.

Unsharing is heaviliy exercised during domain destroy. In experimental testing,
for a domain that points over 100 thousand pages to the same shared frame,
domain destruction dropped from over 7 minutes(!) to less than two seconds.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5965a38564fc -r 8a6f6d38cb84 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -49,6 +49,17 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
+/* Reverse map defines */
+#define RMAP_HASHTAB_ORDER  0
+#define RMAP_HASHTAB_SIZE   \
+        ((PAGE_SIZE << RMAP_HASHTAB_ORDER) / sizeof(struct list_head))
+#define RMAP_USES_HASHTAB(page) \
+        ((page)->sharing->hash_table.flag == NULL)
+#define RMAP_HEAVY_SHARED_PAGE   RMAP_HASHTAB_SIZE
+/* A bit of hysteresis. We don't want to be mutating between list and hash
+ * table constantly. */
+#define RMAP_LIGHT_SHARED_PAGE   (RMAP_HEAVY_SHARED_PAGE >> 2)
+
 #if MEM_SHARING_AUDIT
 
 static struct list_head shr_audit_list;
@@ -72,6 +83,11 @@ static inline void audit_add_list(struct
 /* Removes from the audit list and cleans up the page sharing metadata. */
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
+
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
     spin_unlock(&shr_audit_lock);
@@ -89,6 +105,10 @@ int mem_sharing_audit(void)
 #define audit_add_list(p)  ((void)0)
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
     xfree(page->sharing);
 }
 
@@ -145,6 +165,11 @@ static atomic_t nr_saved_mfns   = ATOMIC
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 /** Reverse map **/
+/* Every shared frame keeps a reverse map (rmap) of <domain, gfn> tuples that
+ * this shared frame backs. For pages with a low degree of sharing, a O(n)
+ * search linked list is good enough. For pages with higher degree of sharing,
+ * we use a hash table instead. */
+
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -155,20 +180,109 @@ typedef struct gfn_info
 static inline void
 rmap_init(struct page_info *page)
 {
+    /* We always start off as a doubly linked list. */
     INIT_LIST_HEAD(&page->sharing->gfns);
 }
 
+/* Exceedingly simple "hash function" */
+#define HASH(domain, gfn)       \
+    (((gfn) + (domain)) % RMAP_HASHTAB_SIZE)
+
+/* Conversions. Tuned by the thresholds. Should only happen twice 
+ * (once each) during the lifetime of a shared page */
+static inline int
+rmap_list_to_hash_table(struct page_info *page)
+{
+    unsigned int i;
+    struct list_head *pos, *tmp, *b =
+        alloc_xenheap_pages(RMAP_HASHTAB_ORDER, 0);
+
+    if ( b == NULL )
+        return -ENOMEM;
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+        INIT_LIST_HEAD(b + i);
+
+    list_for_each_safe(pos, tmp, &page->sharing->gfns)
+    {
+        gfn_info_t *gfn_info = list_entry(pos, gfn_info_t, list);
+        struct list_head *bucket = b + HASH(gfn_info->domain, gfn_info->gfn);
+        list_del(pos);
+        list_add(pos, bucket);
+    }
+
+    page->sharing->hash_table.bucket = b;
+    page->sharing->hash_table.flag   = NULL;
+
+    return 0;
+}
+
 static inline void
-rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+rmap_hash_table_to_list(struct page_info *page)
 {
+    unsigned int i;
+    struct list_head *bucket = page->sharing->hash_table.bucket;
+
+    INIT_LIST_HEAD(&page->sharing->gfns);
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+    {
+        struct list_head *pos, *tmp, *head = bucket + i;
+        list_for_each_safe(pos, tmp, head)
+        {
+            list_del(pos);
+            list_add(pos, &page->sharing->gfns);
+        }
+    }
+
+    free_xenheap_pages(bucket, RMAP_HASHTAB_ORDER);
+}
+
+/* Generic accessors to the rmap */
+static inline unsigned long
+rmap_count(struct page_info *pg)
+{
+    unsigned long count;
+    unsigned long t = read_atomic(&pg->u.inuse.type_info);
+    count = t & PGT_count_mask;
+    if ( t & PGT_locked )
+        count--;
+    return count;
+}
+
+/* The page type count is always decreased after removing from the rmap.
+ * Use a convert flag to avoid mutating the rmap if in the middle of an 
+ * iterator, or if the page will be soon destroyed anyways. */
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page, int convert)
+{
+    if ( RMAP_USES_HASHTAB(page) && convert &&
+         (rmap_count(page) <= RMAP_LIGHT_SHARED_PAGE) )
+        rmap_hash_table_to_list(page);
+
+    /* Regardless of rmap type, same removal operation */
     list_del(&gfn_info->list);
 }
 
+/* The page type count is always increased before adding to the rmap. */
 static inline void
 rmap_add(gfn_info_t *gfn_info, struct page_info *page)
 {
+    struct list_head *head;
+
+    if ( !RMAP_USES_HASHTAB(page) &&
+         (rmap_count(page) >= RMAP_HEAVY_SHARED_PAGE) )
+        /* The conversion may fail with ENOMEM. We'll be less efficient,
+         * but no reason to panic. */
+        (void)rmap_list_to_hash_table(page);
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + 
+                            HASH(gfn_info->domain, gfn_info->gfn) :
+        &page->sharing->gfns;
+
     INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+    list_add(&gfn_info->list, head);
 }
 
 static inline gfn_info_t *
@@ -176,27 +290,33 @@ rmap_retrieve(uint16_t domain_id, unsign
                             struct page_info *page)
 {
     gfn_info_t *gfn_info;
-    struct list_head *le;
-    list_for_each(le, &page->sharing->gfns)
+    struct list_head *le, *head;
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + HASH(domain_id, gfn) :
+        &page->sharing->gfns;
+
+    list_for_each(le, head)
     {
         gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
             return gfn_info;
     }
+
+    /* Nothing was found */
     return NULL;
 }
 
 /* Returns true if the rmap has only one entry. O(1) complexity. */
 static inline int rmap_has_one_entry(struct page_info *page)
 {
-    struct list_head *head = &page->sharing->gfns;
-    return (head->next != head) && (head->next->next == head);
+    return (rmap_count(page) == 1);
 }
 
 /* Returns true if the rmap has any entries. O(1) complexity. */
 static inline int rmap_has_entries(struct page_info *page)
 {
-    return (!list_empty(&page->sharing->gfns));
+    return (rmap_count(page) != 0);
 }
 
 /* The iterator hides the details of how the rmap is implemented. This
@@ -204,20 +324,43 @@ static inline int rmap_has_entries(struc
 struct rmap_iterator {
     struct list_head *curr;
     struct list_head *next;
+    unsigned int bucket;
 };
 
 static inline void
 rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
 {
-    ri->curr = &page->sharing->gfns;
+    ri->curr = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket :
+                &page->sharing->gfns;
     ri->next = ri->curr->next; 
+    ri->bucket = 0;
 }
 
 static inline gfn_info_t *
 rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
 {
-    if ( ri->next == &page->sharing->gfns)
-        return NULL;
+    struct list_head *head = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket + ri->bucket :
+                &page->sharing->gfns;
+
+retry:
+    if ( ri->next == head)
+    {
+        if ( RMAP_USES_HASHTAB(page) )
+        {
+            ri->bucket++;
+            if ( ri->bucket >= RMAP_HASHTAB_SIZE )
+                /* No more hash table buckets */
+                return NULL;
+            head = page->sharing->hash_table.bucket + ri->bucket;
+            ri->curr = head;
+            ri->next = ri->curr->next;
+            goto retry;
+        } else
+            /* List exhausted */
+            return NULL;
+    }
 
     ri->curr = ri->next;
     ri->next = ri->curr->next;
@@ -253,7 +396,7 @@ static inline void mem_sharing_gfn_destr
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    rmap_del(gfn_info, page);
+    rmap_del(gfn_info, page, 1);
     xfree(gfn_info);
 }
 
@@ -870,8 +1013,9 @@ int mem_sharing_share_pages(struct domai
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from client list to source list */
-        rmap_del(gfn, cpage);
+        /* Move the gfn_info from client list to source list.
+         * Don't change the type of rmap for the client page. */
+        rmap_del(gfn, cpage, 0);
         rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
diff -r 5965a38564fc -r 8a6f6d38cb84 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -30,6 +30,13 @@
 
 typedef uint64_t shr_handle_t; 
 
+typedef struct rmap_hashtab {
+    struct list_head *bucket;
+    /* Overlaps with prev pointer of list_head in union below.
+     * Unlike the prev pointer, this can be NULL. */
+    void *flag;
+} rmap_hashtab_t;
+
 struct page_sharing_info
 {
     struct page_info *pg;   /* Back pointer to the page. */
@@ -38,7 +45,11 @@ struct page_sharing_info
     struct list_head entry; /* List of all shared pages (entry). */
     struct rcu_head rcu_head; /* List of all shared pages (entry). */
 #endif
-    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+    /* Reverse map of <domain,gfn> tuples for this shared frame. */
+    union {
+        struct list_head    gfns;
+        rmap_hashtab_t      hash_table;
+    };
 };
 
 #ifdef __x86_64__

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleS-0008EP-6R; Tue, 24 Apr 2012 19:43:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleQ-0008Dr-P5
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:51 +0000
Received: from [193.109.254.147:34381] by server-2.bemta-14.messagelabs.com id
	B3/12-19409-672079F4; Tue, 24 Apr 2012 19:43:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335296628!944381!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTkwMTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5225 invoked from network); 24 Apr 2012 19:43:49 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 19:43:49 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5F03B1A808E;
	Tue, 24 Apr 2012 12:43:48 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TtLBPetY9bp2+Ctm+6lBVh+JTy1Y7BPZh65vhfxMgBov
	AH8va7gv6z03h9Nyl00m1FYcmeOrfhy6asHtGZ3xujQYrZwIic4iDsmY58cWHmJL
	uClYeulA2Ub1h7HAZGmuiZvpqH/UOrKWJfFsvYoRDQA8WCbiOSqKCeGC8wO2oXI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=FF2S6YXGXu4jhQvu8Q0ULfqkEvs=; b=Q8JB6vMmxoI
	HdZ9ICyJhC6zcmlp3xHJkk7UUM1vsoAvVhHl6wxd0VnWYZfMUv304/qMYmEVoPxk
	MJyhmaBLctFSd74U9NE8innWDb7DAnAt3yqVyLjWetTZt8la6Td/O66+2EH3Zo24
	1PIMmxi4i+dLAOxzE9/O5pudYbktIxNE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 8D0631A808B; 
	Tue, 24 Apr 2012 12:43:47 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8a6f6d38cb845a1af07b237dd1fb952863eeec67
Message-Id: <8a6f6d38cb845a1af07b.1335296903@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:23 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 3] x86/mem_sharing: For shared pages with
 many references, use a hash table instead of a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 2 files changed, 169 insertions(+), 14 deletions(-)


For shared frames that have many references, the doubly-linked list used to
store the rmap results in costly scans during unshare operations. To alleviate
the overhead, replace the linked list by a hash table. However, hash tables are
space-intensive, so only use them for pages that have "many" (arbitrary
threshold) references.

Unsharing is heaviliy exercised during domain destroy. In experimental testing,
for a domain that points over 100 thousand pages to the same shared frame,
domain destruction dropped from over 7 minutes(!) to less than two seconds.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5965a38564fc -r 8a6f6d38cb84 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -49,6 +49,17 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
+/* Reverse map defines */
+#define RMAP_HASHTAB_ORDER  0
+#define RMAP_HASHTAB_SIZE   \
+        ((PAGE_SIZE << RMAP_HASHTAB_ORDER) / sizeof(struct list_head))
+#define RMAP_USES_HASHTAB(page) \
+        ((page)->sharing->hash_table.flag == NULL)
+#define RMAP_HEAVY_SHARED_PAGE   RMAP_HASHTAB_SIZE
+/* A bit of hysteresis. We don't want to be mutating between list and hash
+ * table constantly. */
+#define RMAP_LIGHT_SHARED_PAGE   (RMAP_HEAVY_SHARED_PAGE >> 2)
+
 #if MEM_SHARING_AUDIT
 
 static struct list_head shr_audit_list;
@@ -72,6 +83,11 @@ static inline void audit_add_list(struct
 /* Removes from the audit list and cleans up the page sharing metadata. */
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
+
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
     spin_unlock(&shr_audit_lock);
@@ -89,6 +105,10 @@ int mem_sharing_audit(void)
 #define audit_add_list(p)  ((void)0)
 static inline void page_sharing_dispose(struct page_info *page)
 {
+    /* Unlikely given our thresholds, but we should be careful. */
+    if ( unlikely(RMAP_USES_HASHTAB(page)) )
+        free_xenheap_pages(page->sharing->hash_table.bucket, 
+                            RMAP_HASHTAB_ORDER);
     xfree(page->sharing);
 }
 
@@ -145,6 +165,11 @@ static atomic_t nr_saved_mfns   = ATOMIC
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 /** Reverse map **/
+/* Every shared frame keeps a reverse map (rmap) of <domain, gfn> tuples that
+ * this shared frame backs. For pages with a low degree of sharing, a O(n)
+ * search linked list is good enough. For pages with higher degree of sharing,
+ * we use a hash table instead. */
+
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -155,20 +180,109 @@ typedef struct gfn_info
 static inline void
 rmap_init(struct page_info *page)
 {
+    /* We always start off as a doubly linked list. */
     INIT_LIST_HEAD(&page->sharing->gfns);
 }
 
+/* Exceedingly simple "hash function" */
+#define HASH(domain, gfn)       \
+    (((gfn) + (domain)) % RMAP_HASHTAB_SIZE)
+
+/* Conversions. Tuned by the thresholds. Should only happen twice 
+ * (once each) during the lifetime of a shared page */
+static inline int
+rmap_list_to_hash_table(struct page_info *page)
+{
+    unsigned int i;
+    struct list_head *pos, *tmp, *b =
+        alloc_xenheap_pages(RMAP_HASHTAB_ORDER, 0);
+
+    if ( b == NULL )
+        return -ENOMEM;
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+        INIT_LIST_HEAD(b + i);
+
+    list_for_each_safe(pos, tmp, &page->sharing->gfns)
+    {
+        gfn_info_t *gfn_info = list_entry(pos, gfn_info_t, list);
+        struct list_head *bucket = b + HASH(gfn_info->domain, gfn_info->gfn);
+        list_del(pos);
+        list_add(pos, bucket);
+    }
+
+    page->sharing->hash_table.bucket = b;
+    page->sharing->hash_table.flag   = NULL;
+
+    return 0;
+}
+
 static inline void
-rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+rmap_hash_table_to_list(struct page_info *page)
 {
+    unsigned int i;
+    struct list_head *bucket = page->sharing->hash_table.bucket;
+
+    INIT_LIST_HEAD(&page->sharing->gfns);
+
+    for (i = 0; i < RMAP_HASHTAB_SIZE; i++)
+    {
+        struct list_head *pos, *tmp, *head = bucket + i;
+        list_for_each_safe(pos, tmp, head)
+        {
+            list_del(pos);
+            list_add(pos, &page->sharing->gfns);
+        }
+    }
+
+    free_xenheap_pages(bucket, RMAP_HASHTAB_ORDER);
+}
+
+/* Generic accessors to the rmap */
+static inline unsigned long
+rmap_count(struct page_info *pg)
+{
+    unsigned long count;
+    unsigned long t = read_atomic(&pg->u.inuse.type_info);
+    count = t & PGT_count_mask;
+    if ( t & PGT_locked )
+        count--;
+    return count;
+}
+
+/* The page type count is always decreased after removing from the rmap.
+ * Use a convert flag to avoid mutating the rmap if in the middle of an 
+ * iterator, or if the page will be soon destroyed anyways. */
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page, int convert)
+{
+    if ( RMAP_USES_HASHTAB(page) && convert &&
+         (rmap_count(page) <= RMAP_LIGHT_SHARED_PAGE) )
+        rmap_hash_table_to_list(page);
+
+    /* Regardless of rmap type, same removal operation */
     list_del(&gfn_info->list);
 }
 
+/* The page type count is always increased before adding to the rmap. */
 static inline void
 rmap_add(gfn_info_t *gfn_info, struct page_info *page)
 {
+    struct list_head *head;
+
+    if ( !RMAP_USES_HASHTAB(page) &&
+         (rmap_count(page) >= RMAP_HEAVY_SHARED_PAGE) )
+        /* The conversion may fail with ENOMEM. We'll be less efficient,
+         * but no reason to panic. */
+        (void)rmap_list_to_hash_table(page);
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + 
+                            HASH(gfn_info->domain, gfn_info->gfn) :
+        &page->sharing->gfns;
+
     INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+    list_add(&gfn_info->list, head);
 }
 
 static inline gfn_info_t *
@@ -176,27 +290,33 @@ rmap_retrieve(uint16_t domain_id, unsign
                             struct page_info *page)
 {
     gfn_info_t *gfn_info;
-    struct list_head *le;
-    list_for_each(le, &page->sharing->gfns)
+    struct list_head *le, *head;
+
+    head = (RMAP_USES_HASHTAB(page)) ?
+        page->sharing->hash_table.bucket + HASH(domain_id, gfn) :
+        &page->sharing->gfns;
+
+    list_for_each(le, head)
     {
         gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
             return gfn_info;
     }
+
+    /* Nothing was found */
     return NULL;
 }
 
 /* Returns true if the rmap has only one entry. O(1) complexity. */
 static inline int rmap_has_one_entry(struct page_info *page)
 {
-    struct list_head *head = &page->sharing->gfns;
-    return (head->next != head) && (head->next->next == head);
+    return (rmap_count(page) == 1);
 }
 
 /* Returns true if the rmap has any entries. O(1) complexity. */
 static inline int rmap_has_entries(struct page_info *page)
 {
-    return (!list_empty(&page->sharing->gfns));
+    return (rmap_count(page) != 0);
 }
 
 /* The iterator hides the details of how the rmap is implemented. This
@@ -204,20 +324,43 @@ static inline int rmap_has_entries(struc
 struct rmap_iterator {
     struct list_head *curr;
     struct list_head *next;
+    unsigned int bucket;
 };
 
 static inline void
 rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
 {
-    ri->curr = &page->sharing->gfns;
+    ri->curr = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket :
+                &page->sharing->gfns;
     ri->next = ri->curr->next; 
+    ri->bucket = 0;
 }
 
 static inline gfn_info_t *
 rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
 {
-    if ( ri->next == &page->sharing->gfns)
-        return NULL;
+    struct list_head *head = (RMAP_USES_HASHTAB(page)) ?
+                page->sharing->hash_table.bucket + ri->bucket :
+                &page->sharing->gfns;
+
+retry:
+    if ( ri->next == head)
+    {
+        if ( RMAP_USES_HASHTAB(page) )
+        {
+            ri->bucket++;
+            if ( ri->bucket >= RMAP_HASHTAB_SIZE )
+                /* No more hash table buckets */
+                return NULL;
+            head = page->sharing->hash_table.bucket + ri->bucket;
+            ri->curr = head;
+            ri->next = ri->curr->next;
+            goto retry;
+        } else
+            /* List exhausted */
+            return NULL;
+    }
 
     ri->curr = ri->next;
     ri->next = ri->curr->next;
@@ -253,7 +396,7 @@ static inline void mem_sharing_gfn_destr
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    rmap_del(gfn_info, page);
+    rmap_del(gfn_info, page, 1);
     xfree(gfn_info);
 }
 
@@ -870,8 +1013,9 @@ int mem_sharing_share_pages(struct domai
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from client list to source list */
-        rmap_del(gfn, cpage);
+        /* Move the gfn_info from client list to source list.
+         * Don't change the type of rmap for the client page. */
+        rmap_del(gfn, cpage, 0);
         rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
diff -r 5965a38564fc -r 8a6f6d38cb84 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -30,6 +30,13 @@
 
 typedef uint64_t shr_handle_t; 
 
+typedef struct rmap_hashtab {
+    struct list_head *bucket;
+    /* Overlaps with prev pointer of list_head in union below.
+     * Unlike the prev pointer, this can be NULL. */
+    void *flag;
+} rmap_hashtab_t;
+
 struct page_sharing_info
 {
     struct page_info *pg;   /* Back pointer to the page. */
@@ -38,7 +45,11 @@ struct page_sharing_info
     struct list_head entry; /* List of all shared pages (entry). */
     struct rcu_head rcu_head; /* List of all shared pages (entry). */
 #endif
-    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+    /* Reverse map of <domain,gfn> tuples for this shared frame. */
+    union {
+        struct list_head    gfns;
+        rmap_hashtab_t      hash_table;
+    };
 };
 
 #ifdef __x86_64__

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleQ-0008Dt-Cv; Tue, 24 Apr 2012 19:43:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleO-0008Db-N1
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:48 +0000
Received: from [193.109.254.147:34321] by server-10.bemta-14.messagelabs.com
	id 88/74-05847-472079F4; Tue, 24 Apr 2012 19:43:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335296627!6144148!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4NzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20075 invoked from network); 24 Apr 2012 19:43:47 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-8.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 19:43:47 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id B48931A808F;
	Tue, 24 Apr 2012 12:43:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=kbMoztuDzi8MvmuEwgkxqFtOFKyo8P8h1RmIszMq6XGw
	ePo4mtPWUxYIfC0PucP+x36hm9sDaF2PjOdgACTfNdn0rAed8I67f4gh95gUSfMZ
	xTYSRyYm4MuEthMqK7SX7hDHOCxYOcbasAFBRDePASlvxz5HBh4g03bvPvltuFM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MB7du5qa4J4DDiTdmj6EL15GFeI=; b=DbjymIFPEgY
	9IGwlJGWw4xJRT3/V/q/iYB2dLY7+NQ51VyI8VGxglLaCAc3lj+DjeBWmvNwIqi5
	h19UYNxjfT/UhF3vC+p879FQL9yXL8Nd41D0VOZRXjPV1rXXEYJLdbzunWKfYSb7
	fk1Vw8ajlhZb9O1BeVyr9CLszLtZUD+k=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id F36511A8076; 
	Tue, 24 Apr 2012 12:43:45 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 796b523346ac55f938977052d405fc8b7e912b49
Message-Id: <796b523346ac55f93897.1335296901@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 3] x86/mem_sharing: Don't destroy a page's
 shared state before depleting its <gfn, domid> tuple list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 08946bbc8036 -r 796b523346ac xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -963,7 +963,9 @@ gfn_found:
     last_gfn = list_has_one_entry(&page->sharing->gfns);
     if ( last_gfn )
     {
-        /* Clean up shared state */
+        /* Clean up shared state. Get rid of the <domid, gfn> tuple
+         * before destroying the rmap. */
+        mem_sharing_gfn_destroy(d, gfn_info);
         audit_del_list(page);
         page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
@@ -974,7 +976,8 @@ gfn_found:
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
+        if ( !last_gfn )
+            mem_sharing_gfn_destroy(d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -987,7 +990,6 @@ gfn_found:
  
     if ( last_gfn )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleQ-0008Dt-Cv; Tue, 24 Apr 2012 19:43:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleO-0008Db-N1
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:48 +0000
Received: from [193.109.254.147:34321] by server-10.bemta-14.messagelabs.com
	id 88/74-05847-472079F4; Tue, 24 Apr 2012 19:43:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335296627!6144148!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4NzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20075 invoked from network); 24 Apr 2012 19:43:47 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-8.tower-27.messagelabs.com with SMTP;
	24 Apr 2012 19:43:47 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id B48931A808F;
	Tue, 24 Apr 2012 12:43:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=kbMoztuDzi8MvmuEwgkxqFtOFKyo8P8h1RmIszMq6XGw
	ePo4mtPWUxYIfC0PucP+x36hm9sDaF2PjOdgACTfNdn0rAed8I67f4gh95gUSfMZ
	xTYSRyYm4MuEthMqK7SX7hDHOCxYOcbasAFBRDePASlvxz5HBh4g03bvPvltuFM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MB7du5qa4J4DDiTdmj6EL15GFeI=; b=DbjymIFPEgY
	9IGwlJGWw4xJRT3/V/q/iYB2dLY7+NQ51VyI8VGxglLaCAc3lj+DjeBWmvNwIqi5
	h19UYNxjfT/UhF3vC+p879FQL9yXL8Nd41D0VOZRXjPV1rXXEYJLdbzunWKfYSb7
	fk1Vw8ajlhZb9O1BeVyr9CLszLtZUD+k=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id F36511A8076; 
	Tue, 24 Apr 2012 12:43:45 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 796b523346ac55f938977052d405fc8b7e912b49
Message-Id: <796b523346ac55f93897.1335296901@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 3] x86/mem_sharing: Don't destroy a page's
 shared state before depleting its <gfn, domid> tuple list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 08946bbc8036 -r 796b523346ac xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -963,7 +963,9 @@ gfn_found:
     last_gfn = list_has_one_entry(&page->sharing->gfns);
     if ( last_gfn )
     {
-        /* Clean up shared state */
+        /* Clean up shared state. Get rid of the <domid, gfn> tuple
+         * before destroying the rmap. */
+        mem_sharing_gfn_destroy(d, gfn_info);
         audit_del_list(page);
         page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
@@ -974,7 +976,8 @@ gfn_found:
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
+        if ( !last_gfn )
+            mem_sharing_gfn_destroy(d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -987,7 +990,6 @@ gfn_found:
  
     if ( last_gfn )
     {
-        mem_sharing_gfn_destroy(d, gfn_info);
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleQ-0008Dl-1J; Tue, 24 Apr 2012 19:43:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleO-0008Da-Hm
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:48 +0000
Received: from [85.158.143.99:18002] by server-2.bemta-4.messagelabs.com id
	BD/5F-17550-372079F4; Tue, 24 Apr 2012 19:43:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335296626!13899128!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24229 invoked from network); 24 Apr 2012 19:43:46 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.66) by server-16.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 19:43:46 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id B512A1A808B;
	Tue, 24 Apr 2012 12:43:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=r2krlmilVC0uOo1QVUydWh
	cKjeBhnWG+ODkoaVkaBJcgAnEyyeJcRWyzbidY+FWbBWfhuCn+3o3J2WXATj+GiE
	LqtvuxJQsnWFnoYuxMDyQMYVhsKdIyAwu5BteiJKSc1cFxe9+gHhDlXxqQsnIjkR
	SmQ5FetOBjNCwHuMlhWXo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=e0ydieONJVEc
	kEku6sElKpxlydk=; b=lY0gthmby5u0IYpVKY/1ULeCzJgIyGCtbn0enqkXtTDx
	n0uYqO+FHJgC3vtNQHNzFaoFe8s3VfR6R9xixjbJVrvtAZ4jTZM4MeCW5kaf/Pgv
	x+m3JFLBzX6lRrEybz6hI0OKsXwtHl53PgHqB+o0a4V8RCTWVUQYc6Igap/smRs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 356AE1A8076; 
	Tue, 24 Apr 2012 12:43:44 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 3] x86/mem_sharing: Improve performance of
 rmap, fix cascading bugs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a repost of patches 2 and 3 of the series initially posted on Apr 12th.

The first patch has been split into two functionally isolated patches as per
Tim Deegan's request.

The original posting (suitably edited) follows
--------------------------------
The sharing subsystem does not scale elegantly with high degrees of page
sharing. The culprit is a reverse map that each shared frame maintains,
resolving to all domain pages pointing to the shared frame. Because the rmap is
implemented with a O(n) search linked-list, CoW unsharing can result in
prolonged search times.

The place where this becomes most obvious is during domain destruction, during
which all shared p2m entries need to be unshared. Destroying a domain with a
lot of sharing could result in minutes of hypervisor freeze-up: 7 minutes for a
2 GiB domain! As a result, errors cascade throughout the system, including soft
lockups, watchdogs firing, IO drivers timing out, etc.

The proposed solution is to mutate the rmap from a linked list to a hash table
when the number of domain pages referencing the shared frame exceeds a
threshold. This maintains minimal space use for the common case of relatively
low sharing, and switches to an O(1) data structure for heavily shared pages,
with an space overhead of one page. The threshold chosen is 256, as a single
page can fit 256 spill lists for 256 buckets in a hash table.

With these patches in place, domain destruction for a 2 GiB domain with a
shared frame including over a hundred thousand references drops from 7 minutes
to two seconds.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_sharing.c     |    8 +-
 xen/arch/x86/mm/mem_sharing.c     |  138 ++++++++++++++++++++++--------
 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 4 files changed, 274 insertions(+), 55 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleQ-0008Dl-1J; Tue, 24 Apr 2012 19:43:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleO-0008Da-Hm
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:48 +0000
Received: from [85.158.143.99:18002] by server-2.bemta-4.messagelabs.com id
	BD/5F-17550-372079F4; Tue, 24 Apr 2012 19:43:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335296626!13899128!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24229 invoked from network); 24 Apr 2012 19:43:46 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.66) by server-16.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 19:43:46 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id B512A1A808B;
	Tue, 24 Apr 2012 12:43:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=r2krlmilVC0uOo1QVUydWh
	cKjeBhnWG+ODkoaVkaBJcgAnEyyeJcRWyzbidY+FWbBWfhuCn+3o3J2WXATj+GiE
	LqtvuxJQsnWFnoYuxMDyQMYVhsKdIyAwu5BteiJKSc1cFxe9+gHhDlXxqQsnIjkR
	SmQ5FetOBjNCwHuMlhWXo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=e0ydieONJVEc
	kEku6sElKpxlydk=; b=lY0gthmby5u0IYpVKY/1ULeCzJgIyGCtbn0enqkXtTDx
	n0uYqO+FHJgC3vtNQHNzFaoFe8s3VfR6R9xixjbJVrvtAZ4jTZM4MeCW5kaf/Pgv
	x+m3JFLBzX6lRrEybz6hI0OKsXwtHl53PgHqB+o0a4V8RCTWVUQYc6Igap/smRs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 356AE1A8076; 
	Tue, 24 Apr 2012 12:43:44 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 3] x86/mem_sharing: Improve performance of
 rmap, fix cascading bugs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a repost of patches 2 and 3 of the series initially posted on Apr 12th.

The first patch has been split into two functionally isolated patches as per
Tim Deegan's request.

The original posting (suitably edited) follows
--------------------------------
The sharing subsystem does not scale elegantly with high degrees of page
sharing. The culprit is a reverse map that each shared frame maintains,
resolving to all domain pages pointing to the shared frame. Because the rmap is
implemented with a O(n) search linked-list, CoW unsharing can result in
prolonged search times.

The place where this becomes most obvious is during domain destruction, during
which all shared p2m entries need to be unshared. Destroying a domain with a
lot of sharing could result in minutes of hypervisor freeze-up: 7 minutes for a
2 GiB domain! As a result, errors cascade throughout the system, including soft
lockups, watchdogs firing, IO drivers timing out, etc.

The proposed solution is to mutate the rmap from a linked list to a hash table
when the number of domain pages referencing the shared frame exceeds a
threshold. This maintains minimal space use for the common case of relatively
low sharing, and switches to an O(1) data structure for heavily shared pages,
with an space overhead of one page. The threshold chosen is 256, as a single
page can fit 256 spill lists for 256 buckets in a hash table.

With these patches in place, domain destruction for a 2 GiB domain with a
shared frame including over a hundred thousand references drops from 7 minutes
to two seconds.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_sharing.c     |    8 +-
 xen/arch/x86/mm/mem_sharing.c     |  138 ++++++++++++++++++++++--------
 xen/arch/x86/mm/mem_sharing.c     |  170 +++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/mem_sharing.h |   13 ++-
 4 files changed, 274 insertions(+), 55 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleR-0008EC-Q7; Tue, 24 Apr 2012 19:43:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleQ-0008Dk-DT
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:50 +0000
Received: from [85.158.143.99:45099] by server-3.bemta-4.messagelabs.com id
	97/F4-05853-572079F4; Tue, 24 Apr 2012 19:43:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335296628!19831049!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4NzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14228 invoked from network); 24 Apr 2012 19:43:48 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 19:43:48 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 649BC1A8076;
	Tue, 24 Apr 2012 12:43:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ZrV7rbjR41uFMDjUUBcQ66gvtQxHR/XAo93bTckFqfTO
	UBLSDgN6JhsdJfjx9WK58hlFaBb0hWSlVKGtm9AO79VIGSdIzKZ9QQtfRfLXdBni
	3041UFMg9UcBZoSN+A2FzOEcHxwO1ZLxO8rL4cLiu+EbGzsWA0YonFxOjifken0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=21vh70cqRAgFqgZRDr5rcRx0ctY=; b=RfWUw9fhY/N
	jJz9IklTEoANBglnK6SAKehyUV0CJnFKaTgNjrPy+cDbkYRqJtykBzPZkSAiU2Lv
	PKFrxPRL2HiaZxJQbQJkWwB1nYkeLpawUQyeiTIMXkJqQEtcfjqJVQZYfx3PpsT2
	rj2bJJotgfaxL29zqJUf9DhpgWVm3FQ8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id B0AE81A808E; 
	Tue, 24 Apr 2012 12:43:46 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5965a38564fcaf5240a3422d46a4e237b1a544c2
Message-Id: <5965a38564fcaf5240a3.1335296902@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:22 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse map
 for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  138 ++++++++++++++++++++++++++++++-----------
 1 files changed, 100 insertions(+), 38 deletions(-)


Each shared frame maintains a reverse map of <domain, gfn> tuples, so we know
which tuples this shared frame is backing. This is useful for auditing and
sanity-checking, and necessary to update all relevant p2m entries when sharing.

The reverse map is maintained as a doubly linked list, but the interface is
open-coded throughout the mem_sharing.c subsystem. Bury it inside a level of
abstraction, so it can later support different (more scalable) rmap
implementations.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 796b523346ac -r 5965a38564fc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -69,7 +69,8 @@ static inline void audit_add_list(struct
     spin_unlock(&shr_audit_lock);
 }
 
-static inline void audit_del_list(struct page_info *page)
+/* Removes from the audit list and cleans up the page sharing metadata. */
+static inline void page_sharing_dispose(struct page_info *page)
 {
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
@@ -86,7 +87,7 @@ int mem_sharing_audit(void)
 }
 
 #define audit_add_list(p)  ((void)0)
-static inline void audit_del_list(struct page_info *page)
+static inline void page_sharing_dispose(struct page_info *page)
 {
     xfree(page->sharing);
 }
@@ -143,6 +144,7 @@ static inline shr_handle_t get_next_hand
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
+/** Reverse map **/
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -150,15 +152,77 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-/* Returns true if list has only one entry. O(1) complexity. */
-static inline int list_has_one_entry(struct list_head *head)
+static inline void
+rmap_init(struct page_info *page)
 {
+    INIT_LIST_HEAD(&page->sharing->gfns);
+}
+
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+{
+    list_del(&gfn_info->list);
+}
+
+static inline void
+rmap_add(gfn_info_t *gfn_info, struct page_info *page)
+{
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->sharing->gfns);
+}
+
+static inline gfn_info_t *
+rmap_retrieve(uint16_t domain_id, unsigned long gfn, 
+                            struct page_info *page)
+{
+    gfn_info_t *gfn_info;
+    struct list_head *le;
+    list_for_each(le, &page->sharing->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
+            return gfn_info;
+    }
+    return NULL;
+}
+
+/* Returns true if the rmap has only one entry. O(1) complexity. */
+static inline int rmap_has_one_entry(struct page_info *page)
+{
+    struct list_head *head = &page->sharing->gfns;
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline gfn_info_t *gfn_get_info(struct list_head *list)
+/* Returns true if the rmap has any entries. O(1) complexity. */
+static inline int rmap_has_entries(struct page_info *page)
 {
-    return list_entry(list->next, gfn_info_t, list);
+    return (!list_empty(&page->sharing->gfns));
+}
+
+/* The iterator hides the details of how the rmap is implemented. This
+ * involves splitting the list_for_each_safe macro into two steps. */
+struct rmap_iterator {
+    struct list_head *curr;
+    struct list_head *next;
+};
+
+static inline void
+rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
+{
+    ri->curr = &page->sharing->gfns;
+    ri->next = ri->curr->next; 
+}
+
+static inline gfn_info_t *
+rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
+{
+    if ( ri->next == &page->sharing->gfns)
+        return NULL;
+
+    ri->curr = ri->next;
+    ri->next = ri->curr->next;
+
+    return list_entry(ri->curr, gfn_info_t, list);
 }
 
 static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
@@ -172,8 +236,8 @@ static inline gfn_info_t *mem_sharing_gf
 
     gfn_info->gfn = gfn;
     gfn_info->domain = d->domain_id;
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+
+    rmap_add(gfn_info, page);
 
     /* Increment our number of shared pges. */
     atomic_inc(&d->shr_pages);
@@ -181,14 +245,15 @@ static inline gfn_info_t *mem_sharing_gf
     return gfn_info;
 }
 
-static inline void mem_sharing_gfn_destroy(struct domain *d,
+static inline void mem_sharing_gfn_destroy(struct page_info *page,
+                                           struct domain *d,
                                            gfn_info_t *gfn_info)
 {
     /* Decrement the number of pages. */
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    list_del(&gfn_info->list);
+    rmap_del(gfn_info, page);
     xfree(gfn_info);
 }
 
@@ -230,8 +295,9 @@ int mem_sharing_audit(void)
         struct page_sharing_info *pg_shared_info;
         unsigned long nr_gfns = 0;
         struct page_info *pg;
-        struct list_head *le;
         mfn_t mfn;
+        gfn_info_t *g;
+        struct rmap_iterator ri;
 
         pg_shared_info = list_entry(ae, struct page_sharing_info, entry);
         pg = pg_shared_info->pg;
@@ -272,7 +338,7 @@ int mem_sharing_audit(void)
         }
 
         /* Check we have a list */
-        if ( (!pg->sharing) || (list_empty(&pg->sharing->gfns)) )
+        if ( (!pg->sharing) || !rmap_has_entries(pg) )
         {
            MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
                              mfn_x(mfn));
@@ -284,14 +350,13 @@ int mem_sharing_audit(void)
         count_found++;
 
         /* Check if all GFNs map to the MFN, and the p2m types */
-        list_for_each(le, &pg->sharing->gfns)
+        rmap_seed_iterator(pg, &ri);
+        while ( (g = rmap_iterate(pg, &ri)) != NULL )
         {
             struct domain *d;
             p2m_type_t t;
             mfn_t o_mfn;
-            gfn_info_t *g;
 
-            g = list_entry(le, gfn_info_t, list);
             d = get_domain_by_id(g->domain);
             if ( d == NULL )
             {
@@ -677,7 +742,7 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
     page->sharing->pg = page;
-    INIT_LIST_HEAD(&page->sharing->gfns);
+    rmap_init(page);
 
     /* Create the handle */
     page->sharing->handle = get_next_handle();  
@@ -698,7 +763,7 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
-        mem_sharing_gfn_destroy(d, gfn_info);
+        mem_sharing_gfn_destroy(page, d, gfn_info);
         xfree(page->sharing);
         page->sharing = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
@@ -726,13 +791,13 @@ int mem_sharing_share_pages(struct domai
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
     struct page_info *spage, *cpage, *firstpg, *secondpg;
-    struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
     struct two_gfns tg;
+    struct rmap_iterator ri;
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, NULL, &cmfn,
@@ -799,15 +864,15 @@ int mem_sharing_share_pages(struct domai
     }
 
     /* Merge the lists together */
-    list_for_each_safe(le, te, &cpage->sharing->gfns)
+    rmap_seed_iterator(cpage, &ri);
+    while ( (gfn = rmap_iterate(cpage, &ri)) != NULL)
     {
-        gfn = list_entry(le, gfn_info_t, list);
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
         /* Move the gfn_info from client list to source list */
-        list_del(&gfn->list);
-        list_add(&gfn->list, &spage->sharing->gfns);
+        rmap_del(gfn, cpage);
+        rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
@@ -817,7 +882,7 @@ int mem_sharing_share_pages(struct domai
     ASSERT(list_empty(&cpage->sharing->gfns));
 
     /* Clear the rest of the shared state */
-    audit_del_list(cpage);
+    page_sharing_dispose(cpage);
     cpage->sharing = NULL;
 
     mem_sharing_page_unlock(secondpg);
@@ -887,7 +952,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( !ret )
     {
         ret = -ENOENT;
-        mem_sharing_gfn_destroy(cd, gfn_info);
+        mem_sharing_gfn_destroy(spage, cd, gfn_info);
         put_page_and_type(spage);
     } else {
         ret = 0;
@@ -929,7 +994,6 @@ int __mem_sharing_unshare_page(struct do
     void *s, *t;
     int last_gfn;
     gfn_info_t *gfn_info = NULL;
-    struct list_head *le;
    
     mfn = get_gfn(d, gfn, &p2mt);
     
@@ -947,37 +1011,35 @@ int __mem_sharing_unshare_page(struct do
         BUG();
     }
 
-    list_for_each(le, &page->sharing->gfns)
+    gfn_info = rmap_retrieve(d->domain_id, gfn, page);
+    if ( unlikely(gfn_info == NULL) )
     {
-        gfn_info = list_entry(le, gfn_info_t, list);
-        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
-            goto gfn_found;
+        gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                                "%lx\n", gfn);
+        BUG();
     }
-    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
-                            "%lx\n", gfn);
-    BUG();
 
-gfn_found:
     /* Do the accounting first. If anything fails below, we have bigger
      * bigger fish to fry. First, remove the gfn from the list. */ 
-    last_gfn = list_has_one_entry(&page->sharing->gfns);
+    last_gfn = rmap_has_one_entry(page);
     if ( last_gfn )
     {
         /* Clean up shared state. Get rid of the <domid, gfn> tuple
          * before destroying the rmap. */
-        mem_sharing_gfn_destroy(d, gfn_info);
-        audit_del_list(page);
+        mem_sharing_gfn_destroy(page, d, gfn_info);
+        page_sharing_dispose(page);
         page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
+
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         if ( !last_gfn )
-            mem_sharing_gfn_destroy(d, gfn_info);
+            mem_sharing_gfn_destroy(page, d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -1013,7 +1075,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
-    mem_sharing_gfn_destroy(d, gfn_info);
+    mem_sharing_gfn_destroy(old_page, d, gfn_info);
     mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMleR-0008EC-Q7; Tue, 24 Apr 2012 19:43:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMleQ-0008Dk-DT
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 19:43:50 +0000
Received: from [85.158.143.99:45099] by server-3.bemta-4.messagelabs.com id
	97/F4-05853-572079F4; Tue, 24 Apr 2012 19:43:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335296628!19831049!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4NzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14228 invoked from network); 24 Apr 2012 19:43:48 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-216.messagelabs.com with SMTP;
	24 Apr 2012 19:43:48 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 649BC1A8076;
	Tue, 24 Apr 2012 12:43:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ZrV7rbjR41uFMDjUUBcQ66gvtQxHR/XAo93bTckFqfTO
	UBLSDgN6JhsdJfjx9WK58hlFaBb0hWSlVKGtm9AO79VIGSdIzKZ9QQtfRfLXdBni
	3041UFMg9UcBZoSN+A2FzOEcHxwO1ZLxO8rL4cLiu+EbGzsWA0YonFxOjifken0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=21vh70cqRAgFqgZRDr5rcRx0ctY=; b=RfWUw9fhY/N
	jJz9IklTEoANBglnK6SAKehyUV0CJnFKaTgNjrPy+cDbkYRqJtykBzPZkSAiU2Lv
	PKFrxPRL2HiaZxJQbQJkWwB1nYkeLpawUQyeiTIMXkJqQEtcfjqJVQZYfx3PpsT2
	rj2bJJotgfaxL29zqJUf9DhpgWVm3FQ8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id B0AE81A808E; 
	Tue, 24 Apr 2012 12:43:46 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5965a38564fcaf5240a3422d46a4e237b1a544c2
Message-Id: <5965a38564fcaf5240a3.1335296902@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 24 Apr 2012 15:48:22 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 3] x86/mem_sharing: modularize reverse map
 for shared frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_sharing.c |  138 ++++++++++++++++++++++++++++++-----------
 1 files changed, 100 insertions(+), 38 deletions(-)


Each shared frame maintains a reverse map of <domain, gfn> tuples, so we know
which tuples this shared frame is backing. This is useful for auditing and
sanity-checking, and necessary to update all relevant p2m entries when sharing.

The reverse map is maintained as a doubly linked list, but the interface is
open-coded throughout the mem_sharing.c subsystem. Bury it inside a level of
abstraction, so it can later support different (more scalable) rmap
implementations.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 796b523346ac -r 5965a38564fc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -69,7 +69,8 @@ static inline void audit_add_list(struct
     spin_unlock(&shr_audit_lock);
 }
 
-static inline void audit_del_list(struct page_info *page)
+/* Removes from the audit list and cleans up the page sharing metadata. */
+static inline void page_sharing_dispose(struct page_info *page)
 {
     spin_lock(&shr_audit_lock);
     list_del_rcu(&page->sharing->entry);
@@ -86,7 +87,7 @@ int mem_sharing_audit(void)
 }
 
 #define audit_add_list(p)  ((void)0)
-static inline void audit_del_list(struct page_info *page)
+static inline void page_sharing_dispose(struct page_info *page)
 {
     xfree(page->sharing);
 }
@@ -143,6 +144,7 @@ static inline shr_handle_t get_next_hand
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
+/** Reverse map **/
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -150,15 +152,77 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-/* Returns true if list has only one entry. O(1) complexity. */
-static inline int list_has_one_entry(struct list_head *head)
+static inline void
+rmap_init(struct page_info *page)
 {
+    INIT_LIST_HEAD(&page->sharing->gfns);
+}
+
+static inline void
+rmap_del(gfn_info_t *gfn_info, struct page_info *page)
+{
+    list_del(&gfn_info->list);
+}
+
+static inline void
+rmap_add(gfn_info_t *gfn_info, struct page_info *page)
+{
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->sharing->gfns);
+}
+
+static inline gfn_info_t *
+rmap_retrieve(uint16_t domain_id, unsigned long gfn, 
+                            struct page_info *page)
+{
+    gfn_info_t *gfn_info;
+    struct list_head *le;
+    list_for_each(le, &page->sharing->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == domain_id) )
+            return gfn_info;
+    }
+    return NULL;
+}
+
+/* Returns true if the rmap has only one entry. O(1) complexity. */
+static inline int rmap_has_one_entry(struct page_info *page)
+{
+    struct list_head *head = &page->sharing->gfns;
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline gfn_info_t *gfn_get_info(struct list_head *list)
+/* Returns true if the rmap has any entries. O(1) complexity. */
+static inline int rmap_has_entries(struct page_info *page)
 {
-    return list_entry(list->next, gfn_info_t, list);
+    return (!list_empty(&page->sharing->gfns));
+}
+
+/* The iterator hides the details of how the rmap is implemented. This
+ * involves splitting the list_for_each_safe macro into two steps. */
+struct rmap_iterator {
+    struct list_head *curr;
+    struct list_head *next;
+};
+
+static inline void
+rmap_seed_iterator(struct page_info *page, struct rmap_iterator *ri)
+{
+    ri->curr = &page->sharing->gfns;
+    ri->next = ri->curr->next; 
+}
+
+static inline gfn_info_t *
+rmap_iterate(struct page_info *page, struct rmap_iterator *ri)
+{
+    if ( ri->next == &page->sharing->gfns)
+        return NULL;
+
+    ri->curr = ri->next;
+    ri->next = ri->curr->next;
+
+    return list_entry(ri->curr, gfn_info_t, list);
 }
 
 static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
@@ -172,8 +236,8 @@ static inline gfn_info_t *mem_sharing_gf
 
     gfn_info->gfn = gfn;
     gfn_info->domain = d->domain_id;
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &page->sharing->gfns);
+
+    rmap_add(gfn_info, page);
 
     /* Increment our number of shared pges. */
     atomic_inc(&d->shr_pages);
@@ -181,14 +245,15 @@ static inline gfn_info_t *mem_sharing_gf
     return gfn_info;
 }
 
-static inline void mem_sharing_gfn_destroy(struct domain *d,
+static inline void mem_sharing_gfn_destroy(struct page_info *page,
+                                           struct domain *d,
                                            gfn_info_t *gfn_info)
 {
     /* Decrement the number of pages. */
     atomic_dec(&d->shr_pages);
 
     /* Free the gfn_info structure. */
-    list_del(&gfn_info->list);
+    rmap_del(gfn_info, page);
     xfree(gfn_info);
 }
 
@@ -230,8 +295,9 @@ int mem_sharing_audit(void)
         struct page_sharing_info *pg_shared_info;
         unsigned long nr_gfns = 0;
         struct page_info *pg;
-        struct list_head *le;
         mfn_t mfn;
+        gfn_info_t *g;
+        struct rmap_iterator ri;
 
         pg_shared_info = list_entry(ae, struct page_sharing_info, entry);
         pg = pg_shared_info->pg;
@@ -272,7 +338,7 @@ int mem_sharing_audit(void)
         }
 
         /* Check we have a list */
-        if ( (!pg->sharing) || (list_empty(&pg->sharing->gfns)) )
+        if ( (!pg->sharing) || !rmap_has_entries(pg) )
         {
            MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
                              mfn_x(mfn));
@@ -284,14 +350,13 @@ int mem_sharing_audit(void)
         count_found++;
 
         /* Check if all GFNs map to the MFN, and the p2m types */
-        list_for_each(le, &pg->sharing->gfns)
+        rmap_seed_iterator(pg, &ri);
+        while ( (g = rmap_iterate(pg, &ri)) != NULL )
         {
             struct domain *d;
             p2m_type_t t;
             mfn_t o_mfn;
-            gfn_info_t *g;
 
-            g = list_entry(le, gfn_info_t, list);
             d = get_domain_by_id(g->domain);
             if ( d == NULL )
             {
@@ -677,7 +742,7 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
     page->sharing->pg = page;
-    INIT_LIST_HEAD(&page->sharing->gfns);
+    rmap_init(page);
 
     /* Create the handle */
     page->sharing->handle = get_next_handle();  
@@ -698,7 +763,7 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
-        mem_sharing_gfn_destroy(d, gfn_info);
+        mem_sharing_gfn_destroy(page, d, gfn_info);
         xfree(page->sharing);
         page->sharing = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
@@ -726,13 +791,13 @@ int mem_sharing_share_pages(struct domai
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
     struct page_info *spage, *cpage, *firstpg, *secondpg;
-    struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
     struct two_gfns tg;
+    struct rmap_iterator ri;
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, NULL, &cmfn,
@@ -799,15 +864,15 @@ int mem_sharing_share_pages(struct domai
     }
 
     /* Merge the lists together */
-    list_for_each_safe(le, te, &cpage->sharing->gfns)
+    rmap_seed_iterator(cpage, &ri);
+    while ( (gfn = rmap_iterate(cpage, &ri)) != NULL)
     {
-        gfn = list_entry(le, gfn_info_t, list);
         /* Get the source page and type, this should never fail: 
          * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
         /* Move the gfn_info from client list to source list */
-        list_del(&gfn->list);
-        list_add(&gfn->list, &spage->sharing->gfns);
+        rmap_del(gfn, cpage);
+        rmap_add(gfn, spage);
         put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
@@ -817,7 +882,7 @@ int mem_sharing_share_pages(struct domai
     ASSERT(list_empty(&cpage->sharing->gfns));
 
     /* Clear the rest of the shared state */
-    audit_del_list(cpage);
+    page_sharing_dispose(cpage);
     cpage->sharing = NULL;
 
     mem_sharing_page_unlock(secondpg);
@@ -887,7 +952,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( !ret )
     {
         ret = -ENOENT;
-        mem_sharing_gfn_destroy(cd, gfn_info);
+        mem_sharing_gfn_destroy(spage, cd, gfn_info);
         put_page_and_type(spage);
     } else {
         ret = 0;
@@ -929,7 +994,6 @@ int __mem_sharing_unshare_page(struct do
     void *s, *t;
     int last_gfn;
     gfn_info_t *gfn_info = NULL;
-    struct list_head *le;
    
     mfn = get_gfn(d, gfn, &p2mt);
     
@@ -947,37 +1011,35 @@ int __mem_sharing_unshare_page(struct do
         BUG();
     }
 
-    list_for_each(le, &page->sharing->gfns)
+    gfn_info = rmap_retrieve(d->domain_id, gfn, page);
+    if ( unlikely(gfn_info == NULL) )
     {
-        gfn_info = list_entry(le, gfn_info_t, list);
-        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
-            goto gfn_found;
+        gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                                "%lx\n", gfn);
+        BUG();
     }
-    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
-                            "%lx\n", gfn);
-    BUG();
 
-gfn_found:
     /* Do the accounting first. If anything fails below, we have bigger
      * bigger fish to fry. First, remove the gfn from the list. */ 
-    last_gfn = list_has_one_entry(&page->sharing->gfns);
+    last_gfn = rmap_has_one_entry(page);
     if ( last_gfn )
     {
         /* Clean up shared state. Get rid of the <domid, gfn> tuple
          * before destroying the rmap. */
-        mem_sharing_gfn_destroy(d, gfn_info);
-        audit_del_list(page);
+        mem_sharing_gfn_destroy(page, d, gfn_info);
+        page_sharing_dispose(page);
         page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
+
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         if ( !last_gfn )
-            mem_sharing_gfn_destroy(d, gfn_info);
+            mem_sharing_gfn_destroy(page, d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -1013,7 +1075,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
-    mem_sharing_gfn_destroy(d, gfn_info);
+    mem_sharing_gfn_destroy(old_page, d, gfn_info);
     mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlhZ-0000D5-2G; Tue, 24 Apr 2012 19:47:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMlhX-0000Cl-Cv
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 19:47:03 +0000
Received: from [85.158.139.83:48518] by server-5.bemta-5.messagelabs.com id
	24/65-13566-633079F4; Tue, 24 Apr 2012 19:47:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335296821!14054888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16452 invoked from network); 24 Apr 2012 19:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 19:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12115935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 19:47:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 20:47:00 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMlhU-0008CK-LM;
	Tue, 24 Apr 2012 19:47:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMlhU-00018O-Hn;
	Tue, 24 Apr 2012 20:47:00 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12742-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 20:47:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12742: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12742 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12742/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12739
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 12739

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 19:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 19:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlhZ-0000D5-2G; Tue, 24 Apr 2012 19:47:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMlhX-0000Cl-Cv
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 19:47:03 +0000
Received: from [85.158.139.83:48518] by server-5.bemta-5.messagelabs.com id
	24/65-13566-633079F4; Tue, 24 Apr 2012 19:47:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335296821!14054888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16452 invoked from network); 24 Apr 2012 19:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 19:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="12115935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 19:47:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Apr 2012 20:47:00 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMlhU-0008CK-LM;
	Tue, 24 Apr 2012 19:47:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMlhU-00018O-Hn;
	Tue, 24 Apr 2012 20:47:00 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12742-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Apr 2012 20:47:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12742: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12742 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12742/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12739
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 12739

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 20:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 20:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlyk-0000bl-SA; Tue, 24 Apr 2012 20:04:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SMlyj-0000bg-95
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 20:04:49 +0000
Received: from [193.109.254.147:61499] by server-1.bemta-14.messagelabs.com id
	05/70-29372-067079F4; Tue, 24 Apr 2012 20:04:48 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335297887!6094002!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12319 invoked from network); 24 Apr 2012 20:04:48 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 20:04:48 -0000
Received: by eekc13 with SMTP id c13so129675eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 13:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=QfoH4MgHopU1c4U3KOP4eJGlkWovgWvjVfrTuEZic1M=;
	b=CYhKGReTGpnZlHSUWHg7KUD7Jej9EUMKewxe2+J+gJlS+GdaoGP1wRu0aDAb0cZO06
	dhLupPwQmxzFIBAwSwyePBxgaJrwm+jYyPiJliprLgZJNcl/wDXbjN+c4lYN/PoQSZSO
	gXaHob+PcE6CdtEk4CDQxy/33Thwjv4CnAaDq9bE9bgFqFH/BQpT6HWtQKqTrktL19Qq
	1O7KefD87+6BUZsRknf+JlDOSm4lAUKAtfAXxxdsGC2TYsaVaOsxlgyB6D3COk+Qx2uz
	flk5AlD6/h0HLFT3puMUL/IfQw2Asgue9P6uQNUO/rZcHEToVElQsLojA6kHcZq8B6pj
	OuGg==
MIME-Version: 1.0
Received: by 10.14.94.139 with SMTP id n11mr3693832eef.47.1335297887606; Tue,
	24 Apr 2012 13:04:47 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Tue, 24 Apr 2012 13:04:47 -0700 (PDT)
In-Reply-To: <4F953D7B.2090608@citrix.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<4F953D7B.2090608@citrix.com>
Date: Tue, 24 Apr 2012 22:04:47 +0200
Message-ID: <CAFoWEVMsz+qe7Ap7vGYZi6M5a6tiGneD9JdNEfWUDJdRtgjkKA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1430365301800972487=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1430365301800972487==
Content-Type: multipart/alternative; boundary=bcaec52be657429a1a04be724414

--bcaec52be657429a1a04be724414
Content-Type: text/plain; charset=ISO-8859-1

>
> I think the test you have done here is as a regular user (because I see
> the $ instead of #), could you execute the same command as you would call
> xl (either as root or with sudo)?
>
> Yes, I did not notice that, but I was logged on as root. I
was fiddling the prompt colours and I made a mistake for the root PS1
properties. I am still learning about the linux environment. :)

Regards

Sandi

--bcaec52be657429a1a04be724414
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">I think the test you have done here is as a regular user (because=
 I see the $ instead of #), could you execute the same command as you would=
 call xl (either as root or with sudo)?<div class=3D"HOEnZb">
<div class=3D"h5"><br></div></div></blockquote><div>Yes, I did not notice t=
hat, but I was logged on as root. I was=A0fiddling=A0the prompt colours and=
 I made a mistake for the root PS1 properties. I am still learning about th=
e linux environment. :)</div>
<div><br></div><div>Regards</div><div><br></div><div>Sandi</div></div></div=
>

--bcaec52be657429a1a04be724414--


--===============1430365301800972487==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1430365301800972487==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 20:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 20:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMlyk-0000bl-SA; Tue, 24 Apr 2012 20:04:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SMlyj-0000bg-95
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 20:04:49 +0000
Received: from [193.109.254.147:61499] by server-1.bemta-14.messagelabs.com id
	05/70-29372-067079F4; Tue, 24 Apr 2012 20:04:48 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335297887!6094002!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12319 invoked from network); 24 Apr 2012 20:04:48 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 20:04:48 -0000
Received: by eekc13 with SMTP id c13so129675eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 13:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=QfoH4MgHopU1c4U3KOP4eJGlkWovgWvjVfrTuEZic1M=;
	b=CYhKGReTGpnZlHSUWHg7KUD7Jej9EUMKewxe2+J+gJlS+GdaoGP1wRu0aDAb0cZO06
	dhLupPwQmxzFIBAwSwyePBxgaJrwm+jYyPiJliprLgZJNcl/wDXbjN+c4lYN/PoQSZSO
	gXaHob+PcE6CdtEk4CDQxy/33Thwjv4CnAaDq9bE9bgFqFH/BQpT6HWtQKqTrktL19Qq
	1O7KefD87+6BUZsRknf+JlDOSm4lAUKAtfAXxxdsGC2TYsaVaOsxlgyB6D3COk+Qx2uz
	flk5AlD6/h0HLFT3puMUL/IfQw2Asgue9P6uQNUO/rZcHEToVElQsLojA6kHcZq8B6pj
	OuGg==
MIME-Version: 1.0
Received: by 10.14.94.139 with SMTP id n11mr3693832eef.47.1335297887606; Tue,
	24 Apr 2012 13:04:47 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Tue, 24 Apr 2012 13:04:47 -0700 (PDT)
In-Reply-To: <4F953D7B.2090608@citrix.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<4F953D7B.2090608@citrix.com>
Date: Tue, 24 Apr 2012 22:04:47 +0200
Message-ID: <CAFoWEVMsz+qe7Ap7vGYZi6M5a6tiGneD9JdNEfWUDJdRtgjkKA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1430365301800972487=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1430365301800972487==
Content-Type: multipart/alternative; boundary=bcaec52be657429a1a04be724414

--bcaec52be657429a1a04be724414
Content-Type: text/plain; charset=ISO-8859-1

>
> I think the test you have done here is as a regular user (because I see
> the $ instead of #), could you execute the same command as you would call
> xl (either as root or with sudo)?
>
> Yes, I did not notice that, but I was logged on as root. I
was fiddling the prompt colours and I made a mistake for the root PS1
properties. I am still learning about the linux environment. :)

Regards

Sandi

--bcaec52be657429a1a04be724414
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">I think the test you have done here is as a regular user (because=
 I see the $ instead of #), could you execute the same command as you would=
 call xl (either as root or with sudo)?<div class=3D"HOEnZb">
<div class=3D"h5"><br></div></div></blockquote><div>Yes, I did not notice t=
hat, but I was logged on as root. I was=A0fiddling=A0the prompt colours and=
 I made a mistake for the root PS1 properties. I am still learning about th=
e linux environment. :)</div>
<div><br></div><div>Regards</div><div><br></div><div>Sandi</div></div></div=
>

--bcaec52be657429a1a04be724414--


--===============1430365301800972487==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1430365301800972487==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 20:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 20:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMmDa-0000uX-Br; Tue, 24 Apr 2012 20:20:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMmDY-0000uS-As
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 20:20:08 +0000
Received: from [85.158.143.35:15585] by server-2.bemta-4.messagelabs.com id
	D9/C1-17550-7FA079F4; Tue, 24 Apr 2012 20:20:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335298806!14761128!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18812 invoked from network); 24 Apr 2012 20:20:06 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 20:20:06 -0000
Received: by wibhq7 with SMTP id hq7so5084594wib.14
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 13:20:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=dDL0BhYGsrR/174QYgClU8H7wDUH/2P7KGvqD0+m1B0=;
	b=KkAS00RrUYNgK7d7weLe+zMYsbNvx5Vu8RPIC1bFXMueYwNyiDejfLpgqjQTI9VSZQ
	VyaNPBUQqbAIiA8PoMzWy/XXtNj59h/PnzluSspNqgCXIUyZFNlnIsBdoT5dtPSDHX2b
	/Ya8dCYaM7cQjyK1WL/s1i3+tnMDrhK40IoLZCOGBJHfUmtWL9iBmtNTy8gqLLEmC0Up
	gBEUeKYZ3VZqZy/EMTA/0xBTXi7OSvC1JH11Kq6KAzU55FA9Hbyehcv6QcuIbNHlsJcN
	F/XmPxDnbGG7P2ndKH8W6stiGO5k8MyV46dtjO8t4XqKqJA79lE17rJeU0JOoyV1QcrR
	Omzg==
Received: by 10.180.85.70 with SMTP id f6mr34692229wiz.5.1335298806397;
	Tue, 24 Apr 2012 13:20:06 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id ca3sm32044057wib.6.2012.04.24.13.20.04
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 13:20:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 24 Apr 2012 21:20:02 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CBBCC982.31764%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
Thread-Index: Ac0iV6DdpwvelWVZPkGVAK5nErd4ww==
In-Reply-To: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>> as a new function table entry, or pay the price of calling
>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>> the case of the subject vCPU being current.
>> =

>> OK, I will try introducing a new wrapper that will return
>> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.
> =

> Jan,
> =

> How does this look?

Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
patch won't compile on i386, as you have inconsistently ifdef'ed. Just
remove the ifdefs as far as possible, we'd rather have dead code on i386
than ifdefs.

 -- Keir

> PS: Come submission time, I will send it out as two separate patches.
> =

> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>          hvm_get_segment_register(v, x86_seg_ss, &sreg);
>          c.nat->user_regs.ss =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_ds, &sreg);
>          c.nat->user_regs.ds =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_es, &sreg);
>          c.nat->user_regs.es =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs =3D sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base =3D sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs =3D sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +        {
> +            c.nat->gs_base_kernel =3D sreg.base;
> +            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
> +        }
> +        else
> +        {
> +            c.nat->gs_base_user =3D sreg.base;
> +            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
> +        }
> +#endif
>      }
>      else
>      {
>          c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>          c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>          for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
>              c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
>  #ifdef CONFIG_COMPAT
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -640,16 +640,25 @@ static void svm_set_segment_register(str
>      default:
>          BUG();
>      }
> =

>      if ( sync )
>          svm_vmload(vmcb);
>  }
> =

> +#ifdef __x86_64__
> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
> +{
> +    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> +
> +    return vmcb->kerngsbase;
> +}
> +#endif
> +
>  static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> =

>      if ( !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmcb_set_g_pat(vmcb, gpat);
> @@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D svm_vcpu_destroy,
>      .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
>      .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
>      .get_interrupt_shadow =3D svm_get_interrupt_shadow,
>      .set_interrupt_shadow =3D svm_set_interrupt_shadow,
>      .guest_x86_mode       =3D svm_guest_x86_mode,
>      .get_segment_register =3D svm_get_segment_register,
>      .set_segment_register =3D svm_set_segment_register,
> +    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
>      .update_host_cr3      =3D svm_update_host_cr3,
>      .update_guest_cr      =3D svm_update_guest_cr,
>      .update_guest_efer    =3D svm_update_guest_efer,
>      .set_guest_pat        =3D svm_set_guest_pat,
>      .get_guest_pat        =3D svm_get_guest_pat,
>      .set_tsc_offset       =3D svm_set_tsc_offset,
>      .inject_exception     =3D svm_inject_exception,
>      .init_hypercall_page  =3D svm_init_hypercall_page,
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
>          break;
>      default:
>          BUG();
>      }
> =

>      vmx_vmcs_exit(v);
>  }
> =

> +#ifdef __x86_64__
> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
> +{
> +    return v->arch.hvm_vmx.shadow_gs;
> +}
> +#endif
> +
>  static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmx_vmcs_enter(v);
>      __vmwrite(GUEST_PAT, gpat);
>  #ifdef __i386__
> @@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D vmx_vcpu_destroy,
>      .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
>      .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
>      .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>      .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>      .guest_x86_mode       =3D vmx_guest_x86_mode,
>      .get_segment_register =3D vmx_get_segment_register,
>      .set_segment_register =3D vmx_set_segment_register,
> +    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
>      .update_host_cr3      =3D vmx_update_host_cr3,
>      .update_guest_cr      =3D vmx_update_guest_cr,
>      .update_guest_efer    =3D vmx_update_guest_efer,
>      .set_guest_pat        =3D vmx_set_guest_pat,
>      .get_guest_pat        =3D vmx_get_guest_pat,
>      .set_tsc_offset       =3D vmx_set_tsc_offset,
>      .inject_exception     =3D vmx_inject_exception,
>      .init_hypercall_page  =3D vmx_init_hypercall_page,
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -101,16 +101,19 @@ struct hvm_function_table {
>      /* Examine specifics of the guest state. */
>      unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>      void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shado=
w);
>      int (*guest_x86_mode)(struct vcpu *v);
>      void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
>      void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
> +#ifdef __x86_64__
> +    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
> +#endif
> =

>      /*
>       * Re-set the value of CR3 that Xen runs on when handling VM exits.
>       */
>      void (*update_host_cr3)(struct vcpu *v);
> =

>      /*
>       * Called to inform HVM layer that a guest CRn or EFER has changed.
> @@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,
> =

>  static inline void
>  hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>                           struct segment_register *reg)
>  {
>      hvm_funcs.set_segment_register(v, seg, reg);
>  }
> =

> +#ifdef __x86_64__
> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
> +{
> +    return hvm_funcs.get_shadow_gs_base(v);
> +}
> +#endif
> +
>  #define is_viridian_domain(_d)                                          =
   \
>   (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]=
))
> =

>  void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
>                                     unsigned int *ecx, unsigned int *edx);
>  void hvm_migrate_timers(struct vcpu *v);
>  void hvm_do_resume(struct vcpu *v);
>  void hvm_migrate_pirqs(struct vcpu *v);
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 20:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 20:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMmDa-0000uX-Br; Tue, 24 Apr 2012 20:20:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMmDY-0000uS-As
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 20:20:08 +0000
Received: from [85.158.143.35:15585] by server-2.bemta-4.messagelabs.com id
	D9/C1-17550-7FA079F4; Tue, 24 Apr 2012 20:20:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335298806!14761128!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18812 invoked from network); 24 Apr 2012 20:20:06 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 20:20:06 -0000
Received: by wibhq7 with SMTP id hq7so5084594wib.14
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 13:20:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=dDL0BhYGsrR/174QYgClU8H7wDUH/2P7KGvqD0+m1B0=;
	b=KkAS00RrUYNgK7d7weLe+zMYsbNvx5Vu8RPIC1bFXMueYwNyiDejfLpgqjQTI9VSZQ
	VyaNPBUQqbAIiA8PoMzWy/XXtNj59h/PnzluSspNqgCXIUyZFNlnIsBdoT5dtPSDHX2b
	/Ya8dCYaM7cQjyK1WL/s1i3+tnMDrhK40IoLZCOGBJHfUmtWL9iBmtNTy8gqLLEmC0Up
	gBEUeKYZ3VZqZy/EMTA/0xBTXi7OSvC1JH11Kq6KAzU55FA9Hbyehcv6QcuIbNHlsJcN
	F/XmPxDnbGG7P2ndKH8W6stiGO5k8MyV46dtjO8t4XqKqJA79lE17rJeU0JOoyV1QcrR
	Omzg==
Received: by 10.180.85.70 with SMTP id f6mr34692229wiz.5.1335298806397;
	Tue, 24 Apr 2012 13:20:06 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id ca3sm32044057wib.6.2012.04.24.13.20.04
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 13:20:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 24 Apr 2012 21:20:02 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CBBCC982.31764%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
Thread-Index: Ac0iV6DdpwvelWVZPkGVAK5nErd4ww==
In-Reply-To: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>> as a new function table entry, or pay the price of calling
>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>> the case of the subject vCPU being current.
>> =

>> OK, I will try introducing a new wrapper that will return
>> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.
> =

> Jan,
> =

> How does this look?

Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
patch won't compile on i386, as you have inconsistently ifdef'ed. Just
remove the ifdefs as far as possible, we'd rather have dead code on i386
than ifdefs.

 -- Keir

> PS: Come submission time, I will send it out as two separate patches.
> =

> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>          hvm_get_segment_register(v, x86_seg_ss, &sreg);
>          c.nat->user_regs.ss =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_ds, &sreg);
>          c.nat->user_regs.ds =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_es, &sreg);
>          c.nat->user_regs.es =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs =3D sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base =3D sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs =3D sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +        {
> +            c.nat->gs_base_kernel =3D sreg.base;
> +            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
> +        }
> +        else
> +        {
> +            c.nat->gs_base_user =3D sreg.base;
> +            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
> +        }
> +#endif
>      }
>      else
>      {
>          c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>          c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>          for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
>              c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
>  #ifdef CONFIG_COMPAT
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -640,16 +640,25 @@ static void svm_set_segment_register(str
>      default:
>          BUG();
>      }
> =

>      if ( sync )
>          svm_vmload(vmcb);
>  }
> =

> +#ifdef __x86_64__
> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
> +{
> +    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> +
> +    return vmcb->kerngsbase;
> +}
> +#endif
> +
>  static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> =

>      if ( !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmcb_set_g_pat(vmcb, gpat);
> @@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D svm_vcpu_destroy,
>      .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
>      .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
>      .get_interrupt_shadow =3D svm_get_interrupt_shadow,
>      .set_interrupt_shadow =3D svm_set_interrupt_shadow,
>      .guest_x86_mode       =3D svm_guest_x86_mode,
>      .get_segment_register =3D svm_get_segment_register,
>      .set_segment_register =3D svm_set_segment_register,
> +    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
>      .update_host_cr3      =3D svm_update_host_cr3,
>      .update_guest_cr      =3D svm_update_guest_cr,
>      .update_guest_efer    =3D svm_update_guest_efer,
>      .set_guest_pat        =3D svm_set_guest_pat,
>      .get_guest_pat        =3D svm_get_guest_pat,
>      .set_tsc_offset       =3D svm_set_tsc_offset,
>      .inject_exception     =3D svm_inject_exception,
>      .init_hypercall_page  =3D svm_init_hypercall_page,
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
>          break;
>      default:
>          BUG();
>      }
> =

>      vmx_vmcs_exit(v);
>  }
> =

> +#ifdef __x86_64__
> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
> +{
> +    return v->arch.hvm_vmx.shadow_gs;
> +}
> +#endif
> +
>  static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmx_vmcs_enter(v);
>      __vmwrite(GUEST_PAT, gpat);
>  #ifdef __i386__
> @@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D vmx_vcpu_destroy,
>      .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
>      .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
>      .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>      .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>      .guest_x86_mode       =3D vmx_guest_x86_mode,
>      .get_segment_register =3D vmx_get_segment_register,
>      .set_segment_register =3D vmx_set_segment_register,
> +    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
>      .update_host_cr3      =3D vmx_update_host_cr3,
>      .update_guest_cr      =3D vmx_update_guest_cr,
>      .update_guest_efer    =3D vmx_update_guest_efer,
>      .set_guest_pat        =3D vmx_set_guest_pat,
>      .get_guest_pat        =3D vmx_get_guest_pat,
>      .set_tsc_offset       =3D vmx_set_tsc_offset,
>      .inject_exception     =3D vmx_inject_exception,
>      .init_hypercall_page  =3D vmx_init_hypercall_page,
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -101,16 +101,19 @@ struct hvm_function_table {
>      /* Examine specifics of the guest state. */
>      unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>      void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shado=
w);
>      int (*guest_x86_mode)(struct vcpu *v);
>      void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
>      void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
> +#ifdef __x86_64__
> +    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
> +#endif
> =

>      /*
>       * Re-set the value of CR3 that Xen runs on when handling VM exits.
>       */
>      void (*update_host_cr3)(struct vcpu *v);
> =

>      /*
>       * Called to inform HVM layer that a guest CRn or EFER has changed.
> @@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,
> =

>  static inline void
>  hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>                           struct segment_register *reg)
>  {
>      hvm_funcs.set_segment_register(v, seg, reg);
>  }
> =

> +#ifdef __x86_64__
> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
> +{
> +    return hvm_funcs.get_shadow_gs_base(v);
> +}
> +#endif
> +
>  #define is_viridian_domain(_d)                                          =
   \
>   (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]=
))
> =

>  void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
>                                     unsigned int *ecx, unsigned int *edx);
>  void hvm_migrate_timers(struct vcpu *v);
>  void hvm_do_resume(struct vcpu *v);
>  void hvm_migrate_pirqs(struct vcpu *v);
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 20:29:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 20:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMmMA-00015U-Hy; Tue, 24 Apr 2012 20:29:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SMmM9-00015P-Cn
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 20:29:01 +0000
Received: from [193.109.254.147:64306] by server-10.bemta-14.messagelabs.com
	id A8/A2-05847-C0D079F4; Tue, 24 Apr 2012 20:29:00 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335299339!6181780!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13178 invoked from network); 24 Apr 2012 20:28:59 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 20:28:59 -0000
Received: by eekc13 with SMTP id c13so136875eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 13:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9cKLQEkPk0o3F394Aj+JGDILCe9WAGJY4n1XEhvTLX4=;
	b=CEPBLhtBQZmTio6hDGd9L2nDaJN608o7qwlS/oynnAfruW1ib4BW9XfskW+Bb27MQw
	PKevZyiw6vve/DCeVYkm3iLPrxiKPj67LqJ7okMJFIRACVevtipltGrGQbA1Nvs4Pwyl
	YD+exOkjxWPlcR5DbH75TavtLfdTJP5zVmINeHQThtNVibsWnF5VrudQRcMsY01TTlJq
	MGJNoG7tRG1+I2mBhkoz84EOS0MqYVLmO5QJWcIPEWipeAmBF9868FUn6OLRxEBBTU8o
	ICIy8WIjAGFydxQHUAAM9sukHZRKsrexYI2UycRzbI+SpkXg44FJ9oTnrb4M0RG+vKv3
	gnng==
MIME-Version: 1.0
Received: by 10.213.112.142 with SMTP id w14mr34597ebp.24.1335299339439; Tue,
	24 Apr 2012 13:28:59 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Tue, 24 Apr 2012 13:28:59 -0700 (PDT)
In-Reply-To: <1335180628.4347.1.camel@zakaz.uk.xensource.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 22:28:59 +0200
Message-ID: <CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7000308292207593199=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7000308292207593199==
Content-Type: multipart/alternative; boundary=0015174c1234cbcf8504be729aa6

--0015174c1234cbcf8504be729aa6
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 23, 2012 at 1:30 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-04-23 at 12:29 +0100, Stefano Stabellini wrote:
> > On Mon, 23 Apr 2012, Ian Campbell wrote:
> > > On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> > > > [...]
> > >
> > > >  kernel = "/etc/xen/kernels/oi151a/unix"
> > > >  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
> > >
> > > I forget how this works -- do you need to comment these out while using
> > > pygrub or are these paths inside the ISO?
> > > [...]
> > > >  disk =
> > > > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > > > 'phy:/dev/dom0/oi_boot,xvda,w' ]
> > > >  bootloader = "/usr/bin/pygrub"
> > >
> > > Sadly I don't think xl is currently capable of booting using pygrub
> from
> > > a file:/// type device.
> >
> > > I expect this will be resolved by Stefano's "qdisk local attach" series
> > > which was on the list last week.
> >
> > Actually, even without my patch series, xl should be able to boot a PV
> > guest using pygrub if (and only if) the disk is a raw file.
>
> Yes, I've just realised that while editing
> http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installeras part of the dos day -- it seems to work for me at least.
>
> Perhaps the issue here is the use of kernel= and ramdisk= instead of
> bootloader_args? (see the new CD install section of that Debian install
> guide for an example of the sort of thing which works for me)
>
> Ian.
>
> >
> >
> > > In the meantime as a workaround you could try using losetup on the iso
> > > and pointing xl at phy:/dev/loop$N.
> >
> > that should also work
>
>
> Hello guys,

Thanks for the responses.

I have been doing some testing, to see if I could find out what could be
causing the problem.
I have, once again, reinstalled the whole system as I wanted a clean
system, and now I can get the system to create my openindiana VM (with the
bootloader property in the cfg file), however it will not boot fully.

What I did discover is that the VM boot is halted by the vif option in my
cfg file. If I comment it out, the vm boots fine, but of course I cant
complete the install without the network IF present.
I tried creating a different networking architecture as laid out in the xen
wiki's, but with no difference in the behavior.
Occasionally I would get errors in the VM regarding network IF not being
correctly initialized (or something to that extent), which reinforces my
suspicions regarding networking causing the problems

I had all this working in my initial setup, 3.1.9 kernel with xen 4.2
unstable 14785, now I am running kernel 3.1.10. The major differences are
that before I used a file based disk image while now I am using LVM disk
image (or partition), and that I did not patch xen with the Solaris pvgrub
patch. My current disk definition is:

 disk = [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
'phy:/dev/xen-dom0/oi_boot,xvda,w' ]

Have I perhaps made an error here?

Hope that I have not rambled on too much and confused you.

Best regards

Sandi

--0015174c1234cbcf8504be729aa6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Apr 2=
3, 2012 at 1:30 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, 2012-04-23 at 12:2=
9 +0100, Stefano Stabellini wrote:<br>
&gt; On Mon, 23 Apr 2012, Ian Campbell wrote:<br>
&gt; &gt; On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:<br>
&gt; &gt; &gt; [...]<br>
&gt; &gt;<br>
&gt; &gt; &gt; =A0kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot;<br>
&gt; &gt; &gt; =A0ramdisk =3D &quot;/etc/xen/kernels/oi151a/boot_archive&qu=
ot;<br>
&gt; &gt;<br>
&gt; &gt; I forget how this works -- do you need to comment these out while=
 using<br>
&gt; &gt; pygrub or are these paths inside the ISO?<br>
&gt; &gt; [...]<br>
&gt; &gt; &gt; =A0disk =3D<br>
&gt; &gt; &gt; [ &#39;file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdr=
om,r&#39; ,<br>
&gt; &gt; &gt; &#39;phy:/dev/dom0/oi_boot,xvda,w&#39; ]<br>
&gt; &gt; &gt; =A0bootloader =3D &quot;/usr/bin/pygrub&quot;<br>
&gt; &gt;<br>
&gt; &gt; Sadly I don&#39;t think xl is currently capable of booting using =
pygrub from<br>
&gt; &gt; a file:/// type device.<br>
&gt;<br>
&gt; &gt; I expect this will be resolved by Stefano&#39;s &quot;qdisk local=
 attach&quot; series<br>
&gt; &gt; which was on the list last week.<br>
&gt;<br>
&gt; Actually, even without my patch series, xl should be able to boot a PV=
<br>
&gt; guest using pygrub if (and only if) the disk is a raw file.<br>
<br>
</div>Yes, I&#39;ve just realised that while editing<br>
<a href=3D"http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_=
Installer" target=3D"_blank">http://wiki.xen.org/wiki/Debian_Guest_Installa=
tion_Using_Debian_Installer</a> as part of the dos day -- it seems to work =
for me at least.<br>

<br>
Perhaps the issue here is the use of kernel=3D and ramdisk=3D instead of<br=
>
bootloader_args? (see the new CD install section of that Debian install<br>
guide for an example of the sort of thing which works for me)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt;<br>
&gt; &gt; In the meantime as a workaround you could try using losetup on th=
e iso<br>
&gt; &gt; and pointing xl at phy:/dev/loop$N.<br>
&gt;<br>
&gt; that should also work<br>
<br>
<br>
</div></div></blockquote></div>Hello guys,</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">Thanks for the=A0responses.</div><div =
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I have been doin=
g some testing, to see if I could find out what could be causing the proble=
m.</div>
<div class=3D"gmail_extra">I have, once again, reinstalled the whole system=
 as I wanted a clean system, and now I can get the system to create my open=
indiana VM (with the bootloader property in the cfg file), however it will =
not boot fully.</div>
<div class=3D"gmail_extra"><br>What I did discover is that the VM boot is=
=A0halted by the vif option in my cfg file. If I comment it out, the vm boo=
ts fine, but of course I cant complete the install without the network IF p=
resent.</div>
<div class=3D"gmail_extra">I tried creating a different networking architec=
ture as laid out in the xen wiki&#39;s, but with no difference in the=A0beh=
avior.</div><div class=3D"gmail_extra">Occasionally I would get errors in t=
he VM regarding network IF not being correctly=A0initialized=A0(or somethin=
g to that extent), which reinforces my suspicions regarding networking caus=
ing the problems</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I had all t=
his working in my initial setup, 3.1.9 kernel with xen 4.2 unstable 14785, =
now I am running kernel 3.1.10. The major differences are that before I use=
d a file based disk image while now I am using LVM disk image (or partition=
), and that I did not patch xen with the Solaris pvgrub patch. My current d=
isk definition is:</div>
<div class=3D"gmail_extra"><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">=A0disk =3D [ &#39;file:/mnt/media/comp_files/os-iso/oi151=
a.iso,xvdc:cdrom,r&#39; , &#39;phy:/dev/xen-dom0/oi_boot,xvda,w&#39; ]</div=
><div><br>
</div><div>Have I perhaps made an error here?</div><div><br></div><div>Hope=
 that I have not rambled on too much and=A0confused=A0you.</div><div><br></=
div><div>Best regards<br><br>Sandi</div></div>

--0015174c1234cbcf8504be729aa6--


--===============7000308292207593199==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7000308292207593199==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 20:29:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 20:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMmMA-00015U-Hy; Tue, 24 Apr 2012 20:29:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SMmM9-00015P-Cn
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 20:29:01 +0000
Received: from [193.109.254.147:64306] by server-10.bemta-14.messagelabs.com
	id A8/A2-05847-C0D079F4; Tue, 24 Apr 2012 20:29:00 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335299339!6181780!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13178 invoked from network); 24 Apr 2012 20:28:59 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 20:28:59 -0000
Received: by eekc13 with SMTP id c13so136875eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 13:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9cKLQEkPk0o3F394Aj+JGDILCe9WAGJY4n1XEhvTLX4=;
	b=CEPBLhtBQZmTio6hDGd9L2nDaJN608o7qwlS/oynnAfruW1ib4BW9XfskW+Bb27MQw
	PKevZyiw6vve/DCeVYkm3iLPrxiKPj67LqJ7okMJFIRACVevtipltGrGQbA1Nvs4Pwyl
	YD+exOkjxWPlcR5DbH75TavtLfdTJP5zVmINeHQThtNVibsWnF5VrudQRcMsY01TTlJq
	MGJNoG7tRG1+I2mBhkoz84EOS0MqYVLmO5QJWcIPEWipeAmBF9868FUn6OLRxEBBTU8o
	ICIy8WIjAGFydxQHUAAM9sukHZRKsrexYI2UycRzbI+SpkXg44FJ9oTnrb4M0RG+vKv3
	gnng==
MIME-Version: 1.0
Received: by 10.213.112.142 with SMTP id w14mr34597ebp.24.1335299339439; Tue,
	24 Apr 2012 13:28:59 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Tue, 24 Apr 2012 13:28:59 -0700 (PDT)
In-Reply-To: <1335180628.4347.1.camel@zakaz.uk.xensource.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Apr 2012 22:28:59 +0200
Message-ID: <CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7000308292207593199=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7000308292207593199==
Content-Type: multipart/alternative; boundary=0015174c1234cbcf8504be729aa6

--0015174c1234cbcf8504be729aa6
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 23, 2012 at 1:30 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-04-23 at 12:29 +0100, Stefano Stabellini wrote:
> > On Mon, 23 Apr 2012, Ian Campbell wrote:
> > > On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:
> > > > [...]
> > >
> > > >  kernel = "/etc/xen/kernels/oi151a/unix"
> > > >  ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
> > >
> > > I forget how this works -- do you need to comment these out while using
> > > pygrub or are these paths inside the ISO?
> > > [...]
> > > >  disk =
> > > > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > > > 'phy:/dev/dom0/oi_boot,xvda,w' ]
> > > >  bootloader = "/usr/bin/pygrub"
> > >
> > > Sadly I don't think xl is currently capable of booting using pygrub
> from
> > > a file:/// type device.
> >
> > > I expect this will be resolved by Stefano's "qdisk local attach" series
> > > which was on the list last week.
> >
> > Actually, even without my patch series, xl should be able to boot a PV
> > guest using pygrub if (and only if) the disk is a raw file.
>
> Yes, I've just realised that while editing
> http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installeras part of the dos day -- it seems to work for me at least.
>
> Perhaps the issue here is the use of kernel= and ramdisk= instead of
> bootloader_args? (see the new CD install section of that Debian install
> guide for an example of the sort of thing which works for me)
>
> Ian.
>
> >
> >
> > > In the meantime as a workaround you could try using losetup on the iso
> > > and pointing xl at phy:/dev/loop$N.
> >
> > that should also work
>
>
> Hello guys,

Thanks for the responses.

I have been doing some testing, to see if I could find out what could be
causing the problem.
I have, once again, reinstalled the whole system as I wanted a clean
system, and now I can get the system to create my openindiana VM (with the
bootloader property in the cfg file), however it will not boot fully.

What I did discover is that the VM boot is halted by the vif option in my
cfg file. If I comment it out, the vm boots fine, but of course I cant
complete the install without the network IF present.
I tried creating a different networking architecture as laid out in the xen
wiki's, but with no difference in the behavior.
Occasionally I would get errors in the VM regarding network IF not being
correctly initialized (or something to that extent), which reinforces my
suspicions regarding networking causing the problems

I had all this working in my initial setup, 3.1.9 kernel with xen 4.2
unstable 14785, now I am running kernel 3.1.10. The major differences are
that before I used a file based disk image while now I am using LVM disk
image (or partition), and that I did not patch xen with the Solaris pvgrub
patch. My current disk definition is:

 disk = [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
'phy:/dev/xen-dom0/oi_boot,xvda,w' ]

Have I perhaps made an error here?

Hope that I have not rambled on too much and confused you.

Best regards

Sandi

--0015174c1234cbcf8504be729aa6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Apr 2=
3, 2012 at 1:30 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, 2012-04-23 at 12:2=
9 +0100, Stefano Stabellini wrote:<br>
&gt; On Mon, 23 Apr 2012, Ian Campbell wrote:<br>
&gt; &gt; On Sat, 2012-04-21 at 12:04 +0100, Sandi Romih wrote:<br>
&gt; &gt; &gt; [...]<br>
&gt; &gt;<br>
&gt; &gt; &gt; =A0kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot;<br>
&gt; &gt; &gt; =A0ramdisk =3D &quot;/etc/xen/kernels/oi151a/boot_archive&qu=
ot;<br>
&gt; &gt;<br>
&gt; &gt; I forget how this works -- do you need to comment these out while=
 using<br>
&gt; &gt; pygrub or are these paths inside the ISO?<br>
&gt; &gt; [...]<br>
&gt; &gt; &gt; =A0disk =3D<br>
&gt; &gt; &gt; [ &#39;file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdr=
om,r&#39; ,<br>
&gt; &gt; &gt; &#39;phy:/dev/dom0/oi_boot,xvda,w&#39; ]<br>
&gt; &gt; &gt; =A0bootloader =3D &quot;/usr/bin/pygrub&quot;<br>
&gt; &gt;<br>
&gt; &gt; Sadly I don&#39;t think xl is currently capable of booting using =
pygrub from<br>
&gt; &gt; a file:/// type device.<br>
&gt;<br>
&gt; &gt; I expect this will be resolved by Stefano&#39;s &quot;qdisk local=
 attach&quot; series<br>
&gt; &gt; which was on the list last week.<br>
&gt;<br>
&gt; Actually, even without my patch series, xl should be able to boot a PV=
<br>
&gt; guest using pygrub if (and only if) the disk is a raw file.<br>
<br>
</div>Yes, I&#39;ve just realised that while editing<br>
<a href=3D"http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_=
Installer" target=3D"_blank">http://wiki.xen.org/wiki/Debian_Guest_Installa=
tion_Using_Debian_Installer</a> as part of the dos day -- it seems to work =
for me at least.<br>

<br>
Perhaps the issue here is the use of kernel=3D and ramdisk=3D instead of<br=
>
bootloader_args? (see the new CD install section of that Debian install<br>
guide for an example of the sort of thing which works for me)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt;<br>
&gt; &gt; In the meantime as a workaround you could try using losetup on th=
e iso<br>
&gt; &gt; and pointing xl at phy:/dev/loop$N.<br>
&gt;<br>
&gt; that should also work<br>
<br>
<br>
</div></div></blockquote></div>Hello guys,</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">Thanks for the=A0responses.</div><div =
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I have been doin=
g some testing, to see if I could find out what could be causing the proble=
m.</div>
<div class=3D"gmail_extra">I have, once again, reinstalled the whole system=
 as I wanted a clean system, and now I can get the system to create my open=
indiana VM (with the bootloader property in the cfg file), however it will =
not boot fully.</div>
<div class=3D"gmail_extra"><br>What I did discover is that the VM boot is=
=A0halted by the vif option in my cfg file. If I comment it out, the vm boo=
ts fine, but of course I cant complete the install without the network IF p=
resent.</div>
<div class=3D"gmail_extra">I tried creating a different networking architec=
ture as laid out in the xen wiki&#39;s, but with no difference in the=A0beh=
avior.</div><div class=3D"gmail_extra">Occasionally I would get errors in t=
he VM regarding network IF not being correctly=A0initialized=A0(or somethin=
g to that extent), which reinforces my suspicions regarding networking caus=
ing the problems</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I had all t=
his working in my initial setup, 3.1.9 kernel with xen 4.2 unstable 14785, =
now I am running kernel 3.1.10. The major differences are that before I use=
d a file based disk image while now I am using LVM disk image (or partition=
), and that I did not patch xen with the Solaris pvgrub patch. My current d=
isk definition is:</div>
<div class=3D"gmail_extra"><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">=A0disk =3D [ &#39;file:/mnt/media/comp_files/os-iso/oi151=
a.iso,xvdc:cdrom,r&#39; , &#39;phy:/dev/xen-dom0/oi_boot,xvda,w&#39; ]</div=
><div><br>
</div><div>Have I perhaps made an error here?</div><div><br></div><div>Hope=
 that I have not rambled on too much and=A0confused=A0you.</div><div><br></=
div><div>Best regards<br><br>Sandi</div></div>

--0015174c1234cbcf8504be729aa6--


--===============7000308292207593199==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7000308292207593199==--


From xen-devel-bounces@lists.xen.org Tue Apr 24 21:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 21:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMnNb-0001bI-Q6; Tue, 24 Apr 2012 21:34:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMnNZ-0001bD-Nb
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 21:34:34 +0000
Received: from [193.109.254.147:25498] by server-12.bemta-14.messagelabs.com
	id 43/A1-05898-96C179F4; Tue, 24 Apr 2012 21:34:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335303269!6101521!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 24 Apr 2012 21:34:29 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 21:34:29 -0000
Received: by lboi15 with SMTP id i15so1061872lbo.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 14:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fcT4RPCT0UpRWUJmL7tw88Ea8GWWZbE7g9yq5gvEGqU=;
	b=G9oTOgW53bFVUD9x3/6fGuh1a0dc2UqwJ4uOyLWrAsUa8jIVDGmEMTNQqOnMzlhZIj
	IL4Dq7lH4Seol/VfBRpdg+/pqOqiOV2cDPbGzv7tgTxkY6Jyxg+EeVJagqUlbVL+xAIC
	fhPhdITcvy66TeCNmmyHHVKWvxypkAetvcb+w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=fcT4RPCT0UpRWUJmL7tw88Ea8GWWZbE7g9yq5gvEGqU=;
	b=gsFTKprMOO8rvKXTv/8cnXu6JYlmWoG5036qfIYefCEQ8cLw2e1JZ3oh1hwcN93M7O
	8ZmiN2JLAPZ5419CQy5JXnGv0wkaFdEUqXRE8cCfmHXCGwos1SLekeouldjUVEyfdGFp
	aog8Zl6QFqMTiA91m9WReA64rfbLV7n1mDqHPaDsmRlD0jECMGuaEtQxBGEgJNl48wMO
	ZFgWDPA5ULkubDSeoXMV0p+pEP8z0hJAdsQArnS20fVcUKo4pQVkDIm8BNq476ELbZY0
	DEQ5kRxJ7EClHeuv0k3cjNyatFq4QBUcTOaGlK0MrhTfUd6IPwk6BI8rKtl/+Je1GHQ+
	gAQA==
MIME-Version: 1.0
Received: by 10.152.105.197 with SMTP id go5mr59650lab.43.1335303268658; Tue,
	24 Apr 2012 14:34:28 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 14:34:28 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CBBCC982.31764%keir.xen@gmail.com>
References: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
	<CBBCC982.31764%keir.xen@gmail.com>
Date: Tue, 24 Apr 2012 14:34:28 -0700
Message-ID: <CAB10MZAax61ccMOqs_NpSe9A3LWByu6ZohLHeFk5VPVDkgJUgg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Keir Fraser <keir.xen@gmail.com>
X-Gm-Message-State: ALoCoQmags0xic9sZ3Wyzp0YBXu+sdlX/4ZF6koUh0o7t9qfZIMEw2FR5frdsr6CH0Ko9ezT+wQQ
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 1:20 PM, Keir Fraser <keir.xen@gmail.com> wrote:
> On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
>
>> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>>> as a new function table entry, or pay the price of calling
>>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>>> the case of the subject vCPU being current.
>>>
>>> OK, I will try introducing a new wrapper that will return
>>> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.
>>
>> Jan,
>>
>> How does this look?
>
> Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
> patch won't compile on i386, as you have inconsistently ifdef'ed. Just
> remove the ifdefs as far as possible, we'd rather have dead code on i386
> than ifdefs.

Does this look better? I couldn't get away with adding ifdef x86_64
only to domctl.c. I also had to add it to the
(svm/vmx)_get_shadow_gs_base(). It now complies for x86_32.

Aravindh

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
         hvm_get_segment_register(v, x86_seg_ss, &sreg);
         c.nat->user_regs.ss =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_ds, &sreg);
         c.nat->user_regs.ds =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_es, &sreg);
         c.nat->user_regs.es =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs =3D sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base =3D sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs =3D sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+        {
+            c.nat->gs_base_kernel =3D sreg.base;
+            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
+        }
+        else
+        {
+            c.nat->gs_base_user =3D sreg.base;
+            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
+        }
+#endif
     }
     else
     {
         c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
         c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
         for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
             c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
 #ifdef CONFIG_COMPAT
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -640,16 +640,27 @@ static void svm_set_segment_register(str
     default:
         BUG();
     }

     if ( sync )
         svm_vmload(vmcb);
 }

+static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
+{
+#ifdef __x86_64__
+    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
+
+    return vmcb->kerngsbase;
+#else
+    return 0;
+#endif
+}
+
 static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;

     if ( !paging_mode_hap(v->domain) )
         return 0;

     vmcb_set_g_pat(vmcb, gpat);
@@ -1978,16 +1989,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D svm_vcpu_destroy,
     .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
     .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
     .get_interrupt_shadow =3D svm_get_interrupt_shadow,
     .set_interrupt_shadow =3D svm_set_interrupt_shadow,
     .guest_x86_mode       =3D svm_guest_x86_mode,
     .get_segment_register =3D svm_get_segment_register,
     .set_segment_register =3D svm_set_segment_register,
+    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
     .update_host_cr3      =3D svm_update_host_cr3,
     .update_guest_cr      =3D svm_update_guest_cr,
     .update_guest_efer    =3D svm_update_guest_efer,
     .set_guest_pat        =3D svm_set_guest_pat,
     .get_guest_pat        =3D svm_get_guest_pat,
     .set_tsc_offset       =3D svm_set_tsc_offset,
     .inject_exception     =3D svm_inject_exception,
     .init_hypercall_page  =3D svm_init_hypercall_page,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -937,16 +937,25 @@ static void vmx_set_segment_register(str
         break;
     default:
         BUG();
     }

     vmx_vmcs_exit(v);
 }

+static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
+{
+#ifdef __x86_64__
+    return v->arch.hvm_vmx.shadow_gs;
+#else
+    return 0;
+#endif
+}
+
 static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
         return 0;

     vmx_vmcs_enter(v);
     __vmwrite(GUEST_PAT, gpat);
 #ifdef __i386__
@@ -1517,16 +1526,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D vmx_vcpu_destroy,
     .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
     .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
     .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
     .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
     .guest_x86_mode       =3D vmx_guest_x86_mode,
     .get_segment_register =3D vmx_get_segment_register,
     .set_segment_register =3D vmx_set_segment_register,
+    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
     .update_host_cr3      =3D vmx_update_host_cr3,
     .update_guest_cr      =3D vmx_update_guest_cr,
     .update_guest_efer    =3D vmx_update_guest_efer,
     .set_guest_pat        =3D vmx_set_guest_pat,
     .get_guest_pat        =3D vmx_get_guest_pat,
     .set_tsc_offset       =3D vmx_set_tsc_offset,
     .inject_exception     =3D vmx_inject_exception,
     .init_hypercall_page  =3D vmx_init_hypercall_page,
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -101,16 +101,17 @@ struct hvm_function_table {
     /* Examine specifics of the guest state. */
     unsigned int (*get_interrupt_shadow)(struct vcpu *v);
     void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shadow);
     int (*guest_x86_mode)(struct vcpu *v);
     void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
     void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
+    unsigned long (*get_shadow_gs_base)(struct vcpu *v);

     /*
      * Re-set the value of CR3 that Xen runs on when handling VM exits.
      */
     void (*update_host_cr3)(struct vcpu *v);

     /*
      * Called to inform HVM layer that a guest CRn or EFER has changed.
@@ -300,16 +301,21 @@ hvm_get_segment_register(struct vcpu *v,

 static inline void
 hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
                          struct segment_register *reg)
 {
     hvm_funcs.set_segment_register(v, seg, reg);
 }

+static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
+{
+    return hvm_funcs.get_shadow_gs_base(v);
+}
+
 #define is_viridian_domain(_d)                                            =
 \
  (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))

 void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
                                    unsigned int *ecx, unsigned int *edx);
 void hvm_migrate_timers(struct vcpu *v);
 void hvm_do_resume(struct vcpu *v);
 void hvm_migrate_pirqs(struct vcpu *v);



> =A0-- Keir
>
>> PS: Come submission time, I will send it out as two separate patches.
>>
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ss, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ss =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ds, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ds =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_es, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>> +#endif
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D hvm_get_shadow_gs_base(=
v);
>> + =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0else
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D hvm_get_shadow_gs_bas=
e(v);
>> + =A0 =A0 =A0 =A0}
>> +#endif
>> =A0 =A0 =A0}
>> =A0 =A0 =A0else
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>> =A0 =A0 =A0 =A0 =A0c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>> =A0 =A0 =A0 =A0 =A0for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_fra=
mes); ++i )
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frame=
s[i]);
>> =A0#ifdef CONFIG_COMPAT
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -640,16 +640,25 @@ static void svm_set_segment_register(str
>> =A0 =A0 =A0default:
>> =A0 =A0 =A0 =A0 =A0BUG();
>> =A0 =A0 =A0}
>>
>> =A0 =A0 =A0if ( sync )
>> =A0 =A0 =A0 =A0 =A0svm_vmload(vmcb);
>> =A0}
>>
>> +#ifdef __x86_64__
>> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
>> +{
>> + =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>> +
>> + =A0 =A0return vmcb->kerngsbase;
>> +}
>> +#endif
>> +
>> =A0static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>> =A0{
>> =A0 =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>>
>> =A0 =A0 =A0if ( !paging_mode_hap(v->domain) )
>> =A0 =A0 =A0 =A0 =A0return 0;
>>
>> =A0 =A0 =A0vmcb_set_g_pat(vmcb, gpat);
>> @@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D svm_vcpu_destroy,
>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_save_vmcb_ctxt,
>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_load_vmcb_ctxt,
>> =A0 =A0 =A0.get_interrupt_shadow =3D svm_get_interrupt_shadow,
>> =A0 =A0 =A0.set_interrupt_shadow =3D svm_set_interrupt_shadow,
>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D svm_guest_x86_mode,
>> =A0 =A0 =A0.get_segment_register =3D svm_get_segment_register,
>> =A0 =A0 =A0.set_segment_register =3D svm_set_segment_register,
>> + =A0 =A0.get_shadow_gs_base =A0 =3D svm_get_shadow_gs_base,
>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D svm_update_host_cr3,
>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D svm_update_guest_cr,
>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D svm_update_guest_efer,
>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D svm_set_guest_pat,
>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D svm_get_guest_pat,
>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D svm_set_tsc_offset,
>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D svm_inject_exception,
>> =A0 =A0 =A0.init_hypercall_page =A0=3D svm_init_hypercall_page,
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
>> =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0default:
>> =A0 =A0 =A0 =A0 =A0BUG();
>> =A0 =A0 =A0}
>>
>> =A0 =A0 =A0vmx_vmcs_exit(v);
>> =A0}
>>
>> +#ifdef __x86_64__
>> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
>> +{
>> + =A0 =A0return v->arch.hvm_vmx.shadow_gs;
>> +}
>> +#endif
>> +
>> =A0static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>> =A0{
>> =A0 =A0 =A0if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>> =A0 =A0 =A0 =A0 =A0return 0;
>>
>> =A0 =A0 =A0vmx_vmcs_enter(v);
>> =A0 =A0 =A0__vmwrite(GUEST_PAT, gpat);
>> =A0#ifdef __i386__
>> @@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D vmx_vcpu_destroy,
>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_save_vmcs_ctxt,
>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_load_vmcs_ctxt,
>> =A0 =A0 =A0.get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>> =A0 =A0 =A0.set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D vmx_guest_x86_mode,
>> =A0 =A0 =A0.get_segment_register =3D vmx_get_segment_register,
>> =A0 =A0 =A0.set_segment_register =3D vmx_set_segment_register,
>> + =A0 =A0.get_shadow_gs_base =A0 =3D vmx_get_shadow_gs_base,
>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D vmx_update_host_cr3,
>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D vmx_update_guest_cr,
>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D vmx_update_guest_efer,
>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D vmx_set_guest_pat,
>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D vmx_get_guest_pat,
>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D vmx_set_tsc_offset,
>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D vmx_inject_exception,
>> =A0 =A0 =A0.init_hypercall_page =A0=3D vmx_init_hypercall_page,
>> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm=
.h
>> --- a/xen/include/asm-x86/hvm/hvm.h
>> +++ b/xen/include/asm-x86/hvm/hvm.h
>> @@ -101,16 +101,19 @@ struct hvm_function_table {
>> =A0 =A0 =A0/* Examine specifics of the guest state. */
>> =A0 =A0 =A0unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>> =A0 =A0 =A0void (*set_interrupt_shadow)(struct vcpu *v, unsigned int int=
r_shadow);
>> =A0 =A0 =A0int (*guest_x86_mode)(struct vcpu *v);
>> =A0 =A0 =A0void (*get_segment_register)(struct vcpu *v, enum x86_segment=
 seg,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stru=
ct segment_register *reg);
>> =A0 =A0 =A0void (*set_segment_register)(struct vcpu *v, enum x86_segment=
 seg,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stru=
ct segment_register *reg);
>> +#ifdef __x86_64__
>> + =A0 =A0unsigned long (*get_shadow_gs_base)(struct vcpu *v);
>> +#endif
>>
>> =A0 =A0 =A0/*
>> =A0 =A0 =A0 * Re-set the value of CR3 that Xen runs on when handling VM =
exits.
>> =A0 =A0 =A0 */
>> =A0 =A0 =A0void (*update_host_cr3)(struct vcpu *v);
>>
>> =A0 =A0 =A0/*
>> =A0 =A0 =A0 * Called to inform HVM layer that a guest CRn or EFER has ch=
anged.
>> @@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,
>>
>> =A0static inline void
>> =A0hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct segment_regis=
ter *reg)
>> =A0{
>> =A0 =A0 =A0hvm_funcs.set_segment_register(v, seg, reg);
>> =A0}
>>
>> +#ifdef __x86_64__
>> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
>> +{
>> + =A0 =A0return hvm_funcs.get_shadow_gs_base(v);
>> +}
>> +#endif
>> +
>> =A0#define is_viridian_domain(_d) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> =A0 (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDI=
AN]))
>>
>> =A0void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *e=
bx,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
unsigned int *ecx, unsigned int *edx);
>> =A0void hvm_migrate_timers(struct vcpu *v);
>> =A0void hvm_do_resume(struct vcpu *v);
>> =A0void hvm_migrate_pirqs(struct vcpu *v);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 21:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 21:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMnNb-0001bI-Q6; Tue, 24 Apr 2012 21:34:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SMnNZ-0001bD-Nb
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 21:34:34 +0000
Received: from [193.109.254.147:25498] by server-12.bemta-14.messagelabs.com
	id 43/A1-05898-96C179F4; Tue, 24 Apr 2012 21:34:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335303269!6101521!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 24 Apr 2012 21:34:29 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 21:34:29 -0000
Received: by lboi15 with SMTP id i15so1061872lbo.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 14:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fcT4RPCT0UpRWUJmL7tw88Ea8GWWZbE7g9yq5gvEGqU=;
	b=G9oTOgW53bFVUD9x3/6fGuh1a0dc2UqwJ4uOyLWrAsUa8jIVDGmEMTNQqOnMzlhZIj
	IL4Dq7lH4Seol/VfBRpdg+/pqOqiOV2cDPbGzv7tgTxkY6Jyxg+EeVJagqUlbVL+xAIC
	fhPhdITcvy66TeCNmmyHHVKWvxypkAetvcb+w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=fcT4RPCT0UpRWUJmL7tw88Ea8GWWZbE7g9yq5gvEGqU=;
	b=gsFTKprMOO8rvKXTv/8cnXu6JYlmWoG5036qfIYefCEQ8cLw2e1JZ3oh1hwcN93M7O
	8ZmiN2JLAPZ5419CQy5JXnGv0wkaFdEUqXRE8cCfmHXCGwos1SLekeouldjUVEyfdGFp
	aog8Zl6QFqMTiA91m9WReA64rfbLV7n1mDqHPaDsmRlD0jECMGuaEtQxBGEgJNl48wMO
	ZFgWDPA5ULkubDSeoXMV0p+pEP8z0hJAdsQArnS20fVcUKo4pQVkDIm8BNq476ELbZY0
	DEQ5kRxJ7EClHeuv0k3cjNyatFq4QBUcTOaGlK0MrhTfUd6IPwk6BI8rKtl/+Je1GHQ+
	gAQA==
MIME-Version: 1.0
Received: by 10.152.105.197 with SMTP id go5mr59650lab.43.1335303268658; Tue,
	24 Apr 2012 14:34:28 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Tue, 24 Apr 2012 14:34:28 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CBBCC982.31764%keir.xen@gmail.com>
References: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
	<CBBCC982.31764%keir.xen@gmail.com>
Date: Tue, 24 Apr 2012 14:34:28 -0700
Message-ID: <CAB10MZAax61ccMOqs_NpSe9A3LWByu6ZohLHeFk5VPVDkgJUgg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Keir Fraser <keir.xen@gmail.com>
X-Gm-Message-State: ALoCoQmags0xic9sZ3Wyzp0YBXu+sdlX/4ZF6koUh0o7t9qfZIMEw2FR5frdsr6CH0Ko9ezT+wQQ
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 1:20 PM, Keir Fraser <keir.xen@gmail.com> wrote:
> On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
>
>> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>>> as a new function table entry, or pay the price of calling
>>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>>> the case of the subject vCPU being current.
>>>
>>> OK, I will try introducing a new wrapper that will return
>>> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.
>>
>> Jan,
>>
>> How does this look?
>
> Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
> patch won't compile on i386, as you have inconsistently ifdef'ed. Just
> remove the ifdefs as far as possible, we'd rather have dead code on i386
> than ifdefs.

Does this look better? I couldn't get away with adding ifdef x86_64
only to domctl.c. I also had to add it to the
(svm/vmx)_get_shadow_gs_base(). It now complies for x86_32.

Aravindh

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
         hvm_get_segment_register(v, x86_seg_ss, &sreg);
         c.nat->user_regs.ss =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_ds, &sreg);
         c.nat->user_regs.ds =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_es, &sreg);
         c.nat->user_regs.es =3D sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs =3D sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base =3D sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs =3D sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+        {
+            c.nat->gs_base_kernel =3D sreg.base;
+            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
+        }
+        else
+        {
+            c.nat->gs_base_user =3D sreg.base;
+            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
+        }
+#endif
     }
     else
     {
         c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
         c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
         for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
             c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
 #ifdef CONFIG_COMPAT
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -640,16 +640,27 @@ static void svm_set_segment_register(str
     default:
         BUG();
     }

     if ( sync )
         svm_vmload(vmcb);
 }

+static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
+{
+#ifdef __x86_64__
+    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
+
+    return vmcb->kerngsbase;
+#else
+    return 0;
+#endif
+}
+
 static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;

     if ( !paging_mode_hap(v->domain) )
         return 0;

     vmcb_set_g_pat(vmcb, gpat);
@@ -1978,16 +1989,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D svm_vcpu_destroy,
     .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
     .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
     .get_interrupt_shadow =3D svm_get_interrupt_shadow,
     .set_interrupt_shadow =3D svm_set_interrupt_shadow,
     .guest_x86_mode       =3D svm_guest_x86_mode,
     .get_segment_register =3D svm_get_segment_register,
     .set_segment_register =3D svm_set_segment_register,
+    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
     .update_host_cr3      =3D svm_update_host_cr3,
     .update_guest_cr      =3D svm_update_guest_cr,
     .update_guest_efer    =3D svm_update_guest_efer,
     .set_guest_pat        =3D svm_set_guest_pat,
     .get_guest_pat        =3D svm_get_guest_pat,
     .set_tsc_offset       =3D svm_set_tsc_offset,
     .inject_exception     =3D svm_inject_exception,
     .init_hypercall_page  =3D svm_init_hypercall_page,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -937,16 +937,25 @@ static void vmx_set_segment_register(str
         break;
     default:
         BUG();
     }

     vmx_vmcs_exit(v);
 }

+static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
+{
+#ifdef __x86_64__
+    return v->arch.hvm_vmx.shadow_gs;
+#else
+    return 0;
+#endif
+}
+
 static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
         return 0;

     vmx_vmcs_enter(v);
     __vmwrite(GUEST_PAT, gpat);
 #ifdef __i386__
@@ -1517,16 +1526,17 @@ static struct hvm_function_table __read_
     .vcpu_destroy         =3D vmx_vcpu_destroy,
     .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
     .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
     .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
     .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
     .guest_x86_mode       =3D vmx_guest_x86_mode,
     .get_segment_register =3D vmx_get_segment_register,
     .set_segment_register =3D vmx_set_segment_register,
+    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
     .update_host_cr3      =3D vmx_update_host_cr3,
     .update_guest_cr      =3D vmx_update_guest_cr,
     .update_guest_efer    =3D vmx_update_guest_efer,
     .set_guest_pat        =3D vmx_set_guest_pat,
     .get_guest_pat        =3D vmx_get_guest_pat,
     .set_tsc_offset       =3D vmx_set_tsc_offset,
     .inject_exception     =3D vmx_inject_exception,
     .init_hypercall_page  =3D vmx_init_hypercall_page,
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -101,16 +101,17 @@ struct hvm_function_table {
     /* Examine specifics of the guest state. */
     unsigned int (*get_interrupt_shadow)(struct vcpu *v);
     void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shadow);
     int (*guest_x86_mode)(struct vcpu *v);
     void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
     void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
+    unsigned long (*get_shadow_gs_base)(struct vcpu *v);

     /*
      * Re-set the value of CR3 that Xen runs on when handling VM exits.
      */
     void (*update_host_cr3)(struct vcpu *v);

     /*
      * Called to inform HVM layer that a guest CRn or EFER has changed.
@@ -300,16 +301,21 @@ hvm_get_segment_register(struct vcpu *v,

 static inline void
 hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
                          struct segment_register *reg)
 {
     hvm_funcs.set_segment_register(v, seg, reg);
 }

+static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
+{
+    return hvm_funcs.get_shadow_gs_base(v);
+}
+
 #define is_viridian_domain(_d)                                            =
 \
  (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))

 void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
                                    unsigned int *ecx, unsigned int *edx);
 void hvm_migrate_timers(struct vcpu *v);
 void hvm_do_resume(struct vcpu *v);
 void hvm_migrate_pirqs(struct vcpu *v);



> =A0-- Keir
>
>> PS: Come submission time, I will send it out as two separate patches.
>>
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ss, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ss =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ds, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ds =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_es, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>> +#endif
>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>> +#ifdef __x86_64__
>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D hvm_get_shadow_gs_base(=
v);
>> + =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0else
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D hvm_get_shadow_gs_bas=
e(v);
>> + =A0 =A0 =A0 =A0}
>> +#endif
>> =A0 =A0 =A0}
>> =A0 =A0 =A0else
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>> =A0 =A0 =A0 =A0 =A0c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>> =A0 =A0 =A0 =A0 =A0for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_fra=
mes); ++i )
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frame=
s[i]);
>> =A0#ifdef CONFIG_COMPAT
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -640,16 +640,25 @@ static void svm_set_segment_register(str
>> =A0 =A0 =A0default:
>> =A0 =A0 =A0 =A0 =A0BUG();
>> =A0 =A0 =A0}
>>
>> =A0 =A0 =A0if ( sync )
>> =A0 =A0 =A0 =A0 =A0svm_vmload(vmcb);
>> =A0}
>>
>> +#ifdef __x86_64__
>> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
>> +{
>> + =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>> +
>> + =A0 =A0return vmcb->kerngsbase;
>> +}
>> +#endif
>> +
>> =A0static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>> =A0{
>> =A0 =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>>
>> =A0 =A0 =A0if ( !paging_mode_hap(v->domain) )
>> =A0 =A0 =A0 =A0 =A0return 0;
>>
>> =A0 =A0 =A0vmcb_set_g_pat(vmcb, gpat);
>> @@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D svm_vcpu_destroy,
>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_save_vmcb_ctxt,
>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_load_vmcb_ctxt,
>> =A0 =A0 =A0.get_interrupt_shadow =3D svm_get_interrupt_shadow,
>> =A0 =A0 =A0.set_interrupt_shadow =3D svm_set_interrupt_shadow,
>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D svm_guest_x86_mode,
>> =A0 =A0 =A0.get_segment_register =3D svm_get_segment_register,
>> =A0 =A0 =A0.set_segment_register =3D svm_set_segment_register,
>> + =A0 =A0.get_shadow_gs_base =A0 =3D svm_get_shadow_gs_base,
>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D svm_update_host_cr3,
>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D svm_update_guest_cr,
>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D svm_update_guest_efer,
>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D svm_set_guest_pat,
>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D svm_get_guest_pat,
>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D svm_set_tsc_offset,
>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D svm_inject_exception,
>> =A0 =A0 =A0.init_hypercall_page =A0=3D svm_init_hypercall_page,
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
>> =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0default:
>> =A0 =A0 =A0 =A0 =A0BUG();
>> =A0 =A0 =A0}
>>
>> =A0 =A0 =A0vmx_vmcs_exit(v);
>> =A0}
>>
>> +#ifdef __x86_64__
>> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
>> +{
>> + =A0 =A0return v->arch.hvm_vmx.shadow_gs;
>> +}
>> +#endif
>> +
>> =A0static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>> =A0{
>> =A0 =A0 =A0if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>> =A0 =A0 =A0 =A0 =A0return 0;
>>
>> =A0 =A0 =A0vmx_vmcs_enter(v);
>> =A0 =A0 =A0__vmwrite(GUEST_PAT, gpat);
>> =A0#ifdef __i386__
>> @@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D vmx_vcpu_destroy,
>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_save_vmcs_ctxt,
>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_load_vmcs_ctxt,
>> =A0 =A0 =A0.get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>> =A0 =A0 =A0.set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D vmx_guest_x86_mode,
>> =A0 =A0 =A0.get_segment_register =3D vmx_get_segment_register,
>> =A0 =A0 =A0.set_segment_register =3D vmx_set_segment_register,
>> + =A0 =A0.get_shadow_gs_base =A0 =3D vmx_get_shadow_gs_base,
>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D vmx_update_host_cr3,
>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D vmx_update_guest_cr,
>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D vmx_update_guest_efer,
>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D vmx_set_guest_pat,
>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D vmx_get_guest_pat,
>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D vmx_set_tsc_offset,
>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D vmx_inject_exception,
>> =A0 =A0 =A0.init_hypercall_page =A0=3D vmx_init_hypercall_page,
>> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm=
.h
>> --- a/xen/include/asm-x86/hvm/hvm.h
>> +++ b/xen/include/asm-x86/hvm/hvm.h
>> @@ -101,16 +101,19 @@ struct hvm_function_table {
>> =A0 =A0 =A0/* Examine specifics of the guest state. */
>> =A0 =A0 =A0unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>> =A0 =A0 =A0void (*set_interrupt_shadow)(struct vcpu *v, unsigned int int=
r_shadow);
>> =A0 =A0 =A0int (*guest_x86_mode)(struct vcpu *v);
>> =A0 =A0 =A0void (*get_segment_register)(struct vcpu *v, enum x86_segment=
 seg,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stru=
ct segment_register *reg);
>> =A0 =A0 =A0void (*set_segment_register)(struct vcpu *v, enum x86_segment=
 seg,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stru=
ct segment_register *reg);
>> +#ifdef __x86_64__
>> + =A0 =A0unsigned long (*get_shadow_gs_base)(struct vcpu *v);
>> +#endif
>>
>> =A0 =A0 =A0/*
>> =A0 =A0 =A0 * Re-set the value of CR3 that Xen runs on when handling VM =
exits.
>> =A0 =A0 =A0 */
>> =A0 =A0 =A0void (*update_host_cr3)(struct vcpu *v);
>>
>> =A0 =A0 =A0/*
>> =A0 =A0 =A0 * Called to inform HVM layer that a guest CRn or EFER has ch=
anged.
>> @@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,
>>
>> =A0static inline void
>> =A0hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct segment_regis=
ter *reg)
>> =A0{
>> =A0 =A0 =A0hvm_funcs.set_segment_register(v, seg, reg);
>> =A0}
>>
>> +#ifdef __x86_64__
>> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
>> +{
>> + =A0 =A0return hvm_funcs.get_shadow_gs_base(v);
>> +}
>> +#endif
>> +
>> =A0#define is_viridian_domain(_d) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> =A0 (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDI=
AN]))
>>
>> =A0void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *e=
bx,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
unsigned int *ecx, unsigned int *edx);
>> =A0void hvm_migrate_timers(struct vcpu *v);
>> =A0void hvm_do_resume(struct vcpu *v);
>> =A0void hvm_migrate_pirqs(struct vcpu *v);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 22:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 22:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMno0-0001v4-HH; Tue, 24 Apr 2012 22:01:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1SMnnz-0001uz-Cd
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 22:01:51 +0000
Received: from [85.158.143.99:43905] by server-1.bemta-4.messagelabs.com id
	0E/5E-20925-EC2279F4; Tue, 24 Apr 2012 22:01:50 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335304908!25083685!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14730 invoked from network); 24 Apr 2012 22:01:50 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 22:01:50 -0000
Received: from saboo.goop.org (50-76-62-73-ip-static.hfc.comcastbusiness.net
	[50.76.62.73]) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id EC4EF98DE;
	Tue, 24 Apr 2012 15:01:47 -0700 (PDT)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 0AE0B2064F;
	Tue, 24 Apr 2012 15:01:47 -0700 (PDT)
Message-ID: <4F9722CA.80403@goop.org>
Date: Tue, 24 Apr 2012 15:01:46 -0700
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
	<20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
In-Reply-To: <20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
X-Enigmail-Version: 1.4
Cc: Xen Devel <Xen-devel@lists.xensource.com>,
	LKML <linux-kernel@vger.kernel.org>, linux-next@vger.kernel.org,
	Ben Dooks <ben-linux@fluff.org>, Rob Lee <rob.lee@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Xen-devel] linux-next: clean up time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/22/2012 11:48 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 2 Apr 2012 11:20:09 +1000 Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
>>
>> Can people please clean up stuff in their trees that has been merged by
>> their upstream. This is especially useful where the upstream merged (or
>> applied) a slightly different version of their tree.
>
> There is still much cruft in the linux-next included trees ... The
> following trees appear empty (relative to Linus' tree) but cause conflicts:
>
> bjdooks-i2c
> xen
> dma-buf
> cpuidle-cons

Are you pulling from xen.git upstream/xen?  I just updated it to be
current Linus master, so it shouldn't conflict any more.

Thanks,
    J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 22:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 22:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMno0-0001v4-HH; Tue, 24 Apr 2012 22:01:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1SMnnz-0001uz-Cd
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 22:01:51 +0000
Received: from [85.158.143.99:43905] by server-1.bemta-4.messagelabs.com id
	0E/5E-20925-EC2279F4; Tue, 24 Apr 2012 22:01:50 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335304908!25083685!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14730 invoked from network); 24 Apr 2012 22:01:50 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Apr 2012 22:01:50 -0000
Received: from saboo.goop.org (50-76-62-73-ip-static.hfc.comcastbusiness.net
	[50.76.62.73]) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id EC4EF98DE;
	Tue, 24 Apr 2012 15:01:47 -0700 (PDT)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 0AE0B2064F;
	Tue, 24 Apr 2012 15:01:47 -0700 (PDT)
Message-ID: <4F9722CA.80403@goop.org>
Date: Tue, 24 Apr 2012 15:01:46 -0700
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
	<20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
In-Reply-To: <20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
X-Enigmail-Version: 1.4
Cc: Xen Devel <Xen-devel@lists.xensource.com>,
	LKML <linux-kernel@vger.kernel.org>, linux-next@vger.kernel.org,
	Ben Dooks <ben-linux@fluff.org>, Rob Lee <rob.lee@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Xen-devel] linux-next: clean up time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/22/2012 11:48 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 2 Apr 2012 11:20:09 +1000 Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
>>
>> Can people please clean up stuff in their trees that has been merged by
>> their upstream. This is especially useful where the upstream merged (or
>> applied) a slightly different version of their tree.
>
> There is still much cruft in the linux-next included trees ... The
> following trees appear empty (relative to Linus' tree) but cause conflicts:
>
> bjdooks-i2c
> xen
> dma-buf
> cpuidle-cons

Are you pulling from xen.git upstream/xen?  I just updated it to be
current Linus master, so it shouldn't conflict any more.

Thanks,
    J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMop9-0002Ka-Ri; Tue, 24 Apr 2012 23:07:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SMop8-0002KV-4v
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 23:07:06 +0000
Received: from [85.158.143.35:9909] by server-2.bemta-4.messagelabs.com id
	9E/05-17550-912379F4; Tue, 24 Apr 2012 23:07:05 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335308823!13916958!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2615 invoked from network); 24 Apr 2012 23:07:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 23:07:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3ON6u2L029449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 23:06:57 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3ON6ssZ006036
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 23:06:55 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3ON6s2F019304; Tue, 24 Apr 2012 18:06:54 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 16:06:53 -0700
Date: Tue, 24 Apr 2012 16:06:43 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120424160643.531daf88@mantra.us.oracle.com>
In-Reply-To: <20120424093626.GC34721@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012 10:36:26 +0100
Tim Deegan <tim@xen.org> wrote:

> At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > On Thu, 19 Apr 2012 15:15:27 +0100
> > Tim Deegan <tim@xen.org> wrote:

>you still have this mapping.  You should take a PGT_writeable_page
>typecount, too, if the foreign domain isn't in paging_mode_external

Ok, I've it as:
    if (paging_mode_external(fdom)) {
        if (get_page_from_pagenr(mfn, fdom) == 0)
	    failed = 1;
    } else {
        if (get_page_and_type_from_pagenr(mfn, PGT_writable_page, fdom,0,0))
            failed = 1;
    }

But then later fails when it tries to pin the page,
MMUEXT_PIN_L4_TABLE, from the lib at:

        rc = pin_table(dom->xch, pgd_type,
	                xc_dom_p2m_host(dom, dom->pgtables_seg.pfn),
			dom->guest_domid);

(XEN) mm.c:2424:d0 Bad type (saw 7400000000000001 != exp 4000000000000000) for mfn 1bc160 (pfn 2eed)

thanks,
-m


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMop9-0002Ka-Ri; Tue, 24 Apr 2012 23:07:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SMop8-0002KV-4v
	for Xen-devel@lists.xensource.com; Tue, 24 Apr 2012 23:07:06 +0000
Received: from [85.158.143.35:9909] by server-2.bemta-4.messagelabs.com id
	9E/05-17550-912379F4; Tue, 24 Apr 2012 23:07:05 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335308823!13916958!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg5NDU2\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2615 invoked from network); 24 Apr 2012 23:07:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Apr 2012 23:07:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3ON6u2L029449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Apr 2012 23:06:57 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3ON6ssZ006036
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Apr 2012 23:06:55 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3ON6s2F019304; Tue, 24 Apr 2012 18:06:54 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Apr 2012 16:06:53 -0700
Date: Tue, 24 Apr 2012 16:06:43 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120424160643.531daf88@mantra.us.oracle.com>
In-Reply-To: <20120424093626.GC34721@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 24 Apr 2012 10:36:26 +0100
Tim Deegan <tim@xen.org> wrote:

> At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > On Thu, 19 Apr 2012 15:15:27 +0100
> > Tim Deegan <tim@xen.org> wrote:

>you still have this mapping.  You should take a PGT_writeable_page
>typecount, too, if the foreign domain isn't in paging_mode_external

Ok, I've it as:
    if (paging_mode_external(fdom)) {
        if (get_page_from_pagenr(mfn, fdom) == 0)
	    failed = 1;
    } else {
        if (get_page_and_type_from_pagenr(mfn, PGT_writable_page, fdom,0,0))
            failed = 1;
    }

But then later fails when it tries to pin the page,
MMUEXT_PIN_L4_TABLE, from the lib at:

        rc = pin_table(dom->xch, pgd_type,
	                xc_dom_p2m_host(dom, dom->pgtables_seg.pfn),
			dom->guest_domid);

(XEN) mm.c:2424:d0 Bad type (saw 7400000000000001 != exp 4000000000000000) for mfn 1bc160 (pfn 2eed)

thanks,
-m


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:22:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMp32-0002XL-9I; Tue, 24 Apr 2012 23:21:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMp30-0002XG-8M
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 23:21:26 +0000
Received: from [85.158.139.83:19879] by server-10.bemta-5.messagelabs.com id
	6C/9D-08260-575379F4; Tue, 24 Apr 2012 23:21:25 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335309684!24657236!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29964 invoked from network); 24 Apr 2012 23:21:24 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-9.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 23:21:24 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 6D656D3472B;
	Wed, 25 Apr 2012 01:21:24 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id mgwPB2lrqg+x; Wed, 25 Apr 2012 01:21:12 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id B03C3D341B3;
	Wed, 25 Apr 2012 01:21:12 +0200 (CEST)
Message-ID: <4F973568.6000002@vido.info>
Date: Wed, 25 Apr 2012 01:21:12 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
	<20120424163027.GI3213@phenom.dumpdata.com>
In-Reply-To: <20120424163027.GI3213@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 18:30, schrieb Konrad Rzeszutek Wilk:
>>>> I redid the test;
>>>>
>>>> a) with 3.3.0 kernel
>>>> b) with 3.4.0-rc4
>>>> c) with 3.40-rc4 and above patch
>>>>
>>>> everything else remained the same, i.e. test-program and test-scenario
>>>> was not changed and started after about 5min of domu bootup (so that no
>>>> strange bootup-effects become relevant); same phy-backend (lvm on ssd),
>>>> same everything else; so i cant see what else except the used dom0
>>>> kernel is causing this issue; but here are the numbers:
>>>>
>>>> a) read: 135mb/s write: 142mb/s
>>>> b) read: 39mb/s  write: 39mb/s
>>>> c) read: 40mb/s  write: 40mb/s
>>>>
>>>> Only thing that may become relevant is the difference in kernel-config
>>>> betwen 3.3 and 3.4 - here's the diff :
>>>> http://pastebin.com/raw.php?i=Dy71Fegq
>>>>
>>>> Jan, it seems you're right: The patch doesn't add extra performance
>>>> regression - i guess i had an i/o intensive task running in dom0 while
>>>> doing the benchmark yesterday, so that the write performance got so bad.
>>>> sorry for that.
>>>>
>>>> Still there's a significant performance penalty from 3.3 to 3.4
>>> Could you please try to revert the following commits?
>>>
>>> git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
> No way
>>> git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
> Startup.
>>> git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
> Hm, this is just during startup.
>>> git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
> No way.
>
>
>>> git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
> Perhaps? But I am not seeing it.
>
>>> git revert -n 9846ff10af12f9e7caac696737db6c990592a74a
> Perhaps?
>> after reverting said 6 commits (thanks for the ids of these - had difficulties
>> to find them), the performance is back to normal.
>>
>> should i try to circle it down to one of this 6, or do you have a hint on
>> which it might be?
> I think either off these: 4f14faaab4ee46a046b6baff85644be199de718c
> 9846ff10af12f9e7caac696737db6c990592a74a might be the culprit.
>
> Try the 9846ff10 first.
>
>> Greetings
>> Tobias

Hi,

9846ff10 was it!
after reverting it, performance returned to normal.

Thanks!
Tobias





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:22:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMp32-0002XL-9I; Tue, 24 Apr 2012 23:21:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMp30-0002XG-8M
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 23:21:26 +0000
Received: from [85.158.139.83:19879] by server-10.bemta-5.messagelabs.com id
	6C/9D-08260-575379F4; Tue, 24 Apr 2012 23:21:25 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335309684!24657236!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29964 invoked from network); 24 Apr 2012 23:21:24 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-9.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 23:21:24 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 6D656D3472B;
	Wed, 25 Apr 2012 01:21:24 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id mgwPB2lrqg+x; Wed, 25 Apr 2012 01:21:12 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id B03C3D341B3;
	Wed, 25 Apr 2012 01:21:12 +0200 (CEST)
Message-ID: <4F973568.6000002@vido.info>
Date: Wed, 25 Apr 2012 01:21:12 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
	<20120424163027.GI3213@phenom.dumpdata.com>
In-Reply-To: <20120424163027.GI3213@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 18:30, schrieb Konrad Rzeszutek Wilk:
>>>> I redid the test;
>>>>
>>>> a) with 3.3.0 kernel
>>>> b) with 3.4.0-rc4
>>>> c) with 3.40-rc4 and above patch
>>>>
>>>> everything else remained the same, i.e. test-program and test-scenario
>>>> was not changed and started after about 5min of domu bootup (so that no
>>>> strange bootup-effects become relevant); same phy-backend (lvm on ssd),
>>>> same everything else; so i cant see what else except the used dom0
>>>> kernel is causing this issue; but here are the numbers:
>>>>
>>>> a) read: 135mb/s write: 142mb/s
>>>> b) read: 39mb/s  write: 39mb/s
>>>> c) read: 40mb/s  write: 40mb/s
>>>>
>>>> Only thing that may become relevant is the difference in kernel-config
>>>> betwen 3.3 and 3.4 - here's the diff :
>>>> http://pastebin.com/raw.php?i=Dy71Fegq
>>>>
>>>> Jan, it seems you're right: The patch doesn't add extra performance
>>>> regression - i guess i had an i/o intensive task running in dom0 while
>>>> doing the benchmark yesterday, so that the write performance got so bad.
>>>> sorry for that.
>>>>
>>>> Still there's a significant performance penalty from 3.3 to 3.4
>>> Could you please try to revert the following commits?
>>>
>>> git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad
> No way
>>> git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5
> Startup.
>>> git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f
> Hm, this is just during startup.
>>> git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595
> No way.
>
>
>>> git revert -n 4f14faaab4ee46a046b6baff85644be199de718c
> Perhaps? But I am not seeing it.
>
>>> git revert -n 9846ff10af12f9e7caac696737db6c990592a74a
> Perhaps?
>> after reverting said 6 commits (thanks for the ids of these - had difficulties
>> to find them), the performance is back to normal.
>>
>> should i try to circle it down to one of this 6, or do you have a hint on
>> which it might be?
> I think either off these: 4f14faaab4ee46a046b6baff85644be199de718c
> 9846ff10af12f9e7caac696737db6c990592a74a might be the culprit.
>
> Try the 9846ff10 first.
>
>> Greetings
>> Tobias

Hi,

9846ff10 was it!
after reverting it, performance returned to normal.

Thanks!
Tobias





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:29:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:29:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpA4-0002fT-61; Tue, 24 Apr 2012 23:28:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMpA3-0002fO-Ew
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 23:28:43 +0000
Received: from [85.158.139.83:56144] by server-8.bemta-5.messagelabs.com id
	43/CE-26964-A27379F4; Tue, 24 Apr 2012 23:28:42 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335310121!21062480!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UPPERCASE_25_50
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23614 invoked from network); 24 Apr 2012 23:28:41 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-14.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 23:28:41 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id B11C6D3472B;
	Wed, 25 Apr 2012 01:28:41 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id gqB3K2aOxzW3; Wed, 25 Apr 2012 01:28:39 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 3B523D341B3;
	Wed, 25 Apr 2012 01:28:39 +0200 (CEST)
Message-ID: <4F973726.9010405@vido.info>
Date: Wed, 25 Apr 2012 01:28:38 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201204241904.03726.tobias.geiger@vido.info>
	<20120424173601.GA27353@phenom.dumpdata.com>
In-Reply-To: <20120424173601.GA27353@phenom.dumpdata.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 19:36, schrieb Konrad Rzeszutek Wilk:
> On Tue, Apr 24, 2012 at 07:04:03PM +0200, Tobias Geiger wrote:
>> Hi,
>>
>> i'm not sure if i understood the new acpi xen cpufreq driver - here's the
>> output when loading  xen_acpi_processor module in linux 3.4:
>>
>> dom0 dmesg:
>>
>> [   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
>> [   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
>> [   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
>> [   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
>> [   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
>> [   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
>> [   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14
>>
>>
>>
>> xl dmesg:
>>
>> (XEN) Monitor-Mwait will be used to enter C1 state
>> (XEN) Monitor-Mwait will be used to enter C3 state
>> (XEN) no cpu_id for acpi_id 8
>> (XEN) no cpu_id for acpi_id 9
>> (XEN) no cpu_id for acpi_id 10
>> (XEN) no cpu_id for acpi_id 11
>> (XEN) no cpu_id for acpi_id 12
>> (XEN) no cpu_id for acpi_id 13
>> (XEN) no cpu_id for acpi_id 14
>>
>>
>> here the according kernel config:
>>
>> pc:~# zcat /proc/config.gz | grep FREQ
>> CONFIG_CPU_FREQ=y
>> CONFIG_CPU_FREQ_TABLE=y
>> CONFIG_CPU_FREQ_STAT=m
>> # CONFIG_CPU_FREQ_STAT_DETAILS is not set
>> # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
>> # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
>> CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
>> # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
>> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
>> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
>> CONFIG_CPU_FREQ_GOV_USERSPACE=m
>> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
>> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
>> CONFIG_X86_PCC_CPUFREQ=m
>> CONFIG_X86_ACPI_CPUFREQ=m
>> # CONFIG_PM_DEVFREQ is not set
>>
>> and of course:
>> CONFIG_XEN_ACPI_PROCESSOR=m
>>
>> xl info:
>> nr_cpus                : 8
>> max_cpu_id             : 15
>> nr_nodes               : 1
>> cores_per_socket       : 4
>> threads_per_core       : 2
> Can you include your xl dmesg and dmesg and as well
> the /sys/firmware/acpi/tables/DSDT and /sys/firmware/acpi/tables/SSDT*
> files please?
>
> Does xenpm work properly?
>
>>
>> Greetings and thanks for clarification!
>> Tobias


xenpm works - at least "xenpm get-cpuidle-states" and "xenpm 
get-cpufreq-states".

here you can find my acpi-tables including "xl dmesg" and "dmesg" output:

http://www.vido.info/stuff/acpi-tables-2.6.34-rc4.tar.bz2

Greetings
Tobias



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:29:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:29:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpA4-0002fT-61; Tue, 24 Apr 2012 23:28:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SMpA3-0002fO-Ew
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 23:28:43 +0000
Received: from [85.158.139.83:56144] by server-8.bemta-5.messagelabs.com id
	43/CE-26964-A27379F4; Tue, 24 Apr 2012 23:28:42 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335310121!21062480!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UPPERCASE_25_50
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23614 invoked from network); 24 Apr 2012 23:28:41 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-14.tower-182.messagelabs.com with SMTP;
	24 Apr 2012 23:28:41 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id B11C6D3472B;
	Wed, 25 Apr 2012 01:28:41 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id gqB3K2aOxzW3; Wed, 25 Apr 2012 01:28:39 +0200 (CEST)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 3B523D341B3;
	Wed, 25 Apr 2012 01:28:39 +0200 (CEST)
Message-ID: <4F973726.9010405@vido.info>
Date: Wed, 25 Apr 2012 01:28:38 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201204241904.03726.tobias.geiger@vido.info>
	<20120424173601.GA27353@phenom.dumpdata.com>
In-Reply-To: <20120424173601.GA27353@phenom.dumpdata.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 24.04.2012 19:36, schrieb Konrad Rzeszutek Wilk:
> On Tue, Apr 24, 2012 at 07:04:03PM +0200, Tobias Geiger wrote:
>> Hi,
>>
>> i'm not sure if i understood the new acpi xen cpufreq driver - here's the
>> output when loading  xen_acpi_processor module in linux 3.4:
>>
>> dom0 dmesg:
>>
>> [   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
>> [   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
>> [   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
>> [   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
>> [   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
>> [   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
>> [   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14
>>
>>
>>
>> xl dmesg:
>>
>> (XEN) Monitor-Mwait will be used to enter C1 state
>> (XEN) Monitor-Mwait will be used to enter C3 state
>> (XEN) no cpu_id for acpi_id 8
>> (XEN) no cpu_id for acpi_id 9
>> (XEN) no cpu_id for acpi_id 10
>> (XEN) no cpu_id for acpi_id 11
>> (XEN) no cpu_id for acpi_id 12
>> (XEN) no cpu_id for acpi_id 13
>> (XEN) no cpu_id for acpi_id 14
>>
>>
>> here the according kernel config:
>>
>> pc:~# zcat /proc/config.gz | grep FREQ
>> CONFIG_CPU_FREQ=y
>> CONFIG_CPU_FREQ_TABLE=y
>> CONFIG_CPU_FREQ_STAT=m
>> # CONFIG_CPU_FREQ_STAT_DETAILS is not set
>> # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
>> # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
>> CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
>> # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
>> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
>> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
>> CONFIG_CPU_FREQ_GOV_USERSPACE=m
>> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
>> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
>> CONFIG_X86_PCC_CPUFREQ=m
>> CONFIG_X86_ACPI_CPUFREQ=m
>> # CONFIG_PM_DEVFREQ is not set
>>
>> and of course:
>> CONFIG_XEN_ACPI_PROCESSOR=m
>>
>> xl info:
>> nr_cpus                : 8
>> max_cpu_id             : 15
>> nr_nodes               : 1
>> cores_per_socket       : 4
>> threads_per_core       : 2
> Can you include your xl dmesg and dmesg and as well
> the /sys/firmware/acpi/tables/DSDT and /sys/firmware/acpi/tables/SSDT*
> files please?
>
> Does xenpm work properly?
>
>>
>> Greetings and thanks for clarification!
>> Tobias


xenpm works - at least "xenpm get-cpuidle-states" and "xenpm 
get-cpufreq-states".

here you can find my acpi-tables including "xl dmesg" and "dmesg" output:

http://www.vido.info/stuff/acpi-tables-2.6.34-rc4.tar.bz2

Greetings
Tobias



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:33:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpDl-0002mK-Rf; Tue, 24 Apr 2012 23:32:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMpDk-0002mE-Je
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 23:32:32 +0000
Received: from [85.158.143.35:9132] by server-1.bemta-4.messagelabs.com id
	2D/0E-20925-F08379F4; Tue, 24 Apr 2012 23:32:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335310351!13504061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25315 invoked from network); 24 Apr 2012 23:32:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 23:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,476,1330905600"; d="scan'208";a="12117439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 23:32:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 00:32:30 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMpDi-0001Jx-7D;
	Tue, 24 Apr 2012 23:32:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMpDi-00069B-4f;
	Wed, 25 Apr 2012 00:32:30 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12743-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 00:32:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12743: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12743 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12743/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12738

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1a8b47d80157
baseline version:
 xen                  274e5accd62d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=1a8b47d80157
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 1a8b47d80157
+ branch=xen-unstable
+ revision=1a8b47d80157
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1a8b47d80157 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:33:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpDl-0002mK-Rf; Tue, 24 Apr 2012 23:32:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMpDk-0002mE-Je
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 23:32:32 +0000
Received: from [85.158.143.35:9132] by server-1.bemta-4.messagelabs.com id
	2D/0E-20925-F08379F4; Tue, 24 Apr 2012 23:32:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335310351!13504061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjcyOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25315 invoked from network); 24 Apr 2012 23:32:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 23:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,476,1330905600"; d="scan'208";a="12117439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Apr 2012 23:32:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 00:32:30 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMpDi-0001Jx-7D;
	Tue, 24 Apr 2012 23:32:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMpDi-00069B-4f;
	Wed, 25 Apr 2012 00:32:30 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12743-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 00:32:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12743: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12743 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12743/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12738

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1a8b47d80157
baseline version:
 xen                  274e5accd62d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=1a8b47d80157
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 1a8b47d80157
+ branch=xen-unstable
+ revision=1a8b47d80157
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1a8b47d80157 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpRd-00030x-8o; Tue, 24 Apr 2012 23:46:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SMpRb-00030s-3z
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 23:46:51 +0000
Received: from [85.158.143.35:14251] by server-2.bemta-4.messagelabs.com id
	77/91-17550-A6B379F4; Tue, 24 Apr 2012 23:46:50 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335311208!6358997!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4781 invoked from network); 24 Apr 2012 23:46:49 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 23:46:49 -0000
Received: by pbcuo5 with SMTP id uo5so812463pbc.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 16:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=tiYDDwuNDGH6c3QCytPh3C1kN4TWidZgDuHQyWKTd1Q=;
	b=Nym3Ny+2F3DWx2MaC/6enbfn4o8gzyH3J3ZGLHyDqJdG8oWceoELpkbh7BGhmLUmr7
	gIotk/oXtZS+oWTiVa0M/ErzRXJ+xC0e572XAJMeMcCWbPVOzK46qDVMFUiu+SNclEk2
	BFdJA04An3VJzjoDTgE3L8j3IGrjKhm+4RmDZR/jnIkWDm8gsh8LZH0fZmrmqwr+LO4w
	CPkcn6WPaiqTOwmiJQNPEce0I/jL9cToJL3eYiSMVirM1W1ovqCfGd4Fbpo4ZORWmP3a
	16xKG+0Y+HXmES5xGDJjETwHlcltflwnjUoaELcGFCYD870LuvQhJRhA/SljcqjIK7Qb
	KNCA==
MIME-Version: 1.0
Received: by 10.68.201.169 with SMTP id kb9mr1944427pbc.146.1335311207618;
	Tue, 24 Apr 2012 16:46:47 -0700 (PDT)
Received: by 10.68.134.228 with HTTP; Tue, 24 Apr 2012 16:46:47 -0700 (PDT)
In-Reply-To: <20374.55375.731329.295389@mariner.uk.xensource.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
	<CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
	<20374.55375.731329.295389@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 07:46:47 +0800
Message-ID: <CAEwRVpOpzqB597C=JKzKEd7jY8SeXSSf5-ey97xH86pF_8Q4RA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 12:43 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Teck Choon Giam writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
>> On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > The time has come for another round of stable releases.
>> >
>> > Please send (or resend) any outstanding backport requests for 4.0.4 and
>> > 4.1.3 before Friday 20 April.
>>
>> I don't know whether can non-commit xen-unstable be considered for
>> backport so I am trying since deadline is before coming Friday 20
>> April 2012.
>>
>> libxl/xend: name tap devices with a xentap prefix
>
> Yes, I think this is OK in principle but we should wait for the
> patches to actually go into -unstable and be tested there, before we
> apply them to earlier trees.
>
> IIRC we are waiting for a repost of the -unstable version ?

Yes, waiting for the reposts from Ian C. while he is waiting for the
hotplug series (I think) from err... someone (sorry, can't remember
names but I guess is Roger) else to be committed in xen-unstable or
something.  Thanks for letting me know about this is OK to backport
and I agree that we shall wait for it to be committed in xen-unstable
before backporting to earlier tree.
>
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Apr 24 23:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Apr 2012 23:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpRd-00030x-8o; Tue, 24 Apr 2012 23:46:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1SMpRb-00030s-3z
	for xen-devel@lists.xen.org; Tue, 24 Apr 2012 23:46:51 +0000
Received: from [85.158.143.35:14251] by server-2.bemta-4.messagelabs.com id
	77/91-17550-A6B379F4; Tue, 24 Apr 2012 23:46:50 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335311208!6358997!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4781 invoked from network); 24 Apr 2012 23:46:49 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 23:46:49 -0000
Received: by pbcuo5 with SMTP id uo5so812463pbc.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 16:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=tiYDDwuNDGH6c3QCytPh3C1kN4TWidZgDuHQyWKTd1Q=;
	b=Nym3Ny+2F3DWx2MaC/6enbfn4o8gzyH3J3ZGLHyDqJdG8oWceoELpkbh7BGhmLUmr7
	gIotk/oXtZS+oWTiVa0M/ErzRXJ+xC0e572XAJMeMcCWbPVOzK46qDVMFUiu+SNclEk2
	BFdJA04An3VJzjoDTgE3L8j3IGrjKhm+4RmDZR/jnIkWDm8gsh8LZH0fZmrmqwr+LO4w
	CPkcn6WPaiqTOwmiJQNPEce0I/jL9cToJL3eYiSMVirM1W1ovqCfGd4Fbpo4ZORWmP3a
	16xKG+0Y+HXmES5xGDJjETwHlcltflwnjUoaELcGFCYD870LuvQhJRhA/SljcqjIK7Qb
	KNCA==
MIME-Version: 1.0
Received: by 10.68.201.169 with SMTP id kb9mr1944427pbc.146.1335311207618;
	Tue, 24 Apr 2012 16:46:47 -0700 (PDT)
Received: by 10.68.134.228 with HTTP; Tue, 24 Apr 2012 16:46:47 -0700 (PDT)
In-Reply-To: <20374.55375.731329.295389@mariner.uk.xensource.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
	<CAEwRVpOzV3d74umFuyV2aX74PqZZDnMSfyk0NVjR2LwSHopJpg@mail.gmail.com>
	<20374.55375.731329.295389@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 07:46:47 +0800
Message-ID: <CAEwRVpOpzqB597C=JKzKEd7jY8SeXSSf5-ey97xH86pF_8Q4RA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 12:43 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Teck Choon Giam writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
>> On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > The time has come for another round of stable releases.
>> >
>> > Please send (or resend) any outstanding backport requests for 4.0.4 and
>> > 4.1.3 before Friday 20 April.
>>
>> I don't know whether can non-commit xen-unstable be considered for
>> backport so I am trying since deadline is before coming Friday 20
>> April 2012.
>>
>> libxl/xend: name tap devices with a xentap prefix
>
> Yes, I think this is OK in principle but we should wait for the
> patches to actually go into -unstable and be tested there, before we
> apply them to earlier trees.
>
> IIRC we are waiting for a repost of the -unstable version ?

Yes, waiting for the reposts from Ian C. while he is waiting for the
hotplug series (I think) from err... someone (sorry, can't remember
names but I guess is Roger) else to be committed in xen-unstable or
something.  Thanks for letting me know about this is OK to backport
and I agree that we shall wait for it to be committed in xen-unstable
before backporting to earlier tree.
>
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 00:00:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 00:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpef-0003de-TB; Wed, 25 Apr 2012 00:00:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1SMpef-0003dZ-0k
	for Xen-devel@lists.xensource.com; Wed, 25 Apr 2012 00:00:21 +0000
Received: from [85.158.139.83:9223] by server-5.bemta-5.messagelabs.com id
	81/B3-13566-49E379F4; Wed, 25 Apr 2012 00:00:20 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335312017!25330303!1
X-Originating-IP: [203.10.76.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25688 invoked from network); 25 Apr 2012 00:00:18 -0000
Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10)
	by server-12.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 00:00:18 -0000
Received: from canb.auug.org.au (ash.rothwell.emu.id.au
	[IPv6:2402:b800:7003:7010:223:14ff:fe30:c8e4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by members.tip.net.au (Postfix) with ESMTPSA id BAF8A1640A6;
	Wed, 25 Apr 2012 10:00:10 +1000 (EST)
Date: Wed, 25 Apr 2012 10:00:02 +1000
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-Id: <20120425100002.a288b8b25dee6cecf813a69c@canb.auug.org.au>
In-Reply-To: <4F9722CA.80403@goop.org>
References: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
	<20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
	<4F9722CA.80403@goop.org>
X-Mailer: Sylpheed 3.2.0beta7 (GTK+ 2.24.10; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: Xen Devel <Xen-devel@lists.xensource.com>,
	LKML <linux-kernel@vger.kernel.org>, linux-next@vger.kernel.org,
	Ben Dooks <ben-linux@fluff.org>, Rob Lee <rob.lee@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Xen-devel] linux-next: clean up time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5689522242112970085=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5689522242112970085==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1."

--Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1.
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

On Tue, 24 Apr 2012 15:01:46 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wr=
ote:
>
> Are you pulling from xen.git upstream/xen?  I just updated it to be
> current Linus master, so it shouldn't conflict any more.

Yes, I fetch branch upstream/xen from
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git and, yes, it
is empty now, thanks.

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1.
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPlz6CAAoJEECxmPOUX5FEDCMP/2MEVG7K8zd0nCqsDaH/fD/f
RBjLDe5JwSPEDkY9mFJAiS4qhIVNItefqaZO9RzcODT+4nfJAVyp48TXgTB+WS98
AFUYKHM6cFanPlLbUMIzxV5ZVZgDGiN2apbg4fcn9vfkCYBJNzm0ozaABm3xQpDQ
J0LyLiRHmzxDHamgqV5rvKTTJakghV7g37B7X6uq5LawYaF6CRk0jH8/JI0nwO9D
Wb4p22DqkxihG11JrCmpFH0SAozMO+x8h3QaUJ0H7XJyjt9tP6IO9xaNYpapEd65
gqIrSE4OoxmBPsoLZcx1q14IJVb81ccY8WWkKjlxckxUTziETU7itX6cFCF5ehZ/
W8Yr4OeePr61FoEC+Q7EXyYjXjDiScCqXphCbdGDjX/yPRxB4D8ERabFUBMxL21j
+ZCEHQYBZ8rhX5/mbN4m6KEK3a/akT1ZTOHzlqn0oSac4Vpic0KFwEAL7xzmwD7C
XVQilu4PGwJJFvpPA/s5nPaIM1D5j+SS2iWt4/EKTNFsU54RJHGTn05Le+R+sIdB
x5KeGhkGjKNLm3IsZmt6ZE5D6kEVD3814K4/KzMiHeMjNfvqm/DX9UDBkiWub8uo
7T8cT+NbdDAS41IBIjYIC9rEzj8M4NXJ7tpldjaXJn4QKle9Xxd7rePl9ABJz66n
88Ky7oUiCaDbUvirvBh0
=aDPw
-----END PGP SIGNATURE-----

--Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1.--


--===============5689522242112970085==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5689522242112970085==--


From xen-devel-bounces@lists.xen.org Wed Apr 25 00:00:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 00:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMpef-0003de-TB; Wed, 25 Apr 2012 00:00:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1SMpef-0003dZ-0k
	for Xen-devel@lists.xensource.com; Wed, 25 Apr 2012 00:00:21 +0000
Received: from [85.158.139.83:9223] by server-5.bemta-5.messagelabs.com id
	81/B3-13566-49E379F4; Wed, 25 Apr 2012 00:00:20 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335312017!25330303!1
X-Originating-IP: [203.10.76.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25688 invoked from network); 25 Apr 2012 00:00:18 -0000
Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10)
	by server-12.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 00:00:18 -0000
Received: from canb.auug.org.au (ash.rothwell.emu.id.au
	[IPv6:2402:b800:7003:7010:223:14ff:fe30:c8e4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by members.tip.net.au (Postfix) with ESMTPSA id BAF8A1640A6;
	Wed, 25 Apr 2012 10:00:10 +1000 (EST)
Date: Wed, 25 Apr 2012 10:00:02 +1000
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-Id: <20120425100002.a288b8b25dee6cecf813a69c@canb.auug.org.au>
In-Reply-To: <4F9722CA.80403@goop.org>
References: <20120402112009.3477dad7deff0f4d87f49b29@canb.auug.org.au>
	<20120423164859.082b5c53b5d9bd9a524ec864@canb.auug.org.au>
	<4F9722CA.80403@goop.org>
X-Mailer: Sylpheed 3.2.0beta7 (GTK+ 2.24.10; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: Xen Devel <Xen-devel@lists.xensource.com>,
	LKML <linux-kernel@vger.kernel.org>, linux-next@vger.kernel.org,
	Ben Dooks <ben-linux@fluff.org>, Rob Lee <rob.lee@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Xen-devel] linux-next: clean up time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5689522242112970085=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5689522242112970085==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1."

--Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1.
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

On Tue, 24 Apr 2012 15:01:46 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wr=
ote:
>
> Are you pulling from xen.git upstream/xen?  I just updated it to be
> current Linus master, so it shouldn't conflict any more.

Yes, I fetch branch upstream/xen from
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git and, yes, it
is empty now, thanks.

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1.
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPlz6CAAoJEECxmPOUX5FEDCMP/2MEVG7K8zd0nCqsDaH/fD/f
RBjLDe5JwSPEDkY9mFJAiS4qhIVNItefqaZO9RzcODT+4nfJAVyp48TXgTB+WS98
AFUYKHM6cFanPlLbUMIzxV5ZVZgDGiN2apbg4fcn9vfkCYBJNzm0ozaABm3xQpDQ
J0LyLiRHmzxDHamgqV5rvKTTJakghV7g37B7X6uq5LawYaF6CRk0jH8/JI0nwO9D
Wb4p22DqkxihG11JrCmpFH0SAozMO+x8h3QaUJ0H7XJyjt9tP6IO9xaNYpapEd65
gqIrSE4OoxmBPsoLZcx1q14IJVb81ccY8WWkKjlxckxUTziETU7itX6cFCF5ehZ/
W8Yr4OeePr61FoEC+Q7EXyYjXjDiScCqXphCbdGDjX/yPRxB4D8ERabFUBMxL21j
+ZCEHQYBZ8rhX5/mbN4m6KEK3a/akT1ZTOHzlqn0oSac4Vpic0KFwEAL7xzmwD7C
XVQilu4PGwJJFvpPA/s5nPaIM1D5j+SS2iWt4/EKTNFsU54RJHGTn05Le+R+sIdB
x5KeGhkGjKNLm3IsZmt6ZE5D6kEVD3814K4/KzMiHeMjNfvqm/DX9UDBkiWub8uo
7T8cT+NbdDAS41IBIjYIC9rEzj8M4NXJ7tpldjaXJn4QKle9Xxd7rePl9ABJz66n
88Ky7oUiCaDbUvirvBh0
=aDPw
-----END PGP SIGNATURE-----

--Signature=_Wed__25_Apr_2012_10_00_02_+1000_r6sxjq7e5PnFLL1.--


--===============5689522242112970085==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5689522242112970085==--


From xen-devel-bounces@lists.xen.org Wed Apr 25 00:28:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 00:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMq5X-0003rT-CC; Wed, 25 Apr 2012 00:28:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMq5W-0003rO-2V
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 00:28:06 +0000
Received: from [85.158.139.83:54537] by server-8.bemta-5.messagelabs.com id
	1D/7D-26964-515479F4; Wed, 25 Apr 2012 00:28:05 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335313683!24807739!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28579 invoked from network); 25 Apr 2012 00:28:04 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 00:28:04 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 17:28:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134930515"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 17:28:02 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 17:28:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 08:28:00 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2A=
Date: Wed, 25 Apr 2012 00:27:59 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
In-Reply-To: <20120424091646.GB34721@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Tuesday, April 24, 2012 5:17 PM
> To: Zhang, Yang Z
> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir Fraser
> Subject: Re: [Xen-devel] lock in vhpet
> 
> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> > > -----Original Message-----
> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > > Sent: Tuesday, April 24, 2012 1:19 AM
> > >
> > > Let me know if any of this helps
> > No, it not works.
> 
> Do you mean that it doesn't help with the CPU overhead, or that it's broken in
> some other way?
> 
It cannot help with the CPU overhead

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 00:28:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 00:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMq5X-0003rT-CC; Wed, 25 Apr 2012 00:28:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMq5W-0003rO-2V
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 00:28:06 +0000
Received: from [85.158.139.83:54537] by server-8.bemta-5.messagelabs.com id
	1D/7D-26964-515479F4; Wed, 25 Apr 2012 00:28:05 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335313683!24807739!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28579 invoked from network); 25 Apr 2012 00:28:04 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 00:28:04 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 17:28:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134930515"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 17:28:02 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 17:28:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 08:28:00 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2A=
Date: Wed, 25 Apr 2012 00:27:59 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
In-Reply-To: <20120424091646.GB34721@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Tuesday, April 24, 2012 5:17 PM
> To: Zhang, Yang Z
> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir Fraser
> Subject: Re: [Xen-devel] lock in vhpet
> 
> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> > > -----Original Message-----
> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > > Sent: Tuesday, April 24, 2012 1:19 AM
> > >
> > > Let me know if any of this helps
> > No, it not works.
> 
> Do you mean that it doesn't help with the CPU overhead, or that it's broken in
> some other way?
> 
It cannot help with the CPU overhead

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 01:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 01:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMqsd-0007yG-F8; Wed, 25 Apr 2012 01:18:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMqsc-0007yB-2Y
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 01:18:50 +0000
Received: from [193.109.254.147:37807] by server-2.bemta-14.messagelabs.com id
	29/1A-19409-9F0579F4; Wed, 25 Apr 2012 01:18:49 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335316728!6202301!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5OTg0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30690 invoked from network); 25 Apr 2012 01:18:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-27.messagelabs.com with SMTP;
	25 Apr 2012 01:18:48 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Apr 2012 18:18:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134944611"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 18:18:43 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 18:18:43 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 09:18:41 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNIkR6vbaZY0ZDxUaVSAYYvGL0fJaqvVlg
Date: Wed, 25 Apr 2012 01:18:41 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3D4AF@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
In-Reply-To: <20374.60088.396314.671522@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I work on unstable tree.

I think the confliction is my MS outlook configuration issue, I'll re-resend a revised patch.

Thanks,
-Xudong

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Wednesday, April 25, 2012 2:03 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> > <Porting from xen 4.1, patch on Xen unstable 25138>
> 
> I'm afraid that 25138 was out of date even when you posted your revised patch,
> and it still doesn't apply.
> 
> Are you working with the staging tree ?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 01:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 01:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMqsd-0007yG-F8; Wed, 25 Apr 2012 01:18:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMqsc-0007yB-2Y
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 01:18:50 +0000
Received: from [193.109.254.147:37807] by server-2.bemta-14.messagelabs.com id
	29/1A-19409-9F0579F4; Wed, 25 Apr 2012 01:18:49 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335316728!6202301!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5OTg0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30690 invoked from network); 25 Apr 2012 01:18:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-27.messagelabs.com with SMTP;
	25 Apr 2012 01:18:48 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Apr 2012 18:18:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134944611"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 18:18:43 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 18:18:43 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 09:18:41 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNIkR6vbaZY0ZDxUaVSAYYvGL0fJaqvVlg
Date: Wed, 25 Apr 2012 01:18:41 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3D4AF@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
In-Reply-To: <20374.60088.396314.671522@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I work on unstable tree.

I think the confliction is my MS outlook configuration issue, I'll re-resend a revised patch.

Thanks,
-Xudong

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Wednesday, April 25, 2012 2:03 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> > <Porting from xen 4.1, patch on Xen unstable 25138>
> 
> I'm afraid that 25138 was out of date even when you posted your revised patch,
> and it still doesn't apply.
> 
> Are you working with the staging tree ?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 01:41:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 01:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrDd-0008AD-Cx; Wed, 25 Apr 2012 01:40:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMrDc-0008A8-E0
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 01:40:32 +0000
Received: from [85.158.143.99:5493] by server-1.bemta-4.messagelabs.com id
	29/EA-20925-F06579F4; Wed, 25 Apr 2012 01:40:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335318030!15491060!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15258 invoked from network); 25 Apr 2012 01:40:30 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-216.messagelabs.com with SMTP;
	25 Apr 2012 01:40:30 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 79554604061;
	Tue, 24 Apr 2012 18:40:29 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MJvSy+GjHysiMpq2wTRgUpVj+cP9TzSshXo0uJzjVQct
	5wJZl7wlBpq7Eq6Ijvgk/JKfkYJeN/qkET5VzIUEB/fwhjo5jHJV5UJzUFezd3bB
	rMw4W6rUTH4DPUjHDxKU0Jtovngb++uWo+1kNrMv1SS9j78jBgUdacETxOdo+Bw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=KQRlFTQlb0KaeLIPb1omFSVkYnM=; b=iF0PJn88
	VNWy2WzMDqNy6vjgT3uyt1J0bsSI52Vas68VrduHWc0I3PD04UGI18aD0sYK/p2t
	OESNf1An7a4b+IQErF3b4QGWCAbd7L6Fvnzbvp2qvvW0r4hkv8RM36M+AebaC5JO
	H61ZB7wJQ+LwJO84NezHVnrArFkrxAfgnPg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 1C03360405D; 
	Tue, 24 Apr 2012 18:40:29 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 18:40:29 -0700
Message-ID: <958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 18:40:29 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Tim Deegan [mailto:tim@xen.org]
>> Sent: Tuesday, April 24, 2012 5:17 PM
>> To: Zhang, Yang Z
>> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: Re: [Xen-devel] lock in vhpet
>>
>> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> > > -----Original Message-----
>> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> > >
>> > > Let me know if any of this helps
>> > No, it not works.
>>
>> Do you mean that it doesn't help with the CPU overhead, or that it's
>> broken in
>> some other way?
>>
> It cannot help with the CPU overhead

Yang, is there any further information you can provide? A rough idea of
where vcpus are spending time spinning for the p2m lock would be
tremendously useful.

Thanks
Andres

>
> best regards
> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 01:41:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 01:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrDd-0008AD-Cx; Wed, 25 Apr 2012 01:40:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMrDc-0008A8-E0
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 01:40:32 +0000
Received: from [85.158.143.99:5493] by server-1.bemta-4.messagelabs.com id
	29/EA-20925-F06579F4; Wed, 25 Apr 2012 01:40:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335318030!15491060!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15258 invoked from network); 25 Apr 2012 01:40:30 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-216.messagelabs.com with SMTP;
	25 Apr 2012 01:40:30 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 79554604061;
	Tue, 24 Apr 2012 18:40:29 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MJvSy+GjHysiMpq2wTRgUpVj+cP9TzSshXo0uJzjVQct
	5wJZl7wlBpq7Eq6Ijvgk/JKfkYJeN/qkET5VzIUEB/fwhjo5jHJV5UJzUFezd3bB
	rMw4W6rUTH4DPUjHDxKU0Jtovngb++uWo+1kNrMv1SS9j78jBgUdacETxOdo+Bw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=KQRlFTQlb0KaeLIPb1omFSVkYnM=; b=iF0PJn88
	VNWy2WzMDqNy6vjgT3uyt1J0bsSI52Vas68VrduHWc0I3PD04UGI18aD0sYK/p2t
	OESNf1An7a4b+IQErF3b4QGWCAbd7L6Fvnzbvp2qvvW0r4hkv8RM36M+AebaC5JO
	H61ZB7wJQ+LwJO84NezHVnrArFkrxAfgnPg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 1C03360405D; 
	Tue, 24 Apr 2012 18:40:29 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 18:40:29 -0700
Message-ID: <958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 18:40:29 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Tim Deegan [mailto:tim@xen.org]
>> Sent: Tuesday, April 24, 2012 5:17 PM
>> To: Zhang, Yang Z
>> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: Re: [Xen-devel] lock in vhpet
>>
>> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> > > -----Original Message-----
>> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> > >
>> > > Let me know if any of this helps
>> > No, it not works.
>>
>> Do you mean that it doesn't help with the CPU overhead, or that it's
>> broken in
>> some other way?
>>
> It cannot help with the CPU overhead

Yang, is there any further information you can provide? A rough idea of
where vcpus are spending time spinning for the p2m lock would be
tremendously useful.

Thanks
Andres

>
> best regards
> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 01:49:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 01:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrLS-0008J3-Bs; Wed, 25 Apr 2012 01:48:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMrLR-0008Iw-Cr
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 01:48:37 +0000
Received: from [85.158.138.51:24503] by server-7.bemta-3.messagelabs.com id
	D8/13-03078-4F7579F4; Wed, 25 Apr 2012 01:48:36 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335318515!23647254!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2417 invoked from network); 25 Apr 2012 01:48:35 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 01:48:35 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 18:48:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92767716"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Apr 2012 18:48:34 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 18:48:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 09:48:32 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQ
Date: Wed, 25 Apr 2012 01:48:31 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 9:40 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xen.org]
> >> Sent: Tuesday, April 24, 2012 5:17 PM
> >> To: Zhang, Yang Z
> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
> >> Fraser
> >> Subject: Re: [Xen-devel] lock in vhpet
> >>
> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> >> > > -----Original Message-----
> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
> >> > >
> >> > > Let me know if any of this helps
> >> > No, it not works.
> >>
> >> Do you mean that it doesn't help with the CPU overhead, or that it's
> >> broken in some other way?
> >>
> > It cannot help with the CPU overhead
> 
> Yang, is there any further information you can provide? A rough idea of where
> vcpus are spending time spinning for the p2m lock would be tremendously
> useful.
> 
I am doing the further investigation. Hope can get more useful information. 
But actually, the first cs introduced this issue is 24770. When win8 booting and if hpet is enabled, it will use hpet as the time source and there have lots of hpet access and EPT violation. In EPT violation handler, it call get_gfn_type_access to get the mfn. The cs 24770 introduces the gfn_lock for p2m lookups, and then the issue happens. After I removed the gfn_lock, the issue goes. But in latest xen, even I remove this lock, it still shows high cpu utilization.

yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 01:49:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 01:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrLS-0008J3-Bs; Wed, 25 Apr 2012 01:48:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMrLR-0008Iw-Cr
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 01:48:37 +0000
Received: from [85.158.138.51:24503] by server-7.bemta-3.messagelabs.com id
	D8/13-03078-4F7579F4; Wed, 25 Apr 2012 01:48:36 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335318515!23647254!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2417 invoked from network); 25 Apr 2012 01:48:35 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 01:48:35 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 18:48:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92767716"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Apr 2012 18:48:34 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 18:48:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 09:48:32 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQ
Date: Wed, 25 Apr 2012 01:48:31 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 9:40 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xen.org]
> >> Sent: Tuesday, April 24, 2012 5:17 PM
> >> To: Zhang, Yang Z
> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
> >> Fraser
> >> Subject: Re: [Xen-devel] lock in vhpet
> >>
> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> >> > > -----Original Message-----
> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
> >> > >
> >> > > Let me know if any of this helps
> >> > No, it not works.
> >>
> >> Do you mean that it doesn't help with the CPU overhead, or that it's
> >> broken in some other way?
> >>
> > It cannot help with the CPU overhead
> 
> Yang, is there any further information you can provide? A rough idea of where
> vcpus are spending time spinning for the p2m lock would be tremendously
> useful.
> 
I am doing the further investigation. Hope can get more useful information. 
But actually, the first cs introduced this issue is 24770. When win8 booting and if hpet is enabled, it will use hpet as the time source and there have lots of hpet access and EPT violation. In EPT violation handler, it call get_gfn_type_access to get the mfn. The cs 24770 introduces the gfn_lock for p2m lookups, and then the issue happens. After I removed the gfn_lock, the issue goes. But in latest xen, even I remove this lock, it still shows high cpu utilization.

yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:02:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:02:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrYI-0000L6-Mp; Wed, 25 Apr 2012 02:01:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMrYH-0000L1-3d
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:01:53 +0000
Received: from [85.158.143.35:62006] by server-3.bemta-4.messagelabs.com id
	6A/7B-05853-01B579F4; Wed, 25 Apr 2012 02:01:52 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335319311!12865402!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5OTg0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30635 invoked from network); 25 Apr 2012 02:01:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-21.messagelabs.com with SMTP;
	25 Apr 2012 02:01:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Apr 2012 19:01:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134959350"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 19:01:50 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 19:01:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 10:01:48 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNIkR6vbaZY0ZDxUaVSAYYvGL0fJaqyZOQ
Date: Wed, 25 Apr 2012 02:01:47 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3D545@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
In-Reply-To: <20374.60088.396314.671522@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

<RESEND: Porting from xen 4.1, patch on Xen unstable 25220>

libxl: passthrough: avoid passing through devices not owned by pciback

This patch makes sure the passthrough device belongs to pciback before allow them passthrough to the guest.  There are still many other checks missing.

xm terminates the guest startup process when this type of condition is found.  This patch just allows the guest to continue to boot but with no device passthrough.

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff -r a06e6cdeafe3 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Apr 16 13:05:28 2012 +0200
+++ b/tools/libxl/libxl_pci.c	Wed Apr 17 17:02:25 2013 +0800
@@ -664,6 +664,24 @@ int libxl_device_pci_add(libxl_ctx *ctx,
     return rc;
 }
 
+static int libxl_pcidev_assignable(libxl_ctx *ctx, libxl_device_pci *pcidev)
+{
+    libxl_device_pci *pcidevs;
+    int num, i;
+
+    pcidevs = libxl_device_pci_list_assignable(ctx, &num);
+    for (i = 0; i < num; i++) {
+        if (pcidevs[i].domain == pcidev->domain &&
+            pcidevs[i].bus == pcidev->bus &&
+            pcidevs[i].dev == pcidev->dev &&
+            pcidevs[i].func == pcidev->func)
+        {
+            return 1;
+        }
+    }
+    return 0;
+}
+
 int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -674,6 +692,13 @@ int libxl__device_pci_add(libxl__gc *gc,
 
     rc = libxl__device_pci_setdefault(gc, pcidev);
     if (rc) goto out;
+
+    if (!libxl_pcidev_assignable(ctx, pcidev)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable",
+                   pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {


Thanks,
-Xudong


> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Wednesday, April 25, 2012 2:03 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> > <Porting from xen 4.1, patch on Xen unstable 25138>
> 
> I'm afraid that 25138 was out of date even when you posted your
> revised patch, and it still doesn't apply.
> 
> Are you working with the staging tree ?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:02:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:02:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrYI-0000L6-Mp; Wed, 25 Apr 2012 02:01:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMrYH-0000L1-3d
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:01:53 +0000
Received: from [85.158.143.35:62006] by server-3.bemta-4.messagelabs.com id
	6A/7B-05853-01B579F4; Wed, 25 Apr 2012 02:01:52 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335319311!12865402!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjY5OTg0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30635 invoked from network); 25 Apr 2012 02:01:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-21.messagelabs.com with SMTP;
	25 Apr 2012 02:01:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Apr 2012 19:01:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134959350"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 19:01:50 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 19:01:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 10:01:48 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
	devices not owned by pciback
Thread-Index: AQHNIkR6vbaZY0ZDxUaVSAYYvGL0fJaqyZOQ
Date: Wed, 25 Apr 2012 02:01:47 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3D545@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
In-Reply-To: <20374.60088.396314.671522@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

<RESEND: Porting from xen 4.1, patch on Xen unstable 25220>

libxl: passthrough: avoid passing through devices not owned by pciback

This patch makes sure the passthrough device belongs to pciback before allow them passthrough to the guest.  There are still many other checks missing.

xm terminates the guest startup process when this type of condition is found.  This patch just allows the guest to continue to boot but with no device passthrough.

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff -r a06e6cdeafe3 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Apr 16 13:05:28 2012 +0200
+++ b/tools/libxl/libxl_pci.c	Wed Apr 17 17:02:25 2013 +0800
@@ -664,6 +664,24 @@ int libxl_device_pci_add(libxl_ctx *ctx,
     return rc;
 }
 
+static int libxl_pcidev_assignable(libxl_ctx *ctx, libxl_device_pci *pcidev)
+{
+    libxl_device_pci *pcidevs;
+    int num, i;
+
+    pcidevs = libxl_device_pci_list_assignable(ctx, &num);
+    for (i = 0; i < num; i++) {
+        if (pcidevs[i].domain == pcidev->domain &&
+            pcidevs[i].bus == pcidev->bus &&
+            pcidevs[i].dev == pcidev->dev &&
+            pcidevs[i].func == pcidev->func)
+        {
+            return 1;
+        }
+    }
+    return 0;
+}
+
 int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -674,6 +692,13 @@ int libxl__device_pci_add(libxl__gc *gc,
 
     rc = libxl__device_pci_setdefault(gc, pcidev);
     if (rc) goto out;
+
+    if (!libxl_pcidev_assignable(ctx, pcidev)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable",
+                   pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {


Thanks,
-Xudong


> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Wednesday, April 25, 2012 2:03 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Kay, Allen M
> Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
> devices not owned by pciback
> 
> Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing
> through devices not owned by pciback"):
> > <Porting from xen 4.1, patch on Xen unstable 25138>
> 
> I'm afraid that 25138 was out of date even when you posted your
> revised patch, and it still doesn't apply.
> 
> Are you working with the staging tree ?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:14:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrk8-0000Vy-0b; Wed, 25 Apr 2012 02:14:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMrk5-0000Vt-W6
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:14:06 +0000
Received: from [193.109.254.147:24066] by server-1.bemta-14.messagelabs.com id
	CA/3D-29372-DED579F4; Wed, 25 Apr 2012 02:14:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335320044!6206270!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26147 invoked from network); 25 Apr 2012 02:14:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 02:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,476,1330905600"; d="scan'208";a="12118292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 02:14:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 03:14:04 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMrk3-0002Hs-S4;
	Wed, 25 Apr 2012 02:14:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMrk3-0003TS-QK;
	Wed, 25 Apr 2012 03:14:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12744-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 03:14:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12744: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12744 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12744/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 12741
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 12741

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12741

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  99517f769cc8
baseline version:
 xen                  f5f1e6ef9782

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:14:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMrk8-0000Vy-0b; Wed, 25 Apr 2012 02:14:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMrk5-0000Vt-W6
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:14:06 +0000
Received: from [193.109.254.147:24066] by server-1.bemta-14.messagelabs.com id
	CA/3D-29372-DED579F4; Wed, 25 Apr 2012 02:14:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335320044!6206270!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26147 invoked from network); 25 Apr 2012 02:14:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 02:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,476,1330905600"; d="scan'208";a="12118292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 02:14:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 03:14:04 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMrk3-0002Hs-S4;
	Wed, 25 Apr 2012 02:14:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMrk3-0003TS-QK;
	Wed, 25 Apr 2012 03:14:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12744-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 03:14:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12744: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12744 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12744/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 12741
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 12741

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12741

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  99517f769cc8
baseline version:
 xen                  f5f1e6ef9782

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:31:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMs0w-0000iF-W2; Wed, 25 Apr 2012 02:31:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMs0v-0000iA-D2
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:31:29 +0000
Received: from [85.158.143.35:43515] by server-3.bemta-4.messagelabs.com id
	A4/E5-05853-002679F4; Wed, 25 Apr 2012 02:31:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335321087!11496322!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU0ODE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23952 invoked from network); 25 Apr 2012 02:31:27 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.207) by server-2.tower-21.messagelabs.com with SMTP;
	25 Apr 2012 02:31:27 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 92C0B5EC072;
	Tue, 24 Apr 2012 19:31:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ooe3ZnaobgZt7wOjGQRLQvmF8q8plv85KXBu8rNjgvRL
	zvr92TliqMEc/g2zYJK6jVeoamocAOUA0RkRNf7TJdo1uxmOmXl0Bf2hPnDHnLc0
	jOVX5BqXTJBNLOLbA941x7dhvK4goyI+6PpTH+7LUtUMsahWXUa0UwDIV3+VdlQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=OJ1NyiKlH+C1MOViKGNXE9F8Q5k=; b=l55KLNQQ
	ajA5cr02gmn/NhYUXrr3R39Sfhsjk3+3rmnd3G2YXqI6sS55PNXCKsRoofoDnXho
	T8CuKG9YVVzVlJcidG06zS4f1++t9EmveBz8hX+vEnlEWbUugS7AOeD/if5B4/dj
	H3acKzuelPb3jfLUabML3pgO9zN08bfbFVM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 3D3BC5EC014; 
	Tue, 24 Apr 2012 19:31:26 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 19:31:26 -0700
Message-ID: <dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 19:31:26 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>
>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Wednesday, April 25, 2012 9:40 AM
>> To: Zhang, Yang Z
>> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: RE: [Xen-devel] lock in vhpet
>>
>> >> -----Original Message-----
>> >> From: Tim Deegan [mailto:tim@xen.org]
>> >> Sent: Tuesday, April 24, 2012 5:17 PM
>> >> To: Zhang, Yang Z
>> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
>> >> Fraser
>> >> Subject: Re: [Xen-devel] lock in vhpet
>> >>
>> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> >> > > -----Original Message-----
>> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> >> > >
>> >> > > Let me know if any of this helps
>> >> > No, it not works.
>> >>
>> >> Do you mean that it doesn't help with the CPU overhead, or that it's
>> >> broken in some other way?
>> >>
>> > It cannot help with the CPU overhead
>>
>> Yang, is there any further information you can provide? A rough idea of
>> where
>> vcpus are spending time spinning for the p2m lock would be tremendously
>> useful.
>>
> I am doing the further investigation. Hope can get more useful
> information.

Thanks, looking forward to that.

> But actually, the first cs introduced this issue is 24770. When win8
> booting and if hpet is enabled, it will use hpet as the time source and
> there have lots of hpet access and EPT violation. In EPT violation
> handler, it call get_gfn_type_access to get the mfn. The cs 24770
> introduces the gfn_lock for p2m lookups, and then the issue happens. After
> I removed the gfn_lock, the issue goes. But in latest xen, even I remove
> this lock, it still shows high cpu utilization.
>

It would seem then that even the briefest lock-protected critical section
would cause this? In the mmio case, the p2m lock taken in the hap fault
handler is held during the actual lookup, and for a couple of branch
instructions afterwards.

In latest Xen, with lock removed for get_gfn, on which lock is time spent?

Thanks,
Andres

> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:31:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMs0w-0000iF-W2; Wed, 25 Apr 2012 02:31:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMs0v-0000iA-D2
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:31:29 +0000
Received: from [85.158.143.35:43515] by server-3.bemta-4.messagelabs.com id
	A4/E5-05853-002679F4; Wed, 25 Apr 2012 02:31:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335321087!11496322!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU0ODE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23952 invoked from network); 25 Apr 2012 02:31:27 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.207) by server-2.tower-21.messagelabs.com with SMTP;
	25 Apr 2012 02:31:27 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 92C0B5EC072;
	Tue, 24 Apr 2012 19:31:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ooe3ZnaobgZt7wOjGQRLQvmF8q8plv85KXBu8rNjgvRL
	zvr92TliqMEc/g2zYJK6jVeoamocAOUA0RkRNf7TJdo1uxmOmXl0Bf2hPnDHnLc0
	jOVX5BqXTJBNLOLbA941x7dhvK4goyI+6PpTH+7LUtUMsahWXUa0UwDIV3+VdlQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=OJ1NyiKlH+C1MOViKGNXE9F8Q5k=; b=l55KLNQQ
	ajA5cr02gmn/NhYUXrr3R39Sfhsjk3+3rmnd3G2YXqI6sS55PNXCKsRoofoDnXho
	T8CuKG9YVVzVlJcidG06zS4f1++t9EmveBz8hX+vEnlEWbUugS7AOeD/if5B4/dj
	H3acKzuelPb3jfLUabML3pgO9zN08bfbFVM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 3D3BC5EC014; 
	Tue, 24 Apr 2012 19:31:26 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 19:31:26 -0700
Message-ID: <dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 19:31:26 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>
>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Wednesday, April 25, 2012 9:40 AM
>> To: Zhang, Yang Z
>> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: RE: [Xen-devel] lock in vhpet
>>
>> >> -----Original Message-----
>> >> From: Tim Deegan [mailto:tim@xen.org]
>> >> Sent: Tuesday, April 24, 2012 5:17 PM
>> >> To: Zhang, Yang Z
>> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
>> >> Fraser
>> >> Subject: Re: [Xen-devel] lock in vhpet
>> >>
>> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> >> > > -----Original Message-----
>> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> >> > >
>> >> > > Let me know if any of this helps
>> >> > No, it not works.
>> >>
>> >> Do you mean that it doesn't help with the CPU overhead, or that it's
>> >> broken in some other way?
>> >>
>> > It cannot help with the CPU overhead
>>
>> Yang, is there any further information you can provide? A rough idea of
>> where
>> vcpus are spending time spinning for the p2m lock would be tremendously
>> useful.
>>
> I am doing the further investigation. Hope can get more useful
> information.

Thanks, looking forward to that.

> But actually, the first cs introduced this issue is 24770. When win8
> booting and if hpet is enabled, it will use hpet as the time source and
> there have lots of hpet access and EPT violation. In EPT violation
> handler, it call get_gfn_type_access to get the mfn. The cs 24770
> introduces the gfn_lock for p2m lookups, and then the issue happens. After
> I removed the gfn_lock, the issue goes. But in latest xen, even I remove
> this lock, it still shows high cpu utilization.
>

It would seem then that even the briefest lock-protected critical section
would cause this? In the mmio case, the p2m lock taken in the hap fault
handler is held during the actual lookup, and for a couple of branch
instructions afterwards.

In latest Xen, with lock removed for get_gfn, on which lock is time spent?

Thanks,
Andres

> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:37:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:37:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMs6j-0000pa-Q0; Wed, 25 Apr 2012 02:37:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMs6i-0000pU-8K
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:37:28 +0000
Received: from [85.158.138.51:19957] by server-12.bemta-3.messagelabs.com id
	0E/0A-29760-763679F4; Wed, 25 Apr 2012 02:37:27 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335321446!23555199!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13173 invoked from network); 25 Apr 2012 02:37:26 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 02:37:26 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 19:37:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134970659"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 19:37:22 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 19:37:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 10:36:49 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoA==
Date: Wed, 25 Apr 2012 02:36:49 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 10:31 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >
> >> -----Original Message-----
> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> Sent: Wednesday, April 25, 2012 9:40 AM
> >> To: Zhang, Yang Z
> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> >> Subject: RE: [Xen-devel] lock in vhpet
> >>
> >> >> -----Original Message-----
> >> >> From: Tim Deegan [mailto:tim@xen.org]
> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
> >> >> To: Zhang, Yang Z
> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
> >> >> Fraser
> >> >> Subject: Re: [Xen-devel] lock in vhpet
> >> >>
> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> >> >> > > -----Original Message-----
> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
> >> >> > >
> >> >> > > Let me know if any of this helps
> >> >> > No, it not works.
> >> >>
> >> >> Do you mean that it doesn't help with the CPU overhead, or that
> >> >> it's broken in some other way?
> >> >>
> >> > It cannot help with the CPU overhead
> >>
> >> Yang, is there any further information you can provide? A rough idea
> >> of where vcpus are spending time spinning for the p2m lock would be
> >> tremendously useful.
> >>
> > I am doing the further investigation. Hope can get more useful
> > information.
> 
> Thanks, looking forward to that.
> 
> > But actually, the first cs introduced this issue is 24770. When win8
> > booting and if hpet is enabled, it will use hpet as the time source
> > and there have lots of hpet access and EPT violation. In EPT violation
> > handler, it call get_gfn_type_access to get the mfn. The cs 24770
> > introduces the gfn_lock for p2m lookups, and then the issue happens.
> > After I removed the gfn_lock, the issue goes. But in latest xen, even
> > I remove this lock, it still shows high cpu utilization.
> >
> 
> It would seem then that even the briefest lock-protected critical section would
> cause this? In the mmio case, the p2m lock taken in the hap fault handler is
> held during the actual lookup, and for a couple of branch instructions
> afterwards.
> 
> In latest Xen, with lock removed for get_gfn, on which lock is time spent?
Still the p2m_lock.

yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:37:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:37:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMs6j-0000pa-Q0; Wed, 25 Apr 2012 02:37:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMs6i-0000pU-8K
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:37:28 +0000
Received: from [85.158.138.51:19957] by server-12.bemta-3.messagelabs.com id
	0E/0A-29760-763679F4; Wed, 25 Apr 2012 02:37:27 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335321446!23555199!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13173 invoked from network); 25 Apr 2012 02:37:26 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 02:37:26 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 19:37:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134970659"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 19:37:22 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 19:37:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 10:36:49 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoA==
Date: Wed, 25 Apr 2012 02:36:49 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 10:31 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >
> >> -----Original Message-----
> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> Sent: Wednesday, April 25, 2012 9:40 AM
> >> To: Zhang, Yang Z
> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> >> Subject: RE: [Xen-devel] lock in vhpet
> >>
> >> >> -----Original Message-----
> >> >> From: Tim Deegan [mailto:tim@xen.org]
> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
> >> >> To: Zhang, Yang Z
> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
> >> >> Fraser
> >> >> Subject: Re: [Xen-devel] lock in vhpet
> >> >>
> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> >> >> > > -----Original Message-----
> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
> >> >> > >
> >> >> > > Let me know if any of this helps
> >> >> > No, it not works.
> >> >>
> >> >> Do you mean that it doesn't help with the CPU overhead, or that
> >> >> it's broken in some other way?
> >> >>
> >> > It cannot help with the CPU overhead
> >>
> >> Yang, is there any further information you can provide? A rough idea
> >> of where vcpus are spending time spinning for the p2m lock would be
> >> tremendously useful.
> >>
> > I am doing the further investigation. Hope can get more useful
> > information.
> 
> Thanks, looking forward to that.
> 
> > But actually, the first cs introduced this issue is 24770. When win8
> > booting and if hpet is enabled, it will use hpet as the time source
> > and there have lots of hpet access and EPT violation. In EPT violation
> > handler, it call get_gfn_type_access to get the mfn. The cs 24770
> > introduces the gfn_lock for p2m lookups, and then the issue happens.
> > After I removed the gfn_lock, the issue goes. But in latest xen, even
> > I remove this lock, it still shows high cpu utilization.
> >
> 
> It would seem then that even the briefest lock-protected critical section would
> cause this? In the mmio case, the p2m lock taken in the hap fault handler is
> held during the actual lookup, and for a couple of branch instructions
> afterwards.
> 
> In latest Xen, with lock removed for get_gfn, on which lock is time spent?
Still the p2m_lock.

yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMsBG-0000yi-GN; Wed, 25 Apr 2012 02:42:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMsBE-0000ya-8g
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:42:08 +0000
Received: from [85.158.138.51:37101] by server-3.bemta-3.messagelabs.com id
	EC/CC-04048-F74679F4; Wed, 25 Apr 2012 02:42:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335321726!23669222!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4NzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3894 invoked from network); 25 Apr 2012 02:42:06 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 02:42:06 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 3C523714070;
	Tue, 24 Apr 2012 19:42:05 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Kme5ieCL9ebw4iYZbQkp8eGwzMgYaJ8BeMvUclovJgeO
	g9fquY1jBLE2fOJr/bONTa4fvKm7jgy1sITFwdMRkX14nIeV9ygZe7Dkklx7kYRM
	63DBE+0uNr8JnP2aZ+kzK6PisHdp6KfqfeBoQKUSOs8HX0olRnwJKn3KS4B8lWM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=waen5lpACX2rwS3IRAyN1NgXays=; b=qNC8/JXk
	breGuKyYd3XFtoIyTbR8GMcx6nk0NvcPrIkrkx4gKfv9r2+75FXCSdeTrr6RwpON
	XPiX8mrVdL9jHgO3XM+M4ix5COewIM1zohX/8HNydo10V9ERz8pe/bHhpeo3RDCk
	5HFAydL+pncZFxNEcnFMc1gaEfIHkfEksHk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id E7BC771406F; 
	Tue, 24 Apr 2012 19:42:04 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 19:42:05 -0700
Message-ID: <b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 19:42:05 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Wednesday, April 25, 2012 10:31 AM
>> To: Zhang, Yang Z
>> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: RE: [Xen-devel] lock in vhpet
>>
>> >
>> >> -----Original Message-----
>> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> Sent: Wednesday, April 25, 2012 9:40 AM
>> >> To: Zhang, Yang Z
>> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> >> Subject: RE: [Xen-devel] lock in vhpet
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Tim Deegan [mailto:tim@xen.org]
>> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
>> >> >> To: Zhang, Yang Z
>> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
>> >> >> Fraser
>> >> >> Subject: Re: [Xen-devel] lock in vhpet
>> >> >>
>> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> >> >> > > -----Original Message-----
>> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> >> >> > >
>> >> >> > > Let me know if any of this helps
>> >> >> > No, it not works.
>> >> >>
>> >> >> Do you mean that it doesn't help with the CPU overhead, or that
>> >> >> it's broken in some other way?
>> >> >>
>> >> > It cannot help with the CPU overhead
>> >>
>> >> Yang, is there any further information you can provide? A rough idea
>> >> of where vcpus are spending time spinning for the p2m lock would be
>> >> tremendously useful.
>> >>
>> > I am doing the further investigation. Hope can get more useful
>> > information.
>>
>> Thanks, looking forward to that.
>>
>> > But actually, the first cs introduced this issue is 24770. When win8
>> > booting and if hpet is enabled, it will use hpet as the time source
>> > and there have lots of hpet access and EPT violation. In EPT violation
>> > handler, it call get_gfn_type_access to get the mfn. The cs 24770
>> > introduces the gfn_lock for p2m lookups, and then the issue happens.
>> > After I removed the gfn_lock, the issue goes. But in latest xen, even
>> > I remove this lock, it still shows high cpu utilization.
>> >
>>
>> It would seem then that even the briefest lock-protected critical
>> section would
>> cause this? In the mmio case, the p2m lock taken in the hap fault
>> handler is
>> held during the actual lookup, and for a couple of branch instructions
>> afterwards.
>>
>> In latest Xen, with lock removed for get_gfn, on which lock is time
>> spent?
> Still the p2m_lock.

How are you removing the lock from get_gfn?

The p2m lock is taken on a few specific code paths outside of get_gfn
(change type of an entry, add a new p2m entry, setup and teardown), and
I'm surprised any of those code paths is being used by the hpet mmio
handler.

Andres

>
> yang
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMsBG-0000yi-GN; Wed, 25 Apr 2012 02:42:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMsBE-0000ya-8g
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 02:42:08 +0000
Received: from [85.158.138.51:37101] by server-3.bemta-3.messagelabs.com id
	EC/CC-04048-F74679F4; Wed, 25 Apr 2012 02:42:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335321726!23669222!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4NzIw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3894 invoked from network); 25 Apr 2012 02:42:06 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 02:42:06 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 3C523714070;
	Tue, 24 Apr 2012 19:42:05 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Kme5ieCL9ebw4iYZbQkp8eGwzMgYaJ8BeMvUclovJgeO
	g9fquY1jBLE2fOJr/bONTa4fvKm7jgy1sITFwdMRkX14nIeV9ygZe7Dkklx7kYRM
	63DBE+0uNr8JnP2aZ+kzK6PisHdp6KfqfeBoQKUSOs8HX0olRnwJKn3KS4B8lWM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=waen5lpACX2rwS3IRAyN1NgXays=; b=qNC8/JXk
	breGuKyYd3XFtoIyTbR8GMcx6nk0NvcPrIkrkx4gKfv9r2+75FXCSdeTrr6RwpON
	XPiX8mrVdL9jHgO3XM+M4ix5COewIM1zohX/8HNydo10V9ERz8pe/bHhpeo3RDCk
	5HFAydL+pncZFxNEcnFMc1gaEfIHkfEksHk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id E7BC771406F; 
	Tue, 24 Apr 2012 19:42:04 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 19:42:05 -0700
Message-ID: <b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 19:42:05 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Wednesday, April 25, 2012 10:31 AM
>> To: Zhang, Yang Z
>> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: RE: [Xen-devel] lock in vhpet
>>
>> >
>> >> -----Original Message-----
>> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> Sent: Wednesday, April 25, 2012 9:40 AM
>> >> To: Zhang, Yang Z
>> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> >> Subject: RE: [Xen-devel] lock in vhpet
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Tim Deegan [mailto:tim@xen.org]
>> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
>> >> >> To: Zhang, Yang Z
>> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir
>> >> >> Fraser
>> >> >> Subject: Re: [Xen-devel] lock in vhpet
>> >> >>
>> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> >> >> > > -----Original Message-----
>> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> >> >> > >
>> >> >> > > Let me know if any of this helps
>> >> >> > No, it not works.
>> >> >>
>> >> >> Do you mean that it doesn't help with the CPU overhead, or that
>> >> >> it's broken in some other way?
>> >> >>
>> >> > It cannot help with the CPU overhead
>> >>
>> >> Yang, is there any further information you can provide? A rough idea
>> >> of where vcpus are spending time spinning for the p2m lock would be
>> >> tremendously useful.
>> >>
>> > I am doing the further investigation. Hope can get more useful
>> > information.
>>
>> Thanks, looking forward to that.
>>
>> > But actually, the first cs introduced this issue is 24770. When win8
>> > booting and if hpet is enabled, it will use hpet as the time source
>> > and there have lots of hpet access and EPT violation. In EPT violation
>> > handler, it call get_gfn_type_access to get the mfn. The cs 24770
>> > introduces the gfn_lock for p2m lookups, and then the issue happens.
>> > After I removed the gfn_lock, the issue goes. But in latest xen, even
>> > I remove this lock, it still shows high cpu utilization.
>> >
>>
>> It would seem then that even the briefest lock-protected critical
>> section would
>> cause this? In the mmio case, the p2m lock taken in the hap fault
>> handler is
>> held during the actual lookup, and for a couple of branch instructions
>> afterwards.
>>
>> In latest Xen, with lock removed for get_gfn, on which lock is time
>> spent?
> Still the p2m_lock.

How are you removing the lock from get_gfn?

The p2m lock is taken on a few specific code paths outside of get_gfn
(change type of an entry, add a new p2m entry, setup and teardown), and
I'm surprised any of those code paths is being used by the hpet mmio
handler.

Andres

>
> yang
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:47:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMsFq-00018O-7o; Wed, 25 Apr 2012 02:46:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMsFo-00018H-Vr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 02:46:53 +0000
Received: from [85.158.139.83:53222] by server-6.bemta-5.messagelabs.com id
	0A/3F-13222-C95679F4; Wed, 25 Apr 2012 02:46:52 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335322010!21471507!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3753 invoked from network); 25 Apr 2012 02:46:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 02:46:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 19:46:49 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134974041"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 19:46:48 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 19:46:48 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 10:46:44 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
Thread-Index: AQHNIeZj21Ce+YV9d0qRyKcsQnS8w5aqzN/A
Date: Wed, 25 Apr 2012 02:46:44 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
	<4F96690D020000780007F810@nat28.tlf.novell.com>
In-Reply-To: <4F96690D020000780007F810@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, April 24, 2012 2:49 PM
> To: Hao, Xudong
> Cc: xen-devel; konrad.wilk@oracle.com
> Subject: RE: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
> pciback
> 
> >>> On 24.04.12 at 04:49, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> >> > +	/* set default value */
> >> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> >> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
> value */
> >> > +
> >> > +	/* Enable LTR and OBFF before do device assignment */
> >> > +	/* LTR(Latency tolerance reporting) allows devices to send messages
> to the
> >> > +	 * root complex indicating their latency tolerance for snooped &
> unsnooped
> >> > +	 * memory transactions.
> >> > +	 */
> >> > +	pci_enable_ltr(dev);
> >> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
> >>
> >> Wouldn't the guest kernel be able to do this itself, as it's just playing
> > with bits in
> >> the PCIE capability structure, or the LTR extended one?
> >
> > There are two reasons I want to enable ltr/obff in host but not in guest.
> > 1) ltr/obff is not only for one device, enabling them need to enable the
> > whole pci bus, include root port, upstream and downstream port. It's
> complex
> > to let guest enable the whole path.
> 
> Then it would still be more clean to extend the pciif, allowing the guest
> to request enabling, or even better snoop the writes to the capabilities/
> LTR structures in pciback.
> 

Qemu only emulate the device which is assigned to guest, but it does not emulate the physic device's whole bus path. Seems allowing guest request enabling looks reasonable, but I think it's only applicable for "per device feature(that unnecessary to enable the whole pci path)".  

> > 2) LTR/obff are PCIE device capabilities2, current qemu did not support
> > exposing PCIe capabilities2 to guest.
> 
> Mostly the same here, except that adding support for these capabilities
> is obviously going to be needed.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 02:47:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 02:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMsFq-00018O-7o; Wed, 25 Apr 2012 02:46:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SMsFo-00018H-Vr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 02:46:53 +0000
Received: from [85.158.139.83:53222] by server-6.bemta-5.messagelabs.com id
	0A/3F-13222-C95679F4; Wed, 25 Apr 2012 02:46:52 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335322010!21471507!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3753 invoked from network); 25 Apr 2012 02:46:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 02:46:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 19:46:49 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="134974041"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 24 Apr 2012 19:46:48 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 19:46:48 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 10:46:44 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
Thread-Index: AQHNIeZj21Ce+YV9d0qRyKcsQnS8w5aqzN/A
Date: Wed, 25 Apr 2012 02:46:44 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
	<4F96690D020000780007F810@nat28.tlf.novell.com>
In-Reply-To: <4F96690D020000780007F810@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, April 24, 2012 2:49 PM
> To: Hao, Xudong
> Cc: xen-devel; konrad.wilk@oracle.com
> Subject: RE: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
> pciback
> 
> >>> On 24.04.12 at 04:49, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> >> > +	/* set default value */
> >> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> >> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
> value */
> >> > +
> >> > +	/* Enable LTR and OBFF before do device assignment */
> >> > +	/* LTR(Latency tolerance reporting) allows devices to send messages
> to the
> >> > +	 * root complex indicating their latency tolerance for snooped &
> unsnooped
> >> > +	 * memory transactions.
> >> > +	 */
> >> > +	pci_enable_ltr(dev);
> >> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
> >>
> >> Wouldn't the guest kernel be able to do this itself, as it's just playing
> > with bits in
> >> the PCIE capability structure, or the LTR extended one?
> >
> > There are two reasons I want to enable ltr/obff in host but not in guest.
> > 1) ltr/obff is not only for one device, enabling them need to enable the
> > whole pci bus, include root port, upstream and downstream port. It's
> complex
> > to let guest enable the whole path.
> 
> Then it would still be more clean to extend the pciif, allowing the guest
> to request enabling, or even better snoop the writes to the capabilities/
> LTR structures in pciback.
> 

Qemu only emulate the device which is assigned to guest, but it does not emulate the physic device's whole bus path. Seems allowing guest request enabling looks reasonable, but I think it's only applicable for "per device feature(that unnecessary to enable the whole pci path)".  

> > 2) LTR/obff are PCIE device capabilities2, current qemu did not support
> > exposing PCIe capabilities2 to guest.
> 
> Mostly the same here, except that adding support for these capabilities
> is obviously going to be needed.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 03:12:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 03:12:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMseX-0001N1-FQ; Wed, 25 Apr 2012 03:12:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMseW-0001Mw-Dp
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 03:12:24 +0000
Received: from [85.158.143.99:52096] by server-1.bemta-4.messagelabs.com id
	5E/CB-20925-79B679F4; Wed, 25 Apr 2012 03:12:23 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335323541!19859969!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 25 Apr 2012 03:12:22 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-216.messagelabs.com with SMTP;
	25 Apr 2012 03:12:22 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 20:12:20 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92785993"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Apr 2012 20:12:20 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 20:12:18 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 11:12:16 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoAARKmWA//95SRA=
Date: Wed, 25 Apr 2012 03:12:16 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 10:42 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >> -----Original Message-----
> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> Sent: Wednesday, April 25, 2012 10:31 AM
> >> To: Zhang, Yang Z
> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> >> Subject: RE: [Xen-devel] lock in vhpet
> >>
> >> >
> >> >> -----Original Message-----
> >> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> >> Sent: Wednesday, April 25, 2012 9:40 AM
> >> >> To: Zhang, Yang Z
> >> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> >> >> Subject: RE: [Xen-devel] lock in vhpet
> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Tim Deegan [mailto:tim@xen.org]
> >> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
> >> >> >> To: Zhang, Yang Z
> >> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com;
> >> >> >> Keir Fraser
> >> >> >> Subject: Re: [Xen-devel] lock in vhpet
> >> >> >>
> >> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> >> >> >> > > -----Original Message-----
> >> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
> >> >> >> > >
> >> >> >> > > Let me know if any of this helps
> >> >> >> > No, it not works.
> >> >> >>
> >> >> >> Do you mean that it doesn't help with the CPU overhead, or that
> >> >> >> it's broken in some other way?
> >> >> >>
> >> >> > It cannot help with the CPU overhead
> >> >>
> >> >> Yang, is there any further information you can provide? A rough
> >> >> idea of where vcpus are spending time spinning for the p2m lock
> >> >> would be tremendously useful.
> >> >>
> >> > I am doing the further investigation. Hope can get more useful
> >> > information.
> >>
> >> Thanks, looking forward to that.
> >>
> >> > But actually, the first cs introduced this issue is 24770. When
> >> > win8 booting and if hpet is enabled, it will use hpet as the time
> >> > source and there have lots of hpet access and EPT violation. In EPT
> >> > violation handler, it call get_gfn_type_access to get the mfn. The
> >> > cs 24770 introduces the gfn_lock for p2m lookups, and then the issue
> happens.
> >> > After I removed the gfn_lock, the issue goes. But in latest xen,
> >> > even I remove this lock, it still shows high cpu utilization.
> >> >
> >>
> >> It would seem then that even the briefest lock-protected critical
> >> section would cause this? In the mmio case, the p2m lock taken in the
> >> hap fault handler is held during the actual lookup, and for a couple
> >> of branch instructions afterwards.
> >>
> >> In latest Xen, with lock removed for get_gfn, on which lock is time
> >> spent?
> > Still the p2m_lock.
> 
> How are you removing the lock from get_gfn?
>
> The p2m lock is taken on a few specific code paths outside of get_gfn (change
> type of an entry, add a new p2m entry, setup and teardown), and I'm surprised
> any of those code paths is being used by the hpet mmio handler.

Sorry, what I said maybe not accurate. In latest xen, I use a workaround way to skip calling get_gfn_type_access in hvm_hap_nested_page_fault(). So the p2m_lock is still existing. 
Now, I found the contention of p2m_lock is coming from __hvm_copy. In mmio handler, it has some code paths to call it(hvm_fetch_from_guest_virt_nofault(),  hvm_copy_from_guest_virt()). When lots of mmio access happened, the contention is very obviously.

yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 03:12:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 03:12:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMseX-0001N1-FQ; Wed, 25 Apr 2012 03:12:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMseW-0001Mw-Dp
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 03:12:24 +0000
Received: from [85.158.143.99:52096] by server-1.bemta-4.messagelabs.com id
	5E/CB-20925-79B679F4; Wed, 25 Apr 2012 03:12:23 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335323541!19859969!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 25 Apr 2012 03:12:22 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-216.messagelabs.com with SMTP;
	25 Apr 2012 03:12:22 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 20:12:20 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92785993"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Apr 2012 20:12:20 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 20:12:18 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 11:12:16 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoAARKmWA//95SRA=
Date: Wed, 25 Apr 2012 03:12:16 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 10:42 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >> -----Original Message-----
> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> Sent: Wednesday, April 25, 2012 10:31 AM
> >> To: Zhang, Yang Z
> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> >> Subject: RE: [Xen-devel] lock in vhpet
> >>
> >> >
> >> >> -----Original Message-----
> >> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> >> Sent: Wednesday, April 25, 2012 9:40 AM
> >> >> To: Zhang, Yang Z
> >> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
> >> >> Subject: RE: [Xen-devel] lock in vhpet
> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Tim Deegan [mailto:tim@xen.org]
> >> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
> >> >> >> To: Zhang, Yang Z
> >> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com;
> >> >> >> Keir Fraser
> >> >> >> Subject: Re: [Xen-devel] lock in vhpet
> >> >> >>
> >> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
> >> >> >> > > -----Original Message-----
> >> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> >> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
> >> >> >> > >
> >> >> >> > > Let me know if any of this helps
> >> >> >> > No, it not works.
> >> >> >>
> >> >> >> Do you mean that it doesn't help with the CPU overhead, or that
> >> >> >> it's broken in some other way?
> >> >> >>
> >> >> > It cannot help with the CPU overhead
> >> >>
> >> >> Yang, is there any further information you can provide? A rough
> >> >> idea of where vcpus are spending time spinning for the p2m lock
> >> >> would be tremendously useful.
> >> >>
> >> > I am doing the further investigation. Hope can get more useful
> >> > information.
> >>
> >> Thanks, looking forward to that.
> >>
> >> > But actually, the first cs introduced this issue is 24770. When
> >> > win8 booting and if hpet is enabled, it will use hpet as the time
> >> > source and there have lots of hpet access and EPT violation. In EPT
> >> > violation handler, it call get_gfn_type_access to get the mfn. The
> >> > cs 24770 introduces the gfn_lock for p2m lookups, and then the issue
> happens.
> >> > After I removed the gfn_lock, the issue goes. But in latest xen,
> >> > even I remove this lock, it still shows high cpu utilization.
> >> >
> >>
> >> It would seem then that even the briefest lock-protected critical
> >> section would cause this? In the mmio case, the p2m lock taken in the
> >> hap fault handler is held during the actual lookup, and for a couple
> >> of branch instructions afterwards.
> >>
> >> In latest Xen, with lock removed for get_gfn, on which lock is time
> >> spent?
> > Still the p2m_lock.
> 
> How are you removing the lock from get_gfn?
>
> The p2m lock is taken on a few specific code paths outside of get_gfn (change
> type of an entry, add a new p2m entry, setup and teardown), and I'm surprised
> any of those code paths is being used by the hpet mmio handler.

Sorry, what I said maybe not accurate. In latest xen, I use a workaround way to skip calling get_gfn_type_access in hvm_hap_nested_page_fault(). So the p2m_lock is still existing. 
Now, I found the contention of p2m_lock is coming from __hvm_copy. In mmio handler, it has some code paths to call it(hvm_fetch_from_guest_virt_nofault(),  hvm_copy_from_guest_virt()). When lots of mmio access happened, the contention is very obviously.

yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 03:35:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 03:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMszu-0001bL-QN; Wed, 25 Apr 2012 03:34:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMszs-0001bG-Lc
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 03:34:28 +0000
Received: from [85.158.139.83:18545] by server-8.bemta-5.messagelabs.com id
	5E/E8-26964-3C0779F4; Wed, 25 Apr 2012 03:34:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335324865!25271709!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32620 invoked from network); 25 Apr 2012 03:34:26 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 03:34:26 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id CD16B714083;
	Tue, 24 Apr 2012 20:34:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AMYx0lr7euFfDuX6QtnZZnKJX2F6U9EOdAppt/Xp/0P3
	DsTaeq/mfT84iBwUF3wgQ5gMzpxau/KyDE8ytv7CviyrJ5mgQLLWTjjWj1Fy8mm8
	oHneUxrExYqHkCPLyr5nUzMSRwmtbRP84u3ILqfK+0MT330meY1t1ggmGCVjWTM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Ny6hkAdQgeQGExhnJ8Tx8B28YSM=; b=ZViYsC/m
	fleLgjkS5b9fRSIyhVmSKxGLeWw4rVJb10wYXQELSsFeWiOzayqGS12uGByFk9l3
	raoBq4NBSMTrJb6Lflk4ShrPb9ZsQxhyUkQvfiZB2Yf6En4gt/MYqWgRh8QFpYwZ
	7y9QVS9ROoxUoglltmL458QLDWVsGwvMYBo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1828C71406F; 
	Tue, 24 Apr 2012 20:34:24 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 20:34:23 -0700
Message-ID: <a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 20:34:23 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Wednesday, April 25, 2012 10:42 AM
>> To: Zhang, Yang Z
>> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: RE: [Xen-devel] lock in vhpet
>>
>> >> -----Original Message-----
>> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> Sent: Wednesday, April 25, 2012 10:31 AM
>> >> To: Zhang, Yang Z
>> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> >> Subject: RE: [Xen-devel] lock in vhpet
>> >>
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> >> Sent: Wednesday, April 25, 2012 9:40 AM
>> >> >> To: Zhang, Yang Z
>> >> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> >> >> Subject: RE: [Xen-devel] lock in vhpet
>> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: Tim Deegan [mailto:tim@xen.org]
>> >> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
>> >> >> >> To: Zhang, Yang Z
>> >> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com;
>> >> >> >> Keir Fraser
>> >> >> >> Subject: Re: [Xen-devel] lock in vhpet
>> >> >> >>
>> >> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> >> >> >> > > -----Original Message-----
>> >> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> >> >> >> > >
>> >> >> >> > > Let me know if any of this helps
>> >> >> >> > No, it not works.
>> >> >> >>
>> >> >> >> Do you mean that it doesn't help with the CPU overhead, or that
>> >> >> >> it's broken in some other way?
>> >> >> >>
>> >> >> > It cannot help with the CPU overhead
>> >> >>
>> >> >> Yang, is there any further information you can provide? A rough
>> >> >> idea of where vcpus are spending time spinning for the p2m lock
>> >> >> would be tremendously useful.
>> >> >>
>> >> > I am doing the further investigation. Hope can get more useful
>> >> > information.
>> >>
>> >> Thanks, looking forward to that.
>> >>
>> >> > But actually, the first cs introduced this issue is 24770. When
>> >> > win8 booting and if hpet is enabled, it will use hpet as the time
>> >> > source and there have lots of hpet access and EPT violation. In EPT
>> >> > violation handler, it call get_gfn_type_access to get the mfn. The
>> >> > cs 24770 introduces the gfn_lock for p2m lookups, and then the
>> issue
>> happens.
>> >> > After I removed the gfn_lock, the issue goes. But in latest xen,
>> >> > even I remove this lock, it still shows high cpu utilization.
>> >> >
>> >>
>> >> It would seem then that even the briefest lock-protected critical
>> >> section would cause this? In the mmio case, the p2m lock taken in the
>> >> hap fault handler is held during the actual lookup, and for a couple
>> >> of branch instructions afterwards.
>> >>
>> >> In latest Xen, with lock removed for get_gfn, on which lock is time
>> >> spent?
>> > Still the p2m_lock.
>>
>> How are you removing the lock from get_gfn?
>>
>> The p2m lock is taken on a few specific code paths outside of get_gfn
>> (change
>> type of an entry, add a new p2m entry, setup and teardown), and I'm
>> surprised
>> any of those code paths is being used by the hpet mmio handler.
>
> Sorry, what I said maybe not accurate. In latest xen, I use a workaround
> way to skip calling get_gfn_type_access in hvm_hap_nested_page_fault(). So
> the p2m_lock is still existing.
> Now, I found the contention of p2m_lock is coming from __hvm_copy. In mmio
> handler, it has some code paths to call
> it(hvm_fetch_from_guest_virt_nofault(),  hvm_copy_from_guest_virt()). When
> lots of mmio access happened, the contention is very obviously.

Thanks. Can you please try this:
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01861.html

in conjunction with the patch below?
Andres

diff -r 7a7443e80b99 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2383,6 +2383,8 @@ static enum hvm_copy_result __hvm_copy(

     while ( todo > 0 )
     {
+        struct page_info *pg;
+
         count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);

         if ( flags & HVMCOPY_virt )
@@ -2427,7 +2429,11 @@ static enum hvm_copy_result __hvm_copy(
             put_gfn(curr->domain, gfn);
             return HVMCOPY_bad_gfn_to_mfn;
         }
+
         ASSERT(mfn_valid(mfn));
+        pg = mfn_to_page(mfn);
+        ASSERT(get_page(pg, curr->domain));
+        put_gfn(curr->domain, gfn);

         p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);

@@ -2457,7 +2463,7 @@ static enum hvm_copy_result __hvm_copy(
         addr += count;
         buf  += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(pg);
     }

     return HVMCOPY_okay;

>
> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 03:35:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 03:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMszu-0001bL-QN; Wed, 25 Apr 2012 03:34:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SMszs-0001bG-Lc
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 03:34:28 +0000
Received: from [85.158.139.83:18545] by server-8.bemta-5.messagelabs.com id
	5E/E8-26964-3C0779F4; Wed, 25 Apr 2012 03:34:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335324865!25271709!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTgyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32620 invoked from network); 25 Apr 2012 03:34:26 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-182.messagelabs.com with SMTP;
	25 Apr 2012 03:34:26 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id CD16B714083;
	Tue, 24 Apr 2012 20:34:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AMYx0lr7euFfDuX6QtnZZnKJX2F6U9EOdAppt/Xp/0P3
	DsTaeq/mfT84iBwUF3wgQ5gMzpxau/KyDE8ytv7CviyrJ5mgQLLWTjjWj1Fy8mm8
	oHneUxrExYqHkCPLyr5nUzMSRwmtbRP84u3ILqfK+0MT330meY1t1ggmGCVjWTM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Ny6hkAdQgeQGExhnJ8Tx8B28YSM=; b=ZViYsC/m
	fleLgjkS5b9fRSIyhVmSKxGLeWw4rVJb10wYXQELSsFeWiOzayqGS12uGByFk9l3
	raoBq4NBSMTrJb6Lflk4ShrPb9ZsQxhyUkQvfiZB2Yf6En4gt/MYqWgRh8QFpYwZ
	7y9QVS9ROoxUoglltmL458QLDWVsGwvMYBo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1828C71406F; 
	Tue, 24 Apr 2012 20:34:24 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Apr 2012 20:34:23 -0700
Message-ID: <a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 24 Apr 2012 20:34:23 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Wednesday, April 25, 2012 10:42 AM
>> To: Zhang, Yang Z
>> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> Subject: RE: [Xen-devel] lock in vhpet
>>
>> >> -----Original Message-----
>> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> Sent: Wednesday, April 25, 2012 10:31 AM
>> >> To: Zhang, Yang Z
>> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> >> Subject: RE: [Xen-devel] lock in vhpet
>> >>
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> >> Sent: Wednesday, April 25, 2012 9:40 AM
>> >> >> To: Zhang, Yang Z
>> >> >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser
>> >> >> Subject: RE: [Xen-devel] lock in vhpet
>> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: Tim Deegan [mailto:tim@xen.org]
>> >> >> >> Sent: Tuesday, April 24, 2012 5:17 PM
>> >> >> >> To: Zhang, Yang Z
>> >> >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com;
>> >> >> >> Keir Fraser
>> >> >> >> Subject: Re: [Xen-devel] lock in vhpet
>> >> >> >>
>> >> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote:
>> >> >> >> > > -----Original Message-----
>> >> >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> >> >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM
>> >> >> >> > >
>> >> >> >> > > Let me know if any of this helps
>> >> >> >> > No, it not works.
>> >> >> >>
>> >> >> >> Do you mean that it doesn't help with the CPU overhead, or that
>> >> >> >> it's broken in some other way?
>> >> >> >>
>> >> >> > It cannot help with the CPU overhead
>> >> >>
>> >> >> Yang, is there any further information you can provide? A rough
>> >> >> idea of where vcpus are spending time spinning for the p2m lock
>> >> >> would be tremendously useful.
>> >> >>
>> >> > I am doing the further investigation. Hope can get more useful
>> >> > information.
>> >>
>> >> Thanks, looking forward to that.
>> >>
>> >> > But actually, the first cs introduced this issue is 24770. When
>> >> > win8 booting and if hpet is enabled, it will use hpet as the time
>> >> > source and there have lots of hpet access and EPT violation. In EPT
>> >> > violation handler, it call get_gfn_type_access to get the mfn. The
>> >> > cs 24770 introduces the gfn_lock for p2m lookups, and then the
>> issue
>> happens.
>> >> > After I removed the gfn_lock, the issue goes. But in latest xen,
>> >> > even I remove this lock, it still shows high cpu utilization.
>> >> >
>> >>
>> >> It would seem then that even the briefest lock-protected critical
>> >> section would cause this? In the mmio case, the p2m lock taken in the
>> >> hap fault handler is held during the actual lookup, and for a couple
>> >> of branch instructions afterwards.
>> >>
>> >> In latest Xen, with lock removed for get_gfn, on which lock is time
>> >> spent?
>> > Still the p2m_lock.
>>
>> How are you removing the lock from get_gfn?
>>
>> The p2m lock is taken on a few specific code paths outside of get_gfn
>> (change
>> type of an entry, add a new p2m entry, setup and teardown), and I'm
>> surprised
>> any of those code paths is being used by the hpet mmio handler.
>
> Sorry, what I said maybe not accurate. In latest xen, I use a workaround
> way to skip calling get_gfn_type_access in hvm_hap_nested_page_fault(). So
> the p2m_lock is still existing.
> Now, I found the contention of p2m_lock is coming from __hvm_copy. In mmio
> handler, it has some code paths to call
> it(hvm_fetch_from_guest_virt_nofault(),  hvm_copy_from_guest_virt()). When
> lots of mmio access happened, the contention is very obviously.

Thanks. Can you please try this:
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01861.html

in conjunction with the patch below?
Andres

diff -r 7a7443e80b99 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2383,6 +2383,8 @@ static enum hvm_copy_result __hvm_copy(

     while ( todo > 0 )
     {
+        struct page_info *pg;
+
         count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);

         if ( flags & HVMCOPY_virt )
@@ -2427,7 +2429,11 @@ static enum hvm_copy_result __hvm_copy(
             put_gfn(curr->domain, gfn);
             return HVMCOPY_bad_gfn_to_mfn;
         }
+
         ASSERT(mfn_valid(mfn));
+        pg = mfn_to_page(mfn);
+        ASSERT(get_page(pg, curr->domain));
+        put_gfn(curr->domain, gfn);

         p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);

@@ -2457,7 +2463,7 @@ static enum hvm_copy_result __hvm_copy(
         addr += count;
         buf  += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(pg);
     }

     return HVMCOPY_okay;

>
> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 04:37:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 04:37:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMtxy-0001wf-NQ; Wed, 25 Apr 2012 04:36:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1SMtxx-0001wa-JZ
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 04:36:33 +0000
Received: from [85.158.139.83:43272] by server-11.bemta-5.messagelabs.com id
	21/C8-12959-05F779F4; Wed, 25 Apr 2012 04:36:32 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335328591!25347987!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29270 invoked from network); 25 Apr 2012 04:36:32 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 04:36:32 -0000
Received: by bkwj5 with SMTP id j5so1312521bkw.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 21:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=q1RDJqFjCvMEWJL8y14v96sfo0BX7wrt6x9d9eYy2Gs=;
	b=kFXBIOrq0UqBE1vTifBOiEYnOAh84bMAkWP1WbML59ZMZb3zNaB4UswfKJj6e0cW3A
	nCUd2OSvIuzJr74Sr/K8zmcdR6GdixLiGXi/hHQKohDDcQpzlQ2oRIyjJUDTIxtBu8FN
	JrHGHV8NF3C5ChG/feCncGMQnDhcsihGEGVNoof8/0f8fItoDYUxXVoUr9RNofojPeEe
	0zbBf0PMzYpLtLkjsLaDm2AP6nRY5NKcBVd4J6DZnqoWCcKkZX1gmoFA/Z/0bjIogBaq
	EmIAeyZb3hGvcC0wJ3e6kQAR/mxD5/ehyWjSaya7Y7S6tHSu/cHOdFRuHAJKt3j/hCug
	6o2Q==
MIME-Version: 1.0
Received: by 10.204.133.216 with SMTP id g24mr349418bkt.104.1335328591715;
	Tue, 24 Apr 2012 21:36:31 -0700 (PDT)
Received: by 10.204.114.138 with HTTP; Tue, 24 Apr 2012 21:36:31 -0700 (PDT)
Date: Tue, 24 Apr 2012 23:36:31 -0500
Message-ID: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Todd Deshane <todd.deshane@xen.org>
Subject: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2187428976741438058=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2187428976741438058==
Content-Type: multipart/alternative; boundary=0015175df3705e1c5e04be796a1a

--0015175df3705e1c5e04be796a1a
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

I just saw  http://vimeo.com/38636349 by todd. Nice plans for securing xen.

May I know who is leading/implementing XOAR ideas and Dom0 disaggregation?

~ SDK

--0015175df3705e1c5e04be796a1a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi All,<div><br></div><div>I just saw=A0
<a href=3D"http://vimeo.com/38636349">http://vimeo.com/38636349</a>=A0by to=
dd. Nice plans for securing xen.=A0</div><div><br></div><div>May I know who=
 is leading/implementing XOAR ideas and Dom0 disaggregation?</div><div><br =
clear=3D"all">
~ SDK<br><br>
</div>

--0015175df3705e1c5e04be796a1a--


--===============2187428976741438058==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2187428976741438058==--


From xen-devel-bounces@lists.xen.org Wed Apr 25 04:37:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 04:37:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMtxy-0001wf-NQ; Wed, 25 Apr 2012 04:36:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1SMtxx-0001wa-JZ
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 04:36:33 +0000
Received: from [85.158.139.83:43272] by server-11.bemta-5.messagelabs.com id
	21/C8-12959-05F779F4; Wed, 25 Apr 2012 04:36:32 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335328591!25347987!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29270 invoked from network); 25 Apr 2012 04:36:32 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 04:36:32 -0000
Received: by bkwj5 with SMTP id j5so1312521bkw.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 21:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=q1RDJqFjCvMEWJL8y14v96sfo0BX7wrt6x9d9eYy2Gs=;
	b=kFXBIOrq0UqBE1vTifBOiEYnOAh84bMAkWP1WbML59ZMZb3zNaB4UswfKJj6e0cW3A
	nCUd2OSvIuzJr74Sr/K8zmcdR6GdixLiGXi/hHQKohDDcQpzlQ2oRIyjJUDTIxtBu8FN
	JrHGHV8NF3C5ChG/feCncGMQnDhcsihGEGVNoof8/0f8fItoDYUxXVoUr9RNofojPeEe
	0zbBf0PMzYpLtLkjsLaDm2AP6nRY5NKcBVd4J6DZnqoWCcKkZX1gmoFA/Z/0bjIogBaq
	EmIAeyZb3hGvcC0wJ3e6kQAR/mxD5/ehyWjSaya7Y7S6tHSu/cHOdFRuHAJKt3j/hCug
	6o2Q==
MIME-Version: 1.0
Received: by 10.204.133.216 with SMTP id g24mr349418bkt.104.1335328591715;
	Tue, 24 Apr 2012 21:36:31 -0700 (PDT)
Received: by 10.204.114.138 with HTTP; Tue, 24 Apr 2012 21:36:31 -0700 (PDT)
Date: Tue, 24 Apr 2012 23:36:31 -0500
Message-ID: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Todd Deshane <todd.deshane@xen.org>
Subject: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2187428976741438058=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2187428976741438058==
Content-Type: multipart/alternative; boundary=0015175df3705e1c5e04be796a1a

--0015175df3705e1c5e04be796a1a
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

I just saw  http://vimeo.com/38636349 by todd. Nice plans for securing xen.

May I know who is leading/implementing XOAR ideas and Dom0 disaggregation?

~ SDK

--0015175df3705e1c5e04be796a1a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi All,<div><br></div><div>I just saw=A0
<a href=3D"http://vimeo.com/38636349">http://vimeo.com/38636349</a>=A0by to=
dd. Nice plans for securing xen.=A0</div><div><br></div><div>May I know who=
 is leading/implementing XOAR ideas and Dom0 disaggregation?</div><div><br =
clear=3D"all">
~ SDK<br><br>
</div>

--0015175df3705e1c5e04be796a1a--


--===============2187428976741438058==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2187428976741438058==--


From xen-devel-bounces@lists.xen.org Wed Apr 25 05:19:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 05:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMud0-0002O8-48; Wed, 25 Apr 2012 05:18:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMucy-0002O3-St
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 05:18:57 +0000
Received: from [85.158.143.99:61315] by server-3.bemta-4.messagelabs.com id
	1A/A8-05853-049879F4; Wed, 25 Apr 2012 05:18:56 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335331134!24570991!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29638 invoked from network); 25 Apr 2012 05:18:55 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-216.messagelabs.com with SMTP;
	25 Apr 2012 05:18:55 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 22:18:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92815189"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Apr 2012 22:18:53 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 22:18:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 13:18:51 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoAARKmWA//95SRD//2qsgP/+Ni2w
Date: Wed, 25 Apr 2012 05:18:50 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F484A@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
	<a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 11:34 AM
> 
> Thanks. Can you please try this:
> http://lists.xen.org/archives/html/xen-devel/2012-04/msg01861.html
> 
> in conjunction with the patch below?
> Andres
> 
> diff -r 7a7443e80b99 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2383,6 +2383,8 @@ static enum hvm_copy_result __hvm_copy(
> 
>      while ( todo > 0 )
>      {
> +        struct page_info *pg;
> +
>          count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);
> 
>          if ( flags & HVMCOPY_virt )
> @@ -2427,7 +2429,11 @@ static enum hvm_copy_result __hvm_copy(
>              put_gfn(curr->domain, gfn);
>              return HVMCOPY_bad_gfn_to_mfn;
>          }
> +
>          ASSERT(mfn_valid(mfn));
> +        pg = mfn_to_page(mfn);
> +        ASSERT(get_page(pg, curr->domain));
> +        put_gfn(curr->domain, gfn);
> 
>          p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
> 
> @@ -2457,7 +2463,7 @@ static enum hvm_copy_result __hvm_copy(
>          addr += count;
>          buf  += count;
>          todo -= count;
> -        put_gfn(curr->domain, gfn);
> +        put_page(pg);
>      }
> 
>      return HVMCOPY_okay;
No, it doesn't work. On the contrary, the competition is more fiercer than before: 
Here is the p2m_lock competition with 10 seconds with 16 vcpus:
lock:      560583(00000000:83362735), block:      321453(00000009:364CA49B)

yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 05:19:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 05:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMud0-0002O8-48; Wed, 25 Apr 2012 05:18:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SMucy-0002O3-St
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 05:18:57 +0000
Received: from [85.158.143.99:61315] by server-3.bemta-4.messagelabs.com id
	1A/A8-05853-049879F4; Wed, 25 Apr 2012 05:18:56 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335331134!24570991!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwNzUx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29638 invoked from network); 25 Apr 2012 05:18:55 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-216.messagelabs.com with SMTP;
	25 Apr 2012 05:18:55 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Apr 2012 22:18:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="92815189"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Apr 2012 22:18:53 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 24 Apr 2012 22:18:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.253]) with mapi id
	14.01.0355.002; Wed, 25 Apr 2012 13:18:51 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoAARKmWA//95SRD//2qsgP/+Ni2w
Date: Wed, 25 Apr 2012 05:18:50 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F484A@SHSMSX101.ccr.corp.intel.com>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
	<a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, April 25, 2012 11:34 AM
> 
> Thanks. Can you please try this:
> http://lists.xen.org/archives/html/xen-devel/2012-04/msg01861.html
> 
> in conjunction with the patch below?
> Andres
> 
> diff -r 7a7443e80b99 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2383,6 +2383,8 @@ static enum hvm_copy_result __hvm_copy(
> 
>      while ( todo > 0 )
>      {
> +        struct page_info *pg;
> +
>          count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);
> 
>          if ( flags & HVMCOPY_virt )
> @@ -2427,7 +2429,11 @@ static enum hvm_copy_result __hvm_copy(
>              put_gfn(curr->domain, gfn);
>              return HVMCOPY_bad_gfn_to_mfn;
>          }
> +
>          ASSERT(mfn_valid(mfn));
> +        pg = mfn_to_page(mfn);
> +        ASSERT(get_page(pg, curr->domain));
> +        put_gfn(curr->domain, gfn);
> 
>          p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
> 
> @@ -2457,7 +2463,7 @@ static enum hvm_copy_result __hvm_copy(
>          addr += count;
>          buf  += count;
>          todo -= count;
> -        put_gfn(curr->domain, gfn);
> +        put_page(pg);
>      }
> 
>      return HVMCOPY_okay;
No, it doesn't work. On the contrary, the competition is more fiercer than before: 
Here is the p2m_lock competition with 10 seconds with 16 vcpus:
lock:      560583(00000000:83362735), block:      321453(00000009:364CA49B)

yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 05:40:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 05:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMuxB-0002Zo-0T; Wed, 25 Apr 2012 05:39:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMux9-0002Zi-Hf
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 05:39:47 +0000
Received: from [85.158.139.83:50495] by server-5.bemta-5.messagelabs.com id
	5E/F4-13566-22E879F4; Wed, 25 Apr 2012 05:39:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335332385!18009201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14082 invoked from network); 25 Apr 2012 05:39:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 05:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,479,1330905600"; d="scan'208";a="12120313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 05:39:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 06:39:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMux7-0003P4-26;
	Wed, 25 Apr 2012 05:39:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMux6-00078F-QU;
	Wed, 25 Apr 2012 06:39:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12745-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 06:39:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12745: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12745 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12745/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  9 guest-start               fail REGR. vs. 12743
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12743

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  8fddae41cd1b
baseline version:
 xen                  1a8b47d80157

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 05:40:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 05:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMuxB-0002Zo-0T; Wed, 25 Apr 2012 05:39:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMux9-0002Zi-Hf
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 05:39:47 +0000
Received: from [85.158.139.83:50495] by server-5.bemta-5.messagelabs.com id
	5E/F4-13566-22E879F4; Wed, 25 Apr 2012 05:39:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335332385!18009201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14082 invoked from network); 25 Apr 2012 05:39:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 05:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,479,1330905600"; d="scan'208";a="12120313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 05:39:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 06:39:45 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMux7-0003P4-26;
	Wed, 25 Apr 2012 05:39:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMux6-00078F-QU;
	Wed, 25 Apr 2012 06:39:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12745-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 06:39:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12745: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12745 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12745/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  9 guest-start               fail REGR. vs. 12743
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12743

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  8fddae41cd1b
baseline version:
 xen                  1a8b47d80157

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 06:42:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 06:42:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMvvJ-0003FT-2p; Wed, 25 Apr 2012 06:41:57 +0000
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 1SMvvH-0003FO-8q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 06:41:55 +0000
Received: from [193.109.254.147:48154] by server-4.bemta-14.messagelabs.com id
	5E/F5-11570-2BC979F4; Wed, 25 Apr 2012 06:41:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335336113!6161009!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29124 invoked from network); 25 Apr 2012 06:41:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 06:41:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 07:43:09 +0100
Message-Id: <4F97B8E3020000780007FDA3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 07:42:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
	<CBBCC982.31764%keir.xen@gmail.com>
In-Reply-To: <CBBCC982.31764%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 22:20, Keir Fraser <keir.xen@gmail.com> wrote:
> On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
> 
>> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>>> as a new function table entry, or pay the price of calling
>>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>>> the case of the subject vCPU being current.
>>> 
>>> OK, I will try introducing a new wrapper that will return
>>> vmcb->kerngsbase /  v->arch.hvm_vmx.shadow_gs.
>> 
>> Jan,
>> 
>> How does this look?
> 
> Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
> patch won't compile on i386, as you have inconsistently ifdef'ed. Just
> remove the ifdefs as far as possible, we'd rather have dead code on i386
> than ifdefs.

Not exactly: VMX's shadow_gs field is conditional upon __x86_64__
too, so at least the body of the corresponding VMX function needs
to be #ifdef-ed as well. But beyond the #ifdef-ery, this looks good
to me (and I realized only on my way home yesterday that I really
asked too much when wanting this getting called on the current
vCPU to be taken care of - HVM can't call domctls for the time being,
and hence that situation can't arise at present).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 06:42:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 06:42:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMvvJ-0003FT-2p; Wed, 25 Apr 2012 06:41:57 +0000
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 1SMvvH-0003FO-8q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 06:41:55 +0000
Received: from [193.109.254.147:48154] by server-4.bemta-14.messagelabs.com id
	5E/F5-11570-2BC979F4; Wed, 25 Apr 2012 06:41:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335336113!6161009!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29124 invoked from network); 25 Apr 2012 06:41:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 06:41:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 07:43:09 +0100
Message-Id: <4F97B8E3020000780007FDA3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 07:42:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <CAB10MZCQgdddwPyjc1rrgKm+6oY-a0_rwD25rAkiqYiF94iX5w@mail.gmail.com>
	<CBBCC982.31764%keir.xen@gmail.com>
In-Reply-To: <CBBCC982.31764%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 22:20, Keir Fraser <keir.xen@gmail.com> wrote:
> On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
> wrote:
> 
>> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>>> as a new function table entry, or pay the price of calling
>>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>>> the case of the subject vCPU being current.
>>> 
>>> OK, I will try introducing a new wrapper that will return
>>> vmcb->kerngsbase /  v->arch.hvm_vmx.shadow_gs.
>> 
>> Jan,
>> 
>> How does this look?
> 
> Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
> patch won't compile on i386, as you have inconsistently ifdef'ed. Just
> remove the ifdefs as far as possible, we'd rather have dead code on i386
> than ifdefs.

Not exactly: VMX's shadow_gs field is conditional upon __x86_64__
too, so at least the body of the corresponding VMX function needs
to be #ifdef-ed as well. But beyond the #ifdef-ery, this looks good
to me (and I realized only on my way home yesterday that I really
asked too much when wanting this getting called on the current
vCPU to be taken care of - HVM can't call domctls for the time being,
and hence that situation can't arise at present).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 06:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 06:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMw4I-0003Od-2n; Wed, 25 Apr 2012 06:51:14 +0000
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 1SMw4G-0003OY-C1
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 06:51:12 +0000
Received: from [193.109.254.147:24994] by server-4.bemta-14.messagelabs.com id
	58/5A-11570-FDE979F4; Wed, 25 Apr 2012 06:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335336670!6144295!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12401 invoked from network); 25 Apr 2012 06:51:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 06:51:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 07:51:09 +0100
Message-Id: <4F97BB12020000780007FDB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 07:51:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
	<4F96690D020000780007F810@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 04:46, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Tuesday, April 24, 2012 2:49 PM
>> To: Hao, Xudong
>> Cc: xen-devel; konrad.wilk@oracle.com 
>> Subject: RE: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
>> pciback
>> 
>> >>> On 24.04.12 at 04:49, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> >> > +	/* set default value */
>> >> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
>> >> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
>> value */
>> >> > +
>> >> > +	/* Enable LTR and OBFF before do device assignment */
>> >> > +	/* LTR(Latency tolerance reporting) allows devices to send messages
>> to the
>> >> > +	 * root complex indicating their latency tolerance for snooped &
>> unsnooped
>> >> > +	 * memory transactions.
>> >> > +	 */
>> >> > +	pci_enable_ltr(dev);
>> >> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
>> >>
>> >> Wouldn't the guest kernel be able to do this itself, as it's just playing
>> > with bits in
>> >> the PCIE capability structure, or the LTR extended one?
>> >
>> > There are two reasons I want to enable ltr/obff in host but not in guest.
>> > 1) ltr/obff is not only for one device, enabling them need to enable the
>> > whole pci bus, include root port, upstream and downstream port. It's
>> complex
>> > to let guest enable the whole path.
>> 
>> Then it would still be more clean to extend the pciif, allowing the guest
>> to request enabling, or even better snoop the writes to the capabilities/
>> LTR structures in pciback.
>> 
> 
> Qemu only emulate the device which is assigned to guest, but it does not 
> emulate the physic device's whole bus path. Seems allowing guest request 
> enabling looks reasonable, but I think it's only applicable for "per device 
> feature(that unnecessary to enable the whole pci path)".  

No - if the guest asks the host to call pci_enable_ltr(), it'll imply enabling
for the entire path (as that's what the call results in). Which imo is better
than enabling a feature upfront, just in case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 06:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 06:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMw4I-0003Od-2n; Wed, 25 Apr 2012 06:51:14 +0000
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 1SMw4G-0003OY-C1
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 06:51:12 +0000
Received: from [193.109.254.147:24994] by server-4.bemta-14.messagelabs.com id
	58/5A-11570-FDE979F4; Wed, 25 Apr 2012 06:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335336670!6144295!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12401 invoked from network); 25 Apr 2012 06:51:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 06:51:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 07:51:09 +0100
Message-Id: <4F97BB12020000780007FDB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 07:51:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
	<4F96690D020000780007F810@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 04:46, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Tuesday, April 24, 2012 2:49 PM
>> To: Hao, Xudong
>> Cc: xen-devel; konrad.wilk@oracle.com 
>> Subject: RE: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
>> pciback
>> 
>> >>> On 24.04.12 at 04:49, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> >> > +	/* set default value */
>> >> > +	unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
>> >> > +	int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
>> value */
>> >> > +
>> >> > +	/* Enable LTR and OBFF before do device assignment */
>> >> > +	/* LTR(Latency tolerance reporting) allows devices to send messages
>> to the
>> >> > +	 * root complex indicating their latency tolerance for snooped &
>> unsnooped
>> >> > +	 * memory transactions.
>> >> > +	 */
>> >> > +	pci_enable_ltr(dev);
>> >> > +	pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
>> >>
>> >> Wouldn't the guest kernel be able to do this itself, as it's just playing
>> > with bits in
>> >> the PCIE capability structure, or the LTR extended one?
>> >
>> > There are two reasons I want to enable ltr/obff in host but not in guest.
>> > 1) ltr/obff is not only for one device, enabling them need to enable the
>> > whole pci bus, include root port, upstream and downstream port. It's
>> complex
>> > to let guest enable the whole path.
>> 
>> Then it would still be more clean to extend the pciif, allowing the guest
>> to request enabling, or even better snoop the writes to the capabilities/
>> LTR structures in pciback.
>> 
> 
> Qemu only emulate the device which is assigned to guest, but it does not 
> emulate the physic device's whole bus path. Seems allowing guest request 
> enabling looks reasonable, but I think it's only applicable for "per device 
> feature(that unnecessary to enable the whole pci path)".  

No - if the guest asks the host to call pci_enable_ltr(), it'll imply enabling
for the entire path (as that's what the call results in). Which imo is better
than enabling a feature upfront, just in case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 06:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 06:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMw4a-0003Pt-KS; Wed, 25 Apr 2012 06:51:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMw4Z-0003Ph-Ht
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 06:51:32 +0000
Received: from [85.158.143.99:18895] by server-2.bemta-4.messagelabs.com id
	D3/54-17550-2FE979F4; Wed, 25 Apr 2012 06:51:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335336689!24233051!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2834 invoked from network); 25 Apr 2012 06:51:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 06:51:29 -0000
Received: by wgbed3 with SMTP id ed3so1083442wgb.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 23:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=linWusUQxno7Vy6N9r0HgSjpcXYKv8mmmtIU/xIVvBQ=;
	b=p0JIG6Q0VRkiGog7AVSBi1R0ObfJ0w/mmxfrreCEfrPjEFA6lGiwizIIQQjAQnJORv
	kC9AUmEQfgcXDAvQemlpXZqSwzsLB9NoDNbaBnZLwdHBcQ/+VqEu1ycub8yN6A+Ui7y8
	amWMErlQJXOH64ayWo4H7eCDtFistPsoZNVunkzVvX7Y+bxo4zeFTw0x2wLIWTZyx62z
	LByYV1/01xvXjqI/WdrhU0P+FP5+BCf2+LEl/B1j1d09ZzO5Wj0gkORMnxUzzpQrD0/R
	CyJ/AceytxZ0MjkkGNl0EZappt++s8+LqJeAQE6PlyyV0USq+4dHbrlBBSMYtYDYisWw
	9J0g==
Received: by 10.180.96.228 with SMTP id dv4mr3362986wib.14.1335336689238;
	Tue, 24 Apr 2012 23:51:29 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id fn2sm55546695wib.0.2012.04.24.23.51.27
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 23:51:28 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Apr 2012 07:51:19 +0100
From: Keir Fraser <keir@xen.org>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <CBBD5D77.3ED72%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
Thread-Index: Ac0ir9FRcmcGTf9QTUaMd1zQtDbNeg==
In-Reply-To: <CAB10MZAax61ccMOqs_NpSe9A3LWByu6ZohLHeFk5VPVDkgJUgg@mail.gmail.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/2012 22:34, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

> On Tue, Apr 24, 2012 at 1:20 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
>> wrote:
>> =

>>> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
>>> <aravindh@virtuata.com> wrote:
>>>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrot=
e:
>> =

>>>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>>>> as a new function table entry, or pay the price of calling
>>>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>>>> the case of the subject vCPU being current.
>>>> =

>>>> OK, I will try introducing a new wrapper that will return
>>>> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.
>>> =

>>> Jan,
>>> =

>>> How does this look?
>> =

>> Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
>> patch won't compile on i386, as you have inconsistently ifdef'ed. Just
>> remove the ifdefs as far as possible, we'd rather have dead code on i386
>> than ifdefs.
> =

> Does this look better? I couldn't get away with adding ifdef x86_64
> only to domctl.c. I also had to add it to the
> (svm/vmx)_get_shadow_gs_base(). It now complies for x86_32.

You don't need ifdef in svm_get_shadow_gs_base(). Agree that you do in
vmx_get_shadow_gs_base() though. Remove the unnecessary ifdef in svm.c and
then you can submit this with signed-off-by.

 -- Keir

> Aravindh
> =

> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>          hvm_get_segment_register(v, x86_seg_ss, &sreg);
>          c.nat->user_regs.ss =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_ds, &sreg);
>          c.nat->user_regs.ds =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_es, &sreg);
>          c.nat->user_regs.es =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs =3D sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base =3D sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs =3D sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +        {
> +            c.nat->gs_base_kernel =3D sreg.base;
> +            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
> +        }
> +        else
> +        {
> +            c.nat->gs_base_user =3D sreg.base;
> +            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
> +        }
> +#endif
>      }
>      else
>      {
>          c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>          c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>          for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
>              c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
>  #ifdef CONFIG_COMPAT
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -640,16 +640,27 @@ static void svm_set_segment_register(str
>      default:
>          BUG();
>      }
> =

>      if ( sync )
>          svm_vmload(vmcb);
>  }
> =

> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
> +{
> +#ifdef __x86_64__
> +    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> +
> +    return vmcb->kerngsbase;
> +#else
> +    return 0;
> +#endif
> +}
> +
>  static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> =

>      if ( !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmcb_set_g_pat(vmcb, gpat);
> @@ -1978,16 +1989,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D svm_vcpu_destroy,
>      .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
>      .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
>      .get_interrupt_shadow =3D svm_get_interrupt_shadow,
>      .set_interrupt_shadow =3D svm_set_interrupt_shadow,
>      .guest_x86_mode       =3D svm_guest_x86_mode,
>      .get_segment_register =3D svm_get_segment_register,
>      .set_segment_register =3D svm_set_segment_register,
> +    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
>      .update_host_cr3      =3D svm_update_host_cr3,
>      .update_guest_cr      =3D svm_update_guest_cr,
>      .update_guest_efer    =3D svm_update_guest_efer,
>      .set_guest_pat        =3D svm_set_guest_pat,
>      .get_guest_pat        =3D svm_get_guest_pat,
>      .set_tsc_offset       =3D svm_set_tsc_offset,
>      .inject_exception     =3D svm_inject_exception,
>      .init_hypercall_page  =3D svm_init_hypercall_page,
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -937,16 +937,25 @@ static void vmx_set_segment_register(str
>          break;
>      default:
>          BUG();
>      }
> =

>      vmx_vmcs_exit(v);
>  }
> =

> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
> +{
> +#ifdef __x86_64__
> +    return v->arch.hvm_vmx.shadow_gs;
> +#else
> +    return 0;
> +#endif
> +}
> +
>  static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmx_vmcs_enter(v);
>      __vmwrite(GUEST_PAT, gpat);
>  #ifdef __i386__
> @@ -1517,16 +1526,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D vmx_vcpu_destroy,
>      .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
>      .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
>      .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>      .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>      .guest_x86_mode       =3D vmx_guest_x86_mode,
>      .get_segment_register =3D vmx_get_segment_register,
>      .set_segment_register =3D vmx_set_segment_register,
> +    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
>      .update_host_cr3      =3D vmx_update_host_cr3,
>      .update_guest_cr      =3D vmx_update_guest_cr,
>      .update_guest_efer    =3D vmx_update_guest_efer,
>      .set_guest_pat        =3D vmx_set_guest_pat,
>      .get_guest_pat        =3D vmx_get_guest_pat,
>      .set_tsc_offset       =3D vmx_set_tsc_offset,
>      .inject_exception     =3D vmx_inject_exception,
>      .init_hypercall_page  =3D vmx_init_hypercall_page,
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -101,16 +101,17 @@ struct hvm_function_table {
>      /* Examine specifics of the guest state. */
>      unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>      void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shado=
w);
>      int (*guest_x86_mode)(struct vcpu *v);
>      void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
>      void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
> +    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
> =

>      /*
>       * Re-set the value of CR3 that Xen runs on when handling VM exits.
>       */
>      void (*update_host_cr3)(struct vcpu *v);
> =

>      /*
>       * Called to inform HVM layer that a guest CRn or EFER has changed.
> @@ -300,16 +301,21 @@ hvm_get_segment_register(struct vcpu *v,
> =

>  static inline void
>  hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>                           struct segment_register *reg)
>  {
>      hvm_funcs.set_segment_register(v, seg, reg);
>  }
> =

> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
> +{
> +    return hvm_funcs.get_shadow_gs_base(v);
> +}
> +
>  #define is_viridian_domain(_d)                                          =
   \
>   (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]=
))
> =

>  void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
>                                     unsigned int *ecx, unsigned int *edx);
>  void hvm_migrate_timers(struct vcpu *v);
>  void hvm_do_resume(struct vcpu *v);
>  void hvm_migrate_pirqs(struct vcpu *v);
> =

> =

> =

>> =A0-- Keir
>> =

>>> PS: Come submission time, I will send it out as two separate patches.
>>> =

>>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ss, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ss =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ds, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ds =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_es, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>>> +#endif
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>> + =A0 =A0 =A0 =A0{
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D hvm_get_shadow_gs_base=
(v);
>>> + =A0 =A0 =A0 =A0}
>>> + =A0 =A0 =A0 =A0else
>>> + =A0 =A0 =A0 =A0{
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D hvm_get_shadow_gs_ba=
se(v);
>>> + =A0 =A0 =A0 =A0}
>>> +#endif
>>> =A0 =A0 =A0}
>>> =A0 =A0 =A0else
>>> =A0 =A0 =A0{
>>> =A0 =A0 =A0 =A0 =A0c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>>> =A0 =A0 =A0 =A0 =A0c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>>> =A0 =A0 =A0 =A0 =A0for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_fr=
ames); ++i )
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_fram=
es[i]);
>>> =A0#ifdef CONFIG_COMPAT
>>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -640,16 +640,25 @@ static void svm_set_segment_register(str
>>> =A0 =A0 =A0default:
>>> =A0 =A0 =A0 =A0 =A0BUG();
>>> =A0 =A0 =A0}
>>> =

>>> =A0 =A0 =A0if ( sync )
>>> =A0 =A0 =A0 =A0 =A0svm_vmload(vmcb);
>>> =A0}
>>> =

>>> +#ifdef __x86_64__
>>> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
>>> +{
>>> + =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>>> +
>>> + =A0 =A0return vmcb->kerngsbase;
>>> +}
>>> +#endif
>>> +
>>> =A0static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>>> =A0{
>>> =A0 =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>>> =

>>> =A0 =A0 =A0if ( !paging_mode_hap(v->domain) )
>>> =A0 =A0 =A0 =A0 =A0return 0;
>>> =

>>> =A0 =A0 =A0vmcb_set_g_pat(vmcb, gpat);
>>> @@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
>>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D svm_vcpu_destroy,
>>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_save_vmcb_ctxt,
>>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_load_vmcb_ctxt,
>>> =A0 =A0 =A0.get_interrupt_shadow =3D svm_get_interrupt_shadow,
>>> =A0 =A0 =A0.set_interrupt_shadow =3D svm_set_interrupt_shadow,
>>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D svm_guest_x86_mode,
>>> =A0 =A0 =A0.get_segment_register =3D svm_get_segment_register,
>>> =A0 =A0 =A0.set_segment_register =3D svm_set_segment_register,
>>> + =A0 =A0.get_shadow_gs_base =A0 =3D svm_get_shadow_gs_base,
>>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D svm_update_host_cr3,
>>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D svm_update_guest_cr,
>>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D svm_update_guest_efer,
>>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D svm_set_guest_pat,
>>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D svm_get_guest_pat,
>>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D svm_set_tsc_offset,
>>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D svm_inject_exception,
>>> =A0 =A0 =A0.init_hypercall_page =A0=3D svm_init_hypercall_page,
>>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
>>> =A0 =A0 =A0 =A0 =A0break;
>>> =A0 =A0 =A0default:
>>> =A0 =A0 =A0 =A0 =A0BUG();
>>> =A0 =A0 =A0}
>>> =

>>> =A0 =A0 =A0vmx_vmcs_exit(v);
>>> =A0}
>>> =

>>> +#ifdef __x86_64__
>>> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
>>> +{
>>> + =A0 =A0return v->arch.hvm_vmx.shadow_gs;
>>> +}
>>> +#endif
>>> +
>>> =A0static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>>> =A0{
>>> =A0 =A0 =A0if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>>> =A0 =A0 =A0 =A0 =A0return 0;
>>> =

>>> =A0 =A0 =A0vmx_vmcs_enter(v);
>>> =A0 =A0 =A0__vmwrite(GUEST_PAT, gpat);
>>> =A0#ifdef __i386__
>>> @@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
>>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D vmx_vcpu_destroy,
>>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_save_vmcs_ctxt,
>>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_load_vmcs_ctxt,
>>> =A0 =A0 =A0.get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>>> =A0 =A0 =A0.set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D vmx_guest_x86_mode,
>>> =A0 =A0 =A0.get_segment_register =3D vmx_get_segment_register,
>>> =A0 =A0 =A0.set_segment_register =3D vmx_set_segment_register,
>>> + =A0 =A0.get_shadow_gs_base =A0 =3D vmx_get_shadow_gs_base,
>>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D vmx_update_host_cr3,
>>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D vmx_update_guest_cr,
>>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D vmx_update_guest_efer,
>>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D vmx_set_guest_pat,
>>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D vmx_get_guest_pat,
>>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D vmx_set_tsc_offset,
>>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D vmx_inject_exception,
>>> =A0 =A0 =A0.init_hypercall_page =A0=3D vmx_init_hypercall_page,
>>> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hv=
m.h
>>> --- a/xen/include/asm-x86/hvm/hvm.h
>>> +++ b/xen/include/asm-x86/hvm/hvm.h
>>> @@ -101,16 +101,19 @@ struct hvm_function_table {
>>> =A0 =A0 =A0/* Examine specifics of the guest state. */
>>> =A0 =A0 =A0unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>>> =A0 =A0 =A0void (*set_interrupt_shadow)(struct vcpu *v, unsigned int in=
tr_shadow);
>>> =A0 =A0 =A0int (*guest_x86_mode)(struct vcpu *v);
>>> =A0 =A0 =A0void (*get_segment_register)(struct vcpu *v, enum x86_segmen=
t seg,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 str=
uct segment_register *reg);
>>> =A0 =A0 =A0void (*set_segment_register)(struct vcpu *v, enum x86_segmen=
t seg,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 str=
uct segment_register *reg);
>>> +#ifdef __x86_64__
>>> + =A0 =A0unsigned long (*get_shadow_gs_base)(struct vcpu *v);
>>> +#endif
>>> =

>>> =A0 =A0 =A0/*
>>> =A0 =A0 =A0 * Re-set the value of CR3 that Xen runs on when handling VM=
 exits.
>>> =A0 =A0 =A0 */
>>> =A0 =A0 =A0void (*update_host_cr3)(struct vcpu *v);
>>> =

>>> =A0 =A0 =A0/*
>>> =A0 =A0 =A0 * Called to inform HVM layer that a guest CRn or EFER has c=
hanged.
>>> @@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,
>>> =

>>> =A0static inline void
>>> =A0hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct segment_regi=
ster *reg)
>>> =A0{
>>> =A0 =A0 =A0hvm_funcs.set_segment_register(v, seg, reg);
>>> =A0}
>>> =

>>> +#ifdef __x86_64__
>>> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
>>> +{
>>> + =A0 =A0return hvm_funcs.get_shadow_gs_base(v);
>>> +}
>>> +#endif
>>> +
>>> =A0#define is_viridian_domain(_d) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
>>> \
>>> =A0 (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRID=
IAN]))
>>> =

>>> =A0void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *=
ebx,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 unsigned int *ecx, unsigned int *edx);
>>> =A0void hvm_migrate_timers(struct vcpu *v);
>>> =A0void hvm_do_resume(struct vcpu *v);
>>> =A0void hvm_migrate_pirqs(struct vcpu *v);
>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 06:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 06:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMw4a-0003Pt-KS; Wed, 25 Apr 2012 06:51:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SMw4Z-0003Ph-Ht
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 06:51:32 +0000
Received: from [85.158.143.99:18895] by server-2.bemta-4.messagelabs.com id
	D3/54-17550-2FE979F4; Wed, 25 Apr 2012 06:51:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335336689!24233051!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2834 invoked from network); 25 Apr 2012 06:51:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 06:51:29 -0000
Received: by wgbed3 with SMTP id ed3so1083442wgb.32
	for <xen-devel@lists.xen.org>; Tue, 24 Apr 2012 23:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=linWusUQxno7Vy6N9r0HgSjpcXYKv8mmmtIU/xIVvBQ=;
	b=p0JIG6Q0VRkiGog7AVSBi1R0ObfJ0w/mmxfrreCEfrPjEFA6lGiwizIIQQjAQnJORv
	kC9AUmEQfgcXDAvQemlpXZqSwzsLB9NoDNbaBnZLwdHBcQ/+VqEu1ycub8yN6A+Ui7y8
	amWMErlQJXOH64ayWo4H7eCDtFistPsoZNVunkzVvX7Y+bxo4zeFTw0x2wLIWTZyx62z
	LByYV1/01xvXjqI/WdrhU0P+FP5+BCf2+LEl/B1j1d09ZzO5Wj0gkORMnxUzzpQrD0/R
	CyJ/AceytxZ0MjkkGNl0EZappt++s8+LqJeAQE6PlyyV0USq+4dHbrlBBSMYtYDYisWw
	9J0g==
Received: by 10.180.96.228 with SMTP id dv4mr3362986wib.14.1335336689238;
	Tue, 24 Apr 2012 23:51:29 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id fn2sm55546695wib.0.2012.04.24.23.51.27
	(version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 23:51:28 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Apr 2012 07:51:19 +0100
From: Keir Fraser <keir@xen.org>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <CBBD5D77.3ED72%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
	context
Thread-Index: Ac0ir9FRcmcGTf9QTUaMd1zQtDbNeg==
In-Reply-To: <CAB10MZAax61ccMOqs_NpSe9A3LWByu6ZohLHeFk5VPVDkgJUgg@mail.gmail.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU
 context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/04/2012 22:34, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
wrote:

> On Tue, Apr 24, 2012 at 1:20 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
>> wrote:
>> =

>>> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
>>> <aravindh@virtuata.com> wrote:
>>>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@suse.com> wrot=
e:
>> =

>>>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>>>> as a new function table entry, or pay the price of calling
>>>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>>>> the case of the subject vCPU being current.
>>>> =

>>>> OK, I will try introducing a new wrapper that will return
>>>> vmcb->kerngsbase / =A0v->arch.hvm_vmx.shadow_gs.
>>> =

>>> Jan,
>>> =

>>> How does this look?
>> =

>> Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
>> patch won't compile on i386, as you have inconsistently ifdef'ed. Just
>> remove the ifdefs as far as possible, we'd rather have dead code on i386
>> than ifdefs.
> =

> Does this look better? I couldn't get away with adding ifdef x86_64
> only to domctl.c. I also had to add it to the
> (svm/vmx)_get_shadow_gs_base(). It now complies for x86_32.

You don't need ifdef in svm_get_shadow_gs_base(). Agree that you do in
vmx_get_shadow_gs_base() though. Remove the unnecessary ifdef in svm.c and
then you can submit this with signed-off-by.

 -- Keir

> Aravindh
> =

> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>          hvm_get_segment_register(v, x86_seg_ss, &sreg);
>          c.nat->user_regs.ss =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_ds, &sreg);
>          c.nat->user_regs.ds =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_es, &sreg);
>          c.nat->user_regs.es =3D sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs =3D sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base =3D sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs =3D sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +        {
> +            c.nat->gs_base_kernel =3D sreg.base;
> +            c.nat->gs_base_user =3D hvm_get_shadow_gs_base(v);
> +        }
> +        else
> +        {
> +            c.nat->gs_base_user =3D sreg.base;
> +            c.nat->gs_base_kernel =3D hvm_get_shadow_gs_base(v);
> +        }
> +#endif
>      }
>      else
>      {
>          c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>          c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>          for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i )
>              c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_frames[i]);
>  #ifdef CONFIG_COMPAT
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -640,16 +640,27 @@ static void svm_set_segment_register(str
>      default:
>          BUG();
>      }
> =

>      if ( sync )
>          svm_vmload(vmcb);
>  }
> =

> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
> +{
> +#ifdef __x86_64__
> +    struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> +
> +    return vmcb->kerngsbase;
> +#else
> +    return 0;
> +#endif
> +}
> +
>  static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
> =

>      if ( !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmcb_set_g_pat(vmcb, gpat);
> @@ -1978,16 +1989,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D svm_vcpu_destroy,
>      .save_cpu_ctxt        =3D svm_save_vmcb_ctxt,
>      .load_cpu_ctxt        =3D svm_load_vmcb_ctxt,
>      .get_interrupt_shadow =3D svm_get_interrupt_shadow,
>      .set_interrupt_shadow =3D svm_set_interrupt_shadow,
>      .guest_x86_mode       =3D svm_guest_x86_mode,
>      .get_segment_register =3D svm_get_segment_register,
>      .set_segment_register =3D svm_set_segment_register,
> +    .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
>      .update_host_cr3      =3D svm_update_host_cr3,
>      .update_guest_cr      =3D svm_update_guest_cr,
>      .update_guest_efer    =3D svm_update_guest_efer,
>      .set_guest_pat        =3D svm_set_guest_pat,
>      .get_guest_pat        =3D svm_get_guest_pat,
>      .set_tsc_offset       =3D svm_set_tsc_offset,
>      .inject_exception     =3D svm_inject_exception,
>      .init_hypercall_page  =3D svm_init_hypercall_page,
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -937,16 +937,25 @@ static void vmx_set_segment_register(str
>          break;
>      default:
>          BUG();
>      }
> =

>      vmx_vmcs_exit(v);
>  }
> =

> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
> +{
> +#ifdef __x86_64__
> +    return v->arch.hvm_vmx.shadow_gs;
> +#else
> +    return 0;
> +#endif
> +}
> +
>  static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>  {
>      if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>          return 0;
> =

>      vmx_vmcs_enter(v);
>      __vmwrite(GUEST_PAT, gpat);
>  #ifdef __i386__
> @@ -1517,16 +1526,17 @@ static struct hvm_function_table __read_
>      .vcpu_destroy         =3D vmx_vcpu_destroy,
>      .save_cpu_ctxt        =3D vmx_save_vmcs_ctxt,
>      .load_cpu_ctxt        =3D vmx_load_vmcs_ctxt,
>      .get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>      .set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>      .guest_x86_mode       =3D vmx_guest_x86_mode,
>      .get_segment_register =3D vmx_get_segment_register,
>      .set_segment_register =3D vmx_set_segment_register,
> +    .get_shadow_gs_base   =3D vmx_get_shadow_gs_base,
>      .update_host_cr3      =3D vmx_update_host_cr3,
>      .update_guest_cr      =3D vmx_update_guest_cr,
>      .update_guest_efer    =3D vmx_update_guest_efer,
>      .set_guest_pat        =3D vmx_set_guest_pat,
>      .get_guest_pat        =3D vmx_get_guest_pat,
>      .set_tsc_offset       =3D vmx_set_tsc_offset,
>      .inject_exception     =3D vmx_inject_exception,
>      .init_hypercall_page  =3D vmx_init_hypercall_page,
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -101,16 +101,17 @@ struct hvm_function_table {
>      /* Examine specifics of the guest state. */
>      unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>      void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shado=
w);
>      int (*guest_x86_mode)(struct vcpu *v);
>      void (*get_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
>      void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
>                                   struct segment_register *reg);
> +    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
> =

>      /*
>       * Re-set the value of CR3 that Xen runs on when handling VM exits.
>       */
>      void (*update_host_cr3)(struct vcpu *v);
> =

>      /*
>       * Called to inform HVM layer that a guest CRn or EFER has changed.
> @@ -300,16 +301,21 @@ hvm_get_segment_register(struct vcpu *v,
> =

>  static inline void
>  hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>                           struct segment_register *reg)
>  {
>      hvm_funcs.set_segment_register(v, seg, reg);
>  }
> =

> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
> +{
> +    return hvm_funcs.get_shadow_gs_base(v);
> +}
> +
>  #define is_viridian_domain(_d)                                          =
   \
>   (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]=
))
> =

>  void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
>                                     unsigned int *ecx, unsigned int *edx);
>  void hvm_migrate_timers(struct vcpu *v);
>  void hvm_do_resume(struct vcpu *v);
>  void hvm_migrate_pirqs(struct vcpu *v);
> =

> =

> =

>> =A0-- Keir
>> =

>>> PS: Come submission time, I will send it out as two separate patches.
>>> =

>>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -1585,18 +1585,33 @@ void arch_get_info_guest(struct vcpu *v,
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ss, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ss =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_ds, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.ds =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_es, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.es =3D sreg.sel;
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.fs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0c.nat->fs_base =3D sreg.base;
>>> +#endif
>>> =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>> =A0 =A0 =A0 =A0 =A0c.nat->user_regs.gs =3D sreg.sel;
>>> +#ifdef __x86_64__
>>> + =A0 =A0 =A0 =A0if ( ring_0(&c.nat->user_regs) )
>>> + =A0 =A0 =A0 =A0{
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D sreg.base;
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D hvm_get_shadow_gs_base=
(v);
>>> + =A0 =A0 =A0 =A0}
>>> + =A0 =A0 =A0 =A0else
>>> + =A0 =A0 =A0 =A0{
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_user =3D sreg.base;
>>> + =A0 =A0 =A0 =A0 =A0 =A0c.nat->gs_base_kernel =3D hvm_get_shadow_gs_ba=
se(v);
>>> + =A0 =A0 =A0 =A0}
>>> +#endif
>>> =A0 =A0 =A0}
>>> =A0 =A0 =A0else
>>> =A0 =A0 =A0{
>>> =A0 =A0 =A0 =A0 =A0c(ldt_base =3D v->arch.pv_vcpu.ldt_base);
>>> =A0 =A0 =A0 =A0 =A0c(ldt_ents =3D v->arch.pv_vcpu.ldt_ents);
>>> =A0 =A0 =A0 =A0 =A0for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_fr=
ames); ++i )
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0c(gdt_frames[i] =3D v->arch.pv_vcpu.gdt_fram=
es[i]);
>>> =A0#ifdef CONFIG_COMPAT
>>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -640,16 +640,25 @@ static void svm_set_segment_register(str
>>> =A0 =A0 =A0default:
>>> =A0 =A0 =A0 =A0 =A0BUG();
>>> =A0 =A0 =A0}
>>> =

>>> =A0 =A0 =A0if ( sync )
>>> =A0 =A0 =A0 =A0 =A0svm_vmload(vmcb);
>>> =A0}
>>> =

>>> +#ifdef __x86_64__
>>> +static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
>>> +{
>>> + =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>>> +
>>> + =A0 =A0return vmcb->kerngsbase;
>>> +}
>>> +#endif
>>> +
>>> =A0static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
>>> =A0{
>>> =A0 =A0 =A0struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
>>> =

>>> =A0 =A0 =A0if ( !paging_mode_hap(v->domain) )
>>> =A0 =A0 =A0 =A0 =A0return 0;
>>> =

>>> =A0 =A0 =A0vmcb_set_g_pat(vmcb, gpat);
>>> @@ -1978,16 +1987,17 @@ static struct hvm_function_table __read_
>>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D svm_vcpu_destroy,
>>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_save_vmcb_ctxt,
>>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D svm_load_vmcb_ctxt,
>>> =A0 =A0 =A0.get_interrupt_shadow =3D svm_get_interrupt_shadow,
>>> =A0 =A0 =A0.set_interrupt_shadow =3D svm_set_interrupt_shadow,
>>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D svm_guest_x86_mode,
>>> =A0 =A0 =A0.get_segment_register =3D svm_get_segment_register,
>>> =A0 =A0 =A0.set_segment_register =3D svm_set_segment_register,
>>> + =A0 =A0.get_shadow_gs_base =A0 =3D svm_get_shadow_gs_base,
>>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D svm_update_host_cr3,
>>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D svm_update_guest_cr,
>>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D svm_update_guest_efer,
>>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D svm_set_guest_pat,
>>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D svm_get_guest_pat,
>>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D svm_set_tsc_offset,
>>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D svm_inject_exception,
>>> =A0 =A0 =A0.init_hypercall_page =A0=3D svm_init_hypercall_page,
>>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -937,16 +937,23 @@ static void vmx_set_segment_register(str
>>> =A0 =A0 =A0 =A0 =A0break;
>>> =A0 =A0 =A0default:
>>> =A0 =A0 =A0 =A0 =A0BUG();
>>> =A0 =A0 =A0}
>>> =

>>> =A0 =A0 =A0vmx_vmcs_exit(v);
>>> =A0}
>>> =

>>> +#ifdef __x86_64__
>>> +static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
>>> +{
>>> + =A0 =A0return v->arch.hvm_vmx.shadow_gs;
>>> +}
>>> +#endif
>>> +
>>> =A0static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
>>> =A0{
>>> =A0 =A0 =A0if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
>>> =A0 =A0 =A0 =A0 =A0return 0;
>>> =

>>> =A0 =A0 =A0vmx_vmcs_enter(v);
>>> =A0 =A0 =A0__vmwrite(GUEST_PAT, gpat);
>>> =A0#ifdef __i386__
>>> @@ -1517,16 +1524,17 @@ static struct hvm_function_table __read_
>>> =A0 =A0 =A0.vcpu_destroy =A0 =A0 =A0 =A0 =3D vmx_vcpu_destroy,
>>> =A0 =A0 =A0.save_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_save_vmcs_ctxt,
>>> =A0 =A0 =A0.load_cpu_ctxt =A0 =A0 =A0 =A0=3D vmx_load_vmcs_ctxt,
>>> =A0 =A0 =A0.get_interrupt_shadow =3D vmx_get_interrupt_shadow,
>>> =A0 =A0 =A0.set_interrupt_shadow =3D vmx_set_interrupt_shadow,
>>> =A0 =A0 =A0.guest_x86_mode =A0 =A0 =A0 =3D vmx_guest_x86_mode,
>>> =A0 =A0 =A0.get_segment_register =3D vmx_get_segment_register,
>>> =A0 =A0 =A0.set_segment_register =3D vmx_set_segment_register,
>>> + =A0 =A0.get_shadow_gs_base =A0 =3D vmx_get_shadow_gs_base,
>>> =A0 =A0 =A0.update_host_cr3 =A0 =A0 =A0=3D vmx_update_host_cr3,
>>> =A0 =A0 =A0.update_guest_cr =A0 =A0 =A0=3D vmx_update_guest_cr,
>>> =A0 =A0 =A0.update_guest_efer =A0 =A0=3D vmx_update_guest_efer,
>>> =A0 =A0 =A0.set_guest_pat =A0 =A0 =A0 =A0=3D vmx_set_guest_pat,
>>> =A0 =A0 =A0.get_guest_pat =A0 =A0 =A0 =A0=3D vmx_get_guest_pat,
>>> =A0 =A0 =A0.set_tsc_offset =A0 =A0 =A0 =3D vmx_set_tsc_offset,
>>> =A0 =A0 =A0.inject_exception =A0 =A0 =3D vmx_inject_exception,
>>> =A0 =A0 =A0.init_hypercall_page =A0=3D vmx_init_hypercall_page,
>>> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hv=
m.h
>>> --- a/xen/include/asm-x86/hvm/hvm.h
>>> +++ b/xen/include/asm-x86/hvm/hvm.h
>>> @@ -101,16 +101,19 @@ struct hvm_function_table {
>>> =A0 =A0 =A0/* Examine specifics of the guest state. */
>>> =A0 =A0 =A0unsigned int (*get_interrupt_shadow)(struct vcpu *v);
>>> =A0 =A0 =A0void (*set_interrupt_shadow)(struct vcpu *v, unsigned int in=
tr_shadow);
>>> =A0 =A0 =A0int (*guest_x86_mode)(struct vcpu *v);
>>> =A0 =A0 =A0void (*get_segment_register)(struct vcpu *v, enum x86_segmen=
t seg,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 str=
uct segment_register *reg);
>>> =A0 =A0 =A0void (*set_segment_register)(struct vcpu *v, enum x86_segmen=
t seg,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 str=
uct segment_register *reg);
>>> +#ifdef __x86_64__
>>> + =A0 =A0unsigned long (*get_shadow_gs_base)(struct vcpu *v);
>>> +#endif
>>> =

>>> =A0 =A0 =A0/*
>>> =A0 =A0 =A0 * Re-set the value of CR3 that Xen runs on when handling VM=
 exits.
>>> =A0 =A0 =A0 */
>>> =A0 =A0 =A0void (*update_host_cr3)(struct vcpu *v);
>>> =

>>> =A0 =A0 =A0/*
>>> =A0 =A0 =A0 * Called to inform HVM layer that a guest CRn or EFER has c=
hanged.
>>> @@ -300,16 +303,23 @@ hvm_get_segment_register(struct vcpu *v,
>>> =

>>> =A0static inline void
>>> =A0hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct segment_regi=
ster *reg)
>>> =A0{
>>> =A0 =A0 =A0hvm_funcs.set_segment_register(v, seg, reg);
>>> =A0}
>>> =

>>> +#ifdef __x86_64__
>>> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
>>> +{
>>> + =A0 =A0return hvm_funcs.get_shadow_gs_base(v);
>>> +}
>>> +#endif
>>> +
>>> =A0#define is_viridian_domain(_d) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
>>> \
>>> =A0 (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRID=
IAN]))
>>> =

>>> =A0void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *=
ebx,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 unsigned int *ecx, unsigned int *edx);
>>> =A0void hvm_migrate_timers(struct vcpu *v);
>>> =A0void hvm_do_resume(struct vcpu *v);
>>> =A0void hvm_migrate_pirqs(struct vcpu *v);
>>> =

>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> =

>> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 07:15:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 07:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMwRn-0003wa-Ud; Wed, 25 Apr 2012 07:15:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMwRm-0003wV-FT
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 07:15:30 +0000
Received: from [85.158.139.83:61735] by server-10.bemta-5.messagelabs.com id
	2B/D5-08260-194A79F4; Wed, 25 Apr 2012 07:15:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335338127!25364754!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17958 invoked from network); 25 Apr 2012 07:15:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 07:15:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 08:15:26 +0100
Message-Id: <4F97C0C2020000780007FDCA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 08:15:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
	<20120424172424.GD34721@ocelot.phlegethon.org>
In-Reply-To: <20120424172424.GD34721@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] nested vmx: fix instruction decode segment
 limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 19:24, Tim Deegan <tim@xen.org> wrote:
>> @@ -342,6 +342,11 @@ static int decode_vmx_inst(struct cpu_us
>>          hvm_get_segment_register(v, sreg_to_index[info.fields.segment], &seg);
>>          seg_base = seg.base;
>>  
>> +        if ( hvm_long_mode_enabled(v) )
>> +            hvm_get_segment_register(v, x86_seg_cs, &cs);
>> +        else
>> +            memset(&cs, 0, sizeof(cs));
>> +
> 
> I found this a bit confusing - maybe you could extract the attr.fields.l
> bit into a bool here instead of zeroing the struct and extracting it later?

Okay, let me re-do that, and fold in some other adjustments I thought
of making after having sent out the patch.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 07:15:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 07:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMwRn-0003wa-Ud; Wed, 25 Apr 2012 07:15:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMwRm-0003wV-FT
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 07:15:30 +0000
Received: from [85.158.139.83:61735] by server-10.bemta-5.messagelabs.com id
	2B/D5-08260-194A79F4; Wed, 25 Apr 2012 07:15:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335338127!25364754!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17958 invoked from network); 25 Apr 2012 07:15:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 07:15:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 08:15:26 +0100
Message-Id: <4F97C0C2020000780007FDCA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 08:15:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <4F96E018020000780007FAD9@nat28.tlf.novell.com>
	<20120424172424.GD34721@ocelot.phlegethon.org>
In-Reply-To: <20120424172424.GD34721@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] nested vmx: fix instruction decode segment
 limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.04.12 at 19:24, Tim Deegan <tim@xen.org> wrote:
>> @@ -342,6 +342,11 @@ static int decode_vmx_inst(struct cpu_us
>>          hvm_get_segment_register(v, sreg_to_index[info.fields.segment], &seg);
>>          seg_base = seg.base;
>>  
>> +        if ( hvm_long_mode_enabled(v) )
>> +            hvm_get_segment_register(v, x86_seg_cs, &cs);
>> +        else
>> +            memset(&cs, 0, sizeof(cs));
>> +
> 
> I found this a bit confusing - maybe you could extract the attr.fields.l
> bit into a bool here instead of zeroing the struct and extracting it later?

Okay, let me re-do that, and fold in some other adjustments I thought
of making after having sent out the patch.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 07:48:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 07:48:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMwx9-0004DA-R4; Wed, 25 Apr 2012 07:47:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMwx8-0004D5-SS
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 07:47:55 +0000
Received: from [85.158.138.51:47968] by server-8.bemta-3.messagelabs.com id
	5B/6D-24428-A2CA79F4; Wed, 25 Apr 2012 07:47:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335340072!12665229!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15007 invoked from network); 25 Apr 2012 07:47:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 07:47:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 08:47:52 +0100
Message-Id: <4F97C85B020000780007FDE8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 08:48:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3719E22B.1__="
Cc: Tim Deegan <tim@xen.org>, Eddie Dong <eddie.dong@intel.com>
Subject: [Xen-devel] [PATCH v2] vvmx: fix instruction decode segment limit
	check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3719E22B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- no limit check for 64-bit mode (and GS: is not special in any way)
- limit check is needed in compatibility mode
- canonical address check should instead be performed for 64-bit mode
- the last accessed byte must be within limits, not the first byte past
  the accessed range
- segment base address should be ignored for 64-bit mode unless FS: or
  GS: is in use

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -336,8 +336,17 @@ static int decode_vmx_inst(struct cpu_us
     }
     else
     {
+        bool_t mode_64bit =3D 0;
+
         decode->type =3D VMX_INST_MEMREG_TYPE_MEMORY;
-        if ( info.fields.segment > 5 )
+
+        if ( hvm_long_mode_enabled(v) )
+        {
+            hvm_get_segment_register(v, x86_seg_cs, &seg);
+            mode_64bit =3D seg.attr.fields.l;
+        }
+
+        if ( info.fields.segment > VMX_SREG_GS )
             goto gp_fault;
         hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
         seg_base =3D seg.base;
@@ -355,15 +364,20 @@ static int decode_vmx_inst(struct cpu_us
         size =3D 1 << (info.fields.addr_size + 1);
=20
         offset =3D base + index * scale + disp;
-        if ( (offset > seg.limit || offset + size > seg.limit) &&
-            (!hvm_long_mode_enabled(v) || info.fields.segment =3D=3D =
VMX_SREG_GS) )
+        base =3D !mode_64bit || info.fields.segment >=3D VMX_SREG_FS ?
+               seg_base + offset : offset;
+        if ( offset + size - 1 < offset ||
+             (mode_64bit ?
+              !is_canonical_address((long)base < 0 ? base :
+                                    base + size - 1) :
+              offset + size - 1 > seg.limit) )
             goto gp_fault;
=20
         if ( poperandS !=3D NULL &&
-             hvm_copy_from_guest_virt(poperandS, seg_base + offset, size, =
0)
+             hvm_copy_from_guest_virt(poperandS, base, size, 0)
                   !=3D HVMCOPY_okay )
             return X86EMUL_EXCEPTION;
-        decode->mem =3D seg_base + offset;
+        decode->mem =3D base;
         decode->len =3D size;
     }
=20




--=__Part3719E22B.1__=
Content-Type: text/plain; name="vvmx-decode-insn.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vvmx-decode-insn.patch"

vvmx: fix instruction decode segment limit check=0A=0A- no limit check for =
64-bit mode (and GS: is not special in any way)=0A- limit check is needed =
in compatibility mode=0A- canonical address check should instead be =
performed for 64-bit mode=0A- the last accessed byte must be within =
limits, not the first byte past=0A  the accessed range=0A- segment base =
address should be ignored for 64-bit mode unless FS: or=0A  GS: is in =
use=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch=
/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ -336,8 =
+336,17 @@ static int decode_vmx_inst(struct cpu_us=0A     }=0A     =
else=0A     {=0A+        bool_t mode_64bit =3D 0;=0A+=0A         decode->ty=
pe =3D VMX_INST_MEMREG_TYPE_MEMORY;=0A-        if ( info.fields.segment > =
5 )=0A+=0A+        if ( hvm_long_mode_enabled(v) )=0A+        {=0A+        =
    hvm_get_segment_register(v, x86_seg_cs, &seg);=0A+            =
mode_64bit =3D seg.attr.fields.l;=0A+        }=0A+=0A+        if ( =
info.fields.segment > VMX_SREG_GS )=0A             goto gp_fault;=0A       =
  hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);=0A         seg_base =3D seg.base;=0A@@ -355,15 +364,20 @@ static =
int decode_vmx_inst(struct cpu_us=0A         size =3D 1 << (info.fields.add=
r_size + 1);=0A =0A         offset =3D base + index * scale + disp;=0A-    =
    if ( (offset > seg.limit || offset + size > seg.limit) &&=0A-          =
  (!hvm_long_mode_enabled(v) || info.fields.segment =3D=3D VMX_SREG_GS) =
)=0A+        base =3D !mode_64bit || info.fields.segment >=3D VMX_SREG_FS =
?=0A+               seg_base + offset : offset;=0A+        if ( offset + =
size - 1 < offset ||=0A+             (mode_64bit ?=0A+              =
!is_canonical_address((long)base < 0 ? base :=0A+                          =
          base + size - 1) :=0A+              offset + size - 1 > =
seg.limit) )=0A             goto gp_fault;=0A =0A         if ( poperandS =
!=3D NULL &&=0A-             hvm_copy_from_guest_virt(poperandS, seg_base =
+ offset, size, 0)=0A+             hvm_copy_from_guest_virt(poperandS, =
base, size, 0)=0A                   !=3D HVMCOPY_okay )=0A             =
return X86EMUL_EXCEPTION;=0A-        decode->mem =3D seg_base + offset;=0A+=
        decode->mem =3D base;=0A         decode->len =3D size;=0A     }=0A =
=0A
--=__Part3719E22B.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part3719E22B.1__=--


From xen-devel-bounces@lists.xen.org Wed Apr 25 07:48:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 07:48:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMwx9-0004DA-R4; Wed, 25 Apr 2012 07:47:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMwx8-0004D5-SS
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 07:47:55 +0000
Received: from [85.158.138.51:47968] by server-8.bemta-3.messagelabs.com id
	5B/6D-24428-A2CA79F4; Wed, 25 Apr 2012 07:47:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335340072!12665229!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15007 invoked from network); 25 Apr 2012 07:47:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 07:47:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 08:47:52 +0100
Message-Id: <4F97C85B020000780007FDE8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 08:48:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3719E22B.1__="
Cc: Tim Deegan <tim@xen.org>, Eddie Dong <eddie.dong@intel.com>
Subject: [Xen-devel] [PATCH v2] vvmx: fix instruction decode segment limit
	check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3719E22B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- no limit check for 64-bit mode (and GS: is not special in any way)
- limit check is needed in compatibility mode
- canonical address check should instead be performed for 64-bit mode
- the last accessed byte must be within limits, not the first byte past
  the accessed range
- segment base address should be ignored for 64-bit mode unless FS: or
  GS: is in use

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -336,8 +336,17 @@ static int decode_vmx_inst(struct cpu_us
     }
     else
     {
+        bool_t mode_64bit =3D 0;
+
         decode->type =3D VMX_INST_MEMREG_TYPE_MEMORY;
-        if ( info.fields.segment > 5 )
+
+        if ( hvm_long_mode_enabled(v) )
+        {
+            hvm_get_segment_register(v, x86_seg_cs, &seg);
+            mode_64bit =3D seg.attr.fields.l;
+        }
+
+        if ( info.fields.segment > VMX_SREG_GS )
             goto gp_fault;
         hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
         seg_base =3D seg.base;
@@ -355,15 +364,20 @@ static int decode_vmx_inst(struct cpu_us
         size =3D 1 << (info.fields.addr_size + 1);
=20
         offset =3D base + index * scale + disp;
-        if ( (offset > seg.limit || offset + size > seg.limit) &&
-            (!hvm_long_mode_enabled(v) || info.fields.segment =3D=3D =
VMX_SREG_GS) )
+        base =3D !mode_64bit || info.fields.segment >=3D VMX_SREG_FS ?
+               seg_base + offset : offset;
+        if ( offset + size - 1 < offset ||
+             (mode_64bit ?
+              !is_canonical_address((long)base < 0 ? base :
+                                    base + size - 1) :
+              offset + size - 1 > seg.limit) )
             goto gp_fault;
=20
         if ( poperandS !=3D NULL &&
-             hvm_copy_from_guest_virt(poperandS, seg_base + offset, size, =
0)
+             hvm_copy_from_guest_virt(poperandS, base, size, 0)
                   !=3D HVMCOPY_okay )
             return X86EMUL_EXCEPTION;
-        decode->mem =3D seg_base + offset;
+        decode->mem =3D base;
         decode->len =3D size;
     }
=20




--=__Part3719E22B.1__=
Content-Type: text/plain; name="vvmx-decode-insn.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vvmx-decode-insn.patch"

vvmx: fix instruction decode segment limit check=0A=0A- no limit check for =
64-bit mode (and GS: is not special in any way)=0A- limit check is needed =
in compatibility mode=0A- canonical address check should instead be =
performed for 64-bit mode=0A- the last accessed byte must be within =
limits, not the first byte past=0A  the accessed range=0A- segment base =
address should be ignored for 64-bit mode unless FS: or=0A  GS: is in =
use=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch=
/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ -336,8 =
+336,17 @@ static int decode_vmx_inst(struct cpu_us=0A     }=0A     =
else=0A     {=0A+        bool_t mode_64bit =3D 0;=0A+=0A         decode->ty=
pe =3D VMX_INST_MEMREG_TYPE_MEMORY;=0A-        if ( info.fields.segment > =
5 )=0A+=0A+        if ( hvm_long_mode_enabled(v) )=0A+        {=0A+        =
    hvm_get_segment_register(v, x86_seg_cs, &seg);=0A+            =
mode_64bit =3D seg.attr.fields.l;=0A+        }=0A+=0A+        if ( =
info.fields.segment > VMX_SREG_GS )=0A             goto gp_fault;=0A       =
  hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);=0A         seg_base =3D seg.base;=0A@@ -355,15 +364,20 @@ static =
int decode_vmx_inst(struct cpu_us=0A         size =3D 1 << (info.fields.add=
r_size + 1);=0A =0A         offset =3D base + index * scale + disp;=0A-    =
    if ( (offset > seg.limit || offset + size > seg.limit) &&=0A-          =
  (!hvm_long_mode_enabled(v) || info.fields.segment =3D=3D VMX_SREG_GS) =
)=0A+        base =3D !mode_64bit || info.fields.segment >=3D VMX_SREG_FS =
?=0A+               seg_base + offset : offset;=0A+        if ( offset + =
size - 1 < offset ||=0A+             (mode_64bit ?=0A+              =
!is_canonical_address((long)base < 0 ? base :=0A+                          =
          base + size - 1) :=0A+              offset + size - 1 > =
seg.limit) )=0A             goto gp_fault;=0A =0A         if ( poperandS =
!=3D NULL &&=0A-             hvm_copy_from_guest_virt(poperandS, seg_base =
+ offset, size, 0)=0A+             hvm_copy_from_guest_virt(poperandS, =
base, size, 0)=0A                   !=3D HVMCOPY_okay )=0A             =
return X86EMUL_EXCEPTION;=0A-        decode->mem =3D seg_base + offset;=0A+=
        decode->mem =3D base;=0A         decode->len =3D size;=0A     }=0A =
=0A
--=__Part3719E22B.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part3719E22B.1__=--


From xen-devel-bounces@lists.xen.org Wed Apr 25 08:07:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxFt-00054O-6f; Wed, 25 Apr 2012 08:07:17 +0000
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 1SMxFr-00054I-5h
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:07:15 +0000
Received: from [193.109.254.147:32106] by server-7.bemta-14.messagelabs.com id
	4E/18-01627-2B0B79F4; Wed, 25 Apr 2012 08:07:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335341229!6212511!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30664 invoked from network); 25 Apr 2012 08:07:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 08:07:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 09:07:08 +0100
Message-Id: <4F97CCDF020000780007FE01@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 09:07:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
	<a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 05:34, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2383,6 +2383,8 @@ static enum hvm_copy_result __hvm_copy(
> 
>      while ( todo > 0 )
>      {
> +        struct page_info *pg;
> +
>          count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);
> 
>          if ( flags & HVMCOPY_virt )
> @@ -2427,7 +2429,11 @@ static enum hvm_copy_result __hvm_copy(
>              put_gfn(curr->domain, gfn);
>              return HVMCOPY_bad_gfn_to_mfn;
>          }
> +
>          ASSERT(mfn_valid(mfn));
> +        pg = mfn_to_page(mfn);
> +        ASSERT(get_page(pg, curr->domain));

You really shouldn't ever put expressions with (side) effects inside
an ASSERT(), not even for debugging patches that you want others
to apply (you're of course free to shoot yourself in the foot ;-) ), as
it just won't work in non-debug builds.

Jan

> +        put_gfn(curr->domain, gfn);
> 
>          p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
> 
> @@ -2457,7 +2463,7 @@ static enum hvm_copy_result __hvm_copy(
>          addr += count;
>          buf  += count;
>          todo -= count;
> -        put_gfn(curr->domain, gfn);
> +        put_page(pg);
>      }
> 
>      return HVMCOPY_okay;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:07:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxFt-00054O-6f; Wed, 25 Apr 2012 08:07:17 +0000
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 1SMxFr-00054I-5h
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:07:15 +0000
Received: from [193.109.254.147:32106] by server-7.bemta-14.messagelabs.com id
	4E/18-01627-2B0B79F4; Wed, 25 Apr 2012 08:07:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335341229!6212511!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30664 invoked from network); 25 Apr 2012 08:07:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 08:07:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 09:07:08 +0100
Message-Id: <4F97CCDF020000780007FE01@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 09:07:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <20120419082717.GA23663@ocelot.phlegethon.org>
	<CBB58FB0.3E7AC%keir@xen.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<b65c34db6bcef99fac6d7d7bc4af9a5f.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F470B@SHSMSX101.ccr.corp.intel.com>
	<a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <a863787388757514144b4e8896f03d31.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 05:34, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2383,6 +2383,8 @@ static enum hvm_copy_result __hvm_copy(
> 
>      while ( todo > 0 )
>      {
> +        struct page_info *pg;
> +
>          count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);
> 
>          if ( flags & HVMCOPY_virt )
> @@ -2427,7 +2429,11 @@ static enum hvm_copy_result __hvm_copy(
>              put_gfn(curr->domain, gfn);
>              return HVMCOPY_bad_gfn_to_mfn;
>          }
> +
>          ASSERT(mfn_valid(mfn));
> +        pg = mfn_to_page(mfn);
> +        ASSERT(get_page(pg, curr->domain));

You really shouldn't ever put expressions with (side) effects inside
an ASSERT(), not even for debugging patches that you want others
to apply (you're of course free to shoot yourself in the foot ;-) ), as
it just won't work in non-debug builds.

Jan

> +        put_gfn(curr->domain, gfn);
> 
>          p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
> 
> @@ -2457,7 +2463,7 @@ static enum hvm_copy_result __hvm_copy(
>          addr += count;
>          buf  += count;
>          todo -= count;
> -        put_gfn(curr->domain, gfn);
> +        put_page(pg);
>      }
> 
>      return HVMCOPY_okay;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:08:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:08:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxH0-00059T-Uq; Wed, 25 Apr 2012 08:08:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMxGz-00059H-6d
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:08:25 +0000
Received: from [85.158.139.83:61312] by server-9.bemta-5.messagelabs.com id
	71/F3-09826-8F0B79F4; Wed, 25 Apr 2012 08:08:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335341303!25301977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9791 invoked from network); 25 Apr 2012 08:08:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:08:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12123545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:07:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:07:43 +0100
Message-ID: <1335341262.4881.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:07:42 +0100
In-Reply-To: <20374.57450.417199.89376@mariner.uk.xensource.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> > 
> > Pass PYTHON down to seabios, so seabios will
> > use same python binary as whole xen tree does.
> > Fixes build error on NetBSD.
> 
> Ian, does this look sensible to you ?

It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
is OK, so we might as well take this now.

Does
subdirs-seabios: PYTHON=$(PYTHON)
(or something similar) work? Might be a better option in the future

> 
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> > 
> > ----------------------------------------------------------------------
> > diff -r ab552da976a3 tools/firmware/Makefile
> > --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> > +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> > @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >  	false ; \
> >  	fi
> >  endif
> > -	$(MAKE) subdirs-$@
> > +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >  
> >  
> >  .PHONY: install
> > 
> > ----------------------------------------------------------------------
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:08:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:08:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxH0-00059T-Uq; Wed, 25 Apr 2012 08:08:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMxGz-00059H-6d
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:08:25 +0000
Received: from [85.158.139.83:61312] by server-9.bemta-5.messagelabs.com id
	71/F3-09826-8F0B79F4; Wed, 25 Apr 2012 08:08:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335341303!25301977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9791 invoked from network); 25 Apr 2012 08:08:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:08:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12123545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:07:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:07:43 +0100
Message-ID: <1335341262.4881.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:07:42 +0100
In-Reply-To: <20374.57450.417199.89376@mariner.uk.xensource.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> > 
> > Pass PYTHON down to seabios, so seabios will
> > use same python binary as whole xen tree does.
> > Fixes build error on NetBSD.
> 
> Ian, does this look sensible to you ?

It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
is OK, so we might as well take this now.

Does
subdirs-seabios: PYTHON=$(PYTHON)
(or something similar) work? Might be a better option in the future

> 
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> > 
> > ----------------------------------------------------------------------
> > diff -r ab552da976a3 tools/firmware/Makefile
> > --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> > +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> > @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >  	false ; \
> >  	fi
> >  endif
> > -	$(MAKE) subdirs-$@
> > +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >  
> >  
> >  .PHONY: install
> > 
> > ----------------------------------------------------------------------
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:11:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxJz-0005NL-Ho; Wed, 25 Apr 2012 08:11:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMxJy-0005N7-7T
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:11:30 +0000
Received: from [193.109.254.147:42105] by server-1.bemta-14.messagelabs.com id
	AC/8D-29372-1B1B79F4; Wed, 25 Apr 2012 08:11:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335341488!6211788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 344 invoked from network); 25 Apr 2012 08:11:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:11:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12123656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:11:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:11:28 +0100
Message-ID: <1335341487.4881.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:11:27 +0100
In-Reply-To: <20374.59769.738590.656156@mariner.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
	<20374.59769.738590.656156@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 18:57 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> > RFC: libxl: move definition of libxl_domain_config into the IDL
> > 
> > This requires adding a new Array type to the IDL.
> > 
> > DO NOT APPLY. This is 4.3 material.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> > +  idl.Array.len_var contains an idl.Field which is added to the parent
> > +  idl.Aggregate and will contain the length of the array.
> 
> Why does the Array not automatically invent a "num_<foo>" field ?
> Surely there is no benefit to having non-systematically named (or
> typed) array count fields ?

That would be good but currently the Array type doesn't see the name of
the member in the containing struct:
Struct("thing", [
	("disks", Array(libxl_device_disk, "num_disks")),
])

We have a similar problem with the KeyedUnion which similarly ought to
be able to at least default keyvar_name to something.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:11:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxJz-0005NL-Ho; Wed, 25 Apr 2012 08:11:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMxJy-0005N7-7T
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:11:30 +0000
Received: from [193.109.254.147:42105] by server-1.bemta-14.messagelabs.com id
	AC/8D-29372-1B1B79F4; Wed, 25 Apr 2012 08:11:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335341488!6211788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 344 invoked from network); 25 Apr 2012 08:11:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:11:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12123656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:11:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:11:28 +0100
Message-ID: <1335341487.4881.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:11:27 +0100
In-Reply-To: <20374.59769.738590.656156@mariner.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
	<20374.59769.738590.656156@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 18:57 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> > RFC: libxl: move definition of libxl_domain_config into the IDL
> > 
> > This requires adding a new Array type to the IDL.
> > 
> > DO NOT APPLY. This is 4.3 material.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> > +  idl.Array.len_var contains an idl.Field which is added to the parent
> > +  idl.Aggregate and will contain the length of the array.
> 
> Why does the Array not automatically invent a "num_<foo>" field ?
> Surely there is no benefit to having non-systematically named (or
> typed) array count fields ?

That would be good but currently the Array type doesn't see the name of
the member in the containing struct:
Struct("thing", [
	("disks", Array(libxl_device_disk, "num_disks")),
])

We have a similar problem with the KeyedUnion which similarly ought to
be able to at least default keyvar_name to something.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxbK-0005hk-GE; Wed, 25 Apr 2012 08:29:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMxbJ-0005hf-GG
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:29:25 +0000
Received: from [85.158.139.83:58829] by server-10.bemta-5.messagelabs.com id
	5B/DF-08260-4E5B79F4; Wed, 25 Apr 2012 08:29:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335342563!25306000!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15550 invoked from network); 25 Apr 2012 08:29:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 08:29:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMxbF-000DNR-OS; Wed, 25 Apr 2012 08:29:21 +0000
Date: Wed, 25 Apr 2012 09:29:21 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120425082921.GA51354@ocelot.phlegethon.org>
References: <4F97C85B020000780007FDE8@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F97C85B020000780007FDE8@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] vvmx: fix instruction decode segment
	limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:48 +0100 on 25 Apr (1335343691), Jan Beulich wrote:
> - no limit check for 64-bit mode (and GS: is not special in any way)
> - limit check is needed in compatibility mode
> - canonical address check should instead be performed for 64-bit mode
> - the last accessed byte must be within limits, not the first byte past
>   the accessed range
> - segment base address should be ignored for 64-bit mode unless FS: or
>   GS: is in use
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Much clearer, thanks.

Acked-by: Tim Deegan <tim@xen.org>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxbK-0005hk-GE; Wed, 25 Apr 2012 08:29:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SMxbJ-0005hf-GG
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:29:25 +0000
Received: from [85.158.139.83:58829] by server-10.bemta-5.messagelabs.com id
	5B/DF-08260-4E5B79F4; Wed, 25 Apr 2012 08:29:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335342563!25306000!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15550 invoked from network); 25 Apr 2012 08:29:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 08:29:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SMxbF-000DNR-OS; Wed, 25 Apr 2012 08:29:21 +0000
Date: Wed, 25 Apr 2012 09:29:21 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120425082921.GA51354@ocelot.phlegethon.org>
References: <4F97C85B020000780007FDE8@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F97C85B020000780007FDE8@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] vvmx: fix instruction decode segment
	limit check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:48 +0100 on 25 Apr (1335343691), Jan Beulich wrote:
> - no limit check for 64-bit mode (and GS: is not special in any way)
> - limit check is needed in compatibility mode
> - canonical address check should instead be performed for 64-bit mode
> - the last accessed byte must be within limits, not the first byte past
>   the accessed range
> - segment base address should be ignored for 64-bit mode unless FS: or
>   GS: is in use
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Much clearer, thanks.

Acked-by: Tim Deegan <tim@xen.org>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:37:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxif-0005qr-Dm; Wed, 25 Apr 2012 08:37:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMxid-0005qm-9S
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:36:59 +0000
Received: from [85.158.143.35:8536] by server-2.bemta-4.messagelabs.com id
	C2/6E-17550-AA7B79F4; Wed, 25 Apr 2012 08:36:58 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335343016!14825341!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27212 invoked from network); 25 Apr 2012 08:36:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191950398"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 04:36:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 04:36:56 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMxia-0004sS-0u;
	Wed, 25 Apr 2012 09:36:56 +0100
Message-ID: <4F97B7AB.50400@citrix.com>
Date: Wed, 25 Apr 2012 09:36:59 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
In-Reply-To: <20374.60449.668898.21825@mariner.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[PATCH v2] libxl: prevent xl from running if xen=
d is running."):
>> Prevent xl from doing any operation if xend daemon is running. That
>> prevents bugs that happened when xl and xend raced to close a domain.
>
> Thanks, but I'm afraid this needs a refresh.  I recommend you wait
> until tomorrow.  I'm nearly at the end of my huge queue...

Do you mean that the code doesn't apply cleanly, or a refresh in the =

commit message?

In the lists of changes I've added the fact that now you are able to run =

commands that doesn't modify anything.

Thanks, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:37:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:37:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxif-0005qr-Dm; Wed, 25 Apr 2012 08:37:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMxid-0005qm-9S
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:36:59 +0000
Received: from [85.158.143.35:8536] by server-2.bemta-4.messagelabs.com id
	C2/6E-17550-AA7B79F4; Wed, 25 Apr 2012 08:36:58 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335343016!14825341!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY0NjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27212 invoked from network); 25 Apr 2012 08:36:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191950398"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 04:36:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 04:36:56 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMxia-0004sS-0u;
	Wed, 25 Apr 2012 09:36:56 +0100
Message-ID: <4F97B7AB.50400@citrix.com>
Date: Wed, 25 Apr 2012 09:36:59 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
In-Reply-To: <20374.60449.668898.21825@mariner.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[PATCH v2] libxl: prevent xl from running if xen=
d is running."):
>> Prevent xl from doing any operation if xend daemon is running. That
>> prevents bugs that happened when xl and xend raced to close a domain.
>
> Thanks, but I'm afraid this needs a refresh.  I recommend you wait
> until tomorrow.  I'm nearly at the end of my huge queue...

Do you mean that the code doesn't apply cleanly, or a refresh in the =

commit message?

In the lists of changes I've added the fact that now you are able to run =

commands that doesn't modify anything.

Thanks, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:41:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxmf-0005z1-3R; Wed, 25 Apr 2012 08:41:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMxmd-0005yw-T8
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:41:08 +0000
Received: from [193.109.254.147:22579] by server-8.bemta-14.messagelabs.com id
	13/4B-23244-3A8B79F4; Wed, 25 Apr 2012 08:41:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335343266!3753868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10089 invoked from network); 25 Apr 2012 08:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12124714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:41:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 09:41:06 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMxmb-0004R8-UD;
	Wed, 25 Apr 2012 08:41:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMxmb-0006yc-TY;
	Wed, 25 Apr 2012 09:41:05 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12746-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:41:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12746: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12746 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12746/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 12744
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12744
 test-amd64-amd64-xl           9 guest-start        fail in 12744 pass in 12746
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12744 pass in 12746

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12741

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12744 never pass

version targeted for testing:
 xen                  99517f769cc8
baseline version:
 xen                  f5f1e6ef9782

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=99517f769cc8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 99517f769cc8
+ branch=xen-4.1-testing
+ revision=99517f769cc8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 99517f769cc8 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:41:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxmf-0005z1-3R; Wed, 25 Apr 2012 08:41:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMxmd-0005yw-T8
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:41:08 +0000
Received: from [193.109.254.147:22579] by server-8.bemta-14.messagelabs.com id
	13/4B-23244-3A8B79F4; Wed, 25 Apr 2012 08:41:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335343266!3753868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10089 invoked from network); 25 Apr 2012 08:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12124714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:41:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 09:41:06 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SMxmb-0004R8-UD;
	Wed, 25 Apr 2012 08:41:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SMxmb-0006yc-TY;
	Wed, 25 Apr 2012 09:41:05 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12746-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:41:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12746: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12746 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12746/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 12744
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12744
 test-amd64-amd64-xl           9 guest-start        fail in 12744 pass in 12746
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12744 pass in 12746

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12741

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12744 never pass

version targeted for testing:
 xen                  99517f769cc8
baseline version:
 xen                  f5f1e6ef9782

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=99517f769cc8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 99517f769cc8
+ branch=xen-4.1-testing
+ revision=99517f769cc8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 99517f769cc8 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:44:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxpR-00065X-MS; Wed, 25 Apr 2012 08:44:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMxpQ-00065O-BS
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:44:00 +0000
Received: from [85.158.143.99:31893] by server-3.bemta-4.messagelabs.com id
	89/6C-05853-F49B79F4; Wed, 25 Apr 2012 08:43:59 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335343437!13966291!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27384 invoked from network); 25 Apr 2012 08:43:58 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-16.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 08:43:58 -0000
Received: from mail16-va3-R.bigfish.com (10.7.14.239) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 08:43:56 +0000
Received: from mail16-va3 (localhost [127.0.0.1])	by mail16-va3-R.bigfish.com
	(Postfix) with ESMTP id 6E3F616054B;
	Wed, 25 Apr 2012 08:43:56 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail16-va3 (localhost.localdomain [127.0.0.1]) by mail16-va3
	(MessageSwitch) id 1335343434458314_20613;
	Wed, 25 Apr 2012 08:43:54 +0000 (UTC)
Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.248])	by
	mail16-va3.bigfish.com (Postfix) with ESMTP id 5F7FD40050;
	Wed, 25 Apr 2012 08:43:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 08:43:53 +0000
X-WSS-ID: 0M311L1-02-0VJ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25CBEC80D4;	Wed, 25 Apr 2012 03:43:48 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 03:44:26 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 25 Apr 2012 03:43:51 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	04:43:46 -0400
Message-ID: <4F97B941.7000108@amd.com>
Date: Wed, 25 Apr 2012 10:43:45 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
In-Reply-To: <1335341262.4881.15.camel@dagon.hellion.org.uk>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 10:07, Ian Campbell wrote:

> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>
>>> Pass PYTHON down to seabios, so seabios will
>>> use same python binary as whole xen tree does.
>>> Fixes build error on NetBSD.
>>
>> Ian, does this look sensible to you ?
> 
> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> is OK, so we might as well take this now.


Thanks.

 

> Does
> subdirs-seabios: PYTHON=$(PYTHON)
> (or something similar) work? Might be a better option in the future


No, this doesn't work.

> 
>>
>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
>>>
>>> ----------------------------------------------------------------------
>>> diff -r ab552da976a3 tools/firmware/Makefile
>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>  	false ; \
>>>  	fi
>>>  endif
>>> -	$(MAKE) subdirs-$@
>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>  
>>>  
>>>  .PHONY: install
>>>
>>> ----------------------------------------------------------------------
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:44:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxpR-00065X-MS; Wed, 25 Apr 2012 08:44:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMxpQ-00065O-BS
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:44:00 +0000
Received: from [85.158.143.99:31893] by server-3.bemta-4.messagelabs.com id
	89/6C-05853-F49B79F4; Wed, 25 Apr 2012 08:43:59 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335343437!13966291!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27384 invoked from network); 25 Apr 2012 08:43:58 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-16.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 08:43:58 -0000
Received: from mail16-va3-R.bigfish.com (10.7.14.239) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 08:43:56 +0000
Received: from mail16-va3 (localhost [127.0.0.1])	by mail16-va3-R.bigfish.com
	(Postfix) with ESMTP id 6E3F616054B;
	Wed, 25 Apr 2012 08:43:56 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail16-va3 (localhost.localdomain [127.0.0.1]) by mail16-va3
	(MessageSwitch) id 1335343434458314_20613;
	Wed, 25 Apr 2012 08:43:54 +0000 (UTC)
Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.248])	by
	mail16-va3.bigfish.com (Postfix) with ESMTP id 5F7FD40050;
	Wed, 25 Apr 2012 08:43:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 08:43:53 +0000
X-WSS-ID: 0M311L1-02-0VJ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25CBEC80D4;	Wed, 25 Apr 2012 03:43:48 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 03:44:26 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 25 Apr 2012 03:43:51 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	04:43:46 -0400
Message-ID: <4F97B941.7000108@amd.com>
Date: Wed, 25 Apr 2012 10:43:45 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
In-Reply-To: <1335341262.4881.15.camel@dagon.hellion.org.uk>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 10:07, Ian Campbell wrote:

> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>
>>> Pass PYTHON down to seabios, so seabios will
>>> use same python binary as whole xen tree does.
>>> Fixes build error on NetBSD.
>>
>> Ian, does this look sensible to you ?
> 
> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> is OK, so we might as well take this now.


Thanks.

 

> Does
> subdirs-seabios: PYTHON=$(PYTHON)
> (or something similar) work? Might be a better option in the future


No, this doesn't work.

> 
>>
>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
>>>
>>> ----------------------------------------------------------------------
>>> diff -r ab552da976a3 tools/firmware/Makefile
>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>  	false ; \
>>>  	fi
>>>  endif
>>> -	$(MAKE) subdirs-$@
>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>  
>>>  
>>>  .PHONY: install
>>>
>>> ----------------------------------------------------------------------
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:45:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:45:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxqq-0006BT-6E; Wed, 25 Apr 2012 08:45:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <hch@lst.de>)
	id 1SMxqo-0006BL-IJ
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:45:26 +0000
Received: from [85.158.138.51:63858] by server-9.bemta-3.messagelabs.com id
	90/A4-26691-5A9B79F4; Wed, 25 Apr 2012 08:45:25 +0000
X-Env-Sender: hch@lst.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335343524!15753859!1
X-Originating-IP: [213.95.11.211]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18598 invoked from network); 25 Apr 2012 08:45:24 -0000
Received: from verein.lst.de (HELO newverein.lst.de) (213.95.11.211)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 08:45:24 -0000
Received: by newverein.lst.de (Postfix, from userid 2407)
	id 5FFE8AAA83; Wed, 25 Apr 2012 10:45:24 +0200 (CEST)
Date: Wed, 25 Apr 2012 10:45:24 +0200
From: Christoph Hellwig <hch@lst.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120425084524.GA17537@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:
	implement	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -    case BLKIF_OP_WRITE_BARRIER:
> +    case BLKIF_OP_FLUSH_DISKCACHE:
>          if (!ioreq->req.nr_segments) {
>              ioreq->presync = 1;
>              return 0;
>          }
> -        ioreq->presync = ioreq->postsync = 1;
> +        ioreq->postsync = 1;
>          /* fall through */

It might be worth documenting the semantics of BLKIF_OP_FLUSH_DISKCACHE
in a comment here.  I haven't found any spec for the xen_disk protocol,
but from looking at the Linux frontend it seems like the semantics
of REQ_FLUSH and REQ_FUA in the Linux block driver are overloaded into
BLKIF_OP_FLUSH_DISKCACHE, which is fairly confusing given that REQ_FLUSH
already overload functionality.

Even worse REQ_FLUSH with a payload implies a preflush, while REQ_FUA
implies a post flush, and it seems like Xen has no way to distinguish
the two, making thing like log writes very inefficient.

Independent of that the implementation should really use a state machine
around bdrv_aio_flush instead of doing guest-sychronous bdrv_flush calls.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:45:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:45:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxqq-0006BT-6E; Wed, 25 Apr 2012 08:45:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <hch@lst.de>)
	id 1SMxqo-0006BL-IJ
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:45:26 +0000
Received: from [85.158.138.51:63858] by server-9.bemta-3.messagelabs.com id
	90/A4-26691-5A9B79F4; Wed, 25 Apr 2012 08:45:25 +0000
X-Env-Sender: hch@lst.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335343524!15753859!1
X-Originating-IP: [213.95.11.211]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18598 invoked from network); 25 Apr 2012 08:45:24 -0000
Received: from verein.lst.de (HELO newverein.lst.de) (213.95.11.211)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 08:45:24 -0000
Received: by newverein.lst.de (Postfix, from userid 2407)
	id 5FFE8AAA83; Wed, 25 Apr 2012 10:45:24 +0200 (CEST)
Date: Wed, 25 Apr 2012 10:45:24 +0200
From: Christoph Hellwig <hch@lst.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120425084524.GA17537@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:
	implement	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -    case BLKIF_OP_WRITE_BARRIER:
> +    case BLKIF_OP_FLUSH_DISKCACHE:
>          if (!ioreq->req.nr_segments) {
>              ioreq->presync = 1;
>              return 0;
>          }
> -        ioreq->presync = ioreq->postsync = 1;
> +        ioreq->postsync = 1;
>          /* fall through */

It might be worth documenting the semantics of BLKIF_OP_FLUSH_DISKCACHE
in a comment here.  I haven't found any spec for the xen_disk protocol,
but from looking at the Linux frontend it seems like the semantics
of REQ_FLUSH and REQ_FUA in the Linux block driver are overloaded into
BLKIF_OP_FLUSH_DISKCACHE, which is fairly confusing given that REQ_FLUSH
already overload functionality.

Even worse REQ_FLUSH with a payload implies a preflush, while REQ_FUA
implies a post flush, and it seems like Xen has no way to distinguish
the two, making thing like log writes very inefficient.

Independent of that the implementation should really use a state machine
around bdrv_aio_flush instead of doing guest-sychronous bdrv_flush calls.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:53:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxxq-0006T7-8I; Wed, 25 Apr 2012 08:52:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMxxp-0006T2-0e
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:52:41 +0000
Received: from [85.158.143.99:60515] by server-1.bemta-4.messagelabs.com id
	6D/BB-20925-85BB79F4; Wed, 25 Apr 2012 08:52:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335343959!17638771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29353 invoked from network); 25 Apr 2012 08:52:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12124993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:52:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:52:38 +0100
Message-ID: <1335343957.28015.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 25 Apr 2012 09:52:37 +0100
In-Reply-To: <4F97B941.7000108@amd.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
> On 04/25/12 10:07, Ian Campbell wrote:
> 
> > On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> >> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> >>>
> >>> Pass PYTHON down to seabios, so seabios will
> >>> use same python binary as whole xen tree does.
> >>> Fixes build error on NetBSD.
> >>
> >> Ian, does this look sensible to you ?
> > 
> > It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> > is OK, so we might as well take this now.
> 
> 
> Thanks.
> 
>  
> 
> > Does
> > subdirs-seabios: PYTHON=$(PYTHON)
> > (or something similar) work? Might be a better option in the future
> 
> 
> No, this doesn't work.

What about
subdir-all-seabios: PYTHON=...
?

> 
> > 
> >>
> >>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> >>>
> >>> ----------------------------------------------------------------------
> >>> diff -r ab552da976a3 tools/firmware/Makefile
> >>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> >>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> >>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >>>  	false ; \
> >>>  	fi
> >>>  endif
> >>> -	$(MAKE) subdirs-$@
> >>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >>>  
> >>>  
> >>>  .PHONY: install
> >>>
> >>> ----------------------------------------------------------------------
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> > 
> > 
> > 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:53:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMxxq-0006T7-8I; Wed, 25 Apr 2012 08:52:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMxxp-0006T2-0e
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:52:41 +0000
Received: from [85.158.143.99:60515] by server-1.bemta-4.messagelabs.com id
	6D/BB-20925-85BB79F4; Wed, 25 Apr 2012 08:52:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335343959!17638771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29353 invoked from network); 25 Apr 2012 08:52:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12124993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:52:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:52:38 +0100
Message-ID: <1335343957.28015.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 25 Apr 2012 09:52:37 +0100
In-Reply-To: <4F97B941.7000108@amd.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
> On 04/25/12 10:07, Ian Campbell wrote:
> 
> > On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> >> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> >>>
> >>> Pass PYTHON down to seabios, so seabios will
> >>> use same python binary as whole xen tree does.
> >>> Fixes build error on NetBSD.
> >>
> >> Ian, does this look sensible to you ?
> > 
> > It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> > is OK, so we might as well take this now.
> 
> 
> Thanks.
> 
>  
> 
> > Does
> > subdirs-seabios: PYTHON=$(PYTHON)
> > (or something similar) work? Might be a better option in the future
> 
> 
> No, this doesn't work.

What about
subdir-all-seabios: PYTHON=...
?

> 
> > 
> >>
> >>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> >>>
> >>> ----------------------------------------------------------------------
> >>> diff -r ab552da976a3 tools/firmware/Makefile
> >>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> >>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> >>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >>>  	false ; \
> >>>  	fi
> >>>  endif
> >>> -	$(MAKE) subdirs-$@
> >>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >>>  
> >>>  
> >>>  .PHONY: install
> >>>
> >>> ----------------------------------------------------------------------
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> > 
> > 
> > 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:57:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMy2E-0006ai-N7; Wed, 25 Apr 2012 08:57:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMy2D-0006ad-Ty
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:57:14 +0000
Received: from [85.158.138.51:64333] by server-6.bemta-3.messagelabs.com id
	53/0A-05145-96CB79F4; Wed, 25 Apr 2012 08:57:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335344232!23599179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28462 invoked from network); 25 Apr 2012 08:57:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:57:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:57:11 +0100
Message-ID: <1335344230.28015.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:57:10 +0100
In-Reply-To: <20374.59820.578074.902872@mariner.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
	<20374.59820.578074.902872@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: provide
 libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 18:58 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> > libxl: provide libxl_domain_config_init.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Oops, I had an update which I'd forgotten to send out -- this is the
delta, Sorry.

8<----------------------------------------------------


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335344197 -3600
# Node ID bc54fd8d21b4bd50dc365905aff2f2eac7ac0807
# Parent  b27dc6eecfe794fe1bed6d1188a71853818d77e9
libxl: use libxl_domain_config_init and not memset 0

I missed a couple of memsets in 25237:31489be80c51, we need to use
libxl_domain_config_init everywhere and not memset since not all fields are
initialised to zero now (the type field in particular). This fixes an abort
with "xl list <dom>" for a specific domain due to assert(type == -1) in
libxl_domain_build_info_init_type().


Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b27dc6eecfe7 -r bc54fd8d21b4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Apr 25 09:54:39 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Apr 25 09:56:37 2012 +0100
@@ -2464,7 +2464,7 @@ static void list_domains_details(const l
         if (rc)
             continue;
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
-        memset(&d_config, 0x00, sizeof(d_config));
+        libxl_domain_config_init(&d_config);
         parse_config_data(config_file, (char *)data, len, &d_config);
         printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
@@ -3546,7 +3546,7 @@ int main_config_update(int argc, char **
         exit(1);
     }
 
-    memset(&d_config, 0x00, sizeof(d_config));
+    libxl_domain_config_init(&d_config);
 
     parse_config_data(filename, config_data, config_len, &d_config);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 08:57:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 08:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMy2E-0006ai-N7; Wed, 25 Apr 2012 08:57:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMy2D-0006ad-Ty
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 08:57:14 +0000
Received: from [85.158.138.51:64333] by server-6.bemta-3.messagelabs.com id
	53/0A-05145-96CB79F4; Wed, 25 Apr 2012 08:57:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335344232!23599179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjAzNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28462 invoked from network); 25 Apr 2012 08:57:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 08:57:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:57:11 +0100
Message-ID: <1335344230.28015.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 09:57:10 +0100
In-Reply-To: <20374.59820.578074.902872@mariner.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
	<20374.59820.578074.902872@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: provide
 libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 18:58 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> > libxl: provide libxl_domain_config_init.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Oops, I had an update which I'd forgotten to send out -- this is the
delta, Sorry.

8<----------------------------------------------------


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335344197 -3600
# Node ID bc54fd8d21b4bd50dc365905aff2f2eac7ac0807
# Parent  b27dc6eecfe794fe1bed6d1188a71853818d77e9
libxl: use libxl_domain_config_init and not memset 0

I missed a couple of memsets in 25237:31489be80c51, we need to use
libxl_domain_config_init everywhere and not memset since not all fields are
initialised to zero now (the type field in particular). This fixes an abort
with "xl list <dom>" for a specific domain due to assert(type == -1) in
libxl_domain_build_info_init_type().


Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b27dc6eecfe7 -r bc54fd8d21b4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Apr 25 09:54:39 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Apr 25 09:56:37 2012 +0100
@@ -2464,7 +2464,7 @@ static void list_domains_details(const l
         if (rc)
             continue;
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
-        memset(&d_config, 0x00, sizeof(d_config));
+        libxl_domain_config_init(&d_config);
         parse_config_data(config_file, (char *)data, len, &d_config);
         printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
@@ -3546,7 +3546,7 @@ int main_config_update(int argc, char **
         exit(1);
     }
 
-    memset(&d_config, 0x00, sizeof(d_config));
+    libxl_domain_config_init(&d_config);
 
     parse_config_data(filename, config_data, config_len, &d_config);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:03:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMy7d-0006nt-Ot; Wed, 25 Apr 2012 09:02:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMy7c-0006nn-BR
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 09:02:48 +0000
Received: from [193.109.254.147:36659] by server-12.bemta-14.messagelabs.com
	id E4/E6-05898-7BDB79F4; Wed, 25 Apr 2012 09:02:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335344567!6199442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13236 invoked from network); 25 Apr 2012 09:02:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125311"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:02:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:02:46 +0100
Message-ID: <1335344565.28015.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Hellwig <hch@lst.de>
Date: Wed, 25 Apr 2012 10:02:45 +0100
In-Reply-To: <20120425084524.GA17537@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:	implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 09:45 +0100, Christoph Hellwig wrote:
> > -    case BLKIF_OP_WRITE_BARRIER:
> > +    case BLKIF_OP_FLUSH_DISKCACHE:
> >          if (!ioreq->req.nr_segments) {
> >              ioreq->presync = 1;
> >              return 0;
> >          }
> > -        ioreq->presync = ioreq->postsync = 1;
> > +        ioreq->postsync = 1;
> >          /* fall through */
> 
> It might be worth documenting the semantics of BLKIF_OP_FLUSH_DISKCACHE
> in a comment here.  I haven't found any spec for the xen_disk protocol,

The blkif spec was recently much improved, you can find it at
http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html

TBH I'm not sure it actually answers your questions wrt
BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
improving it.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:03:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMy7d-0006nt-Ot; Wed, 25 Apr 2012 09:02:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMy7c-0006nn-BR
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 09:02:48 +0000
Received: from [193.109.254.147:36659] by server-12.bemta-14.messagelabs.com
	id E4/E6-05898-7BDB79F4; Wed, 25 Apr 2012 09:02:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335344567!6199442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13236 invoked from network); 25 Apr 2012 09:02:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125311"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:02:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:02:46 +0100
Message-ID: <1335344565.28015.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Hellwig <hch@lst.de>
Date: Wed, 25 Apr 2012 10:02:45 +0100
In-Reply-To: <20120425084524.GA17537@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:	implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 09:45 +0100, Christoph Hellwig wrote:
> > -    case BLKIF_OP_WRITE_BARRIER:
> > +    case BLKIF_OP_FLUSH_DISKCACHE:
> >          if (!ioreq->req.nr_segments) {
> >              ioreq->presync = 1;
> >              return 0;
> >          }
> > -        ioreq->presync = ioreq->postsync = 1;
> > +        ioreq->postsync = 1;
> >          /* fall through */
> 
> It might be worth documenting the semantics of BLKIF_OP_FLUSH_DISKCACHE
> in a comment here.  I haven't found any spec for the xen_disk protocol,

The blkif spec was recently much improved, you can find it at
http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html

TBH I'm not sure it actually answers your questions wrt
BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
improving it.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:07:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:07:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyBp-0006vb-Fm; Wed, 25 Apr 2012 09:07:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyBn-0006vT-BM
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:07:07 +0000
Received: from [193.109.254.147:43057] by server-2.bemta-14.messagelabs.com id
	E2/04-19409-ABEB79F4; Wed, 25 Apr 2012 09:07:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335344826!3750806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11974 invoked from network); 25 Apr 2012 09:07:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:07:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:07:05 +0100
Message-ID: <1335344824.28015.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Wed, 25 Apr 2012 10:07:04 +0100
In-Reply-To: <20120424193524.GA20565@bloms.de>
References: <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
	<20120424182633.GA20286@bloms.de> <20120424193524.GA20565@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 20:35 +0100, Dieter Bloms wrote:
> Hi,
> 
> On Tue, Apr 24, Dieter Bloms wrote:
> 
> > Hi,
> > 
> > On Tue, Apr 24, Ian Jackson wrote:
> > 
> > > Perhaps it would be better to have a single sched_params struct which
> > > contained all the parameters needed for any scheduler, and simply have
> > > them ignored by libxl for schedulers we're not using.
> 
> ...
> 
> > Anyway I think it is a good design to have one struct with all parameters
> > and I'am willing to implement it.
> 
> I've made a new patch.
> Maybe it fit all your needs.

Thanks, this patch look good to me, I'll leave it to IanJ to decide
which approach he prefers.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:07:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:07:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyBp-0006vb-Fm; Wed, 25 Apr 2012 09:07:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyBn-0006vT-BM
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:07:07 +0000
Received: from [193.109.254.147:43057] by server-2.bemta-14.messagelabs.com id
	E2/04-19409-ABEB79F4; Wed, 25 Apr 2012 09:07:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335344826!3750806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11974 invoked from network); 25 Apr 2012 09:07:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:07:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:07:05 +0100
Message-ID: <1335344824.28015.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Wed, 25 Apr 2012 10:07:04 +0100
In-Reply-To: <20120424193524.GA20565@bloms.de>
References: <20120423193518.GA16134@bloms.de>
	<1335247525.2397.4.camel@Abyss> <20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
	<20120424182633.GA20286@bloms.de> <20120424193524.GA20565@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 20:35 +0100, Dieter Bloms wrote:
> Hi,
> 
> On Tue, Apr 24, Dieter Bloms wrote:
> 
> > Hi,
> > 
> > On Tue, Apr 24, Ian Jackson wrote:
> > 
> > > Perhaps it would be better to have a single sched_params struct which
> > > contained all the parameters needed for any scheduler, and simply have
> > > them ignored by libxl for schedulers we're not using.
> 
> ...
> 
> > Anyway I think it is a good design to have one struct with all parameters
> > and I'am willing to implement it.
> 
> I've made a new patch.
> Maybe it fit all your needs.

Thanks, this patch look good to me, I'll leave it to IanJ to decide
which approach he prefers.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:09:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyE5-00072m-0I; Wed, 25 Apr 2012 09:09:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyE4-00072g-1D
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:09:28 +0000
Received: from [85.158.143.35:16355] by server-1.bemta-4.messagelabs.com id
	D4/6C-20925-74FB79F4; Wed, 25 Apr 2012 09:09:27 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335344965!13579099!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9575 invoked from network); 25 Apr 2012 09:09:26 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:09:26 -0000
Received: from mail53-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:09:23 +0000
Received: from mail53-va3 (localhost [127.0.0.1])	by mail53-va3-R.bigfish.com
	(Postfix) with ESMTP id AB7382044A;
	Wed, 25 Apr 2012 09:09:23 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail53-va3 (localhost.localdomain [127.0.0.1]) by mail53-va3
	(MessageSwitch) id 1335344961824371_11897;
	Wed, 25 Apr 2012 09:09:21 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.240])	by
	mail53-va3.bigfish.com (Postfix) with ESMTP id C39A1320053;
	Wed, 25 Apr 2012 09:09:21 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:09:19 +0000
X-WSS-ID: 0M312RI-01-AK7-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 294AF10280A2;	Wed, 25 Apr 2012 04:09:18 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:09:53 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 25 Apr 2012 04:09:18 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:09:15 -0400
Message-ID: <4F97BF3A.6010801@amd.com>
Date: Wed, 25 Apr 2012 11:09:14 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F88373C.6050007@amd.com>
	<20374.57335.827446.368581@mariner.uk.xensource.com>
In-Reply-To: <20374.57335.827446.368581@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error w/o MEMSHR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/12 19:16, Ian Jackson wrote:

> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error w/o MEMSHR"):
>>
>> Do not include memshr.h when MEMSHR is not defined.
>> Fixes build error when MEMSHR is disabled.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>


Thanks.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:09:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyE5-00072m-0I; Wed, 25 Apr 2012 09:09:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyE4-00072g-1D
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:09:28 +0000
Received: from [85.158.143.35:16355] by server-1.bemta-4.messagelabs.com id
	D4/6C-20925-74FB79F4; Wed, 25 Apr 2012 09:09:27 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335344965!13579099!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9575 invoked from network); 25 Apr 2012 09:09:26 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:09:26 -0000
Received: from mail53-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:09:23 +0000
Received: from mail53-va3 (localhost [127.0.0.1])	by mail53-va3-R.bigfish.com
	(Postfix) with ESMTP id AB7382044A;
	Wed, 25 Apr 2012 09:09:23 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail53-va3 (localhost.localdomain [127.0.0.1]) by mail53-va3
	(MessageSwitch) id 1335344961824371_11897;
	Wed, 25 Apr 2012 09:09:21 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.240])	by
	mail53-va3.bigfish.com (Postfix) with ESMTP id C39A1320053;
	Wed, 25 Apr 2012 09:09:21 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:09:19 +0000
X-WSS-ID: 0M312RI-01-AK7-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 294AF10280A2;	Wed, 25 Apr 2012 04:09:18 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:09:53 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 25 Apr 2012 04:09:18 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:09:15 -0400
Message-ID: <4F97BF3A.6010801@amd.com>
Date: Wed, 25 Apr 2012 11:09:14 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F88373C.6050007@amd.com>
	<20374.57335.827446.368581@mariner.uk.xensource.com>
In-Reply-To: <20374.57335.827446.368581@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error w/o MEMSHR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/12 19:16, Ian Jackson wrote:

> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error w/o MEMSHR"):
>>
>> Do not include memshr.h when MEMSHR is not defined.
>> Fixes build error when MEMSHR is disabled.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>


Thanks.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:11:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyFV-00078m-GK; Wed, 25 Apr 2012 09:10:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyFU-00078d-Mu
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:10:56 +0000
Received: from [85.158.138.51:43334] by server-2.bemta-3.messagelabs.com id
	F1/B5-09269-F9FB79F4; Wed, 25 Apr 2012 09:10:55 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335345053!15759555!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23633 invoked from network); 25 Apr 2012 09:10:54 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:10:54 -0000
Received: from mail138-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:10:52 +0000
Received: from mail138-ch1 (localhost [127.0.0.1])	by
	mail138-ch1-R.bigfish.com (Postfix) with ESMTP id 74B542A00EE;
	Wed, 25 Apr 2012 09:10:52 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail138-ch1 (localhost.localdomain [127.0.0.1]) by mail138-ch1
	(MessageSwitch) id 1335345049630490_25002;
	Wed, 25 Apr 2012 09:10:49 +0000 (UTC)
Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.227])	by mail138-ch1.bigfish.com (Postfix) with ESMTP id
	8B941120066;	Wed, 25 Apr 2012 09:10:49 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:10:49 +0000
X-WSS-ID: 0M312U0-01-AMA-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2154E10280A3;	Wed, 25 Apr 2012 04:10:47 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:10:58 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:10:47 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:10:46 -0400
Message-ID: <4F97BF95.6050209@amd.com>
Date: Wed, 25 Apr 2012 11:10:45 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335343957.28015.1.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 10:52, Ian Campbell wrote:

> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>> On 04/25/12 10:07, Ian Campbell wrote:
>>
>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>
>>>>> Pass PYTHON down to seabios, so seabios will
>>>>> use same python binary as whole xen tree does.
>>>>> Fixes build error on NetBSD.
>>>>
>>>> Ian, does this look sensible to you ?
>>>
>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>> is OK, so we might as well take this now.
>>
>>
>> Thanks.

>>

>>> Does
>>> subdirs-seabios: PYTHON=$(PYTHON)
>>> (or something similar) work? Might be a better option in the future
>>
>> No, this doesn't work.
> 
> What about
> subdir-all-seabios: PYTHON=...
> ?


No, doesn't work. I also tried without success:

subdirs-all-seabios
subdir-all-seabios-dir
subdirs-all-seabios-dir
seabios-dir

Christoph

>>>>
>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>  	false ; \
>>>>>  	fi
>>>>>  endif
>>>>> -	$(MAKE) subdirs-$@
>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>  
>>>>>  
>>>>>  .PHONY: install
>>>>>
>>>>> ----------------------------------------------------------------------


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:11:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyFV-00078m-GK; Wed, 25 Apr 2012 09:10:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyFU-00078d-Mu
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:10:56 +0000
Received: from [85.158.138.51:43334] by server-2.bemta-3.messagelabs.com id
	F1/B5-09269-F9FB79F4; Wed, 25 Apr 2012 09:10:55 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335345053!15759555!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23633 invoked from network); 25 Apr 2012 09:10:54 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:10:54 -0000
Received: from mail138-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:10:52 +0000
Received: from mail138-ch1 (localhost [127.0.0.1])	by
	mail138-ch1-R.bigfish.com (Postfix) with ESMTP id 74B542A00EE;
	Wed, 25 Apr 2012 09:10:52 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail138-ch1 (localhost.localdomain [127.0.0.1]) by mail138-ch1
	(MessageSwitch) id 1335345049630490_25002;
	Wed, 25 Apr 2012 09:10:49 +0000 (UTC)
Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.227])	by mail138-ch1.bigfish.com (Postfix) with ESMTP id
	8B941120066;	Wed, 25 Apr 2012 09:10:49 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:10:49 +0000
X-WSS-ID: 0M312U0-01-AMA-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2154E10280A3;	Wed, 25 Apr 2012 04:10:47 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:10:58 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:10:47 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:10:46 -0400
Message-ID: <4F97BF95.6050209@amd.com>
Date: Wed, 25 Apr 2012 11:10:45 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335343957.28015.1.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 10:52, Ian Campbell wrote:

> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>> On 04/25/12 10:07, Ian Campbell wrote:
>>
>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>
>>>>> Pass PYTHON down to seabios, so seabios will
>>>>> use same python binary as whole xen tree does.
>>>>> Fixes build error on NetBSD.
>>>>
>>>> Ian, does this look sensible to you ?
>>>
>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>> is OK, so we might as well take this now.
>>
>>
>> Thanks.

>>

>>> Does
>>> subdirs-seabios: PYTHON=$(PYTHON)
>>> (or something similar) work? Might be a better option in the future
>>
>> No, this doesn't work.
> 
> What about
> subdir-all-seabios: PYTHON=...
> ?


No, doesn't work. I also tried without success:

subdirs-all-seabios
subdir-all-seabios-dir
subdirs-all-seabios-dir
seabios-dir

Christoph

>>>>
>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>  	false ; \
>>>>>  	fi
>>>>>  endif
>>>>> -	$(MAKE) subdirs-$@
>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>  
>>>>>  
>>>>>  .PHONY: install
>>>>>
>>>>> ----------------------------------------------------------------------


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:14:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyIG-0007KI-38; Wed, 25 Apr 2012 09:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyIE-0007K8-IL
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:13:46 +0000
Received: from [85.158.143.35:9872] by server-3.bemta-4.messagelabs.com id
	49/E8-05853-940C79F4; Wed, 25 Apr 2012 09:13:45 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335345224!12916497!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20080 invoked from network); 25 Apr 2012 09:13:45 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:13:45 -0000
Received: from mail107-va3-R.bigfish.com (10.7.14.242) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:13:43 +0000
Received: from mail107-va3 (localhost [127.0.0.1])	by
	mail107-va3-R.bigfish.com (Postfix) with ESMTP id BF5421E03EE;
	Wed, 25 Apr 2012 09:13:43 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3
	(MessageSwitch) id 1335345222182986_32508;
	Wed, 25 Apr 2012 09:13:42 +0000 (UTC)
Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.242])	by
	mail107-va3.bigfish.com (Postfix) with ESMTP id 1C246A015A;
	Wed, 25 Apr 2012 09:13:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:13:42 +0000
X-WSS-ID: 0M312YO-02-2NQ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 208A9C80D1;	Wed, 25 Apr 2012 04:13:36 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:14:15 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:13:39 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:13:38 -0400
Message-ID: <4F97C041.50205@amd.com>
Date: Wed, 25 Apr 2012 11:13:37 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com>
In-Reply-To: <4F97BF95.6050209@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:10, Christoph Egger wrote:

> On 04/25/12 10:52, Ian Campbell wrote:
> 
>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>
>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>
>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>> use same python binary as whole xen tree does.
>>>>>> Fixes build error on NetBSD.
>>>>>
>>>>> Ian, does this look sensible to you ?
>>>>
>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>> is OK, so we might as well take this now.
>>>
>>>
>>> Thanks.
> 
>>>
> 
>>>> Does
>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>> (or something similar) work? Might be a better option in the future
>>>
>>> No, this doesn't work.
>>
>> What about
>> subdir-all-seabios: PYTHON=...
>> ?
> 
> 
> No, doesn't work. I also tried without success:
> 
> subdirs-all-seabios
> subdir-all-seabios-dir
> subdirs-all-seabios-dir
> seabios-dir

I found something that works:

subdir-all-seabios-dir:
	export PYTHON=$(PYTHON)

Christoph
> 
>>>>>
>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>
>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>  	false ; \
>>>>>>  	fi
>>>>>>  endif
>>>>>> -	$(MAKE) subdirs-$@
>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>  
>>>>>>  
>>>>>>  .PHONY: install
>>>>>>
>>>>>> ----------------------------------------------------------------------
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:14:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyIG-0007KI-38; Wed, 25 Apr 2012 09:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyIE-0007K8-IL
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:13:46 +0000
Received: from [85.158.143.35:9872] by server-3.bemta-4.messagelabs.com id
	49/E8-05853-940C79F4; Wed, 25 Apr 2012 09:13:45 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335345224!12916497!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20080 invoked from network); 25 Apr 2012 09:13:45 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:13:45 -0000
Received: from mail107-va3-R.bigfish.com (10.7.14.242) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:13:43 +0000
Received: from mail107-va3 (localhost [127.0.0.1])	by
	mail107-va3-R.bigfish.com (Postfix) with ESMTP id BF5421E03EE;
	Wed, 25 Apr 2012 09:13:43 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3
	(MessageSwitch) id 1335345222182986_32508;
	Wed, 25 Apr 2012 09:13:42 +0000 (UTC)
Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.242])	by
	mail107-va3.bigfish.com (Postfix) with ESMTP id 1C246A015A;
	Wed, 25 Apr 2012 09:13:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:13:42 +0000
X-WSS-ID: 0M312YO-02-2NQ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 208A9C80D1;	Wed, 25 Apr 2012 04:13:36 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:14:15 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:13:39 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:13:38 -0400
Message-ID: <4F97C041.50205@amd.com>
Date: Wed, 25 Apr 2012 11:13:37 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com>
In-Reply-To: <4F97BF95.6050209@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:10, Christoph Egger wrote:

> On 04/25/12 10:52, Ian Campbell wrote:
> 
>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>
>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>
>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>> use same python binary as whole xen tree does.
>>>>>> Fixes build error on NetBSD.
>>>>>
>>>>> Ian, does this look sensible to you ?
>>>>
>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>> is OK, so we might as well take this now.
>>>
>>>
>>> Thanks.
> 
>>>
> 
>>>> Does
>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>> (or something similar) work? Might be a better option in the future
>>>
>>> No, this doesn't work.
>>
>> What about
>> subdir-all-seabios: PYTHON=...
>> ?
> 
> 
> No, doesn't work. I also tried without success:
> 
> subdirs-all-seabios
> subdir-all-seabios-dir
> subdirs-all-seabios-dir
> seabios-dir

I found something that works:

subdir-all-seabios-dir:
	export PYTHON=$(PYTHON)

Christoph
> 
>>>>>
>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>
>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>  	false ; \
>>>>>>  	fi
>>>>>>  endif
>>>>>> -	$(MAKE) subdirs-$@
>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>  
>>>>>>  
>>>>>>  .PHONY: install
>>>>>>
>>>>>> ----------------------------------------------------------------------
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:15:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyJG-0007RY-Ol; Wed, 25 Apr 2012 09:14:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMyJG-0007RL-2S
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:14:50 +0000
Received: from [85.158.143.99:52003] by server-3.bemta-4.messagelabs.com id
	4E/1B-05853-980C79F4; Wed, 25 Apr 2012 09:14:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335345286!24840089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19265 invoked from network); 25 Apr 2012 09:14:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:14:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191954610"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 05:14:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 05:14:44 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMyJA-0005WP-GQ;
	Wed, 25 Apr 2012 10:14:44 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 10:14:42 +0100
Message-ID: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] libxl/build: print a warning if flex/bison
	are needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds better support for both Flex and Bison, which might
be needed to compile libxl. Now configure script sets BISON and FLEX
Makefile vars if bison and flex are found, but doesn't complain if
they are not found.

Also, added some Makefile soccery to print a warning message if
Bison or Flex are needed but not found.

Please run autogen after applying this patch.

Changes since v1:

 * Print a warning message instead of an error if flex/bison are
   needed but not found.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/configure.ac   |    2 ++
 tools/libxl/Makefile |   16 ++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..47becfe 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -77,6 +77,8 @@ AC_PROG_CC
 AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
+AC_PATH_PROG([BISON], [bison])
+AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 0ac43bd..13de15d 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -48,6 +48,18 @@ please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
 endif
 endif
 
+ifeq ($(FLEX),)
+%.c %.h:: %.l
+	$(warning Flex is needed to compile libxl, please install it and rerun \
+	configure)
+endif
+
+ifeq ($(BISON),)
+%.c %.h:: %.y
+	$(warning Bison is needed to compile libxl, please install it an rerun \
+	configure)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
@@ -83,11 +95,11 @@ all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
-%.c %.h: %.y
+%.c %.h:: %.y
 	@rm -f $*.[ch]
 	$(BISON) --output=$*.c $<
 
-%.c %.h: %.l
+%.c %.h:: %.l
 	@rm -f $*.[ch]
 	$(FLEX) --header-file=$*.h --outfile=$*.c $<
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:15:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyJG-0007RY-Ol; Wed, 25 Apr 2012 09:14:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMyJG-0007RL-2S
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:14:50 +0000
Received: from [85.158.143.99:52003] by server-3.bemta-4.messagelabs.com id
	4E/1B-05853-980C79F4; Wed, 25 Apr 2012 09:14:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335345286!24840089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19265 invoked from network); 25 Apr 2012 09:14:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:14:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191954610"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 05:14:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 05:14:44 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMyJA-0005WP-GQ;
	Wed, 25 Apr 2012 10:14:44 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 10:14:42 +0100
Message-ID: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] libxl/build: print a warning if flex/bison
	are needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds better support for both Flex and Bison, which might
be needed to compile libxl. Now configure script sets BISON and FLEX
Makefile vars if bison and flex are found, but doesn't complain if
they are not found.

Also, added some Makefile soccery to print a warning message if
Bison or Flex are needed but not found.

Please run autogen after applying this patch.

Changes since v1:

 * Print a warning message instead of an error if flex/bison are
   needed but not found.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tools/configure.ac   |    2 ++
 tools/libxl/Makefile |   16 ++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 250dffd..47becfe 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -77,6 +77,8 @@ AC_PROG_CC
 AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
+AC_PATH_PROG([BISON], [bison])
+AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 0ac43bd..13de15d 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -48,6 +48,18 @@ please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
 endif
 endif
 
+ifeq ($(FLEX),)
+%.c %.h:: %.l
+	$(warning Flex is needed to compile libxl, please install it and rerun \
+	configure)
+endif
+
+ifeq ($(BISON),)
+%.c %.h:: %.y
+	$(warning Bison is needed to compile libxl, please install it an rerun \
+	configure)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
@@ -83,11 +95,11 @@ all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
-%.c %.h: %.y
+%.c %.h:: %.y
 	@rm -f $*.[ch]
 	$(BISON) --output=$*.c $<
 
-%.c %.h: %.l
+%.c %.h:: %.l
 	@rm -f $*.[ch]
 	$(FLEX) --header-file=$*.h --outfile=$*.c $<
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyKW-0007Yv-7g; Wed, 25 Apr 2012 09:16:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyKV-0007Yh-2c
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:16:07 +0000
Received: from [85.158.139.83:10718] by server-7.bemta-5.messagelabs.com id
	FD/89-16195-6D0C79F4; Wed, 25 Apr 2012 09:16:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335345364!18045427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22337 invoked from network); 25 Apr 2012 09:16:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:16:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:16:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:16:03 +0100
Message-ID: <1335345362.28015.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 25 Apr 2012 10:16:02 +0100
In-Reply-To: <4F97BF95.6050209@amd.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 10:10 +0100, Christoph Egger wrote:
> On 04/25/12 10:52, Ian Campbell wrote:
> 
> > On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
> >> On 04/25/12 10:07, Ian Campbell wrote:
> >>
> >>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> >>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> >>>>>
> >>>>> Pass PYTHON down to seabios, so seabios will
> >>>>> use same python binary as whole xen tree does.
> >>>>> Fixes build error on NetBSD.
> >>>>
> >>>> Ian, does this look sensible to you ?
> >>>
> >>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> >>> is OK, so we might as well take this now.
> >>
> >>
> >> Thanks.
> 
> >>
> 
> >>> Does
> >>> subdirs-seabios: PYTHON=$(PYTHON)
> >>> (or something similar) work? Might be a better option in the future
> >>
> >> No, this doesn't work.
> > 
> > What about
> > subdir-all-seabios: PYTHON=...
> > ?
> 
> 
> No, doesn't work. I also tried without success:
> 
> subdirs-all-seabios
> subdir-all-seabios-dir
> subdirs-all-seabios-dir
> seabios-dir

Strange. Oh well I guess the original patch does the job.

Ian.

> 
> Christoph
> 
> >>>>
> >>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> >>>
> >>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>>
> >>>>>
> >>>>> ----------------------------------------------------------------------
> >>>>> diff -r ab552da976a3 tools/firmware/Makefile
> >>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> >>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> >>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >>>>>  	false ; \
> >>>>>  	fi
> >>>>>  endif
> >>>>> -	$(MAKE) subdirs-$@
> >>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >>>>>  
> >>>>>  
> >>>>>  .PHONY: install
> >>>>>
> >>>>> ----------------------------------------------------------------------
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyKW-0007Yv-7g; Wed, 25 Apr 2012 09:16:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyKV-0007Yh-2c
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:16:07 +0000
Received: from [85.158.139.83:10718] by server-7.bemta-5.messagelabs.com id
	FD/89-16195-6D0C79F4; Wed, 25 Apr 2012 09:16:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335345364!18045427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22337 invoked from network); 25 Apr 2012 09:16:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:16:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:16:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:16:03 +0100
Message-ID: <1335345362.28015.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 25 Apr 2012 10:16:02 +0100
In-Reply-To: <4F97BF95.6050209@amd.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 10:10 +0100, Christoph Egger wrote:
> On 04/25/12 10:52, Ian Campbell wrote:
> 
> > On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
> >> On 04/25/12 10:07, Ian Campbell wrote:
> >>
> >>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> >>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> >>>>>
> >>>>> Pass PYTHON down to seabios, so seabios will
> >>>>> use same python binary as whole xen tree does.
> >>>>> Fixes build error on NetBSD.
> >>>>
> >>>> Ian, does this look sensible to you ?
> >>>
> >>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> >>> is OK, so we might as well take this now.
> >>
> >>
> >> Thanks.
> 
> >>
> 
> >>> Does
> >>> subdirs-seabios: PYTHON=$(PYTHON)
> >>> (or something similar) work? Might be a better option in the future
> >>
> >> No, this doesn't work.
> > 
> > What about
> > subdir-all-seabios: PYTHON=...
> > ?
> 
> 
> No, doesn't work. I also tried without success:
> 
> subdirs-all-seabios
> subdir-all-seabios-dir
> subdirs-all-seabios-dir
> seabios-dir

Strange. Oh well I guess the original patch does the job.

Ian.

> 
> Christoph
> 
> >>>>
> >>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> >>>
> >>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>>
> >>>>>
> >>>>> ----------------------------------------------------------------------
> >>>>> diff -r ab552da976a3 tools/firmware/Makefile
> >>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> >>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> >>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >>>>>  	false ; \
> >>>>>  	fi
> >>>>>  endif
> >>>>> -	$(MAKE) subdirs-$@
> >>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >>>>>  
> >>>>>  
> >>>>>  .PHONY: install
> >>>>>
> >>>>> ----------------------------------------------------------------------
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:18:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyMn-0007jb-Pt; Wed, 25 Apr 2012 09:18:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyMm-0007jV-Cy
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:18:28 +0000
Received: from [193.109.254.147:52727] by server-8.bemta-14.messagelabs.com id
	46/1D-23244-361C79F4; Wed, 25 Apr 2012 09:18:27 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335345505!6228455!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30122 invoked from network); 25 Apr 2012 09:18:26 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:18:26 -0000
Received: from mail58-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:18:25 +0000
Received: from mail58-ch1 (localhost [127.0.0.1])	by mail58-ch1-R.bigfish.com
	(Postfix) with ESMTP id 1244426026D;
	Wed, 25 Apr 2012 09:18:25 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1
	(MessageSwitch) id 1335345503518453_8539;
	Wed, 25 Apr 2012 09:18:23 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail58-ch1.bigfish.com (Postfix) with ESMTP id
	70A4A4C008D;	Wed, 25 Apr 2012 09:18:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:18:22 +0000
X-WSS-ID: 0M3136J-02-2WW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CD69C80CE;	Wed, 25 Apr 2012 04:18:18 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:18:56 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:18:21 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:18:20 -0400
Message-ID: <4F97C15B.3060300@amd.com>
Date: Wed, 25 Apr 2012 11:18:19 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com> <4F97C041.50205@amd.com>
In-Reply-To: <4F97C041.50205@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:13, Christoph Egger wrote:

> On 04/25/12 11:10, Christoph Egger wrote:
> 
>> On 04/25/12 10:52, Ian Campbell wrote:
>>
>>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>>
>>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>>
>>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>>> use same python binary as whole xen tree does.
>>>>>>> Fixes build error on NetBSD.
>>>>>>
>>>>>> Ian, does this look sensible to you ?
>>>>>
>>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>>> is OK, so we might as well take this now.
>>>>
>>>>
>>>> Thanks.
>>
>>>>
>>
>>>>> Does
>>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>>> (or something similar) work? Might be a better option in the future
>>>>
>>>> No, this doesn't work.
>>>
>>> What about
>>> subdir-all-seabios: PYTHON=...
>>> ?
>>
>>
>> No, doesn't work. I also tried without success:
>>
>> subdirs-all-seabios
>> subdir-all-seabios-dir
>> subdirs-all-seabios-dir
>> seabios-dir
> 
> I found something that works:
> 
> subdir-all-seabios-dir:
> 	export PYTHON=$(PYTHON)

Ah, no. This causes a subsequent seabios build error about a missing
build rule. I should have waited with sending the mail
till the build finished.

> Christoph
>>
>>>>>>
>>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>>
>>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>>  	false ; \
>>>>>>>  	fi
>>>>>>>  endif
>>>>>>> -	$(MAKE) subdirs-$@
>>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>>  
>>>>>>>  
>>>>>>>  .PHONY: install
>>>>>>>
>>>>>>> ----------------------------------------------------------------------


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:18:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyMn-0007jb-Pt; Wed, 25 Apr 2012 09:18:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyMm-0007jV-Cy
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:18:28 +0000
Received: from [193.109.254.147:52727] by server-8.bemta-14.messagelabs.com id
	46/1D-23244-361C79F4; Wed, 25 Apr 2012 09:18:27 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335345505!6228455!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30122 invoked from network); 25 Apr 2012 09:18:26 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:18:26 -0000
Received: from mail58-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:18:25 +0000
Received: from mail58-ch1 (localhost [127.0.0.1])	by mail58-ch1-R.bigfish.com
	(Postfix) with ESMTP id 1244426026D;
	Wed, 25 Apr 2012 09:18:25 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1
	(MessageSwitch) id 1335345503518453_8539;
	Wed, 25 Apr 2012 09:18:23 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail58-ch1.bigfish.com (Postfix) with ESMTP id
	70A4A4C008D;	Wed, 25 Apr 2012 09:18:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:18:22 +0000
X-WSS-ID: 0M3136J-02-2WW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CD69C80CE;	Wed, 25 Apr 2012 04:18:18 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:18:56 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:18:21 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:18:20 -0400
Message-ID: <4F97C15B.3060300@amd.com>
Date: Wed, 25 Apr 2012 11:18:19 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com> <4F97C041.50205@amd.com>
In-Reply-To: <4F97C041.50205@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:13, Christoph Egger wrote:

> On 04/25/12 11:10, Christoph Egger wrote:
> 
>> On 04/25/12 10:52, Ian Campbell wrote:
>>
>>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>>
>>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>>
>>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>>> use same python binary as whole xen tree does.
>>>>>>> Fixes build error on NetBSD.
>>>>>>
>>>>>> Ian, does this look sensible to you ?
>>>>>
>>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>>> is OK, so we might as well take this now.
>>>>
>>>>
>>>> Thanks.
>>
>>>>
>>
>>>>> Does
>>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>>> (or something similar) work? Might be a better option in the future
>>>>
>>>> No, this doesn't work.
>>>
>>> What about
>>> subdir-all-seabios: PYTHON=...
>>> ?
>>
>>
>> No, doesn't work. I also tried without success:
>>
>> subdirs-all-seabios
>> subdir-all-seabios-dir
>> subdirs-all-seabios-dir
>> seabios-dir
> 
> I found something that works:
> 
> subdir-all-seabios-dir:
> 	export PYTHON=$(PYTHON)

Ah, no. This causes a subsequent seabios build error about a missing
build rule. I should have waited with sending the mail
till the build finished.

> Christoph
>>
>>>>>>
>>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>>
>>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>>  	false ; \
>>>>>>>  	fi
>>>>>>>  endif
>>>>>>> -	$(MAKE) subdirs-$@
>>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>>  
>>>>>>>  
>>>>>>>  .PHONY: install
>>>>>>>
>>>>>>> ----------------------------------------------------------------------


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:21:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyPB-0007u2-Fa; Wed, 25 Apr 2012 09:20:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyP9-0007tu-3d
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:20:55 +0000
Received: from [85.158.139.83:8551] by server-12.bemta-5.messagelabs.com id
	71/7C-05587-6F1C79F4; Wed, 25 Apr 2012 09:20:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335345653!14130902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4261 invoked from network); 25 Apr 2012 09:20:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:20:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:20:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:20:53 +0100
Message-ID: <1335345652.28015.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 25 Apr 2012 10:20:52 +0100
In-Reply-To: <4F97C041.50205@amd.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com> <4F97C041.50205@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 10:13 +0100, Christoph Egger wrote:
> On 04/25/12 11:10, Christoph Egger wrote:
> 
> > On 04/25/12 10:52, Ian Campbell wrote:
> > 
> >> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
> >>> On 04/25/12 10:07, Ian Campbell wrote:
> >>>
> >>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> >>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> >>>>>>
> >>>>>> Pass PYTHON down to seabios, so seabios will
> >>>>>> use same python binary as whole xen tree does.
> >>>>>> Fixes build error on NetBSD.
> >>>>>
> >>>>> Ian, does this look sensible to you ?
> >>>>
> >>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> >>>> is OK, so we might as well take this now.
> >>>
> >>>
> >>> Thanks.
> > 
> >>>
> > 
> >>>> Does
> >>>> subdirs-seabios: PYTHON=$(PYTHON)
> >>>> (or something similar) work? Might be a better option in the future
> >>>
> >>> No, this doesn't work.
> >>
> >> What about
> >> subdir-all-seabios: PYTHON=...
> >> ?
> > 
> > 
> > No, doesn't work. I also tried without success:
> > 
> > subdirs-all-seabios
> > subdir-all-seabios-dir
> > subdirs-all-seabios-dir
> > seabios-dir
> 
> I found something that works:
> 
> subdir-all-seabios-dir:
> 	export PYTHON=$(PYTHON)

Really, that's not a syntax I've ever seen before, I've no idea how that
works, all on the same line, sure, but on the next line like that, odd!.
I would have thought that this would have caused "export PYTHON=
$(PYTHON)" to be run it its own new subshell which would immediately
exit.

Anyway, I guess if it works we might as well use this version...



Ian.

> 
> Christoph
> > 
> >>>>>
> >>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> >>>>
> >>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>>>
> >>>>>>
> >>>>>> ----------------------------------------------------------------------
> >>>>>> diff -r ab552da976a3 tools/firmware/Makefile
> >>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> >>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> >>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >>>>>>  	false ; \
> >>>>>>  	fi
> >>>>>>  endif
> >>>>>> -	$(MAKE) subdirs-$@
> >>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >>>>>>  
> >>>>>>  
> >>>>>>  .PHONY: install
> >>>>>>
> >>>>>> ----------------------------------------------------------------------
> > 
> > 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:21:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyPB-0007u2-Fa; Wed, 25 Apr 2012 09:20:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyP9-0007tu-3d
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:20:55 +0000
Received: from [85.158.139.83:8551] by server-12.bemta-5.messagelabs.com id
	71/7C-05587-6F1C79F4; Wed, 25 Apr 2012 09:20:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335345653!14130902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4261 invoked from network); 25 Apr 2012 09:20:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:20:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:20:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:20:53 +0100
Message-ID: <1335345652.28015.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 25 Apr 2012 10:20:52 +0100
In-Reply-To: <4F97C041.50205@amd.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com> <4F97C041.50205@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 10:13 +0100, Christoph Egger wrote:
> On 04/25/12 11:10, Christoph Egger wrote:
> 
> > On 04/25/12 10:52, Ian Campbell wrote:
> > 
> >> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
> >>> On 04/25/12 10:07, Ian Campbell wrote:
> >>>
> >>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> >>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> >>>>>>
> >>>>>> Pass PYTHON down to seabios, so seabios will
> >>>>>> use same python binary as whole xen tree does.
> >>>>>> Fixes build error on NetBSD.
> >>>>>
> >>>>> Ian, does this look sensible to you ?
> >>>>
> >>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> >>>> is OK, so we might as well take this now.
> >>>
> >>>
> >>> Thanks.
> > 
> >>>
> > 
> >>>> Does
> >>>> subdirs-seabios: PYTHON=$(PYTHON)
> >>>> (or something similar) work? Might be a better option in the future
> >>>
> >>> No, this doesn't work.
> >>
> >> What about
> >> subdir-all-seabios: PYTHON=...
> >> ?
> > 
> > 
> > No, doesn't work. I also tried without success:
> > 
> > subdirs-all-seabios
> > subdir-all-seabios-dir
> > subdirs-all-seabios-dir
> > seabios-dir
> 
> I found something that works:
> 
> subdir-all-seabios-dir:
> 	export PYTHON=$(PYTHON)

Really, that's not a syntax I've ever seen before, I've no idea how that
works, all on the same line, sure, but on the next line like that, odd!.
I would have thought that this would have caused "export PYTHON=
$(PYTHON)" to be run it its own new subshell which would immediately
exit.

Anyway, I guess if it works we might as well use this version...



Ian.

> 
> Christoph
> > 
> >>>>>
> >>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> >>>>
> >>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>>>
> >>>>>>
> >>>>>> ----------------------------------------------------------------------
> >>>>>> diff -r ab552da976a3 tools/firmware/Makefile
> >>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
> >>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
> >>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
> >>>>>>  	false ; \
> >>>>>>  	fi
> >>>>>>  endif
> >>>>>> -	$(MAKE) subdirs-$@
> >>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> >>>>>>  
> >>>>>>  
> >>>>>>  .PHONY: install
> >>>>>>
> >>>>>> ----------------------------------------------------------------------
> > 
> > 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyQ7-0007zk-Uv; Wed, 25 Apr 2012 09:21:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyQ6-0007zU-DQ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:21:54 +0000
Received: from [85.158.143.99:63097] by server-3.bemta-4.messagelabs.com id
	FA/C9-05853-132C79F4; Wed, 25 Apr 2012 09:21:53 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335345711!19924270!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 446 invoked from network); 25 Apr 2012 09:21:52 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:21:52 -0000
Received: from mail54-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:21:50 +0000
Received: from mail54-ch1 (localhost [127.0.0.1])	by mail54-ch1-R.bigfish.com
	(Postfix) with ESMTP id 8B0A1604D8;
	Wed, 25 Apr 2012 09:21:50 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail54-ch1 (localhost.localdomain [127.0.0.1]) by mail54-ch1
	(MessageSwitch) id 1335345707711858_31019;
	Wed, 25 Apr 2012 09:21:47 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.239])	by mail54-ch1.bigfish.com (Postfix) with ESMTP id
	A9B231200A3;	Wed, 25 Apr 2012 09:21:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:21:46 +0000
X-WSS-ID: 0M313C8-01-B6X-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F8DE10280A1;	Wed, 25 Apr 2012 04:21:43 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:22:19 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:21:43 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:21:42 -0400
Message-ID: <4F97C225.9000704@amd.com>
Date: Wed, 25 Apr 2012 11:21:41 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com>
	<1335345362.28015.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335345362.28015.9.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:16, Ian Campbell wrote:

> On Wed, 2012-04-25 at 10:10 +0100, Christoph Egger wrote:
>> On 04/25/12 10:52, Ian Campbell wrote:
>>
>>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>>
>>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>>
>>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>>> use same python binary as whole xen tree does.
>>>>>>> Fixes build error on NetBSD.
>>>>>>
>>>>>> Ian, does this look sensible to you ?
>>>>>
>>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>>> is OK, so we might as well take this now.
>>>>
>>>>
>>>> Thanks.
>>
>>>>
>>
>>>>> Does
>>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>>> (or something similar) work? Might be a better option in the future
>>>>
>>>> No, this doesn't work.
>>>
>>> What about
>>> subdir-all-seabios: PYTHON=...
>>> ?
>>
>>
>> No, doesn't work. I also tried without success:
>>
>> subdirs-all-seabios
>> subdir-all-seabios-dir
>> subdirs-all-seabios-dir
>> seabios-dir
> 
> Strange. Oh well I guess the original patch does the job.


Yes, that's right.

Christoph

> 
> Ian.
> 
>>
>> Christoph
>>
>>>>>>
>>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>>
>>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>>  	false ; \
>>>>>>>  	fi
>>>>>>>  endif
>>>>>>> -	$(MAKE) subdirs-$@
>>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>>  
>>>>>>>  
>>>>>>>  .PHONY: install
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>
>>
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyQ7-0007zk-Uv; Wed, 25 Apr 2012 09:21:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyQ6-0007zU-DQ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:21:54 +0000
Received: from [85.158.143.99:63097] by server-3.bemta-4.messagelabs.com id
	FA/C9-05853-132C79F4; Wed, 25 Apr 2012 09:21:53 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335345711!19924270!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 446 invoked from network); 25 Apr 2012 09:21:52 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:21:52 -0000
Received: from mail54-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:21:50 +0000
Received: from mail54-ch1 (localhost [127.0.0.1])	by mail54-ch1-R.bigfish.com
	(Postfix) with ESMTP id 8B0A1604D8;
	Wed, 25 Apr 2012 09:21:50 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail54-ch1 (localhost.localdomain [127.0.0.1]) by mail54-ch1
	(MessageSwitch) id 1335345707711858_31019;
	Wed, 25 Apr 2012 09:21:47 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.239])	by mail54-ch1.bigfish.com (Postfix) with ESMTP id
	A9B231200A3;	Wed, 25 Apr 2012 09:21:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:21:46 +0000
X-WSS-ID: 0M313C8-01-B6X-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F8DE10280A1;	Wed, 25 Apr 2012 04:21:43 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:22:19 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:21:43 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:21:42 -0400
Message-ID: <4F97C225.9000704@amd.com>
Date: Wed, 25 Apr 2012 11:21:41 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com>
	<1335345362.28015.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335345362.28015.9.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:16, Ian Campbell wrote:

> On Wed, 2012-04-25 at 10:10 +0100, Christoph Egger wrote:
>> On 04/25/12 10:52, Ian Campbell wrote:
>>
>>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>>
>>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>>
>>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>>> use same python binary as whole xen tree does.
>>>>>>> Fixes build error on NetBSD.
>>>>>>
>>>>>> Ian, does this look sensible to you ?
>>>>>
>>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>>> is OK, so we might as well take this now.
>>>>
>>>>
>>>> Thanks.
>>
>>>>
>>
>>>>> Does
>>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>>> (or something similar) work? Might be a better option in the future
>>>>
>>>> No, this doesn't work.
>>>
>>> What about
>>> subdir-all-seabios: PYTHON=...
>>> ?
>>
>>
>> No, doesn't work. I also tried without success:
>>
>> subdirs-all-seabios
>> subdir-all-seabios-dir
>> subdirs-all-seabios-dir
>> seabios-dir
> 
> Strange. Oh well I guess the original patch does the job.


Yes, that's right.

Christoph

> 
> Ian.
> 
>>
>> Christoph
>>
>>>>>>
>>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>>
>>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>>  	false ; \
>>>>>>>  	fi
>>>>>>>  endif
>>>>>>> -	$(MAKE) subdirs-$@
>>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>>  
>>>>>>>  
>>>>>>>  .PHONY: install
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>
>>
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyRp-00089Q-GK; Wed, 25 Apr 2012 09:23:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyRn-00089F-Jf
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:23:39 +0000
Received: from [85.158.143.35:8235] by server-3.bemta-4.messagelabs.com id
	58/3D-05853-A92C79F4; Wed, 25 Apr 2012 09:23:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335345817!6422194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30211 invoked from network); 25 Apr 2012 09:23:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:23:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:23:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:23:00 +0100
Message-ID: <1335345779.28015.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 10:22:59 +0100
In-Reply-To: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
 is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 19:05 +0100, Roger Pau Monne wrote:
> Prevent xl from doing any operation if xend daemon is running. That
> prevents bugs that happened when xl and xend raced to close a domain.
> 
> Changes since v1:
> 
>  * Add documentation to xl man page.
> 
>  * Permit the execution of commands that don't modify anything.
> 
>  * Indent error message.
> 
> Cc: george.dunlap@eu.citrix.com
> Cc: ian.jackson@eu.citrix.com
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  docs/man/xl.pod.1         |    6 ++
>  tools/libxl/xl.c          |   22 +++++++-
>  tools/libxl/xl.h          |    1 +
>  tools/libxl/xl_cmdimpl.c  |    4 +-
>  tools/libxl/xl_cmdtable.c |  132 ++++++++++++++++++++++----------------------
>  5 files changed, 96 insertions(+), 69 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index e5324fb..e829697 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -75,6 +75,12 @@ Verbose.
> 
>  Dry run: do not actually execute the command.
> 
> +=item B<-f>
> +
> +Force execution: xl will refuse to run some commands if it detects that xend is
> +also running, this option will force the execution of those commands, even
> +though it is unsafe.
> +
>  =back
> 
>  =head1 DOMAIN SUBCOMMANDS
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index 2b14814..720bb66 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -32,8 +32,11 @@
>  #include "libxlutil.h"
>  #include "xl.h"
> 
> +#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
> +
>  xentoollog_logger_stdiostream *logger;
>  int dryrun_only;
> +int force_execution;
>  int autoballoon = 1;
>  char *lockfile;
>  char *default_vifscript = NULL;
> @@ -103,8 +106,9 @@ int main(int argc, char **argv)
>      char *config_file;
>      void *config_data = 0;
>      int config_len = 0;
> +    const char *locks[] = XEND_LOCK;
> 
> -    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
> +    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
>          switch (opt) {
>          case 'v':
>              if (minmsglevel > 0) minmsglevel--;
> @@ -112,6 +116,9 @@ int main(int argc, char **argv)
>          case 'N':
>              dryrun_only = 1;
>              break;
> +        case 'f':
> +            force_execution = 1;
> +            break;
>          default:
>              fprintf(stderr, "unknown global option\n");
>              exit(2);
> @@ -162,6 +169,19 @@ int main(int argc, char **argv)
>              ret = 1;
>              goto xit;
>          }
> +        if (cspec->modifies) {

Need to handle -N (dry-run) too? That will turn a modifying command into
a non-modifying one.

Do we now have 3 classes of commands which could be represented with an
enum rather than a pair of bools?

      * Purely introspective commands, only query data, do not change
        any state, -N and -f mean nothing.
      * Commands which modify state, but which have a "dry-run" mode. -N
        activates dry-run, -f only means something if !dry-run
      * Commands which modify state, but which do not support a dry-run
        mode, -N is not available, -f does what you'd expect.

> +            for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
> +                if (!access(locks[i], F_OK) && !force_execution) {
> +                    fprintf(stderr,
> +"xend is running, which prevents xl from working correctly.\n"
> +"If you still want to force the execution of xl please use the -f\n"
> +"option.\n"
> +                            );
> +                    ret = 1;
> +                    goto xit;
> +                }
> +            }
> +        }
>          ret = cspec->cmd_impl(argc, argv);
>      } else if (!strcmp(cmd, "help")) {
>          help(argv[1]);
> diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
> index 0a3d628..5ddd2da 100644
> --- a/tools/libxl/xl.h
> +++ b/tools/libxl/xl.h
> @@ -21,6 +21,7 @@ struct cmd_spec {
>      char *cmd_name;
>      int (*cmd_impl)(int argc, char **argv);
>      int can_dryrun;
> +    int modifies;
>      char *cmd_desc;
>      char *cmd_usage;
>      char *cmd_option;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 6f4dd09..65bc6d6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1909,7 +1909,7 @@ void help(const char *command)
>      struct cmd_spec *cmd;
> 
>      if (!command || !strcmp(command, "help")) {
> -        printf("Usage xl [-vN] <subcommand> [args]\n\n");
> +        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
>          printf("xl full list of subcommands:\n\n");
>          for (i = 0; i < cmdtable_len; i++) {
>              printf(" %-19s ", cmd_table[i].cmd_name);
> @@ -1920,7 +1920,7 @@ void help(const char *command)
>      } else {
>          cmd = cmdtable_lookup(command);
>          if (cmd) {
> -            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
> +            printf("Usage: xl [-vf%s] %s %s\n\n%s.\n\n",
>                     cmd->can_dryrun ? "N" : "",
>                     cmd->cmd_name,
>                     cmd->cmd_usage,
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index f461a2a..5509126 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -19,7 +19,7 @@
> 
>  struct cmd_spec cmd_table[] = {
>      { "create",
> -      &main_create, 1,
> +      &main_create, 1, 1,
>        "Create a domain from config file <filename>",
>        "<ConfigFile> [options] [vars]",
>        "-h                      Print this help.\n"
> @@ -33,7 +33,7 @@ struct cmd_spec cmd_table[] = {
>        "-e                      Do not wait in the background for the death of the domain."
>      },
>      { "config-update",
> -      &main_config_update, 1,
> +      &main_config_update, 1, 1,
>        "Update a running domain's saved configuration, used when rebuilding "
>        "the domain after reboot",
>        "<Domain> <ConfigFile> [options] [vars]",
> @@ -42,7 +42,7 @@ struct cmd_spec cmd_table[] = {
>        "-d                      Enable debug messages.\n"
>      },
>      { "list",
> -      &main_list, 0,
> +      &main_list, 0, 0,
>        "List information about all/some domains",
>        "[options] [Domain]\n",
>        "-l, --long              Output all VM details\n"
> @@ -50,12 +50,12 @@ struct cmd_spec cmd_table[] = {
>        "-Z, --context           Prints out security context"
>      },
>      { "destroy",
> -      &main_destroy, 0,
> +      &main_destroy, 0, 1,
>        "Terminate a domain immediately",
>        "<Domain>",
>      },
>      { "shutdown",
> -      &main_shutdown, 0,
> +      &main_shutdown, 0, 1,
>        "Issue a shutdown signal to a domain",
>        "[options] <Domain>",
>        "-h                      Print this help.\n"
> @@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
>        "-w                      Wait for guest to shutdown.\n"
>      },
>      { "reboot",
> -      &main_reboot, 0,
> +      &main_reboot, 0, 1,
>        "Issue a reboot signal to a domain",
>        "[options] <Domain>",
>        "-h                      Print this help.\n"
> @@ -72,44 +72,44 @@ struct cmd_spec cmd_table[] = {
>        "                        no PV drivers.\n"
>      },
>      { "pci-attach",
> -      &main_pciattach, 0,
> +      &main_pciattach, 0, 1,
>        "Insert a new pass-through pci device",
>        "<Domain> <BDF> [Virtual Slot]",
>      },
>      { "pci-detach",
> -      &main_pcidetach, 0,
> +      &main_pcidetach, 0, 1,
>        "Remove a domain's pass-through pci device",
>        "<Domain> <BDF>",
>      },
>      { "pci-list",
> -      &main_pcilist, 0,
> +      &main_pcilist, 0, 0,
>        "List pass-through pci devices for a domain",
>        "<Domain>",
>      },
>      { "pci-list-assignable-devices",
> -      &main_pcilist_assignable, 0,
> +      &main_pcilist_assignable, 0, 0,
>        "List all the assignable pci devices",
>        "",
>      },
>      { "pause",
> -      &main_pause, 0,
> +      &main_pause, 0, 1,
>        "Pause execution of a domain",
>        "<Domain>",
>      },
>      { "unpause",
> -      &main_unpause, 0,
> +      &main_unpause, 0, 1,
>        "Unpause a paused domain",
>        "<Domain>",
>      },
>      { "console",
> -      &main_console, 0,
> +      &main_console, 0, 0,
>        "Attach to domain's console",
>        "[options] <Domain>\n"
>        "-t <type>       console type, pv or serial\n"
>        "-n <number>     console number"
>      },
>      { "vncviewer",
> -      &main_vncviewer, 0,
> +      &main_vncviewer, 0, 0,
>        "Attach to domain's VNC server.",
>        "[options] <Domain>\n"
>        "--autopass               Pass VNC password to viewer via stdin and\n"
> @@ -117,14 +117,14 @@ struct cmd_spec cmd_table[] = {
>        "--vncviewer-autopass     (consistency alias for --autopass)"
>      },
>      { "save",
> -      &main_save, 0,
> +      &main_save, 0, 1,
>        "Save a domain state to restore later",
>        "[options] <Domain> <CheckpointFile> [<ConfigFile>]",
>        "-h  Print this help.\n"
>        "-c  Leave domain running after creating the snapshot."
>      },
>      { "migrate",
> -      &main_migrate, 0,
> +      &main_migrate, 0, 1,
>        "Save a domain state to restore later",
>        "[options] <Domain> <host>",
>        "-h              Print this help.\n"
> @@ -136,12 +136,12 @@ struct cmd_spec cmd_table[] = {
>        "                of the domain."
>      },
>      { "dump-core",
> -      &main_dump_core, 0,
> +      &main_dump_core, 0, 1,
>        "Core dump a domain",
>        "<Domain> <filename>"
>      },
>      { "restore",
> -      &main_restore, 0,
> +      &main_restore, 0, 1,
>        "Restore a domain from a saved state",
>        "[options] [<ConfigFile>] <CheckpointFile>",
>        "-h  Print this help.\n"
> @@ -150,68 +150,68 @@ struct cmd_spec cmd_table[] = {
>        "-d  Enable debug messages."
>      },
>      { "migrate-receive",
> -      &main_migrate_receive, 0,
> +      &main_migrate_receive, 0, 1,
>        "Restore a domain from a saved state",
>        "- for internal use only",
>      },
>      { "cd-insert",
> -      &main_cd_insert, 0,
> +      &main_cd_insert, 0, 1,
>        "Insert a cdrom into a guest's cd drive",
>        "<Domain> <VirtualDevice> <type:path>",
>      },
>      { "cd-eject",
> -      &main_cd_eject, 0,
> +      &main_cd_eject, 0, 1,
>        "Eject a cdrom from a guest's cd drive",
>        "<Domain> <VirtualDevice>",
>      },
>      { "mem-max",
> -      &main_memmax, 0,
> +      &main_memmax, 0, 1,
>        "Set the maximum amount reservation for a domain",
>        "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
>      },
>      { "mem-set",
> -      &main_memset, 0,
> +      &main_memset, 0, 1,
>        "Set the current memory usage for a domain",
>        "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
>      },
>      { "button-press",
> -      &main_button_press, 0,
> +      &main_button_press, 0, 1,
>        "Indicate an ACPI button press to the domain",
>        "<Domain> <Button>",
>        "<Button> may be 'power' or 'sleep'."
>      },
>      { "vcpu-list",
> -      &main_vcpulist, 0,
> +      &main_vcpulist, 0, 0,
>        "List the VCPUs for all/some domains",
>        "[Domain, ...]",
>      },
>      { "vcpu-pin",
> -      &main_vcpupin, 0,
> +      &main_vcpupin, 0, 1,
>        "Set which CPUs a VCPU can use",
>        "<Domain> <VCPU|all> <CPUs|all>",
>      },
>      { "vcpu-set",
> -      &main_vcpuset, 0,
> +      &main_vcpuset, 0, 1,
>        "Set the number of active VCPUs allowed for the domain",
>        "<Domain> <vCPUs>",
>      },
>      { "list-vm",
> -      &main_list_vm, 0,
> +      &main_list_vm, 0, 0,
>        "List the VMs,without DOM0",
>        "",
>      },
>      { "info",
> -      &main_info, 0,
> +      &main_info, 0, 0,
>        "Get information about Xen host",
>        "-n, --numa         List host NUMA topology information",
>      },
>      { "sharing",
> -      &main_sharing, 0,
> +      &main_sharing, 0, 0,
>        "Get information about page sharing",
>        "[Domain]",
>      },
>      { "sched-credit",
> -      &main_sched_credit, 0,
> +      &main_sched_credit, 0, 1,
>        "Get/set credit scheduler parameters",
>        "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
>        "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
> @@ -223,7 +223,7 @@ struct cmd_spec cmd_table[] = {
>        "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
>      },
>      { "sched-credit2",
> -      &main_sched_credit2, 0,
> +      &main_sched_credit2, 0, 1,
>        "Get/set credit2 scheduler parameters",
>        "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
>        "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
> @@ -231,7 +231,7 @@ struct cmd_spec cmd_table[] = {
>        "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
>      },
>      { "sched-sedf",
> -      &main_sched_sedf, 0,
> +      &main_sched_sedf, 0, 1,
>        "Get/set sedf scheduler parameters",
>        "[options]",
>        "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
> @@ -247,109 +247,109 @@ struct cmd_spec cmd_table[] = {
>        "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
>      },
>      { "domid",
> -      &main_domid, 0,
> +      &main_domid, 0, 0,
>        "Convert a domain name to domain id",
>        "<DomainName>",
>      },
>      { "domname",
> -      &main_domname, 0,
> +      &main_domname, 0, 0,
>        "Convert a domain id to domain name",
>        "<DomainId>",
>      },
>      { "rename",
> -      &main_rename, 0,
> +      &main_rename, 0, 1,
>        "Rename a domain",
>        "<Domain> <NewDomainName>",
>      },
>      { "trigger",
> -      &main_trigger, 0,
> +      &main_trigger, 0, 1,
>        "Send a trigger to a domain",
>        "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
>      },
>      { "sysrq",
> -      &main_sysrq, 0,
> +      &main_sysrq, 0, 1,
>        "Send a sysrq to a domain",
>        "<Domain> <letter>",
>      },
>      { "debug-keys",
> -      &main_debug_keys, 0,
> +      &main_debug_keys, 0, 1,
>        "Send debug keys to Xen",
>        "<Keys>",
>      },
>      { "dmesg",
> -      &main_dmesg, 0,
> +      &main_dmesg, 0, 0,
>        "Read and/or clear dmesg buffer",
>        "[-c]",
>        "  -c                        Clear dmesg buffer as well as printing it",
>      },
>      { "top",
> -      &main_top, 0,
> +      &main_top, 0, 0,
>        "Monitor a host and the domains in real time",
>        "",
>      },
>      { "network-attach",
> -      &main_networkattach, 0,
> +      &main_networkattach, 0, 1,
>        "Create a new virtual network device",
>        "<Domain> [type=<type>] [mac=<mac>] [bridge=<bridge>] "
>        "[ip=<ip>] [script=<script>] [backend=<BackDomain>] [vifname=<name>] "
>        "[rate=<rate>] [model=<model>] [accel=<accel>]",
>      },
>      { "network-list",
> -      &main_networklist, 0,
> +      &main_networklist, 0, 0,
>        "List virtual network interfaces for a domain",
>        "<Domain(s)>",
>      },
>      { "network-detach",
> -      &main_networkdetach, 0,
> +      &main_networkdetach, 0, 1,
>        "Destroy a domain's virtual network device",
>        "<Domain> <DevId|mac>",
>      },
>      { "block-attach",
> -      &main_blockattach, 1,
> +      &main_blockattach, 1, 1,
>        "Create a new virtual block device",
>        "<Domain> <disk-spec-component(s)>...",
>      },
>      { "block-list",
> -      &main_blocklist, 0,
> +      &main_blocklist, 0, 0,
>        "List virtual block devices for a domain",
>        "<Domain(s)>",
>      },
>      { "block-detach",
> -      &main_blockdetach, 0,
> +      &main_blockdetach, 0, 1,
>        "Destroy a domain's virtual block device",
>        "<Domain> <DevId>",
>      },
>      { "uptime",
> -      &main_uptime, 0,
> +      &main_uptime, 0, 0,
>        "Print uptime for all/some domains",
>        "[-s] [Domain]",
>      },
>      { "tmem-list",
> -      &main_tmem_list, 0,
> +      &main_tmem_list, 0, 0,
>        "List tmem pools",
>        "[-l] [<Domain>|-a]",
>        "  -l                             List tmem stats",
>      },
>      { "tmem-freeze",
> -      &main_tmem_freeze, 0,
> +      &main_tmem_freeze, 0, 1,
>        "Freeze tmem pools",
>        "[<Domain>|-a]",
>        "  -a                             Freeze all tmem",
>      },
>      { "tmem-destroy",
> -      &main_tmem_destroy, 0,
> +      &main_tmem_destroy, 0, 1,
>        "Destroy tmem pools",
>        "[<Domain>|-a]",
>        "  -a                             Destroy all tmem",
>      },
>      { "tmem-thaw",
> -      &main_tmem_thaw, 0,
> +      &main_tmem_thaw, 0, 1,
>        "Thaw tmem pools",
>        "[<Domain>|-a]",
>        "  -a                             Thaw all tmem",
>      },
>      { "tmem-set",
> -      &main_tmem_set, 0,
> +      &main_tmem_set, 0, 1,
>        "Change tmem settings",
>        "[<Domain>|-a] [-w[=WEIGHT]|-c[=CAP]|-p[=COMPRESS]]",
>        "  -a                             Operate on all tmem\n"
> @@ -358,7 +358,7 @@ struct cmd_spec cmd_table[] = {
>        "  -p COMPRESS                    Compress (int)",
>      },
>      { "tmem-shared-auth",
> -      &main_tmem_shared_auth, 0,
> +      &main_tmem_shared_auth, 0, 1,
>        "De/authenticate shared tmem pool",
>        "[<Domain>|-a] [-u[=UUID] [-A[=AUTH]",
>        "  -a                             Authenticate for all tmem pools\n"
> @@ -367,12 +367,12 @@ struct cmd_spec cmd_table[] = {
>        "  -A AUTH                        0=auth,1=deauth",
>      },
>      { "tmem-freeable",
> -      &main_tmem_freeable, 0,
> +      &main_tmem_freeable, 0, 0,
>        "Get information about how much freeable memory (MB) is in-use by tmem",
>        "",
>      },
>      { "cpupool-create",
> -      &main_cpupoolcreate, 1,
> +      &main_cpupoolcreate, 1, 1,
>        "Create a CPU pool based an ConfigFile",
>        "[options] <ConfigFile> [vars]",
>        "-h, --help                   Print this help.\n"
> @@ -381,53 +381,53 @@ struct cmd_spec cmd_table[] = {
>        "                              (deprecated in favour of global -N option)."
>      },
>      { "cpupool-list",
> -      &main_cpupoollist, 0,
> +      &main_cpupoollist, 0, 0,
>        "List CPU pools on host",
>        "[-c|--cpus] [<CPU Pool>]",
>        "-c, --cpus                     Output list of CPUs used by a pool"
>      },
>      { "cpupool-destroy",
> -      &main_cpupooldestroy, 0,
> +      &main_cpupooldestroy, 0, 1,
>        "Deactivates a CPU pool",
>        "<CPU Pool>",
>      },
>      { "cpupool-rename",
> -      &main_cpupoolrename, 0,
> +      &main_cpupoolrename, 0, 1,
>        "Renames a CPU pool",
>        "<CPU Pool> <new name>",
>      },
>      { "cpupool-cpu-add",
> -      &main_cpupoolcpuadd, 0,
> +      &main_cpupoolcpuadd, 0, 1,
>        "Adds a CPU to a CPU pool",
>        "<CPU Pool> <CPU nr>|node:<node nr>",
>      },
>      { "cpupool-cpu-remove",
> -      &main_cpupoolcpuremove, 0,
> +      &main_cpupoolcpuremove, 0, 1,
>        "Removes a CPU from a CPU pool",
>        "<CPU Pool> <CPU nr>|node:<node nr>",
>      },
>      { "cpupool-migrate",
> -      &main_cpupoolmigrate, 0,
> +      &main_cpupoolmigrate, 0, 1,
>        "Moves a domain into a CPU pool",
>        "<Domain> <CPU Pool>",
>      },
>      { "cpupool-numa-split",
> -      &main_cpupoolnumasplit, 0,
> +      &main_cpupoolnumasplit, 0, 1,
>        "Splits up the machine into one CPU pool per NUMA node",
>        "",
>      },
>      { "getenforce",
> -      &main_getenforce, 0,
> +      &main_getenforce, 0, 0,
>        "Returns the current enforcing mode of the Flask Xen security module",
>        "",
>      },
>      { "setenforce",
> -      &main_setenforce, 0,
> +      &main_setenforce, 0, 1,
>        "Sets the current enforcing mode of the Flask Xen security module",
>        "<1|0|Enforcing|Permissive>",
>      },
>      { "loadpolicy",
> -      &main_loadpolicy, 0,
> +      &main_loadpolicy, 0, 1,
>        "Loads a new policy int the Flask Xen security module",
>        "<policy file>",
>      },
> --
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyRp-00089Q-GK; Wed, 25 Apr 2012 09:23:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMyRn-00089F-Jf
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:23:39 +0000
Received: from [85.158.143.35:8235] by server-3.bemta-4.messagelabs.com id
	58/3D-05853-A92C79F4; Wed, 25 Apr 2012 09:23:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335345817!6422194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NTg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30211 invoked from network); 25 Apr 2012 09:23:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:23:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12125824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:23:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:23:00 +0100
Message-ID: <1335345779.28015.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 10:22:59 +0100
In-Reply-To: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
 is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 19:05 +0100, Roger Pau Monne wrote:
> Prevent xl from doing any operation if xend daemon is running. That
> prevents bugs that happened when xl and xend raced to close a domain.
> 
> Changes since v1:
> 
>  * Add documentation to xl man page.
> 
>  * Permit the execution of commands that don't modify anything.
> 
>  * Indent error message.
> 
> Cc: george.dunlap@eu.citrix.com
> Cc: ian.jackson@eu.citrix.com
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  docs/man/xl.pod.1         |    6 ++
>  tools/libxl/xl.c          |   22 +++++++-
>  tools/libxl/xl.h          |    1 +
>  tools/libxl/xl_cmdimpl.c  |    4 +-
>  tools/libxl/xl_cmdtable.c |  132 ++++++++++++++++++++++----------------------
>  5 files changed, 96 insertions(+), 69 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index e5324fb..e829697 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -75,6 +75,12 @@ Verbose.
> 
>  Dry run: do not actually execute the command.
> 
> +=item B<-f>
> +
> +Force execution: xl will refuse to run some commands if it detects that xend is
> +also running, this option will force the execution of those commands, even
> +though it is unsafe.
> +
>  =back
> 
>  =head1 DOMAIN SUBCOMMANDS
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index 2b14814..720bb66 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -32,8 +32,11 @@
>  #include "libxlutil.h"
>  #include "xl.h"
> 
> +#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
> +
>  xentoollog_logger_stdiostream *logger;
>  int dryrun_only;
> +int force_execution;
>  int autoballoon = 1;
>  char *lockfile;
>  char *default_vifscript = NULL;
> @@ -103,8 +106,9 @@ int main(int argc, char **argv)
>      char *config_file;
>      void *config_data = 0;
>      int config_len = 0;
> +    const char *locks[] = XEND_LOCK;
> 
> -    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
> +    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
>          switch (opt) {
>          case 'v':
>              if (minmsglevel > 0) minmsglevel--;
> @@ -112,6 +116,9 @@ int main(int argc, char **argv)
>          case 'N':
>              dryrun_only = 1;
>              break;
> +        case 'f':
> +            force_execution = 1;
> +            break;
>          default:
>              fprintf(stderr, "unknown global option\n");
>              exit(2);
> @@ -162,6 +169,19 @@ int main(int argc, char **argv)
>              ret = 1;
>              goto xit;
>          }
> +        if (cspec->modifies) {

Need to handle -N (dry-run) too? That will turn a modifying command into
a non-modifying one.

Do we now have 3 classes of commands which could be represented with an
enum rather than a pair of bools?

      * Purely introspective commands, only query data, do not change
        any state, -N and -f mean nothing.
      * Commands which modify state, but which have a "dry-run" mode. -N
        activates dry-run, -f only means something if !dry-run
      * Commands which modify state, but which do not support a dry-run
        mode, -N is not available, -f does what you'd expect.

> +            for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
> +                if (!access(locks[i], F_OK) && !force_execution) {
> +                    fprintf(stderr,
> +"xend is running, which prevents xl from working correctly.\n"
> +"If you still want to force the execution of xl please use the -f\n"
> +"option.\n"
> +                            );
> +                    ret = 1;
> +                    goto xit;
> +                }
> +            }
> +        }
>          ret = cspec->cmd_impl(argc, argv);
>      } else if (!strcmp(cmd, "help")) {
>          help(argv[1]);
> diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
> index 0a3d628..5ddd2da 100644
> --- a/tools/libxl/xl.h
> +++ b/tools/libxl/xl.h
> @@ -21,6 +21,7 @@ struct cmd_spec {
>      char *cmd_name;
>      int (*cmd_impl)(int argc, char **argv);
>      int can_dryrun;
> +    int modifies;
>      char *cmd_desc;
>      char *cmd_usage;
>      char *cmd_option;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 6f4dd09..65bc6d6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1909,7 +1909,7 @@ void help(const char *command)
>      struct cmd_spec *cmd;
> 
>      if (!command || !strcmp(command, "help")) {
> -        printf("Usage xl [-vN] <subcommand> [args]\n\n");
> +        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
>          printf("xl full list of subcommands:\n\n");
>          for (i = 0; i < cmdtable_len; i++) {
>              printf(" %-19s ", cmd_table[i].cmd_name);
> @@ -1920,7 +1920,7 @@ void help(const char *command)
>      } else {
>          cmd = cmdtable_lookup(command);
>          if (cmd) {
> -            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
> +            printf("Usage: xl [-vf%s] %s %s\n\n%s.\n\n",
>                     cmd->can_dryrun ? "N" : "",
>                     cmd->cmd_name,
>                     cmd->cmd_usage,
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index f461a2a..5509126 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -19,7 +19,7 @@
> 
>  struct cmd_spec cmd_table[] = {
>      { "create",
> -      &main_create, 1,
> +      &main_create, 1, 1,
>        "Create a domain from config file <filename>",
>        "<ConfigFile> [options] [vars]",
>        "-h                      Print this help.\n"
> @@ -33,7 +33,7 @@ struct cmd_spec cmd_table[] = {
>        "-e                      Do not wait in the background for the death of the domain."
>      },
>      { "config-update",
> -      &main_config_update, 1,
> +      &main_config_update, 1, 1,
>        "Update a running domain's saved configuration, used when rebuilding "
>        "the domain after reboot",
>        "<Domain> <ConfigFile> [options] [vars]",
> @@ -42,7 +42,7 @@ struct cmd_spec cmd_table[] = {
>        "-d                      Enable debug messages.\n"
>      },
>      { "list",
> -      &main_list, 0,
> +      &main_list, 0, 0,
>        "List information about all/some domains",
>        "[options] [Domain]\n",
>        "-l, --long              Output all VM details\n"
> @@ -50,12 +50,12 @@ struct cmd_spec cmd_table[] = {
>        "-Z, --context           Prints out security context"
>      },
>      { "destroy",
> -      &main_destroy, 0,
> +      &main_destroy, 0, 1,
>        "Terminate a domain immediately",
>        "<Domain>",
>      },
>      { "shutdown",
> -      &main_shutdown, 0,
> +      &main_shutdown, 0, 1,
>        "Issue a shutdown signal to a domain",
>        "[options] <Domain>",
>        "-h                      Print this help.\n"
> @@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
>        "-w                      Wait for guest to shutdown.\n"
>      },
>      { "reboot",
> -      &main_reboot, 0,
> +      &main_reboot, 0, 1,
>        "Issue a reboot signal to a domain",
>        "[options] <Domain>",
>        "-h                      Print this help.\n"
> @@ -72,44 +72,44 @@ struct cmd_spec cmd_table[] = {
>        "                        no PV drivers.\n"
>      },
>      { "pci-attach",
> -      &main_pciattach, 0,
> +      &main_pciattach, 0, 1,
>        "Insert a new pass-through pci device",
>        "<Domain> <BDF> [Virtual Slot]",
>      },
>      { "pci-detach",
> -      &main_pcidetach, 0,
> +      &main_pcidetach, 0, 1,
>        "Remove a domain's pass-through pci device",
>        "<Domain> <BDF>",
>      },
>      { "pci-list",
> -      &main_pcilist, 0,
> +      &main_pcilist, 0, 0,
>        "List pass-through pci devices for a domain",
>        "<Domain>",
>      },
>      { "pci-list-assignable-devices",
> -      &main_pcilist_assignable, 0,
> +      &main_pcilist_assignable, 0, 0,
>        "List all the assignable pci devices",
>        "",
>      },
>      { "pause",
> -      &main_pause, 0,
> +      &main_pause, 0, 1,
>        "Pause execution of a domain",
>        "<Domain>",
>      },
>      { "unpause",
> -      &main_unpause, 0,
> +      &main_unpause, 0, 1,
>        "Unpause a paused domain",
>        "<Domain>",
>      },
>      { "console",
> -      &main_console, 0,
> +      &main_console, 0, 0,
>        "Attach to domain's console",
>        "[options] <Domain>\n"
>        "-t <type>       console type, pv or serial\n"
>        "-n <number>     console number"
>      },
>      { "vncviewer",
> -      &main_vncviewer, 0,
> +      &main_vncviewer, 0, 0,
>        "Attach to domain's VNC server.",
>        "[options] <Domain>\n"
>        "--autopass               Pass VNC password to viewer via stdin and\n"
> @@ -117,14 +117,14 @@ struct cmd_spec cmd_table[] = {
>        "--vncviewer-autopass     (consistency alias for --autopass)"
>      },
>      { "save",
> -      &main_save, 0,
> +      &main_save, 0, 1,
>        "Save a domain state to restore later",
>        "[options] <Domain> <CheckpointFile> [<ConfigFile>]",
>        "-h  Print this help.\n"
>        "-c  Leave domain running after creating the snapshot."
>      },
>      { "migrate",
> -      &main_migrate, 0,
> +      &main_migrate, 0, 1,
>        "Save a domain state to restore later",
>        "[options] <Domain> <host>",
>        "-h              Print this help.\n"
> @@ -136,12 +136,12 @@ struct cmd_spec cmd_table[] = {
>        "                of the domain."
>      },
>      { "dump-core",
> -      &main_dump_core, 0,
> +      &main_dump_core, 0, 1,
>        "Core dump a domain",
>        "<Domain> <filename>"
>      },
>      { "restore",
> -      &main_restore, 0,
> +      &main_restore, 0, 1,
>        "Restore a domain from a saved state",
>        "[options] [<ConfigFile>] <CheckpointFile>",
>        "-h  Print this help.\n"
> @@ -150,68 +150,68 @@ struct cmd_spec cmd_table[] = {
>        "-d  Enable debug messages."
>      },
>      { "migrate-receive",
> -      &main_migrate_receive, 0,
> +      &main_migrate_receive, 0, 1,
>        "Restore a domain from a saved state",
>        "- for internal use only",
>      },
>      { "cd-insert",
> -      &main_cd_insert, 0,
> +      &main_cd_insert, 0, 1,
>        "Insert a cdrom into a guest's cd drive",
>        "<Domain> <VirtualDevice> <type:path>",
>      },
>      { "cd-eject",
> -      &main_cd_eject, 0,
> +      &main_cd_eject, 0, 1,
>        "Eject a cdrom from a guest's cd drive",
>        "<Domain> <VirtualDevice>",
>      },
>      { "mem-max",
> -      &main_memmax, 0,
> +      &main_memmax, 0, 1,
>        "Set the maximum amount reservation for a domain",
>        "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
>      },
>      { "mem-set",
> -      &main_memset, 0,
> +      &main_memset, 0, 1,
>        "Set the current memory usage for a domain",
>        "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
>      },
>      { "button-press",
> -      &main_button_press, 0,
> +      &main_button_press, 0, 1,
>        "Indicate an ACPI button press to the domain",
>        "<Domain> <Button>",
>        "<Button> may be 'power' or 'sleep'."
>      },
>      { "vcpu-list",
> -      &main_vcpulist, 0,
> +      &main_vcpulist, 0, 0,
>        "List the VCPUs for all/some domains",
>        "[Domain, ...]",
>      },
>      { "vcpu-pin",
> -      &main_vcpupin, 0,
> +      &main_vcpupin, 0, 1,
>        "Set which CPUs a VCPU can use",
>        "<Domain> <VCPU|all> <CPUs|all>",
>      },
>      { "vcpu-set",
> -      &main_vcpuset, 0,
> +      &main_vcpuset, 0, 1,
>        "Set the number of active VCPUs allowed for the domain",
>        "<Domain> <vCPUs>",
>      },
>      { "list-vm",
> -      &main_list_vm, 0,
> +      &main_list_vm, 0, 0,
>        "List the VMs,without DOM0",
>        "",
>      },
>      { "info",
> -      &main_info, 0,
> +      &main_info, 0, 0,
>        "Get information about Xen host",
>        "-n, --numa         List host NUMA topology information",
>      },
>      { "sharing",
> -      &main_sharing, 0,
> +      &main_sharing, 0, 0,
>        "Get information about page sharing",
>        "[Domain]",
>      },
>      { "sched-credit",
> -      &main_sched_credit, 0,
> +      &main_sched_credit, 0, 1,
>        "Get/set credit scheduler parameters",
>        "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
>        "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
> @@ -223,7 +223,7 @@ struct cmd_spec cmd_table[] = {
>        "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
>      },
>      { "sched-credit2",
> -      &main_sched_credit2, 0,
> +      &main_sched_credit2, 0, 1,
>        "Get/set credit2 scheduler parameters",
>        "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
>        "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
> @@ -231,7 +231,7 @@ struct cmd_spec cmd_table[] = {
>        "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
>      },
>      { "sched-sedf",
> -      &main_sched_sedf, 0,
> +      &main_sched_sedf, 0, 1,
>        "Get/set sedf scheduler parameters",
>        "[options]",
>        "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
> @@ -247,109 +247,109 @@ struct cmd_spec cmd_table[] = {
>        "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
>      },
>      { "domid",
> -      &main_domid, 0,
> +      &main_domid, 0, 0,
>        "Convert a domain name to domain id",
>        "<DomainName>",
>      },
>      { "domname",
> -      &main_domname, 0,
> +      &main_domname, 0, 0,
>        "Convert a domain id to domain name",
>        "<DomainId>",
>      },
>      { "rename",
> -      &main_rename, 0,
> +      &main_rename, 0, 1,
>        "Rename a domain",
>        "<Domain> <NewDomainName>",
>      },
>      { "trigger",
> -      &main_trigger, 0,
> +      &main_trigger, 0, 1,
>        "Send a trigger to a domain",
>        "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
>      },
>      { "sysrq",
> -      &main_sysrq, 0,
> +      &main_sysrq, 0, 1,
>        "Send a sysrq to a domain",
>        "<Domain> <letter>",
>      },
>      { "debug-keys",
> -      &main_debug_keys, 0,
> +      &main_debug_keys, 0, 1,
>        "Send debug keys to Xen",
>        "<Keys>",
>      },
>      { "dmesg",
> -      &main_dmesg, 0,
> +      &main_dmesg, 0, 0,
>        "Read and/or clear dmesg buffer",
>        "[-c]",
>        "  -c                        Clear dmesg buffer as well as printing it",
>      },
>      { "top",
> -      &main_top, 0,
> +      &main_top, 0, 0,
>        "Monitor a host and the domains in real time",
>        "",
>      },
>      { "network-attach",
> -      &main_networkattach, 0,
> +      &main_networkattach, 0, 1,
>        "Create a new virtual network device",
>        "<Domain> [type=<type>] [mac=<mac>] [bridge=<bridge>] "
>        "[ip=<ip>] [script=<script>] [backend=<BackDomain>] [vifname=<name>] "
>        "[rate=<rate>] [model=<model>] [accel=<accel>]",
>      },
>      { "network-list",
> -      &main_networklist, 0,
> +      &main_networklist, 0, 0,
>        "List virtual network interfaces for a domain",
>        "<Domain(s)>",
>      },
>      { "network-detach",
> -      &main_networkdetach, 0,
> +      &main_networkdetach, 0, 1,
>        "Destroy a domain's virtual network device",
>        "<Domain> <DevId|mac>",
>      },
>      { "block-attach",
> -      &main_blockattach, 1,
> +      &main_blockattach, 1, 1,
>        "Create a new virtual block device",
>        "<Domain> <disk-spec-component(s)>...",
>      },
>      { "block-list",
> -      &main_blocklist, 0,
> +      &main_blocklist, 0, 0,
>        "List virtual block devices for a domain",
>        "<Domain(s)>",
>      },
>      { "block-detach",
> -      &main_blockdetach, 0,
> +      &main_blockdetach, 0, 1,
>        "Destroy a domain's virtual block device",
>        "<Domain> <DevId>",
>      },
>      { "uptime",
> -      &main_uptime, 0,
> +      &main_uptime, 0, 0,
>        "Print uptime for all/some domains",
>        "[-s] [Domain]",
>      },
>      { "tmem-list",
> -      &main_tmem_list, 0,
> +      &main_tmem_list, 0, 0,
>        "List tmem pools",
>        "[-l] [<Domain>|-a]",
>        "  -l                             List tmem stats",
>      },
>      { "tmem-freeze",
> -      &main_tmem_freeze, 0,
> +      &main_tmem_freeze, 0, 1,
>        "Freeze tmem pools",
>        "[<Domain>|-a]",
>        "  -a                             Freeze all tmem",
>      },
>      { "tmem-destroy",
> -      &main_tmem_destroy, 0,
> +      &main_tmem_destroy, 0, 1,
>        "Destroy tmem pools",
>        "[<Domain>|-a]",
>        "  -a                             Destroy all tmem",
>      },
>      { "tmem-thaw",
> -      &main_tmem_thaw, 0,
> +      &main_tmem_thaw, 0, 1,
>        "Thaw tmem pools",
>        "[<Domain>|-a]",
>        "  -a                             Thaw all tmem",
>      },
>      { "tmem-set",
> -      &main_tmem_set, 0,
> +      &main_tmem_set, 0, 1,
>        "Change tmem settings",
>        "[<Domain>|-a] [-w[=WEIGHT]|-c[=CAP]|-p[=COMPRESS]]",
>        "  -a                             Operate on all tmem\n"
> @@ -358,7 +358,7 @@ struct cmd_spec cmd_table[] = {
>        "  -p COMPRESS                    Compress (int)",
>      },
>      { "tmem-shared-auth",
> -      &main_tmem_shared_auth, 0,
> +      &main_tmem_shared_auth, 0, 1,
>        "De/authenticate shared tmem pool",
>        "[<Domain>|-a] [-u[=UUID] [-A[=AUTH]",
>        "  -a                             Authenticate for all tmem pools\n"
> @@ -367,12 +367,12 @@ struct cmd_spec cmd_table[] = {
>        "  -A AUTH                        0=auth,1=deauth",
>      },
>      { "tmem-freeable",
> -      &main_tmem_freeable, 0,
> +      &main_tmem_freeable, 0, 0,
>        "Get information about how much freeable memory (MB) is in-use by tmem",
>        "",
>      },
>      { "cpupool-create",
> -      &main_cpupoolcreate, 1,
> +      &main_cpupoolcreate, 1, 1,
>        "Create a CPU pool based an ConfigFile",
>        "[options] <ConfigFile> [vars]",
>        "-h, --help                   Print this help.\n"
> @@ -381,53 +381,53 @@ struct cmd_spec cmd_table[] = {
>        "                              (deprecated in favour of global -N option)."
>      },
>      { "cpupool-list",
> -      &main_cpupoollist, 0,
> +      &main_cpupoollist, 0, 0,
>        "List CPU pools on host",
>        "[-c|--cpus] [<CPU Pool>]",
>        "-c, --cpus                     Output list of CPUs used by a pool"
>      },
>      { "cpupool-destroy",
> -      &main_cpupooldestroy, 0,
> +      &main_cpupooldestroy, 0, 1,
>        "Deactivates a CPU pool",
>        "<CPU Pool>",
>      },
>      { "cpupool-rename",
> -      &main_cpupoolrename, 0,
> +      &main_cpupoolrename, 0, 1,
>        "Renames a CPU pool",
>        "<CPU Pool> <new name>",
>      },
>      { "cpupool-cpu-add",
> -      &main_cpupoolcpuadd, 0,
> +      &main_cpupoolcpuadd, 0, 1,
>        "Adds a CPU to a CPU pool",
>        "<CPU Pool> <CPU nr>|node:<node nr>",
>      },
>      { "cpupool-cpu-remove",
> -      &main_cpupoolcpuremove, 0,
> +      &main_cpupoolcpuremove, 0, 1,
>        "Removes a CPU from a CPU pool",
>        "<CPU Pool> <CPU nr>|node:<node nr>",
>      },
>      { "cpupool-migrate",
> -      &main_cpupoolmigrate, 0,
> +      &main_cpupoolmigrate, 0, 1,
>        "Moves a domain into a CPU pool",
>        "<Domain> <CPU Pool>",
>      },
>      { "cpupool-numa-split",
> -      &main_cpupoolnumasplit, 0,
> +      &main_cpupoolnumasplit, 0, 1,
>        "Splits up the machine into one CPU pool per NUMA node",
>        "",
>      },
>      { "getenforce",
> -      &main_getenforce, 0,
> +      &main_getenforce, 0, 0,
>        "Returns the current enforcing mode of the Flask Xen security module",
>        "",
>      },
>      { "setenforce",
> -      &main_setenforce, 0,
> +      &main_setenforce, 0, 1,
>        "Sets the current enforcing mode of the Flask Xen security module",
>        "<1|0|Enforcing|Permissive>",
>      },
>      { "loadpolicy",
> -      &main_loadpolicy, 0,
> +      &main_loadpolicy, 0, 1,
>        "Loads a new policy int the Flask Xen security module",
>        "<policy file>",
>      },
> --
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:24:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMySt-0008Gh-4X; Wed, 25 Apr 2012 09:24:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMySs-0008GT-8p
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:24:46 +0000
Received: from [85.158.138.51:64308] by server-4.bemta-3.messagelabs.com id
	CA/F7-15341-DD2C79F4; Wed, 25 Apr 2012 09:24:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335345883!19334778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19999 invoked from network); 25 Apr 2012 09:24:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:24:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191955390"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 05:24:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 05:24:42 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SMySo-0005g3-IH;
	Wed, 25 Apr 2012 10:24:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 057516cb84336da09fe3163aeeb9039cf4d20c26
Message-ID: <057516cb84336da09fe3.1335345882@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Apr 2012 10:24:42 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: waldi@debian.org, Ian.Jackson@citrix.com
Subject: [Xen-devel] [PATCH] docs: use "a4" not "a4wide" paper type for
	doxygen and latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335345862 -3600
# Node ID 057516cb84336da09fe3163aeeb9039cf4d20c26
# Parent  5d796144e8a276ea843c5ad5ec4ae678194d50f3
docs: use "a4" not "a4wide" paper type for doxygen and latex

a4wide is no longer shipped in texlive.

Reported by Bastian Blank
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

Bastian provided a patch for the latex part but no Signed-off-by, I have
trivially reimplemented that part of the fix from his description.

diff -r 5d796144e8a2 -r 057516cb8433 docs/Doxyfile
--- a/docs/Doxyfile	Wed Apr 25 10:17:10 2012 +0100
+++ b/docs/Doxyfile	Wed Apr 25 10:24:22 2012 +0100
@@ -747,7 +747,7 @@ COMPACT_LATEX          = NO
 # by the printer. Possible values are: a4, a4wide, letter, legal and 
 # executive. If left blank a4wide will be used.
 
-PAPER_TYPE             = a4wide
+PAPER_TYPE             = a4
 
 # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
 # packages that should be included in the LaTeX output.
diff -r 5d796144e8a2 -r 057516cb8433 docs/xen-api/xenapi.tex
--- a/docs/xen-api/xenapi.tex	Wed Apr 25 10:17:10 2012 +0100
+++ b/docs/xen-api/xenapi.tex	Wed Apr 25 10:24:22 2012 +0100
@@ -13,7 +13,7 @@
 
 \documentclass{report}
 
-\usepackage{a4wide}
+\usepackage{a4}
 \usepackage{graphics}
 \usepackage{longtable}
 \usepackage{fancyhdr}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:24:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMySt-0008Gh-4X; Wed, 25 Apr 2012 09:24:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMySs-0008GT-8p
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:24:46 +0000
Received: from [85.158.138.51:64308] by server-4.bemta-3.messagelabs.com id
	CA/F7-15341-DD2C79F4; Wed, 25 Apr 2012 09:24:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335345883!19334778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19999 invoked from network); 25 Apr 2012 09:24:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:24:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191955390"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 05:24:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 05:24:42 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SMySo-0005g3-IH;
	Wed, 25 Apr 2012 10:24:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 057516cb84336da09fe3163aeeb9039cf4d20c26
Message-ID: <057516cb84336da09fe3.1335345882@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Apr 2012 10:24:42 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: waldi@debian.org, Ian.Jackson@citrix.com
Subject: [Xen-devel] [PATCH] docs: use "a4" not "a4wide" paper type for
	doxygen and latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335345862 -3600
# Node ID 057516cb84336da09fe3163aeeb9039cf4d20c26
# Parent  5d796144e8a276ea843c5ad5ec4ae678194d50f3
docs: use "a4" not "a4wide" paper type for doxygen and latex

a4wide is no longer shipped in texlive.

Reported by Bastian Blank
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

Bastian provided a patch for the latex part but no Signed-off-by, I have
trivially reimplemented that part of the fix from his description.

diff -r 5d796144e8a2 -r 057516cb8433 docs/Doxyfile
--- a/docs/Doxyfile	Wed Apr 25 10:17:10 2012 +0100
+++ b/docs/Doxyfile	Wed Apr 25 10:24:22 2012 +0100
@@ -747,7 +747,7 @@ COMPACT_LATEX          = NO
 # by the printer. Possible values are: a4, a4wide, letter, legal and 
 # executive. If left blank a4wide will be used.
 
-PAPER_TYPE             = a4wide
+PAPER_TYPE             = a4
 
 # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
 # packages that should be included in the LaTeX output.
diff -r 5d796144e8a2 -r 057516cb8433 docs/xen-api/xenapi.tex
--- a/docs/xen-api/xenapi.tex	Wed Apr 25 10:17:10 2012 +0100
+++ b/docs/xen-api/xenapi.tex	Wed Apr 25 10:24:22 2012 +0100
@@ -13,7 +13,7 @@
 
 \documentclass{report}
 
-\usepackage{a4wide}
+\usepackage{a4}
 \usepackage{graphics}
 \usepackage{longtable}
 \usepackage{fancyhdr}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyV0-0008TM-O0; Wed, 25 Apr 2012 09:26:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMyUz-0008T1-5j
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:26:57 +0000
Received: from [85.158.143.99:17361] by server-2.bemta-4.messagelabs.com id
	06/CF-17550-063C79F4; Wed, 25 Apr 2012 09:26:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335346015!13975362!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1690 invoked from network); 25 Apr 2012 09:26:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 09:26:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 10:26:54 +0100
Message-Id: <4F97DF91020000780007FE82@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 10:27:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>, <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1334875170 14400
> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Wei Huang <wei.huang2@amd.com>
> Tested-by: Wei Huang <wei.huang2@amd.com>

So what's the status of the discussion around this patch? Were
your concerns all addressed, Dan? Is there any re-submisson
necessary/planned?

Jan

> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>  {
>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>  
>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
> -    if ( enable )
> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
> +
> +    if ( enable && !cpu_has_tsc_ratio ) {
>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
> +    }
>  
>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>  }
>  
>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyV0-0008TM-O0; Wed, 25 Apr 2012 09:26:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SMyUz-0008T1-5j
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:26:57 +0000
Received: from [85.158.143.99:17361] by server-2.bemta-4.messagelabs.com id
	06/CF-17550-063C79F4; Wed, 25 Apr 2012 09:26:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335346015!13975362!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1690 invoked from network); 25 Apr 2012 09:26:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 09:26:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 10:26:54 +0100
Message-Id: <4F97DF91020000780007FE82@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 10:27:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>, <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
In-Reply-To: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1334875170 14400
> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Wei Huang <wei.huang2@amd.com>
> Tested-by: Wei Huang <wei.huang2@amd.com>

So what's the status of the discussion around this patch? Were
your concerns all addressed, Dan? Is there any re-submisson
necessary/planned?

Jan

> diff -r 7c777cb8f705 -r 55bf11ebce87 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Wed Apr 18 16:49:55 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Thu Apr 19 18:39:30 2012 -0400
> @@ -724,12 +724,18 @@ static void svm_set_rdtsc_exiting(struct
>  {
>      struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
> +    u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb);
>  
>      general1_intercepts &= ~GENERAL1_INTERCEPT_RDTSC;
> -    if ( enable )
> +    general2_intercepts &= ~GENERAL2_INTERCEPT_RDTSCP;
> +
> +    if ( enable && !cpu_has_tsc_ratio ) {
>          general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
> +        general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;
> +    }
>  
>      vmcb_set_general1_intercepts(vmcb, general1_intercepts);
> +    vmcb_set_general2_intercepts(vmcb, general2_intercepts);
>  }
>  
>  static unsigned int svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:39:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyh4-0000HT-59; Wed, 25 Apr 2012 09:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SMyh3-0000HO-5N
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 09:39:25 +0000
Received: from [85.158.139.83:45677] by server-5.bemta-5.messagelabs.com id
	BB/E8-13566-C46C79F4; Wed, 25 Apr 2012 09:39:24 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335346763!21524496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24383 invoked from network); 25 Apr 2012 09:39:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12126316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:39:23 +0000
Received: from [127.0.1.1] (10.80.3.206) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:39:23 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8b1e0a2ccd7f4e00b5e614472d8987d7d4c5a8c0
Message-ID: <8b1e0a2ccd7f4e00b5e6.1335346757@malcolmc-Precision-WorkStation-T3500>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 25 Apr 2012 10:39:17 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
To: xen-devel@lists.xensource.com
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH] xen: Fix memory hotplug epfn upper limit test
 for updating the compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The epfn is being compared to (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) without a 2 bit shift, resulting in the epfn being compared to the size of the RDWR_COMPAT_MPT table in bytes instead of the maximum page frame number that the RDWR_COMPAT_MPT table can map.

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>

diff -r 274e5accd62d -r 8b1e0a2ccd7f xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -454,7 +454,7 @@ static int setup_compat_m2p_table(struct
     if   ((smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2)) )
         return 0;
 
-    if (epfn > (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
+    if ( epfn > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) )
         epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
 
     emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:39:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyh4-0000HT-59; Wed, 25 Apr 2012 09:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SMyh3-0000HO-5N
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 09:39:25 +0000
Received: from [85.158.139.83:45677] by server-5.bemta-5.messagelabs.com id
	BB/E8-13566-C46C79F4; Wed, 25 Apr 2012 09:39:24 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335346763!21524496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24383 invoked from network); 25 Apr 2012 09:39:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12126316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:39:23 +0000
Received: from [127.0.1.1] (10.80.3.206) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:39:23 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8b1e0a2ccd7f4e00b5e614472d8987d7d4c5a8c0
Message-ID: <8b1e0a2ccd7f4e00b5e6.1335346757@malcolmc-Precision-WorkStation-T3500>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 25 Apr 2012 10:39:17 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
To: xen-devel@lists.xensource.com
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH] xen: Fix memory hotplug epfn upper limit test
 for updating the compat M2P table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The epfn is being compared to (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) without a 2 bit shift, resulting in the epfn being compared to the size of the RDWR_COMPAT_MPT table in bytes instead of the maximum page frame number that the RDWR_COMPAT_MPT table can map.

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>

diff -r 274e5accd62d -r 8b1e0a2ccd7f xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -454,7 +454,7 @@ static int setup_compat_m2p_table(struct
     if   ((smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2)) )
         return 0;
 
-    if (epfn > (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
+    if ( epfn > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) )
         epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
 
     emap = ( (epfn + ((1UL << (L2_PAGETABLE_SHIFT - 2)) - 1 )) &

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:53:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyuB-0000Th-GI; Wed, 25 Apr 2012 09:52:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyu9-0000Tc-Eh
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:52:57 +0000
Received: from [85.158.143.99:26517] by server-1.bemta-4.messagelabs.com id
	41/1B-20925-879C79F4; Wed, 25 Apr 2012 09:52:56 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335347574!15549336!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2993 invoked from network); 25 Apr 2012 09:52:55 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:52:55 -0000
Received: from mail115-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:52:53 +0000
Received: from mail115-tx2 (localhost [127.0.0.1])	by
	mail115-tx2-R.bigfish.com (Postfix) with ESMTP id 5DF2F34033A;
	Wed, 25 Apr 2012 09:52:53 +0000 (UTC)
X-SpamScore: -14
X-BigFish: VPS-14(zzbb2dI936eK146fI1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail115-tx2 (localhost.localdomain [127.0.0.1]) by mail115-tx2
	(MessageSwitch) id 1335347571517765_10559;
	Wed, 25 Apr 2012 09:52:51 +0000 (UTC)
Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.248])	by
	mail115-tx2.bigfish.com (Postfix) with ESMTP id 76AB560119;
	Wed, 25 Apr 2012 09:52:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:52:50 +0000
X-WSS-ID: 0M314S0-01-0PE-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AF8710280AC;	Wed, 25 Apr 2012 04:52:48 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:52:59 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:52:48 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:52:47 -0400
Message-ID: <4F97C96E.8030401@amd.com>
Date: Wed, 25 Apr 2012 11:52:46 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com> <4F97C041.50205@amd.com>
	<1335345652.28015.12.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335345652.28015.12.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:20, Ian Campbell wrote:

> On Wed, 2012-04-25 at 10:13 +0100, Christoph Egger wrote:
>> On 04/25/12 11:10, Christoph Egger wrote:
>>
>>> On 04/25/12 10:52, Ian Campbell wrote:
>>>
>>>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>>>
>>>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>>>
>>>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>>>> use same python binary as whole xen tree does.
>>>>>>>> Fixes build error on NetBSD.
>>>>>>>
>>>>>>> Ian, does this look sensible to you ?
>>>>>>
>>>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>>>> is OK, so we might as well take this now.
>>>>>
>>>>>
>>>>> Thanks.
>>>
>>>>>
>>>
>>>>>> Does
>>>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>>>> (or something similar) work? Might be a better option in the future
>>>>>
>>>>> No, this doesn't work.
>>>>
>>>> What about
>>>> subdir-all-seabios: PYTHON=...
>>>> ?
>>>
>>>
>>> No, doesn't work. I also tried without success:
>>>
>>> subdirs-all-seabios
>>> subdir-all-seabios-dir
>>> subdirs-all-seabios-dir
>>> seabios-dir
>>
>> I found something that works:
>>
>> subdir-all-seabios-dir:
>> 	export PYTHON=$(PYTHON)
> 
> Really, that's not a syntax I've ever seen before, I've no idea how that
> works, all on the same line, sure, but on the next line like that, odd!.
> I would have thought that this would have caused "export PYTHON=
> $(PYTHON)" to be run it its own new subshell which would immediately
> exit.
> 
> Anyway, I guess if it works we might as well use this version...


No, it doesn't. It causes a subsequent seabios build error about
a missing build rule. I should have waited with reporting this
till the build finished.

Christoph

 
> 
> 
> Ian.
> 
>>
>> Christoph
>>>
>>>>>>>
>>>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>>>
>>>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------------
>>>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>>>  	false ; \
>>>>>>>>  	fi
>>>>>>>>  endif
>>>>>>>> -	$(MAKE) subdirs-$@
>>>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  .PHONY: install
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------------
>>>
>>>
>>
>>
>>
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:53:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMyuB-0000Th-GI; Wed, 25 Apr 2012 09:52:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SMyu9-0000Tc-Eh
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:52:57 +0000
Received: from [85.158.143.99:26517] by server-1.bemta-4.messagelabs.com id
	41/1B-20925-879C79F4; Wed, 25 Apr 2012 09:52:56 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335347574!15549336!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2993 invoked from network); 25 Apr 2012 09:52:55 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 09:52:55 -0000
Received: from mail115-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:52:53 +0000
Received: from mail115-tx2 (localhost [127.0.0.1])	by
	mail115-tx2-R.bigfish.com (Postfix) with ESMTP id 5DF2F34033A;
	Wed, 25 Apr 2012 09:52:53 +0000 (UTC)
X-SpamScore: -14
X-BigFish: VPS-14(zzbb2dI936eK146fI1432N98dKzz1202hzz8275bhz2dh668h839h93fhd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail115-tx2 (localhost.localdomain [127.0.0.1]) by mail115-tx2
	(MessageSwitch) id 1335347571517765_10559;
	Wed, 25 Apr 2012 09:52:51 +0000 (UTC)
Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.248])	by
	mail115-tx2.bigfish.com (Postfix) with ESMTP id 76AB560119;
	Wed, 25 Apr 2012 09:52:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 09:52:50 +0000
X-WSS-ID: 0M314S0-01-0PE-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AF8710280AC;	Wed, 25 Apr 2012 04:52:48 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 04:52:59 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 25 Apr 2012 04:52:48 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	05:52:47 -0400
Message-ID: <4F97C96E.8030401@amd.com>
Date: Wed, 25 Apr 2012 11:52:46 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
	<4F97B941.7000108@amd.com>
	<1335343957.28015.1.camel@zakaz.uk.xensource.com>
	<4F97BF95.6050209@amd.com> <4F97C041.50205@amd.com>
	<1335345652.28015.12.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335345652.28015.12.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/12 11:20, Ian Campbell wrote:

> On Wed, 2012-04-25 at 10:13 +0100, Christoph Egger wrote:
>> On 04/25/12 11:10, Christoph Egger wrote:
>>
>>> On 04/25/12 10:52, Ian Campbell wrote:
>>>
>>>> On Wed, 2012-04-25 at 09:43 +0100, Christoph Egger wrote:
>>>>> On 04/25/12 10:07, Ian Campbell wrote:
>>>>>
>>>>>> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
>>>>>>> Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
>>>>>>>>
>>>>>>>> Pass PYTHON down to seabios, so seabios will
>>>>>>>> use same python binary as whole xen tree does.
>>>>>>>> Fixes build error on NetBSD.
>>>>>>>
>>>>>>> Ian, does this look sensible to you ?
>>>>>>
>>>>>> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
>>>>>> is OK, so we might as well take this now.
>>>>>
>>>>>
>>>>> Thanks.
>>>
>>>>>
>>>
>>>>>> Does
>>>>>> subdirs-seabios: PYTHON=$(PYTHON)
>>>>>> (or something similar) work? Might be a better option in the future
>>>>>
>>>>> No, this doesn't work.
>>>>
>>>> What about
>>>> subdir-all-seabios: PYTHON=...
>>>> ?
>>>
>>>
>>> No, doesn't work. I also tried without success:
>>>
>>> subdirs-all-seabios
>>> subdir-all-seabios-dir
>>> subdirs-all-seabios-dir
>>> seabios-dir
>>
>> I found something that works:
>>
>> subdir-all-seabios-dir:
>> 	export PYTHON=$(PYTHON)
> 
> Really, that's not a syntax I've ever seen before, I've no idea how that
> works, all on the same line, sure, but on the next line like that, odd!.
> I would have thought that this would have caused "export PYTHON=
> $(PYTHON)" to be run it its own new subshell which would immediately
> exit.
> 
> Anyway, I guess if it works we might as well use this version...


No, it doesn't. It causes a subsequent seabios build error about
a missing build rule. I should have waited with reporting this
till the build finished.

Christoph

 
> 
> 
> Ian.
> 
>>
>> Christoph
>>>
>>>>>>>
>>>>>>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>>>>>
>>>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------------
>>>>>>>> diff -r ab552da976a3 tools/firmware/Makefile
>>>>>>>> --- a/tools/firmware/Makefile	Wed Apr 11 18:28:33 2012 +0200
>>>>>>>> +++ b/tools/firmware/Makefile	Fri Apr 13 16:22:23 2012 +0200
>>>>>>>> @@ -32,7 +32,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>>>>>>>>  	false ; \
>>>>>>>>  	fi
>>>>>>>>  endif
>>>>>>>> -	$(MAKE) subdirs-$@
>>>>>>>> +	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  .PHONY: install
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------------
>>>
>>>
>>
>>
>>
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz0E-0000bq-AU; Wed, 25 Apr 2012 09:59:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMz0C-0000bk-1t
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:59:12 +0000
Received: from [85.158.143.35:17140] by server-3.bemta-4.messagelabs.com id
	F9/FD-05853-FEAC79F4; Wed, 25 Apr 2012 09:59:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335347950!8672114!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2274 invoked from network); 25 Apr 2012 09:59:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:59:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12126870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:59:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:59:10 +0100
Message-ID: <1335347949.28015.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 10:59:09 +0100
In-Reply-To: <20369.17085.330843.561841@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> > > I'm not quite up to speed with all the context here but is the reason
> > > that you're not suggesting "xen-" is that that's already used for
> > > something else ?
> > 
> > This is to distinguish the vif device from the associated tap device,
> > which would otherwise both be called whatever the user gave as "vifname"
> > in their config, so for vifname=foo you would get foo (the PV one) and
> > xen-foo (the EMU one) which does the job but doesn't really distinguish
> > them.
> 
> Ah, I see.  This sounds like more a job for a suffix than a prefix so
> if we can spare 4 chars I would suggest foo-emu.

So for vifname="foo" it is a no-brainer to call the vif "foo" and the
emulated tap device "foo-emu".

But what about the case where no vifname is given, in that case vif is
named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 09:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 09:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz0E-0000bq-AU; Wed, 25 Apr 2012 09:59:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMz0C-0000bk-1t
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 09:59:12 +0000
Received: from [85.158.143.35:17140] by server-3.bemta-4.messagelabs.com id
	F9/FD-05853-FEAC79F4; Wed, 25 Apr 2012 09:59:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335347950!8672114!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2274 invoked from network); 25 Apr 2012 09:59:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 09:59:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12126870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:59:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:59:10 +0100
Message-ID: <1335347949.28015.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 10:59:09 +0100
In-Reply-To: <20369.17085.330843.561841@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > On Fri, 2012-04-20 at 11:55 +0100, Ian Jackson wrote:
> > > I'm not quite up to speed with all the context here but is the reason
> > > that you're not suggesting "xen-" is that that's already used for
> > > something else ?
> > 
> > This is to distinguish the vif device from the associated tap device,
> > which would otherwise both be called whatever the user gave as "vifname"
> > in their config, so for vifname=foo you would get foo (the PV one) and
> > xen-foo (the EMU one) which does the job but doesn't really distinguish
> > them.
> 
> Ah, I see.  This sounds like more a job for a suffix than a prefix so
> if we can spare 4 chars I would suggest foo-emu.

So for vifname="foo" it is a no-brainer to call the vif "foo" and the
emulated tap device "foo-emu".

But what about the case where no vifname is given, in that case vif is
named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:00:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz18-0000iv-PO; Wed, 25 Apr 2012 10:00:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SMz17-0000ii-Iy
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:00:09 +0000
Received: from [85.158.139.83:14682] by server-9.bemta-5.messagelabs.com id
	48/5F-09826-82BC79F4; Wed, 25 Apr 2012 10:00:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335348006!25395433!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6405 invoked from network); 25 Apr 2012 10:00:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:00:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="24515931"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:00:05 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	06:00:05 -0400
Message-ID: <4F97CB24.6030109@citrix.com>
Date: Wed, 25 Apr 2012 11:00:04 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, George
	Dunlap <dunlapg@gmail.com>
Subject: [Xen-devel] [PATCH] xenalyze: add .hgignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 .hgignore |    3 +++
 1 file changed, 3 insertions(+)
diff -r 84d9c7ac3cbf .hgignore
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/.hgignore	Tue Apr 24 18:37:35 2012 +0100
@@ -0,0 +1,3 @@
+.*\.o
+xenalyze
+dump-raw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:00:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz18-0000iv-PO; Wed, 25 Apr 2012 10:00:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SMz17-0000ii-Iy
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:00:09 +0000
Received: from [85.158.139.83:14682] by server-9.bemta-5.messagelabs.com id
	48/5F-09826-82BC79F4; Wed, 25 Apr 2012 10:00:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335348006!25395433!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6405 invoked from network); 25 Apr 2012 10:00:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:00:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="24515931"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:00:05 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	06:00:05 -0400
Message-ID: <4F97CB24.6030109@citrix.com>
Date: Wed, 25 Apr 2012 11:00:04 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, George
	Dunlap <dunlapg@gmail.com>
Subject: [Xen-devel] [PATCH] xenalyze: add .hgignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 .hgignore |    3 +++
 1 file changed, 3 insertions(+)
diff -r 84d9c7ac3cbf .hgignore
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/.hgignore	Tue Apr 24 18:37:35 2012 +0100
@@ -0,0 +1,3 @@
+.*\.o
+xenalyze
+dump-raw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:01:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz1x-0000nJ-7B; Wed, 25 Apr 2012 10:01:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMz1v-0000n2-U5
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:01:00 +0000
Received: from [85.158.143.99:7567] by server-2.bemta-4.messagelabs.com id
	4F/DC-17550-B5BC79F4; Wed, 25 Apr 2012 10:00:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335348058!13981763!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19059 invoked from network); 25 Apr 2012 10:00:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:00:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12126924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:00:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:00:58 +0100
Message-ID: <1335348056.28015.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:00:56 +0100
In-Reply-To: <20374.59940.607143.114201@mariner.uk.xensource.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
	<20374.59940.607143.114201@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <dunlapg@umich.edu>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 19:00 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] Driver domains communication protocol proposal"):
> > On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > >  vdi
> > >     This host's intent to access a specific target.
> > >     Non-persistent, created on request by toolstack, enumerable.
> > >     Possible states: inactive/active.
> > >     Abstract operations: prepare, activate, deactivate, unprepare.
> > 
> > VDI as used by XenServer seems to mean "virtual disk instance", and as
> > such is actually persistent.  I don't quite understand what it's
> > supposed to mean here, and how it differs from VBD (which in XenServer
> > terminology means "virtual block device").
> 
> One "vdi" in this sense can support multiple "vbd"s.  A "vbd"
> represents an attachment to a domain (or some other kind of provision
> for use) whereas a "vdi" is a preparatory thing.
> 
> Feel free to suggest different terminology.

What does the XCP SMAPI call these things? (Jon CCd)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:01:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz1x-0000nJ-7B; Wed, 25 Apr 2012 10:01:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMz1v-0000n2-U5
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:01:00 +0000
Received: from [85.158.143.99:7567] by server-2.bemta-4.messagelabs.com id
	4F/DC-17550-B5BC79F4; Wed, 25 Apr 2012 10:00:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335348058!13981763!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19059 invoked from network); 25 Apr 2012 10:00:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:00:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12126924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:00:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:00:58 +0100
Message-ID: <1335348056.28015.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:00:56 +0100
In-Reply-To: <20374.59940.607143.114201@mariner.uk.xensource.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
	<20374.59940.607143.114201@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <dunlapg@umich.edu>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 19:00 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] Driver domains communication protocol proposal"):
> > On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > >  vdi
> > >     This host's intent to access a specific target.
> > >     Non-persistent, created on request by toolstack, enumerable.
> > >     Possible states: inactive/active.
> > >     Abstract operations: prepare, activate, deactivate, unprepare.
> > 
> > VDI as used by XenServer seems to mean "virtual disk instance", and as
> > such is actually persistent.  I don't quite understand what it's
> > supposed to mean here, and how it differs from VBD (which in XenServer
> > terminology means "virtual block device").
> 
> One "vdi" in this sense can support multiple "vbd"s.  A "vbd"
> represents an attachment to a domain (or some other kind of provision
> for use) whereas a "vdi" is a preparatory thing.
> 
> Feel free to suggest different terminology.

What does the XCP SMAPI call these things? (Jon CCd)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz3m-0000y4-Nj; Wed, 25 Apr 2012 10:02:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SMz3l-0000xp-4Y
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:02:53 +0000
Received: from [193.109.254.147:11733] by server-10.bemta-14.messagelabs.com
	id 04/58-05847-CCBC79F4; Wed, 25 Apr 2012 10:02:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335348170!6220438!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32523 invoked from network); 25 Apr 2012 10:02:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191958629"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:02:49 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	06:02:49 -0400
Message-ID: <4F97CBC8.6010507@citrix.com>
Date: Wed, 25 Apr 2012 11:02:48 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: George Dunlap <george.dunlap@citrix.com>
Subject: [Xen-devel] [PATCH] xenalyze: add a basic plugin infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow xenalyze to be include (at build time) plugins that can do
per-record actions and a summary.  These plugins can be in C or C++.

The plugins entry points are in struct plugin and pointers to all the
plugins linked in xenalyze are placed in a "plugin" section so
plugin_init() can find them all.

A new command line option (-p, --plugin=PLUGIN) is added to enable one
or more plugins.

A sample plugin (skeleton) is included (mostly because at least one
plugin must be present for the build to work).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 Makefile            |   10 +++---
 analyze.h           |   55 ++++++++++++++++++++++++++++++++++
 plugin.cc           |   84 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 plugin.h            |   48 +++++++++++++++++++++++++++++
 plugin.hh           |   42 ++++++++++++++++++++++++++
 plugins/skeleton.cc |   31 +++++++++++++++++++
 xenalyze.c          |   72 +++++++++++++-------------------------------
 7 files changed, 287 insertions(+), 55 deletions(-)
diff -r f4feecb06e49 Makefile
--- a/Makefile	Tue Apr 24 18:37:35 2012 +0100
+++ b/Makefile	Wed Apr 25 10:42:54 2012 +0100
@@ -1,6 +1,6 @@
 CC = gcc
 
-CFLAGS += -g -O2
+CFLAGS += -g -O2 -I.
 CFLAGS += -fno-strict-aliasing
 CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes
@@ -11,9 +11,11 @@ CFLAGS  += -D_LARGEFILE_SOURCE -D_LARGEF
 CFLAGS += -mno-tls-direct-seg-refs
 CFLAGS  += -Werror
 
+CXXFLAGS := -g -O2 -I. -Wall -Werror -std=c++0x
+
 BIN      = xenalyze dump-raw
 
-HDRS = trace.h analyze.h mread.h
+HDRS = trace.h analyze.h mread.h plugin.h plugin.hh
 
 all: $(BIN)
 
@@ -24,5 +26,5 @@ clean:
 %: %.c $(HDRS) Makefile
 	$(CC) $(CFLAGS) -o $@ $<
 
-xenalyze: xenalyze.o mread.o
-	$(CC) $(CFLAGS) -o $@ $^
+xenalyze: xenalyze.o mread.o plugin.o plugins/skeleton.o
+	$(CXX) $(CFLAGS) -o $@ $^
diff -r f4feecb06e49 analyze.h
--- a/analyze.h	Tue Apr 24 18:37:35 2012 +0100
+++ b/analyze.h	Wed Apr 25 10:42:54 2012 +0100
@@ -1,5 +1,8 @@
 #ifndef __ANALYZE_H
 # define __ANALYZE_H
+
+#include <stdint.h>
+
 #define TRC_GEN_MAIN     0
 #define TRC_SCHED_MAIN   1
 #define TRC_DOM0OP_MAIN  2
@@ -47,4 +50,56 @@ enum {
 };
 
 #define TRC_HVM_OP_DESTROY_PROC (TRC_HVM_HANDLER + 0x100)
+
+typedef unsigned long long tsc_t;
+
+/* -- on-disk trace buffer definitions -- */
+struct trace_record {
+    union {
+        struct {
+            unsigned event:28,
+                extra_words:3,
+                cycle_flag:1;
+            union {
+                struct {
+                    uint32_t tsc_lo, tsc_hi;
+                    uint32_t data[7];
+                } tsc;
+                struct {
+                    uint32_t data[7];
+                } notsc;
+            } u;
+        };
+        uint32_t raw[8];
+    };
+};
+
+/* -- General info about a current record -- */
+struct time_struct {
+    unsigned long long time;
+    unsigned int s, ns;
+};
+
+#define DUMP_HEADER_MAX 256
+
+struct record_info {
+    int cpu;
+    tsc_t tsc;
+    union {
+        unsigned event;
+        struct {
+            unsigned minor:12,
+                sub:4,
+                main:12,
+                unused:4;
+        } evt;
+    };
+    int extra_words;
+    int size;
+    uint32_t *d;
+    char dump_header[DUMP_HEADER_MAX];
+    struct time_struct t;
+    struct trace_record rec;
+};
+
 #endif
diff -r f4feecb06e49 plugin.cc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugin.cc	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,84 @@
+/*
+ * Xenalyze plugin infrastructure.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#include <stdio.h>
+#include <string.h>
+#include <list>
+
+#include "plugin.hh"
+
+typedef std::list<struct plugin *> plugin_list;
+
+static plugin_list available;
+static plugin_list enabled;
+
+bool plugin_enable(const char *name)
+{
+    for (auto p = available.begin(); p != available.end(); p++) {
+        struct plugin *plugin = *p;
+        if (strcmp(plugin->name, name) == 0) {
+            enabled.push_back(plugin);
+            if (plugin->enable) {
+                plugin->enable(plugin);
+            }
+            return true;
+        }
+    }
+    return false;
+}
+
+void plugin_process(const struct record_info *ri)
+{
+    for (auto p = enabled.begin(); p != enabled.end(); p++) {
+        struct plugin *plugin = *p;
+        if (plugin->process) {
+            plugin->process(plugin, ri);
+        }
+    }    
+}
+
+void plugin_summary(void)
+{
+    for (auto p = enabled.begin(); p != enabled.end(); p++) {
+        struct plugin *plugin = *p;
+        if (plugin->summary) {
+            printf("Summary for %s plugin:\n", plugin->name);
+            plugin->summary(plugin);
+        }
+    }
+}
+
+static void plugin_add(struct plugin *plugin)
+{
+    available.push_back(plugin);
+}
+
+void plugin_init(void)
+{
+    extern struct plugin *__start_plugin;
+    extern struct plugin *__stop_plugin;
+    struct plugin **p;
+
+    for (p = &__start_plugin; p < &__stop_plugin; p++) {
+        plugin_add(*p);
+    }
+}
+
+void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri)
+{
+    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
+    p->process(ri);
+}
+
+void plugin_summary_wrapper(struct plugin *plugin)
+{
+    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
+    p->summary();
+    delete p;
+}
diff -r f4feecb06e49 plugin.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugin.h	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,48 @@
+/*
+ * Xenalyze plugin C API.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#ifndef PLUGIN_H
+#define PLUGIN_H
+
+#include <stdbool.h>
+
+#include "analyze.h"
+#include "helpers.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+struct plugin;
+
+typedef void (*plugin_enable_f)(struct plugin *plugin);
+typedef void (*plugin_process_f)(struct plugin *plugin, const struct record_info *ri);
+typedef void (*plugin_summary_f)(struct plugin *plugin);
+
+struct plugin {
+    const char *name;
+    plugin_enable_f enable;
+    plugin_process_f process;
+    plugin_summary_f summary;
+    void *data;
+};
+
+#define DEFINE_PLUGIN(p) \
+    struct plugin *__plugin_ ## p __attribute__((section("plugin"))) = &p
+
+void plugin_init(void);
+bool plugin_enable(const char *name);
+void plugin_process(const struct record_info *ri);
+void plugin_summary(void);
+
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
+#endif /* #ifndef PLUGIN_H */
diff -r f4feecb06e49 plugin.hh
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugin.hh	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,42 @@
+/*
+ * Xenalyze plugin C++ API.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#ifndef PLUGIN_HH
+#define PLUGIN_HH
+
+#include "plugin.h"
+
+class xenalyze_plugin {
+public:
+    virtual ~xenalyze_plugin() {}
+
+    virtual void process(const struct record_info *ri) = 0;
+    virtual void summary() = 0;
+};
+
+#define DEFINE_CXX_PLUGIN(name, cls)                                    \
+    static void __plugin_ ## cls ## _enable(struct plugin *plugin)      \
+    {                                                                   \
+        plugin->data = new cls();                                       \
+    }                                                                   \
+                                                                        \
+    static struct plugin __plugin ## cls = {                            \
+        name,                                                           \
+        __plugin_ ## cls ## _enable,                                    \
+        plugin_process_wrapper,                                         \
+        plugin_summary_wrapper,                                         \
+    };                                                                  \
+    DEFINE_PLUGIN(__plugin ## cls)
+
+extern "C" {
+void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri);
+void plugin_summary_wrapper(struct plugin *plugin);
+}
+
+#endif /* #ifndef PLUGIN_HH */
diff -r f4feecb06e49 plugins/skeleton.cc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugins/skeleton.cc	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,31 @@
+/*
+ * Skeleton xenalyze plugin.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#include "plugin.hh"
+
+class skeleton_plugin : xenalyze_plugin {
+public:
+    skeleton_plugin() {}
+    ~skeleton_plugin() {}
+
+    void process(const struct record_info *ri);
+    void summary(void);
+};
+
+void skeleton_plugin::process(const struct record_info *ri)
+{
+    /* Put per-trace record stuff here. */
+}
+
+void skeleton_plugin::summary(void)
+{
+    /* Print a summary of the results (if applicable). */
+}
+
+DEFINE_CXX_PLUGIN("skeleton", skeleton_plugin);
diff -r f4feecb06e49 xenalyze.c
--- a/xenalyze.c	Tue Apr 24 18:37:35 2012 +0100
+++ b/xenalyze.c	Wed Apr 25 10:42:54 2012 +0100
@@ -32,6 +32,7 @@
 #include "trace.h"
 #include "analyze.h"
 #include "mread.h"
+#include "plugin.h"
 #include <errno.h>
 #include <strings.h>
 #include <string.h>
@@ -40,8 +41,6 @@
 struct mread_ctrl;
 
 
-typedef unsigned long long tsc_t;
-
 #define DEFAULT_CPU_HZ 2400000000LL
 #define ADDR_SPACE_BITS 48
 #define DEFAULT_SAMPLE_SIZE 10240
@@ -260,57 +259,8 @@ struct {
     .interval = { .msec = DEFAULT_INTERVAL_LENGTH },
 };
 
-/* -- on-disk trace buffer definitions -- */
-struct trace_record {
-    union {
-        struct {
-            unsigned event:28,
-                extra_words:3,
-                cycle_flag:1;
-            union {
-                struct {
-                    uint32_t tsc_lo, tsc_hi;
-                    uint32_t data[7];
-                } tsc;
-                struct {
-                    uint32_t data[7];
-                } notsc;
-            } u;
-        };
-        uint32_t raw[8];
-    };
-};
-
 FILE *warn = NULL;
 
-/* -- General info about a current record -- */
-struct time_struct {
-    unsigned long long time;
-    unsigned int s, ns;
-};
-
-#define DUMP_HEADER_MAX 256
-
-struct record_info {
-    int cpu;
-    tsc_t tsc;
-    union {
-        unsigned event;
-        struct {
-            unsigned minor:12,
-                sub:4,
-                main:12,
-                unused:4;
-        } evt;
-    };
-    int extra_words;
-    int size;
-    uint32_t *d;
-    char dump_header[DUMP_HEADER_MAX];
-    struct time_struct t;
-    struct trace_record rec;
-};
-
 /* -- Summary data -- */
 struct cycle_framework {
     tsc_t first_tsc, last_tsc, total_cycles;
@@ -8901,6 +8851,8 @@ void process_record(struct pcpu_info *p)
         default:
             process_generic(ri);
         }
+
+        plugin_process(ri);
     }
 
     UPDATE_VOLUME(p, toplevel[toplevel], ri->size);
@@ -9484,6 +9436,7 @@ enum {
     OPT_DUMP_ALL='a',
     OPT_INTERVAL_LENGTH='i',
     OPT_SUMMARY='s',
+    OPT_PLUGIN='p',
 };
 
 enum {
@@ -9954,6 +9907,15 @@ error_t cmd_parser(int key, char *arg, s
         opt.tsc_loop_fatal = 1;
         break;
 
+    case OPT_PLUGIN:
+        if (plugin_enable(arg)) {
+            G.output_defined = 1;
+        } else {
+            fprintf(stderr, "ERROR: No such plugin `%s'.\n", arg);
+            exit(1);
+        }
+        break;
+
     case ARGP_KEY_ARG:
     {
         /* FIXME - strcpy */
@@ -10246,6 +10208,10 @@ const struct argp_option cmd_opts[] =  {
       .arg = "errlevel",
       .doc = "Sets tolerance for errors found in the file.  Default is 3; max is 6.", },
 
+    { .name = "plugin",
+      .key = OPT_PLUGIN,
+      .arg = "PLUGIN",
+      .doc = "Enable a decoder or summary plugin.", },
 
     { 0 },
 };
@@ -10265,6 +10231,8 @@ int main(int argc, char *argv[]) {
     /* Start with warn at stderr. */
     warn = stderr;
 
+    plugin_init();
+
     argp_parse(&parser_def, argc, argv, 0, NULL, NULL);
 
     if (G.trace_file == NULL)
@@ -10301,6 +10269,8 @@ int main(int argc, char *argv[]) {
     if(opt.summary)
         summary();
 
+    plugin_summary();
+
     if(opt.report_pcpu)
         report_pcpu();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz3m-0000y4-Nj; Wed, 25 Apr 2012 10:02:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SMz3l-0000xp-4Y
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:02:53 +0000
Received: from [193.109.254.147:11733] by server-10.bemta-14.messagelabs.com
	id 04/58-05847-CCBC79F4; Wed, 25 Apr 2012 10:02:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335348170!6220438!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32523 invoked from network); 25 Apr 2012 10:02:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191958629"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:02:49 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012
	06:02:49 -0400
Message-ID: <4F97CBC8.6010507@citrix.com>
Date: Wed, 25 Apr 2012 11:02:48 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: George Dunlap <george.dunlap@citrix.com>
Subject: [Xen-devel] [PATCH] xenalyze: add a basic plugin infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow xenalyze to be include (at build time) plugins that can do
per-record actions and a summary.  These plugins can be in C or C++.

The plugins entry points are in struct plugin and pointers to all the
plugins linked in xenalyze are placed in a "plugin" section so
plugin_init() can find them all.

A new command line option (-p, --plugin=PLUGIN) is added to enable one
or more plugins.

A sample plugin (skeleton) is included (mostly because at least one
plugin must be present for the build to work).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 Makefile            |   10 +++---
 analyze.h           |   55 ++++++++++++++++++++++++++++++++++
 plugin.cc           |   84 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 plugin.h            |   48 +++++++++++++++++++++++++++++
 plugin.hh           |   42 ++++++++++++++++++++++++++
 plugins/skeleton.cc |   31 +++++++++++++++++++
 xenalyze.c          |   72 +++++++++++++-------------------------------
 7 files changed, 287 insertions(+), 55 deletions(-)
diff -r f4feecb06e49 Makefile
--- a/Makefile	Tue Apr 24 18:37:35 2012 +0100
+++ b/Makefile	Wed Apr 25 10:42:54 2012 +0100
@@ -1,6 +1,6 @@
 CC = gcc
 
-CFLAGS += -g -O2
+CFLAGS += -g -O2 -I.
 CFLAGS += -fno-strict-aliasing
 CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes
@@ -11,9 +11,11 @@ CFLAGS  += -D_LARGEFILE_SOURCE -D_LARGEF
 CFLAGS += -mno-tls-direct-seg-refs
 CFLAGS  += -Werror
 
+CXXFLAGS := -g -O2 -I. -Wall -Werror -std=c++0x
+
 BIN      = xenalyze dump-raw
 
-HDRS = trace.h analyze.h mread.h
+HDRS = trace.h analyze.h mread.h plugin.h plugin.hh
 
 all: $(BIN)
 
@@ -24,5 +26,5 @@ clean:
 %: %.c $(HDRS) Makefile
 	$(CC) $(CFLAGS) -o $@ $<
 
-xenalyze: xenalyze.o mread.o
-	$(CC) $(CFLAGS) -o $@ $^
+xenalyze: xenalyze.o mread.o plugin.o plugins/skeleton.o
+	$(CXX) $(CFLAGS) -o $@ $^
diff -r f4feecb06e49 analyze.h
--- a/analyze.h	Tue Apr 24 18:37:35 2012 +0100
+++ b/analyze.h	Wed Apr 25 10:42:54 2012 +0100
@@ -1,5 +1,8 @@
 #ifndef __ANALYZE_H
 # define __ANALYZE_H
+
+#include <stdint.h>
+
 #define TRC_GEN_MAIN     0
 #define TRC_SCHED_MAIN   1
 #define TRC_DOM0OP_MAIN  2
@@ -47,4 +50,56 @@ enum {
 };
 
 #define TRC_HVM_OP_DESTROY_PROC (TRC_HVM_HANDLER + 0x100)
+
+typedef unsigned long long tsc_t;
+
+/* -- on-disk trace buffer definitions -- */
+struct trace_record {
+    union {
+        struct {
+            unsigned event:28,
+                extra_words:3,
+                cycle_flag:1;
+            union {
+                struct {
+                    uint32_t tsc_lo, tsc_hi;
+                    uint32_t data[7];
+                } tsc;
+                struct {
+                    uint32_t data[7];
+                } notsc;
+            } u;
+        };
+        uint32_t raw[8];
+    };
+};
+
+/* -- General info about a current record -- */
+struct time_struct {
+    unsigned long long time;
+    unsigned int s, ns;
+};
+
+#define DUMP_HEADER_MAX 256
+
+struct record_info {
+    int cpu;
+    tsc_t tsc;
+    union {
+        unsigned event;
+        struct {
+            unsigned minor:12,
+                sub:4,
+                main:12,
+                unused:4;
+        } evt;
+    };
+    int extra_words;
+    int size;
+    uint32_t *d;
+    char dump_header[DUMP_HEADER_MAX];
+    struct time_struct t;
+    struct trace_record rec;
+};
+
 #endif
diff -r f4feecb06e49 plugin.cc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugin.cc	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,84 @@
+/*
+ * Xenalyze plugin infrastructure.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#include <stdio.h>
+#include <string.h>
+#include <list>
+
+#include "plugin.hh"
+
+typedef std::list<struct plugin *> plugin_list;
+
+static plugin_list available;
+static plugin_list enabled;
+
+bool plugin_enable(const char *name)
+{
+    for (auto p = available.begin(); p != available.end(); p++) {
+        struct plugin *plugin = *p;
+        if (strcmp(plugin->name, name) == 0) {
+            enabled.push_back(plugin);
+            if (plugin->enable) {
+                plugin->enable(plugin);
+            }
+            return true;
+        }
+    }
+    return false;
+}
+
+void plugin_process(const struct record_info *ri)
+{
+    for (auto p = enabled.begin(); p != enabled.end(); p++) {
+        struct plugin *plugin = *p;
+        if (plugin->process) {
+            plugin->process(plugin, ri);
+        }
+    }    
+}
+
+void plugin_summary(void)
+{
+    for (auto p = enabled.begin(); p != enabled.end(); p++) {
+        struct plugin *plugin = *p;
+        if (plugin->summary) {
+            printf("Summary for %s plugin:\n", plugin->name);
+            plugin->summary(plugin);
+        }
+    }
+}
+
+static void plugin_add(struct plugin *plugin)
+{
+    available.push_back(plugin);
+}
+
+void plugin_init(void)
+{
+    extern struct plugin *__start_plugin;
+    extern struct plugin *__stop_plugin;
+    struct plugin **p;
+
+    for (p = &__start_plugin; p < &__stop_plugin; p++) {
+        plugin_add(*p);
+    }
+}
+
+void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri)
+{
+    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
+    p->process(ri);
+}
+
+void plugin_summary_wrapper(struct plugin *plugin)
+{
+    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
+    p->summary();
+    delete p;
+}
diff -r f4feecb06e49 plugin.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugin.h	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,48 @@
+/*
+ * Xenalyze plugin C API.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#ifndef PLUGIN_H
+#define PLUGIN_H
+
+#include <stdbool.h>
+
+#include "analyze.h"
+#include "helpers.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+struct plugin;
+
+typedef void (*plugin_enable_f)(struct plugin *plugin);
+typedef void (*plugin_process_f)(struct plugin *plugin, const struct record_info *ri);
+typedef void (*plugin_summary_f)(struct plugin *plugin);
+
+struct plugin {
+    const char *name;
+    plugin_enable_f enable;
+    plugin_process_f process;
+    plugin_summary_f summary;
+    void *data;
+};
+
+#define DEFINE_PLUGIN(p) \
+    struct plugin *__plugin_ ## p __attribute__((section("plugin"))) = &p
+
+void plugin_init(void);
+bool plugin_enable(const char *name);
+void plugin_process(const struct record_info *ri);
+void plugin_summary(void);
+
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
+#endif /* #ifndef PLUGIN_H */
diff -r f4feecb06e49 plugin.hh
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugin.hh	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,42 @@
+/*
+ * Xenalyze plugin C++ API.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#ifndef PLUGIN_HH
+#define PLUGIN_HH
+
+#include "plugin.h"
+
+class xenalyze_plugin {
+public:
+    virtual ~xenalyze_plugin() {}
+
+    virtual void process(const struct record_info *ri) = 0;
+    virtual void summary() = 0;
+};
+
+#define DEFINE_CXX_PLUGIN(name, cls)                                    \
+    static void __plugin_ ## cls ## _enable(struct plugin *plugin)      \
+    {                                                                   \
+        plugin->data = new cls();                                       \
+    }                                                                   \
+                                                                        \
+    static struct plugin __plugin ## cls = {                            \
+        name,                                                           \
+        __plugin_ ## cls ## _enable,                                    \
+        plugin_process_wrapper,                                         \
+        plugin_summary_wrapper,                                         \
+    };                                                                  \
+    DEFINE_PLUGIN(__plugin ## cls)
+
+extern "C" {
+void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri);
+void plugin_summary_wrapper(struct plugin *plugin);
+}
+
+#endif /* #ifndef PLUGIN_HH */
diff -r f4feecb06e49 plugins/skeleton.cc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/plugins/skeleton.cc	Wed Apr 25 10:42:54 2012 +0100
@@ -0,0 +1,31 @@
+/*
+ * Skeleton xenalyze plugin.
+ *
+ * Copyright (C) 2012, Citrix Systems R&D Ltd, UK
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+#include "plugin.hh"
+
+class skeleton_plugin : xenalyze_plugin {
+public:
+    skeleton_plugin() {}
+    ~skeleton_plugin() {}
+
+    void process(const struct record_info *ri);
+    void summary(void);
+};
+
+void skeleton_plugin::process(const struct record_info *ri)
+{
+    /* Put per-trace record stuff here. */
+}
+
+void skeleton_plugin::summary(void)
+{
+    /* Print a summary of the results (if applicable). */
+}
+
+DEFINE_CXX_PLUGIN("skeleton", skeleton_plugin);
diff -r f4feecb06e49 xenalyze.c
--- a/xenalyze.c	Tue Apr 24 18:37:35 2012 +0100
+++ b/xenalyze.c	Wed Apr 25 10:42:54 2012 +0100
@@ -32,6 +32,7 @@
 #include "trace.h"
 #include "analyze.h"
 #include "mread.h"
+#include "plugin.h"
 #include <errno.h>
 #include <strings.h>
 #include <string.h>
@@ -40,8 +41,6 @@
 struct mread_ctrl;
 
 
-typedef unsigned long long tsc_t;
-
 #define DEFAULT_CPU_HZ 2400000000LL
 #define ADDR_SPACE_BITS 48
 #define DEFAULT_SAMPLE_SIZE 10240
@@ -260,57 +259,8 @@ struct {
     .interval = { .msec = DEFAULT_INTERVAL_LENGTH },
 };
 
-/* -- on-disk trace buffer definitions -- */
-struct trace_record {
-    union {
-        struct {
-            unsigned event:28,
-                extra_words:3,
-                cycle_flag:1;
-            union {
-                struct {
-                    uint32_t tsc_lo, tsc_hi;
-                    uint32_t data[7];
-                } tsc;
-                struct {
-                    uint32_t data[7];
-                } notsc;
-            } u;
-        };
-        uint32_t raw[8];
-    };
-};
-
 FILE *warn = NULL;
 
-/* -- General info about a current record -- */
-struct time_struct {
-    unsigned long long time;
-    unsigned int s, ns;
-};
-
-#define DUMP_HEADER_MAX 256
-
-struct record_info {
-    int cpu;
-    tsc_t tsc;
-    union {
-        unsigned event;
-        struct {
-            unsigned minor:12,
-                sub:4,
-                main:12,
-                unused:4;
-        } evt;
-    };
-    int extra_words;
-    int size;
-    uint32_t *d;
-    char dump_header[DUMP_HEADER_MAX];
-    struct time_struct t;
-    struct trace_record rec;
-};
-
 /* -- Summary data -- */
 struct cycle_framework {
     tsc_t first_tsc, last_tsc, total_cycles;
@@ -8901,6 +8851,8 @@ void process_record(struct pcpu_info *p)
         default:
             process_generic(ri);
         }
+
+        plugin_process(ri);
     }
 
     UPDATE_VOLUME(p, toplevel[toplevel], ri->size);
@@ -9484,6 +9436,7 @@ enum {
     OPT_DUMP_ALL='a',
     OPT_INTERVAL_LENGTH='i',
     OPT_SUMMARY='s',
+    OPT_PLUGIN='p',
 };
 
 enum {
@@ -9954,6 +9907,15 @@ error_t cmd_parser(int key, char *arg, s
         opt.tsc_loop_fatal = 1;
         break;
 
+    case OPT_PLUGIN:
+        if (plugin_enable(arg)) {
+            G.output_defined = 1;
+        } else {
+            fprintf(stderr, "ERROR: No such plugin `%s'.\n", arg);
+            exit(1);
+        }
+        break;
+
     case ARGP_KEY_ARG:
     {
         /* FIXME - strcpy */
@@ -10246,6 +10208,10 @@ const struct argp_option cmd_opts[] =  {
       .arg = "errlevel",
       .doc = "Sets tolerance for errors found in the file.  Default is 3; max is 6.", },
 
+    { .name = "plugin",
+      .key = OPT_PLUGIN,
+      .arg = "PLUGIN",
+      .doc = "Enable a decoder or summary plugin.", },
 
     { 0 },
 };
@@ -10265,6 +10231,8 @@ int main(int argc, char *argv[]) {
     /* Start with warn at stderr. */
     warn = stderr;
 
+    plugin_init();
+
     argp_parse(&parser_def, argc, argv, 0, NULL, NULL);
 
     if (G.trace_file == NULL)
@@ -10301,6 +10269,8 @@ int main(int argc, char *argv[]) {
     if(opt.summary)
         summary();
 
+    plugin_summary();
+
     if(opt.report_pcpu)
         report_pcpu();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:07:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz7X-0001Fh-ID; Wed, 25 Apr 2012 10:06:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SMz7V-0001FY-UI
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:06:46 +0000
Received: from [85.158.138.51:58437] by server-7.bemta-3.messagelabs.com id
	55/40-03078-5BCC79F4; Wed, 25 Apr 2012 10:06:45 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335348402!15770489!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12747 invoked from network); 25 Apr 2012 10:06:43 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-12.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 10:06:43 -0000
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com
	[209.85.212.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 58BE7DBCAA
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 18:06:28 +0800 (CST)
Received: by vbbfq11 with SMTP id fq11so1324027vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 03:06:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.228 with SMTP id fb4mr1638554vdb.62.1335348381739; Wed,
	25 Apr 2012 03:06:21 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Wed, 25 Apr 2012 03:06:21 -0700 (PDT)
In-Reply-To: <20120424162321.GH3213@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
	<CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
	<20120424162321.GH3213@phenom.dumpdata.com>
Date: Wed, 25 Apr 2012 18:06:21 +0800
Message-ID: <CAF1ivSYFp7duSCNb+_5teM83icx1O-rY0YVFm7Laq_JLZuzerw@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 12:23 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Apr 24, 2012 at 10:43:53PM +0800, Lin Ming wrote:
>> On Mon, Apr 23, 2012 at 11:11 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>> >> >> > How about return -1 on error?
>> >> >> > The calling function can check -1 for error.
>> >> >>
>> >> >> Isn't -1 potentially (at least theoretically) a valid value to rea=
d from
>> >> >> one of these registers?
>> >> >
>> >> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
>> >> >
>> >> > Perhaps the fallback is to emulate (so retain some of the original =
code)
>> >> > as we have been since .. uh 3.0?
>> >>
>> >> Do you mean the return value of io_apic_read in 3.0?
>> >
>> > No. I meant that we would continue to emulate. The improvement
>> > is that now we do:
>> >
>> > =A0 =A0 =A0 if (reg =3D=3D 0x1)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
>> > =A0 =A0 =A0 else if (reg =3D=3D 0x0)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>> >
>> > instead of 0xfdfdfdfd.
>> >
>> >> It's 0xffffffff.
>> >
>> > Now it is 0xfdfdfdfd.
>> >
>> > I am suggesting that instead of BUG_ON(), we fallback to do returning
>> > an emulatated IO_APIC values - like the ones that this original patch
>> > cooked up..
>>
>> But we still need to return some value if the register is not emulated.
>
> Right. 0xfd;
>>
>> How about below?
>
>
> Almost perfect.
>>
>> unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>> {
>> =A0 =A0 =A0 =A0 struct physdev_apic apic_op;
>> =A0 =A0 =A0 =A0 int ret;
>>
>> =A0 =A0 =A0 =A0 apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
>> =A0 =A0 =A0 =A0 apic_op.reg =3D reg;
>> =A0 =A0 =A0 =A0 ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic=
_op);
>> =A0 =A0 =A0 =A0 if (!ret)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic_op.value;
>>
>> =A0 =A0 =A0 =A0 /* emulate register */
>> =A0 =A0 =A0 =A0 if (reg =3D=3D 0x1)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
>> =A0 =A0 =A0 =A0 else if (reg =3D=3D 0x0)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>> =A0 =A0 =A0 =A0 else
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
>
> =A0 =A0 =A0 =A0return 0xfd;

Where does this magic number 0xfd come from?

Both native_io_apic_read and xen_io_apic_read does not return 0xfd on error.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:07:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMz7X-0001Fh-ID; Wed, 25 Apr 2012 10:06:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SMz7V-0001FY-UI
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:06:46 +0000
Received: from [85.158.138.51:58437] by server-7.bemta-3.messagelabs.com id
	55/40-03078-5BCC79F4; Wed, 25 Apr 2012 10:06:45 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335348402!15770489!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12747 invoked from network); 25 Apr 2012 10:06:43 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-12.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 10:06:43 -0000
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com
	[209.85.212.43]) (Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 58BE7DBCAA
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 18:06:28 +0800 (CST)
Received: by vbbfq11 with SMTP id fq11so1324027vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 03:06:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.228 with SMTP id fb4mr1638554vdb.62.1335348381739; Wed,
	25 Apr 2012 03:06:21 -0700 (PDT)
Received: by 10.52.37.167 with HTTP; Wed, 25 Apr 2012 03:06:21 -0700 (PDT)
In-Reply-To: <20120424162321.GH3213@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
	<CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
	<20120424162321.GH3213@phenom.dumpdata.com>
Date: Wed, 25 Apr 2012 18:06:21 +0800
Message-ID: <CAF1ivSYFp7duSCNb+_5teM83icx1O-rY0YVFm7Laq_JLZuzerw@mail.gmail.com>
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 12:23 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Apr 24, 2012 at 10:43:53PM +0800, Lin Ming wrote:
>> On Mon, Apr 23, 2012 at 11:11 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>> >> >> > How about return -1 on error?
>> >> >> > The calling function can check -1 for error.
>> >> >>
>> >> >> Isn't -1 potentially (at least theoretically) a valid value to rea=
d from
>> >> >> one of these registers?
>> >> >
>> >> > Yeah, but then we are back to crashing at bootup (with dom0) :-)
>> >> >
>> >> > Perhaps the fallback is to emulate (so retain some of the original =
code)
>> >> > as we have been since .. uh 3.0?
>> >>
>> >> Do you mean the return value of io_apic_read in 3.0?
>> >
>> > No. I meant that we would continue to emulate. The improvement
>> > is that now we do:
>> >
>> > =A0 =A0 =A0 if (reg =3D=3D 0x1)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
>> > =A0 =A0 =A0 else if (reg =3D=3D 0x0)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>> >
>> > instead of 0xfdfdfdfd.
>> >
>> >> It's 0xffffffff.
>> >
>> > Now it is 0xfdfdfdfd.
>> >
>> > I am suggesting that instead of BUG_ON(), we fallback to do returning
>> > an emulatated IO_APIC values - like the ones that this original patch
>> > cooked up..
>>
>> But we still need to return some value if the register is not emulated.
>
> Right. 0xfd;
>>
>> How about below?
>
>
> Almost perfect.
>>
>> unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
>> {
>> =A0 =A0 =A0 =A0 struct physdev_apic apic_op;
>> =A0 =A0 =A0 =A0 int ret;
>>
>> =A0 =A0 =A0 =A0 apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
>> =A0 =A0 =A0 =A0 apic_op.reg =3D reg;
>> =A0 =A0 =A0 =A0 ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic=
_op);
>> =A0 =A0 =A0 =A0 if (!ret)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic_op.value;
>>
>> =A0 =A0 =A0 =A0 /* emulate register */
>> =A0 =A0 =A0 =A0 if (reg =3D=3D 0x1)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
>> =A0 =A0 =A0 =A0 else if (reg =3D=3D 0x0)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
>> =A0 =A0 =A0 =A0 else
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
>
> =A0 =A0 =A0 =A0return 0xfd;

Where does this magic number 0xfd come from?

Both native_io_apic_read and xen_io_apic_read does not return 0xfd on error.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:11:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzBy-0001Wx-1D; Wed, 25 Apr 2012 10:11:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzBv-0001Wh-Ix
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:11:19 +0000
Received: from [85.158.139.83:3039] by server-9.bemta-5.messagelabs.com id
	F8/AC-09826-6CDC79F4; Wed, 25 Apr 2012 10:11:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335348678!25398713!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30969 invoked from network); 25 Apr 2012 10:11:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:11:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:11:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzBt-0004xV-CY; Wed, 25 Apr 2012 10:11:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzBt-00019O-9k;
	Wed, 25 Apr 2012 11:11:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.52677.287182.934829@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:11:17 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335347949.28015.19.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> So for vifname="foo" it is a no-brainer to call the vif "foo" and the
> emulated tap device "foo-emu".
> 
> But what about the case where no vifname is given, in that case vif is
> named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
> changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
> now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?

I think either is fine.  While we're changing it it probably makes
sense to use "vif..." as indeed it is more consistent.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:11:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzBy-0001Wx-1D; Wed, 25 Apr 2012 10:11:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzBv-0001Wh-Ix
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:11:19 +0000
Received: from [85.158.139.83:3039] by server-9.bemta-5.messagelabs.com id
	F8/AC-09826-6CDC79F4; Wed, 25 Apr 2012 10:11:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335348678!25398713!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30969 invoked from network); 25 Apr 2012 10:11:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:11:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:11:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzBt-0004xV-CY; Wed, 25 Apr 2012 10:11:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzBt-00019O-9k;
	Wed, 25 Apr 2012 11:11:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.52677.287182.934829@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:11:17 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1335347949.28015.19.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> So for vifname="foo" it is a no-brainer to call the vif "foo" and the
> emulated tap device "foo-emu".
> 
> But what about the case where no vifname is given, in that case vif is
> named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
> changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
> now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?

I think either is fine.  While we're changing it it probably makes
sense to use "vif..." as indeed it is more consistent.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:14:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:14:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzFE-0001mM-Mj; Wed, 25 Apr 2012 10:14:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzFD-0001m8-6V
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:14:43 +0000
Received: from [193.109.254.147:22476] by server-3.bemta-14.messagelabs.com id
	03/73-23274-29EC79F4; Wed, 25 Apr 2012 10:14:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335348881!6215821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19875 invoked from network); 25 Apr 2012 10:14:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:14:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:14:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:14:41 +0100
Message-ID: <1335348880.28015.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:14:40 +0100
In-Reply-To: <20375.52677.287182.934829@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:11 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > So for vifname="foo" it is a no-brainer to call the vif "foo" and the
> > emulated tap device "foo-emu".
> > 
> > But what about the case where no vifname is given, in that case vif is
> > named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
> > changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
> > now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?
> 
> I think either is fine.  While we're changing it it probably makes
> sense to use "vif..." as indeed it is more consistent.

OK, vifX.Y and vifX.Y-emu it is...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:14:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:14:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzFE-0001mM-Mj; Wed, 25 Apr 2012 10:14:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzFD-0001m8-6V
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:14:43 +0000
Received: from [193.109.254.147:22476] by server-3.bemta-14.messagelabs.com id
	03/73-23274-29EC79F4; Wed, 25 Apr 2012 10:14:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335348881!6215821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19875 invoked from network); 25 Apr 2012 10:14:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:14:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:14:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:14:41 +0100
Message-ID: <1335348880.28015.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:14:40 +0100
In-Reply-To: <20375.52677.287182.934829@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:11 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > So for vifname="foo" it is a no-brainer to call the vif "foo" and the
> > emulated tap device "foo-emu".
> > 
> > But what about the case where no vifname is given, in that case vif is
> > named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
> > changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
> > now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?
> 
> I think either is fine.  While we're changing it it probably makes
> sense to use "vif..." as indeed it is more consistent.

OK, vifX.Y and vifX.Y-emu it is...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:15:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:15:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzFn-0001qF-4A; Wed, 25 Apr 2012 10:15:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzFm-0001q0-34
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:15:18 +0000
Received: from [85.158.143.99:9434] by server-3.bemta-4.messagelabs.com id
	F7/5B-05853-5BEC79F4; Wed, 25 Apr 2012 10:15:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335348914!17656155!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21442 invoked from network); 25 Apr 2012 10:15:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191959806"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:15:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 06:15:13 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SMzFg-0006WO-V7;
	Wed, 25 Apr 2012 11:15:12 +0100
MIME-Version: 1.0
X-Mercurial-Node: c8486295429011e9a220db1b6ed9f34ba690e729
Message-ID: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Apr 2012 11:15:12 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian.Jackson@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335348624 -3600
# Node ID c8486295429011e9a220db1b6ed9f34ba690e729
# Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
libxl: default to xenconsoled for pv guests, even if qemu is running.

Currently we prefer to use qemu for the disk backend if we are starting qemu
anyway (e.g. to service a disk).

Unfortunately qemu doesn't log the console, which xenconsoled can do via
XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
there is no particular reason to prefer qemu just because it happens to be
running.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

I'm not sure if this is 4.2 material, perhaps too late to be making this sort
of change?

diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
@@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_vfbs, d_config->vfbs,
                 d_config->num_disks, &d_config->disks[0]);
 
-        if (need_qemu)
-             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
+        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
 
         libxl__device_console_add(gc, domid, &console, &state);
         libxl__device_console_dispose(&console);
diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Apr 25 11:05:05 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Apr 25 11:10:24 2012 +0100
@@ -1093,11 +1093,6 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
 {
     int i, ret = 0;
 
-    if (nr_consoles > 1) {
-        ret = 1;
-        goto out;
-    }
-
     for (i = 0; i < nr_consoles; i++) {
         if (consoles[i].consback == LIBXL__CONSOLE_BACKEND_IOEMU) {
             ret = 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:15:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:15:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzFn-0001qF-4A; Wed, 25 Apr 2012 10:15:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzFm-0001q0-34
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:15:18 +0000
Received: from [85.158.143.99:9434] by server-3.bemta-4.messagelabs.com id
	F7/5B-05853-5BEC79F4; Wed, 25 Apr 2012 10:15:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335348914!17656155!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21442 invoked from network); 25 Apr 2012 10:15:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191959806"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:15:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 06:15:13 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SMzFg-0006WO-V7;
	Wed, 25 Apr 2012 11:15:12 +0100
MIME-Version: 1.0
X-Mercurial-Node: c8486295429011e9a220db1b6ed9f34ba690e729
Message-ID: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Apr 2012 11:15:12 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian.Jackson@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335348624 -3600
# Node ID c8486295429011e9a220db1b6ed9f34ba690e729
# Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
libxl: default to xenconsoled for pv guests, even if qemu is running.

Currently we prefer to use qemu for the disk backend if we are starting qemu
anyway (e.g. to service a disk).

Unfortunately qemu doesn't log the console, which xenconsoled can do via
XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
there is no particular reason to prefer qemu just because it happens to be
running.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

I'm not sure if this is 4.2 material, perhaps too late to be making this sort
of change?

diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
@@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_vfbs, d_config->vfbs,
                 d_config->num_disks, &d_config->disks[0]);
 
-        if (need_qemu)
-             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
+        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
 
         libxl__device_console_add(gc, domid, &console, &state);
         libxl__device_console_dispose(&console);
diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Apr 25 11:05:05 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Apr 25 11:10:24 2012 +0100
@@ -1093,11 +1093,6 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
 {
     int i, ret = 0;
 
-    if (nr_consoles > 1) {
-        ret = 1;
-        goto out;
-    }
-
     for (i = 0; i < nr_consoles; i++) {
         if (consoles[i].consback == LIBXL__CONSOLE_BACKEND_IOEMU) {
             ret = 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:17:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzHT-00020B-Lu; Wed, 25 Apr 2012 10:17:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzHR-0001zy-PR
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:17:01 +0000
Received: from [85.158.143.35:50271] by server-3.bemta-4.messagelabs.com id
	07/6E-05853-D1FC79F4; Wed, 25 Apr 2012 10:17:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335349017!13593245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17649 invoked from network); 25 Apr 2012 10:16:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:16:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:16:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzHN-0004zT-12; Wed, 25 Apr 2012 10:16:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzHM-0001A5-WE;
	Wed, 25 Apr 2012 11:16:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53013.256209.209386@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:16:53 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3D4AF@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D4AF@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> I work on unstable tree.

xen-unstable.hg comes in two variants.  See the text under
  http://wiki.xen.org/wiki/Submitting_Xen_Patches#After_your_patch_is_committed

> I think the confliction is my MS outlook configuration issue, I'll re-resend a revised patch.

I think it's because you used an out of date tip.  You based your
patch on 25138, according to your email.  But at the time you sent
your email, the most recent changeset was something later than 25156,
and 25156 changed libcl_pci.c.

But I will try your repost.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:17:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzHT-00020B-Lu; Wed, 25 Apr 2012 10:17:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzHR-0001zy-PR
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:17:01 +0000
Received: from [85.158.143.35:50271] by server-3.bemta-4.messagelabs.com id
	07/6E-05853-D1FC79F4; Wed, 25 Apr 2012 10:17:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335349017!13593245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17649 invoked from network); 25 Apr 2012 10:16:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:16:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:16:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzHN-0004zT-12; Wed, 25 Apr 2012 10:16:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzHM-0001A5-WE;
	Wed, 25 Apr 2012 11:16:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53013.256209.209386@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:16:53 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3D4AF@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D4AF@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("RE: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> I work on unstable tree.

xen-unstable.hg comes in two variants.  See the text under
  http://wiki.xen.org/wiki/Submitting_Xen_Patches#After_your_patch_is_committed

> I think the confliction is my MS outlook configuration issue, I'll re-resend a revised patch.

I think it's because you used an out of date tip.  You based your
patch on 25138, according to your email.  But at the time you sent
your email, the most recent changeset was something later than 25156,
and 25156 changed libcl_pci.c.

But I will try your repost.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:19:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzJL-0002BT-5z; Wed, 25 Apr 2012 10:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzJJ-0002BI-Qb
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:18:58 +0000
Received: from [193.109.254.147:22332] by server-12.bemta-14.messagelabs.com
	id 3C/73-05898-19FC79F4; Wed, 25 Apr 2012 10:18:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335349136!6273099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23808 invoked from network); 25 Apr 2012 10:18:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:18:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:18:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:18:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzJH-00050M-75; Wed, 25 Apr 2012 10:18:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzJH-0001H7-67;
	Wed, 25 Apr 2012 11:18:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53135.175025.811413@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:18:55 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3D545@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D545@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> libxl: passthrough: avoid passing through devices not owned by pciback

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:19:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzJL-0002BT-5z; Wed, 25 Apr 2012 10:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzJJ-0002BI-Qb
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:18:58 +0000
Received: from [193.109.254.147:22332] by server-12.bemta-14.messagelabs.com
	id 3C/73-05898-19FC79F4; Wed, 25 Apr 2012 10:18:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335349136!6273099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23808 invoked from network); 25 Apr 2012 10:18:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:18:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:18:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:18:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzJH-00050M-75; Wed, 25 Apr 2012 10:18:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzJH-0001H7-67;
	Wed, 25 Apr 2012 11:18:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53135.175025.811413@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:18:55 +0100
To: "Hao, Xudong" <xudong.hao@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD3D545@SHSMSX101.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FCF23D7@SHSMSX102.ccr.corp.intel.com>
	<20345.56112.630128.747571@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD0826A@SHSMSX102.ccr.corp.intel.com>
	<20349.44836.366233.162318@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD09DDF@SHSMSX102.ccr.corp.intel.com>
	<20374.60088.396314.671522@mariner.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D545@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through
 devices not owned by pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hao, Xudong writes ("Re: [Xen-devel] [PATCH] libxl: passthrough: avoid passing through devices not owned by pciback"):
> libxl: passthrough: avoid passing through devices not owned by pciback

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:20:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzKk-0002KG-Lr; Wed, 25 Apr 2012 10:20:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <hch@lst.de>)
	id 1SMzKj-0002K5-SS
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:20:25 +0000
Received: from [85.158.143.99:17093] by server-3.bemta-4.messagelabs.com id
	D7/14-05853-9EFC79F4; Wed, 25 Apr 2012 10:20:25 +0000
X-Env-Sender: hch@lst.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335349224!21807331!1
X-Originating-IP: [213.95.11.211]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6965 invoked from network); 25 Apr 2012 10:20:24 -0000
Received: from verein.lst.de (HELO newverein.lst.de) (213.95.11.211)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 10:20:24 -0000
Received: by newverein.lst.de (Postfix, from userid 2407)
	id 94CEF13FBE; Wed, 25 Apr 2012 12:20:24 +0200 (CEST)
Date: Wed, 25 Apr 2012 12:20:24 +0200
From: Christoph Hellwig <hch@lst.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425102024.GA19800@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335344565.28015.7.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:
	implement	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 10:02:45AM +0100, Ian Campbell wrote:
> The blkif spec was recently much improved, you can find it at
> http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
> 
> TBH I'm not sure it actually answers your questions wrt
> BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
> improving it.

That description in there is overly simple, and does not match any of the
implementations known to me on either end.

Talking about those: the mainline Linux blkback backend also implements
different semantics from what mainline Linux blkfront seems to expect,
as well as different from qemu.  Looking at these three alone I can't see
how Xen ever managed to get data to disk reliably if using the paravirt
interface.
with the implementations in qemu and the Linux kernel frontend and backends,
which

> 
> Ian
> 
---end quoted text---

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:20:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzKk-0002KG-Lr; Wed, 25 Apr 2012 10:20:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <hch@lst.de>)
	id 1SMzKj-0002K5-SS
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:20:25 +0000
Received: from [85.158.143.99:17093] by server-3.bemta-4.messagelabs.com id
	D7/14-05853-9EFC79F4; Wed, 25 Apr 2012 10:20:25 +0000
X-Env-Sender: hch@lst.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335349224!21807331!1
X-Originating-IP: [213.95.11.211]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6965 invoked from network); 25 Apr 2012 10:20:24 -0000
Received: from verein.lst.de (HELO newverein.lst.de) (213.95.11.211)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 10:20:24 -0000
Received: by newverein.lst.de (Postfix, from userid 2407)
	id 94CEF13FBE; Wed, 25 Apr 2012 12:20:24 +0200 (CEST)
Date: Wed, 25 Apr 2012 12:20:24 +0200
From: Christoph Hellwig <hch@lst.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425102024.GA19800@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335344565.28015.7.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:
	implement	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 10:02:45AM +0100, Ian Campbell wrote:
> The blkif spec was recently much improved, you can find it at
> http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
> 
> TBH I'm not sure it actually answers your questions wrt
> BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
> improving it.

That description in there is overly simple, and does not match any of the
implementations known to me on either end.

Talking about those: the mainline Linux blkback backend also implements
different semantics from what mainline Linux blkfront seems to expect,
as well as different from qemu.  Looking at these three alone I can't see
how Xen ever managed to get data to disk reliably if using the paravirt
interface.
with the implementations in qemu and the Linux kernel frontend and backends,
which

> 
> Ian
> 
---end quoted text---

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:23:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzN9-0002Wb-8M; Wed, 25 Apr 2012 10:22:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SMzN8-0002WS-6h
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:22:54 +0000
Received: from [85.158.143.99:27807] by server-2.bemta-4.messagelabs.com id
	7C/42-17550-D70D79F4; Wed, 25 Apr 2012 10:22:53 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335349372!24619470!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18339 invoked from network); 25 Apr 2012 10:22:52 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 10:22:52 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 9E156541C5; Wed, 25 Apr 2012 12:22:50 +0200 (CEST)
Date: Wed, 25 Apr 2012 12:22:50 +0200
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425102250.GB17344@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20120416154210.GA6338@wavehammer.waldi.eu.org>
	<1334591484.14560.219.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334591484.14560.219.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 04:51:24PM +0100, Ian Campbell wrote:
> On Mon, 2012-04-16 at 16:42 +0100, Bastian Blank wrote:
> > The xenstore header xs.h is producing conflicts with other software[1].
> > 
> > xs is a too short identifier and does not matche the library. Renaming
> > the headers to xenstore.h and xenstore_lib.h is the easiest way to make
> > them easy recognizable and prevent furthe problems.

Signed-off-by: Bastian Blank <waldi@debian.org>

-- 
All your people must learn before you can reach for the stars.
		-- Kirk, "The Gamesters of Triskelion", stardate 3259.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:23:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzN9-0002Wb-8M; Wed, 25 Apr 2012 10:22:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SMzN8-0002WS-6h
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:22:54 +0000
Received: from [85.158.143.99:27807] by server-2.bemta-4.messagelabs.com id
	7C/42-17550-D70D79F4; Wed, 25 Apr 2012 10:22:53 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335349372!24619470!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18339 invoked from network); 25 Apr 2012 10:22:52 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 10:22:52 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 9E156541C5; Wed, 25 Apr 2012 12:22:50 +0200 (CEST)
Date: Wed, 25 Apr 2012 12:22:50 +0200
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425102250.GB17344@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20120416154210.GA6338@wavehammer.waldi.eu.org>
	<1334591484.14560.219.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334591484.14560.219.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 04:51:24PM +0100, Ian Campbell wrote:
> On Mon, 2012-04-16 at 16:42 +0100, Bastian Blank wrote:
> > The xenstore header xs.h is producing conflicts with other software[1].
> > 
> > xs is a too short identifier and does not matche the library. Renaming
> > the headers to xenstore.h and xenstore_lib.h is the easiest way to make
> > them easy recognizable and prevent furthe problems.

Signed-off-by: Bastian Blank <waldi@debian.org>

-- 
All your people must learn before you can reach for the stars.
		-- Kirk, "The Gamesters of Triskelion", stardate 3259.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:23:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzNG-0002Xr-Pg; Wed, 25 Apr 2012 10:23:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzNG-0002Xk-4Q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:23:02 +0000
Received: from [85.158.143.99:34415] by server-3.bemta-4.messagelabs.com id
	40/B8-05853-580D79F4; Wed, 25 Apr 2012 10:23:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335349380!24619504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18811 invoked from network); 25 Apr 2012 10:23:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:23:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:23:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:23:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzNE-00051g-BK; Wed, 25 Apr 2012 10:23:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzNE-0001HZ-AJ;
	Wed, 25 Apr 2012 11:23:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53380.304650.469977@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:23:00 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335341262.4881.15.camel@dagon.hellion.org.uk>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] fix build error with seabios"):
> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> > > 
> > > Pass PYTHON down to seabios, so seabios will
> > > use same python binary as whole xen tree does.
> > > Fixes build error on NetBSD.
> > 
> > Ian, does this look sensible to you ?
> 
> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> is OK, so we might as well take this now.

I wasn't sure about that.  But OK.

> > > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I have applied it.

But I rewrote the commit message.  Christoph, I often find I need to
rewrite or reword your commit messages; you might like to look at the
message for 25241:15f094c85c85 to see what would be a more
conventional style and set of information.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:23:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzNG-0002Xr-Pg; Wed, 25 Apr 2012 10:23:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzNG-0002Xk-4Q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:23:02 +0000
Received: from [85.158.143.99:34415] by server-3.bemta-4.messagelabs.com id
	40/B8-05853-580D79F4; Wed, 25 Apr 2012 10:23:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335349380!24619504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18811 invoked from network); 25 Apr 2012 10:23:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:23:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:23:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:23:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzNE-00051g-BK; Wed, 25 Apr 2012 10:23:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzNE-0001HZ-AJ;
	Wed, 25 Apr 2012 11:23:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53380.304650.469977@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:23:00 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335341262.4881.15.camel@dagon.hellion.org.uk>
References: <4F8836C9.9080502@amd.com>
	<20374.57450.417199.89376@mariner.uk.xensource.com>
	<1335341262.4881.15.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix build error with seabios
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] fix build error with seabios"):
> On Tue, 2012-04-24 at 18:18 +0100, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] fix build error with seabios"):
> > > 
> > > Pass PYTHON down to seabios, so seabios will
> > > use same python binary as whole xen tree does.
> > > Fixes build error on NetBSD.
> > 
> > Ian, does this look sensible to you ?
> 
> It exports $(PYTHON) to all subdirs of tools/firmware, but I guess that
> is OK, so we might as well take this now.

I wasn't sure about that.  But OK.

> > > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I have applied it.

But I rewrote the commit message.  Christoph, I often find I need to
rewrite or reword your commit messages; you might like to look at the
message for 25241:15f094c85c85 to see what would be a more
conventional style and set of information.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzNV-0002ap-6i; Wed, 25 Apr 2012 10:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SMzNU-0002aS-8H
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:23:16 +0000
Received: from [85.158.143.35:61995] by server-2.bemta-4.messagelabs.com id
	C8/F2-17550-390D79F4; Wed, 25 Apr 2012 10:23:15 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335349394!12589207!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6463 invoked from network); 25 Apr 2012 10:23:14 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 10:23:14 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 9D5FF541C5; Wed, 25 Apr 2012 12:23:13 +0200 (CEST)
Date: Wed, 25 Apr 2012 12:23:13 +0200
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425102313.GC17344@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20120416154629.GB6338@wavehammer.waldi.eu.org>
	<1334593355.14560.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334593355.14560.227.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Don't use a4wide in latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 05:22:35PM +0100, Ian Campbell wrote:
> On Mon, 2012-04-16 at 16:46 +0100, Bastian Blank wrote:
> > a4wide is not longer shipped in texlive. Just don't use it.

Signed-off-by: Bastian Blank <waldi@debian.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzNV-0002ap-6i; Wed, 25 Apr 2012 10:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1SMzNU-0002aS-8H
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:23:16 +0000
Received: from [85.158.143.35:61995] by server-2.bemta-4.messagelabs.com id
	C8/F2-17550-390D79F4; Wed, 25 Apr 2012 10:23:15 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335349394!12589207!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6463 invoked from network); 25 Apr 2012 10:23:14 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 10:23:14 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 9D5FF541C5; Wed, 25 Apr 2012 12:23:13 +0200 (CEST)
Date: Wed, 25 Apr 2012 12:23:13 +0200
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425102313.GC17344@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20120416154629.GB6338@wavehammer.waldi.eu.org>
	<1334593355.14560.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334593355.14560.227.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Don't use a4wide in latex
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 16, 2012 at 05:22:35PM +0100, Ian Campbell wrote:
> On Mon, 2012-04-16 at 16:46 +0100, Bastian Blank wrote:
> > a4wide is not longer shipped in texlive. Just don't use it.

Signed-off-by: Bastian Blank <waldi@debian.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:25:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzPX-0002tm-OR; Wed, 25 Apr 2012 10:25:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzPW-0002tc-35
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:25:22 +0000
Received: from [193.109.254.147:51728] by server-12.bemta-14.messagelabs.com
	id 87/39-05898-111D79F4; Wed, 25 Apr 2012 10:25:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335349519!6206625!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10899 invoked from network); 25 Apr 2012 10:25:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:25:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:25:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:25:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzPS-00053w-Ha; Wed, 25 Apr 2012 10:25:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzPS-0001Hu-Ga;
	Wed, 25 Apr 2012 11:25:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53518.253950.509933@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:25:18 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335341487.4881.17.camel@dagon.hellion.org.uk>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
	<20374.59769.738590.656156@mariner.uk.xensource.com>
	<1335341487.4881.17.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> On Tue, 2012-04-24 at 18:57 +0100, Ian Jackson wrote:
...
> > Why does the Array not automatically invent a "num_<foo>" field ?
> > Surely there is no benefit to having non-systematically named (or
> > typed) array count fields ?
> 
> That would be good but currently the Array type doesn't see the name of
> the member in the containing struct:
> Struct("thing", [
> 	("disks", Array(libxl_device_disk, "num_disks")),
> ])
> 
> We have a similar problem with the KeyedUnion which similarly ought to
> be able to at least default keyvar_name to something.

Ah.  Can we make it an absolutely hard policy rule that the name _is_
some fixed variant on the name of the pointer member ?  That way we
will be able to autogenerate it later without trouble.

The transformation should probably not involve adding "s" because then
people will be tempted to sometimes add "es" (or alternatively we have
to live with misspelled plurals).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:25:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzPX-0002tm-OR; Wed, 25 Apr 2012 10:25:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzPW-0002tc-35
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:25:22 +0000
Received: from [193.109.254.147:51728] by server-12.bemta-14.messagelabs.com
	id 87/39-05898-111D79F4; Wed, 25 Apr 2012 10:25:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335349519!6206625!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10899 invoked from network); 25 Apr 2012 10:25:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:25:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:25:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:25:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzPS-00053w-Ha; Wed, 25 Apr 2012 10:25:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzPS-0001Hu-Ga;
	Wed, 25 Apr 2012 11:25:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53518.253950.509933@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:25:18 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335341487.4881.17.camel@dagon.hellion.org.uk>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
	<20374.59769.738590.656156@mariner.uk.xensource.com>
	<1335341487.4881.17.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> On Tue, 2012-04-24 at 18:57 +0100, Ian Jackson wrote:
...
> > Why does the Array not automatically invent a "num_<foo>" field ?
> > Surely there is no benefit to having non-systematically named (or
> > typed) array count fields ?
> 
> That would be good but currently the Array type doesn't see the name of
> the member in the containing struct:
> Struct("thing", [
> 	("disks", Array(libxl_device_disk, "num_disks")),
> ])
> 
> We have a similar problem with the KeyedUnion which similarly ought to
> be able to at least default keyvar_name to something.

Ah.  Can we make it an absolutely hard policy rule that the name _is_
some fixed variant on the name of the pointer member ?  That way we
will be able to autogenerate it later without trouble.

The transformation should probably not involve adding "s" because then
people will be tempted to sometimes add "es" (or alternatively we have
to live with misspelled plurals).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:26:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzQ5-0002zg-6d; Wed, 25 Apr 2012 10:25:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzQ3-0002zJ-94
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:25:55 +0000
Received: from [85.158.143.35:21269] by server-1.bemta-4.messagelabs.com id
	80/62-20925-231D79F4; Wed, 25 Apr 2012 10:25:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335349553!13638770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30696 invoked from network); 25 Apr 2012 10:25:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:25:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:25:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:25:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzQ1-000548-Eh; Wed, 25 Apr 2012 10:25:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzQ1-00024r-Ad;
	Wed, 25 Apr 2012 11:25:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53553.269226.466311@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:25:53 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F97B7AB.50400@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
	<4F97B7AB.50400@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v2] libxl: prevent xl from running if x=
end is running."):
> Ian Jackson escribi=F3:
...
> > Thanks, but I'm afraid this needs a refresh.  I recommend you wait
> > until tomorrow.  I'm nearly at the end of my huge queue...
> =

> Do you mean that the code doesn't apply cleanly, or a refresh in the =

> commit message?

The former.

> In the lists of changes I've added the fact that now you are able to run =

> commands that doesn't modify anything.

Right, yes, that's good.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:26:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzQ5-0002zg-6d; Wed, 25 Apr 2012 10:25:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzQ3-0002zJ-94
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:25:55 +0000
Received: from [85.158.143.35:21269] by server-1.bemta-4.messagelabs.com id
	80/62-20925-231D79F4; Wed, 25 Apr 2012 10:25:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335349553!13638770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30696 invoked from network); 25 Apr 2012 10:25:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:25:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:25:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:25:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzQ1-000548-Eh; Wed, 25 Apr 2012 10:25:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzQ1-00024r-Ad;
	Wed, 25 Apr 2012 11:25:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53553.269226.466311@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:25:53 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F97B7AB.50400@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
	<4F97B7AB.50400@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v2] libxl: prevent xl from running if x=
end is running."):
> Ian Jackson escribi=F3:
...
> > Thanks, but I'm afraid this needs a refresh.  I recommend you wait
> > until tomorrow.  I'm nearly at the end of my huge queue...
> =

> Do you mean that the code doesn't apply cleanly, or a refresh in the =

> commit message?

The former.

> In the lists of changes I've added the fact that now you are able to run =

> commands that doesn't modify anything.

Right, yes, that's good.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:27:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzRT-0003AJ-N6; Wed, 25 Apr 2012 10:27:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMzRS-0003AA-N1
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:27:22 +0000
Received: from [85.158.139.83:65103] by server-9.bemta-5.messagelabs.com id
	A0/A5-09826-981D79F4; Wed, 25 Apr 2012 10:27:21 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335349639!18172025!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29266 invoked from network); 25 Apr 2012 10:27:20 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:27:20 -0000
Received: by qcsc20 with SMTP id c20so1183965qcs.32
	for <xen-devel@lists.xen.org>; Wed, 25 Apr 2012 03:27:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=G8uJp/SIdnWWQXtrqu5iO8dV+2saWXo4On04j9awh/I=;
	b=tr29rOmm4QHtXm5vZS3fFnuHDbCkx2VEFrYUPM1XD2mvQnBRVKv185p7hy8ivDqtis
	EfOxxfIrmeanYscPLn4QT5AzPHBf+Ev3VDxMH7oQS0YJvDK1Ghd7maT1r+UPmtrcijrU
	pva2y9/0x3LdB7wrkctt5ndvrFwW2zoaqn7Xx86v8uQNI1wNWZFDD+NTmfpVmjaYO18c
	6NuesUE9WHyMBTqKsVqYXz+t5UDcFbbV6liy6Py88P1OckzSggaNQ+bfS1h1/6mFkYTv
	UrOs5KhhxQU7we6CQq9XCsUw0JyAmHu1WZDHwGwiPUycpHgiIqFAgr80gMDmTDbg1ktl
	kORQ==
MIME-Version: 1.0
Received: by 10.224.111.67 with SMTP id r3mr1570182qap.36.1335349638579; Wed,
	25 Apr 2012 03:27:18 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Wed, 25 Apr 2012 03:27:18 -0700 (PDT)
In-Reply-To: <20374.59940.607143.114201@mariner.uk.xensource.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
	<20374.59940.607143.114201@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:27:18 +0100
X-Google-Sender-Auth: DctROhSgc9X7ojpv0sGWwvoVx7k
Message-ID: <CAFLBxZb-eJPC1HNx5O4JsB+Lz+FUT66vWTYU6CR8PXfenA26EA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Jonathan Ludlam <jonathan.ludlam@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 7:00 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr=
ote:
> George Dunlap writes ("Re: [Xen-devel] Driver domains communication proto=
col proposal"):
>> On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> =
wrote:
>> > =A0vdi
>> > =A0 =A0 This host's intent to access a specific target.
>> > =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
>> > =A0 =A0 Possible states: inactive/active.
>> > =A0 =A0 Abstract operations: prepare, activate, deactivate, unprepare.
>>
>> VDI as used by XenServer seems to mean "virtual disk instance", and as
>> such is actually persistent. =A0I don't quite understand what it's
>> supposed to mean here, and how it differs from VBD (which in XenServer
>> terminology means "virtual block device").
>
> One "vdi" in this sense can support multiple "vbd"s. =A0A "vbd"
> represents an attachment to a domain (or some other kind of provision
> for use) whereas a "vdi" is a preparatory thing.

Ah, so what you're calling "vdi" in this case is a thing into which
vbd's can plug -- what we might call the backend "node" for a
particular disk image?

So we have:

[A] <--> [B] <--> { [C], [D], [E] }

Where:
* A is the actual disk image on stable storage somewhere
* B is the instance of the code that can access A and provide access
to VMs which connect to it (not persistent)
* C D and E are instances of code running inside the guest which
connect to B and provide a block device to the guest OS which looks
like A (again not persistent)

Is that correct?

I think calling A a "virtual disk image" makes the most sense; reusing
that name for B is a bad idea given that it's already used for A in
XenServer terminology.  (Jonathan, correct me if I'm wrong here.)

I think that calling C D and E "vbd"s also makes sense.

So we just need to have a good name for the running instance of a
blockback process / thread / whatever that accesses a particular VDI.
Virtual disk provider (VDP)? Block back instance (BBI)?  Virtual block
backend (VBB)?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:27:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzRT-0003AJ-N6; Wed, 25 Apr 2012 10:27:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMzRS-0003AA-N1
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:27:22 +0000
Received: from [85.158.139.83:65103] by server-9.bemta-5.messagelabs.com id
	A0/A5-09826-981D79F4; Wed, 25 Apr 2012 10:27:21 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335349639!18172025!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29266 invoked from network); 25 Apr 2012 10:27:20 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:27:20 -0000
Received: by qcsc20 with SMTP id c20so1183965qcs.32
	for <xen-devel@lists.xen.org>; Wed, 25 Apr 2012 03:27:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=G8uJp/SIdnWWQXtrqu5iO8dV+2saWXo4On04j9awh/I=;
	b=tr29rOmm4QHtXm5vZS3fFnuHDbCkx2VEFrYUPM1XD2mvQnBRVKv185p7hy8ivDqtis
	EfOxxfIrmeanYscPLn4QT5AzPHBf+Ev3VDxMH7oQS0YJvDK1Ghd7maT1r+UPmtrcijrU
	pva2y9/0x3LdB7wrkctt5ndvrFwW2zoaqn7Xx86v8uQNI1wNWZFDD+NTmfpVmjaYO18c
	6NuesUE9WHyMBTqKsVqYXz+t5UDcFbbV6liy6Py88P1OckzSggaNQ+bfS1h1/6mFkYTv
	UrOs5KhhxQU7we6CQq9XCsUw0JyAmHu1WZDHwGwiPUycpHgiIqFAgr80gMDmTDbg1ktl
	kORQ==
MIME-Version: 1.0
Received: by 10.224.111.67 with SMTP id r3mr1570182qap.36.1335349638579; Wed,
	25 Apr 2012 03:27:18 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Wed, 25 Apr 2012 03:27:18 -0700 (PDT)
In-Reply-To: <20374.59940.607143.114201@mariner.uk.xensource.com>
References: <20348.27879.297617.171564@mariner.uk.xensource.com>
	<CAFLBxZb8FifF0cKfCr3R=jDEgff8eXNwNmx63xr-FFiCbwPvMA@mail.gmail.com>
	<20374.59940.607143.114201@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:27:18 +0100
X-Google-Sender-Auth: DctROhSgc9X7ojpv0sGWwvoVx7k
Message-ID: <CAFLBxZb-eJPC1HNx5O4JsB+Lz+FUT66vWTYU6CR8PXfenA26EA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Jonathan Ludlam <jonathan.ludlam@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Driver domains communication protocol proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 7:00 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr=
ote:
> George Dunlap writes ("Re: [Xen-devel] Driver domains communication proto=
col proposal"):
>> On Wed, Apr 4, 2012 at 4:46 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> =
wrote:
>> > =A0vdi
>> > =A0 =A0 This host's intent to access a specific target.
>> > =A0 =A0 Non-persistent, created on request by toolstack, enumerable.
>> > =A0 =A0 Possible states: inactive/active.
>> > =A0 =A0 Abstract operations: prepare, activate, deactivate, unprepare.
>>
>> VDI as used by XenServer seems to mean "virtual disk instance", and as
>> such is actually persistent. =A0I don't quite understand what it's
>> supposed to mean here, and how it differs from VBD (which in XenServer
>> terminology means "virtual block device").
>
> One "vdi" in this sense can support multiple "vbd"s. =A0A "vbd"
> represents an attachment to a domain (or some other kind of provision
> for use) whereas a "vdi" is a preparatory thing.

Ah, so what you're calling "vdi" in this case is a thing into which
vbd's can plug -- what we might call the backend "node" for a
particular disk image?

So we have:

[A] <--> [B] <--> { [C], [D], [E] }

Where:
* A is the actual disk image on stable storage somewhere
* B is the instance of the code that can access A and provide access
to VMs which connect to it (not persistent)
* C D and E are instances of code running inside the guest which
connect to B and provide a block device to the guest OS which looks
like A (again not persistent)

Is that correct?

I think calling A a "virtual disk image" makes the most sense; reusing
that name for B is a bad idea given that it's already used for A in
XenServer terminology.  (Jonathan, correct me if I'm wrong here.)

I think that calling C D and E "vbd"s also makes sense.

So we just need to have a good name for the running instance of a
blockback process / thread / whatever that accesses a particular VDI.
Virtual disk provider (VDP)? Block back instance (BBI)?  Virtual block
backend (VBB)?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:28:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzSI-0003Hk-58; Wed, 25 Apr 2012 10:28:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzSG-0003HV-Sm
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:28:13 +0000
Received: from [85.158.143.99:65371] by server-2.bemta-4.messagelabs.com id
	17/CA-17550-CB1D79F4; Wed, 25 Apr 2012 10:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335349690!18144662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30500 invoked from network); 25 Apr 2012 10:28:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:28:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:28:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:28:09 +0100
Message-ID: <1335349688.28015.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:28:08 +0100
In-Reply-To: <20375.53518.253950.509933@mariner.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
	<20374.59769.738590.656156@mariner.uk.xensource.com>
	<1335341487.4881.17.camel@dagon.hellion.org.uk>
	<20375.53518.253950.509933@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:25 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> > On Tue, 2012-04-24 at 18:57 +0100, Ian Jackson wrote:
> ...
> > > Why does the Array not automatically invent a "num_<foo>" field ?
> > > Surely there is no benefit to having non-systematically named (or
> > > typed) array count fields ?
> > 
> > That would be good but currently the Array type doesn't see the name of
> > the member in the containing struct:
> > Struct("thing", [
> > 	("disks", Array(libxl_device_disk, "num_disks")),
> > ])
> > 
> > We have a similar problem with the KeyedUnion which similarly ought to
> > be able to at least default keyvar_name to something.
> 
> Ah.  Can we make it an absolutely hard policy rule that the name _is_
> some fixed variant on the name of the pointer member ?  That way we
> will be able to autogenerate it later without trouble.

That seems reasonable.

> The transformation should probably not involve adding "s" because then
> people will be tempted to sometimes add "es" (or alternatively we have
> to live with misspelled plurals).

as does this.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:28:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzSI-0003Hk-58; Wed, 25 Apr 2012 10:28:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzSG-0003HV-Sm
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:28:13 +0000
Received: from [85.158.143.99:65371] by server-2.bemta-4.messagelabs.com id
	17/CA-17550-CB1D79F4; Wed, 25 Apr 2012 10:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335349690!18144662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30500 invoked from network); 25 Apr 2012 10:28:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:28:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:28:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:28:09 +0100
Message-ID: <1335349688.28015.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:28:08 +0100
In-Reply-To: <20375.53518.253950.509933@mariner.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<dc3241cf1ed1b8e5709c.1333535781@cosworth.uk.xensource.com>
	<20374.59769.738590.656156@mariner.uk.xensource.com>
	<1335341487.4881.17.camel@dagon.hellion.org.uk>
	<20375.53518.253950.509933@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of
 libxl_domain_config into the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:25 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL"):
> > On Tue, 2012-04-24 at 18:57 +0100, Ian Jackson wrote:
> ...
> > > Why does the Array not automatically invent a "num_<foo>" field ?
> > > Surely there is no benefit to having non-systematically named (or
> > > typed) array count fields ?
> > 
> > That would be good but currently the Array type doesn't see the name of
> > the member in the containing struct:
> > Struct("thing", [
> > 	("disks", Array(libxl_device_disk, "num_disks")),
> > ])
> > 
> > We have a similar problem with the KeyedUnion which similarly ought to
> > be able to at least default keyvar_name to something.
> 
> Ah.  Can we make it an absolutely hard policy rule that the name _is_
> some fixed variant on the name of the pointer member ?  That way we
> will be able to autogenerate it later without trouble.

That seems reasonable.

> The transformation should probably not involve adding "s" because then
> people will be tempted to sometimes add "es" (or alternatively we have
> to live with misspelled plurals).

as does this.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:29:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzTW-0003Pv-KR; Wed, 25 Apr 2012 10:29:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzTU-0003Ph-Oh
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:29:28 +0000
Received: from [85.158.143.35:48064] by server-2.bemta-4.messagelabs.com id
	1E/9C-17550-802D79F4; Wed, 25 Apr 2012 10:29:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335349767!13639451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9736 invoked from network); 25 Apr 2012 10:29:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:29:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:29:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzTT-00055e-7B; Wed, 25 Apr 2012 10:29:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzTS-0007HN-TT;
	Wed, 25 Apr 2012 11:29:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53766.400829.139875@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:29:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335345779.28015.15.camel@zakaz.uk.xensource.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<1335345779.28015.15.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
 is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend is running."):
> On Tue, 2012-04-24 at 19:05 +0100, Roger Pau Monne wrote:
> > Prevent xl from doing any operation if xend daemon is running. That
> > prevents bugs that happened when xl and xend raced to close a domain.
...
> Do we now have 3 classes of commands which could be represented with an
> enum rather than a pair of bools?

No, because hopefully eventually every command will support dryrun and
then we can abolish that flag.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:29:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzTW-0003Pv-KR; Wed, 25 Apr 2012 10:29:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzTU-0003Ph-Oh
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:29:28 +0000
Received: from [85.158.143.35:48064] by server-2.bemta-4.messagelabs.com id
	1E/9C-17550-802D79F4; Wed, 25 Apr 2012 10:29:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335349767!13639451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9736 invoked from network); 25 Apr 2012 10:29:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:29:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:29:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzTT-00055e-7B; Wed, 25 Apr 2012 10:29:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzTS-0007HN-TT;
	Wed, 25 Apr 2012 11:29:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53766.400829.139875@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:29:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335345779.28015.15.camel@zakaz.uk.xensource.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<1335345779.28015.15.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
 is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend is running."):
> On Tue, 2012-04-24 at 19:05 +0100, Roger Pau Monne wrote:
> > Prevent xl from doing any operation if xend daemon is running. That
> > prevents bugs that happened when xl and xend raced to close a domain.
...
> Do we now have 3 classes of commands which could be represented with an
> enum rather than a pair of bools?

No, because hopefully eventually every command will support dryrun and
then we can abolish that flag.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzUc-0003Xp-4U; Wed, 25 Apr 2012 10:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMzUa-0003Xg-Ri
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:30:37 +0000
Received: from [85.158.143.99:19779] by server-1.bemta-4.messagelabs.com id
	E8/D9-20925-C42D79F4; Wed, 25 Apr 2012 10:30:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335349834!13987876!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18337 invoked from network); 25 Apr 2012 10:30:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:30:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:30:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:30:24 +0100
Date: Wed, 25 Apr 2012 11:36:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1335348624 -3600
> # Node ID c8486295429011e9a220db1b6ed9f34ba690e729
> # Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
> libxl: default to xenconsoled for pv guests, even if qemu is running.
> 
> Currently we prefer to use qemu for the disk backend if we are starting qemu
> anyway (e.g. to service a disk).
> 
> Unfortunately qemu doesn't log the console, which xenconsoled can do via
> XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> there is no particular reason to prefer qemu just because it happens to be
> running.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

QEMU's console backend supports multiple PV consoles while xenconsoled
does not.
I think you should just change the default only in case a single PV
console is configured.


> I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> of change?
> 
> diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
> +++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
> @@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
>                  d_config->num_vfbs, d_config->vfbs,
>                  d_config->num_disks, &d_config->disks[0]);
>  
> -        if (need_qemu)
> -             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> +        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
>  
>          libxl__device_console_add(gc, domid, &console, &state);
>          libxl__device_console_dispose(&console);

I would change the if into:

if (need_qemu and nr_console > 1)

even though I am aware that at the moment nr_console is always 1.


> diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Wed Apr 25 11:05:05 2012 +0100
> +++ b/tools/libxl/libxl_dm.c	Wed Apr 25 11:10:24 2012 +0100
> @@ -1093,11 +1093,6 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
>  {
>      int i, ret = 0;
>  
> -    if (nr_consoles > 1) {
> -        ret = 1;
> -        goto out;
> -    }
> -

I would get rid of this change

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzUc-0003Xp-4U; Wed, 25 Apr 2012 10:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMzUa-0003Xg-Ri
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:30:37 +0000
Received: from [85.158.143.99:19779] by server-1.bemta-4.messagelabs.com id
	E8/D9-20925-C42D79F4; Wed, 25 Apr 2012 10:30:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335349834!13987876!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18337 invoked from network); 25 Apr 2012 10:30:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:30:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:30:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:30:24 +0100
Date: Wed, 25 Apr 2012 11:36:27 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1335348624 -3600
> # Node ID c8486295429011e9a220db1b6ed9f34ba690e729
> # Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
> libxl: default to xenconsoled for pv guests, even if qemu is running.
> 
> Currently we prefer to use qemu for the disk backend if we are starting qemu
> anyway (e.g. to service a disk).
> 
> Unfortunately qemu doesn't log the console, which xenconsoled can do via
> XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> there is no particular reason to prefer qemu just because it happens to be
> running.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

QEMU's console backend supports multiple PV consoles while xenconsoled
does not.
I think you should just change the default only in case a single PV
console is configured.


> I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> of change?
> 
> diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
> +++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
> @@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
>                  d_config->num_vfbs, d_config->vfbs,
>                  d_config->num_disks, &d_config->disks[0]);
>  
> -        if (need_qemu)
> -             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> +        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
>  
>          libxl__device_console_add(gc, domid, &console, &state);
>          libxl__device_console_dispose(&console);

I would change the if into:

if (need_qemu and nr_console > 1)

even though I am aware that at the moment nr_console is always 1.


> diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Wed Apr 25 11:05:05 2012 +0100
> +++ b/tools/libxl/libxl_dm.c	Wed Apr 25 11:10:24 2012 +0100
> @@ -1093,11 +1093,6 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
>  {
>      int i, ret = 0;
>  
> -    if (nr_consoles > 1) {
> -        ret = 1;
> -        goto out;
> -    }
> -

I would get rid of this change

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:32:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:32:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzVx-0003jF-Pk; Wed, 25 Apr 2012 10:32:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMzVw-0003iv-8w
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:32:00 +0000
Received: from [85.158.143.35:26202] by server-3.bemta-4.messagelabs.com id
	8C/A7-05853-F92D79F4; Wed, 25 Apr 2012 10:31:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335349917!13596213!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7821 invoked from network); 25 Apr 2012 10:31:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:31:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="24516777"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:31:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 06:31:57 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMzVs-0006sY-OR;
	Wed, 25 Apr 2012 11:31:56 +0100
Message-ID: <4F97D2A0.2060207@citrix.com>
Date: Wed, 25 Apr 2012 11:32:00 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
	<4F97B7AB.50400@citrix.com>
	<20375.53553.269226.466311@mariner.uk.xensource.com>
In-Reply-To: <20375.53553.269226.466311@mariner.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("Re: [PATCH v2] libxl: prevent xl from running if=
 xend is running."):
>> Ian Jackson escribi=F3:
> ...
>>> Thanks, but I'm afraid this needs a refresh.  I recommend you wait
>>> until tomorrow.  I'm nearly at the end of my huge queue...
>> Do you mean that the code doesn't apply cleanly, or a refresh in the
>> commit message?
>
> The former.

Anyway I'm going to make the change requested by Ian Campbell, and I'm =

going to add an enum to define the type of commands, currently I have =

the following names:

STATIC: doesn't modify anything
DRY_RUN: modifies, but has a dry_run option
MODIFIES: modifies, but has no dry_run option

The names are crap, so if you have a better naming scheme I'm open to =

suggestions.

>
>> In the lists of changes I've added the fact that now you are able to run
>> commands that doesn't modify anything.
>
> Right, yes, that's good.
>
> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:32:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:32:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzVx-0003jF-Pk; Wed, 25 Apr 2012 10:32:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMzVw-0003iv-8w
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:32:00 +0000
Received: from [85.158.143.35:26202] by server-3.bemta-4.messagelabs.com id
	8C/A7-05853-F92D79F4; Wed, 25 Apr 2012 10:31:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335349917!13596213!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7821 invoked from network); 25 Apr 2012 10:31:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:31:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="24516777"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:31:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 06:31:57 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMzVs-0006sY-OR;
	Wed, 25 Apr 2012 11:31:56 +0100
Message-ID: <4F97D2A0.2060207@citrix.com>
Date: Wed, 25 Apr 2012 11:32:00 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
	<4F97B7AB.50400@citrix.com>
	<20375.53553.269226.466311@mariner.uk.xensource.com>
In-Reply-To: <20375.53553.269226.466311@mariner.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("Re: [PATCH v2] libxl: prevent xl from running if=
 xend is running."):
>> Ian Jackson escribi=F3:
> ...
>>> Thanks, but I'm afraid this needs a refresh.  I recommend you wait
>>> until tomorrow.  I'm nearly at the end of my huge queue...
>> Do you mean that the code doesn't apply cleanly, or a refresh in the
>> commit message?
>
> The former.

Anyway I'm going to make the change requested by Ian Campbell, and I'm =

going to add an enum to define the type of commands, currently I have =

the following names:

STATIC: doesn't modify anything
DRY_RUN: modifies, but has a dry_run option
MODIFIES: modifies, but has no dry_run option

The names are crap, so if you have a better naming scheme I'm open to =

suggestions.

>
>> In the lists of changes I've added the fact that now you are able to run
>> commands that doesn't modify anything.
>
> Right, yes, that's good.
>
> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzWw-0003r0-9G; Wed, 25 Apr 2012 10:33:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzWu-0003qh-CD
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:33:00 +0000
Received: from [193.109.254.147:28055] by server-6.bemta-14.messagelabs.com id
	AC/00-02047-BD2D79F4; Wed, 25 Apr 2012 10:32:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335349951!554085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2730 invoked from network); 25 Apr 2012 10:32:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:32:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:32:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzWQ-00056a-Jp; Wed, 25 Apr 2012 10:32:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzWQ-0005UU-D0;
	Wed, 25 Apr 2012 11:32:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53950.77177.102406@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:32:30 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running"):
> libxl: default to xenconsoled for pv guests, even if qemu is running.
> 
> Currently we prefer to use qemu for the disk backend if we are starting qemu
> anyway (e.g. to service a disk).
...
> I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> of change?

I think we can regard this as a bugfix, or make an exception.

But: have you tested this ?  ISTR hearing that there was some
difficulty getting a pv qemu not to try to provide the console.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzWw-0003r0-9G; Wed, 25 Apr 2012 10:33:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzWu-0003qh-CD
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:33:00 +0000
Received: from [193.109.254.147:28055] by server-6.bemta-14.messagelabs.com id
	AC/00-02047-BD2D79F4; Wed, 25 Apr 2012 10:32:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335349951!554085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2730 invoked from network); 25 Apr 2012 10:32:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:32:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:32:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzWQ-00056a-Jp; Wed, 25 Apr 2012 10:32:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzWQ-0005UU-D0;
	Wed, 25 Apr 2012 11:32:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.53950.77177.102406@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:32:30 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running"):
> libxl: default to xenconsoled for pv guests, even if qemu is running.
> 
> Currently we prefer to use qemu for the disk backend if we are starting qemu
> anyway (e.g. to service a disk).
...
> I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> of change?

I think we can regard this as a bugfix, or make an exception.

But: have you tested this ?  ISTR hearing that there was some
difficulty getting a pv qemu not to try to provide the console.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:34:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzYQ-00042N-Rn; Wed, 25 Apr 2012 10:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzYP-00042C-MW
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:34:33 +0000
Received: from [85.158.143.99:46304] by server-2.bemta-4.messagelabs.com id
	69/E4-17550-933D79F4; Wed, 25 Apr 2012 10:34:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335350072!13988691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 956 invoked from network); 25 Apr 2012 10:34:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:34:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:34:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzYN-00057L-Ki; Wed, 25 Apr 2012 10:34:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzYN-0007SY-Bq;
	Wed, 25 Apr 2012 11:34:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54071.115138.286017@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:34:31 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F97D2A0.2060207@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
	<4F97B7AB.50400@citrix.com>
	<20375.53553.269226.466311@mariner.uk.xensource.com>
	<4F97D2A0.2060207@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v2] libxl: prevent xl from running if x=
end is running."):
> Ian Jackson escribi=F3:
> > The former.
> =

> Anyway I'm going to make the change requested by Ian Campbell, and I'm =

> going to add an enum to define the type of commands, currently I have =

> the following names:

Please don't.  I don't agree with him, as I said...

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:34:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzYQ-00042N-Rn; Wed, 25 Apr 2012 10:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzYP-00042C-MW
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:34:33 +0000
Received: from [85.158.143.99:46304] by server-2.bemta-4.messagelabs.com id
	69/E4-17550-933D79F4; Wed, 25 Apr 2012 10:34:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335350072!13988691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 956 invoked from network); 25 Apr 2012 10:34:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:34:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:34:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzYN-00057L-Ki; Wed, 25 Apr 2012 10:34:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzYN-0007SY-Bq;
	Wed, 25 Apr 2012 11:34:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54071.115138.286017@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:34:31 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F97D2A0.2060207@citrix.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<20374.60449.668898.21825@mariner.uk.xensource.com>
	<4F97B7AB.50400@citrix.com>
	<20375.53553.269226.466311@mariner.uk.xensource.com>
	<4F97D2A0.2060207@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v2] libxl: prevent xl from running if x=
end is running."):
> Ian Jackson escribi=F3:
> > The former.
> =

> Anyway I'm going to make the change requested by Ian Campbell, and I'm =

> going to add an enum to define the type of commands, currently I have =

> the following names:

Please don't.  I don't agree with him, as I said...

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:36:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzaA-0004EI-EE; Wed, 25 Apr 2012 10:36:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMza8-0004E8-L4
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:36:20 +0000
Received: from [85.158.143.35:35003] by server-1.bemta-4.messagelabs.com id
	AC/F2-20925-3A3D79F4; Wed, 25 Apr 2012 10:36:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335350179!13640766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31618 invoked from network); 25 Apr 2012 10:36:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127937"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:36:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:36:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMza6-000583-Bb; Wed, 25 Apr 2012 10:36:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMza6-0007og-AP;
	Wed, 25 Apr 2012 11:36:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54178.152546.960985@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:36:18 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335344230.28015.3.camel@zakaz.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
	<20374.59820.578074.902872@mariner.uk.xensource.com>
	<1335344230.28015.3.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: provide
 libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> On Tue, 2012-04-24 at 18:58 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> > > libxl: provide libxl_domain_config_init.
> > 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Oops, I had an update which I'd forgotten to send out -- this is the
> delta, Sorry.

Ooops.

> libxl: use libxl_domain_config_init and not memset 0

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I missed a couple of memsets in 25237:31489be80c51, we need to use
> libxl_domain_config_init everywhere and not memset since not all fields are
> initialised to zero now (the type field in particular). This fixes an abort
> with "xl list <dom>" for a specific domain due to assert(type == -1) in
> libxl_domain_build_info_init_type().

This will probably turn up as an automatic test failure.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:36:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzaA-0004EI-EE; Wed, 25 Apr 2012 10:36:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMza8-0004E8-L4
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:36:20 +0000
Received: from [85.158.143.35:35003] by server-1.bemta-4.messagelabs.com id
	AC/F2-20925-3A3D79F4; Wed, 25 Apr 2012 10:36:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335350179!13640766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31618 invoked from network); 25 Apr 2012 10:36:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12127937"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:36:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:36:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMza6-000583-Bb; Wed, 25 Apr 2012 10:36:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMza6-0007og-AP;
	Wed, 25 Apr 2012 11:36:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54178.152546.960985@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:36:18 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335344230.28015.3.camel@zakaz.uk.xensource.com>
References: <patchbomb.1333535779@cosworth.uk.xensource.com>
	<ac6f863df8f8c86dcc58.1333535780@cosworth.uk.xensource.com>
	<20374.59820.578074.902872@mariner.uk.xensource.com>
	<1335344230.28015.3.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: provide
 libxl_domain_config_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> On Tue, 2012-04-24 at 18:58 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 1 of 2] libxl: provide libxl_domain_config_init"):
> > > libxl: provide libxl_domain_config_init.
> > 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Oops, I had an update which I'd forgotten to send out -- this is the
> delta, Sorry.

Ooops.

> libxl: use libxl_domain_config_init and not memset 0

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I missed a couple of memsets in 25237:31489be80c51, we need to use
> libxl_domain_config_init everywhere and not memset since not all fields are
> initialised to zero now (the type field in particular). This fixes an abort
> with "xl list <dom>" for a specific domain due to assert(type == -1) in
> libxl_domain_build_info_init_type().

This will probably turn up as an automatic test failure.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:40:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMze4-0004Sp-4L; Wed, 25 Apr 2012 10:40:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMze2-0004Si-O0
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:40:22 +0000
Received: from [85.158.143.35:60677] by server-2.bemta-4.messagelabs.com id
	B6/FD-17550-694D79F4; Wed, 25 Apr 2012 10:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335350420!6528186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27795 invoked from network); 25 Apr 2012 10:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:40:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:40:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMze0-00059B-6w; Wed, 25 Apr 2012 10:40:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMze0-0007xy-5H;
	Wed, 25 Apr 2012 11:40:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54420.148043.572871@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:40:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335344824.28015.8.camel@zakaz.uk.xensource.com>
References: <20120423193518.GA16134@bloms.de> <1335247525.2397.4.camel@Abyss>
	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
	<20120424182633.GA20286@bloms.de> <20120424193524.GA20565@bloms.de>
	<1335344824.28015.8.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> On Tue, 2012-04-24 at 20:35 +0100, Dieter Bloms wrote:
> > I've made a new patch.
> > Maybe it fit all your needs.
> 
> Thanks, this patch look good to me, I'll leave it to IanJ to decide
> which approach he prefers.

Thanks, I'll take that as an ack.  I've applied Dieter's latest
version, which I like.

I edited the docs message to change "can be set for" to "honoured
by", because variables can be set which will then be ignored.  Eg:

 +=item B<cpu_weight=WEIGHT>
 +
 +A domain with a weight of 512 will get twice as much CPU as a domain
 +with a weight of 256 on a contended host.
 +Legal weights range from 1 to 65535 and the default is 256.
-+Can be set for credit, credit2 and sedf scheduler.
++Honoured by the credit, credit2 and sedf schedulers.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:40:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMze4-0004Sp-4L; Wed, 25 Apr 2012 10:40:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMze2-0004Si-O0
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:40:22 +0000
Received: from [85.158.143.35:60677] by server-2.bemta-4.messagelabs.com id
	B6/FD-17550-694D79F4; Wed, 25 Apr 2012 10:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335350420!6528186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27795 invoked from network); 25 Apr 2012 10:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:40:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:40:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMze0-00059B-6w; Wed, 25 Apr 2012 10:40:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMze0-0007xy-5H;
	Wed, 25 Apr 2012 11:40:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54420.148043.572871@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:40:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335344824.28015.8.camel@zakaz.uk.xensource.com>
References: <20120423193518.GA16134@bloms.de> <1335247525.2397.4.camel@Abyss>
	<20120424121402.GA19331@bloms.de>
	<1335272980.4347.122.camel@zakaz.uk.xensource.com>
	<20120424143329.GB19331@bloms.de>
	<1335279087.4347.186.camel@zakaz.uk.xensource.com>
	<20374.52925.940533.95590@mariner.uk.xensource.com>
	<1335284131.4347.216.camel@zakaz.uk.xensource.com>
	<20374.53940.224705.242658@mariner.uk.xensource.com>
	<20120424182633.GA20286@bloms.de> <20120424193524.GA20565@bloms.de>
	<1335344824.28015.8.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Dieter Bloms <dieter@bloms.de>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter
 cpu_weight from my config file while xm does honour it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it"):
> On Tue, 2012-04-24 at 20:35 +0100, Dieter Bloms wrote:
> > I've made a new patch.
> > Maybe it fit all your needs.
> 
> Thanks, this patch look good to me, I'll leave it to IanJ to decide
> which approach he prefers.

Thanks, I'll take that as an ack.  I've applied Dieter's latest
version, which I like.

I edited the docs message to change "can be set for" to "honoured
by", because variables can be set which will then be ignored.  Eg:

 +=item B<cpu_weight=WEIGHT>
 +
 +A domain with a weight of 512 will get twice as much CPU as a domain
 +with a weight of 256 on a contended host.
 +Legal weights range from 1 to 65535 and the default is 256.
-+Can be set for credit, credit2 and sedf scheduler.
++Honoured by the credit, credit2 and sedf schedulers.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzeS-0004V4-Hg; Wed, 25 Apr 2012 10:40:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzeQ-0004Ui-QY
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:40:47 +0000
Received: from [85.158.138.51:7334] by server-8.bemta-3.messagelabs.com id
	78/B3-24428-DA4D79F4; Wed, 25 Apr 2012 10:40:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335350444!23667060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28296 invoked from network); 25 Apr 2012 10:40:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:40:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:40:44 +0100
Message-ID: <1335350442.28015.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:40:42 +0100
In-Reply-To: <alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:36 +0100, Stefano Stabellini wrote:
> On Wed, 25 Apr 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1335348624 -3600
> > # Node ID c8486295429011e9a220db1b6ed9f34ba690e729
> > # Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
> > libxl: default to xenconsoled for pv guests, even if qemu is running.
> > 
> > Currently we prefer to use qemu for the disk backend if we are starting qemu
> > anyway (e.g. to service a disk).
> > 
> > Unfortunately qemu doesn't log the console, which xenconsoled can do via
> > XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> > there is no particular reason to prefer qemu just because it happens to be
> > running.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> QEMU's console backend supports multiple PV consoles while xenconsoled
> does not.
> I think you should just change the default only in case a single PV
> console is configured.
> 
> 
> > I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> > of change?
> > 
> > diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
> > +++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
> > @@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
> >                  d_config->num_vfbs, d_config->vfbs,
> >                  d_config->num_disks, &d_config->disks[0]);
> >  
> > -        if (need_qemu)
> > -             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> > +        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
> >  
> >          libxl__device_console_add(gc, domid, &console, &state);
> >          libxl__device_console_dispose(&console);
> 
> I would change the if into:
> 
> if (need_qemu and nr_console > 1)
> 
> even though I am aware that at the moment nr_console is always 1.

There isn't actually a nr_console here, just a hardcoded 1... I could
add a nr_console just for this but perhaps it makes more sense for
libxl__need_xenpv_qemu to enforce this by updating consback for all
consoles iff there are > 1 of them and then returning need_qemu as
appropriate?

I'm a little unhappy with having need_qemu have side-effects like this,
but it seems better than splitting the logic into two places...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzeS-0004V4-Hg; Wed, 25 Apr 2012 10:40:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzeQ-0004Ui-QY
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:40:47 +0000
Received: from [85.158.138.51:7334] by server-8.bemta-3.messagelabs.com id
	78/B3-24428-DA4D79F4; Wed, 25 Apr 2012 10:40:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335350444!23667060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28296 invoked from network); 25 Apr 2012 10:40:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:40:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:40:44 +0100
Message-ID: <1335350442.28015.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:40:42 +0100
In-Reply-To: <alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:36 +0100, Stefano Stabellini wrote:
> On Wed, 25 Apr 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1335348624 -3600
> > # Node ID c8486295429011e9a220db1b6ed9f34ba690e729
> > # Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
> > libxl: default to xenconsoled for pv guests, even if qemu is running.
> > 
> > Currently we prefer to use qemu for the disk backend if we are starting qemu
> > anyway (e.g. to service a disk).
> > 
> > Unfortunately qemu doesn't log the console, which xenconsoled can do via
> > XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> > there is no particular reason to prefer qemu just because it happens to be
> > running.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> QEMU's console backend supports multiple PV consoles while xenconsoled
> does not.
> I think you should just change the default only in case a single PV
> console is configured.
> 
> 
> > I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> > of change?
> > 
> > diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
> > +++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
> > @@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
> >                  d_config->num_vfbs, d_config->vfbs,
> >                  d_config->num_disks, &d_config->disks[0]);
> >  
> > -        if (need_qemu)
> > -             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> > +        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
> >  
> >          libxl__device_console_add(gc, domid, &console, &state);
> >          libxl__device_console_dispose(&console);
> 
> I would change the if into:
> 
> if (need_qemu and nr_console > 1)
> 
> even though I am aware that at the moment nr_console is always 1.

There isn't actually a nr_console here, just a hardcoded 1... I could
add a nr_console just for this but perhaps it makes more sense for
libxl__need_xenpv_qemu to enforce this by updating consback for all
consoles iff there are > 1 of them and then returning need_qemu as
appropriate?

I'm a little unhappy with having need_qemu have side-effects like this,
but it seems better than splitting the logic into two places...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:44:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzhZ-0004lK-80; Wed, 25 Apr 2012 10:44:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMzhX-0004l2-RR
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:44:00 +0000
Received: from [85.158.138.51:27711] by server-10.bemta-3.messagelabs.com id
	D9/6A-29478-E65D79F4; Wed, 25 Apr 2012 10:43:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335350637!15776915!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22792 invoked from network); 25 Apr 2012 10:43:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:43:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:43:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:43:26 +0100
Date: Wed, 25 Apr 2012 11:49:30 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335350442.28015.29.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
	<1335350442.28015.29.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Ian Campbell wrote:
> On Wed, 2012-04-25 at 11:36 +0100, Stefano Stabellini wrote:
> > On Wed, 25 Apr 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1335348624 -3600
> > > # Node ID c8486295429011e9a220db1b6ed9f34ba690e729
> > > # Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
> > > libxl: default to xenconsoled for pv guests, even if qemu is running.
> > > 
> > > Currently we prefer to use qemu for the disk backend if we are starting qemu
> > > anyway (e.g. to service a disk).
> > > 
> > > Unfortunately qemu doesn't log the console, which xenconsoled can do via
> > > XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> > > there is no particular reason to prefer qemu just because it happens to be
> > > running.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > QEMU's console backend supports multiple PV consoles while xenconsoled
> > does not.
> > I think you should just change the default only in case a single PV
> > console is configured.
> > 
> > 
> > > I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> > > of change?
> > > 
> > > diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
> > > +++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
> > > @@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
> > >                  d_config->num_vfbs, d_config->vfbs,
> > >                  d_config->num_disks, &d_config->disks[0]);
> > >  
> > > -        if (need_qemu)
> > > -             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> > > +        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
> > >  
> > >          libxl__device_console_add(gc, domid, &console, &state);
> > >          libxl__device_console_dispose(&console);
> > 
> > I would change the if into:
> > 
> > if (need_qemu and nr_console > 1)
> > 
> > even though I am aware that at the moment nr_console is always 1.
> 
> There isn't actually a nr_console here, just a hardcoded 1... I could
> add a nr_console just for this but perhaps it makes more sense for
> libxl__need_xenpv_qemu to enforce this by updating consback for all
> consoles iff there are > 1 of them and then returning need_qemu as
> appropriate?
> 
> I'm a little unhappy with having need_qemu have side-effects like this,
> but it seems better than splitting the logic into two places...

I would be OK with that, maybe it is worth adding a comment on
libxl__need_xenpv_qemu to document the behavior.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:44:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzhZ-0004lK-80; Wed, 25 Apr 2012 10:44:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SMzhX-0004l2-RR
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:44:00 +0000
Received: from [85.158.138.51:27711] by server-10.bemta-3.messagelabs.com id
	D9/6A-29478-E65D79F4; Wed, 25 Apr 2012 10:43:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335350637!15776915!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22792 invoked from network); 25 Apr 2012 10:43:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:43:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:43:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:43:26 +0100
Date: Wed, 25 Apr 2012 11:49:30 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335350442.28015.29.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
	<1335350442.28015.29.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Ian Campbell wrote:
> On Wed, 2012-04-25 at 11:36 +0100, Stefano Stabellini wrote:
> > On Wed, 25 Apr 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1335348624 -3600
> > > # Node ID c8486295429011e9a220db1b6ed9f34ba690e729
> > > # Parent  6f740f2f6e3e080e4bba9df59c826947885f6bd7
> > > libxl: default to xenconsoled for pv guests, even if qemu is running.
> > > 
> > > Currently we prefer to use qemu for the disk backend if we are starting qemu
> > > anyway (e.g. to service a disk).
> > > 
> > > Unfortunately qemu doesn't log the console, which xenconsoled can do via
> > > XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> > > there is no particular reason to prefer qemu just because it happens to be
> > > running.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > QEMU's console backend supports multiple PV consoles while xenconsoled
> > does not.
> > I think you should just change the default only in case a single PV
> > console is configured.
> > 
> > 
> > > I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> > > of change?
> > > 
> > > diff -r 6f740f2f6e3e -r c84862954290 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c	Wed Apr 25 11:05:05 2012 +0100
> > > +++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:10:24 2012 +0100
> > > @@ -682,8 +682,7 @@ static int do_domain_create(libxl__gc *g
> > >                  d_config->num_vfbs, d_config->vfbs,
> > >                  d_config->num_disks, &d_config->disks[0]);
> > >  
> > > -        if (need_qemu)
> > > -             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
> > > +        console.consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
> > >  
> > >          libxl__device_console_add(gc, domid, &console, &state);
> > >          libxl__device_console_dispose(&console);
> > 
> > I would change the if into:
> > 
> > if (need_qemu and nr_console > 1)
> > 
> > even though I am aware that at the moment nr_console is always 1.
> 
> There isn't actually a nr_console here, just a hardcoded 1... I could
> add a nr_console just for this but perhaps it makes more sense for
> libxl__need_xenpv_qemu to enforce this by updating consback for all
> consoles iff there are > 1 of them and then returning need_qemu as
> appropriate?
> 
> I'm a little unhappy with having need_qemu have side-effects like this,
> but it seems better than splitting the logic into two places...

I would be OK with that, maybe it is worth adding a comment on
libxl__need_xenpv_qemu to document the behavior.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMziy-0004sN-O2; Wed, 25 Apr 2012 10:45:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzix-0004sB-0V
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:45:27 +0000
Received: from [85.158.139.83:43067] by server-12.bemta-5.messagelabs.com id
	C6/FE-05587-6C5D79F4; Wed, 25 Apr 2012 10:45:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335350725!25405947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14433 invoked from network); 25 Apr 2012 10:45:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:45:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:45:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:45:24 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMziu-0005Aq-LM; Wed, 25 Apr 2012 10:45:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMziu-0000J2-Iz;
	Wed, 25 Apr 2012 11:45:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54724.573559.470745@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:45:24 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
References: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl/build: print a warning if
	flex/bison are needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v2] libxl/build: print a warning if flex/bison are needed"):
> This patch adds better support for both Flex and Bison, which might
> be needed to compile libxl. Now configure script sets BISON and FLEX
> Makefile vars if bison and flex are found, but doesn't complain if
> they are not found.
> 
> Also, added some Makefile soccery to print a warning message if
> Bison or Flex are needed but not found.

Marvellous.  I have applied this.  I altered the warning message
slightly:

 +ifeq ($(FLEX),)
 +%.c %.h:: %.l
-+      $(warning Flex is needed to compile libxl, please install it and rerun \
-+      configure)
++      $(warning Flex is needed to rebuild some libxl parsers and \
++                scanners, please install it and rerun configure)
 +endif
 +
 +ifeq ($(BISON),)
 +%.c %.h:: %.y
-+      $(warning Bison is needed to compile libxl, please install it an rerun \
-+      configure)
++      $(warning Bison is needed to rebuild some libxl parsers and \
++                scanners, please install it an rerun configure)
 +endif
 +

I trust that's OK.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMziy-0004sN-O2; Wed, 25 Apr 2012 10:45:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzix-0004sB-0V
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:45:27 +0000
Received: from [85.158.139.83:43067] by server-12.bemta-5.messagelabs.com id
	C6/FE-05587-6C5D79F4; Wed, 25 Apr 2012 10:45:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335350725!25405947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14433 invoked from network); 25 Apr 2012 10:45:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:45:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:45:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:45:24 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMziu-0005Aq-LM; Wed, 25 Apr 2012 10:45:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMziu-0000J2-Iz;
	Wed, 25 Apr 2012 11:45:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.54724.573559.470745@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:45:24 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
References: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl/build: print a warning if
	flex/bison are needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v2] libxl/build: print a warning if flex/bison are needed"):
> This patch adds better support for both Flex and Bison, which might
> be needed to compile libxl. Now configure script sets BISON and FLEX
> Makefile vars if bison and flex are found, but doesn't complain if
> they are not found.
> 
> Also, added some Makefile soccery to print a warning message if
> Bison or Flex are needed but not found.

Marvellous.  I have applied this.  I altered the warning message
slightly:

 +ifeq ($(FLEX),)
 +%.c %.h:: %.l
-+      $(warning Flex is needed to compile libxl, please install it and rerun \
-+      configure)
++      $(warning Flex is needed to rebuild some libxl parsers and \
++                scanners, please install it and rerun configure)
 +endif
 +
 +ifeq ($(BISON),)
 +%.c %.h:: %.y
-+      $(warning Bison is needed to compile libxl, please install it an rerun \
-+      configure)
++      $(warning Bison is needed to rebuild some libxl parsers and \
++                scanners, please install it an rerun configure)
 +endif
 +

I trust that's OK.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:47:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:47:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzkJ-00051a-CJ; Wed, 25 Apr 2012 10:46:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMzkI-00051U-KO
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:46:50 +0000
Received: from [193.109.254.147:54778] by server-4.bemta-14.messagelabs.com id
	AD/D0-11570-916D79F4; Wed, 25 Apr 2012 10:46:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335350806!3781610!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6039 invoked from network); 25 Apr 2012 10:46:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:46:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191963032"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:46:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 06:46:45 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMzkC-0007DI-U5;
	Wed, 25 Apr 2012 11:46:44 +0100
Message-ID: <4F97D618.5010807@citrix.com>
Date: Wed, 25 Apr 2012 11:46:48 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
	<20375.54724.573559.470745@mariner.uk.xensource.com>
In-Reply-To: <20375.54724.573559.470745@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl/build: print a warning if
	flex/bison are needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[PATCH v2] libxl/build: print a warning if flex/=
bison are needed"):
>> This patch adds better support for both Flex and Bison, which might
>> be needed to compile libxl. Now configure script sets BISON and FLEX
>> Makefile vars if bison and flex are found, but doesn't complain if
>> they are not found.
>>
>> Also, added some Makefile soccery to print a warning message if
>> Bison or Flex are needed but not found.
>
> Marvellous.  I have applied this.  I altered the warning message
> slightly:
>
>   +ifeq ($(FLEX),)
>   +%.c %.h:: %.l
> -+      $(warning Flex is needed to compile libxl, please install it and =
rerun \
> -+      configure)
> ++      $(warning Flex is needed to rebuild some libxl parsers and \
> ++                scanners, please install it and rerun configure)
>   +endif
>   +
>   +ifeq ($(BISON),)
>   +%.c %.h:: %.y
> -+      $(warning Bison is needed to compile libxl, please install it an =
rerun \
> -+      configure)
> ++      $(warning Bison is needed to rebuild some libxl parsers and \
> ++                scanners, please install it an rerun configure)
>   +endif
>   +
>
> I trust that's OK.

Sure, thanks!

> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:47:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:47:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzkJ-00051a-CJ; Wed, 25 Apr 2012 10:46:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SMzkI-00051U-KO
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:46:50 +0000
Received: from [193.109.254.147:54778] by server-4.bemta-14.messagelabs.com id
	AD/D0-11570-916D79F4; Wed, 25 Apr 2012 10:46:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335350806!3781610!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6039 invoked from network); 25 Apr 2012 10:46:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:46:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191963032"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 06:46:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 06:46:45 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SMzkC-0007DI-U5;
	Wed, 25 Apr 2012 11:46:44 +0100
Message-ID: <4F97D618.5010807@citrix.com>
Date: Wed, 25 Apr 2012 11:46:48 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1335345282-42997-1-git-send-email-roger.pau@citrix.com>
	<20375.54724.573559.470745@mariner.uk.xensource.com>
In-Reply-To: <20375.54724.573559.470745@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl/build: print a warning if
	flex/bison are needed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[PATCH v2] libxl/build: print a warning if flex/=
bison are needed"):
>> This patch adds better support for both Flex and Bison, which might
>> be needed to compile libxl. Now configure script sets BISON and FLEX
>> Makefile vars if bison and flex are found, but doesn't complain if
>> they are not found.
>>
>> Also, added some Makefile soccery to print a warning message if
>> Bison or Flex are needed but not found.
>
> Marvellous.  I have applied this.  I altered the warning message
> slightly:
>
>   +ifeq ($(FLEX),)
>   +%.c %.h:: %.l
> -+      $(warning Flex is needed to compile libxl, please install it and =
rerun \
> -+      configure)
> ++      $(warning Flex is needed to rebuild some libxl parsers and \
> ++                scanners, please install it and rerun configure)
>   +endif
>   +
>   +ifeq ($(BISON),)
>   +%.c %.h:: %.y
> -+      $(warning Bison is needed to compile libxl, please install it an =
rerun \
> -+      configure)
> ++      $(warning Bison is needed to rebuild some libxl parsers and \
> ++                scanners, please install it an rerun configure)
>   +endif
>   +
>
> I trust that's OK.

Sure, thanks!

> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:51:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzoJ-0005G8-2T; Wed, 25 Apr 2012 10:50:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMzoI-0005G1-1X
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:50:58 +0000
Received: from [85.158.143.99:28318] by server-1.bemta-4.messagelabs.com id
	3E/5B-20925-117D79F4; Wed, 25 Apr 2012 10:50:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335351054!18812933!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21535 invoked from network); 25 Apr 2012 10:50:55 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:50:55 -0000
Received: by qcsp15 with SMTP id p15so1202989qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 03:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fpFxFeG/uUqyLJSdm/iW2i3NO+JOLlLL/10A5/p6XdM=;
	b=TC1kGpbGv/y87wsnFGyG/BeeuWg+8jwLvzipSc4YgV2twFr67gmdWUOVyDJSApVZyq
	kVimWoSeywy/HVbDlUy02EwZPUhZMkNTemzlRsu2Cr3XbD6SqtlDE0ZNtOe0E5cwvo3b
	K56YDn4qsKOUSSHH/NTQZiRqJTdPlqboAHHsQ8DvXSHs3/M7DDodgihrW7fo4XB2sjdz
	HEpcx2FQhepjuXTcmSlhfGAF6hNCJ92PRuXvw+Z4cLrSu6B40YMFE4cwVZilICEe75l2
	LiV2hSXRPDUzlVCGlTD9X84NOxAAgmC5Nc2csVIYbgadeeH0WJXp43mtSEM8x4IwYK5A
	VBWg==
MIME-Version: 1.0
Received: by 10.224.181.69 with SMTP id bx5mr1568207qab.49.1335351053631; Wed,
	25 Apr 2012 03:50:53 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Wed, 25 Apr 2012 03:50:53 -0700 (PDT)
In-Reply-To: <20373.29788.772445.467842@mariner.uk.xensource.com>
References: <0fb728d56baeaed476d2.1333477788@kodo2>
	<20373.29788.772445.467842@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:50:53 +0100
X-Google-Sender-Auth: Ro2-Yvn3FPxN5CHCyZsiekiGCIo
Message-ID: <CAFLBxZZNRVbukYX=v=dAXxONKGL0o3w2=aezX8EJ4KJqxfvtJw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 4:25 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr=
ote:
>> - =A0 =A0printf("Using config file \"%s\"\n", filename);
>> + =A0 =A0printf("Using config file \"%s\"\n", config_src);
>
> This will print
> =A0 Using config file "command line"
> which is rather an odd message. =A0Perhaps change the string to
> `<command line>' and remove the quotes ?

Changing the string to <command line> makes sense.  I think the point
of putting quotes there is to avoid getting strange results if your
filenames have spaces.  But I suppose if you're strange enough to be
using spaces in your filenames, you should be able to figure out
what's going on yourself. :-)

New patch on the way...
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:51:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzoJ-0005G8-2T; Wed, 25 Apr 2012 10:50:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SMzoI-0005G1-1X
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:50:58 +0000
Received: from [85.158.143.99:28318] by server-1.bemta-4.messagelabs.com id
	3E/5B-20925-117D79F4; Wed, 25 Apr 2012 10:50:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335351054!18812933!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21535 invoked from network); 25 Apr 2012 10:50:55 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:50:55 -0000
Received: by qcsp15 with SMTP id p15so1202989qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 03:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fpFxFeG/uUqyLJSdm/iW2i3NO+JOLlLL/10A5/p6XdM=;
	b=TC1kGpbGv/y87wsnFGyG/BeeuWg+8jwLvzipSc4YgV2twFr67gmdWUOVyDJSApVZyq
	kVimWoSeywy/HVbDlUy02EwZPUhZMkNTemzlRsu2Cr3XbD6SqtlDE0ZNtOe0E5cwvo3b
	K56YDn4qsKOUSSHH/NTQZiRqJTdPlqboAHHsQ8DvXSHs3/M7DDodgihrW7fo4XB2sjdz
	HEpcx2FQhepjuXTcmSlhfGAF6hNCJ92PRuXvw+Z4cLrSu6B40YMFE4cwVZilICEe75l2
	LiV2hSXRPDUzlVCGlTD9X84NOxAAgmC5Nc2csVIYbgadeeH0WJXp43mtSEM8x4IwYK5A
	VBWg==
MIME-Version: 1.0
Received: by 10.224.181.69 with SMTP id bx5mr1568207qab.49.1335351053631; Wed,
	25 Apr 2012 03:50:53 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Wed, 25 Apr 2012 03:50:53 -0700 (PDT)
In-Reply-To: <20373.29788.772445.467842@mariner.uk.xensource.com>
References: <0fb728d56baeaed476d2.1333477788@kodo2>
	<20373.29788.772445.467842@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:50:53 +0100
X-Google-Sender-Auth: Ro2-Yvn3FPxN5CHCyZsiekiGCIo
Message-ID: <CAFLBxZZNRVbukYX=v=dAXxONKGL0o3w2=aezX8EJ4KJqxfvtJw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: Don't require a config file for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 23, 2012 at 4:25 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wr=
ote:
>> - =A0 =A0printf("Using config file \"%s\"\n", filename);
>> + =A0 =A0printf("Using config file \"%s\"\n", config_src);
>
> This will print
> =A0 Using config file "command line"
> which is rather an odd message. =A0Perhaps change the string to
> `<command line>' and remove the quotes ?

Changing the string to <command line> makes sense.  I think the point
of putting quotes there is to avoid getting strange results if your
filenames have spaces.  But I suppose if you're strange enough to be
using spaces in your filenames, you should be able to figure out
what's going on yourself. :-)

New patch on the way...
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzpX-0005Kw-IC; Wed, 25 Apr 2012 10:52:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzpW-0005Kp-9s
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:52:14 +0000
Received: from [85.158.139.83:43454] by server-12.bemta-5.messagelabs.com id
	A5/38-05587-D57D79F4; Wed, 25 Apr 2012 10:52:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335351131!25406263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10200 invoked from network); 25 Apr 2012 10:52:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:52:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:52:11 +0100
Message-ID: <1335351129.28015.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:52:09 +0100
In-Reply-To: <20375.53950.77177.102406@mariner.uk.xensource.com>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<20375.53950.77177.102406@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:32 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running"):
> > libxl: default to xenconsoled for pv guests, even if qemu is running.
> > 
> > Currently we prefer to use qemu for the disk backend if we are starting qemu
> > anyway (e.g. to service a disk).
> ...
> > I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> > of change?
> 
> I think we can regard this as a bugfix, or make an exception.
> 
> But: have you tested this ?  ISTR hearing that there was some
> difficulty getting a pv qemu not to try to provide the console.

I did run a PV guest with it and it seemed to be doing what I expected
(i.e. my guest logs showed up in /var/log/xen/console).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzpX-0005Kw-IC; Wed, 25 Apr 2012 10:52:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SMzpW-0005Kp-9s
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 10:52:14 +0000
Received: from [85.158.139.83:43454] by server-12.bemta-5.messagelabs.com id
	A5/38-05587-D57D79F4; Wed, 25 Apr 2012 10:52:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335351131!25406263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10200 invoked from network); 25 Apr 2012 10:52:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:52:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:52:11 +0100
Message-ID: <1335351129.28015.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 11:52:09 +0100
In-Reply-To: <20375.53950.77177.102406@mariner.uk.xensource.com>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<20375.53950.77177.102406@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:32 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running"):
> > libxl: default to xenconsoled for pv guests, even if qemu is running.
> > 
> > Currently we prefer to use qemu for the disk backend if we are starting qemu
> > anyway (e.g. to service a disk).
> ...
> > I'm not sure if this is 4.2 material, perhaps too late to be making this sort
> > of change?
> 
> I think we can regard this as a bugfix, or make an exception.
> 
> But: have you tested this ?  ISTR hearing that there was some
> difficulty getting a pv qemu not to try to provide the console.

I did run a PV guest with it and it seemed to be doing what I expected
(i.e. my guest logs showed up in /var/log/xen/console).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzvP-0005YH-CX; Wed, 25 Apr 2012 10:58:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzvO-0005YC-MA
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:58:18 +0000
Received: from [85.158.143.99:14714] by server-2.bemta-4.messagelabs.com id
	B7/7F-17550-AC8D79F4; Wed, 25 Apr 2012 10:58:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335351496!15423815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21977 invoked from network); 25 Apr 2012 10:58:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:58:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:58:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:58:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzvK-0005Gb-VJ	for xen-devel@lists.xensource.com;
	Wed, 25 Apr 2012 10:58:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzvK-0000l6-UI	for
	xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:58:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.55494.925787.524611@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:58:14 +0100
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH 1/2] libxl: provide "realclean" to remove
	autogenerated files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This removes even the files committed into the tree.  One consequence is
that it becomes easier to reliably force a total rebuild.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 841b7e3bd1f9 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/Makefile	Wed Apr 25 11:52:58 2012 +0100
@@ -70,8 +70,9 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
-AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTO_STEMS := $(basename $(wildcard *.[ly]))
+AUTOINCS= $(addsuffix .h, $(AUTO_STEMS)) _libxl_list.h
+AUTOSRCS= $(addsuffix .c, $(AUTO_STEMS))
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
@@ -182,8 +183,10 @@ clean:
 	$(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS)
 	$(RM) -f _*.c *.pyc _libxl_paths.*.tmp
 	$(RM) -f testidl.c.new testidl.c
-#	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
 
 distclean: clean
 
+realclean: distclean
+	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
+
 -include $(DEPS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzvP-0005YH-CX; Wed, 25 Apr 2012 10:58:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzvO-0005YC-MA
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:58:18 +0000
Received: from [85.158.143.99:14714] by server-2.bemta-4.messagelabs.com id
	B7/7F-17550-AC8D79F4; Wed, 25 Apr 2012 10:58:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1335351496!15423815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21977 invoked from network); 25 Apr 2012 10:58:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:58:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:58:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:58:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzvK-0005Gb-VJ	for xen-devel@lists.xensource.com;
	Wed, 25 Apr 2012 10:58:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzvK-0000l6-UI	for
	xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:58:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.55494.925787.524611@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:58:14 +0100
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH 1/2] libxl: provide "realclean" to remove
	autogenerated files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This removes even the files committed into the tree.  One consequence is
that it becomes easier to reliably force a total rebuild.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 841b7e3bd1f9 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/Makefile	Wed Apr 25 11:52:58 2012 +0100
@@ -70,8 +70,9 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
-AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTO_STEMS := $(basename $(wildcard *.[ly]))
+AUTOINCS= $(addsuffix .h, $(AUTO_STEMS)) _libxl_list.h
+AUTOSRCS= $(addsuffix .c, $(AUTO_STEMS))
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
@@ -182,8 +183,10 @@ clean:
 	$(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS)
 	$(RM) -f _*.c *.pyc _libxl_paths.*.tmp
 	$(RM) -f testidl.c.new testidl.c
-#	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
 
 distclean: clean
 
+realclean: distclean
+	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
+
 -include $(DEPS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:59:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzw6-0005b4-RY; Wed, 25 Apr 2012 10:59:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzw5-0005at-2o
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:59:01 +0000
Received: from [85.158.138.51:3482] by server-9.bemta-3.messagelabs.com id
	C3/37-26691-4F8D79F4; Wed, 25 Apr 2012 10:59:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335351539!23670604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12130 invoked from network); 25 Apr 2012 10:58:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:58:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:58:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:58:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzvm-0005Go-Sm	for xen-devel@lists.xensource.com;
	Wed, 25 Apr 2012 10:58:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzvm-0000lK-Qm	for
	xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:58:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.55522.813358.134995@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:58:42 +0100
To: xen-devel@lists.xensource.com
In-Reply-To: <20375.55494.925787.524611@mariner.uk.xensource.com>
References: <20375.55494.925787.524611@mariner.uk.xensource.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH 2/2] libxl: regenerate flex/bison output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

No intentional functional change.  The following hopefully
non-functional changes:
 * Regenerate parsers with Bison 2.4.1 (Debian's 1:2.4.1.dfsg-3 i386)
 * Whitespace fixes previously done to the whole of libxl are
   undone as far as they effect these files;
 * Remove semiautomatically-added "Local variables" stanzas from
   autogenerated files.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_l.c
--- a/tools/libxl/libxlu_cfg_l.c	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_l.c	Wed Apr 25 11:53:23 2012 +0100
@@ -34,7 +34,7 @@
 #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
 
 /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h,
- * if you want the limit (max/min) macros for int types.
+ * if you want the limit (max/min) macros for int types. 
  */
 #ifndef __STDC_LIMIT_MACROS
 #define __STDC_LIMIT_MACROS 1
@@ -51,7 +51,7 @@ typedef uint32_t flex_uint32_t;
 typedef signed char flex_int8_t;
 typedef short int flex_int16_t;
 typedef int flex_int32_t;
-typedef unsigned char flex_uint8_t;
+typedef unsigned char flex_uint8_t; 
 typedef unsigned short int flex_uint16_t;
 typedef unsigned int flex_uint32_t;
 
@@ -185,7 +185,7 @@ typedef struct yy_buffer_state *YY_BUFFE
 
     /* Note: We specifically omit the test for yy_rule_can_match_eol because it requires
      *       access to the local variable yy_act. Since yyless() is a macro, it would break
-     *       existing scanners that call yyless() from OUTSIDE xlu__cfg_yylex.
+     *       existing scanners that call yyless() from OUTSIDE xlu__cfg_yylex. 
      *       One obvious solution it to make yy_act a global. I tried that, and saw
      *       a 5% performance hit in a non-yylineno scanner, because yy_act is
      *       normally declared as a register variable-- so it is not worth it.
@@ -197,7 +197,7 @@ typedef struct yy_buffer_state *YY_BUFFE
                     if ( yytext[yyl] == '\n' )\
                         --yylineno;\
             }while(0)
-
+    
 /* Return all but the first "n" matched characters back to the input stream. */
 #define yyless(n) \
 	do \
@@ -259,7 +259,7 @@ struct yy_buffer_state
 
     int yy_bs_lineno; /**< The line count. */
     int yy_bs_column; /**< The column count. */
-
+    
 	/* Whether to try to fill the input buffer when we reach the
 	 * end of it.
 	 */
@@ -574,9 +574,9 @@ static int yy_init_globals (yyscan_t yys
     /* This must go here because YYSTYPE and YYLTYPE are included
      * from bison output in section 1.*/
     #    define yylval yyg->yylval_r
-
+    
     #    define yylloc yyg->yylloc_r
-
+    
 int xlu__cfg_yylex_init (yyscan_t* scanner);
 
 int xlu__cfg_yylex_init_extra (YY_EXTRA_TYPE user_defined,yyscan_t* scanner);
@@ -615,9 +615,9 @@ YYSTYPE * xlu__cfg_yyget_lval (yyscan_t 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
 
        YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner );
-
+    
         void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner );
-
+    
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -845,7 +845,7 @@ yy_find_action:
 			int yyl;
 			for ( yyl = yyg->yy_more_len; yyl < yyleng; ++yyl )
 				if ( yytext[yyl] == '\n' )
-
+					   
     do{ yylineno++;
         yycolumn=0;
     }while(0)
@@ -1377,7 +1377,7 @@ static int yy_get_next_buffer (yyscan_t 
 	yyg->yy_hold_char = *++yyg->yy_c_buf_p;
 
 	if ( c == '\n' )
-
+		   
     do{ yylineno++;
         yycolumn=0;
     }while(0)
@@ -1460,7 +1460,7 @@ static void xlu__cfg_yy_load_buffer_stat
     YY_BUFFER_STATE xlu__cfg_yy_create_buffer  (FILE * file, int  size , yyscan_t yyscanner)
 {
 	YY_BUFFER_STATE b;
-
+    
 	b = (YY_BUFFER_STATE) xlu__cfg_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner );
 	if ( ! b )
 		YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yy_create_buffer()" );
@@ -1504,7 +1504,7 @@ static void xlu__cfg_yy_load_buffer_stat
 #ifndef __cplusplus
 extern int isatty (int );
 #endif /* __cplusplus */
-
+    
 /* Initializes or reinitializes a buffer.
  * This function is sometimes called more than once on the same buffer,
  * such as during a xlu__cfg_yyrestart() or at EOF.
@@ -1530,7 +1530,7 @@ extern int isatty (int );
     }
 
         b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
-
+    
 	errno = oerrno;
 }
 
@@ -1636,9 +1636,9 @@ static void xlu__cfg_yyensure_buffer_sta
 								, yyscanner);
 		if ( ! yyg->yy_buffer_stack )
 			YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yyensure_buffer_stack()" );
-
+								  
 		memset(yyg->yy_buffer_stack, 0, num_to_alloc * sizeof(struct yy_buffer_state*));
-
+				
 		yyg->yy_buffer_stack_max = num_to_alloc;
 		yyg->yy_buffer_stack_top = 0;
 		return;
@@ -1667,12 +1667,12 @@ static void xlu__cfg_yyensure_buffer_sta
  * @param base the character buffer
  * @param size the size in bytes of the character buffer
  * @param yyscanner The scanner object.
- * @return the newly allocated buffer state object.
+ * @return the newly allocated buffer state object. 
  */
 YY_BUFFER_STATE xlu__cfg_yy_scan_buffer  (char * base, yy_size_t  size , yyscan_t yyscanner)
 {
 	YY_BUFFER_STATE b;
-
+    
 	if ( size < 2 ||
 	     base[size-2] != YY_END_OF_BUFFER_CHAR ||
 	     base[size-1] != YY_END_OF_BUFFER_CHAR )
@@ -1708,7 +1708,7 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_buffer 
  */
 YY_BUFFER_STATE xlu__cfg_yy_scan_string (yyconst char * yystr , yyscan_t yyscanner)
 {
-
+    
 	return xlu__cfg_yy_scan_bytes(yystr,strlen(yystr) ,yyscanner);
 }
 
@@ -1725,7 +1725,7 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_bytes  
 	char *buf;
 	yy_size_t n;
 	int i;
-
+    
 	/* Get memory for full buffer, including space for trailing EOB's. */
 	n = _yybytes_len + 2;
 	buf = (char *) xlu__cfg_yyalloc(n ,yyscanner );
@@ -1793,10 +1793,10 @@ YY_EXTRA_TYPE xlu__cfg_yyget_extra  (yys
 int xlu__cfg_yyget_lineno  (yyscan_t yyscanner)
 {
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
-
+    
         if (! YY_CURRENT_BUFFER)
             return 0;
-
+    
     return yylineno;
 }
 
@@ -1806,10 +1806,10 @@ int xlu__cfg_yyget_lineno  (yyscan_t yys
 int xlu__cfg_yyget_column  (yyscan_t yyscanner)
 {
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
-
+    
         if (! YY_CURRENT_BUFFER)
             return 0;
-
+    
     return yycolumn;
 }
 
@@ -1870,8 +1870,8 @@ void xlu__cfg_yyset_lineno (int  line_nu
 
         /* lineno is only valid if an input buffer exists. */
         if (! YY_CURRENT_BUFFER )
-           yy_fatal_error( "xlu__cfg_yyset_lineno called with no buffer" , yyscanner);
-
+           yy_fatal_error( "xlu__cfg_yyset_lineno called with no buffer" , yyscanner); 
+    
     yylineno = line_number;
 }
 
@@ -1885,8 +1885,8 @@ void xlu__cfg_yyset_column (int  column_
 
         /* column is only valid if an input buffer exists. */
         if (! YY_CURRENT_BUFFER )
-           yy_fatal_error( "xlu__cfg_yyset_column called with no buffer" , yyscanner);
-
+           yy_fatal_error( "xlu__cfg_yyset_column called with no buffer" , yyscanner); 
+    
     yycolumn = column_no;
 }
 
@@ -1939,13 +1939,13 @@ YYLTYPE *xlu__cfg_yyget_lloc  (yyscan_t 
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
     return yylloc;
 }
-
+    
 void xlu__cfg_yyset_lloc (YYLTYPE *  yylloc_param , yyscan_t yyscanner)
 {
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
     yylloc = yylloc_param;
 }
-
+    
 /* User-visible API */
 
 /* xlu__cfg_yylex_init is special because it creates the scanner itself, so it is
@@ -1993,20 +1993,20 @@ int xlu__cfg_yylex_init_extra(YY_EXTRA_T
         errno = EINVAL;
         return 1;
     }
-
+	
     *ptr_yy_globals = (yyscan_t) xlu__cfg_yyalloc ( sizeof( struct yyguts_t ), &dummy_yyguts );
-
+	
     if (*ptr_yy_globals == NULL){
         errno = ENOMEM;
         return 1;
     }
-
+    
     /* By setting to 0xAA, we expose bugs in
     yy_init_globals. Leave at 0x00 for releases. */
     memset(*ptr_yy_globals,0x00,sizeof(struct yyguts_t));
-
+    
     xlu__cfg_yyset_extra (yy_user_defined, *ptr_yy_globals);
-
+    
     return yy_init_globals ( *ptr_yy_globals );
 }
 
@@ -2122,11 +2122,3 @@ void xlu__cfg_yyfree (void * ptr , yysca
 #define YYTABLES_NAME "yytables"
 
 #line 104 "libxlu_cfg_l.l"
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_l.h
--- a/tools/libxl/libxlu_cfg_l.h	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_l.h	Wed Apr 25 11:53:23 2012 +0100
@@ -38,7 +38,7 @@
 #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
 
 /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h,
- * if you want the limit (max/min) macros for int types.
+ * if you want the limit (max/min) macros for int types. 
  */
 #ifndef __STDC_LIMIT_MACROS
 #define __STDC_LIMIT_MACROS 1
@@ -55,7 +55,7 @@ typedef uint32_t flex_uint32_t;
 typedef signed char flex_int8_t;
 typedef short int flex_int16_t;
 typedef int flex_int32_t;
-typedef unsigned char flex_uint8_t;
+typedef unsigned char flex_uint8_t; 
 typedef unsigned short int flex_uint16_t;
 typedef unsigned int flex_uint32_t;
 
@@ -193,7 +193,7 @@ struct yy_buffer_state
 
     int yy_bs_lineno; /**< The line count. */
     int yy_bs_column; /**< The column count. */
-
+    
 	/* Whether to try to fill the input buffer when we reach the
 	 * end of it.
 	 */
@@ -281,9 +281,9 @@ YYSTYPE * xlu__cfg_yyget_lval (yyscan_t 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
 
        YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner );
-
+    
         void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner );
-
+    
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -355,11 +355,3 @@ extern int xlu__cfg_yylex \
 #line 356 "libxlu_cfg_l.h"
 #undef xlu__cfg_yyIN_HEADER
 #endif /* xlu__cfg_yyHEADER_H */
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_y.c
--- a/tools/libxl/libxlu_cfg_y.c	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_y.c	Wed Apr 25 11:53:23 2012 +0100
@@ -1,24 +1,23 @@
-/* A Bison parser, made by GNU Bison 2.3.  */
+
+/* A Bison parser, made by GNU Bison 2.4.1.  */
 
 /* Skeleton implementation for Bison's Yacc-like parsers in C
-
-   Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
+   
+      Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
    Free Software Foundation, Inc.
-
-   This program is free software; you can redistribute it and/or modify
+   
+   This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2, or (at your option)
-   any later version.
-
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+   
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
-
+   
    You should have received a copy of the GNU General Public License
-   along with this program; if not, write to the Free Software
-   Foundation, Inc., 51 Franklin Street, Fifth Floor,
-   Boston, MA 02110-1301, USA.  */
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 /* As a special exception, you may create a larger work that contains
    part or all of the Bison parser skeleton and distribute that work
@@ -29,7 +28,7 @@
    special exception, which will cause the skeleton and the resulting
    Bison output files to be licensed under the GNU General Public
    License without this special exception.
-
+   
    This special exception was added by the Free Software Foundation in
    version 2.2 of Bison.  */
 
@@ -47,7 +46,7 @@
 #define YYBISON 1
 
 /* Bison version.  */
-#define YYBISON_VERSION "2.3"
+#define YYBISON_VERSION "2.4.1"
 
 /* Skeleton name.  */
 #define YYSKELETON_NAME "yacc.c"
@@ -55,41 +54,28 @@
 /* Pure parsers.  */
 #define YYPURE 1
 
+/* Push parsers.  */
+#define YYPUSH 0
+
+/* Pull parsers.  */
+#define YYPULL 1
+
 /* Using locations.  */
 #define YYLSP_NEEDED 1
 
 /* Substitute the variable and function names.  */
-#define yyparse xlu__cfg_yyparse
-#define yylex   xlu__cfg_yylex
-#define yyerror xlu__cfg_yyerror
-#define yylval  xlu__cfg_yylval
-#define yychar  xlu__cfg_yychar
-#define yydebug xlu__cfg_yydebug
-#define yynerrs xlu__cfg_yynerrs
-#define yylloc xlu__cfg_yylloc
-
-/* Tokens.  */
-#ifndef YYTOKENTYPE
-# define YYTOKENTYPE
-   /* Put the tokens into the symbol table, so that GDB and other debuggers
-      know about them.  */
-   enum yytokentype {
-     IDENT = 258,
-     STRING = 259,
-     NUMBER = 260,
-     NEWLINE = 261
-   };
-#endif
-/* Tokens.  */
-#define IDENT 258
-#define STRING 259
-#define NUMBER 260
-#define NEWLINE 261
-
-
-
+#define yyparse         xlu__cfg_yyparse
+#define yylex           xlu__cfg_yylex
+#define yyerror         xlu__cfg_yyerror
+#define yylval          xlu__cfg_yylval
+#define yychar          xlu__cfg_yychar
+#define yydebug         xlu__cfg_yydebug
+#define yynerrs         xlu__cfg_yynerrs
+#define yylloc          xlu__cfg_yylloc
 
 /* Copy the first part of user declarations.  */
+
+/* Line 189 of yacc.c  */
 #line 19 "libxlu_cfg_y.y"
 
 #define YYLEX_PARAM ctx->scanner
@@ -97,6 +83,9 @@
 #include "libxlu_cfg_l.h"
 
 
+/* Line 189 of yacc.c  */
+#line 88 "libxlu_cfg_y.c"
+
 /* Enabling traces.  */
 #ifndef YYDEBUG
 # define YYDEBUG 0
@@ -115,19 +104,40 @@
 # define YYTOKEN_TABLE 0
 #endif
 
+
+/* Tokens.  */
+#ifndef YYTOKENTYPE
+# define YYTOKENTYPE
+   /* Put the tokens into the symbol table, so that GDB and other debuggers
+      know about them.  */
+   enum yytokentype {
+     IDENT = 258,
+     STRING = 259,
+     NUMBER = 260,
+     NEWLINE = 261
+   };
+#endif
+
+
+
 #if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
 typedef union YYSTYPE
+{
+
+/* Line 214 of yacc.c  */
 #line 25 "libxlu_cfg_y.y"
-{
+
   char *string;
   XLU_ConfigSetting *setting;
-}
-/* Line 187 of yacc.c.  */
-#line 127 "libxlu_cfg_y.c"
-	YYSTYPE;
+
+
+
+/* Line 214 of yacc.c  */
+#line 137 "libxlu_cfg_y.c"
+} YYSTYPE;
+# define YYSTYPE_IS_TRIVIAL 1
 # define yystype YYSTYPE /* obsolescent; will be withdrawn */
 # define YYSTYPE_IS_DECLARED 1
-# define YYSTYPE_IS_TRIVIAL 1
 #endif
 
 #if ! defined YYLTYPE && ! defined YYLTYPE_IS_DECLARED
@@ -147,8 +157,8 @@ typedef struct YYLTYPE
 /* Copy the second part of user declarations.  */
 
 
-/* Line 216 of yacc.c.  */
-#line 152 "libxlu_cfg_y.c"
+/* Line 264 of yacc.c  */
+#line 162 "libxlu_cfg_y.c"
 
 #ifdef short
 # undef short
@@ -223,14 +233,14 @@ typedef short int yytype_int16;
 #if (defined __STDC__ || defined __C99__FUNC__ \
      || defined __cplusplus || defined _MSC_VER)
 static int
-YYID (int i)
+YYID (int yyi)
 #else
 static int
-YYID (i)
-    int i;
+YYID (yyi)
+    int yyi;
 #endif
 {
-  return i;
+  return yyi;
 }
 #endif
 
@@ -312,9 +322,9 @@ void free (void *); /* INFRINGES ON USER
 /* A type that is properly aligned for any stack member.  */
 union yyalloc
 {
-  yytype_int16 yyss;
-  YYSTYPE yyvs;
-    YYLTYPE yyls;
+  yytype_int16 yyss_alloc;
+  YYSTYPE yyvs_alloc;
+  YYLTYPE yyls_alloc;
 };
 
 /* The size of the maximum gap between one aligned stack and the next.  */
@@ -349,12 +359,12 @@ union yyalloc
    elements in the stack, and YYPTR gives the new location of the
    stack.  Advance YYPTR to a properly aligned location for the next
    stack.  */
-# define YYSTACK_RELOCATE(Stack)					\
+# define YYSTACK_RELOCATE(Stack_alloc, Stack)				\
     do									\
       {									\
 	YYSIZE_T yynewbytes;						\
-	YYCOPY (&yyptr->Stack, Stack, yysize);				\
-	Stack = &yyptr->Stack;						\
+	YYCOPY (&yyptr->Stack_alloc, Stack, yysize);			\
+	Stack = &yyptr->Stack_alloc;					\
 	yynewbytes = yystacksize * sizeof (*Stack) + YYSTACK_GAP_MAXIMUM; \
 	yyptr += yynewbytes / sizeof (*yyptr);				\
       }									\
@@ -451,7 +461,7 @@ static const yytype_uint8 yyrline[] =
 static const char *const yytname[] =
 {
   "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
-  "'='", "';'", "'['", "']'", "','", "$accept", "file", "setting", "@1",
+  "'='", "';'", "'['", "']'", "','", "$accept", "file", "setting", "$@1",
   "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
 };
 #endif
@@ -732,17 +742,20 @@ yy_symbol_print (yyoutput, yytype, yyval
 #if (defined __STDC__ || defined __C99__FUNC__ \
      || defined __cplusplus || defined _MSC_VER)
 static void
-yy_stack_print (yytype_int16 *bottom, yytype_int16 *top)
+yy_stack_print (yytype_int16 *yybottom, yytype_int16 *yytop)
 #else
 static void
-yy_stack_print (bottom, top)
-    yytype_int16 *bottom;
-    yytype_int16 *top;
+yy_stack_print (yybottom, yytop)
+    yytype_int16 *yybottom;
+    yytype_int16 *yytop;
 #endif
 {
   YYFPRINTF (stderr, "Stack now");
-  for (; bottom <= top; ++bottom)
-    YYFPRINTF (stderr, " %d", *bottom);
+  for (; yybottom <= yytop; yybottom++)
+    {
+      int yybot = *yybottom;
+      YYFPRINTF (stderr, " %d", yybot);
+    }
   YYFPRINTF (stderr, "\n");
 }
 
@@ -778,11 +791,11 @@ yy_reduce_print (yyvsp, yylsp, yyrule, c
   /* The symbols being reduced.  */
   for (yyi = 0; yyi < yynrhs; yyi++)
     {
-      fprintf (stderr, "   $%d = ", yyi + 1);
+      YYFPRINTF (stderr, "   $%d = ", yyi + 1);
       yy_symbol_print (stderr, yyrhs[yyprhs[yyrule] + yyi],
 		       &(yyvsp[(yyi + 1) - (yynrhs)])
 		       , &(yylsp[(yyi + 1) - (yynrhs)])		       , ctx);
-      fprintf (stderr, "\n");
+      YYFPRINTF (stderr, "\n");
     }
 }
 
@@ -819,7 +832,7 @@ int yydebug;
 # define YYMAXDEPTH 10000
 #endif
 
-
+
 
 #if YYERROR_VERBOSE
 
@@ -1030,7 +1043,7 @@ yysyntax_error (char *yyresult, int yyst
     }
 }
 #endif /* YYERROR_VERBOSE */
-
+
 
 /*-----------------------------------------------.
 | Release the memory associated to this symbol.  |
@@ -1062,39 +1075,67 @@ yydestruct (yymsg, yytype, yyvaluep, yyl
   switch (yytype)
     {
       case 3: /* "IDENT" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1068 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1085 "libxlu_cfg_y.c"
 	break;
       case 4: /* "STRING" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1073 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1094 "libxlu_cfg_y.c"
 	break;
       case 5: /* "NUMBER" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1078 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1103 "libxlu_cfg_y.c"
 	break;
       case 17: /* "value" */
+
+/* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
-#line 1083 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1112 "libxlu_cfg_y.c"
 	break;
       case 18: /* "atom" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1088 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1121 "libxlu_cfg_y.c"
 	break;
       case 19: /* "valuelist" */
+
+/* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
-#line 1093 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1130 "libxlu_cfg_y.c"
 	break;
       case 20: /* "values" */
+
+/* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
-#line 1098 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1139 "libxlu_cfg_y.c"
 	break;
 
       default:
@@ -1102,9 +1143,7 @@ yydestruct (yymsg, yytype, yyvaluep, yyl
     }
 }
 
-
 /* Prevent warnings from -Wmissing-prototypes.  */
-
 #ifdef YYPARSE_PARAM
 #if defined __STDC__ || defined __cplusplus
 int yyparse (void *YYPARSE_PARAM);
@@ -1123,10 +1162,9 @@ int yyparse ();
 
 
 
-
-/*----------.
-| yyparse.  |
-`----------*/
+/*-------------------------.
+| yyparse or yypush_parse.  |
+`-------------------------*/
 
 #ifdef YYPARSE_PARAM
 #if (defined __STDC__ || defined __C99__FUNC__ \
@@ -1150,24 +1188,59 @@ yyparse (ctx)
 #endif
 #endif
 {
-  /* The look-ahead symbol.  */
+/* The lookahead symbol.  */
 int yychar;
 
-/* The semantic value of the look-ahead symbol.  */
+/* The semantic value of the lookahead symbol.  */
 YYSTYPE yylval;
 
-/* Number of syntax errors so far.  */
-int yynerrs;
-/* Location data for the look-ahead symbol.  */
+/* Location data for the lookahead symbol.  */
 YYLTYPE yylloc;
 
-  int yystate;
+    /* Number of syntax errors so far.  */
+    int yynerrs;
+
+    int yystate;
+    /* Number of tokens to shift before error messages enabled.  */
+    int yyerrstatus;
+
+    /* The stacks and their tools:
+       `yyss': related to states.
+       `yyvs': related to semantic values.
+       `yyls': related to locations.
+
+       Refer to the stacks thru separate pointers, to allow yyoverflow
+       to reallocate them elsewhere.  */
+
+    /* The state stack.  */
+    yytype_int16 yyssa[YYINITDEPTH];
+    yytype_int16 *yyss;
+    yytype_int16 *yyssp;
+
+    /* The semantic value stack.  */
+    YYSTYPE yyvsa[YYINITDEPTH];
+    YYSTYPE *yyvs;
+    YYSTYPE *yyvsp;
+
+    /* The location stack.  */
+    YYLTYPE yylsa[YYINITDEPTH];
+    YYLTYPE *yyls;
+    YYLTYPE *yylsp;
+
+    /* The locations where the error started and ended.  */
+    YYLTYPE yyerror_range[2];
+
+    YYSIZE_T yystacksize;
+
   int yyn;
   int yyresult;
-  /* Number of tokens to shift before error messages enabled.  */
-  int yyerrstatus;
-  /* Look-ahead token as an internal (translated) token number.  */
-  int yytoken = 0;
+  /* Lookahead token as an internal (translated) token number.  */
+  int yytoken;
+  /* The variables used to return semantic value and location from the
+     action routines.  */
+  YYSTYPE yyval;
+  YYLTYPE yyloc;
+
 #if YYERROR_VERBOSE
   /* Buffer for error messages, and its allocated size.  */
   char yymsgbuf[128];
@@ -1175,63 +1248,37 @@ YYLTYPE yylloc;
   YYSIZE_T yymsg_alloc = sizeof yymsgbuf;
 #endif
 
-  /* Three stacks and their tools:
-     `yyss': related to states,
-     `yyvs': related to semantic values,
-     `yyls': related to locations.
-
-     Refer to the stacks thru separate pointers, to allow yyoverflow
-     to reallocate them elsewhere.  */
-
-  /* The state stack.  */
-  yytype_int16 yyssa[YYINITDEPTH];
-  yytype_int16 *yyss = yyssa;
-  yytype_int16 *yyssp;
-
-  /* The semantic value stack.  */
-  YYSTYPE yyvsa[YYINITDEPTH];
-  YYSTYPE *yyvs = yyvsa;
-  YYSTYPE *yyvsp;
-
-  /* The location stack.  */
-  YYLTYPE yylsa[YYINITDEPTH];
-  YYLTYPE *yyls = yylsa;
-  YYLTYPE *yylsp;
-  /* The locations where the error started and ended.  */
-  YYLTYPE yyerror_range[2];
-
 #define YYPOPSTACK(N)   (yyvsp -= (N), yyssp -= (N), yylsp -= (N))
 
-  YYSIZE_T yystacksize = YYINITDEPTH;
-
-  /* The variables used to return semantic value and location from the
-     action routines.  */
-  YYSTYPE yyval;
-  YYLTYPE yyloc;
-
   /* The number of symbols on the RHS of the reduced rule.
      Keep to zero when no symbol should be popped.  */
   int yylen = 0;
 
+  yytoken = 0;
+  yyss = yyssa;
+  yyvs = yyvsa;
+  yyls = yylsa;
+  yystacksize = YYINITDEPTH;
+
   YYDPRINTF ((stderr, "Starting parse\n"));
 
   yystate = 0;
   yyerrstatus = 0;
   yynerrs = 0;
-  yychar = YYEMPTY;		/* Cause a token to be read.  */
+  yychar = YYEMPTY; /* Cause a token to be read.  */
 
   /* Initialize stack pointers.
      Waste one element of value and location stack
      so that they stay on the same level as the state stack.
      The wasted elements are never initialized.  */
-
   yyssp = yyss;
   yyvsp = yyvs;
   yylsp = yyls;
+
 #if YYLTYPE_IS_TRIVIAL
   /* Initialize the default location before parsing starts.  */
   yylloc.first_line   = yylloc.last_line   = 1;
-  yylloc.first_column = yylloc.last_column = 0;
+  yylloc.first_column = yylloc.last_column = 1;
 #endif
 
   goto yysetstate;
@@ -1270,6 +1317,7 @@ YYLTYPE yylloc;
 		    &yyvs1, yysize * sizeof (*yyvsp),
 		    &yyls1, yysize * sizeof (*yylsp),
 		    &yystacksize);
+
 	yyls = yyls1;
 	yyss = yyss1;
 	yyvs = yyvs1;
@@ -1291,9 +1339,9 @@ YYLTYPE yylloc;
 	  (union yyalloc *) YYSTACK_ALLOC (YYSTACK_BYTES (yystacksize));
 	if (! yyptr)
 	  goto yyexhaustedlab;
-	YYSTACK_RELOCATE (yyss);
-	YYSTACK_RELOCATE (yyvs);
-	YYSTACK_RELOCATE (yyls);
+	YYSTACK_RELOCATE (yyss_alloc, yyss);
+	YYSTACK_RELOCATE (yyvs_alloc, yyvs);
+	YYSTACK_RELOCATE (yyls_alloc, yyls);
 #  undef YYSTACK_RELOCATE
 	if (yyss1 != yyssa)
 	  YYSTACK_FREE (yyss1);
@@ -1314,6 +1362,9 @@ YYLTYPE yylloc;
 
   YYDPRINTF ((stderr, "Entering state %d\n", yystate));
 
+  if (yystate == YYFINAL)
+    YYACCEPT;
+
   goto yybackup;
 
 /*-----------.
@@ -1322,16 +1373,16 @@ YYLTYPE yylloc;
 yybackup:
 
   /* Do appropriate processing given the current state.  Read a
-     look-ahead token if we need one and don't already have one.  */
+     lookahead token if we need one and don't already have one.  */
 
-  /* First try to decide what to do without reference to look-ahead token.  */
+  /* First try to decide what to do without reference to lookahead token.  */
   yyn = yypact[yystate];
   if (yyn == YYPACT_NINF)
     goto yydefault;
 
-  /* Not known => get a look-ahead token if don't already have one.  */
+  /* Not known => get a lookahead token if don't already have one.  */
 
-  /* YYCHAR is either YYEMPTY or YYEOF or a valid look-ahead symbol.  */
+  /* YYCHAR is either YYEMPTY or YYEOF or a valid lookahead symbol.  */
   if (yychar == YYEMPTY)
     {
       YYDPRINTF ((stderr, "Reading a token: "));
@@ -1363,20 +1414,16 @@ yybackup:
       goto yyreduce;
     }
 
-  if (yyn == YYFINAL)
-    YYACCEPT;
-
   /* Count tokens shifted since error; after three, turn off error
      status.  */
   if (yyerrstatus)
     yyerrstatus--;
 
-  /* Shift the look-ahead token.  */
+  /* Shift the lookahead token.  */
   YY_SYMBOL_PRINT ("Shifting", yytoken, &yylval, &yylloc);
 
-  /* Discard the shifted token unless it is eof.  */
-  if (yychar != YYEOF)
-    yychar = YYEMPTY;
+  /* Discard the shifted token.  */
+  yychar = YYEMPTY;
 
   yystate = yyn;
   *++yyvsp = yylval;
@@ -1417,58 +1464,79 @@ yyreduce:
   switch (yyn)
     {
         case 4:
+
+/* Line 1455 of yacc.c  */
 #line 50 "libxlu_cfg_y.y"
     { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); ;}
     break;
 
   case 10:
+
+/* Line 1455 of yacc.c  */
 #line 58 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); ;}
     break;
 
   case 11:
+
+/* Line 1455 of yacc.c  */
 #line 59 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(3) - (4)].setting); ;}
     break;
 
   case 12:
+
+/* Line 1455 of yacc.c  */
 #line 61 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
   case 13:
+
+/* Line 1455 of yacc.c  */
 #line 62 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
   case 14:
+
+/* Line 1455 of yacc.c  */
 #line 64 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); ;}
     break;
 
   case 15:
+
+/* Line 1455 of yacc.c  */
 #line 65 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (1)].setting); ;}
     break;
 
   case 16:
+
+/* Line 1455 of yacc.c  */
 #line 66 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (3)].setting); ;}
     break;
 
   case 17:
+
+/* Line 1455 of yacc.c  */
 #line 68 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); ;}
     break;
 
   case 18:
+
+/* Line 1455 of yacc.c  */
 #line 69 "libxlu_cfg_y.y"
     { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); ;}
     break;
 
 
-/* Line 1267 of yacc.c.  */
-#line 1472 "libxlu_cfg_y.c"
+
+/* Line 1455 of yacc.c  */
+#line 1540 "libxlu_cfg_y.c"
       default: break;
     }
   YY_SYMBOL_PRINT ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
@@ -1544,7 +1612,7 @@ yyerrlab:
 
   if (yyerrstatus == 3)
     {
-      /* If just tried and failed to reuse look-ahead token after an
+      /* If just tried and failed to reuse lookahead token after an
 	 error, discard it.  */
 
       if (yychar <= YYEOF)
@@ -1561,7 +1629,7 @@ yyerrlab:
 	}
     }
 
-  /* Else will try to reuse look-ahead token after shifting the error
+  /* Else will try to reuse lookahead token after shifting the error
      token.  */
   goto yyerrlab1;
 
@@ -1619,14 +1687,11 @@ yyerrlab1:
       YY_STACK_PRINT (yyss, yyssp);
     }
 
-  if (yyn == YYFINAL)
-    YYACCEPT;
-
   *++yyvsp = yylval;
 
   yyerror_range[1] = yylloc;
   /* Using YYLLOC is tempting, but would change the location of
-     the look-ahead.  YYLOC is available though.  */
+     the lookahead.  YYLOC is available though.  */
   YYLLOC_DEFAULT (yyloc, (yyerror_range - 1), 2);
   *++yylsp = yyloc;
 
@@ -1651,7 +1716,7 @@ yyabortlab:
   yyresult = 1;
   goto yyreturn;
 
-#ifndef yyoverflow
+#if !defined(yyoverflow) || YYERROR_VERBOSE
 /*-------------------------------------------------.
 | yyexhaustedlab -- memory exhaustion comes here.  |
 `-------------------------------------------------*/
@@ -1662,7 +1727,7 @@ yyexhaustedlab:
 #endif
 
 yyreturn:
-  if (yychar != YYEOF && yychar != YYEMPTY)
+  if (yychar != YYEMPTY)
      yydestruct ("Cleanup: discarding lookahead",
 		 yytoken, &yylval, &yylloc, ctx);
   /* Do not reclaim the symbols of the rule which action triggered
@@ -1689,11 +1754,3 @@ yyreturn:
 
 
 
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_y.h
--- a/tools/libxl/libxlu_cfg_y.h	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_y.h	Wed Apr 25 11:53:23 2012 +0100
@@ -1,24 +1,23 @@
-/* A Bison parser, made by GNU Bison 2.3.  */
+
+/* A Bison parser, made by GNU Bison 2.4.1.  */
 
 /* Skeleton interface for Bison's Yacc-like parsers in C
-
-   Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
+   
+      Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
    Free Software Foundation, Inc.
-
-   This program is free software; you can redistribute it and/or modify
+   
+   This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2, or (at your option)
-   any later version.
-
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+   
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
-
+   
    You should have received a copy of the GNU General Public License
-   along with this program; if not, write to the Free Software
-   Foundation, Inc., 51 Franklin Street, Fifth Floor,
-   Boston, MA 02110-1301, USA.  */
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 /* As a special exception, you may create a larger work that contains
    part or all of the Bison parser skeleton and distribute that work
@@ -29,10 +28,11 @@
    special exception, which will cause the skeleton and the resulting
    Bison output files to be licensed under the GNU General Public
    License without this special exception.
-
+   
    This special exception was added by the Free Software Foundation in
    version 2.2 of Bison.  */
 
+
 /* Tokens.  */
 #ifndef YYTOKENTYPE
 # define YYTOKENTYPE
@@ -45,28 +45,27 @@
      NEWLINE = 261
    };
 #endif
-/* Tokens.  */
-#define IDENT 258
-#define STRING 259
-#define NUMBER 260
-#define NEWLINE 261
-
 
 
 
 #if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
 typedef union YYSTYPE
+{
+
+/* Line 1676 of yacc.c  */
 #line 25 "libxlu_cfg_y.y"
-{
+
   char *string;
   XLU_ConfigSetting *setting;
-}
-/* Line 1489 of yacc.c.  */
-#line 66 "libxlu_cfg_y.h"
-	YYSTYPE;
+
+
+
+/* Line 1676 of yacc.c  */
+#line 65 "libxlu_cfg_y.h"
+} YYSTYPE;
+# define YYSTYPE_IS_TRIVIAL 1
 # define yystype YYSTYPE /* obsolescent; will be withdrawn */
 # define YYSTYPE_IS_DECLARED 1
-# define YYSTYPE_IS_TRIVIAL 1
 #endif
 
 
@@ -86,10 +85,3 @@ typedef struct YYLTYPE
 
 
 
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_disk_l.c
--- a/tools/libxl/libxlu_disk_l.c	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_disk_l.c	Wed Apr 25 11:53:23 2012 +0100
@@ -2517,11 +2517,3 @@ void xlu__disk_yyfree (void * ptr , yysc
 #define YYTABLES_NAME "yytables"
 
 #line 227 "libxlu_disk_l.l"
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_disk_l.h
--- a/tools/libxl/libxlu_disk_l.h	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_disk_l.h	Wed Apr 25 11:53:23 2012 +0100
@@ -345,11 +345,3 @@ extern int xlu__disk_yylex (yyscan_t yys
 #line 346 "libxlu_disk_l.h"
 #undef xlu__disk_yyIN_HEADER
 #endif /* xlu__disk_yyHEADER_H */
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 10:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 10:59:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SMzw6-0005b4-RY; Wed, 25 Apr 2012 10:59:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SMzw5-0005at-2o
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 10:59:01 +0000
Received: from [85.158.138.51:3482] by server-9.bemta-3.messagelabs.com id
	C3/37-26691-4F8D79F4; Wed, 25 Apr 2012 10:59:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335351539!23670604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12130 invoked from network); 25 Apr 2012 10:58:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 10:58:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:58:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 11:58:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SMzvm-0005Go-Sm	for xen-devel@lists.xensource.com;
	Wed, 25 Apr 2012 10:58:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SMzvm-0000lK-Qm	for
	xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:58:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.55522.813358.134995@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 11:58:42 +0100
To: xen-devel@lists.xensource.com
In-Reply-To: <20375.55494.925787.524611@mariner.uk.xensource.com>
References: <20375.55494.925787.524611@mariner.uk.xensource.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH 2/2] libxl: regenerate flex/bison output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

No intentional functional change.  The following hopefully
non-functional changes:
 * Regenerate parsers with Bison 2.4.1 (Debian's 1:2.4.1.dfsg-3 i386)
 * Whitespace fixes previously done to the whole of libxl are
   undone as far as they effect these files;
 * Remove semiautomatically-added "Local variables" stanzas from
   autogenerated files.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_l.c
--- a/tools/libxl/libxlu_cfg_l.c	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_l.c	Wed Apr 25 11:53:23 2012 +0100
@@ -34,7 +34,7 @@
 #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
 
 /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h,
- * if you want the limit (max/min) macros for int types.
+ * if you want the limit (max/min) macros for int types. 
  */
 #ifndef __STDC_LIMIT_MACROS
 #define __STDC_LIMIT_MACROS 1
@@ -51,7 +51,7 @@ typedef uint32_t flex_uint32_t;
 typedef signed char flex_int8_t;
 typedef short int flex_int16_t;
 typedef int flex_int32_t;
-typedef unsigned char flex_uint8_t;
+typedef unsigned char flex_uint8_t; 
 typedef unsigned short int flex_uint16_t;
 typedef unsigned int flex_uint32_t;
 
@@ -185,7 +185,7 @@ typedef struct yy_buffer_state *YY_BUFFE
 
     /* Note: We specifically omit the test for yy_rule_can_match_eol because it requires
      *       access to the local variable yy_act. Since yyless() is a macro, it would break
-     *       existing scanners that call yyless() from OUTSIDE xlu__cfg_yylex.
+     *       existing scanners that call yyless() from OUTSIDE xlu__cfg_yylex. 
      *       One obvious solution it to make yy_act a global. I tried that, and saw
      *       a 5% performance hit in a non-yylineno scanner, because yy_act is
      *       normally declared as a register variable-- so it is not worth it.
@@ -197,7 +197,7 @@ typedef struct yy_buffer_state *YY_BUFFE
                     if ( yytext[yyl] == '\n' )\
                         --yylineno;\
             }while(0)
-
+    
 /* Return all but the first "n" matched characters back to the input stream. */
 #define yyless(n) \
 	do \
@@ -259,7 +259,7 @@ struct yy_buffer_state
 
     int yy_bs_lineno; /**< The line count. */
     int yy_bs_column; /**< The column count. */
-
+    
 	/* Whether to try to fill the input buffer when we reach the
 	 * end of it.
 	 */
@@ -574,9 +574,9 @@ static int yy_init_globals (yyscan_t yys
     /* This must go here because YYSTYPE and YYLTYPE are included
      * from bison output in section 1.*/
     #    define yylval yyg->yylval_r
-
+    
     #    define yylloc yyg->yylloc_r
-
+    
 int xlu__cfg_yylex_init (yyscan_t* scanner);
 
 int xlu__cfg_yylex_init_extra (YY_EXTRA_TYPE user_defined,yyscan_t* scanner);
@@ -615,9 +615,9 @@ YYSTYPE * xlu__cfg_yyget_lval (yyscan_t 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
 
        YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner );
-
+    
         void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner );
-
+    
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -845,7 +845,7 @@ yy_find_action:
 			int yyl;
 			for ( yyl = yyg->yy_more_len; yyl < yyleng; ++yyl )
 				if ( yytext[yyl] == '\n' )
-
+					   
     do{ yylineno++;
         yycolumn=0;
     }while(0)
@@ -1377,7 +1377,7 @@ static int yy_get_next_buffer (yyscan_t 
 	yyg->yy_hold_char = *++yyg->yy_c_buf_p;
 
 	if ( c == '\n' )
-
+		   
     do{ yylineno++;
         yycolumn=0;
     }while(0)
@@ -1460,7 +1460,7 @@ static void xlu__cfg_yy_load_buffer_stat
     YY_BUFFER_STATE xlu__cfg_yy_create_buffer  (FILE * file, int  size , yyscan_t yyscanner)
 {
 	YY_BUFFER_STATE b;
-
+    
 	b = (YY_BUFFER_STATE) xlu__cfg_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner );
 	if ( ! b )
 		YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yy_create_buffer()" );
@@ -1504,7 +1504,7 @@ static void xlu__cfg_yy_load_buffer_stat
 #ifndef __cplusplus
 extern int isatty (int );
 #endif /* __cplusplus */
-
+    
 /* Initializes or reinitializes a buffer.
  * This function is sometimes called more than once on the same buffer,
  * such as during a xlu__cfg_yyrestart() or at EOF.
@@ -1530,7 +1530,7 @@ extern int isatty (int );
     }
 
         b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
-
+    
 	errno = oerrno;
 }
 
@@ -1636,9 +1636,9 @@ static void xlu__cfg_yyensure_buffer_sta
 								, yyscanner);
 		if ( ! yyg->yy_buffer_stack )
 			YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yyensure_buffer_stack()" );
-
+								  
 		memset(yyg->yy_buffer_stack, 0, num_to_alloc * sizeof(struct yy_buffer_state*));
-
+				
 		yyg->yy_buffer_stack_max = num_to_alloc;
 		yyg->yy_buffer_stack_top = 0;
 		return;
@@ -1667,12 +1667,12 @@ static void xlu__cfg_yyensure_buffer_sta
  * @param base the character buffer
  * @param size the size in bytes of the character buffer
  * @param yyscanner The scanner object.
- * @return the newly allocated buffer state object.
+ * @return the newly allocated buffer state object. 
  */
 YY_BUFFER_STATE xlu__cfg_yy_scan_buffer  (char * base, yy_size_t  size , yyscan_t yyscanner)
 {
 	YY_BUFFER_STATE b;
-
+    
 	if ( size < 2 ||
 	     base[size-2] != YY_END_OF_BUFFER_CHAR ||
 	     base[size-1] != YY_END_OF_BUFFER_CHAR )
@@ -1708,7 +1708,7 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_buffer 
  */
 YY_BUFFER_STATE xlu__cfg_yy_scan_string (yyconst char * yystr , yyscan_t yyscanner)
 {
-
+    
 	return xlu__cfg_yy_scan_bytes(yystr,strlen(yystr) ,yyscanner);
 }
 
@@ -1725,7 +1725,7 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_bytes  
 	char *buf;
 	yy_size_t n;
 	int i;
-
+    
 	/* Get memory for full buffer, including space for trailing EOB's. */
 	n = _yybytes_len + 2;
 	buf = (char *) xlu__cfg_yyalloc(n ,yyscanner );
@@ -1793,10 +1793,10 @@ YY_EXTRA_TYPE xlu__cfg_yyget_extra  (yys
 int xlu__cfg_yyget_lineno  (yyscan_t yyscanner)
 {
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
-
+    
         if (! YY_CURRENT_BUFFER)
             return 0;
-
+    
     return yylineno;
 }
 
@@ -1806,10 +1806,10 @@ int xlu__cfg_yyget_lineno  (yyscan_t yys
 int xlu__cfg_yyget_column  (yyscan_t yyscanner)
 {
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
-
+    
         if (! YY_CURRENT_BUFFER)
             return 0;
-
+    
     return yycolumn;
 }
 
@@ -1870,8 +1870,8 @@ void xlu__cfg_yyset_lineno (int  line_nu
 
         /* lineno is only valid if an input buffer exists. */
         if (! YY_CURRENT_BUFFER )
-           yy_fatal_error( "xlu__cfg_yyset_lineno called with no buffer" , yyscanner);
-
+           yy_fatal_error( "xlu__cfg_yyset_lineno called with no buffer" , yyscanner); 
+    
     yylineno = line_number;
 }
 
@@ -1885,8 +1885,8 @@ void xlu__cfg_yyset_column (int  column_
 
         /* column is only valid if an input buffer exists. */
         if (! YY_CURRENT_BUFFER )
-           yy_fatal_error( "xlu__cfg_yyset_column called with no buffer" , yyscanner);
-
+           yy_fatal_error( "xlu__cfg_yyset_column called with no buffer" , yyscanner); 
+    
     yycolumn = column_no;
 }
 
@@ -1939,13 +1939,13 @@ YYLTYPE *xlu__cfg_yyget_lloc  (yyscan_t 
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
     return yylloc;
 }
-
+    
 void xlu__cfg_yyset_lloc (YYLTYPE *  yylloc_param , yyscan_t yyscanner)
 {
     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
     yylloc = yylloc_param;
 }
-
+    
 /* User-visible API */
 
 /* xlu__cfg_yylex_init is special because it creates the scanner itself, so it is
@@ -1993,20 +1993,20 @@ int xlu__cfg_yylex_init_extra(YY_EXTRA_T
         errno = EINVAL;
         return 1;
     }
-
+	
     *ptr_yy_globals = (yyscan_t) xlu__cfg_yyalloc ( sizeof( struct yyguts_t ), &dummy_yyguts );
-
+	
     if (*ptr_yy_globals == NULL){
         errno = ENOMEM;
         return 1;
     }
-
+    
     /* By setting to 0xAA, we expose bugs in
     yy_init_globals. Leave at 0x00 for releases. */
     memset(*ptr_yy_globals,0x00,sizeof(struct yyguts_t));
-
+    
     xlu__cfg_yyset_extra (yy_user_defined, *ptr_yy_globals);
-
+    
     return yy_init_globals ( *ptr_yy_globals );
 }
 
@@ -2122,11 +2122,3 @@ void xlu__cfg_yyfree (void * ptr , yysca
 #define YYTABLES_NAME "yytables"
 
 #line 104 "libxlu_cfg_l.l"
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_l.h
--- a/tools/libxl/libxlu_cfg_l.h	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_l.h	Wed Apr 25 11:53:23 2012 +0100
@@ -38,7 +38,7 @@
 #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
 
 /* C99 says to define __STDC_LIMIT_MACROS before including stdint.h,
- * if you want the limit (max/min) macros for int types.
+ * if you want the limit (max/min) macros for int types. 
  */
 #ifndef __STDC_LIMIT_MACROS
 #define __STDC_LIMIT_MACROS 1
@@ -55,7 +55,7 @@ typedef uint32_t flex_uint32_t;
 typedef signed char flex_int8_t;
 typedef short int flex_int16_t;
 typedef int flex_int32_t;
-typedef unsigned char flex_uint8_t;
+typedef unsigned char flex_uint8_t; 
 typedef unsigned short int flex_uint16_t;
 typedef unsigned int flex_uint32_t;
 
@@ -193,7 +193,7 @@ struct yy_buffer_state
 
     int yy_bs_lineno; /**< The line count. */
     int yy_bs_column; /**< The column count. */
-
+    
 	/* Whether to try to fill the input buffer when we reach the
 	 * end of it.
 	 */
@@ -281,9 +281,9 @@ YYSTYPE * xlu__cfg_yyget_lval (yyscan_t 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
 
        YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner );
-
+    
         void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner );
-
+    
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -355,11 +355,3 @@ extern int xlu__cfg_yylex \
 #line 356 "libxlu_cfg_l.h"
 #undef xlu__cfg_yyIN_HEADER
 #endif /* xlu__cfg_yyHEADER_H */
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_y.c
--- a/tools/libxl/libxlu_cfg_y.c	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_y.c	Wed Apr 25 11:53:23 2012 +0100
@@ -1,24 +1,23 @@
-/* A Bison parser, made by GNU Bison 2.3.  */
+
+/* A Bison parser, made by GNU Bison 2.4.1.  */
 
 /* Skeleton implementation for Bison's Yacc-like parsers in C
-
-   Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
+   
+      Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
    Free Software Foundation, Inc.
-
-   This program is free software; you can redistribute it and/or modify
+   
+   This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2, or (at your option)
-   any later version.
-
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+   
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
-
+   
    You should have received a copy of the GNU General Public License
-   along with this program; if not, write to the Free Software
-   Foundation, Inc., 51 Franklin Street, Fifth Floor,
-   Boston, MA 02110-1301, USA.  */
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 /* As a special exception, you may create a larger work that contains
    part or all of the Bison parser skeleton and distribute that work
@@ -29,7 +28,7 @@
    special exception, which will cause the skeleton and the resulting
    Bison output files to be licensed under the GNU General Public
    License without this special exception.
-
+   
    This special exception was added by the Free Software Foundation in
    version 2.2 of Bison.  */
 
@@ -47,7 +46,7 @@
 #define YYBISON 1
 
 /* Bison version.  */
-#define YYBISON_VERSION "2.3"
+#define YYBISON_VERSION "2.4.1"
 
 /* Skeleton name.  */
 #define YYSKELETON_NAME "yacc.c"
@@ -55,41 +54,28 @@
 /* Pure parsers.  */
 #define YYPURE 1
 
+/* Push parsers.  */
+#define YYPUSH 0
+
+/* Pull parsers.  */
+#define YYPULL 1
+
 /* Using locations.  */
 #define YYLSP_NEEDED 1
 
 /* Substitute the variable and function names.  */
-#define yyparse xlu__cfg_yyparse
-#define yylex   xlu__cfg_yylex
-#define yyerror xlu__cfg_yyerror
-#define yylval  xlu__cfg_yylval
-#define yychar  xlu__cfg_yychar
-#define yydebug xlu__cfg_yydebug
-#define yynerrs xlu__cfg_yynerrs
-#define yylloc xlu__cfg_yylloc
-
-/* Tokens.  */
-#ifndef YYTOKENTYPE
-# define YYTOKENTYPE
-   /* Put the tokens into the symbol table, so that GDB and other debuggers
-      know about them.  */
-   enum yytokentype {
-     IDENT = 258,
-     STRING = 259,
-     NUMBER = 260,
-     NEWLINE = 261
-   };
-#endif
-/* Tokens.  */
-#define IDENT 258
-#define STRING 259
-#define NUMBER 260
-#define NEWLINE 261
-
-
-
+#define yyparse         xlu__cfg_yyparse
+#define yylex           xlu__cfg_yylex
+#define yyerror         xlu__cfg_yyerror
+#define yylval          xlu__cfg_yylval
+#define yychar          xlu__cfg_yychar
+#define yydebug         xlu__cfg_yydebug
+#define yynerrs         xlu__cfg_yynerrs
+#define yylloc          xlu__cfg_yylloc
 
 /* Copy the first part of user declarations.  */
+
+/* Line 189 of yacc.c  */
 #line 19 "libxlu_cfg_y.y"
 
 #define YYLEX_PARAM ctx->scanner
@@ -97,6 +83,9 @@
 #include "libxlu_cfg_l.h"
 
 
+/* Line 189 of yacc.c  */
+#line 88 "libxlu_cfg_y.c"
+
 /* Enabling traces.  */
 #ifndef YYDEBUG
 # define YYDEBUG 0
@@ -115,19 +104,40 @@
 # define YYTOKEN_TABLE 0
 #endif
 
+
+/* Tokens.  */
+#ifndef YYTOKENTYPE
+# define YYTOKENTYPE
+   /* Put the tokens into the symbol table, so that GDB and other debuggers
+      know about them.  */
+   enum yytokentype {
+     IDENT = 258,
+     STRING = 259,
+     NUMBER = 260,
+     NEWLINE = 261
+   };
+#endif
+
+
+
 #if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
 typedef union YYSTYPE
+{
+
+/* Line 214 of yacc.c  */
 #line 25 "libxlu_cfg_y.y"
-{
+
   char *string;
   XLU_ConfigSetting *setting;
-}
-/* Line 187 of yacc.c.  */
-#line 127 "libxlu_cfg_y.c"
-	YYSTYPE;
+
+
+
+/* Line 214 of yacc.c  */
+#line 137 "libxlu_cfg_y.c"
+} YYSTYPE;
+# define YYSTYPE_IS_TRIVIAL 1
 # define yystype YYSTYPE /* obsolescent; will be withdrawn */
 # define YYSTYPE_IS_DECLARED 1
-# define YYSTYPE_IS_TRIVIAL 1
 #endif
 
 #if ! defined YYLTYPE && ! defined YYLTYPE_IS_DECLARED
@@ -147,8 +157,8 @@ typedef struct YYLTYPE
 /* Copy the second part of user declarations.  */
 
 
-/* Line 216 of yacc.c.  */
-#line 152 "libxlu_cfg_y.c"
+/* Line 264 of yacc.c  */
+#line 162 "libxlu_cfg_y.c"
 
 #ifdef short
 # undef short
@@ -223,14 +233,14 @@ typedef short int yytype_int16;
 #if (defined __STDC__ || defined __C99__FUNC__ \
      || defined __cplusplus || defined _MSC_VER)
 static int
-YYID (int i)
+YYID (int yyi)
 #else
 static int
-YYID (i)
-    int i;
+YYID (yyi)
+    int yyi;
 #endif
 {
-  return i;
+  return yyi;
 }
 #endif
 
@@ -312,9 +322,9 @@ void free (void *); /* INFRINGES ON USER
 /* A type that is properly aligned for any stack member.  */
 union yyalloc
 {
-  yytype_int16 yyss;
-  YYSTYPE yyvs;
-    YYLTYPE yyls;
+  yytype_int16 yyss_alloc;
+  YYSTYPE yyvs_alloc;
+  YYLTYPE yyls_alloc;
 };
 
 /* The size of the maximum gap between one aligned stack and the next.  */
@@ -349,12 +359,12 @@ union yyalloc
    elements in the stack, and YYPTR gives the new location of the
    stack.  Advance YYPTR to a properly aligned location for the next
    stack.  */
-# define YYSTACK_RELOCATE(Stack)					\
+# define YYSTACK_RELOCATE(Stack_alloc, Stack)				\
     do									\
       {									\
 	YYSIZE_T yynewbytes;						\
-	YYCOPY (&yyptr->Stack, Stack, yysize);				\
-	Stack = &yyptr->Stack;						\
+	YYCOPY (&yyptr->Stack_alloc, Stack, yysize);			\
+	Stack = &yyptr->Stack_alloc;					\
 	yynewbytes = yystacksize * sizeof (*Stack) + YYSTACK_GAP_MAXIMUM; \
 	yyptr += yynewbytes / sizeof (*yyptr);				\
       }									\
@@ -451,7 +461,7 @@ static const yytype_uint8 yyrline[] =
 static const char *const yytname[] =
 {
   "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
-  "'='", "';'", "'['", "']'", "','", "$accept", "file", "setting", "@1",
+  "'='", "';'", "'['", "']'", "','", "$accept", "file", "setting", "$@1",
   "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
 };
 #endif
@@ -732,17 +742,20 @@ yy_symbol_print (yyoutput, yytype, yyval
 #if (defined __STDC__ || defined __C99__FUNC__ \
      || defined __cplusplus || defined _MSC_VER)
 static void
-yy_stack_print (yytype_int16 *bottom, yytype_int16 *top)
+yy_stack_print (yytype_int16 *yybottom, yytype_int16 *yytop)
 #else
 static void
-yy_stack_print (bottom, top)
-    yytype_int16 *bottom;
-    yytype_int16 *top;
+yy_stack_print (yybottom, yytop)
+    yytype_int16 *yybottom;
+    yytype_int16 *yytop;
 #endif
 {
   YYFPRINTF (stderr, "Stack now");
-  for (; bottom <= top; ++bottom)
-    YYFPRINTF (stderr, " %d", *bottom);
+  for (; yybottom <= yytop; yybottom++)
+    {
+      int yybot = *yybottom;
+      YYFPRINTF (stderr, " %d", yybot);
+    }
   YYFPRINTF (stderr, "\n");
 }
 
@@ -778,11 +791,11 @@ yy_reduce_print (yyvsp, yylsp, yyrule, c
   /* The symbols being reduced.  */
   for (yyi = 0; yyi < yynrhs; yyi++)
     {
-      fprintf (stderr, "   $%d = ", yyi + 1);
+      YYFPRINTF (stderr, "   $%d = ", yyi + 1);
       yy_symbol_print (stderr, yyrhs[yyprhs[yyrule] + yyi],
 		       &(yyvsp[(yyi + 1) - (yynrhs)])
 		       , &(yylsp[(yyi + 1) - (yynrhs)])		       , ctx);
-      fprintf (stderr, "\n");
+      YYFPRINTF (stderr, "\n");
     }
 }
 
@@ -819,7 +832,7 @@ int yydebug;
 # define YYMAXDEPTH 10000
 #endif
 
-
+
 
 #if YYERROR_VERBOSE
 
@@ -1030,7 +1043,7 @@ yysyntax_error (char *yyresult, int yyst
     }
 }
 #endif /* YYERROR_VERBOSE */
-
+
 
 /*-----------------------------------------------.
 | Release the memory associated to this symbol.  |
@@ -1062,39 +1075,67 @@ yydestruct (yymsg, yytype, yyvaluep, yyl
   switch (yytype)
     {
       case 3: /* "IDENT" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1068 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1085 "libxlu_cfg_y.c"
 	break;
       case 4: /* "STRING" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1073 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1094 "libxlu_cfg_y.c"
 	break;
       case 5: /* "NUMBER" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1078 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1103 "libxlu_cfg_y.c"
 	break;
       case 17: /* "value" */
+
+/* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
-#line 1083 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1112 "libxlu_cfg_y.c"
 	break;
       case 18: /* "atom" */
+
+/* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
-#line 1088 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1121 "libxlu_cfg_y.c"
 	break;
       case 19: /* "valuelist" */
+
+/* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
-#line 1093 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1130 "libxlu_cfg_y.c"
 	break;
       case 20: /* "values" */
+
+/* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
-#line 1098 "libxlu_cfg_y.c"
+
+/* Line 1000 of yacc.c  */
+#line 1139 "libxlu_cfg_y.c"
 	break;
 
       default:
@@ -1102,9 +1143,7 @@ yydestruct (yymsg, yytype, yyvaluep, yyl
     }
 }
 
-
 /* Prevent warnings from -Wmissing-prototypes.  */
-
 #ifdef YYPARSE_PARAM
 #if defined __STDC__ || defined __cplusplus
 int yyparse (void *YYPARSE_PARAM);
@@ -1123,10 +1162,9 @@ int yyparse ();
 
 
 
-
-/*----------.
-| yyparse.  |
-`----------*/
+/*-------------------------.
+| yyparse or yypush_parse.  |
+`-------------------------*/
 
 #ifdef YYPARSE_PARAM
 #if (defined __STDC__ || defined __C99__FUNC__ \
@@ -1150,24 +1188,59 @@ yyparse (ctx)
 #endif
 #endif
 {
-  /* The look-ahead symbol.  */
+/* The lookahead symbol.  */
 int yychar;
 
-/* The semantic value of the look-ahead symbol.  */
+/* The semantic value of the lookahead symbol.  */
 YYSTYPE yylval;
 
-/* Number of syntax errors so far.  */
-int yynerrs;
-/* Location data for the look-ahead symbol.  */
+/* Location data for the lookahead symbol.  */
 YYLTYPE yylloc;
 
-  int yystate;
+    /* Number of syntax errors so far.  */
+    int yynerrs;
+
+    int yystate;
+    /* Number of tokens to shift before error messages enabled.  */
+    int yyerrstatus;
+
+    /* The stacks and their tools:
+       `yyss': related to states.
+       `yyvs': related to semantic values.
+       `yyls': related to locations.
+
+       Refer to the stacks thru separate pointers, to allow yyoverflow
+       to reallocate them elsewhere.  */
+
+    /* The state stack.  */
+    yytype_int16 yyssa[YYINITDEPTH];
+    yytype_int16 *yyss;
+    yytype_int16 *yyssp;
+
+    /* The semantic value stack.  */
+    YYSTYPE yyvsa[YYINITDEPTH];
+    YYSTYPE *yyvs;
+    YYSTYPE *yyvsp;
+
+    /* The location stack.  */
+    YYLTYPE yylsa[YYINITDEPTH];
+    YYLTYPE *yyls;
+    YYLTYPE *yylsp;
+
+    /* The locations where the error started and ended.  */
+    YYLTYPE yyerror_range[2];
+
+    YYSIZE_T yystacksize;
+
   int yyn;
   int yyresult;
-  /* Number of tokens to shift before error messages enabled.  */
-  int yyerrstatus;
-  /* Look-ahead token as an internal (translated) token number.  */
-  int yytoken = 0;
+  /* Lookahead token as an internal (translated) token number.  */
+  int yytoken;
+  /* The variables used to return semantic value and location from the
+     action routines.  */
+  YYSTYPE yyval;
+  YYLTYPE yyloc;
+
 #if YYERROR_VERBOSE
   /* Buffer for error messages, and its allocated size.  */
   char yymsgbuf[128];
@@ -1175,63 +1248,37 @@ YYLTYPE yylloc;
   YYSIZE_T yymsg_alloc = sizeof yymsgbuf;
 #endif
 
-  /* Three stacks and their tools:
-     `yyss': related to states,
-     `yyvs': related to semantic values,
-     `yyls': related to locations.
-
-     Refer to the stacks thru separate pointers, to allow yyoverflow
-     to reallocate them elsewhere.  */
-
-  /* The state stack.  */
-  yytype_int16 yyssa[YYINITDEPTH];
-  yytype_int16 *yyss = yyssa;
-  yytype_int16 *yyssp;
-
-  /* The semantic value stack.  */
-  YYSTYPE yyvsa[YYINITDEPTH];
-  YYSTYPE *yyvs = yyvsa;
-  YYSTYPE *yyvsp;
-
-  /* The location stack.  */
-  YYLTYPE yylsa[YYINITDEPTH];
-  YYLTYPE *yyls = yylsa;
-  YYLTYPE *yylsp;
-  /* The locations where the error started and ended.  */
-  YYLTYPE yyerror_range[2];
-
 #define YYPOPSTACK(N)   (yyvsp -= (N), yyssp -= (N), yylsp -= (N))
 
-  YYSIZE_T yystacksize = YYINITDEPTH;
-
-  /* The variables used to return semantic value and location from the
-     action routines.  */
-  YYSTYPE yyval;
-  YYLTYPE yyloc;
-
   /* The number of symbols on the RHS of the reduced rule.
      Keep to zero when no symbol should be popped.  */
   int yylen = 0;
 
+  yytoken = 0;
+  yyss = yyssa;
+  yyvs = yyvsa;
+  yyls = yylsa;
+  yystacksize = YYINITDEPTH;
+
   YYDPRINTF ((stderr, "Starting parse\n"));
 
   yystate = 0;
   yyerrstatus = 0;
   yynerrs = 0;
-  yychar = YYEMPTY;		/* Cause a token to be read.  */
+  yychar = YYEMPTY; /* Cause a token to be read.  */
 
   /* Initialize stack pointers.
      Waste one element of value and location stack
      so that they stay on the same level as the state stack.
      The wasted elements are never initialized.  */
-
   yyssp = yyss;
   yyvsp = yyvs;
   yylsp = yyls;
+
 #if YYLTYPE_IS_TRIVIAL
   /* Initialize the default location before parsing starts.  */
   yylloc.first_line   = yylloc.last_line   = 1;
-  yylloc.first_column = yylloc.last_column = 0;
+  yylloc.first_column = yylloc.last_column = 1;
 #endif
 
   goto yysetstate;
@@ -1270,6 +1317,7 @@ YYLTYPE yylloc;
 		    &yyvs1, yysize * sizeof (*yyvsp),
 		    &yyls1, yysize * sizeof (*yylsp),
 		    &yystacksize);
+
 	yyls = yyls1;
 	yyss = yyss1;
 	yyvs = yyvs1;
@@ -1291,9 +1339,9 @@ YYLTYPE yylloc;
 	  (union yyalloc *) YYSTACK_ALLOC (YYSTACK_BYTES (yystacksize));
 	if (! yyptr)
 	  goto yyexhaustedlab;
-	YYSTACK_RELOCATE (yyss);
-	YYSTACK_RELOCATE (yyvs);
-	YYSTACK_RELOCATE (yyls);
+	YYSTACK_RELOCATE (yyss_alloc, yyss);
+	YYSTACK_RELOCATE (yyvs_alloc, yyvs);
+	YYSTACK_RELOCATE (yyls_alloc, yyls);
 #  undef YYSTACK_RELOCATE
 	if (yyss1 != yyssa)
 	  YYSTACK_FREE (yyss1);
@@ -1314,6 +1362,9 @@ YYLTYPE yylloc;
 
   YYDPRINTF ((stderr, "Entering state %d\n", yystate));
 
+  if (yystate == YYFINAL)
+    YYACCEPT;
+
   goto yybackup;
 
 /*-----------.
@@ -1322,16 +1373,16 @@ YYLTYPE yylloc;
 yybackup:
 
   /* Do appropriate processing given the current state.  Read a
-     look-ahead token if we need one and don't already have one.  */
+     lookahead token if we need one and don't already have one.  */
 
-  /* First try to decide what to do without reference to look-ahead token.  */
+  /* First try to decide what to do without reference to lookahead token.  */
   yyn = yypact[yystate];
   if (yyn == YYPACT_NINF)
     goto yydefault;
 
-  /* Not known => get a look-ahead token if don't already have one.  */
+  /* Not known => get a lookahead token if don't already have one.  */
 
-  /* YYCHAR is either YYEMPTY or YYEOF or a valid look-ahead symbol.  */
+  /* YYCHAR is either YYEMPTY or YYEOF or a valid lookahead symbol.  */
   if (yychar == YYEMPTY)
     {
       YYDPRINTF ((stderr, "Reading a token: "));
@@ -1363,20 +1414,16 @@ yybackup:
       goto yyreduce;
     }
 
-  if (yyn == YYFINAL)
-    YYACCEPT;
-
   /* Count tokens shifted since error; after three, turn off error
      status.  */
   if (yyerrstatus)
     yyerrstatus--;
 
-  /* Shift the look-ahead token.  */
+  /* Shift the lookahead token.  */
   YY_SYMBOL_PRINT ("Shifting", yytoken, &yylval, &yylloc);
 
-  /* Discard the shifted token unless it is eof.  */
-  if (yychar != YYEOF)
-    yychar = YYEMPTY;
+  /* Discard the shifted token.  */
+  yychar = YYEMPTY;
 
   yystate = yyn;
   *++yyvsp = yylval;
@@ -1417,58 +1464,79 @@ yyreduce:
   switch (yyn)
     {
         case 4:
+
+/* Line 1455 of yacc.c  */
 #line 50 "libxlu_cfg_y.y"
     { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); ;}
     break;
 
   case 10:
+
+/* Line 1455 of yacc.c  */
 #line 58 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); ;}
     break;
 
   case 11:
+
+/* Line 1455 of yacc.c  */
 #line 59 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(3) - (4)].setting); ;}
     break;
 
   case 12:
+
+/* Line 1455 of yacc.c  */
 #line 61 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
   case 13:
+
+/* Line 1455 of yacc.c  */
 #line 62 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
   case 14:
+
+/* Line 1455 of yacc.c  */
 #line 64 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); ;}
     break;
 
   case 15:
+
+/* Line 1455 of yacc.c  */
 #line 65 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (1)].setting); ;}
     break;
 
   case 16:
+
+/* Line 1455 of yacc.c  */
 #line 66 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (3)].setting); ;}
     break;
 
   case 17:
+
+/* Line 1455 of yacc.c  */
 #line 68 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); ;}
     break;
 
   case 18:
+
+/* Line 1455 of yacc.c  */
 #line 69 "libxlu_cfg_y.y"
     { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); ;}
     break;
 
 
-/* Line 1267 of yacc.c.  */
-#line 1472 "libxlu_cfg_y.c"
+
+/* Line 1455 of yacc.c  */
+#line 1540 "libxlu_cfg_y.c"
       default: break;
     }
   YY_SYMBOL_PRINT ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
@@ -1544,7 +1612,7 @@ yyerrlab:
 
   if (yyerrstatus == 3)
     {
-      /* If just tried and failed to reuse look-ahead token after an
+      /* If just tried and failed to reuse lookahead token after an
 	 error, discard it.  */
 
       if (yychar <= YYEOF)
@@ -1561,7 +1629,7 @@ yyerrlab:
 	}
     }
 
-  /* Else will try to reuse look-ahead token after shifting the error
+  /* Else will try to reuse lookahead token after shifting the error
      token.  */
   goto yyerrlab1;
 
@@ -1619,14 +1687,11 @@ yyerrlab1:
       YY_STACK_PRINT (yyss, yyssp);
     }
 
-  if (yyn == YYFINAL)
-    YYACCEPT;
-
   *++yyvsp = yylval;
 
   yyerror_range[1] = yylloc;
   /* Using YYLLOC is tempting, but would change the location of
-     the look-ahead.  YYLOC is available though.  */
+     the lookahead.  YYLOC is available though.  */
   YYLLOC_DEFAULT (yyloc, (yyerror_range - 1), 2);
   *++yylsp = yyloc;
 
@@ -1651,7 +1716,7 @@ yyabortlab:
   yyresult = 1;
   goto yyreturn;
 
-#ifndef yyoverflow
+#if !defined(yyoverflow) || YYERROR_VERBOSE
 /*-------------------------------------------------.
 | yyexhaustedlab -- memory exhaustion comes here.  |
 `-------------------------------------------------*/
@@ -1662,7 +1727,7 @@ yyexhaustedlab:
 #endif
 
 yyreturn:
-  if (yychar != YYEOF && yychar != YYEMPTY)
+  if (yychar != YYEMPTY)
      yydestruct ("Cleanup: discarding lookahead",
 		 yytoken, &yylval, &yylloc, ctx);
   /* Do not reclaim the symbols of the rule which action triggered
@@ -1689,11 +1754,3 @@ yyreturn:
 
 
 
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_cfg_y.h
--- a/tools/libxl/libxlu_cfg_y.h	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_cfg_y.h	Wed Apr 25 11:53:23 2012 +0100
@@ -1,24 +1,23 @@
-/* A Bison parser, made by GNU Bison 2.3.  */
+
+/* A Bison parser, made by GNU Bison 2.4.1.  */
 
 /* Skeleton interface for Bison's Yacc-like parsers in C
-
-   Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
+   
+      Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
    Free Software Foundation, Inc.
-
-   This program is free software; you can redistribute it and/or modify
+   
+   This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2, or (at your option)
-   any later version.
-
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+   
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
-
+   
    You should have received a copy of the GNU General Public License
-   along with this program; if not, write to the Free Software
-   Foundation, Inc., 51 Franklin Street, Fifth Floor,
-   Boston, MA 02110-1301, USA.  */
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 /* As a special exception, you may create a larger work that contains
    part or all of the Bison parser skeleton and distribute that work
@@ -29,10 +28,11 @@
    special exception, which will cause the skeleton and the resulting
    Bison output files to be licensed under the GNU General Public
    License without this special exception.
-
+   
    This special exception was added by the Free Software Foundation in
    version 2.2 of Bison.  */
 
+
 /* Tokens.  */
 #ifndef YYTOKENTYPE
 # define YYTOKENTYPE
@@ -45,28 +45,27 @@
      NEWLINE = 261
    };
 #endif
-/* Tokens.  */
-#define IDENT 258
-#define STRING 259
-#define NUMBER 260
-#define NEWLINE 261
-
 
 
 
 #if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
 typedef union YYSTYPE
+{
+
+/* Line 1676 of yacc.c  */
 #line 25 "libxlu_cfg_y.y"
-{
+
   char *string;
   XLU_ConfigSetting *setting;
-}
-/* Line 1489 of yacc.c.  */
-#line 66 "libxlu_cfg_y.h"
-	YYSTYPE;
+
+
+
+/* Line 1676 of yacc.c  */
+#line 65 "libxlu_cfg_y.h"
+} YYSTYPE;
+# define YYSTYPE_IS_TRIVIAL 1
 # define yystype YYSTYPE /* obsolescent; will be withdrawn */
 # define YYSTYPE_IS_DECLARED 1
-# define YYSTYPE_IS_TRIVIAL 1
 #endif
 
 
@@ -86,10 +85,3 @@ typedef struct YYLTYPE
 
 
 
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_disk_l.c
--- a/tools/libxl/libxlu_disk_l.c	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_disk_l.c	Wed Apr 25 11:53:23 2012 +0100
@@ -2517,11 +2517,3 @@ void xlu__disk_yyfree (void * ptr , yysc
 #define YYTABLES_NAME "yytables"
 
 #line 227 "libxlu_disk_l.l"
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff -r 841b7e3bd1f9 tools/libxl/libxlu_disk_l.h
--- a/tools/libxl/libxlu_disk_l.h	Wed Apr 25 11:44:09 2012 +0100
+++ b/tools/libxl/libxlu_disk_l.h	Wed Apr 25 11:53:23 2012 +0100
@@ -345,11 +345,3 @@ extern int xlu__disk_yylex (yyscan_t yys
 #line 346 "libxlu_disk_l.h"
 #undef xlu__disk_yyIN_HEADER
 #endif /* xlu__disk_yyHEADER_H */
-
-/*
- * Local variables:
- * mode: C
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:04:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN00v-00064G-EZ; Wed, 25 Apr 2012 11:04:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN00t-000645-VD
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:04:00 +0000
Received: from [85.158.143.99:54782] by server-1.bemta-4.messagelabs.com id
	D2/C4-20925-F1AD79F4; Wed, 25 Apr 2012 11:03:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335351838!19924009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11364 invoked from network); 25 Apr 2012 11:03:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:02:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:02:55 +0100
Message-ID: <1335351773.28015.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:02:53 +0100
In-Reply-To: <alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
	<1335350442.28015.29.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:49 +0100, Stefano Stabellini wrote:

> I would be OK with that, maybe it is worth adding a comment on
> libxl__need_xenpv_qemu to document the behavior.

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335351300 -3600
# Node ID 28f86b71782a099c0373fb237e6b08e0788ff69d
# Parent  02f0161ae6201ded5415e7f0c92214b4783c8d72
libxl: default to xenconsoled for pv guests, even if qemu is running.

Currently we prefer to use qemu for the disk backend if we are starting qemu
anyway (e.g. to service a disk).

Unfortunately qemu doesn't log the console, which xenconsoled can do via
XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
there is no particular reason to prefer qemu just because it happens to be
running.

However we must use qemu if thereis more than one console (xenconsoled only
supports a single console).

Therefore push the logic to change the console backend down into
libxl__need_xenpv_qemu so that it can do the right thing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

I'm not sure if this is 4.2 material, perhaps too late to be making this sort
of change?

diff -r 02f0161ae620 -r 28f86b71782a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 25 11:30:58 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:55:00 2012 +0100
@@ -682,9 +682,6 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_vfbs, d_config->vfbs,
                 d_config->num_disks, &d_config->disks[0]);
 
-        if (need_qemu)
-             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
-
         libxl__device_console_add(gc, domid, &console, &state);
         libxl__device_console_dispose(&console);
 
diff -r 02f0161ae620 -r 28f86b71782a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Apr 25 11:30:58 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Apr 25 11:55:00 2012 +0100
@@ -1093,7 +1093,13 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
 {
     int i, ret = 0;
 
+    /*
+     * qemu is required in order to support 2 or more consoles. So switch all
+     * backends to qemu if this is the case
+     */
     if (nr_consoles > 1) {
+        for (i = 0; i < nr_consoles; i++)
+            consoles[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
         ret = 1;
         goto out;
     }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:04:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN00v-00064G-EZ; Wed, 25 Apr 2012 11:04:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN00t-000645-VD
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:04:00 +0000
Received: from [85.158.143.99:54782] by server-1.bemta-4.messagelabs.com id
	D2/C4-20925-F1AD79F4; Wed, 25 Apr 2012 11:03:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335351838!19924009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11364 invoked from network); 25 Apr 2012 11:03:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:02:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:02:55 +0100
Message-ID: <1335351773.28015.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:02:53 +0100
In-Reply-To: <alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
	<1335350442.28015.29.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:49 +0100, Stefano Stabellini wrote:

> I would be OK with that, maybe it is worth adding a comment on
> libxl__need_xenpv_qemu to document the behavior.

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335351300 -3600
# Node ID 28f86b71782a099c0373fb237e6b08e0788ff69d
# Parent  02f0161ae6201ded5415e7f0c92214b4783c8d72
libxl: default to xenconsoled for pv guests, even if qemu is running.

Currently we prefer to use qemu for the disk backend if we are starting qemu
anyway (e.g. to service a disk).

Unfortunately qemu doesn't log the console, which xenconsoled can do via
XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
there is no particular reason to prefer qemu just because it happens to be
running.

However we must use qemu if thereis more than one console (xenconsoled only
supports a single console).

Therefore push the logic to change the console backend down into
libxl__need_xenpv_qemu so that it can do the right thing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

I'm not sure if this is 4.2 material, perhaps too late to be making this sort
of change?

diff -r 02f0161ae620 -r 28f86b71782a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 25 11:30:58 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Apr 25 11:55:00 2012 +0100
@@ -682,9 +682,6 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_vfbs, d_config->vfbs,
                 d_config->num_disks, &d_config->disks[0]);
 
-        if (need_qemu)
-             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
-
         libxl__device_console_add(gc, domid, &console, &state);
         libxl__device_console_dispose(&console);
 
diff -r 02f0161ae620 -r 28f86b71782a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Apr 25 11:30:58 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Apr 25 11:55:00 2012 +0100
@@ -1093,7 +1093,13 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
 {
     int i, ret = 0;
 
+    /*
+     * qemu is required in order to support 2 or more consoles. So switch all
+     * backends to qemu if this is the case
+     */
     if (nr_consoles > 1) {
+        for (i = 0; i < nr_consoles; i++)
+            consoles[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
         ret = 1;
         goto out;
     }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN01F-00066s-S3; Wed, 25 Apr 2012 11:04:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SN01E-00066P-Ns
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:04:20 +0000
Received: from [85.158.143.99:58180] by server-1.bemta-4.messagelabs.com id
	D9/65-20925-23AD79F4; Wed, 25 Apr 2012 11:04:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335351856!25209968!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16004 invoked from network); 25 Apr 2012 11:04:18 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:04:18 -0000
Received: by qaeb19 with SMTP id b19so3566636qae.11
	for <xen-devel@lists.xen.org>; Wed, 25 Apr 2012 04:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=M6X/OH4cz7gocJqy4sR7jtrnKiSwGhNnWhe13MUCZWY=;
	b=c/4optgXQyvWIijwYOOze/qYdoVnrng+wpf0qYmwB50DFToRSxgNZ8KHWG30BvbiGI
	HQIOkfr4Y+4nAWru4/+QwrYxOosC+5lNfBG0/4GjJKNsLZ6rKm67m/tvdiI0ZIBzYmS0
	rUhe8DVlfFdNBVdsk1kdIZ2ZJJfgc0663sG5fepO56wSce4FD9UWeEaHKDRzoIQfOZFg
	N8jc+wPer42bj5wqxfXiqAkMGnSwb3zTOTbr6GX44XIUf4D3mEMXYVlYHerYaYyttfQ+
	iyj8aiFocJijLV0R1j5ybVDBx82KKYDUK3+YDhw4149NVLelfsUnKnVkkIqcmEYXgyVQ
	CXqA==
MIME-Version: 1.0
Received: by 10.229.178.233 with SMTP id bn41mr376510qcb.89.1335351856551;
	Wed, 25 Apr 2012 04:04:16 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Wed, 25 Apr 2012 04:04:16 -0700 (PDT)
Date: Wed, 25 Apr 2012 12:04:16 +0100
X-Google-Sender-Auth: 5PnQMxo4qIPNokDjN4xojwPjY7k
Message-ID: <CAFLBxZZOBvvXVccPxh3VxR79NEcdQPjsfpLwubUYni8iVCW+yw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	=?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: [Xen-devel] Make clean failure with qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some kind of dependency failure with make clean and qemu:

$ make -C tools clean
[...]
make[1]: Warning: File
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/../Config.mk' has
modification time 49 s in the future
set -e; if test -d qemu-xen-traditional-dir/.; then \
		make -C qemu-xen-traditional-dir clean; \
	fi
make[2]: Entering directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/qemu-xen-traditional-dir-remote'
Makefile:3: config-host.mak: No such file or directory
Makefile:4: /rules.mak: No such file or directory
make[2]: *** No rule to make target `/rules.mak'. Stop.
make[2]: Leaving directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/qemu-xen-traditional-dir-remote'
make[1]: *** [subdir-clean-qemu-xen-traditional-dir] Error 2
make[1]: Leaving directory `/home/gdunlap/hg/open-source/xen-upstream.hg/tools'
make: *** [subdirs-clean] Error 2
make: Leaving directory `/home/gdunlap/hg/open-source/xen-upstream.hg/tools'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN01F-00066s-S3; Wed, 25 Apr 2012 11:04:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SN01E-00066P-Ns
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:04:20 +0000
Received: from [85.158.143.99:58180] by server-1.bemta-4.messagelabs.com id
	D9/65-20925-23AD79F4; Wed, 25 Apr 2012 11:04:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335351856!25209968!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16004 invoked from network); 25 Apr 2012 11:04:18 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:04:18 -0000
Received: by qaeb19 with SMTP id b19so3566636qae.11
	for <xen-devel@lists.xen.org>; Wed, 25 Apr 2012 04:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=M6X/OH4cz7gocJqy4sR7jtrnKiSwGhNnWhe13MUCZWY=;
	b=c/4optgXQyvWIijwYOOze/qYdoVnrng+wpf0qYmwB50DFToRSxgNZ8KHWG30BvbiGI
	HQIOkfr4Y+4nAWru4/+QwrYxOosC+5lNfBG0/4GjJKNsLZ6rKm67m/tvdiI0ZIBzYmS0
	rUhe8DVlfFdNBVdsk1kdIZ2ZJJfgc0663sG5fepO56wSce4FD9UWeEaHKDRzoIQfOZFg
	N8jc+wPer42bj5wqxfXiqAkMGnSwb3zTOTbr6GX44XIUf4D3mEMXYVlYHerYaYyttfQ+
	iyj8aiFocJijLV0R1j5ybVDBx82KKYDUK3+YDhw4149NVLelfsUnKnVkkIqcmEYXgyVQ
	CXqA==
MIME-Version: 1.0
Received: by 10.229.178.233 with SMTP id bn41mr376510qcb.89.1335351856551;
	Wed, 25 Apr 2012 04:04:16 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Wed, 25 Apr 2012 04:04:16 -0700 (PDT)
Date: Wed, 25 Apr 2012 12:04:16 +0100
X-Google-Sender-Auth: 5PnQMxo4qIPNokDjN4xojwPjY7k
Message-ID: <CAFLBxZZOBvvXVccPxh3VxR79NEcdQPjsfpLwubUYni8iVCW+yw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	=?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: [Xen-devel] Make clean failure with qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some kind of dependency failure with make clean and qemu:

$ make -C tools clean
[...]
make[1]: Warning: File
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/../Config.mk' has
modification time 49 s in the future
set -e; if test -d qemu-xen-traditional-dir/.; then \
		make -C qemu-xen-traditional-dir clean; \
	fi
make[2]: Entering directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/qemu-xen-traditional-dir-remote'
Makefile:3: config-host.mak: No such file or directory
Makefile:4: /rules.mak: No such file or directory
make[2]: *** No rule to make target `/rules.mak'. Stop.
make[2]: Leaving directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/qemu-xen-traditional-dir-remote'
make[1]: *** [subdir-clean-qemu-xen-traditional-dir] Error 2
make[1]: Leaving directory `/home/gdunlap/hg/open-source/xen-upstream.hg/tools'
make: *** [subdirs-clean] Error 2
make: Leaving directory `/home/gdunlap/hg/open-source/xen-upstream.hg/tools'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:04:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN01P-00068P-Be; Wed, 25 Apr 2012 11:04:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN01N-000682-Pz
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:04:29 +0000
Received: from [193.109.254.147:25434] by server-12.bemta-14.messagelabs.com
	id 3B/DE-05898-D3AD79F4; Wed, 25 Apr 2012 11:04:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335351864!6233702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11965 invoked from network); 25 Apr 2012 11:04:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:04:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:04:23 +0100
Message-ID: <1335351862.28015.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:04:22 +0100
In-Reply-To: <20375.53766.400829.139875@mariner.uk.xensource.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<1335345779.28015.15.camel@zakaz.uk.xensource.com>
	<20375.53766.400829.139875@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
 is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:29 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend is running."):
> > On Tue, 2012-04-24 at 19:05 +0100, Roger Pau Monne wrote:
> > > Prevent xl from doing any operation if xend daemon is running. That
> > > prevents bugs that happened when xl and xend raced to close a domain.
> ...
> > Do we now have 3 classes of commands which could be represented with an
> > enum rather than a pair of bools?
> 
> No, because hopefully eventually every command will support dryrun and
> then we can abolish that flag.

Makes sense.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:04:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN01P-00068P-Be; Wed, 25 Apr 2012 11:04:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN01N-000682-Pz
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:04:29 +0000
Received: from [193.109.254.147:25434] by server-12.bemta-14.messagelabs.com
	id 3B/DE-05898-D3AD79F4; Wed, 25 Apr 2012 11:04:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335351864!6233702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11965 invoked from network); 25 Apr 2012 11:04:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12128919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:04:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:04:23 +0100
Message-ID: <1335351862.28015.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:04:22 +0100
In-Reply-To: <20375.53766.400829.139875@mariner.uk.xensource.com>
References: <1335290722-41487-1-git-send-email-roger.pau@citrix.com>
	<1335345779.28015.15.camel@zakaz.uk.xensource.com>
	<20375.53766.400829.139875@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend
 is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:29 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: prevent xl from running if xend is running."):
> > On Tue, 2012-04-24 at 19:05 +0100, Roger Pau Monne wrote:
> > > Prevent xl from doing any operation if xend daemon is running. That
> > > prevents bugs that happened when xl and xend raced to close a domain.
> ...
> > Do we now have 3 classes of commands which could be represented with an
> > enum rather than a pair of bools?
> 
> No, because hopefully eventually every command will support dryrun and
> then we can abolish that flag.

Makes sense.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN05y-0006bf-2r; Wed, 25 Apr 2012 11:09:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN05w-0006bN-Ed
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:09:12 +0000
Received: from [193.109.254.147:38994] by server-8.bemta-14.messagelabs.com id
	3B/DA-23244-75BD79F4; Wed, 25 Apr 2012 11:09:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335352149!6283150!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1339 invoked from network); 25 Apr 2012 11:09:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:09:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191965838"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:09:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:09:03 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN05n-0007g2-25;
	Wed, 25 Apr 2012 12:09:03 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 12:09:02 +0100
Message-ID: <1335352142-43858-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3] libxl: prevent xl from running if xend is
	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prevent xl from doing any operation if xend daemon is running. That
prevents bugs that happened when xl and xend raced to close a domain.

Changes since v2:

 * Allow to dry run even if xend is running.

 * Refresh to apply to current tree.

Changes since v1:

 * Add documentation to xl man page.

 * Permit the execution of commands that don't modify anything.

 * Indent error message.

Cc: ian.jackson@eu.citrix.com
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.pod.1         |    6 ++
 tools/libxl/xl.c          |   22 +++++++-
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    5 +-
 tools/libxl/xl_cmdtable.c |  132 ++++++++++++++++++++++----------------------
 5 files changed, 97 insertions(+), 69 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e5324fb..e829697 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -75,6 +75,12 @@ Verbose.
 
 Dry run: do not actually execute the command.
 
+=item B<-f>
+
+Force execution: xl will refuse to run some commands if it detects that xend is
+also running, this option will force the execution of those commands, even
+though it is unsafe.
+
 =back
 
 =head1 DOMAIN SUBCOMMANDS
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..51369fd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -32,8 +32,11 @@
 #include "libxlutil.h"
 #include "xl.h"
 
+#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
+
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
+int force_execution;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
@@ -114,8 +117,9 @@ int main(int argc, char **argv)
     char *config_file;
     void *config_data = 0;
     int config_len = 0;
+    const char *locks[] = XEND_LOCK;
 
-    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
+    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
         switch (opt) {
         case 'v':
             if (minmsglevel > 0) minmsglevel--;
@@ -123,6 +127,9 @@ int main(int argc, char **argv)
         case 'N':
             dryrun_only = 1;
             break;
+        case 'f':
+            force_execution = 1;
+            break;
         default:
             fprintf(stderr, "unknown global option\n");
             exit(2);
@@ -173,6 +180,19 @@ int main(int argc, char **argv)
             ret = 1;
             goto xit;
         }
+        if (cspec->modifies && !dryrun_only) {
+            for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
+                if (!access(locks[i], F_OK) && !force_execution) {
+                    fprintf(stderr,
+"xend is running, which prevents xl from working correctly.\n"
+"If you still want to force the execution of xl please use the -f\n"
+"option.\n"
+                            );
+                    ret = 1;
+                    goto xit;
+                }
+            }
+        }
         ret = cspec->cmd_impl(argc, argv);
     } else if (!strcmp(cmd, "help")) {
         help(argv[1]);
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..8c0823f 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -21,6 +21,7 @@ struct cmd_spec {
     char *cmd_name;
     int (*cmd_impl)(int argc, char **argv);
     int can_dryrun;
+    int modifies;
     char *cmd_desc;
     char *cmd_usage;
     char *cmd_option;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..085ec80 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1905,7 +1905,7 @@ void help(const char *command)
     struct cmd_spec *cmd;
 
     if (!command || !strcmp(command, "help")) {
-        printf("Usage xl [-vN] <subcommand> [args]\n\n");
+        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
         printf("xl full list of subcommands:\n\n");
         for (i = 0; i < cmdtable_len; i++) {
             printf(" %-19s ", cmd_table[i].cmd_name);
@@ -1916,7 +1916,8 @@ void help(const char *command)
     } else {
         cmd = cmdtable_lookup(command);
         if (cmd) {
-            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
+            printf("Usage: xl [-v%s%s] %s %s\n\n%s.\n\n",
+                   cmd->modifies ? "f" : "",
                    cmd->can_dryrun ? "N" : "",
                    cmd->cmd_name,
                    cmd->cmd_usage,
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 736a836..36c047f 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -19,7 +19,7 @@
 
 struct cmd_spec cmd_table[] = {
     { "create",
-      &main_create, 1,
+      &main_create, 1, 1,
       "Create a domain from config file <filename>",
       "<ConfigFile> [options] [vars]",
       "-h                      Print this help.\n"
@@ -33,7 +33,7 @@ struct cmd_spec cmd_table[] = {
       "-e                      Do not wait in the background for the death of the domain."
     },
     { "config-update",
-      &main_config_update, 1,
+      &main_config_update, 1, 1,
       "Update a running domain's saved configuration, used when rebuilding "
       "the domain after reboot",
       "<Domain> <ConfigFile> [options] [vars]",
@@ -42,7 +42,7 @@ struct cmd_spec cmd_table[] = {
       "-d                      Enable debug messages.\n"
     },
     { "list",
-      &main_list, 0,
+      &main_list, 0, 0,
       "List information about all/some domains",
       "[options] [Domain]\n",
       "-l, --long              Output all VM details\n"
@@ -50,12 +50,12 @@ struct cmd_spec cmd_table[] = {
       "-Z, --context           Prints out security context"
     },
     { "destroy",
-      &main_destroy, 0,
+      &main_destroy, 0, 1,
       "Terminate a domain immediately",
       "<Domain>",
     },
     { "shutdown",
-      &main_shutdown, 0,
+      &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-w                      Wait for guest to shutdown.\n"
     },
     { "reboot",
-      &main_reboot, 0,
+      &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -72,44 +72,44 @@ struct cmd_spec cmd_table[] = {
       "                        no PV drivers.\n"
     },
     { "pci-attach",
-      &main_pciattach, 0,
+      &main_pciattach, 0, 1,
       "Insert a new pass-through pci device",
       "<Domain> <BDF> [Virtual Slot]",
     },
     { "pci-detach",
-      &main_pcidetach, 0,
+      &main_pcidetach, 0, 1,
       "Remove a domain's pass-through pci device",
       "<Domain> <BDF>",
     },
     { "pci-list",
-      &main_pcilist, 0,
+      &main_pcilist, 0, 0,
       "List pass-through pci devices for a domain",
       "<Domain>",
     },
     { "pci-list-assignable-devices",
-      &main_pcilist_assignable, 0,
+      &main_pcilist_assignable, 0, 0,
       "List all the assignable pci devices",
       "",
     },
     { "pause",
-      &main_pause, 0,
+      &main_pause, 0, 1,
       "Pause execution of a domain",
       "<Domain>",
     },
     { "unpause",
-      &main_unpause, 0,
+      &main_unpause, 0, 1,
       "Unpause a paused domain",
       "<Domain>",
     },
     { "console",
-      &main_console, 0,
+      &main_console, 0, 0,
       "Attach to domain's console",
       "[options] <Domain>\n"
       "-t <type>       console type, pv or serial\n"
       "-n <number>     console number"
     },
     { "vncviewer",
-      &main_vncviewer, 0,
+      &main_vncviewer, 0, 0,
       "Attach to domain's VNC server.",
       "[options] <Domain>\n"
       "--autopass               Pass VNC password to viewer via stdin and\n"
@@ -117,14 +117,14 @@ struct cmd_spec cmd_table[] = {
       "--vncviewer-autopass     (consistency alias for --autopass)"
     },
     { "save",
-      &main_save, 0,
+      &main_save, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <CheckpointFile> [<ConfigFile>]",
       "-h  Print this help.\n"
       "-c  Leave domain running after creating the snapshot."
     },
     { "migrate",
-      &main_migrate, 0,
+      &main_migrate, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <host>",
       "-h              Print this help.\n"
@@ -136,12 +136,12 @@ struct cmd_spec cmd_table[] = {
       "                of the domain."
     },
     { "dump-core",
-      &main_dump_core, 0,
+      &main_dump_core, 0, 1,
       "Core dump a domain",
       "<Domain> <filename>"
     },
     { "restore",
-      &main_restore, 0,
+      &main_restore, 0, 1,
       "Restore a domain from a saved state",
       "[options] [<ConfigFile>] <CheckpointFile>",
       "-h  Print this help.\n"
@@ -150,68 +150,68 @@ struct cmd_spec cmd_table[] = {
       "-d  Enable debug messages."
     },
     { "migrate-receive",
-      &main_migrate_receive, 0,
+      &main_migrate_receive, 0, 1,
       "Restore a domain from a saved state",
       "- for internal use only",
     },
     { "cd-insert",
-      &main_cd_insert, 0,
+      &main_cd_insert, 0, 1,
       "Insert a cdrom into a guest's cd drive",
       "<Domain> <VirtualDevice> <type:path>",
     },
     { "cd-eject",
-      &main_cd_eject, 0,
+      &main_cd_eject, 0, 1,
       "Eject a cdrom from a guest's cd drive",
       "<Domain> <VirtualDevice>",
     },
     { "mem-max",
-      &main_memmax, 0,
+      &main_memmax, 0, 1,
       "Set the maximum amount reservation for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "mem-set",
-      &main_memset, 0,
+      &main_memset, 0, 1,
       "Set the current memory usage for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "button-press",
-      &main_button_press, 0,
+      &main_button_press, 0, 1,
       "Indicate an ACPI button press to the domain",
       "<Domain> <Button>",
       "<Button> may be 'power' or 'sleep'."
     },
     { "vcpu-list",
-      &main_vcpulist, 0,
+      &main_vcpulist, 0, 0,
       "List the VCPUs for all/some domains",
       "[Domain, ...]",
     },
     { "vcpu-pin",
-      &main_vcpupin, 0,
+      &main_vcpupin, 0, 1,
       "Set which CPUs a VCPU can use",
       "<Domain> <VCPU|all> <CPUs|all>",
     },
     { "vcpu-set",
-      &main_vcpuset, 0,
+      &main_vcpuset, 0, 1,
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
     { "list-vm",
-      &main_list_vm, 0,
+      &main_list_vm, 0, 0,
       "List the VMs,without DOM0",
       "",
     },
     { "info",
-      &main_info, 0,
+      &main_info, 0, 0,
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
     { "sharing",
-      &main_sharing, 0,
+      &main_sharing, 0, 0,
       "Get information about page sharing",
       "[Domain]", 
     },
     { "sched-credit",
-      &main_sched_credit, 0,
+      &main_sched_credit, 0, 1,
       "Get/set credit scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
@@ -223,7 +223,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
-      &main_sched_credit2, 0,
+      &main_sched_credit2, 0, 1,
       "Get/set credit2 scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -231,7 +231,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "sched-sedf",
-      &main_sched_sedf, 0,
+      &main_sched_sedf, 0, 1,
       "Get/set sedf scheduler parameters",
       "[options]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -247,109 +247,109 @@ struct cmd_spec cmd_table[] = {
       "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
-      &main_domid, 0,
+      &main_domid, 0, 0,
       "Convert a domain name to domain id",
       "<DomainName>",
     },
     { "domname",
-      &main_domname, 0,
+      &main_domname, 0, 0,
       "Convert a domain id to domain name",
       "<DomainId>",
     },
     { "rename",
-      &main_rename, 0,
+      &main_rename, 0, 1,
       "Rename a domain",
       "<Domain> <NewDomainName>",
     },
     { "trigger",
-      &main_trigger, 0,
+      &main_trigger, 0, 1,
       "Send a trigger to a domain",
       "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
     },
     { "sysrq",
-      &main_sysrq, 0,
+      &main_sysrq, 0, 1,
       "Send a sysrq to a domain",
       "<Domain> <letter>",
     },
     { "debug-keys",
-      &main_debug_keys, 0,
+      &main_debug_keys, 0, 1,
       "Send debug keys to Xen",
       "<Keys>",
     },
     { "dmesg",
-      &main_dmesg, 0,
+      &main_dmesg, 0, 0,
       "Read and/or clear dmesg buffer",
       "[-c]",
       "  -c                        Clear dmesg buffer as well as printing it",
     },
     { "top",
-      &main_top, 0,
+      &main_top, 0, 0,
       "Monitor a host and the domains in real time",
       "",
     },
     { "network-attach",
-      &main_networkattach, 1,
+      &main_networkattach, 1, 1,
       "Create a new virtual network device",
       "<Domain> [type=<type>] [mac=<mac>] [bridge=<bridge>] "
       "[ip=<ip>] [script=<script>] [backend=<BackDomain>] [vifname=<name>] "
       "[rate=<rate>] [model=<model>] [accel=<accel>]",
     },
     { "network-list",
-      &main_networklist, 0,
+      &main_networklist, 0, 0,
       "List virtual network interfaces for a domain",
       "<Domain(s)>",
     },
     { "network-detach",
-      &main_networkdetach, 0,
+      &main_networkdetach, 0, 1,
       "Destroy a domain's virtual network device",
       "<Domain> <DevId|mac>",
     },
     { "block-attach",
-      &main_blockattach, 1,
+      &main_blockattach, 1, 1,
       "Create a new virtual block device",
       "<Domain> <disk-spec-component(s)>...",
     },
     { "block-list",
-      &main_blocklist, 0,
+      &main_blocklist, 0, 0,
       "List virtual block devices for a domain",
       "<Domain(s)>",
     },
     { "block-detach",
-      &main_blockdetach, 0,
+      &main_blockdetach, 0, 1,
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
     { "uptime",
-      &main_uptime, 0,
+      &main_uptime, 0, 0,
       "Print uptime for all/some domains",
       "[-s] [Domain]",
     },
     { "tmem-list",
-      &main_tmem_list, 0,
+      &main_tmem_list, 0, 0,
       "List tmem pools",
       "[-l] [<Domain>|-a]",
       "  -l                             List tmem stats",
     },
     { "tmem-freeze",
-      &main_tmem_freeze, 0,
+      &main_tmem_freeze, 0, 1,
       "Freeze tmem pools",
       "[<Domain>|-a]",
       "  -a                             Freeze all tmem",
     },
     { "tmem-destroy",
-      &main_tmem_destroy, 0,
+      &main_tmem_destroy, 0, 1,
       "Destroy tmem pools",
       "[<Domain>|-a]",
       "  -a                             Destroy all tmem",
     },
     { "tmem-thaw",
-      &main_tmem_thaw, 0,
+      &main_tmem_thaw, 0, 1,
       "Thaw tmem pools",
       "[<Domain>|-a]",
       "  -a                             Thaw all tmem",
     },
     { "tmem-set",
-      &main_tmem_set, 0,
+      &main_tmem_set, 0, 1,
       "Change tmem settings",
       "[<Domain>|-a] [-w[=WEIGHT]|-c[=CAP]|-p[=COMPRESS]]",
       "  -a                             Operate on all tmem\n"
@@ -358,7 +358,7 @@ struct cmd_spec cmd_table[] = {
       "  -p COMPRESS                    Compress (int)",
     },
     { "tmem-shared-auth",
-      &main_tmem_shared_auth, 0,
+      &main_tmem_shared_auth, 0, 1,
       "De/authenticate shared tmem pool",
       "[<Domain>|-a] [-u[=UUID] [-A[=AUTH]",
       "  -a                             Authenticate for all tmem pools\n"
@@ -367,12 +367,12 @@ struct cmd_spec cmd_table[] = {
       "  -A AUTH                        0=auth,1=deauth",
     },
     { "tmem-freeable",
-      &main_tmem_freeable, 0,
+      &main_tmem_freeable, 0, 0,
       "Get information about how much freeable memory (MB) is in-use by tmem",
       "",
     },
     { "cpupool-create",
-      &main_cpupoolcreate, 1,
+      &main_cpupoolcreate, 1, 1,
       "Create a CPU pool based an ConfigFile",
       "[options] <ConfigFile> [vars]",
       "-h, --help                   Print this help.\n"
@@ -381,53 +381,53 @@ struct cmd_spec cmd_table[] = {
       "                              (deprecated in favour of global -N option)."
     },
     { "cpupool-list",
-      &main_cpupoollist, 0,
+      &main_cpupoollist, 0, 0,
       "List CPU pools on host",
       "[-c|--cpus] [<CPU Pool>]",
       "-c, --cpus                     Output list of CPUs used by a pool"
     },
     { "cpupool-destroy",
-      &main_cpupooldestroy, 0,
+      &main_cpupooldestroy, 0, 1,
       "Deactivates a CPU pool",
       "<CPU Pool>",
     },
     { "cpupool-rename",
-      &main_cpupoolrename, 0,
+      &main_cpupoolrename, 0, 1,
       "Renames a CPU pool",
       "<CPU Pool> <new name>",
     },
     { "cpupool-cpu-add",
-      &main_cpupoolcpuadd, 0,
+      &main_cpupoolcpuadd, 0, 1,
       "Adds a CPU to a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-cpu-remove",
-      &main_cpupoolcpuremove, 0,
+      &main_cpupoolcpuremove, 0, 1,
       "Removes a CPU from a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-migrate",
-      &main_cpupoolmigrate, 0,
+      &main_cpupoolmigrate, 0, 1,
       "Moves a domain into a CPU pool",
       "<Domain> <CPU Pool>",
     },
     { "cpupool-numa-split",
-      &main_cpupoolnumasplit, 0,
+      &main_cpupoolnumasplit, 0, 1,
       "Splits up the machine into one CPU pool per NUMA node",
       "",
     },
     { "getenforce",
-      &main_getenforce, 0,
+      &main_getenforce, 0, 0,
       "Returns the current enforcing mode of the Flask Xen security module",
       "",
     },
     { "setenforce",
-      &main_setenforce, 0,
+      &main_setenforce, 0, 1,
       "Sets the current enforcing mode of the Flask Xen security module",
       "<1|0|Enforcing|Permissive>",
     },
     { "loadpolicy",
-      &main_loadpolicy, 0,
+      &main_loadpolicy, 0, 1,
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN05y-0006bf-2r; Wed, 25 Apr 2012 11:09:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN05w-0006bN-Ed
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:09:12 +0000
Received: from [193.109.254.147:38994] by server-8.bemta-14.messagelabs.com id
	3B/DA-23244-75BD79F4; Wed, 25 Apr 2012 11:09:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335352149!6283150!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1339 invoked from network); 25 Apr 2012 11:09:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:09:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191965838"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:09:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:09:03 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN05n-0007g2-25;
	Wed, 25 Apr 2012 12:09:03 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 12:09:02 +0100
Message-ID: <1335352142-43858-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3] libxl: prevent xl from running if xend is
	running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Prevent xl from doing any operation if xend daemon is running. That
prevents bugs that happened when xl and xend raced to close a domain.

Changes since v2:

 * Allow to dry run even if xend is running.

 * Refresh to apply to current tree.

Changes since v1:

 * Add documentation to xl man page.

 * Permit the execution of commands that don't modify anything.

 * Indent error message.

Cc: ian.jackson@eu.citrix.com
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.pod.1         |    6 ++
 tools/libxl/xl.c          |   22 +++++++-
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    5 +-
 tools/libxl/xl_cmdtable.c |  132 ++++++++++++++++++++++----------------------
 5 files changed, 97 insertions(+), 69 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e5324fb..e829697 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -75,6 +75,12 @@ Verbose.
 
 Dry run: do not actually execute the command.
 
+=item B<-f>
+
+Force execution: xl will refuse to run some commands if it detects that xend is
+also running, this option will force the execution of those commands, even
+though it is unsafe.
+
 =back
 
 =head1 DOMAIN SUBCOMMANDS
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..51369fd 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -32,8 +32,11 @@
 #include "libxlutil.h"
 #include "xl.h"
 
+#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" }
+
 xentoollog_logger_stdiostream *logger;
 int dryrun_only;
+int force_execution;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
@@ -114,8 +117,9 @@ int main(int argc, char **argv)
     char *config_file;
     void *config_data = 0;
     int config_len = 0;
+    const char *locks[] = XEND_LOCK;
 
-    while ((opt = getopt(argc, argv, "+vN")) >= 0) {
+    while ((opt = getopt(argc, argv, "+vfN")) >= 0) {
         switch (opt) {
         case 'v':
             if (minmsglevel > 0) minmsglevel--;
@@ -123,6 +127,9 @@ int main(int argc, char **argv)
         case 'N':
             dryrun_only = 1;
             break;
+        case 'f':
+            force_execution = 1;
+            break;
         default:
             fprintf(stderr, "unknown global option\n");
             exit(2);
@@ -173,6 +180,19 @@ int main(int argc, char **argv)
             ret = 1;
             goto xit;
         }
+        if (cspec->modifies && !dryrun_only) {
+            for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
+                if (!access(locks[i], F_OK) && !force_execution) {
+                    fprintf(stderr,
+"xend is running, which prevents xl from working correctly.\n"
+"If you still want to force the execution of xl please use the -f\n"
+"option.\n"
+                            );
+                    ret = 1;
+                    goto xit;
+                }
+            }
+        }
         ret = cspec->cmd_impl(argc, argv);
     } else if (!strcmp(cmd, "help")) {
         help(argv[1]);
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 7e258d5..8c0823f 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -21,6 +21,7 @@ struct cmd_spec {
     char *cmd_name;
     int (*cmd_impl)(int argc, char **argv);
     int can_dryrun;
+    int modifies;
     char *cmd_desc;
     char *cmd_usage;
     char *cmd_option;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5703512..085ec80 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1905,7 +1905,7 @@ void help(const char *command)
     struct cmd_spec *cmd;
 
     if (!command || !strcmp(command, "help")) {
-        printf("Usage xl [-vN] <subcommand> [args]\n\n");
+        printf("Usage xl [-vfN] <subcommand> [args]\n\n");
         printf("xl full list of subcommands:\n\n");
         for (i = 0; i < cmdtable_len; i++) {
             printf(" %-19s ", cmd_table[i].cmd_name);
@@ -1916,7 +1916,8 @@ void help(const char *command)
     } else {
         cmd = cmdtable_lookup(command);
         if (cmd) {
-            printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n",
+            printf("Usage: xl [-v%s%s] %s %s\n\n%s.\n\n",
+                   cmd->modifies ? "f" : "",
                    cmd->can_dryrun ? "N" : "",
                    cmd->cmd_name,
                    cmd->cmd_usage,
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 736a836..36c047f 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -19,7 +19,7 @@
 
 struct cmd_spec cmd_table[] = {
     { "create",
-      &main_create, 1,
+      &main_create, 1, 1,
       "Create a domain from config file <filename>",
       "<ConfigFile> [options] [vars]",
       "-h                      Print this help.\n"
@@ -33,7 +33,7 @@ struct cmd_spec cmd_table[] = {
       "-e                      Do not wait in the background for the death of the domain."
     },
     { "config-update",
-      &main_config_update, 1,
+      &main_config_update, 1, 1,
       "Update a running domain's saved configuration, used when rebuilding "
       "the domain after reboot",
       "<Domain> <ConfigFile> [options] [vars]",
@@ -42,7 +42,7 @@ struct cmd_spec cmd_table[] = {
       "-d                      Enable debug messages.\n"
     },
     { "list",
-      &main_list, 0,
+      &main_list, 0, 0,
       "List information about all/some domains",
       "[options] [Domain]\n",
       "-l, --long              Output all VM details\n"
@@ -50,12 +50,12 @@ struct cmd_spec cmd_table[] = {
       "-Z, --context           Prints out security context"
     },
     { "destroy",
-      &main_destroy, 0,
+      &main_destroy, 0, 1,
       "Terminate a domain immediately",
       "<Domain>",
     },
     { "shutdown",
-      &main_shutdown, 0,
+      &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-w                      Wait for guest to shutdown.\n"
     },
     { "reboot",
-      &main_reboot, 0,
+      &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
       "[options] <Domain>",
       "-h                      Print this help.\n"
@@ -72,44 +72,44 @@ struct cmd_spec cmd_table[] = {
       "                        no PV drivers.\n"
     },
     { "pci-attach",
-      &main_pciattach, 0,
+      &main_pciattach, 0, 1,
       "Insert a new pass-through pci device",
       "<Domain> <BDF> [Virtual Slot]",
     },
     { "pci-detach",
-      &main_pcidetach, 0,
+      &main_pcidetach, 0, 1,
       "Remove a domain's pass-through pci device",
       "<Domain> <BDF>",
     },
     { "pci-list",
-      &main_pcilist, 0,
+      &main_pcilist, 0, 0,
       "List pass-through pci devices for a domain",
       "<Domain>",
     },
     { "pci-list-assignable-devices",
-      &main_pcilist_assignable, 0,
+      &main_pcilist_assignable, 0, 0,
       "List all the assignable pci devices",
       "",
     },
     { "pause",
-      &main_pause, 0,
+      &main_pause, 0, 1,
       "Pause execution of a domain",
       "<Domain>",
     },
     { "unpause",
-      &main_unpause, 0,
+      &main_unpause, 0, 1,
       "Unpause a paused domain",
       "<Domain>",
     },
     { "console",
-      &main_console, 0,
+      &main_console, 0, 0,
       "Attach to domain's console",
       "[options] <Domain>\n"
       "-t <type>       console type, pv or serial\n"
       "-n <number>     console number"
     },
     { "vncviewer",
-      &main_vncviewer, 0,
+      &main_vncviewer, 0, 0,
       "Attach to domain's VNC server.",
       "[options] <Domain>\n"
       "--autopass               Pass VNC password to viewer via stdin and\n"
@@ -117,14 +117,14 @@ struct cmd_spec cmd_table[] = {
       "--vncviewer-autopass     (consistency alias for --autopass)"
     },
     { "save",
-      &main_save, 0,
+      &main_save, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <CheckpointFile> [<ConfigFile>]",
       "-h  Print this help.\n"
       "-c  Leave domain running after creating the snapshot."
     },
     { "migrate",
-      &main_migrate, 0,
+      &main_migrate, 0, 1,
       "Save a domain state to restore later",
       "[options] <Domain> <host>",
       "-h              Print this help.\n"
@@ -136,12 +136,12 @@ struct cmd_spec cmd_table[] = {
       "                of the domain."
     },
     { "dump-core",
-      &main_dump_core, 0,
+      &main_dump_core, 0, 1,
       "Core dump a domain",
       "<Domain> <filename>"
     },
     { "restore",
-      &main_restore, 0,
+      &main_restore, 0, 1,
       "Restore a domain from a saved state",
       "[options] [<ConfigFile>] <CheckpointFile>",
       "-h  Print this help.\n"
@@ -150,68 +150,68 @@ struct cmd_spec cmd_table[] = {
       "-d  Enable debug messages."
     },
     { "migrate-receive",
-      &main_migrate_receive, 0,
+      &main_migrate_receive, 0, 1,
       "Restore a domain from a saved state",
       "- for internal use only",
     },
     { "cd-insert",
-      &main_cd_insert, 0,
+      &main_cd_insert, 0, 1,
       "Insert a cdrom into a guest's cd drive",
       "<Domain> <VirtualDevice> <type:path>",
     },
     { "cd-eject",
-      &main_cd_eject, 0,
+      &main_cd_eject, 0, 1,
       "Eject a cdrom from a guest's cd drive",
       "<Domain> <VirtualDevice>",
     },
     { "mem-max",
-      &main_memmax, 0,
+      &main_memmax, 0, 1,
       "Set the maximum amount reservation for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "mem-set",
-      &main_memset, 0,
+      &main_memset, 0, 1,
       "Set the current memory usage for a domain",
       "<Domain> <MemMB['b'[bytes]|'k'[KB]|'m'[MB]|'g'[GB]|'t'[TB]]>",
     },
     { "button-press",
-      &main_button_press, 0,
+      &main_button_press, 0, 1,
       "Indicate an ACPI button press to the domain",
       "<Domain> <Button>",
       "<Button> may be 'power' or 'sleep'."
     },
     { "vcpu-list",
-      &main_vcpulist, 0,
+      &main_vcpulist, 0, 0,
       "List the VCPUs for all/some domains",
       "[Domain, ...]",
     },
     { "vcpu-pin",
-      &main_vcpupin, 0,
+      &main_vcpupin, 0, 1,
       "Set which CPUs a VCPU can use",
       "<Domain> <VCPU|all> <CPUs|all>",
     },
     { "vcpu-set",
-      &main_vcpuset, 0,
+      &main_vcpuset, 0, 1,
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
     { "list-vm",
-      &main_list_vm, 0,
+      &main_list_vm, 0, 0,
       "List the VMs,without DOM0",
       "",
     },
     { "info",
-      &main_info, 0,
+      &main_info, 0, 0,
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
     { "sharing",
-      &main_sharing, 0,
+      &main_sharing, 0, 0,
       "Get information about page sharing",
       "[Domain]", 
     },
     { "sched-credit",
-      &main_sched_credit, 0,
+      &main_sched_credit, 0, 1,
       "Get/set credit scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
@@ -223,7 +223,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
-      &main_sched_credit2, 0,
+      &main_sched_credit2, 0, 1,
       "Get/set credit2 scheduler parameters",
       "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -231,7 +231,7 @@ struct cmd_spec cmd_table[] = {
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "sched-sedf",
-      &main_sched_sedf, 0,
+      &main_sched_sedf, 0, 1,
       "Get/set sedf scheduler parameters",
       "[options]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
@@ -247,109 +247,109 @@ struct cmd_spec cmd_table[] = {
       "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
-      &main_domid, 0,
+      &main_domid, 0, 0,
       "Convert a domain name to domain id",
       "<DomainName>",
     },
     { "domname",
-      &main_domname, 0,
+      &main_domname, 0, 0,
       "Convert a domain id to domain name",
       "<DomainId>",
     },
     { "rename",
-      &main_rename, 0,
+      &main_rename, 0, 1,
       "Rename a domain",
       "<Domain> <NewDomainName>",
     },
     { "trigger",
-      &main_trigger, 0,
+      &main_trigger, 0, 1,
       "Send a trigger to a domain",
       "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
     },
     { "sysrq",
-      &main_sysrq, 0,
+      &main_sysrq, 0, 1,
       "Send a sysrq to a domain",
       "<Domain> <letter>",
     },
     { "debug-keys",
-      &main_debug_keys, 0,
+      &main_debug_keys, 0, 1,
       "Send debug keys to Xen",
       "<Keys>",
     },
     { "dmesg",
-      &main_dmesg, 0,
+      &main_dmesg, 0, 0,
       "Read and/or clear dmesg buffer",
       "[-c]",
       "  -c                        Clear dmesg buffer as well as printing it",
     },
     { "top",
-      &main_top, 0,
+      &main_top, 0, 0,
       "Monitor a host and the domains in real time",
       "",
     },
     { "network-attach",
-      &main_networkattach, 1,
+      &main_networkattach, 1, 1,
       "Create a new virtual network device",
       "<Domain> [type=<type>] [mac=<mac>] [bridge=<bridge>] "
       "[ip=<ip>] [script=<script>] [backend=<BackDomain>] [vifname=<name>] "
       "[rate=<rate>] [model=<model>] [accel=<accel>]",
     },
     { "network-list",
-      &main_networklist, 0,
+      &main_networklist, 0, 0,
       "List virtual network interfaces for a domain",
       "<Domain(s)>",
     },
     { "network-detach",
-      &main_networkdetach, 0,
+      &main_networkdetach, 0, 1,
       "Destroy a domain's virtual network device",
       "<Domain> <DevId|mac>",
     },
     { "block-attach",
-      &main_blockattach, 1,
+      &main_blockattach, 1, 1,
       "Create a new virtual block device",
       "<Domain> <disk-spec-component(s)>...",
     },
     { "block-list",
-      &main_blocklist, 0,
+      &main_blocklist, 0, 0,
       "List virtual block devices for a domain",
       "<Domain(s)>",
     },
     { "block-detach",
-      &main_blockdetach, 0,
+      &main_blockdetach, 0, 1,
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
     { "uptime",
-      &main_uptime, 0,
+      &main_uptime, 0, 0,
       "Print uptime for all/some domains",
       "[-s] [Domain]",
     },
     { "tmem-list",
-      &main_tmem_list, 0,
+      &main_tmem_list, 0, 0,
       "List tmem pools",
       "[-l] [<Domain>|-a]",
       "  -l                             List tmem stats",
     },
     { "tmem-freeze",
-      &main_tmem_freeze, 0,
+      &main_tmem_freeze, 0, 1,
       "Freeze tmem pools",
       "[<Domain>|-a]",
       "  -a                             Freeze all tmem",
     },
     { "tmem-destroy",
-      &main_tmem_destroy, 0,
+      &main_tmem_destroy, 0, 1,
       "Destroy tmem pools",
       "[<Domain>|-a]",
       "  -a                             Destroy all tmem",
     },
     { "tmem-thaw",
-      &main_tmem_thaw, 0,
+      &main_tmem_thaw, 0, 1,
       "Thaw tmem pools",
       "[<Domain>|-a]",
       "  -a                             Thaw all tmem",
     },
     { "tmem-set",
-      &main_tmem_set, 0,
+      &main_tmem_set, 0, 1,
       "Change tmem settings",
       "[<Domain>|-a] [-w[=WEIGHT]|-c[=CAP]|-p[=COMPRESS]]",
       "  -a                             Operate on all tmem\n"
@@ -358,7 +358,7 @@ struct cmd_spec cmd_table[] = {
       "  -p COMPRESS                    Compress (int)",
     },
     { "tmem-shared-auth",
-      &main_tmem_shared_auth, 0,
+      &main_tmem_shared_auth, 0, 1,
       "De/authenticate shared tmem pool",
       "[<Domain>|-a] [-u[=UUID] [-A[=AUTH]",
       "  -a                             Authenticate for all tmem pools\n"
@@ -367,12 +367,12 @@ struct cmd_spec cmd_table[] = {
       "  -A AUTH                        0=auth,1=deauth",
     },
     { "tmem-freeable",
-      &main_tmem_freeable, 0,
+      &main_tmem_freeable, 0, 0,
       "Get information about how much freeable memory (MB) is in-use by tmem",
       "",
     },
     { "cpupool-create",
-      &main_cpupoolcreate, 1,
+      &main_cpupoolcreate, 1, 1,
       "Create a CPU pool based an ConfigFile",
       "[options] <ConfigFile> [vars]",
       "-h, --help                   Print this help.\n"
@@ -381,53 +381,53 @@ struct cmd_spec cmd_table[] = {
       "                              (deprecated in favour of global -N option)."
     },
     { "cpupool-list",
-      &main_cpupoollist, 0,
+      &main_cpupoollist, 0, 0,
       "List CPU pools on host",
       "[-c|--cpus] [<CPU Pool>]",
       "-c, --cpus                     Output list of CPUs used by a pool"
     },
     { "cpupool-destroy",
-      &main_cpupooldestroy, 0,
+      &main_cpupooldestroy, 0, 1,
       "Deactivates a CPU pool",
       "<CPU Pool>",
     },
     { "cpupool-rename",
-      &main_cpupoolrename, 0,
+      &main_cpupoolrename, 0, 1,
       "Renames a CPU pool",
       "<CPU Pool> <new name>",
     },
     { "cpupool-cpu-add",
-      &main_cpupoolcpuadd, 0,
+      &main_cpupoolcpuadd, 0, 1,
       "Adds a CPU to a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-cpu-remove",
-      &main_cpupoolcpuremove, 0,
+      &main_cpupoolcpuremove, 0, 1,
       "Removes a CPU from a CPU pool",
       "<CPU Pool> <CPU nr>|node:<node nr>",
     },
     { "cpupool-migrate",
-      &main_cpupoolmigrate, 0,
+      &main_cpupoolmigrate, 0, 1,
       "Moves a domain into a CPU pool",
       "<Domain> <CPU Pool>",
     },
     { "cpupool-numa-split",
-      &main_cpupoolnumasplit, 0,
+      &main_cpupoolnumasplit, 0, 1,
       "Splits up the machine into one CPU pool per NUMA node",
       "",
     },
     { "getenforce",
-      &main_getenforce, 0,
+      &main_getenforce, 0, 0,
       "Returns the current enforcing mode of the Flask Xen security module",
       "",
     },
     { "setenforce",
-      &main_setenforce, 0,
+      &main_setenforce, 0, 1,
       "Sets the current enforcing mode of the Flask Xen security module",
       "<1|0|Enforcing|Permissive>",
     },
     { "loadpolicy",
-      &main_loadpolicy, 0,
+      &main_loadpolicy, 0, 1,
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:16:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:16:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0CP-0006xx-6O; Wed, 25 Apr 2012 11:15:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN0CN-0006xr-Ol
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:15:51 +0000
Received: from [85.158.143.99:11077] by server-3.bemta-4.messagelabs.com id
	F3/D6-05853-7ECD79F4; Wed, 25 Apr 2012 11:15:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335352550!25172067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28609 invoked from network); 25 Apr 2012 11:15:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:15:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12129194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:15:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 12:15:50 +0100
Date: Wed, 25 Apr 2012 12:21:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Christoph Hellwig <hch@lst.de>
In-Reply-To: <20120425102024.GA19800@lst.de>
Message-ID: <alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Christoph Hellwig wrote:
> On Wed, Apr 25, 2012 at 10:02:45AM +0100, Ian Campbell wrote:
> > The blkif spec was recently much improved, you can find it at
> > http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
> > 
> > TBH I'm not sure it actually answers your questions wrt
> > BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
> > improving it.
> 
> That description in there is overly simple, and does not match any of the
> implementations known to me on either end.

That is true, in fact I couldn't figure out what I had to implement just
reading the comment. So I went through the blkback code and tried to
understand what I had to do, but I got it wrong.

Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
is supposed to have the same semantics as REQ_FLUSH, that implies a
preflush if nr_segments > 0, not a postflush like I did.

Konrad, can you please confirm this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:16:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:16:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0CP-0006xx-6O; Wed, 25 Apr 2012 11:15:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN0CN-0006xr-Ol
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:15:51 +0000
Received: from [85.158.143.99:11077] by server-3.bemta-4.messagelabs.com id
	F3/D6-05853-7ECD79F4; Wed, 25 Apr 2012 11:15:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335352550!25172067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28609 invoked from network); 25 Apr 2012 11:15:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:15:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12129194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:15:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 12:15:50 +0100
Date: Wed, 25 Apr 2012 12:21:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Christoph Hellwig <hch@lst.de>
In-Reply-To: <20120425102024.GA19800@lst.de>
Message-ID: <alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Christoph Hellwig wrote:
> On Wed, Apr 25, 2012 at 10:02:45AM +0100, Ian Campbell wrote:
> > The blkif spec was recently much improved, you can find it at
> > http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
> > 
> > TBH I'm not sure it actually answers your questions wrt
> > BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
> > improving it.
> 
> That description in there is overly simple, and does not match any of the
> implementations known to me on either end.

That is true, in fact I couldn't figure out what I had to implement just
reading the comment. So I went through the blkback code and tried to
understand what I had to do, but I got it wrong.

Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
is supposed to have the same semantics as REQ_FLUSH, that implies a
preflush if nr_segments > 0, not a postflush like I did.

Konrad, can you please confirm this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:17:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0E7-000735-M2; Wed, 25 Apr 2012 11:17:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN0E6-00072z-W4
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:17:39 +0000
Received: from [193.109.254.147:45694] by server-4.bemta-14.messagelabs.com id
	63/8B-11570-25DD79F4; Wed, 25 Apr 2012 11:17:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335352657!6236483!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6430 invoked from network); 25 Apr 2012 11:17:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12129225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:17:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:17:37 +0100
Message-ID: <1335352655.28015.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:17:35 +0100
In-Reply-To: <alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
	<alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Christoph Hellwig <hch@lst.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 12:21 +0100, Stefano Stabellini wrote:
> On Wed, 25 Apr 2012, Christoph Hellwig wrote:
> > On Wed, Apr 25, 2012 at 10:02:45AM +0100, Ian Campbell wrote:
> > > The blkif spec was recently much improved, you can find it at
> > > http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
> > > 
> > > TBH I'm not sure it actually answers your questions wrt
> > > BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
> > > improving it.
> > 
> > That description in there is overly simple, and does not match any of the
> > implementations known to me on either end.
> 
> That is true, in fact I couldn't figure out what I had to implement just
> reading the comment. So I went through the blkback code and tried to
> understand what I had to do, but I got it wrong.
> 
> Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
> is supposed to have the same semantics as REQ_FLUSH, that implies a
> preflush if nr_segments > 0, not a postflush like I did.
> 
> Konrad, can you please confirm this?

... and then provide a patch to blkif.h.

Thanks,

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:17:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0E7-000735-M2; Wed, 25 Apr 2012 11:17:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN0E6-00072z-W4
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:17:39 +0000
Received: from [193.109.254.147:45694] by server-4.bemta-14.messagelabs.com id
	63/8B-11570-25DD79F4; Wed, 25 Apr 2012 11:17:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335352657!6236483!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6430 invoked from network); 25 Apr 2012 11:17:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12129225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:17:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:17:37 +0100
Message-ID: <1335352655.28015.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:17:35 +0100
In-Reply-To: <alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
	<alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Christoph Hellwig <hch@lst.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 12:21 +0100, Stefano Stabellini wrote:
> On Wed, 25 Apr 2012, Christoph Hellwig wrote:
> > On Wed, Apr 25, 2012 at 10:02:45AM +0100, Ian Campbell wrote:
> > > The blkif spec was recently much improved, you can find it at
> > > http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
> > > 
> > > TBH I'm not sure it actually answers your questions wrt
> > > BLKIF_OP_FLUSH_DISKCACHE, if not please let us know and we can see about
> > > improving it.
> > 
> > That description in there is overly simple, and does not match any of the
> > implementations known to me on either end.
> 
> That is true, in fact I couldn't figure out what I had to implement just
> reading the comment. So I went through the blkback code and tried to
> understand what I had to do, but I got it wrong.
> 
> Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
> is supposed to have the same semantics as REQ_FLUSH, that implies a
> preflush if nr_segments > 0, not a postflush like I did.
> 
> Konrad, can you please confirm this?

... and then provide a patch to blkif.h.

Thanks,

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:19:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0Fg-00079b-5g; Wed, 25 Apr 2012 11:19:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN0Ff-00079T-Hg
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:19:15 +0000
Received: from [85.158.138.51:5567] by server-6.bemta-3.messagelabs.com id
	C1/2C-05145-2BDD79F4; Wed, 25 Apr 2012 11:19:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335352753!23738932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13606 invoked from network); 25 Apr 2012 11:19:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:19:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12129253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:19:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:19:13 +0100
Message-ID: <1335352752.28015.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 12:19:12 +0100
In-Reply-To: <1334928211-29856-5-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 14:23 +0100, Roger Pau Monne wrote:
> 
>  * Added fancy functions to fetch tap and vif names, now the prefix of
> the tap
>    device has been saved in a constant, called TAP_DEVICE_PREFIX.

You missed the device name construction in
libxl__build_device_model_args_*.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:19:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0Fg-00079b-5g; Wed, 25 Apr 2012 11:19:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN0Ff-00079T-Hg
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:19:15 +0000
Received: from [85.158.138.51:5567] by server-6.bemta-3.messagelabs.com id
	C1/2C-05145-2BDD79F4; Wed, 25 Apr 2012 11:19:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335352753!23738932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13606 invoked from network); 25 Apr 2012 11:19:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:19:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12129253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:19:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 12:19:13 +0100
Message-ID: <1335352752.28015.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 12:19:12 +0100
In-Reply-To: <1334928211-29856-5-git-send-email-roger.pau@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-20 at 14:23 +0100, Roger Pau Monne wrote:
> 
>  * Added fancy functions to fetch tap and vif names, now the prefix of
> the tap
>    device has been saved in a constant, called TAP_DEVICE_PREFIX.

You missed the device name construction in
libxl__build_device_model_args_*.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0Jt-0007O9-TZ; Wed, 25 Apr 2012 11:23:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <hch@lst.de>)
	id 1SN0Js-0007O3-SL
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:23:36 +0000
Received: from [193.109.254.147:52511] by server-7.bemta-14.messagelabs.com id
	9F/A1-01627-8BED79F4; Wed, 25 Apr 2012 11:23:36 +0000
X-Env-Sender: hch@lst.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335353015!6255032!1
X-Originating-IP: [213.95.11.211]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29741 invoked from network); 25 Apr 2012 11:23:35 -0000
Received: from verein.lst.de (HELO newverein.lst.de) (213.95.11.211)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 11:23:35 -0000
Received: by newverein.lst.de (Postfix, from userid 2407)
	id 31B8713FBA; Wed, 25 Apr 2012 13:23:35 +0200 (CEST)
Date: Wed, 25 Apr 2012 13:23:35 +0200
From: Christoph Hellwig <hch@lst.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120425112335.GA20868@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
	<alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:
	implement	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote:
> That is true, in fact I couldn't figure out what I had to implement just
> reading the comment. So I went through the blkback code and tried to
> understand what I had to do, but I got it wrong.
> 
> Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
> is supposed to have the same semantics as REQ_FLUSH, that implies a
> preflush if nr_segments > 0, not a postflush like I did.

It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA
into BLKIF_OP_FLUSH_DISKCACHE.

REQ_FLUSH either is a pre flush or a pure flush without a data transfer,
and REQ_FUA is a post flush.  So to get the proper semantics you'll have
to do both, _and_ sequence it so that no operation starts before the
previous one finished.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0Jt-0007O9-TZ; Wed, 25 Apr 2012 11:23:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <hch@lst.de>)
	id 1SN0Js-0007O3-SL
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:23:36 +0000
Received: from [193.109.254.147:52511] by server-7.bemta-14.messagelabs.com id
	9F/A1-01627-8BED79F4; Wed, 25 Apr 2012 11:23:36 +0000
X-Env-Sender: hch@lst.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335353015!6255032!1
X-Originating-IP: [213.95.11.211]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29741 invoked from network); 25 Apr 2012 11:23:35 -0000
Received: from verein.lst.de (HELO newverein.lst.de) (213.95.11.211)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 11:23:35 -0000
Received: by newverein.lst.de (Postfix, from userid 2407)
	id 31B8713FBA; Wed, 25 Apr 2012 13:23:35 +0200 (CEST)
Date: Wed, 25 Apr 2012 13:23:35 +0200
From: Christoph Hellwig <hch@lst.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120425112335.GA20868@lst.de>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
	<alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk:
	implement	BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote:
> That is true, in fact I couldn't figure out what I had to implement just
> reading the comment. So I went through the blkback code and tried to
> understand what I had to do, but I got it wrong.
> 
> Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
> is supposed to have the same semantics as REQ_FLUSH, that implies a
> preflush if nr_segments > 0, not a postflush like I did.

It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA
into BLKIF_OP_FLUSH_DISKCACHE.

REQ_FLUSH either is a pre flush or a pure flush without a data transfer,
and REQ_FUA is a post flush.  So to get the proper semantics you'll have
to do both, _and_ sequence it so that no operation starts before the
previous one finished.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:36:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0Vn-0007YM-8x; Wed, 25 Apr 2012 11:35:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN0Vm-0007YH-4s
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:35:54 +0000
Received: from [85.158.138.51:14305] by server-10.bemta-3.messagelabs.com id
	60/CD-29478-991E79F4; Wed, 25 Apr 2012 11:35:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335353751!15786791!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9362 invoked from network); 25 Apr 2012 11:35:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:35:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191968546"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:35:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:35:51 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN0L8-000806-Sg;
	Wed, 25 Apr 2012 12:24:54 +0100
Message-ID: <4F97DF0A.3030904@citrix.com>
Date: Wed, 25 Apr 2012 12:24:58 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
	<1335352752.28015.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335352752.28015.36.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBGcmksIDIwMTItMDQtMjAgYXQgMTQ6MjMgKzAx
MDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gICAqIEFkZGVkIGZhbmN5IGZ1bmN0aW9ucyB0
byBmZXRjaCB0YXAgYW5kIHZpZiBuYW1lcywgbm93IHRoZSBwcmVmaXggb2YKPj4gdGhlIHRhcAo+
PiAgICAgZGV2aWNlIGhhcyBiZWVuIHNhdmVkIGluIGEgY29uc3RhbnQsIGNhbGxlZCBUQVBfREVW
SUNFX1BSRUZJWC4KPgo+IFlvdSBtaXNzZWQgdGhlIGRldmljZSBuYW1lIGNvbnN0cnVjdGlvbiBp
bgo+IGxpYnhsX19idWlsZF9kZXZpY2VfbW9kZWxfYXJnc18qLgoKRGlkbid0IHlvdSBoYXZlIHRo
YXQgb24geW91ciBwYXRjaD8gQW55d2F5LCBwbGVhc2UgdGFrZSB0aGlzIGZ1bmN0aW9ucyAKYW5k
IG1lcmdlIHRoZW0gd2l0aCB5b3VyIG93biBzZXJpZXMvcGF0Y2gsIHRoaXMgaXMgYSBtZXNzLgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:36:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0Vn-0007YM-8x; Wed, 25 Apr 2012 11:35:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN0Vm-0007YH-4s
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:35:54 +0000
Received: from [85.158.138.51:14305] by server-10.bemta-3.messagelabs.com id
	60/CD-29478-991E79F4; Wed, 25 Apr 2012 11:35:53 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335353751!15786791!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9362 invoked from network); 25 Apr 2012 11:35:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:35:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191968546"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:35:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:35:51 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN0L8-000806-Sg;
	Wed, 25 Apr 2012 12:24:54 +0100
Message-ID: <4F97DF0A.3030904@citrix.com>
Date: Wed, 25 Apr 2012 12:24:58 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-5-git-send-email-roger.pau@citrix.com>
	<1335352752.28015.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335352752.28015.36.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 4/5] libxl: call hotplug scripts from
 libxl for vif
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBGcmksIDIwMTItMDQtMjAgYXQgMTQ6MjMgKzAx
MDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gICAqIEFkZGVkIGZhbmN5IGZ1bmN0aW9ucyB0
byBmZXRjaCB0YXAgYW5kIHZpZiBuYW1lcywgbm93IHRoZSBwcmVmaXggb2YKPj4gdGhlIHRhcAo+
PiAgICAgZGV2aWNlIGhhcyBiZWVuIHNhdmVkIGluIGEgY29uc3RhbnQsIGNhbGxlZCBUQVBfREVW
SUNFX1BSRUZJWC4KPgo+IFlvdSBtaXNzZWQgdGhlIGRldmljZSBuYW1lIGNvbnN0cnVjdGlvbiBp
bgo+IGxpYnhsX19idWlsZF9kZXZpY2VfbW9kZWxfYXJnc18qLgoKRGlkbid0IHlvdSBoYXZlIHRo
YXQgb24geW91ciBwYXRjaD8gQW55d2F5LCBwbGVhc2UgdGFrZSB0aGlzIGZ1bmN0aW9ucyAKYW5k
IG1lcmdlIHRoZW0gd2l0aCB5b3VyIG93biBzZXJpZXMvcGF0Y2gsIHRoaXMgaXMgYSBtZXNzLgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:42:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0c8-00082e-Rc; Wed, 25 Apr 2012 11:42:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN0c7-00082I-Sv
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:42:28 +0000
Received: from [85.158.138.51:57859] by server-4.bemta-3.messagelabs.com id
	0F/28-15341-323E79F4; Wed, 25 Apr 2012 11:42:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335354144!23632222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29537 invoked from network); 25 Apr 2012 11:42:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:42:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191969276"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:42:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:42:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN0c3-0008Uz-Nw;
	Wed, 25 Apr 2012 12:42:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 12:42:25 +0100
Message-ID: <1335354146-44894-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v4 1/2] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Changes since v2:

 * Remove non related indentation changes.

Changes since v1:

 * Indentation fixes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8cf9d9d..27483e5 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -218,9 +218,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
+                                      "script=%s,downscript=%s",
+                                      vifs[i].devid, ifname, vifs[i].bridge,
+                                      libxl_tapif_script(gc),
+                                      libxl_tapif_script(gc)),
+                                  NULL);
                 ioemu_vifs++;
             }
         }
@@ -462,10 +467,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].model, vifs[i].devid,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
-                flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
-                                                vifs[i].devid, ifname,
-                                                libxl_tapif_script(gc)));
+                flexarray_append(dm_args, libxl__sprintf(gc,
+                                          "type=tap,id=net%d,ifname=%s,"
+                                          "script=%s,downscript=%s",
+                                          vifs[i].devid, ifname,
+                                          libxl_tapif_script(gc),
+                                          libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
         }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:42:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0c8-00082e-Rc; Wed, 25 Apr 2012 11:42:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN0c7-00082I-Sv
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:42:28 +0000
Received: from [85.158.138.51:57859] by server-4.bemta-3.messagelabs.com id
	0F/28-15341-323E79F4; Wed, 25 Apr 2012 11:42:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335354144!23632222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29537 invoked from network); 25 Apr 2012 11:42:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:42:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191969276"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:42:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:42:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN0c3-0008Uz-Nw;
	Wed, 25 Apr 2012 12:42:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 12:42:25 +0100
Message-ID: <1335354146-44894-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v4 1/2] libxl: add "downscript=no" to Qemu call
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we only pass script=no to Qemu, to avoid calling any scripts when
attaching a tap interface, but we should also pass downscript=no to avoid Qemu
trying to execute a script when disconnecting the interface. This prevents the
following harmless error message:

/etc/qemu-ifdown: could not launch network script

Changes since v2:

 * Remove non related indentation changes.

Changes since v1:

 * Indentation fixes.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8cf9d9d..27483e5 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -218,9 +218,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
-                                "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s",
-                                                       vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)),
-                                NULL);
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
+                                      "script=%s,downscript=%s",
+                                      vifs[i].devid, ifname, vifs[i].bridge,
+                                      libxl_tapif_script(gc),
+                                      libxl_tapif_script(gc)),
+                                  NULL);
                 ioemu_vifs++;
             }
         }
@@ -462,10 +467,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                 vifs[i].model, vifs[i].devid,
                                                 vifs[i].devid, smac));
                 flexarray_append(dm_args, "-netdev");
-                flexarray_append(dm_args,
-                   libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s",
-                                                vifs[i].devid, ifname,
-                                                libxl_tapif_script(gc)));
+                flexarray_append(dm_args, libxl__sprintf(gc,
+                                          "type=tap,id=net%d,ifname=%s,"
+                                          "script=%s,downscript=%s",
+                                          vifs[i].devid, ifname,
+                                          libxl_tapif_script(gc),
+                                          libxl_tapif_script(gc)));
                 ioemu_vifs++;
             }
         }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:42:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0cA-00082w-8S; Wed, 25 Apr 2012 11:42:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN0c8-00082b-Og
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:42:28 +0000
Received: from [85.158.138.51:51499] by server-6.bemta-3.messagelabs.com id
	E7/5A-05145-323E79F4; Wed, 25 Apr 2012 11:42:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335354144!23632222!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29584 invoked from network); 25 Apr 2012 11:42:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191969277"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:42:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:42:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN0c3-0008Uz-Oa;
	Wed, 25 Apr 2012 12:42:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 12:42:26 +0100
Message-ID: <1335354146-44894-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1335354146-44894-1-git-send-email-roger.pau@citrix.com>
References: <1335354146-44894-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v4 2/2] libxl: fix indentation in libxl_dm.c for
	qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fixed indentation on Qemu argument construction for network devices.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 27483e5..35a2ddc 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,8 +216,10 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "nic,vlan=%d,macaddr=%s,model=%s",
+                                      vifs[i].devid, smac, vifs[i].model),
                                   "-net",
                                   libxl__sprintf(gc,
                                       "tap,vlan=%d,ifname=%s,bridge=%s,"
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:42:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0cA-00082w-8S; Wed, 25 Apr 2012 11:42:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN0c8-00082b-Og
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 11:42:28 +0000
Received: from [85.158.138.51:51499] by server-6.bemta-3.messagelabs.com id
	E7/5A-05145-323E79F4; Wed, 25 Apr 2012 11:42:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335354144!23632222!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29584 invoked from network); 25 Apr 2012 11:42:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330923600"; d="scan'208";a="191969277"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 07:42:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 07:42:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN0c3-0008Uz-Oa;
	Wed, 25 Apr 2012 12:42:23 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 12:42:26 +0100
Message-ID: <1335354146-44894-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1335354146-44894-1-git-send-email-roger.pau@citrix.com>
References: <1335354146-44894-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v4 2/2] libxl: fix indentation in libxl_dm.c for
	qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fixed indentation on Qemu argument construction for network devices.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 27483e5..35a2ddc 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -216,8 +216,10 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                 else
                     ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
-                                "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
-                                                       vifs[i].devid, smac, vifs[i].model),
+                                  "-net",
+                                  libxl__sprintf(gc,
+                                      "nic,vlan=%d,macaddr=%s,model=%s",
+                                      vifs[i].devid, smac, vifs[i].model),
                                   "-net",
                                   libxl__sprintf(gc,
                                       "tap,vlan=%d,ifname=%s,bridge=%s,"
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:59:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0sd-0000aY-64; Wed, 25 Apr 2012 11:59:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN0sb-0000aT-Nf
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:59:30 +0000
Received: from [85.158.143.99:4587] by server-2.bemta-4.messagelabs.com id
	A1/52-17550-F17E79F4; Wed, 25 Apr 2012 11:59:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335355167!24637529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10427 invoked from network); 25 Apr 2012 11:59:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:59:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12130200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:59:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 12:59:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SN0sY-0005mS-JD;
	Wed, 25 Apr 2012 11:59:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SN0sY-0007ia-Gx;
	Wed, 25 Apr 2012 12:59:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12748-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:59:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12748: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12748 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12748/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12743

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8fddae41cd1b
baseline version:
 xen                  1a8b47d80157

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 11:59:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 11:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN0sd-0000aY-64; Wed, 25 Apr 2012 11:59:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN0sb-0000aT-Nf
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 11:59:30 +0000
Received: from [85.158.143.99:4587] by server-2.bemta-4.messagelabs.com id
	A1/52-17550-F17E79F4; Wed, 25 Apr 2012 11:59:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335355167!24637529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10427 invoked from network); 25 Apr 2012 11:59:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 11:59:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="12130200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:59:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 12:59:26 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SN0sY-0005mS-JD;
	Wed, 25 Apr 2012 11:59:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SN0sY-0007ia-Gx;
	Wed, 25 Apr 2012 12:59:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12748-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 12:59:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12748: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12748 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12748/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 12743

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8fddae41cd1b
baseline version:
 xen                  1a8b47d80157

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1NP-0001XK-R2; Wed, 25 Apr 2012 12:31:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1NO-0001XF-5L
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 12:31:18 +0000
Received: from [85.158.143.99:17638] by server-3.bemta-4.messagelabs.com id
	A6/A6-05853-59EE79F4; Wed, 25 Apr 2012 12:31:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335357076!24296687!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4636 invoked from network); 25 Apr 2012 12:31:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:31:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1NL-000E6v-Ig; Wed, 25 Apr 2012 12:31:15 +0000
Date: Wed, 25 Apr 2012 13:31:15 +0100
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20120425123115.GC51354@ocelot.phlegethon.org>
References: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Todd Deshane <todd.deshane@xen.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 23:36 -0500 on 24 Apr (1335310591), Srujan Kotikela wrote:
> Hi All,
> 
> I just saw  http://vimeo.com/38636349 by todd. Nice plans for securing xen.
> 
> May I know who is leading/implementing XOAR ideas and Dom0 disaggregation?

I believe the XCP/xapi developers are looking into implementing it.  You
could also look at Qubes OS, which uses a lot of similar ideas in a
desktop setting.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1NP-0001XK-R2; Wed, 25 Apr 2012 12:31:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1NO-0001XF-5L
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 12:31:18 +0000
Received: from [85.158.143.99:17638] by server-3.bemta-4.messagelabs.com id
	A6/A6-05853-59EE79F4; Wed, 25 Apr 2012 12:31:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335357076!24296687!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4636 invoked from network); 25 Apr 2012 12:31:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:31:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1NL-000E6v-Ig; Wed, 25 Apr 2012 12:31:15 +0000
Date: Wed, 25 Apr 2012 13:31:15 +0100
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20120425123115.GC51354@ocelot.phlegethon.org>
References: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Todd Deshane <todd.deshane@xen.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 23:36 -0500 on 24 Apr (1335310591), Srujan Kotikela wrote:
> Hi All,
> 
> I just saw  http://vimeo.com/38636349 by todd. Nice plans for securing xen.
> 
> May I know who is leading/implementing XOAR ideas and Dom0 disaggregation?

I believe the XCP/xapi developers are looking into implementing it.  You
could also look at Qubes OS, which uses a lot of similar ideas in a
desktop setting.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:42:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1Xl-00022n-RD; Wed, 25 Apr 2012 12:42:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1Xk-00022i-PA
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:42:00 +0000
Received: from [193.109.254.147:3321] by server-2.bemta-14.messagelabs.com id
	00/A6-19409-711F79F4; Wed, 25 Apr 2012 12:41:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335357719!6301569!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29911 invoked from network); 25 Apr 2012 12:41:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:41:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1XX-000E9F-LM; Wed, 25 Apr 2012 12:41:47 +0000
Date: Wed, 25 Apr 2012 13:41:47 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425124147.GD51354@ocelot.phlegethon.org>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
	<51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mem_sharing: Rectify test for
	"empty" physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:20 -0400 on 24 Apr (1335280819), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  7 ++++---
>  xen/include/asm-x86/p2m.h     |  8 ++++++++
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 5be9a05f17fd -r 51646b89b182 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
>      if ( spage->sharing->handle != sh )
>          goto err_unlock;
>  
> -    /* Make sure the target page is a hole in the physmap */
> -    if ( mfn_valid(cmfn) ||
> -         (!(p2m_is_ram(cmfn_type))) )
> +    /* Make sure the target page is a hole in the physmap. These are typically
> +     * p2m_mmio_dm, but also accept p2m_invalid and paged out pages. See the
> +     * definition of p2m_is_hole in p2m.h. */
> +    if ( !p2m_is_hole(cmfn_type) || mfn_valid(cmfn) )

Hmm.  Is the mfn_valid() to handle p2m_ram_paging_in entries sometimes
having an MFN and sometimes not?  I think it would be nicer to either
always replace paging-in pages or never do it.  In any case, it's bogus
to test mfn_valid() for any of the other types.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:42:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1Xl-00022n-RD; Wed, 25 Apr 2012 12:42:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1Xk-00022i-PA
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:42:00 +0000
Received: from [193.109.254.147:3321] by server-2.bemta-14.messagelabs.com id
	00/A6-19409-711F79F4; Wed, 25 Apr 2012 12:41:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335357719!6301569!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29911 invoked from network); 25 Apr 2012 12:41:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:41:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1XX-000E9F-LM; Wed, 25 Apr 2012 12:41:47 +0000
Date: Wed, 25 Apr 2012 13:41:47 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425124147.GD51354@ocelot.phlegethon.org>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
	<51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mem_sharing: Rectify test for
	"empty" physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:20 -0400 on 24 Apr (1335280819), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  7 ++++---
>  xen/include/asm-x86/p2m.h     |  8 ++++++++
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 5be9a05f17fd -r 51646b89b182 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
>      if ( spage->sharing->handle != sh )
>          goto err_unlock;
>  
> -    /* Make sure the target page is a hole in the physmap */
> -    if ( mfn_valid(cmfn) ||
> -         (!(p2m_is_ram(cmfn_type))) )
> +    /* Make sure the target page is a hole in the physmap. These are typically
> +     * p2m_mmio_dm, but also accept p2m_invalid and paged out pages. See the
> +     * definition of p2m_is_hole in p2m.h. */
> +    if ( !p2m_is_hole(cmfn_type) || mfn_valid(cmfn) )

Hmm.  Is the mfn_valid() to handle p2m_ram_paging_in entries sometimes
having an MFN and sometimes not?  I think it would be nicer to either
always replace paging-in pages or never do it.  In any case, it's bogus
to test mfn_valid() for any of the other types.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1ga-0002Mi-Vw; Wed, 25 Apr 2012 12:51:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1gZ-0002Md-7y
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:51:07 +0000
Received: from [193.109.254.147:57230] by server-5.bemta-14.messagelabs.com id
	B9/F9-30733-A33F79F4; Wed, 25 Apr 2012 12:51:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335358265!6255083!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13573 invoked from network); 25 Apr 2012 12:51:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:51:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1gW-000EBL-1L; Wed, 25 Apr 2012 12:51:04 +0000
Date: Wed, 25 Apr 2012 13:51:03 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425125103.GE51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm: Relieve contention for p2m
	lock in gva_to_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:34 -0400 on 24 Apr (1335281651), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/hap/guest_walk.c |  6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> 
> We don't need to hold the p2m lock for the duration of the guest walk. We need
> to ensure livenes of the top level page.

I'm not sure I want to start taking these s/gfn-lock/get-page/ changes
piecemeal without a clear understanding of why the gfn-locking is not
needed.  My understanding was that

 - get_page protects against the page being freed and reused.
 - gfn-lock protects against the GFN being reused, or the page 
   being reused within the VM. 

Are there some cases where we only care about the first of these and
some where we care about both?  In other words, can we replace the
gfn-locking everywhere with get_page/put_page (i.e. get rid of put_gfn)?

Also:

> @@ -85,13 +86,16 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>  
>      /* Map the top-level table and call the tree-walker */
>      ASSERT(mfn_valid(mfn_x(top_mfn)));
> +    top_page = mfn_to_page(mfn_x(top_mfn));
> +    ASSERT(get_page(top_page, p2m->domain));

ASSERT(foo) is compiled out on non-debug builds, so that's definitely
not what you want. 

I personally dislike this idiom with BUG_ON() as well, because even
though BUG_ON(some side-effecting statement) may be correct, my eye
tends to skip over it when skimming code.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1ga-0002Mi-Vw; Wed, 25 Apr 2012 12:51:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1gZ-0002Md-7y
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:51:07 +0000
Received: from [193.109.254.147:57230] by server-5.bemta-14.messagelabs.com id
	B9/F9-30733-A33F79F4; Wed, 25 Apr 2012 12:51:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335358265!6255083!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13573 invoked from network); 25 Apr 2012 12:51:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:51:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1gW-000EBL-1L; Wed, 25 Apr 2012 12:51:04 +0000
Date: Wed, 25 Apr 2012 13:51:03 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425125103.GE51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm: Relieve contention for p2m
	lock in gva_to_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:34 -0400 on 24 Apr (1335281651), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/hap/guest_walk.c |  6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> 
> We don't need to hold the p2m lock for the duration of the guest walk. We need
> to ensure livenes of the top level page.

I'm not sure I want to start taking these s/gfn-lock/get-page/ changes
piecemeal without a clear understanding of why the gfn-locking is not
needed.  My understanding was that

 - get_page protects against the page being freed and reused.
 - gfn-lock protects against the GFN being reused, or the page 
   being reused within the VM. 

Are there some cases where we only care about the first of these and
some where we care about both?  In other words, can we replace the
gfn-locking everywhere with get_page/put_page (i.e. get rid of put_gfn)?

Also:

> @@ -85,13 +86,16 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>  
>      /* Map the top-level table and call the tree-walker */
>      ASSERT(mfn_valid(mfn_x(top_mfn)));
> +    top_page = mfn_to_page(mfn_x(top_mfn));
> +    ASSERT(get_page(top_page, p2m->domain));

ASSERT(foo) is compiled out on non-debug builds, so that's definitely
not what you want. 

I personally dislike this idiom with BUG_ON() as well, because even
though BUG_ON(some side-effecting statement) may be correct, my eye
tends to skip over it when skimming code.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:54:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1jb-0002U1-Ix; Wed, 25 Apr 2012 12:54:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1ja-0002Tu-Re
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:54:15 +0000
Received: from [193.109.254.147:47910] by server-3.bemta-14.messagelabs.com id
	AE/E6-23274-6F3F79F4; Wed, 25 Apr 2012 12:54:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335358451!6264679!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5512 invoked from network); 25 Apr 2012 12:54:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:54:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1jX-000EBj-Bj; Wed, 25 Apr 2012 12:54:11 +0000
Date: Wed, 25 Apr 2012 13:54:11 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425125411.GF51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/emulate: Relieve contention of
	p2m lock in emulation of rep movs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:34 -0400 on 24 Apr (1335281652), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c |  27 +++++++++------------------
>  1 files changed, 9 insertions(+), 18 deletions(-)
> 
> 
> get_two_gfns is used to query the source and target physical addresses of the
> emulated rep movs. It is not necessary to hold onto the two gfn's for the
> duration of the emulation: further calls down the line will do the appropriate
> unsharing or paging in, and unwind correctly on failure.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 58fd70123787 -r 2ffc676120b8 xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -714,25 +714,23 @@ static int hvmemul_rep_movs(
>      if ( rc != X86EMUL_OKAY )
>          return rc;
>  
> +    /* The query on the gfns is to establish the need for mmio. In the two mmio
> +     * cases, a proper get_gfn for the "other" gfn will be enacted, with paging in
> +     * or unsharing if necessary. In the memmove case, the gfn might change given
> +     * the bytes mov'ed, and, again, proper get_gfn's will be enacted in
> +     * __hvm_copy. */ 
>      get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
>                   current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
>                   P2M_ALLOC, &tg);
> -
> +    put_two_gfns(&tg);

If we're just going to put_ these immediately, we don't need to use
get_two_gfns().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:54:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1jb-0002U1-Ix; Wed, 25 Apr 2012 12:54:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN1ja-0002Tu-Re
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:54:15 +0000
Received: from [193.109.254.147:47910] by server-3.bemta-14.messagelabs.com id
	AE/E6-23274-6F3F79F4; Wed, 25 Apr 2012 12:54:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335358451!6264679!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5512 invoked from network); 25 Apr 2012 12:54:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 12:54:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN1jX-000EBj-Bj; Wed, 25 Apr 2012 12:54:11 +0000
Date: Wed, 25 Apr 2012 13:54:11 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425125411.GF51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/emulate: Relieve contention of
	p2m lock in emulation of rep movs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:34 -0400 on 24 Apr (1335281652), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c |  27 +++++++++------------------
>  1 files changed, 9 insertions(+), 18 deletions(-)
> 
> 
> get_two_gfns is used to query the source and target physical addresses of the
> emulated rep movs. It is not necessary to hold onto the two gfn's for the
> duration of the emulation: further calls down the line will do the appropriate
> unsharing or paging in, and unwind correctly on failure.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 58fd70123787 -r 2ffc676120b8 xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -714,25 +714,23 @@ static int hvmemul_rep_movs(
>      if ( rc != X86EMUL_OKAY )
>          return rc;
>  
> +    /* The query on the gfns is to establish the need for mmio. In the two mmio
> +     * cases, a proper get_gfn for the "other" gfn will be enacted, with paging in
> +     * or unsharing if necessary. In the memmove case, the gfn might change given
> +     * the bytes mov'ed, and, again, proper get_gfn's will be enacted in
> +     * __hvm_copy. */ 
>      get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
>                   current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
>                   P2M_ALLOC, &tg);
> -
> +    put_two_gfns(&tg);

If we're just going to put_ these immediately, we don't need to use
get_two_gfns().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:59:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1oh-0002fe-BV; Wed, 25 Apr 2012 12:59:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN1og-0002fY-3Q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:59:30 +0000
Received: from [85.158.139.83:51773] by server-3.bemta-5.messagelabs.com id
	BF/75-25237-135F79F4; Wed, 25 Apr 2012 12:59:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335358767!24906041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10638 invoked from network); 25 Apr 2012 12:59:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 12:59:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12131599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 12:58:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 13:58:58 +0100
Message-ID: <1335358736.28015.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 13:58:56 +0100
In-Reply-To: <1335348880.28015.24.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
	<1335348880.28015.24.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:14 +0100, Ian Campbell wrote:
> On Wed, 2012-04-25 at 11:11 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > > So for vifname="foo" it is a no-brainer to call the vif "foo" and the
> > > emulated tap device "foo-emu".
> > > 
> > > But what about the case where no vifname is given, in that case vif is
> > > named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
> > > changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
> > > now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?
> > 
> > I think either is fine.  While we're changing it it probably makes
> > sense to use "vif..." as indeed it is more consistent.
> 
> OK, vifX.Y and vifX.Y-emu it is...

This turned out to be a bit more complex than I was expecting, mostly
because the use of "vifname" with tap devices was already broken. I
think this does the right things with each type of device.

Roger, not sure what knock on effect this has on your series. The main
thing is likely to be that you needn't find the vifname since you
actually want the standard name not the user supplied once on most
occasions.

Ian.

8<---------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335354957 -3600
# Node ID 44fc76485f797bdd726fed4a2a7c4b06363fdb88
# Parent  a14b1dd0feeee300c37c44564381f4e8ea837c45
libxl/xend: name tap devices vifX.Y-emu

This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)

Correct the documentation for the "vifname" option which suggested it applied
to HVM tap devices only, which is not the case.

Reported by Michael Young.

Also fix the use of vifname with emulated devices. This is slightly complex.
The current hotplug scripts rely on being able to parse the "tapX.Y" (now
"vifX.Y-emu") name in order to locate the xenstore backend dir relating to the
corresponding vif. This is because we cannot inject our own environment vars
into the tap hotplug events. However this means that if the tap is initially
named with a user specified name (which will not match the expected scheme) we
fail to do anything useful with the device. So now we create the initial tap
device with the standard "vifX.Y-emu" name and the hotplug script will handle
the rename to the desired name. This is also how PV vif devices work -- they
are always created by netback with the name vifX.Y and renamed in the script.

Lastly also move libxl__device_* to a better place in the header, otherwise the
comment about evgen stuff isn't next to the associated functions (noticed jsut
because I was going to add nic_devname near to the setdefault functions)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a14b1dd0feee -r 44fc76485f79 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Wed Apr 25 10:53:52 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Wed Apr 25 12:55:57 2012 +0100
@@ -93,11 +93,14 @@ are:
 
 ### vifname
 
-This keyword is valid for HVM guest devices with `type=ioemu` only.
+Specifies the backend device name for the virtual device.
 
-Specifies the backend device name for an emulated device. The default
-is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
-is the device number.
+If the domain is an HVM domain then the associated emulated (tap)
+device will have a "-emu" suffice added.
+
+The default name for the virtual device is `vifDOMID.DEVID` where
+`DOMID` is the guest domain ID and `DEVID` is the device
+number. Likewise the default tap name is `vifDOMID.DEVID-emu`.
 
 ### script
 
diff -r a14b1dd0feee -r 44fc76485f79 tools/hotplug/Linux/vif-common.sh
--- a/tools/hotplug/Linux/vif-common.sh	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/hotplug/Linux/vif-common.sh	Wed Apr 25 12:55:57 2012 +0100
@@ -85,12 +85,23 @@ elif [ "$type_if" = tap ]; then
     : ${INTERFACE:?}
 
     # Get xenbus_path from device name.
-    # The name is built like that: "tap${domid}.${devid}".
-    dev_=${dev#tap}
+    # The name is built like that: "vif${domid}.${devid}-emu".
+    dev_=${dev#vif}
+    dev_=${dev_%-emu}
     domid=${dev_%.*}
     devid=${dev_#*.}
 
     XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid"
+    vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "")
+    if [ "$vifname" ]
+    then
+        vifname="${vifname}-emu"
+        if [ "$command" == "add" ] && ! ip link show "$vifname" >&/dev/null
+        then
+            do_or_die ip link set "$dev" name "$vifname"
+        fi
+        dev="$vifname"
+    fi
 fi
 
 ip=${ip:-}
diff -r a14b1dd0feee -r 44fc76485f79 tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Wed Apr 25 12:55:57 2012 +0100
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blkt
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff -r a14b1dd0feee -r 44fc76485f79 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Apr 25 12:55:57 2012 +0100
@@ -2095,6 +2095,21 @@ int libxl_device_nic_getinfo(libxl_ctx *
     return 0;
 }
 
+const char *libxl__device_nic_devname(libxl__gc *gc,
+                                      uint32_t domid,
+                                      uint32_t devid,
+                                      libxl_nic_type type)
+{
+    switch (type) {
+    case LIBXL_NIC_TYPE_VIF:
+        return GCSPRINTF("vif%u.%d", domid, devid);
+    case LIBXL_NIC_TYPE_IOEMU:
+        return GCSPRINTF("vif%u.%d" TAP_DEVICE_SUFFIX, domid, devid);
+    default:
+        abort();
+    }
+}
+
 /******************************************************************************/
 int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                               libxl__device_console *console,
diff -r a14b1dd0feee -r 44fc76485f79 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Apr 25 12:55:57 2012 +0100
@@ -209,12 +209,9 @@ static char ** libxl__build_device_model
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
-                char *ifname;
-                if (!vifs[i].ifname)
-                    ifname = libxl__sprintf(gc,
-                                            "tap%d.%d", domid, vifs[i].devid);
-                else
-                    ifname = vifs[i].ifname;
+                const char *ifname = libxl__device_nic_devname(gc,
+                                                domid, vifs[i].devid,
+                                                LIBXL_NIC_TYPE_IOEMU);
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
@@ -449,13 +446,9 @@ static char ** libxl__build_device_model
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
-                char *ifname;
-                if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d",
-                                            guest_domid, vifs[i].devid);
-                } else {
-                    ifname = vifs[i].ifname;
-                }
+                const char *ifname = libxl__device_nic_devname(gc,
+                                                guest_domid, vifs[i].devid,
+                                                LIBXL_NIC_TYPE_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
                    libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
diff -r a14b1dd0feee -r 44fc76485f79 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Apr 25 12:55:57 2012 +0100
@@ -83,6 +83,7 @@
 #define STUBDOM_CONSOLE_RESTORE 2
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
+#define TAP_DEVICE_SUFFIX "-emu"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -196,17 +197,6 @@ _hidden libxl__ev_xswatch *libxl__watch_
  * version of the _evdisable_FOO function; the internal one is
  * used during cleanup.
  */
-_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
-                                        libxl_domain_create_info *c_info);
-_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
-                                        libxl_domain_build_info *b_info);
-_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
-                                          libxl_device_disk *disk);
-_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
-_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
-_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
-_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
-
 struct libxl__evgen_domain_death {
     uint32_t domid;
     unsigned shutdown_reported:1, death_reported:1;
@@ -704,6 +694,21 @@ _hidden int libxl__wait_for_backend(libx
  *     All libxl API functions are expected to have arranged for this
  *     to be called before using any values within these structures.
  */
+_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_create_info *c_info);
+_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info);
+_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
+                                          libxl_device_disk *disk);
+_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
+_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
+_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
+_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
+
+_hidden const char *libxl__device_nic_devname(libxl__gc *gc,
+                                              uint32_t domid,
+                                              uint32_t devid,
+                                              libxl_nic_type type);
 
 /* Arranges that dev will be removed from its guest.  When
  * this is done, the ao will be completed.  An error
diff -r a14b1dd0feee -r 44fc76485f79 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/python/xen/xend/image.py	Wed Apr 25 12:55:57 2012 +0100
@@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler):
             ret.append("-net")
             ret.append("nic,vlan=%d,macaddr=%s,model=%s" %
                        (nics, mac, model))
-            vifname = devinfo.get('vifname')
-            if vifname:
-                vifname = "tap-" + vifname
-            else:
-                vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1)
+            vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
             ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
                        (nics, vifname, bridge))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 12:59:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 12:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1oh-0002fe-BV; Wed, 25 Apr 2012 12:59:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN1og-0002fY-3Q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 12:59:30 +0000
Received: from [85.158.139.83:51773] by server-3.bemta-5.messagelabs.com id
	BF/75-25237-135F79F4; Wed, 25 Apr 2012 12:59:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335358767!24906041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10638 invoked from network); 25 Apr 2012 12:59:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 12:59:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12131599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 12:58:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 13:58:58 +0100
Message-ID: <1335358736.28015.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 13:58:56 +0100
In-Reply-To: <1335348880.28015.24.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
	<1335348880.28015.24.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: M A Young <m.a.young@durham.ac.uk>, Roger Pau Monne <roger.pau@citrix.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 11:14 +0100, Ian Campbell wrote:
> On Wed, 2012-04-25 at 11:11 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> > > So for vifname="foo" it is a no-brainer to call the vif "foo" and the
> > > emulated tap device "foo-emu".
> > > 
> > > But what about the case where no vifname is given, in that case vif is
> > > named "vif<DOM>.<DEV>". But what to call the tap? Previously I was
> > > changing the name from tap<DOM>.<DEV> to xentap<DOM>.<DEV> but perhaps
> > > now "vif<DOM>.<DEV>-emu" makes more sense/is more consistent?
> > 
> > I think either is fine.  While we're changing it it probably makes
> > sense to use "vif..." as indeed it is more consistent.
> 
> OK, vifX.Y and vifX.Y-emu it is...

This turned out to be a bit more complex than I was expecting, mostly
because the use of "vifname" with tap devices was already broken. I
think this does the right things with each type of device.

Roger, not sure what knock on effect this has on your series. The main
thing is likely to be that you needn't find the vifname since you
actually want the standard name not the user supplied once on most
occasions.

Ian.

8<---------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1335354957 -3600
# Node ID 44fc76485f797bdd726fed4a2a7c4b06363fdb88
# Parent  a14b1dd0feeee300c37c44564381f4e8ea837c45
libxl/xend: name tap devices vifX.Y-emu

This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)

Correct the documentation for the "vifname" option which suggested it applied
to HVM tap devices only, which is not the case.

Reported by Michael Young.

Also fix the use of vifname with emulated devices. This is slightly complex.
The current hotplug scripts rely on being able to parse the "tapX.Y" (now
"vifX.Y-emu") name in order to locate the xenstore backend dir relating to the
corresponding vif. This is because we cannot inject our own environment vars
into the tap hotplug events. However this means that if the tap is initially
named with a user specified name (which will not match the expected scheme) we
fail to do anything useful with the device. So now we create the initial tap
device with the standard "vifX.Y-emu" name and the hotplug script will handle
the rename to the desired name. This is also how PV vif devices work -- they
are always created by netback with the name vifX.Y and renamed in the script.

Lastly also move libxl__device_* to a better place in the header, otherwise the
comment about evgen stuff isn't next to the associated functions (noticed jsut
because I was going to add nic_devname near to the setdefault functions)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a14b1dd0feee -r 44fc76485f79 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Wed Apr 25 10:53:52 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Wed Apr 25 12:55:57 2012 +0100
@@ -93,11 +93,14 @@ are:
 
 ### vifname
 
-This keyword is valid for HVM guest devices with `type=ioemu` only.
+Specifies the backend device name for the virtual device.
 
-Specifies the backend device name for an emulated device. The default
-is `tapDOMID.DEVID` where `DOMID` is the guest domain ID and `DEVID`
-is the device number.
+If the domain is an HVM domain then the associated emulated (tap)
+device will have a "-emu" suffice added.
+
+The default name for the virtual device is `vifDOMID.DEVID` where
+`DOMID` is the guest domain ID and `DEVID` is the device
+number. Likewise the default tap name is `vifDOMID.DEVID-emu`.
 
 ### script
 
diff -r a14b1dd0feee -r 44fc76485f79 tools/hotplug/Linux/vif-common.sh
--- a/tools/hotplug/Linux/vif-common.sh	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/hotplug/Linux/vif-common.sh	Wed Apr 25 12:55:57 2012 +0100
@@ -85,12 +85,23 @@ elif [ "$type_if" = tap ]; then
     : ${INTERFACE:?}
 
     # Get xenbus_path from device name.
-    # The name is built like that: "tap${domid}.${devid}".
-    dev_=${dev#tap}
+    # The name is built like that: "vif${domid}.${devid}-emu".
+    dev_=${dev#vif}
+    dev_=${dev_%-emu}
     domid=${dev_%.*}
     devid=${dev_#*.}
 
     XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid"
+    vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "")
+    if [ "$vifname" ]
+    then
+        vifname="${vifname}-emu"
+        if [ "$command" == "add" ] && ! ip link show "$vifname" >&/dev/null
+        then
+            do_or_die ip link set "$dev" name "$vifname"
+        fi
+        dev="$vifname"
+    fi
 fi
 
 ip=${ip:-}
diff -r a14b1dd0feee -r 44fc76485f79 tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Wed Apr 25 12:55:57 2012 +0100
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blkt
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff -r a14b1dd0feee -r 44fc76485f79 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Apr 25 12:55:57 2012 +0100
@@ -2095,6 +2095,21 @@ int libxl_device_nic_getinfo(libxl_ctx *
     return 0;
 }
 
+const char *libxl__device_nic_devname(libxl__gc *gc,
+                                      uint32_t domid,
+                                      uint32_t devid,
+                                      libxl_nic_type type)
+{
+    switch (type) {
+    case LIBXL_NIC_TYPE_VIF:
+        return GCSPRINTF("vif%u.%d", domid, devid);
+    case LIBXL_NIC_TYPE_IOEMU:
+        return GCSPRINTF("vif%u.%d" TAP_DEVICE_SUFFIX, domid, devid);
+    default:
+        abort();
+    }
+}
+
 /******************************************************************************/
 int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                               libxl__device_console *console,
diff -r a14b1dd0feee -r 44fc76485f79 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Apr 25 12:55:57 2012 +0100
@@ -209,12 +209,9 @@ static char ** libxl__build_device_model
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
-                char *ifname;
-                if (!vifs[i].ifname)
-                    ifname = libxl__sprintf(gc,
-                                            "tap%d.%d", domid, vifs[i].devid);
-                else
-                    ifname = vifs[i].ifname;
+                const char *ifname = libxl__device_nic_devname(gc,
+                                                domid, vifs[i].devid,
+                                                LIBXL_NIC_TYPE_IOEMU);
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
@@ -449,13 +446,9 @@ static char ** libxl__build_device_model
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
-                char *ifname;
-                if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d",
-                                            guest_domid, vifs[i].devid);
-                } else {
-                    ifname = vifs[i].ifname;
-                }
+                const char *ifname = libxl__device_nic_devname(gc,
+                                                guest_domid, vifs[i].devid,
+                                                LIBXL_NIC_TYPE_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
                    libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
diff -r a14b1dd0feee -r 44fc76485f79 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Apr 25 12:55:57 2012 +0100
@@ -83,6 +83,7 @@
 #define STUBDOM_CONSOLE_RESTORE 2
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
+#define TAP_DEVICE_SUFFIX "-emu"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -196,17 +197,6 @@ _hidden libxl__ev_xswatch *libxl__watch_
  * version of the _evdisable_FOO function; the internal one is
  * used during cleanup.
  */
-_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
-                                        libxl_domain_create_info *c_info);
-_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
-                                        libxl_domain_build_info *b_info);
-_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
-                                          libxl_device_disk *disk);
-_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
-_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
-_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
-_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
-
 struct libxl__evgen_domain_death {
     uint32_t domid;
     unsigned shutdown_reported:1, death_reported:1;
@@ -704,6 +694,21 @@ _hidden int libxl__wait_for_backend(libx
  *     All libxl API functions are expected to have arranged for this
  *     to be called before using any values within these structures.
  */
+_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_create_info *c_info);
+_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info);
+_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
+                                          libxl_device_disk *disk);
+_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
+_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
+_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
+_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
+
+_hidden const char *libxl__device_nic_devname(libxl__gc *gc,
+                                              uint32_t domid,
+                                              uint32_t devid,
+                                              libxl_nic_type type);
 
 /* Arranges that dev will be removed from its guest.  When
  * this is done, the ao will be completed.  An error
diff -r a14b1dd0feee -r 44fc76485f79 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Wed Apr 25 10:53:52 2012 +0100
+++ b/tools/python/xen/xend/image.py	Wed Apr 25 12:55:57 2012 +0100
@@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler):
             ret.append("-net")
             ret.append("nic,vlan=%d,macaddr=%s,model=%s" %
                        (nics, mac, model))
-            vifname = devinfo.get('vifname')
-            if vifname:
-                vifname = "tap-" + vifname
-            else:
-                vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1)
+            vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
             ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
                        (nics, vifname, bridge))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:01:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1qE-0002li-TY; Wed, 25 Apr 2012 13:01:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SN1qD-0002lc-9C
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 13:01:05 +0000
Received: from [193.109.254.147:43996] by server-9.bemta-14.messagelabs.com id
	0D/E3-05787-095F79F4; Wed, 25 Apr 2012 13:01:04 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335358861!6257017!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32041 invoked from network); 25 Apr 2012 13:01:01 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-12.tower-27.messagelabs.com with SMTP;
	25 Apr 2012 13:01:01 -0000
Received: from p5b2e257f.dip.t-dialin.net ([91.46.37.127] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SN1q8-0004V3-5B; Wed, 25 Apr 2012 13:01:00 +0000
Message-ID: <4F97F58A.8090409@canonical.com>
Date: Wed, 25 Apr 2012 15:00:58 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4
Cc: Jan Beulich <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2199221830262411281=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2199221830262411281==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigCE74410632203E6E18255326"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCE74410632203E6E18255326
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Since there have been requests about that driver to get backported into 3=
=2E2, I
was interested to find out what or how much would be gained by that.

The first system I tried was an AMD based one (8 core Opteron 6128@2GHz).=
 Which
was not very successful as the drivers bail out of the init function beca=
use the
first call to acpi_processor_register_performance() returns -ENODEV. Ther=
e is
some frequency scaling when running without Xen, so I need to do some mor=
e
debugging there.

The second system was an Intel one (4 core i7 920@2.67GHz) which was
successfully loading the driver. Via xenpm I can see the various frequenc=
ies and
also see them being changed. However the cpuidle data out of xenpm looks =
a bit odd:

#> xenpm get-cpuidle-states 0
Max C-state: C7

cpu id               : 0
total C-states       : 2
idle time(ms)        : 10819311
C0                   : transition [00000000000000000001]
                       residency  [00000000000000005398 ms]
C1                   : transition [00000000000000000001]
                       residency  [00000000000010819311 ms]
pc3                  : [00000000000000000000 ms]
pc6                  : [00000000000000000000 ms]
pc7                  : [00000000000000000000 ms]
cc3                  : [00000000000000000000 ms]
cc6                  : [00000000000000000000 ms]

Also gathering samples over 30s does look like only C0 and C1 are used. T=
his
might be because C1E support is enabled in BIOS but when looking at the
intel_idle data in sysfs when running without a hypervisor will show C3 a=
nd C6
for the cores. That could have been just a wrong output, so I plugged in =
a power
meter and compared a kernel running natively and running as dom0 (with an=
d
without the acpi-processor driver).

Native: 175W
dom0:   183W (with only marginal difference between with or without the
              processor driver)
[yes, the system has a somewhat high base consumption which I attribute t=
o a
ridiculously dimensioned graphics subsystem to be running a text console]=


This I would take as C3 and C6 really not being used and the frequency sc=
aling
having no impact on the idle system is not that much surprising. But if t=
hat was
true it would also limit the usefulness of the turbo mode which I underst=
and
would also be limited by the c-state of the other cores.

Do I misread the data I see? Or maybe its a known limitation? In case it =
is
worth doing more research I'll gladly try things and gather more data.

Thanks,
Stefan


--------------enigCE74410632203E6E18255326
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPl/WKAAoJEOhnXe7L7s6j4U4QAK7qNx2TVnRLPA7CLQs+QqJ2
wG1b8kBvK9k0npqsoLNK5uE6tNW3w5JFvt3eD+3K+YBQ3Pw82LnETQz2w3Cuz/pU
Psu+WPIZmaKq/pwVUYC9ZK7IjuGK8RIW03nkBN3klmbR8xQgP+B2AG7i4VF5G//h
Nz16CwuM0BwU/QHgjJBF0Z0MkzX0b94RBoeumuXq9C97TQJoqFkEEbSr/4dxKJLu
h6qqhXuZbK164qXTgMfsYrQeBUI7pK2WC5w8P6ikEanXmtVtm8gd70KBjwIilmyz
nVcWVOypMLjJCa3zgydZ9h9PnRzyPtjwi/BorLtM3g5mmtmzqcod4MKrb0R+Nv15
XPWYJRRadyTGZ42tSbWACt6QztzxwBly6kowQ9Y98lM6NedzkZtQcArV26mfn7L3
JogyGjesguqH+Npy3XpIKyeslozHIoC6rANje62diP3ExatTdhPvHzHRq9UqVRyU
NqOFEulBCdua3+ZTyoMFRKFjUDebl2uNHXjkrw35W3+FWnqu8pYJCqygvTleIzVe
A4Nh9s4o+KVZYlZ+aY9thoZiQcSZWQR33Gu+UUDaMqZ1DzklHB/KXUF+KMwg/pNe
N37fg2Q2JRLcSvlyb6EsfNt3Rnl6qHk7eT1Lo3q1N8gqFga7epL/f9JgJzwUG3ov
hGXSR7B6j5j6ZzaMGMGr
=X8Qg
-----END PGP SIGNATURE-----

--------------enigCE74410632203E6E18255326--


--===============2199221830262411281==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2199221830262411281==--


From xen-devel-bounces@lists.xen.org Wed Apr 25 13:01:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN1qE-0002li-TY; Wed, 25 Apr 2012 13:01:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SN1qD-0002lc-9C
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 13:01:05 +0000
Received: from [193.109.254.147:43996] by server-9.bemta-14.messagelabs.com id
	0D/E3-05787-095F79F4; Wed, 25 Apr 2012 13:01:04 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335358861!6257017!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32041 invoked from network); 25 Apr 2012 13:01:01 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-12.tower-27.messagelabs.com with SMTP;
	25 Apr 2012 13:01:01 -0000
Received: from p5b2e257f.dip.t-dialin.net ([91.46.37.127] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SN1q8-0004V3-5B; Wed, 25 Apr 2012 13:01:00 +0000
Message-ID: <4F97F58A.8090409@canonical.com>
Date: Wed, 25 Apr 2012 15:00:58 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4
Cc: Jan Beulich <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2199221830262411281=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2199221830262411281==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigCE74410632203E6E18255326"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCE74410632203E6E18255326
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Since there have been requests about that driver to get backported into 3=
=2E2, I
was interested to find out what or how much would be gained by that.

The first system I tried was an AMD based one (8 core Opteron 6128@2GHz).=
 Which
was not very successful as the drivers bail out of the init function beca=
use the
first call to acpi_processor_register_performance() returns -ENODEV. Ther=
e is
some frequency scaling when running without Xen, so I need to do some mor=
e
debugging there.

The second system was an Intel one (4 core i7 920@2.67GHz) which was
successfully loading the driver. Via xenpm I can see the various frequenc=
ies and
also see them being changed. However the cpuidle data out of xenpm looks =
a bit odd:

#> xenpm get-cpuidle-states 0
Max C-state: C7

cpu id               : 0
total C-states       : 2
idle time(ms)        : 10819311
C0                   : transition [00000000000000000001]
                       residency  [00000000000000005398 ms]
C1                   : transition [00000000000000000001]
                       residency  [00000000000010819311 ms]
pc3                  : [00000000000000000000 ms]
pc6                  : [00000000000000000000 ms]
pc7                  : [00000000000000000000 ms]
cc3                  : [00000000000000000000 ms]
cc6                  : [00000000000000000000 ms]

Also gathering samples over 30s does look like only C0 and C1 are used. T=
his
might be because C1E support is enabled in BIOS but when looking at the
intel_idle data in sysfs when running without a hypervisor will show C3 a=
nd C6
for the cores. That could have been just a wrong output, so I plugged in =
a power
meter and compared a kernel running natively and running as dom0 (with an=
d
without the acpi-processor driver).

Native: 175W
dom0:   183W (with only marginal difference between with or without the
              processor driver)
[yes, the system has a somewhat high base consumption which I attribute t=
o a
ridiculously dimensioned graphics subsystem to be running a text console]=


This I would take as C3 and C6 really not being used and the frequency sc=
aling
having no impact on the idle system is not that much surprising. But if t=
hat was
true it would also limit the usefulness of the turbo mode which I underst=
and
would also be limited by the c-state of the other cores.

Do I misread the data I see? Or maybe its a known limitation? In case it =
is
worth doing more research I'll gladly try things and gather more data.

Thanks,
Stefan


--------------enigCE74410632203E6E18255326
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPl/WKAAoJEOhnXe7L7s6j4U4QAK7qNx2TVnRLPA7CLQs+QqJ2
wG1b8kBvK9k0npqsoLNK5uE6tNW3w5JFvt3eD+3K+YBQ3Pw82LnETQz2w3Cuz/pU
Psu+WPIZmaKq/pwVUYC9ZK7IjuGK8RIW03nkBN3klmbR8xQgP+B2AG7i4VF5G//h
Nz16CwuM0BwU/QHgjJBF0Z0MkzX0b94RBoeumuXq9C97TQJoqFkEEbSr/4dxKJLu
h6qqhXuZbK164qXTgMfsYrQeBUI7pK2WC5w8P6ikEanXmtVtm8gd70KBjwIilmyz
nVcWVOypMLjJCa3zgydZ9h9PnRzyPtjwi/BorLtM3g5mmtmzqcod4MKrb0R+Nv15
XPWYJRRadyTGZ42tSbWACt6QztzxwBly6kowQ9Y98lM6NedzkZtQcArV26mfn7L3
JogyGjesguqH+Npy3XpIKyeslozHIoC6rANje62diP3ExatTdhPvHzHRq9UqVRyU
NqOFEulBCdua3+ZTyoMFRKFjUDebl2uNHXjkrw35W3+FWnqu8pYJCqygvTleIzVe
A4Nh9s4o+KVZYlZ+aY9thoZiQcSZWQR33Gu+UUDaMqZ1DzklHB/KXUF+KMwg/pNe
N37fg2Q2JRLcSvlyb6EsfNt3Rnl6qHk7eT1Lo3q1N8gqFga7epL/f9JgJzwUG3ov
hGXSR7B6j5j6ZzaMGMGr
=X8Qg
-----END PGP SIGNATURE-----

--------------enigCE74410632203E6E18255326--


--===============2199221830262411281==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2199221830262411281==--


From xen-devel-bounces@lists.xen.org Wed Apr 25 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN20J-00036l-8F; Wed, 25 Apr 2012 13:11:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN20I-00036b-6c
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:11:30 +0000
Received: from [193.109.254.147:25386] by server-9.bemta-14.messagelabs.com id
	EE/8F-05787-108F79F4; Wed, 25 Apr 2012 13:11:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335359486!6259329!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21918 invoked from network); 25 Apr 2012 13:11:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 13:11:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN20D-000EF8-4c; Wed, 25 Apr 2012 13:11:25 +0000
Date: Wed, 25 Apr 2012 14:11:25 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425131125.GG51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<7a7443e80b9906908dfa.1335296053@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7a7443e80b9906908dfa.1335296053@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/emulation: No need to get_gfn on
	zero ram_gpa
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:34 -0400 on 24 Apr (1335281653), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c |  48 ++++++++++++++++++++++++---------------------
>  1 files changed, 26 insertions(+), 22 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 2ffc676120b8 -r 7a7443e80b99 xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -60,33 +60,37 @@ static int hvmemul_do_io(
>      ioreq_t *p = get_ioreq(curr);
>      unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
>      p2m_type_t p2mt;
> -    mfn_t ram_mfn;
> +    mfn_t ram_mfn = _mfn(INVALID_MFN);
>      int rc;
>  
> -    /* Check for paged out page */
> -    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
> -    if ( p2m_is_paging(p2mt) )
> -    {
> -        put_gfn(curr->domain, ram_gfn); 
> -        p2m_mem_paging_populate(curr->domain, ram_gfn);
> -        return X86EMUL_RETRY;
> -    }
> -    if ( p2m_is_shared(p2mt) )
> -    {
> -        put_gfn(curr->domain, ram_gfn); 
> -        return X86EMUL_RETRY;
> -    }
> -
> -    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
> -     * to avoid potential deadlock wrt event channel lock, later. */
> -    if ( mfn_valid(mfn_x(ram_mfn)) )
> -        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
> -             curr->domain) )
> +    /* Many callers pass a stub zero ram_gpa address. */
> +    if ( ram_gfn != 0 )

To safely gate on this, the 'stub' value needs to be made into something
that can't be confused with a real paddr, say, ragm_gpa == -1.
Otherwise we lose protection for IO where the target is in page zero. 

> +    { 
> +        /* Check for paged out page */
> +        ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
> +        if ( p2m_is_paging(p2mt) )
>          {
> -            put_gfn(curr->domain, ram_gfn);
> +            put_gfn(curr->domain, ram_gfn); 
> +            p2m_mem_paging_populate(curr->domain, ram_gfn);
>              return X86EMUL_RETRY;
>          }
> -    put_gfn(curr->domain, ram_gfn);
> +        if ( p2m_is_shared(p2mt) )
> +        {
> +            put_gfn(curr->domain, ram_gfn); 
> +            return X86EMUL_RETRY;
> +        }
> +
> +        /* Maintain a ref on the mfn to ensure liveness. Put the gfn
> +         * to avoid potential deadlock wrt event channel lock, later. */
> +        if ( mfn_valid(mfn_x(ram_mfn)) )
> +            if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
> +                 curr->domain) )
> +            {
> +                put_gfn(curr->domain, ram_gfn);
> +                return X86EMUL_RETRY;
> +            }
> +        put_gfn(curr->domain, ram_gfn);
> +    }
>  
>      /*
>       * Weird-sized accesses have undefined behaviour: we discard writes
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN20J-00036l-8F; Wed, 25 Apr 2012 13:11:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN20I-00036b-6c
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:11:30 +0000
Received: from [193.109.254.147:25386] by server-9.bemta-14.messagelabs.com id
	EE/8F-05787-108F79F4; Wed, 25 Apr 2012 13:11:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335359486!6259329!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21918 invoked from network); 25 Apr 2012 13:11:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 13:11:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN20D-000EF8-4c; Wed, 25 Apr 2012 13:11:25 +0000
Date: Wed, 25 Apr 2012 14:11:25 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120425131125.GG51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<7a7443e80b9906908dfa.1335296053@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7a7443e80b9906908dfa.1335296053@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] x86/emulation: No need to get_gfn on
	zero ram_gpa
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:34 -0400 on 24 Apr (1335281653), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c |  48 ++++++++++++++++++++++++---------------------
>  1 files changed, 26 insertions(+), 22 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 2ffc676120b8 -r 7a7443e80b99 xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -60,33 +60,37 @@ static int hvmemul_do_io(
>      ioreq_t *p = get_ioreq(curr);
>      unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
>      p2m_type_t p2mt;
> -    mfn_t ram_mfn;
> +    mfn_t ram_mfn = _mfn(INVALID_MFN);
>      int rc;
>  
> -    /* Check for paged out page */
> -    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
> -    if ( p2m_is_paging(p2mt) )
> -    {
> -        put_gfn(curr->domain, ram_gfn); 
> -        p2m_mem_paging_populate(curr->domain, ram_gfn);
> -        return X86EMUL_RETRY;
> -    }
> -    if ( p2m_is_shared(p2mt) )
> -    {
> -        put_gfn(curr->domain, ram_gfn); 
> -        return X86EMUL_RETRY;
> -    }
> -
> -    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
> -     * to avoid potential deadlock wrt event channel lock, later. */
> -    if ( mfn_valid(mfn_x(ram_mfn)) )
> -        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
> -             curr->domain) )
> +    /* Many callers pass a stub zero ram_gpa address. */
> +    if ( ram_gfn != 0 )

To safely gate on this, the 'stub' value needs to be made into something
that can't be confused with a real paddr, say, ragm_gpa == -1.
Otherwise we lose protection for IO where the target is in page zero. 

> +    { 
> +        /* Check for paged out page */
> +        ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
> +        if ( p2m_is_paging(p2mt) )
>          {
> -            put_gfn(curr->domain, ram_gfn);
> +            put_gfn(curr->domain, ram_gfn); 
> +            p2m_mem_paging_populate(curr->domain, ram_gfn);
>              return X86EMUL_RETRY;
>          }
> -    put_gfn(curr->domain, ram_gfn);
> +        if ( p2m_is_shared(p2mt) )
> +        {
> +            put_gfn(curr->domain, ram_gfn); 
> +            return X86EMUL_RETRY;
> +        }
> +
> +        /* Maintain a ref on the mfn to ensure liveness. Put the gfn
> +         * to avoid potential deadlock wrt event channel lock, later. */
> +        if ( mfn_valid(mfn_x(ram_mfn)) )
> +            if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
> +                 curr->domain) )
> +            {
> +                put_gfn(curr->domain, ram_gfn);
> +                return X86EMUL_RETRY;
> +            }
> +        put_gfn(curr->domain, ram_gfn);
> +    }
>  
>      /*
>       * Weird-sized accesses have undefined behaviour: we discard writes
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:30:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2In-00040S-Qf; Wed, 25 Apr 2012 13:30:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN2Il-000407-OO
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:30:36 +0000
Received: from [85.158.139.83:64068] by server-10.bemta-5.messagelabs.com id
	34/10-08260-A7CF79F4; Wed, 25 Apr 2012 13:30:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335360632!25435967!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10274 invoked from network); 25 Apr 2012 13:30:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:30:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="24523956"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:30:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:30:31 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN250-0001v9-5t;
	Wed, 25 Apr 2012 14:16:22 +0100
Message-ID: <4F97F929.5030707@citrix.com>
Date: Wed, 25 Apr 2012 14:16:25 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
	<1335348880.28015.24.camel@zakaz.uk.xensource.com>
	<1335358736.28015.41.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335358736.28015.41.camel@zakaz.uk.xensource.com>
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	M A Young <m.a.young@durham.ac.uk>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBXZWQsIDIwMTItMDQtMjUgYXQgMTE6MTQgKzAx
MDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4gT24gV2VkLCAyMDEyLTA0LTI1IGF0IDExOjExICsw
MTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPj4+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hl
bi1kZXZlbF0gW3BhdGNoXSB4ZW4gdWRldiBydWxlIGludGVyZmVyaW5nIHdpdGggb3BlbnZwbiIp
Ogo+Pj4+IFNvIGZvciB2aWZuYW1lPSJmb28iIGl0IGlzIGEgbm8tYnJhaW5lciB0byBjYWxsIHRo
ZSB2aWYgImZvbyIgYW5kIHRoZQo+Pj4+IGVtdWxhdGVkIHRhcCBkZXZpY2UgImZvby1lbXUiLgo+
Pj4+Cj4+Pj4gQnV0IHdoYXQgYWJvdXQgdGhlIGNhc2Ugd2hlcmUgbm8gdmlmbmFtZSBpcyBnaXZl
biwgaW4gdGhhdCBjYXNlIHZpZiBpcwo+Pj4+IG5hbWVkICJ2aWY8RE9NPi48REVWPiIuIEJ1dCB3
aGF0IHRvIGNhbGwgdGhlIHRhcD8gUHJldmlvdXNseSBJIHdhcwo+Pj4+IGNoYW5naW5nIHRoZSBu
YW1lIGZyb20gdGFwPERPTT4uPERFVj4gIHRvIHhlbnRhcDxET00+LjxERVY+ICBidXQgcGVyaGFw
cwo+Pj4+IG5vdyAidmlmPERPTT4uPERFVj4tZW11IiBtYWtlcyBtb3JlIHNlbnNlL2lzIG1vcmUg
Y29uc2lzdGVudD8KPj4+IEkgdGhpbmsgZWl0aGVyIGlzIGZpbmUuICBXaGlsZSB3ZSdyZSBjaGFu
Z2luZyBpdCBpdCBwcm9iYWJseSBtYWtlcwo+Pj4gc2Vuc2UgdG8gdXNlICJ2aWYuLi4iIGFzIGlu
ZGVlZCBpdCBpcyBtb3JlIGNvbnNpc3RlbnQuCj4+IE9LLCB2aWZYLlkgYW5kIHZpZlguWS1lbXUg
aXQgaXMuLi4KPgo+IFRoaXMgdHVybmVkIG91dCB0byBiZSBhIGJpdCBtb3JlIGNvbXBsZXggdGhh
biBJIHdhcyBleHBlY3RpbmcsIG1vc3RseQo+IGJlY2F1c2UgdGhlIHVzZSBvZiAidmlmbmFtZSIg
d2l0aCB0YXAgZGV2aWNlcyB3YXMgYWxyZWFkeSBicm9rZW4uIEkKPiB0aGluayB0aGlzIGRvZXMg
dGhlIHJpZ2h0IHRoaW5ncyB3aXRoIGVhY2ggdHlwZSBvZiBkZXZpY2UuCj4KPiBSb2dlciwgbm90
IHN1cmUgd2hhdCBrbm9jayBvbiBlZmZlY3QgdGhpcyBoYXMgb24geW91ciBzZXJpZXMuIFRoZSBt
YWluCj4gdGhpbmcgaXMgbGlrZWx5IHRvIGJlIHRoYXQgeW91IG5lZWRuJ3QgZmluZCB0aGUgdmlm
bmFtZSBzaW5jZSB5b3UKPiBhY3R1YWxseSB3YW50IHRoZSBzdGFuZGFyZCBuYW1lIG5vdCB0aGUg
dXNlciBzdXBwbGllZCBvbmNlIG9uIG1vc3QKPiBvY2Nhc2lvbnMuCgogRnJvbSB3aGF0IEkgc2Vl
LCBJIGhhdmUgdG8gcGFzcyB0aGUgbmFtZSByZXR1cm5lZCBieSAKbGlieGxfX2RldmljZV9uaWNf
ZGV2bmFtZSB0byB0aGUgaG90cGx1ZyBzY3JpcHRzLCBpcyB0aGF0IHJpZ2h0PwoKVGhhbmtzIGZv
ciBkb2luZyB0aGlzIQoKPiBJYW4uCj4KPiA4PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiAj
IFVzZXIgSWFuIENhbXBiZWxsPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ICMgRGF0ZSAxMzM1
MzU0OTU3IC0zNjAwCj4gIyBOb2RlIElEIDQ0ZmM3NjQ4NWY3OTdiZGQ3MjZmZWQ0YTJhN2M0YjA2
MzYzZmRiODgKPiAjIFBhcmVudCAgYTE0YjFkZDBmZWVlZTMwMGMzN2M0NDU2NDM4MWY0ZThlYTgz
N2M0NQo+IGxpYnhsL3hlbmQ6IG5hbWUgdGFwIGRldmljZXMgdmlmWC5ZLWVtdQo+Cj4gVGhpcyBw
cmV2ZW50cyB0aGUgdWRldiBzY3JpcHRzIGZyb20gb3BlcmF0aW5nIG9uIG90aGVyIHRhcCBkZXZp
Y2VzIChlLmcuCj4gb3BlbnZwbiBldGMpCj4KPiBDb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZv
ciB0aGUgInZpZm5hbWUiIG9wdGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAo+IHRvIEhW
TSB0YXAgZGV2aWNlcyBvbmx5LCB3aGljaCBpcyBub3QgdGhlIGNhc2UuCj4KPiBSZXBvcnRlZCBi
eSBNaWNoYWVsIFlvdW5nLgo+Cj4gQWxzbyBmaXggdGhlIHVzZSBvZiB2aWZuYW1lIHdpdGggZW11
bGF0ZWQgZGV2aWNlcy4gVGhpcyBpcyBzbGlnaHRseSBjb21wbGV4Lgo+IFRoZSBjdXJyZW50IGhv
dHBsdWcgc2NyaXB0cyByZWx5IG9uIGJlaW5nIGFibGUgdG8gcGFyc2UgdGhlICJ0YXBYLlkiIChu
b3cKPiAidmlmWC5ZLWVtdSIpIG5hbWUgaW4gb3JkZXIgdG8gbG9jYXRlIHRoZSB4ZW5zdG9yZSBi
YWNrZW5kIGRpciByZWxhdGluZyB0byB0aGUKPiBjb3JyZXNwb25kaW5nIHZpZi4gVGhpcyBpcyBi
ZWNhdXNlIHdlIGNhbm5vdCBpbmplY3Qgb3VyIG93biBlbnZpcm9ubWVudCB2YXJzCj4gaW50byB0
aGUgdGFwIGhvdHBsdWcgZXZlbnRzLiBIb3dldmVyIHRoaXMgbWVhbnMgdGhhdCBpZiB0aGUgdGFw
IGlzIGluaXRpYWxseQo+IG5hbWVkIHdpdGggYSB1c2VyIHNwZWNpZmllZCBuYW1lICh3aGljaCB3
aWxsIG5vdCBtYXRjaCB0aGUgZXhwZWN0ZWQgc2NoZW1lKSB3ZQo+IGZhaWwgdG8gZG8gYW55dGhp
bmcgdXNlZnVsIHdpdGggdGhlIGRldmljZS4gU28gbm93IHdlIGNyZWF0ZSB0aGUgaW5pdGlhbCB0
YXAKPiBkZXZpY2Ugd2l0aCB0aGUgc3RhbmRhcmQgInZpZlguWS1lbXUiIG5hbWUgYW5kIHRoZSBo
b3RwbHVnIHNjcmlwdCB3aWxsIGhhbmRsZQo+IHRoZSByZW5hbWUgdG8gdGhlIGRlc2lyZWQgbmFt
ZS4gVGhpcyBpcyBhbHNvIGhvdyBQViB2aWYgZGV2aWNlcyB3b3JrIC0tIHRoZXkKPiBhcmUgYWx3
YXlzIGNyZWF0ZWQgYnkgbmV0YmFjayB3aXRoIHRoZSBuYW1lIHZpZlguWSBhbmQgcmVuYW1lZCBp
biB0aGUgc2NyaXB0Lgo+Cj4gTGFzdGx5IGFsc28gbW92ZSBsaWJ4bF9fZGV2aWNlXyogdG8gYSBi
ZXR0ZXIgcGxhY2UgaW4gdGhlIGhlYWRlciwgb3RoZXJ3aXNlIHRoZQo+IGNvbW1lbnQgYWJvdXQg
ZXZnZW4gc3R1ZmYgaXNuJ3QgbmV4dCB0byB0aGUgYXNzb2NpYXRlZCBmdW5jdGlvbnMgKG5vdGlj
ZWQganN1dAo+IGJlY2F1c2UgSSB3YXMgZ29pbmcgdG8gYWRkIG5pY19kZXZuYW1lIG5lYXIgdG8g
dGhlIHNldGRlZmF1bHQgZnVuY3Rpb25zKQo+Cj4gU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+Cj4gZGlmZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRm
Yzc2NDg1Zjc5IGRvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24KPiAt
LS0gYS9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCVdlZCBBcHIg
MjUgMTA6NTM6NTIgMjAxMiArMDEwMAo+ICsrKyBiL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZp
Z3VyYXRpb24ubWFya2Rvd24JV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAwCj4gQEAgLTkz
LDExICs5MywxNCBAQCBhcmU6Cj4KPiAgICMjIyB2aWZuYW1lCj4KPiAtVGhpcyBrZXl3b3JkIGlz
IHZhbGlkIGZvciBIVk0gZ3Vlc3QgZGV2aWNlcyB3aXRoIGB0eXBlPWlvZW11YCBvbmx5Lgo+ICtT
cGVjaWZpZXMgdGhlIGJhY2tlbmQgZGV2aWNlIG5hbWUgZm9yIHRoZSB2aXJ0dWFsIGRldmljZS4K
Pgo+IC1TcGVjaWZpZXMgdGhlIGJhY2tlbmQgZGV2aWNlIG5hbWUgZm9yIGFuIGVtdWxhdGVkIGRl
dmljZS4gVGhlIGRlZmF1bHQKPiAtaXMgYHRhcERPTUlELkRFVklEYCB3aGVyZSBgRE9NSURgIGlz
IHRoZSBndWVzdCBkb21haW4gSUQgYW5kIGBERVZJRGAKPiAtaXMgdGhlIGRldmljZSBudW1iZXIu
Cj4gK0lmIHRoZSBkb21haW4gaXMgYW4gSFZNIGRvbWFpbiB0aGVuIHRoZSBhc3NvY2lhdGVkIGVt
dWxhdGVkICh0YXApCj4gK2RldmljZSB3aWxsIGhhdmUgYSAiLWVtdSIgc3VmZmljZSBhZGRlZC4K
PiArCj4gK1RoZSBkZWZhdWx0IG5hbWUgZm9yIHRoZSB2aXJ0dWFsIGRldmljZSBpcyBgdmlmRE9N
SUQuREVWSURgIHdoZXJlCj4gK2BET01JRGAgaXMgdGhlIGd1ZXN0IGRvbWFpbiBJRCBhbmQgYERF
VklEYCBpcyB0aGUgZGV2aWNlCj4gK251bWJlci4gTGlrZXdpc2UgdGhlIGRlZmF1bHQgdGFwIG5h
bWUgaXMgYHZpZkRPTUlELkRFVklELWVtdWAuCj4KPiAgICMjIyBzY3JpcHQKPgo+IGRpZmYgLXIg
YTE0YjFkZDBmZWVlIC1yIDQ0ZmM3NjQ4NWY3OSB0b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21t
b24uc2gKPiAtLS0gYS90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2gJV2VkIEFwciAy
NSAxMDo1Mzo1MiAyMDEyICswMTAwCj4gKysrIGIvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29t
bW9uLnNoCVdlZCBBcHIgMjUgMTI6NTU6NTcgMjAxMiArMDEwMAo+IEBAIC04NSwxMiArODUsMjMg
QEAgZWxpZiBbICIkdHlwZV9pZiIgPSB0YXAgXTsgdGhlbgo+ICAgICAgIDogJHtJTlRFUkZBQ0U6
P30KPgo+ICAgICAgICMgR2V0IHhlbmJ1c19wYXRoIGZyb20gZGV2aWNlIG5hbWUuCj4gLSAgICAj
IFRoZSBuYW1lIGlzIGJ1aWx0IGxpa2UgdGhhdDogInRhcCR7ZG9taWR9LiR7ZGV2aWR9Ii4KPiAt
ICAgIGRldl89JHtkZXYjdGFwfQo+ICsgICAgIyBUaGUgbmFtZSBpcyBidWlsdCBsaWtlIHRoYXQ6
ICJ2aWYke2RvbWlkfS4ke2RldmlkfS1lbXUiLgo+ICsgICAgZGV2Xz0ke2RldiN2aWZ9Cj4gKyAg
ICBkZXZfPSR7ZGV2XyUtZW11fQo+ICAgICAgIGRvbWlkPSR7ZGV2XyUuKn0KPiAgICAgICBkZXZp
ZD0ke2Rldl8jKi59Cj4KPiAgICAgICBYRU5CVVNfUEFUSD0iL2xvY2FsL2RvbWFpbi8wL2JhY2tl
bmQvdmlmLyRkb21pZC8kZGV2aWQiCj4gKyAgICB2aWZuYW1lPSQoeGVuc3RvcmVfcmVhZF9kZWZh
dWx0ICIkWEVOQlVTX1BBVEgvdmlmbmFtZSIgIiIpCj4gKyAgICBpZiBbICIkdmlmbmFtZSIgXQo+
ICsgICAgdGhlbgo+ICsgICAgICAgIHZpZm5hbWU9IiR7dmlmbmFtZX0tZW11Igo+ICsgICAgICAg
IGlmIFsgIiRjb21tYW5kIiA9PSAiYWRkIiBdJiYgICEgaXAgbGluayBzaG93ICIkdmlmbmFtZSI+
Ji9kZXYvbnVsbAo+ICsgICAgICAgIHRoZW4KPiArICAgICAgICAgICAgZG9fb3JfZGllIGlwIGxp
bmsgc2V0ICIkZGV2IiBuYW1lICIkdmlmbmFtZSIKPiArICAgICAgICBmaQo+ICsgICAgICAgIGRl
dj0iJHZpZm5hbWUiCj4gKyAgICBmaQo+ICAgZmkKPgo+ICAgaXA9JHtpcDotfQo+IGRpZmYgLXIg
YTE0YjFkZDBmZWVlIC1yIDQ0ZmM3NjQ4NWY3OSB0b29scy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNr
ZW5kLnJ1bGVzCj4gLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcwlX
ZWQgQXByIDI1IDEwOjUzOjUyIDIwMTIgKzAxMDAKPiArKysgYi90b29scy9ob3RwbHVnL0xpbnV4
L3hlbi1iYWNrZW5kLnJ1bGVzCVdlZCBBcHIgMjUgMTI6NTU6NTcgMjAxMiArMDEwMAo+IEBAIC0x
Myw0ICsxMyw0IEBAIEtFUk5FTD09ImJsa3RhcC1jb250cm9sIiwgTkFNRT0ieGVuL2Jsa3QKPiAg
IEtFUk5FTD09ImdudGRldiIsIE5BTUU9Inhlbi8layIsIE1PREU9IjA2MDAiCj4gICBLRVJORUw9
PSJwY2lfaW9tdWwiLCBOQU1FPSJ4ZW4vJWsiLCBNT0RFPSIwNjAwIgo+ICAgS0VSTkVMPT0idGFw
ZGV2W2Etel0qIiwgTkFNRT0ieGVuL2Jsa3RhcC0yL3RhcGRldiVtIiwgTU9ERT0iMDYwMCIKPiAt
U1VCU1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idGFwKiIsIEFDVElPTj09ImFkZCIsIFJVTis9Ii9l
dGMveGVuL3NjcmlwdHMvdmlmLXNldHVwICRlbnZ7QUNUSU9OfSB0eXBlX2lmPXRhcCIKPiArU1VC
U1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idmlmKi1lbXUiLCBBQ1RJT049PSJhZGQiLCBSVU4rPSIv
ZXRjL3hlbi9zY3JpcHRzL3ZpZi1zZXR1cCAkZW52e0FDVElPTn0gdHlwZV9pZj10YXAiCj4gZGlm
ZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRmYzc2NDg1Zjc5IHRvb2xzL2xpYnhsL2xpYnhsLmMKPiAt
LS0gYS90b29scy9saWJ4bC9saWJ4bC5jCVdlZCBBcHIgMjUgMTA6NTM6NTIgMjAxMiArMDEwMAo+
ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMJV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAw
Cj4gQEAgLTIwOTUsNiArMjA5NSwyMSBAQCBpbnQgbGlieGxfZGV2aWNlX25pY19nZXRpbmZvKGxp
YnhsX2N0eCAqCj4gICAgICAgcmV0dXJuIDA7Cj4gICB9Cj4KPiArY29uc3QgY2hhciAqbGlieGxf
X2RldmljZV9uaWNfZGV2bmFtZShsaWJ4bF9fZ2MgKmdjLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRldmlkLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGxpYnhsX25pY190eXBlIHR5cGUpCj4gK3sKPiArICAgIHN3aXRj
aCAodHlwZSkgewo+ICsgICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9WSUY6Cj4gKyAgICAgICAgcmV0
dXJuIEdDU1BSSU5URigidmlmJXUuJWQiLCBkb21pZCwgZGV2aWQpOwo+ICsgICAgY2FzZSBMSUJY
TF9OSUNfVFlQRV9JT0VNVToKPiArICAgICAgICByZXR1cm4gR0NTUFJJTlRGKCJ2aWYldS4lZCIg
VEFQX0RFVklDRV9TVUZGSVgsIGRvbWlkLCBkZXZpZCk7Cj4gKyAgICBkZWZhdWx0Ogo+ICsgICAg
ICAgIGFib3J0KCk7Cj4gKyAgICB9Cj4gK30KPiArCj4gICAvKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Lwo+ICAgaW50IGxpYnhsX19kZXZpY2VfY29uc29sZV9hZGQobGlieGxfX2djICpnYywgdWludDMy
X3QgZG9taWQsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fZGV2aWNl
X2NvbnNvbGUgKmNvbnNvbGUsCj4gZGlmZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRmYzc2NDg1Zjc5
IHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMKPiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9kbS5jCVdl
ZCBBcHIgMjUgMTA6NTM6NTIgMjAxMiArMDEwMAo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2Rt
LmMJV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAwCj4gQEAgLTIwOSwxMiArMjA5LDkgQEAg
c3RhdGljIGNoYXIgKiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAo+ICAgICAgICAgICAgICAg
aWYgKHZpZnNbaV0ubmljdHlwZSA9PSBMSUJYTF9OSUNfVFlQRV9JT0VNVSkgewo+ICAgICAgICAg
ICAgICAgICAgIGNoYXIgKnNtYWMgPSBsaWJ4bF9fc3ByaW50ZihnYywKPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTElCWExfTUFDX0ZNVCwgTElCWExfTUFDX0JZVEVTKHZp
ZnNbaV0ubWFjKSk7Cj4gLSAgICAgICAgICAgICAgICBjaGFyICppZm5hbWU7Cj4gLSAgICAgICAg
ICAgICAgICBpZiAoIXZpZnNbaV0uaWZuYW1lKQo+IC0gICAgICAgICAgICAgICAgICAgIGlmbmFt
ZSA9IGxpYnhsX19zcHJpbnRmKGdjLAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICJ0YXAlZC4lZCIsIGRvbWlkLCB2aWZzW2ldLmRldmlkKTsKPiAtICAgICAg
ICAgICAgICAgIGVsc2UKPiAtICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlm
bmFtZTsKPiArICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmlmbmFtZSA9IGxpYnhsX19kZXZp
Y2VfbmljX2Rldm5hbWUoZ2MsCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRvbWlkLCB2aWZzW2ldLmRldmlkLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMSUJYTF9OSUNfVFlQRV9JT0VNVSk7Cj4gICAg
ICAgICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBlbmQoZG1fYXJncywKPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIi1uZXQiLCBsaWJ4bF9fc3ByaW50ZihnYywgIm5pYyx2bGFu
PSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiLAo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQsIHNtYWMsIHZpZnNbaV0u
bW9kZWwpLAo+IEBAIC00NDksMTMgKzQ0Niw5IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX19idWls
ZF9kZXZpY2VfbW9kZWwKPiAgICAgICAgICAgICAgIGlmICh2aWZzW2ldLm5pY3R5cGUgPT0gTElC
WExfTklDX1RZUEVfSU9FTVUpIHsKPiAgICAgICAgICAgICAgICAgICBjaGFyICpzbWFjID0gbGli
eGxfX3NwcmludGYoZ2MsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExJQlhM
X01BQ19GTVQsIExJQlhMX01BQ19CWVRFUyh2aWZzW2ldLm1hYykpOwo+IC0gICAgICAgICAgICAg
ICAgY2hhciAqaWZuYW1lOwo+IC0gICAgICAgICAgICAgICAgaWYgKCF2aWZzW2ldLmlmbmFtZSkg
ewo+IC0gICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdjLCAidGFw
JWQuJWQiLAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGd1
ZXN0X2RvbWlkLCB2aWZzW2ldLmRldmlkKTsKPiAtICAgICAgICAgICAgICAgIH0gZWxzZSB7Cj4g
LSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gdmlmc1tpXS5pZm5hbWU7Cj4gLSAgICAgICAg
ICAgICAgICB9Cj4gKyAgICAgICAgICAgICAgICBjb25zdCBjaGFyICppZm5hbWUgPSBsaWJ4bF9f
ZGV2aWNlX25pY19kZXZuYW1lKGdjLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBndWVzdF9kb21pZCwgdmlmc1tpXS5kZXZpZCwKPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTElCWExfTklDX1RZUEVfSU9F
TVUpOwo+ICAgICAgICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1kZXZp
Y2UiKTsKPiAgICAgICAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsCj4gICAg
ICAgICAgICAgICAgICAgICAgbGlieGxfX3NwcmludGYoZ2MsICIlcyxpZD1uaWMlZCxuZXRkZXY9
bmV0JWQsbWFjPSVzIiwKPiBkaWZmIC1yIGExNGIxZGQwZmVlZSAtciA0NGZjNzY0ODVmNzkgdG9v
bHMvbGlieGwvbGlieGxfaW50ZXJuYWwuaAo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVy
bmFsLmgJV2VkIEFwciAyNSAxMDo1Mzo1MiAyMDEyICswMTAwCj4gKysrIGIvdG9vbHMvbGlieGwv
bGlieGxfaW50ZXJuYWwuaAlXZWQgQXByIDI1IDEyOjU1OjU3IDIwMTIgKzAxMDAKPiBAQCAtODMs
NiArODMsNyBAQAo+ICAgI2RlZmluZSBTVFVCRE9NX0NPTlNPTEVfUkVTVE9SRSAyCj4gICAjZGVm
aW5lIFNUVUJET01fQ09OU09MRV9TRVJJQUwgMwo+ICAgI2RlZmluZSBTVFVCRE9NX1NQRUNJQUxf
Q09OU09MRVMgMwo+ICsjZGVmaW5lIFRBUF9ERVZJQ0VfU1VGRklYICItZW11Igo+Cj4gICAjZGVm
aW5lIEFSUkFZX1NJWkUoYSkgKHNpemVvZihhKSAvIHNpemVvZihhWzBdKSkKPgo+IEBAIC0xOTYs
MTcgKzE5Nyw2IEBAIF9oaWRkZW4gbGlieGxfX2V2X3hzd2F0Y2ggKmxpYnhsX193YXRjaF8KPiAg
ICAqIHZlcnNpb24gb2YgdGhlIF9ldmRpc2FibGVfRk9PIGZ1bmN0aW9uOyB0aGUgaW50ZXJuYWwg
b25lIGlzCj4gICAgKiB1c2VkIGR1cmluZyBjbGVhbnVwLgo+ICAgICovCj4gLV9oaWRkZW4gaW50
IGxpYnhsX19kb21haW5fY3JlYXRlX2luZm9fc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLAo+IC0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfZG9tYWluX2NyZWF0
ZV9pbmZvICpjX2luZm8pOwo+IC1faGlkZGVuIGludCBsaWJ4bF9fZG9tYWluX2J1aWxkX2luZm9f
c2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmJfaW5mbyk7Cj4gLV9oaWRkZW4g
aW50IGxpYnhsX19kZXZpY2VfZGlza19zZXRkZWZhdWx0KGxpYnhsX19nYyAqZ2MsCj4gLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2RldmljZV9kaXNrICpk
aXNrKTsKPiAtX2hpZGRlbiBpbnQgbGlieGxfX2RldmljZV9uaWNfc2V0ZGVmYXVsdChsaWJ4bF9f
Z2MgKmdjLCBsaWJ4bF9kZXZpY2VfbmljICpuaWMpOwo+IC1faGlkZGVuIGludCBsaWJ4bF9fZGV2
aWNlX3ZmYl9zZXRkZWZhdWx0KGxpYnhsX19nYyAqZ2MsIGxpYnhsX2RldmljZV92ZmIgKnZmYik7
Cj4gLV9oaWRkZW4gaW50IGxpYnhsX19kZXZpY2VfdmtiX3NldGRlZmF1bHQobGlieGxfX2djICpn
YywgbGlieGxfZGV2aWNlX3ZrYiAqdmtiKTsKPiAtX2hpZGRlbiBpbnQgbGlieGxfX2RldmljZV9w
Y2lfc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9kZXZpY2VfcGNpICpwY2kpOwo+IC0K
PiAgIHN0cnVjdCBsaWJ4bF9fZXZnZW5fZG9tYWluX2RlYXRoIHsKPiAgICAgICB1aW50MzJfdCBk
b21pZDsKPiAgICAgICB1bnNpZ25lZCBzaHV0ZG93bl9yZXBvcnRlZDoxLCBkZWF0aF9yZXBvcnRl
ZDoxOwo+IEBAIC03MDQsNiArNjk0LDIxIEBAIF9oaWRkZW4gaW50IGxpYnhsX193YWl0X2Zvcl9i
YWNrZW5kKGxpYngKPiAgICAqICAgICBBbGwgbGlieGwgQVBJIGZ1bmN0aW9ucyBhcmUgZXhwZWN0
ZWQgdG8gaGF2ZSBhcnJhbmdlZCBmb3IgdGhpcwo+ICAgICogICAgIHRvIGJlIGNhbGxlZCBiZWZv
cmUgdXNpbmcgYW55IHZhbHVlcyB3aXRoaW4gdGhlc2Ugc3RydWN0dXJlcy4KPiAgICAqLwo+ICtf
aGlkZGVuIGludCBsaWJ4bF9fZG9tYWluX2NyZWF0ZV9pbmZvX3NldGRlZmF1bHQobGlieGxfX2dj
ICpnYywKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2Rv
bWFpbl9jcmVhdGVfaW5mbyAqY19pbmZvKTsKPiArX2hpZGRlbiBpbnQgbGlieGxfX2RvbWFpbl9i
dWlsZF9pbmZvX3NldGRlZmF1bHQobGlieGxfX2djICpnYywKPiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvICpiX2luZm8pOwo+
ICtfaGlkZGVuIGludCBsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdj
LAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZp
Y2VfZGlzayAqZGlzayk7Cj4gK19oaWRkZW4gaW50IGxpYnhsX19kZXZpY2VfbmljX3NldGRlZmF1
bHQobGlieGxfX2djICpnYywgbGlieGxfZGV2aWNlX25pYyAqbmljKTsKPiArX2hpZGRlbiBpbnQg
bGlieGxfX2RldmljZV92ZmJfc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9kZXZpY2Vf
dmZiICp2ZmIpOwo+ICtfaGlkZGVuIGludCBsaWJ4bF9fZGV2aWNlX3ZrYl9zZXRkZWZhdWx0KGxp
YnhsX19nYyAqZ2MsIGxpYnhsX2RldmljZV92a2IgKnZrYik7Cj4gK19oaWRkZW4gaW50IGxpYnhs
X19kZXZpY2VfcGNpX3NldGRlZmF1bHQobGlieGxfX2djICpnYywgbGlieGxfZGV2aWNlX3BjaSAq
cGNpKTsKPiArCj4gK19oaWRkZW4gY29uc3QgY2hhciAqbGlieGxfX2RldmljZV9uaWNfZGV2bmFt
ZShsaWJ4bF9fZ2MgKmdjLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdWludDMyX3QgZG9taWQsCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50MzJfdCBkZXZpZCwKPiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX25pY190eXBlIHR5cGUpOwo+Cj4gICAvKiBB
cnJhbmdlcyB0aGF0IGRldiB3aWxsIGJlIHJlbW92ZWQgZnJvbSBpdHMgZ3Vlc3QuICBXaGVuCj4g
ICAgKiB0aGlzIGlzIGRvbmUsIHRoZSBhbyB3aWxsIGJlIGNvbXBsZXRlZC4gIEFuIGVycm9yCj4g
ZGlmZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRmYzc2NDg1Zjc5IHRvb2xzL3B5dGhvbi94ZW4veGVu
ZC9pbWFnZS5weQo+IC0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5weQlXZWQgQXBy
IDI1IDEwOjUzOjUyIDIwMTIgKzAxMDAKPiArKysgYi90b29scy9weXRob24veGVuL3hlbmQvaW1h
Z2UucHkJV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAwCj4gQEAgLTkxNywxMSArOTE3LDcg
QEAgY2xhc3MgSFZNSW1hZ2VIYW5kbGVyKEltYWdlSGFuZGxlcik6Cj4gICAgICAgICAgICAgICBy
ZXQuYXBwZW5kKCItbmV0IikKPiAgICAgICAgICAgICAgIHJldC5hcHBlbmQoIm5pYyx2bGFuPSVk
LG1hY2FkZHI9JXMsbW9kZWw9JXMiICUKPiAgICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3Ms
IG1hYywgbW9kZWwpKQo+IC0gICAgICAgICAgICB2aWZuYW1lID0gZGV2aW5mby5nZXQoJ3ZpZm5h
bWUnKQo+IC0gICAgICAgICAgICBpZiB2aWZuYW1lOgo+IC0gICAgICAgICAgICAgICAgdmlmbmFt
ZSA9ICJ0YXAtIiArIHZpZm5hbWUKPiAtICAgICAgICAgICAgZWxzZToKPiAtICAgICAgICAgICAg
ICAgIHZpZm5hbWUgPSAidGFwJWQuJWQiICUgKHNlbGYudm0uZ2V0RG9taWQoKSwgbmljcy0xKQo+
ICsgICAgICAgICAgICB2aWZuYW1lID0gInZpZiVkLiVkLWVtdSIgJSAoc2VsZi52bS5nZXREb21p
ZCgpLCBuaWNzLTEpCj4gICAgICAgICAgICAgICByZXQuYXBwZW5kKCItbmV0IikKPiAgICAgICAg
ICAgICAgIHJldC5hcHBlbmQoInRhcCx2bGFuPSVkLGlmbmFtZT0lcyxicmlkZ2U9JXMiICUKPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3MsIHZpZm5hbWUsIGJyaWRnZSkpCj4KPgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:30:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2In-00040S-Qf; Wed, 25 Apr 2012 13:30:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN2Il-000407-OO
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:30:36 +0000
Received: from [85.158.139.83:64068] by server-10.bemta-5.messagelabs.com id
	34/10-08260-A7CF79F4; Wed, 25 Apr 2012 13:30:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335360632!25435967!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10274 invoked from network); 25 Apr 2012 13:30:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:30:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="24523956"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:30:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:30:31 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN250-0001v9-5t;
	Wed, 25 Apr 2012 14:16:22 +0100
Message-ID: <4F97F929.5030707@citrix.com>
Date: Wed, 25 Apr 2012 14:16:25 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
	<1335348880.28015.24.camel@zakaz.uk.xensource.com>
	<1335358736.28015.41.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335358736.28015.41.camel@zakaz.uk.xensource.com>
Cc: Teck Choon Giam <giamteckchoon@gmail.com>,
	M A Young <m.a.young@durham.ac.uk>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBXZWQsIDIwMTItMDQtMjUgYXQgMTE6MTQgKzAx
MDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4gT24gV2VkLCAyMDEyLTA0LTI1IGF0IDExOjExICsw
MTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPj4+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hl
bi1kZXZlbF0gW3BhdGNoXSB4ZW4gdWRldiBydWxlIGludGVyZmVyaW5nIHdpdGggb3BlbnZwbiIp
Ogo+Pj4+IFNvIGZvciB2aWZuYW1lPSJmb28iIGl0IGlzIGEgbm8tYnJhaW5lciB0byBjYWxsIHRo
ZSB2aWYgImZvbyIgYW5kIHRoZQo+Pj4+IGVtdWxhdGVkIHRhcCBkZXZpY2UgImZvby1lbXUiLgo+
Pj4+Cj4+Pj4gQnV0IHdoYXQgYWJvdXQgdGhlIGNhc2Ugd2hlcmUgbm8gdmlmbmFtZSBpcyBnaXZl
biwgaW4gdGhhdCBjYXNlIHZpZiBpcwo+Pj4+IG5hbWVkICJ2aWY8RE9NPi48REVWPiIuIEJ1dCB3
aGF0IHRvIGNhbGwgdGhlIHRhcD8gUHJldmlvdXNseSBJIHdhcwo+Pj4+IGNoYW5naW5nIHRoZSBu
YW1lIGZyb20gdGFwPERPTT4uPERFVj4gIHRvIHhlbnRhcDxET00+LjxERVY+ICBidXQgcGVyaGFw
cwo+Pj4+IG5vdyAidmlmPERPTT4uPERFVj4tZW11IiBtYWtlcyBtb3JlIHNlbnNlL2lzIG1vcmUg
Y29uc2lzdGVudD8KPj4+IEkgdGhpbmsgZWl0aGVyIGlzIGZpbmUuICBXaGlsZSB3ZSdyZSBjaGFu
Z2luZyBpdCBpdCBwcm9iYWJseSBtYWtlcwo+Pj4gc2Vuc2UgdG8gdXNlICJ2aWYuLi4iIGFzIGlu
ZGVlZCBpdCBpcyBtb3JlIGNvbnNpc3RlbnQuCj4+IE9LLCB2aWZYLlkgYW5kIHZpZlguWS1lbXUg
aXQgaXMuLi4KPgo+IFRoaXMgdHVybmVkIG91dCB0byBiZSBhIGJpdCBtb3JlIGNvbXBsZXggdGhh
biBJIHdhcyBleHBlY3RpbmcsIG1vc3RseQo+IGJlY2F1c2UgdGhlIHVzZSBvZiAidmlmbmFtZSIg
d2l0aCB0YXAgZGV2aWNlcyB3YXMgYWxyZWFkeSBicm9rZW4uIEkKPiB0aGluayB0aGlzIGRvZXMg
dGhlIHJpZ2h0IHRoaW5ncyB3aXRoIGVhY2ggdHlwZSBvZiBkZXZpY2UuCj4KPiBSb2dlciwgbm90
IHN1cmUgd2hhdCBrbm9jayBvbiBlZmZlY3QgdGhpcyBoYXMgb24geW91ciBzZXJpZXMuIFRoZSBt
YWluCj4gdGhpbmcgaXMgbGlrZWx5IHRvIGJlIHRoYXQgeW91IG5lZWRuJ3QgZmluZCB0aGUgdmlm
bmFtZSBzaW5jZSB5b3UKPiBhY3R1YWxseSB3YW50IHRoZSBzdGFuZGFyZCBuYW1lIG5vdCB0aGUg
dXNlciBzdXBwbGllZCBvbmNlIG9uIG1vc3QKPiBvY2Nhc2lvbnMuCgogRnJvbSB3aGF0IEkgc2Vl
LCBJIGhhdmUgdG8gcGFzcyB0aGUgbmFtZSByZXR1cm5lZCBieSAKbGlieGxfX2RldmljZV9uaWNf
ZGV2bmFtZSB0byB0aGUgaG90cGx1ZyBzY3JpcHRzLCBpcyB0aGF0IHJpZ2h0PwoKVGhhbmtzIGZv
ciBkb2luZyB0aGlzIQoKPiBJYW4uCj4KPiA4PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiAj
IFVzZXIgSWFuIENhbXBiZWxsPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ICMgRGF0ZSAxMzM1
MzU0OTU3IC0zNjAwCj4gIyBOb2RlIElEIDQ0ZmM3NjQ4NWY3OTdiZGQ3MjZmZWQ0YTJhN2M0YjA2
MzYzZmRiODgKPiAjIFBhcmVudCAgYTE0YjFkZDBmZWVlZTMwMGMzN2M0NDU2NDM4MWY0ZThlYTgz
N2M0NQo+IGxpYnhsL3hlbmQ6IG5hbWUgdGFwIGRldmljZXMgdmlmWC5ZLWVtdQo+Cj4gVGhpcyBw
cmV2ZW50cyB0aGUgdWRldiBzY3JpcHRzIGZyb20gb3BlcmF0aW5nIG9uIG90aGVyIHRhcCBkZXZp
Y2VzIChlLmcuCj4gb3BlbnZwbiBldGMpCj4KPiBDb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZv
ciB0aGUgInZpZm5hbWUiIG9wdGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAo+IHRvIEhW
TSB0YXAgZGV2aWNlcyBvbmx5LCB3aGljaCBpcyBub3QgdGhlIGNhc2UuCj4KPiBSZXBvcnRlZCBi
eSBNaWNoYWVsIFlvdW5nLgo+Cj4gQWxzbyBmaXggdGhlIHVzZSBvZiB2aWZuYW1lIHdpdGggZW11
bGF0ZWQgZGV2aWNlcy4gVGhpcyBpcyBzbGlnaHRseSBjb21wbGV4Lgo+IFRoZSBjdXJyZW50IGhv
dHBsdWcgc2NyaXB0cyByZWx5IG9uIGJlaW5nIGFibGUgdG8gcGFyc2UgdGhlICJ0YXBYLlkiIChu
b3cKPiAidmlmWC5ZLWVtdSIpIG5hbWUgaW4gb3JkZXIgdG8gbG9jYXRlIHRoZSB4ZW5zdG9yZSBi
YWNrZW5kIGRpciByZWxhdGluZyB0byB0aGUKPiBjb3JyZXNwb25kaW5nIHZpZi4gVGhpcyBpcyBi
ZWNhdXNlIHdlIGNhbm5vdCBpbmplY3Qgb3VyIG93biBlbnZpcm9ubWVudCB2YXJzCj4gaW50byB0
aGUgdGFwIGhvdHBsdWcgZXZlbnRzLiBIb3dldmVyIHRoaXMgbWVhbnMgdGhhdCBpZiB0aGUgdGFw
IGlzIGluaXRpYWxseQo+IG5hbWVkIHdpdGggYSB1c2VyIHNwZWNpZmllZCBuYW1lICh3aGljaCB3
aWxsIG5vdCBtYXRjaCB0aGUgZXhwZWN0ZWQgc2NoZW1lKSB3ZQo+IGZhaWwgdG8gZG8gYW55dGhp
bmcgdXNlZnVsIHdpdGggdGhlIGRldmljZS4gU28gbm93IHdlIGNyZWF0ZSB0aGUgaW5pdGlhbCB0
YXAKPiBkZXZpY2Ugd2l0aCB0aGUgc3RhbmRhcmQgInZpZlguWS1lbXUiIG5hbWUgYW5kIHRoZSBo
b3RwbHVnIHNjcmlwdCB3aWxsIGhhbmRsZQo+IHRoZSByZW5hbWUgdG8gdGhlIGRlc2lyZWQgbmFt
ZS4gVGhpcyBpcyBhbHNvIGhvdyBQViB2aWYgZGV2aWNlcyB3b3JrIC0tIHRoZXkKPiBhcmUgYWx3
YXlzIGNyZWF0ZWQgYnkgbmV0YmFjayB3aXRoIHRoZSBuYW1lIHZpZlguWSBhbmQgcmVuYW1lZCBp
biB0aGUgc2NyaXB0Lgo+Cj4gTGFzdGx5IGFsc28gbW92ZSBsaWJ4bF9fZGV2aWNlXyogdG8gYSBi
ZXR0ZXIgcGxhY2UgaW4gdGhlIGhlYWRlciwgb3RoZXJ3aXNlIHRoZQo+IGNvbW1lbnQgYWJvdXQg
ZXZnZW4gc3R1ZmYgaXNuJ3QgbmV4dCB0byB0aGUgYXNzb2NpYXRlZCBmdW5jdGlvbnMgKG5vdGlj
ZWQganN1dAo+IGJlY2F1c2UgSSB3YXMgZ29pbmcgdG8gYWRkIG5pY19kZXZuYW1lIG5lYXIgdG8g
dGhlIHNldGRlZmF1bHQgZnVuY3Rpb25zKQo+Cj4gU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+Cj4gZGlmZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRm
Yzc2NDg1Zjc5IGRvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24KPiAt
LS0gYS9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCVdlZCBBcHIg
MjUgMTA6NTM6NTIgMjAxMiArMDEwMAo+ICsrKyBiL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZp
Z3VyYXRpb24ubWFya2Rvd24JV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAwCj4gQEAgLTkz
LDExICs5MywxNCBAQCBhcmU6Cj4KPiAgICMjIyB2aWZuYW1lCj4KPiAtVGhpcyBrZXl3b3JkIGlz
IHZhbGlkIGZvciBIVk0gZ3Vlc3QgZGV2aWNlcyB3aXRoIGB0eXBlPWlvZW11YCBvbmx5Lgo+ICtT
cGVjaWZpZXMgdGhlIGJhY2tlbmQgZGV2aWNlIG5hbWUgZm9yIHRoZSB2aXJ0dWFsIGRldmljZS4K
Pgo+IC1TcGVjaWZpZXMgdGhlIGJhY2tlbmQgZGV2aWNlIG5hbWUgZm9yIGFuIGVtdWxhdGVkIGRl
dmljZS4gVGhlIGRlZmF1bHQKPiAtaXMgYHRhcERPTUlELkRFVklEYCB3aGVyZSBgRE9NSURgIGlz
IHRoZSBndWVzdCBkb21haW4gSUQgYW5kIGBERVZJRGAKPiAtaXMgdGhlIGRldmljZSBudW1iZXIu
Cj4gK0lmIHRoZSBkb21haW4gaXMgYW4gSFZNIGRvbWFpbiB0aGVuIHRoZSBhc3NvY2lhdGVkIGVt
dWxhdGVkICh0YXApCj4gK2RldmljZSB3aWxsIGhhdmUgYSAiLWVtdSIgc3VmZmljZSBhZGRlZC4K
PiArCj4gK1RoZSBkZWZhdWx0IG5hbWUgZm9yIHRoZSB2aXJ0dWFsIGRldmljZSBpcyBgdmlmRE9N
SUQuREVWSURgIHdoZXJlCj4gK2BET01JRGAgaXMgdGhlIGd1ZXN0IGRvbWFpbiBJRCBhbmQgYERF
VklEYCBpcyB0aGUgZGV2aWNlCj4gK251bWJlci4gTGlrZXdpc2UgdGhlIGRlZmF1bHQgdGFwIG5h
bWUgaXMgYHZpZkRPTUlELkRFVklELWVtdWAuCj4KPiAgICMjIyBzY3JpcHQKPgo+IGRpZmYgLXIg
YTE0YjFkZDBmZWVlIC1yIDQ0ZmM3NjQ4NWY3OSB0b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21t
b24uc2gKPiAtLS0gYS90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2gJV2VkIEFwciAy
NSAxMDo1Mzo1MiAyMDEyICswMTAwCj4gKysrIGIvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29t
bW9uLnNoCVdlZCBBcHIgMjUgMTI6NTU6NTcgMjAxMiArMDEwMAo+IEBAIC04NSwxMiArODUsMjMg
QEAgZWxpZiBbICIkdHlwZV9pZiIgPSB0YXAgXTsgdGhlbgo+ICAgICAgIDogJHtJTlRFUkZBQ0U6
P30KPgo+ICAgICAgICMgR2V0IHhlbmJ1c19wYXRoIGZyb20gZGV2aWNlIG5hbWUuCj4gLSAgICAj
IFRoZSBuYW1lIGlzIGJ1aWx0IGxpa2UgdGhhdDogInRhcCR7ZG9taWR9LiR7ZGV2aWR9Ii4KPiAt
ICAgIGRldl89JHtkZXYjdGFwfQo+ICsgICAgIyBUaGUgbmFtZSBpcyBidWlsdCBsaWtlIHRoYXQ6
ICJ2aWYke2RvbWlkfS4ke2RldmlkfS1lbXUiLgo+ICsgICAgZGV2Xz0ke2RldiN2aWZ9Cj4gKyAg
ICBkZXZfPSR7ZGV2XyUtZW11fQo+ICAgICAgIGRvbWlkPSR7ZGV2XyUuKn0KPiAgICAgICBkZXZp
ZD0ke2Rldl8jKi59Cj4KPiAgICAgICBYRU5CVVNfUEFUSD0iL2xvY2FsL2RvbWFpbi8wL2JhY2tl
bmQvdmlmLyRkb21pZC8kZGV2aWQiCj4gKyAgICB2aWZuYW1lPSQoeGVuc3RvcmVfcmVhZF9kZWZh
dWx0ICIkWEVOQlVTX1BBVEgvdmlmbmFtZSIgIiIpCj4gKyAgICBpZiBbICIkdmlmbmFtZSIgXQo+
ICsgICAgdGhlbgo+ICsgICAgICAgIHZpZm5hbWU9IiR7dmlmbmFtZX0tZW11Igo+ICsgICAgICAg
IGlmIFsgIiRjb21tYW5kIiA9PSAiYWRkIiBdJiYgICEgaXAgbGluayBzaG93ICIkdmlmbmFtZSI+
Ji9kZXYvbnVsbAo+ICsgICAgICAgIHRoZW4KPiArICAgICAgICAgICAgZG9fb3JfZGllIGlwIGxp
bmsgc2V0ICIkZGV2IiBuYW1lICIkdmlmbmFtZSIKPiArICAgICAgICBmaQo+ICsgICAgICAgIGRl
dj0iJHZpZm5hbWUiCj4gKyAgICBmaQo+ICAgZmkKPgo+ICAgaXA9JHtpcDotfQo+IGRpZmYgLXIg
YTE0YjFkZDBmZWVlIC1yIDQ0ZmM3NjQ4NWY3OSB0b29scy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNr
ZW5kLnJ1bGVzCj4gLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcwlX
ZWQgQXByIDI1IDEwOjUzOjUyIDIwMTIgKzAxMDAKPiArKysgYi90b29scy9ob3RwbHVnL0xpbnV4
L3hlbi1iYWNrZW5kLnJ1bGVzCVdlZCBBcHIgMjUgMTI6NTU6NTcgMjAxMiArMDEwMAo+IEBAIC0x
Myw0ICsxMyw0IEBAIEtFUk5FTD09ImJsa3RhcC1jb250cm9sIiwgTkFNRT0ieGVuL2Jsa3QKPiAg
IEtFUk5FTD09ImdudGRldiIsIE5BTUU9Inhlbi8layIsIE1PREU9IjA2MDAiCj4gICBLRVJORUw9
PSJwY2lfaW9tdWwiLCBOQU1FPSJ4ZW4vJWsiLCBNT0RFPSIwNjAwIgo+ICAgS0VSTkVMPT0idGFw
ZGV2W2Etel0qIiwgTkFNRT0ieGVuL2Jsa3RhcC0yL3RhcGRldiVtIiwgTU9ERT0iMDYwMCIKPiAt
U1VCU1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idGFwKiIsIEFDVElPTj09ImFkZCIsIFJVTis9Ii9l
dGMveGVuL3NjcmlwdHMvdmlmLXNldHVwICRlbnZ7QUNUSU9OfSB0eXBlX2lmPXRhcCIKPiArU1VC
U1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idmlmKi1lbXUiLCBBQ1RJT049PSJhZGQiLCBSVU4rPSIv
ZXRjL3hlbi9zY3JpcHRzL3ZpZi1zZXR1cCAkZW52e0FDVElPTn0gdHlwZV9pZj10YXAiCj4gZGlm
ZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRmYzc2NDg1Zjc5IHRvb2xzL2xpYnhsL2xpYnhsLmMKPiAt
LS0gYS90b29scy9saWJ4bC9saWJ4bC5jCVdlZCBBcHIgMjUgMTA6NTM6NTIgMjAxMiArMDEwMAo+
ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMJV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAw
Cj4gQEAgLTIwOTUsNiArMjA5NSwyMSBAQCBpbnQgbGlieGxfZGV2aWNlX25pY19nZXRpbmZvKGxp
YnhsX2N0eCAqCj4gICAgICAgcmV0dXJuIDA7Cj4gICB9Cj4KPiArY29uc3QgY2hhciAqbGlieGxf
X2RldmljZV9uaWNfZGV2bmFtZShsaWJ4bF9fZ2MgKmdjLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRldmlkLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGxpYnhsX25pY190eXBlIHR5cGUpCj4gK3sKPiArICAgIHN3aXRj
aCAodHlwZSkgewo+ICsgICAgY2FzZSBMSUJYTF9OSUNfVFlQRV9WSUY6Cj4gKyAgICAgICAgcmV0
dXJuIEdDU1BSSU5URigidmlmJXUuJWQiLCBkb21pZCwgZGV2aWQpOwo+ICsgICAgY2FzZSBMSUJY
TF9OSUNfVFlQRV9JT0VNVToKPiArICAgICAgICByZXR1cm4gR0NTUFJJTlRGKCJ2aWYldS4lZCIg
VEFQX0RFVklDRV9TVUZGSVgsIGRvbWlkLCBkZXZpZCk7Cj4gKyAgICBkZWZhdWx0Ogo+ICsgICAg
ICAgIGFib3J0KCk7Cj4gKyAgICB9Cj4gK30KPiArCj4gICAvKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Lwo+ICAgaW50IGxpYnhsX19kZXZpY2VfY29uc29sZV9hZGQobGlieGxfX2djICpnYywgdWludDMy
X3QgZG9taWQsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9fZGV2aWNl
X2NvbnNvbGUgKmNvbnNvbGUsCj4gZGlmZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRmYzc2NDg1Zjc5
IHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMKPiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9kbS5jCVdl
ZCBBcHIgMjUgMTA6NTM6NTIgMjAxMiArMDEwMAo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2Rt
LmMJV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAwCj4gQEAgLTIwOSwxMiArMjA5LDkgQEAg
c3RhdGljIGNoYXIgKiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAo+ICAgICAgICAgICAgICAg
aWYgKHZpZnNbaV0ubmljdHlwZSA9PSBMSUJYTF9OSUNfVFlQRV9JT0VNVSkgewo+ICAgICAgICAg
ICAgICAgICAgIGNoYXIgKnNtYWMgPSBsaWJ4bF9fc3ByaW50ZihnYywKPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTElCWExfTUFDX0ZNVCwgTElCWExfTUFDX0JZVEVTKHZp
ZnNbaV0ubWFjKSk7Cj4gLSAgICAgICAgICAgICAgICBjaGFyICppZm5hbWU7Cj4gLSAgICAgICAg
ICAgICAgICBpZiAoIXZpZnNbaV0uaWZuYW1lKQo+IC0gICAgICAgICAgICAgICAgICAgIGlmbmFt
ZSA9IGxpYnhsX19zcHJpbnRmKGdjLAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICJ0YXAlZC4lZCIsIGRvbWlkLCB2aWZzW2ldLmRldmlkKTsKPiAtICAgICAg
ICAgICAgICAgIGVsc2UKPiAtICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlm
bmFtZTsKPiArICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmlmbmFtZSA9IGxpYnhsX19kZXZp
Y2VfbmljX2Rldm5hbWUoZ2MsCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRvbWlkLCB2aWZzW2ldLmRldmlkLAo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMSUJYTF9OSUNfVFlQRV9JT0VNVSk7Cj4gICAg
ICAgICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBlbmQoZG1fYXJncywKPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIi1uZXQiLCBsaWJ4bF9fc3ByaW50ZihnYywgIm5pYyx2bGFu
PSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiLAo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQsIHNtYWMsIHZpZnNbaV0u
bW9kZWwpLAo+IEBAIC00NDksMTMgKzQ0Niw5IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX19idWls
ZF9kZXZpY2VfbW9kZWwKPiAgICAgICAgICAgICAgIGlmICh2aWZzW2ldLm5pY3R5cGUgPT0gTElC
WExfTklDX1RZUEVfSU9FTVUpIHsKPiAgICAgICAgICAgICAgICAgICBjaGFyICpzbWFjID0gbGli
eGxfX3NwcmludGYoZ2MsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExJQlhM
X01BQ19GTVQsIExJQlhMX01BQ19CWVRFUyh2aWZzW2ldLm1hYykpOwo+IC0gICAgICAgICAgICAg
ICAgY2hhciAqaWZuYW1lOwo+IC0gICAgICAgICAgICAgICAgaWYgKCF2aWZzW2ldLmlmbmFtZSkg
ewo+IC0gICAgICAgICAgICAgICAgICAgIGlmbmFtZSA9IGxpYnhsX19zcHJpbnRmKGdjLCAidGFw
JWQuJWQiLAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGd1
ZXN0X2RvbWlkLCB2aWZzW2ldLmRldmlkKTsKPiAtICAgICAgICAgICAgICAgIH0gZWxzZSB7Cj4g
LSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gdmlmc1tpXS5pZm5hbWU7Cj4gLSAgICAgICAg
ICAgICAgICB9Cj4gKyAgICAgICAgICAgICAgICBjb25zdCBjaGFyICppZm5hbWUgPSBsaWJ4bF9f
ZGV2aWNlX25pY19kZXZuYW1lKGdjLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBndWVzdF9kb21pZCwgdmlmc1tpXS5kZXZpZCwKPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTElCWExfTklDX1RZUEVfSU9F
TVUpOwo+ICAgICAgICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1kZXZp
Y2UiKTsKPiAgICAgICAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsCj4gICAg
ICAgICAgICAgICAgICAgICAgbGlieGxfX3NwcmludGYoZ2MsICIlcyxpZD1uaWMlZCxuZXRkZXY9
bmV0JWQsbWFjPSVzIiwKPiBkaWZmIC1yIGExNGIxZGQwZmVlZSAtciA0NGZjNzY0ODVmNzkgdG9v
bHMvbGlieGwvbGlieGxfaW50ZXJuYWwuaAo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVy
bmFsLmgJV2VkIEFwciAyNSAxMDo1Mzo1MiAyMDEyICswMTAwCj4gKysrIGIvdG9vbHMvbGlieGwv
bGlieGxfaW50ZXJuYWwuaAlXZWQgQXByIDI1IDEyOjU1OjU3IDIwMTIgKzAxMDAKPiBAQCAtODMs
NiArODMsNyBAQAo+ICAgI2RlZmluZSBTVFVCRE9NX0NPTlNPTEVfUkVTVE9SRSAyCj4gICAjZGVm
aW5lIFNUVUJET01fQ09OU09MRV9TRVJJQUwgMwo+ICAgI2RlZmluZSBTVFVCRE9NX1NQRUNJQUxf
Q09OU09MRVMgMwo+ICsjZGVmaW5lIFRBUF9ERVZJQ0VfU1VGRklYICItZW11Igo+Cj4gICAjZGVm
aW5lIEFSUkFZX1NJWkUoYSkgKHNpemVvZihhKSAvIHNpemVvZihhWzBdKSkKPgo+IEBAIC0xOTYs
MTcgKzE5Nyw2IEBAIF9oaWRkZW4gbGlieGxfX2V2X3hzd2F0Y2ggKmxpYnhsX193YXRjaF8KPiAg
ICAqIHZlcnNpb24gb2YgdGhlIF9ldmRpc2FibGVfRk9PIGZ1bmN0aW9uOyB0aGUgaW50ZXJuYWwg
b25lIGlzCj4gICAgKiB1c2VkIGR1cmluZyBjbGVhbnVwLgo+ICAgICovCj4gLV9oaWRkZW4gaW50
IGxpYnhsX19kb21haW5fY3JlYXRlX2luZm9fc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLAo+IC0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfZG9tYWluX2NyZWF0
ZV9pbmZvICpjX2luZm8pOwo+IC1faGlkZGVuIGludCBsaWJ4bF9fZG9tYWluX2J1aWxkX2luZm9f
c2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmJfaW5mbyk7Cj4gLV9oaWRkZW4g
aW50IGxpYnhsX19kZXZpY2VfZGlza19zZXRkZWZhdWx0KGxpYnhsX19nYyAqZ2MsCj4gLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2RldmljZV9kaXNrICpk
aXNrKTsKPiAtX2hpZGRlbiBpbnQgbGlieGxfX2RldmljZV9uaWNfc2V0ZGVmYXVsdChsaWJ4bF9f
Z2MgKmdjLCBsaWJ4bF9kZXZpY2VfbmljICpuaWMpOwo+IC1faGlkZGVuIGludCBsaWJ4bF9fZGV2
aWNlX3ZmYl9zZXRkZWZhdWx0KGxpYnhsX19nYyAqZ2MsIGxpYnhsX2RldmljZV92ZmIgKnZmYik7
Cj4gLV9oaWRkZW4gaW50IGxpYnhsX19kZXZpY2VfdmtiX3NldGRlZmF1bHQobGlieGxfX2djICpn
YywgbGlieGxfZGV2aWNlX3ZrYiAqdmtiKTsKPiAtX2hpZGRlbiBpbnQgbGlieGxfX2RldmljZV9w
Y2lfc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9kZXZpY2VfcGNpICpwY2kpOwo+IC0K
PiAgIHN0cnVjdCBsaWJ4bF9fZXZnZW5fZG9tYWluX2RlYXRoIHsKPiAgICAgICB1aW50MzJfdCBk
b21pZDsKPiAgICAgICB1bnNpZ25lZCBzaHV0ZG93bl9yZXBvcnRlZDoxLCBkZWF0aF9yZXBvcnRl
ZDoxOwo+IEBAIC03MDQsNiArNjk0LDIxIEBAIF9oaWRkZW4gaW50IGxpYnhsX193YWl0X2Zvcl9i
YWNrZW5kKGxpYngKPiAgICAqICAgICBBbGwgbGlieGwgQVBJIGZ1bmN0aW9ucyBhcmUgZXhwZWN0
ZWQgdG8gaGF2ZSBhcnJhbmdlZCBmb3IgdGhpcwo+ICAgICogICAgIHRvIGJlIGNhbGxlZCBiZWZv
cmUgdXNpbmcgYW55IHZhbHVlcyB3aXRoaW4gdGhlc2Ugc3RydWN0dXJlcy4KPiAgICAqLwo+ICtf
aGlkZGVuIGludCBsaWJ4bF9fZG9tYWluX2NyZWF0ZV9pbmZvX3NldGRlZmF1bHQobGlieGxfX2dj
ICpnYywKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2Rv
bWFpbl9jcmVhdGVfaW5mbyAqY19pbmZvKTsKPiArX2hpZGRlbiBpbnQgbGlieGxfX2RvbWFpbl9i
dWlsZF9pbmZvX3NldGRlZmF1bHQobGlieGxfX2djICpnYywKPiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvICpiX2luZm8pOwo+
ICtfaGlkZGVuIGludCBsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdj
LAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZp
Y2VfZGlzayAqZGlzayk7Cj4gK19oaWRkZW4gaW50IGxpYnhsX19kZXZpY2VfbmljX3NldGRlZmF1
bHQobGlieGxfX2djICpnYywgbGlieGxfZGV2aWNlX25pYyAqbmljKTsKPiArX2hpZGRlbiBpbnQg
bGlieGxfX2RldmljZV92ZmJfc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9kZXZpY2Vf
dmZiICp2ZmIpOwo+ICtfaGlkZGVuIGludCBsaWJ4bF9fZGV2aWNlX3ZrYl9zZXRkZWZhdWx0KGxp
YnhsX19nYyAqZ2MsIGxpYnhsX2RldmljZV92a2IgKnZrYik7Cj4gK19oaWRkZW4gaW50IGxpYnhs
X19kZXZpY2VfcGNpX3NldGRlZmF1bHQobGlieGxfX2djICpnYywgbGlieGxfZGV2aWNlX3BjaSAq
cGNpKTsKPiArCj4gK19oaWRkZW4gY29uc3QgY2hhciAqbGlieGxfX2RldmljZV9uaWNfZGV2bmFt
ZShsaWJ4bF9fZ2MgKmdjLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdWludDMyX3QgZG9taWQsCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50MzJfdCBkZXZpZCwKPiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX25pY190eXBlIHR5cGUpOwo+Cj4gICAvKiBB
cnJhbmdlcyB0aGF0IGRldiB3aWxsIGJlIHJlbW92ZWQgZnJvbSBpdHMgZ3Vlc3QuICBXaGVuCj4g
ICAgKiB0aGlzIGlzIGRvbmUsIHRoZSBhbyB3aWxsIGJlIGNvbXBsZXRlZC4gIEFuIGVycm9yCj4g
ZGlmZiAtciBhMTRiMWRkMGZlZWUgLXIgNDRmYzc2NDg1Zjc5IHRvb2xzL3B5dGhvbi94ZW4veGVu
ZC9pbWFnZS5weQo+IC0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5weQlXZWQgQXBy
IDI1IDEwOjUzOjUyIDIwMTIgKzAxMDAKPiArKysgYi90b29scy9weXRob24veGVuL3hlbmQvaW1h
Z2UucHkJV2VkIEFwciAyNSAxMjo1NTo1NyAyMDEyICswMTAwCj4gQEAgLTkxNywxMSArOTE3LDcg
QEAgY2xhc3MgSFZNSW1hZ2VIYW5kbGVyKEltYWdlSGFuZGxlcik6Cj4gICAgICAgICAgICAgICBy
ZXQuYXBwZW5kKCItbmV0IikKPiAgICAgICAgICAgICAgIHJldC5hcHBlbmQoIm5pYyx2bGFuPSVk
LG1hY2FkZHI9JXMsbW9kZWw9JXMiICUKPiAgICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3Ms
IG1hYywgbW9kZWwpKQo+IC0gICAgICAgICAgICB2aWZuYW1lID0gZGV2aW5mby5nZXQoJ3ZpZm5h
bWUnKQo+IC0gICAgICAgICAgICBpZiB2aWZuYW1lOgo+IC0gICAgICAgICAgICAgICAgdmlmbmFt
ZSA9ICJ0YXAtIiArIHZpZm5hbWUKPiAtICAgICAgICAgICAgZWxzZToKPiAtICAgICAgICAgICAg
ICAgIHZpZm5hbWUgPSAidGFwJWQuJWQiICUgKHNlbGYudm0uZ2V0RG9taWQoKSwgbmljcy0xKQo+
ICsgICAgICAgICAgICB2aWZuYW1lID0gInZpZiVkLiVkLWVtdSIgJSAoc2VsZi52bS5nZXREb21p
ZCgpLCBuaWNzLTEpCj4gICAgICAgICAgICAgICByZXQuYXBwZW5kKCItbmV0IikKPiAgICAgICAg
ICAgICAgIHJldC5hcHBlbmQoInRhcCx2bGFuPSVkLGlmbmFtZT0lcyxicmlkZ2U9JXMiICUKPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3MsIHZpZm5hbWUsIGJyaWRnZSkpCj4KPgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2Io-00040Z-7y; Wed, 25 Apr 2012 13:30:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN2In-00040I-8O
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:30:37 +0000
Received: from [85.158.139.83:64229] by server-8.bemta-5.messagelabs.com id
	0E/94-26964-C7CF79F4; Wed, 25 Apr 2012 13:30:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335360627!25481459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27850 invoked from network); 25 Apr 2012 13:30:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="191989582"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:30:15 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:30:15 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN28D-0002F6-BY;
	Wed, 25 Apr 2012 14:19:41 +0100
Message-ID: <4F97F9F1.4010003@citrix.com>
Date: Wed, 25 Apr 2012 14:19:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
	<20373.35017.147406.379559@mariner.uk.xensource.com>
In-Reply-To: <20373.35017.147406.379559@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_=
path_cleanup"):
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index c7e057d..36d58cd 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpa=
th, int *pdisk,
>>       return -1;
>>   }
>>
>> -
>
> Unrelated whitespace change.

Done.

>> +/*
>> + * Perfrom recursive cleanup of xenstore path, from top to bottom
>> + * just like xenstore-rm -t
>> + */
>> +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);
>
> I think, following my confusion, that this needs some better
> documentation comment.

Ok, I've tried to change to something more self-explaining.

>> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
>> index 3ea8d08..0b1b844 100644
>> --- a/tools/libxl/libxl_xshelp.c
>> +++ b/tools/libxl/libxl_xshelp.c
>> @@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t =
domid)
>>       return s;
>>   }
>>
>> +int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
>> +{
>> +    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>> +    unsigned int nb =3D 0;
>> +    char *last;
>> +
>> +    if (!path)
>> +        return 0;
>> +
>> +    xs_rm(ctx->xsh, XBT_NULL, path);
>> +
>> +    for (last =3D strrchr(path, '/'); last !=3D NULL; last =3D strrchr(=
path, '/')) {
>
> If the path is relative, this won't work correctly.

Are you sure? From what I've tested it seems to work ok.

>
> Also this whole thing needs to take place in a transaction, or it is
> racy.  Probably a transaction supplied by the caller, in which case
> you should assert it.

Ok, will add another lock.

>> +        *last =3D '\0';
>> +        if (!libxl__xs_directory(gc, XBT_NULL, path,&nb))
>> +            continue;
>
> If this fails, it should be a fatal error; we should not just blunder
> on.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2Io-00040Z-7y; Wed, 25 Apr 2012 13:30:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN2In-00040I-8O
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:30:37 +0000
Received: from [85.158.139.83:64229] by server-8.bemta-5.messagelabs.com id
	0E/94-26964-C7CF79F4; Wed, 25 Apr 2012 13:30:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335360627!25481459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27850 invoked from network); 25 Apr 2012 13:30:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="191989582"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 09:30:15 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 09:30:15 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN28D-0002F6-BY;
	Wed, 25 Apr 2012 14:19:41 +0100
Message-ID: <4F97F9F1.4010003@citrix.com>
Date: Wed, 25 Apr 2012 14:19:45 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-3-git-send-email-roger.pau@citrix.com>
	<20373.35017.147406.379559@mariner.uk.xensource.com>
In-Reply-To: <20373.35017.147406.379559@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_=
path_cleanup"):
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index c7e057d..36d58cd 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpa=
th, int *pdisk,
>>       return -1;
>>   }
>>
>> -
>
> Unrelated whitespace change.

Done.

>> +/*
>> + * Perfrom recursive cleanup of xenstore path, from top to bottom
>> + * just like xenstore-rm -t
>> + */
>> +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path);
>
> I think, following my confusion, that this needs some better
> documentation comment.

Ok, I've tried to change to something more self-explaining.

>> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
>> index 3ea8d08..0b1b844 100644
>> --- a/tools/libxl/libxl_xshelp.c
>> +++ b/tools/libxl/libxl_xshelp.c
>> @@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t =
domid)
>>       return s;
>>   }
>>
>> +int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
>> +{
>> +    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>> +    unsigned int nb =3D 0;
>> +    char *last;
>> +
>> +    if (!path)
>> +        return 0;
>> +
>> +    xs_rm(ctx->xsh, XBT_NULL, path);
>> +
>> +    for (last =3D strrchr(path, '/'); last !=3D NULL; last =3D strrchr(=
path, '/')) {
>
> If the path is relative, this won't work correctly.

Are you sure? From what I've tested it seems to work ok.

>
> Also this whole thing needs to take place in a transaction, or it is
> racy.  Probably a transaction supplied by the caller, in which case
> you should assert it.

Ok, will add another lock.

>> +        *last =3D '\0';
>> +        if (!libxl__xs_directory(gc, XBT_NULL, path,&nb))
>> +            continue;
>
> If this fails, it should be a fatal error; we should not just blunder
> on.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2QD-0004Ij-6P; Wed, 25 Apr 2012 13:38:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN2QC-0004Ie-9t
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:16 +0000
Received: from [193.109.254.147:31791] by server-2.bemta-14.messagelabs.com id
	6E/C5-19409-74EF79F4; Wed, 25 Apr 2012 13:38:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335361094!6282711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14635 invoked from network); 25 Apr 2012 13:38:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 14:38:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN2QA-0006Nc-5P; Wed, 25 Apr 2012 13:38:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN2QA-0003UN-1P;
	Wed, 25 Apr 2012 14:38:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.65092.265935.878121@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 14:38:12 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335275974.4347.148.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
	<1335275974.4347.148.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for
 long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for long-running operations"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > This will be used for reporting, during domain creation, that the
> > console is ready.
> 
> I think of progress as being 1%, 2%, 3%...10% etc type stuff. I guess
> progress in the sense you mean here could be thought of as "milestones"?

It might be used for either of those.

> > @@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
> >  {
...
> >      LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
> >          LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
> >          CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
> >      }
> 
> Are the BSD FOREACH_SAFE functions safe against manipulation from other
> threads?

No.  That would mean they'd have to be some kind of RCU thing, which
they are not.

> I only ask because Stefano was surprised that this wasn't the case for
> the Linux macros, in that context "SAFE" just means you can delete the
> element in this thread (like you do here) but that if another thread is
> also manipulating the same list.
...
> By my reading these macros suffer from the same and therefore a bunch
> more locking is needed. I hope I'm mistaken...

The lists in the egc are per-thread data structures.  So that is
safe.  I started writing a reply which contained some proposed
comments for clarifying this situation, and discovered an actual bug -
the ao may be used reentrantly in a way that's not safe.

Please see the patch below, which I hope will clarify things.  This
will go into my series before this progress reporting patch.  I will
update the progress reporting patch with improved comments, but it's
very similar so I think the intent should now be clear.

> > +     * decrememt progress_reports_outstanding, and call us again.
> 
>           decrement

Fixed.

> > +libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
> > +                            const libxl_asyncop_how *how)
> 
> AFAICT this function has just moved and not changed, right?

Yes, this is pointless code motion.  Well actually it doesn't move but
git-diff didn't manage to find it.  I have shuffled things around to
make these hunks go away.

> [...]
> 
> My only concern is about the locking of the list walks -- but if that is
> an issue it will also be there in existing code so I think it can all be
> fixed in one go later. Hence:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

You failed to spot that libxl__ao_progress_report doesn't ever add the
generated aop to the aops_for_callback list :-).  In general the
callback-style interaction with libxl is very lightly tested.  I
expect the appearance of the first user (libvirt, probably) will mean
we have to do some debugging.

Anyway, I'll not add your ack to this just yet.  I'd rather wait until
I've seen what you say about the comments below, and perhaps about the
revised version.

I intend to repost the whole series today.

Ian.


From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Fix an ao completion bug; document locking policy

Document the concurrent access policies for libxl__ao and libxl__egc,
and their corresponding gcs.

Fix a violation of the policy:

If an ao was submitted and a callback requested, and while the
initiating function was still running on the original thread, the ao
is completed on another thread, the completing thread would improperly
concurrently access the ao with the initiating thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl_event.c    |    7 +++++++
 tools/libxl/libxl_internal.h |   23 ++++++++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 2f559d5..7e8d002 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -897,6 +897,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
 
 static void egc_run_callbacks(libxl__egc *egc)
 {
+    /*
+     * The callbacks must happen with the ctx unlocked.
+     * See the comment near #define EGC_GC in libxl_internal.h and
+     * those in the definitions of libxl__egc and libxl__ao.
+     */
     EGC_GC;
     libxl_event *ev, *ev_tmp;
 
@@ -910,9 +915,11 @@ static void egc_run_callbacks(libxl__egc *egc)
                              entry_for_callback, ao_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
         ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        CTX_LOCK;
         ao->notified = 1;
         if (!ao->in_initiator)
             libxl__ao__destroy(CTX, ao);
+        CTX_UNLOCK;
     }
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 72e3fd9..b3657cd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -368,7 +368,8 @@ struct libxl__gc {
 };
 
 struct libxl__egc {
-    /* for event-generating functions only */
+    /* For event-generating functions only.
+     * The egc and its gc may be accessed only on the creating thread. */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
@@ -378,6 +379,20 @@ struct libxl__egc {
 #define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
 
 struct libxl__ao {
+    /*
+     * An ao and its gc may be accessed only with the ctx lock held.
+     *
+     * Special exception: If an ao has been added to
+     * egc->aos_for_callback, the thread owning the egc may remove the
+     * ao from that list and make the callback without holding the
+     * lock.
+     *
+     * Corresponding restriction: An ao may be added only to one
+     * egc->aos_for_callback, once; rc and how must already have been
+     * set and may not be subsequently modified.  (This restriction is
+     * easily and obviously met since the ao is queued for callback
+     * only in libxl__ao_complete.)
+     */
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
@@ -1352,6 +1367,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * should in any case not find it necessary to call egc-creators from
  * within libxl.
  *
+ * The callbacks must all take place with the ctx unlocked because
+ * the application is entitled to reenter libxl from them.  This
+ * would be bad not because the lock is not recursive (it is) but
+ * because the application might make blocking libxl calls which
+ * would hold the lock unreasonably long.
+ *
  * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
  * with the ctx *unlocked*.  So the right pattern has the EGC_...
  * macro calls on the outside of the CTX_... ones.
-- 
tg: (d9d64ad..) t/xen/xl.event.ao-threading-lock-fix (depends on: t/xen/xl.event.domain-create)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2QD-0004Ij-6P; Wed, 25 Apr 2012 13:38:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN2QC-0004Ie-9t
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:16 +0000
Received: from [193.109.254.147:31791] by server-2.bemta-14.messagelabs.com id
	6E/C5-19409-74EF79F4; Wed, 25 Apr 2012 13:38:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335361094!6282711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14635 invoked from network); 25 Apr 2012 13:38:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 14:38:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN2QA-0006Nc-5P; Wed, 25 Apr 2012 13:38:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN2QA-0003UN-1P;
	Wed, 25 Apr 2012 14:38:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.65092.265935.878121@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 14:38:12 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335275974.4347.148.camel@zakaz.uk.xensource.com>
References: <1334596686-8479-1-git-send-email-ian.jackson@eu.citrix.com>
	<1334596686-8479-20-git-send-email-ian.jackson@eu.citrix.com>
	<1335275974.4347.148.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for
 long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 19/24] libxl: provide progress reporting for long-running operations"):
> On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > This will be used for reporting, during domain creation, that the
> > console is ready.
> 
> I think of progress as being 1%, 2%, 3%...10% etc type stuff. I guess
> progress in the sense you mean here could be thought of as "milestones"?

It might be used for either of those.

> > @@ -899,12 +899,25 @@ static void egc_run_callbacks(libxl__egc *egc)
> >  {
...
> >      LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
> >          LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
> >          CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
> >      }
> 
> Are the BSD FOREACH_SAFE functions safe against manipulation from other
> threads?

No.  That would mean they'd have to be some kind of RCU thing, which
they are not.

> I only ask because Stefano was surprised that this wasn't the case for
> the Linux macros, in that context "SAFE" just means you can delete the
> element in this thread (like you do here) but that if another thread is
> also manipulating the same list.
...
> By my reading these macros suffer from the same and therefore a bunch
> more locking is needed. I hope I'm mistaken...

The lists in the egc are per-thread data structures.  So that is
safe.  I started writing a reply which contained some proposed
comments for clarifying this situation, and discovered an actual bug -
the ao may be used reentrantly in a way that's not safe.

Please see the patch below, which I hope will clarify things.  This
will go into my series before this progress reporting patch.  I will
update the progress reporting patch with improved comments, but it's
very similar so I think the intent should now be clear.

> > +     * decrememt progress_reports_outstanding, and call us again.
> 
>           decrement

Fixed.

> > +libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
> > +                            const libxl_asyncop_how *how)
> 
> AFAICT this function has just moved and not changed, right?

Yes, this is pointless code motion.  Well actually it doesn't move but
git-diff didn't manage to find it.  I have shuffled things around to
make these hunks go away.

> [...]
> 
> My only concern is about the locking of the list walks -- but if that is
> an issue it will also be there in existing code so I think it can all be
> fixed in one go later. Hence:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

You failed to spot that libxl__ao_progress_report doesn't ever add the
generated aop to the aops_for_callback list :-).  In general the
callback-style interaction with libxl is very lightly tested.  I
expect the appearance of the first user (libvirt, probably) will mean
we have to do some debugging.

Anyway, I'll not add your ack to this just yet.  I'd rather wait until
I've seen what you say about the comments below, and perhaps about the
revised version.

I intend to repost the whole series today.

Ian.


From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Fix an ao completion bug; document locking policy

Document the concurrent access policies for libxl__ao and libxl__egc,
and their corresponding gcs.

Fix a violation of the policy:

If an ao was submitted and a callback requested, and while the
initiating function was still running on the original thread, the ao
is completed on another thread, the completing thread would improperly
concurrently access the ao with the initiating thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl_event.c    |    7 +++++++
 tools/libxl/libxl_internal.h |   23 ++++++++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 2f559d5..7e8d002 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -897,6 +897,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
 
 static void egc_run_callbacks(libxl__egc *egc)
 {
+    /*
+     * The callbacks must happen with the ctx unlocked.
+     * See the comment near #define EGC_GC in libxl_internal.h and
+     * those in the definitions of libxl__egc and libxl__ao.
+     */
     EGC_GC;
     libxl_event *ev, *ev_tmp;
 
@@ -910,9 +915,11 @@ static void egc_run_callbacks(libxl__egc *egc)
                              entry_for_callback, ao_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
         ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        CTX_LOCK;
         ao->notified = 1;
         if (!ao->in_initiator)
             libxl__ao__destroy(CTX, ao);
+        CTX_UNLOCK;
     }
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 72e3fd9..b3657cd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -368,7 +368,8 @@ struct libxl__gc {
 };
 
 struct libxl__egc {
-    /* for event-generating functions only */
+    /* For event-generating functions only.
+     * The egc and its gc may be accessed only on the creating thread. */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
@@ -378,6 +379,20 @@ struct libxl__egc {
 #define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
 
 struct libxl__ao {
+    /*
+     * An ao and its gc may be accessed only with the ctx lock held.
+     *
+     * Special exception: If an ao has been added to
+     * egc->aos_for_callback, the thread owning the egc may remove the
+     * ao from that list and make the callback without holding the
+     * lock.
+     *
+     * Corresponding restriction: An ao may be added only to one
+     * egc->aos_for_callback, once; rc and how must already have been
+     * set and may not be subsequently modified.  (This restriction is
+     * easily and obviously met since the ao is queued for callback
+     * only in libxl__ao_complete.)
+     */
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
@@ -1352,6 +1367,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * should in any case not find it necessary to call egc-creators from
  * within libxl.
  *
+ * The callbacks must all take place with the ctx unlocked because
+ * the application is entitled to reenter libxl from them.  This
+ * would be bad not because the lock is not recursive (it is) but
+ * because the application might make blocking libxl calls which
+ * would hold the lock unreasonably long.
+ *
  * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
  * with the ctx *unlocked*.  So the right pattern has the EGC_...
  * macro calls on the outside of the CTX_... ones.
-- 
tg: (d9d64ad..) t/xen/xl.event.ao-threading-lock-fix (depends on: t/xen/xl.event.domain-create)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2QU-0004KH-Pd; Wed, 25 Apr 2012 13:38:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN2QS-0004Jz-R3
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:33 +0000
Received: from [85.158.138.51:9878] by server-3.bemta-3.messagelabs.com id
	99/CF-04048-75EF79F4; Wed, 25 Apr 2012 13:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335361111!23710908!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25039 invoked from network); 25 Apr 2012 13:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 14:38:30 +0100
Message-ID: <1335361109.28015.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 14:38:29 +0100
In-Reply-To: <4F97F929.5030707@citrix.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
	<1335348880.28015.24.camel@zakaz.uk.xensource.com>
	<1335358736.28015.41.camel@zakaz.uk.xensource.com>
	<4F97F929.5030707@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Teck Choon Giam <giamteckchoon@gmail.com>, M A
	Young <m.a.young@durham.ac.uk>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTI1IGF0IDE0OjE2ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiA+IE9uIFdlZCwgMjAxMi0wNC0yNSBhdCAxMTox
NCArMDEwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+IE9uIFdlZCwgMjAxMi0wNC0yNSBhdCAx
MToxMSArMDEwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4gPj4+IElhbiBDYW1wYmVsbCB3cml0ZXMg
KCJSZTogW1hlbi1kZXZlbF0gW3BhdGNoXSB4ZW4gdWRldiBydWxlIGludGVyZmVyaW5nIHdpdGgg
b3BlbnZwbiIpOgo+ID4+Pj4gU28gZm9yIHZpZm5hbWU9ImZvbyIgaXQgaXMgYSBuby1icmFpbmVy
IHRvIGNhbGwgdGhlIHZpZiAiZm9vIiBhbmQgdGhlCj4gPj4+PiBlbXVsYXRlZCB0YXAgZGV2aWNl
ICJmb28tZW11Ii4KPiA+Pj4+Cj4gPj4+PiBCdXQgd2hhdCBhYm91dCB0aGUgY2FzZSB3aGVyZSBu
byB2aWZuYW1lIGlzIGdpdmVuLCBpbiB0aGF0IGNhc2UgdmlmIGlzCj4gPj4+PiBuYW1lZCAidmlm
PERPTT4uPERFVj4iLiBCdXQgd2hhdCB0byBjYWxsIHRoZSB0YXA/IFByZXZpb3VzbHkgSSB3YXMK
PiA+Pj4+IGNoYW5naW5nIHRoZSBuYW1lIGZyb20gdGFwPERPTT4uPERFVj4gIHRvIHhlbnRhcDxE
T00+LjxERVY+ICBidXQgcGVyaGFwcwo+ID4+Pj4gbm93ICJ2aWY8RE9NPi48REVWPi1lbXUiIG1h
a2VzIG1vcmUgc2Vuc2UvaXMgbW9yZSBjb25zaXN0ZW50Pwo+ID4+PiBJIHRoaW5rIGVpdGhlciBp
cyBmaW5lLiAgV2hpbGUgd2UncmUgY2hhbmdpbmcgaXQgaXQgcHJvYmFibHkgbWFrZXMKPiA+Pj4g
c2Vuc2UgdG8gdXNlICJ2aWYuLi4iIGFzIGluZGVlZCBpdCBpcyBtb3JlIGNvbnNpc3RlbnQuCj4g
Pj4gT0ssIHZpZlguWSBhbmQgdmlmWC5ZLWVtdSBpdCBpcy4uLgo+ID4KPiA+IFRoaXMgdHVybmVk
IG91dCB0byBiZSBhIGJpdCBtb3JlIGNvbXBsZXggdGhhbiBJIHdhcyBleHBlY3RpbmcsIG1vc3Rs
eQo+ID4gYmVjYXVzZSB0aGUgdXNlIG9mICJ2aWZuYW1lIiB3aXRoIHRhcCBkZXZpY2VzIHdhcyBh
bHJlYWR5IGJyb2tlbi4gSQo+ID4gdGhpbmsgdGhpcyBkb2VzIHRoZSByaWdodCB0aGluZ3Mgd2l0
aCBlYWNoIHR5cGUgb2YgZGV2aWNlLgo+ID4KPiA+IFJvZ2VyLCBub3Qgc3VyZSB3aGF0IGtub2Nr
IG9uIGVmZmVjdCB0aGlzIGhhcyBvbiB5b3VyIHNlcmllcy4gVGhlIG1haW4KPiA+IHRoaW5nIGlz
IGxpa2VseSB0byBiZSB0aGF0IHlvdSBuZWVkbid0IGZpbmQgdGhlIHZpZm5hbWUgc2luY2UgeW91
Cj4gPiBhY3R1YWxseSB3YW50IHRoZSBzdGFuZGFyZCBuYW1lIG5vdCB0aGUgdXNlciBzdXBwbGll
ZCBvbmNlIG9uIG1vc3QKPiA+IG9jY2FzaW9ucy4KPiAKPiAgRnJvbSB3aGF0IEkgc2VlLCBJIGhh
dmUgdG8gcGFzcyB0aGUgbmFtZSByZXR1cm5lZCBieQo+IGxpYnhsX19kZXZpY2VfbmljX2Rldm5h
bWUgdG8gdGhlIGhvdHBsdWcgc2NyaXB0cywgaXMgdGhhdCByaWdodD8KCkFGQUlDVCBwcmV0dHkg
bXVjaCwgeWVzLgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2QU-0004KH-Pd; Wed, 25 Apr 2012 13:38:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN2QS-0004Jz-R3
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:33 +0000
Received: from [85.158.138.51:9878] by server-3.bemta-3.messagelabs.com id
	99/CF-04048-75EF79F4; Wed, 25 Apr 2012 13:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335361111!23710908!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25039 invoked from network); 25 Apr 2012 13:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 14:38:30 +0100
Message-ID: <1335361109.28015.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 14:38:29 +0100
In-Reply-To: <4F97F929.5030707@citrix.com>
References: <alpine.DEB.2.00.1204141534100.30192@vega-b.dur.ac.uk>
	<1334658395.23948.6.camel@zakaz.uk.xensource.com>
	<CAEwRVpP47=mKrcZ_5ATZga4wvkMaSysPh-BEfRorcxrCJ7W6pg@mail.gmail.com>
	<1334817587.11493.44.camel@dagon.hellion.org.uk>
	<1334912603.28331.2.camel@zakaz.uk.xensource.com>
	<20369.15528.270106.567037@mariner.uk.xensource.com>
	<1334918900.28331.47.camel@zakaz.uk.xensource.com>
	<20369.16555.46229.798603@mariner.uk.xensource.com>
	<1334919613.28331.53.camel@zakaz.uk.xensource.com>
	<20369.17085.330843.561841@mariner.uk.xensource.com>
	<1335347949.28015.19.camel@zakaz.uk.xensource.com>
	<20375.52677.287182.934829@mariner.uk.xensource.com>
	<1335348880.28015.24.camel@zakaz.uk.xensource.com>
	<1335358736.28015.41.camel@zakaz.uk.xensource.com>
	<4F97F929.5030707@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Teck Choon Giam <giamteckchoon@gmail.com>, M A
	Young <m.a.young@durham.ac.uk>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTI1IGF0IDE0OjE2ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiA+IE9uIFdlZCwgMjAxMi0wNC0yNSBhdCAxMTox
NCArMDEwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+IE9uIFdlZCwgMjAxMi0wNC0yNSBhdCAx
MToxMSArMDEwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4gPj4+IElhbiBDYW1wYmVsbCB3cml0ZXMg
KCJSZTogW1hlbi1kZXZlbF0gW3BhdGNoXSB4ZW4gdWRldiBydWxlIGludGVyZmVyaW5nIHdpdGgg
b3BlbnZwbiIpOgo+ID4+Pj4gU28gZm9yIHZpZm5hbWU9ImZvbyIgaXQgaXMgYSBuby1icmFpbmVy
IHRvIGNhbGwgdGhlIHZpZiAiZm9vIiBhbmQgdGhlCj4gPj4+PiBlbXVsYXRlZCB0YXAgZGV2aWNl
ICJmb28tZW11Ii4KPiA+Pj4+Cj4gPj4+PiBCdXQgd2hhdCBhYm91dCB0aGUgY2FzZSB3aGVyZSBu
byB2aWZuYW1lIGlzIGdpdmVuLCBpbiB0aGF0IGNhc2UgdmlmIGlzCj4gPj4+PiBuYW1lZCAidmlm
PERPTT4uPERFVj4iLiBCdXQgd2hhdCB0byBjYWxsIHRoZSB0YXA/IFByZXZpb3VzbHkgSSB3YXMK
PiA+Pj4+IGNoYW5naW5nIHRoZSBuYW1lIGZyb20gdGFwPERPTT4uPERFVj4gIHRvIHhlbnRhcDxE
T00+LjxERVY+ICBidXQgcGVyaGFwcwo+ID4+Pj4gbm93ICJ2aWY8RE9NPi48REVWPi1lbXUiIG1h
a2VzIG1vcmUgc2Vuc2UvaXMgbW9yZSBjb25zaXN0ZW50Pwo+ID4+PiBJIHRoaW5rIGVpdGhlciBp
cyBmaW5lLiAgV2hpbGUgd2UncmUgY2hhbmdpbmcgaXQgaXQgcHJvYmFibHkgbWFrZXMKPiA+Pj4g
c2Vuc2UgdG8gdXNlICJ2aWYuLi4iIGFzIGluZGVlZCBpdCBpcyBtb3JlIGNvbnNpc3RlbnQuCj4g
Pj4gT0ssIHZpZlguWSBhbmQgdmlmWC5ZLWVtdSBpdCBpcy4uLgo+ID4KPiA+IFRoaXMgdHVybmVk
IG91dCB0byBiZSBhIGJpdCBtb3JlIGNvbXBsZXggdGhhbiBJIHdhcyBleHBlY3RpbmcsIG1vc3Rs
eQo+ID4gYmVjYXVzZSB0aGUgdXNlIG9mICJ2aWZuYW1lIiB3aXRoIHRhcCBkZXZpY2VzIHdhcyBh
bHJlYWR5IGJyb2tlbi4gSQo+ID4gdGhpbmsgdGhpcyBkb2VzIHRoZSByaWdodCB0aGluZ3Mgd2l0
aCBlYWNoIHR5cGUgb2YgZGV2aWNlLgo+ID4KPiA+IFJvZ2VyLCBub3Qgc3VyZSB3aGF0IGtub2Nr
IG9uIGVmZmVjdCB0aGlzIGhhcyBvbiB5b3VyIHNlcmllcy4gVGhlIG1haW4KPiA+IHRoaW5nIGlz
IGxpa2VseSB0byBiZSB0aGF0IHlvdSBuZWVkbid0IGZpbmQgdGhlIHZpZm5hbWUgc2luY2UgeW91
Cj4gPiBhY3R1YWxseSB3YW50IHRoZSBzdGFuZGFyZCBuYW1lIG5vdCB0aGUgdXNlciBzdXBwbGll
ZCBvbmNlIG9uIG1vc3QKPiA+IG9jY2FzaW9ucy4KPiAKPiAgRnJvbSB3aGF0IEkgc2VlLCBJIGhh
dmUgdG8gcGFzcyB0aGUgbmFtZSByZXR1cm5lZCBieQo+IGxpYnhsX19kZXZpY2VfbmljX2Rldm5h
bWUgdG8gdGhlIGhvdHBsdWcgc2NyaXB0cywgaXMgdGhhdCByaWdodD8KCkFGQUlDVCBwcmV0dHkg
bXVjaCwgeWVzLgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:39:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2Qd-0004LM-5j; Wed, 25 Apr 2012 13:38:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN2Qc-0004LB-BQ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:42 +0000
Received: from [85.158.139.83:34045] by server-6.bemta-5.messagelabs.com id
	93/CC-13222-16EF79F4; Wed, 25 Apr 2012 13:38:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335361120!25437944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15162 invoked from network); 25 Apr 2012 13:38:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 14:38:39 +0100
Date: Wed, 25 Apr 2012 14:44:44 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <4F973568.6000002@vido.info>
Message-ID: <alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
	<20120424163027.GI3213@phenom.dumpdata.com>
	<4F973568.6000002@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Tobias Geiger wrote:
> Hi,
> 
> 9846ff10 was it!
> after reverting it, performance returned to normal.

Argh, that is one of my commits, and is supposed to be a performance
improvement!

I couldn't reproduce the regression you are seeing but the patch is
pretty simple, so just by reading it again I think I manage to spot a
possible error. Could you please try again with the appended patch?



diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4b33acd..0a8a17c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 
 static bool pirq_check_eoi_map(unsigned irq)
 {
-	return test_bit(irq, pirq_eoi_map);
+	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
 
 static bool pirq_needs_eoi_flag(unsigned irq)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:39:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2Qd-0004LM-5j; Wed, 25 Apr 2012 13:38:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN2Qc-0004LB-BQ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:42 +0000
Received: from [85.158.139.83:34045] by server-6.bemta-5.messagelabs.com id
	93/CC-13222-16EF79F4; Wed, 25 Apr 2012 13:38:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335361120!25437944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15162 invoked from network); 25 Apr 2012 13:38:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 14:38:39 +0100
Date: Wed, 25 Apr 2012 14:44:44 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <4F973568.6000002@vido.info>
Message-ID: <alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204241409.44044.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204241344410.26786@kaball-desktop>
	<201204241607.24864.tobias.geiger@vido.info>
	<20120424163027.GI3213@phenom.dumpdata.com>
	<4F973568.6000002@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Tobias Geiger wrote:
> Hi,
> 
> 9846ff10 was it!
> after reverting it, performance returned to normal.

Argh, that is one of my commits, and is supposed to be a performance
improvement!

I couldn't reproduce the regression you are seeing but the patch is
pretty simple, so just by reading it again I think I manage to spot a
possible error. Could you please try again with the appended patch?



diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4b33acd..0a8a17c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 
 static bool pirq_check_eoi_map(unsigned irq)
 {
-	return test_bit(irq, pirq_eoi_map);
+	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
 
 static bool pirq_needs_eoi_flag(unsigned irq)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2Qp-0004Nv-Ig; Wed, 25 Apr 2012 13:38:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN2Qo-0004Na-MS
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:54 +0000
Received: from [85.158.138.51:20578] by server-2.bemta-3.messagelabs.com id
	6B/C0-09269-D6EF79F4; Wed, 25 Apr 2012 13:38:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335361133!23711002!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26600 invoked from network); 25 Apr 2012 13:38:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 14:38:52 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN2Qm-0006Nu-J6; Wed, 25 Apr 2012 13:38:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN2Qm-0003Us-IP;
	Wed, 25 Apr 2012 14:38:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.65132.456936.198162@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 14:38:52 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1335352142-43858-1-git-send-email-roger.pau@citrix.com>
References: <1335352142-43858-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v3] libxl: prevent xl from running if xend is running."):
> Prevent xl from doing any operation if xend daemon is running. That
> prevents bugs that happened when xl and xend raced to close a domain.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2Qp-0004Nv-Ig; Wed, 25 Apr 2012 13:38:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN2Qo-0004Na-MS
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:38:54 +0000
Received: from [85.158.138.51:20578] by server-2.bemta-3.messagelabs.com id
	6B/C0-09269-D6EF79F4; Wed, 25 Apr 2012 13:38:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335361133!23711002!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26600 invoked from network); 25 Apr 2012 13:38:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 13:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12132826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 13:38:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 14:38:52 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN2Qm-0006Nu-J6; Wed, 25 Apr 2012 13:38:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN2Qm-0003Us-IP;
	Wed, 25 Apr 2012 14:38:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20375.65132.456936.198162@mariner.uk.xensource.com>
Date: Wed, 25 Apr 2012 14:38:52 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1335352142-43858-1-git-send-email-roger.pau@citrix.com>
References: <1335352142-43858-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] libxl: prevent xl from running if xend
	is running.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v3] libxl: prevent xl from running if xend is running."):
> Prevent xl from doing any operation if xend daemon is running. That
> prevents bugs that happened when xl and xend raced to close a domain.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:57:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2id-00051P-Do; Wed, 25 Apr 2012 13:57:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SN2ic-00051K-21
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:57:18 +0000
Received: from [193.109.254.147:16042] by server-3.bemta-14.messagelabs.com id
	A4/BC-23274-DB2089F4; Wed, 25 Apr 2012 13:57:17 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335362236!1086222!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25400 invoked from network); 25 Apr 2012 13:57:16 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-10.tower-27.messagelabs.com with SMTP;
	25 Apr 2012 13:57:16 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 71973D3474A;
	Wed, 25 Apr 2012 15:57:16 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Qw5f6VweKJ6M; Wed, 25 Apr 2012 15:57:14 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 6261ED3409F;
	Wed, 25 Apr 2012 15:57:14 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 15:57:13 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F973568.6000002@vido.info>
	<alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201204251557.13353.tobias.geiger@vido.info>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Mittwoch, 25. April 2012, 15:44:44 schrieb Stefano Stabellini:
> On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > Hi,
> > 
> > 9846ff10 was it!
> > after reverting it, performance returned to normal.
> 
> Argh, that is one of my commits, and is supposed to be a performance
> improvement!
> 
> I couldn't reproduce the regression you are seeing but the patch is
> pretty simple, so just by reading it again I think I manage to spot a
> possible error. Could you please try again with the appended patch?
> 
> 
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 4b33acd..0a8a17c 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int
> evtchn)
> 
>  static bool pirq_check_eoi_map(unsigned irq)
>  {
> -	return test_bit(irq, pirq_eoi_map);
> +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
>  }
> 
>  static bool pirq_needs_eoi_flag(unsigned irq)

Looks good; 

I applied it to 3.4.0-rc4 and the performance went to normal again.

Thanks!
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 13:57:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 13:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2id-00051P-Do; Wed, 25 Apr 2012 13:57:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SN2ic-00051K-21
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 13:57:18 +0000
Received: from [193.109.254.147:16042] by server-3.bemta-14.messagelabs.com id
	A4/BC-23274-DB2089F4; Wed, 25 Apr 2012 13:57:17 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335362236!1086222!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25400 invoked from network); 25 Apr 2012 13:57:16 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-10.tower-27.messagelabs.com with SMTP;
	25 Apr 2012 13:57:16 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 71973D3474A;
	Wed, 25 Apr 2012 15:57:16 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Qw5f6VweKJ6M; Wed, 25 Apr 2012 15:57:14 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 6261ED3409F;
	Wed, 25 Apr 2012 15:57:14 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 15:57:13 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F973568.6000002@vido.info>
	<alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201204251557.13353.tobias.geiger@vido.info>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Mittwoch, 25. April 2012, 15:44:44 schrieb Stefano Stabellini:
> On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > Hi,
> > 
> > 9846ff10 was it!
> > after reverting it, performance returned to normal.
> 
> Argh, that is one of my commits, and is supposed to be a performance
> improvement!
> 
> I couldn't reproduce the regression you are seeing but the patch is
> pretty simple, so just by reading it again I think I manage to spot a
> possible error. Could you please try again with the appended patch?
> 
> 
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 4b33acd..0a8a17c 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int
> evtchn)
> 
>  static bool pirq_check_eoi_map(unsigned irq)
>  {
> -	return test_bit(irq, pirq_eoi_map);
> +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
>  }
> 
>  static bool pirq_needs_eoi_flag(unsigned irq)

Looks good; 

I applied it to 3.4.0-rc4 and the performance went to normal again.

Thanks!
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:03:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2np-0005EI-9v; Wed, 25 Apr 2012 14:02:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN2no-0005EB-Gr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:02:40 +0000
Received: from [193.109.254.147:61679] by server-12.bemta-14.messagelabs.com
	id C5/23-05898-FF3089F4; Wed, 25 Apr 2012 14:02:39 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335362559!3822849!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTA1NDk0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19294 invoked from network); 25 Apr 2012 14:02:39 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 14:02:39 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN2nm-0008Mr-CJ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:02:38 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Wed, 25 Apr 2012
	15:01:37 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 15:01:31 +0100
Thread-Topic: xen-unstable libvchan not working
Thread-Index: Ac0i6+4vRVtkMDaZRe+EUPKhtT0ECQ==
Message-ID: <4F9803BB.8060106@newcastle.ac.uk>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Subject: [Xen-devel] xen-unstable libvchan not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everyone,

I have a machine that have built earlier this year and
libvchan works correctly.
Now, I am trying to build a new one but it doesn't work.

I have used the latest xen-unstable.
When I try the vchan-node2 test application I get:

(guest 1 is the server and guest 2 the client)

# ./vchan-node2 server 1 /local/domain/1/data/vchan-1-2
libxenvchan_*_init: No such file or directory

I thought it could be the directory in xenstored so I created it
manually but the error persists.

Anyone has came across this problem?

I have all the required modules and libraries running in
the guests:
# lsmod | grep xen
xen_gntalloc            5536  0
xen_gntdev              9019  0
xen_evtchn              5032  0
xen_kbdfront            4149  0
xen_netfront           16358  0
xenfs                   9621  1
xen_blkfront           12741  3
# mount | grep xen
none on /proc/xen type xenfs (rw,relatime)

# ls /usr/lib64/ | grep xen
libxenctrl.a
libxenctrl.so
libxenctrl.so.4.2
libxenctrl.so.4.2.0
libxenstore.a
libxenstore.so
libxenstore.so.3.0
libxenstore.so.3.0.0
libxenvchan.a
libxenvchan.so
libxenvchan.so.1.0
libxenvchan.so.1.0.0

Cheers,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:03:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2np-0005EI-9v; Wed, 25 Apr 2012 14:02:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN2no-0005EB-Gr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:02:40 +0000
Received: from [193.109.254.147:61679] by server-12.bemta-14.messagelabs.com
	id C5/23-05898-FF3089F4; Wed, 25 Apr 2012 14:02:39 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335362559!3822849!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gMTA1NDk0\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19294 invoked from network); 25 Apr 2012 14:02:39 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 14:02:39 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN2nm-0008Mr-CJ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:02:38 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Wed, 25 Apr 2012
	15:01:37 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 15:01:31 +0100
Thread-Topic: xen-unstable libvchan not working
Thread-Index: Ac0i6+4vRVtkMDaZRe+EUPKhtT0ECQ==
Message-ID: <4F9803BB.8060106@newcastle.ac.uk>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Subject: [Xen-devel] xen-unstable libvchan not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everyone,

I have a machine that have built earlier this year and
libvchan works correctly.
Now, I am trying to build a new one but it doesn't work.

I have used the latest xen-unstable.
When I try the vchan-node2 test application I get:

(guest 1 is the server and guest 2 the client)

# ./vchan-node2 server 1 /local/domain/1/data/vchan-1-2
libxenvchan_*_init: No such file or directory

I thought it could be the directory in xenstored so I created it
manually but the error persists.

Anyone has came across this problem?

I have all the required modules and libraries running in
the guests:
# lsmod | grep xen
xen_gntalloc            5536  0
xen_gntdev              9019  0
xen_evtchn              5032  0
xen_kbdfront            4149  0
xen_netfront           16358  0
xenfs                   9621  1
xen_blkfront           12741  3
# mount | grep xen
none on /proc/xen type xenfs (rw,relatime)

# ls /usr/lib64/ | grep xen
libxenctrl.a
libxenctrl.so
libxenctrl.so.4.2
libxenctrl.so.4.2.0
libxenstore.a
libxenstore.so
libxenstore.so.3.0
libxenstore.so.3.0.0
libxenvchan.a
libxenvchan.so
libxenvchan.so.1.0
libxenvchan.so.1.0.0

Cheers,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:12:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2wZ-0005Qc-AU; Wed, 25 Apr 2012 14:11:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN2wY-0005QV-58
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:11:42 +0000
Received: from [85.158.138.51:46410] by server-12.bemta-3.messagelabs.com id
	66/A0-29760-D16089F4; Wed, 25 Apr 2012 14:11:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335363099!19674873!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11977 invoked from network); 25 Apr 2012 14:11:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 14:11:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="191998132"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:09:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:09:48 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN2ec-000395-LU;
	Wed, 25 Apr 2012 14:53:10 +0100
Message-ID: <4F9801CA.6040800@citrix.com>
Date: Wed, 25 Apr 2012 14:53:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
	<1335263341.4347.75.camel@zakaz.uk.xensource.com>
	<20374.33383.748153.64321@mariner.uk.xensource.com>
In-Reply-To: <20374.33383.748153.64321@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug =
scripts from libxl	for vbd"):
>> On Tue, 2012-04-24 at 11:27 +0100, Ian Jackson wrote:
>>> I was suggesting that the key should be global, and XENBUS_PATH
>>> contains too much.
>> Ah, I saw "latter" and read the last bit of my sentence "per-device", my
>> mistake.
>
> Right.
>
> The reason I think it should be global is that this is a transitional
> bodge to make driver domains continue to work pending a proper
> sorting-out in 4.3.  So there is no need to make it fully general.
>
> Ian.

So the new variable should be global, even between devices, so that we =

either enable hotplug script calling from xl for all, or for none. =

Something like:

/libxl/run_hotplug_scripts

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:12:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN2wZ-0005Qc-AU; Wed, 25 Apr 2012 14:11:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SN2wY-0005QV-58
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:11:42 +0000
Received: from [85.158.138.51:46410] by server-12.bemta-3.messagelabs.com id
	66/A0-29760-D16089F4; Wed, 25 Apr 2012 14:11:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335363099!19674873!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11977 invoked from network); 25 Apr 2012 14:11:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 14:11:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="191998132"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 10:09:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 10:09:48 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SN2ec-000395-LU;
	Wed, 25 Apr 2012 14:53:10 +0100
Message-ID: <4F9801CA.6040800@citrix.com>
Date: Wed, 25 Apr 2012 14:53:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
	<1335263341.4347.75.camel@zakaz.uk.xensource.com>
	<20374.33383.748153.64321@mariner.uk.xensource.com>
In-Reply-To: <20374.33383.748153.64321@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug =
scripts from libxl	for vbd"):
>> On Tue, 2012-04-24 at 11:27 +0100, Ian Jackson wrote:
>>> I was suggesting that the key should be global, and XENBUS_PATH
>>> contains too much.
>> Ah, I saw "latter" and read the last bit of my sentence "per-device", my
>> mistake.
>
> Right.
>
> The reason I think it should be global is that this is a transitional
> bodge to make driver domains continue to work pending a proper
> sorting-out in 4.3.  So there is no need to make it fully general.
>
> Ian.

So the new variable should be global, even between devices, so that we =

either enable hotplug script calling from xl for all, or for none. =

Something like:

/libxl/run_hotplug_scripts

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:27:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3BY-0005h1-SX; Wed, 25 Apr 2012 14:27:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN3BX-0005gu-At
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:27:11 +0000
Received: from [85.158.139.83:16589] by server-10.bemta-5.messagelabs.com id
	4A/C3-08260-EB9089F4; Wed, 25 Apr 2012 14:27:10 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335364029!25449061!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTA1MDQ1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2889 invoked from network); 25 Apr 2012 14:27:10 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 14:27:10 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN3BV-0004LP-Dm
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:27:09 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 25 Apr 2012
	15:26:45 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 15:26:45 +0100
Thread-Topic: xen-unstable libvchan not working
Thread-Index: Ac0i73FDo6iBpm7HSzuTQmLxthq05w==
Message-ID: <4F9809A5.9010309@newcastle.ac.uk>
References: <4F9803BB.8060106@newcastle.ac.uk>
In-Reply-To: <4F9803BB.8060106@newcastle.ac.uk>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable libvchan not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/2012 03:01 PM, Francisco Rocha wrote:
> Hi everyone,
>
> I have a machine that have built earlier this year and
> libvchan works correctly.
> Now, I am trying to build a new one but it doesn't work.
>
> I have used the latest xen-unstable.
> When I try the vchan-node2 test application I get:
>
> (guest 1 is the server and guest 2 the client)
>
> # ./vchan-node2 server 1 /local/domain/1/data/vchan-1-2
> libxenvchan_*_init: No such file or directory
>
> I thought it could be the directory in xenstored so I created it
> manually but the error persists.
>
> Anyone has came across this problem?
I have added some tracing to see which part of the init was
failing. It looks like it is xc_evtchn_open. What can cause
this to fail?
>
> I have all the required modules and libraries running in
> the guests:
> # lsmod | grep xen
> xen_gntalloc            5536  0
> xen_gntdev              9019  0
> xen_evtchn              5032  0
> xen_kbdfront            4149  0
> xen_netfront           16358  0
> xenfs                   9621  1
> xen_blkfront           12741  3
> # mount | grep xen
> none on /proc/xen type xenfs (rw,relatime)
>
> # ls /usr/lib64/ | grep xen
> libxenctrl.a
> libxenctrl.so
> libxenctrl.so.4.2
> libxenctrl.so.4.2.0
> libxenstore.a
> libxenstore.so
> libxenstore.so.3.0
> libxenstore.so.3.0.0
> libxenvchan.a
> libxenvchan.so
> libxenvchan.so.1.0
> libxenvchan.so.1.0.0
>
> Cheers,
> Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:27:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3BY-0005h1-SX; Wed, 25 Apr 2012 14:27:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN3BX-0005gu-At
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:27:11 +0000
Received: from [85.158.139.83:16589] by server-10.bemta-5.messagelabs.com id
	4A/C3-08260-EB9089F4; Wed, 25 Apr 2012 14:27:10 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1335364029!25449061!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTA1MDQ1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2889 invoked from network); 25 Apr 2012 14:27:10 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 14:27:10 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SN3BV-0004LP-Dm
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:27:09 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Wed, 25 Apr 2012
	15:26:45 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 15:26:45 +0100
Thread-Topic: xen-unstable libvchan not working
Thread-Index: Ac0i73FDo6iBpm7HSzuTQmLxthq05w==
Message-ID: <4F9809A5.9010309@newcastle.ac.uk>
References: <4F9803BB.8060106@newcastle.ac.uk>
In-Reply-To: <4F9803BB.8060106@newcastle.ac.uk>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable libvchan not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/2012 03:01 PM, Francisco Rocha wrote:
> Hi everyone,
>
> I have a machine that have built earlier this year and
> libvchan works correctly.
> Now, I am trying to build a new one but it doesn't work.
>
> I have used the latest xen-unstable.
> When I try the vchan-node2 test application I get:
>
> (guest 1 is the server and guest 2 the client)
>
> # ./vchan-node2 server 1 /local/domain/1/data/vchan-1-2
> libxenvchan_*_init: No such file or directory
>
> I thought it could be the directory in xenstored so I created it
> manually but the error persists.
>
> Anyone has came across this problem?
I have added some tracing to see which part of the init was
failing. It looks like it is xc_evtchn_open. What can cause
this to fail?
>
> I have all the required modules and libraries running in
> the guests:
> # lsmod | grep xen
> xen_gntalloc            5536  0
> xen_gntdev              9019  0
> xen_evtchn              5032  0
> xen_kbdfront            4149  0
> xen_netfront           16358  0
> xenfs                   9621  1
> xen_blkfront           12741  3
> # mount | grep xen
> none on /proc/xen type xenfs (rw,relatime)
>
> # ls /usr/lib64/ | grep xen
> libxenctrl.a
> libxenctrl.so
> libxenctrl.so.4.2
> libxenctrl.so.4.2.0
> libxenstore.a
> libxenstore.so
> libxenstore.so.3.0
> libxenstore.so.3.0.0
> libxenvchan.a
> libxenvchan.so
> libxenvchan.so.1.0
> libxenvchan.so.1.0.0
>
> Cheers,
> Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3gd-0006jo-TK; Wed, 25 Apr 2012 14:59:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN3gb-0006jj-Nn
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:59:17 +0000
Received: from [85.158.139.83:25614] by server-6.bemta-5.messagelabs.com id
	DD/D8-13222-441189F4; Wed, 25 Apr 2012 14:59:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335365956!25455626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28882 invoked from network); 25 Apr 2012 14:59:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 14:59:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12135602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 14:59:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 15:59:09 +0100
Message-ID: <1335365948.28015.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 15:59:08 +0100
In-Reply-To: <4F9801CA.6040800@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
	<1335263341.4347.75.camel@zakaz.uk.xensource.com>
	<20374.33383.748153.64321@mariner.uk.xensource.com>
	<4F9801CA.6040800@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTI1IGF0IDE0OjUzICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIEphY2tzb24gZXNjcmliacOzOgo+ID4gSWFuIENhbXBiZWxsIHdyaXRlcyAoIlJlOiBb
WGVuLWRldmVsXSBbUEFUQ0ggdjMgMy81XSBsaWJ4bDogY2FsbCBob3RwbHVnIHNjcmlwdHMgZnJv
bSBsaWJ4bAlmb3IgdmJkIik6Cj4gPj4gT24gVHVlLCAyMDEyLTA0LTI0IGF0IDExOjI3ICswMTAw
LCBJYW4gSmFja3NvbiB3cm90ZToKPiA+Pj4gSSB3YXMgc3VnZ2VzdGluZyB0aGF0IHRoZSBrZXkg
c2hvdWxkIGJlIGdsb2JhbCwgYW5kIFhFTkJVU19QQVRICj4gPj4+IGNvbnRhaW5zIHRvbyBtdWNo
Lgo+ID4+IEFoLCBJIHNhdyAibGF0dGVyIiBhbmQgcmVhZCB0aGUgbGFzdCBiaXQgb2YgbXkgc2Vu
dGVuY2UgInBlci1kZXZpY2UiLCBteQo+ID4+IG1pc3Rha2UuCj4gPgo+ID4gUmlnaHQuCj4gPgo+
ID4gVGhlIHJlYXNvbiBJIHRoaW5rIGl0IHNob3VsZCBiZSBnbG9iYWwgaXMgdGhhdCB0aGlzIGlz
IGEgdHJhbnNpdGlvbmFsCj4gPiBib2RnZSB0byBtYWtlIGRyaXZlciBkb21haW5zIGNvbnRpbnVl
IHRvIHdvcmsgcGVuZGluZyBhIHByb3Blcgo+ID4gc29ydGluZy1vdXQgaW4gNC4zLiAgU28gdGhl
cmUgaXMgbm8gbmVlZCB0byBtYWtlIGl0IGZ1bGx5IGdlbmVyYWwuCj4gPgo+ID4gSWFuLgo+IAo+
IFNvIHRoZSBuZXcgdmFyaWFibGUgc2hvdWxkIGJlIGdsb2JhbCwgZXZlbiBiZXR3ZWVuIGRldmlj
ZXMsIHNvIHRoYXQgd2UgCj4gZWl0aGVyIGVuYWJsZSBob3RwbHVnIHNjcmlwdCBjYWxsaW5nIGZy
b20geGwgZm9yIGFsbCwgb3IgZm9yIG5vbmUuIAo+IFNvbWV0aGluZyBsaWtlOgo+IAo+IC9saWJ4
bC9ydW5faG90cGx1Z19zY3JpcHRzCgpJdCBzdGlsbCBuZWVkcyB0byBiZSBwZXItYmFja2VuZCBk
b21haW4sIGRvZXNuJ3QgaXQ/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 14:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 14:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3gd-0006jo-TK; Wed, 25 Apr 2012 14:59:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN3gb-0006jj-Nn
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 14:59:17 +0000
Received: from [85.158.139.83:25614] by server-6.bemta-5.messagelabs.com id
	DD/D8-13222-441189F4; Wed, 25 Apr 2012 14:59:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335365956!25455626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28882 invoked from network); 25 Apr 2012 14:59:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 14:59:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12135602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 14:59:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 15:59:09 +0100
Message-ID: <1335365948.28015.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 25 Apr 2012 15:59:08 +0100
In-Reply-To: <4F9801CA.6040800@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<1335258998.4347.59.camel@zakaz.uk.xensource.com>
	<20374.31730.484142.339795@mariner.uk.xensource.com>
	<1335262630.4347.73.camel@zakaz.uk.xensource.com>
	<20374.32791.895351.745797@mariner.uk.xensource.com>
	<1335263341.4347.75.camel@zakaz.uk.xensource.com>
	<20374.33383.748153.64321@mariner.uk.xensource.com>
	<4F9801CA.6040800@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 3/5] libxl: call hotplug scripts from
 libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTI1IGF0IDE0OjUzICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIEphY2tzb24gZXNjcmliacOzOgo+ID4gSWFuIENhbXBiZWxsIHdyaXRlcyAoIlJlOiBb
WGVuLWRldmVsXSBbUEFUQ0ggdjMgMy81XSBsaWJ4bDogY2FsbCBob3RwbHVnIHNjcmlwdHMgZnJv
bSBsaWJ4bAlmb3IgdmJkIik6Cj4gPj4gT24gVHVlLCAyMDEyLTA0LTI0IGF0IDExOjI3ICswMTAw
LCBJYW4gSmFja3NvbiB3cm90ZToKPiA+Pj4gSSB3YXMgc3VnZ2VzdGluZyB0aGF0IHRoZSBrZXkg
c2hvdWxkIGJlIGdsb2JhbCwgYW5kIFhFTkJVU19QQVRICj4gPj4+IGNvbnRhaW5zIHRvbyBtdWNo
Lgo+ID4+IEFoLCBJIHNhdyAibGF0dGVyIiBhbmQgcmVhZCB0aGUgbGFzdCBiaXQgb2YgbXkgc2Vu
dGVuY2UgInBlci1kZXZpY2UiLCBteQo+ID4+IG1pc3Rha2UuCj4gPgo+ID4gUmlnaHQuCj4gPgo+
ID4gVGhlIHJlYXNvbiBJIHRoaW5rIGl0IHNob3VsZCBiZSBnbG9iYWwgaXMgdGhhdCB0aGlzIGlz
IGEgdHJhbnNpdGlvbmFsCj4gPiBib2RnZSB0byBtYWtlIGRyaXZlciBkb21haW5zIGNvbnRpbnVl
IHRvIHdvcmsgcGVuZGluZyBhIHByb3Blcgo+ID4gc29ydGluZy1vdXQgaW4gNC4zLiAgU28gdGhl
cmUgaXMgbm8gbmVlZCB0byBtYWtlIGl0IGZ1bGx5IGdlbmVyYWwuCj4gPgo+ID4gSWFuLgo+IAo+
IFNvIHRoZSBuZXcgdmFyaWFibGUgc2hvdWxkIGJlIGdsb2JhbCwgZXZlbiBiZXR3ZWVuIGRldmlj
ZXMsIHNvIHRoYXQgd2UgCj4gZWl0aGVyIGVuYWJsZSBob3RwbHVnIHNjcmlwdCBjYWxsaW5nIGZy
b20geGwgZm9yIGFsbCwgb3IgZm9yIG5vbmUuIAo+IFNvbWV0aGluZyBsaWtlOgo+IAo+IC9saWJ4
bC9ydW5faG90cGx1Z19zY3JpcHRzCgpJdCBzdGlsbCBuZWVkcyB0byBiZSBwZXItYmFja2VuZCBk
b21haW4sIGRvZXNuJ3QgaXQ/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:00:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3hR-0006pH-Gv; Wed, 25 Apr 2012 15:00:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN3hQ-0006p9-Lb
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:00:08 +0000
Received: from [85.158.138.51:26261] by server-8.bemta-3.messagelabs.com id
	39/1D-24428-771189F4; Wed, 25 Apr 2012 15:00:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335366006!15829156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7132 invoked from network); 25 Apr 2012 15:00:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:00:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12135613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 14:59:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 15:59:36 +0100
Date: Wed, 25 Apr 2012 16:05:26 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204251557.13353.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204251605140.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F973568.6000002@vido.info>
	<alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
	<201204251557.13353.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Tobias Geiger wrote:
> Am Mittwoch, 25. April 2012, 15:44:44 schrieb Stefano Stabellini:
> > On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > > Hi,
> > > 
> > > 9846ff10 was it!
> > > after reverting it, performance returned to normal.
> > 
> > Argh, that is one of my commits, and is supposed to be a performance
> > improvement!
> > 
> > I couldn't reproduce the regression you are seeing but the patch is
> > pretty simple, so just by reading it again I think I manage to spot a
> > possible error. Could you please try again with the appended patch?
> > 
> > 
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 4b33acd..0a8a17c 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int
> > evtchn)
> > 
> >  static bool pirq_check_eoi_map(unsigned irq)
> >  {
> > -	return test_bit(irq, pirq_eoi_map);
> > +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
> >  }
> > 
> >  static bool pirq_needs_eoi_flag(unsigned irq)
> 
> Looks good; 
> 
> I applied it to 3.4.0-rc4 and the performance went to normal again.

I'll add your tested-by if it is OK for you

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:00:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3hR-0006pH-Gv; Wed, 25 Apr 2012 15:00:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN3hQ-0006p9-Lb
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:00:08 +0000
Received: from [85.158.138.51:26261] by server-8.bemta-3.messagelabs.com id
	39/1D-24428-771189F4; Wed, 25 Apr 2012 15:00:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335366006!15829156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7132 invoked from network); 25 Apr 2012 15:00:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:00:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12135613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 14:59:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 15:59:36 +0100
Date: Wed, 25 Apr 2012 16:05:26 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <201204251557.13353.tobias.geiger@vido.info>
Message-ID: <alpine.DEB.2.00.1204251605140.26786@kaball-desktop>
References: <201204231202.27731.tobias.geiger@vido.info>
	<4F973568.6000002@vido.info>
	<alpine.DEB.2.00.1204251356260.26786@kaball-desktop>
	<201204251557.13353.tobias.geiger@vido.info>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
 in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Tobias Geiger wrote:
> Am Mittwoch, 25. April 2012, 15:44:44 schrieb Stefano Stabellini:
> > On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > > Hi,
> > > 
> > > 9846ff10 was it!
> > > after reverting it, performance returned to normal.
> > 
> > Argh, that is one of my commits, and is supposed to be a performance
> > improvement!
> > 
> > I couldn't reproduce the regression you are seeing but the patch is
> > pretty simple, so just by reading it again I think I manage to spot a
> > possible error. Could you please try again with the appended patch?
> > 
> > 
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 4b33acd..0a8a17c 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int
> > evtchn)
> > 
> >  static bool pirq_check_eoi_map(unsigned irq)
> >  {
> > -	return test_bit(irq, pirq_eoi_map);
> > +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
> >  }
> > 
> >  static bool pirq_needs_eoi_flag(unsigned irq)
> 
> Looks good; 
> 
> I applied it to 3.4.0-rc4 and the performance went to normal again.

I'll add your tested-by if it is OK for you

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:01:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3iW-0006vA-VZ; Wed, 25 Apr 2012 15:01:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SN3iV-0006uu-EG
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:01:15 +0000
Received: from [85.158.143.99:58889] by server-3.bemta-4.messagelabs.com id
	0D/69-05853-AB1189F4; Wed, 25 Apr 2012 15:01:14 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335366072!18198187!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNDEw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31541 invoked from network); 25 Apr 2012 15:01:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 15:01:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3PF19hD027833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Apr 2012 15:01:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3PF19K3026413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Apr 2012 15:01:09 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3PF18pR018280; Wed, 25 Apr 2012 10:01:08 -0500
MIME-Version: 1.0
Message-ID: <a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
Date: Wed, 25 Apr 2012 08:01:01 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
In-Reply-To: <4F97DF91020000780007FE82@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, April 25, 2012 3:27 AM
> To: Boris Ostrovsky; Dan Magenheimer
> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org
> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> >>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> > # HG changeset patch
> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> > # Date 1334875170 14400
> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> >
> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> > Acked-by: Wei Huang <wei.huang2@amd.com>
> > Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> So what's the status of the discussion around this patch? Were
> your concerns all addressed, Dan? Is there any re-submisson
> necessary/planned?

My concerns will be addressed when there is a fully-functional
adequately-tested full-stack implementation, rather than "we
have a new instruction that should solve (part of) this problem,
let's turn it on by default."

While I wish I could invest the time required to do (or
participate in) the testing, sadly I can't, so I understand
if my opinion is discarded.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:01:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3iW-0006vA-VZ; Wed, 25 Apr 2012 15:01:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SN3iV-0006uu-EG
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:01:15 +0000
Received: from [85.158.143.99:58889] by server-3.bemta-4.messagelabs.com id
	0D/69-05853-AB1189F4; Wed, 25 Apr 2012 15:01:14 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335366072!18198187!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNDEw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31541 invoked from network); 25 Apr 2012 15:01:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Apr 2012 15:01:13 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3PF19hD027833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Apr 2012 15:01:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3PF19K3026413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Apr 2012 15:01:09 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3PF18pR018280; Wed, 25 Apr 2012 10:01:08 -0500
MIME-Version: 1.0
Message-ID: <a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
Date: Wed, 25 Apr 2012 08:01:01 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
In-Reply-To: <4F97DF91020000780007FE82@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, April 25, 2012 3:27 AM
> To: Boris Ostrovsky; Dan Magenheimer
> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org
> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> >>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> > # HG changeset patch
> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> > # Date 1334875170 14400
> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> >
> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> > Acked-by: Wei Huang <wei.huang2@amd.com>
> > Tested-by: Wei Huang <wei.huang2@amd.com>
> 
> So what's the status of the discussion around this patch? Were
> your concerns all addressed, Dan? Is there any re-submisson
> necessary/planned?

My concerns will be addressed when there is a fully-functional
adequately-tested full-stack implementation, rather than "we
have a new instruction that should solve (part of) this problem,
let's turn it on by default."

While I wish I could invest the time required to do (or
participate in) the testing, sadly I can't, so I understand
if my opinion is discarded.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3kL-00074C-JY; Wed, 25 Apr 2012 15:03:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SN3kJ-00073v-Uc
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:03:08 +0000
Received: from [85.158.138.51:47680] by server-10.bemta-3.messagelabs.com id
	6A/2F-29478-B22189F4; Wed, 25 Apr 2012 15:03:07 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335366186!15829796!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19633 invoked from network); 25 Apr 2012 15:03:06 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-12.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 15:03:06 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 4E33DD3474A;
	Wed, 25 Apr 2012 17:03:06 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id CeYnkV49m2Jp; Wed, 25 Apr 2012 17:03:03 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 6B2E0D3462D;
	Wed, 25 Apr 2012 17:03:03 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 17:03:02 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204251557.13353.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204251605140.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204251605140.26786@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201204251703.02497.tobias.geiger@vido.info>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Mittwoch, 25. April 2012, 17:05:26 schrieb Stefano Stabellini:
> On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > Am Mittwoch, 25. April 2012, 15:44:44 schrieb Stefano Stabellini:
> > > On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > > > Hi,
> > > > 
> > > > 9846ff10 was it!
> > > > after reverting it, performance returned to normal.
> > > 
> > > Argh, that is one of my commits, and is supposed to be a performance
> > > improvement!
> > > 
> > > I couldn't reproduce the regression you are seeing but the patch is
> > > pretty simple, so just by reading it again I think I manage to spot a
> > > possible error. Could you please try again with the appended patch?
> > > 
> > > 
> > > 
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 4b33acd..0a8a17c 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int
> > > evtchn)
> > > 
> > >  static bool pirq_check_eoi_map(unsigned irq)
> > >  {
> > > 
> > > -	return test_bit(irq, pirq_eoi_map);
> > > +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
> > > 
> > >  }
> > >  
> > >  static bool pirq_needs_eoi_flag(unsigned irq)
> > 
> > Looks good;
> > 
> > I applied it to 3.4.0-rc4 and the performance went to normal again.
> 
> I'll add your tested-by if it is OK for you

of course - thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3kL-00074C-JY; Wed, 25 Apr 2012 15:03:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1SN3kJ-00073v-Uc
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:03:08 +0000
Received: from [85.158.138.51:47680] by server-10.bemta-3.messagelabs.com id
	6A/2F-29478-B22189F4; Wed, 25 Apr 2012 15:03:07 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335366186!15829796!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19633 invoked from network); 25 Apr 2012 15:03:06 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-12.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 15:03:06 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 4E33DD3474A;
	Wed, 25 Apr 2012 17:03:06 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id CeYnkV49m2Jp; Wed, 25 Apr 2012 17:03:03 +0200 (CEST)
Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 6B2E0D3462D;
	Wed, 25 Apr 2012 17:03:03 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 25 Apr 2012 17:03:02 +0200
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201204231202.27731.tobias.geiger@vido.info>
	<201204251557.13353.tobias.geiger@vido.info>
	<alpine.DEB.2.00.1204251605140.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1204251605140.26786@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201204251703.02497.tobias.geiger@vido.info>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Degregated I/O Performance since 3.4 - Regression
	in 3.4?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Mittwoch, 25. April 2012, 17:05:26 schrieb Stefano Stabellini:
> On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > Am Mittwoch, 25. April 2012, 15:44:44 schrieb Stefano Stabellini:
> > > On Wed, 25 Apr 2012, Tobias Geiger wrote:
> > > > Hi,
> > > > 
> > > > 9846ff10 was it!
> > > > after reverting it, performance returned to normal.
> > > 
> > > Argh, that is one of my commits, and is supposed to be a performance
> > > improvement!
> > > 
> > > I couldn't reproduce the regression you are seeing but the patch is
> > > pretty simple, so just by reading it again I think I manage to spot a
> > > possible error. Could you please try again with the appended patch?
> > > 
> > > 
> > > 
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 4b33acd..0a8a17c 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int
> > > evtchn)
> > > 
> > >  static bool pirq_check_eoi_map(unsigned irq)
> > >  {
> > > 
> > > -	return test_bit(irq, pirq_eoi_map);
> > > +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
> > > 
> > >  }
> > >  
> > >  static bool pirq_needs_eoi_flag(unsigned irq)
> > 
> > Looks good;
> > 
> > I applied it to 3.4.0-rc4 and the performance went to normal again.
> 
> I'll add your tested-by if it is OK for you

of course - thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:16:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3wf-0007R2-VI; Wed, 25 Apr 2012 15:15:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN3we-0007Qx-MD
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:15:52 +0000
Received: from [193.109.254.147:49502] by server-2.bemta-14.messagelabs.com id
	C1/B7-19409-825189F4; Wed, 25 Apr 2012 15:15:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335366927!6269081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22190 invoked from network); 25 Apr 2012 15:15:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:15:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="192014963"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:06:30 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:06:29 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SN3mS-0004OQ-6V; Wed, 25 Apr 2012 16:05:21 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:11:38 +0100
Message-ID: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: tobias.geiger@vido.info,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen: use the pirq number to check the
	pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In pirq_check_eoi_map use the pirq number rather than the Linux irq
number to check whether an eoi is needed in the pirq_eoi_map.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Tobias Geiger <tobias.geiger@vido.info>
---
 drivers/xen/events.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4b33acd..0a8a17c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 
 static bool pirq_check_eoi_map(unsigned irq)
 {
-	return test_bit(irq, pirq_eoi_map);
+	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
 
 static bool pirq_needs_eoi_flag(unsigned irq)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:16:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN3wf-0007R2-VI; Wed, 25 Apr 2012 15:15:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN3we-0007Qx-MD
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:15:52 +0000
Received: from [193.109.254.147:49502] by server-2.bemta-14.messagelabs.com id
	C1/B7-19409-825189F4; Wed, 25 Apr 2012 15:15:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335366927!6269081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDY4NzM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22190 invoked from network); 25 Apr 2012 15:15:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:15:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="192014963"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 11:06:30 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:06:29 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SN3mS-0004OQ-6V; Wed, 25 Apr 2012 16:05:21 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:11:38 +0100
Message-ID: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: tobias.geiger@vido.info,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen: use the pirq number to check the
	pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In pirq_check_eoi_map use the pirq number rather than the Linux irq
number to check whether an eoi is needed in the pirq_eoi_map.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Tobias Geiger <tobias.geiger@vido.info>
---
 drivers/xen/events.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4b33acd..0a8a17c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 
 static bool pirq_check_eoi_map(unsigned irq)
 {
-	return test_bit(irq, pirq_eoi_map);
+	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
 
 static bool pirq_needs_eoi_flag(unsigned irq)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:20:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN40v-0007bh-Lb; Wed, 25 Apr 2012 15:20:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SN40u-0007ba-4O
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:20:16 +0000
Received: from [85.158.138.51:47491] by server-2.bemta-3.messagelabs.com id
	27/3B-09269-F26189F4; Wed, 25 Apr 2012 15:20:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335367214!23754557!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjA5MTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16976 invoked from network); 25 Apr 2012 15:20:14 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 15:20:14 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 55AF8604079;
	Wed, 25 Apr 2012 08:20:13 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=HMRUSz9c6LgmJRgfKrnCyGHXJ5j41N6sFAp4JIvos5yw
	LvZEFHAEtZ4TUbMfOCQSyUfiNQ4wj6NmAbu1SzBVoswlR307rUyXOusqwmaoQpo5
	oG754iv3xQAg+CntAxTXf/gu01kpBMCaL+lIhQ7L9XytxXKnWVtgpk999BohtMo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=EE0AwHkGGZxvqVn31lkxior/FOg=; b=V9trSg1X
	8Yg7Kc8DDsILpAlugctiiv0mo5r9SpLmYxEaNQ+ZIVafPWGNCFhBg0hexUdd3ibf
	9yI8ogXDwztjTnRbfDQsbyKjgeyjzlAxXkOaG1X+JHIVj/t0ctidiMIJ0xlsGxAt
	p/An5fYPEtbhrVIFr7tkPZdoLDVlko2Buig=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 8FC3B604078; 
	Wed, 25 Apr 2012 08:20:12 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 25 Apr 2012 08:20:13 -0700
Message-ID: <1eca79e04d540f6c44b72e865c19c3b9.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120425124147.GD51354@ocelot.phlegethon.org>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
	<51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
	<20120425124147.GD51354@ocelot.phlegethon.org>
Date: Wed, 25 Apr 2012 08:20:13 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mem_sharing: Rectify test for
 "empty" physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 15:20 -0400 on 24 Apr (1335280819), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c |  7 ++++---
>>  xen/include/asm-x86/p2m.h     |  8 ++++++++
>>  2 files changed, 12 insertions(+), 3 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 5be9a05f17fd -r 51646b89b182 xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
>>      if ( spage->sharing->handle != sh )
>>          goto err_unlock;
>>
>> -    /* Make sure the target page is a hole in the physmap */
>> -    if ( mfn_valid(cmfn) ||
>> -         (!(p2m_is_ram(cmfn_type))) )
>> +    /* Make sure the target page is a hole in the physmap. These are
>> typically
>> +     * p2m_mmio_dm, but also accept p2m_invalid and paged out pages.
>> See the
>> +     * definition of p2m_is_hole in p2m.h. */
>> +    if ( !p2m_is_hole(cmfn_type) || mfn_valid(cmfn) )
>
> Hmm.  Is the mfn_valid() to handle p2m_ram_paging_in entries sometimes
> having an MFN and sometimes not?  I think it would be nicer to either
> always replace paging-in pages or never do it.  In any case, it's bogus
> to test mfn_valid() for any of the other types.

Yes, that is the concern. paging_in entries may have a backing mfn. I am
not opposed to just replacing the entry if it is in paging_in state,
regardless of the mfn. It would be similar to any of the cases in which
guest_physmap_add_entry is used with a valid mfn in the entry to be
updated.

Andres

>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:20:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN40v-0007bh-Lb; Wed, 25 Apr 2012 15:20:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SN40u-0007ba-4O
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:20:16 +0000
Received: from [85.158.138.51:47491] by server-2.bemta-3.messagelabs.com id
	27/3B-09269-F26189F4; Wed, 25 Apr 2012 15:20:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335367214!23754557!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjA5MTA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16976 invoked from network); 25 Apr 2012 15:20:14 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 15:20:14 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 55AF8604079;
	Wed, 25 Apr 2012 08:20:13 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=HMRUSz9c6LgmJRgfKrnCyGHXJ5j41N6sFAp4JIvos5yw
	LvZEFHAEtZ4TUbMfOCQSyUfiNQ4wj6NmAbu1SzBVoswlR307rUyXOusqwmaoQpo5
	oG754iv3xQAg+CntAxTXf/gu01kpBMCaL+lIhQ7L9XytxXKnWVtgpk999BohtMo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=EE0AwHkGGZxvqVn31lkxior/FOg=; b=V9trSg1X
	8Yg7Kc8DDsILpAlugctiiv0mo5r9SpLmYxEaNQ+ZIVafPWGNCFhBg0hexUdd3ibf
	9yI8ogXDwztjTnRbfDQsbyKjgeyjzlAxXkOaG1X+JHIVj/t0ctidiMIJ0xlsGxAt
	p/An5fYPEtbhrVIFr7tkPZdoLDVlko2Buig=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 8FC3B604078; 
	Wed, 25 Apr 2012 08:20:12 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 25 Apr 2012 08:20:13 -0700
Message-ID: <1eca79e04d540f6c44b72e865c19c3b9.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120425124147.GD51354@ocelot.phlegethon.org>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
	<51646b89b1822fe74ffb.1335295219@xdev.gridcentric.ca>
	<20120425124147.GD51354@ocelot.phlegethon.org>
Date: Wed, 25 Apr 2012 08:20:13 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mem_sharing: Rectify test for
 "empty" physmap entry in sharing_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 15:20 -0400 on 24 Apr (1335280819), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c |  7 ++++---
>>  xen/include/asm-x86/p2m.h     |  8 ++++++++
>>  2 files changed, 12 insertions(+), 3 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 5be9a05f17fd -r 51646b89b182 xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1073,9 +1073,10 @@ int mem_sharing_add_to_physmap(struct do
>>      if ( spage->sharing->handle != sh )
>>          goto err_unlock;
>>
>> -    /* Make sure the target page is a hole in the physmap */
>> -    if ( mfn_valid(cmfn) ||
>> -         (!(p2m_is_ram(cmfn_type))) )
>> +    /* Make sure the target page is a hole in the physmap. These are
>> typically
>> +     * p2m_mmio_dm, but also accept p2m_invalid and paged out pages.
>> See the
>> +     * definition of p2m_is_hole in p2m.h. */
>> +    if ( !p2m_is_hole(cmfn_type) || mfn_valid(cmfn) )
>
> Hmm.  Is the mfn_valid() to handle p2m_ram_paging_in entries sometimes
> having an MFN and sometimes not?  I think it would be nicer to either
> always replace paging-in pages or never do it.  In any case, it's bogus
> to test mfn_valid() for any of the other types.

Yes, that is the concern. paging_in entries may have a backing mfn. I am
not opposed to just replacing the entry if it is in paging_in state,
regardless of the mfn. It would be similar to any of the cases in which
guest_physmap_add_entry is used with a valid mfn in the entry to be
updated.

Andres

>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:28:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN48w-0007mn-L2; Wed, 25 Apr 2012 15:28:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN48v-0007mi-9q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:28:33 +0000
Received: from [85.158.138.51:7181] by server-6.bemta-3.messagelabs.com id
	74/77-05145-028189F4; Wed, 25 Apr 2012 15:28:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335367711!23756097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14188 invoked from network); 25 Apr 2012 15:28:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12136535"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:28:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:28:31 +0100
Date: Wed, 25 Apr 2012 16:34:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335351773.28015.33.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204251632300.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
	<1335350442.28015.29.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
	<1335351773.28015.33.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1335351300 -3600
> # Node ID 28f86b71782a099c0373fb237e6b08e0788ff69d
> # Parent  02f0161ae6201ded5415e7f0c92214b4783c8d72
> libxl: default to xenconsoled for pv guests, even if qemu is running.
> 
> Currently we prefer to use qemu for the disk backend if we are starting qemu
> anyway (e.g. to service a disk).
> 
> Unfortunately qemu doesn't log the console, which xenconsoled can do via
> XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> there is no particular reason to prefer qemu just because it happens to be
> running.
> 
> However we must use qemu if thereis more than one console (xenconsoled only
> supports a single console).
> 
> Therefore push the logic to change the console backend down into
> libxl__need_xenpv_qemu so that it can do the right thing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:28:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN48w-0007mn-L2; Wed, 25 Apr 2012 15:28:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN48v-0007mi-9q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:28:33 +0000
Received: from [85.158.138.51:7181] by server-6.bemta-3.messagelabs.com id
	74/77-05145-028189F4; Wed, 25 Apr 2012 15:28:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335367711!23756097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14188 invoked from network); 25 Apr 2012 15:28:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12136535"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:28:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:28:31 +0100
Date: Wed, 25 Apr 2012 16:34:37 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335351773.28015.33.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204251632300.26786@kaball-desktop>
References: <c8486295429011e9a220.1335348912@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1204251128260.26786@kaball-desktop>
	<1335350442.28015.29.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204251147470.26786@kaball-desktop>
	<1335351773.28015.33.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests,
 even if qemu is running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 25 Apr 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1335351300 -3600
> # Node ID 28f86b71782a099c0373fb237e6b08e0788ff69d
> # Parent  02f0161ae6201ded5415e7f0c92214b4783c8d72
> libxl: default to xenconsoled for pv guests, even if qemu is running.
> 
> Currently we prefer to use qemu for the disk backend if we are starting qemu
> anyway (e.g. to service a disk).
> 
> Unfortunately qemu doesn't log the console, which xenconsoled can do via
> XENCONSOLED_TRACE=guest. Since xenconsoled is also running anyway it seems like
> there is no particular reason to prefer qemu just because it happens to be
> running.
> 
> However we must use qemu if thereis more than one console (xenconsoled only
> supports a single console).
> 
> Therefore push the logic to change the console backend down into
> libxl__need_xenpv_qemu so that it can do the right thing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Dn-0007vb-Iu; Wed, 25 Apr 2012 15:33:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SN4Dl-0007vT-Mh
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:33:33 +0000
Received: from [85.158.138.51:58788] by server-4.bemta-3.messagelabs.com id
	44/C9-15341-C49189F4; Wed, 25 Apr 2012 15:33:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335368011!23788185!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE5Mzc4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6376 invoked from network); 25 Apr 2012 15:33:32 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 15:33:32 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 1EC04458080;
	Wed, 25 Apr 2012 08:33:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dBECX+ndYjkTDe4EinMG6fbwFCUNimFMGzAleDqIBHrW
	i4nPSvZq9jYC+a4BIOzf2w8WN6Tfb1kTmxog40viH/YfJ3iPzwgXDKngchE1nHzr
	QF9rW1cUuWHEd17I8o50t+IHlGOKcq0I4c2xuFwAScBFfBDOxsbk1nGXhG1p4/Y=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jomk5MDNK8vY3Fgun8ZSXnq+SuA=; b=MDVeaehS
	+fZN9uzZq8YLxjZ7p+SRVvnQCJx4BVqFrZEBkmsGa6Ai61T2/Hz8cv5UObMLdEtU
	+SsP6ClT/O1jRRhxUDYMUwg6VNck0AI2jmR6laEapvNTwoN4YFixu8yn9LFDXrd4
	OjSVJKuXeqXI498FmC2J7nDIFQRYJ/o5mYE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 5B09E45807C; 
	Wed, 25 Apr 2012 08:33:30 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 25 Apr 2012 08:33:31 -0700
Message-ID: <9e4ccd16e68b0500fa99dd5a6bd3efab.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120425125103.GE51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
	<20120425125103.GE51354@ocelot.phlegethon.org>
Date: Wed, 25 Apr 2012 08:33:31 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm: Relieve contention for p2m
 lock in gva_to_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 15:34 -0400 on 24 Apr (1335281651), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/hap/guest_walk.c |  6 +++++-
>>  1 files changed, 5 insertions(+), 1 deletions(-)
>>
>>
>> We don't need to hold the p2m lock for the duration of the guest walk.
>> We need
>> to ensure livenes of the top level page.
>
> I'm not sure I want to start taking these s/gfn-lock/get-page/ changes
> piecemeal without a clear understanding of why the gfn-locking is not
> needed.  My understanding was that
>
>  - get_page protects against the page being freed and reused.
>  - gfn-lock protects against the GFN being reused, or the page
>    being reused within the VM.

Most cases gfn_lock protects against are already taken care of by the end
of a query. From there on, get_page will protect you against paging out.

gfn_lock will further protect the caller from the gfn being replaced. That
is the risk we are taking in these code paths, and the assumption is that
the VM would not try that on its own pagetables, GDTs, or mmio targets. If
so, Xen won't misbehave, yet the VM will shoot itself in the foot.
Deservedly.

gfn/p2m lock will also prevent modifications elsewhere in the p2m, and
that is good motivation for a fine-grained lock. These code paths don't
care about modifications elsewhere in the p2m.

I agree it's rather ad hoc, and I'm not happy about it. I would prefer a
proper construct that buries all details, or finding out if rwlocks are
feasible. I'm trying to find ways to relieve contention and address Yang's
problem before the window closes. It hasn't seem that successful anyways.

Andres
>
> Are there some cases where we only care about the first of these and
> some where we care about both?  In other words, can we replace the
> gfn-locking everywhere with get_page/put_page (i.e. get rid of put_gfn)?
>
> Also:
>
>> @@ -85,13 +86,16 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>>
>>      /* Map the top-level table and call the tree-walker */
>>      ASSERT(mfn_valid(mfn_x(top_mfn)));
>> +    top_page = mfn_to_page(mfn_x(top_mfn));
>> +    ASSERT(get_page(top_page, p2m->domain));
>
> ASSERT(foo) is compiled out on non-debug builds, so that's definitely
> not what you want.
>
> I personally dislike this idiom with BUG_ON() as well, because even
> though BUG_ON(some side-effecting statement) may be correct, my eye
> tends to skip over it when skimming code.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Dn-0007vb-Iu; Wed, 25 Apr 2012 15:33:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SN4Dl-0007vT-Mh
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:33:33 +0000
Received: from [85.158.138.51:58788] by server-4.bemta-3.messagelabs.com id
	44/C9-15341-C49189F4; Wed, 25 Apr 2012 15:33:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335368011!23788185!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE5Mzc4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6376 invoked from network); 25 Apr 2012 15:33:32 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	25 Apr 2012 15:33:32 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 1EC04458080;
	Wed, 25 Apr 2012 08:33:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dBECX+ndYjkTDe4EinMG6fbwFCUNimFMGzAleDqIBHrW
	i4nPSvZq9jYC+a4BIOzf2w8WN6Tfb1kTmxog40viH/YfJ3iPzwgXDKngchE1nHzr
	QF9rW1cUuWHEd17I8o50t+IHlGOKcq0I4c2xuFwAScBFfBDOxsbk1nGXhG1p4/Y=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jomk5MDNK8vY3Fgun8ZSXnq+SuA=; b=MDVeaehS
	+fZN9uzZq8YLxjZ7p+SRVvnQCJx4BVqFrZEBkmsGa6Ai61T2/Hz8cv5UObMLdEtU
	+SsP6ClT/O1jRRhxUDYMUwg6VNck0AI2jmR6laEapvNTwoN4YFixu8yn9LFDXrd4
	OjSVJKuXeqXI498FmC2J7nDIFQRYJ/o5mYE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 5B09E45807C; 
	Wed, 25 Apr 2012 08:33:30 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 25 Apr 2012 08:33:31 -0700
Message-ID: <9e4ccd16e68b0500fa99dd5a6bd3efab.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120425125103.GE51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<58fd70123787dd0063fe.1335296051@xdev.gridcentric.ca>
	<20120425125103.GE51354@ocelot.phlegethon.org>
Date: Wed, 25 Apr 2012 08:33:31 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86/mm: Relieve contention for p2m
 lock in gva_to_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 15:34 -0400 on 24 Apr (1335281651), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/hap/guest_walk.c |  6 +++++-
>>  1 files changed, 5 insertions(+), 1 deletions(-)
>>
>>
>> We don't need to hold the p2m lock for the duration of the guest walk.
>> We need
>> to ensure livenes of the top level page.
>
> I'm not sure I want to start taking these s/gfn-lock/get-page/ changes
> piecemeal without a clear understanding of why the gfn-locking is not
> needed.  My understanding was that
>
>  - get_page protects against the page being freed and reused.
>  - gfn-lock protects against the GFN being reused, or the page
>    being reused within the VM.

Most cases gfn_lock protects against are already taken care of by the end
of a query. From there on, get_page will protect you against paging out.

gfn_lock will further protect the caller from the gfn being replaced. That
is the risk we are taking in these code paths, and the assumption is that
the VM would not try that on its own pagetables, GDTs, or mmio targets. If
so, Xen won't misbehave, yet the VM will shoot itself in the foot.
Deservedly.

gfn/p2m lock will also prevent modifications elsewhere in the p2m, and
that is good motivation for a fine-grained lock. These code paths don't
care about modifications elsewhere in the p2m.

I agree it's rather ad hoc, and I'm not happy about it. I would prefer a
proper construct that buries all details, or finding out if rwlocks are
feasible. I'm trying to find ways to relieve contention and address Yang's
problem before the window closes. It hasn't seem that successful anyways.

Andres
>
> Are there some cases where we only care about the first of these and
> some where we care about both?  In other words, can we replace the
> gfn-locking everywhere with get_page/put_page (i.e. get rid of put_gfn)?
>
> Also:
>
>> @@ -85,13 +86,16 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>>
>>      /* Map the top-level table and call the tree-walker */
>>      ASSERT(mfn_valid(mfn_x(top_mfn)));
>> +    top_page = mfn_to_page(mfn_x(top_mfn));
>> +    ASSERT(get_page(top_page, p2m->domain));
>
> ASSERT(foo) is compiled out on non-debug builds, so that's definitely
> not what you want.
>
> I personally dislike this idiom with BUG_ON() as well, because even
> though BUG_ON(some side-effecting statement) may be correct, my eye
> tends to skip over it when skimming code.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4P7-00089G-Vc; Wed, 25 Apr 2012 15:45:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN4P7-00089B-Ar
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:45:17 +0000
Received: from [193.109.254.147:28315] by server-6.bemta-14.messagelabs.com id
	21/A0-02047-C0C189F4; Wed, 25 Apr 2012 15:45:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335368715!1110944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6718 invoked from network); 25 Apr 2012 15:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12136864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:44:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:44:41 +0100
Date: Wed, 25 Apr 2012 16:50:47 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-368691955-1335368244=:26786"
Content-ID: <alpine.DEB.2.00.1204251637350.26786@kaball-desktop>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-368691955-1335368244=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1204251637351.26786@kaball-desktop>

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> On Apr 24, 2012, at 10:03 AM, Stefano Stabellini wrote:
> 
>       Could you please apply the appended patch to the qemu tree and then post
>       the qemu log file again?
> 
> 
> 
> Meanwhile, here's said log with patch applied:
> 
> [root@xentest2012 xen]# more qemu-dm-finnix.log 
> domid: 1
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628
> : Init blktap pipes
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603
> : Created /var/run/tap directory
> Could not open /var/run/tap/qemu-read-1
> char device redirected to /dev/pts/2
> DEBUG blk_init 587
> DEBUG blk_init 602 filename=/var/finnix/finnix-104.iso
> DEBUG blk_init 613 protocol=raw
> DEBUG blk_init 622
> DEBUG blk_init 636
> DEBUG blk_init 659
> xs_read(): target get error. /local/domain/1/target.
> (qemu) (qemu) 

It looks like the disk was opened correctly, maybe more logging will
tell us what is going wrong.
Could you please try the following patch?



diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 64dc93a..f564667 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -50,7 +50,7 @@ const char *xen_protocol;
 
 /* private */
 static TAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = TAILQ_HEAD_INITIALIZER(xendevs);
-static int debug = 0;
+static int debug = 9;
 
 /* ------------------------------------------------------------- */
 
--8323329-368691955-1335368244=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-368691955-1335368244=:26786--


From xen-devel-bounces@lists.xen.org Wed Apr 25 15:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4P7-00089G-Vc; Wed, 25 Apr 2012 15:45:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SN4P7-00089B-Ar
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:45:17 +0000
Received: from [193.109.254.147:28315] by server-6.bemta-14.messagelabs.com id
	21/A0-02047-C0C189F4; Wed, 25 Apr 2012 15:45:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335368715!1110944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6718 invoked from network); 25 Apr 2012 15:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12136864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:44:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:44:41 +0100
Date: Wed, 25 Apr 2012 16:50:47 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-368691955-1335368244=:26786"
Content-ID: <alpine.DEB.2.00.1204251637350.26786@kaball-desktop>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--8323329-368691955-1335368244=:26786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1204251637351.26786@kaball-desktop>

On Tue, 24 Apr 2012, Sam Mulvey wrote:
> On Apr 24, 2012, at 10:03 AM, Stefano Stabellini wrote:
> 
>       Could you please apply the appended patch to the qemu tree and then post
>       the qemu log file again?
> 
> 
> 
> Meanwhile, here's said log with patch applied:
> 
> [root@xentest2012 xen]# more qemu-dm-finnix.log 
> domid: 1
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628
> : Init blktap pipes
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603
> : Created /var/run/tap directory
> Could not open /var/run/tap/qemu-read-1
> char device redirected to /dev/pts/2
> DEBUG blk_init 587
> DEBUG blk_init 602 filename=/var/finnix/finnix-104.iso
> DEBUG blk_init 613 protocol=raw
> DEBUG blk_init 622
> DEBUG blk_init 636
> DEBUG blk_init 659
> xs_read(): target get error. /local/domain/1/target.
> (qemu) (qemu) 

It looks like the disk was opened correctly, maybe more logging will
tell us what is going wrong.
Could you please try the following patch?



diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 64dc93a..f564667 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -50,7 +50,7 @@ const char *xen_protocol;
 
 /* private */
 static TAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = TAILQ_HEAD_INITIALIZER(xendevs);
-static int debug = 0;
+static int debug = 9;
 
 /* ------------------------------------------------------------- */
 
--8323329-368691955-1335368244=:26786
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--8323329-368691955-1335368244=:26786--


From xen-devel-bounces@lists.xen.org Wed Apr 25 15:51:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Uu-0008L3-RI; Wed, 25 Apr 2012 15:51:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SN4Ut-0008Kr-E5
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:51:15 +0000
Received: from [85.158.143.99:17737] by server-3.bemta-4.messagelabs.com id
	6C/FD-05853-F6D189F4; Wed, 25 Apr 2012 15:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335369070!18871746!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25173 invoked from network); 25 Apr 2012 15:51:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 15:51:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 16:51:07 +0100
Message-Id: <4F98399D0200007800080055@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 16:51:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,
	"Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
	<a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
In-Reply-To: <a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 17:01, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, April 25, 2012 3:27 AM
>> To: Boris Ostrovsky; Dan Magenheimer
>> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org 
>> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is 
> supported by hardware
>> 
>> >>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> > # HG changeset patch
>> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> > # Date 1334875170 14400
>> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> >
>> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>> >
>> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> > Acked-by: Wei Huang <wei.huang2@amd.com>
>> > Tested-by: Wei Huang <wei.huang2@amd.com>
>> 
>> So what's the status of the discussion around this patch? Were
>> your concerns all addressed, Dan? Is there any re-submisson
>> necessary/planned?
> 
> My concerns will be addressed when there is a fully-functional
> adequately-tested full-stack implementation, rather than "we
> have a new instruction that should solve (part of) this problem,
> let's turn it on by default."
> 
> While I wish I could invest the time required to do (or
> participate in) the testing, sadly I can't, so I understand
> if my opinion is discarded.

As Keir had asked to get an ACK/NAK from you - is this then a NAK
or a "don't care" or yet something else (it doesn't read anywhere
close to an ACK in any case).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:51:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Uu-0008L3-RI; Wed, 25 Apr 2012 15:51:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SN4Ut-0008Kr-E5
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:51:15 +0000
Received: from [85.158.143.99:17737] by server-3.bemta-4.messagelabs.com id
	6C/FD-05853-F6D189F4; Wed, 25 Apr 2012 15:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335369070!18871746!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25173 invoked from network); 25 Apr 2012 15:51:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 15:51:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Apr 2012 16:51:07 +0100
Message-Id: <4F98399D0200007800080055@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Apr 2012 16:51:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,
	"Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
	<a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
In-Reply-To: <a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 17:01, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, April 25, 2012 3:27 AM
>> To: Boris Ostrovsky; Dan Magenheimer
>> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org 
>> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is 
> supported by hardware
>> 
>> >>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> > # HG changeset patch
>> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> > # Date 1334875170 14400
>> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>> >
>> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>> >
>> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> > Acked-by: Wei Huang <wei.huang2@amd.com>
>> > Tested-by: Wei Huang <wei.huang2@amd.com>
>> 
>> So what's the status of the discussion around this patch? Were
>> your concerns all addressed, Dan? Is there any re-submisson
>> necessary/planned?
> 
> My concerns will be addressed when there is a fully-functional
> adequately-tested full-stack implementation, rather than "we
> have a new instruction that should solve (part of) this problem,
> let's turn it on by default."
> 
> While I wish I could invest the time required to do (or
> participate in) the testing, sadly I can't, so I understand
> if my opinion is discarded.

As Keir had asked to get an ACK/NAK from you - is this then a NAK
or a "don't care" or yet something else (it doesn't read anywhere
close to an ACK in any case).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZV-0008U2-R1; Wed, 25 Apr 2012 15:56:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008T7-EW
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:00 +0000
Received: from [85.158.138.51:30920] by server-10.bemta-3.messagelabs.com id
	3E/E5-29478-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19030 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bh-4G; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZS-0003S2-3B;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:52 +0100
Message-ID: <1335369353-13012-25-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/25] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Abolish libxl_fork.  Its only callers were in xl.  Its functionality
is now moved elsewhere, as follows:

* The "logging version of fork", which is what it was billed as, is now
  xl_fork, which also dies on failure.

* Closing the xenstore handle in the child is now done in
  libxl__ev_child_fork, which is the only remaining place where fork
  is called in libxl.

* We provide a new function libxl__ev_child_xenstore_reopen for
  in-libxl children to make the ctx useable for xenstore again.

* Consequently libxl__spawn_record_pid now no longer needs to mess
  about with its own xenstore handle.  As a bonus it can now just use
  libxl__xs_write.

Also, since we have now converted all the forkers in libxl, we can
always honour the fork_replacement childproc hook - so do so.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   35 ++++++++++++++++-------------------
 tools/libxl/libxl_fork.c     |   25 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 tools/libxl/libxl_utils.c    |   21 ---------------------
 tools/libxl/libxl_utils.h    |    3 +--
 tools/libxl/xl.c             |   12 ++++++++++++
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |    5 ++---
 8 files changed, 61 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index d44b702..d681736 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,34 +127,23 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
-                            pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, pid_t pid)
 {
-    struct xs_handle *xsh = NULL;
-    const char *pid = NULL;
-    int rc, xsok;
+    int r, rc;
 
-    pid = GCSPRINTF("%d", innerchild);
+    rc = libxl__ev_child_xenstore_reopen(gc, spawn->what);
+    if (rc) goto out;
 
-    /* we mustn't use the parent's handle in the child */
-    xsh = xs_daemon_open();
-    if (!xsh) {
-        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
-             spawn->pidpath, pid);
-        rc = ERROR_FAIL;  goto out;
-    }
-
-    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
-    if (!xsok) {
+    r = libxl__xs_write(gc, XBT_NULL, spawn->pidpath, "%d", pid);
+    if (r) {
         LOGE(ERROR,
-             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+             "write %s = %d: xenstore write failed", spawn->pidpath, pid);
         rc = ERROR_FAIL;  goto out;
     }
 
     rc = 0;
 
 out:
-    if (xsh) xs_daemon_close(xsh);
     return rc ? SIGTERM : 0;
 }
 
@@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
     /* we are now the middle process */
 
-    child = fork();
+    pid_t (*fork_replacement)(void*) =
+        CTX->childproc_hooks
+        ? CTX->childproc_hooks->fork_replacement
+        : 0;
+    child =
+        fork_replacement
+        ? fork_replacement(CTX->childproc_user)
+        : fork();
+
     if (child == -1)
         exit(255);
     if (!child) {
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 35c8bdd..9ff99e0 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -347,7 +347,12 @@ pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
 
     if (!pid) {
         /* woohoo! */
-        return 0; /* Yes, CTX is left locked in the child. */
+        if (CTX->xsh) {
+            xs_daemon_destroy_postfork(CTX->xsh);
+            CTX->xsh = NULL; /* turns mistakes into crashes */
+        }
+        /* Yes, CTX is left locked in the child. */
+        return 0;
     }
 
     ch->pid = pid;
@@ -395,6 +400,24 @@ const libxl_childproc_hooks libxl__childproc_default_hooks = {
     libxl_sigchld_owner_libxl, 0, 0
 };
 
+int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what) {
+    int rc;
+
+    assert(!CTX->xsh);
+    CTX->xsh = xs_daemon_open();
+    if (!CTX->xsh) {
+        LOGE(ERROR, "%s: xenstore reopen failed", what);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    libxl_fd_set_cloexec(CTX, xs_fileno(CTX->xsh), 1);
+
+    return 0;
+
+ out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 459c27b..64340af 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -650,6 +650,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
 static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
                 { return childw_out->pid >= 0; }
 
+/* Useable (only) in the child to once more make the ctx useable for
+ * xenstore operations.  logs failure in the form "what: <error
+ * message>". */
+_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what);
+
 
 /*
  * Other event-handling support provided by the libxl event core to
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f0d94c6..858410e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -444,27 +444,6 @@ int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
     return rc;
 }
 
-pid_t libxl_fork(libxl_ctx *ctx)
-{
-    pid_t pid;
-
-    pid = fork();
-    if (pid == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed");
-        return -1;
-    }
-
-    if (!pid) {
-        if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-        ctx->xsh = 0;
-        /* This ensures that anyone who forks but doesn't exec,
-         * and doesn't reinitialise the libxl_ctx, is OK.
-         * It also means they can safely call libxl_ctx_free. */
-    }
-
-    return pid;
-}
-
 int libxl_pipe(libxl_ctx *ctx, int pipes[2])
 {
     if (pipe(pipes) < 0) {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 2b47622..74beb52 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -47,9 +47,8 @@ int libxl_write_exactly(libxl_ctx *ctx, int fd, const void *data,
    * logged using filename (which is only used for logging) and what
    * (which may be 0). */
 
-pid_t libxl_fork(libxl_ctx *ctx);
 int libxl_pipe(libxl_ctx *ctx, int pipes[2]);
-  /* Just like fork(2), pipe(2), but log errors. */
+  /* Just like pipe(2), but log errors. */
 
 void libxl_report_child_exitstatus(libxl_ctx *ctx, xentoollog_level,
                                    const char *what, pid_t pid, int status);
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..d4db1f8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -105,6 +105,18 @@ void postfork(void)
     }
 }
 
+pid_t xl_fork(libxl_ctx *ctx) {
+    pid_t pid;
+
+    pid = fork();
+    if (pid == -1) {
+        perror("fork failed");
+        exit(-1);
+    }
+
+    return pid;
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index f0d0ec8..2b6714a 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+pid_t xl_fork(libxl_ctx *ctx); /* like fork, but prints and dies if it fails */
 void postfork(void);
 
 /* global options */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2e89671..8908581 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1736,7 +1736,7 @@ start:
         pid_t child1, got_child;
         int nullfd;
 
-        child1 = libxl_fork(ctx);
+        child1 = xl_fork(ctx);
         if (child1) {
             printf("Daemon running with PID %d\n", child1);
 
@@ -2775,8 +2775,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     MUST( libxl_pipe(ctx, sendpipe) );
     MUST( libxl_pipe(ctx, recvpipe) );
 
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
+    child = xl_fork(ctx);
 
     if (!child) {
         dup2(sendpipe[0], 0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Ze-0000B0-Oj; Wed, 25 Apr 2012 15:56:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4Zc-00007B-Cr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:08 +0000
Received: from [193.109.254.147:63174] by server-1.bemta-14.messagelabs.com id
	2D/FE-29372-79E189F4; Wed, 25 Apr 2012 15:56:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335369363!1112892!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20916 invoked from network); 25 Apr 2012 15:56:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007au-3q; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qm-2M;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:35 +0100
Message-ID: <1335369353-13012-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/25] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4db0650..f506f56 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1130,6 +1130,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e0aa255..8b3852f 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -593,38 +593,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1a4874c..19b4615 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZZ-00005L-Pp; Wed, 25 Apr 2012 15:56:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uc-CG
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.143.99:56824] by server-3.bemta-4.messagelabs.com id
	EC/72-05853-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7410 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007ag-Nw; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QO-M5;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:29 +0100
Message-ID: <1335369353-13012-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/25] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 34ea15c..4e8ea9a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ _hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZV-0008U2-R1; Wed, 25 Apr 2012 15:56:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008T7-EW
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:00 +0000
Received: from [85.158.138.51:30920] by server-10.bemta-3.messagelabs.com id
	3E/E5-29478-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19030 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bh-4G; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZS-0003S2-3B;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:52 +0100
Message-ID: <1335369353-13012-25-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/25] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Abolish libxl_fork.  Its only callers were in xl.  Its functionality
is now moved elsewhere, as follows:

* The "logging version of fork", which is what it was billed as, is now
  xl_fork, which also dies on failure.

* Closing the xenstore handle in the child is now done in
  libxl__ev_child_fork, which is the only remaining place where fork
  is called in libxl.

* We provide a new function libxl__ev_child_xenstore_reopen for
  in-libxl children to make the ctx useable for xenstore again.

* Consequently libxl__spawn_record_pid now no longer needs to mess
  about with its own xenstore handle.  As a bonus it can now just use
  libxl__xs_write.

Also, since we have now converted all the forkers in libxl, we can
always honour the fork_replacement childproc hook - so do so.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_exec.c     |   35 ++++++++++++++++-------------------
 tools/libxl/libxl_fork.c     |   25 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 tools/libxl/libxl_utils.c    |   21 ---------------------
 tools/libxl/libxl_utils.h    |    3 +--
 tools/libxl/xl.c             |   12 ++++++++++++
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |    5 ++---
 8 files changed, 61 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index d44b702..d681736 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,34 +127,23 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
-                            pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, pid_t pid)
 {
-    struct xs_handle *xsh = NULL;
-    const char *pid = NULL;
-    int rc, xsok;
+    int r, rc;
 
-    pid = GCSPRINTF("%d", innerchild);
+    rc = libxl__ev_child_xenstore_reopen(gc, spawn->what);
+    if (rc) goto out;
 
-    /* we mustn't use the parent's handle in the child */
-    xsh = xs_daemon_open();
-    if (!xsh) {
-        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
-             spawn->pidpath, pid);
-        rc = ERROR_FAIL;  goto out;
-    }
-
-    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
-    if (!xsok) {
+    r = libxl__xs_write(gc, XBT_NULL, spawn->pidpath, "%d", pid);
+    if (r) {
         LOGE(ERROR,
-             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+             "write %s = %d: xenstore write failed", spawn->pidpath, pid);
         rc = ERROR_FAIL;  goto out;
     }
 
     rc = 0;
 
 out:
-    if (xsh) xs_daemon_close(xsh);
     return rc ? SIGTERM : 0;
 }
 
@@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
     /* we are now the middle process */
 
-    child = fork();
+    pid_t (*fork_replacement)(void*) =
+        CTX->childproc_hooks
+        ? CTX->childproc_hooks->fork_replacement
+        : 0;
+    child =
+        fork_replacement
+        ? fork_replacement(CTX->childproc_user)
+        : fork();
+
     if (child == -1)
         exit(255);
     if (!child) {
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 35c8bdd..9ff99e0 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -347,7 +347,12 @@ pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
 
     if (!pid) {
         /* woohoo! */
-        return 0; /* Yes, CTX is left locked in the child. */
+        if (CTX->xsh) {
+            xs_daemon_destroy_postfork(CTX->xsh);
+            CTX->xsh = NULL; /* turns mistakes into crashes */
+        }
+        /* Yes, CTX is left locked in the child. */
+        return 0;
     }
 
     ch->pid = pid;
@@ -395,6 +400,24 @@ const libxl_childproc_hooks libxl__childproc_default_hooks = {
     libxl_sigchld_owner_libxl, 0, 0
 };
 
+int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what) {
+    int rc;
+
+    assert(!CTX->xsh);
+    CTX->xsh = xs_daemon_open();
+    if (!CTX->xsh) {
+        LOGE(ERROR, "%s: xenstore reopen failed", what);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    libxl_fd_set_cloexec(CTX, xs_fileno(CTX->xsh), 1);
+
+    return 0;
+
+ out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 459c27b..64340af 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -650,6 +650,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
 static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
                 { return childw_out->pid >= 0; }
 
+/* Useable (only) in the child to once more make the ctx useable for
+ * xenstore operations.  logs failure in the form "what: <error
+ * message>". */
+_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what);
+
 
 /*
  * Other event-handling support provided by the libxl event core to
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f0d94c6..858410e 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -444,27 +444,6 @@ int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
     return rc;
 }
 
-pid_t libxl_fork(libxl_ctx *ctx)
-{
-    pid_t pid;
-
-    pid = fork();
-    if (pid == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed");
-        return -1;
-    }
-
-    if (!pid) {
-        if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-        ctx->xsh = 0;
-        /* This ensures that anyone who forks but doesn't exec,
-         * and doesn't reinitialise the libxl_ctx, is OK.
-         * It also means they can safely call libxl_ctx_free. */
-    }
-
-    return pid;
-}
-
 int libxl_pipe(libxl_ctx *ctx, int pipes[2])
 {
     if (pipe(pipes) < 0) {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 2b47622..74beb52 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -47,9 +47,8 @@ int libxl_write_exactly(libxl_ctx *ctx, int fd, const void *data,
    * logged using filename (which is only used for logging) and what
    * (which may be 0). */
 
-pid_t libxl_fork(libxl_ctx *ctx);
 int libxl_pipe(libxl_ctx *ctx, int pipes[2]);
-  /* Just like fork(2), pipe(2), but log errors. */
+  /* Just like pipe(2), but log errors. */
 
 void libxl_report_child_exitstatus(libxl_ctx *ctx, xentoollog_level,
                                    const char *what, pid_t pid, int status);
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a6ffd25..d4db1f8 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -105,6 +105,18 @@ void postfork(void)
     }
 }
 
+pid_t xl_fork(libxl_ctx *ctx) {
+    pid_t pid;
+
+    pid = fork();
+    if (pid == -1) {
+        perror("fork failed");
+        exit(-1);
+    }
+
+    return pid;
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index f0d0ec8..2b6714a 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+pid_t xl_fork(libxl_ctx *ctx); /* like fork, but prints and dies if it fails */
 void postfork(void);
 
 /* global options */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2e89671..8908581 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1736,7 +1736,7 @@ start:
         pid_t child1, got_child;
         int nullfd;
 
-        child1 = libxl_fork(ctx);
+        child1 = xl_fork(ctx);
         if (child1) {
             printf("Daemon running with PID %d\n", child1);
 
@@ -2775,8 +2775,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     MUST( libxl_pipe(ctx, sendpipe) );
     MUST( libxl_pipe(ctx, recvpipe) );
 
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
+    child = xl_fork(ctx);
 
     if (!child) {
         dup2(sendpipe[0], 0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Ze-0000B0-Oj; Wed, 25 Apr 2012 15:56:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4Zc-00007B-Cr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:08 +0000
Received: from [193.109.254.147:63174] by server-1.bemta-14.messagelabs.com id
	2D/FE-29372-79E189F4; Wed, 25 Apr 2012 15:56:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335369363!1112892!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20916 invoked from network); 25 Apr 2012 15:56:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007au-3q; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qm-2M;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:35 +0100
Message-ID: <1335369353-13012-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/25] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4db0650..f506f56 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1130,6 +1130,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e0aa255..8b3852f 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -593,38 +593,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1a4874c..19b4615 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
 {
     int i;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zc-000088-Vn; Wed, 25 Apr 2012 15:56:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008VA-5p
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [193.109.254.147:19525] by server-9.bemta-14.messagelabs.com id
	F1/C8-05787-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335369362!623424!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5291 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bT-Ql; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rb-Pv;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:46 +0100
Message-ID: <1335369353-13012-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/25] libxl: make libxl_create run bootloader
	via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change initiate_domain_create to properly use libxl__bootloader_run
rather than improperly calling libxl_run_bootloader with NULL ao_how.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v7:
 * constify convenience aliases.

Changes since v6:
 * Bugfixes from testing.
---
 tools/libxl/libxl_create.c   |   53 +++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 0f17202..e35a944 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -571,6 +571,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int rc);
 
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
@@ -591,6 +594,7 @@ static void initiate_domain_create(libxl__egc *egc,
     const int restore_fd = dcs->restore_fd;
     const libxl_console_ready cb = dcs->console_cb;
     void *const priv = dcs->console_cb_priv;
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
 
@@ -620,21 +624,43 @@ static void initiate_domain_create(libxl__egc *egc,
         if (ret) goto error_out;
     }
 
+    dcs->bl.ao = ao;
     libxl_device_disk *bootdisk =
         d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
 
     if (restore_fd < 0 && bootdisk) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
-                                   0 /* fixme-ao */);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to run bootloader: %d", ret);
-            goto error_out;
-        }
+        dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.info = &d_config->b_info,
+        dcs->bl.disk = bootdisk;
+        dcs->bl.domid = dcs->guest_domid;
+            
+        libxl__bootloader_run(egc, &dcs->bl);
+    } else {
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     }
+    return;
 
-    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
-    libxl__domain_build_state *state = &dcs->build_state;
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
+    if (ret) goto error_out;
 
     /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm.
      * Fill in any field required by either, including both relevant
@@ -788,12 +814,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
+        ret = libxl__e820_alloc(gc, domid, d_config);
+        if (ret) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
+                      ret, errno);
+            goto error_out;
+        }
     }
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 90b08ef..c238e86 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1680,6 +1680,7 @@ struct libxl__domain_create_state {
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
+    libxl__bootloader_state bl;
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZZ-00005L-Pp; Wed, 25 Apr 2012 15:56:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uc-CG
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.143.99:56824] by server-3.bemta-4.messagelabs.com id
	EC/72-05853-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7410 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007ag-Nw; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QO-M5;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:29 +0100
Message-ID: <1335369353-13012-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/25] libxl: handle POLLERR, POLLHUP,
	POLLNVAL properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pass POLLERR and POLLHUP to fd callbacks, as is necessary.
Crash on POLLNVAL since that means our fds are messed up.

Document the behaviour (including the fact that poll sometimes sets
POLLHUP or POLLERR even if only POLLIN was requested.

Fix the one current fd callback to do something with POLLERR|POLLHUP.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 638b9ab..5e1a207 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -335,6 +335,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev,
 {
     EGC_GC;
 
+    if (revents & (POLLERR|POLLHUP))
+        LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0);
+
     for (;;) {
         char **event = xs_check_watch(CTX->xsh);
         if (!event) {
@@ -739,7 +742,9 @@ static int afterpoll_check_fd(libxl__poller *poller,
         /* again, stale slot entry */
         return 0;
 
-    int revents = fds[slot].revents & events;
+    assert(!(fds[slot].revents & POLLNVAL));
+
+    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
 
     return revents;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 34ea15c..4e8ea9a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -127,6 +127,11 @@ _hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
+  /* Note that revents may contain POLLERR or POLLHUP regardless of
+   * events; otherwise revents contains only bits in events.  Contrary
+   * to the documentation for poll(2), POLLERR and POLLHUP can occur
+   * even if only POLLIN was set in events.  (POLLNVAL is a fatal
+   * error and will cause libxl event machinery to fail an assertion.) */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zd-000098-QH; Wed, 25 Apr 2012 15:56:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008UT-Hs
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:48951] by server-2.bemta-4.messagelabs.com id
	EF/B5-17550-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7540 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bN-OD; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RS-Ls;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:44 +0100
Message-ID: <1335369353-13012-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/25] libxl: change some structures to unit
	arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch these variables will turn into actual pointers.

To clarify that patch, prepare the ground by changing these variables
from "struct foo var" to "struct foo var[1]".  This enables accesses
to them and their members to be made as if they were pointers.

No functional change.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |   18 +++++-----
 tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7247b57..92e6951 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -564,7 +564,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state;
+    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
@@ -606,12 +606,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(&state, 0, sizeof(state));
+    memset(state, 0, sizeof(*state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
     }
 
     if (ret) {
@@ -649,7 +649,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
@@ -657,7 +657,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
-                                         &state, &dm_starting);
+                                         state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -686,11 +686,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (need_qemu)
              console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
         }
         break;
     }
@@ -704,7 +704,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index d84dcd6..73db62e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config;
+    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state;
+    libxl__domain_build_state stubdom_state[1];
     uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
@@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
-    libxl_domain_create_info_init(&dm_config.c_info);
-    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+    libxl_domain_create_info_init(&dm_config->c_info);
+    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
-    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
+    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
-    libxl_uuid_generate(&dm_config.c_info.uuid);
+    libxl_uuid_generate(&dm_config->c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info);
-    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
+    libxl_domain_build_info_init(&dm_config->b_info);
+    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
 
-    dm_config.b_info.max_vcpus = 1;
-    dm_config.b_info.max_memkb = 32 * 1024;
-    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+    dm_config->b_info.max_vcpus = 1;
+    dm_config->b_info.max_memkb = 32 * 1024;
+    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl__xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
-    dm_config.b_info.u.pv.ramdisk.path = "";
-    dm_config.b_info.u.pv.features = "";
+    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
+    dm_config->b_info.u.pv.ramdisk.path = "";
+    dm_config->b_info.u.pv.features = "";
 
-    dm_config.b_info.device_model_version =
+    dm_config->b_info.device_model_version =
         guest_config->b_info.device_model_version;
-    dm_config.b_info.device_model =
+    dm_config->b_info.device_model =
         guest_config->b_info.device_model;
-    dm_config.b_info.extra = guest_config->b_info.extra;
-    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
-    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+    dm_config->b_info.extra = guest_config->b_info.extra;
+    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
 
-    dm_config.disks = guest_config->disks;
-    dm_config.num_disks = guest_config->num_disks;
+    dm_config->disks = guest_config->disks;
+    dm_config->num_disks = guest_config->num_disks;
 
-    dm_config.vifs = guest_config->vifs;
-    dm_config.num_vifs = guest_config->num_vifs;
+    dm_config->vifs = guest_config->vifs;
+    dm_config->num_vifs = guest_config->num_vifs;
 
-    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
     if (ret) goto out;
-    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
     if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
-    dm_config.vfbs = &vfb;
-    dm_config.num_vfbs = 1;
-    dm_config.vkbs = &vkb;
-    dm_config.num_vkbs = 1;
+    dm_config->vfbs = &vfb;
+    dm_config->num_vfbs = 1;
+    dm_config->vkbs = &vkb;
+    dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
     dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
 
@@ -788,20 +788,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+    for (i = 0; i < dm_config->num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+    for (i = 0; i < dm_config->num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -845,14 +845,14 @@ retry_transaction:
                 break;
         }
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
-                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
     if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 &dm_config,
-                                 &stubdom_state,
+                                 dm_config,
+                                 stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zb-000070-RS; Wed, 25 Apr 2012 15:56:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008V0-W1
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.139.83:25243] by server-9.bemta-5.messagelabs.com id
	A4/27-09826-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10748 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bM-M4; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RN-Jq;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:43 +0100
Message-ID: <1335369353-13012-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/25] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove this obsolete hook.  Callers inside libxl which create and reap
children should use the mechanisms provided by the event system.

(This has no functional difference since there is no way for
ctx->waitpid_instead ever to become set.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_exec.c     |   12 +++---------
 tools/libxl/libxl_internal.h |    3 ---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..2ee2154 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -19,11 +19,6 @@
 
 #include "libxl_internal.h"
 
-static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
-{
-    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
-}
-
 static void check_open_fds(const char *what)
 {
     const char *env_debug;
@@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
 
     if (!for_spawn) _exit(0); /* just detach then */
 
-    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
+    got = waitpid(child, &status, 0);
     assert(got == child);
 
     rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
@@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
                          (unsigned long)for_spawn->intermediate);
             abort(); /* things are very wrong */
         }
-        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
+        got = waitpid(for_spawn->intermediate, &status, 0);
         assert(got == for_spawn->intermediate);
         if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
             report_spawn_intermediate_status(gc, for_spawn, status);
@@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
 
 int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     pid_t got;
     int status;
 
     if (!for_spawn) return 0;
 
     assert(for_spawn->intermediate);
-    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
+    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
     if (!got) return 0;
 
     assert(got == for_spawn->intermediate);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a5b8681..0109f79 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -335,9 +335,6 @@ struct libxl__ctx {
     int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
     LIBXL_LIST_HEAD(, libxl__ev_child) children;
 
-    /* This is obsolete and must be removed: */
-    int (*waitpid_instead)(pid_t pid, int *status, int flags);
-
     libxl_version_info version_info;
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zc-000088-Vn; Wed, 25 Apr 2012 15:56:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008VA-5p
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [193.109.254.147:19525] by server-9.bemta-14.messagelabs.com id
	F1/C8-05787-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335369362!623424!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5291 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bT-Ql; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rb-Pv;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:46 +0100
Message-ID: <1335369353-13012-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/25] libxl: make libxl_create run bootloader
	via callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change initiate_domain_create to properly use libxl__bootloader_run
rather than improperly calling libxl_run_bootloader with NULL ao_how.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v7:
 * constify convenience aliases.

Changes since v6:
 * Bugfixes from testing.
---
 tools/libxl/libxl_create.c   |   53 +++++++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 0f17202..e35a944 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -571,6 +571,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int rc);
 
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
@@ -591,6 +594,7 @@ static void initiate_domain_create(libxl__egc *egc,
     const int restore_fd = dcs->restore_fd;
     const libxl_console_ready cb = dcs->console_cb;
     void *const priv = dcs->console_cb_priv;
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
 
@@ -620,21 +624,43 @@ static void initiate_domain_create(libxl__egc *egc,
         if (ret) goto error_out;
     }
 
+    dcs->bl.ao = ao;
     libxl_device_disk *bootdisk =
         d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
 
     if (restore_fd < 0 && bootdisk) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
-                                   0 /* fixme-ao */);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to run bootloader: %d", ret);
-            goto error_out;
-        }
+        dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.info = &d_config->b_info,
+        dcs->bl.disk = bootdisk;
+        dcs->bl.domid = dcs->guest_domid;
+            
+        libxl__bootloader_run(egc, &dcs->bl);
+    } else {
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     }
+    return;
 
-    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
-    libxl__domain_build_state *state = &dcs->build_state;
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_bootloader_done(libxl__egc *egc,
+                                      libxl__bootloader_state *bl,
+                                      int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
+    if (ret) goto error_out;
 
     /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm.
      * Fill in any field required by either, including both relevant
@@ -788,12 +814,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
+        ret = libxl__e820_alloc(gc, domid, d_config);
+        if (ret) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
+                      ret, errno);
+            goto error_out;
+        }
     }
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 90b08ef..c238e86 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1680,6 +1680,7 @@ struct libxl__domain_create_state {
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
+    libxl__bootloader_state bl;
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZX-0008VB-La; Wed, 25 Apr 2012 15:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZV-0008T0-8B
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:01 +0000
Received: from [85.158.138.51:31027] by server-4.bemta-3.messagelabs.com id
	BA/B2-15341-09E189F4; Wed, 25 Apr 2012 15:56:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335369359!23761184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8436 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007ao-TX; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QW-Q4;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:31 +0100
Message-ID: <1335369353-13012-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/25] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   62 ++++++++++-
 6 files changed, 515 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9984d46..b6ff270 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index d59f0ee..fb90aed 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 149a4eb..2f559d5 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index dce88ad..35c8bdd 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2d99f29..e665d8d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -197,6 +197,19 @@ _hidden libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc,
                                                       int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -316,10 +329,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -567,6 +584,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon.  The child may not
+ * make any further calls to libxl infrastructure, except for memory
+ * allocation and logging.  If the child needs to use xenstore it
+ * must open its own xs handle and use it directly, rather than via
+ * the libxl event machinery.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -620,6 +667,15 @@ _hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 _hidden void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 _hidden int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZX-0008Uo-7Y; Wed, 25 Apr 2012 15:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZV-0008T7-3q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:01 +0000
Received: from [85.158.138.51:45144] by server-10.bemta-3.messagelabs.com id
	C1/F5-29478-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19052 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bj-4S; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZS-0003S6-3f;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:53 +0100
Message-ID: <1335369353-13012-26-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 25/25] libxl: aborting bootloader invocation
	when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cancel the bootloader (specifically, by sending it a signal) if the
domain is seen to disappear from xenstore.

We use a new utility event source libxl__domaindeathcheck which
provides a convenient wrapper for the xenstore watch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v7:
 * Add a comment explaining why we use a watch on the domain's
   xenstore path rather than @releaseDomain.
 * Fix typo in error message.
---
 tools/libxl/libxl_bootloader.c |   43 ++++++++++++++++++++++++++++--------
 tools/libxl/libxl_event.c      |   47 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   29 +++++++++++++++++++++++-
 3 files changed, 108 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 8436c07..fb1302b 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -31,6 +31,7 @@ static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
 static void bootloader_display_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_domaindeath(libxl__egc*, libxl__domaindeathcheck *dc);
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status);
 
@@ -213,6 +214,7 @@ void libxl__bootloader_init(libxl__bootloader_state *bl)
     bl->ptys[0].master = bl->ptys[0].slave = 0;
     bl->ptys[1].master = bl->ptys[1].slave = 0;
     libxl__ev_child_init(&bl->child);
+    libxl__domaindeathcheck_init(&bl->deathcheck);
     bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
     bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
 }
@@ -230,6 +232,7 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         free(bl->diskpath);
         bl->diskpath = 0;
     }
+    libxl__domaindeathcheck_stop(gc,&bl->deathcheck);
     libxl__datacopier_kill(&bl->keystrokes);
     libxl__datacopier_kill(&bl->display);
     for (i=0; i<2; i++) {
@@ -256,6 +259,23 @@ static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
     bl->callback(egc, bl, rc);
 }
 
+/* might be called at any time, provided it's init'd */
+static void bootloader_abort(libxl__egc *egc,
+                             libxl__bootloader_state *bl, int rc)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
+    }
+    bl->rc = rc;
+}
+
 /*----- main flow of control -----*/
 
 void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
@@ -377,6 +397,12 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    bl->deathcheck.what = "stopping bootloader";
+    bl->deathcheck.domid = bl->domid;
+    bl->deathcheck.callback = bootloader_domaindeath;
+    rc = libxl__domaindeathcheck_start(gc, &bl->deathcheck);
+    if (rc) goto out;
+
     if (bl->console_available)
         bl->console_available(egc, bl);
 
@@ -454,18 +480,9 @@ static void bootloader_copyfail(libxl__egc *egc, const char *which,
        libxl__bootloader_state *bl, int onwrite, int errnoval)
 {
     STATE_AO_GC(bl->ao);
-    int r;
-
     if (!onwrite && !errnoval)
         LOG(ERROR, "unexpected eof copying %s", which);
-    libxl__datacopier_kill(&bl->keystrokes);
-    libxl__datacopier_kill(&bl->display);
-    if (libxl__ev_child_inuse(&bl->child)) {
-        r = kill(bl->child.pid, SIGTERM);
-        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
-                    (unsigned long)bl->child.pid);
-    }
-    bl->rc = ERROR_FAIL;
+    bootloader_abort(egc, bl, ERROR_FAIL);
 }
 static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval)
@@ -480,6 +497,12 @@ static void bootloader_display_copyfail(libxl__egc *egc,
     bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
 }
 
+static void bootloader_domaindeath(libxl__egc *egc, libxl__domaindeathcheck *dc)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, deathcheck);
+    bootloader_abort(egc, bl, ERROR_FAIL);
+}
+
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status)
 {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index f726fc2..b0e05ed 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -585,6 +585,53 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
 }
 
 /*
+ * domain death/destruction
+ */
+
+/*
+ * We use a xenstore watch on the domain's path, rather than using an
+ * @releaseDomain watch and asking the hypervisor.  This is simpler
+ * because turning @releaseDomain into domain-specific information is
+ * complicated.
+ *
+ * It is also sufficient for our callers, which are generally trying
+ * to do cleanup of their own execution state on domain death, for the
+ * following reason: if the domain is destroyed then either (a) the
+ * entries in xenstore have already been deleted, in which case the
+ * test here works or (b) they have not in which case something has
+ * gone very badly wrong and we are going to leak those xenstore
+ * entries, in which case trying to avoid leaking other stuff is
+ * futile.
+ */
+
+static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch);
+    EGC_GC;
+    const char *p = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (p) return;
+
+    if (errno!=ENOENT) {
+        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
+                              " for domain detach check", errno, 0);
+        return;
+    }
+
+    LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)",
+        dc->what, dc->domid, watch_path);
+    dc->callback(egc, dc);
+}
+
+int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                  libxl__domaindeathcheck *dc)
+{
+    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
+    return libxl__ev_xswatch_register(gc, &dc->watch,
+                                      domaindeathcheck_callback, path);
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 64340af..6a48679 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -861,6 +861,33 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
                                     const char *state_path,
                                     int state, int milliseconds);
 
+/*
+ * libxl__ev_domaindeathcheck_register - arranges to call back (once)
+ * if the domain is destroyed.  If the domain dies, we log a message
+ * of the form "<what>: <explanation of the situation, including the domid>".
+ */
+
+typedef struct libxl__domaindeathcheck libxl__domaindeathcheck;
+typedef void libxl___domaindeathcheck_callback(libxl__egc *egc,
+                                         libxl__domaindeathcheck*);
+
+struct libxl__domaindeathcheck {
+    /* must be filled in by caller, and remain valid: */
+    const char *what;
+    uint32_t domid;
+    libxl___domaindeathcheck_callback *callback;
+    /* private */
+    libxl__ev_xswatch watch;
+};
+
+_hidden int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                          libxl__domaindeathcheck *dc);
+
+static inline void libxl__domaindeathcheck_init
+ (libxl__domaindeathcheck *dc) { libxl__ev_xswatch_init(&dc->watch); }
+static inline void libxl__domaindeathcheck_stop(libxl__gc *gc,
+  libxl__domaindeathcheck *dc) { libxl__ev_xswatch_deregister(gc,&dc->watch); }
+
 
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
@@ -1729,6 +1756,7 @@ struct libxl__bootloader_state {
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
     libxl__ev_child child;
+    libxl__domaindeathcheck deathcheck;
     int nargs, argsspace;
     const char **args;
     libxl__datacopier_state keystrokes, display;
@@ -1741,7 +1769,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
-
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zd-000098-QH; Wed, 25 Apr 2012 15:56:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008UT-Hs
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:48951] by server-2.bemta-4.messagelabs.com id
	EF/B5-17550-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7540 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bN-OD; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RS-Ls;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:44 +0100
Message-ID: <1335369353-13012-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/25] libxl: change some structures to unit
	arrays
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch these variables will turn into actual pointers.

To clarify that patch, prepare the ground by changing these variables
from "struct foo var" to "struct foo var[1]".  This enables accesses
to them and their members to be made as if they were pointers.

No functional change.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |   18 +++++-----
 tools/libxl/libxl_dm.c     |   84 ++++++++++++++++++++++----------------------
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7247b57..92e6951 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -564,7 +564,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state;
+    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
@@ -606,12 +606,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(&state, 0, sizeof(state));
+    memset(state, 0, sizeof(*state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
     }
 
     if (ret) {
@@ -649,7 +649,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
@@ -657,7 +657,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_dispose(&vkb);
 
         ret = libxl__create_device_model(gc, domid, d_config,
-                                         &state, &dm_starting);
+                                         state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -686,11 +686,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (need_qemu)
              console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
-        libxl__device_console_add(gc, domid, &console, &state);
+        libxl__device_console_add(gc, domid, &console, state);
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
         }
         break;
     }
@@ -704,7 +704,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index d84dcd6..73db62e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -676,10 +676,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config;
+    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state;
+    libxl__domain_build_state stubdom_state[1];
     uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
@@ -692,58 +692,58 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
-    libxl_domain_create_info_init(&dm_config.c_info);
-    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+    libxl_domain_create_info_init(&dm_config->c_info);
+    dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
-    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
+    dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
-    libxl_uuid_generate(&dm_config.c_info.uuid);
+    libxl_uuid_generate(&dm_config->c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info);
-    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
+    libxl_domain_build_info_init(&dm_config->b_info);
+    libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
 
-    dm_config.b_info.max_vcpus = 1;
-    dm_config.b_info.max_memkb = 32 * 1024;
-    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+    dm_config->b_info.max_vcpus = 1;
+    dm_config->b_info.max_memkb = 32 * 1024;
+    dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+    dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl__xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
-    dm_config.b_info.u.pv.ramdisk.path = "";
-    dm_config.b_info.u.pv.features = "";
+    dm_config->b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
+    dm_config->b_info.u.pv.ramdisk.path = "";
+    dm_config->b_info.u.pv.features = "";
 
-    dm_config.b_info.device_model_version =
+    dm_config->b_info.device_model_version =
         guest_config->b_info.device_model_version;
-    dm_config.b_info.device_model =
+    dm_config->b_info.device_model =
         guest_config->b_info.device_model;
-    dm_config.b_info.extra = guest_config->b_info.extra;
-    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
-    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+    dm_config->b_info.extra = guest_config->b_info.extra;
+    dm_config->b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config->b_info.extra_hvm = guest_config->b_info.extra_hvm;
 
-    dm_config.disks = guest_config->disks;
-    dm_config.num_disks = guest_config->num_disks;
+    dm_config->disks = guest_config->disks;
+    dm_config->num_disks = guest_config->num_disks;
 
-    dm_config.vifs = guest_config->vifs;
-    dm_config.num_vifs = guest_config->num_vifs;
+    dm_config->vifs = guest_config->vifs;
+    dm_config->num_vifs = guest_config->num_vifs;
 
-    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info);
     if (ret) goto out;
-    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info);
     if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
-    dm_config.vfbs = &vfb;
-    dm_config.num_vfbs = 1;
-    dm_config.vkbs = &vkb;
-    dm_config.num_vkbs = 1;
+    dm_config->vfbs = &vfb;
+    dm_config->num_vfbs = 1;
+    dm_config->vkbs = &vkb;
+    dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
     dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
 
@@ -788,20 +788,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
+    for (i = 0; i < dm_config->num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
+    for (i = 0; i < dm_config->num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -845,14 +845,14 @@ retry_transaction:
                 break;
         }
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
-                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
     if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 &dm_config,
-                                 &stubdom_state,
+                                 dm_config,
+                                 stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zb-000070-RS; Wed, 25 Apr 2012 15:56:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008V0-W1
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.139.83:25243] by server-9.bemta-5.messagelabs.com id
	A4/27-09826-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10748 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bM-M4; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RN-Jq;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:43 +0100
Message-ID: <1335369353-13012-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/25] libxl: remove ctx->waitpid_instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove this obsolete hook.  Callers inside libxl which create and reap
children should use the mechanisms provided by the event system.

(This has no functional difference since there is no way for
ctx->waitpid_instead ever to become set.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_exec.c     |   12 +++---------
 tools/libxl/libxl_internal.h |    3 ---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b10e79f..2ee2154 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -19,11 +19,6 @@
 
 #include "libxl_internal.h"
 
-static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
-{
-    return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options);
-}
-
 static void check_open_fds(const char *what)
 {
     const char *env_debug;
@@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc,
 
     if (!for_spawn) _exit(0); /* just detach then */
 
-    got = call_waitpid(ctx->waitpid_instead, child, &status, 0);
+    got = waitpid(child, &status, 0);
     assert(got == child);
 
     rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
@@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc,
                          (unsigned long)for_spawn->intermediate);
             abort(); /* things are very wrong */
         }
-        got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0);
+        got = waitpid(for_spawn->intermediate, &status, 0);
         assert(got == for_spawn->intermediate);
         if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
             report_spawn_intermediate_status(gc, for_spawn, status);
@@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc,
 
 int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     pid_t got;
     int status;
 
     if (!for_spawn) return 0;
 
     assert(for_spawn->intermediate);
-    got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG);
+    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
     if (!got) return 0;
 
     assert(got == for_spawn->intermediate);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a5b8681..0109f79 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -335,9 +335,6 @@ struct libxl__ctx {
     int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
     LIBXL_LIST_HEAD(, libxl__ev_child) children;
 
-    /* This is obsolete and must be removed: */
-    int (*waitpid_instead)(pid_t pid, int *status, int flags);
-
     libxl_version_info version_info;
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZW-0008UY-SE; Wed, 25 Apr 2012 15:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008TF-Ta
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:01 +0000
Received: from [85.158.138.51:30980] by server-11.bemta-3.messagelabs.com id
	D4/8F-18894-09E189F4; Wed, 25 Apr 2012 15:56:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19071 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137126"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007as-26; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qe-02;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:33 +0100
Message-ID: <1335369353-13012-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/25] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v7:
 * Actually include the call to AX_CHECK_PTYFUNCS in this patch,
   not the previous one, and regenerate configure accordingly.

Changes since v6:
 * Put failure macro call in correct place so it might actually happen.
 * Try both with -lutil and without.
 * Patch now contains update for config.h.in.
---
 config/Tools.mk.in             |    2 +
 tools/config.h.in              |    3 ++
 tools/configure                |   61 ++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac             |    2 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++
 tools/m4/ptyfuncs.m4           |   28 ++++++++++++++++++
 7 files changed, 101 insertions(+), 1 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index ee6cda3..5b80359 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/config.h.in b/tools/config.h.in
index 17c8913..bc1ed10 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -42,6 +42,9 @@
 /* Define curses header to use */
 #undef INCLUDE_CURSES_H
 
+/* libutil header file name */
+#undef INCLUDE_LIBUTIL_H
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
diff --git a/tools/configure b/tools/configure
index d8918fe..be7feb6 100755
--- a/tools/configure
+++ b/tools/configure
@@ -598,6 +598,7 @@ ac_includes_default="\
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -2308,6 +2309,8 @@ fi
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -6443,6 +6446,64 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "Unable to find library for openpty and login_tty
+See \`config.log' for more details" "$LINENO" 5 ; }
+            fi
+
+    saved_LIBS="$LIBS"
+
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+                break
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+        done
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index deb848d..4e9cb03 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -32,6 +32,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -132,6 +133,7 @@ AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
+AX_CHECK_PTYFUNCS
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5469454..1261d43 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..7581704
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,28 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                AC_MSG_FAILURE([Unable to find library for openpty and login_tty])
+            fi
+            AX_SAVEVAR_SAVE(LIBS)
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+],[
+                break
+            ],[])
+            AX_SAVEVAR_RESTORE(LIBS)
+        done
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZU-0008TG-II; Wed, 25 Apr 2012 15:56:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZT-0008Sy-CK
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:55:59 +0000
Received: from [85.158.138.51:45018] by server-12.bemta-3.messagelabs.com id
	8D/17-29760-E8E189F4; Wed, 25 Apr 2012 15:55:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18944 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007aw-5m; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qs-3e;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:36 +0100
Message-ID: <1335369353-13012-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/25] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7ab2f72..f4a2718 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -573,9 +573,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zc-00007P-77; Wed, 25 Apr 2012 15:56:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008Uw-0Y
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.139.83:25248] by server-3.bemta-5.messagelabs.com id
	D4/7F-25237-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10702 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137134"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b9-Dd; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003R9-BP;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:40 +0100
Message-ID: <1335369353-13012-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/25] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 19b4615..f0d94c6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZX-0008Uo-7Y; Wed, 25 Apr 2012 15:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZV-0008T7-3q
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:01 +0000
Received: from [85.158.138.51:45144] by server-10.bemta-3.messagelabs.com id
	C1/F5-29478-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19052 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bj-4S; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZS-0003S6-3f;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:53 +0100
Message-ID: <1335369353-13012-26-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 25/25] libxl: aborting bootloader invocation
	when domain dioes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cancel the bootloader (specifically, by sending it a signal) if the
domain is seen to disappear from xenstore.

We use a new utility event source libxl__domaindeathcheck which
provides a convenient wrapper for the xenstore watch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v7:
 * Add a comment explaining why we use a watch on the domain's
   xenstore path rather than @releaseDomain.
 * Fix typo in error message.
---
 tools/libxl/libxl_bootloader.c |   43 ++++++++++++++++++++++++++++--------
 tools/libxl/libxl_event.c      |   47 ++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |   29 +++++++++++++++++++++++-
 3 files changed, 108 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 8436c07..fb1302b 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -31,6 +31,7 @@ static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
 static void bootloader_display_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_domaindeath(libxl__egc*, libxl__domaindeathcheck *dc);
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status);
 
@@ -213,6 +214,7 @@ void libxl__bootloader_init(libxl__bootloader_state *bl)
     bl->ptys[0].master = bl->ptys[0].slave = 0;
     bl->ptys[1].master = bl->ptys[1].slave = 0;
     libxl__ev_child_init(&bl->child);
+    libxl__domaindeathcheck_init(&bl->deathcheck);
     bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
     bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
 }
@@ -230,6 +232,7 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         free(bl->diskpath);
         bl->diskpath = 0;
     }
+    libxl__domaindeathcheck_stop(gc,&bl->deathcheck);
     libxl__datacopier_kill(&bl->keystrokes);
     libxl__datacopier_kill(&bl->display);
     for (i=0; i<2; i++) {
@@ -256,6 +259,23 @@ static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
     bl->callback(egc, bl, rc);
 }
 
+/* might be called at any time, provided it's init'd */
+static void bootloader_abort(libxl__egc *egc,
+                             libxl__bootloader_state *bl, int rc)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
+    }
+    bl->rc = rc;
+}
+
 /*----- main flow of control -----*/
 
 void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
@@ -377,6 +397,12 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    bl->deathcheck.what = "stopping bootloader";
+    bl->deathcheck.domid = bl->domid;
+    bl->deathcheck.callback = bootloader_domaindeath;
+    rc = libxl__domaindeathcheck_start(gc, &bl->deathcheck);
+    if (rc) goto out;
+
     if (bl->console_available)
         bl->console_available(egc, bl);
 
@@ -454,18 +480,9 @@ static void bootloader_copyfail(libxl__egc *egc, const char *which,
        libxl__bootloader_state *bl, int onwrite, int errnoval)
 {
     STATE_AO_GC(bl->ao);
-    int r;
-
     if (!onwrite && !errnoval)
         LOG(ERROR, "unexpected eof copying %s", which);
-    libxl__datacopier_kill(&bl->keystrokes);
-    libxl__datacopier_kill(&bl->display);
-    if (libxl__ev_child_inuse(&bl->child)) {
-        r = kill(bl->child.pid, SIGTERM);
-        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
-                    (unsigned long)bl->child.pid);
-    }
-    bl->rc = ERROR_FAIL;
+    bootloader_abort(egc, bl, ERROR_FAIL);
 }
 static void bootloader_keystrokes_copyfail(libxl__egc *egc,
        libxl__datacopier_state *dc, int onwrite, int errnoval)
@@ -480,6 +497,12 @@ static void bootloader_display_copyfail(libxl__egc *egc,
     bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
 }
 
+static void bootloader_domaindeath(libxl__egc *egc, libxl__domaindeathcheck *dc)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, deathcheck);
+    bootloader_abort(egc, bl, ERROR_FAIL);
+}
+
 static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
                                 pid_t pid, int status)
 {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index f726fc2..b0e05ed 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -585,6 +585,53 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
 }
 
 /*
+ * domain death/destruction
+ */
+
+/*
+ * We use a xenstore watch on the domain's path, rather than using an
+ * @releaseDomain watch and asking the hypervisor.  This is simpler
+ * because turning @releaseDomain into domain-specific information is
+ * complicated.
+ *
+ * It is also sufficient for our callers, which are generally trying
+ * to do cleanup of their own execution state on domain death, for the
+ * following reason: if the domain is destroyed then either (a) the
+ * entries in xenstore have already been deleted, in which case the
+ * test here works or (b) they have not in which case something has
+ * gone very badly wrong and we are going to leak those xenstore
+ * entries, in which case trying to avoid leaking other stuff is
+ * futile.
+ */
+
+static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch);
+    EGC_GC;
+    const char *p = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (p) return;
+
+    if (errno!=ENOENT) {
+        LIBXL__EVENT_DISASTER(egc,"failed to read xenstore"
+                              " for domain detach check", errno, 0);
+        return;
+    }
+
+    LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)",
+        dc->what, dc->domid, watch_path);
+    dc->callback(egc, dc);
+}
+
+int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                  libxl__domaindeathcheck *dc)
+{
+    const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid);
+    return libxl__ev_xswatch_register(gc, &dc->watch,
+                                      domaindeathcheck_callback, path);
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 64340af..6a48679 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -861,6 +861,33 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
                                     const char *state_path,
                                     int state, int milliseconds);
 
+/*
+ * libxl__ev_domaindeathcheck_register - arranges to call back (once)
+ * if the domain is destroyed.  If the domain dies, we log a message
+ * of the form "<what>: <explanation of the situation, including the domid>".
+ */
+
+typedef struct libxl__domaindeathcheck libxl__domaindeathcheck;
+typedef void libxl___domaindeathcheck_callback(libxl__egc *egc,
+                                         libxl__domaindeathcheck*);
+
+struct libxl__domaindeathcheck {
+    /* must be filled in by caller, and remain valid: */
+    const char *what;
+    uint32_t domid;
+    libxl___domaindeathcheck_callback *callback;
+    /* private */
+    libxl__ev_xswatch watch;
+};
+
+_hidden int libxl__domaindeathcheck_start(libxl__gc *gc,
+                                          libxl__domaindeathcheck *dc);
+
+static inline void libxl__domaindeathcheck_init
+ (libxl__domaindeathcheck *dc) { libxl__ev_xswatch_init(&dc->watch); }
+static inline void libxl__domaindeathcheck_stop(libxl__gc *gc,
+  libxl__domaindeathcheck *dc) { libxl__ev_xswatch_deregister(gc,&dc->watch); }
+
 
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
@@ -1729,6 +1756,7 @@ struct libxl__bootloader_state {
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
     libxl__ev_child child;
+    libxl__domaindeathcheck deathcheck;
     int nargs, argsspace;
     const char **args;
     libxl__datacopier_state keystrokes, display;
@@ -1741,7 +1769,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
-
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zb-00006N-2z; Wed, 25 Apr 2012 15:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uc-SE
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:56907] by server-3.bemta-4.messagelabs.com id
	01/82-05853-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7522 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b1-95; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qx-5c;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:37 +0100
Message-ID: <1335369353-13012-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/25] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v7:
 * assert that the ao is non-null on _init.
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 231 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1261d43..5d9227e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -64,7 +64,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..4c60ad9
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    assert(dc->ao);
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        datacopier_callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc->ao);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f506f56..0c1c8f9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -835,6 +835,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1468,6 +1469,45 @@ _hidden const char *libxl__xen_script_dir_path(void);
 _hidden const char *libxl__lock_dir_path(void);
 _hidden const char *libxl__run_dir_path(void);
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errnoval is valid
+ * onwrite==0 means failure happened when reading
+ *     errnoval==0 means we got eof and all data was written
+ *     errnoval!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZW-0008UY-SE; Wed, 25 Apr 2012 15:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008TF-Ta
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:01 +0000
Received: from [85.158.138.51:30980] by server-11.bemta-3.messagelabs.com id
	D4/8F-18894-09E189F4; Wed, 25 Apr 2012 15:56:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19071 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137126"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007as-26; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qe-02;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:33 +0100
Message-ID: <1335369353-13012-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/25] autoconf: New test for openpty et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We may need to #include <libutil.h>, and/or link with -lutil, to use
openpty, login_tty, and the like.  Provide INCLUDE_LIBUTIL_H
(preprocessor constant, not always defined) and PTYFUNCS_LIBS
(makefile variable).

We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather
than UTIL_LIBS, and #include <libutil.h> where appropriate.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v7:
 * Actually include the call to AX_CHECK_PTYFUNCS in this patch,
   not the previous one, and regenerate configure accordingly.

Changes since v6:
 * Put failure macro call in correct place so it might actually happen.
 * Try both with -lutil and without.
 * Patch now contains update for config.h.in.
---
 config/Tools.mk.in             |    2 +
 tools/config.h.in              |    3 ++
 tools/configure                |   61 ++++++++++++++++++++++++++++++++++++++++
 tools/configure.ac             |    2 +
 tools/libxl/Makefile           |    2 +-
 tools/libxl/libxl_bootloader.c |    4 ++
 tools/m4/ptyfuncs.m4           |   28 ++++++++++++++++++
 7 files changed, 101 insertions(+), 1 deletions(-)
 create mode 100644 tools/m4/ptyfuncs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index ee6cda3..5b80359 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -30,6 +30,8 @@ PTHREAD_CFLAGS      := @PTHREAD_CFLAGS@
 PTHREAD_LDFLAGS     := @PTHREAD_LDFLAGS@
 PTHREAD_LIBS        := @PTHREAD_LIBS@
 
+PTYFUNCS_LIBS       := @PTYFUNCS_LIBS@
+
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/config.h.in b/tools/config.h.in
index 17c8913..bc1ed10 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -42,6 +42,9 @@
 /* Define curses header to use */
 #undef INCLUDE_CURSES_H
 
+/* libutil header file name */
+#undef INCLUDE_LIBUTIL_H
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
diff --git a/tools/configure b/tools/configure
index d8918fe..be7feb6 100755
--- a/tools/configure
+++ b/tools/configure
@@ -598,6 +598,7 @@ ac_includes_default="\
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
 libiconv
+PTYFUNCS_LIBS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -2308,6 +2309,8 @@ fi
 
 
 
+
+
 # Enable/disable options
 
 # Check whether --enable-githttp was given.
@@ -6443,6 +6446,64 @@ $as_echo "$ax_cv_pthread_flags" >&6; }
 
 
 
+
+    ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default"
+if test "x$ac_cv_header_libutil_h" = x""yes; then :
+
+
+$as_echo "#define INCLUDE_LIBUTIL_H <libutil.h>" >>confdefs.h
+
+
+fi
+
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5
+$as_echo_n "checking for openpty et al... " >&6; }
+if test "${ax_cv_ptyfuncs_libs+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "Unable to find library for openpty and login_tty
+See \`config.log' for more details" "$LINENO" 5 ; }
+            fi
+
+    saved_LIBS="$LIBS"
+
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+
+                break
+
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+    LIBS="$saved_LIBS"
+
+        done
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5
+$as_echo "$ax_cv_ptyfuncs_libs" >&6; }
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index deb848d..4e9cb03 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -32,6 +32,7 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
+m4_include([m4/ptyfuncs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -132,6 +133,7 @@ AC_SUBST(libext2fs)
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
+AX_CHECK_PTYFUNCS
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5469454..1261d43 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 2774062..b50944a 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -16,6 +16,10 @@
 
 #include <termios.h>
 
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4
new file mode 100644
index 0000000..7581704
--- /dev/null
+++ b/tools/m4/ptyfuncs.m4
@@ -0,0 +1,28 @@
+AC_DEFUN([AX_CHECK_PTYFUNCS], [
+    AC_CHECK_HEADER([libutil.h],[
+      AC_DEFINE([INCLUDE_LIBUTIL_H],[<libutil.h>],[libutil header file name])
+    ])
+    AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [
+        for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do
+            if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then
+                AC_MSG_FAILURE([Unable to find library for openpty and login_tty])
+            fi
+            AX_SAVEVAR_SAVE(LIBS)
+            LIBS="$LIBS $ax_cv_ptyfuncs_libs"
+            AC_LINK_IFELSE([
+#ifdef INCLUDE_LIBUTIL_H
+#include INCLUDE_LIBUTIL_H
+#endif
+int main(void) {
+  openpty(0,0,0,0,0);
+  login_tty(0);
+}
+],[
+                break
+            ],[])
+            AX_SAVEVAR_RESTORE(LIBS)
+        done
+    ])
+    PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs"
+    AC_SUBST(PTYFUNCS_LIBS)
+])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZV-0008Tj-Cw; Wed, 25 Apr 2012 15:56:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008T0-0J
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:00 +0000
Received: from [85.158.138.51:30862] by server-4.bemta-3.messagelabs.com id
	1E/A2-15341-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18984 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bg-3H; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZS-0003Ry-1R;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:51 +0100
Message-ID: <1335369353-13012-24-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/25] libxl: clarify definition of "slow"
	operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the comment in libxl_internal.h to be clearer about which
application-facing libxl operations need to take an ao_how.

Reported-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++------
 1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 55d07c4..459c27b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1430,17 +1430,34 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 /*
  * Machinery for asynchronous operations ("ao")
  *
- * All "slow" functions (includes anything that might block on a
- * guest or an external script) need to use the asynchronous
- * operation ("ao") machinery.  The function should take a parameter
- * const libxl_asyncop_how *ao_how and must start with a call to
- * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * inside libxl, because they can cause reentrancy callbacks.
+ * All "slow" functions (see below for the exact definition) need to
+ * use the asynchronous operation ("ao") machinery.  The function
+ * should take a parameter const libxl_asyncop_how *ao_how and must
+ * start with a call to AO_INITIATOR_ENTRY.  These functions MAY NOT
+ * be called from inside libxl, because they can cause reentrancy
+ * callbacks.
  *
  * For the same reason functions taking an ao_how may make themselves
  * an egc with EGC_INIT (and they will generally want to, to be able
  * to immediately complete an ao during its setup).
  *
+ *
+ * "Slow" functions includes any that might block on a guest or an
+ * external script.  More broadly, it includes any operations which
+ * are sufficiently slow that an application might reasonably want to
+ * initiate them, and then carry on doing something else, while the
+ * operation completes.  That is, a "fast" function must be fast
+ * enough that we do not mind blocking all other management operations
+ * on the same host while it completes.
+ *
+ * There are certain primitive functions which make a libxl operation
+ * necessarily "slow" for API reasons.  These are:
+ *  - awaiting xenstore watches (although read-modify-write xenstore
+ *    transactions are OK for fast functions)
+ *  - spawning subprocesses
+ *  - anything with a timeout
+ *
+ *
  * Lifecycle of an ao:
  *
  * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZZ-000050-Br; Wed, 25 Apr 2012 15:56:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008UM-7d
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.139.83:25138] by server-12.bemta-5.messagelabs.com id
	E8/5B-05587-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10625 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007af-MP; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QM-La;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:28 +0100
Message-ID: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v8 00/25] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This incorporates changes from review.

These have already been acked, apart from 04/25, and could go into the
tree very soon:

  01/25 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
  02/25 libxl: support multiple libxl__ev_fds for the same fd
  03/25 libxl: event API: new facilities for waiting for subprocesses
! 04/25 autoconf: trim the configure script; use autoheader
  05/25 autoconf: New test for openpty et al.
  06/25 libxl: provide libxl__remove_file et al.
  07/25 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
  08/25 libxl: Clean up setdefault in do_domain_create
  09/25 libxl: provide libxl__datacopier_*
  10/25 libxl: provide libxl__openpty_*
  11/25 libxl: ao: Convert libxl_run_bootloader
  12/25 libxl: make libxl_create_logfile const-correct
  13/25 libxl: log bootloader output
  14/25 libxl: Allow AO_GC and EGC_GC even if not used
  15/25 libxl: remove ctx->waitpid_instead

These are the remaining meat; all except 19/25 have been posted before
and some have been acked:
  
  16/25 libxl: change some structures to unit arrays
  17/25 libxl: ao: convert libxl__spawn_*
  18/25 libxl: make libxl_create run bootloader via callback
* 19/25 libxl: Fix an ao completion bug; document locking policy
  20/25 libxl: provide progress reporting for long-running operations
  21/25 libxl: remove malloc failure handling from NEW_EVENT
  22/25 libxl: convert console callback to libxl_asyncprogress_how
  23/25 libxl: clarify definition of "slow" operation
  24/25 libxl: child processes cleanups
  25/25 libxl: aborting bootloader invocation when domain dioes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZW-0008UA-6s; Wed, 25 Apr 2012 15:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008T0-Hn
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:00 +0000
Received: from [85.158.138.51:30889] by server-4.bemta-3.messagelabs.com id
	71/B2-15341-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18999 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bf-1g; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Ru-W8;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:50 +0100
Message-ID: <1335369353-13012-23-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/25] libxl: convert console callback to
	libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the old console callback.  (Its reentrancy properties were
troublesome: in principle, the event loop might be reentered during
the callback, and the libxl__domain_create_state swept out from under
the feet of the domain creation.)

As a side effect of the new code arrangements, the console callback
for non-bootloader-using PV guests now occurs near the end of domain
creation, in the same place as for HVM guests, rather than near the
start.

The new arrangements should in principle mean that by the time the
console is described as ready by the callback, the xenstore key is
indeed ready.  So in the future the timeout might be removed from
the console client.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h            |   17 ++++++-----
 tools/libxl/libxl_bootloader.c |    3 ++
 tools/libxl/libxl_create.c     |   59 +++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h   |    6 +++-
 tools/libxl/libxl_types.idl    |    2 +
 tools/libxl/xl_cmdimpl.c       |   25 ++++++++++-------
 6 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7bd6231..0ff4a83 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
-typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
-   * properties need to be documented but they may turn out to be too
-   * awkward */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            const libxl_asyncop_how *ao_how);
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how);
+                                const libxl_asyncop_how *ao_how,
+                                const libxl_asyncprogress_how *aop_console_how);
+  /* A progress report will be made via ao_console_how, of type
+   * domain_create_console_available, when the domain's primary
+   * console is available and can be connected to.
+   */
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 1534bae..8436c07 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -377,6 +377,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    if (bl->console_available)
+        bl->console_available(egc, bl);
+
     int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
     int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e35a944..928a48c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -571,10 +571,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl);
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -592,8 +597,6 @@ static void initiate_domain_create(libxl__egc *egc,
     /* convenience aliases */
     libxl_domain_config *const d_config = dcs->guest_config;
     const int restore_fd = dcs->restore_fd;
-    const libxl_console_ready cb = dcs->console_cb;
-    void *const priv = dcs->console_cb_priv;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
@@ -611,11 +614,6 @@ static void initiate_domain_create(libxl__egc *egc,
     dcs->guest_domid = domid;
     dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */
 
-    if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
-
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
@@ -630,6 +628,7 @@ static void initiate_domain_create(libxl__egc *egc,
 
     if (restore_fd < 0 && bootdisk) {
         dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.console_available = domcreate_bootloader_console_available;
         dcs->bl.info = &d_config->b_info,
         dcs->bl.disk = bootdisk;
         dcs->bl.domid = dcs->guest_domid;
@@ -645,6 +644,21 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    domcreate_console_available(egc, dcs);
+}
+
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs) {
+    libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
+                              NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
+                                        dcs->guest_domid));
+}
+
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int ret)
@@ -783,8 +797,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *const d_config = dcs->guest_config;
-    const libxl_console_ready cb = dcs->console_cb;
-    void *const priv = dcs->console_cb_priv;
 
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -822,12 +834,7 @@ static void domcreate_devmodel_started(libxl__egc *egc,
             goto error_out;
         }
     }
-    if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
-                (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-                 d_config->b_info.u.pv.bootloader ))) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
+    domcreate_console_available(egc, dcs);
 
     domcreate_complete(egc, dcs, 0);
     return;
@@ -867,8 +874,9 @@ static void domain_create_cb(libxl__egc *egc,
                              int rc, uint32_t domid);
 
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            int restore_fd, const libxl_asyncop_how *ao_how)
+                            uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
     AO_CREATE(ctx, 0, ao_how);
     libxl__app_domain_create_state *cdcs;
@@ -877,9 +885,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
     cdcs->dcs.restore_fd = restore_fd;
-    cdcs->dcs.console_cb = cb;
-    cdcs->dcs.console_cb_priv = priv;
     cdcs->dcs.callback = domain_create_cb;
+    libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
     cdcs->domid_out = domid;
 
     initiate_domain_create(egc, &cdcs->dcs);
@@ -901,19 +908,21 @@ static void domain_create_cb(libxl__egc *egc,
 }
     
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
                             uint32_t *domid,
-                            const libxl_asyncop_how *ao_how)
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
+    return do_domain_create(ctx, d_config, domid, -1,
+                            ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how)
+                                const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
+    return do_domain_create(ctx, d_config, domid, restore_fd,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4adbb5f..55d07c4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1690,11 +1690,14 @@ int libxl__openptys(libxl__openpty_state *op,
 typedef struct libxl__bootloader_state libxl__bootloader_state;
 typedef void libxl__run_bootloader_callback(libxl__egc*,
                                 libxl__bootloader_state*, int rc);
+typedef void libxl__bootloader_console_callback(libxl__egc*,
+                                libxl__bootloader_state*);
 
 struct libxl__bootloader_state {
     /* caller must fill these in, and they must all remain valid */
     libxl__ao *ao;
     libxl__run_bootloader_callback *callback;
+    libxl__bootloader_console_callback *console_available;
     libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
     libxl_device_disk *disk;
     uint32_t domid;
@@ -1730,9 +1733,8 @@ struct libxl__domain_create_state {
     libxl__ao *ao;
     libxl_domain_config *guest_config;
     int restore_fd;
-    libxl_console_ready console_cb;
-    void *console_cb_priv;
     libxl__domain_create_cb *callback;
+    libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 68599cb..551e367 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -459,6 +459,7 @@ libxl_event_type = Enumeration("event_type", [
     (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
+    (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -484,4 +485,5 @@ libxl_event = Struct("event",[
            ("operation_complete", Struct(None, [
                                         ("rc", integer),
                                  ])),
+           ("domain_create_console_available", Struct(None, [])),
            ]))])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 399359e..2e89671 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1457,16 +1457,18 @@ static int freemem(libxl_domain_build_info *b_info)
     return ERROR_NOMEM;
 }
 
-static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
+static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv)
 {
     pid_t *pid = priv;
 
+    libxl_event_free(ctx, ev);
+
     *pid = fork();
     if (*pid < 0) {
         perror("unable to fork xenconsole");
-        return ERROR_FAIL;
+        return;
     } else if (*pid > 0)
-        return 0;
+        return;
 
     postfork();
 
@@ -1533,7 +1535,7 @@ static int create_domain(struct domain_create *dom_info)
     int config_len = 0;
     int restore_fd = -1;
     int status = 0;
-    libxl_console_ready cb;
+    const libxl_asyncprogress_how *autoconnect_console_how;
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
@@ -1687,24 +1689,27 @@ start:
         goto error_out;
     }
 
+    libxl_asyncprogress_how autoconnect_console_how_buf;
     if ( dom_info->console_autoconnect ) {
-        cb = autoconnect_console;
+        autoconnect_console_how_buf.callback = autoconnect_console;
+        autoconnect_console_how_buf.for_callback = &child_console_pid;
+        autoconnect_console_how = &autoconnect_console_how_buf;
     }else{
-        cb = NULL;
+        autoconnect_console_how = 0;
     }
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                          cb, &child_console_pid,
-                                          &domid, restore_fd, 0);
+                                          &domid, restore_fd,
+                                          0, autoconnect_console_how);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
          */
         restore_file = NULL;
     }else{
-        ret = libxl_domain_create_new(ctx, &d_config,
-                                      cb, &child_console_pid, &domid, 0);
+        ret = libxl_domain_create_new(ctx, &d_config, &domid,
+                                      0, autoconnect_console_how);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZU-0008TG-II; Wed, 25 Apr 2012 15:56:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZT-0008Sy-CK
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:55:59 +0000
Received: from [85.158.138.51:45018] by server-12.bemta-3.messagelabs.com id
	8D/17-29760-E8E189F4; Wed, 25 Apr 2012 15:55:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18944 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007aw-5m; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qs-3e;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:36 +0100
Message-ID: <1335369353-13012-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/25] libxl: Clean up setdefault in
	do_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

do_domain_create called libxl__domain_create_info_setdefault twice.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7ab2f72..f4a2718 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -573,9 +573,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
-    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
-    if (ret) goto error_out;
-
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zb-00006f-FG; Wed, 25 Apr 2012 15:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uv-Rv
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:48894] by server-1.bemta-4.messagelabs.com id
	0C/A3-20925-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7466 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b5-9c; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003R1-8B;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:38 +0100
Message-ID: <1335369353-13012-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/25] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 4c60ad9..734a5dc 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op->ao);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op->ao);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0c1c8f9..2aa32cc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1508,6 +1508,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zb-00006N-2z; Wed, 25 Apr 2012 15:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uc-SE
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:56907] by server-3.bemta-4.messagelabs.com id
	01/82-05853-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7522 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b1-95; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qx-5c;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:37 +0100
Message-ID: <1335369353-13012-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/25] libxl: provide libxl__datacopier_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to shovel data between fds.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v7:
 * assert that the ao is non-null on _init.
---
 tools/libxl/Makefile         |    3 +-
 tools/libxl/libxl_aoutils.c  |  189 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   40 +++++++++
 3 files changed, 231 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_aoutils.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1261d43..5d9227e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -64,7 +64,8 @@ LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
-			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
+			libxl_internal.o libxl_utils.o libxl_uuid.o \
+			libxl_json.o libxl_aoutils.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
new file mode 100644
index 0000000..4c60ad9
--- /dev/null
+++ b/tools/libxl/libxl_aoutils.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2010      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*----- data copier -----*/
+
+void libxl__datacopier_init(libxl__datacopier_state *dc)
+{
+    assert(dc->ao);
+    libxl__ev_fd_init(&dc->toread);
+    libxl__ev_fd_init(&dc->towrite);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+void libxl__datacopier_kill(libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    libxl__datacopier_buf *buf, *tbuf;
+
+    libxl__ev_fd_deregister(gc, &dc->toread);
+    libxl__ev_fd_deregister(gc, &dc->towrite);
+    LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf)
+        free(buf);
+    LIBXL_TAILQ_INIT(&dc->bufs);
+}
+
+static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc,
+                                int onwrite, int errnoval)
+{
+    libxl__datacopier_kill(dc);
+    dc->callback(egc, dc, onwrite, errnoval);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents);
+
+static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
+{
+    STATE_AO_GC(dc->ao);
+    int rc;
+    
+    if (dc->used) {
+        if (!libxl__ev_fd_isregistered(&dc->towrite)) {
+            rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                                       dc->writefd, POLLOUT);
+            if (rc) {
+                LOG(ERROR, "unable to establish write event on %s"
+                    " during copy of %s", dc->writewhat, dc->copywhat);
+                datacopier_callback(egc, dc, -1, 0);
+                return;
+            }
+        }
+    } else if (!libxl__ev_fd_isregistered(&dc->toread)) {
+        /* we have had eof */
+        datacopier_callback(egc, dc, 0, 0);
+        return;
+    } else {
+        /* nothing buffered, but still reading */
+        libxl__ev_fd_deregister(gc, &dc->towrite);
+    }
+}
+
+static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)"
+            " on %s during copy of %s", revents, dc->readwhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLIN);
+    for (;;) {
+        while (dc->used >= dc->maxsz) {
+            libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs);
+            dc->used -= rm->used;
+            assert(dc->used >= 0);
+            LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry);
+            free(rm);
+        }
+
+        libxl__datacopier_buf *buf =
+            LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs);
+        if (!buf || buf->used >= sizeof(buf->buf)) {
+            buf = malloc(sizeof(*buf));
+            if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
+            buf->used = 0;
+            LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+        }
+        int r = read(ev->fd,
+                     buf->buf + buf->used,
+                     sizeof(buf->buf) - buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error reading %s during copy of %s",
+                 dc->readwhat, dc->copywhat);
+            datacopier_callback(egc, dc, 0, errno);
+            return;
+        }
+        if (r == 0) {
+            libxl__ev_fd_deregister(gc, &dc->toread);
+            break;
+        }
+        buf->used += r;
+        dc->used += r;
+        assert(buf->used <= sizeof(buf->buf));
+    }
+    datacopier_check_state(egc, dc);
+}
+
+static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev,
+                                int fd, short events, short revents) {
+    libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite);
+    STATE_AO_GC(dc->ao);
+
+    if (revents & ~POLLOUT) {
+        LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)"
+            " on %s during copy of %s", revents, dc->writewhat, dc->copywhat);
+        datacopier_callback(egc, dc, -1, 0);
+        return;
+    }
+    assert(revents & POLLOUT);
+    for (;;) {
+        libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs);
+        if (!buf)
+            break;
+        if (!buf->used) {
+            LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry);
+            free(buf);
+            continue;
+        }
+        int r = write(ev->fd, buf->buf, buf->used);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) break;
+            LOGE(ERROR, "error writing to %s during copy of %s",
+                 dc->writewhat, dc->copywhat);
+            datacopier_callback(egc, dc, 1, errno);
+            return;
+        }
+        assert(r > 0);
+        assert(r <= buf->used);
+        buf->used -= r;
+        dc->used -= r;
+        assert(dc->used >= 0);
+        memmove(buf->buf, buf->buf+r, buf->used);
+    }
+    datacopier_check_state(egc, dc);
+}
+
+int libxl__datacopier_start(libxl__datacopier_state *dc)
+{
+    int rc;
+    STATE_AO_GC(dc->ao);
+
+    libxl__datacopier_init(dc);
+
+    rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable,
+                               dc->readfd, POLLIN);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable,
+                               dc->writefd, POLLOUT);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__datacopier_kill(dc);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f506f56..0c1c8f9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -835,6 +835,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
@@ -1468,6 +1469,45 @@ _hidden const char *libxl__xen_script_dir_path(void);
 _hidden const char *libxl__lock_dir_path(void);
 _hidden const char *libxl__run_dir_path(void);
 
+/*----- datacopier: copies data from one fd to another -----*/
+
+typedef struct libxl__datacopier_state libxl__datacopier_state;
+typedef struct libxl__datacopier_buf libxl__datacopier_buf;
+
+/* onwrite==1 means failure happened when writing, logged, errnoval is valid
+ * onwrite==0 means failure happened when reading
+ *     errnoval==0 means we got eof and all data was written
+ *     errnoval!=0 means we had a read error, logged
+ * onwrite==-1 means some other internal failure, errnoval not valid, logged
+ * in all cases copier is killed before calling this callback */
+typedef void libxl__datacopier_callback(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
+struct libxl__datacopier_buf {
+    /* private to datacopier */
+    LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry;
+    int used;
+    char buf[1000];
+};
+
+struct libxl__datacopier_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    int readfd, writefd;
+    ssize_t maxsz;
+    const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    libxl__datacopier_callback *callback;
+    /* remaining fields are private to datacopier */
+    libxl__ev_fd toread, towrite;
+    ssize_t used;
+    LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs;
+};
+
+_hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
+_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
+_hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZZ-000050-Br; Wed, 25 Apr 2012 15:56:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008UM-7d
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.139.83:25138] by server-12.bemta-5.messagelabs.com id
	E8/5B-05587-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10625 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007af-MP; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QM-La;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:28 +0100
Message-ID: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v8 00/25] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This incorporates changes from review.

These have already been acked, apart from 04/25, and could go into the
tree very soon:

  01/25 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
  02/25 libxl: support multiple libxl__ev_fds for the same fd
  03/25 libxl: event API: new facilities for waiting for subprocesses
! 04/25 autoconf: trim the configure script; use autoheader
  05/25 autoconf: New test for openpty et al.
  06/25 libxl: provide libxl__remove_file et al.
  07/25 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
  08/25 libxl: Clean up setdefault in do_domain_create
  09/25 libxl: provide libxl__datacopier_*
  10/25 libxl: provide libxl__openpty_*
  11/25 libxl: ao: Convert libxl_run_bootloader
  12/25 libxl: make libxl_create_logfile const-correct
  13/25 libxl: log bootloader output
  14/25 libxl: Allow AO_GC and EGC_GC even if not used
  15/25 libxl: remove ctx->waitpid_instead

These are the remaining meat; all except 19/25 have been posted before
and some have been acked:
  
  16/25 libxl: change some structures to unit arrays
  17/25 libxl: ao: convert libxl__spawn_*
  18/25 libxl: make libxl_create run bootloader via callback
* 19/25 libxl: Fix an ao completion bug; document locking policy
  20/25 libxl: provide progress reporting for long-running operations
  21/25 libxl: remove malloc failure handling from NEW_EVENT
  22/25 libxl: convert console callback to libxl_asyncprogress_how
  23/25 libxl: clarify definition of "slow" operation
  24/25 libxl: child processes cleanups
  25/25 libxl: aborting bootloader invocation when domain dioes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZW-0008UA-6s; Wed, 25 Apr 2012 15:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008T0-Hn
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:00 +0000
Received: from [85.158.138.51:30889] by server-4.bemta-3.messagelabs.com id
	71/B2-15341-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18999 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bf-1g; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Ru-W8;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:50 +0100
Message-ID: <1335369353-13012-23-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/25] libxl: convert console callback to
	libxl_asyncprogress_how
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the old console callback.  (Its reentrancy properties were
troublesome: in principle, the event loop might be reentered during
the callback, and the libxl__domain_create_state swept out from under
the feet of the domain creation.)

As a side effect of the new code arrangements, the console callback
for non-bootloader-using PV guests now occurs near the end of domain
creation, in the same place as for HVM guests, rather than near the
start.

The new arrangements should in principle mean that by the time the
console is described as ready by the callback, the xenstore key is
indeed ready.  So in the future the timeout might be removed from
the console client.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h            |   17 ++++++-----
 tools/libxl/libxl_bootloader.c |    3 ++
 tools/libxl/libxl_create.c     |   59 +++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h   |    6 +++-
 tools/libxl/libxl_types.idl    |    2 +
 tools/libxl/xl_cmdimpl.c       |   25 ++++++++++-------
 6 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7bd6231..0ff4a83 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
-typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
-   * properties need to be documented but they may turn out to be too
-   * awkward */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            const libxl_asyncop_how *ao_how);
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how);
+                                const libxl_asyncop_how *ao_how,
+                                const libxl_asyncprogress_how *aop_console_how);
+  /* A progress report will be made via ao_console_how, of type
+   * domain_create_console_available, when the domain's primary
+   * console is available and can be connected to.
+   */
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 1534bae..8436c07 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -377,6 +377,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
         goto out;
     }
 
+    if (bl->console_available)
+        bl->console_available(egc, bl);
+
     int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
     int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e35a944..928a48c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -571,10 +571,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 static void domcreate_devmodel_started(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc);
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl);
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -592,8 +597,6 @@ static void initiate_domain_create(libxl__egc *egc,
     /* convenience aliases */
     libxl_domain_config *const d_config = dcs->guest_config;
     const int restore_fd = dcs->restore_fd;
-    const libxl_console_ready cb = dcs->console_cb;
-    void *const priv = dcs->console_cb_priv;
     memset(&dcs->build_state, 0, sizeof(dcs->build_state));
 
     domid = 0;
@@ -611,11 +614,6 @@ static void initiate_domain_create(libxl__egc *egc,
     dcs->guest_domid = domid;
     dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */
 
-    if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
-
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
@@ -630,6 +628,7 @@ static void initiate_domain_create(libxl__egc *egc,
 
     if (restore_fd < 0 && bootdisk) {
         dcs->bl.callback = domcreate_bootloader_done;
+        dcs->bl.console_available = domcreate_bootloader_console_available;
         dcs->bl.info = &d_config->b_info,
         dcs->bl.disk = bootdisk;
         dcs->bl.domid = dcs->guest_domid;
@@ -645,6 +644,21 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_bootloader_console_available(libxl__egc *egc,
+                                                   libxl__bootloader_state *bl)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
+    STATE_AO_GC(bl->ao);
+    domcreate_console_available(egc, dcs);
+}
+
+static void domcreate_console_available(libxl__egc *egc,
+                                        libxl__domain_create_state *dcs) {
+    libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
+                              NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
+                                        dcs->guest_domid));
+}
+
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int ret)
@@ -783,8 +797,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 
     /* convenience aliases */
     libxl_domain_config *const d_config = dcs->guest_config;
-    const libxl_console_ready cb = dcs->console_cb;
-    void *const priv = dcs->console_cb_priv;
 
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -822,12 +834,7 @@ static void domcreate_devmodel_started(libxl__egc *egc,
             goto error_out;
         }
     }
-    if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
-                (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-                 d_config->b_info.u.pv.bootloader ))) {
-        ret = (*cb)(ctx, domid, priv);
-        if (ret) goto error_out;
-    }
+    domcreate_console_available(egc, dcs);
 
     domcreate_complete(egc, dcs, 0);
     return;
@@ -867,8 +874,9 @@ static void domain_create_cb(libxl__egc *egc,
                              int rc, uint32_t domid);
 
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid,
-                            int restore_fd, const libxl_asyncop_how *ao_how)
+                            uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
     AO_CREATE(ctx, 0, ao_how);
     libxl__app_domain_create_state *cdcs;
@@ -877,9 +885,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     cdcs->dcs.ao = ao;
     cdcs->dcs.guest_config = d_config;
     cdcs->dcs.restore_fd = restore_fd;
-    cdcs->dcs.console_cb = cb;
-    cdcs->dcs.console_cb_priv = priv;
     cdcs->dcs.callback = domain_create_cb;
+    libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
     cdcs->domid_out = domid;
 
     initiate_domain_create(egc, &cdcs->dcs);
@@ -901,19 +908,21 @@ static void domain_create_cb(libxl__egc *egc,
 }
     
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
                             uint32_t *domid,
-                            const libxl_asyncop_how *ao_how)
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
+    return do_domain_create(ctx, d_config, domid, -1,
+                            ao_how, aop_console_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv,
                                 uint32_t *domid, int restore_fd,
-                                const libxl_asyncop_how *ao_how)
+                                const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
+    return do_domain_create(ctx, d_config, domid, restore_fd,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4adbb5f..55d07c4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1690,11 +1690,14 @@ int libxl__openptys(libxl__openpty_state *op,
 typedef struct libxl__bootloader_state libxl__bootloader_state;
 typedef void libxl__run_bootloader_callback(libxl__egc*,
                                 libxl__bootloader_state*, int rc);
+typedef void libxl__bootloader_console_callback(libxl__egc*,
+                                libxl__bootloader_state*);
 
 struct libxl__bootloader_state {
     /* caller must fill these in, and they must all remain valid */
     libxl__ao *ao;
     libxl__run_bootloader_callback *callback;
+    libxl__bootloader_console_callback *console_available;
     libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
     libxl_device_disk *disk;
     uint32_t domid;
@@ -1730,9 +1733,8 @@ struct libxl__domain_create_state {
     libxl__ao *ao;
     libxl_domain_config *guest_config;
     int restore_fd;
-    libxl_console_ready console_cb;
-    void *console_cb_priv;
     libxl__domain_create_cb *callback;
+    libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
     int guest_domid;
     libxl__domain_build_state build_state;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 68599cb..551e367 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -459,6 +459,7 @@ libxl_event_type = Enumeration("event_type", [
     (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
+    (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -484,4 +485,5 @@ libxl_event = Struct("event",[
            ("operation_complete", Struct(None, [
                                         ("rc", integer),
                                  ])),
+           ("domain_create_console_available", Struct(None, [])),
            ]))])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 399359e..2e89671 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1457,16 +1457,18 @@ static int freemem(libxl_domain_build_info *b_info)
     return ERROR_NOMEM;
 }
 
-static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
+static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv)
 {
     pid_t *pid = priv;
 
+    libxl_event_free(ctx, ev);
+
     *pid = fork();
     if (*pid < 0) {
         perror("unable to fork xenconsole");
-        return ERROR_FAIL;
+        return;
     } else if (*pid > 0)
-        return 0;
+        return;
 
     postfork();
 
@@ -1533,7 +1535,7 @@ static int create_domain(struct domain_create *dom_info)
     int config_len = 0;
     int restore_fd = -1;
     int status = 0;
-    libxl_console_ready cb;
+    const libxl_asyncprogress_how *autoconnect_console_how;
     pid_t child_console_pid = -1;
     struct save_file_header hdr;
 
@@ -1687,24 +1689,27 @@ start:
         goto error_out;
     }
 
+    libxl_asyncprogress_how autoconnect_console_how_buf;
     if ( dom_info->console_autoconnect ) {
-        cb = autoconnect_console;
+        autoconnect_console_how_buf.callback = autoconnect_console;
+        autoconnect_console_how_buf.for_callback = &child_console_pid;
+        autoconnect_console_how = &autoconnect_console_how_buf;
     }else{
-        cb = NULL;
+        autoconnect_console_how = 0;
     }
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                          cb, &child_console_pid,
-                                          &domid, restore_fd, 0);
+                                          &domid, restore_fd,
+                                          0, autoconnect_console_how);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
          */
         restore_file = NULL;
     }else{
-        ret = libxl_domain_create_new(ctx, &d_config,
-                                      cb, &child_console_pid, &domid, 0);
+        ret = libxl_domain_create_new(ctx, &d_config, &domid,
+                                      0, autoconnect_console_how);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZV-0008Tj-Cw; Wed, 25 Apr 2012 15:56:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZU-0008T0-0J
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:00 +0000
Received: from [85.158.138.51:30862] by server-4.bemta-3.messagelabs.com id
	1E/A2-15341-F8E189F4; Wed, 25 Apr 2012 15:55:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18984 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bg-3H; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZS-0003Ry-1R;
	Wed, 25 Apr 2012 16:55:58 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:51 +0100
Message-ID: <1335369353-13012-24-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/25] libxl: clarify definition of "slow"
	operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the comment in libxl_internal.h to be clearer about which
application-facing libxl operations need to take an ao_how.

Reported-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++------
 1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 55d07c4..459c27b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1430,17 +1430,34 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 /*
  * Machinery for asynchronous operations ("ao")
  *
- * All "slow" functions (includes anything that might block on a
- * guest or an external script) need to use the asynchronous
- * operation ("ao") machinery.  The function should take a parameter
- * const libxl_asyncop_how *ao_how and must start with a call to
- * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * inside libxl, because they can cause reentrancy callbacks.
+ * All "slow" functions (see below for the exact definition) need to
+ * use the asynchronous operation ("ao") machinery.  The function
+ * should take a parameter const libxl_asyncop_how *ao_how and must
+ * start with a call to AO_INITIATOR_ENTRY.  These functions MAY NOT
+ * be called from inside libxl, because they can cause reentrancy
+ * callbacks.
  *
  * For the same reason functions taking an ao_how may make themselves
  * an egc with EGC_INIT (and they will generally want to, to be able
  * to immediately complete an ao during its setup).
  *
+ *
+ * "Slow" functions includes any that might block on a guest or an
+ * external script.  More broadly, it includes any operations which
+ * are sufficiently slow that an application might reasonably want to
+ * initiate them, and then carry on doing something else, while the
+ * operation completes.  That is, a "fast" function must be fast
+ * enough that we do not mind blocking all other management operations
+ * on the same host while it completes.
+ *
+ * There are certain primitive functions which make a libxl operation
+ * necessarily "slow" for API reasons.  These are:
+ *  - awaiting xenstore watches (although read-modify-write xenstore
+ *    transactions are OK for fast functions)
+ *  - spawning subprocesses
+ *  - anything with a timeout
+ *
+ *
  * Lifecycle of an ao:
  *
  * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zc-00007i-J3; Wed, 25 Apr 2012 15:56:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008UT-4W
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:48873] by server-2.bemta-4.messagelabs.com id
	4D/B5-17550-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7445 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007aj-QI; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QS-Nk;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:30 +0100
Message-ID: <1335369353-13012-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/25] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Fix typo
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..149a4eb 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each element in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e8ea9a..2d99f29 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -258,8 +262,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Za-00005e-5t; Wed, 25 Apr 2012 15:56:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008UT-82
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.143.99:48846] by server-2.bemta-4.messagelabs.com id
	1C/B5-17550-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7368 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bS-QA; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RX-O1;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:45 +0100
Message-ID: <1335369353-13012-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/25] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn becomes a callback-style asynchronous function.
The implementation is now in terms of libxl__ev_* including
libxl_ev_child.

All the callers need to be updated.  This includes the device model
spawning functions libxl__create_device_model and
libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
abolished; instead the dm spawner calls back.

(The choice of which kind of device model to create is lifted out of
what used to be libxl__create_device_model, because that function was
indirectly recursive.  Recursive callback-style operations are clumsy
because they require a pointer indirection for the nested states.)

Waiting for proper device model startup it is no longer notionally
optional.  Previously the code appeared to tolerate this by passing
NULL for various libxl__spawner_starting* parameters to device model
spawners.  However, this was not used anywhere.

Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
no longer supported.  It remains as an unused formal parameter to
avoid updating, in this patch, all the call sites which pass NULL.
libxl__wait_for_offspring is in any case itself an obsolete function,
so this wrinkle will go away when its callers are updated to use the
event system.  Consequently libxl__spawn_check is also abolished.

The "console ready" callback also remains unchanged in this patch.
The API for this needs to be reviewed in the context of the event
series and its reentrancy restrictions documented.

Thus their callers need to be updated.  These are the domain creation
functions libxl_domain_create_new and _restore.  These functions now
take ao_hows, and have a private state structure.

However domain creation remains not completely converted to the event
mechanism; in particular it runs the outward-facing function
libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
happens in the current code this is not a bug because none of the rest
of the functionality surrounding the bootloader call will mind if the
event loop is reentered in the middle of its execution.

The file-scope function libxl__set_fd_flag which was used by the
previous spawn arrangements becomes unused and is removed; other
places in libxl can use libxl_fd_set_nonblock and
libxl_fd_set_cloexec, which of course remain.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v7:
 * Rename libxl__spawn_stubdom to libxl__spawn_stub_dm (and ..._state);
   rename the state's stubdom_* members to dm_*.
 * Eliminate the union between the two dm creation states in
   libxl__domain_create_state.  Instead, the domain creation code
   simply uses libxl__stub_dm_spawn_state.dm directly, if we're
   taking the local dm path.
 * Remove a spurious "break".
 * In domain creation, move the PV non-qemu case into the switch.
 * Code style fixes.
 * Constify some convenience aliases.
 * Improve comments (including typo fixes).
---
 tools/libxl/libxl.h          |   14 ++-
 tools/libxl/libxl_create.c   |  206 +++++++++++++++++++-----
 tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
 tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
 tools/libxl/xl_cmdimpl.c     |    6 +-
 6 files changed, 683 insertions(+), 402 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 3087146..b497430 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
+   * properties need to be documented but they may turn out to be too
+   * awkward */
+
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            const libxl_asyncop_how *ao_how);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how);
+
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 92e6951..0f17202 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -558,16 +558,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
-static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+/*----- main domain creation -----*/
+
+/* We have a linear control flow; only one event callback is
+ * outstanding at any time.  Each initiation and callback function
+ * arranges for the next to be called, as the very last thing it
+ * does.  (If that particular sub-operation is not needed, a
+ * function will call the next event callback directly.)
+ */
+
+/* Event callbacks, in this order: */
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+/* Our own function to clean up and call the user's callback.
+ * The final call in the sequence. */
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc);
+
+static void initiate_domain_create(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs)
 {
+    STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
+    /* convenience aliases */
+    libxl_domain_config *const d_config = dcs->guest_config;
+    const int restore_fd = dcs->restore_fd;
+    const libxl_console_ready cb = dcs->console_cb;
+    void *const priv = dcs->console_cb_priv;
+
     domid = 0;
 
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
@@ -580,9 +604,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
+    dcs->guest_domid = domid;
+    dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */
+
     if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
@@ -606,7 +633,17 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(state, 0, sizeof(*state));
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+    libxl__domain_build_state *state = &dcs->build_state;
+
+    /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm.
+     * Fill in any field required by either, including both relevant
+     * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */
+    dcs->dmss.dm.spawn.ao = ao;
+    dcs->dmss.dm.guest_config = dcs->guest_config;
+    dcs->dmss.dm.build_state = &dcs->build_state;
+    dcs->dmss.dm.callback = domcreate_devmodel_started;
+    dcs->dmss.callback = domcreate_devmodel_started;
 
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
@@ -656,14 +693,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        ret = libxl__create_device_model(gc, domid, d_config,
-                                         state, &dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to create device model: %d", ret);
-            goto error_out;
-        }
-        break;
+        dcs->dmss.dm.guest_domid = domid;
+        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
+            libxl__spawn_stub_dm(egc, &dcs->dmss);
+        else
+            libxl__spawn_local_dm(egc, &dcs->dmss.dm);
+        return;
     }
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -690,26 +725,52 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
+            dcs->dmss.dm.guest_domid = domid;
+            libxl__spawn_local_dm(egc, &dcs->dmss.dm);
+            return;
+        } else {
+            assert(!dcs->dmss.dm.guest_domid);
+            domcreate_devmodel_started(egc, &dcs->dmss.dm, 0);
+            return;
         }
-        break;
     }
     default:
         ret = ERROR_INVAL;
         goto error_out;
     }
+    abort(); /* not reached */
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss.dm);
+    STATE_AO_GC(dmss->spawn.ao);
+    int i;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *const d_config = dcs->guest_config;
+    const libxl_console_ready cb = dcs->console_cb;
+    void *const priv = dcs->console_cb_priv;
+
+    if (ret) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "device model did not start: %d", ret);
+        goto error_out;
+    }
 
-    if (dm_starting) {
+    if (dcs->dmss.dm.guest_domid) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "device model did not start: %d", ret);
-            goto error_out;
-        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
@@ -737,38 +798,95 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
-    *domid_out = domid;
-    return 0;
+    domcreate_complete(egc, dcs, 0);
+    return;
 
 error_out:
-    if (domid)
-        libxl_domain_destroy(ctx, domid);
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
 
-    return ret;
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc)
+{
+    STATE_AO_GC(dcs->ao);
+
+    if (rc) {
+        if (dcs->guest_domid) {
+            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
+            if (rc2)
+                LOG(ERROR, "unable to destroy domain %d following"
+                    " failed creation", dcs->guest_domid);
+        }
+        dcs->guest_domid = -1;
+    }
+    dcs->callback(egc, dcs, rc, dcs->guest_domid);
 }
 
+/*----- application-facing domain creation interface -----*/
+
+typedef struct {
+    libxl__domain_create_state dcs;
+    uint32_t *domid_out;
+} libxl__app_domain_create_state;
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid);
+
+static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, 0, ao_how);
+    libxl__app_domain_create_state *cdcs;
+
+    GCNEW(cdcs);
+    cdcs->dcs.ao = ao;
+    cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.console_cb = cb;
+    cdcs->dcs.console_cb_priv = priv;
+    cdcs->dcs.callback = domain_create_cb;
+    cdcs->domid_out = domid;
+
+    initiate_domain_create(egc, &cdcs->dcs);
+
+    return AO_INPROGRESS;
+}
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid)
+{
+    libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs);
+    STATE_AO_GC(cdcs->dcs.ao);
+
+    if (!rc)
+        *cdcs->domid_out = domid;
+
+    libxl__ao_complete(egc, ao, rc);
+}
+    
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv,
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 73db62e..7035f1b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -667,24 +667,28 @@ retry_transaction:
     return 0;
 }
 
-static int libxl__create_stubdom(libxl__gc *gc,
-                                 int guest_domid,
-                                 libxl_domain_config *guest_config,
-                                 libxl__domain_build_state *d_state,
-                                 libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc);
+
+void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 {
+    STATE_AO_GC(sdss->dm.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state[1];
-    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
-    libxl__spawner_starting *dm_starting = 0;
+
+    /* convenience aliases */
+    libxl_domain_config *const dm_config = &sdss->dm_config;
+    libxl_domain_config *const guest_config = sdss->dm.guest_config;
+    const int guest_domid = sdss->dm.guest_domid;
+    libxl__domain_build_state *const d_state = sdss->dm.build_state;
+    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -692,6 +696,8 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
+    sdss->pvqemu.guest_domid = 0;
+
     libxl_domain_create_info_init(&dm_config->c_info);
     dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
@@ -739,10 +745,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
     if (ret)
         goto out;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
     ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
@@ -850,42 +856,67 @@ retry_transaction:
             goto out_free;
     }
 
-    if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 dm_config,
-                                 stubdom_state,
-                                 &dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-
-    libxl_domain_unpause(ctx, dm_domid);
+    sdss->pvqemu.guest_domid = dm_domid;
+    sdss->pvqemu.guest_config = &sdss->dm_config;
+    sdss->pvqemu.build_state = &sdss->dm_state;
+    sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
-    if (starting_r) {
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = guest_domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
-        (*starting_r)->for_spawn = NULL;
-    }
+    libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    ret = 0;
+    free(args);
+    return;
 
 out_free:
     free(args);
 out:
-    return ret;
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
 }
 
-int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__stub_dm_spawn_state *sdss =
+        CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
+    STATE_AO_GC(sdss->dm.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) goto out;
+
+    rc = libxl_domain_unpause(CTX, dm_domid);
+    if (rc) goto out;
+
+ out:
+    if (rc) {
+        if (dm_domid)
+            libxl_domain_destroy(CTX, dm_domid);
+    }
+    sdss->callback(egc, &sdss->dm, rc);
+}
+
+/* callbacks passed to libxl__spawn_spawn */
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata);
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn);
+
+/* our "next step" function, called from those callbacks and elsewhere */
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
+{
+    /* convenience aliases */
+    const int domid = dmss->guest_domid;
+    libxl__domain_build_state *const state = dmss->build_state;
+    libxl__spawn_state *const spawn = &dmss->spawn;
+
+    STATE_AO_GC(dmss->spawn.ao);
+
+    libxl_ctx *ctx = CTX;
+    libxl_domain_config *guest_config = dmss->guest_config;
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
@@ -893,15 +924,13 @@ int libxl__create_device_model(libxl__gc *gc,
     int logfile_w, null;
     int rc;
     char **args, **arg;
-    libxl__spawner_starting buf_starting, *p;
     xs_transaction_t t;
     char *vm_path;
     char **pass_stuff;
     const char *dm;
 
     if (libxl_defbool_val(b_info->device_model_stubdomain)) {
-        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
-        goto out;
+        abort();
     }
 
     dm = libxl__domain_device_model(gc, b_info);
@@ -945,25 +974,8 @@ int libxl__create_device_model(libxl__gc *gc,
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
-    if (starting_r) {
-        rc = ERROR_NOMEM;
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        if (!*starting_r)
-            goto out_close;
-        p = *starting_r;
-        p->for_spawn = calloc(1, sizeof(libxl__spawn_starting));
-    } else {
-        p = &buf_starting;
-        p->for_spawn = NULL;
-    }
-
-    p->domid = domid;
-    p->dom_path = libxl__xs_get_dompath(gc, domid);
-    p->pid_path = "image/device-model-pid";
-    if (!p->dom_path) {
-        rc = ERROR_FAIL;
-        goto out_close;
-    }
+    const char *dom_path = libxl__xs_get_dompath(gc, domid);
+    spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid");
 
     if (vnc && vnc->passwd) {
         /* This xenstore key will only be used by qemu-xen-traditionnal.
@@ -971,7 +983,7 @@ int libxl__create_device_model(libxl__gc *gc,
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
-        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path));
+        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path));
         if (vm_path) {
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
@@ -988,8 +1000,15 @@ retry_transaction:
     for (arg = args; *arg; arg++)
         LIBXL__LOG(CTX, XTL_DEBUG, "  %s", *arg);
 
-    rc = libxl__spawn_spawn(gc, p->for_spawn, "device model",
-                            libxl_spawner_record_pid, p);
+    spawn->what = GCSPRINTF("domain %d device model", domid);
+    spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid);
+    spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+    spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
+    spawn->midproc_cb = libxl__spawn_record_pid;
+    spawn->confirm_cb = device_model_confirm;
+    spawn->failure_cb = device_model_startup_failed;
+
+    rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
     if (!rc) { /* inner child */
@@ -1004,30 +1023,61 @@ out_close:
     close(logfile_w);
     free(args);
 out:
-    return rc;
+    if (rc)
+        device_model_spawn_outcome(egc, dmss, rc);
+}
+
+
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    STATE_AO_GC(spawn->ao);
+
+    if (!xsdata)
+        return;
+
+    if (strcmp(xsdata, "running"))
+        return;
+
+    libxl__spawn_detach(gc, spawn);
+
+    device_model_spawn_outcome(egc, dmss, 0);
 }
 
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
+}
 
-int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl__domain_build_state *state,
-                                libxl__spawner_starting *starting)
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc)
 {
-    char *path;
-    int domid = starting->domid;
-    int ret, ret2;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    ret = libxl__spawn_confirm_offspring_startup(gc,
-                                     LIBXL_DEVICE_MODEL_START_TIMEOUT,
-                                     "Device Model", path, "running", starting);
+    STATE_AO_GC(dmss->spawn.ao);
+    int ret2;
+
+    if (rc)
+        LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc);
+
+    libxl__domain_build_state *state = dmss->build_state;
+
     if (state->saved_state) {
         ret2 = unlink(state->saved_state);
-        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
-                                   "failed to remove device-model state %s\n",
-                                   state->saved_state);
-        /* Do not clobber spawn_confirm error code with unlink error code. */
-        if (!ret) ret = ret2;
+        if (ret2) {
+            LOGE(ERROR, "%s: failed to remove device-model state %s",
+                 dmss->spawn.what, state->saved_state);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
-    return ret;
+
+    rc = 0;
+
+ out:
+    dmss->callback(egc, dmss, rc);
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
@@ -1123,15 +1173,6 @@ out:
     return ret;
 }
 
-int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                             libxl_domain_config *guest_config,
-                             libxl__domain_build_state *state,
-                             libxl__spawner_starting **starting_r)
-{
-    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 2ee2154..d44b702 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
+                            pid_t innerchild)
 {
-    libxl__spawner_starting *starting = for_spawn;
-    struct xs_handle *xsh;
-    char *path = NULL, *pid = NULL;
-    int len;
-
-    if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0)
-        goto out;
+    struct xs_handle *xsh = NULL;
+    const char *pid = NULL;
+    int rc, xsok;
 
-    len = asprintf(&pid, "%d", innerchild);
-    if (len < 0)
-        goto out;
+    pid = GCSPRINTF("%d", innerchild);
 
     /* we mustn't use the parent's handle in the child */
     xsh = xs_daemon_open();
+    if (!xsh) {
+        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
+             spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
 
-    xs_write(xsh, XBT_NULL, path, pid, len);
+    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
+    if (!xsok) {
+        LOGE(ERROR,
+             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    rc = 0;
 
-    xs_daemon_close(xsh);
 out:
-    free(path);
-    free(pid);
+    if (xsh) xs_daemon_close(xsh);
+    return rc ? SIGTERM : 0;
 }
 
 int libxl__wait_for_offspring(libxl__gc *gc,
@@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc,
     tv.tv_sec = timeout;
     tv.tv_usec = 0;
     nfds = xs_fileno(xsh) + 1;
-    if (spawning && spawning->fd > xs_fileno(xsh))
-        nfds = spawning->fd + 1;
+    assert(!spawning);
 
     while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        if ( spawning ) {
-            rc = libxl__spawn_check(gc, spawning);
-            if ( rc ) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "%s died during startup", what);
-                rc = -1;
-                goto err_died;
-            }
-        }
         p = xs_read(xsh, XBT_NULL, path, &len);
         if ( NULL == p )
             goto again;
@@ -218,8 +214,6 @@ again:
         free(p);
         FD_ZERO(&rfds);
         FD_SET(xs_fileno(xsh), &rfds);
-        if (spawning)
-            FD_SET(spawning->fd, &rfds);
         rc = select(nfds, &rfds, NULL, NULL, &tv);
         if (rc > 0) {
             if (FD_ISSET(xs_fileno(xsh), &rfds)) {
@@ -229,207 +223,215 @@ again:
                 else
                     goto again;
             }
-            if (spawning && FD_ISSET(spawning->fd, &rfds)) {
-                unsigned char dummy;
-                if (read(spawning->fd, &dummy, sizeof(dummy)) != 1)
-                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG,
-                                     "failed to read spawn status pipe");
-            }
         }
     }
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what);
-err_died:
+
     xs_unwatch(xsh, path, path);
     xs_daemon_close(xsh);
 err:
     return -1;
 }
 
-static int detach_offspring(libxl__gc *gc,
-                               libxl__spawner_starting *starting)
-{
-    int rc;
-    rc = libxl__spawn_detach(gc, starting->for_spawn);
-    if (starting->for_spawn)
-        free(starting->for_spawn);
-    free(starting);
-    return rc;
-}
 
-int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting)
-{
-    int detach;
-    int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what,
-                                               path, state,
-                                               starting->for_spawn, NULL, NULL);
-    detach = detach_offspring(gc, starting);
-    return problem ? problem : detach;
-}
+/*----- spawn implementation -----*/
 
-static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag)
-{
-    int flags;
+/*
+ * Full set of possible states of a libxl__spawn_state and its _detachable:
+ *
+ *               ss->        ss->        ss->    | ssd->       ssd->
+ *               timeout     xswatch     ssd     |  mid         ss
+ *  - Undefined   undef       undef       no     |  -           -
+ *  - Idle        Idle        Idle        no     |  -           -
+ *  - Active      Active      Active      yes    |  Active      yes
+ *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
+ *  - Detached    -           -           -      |  Active      no
+ *
+ * When in state Detached, the middle process has been sent a SIGKILL.
+ */
 
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1)
-        return ERROR_FAIL;
+/* Event callbacks. */
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path);
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs);
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status);
 
-    flags |= flag;
+/* Precondition: Partial.  Results: Detached. */
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-    if (fcntl(fd, F_SETFL, flags) == -1)
-        return ERROR_FAIL;
+/* Precondition: Partial; caller has logged failure reason.
+ * Results: Caller notified of failure;
+ *  after return, ss may be completely invalid as caller may reuse it */
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
 
-    return 0;
+void libxl__spawn_init(libxl__spawn_state *ss)
+{
+    libxl__ev_time_init(&ss->timeout);
+    libxl__ev_xswatch_init(&ss->xswatch);
+    ss->ssd = 0;
 }
 
-int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn,
-                                                pid_t innerchild),
-                      void *hook_data)
+int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    pid_t child, got;
+    STATE_AO_GC(ss->ao);
+    int r;
+    pid_t child;
     int status, rc;
-    pid_t intermediate;
-    int pipes[2];
-    unsigned char dummy = 0;
-
-    if (for_spawn) {
-        for_spawn->what = strdup(what);
-        if (!for_spawn->what) return ERROR_NOMEM;
-
-        if (libxl_pipe(ctx, pipes) < 0)
-            goto err_parent;
-        if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 ||
-            libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0)
-            goto err_parent_pipes;
-    }
 
-    intermediate = libxl_fork(ctx);
-    if (intermediate ==-1)
-        goto err_parent_pipes;
+    libxl__spawn_init(ss);
+    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    libxl__ev_child_init(&ss->ssd->mid);
+
+    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
+                                     spawn_timeout, ss->timeout_ms);
+    if (rc) goto out_err;
 
-    if (intermediate) {
+    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
+                                    spawn_watch_event, ss->xspath);
+    if (rc) goto out_err;
+
+    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
+
+    if (middle) {
         /* parent */
-        if (for_spawn) {
-            for_spawn->intermediate = intermediate;
-            for_spawn->fd = pipes[0];
-            close(pipes[1]);
-        }
         return 1;
     }
 
-    /* we are now the intermediate process */
-    if (for_spawn) close(pipes[0]);
+    /* we are now the middle process */
 
     child = fork();
     if (child == -1)
         exit(255);
     if (!child) {
-        if (for_spawn) close(pipes[1]);
         return 0; /* caller runs child code */
     }
 
-    intermediate_hook(hook_data, child);
-
-    if (!for_spawn) _exit(0); /* just detach then */
-
-    got = waitpid(child, &status, 0);
-    assert(got == child);
-
-    rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
-          WIFSIGNALED(status) && WTERMSIG(status) < 127
-          ? WTERMSIG(status)+128 : -1);
-    if (for_spawn) {
-        if (write(pipes[1], &dummy, sizeof(dummy)) != 1)
-            perror("libxl__spawn_spawn: unable to signal child exit to parent");
+    int failsig = ss->midproc_cb(gc, ss, middle);
+    if (failsig) {
+        kill(child, failsig);
+        _exit(127);
     }
-    _exit(rc);
 
- err_parent_pipes:
-    if (for_spawn) {
-        close(pipes[0]);
-        close(pipes[1]);
+    for (;;) {
+        pid_t got = waitpid(child, &status, 0);
+        if (got == -1) {
+            assert(errno == EINTR);
+            continue;
+        }
+        assert(got == child);
+        break;
     }
 
- err_parent:
-    if (for_spawn) free(for_spawn->what);
+    r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) :
+         WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 :
+         -1);
+    _exit(r);
 
-    return ERROR_FAIL;
+ out_err:
+    spawn_cleanup(gc, ss);
+    return rc;
 }
 
-static void report_spawn_intermediate_status(libxl__gc *gc,
-                                             libxl__spawn_starting *for_spawn,
-                                             int status)
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
-    if (!WIFEXITED(status)) {
-        libxl_ctx *ctx = libxl__gc_owner(gc);
-        char *intermediate_what;
-        /* intermediate process did the logging itself if it exited */
-        if ( asprintf(&intermediate_what,
-                 "%s intermediate process (startup monitor)",
-                 for_spawn->what) < 0 )
-            intermediate_what = "intermediate process (startup monitor)";
-        libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what,
-                                      for_spawn->intermediate, status);
+    int r;
+
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+
+    libxl__spawn_state_detachable *ssd = ss->ssd;
+    if (ssd) {
+        if (libxl__ev_child_inuse(&ssd->mid)) {
+            pid_t child = ssd->mid.pid;
+            r = kill(child, SIGKILL);
+            if (r && errno != ESRCH)
+                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+                     ss->what, (unsigned long)child);
+        }
+
+        /* disconnect the ss and ssd from each other */
+        ssd->ss = 0;
+        ss->ssd = 0;
     }
 }
 
-int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn)
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int r, status;
-    pid_t got;
-    int rc = 0;
+    EGC_GC;
+    spawn_cleanup(gc, ss);
+    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+}
 
-    if (!for_spawn) return 0;
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs)
+{
+    /* Before event, was Active; is now Partial. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
+    LOG(ERROR, "%s: startup timed out", ss->what);
+    spawn_failed(egc, ss); /* must be last */
+}
 
-    if (for_spawn->intermediate) {
-        r = kill(for_spawn->intermediate, SIGKILL);
-        if (r) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                         "could not kill %s intermediate process [%ld]",
-                         for_spawn->what,
-                         (unsigned long)for_spawn->intermediate);
-            abort(); /* things are very wrong */
-        }
-        got = waitpid(for_spawn->intermediate, &status, 0);
-        assert(got == for_spawn->intermediate);
-        if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
-            report_spawn_intermediate_status(gc, for_spawn, status);
-            rc = ERROR_FAIL;
-        }
-        for_spawn->intermediate = 0;
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path)
+{
+    /* On entry, is Active. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
+    char *p = libxl__xs_read(gc, 0, ss->xspath);
+    if (!p && errno != ENOENT) {
+        LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
+        spawn_failed(egc, ss); /* must be last */
+        return;
     }
-
-    free(for_spawn->what);
-    for_spawn->what = 0;
-
-    return rc;
+    ss->confirm_cb(egc, ss, p); /* must be last */
 }
 
-int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status)
+    /* Before event, was Active or Detached;
+     * is now Active or Detached except that ssd->mid is Idle */
 {
-    pid_t got;
-    int status;
-
-    if (!for_spawn) return 0;
+    EGC_GC;
+    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
+    libxl__spawn_state *ss = ssd->ss;
 
-    assert(for_spawn->intermediate);
-    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
-    if (!got) return 0;
-
-    assert(got == for_spawn->intermediate);
-    report_spawn_intermediate_status(gc, for_spawn, status);
+    if (!WIFEXITED(status)) {
+        const char *what =
+            GCSPRINTF("%s intermediate process (startup monitor)",
+                      ss ? ss->what : "(detached)");
+        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+        libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
+    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        if (!status)
+            LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
+                " when we were waiting for it to confirm startup",
+                ss->what, (unsigned long)pid);
+        else if (status <= 127)
+            LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d",
+                ss->what, (unsigned long)pid, status);
+        else if (status < 255) {
+            int sig = status - 128;
+            const char *str = strsignal(sig);
+            if (str)
+                LOG(ERROR, "%s [%ld]: died during startup due to fatal"
+                    " signal %s", ss->what, (unsigned long)pid, str);
+            else
+                LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
+                    " signal number %d", ss->what, (unsigned long)pid, sig);
+        }
+        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
+        spawn_failed(egc, ss); /* must be last use of ss */
+    }
+    free(ssd);
+}
 
-    for_spawn->intermediate = 0;
-    return ERROR_FAIL;
+void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    spawn_cleanup(gc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0109f79..90b08ef 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -842,75 +842,198 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                                       libxl_device_pci *pcidev, int num);
 _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
 
-/* xl_exec */
+/*
+ *----- spawn -----
+ *
+ * Higher-level double-fork and separate detach eg as for device models
+ *
+ * Each libxl__spawn_state is in one of the conventional states
+ *    Undefined, Idle, Active
+ */
 
- /* higher-level double-fork and separate detach eg as for device models */
+typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
+/* this type is never defined, so no objects of this type exist
+ * fixme-ao  This should go away completely.  */
 
-typedef struct {
-    /* put this in your own status structure as returned to application */
-    /* all fields are private to libxl_spawn_... */
-    pid_t intermediate;
-    int fd;
-    char *what; /* malloc'd in spawn_spawn */
-} libxl__spawn_starting;
+typedef struct libxl__spawn_state libxl__spawn_state;
 
-typedef struct {
-    char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */
-    const char *pid_path; /* only for libxl_spawner_record_pid */
-    int domid;
-    libxl__spawn_starting *for_spawn;
-} libxl__spawner_starting;
+/* Clears out a spawn state; idempotent. */
+_hidden void libxl__spawn_init(libxl__spawn_state*);
 
 /*
- * libxl__spawn_spawn - Create a new process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * what: string describing the spawned process
- * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
- * hook_data: data to pass to the hook function
+ * libxl__spawn_spawn - Create a new process which will become daemonic
+ * Forks twice, to allow the child to detach entirely from the parent.
+ *
+ * We call the two generated processes the "middle child" (result of
+ * the first fork) and the "inner child" (result of the second fork
+ * which takes place in the middle child).
+ *
+ * The inner child must soon exit or exec.  It must also soon exit or
+ * notify the parent of its successful startup by writing to the
+ * xenstore path xspath.
+ *
+ * The user (in the parent) will be called back (confirm_cb) every
+ * time that xenstore path is modified.
+ *
+ * In both children, the ctx is not fully usable: gc and logging
+ * operations are OK, but operations on Xen and xenstore are not.
+ * (The restrictions are the same as those which apply to children
+ * made with libxl__ev_child_fork.)
+ *
+ * midproc_cb will be called in the middle child, with the pid of the
+ * inner child; this could for example record the pid.  midproc_cb
+ * should be fast, and should return.  It will be called (reentrantly)
+ * within libxl__spawn_init.
+ *
+ * failure_cb will be called in the parent on failure of the
+ * intermediate or final child; an error message will have been
+ * logged.
+ *
+ * confirm_cb and failure_cb will not be called reentrantly from
+ * within libxl__spawn_spawn.
+ *
+ * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
- *  < 0   error, for_spawn need not be detached
- *   +1   caller is the parent, must call detach on *for_spawn eventually
+ *  < 0   error, *spawn is now Idle and need not be detached
+ *   +1   caller is the parent, *spawn is Active and must eventually be detached
  *    0   caller is now the inner child, should probably call libxl__exec
- * Caller, may pass 0 for for_spawn, in which case no need to detach.
+ *
+ * The spawn state must be Undefined or Idle on entry.
  */
-_hidden int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
-                      void *hook_data);
+_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl_spawner_record_pid - Record given pid in xenstore
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * innerchild: pid of the child
+ * libxl__spawn_detach - Detaches the daemonic child.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, failures of either child are no
+ * longer reported via failure_cb.
+ *
+ * If called before the inner child has been created, this may prevent
+ * it from running at all.  Thus this should be called only when the
+ * inner child has notified that it is ready.  Normally it will be
+ * called from within confirm_cb.
  *
- * This function is passed as intermediate_hook to libxl__spawn_spawn.
+ * Logs errors.
+ *
+ * The spawn state must be Active or Idle on entry and will be Idle
+ * on return.
  */
-_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild);
+_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
- * libxl__spawn_confirm_offspring_startup - Wait for child state
- * gc: allocation pool
- * timeout: how many seconds to wait for the child
- * what: string describing the spawned process
- * path: path to the state file in xenstore
- * state: expected string to wait for in path (optional)
- * starting: malloc'd pointer to libxl__spawner_starting
+ * If successful, this should return 0.
  *
- * Returns 0 on success, and < 0 on error.
+ * Otherwise it should return a signal number, which will be
+ * sent to the inner child; the overall spawn will then fail.
+ */
+typedef int /* signal number */
+libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner);
+
+/*
+ * Called if the spawn failed.  The reason will have been logged.
+ * The spawn state will be Idle on entry to the callback (and
+ * it may be reused immediately if desired).
+ */
+typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
+
+/*
+ * Called when the xspath watch triggers.  xspath will have been read
+ * and the result placed in xsdata; if that failed because the key
+ * didn't exist, xspath==0.  (If it failed for some other reason,
+ * the spawn machinery calls failure_cb instead.)
  *
- * This function waits the given timeout for the given path to appear
- * in xenstore, and optionally for state in path.
- * The intermediate process created in libxl__spawn_spawn is killed.
- * The memory referenced by starting->for_spawn and starting is free'd.
+ * If the child has indicated its successful startup, or a failure
+ * has occurred, this should call libxl__spawn_detach.
+ *
+ * If the child is still starting up, should simply return, doing
+ * nothing.
+ *
+ * The spawn state will be Active on entry to the callback; there
+ * are no restrictions on the state on return; it may even have
+ * been detached and reused.
  */
-_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting);
+typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
+                                     const char *xsdata);
+
+typedef struct {
+    /* Private to the spawn implementation.
+     */
+    /* This separate struct, from malloc, allows us to "detach"
+     * the child and reap it later, when our user has gone
+     * away and freed its libxl__spawn_state */
+    struct libxl__spawn_state *ss;
+    libxl__ev_child mid;
+} libxl__spawn_state_detachable;
+
+struct libxl__spawn_state {
+    /* must be filled in by user and remain valid */
+    libxl__ao *ao;
+    const char *what;
+    const char *xspath;
+    const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */
+    int timeout_ms; /* -1 means forever */
+    libxl__spawn_midproc_cb *midproc_cb;
+    libxl__spawn_failure_cb *failure_cb;
+    libxl__spawn_confirm_cb *confirm_cb;
+
+    /* remaining fields are private to libxl_spawn_... */
+    libxl__ev_time timeout;
+    libxl__ev_xswatch xswatch;
+    libxl__spawn_state_detachable *ssd;
+};
+
+static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
+    { return !!ss->ssd; }
+
+/*
+ * libxl_spawner_record_pid - Record given pid in xenstore
+ *
+ * This function can be passed directly as an intermediate_hook to
+ * libxl__spawn_spawn.  On failure, returns the value SIGTERM.
+ */
+_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
+                                    pid_t innerchild);
+
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - spawn.ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdom device models. */
+
+typedef struct {
+    /* Mixed - user must fill in public parts EXCEPT callback,
+     * which may be undefined on entry.  (See above for details) */
+    libxl__dm_spawn_state dm; /* the stub domain device model */
+    /* filled in by user, must remain valid: */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
+    /* private to libxl__spawn_stub_dm: */
+    libxl_domain_config dm_config;
+    libxl__domain_build_state dm_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stub_dm_spawn_state;
+
+_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
+
 
 /*
  * libxl__wait_for_offspring - Wait for child state
@@ -943,31 +1066,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
                                                        void *userdata),
                                  void *check_callback_userdata);
 
-/*
- * libxl__spawn_detach - Kill intermediate process from spawn_spawn
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors.  Idempotent, but only permitted after successful
- * call to libxl__spawn_spawn, and no point calling it again if it fails.
- */
-_hidden int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
-
-/*
- * libxl__spawn_check - Check intermediate child process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors but also returns them.
- * Caller must still call detach.
- */
-_hidden int libxl__spawn_check(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
@@ -986,15 +1084,6 @@ _hidden int libxl__domain_build(libxl__gc *gc,
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
-_hidden int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
-_hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1002,10 +1091,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
   /* Caller must either: pass starting_r==0, or on successful
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
-_hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting *starting);
-_hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,
                                 uint32_t domid, char *state,
                                 libxl__spawn_starting *spawning,
@@ -1576,6 +1661,31 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
 
+/*----- Domain creation -----*/
+
+typedef struct libxl__domain_create_state libxl__domain_create_state;
+
+typedef void libxl__domain_create_cb(libxl__egc *egc,
+                                     libxl__domain_create_state*,
+                                     int rc, uint32_t domid);
+
+struct libxl__domain_create_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl_domain_config *guest_config;
+    int restore_fd;
+    libxl_console_ready console_cb;
+    void *console_cb_priv;
+    libxl__domain_create_cb *callback;
+    /* private to domain_create */
+    int guest_domid;
+    libxl__domain_build_state build_state;
+    libxl__stub_dm_spawn_state dmss;
+        /* If we're not doing stubdom, we use only dmss.dm,
+         * for the non-stubdom device model. */
+};
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 28f5cab..399359e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1695,8 +1695,8 @@ start:
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                            cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                          cb, &child_console_pid,
+                                          &domid, restore_fd, 0);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1704,7 +1704,7 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                      cb, &child_console_pid, &domid, 0);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zb-00006f-FG; Wed, 25 Apr 2012 15:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uv-Rv
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:48894] by server-1.bemta-4.messagelabs.com id
	0C/A3-20925-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7466 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b5-9c; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003R1-8B;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:38 +0100
Message-ID: <1335369353-13012-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/25] libxl: provide libxl__openpty_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

General facility for ao operations to open ptys.

This will be used by the bootloader machinery.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c  |  127 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   36 ++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 4c60ad9..734a5dc 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
     return rc;
 }
 
+/*----- openpty -----*/
+
+/* implementation */
+    
+static void openpty_cleanup(libxl__openpty_state *op)
+{
+    int i;
+
+    for (i=0; i<op->count; i++) {
+        libxl__openpty_result *res = &op->results[i];
+        libxl__carefd_close(res->master);  res->master = 0;
+        libxl__carefd_close(res->slave);   res->slave = 0;
+    }
+}
+
+static void openpty_exited(libxl__egc *egc, libxl__ev_child *child,
+                           pid_t pid, int status) {
+    libxl__openpty_state *op = CONTAINER_OF(child, *op, child);
+    STATE_AO_GC(op->ao);
+
+    if (status) {
+        /* Perhaps the child gave us the fds and then exited nonzero.
+         * Well that would be odd but we don't really care. */
+        libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR
+                                                  : LIBXL__LOG_WARNING,
+                                      "openpty child", pid, status);
+    }
+    if (op->rc)
+        openpty_cleanup(op);
+    op->callback(egc, op);
+}
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp) {
+    /*
+     * This is completely crazy.  openpty calls grantpt which the spec
+     * says may fork, and may not be called with a SIGCHLD handler.
+     * Now our application may have a SIGCHLD handler so that's bad.
+     * We could perhaps block it but we'd need to block it on all
+     * threads.  This is just Too Hard.
+     *
+     * So instead, we run openpty in a child process.  That child
+     * process then of course has only our own thread and our own
+     * signal handlers.  We pass the fds back.
+     *
+     * Since our only current caller actually wants two ptys, we
+     * support calling openpty multiple times for a single fork.
+     */
+    STATE_AO_GC(op->ao);
+    int count = op->count;
+    int r, i, rc, sockets[2], ptyfds[count][2];
+    libxl__carefd *for_child = 0;
+    pid_t pid = -1;
+
+    for (i=0; i<count; i++) {
+        ptyfds[i][0] = ptyfds[i][1] = -1;
+        libxl__openpty_result *res = &op->results[i];
+        assert(!res->master);
+        assert(!res->slave);
+    }
+    sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
+
+    libxl__carefd_begin();
+    r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
+    if (r) { sockets[0] = sockets[1] = -1; }
+    for_child = libxl__carefd_opened(CTX, sockets[1]);
+    if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
+
+    pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        close(sockets[0]);
+        signal(SIGCHLD, SIG_DFL);
+
+        for (i=0; i<count; i++) {
+            r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
+            if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
+        }
+        rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
+                                2*count, &ptyfds[0][0], "ptys");
+        if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
+        _exit(0);
+    }
+
+    libxl__carefd_close(for_child);
+    for_child = 0;
+
+    /* this should be fast so do it synchronously */
+
+    libxl__carefd_begin();
+    char buf[1];
+    rc = libxl__recvmsg_fds(gc, sockets[0], buf,1,
+                            2*count, &ptyfds[0][0], "ptys");
+    if (!rc) {
+        for (i=0; i<count; i++) {
+            libxl__openpty_result *res = &op->results[i];
+            res->master = libxl__carefd_record(CTX, ptyfds[i][0]);
+            res->slave =  libxl__carefd_record(CTX, ptyfds[i][1]);
+        }
+    }
+    /* now the pty fds are in the carefds, if they were ever open */
+    libxl__carefd_unlock();
+    if (rc)
+        goto out;
+
+    rc = 0;
+
+ out:
+    if (sockets[0] >= 0) close(sockets[0]);
+    libxl__carefd_close(for_child);
+    if (libxl__ev_child_inuse(&op->child)) {
+        op->rc = rc;
+        /* we will get a callback when the child dies */
+        return 0;
+    }
+
+    assert(rc);
+    openpty_cleanup(op);
+    return rc;
+}
+
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0c1c8f9..2aa32cc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1508,6 +1508,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- openpty -----*/
+
+/*
+ * opens count (>0) ptys like count calls to openpty, and then
+ * calls back.  On entry, all op[].master and op[].slave must be
+ * 0.  On callback, either rc==0 and master and slave are non-0,
+ * or rc is a libxl error and they are both 0.  If libxl__openpty
+ * returns non-0 no callback will happen and everything is left
+ * cleaned up.
+ */
+
+typedef struct libxl__openpty_state libxl__openpty_state;
+typedef struct libxl__openpty_result libxl__openpty_result;
+typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op);
+
+struct libxl__openpty_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__openpty_callback *callback;
+    int count;
+    libxl__openpty_result *results; /* actual size is count, out parameter */
+    /* public, result, caller may only read in callback */
+    int rc;
+    /* private for implementation */
+    libxl__ev_child child;
+};
+
+struct libxl__openpty_result {
+    libxl__carefd *master, *slave;
+};
+
+int libxl__openptys(libxl__openpty_state *op,
+                    const struct termios *termp,
+                    const struct winsize *winp);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Za-00005e-5t; Wed, 25 Apr 2012 15:56:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008UT-82
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.143.99:48846] by server-2.bemta-4.messagelabs.com id
	1C/B5-17550-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7368 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bS-QA; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RX-O1;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:45 +0100
Message-ID: <1335369353-13012-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/25] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn becomes a callback-style asynchronous function.
The implementation is now in terms of libxl__ev_* including
libxl_ev_child.

All the callers need to be updated.  This includes the device model
spawning functions libxl__create_device_model and
libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
abolished; instead the dm spawner calls back.

(The choice of which kind of device model to create is lifted out of
what used to be libxl__create_device_model, because that function was
indirectly recursive.  Recursive callback-style operations are clumsy
because they require a pointer indirection for the nested states.)

Waiting for proper device model startup it is no longer notionally
optional.  Previously the code appeared to tolerate this by passing
NULL for various libxl__spawner_starting* parameters to device model
spawners.  However, this was not used anywhere.

Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
no longer supported.  It remains as an unused formal parameter to
avoid updating, in this patch, all the call sites which pass NULL.
libxl__wait_for_offspring is in any case itself an obsolete function,
so this wrinkle will go away when its callers are updated to use the
event system.  Consequently libxl__spawn_check is also abolished.

The "console ready" callback also remains unchanged in this patch.
The API for this needs to be reviewed in the context of the event
series and its reentrancy restrictions documented.

Thus their callers need to be updated.  These are the domain creation
functions libxl_domain_create_new and _restore.  These functions now
take ao_hows, and have a private state structure.

However domain creation remains not completely converted to the event
mechanism; in particular it runs the outward-facing function
libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
happens in the current code this is not a bug because none of the rest
of the functionality surrounding the bootloader call will mind if the
event loop is reentered in the middle of its execution.

The file-scope function libxl__set_fd_flag which was used by the
previous spawn arrangements becomes unused and is removed; other
places in libxl can use libxl_fd_set_nonblock and
libxl_fd_set_cloexec, which of course remain.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v7:
 * Rename libxl__spawn_stubdom to libxl__spawn_stub_dm (and ..._state);
   rename the state's stubdom_* members to dm_*.
 * Eliminate the union between the two dm creation states in
   libxl__domain_create_state.  Instead, the domain creation code
   simply uses libxl__stub_dm_spawn_state.dm directly, if we're
   taking the local dm path.
 * Remove a spurious "break".
 * In domain creation, move the PV non-qemu case into the switch.
 * Code style fixes.
 * Constify some convenience aliases.
 * Improve comments (including typo fixes).
---
 tools/libxl/libxl.h          |   14 ++-
 tools/libxl/libxl_create.c   |  206 +++++++++++++++++++-----
 tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
 tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
 tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
 tools/libxl/xl_cmdimpl.c     |    6 +-
 6 files changed, 683 insertions(+), 402 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 3087146..b497430 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
-int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
-int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+  /* fixme-ao   Need to review this API.  If we keep it, the reentrancy
+   * properties need to be documented but they may turn out to be too
+   * awkward */
+
+int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            const libxl_asyncop_how *ao_how);
+int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how);
+
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 92e6951..0f17202 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -558,16 +558,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
-static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv,
-                            uint32_t *domid_out, int restore_fd)
+/*----- main domain creation -----*/
+
+/* We have a linear control flow; only one event callback is
+ * outstanding at any time.  Each initiation and callback function
+ * arranges for the next to be called, as the very last thing it
+ * does.  (If that particular sub-operation is not needed, a
+ * function will call the next event callback directly.)
+ */
+
+/* Event callbacks, in this order: */
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+/* Our own function to clean up and call the user's callback.
+ * The final call in the sequence. */
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc);
+
+static void initiate_domain_create(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs)
 {
+    STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    libxl__spawner_starting *dm_starting = 0;
-    libxl__domain_build_state state[1];
     uint32_t domid;
     int i, ret;
 
+    /* convenience aliases */
+    libxl_domain_config *const d_config = dcs->guest_config;
+    const int restore_fd = dcs->restore_fd;
+    const libxl_console_ready cb = dcs->console_cb;
+    void *const priv = dcs->console_cb_priv;
+
     domid = 0;
 
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
@@ -580,9 +604,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         goto error_out;
     }
 
+    dcs->guest_domid = domid;
+    dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */
+
     if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
@@ -606,7 +633,17 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         }
     }
 
-    memset(state, 0, sizeof(*state));
+    memset(&dcs->build_state, 0, sizeof(dcs->build_state));
+    libxl__domain_build_state *state = &dcs->build_state;
+
+    /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm.
+     * Fill in any field required by either, including both relevant
+     * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */
+    dcs->dmss.dm.spawn.ao = ao;
+    dcs->dmss.dm.guest_config = dcs->guest_config;
+    dcs->dmss.dm.build_state = &dcs->build_state;
+    dcs->dmss.dm.callback = domcreate_devmodel_started;
+    dcs->dmss.callback = domcreate_devmodel_started;
 
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
@@ -656,14 +693,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        ret = libxl__create_device_model(gc, domid, d_config,
-                                         state, &dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "failed to create device model: %d", ret);
-            goto error_out;
-        }
-        break;
+        dcs->dmss.dm.guest_domid = domid;
+        if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
+            libxl__spawn_stub_dm(egc, &dcs->dmss);
+        else
+            libxl__spawn_local_dm(egc, &dcs->dmss.dm);
+        return;
     }
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -690,26 +725,52 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         libxl__device_console_dispose(&console);
 
         if (need_qemu) {
-            libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting);
+            dcs->dmss.dm.guest_domid = domid;
+            libxl__spawn_local_dm(egc, &dcs->dmss.dm);
+            return;
+        } else {
+            assert(!dcs->dmss.dm.guest_domid);
+            domcreate_devmodel_started(egc, &dcs->dmss.dm, 0);
+            return;
         }
-        break;
     }
     default:
         ret = ERROR_INVAL;
         goto error_out;
     }
+    abort(); /* not reached */
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_devmodel_started(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int ret)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss.dm);
+    STATE_AO_GC(dmss->spawn.ao);
+    int i;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *const d_config = dcs->guest_config;
+    const libxl_console_ready cb = dcs->console_cb;
+    void *const priv = dcs->console_cb_priv;
+
+    if (ret) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "device model did not start: %d", ret);
+        goto error_out;
+    }
 
-    if (dm_starting) {
+    if (dcs->dmss.dm.guest_domid) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(gc, domid, d_config);
         }
-        ret = libxl__confirm_device_model_startup(gc, state, dm_starting);
-        if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "device model did not start: %d", ret);
-            goto error_out;
-        }
     }
 
     for (i = 0; i < d_config->num_pcidevs; i++)
@@ -737,38 +798,95 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
-        if ( (*cb)(ctx, domid, priv) )
-            goto error_out;
+        ret = (*cb)(ctx, domid, priv);
+        if (ret) goto error_out;
     }
 
-    *domid_out = domid;
-    return 0;
+    domcreate_complete(egc, dcs, 0);
+    return;
 
 error_out:
-    if (domid)
-        libxl_domain_destroy(ctx, domid);
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
 
-    return ret;
+static void domcreate_complete(libxl__egc *egc,
+                               libxl__domain_create_state *dcs,
+                               int rc)
+{
+    STATE_AO_GC(dcs->ao);
+
+    if (rc) {
+        if (dcs->guest_domid) {
+            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
+            if (rc2)
+                LOG(ERROR, "unable to destroy domain %d following"
+                    " failed creation", dcs->guest_domid);
+        }
+        dcs->guest_domid = -1;
+    }
+    dcs->callback(egc, dcs, rc, dcs->guest_domid);
 }
 
+/*----- application-facing domain creation interface -----*/
+
+typedef struct {
+    libxl__domain_create_state dcs;
+    uint32_t *domid_out;
+} libxl__app_domain_create_state;
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid);
+
+static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            libxl_console_ready cb, void *priv, uint32_t *domid,
+                            int restore_fd, const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, 0, ao_how);
+    libxl__app_domain_create_state *cdcs;
+
+    GCNEW(cdcs);
+    cdcs->dcs.ao = ao;
+    cdcs->dcs.guest_config = d_config;
+    cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.console_cb = cb;
+    cdcs->dcs.console_cb_priv = priv;
+    cdcs->dcs.callback = domain_create_cb;
+    cdcs->domid_out = domid;
+
+    initiate_domain_create(egc, &cdcs->dcs);
+
+    return AO_INPROGRESS;
+}
+
+static void domain_create_cb(libxl__egc *egc,
+                             libxl__domain_create_state *dcs,
+                             int rc, uint32_t domid)
+{
+    libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs);
+    STATE_AO_GC(cdcs->dcs.ao);
+
+    if (!rc)
+        *cdcs->domid_out = domid;
+
+    libxl__ao_complete(egc, ao, rc);
+}
+    
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
-                            libxl_console_ready cb, void *priv, uint32_t *domid)
+                            libxl_console_ready cb, void *priv,
+                            uint32_t *domid,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how);
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
-                                libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
+                                libxl_console_ready cb, void *priv,
+                                uint32_t *domid, int restore_fd,
+                                const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc;
-    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
-    GC_FREE;
-    return rc;
+    return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 73db62e..7035f1b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -667,24 +667,28 @@ retry_transaction:
     return 0;
 }
 
-static int libxl__create_stubdom(libxl__gc *gc,
-                                 int guest_domid,
-                                 libxl_domain_config *guest_config,
-                                 libxl__domain_build_state *d_state,
-                                 libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc);
+
+void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 {
+    STATE_AO_GC(sdss->dm.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl__device_console *console;
-    libxl_domain_config dm_config[1];
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state stubdom_state[1];
-    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
-    libxl__spawner_starting *dm_starting = 0;
+
+    /* convenience aliases */
+    libxl_domain_config *const dm_config = &sdss->dm_config;
+    libxl_domain_config *const guest_config = sdss->dm.guest_config;
+    const int guest_domid = sdss->dm.guest_domid;
+    libxl__domain_build_state *const d_state = sdss->dm.build_state;
+    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -692,6 +696,8 @@ static int libxl__create_stubdom(libxl__gc *gc,
         goto out;
     }
 
+    sdss->pvqemu.guest_domid = 0;
+
     libxl_domain_create_info_init(&dm_config->c_info);
     dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config->c_info.name = libxl__sprintf(gc, "%s-dm",
@@ -739,10 +745,10 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config->num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    dm_domid = 0;
-    ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid);
+    ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
     if (ret)
         goto out;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
     ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state);
     if (ret)
         goto out;
@@ -850,42 +856,67 @@ retry_transaction:
             goto out_free;
     }
 
-    if (libxl__create_xenpv_qemu(gc, dm_domid,
-                                 dm_config,
-                                 stubdom_state,
-                                 &dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
-        ret = ERROR_FAIL;
-        goto out_free;
-    }
-
-    libxl_domain_unpause(ctx, dm_domid);
+    sdss->pvqemu.guest_domid = dm_domid;
+    sdss->pvqemu.guest_config = &sdss->dm_config;
+    sdss->pvqemu.build_state = &sdss->dm_state;
+    sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
-    if (starting_r) {
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = guest_domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
-        (*starting_r)->for_spawn = NULL;
-    }
+    libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    ret = 0;
+    free(args);
+    return;
 
 out_free:
     free(args);
 out:
-    return ret;
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
 }
 
-int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r)
+static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
+                                libxl__dm_spawn_state *stubdom_dmss,
+                                int rc)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__stub_dm_spawn_state *sdss =
+        CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
+    STATE_AO_GC(sdss->dm.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) goto out;
+
+    rc = libxl_domain_unpause(CTX, dm_domid);
+    if (rc) goto out;
+
+ out:
+    if (rc) {
+        if (dm_domid)
+            libxl_domain_destroy(CTX, dm_domid);
+    }
+    sdss->callback(egc, &sdss->dm, rc);
+}
+
+/* callbacks passed to libxl__spawn_spawn */
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata);
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn);
+
+/* our "next step" function, called from those callbacks and elsewhere */
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc);
+
+void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
+{
+    /* convenience aliases */
+    const int domid = dmss->guest_domid;
+    libxl__domain_build_state *const state = dmss->build_state;
+    libxl__spawn_state *const spawn = &dmss->spawn;
+
+    STATE_AO_GC(dmss->spawn.ao);
+
+    libxl_ctx *ctx = CTX;
+    libxl_domain_config *guest_config = dmss->guest_config;
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
@@ -893,15 +924,13 @@ int libxl__create_device_model(libxl__gc *gc,
     int logfile_w, null;
     int rc;
     char **args, **arg;
-    libxl__spawner_starting buf_starting, *p;
     xs_transaction_t t;
     char *vm_path;
     char **pass_stuff;
     const char *dm;
 
     if (libxl_defbool_val(b_info->device_model_stubdomain)) {
-        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
-        goto out;
+        abort();
     }
 
     dm = libxl__domain_device_model(gc, b_info);
@@ -945,25 +974,8 @@ int libxl__create_device_model(libxl__gc *gc,
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
-    if (starting_r) {
-        rc = ERROR_NOMEM;
-        *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        if (!*starting_r)
-            goto out_close;
-        p = *starting_r;
-        p->for_spawn = calloc(1, sizeof(libxl__spawn_starting));
-    } else {
-        p = &buf_starting;
-        p->for_spawn = NULL;
-    }
-
-    p->domid = domid;
-    p->dom_path = libxl__xs_get_dompath(gc, domid);
-    p->pid_path = "image/device-model-pid";
-    if (!p->dom_path) {
-        rc = ERROR_FAIL;
-        goto out_close;
-    }
+    const char *dom_path = libxl__xs_get_dompath(gc, domid);
+    spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid");
 
     if (vnc && vnc->passwd) {
         /* This xenstore key will only be used by qemu-xen-traditionnal.
@@ -971,7 +983,7 @@ int libxl__create_device_model(libxl__gc *gc,
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
-        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path));
+        vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path));
         if (vm_path) {
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
@@ -988,8 +1000,15 @@ retry_transaction:
     for (arg = args; *arg; arg++)
         LIBXL__LOG(CTX, XTL_DEBUG, "  %s", *arg);
 
-    rc = libxl__spawn_spawn(gc, p->for_spawn, "device model",
-                            libxl_spawner_record_pid, p);
+    spawn->what = GCSPRINTF("domain %d device model", domid);
+    spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid);
+    spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+    spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
+    spawn->midproc_cb = libxl__spawn_record_pid;
+    spawn->confirm_cb = device_model_confirm;
+    spawn->failure_cb = device_model_startup_failed;
+
+    rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
     if (!rc) { /* inner child */
@@ -1004,30 +1023,61 @@ out_close:
     close(logfile_w);
     free(args);
 out:
-    return rc;
+    if (rc)
+        device_model_spawn_outcome(egc, dmss, rc);
+}
+
+
+static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+                                 const char *xsdata)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    STATE_AO_GC(spawn->ao);
+
+    if (!xsdata)
+        return;
+
+    if (strcmp(xsdata, "running"))
+        return;
+
+    libxl__spawn_detach(gc, spawn);
+
+    device_model_spawn_outcome(egc, dmss, 0);
 }
 
+static void device_model_startup_failed(libxl__egc *egc,
+                                        libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
+}
 
-int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl__domain_build_state *state,
-                                libxl__spawner_starting *starting)
+static void device_model_spawn_outcome(libxl__egc *egc,
+                                       libxl__dm_spawn_state *dmss,
+                                       int rc)
 {
-    char *path;
-    int domid = starting->domid;
-    int ret, ret2;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    ret = libxl__spawn_confirm_offspring_startup(gc,
-                                     LIBXL_DEVICE_MODEL_START_TIMEOUT,
-                                     "Device Model", path, "running", starting);
+    STATE_AO_GC(dmss->spawn.ao);
+    int ret2;
+
+    if (rc)
+        LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc);
+
+    libxl__domain_build_state *state = dmss->build_state;
+
     if (state->saved_state) {
         ret2 = unlink(state->saved_state);
-        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
-                                   "failed to remove device-model state %s\n",
-                                   state->saved_state);
-        /* Do not clobber spawn_confirm error code with unlink error code. */
-        if (!ret) ret = ret2;
+        if (ret2) {
+            LOGE(ERROR, "%s: failed to remove device-model state %s",
+                 dmss->spawn.what, state->saved_state);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
-    return ret;
+
+    rc = 0;
+
+ out:
+    dmss->callback(egc, dmss, rc);
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
@@ -1123,15 +1173,6 @@ out:
     return ret;
 }
 
-int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                             libxl_domain_config *guest_config,
-                             libxl__domain_build_state *state,
-                             libxl__spawner_starting **starting_r)
-{
-    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 2ee2154..d44b702 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx,
     }
 }
 
-void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild)
+int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn,
+                            pid_t innerchild)
 {
-    libxl__spawner_starting *starting = for_spawn;
-    struct xs_handle *xsh;
-    char *path = NULL, *pid = NULL;
-    int len;
-
-    if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0)
-        goto out;
+    struct xs_handle *xsh = NULL;
+    const char *pid = NULL;
+    int rc, xsok;
 
-    len = asprintf(&pid, "%d", innerchild);
-    if (len < 0)
-        goto out;
+    pid = GCSPRINTF("%d", innerchild);
 
     /* we mustn't use the parent's handle in the child */
     xsh = xs_daemon_open();
+    if (!xsh) {
+        LOGE(ERROR, "write %s = %s: xenstore reopen failed",
+             spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
 
-    xs_write(xsh, XBT_NULL, path, pid, len);
+    xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid));
+    if (!xsok) {
+        LOGE(ERROR,
+             "write %s = %s: xenstore write failed", spawn->pidpath, pid);
+        rc = ERROR_FAIL;  goto out;
+    }
+
+    rc = 0;
 
-    xs_daemon_close(xsh);
 out:
-    free(path);
-    free(pid);
+    if (xsh) xs_daemon_close(xsh);
+    return rc ? SIGTERM : 0;
 }
 
 int libxl__wait_for_offspring(libxl__gc *gc,
@@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc,
     tv.tv_sec = timeout;
     tv.tv_usec = 0;
     nfds = xs_fileno(xsh) + 1;
-    if (spawning && spawning->fd > xs_fileno(xsh))
-        nfds = spawning->fd + 1;
+    assert(!spawning);
 
     while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        if ( spawning ) {
-            rc = libxl__spawn_check(gc, spawning);
-            if ( rc ) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "%s died during startup", what);
-                rc = -1;
-                goto err_died;
-            }
-        }
         p = xs_read(xsh, XBT_NULL, path, &len);
         if ( NULL == p )
             goto again;
@@ -218,8 +214,6 @@ again:
         free(p);
         FD_ZERO(&rfds);
         FD_SET(xs_fileno(xsh), &rfds);
-        if (spawning)
-            FD_SET(spawning->fd, &rfds);
         rc = select(nfds, &rfds, NULL, NULL, &tv);
         if (rc > 0) {
             if (FD_ISSET(xs_fileno(xsh), &rfds)) {
@@ -229,207 +223,215 @@ again:
                 else
                     goto again;
             }
-            if (spawning && FD_ISSET(spawning->fd, &rfds)) {
-                unsigned char dummy;
-                if (read(spawning->fd, &dummy, sizeof(dummy)) != 1)
-                    LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG,
-                                     "failed to read spawn status pipe");
-            }
         }
     }
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what);
-err_died:
+
     xs_unwatch(xsh, path, path);
     xs_daemon_close(xsh);
 err:
     return -1;
 }
 
-static int detach_offspring(libxl__gc *gc,
-                               libxl__spawner_starting *starting)
-{
-    int rc;
-    rc = libxl__spawn_detach(gc, starting->for_spawn);
-    if (starting->for_spawn)
-        free(starting->for_spawn);
-    free(starting);
-    return rc;
-}
 
-int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting)
-{
-    int detach;
-    int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what,
-                                               path, state,
-                                               starting->for_spawn, NULL, NULL);
-    detach = detach_offspring(gc, starting);
-    return problem ? problem : detach;
-}
+/*----- spawn implementation -----*/
 
-static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag)
-{
-    int flags;
+/*
+ * Full set of possible states of a libxl__spawn_state and its _detachable:
+ *
+ *               ss->        ss->        ss->    | ssd->       ssd->
+ *               timeout     xswatch     ssd     |  mid         ss
+ *  - Undefined   undef       undef       no     |  -           -
+ *  - Idle        Idle        Idle        no     |  -           -
+ *  - Active      Active      Active      yes    |  Active      yes
+ *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
+ *  - Detached    -           -           -      |  Active      no
+ *
+ * When in state Detached, the middle process has been sent a SIGKILL.
+ */
 
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1)
-        return ERROR_FAIL;
+/* Event callbacks. */
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path);
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs);
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status);
 
-    flags |= flag;
+/* Precondition: Partial.  Results: Detached. */
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-    if (fcntl(fd, F_SETFL, flags) == -1)
-        return ERROR_FAIL;
+/* Precondition: Partial; caller has logged failure reason.
+ * Results: Caller notified of failure;
+ *  after return, ss may be completely invalid as caller may reuse it */
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
 
-    return 0;
+void libxl__spawn_init(libxl__spawn_state *ss)
+{
+    libxl__ev_time_init(&ss->timeout);
+    libxl__ev_xswatch_init(&ss->xswatch);
+    ss->ssd = 0;
 }
 
-int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn,
-                                                pid_t innerchild),
-                      void *hook_data)
+int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    pid_t child, got;
+    STATE_AO_GC(ss->ao);
+    int r;
+    pid_t child;
     int status, rc;
-    pid_t intermediate;
-    int pipes[2];
-    unsigned char dummy = 0;
-
-    if (for_spawn) {
-        for_spawn->what = strdup(what);
-        if (!for_spawn->what) return ERROR_NOMEM;
-
-        if (libxl_pipe(ctx, pipes) < 0)
-            goto err_parent;
-        if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 ||
-            libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0)
-            goto err_parent_pipes;
-    }
 
-    intermediate = libxl_fork(ctx);
-    if (intermediate ==-1)
-        goto err_parent_pipes;
+    libxl__spawn_init(ss);
+    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    libxl__ev_child_init(&ss->ssd->mid);
+
+    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
+                                     spawn_timeout, ss->timeout_ms);
+    if (rc) goto out_err;
 
-    if (intermediate) {
+    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
+                                    spawn_watch_event, ss->xspath);
+    if (rc) goto out_err;
+
+    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
+
+    if (middle) {
         /* parent */
-        if (for_spawn) {
-            for_spawn->intermediate = intermediate;
-            for_spawn->fd = pipes[0];
-            close(pipes[1]);
-        }
         return 1;
     }
 
-    /* we are now the intermediate process */
-    if (for_spawn) close(pipes[0]);
+    /* we are now the middle process */
 
     child = fork();
     if (child == -1)
         exit(255);
     if (!child) {
-        if (for_spawn) close(pipes[1]);
         return 0; /* caller runs child code */
     }
 
-    intermediate_hook(hook_data, child);
-
-    if (!for_spawn) _exit(0); /* just detach then */
-
-    got = waitpid(child, &status, 0);
-    assert(got == child);
-
-    rc = (WIFEXITED(status) ? WEXITSTATUS(status) :
-          WIFSIGNALED(status) && WTERMSIG(status) < 127
-          ? WTERMSIG(status)+128 : -1);
-    if (for_spawn) {
-        if (write(pipes[1], &dummy, sizeof(dummy)) != 1)
-            perror("libxl__spawn_spawn: unable to signal child exit to parent");
+    int failsig = ss->midproc_cb(gc, ss, middle);
+    if (failsig) {
+        kill(child, failsig);
+        _exit(127);
     }
-    _exit(rc);
 
- err_parent_pipes:
-    if (for_spawn) {
-        close(pipes[0]);
-        close(pipes[1]);
+    for (;;) {
+        pid_t got = waitpid(child, &status, 0);
+        if (got == -1) {
+            assert(errno == EINTR);
+            continue;
+        }
+        assert(got == child);
+        break;
     }
 
- err_parent:
-    if (for_spawn) free(for_spawn->what);
+    r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) :
+         WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 :
+         -1);
+    _exit(r);
 
-    return ERROR_FAIL;
+ out_err:
+    spawn_cleanup(gc, ss);
+    return rc;
 }
 
-static void report_spawn_intermediate_status(libxl__gc *gc,
-                                             libxl__spawn_starting *for_spawn,
-                                             int status)
+static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
-    if (!WIFEXITED(status)) {
-        libxl_ctx *ctx = libxl__gc_owner(gc);
-        char *intermediate_what;
-        /* intermediate process did the logging itself if it exited */
-        if ( asprintf(&intermediate_what,
-                 "%s intermediate process (startup monitor)",
-                 for_spawn->what) < 0 )
-            intermediate_what = "intermediate process (startup monitor)";
-        libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what,
-                                      for_spawn->intermediate, status);
+    int r;
+
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+
+    libxl__spawn_state_detachable *ssd = ss->ssd;
+    if (ssd) {
+        if (libxl__ev_child_inuse(&ssd->mid)) {
+            pid_t child = ssd->mid.pid;
+            r = kill(child, SIGKILL);
+            if (r && errno != ESRCH)
+                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+                     ss->what, (unsigned long)child);
+        }
+
+        /* disconnect the ss and ssd from each other */
+        ssd->ss = 0;
+        ss->ssd = 0;
     }
 }
 
-int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn)
+static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int r, status;
-    pid_t got;
-    int rc = 0;
+    EGC_GC;
+    spawn_cleanup(gc, ss);
+    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+}
 
-    if (!for_spawn) return 0;
+static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                          const struct timeval *requested_abs)
+{
+    /* Before event, was Active; is now Partial. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
+    LOG(ERROR, "%s: startup timed out", ss->what);
+    spawn_failed(egc, ss); /* must be last */
+}
 
-    if (for_spawn->intermediate) {
-        r = kill(for_spawn->intermediate, SIGKILL);
-        if (r) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                         "could not kill %s intermediate process [%ld]",
-                         for_spawn->what,
-                         (unsigned long)for_spawn->intermediate);
-            abort(); /* things are very wrong */
-        }
-        got = waitpid(for_spawn->intermediate, &status, 0);
-        assert(got == for_spawn->intermediate);
-        if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) {
-            report_spawn_intermediate_status(gc, for_spawn, status);
-            rc = ERROR_FAIL;
-        }
-        for_spawn->intermediate = 0;
+static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                              const char *watch_path, const char *event_path)
+{
+    /* On entry, is Active. */
+    EGC_GC;
+    libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
+    char *p = libxl__xs_read(gc, 0, ss->xspath);
+    if (!p && errno != ENOENT) {
+        LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
+        spawn_failed(egc, ss); /* must be last */
+        return;
     }
-
-    free(for_spawn->what);
-    for_spawn->what = 0;
-
-    return rc;
+    ss->confirm_cb(egc, ss, p); /* must be last */
 }
 
-int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn)
+static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
+                               pid_t pid, int status)
+    /* Before event, was Active or Detached;
+     * is now Active or Detached except that ssd->mid is Idle */
 {
-    pid_t got;
-    int status;
-
-    if (!for_spawn) return 0;
+    EGC_GC;
+    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
+    libxl__spawn_state *ss = ssd->ss;
 
-    assert(for_spawn->intermediate);
-    got = waitpid(for_spawn->intermediate, &status, WNOHANG);
-    if (!got) return 0;
-
-    assert(got == for_spawn->intermediate);
-    report_spawn_intermediate_status(gc, for_spawn, status);
+    if (!WIFEXITED(status)) {
+        const char *what =
+            GCSPRINTF("%s intermediate process (startup monitor)",
+                      ss ? ss->what : "(detached)");
+        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+        libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
+    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        if (!status)
+            LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
+                " when we were waiting for it to confirm startup",
+                ss->what, (unsigned long)pid);
+        else if (status <= 127)
+            LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d",
+                ss->what, (unsigned long)pid, status);
+        else if (status < 255) {
+            int sig = status - 128;
+            const char *str = strsignal(sig);
+            if (str)
+                LOG(ERROR, "%s [%ld]: died during startup due to fatal"
+                    " signal %s", ss->what, (unsigned long)pid, str);
+            else
+                LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
+                    " signal number %d", ss->what, (unsigned long)pid, sig);
+        }
+        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
+        spawn_failed(egc, ss); /* must be last use of ss */
+    }
+    free(ssd);
+}
 
-    for_spawn->intermediate = 0;
-    return ERROR_FAIL;
+void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    spawn_cleanup(gc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0109f79..90b08ef 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -842,75 +842,198 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                                       libxl_device_pci *pcidev, int num);
 _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
 
-/* xl_exec */
+/*
+ *----- spawn -----
+ *
+ * Higher-level double-fork and separate detach eg as for device models
+ *
+ * Each libxl__spawn_state is in one of the conventional states
+ *    Undefined, Idle, Active
+ */
 
- /* higher-level double-fork and separate detach eg as for device models */
+typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
+/* this type is never defined, so no objects of this type exist
+ * fixme-ao  This should go away completely.  */
 
-typedef struct {
-    /* put this in your own status structure as returned to application */
-    /* all fields are private to libxl_spawn_... */
-    pid_t intermediate;
-    int fd;
-    char *what; /* malloc'd in spawn_spawn */
-} libxl__spawn_starting;
+typedef struct libxl__spawn_state libxl__spawn_state;
 
-typedef struct {
-    char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */
-    const char *pid_path; /* only for libxl_spawner_record_pid */
-    int domid;
-    libxl__spawn_starting *for_spawn;
-} libxl__spawner_starting;
+/* Clears out a spawn state; idempotent. */
+_hidden void libxl__spawn_init(libxl__spawn_state*);
 
 /*
- * libxl__spawn_spawn - Create a new process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * what: string describing the spawned process
- * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid
- * hook_data: data to pass to the hook function
+ * libxl__spawn_spawn - Create a new process which will become daemonic
+ * Forks twice, to allow the child to detach entirely from the parent.
+ *
+ * We call the two generated processes the "middle child" (result of
+ * the first fork) and the "inner child" (result of the second fork
+ * which takes place in the middle child).
+ *
+ * The inner child must soon exit or exec.  It must also soon exit or
+ * notify the parent of its successful startup by writing to the
+ * xenstore path xspath.
+ *
+ * The user (in the parent) will be called back (confirm_cb) every
+ * time that xenstore path is modified.
+ *
+ * In both children, the ctx is not fully usable: gc and logging
+ * operations are OK, but operations on Xen and xenstore are not.
+ * (The restrictions are the same as those which apply to children
+ * made with libxl__ev_child_fork.)
+ *
+ * midproc_cb will be called in the middle child, with the pid of the
+ * inner child; this could for example record the pid.  midproc_cb
+ * should be fast, and should return.  It will be called (reentrantly)
+ * within libxl__spawn_init.
+ *
+ * failure_cb will be called in the parent on failure of the
+ * intermediate or final child; an error message will have been
+ * logged.
+ *
+ * confirm_cb and failure_cb will not be called reentrantly from
+ * within libxl__spawn_spawn.
+ *
+ * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
- *  < 0   error, for_spawn need not be detached
- *   +1   caller is the parent, must call detach on *for_spawn eventually
+ *  < 0   error, *spawn is now Idle and need not be detached
+ *   +1   caller is the parent, *spawn is Active and must eventually be detached
  *    0   caller is now the inner child, should probably call libxl__exec
- * Caller, may pass 0 for for_spawn, in which case no need to detach.
+ *
+ * The spawn state must be Undefined or Idle on entry.
  */
-_hidden int libxl__spawn_spawn(libxl__gc *gc,
-                      libxl__spawn_starting *for_spawn,
-                      const char *what,
-                      void (*intermediate_hook)(void *for_spawn, pid_t innerchild),
-                      void *hook_data);
+_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl_spawner_record_pid - Record given pid in xenstore
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- * innerchild: pid of the child
+ * libxl__spawn_detach - Detaches the daemonic child.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, failures of either child are no
+ * longer reported via failure_cb.
+ *
+ * If called before the inner child has been created, this may prevent
+ * it from running at all.  Thus this should be called only when the
+ * inner child has notified that it is ready.  Normally it will be
+ * called from within confirm_cb.
  *
- * This function is passed as intermediate_hook to libxl__spawn_spawn.
+ * Logs errors.
+ *
+ * The spawn state must be Active or Idle on entry and will be Idle
+ * on return.
  */
-_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild);
+_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
- * libxl__spawn_confirm_offspring_startup - Wait for child state
- * gc: allocation pool
- * timeout: how many seconds to wait for the child
- * what: string describing the spawned process
- * path: path to the state file in xenstore
- * state: expected string to wait for in path (optional)
- * starting: malloc'd pointer to libxl__spawner_starting
+ * If successful, this should return 0.
  *
- * Returns 0 on success, and < 0 on error.
+ * Otherwise it should return a signal number, which will be
+ * sent to the inner child; the overall spawn will then fail.
+ */
+typedef int /* signal number */
+libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner);
+
+/*
+ * Called if the spawn failed.  The reason will have been logged.
+ * The spawn state will be Idle on entry to the callback (and
+ * it may be reused immediately if desired).
+ */
+typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
+
+/*
+ * Called when the xspath watch triggers.  xspath will have been read
+ * and the result placed in xsdata; if that failed because the key
+ * didn't exist, xspath==0.  (If it failed for some other reason,
+ * the spawn machinery calls failure_cb instead.)
  *
- * This function waits the given timeout for the given path to appear
- * in xenstore, and optionally for state in path.
- * The intermediate process created in libxl__spawn_spawn is killed.
- * The memory referenced by starting->for_spawn and starting is free'd.
+ * If the child has indicated its successful startup, or a failure
+ * has occurred, this should call libxl__spawn_detach.
+ *
+ * If the child is still starting up, should simply return, doing
+ * nothing.
+ *
+ * The spawn state will be Active on entry to the callback; there
+ * are no restrictions on the state on return; it may even have
+ * been detached and reused.
  */
-_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc,
-                                       uint32_t timeout, char *what,
-                                       char *path, char *state,
-                                       libxl__spawner_starting *starting);
+typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
+                                     const char *xsdata);
+
+typedef struct {
+    /* Private to the spawn implementation.
+     */
+    /* This separate struct, from malloc, allows us to "detach"
+     * the child and reap it later, when our user has gone
+     * away and freed its libxl__spawn_state */
+    struct libxl__spawn_state *ss;
+    libxl__ev_child mid;
+} libxl__spawn_state_detachable;
+
+struct libxl__spawn_state {
+    /* must be filled in by user and remain valid */
+    libxl__ao *ao;
+    const char *what;
+    const char *xspath;
+    const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */
+    int timeout_ms; /* -1 means forever */
+    libxl__spawn_midproc_cb *midproc_cb;
+    libxl__spawn_failure_cb *failure_cb;
+    libxl__spawn_confirm_cb *confirm_cb;
+
+    /* remaining fields are private to libxl_spawn_... */
+    libxl__ev_time timeout;
+    libxl__ev_xswatch xswatch;
+    libxl__spawn_state_detachable *ssd;
+};
+
+static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
+    { return !!ss->ssd; }
+
+/*
+ * libxl_spawner_record_pid - Record given pid in xenstore
+ *
+ * This function can be passed directly as an intermediate_hook to
+ * libxl__spawn_spawn.  On failure, returns the value SIGTERM.
+ */
+_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
+                                    pid_t innerchild);
+
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - spawn.ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdom device models. */
+
+typedef struct {
+    /* Mixed - user must fill in public parts EXCEPT callback,
+     * which may be undefined on entry.  (See above for details) */
+    libxl__dm_spawn_state dm; /* the stub domain device model */
+    /* filled in by user, must remain valid: */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
+    /* private to libxl__spawn_stub_dm: */
+    libxl_domain_config dm_config;
+    libxl__domain_build_state dm_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stub_dm_spawn_state;
+
+_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
+
 
 /*
  * libxl__wait_for_offspring - Wait for child state
@@ -943,31 +1066,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc,
                                                        void *userdata),
                                  void *check_callback_userdata);
 
-/*
- * libxl__spawn_detach - Kill intermediate process from spawn_spawn
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors.  Idempotent, but only permitted after successful
- * call to libxl__spawn_spawn, and no point calling it again if it fails.
- */
-_hidden int libxl__spawn_detach(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
-
-/*
- * libxl__spawn_check - Check intermediate child process
- * gc: allocation pool
- * for_spawn: malloc'd pointer to libxl__spawn_starting (optional)
- *
- * Returns 0 on success, and < 0 on error.
- *
- * Logs errors but also returns them.
- * Caller must still call detach.
- */
-_hidden int libxl__spawn_check(libxl__gc *gc,
-                       libxl__spawn_starting *for_spawn);
 
  /* low-level stuff, for synchronous subprocesses etc. */
 
@@ -986,15 +1084,6 @@ _hidden int libxl__domain_build(libxl__gc *gc,
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
-_hidden int libxl__create_device_model(libxl__gc *gc,
-                              int domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
-_hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
-                              libxl_domain_config *guest_config,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1002,10 +1091,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
   /* Caller must either: pass starting_r==0, or on successful
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
-_hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
-                              libxl__domain_build_state *state,
-                              libxl__spawner_starting *starting);
-_hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,
                                 uint32_t domid, char *state,
                                 libxl__spawn_starting *spawning,
@@ -1576,6 +1661,31 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
 
+/*----- Domain creation -----*/
+
+typedef struct libxl__domain_create_state libxl__domain_create_state;
+
+typedef void libxl__domain_create_cb(libxl__egc *egc,
+                                     libxl__domain_create_state*,
+                                     int rc, uint32_t domid);
+
+struct libxl__domain_create_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl_domain_config *guest_config;
+    int restore_fd;
+    libxl_console_ready console_cb;
+    void *console_cb_priv;
+    libxl__domain_create_cb *callback;
+    /* private to domain_create */
+    int guest_domid;
+    libxl__domain_build_state build_state;
+    libxl__stub_dm_spawn_state dmss;
+        /* If we're not doing stubdom, we use only dmss.dm,
+         * for the non-stubdom device model. */
+};
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 28f5cab..399359e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1695,8 +1695,8 @@ start:
 
     if ( restore_file ) {
         ret = libxl_domain_create_restore(ctx, &d_config,
-                                            cb, &child_console_pid,
-                                            &domid, restore_fd);
+                                          cb, &child_console_pid,
+                                          &domid, restore_fd, 0);
         /*
          * On subsequent reboot etc we should create the domain, not
          * restore/migrate-receive it again.
@@ -1704,7 +1704,7 @@ start:
         restore_file = NULL;
     }else{
         ret = libxl_domain_create_new(ctx, &d_config,
-                                        cb, &child_console_pid, &domid);
+                                      cb, &child_console_pid, &domid, 0);
     }
     if ( ret )
         goto error_out;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Za-00005x-Lh; Wed, 25 Apr 2012 15:56:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uf-Hr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.139.83:25165] by server-8.bemta-5.messagelabs.com id
	4A/10-26964-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10657 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007at-2Y; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qi-1m;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:34 +0100
Message-ID: <1335369353-13012-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/25] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e665d8d..4db0650 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -443,6 +443,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..1a4874c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) goto out;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zc-00007i-J3; Wed, 25 Apr 2012 15:56:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008UT-4W
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.143.99:48873] by server-2.bemta-4.messagelabs.com id
	4D/B5-17550-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335369360!24339614!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7445 invoked from network); 25 Apr 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007aj-QI; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QS-Nk;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:30 +0100
Message-ID: <1335369353-13012-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/25] libxl: support multiple libxl__ev_fds for
	the same fd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need a slightly more sophisticated data structure to allow this,
where we record the slot not just for each fd but also for each
(fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT.

Document the new relaxed restriction.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Fix typo
---
 tools/libxl/libxl_event.c    |   62 +++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   10 +++++--
 2 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5e1a207..149a4eb 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -635,10 +635,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
 
     /*
-     * In order to be able to efficiently find the libxl__ev_fd
-     * for a struct poll during _afterpoll, we maintain a shadow
-     * data structure in CTX->fd_beforepolled: each slot in
-     * the fds array corresponds to a slot in fd_beforepolled.
+     * In order to be able to efficiently find the libxl__ev_fd for a
+     * struct poll during _afterpoll, we maintain a shadow data
+     * structure in CTX->fd_rindices: each fd corresponds to a slot in
+     * fd_rindices, and each element in the rindices is three indices
+     * into the fd array (for POLLIN, POLLPRI and POLLOUT).
      */
 
     if (*nfds_io) {
@@ -659,14 +660,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         });
 
         /* make sure our array is as big as *nfds_io */
-        if (poller->fd_rindex_allocd < maxfd) {
-            assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
-            if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + poller->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
-            poller->fd_rindex = newarray;
-            poller->fd_rindex_allocd = maxfd;
+        if (poller->fd_rindices_allocd < maxfd) {
+            assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
+            poller->fd_rindices =
+                libxl__realloc(0, poller->fd_rindices,
+                               maxfd * sizeof(*poller->fd_rindices));
+            memset(poller->fd_rindices + poller->fd_rindices_allocd,
+                   0,
+                   (maxfd - poller->fd_rindices_allocd)
+                     * sizeof(*poller->fd_rindices));
+            poller->fd_rindices_allocd = maxfd;
         }
     }
 
@@ -677,8 +680,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             fds[used].fd = req_fd;
             fds[used].events = req_events;
             fds[used].revents = 0;
-            assert(req_fd < poller->fd_rindex_allocd);
-            poller->fd_rindex[req_fd] = used;
+            assert(req_fd < poller->fd_rindices_allocd);
+            if (req_events & POLLIN)  poller->fd_rindices[req_fd][0] = used;
+            if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used;
+            if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used;
         }
         used++;
     });
@@ -706,7 +711,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
             *timeout_upd = our_timeout;
     }
 
- out:
     return rc;
 }
 
@@ -728,24 +732,28 @@ static int afterpoll_check_fd(libxl__poller *poller,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= poller->fd_rindex_allocd)
+    if (fd >= poller->fd_rindices_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = poller->fd_rindex[fd];
+    int i, revents = 0;
+    for (i=0; i<3; i++) {
+        int slot = poller->fd_rindices[fd][i];
 
-    if (slot >= nfds)
-        /* stale slot entry; again, added afterwards */
-        return 0;
+        if (slot >= nfds)
+            /* stale slot entry; again, added afterwards */
+            continue;
 
-    if (fds[slot].fd != fd)
-        /* again, stale slot entry */
-        return 0;
+        if (fds[slot].fd != fd)
+            /* again, stale slot entry */
+            continue;
 
-    assert(!(fds[slot].revents & POLLNVAL));
+        assert(!(fds[slot].revents & POLLNVAL));
+        revents |= fds[slot].revents;
+    }
 
-    int revents = fds[slot].revents & (events | POLLERR | POLLHUP);
     /* we mask in case requested events have changed */
+    revents &= (events | POLLERR | POLLHUP);
 
     return revents;
 }
@@ -1009,7 +1017,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
-    p->fd_rindex = 0;
+    p->fd_rindices = 0;
 
     r = pipe(p->wakeup_pipe);
     if (r) {
@@ -1036,7 +1044,7 @@ void libxl__poller_dispose(libxl__poller *p)
     if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
     if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
     free(p->fd_polls);
-    free(p->fd_rindex);
+    free(p->fd_rindices);
 }
 
 libxl__poller *libxl__poller_get(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e8ea9a..2d99f29 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -131,7 +131,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
    * events; otherwise revents contains only bits in events.  Contrary
    * to the documentation for poll(2), POLLERR and POLLHUP can occur
    * even if only POLLIN was set in events.  (POLLNVAL is a fatal
-   * error and will cause libxl event machinery to fail an assertion.) */
+   * error and will cause libxl event machinery to fail an assertion.)
+   *
+   * It is not permitted to listen for the same or overlapping events
+   * on the same fd using multiple different libxl__ev_fd's.
+   */
 struct libxl__ev_fd {
     /* caller should include this in their own struct */
     /* read-only for caller, who may read only when registered: */
@@ -258,8 +262,8 @@ struct libxl__poller {
     struct pollfd *fd_polls;
     int fd_polls_allocd;
 
-    int fd_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    int fd_rindices_allocd;
+    int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */
 
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZX-0008VB-La; Wed, 25 Apr 2012 15:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZV-0008T0-8B
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:01 +0000
Received: from [85.158.138.51:31027] by server-4.bemta-3.messagelabs.com id
	BA/B2-15341-09E189F4; Wed, 25 Apr 2012 15:56:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335369359!23761184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8436 invoked from network); 25 Apr 2012 15:55:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZQ-0007ao-TX; Wed, 25 Apr 2012 15:55:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003QW-Q4;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:31 +0100
Message-ID: <1335369353-13012-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/25] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl.h          |    1 +
 tools/libxl/libxl_event.c    |   53 +++++++--
 tools/libxl/libxl_event.h    |  147 +++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  255 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   62 ++++++++++-
 6 files changed, 515 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9984d46..b6ff270 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index d59f0ee..fb90aed 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -380,6 +380,7 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_UNKNOWN_CHILD = -14,
 };
 
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 149a4eb..2f559d5 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -623,6 +623,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -762,10 +766,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -776,11 +781,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1078,16 +1088,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r == sizeof(buf)) continue;
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 2d2196f..713d96d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     A program which does this must call libxl_childproc_setmode.
+ *     There are two options:
+ * 
+ *     libxl_sigchld_owner_mainloop:
+ *       The application must install a SIGCHLD handler and reap (at
+ *       least) all of libxl's children and pass their exit status
+ *       to libxl by calling libxl_childproc_exited.
+ *
+ *     libxl_sigchld_owner_libxl_always:
+ *       The application expects libxl to reap all of its children,
+ *       and provides a callback to be notified of their exit
+ *       statues.
+ *
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_UNKNOWN_CHILD if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_UNKNOWN_CHILD.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index dce88ad..35c8bdd 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_UNKNOWN_CHILD;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc)
+{
+    /* May make callbacks into the application for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                rc = CTX->childproc_hooks->reaped_callback
+                        (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+                if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) {
+                    char disasterbuf[200];
+                    snprintf(disasterbuf, sizeof(disasterbuf), " reported by"
+                             " libxl_childproc_hooks->reaped_callback"
+                             " (for pid=%lu, status=%d; error code %d)",
+                             (unsigned long)pid, status, rc);
+                    LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0);
+                    return;
+                }
+            } else {
+                rc = ERROR_UNKNOWN_CHILD;
+            }
+            if (rc)
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2d99f29..e665d8d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -197,6 +197,19 @@ _hidden libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc,
                                                       int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -316,10 +329,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -567,6 +584,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon.  The child may not
+ * make any further calls to libxl infrastructure, except for memory
+ * allocation and logging.  If the child needs to use xenstore it
+ * must open its own xs handle and use it directly, rather than via
+ * the libxl event machinery.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  death may be NULL in which case
+ * the child is still reaped but its death is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -620,6 +667,15 @@ _hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 _hidden void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 _hidden int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zc-00007P-77; Wed, 25 Apr 2012 15:56:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZY-0008Uw-0Y
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:04 +0000
Received: from [85.158.139.83:25248] by server-3.bemta-5.messagelabs.com id
	D4/7F-25237-39E189F4; Wed, 25 Apr 2012 15:56:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10702 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137134"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b9-Dd; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003R9-BP;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:40 +0100
Message-ID: <1335369353-13012-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/25] libxl: make libxl_create_logfile
	const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 19b4615..f0d94c6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
     return 0;
 }
 
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name)
 {
     GC_INIT(ctx);
     struct stat stat_buf;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index ca53a8a..2b47622 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
-int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
+int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
 int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend);
 
 int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZU-0008TR-VB; Wed, 25 Apr 2012 15:56:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZT-0008Sz-Lv
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:55:59 +0000
Received: from [85.158.138.51:30846] by server-3.bemta-3.messagelabs.com id
	79/5F-04048-E8E189F4; Wed, 25 Apr 2012 15:55:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18971 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bI-KE; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RH-Gk;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:42 +0100
Message-ID: <1335369353-13012-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/25] libxl: Allow AO_GC and EGC_GC even if not
	used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mark the gc produced by AO_GC and EGC_GC with the gcc feature
__attribute__((unused)).  This allows the use of EGC_INIT and
STATE_AO_GC by functions which do actually use the gc.

This is convenient because those functions might want to use the ao or
egc, rather than the gc; and also because it means that functions
which morally ought to be fishing any gc they use out of an egc or
state structure can be written do so regardless of whether the gc is
actually used right then.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4610f01..a5b8681 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1282,7 +1282,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 /* useful for all functions which take an egc: */
 
 #define EGC_GC                                  \
-    libxl__gc *const gc = &egc->gc
+    libxl__gc *const gc __attribute__((unused)) = &egc->gc
 
 /* egc initialisation and destruction: */
 
@@ -1385,7 +1385,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     })
 
 #define AO_GC                                   \
-    libxl__gc *const gc = &ao->gc
+    libxl__gc *const gc __attribute__((unused)) = &ao->gc
 
 #define STATE_AO_GC(op_ao)                      \
     libxl__ao *const ao = (op_ao);              \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Za-00005x-Lh; Wed, 25 Apr 2012 15:56:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZX-0008Uf-Hr
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:03 +0000
Received: from [85.158.139.83:25165] by server-8.bemta-5.messagelabs.com id
	4A/10-26964-29E189F4; Wed, 25 Apr 2012 15:56:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335369361!25467407!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10657 invoked from network); 25 Apr 2012 15:56:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007at-2Y; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Qi-1m;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:34 +0100
Message-ID: <1335369353-13012-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/25] libxl: provide libxl__remove_file et al.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These utility functions cope with EINTR AND ENOENT, do error logging,
and we provide a recursive version to delete whole directory trees.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    7 ++++
 tools/libxl/libxl_utils.c    |   79 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e665d8d..4db0650 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -443,6 +443,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
  * string. (similar to a gc'd dirname(3)). */
 _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
+/* Each of these logs errors and returns a libxl error code.
+ * They do not mind if path is already removed.
+ * For _file, path must not be a directory; for _directory it must be. */
+_hidden int libxl__remove_file(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
+_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 0cbd85e..1a4874c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename,
 READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
+int libxl__remove_file(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = unlink(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove file %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_file_or_directory(libxl__gc *gc, const char *path)
+{
+    for (;;) {
+        int r = rmdir(path);
+        if (!r) return 0;
+        if (errno == ENOENT) return 0;
+        if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path);
+        if (errno == ENOTDIR) return libxl__remove_file(gc, path);
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove %s", path);
+        return ERROR_FAIL;
+     }
+}
+
+int libxl__remove_directory(libxl__gc *gc, const char *dirpath)
+{
+    int rc = 0;
+    DIR *d = 0;
+
+    d = opendir(dirpath);
+    if (!d) {
+        if (errno == ENOENT)
+            goto out;
+
+        LOGE(ERROR, "failed to opendir %s for removal", dirpath);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    size_t need = offsetof(struct dirent, d_name) +
+        pathconf(dirpath, _PC_NAME_MAX) + 1;
+    struct dirent *de_buf = libxl__zalloc(gc, need);
+    struct dirent *de;
+
+    for (;;) {
+        int r = readdir_r(d, de_buf, &de);
+        if (r) {
+            LOGE(ERROR, "failed to readdir %s for removal", dirpath);
+            rc = ERROR_FAIL;
+            break;
+        }
+        if (!de)
+            break;
+
+        if (!strcmp(de->d_name, ".") ||
+            !strcmp(de->d_name, ".."))
+            continue;
+
+        const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name);
+        if (libxl__remove_file_or_directory(gc, subpath))
+            rc = ERROR_FAIL;
+    }
+
+    for (;;) {
+        int r = rmdir(dirpath);
+        if (!r) break;
+        if (errno == ENOENT) goto out;
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to remove emptied directory %s", dirpath);
+        rc = ERROR_FAIL;
+    }
+
+ out:
+    if (d) closedir(d);
+
+    return rc;
+}
 
 pid_t libxl_fork(libxl_ctx *ctx)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4ZU-0008TR-VB; Wed, 25 Apr 2012 15:56:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4ZT-0008Sz-Lv
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:55:59 +0000
Received: from [85.158.138.51:30846] by server-3.bemta-3.messagelabs.com id
	79/5F-04048-E8E189F4; Wed, 25 Apr 2012 15:55:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335369357!23792183!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18971 invoked from network); 25 Apr 2012 15:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:55:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bI-KE; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RH-Gk;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 25 Apr 2012 16:55:42 +0100
Message-ID: <1335369353-13012-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/25] libxl: Allow AO_GC and EGC_GC even if not
	used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mark the gc produced by AO_GC and EGC_GC with the gcc feature
__attribute__((unused)).  This allows the use of EGC_INIT and
STATE_AO_GC by functions which do actually use the gc.

This is convenient because those functions might want to use the ao or
egc, rather than the gc; and also because it means that functions
which morally ought to be fishing any gc they use out of an egc or
state structure can be written do so regardless of whether the gc is
actually used right then.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4610f01..a5b8681 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1282,7 +1282,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 /* useful for all functions which take an egc: */
 
 #define EGC_GC                                  \
-    libxl__gc *const gc = &egc->gc
+    libxl__gc *const gc __attribute__((unused)) = &egc->gc
 
 /* egc initialisation and destruction: */
 
@@ -1385,7 +1385,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     })
 
 #define AO_GC                                   \
-    libxl__gc *const gc = &ao->gc
+    libxl__gc *const gc __attribute__((unused)) = &ao->gc
 
 #define STATE_AO_GC(op_ao)                      \
     libxl__ao *const ao = (op_ao);              \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zj-0000Jv-LN; Wed, 25 Apr 2012 15:56:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4Zf-00009K-At
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:12 +0000
Received: from [193.109.254.147:51904] by server-3.bemta-14.messagelabs.com id
	C9/7C-23274-99E189F4; Wed, 25 Apr 2012 15:56:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335369363!1112892!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20927 invoked from network); 25 Apr 2012 15:56:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007ar-0K; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003Qa-TT;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:32 +0100
Message-ID: <1335369353-13012-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] =?utf-8?q?=5BPATCH_04/25=5D_autoconf=3A_trim_the_conf?=
	=?utf-8?q?igure_script=3B_use_autoheader?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVtb3ZlIGEgbG90IG9mIHVubmVjZXNzYXJ5IHRlc3RzLiAgU3BlY2lmaWNhbGx5LCB3ZSBubyBs
b25nZXIgdGVzdApmb3Igc3RhbmRhcmQgUE9TSVggZmFjaWxpdGllcyB3aGljaCB3ZSBleHBlY3Qg
dG8gYmUgcHJvdmlkZWQKZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNhc2Ug
aGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgoKU3dpdGNoIHRvIGdlbmVyYXRpbmcgY29uZmlnLmgu
aW4gd2l0aCBhdXRvaGVhZGVyLgoKU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNr
c29uQGV1LmNpdHJpeC5jb20+CkNjOiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51
cGMuZWR1PgoKQ2hhbmdlcyBzaW5jZSB2NzoKICogUmVtb3ZlZCBBWF9DSEVDS19QVFlGVU5DUyAo
c251Y2sgaW4gZnJvbSBwcmV2aW91cyBwYXRjaCkKLS0tCiBhdXRvZ2VuLnNoICAgICAgICAgfCAg
ICAxICsKIHRvb2xzL2NvbmZpZy5oLmluICB8ICAgNzMgKy0KIHRvb2xzL2NvbmZpZ3VyZSAgICB8
IDg4MjUgKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogdG9vbHMvY29uZmlndXJlLmFjIHwgICA2MCArLQogNCBmaWxlcyBjaGFuZ2VkLCAyOTgxIGlu
c2VydGlvbnMoKyksIDU5NzggZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXV0b2dlbi5zaCBi
L2F1dG9nZW4uc2gKaW5kZXggYzI4OGI3MS4uNThhNzFjZSAxMDA3NTUKLS0tIGEvYXV0b2dlbi5z
aAorKysgYi9hdXRvZ2VuLnNoCkBAIC0xLDMgKzEsNCBAQAogIyEvYmluL3NoIC1lCiBjZCB0b29s
cwogYXV0b2NvbmYKK2F1dG9oZWFkZXIKZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbmZpZy5oLmluIGIv
dG9vbHMvY29uZmlnLmguaW4KaW5kZXggZjhmOTZkYy4uMTdjODkxMyAxMDA2NDQKLS0tIGEvdG9v
bHMvY29uZmlnLmguaW4KKysrIGIvdG9vbHMvY29uZmlnLmguaW4KQEAgLTEsMTkgKzEsNjQgQEAK
LS8qCi0gKiBDb3B5cmlnaHQgKEMpIDIwMTIKLSAqCi0gKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQotICogaXQgdW5k
ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMg
cHVibGlzaGVkCi0gKiBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyB2ZXJzaW9uIDIu
MSBvbmx5LiB3aXRoIHRoZSBzcGVjaWFsCi0gKiBleGNlcHRpb24gb24gbGlua2luZyBkZXNjcmli
ZWQgaW4gZmlsZSBMSUNFTlNFLgotICoKLSAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBp
biB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAotICogYnV0IFdJVEhPVVQgQU5ZIFdB
UlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKLSAqIE1FUkNIQU5U
QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKLSAq
IEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgotICov
CisvKiBjb25maWcuaC5pbi4gIEdlbmVyYXRlZCBmcm9tIGNvbmZpZ3VyZS5hYyBieSBhdXRvaGVh
ZGVyLiAgKi8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0lOVFRZUEVTX0gKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIGBjcnlwdG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KKyN1bmRlZiBI
QVZFX0xJQkNSWVBUTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHlhamwnIGxp
YnJhcnkgKC1seWFqbCkuICovCisjdW5kZWYgSEFWRV9MSUJZQUpMCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgeicgbGlicmFyeSAoLWx6KS4gKi8KKyN1bmRlZiBIQVZFX0xJQloK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxtZW1vcnkuaD4gaGVhZGVyIGZpbGUu
ICovCisjdW5kZWYgSEFWRV9NRU1PUllfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN0ZGludC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURElOVF9ICisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkbGliLmg+IGhlYWRlciBmaWxlLiAqLwor
I3VuZGVmIEhBVkVfU1RETElCX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxz
dHJpbmdzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1RSSU5HU19ICisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5nLmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfU1RSSU5HX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMv
c3RhdC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19TVEFUX0gKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvdHlwZXMuaD4gaGVhZGVyIGZpbGUuICovCisj
dW5kZWYgSEFWRV9TWVNfVFlQRVNfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
PHVuaXN0ZC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1VOSVNURF9ICiAKIC8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4gaGVhZGVyIGZp
bGUuICovCiAjdW5kZWYgSEFWRV9ZQUpMX1lBSkxfVkVSU0lPTl9ICiAKLS8qIERlZmluZSBjdXJz
ZXMgaGVhZGVyIHRvIGluY2x1ZGUuICovCisvKiBEZWZpbmUgY3Vyc2VzIGhlYWRlciB0byB1c2Ug
Ki8KICN1bmRlZiBJTkNMVURFX0NVUlNFU19ICisKKy8qIERlZmluZSB0byB0aGUgYWRkcmVzcyB3
aGVyZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLworI3Vu
ZGVmIFBBQ0tBR0VfQlVHUkVQT1JUCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1lIG9mIHRo
aXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX05BTUUKKworLyogRGVmaW5lIHRvIHRoZSBm
dWxsIG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0Vf
U1RSSU5HCisKKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBzaG9ydCBuYW1lIG9mIHRoaXMg
cGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1RBUk5BTUUKKworLyogRGVmaW5lIHRvIHRoZSBo
b21lIHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1VSTAorCisvKiBE
ZWZpbmUgdG8gdGhlIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0Vf
VkVSU0lPTgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgQU5TSSBDIGhlYWRlciBm
aWxlcy4gKi8KKyN1bmRlZiBTVERDX0hFQURFUlMKZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbmZpZ3Vy
ZSBiL3Rvb2xzL2NvbmZpZ3VyZQppbmRleCA4OTdlMDYxLi5kODkxOGZlIDEwMDc1NQotLS0gYS90
b29scy9jb25maWd1cmUKKysrIGIvdG9vbHMvY29uZmlndXJlCkBAIC01OTUsMTIgKzU5NSw4IEBA
IGFjX2luY2x1ZGVzX2RlZmF1bHQ9IlwKICMgaW5jbHVkZSA8dW5pc3RkLmg+CiAjZW5kaWYiCiAK
LWFjX2hlYWRlcl9saXN0PQotYWNfZnVuY19saXN0PQogYWNfc3Vic3RfdmFycz0nTFRMSUJPQkpT
Ci1QT1dfTElCCiBMSUJPQkpTCi1BTExPQ0EKIGxpYmljb252CiBQVEhSRUFEX0xJQlMKIFBUSFJF
QURfTERGTEFHUwpAQCAtNjE2LDYgKzYxMiw5IEBAIFBLR19DT05GSUdfTElCRElSCiBQS0dfQ09O
RklHX1BBVEgKIFBLR19DT05GSUcKIENVUlNFU19MSUJTCitFR1JFUAorR1JFUAorQ1BQCiBweWNv
bmZpZwogUFlUSE9OUEFUSAogT0NBTUxCVUlMRApAQCAtNjM1LDggKzYzNCwxMyBAQCBJTlNUQUxM
X0RBVEEKIElOU1RBTExfU0NSSVBUCiBJTlNUQUxMX1BST0dSQU0KIFNFVF9NQUtFCi1MTl9TCi1T
RUQKK09CSkVYVAorRVhFRVhUCithY19jdF9DQworQ1BQRkxBR1MKK0xERkxBR1MKK0NGTEFHUwor
Q0MKIElBU0wKIEJDQwogTEQ4NgpAQCAtNjY1LDI0ICs2NjksNiBAQCB4ZW5hcGkKIHZ0cG0KIG1v
bml0b3JzCiBnaXRodHRwCi1ob3N0X29zCi1ob3N0X3ZlbmRvcgotaG9zdF9jcHUKLWhvc3QKLWJ1
aWxkX29zCi1idWlsZF92ZW5kb3IKLWJ1aWxkX2NwdQotYnVpbGQKLUVHUkVQCi1HUkVQCi1DUFAK
LU9CSkVYVAotRVhFRVhUCi1hY19jdF9DQwotQ1BQRkxBR1MKLUxERkxBR1MKLUNGTEFHUwotQ0MK
IHRhcmdldF9hbGlhcwogaG9zdF9hbGlhcwogYnVpbGRfYWxpYXMKQEAgLTc0MCwxMiArNzI2LDYg
QEAgZW5hYmxlX2RlYnVnCiAgICAgICBhY19wcmVjaW91c192YXJzPSdidWlsZF9hbGlhcwogaG9z
dF9hbGlhcwogdGFyZ2V0X2FsaWFzCi1DQwotQ0ZMQUdTCi1MREZMQUdTCi1MSUJTCi1DUFBGTEFH
UwotQ1BQCiBQUkVQRU5EX0lOQ0xVREVTCiBQUkVQRU5EX0xJQgogQVBQRU5EX0lOQ0xVREVTCkBA
IC03NjIsNiArNzQyLDEyIEBAIEFTODYKIExEODYKIEJDQwogSUFTTAorQ0MKK0NGTEFHUworTERG
TEFHUworTElCUworQ1BQRkxBR1MKK0NQUAogUEtHX0NPTkZJRwogUEtHX0NPTkZJR19QQVRICiBQ
S0dfQ09ORklHX0xJQkRJUgpAQCAtMTM2NSwxMCArMTM1MSw2IEBAIEZpbmUgdHVuaW5nIG9mIHRo
ZSBpbnN0YWxsYXRpb24gZGlyZWN0b3JpZXM6CiBfQUNFT0YKIAogICBjYXQgPDxcX0FDRU9GCi0K
LVN5c3RlbSB0eXBlczoKLSAgLS1idWlsZD1CVUlMRCAgICAgY29uZmlndXJlIGZvciBidWlsZGlu
ZyBvbiBCVUlMRCBbZ3Vlc3NlZF0KLSAgLS1ob3N0PUhPU1QgICAgICAgY3Jvc3MtY29tcGlsZSB0
byBidWlsZCBwcm9ncmFtcyB0byBydW4gb24gSE9TVCBbQlVJTERdCiBfQUNFT0YKIGZpCiAKQEAg
LTEzOTksMTQgKzEzODEsNiBAQCBPcHRpb25hbCBGZWF0dXJlczoKICAgLS1kaXNhYmxlLWRlYnVn
ICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiB0b29scyAoZGVmYXVsdCBpcyBFTkFCTEVE
KQogCiBTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoKLSAgQ0MgICAgICAg
ICAgQyBjb21waWxlciBjb21tYW5kCi0gIENGTEFHUyAgICAgIEMgY29tcGlsZXIgZmxhZ3MKLSAg
TERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxp
YnJhcmllcyBpbiBhCi0gICAgICAgICAgICAgIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8bGliIGRp
cj4KLSAgTElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8gdGhlIGxpbmtlciwgZS5nLiAt
bDxsaWJyYXJ5PgotICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3Ig
ZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCi0gICAgICAgICAgICAgIHlvdSBoYXZlIGhl
YWRlcnMgaW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1ZGUgZGlyPgotICBDUFAgICAg
ICAgICBDIHByZXByb2Nlc3NvcgogICBQUkVQRU5EX0lOQ0xVREVTCiAgICAgICAgICAgICAgIExp
c3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQog
ICBQUkVQRU5EX0xJQiBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxB
R1MgKHdpdGhvdXQgLUwpCkBAIC0xNDI1LDYgKzEzOTksMTQgQEAgU29tZSBpbmZsdWVudGlhbCBl
bnZpcm9ubWVudCB2YXJpYWJsZXM6CiAgIExEODYgICAgICAgIFBhdGggdG8gbGQ4NiB0b29sCiAg
IEJDQyAgICAgICAgIFBhdGggdG8gYmNjIHRvb2wKICAgSUFTTCAgICAgICAgUGF0aCB0byBpYXNs
IHRvb2wKKyAgQ0MgICAgICAgICAgQyBjb21waWxlciBjb21tYW5kCisgIENGTEFHUyAgICAgIEMg
Y29tcGlsZXIgZmxhZ3MKKyAgTERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBk
aXI+IGlmIHlvdSBoYXZlIGxpYnJhcmllcyBpbiBhCisgICAgICAgICAgICAgIG5vbnN0YW5kYXJk
IGRpcmVjdG9yeSA8bGliIGRpcj4KKyAgTElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8g
dGhlIGxpbmtlciwgZS5nLiAtbDxsaWJyYXJ5PgorICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBD
L0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCisgICAgICAg
ICAgICAgIHlvdSBoYXZlIGhlYWRlcnMgaW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1
ZGUgZGlyPgorICBDUFAgICAgICAgICBDIHByZXByb2Nlc3NvcgogICBQS0dfQ09ORklHICBwYXRo
IHRvIHBrZy1jb25maWcgdXRpbGl0eQogICBQS0dfQ09ORklHX1BBVEgKICAgICAgICAgICAgICAg
ZGlyZWN0b3JpZXMgdG8gYWRkIHRvIHBrZy1jb25maWcncyBzZWFyY2ggcGF0aApAQCAtMTc5Nywz
MTEgKzE3NzksNiBAQCBmaQogICBhc19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKIAogfSAjIGFj
X2ZuX2NfdHJ5X2xpbmsKLQotIyBhY19mbl9jX2NoZWNrX2Z1bmMgTElORU5PIEZVTkMgVkFSCi0j
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgVGVzdHMgd2hldGhlciBGVU5D
IGV4aXN0cywgc2V0dGluZyB0aGUgY2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5Ci1hY19m
bl9jX2NoZWNrX2Z1bmMgKCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xp
bmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHsk
MytzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVs
c2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k
IGNvbmZkZWZzLmguICAqLwotLyogRGVmaW5lICQyIHRvIGFuIGlubm9jdW91cyB2YXJpYW50LCBp
biBjYXNlIDxsaW1pdHMuaD4gZGVjbGFyZXMgJDIuCi0gICBGb3IgZXhhbXBsZSwgSFAtVVggMTFp
IDxsaW1pdHMuaD4gZGVjbGFyZXMgZ2V0dGltZW9mZGF5LiAgKi8KLSNkZWZpbmUgJDIgaW5ub2N1
b3VzXyQyCi0KLS8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhv
cGVmdWxseSBmZXcgcHJvdG90eXBlcywKLSAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFy
ICQyICgpOyBiZWxvdy4KLSAgICBQcmVmZXIgPGxpbWl0cy5oPiB0byA8YXNzZXJ0Lmg+IGlmIF9f
U1REQ19fIGlzIGRlZmluZWQsIHNpbmNlCi0gICAgPGxpbWl0cy5oPiBleGlzdHMgZXZlbiBvbiBm
cmVlc3RhbmRpbmcgY29tcGlsZXJzLiAgKi8KLQotI2lmZGVmIF9fU1REQ19fCi0jIGluY2x1ZGUg
PGxpbWl0cy5oPgotI2Vsc2UKLSMgaW5jbHVkZSA8YXNzZXJ0Lmg+Ci0jZW5kaWYKLQotI3VuZGVm
ICQyCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu
IGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0
eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUg
d291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0j
ZW5kaWYKLWNoYXIgJDIgKCk7Ci0vKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9y
IGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzCi0gICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBF
Tk9TWVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQKLSAgICBzb21ldGhpbmcg
c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8KLSNp
ZiBkZWZpbmVkIF9fc3R1Yl8kMiB8fCBkZWZpbmVkIF9fc3R1Yl9fXyQyCi1jaG9rZSBtZQotI2Vu
ZGlmCi0KLWludAotbWFpbiAoKQotewotcmV0dXJuICQyICgpOwotICA7Ci0gIHJldHVybiAwOwot
fQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGV2YWwg
IiQzPXllcyIKLWVsc2UKLSAgZXZhbCAiJDM9bm8iCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0
LiRhY19leHQKLWZpCi1ldmFsIGFjX3Jlcz1cJCQzCi0JICAgICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19lY2hvICIk
YWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVu
b19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KLQotfSAjIGFj
X2ZuX2NfY2hlY2tfZnVuYwotCi0jIGFjX2ZuX2NfY2hlY2tfdHlwZSBMSU5FTk8gVFlQRSBWQVIg
SU5DTFVERVMKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQot
IyBUZXN0cyB3aGV0aGVyIFRZUEUgZXhpc3RzIGFmdGVyIGhhdmluZyBpbmNsdWRlZCBJTkNMVURF
Uywgc2V0dGluZyBjYWNoZQotIyB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCi1hY19mbl9jX2No
ZWNrX3R5cGUgKCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19z
dGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHskMytzZXR9
XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAg
ZXZhbCAiJDM9bm8iCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ0Ci1pbnQKLW1haW4gKCkKLXsKLWlmIChzaXpl
b2YgKCQyKSkKLQkgcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJDQKLWlu
dAotbWFpbiAoKQotewotaWYgKHNpemVvZiAoKCQyKSkpCi0JICAgIHJldHVybiAwOwotICA7Ci0g
IHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0KLWVsc2UKLSAgZXZhbCAiJDM9eWVzIgotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLWV2
YWwgYWNfcmVzPVwkJDMKLQkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQot
ICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYg
eyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQotCi19ICMgYWNfZm5fY19jaGVja190eXBl
Ci0KLSMgYWNfZm5fY19maW5kX2ludFhfdCBMSU5FTk8gQklUUyBWQVIKLSMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgRmluZHMgYSBzaWduZWQgaW50ZWdlciB0eXBlIHdp
dGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIKLSMgYWNjb3JkaW5nbHku
Ci1hY19mbl9jX2ZpbmRfaW50WF90ICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEi
fSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW50JDJf
dCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgaW50JDJfdC4uLiAiID4mNjsgfQotaWYg
ZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgotZWxzZQotICBldmFsICIkMz1ubyIKLSAgICAgIyBPcmRlciBpcyBpbXBv
cnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCi0g
ICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCi0gICAgIGZvciBh
Y190eXBlIGluIGludCQyX3QgJ2ludCcgJ2xvbmcgaW50JyBcCi0JICdsb25nIGxvbmcgaW50JyAn
c2hvcnQgaW50JyAnc2lnbmVkIGNoYXInOyBkbwotICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNs
dWRlc19kZWZhdWx0Ci0JICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKLWludAotbWFpbiAo
KQotewotc3RhdGljIGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoMCA8ICgkYWNfdHlwZSkgKCgo
KCgkYWNfdHlwZSkgMSA8PCBOKSA8PCBOKSAtIDEpICogMiArIDEpKV07Ci10ZXN0X2FycmF5IFsw
XSA9IDAKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0
Ci0JICAgICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKLWludAotbWFpbiAoKQotewotc3Rh
dGljIGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAx
IDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkKLQkJIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBl
KSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMikpXTsKLXRlc3RfYXJyYXkgWzBdID0gMAotCi0g
IDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKLQotZWxzZQotICBjYXNlICRhY190eXBlIGluICMoCi0gIGludCQyX3QpIDoK
LSAgICBldmFsICIkMz15ZXMiIDs7ICMoCi0gICopIDoKLSAgICBldmFsICIkMz1cJGFjX3R5cGUi
IDs7Ci1lc2FjCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQz
IlwiID0geCJubyI7IHRoZW4gOgotCi1lbHNlCi0gIGJyZWFrCi1maQotICAgICBkb25lCi1maQot
ZXZhbCBhY19yZXM9XCQkMwotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9
Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAm
JiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2ZpbmRfaW50
WF90Ci0KLSMgYWNfZm5fY19jaGVja19tZW1iZXIgTElORU5PIEFHR1IgTUVNQkVSIFZBUiBJTkNM
VURFUwotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tCi0jIFRyaWVzIHRvIGZpbmQgaWYgdGhlIGZpZWxkIE1FTUJFUiBleGlzdHMgaW4gdHlwZSBB
R0dSLCBhZnRlciBpbmNsdWRpbmcKLSMgSU5DTFVERVMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUg
VkFSIGFjY29yZGluZ2x5LgotYWNfZm5fY19jaGVja19tZW1iZXIgKCkKLXsKLSAgYXNfbGluZW5v
PSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xp
bmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkMi4kMyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuJDMuLi4g
IiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHskNCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJDUKLWludAot
bWFpbiAoKQotewotc3RhdGljICQyIGFjX2FnZ3I7Ci1pZiAoYWNfYWdnci4kMykKLXJldHVybiAw
OwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIk
TElORU5PIjsgdGhlbiA6Ci0gIGV2YWwgIiQ0PXllcyIKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJDUK
LWludAotbWFpbiAoKQotewotc3RhdGljICQyIGFjX2FnZ3I7Ci1pZiAoc2l6ZW9mIGFjX2FnZ3Iu
JDMpCi1yZXR1cm4gMDsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBldmFsICIkND15ZXMiCi1lbHNlCi0gIGV2
YWwgIiQ0PW5vIgotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLWV2YWwgYWNfcmVzPVwkJDQKLQkgICAg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19y
ZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFsICRhc19saW5lbm9fc3Rh
Y2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBh
c19saW5lbm87fQotCi19ICMgYWNfZm5fY19jaGVja19tZW1iZXIKLQotIyBhY19mbl9jX2ZpbmRf
dWludFhfdCBMSU5FTk8gQklUUyBWQVIKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCi0jIEZpbmRzIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRoIEJJVFMs
IHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSCi0jIGFjY29yZGluZ2x5LgotYWNfZm5fY19maW5k
X3VpbnRYX3QgKCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19z
dGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgdWludCQyX3QuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3Qg
XCJcJHskMytzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKLWVsc2UKLSAgZXZhbCAiJDM9bm8iCi0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2
ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgotICAgICAjIHRoYW4g
aGFsZiBvZiB0aGUgZXhwZWN0ZWQgdGFyZ2V0IHdpZHRoLgotICAgICBmb3IgYWNfdHlwZSBpbiB1
aW50JDJfdCAndW5zaWduZWQgaW50JyAndW5zaWduZWQgbG9uZyBpbnQnIFwKLQkgJ3Vuc2lnbmVk
IGxvbmcgbG9uZyBpbnQnICd1bnNpZ25lZCBzaG9ydCBpbnQnICd1bnNpZ25lZCBjaGFyJzsgZG8K
LSAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBl
bmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAotaW50Ci1tYWluICgpCi17
Ci1zdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgoKCRhY190eXBlKSAtMSA+PiAoJDIg
LyAyIC0gMSkpID4+ICgkMiAvIDIgLSAxKSA9PSAzKV07Ci10ZXN0X2FycmF5IFswXSA9IDAKLQot
ICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Ci0gIGNhc2UgJGFjX3R5cGUgaW4gIygKLSAgdWludCQyX3QpIDoKLSAgICBl
dmFsICIkMz15ZXMiIDs7ICMoCi0gICopIDoKLSAgICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Ci1l
c2FjCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25m
dGVzdC4kYWNfZXh0Ci0gICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQzIlwiID0geCJubyI7IHRo
ZW4gOgotCi1lbHNlCi0gIGJyZWFrCi1maQotICAgICBkb25lCi1maQotZXZhbCBhY19yZXM9XCQk
MwotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Ci0gIGV2YWwgJGFzX2xp
bmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07
IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2ZpbmRfdWludFhfdAogY2F0ID5jb25m
aWcubG9nIDw8X0FDRU9GCiBUaGlzIGZpbGUgY29udGFpbnMgYW55IG1lc3NhZ2VzIHByb2R1Y2Vk
IGJ5IGNvbXBpbGVycyB3aGlsZQogcnVubmluZyBjb25maWd1cmUsIHRvIGFpZCBkZWJ1Z2dpbmcg
aWYgY29uZmlndXJlIG1ha2VzIGEgbWlzdGFrZS4KQEAgLTIzODYsMTEgKzIwNjMsNiBAQCAkYXNf
ZWNobyAiJGFzX21lOiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KICAgPiRjYWNo
ZV9maWxlCiBmaQogCi1hc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvdGltZS5oIgot
YXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCi1hc19mbl9hcHBlbmQgYWNf
ZnVuY19saXN0ICIgYWxhcm0iCi1hc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzdGRsaWIu
aCIKLWFzX2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgogIyBDaGVjayB0
aGF0IHRoZSBwcmVjaW91cyB2YXJpYWJsZXMgc2F2ZWQgaW4gdGhlIGNhY2hlIGhhdmUga2VwdCB0
aGUgc2FtZQogIyB2YWx1ZS4KIGFjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQpAQCAtMjUwOCwxNzMw
ICsyMTgwLDQwIEBAIEFQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBpbnN0ZWFkIHdoZW4g
cG9zc2libGUuIiA+JjI7fQogCiBmaQogCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFH
UycKLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0
ID4mNScKLWFjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxB
R1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9
JGFjX2N2X2NfY29tcGlsZXJfZ251Ci1pZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVu
Ci0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1nY2MiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9v
bF9wcmVmaXh9Z2NjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlm
IHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2Nj
IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAg
ZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0k
YXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotCi1maQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2df
Q0MiOyB0aGVuCi0gIGFjX2N0X0NDPSRDQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
ImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
Z2NjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9
IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRl
c3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0ND
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0k
YXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
ImdjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25l
Ci0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJv
Z19hY19jdF9DQwotaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKLSRhc19l
Y2hvICIkYWNfY3RfQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZp
Ci0KLSAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIKLSAgZWxzZQot
ICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBDQz0kYWNfY3Rf
Q0MKLSAgZmkKLWVsc2UKLSAgQ0M9IiRhY19jdl9wcm9nX0NDIgotZmkKLQotaWYgdGVzdCAteiAi
JENDIjsgdGhlbgotICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
LSAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9v
bF9wcmVmaXh9Y2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIK
LSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRv
bmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVz
dCAtbiAiJENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFz
X2VjaG8gIm5vIiA+JjY7IH0KLWZpCi0KLQotICBmaQotZmkKLWlmIHRlc3QgLXogIiRDQyI7IHRo
ZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9n
X0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotICBhY19w
cm9nX3JlamVjdGVkPW5vCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1m
b3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KLSAgICBpZiB0ZXN0ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA9ICIvdXNy
L3VjYi9jYyI7IHRoZW4KLSAgICAgICBhY19wcm9nX3JlamVjdGVkPXllcwotICAgICAgIGNvbnRp
bnVlCi0gICAgIGZpCi0gICAgYWNfY3ZfcHJvZ19DQz0iY2MiCi0gICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZT
Ci0KLWlmIHRlc3QgJGFjX3Byb2dfcmVqZWN0ZWQgPSB5ZXM7IHRoZW4KLSAgIyBXZSBmb3VuZCBh
IGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0LgotICBzZXQg
ZHVtbXkgJGFjX2N2X3Byb2dfQ0MKLSAgc2hpZnQKLSAgaWYgdGVzdCAkIyAhPSAwOyB0aGVuCi0g
ICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVudCBjb21waWxlciBmcm9tIHRoZSBib2d1cyBvbmUuCi0g
ICAgIyBIb3dldmVyLCBpdCBoYXMgdGhlIHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxs
IGJlIGNob3NlbgotICAgICMgZmlyc3QgaWYgd2Ugc2V0IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1l
OyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgotICAgIHNoaWZ0Ci0gICAgYWNfY3ZfcHJvZ19DQz0i
JGFzX2Rpci8kYWNfd29yZCR7MSsnICd9JEAiCi0gIGZpCi1maQotZmkKLWZpCi1DQz0kYWNfY3Zf
cHJvZ19DQwotaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsg
fQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCi0KLQotZmkKLWlmIHRlc3QgLXog
IiRDQyI7IHRoZW4KLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICBmb3Ig
YWNfcHJvZyBpbiBjbC5leGUKLSAgZG8KLSAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
IiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KLXNldCBkdW1teSAkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgot
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFj
X2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNl
Ci1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQ
QVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19j
dl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIKLSAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMK
LQotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUK
LSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZp
Ci0KLQotICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKLSAgZG9uZQotZmkKLWlmIHRlc3QgLXog
IiRDQyI7IHRoZW4KLSAgYWNfY3RfQ0M9JENDCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotZG8K
LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJGFjX3Byb2c7IGFjX3dvcmQ9JDIK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X0ND
IjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX3Byb2ciCi0gICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCi0KLWZpCi1maQotYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MK
LWlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0
X0NDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0KLSAgdGVz
dCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhawotZG9uZQotCi0gIGlmIHRlc3QgIngkYWNfY3RfQ0Mi
ID0geDsgdGhlbgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6
JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3Mg
dG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJu
ZWQ9eWVzIDs7Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0gIGZpCi1maQotCi1maQotCi0KLXRl
c3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBp
bGVyIGZvdW5kIGluIFwkUEFUSAotU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIg
IiRMSU5FTk8iIDUgOyB9Ci0KLSMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBj
b21waWxlci4KLSRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQotc2V0IFggJGFjX2NvbXBpbGUKLWFjX2NvbXBp
bGVyPSQyCi1mb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCi0g
IHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKLWNhc2UgIigoJGFjX3Ry
eSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICop
IGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5
X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5j
b25mdGVzdC5lcnIKLSAgYWNfc3RhdHVzPSQ/Ci0gIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0
aGVuCi0gICAgc2VkICcxMGFcCi0uLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4u
Ci0gICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCi0gICAgY2F0IGNvbmZ0
ZXN0LmVyMSA+JjUKLSAgZmkKLSAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgotICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQotZG9uZQotCi1jYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAot
bWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWFjX2NsZWFuX2ZpbGVz
X3NhdmU9JGFjX2NsZWFuX2ZpbGVzCi1hY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGEu
b3V0IGEub3V0LmRTWU0gYS5leGUgYi5vdXQiCi0jIFRyeSB0byBjcmVhdGUgYW4gZXhlY3V0YWJs
ZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNyZWdhcmQgYS5vdXQuCi0jIEl0IHdpbGwgaGVscCB1cyBk
aWFnbm9zZSBicm9rZW4gY29tcGlsZXJzLCBhbmQgZmluZGluZyBvdXQgYW4gaW50dWl0aW9uCi0j
IG9mIGV4ZWV4dC4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3JrcyIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzLi4uICIgPiY2OyB9Ci1hY19saW5rX2Rl
ZmF1bHQ9YCRhc19lY2hvICIkYWNfbGluayIgfCBzZWQgJ3MvIC1vICpjb25mdGVzdFteIF0qLy8n
YAotCi0jIFRoZSBwb3NzaWJsZSBvdXRwdXQgZmlsZXM6Ci1hY19maWxlcz0iYS5vdXQgY29uZnRl
c3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFfb3V0LmV4ZSBiLm91dCBjb25mdGVzdC4qIgotCi1hY19y
bWZpbGVzPQotZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzCi1kbwotICBjYXNlICRhY19maWxlIGlu
Ci0gICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0g
fCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7
OwotICAgICogKSBhY19ybWZpbGVzPSIkYWNfcm1maWxlcyAkYWNfZmlsZSI7OwotICBlc2FjCi1k
b25lCi1ybSAtZiAkYWNfcm1maWxlcwotCi1pZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19kZWZhdWx0
IgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hv
PVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1lc2FjCi1ldmFsIGFjX3Ry
eV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgot
JGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIkYWNfbGlua19kZWZhdWx0
IikgMj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07
IHRoZW4gOgotICAjIEF1dG9jb25mLTIuMTMgY291bGQgc2V0IHRoZSBhY19jdl9leGVleHQgdmFy
aWFibGUgdG8gYG5vJy4KLSMgU28gaWdub3JlIGEgdmFsdWUgb2YgYG5vJywgb3RoZXJ3aXNlIHRo
aXMgd291bGQgbGVhZCB0byBgRVhFRVhUID0gbm8nCi0jIGluIGEgTWFrZWZpbGUuICBXZSBzaG91
bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4ZWV4dCBpZiBpdCB3YXMgY2FjaGVkLAotIyBzbyB0aGF0
IHRoZSB1c2VyIGNhbiBzaG9ydC1jaXJjdWl0IHRoaXMgdGVzdCBmb3IgY29tcGlsZXJzIHVua25v
d24gdG8KLSMgQXV0b2NvbmYuCi1mb3IgYWNfZmlsZSBpbiAkYWNfZmlsZXMgJycKLWRvCi0gIHRl
c3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQotICBjYXNlICRhY19maWxlIGluCi0gICAgKi4k
YWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwg
Ki5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKQotCTs7Ci0gICAg
W2FiXS5vdXQgKQotCSMgV2UgZm91bmQgdGhlIGRlZmF1bHQgZXhlY3V0YWJsZSwgYnV0IGV4ZWV4
dD0nJyBpcyBtb3N0Ci0JIyBjZXJ0YWlubHkgcmlnaHQuCi0JYnJlYWs7OwotICAgICouKiApCi0J
aWYgdGVzdCAiJHthY19jdl9leGVleHQrc2V0fSIgPSBzZXQgJiYgdGVzdCAiJGFjX2N2X2V4ZWV4
dCIgIT0gbm87Ci0JdGhlbiA6OyBlbHNlCi0JICAgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmls
ZSIgOiAnW14uXSpcKFwuLipcKSdgCi0JZmkKLQkjIFdlIHNldCBhY19jdl9leGVleHQgaGVyZSBi
ZWNhdXNlIHRoZSBsYXRlciB0ZXN0IGZvciBpdCBpcyBub3QKLQkjIHNhZmU6IGNyb3NzIGNvbXBp
bGVycyBtYXkgbm90IGFkZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKLQkjIGFyZ3VtZW50
LCBzbyB3ZSBtYXkgbmVlZCB0byBrbm93IGl0IGF0IHRoYXQgcG9pbnQgYWxyZWFkeS4KLQkjIEV2
ZW4gaWYgdGhpcyBzZWN0aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YK
LQkjIGFjdHVhbGx5IHdvcmtpbmcuCi0JYnJlYWs7OwotICAgICogKQotCWJyZWFrOzsKLSAgZXNh
YwotZG9uZQotdGVzdCAiJGFjX2N2X2V4ZWV4dCIgPSBubyAmJiBhY19jdl9leGVleHQ9Ci0KLWVs
c2UKLSAgYWNfZmlsZT0nJwotZmkKLWlmIHRlc3QgLXogIiRhY19maWxlIjsgdGhlbiA6Ci0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0k
YXNfZWNobyAibm8iID4mNjsgfQotJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2Fz
OiIgPiY1Ci1zZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1Ci0KLXsgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5f
ZXJyb3IgNzcgIkMgY29tcGlsZXIgY2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcwotU2VlIFxgY29u
ZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci1lbHNlCi0gIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFz
X2VjaG8gInllcyIgPiY2OyB9Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUi
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQg
ZmlsZSBuYW1lLi4uICIgPiY2OyB9Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQotJGFzX2VjaG8gIiRhY19maWxlIiA+JjY7IH0K
LWFjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0Ci0KLXJtIC1mIC1yIGEub3V0IGEub3V0LmRTWU0gYS5l
eGUgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGIub3V0Ci1hY19jbGVhbl9maWxlcz0kYWNfY2xlYW5f
ZmlsZXNfc2F2ZQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMuLi4gIiA+JjY7IH0KLWlmIHsgeyBhY190cnk9IiRh
Y19saW5rIgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3Ry
eV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1lc2FjCi1ldmFs
IGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNo
b1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIkYWNfbGluayIp
IDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0
aGVuIDoKLSAgIyBJZiBib3RoIGBjb25mdGVzdC5leGUnIGFuZCBgY29uZnRlc3QnIGFyZSBgcHJl
c2VudCcgKHdlbGwsIG9ic2VydmFibGUpCi0jIGNhdGNoIGBjb25mdGVzdC5leGUnLiAgRm9yIGlu
c3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3QnIHdpbGwKLSMgd29yayBwcm9wZXJseSAo
aS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScpLCB3aGlsZSBpdCB3b24ndCB3aXRoCi0jIGBy
bScuCi1mb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUgY29uZnRlc3QgY29uZnRlc3QuKjsgZG8K
LSAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlCi0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAg
ICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICou
YmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7Ci0g
ICAgKi4qICkgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdg
Ci0JICBicmVhazs7Ci0gICAgKiApIGJyZWFrOzsKLSAgZXNhYwotZG9uZQotZWxzZQotICB7IHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30K
LWFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0YWJsZXM6IGNh
bm5vdCBjb21waWxlIGFuZCBsaW5rCi1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxz
IiAiJExJTkVOTyIgNSA7IH0KLWZpCi1ybSAtZiBjb25mdGVzdCBjb25mdGVzdCRhY19jdl9leGVl
eHQKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfZXhlZXh0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfZXhlZXh0IiA+JjY7IH0KLQotcm0gLWYg
Y29uZnRlc3QuJGFjX2V4dAotRVhFRVhUPSRhY19jdl9leGVleHQKLWFjX2V4ZWV4dD0kRVhFRVhU
Ci1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u
ZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3RkaW8uaD4KLWludAotbWFpbiAoKQotewotRklMRSAq
ZiA9IGZvcGVuICgiY29uZnRlc3Qub3V0IiwgInciKTsKLSByZXR1cm4gZmVycm9yIChmKSB8fCBm
Y2xvc2UgKGYpICE9IDA7Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotYWNfY2xlYW5f
ZmlsZXM9IiRhY19jbGVhbl9maWxlcyBjb25mdGVzdC5vdXQiCi0jIENoZWNrIHRoYXQgdGhlIGNv
bXBpbGVyIHByb2R1Y2VzIGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBub3QsIGVpdGhlcgot
IyB0aGUgY29tcGlsZXIgaXMgYnJva2VuLCBvciB3ZSBjcm9zcyBjb21waWxlLgoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBj
cm9zcyBjb21waWxpbmciID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUg
Y3Jvc3MgY29tcGlsaW5nLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiAh
PSB5ZXM7IHRoZW4KLSAgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCi1jYXNlICIoKCRhY190cnkiIGlu
Ci0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190
cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hv
IjsgfSA+JjUKLSAgKGV2YWwgIiRhY19saW5rIikgMj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1
Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KLSAgaWYgeyBhY190cnk9Jy4vY29uZnRlc3QkYWNf
Y3ZfZXhlZXh0JwotICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpc
XCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1l
c2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRh
Y190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIk
YWNfdHJ5IikgMj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH07IH07IHRoZW4KLSAgICBjcm9zc19jb21waWxpbmc9bm8KLSAgZWxzZQotICAgIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0gbWF5YmU7IHRoZW4KLQljcm9zc19jb21waWxpbmc9eWVz
Ci0gICAgZWxzZQotCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBl
cnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxg
JGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBydW4gQyBjb21waWxlZCBw
cm9ncmFtcy4KLUlmIHlvdSBtZWFudCB0byBjcm9zcyBjb21waWxlLCB1c2UgXGAtLWhvc3QnLgot
U2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci0gICAg
ZmkKLSAgZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGNyb3NzX2NvbXBpbGluZyIgPiY1Ci0kYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIg
PiY2OyB9Ci0KLXJtIC1mIGNvbmZ0ZXN0LiRhY19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNv
bmZ0ZXN0Lm91dAotYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBv
YmplY3QgZmlsZXMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmpl
Y3QgZmlsZXMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfb2JqZXh0K3NldH0iID0gc2V0
OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAq
LwotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1ybSAt
ZiBjb25mdGVzdC5vIGNvbmZ0ZXN0Lm9iagotaWYgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGUiCi1j
YXNlICIoKCRhY190cnkiIGluCi0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7OwotICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2Vj
aG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNf
ZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKLSAgKGV2YWwgIiRhY19jb21waWxlIikgMj4mNQot
ICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
XCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgot
ICBmb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5vIGNvbmZ0ZXN0Lm9iaiBjb25mdGVzdC4qOyBkbwot
ICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWU7Ci0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAg
ICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICou
YmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gKSA7OwotICAgICopIGFjX2N2X29i
amV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJy4qXC5cKC4qXCknYAotICAgICAgIGJyZWFrOzsKLSAg
ZXNhYwotZG9uZQotZWxzZQotICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6
IiA+JjUKLXNlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKLQoteyB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1
Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9l
cnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIG9iamVjdCBmaWxlczogY2Fubm90IGNv
bXBpbGUKLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsg
fQotZmkKLXJtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
b2JqZXh0IiA+JjUKLSRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KLU9CSkVYVD0kYWNf
Y3Zfb2JqZXh0Ci1hY19vYmpleHQ9JE9CSkVYVAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29t
cGlsZXIiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhl
IEdOVSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJf
Z251K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVs
c2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k
IGNvbmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkKLXsKLSNpZm5kZWYgX19HTlVDX18KLSAg
ICAgICBjaG9rZSBtZQotI2VuZGlmCi0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jb21waWxlcl9nbnU9
eWVzCi1lbHNlCi0gIGFjX2NvbXBpbGVyX2dudT1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotYWNfY3ZfY19jb21waWxl
cl9nbnU9JGFjX2NvbXBpbGVyX2dudQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY1Ci0kYXNfZWNo
byAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KLWlmIHRlc3QgJGFjX2NvbXBpbGVyX2du
dSA9IHllczsgdGhlbgotICBHQ0M9eWVzCi1lbHNlCi0gIEdDQz0KLWZpCi1hY190ZXN0X0NGTEFH
Uz0ke0NGTEFHUytzZXR9Ci1hY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWci
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZy4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9
JGFjX2Nfd2Vycm9yX2ZsYWcKLSAgIGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCi0gICBhY19jdl9wcm9n
X2NjX2c9bm8KLSAgIENGTEFHUz0iLWciCi0gICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQot
ewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUg
IiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfcHJvZ19jY19nPXllcwotZWxzZQotICBDRkxBR1M9
IiIKLSAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4g
MDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgot
Ci1lbHNlCi0gIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotCSBDRkxB
R1M9Ii1nIgotCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
LSAgYWNfY3ZfcHJvZ19jY19nPXllcwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotICAgYWNf
Y193ZXJyb3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCi1maQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQot
JGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQotaWYgdGVzdCAiJGFjX3Rlc3RfQ0ZM
QUdTIiA9IHNldDsgdGhlbgotICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCi1lbGlmIHRlc3QgJGFj
X2N2X3Byb2dfY2NfZyA9IHllczsgdGhlbgotICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgot
ICAgIENGTEFHUz0iLWcgLU8yIgotICBlbHNlCi0gICAgQ0ZMQUdTPSItZyIKLSAgZmkKLWVsc2UK
LSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KLSAgICBDRkxBR1M9Ii1PMiIKLSAgZWxzZQot
ICAgIENGTEFHUz0KLSAgZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKLSRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfYzg5K3NldH0iID0gc2V0OyB0aGVuIDoK
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY3ZfcHJvZ19jY19jODk9
bm8KLWFjX3NhdmVfQ0M9JENDCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3RkYXJnLmg+Ci0jaW5j
bHVkZSA8c3RkaW8uaD4KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KLSNpbmNsdWRlIDxzeXMvc3Rh
dC5oPgotLyogTW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1Mg
NS43J3Mgc3JjL2NvbmYuc2guICAqLwotc3RydWN0IGJ1ZiB7IGludCB4OyB9OwotRklMRSAqICgq
cmNzb3BlbikgKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KTsKLXN0YXRpYyBjaGFy
ICplIChwLCBpKQotICAgICBjaGFyICoqcDsKLSAgICAgaW50IGk7Ci17Ci0gIHJldHVybiBwW2ld
OwotfQotc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoq
cCwgLi4uKQotewotICBjaGFyICpzOwotICB2YV9saXN0IHY7Ci0gIHZhX3N0YXJ0ICh2LHApOwot
ICBzID0gZyAocCwgdmFfYXJnICh2LGludCkpOwotICB2YV9lbmQgKHYpOwotICByZXR1cm4gczsK
LX0KLQotLyogT1NGIDQuMCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5
IGRlZmF1bHQuICBJdCBoYXMKLSAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQg
bm90ICdceEhIJyBoZXggY2hhcmFjdGVyIGNvbnN0YW50cy4KLSAgIFRoZXNlIGRvbid0IHByb3Zv
a2UgYW4gZXJyb3IgdW5mb3J0dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAot
ICAgYXMgJ3gnLiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlz
IGFkZGVkIHRvIGdldAotICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4
JyBhbHdheXMgY29tZXMgb3V0IHRydWUsIGZvciBhbgotICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4g
IEl0J3MgbmVjZXNzYXJ5IHRvIHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCi0gICB0
aGF0J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICovCi1pbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAn
ID09IDAgPyAxIDogLTFdOwotCi0vKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkg
ZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKLSAgIGluc2lkZSBzdHJp
bmdzIGFuZCBjaGFyYWN0ZXIgY29uc3RhbnRzLiAgKi8KLSNkZWZpbmUgRk9PKHgpICd4JwotaW50
IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07Ci0KLWludCB0ZXN0IChpbnQg
aSwgZG91YmxlIHgpOwotc3RydWN0IHMxIHtpbnQgKCpmKSAoaW50IGEpO307Ci1zdHJ1Y3QgczIg
e2ludCAoKmYpIChkb3VibGUgYSk7fTsKLWludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklM
RSAqKCopKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOwotaW50
IGFyZ2M7Ci1jaGFyICoqYXJndjsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGYgKGUsIGFyZ3Ys
IDApICE9IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOwotICA7Ci0gIHJl
dHVybiAwOwotfQotX0FDRU9GCi1mb3IgYWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFs
YW5nbHZsPWFuc2kgLXN0ZCBcCi0JLUFlICItQWEgLURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VY
VEVOU0lPTlNfXyIKLWRvCi0gIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgotICBpZiBhY19mbl9j
X3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19h
cmcKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0Ci0gIHRl
c3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCi1kb25lCi1ybSAtZiBj
b25mdGVzdC4kYWNfZXh0Ci1DQz0kYWNfc2F2ZV9DQwotCi1maQotIyBBQ19DQUNIRV9WQUwKLWNh
c2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCi0gIHgpCi0gICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vbmUgbmVlZGVkIiA+JjUKLSRhc19lY2hv
ICJub25lIG5lZWRlZCIgPiY2OyB9IDs7Ci0gIHhubykKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdW5zdXBwb3J0ZWQiID4mNQotJGFzX2VjaG8g
InVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKLSAgKikKLSAgICBDQz0iJENDICRhY19jdl9wcm9nX2Nj
X2M4OSIKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODki
ID4mNjsgfSA7OwotZXNhYwotaWYgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0
aGVuIDoKLQotZmkKLQotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21w
aWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19s
aW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdT
IGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2Nv
bXBpbGVyX2dudQotCi0KLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29t
cGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNf
bGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFH
UyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19j
b21waWxlcl9nbnUKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IuLi4gIiA+JjY7IH0KLSMgT24gU3Vu
cywgc29tZXRpbWVzICRDUFAgbmFtZXMgYSBkaXJlY3RvcnkuCi1pZiB0ZXN0IC1uICIkQ1BQIiAm
JiB0ZXN0IC1kICIkQ1BQIjsgdGhlbgotICBDUFA9Ci1maQotaWYgdGVzdCAteiAiJENQUCI7IHRo
ZW4KLSAgaWYgdGVzdCAiJHthY19jdl9wcm9nX0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gICAgICAjIERvdWJsZSBxdW90ZXMgYmVj
YXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhwYW5kZWQKLSAgICBmb3IgQ1BQIGluICIkQ0MgLUUiICIk
Q0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIgIi9saWIvY3BwIgotICAgIGRvCi0gICAgICBhY19wcmVw
cm9jX29rPWZhbHNlCi1mb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKLWRvCi0g
ICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcg
Z2xpYmMKLSAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCi0gICMgUHJlZmVy
IDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQot
ICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KLSAg
IyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidz
IHBhcnNlciwKLSAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVy
ZSB0byBjYXRjaCB0aGlzIGNhc2UuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpZmRlZiBfX1NURENfXwotIyBp
bmNsdWRlIDxsaW1pdHMuaD4KLSNlbHNlCi0jIGluY2x1ZGUgPGFzc2VydC5oPgotI2VuZGlmCi0J
CSAgICAgU3ludGF4IGVycm9yCi1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7
IHRoZW4gOgotCi1lbHNlCi0gICMgQnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KLWNvbnRp
bnVlCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAot
Ci0gICMgT0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlz
dGVudCBoZWFkZXJzCi0gICMgY2FuIGJlIGRldGVjdGVkIGFuZCBob3cuCi0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LSNpbmNsdWRlIDxhY19ub25leGlzdGVudC5oPgotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jcHAg
IiRMSU5FTk8iOyB0aGVuIDoKLSAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4K
LWNvbnRpbnVlCi1lbHNlCi0gICMgUGFzc2VzIGJvdGggdGVzdHMuCi1hY19wcmVwcm9jX29rPToK
LWJyZWFrCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4
dAotCi1kb25lCi0jIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xl
YW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KLXJtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19leHQKLWlmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKLSAgYnJlYWsKLWZpCi0K
LSAgICBkb25lCi0gICAgYWNfY3ZfcHJvZ19DUFA9JENQUAotCi1maQotICBDUFA9JGFjX2N2X3By
b2dfQ1BQCi1lbHNlCi0gIGFjX2N2X3Byb2dfQ1BQPSRDUFAKLWZpCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENQUCIgPiY1Ci0kYXNfZWNobyAiJENQ
UCIgPiY2OyB9Ci1hY19wcmVwcm9jX29rPWZhbHNlCi1mb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxh
ZyBpbiAnJyB5ZXMKLWRvCi0gICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdj
Yywgc28gY29uZmlndXJpbmcgZ2xpYmMKLSAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIg
d29ya3MuCi0gICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBp
cyBkZWZpbmVkLCBzaW5jZQotICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5k
aW5nIGNvbXBpbGVycy4KLSAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJv
dWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKLSAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5
bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCi0gIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNp
ZmRlZiBfX1NURENfXwotIyBpbmNsdWRlIDxsaW1pdHMuaD4KLSNlbHNlCi0jIGluY2x1ZGUgPGFz
c2VydC5oPgotI2VuZGlmCi0JCSAgICAgU3ludGF4IGVycm9yCi1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgotCi1lbHNlCi0gICMgQnJva2VuOiBmYWlscyBvbiB2
YWxpZCBpbnB1dC4KLWNvbnRpbnVlCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0Lmkg
Y29uZnRlc3QuJGFjX2V4dAotCi0gICMgT0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hl
Y2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCi0gICMgY2FuIGJlIGRldGVjdGVkIGFuZCBo
b3cuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxhY19ub25leGlzdGVudC5oPgotX0FDRU9GCi1p
ZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKLSAgIyBCcm9rZW46IHN1Y2Nlc3Mg
b24gaW52YWxpZCBpbnB1dC4KLWNvbnRpbnVlCi1lbHNlCi0gICMgUGFzc2VzIGJvdGggdGVzdHMu
Ci1hY19wcmVwcm9jX29rPToKLWJyZWFrCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuJGFjX2V4dAotCi1kb25lCi0jIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BS
RVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KLXJtIC1mIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKLWlmICRhY19wcmVwcm9jX29rOyB0aGVu
IDoKLQotZWxzZQotICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiYyO30KLWFzX2ZuX2Vycm9yICQ/ICJDIHByZXByb2Nlc3NvciBcIiRDUFBc
IiBmYWlscyBzYW5pdHkgY2hlY2sKLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMi
ICIkTElORU5PIiA1IDsgfQotZmkKLQotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1Mn
Ci1hY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+
JjUnCi1hY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdT
ICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRh
Y19jdl9jX2NvbXBpbGVyX2dudQotCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1l
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxp
bmVzIGFuZCAtZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0dSRVArc2V0fSIg
PSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0
ZXN0IC16ICIkR1JFUCI7IHRoZW4KLSAgYWNfcGF0aF9HUkVQX2ZvdW5kPWZhbHNlCi0gICMgTG9v
cCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1M
SVNUCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIg
aW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCi1kbwotICBJRlM9JGFzX3NhdmVf
SUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX3Byb2cgaW4g
Z3JlcCBnZ3JlcDsgZG8KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KLSAgICAgIGFjX3BhdGhfR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19l
eGVjX2V4dCIKLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfR1JFUCIgJiYgJGFzX3Rlc3RfeCAi
JGFjX3BhdGhfR1JFUCI7IH0gfHwgY29udGludWUKLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0dS
RVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KLSAgIyBDaGVjayBmb3IgR05VICRhY19w
YXRoX0dSRVAKLWNhc2UgYCIkYWNfcGF0aF9HUkVQIiAtLXZlcnNpb24gMj4mMWAgaW4KLSpHTlUq
KQotICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiIGFjX3BhdGhfR1JFUF9mb3VuZD06
OzsKLSopCi0gIGFjX2NvdW50PTAKLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3Qu
aW4iCi0gIHdoaWxlIDoKLSAgZG8KLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4i
ID4iY29uZnRlc3QudG1wIgotICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKLSAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKLSAgICAkYXNfZWNobyAnR1JFUCcgPj4g
ImNvbmZ0ZXN0Lm5sIgotICAgICIkYWNfcGF0aF9HUkVQIiAtZSAnR1JFUCQnIC1lICctKGNhbm5v
dCBtYXRjaCktJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8
IGJyZWFrCi0gICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwg
Mj4mMSB8fCBicmVhawotICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9
JGFzX3ZhbAotICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfR1JFUF9tYXgtMH07
IHRoZW4KLSAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcg
Zm9yIGEgYmV0dGVyIG9uZQotICAgICAgYWNfY3ZfcGF0aF9HUkVQPSIkYWNfcGF0aF9HUkVQIgot
ICAgICAgYWNfcGF0aF9HUkVQX21heD0kYWNfY291bnQKLSAgICBmaQotICAgICMgMTAqKDJeMTAp
IGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKLSAgICB0ZXN0ICRhY19jb3Vu
dCAtZ3QgMTAgJiYgYnJlYWsKLSAgZG9uZQotICBybSAtZiBjb25mdGVzdC5pbiBjb25mdGVzdC50
bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKLWVzYWMKLQotICAgICAgJGFjX3BhdGhfR1JF
UF9mb3VuZCAmJiBicmVhayAzCi0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2
ZV9JRlMKLSAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4KLSAgICBhc19mbl9l
cnJvciAkPyAibm8gYWNjZXB0YWJsZSBncmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhf
U0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKLSAgZmkKLWVsc2UKLSAgYWNfY3Zf
cGF0aF9HUkVQPSRHUkVQCi1maQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0dSRVAiID4mNQotJGFzX2VjaG8gIiRhY19j
dl9wYXRoX0dSRVAiID4mNjsgfQotIEdSRVA9IiRhY19jdl9wYXRoX0dSRVAiCi0KLQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZWdyZXAiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGVncmVwLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfRUdSRVArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgotZWxzZQotICBpZiBlY2hvIGEgfCAkR1JFUCAtRSAnKGF8YiknID4vZGV2L251
bGwgMj4mMQotICAgdGhlbiBhY19jdl9wYXRoX0VHUkVQPSIkR1JFUCAtRSIKLSAgIGVsc2UKLSAg
ICAgaWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgotICBhY19wYXRoX0VHUkVQX2ZvdW5kPWZhbHNl
Ci0gICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQ
Uk9HTkFNRS1MSVNUCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZv
ciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCi1kbwotICBJRlM9
JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFj
X3Byb2cgaW4gZWdyZXA7IGRvCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCi0gICAgICBhY19wYXRoX0VHUkVQPSIkYXNfZGlyLyRhY19wcm9n
JGFjX2V4ZWNfZXh0IgotICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9FR1JFUCIgJiYgJGFzX3Rl
c3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNvbnRpbnVlCi0jIENoZWNrIGZvciBHTlUgYWNf
cGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgotICAjIENoZWNrIGZvciBH
TlUgJGFjX3BhdGhfRUdSRVAKLWNhc2UgYCIkYWNfcGF0aF9FR1JFUCIgLS12ZXJzaW9uIDI+JjFg
IGluCi0qR05VKikKLSAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiIGFjX3BhdGhf
RUdSRVBfZm91bmQ9Ojs7Ci0qKQotICBhY19jb3VudD0wCi0gICRhc19lY2hvX24gMDEyMzQ1Njc4
OSA+ImNvbmZ0ZXN0LmluIgotICB3aGlsZSA6Ci0gIGRvCi0gICAgY2F0ICJjb25mdGVzdC5pbiIg
ImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIKLSAgICBtdiAiY29uZnRlc3QudG1wIiAiY29u
ZnRlc3QuaW4iCi0gICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCi0gICAgJGFzX2Vj
aG8gJ0VHUkVQJyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRhY19wYXRoX0VHUkVQIiAnRUdSRVAk
JyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCi0g
ICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBi
cmVhawotICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9JGFzX3ZhbAot
ICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfRUdSRVBfbWF4LTB9OyB0aGVuCi0g
ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl
dHRlciBvbmUKLSAgICAgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIgotICAgICAg
YWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigyXjEwKSBjaGFy
cyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNfY291bnQgLWd0
IDEwICYmIGJyZWFrCi0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNv
bmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Ci1lc2FjCi0KLSAgICAgICRhY19wYXRoX0VHUkVQX2Zv
dW5kICYmIGJyZWFrIDMKLSAgICBkb25lCi0gIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lG
UwotICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JFUCI7IHRoZW4KLSAgICBhc19mbl9lcnJv
ciAkPyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NF
UEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1Ci0gIGZpCi1lbHNlCi0gIGFjX2N2X3Bh
dGhfRUdSRVA9JEVHUkVQCi1maQotCi0gICBmaQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9FR1JFUCIgPiY1Ci0kYXNfZWNo
byAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQotIEVHUkVQPSIkYWNfY3ZfcGF0aF9FR1JFUCIK
LQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBBTlNJIEMgaGVhZGVyIGZpbGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBBTlNJ
IEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zdGRj
K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGxpYi5oPgotI2luY2x1ZGUgPHN0ZGFyZy5oPgot
I2luY2x1ZGUgPHN0cmluZy5oPgotI2luY2x1ZGUgPGZsb2F0Lmg+Ci0KLWludAotbWFpbiAoKQot
ewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUg
IiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfaGVhZGVyX3N0ZGM9eWVzCi1lbHNlCi0gIGFjX2N2
X2hlYWRlcl9zdGRjPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0g
eWVzOyB0aGVuCi0gICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwg
Y29udHJhcnkgdG8gQU5TSS4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0cmluZy5oPgotCi1f
QUNFT0YKLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKLSAgJEVH
UkVQICJtZW1jaHIiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0KLWVsc2UKLSAgYWNfY3ZfaGVh
ZGVyX3N0ZGM9bm8KLWZpCi1ybSAtZiBjb25mdGVzdCoKLQotZmkKLQotaWYgdGVzdCAkYWNfY3Zf
aGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLSAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3Qg
ZGVjbGFyZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8
c3RkbGliLmg+Ci0KLV9BQ0VPRgotaWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIp
IDI+JjUgfAotICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0KLWVsc2UK
LSAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KLWZpCi1ybSAtZiBjb25mdGVzdCoKLQotZmkKLQotaWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLSAgIyAvYmluL2NjIGluIElyaXgt
NC4wLjUgZ2V0cyBub24tQU5TSSBjdHlwZSBtYWNyb3MgdW5sZXNzIHVzaW5nIC1hbnNpLgotICBp
ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIDoKLWVsc2UKLSAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZz
LmguICAqLwotI2luY2x1ZGUgPGN0eXBlLmg+Ci0jaW5jbHVkZSA8c3RkbGliLmg+Ci0jaWYgKCgn
ICcgJiAweDBGRikgPT0gMHgwMjApCi0jIGRlZmluZSBJU0xPV0VSKGMpICgnYScgPD0gKGMpICYm
IChjKSA8PSAneicpCi0jIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gJ0EnICsgKChj
KSAtICdhJykgOiAoYykpCi0jZWxzZQotIyBkZWZpbmUgSVNMT1dFUihjKSBcCi0JCSAgICgoJ2En
IDw9IChjKSAmJiAoYykgPD0gJ2knKSBcCi0JCSAgICAgfHwgKCdqJyA8PSAoYykgJiYgKGMpIDw9
ICdyJykgXAotCQkgICAgIHx8ICgncycgPD0gKGMpICYmIChjKSA8PSAneicpKQotIyBkZWZpbmUg
VE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICgoYykgfCAweDQwKSA6IChjKSkKLSNlbmRpZgotCi0j
ZGVmaW5lIFhPUihlLCBmKSAoKChlKSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQotaW50Ci1t
YWluICgpCi17Ci0gIGludCBpOwotICBmb3IgKGkgPSAwOyBpIDwgMjU2OyBpKyspCi0gICAgaWYg
KFhPUiAoaXNsb3dlciAoaSksIElTTE9XRVIgKGkpKQotCXx8IHRvdXBwZXIgKGkpICE9IFRPVVBQ
RVIgKGkpKQotICAgICAgcmV0dXJuIDI7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19m
bl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQotICBhY19jdl9oZWFkZXJfc3Rk
Yz1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5v
dXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5i
ZWFtIGNvbmZ0ZXN0LiRhY19leHQKLWZpCi0KLWZpCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYyIgPiY1Ci0kYXNf
ZWNobyAiJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9z
dGRjID0geWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIFNURENfSEVBREVSUyAxIiA+PmNv
bmZkZWZzLmgKLQotZmkKLQotIyBPbiBJUklYIDUuMywgc3lzL3R5cGVzIGFuZCBpbnR0eXBlcy5o
IGFyZSBjb25mbGljdGluZy4KLWZvciBhY19oZWFkZXIgaW4gc3lzL3R5cGVzLmggc3lzL3N0YXQu
aCBzdGRsaWIuaCBzdHJpbmcuaCBtZW1vcnkuaCBzdHJpbmdzLmggXAotCQkgIGludHR5cGVzLmgg
c3RkaW50LmggdW5pc3RkLmgKLWRvIDoKLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3Zf
aGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfY29t
cGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQKLSIKLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwiID0geCJ5ZXMi
OyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBgJGFzX2VjaG8g
IkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQotZmkKLQotZG9uZQot
Ci0KLQotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibWluaXgvY29u
ZmlnLmgiICJhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19oIiA9IHgiInllczsgdGhl
biA6Ci0gIE1JTklYPXllcwotZWxzZQotICBNSU5JWD0KLWZpCi0KLQotICBpZiB0ZXN0ICIkTUlO
SVgiID0geWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIgPj5j
b25mZGVmcy5oCi0KLQotJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+Y29u
ZmRlZnMuaAotCi0KLSRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZkZWZzLmgKLQot
ICBmaQotCi0KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fIiA+JjUKLSRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2FmZSB0byBkZWZpbmUgX19FWFRFTlNJ
T05TX18uLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRl
bnNpb25zX18rc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLSMJICBkZWZpbmUgX19FWFRFTlNJT05TX18gMQotCSAg
JGFjX2luY2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJuIDA7
Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAg
YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX189eWVzCi1lbHNlCi0gIGFjX2N2X3Nh
ZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9zYWZlX3RvX2RlZmlu
ZV9fX2V4dGVuc2lvbnNfXyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19f
ZXh0ZW5zaW9uc19fIiA+JjY7IH0KLSAgdGVzdCAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRl
bnNpb25zX18gPSB5ZXMgJiYKLSAgICAkYXNfZWNobyAiI2RlZmluZSBfX0VYVEVOU0lPTlNfXyAx
IiA+PmNvbmZkZWZzLmgKLQotICAkYXNfZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNv
bmZkZWZzLmgKLQotICAkYXNfZWNobyAiI2RlZmluZSBfR05VX1NPVVJDRSAxIiA+PmNvbmZkZWZz
LmgKLQotICAkYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MgMSIgPj5j
b25mZGVmcy5oCi0KLSAgJGFzX2VjaG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25m
ZGVmcy5oCi0KLQotIyBNYWtlIHN1cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgotJFNIRUxMICIk
YWNfYXV4X2Rpci9jb25maWcuc3ViIiBzdW40ID4vZGV2L251bGwgMj4mMSB8fAotICBhc19mbl9l
cnJvciAkPyAiY2Fubm90IHJ1biAkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgIiRMSU5F
Tk8iIDUKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBidWlsZCBzeXN0ZW0gdHlwZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBidWlsZCBzeXN0
ZW0gdHlwZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9idWlsZCtzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2J1aWxkX2Fs
aWFzPSRidWlsZF9hbGlhcwotdGVzdCAieCRhY19idWlsZF9hbGlhcyIgPSB4ICYmCi0gIGFjX2J1
aWxkX2FsaWFzPWAkU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5ndWVzcyJgCi10ZXN0ICJ4JGFj
X2J1aWxkX2FsaWFzIiA9IHggJiYKLSAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBndWVzcyBidWls
ZCB0eXBlOyB5b3UgbXVzdCBzcGVjaWZ5IG9uZSIgIiRMSU5FTk8iIDUKLWFjX2N2X2J1aWxkPWAk
U0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICRhY19idWlsZF9hbGlhc2AgfHwKLSAgYXNf
Zm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViICRhY19idWlsZF9hbGlh
cyBmYWlsZWQiICIkTElORU5PIiA1Ci0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2J1aWxkIiA+JjUKLSRhc19lY2hvICIkYWNfY3Zf
YnVpbGQiID4mNjsgfQotY2FzZSAkYWNfY3ZfYnVpbGQgaW4KLSotKi0qKSA7OwotKikgYXNfZm5f
ZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGJ1aWxkIiAiJExJTkVOTyIgNSA7
OwotZXNhYwotYnVpbGQ9JGFjX2N2X2J1aWxkCi1hY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCi1z
ZXQgeCAkYWNfY3ZfYnVpbGQKLXNoaWZ0Ci1idWlsZF9jcHU9JDEKLWJ1aWxkX3ZlbmRvcj0kMgot
c2hpZnQ7IHNoaWZ0Ci0jIFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1
c2VkIHRvIGNyZWF0ZSAkKiwKLSMgZXhjZXB0IHdpdGggb2xkIHNoZWxsczoKLWJ1aWxkX29zPSQq
Ci1JRlM9JGFjX3NhdmVfSUZTCi1jYXNlICRidWlsZF9vcyBpbiAqXCAqKSBidWlsZF9vcz1gZWNo
byAiJGJ1aWxkX29zIiB8IHNlZCAncy8gLy0vZydgOzsgZXNhYwotCi0KLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZSIgPiY1
Ci0kYXNfZWNob19uICJjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlLi4uICIgPiY2OyB9Ci1pZiB0
ZXN0ICIke2FjX2N2X2hvc3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICJ4JGhvc3RfYWxpYXMiID0geDsgdGhlbgotICBh
Y19jdl9ob3N0PSRhY19jdl9idWlsZAotZWxzZQotICBhY19jdl9ob3N0PWAkU0hFTEwgIiRhY19h
dXhfZGlyL2NvbmZpZy5zdWIiICRob3N0X2FsaWFzYCB8fAotICAgIGFzX2ZuX2Vycm9yICQ/ICIk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkaG9zdF9hbGlhcyBmYWlsZWQiICIkTElORU5P
IiA1Ci1maQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9ob3N0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaG9zdCIgPiY2OyB9Ci1j
YXNlICRhY19jdl9ob3N0IGluCi0qLSotKikgOzsKLSopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlk
IHZhbHVlIG9mIGNhbm9uaWNhbCBob3N0IiAiJExJTkVOTyIgNSA7OwotZXNhYwotaG9zdD0kYWNf
Y3ZfaG9zdAotYWNfc2F2ZV9JRlM9JElGUzsgSUZTPSctJwotc2V0IHggJGFjX2N2X2hvc3QKLXNo
aWZ0Ci1ob3N0X2NwdT0kMQotaG9zdF92ZW5kb3I9JDIKLXNoaWZ0OyBzaGlmdAotIyBSZW1lbWJl
ciwgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiBJRlMgaXMgdXNlZCB0byBjcmVhdGUgJCosCi0jIGV4
Y2VwdCB3aXRoIG9sZCBzaGVsbHM6Ci1ob3N0X29zPSQqCi1JRlM9JGFjX3NhdmVfSUZTCi1jYXNl
ICRob3N0X29zIGluICpcICopIGhvc3Rfb3M9YGVjaG8gIiRob3N0X29zIiB8IHNlZCAncy8gLy0v
ZydgOzsgZXNhYwotCi0KLQotIyBNNCBNYWNybyBpbmNsdWRlcwotCi0KLQotCi0KLQotCi0KLQot
Ci0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0K
LQotCi0KLQotCi0KLQotCi0KLSMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQgdXRpbGlz
ZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KLSMgc2VyaWFsIDEgKHBr
Zy1jb25maWctMC4yNCkKLSMKLSMgQ29weXJpZ2h0IMKpIDIwMDQgU2NvdHQgSmFtZXMgUmVtbmFu
dCA8c2NvdHRAbmV0c3BsaXQuY29tPi4KLSMKLSMgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKLSMgaXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkK
LSMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUg
TGljZW5zZSwgb3IKLSMgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KLSMKLSMg
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1
c2VmdWwsIGJ1dAotIyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBs
aWVkIHdhcnJhbnR5IG9mCi0jIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJ
Q1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCi0jIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9y
IG1vcmUgZGV0YWlscy4KLSMKLSMgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKLSMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07
IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKLSMgRm91bmRhdGlvbiwgSW5jLiwg
NTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLCBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVTQS4K
LSMKLSMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UsIGlmIHlvdQotIyBkaXN0cmlidXRlIHRoaXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3Jh
bSB0aGF0IGNvbnRhaW5zIGEKLSMgY29uZmlndXJhdGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1
dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIKLSMgdGhlIHNhbWUgZGlzdHJpYnV0aW9u
IHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhhdCBwcm9ncmFtLgotCi0jIFBL
R19QUk9HX1BLR19DT05GSUcoW01JTi1WRVJTSU9OXSkKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQotIyBQS0dfUFJPR19QS0dfQ09ORklHCi0KLSMgUEtHX0NIRUNLX0VYSVNU
UyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQotIwot
IyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMgZXhpc3Rz
LiAgU2ltaWxhcgotIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBub3Qgc2V0IHZh
cmlhYmxlcyBvciBwcmludCBlcnJvcnMuCi0jCi0jIFBsZWFzZSByZW1lbWJlciB0aGF0IG00IGV4
cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCi0jIG9ubHkgYXQgdGhlIGZp
cnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBwbGFjZQotIyBp
dCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdpdGhpbiBhbiAi
aWYiLCB5b3UKLSMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFsbHkKLSMgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KLQotCi0jIF9QS0dfQ09ORklHKFtWQVJJQUJMRV0sIFtDT01NQU5EXSwgW01PRFVMRVNdKQot
IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgX1BLR19D
T05GSUcKLQotIyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKLSMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0KLSMgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVECi0KLQotIyBQS0df
Q0hFQ0tfTU9EVUxFUyhWQVJJQUJMRS1QUkVGSVgsIE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRd
LAotIyBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCi0jCi0jCi0jIE5vdGUgdGhhdCBpZiB0aGVyZSBp
cyBhIHBvc3NpYmlsaXR5IHRoZSBmaXJzdCBjYWxsIHRvCi0jIFBLR19DSEVDS19NT0RVTEVTIG1p
Z2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3VyZSB0byBpbmNsdWRlIGFuCi0jIGV4cGxp
Y2l0IGNhbGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBpbiB5b3VyIGNvbmZpZ3VyZS5hYwotIwot
IwotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQotIyBQS0dfQ0hFQ0tfTU9EVUxFUwotCi0KLQotIyBXZSBkZWZpbmUsIHNlcGFy
YXRlbHksIFBUSFJFQURfQ0ZMQUdTLCBfTERGTEFHUyBhbmQgX0xJQlMKLSMgZXZlbiB0aG91Z2gg
Y3VycmVudGx5IHdlIGRvbid0IHNldCB0aGVtIHZlcnkgc2VwYXJhdGVseS4KLSMgVGhpcyBtZWFu
cyB0aGF0IHRoZSBtYWtlZmlsZXMgd2lsbCBub3QgbmVlZCB0byBjaGFuZ2UgaW4KLSMgdGhlIGZ1
dHVyZSBpZiB3ZSBtYWtlIHRoZSB0ZXN0IG1vcmUgc29waGlzdGljYXRlZC4KLQotCi0KLSMgV2Ug
aW52b2tlIEFYX1BUSFJFQURfVkFSUyB3aXRoIHRoZSBuYW1lIG9mIGFub3RoZXIgbWFjcm8KLSMg
d2hpY2ggaXMgdGhlbiBleHBhbmRlZCBvbmNlIGZvciBlYWNoIHZhcmlhYmxlLgotCi0KLQotCi0K
LQotCi0KLSMgRW5hYmxlL2Rpc2FibGUgb3B0aW9ucwotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFi
bGUtZ2l0aHR0cCB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9naXRodHRwK3NldH0iID0g
c2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfZ2l0aHR0cDsKLWZpCi0KLQotaWYgdGVz
dCAieCRlbmFibGVfZ2l0aHR0cCIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9naXRodHRw
PSJuIgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0gInh5ZXMiOyB0aGVuIDoKLQot
ICAgIGF4X2N2X2dpdGh0dHA9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhl
biA6Ci0KLSAgICBheF9jdl9naXRodHRwPSJuIgotCi1maQotZ2l0aHR0cD0kYXhfY3ZfZ2l0aHR0
cAotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KLWlm
IHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFs
PSRlbmFibGVfbW9uaXRvcnM7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9
ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X21vbml0b3JzPSJuIgotCi1lbGlmIHRlc3QgIngk
ZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9tb25pdG9ycz0i
eSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9tb25pdG9yczsgdGhlbiA6Ci0KLSAgICBheF9jdl9t
b25pdG9ycz0ieSIKLQotZmkKLW1vbml0b3JzPSRheF9jdl9tb25pdG9ycwotCi0KLQotIyBDaGVj
ayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfdnRw
bStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07Ci1maQotCi0K
LWlmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfdnRw
bT0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAg
ICBheF9jdl92dHBtPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgotCi0g
ICAgYXhfY3ZfdnRwbT0ibiIKLQotZmkKLXZ0cG09JGF4X2N2X3Z0cG0KLQotCi0KLSMgQ2hlY2sg
d2hldGhlciAtLWVuYWJsZS14ZW5hcGkgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfeGVu
YXBpK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfeGVuYXBpOwotZmkK
LQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhf
Y3ZfeGVuYXBpPSJuIgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieHllcyI7IHRo
ZW4gOgotCi0gICAgYXhfY3ZfeGVuYXBpPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X3hlbmFw
aTsgdGhlbiA6Ci0KLSAgICBheF9jdl94ZW5hcGk9Im4iCi0KLWZpCi14ZW5hcGk9JGF4X2N2X3hl
bmFwaQotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZl
bi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3B5dGhvbnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAg
ZW5hYmxldmFsPSRlbmFibGVfcHl0aG9udG9vbHM7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxl
X3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJu
IgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6Ci0K
LSAgICBheF9jdl9weXRob250b29scz0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250
b29sczsgdGhlbiA6Ci0KLSAgICBheF9jdl9weXRob250b29scz0ieSIKLQotZmkKLXB5dGhvbnRv
b2xzPSRheF9jdl9weXRob250b29scwotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW9j
YW1sdG9vbHMgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfb2NhbWx0b29scytzZXR9IiA9
IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX29jYW1sdG9vbHM7Ci1maQotCi0KLWlm
IHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3Zf
b2NhbWx0b29scz0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVz
IjsgdGhlbiA6Ci0KLSAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4
X2N2X29jYW1sdG9vbHM7IHRoZW4gOgotCi0gICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKLQotZmkK
LW9jYW1sdG9vbHM9JGF4X2N2X29jYW1sdG9vbHMKLQotCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVu
YWJsZS1taW5pdGVybSB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9taW5pdGVybStzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOwotZmkKLQotCi1p
ZiB0ZXN0ICJ4JGVuYWJsZV9taW5pdGVybSIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9t
aW5pdGVybT0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9taW5pdGVybSIgPSAieHllcyI7IHRo
ZW4gOgotCi0gICAgYXhfY3ZfbWluaXRlcm09InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfbWlu
aXRlcm07IHRoZW4gOgotCi0gICAgYXhfY3ZfbWluaXRlcm09Im4iCi0KLWZpCi1taW5pdGVybT0k
YXhfY3ZfbWluaXRlcm0KLQotCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21vdW50IHdh
cyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0fSIgPSBzZXQ7IHRoZW4gOgot
ICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9s
b21vdW50IiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X2xvbW91bnQ9Im4iCi0KLWVsaWYg
dGVzdCAieCRlbmFibGVfbG9tb3VudCIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfbG9t
b3VudD0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9sb21vdW50OyB0aGVuIDoKLQotICAgIGF4
X2N2X2xvbW91bnQ9Im4iCi0KLWZpCi1sb21vdW50PSRheF9jdl9sb21vdW50Ci0KLQotCi0jIENo
ZWNrIHdoZXRoZXIgLS1lbmFibGUtb3ZtZiB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9v
dm1mK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfb3ZtZjsKLWZpCi0K
LQotaWYgdGVzdCAieCRlbmFibGVfb3ZtZiIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9v
dm1mPSJuIgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX292bWYiID0gInh5ZXMiOyB0aGVuIDoKLQot
ICAgIGF4X2N2X292bWY9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3Zfb3ZtZjsgdGhlbiA6Ci0K
LSAgICBheF9jdl9vdm1mPSJuIgotCi1maQotb3ZtZj0kYXhfY3Zfb3ZtZgorIyBNNCBNYWNybyBp
bmNsdWRlcwogCiAKIAotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXJvbWJpb3Mgd2FzIGdpdmVu
LgotaWYgdGVzdCAiJHtlbmFibGVfcm9tYmlvcytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJs
ZXZhbD0kZW5hYmxlX3JvbWJpb3M7Ci1maQogCiAKLWlmIHRlc3QgIngkZW5hYmxlX3JvbWJpb3Mi
ID0gInhubyI7IHRoZW4gOgogCi0gICAgYXhfY3Zfcm9tYmlvcz0ibiIKIAotZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9yb21iaW9zIiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICBheF9jdl9yb21iaW9zPSJ5
IgogCi1lbGlmIHRlc3QgLXogJGF4X2N2X3JvbWJpb3M7IHRoZW4gOgogCi0gICAgYXhfY3Zfcm9t
Ymlvcz0ieSIKIAotZmkKLXJvbWJpb3M9JGF4X2N2X3JvbWJpb3MKIAogCiAKLSMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1zZWFiaW9zIHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3NlYWJp
b3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9zZWFiaW9zOwotZmkK
IAogCi1pZiB0ZXN0ICJ4JGVuYWJsZV9zZWFiaW9zIiA9ICJ4bm8iOyB0aGVuIDoKIAotICAgIGF4
X2N2X3NlYWJpb3M9Im4iCiAKLWVsaWYgdGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieHllcyI7
IHRoZW4gOgogCi0gICAgYXhfY3Zfc2VhYmlvcz0ieSIKIAotZWxpZiB0ZXN0IC16ICRheF9jdl9z
ZWFiaW9zOyB0aGVuIDoKIAotICAgIGF4X2N2X3NlYWJpb3M9InkiCiAKLWZpCi1zZWFiaW9zPSRh
eF9jdl9zZWFiaW9zCiAKIAogCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtZGVidWcgd2FzIGdp
dmVuLgotaWYgdGVzdCAiJHtlbmFibGVfZGVidWcrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFi
bGV2YWw9JGVuYWJsZV9kZWJ1ZzsKLWZpCiAKIAotaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0g
InhubyI7IHRoZW4gOgogCi0gICAgYXhfY3ZfZGVidWc9Im4iCiAKLWVsaWYgdGVzdCAieCRlbmFi
bGVfZGVidWciID0gInh5ZXMiOyB0aGVuIDoKIAotICAgIGF4X2N2X2RlYnVnPSJ5IgogCi1lbGlm
IHRlc3QgLXogJGF4X2N2X2RlYnVnOyB0aGVuIDoKIAotICAgIGF4X2N2X2RlYnVnPSJ5IgogCi1m
aQotZGVidWc9JGF4X2N2X2RlYnVnCiAKIAogCkBAIC00MjQwLDkzMCArMjIyMiw0MzIgQEAgZGVi
dWc9JGF4X2N2X2RlYnVnCiAKIAogCi1mb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKLWRv
Ci0gICAgUFJFUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCi1kb25lCi1mb3IgbGRmbGFnIGluICRQ
UkVQRU5EX0xJQgotZG8KLSAgICBQUkVQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgotZG9uZQot
Zm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMKLWRvCi0gICAgQVBQRU5EX0NGTEFHUys9IiAt
SSRjZmxhZyIKLWRvbmUKLWZvciBsZGZsYWcgaW4gJEFQUEVORF9MSUIKLWRvCi0gICAgQVBQRU5E
X0xERkxBR1MrPSIgLUwkbGRmbGFnIgotZG9uZQotQ0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENG
TEFHUyAkQVBQRU5EX0NGTEFHUyIKLUxERkxBR1M9IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1Mg
JEFQUEVORF9MREZMQUdTIgogCiAKIAogCiAKIAorIyBwa2cubTQgLSBNYWNyb3MgdG8gbG9jYXRl
IGFuZCB1dGlsaXNlIHBrZy1jb25maWcuICAgICAgICAgICAgLSotIEF1dG9jb25mIC0qLQorIyBz
ZXJpYWwgMSAocGtnLWNvbmZpZy0wLjI0KQorIworIyBDb3B5cmlnaHQgwqkgMjAwNCBTY290dCBK
YW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+LgorIworIyBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorIyBp
dCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1
Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lv
biAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJz
aW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBp
dCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2
ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1Mg
Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUKKyMgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg
YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorIyBhbG9uZyB3aXRoIHRo
aXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0
aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgMDIxMTEt
MTMwNywgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3RyaWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQg
b2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBjb25maWd1cmF0aW9uIHNjcmlwdCBnZW5l
cmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVkZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBk
aXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZvciB0aGUgcmVzdCBvZiB0aGF0IHByb2dy
YW0uCiAKKyMgUEtHX1BST0dfUEtHX0NPTkZJRyhbTUlOLVZFUlNJT05dKQorIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBLR19QUk9HX1BLR19DT05GSUcKIAorIyBQS0df
Q0hFQ0tfRVhJU1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1G
T1VORF0pCisjCisjIENoZWNrIHRvIHNlZSB3aGV0aGVyIGEgcGFydGljdWxhciBzZXQgb2YgbW9k
dWxlcyBleGlzdHMuICBTaW1pbGFyCisjIHRvIFBLR19DSEVDS19NT0RVTEVTKCksIGJ1dCBkb2Vz
IG5vdCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9ycy4KKyMKKyMgUGxlYXNlIHJlbWVtYmVy
IHRoYXQgbTQgZXhwYW5kcyBBQ19SRVFVSVJFKFtQS0dfUFJPR19QS0dfQ09ORklHXSkKKyMgb25s
eSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZpZ3VyZS5hYywgc28gaWYgdGhlIGZpcnN0
IHBsYWNlCisjIGl0J3MgY2FsbGVkIG1pZ2h0IGJlIHNraXBwZWQgKHN1Y2ggYXMgaWYgaXQgaXMg
d2l0aGluIGFuICJpZiIsIHlvdQorIyBoYXZlIHRvIGNhbGwgUEtHX0NIRUNLX0VYSVNUUyBtYW51
YWxseQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQogCiAKKyMgX1BLR19DT05GSUcoW1ZBUklBQkxFXSwgW0NPTU1BTkRdLCBb
TU9EVUxFU10pCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorIyBfUEtHX0NPTkZJRwogCisjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQK
IAogCisjIFBLR19DSEVDS19NT0RVTEVTKFZBUklBQkxFLVBSRUZJWCwgTU9EVUxFUywgW0FDVElP
Ti1JRi1GT1VORF0sCisjIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkKKyMKKyMKKyMgTm90ZSB0aGF0
IGlmIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhlIGZpcnN0IGNhbGwgdG8KKyMgUEtHX0NIRUNL
X01PRFVMRVMgbWlnaHQgbm90IGhhcHBlbiwgeW91IHNob3VsZCBiZSBzdXJlIHRvIGluY2x1ZGUg
YW4KKyMgZXhwbGljaXQgY2FsbCB0byBQS0dfUFJPR19QS0dfQ09ORklHIGluIHlvdXIgY29uZmln
dXJlLmFjCisjCisjCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBLR19DSEVDS19NT0RVTEVTCiAKLSMgQ2hlY2tzIGZv
ciBwcm9ncmFtcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0cHV0IiA+JjUKLSRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dC4u
LiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1NFRCtzZXR9IiA9IHNldDsgdGhlbiA6
Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gICAgICAgICAgICBhY19zY3Jp
cHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJiYmJiYmJi
YmJiYmJiYmJiYmJiYmJiYmIvCi0gICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7IGRvCi0g
ICAgICAgYWNfc2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKLSAgICAgZG9uZQot
ICAgICBlY2hvICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0ZXN0LnNl
ZAotICAgICB7IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9Ci0gICAgIGlmIHRlc3QgLXog
IiRTRUQiOyB0aGVuCi0gIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCi0gICMgTG9vcCB0aHJvdWdo
IHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCi0gIGFz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgK
LWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
LSAgICBmb3IgYWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KLSAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgICAgIGFjX3BhdGhfU0VEPSIkYXNf
ZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgotICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9TRUQi
ICYmICRhc190ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKLSMgQ2hlY2sgZm9y
IEdOVSBhY19wYXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgotICAjIENoZWNr
IGZvciBHTlUgJGFjX3BhdGhfU0VECi1jYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNpb24gMj4m
MWAgaW4KLSpHTlUqKQotICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19wYXRoX1NF
RF9mb3VuZD06OzsKLSopCi0gIGFjX2NvdW50PTAKLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4i
Y29uZnRlc3QuaW4iCi0gIHdoaWxlIDoKLSAgZG8KLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29u
ZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgotICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVz
dC5pbiIKLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKLSAgICAkYXNfZWNobyAn
JyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Quc2VkIDwg
ImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKLSAgICBk
aWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFr
Ci0gICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCi0gICAg
aWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCi0gICAgICAj
IEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBv
bmUKLSAgICAgIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCi0gICAgICBhY19wYXRoX1NF
RF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBz
ZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFr
Ci0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNv
bmZ0ZXN0Lm91dDs7Ci1lc2FjCiAKLSAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBicmVhayAz
Ci0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLSAgaWYgdGVzdCAt
eiAiJGFjX2N2X3BhdGhfU0VEIjsgdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRh
YmxlIHNlZCBjb3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1Ci0gIGZpCi1lbHNl
Ci0gIGFjX2N2X3BhdGhfU0VEPSRTRUQKLWZpCiAKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKLSRhc19lY2hv
ICIkYWNfY3ZfcGF0aF9TRUQiID4mNjsgfQotIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgotICBybSAt
ZiBjb25mdGVzdC5zZWQKKyMgV2UgZGVmaW5lLCBzZXBhcmF0ZWx5LCBQVEhSRUFEX0NGTEFHUywg
X0xERkxBR1MgYW5kIF9MSUJTCisjIGV2ZW4gdGhvdWdoIGN1cnJlbnRseSB3ZSBkb24ndCBzZXQg
dGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCisjIFRoaXMgbWVhbnMgdGhhdCB0aGUgbWFrZWZpbGVzIHdp
bGwgbm90IG5lZWQgdG8gY2hhbmdlIGluCisjIHRoZSBmdXR1cmUgaWYgd2UgbWFrZSB0aGUgdGVz
dCBtb3JlIHNvcGhpc3RpY2F0ZWQuCiAKLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdT
JwotYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQg
PiY1JwotYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFH
UyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0k
YWNfY3ZfY19jb21waWxlcl9nbnUKLWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29s
X3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2Mi
Ci0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBk
b25lCi1JRlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRh
c19lY2hvICJubyIgPiY2OyB9Ci1maQogCisjIFdlIGludm9rZSBBWF9QVEhSRUFEX1ZBUlMgd2l0
aCB0aGUgbmFtZSBvZiBhbm90aGVyIG1hY3JvCisjIHdoaWNoIGlzIHRoZW4gZXhwYW5kZWQgb25j
ZSBmb3IgZWFjaCB2YXJpYWJsZS4KIAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsg
dGhlbgotICBhY19jdF9DQz0kQ0MKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2Mi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGdjYzsg
YWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1u
ICIkYWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3Nh
dmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2Mi
Ci0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBk
b25lCi1JRlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKLWlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N0X0NDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQogCi0g
IGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBj
YXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29s
cyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0
IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0g
IGZpCi1lbHNlCi0gIENDPSIkYWNfY3ZfcHJvZ19DQyIKLWZpCiAKLWlmIHRlc3QgLXogIiRDQyI7
IHRoZW4KLSAgICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJl
Zml4fWNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNl
dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCi0gICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4g
IiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hv
ICJubyIgPiY2OyB9Ci1maQogCiAKLSAgZmkKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0k
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0i
JENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLSAgYWNfcHJvZ19y
ZWplY3RlZD1ubwotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFz
X2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
Ci0gICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2Iv
Y2MiOyB0aGVuCi0gICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKLSAgICAgICBjb250aW51ZQot
ICAgICBmaQotICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgotICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4m
NQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwogCi1p
ZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCi0gICMgV2UgZm91bmQgYSBib2dv
biBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KLSAgc2V0IGR1bW15
ICRhY19jdl9wcm9nX0NDCi0gIHNoaWZ0Ci0gIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgotICAgICMg
V2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgotICAgICMg
SG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBj
aG9zZW4KLSAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNl
IHRoZSBmdWxsIGZpbGUgbmFtZS4KLSAgICBzaGlmdAotICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19k
aXIvJGFjX3dvcmQkezErJyAnfSRAIgotICBmaQotZmkKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2df
Q0MKLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVs
c2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9CisjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKKwor
IyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWdpdGh0dHAgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtl
bmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX2dp
dGh0dHA7CiBmaQogCiAKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gIGlmIHRlc3QgLW4g
IiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCi0gIGRvCi0g
ICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJGFjX3Rv
b2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0ND
K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK
LSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lG
UwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJGFjX3Rvb2xfcHJlZml4
JGFjX3Byb2ciCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91
bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQot
ZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRw
IiA9ICJ4bm8iOyB0aGVuIDoKIAotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAt
biAiJENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KLWZpCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKIAorZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICB0ZXN0IC1uICIkQ0MiICYm
IGJyZWFrCi0gIGRvbmUKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gIGFjX2N0X0NDPSRD
QwotICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKLWRvCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgot
c2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19h
Y19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UK
LWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBB
VEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2
X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAg
IGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworICAgIGF4X2N2
X2dpdGh0dHA9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhlbiA6CisKKyAg
ICBheF9jdl9naXRodHRwPSJuIgogCiBmaQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0
X0NDCi1pZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRh
Y19jdF9DQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKK2dpdGh0
dHA9JGF4X2N2X2dpdGh0dHAKIAogCi0gIHRlc3QgLW4gIiRhY19jdF9DQyIgJiYgYnJlYWsKLWRv
bmUKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KLSAgICBDQz0iIgotICBlbHNl
Ci0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikKLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIk
YXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3Qg
dHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwotICAgIENDPSRhY19j
dF9DQwotICBmaQorIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4K
K2lmIHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxl
dmFsPSRlbmFibGVfbW9uaXRvcnM7CiBmaQogCi1maQogCitpZiB0ZXN0ICJ4JGVuYWJsZV9tb25p
dG9ycyIgPSAieG5vIjsgdGhlbiA6CiAKLXRlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0k
YXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJv
ciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAotU2VlIFxgY29u
ZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisgICAgYXhfY3ZfbW9u
aXRvcnM9Im4iCiAKLSMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxl
ci4KLSRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBD
IGNvbXBpbGVyIHZlcnNpb24iID4mNQotc2V0IFggJGFjX2NvbXBpbGUKLWFjX2NvbXBpbGVyPSQy
Ci1mb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCi0gIHsgeyBh
Y190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKLWNhc2UgIigoJGFjX3RyeSIgaW4K
LSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3Ry
eV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8i
OyB9ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVz
dC5lcnIKLSAgYWNfc3RhdHVzPSQ/Ci0gIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCi0g
ICAgc2VkICcxMGFcCi0uLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCi0gICAg
ICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCi0gICAgY2F0IGNvbmZ0ZXN0LmVy
MSA+JjUKLSAgZmkKLSAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgotICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAg
dGVzdCAkYWNfc3RhdHVzID0gMDsgfQotZG9uZQorZWxpZiB0ZXN0ICJ4JGVuYWJsZV9tb25pdG9y
cyIgPSAieHllcyI7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCiAKLWludAotbWFpbiAoKQotewotI2lm
bmRlZiBfX0dOVUNfXwotICAgICAgIGNob2tlIG1lCi0jZW5kaWYKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfbW9uaXRvcnM7IHRoZW4gOgogCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY29tcGlsZXJfZ251PXll
cwotZWxzZQotICBhY19jb21waWxlcl9nbnU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWFjX2N2X2NfY29tcGlsZXJf
Z251PSRhY19jb21waWxlcl9nbnUKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKIAogZmkKLXsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21w
aWxlcl9nbnUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9Ci1p
ZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7IHRoZW4KLSAgR0NDPXllcwotZWxzZQotICBH
Q0M9Ci1maQotYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQotYWNfc2F2ZV9DRkxBR1M9JENG
TEFHUwoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3
aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIg
JENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19nK3Nl
dH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAg
YWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9mbGFnCi0gICBhY19jX3dlcnJvcl9m
bGFnPXllcwotICAgYWNfY3ZfcHJvZ19jY19nPW5vCi0gICBDRkxBR1M9Ii1nIgotICAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworbW9uaXRvcnM9JGF4X2N2X21vbml0b3JzCiAKLWludAotbWFpbiAoKQotewogCi0gIDsK
LSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKLSAgYWNfY3ZfcHJvZ19jY19nPXllcwotZWxzZQotICBDRkxBR1M9IiIKLSAgICAg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KIAotaW50Ci1tYWluICgpCi17CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUt
dnRwbSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV92dHBtK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgZW5hYmxldmFsPSRlbmFibGVfdnRwbTsKK2ZpCiAKLSAgOwotICByZXR1cm4gMDsKLX0K
LV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgogCi1lbHNl
Ci0gIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotCSBDRkxBR1M9Ii1n
IgotCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQg
Y29uZmRlZnMuaC4gICovCitpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoK
IAotaW50Ci1tYWluICgpCi17CisgICAgYXhfY3ZfdnRwbT0ibiIKKworZWxpZiB0ZXN0ICJ4JGVu
YWJsZV92dHBtIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl92dHBtPSJ5IgorCitlbGlm
IHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ibiIKIAotICA7
Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P
IjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0
LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1y
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKLSAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotZmkKLXsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19j
Y19nIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KLWlmIHRlc3QgIiRh
Y190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4KLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwotZWxp
ZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KLSAgaWYgdGVzdCAiJEdDQyIgPSB5
ZXM7IHRoZW4KLSAgICBDRkxBR1M9Ii1nIC1PMiIKLSAgZWxzZQotICAgIENGTEFHUz0iLWciCi0g
IGZpCi1lbHNlCi0gIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItTzIi
Ci0gIGVsc2UKLSAgICBDRkxBR1M9Ci0gIGZpCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4
OSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNP
IEM4OS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNl
dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2N2X3By
b2dfY2NfYzg5PW5vCi1hY19zYXZlX0NDPSRDQwotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGFy
Zy5oPgotI2luY2x1ZGUgPHN0ZGlvLmg+Ci0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVk
ZSA8c3lzL3N0YXQuaD4KLS8qIE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVu
IGZyb20gUkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KLXN0cnVjdCBidWYgeyBpbnQgeDsgfTsK
LUZJTEUgKiAoKnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Ci1z
dGF0aWMgY2hhciAqZSAocCwgaSkKLSAgICAgY2hhciAqKnA7Ci0gICAgIGludCBpOwotewotICBy
ZXR1cm4gcFtpXTsKLX0KLXN0YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50
KSwgY2hhciAqKnAsIC4uLikKLXsKLSAgY2hhciAqczsKLSAgdmFfbGlzdCB2OwotICB2YV9zdGFy
dCAodixwKTsKLSAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKLSAgdmFfZW5kICh2KTsKLSAg
cmV0dXJuIHM7Ci19Cit2dHBtPSRheF9jdl92dHBtCiAKLS8qIE9TRiA0LjAgQ29tcGFxIGNjIGlz
IHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQgaGFzCi0gICBmdW5jdGlv
biBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhISCcgaGV4IGNoYXJhY3RlciBjb25z
dGFudHMuCi0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVuZm9ydHVuYXRlbHksIGlu
c3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKLSAgIGFzICd4Jy4gIFRoZSBmb2xsb3dpbmcgaW5k
dWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQKLSAgIHByb3BlciBBTlNJ
IG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlzIGNvbWVzIG91dCB0cnVlLCBmb3Ig
YW4KLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vzc2FyeSB0byB3cml0ZSAnXHgw
MCc9PTAgdG8gZ2V0IHNvbWV0aGluZwotICAgdGhhdCdzIHRydWUgb25seSB3aXRoIC1zdGQuICAq
LwotaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8gMSA6IC0xXTsKIAotLyogSUJNIEMg
NiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQsIGJ1dCBpdCByZXBsYWNlcyBtYWNy
byBwYXJhbWV0ZXJzCi0gICBpbnNpZGUgc3RyaW5ncyBhbmQgY2hhcmFjdGVyIGNvbnN0YW50cy4g
ICovCi0jZGVmaW5lIEZPTyh4KSAneCcKLWludCB4bGM2X2NjX2FycmF5W0ZPTyhhKSA9PSAneCcg
PyAxIDogLTFdOwogCi1pbnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsKLXN0cnVjdCBzMSB7aW50
ICgqZikgKGludCBhKTt9Owotc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91YmxlIGEpO307Ci1pbnQg
cGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVjdCBz
dGF0ICosIGludCksIGludCwgaW50KTsKLWludCBhcmdjOwotY2hhciAqKmFyZ3Y7Ci1pbnQKLW1h
aW4gKCkKLXsKLXJldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwgYXJn
diwgMSkgIT0gYXJndlsxXTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotZm9yIGFjX2Fy
ZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1hbnNpIC1zdGQgXAotCS1BZSAiLUFh
IC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05TX18iCi1kbwotICBDQz0iJGFjX3Nh
dmVfQ0MgJGFjX2FyZyIKLSAgaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUt
eGVuYXBpIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3hlbmFwaStzZXR9IiA9IHNldDsg
dGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hlbmFwaTsKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0Ci0gIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODki
ICE9ICJ4bm8iICYmIGJyZWFrCi1kb25lCi1ybSAtZiBjb25mdGVzdC4kYWNfZXh0Ci1DQz0kYWNf
c2F2ZV9DQworCisKK2lmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6CisK
KyAgICBheF9jdl94ZW5hcGk9Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGVuYXBpIiA9ICJ4
eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl94ZW5hcGk9InkiCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfeGVuYXBpOyB0aGVuIDoKKworICAgIGF4X2N2X3hlbmFwaT0ibiIKIAogZmkKLSMgQUNfQ0FD
SEVfVkFMCi1jYXNlICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiBpbgotICB4KQotICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1
Ci0kYXNfZWNobyAibm9uZSBuZWVkZWQiID4mNjsgfSA7OwotICB4bm8pCi0gICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUK
LSRhc19lY2hvICJ1bnN1cHBvcnRlZCIgPiY2OyB9IDs7Ci0gICopCi0gICAgQ0M9IiRDQyAkYWNf
Y3ZfcHJvZ19jY19jODkiCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2M4OSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3By
b2dfY2NfYzg5IiA+JjY7IH0gOzsKLWVzYWMKLWlmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODki
ICE9IHhubzsgdGhlbiA6Cit4ZW5hcGk9JGF4X2N2X3hlbmFwaQorCiAKKworIyBDaGVjayB3aGV0
aGVyIC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3B5
dGhvbnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcHl0aG9u
dG9vbHM7CiBmaQogCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBp
bGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xp
bms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1Mg
Y29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29t
cGlsZXJfZ251CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0
aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9Ci1MTl9TPSRhc19sbl9zCi1pZiB0ZXN0ICIkTE5f
UyIgPSAibG4gLXMiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIgPiY2OyB9Ci1lbHNlCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubywgdXNpbmcg
JExOX1MiID4mNQotJGFzX2VjaG8gIm5vLCB1c2luZyAkTE5fUyIgPiY2OyB9CitpZiB0ZXN0ICJ4
JGVuYWJsZV9weXRob250b29scyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9weXRob250
b29scz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9weXRob250b29scyIgPSAieHllcyI7IHRo
ZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zf
cHl0aG9udG9vbHM7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9InkiCisKIGZpCitw
eXRob250b29scz0kYXhfY3ZfcHl0aG9udG9vbHMKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1B
S0UpIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMg
XCQoTUFLRSkuLi4gIiA+JjY7IH0KLXNldCB4ICR7TUFLRS1tYWtlfQotYWNfbWFrZT1gJGFzX2Vj
aG8gIiQyIiB8IHNlZCAncy8rL3AvZzsgcy9bXmEtekEtWjAtOV9dL18vZydgCi1pZiBldmFsICJ0
ZXN0IFwiXCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0K3NldH1cIiIgPSBzZXQ7IHRo
ZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgPmNvbmZ0ZXN0
Lm1ha2UgPDxcX0FDRU9GCi1TSEVMTCA9IC9iaW4vc2gKLWFsbDoKLQlAZWNobyAnQEBAJSUlPSQo
TUFLRSk9QEBAJSUlJwotX0FDRU9GCi0jIEdOVSBtYWtlIHNvbWV0aW1lcyBwcmludHMgIm1ha2Vb
MV06IEVudGVyaW5nIC4uLiIsIHdoaWNoIHdvdWxkIGNvbmZ1c2UgdXMuCi1jYXNlIGAke01BS0Ut
bWFrZX0gLWYgY29uZnRlc3QubWFrZSAyPi9kZXYvbnVsbGAgaW4KLSAgKkBAQCUlJT0/Kj1AQEAl
JSUqKQotICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PXllczs7Ci0gICop
Ci0gICAgZXZhbCBhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQ9bm87OwotZXNhYwotcm0g
LWYgY29uZnRlc3QubWFrZQorCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xz
IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX29jYW1sdG9vbHMrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xzOwogZmkKLWlmIGV2YWwgdGVzdCBc
JGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCA9IHllczsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hv
ICJ5ZXMiID4mNjsgfQotICBTRVRfTUFLRT0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9
Ci0gIFNFVF9NQUtFPSJNQUtFPSR7TUFLRS1tYWtlfSIKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9v
Y2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9vbHM9Im4iCisK
K2VsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgorCisgICAg
YXhfY3Zfb2NhbWx0b29scz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9vY2FtbHRvb2xzOyB0
aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCisKIGZpCitvY2FtbHRvb2xzPSRheF9j
dl9vY2FtbHRvb2xzCiAKLSMgRmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVy
IGEgQyBwcm9ncmFtIChmYXN0ZXIpLAotIyBzbyBvbmUgc2NyaXB0IGlzIGFzIGdvb2QgYXMgYW5v
dGhlci4gIEJ1dCBhdm9pZCB0aGUgYnJva2VuIG9yCi0jIGluY29tcGF0aWJsZSB2ZXJzaW9uczoK
LSMgU3lzViAvZXRjL2luc3RhbGwsIC91c3Ivc2Jpbi9pbnN0YWxsCi0jIFN1bk9TIC91c3IvZXRj
L2luc3RhbGwKLSMgSVJJWCAvc2Jpbi9pbnN0YWxsCi0jIEFJWCAvYmluL2luc3RhbGwKLSMgQW1p
Z2FPUyAvQy9pbnN0YWxsLCB3aGljaCBpbnN0YWxscyBib290YmxvY2tzIG9uIGZsb3BweSBkaXNj
cwotIyBBSVggNCAvdXNyL2Jpbi9pbnN0YWxsYnNkLCB3aGljaCBkb2Vzbid0IHdvcmsgd2l0aG91
dCBhIC1nIGZsYWcKLSMgQUZTIC91c3IvYWZzd3MvYmluL2luc3RhbGwsIHdoaWNoIG1pc2hhbmRs
ZXMgbm9uZXhpc3RlbnQgYXJncwotIyBTVlI0IC91c3IvdWNiL2luc3RhbGwsIHdoaWNoIHRyaWVz
IHRvIHVzZSB0aGUgbm9uZXhpc3RlbnQgZ3JvdXAgInN0YWZmIgotIyBPUy8yJ3Mgc3lzdGVtIGlu
c3RhbGwsIHdoaWNoIGhhcyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHNlbWFudGljCi0jIC4vaW5z
dGFsbCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNyZWF0ZWQgYnkgbWFrZSBmcm9tIC4vaW5z
dGFsbC5zaC4KLSMgUmVqZWN0IGluc3RhbGwgcHJvZ3JhbXMgdGhhdCBjYW5ub3QgaW5zdGFsbCBt
dWx0aXBsZSBmaWxlcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbCIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsLi4uICIgPiY2OyB9Ci1pZiB0ZXN0
IC16ICIkSU5TVEFMTCI7IHRoZW4KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9pbnN0YWxsK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAot
ZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgot
ICAgICMgQWNjb3VudCBmb3IgcGVvcGxlIHdobyBwdXQgdHJhaWxpbmcgc2xhc2hlcyBpbiBQQVRI
IGVsZW1lbnRzLgotY2FzZSAkYXNfZGlyLyBpbiAjKCgKLSAgLi8gfCAuLy8gfCAvW2NDXS8qIHwg
XAotICAvZXRjLyogfCAvdXNyL3NiaW4vKiB8IC91c3IvZXRjLyogfCAvc2Jpbi8qIHwgL3Vzci9h
ZnN3cy9iaW4vKiB8IFwKLSAgPzpbXFwvXW9zMltcXC9daW5zdGFsbFtcXC9dKiB8ID86W1xcL11P
UzJbXFwvXUlOU1RBTExbXFwvXSogfCBcCi0gIC91c3IvdWNiLyogKSA7OwotICAqKQotICAgICMg
T1NGMSBhbmQgU0NPIE9EVCAzLjAgaGF2ZSB0aGVpciBvd24gbmFtZXMgZm9yIGluc3RhbGwuCi0g
ICAgIyBEb24ndCB1c2UgaW5zdGFsbGJzZCBmcm9tIE9TRiBzaW5jZSBpdCBpbnN0YWxscyBzdHVm
ZiBhcyByb290Ci0gICAgIyBieSBkZWZhdWx0LgotICAgIGZvciBhY19wcm9nIGluIGdpbnN0YWxs
IHNjb2luc3QgaW5zdGFsbDsgZG8KLSAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotCWlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCI7
IH07IHRoZW4KLQkgIGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCi0JICAgIGdyZXAgZHNw
bXNnICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4K
LQkgICAgIyBBSVggaW5zdGFsbC4gIEl0IGhhcyBhbiBpbmNvbXBhdGlibGUgY2FsbGluZyBjb252
ZW50aW9uLgotCSAgICA6Ci0JICBlbGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCi0JICAg
IGdyZXAgcHdwbHVzICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+
JjE7IHRoZW4KLQkgICAgIyBwcm9ncmFtLXNwZWNpZmljIGluc3RhbGwgc2NyaXB0IHVzZWQgYnkg
SFAgcHdwbHVzLS1kb24ndCB1c2UuCi0JICAgIDoKLQkgIGVsc2UKLQkgICAgcm0gLXJmIGNvbmZ0
ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRlc3QuZGlyCi0JICAgIGVjaG8gb25lID4gY29uZnRl
c3Qub25lCi0JICAgIGVjaG8gdHdvID4gY29uZnRlc3QudHdvCi0JICAgIG1rZGlyIGNvbmZ0ZXN0
LmRpcgotCSAgICBpZiAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgLWMgY29uZnRlc3Qu
b25lIGNvbmZ0ZXN0LnR3byAiYHB3ZGAvY29uZnRlc3QuZGlyIiAmJgotCSAgICAgIHRlc3QgLXMg
Y29uZnRlc3Qub25lICYmIHRlc3QgLXMgY29uZnRlc3QudHdvICYmCi0JICAgICAgdGVzdCAtcyBj
b25mdGVzdC5kaXIvY29uZnRlc3Qub25lICYmCi0JICAgICAgdGVzdCAtcyBjb25mdGVzdC5kaXIv
Y29uZnRlc3QudHdvCi0JICAgIHRoZW4KLQkgICAgICBhY19jdl9wYXRoX2luc3RhbGw9IiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQgLWMiCi0JICAgICAgYnJlYWsgMwotCSAgICBmaQotCSAg
ZmkKLQlmaQotICAgICAgZG9uZQotICAgIGRvbmUKLSAgICA7OwotZXNhYwogCi0gIGRvbmUKLUlG
Uz0kYXNfc2F2ZV9JRlMKIAotcm0gLXJmIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRl
c3QuZGlyCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgoraWYg
dGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9
JGVuYWJsZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0g
InhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbWluaXRlcm09Im4iCisKK2VsaWYgdGVzdCAieCRl
bmFibGVfbWluaXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5
IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAgIGF4X2N2X21p
bml0ZXJtPSJuIgogCiBmaQotICBpZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9
IHNldDsgdGhlbgotICAgIElOU1RBTEw9JGFjX2N2X3BhdGhfaW5zdGFsbAotICBlbHNlCi0gICAg
IyBBcyBhIGxhc3QgcmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2Fj
aGUgYQotICAgICMgdmFsdWUgZm9yIElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwg
YmVjYXVzZSB0aGF0IHdpbGwKLSAgICAjIGJyZWFrIG90aGVyIHBhY2thZ2VzIHVzaW5nIHRoZSBj
YWNoZSBpZiB0aGF0IGRpcmVjdG9yeSBpcwotICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVl
IGlzIGEgcmVsYXRpdmUgbmFtZS4KLSAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCi0gIGZpCitt
aW5pdGVybT0kYXhfY3ZfbWluaXRlcm0KKworCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1s
b21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0fSIgPSBzZXQ7
IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OwogZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSU5TVEFMTCIgPiY1Ci0kYXNfZWNo
byAiJElOU1RBTEwiID4mNjsgfQogCi0jIFVzZSB0ZXN0IC16IGJlY2F1c2UgU3VuT1M0IHNoIG1p
c2hhbmRsZXMgYnJhY2VzIGluICR7dmFyLXZhbH0uCi0jIEl0IHRoaW5rcyB0aGUgZmlyc3QgY2xv
c2UgYnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgotdGVzdCAteiAiJElOU1RB
TExfUFJPR1JBTSIgJiYgSU5TVEFMTF9QUk9HUkFNPScke0lOU1RBTEx9JwogCi10ZXN0IC16ICIk
SU5TVEFMTF9TQ1JJUFQiICYmIElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworaWYgdGVzdCAi
eCRlbmFibGVfbG9tb3VudCIgPSAieG5vIjsgdGhlbiA6CiAKLXRlc3QgLXogIiRJTlNUQUxMX0RB
VEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisgICAgYXhfY3ZfbG9tb3Vu
dD0ibiIKIAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiaXNvbiIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgYmlzb247IGFjX3dvcmQ9JDIK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0JJU09OK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2FzZSAkQklTT04gaW4KLSAgW1xcL10q
IHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElG
Uz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfQklTT049
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitlbGlm
IHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X2xv
bW91bnQ9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbG9tb3VudDsgdGhlbiA6CisKKyAgICBh
eF9jdl9sb21vdW50PSJuIgogCi0gIDs7Ci1lc2FjCiBmaQotQklTT049JGFjX2N2X3BhdGhfQklT
T04KLWlmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1Ci0kYXNfZWNobyAiJEJJU09OIiA+
JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Citsb21vdW50PSRheF9jdl9sb21v
dW50CisKKworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb3ZtZiB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9vdm1mK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfb3ZtZjsKIGZpCiAKIAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJmbGV4Iiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBmbGV4OyBhY193
b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9GTEVYK3NldH0iID0gc2V0OyB0aGVuIDoK
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2FzZSAkRkxFWCBpbgotICBb
XFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0g
IElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfRkxF
WD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKK2lm
IHRlc3QgIngkZW5hYmxlX292bWYiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3Zfb3ZtZj0i
biIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBh
eF9jdl9vdm1mPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X292bWY7IHRoZW4gOgorCisgICAg
YXhfY3Zfb3ZtZj0ibiIKIAotICA7OwotZXNhYwogZmkKLUZMRVg9JGFjX2N2X3BhdGhfRkxFWAot
aWYgdGVzdCAtbiAiJEZMRVgiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkRkxFWCIgPiY1Ci0kYXNfZWNobyAiJEZMRVgiID4mNjsgfQot
ZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KK292bWY9JGF4X2N2X292bWYKKworCisKKyMg
Q2hlY2sgd2hldGhlciAtLWVuYWJsZS1yb21iaW9zIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5h
YmxlX3JvbWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9yb21i
aW9zOwogZmkKIAogCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBlcmwiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IHBlcmw7IGFjX3dvcmQ9
JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1BFUkwrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXNlICRQRVJMIGluCi0gIFtcXC9d
KiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX1BFUkw9IiRQRVJMIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZT
PSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9QRVJMPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot
ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworaWYgdGVz
dCAieCRlbmFibGVfcm9tYmlvcyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9yb21iaW9z
PSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3JvbWJpb3MiID0gInh5ZXMiOyB0aGVuIDoKKwor
ICAgIGF4X2N2X3JvbWJpb3M9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfcm9tYmlvczsgdGhl
biA6CisKKyAgICBheF9jdl9yb21iaW9zPSJ5IgogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1BF
UkwiICYmIGFjX2N2X3BhdGhfUEVSTD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotUEVSTD0kYWNfY3Zf
cGF0aF9QRVJMCi1pZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQRVJMIiA+JjUKLSRhc19lY2hvICIkUEVS
TCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorcm9tYmlvcz0kYXhfY3Zf
cm9tYmlvcworCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXNlYWJpb3Mgd2FzIGdpdmVu
LgoraWYgdGVzdCAiJHtlbmFibGVfc2VhYmlvcytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJs
ZXZhbD0kZW5hYmxlX3NlYWJpb3M7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3NlYWJpb3Mi
ID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3Zfc2VhYmlvcz0ibiIKKworZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9zZWFiaW9zIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9zZWFiaW9zPSJ5
IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3NlYWJpb3M7IHRoZW4gOgorCisgICAgYXhfY3Zfc2Vh
Ymlvcz0ieSIKKworZmkKK3NlYWJpb3M9JGF4X2N2X3NlYWJpb3MKKworCisKKyMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9kZWJ1Zytz
ZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX2RlYnVnOworZmkKKworCitp
ZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9kZWJ1
Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieHllcyI7IHRoZW4gOgorCisg
ICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfZGVidWc7IHRoZW4gOgor
CisgICAgYXhfY3ZfZGVidWc9InkiCisKIGZpCitkZWJ1Zz0kYXhfY3ZfZGVidWcKKworCisKKwor
CisKKworCitmb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKK2RvCisgICAgUFJFUEVORF9D
RkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRQUkVQRU5EX0xJQgorZG8K
KyAgICBQUkVQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorZm9yIGNmbGFnIGluICRB
UFBFTkRfSU5DTFVERVMKK2RvCisgICAgQVBQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUK
K2ZvciBsZGZsYWcgaW4gJEFQUEVORF9MSUIKK2RvCisgICAgQVBQRU5EX0xERkxBR1MrPSIgLUwk
bGRmbGFnIgorZG9uZQorQ0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENGTEFHUyAkQVBQRU5EX0NG
TEFHUyIKK0xERkxBR1M9IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdT
IgorCisKIAogCi1pZiB0ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3RhbGwgcGVybCIgIiRMSU5F
Tk8iIDUKLWZpCi1pZiB0ZXN0ICJ4JHhhcGkiID0gInh5IjsgdGhlbiA6CiAKLSAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImN1cmwtY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgorCisK
KworCisKKworCisKKworIyBDaGVja3MgZm9yIHByb2dyYW1zLgorYWNfZXh0PWMKK2FjX2NwcD0n
JENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29u
ZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRD
RkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNf
Y29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xf
cHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9w
cmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBk
dW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3BhdGhfQ1VSTCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mr
c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot
ICBjYXNlICRDVVJMIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0NVUkw9
IiRDVVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAg
OzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRh
Y19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0NVUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2MiCiAgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTE3MSw0NCArMjY1
NSwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9wYXRoX0NVUkw9Im5vIgotICA7OwotZXNhYwogZmkKLUNV
Ukw9JGFjX2N2X3BhdGhfQ1VSTAotaWYgdGVzdCAtbiAiJENVUkwiOyB0aGVuCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Ci0kYXNf
ZWNobyAiJENVUkwiID4mNjsgfQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAi
bm8iID4mNjsgfQogZmkKIAogCi1pZiB0ZXN0IHgiJHtDVVJMfSIgPT0geCJubyIKLXRoZW4KLSAg
ICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgY3VybC1jb25maWcsIHBsZWFzZSBpbnN0
YWxsIGN1cmwtY29uZmlnIiAiJExJTkVOTyIgNQogZmkKLSAgICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgInhtbDItY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KLXNldCBkdW1teSB4bWwyLWNvbmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFj
X2N2X3Byb2dfQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgZ2NjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YTUwrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0g
c2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAk
WE1MIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX1hNTD0iJFhNTCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0g
IGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJGFj
X2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lG
UwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9YTUw9IiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgogICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUyMTYsMzkgKzI2OTUsNDMg
QEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfWE1MIiAmJiBhY19jdl9wYXRoX1hNTD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotWE1MPSRhY19j
dl9wYXRoX1hNTAotaWYgdGVzdCAtbiAiJFhNTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYTUwiID4mNQotJGFzX2VjaG8gIiRYTUwi
ID4mNjsgfQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9CiBl
bHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotCi1pZiB0ZXN0IHgiJHtYTUx9IiA9
PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4bWwyLWNv
bmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElORU5PIiA1Ci1maQotCisgIGlm
IHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNl
ICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZp
CitlbHNlCisgIENDPSIkYWNfY3ZfcHJvZ19DQyIKIGZpCi1pZiB0ZXN0ICJ4JG9jYW1sdG9vbHMi
ID0gInh5IjsgdGhlbiA6CiAKLSAgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYwotICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGMiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjOyBhY193b3JkPSQy
CitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xf
cHJlZml4IjsgdGhlbgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1jYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3Byb2dfT0NBTUxDK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19D
QytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl
Ci0gIGlmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NB
TUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0LgogZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9y
IGFzX2RpciBpbiAkUEFUSApAQCAtNTI1Nyw3ICsyNzQwLDcgQEAgZG8KICAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIKKyAg
ICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgogICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUyNjcsMjkgKzI3NTAsMzAgQEAgSUZTPSRh
c19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKLWlmIHRlc3Qg
LW4gIiRPQ0FNTEMiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+JjUKLSRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK0ND
PSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRD
QyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCisgIGZpCiBm
aQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgotICBhY19jdF9PQ0FNTEM9
JE9DQU1MQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxjOyBhY193b3Jk
PSQyCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
IGNjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0
aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9IiRhY19jdF9P
Q0FNTEMiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCiBlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCkBAIC01Mjk3LDcg
KzI3ODEsMTEgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxDPSJvY2FtbGMiCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAg
ICAgICBjb250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgogICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUzMDUsNjEgKzI3OTMsNDQg
QEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKK2lmIHRlc3QgJGFjX3Byb2dfcmVq
ZWN0ZWQgPSB5ZXM7IHRoZW4KKyAgIyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBt
YWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0LgorICBzZXQgZHVtbXkgJGFjX2N2X3Byb2dfQ0MKKyAg
c2hpZnQKKyAgaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVu
dCBjb21waWxlciBmcm9tIHRoZSBib2d1cyBvbmUuCisgICAgIyBIb3dldmVyLCBpdCBoYXMgdGhl
IHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxsIGJlIGNob3NlbgorICAgICMgZmlyc3Qg
aWYgd2Ugc2V0IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1l
LgorICAgIHNoaWZ0CisgICAgYWNfY3ZfcHJvZ19DQz0iJGFzX2Rpci8kYWNfd29yZCR7MSsnICd9
JEAiCisgIGZpCiBmaQogZmkKLWFjX2N0X09DQU1MQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMK
LWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxDIiA+JjUKLSRhc19lY2hv
ICIkYWNfY3RfT0NBTUxDIiA+JjY7IH0KK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAt
biAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQogICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEMiID0geDsgdGhl
bgotICAgIE9DQU1MQz0ibm8iCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFj
X3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9v
bHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9
eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMKLSAgZmkKLWVsc2UKLSAgT0NB
TUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMiCi1maQotCi0KLSAgaWYgdGVzdCAiJE9DQU1MQyIgIT0g
Im5vIjsgdGhlbgotICAgICBPQ0FNTFZFUlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8
Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKLSAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIg
PiY1Ci0kYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjY7IH0KLSAg
ICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAotICAgICBpZiB0ZXN0ICIkT0NBTUxMSUIi
ID0gIiI7IHRoZW4KLSAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rldi9udWxs
IHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRgCi0gICAgIGVsc2UKLSAgICAg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DQU1M
TElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY1Ci0kYXNfZWNobyAiT0NBTUxM
SUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7IH0KLSAgICAgZmkKLSAgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIGxp
YnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQotJGFzX2VjaG8gIk9DYW1sIGxpYnJhcnkgcGF0
aCBpcyAkT0NBTUxMSUIiID4mNjsgfQotCi0KIAotCi0gICAgICMgY2hlY2tpbmcgZm9yIG9jYW1s
b3B0Ci0gICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Iiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4
fW9jYW1sb3B0OyBhY193b3JkPSQyCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBpZiB0
ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNsLmV4ZQor
ICBkbworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFj
X3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
ICRhY190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
cHJvZ19PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2df
Q0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxPUFQ9
IiRPQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKIGZvciBhc19kaXIgaW4gJFBBVEgKQEAgLTUzNjgsNyArMjgzOSw3IEBAIGRvCiAgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0IgorICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZpeCRhY19wcm9nIgogICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUzNzgsMjggKzI4
NDksMzIgQEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MT1BUPSRhY19jdl9wcm9n
X09DQU1MT1BUCi1pZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxPUFQiID4mNQotJGFzX2Vj
aG8gIiRPQ0FNTE9QVCIgPiY2OyB9CitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5v
IiA+JjY7IH0KIGZpCiAKIAorICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKKyAgZG9uZQogZmkK
LWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BUIjsgdGhlbgotICBhY19jdF9PQ0FNTE9Q
VD0kT0NBTUxPUFQKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxvcHQ7
IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZv
ciBhY19wcm9nIGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
YWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgJGFjX3Byb2c7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09D
QU1MT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9D
QytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl
Ci0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KKyAgaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQog
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFU
SApAQCAtNTQwOCw3ICsyODgzLDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19wcm9nIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkK
QEAgLTU0MTYsMTkgKzI4OTEsMjMgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAK
LWZpCi1maQotYWNfY3RfT0NBTUxPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQKLWlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE9QVCIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N0X09DQU1MT1BUIiA+JjY7IH0KK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAi
JGFjX2N0X0NDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0g
IGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFQiID0geDsgdGhlbgotICAgIE9DQU1MT1BUPSJubyIK
KworICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCitkb25lCisKKyAgaWYgdGVzdCAieCRh
Y19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKICAgZWxzZQogICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KIHllczopCkBAIC01NDM2LDM5NiArMjkxNSw2NDkg
QEAgeWVzOikKICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7
OwogZXNhYwotICAgIE9DQU1MT1BUPSRhY19jdF9PQ0FNTE9QVAorICAgIENDPSRhY19jdF9DQwog
ICBmaQotZWxzZQotICBPQ0FNTE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFQiCiBmaQogCi0gICAg
IE9DQU1MQkVTVD1ieXRlCi0gICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCi0J
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBDYW5ub3Qg
ZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mNQotJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0
aW9uIG9ubHkuIiA+JjI7fQotICAgICBlbHNlCi0JVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAotCWlmIHRlc3QgIiRUTVBW
RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCi0JICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2Nh
bWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKLSRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJz
IGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KLQkgICAgT0NBTUxPUFQ9
bm8KLQllbHNlCi0JICAgIE9DQU1MQkVTVD1vcHQKK2ZpCisKKwordGVzdCAteiAiJENDIiAmJiB7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFj
X3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KK2FzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQ
QVRICitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0K
KworIyBQcm92aWRlIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgorJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIg
dmVyc2lvbiIgPiY1CitzZXQgWCAkYWNfY29tcGlsZQorYWNfY29tcGlsZXI9JDIKK2ZvciBhY19v
cHRpb24gaW4gLS12ZXJzaW9uIC12IC1WIC1xdmVyc2lvbjsgZG8KKyAgeyB7IGFjX3RyeT0iJGFj
X2NvbXBpbGVyICRhY19vcHRpb24gPiY1IgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwg
KlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFj
X3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cisg
IChldmFsICIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgorICBh
Y19zdGF0dXM9JD8KKyAgaWYgdGVzdCAtcyBjb25mdGVzdC5lcnI7IHRoZW4KKyAgICBzZWQgJzEw
YVwKKy4uLiByZXN0IG9mIHN0ZGVyciBvdXRwdXQgZGVsZXRlZCAuLi4KKyAgICAgICAgIDEwcScg
Y29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICBm
aQorICBybSAtZiBjb25mdGVzdC5lcjEgY29uZnRlc3QuZXJyCisgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9Citkb25lCisKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAg
OworICByZXR1cm4gMDsKK30KK19BQ0VPRgorYWNfY2xlYW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5f
ZmlsZXMKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5fZmlsZXMgYS5vdXQgYS5vdXQuZFNZTSBh
LmV4ZSBiLm91dCIKKyMgVHJ5IHRvIGNyZWF0ZSBhbiBleGVjdXRhYmxlIHdpdGhvdXQgLW8gZmly
c3QsIGRpc3JlZ2FyZCBhLm91dC4KKyMgSXQgd2lsbCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBj
b21waWxlcnMsIGFuZCBmaW5kaW5nIG91dCBhbiBpbnR1aXRpb24KKyMgb2YgZXhlZXh0LgoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRo
ZSBDIGNvbXBpbGVyIHdvcmtzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhl
IEMgY29tcGlsZXIgd29ya3MuLi4gIiA+JjY7IH0KK2FjX2xpbmtfZGVmYXVsdD1gJGFzX2VjaG8g
IiRhY19saW5rIiB8IHNlZCAncy8gLW8gKmNvbmZ0ZXN0W14gXSovLydgCisKKyMgVGhlIHBvc3Np
YmxlIG91dHB1dCBmaWxlczoKK2FjX2ZpbGVzPSJhLm91dCBjb25mdGVzdC5leGUgY29uZnRlc3Qg
YS5leGUgYV9vdXQuZXhlIGIub3V0IGNvbmZ0ZXN0LioiCisKK2FjX3JtZmlsZXM9Citmb3IgYWNf
ZmlsZSBpbiAkYWNfZmlsZXMKK2RvCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQg
fCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8
ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7CisgICAgKiApIGFjX3Jt
ZmlsZXM9IiRhY19ybWZpbGVzICRhY19maWxlIjs7CisgIGVzYWMKK2RvbmUKK3JtIC1mICRhY19y
bWZpbGVzCisKK2lmIHsgeyBhY190cnk9IiRhY19saW5rX2RlZmF1bHQiCitjYXNlICIoKCRhY190
cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAq
KSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3Ry
eV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rX2RlZmF1bHQiKSAyPiY1CisgIGFjX3N0
YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6CisgICMgQXV0
b2NvbmYtMi4xMyBjb3VsZCBzZXQgdGhlIGFjX2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgor
IyBTbyBpZ25vcmUgYSB2YWx1ZSBvZiBgbm8nLCBvdGhlcndpc2UgdGhpcyB3b3VsZCBsZWFkIHRv
IGBFWEVFWFQgPSBubycKKyMgaW4gYSBNYWtlZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUg
YWNfY3ZfZXhlZXh0IGlmIGl0IHdhcyBjYWNoZWQsCisjIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNo
b3J0LWNpcmN1aXQgdGhpcyB0ZXN0IGZvciBjb21waWxlcnMgdW5rbm93biB0bworIyBBdXRvY29u
Zi4KK2ZvciBhY19maWxlIGluICRhY19maWxlcyAnJworZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUi
IHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2Zm
IHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwg
Ki5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApCisJOzsKKyAgICBbYWJdLm91dCApCisJIyBX
ZSBmb3VuZCB0aGUgZGVmYXVsdCBleGVjdXRhYmxlLCBidXQgZXhlZXh0PScnIGlzIG1vc3QKKwkj
IGNlcnRhaW5seSByaWdodC4KKwlicmVhazs7CisgICAgKi4qICkKKwlpZiB0ZXN0ICIke2FjX2N2
X2V4ZWV4dCtzZXR9IiA9IHNldCAmJiB0ZXN0ICIkYWNfY3ZfZXhlZXh0IiAhPSBubzsKKwl0aGVu
IDo7IGVsc2UKKwkgICBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4u
KlwpJ2AKIAlmaQotICAgICBmaQorCSMgV2Ugc2V0IGFjX2N2X2V4ZWV4dCBoZXJlIGJlY2F1c2Ug
dGhlIGxhdGVyIHRlc3QgZm9yIGl0IGlzIG5vdAorCSMgc2FmZTogY3Jvc3MgY29tcGlsZXJzIG1h
eSBub3QgYWRkIHRoZSBzdWZmaXggaWYgZ2l2ZW4gYW4gYC1vJworCSMgYXJndW1lbnQsIHNvIHdl
IG1heSBuZWVkIHRvIGtub3cgaXQgYXQgdGhhdCBwb2ludCBhbHJlYWR5LgorCSMgRXZlbiBpZiB0
aGlzIHNlY3Rpb24gbG9va3MgY3J1ZnR5OiBpdCBoYXMgdGhlIGFkdmFudGFnZSBvZgorCSMgYWN0
dWFsbHkgd29ya2luZy4KKwlicmVhazs7CisgICAgKiApCisJYnJlYWs7OworICBlc2FjCitkb25l
Cit0ZXN0ICIkYWNfY3ZfZXhlZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KKworZWxzZQorICBh
Y19maWxlPScnCitmaQoraWYgdGVzdCAteiAiJGFjX2ZpbGUiOyB0aGVuIDoKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CiskYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUK
K3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworeyB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciA3
NyAiQyBjb21waWxlciBjYW5ub3QgY3JlYXRlIGV4ZWN1dGFibGVzCitTZWUgXGBjb25maWcubG9n
JyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAi
eWVzIiA+JjY7IH0KK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZSIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5h
bWUuLi4gIiA+JjY7IH0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFjX2ZpbGUiID4mNjsgfQorYWNfZXhl
ZXh0PSRhY19jdl9leGVleHQKKworcm0gLWYgLXIgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25m
dGVzdCRhY19jdl9leGVleHQgYi5vdXQKK2FjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19z
YXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBzdWZmaXggb2YgZXhlY3V0YWJsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1
ZmZpeCBvZiBleGVjdXRhYmxlcy4uLiAiID4mNjsgfQoraWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsi
CitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89
XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5
X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCisk
YXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQor
ICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
XCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgor
ICAjIElmIGJvdGggYGNvbmZ0ZXN0LmV4ZScgYW5kIGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAo
d2VsbCwgb2JzZXJ2YWJsZSkKKyMgY2F0Y2ggYGNvbmZ0ZXN0LmV4ZScuICBGb3IgaW5zdGFuY2Ug
d2l0aCBDeWd3aW4sIGBscyBjb25mdGVzdCcgd2lsbAorIyB3b3JrIHByb3Blcmx5IChpLmUuLCBy
ZWZlciB0byBgY29uZnRlc3QuZXhlJyksIHdoaWxlIGl0IHdvbid0IHdpdGgKKyMgYHJtJy4KK2Zv
ciBhY19maWxlIGluIGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBjb25mdGVzdC4qOyBkbworICB0ZXN0
IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFj
X2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICou
YmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKKyAgICAqLiog
KSBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKKwkgIGJy
ZWFrOzsKKyAgICAqICkgYnJlYWs7OworICBlc2FjCitkb25lCitlbHNlCisgIHsgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5f
ZXJyb3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBleGVjdXRhYmxlczogY2Fubm90IGNv
bXBpbGUgYW5kIGxpbmsKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElO
RU5PIiA1IDsgfQorZmkKK3JtIC1mIGNvbmZ0ZXN0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dAoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9leGVl
eHQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9leGVleHQiID4mNjsgfQogCitybSAtZiBjb25mdGVz
dC4kYWNfZXh0CitFWEVFWFQ9JGFjX2N2X2V4ZWV4dAorYWNfZXhlZXh0PSRFWEVFWFQKK2NhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKyNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgpCit7CitGSUxFICpmID0gZm9w
ZW4gKCJjb25mdGVzdC5vdXQiLCAidyIpOworIHJldHVybiBmZXJyb3IgKGYpIHx8IGZjbG9zZSAo
ZikgIT0gMDsKIAorICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCithY19jbGVhbl9maWxlcz0i
JGFjX2NsZWFuX2ZpbGVzIGNvbmZ0ZXN0Lm91dCIKKyMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIg
cHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwgZWl0aGVyCisjIHRoZSBj
b21waWxlciBpcyBicm9rZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNv
bXBpbGluZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBj
b21waWxpbmcuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiRjcm9zc19jb21waWxpbmciICE9IHllczsg
dGhlbgorICB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwi
KiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hv
PSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4m
NQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVz
dCAkYWNfc3RhdHVzID0gMDsgfQorICBpZiB7IGFjX3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVl
eHQnCisgIHsgeyBjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNf
dHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2
YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9l
Y2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY190cnki
KSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsg
fTsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGluZz1ubworICBlbHNlCisgICAgaWYgdGVzdCAiJGNy
b3NzX2NvbXBpbGluZyIgPSBtYXliZTsgdGhlbgorCWNyb3NzX2NvbXBpbGluZz15ZXMKKyAgICBl
bHNlCisJeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBp
biBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdk
JzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biBDIGNvbXBpbGVkIHByb2dyYW1z
LgorSWYgeW91IG1lYW50IHRvIGNyb3NzIGNvbXBpbGUsIHVzZSBcYC0taG9zdCcuCitTZWUgXGBj
b25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KKyAgICBmaQorICBm
aQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
Y3Jvc3NfY29tcGlsaW5nIiA+JjUKKyRhc19lY2hvICIkY3Jvc3NfY29tcGlsaW5nIiA+JjY7IH0K
IAotICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0Ci0gICAgIGlmIHRlc3QgLW4gIiRhY190
b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rv
b2xfcHJlZml4fW9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdDsgYWNfd29yZD0kMgot
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxDRE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoK
K3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNvbmZ0ZXN0Lm91
dAorYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmls
ZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zfb2JqZXh0K3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1M
Q0RPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiRPQ0FNTENET1RPUFQi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRh
c19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RP
UFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKKyAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLwogCi1maQotZmkKLU9DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RP
UFQKLWlmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKLSRhc19l
Y2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9
Ci1maQoraW50CittYWluICgpCit7CiAKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorcm0g
LWYgY29uZnRlc3QubyBjb25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgor
Y2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwk
YWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9l
Y2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFz
X2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUK
KyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoK
KyAgZm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8K
KyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRhY19maWxlIGluCisg
ICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAq
LmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAgICAqKSBhY19jdl9v
YmpleHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAgICBicmVhazs7Cisg
IGVzYWMKK2RvbmUKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2Fz
OiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CiAKK3sgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5f
ZXJyb3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBj
b21waWxlCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7
IH0KIGZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCi0gIGFj
X2N0X09DQU1MQ0RPVE9QVD0kT0NBTUxDRE9UT1BUCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAib2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgb2NhbWxjLm9wdDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By
b2dfYWNfY3RfT0NBTUxDRE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKK3JtIC1mIGNvbmZ0ZXN0
LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb2JqZXh0IiA+JjUKKyRhc19lY2hv
ICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KK09CSkVYVD0kYWNfY3Zfb2JqZXh0CithY19vYmpleHQ9
JE9CSkVYVAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJfZ251K3NldH0iID0gc2V0OyB0aGVu
IDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9
IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgot
ZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBp
biAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5vcHQiCi0gICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3Nh
dmVfSUZTCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KIAotZmkKLWZpCi1hY19jdF9PQ0FNTENET1RPUFQ9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUCi1pZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BU
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X09DQU1MQ0RPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MQ0RPVE9Q
VCIgPiY2OyB9CitpbnQKK21haW4gKCkKK3sKKyNpZm5kZWYgX19HTlVDX18KKyAgICAgICBjaG9r
ZSBtZQorI2VuZGlmCisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jb21waWxlcl9nbnU9eWVzCiBlbHNl
Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorICBhY19jb21waWxlcl9nbnU9bm8KIGZpCitybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQK
K2FjX2N2X2NfY29tcGlsZXJfZ251PSRhY19jb21waWxlcl9nbnUKIAotICBpZiB0ZXN0ICJ4JGFj
X2N0X09DQU1MQ0RPVE9QVCIgPSB4OyB0aGVuCi0gICAgT0NBTUxDRE9UT1BUPSJubyIKLSAgZWxz
ZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAi
JGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FNTENE
T1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAotICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQor
JGFzX2VjaG8gIiRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21w
aWxlcl9nbnUgPSB5ZXM7IHRoZW4KKyAgR0NDPXllcwogZWxzZQotICBPQ0FNTENET1RPUFQ9IiRh
Y19jdl9wcm9nX09DQU1MQ0RPVE9QVCIKKyAgR0NDPQogZmkKLQotICAgICBpZiB0ZXN0ICIkT0NB
TUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCi0JVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8
IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKLQlpZiB0ZXN0ICIkVE1Q
VkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgotCSAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j
YW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKLSRhc19lY2hvICJ2ZXJzaW9ucyBkaWZm
ZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsgfQotCWVsc2UKLQkg
ICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKLQlmaQotICAgICBmaQotCi0gICAgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sb3B0Lm9wdAotICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVu
Ci0JaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQor
YWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgotICBh
Y19jdl9wcm9nX09DQU1MT1BURE9UT1BUPSIkT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJHthY190b29s
X3ByZWZpeH1vY2FtbG9wdC5vcHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJl
YWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCisgIGFjX3NhdmVfY193
ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNfY193ZXJyb3JfZmxhZz15ZXMKKyAg
IGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIKKyAgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotZmkK
LWZpCi1PQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAotaWYgdGVzdCAt
biAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKLSRhc19lY2hvICIkT0NB
TUxPUFRET1RPUFQiID4mNjsgfQoraW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9wcm9nX2NjX2c9eWVzCiBlbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKKyAg
Q0ZMQUdTPSIiCisgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKK2ludAorbWFpbiAoKQorewogCi1maQotaWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCi0gIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
Im9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTE9QVERPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9Q
VCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1M
T1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRv
Ci0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxPUFRET1RPUFQ9Im9jYW1sb3B0Lm9wdCIKLSAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMK
KyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJy
b3JfZmxhZworCSBDRkxBR1M9Ii1nIgorCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQorewog
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRM
SU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19nPXllcwogZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAogZmkKLWFjX2N0
X09DQU1MT1BURE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUCi1pZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNQot
JGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNo
byAibm8iID4mNjsgfQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CiBmaQotCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFRET1RP
UFQiID0geDsgdGhlbgotICAgIE9DQU1MT1BURE9UT1BUPSJubyIKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgYWNfY193ZXJy
b3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQoraWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9
IHNldDsgdGhlbgorICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCitlbGlmIHRlc3QgJGFjX2N2X3By
b2dfY2NfZyA9IHllczsgdGhlbgorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENG
TEFHUz0iLWcgLU8yIgogICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29s
X3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7
OwotZXNhYwotICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERPVE9QVAorICAgIENG
TEFHUz0iLWciCiAgIGZpCiBlbHNlCi0gIE9DQU1MT1BURE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FN
TE9QVERPVE9QVCIKLWZpCi0KLQlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRo
ZW4KLQkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2
ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCi0JICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIk
T0NBTUxWRVJTSU9OIiA7IHRoZW4KLQkgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9w
dC5vcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbiBkaWZmZXJzIGZyb20gb2Nh
bWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9Ci0JICAgZWxzZQotCSAgICAgIE9D
QU1MT1BUPSRPQ0FNTE9QVERPVE9QVAotCSAgIGZpCi0gICAgICAgIGZpCi0gICAgIGZpCi0KLQor
ICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisg
ICAgQ0ZMQUdTPQogICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jdl9wcm9nX2NjX2M4OT1u
bworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNs
dWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0
Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1
LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVmIHsgaW50IHg7IH07CitGSUxFICogKCpy
Y3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOworc3RhdGljIGNoYXIg
KmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBpbnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07
Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIgKipw
LCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3QgdjsKKyAgdmFfc3RhcnQgKHYscCk7Cisg
IHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZhX2VuZCAodik7CisgIHJldHVybiBzOwor
fQogCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21lIHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkg
ZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBu
b3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRzLgorICAgVGhlc2UgZG9uJ3QgcHJvdm9r
ZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCisg
ICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMgYW4gZXJyb3IsIHVudGlsIC1zdGQgaXMg
YWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gn
IGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisgICBhcnJheSBzaXplIGF0IGxlYXN0LiAg
SXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKKyAgIHRo
YXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2ludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcg
PT0gMCA/IDEgOiAtMV07CiAKKy8qIElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBk
ZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFyYW1ldGVycworICAgaW5zaWRlIHN0cmlu
Z3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLworI2RlZmluZSBGT08oeCkgJ3gnCitpbnQg
eGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6IC0xXTsKIAotICAjIGNoZWNraW5nIGZv
ciBvY2FtbCB0b3BsZXZlbAotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29s
X3ByZWZpeH1vY2FtbDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUwr
c2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQot
ICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUw9IiRPQ0FNTCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICitpbnQgdGVzdCAoaW50
IGksIGRvdWJsZSB4KTsKK3N0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Oworc3RydWN0IHMy
IHtpbnQgKCpmKSAoZG91YmxlIGEpO307CitpbnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJ
TEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCksIGludCwgaW50KTsKK2lu
dCBhcmdjOworY2hhciAqKmFyZ3Y7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBmIChlLCBhcmd2
LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwgYXJndiwgMSkgIT0gYXJndlsxXTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgorZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1x
bGFuZ2x2bD1hbnNpIC1zdGQgXAorCS1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19F
WFRFTlNJT05TX18iCiBkbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
LSAgICBhY19jdl9wcm9nX09DQU1MPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIgotICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgQ0M9IiRhY19zYXZlX0NDICRh
Y19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNf
Y3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIgJiYg
YnJlYWsKIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworcm0gLWYgY29uZnRlc3QuJGFj
X2V4dAorQ0M9JGFjX3NhdmVfQ0MKIAogZmkKLWZpCi1PQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAot
aWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MIiA+JjUKLSRhc19lY2hvICIkT0NBTUwiID4mNjsg
fQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyMgQUNfQ0FDSEVfVkFMCitjYXNlICJ4
JGFjX2N2X3Byb2dfY2NfYzg5IiBpbgorICB4KQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1CiskYXNfZWNobyAibm9u
ZSBuZWVkZWQiID4mNjsgfSA7OworICB4bm8pCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUKKyRhc19lY2hvICJ1bnN1
cHBvcnRlZCIgPiY2OyB9IDs7CisgICopCisgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODki
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9wcm9nX2NjX2M4OSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7
IH0gOzsKK2VzYWMKK2lmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6
CisKIGZpCiAKK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0n
JENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0n
JENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxl
cl9nbnUKIAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MIjsgdGhlbgotICBhY19j
dF9PQ0FNTD0kT0NBTUwKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWw7IGFj
X3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MK3NldH0iID0gc2V0
OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0UpLi4uICIgPiY2OyB9Citz
ZXQgeCAke01BS0UtbWFrZX0KK2FjX21ha2U9YCRhc19lY2hvICIkMiIgfCBzZWQgJ3MvKy9wL2c7
IHMvW15hLXpBLVowLTlfXS9fL2cnYAoraWYgZXZhbCAidGVzdCBcIlwke2FjX2N2X3Byb2dfbWFr
ZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgotICBh
Y19jdl9wcm9nX2FjX2N0X09DQU1MPSIkYWNfY3RfT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0ib2NhbWwiCi0gICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFz
X3NhdmVfSUZTCi0KLWZpCi1maQotYWNfY3RfT0NBTUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwK
LWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTCIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N0X09DQU1MIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQot
Ci0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUwiID0geDsgdGhlbgotICAgIE9DQU1MPSJubyIKLSAg
ZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczop
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKKyAgY2F0ID5jb25mdGVz
dC5tYWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAvYmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0k
KE1BS0UpPUBAQCUlJScKK19BQ0VPRgorIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtl
WzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtF
LW1ha2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBA
JSUlKikKKyAgICBldmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAq
KQorICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKIGVzYWMKLSAg
ICBPQ0FNTD0kYWNfY3RfT0NBTUwKLSAgZmkKK3JtIC1mIGNvbmZ0ZXN0Lm1ha2UKK2ZpCitpZiBl
dmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1
CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CiBlbHNlCi0gIE9DQU1MPSIkYWNf
Y3ZfcHJvZ19PQ0FNTCIKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgIFNFVF9NQUtFPSJNQUtF
PSR7TUFLRS1tYWtlfSIKIGZpCiAKLQotICAjIGNoZWNraW5nIGZvciBvY2FtbGRlcAotICBpZiB0
ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGRlcDsgYWNf
d29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxERVArc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorIyBGaW5kIGEgZ29vZCBpbnN0YWxsIHByb2dyYW0uICBXZSBwcmVmZXIgYSBDIHByb2dy
YW0gKGZhc3RlciksCisjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBhbm90aGVyLiAgQnV0
IGF2b2lkIHRoZSBicm9rZW4gb3IKKyMgaW5jb21wYXRpYmxlIHZlcnNpb25zOgorIyBTeXNWIC9l
dGMvaW5zdGFsbCwgL3Vzci9zYmluL2luc3RhbGwKKyMgU3VuT1MgL3Vzci9ldGMvaW5zdGFsbAor
IyBJUklYIC9zYmluL2luc3RhbGwKKyMgQUlYIC9iaW4vaW5zdGFsbAorIyBBbWlnYU9TIC9DL2lu
c3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxvcHB5IGRpc2NzCisjIEFJWCA0
IC91c3IvYmluL2luc3RhbGxic2QsIHdoaWNoIGRvZXNuJ3Qgd29yayB3aXRob3V0IGEgLWcgZmxh
ZworIyBBRlMgL3Vzci9hZnN3cy9iaW4vaW5zdGFsbCwgd2hpY2ggbWlzaGFuZGxlcyBub25leGlz
dGVudCBhcmdzCisjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRo
ZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCisjIE9TLzIncyBzeXN0ZW0gaW5zdGFsbCwgd2hp
Y2ggaGFzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc2VtYW50aWMKKyMgLi9pbnN0YWxsLCB3aGlj
aCBjYW4gYmUgZXJyb25lb3VzbHkgY3JlYXRlZCBieSBtYWtlIGZyb20gLi9pbnN0YWxsLnNoLgor
IyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZp
bGVzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwuLi4gIiA+JjY7IH0KK2lmIHRlc3QgLXogIiRJTlNU
QUxMIjsgdGhlbgoraWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIk
T0NBTUxERVAiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxERVA9IiRPQ0FNTERFUCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
IGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxk
ZXAiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQor
ICAgICMgQWNjb3VudCBmb3IgcGVvcGxlIHdobyBwdXQgdHJhaWxpbmcgc2xhc2hlcyBpbiBQQVRI
IGVsZW1lbnRzLgorY2FzZSAkYXNfZGlyLyBpbiAjKCgKKyAgLi8gfCAuLy8gfCAvW2NDXS8qIHwg
XAorICAvZXRjLyogfCAvdXNyL3NiaW4vKiB8IC91c3IvZXRjLyogfCAvc2Jpbi8qIHwgL3Vzci9h
ZnN3cy9iaW4vKiB8IFwKKyAgPzpbXFwvXW9zMltcXC9daW5zdGFsbFtcXC9dKiB8ID86W1xcL11P
UzJbXFwvXUlOU1RBTExbXFwvXSogfCBcCisgIC91c3IvdWNiLyogKSA7OworICAqKQorICAgICMg
T1NGMSBhbmQgU0NPIE9EVCAzLjAgaGF2ZSB0aGVpciBvd24gbmFtZXMgZm9yIGluc3RhbGwuCisg
ICAgIyBEb24ndCB1c2UgaW5zdGFsbGJzZCBmcm9tIE9TRiBzaW5jZSBpdCBpbnN0YWxscyBzdHVm
ZiBhcyByb290CisgICAgIyBieSBkZWZhdWx0LgorICAgIGZvciBhY19wcm9nIGluIGdpbnN0YWxs
IHNjb2luc3QgaW5zdGFsbDsgZG8KKyAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworCWlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCI7
IH07IHRoZW4KKwkgIGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCisJICAgIGdyZXAgZHNw
bXNnICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4K
KwkgICAgIyBBSVggaW5zdGFsbC4gIEl0IGhhcyBhbiBpbmNvbXBhdGlibGUgY2FsbGluZyBjb252
ZW50aW9uLgorCSAgICA6CisJICBlbGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCisJICAg
IGdyZXAgcHdwbHVzICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+
JjE7IHRoZW4KKwkgICAgIyBwcm9ncmFtLXNwZWNpZmljIGluc3RhbGwgc2NyaXB0IHVzZWQgYnkg
SFAgcHdwbHVzLS1kb24ndCB1c2UuCisJICAgIDoKKwkgIGVsc2UKKwkgICAgcm0gLXJmIGNvbmZ0
ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRlc3QuZGlyCisJICAgIGVjaG8gb25lID4gY29uZnRl
c3Qub25lCisJICAgIGVjaG8gdHdvID4gY29uZnRlc3QudHdvCisJICAgIG1rZGlyIGNvbmZ0ZXN0
LmRpcgorCSAgICBpZiAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgLWMgY29uZnRlc3Qu
b25lIGNvbmZ0ZXN0LnR3byAiYHB3ZGAvY29uZnRlc3QuZGlyIiAmJgorCSAgICAgIHRlc3QgLXMg
Y29uZnRlc3Qub25lICYmIHRlc3QgLXMgY29uZnRlc3QudHdvICYmCisJICAgICAgdGVzdCAtcyBj
b25mdGVzdC5kaXIvY29uZnRlc3Qub25lICYmCisJICAgICAgdGVzdCAtcyBjb25mdGVzdC5kaXIv
Y29uZnRlc3QudHdvCisJICAgIHRoZW4KKwkgICAgICBhY19jdl9wYXRoX2luc3RhbGw9IiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQgLWMiCisJICAgICAgYnJlYWsgMworCSAgICBmaQorCSAg
ZmkKKwlmaQorICAgICAgZG9uZQorICAgIGRvbmUKKyAgICA7OworZXNhYworCiAgIGRvbmUKIElG
Uz0kYXNfc2F2ZV9JRlMKIAorcm0gLXJmIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRl
c3QuZGlyCisKIGZpCisgIGlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9pbnN0YWxsK3NldH0iID0gc2V0
OyB0aGVuCisgICAgSU5TVEFMTD0kYWNfY3ZfcGF0aF9pbnN0YWxsCisgIGVsc2UKKyAgICAjIEFz
IGEgbGFzdCByZXNvcnQsIHVzZSB0aGUgc2xvdyBzaGVsbCBzY3JpcHQuICBEb24ndCBjYWNoZSBh
CisgICAgIyB2YWx1ZSBmb3IgSU5TVEFMTCB3aXRoaW4gYSBzb3VyY2UgZGlyZWN0b3J5LCBiZWNh
dXNlIHRoYXQgd2lsbAorICAgICMgYnJlYWsgb3RoZXIgcGFja2FnZXMgdXNpbmcgdGhlIGNhY2hl
IGlmIHRoYXQgZGlyZWN0b3J5IGlzCisgICAgIyByZW1vdmVkLCBvciBpZiB0aGUgdmFsdWUgaXMg
YSByZWxhdGl2ZSBuYW1lLgorICAgIElOU1RBTEw9JGFjX2luc3RhbGxfc2gKKyAgZmkKIGZpCi1P
Q0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAotaWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhl
bgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MREVQIiA+JjUKLSRhc19lY2hvICIkT0NBTUxERVAiID4mNjsgfQotZWxzZQotICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KLWZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJElOU1RBTEwiID4mNQorJGFzX2VjaG8gIiRJTlNUQUxMIiA+JjY7IH0KIAor
IyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1bk9TNCBzaCBtaXNoYW5kbGVzIGJyYWNlcyBpbiAke3Zh
ci12YWx9LgorIyBJdCB0aGlua3MgdGhlIGZpcnN0IGNsb3NlIGJyYWNlIGVuZHMgdGhlIHZhcmlh
YmxlIHN1YnN0aXR1dGlvbi4KK3Rlc3QgLXogIiRJTlNUQUxMX1BST0dSQU0iICYmIElOU1RBTExf
UFJPR1JBTT0nJHtJTlNUQUxMfScKIAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1M
REVQIjsgdGhlbgotICBhY19jdF9PQ0FNTERFUD0kT0NBTUxERVAKLSAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbGRlcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxkZXA7IGFjX3dvcmQ9JDIKK3Rlc3QgLXogIiRJTlNUQUxM
X1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNU
QUxMX0RBVEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAiYmlzb24iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgorc2V0IGR1bW15IGJpc29uOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2Fj
X2N2X3BhdGhfQklTT04rc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCi0gIGFj
X2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9IiRhY19jdF9PQ0FNTERFUCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCisgIGNhc2UgJEJJU09OIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9w
YXRoX0JJU09OPSIkQklTT04iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSJvY2FtbGRlcCIKKyAg
ICBhY19jdl9wYXRoX0JJU09OPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTU4MzMsNTMgKzM1NjUs
MzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKKyAgOzsKK2VzYWMKIGZpCi1m
aQotYWNfY3RfT0NBTUxERVA9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVAKLWlmIHRlc3QgLW4g
IiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERFUCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0
X09DQU1MREVQIiA+JjY7IH0KK0JJU09OPSRhY19jdl9wYXRoX0JJU09OCitpZiB0ZXN0IC1uICIk
QklTT04iOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkQklTT04iID4mNQorJGFzX2VjaG8gIiRCSVNPTiIgPiY2OyB9CiBlbHNlCiAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAk
YXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9
IHg7IHRoZW4KLSAgICBPQ0FNTERFUD0ibm8iCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCi0gIGZp
Ci1lbHNlCi0gIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKLWZpCi0KIAotICAjIGNo
ZWNraW5nIGZvciBvY2FtbG1rdG9wCi0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRo
ZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
bWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgorIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJmbGV4Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBmbGV4OyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9GTEVY
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgaWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxNS1RP
UD0iJE9DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQot
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRGTEVYIGluCisg
IFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0ZMRVg9IiRGTEVYIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8K
ICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCisgICAgYWNfY3ZfcGF0aF9G
TEVYPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTU4ODcsMzkgKzM2MDUsMzkgQEAgZG9uZQogICBk
b25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKKyAgOzsKK2VzYWMKIGZpCi1maQotT0NBTUxNS1RPUD0k
YWNfY3ZfcHJvZ19PQ0FNTE1LVE9QCi1pZiB0ZXN0IC1uICIkT0NBTUxNS1RPUCI7IHRoZW4KLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1L
VE9QIiA+JjUKLSRhc19lY2hvICIkT0NBTUxNS1RPUCIgPiY2OyB9CitGTEVYPSRhY19jdl9wYXRo
X0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQorJGFzX2VjaG8gIiRGTEVYIiA+
JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCiAKLWZpCi1pZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgotICBhY19jdF9PQ0FNTE1LVE9QPSRP
Q0FNTE1LVE9QCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta3RvcCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxta3Rv
cDsgYWNfd29yZD0kMgorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwZXJsIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBwZXJsOyBhY193b3Jk
PSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QK3NldH0iID0gc2V0
OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QRVJMK3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0
X09DQU1MTUtUT1AiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0
X09DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRQRVJMIGluCisgIFtc
XC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1BFUkw9IiRQRVJMIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAg
SUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9wIgorICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh
ayAyCiAgIGZpCkBAIC01OTI3LDUzICszNjQ1LDQ2IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19z
YXZlX0lGUwogCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1BFUkwiICYmIGFjX2N2X3BhdGhfUEVS
TD0ibm8iCisgIDs7Citlc2FjCiBmaQotZmkKLWFjX2N0X09DQU1MTUtUT1A9JGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxNS1RPUAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCi0g
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Rf
T0NBTUxNS1RPUCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MTUtUT1AiID4mNjsgfQorUEVS
TD0kYWNfY3ZfcGF0aF9QRVJMCitpZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQRVJMIiA+JjUKKyRhc19l
Y2hvICIkUEVSTCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAot
ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MTUtUT1AiID0geDsgdGhlbgotICAgIE9DQU1MTUtUT1A9
Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBp
bgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
LSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwot
ICAgIE9DQU1MTUtUT1A9JGFjX2N0X09DQU1MTUtUT1AKLSAgZmkKLWVsc2UKLSAgT0NBTUxNS1RP
UD0iJGFjX2N2X3Byb2dfT0NBTUxNS1RPUCIKLWZpCiAKK2lmIHRlc3QgeCIke1BFUkx9IiA9PSB4
Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBwZXJsLCBwbGVh
c2UgaW5zdGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkeGFwaSIgPSAieHki
OyB0aGVuIDoKIAotICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCi0gIGlmIHRlc3QgLW4gIiRh
Y190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0k
MgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY3VybC1jb25maWciLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGN1cmwtY29uZmlnOyBh
Y193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0
OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9DVVJMK3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1M
TUtMSUIiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxNS0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRDVVJMIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQor
ICBhY19jdl9wYXRoX0NVUkw9IiRDVVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwog
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sbWtsaWIiCisgICAgYWNfY3ZfcGF0aF9DVVJMPSIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAg
ZmkKQEAgLTU5ODEsMzkgKzM2OTIsNDQgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZT
CiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQ1VSTCIgJiYgYWNfY3ZfcGF0aF9DVVJMPSJubyIK
KyAgOzsKK2VzYWMKIGZpCi1maQotT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19PQ0FNTE1LTElCCi1p
ZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LTElCIiA+JjUKLSRhc19lY2hvICIkT0NB
TUxNS0xJQiIgPiY2OyB9CitDVVJMPSRhY19jdl9wYXRoX0NVUkwKK2lmIHRlc3QgLW4gIiRDVVJM
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENVUkwiID4mNQorJGFzX2VjaG8gIiRDVVJMIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hv
ICJubyIgPiY2OyB9CiBmaQogCiAKK2lmIHRlc3QgeCIke0NVUkx9IiA9PSB4Im5vIgordGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBjdXJsLWNvbmZpZywgcGxlYXNlIGlu
c3RhbGwgY3VybC1jb25maWciICIkTElORU5PIiA1CiBmaQotaWYgdGVzdCAteiAiJGFjX2N2X3By
b2dfT0NBTUxNS0xJQiI7IHRoZW4KLSAgYWNfY3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgotICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIK
KyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInhtbDItY29uZmlnIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB4bWwyLWNvbmZpZzsgYWNf
d29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQitzZXR9IiA9
IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfWE1MK3NldH0iID0gc2V0OyB0aGVu
IDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MTUtMSUIiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQj0iJGFj
X2N0X09DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQot
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRYTUwgaW4KKyAg
W1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfWE1MPSIkWE1MIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAg
SUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LTElCPSJvY2FtbG1rbGliIgorICAgIGFjX2N2X3BhdGhfWE1MPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFr
IDIKICAgZmkKQEAgLTYwMjEsNDQgKzM3MzcsMzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3Nh
dmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWE1MIiAmJiBhY19jdl9wYXRoX1hNTD0i
bm8iCisgIDs7Citlc2FjCiBmaQotZmkKLWFjX2N0X09DQU1MTUtMSUI9JGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxNS0xJQgotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtMSUIiOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB
TUxNS0xJQiIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MTUtMSUIiID4mNjsgfQorWE1MPSRh
Y19jdl9wYXRoX1hNTAoraWYgdGVzdCAtbiAiJFhNTCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYTUwiID4mNQorJGFzX2VjaG8gIiRY
TUwiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVz
dCAieCRhY19jdF9PQ0FNTE1LTElCIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE1LTElCPSJubyIKLSAg
ZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczop
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FN
TE1LTElCPSRhY19jdF9PQ0FNTE1LTElCCi0gIGZpCi1lbHNlCi0gIE9DQU1MTUtMSUI9IiRhY19j
dl9wcm9nX09DQU1MTUtMSUIiCisKK2lmIHRlc3QgeCIke1hNTH0iID09IHgibm8iCit0aGVuCisg
ICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIHhtbDItY29uZmlnLCBwbGVhc2UgaW5z
dGFsbCB4bWwyLWNvbmZpZyIgIiRMSU5FTk8iIDUKIGZpCiAKK2ZpCitpZiB0ZXN0ICJ4JG9jYW1s
dG9vbHMiID0gInh5IjsgdGhlbiA6CiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgICAg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sYwogICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0
aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft
bGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbGRvYzsgYWNfd29yZD0kMgorICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsg
YWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6
CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FN
TERPQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJE9DQU1MRE9DIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19PQ0FNTEM9IiRPQ0FNTEMiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgogZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFz
X2RpciBpbiAkUEFUSApAQCAtNjA2Nyw3ICszNzc4LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgotICAgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisg
ICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgogICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTYwNzcsMTAgKzM3ODgsMTAg
QEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MRE9DPSRhY19jdl9wcm9nX09DQU1M
RE9DCi1pZiB0ZXN0IC1uICIkT0NBTUxET0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxET0MiID4mNQotJGFzX2VjaG8gIiRP
Q0FNTERPQyIgPiY2OyB9CitPQ0FNTEM9JGFjX2N2X3Byb2dfT0NBTUxDCitpZiB0ZXN0IC1uICIk
T0NBTUxDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJE9DQU1MQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MQyIgPiY2OyB9CiBlbHNlCiAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
CiAkYXNfZWNobyAibm8iID4mNjsgfQpAQCAtNjA4OCwxNyArMzc5OSwxNyBAQCBmaQogCiAKIGZp
Ci1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERPQyI7IHRoZW4KLSAgYWNfY3RfT0NBTUxE
T0M9JE9DQU1MRE9DCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sZG9j
OyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEMiOyB0aGVuCisgIGFj
X2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxj
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2Ft
bGM7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DK3Nl
dH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMrc2V0
fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxET0M9IiRhY19jdF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxDPSIkYWNfY3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
IGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIg
aW4gJFBBVEgKQEAgLTYxMDcsNyArMzgxOCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAg
ICBhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSJvY2FtbGRvYyIKKyAgICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MQz0ib2NhbWxjIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFr
IDIKICAgZmkKQEAgLTYxMTcsMTcgKzM4MjgsMTcgQEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQog
ZmkKLWFjX2N0X09DQU1MRE9DPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCi1pZiB0ZXN0IC1u
ICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxET0MiID4mNQotJGFzX2VjaG8gIiRhY19j
dF9PQ0FNTERPQyIgPiY2OyB9CithY19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxD
CitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQyIgPiY1CiskYXNfZWNo
byAiJGFjX2N0X09DQU1MQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQog
ZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MRE9DIiA9IHg7IHRoZW4KLSAgICBPQ0FNTERP
Qz0ibm8iCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEM9
Im5vIgogICBlbHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBp
bgogeWVzOikKQEAgLTYxMzUsMjQgKzM4NDYsNDEgQEAgeWVzOikKICRhc19lY2hvICIkYXNfbWU6
IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxl
dCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7OwogZXNhYwotICAgIE9DQU1MRE9DPSRhY19j
dF9PQ0FNTERPQworICAgIE9DQU1MQz0kYWNfY3RfT0NBTUxDCiAgIGZpCiBlbHNlCi0gIE9DQU1M
RE9DPSIkYWNfY3ZfcHJvZ19PQ0FNTERPQyIKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMi
CiBmaQogCiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAotICBpZiB0ZXN0IC1uICIkYWNf
dG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190
b29sX3ByZWZpeH1vY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQ7IGFjX3dvcmQ9JDIK
KyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZFUlNJT049YCRP
Q0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKKyAgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZl
cnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAk
T0NBTUxWRVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAor
ICAgICBpZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRP
Q0FNTEMgLXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAn
IC1mIDRgCisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0
LiIgPiY1CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQu
IiA+JjY7IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQorJGFz
X2VjaG8gIk9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQorCisKKworCisg
ICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCiB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19PQ0FNTEJVSUxEK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgotICBh
Y19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgorICBhY19jdl9wcm9n
X09DQU1MT1BUPSIkT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgog
ZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBp
biAkUEFUSApAQCAtNjE2MSw3ICszODg5LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAg
IGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkIgorICAg
IGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCiAgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjE3MSwxMCArMzg5OSwx
MCBAQCBJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19P
Q0FNTEJVSUxECi1pZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KLSAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJVSUxEIiA+JjUKLSRh
c19lY2hvICIkT0NBTUxCVUlMRCIgPiY2OyB9CitPQ0FNTE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9Q
VAoraWYgdGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BUIiA+JjUKKyRhc19lY2hvICIkT0NB
TUxPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KQEAgLTYxODIsMTcg
KzM5MTAsMTcgQEAgZmkKIAogCiBmaQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxCVUlM
RCI7IHRoZW4KLSAgYWNfY3RfT0NBTUxCVUlMRD0kT0NBTUxCVUlMRAotICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIm9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MT1BUIjsgdGhlbgorICBhY19jdF9PQ0FNTE9QVD0kT0NBTUxPUFQK
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdCIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxvcHQ7IGFjX3dvcmQ9JDIK
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUK3NldH0iID0gc2V0OyB0
aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0i
JGFjX2N0X09DQU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFQ9IiRhY19jdF9PQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGly
IGluICRQQVRICkBAIC02MjAxLDcgKzM5MjksNyBAQCBkbwogICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl
bnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0g
ICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgorICAgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQog
ICAgIGJyZWFrIDIKICAgZmkKQEAgLTYyMTEsMTcgKzM5MzksMTcgQEAgSUZTPSRhc19zYXZlX0lG
UwogCiBmaQogZmkKLWFjX2N0X09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlM
RAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1
Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MQlVJTEQiID4mNjsgfQorYWNfY3RfT0NBTUxPUFQ9JGFj
X2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdF9PQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MT1BUIiA+JjY7IH0KIGVs
c2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUxCVUlMRCIgPSB4OyB0aGVuCi0gICAgT0NBTUxCVUlMRD0ibm8iCisgIGlmIHRlc3QgIngkYWNf
Y3RfT0NBTUxPUFQiID0geDsgdGhlbgorICAgIE9DQU1MT1BUPSJubyIKICAgZWxzZQogICAgIGNh
c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KIHllczopCkBAIC02MjI5LDQ0
ICszOTU3LDg5IEBAIHllczopCiAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CiBhY190b29sX3dh
cm5lZD15ZXMgOzsKIGVzYWMKLSAgICBPQ0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgICAg
T0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCiAgIGZpCiBlbHNlCi0gIE9DQU1MQlVJTEQ9IiRhY19j
dl9wcm9nX09DQU1MQlVJTEQiCisgIE9DQU1MT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCIKIGZp
CiAKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9ICJubyI7
IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6
IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUg
Y29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxP
UFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVz
dCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMg
ZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25z
IGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgICBP
Q0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCiAKLSAg
ICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6CiAKLSAgICAgICAgaWYgdGVzdCAi
eCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgogCi0gICAgICAgICAgICBhc19m
bl9lcnJvciAkPyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1s
IiAiJExJTkVOTyIgNQotZmkKLSAgICAgICAgb2NhbWx0b29scz0ibiIKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxjLm9wdAorICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVu
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGMu
b3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCisg
IGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIkT0NBTUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sYy5vcHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCitmaQorT0NBTUxDRE9U
T1BUPSRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9QVCI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRPQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTENET1RPUFQiID4mNjsgfQorZWxz
ZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKIAogZmkKLSMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgYmFzaDsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NB
TUxDRE9UT1BUIjsgdGhlbgorICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RPVE9QVAorICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIK
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0JBU0grc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVz
dCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJEJBU0ggaW4KLSAgW1xc
L10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQkFTSD0iJEJBU0giICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTENE
T1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSIkYWNfY3RfT0NB
TUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
QkFTSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MQ0RPVE9QVD0ib2NhbWxjLm9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAg
ICBicmVhayAyCiAgIGZpCkBAIC02Mjc0LDU2ICs0MDQ3LDYzIEBAIGRvbmUKICAgZG9uZQogSUZT
PSRhc19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3Bh
dGhfQkFTSD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotQkFTSD0kYWNfY3ZfcGF0aF9CQVNICi1pZiB0
ZXN0IC1uICIkQkFTSCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRCQVNIIiA+JjUKLSRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitmaQor
YWNfY3RfT0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFz
X2VjaG8gIiRhY19jdF9PQ0FNTENET1RPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5v
IiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7QkFTSH0iID09IHgibm8iCi10aGVuCi0gICAg
YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2gi
ICIkTElORU5PIiA1CisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDRE9UT1BUIiA9IHg7IHRoZW4K
KyAgICBPQ0FNTENET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5n
OiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGgg
aG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2Fy
bmVkPXllcyA7OworZXNhYworICAgIE9DQU1MQ0RPVE9QVD0kYWNfY3RfT0NBTUxDRE9UT1BUCisg
IGZpCitlbHNlCisgIE9DQU1MQ0RPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUIgogZmkK
LWlmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhlbiA6Ci0KLSAgICBpZiBlY2hvICIk
UFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CiAKLSAgICAgICAgUFlUSE9OUEFUSD0kUFlU
SE9OCi0gICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgIGlmIHRlc3Qg
IiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BU
IC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3Qg
IiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZy
b20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25z
IGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9CisJZWxz
ZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCiAKLWVsaWYgdGVzdCAt
eiAiJFBZVEhPTiI7IHRoZW4gOgotICBQWVRIT049InB5dGhvbiIKLWVsc2UKLSAgYXNfZm5fZXJy
b3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1dGUgcGF0aCIgIiRM
SU5FTk8iIDUKLWZpCi0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAkUFlUSE9O
OyBhY193b3JkPSQyCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0
ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl
Zml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
K3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgogeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p
ZiB0ZXN0ICIke2FjX2N2X3BhdGhfUFlUSE9OUEFUSCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0
ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRQWVRIT05QQVRIIGluCi0g
IFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9IiRQWVRIT05QQVRI
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAg
KikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1u
ICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiRP
Q0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCith
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRI
CiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9w
YXRoX1BZVEhPTlBBVEg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3Zf
cHJvZ19PQ0FNTE9QVERPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiCiAgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjMzMSw2MiArNDEx
MSwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgotICA7Owot
ZXNhYwogZmkKLVBZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAotaWYgdGVzdCAtbiAi
JFBZVEhPTlBBVEgiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1Ci0kYXNfZWNobyAiJFBZVEhPTlBBVEgiID4m
NjsgfQorZmkKK09DQU1MT1BURE9UT1BUPSRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0
ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8g
IiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQog
ZmkKIAogCi1pZiB0ZXN0IHgiJHtQWVRIT05QQVRIfSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19m
bl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgJFBZVEhPTiwgcGxlYXNlIGluc3RhbGwgJFBZVEhP
TiIgIiRMSU5FTk8iIDUKLWZpCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgcHl0aG9uIHZlcnNpb24gPj0gMi4zICIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgcHl0aG9uIHZlcnNpb24gPj0gMi4zIC4uLiAiID4mNjsgfQotYCRQ
WVRIT04gLWMgJ2ltcG9ydCBzeXM7IHN5cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAo
MiwgMykiKSknYAotaWYgdGVzdCAiJD8iICE9ICIwIgotdGhlbgotICAgIHB5dGhvbl92ZXJzaW9u
PWAkUFlUSE9OIC1WIDI+JjFgCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci0gICAgYXNfZm5f
ZXJyb3IgJD8gIiRweXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZl
cnNpb24gaXMgMi4zIiAiJExJTkVOTyIgNQotZWxzZQotICAgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIgPiY2
OyB9CiBmaQotCi1hY19wcmV2aW91c19jcHBmbGFncz0kQ1BQRkxBR1MKLWFjX3ByZXZpb3VzX2xk
ZmxhZ3M9JExERkxBR1MKLWFjX3B5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1jICdpbXBvcnQgZGlz
dHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2Nv
bmZpZ192YXIoIlZFUlNJT04iKSdgCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRQWVRI
T04tY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBk
dW1teSAkUFlUSE9OLWNvbmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2df
T0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BURE9UT1BUPSRPQ0FNTE9QVERP
VE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Lm9wdCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxvcHQub3B0
OyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9weWNvbmZpZytzZXR9IiA9IHNl
dDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBj
YXNlICRweWNvbmZpZyBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9weWNv
bmZpZz0iJHB5Y29uZmlnIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg
cGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZT
CiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX3B5Y29uZmlnPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9
Im9jYW1sb3B0Lm9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02Mzk0LDEyNyArNDE1MSw2OCBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9J
RlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9weWNvbmZpZyIgJiYgYWNfY3ZfcGF0aF9weWNv
bmZpZz0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotcHljb25maWc9JGFjX2N2X3BhdGhfcHljb25maWcK
LWlmIHRlc3QgLW4gIiRweWNvbmZpZyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRweWNvbmZpZyIgPiY1Ci0kYXNfZWNobyAiJHB5Y29u
ZmlnIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0
X09DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4m
NjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiRw
eWNvbmZpZyIgPT0geCJubyI7IHRoZW4gOgotCi0gICAgICAgIENQUEZMQUdTPSIkQ0ZMQUdTIGAk
UFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgICAgICBwcmludCAi
LUkiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiSU5DTFVERVBZIiknYCIK
LSAgICBDUFBGTEFHUz0iJENQUEZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5
c2NvbmZpZzsgXAotICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdf
dmFyKCJDRkxBR1MiKSdgIgotICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBv
cnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29u
ZmlnLmdldF9jb25maWdfdmFyKCJMSUJTIiknYCIKLSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZ
VEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgZGlz
dHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiU1lTTElCUyIpJ2AiCi0gICAgTERGTEFH
Uz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCi0g
ICAgICAgIHByaW50ICItTCIgKyBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBs
YXRfc3BlY2lmaWM9MSxcCi0gICAgICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidgIgot
ICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2Nv
bmZpZzsgXAotICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFy
KCJMSU5LRk9SU0hBUkVEIiknYCIKLSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAn
aW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5
c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTERGTEFHUyIpJ2AiCi0KLWVsc2UKLQotICAgICAgICBD
UFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTi1jb25maWcgLS1jZmxhZ3NgIgotICAgIExERkxBR1M9
IiRMREZMQUdTIGAkUFlUSE9OLWNvbmZpZyAtLWxkZmxhZ3NgIgotCi1maQotCi1hY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiUHl0aG9uLmgiICJhY19jdl9oZWFkZXJfUHl0
aG9uX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX1B5
dGhvbl9oIiA9IHgiInllczsgdGhlbiA6Ci0KKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERP
VE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg
PiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRh
Y19jdF9PQ0FNTE9QVERPVE9QVAorICBmaQogZWxzZQotICBhc19mbl9lcnJvciAkPyAiVW5hYmxl
IHRvIGZpbmQgUHl0aG9uIGRldmVsb3BtZW50IGhlYWRlcnMiICIkTElORU5PIiA1CisgIE9DQU1M
T1BURE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVCIKIGZpCiAKKwlpZiB0ZXN0ICIk
T0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRE
T1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAg
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbiBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIgPiY1CiskYXNfZWNo
byAidmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIg
PiY2OyB9CisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZp
CisgICAgICAgIGZpCisgICAgIGZpCiAKLWFzX2FjX0xpYj1gJGFzX2VjaG8gImFjX2N2X2xpYl9w
eXRob24kYWNfcHl0aG9uX3ZlcnNpb24nJ19QeUFyZ19QYXJzZVR1cGxlIiB8ICRhc190cl9zaGAK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIFB5
QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9u
X3ZlcnNpb24uLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHskYXNfYWNfTGliK3NldH1c
IiIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBh
Y19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVy
c2lvbiAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwg
cHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWln
aHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0
cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3Bs
dXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgUHlBcmdfUGFyc2VUdXBsZSAoKTsKLWlu
dAotbWFpbiAoKQotewotcmV0dXJuIFB5QXJnX1BhcnNlVHVwbGUgKCk7Ci0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAg
ZXZhbCAiJGFzX2FjX0xpYj15ZXMiCi1lbHNlCi0gIGV2YWwgIiRhc19hY19MaWI9bm8iCi1maQot
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlMKLWZpCi1ldmFsIGFjX3Jlcz1cJCRhc19hY19MaWIKLQkgICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8g
IiRhY19yZXMiID4mNjsgfQotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19MaWIiXCIgPSB4Inll
cyI7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNo
byAiSEFWRV9MSUJweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iIHwgJGFzX3RyX2NwcGAgMQotX0FD
RU9GCi0KLSAgTElCUz0iLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24gJExJQlMiCiAKLWVsc2UK
LSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgcHl0aG9uIGRldmVs
b3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1Ci1maQorICBmaQogCi1DUFBGTEFHUz0kYWNfcHJl
dmlvdXNfY3BwZmxhZ3MKLUxETEZBR1M9JGFjX3ByZXZpb3VzX2xkZmxhZ3MKIAogCi1maQotIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIKKyAgIyBj
aGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hv
X24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9w
YXRoX1hHRVRURVhUK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P
Q0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGNhc2UgJFhHRVRURVhUIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9w
YXRoX1hHRVRURVhUPSIkWEdFVFRFWFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FN
TD0iJE9DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
WEdFVFRFWFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19P
Q0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
ICAgICBicmVhayAyCiAgIGZpCkBAIC02NTIyLDQ0ICs0MjIwLDM5IEBAIGRvbmUKICAgZG9uZQog
SUZTPSRhc19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1hHRVRURVhUIiAmJiBh
Y19jdl9wYXRoX1hHRVRURVhUPSJubyIKLSAgOzsKLWVzYWMKIGZpCi1YR0VUVEVYVD0kYWNfY3Zf
cGF0aF9YR0VUVEVYVAotaWYgdGVzdCAtbiAiJFhHRVRURVhUIjsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhHRVRURVhUIiA+JjUKLSRh
c19lY2hvICIkWEdFVFRFWFQiID4mNjsgfQorZmkKK09DQU1MPSRhY19jdl9wcm9nX09DQU1MCitp
ZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkT0NBTUwiID4mNQorJGFzX2VjaG8gIiRPQ0FNTCIgPiY2OyB9
CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1pZiB0ZXN0IHgiJHtYR0VU
VEVYVH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k
IHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIgIiRMSU5FTk8iIDUKIGZpCi0jIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGFzODY7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRh
Y19jdl9wcm9nX09DQU1MIjsgdGhlbgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWw7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19j
dl9wYXRoX0FTODYrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj
X2N0X09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKIGVsc2UKLSAgY2FzZSAkQVM4NiBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3Zf
cGF0aF9BUzg2PSIkQVM4NiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MPSIkYWNfY3RfT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgor
ZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBp
biAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcGF0aF9BUzg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAg
IGJyZWFrIDIKICAgZmkKQEAgLTY1NjcsNDQgKzQyNjAsNTMgQEAgZG9uZQogICBkb25lCiBJRlM9
JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQVM4NiIgJiYgYWNfY3ZfcGF0
aF9BUzg2PSJubyIKLSAgOzsKLWVzYWMKIGZpCi1BUzg2PSRhY19jdl9wYXRoX0FTODYKLWlmIHRl
c3QgLW4gIiRBUzg2IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJEFTODYiID4mNQotJGFzX2VjaG8gIiRBUzg2IiA+JjY7IH0KK2ZpCith
Y19jdF9PQ0FNTD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N0X09DQU1MIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUwiID4mNjsgfQog
ZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7QVM4Nn0i
ID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGFzODYs
IHBsZWFzZSBpbnN0YWxsIGFzODYiICIkTElORU5PIiA1CisgIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUwiID0geDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2lu
ZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190
b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwKKyAgZmkKK2Vs
c2UKKyAgT0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgogZmkKLSMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAibGQ4NiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z
ZXQgZHVtbXkgbGQ4NjsgYWNfd29yZD0kMgorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAK
KyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxk
ZXA7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0xEODYrc2V0fSIgPSBzZXQ7
IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MREVQK3NldH0iID0gc2V0OyB0aGVu
IDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkTEQ4NiBpbgot
ICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9MRDg2PSIkTEQ4NiIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1MREVQ
IjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9MRDg2PSIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxkZXAiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAt
NjYxMiw0NCArNDMxNCwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0
ZXN0IC16ICIkYWNfY3ZfcGF0aF9MRDg2IiAmJiBhY19jdl9wYXRoX0xEODY9Im5vIgotICA7Owot
ZXNhYwogZmkKLUxEODY9JGFjX2N2X3BhdGhfTEQ4NgotaWYgdGVzdCAtbiAiJExEODYiOyB0aGVu
Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkTEQ4
NiIgPiY1Ci0kYXNfZWNobyAiJExEODYiID4mNjsgfQorZmkKK09DQU1MREVQPSRhY19jdl9wcm9n
X09DQU1MREVQCitpZiB0ZXN0IC1uICIkT0NBTUxERVAiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxERVAiID4mNQorJGFzX2Vj
aG8gIiRPQ0FNTERFUCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkK
IAogCi1pZiB0ZXN0IHgiJHtMRDg2fSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19mbl9lcnJvciAk
PyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGluc3RhbGwgbGQ4NiIgIiRMSU5FTk8iIDUK
IGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJjYyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgYmNjOyBhY193b3JkPSQyCitpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1M
REVQCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3Jk
PSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYg
dGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MREVQK3NldH0iID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkQkNDIGluCi0gIFtcXC9d
KiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0JDQz0iJEJDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MREVQIjsg
dGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxERVAiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZl
X0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9CQ0M9IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0ib2NhbWxk
ZXAiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjY1
NywyODMgKzQzNTQsMjQxIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi0gIHRl
c3QgLXogIiRhY19jdl9wYXRoX0JDQyIgJiYgYWNfY3ZfcGF0aF9CQ0M9Im5vIgotICA7OwotZXNh
YwogZmkKLUJDQz0kYWNfY3ZfcGF0aF9CQ0MKLWlmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQkNDIiA+JjUK
LSRhc19lY2hvICIkQkNDIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTERFUD0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTERFUAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MREVQIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1M
REVQIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxERVAiID4mNjsgfQogZWxzZQogICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFz
X2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7QkNDfSIgPT0geCJubyIKLXRo
ZW4KLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmNjLCBwbGVhc2UgaW5zdGFs
bCBiY2MiICIkTElORU5PIiA1CisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxERVAiID0geDsgdGhl
bgorICAgIE9DQU1MREVQPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzok
YWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5l
ZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTERFUD0kYWNfY3RfT0NBTUxERVAKKyAgZmkKK2Vsc2UK
KyAgT0NBTUxERVA9IiRhY19jdl9wcm9nX09DQU1MREVQIgogZmkKLSMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiaWFzbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgaWFzbDsgYWNfd29yZD0kMgorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxt
a3RvcAorICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4
fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0lBU0wrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MTUtUT1Arc2V0fSIg
PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNl
ICRJQVNMIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0lBU0w9IiRJQVNM
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAg
KikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1u
ICIkT0NBTUxNS1RPUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QPSIkT0NBTUxNS1RP
UCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9
JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0lBU0w9IiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QPSIk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAg
ICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0KLSAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfSUFTTCIgJiYgYWNfY3ZfcGF0aF9JQVNMPSJubyIKLSAgOzsKLWVz
YWMKLWZpCi1JQVNMPSRhY19jdl9wYXRoX0lBU0wKLWlmIHRlc3QgLW4gIiRJQVNMIjsgdGhlbgot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElBU0wi
ID4mNQotJGFzX2VjaG8gIiRJQVNMIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2
OyB9Ci1maQotCi0KLWlmIHRlc3QgeCIke0lBU0x9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2Zu
X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNsLCBwbGVhc2UgaW5zdGFsbCBpYXNsIiAiJExJ
TkVOTyIgNQotZmkKLQotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1
aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4g
OgotCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHV1aWRfY2xlYXIgaW4gLWx1dWlkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl91
dWlkX3V1aWRfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHV1
aWQgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot
LyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHBy
b3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0
IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg
YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVz
cGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIHV1aWRfY2xlYXIgKCk7Ci1pbnQKLW1haW4g
KCkKLXsKLXJldHVybiB1dWlkX2NsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9G
Ci1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl91dWlk
X3V1aWRfY2xlYXI9eWVzCi1lbHNlCi0gIGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXI9bm8KLWZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVf
TElCUwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl91
dWlkX3V1aWRfY2xlYXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfdXVpZF91dWlkX2Ns
ZWFyIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYnV1aWQ9InkiCi1maQotCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAogZmkKLQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9t
b25ncmVsICIkTElORU5PIiAidXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfaCIgIiRhY19pbmNs
dWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF9oIiA9IHgiInllczsg
dGhlbiA6Ci0gIGxpYnV1aWQ9InkiCiBmaQotCi0KLWlmIHRlc3QgIiRsaWJ1dWlkIiAhPSAieSI7
IHRoZW4gOgotCi0gICAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBs
aWJyYXJ5IiAiJExJTkVOTyIgNQotCitPQ0FNTE1LVE9QPSRhY19jdl9wcm9nX09DQU1MTUtUT1AK
K2lmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtUT1AiID4mNQorJGFzX2VjaG8gIiRP
Q0FNTE1LVE9QIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCiAK
LWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJjdXJzZXMuaCIgImFjX2N2
X2hlYWRlcl9jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19j
dl9oZWFkZXJfY3Vyc2VzX2giID0geCIieWVzOyB0aGVuIDoKLQotICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vyc2Vz
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcy4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfY3Vyc2VzX2NsZWFyK3NldH0iID0gc2V0OyB0aGVu
IDoKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19j
dF9PQ0FNTE1LVE9QPSRPQ0FNTE1LVE9QCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
b2NhbWxta3RvcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgb2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sY3Vy
c2VzICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
LS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1
c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBjbGVhciAoKTsKLWludAotbWFpbiAoKQot
ewotcmV0dXJuIGNsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9jdXJzZXNfY2xlYXI9
eWVzCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MTUtUT1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KIGVsc2UKLSAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj1ubworYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8K
KyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9wIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCiBmaQot
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfY3Vyc2Vz
X2NsZWFyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPSB4IiJ5
ZXM7IHRoZW4gOgotICBjdXJzZXM9InkiCithY19jdF9PQ0FNTE1LVE9QPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MTUtUT1AKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09D
QU1MTUtUT1AiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KIGVsc2UK
LSAgY3Vyc2VzPSJuIgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQorICBpZiB0ZXN0
ICJ4JGFjX2N0X09DQU1MTUtUT1AiID0geDsgdGhlbgorICAgIE9DQU1MTUtUT1A9Im5vIgorICBl
bHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1M
TUtUT1A9JGFjX2N0X09DQU1MTUtUT1AKKyAgZmkKIGVsc2UKLSAgY3Vyc2VzPSJuIgorICBPQ0FN
TE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgogZmkKIAogCi1hY19mbl9jX2NoZWNrX2hl
YWRlcl9tb25ncmVsICIkTElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNf
aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbmN1cnNl
c19oIiA9IHgiInllczsgdGhlbiA6Ci0KLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMiID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sbmN1cnNlcy4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9saWJfbmN1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxt
a2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0i
LWxuY3Vyc2VzICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRl
cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGlu
dCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRo
ZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYg
X19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBjbGVhciAoKTsKLWludAotbWFp
biAoKQotewotcmV0dXJuIGNsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1p
ZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9uY3Vyc2Vz
X2NsZWFyPXllcworICBpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJv
Z19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl
c3QuCiBlbHNlCi0gIGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyPW5vCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFz
X3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtMSUI9
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
KyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwogZmkK
LXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9M
SUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9uY3Vy
c2VzX2NsZWFyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0g
eCIieWVzOyB0aGVuIDoKLSAgbmN1cnNlcz0ieSIKK09DQU1MTUtMSUI9JGFjX2N2X3Byb2dfT0NB
TUxNS0xJQgoraWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS0xJQiIgPiY1CiskYXNf
ZWNobyAiJE9DQU1MTUtMSUIiID4mNjsgfQogZWxzZQotICBuY3Vyc2VzPSJuIgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotZWxzZQotICBuY3Vyc2VzPSJuIgogZmkKLQotCi1pZiB0
ZXN0ICIkY3Vyc2VzIiA9ICJuIiAmJiB0ZXN0ICIkbmN1cnNlcyIgPSAibiI7IHRoZW4gOgotCi0g
ICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgY3Vyc2VzIGxpYnJh
cnkiICIkTElORU5PIiA1CitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIjsgdGhl
bgorICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgb2NhbWxta2xpYjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsg
dGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9PQ0FNTE1LTElCIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxN
S0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAy
CisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAogZmkKLSMgUHJlZmVyIG5j
dXJzZXMgb3ZlciBjdXJzZXMgaWYgYm90aCBhcmUgcHJlc2VudAotaWYgdGVzdCAiJG5jdXJzZXMi
ID0gInkiOyB0aGVuIDoKLQotICAgIENVUlNFU19MSUJTPSItbG5jdXJzZXMiCi0KLSRhc19lY2hv
ICIjZGVmaW5lIElOQ0xVREVfQ1VSU0VTX0ggPG5jdXJzZXMuaD4iID4+Y29uZmRlZnMuaAotCi0K
K2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2Vj
aG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KIGVsc2UKLQotICAgIENVUlNFU19MSUJTPSIt
bGN1cnNlcyIKLQotJGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNfSCA8Y3Vyc2VzLmg+
IiA+PmNvbmZkZWZzLmgKLQotCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAorICBpZiB0
ZXN0ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgorICAgIE9DQU1MTUtMSUI9Im5vIgor
ICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVz
OikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNp
bmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19l
Y2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9D
QU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKKyAgZmkKK2Vsc2UKKyAgT0NBTUxNS0xJQj0iJGFj
X2N2X3Byb2dfT0NBTUxNS0xJQiIKK2ZpCiAKIAotCi0KLQotCi0KLWlmIHRlc3QgIngkYWNfY3Zf
ZW52X1BLR19DT05GSUdfc2V0IiAhPSAieHNldCI7IHRoZW4KLQlpZiB0ZXN0IC1uICIkYWNfdG9v
bF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1wa2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25maWc7IGFjX3dvcmQ9JDIKKyAg
IyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4Ijsg
dGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxkb2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19j
dl9wYXRoX1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9w
cm9nX09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKIGVsc2UKLSAgY2FzZSAkUEtHX0NPTkZJRyBpbgotICBbXFwvXSogfCA/OltcXC9dKikK
LSAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgor
ICBhY19jdl9wcm9nX09DQU1MRE9DPSIkT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgog
Zm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0
YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9
OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxk
b2MiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjk0
MSwxMyArNDU5NiwxMiBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICA7Owot
ZXNhYwogZmkKLVBLR19DT05GSUc9JGFjX2N2X3BhdGhfUEtHX0NPTkZJRwotaWYgdGVzdCAtbiAi
JFBLR19DT05GSUciOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1Ci0kYXNfZWNobyAiJFBLR19DT05GSUciID4m
NjsgfQorZmkKK09DQU1MRE9DPSRhY19jdl9wcm9nX09DQU1MRE9DCitpZiB0ZXN0IC1uICIkT0NB
TUxET0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRPQ0FNTERPQyIgPiY2OyB9CiBlbHNl
CiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQpAQCAtNjk1NSwyOCArNDYwOSwyNiBAQCBmaQogCiAK
IGZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIjsgdGhlbgotICBhY19wdF9Q
S0dfQ09ORklHPSRQS0dfQ09ORklHCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGtn
LWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVt
bXkgcGtnLWNvbmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxE
T0MiOyB0aGVuCisgIGFjX2N0X09DQU1MRE9DPSRPQ0FNTERPQworICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSBvY2FtbGRvYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3BhdGhfYWNfcHRfUEtHX0NPTkZJRytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2Fj
X2N2X3Byb2dfYWNfY3RfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCi0gIFtc
XC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19wdF9Q
S0dfQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4K
LSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxET0M9IiRhY19jdF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGly
IGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAg
ICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0ib2NhbWxkb2MiCiAgICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjk4NCwyMCArNDYzNiwxOSBA
QCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICA7OwotZXNhYwogZmkKLWFjX3B0
X1BLR19DT05GSUc9JGFjX2N2X3BhdGhfYWNfcHRfUEtHX0NPTkZJRwotaWYgdGVzdCAtbiAiJGFj
X3B0X1BLR19DT05GSUciOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfcHRfUEtHX0NPTkZJRyIgPiY1Ci0kYXNfZWNobyAiJGFjX3B0
X1BLR19DT05GSUciID4mNjsgfQorZmkKK2FjX2N0X09DQU1MRE9DPSRhY19jdl9wcm9nX2FjX2N0
X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxET0Mi
ID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERPQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNo
byAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05GSUciID0geDsg
dGhlbgotICAgIFBLR19DT05GSUc9IiIKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTERPQyIgPSB4
OyB0aGVuCisgICAgT0NBTUxET0M9Im5vIgogICBlbHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgogeWVzOikKQEAgLTcwMDUsNjI0ICs0NjU2LDcxOCBAQCB5
ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBl
c2FjCi0gICAgUEtHX0NPTkZJRz0kYWNfcHRfUEtHX0NPTkZJRworICAgIE9DQU1MRE9DPSRhY19j
dF9PQ0FNTERPQwogICBmaQogZWxzZQotICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09O
RklHIgotZmkKLQotZmkKLWlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgotCV9wa2dfbWlu
X3ZlcnNpb249MC45LjAKLQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQgbGVhc3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lv
biIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNp
b24gJF9wa2dfbWluX3ZlcnNpb24uLi4gIiA+JjY7IH0KLQlpZiAkUEtHX0NPTkZJRyAtLWF0bGVh
c3QtcGtnY29uZmlnLXZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb247IHRoZW4KLQkJeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Ci0kYXNfZWNo
byAieWVzIiA+JjY7IH0KLQllbHNlCi0JCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCQlQS0dfQ09O
RklHPSIiCi0JZmkKLWZpCi0KLXBrZ19mYWlsZWQ9bm8KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdsaWIiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGdsaWIuLi4gIiA+JjY7IH0KLQotaWYgdGVzdCAtbiAiJGdsaWJfQ0ZMQUdTIjsg
dGhlbgotICAgIHBrZ19jdl9nbGliX0NGTEFHUz0iJGdsaWJfQ0ZMQUdTIgotIGVsaWYgdGVzdCAt
biAiJFBLR19DT05GSUciOyB0aGVuCi0gICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwK
LSAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09O
RklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1Ci0gICgkUEtH
X0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1Ci0gIGFjX3N0
YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgotICBwa2dfY3Zf
Z2xpYl9DRkxBR1M9YCRQS0dfQ09ORklHIC0tY2ZsYWdzICJnbGliLTIuMCIgMj4vZGV2L251bGxg
Ci1lbHNlCi0gIHBrZ19mYWlsZWQ9eWVzCi1maQotIGVsc2UKLSAgICBwa2dfZmFpbGVkPXVudHJp
ZWQKLWZpCi1pZiB0ZXN0IC1uICIkZ2xpYl9MSUJTIjsgdGhlbgotICAgIHBrZ19jdl9nbGliX0xJ
QlM9IiRnbGliX0xJQlMiCi0gZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KLSAgICBp
ZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAotICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMg
XCJnbGliLTIuMFwiIjsgfSA+JjUKLSAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJy
b3JzICJnbGliLTIuMCIpIDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9OyB0aGVuCi0gIHBrZ19jdl9nbGliX0xJQlM9YCRQS0dfQ09ORklHIC0tbGli
cyAiZ2xpYi0yLjAiIDI+L2Rldi9udWxsYAotZWxzZQotICBwa2dfZmFpbGVkPXllcwotZmkKLSBl
bHNlCi0gICAgcGtnX2ZhaWxlZD11bnRyaWVkCi1maQotCi0KLQotaWYgdGVzdCAkcGtnX2ZhaWxl
ZCA9IHllczsgdGhlbgotICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCi1pZiAkUEtHX0NPTkZJ
RyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgotICAgICAgICBfcGtnX3No
b3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCi1lbHNlCi0gICAgICAgIF9wa2dfc2hvcnRfZXJyb3Jz
X3N1cHBvcnRlZD1ubworICBPQ0FNTERPQz0iJGFjX2N2X3Byb2dfT0NBTUxET0MiCiBmaQotICAg
ICAgICBpZiB0ZXN0ICRfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQgPSB5ZXM7IHRoZW4KLQkg
ICAgICAgIGdsaWJfUEtHX0VSUk9SUz1gJFBLR19DT05GSUcgLS1zaG9ydC1lcnJvcnMgLS1wcmlu
dC1lcnJvcnMgImdsaWItMi4wIiAyPiYxYAotICAgICAgICBlbHNlCi0JICAgICAgICBnbGliX1BL
R19FUlJPUlM9YCRQS0dfQ09ORklHIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKLSAg
ICAgICAgZmkKLQkjIFB1dCB0aGUgbmFzdHkgZXJyb3IgbWVzc2FnZSBpbiBjb25maWcubG9nIHdo
ZXJlIGl0IGJlbG9uZ3MKLQllY2hvICIkZ2xpYl9QS0dfRVJST1JTIiA+JjUKLQotCWFzX2ZuX2Vy
cm9yICQ/ICJQYWNrYWdlIHJlcXVpcmVtZW50cyAoZ2xpYi0yLjApIHdlcmUgbm90IG1ldDoKLQot
JGdsaWJfUEtHX0VSUk9SUwotCi1Db25zaWRlciBhZGp1c3RpbmcgdGhlIFBLR19DT05GSUdfUEFU
SCBlbnZpcm9ubWVudCB2YXJpYWJsZSBpZiB5b3UKLWluc3RhbGxlZCBzb2Z0d2FyZSBpbiBhIG5v
bi1zdGFuZGFyZCBwcmVmaXguCi0KLUFsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZp
cm9ubWVudCB2YXJpYWJsZXMgZ2xpYl9DRkxBR1MKLWFuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhl
IG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgotU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZv
ciBtb3JlIGRldGFpbHMuIiAiJExJTkVOTyIgNQotZWxpZiB0ZXN0ICRwa2dfZmFpbGVkID0gdW50
cmllZDsgdGhlbgotICAgICAJeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci0JeyB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0k
YXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJv
ciAkPyAiVGhlIHBrZy1jb25maWcgc2NyaXB0IGNvdWxkIG5vdCBiZSBmb3VuZCBvciBpcyB0b28g
b2xkLiAgTWFrZSBzdXJlIGl0Ci1pcyBpbiB5b3VyIFBBVEggb3Igc2V0IHRoZSBQS0dfQ09ORklH
IGVudmlyb25tZW50IHZhcmlhYmxlIHRvIHRoZSBmdWxsCi1wYXRoIHRvIHBrZy1jb25maWcuCiAK
LUFsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZpcm9ubWVudCB2YXJpYWJsZXMgZ2xp
Yl9DRkxBR1MKLWFuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29u
ZmlnLgotU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuCiAKLVRv
IGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+
LgotU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Cisg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxidWlsZCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19PQ0FNTEJVSUxEK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLQlnbGliX0NGTEFHUz0kcGtnX2N2X2dsaWJfQ0ZMQUdT
Ci0JZ2xpYl9MSUJTPSRwa2dfY3ZfZ2xpYl9MSUJTCi0gICAgICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIg
PiY2OyB9Ci0KLWZpCi0KLSMgQ2hlY2sgbGlicmFyeSBwYXRoCi1pZiB0ZXN0ICJcJHtleGVjX3By
ZWZpeH0vbGliIiA9ICIkbGliZGlyIjsgdGhlbiA6Ci0gIGlmIHRlc3QgIiRleGVjX3ByZWZpeCIg
PSAiTk9ORSIgJiYgdGVzdCAiJHByZWZpeCIgIT0gIk5PTkUiOyB0aGVuIDoKLSAgZXhlY19wcmVm
aXg9JHByZWZpeAotZmkKLSAgICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0gIk5PTkUiOyB0aGVu
IDoKLSAgZXhlY19wcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4Ci1maQotICAgIGlmIHRlc3QgLWQg
IiR7ZXhlY19wcmVmaXh9L2xpYjY0IjsgdGhlbiA6Ci0KLSAgICAgICAgTElCX1BBVEg9ImxpYjY0
IgotCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1M
QlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVs
c2UKLQotICAgICAgICBMSUJfUEFUSD0ibGliIgorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUwor
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sYnVpbGQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCi0KLWVsc2UKLQot
ICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVjX3ByZWZpeCIgKyAxYH0i
Ci0KIGZpCi0KLQotIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KLWFjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJiemxpYi5oIiAiYWNfY3ZfaGVhZGVyX2J6bGliX2giICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2J6bGliX2giID0geCIi
eWVzOyB0aGVuIDoKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgQloyX2J6RGVjb21wcmVzc0luaXQgaW4gLWxiejIiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGJ6MiAgJExJQlMiCi1jYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0K
LS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9y
LgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m
IGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQg
c3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYK
LWNoYXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBC
WjJfYnpEZWNvbXByZXNzSW5pdCAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfYnoyX0JaMl9i
ekRlY29tcHJlc3NJbml0PXllcworT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19PQ0FNTEJVSUxECitp
ZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJVSUxEIiA+JjUKKyRhc19lY2hvICIkT0NB
TUxCVUlMRCIgPiY2OyB9CiBlbHNlCi0gIGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0lu
aXQ9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
LSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tf
bGliX3NhdmVfTElCUwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1Ci0kYXNf
ZWNobyAiJGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNjsgfQotaWYgdGVz
dCAieCRhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0IiA9IHgiInllczsgdGhlbiA6
Ci0gIHpsaWI9IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CiBmaQogCiAKIGZpCi0KLQotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVO
TyIgImx6bWEuaCIgImFjX2N2X2hlYWRlcl9sem1hX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIK
LWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2x6bWFfaCIgPSB4IiJ5ZXM7IHRoZW4gOgotCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem1hX3N0
cmVhbV9kZWNvZGVyIGluIC1sbHptYSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgbHpt
YV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdF9PQ0FNTEJVSUxEPSRP
Q0FNTEJVSUxECisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxidWls
ZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRCtz
ZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0g
IGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sbHptYSAgJExJQlMiCi1jYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMu
aC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lk
IGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVy
biB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5
cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMi
Ci0jZW5kaWYKLWNoYXIgbHptYV9zdHJlYW1fZGVjb2RlciAoKTsKLWludAotbWFpbiAoKQotewot
cmV0dXJuIGx6bWFfc3RyZWFtX2RlY29kZXIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNF
T0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2x6
bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj15ZXMKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJ
TEQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09DQU1MQlVJ
TEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQotICBhY19jdl9saWJf
bHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5vCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9Im9jYW1s
YnVpbGQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3Qu
JGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bWFfbHptYV9z
dHJlYW1fZGVjb2RlciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFt
X2RlY29kZXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9k
ZWNvZGVyIiA9IHgiInllczsgdGhlbiA6Ci0gIHpsaWI9IiR6bGliIC1ESEFWRV9MWk1BIC1sbHpt
YSIKK2FjX2N0X09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNo
byAiJGFjX2N0X09DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KIGZpCiAKLQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQlVJTEQiID0geDsgdGhlbgorICAg
IE9DQU1MQlVJTEQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190
b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0
cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz
IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXll
cyA7OworZXNhYworICAgIE9DQU1MQlVJTEQ9JGFjX2N0X09DQU1MQlVJTEQKKyAgZmkKK2Vsc2UK
KyAgT0NBTUxCVUlMRD0iJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCIKIGZpCiAKIAotYWNfZm5fY19j
aGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVhZGVy
X2x6b19sem8xeF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hl
YWRlcl9sem9fbHpvMXhfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICAgIGlmIHRlc3QgIngkT0NBTUxD
IiA9ICJ4bm8iOyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgbHpvMXhfZGVjb21wcmVzcyBpbiAtbGx6bzIiID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGx6bzIgICRMSUJTIgotY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLworICAg
ICAgICBpZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CiAKLS8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgot
ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg
R0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp
bGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNo
YXIgbHpvMXhfZGVjb21wcmVzcyAoKTsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGx6bzF4X2Rl
Y29tcHJlc3MgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVz
cz15ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcz1ubwotZmkKLXJt
IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT
CisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVu
YWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVOTyIgNQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21w
cmVzcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4m
NjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA9IHgiInll
czsgdGhlbiA6Ci0gIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCisgICAgICAgIG9j
YW1sdG9vbHM9Im4iCisKIGZpCiAKK2ZpCisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJh
c2giLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGJh
c2g7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX0JBU0grc2V0fSIgPSBzZXQ7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCQVNI
IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAg
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU
SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf
cGF0aF9CQVNIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUwogCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3BhdGhfQkFTSD0i
bm8iCisgIDs7Citlc2FjCitmaQorQkFTSD0kYWNfY3ZfcGF0aF9CQVNICitpZiB0ZXN0IC1uICIk
QkFTSCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRCQVNIIiA+JjUKKyRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQogZmkKIAogCitpZiB0ZXN0IHgiJHtCQVNIfSIgPT0geCJubyIKK3Ro
ZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmFzaCwgcGxlYXNlIGluc3Rh
bGwgYmFzaCIgIiRMSU5FTk8iIDUKK2ZpCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKLSRhc19lY2hv
X24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQotaWYgdGVzdCAi
JHthY19jdl9saWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKK2FjX2V4dD1jCith
Y19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZM
QUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4m
NScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVw
cm9jZXNzb3IiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVw
cm9jZXNzb3IuLi4gIiA+JjY7IH0KKyMgT24gU3Vucywgc29tZXRpbWVzICRDUFAgbmFtZXMgYSBk
aXJlY3RvcnkuCitpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIkQ1BQIjsgdGhlbgorICBD
UFA9CitmaQoraWYgdGVzdCAteiAiJENQUCI7IHRoZW4KKyAgaWYgdGVzdCAiJHthY19jdl9wcm9n
X0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sYWlvICAkTElCUyIK
LWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICMgRG91
YmxlIHF1b3RlcyBiZWNhdXNlIENQUCBuZWVkcyB0byBiZSBleHBhbmRlZAorICAgIGZvciBDUFAg
aW4gIiRDQyAtRSIgIiRDQyAtRSAtdHJhZGl0aW9uYWwtY3BwIiAiL2xpYi9jcHAiCisgICAgZG8K
KyAgICAgIGFjX3ByZXByb2Nfb2s9ZmFsc2UKK2ZvciBhY19jX3ByZXByb2Nfd2Fybl9mbGFnIGlu
ICcnIHllcworZG8KKyAgIyBVc2UgYSBoZWFkZXIgZmlsZSB0aGF0IGNvbWVzIHdpdGggZ2NjLCBz
byBjb25maWd1cmluZyBnbGliYworICAjIHdpdGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jr
cy4KKyAgIyBQcmVmZXIgPGxpbWl0cy5oPiB0byA8YXNzZXJ0Lmg+IGlmIF9fU1REQ19fIGlzIGRl
ZmluZWQsIHNpbmNlCisgICMgPGxpbWl0cy5oPiBleGlzdHMgZXZlbiBvbiBmcmVlc3RhbmRpbmcg
Y29tcGlsZXJzLgorICAjIE9uIHRoZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2gg
dGhlIGNvbXBpbGVyJ3MgcGFyc2VyLAorICAjIG5vdCBqdXN0IHRocm91Z2ggY3BwLiAiU3ludGF4
IGVycm9yIiBpcyBoZXJlIHRvIGNhdGNoIHRoaXMgY2FzZS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBP
dmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAg
IFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdD
QwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs
IGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgorI2lmZGVmIF9fU1RE
Q19fCisjIGluY2x1ZGUgPGxpbWl0cy5oPgorI2Vsc2UKKyMgaW5jbHVkZSA8YXNzZXJ0Lmg+CiAj
ZW5kaWYKLWNoYXIgaW9fc2V0dXAgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBpb19zZXR1
cCAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KKwkJICAgICBTeW50YXggZXJyb3IKIF9BQ0VPRgot
aWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfYWlvX2lv
X3NldHVwPXllcworaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisKIGVsc2UK
LSAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4k
YWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisgICMgQnJva2VuOiBmYWlscyBv
biB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKLSRhc19l
Y2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKLSAgc3lzdGVtX2Fpbz0ieSIKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3Jr
cyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwor
ICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNf
bm9uZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQogZWxz
ZQotICBzeXN0ZW1fYWlvPSJuIgorICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19v
az06CiticmVhaworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRh
Y19leHQKKworZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdz
IGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisgIGJyZWFrCiBm
aQogCisgICAgZG9uZQorICAgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKIAoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8uLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAogZWxz
ZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGNyeXB0byAgJExJQlMi
Ci1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X3By
b2dfQ1BQPSRDUFAKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENQUCIgPiY1CiskYXNfZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29r
PWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNl
IGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMK
KyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1p
dHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxs
aW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0
aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNl
ciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBj
YXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRl
cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGlu
dCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRo
ZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYg
X19jcGx1c3BsdXMKLWV4dGVybiAiQyIKKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1p
dHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgogI2VuZGlmCi1jaGFyIE1ENSAoKTsK
LWludAotbWFpbiAoKQotewotcmV0dXJuIE1ENSAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KKwkJ
ICAgICBTeW50YXggZXJyb3IKIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7
IHRoZW4gOgotICBhY19jdl9saWJfY3J5cHRvX01ENT15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAi
JExJTkVOTyI7IHRoZW4gOgorCiBlbHNlCi0gIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PW5vCi1maQot
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlMKKyAgIyBCcm9rZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgorY29udGludWUKIGZpCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9j
cnlwdG9fTUQ1IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQot
aWYgdGVzdCAieCRhY19jdl9saWJfY3J5cHRvX01ENSIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKK3JtIC1mIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3JrcyBv
biBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAj
IGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9u
ZXhpc3RlbnQuaD4KIF9BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6
CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQor
ICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKIAotICBMSUJTPSItbGNy
eXB0byAkTElCUyIKK2RvbmUKKyMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVM
U0UncyBjbGVhbmluZyBjb2RlIHdhcyBza2lwcGVkLgorcm0gLWYgY29uZnRlc3QuaSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX2V4dAoraWYgJGFjX3ByZXByb2Nfb2s7IHRoZW4gOgogCiBlbHNl
Ci0gIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJjcnlwdG8iICIkTElORU5PIiA1
CisgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6
IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gIkMgcHJlcHJvY2Vzc29yIFwiJENQUFwiIGZhaWxzIHNh
bml0eSBjaGVjaworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDUgOyB9CiBmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcy4uLiAiID4mNjsgfQotaWYgdGVzdCAi
JHthY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMitzZXR9IiA9IHNldDsgdGhlbiA6CithY19l
eHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdT
ICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVz
dCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAk
TElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKworeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3JlcCB0
aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3BhdGhfR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJ
QlM9Ii1sZXh0MmZzICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyAgaWYgdGVzdCAteiAiJEdSRVAiOyB0
aGVuCisgIGFjX3BhdGhfR1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhyb3VnaCB0aGUgdXNl
cidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAorICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhfU0VQ
QVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dyZXA7IGRvCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
ICAgICBhY19wYXRoX0dSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAgICB7
IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0dSRVAiOyB9
IHx8IGNvbnRpbnVlCisjIENoZWNrIGZvciBHTlUgYWNfcGF0aF9HUkVQIGFuZCBzZWxlY3QgaXQg
aWYgaXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9HUkVQCitjYXNlIGAi
JGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0aF9H
UkVQPSIkYWNfcGF0aF9HUkVQIiBhY19wYXRoX0dSRVBfZm91bmQ9Ojs7CisqKQorICBhY19jb3Vu
dD0wCisgICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6Cisg
IGRvCisgICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIK
KyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0Lmlu
IiAiY29uZnRlc3QubmwiCisgICAgJGFzX2VjaG8gJ0dSRVAnID4+ICJjb25mdGVzdC5ubCIKKyAg
ICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gpLScgPCAiY29u
ZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAgIGRpZmYg
ImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKKyAg
ICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAgICBpZiB0
ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCisgICAgICAjIEJl
c3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUK
KyAgICAgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIKKyAgICAgIGFjX3BhdGhfR1JF
UF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBz
ZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFr
CisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNv
bmZ0ZXN0Lm91dDs7Citlc2FjCiAKLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90
eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0
Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1
bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVz
Ci1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgZXh0MmZzX29wZW4yICgpOwotaW50Ci1tYWluICgp
Ci17Ci1yZXR1cm4gZXh0MmZzX29wZW4yICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9G
Ci1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9leHQy
ZnNfZXh0MmZzX29wZW4yPXllcworICAgICAgJGFjX3BhdGhfR1JFUF9mb3VuZCAmJiBicmVhayAz
CisgICAgZG9uZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAt
eiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4KKyAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0
YWJsZSBncmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0
L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKIGVsc2UKLSAgYWNfY3ZfbGliX2V4dDJmc19leHQyZnNf
b3BlbjI9bm8KKyAgYWNfY3ZfcGF0aF9HUkVQPSRHUkVQCiBmaQotcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKwogZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4dDJm
c19leHQyZnNfb3BlbjIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19v
cGVuMiIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA9
IHgiInllczsgdGhlbiA6Ci0gIGxpYmV4dDJmcz0ieSIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9HUkVQIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfcGF0aF9HUkVQIiA+JjY7IH0KKyBHUkVQPSIkYWNfY3ZfcGF0aF9HUkVQIgorCisK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGVn
cmVwIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9wYXRoX0VHUkVQK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgbGliZXh0MmZzPSJuIgorICBpZiBlY2hvIGEgfCAk
R1JFUCAtRSAnKGF8YiknID4vZGV2L251bGwgMj4mMQorICAgdGhlbiBhY19jdl9wYXRoX0VHUkVQ
PSIkR1JFUCAtRSIKKyAgIGVsc2UKKyAgICAgaWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgorICBh
Y19wYXRoX0VHUkVQX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0
aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1Iv
dXNyL3hwZzQvYmluCitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX3Byb2cgaW4gZWdyZXA7IGRvCisgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgICAgICBhY19wYXRo
X0VHUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIk
YWNfcGF0aF9FR1JFUCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNvbnRp
bnVlCisjIENoZWNrIGZvciBHTlUgYWNfcGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlz
IGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfRUdSRVAKK2Nhc2UgYCIkYWNfcGF0
aF9FR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0aF9FR1JFUD0i
JGFjX3BhdGhfRUdSRVAiIGFjX3BhdGhfRUdSRVBfZm91bmQ9Ojs7CisqKQorICBhY19jb3VudD0w
CisgICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6CisgIGRv
CisgICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIKKyAg
ICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0LmluIiAi
Y29uZnRlc3QubmwiCisgICAgJGFzX2VjaG8gJ0VHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAg
IiRhY19wYXRoX0VHUkVQIiAnRUdSRVAkJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQi
IDI+L2Rldi9udWxsIHx8IGJyZWFrCisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3Qu
bmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCAr
IDEgJiYgYWNfY291bnQ9JGFzX3ZhbAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3Bh
dGhfRUdSRVBfbWF4LTB9OyB0aGVuCisgICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBi
dXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUKKyAgICAgIGFjX2N2X3BhdGhfRUdSRVA9
IiRhY19wYXRoX0VHUkVQIgorICAgICAgYWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50CisgICAg
ZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdo
CisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCisgIGRvbmUKKyAgcm0gLWYgY29u
ZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisK
KyAgICAgICRhY19wYXRoX0VHUkVQX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JF
UCI7IHRoZW4KKyAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBi
ZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1
CisgIGZpCitlbHNlCisgIGFjX2N2X3BhdGhfRUdSRVA9JEVHUkVQCiBmaQogCisgICBmaQorZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
cGF0aF9FR1JFUCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQorIEVH
UkVQPSIkYWNfY3ZfcGF0aF9FR1JFUCIKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdCIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdj
cnlwdC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFz
aF9idWZmZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Citp
ZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zdGRjK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UwotTElCUz0iLWxnY3J5cHQgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVk
ZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8ZmxvYXQuaD4KIAot
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Ci0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgot
Y2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gZ2Ny
eV9tZF9oYXNoX2J1ZmZlciAoKTsKKwogICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBh
Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlcj15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9eWVzCiBlbHNlCi0gIGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0
Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCiBm
aQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9s
aWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9s
aWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID0geCIieWVzOyB0aGVuIDoKLSAgbGliZ2Ny
eXB0PSJ5Igorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25m
dGVzdC4kYWNfZXh0CisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCisg
ICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwgY29udHJhcnkgdG8g
QU5TSS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0cmluZy5oPgorCitfQUNFT0YKK2lmIChl
dmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVHUkVQICJtZW1jaHIi
ID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisKIGVsc2UKLSAgbGliZ2NyeXB0PSJuIgorICBhY19j
dl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCiBmaQogCitpZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2Vz
IG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxzdGRsaWIuaD4KIAorX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNf
ZXh0IikgMj4mNSB8CisgICRFR1JFUCAiZnJlZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKIAot
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IHB0aHJlYWQgZmxhZyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZCBmbGFn
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2F4X2N2X3B0aHJlYWRfZmxhZ3Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQorICBhY19jdl9oZWFk
ZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgogCi0gICAgICAgIGF4X2N2X3B0aHJlYWRf
ZmxhZ3M9LXB0aHJlYWQKK2ZpCiAKLSAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJlYWRf
ZmxhZ3MiCi0gICAgUFRIUkVBRF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKLSAgICBQ
VEhSRUFEX0xJQlM9IiIKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCisg
ICMgL2Jpbi9jYyBpbiBJcml4LTQuMC41IGdldHMgbm9uLUFOU0kgY3R5cGUgbWFjcm9zIHVubGVz
cyB1c2luZyAtYW5zaS4KKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g
OgorICA6CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxjdHlwZS5oPgorI2luY2x1ZGUg
PHN0ZGxpYi5oPgorI2lmICgoJyAnICYgMHgwRkYpID09IDB4MDIwKQorIyBkZWZpbmUgSVNMT1dF
UihjKSAoJ2EnIDw9IChjKSAmJiAoYykgPD0gJ3onKQorIyBkZWZpbmUgVE9VUFBFUihjKSAoSVNM
T1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMpKQorI2Vsc2UKKyMgZGVmaW5lIElTTE9X
RVIoYykgXAorCQkgICAoKCdhJyA8PSAoYykgJiYgKGMpIDw9ICdpJykgXAorCQkgICAgIHx8ICgn
aicgPD0gKGMpICYmIChjKSA8PSAncicpIFwKKwkJICAgICB8fCAoJ3MnIDw9IChjKSAmJiAoYykg
PD0gJ3onKSkKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAoKGMpIHwgMHg0MCkg
OiAoYykpCisjZW5kaWYKIAorI2RlZmluZSBYT1IoZSwgZikgKCgoZSkgJiYgIShmKSkgfHwgKCEo
ZSkgJiYgKGYpKSkKK2ludAorbWFpbiAoKQoreworICBpbnQgaTsKKyAgZm9yIChpID0gMDsgaSA8
IDI1NjsgaSsrKQorICAgIGlmIChYT1IgKGlzbG93ZXIgKGkpLCBJU0xPV0VSIChpKSkKKwl8fCB0
b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkKKyAgICAgIHJldHVybiAyOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CiAKLSAgICBz
YXZlZF9DRkxBR1M9IiRDRkxBR1MiCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitmaQor
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorZmkKIAotICAgIHNhdmVkX0xERkxBR1M9IiRMREZMQUdTIgorZmkKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hl
YWRlcl9zdGRjIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KIAotICAgIHNhdmVkX0xJQlM9IiRM
SUJTIgorJGFzX2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAogCitm
aQogCi0gICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQVEhSRUFEX0NGTEFHUyIKKyMgT24gSVJJWCA1LjMs
IHN5cy90eXBlcyBhbmQgaW50dHlwZXMuaCBhcmUgY29uZmxpY3RpbmcuCitmb3IgYWNfaGVhZGVy
IGluIHN5cy90eXBlcy5oIHN5cy9zdGF0Lmggc3RkbGliLmggc3RyaW5nLmggbWVtb3J5Lmggc3Ry
aW5ncy5oIFwKKwkJICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0ZC5oCitkbyA6CisgIGFzX2Fj
X0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAK
K2FjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFz
X2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQi
JGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAg
MQorX0FDRU9GCiAKLSAgICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgorZmkK
IAotICAgIExJQlM9IiRMSUJTICRQVEhSRUFEX0xJQlMiCitkb25lCiAKLSAgICAgICAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwogCi0jaW5jbHVkZSA8cHRocmVhZC5oPgotaW50IG1haW4odm9pZCkgewotICBwdGhyZWFk
X2F0Zm9yaygwLDAsMCk7Ci0gIHB0aHJlYWRfY3JlYXRlKDAsMCwwLDApOwotfQoraWYgdGVzdCAi
eCRweXRob250b29scyIgPSAieHkiOyB0aGVuIDoKIAotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6CisgICAgaWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJe
LyI7IHRoZW4gOgogCisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049
YGJhc2VuYW1lICRQWVRIT05QQVRIYAorCitlbGlmIHRlc3QgLXogIiRQWVRIT04iOyB0aGVuIDoK
KyAgUFlUSE9OPSJweXRob24iCiBlbHNlCi0gIGF4X2N2X3B0aHJlYWRfZmxhZ3M9ZmFpbGVkCisg
IGFzX2ZuX2Vycm9yICQ/ICJQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRl
IHBhdGgiICIkTElORU5PIiA1CiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAg
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRQWVRIT04iLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRQWVRIT047IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRQWVRIT05QQVRIIGluCisg
IFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9IiRQWVRIT05QQVRI
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAg
KikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBp
biAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAg
YWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUwogCi0gICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgorICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgor
ICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAoraWYgdGVz
dCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKLSAgICBMREZM
QUdTPSIkc2F2ZWRfTERGTEFHUyIKIAotICAgIExJQlM9IiRzYXZlZF9MSUJTIgoraWYgdGVzdCB4
IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1Citm
aQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBvcnQg
c3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKK2lmIHRl
c3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYx
YAorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICAgIGFzX2ZuX2Vycm9yICQ/ICIkcHl0aG9u
X3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMyIgIiRM
SU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKIAorYWNfcHJl
dmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCithY19wcmV2aW91c19sZGZsYWdzPSRMREZMQUdTCith
Y19weXRob25fdmVyc2lvbj1gJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7
IFwKKyAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJWRVJTSU9O
IiknYAorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OLWNvbmZpZyIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJFBZVEhPTi1jb25m
aWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX3B5Y29uZmlnK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAk
cHljb25maWcgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfcHljb25maWc9
IiRweWNvbmZpZyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGgu
CisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3BhdGhfcHljb25maWc9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfcHljb25m
aWciICYmIGFjX2N2X3BhdGhfcHljb25maWc9Im5vIgorICA7OworZXNhYworZmkKK3B5Y29uZmln
PSRhY19jdl9wYXRoX3B5Y29uZmlnCitpZiB0ZXN0IC1uICIkcHljb25maWciOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkcHljb25maWci
ID4mNQorJGFzX2VjaG8gIiRweWNvbmZpZyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8i
ID4mNjsgfQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYXhfY3ZfcHRocmVhZF9mbGFncyIgPiY1Ci0kYXNfZWNobyAiJGF4X2N2X3B0aHJlYWRf
ZmxhZ3MiID4mNjsgfQotICAgIGlmIHRlc3QgIngkYXhfY3ZfcHRocmVhZF9mbGFncyIgPSB4ZmFp
bGVkOyB0aGVuCi0gICAgICAgIGFzX2ZuX2Vycm9yICQ/ICItcHRocmVhZCBkb2VzIG5vdCB3b3Jr
IiAiJExJTkVOTyIgNQotICAgIGZpCi0KLSAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJl
YWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKLSAg
ICBQVEhSRUFEX0xJQlM9IiIKIAogCitpZiB0ZXN0IHgiJHB5Y29uZmlnIiA9PSB4Im5vIjsgdGhl
biA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIGNsb2NrX2dldHRpbWUgaW4gLWxydCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
Y2xvY2tfZ2V0dGltZSBpbiAtbHJ0Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9y
dF9jbG9ja19nZXR0aW1lK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxy
dCAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCisgICAgICAgIENQUEZMQUdTPSIkQ0ZMQUdTIGAkUFlUSE9O
IC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAorICAgICAgICBwcmludCAiLUkiICsg
ZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiSU5DTFVERVBZIiknYCIKKyAgICBD
UFBGTEFHUz0iJENQUEZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZp
ZzsgXAorICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJD
RkxBR1MiKSdgIgorICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlz
dHV0aWxzLnN5c2NvbmZpZzsgXAorICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdl
dF9jb25maWdfdmFyKCJMSUJTIiknYCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAt
YyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgZGlzdHV0aWxz
LnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiU1lTTElCUyIpJ2AiCisgICAgTERGTEFHUz0iJExE
RkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCisgICAgICAg
IHByaW50ICItTCIgKyBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBsYXRfc3Bl
Y2lmaWM9MSxcCisgICAgICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidgIgorICAgIExE
RkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsg
XAorICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJMSU5L
Rk9SU0hBUkVEIiknYCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0
IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZp
Zy5nZXRfY29uZmlnX3ZhcigiTERGTEFHUyIpJ2AiCiAKLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50
ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBp
bnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0
aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVm
IF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgY2xvY2tfZ2V0dGltZSAoKTsK
LWludAotbWFpbiAoKQotewotcmV0dXJuIGNsb2NrX2dldHRpbWUgKCk7Ci0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAg
YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9eWVzCiBlbHNlCi0gIGFjX2N2X2xpYl9ydF9jbG9j
a19nZXR0aW1lPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjUKLSRhc19l
Y2hvICIkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID4mNjsgfQotaWYgdGVzdCAieCRhY19j
dl9saWJfcnRfY2xvY2tfZ2V0dGltZSIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCUlQgMQotX0FDRU9GCiAKLSAgTElCUz0iLWxy
dCAkTElCUyIKKyAgICAgICAgQ1BQRkxBR1M9IiRDRkxBR1MgYCRQWVRIT04tY29uZmlnIC0tY2Zs
YWdzYCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTi1jb25maWcgLS1sZGZsYWdzYCIK
IAogZmkKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl95
YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHlh
amwgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot
LyogZW5kIGNvbmZkZWZzLmguICAqLworYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJ
TkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVyX1B5dGhvbl9oIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9QeXRob25faCIgPSB4IiJ5ZXM7IHRoZW4g
OgogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl
cnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw
ZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2Vu
ZGlmCi1jaGFyIHlhamxfYWxsb2MgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiB5YWpsX2Fs
bG9jICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5r
ICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCiBlbHNl
Ci0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0
LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRl
c3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworICBhc19mbl9lcnJvciAk
PyAiVW5hYmxlIHRvIGZpbmQgUHl0aG9uIGRldmVsb3BtZW50IGhlYWRlcnMiICIkTElORU5PIiA1
CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX3lhamxf
eWFqbF9hbGxvYyIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mi
ID0geCIieWVzOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBI
QVZFX0xJQllBSkwgMQotX0FDRU9GCi0KLSAgTElCUz0iLWx5YWpsICRMSUJTIgogCi1lbHNlCi0g
IGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB5YWpsIiAiJExJTkVOTyIgNQotZmkKIAot
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZGVm
bGF0ZUNvcHkgaW4gLWx6IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBkZWZsYXRlQ29w
eSBpbiAtbHouLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkr
c2V0fSIgPSBzZXQ7IHRoZW4gOgorYXNfYWNfTGliPWAkYXNfZWNobyAiYWNfY3ZfbGliX3B5dGhv
biRhY19weXRob25fdmVyc2lvbicnX1B5QXJnX1BhcnNlVHVwbGUiIHwgJGFzX3RyX3NoYAoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgUHlBcmdf
UGFyc2VUdXBsZSBpbiAtbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgUHlBcmdfUGFyc2VUdXBsZSBpbiAtbHB5dGhvbiRhY19weXRob25fdmVy
c2lvbi4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyRhc19hY19MaWIrc2V0fVwiIiA9
IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCiAgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1seiAgJExJQlMiCitMSUJTPSItbHB5dGhv
biRhY19weXRob25fdmVyc2lvbiAgJExJQlMiCiBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKQEAgLTc2MzIsMTg5MyAr
NTM3NywxMTczIEBAIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
ICNpZmRlZiBfX2NwbHVzcGx1cwogZXh0ZXJuICJDIgogI2VuZGlmCi1jaGFyIGRlZmxhdGVDb3B5
ICgpOworY2hhciBQeUFyZ19QYXJzZVR1cGxlICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4g
ZGVmbGF0ZUNvcHkgKCk7CityZXR1cm4gUHlBcmdfUGFyc2VUdXBsZSAoKTsKICAgOwogICByZXR1
cm4gMDsKIH0KIF9BQ0VPRgogaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgot
ICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKKyAgZXZhbCAiJGFzX2FjX0xpYj15ZXMiCiBl
bHNlCi0gIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5vCisgIGV2YWwgIiRhc19hY19MaWI9bm8i
CiBmaQogcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCiAgICAg
Y29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKIExJQlM9JGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfel9kZWZsYXRlQ29w
eSIgPSB4IiJ5ZXM7IHRoZW4gOgorZXZhbCBhY19yZXM9XCQkYXNfYWNfTGliCisJICAgICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+
JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNf
TGliIlwiID0geCJ5ZXMiOyB0aGVuIDoKICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2Rl
ZmluZSBIQVZFX0xJQlogMQorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfTElCcHl0aG9uJGFjX3B5
dGhvbl92ZXJzaW9uIiB8ICRhc190cl9jcHBgIDEKIF9BQ0VPRgogCi0gIExJQlM9Ii1seiAkTElC
UyIKLQotZWxzZQotICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgemxpYiIgIiRMSU5F
Tk8iIDUKLWZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udiIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k
TElCUwotTElCUz0iLWxpY29udiAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCisgIExJQlM9Ii1scHl0aG9u
JGFjX3B5dGhvbl92ZXJzaW9uICRMSUJTIgogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFs
IHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1p
Z2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBp
dHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2Nw
bHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGxpYmljb252X29wZW4gKCk7Ci1pbnQK
LW1haW4gKCkKLXsKLXJldHVybiBsaWJpY29udl9vcGVuICgpOwotICA7Ci0gIHJldHVybiAwOwot
fQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2
X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwotZWxzZQotICBhY19jdl9saWJfaWNvbnZfbGli
aWNvbnZfb3Blbj1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY1Ci0k
YXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjY7IH0KLWlmIHRlc3Qg
IngkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID0geCIieWVzOyB0aGVuIDoKLSAgbGli
aWNvbnY9InkiCiBlbHNlCi0gIGxpYmljb252PSJuIgorICBhc19mbl9lcnJvciAkPyAiVW5hYmxl
IHRvIGZpbmQgYSBzdWl0YWJsZSBweXRob24gZGV2ZWxvcG1lbnQgbGlicmFyeSIgIiRMSU5FTk8i
IDUKIGZpCiAKK0NQUEZMQUdTPSRhY19wcmV2aW91c19jcHBmbGFncworTERMRkFHUz0kYWNfcHJl
dmlvdXNfbGRmbGFncwogCiAKLSMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCi0jIFRoZSBVbHRy
aXggNC4yIG1pcHMgYnVpbHRpbiBhbGxvY2EgZGVjbGFyZWQgYnkgYWxsb2NhLmggb25seSB3b3Jr
cwotIyBmb3IgY29uc3RhbnQgYXJndW1lbnRzLiAgVXNlbGVzcyEKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmgiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmguLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3Zfd29ya2luZ19hbGxvY2FfaCtzZXR9IiA9IHNldDsgdGhlbiA6Citm
aQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgdGVzdCAiJHthY19jdl9wYXRoX1hHRVRURVhUK3NldH0iID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUg
PGFsbG9jYS5oPgotaW50Ci1tYWluICgpCi17Ci1jaGFyICpwID0gKGNoYXIgKikgYWxsb2NhICgy
ICogc2l6ZW9mIChpbnQpKTsKLQkJCSAgaWYgKHApIHJldHVybiAwOwotICA7Ci0gIHJldHVybiAw
OwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFj
X2N2X3dvcmtpbmdfYWxsb2NhX2g9eWVzCi1lbHNlCi0gIGFjX2N2X3dvcmtpbmdfYWxsb2NhX2g9
bm8KKyAgY2FzZSAkWEdFVFRFWFQgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3Bh
dGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qg
d2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2
X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9Im5vIgorICA7OworZXNhYwog
ZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitYR0VUVEVYVD0kYWNfY3ZfcGF0aF9Y
R0VUVEVYVAoraWYgdGVzdCAtbiAiJFhHRVRURVhUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhHRVRURVhUIiA+JjUKKyRhc19lY2hv
ICIkWEdFVFRFWFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCi17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3dv
cmtpbmdfYWxsb2NhX2giID4mNQotJGFzX2VjaG8gIiRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+
JjY7IH0KLWlmIHRlc3QgJGFjX2N2X3dvcmtpbmdfYWxsb2NhX2ggPSB5ZXM7IHRoZW4KIAotJGFz
X2VjaG8gIiNkZWZpbmUgSEFWRV9BTExPQ0FfSCAxIiA+PmNvbmZkZWZzLmgKIAoraWYgdGVzdCB4
IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUg
dG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1CiBm
aQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBhbGxvY2EiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGFsbG9jYS4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9mdW5jX2FsbG9jYV93b3JrcytzZXR9IiA9IHNldDsgdGhlbiA6
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGFzODY7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX0FTODYrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgogZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZkZWYgX19HTlVDX18KLSMgZGVm
aW5lIGFsbG9jYSBfX2J1aWx0aW5fYWxsb2NhCi0jZWxzZQotIyBpZmRlZiBfTVNDX1ZFUgotIyAg
aW5jbHVkZSA8bWFsbG9jLmg+Ci0jICBkZWZpbmUgYWxsb2NhIF9hbGxvY2EKLSMgZWxzZQotIyAg
aWZkZWYgSEFWRV9BTExPQ0FfSAotIyAgIGluY2x1ZGUgPGFsbG9jYS5oPgotIyAgZWxzZQotIyAg
IGlmZGVmIF9BSVgKLSAjcHJhZ21hIGFsbG9jYQotIyAgIGVsc2UKLSMgICAgaWZuZGVmIGFsbG9j
YSAvKiBwcmVkZWZpbmVkIGJ5IEhQIGNjICtPbGliY2FsbHMgKi8KLWNoYXIgKmFsbG9jYSAoKTsK
LSMgICAgZW5kaWYKLSMgICBlbmRpZgotIyAgZW5kaWYKLSMgZW5kaWYKLSNlbmRpZgotCi1pbnQK
LW1haW4gKCkKLXsKLWNoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDEpOwotCQkJCSAgICBpZiAo
cCkgcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3M9eWVzCi1l
bHNlCi0gIGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjUKLSRhc19lY2hvICIkYWNfY3Zf
ZnVuY19hbGxvY2Ffd29ya3MiID4mNjsgfQotCi1pZiB0ZXN0ICRhY19jdl9mdW5jX2FsbG9jYV93
b3JrcyA9IHllczsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX0FMTE9DQSAxIiA+PmNv
bmZkZWZzLmgKKyAgY2FzZSAkQVM4NiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9BUzg2PSIkQVM4NiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQVM4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9BUzg2
IiAmJiBhY19jdl9wYXRoX0FTODY9Im5vIgorICA7OworZXNhYworZmkKK0FTODY9JGFjX2N2X3Bh
dGhfQVM4NgoraWYgdGVzdCAtbiAiJEFTODYiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQVM4NiIgPiY1CiskYXNfZWNobyAiJEFTODYi
ID4mNjsgfQogZWxzZQotICAjIFRoZSBTVlIzIGxpYlBXIGFuZCBTVlI0IGxpYnVjYiBib3RoIGNv
bnRhaW4gaW5jb21wYXRpYmxlIGZ1bmN0aW9ucwotIyB0aGF0IGNhdXNlIHRyb3VibGUuICBTb21l
IHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2NhIG9yCi0jIGNvbnRhaW4gYSBidWdn
eSB2ZXJzaW9uLiAgSWYgeW91IHN0aWxsIHdhbnQgdG8gdXNlIHRoZWlyIGFsbG9jYSwKLSMgdXNl
IGFyIHRvIGV4dHJhY3QgYWxsb2NhLm8gZnJvbSB0aGVtIGluc3RlYWQgb2YgY29tcGlsaW5nIGFs
bG9jYS5jLgotCi1BTExPQ0E9XCR7TElCT0JKRElSfWFsbG9jYS4kYWNfb2JqZXh0Ci0KLSRhc19l
Y2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMuaAorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3MiID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgd2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzLi4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X29zX2NyYXkrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYg
dGVzdCB4IiR7QVM4Nn0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGFzODYsIHBsZWFzZSBpbnN0YWxsIGFzODYiICIkTElORU5PIiA1CitmaQorIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJsZDg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBsZDg2OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7
YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmIGRlZmluZWQgQ1JBWSAmJiAhIGRlZmlu
ZWQgQ1JBWTIKLXdlYmVjcmF5Ci0jZWxzZQotd2Vub3RiZWNyYXkKLSNlbmRpZgorICBjYXNlICRM
RDg2IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0xEODY9IiRMRDg2IiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikK
KyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAk
UEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNf
Y3ZfcGF0aF9MRDg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19z
YXZlX0lGUwogCi1fQUNFT0YKLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAy
PiY1IHwKLSAgJEVHUkVQICJ3ZWJlY3JheSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKLSAgYWNf
Y3Zfb3NfY3JheT15ZXMKLWVsc2UKLSAgYWNfY3Zfb3NfY3JheT1ubworICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9MRDg2IiAmJiBhY19jdl9wYXRoX0xEODY9Im5vIgorICA7OworZXNhYwogZmkKLXJt
IC1mIGNvbmZ0ZXN0KgotCitMRDg2PSRhY19jdl9wYXRoX0xEODYKK2lmIHRlc3QgLW4gIiRMRDg2
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJExEODYiID4mNQorJGFzX2VjaG8gIiRMRDg2IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9vc19jcmF5IiA+JjUKLSRhc19lY2hvICIkYWNfY3Zfb3NfY3JheSIg
PiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9vc19jcmF5ID0geWVzOyB0aGVuCi0gIGZvciBhY19mdW5j
IGluIF9nZXRiNjcgR0VUQjY3IGdldGI2NzsgZG8KLSAgICBhc19hY192YXI9YCRhc19lY2hvICJh
Y19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKLWFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJ
TkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNf
dmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2Rl
ZmluZSBDUkFZX1NUQUNLU0VHX0VORCAkYWNfZnVuYwotX0FDRU9GCiAKLSAgICBicmVhawotZmkK
IAotICBkb25lCitpZiB0ZXN0IHgiJHtMRDg2fSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGluc3RhbGwgbGQ4NiIgIiRMSU5F
Tk8iIDUKIGZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYSIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyBzdGFjayBkaXJlY3Rpb24gZm9yIEMgYWxsb2NhLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uK3NldH0iID0gc2V0OyB0aGVuIDoKKyMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiYmNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSBiY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRo
X0JDQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3Zf
Y19zdGFja19kaXJlY3Rpb249MAotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVm
YXVsdAotaW50Ci1maW5kX3N0YWNrX2RpcmVjdGlvbiAoKQotewotICBzdGF0aWMgY2hhciAqYWRk
ciA9IDA7Ci0gIGF1dG8gY2hhciBkdW1teTsKLSAgaWYgKGFkZHIgPT0gMCkKLSAgICB7Ci0gICAg
ICBhZGRyID0gJmR1bW15OwotICAgICAgcmV0dXJuIGZpbmRfc3RhY2tfZGlyZWN0aW9uICgpOwot
ICAgIH0KLSAgZWxzZQotICAgIHJldHVybiAoJmR1bW15ID4gYWRkcikgPyAxIDogLTE7Ci19Cisg
IGNhc2UgJEJDQyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CQ0M9IiRC
Q0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7Owor
ICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wYXRoX0JDQz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k
YXNfc2F2ZV9JRlMKIAotaW50Ci1tYWluICgpCi17Ci0gIHJldHVybiBmaW5kX3N0YWNrX2RpcmVj
dGlvbiAoKSA8IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRo
ZW4gOgotICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0xCi1lbHNlCi0gIGFjX2N2X2Nfc3RhY2tf
ZGlyZWN0aW9uPS0xCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24u
b3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQ0Mi
ICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKKyAgOzsKK2VzYWMKIGZpCi0KK0JDQz0kYWNfY3ZfcGF0
aF9CQ0MKK2lmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQkNDIiA+JjUKKyRhc19lY2hvICIkQkNDIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIg
PiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjY7IH0KLWNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgU1RBQ0tfRElSRUNUSU9OICRhY19jdl9jX3N0YWNr
X2RpcmVjdGlvbgotX0FDRU9GCiAKIAoraWYgdGVzdCB4IiR7QkNDfSIgPT0geCJubyIKK3RoZW4K
KyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmNjLCBwbGVhc2UgaW5zdGFsbCBi
Y2MiICIkTElORU5PIiA1CiBmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJpYXNsIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBpYXNsOyBh
Y193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9JQVNMK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkSUFTTCBpbgor
ICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9JQVNMPSIkSUFTTCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf
SUFTTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK
IAotZm9yIGFjX2hlYWRlciBpbiAgXAotICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRs
LmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAotICAgICAgICAgICAg
ICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmlu
Zy5oIFwKLSAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBz
eXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCi0gICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5
cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAotICAgICAgICAgICAg
ICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5vIgorICA7OworZXNhYworZmkKK0lBU0w9JGFj
X2N2X3BhdGhfSUFTTAoraWYgdGVzdCAtbiAiJElBU0wiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSUFTTCIgPiY1CiskYXNfZWNobyAi
JElBU0wiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKLWRvIDoK
LSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFz
X3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIiRhY19oZWFk
ZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiBldmFsIHRlc3Qg
XCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3Ry
X2NwcGAgMQotX0FDRU9GCiAKK2lmIHRlc3QgeCIke0lBU0x9IiA9PSB4Im5vIgordGhlbgorICAg
IGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNsLCBwbGVhc2UgaW5zdGFsbCBpYXNs
IiAiJExJTkVOTyIgNQogZmkKIAotZG9uZQotCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVs
ICIkTElORU5PIiAidXVpZC91dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF91dWlkX2giICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiA9
IHgiInllczsgdGhlbiA6CiAKLSMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5k
IGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5OSIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMgdG8g
Qzk5Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zdGRib29sX2grc2V0fSIg
PSBzZXQ7IHRoZW4gOgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIgaW4gLWx1dWlkIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth
Y19jdl9saWJfdXVpZF91dWlkX2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHV1
aWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAog
LyogZW5kIGNvbmZkZWZzLmguICAqLwogCi0jaW5jbHVkZSA8c3RkYm9vbC5oPgotI2lmbmRlZiBi
b29sCi0gImVycm9yOiBib29sIGlzIG5vdCBkZWZpbmVkIgotI2VuZGlmCi0jaWZuZGVmIGZhbHNl
Ci0gImVycm9yOiBmYWxzZSBpcyBub3QgZGVmaW5lZCIKLSNlbmRpZgotI2lmIGZhbHNlCi0gImVy
cm9yOiBmYWxzZSBpcyBub3QgMCIKLSNlbmRpZgotI2lmbmRlZiB0cnVlCi0gImVycm9yOiB0cnVl
IGlzIG5vdCBkZWZpbmVkIgotI2VuZGlmCi0jaWYgdHJ1ZSAhPSAxCi0gImVycm9yOiB0cnVlIGlz
IG5vdCAxIgotI2VuZGlmCi0jaWZuZGVmIF9fYm9vbF90cnVlX2ZhbHNlX2FyZV9kZWZpbmVkCi0g
ImVycm9yOiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCBpcyBub3QgZGVmaW5lZCIKKy8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgor
ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg
R0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp
bGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCiAjZW5kaWYKLQot
CXN0cnVjdCBzIHsgX0Jvb2wgczogMTsgX0Jvb2wgdDsgfSBzOwotCi0JY2hhciBhW3RydWUgPT0g
MSA/IDEgOiAtMV07Ci0JY2hhciBiW2ZhbHNlID09IDAgPyAxIDogLTFdOwotCWNoYXIgY1tfX2Jv
b2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCA9PSAxID8gMSA6IC0xXTsKLQljaGFyIGRbKGJvb2wp
IDAuNSA9PSB0cnVlID8gMSA6IC0xXTsKLQlib29sIGUgPSAmczsKLQljaGFyIGZbKF9Cb29sKSAw
LjAgPT0gZmFsc2UgPyAxIDogLTFdOwotCWNoYXIgZ1t0cnVlXTsKLQljaGFyIGhbc2l6ZW9mIChf
Qm9vbCldOwotCWNoYXIgaVtzaXplb2Ygcy50XTsKLQllbnVtIHsgaiA9IGZhbHNlLCBrID0gdHJ1
ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAyNTYgfTsKLQkvKiBUaGUgZm9sbG93aW5n
IGZhaWxzIGZvcgotCSAgIEhQIGFDKysvQU5TSSBDIEIzOTEwQiBBLjA1LjU1IFtEZWMgMDQgMjAw
M10uICovCi0JX0Jvb2wgblttXTsKLQljaGFyIG9bc2l6ZW9mIG4gPT0gbSAqIHNpemVvZiBuWzBd
ID8gMSA6IC0xXTsKLQljaGFyIHBbLTEgLSAoX0Jvb2wpIDAgPCAwICYmIC0xIC0gKGJvb2wpIDAg
PCAwID8gMSA6IC0xXTsKLSMJaWYgZGVmaW5lZCBfX3hsY19fIHx8IGRlZmluZWQgX19HTlVDX18K
LQkgLyogQ2F0Y2ggYSBidWcgaW4gSUJNIEFJWCB4bGMgY29tcGlsZXIgdmVyc2lvbiA2LjAuMC4w
Ci0JICAgIHJlcG9ydGVkIGJ5IEphbWVzIExlbWxleSBvbiAyMDA1LTEwLTA1OyBzZWUKLQkgICAg
aHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMC9t
c2cwMDA4Ni5odG1sCi0JICAgIFRoaXMgdGVzdCBpcyBub3QgcXVpdGUgcmlnaHQsIHNpbmNlIHhs
YyBpcyBhbGxvd2VkIHRvCi0JICAgIHJlamVjdCB0aGlzIHByb2dyYW0sIGFzIHRoZSBpbml0aWFs
aXplciBmb3IgeGxjYnVnIGlzCi0JICAgIG5vdCBvbmUgb2YgdGhlIGZvcm1zIHRoYXQgQyByZXF1
aXJlcyBzdXBwb3J0IGZvci4KLQkgICAgSG93ZXZlciwgZG9pbmcgdGhlIHRlc3QgcmlnaHQgd291
bGQgcmVxdWlyZSBhIHJ1bnRpbWUKLQkgICAgdGVzdCwgYW5kIHRoYXQgd291bGQgbWFrZSBjcm9z
cy1jb21waWxhdGlvbiBoYXJkZXIuCi0JICAgIExldCB1cyBob3BlIHRoYXQgSUJNIGZpeGVzIHRo
ZSB4bGMgYnVnLCBhbmQgYWxzbyBhZGRzCi0JICAgIHN1cHBvcnQgZm9yIHRoaXMga2luZCBvZiBj
b25zdGFudCBleHByZXNzaW9uLiAgSW4gdGhlCi0JICAgIG1lYW50aW1lLCB0aGlzIHRlc3Qgd2ls
bCByZWplY3QgeGxjLCB3aGljaCBpcyBPSywgc2luY2UKLQkgICAgb3VyIHN0ZGJvb2wuaCBzdWJz
dGl0dXRlIHNob3VsZCBzdWZmaWNlLiAgV2UgYWxzbyB0ZXN0Ci0JICAgIHRoaXMgd2l0aCBHQ0Ms
IHdoZXJlIGl0IHNob3VsZCB3b3JrLCB0byBkZXRlY3QgbW9yZQotCSAgICBxdWlja2x5IHdoZXRo
ZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRlc3QgaW4gdGhlCi0JICAgIGZ1dHVyZS4gICovCi0J
IGNoYXIgZGlnc1tdID0gIjAxMjM0NTY3ODkiOwotCSBpbnQgeGxjYnVnID0gMSAvICgmKGRpZ3Mg
KyA1KVstMiArIChib29sKSAxXSA9PSAmZGlnc1s0XSA/IDEgOiAtMSk7Ci0jCWVuZGlmCi0JLyog
Q2F0Y2ggYSBidWcgaW4gYW4gSFAtVVggQyBjb21waWxlci4gIFNlZQotCSAgIGh0dHA6Ly9nY2Mu
Z251Lm9yZy9tbC9nY2MtcGF0Y2hlcy8yMDAzLTEyL21zZzAyMzAzLmh0bWwKLQkgICBodHRwOi8v
bGlzdHMuZ251Lm9yZy9hcmNoaXZlL2h0bWwvYnVnLWNvcmV1dGlscy8yMDA1LTExL21zZzAwMTYx
Lmh0bWwKLQkgKi8KLQlfQm9vbCBxID0gdHJ1ZTsKLQlfQm9vbCAqcHEgPSAmcTsKLQorY2hhciB1
dWlkX2NsZWFyICgpOwogaW50CiBtYWluICgpCiB7Ci0KLQkqcHEgfD0gcTsKLQkqcHEgfD0gISBx
OwotCS8qIFJlZmVyIHRvIGV2ZXJ5IGRlY2xhcmVkIHZhbHVlLCB0byBhdm9pZCBjb21waWxlciBv
cHRpbWl6YXRpb25zLiAgKi8KLQlyZXR1cm4gKCFhICsgIWIgKyAhYyArICFkICsgIWUgKyAhZiAr
ICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCi0JCSsgIW0gKyAhbiArICFvICsgIXAgKyAh
cSArICFwcSk7Ci0KK3JldHVybiB1dWlkX2NsZWFyICgpOwogICA7CiAgIHJldHVybiAwOwogfQog
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2
X2hlYWRlcl9zdGRib29sX2g9eWVzCi1lbHNlCi0gIGFjX2N2X2hlYWRlcl9zdGRib29sX2g9bm8K
LWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0
LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2hlYWRlcl9zdGRib29sX2giID4mNQotJGFzX2VjaG8gIiRhY19jdl9oZWFk
ZXJfc3RkYm9vbF9oIiA+JjY7IH0KLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgIl9Cb29s
IiAiYWNfY3ZfdHlwZV9fQm9vbCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRh
Y19jdl90eXBlX19Cb29sIiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKLSNkZWZpbmUgSEFWRV9fQk9PTCAxCi1fQUNFT0YKLQotCi1maQotCi1pZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYm9vbF9oID0geWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIEhB
VkVfU1REQk9PTF9IIDEiID4+Y29uZmRlZnMuaAotCi1maQotCi17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMvdHlwZXMuaCIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmguLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfdHlwZV91aWRfdCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0g
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRl
IDxzeXMvdHlwZXMuaD4KLQotX0FDRU9GCi1pZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNf
ZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAidWlkX3QiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0g
IGFjX2N2X3R5cGVfdWlkX3Q9eWVzCi1lbHNlCi0gIGFjX2N2X3R5cGVfdWlkX3Q9bm8KLWZpCi1y
bSAtZiBjb25mdGVzdCoKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3R5
cGVfdWlkX3QiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfdHlwZV91aWRfdCA9IG5vOyB0aGVuCi0K
LSRhc19lY2hvICIjZGVmaW5lIHVpZF90IGludCIgPj5jb25mZGVmcy5oCi0KLQotJGFzX2VjaG8g
IiNkZWZpbmUgZ2lkX3QgaW50IiA+PmNvbmZkZWZzLmgKLQotZmkKLQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW5saW5lIiA+JjUKLSRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
Y19pbmxpbmUrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgotZWxzZQotICBhY19jdl9jX2lubGluZT1ubwotZm9yIGFjX2t3IGluIGlubGluZSBfX2lubGlu
ZV9fIF9faW5saW5lOyBkbwotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZuZGVmIF9fY3BsdXNwbHVzCi10eXBl
ZGVmIGludCBmb29fdDsKLXN0YXRpYyAkYWNfa3cgZm9vX3Qgc3RhdGljX2ZvbyAoKSB7cmV0dXJu
IDA7IH0KLSRhY19rdyBmb29fdCBmb28gKCkge3JldHVybiAwOyB9Ci0jZW5kaWYKLQotX0FDRU9G
Ci1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2NfaW5s
aW5lPSRhY19rdworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9saWJfdXVpZF91dWlkX2NsZWFyPXllcworZWxzZQorICBhY19jdl9saWJfdXVpZF91dWlkX2Ns
ZWFyPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0Ci0gIHRlc3QgIiRhY19jdl9jX2lubGluZSIgIT0gbm8gJiYgYnJlYWsK
LWRvbmUKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3V1aWRf
dXVpZF9jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJ1dWlkPSJ5IgogZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19pbmxpbmUi
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2OyB9CiAKLWNhc2UgJGFjX2N2X2Nf
aW5saW5lIGluCi0gIGlubGluZSB8IHllcykgOzsKLSAgKikKLSAgICBjYXNlICRhY19jdl9jX2lu
bGluZSBpbgotICAgICAgbm8pIGFjX3ZhbD07OwotICAgICAgKikgYWNfdmFsPSRhY19jdl9jX2lu
bGluZTs7Ci0gICAgZXNhYwotICAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNpZm5kZWYg
X19jcGx1c3BsdXMKLSNkZWZpbmUgaW5saW5lICRhY192YWwKLSNlbmRpZgotX0FDRU9GCi0gICAg
OzsKLWVzYWMKIAotYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY19p
bnQxNl90IgotY2FzZSAkYWNfY3ZfY19pbnQxNl90IGluICMoCi0gIG5vfHllcykgOzsgIygKLSAg
KikKK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgaW50MTZfdCAkYWNf
Y3ZfY19pbnQxNl90Ci1fQUNFT0YKLTs7Ci1lc2FjCiAKLWFjX2ZuX2NfZmluZF9pbnRYX3QgIiRM
SU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKLWNhc2UgJGFjX2N2X2NfaW50MzJfdCBpbiAj
KAotICBub3x5ZXMpIDs7ICMoCi0gICopCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAidXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF9oIiA9IHgiInllczsgdGhlbiA6Cisg
IGxpYnV1aWQ9InkiCitmaQogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGlu
dDMyX3QgJGFjX2N2X2NfaW50MzJfdAotX0FDRU9GCi07OwotZXNhYwogCi1hY19mbl9jX2ZpbmRf
aW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0X3QiCi1jYXNlICRhY19jdl9jX2lu
dDY0X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQoraWYgdGVzdCAiJGxpYnV1aWQiICE9
ICJ5IjsgdGhlbiA6CiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgaW50NjRf
dCAkYWNfY3ZfY19pbnQ2NF90Ci1fQUNFT0YKLTs7Ci1lc2FjCisgICAgYXNfZm5fZXJyb3IgJD8g
ImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBsaWJyYXJ5IiAiJExJTkVOTyIgNQogCi1hY19mbl9j
X2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIgImFjX2N2X2NfaW50OF90IgotY2FzZSAkYWNfY3Zf
Y19pbnQ4X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQorZmkKIAotY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBpbnQ4X3QgJGFjX2N2X2NfaW50OF90Ci1fQUNFT0YKLTs7
Ci1lc2FjCiAKLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgIm1vZGVfdCIgImFjX2N2X3R5
cGVfbW9kZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
bW9kZV90IiA9IHgiInllczsgdGhlbiA6CithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJfY3Vyc2VzX2giICIkYWNfaW5jbHVkZXNf
ZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2N1cnNlc19oIiA9IHgiInllczsgdGhl
biA6CiAKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
Y2xlYXIgaW4gLWxjdXJzZXMuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2N1cnNl
c19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CiBlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sY3Vyc2VzICAk
TElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBt
b2RlX3QgaW50CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9p
ZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1
cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90
eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJD
IgorI2VuZGlmCitjaGFyIGNsZWFyICgpOworaW50CittYWluICgpCit7CityZXR1cm4gY2xlYXIg
KCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CiBfQUNFT0YKLQoraWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPXllcworZWxzZQorICBh
Y19jdl9saWJfY3Vyc2VzX2NsZWFyPW5vCiBmaQotCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F
Tk8iICJvZmZfdCIgImFjX2N2X3R5cGVfb2ZmX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlm
IHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZfdCIgPSB4IiJ5ZXM7IHRoZW4gOgotCitybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVl
eHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGli
X2N1cnNlc19jbGVhciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID4m
NjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA9IHgiInllczsgdGhlbiA6
CisgIGN1cnNlcz0ieSIKIGVsc2UKLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmlu
ZSBvZmZfdCBsb25nIGludAotX0FDRU9GCi0KKyAgY3Vyc2VzPSJuIgogZmkKIAotYWNfZm5fY19j
aGVja190eXBlICIkTElORU5PIiAicGlkX3QiICJhY19jdl90eXBlX3BpZF90IiAiJGFjX2luY2x1
ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcGlkX3QiID0geCIieWVzOyB0aGVu
IDoKIAogZWxzZQorICBjdXJzZXM9Im4iCitmaQogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
Ci0jZGVmaW5lIHBpZF90IGludAotX0FDRU9GCiAKLWZpCithY19mbl9jX2NoZWNrX2hlYWRlcl9t
b25ncmVsICIkTElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRh
Y19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbmN1cnNlc19oIiA9
IHgiInllczsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQiID4mNQotJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3Qg
IiR7YWNfY3ZfY19yZXN0cmljdCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vy
c2VzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMuLi4g
IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jdl9jX3Jl
c3RyaWN0PW5vCi0gICAjIFRoZSBvcmRlciBoZXJlIGNhdGVycyB0byB0aGUgZmFjdCB0aGF0IEMr
KyBkb2VzIG5vdCByZXF1aXJlIHJlc3RyaWN0LgotICAgZm9yIGFjX2t3IGluIF9fcmVzdHJpY3Qg
X19yZXN0cmljdF9fIF9SZXN0cmljdCByZXN0cmljdDsgZG8KLSAgICAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRM
SUJTCitMSUJTPSItbG5jdXJzZXMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotdHlwZWRlZiBpbnQgKiBp
bnRfcHRyOwotCWludCBmb28gKGludF9wdHIgJGFjX2t3IGlwKSB7Ci0JcmV0dXJuIGlwWzBdOwot
ICAgICAgIH0KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv
aWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0
dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3Rv
dHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAi
QyIKKyNlbmRpZgorY2hhciBjbGVhciAoKTsKIGludAogbWFpbiAoKQogewotaW50IHNbMV07Ci0J
aW50ICogJGFjX2t3IHQgPSBzOwotCXRbMF0gPSAwOwotCXJldHVybiBmb28odCkKK3JldHVybiBj
bGVhciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX3Jlc3RyaWN0PSRhY19rdworaWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfbmN1cnNlc19jbGVh
cj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9bm8KIGZpCi1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgICAg
dGVzdCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJyZWFrCi0gICBkb25lCi0KK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBm
aQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9jX3Jlc3RyaWN0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfY19yZXN0cmljdCIgPiY2OyB9Ci0K
LSBjYXNlICRhY19jdl9jX3Jlc3RyaWN0IGluCi0gICByZXN0cmljdCkgOzsKLSAgIG5vKSAkYXNf
ZWNobyAiI2RlZmluZSByZXN0cmljdCAvKiovIiA+PmNvbmZkZWZzLmgKLSA7OwotICAgKikgIGNh
dCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgcmVzdHJpY3QgJGFjX2N2X2NfcmVzdHJp
Y3QKLV9BQ0VPRgotIDs7Ci0gZXNhYwotCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJz
aXplX3QiICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVz
dCAieCRhY19jdl90eXBlX3NpemVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgotCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9uY3Vyc2VzX2Ns
ZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBuY3Vy
c2VzPSJ5IgogZWxzZQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHNpemVf
dCB1bnNpZ25lZCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9Im4iCiBmaQogCi1hY19mbl9jX2No
ZWNrX3R5cGUgIiRMSU5FTk8iICJzc2l6ZV90IiAiYWNfY3ZfdHlwZV9zc2l6ZV90IiAiJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc3NpemVfdCIgPSB4IiJ5ZXM7
IHRoZW4gOgogCiBlbHNlCi0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgc3Np
emVfdCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9Im4iCiBmaQogCi1hY19mbl9jX2NoZWNrX21l
bWJlciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxrc2l6ZSIgImFjX2N2X21lbWJlcl9z
dHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4
JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiA9IHgiInllczsgdGhlbiA6CiAK
LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9C
TEtTSVpFIDEKLV9BQ0VPRgoraWYgdGVzdCAiJGN1cnNlcyIgPSAibiIgJiYgdGVzdCAiJG5jdXJz
ZXMiID0gIm4iOyB0aGVuIDoKIAorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBh
IHN1aXRhYmxlIGN1cnNlcyBsaWJyYXJ5IiAiJExJTkVOTyIgNQogCiBmaQorIyBQcmVmZXIgbmN1
cnNlcyBvdmVyIGN1cnNlcyBpZiBib3RoIGFyZSBwcmVzZW50CitpZiB0ZXN0ICIkbmN1cnNlcyIg
PSAieSI7IHRoZW4gOgogCi1hY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVjdCBz
dGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsb2NrcyIgIiRh
Y19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRf
c3RfYmxvY2tzIiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MgMQotX0FDRU9GCisgICAgQ1VSU0VT
X0xJQlM9Ii1sbmN1cnNlcyIKIAorJGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNfSCA8
bmN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfU1RfQkxP
Q0tTIDEiID4+Y29uZmRlZnMuaAogCiBlbHNlCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoi
IGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIGZp
bGVibG9ja3MuJGFjX29iamV4dCIKLSA7OwotZXNhYwotCi1maQotCiAKLWFjX2ZuX2NfY2hlY2tf
bWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0YXQiICJzdF9yZGV2IiAiYWNfY3ZfbWVtYmVyX3N0
cnVjdF9zdGF0X3N0X3JkZXYiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNf
Y3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiID0geCIieWVzOyB0aGVuIDoKKyAgICBDVVJT
RVNfTElCUz0iLWxjdXJzZXMiCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUg
SEFWRV9TVFJVQ1RfU1RBVF9TVF9SREVWIDEKLV9BQ0VPRgorJGFzX2VjaG8gIiNkZWZpbmUgSU5D
TFVERV9DVVJTRVNfSCA8Y3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKIAogCiBmaQogCi1hY19mbl9j
X2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY191aW50MTZfdCIKLWNhc2UgJGFj
X2N2X2NfdWludDE2X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQogCiAKLWNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgdWludDE2X3QgJGFjX2N2X2NfdWludDE2X3QKLV9B
Q0VPRgotOzsKLSAgZXNhYwogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjMyIiAi
YWNfY3ZfY191aW50MzJfdCIKLWNhc2UgJGFjX2N2X2NfdWludDMyX3QgaW4gIygKLSAgbm98eWVz
KSA7OyAjKAotICAqKQogCi0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDMyX1QgMSIgPj5jb25mZGVm
cy5oCiAKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50MzJfdCAkYWNf
Y3ZfY191aW50MzJfdAotX0FDRU9GCi07OwotICBlc2FjCiAKLWFjX2ZuX2NfZmluZF91aW50WF90
ICIkTElORU5PIiAiNjQiICJhY19jdl9jX3VpbnQ2NF90IgotY2FzZSAkYWNfY3ZfY191aW50NjRf
dCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCitpZiB0ZXN0ICJ4JGFjX2N2X2Vudl9QS0dfQ09ORklH
X3NldCIgIT0gInhzZXQiOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9cGtnLWNv
bmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfcGF0aF9QS0dfQ09ORklHK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/Oltc
XC9dKikKKyAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CiAgICopCisgIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUEtH
X0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ2NF9UIDEiID4+Y29uZmRlZnMuaAotCisgIDs7
Citlc2FjCitmaQorUEtHX0NPTkZJRz0kYWNfY3ZfcGF0aF9QS0dfQ09ORklHCitpZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRQS0dfQ09ORklHIiA+JjUKKyRhc19lY2hvICIkUEtHX0NPTkZJRyIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKIAotY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50NjRfdCAkYWNfY3ZfY191aW50NjRfdAotX0FDRU9G
Ci07OwotICBlc2FjCiAKLWFjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiOCIgImFjX2N2
X2NfdWludDhfdCIKLWNhc2UgJGFjX2N2X2NfdWludDhfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMo
CitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRoZW4KKyAgYWNfcHRf
UEtHX0NPTkZJRz0kUEtHX0NPTkZJRworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBr
Zy1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX2FjX3B0
X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCisgIFtcXC9dKiB8ID86W1xc
L10qKQorICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19wdF9QS0dfQ09ORklHIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKICAgKikK
KyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAk
UEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNf
Y3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUwogCi0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDhfVCAxIiA+PmNv
bmZkZWZzLmgKLQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHVpbnQ4X3Qg
JGFjX2N2X2NfdWludDhfdAotX0FDRU9GCi07OwotICBlc2FjCi0KLWFjX2ZuX2NfY2hlY2tfdHlw
ZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVfcHRyZGlmZl90IiAiJGFjX2luY2x1
ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcHRyZGlmZl90IiA9IHgiInllczsg
dGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9QVFJESUZG
X1QgMQotX0FDRU9GCi0KLQorICA7OworZXNhYworZmkKK2FjX3B0X1BLR19DT05GSUc9JGFjX2N2
X3BhdGhfYWNfcHRfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAiJGFjX3B0X1BLR19DT05GSUciOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfcHRfUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJGFjX3B0X1BLR19DT05GSUciID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotIyBDaGVja3MgZm9yIGxp
YnJhcnkgZnVuY3Rpb25zLgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfZXJyb3Jf
YXRfbGluZStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxlcnJvci5oPgotaW50Ci1tYWluICgpCi17
Ci1lcnJvcl9hdF9saW5lICgwLCAwLCAiIiwgMCwgImFuIGVycm9yIG9jY3VycmVkIik7Ci0gIDsK
LSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKLSAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVzCisgIGlmIHRlc3QgIngkYWNfcHRf
UEtHX0NPTkZJRyIgPSB4OyB0aGVuCisgICAgUEtHX0NPTkZJRz0iIgorICBlbHNlCisgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg
PiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIFBLR19DT05GSUc9JGFjX3B0
X1BLR19DT05GSUcKKyAgZmkKIGVsc2UKLSAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9bm8KLWZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0
aF9QS0dfQ09ORklHIgogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUiID4mNQotJGFzX2VjaG8gIiRhY19j
dl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9saWJfZXJyb3JfYXRf
bGluZSA9IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIGVycm9yLiRhY19v
YmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBlcnJvci4kYWNfb2JqZXh0Igot
IDs7Ci1lc2FjCiAKIGZpCi0KLWZvciBhY19oZWFkZXIgaW4gdmZvcmsuaAotZG8gOgotICBhY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidmZvcmsuaCIgImFjX2N2X2hlYWRl
cl92Zm9ya19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRl
cl92Zm9ya19oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgSEFWRV9WRk9SS19IIDEKLV9BQ0VPRgotCitpZiB0ZXN0IC1uICIkUEtHX0NPTkZJ
RyI7IHRoZW4KKwlfcGtnX21pbl92ZXJzaW9uPTAuOS4wCisJeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNp
b24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgcGtnLWNvbmZp
ZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uLi4uICIgPiY2OyB9CisJaWYg
JFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9u
OyB0aGVuCisJCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisJZWxzZQorCQl7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KKwkJUEtHX0NPTkZJRz0iIgorCWZpCiBmaQogCi1kb25lCi0KLWZvciBhY19mdW5j
IGluIGZvcmsgdmZvcmsKLWRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18k
YWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNf
ZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgi
eWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19l
Y2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VPRgotCi1maQotZG9uZQor
cGtnX2ZhaWxlZD1ubworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZ2xpYiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2xpYi4uLiAi
ID4mNjsgfQogCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9yayIgPSB4eWVzOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtp
bmcgZm9yayIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBmb3JrLi4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfZm9ya193b3JrcytzZXR9IiA9IHNldDsgdGhl
biA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgIiRjcm9z
c19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPWNyb3Nz
CitpZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0aGVuCisgICAgcGtnX2N2X2dsaWJfQ0ZMQUdT
PSIkZ2xpYl9DRkxBR1MiCisgZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgICBp
ZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMg
XCJnbGliLTIuMFwiIjsgfSA+JjUKKyAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJy
b3JzICJnbGliLTIuMCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9OyB0aGVuCisgIHBrZ19jdl9nbGliX0NGTEFHUz1gJFBLR19DT05GSUcgLS1j
ZmxhZ3MgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotCi0JICAvKiBCeSBSdWVkaWdlciBLdWhs
bWFubi4gKi8KLQkgIHJldHVybiBmb3JrICgpIDwgMDsKLQotICA7Ci0gIHJldHVybiAwOwotfQot
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVu
Y19mb3JrX3dvcmtzPXllcworICBwa2dfZmFpbGVkPXllcworZmkKKyBlbHNlCisgICAgcGtnX2Zh
aWxlZD11bnRyaWVkCitmaQoraWYgdGVzdCAtbiAiJGdsaWJfTElCUyI7IHRoZW4KKyAgICBwa2df
Y3ZfZ2xpYl9MSUJTPSIkZ2xpYl9MSUJTIgorIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0
aGVuCisgICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwKKyAgICB7IHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJp
bnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1CisgICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAt
LXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAg
dGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgorICBwa2dfY3ZfZ2xpYl9MSUJTPWAkUEtHX0NP
TkZJRyAtLWxpYnMgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAKIGVsc2UKLSAgYWNfY3ZfZnVuY19m
b3JrX3dvcmtzPW5vCisgIHBrZ19mYWlsZWQ9eWVzCiBmaQotcm0gLWYgY29yZSAqLmNvcmUgY29y
ZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorIGVsc2UKKyAg
ICBwa2dfZmFpbGVkPXVudHJpZWQKIGZpCiAKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY1Ci0kYXNf
ZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9CiAKKworaWYgdGVzdCAkcGtnX2Zh
aWxlZCA9IHllczsgdGhlbgorICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCitpZiAkUEtHX0NP
TkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtn
X3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCiBlbHNlCi0gIGFjX2N2X2Z1bmNfZm9ya193b3Jr
cz0kYWNfY3ZfZnVuY19mb3JrCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZD1u
bwogZmkKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhlbgot
ICBjYXNlICRob3N0IGluCi0gICAgKi0qLWFtaWdhb3MqIHwgKi0qLW1zZG9zZGpncHAqKQotICAg
ICAgIyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZlIG9ubHkgYSBkdW1teSBmb3JrKCkg
c3R1YgotICAgICAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCi0gICAgICA7OwotICAgICopCi0g
ICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCi0gICAgICA7OwotICBlc2FjCi0gIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19j
dl9mdW5jX2Zvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+
JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19mb3JrX3dv
cmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KLWZpCi1hY19j
dl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1
bmNfdmZvcmsiID0geHllczsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHZmb3JrIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB3b3JraW5nIHZmb3JrLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1
bmNfdmZvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6
Ci0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9Y3Jvc3MKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotLyog
VGhhbmtzIHRvIFBhdWwgRWdnZXJ0IGZvciB0aGlzIHRlc3QuICAqLwotJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQKLSNpbmNsdWRlIDxzeXMvd2FpdC5oPgotI2lmZGVmIEhBVkVfVkZPUktfSAotIyBpbmNs
dWRlIDx2Zm9yay5oPgotI2VuZGlmCi0vKiBPbiBzb21lIHNwYXJjIHN5c3RlbXMsIGNoYW5nZXMg
YnkgdGhlIGNoaWxkIHRvIGxvY2FsIGFuZCBpbmNvbWluZwotICAgYXJndW1lbnQgcmVnaXN0ZXJz
IGFyZSBwcm9wYWdhdGVkIGJhY2sgdG8gdGhlIHBhcmVudC4gIFRoZSBjb21waWxlcgotICAgaXMg
dG9sZCBhYm91dCB0aGlzIHdpdGggI2luY2x1ZGUgPHZmb3JrLmg+LCBidXQgc29tZSBjb21waWxl
cnMKLSAgIChlLmcuIGdjYyAtTykgZG9uJ3QgZ3JvayA8dmZvcmsuaD4uICBUZXN0IGZvciB0aGlz
IGJ5IHVzaW5nIGEKLSAgIHN0YXRpYyB2YXJpYWJsZSB3aG9zZSBhZGRyZXNzIGlzIHB1dCBpbnRv
IGEgcmVnaXN0ZXIgdGhhdCBpcwotICAgY2xvYmJlcmVkIGJ5IHRoZSB2Zm9yay4gICovCi1zdGF0
aWMgdm9pZAotI2lmZGVmIF9fY3BsdXNwbHVzCi1zcGFyY19hZGRyZXNzX3Rlc3QgKGludCBhcmcp
Ci0jIGVsc2UKLXNwYXJjX2FkZHJlc3NfdGVzdCAoYXJnKSBpbnQgYXJnOwotI2VuZGlmCi17Ci0g
IHN0YXRpYyBwaWRfdCBjaGlsZDsKLSAgaWYgKCFjaGlsZCkgewotICAgIGNoaWxkID0gdmZvcmsg
KCk7Ci0gICAgaWYgKGNoaWxkIDwgMCkgewotICAgICAgcGVycm9yICgidmZvcmsiKTsKLSAgICAg
IF9leGl0KDIpOwotICAgIH0KLSAgICBpZiAoIWNoaWxkKSB7Ci0gICAgICBhcmcgPSBnZXRwaWQo
KTsKLSAgICAgIHdyaXRlKC0xLCAiIiwgMCk7Ci0gICAgICBfZXhpdCAoYXJnKTsKLSAgICB9Ci0g
IH0KLX0KKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVz
OyB0aGVuCisJICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJy
b3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKKyAgICAgICAgZWxzZQorCSAgICAg
ICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAi
IDI+JjFgCisgICAgICAgIGZpCisJIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29u
ZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdzCisJZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIgPiY1CiAK
LWludAotbWFpbiAoKQotewotICBwaWRfdCBwYXJlbnQgPSBnZXRwaWQgKCk7Ci0gIHBpZF90IGNo
aWxkOwotCi0gIHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7Ci0KLSAgY2hpbGQgPSB2Zm9yayAoKTsK
LQotICBpZiAoY2hpbGQgPT0gMCkgewotICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0ZXN0IGZvciBz
cGFyYyB2Zm9yayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKLSAgICAgICB0ZXN0IHVzZXMgbG90
cyBvZiBsb2NhbCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1hbnkgbG9jYWwKLSAgICAgICB2YXJp
YWJsZXMgYXMgbWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBpbmNsdWRpbmcgY29tcGlsZXIKLSAg
ICAgICB0ZW1wb3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9yIGdjYyAxLjQwLjMgb24g
YSBTb2xhcmlzCi0gICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3ZSB1c2UgOCB0byBiZSBzYWZlLiAg
QSBidWdneSBjb21waWxlciBzaG91bGQKLSAgICAgICByZXVzZSB0aGUgcmVnaXN0ZXIgb2YgcGFy
ZW50IGZvciBvbmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywKLSAgICAgICBzaW5jZSBpdCB3aWxs
IHRoaW5rIHRoYXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJlIHVzZWQgYW55IG1vcmUKLSAgICAg
ICBpbiB0aGlzIHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhlIGxvY2FsIHZhcmlhYmxlIHdpbGwg
dGh1cwotICAgICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFyZW50IHByb2Nlc3MuICAqLwotICAg
IHBpZF90Ci0gICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0cGlkKCksIHAyID0gZ2V0cGlkKCks
IHAzID0gZ2V0cGlkKCksCi0gICAgICBwNCA9IGdldHBpZCgpLCBwNSA9IGdldHBpZCgpLCBwNiA9
IGdldHBpZCgpLCBwNyA9IGdldHBpZCgpOwotICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0
aGF0IHAuLnA3IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1pZ2h0Ci0gICAgICAgdXNlIHRoZSBz
YW1lIGhhcmR3YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2NhbCB2YXJpYWJsZXMuICAqLwotICAg
IGlmIChwICE9IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8fCBwICE9IHA0Ci0JfHwgcCAhPSBw
NSB8fCBwICE9IHA2IHx8IHAgIT0gcDcpCi0gICAgICBfZXhpdCgxKTsKLQotICAgIC8qIE9uIHNv
bWUgc3lzdGVtcyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50
Ci0gICAgICAgZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3JzLiAgSWYgdGhlIGNoaWxkIGNsb3Nl
cyBhIGRlc2NyaXB0b3IKLSAgICAgICBiZWZvcmUgaXQgZXhlY3Mgb3IgZXhpdHMsIHRoaXMgbXVu
Z2VzIHRoZSBwYXJlbnQncyBkZXNjcmlwdG9yCi0gICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRo
aXMgYnkgY2xvc2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KLSAgICBfZXhpdChjbG9zZShm
aWxlbm8oc3Rkb3V0KSkgIT0gMCk7Ci0gIH0gZWxzZSB7Ci0gICAgaW50IHN0YXR1czsKLSAgICBz
dHJ1Y3Qgc3RhdCBzdDsKKwlhc19mbl9lcnJvciAkPyAiUGFja2FnZSByZXF1aXJlbWVudHMgKGds
aWItMi4wKSB3ZXJlIG5vdCBtZXQ6CiAKLSAgICB3aGlsZSAod2FpdCgmc3RhdHVzKSAhPSBjaGls
ZCkKLSAgICAgIDsKLSAgICByZXR1cm4gKAotCSAvKiBXYXMgdGhlcmUgc29tZSBwcm9ibGVtIHdp
dGggdmZvcmtpbmc/ICAqLwotCSBjaGlsZCA8IDAKKyRnbGliX1BLR19FUlJPUlMKIAotCSAvKiBE
aWQgdGhlIGNoaWxkIGZhaWw/ICAoVGhpcyBzaG91bGRuJ3QgaGFwcGVuLikgICovCi0JIHx8IHN0
YXR1cworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1lbnQg
dmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJl
Zml4LgogCi0JIC8qIERpZCB0aGUgdmZvcmsvY29tcGlsZXIgYnVnIG9jY3VyPyAgKi8KLQkgfHwg
cGFyZW50ICE9IGdldHBpZCgpCitBbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJv
bm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBu
ZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3Ig
bW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKK2VsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJp
ZWQ7IHRoZW4KKyAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCXsgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFz
X2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3Ig
JD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9s
ZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBl
bnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0aCB0byBwa2ctY29uZmlnLgogCi0J
IC8qIERpZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1cj8gICovCi0JIHx8IGZzdGF0KGZp
bGVubyhzdGRvdXQpLCAmc3QpICE9IDAKLQkgKTsKLSAgfQotfQotX0FDRU9GCi1pZiBhY19mbl9j
X3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz15ZXMK
K0FsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZpcm9ubWVudCB2YXJpYWJsZXMgZ2xp
Yl9DRkxBR1MKK2FuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29u
ZmlnLgorU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuCisKK1Rv
IGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+
LgorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CiBl
bHNlCi0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KLWZpCi1ybSAtZiBjb3JlICouY29yZSBj
b3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Ci1maQorCWds
aWJfQ0ZMQUdTPSRwa2dfY3ZfZ2xpYl9DRkxBR1MKKwlnbGliX0xJQlM9JHBrZ19jdl9nbGliX0xJ
QlMKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KIAogZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY192Zm9ya193b3Jr
cyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID4mNjsgfQogCi1maTsK
LWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhlbgotICBhY19j
dl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCi0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX3Zmb3Jr
X3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1Ci0kYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MgZ3Vlc3Nl
ZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7fQorIyBDaGVjayBsaWJyYXJ5IHBh
dGgKK2lmIHRlc3QgIlwke2V4ZWNfcHJlZml4fS9saWIiID0gIiRsaWJkaXIiOyB0aGVuIDoKKyAg
aWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIiAmJiB0ZXN0ICIkcHJlZml4IiAhPSAiTk9O
RSI7IHRoZW4gOgorICBleGVjX3ByZWZpeD0kcHJlZml4CiBmaQorICAgIGlmIHRlc3QgIiRleGVj
X3ByZWZpeCIgPSAiTk9ORSI7IHRoZW4gOgorICBleGVjX3ByZWZpeD0kYWNfZGVmYXVsdF9wcmVm
aXgKK2ZpCisgICAgaWYgdGVzdCAtZCAiJHtleGVjX3ByZWZpeH0vbGliNjQiOyB0aGVuIDoKIAot
aWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KLQotJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX1ZGT1JLIDEiID4+Y29uZmRlZnMuaAorICAgICAgICBM
SUJfUEFUSD0ibGliNjQiCiAKIGVsc2UKIAotJGFzX2VjaG8gIiNkZWZpbmUgdmZvcmsgZm9yayIg
Pj5jb25mZGVmcy5oCisgICAgICAgIExJQl9QQVRIPSJsaWIiCiAKIGZpCi1pZiB0ZXN0ICJ4JGFj
X2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhB
VkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorZWxzZQogCi1maQorICAgIExJQl9QQVRI
PSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVjX3ByZWZpeCIgKyAxYH0iCiAKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVf
U09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMu
Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2Urc2V0fSIg
PSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICB3aGls
ZSA6OyBkbwotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+IC8qIGZvciBvZmZf
dCAqLwotICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KLWludAotbWFpbiAoKQotewotaW50ICgqZnAp
IChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwotICAgICByZXR1cm4gZnNlZWtvIChzdGRp
biwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VP
RgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9zeXNfbGFy
Z2VmaWxlX3NvdXJjZT1ubzsgYnJlYWsKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQg
Y29uZmRlZnMuaC4gICovCi0jZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFIDEKLSNpbmNsdWRlIDxz
eXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCi0gICAgICNpbmNsdWRlIDxzdGRpby5oPgotaW50
Ci1tYWluICgpCi17Ci1pbnQgKCpmcCkgKEZJTEUgKiwgb2ZmX3QsIGludCkgPSBmc2Vla287Ci0g
ICAgIHJldHVybiBmc2Vla28gKHN0ZGluLCAwLCAwKSAmJiBmcCAoc3RkaW4sIDAsIDApOwotICA7
Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPTE7IGJyZWFrCiBmaQotcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9dW5r
bm93bgotICBicmVhawotZG9uZQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNQotJGFzX2Vj
aG8gIiRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2OyB9Ci1jYXNlICRhY19jdl9zeXNf
bGFyZ2VmaWxlX3NvdXJjZSBpbiAjKAotICBubyB8IHVua25vd24pIDs7Ci0gICopCi1jYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFICRhY19jdl9zeXNf
bGFyZ2VmaWxlX3NvdXJjZQotX0FDRU9GCi07OwotZXNhYwotcm0gLXJmIGNvbmZ0ZXN0KgotCi0j
IFdlIHVzZWQgdG8gdHJ5IGRlZmluaW5nIF9YT1BFTl9TT1VSQ0U9NTAwIHRvbywgdG8gd29yayBh
cm91bmQgYSBidWcKLSMgaW4gZ2xpYmMgMi4xLjMsIGJ1dCB0aGF0IGJyZWFrcyB0b28gbWFueSBv
dGhlciB0aGluZ3MuCi0jIElmIHlvdSB3YW50IGZzZWVrbyBhbmQgZnRlbGxvIHdpdGggZ2xpYmMs
IHVwZ3JhZGUgdG8gYSBmaXhlZCBnbGliYy4KLWlmIHRlc3QgJGFjX2N2X3N5c19sYXJnZWZpbGVf
c291cmNlICE9IHVua25vd247IHRoZW4KIAotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9GU0VFS08g
MSIgPj5jb25mZGVmcy5oCiAKLWZpCisjIENoZWNrcyBmb3IgbGlicmFyaWVzLgorYWNfZm5fY19j
aGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImJ6bGliLmgiICJhY19jdl9oZWFkZXJfYnps
aWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfYnps
aWJfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMgdHJhaWxp
bmcgc2xhc2giID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0
bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9m
dW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsrc2V0fSIgPSBzZXQ7IHRoZW4g
OgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
QloyX2J6RGVjb21wcmVzc0luaXQgaW4gLWxiejIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIk
e2FjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBzZXQ7IHRoZW4gOgog
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBybSAtZiBjb25mdGVzdC5zeW0g
Y29uZnRlc3QuZmlsZQotZWNobyA+Y29uZnRlc3QuZmlsZQotaWYgdGVzdCAiJGFzX2xuX3MiID0g
ImxuIC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0ZXN0LnN5bTsgdGhlbgotICBpZiB0
ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfbHN0YXRf
ZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubwotZWxzZQotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKK0xJQlM9Ii1sYnoyICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0
CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy
cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl
IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k
aWYKK2NoYXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7CiBpbnQKIG1haW4gKCkKIHsKLXN0cnVj
dCBzdGF0IHNidWY7Ci0gICAgIC8qIExpbnV4IHdpbGwgZGVyZWZlcmVuY2UgdGhlIHN5bWxpbmsg
YW5kIGZhaWwsIGFzIHJlcXVpcmVkIGJ5IFBPU0lYLgotCVRoYXQgaXMgYmV0dGVyIGluIHRoZSBz
ZW5zZSB0aGF0IGl0IG1lYW5zIHdlIHdpbGwgbm90Ci0JaGF2ZSB0byBjb21waWxlIGFuZCB1c2Ug
dGhlIGxzdGF0IHdyYXBwZXIuICAqLwotICAgICByZXR1cm4gbHN0YXQgKCJjb25mdGVzdC5zeW0v
IiwgJnNidWYpID09IDA7CityZXR1cm4gQloyX2J6RGVjb21wcmVzc0luaXQgKCk7CiAgIDsKICAg
cmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9eWVzCi1l
bHNlCi0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubwot
ZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29u
ZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNv
bmZ0ZXN0LiRhY19leHQKLWZpCi0KK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVu
IDoKKyAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdD15ZXMKIGVsc2UKLSAgIyBJ
ZiB0aGUgYGxuIC1zJyBjb21tYW5kIGZhaWxlZCwgdGhlbiB3ZSBwcm9iYWJseSBkb24ndCBldmVu
Ci0gICMgaGF2ZSBhbiBsc3RhdCBmdW5jdGlvbi4KLSAgYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVy
ZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCisgIGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVz
c0luaXQ9bm8KIGZpCi1ybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQotCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9i
ejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfYnoy
X0JaMl9iekRlY29tcHJlc3NJbml0IiA9IHgiInllczsgdGhlbiA6CisgIHpsaWI9IiR6bGliIC1E
SEFWRV9CWkxJQiAtbGJ6MiIKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3lt
bGluayIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNo
ZWRfc3ltbGluayIgPiY2OyB9Ci0KLXRlc3QgJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2Vz
X3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0j
ZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LIDEKLV9BQ0VPRgogCitmaQogCi1p
ZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIg
PSB4bm87IHRoZW4KLSAgY2FzZSAiICRMSUJPQkpTICIgaW4KLSAgKiIgbHN0YXQuJGFjX29iamV4
dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIGxzdGF0LiRhY19vYmpleHQiCi0gOzsK
LWVzYWMKIAotZmkKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJsem1h
LmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X2hlYWRlcl9sem1hX2giID0geCIieWVzOyB0aGVuIDoKIAoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5o
IGRlZmluZXMgbWFrZWRldiIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHN5cy90
eXBlcy5oIGRlZmluZXMgbWFrZWRldi4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFk
ZXJfc3lzX3R5cGVzX2hfbWFrZWRlditzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem1hX3N0cmVhbV9kZWNv
ZGVyIGluIC1sbHptYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgbHptYV9zdHJlYW1f
ZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bWFf
bHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxsem1hICAk
TElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKworLyogT3ZlcnJpZGUg
YW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hh
ciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1
aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g
ICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBsem1hX3N0
cmVhbV9kZWNvZGVyICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gbWFrZWRldigwLCAwKTsK
K3JldHVybiBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwogICA7CiAgIHJldHVybiAwOwogfQogX0FD
RU9GCiBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2hlYWRl
cl9zeXNfdHlwZXNfaF9tYWtlZGV2PXllcworICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9k
ZWNvZGVyPXllcwogZWxzZQotICBhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj1ubwor
ICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5vCiBmaQogcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCiAgICAgY29uZnRlc3QkYWNfZXhlZXh0
IGNvbmZ0ZXN0LiRhY19leHQKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYiID4mNQot
JGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIgPiY2OyB9Ci0KLWlm
IHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2ID0gbm87IHRoZW4KLWFjX2Zu
X2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvbWtkZXYuaCIgImFjX2N2X2hl
YWRlcl9zeXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19j
dl9oZWFkZXJfc3lzX21rZGV2X2giID0geCIieWVzOyB0aGVuIDoKLQotJGFzX2VjaG8gIiNkZWZp
bmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCi0KK0xJQlM9JGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlMKIGZpCi0KLQotCi0gIGlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCA9
IG5vOyB0aGVuCi0gICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN5
cy9zeXNtYWNyb3MuaCIgImFjX2N2X2hlYWRlcl9zeXNfc3lzbWFjcm9zX2giICIkYWNfaW5jbHVk
ZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgPSB4
IiJ5ZXM7IHRoZW4gOgotCi0kYXNfZWNobyAiI2RlZmluZSBNQUpPUl9JTl9TWVNNQUNST1MgMSIg
Pj5jb25mZGVmcy5oCi0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXIiID4mNjsgfQoraWYgdGVzdCAi
eCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyIiA9IHgiInllczsgdGhlbiA6Cisg
IHpsaWI9IiR6bGliIC1ESEFWRV9MWk1BIC1sbHptYSIKIGZpCiAKIAotICBmaQogZmkKIAotZm9y
IGFjX2hlYWRlciBpbiBzdGRsaWIuaAotZG8gOgotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25n
cmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3RkbGliX2giICIkYWNfaW5j
bHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiA9IHgiInll
czsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVERM
SUJfSCAxCi1fQUNFT0YKLQotZmkKIAotZG9uZQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem9fbHpvMXhfaCIg
PSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxvYyIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSBtYWxsb2MuLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsK3NldH0iID0gc2V0OyB0aGVu
IDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIg
PSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9bm8KLWVsc2UKLSAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGx6bzIgICRMSUJTIgorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lm
IGRlZmluZWQgU1REQ19IRUFERVJTIHx8IGRlZmluZWQgSEFWRV9TVERMSUJfSAotIyBpbmNsdWRl
IDxzdGRsaWIuaD4KLSNlbHNlCi1jaGFyICptYWxsb2MgKCk7Ci0jZW5kaWYKIAorLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBsem8x
eF9kZWNvbXByZXNzICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gISBtYWxsb2MgKDApOwor
cmV0dXJuIGx6bzF4X2RlY29tcHJlc3MgKCk7CiAgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YK
LWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX21hbGxv
Y18wX25vbm51bGw9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9eWVzCiBlbHNlCi0gIGFjX2N2X2Z1bmNf
bWFsbG9jXzBfbm9ubnVsbD1ubworICBhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPW5v
CiBmaQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBj
b25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0g
Y29uZnRlc3QuJGFjX2V4dAorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA9IHgiInllczsgdGhlbiA6
CisgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCiBmaQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX21hbGxvY18wX25v
bm51bGwiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNjsg
fQotaWYgdGVzdCAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKLQot
JGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMSIgPj5jb25mZGVmcy5oCi0KLWVsc2UKLSAg
JGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMCIgPj5jb25mZGVmcy5oCi0KLSAgIGNhc2Ug
IiAkTElCT0JKUyAiIGluCi0gICoiIG1hbGxvYy4kYWNfb2JqZXh0ICIqICkgOzsKLSAgKikgTElC
T0JKUz0iJExJQk9CSlMgbWFsbG9jLiRhY19vYmpleHQiCi0gOzsKLWVzYWMKLQogCi0kYXNfZWNo
byAiI2RlZmluZSBtYWxsb2MgcnBsX21hbGxvYyIgPj5jb25mZGVmcy5oCiAKIGZpCiAKIAoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRp
bWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNs
dWRlZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFkZXJfdGltZStzZXR9IiA9IHNl
dDsgdGhlbiA6CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfYWlv
X2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAor
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGFpbyAgJExJQlMiCitjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRlZnMu
aC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL3RpbWUuaD4KLSNp
bmNsdWRlIDx0aW1lLmg+CiAKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl
IHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg
dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu
dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitl
eHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgaW9fc2V0dXAgKCk7CiBpbnQKIG1haW4gKCkKIHsKLWlm
ICgoc3RydWN0IHRtICopIDApCi1yZXR1cm4gMDsKK3JldHVybiBpb19zZXR1cCAoKTsKICAgOwog
ICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgotICBhY19jdl9oZWFkZXJfdGltZT15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRM
SU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15ZXMKIGVsc2UKLSAgYWNf
Y3ZfaGVhZGVyX3RpbWU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl90aW1lIiA+JjUKLSRhc19lY2hv
ICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3RpbWUg
PSB5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgVElNRV9XSVRIX1NZU19USU1FIDEiID4+
Y29uZmRlZnMuaAotCisgIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9bm8KIGZpCi0KLQotCi0KLSAg
Zm9yIGFjX2hlYWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKLWRvIDoKLSAgYXNfYWNfSGVhZGVyPWAk
YXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAotYWNfZm5fY19j
aGVja19oZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVy
IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSIKLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVh
ZGVyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2Rl
ZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YK
LQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29u
ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZl
X0xJQlMKIGZpCi0KLWRvbmUKLQotCi0KLQotCi0KLQotCi0gIGZvciBhY19mdW5jIGluICRhY19m
dW5jX2xpc3QKLWRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVu
YyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIg
IiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsg
dGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJI
QVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VPRgotCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9haW9faW9fc2V0dXAi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjY7IH0KK2lmIHRlc3Qg
IngkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBzeXN0ZW1fYWlv
PSJ5IgorZWxzZQorICBzeXN0ZW1fYWlvPSJuIgogZmkKLWRvbmUKLQogCiAKLQotCi17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1r
dGltZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBta3RpbWUuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY193b3JraW5nX21rdGltZStzZXR9IiA9IHNldDsg
dGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIE1ENSBp
biAtbGNyeXB0by4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfY3J5cHRvX01ENStz
ZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0g
IGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY193
b3JraW5nX21rdGltZT1ubwotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sY3J5
cHRvICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLS8qIFRlc3QgcHJvZ3JhbSBmcm9tIFBhdWwgRWdnZXJ0
IGFuZCBUb255IExlbmVpcy4gICovCi0jaWZkZWYgVElNRV9XSVRIX1NZU19USU1FCi0jIGluY2x1
ZGUgPHN5cy90aW1lLmg+Ci0jIGluY2x1ZGUgPHRpbWUuaD4KLSNlbHNlCi0jIGlmZGVmIEhBVkVf
U1lTX1RJTUVfSAotIyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4KLSMgZWxzZQotIyAgaW5jbHVkZSA8
dGltZS5oPgotIyBlbmRpZgotI2VuZGlmCi0KLSNpbmNsdWRlIDxsaW1pdHMuaD4KLSNpbmNsdWRl
IDxzdGRsaWIuaD4KIAotI2lmZGVmIEhBVkVfVU5JU1REX0gKLSMgaW5jbHVkZSA8dW5pc3RkLmg+
Ci0jZW5kaWYKLQotI2lmbmRlZiBIQVZFX0FMQVJNCi0jIGRlZmluZSBhbGFybShYKSAvKiBlbXB0
eSAqLworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4g
ZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5
cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3
b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKICNl
bmRpZgotCi0vKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24gdG8gcnBsX3B1dGVudiBieSBvdGhl
ciBjb25maWcgdGVzdHMuICAqLwotI3VuZGVmIHB1dGVudgotCi1zdGF0aWMgdGltZV90IHRpbWVf
dF9tYXg7Ci1zdGF0aWMgdGltZV90IHRpbWVfdF9taW47Ci0KLS8qIFZhbHVlcyB3ZSdsbCB1c2Ug
dG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4gICovCi1zdGF0aWMgY29uc3QgY2hh
ciAqdHpfc3RyaW5nc1tdID0gewotICAoY29uc3QgY2hhciAqKSAwLCAiVFo9R01UMCIsICJUWj1K
U1QtOSIsCi0gICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6MDA6MDAsTTIuMy4wLzAwOjAwOjAw
IgotfTsKLSNkZWZpbmUgTl9TVFJJTkdTIChzaXplb2YgKHR6X3N0cmluZ3MpIC8gc2l6ZW9mICh0
el9zdHJpbmdzWzBdKSkKLQotLyogUmV0dXJuIDAgaWYgbWt0aW1lIGZhaWxzIHRvIGNvbnZlcnQg
YSBkYXRlIGluIHRoZSBzcHJpbmctZm9yd2FyZCBnYXAuCi0gICBCYXNlZCBvbiBhIHByb2JsZW0g
cmVwb3J0IGZyb20gQW5kcmVhcyBKYWVnZXIuICAqLwotc3RhdGljIGludAotc3ByaW5nX2Zvcndh
cmRfZ2FwICgpCi17Ci0gIC8qIGdsaWJjICh1cCB0byBhYm91dCAxOTk4LTEwLTA3KSBmYWlsZWQg
dGhpcyB0ZXN0LiAqLwotICBzdHJ1Y3QgdG0gdG07Ci0KLSAgLyogVXNlIHRoZSBwb3J0YWJsZSBQ
T1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCi0gICAgIGlu
c3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBkZXRlY3QgdGhlIGJ1
ZyBldmVuCi0gICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBleHRl
bnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCi0gICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGluc3Rh
bGxlZC4gICovCi0gIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIp
OwotCi0gIHRtLnRtX3llYXIgPSA5ODsKLSAgdG0udG1fbW9uID0gMzsKLSAgdG0udG1fbWRheSA9
IDU7Ci0gIHRtLnRtX2hvdXIgPSAyOwotICB0bS50bV9taW4gPSAwOwotICB0bS50bV9zZWMgPSAw
OwotICB0bS50bV9pc2RzdCA9IC0xOwotICByZXR1cm4gbWt0aW1lICgmdG0pICE9ICh0aW1lX3Qp
IC0xOwotfQotCi1zdGF0aWMgaW50Ci1ta3RpbWVfdGVzdDEgKHRpbWVfdCBub3cpCi17Ci0gIHN0
cnVjdCB0bSAqbHQ7Ci0gIHJldHVybiAhIChsdCA9IGxvY2FsdGltZSAoJm5vdykpIHx8IG1rdGlt
ZSAobHQpID09IG5vdzsKLX0KLQotc3RhdGljIGludAotbWt0aW1lX3Rlc3QgKHRpbWVfdCBub3cp
Ci17Ci0gIHJldHVybiAobWt0aW1lX3Rlc3QxIChub3cpCi0JICAmJiBta3RpbWVfdGVzdDEgKCh0
aW1lX3QpICh0aW1lX3RfbWF4IC0gbm93KSkKLQkgICYmIG1rdGltZV90ZXN0MSAoKHRpbWVfdCkg
KHRpbWVfdF9taW4gKyBub3cpKSk7Ci19Ci0KLXN0YXRpYyBpbnQKLWlyaXhfNl80X2J1ZyAoKQot
ewotICAvKiBCYXNlZCBvbiBjb2RlIGZyb20gQXJpZWwgRmFpZ29uLiAgKi8KLSAgc3RydWN0IHRt
IHRtOwotICB0bS50bV95ZWFyID0gOTY7Ci0gIHRtLnRtX21vbiA9IDM7Ci0gIHRtLnRtX21kYXkg
PSAwOwotICB0bS50bV9ob3VyID0gMDsKLSAgdG0udG1fbWluID0gMDsKLSAgdG0udG1fc2VjID0g
MDsKLSAgdG0udG1faXNkc3QgPSAtMTsKLSAgbWt0aW1lICgmdG0pOwotICByZXR1cm4gdG0udG1f
bW9uID09IDIgJiYgdG0udG1fbWRheSA9PSAzMTsKLX0KLQotc3RhdGljIGludAotYmlndGltZV90
ZXN0IChpbnQgaikKLXsKLSAgc3RydWN0IHRtIHRtOwotICB0aW1lX3Qgbm93OwotICB0bS50bV95
ZWFyID0gdG0udG1fbW9uID0gdG0udG1fbWRheSA9IHRtLnRtX2hvdXIgPSB0bS50bV9taW4gPSB0
bS50bV9zZWMgPSBqOwotICBub3cgPSBta3RpbWUgKCZ0bSk7Ci0gIGlmIChub3cgIT0gKHRpbWVf
dCkgLTEpCi0gICAgewotICAgICAgc3RydWN0IHRtICpsdCA9IGxvY2FsdGltZSAoJm5vdyk7Ci0g
ICAgICBpZiAoISAobHQKLQkgICAgICYmIGx0LT50bV95ZWFyID09IHRtLnRtX3llYXIKLQkgICAg
ICYmIGx0LT50bV9tb24gPT0gdG0udG1fbW9uCi0JICAgICAmJiBsdC0+dG1fbWRheSA9PSB0bS50
bV9tZGF5Ci0JICAgICAmJiBsdC0+dG1faG91ciA9PSB0bS50bV9ob3VyCi0JICAgICAmJiBsdC0+
dG1fbWluID09IHRtLnRtX21pbgotCSAgICAgJiYgbHQtPnRtX3NlYyA9PSB0bS50bV9zZWMKLQkg
ICAgICYmIGx0LT50bV95ZGF5ID09IHRtLnRtX3lkYXkKLQkgICAgICYmIGx0LT50bV93ZGF5ID09
IHRtLnRtX3dkYXkKLQkgICAgICYmICgobHQtPnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IGx0LT50
bV9pc2RzdCkKLQkJICA9PSAodG0udG1faXNkc3QgPCAwID8gLTEgOiAwIDwgdG0udG1faXNkc3Qp
KSkpCi0JcmV0dXJuIDA7Ci0gICAgfQotICByZXR1cm4gMTsKLX0KLQotc3RhdGljIGludAoteWVh
cl8yMDUwX3Rlc3QgKCkKLXsKLSAgLyogVGhlIGNvcnJlY3QgYW5zd2VyIGZvciAyMDUwLTAyLTAx
IDAwOjAwOjAwIGluIFBhY2lmaWMgdGltZSwKLSAgICAgaWdub3JpbmcgbGVhcCBzZWNvbmRzLiAg
Ki8KLSAgdW5zaWduZWQgbG9uZyBpbnQgYW5zd2VyID0gMjUyNzMxNTIwMFVMOwotCi0gIHN0cnVj
dCB0bSB0bTsKLSAgdGltZV90IHQ7Ci0gIHRtLnRtX3llYXIgPSAyMDUwIC0gMTkwMDsKLSAgdG0u
dG1fbW9uID0gMiAtIDE7Ci0gIHRtLnRtX21kYXkgPSAxOwotICB0bS50bV9ob3VyID0gdG0udG1f
bWluID0gdG0udG1fc2VjID0gMDsKLSAgdG0udG1faXNkc3QgPSAtMTsKLQotICAvKiBVc2UgdGhl
IHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUu
MCIKLSAgICAgaW5zdGVhZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRl
dGVjdCB0aGUgYnVnIGV2ZW4KLSAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhl
IE9sc29uIGV4dGVuc2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUKLSAgICAgZnVsbCB6b25laW5mbyB0
YWJsZXMgaW5zdGFsbGVkLiAgKi8KLSAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEu
MCxNMTAuNS4wIik7Ci0KLSAgdCA9IG1rdGltZSAoJnRtKTsKLQotICAvKiBDaGVjayB0aGF0IHRo
ZSByZXN1bHQgaXMgZWl0aGVyIGEgZmFpbHVyZSwgb3IgY2xvc2UgZW5vdWdoCi0gICAgIHRvIHRo
ZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdlIGNhbiBhc3N1bWUgdGhlIGRpc2NyZXBhbmN5IGlzCi0g
ICAgIGR1ZSB0byBsZWFwIHNlY29uZHMuICAqLwotICByZXR1cm4gKHQgPT0gKHRpbWVfdCkgLTEK
LQkgIHx8ICgwIDwgdCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAmJiB0IDw9IGFuc3dlciArIDEyMCkp
OwotfQotCitjaGFyIE1ENSAoKTsKIGludAogbWFpbiAoKQogewotICB0aW1lX3QgdCwgZGVsdGE7
Ci0gIGludCBpLCBqOwotCi0gIC8qIFRoaXMgdGVzdCBtYWtlcyBzb21lIGJ1Z2d5IG1rdGltZSBp
bXBsZW1lbnRhdGlvbnMgbG9vcC4KLSAgICAgR2l2ZSB1cCBhZnRlciA2MCBzZWNvbmRzOyBhIG1r
dGltZSBzbG93ZXIgdGhhbiB0aGF0Ci0gICAgIGlzbid0IHdvcnRoIHVzaW5nIGFueXdheS4gICov
Ci0gIGFsYXJtICg2MCk7Ci0KLSAgZm9yICg7OykKLSAgICB7Ci0gICAgICB0ID0gKHRpbWVfdF9t
YXggPDwgMSkgKyAxOwotICAgICAgaWYgKHQgPD0gdGltZV90X21heCkKLQlicmVhazsKLSAgICAg
IHRpbWVfdF9tYXggPSB0OwotICAgIH0KLSAgdGltZV90X21pbiA9IC0gKCh0aW1lX3QpIH4gKHRp
bWVfdCkgMCA9PSAodGltZV90KSAtMSkgLSB0aW1lX3RfbWF4OwotCi0gIGRlbHRhID0gdGltZV90
X21heCAvIDk5NzsgLyogYSBzdWl0YWJsZSBwcmltZSBudW1iZXIgKi8KLSAgZm9yIChpID0gMDsg
aSA8IE5fU1RSSU5HUzsgaSsrKQotICAgIHsKLSAgICAgIGlmICh0el9zdHJpbmdzW2ldKQotCXB1
dGVudiAoKGNoYXIqKSB0el9zdHJpbmdzW2ldKTsKLQotICAgICAgZm9yICh0ID0gMDsgdCA8PSB0
aW1lX3RfbWF4IC0gZGVsdGE7IHQgKz0gZGVsdGEpCi0JaWYgKCEgbWt0aW1lX3Rlc3QgKHQpKQot
CSAgcmV0dXJuIDE7Ci0gICAgICBpZiAoISAobWt0aW1lX3Rlc3QgKCh0aW1lX3QpIDEpCi0JICAg
ICAmJiBta3RpbWVfdGVzdCAoKHRpbWVfdCkgKDYwICogNjApKQotCSAgICAgJiYgbWt0aW1lX3Rl
c3QgKCh0aW1lX3QpICg2MCAqIDYwICogMjQpKSkpCi0JcmV0dXJuIDE7Ci0KLSAgICAgIGZvciAo
aiA9IDE7IDsgaiA8PD0gMSkKLQlpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQotCSAgcmV0dXJuIDE7
Ci0JZWxzZSBpZiAoSU5UX01BWCAvIDIgPCBqKQotCSAgYnJlYWs7Ci0gICAgICBpZiAoISBiaWd0
aW1lX3Rlc3QgKElOVF9NQVgpKQotCXJldHVybiAxOwotICAgIH0KLSAgcmV0dXJuICEgKGlyaXhf
Nl80X2J1ZyAoKSAmJiBzcHJpbmdfZm9yd2FyZF9nYXAgKCkgJiYgeWVhcl8yMDUwX3Rlc3QgKCkp
OworcmV0dXJuIE1ENSAoKTsKKyAgOworICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5f
Y190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWU9
eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9j
cnlwdG9fTUQ1PXllcwogZWxzZQotICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCi1maQot
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAotZmkKLQorICBhY19jdl9saWJfY3J5cHRvX01ENT1ubwogZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY193b3Jr
aW5nX21rdGltZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4m
NjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVuY193b3JraW5nX21rdGltZSA9IG5vOyB0aGVuCi0gIGNh
c2UgIiAkTElCT0JKUyAiIGluCi0gICoiIG1rdGltZS4kYWNfb2JqZXh0ICIqICkgOzsKLSAgKikg
TElCT0JKUz0iJExJQk9CSlMgbWt0aW1lLiRhY19vYmpleHQiCi0gOzsKLWVzYWMKLQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZp
Ci0KLQotCi0KLQotCi1mb3IgYWNfZnVuYyBpbiBnZXRwYWdlc2l6ZQotZG8gOgotICBhY19mbl9j
X2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6ZSIgImFjX2N2X2Z1bmNfZ2V0cGFnZXNp
emUiCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiID0geCIieWVzOyB0aGVuIDoK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX2NyeXB0b19NRDUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY2
OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9IHgiInllczsgdGhlbiA6CiAg
IGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9HRVRQQUdFU0laRSAxCisj
ZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKIF9BQ0VPRgogCisgIExJQlM9Ii1sY3J5cHRvICRMSUJT
IgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJjcnlwdG8iICIk
TElORU5PIiA1CiBmaQotZG9uZQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX21t
YXBfZml4ZWRfbWFwcGVkK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJm
cyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZz
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yK3Nl
dH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAg
aWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX21t
YXBfZml4ZWRfbWFwcGVkPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxl
eHQyZnMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLS8qIG1hbGxv
YyBtaWdodCBoYXZlIGJlZW4gcmVuYW1lZCBhcyBycGxfbWFsbG9jLiAqLwotI3VuZGVmIG1hbGxv
YwotCi0vKiBUaGFua3MgdG8gTWlrZSBIYWVydGVsIGFuZCBKaW0gQXZlcmEgZm9yIHRoaXMgdGVz
dC4KLSAgIEhlcmUgaXMgYSBtYXRyaXggb2YgbW1hcCBwb3NzaWJpbGl0aWVzOgotCW1tYXAgcHJp
dmF0ZSBub3QgZml4ZWQKLQltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJlbnRs
eSB1bm1hcHBlZAotCW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBw
ZWQKLQltbWFwIHNoYXJlZCBub3QgZml4ZWQKLQltbWFwIHNoYXJlZCBmaXhlZCBhdCBzb21ld2hl
cmUgY3VycmVudGx5IHVubWFwcGVkCi0JbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGFs
cmVhZHkgbWFwcGVkCi0gICBGb3IgcHJpdmF0ZSBtYXBwaW5ncywgd2Ugc2hvdWxkIHZlcmlmeSB0
aGF0IGNoYW5nZXMgY2Fubm90IGJlIHJlYWQoKQotICAgYmFjayBmcm9tIHRoZSBmaWxlLCBub3Ig
bW1hcCdzIGJhY2sgZnJvbSB0aGUgZmlsZSBhdCBhIGRpZmZlcmVudAotICAgYWRkcmVzcy4gIChU
aGVyZSBoYXZlIGJlZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRlIHdhcyBub3QgY29ycmVjdGx5Ci0g
ICBpbXBsZW1lbnRlZCBsaWtlIHRoZSBpbmZhbW91cyBpMzg2IHN2cjQuMCwgYW5kIHN5c3RlbXMg
d2hlcmUgdGhlCi0gICBWTSBwYWdlIGNhY2hlIHdhcyBub3QgY29oZXJlbnQgd2l0aCB0aGUgZmls
ZSBzeXN0ZW0gYnVmZmVyIGNhY2hlCi0gICBsaWtlIGVhcmx5IHZlcnNpb25zIG9mIEZyZWVCU0Qg
YW5kIHBvc3NpYmx5IGNvbnRlbXBvcmFyeSBOZXRCU0QuKQotICAgRm9yIHNoYXJlZCBtYXBwaW5n
cywgd2Ugc2hvdWxkIGNvbnZlcnNlbHkgdmVyaWZ5IHRoYXQgY2hhbmdlcyBnZXQKLSAgIHByb3Bh
Z2F0ZWQgYmFjayB0byBhbGwgdGhlIHBsYWNlcyB0aGV5J3JlIHN1cHBvc2VkIHRvIGJlLgotCi0g
ICBHcmVwIHdhbnRzIHByaXZhdGUgZml4ZWQgYWxyZWFkeSBtYXBwZWQuCi0gICBUaGUgbWFpbiB0
aGluZ3MgZ3JlcCBuZWVkcyB0byBrbm93IGFib3V0IG1tYXAgYXJlOgotICAgKiBkb2VzIGl0IGV4
aXN0IGFuZCBpcyBpdCBzYWZlIHRvIHdyaXRlIGludG8gdGhlIG1tYXAnZCBhcmVhCi0gICAqIGhv
dyB0byB1c2UgaXQgKEJTRCB2YXJpYW50cykgICovCi0KLSNpbmNsdWRlIDxmY250bC5oPgotI2lu
Y2x1ZGUgPHN5cy9tbWFuLmg+Ci0KLSNpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMgJiYgIWRlZmlu
ZWQgSEFWRV9TVERMSUJfSAotY2hhciAqbWFsbG9jICgpOwotI2VuZGlmCi0KLS8qIFRoaXMgbWVz
cyB3YXMgY29waWVkIGZyb20gdGhlIEdOVSBnZXRwYWdlc2l6ZS5oLiAgKi8KLSNpZm5kZWYgSEFW
RV9HRVRQQUdFU0laRQotIyBpZmRlZiBfU0NfUEFHRVNJWkUKLSMgIGRlZmluZSBnZXRwYWdlc2l6
ZSgpIHN5c2NvbmYoX1NDX1BBR0VTSVpFKQotIyBlbHNlIC8qIG5vIF9TQ19QQUdFU0laRSAqLwot
IyAgaWZkZWYgSEFWRV9TWVNfUEFSQU1fSAotIyAgIGluY2x1ZGUgPHN5cy9wYXJhbS5oPgotIyAg
IGlmZGVmIEVYRUNfUEFHRVNJWkUKLSMgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgRVhFQ19QQUdF
U0laRQotIyAgIGVsc2UgLyogbm8gRVhFQ19QQUdFU0laRSAqLwotIyAgICBpZmRlZiBOQlBHCi0j
ICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBOQlBHICogQ0xTSVpFCi0jICAgICBpZm5kZWYgQ0xT
SVpFCi0jICAgICAgZGVmaW5lIENMU0laRSAxCi0jICAgICBlbmRpZiAvKiBubyBDTFNJWkUgKi8K
LSMgICAgZWxzZSAvKiBubyBOQlBHICovCi0jICAgICBpZmRlZiBOQlBDCi0jICAgICAgZGVmaW5l
IGdldHBhZ2VzaXplKCkgTkJQQwotIyAgICAgZWxzZSAvKiBubyBOQlBDICovCi0jICAgICAgaWZk
ZWYgUEFHRVNJWkUKLSMgICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgUEFHRVNJWkUKLSMgICAg
ICBlbmRpZiAvKiBQQUdFU0laRSAqLwotIyAgICAgZW5kaWYgLyogbm8gTkJQQyAqLwotIyAgICBl
bmRpZiAvKiBubyBOQlBHICovCi0jICAgZW5kaWYgLyogbm8gRVhFQ19QQUdFU0laRSAqLwotIyAg
ZWxzZSAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCi0jICAgZGVmaW5lIGdldHBhZ2VzaXplKCkg
ODE5MgkvKiBwdW50IHRvdGFsbHkgKi8KLSMgIGVuZGlmIC8qIG5vIEhBVkVfU1lTX1BBUkFNX0gg
Ki8KLSMgZW5kaWYgLyogbm8gX1NDX1BBR0VTSVpFICovCi0KLSNlbmRpZiAvKiBubyBIQVZFX0dF
VFBBR0VTSVpFICovCiAKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRv
IGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl
IHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBw
cm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRl
cm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0MmZzX29wZW4yICgpOwogaW50CiBtYWluICgpCiB7Ci0g
IGNoYXIgKmRhdGEsICpkYXRhMiwgKmRhdGEzOwotICBjb25zdCBjaGFyICpjZGF0YTI7Ci0gIGlu
dCBpLCBwYWdlc2l6ZTsKLSAgaW50IGZkLCBmZDI7Ci0KLSAgcGFnZXNpemUgPSBnZXRwYWdlc2l6
ZSAoKTsKLQotICAvKiBGaXJzdCwgbWFrZSBhIGZpbGUgd2l0aCBzb21lIGtub3duIGdhcmJhZ2Ug
aW4gaXQuICovCi0gIGRhdGEgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsKLSAgaWYgKCFk
YXRhKQotICAgIHJldHVybiAxOwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKLSAg
ICAqKGRhdGEgKyBpKSA9IHJhbmQgKCk7Ci0gIHVtYXNrICgwKTsKLSAgZmQgPSBjcmVhdCAoImNv
bmZ0ZXN0Lm1tYXAiLCAwNjAwKTsKLSAgaWYgKGZkIDwgMCkKLSAgICByZXR1cm4gMjsKLSAgaWYg
KHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2VzaXplKQotICAgIHJldHVybiAzOwot
ICBjbG9zZSAoZmQpOwotCi0gIC8qIE5leHQsIGNoZWNrIHRoYXQgdGhlIHRhaWwgb2YgYSBwYWdl
IGlzIHplcm8tZmlsbGVkLiAgRmlsZSBtdXN0IGhhdmUKLSAgICAgbm9uLXplcm8gbGVuZ3RoLCBv
dGhlcndpc2Ugd2UgcmlzayBTSUdCVVMgZm9yIGVudGlyZSBwYWdlLiAgKi8KLSAgZmQyID0gb3Bl
biAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQgfCBPX1RSVU5DLCAwNjAwKTsKLSAg
aWYgKGZkMiA8IDApCi0gICAgcmV0dXJuIDQ7Ci0gIGNkYXRhMiA9ICIiOwotICBpZiAod3JpdGUg
KGZkMiwgY2RhdGEyLCAxKSAhPSAxKQotICAgIHJldHVybiA1OwotICBkYXRhMiA9IChjaGFyICop
IG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dSSVRFLCBNQVBfU0hBUkVELCBm
ZDIsIDBMKTsKLSAgaWYgKGRhdGEyID09IE1BUF9GQUlMRUQpCi0gICAgcmV0dXJuIDY7Ci0gIGZv
ciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQotICAgIGlmICgqKGRhdGEyICsgaSkpCi0gICAg
ICByZXR1cm4gNzsKLSAgY2xvc2UgKGZkMik7Ci0gIGlmIChtdW5tYXAgKGRhdGEyLCBwYWdlc2l6
ZSkpCi0gICAgcmV0dXJuIDg7Ci0KLSAgLyogTmV4dCwgdHJ5IHRvIG1tYXAgdGhlIGZpbGUgYXQg
YSBmaXhlZCBhZGRyZXNzIHdoaWNoIGFscmVhZHkgaGFzCi0gICAgIHNvbWV0aGluZyBlbHNlIGFs
bG9jYXRlZCBhdCBpdC4gIElmIHdlIGNhbiwgYWxzbyBtYWtlIHN1cmUgdGhhdAotICAgICB3ZSBz
ZWUgdGhlIHNhbWUgZ2FyYmFnZS4gICovCi0gIGZkID0gb3BlbiAoImNvbmZ0ZXN0Lm1tYXAiLCBP
X1JEV1IpOwotICBpZiAoZmQgPCAwKQotICAgIHJldHVybiA5OwotICBpZiAoZGF0YTIgIT0gbW1h
cCAoZGF0YTIsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dSSVRFLAotCQkgICAgIE1BUF9Q
UklWQVRFIHwgTUFQX0ZJWEVELCBmZCwgMEwpKQotICAgIHJldHVybiAxMDsKLSAgZm9yIChpID0g
MDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgaWYgKCooZGF0YSArIGkpICE9ICooZGF0YTIgKyBp
KSkKLSAgICAgIHJldHVybiAxMTsKLQotICAvKiBGaW5hbGx5LCBtYWtlIHN1cmUgdGhhdCBjaGFu
Z2VzIHRvIHRoZSBtYXBwZWQgYXJlYSBkbyBub3QKLSAgICAgcGVyY29sYXRlIGJhY2sgdG8gdGhl
IGZpbGUgYXMgc2VlbiBieSByZWFkKCkuICAoVGhpcyBpcyBhIGJ1ZyBvbgotICAgICBzb21lIHZh
cmlhbnRzIG9mIGkzODYgc3ZyNC4wLikgICovCi0gIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsg
KytpKQotICAgICooZGF0YTIgKyBpKSA9ICooZGF0YTIgKyBpKSArIDE7Ci0gIGRhdGEzID0gKGNo
YXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7Ci0gIGlmICghZGF0YTMpCi0gICAgcmV0dXJuIDEyOwot
ICBpZiAocmVhZCAoZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0gcGFnZXNpemUpCi0gICAgcmV0dXJu
IDEzOwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKLSAgICBpZiAoKihkYXRhICsg
aSkgIT0gKihkYXRhMyArIGkpKQotICAgICAgcmV0dXJuIDE0OwotICBjbG9zZSAoZmQpOworcmV0
dXJuIGV4dDJmc19vcGVuMiAoKTsKKyAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNf
Zm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9t
YXBwZWQ9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2
X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcwogZWxzZQotICBhY19jdl9mdW5jX21tYXBfZml4
ZWRfbWFwcGVkPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24u
b3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKLQorICBhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMj1ubwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVu
Y19tbWFwX2ZpeGVkX21hcHBlZCA9IHllczsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBIQVZF
X01NQVAgMSIgPj5jb25mZGVmcy5oCi0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitM
SUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotcm0gLWYgY29uZnRlc3QubW1hcCBjb25m
dGVzdC50eHQKLQotZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAotZG8gOgotICBhY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3Rk
bGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0
ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNk
ZWZpbmUgSEFWRV9TVERMSUJfSCAxCi1fQUNFT0YKLQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIg
PiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjY7IH0KK2lm
IHRlc3QgIngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID0geCIieWVzOyB0aGVuIDoK
KyAgbGliZXh0MmZzPSJ5IgorZWxzZQorICBsaWJleHQyZnM9Im4iCiBmaQogCi1kb25lCiAKLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEdOVSBs
aWJjIGNvbXBhdGlibGUgcmVhbGxvYyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgR05V
IGxpYmMgY29tcGF0aWJsZSByZWFsbG9jLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1
bmNfcmVhbGxvY18wX25vbm51bGwrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZl
ciBpbiAtbGdjcnlwdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNo
X2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfZ2Ny
eXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHll
czsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9bm8KLWVsc2UKLSAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJf
c2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGdjcnlwdCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWYg
ZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICi0jIGluY2x1ZGUg
PHN0ZGxpYi5oPgotI2Vsc2UKLWNoYXIgKnJlYWxsb2MgKCk7Ci0jZW5kaWYKIAorLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBnY3J5
X21kX2hhc2hfYnVmZmVyICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gISByZWFsbG9jICgw
LCAwKTsKK3JldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwogICA7CiAgIHJldHVybiAwOwog
fQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zf
ZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyPXllcwogZWxz
ZQotICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCisgIGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwogZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRl
c3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25m
dGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5
cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJnY3J5cHQ9InkiCitl
bHNlCisgIGxpYmdjcnlwdD0ibiIKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNQotJGFz
X2VjaG8gIiRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KLWlmIHRlc3QgJGFj
X2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwgPSB5ZXM7IHRoZW4gOgogCi0kYXNfZWNobyAiI2Rl
ZmluZSBIQVZFX1JFQUxMT0MgMSIgPj5jb25mZGVmcy5oCiAKKworICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZyIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZCBmbGFnLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2F4X2N2X3B0aHJlYWRfZmxhZ3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX1JFQUxM
T0MgMCIgPj5jb25mZGVmcy5oCiAKLSAgIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIHJlYWxs
b2MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIHJlYWxsb2MuJGFj
X29iamV4dCIKLSA7OwotZXNhYworICAgICAgICBheF9jdl9wdGhyZWFkX2ZsYWdzPS1wdGhyZWFk
CisKKyAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVB
RF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKKyAgICBQVEhSRUFEX0xJQlM9IiIKKwor
CisgICAgc2F2ZWRfQ0ZMQUdTPSIkQ0ZMQUdTIgorCisgICAgc2F2ZWRfTERGTEFHUz0iJExERkxB
R1MiCisKKyAgICBzYXZlZF9MSUJTPSIkTElCUyIKKworCisgICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQ
VEhSRUFEX0NGTEFHUyIKKworICAgIExERkxBR1M9IiRMREZMQUdTICRQVEhSRUFEX0xERkxBR1Mi
CisKKyAgICBMSUJTPSIkTElCUyAkUFRIUkVBRF9MSUJTIgorCisgICAgICAgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworI2luY2x1ZGUgPHB0aHJlYWQuaD4KK2ludCBtYWluKHZvaWQpIHsKKyAgcHRocmVhZF9hdGZv
cmsoMCwwLDApOworICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCwwKTsKK30KKworX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYXhfY3ZfcHRocmVh
ZF9mbGFncz1mYWlsZWQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorCisgICAg
Q0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgorCisgICAgTERGTEFHUz0iJHNhdmVkX0xERkxBR1MiCiAK
KyAgICBMSUJTPSIkc2F2ZWRfTElCUyIKIAotJGFzX2VjaG8gIiNkZWZpbmUgcmVhbGxvYyBycGxf
cmVhbGxvYyIgPj5jb25mZGVmcy5oCiAKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQorJGFzX2VjaG8g
IiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7IH0KKyAgICBpZiB0ZXN0ICJ4JGF4X2N2X3B0aHJl
YWRfZmxhZ3MiID0geGZhaWxlZDsgdGhlbgorICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0aHJl
YWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKKyAgICBmaQorCisgICAgUFRIUkVBRF9DRkxB
R1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgorICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0
aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MSUJTPSIiCisKIAogCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4iID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3Rybmxlbi4uLiAiID4mNjsgfQot
aWYgdGVzdCAiJHthY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZytzZXR9IiA9IHNldDsgdGhlbiA6
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB5
YWpsX2FsbG9jIGluIC1seWFqbCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgeWFqbF9h
bGxvYyBpbiAtbHlhamwuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3lhamxfeWFq
bF9hbGxvYytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNf
Y3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitM
SUJTPSItbHlhamwgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciB5YWpsX2FsbG9jICgpOwogaW50CiBtYWluICgpCiB7Ci0KLSNkZWZpbmUgUyAiZm9vYmFy
IgotI2RlZmluZSBTX0xFTiAoc2l6ZW9mIFMgLSAxKQotCi0gIC8qIEF0IGxlYXN0IG9uZSBpbXBs
ZW1lbnRhdGlvbiBpcyBidWdneTogdGhhdCBvZiBBSVggNC4zIHdvdWxkCi0gICAgIGdpdmUgc3Ry
bmxlbiAoUywgMSkgPT0gMy4gICovCi0KLSAgaW50IGk7Ci0gIGZvciAoaSA9IDA7IGkgPCBTX0xF
TiArIDE7ICsraSkKLSAgICB7Ci0gICAgICBpbnQgZXhwZWN0ZWQgPSBpIDw9IFNfTEVOID8gaSA6
IFNfTEVOOwotICAgICAgaWYgKHN0cm5sZW4gKFMsIGkpICE9IGV4cGVjdGVkKQotCXJldHVybiAx
OwotICAgIH0KLSAgcmV0dXJuIDA7Ci0KK3JldHVybiB5YWpsX2FsbG9jICgpOwogICA7CiAgIHJl
dHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoK
LSAgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCiBlbHNlCi0g
IGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nPW5vCisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxs
b2M9bm8KIGZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIu
b3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu
YmVhbSBjb25mdGVzdC4kYWNfZXh0CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElC
Uz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQoraWYgdGVzdCAieCRh
Y19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHgiInllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKK19BQ0VPRgogCi1maQoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5j
X3N0cm5sZW5fd29ya2luZyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3Jr
aW5nIiA+JjY7IH0KLXRlc3QgJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nID0gbm8gJiYgY2Fz
ZSAiICRMSUJPQkpTICIgaW4KLSAgKiIgc3Rybmxlbi4kYWNfb2JqZXh0ICIqICkgOzsKLSAgKikg
TElCT0JKUz0iJExJQk9CSlMgc3Rybmxlbi4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCisgIExJQlM9
Ii1seWFqbCAkTElCUyIKIAorZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQg
eWFqbCIgIiRMSU5FTk8iIDUKK2ZpCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9kIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9m
dW5jX3N0cnRvZCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHoiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1sei4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9saWJfel9kZWZsYXRlQ29weStzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxp
bmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KLWVsc2UKLSAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2
ZV9MSUJTPSRMSUJTCitMSUJTPSItbHogICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwogCi0kYWNfaW5jbHVk
ZXNfZGVmYXVsdAotI2lmbmRlZiBzdHJ0b2QKLWRvdWJsZSBzdHJ0b2QgKCk7CisvKiBPdmVycmlk
ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBj
aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAg
YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5
LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgogI2VuZGlmCitjaGFyIGRlZmxh
dGVDb3B5ICgpOwogaW50Ci1tYWluKCkKK21haW4gKCkKIHsKLSAgewotICAgIC8qIFNvbWUgdmVy
c2lvbnMgb2YgTGludXggc3RydG9kIG1pcy1wYXJzZSBzdHJpbmdzIHdpdGggbGVhZGluZyAnKycu
ICAqLwotICAgIGNoYXIgKnN0cmluZyA9ICIgKzY5IjsKLSAgICBjaGFyICp0ZXJtOwotICAgIGRv
dWJsZSB2YWx1ZTsKLSAgICB2YWx1ZSA9IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Ci0gICAgaWYg
KHZhbHVlICE9IDY5IHx8IHRlcm0gIT0gKHN0cmluZyArIDQpKQotICAgICAgcmV0dXJuIDE7Ci0g
IH0KLQotICB7Ci0gICAgLyogVW5kZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5zIHRoZSB3
cm9uZyB2YWx1ZSBmb3IgdGhlCi0gICAgICAgdGVybWluYXRpbmcgY2hhcmFjdGVyIHVuZGVyIHNv
bWUgY29uZGl0aW9ucy4gICovCi0gICAgY2hhciAqc3RyaW5nID0gIk5hTiI7Ci0gICAgY2hhciAq
dGVybTsKLSAgICBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOwotICAgIGlmICh0ZXJtICE9IHN0cmlu
ZyAmJiAqKHRlcm0gLSAxKSA9PSAwKQotICAgICAgcmV0dXJuIDE7Ci0gIH0KK3JldHVybiBkZWZs
YXRlQ29weSAoKTsKKyAgOwogICByZXR1cm4gMDsKIH0KLQogX0FDRU9GCi1pZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19zdHJ0b2Q9eWVzCitpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5
PXllcwogZWxzZQotICBhY19jdl9mdW5jX3N0cnRvZD1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3Jl
IGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKKyAgYWNf
Y3ZfbGliX3pfZGVmbGF0ZUNvcHk9bm8KIGZpCi0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf
ZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3N0cnRvZCIgPiY1Ci0k
YXNfZWNobyAiJGFjX2N2X2Z1bmNfc3RydG9kIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2Z1bmNf
c3RydG9kID0gbm87IHRoZW4KLSAgY2FzZSAiICRMSUJPQkpTICIgaW4KLSAgKiIgc3RydG9kLiRh
Y19vYmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBzdHJ0b2QuJGFjX29iamV4
dCIKLSA7OwotZXNhYworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xp
Yl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3pfZGVmbGF0ZUNv
cHkiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBIQVZFX0xJQlogMQorX0FDRU9GCiAKLWFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgInBv
dyIgImFjX2N2X2Z1bmNfcG93IgotaWYgdGVzdCAieCRhY19jdl9mdW5jX3BvdyIgPSB4IiJ5ZXM7
IHRoZW4gOgorICBMSUJTPSItbHogJExJQlMiCiAKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNv
dWxkIG5vdCBmaW5kIHpsaWIiICIkTElORU5PIiA1CiBmaQogCi1pZiB0ZXN0ICRhY19jdl9mdW5j
X3BvdyA9IG5vOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHBvdyBpbiAtbG0iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHBvdyBpbiAtbG0uLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX21fcG93K3NldH0i
ID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udiIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252Li4uICIgPiY2OyB9CitpZiB0ZXN0
ICIke2FjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuK3NldH0iID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKICAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUwotTElCUz0iLWxtICAkTElCUyIKK0xJQlM9Ii1saWNvbnYgICRMSUJTIgogY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwogCkBAIC05NTI4LDU1ICs2NTUzLDQ1IEBAIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKICNpZmRlZiBfX2NwbHVzcGx1cwogZXh0ZXJuICJDIgogI2VuZGlm
Ci1jaGFyIHBvdyAoKTsKK2NoYXIgbGliaWNvbnZfb3BlbiAoKTsKIGludAogbWFpbiAoKQogewot
cmV0dXJuIHBvdyAoKTsKK3JldHVybiBsaWJpY29udl9vcGVuICgpOwogICA7CiAgIHJldHVybiAw
OwogfQogX0FDRU9GCiBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFj
X2N2X2xpYl9tX3Bvdz15ZXMKKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49eWVzCiBl
bHNlCi0gIGFjX2N2X2xpYl9tX3Bvdz1ubworICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Bl
bj1ubwogZmkKIHJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAog
ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CiBMSUJTPSRhY19jaGVja19s
aWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9saWJfbV9wb3ciID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfbV9w
b3ciID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfbV9wb3ciID0geCIieWVzOyB0aGVuIDoK
LSAgUE9XX0xJQj0tbG0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNQorJGFzX2VjaG8gIiRh
Y19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9pY29udl9saWJpY29udl9vcGVuIiA9IHgiInllczsgdGhlbiA6CisgIGxpYmljb252PSJ5Igog
ZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6
IGNhbm5vdCBmaW5kIGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9mIHBvdyIgPiY1Ci0k
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcg
ZGVmaW5pdGlvbiBvZiBwb3ciID4mMjt9Ci1maQotCisgIGxpYmljb252PSJuIgogZmkKIAotZmkK
IAotZm9yIGFjX2Z1bmMgaW4gIFwKLSAgICAgICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8g
Y2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3luYyBmdHJ1bmNhdGUgXAotICAgICAgICAgICAgICAg
IGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhvc3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRh
eSBcCi0gICAgICAgICAgICAgICAgaW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hy
IG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKLSAgICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBh
dGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2VsZWN0IHNldGVudiBcCi0gICAgICAgICAg
ICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0
cm5kdXAgXAotICAgICAgICAgICAgICAgIHN0cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0
cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0IFwKLSAgICAgICAgICAgICAgICB1bmFtZSBcCiAK
KyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCitmb3IgYWNfaGVhZGVyIGluIHlhamwveWFqbF92
ZXJzaW9uLmgKIGRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVu
YyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIg
IiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsg
dGhlbiA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJ5YWpsL3lh
amxfdmVyc2lvbi5oIiAiYWNfY3ZfaGVhZGVyX3lhamxfeWFqbF92ZXJzaW9uX2giICIkYWNfaW5j
bHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3lhamxfeWFqbF92ZXJzaW9u
X2giID0geCIieWVzOyB0aGVuIDoKICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmlu
ZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1bmMiIHwgJGFzX3RyX2NwcGAgMQorI2RlZmluZSBIQVZF
X1lBSkxfWUFKTF9WRVJTSU9OX0ggMQogX0FDRU9GCiAKIGZpCisKIGRvbmUKIAogCmRpZmYgLS1n
aXQgYS90b29scy9jb25maWd1cmUuYWMgYi90b29scy9jb25maWd1cmUuYWMKaW5kZXggNTdjODg3
ZC4uZGViODQ4ZCAxMDA2NDQKLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCisrKyBiL3Rvb2xzL2Nv
bmZpZ3VyZS5hYwpAQCAtMTksOSArMTksNiBAQCByZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5D
TFVERVMsIFBSRVBFTkRfTElCLCBcCiBBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5z
dGVhZCB3aGVuIHBvc3NpYmxlLl0pCiBdKQogCi1BQ19VU0VfU1lTVEVNX0VYVEVOU0lPTlMKLUFD
X0NBTk9OSUNBTF9IT1NUCi0KICMgTTQgTWFjcm8gaW5jbHVkZXMKIG00X2luY2x1ZGUoW200L3Nh
dmV2YXIubTRdKQogbTRfaW5jbHVkZShbbTQvZmVhdHVyZXMubTRdKQpAQCAtNzUsOSArNzIsNyBA
QCBBQ19BUkdfVkFSKFtCQ0NdLCBbUGF0aCB0byBiY2MgdG9vbF0pCiBBQ19BUkdfVkFSKFtJQVNM
XSwgW1BhdGggdG8gaWFzbCB0b29sXSkKIAogIyBDaGVja3MgZm9yIHByb2dyYW1zLgotQUNfUFJP
R19TRUQKIEFDX1BST0dfQ0MKLUFDX1BST0dfTE5fUwogQUNfUFJPR19NQUtFX1NFVAogQUNfUFJP
R19JTlNUQUxMCiBBQ19QQVRIX1BST0coW0JJU09OXSwgW2Jpc29uXSkKQEAgLTEzNyw3ICsxMzIs
NiBAQCBBQ19TVUJTVChsaWJleHQyZnMpCiBBQ19DSEVDS19MSUIoW2djcnlwdF0sIFtnY3J5X21k
X2hhc2hfYnVmZmVyXSwgW2xpYmdjcnlwdD0ieSJdLCBbbGliZ2NyeXB0PSJuIl0pCiBBQ19TVUJT
VChsaWJnY3J5cHQpCiBBWF9DSEVDS19QVEhSRUFECi1BQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2Nr
X2dldHRpbWVdKQogQUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwKICAgICBb
QUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5YWpsXSldKQogQUNfQ0hFQ0tfTElCKFt6XSwg
W2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0p
CkBAIC0xNDUsNTggKzEzOSw2IEBAIEFDX0NIRUNLX0xJQihbaWNvbnZdLCBbbGliaWNvbnZfb3Bl
bl0sIFtsaWJpY29udj0ieSJdLCBbbGliaWNvbnY9Im4iXSkKIEFDX1NVQlNUKGxpYmljb252KQog
CiAjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgotQUNfRlVOQ19BTExPQ0EKLUFDX0NIRUNLX0hF
QURFUlMoWyBcCi0gICAgICAgICAgICAgICAgYXJwYS9pbmV0LmggZmNudGwuaCBpbnR0eXBlcy5o
IGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCi0gICAgICAgICAgICAgICAgbmV0ZGIuaCBu
ZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50Lmggc3RkbGliLmggc3RyaW5nLmggXAotICAgICAg
ICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5oIHN5cy9tb3VudC5oIHN5
cy9wYXJhbS5oIFwKLSAgICAgICAgICAgICAgICBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBz
eXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCi0gICAgICAgICAgICAgICAgdW5pc3RkLmgg
eWFqbC95YWpsX3ZlcnNpb24uaCBcCi0gICAgICAgICAgICAgICAgXSkKLQotIyBDaGVja3MgZm9y
IHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgotQUNf
SEVBREVSX1NUREJPT0wKLUFDX1RZUEVfVUlEX1QKLUFDX0NfSU5MSU5FCi1BQ19UWVBFX0lOVDE2
X1QKLUFDX1RZUEVfSU5UMzJfVAotQUNfVFlQRV9JTlQ2NF9UCi1BQ19UWVBFX0lOVDhfVAotQUNf
VFlQRV9NT0RFX1QKLUFDX1RZUEVfT0ZGX1QKLUFDX1RZUEVfUElEX1QKLUFDX0NfUkVTVFJJQ1QK
LUFDX1RZUEVfU0laRV9UCi1BQ19UWVBFX1NTSVpFX1QKLUFDX0NIRUNLX01FTUJFUlMoW3N0cnVj
dCBzdGF0LnN0X2Jsa3NpemVdKQotQUNfU1RSVUNUX1NUX0JMT0NLUwotQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCi1BQ19UWVBFX1VJTlQxNl9UCi1BQ19UWVBFX1VJTlQz
Ml9UCi1BQ19UWVBFX1VJTlQ2NF9UCi1BQ19UWVBFX1VJTlQ4X1QKLUFDX0NIRUNLX1RZUEVTKFtw
dHJkaWZmX3RdKQotCi0jIENoZWNrcyBmb3IgbGlicmFyeSBmdW5jdGlvbnMuCi1BQ19GVU5DX0VS
Uk9SX0FUX0xJTkUKLUFDX0ZVTkNfRk9SSwotQUNfRlVOQ19GU0VFS08KLUFDX0ZVTkNfTFNUQVRf
Rk9MTE9XU19TTEFTSEVEX1NZTUxJTksKLUFDX0hFQURFUl9NQUpPUgotQUNfRlVOQ19NQUxMT0MK
LUFDX0ZVTkNfTUtUSU1FCi1BQ19GVU5DX01NQVAKLUFDX0ZVTkNfUkVBTExPQwotQUNfRlVOQ19T
VFJOTEVOCi1BQ19GVU5DX1NUUlRPRAotQUNfQ0hFQ0tfRlVOQ1MoWyBcCi0gICAgICAgICAgICAg
ICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5j
YXRlIFwKLSAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBn
ZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAotICAgICAgICAgICAgICAgIGluZXRfbnRvYSBpc2Fz
Y2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3ZlIG1lbXNldCBta2RpciBcCi0gICAgICAgICAg
ICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVj
dCBzZXRlbnYgXAotICAgICAgICAgICAgICAgIHNvY2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJj
c3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKLSAgICAgICAgICAgICAgICBzdHJwYnJrIHN0
cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNldCBcCi0gICAg
ICAgICAgICAgICAgdW5hbWUgXAotICAgICAgICAgICAgICAgIF0pCitBQ19DSEVDS19IRUFERVJT
KFt5YWpsL3lhamxfdmVyc2lvbi5oXSkKIAogQUNfT1VUUFVUKCkKLS0gCjEuNy4yLjUKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Apr 25 15:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 15:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4Zj-0000Jv-LN; Wed, 25 Apr 2012 15:56:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4Zf-00009K-At
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 15:56:12 +0000
Received: from [193.109.254.147:51904] by server-3.bemta-14.messagelabs.com id
	C9/7C-23274-99E189F4; Wed, 25 Apr 2012 15:56:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335369363!1112892!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20927 invoked from network); 25 Apr 2012 15:56:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 15:56:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 15:56:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 16:56:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007ar-0K; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZQ-0003Qa-TT;
	Wed, 25 Apr 2012 16:55:56 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:32 +0100
Message-ID: <1335369353-13012-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] =?utf-8?q?=5BPATCH_04/25=5D_autoconf=3A_trim_the_conf?=
	=?utf-8?q?igure_script=3B_use_autoheader?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVtb3ZlIGEgbG90IG9mIHVubmVjZXNzYXJ5IHRlc3RzLiAgU3BlY2lmaWNhbGx5LCB3ZSBubyBs
b25nZXIgdGVzdApmb3Igc3RhbmRhcmQgUE9TSVggZmFjaWxpdGllcyB3aGljaCB3ZSBleHBlY3Qg
dG8gYmUgcHJvdmlkZWQKZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNhc2Ug
aGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgoKU3dpdGNoIHRvIGdlbmVyYXRpbmcgY29uZmlnLmgu
aW4gd2l0aCBhdXRvaGVhZGVyLgoKU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNr
c29uQGV1LmNpdHJpeC5jb20+CkNjOiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51
cGMuZWR1PgoKQ2hhbmdlcyBzaW5jZSB2NzoKICogUmVtb3ZlZCBBWF9DSEVDS19QVFlGVU5DUyAo
c251Y2sgaW4gZnJvbSBwcmV2aW91cyBwYXRjaCkKLS0tCiBhdXRvZ2VuLnNoICAgICAgICAgfCAg
ICAxICsKIHRvb2xzL2NvbmZpZy5oLmluICB8ICAgNzMgKy0KIHRvb2xzL2NvbmZpZ3VyZSAgICB8
IDg4MjUgKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogdG9vbHMvY29uZmlndXJlLmFjIHwgICA2MCArLQogNCBmaWxlcyBjaGFuZ2VkLCAyOTgxIGlu
c2VydGlvbnMoKyksIDU5NzggZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXV0b2dlbi5zaCBi
L2F1dG9nZW4uc2gKaW5kZXggYzI4OGI3MS4uNThhNzFjZSAxMDA3NTUKLS0tIGEvYXV0b2dlbi5z
aAorKysgYi9hdXRvZ2VuLnNoCkBAIC0xLDMgKzEsNCBAQAogIyEvYmluL3NoIC1lCiBjZCB0b29s
cwogYXV0b2NvbmYKK2F1dG9oZWFkZXIKZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbmZpZy5oLmluIGIv
dG9vbHMvY29uZmlnLmguaW4KaW5kZXggZjhmOTZkYy4uMTdjODkxMyAxMDA2NDQKLS0tIGEvdG9v
bHMvY29uZmlnLmguaW4KKysrIGIvdG9vbHMvY29uZmlnLmguaW4KQEAgLTEsMTkgKzEsNjQgQEAK
LS8qCi0gKiBDb3B5cmlnaHQgKEMpIDIwMTIKLSAqCi0gKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQotICogaXQgdW5k
ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMg
cHVibGlzaGVkCi0gKiBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyB2ZXJzaW9uIDIu
MSBvbmx5LiB3aXRoIHRoZSBzcGVjaWFsCi0gKiBleGNlcHRpb24gb24gbGlua2luZyBkZXNjcmli
ZWQgaW4gZmlsZSBMSUNFTlNFLgotICoKLSAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBp
biB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAotICogYnV0IFdJVEhPVVQgQU5ZIFdB
UlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKLSAqIE1FUkNIQU5U
QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKLSAq
IEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgotICov
CisvKiBjb25maWcuaC5pbi4gIEdlbmVyYXRlZCBmcm9tIGNvbmZpZ3VyZS5hYyBieSBhdXRvaGVh
ZGVyLiAgKi8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0lOVFRZUEVTX0gKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIGBjcnlwdG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KKyN1bmRlZiBI
QVZFX0xJQkNSWVBUTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHlhamwnIGxp
YnJhcnkgKC1seWFqbCkuICovCisjdW5kZWYgSEFWRV9MSUJZQUpMCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgeicgbGlicmFyeSAoLWx6KS4gKi8KKyN1bmRlZiBIQVZFX0xJQloK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxtZW1vcnkuaD4gaGVhZGVyIGZpbGUu
ICovCisjdW5kZWYgSEFWRV9NRU1PUllfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN0ZGludC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURElOVF9ICisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkbGliLmg+IGhlYWRlciBmaWxlLiAqLwor
I3VuZGVmIEhBVkVfU1RETElCX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxz
dHJpbmdzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1RSSU5HU19ICisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5nLmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfU1RSSU5HX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMv
c3RhdC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19TVEFUX0gKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvdHlwZXMuaD4gaGVhZGVyIGZpbGUuICovCisj
dW5kZWYgSEFWRV9TWVNfVFlQRVNfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
PHVuaXN0ZC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1VOSVNURF9ICiAKIC8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4gaGVhZGVyIGZp
bGUuICovCiAjdW5kZWYgSEFWRV9ZQUpMX1lBSkxfVkVSU0lPTl9ICiAKLS8qIERlZmluZSBjdXJz
ZXMgaGVhZGVyIHRvIGluY2x1ZGUuICovCisvKiBEZWZpbmUgY3Vyc2VzIGhlYWRlciB0byB1c2Ug
Ki8KICN1bmRlZiBJTkNMVURFX0NVUlNFU19ICisKKy8qIERlZmluZSB0byB0aGUgYWRkcmVzcyB3
aGVyZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLworI3Vu
ZGVmIFBBQ0tBR0VfQlVHUkVQT1JUCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1lIG9mIHRo
aXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX05BTUUKKworLyogRGVmaW5lIHRvIHRoZSBm
dWxsIG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0Vf
U1RSSU5HCisKKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBzaG9ydCBuYW1lIG9mIHRoaXMg
cGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1RBUk5BTUUKKworLyogRGVmaW5lIHRvIHRoZSBo
b21lIHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1VSTAorCisvKiBE
ZWZpbmUgdG8gdGhlIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0Vf
VkVSU0lPTgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgQU5TSSBDIGhlYWRlciBm
aWxlcy4gKi8KKyN1bmRlZiBTVERDX0hFQURFUlMKZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbmZpZ3Vy
ZSBiL3Rvb2xzL2NvbmZpZ3VyZQppbmRleCA4OTdlMDYxLi5kODkxOGZlIDEwMDc1NQotLS0gYS90
b29scy9jb25maWd1cmUKKysrIGIvdG9vbHMvY29uZmlndXJlCkBAIC01OTUsMTIgKzU5NSw4IEBA
IGFjX2luY2x1ZGVzX2RlZmF1bHQ9IlwKICMgaW5jbHVkZSA8dW5pc3RkLmg+CiAjZW5kaWYiCiAK
LWFjX2hlYWRlcl9saXN0PQotYWNfZnVuY19saXN0PQogYWNfc3Vic3RfdmFycz0nTFRMSUJPQkpT
Ci1QT1dfTElCCiBMSUJPQkpTCi1BTExPQ0EKIGxpYmljb252CiBQVEhSRUFEX0xJQlMKIFBUSFJF
QURfTERGTEFHUwpAQCAtNjE2LDYgKzYxMiw5IEBAIFBLR19DT05GSUdfTElCRElSCiBQS0dfQ09O
RklHX1BBVEgKIFBLR19DT05GSUcKIENVUlNFU19MSUJTCitFR1JFUAorR1JFUAorQ1BQCiBweWNv
bmZpZwogUFlUSE9OUEFUSAogT0NBTUxCVUlMRApAQCAtNjM1LDggKzYzNCwxMyBAQCBJTlNUQUxM
X0RBVEEKIElOU1RBTExfU0NSSVBUCiBJTlNUQUxMX1BST0dSQU0KIFNFVF9NQUtFCi1MTl9TCi1T
RUQKK09CSkVYVAorRVhFRVhUCithY19jdF9DQworQ1BQRkxBR1MKK0xERkxBR1MKK0NGTEFHUwor
Q0MKIElBU0wKIEJDQwogTEQ4NgpAQCAtNjY1LDI0ICs2NjksNiBAQCB4ZW5hcGkKIHZ0cG0KIG1v
bml0b3JzCiBnaXRodHRwCi1ob3N0X29zCi1ob3N0X3ZlbmRvcgotaG9zdF9jcHUKLWhvc3QKLWJ1
aWxkX29zCi1idWlsZF92ZW5kb3IKLWJ1aWxkX2NwdQotYnVpbGQKLUVHUkVQCi1HUkVQCi1DUFAK
LU9CSkVYVAotRVhFRVhUCi1hY19jdF9DQwotQ1BQRkxBR1MKLUxERkxBR1MKLUNGTEFHUwotQ0MK
IHRhcmdldF9hbGlhcwogaG9zdF9hbGlhcwogYnVpbGRfYWxpYXMKQEAgLTc0MCwxMiArNzI2LDYg
QEAgZW5hYmxlX2RlYnVnCiAgICAgICBhY19wcmVjaW91c192YXJzPSdidWlsZF9hbGlhcwogaG9z
dF9hbGlhcwogdGFyZ2V0X2FsaWFzCi1DQwotQ0ZMQUdTCi1MREZMQUdTCi1MSUJTCi1DUFBGTEFH
UwotQ1BQCiBQUkVQRU5EX0lOQ0xVREVTCiBQUkVQRU5EX0xJQgogQVBQRU5EX0lOQ0xVREVTCkBA
IC03NjIsNiArNzQyLDEyIEBAIEFTODYKIExEODYKIEJDQwogSUFTTAorQ0MKK0NGTEFHUworTERG
TEFHUworTElCUworQ1BQRkxBR1MKK0NQUAogUEtHX0NPTkZJRwogUEtHX0NPTkZJR19QQVRICiBQ
S0dfQ09ORklHX0xJQkRJUgpAQCAtMTM2NSwxMCArMTM1MSw2IEBAIEZpbmUgdHVuaW5nIG9mIHRo
ZSBpbnN0YWxsYXRpb24gZGlyZWN0b3JpZXM6CiBfQUNFT0YKIAogICBjYXQgPDxcX0FDRU9GCi0K
LVN5c3RlbSB0eXBlczoKLSAgLS1idWlsZD1CVUlMRCAgICAgY29uZmlndXJlIGZvciBidWlsZGlu
ZyBvbiBCVUlMRCBbZ3Vlc3NlZF0KLSAgLS1ob3N0PUhPU1QgICAgICAgY3Jvc3MtY29tcGlsZSB0
byBidWlsZCBwcm9ncmFtcyB0byBydW4gb24gSE9TVCBbQlVJTERdCiBfQUNFT0YKIGZpCiAKQEAg
LTEzOTksMTQgKzEzODEsNiBAQCBPcHRpb25hbCBGZWF0dXJlczoKICAgLS1kaXNhYmxlLWRlYnVn
ICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiB0b29scyAoZGVmYXVsdCBpcyBFTkFCTEVE
KQogCiBTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoKLSAgQ0MgICAgICAg
ICAgQyBjb21waWxlciBjb21tYW5kCi0gIENGTEFHUyAgICAgIEMgY29tcGlsZXIgZmxhZ3MKLSAg
TERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxp
YnJhcmllcyBpbiBhCi0gICAgICAgICAgICAgIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8bGliIGRp
cj4KLSAgTElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8gdGhlIGxpbmtlciwgZS5nLiAt
bDxsaWJyYXJ5PgotICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3Ig
ZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCi0gICAgICAgICAgICAgIHlvdSBoYXZlIGhl
YWRlcnMgaW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1ZGUgZGlyPgotICBDUFAgICAg
ICAgICBDIHByZXByb2Nlc3NvcgogICBQUkVQRU5EX0lOQ0xVREVTCiAgICAgICAgICAgICAgIExp
c3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQog
ICBQUkVQRU5EX0xJQiBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxB
R1MgKHdpdGhvdXQgLUwpCkBAIC0xNDI1LDYgKzEzOTksMTQgQEAgU29tZSBpbmZsdWVudGlhbCBl
bnZpcm9ubWVudCB2YXJpYWJsZXM6CiAgIExEODYgICAgICAgIFBhdGggdG8gbGQ4NiB0b29sCiAg
IEJDQyAgICAgICAgIFBhdGggdG8gYmNjIHRvb2wKICAgSUFTTCAgICAgICAgUGF0aCB0byBpYXNs
IHRvb2wKKyAgQ0MgICAgICAgICAgQyBjb21waWxlciBjb21tYW5kCisgIENGTEFHUyAgICAgIEMg
Y29tcGlsZXIgZmxhZ3MKKyAgTERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBk
aXI+IGlmIHlvdSBoYXZlIGxpYnJhcmllcyBpbiBhCisgICAgICAgICAgICAgIG5vbnN0YW5kYXJk
IGRpcmVjdG9yeSA8bGliIGRpcj4KKyAgTElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8g
dGhlIGxpbmtlciwgZS5nLiAtbDxsaWJyYXJ5PgorICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBD
L0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCisgICAgICAg
ICAgICAgIHlvdSBoYXZlIGhlYWRlcnMgaW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1
ZGUgZGlyPgorICBDUFAgICAgICAgICBDIHByZXByb2Nlc3NvcgogICBQS0dfQ09ORklHICBwYXRo
IHRvIHBrZy1jb25maWcgdXRpbGl0eQogICBQS0dfQ09ORklHX1BBVEgKICAgICAgICAgICAgICAg
ZGlyZWN0b3JpZXMgdG8gYWRkIHRvIHBrZy1jb25maWcncyBzZWFyY2ggcGF0aApAQCAtMTc5Nywz
MTEgKzE3NzksNiBAQCBmaQogICBhc19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKIAogfSAjIGFj
X2ZuX2NfdHJ5X2xpbmsKLQotIyBhY19mbl9jX2NoZWNrX2Z1bmMgTElORU5PIEZVTkMgVkFSCi0j
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgVGVzdHMgd2hldGhlciBGVU5D
IGV4aXN0cywgc2V0dGluZyB0aGUgY2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5Ci1hY19m
bl9jX2NoZWNrX2Z1bmMgKCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xp
bmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHsk
MytzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVs
c2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k
IGNvbmZkZWZzLmguICAqLwotLyogRGVmaW5lICQyIHRvIGFuIGlubm9jdW91cyB2YXJpYW50LCBp
biBjYXNlIDxsaW1pdHMuaD4gZGVjbGFyZXMgJDIuCi0gICBGb3IgZXhhbXBsZSwgSFAtVVggMTFp
IDxsaW1pdHMuaD4gZGVjbGFyZXMgZ2V0dGltZW9mZGF5LiAgKi8KLSNkZWZpbmUgJDIgaW5ub2N1
b3VzXyQyCi0KLS8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhv
cGVmdWxseSBmZXcgcHJvdG90eXBlcywKLSAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFy
ICQyICgpOyBiZWxvdy4KLSAgICBQcmVmZXIgPGxpbWl0cy5oPiB0byA8YXNzZXJ0Lmg+IGlmIF9f
U1REQ19fIGlzIGRlZmluZWQsIHNpbmNlCi0gICAgPGxpbWl0cy5oPiBleGlzdHMgZXZlbiBvbiBm
cmVlc3RhbmRpbmcgY29tcGlsZXJzLiAgKi8KLQotI2lmZGVmIF9fU1REQ19fCi0jIGluY2x1ZGUg
PGxpbWl0cy5oPgotI2Vsc2UKLSMgaW5jbHVkZSA8YXNzZXJ0Lmg+Ci0jZW5kaWYKLQotI3VuZGVm
ICQyCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu
IGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0
eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUg
d291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0j
ZW5kaWYKLWNoYXIgJDIgKCk7Ci0vKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9y
IGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzCi0gICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBF
Tk9TWVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQKLSAgICBzb21ldGhpbmcg
c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8KLSNp
ZiBkZWZpbmVkIF9fc3R1Yl8kMiB8fCBkZWZpbmVkIF9fc3R1Yl9fXyQyCi1jaG9rZSBtZQotI2Vu
ZGlmCi0KLWludAotbWFpbiAoKQotewotcmV0dXJuICQyICgpOwotICA7Ci0gIHJldHVybiAwOwot
fQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGV2YWwg
IiQzPXllcyIKLWVsc2UKLSAgZXZhbCAiJDM9bm8iCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0
LiRhY19leHQKLWZpCi1ldmFsIGFjX3Jlcz1cJCQzCi0JICAgICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19lY2hvICIk
YWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVu
b19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KLQotfSAjIGFj
X2ZuX2NfY2hlY2tfZnVuYwotCi0jIGFjX2ZuX2NfY2hlY2tfdHlwZSBMSU5FTk8gVFlQRSBWQVIg
SU5DTFVERVMKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQot
IyBUZXN0cyB3aGV0aGVyIFRZUEUgZXhpc3RzIGFmdGVyIGhhdmluZyBpbmNsdWRlZCBJTkNMVURF
Uywgc2V0dGluZyBjYWNoZQotIyB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCi1hY19mbl9jX2No
ZWNrX3R5cGUgKCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19z
dGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHskMytzZXR9
XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAg
ZXZhbCAiJDM9bm8iCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ0Ci1pbnQKLW1haW4gKCkKLXsKLWlmIChzaXpl
b2YgKCQyKSkKLQkgcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJDQKLWlu
dAotbWFpbiAoKQotewotaWYgKHNpemVvZiAoKCQyKSkpCi0JICAgIHJldHVybiAwOwotICA7Ci0g
IHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Ci0KLWVsc2UKLSAgZXZhbCAiJDM9eWVzIgotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLWV2
YWwgYWNfcmVzPVwkJDMKLQkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQot
ICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYg
eyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQotCi19ICMgYWNfZm5fY19jaGVja190eXBl
Ci0KLSMgYWNfZm5fY19maW5kX2ludFhfdCBMSU5FTk8gQklUUyBWQVIKLSMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgRmluZHMgYSBzaWduZWQgaW50ZWdlciB0eXBlIHdp
dGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIKLSMgYWNjb3JkaW5nbHku
Ci1hY19mbl9jX2ZpbmRfaW50WF90ICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEi
fSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW50JDJf
dCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgaW50JDJfdC4uLiAiID4mNjsgfQotaWYg
ZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgotZWxzZQotICBldmFsICIkMz1ubyIKLSAgICAgIyBPcmRlciBpcyBpbXBv
cnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCi0g
ICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCi0gICAgIGZvciBh
Y190eXBlIGluIGludCQyX3QgJ2ludCcgJ2xvbmcgaW50JyBcCi0JICdsb25nIGxvbmcgaW50JyAn
c2hvcnQgaW50JyAnc2lnbmVkIGNoYXInOyBkbwotICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNs
dWRlc19kZWZhdWx0Ci0JICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKLWludAotbWFpbiAo
KQotewotc3RhdGljIGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoMCA8ICgkYWNfdHlwZSkgKCgo
KCgkYWNfdHlwZSkgMSA8PCBOKSA8PCBOKSAtIDEpICogMiArIDEpKV07Ci10ZXN0X2FycmF5IFsw
XSA9IDAKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0
Ci0JICAgICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKLWludAotbWFpbiAoKQotewotc3Rh
dGljIGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAx
IDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkKLQkJIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBl
KSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMikpXTsKLXRlc3RfYXJyYXkgWzBdID0gMAotCi0g
IDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKLQotZWxzZQotICBjYXNlICRhY190eXBlIGluICMoCi0gIGludCQyX3QpIDoK
LSAgICBldmFsICIkMz15ZXMiIDs7ICMoCi0gICopIDoKLSAgICBldmFsICIkMz1cJGFjX3R5cGUi
IDs7Ci1lc2FjCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQz
IlwiID0geCJubyI7IHRoZW4gOgotCi1lbHNlCi0gIGJyZWFrCi1maQotICAgICBkb25lCi1maQot
ZXZhbCBhY19yZXM9XCQkMwotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9
Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAm
JiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2ZpbmRfaW50
WF90Ci0KLSMgYWNfZm5fY19jaGVja19tZW1iZXIgTElORU5PIEFHR1IgTUVNQkVSIFZBUiBJTkNM
VURFUwotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tCi0jIFRyaWVzIHRvIGZpbmQgaWYgdGhlIGZpZWxkIE1FTUJFUiBleGlzdHMgaW4gdHlwZSBB
R0dSLCBhZnRlciBpbmNsdWRpbmcKLSMgSU5DTFVERVMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUg
VkFSIGFjY29yZGluZ2x5LgotYWNfZm5fY19jaGVja19tZW1iZXIgKCkKLXsKLSAgYXNfbGluZW5v
PSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xp
bmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkMi4kMyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuJDMuLi4g
IiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHskNCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJDUKLWludAot
bWFpbiAoKQotewotc3RhdGljICQyIGFjX2FnZ3I7Ci1pZiAoYWNfYWdnci4kMykKLXJldHVybiAw
OwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIk
TElORU5PIjsgdGhlbiA6Ci0gIGV2YWwgIiQ0PXllcyIKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJDUK
LWludAotbWFpbiAoKQotewotc3RhdGljICQyIGFjX2FnZ3I7Ci1pZiAoc2l6ZW9mIGFjX2FnZ3Iu
JDMpCi1yZXR1cm4gMDsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBldmFsICIkND15ZXMiCi1lbHNlCi0gIGV2
YWwgIiQ0PW5vIgotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLWV2YWwgYWNfcmVzPVwkJDQKLQkgICAg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19y
ZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFsICRhc19saW5lbm9fc3Rh
Y2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBh
c19saW5lbm87fQotCi19ICMgYWNfZm5fY19jaGVja19tZW1iZXIKLQotIyBhY19mbl9jX2ZpbmRf
dWludFhfdCBMSU5FTk8gQklUUyBWQVIKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCi0jIEZpbmRzIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRoIEJJVFMs
IHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSCi0jIGFjY29yZGluZ2x5LgotYWNfZm5fY19maW5k
X3VpbnRYX3QgKCkKLXsKLSAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19z
dGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawotICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1Ci0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgdWludCQyX3QuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3Qg
XCJcJHskMytzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKLWVsc2UKLSAgZXZhbCAiJDM9bm8iCi0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2
ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgotICAgICAjIHRoYW4g
aGFsZiBvZiB0aGUgZXhwZWN0ZWQgdGFyZ2V0IHdpZHRoLgotICAgICBmb3IgYWNfdHlwZSBpbiB1
aW50JDJfdCAndW5zaWduZWQgaW50JyAndW5zaWduZWQgbG9uZyBpbnQnIFwKLQkgJ3Vuc2lnbmVk
IGxvbmcgbG9uZyBpbnQnICd1bnNpZ25lZCBzaG9ydCBpbnQnICd1bnNpZ25lZCBjaGFyJzsgZG8K
LSAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBl
bmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAotaW50Ci1tYWluICgpCi17
Ci1zdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgoKCRhY190eXBlKSAtMSA+PiAoJDIg
LyAyIC0gMSkpID4+ICgkMiAvIDIgLSAxKSA9PSAzKV07Ci10ZXN0X2FycmF5IFswXSA9IDAKLQot
ICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Ci0gIGNhc2UgJGFjX3R5cGUgaW4gIygKLSAgdWludCQyX3QpIDoKLSAgICBl
dmFsICIkMz15ZXMiIDs7ICMoCi0gICopIDoKLSAgICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Ci1l
c2FjCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25m
dGVzdC4kYWNfZXh0Ci0gICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQzIlwiID0geCJubyI7IHRo
ZW4gOgotCi1lbHNlCi0gIGJyZWFrCi1maQotICAgICBkb25lCi1maQotZXZhbCBhY19yZXM9XCQk
MwotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Ci0gIGV2YWwgJGFzX2xp
bmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07
IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2ZpbmRfdWludFhfdAogY2F0ID5jb25m
aWcubG9nIDw8X0FDRU9GCiBUaGlzIGZpbGUgY29udGFpbnMgYW55IG1lc3NhZ2VzIHByb2R1Y2Vk
IGJ5IGNvbXBpbGVycyB3aGlsZQogcnVubmluZyBjb25maWd1cmUsIHRvIGFpZCBkZWJ1Z2dpbmcg
aWYgY29uZmlndXJlIG1ha2VzIGEgbWlzdGFrZS4KQEAgLTIzODYsMTEgKzIwNjMsNiBAQCAkYXNf
ZWNobyAiJGFzX21lOiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KICAgPiRjYWNo
ZV9maWxlCiBmaQogCi1hc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvdGltZS5oIgot
YXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCi1hc19mbl9hcHBlbmQgYWNf
ZnVuY19saXN0ICIgYWxhcm0iCi1hc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzdGRsaWIu
aCIKLWFzX2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgogIyBDaGVjayB0
aGF0IHRoZSBwcmVjaW91cyB2YXJpYWJsZXMgc2F2ZWQgaW4gdGhlIGNhY2hlIGhhdmUga2VwdCB0
aGUgc2FtZQogIyB2YWx1ZS4KIGFjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQpAQCAtMjUwOCwxNzMw
ICsyMTgwLDQwIEBAIEFQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBpbnN0ZWFkIHdoZW4g
cG9zc2libGUuIiA+JjI7fQogCiBmaQogCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFH
UycKLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0
ID4mNScKLWFjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxB
R1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9
JGFjX2N2X2NfY29tcGlsZXJfZ251Ci1pZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVu
Ci0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1nY2MiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9v
bF9wcmVmaXh9Z2NjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlm
IHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2Nj
IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAg
ZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0k
YXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotCi1maQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2df
Q0MiOyB0aGVuCi0gIGFjX2N0X0NDPSRDQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
ImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
Z2NjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9
IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRl
c3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0ND
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0k
YXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
ImdjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25l
Ci0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJv
Z19hY19jdF9DQwotaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKLSRhc19l
Y2hvICIkYWNfY3RfQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZp
Ci0KLSAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIKLSAgZWxzZQot
ICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBDQz0kYWNfY3Rf
Q0MKLSAgZmkKLWVsc2UKLSAgQ0M9IiRhY19jdl9wcm9nX0NDIgotZmkKLQotaWYgdGVzdCAteiAi
JENDIjsgdGhlbgotICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
LSAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9v
bF9wcmVmaXh9Y2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIK
LSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRv
bmUKLUlGUz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVz
dCAtbiAiJENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFz
X2VjaG8gIm5vIiA+JjY7IH0KLWZpCi0KLQotICBmaQotZmkKLWlmIHRlc3QgLXogIiRDQyI7IHRo
ZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9n
X0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotICBhY19w
cm9nX3JlamVjdGVkPW5vCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1m
b3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KLSAgICBpZiB0ZXN0ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA9ICIvdXNy
L3VjYi9jYyI7IHRoZW4KLSAgICAgICBhY19wcm9nX3JlamVjdGVkPXllcwotICAgICAgIGNvbnRp
bnVlCi0gICAgIGZpCi0gICAgYWNfY3ZfcHJvZ19DQz0iY2MiCi0gICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZT
Ci0KLWlmIHRlc3QgJGFjX3Byb2dfcmVqZWN0ZWQgPSB5ZXM7IHRoZW4KLSAgIyBXZSBmb3VuZCBh
IGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0LgotICBzZXQg
ZHVtbXkgJGFjX2N2X3Byb2dfQ0MKLSAgc2hpZnQKLSAgaWYgdGVzdCAkIyAhPSAwOyB0aGVuCi0g
ICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVudCBjb21waWxlciBmcm9tIHRoZSBib2d1cyBvbmUuCi0g
ICAgIyBIb3dldmVyLCBpdCBoYXMgdGhlIHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxs
IGJlIGNob3NlbgotICAgICMgZmlyc3QgaWYgd2Ugc2V0IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1l
OyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgotICAgIHNoaWZ0Ci0gICAgYWNfY3ZfcHJvZ19DQz0i
JGFzX2Rpci8kYWNfd29yZCR7MSsnICd9JEAiCi0gIGZpCi1maQotZmkKLWZpCi1DQz0kYWNfY3Zf
cHJvZ19DQwotaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsg
fQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCi0KLQotZmkKLWlmIHRlc3QgLXog
IiRDQyI7IHRoZW4KLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICBmb3Ig
YWNfcHJvZyBpbiBjbC5leGUKLSAgZG8KLSAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
IiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KLXNldCBkdW1teSAkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgot
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFj
X2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNl
Ci1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQ
QVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19j
dl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIKLSAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMK
LQotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUK
LSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZp
Ci0KLQotICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKLSAgZG9uZQotZmkKLWlmIHRlc3QgLXog
IiRDQyI7IHRoZW4KLSAgYWNfY3RfQ0M9JENDCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotZG8K
LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJGFjX3Byb2c7IGFjX3dvcmQ9JDIK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X0ND
IjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX3Byb2ciCi0gICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCi0KLWZpCi1maQotYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MK
LWlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0
X0NDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0KLSAgdGVz
dCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhawotZG9uZQotCi0gIGlmIHRlc3QgIngkYWNfY3RfQ0Mi
ID0geDsgdGhlbgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6
JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3Mg
dG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJu
ZWQ9eWVzIDs7Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0gIGZpCi1maQotCi1maQotCi0KLXRl
c3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBp
bGVyIGZvdW5kIGluIFwkUEFUSAotU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIg
IiRMSU5FTk8iIDUgOyB9Ci0KLSMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBj
b21waWxlci4KLSRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQotc2V0IFggJGFjX2NvbXBpbGUKLWFjX2NvbXBp
bGVyPSQyCi1mb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCi0g
IHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKLWNhc2UgIigoJGFjX3Ry
eSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICop
IGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5
X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5j
b25mdGVzdC5lcnIKLSAgYWNfc3RhdHVzPSQ/Ci0gIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0
aGVuCi0gICAgc2VkICcxMGFcCi0uLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4u
Ci0gICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCi0gICAgY2F0IGNvbmZ0
ZXN0LmVyMSA+JjUKLSAgZmkKLSAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgotICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQotZG9uZQotCi1jYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAot
bWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWFjX2NsZWFuX2ZpbGVz
X3NhdmU9JGFjX2NsZWFuX2ZpbGVzCi1hY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGEu
b3V0IGEub3V0LmRTWU0gYS5leGUgYi5vdXQiCi0jIFRyeSB0byBjcmVhdGUgYW4gZXhlY3V0YWJs
ZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNyZWdhcmQgYS5vdXQuCi0jIEl0IHdpbGwgaGVscCB1cyBk
aWFnbm9zZSBicm9rZW4gY29tcGlsZXJzLCBhbmQgZmluZGluZyBvdXQgYW4gaW50dWl0aW9uCi0j
IG9mIGV4ZWV4dC4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3JrcyIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzLi4uICIgPiY2OyB9Ci1hY19saW5rX2Rl
ZmF1bHQ9YCRhc19lY2hvICIkYWNfbGluayIgfCBzZWQgJ3MvIC1vICpjb25mdGVzdFteIF0qLy8n
YAotCi0jIFRoZSBwb3NzaWJsZSBvdXRwdXQgZmlsZXM6Ci1hY19maWxlcz0iYS5vdXQgY29uZnRl
c3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFfb3V0LmV4ZSBiLm91dCBjb25mdGVzdC4qIgotCi1hY19y
bWZpbGVzPQotZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzCi1kbwotICBjYXNlICRhY19maWxlIGlu
Ci0gICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0g
fCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7
OwotICAgICogKSBhY19ybWZpbGVzPSIkYWNfcm1maWxlcyAkYWNfZmlsZSI7OwotICBlc2FjCi1k
b25lCi1ybSAtZiAkYWNfcm1maWxlcwotCi1pZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19kZWZhdWx0
IgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hv
PVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1lc2FjCi1ldmFsIGFjX3Ry
eV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgot
JGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIkYWNfbGlua19kZWZhdWx0
IikgMj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07
IHRoZW4gOgotICAjIEF1dG9jb25mLTIuMTMgY291bGQgc2V0IHRoZSBhY19jdl9leGVleHQgdmFy
aWFibGUgdG8gYG5vJy4KLSMgU28gaWdub3JlIGEgdmFsdWUgb2YgYG5vJywgb3RoZXJ3aXNlIHRo
aXMgd291bGQgbGVhZCB0byBgRVhFRVhUID0gbm8nCi0jIGluIGEgTWFrZWZpbGUuICBXZSBzaG91
bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4ZWV4dCBpZiBpdCB3YXMgY2FjaGVkLAotIyBzbyB0aGF0
IHRoZSB1c2VyIGNhbiBzaG9ydC1jaXJjdWl0IHRoaXMgdGVzdCBmb3IgY29tcGlsZXJzIHVua25v
d24gdG8KLSMgQXV0b2NvbmYuCi1mb3IgYWNfZmlsZSBpbiAkYWNfZmlsZXMgJycKLWRvCi0gIHRl
c3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQotICBjYXNlICRhY19maWxlIGluCi0gICAgKi4k
YWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwg
Ki5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKQotCTs7Ci0gICAg
W2FiXS5vdXQgKQotCSMgV2UgZm91bmQgdGhlIGRlZmF1bHQgZXhlY3V0YWJsZSwgYnV0IGV4ZWV4
dD0nJyBpcyBtb3N0Ci0JIyBjZXJ0YWlubHkgcmlnaHQuCi0JYnJlYWs7OwotICAgICouKiApCi0J
aWYgdGVzdCAiJHthY19jdl9leGVleHQrc2V0fSIgPSBzZXQgJiYgdGVzdCAiJGFjX2N2X2V4ZWV4
dCIgIT0gbm87Ci0JdGhlbiA6OyBlbHNlCi0JICAgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmls
ZSIgOiAnW14uXSpcKFwuLipcKSdgCi0JZmkKLQkjIFdlIHNldCBhY19jdl9leGVleHQgaGVyZSBi
ZWNhdXNlIHRoZSBsYXRlciB0ZXN0IGZvciBpdCBpcyBub3QKLQkjIHNhZmU6IGNyb3NzIGNvbXBp
bGVycyBtYXkgbm90IGFkZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKLQkjIGFyZ3VtZW50
LCBzbyB3ZSBtYXkgbmVlZCB0byBrbm93IGl0IGF0IHRoYXQgcG9pbnQgYWxyZWFkeS4KLQkjIEV2
ZW4gaWYgdGhpcyBzZWN0aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YK
LQkjIGFjdHVhbGx5IHdvcmtpbmcuCi0JYnJlYWs7OwotICAgICogKQotCWJyZWFrOzsKLSAgZXNh
YwotZG9uZQotdGVzdCAiJGFjX2N2X2V4ZWV4dCIgPSBubyAmJiBhY19jdl9leGVleHQ9Ci0KLWVs
c2UKLSAgYWNfZmlsZT0nJwotZmkKLWlmIHRlc3QgLXogIiRhY19maWxlIjsgdGhlbiA6Ci0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0k
YXNfZWNobyAibm8iID4mNjsgfQotJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2Fz
OiIgPiY1Ci1zZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1Ci0KLXsgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5f
ZXJyb3IgNzcgIkMgY29tcGlsZXIgY2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcwotU2VlIFxgY29u
ZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci1lbHNlCi0gIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFz
X2VjaG8gInllcyIgPiY2OyB9Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUi
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQg
ZmlsZSBuYW1lLi4uICIgPiY2OyB9Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQotJGFzX2VjaG8gIiRhY19maWxlIiA+JjY7IH0K
LWFjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0Ci0KLXJtIC1mIC1yIGEub3V0IGEub3V0LmRTWU0gYS5l
eGUgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGIub3V0Ci1hY19jbGVhbl9maWxlcz0kYWNfY2xlYW5f
ZmlsZXNfc2F2ZQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMuLi4gIiA+JjY7IH0KLWlmIHsgeyBhY190cnk9IiRh
Y19saW5rIgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3Ry
eV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1lc2FjCi1ldmFs
IGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNo
b1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIkYWNfbGluayIp
IDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0
aGVuIDoKLSAgIyBJZiBib3RoIGBjb25mdGVzdC5leGUnIGFuZCBgY29uZnRlc3QnIGFyZSBgcHJl
c2VudCcgKHdlbGwsIG9ic2VydmFibGUpCi0jIGNhdGNoIGBjb25mdGVzdC5leGUnLiAgRm9yIGlu
c3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3QnIHdpbGwKLSMgd29yayBwcm9wZXJseSAo
aS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScpLCB3aGlsZSBpdCB3b24ndCB3aXRoCi0jIGBy
bScuCi1mb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUgY29uZnRlc3QgY29uZnRlc3QuKjsgZG8K
LSAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlCi0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAg
ICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICou
YmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7Ci0g
ICAgKi4qICkgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdg
Ci0JICBicmVhazs7Ci0gICAgKiApIGJyZWFrOzsKLSAgZXNhYwotZG9uZQotZWxzZQotICB7IHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30K
LWFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0YWJsZXM6IGNh
bm5vdCBjb21waWxlIGFuZCBsaW5rCi1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxz
IiAiJExJTkVOTyIgNSA7IH0KLWZpCi1ybSAtZiBjb25mdGVzdCBjb25mdGVzdCRhY19jdl9leGVl
eHQKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfZXhlZXh0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfZXhlZXh0IiA+JjY7IH0KLQotcm0gLWYg
Y29uZnRlc3QuJGFjX2V4dAotRVhFRVhUPSRhY19jdl9leGVleHQKLWFjX2V4ZWV4dD0kRVhFRVhU
Ci1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u
ZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3RkaW8uaD4KLWludAotbWFpbiAoKQotewotRklMRSAq
ZiA9IGZvcGVuICgiY29uZnRlc3Qub3V0IiwgInciKTsKLSByZXR1cm4gZmVycm9yIChmKSB8fCBm
Y2xvc2UgKGYpICE9IDA7Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotYWNfY2xlYW5f
ZmlsZXM9IiRhY19jbGVhbl9maWxlcyBjb25mdGVzdC5vdXQiCi0jIENoZWNrIHRoYXQgdGhlIGNv
bXBpbGVyIHByb2R1Y2VzIGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBub3QsIGVpdGhlcgot
IyB0aGUgY29tcGlsZXIgaXMgYnJva2VuLCBvciB3ZSBjcm9zcyBjb21waWxlLgoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBj
cm9zcyBjb21waWxpbmciID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUg
Y3Jvc3MgY29tcGlsaW5nLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiAh
PSB5ZXM7IHRoZW4KLSAgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCi1jYXNlICIoKCRhY190cnkiIGlu
Ci0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190
cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hv
IjsgfSA+JjUKLSAgKGV2YWwgIiRhY19saW5rIikgMj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1
Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KLSAgaWYgeyBhY190cnk9Jy4vY29uZnRlc3QkYWNf
Y3ZfZXhlZXh0JwotICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpc
XCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1l
c2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRh
Y190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIk
YWNfdHJ5IikgMj4mNQotICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH07IH07IHRoZW4KLSAgICBjcm9zc19jb21waWxpbmc9bm8KLSAgZWxzZQotICAgIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0gbWF5YmU7IHRoZW4KLQljcm9zc19jb21waWxpbmc9eWVz
Ci0gICAgZWxzZQotCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBl
cnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxg
JGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBydW4gQyBjb21waWxlZCBw
cm9ncmFtcy4KLUlmIHlvdSBtZWFudCB0byBjcm9zcyBjb21waWxlLCB1c2UgXGAtLWhvc3QnLgot
U2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Ci0gICAg
ZmkKLSAgZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGNyb3NzX2NvbXBpbGluZyIgPiY1Ci0kYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIg
PiY2OyB9Ci0KLXJtIC1mIGNvbmZ0ZXN0LiRhY19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNv
bmZ0ZXN0Lm91dAotYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBv
YmplY3QgZmlsZXMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmpl
Y3QgZmlsZXMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfb2JqZXh0K3NldH0iID0gc2V0
OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAq
LwotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1ybSAt
ZiBjb25mdGVzdC5vIGNvbmZ0ZXN0Lm9iagotaWYgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGUiCi1j
YXNlICIoKCRhY190cnkiIGluCi0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7OwotICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2Vj
aG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNf
ZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKLSAgKGV2YWwgIiRhY19jb21waWxlIikgMj4mNQot
ICBhY19zdGF0dXM9JD8KLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
XCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgot
ICBmb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5vIGNvbmZ0ZXN0Lm9iaiBjb25mdGVzdC4qOyBkbwot
ICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWU7Ci0gIGNhc2UgJGFjX2ZpbGUgaW4KLSAg
ICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICou
YmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gKSA7OwotICAgICopIGFjX2N2X29i
amV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJy4qXC5cKC4qXCknYAotICAgICAgIGJyZWFrOzsKLSAg
ZXNhYwotZG9uZQotZWxzZQotICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6
IiA+JjUKLXNlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKLQoteyB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1
Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9l
cnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIG9iamVjdCBmaWxlczogY2Fubm90IGNv
bXBpbGUKLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsg
fQotZmkKLXJtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
b2JqZXh0IiA+JjUKLSRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KLU9CSkVYVD0kYWNf
Y3Zfb2JqZXh0Ci1hY19vYmpleHQ9JE9CSkVYVAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29t
cGlsZXIiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhl
IEdOVSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJf
Z251K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVs
c2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k
IGNvbmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkKLXsKLSNpZm5kZWYgX19HTlVDX18KLSAg
ICAgICBjaG9rZSBtZQotI2VuZGlmCi0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jb21waWxlcl9nbnU9
eWVzCi1lbHNlCi0gIGFjX2NvbXBpbGVyX2dudT1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotYWNfY3ZfY19jb21waWxl
cl9nbnU9JGFjX2NvbXBpbGVyX2dudQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY1Ci0kYXNfZWNo
byAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KLWlmIHRlc3QgJGFjX2NvbXBpbGVyX2du
dSA9IHllczsgdGhlbgotICBHQ0M9eWVzCi1lbHNlCi0gIEdDQz0KLWZpCi1hY190ZXN0X0NGTEFH
Uz0ke0NGTEFHUytzZXR9Ci1hY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWci
ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZy4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9
JGFjX2Nfd2Vycm9yX2ZsYWcKLSAgIGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCi0gICBhY19jdl9wcm9n
X2NjX2c9bm8KLSAgIENGTEFHUz0iLWciCi0gICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQot
ewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUg
IiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfcHJvZ19jY19nPXllcwotZWxzZQotICBDRkxBR1M9
IiIKLSAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4g
MDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgot
Ci1lbHNlCi0gIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotCSBDRkxB
R1M9Ii1nIgotCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
LSAgYWNfY3ZfcHJvZ19jY19nPXllcwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotICAgYWNf
Y193ZXJyb3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCi1maQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQot
JGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQotaWYgdGVzdCAiJGFjX3Rlc3RfQ0ZM
QUdTIiA9IHNldDsgdGhlbgotICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCi1lbGlmIHRlc3QgJGFj
X2N2X3Byb2dfY2NfZyA9IHllczsgdGhlbgotICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgot
ICAgIENGTEFHUz0iLWcgLU8yIgotICBlbHNlCi0gICAgQ0ZMQUdTPSItZyIKLSAgZmkKLWVsc2UK
LSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KLSAgICBDRkxBR1M9Ii1PMiIKLSAgZWxzZQot
ICAgIENGTEFHUz0KLSAgZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKLSRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfYzg5K3NldH0iID0gc2V0OyB0aGVuIDoK
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY3ZfcHJvZ19jY19jODk9
bm8KLWFjX3NhdmVfQ0M9JENDCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3RkYXJnLmg+Ci0jaW5j
bHVkZSA8c3RkaW8uaD4KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KLSNpbmNsdWRlIDxzeXMvc3Rh
dC5oPgotLyogTW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1Mg
NS43J3Mgc3JjL2NvbmYuc2guICAqLwotc3RydWN0IGJ1ZiB7IGludCB4OyB9OwotRklMRSAqICgq
cmNzb3BlbikgKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KTsKLXN0YXRpYyBjaGFy
ICplIChwLCBpKQotICAgICBjaGFyICoqcDsKLSAgICAgaW50IGk7Ci17Ci0gIHJldHVybiBwW2ld
OwotfQotc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoq
cCwgLi4uKQotewotICBjaGFyICpzOwotICB2YV9saXN0IHY7Ci0gIHZhX3N0YXJ0ICh2LHApOwot
ICBzID0gZyAocCwgdmFfYXJnICh2LGludCkpOwotICB2YV9lbmQgKHYpOwotICByZXR1cm4gczsK
LX0KLQotLyogT1NGIDQuMCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5
IGRlZmF1bHQuICBJdCBoYXMKLSAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQg
bm90ICdceEhIJyBoZXggY2hhcmFjdGVyIGNvbnN0YW50cy4KLSAgIFRoZXNlIGRvbid0IHByb3Zv
a2UgYW4gZXJyb3IgdW5mb3J0dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAot
ICAgYXMgJ3gnLiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlz
IGFkZGVkIHRvIGdldAotICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4
JyBhbHdheXMgY29tZXMgb3V0IHRydWUsIGZvciBhbgotICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4g
IEl0J3MgbmVjZXNzYXJ5IHRvIHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCi0gICB0
aGF0J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICovCi1pbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAn
ID09IDAgPyAxIDogLTFdOwotCi0vKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkg
ZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKLSAgIGluc2lkZSBzdHJp
bmdzIGFuZCBjaGFyYWN0ZXIgY29uc3RhbnRzLiAgKi8KLSNkZWZpbmUgRk9PKHgpICd4JwotaW50
IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07Ci0KLWludCB0ZXN0IChpbnQg
aSwgZG91YmxlIHgpOwotc3RydWN0IHMxIHtpbnQgKCpmKSAoaW50IGEpO307Ci1zdHJ1Y3QgczIg
e2ludCAoKmYpIChkb3VibGUgYSk7fTsKLWludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklM
RSAqKCopKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOwotaW50
IGFyZ2M7Ci1jaGFyICoqYXJndjsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGYgKGUsIGFyZ3Ys
IDApICE9IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOwotICA7Ci0gIHJl
dHVybiAwOwotfQotX0FDRU9GCi1mb3IgYWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFs
YW5nbHZsPWFuc2kgLXN0ZCBcCi0JLUFlICItQWEgLURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VY
VEVOU0lPTlNfXyIKLWRvCi0gIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgotICBpZiBhY19mbl9j
X3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19h
cmcKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0Ci0gIHRl
c3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCi1kb25lCi1ybSAtZiBj
b25mdGVzdC4kYWNfZXh0Ci1DQz0kYWNfc2F2ZV9DQwotCi1maQotIyBBQ19DQUNIRV9WQUwKLWNh
c2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCi0gIHgpCi0gICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vbmUgbmVlZGVkIiA+JjUKLSRhc19lY2hv
ICJub25lIG5lZWRlZCIgPiY2OyB9IDs7Ci0gIHhubykKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdW5zdXBwb3J0ZWQiID4mNQotJGFzX2VjaG8g
InVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKLSAgKikKLSAgICBDQz0iJENDICRhY19jdl9wcm9nX2Nj
X2M4OSIKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODki
ID4mNjsgfSA7OwotZXNhYwotaWYgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0
aGVuIDoKLQotZmkKLQotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21w
aWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19s
aW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdT
IGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2Nv
bXBpbGVyX2dudQotCi0KLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29t
cGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNf
bGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFH
UyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19j
b21waWxlcl9nbnUKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IuLi4gIiA+JjY7IH0KLSMgT24gU3Vu
cywgc29tZXRpbWVzICRDUFAgbmFtZXMgYSBkaXJlY3RvcnkuCi1pZiB0ZXN0IC1uICIkQ1BQIiAm
JiB0ZXN0IC1kICIkQ1BQIjsgdGhlbgotICBDUFA9Ci1maQotaWYgdGVzdCAteiAiJENQUCI7IHRo
ZW4KLSAgaWYgdGVzdCAiJHthY19jdl9wcm9nX0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gICAgICAjIERvdWJsZSBxdW90ZXMgYmVj
YXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhwYW5kZWQKLSAgICBmb3IgQ1BQIGluICIkQ0MgLUUiICIk
Q0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIgIi9saWIvY3BwIgotICAgIGRvCi0gICAgICBhY19wcmVw
cm9jX29rPWZhbHNlCi1mb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKLWRvCi0g
ICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcg
Z2xpYmMKLSAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCi0gICMgUHJlZmVy
IDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQot
ICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KLSAg
IyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidz
IHBhcnNlciwKLSAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVy
ZSB0byBjYXRjaCB0aGlzIGNhc2UuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpZmRlZiBfX1NURENfXwotIyBp
bmNsdWRlIDxsaW1pdHMuaD4KLSNlbHNlCi0jIGluY2x1ZGUgPGFzc2VydC5oPgotI2VuZGlmCi0J
CSAgICAgU3ludGF4IGVycm9yCi1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7
IHRoZW4gOgotCi1lbHNlCi0gICMgQnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KLWNvbnRp
bnVlCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAot
Ci0gICMgT0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlz
dGVudCBoZWFkZXJzCi0gICMgY2FuIGJlIGRldGVjdGVkIGFuZCBob3cuCi0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
LSNpbmNsdWRlIDxhY19ub25leGlzdGVudC5oPgotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jcHAg
IiRMSU5FTk8iOyB0aGVuIDoKLSAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4K
LWNvbnRpbnVlCi1lbHNlCi0gICMgUGFzc2VzIGJvdGggdGVzdHMuCi1hY19wcmVwcm9jX29rPToK
LWJyZWFrCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4
dAotCi1kb25lCi0jIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xl
YW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KLXJtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19leHQKLWlmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKLSAgYnJlYWsKLWZpCi0K
LSAgICBkb25lCi0gICAgYWNfY3ZfcHJvZ19DUFA9JENQUAotCi1maQotICBDUFA9JGFjX2N2X3By
b2dfQ1BQCi1lbHNlCi0gIGFjX2N2X3Byb2dfQ1BQPSRDUFAKLWZpCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENQUCIgPiY1Ci0kYXNfZWNobyAiJENQ
UCIgPiY2OyB9Ci1hY19wcmVwcm9jX29rPWZhbHNlCi1mb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxh
ZyBpbiAnJyB5ZXMKLWRvCi0gICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdj
Yywgc28gY29uZmlndXJpbmcgZ2xpYmMKLSAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIg
d29ya3MuCi0gICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBp
cyBkZWZpbmVkLCBzaW5jZQotICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5k
aW5nIGNvbXBpbGVycy4KLSAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJv
dWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKLSAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5
bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCi0gIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNp
ZmRlZiBfX1NURENfXwotIyBpbmNsdWRlIDxsaW1pdHMuaD4KLSNlbHNlCi0jIGluY2x1ZGUgPGFz
c2VydC5oPgotI2VuZGlmCi0JCSAgICAgU3ludGF4IGVycm9yCi1fQUNFT0YKLWlmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgotCi1lbHNlCi0gICMgQnJva2VuOiBmYWlscyBvbiB2
YWxpZCBpbnB1dC4KLWNvbnRpbnVlCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0Lmkg
Y29uZnRlc3QuJGFjX2V4dAotCi0gICMgT0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hl
Y2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCi0gICMgY2FuIGJlIGRldGVjdGVkIGFuZCBo
b3cuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxhY19ub25leGlzdGVudC5oPgotX0FDRU9GCi1p
ZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKLSAgIyBCcm9rZW46IHN1Y2Nlc3Mg
b24gaW52YWxpZCBpbnB1dC4KLWNvbnRpbnVlCi1lbHNlCi0gICMgUGFzc2VzIGJvdGggdGVzdHMu
Ci1hY19wcmVwcm9jX29rPToKLWJyZWFrCi1maQotcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuJGFjX2V4dAotCi1kb25lCi0jIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BS
RVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KLXJtIC1mIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKLWlmICRhY19wcmVwcm9jX29rOyB0aGVu
IDoKLQotZWxzZQotICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiYyO30KLWFzX2ZuX2Vycm9yICQ/ICJDIHByZXByb2Nlc3NvciBcIiRDUFBc
IiBmYWlscyBzYW5pdHkgY2hlY2sKLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMi
ICIkTElORU5PIiA1IDsgfQotZmkKLQotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1Mn
Ci1hY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+
JjUnCi1hY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdT
ICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRh
Y19jdl9jX2NvbXBpbGVyX2dudQotCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1l
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxp
bmVzIGFuZCAtZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0dSRVArc2V0fSIg
PSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0
ZXN0IC16ICIkR1JFUCI7IHRoZW4KLSAgYWNfcGF0aF9HUkVQX2ZvdW5kPWZhbHNlCi0gICMgTG9v
cCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1M
SVNUCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIg
aW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCi1kbwotICBJRlM9JGFzX3NhdmVf
SUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX3Byb2cgaW4g
Z3JlcCBnZ3JlcDsgZG8KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KLSAgICAgIGFjX3BhdGhfR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19l
eGVjX2V4dCIKLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfR1JFUCIgJiYgJGFzX3Rlc3RfeCAi
JGFjX3BhdGhfR1JFUCI7IH0gfHwgY29udGludWUKLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0dS
RVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KLSAgIyBDaGVjayBmb3IgR05VICRhY19w
YXRoX0dSRVAKLWNhc2UgYCIkYWNfcGF0aF9HUkVQIiAtLXZlcnNpb24gMj4mMWAgaW4KLSpHTlUq
KQotICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiIGFjX3BhdGhfR1JFUF9mb3VuZD06
OzsKLSopCi0gIGFjX2NvdW50PTAKLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3Qu
aW4iCi0gIHdoaWxlIDoKLSAgZG8KLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4i
ID4iY29uZnRlc3QudG1wIgotICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKLSAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKLSAgICAkYXNfZWNobyAnR1JFUCcgPj4g
ImNvbmZ0ZXN0Lm5sIgotICAgICIkYWNfcGF0aF9HUkVQIiAtZSAnR1JFUCQnIC1lICctKGNhbm5v
dCBtYXRjaCktJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8
IGJyZWFrCi0gICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwg
Mj4mMSB8fCBicmVhawotICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9
JGFzX3ZhbAotICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfR1JFUF9tYXgtMH07
IHRoZW4KLSAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcg
Zm9yIGEgYmV0dGVyIG9uZQotICAgICAgYWNfY3ZfcGF0aF9HUkVQPSIkYWNfcGF0aF9HUkVQIgot
ICAgICAgYWNfcGF0aF9HUkVQX21heD0kYWNfY291bnQKLSAgICBmaQotICAgICMgMTAqKDJeMTAp
IGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKLSAgICB0ZXN0ICRhY19jb3Vu
dCAtZ3QgMTAgJiYgYnJlYWsKLSAgZG9uZQotICBybSAtZiBjb25mdGVzdC5pbiBjb25mdGVzdC50
bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKLWVzYWMKLQotICAgICAgJGFjX3BhdGhfR1JF
UF9mb3VuZCAmJiBicmVhayAzCi0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2
ZV9JRlMKLSAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4KLSAgICBhc19mbl9l
cnJvciAkPyAibm8gYWNjZXB0YWJsZSBncmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhf
U0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKLSAgZmkKLWVsc2UKLSAgYWNfY3Zf
cGF0aF9HUkVQPSRHUkVQCi1maQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0dSRVAiID4mNQotJGFzX2VjaG8gIiRhY19j
dl9wYXRoX0dSRVAiID4mNjsgfQotIEdSRVA9IiRhY19jdl9wYXRoX0dSRVAiCi0KLQoteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZWdyZXAiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGVncmVwLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfRUdSRVArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgotZWxzZQotICBpZiBlY2hvIGEgfCAkR1JFUCAtRSAnKGF8YiknID4vZGV2L251
bGwgMj4mMQotICAgdGhlbiBhY19jdl9wYXRoX0VHUkVQPSIkR1JFUCAtRSIKLSAgIGVsc2UKLSAg
ICAgaWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgotICBhY19wYXRoX0VHUkVQX2ZvdW5kPWZhbHNl
Ci0gICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQ
Uk9HTkFNRS1MSVNUCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZv
ciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCi1kbwotICBJRlM9
JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFj
X3Byb2cgaW4gZWdyZXA7IGRvCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCi0gICAgICBhY19wYXRoX0VHUkVQPSIkYXNfZGlyLyRhY19wcm9n
JGFjX2V4ZWNfZXh0IgotICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9FR1JFUCIgJiYgJGFzX3Rl
c3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNvbnRpbnVlCi0jIENoZWNrIGZvciBHTlUgYWNf
cGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgotICAjIENoZWNrIGZvciBH
TlUgJGFjX3BhdGhfRUdSRVAKLWNhc2UgYCIkYWNfcGF0aF9FR1JFUCIgLS12ZXJzaW9uIDI+JjFg
IGluCi0qR05VKikKLSAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiIGFjX3BhdGhf
RUdSRVBfZm91bmQ9Ojs7Ci0qKQotICBhY19jb3VudD0wCi0gICRhc19lY2hvX24gMDEyMzQ1Njc4
OSA+ImNvbmZ0ZXN0LmluIgotICB3aGlsZSA6Ci0gIGRvCi0gICAgY2F0ICJjb25mdGVzdC5pbiIg
ImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIKLSAgICBtdiAiY29uZnRlc3QudG1wIiAiY29u
ZnRlc3QuaW4iCi0gICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCi0gICAgJGFzX2Vj
aG8gJ0VHUkVQJyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRhY19wYXRoX0VHUkVQIiAnRUdSRVAk
JyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCi0g
ICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBi
cmVhawotICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9JGFzX3ZhbAot
ICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfRUdSRVBfbWF4LTB9OyB0aGVuCi0g
ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl
dHRlciBvbmUKLSAgICAgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIgotICAgICAg
YWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigyXjEwKSBjaGFy
cyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNfY291bnQgLWd0
IDEwICYmIGJyZWFrCi0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNv
bmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Ci1lc2FjCi0KLSAgICAgICRhY19wYXRoX0VHUkVQX2Zv
dW5kICYmIGJyZWFrIDMKLSAgICBkb25lCi0gIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lG
UwotICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JFUCI7IHRoZW4KLSAgICBhc19mbl9lcnJv
ciAkPyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NF
UEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1Ci0gIGZpCi1lbHNlCi0gIGFjX2N2X3Bh
dGhfRUdSRVA9JEVHUkVQCi1maQotCi0gICBmaQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9FR1JFUCIgPiY1Ci0kYXNfZWNo
byAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQotIEVHUkVQPSIkYWNfY3ZfcGF0aF9FR1JFUCIK
LQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBBTlNJIEMgaGVhZGVyIGZpbGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBBTlNJ
IEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zdGRj
K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK
LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv
bmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGxpYi5oPgotI2luY2x1ZGUgPHN0ZGFyZy5oPgot
I2luY2x1ZGUgPHN0cmluZy5oPgotI2luY2x1ZGUgPGZsb2F0Lmg+Ci0KLWludAotbWFpbiAoKQot
ewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUg
IiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfaGVhZGVyX3N0ZGM9eWVzCi1lbHNlCi0gIGFjX2N2
X2hlYWRlcl9zdGRjPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0g
eWVzOyB0aGVuCi0gICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwg
Y29udHJhcnkgdG8gQU5TSS4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0cmluZy5oPgotCi1f
QUNFT0YKLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKLSAgJEVH
UkVQICJtZW1jaHIiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0KLWVsc2UKLSAgYWNfY3ZfaGVh
ZGVyX3N0ZGM9bm8KLWZpCi1ybSAtZiBjb25mdGVzdCoKLQotZmkKLQotaWYgdGVzdCAkYWNfY3Zf
aGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLSAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3Qg
ZGVjbGFyZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8
c3RkbGliLmg+Ci0KLV9BQ0VPRgotaWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIp
IDI+JjUgfAotICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0KLWVsc2UK
LSAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KLWZpCi1ybSAtZiBjb25mdGVzdCoKLQotZmkKLQotaWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KLSAgIyAvYmluL2NjIGluIElyaXgt
NC4wLjUgZ2V0cyBub24tQU5TSSBjdHlwZSBtYWNyb3MgdW5sZXNzIHVzaW5nIC1hbnNpLgotICBp
ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIDoKLWVsc2UKLSAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZz
LmguICAqLwotI2luY2x1ZGUgPGN0eXBlLmg+Ci0jaW5jbHVkZSA8c3RkbGliLmg+Ci0jaWYgKCgn
ICcgJiAweDBGRikgPT0gMHgwMjApCi0jIGRlZmluZSBJU0xPV0VSKGMpICgnYScgPD0gKGMpICYm
IChjKSA8PSAneicpCi0jIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gJ0EnICsgKChj
KSAtICdhJykgOiAoYykpCi0jZWxzZQotIyBkZWZpbmUgSVNMT1dFUihjKSBcCi0JCSAgICgoJ2En
IDw9IChjKSAmJiAoYykgPD0gJ2knKSBcCi0JCSAgICAgfHwgKCdqJyA8PSAoYykgJiYgKGMpIDw9
ICdyJykgXAotCQkgICAgIHx8ICgncycgPD0gKGMpICYmIChjKSA8PSAneicpKQotIyBkZWZpbmUg
VE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICgoYykgfCAweDQwKSA6IChjKSkKLSNlbmRpZgotCi0j
ZGVmaW5lIFhPUihlLCBmKSAoKChlKSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQotaW50Ci1t
YWluICgpCi17Ci0gIGludCBpOwotICBmb3IgKGkgPSAwOyBpIDwgMjU2OyBpKyspCi0gICAgaWYg
KFhPUiAoaXNsb3dlciAoaSksIElTTE9XRVIgKGkpKQotCXx8IHRvdXBwZXIgKGkpICE9IFRPVVBQ
RVIgKGkpKQotICAgICAgcmV0dXJuIDI7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19m
bl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQotICBhY19jdl9oZWFkZXJfc3Rk
Yz1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5v
dXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5i
ZWFtIGNvbmZ0ZXN0LiRhY19leHQKLWZpCi0KLWZpCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYyIgPiY1Ci0kYXNf
ZWNobyAiJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9z
dGRjID0geWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIFNURENfSEVBREVSUyAxIiA+PmNv
bmZkZWZzLmgKLQotZmkKLQotIyBPbiBJUklYIDUuMywgc3lzL3R5cGVzIGFuZCBpbnR0eXBlcy5o
IGFyZSBjb25mbGljdGluZy4KLWZvciBhY19oZWFkZXIgaW4gc3lzL3R5cGVzLmggc3lzL3N0YXQu
aCBzdGRsaWIuaCBzdHJpbmcuaCBtZW1vcnkuaCBzdHJpbmdzLmggXAotCQkgIGludHR5cGVzLmgg
c3RkaW50LmggdW5pc3RkLmgKLWRvIDoKLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3Zf
aGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfY29t
cGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQKLSIKLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwiID0geCJ5ZXMi
OyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBgJGFzX2VjaG8g
IkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQotZmkKLQotZG9uZQot
Ci0KLQotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibWluaXgvY29u
ZmlnLmgiICJhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19oIiA9IHgiInllczsgdGhl
biA6Ci0gIE1JTklYPXllcwotZWxzZQotICBNSU5JWD0KLWZpCi0KLQotICBpZiB0ZXN0ICIkTUlO
SVgiID0geWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIgPj5j
b25mZGVmcy5oCi0KLQotJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+Y29u
ZmRlZnMuaAotCi0KLSRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZkZWZzLmgKLQot
ICBmaQotCi0KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fIiA+JjUKLSRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2FmZSB0byBkZWZpbmUgX19FWFRFTlNJ
T05TX18uLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRl
bnNpb25zX18rc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLSMJICBkZWZpbmUgX19FWFRFTlNJT05TX18gMQotCSAg
JGFjX2luY2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJuIDA7
Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAg
YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX189eWVzCi1lbHNlCi0gIGFjX2N2X3Nh
ZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9zYWZlX3RvX2RlZmlu
ZV9fX2V4dGVuc2lvbnNfXyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19f
ZXh0ZW5zaW9uc19fIiA+JjY7IH0KLSAgdGVzdCAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRl
bnNpb25zX18gPSB5ZXMgJiYKLSAgICAkYXNfZWNobyAiI2RlZmluZSBfX0VYVEVOU0lPTlNfXyAx
IiA+PmNvbmZkZWZzLmgKLQotICAkYXNfZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNv
bmZkZWZzLmgKLQotICAkYXNfZWNobyAiI2RlZmluZSBfR05VX1NPVVJDRSAxIiA+PmNvbmZkZWZz
LmgKLQotICAkYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MgMSIgPj5j
b25mZGVmcy5oCi0KLSAgJGFzX2VjaG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25m
ZGVmcy5oCi0KLQotIyBNYWtlIHN1cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgotJFNIRUxMICIk
YWNfYXV4X2Rpci9jb25maWcuc3ViIiBzdW40ID4vZGV2L251bGwgMj4mMSB8fAotICBhc19mbl9l
cnJvciAkPyAiY2Fubm90IHJ1biAkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgIiRMSU5F
Tk8iIDUKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBidWlsZCBzeXN0ZW0gdHlwZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBidWlsZCBzeXN0
ZW0gdHlwZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9idWlsZCtzZXR9IiA9IHNldDsg
dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2J1aWxkX2Fs
aWFzPSRidWlsZF9hbGlhcwotdGVzdCAieCRhY19idWlsZF9hbGlhcyIgPSB4ICYmCi0gIGFjX2J1
aWxkX2FsaWFzPWAkU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5ndWVzcyJgCi10ZXN0ICJ4JGFj
X2J1aWxkX2FsaWFzIiA9IHggJiYKLSAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBndWVzcyBidWls
ZCB0eXBlOyB5b3UgbXVzdCBzcGVjaWZ5IG9uZSIgIiRMSU5FTk8iIDUKLWFjX2N2X2J1aWxkPWAk
U0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICRhY19idWlsZF9hbGlhc2AgfHwKLSAgYXNf
Zm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViICRhY19idWlsZF9hbGlh
cyBmYWlsZWQiICIkTElORU5PIiA1Ci0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2J1aWxkIiA+JjUKLSRhc19lY2hvICIkYWNfY3Zf
YnVpbGQiID4mNjsgfQotY2FzZSAkYWNfY3ZfYnVpbGQgaW4KLSotKi0qKSA7OwotKikgYXNfZm5f
ZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGJ1aWxkIiAiJExJTkVOTyIgNSA7
OwotZXNhYwotYnVpbGQ9JGFjX2N2X2J1aWxkCi1hY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCi1z
ZXQgeCAkYWNfY3ZfYnVpbGQKLXNoaWZ0Ci1idWlsZF9jcHU9JDEKLWJ1aWxkX3ZlbmRvcj0kMgot
c2hpZnQ7IHNoaWZ0Ci0jIFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1
c2VkIHRvIGNyZWF0ZSAkKiwKLSMgZXhjZXB0IHdpdGggb2xkIHNoZWxsczoKLWJ1aWxkX29zPSQq
Ci1JRlM9JGFjX3NhdmVfSUZTCi1jYXNlICRidWlsZF9vcyBpbiAqXCAqKSBidWlsZF9vcz1gZWNo
byAiJGJ1aWxkX29zIiB8IHNlZCAncy8gLy0vZydgOzsgZXNhYwotCi0KLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZSIgPiY1
Ci0kYXNfZWNob19uICJjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlLi4uICIgPiY2OyB9Ci1pZiB0
ZXN0ICIke2FjX2N2X2hvc3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICJ4JGhvc3RfYWxpYXMiID0geDsgdGhlbgotICBh
Y19jdl9ob3N0PSRhY19jdl9idWlsZAotZWxzZQotICBhY19jdl9ob3N0PWAkU0hFTEwgIiRhY19h
dXhfZGlyL2NvbmZpZy5zdWIiICRob3N0X2FsaWFzYCB8fAotICAgIGFzX2ZuX2Vycm9yICQ/ICIk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkaG9zdF9hbGlhcyBmYWlsZWQiICIkTElORU5P
IiA1Ci1maQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9ob3N0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaG9zdCIgPiY2OyB9Ci1j
YXNlICRhY19jdl9ob3N0IGluCi0qLSotKikgOzsKLSopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlk
IHZhbHVlIG9mIGNhbm9uaWNhbCBob3N0IiAiJExJTkVOTyIgNSA7OwotZXNhYwotaG9zdD0kYWNf
Y3ZfaG9zdAotYWNfc2F2ZV9JRlM9JElGUzsgSUZTPSctJwotc2V0IHggJGFjX2N2X2hvc3QKLXNo
aWZ0Ci1ob3N0X2NwdT0kMQotaG9zdF92ZW5kb3I9JDIKLXNoaWZ0OyBzaGlmdAotIyBSZW1lbWJl
ciwgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiBJRlMgaXMgdXNlZCB0byBjcmVhdGUgJCosCi0jIGV4
Y2VwdCB3aXRoIG9sZCBzaGVsbHM6Ci1ob3N0X29zPSQqCi1JRlM9JGFjX3NhdmVfSUZTCi1jYXNl
ICRob3N0X29zIGluICpcICopIGhvc3Rfb3M9YGVjaG8gIiRob3N0X29zIiB8IHNlZCAncy8gLy0v
ZydgOzsgZXNhYwotCi0KLQotIyBNNCBNYWNybyBpbmNsdWRlcwotCi0KLQotCi0KLQotCi0KLQot
Ci0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0K
LQotCi0KLQotCi0KLQotCi0KLSMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQgdXRpbGlz
ZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KLSMgc2VyaWFsIDEgKHBr
Zy1jb25maWctMC4yNCkKLSMKLSMgQ29weXJpZ2h0IMKpIDIwMDQgU2NvdHQgSmFtZXMgUmVtbmFu
dCA8c2NvdHRAbmV0c3BsaXQuY29tPi4KLSMKLSMgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKLSMgaXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkK
LSMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUg
TGljZW5zZSwgb3IKLSMgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KLSMKLSMg
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1
c2VmdWwsIGJ1dAotIyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBs
aWVkIHdhcnJhbnR5IG9mCi0jIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJ
Q1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCi0jIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9y
IG1vcmUgZGV0YWlscy4KLSMKLSMgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKLSMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07
IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKLSMgRm91bmRhdGlvbiwgSW5jLiwg
NTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLCBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVTQS4K
LSMKLSMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UsIGlmIHlvdQotIyBkaXN0cmlidXRlIHRoaXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3Jh
bSB0aGF0IGNvbnRhaW5zIGEKLSMgY29uZmlndXJhdGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1
dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIKLSMgdGhlIHNhbWUgZGlzdHJpYnV0aW9u
IHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhhdCBwcm9ncmFtLgotCi0jIFBL
R19QUk9HX1BLR19DT05GSUcoW01JTi1WRVJTSU9OXSkKLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQotIyBQS0dfUFJPR19QS0dfQ09ORklHCi0KLSMgUEtHX0NIRUNLX0VYSVNU
UyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQotIwot
IyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMgZXhpc3Rz
LiAgU2ltaWxhcgotIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBub3Qgc2V0IHZh
cmlhYmxlcyBvciBwcmludCBlcnJvcnMuCi0jCi0jIFBsZWFzZSByZW1lbWJlciB0aGF0IG00IGV4
cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCi0jIG9ubHkgYXQgdGhlIGZp
cnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBwbGFjZQotIyBp
dCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdpdGhpbiBhbiAi
aWYiLCB5b3UKLSMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFsbHkKLSMgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KLQotCi0jIF9QS0dfQ09ORklHKFtWQVJJQUJMRV0sIFtDT01NQU5EXSwgW01PRFVMRVNdKQot
IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgX1BLR19D
T05GSUcKLQotIyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKLSMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0KLSMgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVECi0KLQotIyBQS0df
Q0hFQ0tfTU9EVUxFUyhWQVJJQUJMRS1QUkVGSVgsIE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRd
LAotIyBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCi0jCi0jCi0jIE5vdGUgdGhhdCBpZiB0aGVyZSBp
cyBhIHBvc3NpYmlsaXR5IHRoZSBmaXJzdCBjYWxsIHRvCi0jIFBLR19DSEVDS19NT0RVTEVTIG1p
Z2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3VyZSB0byBpbmNsdWRlIGFuCi0jIGV4cGxp
Y2l0IGNhbGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBpbiB5b3VyIGNvbmZpZ3VyZS5hYwotIwot
IwotIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQotIyBQS0dfQ0hFQ0tfTU9EVUxFUwotCi0KLQotIyBXZSBkZWZpbmUsIHNlcGFy
YXRlbHksIFBUSFJFQURfQ0ZMQUdTLCBfTERGTEFHUyBhbmQgX0xJQlMKLSMgZXZlbiB0aG91Z2gg
Y3VycmVudGx5IHdlIGRvbid0IHNldCB0aGVtIHZlcnkgc2VwYXJhdGVseS4KLSMgVGhpcyBtZWFu
cyB0aGF0IHRoZSBtYWtlZmlsZXMgd2lsbCBub3QgbmVlZCB0byBjaGFuZ2UgaW4KLSMgdGhlIGZ1
dHVyZSBpZiB3ZSBtYWtlIHRoZSB0ZXN0IG1vcmUgc29waGlzdGljYXRlZC4KLQotCi0KLSMgV2Ug
aW52b2tlIEFYX1BUSFJFQURfVkFSUyB3aXRoIHRoZSBuYW1lIG9mIGFub3RoZXIgbWFjcm8KLSMg
d2hpY2ggaXMgdGhlbiBleHBhbmRlZCBvbmNlIGZvciBlYWNoIHZhcmlhYmxlLgotCi0KLQotCi0K
LQotCi0KLSMgRW5hYmxlL2Rpc2FibGUgb3B0aW9ucwotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFi
bGUtZ2l0aHR0cCB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9naXRodHRwK3NldH0iID0g
c2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfZ2l0aHR0cDsKLWZpCi0KLQotaWYgdGVz
dCAieCRlbmFibGVfZ2l0aHR0cCIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9naXRodHRw
PSJuIgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0gInh5ZXMiOyB0aGVuIDoKLQot
ICAgIGF4X2N2X2dpdGh0dHA9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhl
biA6Ci0KLSAgICBheF9jdl9naXRodHRwPSJuIgotCi1maQotZ2l0aHR0cD0kYXhfY3ZfZ2l0aHR0
cAotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KLWlm
IHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFs
PSRlbmFibGVfbW9uaXRvcnM7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9
ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X21vbml0b3JzPSJuIgotCi1lbGlmIHRlc3QgIngk
ZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9tb25pdG9ycz0i
eSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9tb25pdG9yczsgdGhlbiA6Ci0KLSAgICBheF9jdl9t
b25pdG9ycz0ieSIKLQotZmkKLW1vbml0b3JzPSRheF9jdl9tb25pdG9ycwotCi0KLQotIyBDaGVj
ayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfdnRw
bStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07Ci1maQotCi0K
LWlmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfdnRw
bT0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAg
ICBheF9jdl92dHBtPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgotCi0g
ICAgYXhfY3ZfdnRwbT0ibiIKLQotZmkKLXZ0cG09JGF4X2N2X3Z0cG0KLQotCi0KLSMgQ2hlY2sg
d2hldGhlciAtLWVuYWJsZS14ZW5hcGkgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfeGVu
YXBpK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfeGVuYXBpOwotZmkK
LQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhf
Y3ZfeGVuYXBpPSJuIgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieHllcyI7IHRo
ZW4gOgotCi0gICAgYXhfY3ZfeGVuYXBpPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X3hlbmFw
aTsgdGhlbiA6Ci0KLSAgICBheF9jdl94ZW5hcGk9Im4iCi0KLWZpCi14ZW5hcGk9JGF4X2N2X3hl
bmFwaQotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZl
bi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3B5dGhvbnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAg
ZW5hYmxldmFsPSRlbmFibGVfcHl0aG9udG9vbHM7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5hYmxl
X3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJu
IgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6Ci0K
LSAgICBheF9jdl9weXRob250b29scz0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250
b29sczsgdGhlbiA6Ci0KLSAgICBheF9jdl9weXRob250b29scz0ieSIKLQotZmkKLXB5dGhvbnRv
b2xzPSRheF9jdl9weXRob250b29scwotCi0KLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW9j
YW1sdG9vbHMgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfb2NhbWx0b29scytzZXR9IiA9
IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX29jYW1sdG9vbHM7Ci1maQotCi0KLWlm
IHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3Zf
b2NhbWx0b29scz0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVz
IjsgdGhlbiA6Ci0KLSAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4
X2N2X29jYW1sdG9vbHM7IHRoZW4gOgotCi0gICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKLQotZmkK
LW9jYW1sdG9vbHM9JGF4X2N2X29jYW1sdG9vbHMKLQotCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVu
YWJsZS1taW5pdGVybSB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9taW5pdGVybStzZXR9
IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOwotZmkKLQotCi1p
ZiB0ZXN0ICJ4JGVuYWJsZV9taW5pdGVybSIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9t
aW5pdGVybT0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9taW5pdGVybSIgPSAieHllcyI7IHRo
ZW4gOgotCi0gICAgYXhfY3ZfbWluaXRlcm09InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfbWlu
aXRlcm07IHRoZW4gOgotCi0gICAgYXhfY3ZfbWluaXRlcm09Im4iCi0KLWZpCi1taW5pdGVybT0k
YXhfY3ZfbWluaXRlcm0KLQotCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21vdW50IHdh
cyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0fSIgPSBzZXQ7IHRoZW4gOgot
ICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9s
b21vdW50IiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X2xvbW91bnQ9Im4iCi0KLWVsaWYg
dGVzdCAieCRlbmFibGVfbG9tb3VudCIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfbG9t
b3VudD0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9sb21vdW50OyB0aGVuIDoKLQotICAgIGF4
X2N2X2xvbW91bnQ9Im4iCi0KLWZpCi1sb21vdW50PSRheF9jdl9sb21vdW50Ci0KLQotCi0jIENo
ZWNrIHdoZXRoZXIgLS1lbmFibGUtb3ZtZiB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9v
dm1mK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfb3ZtZjsKLWZpCi0K
LQotaWYgdGVzdCAieCRlbmFibGVfb3ZtZiIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9v
dm1mPSJuIgotCi1lbGlmIHRlc3QgIngkZW5hYmxlX292bWYiID0gInh5ZXMiOyB0aGVuIDoKLQot
ICAgIGF4X2N2X292bWY9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3Zfb3ZtZjsgdGhlbiA6Ci0K
LSAgICBheF9jdl9vdm1mPSJuIgotCi1maQotb3ZtZj0kYXhfY3Zfb3ZtZgorIyBNNCBNYWNybyBp
bmNsdWRlcwogCiAKIAotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXJvbWJpb3Mgd2FzIGdpdmVu
LgotaWYgdGVzdCAiJHtlbmFibGVfcm9tYmlvcytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJs
ZXZhbD0kZW5hYmxlX3JvbWJpb3M7Ci1maQogCiAKLWlmIHRlc3QgIngkZW5hYmxlX3JvbWJpb3Mi
ID0gInhubyI7IHRoZW4gOgogCi0gICAgYXhfY3Zfcm9tYmlvcz0ibiIKIAotZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9yb21iaW9zIiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICBheF9jdl9yb21iaW9zPSJ5
IgogCi1lbGlmIHRlc3QgLXogJGF4X2N2X3JvbWJpb3M7IHRoZW4gOgogCi0gICAgYXhfY3Zfcm9t
Ymlvcz0ieSIKIAotZmkKLXJvbWJpb3M9JGF4X2N2X3JvbWJpb3MKIAogCiAKLSMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1zZWFiaW9zIHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3NlYWJp
b3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9zZWFiaW9zOwotZmkK
IAogCi1pZiB0ZXN0ICJ4JGVuYWJsZV9zZWFiaW9zIiA9ICJ4bm8iOyB0aGVuIDoKIAotICAgIGF4
X2N2X3NlYWJpb3M9Im4iCiAKLWVsaWYgdGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieHllcyI7
IHRoZW4gOgogCi0gICAgYXhfY3Zfc2VhYmlvcz0ieSIKIAotZWxpZiB0ZXN0IC16ICRheF9jdl9z
ZWFiaW9zOyB0aGVuIDoKIAotICAgIGF4X2N2X3NlYWJpb3M9InkiCiAKLWZpCi1zZWFiaW9zPSRh
eF9jdl9zZWFiaW9zCiAKIAogCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtZGVidWcgd2FzIGdp
dmVuLgotaWYgdGVzdCAiJHtlbmFibGVfZGVidWcrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFi
bGV2YWw9JGVuYWJsZV9kZWJ1ZzsKLWZpCiAKIAotaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0g
InhubyI7IHRoZW4gOgogCi0gICAgYXhfY3ZfZGVidWc9Im4iCiAKLWVsaWYgdGVzdCAieCRlbmFi
bGVfZGVidWciID0gInh5ZXMiOyB0aGVuIDoKIAotICAgIGF4X2N2X2RlYnVnPSJ5IgogCi1lbGlm
IHRlc3QgLXogJGF4X2N2X2RlYnVnOyB0aGVuIDoKIAotICAgIGF4X2N2X2RlYnVnPSJ5IgogCi1m
aQotZGVidWc9JGF4X2N2X2RlYnVnCiAKIAogCkBAIC00MjQwLDkzMCArMjIyMiw0MzIgQEAgZGVi
dWc9JGF4X2N2X2RlYnVnCiAKIAogCi1mb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKLWRv
Ci0gICAgUFJFUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCi1kb25lCi1mb3IgbGRmbGFnIGluICRQ
UkVQRU5EX0xJQgotZG8KLSAgICBQUkVQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgotZG9uZQot
Zm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMKLWRvCi0gICAgQVBQRU5EX0NGTEFHUys9IiAt
SSRjZmxhZyIKLWRvbmUKLWZvciBsZGZsYWcgaW4gJEFQUEVORF9MSUIKLWRvCi0gICAgQVBQRU5E
X0xERkxBR1MrPSIgLUwkbGRmbGFnIgotZG9uZQotQ0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENG
TEFHUyAkQVBQRU5EX0NGTEFHUyIKLUxERkxBR1M9IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1Mg
JEFQUEVORF9MREZMQUdTIgogCiAKIAogCiAKIAorIyBwa2cubTQgLSBNYWNyb3MgdG8gbG9jYXRl
IGFuZCB1dGlsaXNlIHBrZy1jb25maWcuICAgICAgICAgICAgLSotIEF1dG9jb25mIC0qLQorIyBz
ZXJpYWwgMSAocGtnLWNvbmZpZy0wLjI0KQorIworIyBDb3B5cmlnaHQgwqkgMjAwNCBTY290dCBK
YW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+LgorIworIyBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorIyBp
dCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1
Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lv
biAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJz
aW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBp
dCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2
ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1Mg
Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUKKyMgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg
YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorIyBhbG9uZyB3aXRoIHRo
aXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0
aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgMDIxMTEt
MTMwNywgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3RyaWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQg
b2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBjb25maWd1cmF0aW9uIHNjcmlwdCBnZW5l
cmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVkZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBk
aXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZvciB0aGUgcmVzdCBvZiB0aGF0IHByb2dy
YW0uCiAKKyMgUEtHX1BST0dfUEtHX0NPTkZJRyhbTUlOLVZFUlNJT05dKQorIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBLR19QUk9HX1BLR19DT05GSUcKIAorIyBQS0df
Q0hFQ0tfRVhJU1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1G
T1VORF0pCisjCisjIENoZWNrIHRvIHNlZSB3aGV0aGVyIGEgcGFydGljdWxhciBzZXQgb2YgbW9k
dWxlcyBleGlzdHMuICBTaW1pbGFyCisjIHRvIFBLR19DSEVDS19NT0RVTEVTKCksIGJ1dCBkb2Vz
IG5vdCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9ycy4KKyMKKyMgUGxlYXNlIHJlbWVtYmVy
IHRoYXQgbTQgZXhwYW5kcyBBQ19SRVFVSVJFKFtQS0dfUFJPR19QS0dfQ09ORklHXSkKKyMgb25s
eSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZpZ3VyZS5hYywgc28gaWYgdGhlIGZpcnN0
IHBsYWNlCisjIGl0J3MgY2FsbGVkIG1pZ2h0IGJlIHNraXBwZWQgKHN1Y2ggYXMgaWYgaXQgaXMg
d2l0aGluIGFuICJpZiIsIHlvdQorIyBoYXZlIHRvIGNhbGwgUEtHX0NIRUNLX0VYSVNUUyBtYW51
YWxseQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQogCiAKKyMgX1BLR19DT05GSUcoW1ZBUklBQkxFXSwgW0NPTU1BTkRdLCBb
TU9EVUxFU10pCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorIyBfUEtHX0NPTkZJRwogCisjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQK
IAogCisjIFBLR19DSEVDS19NT0RVTEVTKFZBUklBQkxFLVBSRUZJWCwgTU9EVUxFUywgW0FDVElP
Ti1JRi1GT1VORF0sCisjIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkKKyMKKyMKKyMgTm90ZSB0aGF0
IGlmIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhlIGZpcnN0IGNhbGwgdG8KKyMgUEtHX0NIRUNL
X01PRFVMRVMgbWlnaHQgbm90IGhhcHBlbiwgeW91IHNob3VsZCBiZSBzdXJlIHRvIGluY2x1ZGUg
YW4KKyMgZXhwbGljaXQgY2FsbCB0byBQS0dfUFJPR19QS0dfQ09ORklHIGluIHlvdXIgY29uZmln
dXJlLmFjCisjCisjCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBLR19DSEVDS19NT0RVTEVTCiAKLSMgQ2hlY2tzIGZv
ciBwcm9ncmFtcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0cHV0IiA+JjUKLSRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dC4u
LiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1NFRCtzZXR9IiA9IHNldDsgdGhlbiA6
Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gICAgICAgICAgICBhY19zY3Jp
cHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJiYmJiYmJi
YmJiYmJiYmJiYmJiYmJiYmIvCi0gICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7IGRvCi0g
ICAgICAgYWNfc2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKLSAgICAgZG9uZQot
ICAgICBlY2hvICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0ZXN0LnNl
ZAotICAgICB7IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9Ci0gICAgIGlmIHRlc3QgLXog
IiRTRUQiOyB0aGVuCi0gIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCi0gICMgTG9vcCB0aHJvdWdo
IHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCi0gIGFz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgK
LWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
LSAgICBmb3IgYWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KLSAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgICAgIGFjX3BhdGhfU0VEPSIkYXNf
ZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgotICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9TRUQi
ICYmICRhc190ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKLSMgQ2hlY2sgZm9y
IEdOVSBhY19wYXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgotICAjIENoZWNr
IGZvciBHTlUgJGFjX3BhdGhfU0VECi1jYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNpb24gMj4m
MWAgaW4KLSpHTlUqKQotICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19wYXRoX1NF
RF9mb3VuZD06OzsKLSopCi0gIGFjX2NvdW50PTAKLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4i
Y29uZnRlc3QuaW4iCi0gIHdoaWxlIDoKLSAgZG8KLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29u
ZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgotICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVz
dC5pbiIKLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKLSAgICAkYXNfZWNobyAn
JyA+PiAiY29uZnRlc3QubmwiCi0gICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Quc2VkIDwg
ImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKLSAgICBk
aWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFr
Ci0gICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCi0gICAg
aWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCi0gICAgICAj
IEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBv
bmUKLSAgICAgIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCi0gICAgICBhY19wYXRoX1NF
RF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBz
ZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFr
Ci0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNv
bmZ0ZXN0Lm91dDs7Ci1lc2FjCiAKLSAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBicmVhayAz
Ci0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLSAgaWYgdGVzdCAt
eiAiJGFjX2N2X3BhdGhfU0VEIjsgdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRh
YmxlIHNlZCBjb3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1Ci0gIGZpCi1lbHNl
Ci0gIGFjX2N2X3BhdGhfU0VEPSRTRUQKLWZpCiAKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKLSRhc19lY2hv
ICIkYWNfY3ZfcGF0aF9TRUQiID4mNjsgfQotIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgotICBybSAt
ZiBjb25mdGVzdC5zZWQKKyMgV2UgZGVmaW5lLCBzZXBhcmF0ZWx5LCBQVEhSRUFEX0NGTEFHUywg
X0xERkxBR1MgYW5kIF9MSUJTCisjIGV2ZW4gdGhvdWdoIGN1cnJlbnRseSB3ZSBkb24ndCBzZXQg
dGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCisjIFRoaXMgbWVhbnMgdGhhdCB0aGUgbWFrZWZpbGVzIHdp
bGwgbm90IG5lZWQgdG8gY2hhbmdlIGluCisjIHRoZSBmdXR1cmUgaWYgd2UgbWFrZSB0aGUgdGVz
dCBtb3JlIHNvcGhpc3RpY2F0ZWQuCiAKLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdT
JwotYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQg
PiY1JwotYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFH
UyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0k
YWNfY3ZfY19jb21waWxlcl9nbnUKLWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29s
X3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2Mi
Ci0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBk
b25lCi1JRlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRh
c19lY2hvICJubyIgPiY2OyB9Ci1maQogCisjIFdlIGludm9rZSBBWF9QVEhSRUFEX1ZBUlMgd2l0
aCB0aGUgbmFtZSBvZiBhbm90aGVyIG1hY3JvCisjIHdoaWNoIGlzIHRoZW4gZXhwYW5kZWQgb25j
ZSBmb3IgZWFjaCB2YXJpYWJsZS4KIAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsg
dGhlbgotICBhY19jdF9DQz0kQ0MKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2Mi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGdjYzsg
YWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1u
ICIkYWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3Nh
dmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2Mi
Ci0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBk
b25lCi1JRlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKLWlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N0X0NDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQogCi0g
IGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBj
YXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29s
cyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0
IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0g
IGZpCi1lbHNlCi0gIENDPSIkYWNfY3ZfcHJvZ19DQyIKLWZpCiAKLWlmIHRlc3QgLXogIiRDQyI7
IHRoZW4KLSAgICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJl
Zml4fWNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNl
dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCi0gICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1J
RlM9JGFzX3NhdmVfSUZTCiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4g
IiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hv
ICJubyIgPiY2OyB9Ci1maQogCiAKLSAgZmkKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0k
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0i
JENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLSAgYWNfcHJvZ19y
ZWplY3RlZD1ubwotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFz
X2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
Ci0gICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2Iv
Y2MiOyB0aGVuCi0gICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKLSAgICAgICBjb250aW51ZQot
ICAgICBmaQotICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgotICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4m
NQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwogCi1p
ZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCi0gICMgV2UgZm91bmQgYSBib2dv
biBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KLSAgc2V0IGR1bW15
ICRhY19jdl9wcm9nX0NDCi0gIHNoaWZ0Ci0gIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgotICAgICMg
V2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgotICAgICMg
SG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBj
aG9zZW4KLSAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNl
IHRoZSBmdWxsIGZpbGUgbmFtZS4KLSAgICBzaGlmdAotICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19k
aXIvJGFjX3dvcmQkezErJyAnfSRAIgotICBmaQotZmkKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2df
Q0MKLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVs
c2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9CisjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKKwor
IyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWdpdGh0dHAgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtl
bmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX2dp
dGh0dHA7CiBmaQogCiAKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gIGlmIHRlc3QgLW4g
IiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCi0gIGRvCi0g
ICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJGFjX3Rv
b2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX0ND
K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK
LSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lG
UwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19DQz0iJGFjX3Rvb2xfcHJlZml4
JGFjX3Byb2ciCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91
bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQot
ZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRw
IiA9ICJ4bm8iOyB0aGVuIDoKIAotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAt
biAiJENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KLWZpCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKIAorZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICB0ZXN0IC1uICIkQ0MiICYm
IGJyZWFrCi0gIGRvbmUKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gIGFjX2N0X0NDPSRD
QwotICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKLWRvCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgot
c2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19h
Y19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UK
LWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBB
VEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2
X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAg
IGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworICAgIGF4X2N2
X2dpdGh0dHA9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhlbiA6CisKKyAg
ICBheF9jdl9naXRodHRwPSJuIgogCiBmaQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0
X0NDCi1pZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRh
Y19jdF9DQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKK2dpdGh0
dHA9JGF4X2N2X2dpdGh0dHAKIAogCi0gIHRlc3QgLW4gIiRhY19jdF9DQyIgJiYgYnJlYWsKLWRv
bmUKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KLSAgICBDQz0iIgotICBlbHNl
Ci0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikKLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIk
YXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3Qg
dHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwotICAgIENDPSRhY19j
dF9DQwotICBmaQorIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4K
K2lmIHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxl
dmFsPSRlbmFibGVfbW9uaXRvcnM7CiBmaQogCi1maQogCitpZiB0ZXN0ICJ4JGVuYWJsZV9tb25p
dG9ycyIgPSAieG5vIjsgdGhlbiA6CiAKLXRlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0k
YXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJv
ciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAotU2VlIFxgY29u
ZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisgICAgYXhfY3ZfbW9u
aXRvcnM9Im4iCiAKLSMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxl
ci4KLSRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBD
IGNvbXBpbGVyIHZlcnNpb24iID4mNQotc2V0IFggJGFjX2NvbXBpbGUKLWFjX2NvbXBpbGVyPSQy
Ci1mb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCi0gIHsgeyBh
Y190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKLWNhc2UgIigoJGFjX3RyeSIgaW4K
LSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3Ry
eV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8i
OyB9ID4mNQotICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVz
dC5lcnIKLSAgYWNfc3RhdHVzPSQ/Ci0gIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCi0g
ICAgc2VkICcxMGFcCi0uLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCi0gICAg
ICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCi0gICAgY2F0IGNvbmZ0ZXN0LmVy
MSA+JjUKLSAgZmkKLSAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgotICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAg
dGVzdCAkYWNfc3RhdHVzID0gMDsgfQotZG9uZQorZWxpZiB0ZXN0ICJ4JGVuYWJsZV9tb25pdG9y
cyIgPSAieHllcyI7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0
fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl
ZnMuaC4gICovCisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCiAKLWludAotbWFpbiAoKQotewotI2lm
bmRlZiBfX0dOVUNfXwotICAgICAgIGNob2tlIG1lCi0jZW5kaWYKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfbW9uaXRvcnM7IHRoZW4gOgogCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY29tcGlsZXJfZ251PXll
cwotZWxzZQotICBhY19jb21waWxlcl9nbnU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWFjX2N2X2NfY29tcGlsZXJf
Z251PSRhY19jb21waWxlcl9nbnUKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKIAogZmkKLXsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21w
aWxlcl9nbnUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9Ci1p
ZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7IHRoZW4KLSAgR0NDPXllcwotZWxzZQotICBH
Q0M9Ci1maQotYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQotYWNfc2F2ZV9DRkxBR1M9JENG
TEFHUwoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3
aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIg
JENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19nK3Nl
dH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAg
YWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9mbGFnCi0gICBhY19jX3dlcnJvcl9m
bGFnPXllcwotICAgYWNfY3ZfcHJvZ19jY19nPW5vCi0gICBDRkxBR1M9Ii1nIgotICAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworbW9uaXRvcnM9JGF4X2N2X21vbml0b3JzCiAKLWludAotbWFpbiAoKQotewogCi0gIDsK
LSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKLSAgYWNfY3ZfcHJvZ19jY19nPXllcwotZWxzZQotICBDRkxBR1M9IiIKLSAgICAg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KIAotaW50Ci1tYWluICgpCi17CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUt
dnRwbSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV92dHBtK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgZW5hYmxldmFsPSRlbmFibGVfdnRwbTsKK2ZpCiAKLSAgOwotICByZXR1cm4gMDsKLX0K
LV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgogCi1lbHNl
Ci0gIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotCSBDRkxBR1M9Ii1n
IgotCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQg
Y29uZmRlZnMuaC4gICovCitpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoK
IAotaW50Ci1tYWluICgpCi17CisgICAgYXhfY3ZfdnRwbT0ibiIKKworZWxpZiB0ZXN0ICJ4JGVu
YWJsZV92dHBtIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl92dHBtPSJ5IgorCitlbGlm
IHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ibiIKIAotICA7
Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P
IjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0
LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1y
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKLSAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotZmkKLXsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19j
Y19nIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KLWlmIHRlc3QgIiRh
Y190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4KLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwotZWxp
ZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KLSAgaWYgdGVzdCAiJEdDQyIgPSB5
ZXM7IHRoZW4KLSAgICBDRkxBR1M9Ii1nIC1PMiIKLSAgZWxzZQotICAgIENGTEFHUz0iLWciCi0g
IGZpCi1lbHNlCi0gIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItTzIi
Ci0gIGVsc2UKLSAgICBDRkxBR1M9Ci0gIGZpCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4
OSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNP
IEM4OS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNl
dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2N2X3By
b2dfY2NfYzg5PW5vCi1hY19zYXZlX0NDPSRDQwotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGFy
Zy5oPgotI2luY2x1ZGUgPHN0ZGlvLmg+Ci0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVk
ZSA8c3lzL3N0YXQuaD4KLS8qIE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVu
IGZyb20gUkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KLXN0cnVjdCBidWYgeyBpbnQgeDsgfTsK
LUZJTEUgKiAoKnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Ci1z
dGF0aWMgY2hhciAqZSAocCwgaSkKLSAgICAgY2hhciAqKnA7Ci0gICAgIGludCBpOwotewotICBy
ZXR1cm4gcFtpXTsKLX0KLXN0YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50
KSwgY2hhciAqKnAsIC4uLikKLXsKLSAgY2hhciAqczsKLSAgdmFfbGlzdCB2OwotICB2YV9zdGFy
dCAodixwKTsKLSAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKLSAgdmFfZW5kICh2KTsKLSAg
cmV0dXJuIHM7Ci19Cit2dHBtPSRheF9jdl92dHBtCiAKLS8qIE9TRiA0LjAgQ29tcGFxIGNjIGlz
IHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQgaGFzCi0gICBmdW5jdGlv
biBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhISCcgaGV4IGNoYXJhY3RlciBjb25z
dGFudHMuCi0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVuZm9ydHVuYXRlbHksIGlu
c3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKLSAgIGFzICd4Jy4gIFRoZSBmb2xsb3dpbmcgaW5k
dWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQKLSAgIHByb3BlciBBTlNJ
IG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlzIGNvbWVzIG91dCB0cnVlLCBmb3Ig
YW4KLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vzc2FyeSB0byB3cml0ZSAnXHgw
MCc9PTAgdG8gZ2V0IHNvbWV0aGluZwotICAgdGhhdCdzIHRydWUgb25seSB3aXRoIC1zdGQuICAq
LwotaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8gMSA6IC0xXTsKIAotLyogSUJNIEMg
NiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQsIGJ1dCBpdCByZXBsYWNlcyBtYWNy
byBwYXJhbWV0ZXJzCi0gICBpbnNpZGUgc3RyaW5ncyBhbmQgY2hhcmFjdGVyIGNvbnN0YW50cy4g
ICovCi0jZGVmaW5lIEZPTyh4KSAneCcKLWludCB4bGM2X2NjX2FycmF5W0ZPTyhhKSA9PSAneCcg
PyAxIDogLTFdOwogCi1pbnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsKLXN0cnVjdCBzMSB7aW50
ICgqZikgKGludCBhKTt9Owotc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91YmxlIGEpO307Ci1pbnQg
cGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVjdCBz
dGF0ICosIGludCksIGludCwgaW50KTsKLWludCBhcmdjOwotY2hhciAqKmFyZ3Y7Ci1pbnQKLW1h
aW4gKCkKLXsKLXJldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwgYXJn
diwgMSkgIT0gYXJndlsxXTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotZm9yIGFjX2Fy
ZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1hbnNpIC1zdGQgXAotCS1BZSAiLUFh
IC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05TX18iCi1kbwotICBDQz0iJGFjX3Nh
dmVfQ0MgJGFjX2FyZyIKLSAgaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUt
eGVuYXBpIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3hlbmFwaStzZXR9IiA9IHNldDsg
dGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hlbmFwaTsKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0Ci0gIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODki
ICE9ICJ4bm8iICYmIGJyZWFrCi1kb25lCi1ybSAtZiBjb25mdGVzdC4kYWNfZXh0Ci1DQz0kYWNf
c2F2ZV9DQworCisKK2lmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6CisK
KyAgICBheF9jdl94ZW5hcGk9Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGVuYXBpIiA9ICJ4
eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl94ZW5hcGk9InkiCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfeGVuYXBpOyB0aGVuIDoKKworICAgIGF4X2N2X3hlbmFwaT0ibiIKIAogZmkKLSMgQUNfQ0FD
SEVfVkFMCi1jYXNlICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiBpbgotICB4KQotICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1
Ci0kYXNfZWNobyAibm9uZSBuZWVkZWQiID4mNjsgfSA7OwotICB4bm8pCi0gICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUK
LSRhc19lY2hvICJ1bnN1cHBvcnRlZCIgPiY2OyB9IDs7Ci0gICopCi0gICAgQ0M9IiRDQyAkYWNf
Y3ZfcHJvZ19jY19jODkiCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2M4OSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3By
b2dfY2NfYzg5IiA+JjY7IH0gOzsKLWVzYWMKLWlmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODki
ICE9IHhubzsgdGhlbiA6Cit4ZW5hcGk9JGF4X2N2X3hlbmFwaQorCiAKKworIyBDaGVjayB3aGV0
aGVyIC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3B5
dGhvbnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcHl0aG9u
dG9vbHM7CiBmaQogCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBp
bGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xp
bms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1Mg
Y29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29t
cGlsZXJfZ251CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0
aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9Ci1MTl9TPSRhc19sbl9zCi1pZiB0ZXN0ICIkTE5f
UyIgPSAibG4gLXMiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIgPiY2OyB9Ci1lbHNlCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubywgdXNpbmcg
JExOX1MiID4mNQotJGFzX2VjaG8gIm5vLCB1c2luZyAkTE5fUyIgPiY2OyB9CitpZiB0ZXN0ICJ4
JGVuYWJsZV9weXRob250b29scyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9weXRob250
b29scz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9weXRob250b29scyIgPSAieHllcyI7IHRo
ZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zf
cHl0aG9udG9vbHM7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9InkiCisKIGZpCitw
eXRob250b29scz0kYXhfY3ZfcHl0aG9udG9vbHMKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1B
S0UpIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMg
XCQoTUFLRSkuLi4gIiA+JjY7IH0KLXNldCB4ICR7TUFLRS1tYWtlfQotYWNfbWFrZT1gJGFzX2Vj
aG8gIiQyIiB8IHNlZCAncy8rL3AvZzsgcy9bXmEtekEtWjAtOV9dL18vZydgCi1pZiBldmFsICJ0
ZXN0IFwiXCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0K3NldH1cIiIgPSBzZXQ7IHRo
ZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgPmNvbmZ0ZXN0
Lm1ha2UgPDxcX0FDRU9GCi1TSEVMTCA9IC9iaW4vc2gKLWFsbDoKLQlAZWNobyAnQEBAJSUlPSQo
TUFLRSk9QEBAJSUlJwotX0FDRU9GCi0jIEdOVSBtYWtlIHNvbWV0aW1lcyBwcmludHMgIm1ha2Vb
MV06IEVudGVyaW5nIC4uLiIsIHdoaWNoIHdvdWxkIGNvbmZ1c2UgdXMuCi1jYXNlIGAke01BS0Ut
bWFrZX0gLWYgY29uZnRlc3QubWFrZSAyPi9kZXYvbnVsbGAgaW4KLSAgKkBAQCUlJT0/Kj1AQEAl
JSUqKQotICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PXllczs7Ci0gICop
Ci0gICAgZXZhbCBhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQ9bm87OwotZXNhYwotcm0g
LWYgY29uZnRlc3QubWFrZQorCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xz
IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX29jYW1sdG9vbHMrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xzOwogZmkKLWlmIGV2YWwgdGVzdCBc
JGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCA9IHllczsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hv
ICJ5ZXMiID4mNjsgfQotICBTRVRfTUFLRT0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9
Ci0gIFNFVF9NQUtFPSJNQUtFPSR7TUFLRS1tYWtlfSIKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9v
Y2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9vbHM9Im4iCisK
K2VsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgorCisgICAg
YXhfY3Zfb2NhbWx0b29scz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9vY2FtbHRvb2xzOyB0
aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCisKIGZpCitvY2FtbHRvb2xzPSRheF9j
dl9vY2FtbHRvb2xzCiAKLSMgRmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVy
IGEgQyBwcm9ncmFtIChmYXN0ZXIpLAotIyBzbyBvbmUgc2NyaXB0IGlzIGFzIGdvb2QgYXMgYW5v
dGhlci4gIEJ1dCBhdm9pZCB0aGUgYnJva2VuIG9yCi0jIGluY29tcGF0aWJsZSB2ZXJzaW9uczoK
LSMgU3lzViAvZXRjL2luc3RhbGwsIC91c3Ivc2Jpbi9pbnN0YWxsCi0jIFN1bk9TIC91c3IvZXRj
L2luc3RhbGwKLSMgSVJJWCAvc2Jpbi9pbnN0YWxsCi0jIEFJWCAvYmluL2luc3RhbGwKLSMgQW1p
Z2FPUyAvQy9pbnN0YWxsLCB3aGljaCBpbnN0YWxscyBib290YmxvY2tzIG9uIGZsb3BweSBkaXNj
cwotIyBBSVggNCAvdXNyL2Jpbi9pbnN0YWxsYnNkLCB3aGljaCBkb2Vzbid0IHdvcmsgd2l0aG91
dCBhIC1nIGZsYWcKLSMgQUZTIC91c3IvYWZzd3MvYmluL2luc3RhbGwsIHdoaWNoIG1pc2hhbmRs
ZXMgbm9uZXhpc3RlbnQgYXJncwotIyBTVlI0IC91c3IvdWNiL2luc3RhbGwsIHdoaWNoIHRyaWVz
IHRvIHVzZSB0aGUgbm9uZXhpc3RlbnQgZ3JvdXAgInN0YWZmIgotIyBPUy8yJ3Mgc3lzdGVtIGlu
c3RhbGwsIHdoaWNoIGhhcyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHNlbWFudGljCi0jIC4vaW5z
dGFsbCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNyZWF0ZWQgYnkgbWFrZSBmcm9tIC4vaW5z
dGFsbC5zaC4KLSMgUmVqZWN0IGluc3RhbGwgcHJvZ3JhbXMgdGhhdCBjYW5ub3QgaW5zdGFsbCBt
dWx0aXBsZSBmaWxlcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbCIgPiY1Ci0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsLi4uICIgPiY2OyB9Ci1pZiB0ZXN0
IC16ICIkSU5TVEFMTCI7IHRoZW4KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9pbnN0YWxsK3NldH0i
ID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAot
ZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgot
ICAgICMgQWNjb3VudCBmb3IgcGVvcGxlIHdobyBwdXQgdHJhaWxpbmcgc2xhc2hlcyBpbiBQQVRI
IGVsZW1lbnRzLgotY2FzZSAkYXNfZGlyLyBpbiAjKCgKLSAgLi8gfCAuLy8gfCAvW2NDXS8qIHwg
XAotICAvZXRjLyogfCAvdXNyL3NiaW4vKiB8IC91c3IvZXRjLyogfCAvc2Jpbi8qIHwgL3Vzci9h
ZnN3cy9iaW4vKiB8IFwKLSAgPzpbXFwvXW9zMltcXC9daW5zdGFsbFtcXC9dKiB8ID86W1xcL11P
UzJbXFwvXUlOU1RBTExbXFwvXSogfCBcCi0gIC91c3IvdWNiLyogKSA7OwotICAqKQotICAgICMg
T1NGMSBhbmQgU0NPIE9EVCAzLjAgaGF2ZSB0aGVpciBvd24gbmFtZXMgZm9yIGluc3RhbGwuCi0g
ICAgIyBEb24ndCB1c2UgaW5zdGFsbGJzZCBmcm9tIE9TRiBzaW5jZSBpdCBpbnN0YWxscyBzdHVm
ZiBhcyByb290Ci0gICAgIyBieSBkZWZhdWx0LgotICAgIGZvciBhY19wcm9nIGluIGdpbnN0YWxs
IHNjb2luc3QgaW5zdGFsbDsgZG8KLSAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotCWlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCI7
IH07IHRoZW4KLQkgIGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCi0JICAgIGdyZXAgZHNw
bXNnICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4K
LQkgICAgIyBBSVggaW5zdGFsbC4gIEl0IGhhcyBhbiBpbmNvbXBhdGlibGUgY2FsbGluZyBjb252
ZW50aW9uLgotCSAgICA6Ci0JICBlbGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCi0JICAg
IGdyZXAgcHdwbHVzICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+
JjE7IHRoZW4KLQkgICAgIyBwcm9ncmFtLXNwZWNpZmljIGluc3RhbGwgc2NyaXB0IHVzZWQgYnkg
SFAgcHdwbHVzLS1kb24ndCB1c2UuCi0JICAgIDoKLQkgIGVsc2UKLQkgICAgcm0gLXJmIGNvbmZ0
ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRlc3QuZGlyCi0JICAgIGVjaG8gb25lID4gY29uZnRl
c3Qub25lCi0JICAgIGVjaG8gdHdvID4gY29uZnRlc3QudHdvCi0JICAgIG1rZGlyIGNvbmZ0ZXN0
LmRpcgotCSAgICBpZiAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgLWMgY29uZnRlc3Qu
b25lIGNvbmZ0ZXN0LnR3byAiYHB3ZGAvY29uZnRlc3QuZGlyIiAmJgotCSAgICAgIHRlc3QgLXMg
Y29uZnRlc3Qub25lICYmIHRlc3QgLXMgY29uZnRlc3QudHdvICYmCi0JICAgICAgdGVzdCAtcyBj
b25mdGVzdC5kaXIvY29uZnRlc3Qub25lICYmCi0JICAgICAgdGVzdCAtcyBjb25mdGVzdC5kaXIv
Y29uZnRlc3QudHdvCi0JICAgIHRoZW4KLQkgICAgICBhY19jdl9wYXRoX2luc3RhbGw9IiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQgLWMiCi0JICAgICAgYnJlYWsgMwotCSAgICBmaQotCSAg
ZmkKLQlmaQotICAgICAgZG9uZQotICAgIGRvbmUKLSAgICA7OwotZXNhYwogCi0gIGRvbmUKLUlG
Uz0kYXNfc2F2ZV9JRlMKIAotcm0gLXJmIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRl
c3QuZGlyCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgoraWYg
dGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9
JGVuYWJsZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0g
InhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbWluaXRlcm09Im4iCisKK2VsaWYgdGVzdCAieCRl
bmFibGVfbWluaXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5
IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAgIGF4X2N2X21p
bml0ZXJtPSJuIgogCiBmaQotICBpZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9
IHNldDsgdGhlbgotICAgIElOU1RBTEw9JGFjX2N2X3BhdGhfaW5zdGFsbAotICBlbHNlCi0gICAg
IyBBcyBhIGxhc3QgcmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2Fj
aGUgYQotICAgICMgdmFsdWUgZm9yIElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwg
YmVjYXVzZSB0aGF0IHdpbGwKLSAgICAjIGJyZWFrIG90aGVyIHBhY2thZ2VzIHVzaW5nIHRoZSBj
YWNoZSBpZiB0aGF0IGRpcmVjdG9yeSBpcwotICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVl
IGlzIGEgcmVsYXRpdmUgbmFtZS4KLSAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCi0gIGZpCitt
aW5pdGVybT0kYXhfY3ZfbWluaXRlcm0KKworCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1s
b21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0fSIgPSBzZXQ7
IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OwogZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSU5TVEFMTCIgPiY1Ci0kYXNfZWNo
byAiJElOU1RBTEwiID4mNjsgfQogCi0jIFVzZSB0ZXN0IC16IGJlY2F1c2UgU3VuT1M0IHNoIG1p
c2hhbmRsZXMgYnJhY2VzIGluICR7dmFyLXZhbH0uCi0jIEl0IHRoaW5rcyB0aGUgZmlyc3QgY2xv
c2UgYnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgotdGVzdCAteiAiJElOU1RB
TExfUFJPR1JBTSIgJiYgSU5TVEFMTF9QUk9HUkFNPScke0lOU1RBTEx9JwogCi10ZXN0IC16ICIk
SU5TVEFMTF9TQ1JJUFQiICYmIElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworaWYgdGVzdCAi
eCRlbmFibGVfbG9tb3VudCIgPSAieG5vIjsgdGhlbiA6CiAKLXRlc3QgLXogIiRJTlNUQUxMX0RB
VEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisgICAgYXhfY3ZfbG9tb3Vu
dD0ibiIKIAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiaXNvbiIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgYmlzb247IGFjX3dvcmQ9JDIK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0JJU09OK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2FzZSAkQklTT04gaW4KLSAgW1xcL10q
IHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElG
Uz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfQklTT049
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitlbGlm
IHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X2xv
bW91bnQ9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbG9tb3VudDsgdGhlbiA6CisKKyAgICBh
eF9jdl9sb21vdW50PSJuIgogCi0gIDs7Ci1lc2FjCiBmaQotQklTT049JGFjX2N2X3BhdGhfQklT
T04KLWlmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1Ci0kYXNfZWNobyAiJEJJU09OIiA+
JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Citsb21vdW50PSRheF9jdl9sb21v
dW50CisKKworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb3ZtZiB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9vdm1mK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfb3ZtZjsKIGZpCiAKIAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJmbGV4Iiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBmbGV4OyBhY193
b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9GTEVYK3NldH0iID0gc2V0OyB0aGVuIDoK
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2FzZSAkRkxFWCBpbgotICBb
XFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0g
IElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfRkxF
WD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKK2lm
IHRlc3QgIngkZW5hYmxlX292bWYiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3Zfb3ZtZj0i
biIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBh
eF9jdl9vdm1mPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X292bWY7IHRoZW4gOgorCisgICAg
YXhfY3Zfb3ZtZj0ibiIKIAotICA7OwotZXNhYwogZmkKLUZMRVg9JGFjX2N2X3BhdGhfRkxFWAot
aWYgdGVzdCAtbiAiJEZMRVgiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkRkxFWCIgPiY1Ci0kYXNfZWNobyAiJEZMRVgiID4mNjsgfQot
ZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KK292bWY9JGF4X2N2X292bWYKKworCisKKyMg
Q2hlY2sgd2hldGhlciAtLWVuYWJsZS1yb21iaW9zIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5h
YmxlX3JvbWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9yb21i
aW9zOwogZmkKIAogCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBlcmwiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IHBlcmw7IGFjX3dvcmQ9
JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX1BFUkwrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXNlICRQRVJMIGluCi0gIFtcXC9d
KiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX1BFUkw9IiRQRVJMIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZT
PSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9QRVJMPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot
ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworaWYgdGVz
dCAieCRlbmFibGVfcm9tYmlvcyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9yb21iaW9z
PSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3JvbWJpb3MiID0gInh5ZXMiOyB0aGVuIDoKKwor
ICAgIGF4X2N2X3JvbWJpb3M9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfcm9tYmlvczsgdGhl
biA6CisKKyAgICBheF9jdl9yb21iaW9zPSJ5IgogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1BF
UkwiICYmIGFjX2N2X3BhdGhfUEVSTD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotUEVSTD0kYWNfY3Zf
cGF0aF9QRVJMCi1pZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQRVJMIiA+JjUKLSRhc19lY2hvICIkUEVS
TCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorcm9tYmlvcz0kYXhfY3Zf
cm9tYmlvcworCisKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXNlYWJpb3Mgd2FzIGdpdmVu
LgoraWYgdGVzdCAiJHtlbmFibGVfc2VhYmlvcytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJs
ZXZhbD0kZW5hYmxlX3NlYWJpb3M7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3NlYWJpb3Mi
ID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3Zfc2VhYmlvcz0ibiIKKworZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9zZWFiaW9zIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9zZWFiaW9zPSJ5
IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3NlYWJpb3M7IHRoZW4gOgorCisgICAgYXhfY3Zfc2Vh
Ymlvcz0ieSIKKworZmkKK3NlYWJpb3M9JGF4X2N2X3NlYWJpb3MKKworCisKKyMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9kZWJ1Zytz
ZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX2RlYnVnOworZmkKKworCitp
ZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9kZWJ1
Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieHllcyI7IHRoZW4gOgorCisg
ICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfZGVidWc7IHRoZW4gOgor
CisgICAgYXhfY3ZfZGVidWc9InkiCisKIGZpCitkZWJ1Zz0kYXhfY3ZfZGVidWcKKworCisKKwor
CisKKworCitmb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKK2RvCisgICAgUFJFUEVORF9D
RkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRQUkVQRU5EX0xJQgorZG8K
KyAgICBQUkVQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorZm9yIGNmbGFnIGluICRB
UFBFTkRfSU5DTFVERVMKK2RvCisgICAgQVBQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUK
K2ZvciBsZGZsYWcgaW4gJEFQUEVORF9MSUIKK2RvCisgICAgQVBQRU5EX0xERkxBR1MrPSIgLUwk
bGRmbGFnIgorZG9uZQorQ0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENGTEFHUyAkQVBQRU5EX0NG
TEFHUyIKK0xERkxBR1M9IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdT
IgorCisKIAogCi1pZiB0ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3RhbGwgcGVybCIgIiRMSU5F
Tk8iIDUKLWZpCi1pZiB0ZXN0ICJ4JHhhcGkiID0gInh5IjsgdGhlbiA6CiAKLSAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImN1cmwtY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgorCisK
KworCisKKworCisKKworIyBDaGVja3MgZm9yIHByb2dyYW1zLgorYWNfZXh0PWMKK2FjX2NwcD0n
JENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29u
ZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRD
RkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNf
Y29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xf
cHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9w
cmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBk
dW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3BhdGhfQ1VSTCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mr
c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot
ICBjYXNlICRDVVJMIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0NVUkw9
IiRDVVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAg
OzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRh
Y19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0NVUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2MiCiAgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNTE3MSw0NCArMjY1
NSwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9wYXRoX0NVUkw9Im5vIgotICA7OwotZXNhYwogZmkKLUNV
Ukw9JGFjX2N2X3BhdGhfQ1VSTAotaWYgdGVzdCAtbiAiJENVUkwiOyB0aGVuCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Ci0kYXNf
ZWNobyAiJENVUkwiID4mNjsgfQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAi
bm8iID4mNjsgfQogZmkKIAogCi1pZiB0ZXN0IHgiJHtDVVJMfSIgPT0geCJubyIKLXRoZW4KLSAg
ICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgY3VybC1jb25maWcsIHBsZWFzZSBpbnN0
YWxsIGN1cmwtY29uZmlnIiAiJExJTkVOTyIgNQogZmkKLSAgICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgInhtbDItY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KLXNldCBkdW1teSB4bWwyLWNvbmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFj
X2N2X3Byb2dfQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgZ2NjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YTUwrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0g
c2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAk
WE1MIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX1hNTD0iJFhNTCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0g
IGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJGFj
X2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lG
UwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9YTUw9IiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgogICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUyMTYsMzkgKzI2OTUsNDMg
QEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfWE1MIiAmJiBhY19jdl9wYXRoX1hNTD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotWE1MPSRhY19j
dl9wYXRoX1hNTAotaWYgdGVzdCAtbiAiJFhNTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYTUwiID4mNQotJGFzX2VjaG8gIiRYTUwi
ID4mNjsgfQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9CiBl
bHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotCi1pZiB0ZXN0IHgiJHtYTUx9IiA9
PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4bWwyLWNv
bmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElORU5PIiA1Ci1maQotCisgIGlm
IHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNl
ICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZp
CitlbHNlCisgIENDPSIkYWNfY3ZfcHJvZ19DQyIKIGZpCi1pZiB0ZXN0ICJ4JG9jYW1sdG9vbHMi
ID0gInh5IjsgdGhlbiA6CiAKLSAgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYwotICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGMiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjOyBhY193b3JkPSQy
CitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xf
cHJlZml4IjsgdGhlbgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1jYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3Byb2dfT0NBTUxDK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19D
QytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl
Ci0gIGlmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NB
TUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0LgogZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9y
IGFzX2RpciBpbiAkUEFUSApAQCAtNTI1Nyw3ICsyNzQwLDcgQEAgZG8KICAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIKKyAg
ICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgogICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUyNjcsMjkgKzI3NTAsMzAgQEAgSUZTPSRh
c19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKLWlmIHRlc3Qg
LW4gIiRPQ0FNTEMiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+JjUKLSRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK0ND
PSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRD
QyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCisgIGZpCiBm
aQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgotICBhY19jdF9PQ0FNTEM9
JE9DQU1MQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxjOyBhY193b3Jk
PSQyCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
IGNjOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0
aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9IiRhY19jdF9P
Q0FNTEMiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCiBlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCkBAIC01Mjk3LDcg
KzI3ODEsMTEgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxDPSJvY2FtbGMiCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAg
ICAgICBjb250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgogICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUzMDUsNjEgKzI3OTMsNDQg
QEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKK2lmIHRlc3QgJGFjX3Byb2dfcmVq
ZWN0ZWQgPSB5ZXM7IHRoZW4KKyAgIyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBt
YWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0LgorICBzZXQgZHVtbXkgJGFjX2N2X3Byb2dfQ0MKKyAg
c2hpZnQKKyAgaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVu
dCBjb21waWxlciBmcm9tIHRoZSBib2d1cyBvbmUuCisgICAgIyBIb3dldmVyLCBpdCBoYXMgdGhl
IHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxsIGJlIGNob3NlbgorICAgICMgZmlyc3Qg
aWYgd2Ugc2V0IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1l
LgorICAgIHNoaWZ0CisgICAgYWNfY3ZfcHJvZ19DQz0iJGFzX2Rpci8kYWNfd29yZCR7MSsnICd9
JEAiCisgIGZpCiBmaQogZmkKLWFjX2N0X09DQU1MQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMK
LWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxDIiA+JjUKLSRhc19lY2hv
ICIkYWNfY3RfT0NBTUxDIiA+JjY7IH0KK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAt
biAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQogICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEMiID0geDsgdGhl
bgotICAgIE9DQU1MQz0ibm8iCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFj
X3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9v
bHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9
eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMKLSAgZmkKLWVsc2UKLSAgT0NB
TUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMiCi1maQotCi0KLSAgaWYgdGVzdCAiJE9DQU1MQyIgIT0g
Im5vIjsgdGhlbgotICAgICBPQ0FNTFZFUlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8
Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKLSAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIg
PiY1Ci0kYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjY7IH0KLSAg
ICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAotICAgICBpZiB0ZXN0ICIkT0NBTUxMSUIi
ID0gIiI7IHRoZW4KLSAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rldi9udWxs
IHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRgCi0gICAgIGVsc2UKLSAgICAg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DQU1M
TElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY1Ci0kYXNfZWNobyAiT0NBTUxM
SUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7IH0KLSAgICAgZmkKLSAgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIGxp
YnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQotJGFzX2VjaG8gIk9DYW1sIGxpYnJhcnkgcGF0
aCBpcyAkT0NBTUxMSUIiID4mNjsgfQotCi0KIAotCi0gICAgICMgY2hlY2tpbmcgZm9yIG9jYW1s
b3B0Ci0gICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Iiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4
fW9jYW1sb3B0OyBhY193b3JkPSQyCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBpZiB0
ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNsLmV4ZQor
ICBkbworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFj
X3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
ICRhY190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
cHJvZ19PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2df
Q0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxz
ZQotICBpZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxPUFQ9
IiRPQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKIGZvciBhc19kaXIgaW4gJFBBVEgKQEAgLTUzNjgsNyArMjgzOSw3IEBAIGRvCiAgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0IgorICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZpeCRhY19wcm9nIgogICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUzNzgsMjggKzI4
NDksMzIgQEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MT1BUPSRhY19jdl9wcm9n
X09DQU1MT1BUCi1pZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxPUFQiID4mNQotJGFzX2Vj
aG8gIiRPQ0FNTE9QVCIgPiY2OyB9CitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5v
IiA+JjY7IH0KIGZpCiAKIAorICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKKyAgZG9uZQogZmkK
LWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BUIjsgdGhlbgotICBhY19jdF9PQ0FNTE9Q
VD0kT0NBTUxPUFQKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxvcHQ7
IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZv
ciBhY19wcm9nIGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
YWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgJGFjX3Byb2c7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09D
QU1MT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9D
QytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl
Ci0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KKyAgaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQog
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFU
SApAQCAtNTQwOCw3ICsyODgzLDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19wcm9nIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkK
QEAgLTU0MTYsMTkgKzI4OTEsMjMgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAK
LWZpCi1maQotYWNfY3RfT0NBTUxPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQKLWlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE9QVCIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N0X09DQU1MT1BUIiA+JjY7IH0KK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAi
JGFjX2N0X0NDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0g
IGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFQiID0geDsgdGhlbgotICAgIE9DQU1MT1BUPSJubyIK
KworICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCitkb25lCisKKyAgaWYgdGVzdCAieCRh
Y19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKICAgZWxzZQogICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KIHllczopCkBAIC01NDM2LDM5NiArMjkxNSw2NDkg
QEAgeWVzOikKICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7
OwogZXNhYwotICAgIE9DQU1MT1BUPSRhY19jdF9PQ0FNTE9QVAorICAgIENDPSRhY19jdF9DQwog
ICBmaQotZWxzZQotICBPQ0FNTE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFQiCiBmaQogCi0gICAg
IE9DQU1MQkVTVD1ieXRlCi0gICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCi0J
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBDYW5ub3Qg
ZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mNQotJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0
aW9uIG9ubHkuIiA+JjI7fQotICAgICBlbHNlCi0JVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAotCWlmIHRlc3QgIiRUTVBW
RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCi0JICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2Nh
bWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKLSRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJz
IGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KLQkgICAgT0NBTUxPUFQ9
bm8KLQllbHNlCi0JICAgIE9DQU1MQkVTVD1vcHQKK2ZpCisKKwordGVzdCAteiAiJENDIiAmJiB7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFj
X3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KK2FzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQ
QVRICitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0K
KworIyBQcm92aWRlIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgorJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIg
dmVyc2lvbiIgPiY1CitzZXQgWCAkYWNfY29tcGlsZQorYWNfY29tcGlsZXI9JDIKK2ZvciBhY19v
cHRpb24gaW4gLS12ZXJzaW9uIC12IC1WIC1xdmVyc2lvbjsgZG8KKyAgeyB7IGFjX3RyeT0iJGFj
X2NvbXBpbGVyICRhY19vcHRpb24gPiY1IgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwg
KlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFj
X3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cisg
IChldmFsICIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgorICBh
Y19zdGF0dXM9JD8KKyAgaWYgdGVzdCAtcyBjb25mdGVzdC5lcnI7IHRoZW4KKyAgICBzZWQgJzEw
YVwKKy4uLiByZXN0IG9mIHN0ZGVyciBvdXRwdXQgZGVsZXRlZCAuLi4KKyAgICAgICAgIDEwcScg
Y29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICBm
aQorICBybSAtZiBjb25mdGVzdC5lcjEgY29uZnRlc3QuZXJyCisgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9Citkb25lCisKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAg
OworICByZXR1cm4gMDsKK30KK19BQ0VPRgorYWNfY2xlYW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5f
ZmlsZXMKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5fZmlsZXMgYS5vdXQgYS5vdXQuZFNZTSBh
LmV4ZSBiLm91dCIKKyMgVHJ5IHRvIGNyZWF0ZSBhbiBleGVjdXRhYmxlIHdpdGhvdXQgLW8gZmly
c3QsIGRpc3JlZ2FyZCBhLm91dC4KKyMgSXQgd2lsbCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBj
b21waWxlcnMsIGFuZCBmaW5kaW5nIG91dCBhbiBpbnR1aXRpb24KKyMgb2YgZXhlZXh0LgoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRo
ZSBDIGNvbXBpbGVyIHdvcmtzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhl
IEMgY29tcGlsZXIgd29ya3MuLi4gIiA+JjY7IH0KK2FjX2xpbmtfZGVmYXVsdD1gJGFzX2VjaG8g
IiRhY19saW5rIiB8IHNlZCAncy8gLW8gKmNvbmZ0ZXN0W14gXSovLydgCisKKyMgVGhlIHBvc3Np
YmxlIG91dHB1dCBmaWxlczoKK2FjX2ZpbGVzPSJhLm91dCBjb25mdGVzdC5leGUgY29uZnRlc3Qg
YS5leGUgYV9vdXQuZXhlIGIub3V0IGNvbmZ0ZXN0LioiCisKK2FjX3JtZmlsZXM9Citmb3IgYWNf
ZmlsZSBpbiAkYWNfZmlsZXMKK2RvCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQg
fCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8
ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7CisgICAgKiApIGFjX3Jt
ZmlsZXM9IiRhY19ybWZpbGVzICRhY19maWxlIjs7CisgIGVzYWMKK2RvbmUKK3JtIC1mICRhY19y
bWZpbGVzCisKK2lmIHsgeyBhY190cnk9IiRhY19saW5rX2RlZmF1bHQiCitjYXNlICIoKCRhY190
cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAq
KSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3Ry
eV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rX2RlZmF1bHQiKSAyPiY1CisgIGFjX3N0
YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6CisgICMgQXV0
b2NvbmYtMi4xMyBjb3VsZCBzZXQgdGhlIGFjX2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgor
IyBTbyBpZ25vcmUgYSB2YWx1ZSBvZiBgbm8nLCBvdGhlcndpc2UgdGhpcyB3b3VsZCBsZWFkIHRv
IGBFWEVFWFQgPSBubycKKyMgaW4gYSBNYWtlZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUg
YWNfY3ZfZXhlZXh0IGlmIGl0IHdhcyBjYWNoZWQsCisjIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNo
b3J0LWNpcmN1aXQgdGhpcyB0ZXN0IGZvciBjb21waWxlcnMgdW5rbm93biB0bworIyBBdXRvY29u
Zi4KK2ZvciBhY19maWxlIGluICRhY19maWxlcyAnJworZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUi
IHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2Zm
IHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwg
Ki5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApCisJOzsKKyAgICBbYWJdLm91dCApCisJIyBX
ZSBmb3VuZCB0aGUgZGVmYXVsdCBleGVjdXRhYmxlLCBidXQgZXhlZXh0PScnIGlzIG1vc3QKKwkj
IGNlcnRhaW5seSByaWdodC4KKwlicmVhazs7CisgICAgKi4qICkKKwlpZiB0ZXN0ICIke2FjX2N2
X2V4ZWV4dCtzZXR9IiA9IHNldCAmJiB0ZXN0ICIkYWNfY3ZfZXhlZXh0IiAhPSBubzsKKwl0aGVu
IDo7IGVsc2UKKwkgICBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4u
KlwpJ2AKIAlmaQotICAgICBmaQorCSMgV2Ugc2V0IGFjX2N2X2V4ZWV4dCBoZXJlIGJlY2F1c2Ug
dGhlIGxhdGVyIHRlc3QgZm9yIGl0IGlzIG5vdAorCSMgc2FmZTogY3Jvc3MgY29tcGlsZXJzIG1h
eSBub3QgYWRkIHRoZSBzdWZmaXggaWYgZ2l2ZW4gYW4gYC1vJworCSMgYXJndW1lbnQsIHNvIHdl
IG1heSBuZWVkIHRvIGtub3cgaXQgYXQgdGhhdCBwb2ludCBhbHJlYWR5LgorCSMgRXZlbiBpZiB0
aGlzIHNlY3Rpb24gbG9va3MgY3J1ZnR5OiBpdCBoYXMgdGhlIGFkdmFudGFnZSBvZgorCSMgYWN0
dWFsbHkgd29ya2luZy4KKwlicmVhazs7CisgICAgKiApCisJYnJlYWs7OworICBlc2FjCitkb25l
Cit0ZXN0ICIkYWNfY3ZfZXhlZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KKworZWxzZQorICBh
Y19maWxlPScnCitmaQoraWYgdGVzdCAteiAiJGFjX2ZpbGUiOyB0aGVuIDoKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CiskYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUK
K3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworeyB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciA3
NyAiQyBjb21waWxlciBjYW5ub3QgY3JlYXRlIGV4ZWN1dGFibGVzCitTZWUgXGBjb25maWcubG9n
JyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAi
eWVzIiA+JjY7IH0KK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZSIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5h
bWUuLi4gIiA+JjY7IH0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFjX2ZpbGUiID4mNjsgfQorYWNfZXhl
ZXh0PSRhY19jdl9leGVleHQKKworcm0gLWYgLXIgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25m
dGVzdCRhY19jdl9leGVleHQgYi5vdXQKK2FjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19z
YXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBzdWZmaXggb2YgZXhlY3V0YWJsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1
ZmZpeCBvZiBleGVjdXRhYmxlcy4uLiAiID4mNjsgfQoraWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsi
CitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89
XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5
X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCisk
YXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQor
ICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
XCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgor
ICAjIElmIGJvdGggYGNvbmZ0ZXN0LmV4ZScgYW5kIGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAo
d2VsbCwgb2JzZXJ2YWJsZSkKKyMgY2F0Y2ggYGNvbmZ0ZXN0LmV4ZScuICBGb3IgaW5zdGFuY2Ug
d2l0aCBDeWd3aW4sIGBscyBjb25mdGVzdCcgd2lsbAorIyB3b3JrIHByb3Blcmx5IChpLmUuLCBy
ZWZlciB0byBgY29uZnRlc3QuZXhlJyksIHdoaWxlIGl0IHdvbid0IHdpdGgKKyMgYHJtJy4KK2Zv
ciBhY19maWxlIGluIGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBjb25mdGVzdC4qOyBkbworICB0ZXN0
IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFj
X2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICou
YmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKKyAgICAqLiog
KSBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKKwkgIGJy
ZWFrOzsKKyAgICAqICkgYnJlYWs7OworICBlc2FjCitkb25lCitlbHNlCisgIHsgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5f
ZXJyb3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBleGVjdXRhYmxlczogY2Fubm90IGNv
bXBpbGUgYW5kIGxpbmsKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElO
RU5PIiA1IDsgfQorZmkKK3JtIC1mIGNvbmZ0ZXN0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dAoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9leGVl
eHQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9leGVleHQiID4mNjsgfQogCitybSAtZiBjb25mdGVz
dC4kYWNfZXh0CitFWEVFWFQ9JGFjX2N2X2V4ZWV4dAorYWNfZXhlZXh0PSRFWEVFWFQKK2NhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKyNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgpCit7CitGSUxFICpmID0gZm9w
ZW4gKCJjb25mdGVzdC5vdXQiLCAidyIpOworIHJldHVybiBmZXJyb3IgKGYpIHx8IGZjbG9zZSAo
ZikgIT0gMDsKIAorICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCithY19jbGVhbl9maWxlcz0i
JGFjX2NsZWFuX2ZpbGVzIGNvbmZ0ZXN0Lm91dCIKKyMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIg
cHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwgZWl0aGVyCisjIHRoZSBj
b21waWxlciBpcyBicm9rZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNv
bXBpbGluZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBj
b21waWxpbmcuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiRjcm9zc19jb21waWxpbmciICE9IHllczsg
dGhlbgorICB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwi
KiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hv
PSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4m
NQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVz
dCAkYWNfc3RhdHVzID0gMDsgfQorICBpZiB7IGFjX3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVl
eHQnCisgIHsgeyBjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNf
dHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2
YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9l
Y2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY190cnki
KSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsg
fTsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGluZz1ubworICBlbHNlCisgICAgaWYgdGVzdCAiJGNy
b3NzX2NvbXBpbGluZyIgPSBtYXliZTsgdGhlbgorCWNyb3NzX2NvbXBpbGluZz15ZXMKKyAgICBl
bHNlCisJeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBp
biBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdk
JzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biBDIGNvbXBpbGVkIHByb2dyYW1z
LgorSWYgeW91IG1lYW50IHRvIGNyb3NzIGNvbXBpbGUsIHVzZSBcYC0taG9zdCcuCitTZWUgXGBj
b25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KKyAgICBmaQorICBm
aQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
Y3Jvc3NfY29tcGlsaW5nIiA+JjUKKyRhc19lY2hvICIkY3Jvc3NfY29tcGlsaW5nIiA+JjY7IH0K
IAotICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0Ci0gICAgIGlmIHRlc3QgLW4gIiRhY190
b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rv
b2xfcHJlZml4fW9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdDsgYWNfd29yZD0kMgot
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxDRE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoK
K3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNvbmZ0ZXN0Lm91
dAorYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmls
ZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zfb2JqZXh0K3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1M
Q0RPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiRPQ0FNTENET1RPUFQi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRh
c19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RP
UFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKKyAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLwogCi1maQotZmkKLU9DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RP
UFQKLWlmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKLSRhc19l
Y2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9
Ci1maQoraW50CittYWluICgpCit7CiAKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorcm0g
LWYgY29uZnRlc3QubyBjb25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgor
Y2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwk
YWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9l
Y2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFz
X2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUK
KyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoK
KyAgZm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8K
KyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRhY19maWxlIGluCisg
ICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAq
LmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAgICAqKSBhY19jdl9v
YmpleHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAgICBicmVhazs7Cisg
IGVzYWMKK2RvbmUKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2Fz
OiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CiAKK3sgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5f
ZXJyb3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBj
b21waWxlCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7
IH0KIGZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCi0gIGFj
X2N0X09DQU1MQ0RPVE9QVD0kT0NBTUxDRE9UT1BUCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAib2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgb2NhbWxjLm9wdDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By
b2dfYWNfY3RfT0NBTUxDRE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKK3JtIC1mIGNvbmZ0ZXN0
LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb2JqZXh0IiA+JjUKKyRhc19lY2hv
ICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KK09CSkVYVD0kYWNfY3Zfb2JqZXh0CithY19vYmpleHQ9
JE9CSkVYVAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJfZ251K3NldH0iID0gc2V0OyB0aGVu
IDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9
IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgot
ZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBp
biAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5vcHQiCi0gICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3Nh
dmVfSUZTCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KIAotZmkKLWZpCi1hY19jdF9PQ0FNTENET1RPUFQ9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUCi1pZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BU
IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N0X09DQU1MQ0RPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MQ0RPVE9Q
VCIgPiY2OyB9CitpbnQKK21haW4gKCkKK3sKKyNpZm5kZWYgX19HTlVDX18KKyAgICAgICBjaG9r
ZSBtZQorI2VuZGlmCisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jb21waWxlcl9nbnU9eWVzCiBlbHNl
Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorICBhY19jb21waWxlcl9nbnU9bm8KIGZpCitybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQK
K2FjX2N2X2NfY29tcGlsZXJfZ251PSRhY19jb21waWxlcl9nbnUKIAotICBpZiB0ZXN0ICJ4JGFj
X2N0X09DQU1MQ0RPVE9QVCIgPSB4OyB0aGVuCi0gICAgT0NBTUxDRE9UT1BUPSJubyIKLSAgZWxz
ZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAi
JGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FNTENE
T1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAotICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQor
JGFzX2VjaG8gIiRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21w
aWxlcl9nbnUgPSB5ZXM7IHRoZW4KKyAgR0NDPXllcwogZWxzZQotICBPQ0FNTENET1RPUFQ9IiRh
Y19jdl9wcm9nX09DQU1MQ0RPVE9QVCIKKyAgR0NDPQogZmkKLQotICAgICBpZiB0ZXN0ICIkT0NB
TUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCi0JVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8
IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKLQlpZiB0ZXN0ICIkVE1Q
VkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgotCSAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j
YW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKLSRhc19lY2hvICJ2ZXJzaW9ucyBkaWZm
ZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsgfQotCWVsc2UKLQkg
ICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKLQlmaQotICAgICBmaQotCi0gICAgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sb3B0Lm9wdAotICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVu
Ci0JaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQor
YWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgotICBh
Y19jdl9wcm9nX09DQU1MT1BURE9UT1BUPSIkT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJHthY190b29s
X3ByZWZpeH1vY2FtbG9wdC5vcHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJl
YWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCisgIGFjX3NhdmVfY193
ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNfY193ZXJyb3JfZmxhZz15ZXMKKyAg
IGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIKKyAgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotZmkK
LWZpCi1PQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAotaWYgdGVzdCAt
biAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKLSRhc19lY2hvICIkT0NB
TUxPUFRET1RPUFQiID4mNjsgfQoraW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9wcm9nX2NjX2c9eWVzCiBlbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKKyAg
Q0ZMQUdTPSIiCisgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKK2ludAorbWFpbiAoKQorewogCi1maQotaWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCi0gIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
Im9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTE9QVERPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9Q
VCI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1M
T1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRv
Ci0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxPUFRET1RPUFQ9Im9jYW1sb3B0Lm9wdCIKLSAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMK
KyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJy
b3JfZmxhZworCSBDRkxBR1M9Ii1nIgorCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQorewog
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRM
SU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19nPXllcwogZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAogZmkKLWFjX2N0
X09DQU1MT1BURE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUCi1pZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNQot
JGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNo
byAibm8iID4mNjsgfQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CiBmaQotCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFRET1RP
UFQiID0geDsgdGhlbgotICAgIE9DQU1MT1BURE9UT1BUPSJubyIKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgYWNfY193ZXJy
b3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQoraWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9
IHNldDsgdGhlbgorICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCitlbGlmIHRlc3QgJGFjX2N2X3By
b2dfY2NfZyA9IHllczsgdGhlbgorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENG
TEFHUz0iLWcgLU8yIgogICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29s
X3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7
OwotZXNhYwotICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERPVE9QVAorICAgIENG
TEFHUz0iLWciCiAgIGZpCiBlbHNlCi0gIE9DQU1MT1BURE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FN
TE9QVERPVE9QVCIKLWZpCi0KLQlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRo
ZW4KLQkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2
ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCi0JICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIk
T0NBTUxWRVJTSU9OIiA7IHRoZW4KLQkgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9w
dC5vcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbiBkaWZmZXJzIGZyb20gb2Nh
bWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9Ci0JICAgZWxzZQotCSAgICAgIE9D
QU1MT1BUPSRPQ0FNTE9QVERPVE9QVAotCSAgIGZpCi0gICAgICAgIGZpCi0gICAgIGZpCi0KLQor
ICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisg
ICAgQ0ZMQUdTPQogICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jdl9wcm9nX2NjX2M4OT1u
bworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNs
dWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0
Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1
LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVmIHsgaW50IHg7IH07CitGSUxFICogKCpy
Y3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOworc3RhdGljIGNoYXIg
KmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBpbnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07
Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIgKipw
LCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3QgdjsKKyAgdmFfc3RhcnQgKHYscCk7Cisg
IHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZhX2VuZCAodik7CisgIHJldHVybiBzOwor
fQogCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21lIHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkg
ZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBu
b3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRzLgorICAgVGhlc2UgZG9uJ3QgcHJvdm9r
ZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCisg
ICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMgYW4gZXJyb3IsIHVudGlsIC1zdGQgaXMg
YWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gn
IGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisgICBhcnJheSBzaXplIGF0IGxlYXN0LiAg
SXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKKyAgIHRo
YXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2ludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcg
PT0gMCA/IDEgOiAtMV07CiAKKy8qIElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBk
ZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFyYW1ldGVycworICAgaW5zaWRlIHN0cmlu
Z3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLworI2RlZmluZSBGT08oeCkgJ3gnCitpbnQg
eGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6IC0xXTsKIAotICAjIGNoZWNraW5nIGZv
ciBvY2FtbCB0b3BsZXZlbAotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29s
X3ByZWZpeH1vY2FtbDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUwr
c2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQot
ICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUw9IiRPQ0FNTCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICitpbnQgdGVzdCAoaW50
IGksIGRvdWJsZSB4KTsKK3N0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Oworc3RydWN0IHMy
IHtpbnQgKCpmKSAoZG91YmxlIGEpO307CitpbnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJ
TEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCksIGludCwgaW50KTsKK2lu
dCBhcmdjOworY2hhciAqKmFyZ3Y7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBmIChlLCBhcmd2
LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwgYXJndiwgMSkgIT0gYXJndlsxXTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgorZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1x
bGFuZ2x2bD1hbnNpIC1zdGQgXAorCS1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19F
WFRFTlNJT05TX18iCiBkbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
LSAgICBhY19jdl9wcm9nX09DQU1MPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIgotICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKKyAgQ0M9IiRhY19zYXZlX0NDICRh
Y19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNf
Y3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIgJiYg
YnJlYWsKIGRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworcm0gLWYgY29uZnRlc3QuJGFj
X2V4dAorQ0M9JGFjX3NhdmVfQ0MKIAogZmkKLWZpCi1PQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAot
aWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MIiA+JjUKLSRhc19lY2hvICIkT0NBTUwiID4mNjsg
fQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyMgQUNfQ0FDSEVfVkFMCitjYXNlICJ4
JGFjX2N2X3Byb2dfY2NfYzg5IiBpbgorICB4KQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1CiskYXNfZWNobyAibm9u
ZSBuZWVkZWQiID4mNjsgfSA7OworICB4bm8pCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUKKyRhc19lY2hvICJ1bnN1
cHBvcnRlZCIgPiY2OyB9IDs7CisgICopCisgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODki
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9wcm9nX2NjX2M4OSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7
IH0gOzsKK2VzYWMKK2lmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6
CisKIGZpCiAKK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0n
JENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0n
JENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxl
cl9nbnUKIAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MIjsgdGhlbgotICBhY19j
dF9PQ0FNTD0kT0NBTUwKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWw7IGFj
X3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MK3NldH0iID0gc2V0
OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0UpLi4uICIgPiY2OyB9Citz
ZXQgeCAke01BS0UtbWFrZX0KK2FjX21ha2U9YCRhc19lY2hvICIkMiIgfCBzZWQgJ3MvKy9wL2c7
IHMvW15hLXpBLVowLTlfXS9fL2cnYAoraWYgZXZhbCAidGVzdCBcIlwke2FjX2N2X3Byb2dfbWFr
ZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgotICBh
Y19jdl9wcm9nX2FjX2N0X09DQU1MPSIkYWNfY3RfT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0ib2NhbWwiCi0gICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFz
X3NhdmVfSUZTCi0KLWZpCi1maQotYWNfY3RfT0NBTUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwK
LWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTCIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N0X09DQU1MIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQot
Ci0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUwiID0geDsgdGhlbgotICAgIE9DQU1MPSJubyIKLSAg
ZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczop
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKKyAgY2F0ID5jb25mdGVz
dC5tYWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAvYmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0k
KE1BS0UpPUBAQCUlJScKK19BQ0VPRgorIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtl
WzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtF
LW1ha2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBA
JSUlKikKKyAgICBldmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAq
KQorICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKIGVzYWMKLSAg
ICBPQ0FNTD0kYWNfY3RfT0NBTUwKLSAgZmkKK3JtIC1mIGNvbmZ0ZXN0Lm1ha2UKK2ZpCitpZiBl
dmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1
CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CiBlbHNlCi0gIE9DQU1MPSIkYWNf
Y3ZfcHJvZ19PQ0FNTCIKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgIFNFVF9NQUtFPSJNQUtF
PSR7TUFLRS1tYWtlfSIKIGZpCiAKLQotICAjIGNoZWNraW5nIGZvciBvY2FtbGRlcAotICBpZiB0
ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGRlcDsgYWNf
d29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxERVArc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorIyBGaW5kIGEgZ29vZCBpbnN0YWxsIHByb2dyYW0uICBXZSBwcmVmZXIgYSBDIHByb2dy
YW0gKGZhc3RlciksCisjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBhbm90aGVyLiAgQnV0
IGF2b2lkIHRoZSBicm9rZW4gb3IKKyMgaW5jb21wYXRpYmxlIHZlcnNpb25zOgorIyBTeXNWIC9l
dGMvaW5zdGFsbCwgL3Vzci9zYmluL2luc3RhbGwKKyMgU3VuT1MgL3Vzci9ldGMvaW5zdGFsbAor
IyBJUklYIC9zYmluL2luc3RhbGwKKyMgQUlYIC9iaW4vaW5zdGFsbAorIyBBbWlnYU9TIC9DL2lu
c3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxvcHB5IGRpc2NzCisjIEFJWCA0
IC91c3IvYmluL2luc3RhbGxic2QsIHdoaWNoIGRvZXNuJ3Qgd29yayB3aXRob3V0IGEgLWcgZmxh
ZworIyBBRlMgL3Vzci9hZnN3cy9iaW4vaW5zdGFsbCwgd2hpY2ggbWlzaGFuZGxlcyBub25leGlz
dGVudCBhcmdzCisjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRo
ZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCisjIE9TLzIncyBzeXN0ZW0gaW5zdGFsbCwgd2hp
Y2ggaGFzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc2VtYW50aWMKKyMgLi9pbnN0YWxsLCB3aGlj
aCBjYW4gYmUgZXJyb25lb3VzbHkgY3JlYXRlZCBieSBtYWtlIGZyb20gLi9pbnN0YWxsLnNoLgor
IyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZp
bGVzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwuLi4gIiA+JjY7IH0KK2lmIHRlc3QgLXogIiRJTlNU
QUxMIjsgdGhlbgoraWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIk
T0NBTUxERVAiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxERVA9IiRPQ0FNTERFUCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
IGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxk
ZXAiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQor
ICAgICMgQWNjb3VudCBmb3IgcGVvcGxlIHdobyBwdXQgdHJhaWxpbmcgc2xhc2hlcyBpbiBQQVRI
IGVsZW1lbnRzLgorY2FzZSAkYXNfZGlyLyBpbiAjKCgKKyAgLi8gfCAuLy8gfCAvW2NDXS8qIHwg
XAorICAvZXRjLyogfCAvdXNyL3NiaW4vKiB8IC91c3IvZXRjLyogfCAvc2Jpbi8qIHwgL3Vzci9h
ZnN3cy9iaW4vKiB8IFwKKyAgPzpbXFwvXW9zMltcXC9daW5zdGFsbFtcXC9dKiB8ID86W1xcL11P
UzJbXFwvXUlOU1RBTExbXFwvXSogfCBcCisgIC91c3IvdWNiLyogKSA7OworICAqKQorICAgICMg
T1NGMSBhbmQgU0NPIE9EVCAzLjAgaGF2ZSB0aGVpciBvd24gbmFtZXMgZm9yIGluc3RhbGwuCisg
ICAgIyBEb24ndCB1c2UgaW5zdGFsbGJzZCBmcm9tIE9TRiBzaW5jZSBpdCBpbnN0YWxscyBzdHVm
ZiBhcyByb290CisgICAgIyBieSBkZWZhdWx0LgorICAgIGZvciBhY19wcm9nIGluIGdpbnN0YWxs
IHNjb2luc3QgaW5zdGFsbDsgZG8KKyAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworCWlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCI7
IH07IHRoZW4KKwkgIGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCisJICAgIGdyZXAgZHNw
bXNnICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4K
KwkgICAgIyBBSVggaW5zdGFsbC4gIEl0IGhhcyBhbiBpbmNvbXBhdGlibGUgY2FsbGluZyBjb252
ZW50aW9uLgorCSAgICA6CisJICBlbGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCisJICAg
IGdyZXAgcHdwbHVzICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+
JjE7IHRoZW4KKwkgICAgIyBwcm9ncmFtLXNwZWNpZmljIGluc3RhbGwgc2NyaXB0IHVzZWQgYnkg
SFAgcHdwbHVzLS1kb24ndCB1c2UuCisJICAgIDoKKwkgIGVsc2UKKwkgICAgcm0gLXJmIGNvbmZ0
ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRlc3QuZGlyCisJICAgIGVjaG8gb25lID4gY29uZnRl
c3Qub25lCisJICAgIGVjaG8gdHdvID4gY29uZnRlc3QudHdvCisJICAgIG1rZGlyIGNvbmZ0ZXN0
LmRpcgorCSAgICBpZiAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgLWMgY29uZnRlc3Qu
b25lIGNvbmZ0ZXN0LnR3byAiYHB3ZGAvY29uZnRlc3QuZGlyIiAmJgorCSAgICAgIHRlc3QgLXMg
Y29uZnRlc3Qub25lICYmIHRlc3QgLXMgY29uZnRlc3QudHdvICYmCisJICAgICAgdGVzdCAtcyBj
b25mdGVzdC5kaXIvY29uZnRlc3Qub25lICYmCisJICAgICAgdGVzdCAtcyBjb25mdGVzdC5kaXIv
Y29uZnRlc3QudHdvCisJICAgIHRoZW4KKwkgICAgICBhY19jdl9wYXRoX2luc3RhbGw9IiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQgLWMiCisJICAgICAgYnJlYWsgMworCSAgICBmaQorCSAg
ZmkKKwlmaQorICAgICAgZG9uZQorICAgIGRvbmUKKyAgICA7OworZXNhYworCiAgIGRvbmUKIElG
Uz0kYXNfc2F2ZV9JRlMKIAorcm0gLXJmIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRl
c3QuZGlyCisKIGZpCisgIGlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9pbnN0YWxsK3NldH0iID0gc2V0
OyB0aGVuCisgICAgSU5TVEFMTD0kYWNfY3ZfcGF0aF9pbnN0YWxsCisgIGVsc2UKKyAgICAjIEFz
IGEgbGFzdCByZXNvcnQsIHVzZSB0aGUgc2xvdyBzaGVsbCBzY3JpcHQuICBEb24ndCBjYWNoZSBh
CisgICAgIyB2YWx1ZSBmb3IgSU5TVEFMTCB3aXRoaW4gYSBzb3VyY2UgZGlyZWN0b3J5LCBiZWNh
dXNlIHRoYXQgd2lsbAorICAgICMgYnJlYWsgb3RoZXIgcGFja2FnZXMgdXNpbmcgdGhlIGNhY2hl
IGlmIHRoYXQgZGlyZWN0b3J5IGlzCisgICAgIyByZW1vdmVkLCBvciBpZiB0aGUgdmFsdWUgaXMg
YSByZWxhdGl2ZSBuYW1lLgorICAgIElOU1RBTEw9JGFjX2luc3RhbGxfc2gKKyAgZmkKIGZpCi1P
Q0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAotaWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhl
bgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MREVQIiA+JjUKLSRhc19lY2hvICIkT0NBTUxERVAiID4mNjsgfQotZWxzZQotICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KLWZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJElOU1RBTEwiID4mNQorJGFzX2VjaG8gIiRJTlNUQUxMIiA+JjY7IH0KIAor
IyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1bk9TNCBzaCBtaXNoYW5kbGVzIGJyYWNlcyBpbiAke3Zh
ci12YWx9LgorIyBJdCB0aGlua3MgdGhlIGZpcnN0IGNsb3NlIGJyYWNlIGVuZHMgdGhlIHZhcmlh
YmxlIHN1YnN0aXR1dGlvbi4KK3Rlc3QgLXogIiRJTlNUQUxMX1BST0dSQU0iICYmIElOU1RBTExf
UFJPR1JBTT0nJHtJTlNUQUxMfScKIAotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1M
REVQIjsgdGhlbgotICBhY19jdF9PQ0FNTERFUD0kT0NBTUxERVAKLSAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbGRlcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxkZXA7IGFjX3dvcmQ9JDIKK3Rlc3QgLXogIiRJTlNUQUxM
X1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNU
QUxMX0RBVEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAiYmlzb24iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgorc2V0IGR1bW15IGJpc29uOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2Fj
X2N2X3BhdGhfQklTT04rc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCi0gIGFj
X2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9IiRhY19jdF9PQ0FNTERFUCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCisgIGNhc2UgJEJJU09OIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9w
YXRoX0JJU09OPSIkQklTT04iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSJvY2FtbGRlcCIKKyAg
ICBhY19jdl9wYXRoX0JJU09OPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTU4MzMsNTMgKzM1NjUs
MzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKKyAgOzsKK2VzYWMKIGZpCi1m
aQotYWNfY3RfT0NBTUxERVA9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVAKLWlmIHRlc3QgLW4g
IiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERFUCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0
X09DQU1MREVQIiA+JjY7IH0KK0JJU09OPSRhY19jdl9wYXRoX0JJU09OCitpZiB0ZXN0IC1uICIk
QklTT04iOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkQklTT04iID4mNQorJGFzX2VjaG8gIiRCSVNPTiIgPiY2OyB9CiBlbHNlCiAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAk
YXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9
IHg7IHRoZW4KLSAgICBPQ0FNTERFUD0ibm8iCi0gIGVsc2UKLSAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQotYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCi0gIGZp
Ci1lbHNlCi0gIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKLWZpCi0KIAotICAjIGNo
ZWNraW5nIGZvciBvY2FtbG1rdG9wCi0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRo
ZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
bWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgorIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJmbGV4Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBmbGV4OyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9GTEVY
K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UK
LSAgaWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxNS1RP
UD0iJE9DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQot
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRGTEVYIGluCisg
IFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0ZMRVg9IiRGTEVYIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8K
ICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCisgICAgYWNfY3ZfcGF0aF9G
TEVYPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTU4ODcsMzkgKzM2MDUsMzkgQEAgZG9uZQogICBk
b25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKKyAgOzsKK2VzYWMKIGZpCi1maQotT0NBTUxNS1RPUD0k
YWNfY3ZfcHJvZ19PQ0FNTE1LVE9QCi1pZiB0ZXN0IC1uICIkT0NBTUxNS1RPUCI7IHRoZW4KLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1L
VE9QIiA+JjUKLSRhc19lY2hvICIkT0NBTUxNS1RPUCIgPiY2OyB9CitGTEVYPSRhY19jdl9wYXRo
X0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQorJGFzX2VjaG8gIiRGTEVYIiA+
JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCiAKLWZpCi1pZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgotICBhY19jdF9PQ0FNTE1LVE9QPSRP
Q0FNTE1LVE9QCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta3RvcCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgb2NhbWxta3Rv
cDsgYWNfd29yZD0kMgorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwZXJsIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBwZXJsOyBhY193b3Jk
PSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QK3NldH0iID0gc2V0
OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QRVJMK3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0
X09DQU1MTUtUT1AiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0
X09DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRQRVJMIGluCisgIFtc
XC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1BFUkw9IiRQRVJMIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAg
SUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9wIgorICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh
ayAyCiAgIGZpCkBAIC01OTI3LDUzICszNjQ1LDQ2IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19z
YXZlX0lGUwogCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1BFUkwiICYmIGFjX2N2X3BhdGhfUEVS
TD0ibm8iCisgIDs7Citlc2FjCiBmaQotZmkKLWFjX2N0X09DQU1MTUtUT1A9JGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxNS1RPUAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCi0g
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Rf
T0NBTUxNS1RPUCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MTUtUT1AiID4mNjsgfQorUEVS
TD0kYWNfY3ZfcGF0aF9QRVJMCitpZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQRVJMIiA+JjUKKyRhc19l
Y2hvICIkUEVSTCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAot
ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MTUtUT1AiID0geDsgdGhlbgotICAgIE9DQU1MTUtUT1A9
Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBp
bgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
LSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwot
ICAgIE9DQU1MTUtUT1A9JGFjX2N0X09DQU1MTUtUT1AKLSAgZmkKLWVsc2UKLSAgT0NBTUxNS1RP
UD0iJGFjX2N2X3Byb2dfT0NBTUxNS1RPUCIKLWZpCiAKK2lmIHRlc3QgeCIke1BFUkx9IiA9PSB4
Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBwZXJsLCBwbGVh
c2UgaW5zdGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkeGFwaSIgPSAieHki
OyB0aGVuIDoKIAotICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCi0gIGlmIHRlc3QgLW4gIiRh
Y190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0k
MgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY3VybC1jb25maWciLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGN1cmwtY29uZmlnOyBh
Y193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0
OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9DVVJMK3NldH0iID0gc2V0OyB0aGVuIDoK
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1M
TUtMSUIiOyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxNS0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRDVVJMIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQor
ICBhY19jdl9wYXRoX0NVUkw9IiRDVVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwog
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sbWtsaWIiCisgICAgYWNfY3ZfcGF0aF9DVVJMPSIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAg
ZmkKQEAgLTU5ODEsMzkgKzM2OTIsNDQgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZT
CiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQ1VSTCIgJiYgYWNfY3ZfcGF0aF9DVVJMPSJubyIK
KyAgOzsKK2VzYWMKIGZpCi1maQotT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19PQ0FNTE1LTElCCi1p
ZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LTElCIiA+JjUKLSRhc19lY2hvICIkT0NB
TUxNS0xJQiIgPiY2OyB9CitDVVJMPSRhY19jdl9wYXRoX0NVUkwKK2lmIHRlc3QgLW4gIiRDVVJM
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENVUkwiID4mNQorJGFzX2VjaG8gIiRDVVJMIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hv
ICJubyIgPiY2OyB9CiBmaQogCiAKK2lmIHRlc3QgeCIke0NVUkx9IiA9PSB4Im5vIgordGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBjdXJsLWNvbmZpZywgcGxlYXNlIGlu
c3RhbGwgY3VybC1jb25maWciICIkTElORU5PIiA1CiBmaQotaWYgdGVzdCAteiAiJGFjX2N2X3By
b2dfT0NBTUxNS0xJQiI7IHRoZW4KLSAgYWNfY3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgotICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIK
KyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInhtbDItY29uZmlnIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB4bWwyLWNvbmZpZzsgYWNf
d29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQitzZXR9IiA9
IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfWE1MK3NldH0iID0gc2V0OyB0aGVu
IDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MTUtMSUIiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQj0iJGFj
X2N0X09DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQot
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBjYXNlICRYTUwgaW4KKyAg
W1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfWE1MPSIkWE1MIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAg
SUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE1LTElCPSJvY2FtbG1rbGliIgorICAgIGFjX2N2X3BhdGhfWE1MPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFr
IDIKICAgZmkKQEAgLTYwMjEsNDQgKzM3MzcsMzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3Nh
dmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWE1MIiAmJiBhY19jdl9wYXRoX1hNTD0i
bm8iCisgIDs7Citlc2FjCiBmaQotZmkKLWFjX2N0X09DQU1MTUtMSUI9JGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxNS0xJQgotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtMSUIiOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB
TUxNS0xJQiIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MTUtMSUIiID4mNjsgfQorWE1MPSRh
Y19jdl9wYXRoX1hNTAoraWYgdGVzdCAtbiAiJFhNTCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYTUwiID4mNQorJGFzX2VjaG8gIiRY
TUwiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVz
dCAieCRhY19jdF9PQ0FNTE1LTElCIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE1LTElCPSJubyIKLSAg
ZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczop
Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FN
TE1LTElCPSRhY19jdF9PQ0FNTE1LTElCCi0gIGZpCi1lbHNlCi0gIE9DQU1MTUtMSUI9IiRhY19j
dl9wcm9nX09DQU1MTUtMSUIiCisKK2lmIHRlc3QgeCIke1hNTH0iID09IHgibm8iCit0aGVuCisg
ICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIHhtbDItY29uZmlnLCBwbGVhc2UgaW5z
dGFsbCB4bWwyLWNvbmZpZyIgIiRMSU5FTk8iIDUKIGZpCiAKK2ZpCitpZiB0ZXN0ICJ4JG9jYW1s
dG9vbHMiID0gInh5IjsgdGhlbiA6CiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgICAg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sYwogICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0
aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft
bGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbGRvYzsgYWNfd29yZD0kMgorICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsg
YWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6
CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FN
TERPQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJE9DQU1MRE9DIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19PQ0FNTEM9IiRPQ0FNTEMiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgogZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFz
X2RpciBpbiAkUEFUSApAQCAtNjA2Nyw3ICszNzc4LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgotICAgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisg
ICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgogICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTYwNzcsMTAgKzM3ODgsMTAg
QEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MRE9DPSRhY19jdl9wcm9nX09DQU1M
RE9DCi1pZiB0ZXN0IC1uICIkT0NBTUxET0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxET0MiID4mNQotJGFzX2VjaG8gIiRP
Q0FNTERPQyIgPiY2OyB9CitPQ0FNTEM9JGFjX2N2X3Byb2dfT0NBTUxDCitpZiB0ZXN0IC1uICIk
T0NBTUxDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJE9DQU1MQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MQyIgPiY2OyB9CiBlbHNlCiAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
CiAkYXNfZWNobyAibm8iID4mNjsgfQpAQCAtNjA4OCwxNyArMzc5OSwxNyBAQCBmaQogCiAKIGZp
Ci1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERPQyI7IHRoZW4KLSAgYWNfY3RfT0NBTUxE
T0M9JE9DQU1MRE9DCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sZG9j
OyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEMiOyB0aGVuCisgIGFj
X2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxj
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2Ft
bGM7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DK3Nl
dH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMrc2V0
fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxET0M9IiRhY19jdF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxDPSIkYWNfY3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
IGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIg
aW4gJFBBVEgKQEAgLTYxMDcsNyArMzgxOCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAg
ICBhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSJvY2FtbGRvYyIKKyAgICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MQz0ib2NhbWxjIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFr
IDIKICAgZmkKQEAgLTYxMTcsMTcgKzM4MjgsMTcgQEAgSUZTPSRhc19zYXZlX0lGUwogCiBmaQog
ZmkKLWFjX2N0X09DQU1MRE9DPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCi1pZiB0ZXN0IC1u
ICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxET0MiID4mNQotJGFzX2VjaG8gIiRhY19j
dF9PQ0FNTERPQyIgPiY2OyB9CithY19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxD
CitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQyIgPiY1CiskYXNfZWNo
byAiJGFjX2N0X09DQU1MQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQog
ZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MRE9DIiA9IHg7IHRoZW4KLSAgICBPQ0FNTERP
Qz0ibm8iCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEM9
Im5vIgogICBlbHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBp
bgogeWVzOikKQEAgLTYxMzUsMjQgKzM4NDYsNDEgQEAgeWVzOikKICRhc19lY2hvICIkYXNfbWU6
IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxl
dCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7OwogZXNhYwotICAgIE9DQU1MRE9DPSRhY19j
dF9PQ0FNTERPQworICAgIE9DQU1MQz0kYWNfY3RfT0NBTUxDCiAgIGZpCiBlbHNlCi0gIE9DQU1M
RE9DPSIkYWNfY3ZfcHJvZ19PQ0FNTERPQyIKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMi
CiBmaQogCiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAotICBpZiB0ZXN0IC1uICIkYWNf
dG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190
b29sX3ByZWZpeH1vY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQ7IGFjX3dvcmQ9JDIK
KyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZFUlNJT049YCRP
Q0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKKyAgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZl
cnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAk
T0NBTUxWRVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAor
ICAgICBpZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRP
Q0FNTEMgLXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAn
IC1mIDRgCisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0
LiIgPiY1CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQu
IiA+JjY7IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQorJGFz
X2VjaG8gIk9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQorCisKKworCisg
ICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCiB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19PQ0FNTEJVSUxEK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgotICBh
Y19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgorICBhY19jdl9wcm9n
X09DQU1MT1BUPSIkT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgog
ZWxzZQogYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBp
biAkUEFUSApAQCAtNjE2MSw3ICszODg5LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAg
IGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkIgorICAg
IGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCiAgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjE3MSwxMCArMzg5OSwx
MCBAQCBJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCiBmaQotT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19P
Q0FNTEJVSUxECi1pZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KLSAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJVSUxEIiA+JjUKLSRh
c19lY2hvICIkT0NBTUxCVUlMRCIgPiY2OyB9CitPQ0FNTE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9Q
VAoraWYgdGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BUIiA+JjUKKyRhc19lY2hvICIkT0NB
TUxPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KQEAgLTYxODIsMTcg
KzM5MTAsMTcgQEAgZmkKIAogCiBmaQotaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxCVUlM
RCI7IHRoZW4KLSAgYWNfY3RfT0NBTUxCVUlMRD0kT0NBTUxCVUlMRAotICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIm9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MT1BUIjsgdGhlbgorICBhY19jdF9PQ0FNTE9QVD0kT0NBTUxPUFQK
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdCIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxvcHQ7IGFjX3dvcmQ9JDIK
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUK3NldH0iID0gc2V0OyB0
aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0i
JGFjX2N0X09DQU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFQ9IiRhY19jdF9PQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGly
IGluICRQQVRICkBAIC02MjAxLDcgKzM5MjksNyBAQCBkbwogICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl
bnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0g
ICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgorICAgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQog
ICAgIGJyZWFrIDIKICAgZmkKQEAgLTYyMTEsMTcgKzM5MzksMTcgQEAgSUZTPSRhc19zYXZlX0lG
UwogCiBmaQogZmkKLWFjX2N0X09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlM
RAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1
Ci0kYXNfZWNobyAiJGFjX2N0X09DQU1MQlVJTEQiID4mNjsgfQorYWNfY3RfT0NBTUxPUFQ9JGFj
X2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdF9PQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MT1BUIiA+JjY7IH0KIGVs
c2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUxCVUlMRCIgPSB4OyB0aGVuCi0gICAgT0NBTUxCVUlMRD0ibm8iCisgIGlmIHRlc3QgIngkYWNf
Y3RfT0NBTUxPUFQiID0geDsgdGhlbgorICAgIE9DQU1MT1BUPSJubyIKICAgZWxzZQogICAgIGNh
c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KIHllczopCkBAIC02MjI5LDQ0
ICszOTU3LDg5IEBAIHllczopCiAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CiBhY190b29sX3dh
cm5lZD15ZXMgOzsKIGVzYWMKLSAgICBPQ0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgICAg
T0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCiAgIGZpCiBlbHNlCi0gIE9DQU1MQlVJTEQ9IiRhY19j
dl9wcm9nX09DQU1MQlVJTEQiCisgIE9DQU1MT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCIKIGZp
CiAKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9ICJubyI7
IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6
IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUg
Y29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxP
UFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVz
dCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMg
ZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25z
IGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgICBP
Q0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCiAKLSAg
ICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6CiAKLSAgICAgICAgaWYgdGVzdCAi
eCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgogCi0gICAgICAgICAgICBhc19m
bl9lcnJvciAkPyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1s
IiAiJExJTkVOTyIgNQotZmkKLSAgICAgICAgb2NhbWx0b29scz0ibiIKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxjLm9wdAorICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVu
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGMu
b3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCisg
IGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIkT0NBTUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sYy5vcHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCitmaQorT0NBTUxDRE9U
T1BUPSRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9QVCI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRPQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTENET1RPUFQiID4mNjsgfQorZWxz
ZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKIAogZmkKLSMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgYmFzaDsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NB
TUxDRE9UT1BUIjsgdGhlbgorICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RPVE9QVAorICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIK
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0JBU0grc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVz
dCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJEJBU0ggaW4KLSAgW1xc
L10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQkFTSD0iJEJBU0giICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTENE
T1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSIkYWNfY3RfT0NB
TUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
QkFTSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MQ0RPVE9QVD0ib2NhbWxjLm9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAg
ICBicmVhayAyCiAgIGZpCkBAIC02Mjc0LDU2ICs0MDQ3LDYzIEBAIGRvbmUKICAgZG9uZQogSUZT
PSRhc19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3Bh
dGhfQkFTSD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotQkFTSD0kYWNfY3ZfcGF0aF9CQVNICi1pZiB0
ZXN0IC1uICIkQkFTSCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRCQVNIIiA+JjUKLSRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitmaQor
YWNfY3RfT0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFz
X2VjaG8gIiRhY19jdF9PQ0FNTENET1RPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5v
IiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7QkFTSH0iID09IHgibm8iCi10aGVuCi0gICAg
YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2gi
ICIkTElORU5PIiA1CisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDRE9UT1BUIiA9IHg7IHRoZW4K
KyAgICBPQ0FNTENET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5n
OiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGgg
aG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2Fy
bmVkPXllcyA7OworZXNhYworICAgIE9DQU1MQ0RPVE9QVD0kYWNfY3RfT0NBTUxDRE9UT1BUCisg
IGZpCitlbHNlCisgIE9DQU1MQ0RPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUIgogZmkK
LWlmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhlbiA6Ci0KLSAgICBpZiBlY2hvICIk
UFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CiAKLSAgICAgICAgUFlUSE9OUEFUSD0kUFlU
SE9OCi0gICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgIGlmIHRlc3Qg
IiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BU
IC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3Qg
IiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZy
b20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25z
IGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9CisJZWxz
ZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCiAKLWVsaWYgdGVzdCAt
eiAiJFBZVEhPTiI7IHRoZW4gOgotICBQWVRIT049InB5dGhvbiIKLWVsc2UKLSAgYXNfZm5fZXJy
b3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1dGUgcGF0aCIgIiRM
SU5FTk8iIDUKLWZpCi0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAkUFlUSE9O
OyBhY193b3JkPSQyCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0
ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl
Zml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
K3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgogeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p
ZiB0ZXN0ICIke2FjX2N2X3BhdGhfUFlUSE9OUEFUSCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0
ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRQWVRIT05QQVRIIGluCi0g
IFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9IiRQWVRIT05QQVRI
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAg
KikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1u
ICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiRP
Q0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCith
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRI
CiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9w
YXRoX1BZVEhPTlBBVEg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3Zf
cHJvZ19PQ0FNTE9QVERPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiCiAgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjMzMSw2MiArNDEx
MSwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgotICA7Owot
ZXNhYwogZmkKLVBZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAotaWYgdGVzdCAtbiAi
JFBZVEhPTlBBVEgiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1Ci0kYXNfZWNobyAiJFBZVEhPTlBBVEgiID4m
NjsgfQorZmkKK09DQU1MT1BURE9UT1BUPSRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0
ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8g
IiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQog
ZmkKIAogCi1pZiB0ZXN0IHgiJHtQWVRIT05QQVRIfSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19m
bl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgJFBZVEhPTiwgcGxlYXNlIGluc3RhbGwgJFBZVEhP
TiIgIiRMSU5FTk8iIDUKLWZpCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgcHl0aG9uIHZlcnNpb24gPj0gMi4zICIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgcHl0aG9uIHZlcnNpb24gPj0gMi4zIC4uLiAiID4mNjsgfQotYCRQ
WVRIT04gLWMgJ2ltcG9ydCBzeXM7IHN5cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAo
MiwgMykiKSknYAotaWYgdGVzdCAiJD8iICE9ICIwIgotdGhlbgotICAgIHB5dGhvbl92ZXJzaW9u
PWAkUFlUSE9OIC1WIDI+JjFgCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci0gICAgYXNfZm5f
ZXJyb3IgJD8gIiRweXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZl
cnNpb24gaXMgMi4zIiAiJExJTkVOTyIgNQotZWxzZQotICAgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIgPiY2
OyB9CiBmaQotCi1hY19wcmV2aW91c19jcHBmbGFncz0kQ1BQRkxBR1MKLWFjX3ByZXZpb3VzX2xk
ZmxhZ3M9JExERkxBR1MKLWFjX3B5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1jICdpbXBvcnQgZGlz
dHV0aWxzLnN5c2NvbmZpZzsgXAotICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2Nv
bmZpZ192YXIoIlZFUlNJT04iKSdgCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRQWVRI
T04tY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBk
dW1teSAkUFlUSE9OLWNvbmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2df
T0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BURE9UT1BUPSRPQ0FNTE9QVERP
VE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Lm9wdCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxvcHQub3B0
OyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9weWNvbmZpZytzZXR9IiA9IHNl
dDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBj
YXNlICRweWNvbmZpZyBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9weWNv
bmZpZz0iJHB5Y29uZmlnIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg
cGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZT
CiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX3B5Y29uZmlnPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9
Im9jYW1sb3B0Lm9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAg
IGZpCkBAIC02Mzk0LDEyNyArNDE1MSw2OCBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9J
RlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9weWNvbmZpZyIgJiYgYWNfY3ZfcGF0aF9weWNv
bmZpZz0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotcHljb25maWc9JGFjX2N2X3BhdGhfcHljb25maWcK
LWlmIHRlc3QgLW4gIiRweWNvbmZpZyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRweWNvbmZpZyIgPiY1Ci0kYXNfZWNobyAiJHB5Y29u
ZmlnIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0
X09DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4m
NjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiRw
eWNvbmZpZyIgPT0geCJubyI7IHRoZW4gOgotCi0gICAgICAgIENQUEZMQUdTPSIkQ0ZMQUdTIGAk
UFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgICAgICBwcmludCAi
LUkiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiSU5DTFVERVBZIiknYCIK
LSAgICBDUFBGTEFHUz0iJENQUEZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5
c2NvbmZpZzsgXAotICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdf
dmFyKCJDRkxBR1MiKSdgIgotICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBv
cnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29u
ZmlnLmdldF9jb25maWdfdmFyKCJMSUJTIiknYCIKLSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZ
VEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgZGlz
dHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiU1lTTElCUyIpJ2AiCi0gICAgTERGTEFH
Uz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCi0g
ICAgICAgIHByaW50ICItTCIgKyBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBs
YXRfc3BlY2lmaWM9MSxcCi0gICAgICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidgIgot
ICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2Nv
bmZpZzsgXAotICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFy
KCJMSU5LRk9SU0hBUkVEIiknYCIKLSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAn
aW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5
c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTERGTEFHUyIpJ2AiCi0KLWVsc2UKLQotICAgICAgICBD
UFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTi1jb25maWcgLS1jZmxhZ3NgIgotICAgIExERkxBR1M9
IiRMREZMQUdTIGAkUFlUSE9OLWNvbmZpZyAtLWxkZmxhZ3NgIgotCi1maQotCi1hY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiUHl0aG9uLmgiICJhY19jdl9oZWFkZXJfUHl0
aG9uX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX1B5
dGhvbl9oIiA9IHgiInllczsgdGhlbiA6Ci0KKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERP
VE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg
PiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRh
Y19jdF9PQ0FNTE9QVERPVE9QVAorICBmaQogZWxzZQotICBhc19mbl9lcnJvciAkPyAiVW5hYmxl
IHRvIGZpbmQgUHl0aG9uIGRldmVsb3BtZW50IGhlYWRlcnMiICIkTElORU5PIiA1CisgIE9DQU1M
T1BURE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVCIKIGZpCiAKKwlpZiB0ZXN0ICIk
T0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRE
T1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAg
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbiBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIgPiY1CiskYXNfZWNo
byAidmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLiIg
PiY2OyB9CisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZp
CisgICAgICAgIGZpCisgICAgIGZpCiAKLWFzX2FjX0xpYj1gJGFzX2VjaG8gImFjX2N2X2xpYl9w
eXRob24kYWNfcHl0aG9uX3ZlcnNpb24nJ19QeUFyZ19QYXJzZVR1cGxlIiB8ICRhc190cl9zaGAK
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIFB5
QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9u
X3ZlcnNpb24uLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRlc3QgXCJcJHskYXNfYWNfTGliK3NldH1c
IiIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBh
Y19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVy
c2lvbiAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwg
cHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWln
aHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0
cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3Bs
dXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgUHlBcmdfUGFyc2VUdXBsZSAoKTsKLWlu
dAotbWFpbiAoKQotewotcmV0dXJuIFB5QXJnX1BhcnNlVHVwbGUgKCk7Ci0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAg
ZXZhbCAiJGFzX2FjX0xpYj15ZXMiCi1lbHNlCi0gIGV2YWwgIiRhc19hY19MaWI9bm8iCi1maQot
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlMKLWZpCi1ldmFsIGFjX3Jlcz1cJCRhc19hY19MaWIKLQkgICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8g
IiRhY19yZXMiID4mNjsgfQotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19MaWIiXCIgPSB4Inll
cyI7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNo
byAiSEFWRV9MSUJweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iIHwgJGFzX3RyX2NwcGAgMQotX0FD
RU9GCi0KLSAgTElCUz0iLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24gJExJQlMiCiAKLWVsc2UK
LSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgcHl0aG9uIGRldmVs
b3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1Ci1maQorICBmaQogCi1DUFBGTEFHUz0kYWNfcHJl
dmlvdXNfY3BwZmxhZ3MKLUxETEZBR1M9JGFjX3ByZXZpb3VzX2xkZmxhZ3MKIAogCi1maQotIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIKKyAgIyBj
aGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hv
X24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9w
YXRoX1hHRVRURVhUK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P
Q0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGNhc2UgJFhHRVRURVhUIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9w
YXRoX1hHRVRURVhUPSIkWEdFVFRFWFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FN
TD0iJE9DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRv
CiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhf
WEdFVFRFWFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19P
Q0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
ICAgICBicmVhayAyCiAgIGZpCkBAIC02NTIyLDQ0ICs0MjIwLDM5IEBAIGRvbmUKICAgZG9uZQog
SUZTPSRhc19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1hHRVRURVhUIiAmJiBh
Y19jdl9wYXRoX1hHRVRURVhUPSJubyIKLSAgOzsKLWVzYWMKIGZpCi1YR0VUVEVYVD0kYWNfY3Zf
cGF0aF9YR0VUVEVYVAotaWYgdGVzdCAtbiAiJFhHRVRURVhUIjsgdGhlbgotICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhHRVRURVhUIiA+JjUKLSRh
c19lY2hvICIkWEdFVFRFWFQiID4mNjsgfQorZmkKK09DQU1MPSRhY19jdl9wcm9nX09DQU1MCitp
ZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkT0NBTUwiID4mNQorJGFzX2VjaG8gIiRPQ0FNTCIgPiY2OyB9
CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1pZiB0ZXN0IHgiJHtYR0VU
VEVYVH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k
IHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIgIiRMSU5FTk8iIDUKIGZpCi0jIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGFzODY7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRh
Y19jdl9wcm9nX09DQU1MIjsgdGhlbgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWw7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19j
dl9wYXRoX0FTODYrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj
X2N0X09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKIGVsc2UKLSAgY2FzZSAkQVM4NiBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3Zf
cGF0aF9BUzg2PSIkQVM4NiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MPSIkYWNfY3RfT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgor
ZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBp
biAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAg
YWNfY3ZfcGF0aF9BUzg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAg
IGJyZWFrIDIKICAgZmkKQEAgLTY1NjcsNDQgKzQyNjAsNTMgQEAgZG9uZQogICBkb25lCiBJRlM9
JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQVM4NiIgJiYgYWNfY3ZfcGF0
aF9BUzg2PSJubyIKLSAgOzsKLWVzYWMKIGZpCi1BUzg2PSRhY19jdl9wYXRoX0FTODYKLWlmIHRl
c3QgLW4gIiRBUzg2IjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJEFTODYiID4mNQotJGFzX2VjaG8gIiRBUzg2IiA+JjY7IH0KK2ZpCith
Y19jdF9PQ0FNTD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N0X09DQU1MIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUwiID4mNjsgfQog
ZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7QVM4Nn0i
ID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGFzODYs
IHBsZWFzZSBpbnN0YWxsIGFzODYiICIkTElORU5PIiA1CisgIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUwiID0geDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhl
ZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2lu
ZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190
b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwKKyAgZmkKK2Vs
c2UKKyAgT0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgogZmkKLSMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAibGQ4NiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z
ZXQgZHVtbXkgbGQ4NjsgYWNfd29yZD0kMgorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAK
KyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxk
ZXA7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0xEODYrc2V0fSIgPSBzZXQ7
IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MREVQK3NldH0iID0gc2V0OyB0aGVu
IDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkTEQ4NiBpbgot
ICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9MRDg2PSIkTEQ4NiIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1MREVQ
IjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9MRDg2PSIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxkZXAiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAt
NjYxMiw0NCArNDMxNCwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0
ZXN0IC16ICIkYWNfY3ZfcGF0aF9MRDg2IiAmJiBhY19jdl9wYXRoX0xEODY9Im5vIgotICA7Owot
ZXNhYwogZmkKLUxEODY9JGFjX2N2X3BhdGhfTEQ4NgotaWYgdGVzdCAtbiAiJExEODYiOyB0aGVu
Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkTEQ4
NiIgPiY1Ci0kYXNfZWNobyAiJExEODYiID4mNjsgfQorZmkKK09DQU1MREVQPSRhY19jdl9wcm9n
X09DQU1MREVQCitpZiB0ZXN0IC1uICIkT0NBTUxERVAiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxERVAiID4mNQorJGFzX2Vj
aG8gIiRPQ0FNTERFUCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkK
IAogCi1pZiB0ZXN0IHgiJHtMRDg2fSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19mbl9lcnJvciAk
PyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGluc3RhbGwgbGQ4NiIgIiRMSU5FTk8iIDUK
IGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJjYyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgYmNjOyBhY193b3JkPSQyCitpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1M
REVQCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3Jk
PSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYg
dGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MREVQK3NldH0iID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkQkNDIGluCi0gIFtcXC9d
KiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0JDQz0iJEJDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MREVQIjsg
dGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxERVAiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZl
X0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9CQ0M9IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0ib2NhbWxk
ZXAiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjY1
NywyODMgKzQzNTQsMjQxIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi0gIHRl
c3QgLXogIiRhY19jdl9wYXRoX0JDQyIgJiYgYWNfY3ZfcGF0aF9CQ0M9Im5vIgotICA7OwotZXNh
YwogZmkKLUJDQz0kYWNfY3ZfcGF0aF9CQ0MKLWlmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQkNDIiA+JjUK
LSRhc19lY2hvICIkQkNDIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTERFUD0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTERFUAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MREVQIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1M
REVQIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxERVAiID4mNjsgfQogZWxzZQogICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFz
X2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7QkNDfSIgPT0geCJubyIKLXRo
ZW4KLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmNjLCBwbGVhc2UgaW5zdGFs
bCBiY2MiICIkTElORU5PIiA1CisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxERVAiID0geDsgdGhl
bgorICAgIE9DQU1MREVQPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzok
YWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5l
ZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTERFUD0kYWNfY3RfT0NBTUxERVAKKyAgZmkKK2Vsc2UK
KyAgT0NBTUxERVA9IiRhY19jdl9wcm9nX09DQU1MREVQIgogZmkKLSMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiaWFzbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Ci1zZXQgZHVtbXkgaWFzbDsgYWNfd29yZD0kMgorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxt
a3RvcAorICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4
fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0lBU0wrc2V0
fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MTUtUT1Arc2V0fSIg
PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNl
ICRJQVNMIGluCi0gIFtcXC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX0lBU0w9IiRJQVNM
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAg
KikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1u
ICIkT0NBTUxNS1RPUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QPSIkT0NBTUxNS1RP
UCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9
JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0lBU0w9IiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QPSIk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAg
ICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0KLSAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfSUFTTCIgJiYgYWNfY3ZfcGF0aF9JQVNMPSJubyIKLSAgOzsKLWVz
YWMKLWZpCi1JQVNMPSRhY19jdl9wYXRoX0lBU0wKLWlmIHRlc3QgLW4gIiRJQVNMIjsgdGhlbgot
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElBU0wi
ID4mNQotJGFzX2VjaG8gIiRJQVNMIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2
OyB9Ci1maQotCi0KLWlmIHRlc3QgeCIke0lBU0x9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2Zu
X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNsLCBwbGVhc2UgaW5zdGFsbCBpYXNsIiAiJExJ
TkVOTyIgNQotZmkKLQotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1
aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4g
OgotCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHV1aWRfY2xlYXIgaW4gLWx1dWlkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl91
dWlkX3V1aWRfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHV1
aWQgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot
LyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHBy
b3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0
IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg
YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVz
cGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIHV1aWRfY2xlYXIgKCk7Ci1pbnQKLW1haW4g
KCkKLXsKLXJldHVybiB1dWlkX2NsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9G
Ci1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl91dWlk
X3V1aWRfY2xlYXI9eWVzCi1lbHNlCi0gIGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXI9bm8KLWZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVf
TElCUwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl91
dWlkX3V1aWRfY2xlYXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfdXVpZF91dWlkX2Ns
ZWFyIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYnV1aWQ9InkiCi1maQotCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAogZmkKLQotCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9t
b25ncmVsICIkTElORU5PIiAidXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfaCIgIiRhY19pbmNs
dWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF9oIiA9IHgiInllczsg
dGhlbiA6Ci0gIGxpYnV1aWQ9InkiCiBmaQotCi0KLWlmIHRlc3QgIiRsaWJ1dWlkIiAhPSAieSI7
IHRoZW4gOgotCi0gICAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBs
aWJyYXJ5IiAiJExJTkVOTyIgNQotCitPQ0FNTE1LVE9QPSRhY19jdl9wcm9nX09DQU1MTUtUT1AK
K2lmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtUT1AiID4mNQorJGFzX2VjaG8gIiRP
Q0FNTE1LVE9QIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCiAK
LWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJjdXJzZXMuaCIgImFjX2N2
X2hlYWRlcl9jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19j
dl9oZWFkZXJfY3Vyc2VzX2giID0geCIieWVzOyB0aGVuIDoKLQotICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vyc2Vz
IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcy4uLiAiID4m
NjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfY3Vyc2VzX2NsZWFyK3NldH0iID0gc2V0OyB0aGVu
IDoKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19j
dF9PQ0FNTE1LVE9QPSRPQ0FNTE1LVE9QCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
b2NhbWxta3RvcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgb2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sY3Vy
c2VzICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
LS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1
c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBjbGVhciAoKTsKLWludAotbWFpbiAoKQot
ewotcmV0dXJuIGNsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9jdXJzZXNfY2xlYXI9
eWVzCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MTUtUT1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KIGVsc2UKLSAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj1ubworYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8K
KyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9wIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCiBmaQot
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfY3Vyc2Vz
X2NsZWFyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPSB4IiJ5
ZXM7IHRoZW4gOgotICBjdXJzZXM9InkiCithY19jdF9PQ0FNTE1LVE9QPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MTUtUT1AKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09D
QU1MTUtUT1AiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KIGVsc2UK
LSAgY3Vyc2VzPSJuIgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQorICBpZiB0ZXN0
ICJ4JGFjX2N0X09DQU1MTUtUT1AiID0geDsgdGhlbgorICAgIE9DQU1MTUtUT1A9Im5vIgorICBl
bHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1M
TUtUT1A9JGFjX2N0X09DQU1MTUtUT1AKKyAgZmkKIGVsc2UKLSAgY3Vyc2VzPSJuIgorICBPQ0FN
TE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgogZmkKIAogCi1hY19mbl9jX2NoZWNrX2hl
YWRlcl9tb25ncmVsICIkTElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNf
aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbmN1cnNl
c19oIiA9IHgiInllczsgdGhlbiA6Ci0KLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMiID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sbmN1cnNlcy4uLiAiID4mNjsgfQotaWYgdGVz
dCAiJHthY19jdl9saWJfbmN1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxt
a2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0i
LWxuY3Vyc2VzICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRl
cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGlu
dCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRo
ZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYg
X19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBjbGVhciAoKTsKLWludAotbWFp
biAoKQotewotcmV0dXJuIGNsZWFyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1p
ZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9uY3Vyc2Vz
X2NsZWFyPXllcworICBpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJv
Z19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl
c3QuCiBlbHNlCi0gIGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyPW5vCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFz
X3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtMSUI9
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
KyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwogZmkK
LXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9M
SUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9uY3Vy
c2VzX2NsZWFyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0g
eCIieWVzOyB0aGVuIDoKLSAgbmN1cnNlcz0ieSIKK09DQU1MTUtMSUI9JGFjX2N2X3Byb2dfT0NB
TUxNS0xJQgoraWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS0xJQiIgPiY1CiskYXNf
ZWNobyAiJE9DQU1MTUtMSUIiID4mNjsgfQogZWxzZQotICBuY3Vyc2VzPSJuIgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotZWxzZQotICBuY3Vyc2VzPSJuIgogZmkKLQotCi1pZiB0
ZXN0ICIkY3Vyc2VzIiA9ICJuIiAmJiB0ZXN0ICIkbmN1cnNlcyIgPSAibiI7IHRoZW4gOgotCi0g
ICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgY3Vyc2VzIGxpYnJh
cnkiICIkTElORU5PIiA1CitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIjsgdGhl
bgorICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgb2NhbWxta2xpYjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsg
dGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9PQ0FNTE1LTElCIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxN
S0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAy
CisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAogZmkKLSMgUHJlZmVyIG5j
dXJzZXMgb3ZlciBjdXJzZXMgaWYgYm90aCBhcmUgcHJlc2VudAotaWYgdGVzdCAiJG5jdXJzZXMi
ID0gInkiOyB0aGVuIDoKLQotICAgIENVUlNFU19MSUJTPSItbG5jdXJzZXMiCi0KLSRhc19lY2hv
ICIjZGVmaW5lIElOQ0xVREVfQ1VSU0VTX0ggPG5jdXJzZXMuaD4iID4+Y29uZmRlZnMuaAotCi0K
K2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2Vj
aG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KIGVsc2UKLQotICAgIENVUlNFU19MSUJTPSIt
bGN1cnNlcyIKLQotJGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNfSCA8Y3Vyc2VzLmg+
IiA+PmNvbmZkZWZzLmgKLQotCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAorICBpZiB0
ZXN0ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgorICAgIE9DQU1MTUtMSUI9Im5vIgor
ICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVz
OikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNp
bmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19l
Y2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9D
QU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKKyAgZmkKK2Vsc2UKKyAgT0NBTUxNS0xJQj0iJGFj
X2N2X3Byb2dfT0NBTUxNS0xJQiIKK2ZpCiAKIAotCi0KLQotCi0KLWlmIHRlc3QgIngkYWNfY3Zf
ZW52X1BLR19DT05GSUdfc2V0IiAhPSAieHNldCI7IHRoZW4KLQlpZiB0ZXN0IC1uICIkYWNfdG9v
bF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1wa2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25maWc7IGFjX3dvcmQ9JDIKKyAg
IyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4Ijsg
dGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxkb2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19j
dl9wYXRoX1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9w
cm9nX09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKIGVsc2UKLSAgY2FzZSAkUEtHX0NPTkZJRyBpbgotICBbXFwvXSogfCA/OltcXC9dKikK
LSAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgor
ICBhY19jdl9wcm9nX09DQU1MRE9DPSIkT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgog
Zm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0
YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9
OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxk
b2MiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjk0
MSwxMyArNDU5NiwxMiBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICA7Owot
ZXNhYwogZmkKLVBLR19DT05GSUc9JGFjX2N2X3BhdGhfUEtHX0NPTkZJRwotaWYgdGVzdCAtbiAi
JFBLR19DT05GSUciOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1Ci0kYXNfZWNobyAiJFBLR19DT05GSUciID4m
NjsgfQorZmkKK09DQU1MRE9DPSRhY19jdl9wcm9nX09DQU1MRE9DCitpZiB0ZXN0IC1uICIkT0NB
TUxET0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRPQ0FNTERPQyIgPiY2OyB9CiBlbHNl
CiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQpAQCAtNjk1NSwyOCArNDYwOSwyNiBAQCBmaQogCiAK
IGZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIjsgdGhlbgotICBhY19wdF9Q
S0dfQ09ORklHPSRQS0dfQ09ORklHCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGtn
LWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVt
bXkgcGtnLWNvbmZpZzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxE
T0MiOyB0aGVuCisgIGFjX2N0X09DQU1MRE9DPSRPQ0FNTERPQworICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSBvY2FtbGRvYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2
X3BhdGhfYWNfcHRfUEtHX0NPTkZJRytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2Fj
X2N2X3Byb2dfYWNfY3RfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCi0gIFtc
XC9dKiB8ID86W1xcL10qKQotICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19wdF9Q
S0dfQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4K
LSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxET0M9IiRhY19jdF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGly
IGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAg
ICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0ib2NhbWxkb2MiCiAgICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAtNjk4NCwyMCArNDYzNiwxOSBA
QCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICA7OwotZXNhYwogZmkKLWFjX3B0
X1BLR19DT05GSUc9JGFjX2N2X3BhdGhfYWNfcHRfUEtHX0NPTkZJRwotaWYgdGVzdCAtbiAiJGFj
X3B0X1BLR19DT05GSUciOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfcHRfUEtHX0NPTkZJRyIgPiY1Ci0kYXNfZWNobyAiJGFjX3B0
X1BLR19DT05GSUciID4mNjsgfQorZmkKK2FjX2N0X09DQU1MRE9DPSRhY19jdl9wcm9nX2FjX2N0
X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxET0Mi
ID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERPQyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNo
byAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05GSUciID0geDsg
dGhlbgotICAgIFBLR19DT05GSUc9IiIKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTERPQyIgPSB4
OyB0aGVuCisgICAgT0NBTUxET0M9Im5vIgogICBlbHNlCiAgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgogeWVzOikKQEAgLTcwMDUsNjI0ICs0NjU2LDcxOCBAQCB5
ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVzIDs7CiBl
c2FjCi0gICAgUEtHX0NPTkZJRz0kYWNfcHRfUEtHX0NPTkZJRworICAgIE9DQU1MRE9DPSRhY19j
dF9PQ0FNTERPQwogICBmaQogZWxzZQotICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09O
RklHIgotZmkKLQotZmkKLWlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgotCV9wa2dfbWlu
X3ZlcnNpb249MC45LjAKLQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQgbGVhc3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lv
biIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNp
b24gJF9wa2dfbWluX3ZlcnNpb24uLi4gIiA+JjY7IH0KLQlpZiAkUEtHX0NPTkZJRyAtLWF0bGVh
c3QtcGtnY29uZmlnLXZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb247IHRoZW4KLQkJeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Ci0kYXNfZWNo
byAieWVzIiA+JjY7IH0KLQllbHNlCi0JCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCQlQS0dfQ09O
RklHPSIiCi0JZmkKLWZpCi0KLXBrZ19mYWlsZWQ9bm8KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdsaWIiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGdsaWIuLi4gIiA+JjY7IH0KLQotaWYgdGVzdCAtbiAiJGdsaWJfQ0ZMQUdTIjsg
dGhlbgotICAgIHBrZ19jdl9nbGliX0NGTEFHUz0iJGdsaWJfQ0ZMQUdTIgotIGVsaWYgdGVzdCAt
biAiJFBLR19DT05GSUciOyB0aGVuCi0gICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwK
LSAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09O
RklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1Ci0gICgkUEtH
X0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1Ci0gIGFjX3N0
YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgotICBwa2dfY3Zf
Z2xpYl9DRkxBR1M9YCRQS0dfQ09ORklHIC0tY2ZsYWdzICJnbGliLTIuMCIgMj4vZGV2L251bGxg
Ci1lbHNlCi0gIHBrZ19mYWlsZWQ9eWVzCi1maQotIGVsc2UKLSAgICBwa2dfZmFpbGVkPXVudHJp
ZWQKLWZpCi1pZiB0ZXN0IC1uICIkZ2xpYl9MSUJTIjsgdGhlbgotICAgIHBrZ19jdl9nbGliX0xJ
QlM9IiRnbGliX0xJQlMiCi0gZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KLSAgICBp
ZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAotICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMg
XCJnbGliLTIuMFwiIjsgfSA+JjUKLSAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJy
b3JzICJnbGliLTIuMCIpIDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9OyB0aGVuCi0gIHBrZ19jdl9nbGliX0xJQlM9YCRQS0dfQ09ORklHIC0tbGli
cyAiZ2xpYi0yLjAiIDI+L2Rldi9udWxsYAotZWxzZQotICBwa2dfZmFpbGVkPXllcwotZmkKLSBl
bHNlCi0gICAgcGtnX2ZhaWxlZD11bnRyaWVkCi1maQotCi0KLQotaWYgdGVzdCAkcGtnX2ZhaWxl
ZCA9IHllczsgdGhlbgotICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCi1pZiAkUEtHX0NPTkZJ
RyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgotICAgICAgICBfcGtnX3No
b3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCi1lbHNlCi0gICAgICAgIF9wa2dfc2hvcnRfZXJyb3Jz
X3N1cHBvcnRlZD1ubworICBPQ0FNTERPQz0iJGFjX2N2X3Byb2dfT0NBTUxET0MiCiBmaQotICAg
ICAgICBpZiB0ZXN0ICRfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQgPSB5ZXM7IHRoZW4KLQkg
ICAgICAgIGdsaWJfUEtHX0VSUk9SUz1gJFBLR19DT05GSUcgLS1zaG9ydC1lcnJvcnMgLS1wcmlu
dC1lcnJvcnMgImdsaWItMi4wIiAyPiYxYAotICAgICAgICBlbHNlCi0JICAgICAgICBnbGliX1BL
R19FUlJPUlM9YCRQS0dfQ09ORklHIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKLSAg
ICAgICAgZmkKLQkjIFB1dCB0aGUgbmFzdHkgZXJyb3IgbWVzc2FnZSBpbiBjb25maWcubG9nIHdo
ZXJlIGl0IGJlbG9uZ3MKLQllY2hvICIkZ2xpYl9QS0dfRVJST1JTIiA+JjUKLQotCWFzX2ZuX2Vy
cm9yICQ/ICJQYWNrYWdlIHJlcXVpcmVtZW50cyAoZ2xpYi0yLjApIHdlcmUgbm90IG1ldDoKLQot
JGdsaWJfUEtHX0VSUk9SUwotCi1Db25zaWRlciBhZGp1c3RpbmcgdGhlIFBLR19DT05GSUdfUEFU
SCBlbnZpcm9ubWVudCB2YXJpYWJsZSBpZiB5b3UKLWluc3RhbGxlZCBzb2Z0d2FyZSBpbiBhIG5v
bi1zdGFuZGFyZCBwcmVmaXguCi0KLUFsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZp
cm9ubWVudCB2YXJpYWJsZXMgZ2xpYl9DRkxBR1MKLWFuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhl
IG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgotU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZv
ciBtb3JlIGRldGFpbHMuIiAiJExJTkVOTyIgNQotZWxpZiB0ZXN0ICRwa2dfZmFpbGVkID0gdW50
cmllZDsgdGhlbgotICAgICAJeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci0JeyB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Ci0k
YXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9lcnJv
ciAkPyAiVGhlIHBrZy1jb25maWcgc2NyaXB0IGNvdWxkIG5vdCBiZSBmb3VuZCBvciBpcyB0b28g
b2xkLiAgTWFrZSBzdXJlIGl0Ci1pcyBpbiB5b3VyIFBBVEggb3Igc2V0IHRoZSBQS0dfQ09ORklH
IGVudmlyb25tZW50IHZhcmlhYmxlIHRvIHRoZSBmdWxsCi1wYXRoIHRvIHBrZy1jb25maWcuCiAK
LUFsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZpcm9ubWVudCB2YXJpYWJsZXMgZ2xp
Yl9DRkxBR1MKLWFuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29u
ZmlnLgotU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuCiAKLVRv
IGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+
LgotU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Cisg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxidWlsZCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19PQ0FNTEJVSUxEK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLQlnbGliX0NGTEFHUz0kcGtnX2N2X2dsaWJfQ0ZMQUdT
Ci0JZ2xpYl9MSUJTPSRwa2dfY3ZfZ2xpYl9MSUJTCi0gICAgICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIg
PiY2OyB9Ci0KLWZpCi0KLSMgQ2hlY2sgbGlicmFyeSBwYXRoCi1pZiB0ZXN0ICJcJHtleGVjX3By
ZWZpeH0vbGliIiA9ICIkbGliZGlyIjsgdGhlbiA6Ci0gIGlmIHRlc3QgIiRleGVjX3ByZWZpeCIg
PSAiTk9ORSIgJiYgdGVzdCAiJHByZWZpeCIgIT0gIk5PTkUiOyB0aGVuIDoKLSAgZXhlY19wcmVm
aXg9JHByZWZpeAotZmkKLSAgICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0gIk5PTkUiOyB0aGVu
IDoKLSAgZXhlY19wcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4Ci1maQotICAgIGlmIHRlc3QgLWQg
IiR7ZXhlY19wcmVmaXh9L2xpYjY0IjsgdGhlbiA6Ci0KLSAgICAgICAgTElCX1BBVEg9ImxpYjY0
IgotCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1M
QlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVs
c2UKLQotICAgICAgICBMSUJfUEFUSD0ibGliIgorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUwor
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sYnVpbGQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCi0KLWVsc2UKLQot
ICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVjX3ByZWZpeCIgKyAxYH0i
Ci0KIGZpCi0KLQotIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KLWFjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJiemxpYi5oIiAiYWNfY3ZfaGVhZGVyX2J6bGliX2giICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2J6bGliX2giID0geCIi
eWVzOyB0aGVuIDoKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgQloyX2J6RGVjb21wcmVzc0luaXQgaW4gLWxiejIiID4mNQotJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGJ6MiAgJExJQlMiCi1jYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0K
LS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9y
LgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m
IGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQg
c3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYK
LWNoYXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBC
WjJfYnpEZWNvbXByZXNzSW5pdCAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfYnoyX0JaMl9i
ekRlY29tcHJlc3NJbml0PXllcworT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19PQ0FNTEJVSUxECitp
ZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJVSUxEIiA+JjUKKyRhc19lY2hvICIkT0NB
TUxCVUlMRCIgPiY2OyB9CiBlbHNlCi0gIGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0lu
aXQ9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
LSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tf
bGliX3NhdmVfTElCUwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1Ci0kYXNf
ZWNobyAiJGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNjsgfQotaWYgdGVz
dCAieCRhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0IiA9IHgiInllczsgdGhlbiA6
Ci0gIHpsaWI9IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CiBmaQogCiAKIGZpCi0KLQotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVO
TyIgImx6bWEuaCIgImFjX2N2X2hlYWRlcl9sem1hX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIK
LWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2x6bWFfaCIgPSB4IiJ5ZXM7IHRoZW4gOgotCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem1hX3N0
cmVhbV9kZWNvZGVyIGluIC1sbHptYSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgbHpt
YV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdF9PQ0FNTEJVSUxEPSRP
Q0FNTEJVSUxECisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxidWls
ZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRCtz
ZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0g
IGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sbHptYSAgJExJQlMiCi1jYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMu
aC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lk
IGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVy
biB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5
cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMi
Ci0jZW5kaWYKLWNoYXIgbHptYV9zdHJlYW1fZGVjb2RlciAoKTsKLWludAotbWFpbiAoKQotewot
cmV0dXJuIGx6bWFfc3RyZWFtX2RlY29kZXIgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNF
T0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2x6
bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj15ZXMKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJ
TEQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09DQU1MQlVJ
TEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQotICBhY19jdl9saWJf
bHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5vCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9Im9jYW1s
YnVpbGQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3Qu
JGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bWFfbHptYV9z
dHJlYW1fZGVjb2RlciIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFt
X2RlY29kZXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9k
ZWNvZGVyIiA9IHgiInllczsgdGhlbiA6Ci0gIHpsaWI9IiR6bGliIC1ESEFWRV9MWk1BIC1sbHpt
YSIKK2FjX2N0X09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNo
byAiJGFjX2N0X09DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KIGZpCiAKLQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQlVJTEQiID0geDsgdGhlbgorICAg
IE9DQU1MQlVJTEQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190
b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0
cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz
IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXll
cyA7OworZXNhYworICAgIE9DQU1MQlVJTEQ9JGFjX2N0X09DQU1MQlVJTEQKKyAgZmkKK2Vsc2UK
KyAgT0NBTUxCVUlMRD0iJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCIKIGZpCiAKIAotYWNfZm5fY19j
aGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVhZGVy
X2x6b19sem8xeF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hl
YWRlcl9sem9fbHpvMXhfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICAgIGlmIHRlc3QgIngkT0NBTUxD
IiA9ICJ4bm8iOyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgbHpvMXhfZGVjb21wcmVzcyBpbiAtbGx6bzIiID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yLi4uICIgPiY2OyB9
Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGx6bzIgICRMSUJTIgotY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLworICAg
ICAgICBpZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CiAKLS8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgot
ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg
R0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp
bGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNo
YXIgbHpvMXhfZGVjb21wcmVzcyAoKTsKLWludAotbWFpbiAoKQotewotcmV0dXJuIGx6bzF4X2Rl
Y29tcHJlc3MgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVz
cz15ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcz1ubwotZmkKLXJt
IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT
CisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVu
YWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVOTyIgNQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21w
cmVzcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4m
NjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA9IHgiInll
czsgdGhlbiA6Ci0gIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCisgICAgICAgIG9j
YW1sdG9vbHM9Im4iCisKIGZpCiAKK2ZpCisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJh
c2giLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGJh
c2g7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX0JBU0grc2V0fSIgPSBzZXQ7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCQVNI
IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAg
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU
SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf
cGF0aF9CQVNIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUwogCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3BhdGhfQkFTSD0i
bm8iCisgIDs7Citlc2FjCitmaQorQkFTSD0kYWNfY3ZfcGF0aF9CQVNICitpZiB0ZXN0IC1uICIk
QkFTSCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRCQVNIIiA+JjUKKyRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQogZmkKIAogCitpZiB0ZXN0IHgiJHtCQVNIfSIgPT0geCJubyIKK3Ro
ZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmFzaCwgcGxlYXNlIGluc3Rh
bGwgYmFzaCIgIiRMSU5FTk8iIDUKK2ZpCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKLSRhc19lY2hv
X24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQotaWYgdGVzdCAi
JHthY19jdl9saWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKK2FjX2V4dD1jCith
Y19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZM
QUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4m
NScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVw
cm9jZXNzb3IiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVw
cm9jZXNzb3IuLi4gIiA+JjY7IH0KKyMgT24gU3Vucywgc29tZXRpbWVzICRDUFAgbmFtZXMgYSBk
aXJlY3RvcnkuCitpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIkQ1BQIjsgdGhlbgorICBD
UFA9CitmaQoraWYgdGVzdCAteiAiJENQUCI7IHRoZW4KKyAgaWYgdGVzdCAiJHthY19jdl9wcm9n
X0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sYWlvICAkTElCUyIK
LWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICMgRG91
YmxlIHF1b3RlcyBiZWNhdXNlIENQUCBuZWVkcyB0byBiZSBleHBhbmRlZAorICAgIGZvciBDUFAg
aW4gIiRDQyAtRSIgIiRDQyAtRSAtdHJhZGl0aW9uYWwtY3BwIiAiL2xpYi9jcHAiCisgICAgZG8K
KyAgICAgIGFjX3ByZXByb2Nfb2s9ZmFsc2UKK2ZvciBhY19jX3ByZXByb2Nfd2Fybl9mbGFnIGlu
ICcnIHllcworZG8KKyAgIyBVc2UgYSBoZWFkZXIgZmlsZSB0aGF0IGNvbWVzIHdpdGggZ2NjLCBz
byBjb25maWd1cmluZyBnbGliYworICAjIHdpdGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jr
cy4KKyAgIyBQcmVmZXIgPGxpbWl0cy5oPiB0byA8YXNzZXJ0Lmg+IGlmIF9fU1REQ19fIGlzIGRl
ZmluZWQsIHNpbmNlCisgICMgPGxpbWl0cy5oPiBleGlzdHMgZXZlbiBvbiBmcmVlc3RhbmRpbmcg
Y29tcGlsZXJzLgorICAjIE9uIHRoZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2gg
dGhlIGNvbXBpbGVyJ3MgcGFyc2VyLAorICAjIG5vdCBqdXN0IHRocm91Z2ggY3BwLiAiU3ludGF4
IGVycm9yIiBpcyBoZXJlIHRvIGNhdGNoIHRoaXMgY2FzZS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBP
dmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAg
IFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdD
QwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs
IGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgorI2lmZGVmIF9fU1RE
Q19fCisjIGluY2x1ZGUgPGxpbWl0cy5oPgorI2Vsc2UKKyMgaW5jbHVkZSA8YXNzZXJ0Lmg+CiAj
ZW5kaWYKLWNoYXIgaW9fc2V0dXAgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBpb19zZXR1
cCAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KKwkJICAgICBTeW50YXggZXJyb3IKIF9BQ0VPRgot
aWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfYWlvX2lv
X3NldHVwPXllcworaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisKIGVsc2UK
LSAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4k
YWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisgICMgQnJva2VuOiBmYWlscyBv
biB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKLSRhc19l
Y2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKLSAgc3lzdGVtX2Fpbz0ieSIKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3Jr
cyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwor
ICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNf
bm9uZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQogZWxz
ZQotICBzeXN0ZW1fYWlvPSJuIgorICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19v
az06CiticmVhaworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRh
Y19leHQKKworZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdz
IGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisgIGJyZWFrCiBm
aQogCisgICAgZG9uZQorICAgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKIAoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvIiA+
JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8uLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAogZWxz
ZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGNyeXB0byAgJExJQlMi
Ci1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X3By
b2dfQ1BQPSRDUFAKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENQUCIgPiY1CiskYXNfZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29r
PWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNl
IGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMK
KyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1p
dHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxs
aW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0
aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNl
ciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBj
YXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRl
cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGlu
dCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRo
ZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYg
X19jcGx1c3BsdXMKLWV4dGVybiAiQyIKKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1p
dHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgogI2VuZGlmCi1jaGFyIE1ENSAoKTsK
LWludAotbWFpbiAoKQotewotcmV0dXJuIE1ENSAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KKwkJ
ICAgICBTeW50YXggZXJyb3IKIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7
IHRoZW4gOgotICBhY19jdl9saWJfY3J5cHRvX01ENT15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAi
JExJTkVOTyI7IHRoZW4gOgorCiBlbHNlCi0gIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PW5vCi1maQot
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJ
QlMKKyAgIyBCcm9rZW46IGZhaWxzIG9uIHZhbGlkIGlucHV0LgorY29udGludWUKIGZpCi17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9j
cnlwdG9fTUQ1IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQot
aWYgdGVzdCAieCRhY19jdl9saWJfY3J5cHRvX01ENSIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKK3JtIC1mIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3JrcyBv
biBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAj
IGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9u
ZXhpc3RlbnQuaD4KIF9BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6
CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQor
ICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKIAotICBMSUJTPSItbGNy
eXB0byAkTElCUyIKK2RvbmUKKyMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVM
U0UncyBjbGVhbmluZyBjb2RlIHdhcyBza2lwcGVkLgorcm0gLWYgY29uZnRlc3QuaSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX2V4dAoraWYgJGFjX3ByZXByb2Nfb2s7IHRoZW4gOgogCiBlbHNl
Ci0gIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJjcnlwdG8iICIkTElORU5PIiA1
CisgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6
IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gIkMgcHJlcHJvY2Vzc29yIFwiJENQUFwiIGZhaWxzIHNh
bml0eSBjaGVjaworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDUgOyB9CiBmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcy4uLiAiID4mNjsgfQotaWYgdGVzdCAi
JHthY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMitzZXR9IiA9IHNldDsgdGhlbiA6CithY19l
eHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdT
ICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVz
dCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAk
TElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKworeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3JlcCB0
aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3BhdGhfR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJ
QlM9Ii1sZXh0MmZzICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyAgaWYgdGVzdCAteiAiJEdSRVAiOyB0
aGVuCisgIGFjX3BhdGhfR1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhyb3VnaCB0aGUgdXNl
cidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAorICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhfU0VQ
QVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dyZXA7IGRvCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
ICAgICBhY19wYXRoX0dSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAgICB7
IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0dSRVAiOyB9
IHx8IGNvbnRpbnVlCisjIENoZWNrIGZvciBHTlUgYWNfcGF0aF9HUkVQIGFuZCBzZWxlY3QgaXQg
aWYgaXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9HUkVQCitjYXNlIGAi
JGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0aF9H
UkVQPSIkYWNfcGF0aF9HUkVQIiBhY19wYXRoX0dSRVBfZm91bmQ9Ojs7CisqKQorICBhY19jb3Vu
dD0wCisgICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6Cisg
IGRvCisgICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIK
KyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0Lmlu
IiAiY29uZnRlc3QubmwiCisgICAgJGFzX2VjaG8gJ0dSRVAnID4+ICJjb25mdGVzdC5ubCIKKyAg
ICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gpLScgPCAiY29u
ZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAgIGRpZmYg
ImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKKyAg
ICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAgICBpZiB0
ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCisgICAgICAjIEJl
c3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUK
KyAgICAgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIKKyAgICAgIGFjX3BhdGhfR1JF
UF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBz
ZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFr
CisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNv
bmZ0ZXN0Lm91dDs7Citlc2FjCiAKLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90
eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0
Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1
bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVz
Ci1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgZXh0MmZzX29wZW4yICgpOwotaW50Ci1tYWluICgp
Ci17Ci1yZXR1cm4gZXh0MmZzX29wZW4yICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9G
Ci1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9leHQy
ZnNfZXh0MmZzX29wZW4yPXllcworICAgICAgJGFjX3BhdGhfR1JFUF9mb3VuZCAmJiBicmVhayAz
CisgICAgZG9uZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAt
eiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4KKyAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0
YWJsZSBncmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0
L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKIGVsc2UKLSAgYWNfY3ZfbGliX2V4dDJmc19leHQyZnNf
b3BlbjI9bm8KKyAgYWNfY3ZfcGF0aF9HUkVQPSRHUkVQCiBmaQotcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKwogZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4dDJm
c19leHQyZnNfb3BlbjIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19v
cGVuMiIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA9
IHgiInllczsgdGhlbiA6Ci0gIGxpYmV4dDJmcz0ieSIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9HUkVQIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfcGF0aF9HUkVQIiA+JjY7IH0KKyBHUkVQPSIkYWNfY3ZfcGF0aF9HUkVQIgorCisK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGVn
cmVwIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9wYXRoX0VHUkVQK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgbGliZXh0MmZzPSJuIgorICBpZiBlY2hvIGEgfCAk
R1JFUCAtRSAnKGF8YiknID4vZGV2L251bGwgMj4mMQorICAgdGhlbiBhY19jdl9wYXRoX0VHUkVQ
PSIkR1JFUCAtRSIKKyAgIGVsc2UKKyAgICAgaWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgorICBh
Y19wYXRoX0VHUkVQX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0
aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1Iv
dXNyL3hwZzQvYmluCitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX3Byb2cgaW4gZWdyZXA7IGRvCisgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgICAgICBhY19wYXRo
X0VHUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIk
YWNfcGF0aF9FR1JFUCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNvbnRp
bnVlCisjIENoZWNrIGZvciBHTlUgYWNfcGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlz
IGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfRUdSRVAKK2Nhc2UgYCIkYWNfcGF0
aF9FR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0aF9FR1JFUD0i
JGFjX3BhdGhfRUdSRVAiIGFjX3BhdGhfRUdSRVBfZm91bmQ9Ojs7CisqKQorICBhY19jb3VudD0w
CisgICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6CisgIGRv
CisgICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIKKyAg
ICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0LmluIiAi
Y29uZnRlc3QubmwiCisgICAgJGFzX2VjaG8gJ0VHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAg
IiRhY19wYXRoX0VHUkVQIiAnRUdSRVAkJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQi
IDI+L2Rldi9udWxsIHx8IGJyZWFrCisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3Qu
bmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCAr
IDEgJiYgYWNfY291bnQ9JGFzX3ZhbAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3Bh
dGhfRUdSRVBfbWF4LTB9OyB0aGVuCisgICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBi
dXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUKKyAgICAgIGFjX2N2X3BhdGhfRUdSRVA9
IiRhY19wYXRoX0VHUkVQIgorICAgICAgYWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50CisgICAg
ZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdo
CisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCisgIGRvbmUKKyAgcm0gLWYgY29u
ZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisK
KyAgICAgICRhY19wYXRoX0VHUkVQX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JF
UCI7IHRoZW4KKyAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBi
ZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1
CisgIGZpCitlbHNlCisgIGFjX2N2X3BhdGhfRUdSRVA9JEVHUkVQCiBmaQogCisgICBmaQorZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
cGF0aF9FR1JFUCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQorIEVH
UkVQPSIkYWNfY3ZfcGF0aF9FR1JFUCIKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdjcnlwdCIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAtbGdj
cnlwdC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFz
aF9idWZmZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Citp
ZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zdGRjK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UwotTElCUz0iLWxnY3J5cHQgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVk
ZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8ZmxvYXQuaD4KIAot
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Ci0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgot
Y2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gZ2Ny
eV9tZF9oYXNoX2J1ZmZlciAoKTsKKwogICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBh
Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlcj15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9eWVzCiBlbHNlCi0gIGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0
Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCiBm
aQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9s
aWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9s
aWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID0geCIieWVzOyB0aGVuIDoKLSAgbGliZ2Ny
eXB0PSJ5Igorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25m
dGVzdC4kYWNfZXh0CisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCisg
ICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwgY29udHJhcnkgdG8g
QU5TSS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0cmluZy5oPgorCitfQUNFT0YKK2lmIChl
dmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVHUkVQICJtZW1jaHIi
ID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisKIGVsc2UKLSAgbGliZ2NyeXB0PSJuIgorICBhY19j
dl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCiBmaQogCitpZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2Vz
IG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxzdGRsaWIuaD4KIAorX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNf
ZXh0IikgMj4mNSB8CisgICRFR1JFUCAiZnJlZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKIAot
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IHB0aHJlYWQgZmxhZyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZCBmbGFn
Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2F4X2N2X3B0aHJlYWRfZmxhZ3Mrc2V0fSIgPSBzZXQ7
IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQorICBhY19jdl9oZWFk
ZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgogCi0gICAgICAgIGF4X2N2X3B0aHJlYWRf
ZmxhZ3M9LXB0aHJlYWQKK2ZpCiAKLSAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJlYWRf
ZmxhZ3MiCi0gICAgUFRIUkVBRF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKLSAgICBQ
VEhSRUFEX0xJQlM9IiIKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCisg
ICMgL2Jpbi9jYyBpbiBJcml4LTQuMC41IGdldHMgbm9uLUFOU0kgY3R5cGUgbWFjcm9zIHVubGVz
cyB1c2luZyAtYW5zaS4KKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g
OgorICA6CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxjdHlwZS5oPgorI2luY2x1ZGUg
PHN0ZGxpYi5oPgorI2lmICgoJyAnICYgMHgwRkYpID09IDB4MDIwKQorIyBkZWZpbmUgSVNMT1dF
UihjKSAoJ2EnIDw9IChjKSAmJiAoYykgPD0gJ3onKQorIyBkZWZpbmUgVE9VUFBFUihjKSAoSVNM
T1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMpKQorI2Vsc2UKKyMgZGVmaW5lIElTTE9X
RVIoYykgXAorCQkgICAoKCdhJyA8PSAoYykgJiYgKGMpIDw9ICdpJykgXAorCQkgICAgIHx8ICgn
aicgPD0gKGMpICYmIChjKSA8PSAncicpIFwKKwkJICAgICB8fCAoJ3MnIDw9IChjKSAmJiAoYykg
PD0gJ3onKSkKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAoKGMpIHwgMHg0MCkg
OiAoYykpCisjZW5kaWYKIAorI2RlZmluZSBYT1IoZSwgZikgKCgoZSkgJiYgIShmKSkgfHwgKCEo
ZSkgJiYgKGYpKSkKK2ludAorbWFpbiAoKQoreworICBpbnQgaTsKKyAgZm9yIChpID0gMDsgaSA8
IDI1NjsgaSsrKQorICAgIGlmIChYT1IgKGlzbG93ZXIgKGkpLCBJU0xPV0VSIChpKSkKKwl8fCB0
b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkKKyAgICAgIHJldHVybiAyOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CiAKLSAgICBz
YXZlZF9DRkxBR1M9IiRDRkxBR1MiCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitmaQor
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorZmkKIAotICAgIHNhdmVkX0xERkxBR1M9IiRMREZMQUdTIgorZmkKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hl
YWRlcl9zdGRjIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KIAotICAgIHNhdmVkX0xJQlM9IiRM
SUJTIgorJGFzX2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAogCitm
aQogCi0gICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQVEhSRUFEX0NGTEFHUyIKKyMgT24gSVJJWCA1LjMs
IHN5cy90eXBlcyBhbmQgaW50dHlwZXMuaCBhcmUgY29uZmxpY3RpbmcuCitmb3IgYWNfaGVhZGVy
IGluIHN5cy90eXBlcy5oIHN5cy9zdGF0Lmggc3RkbGliLmggc3RyaW5nLmggbWVtb3J5Lmggc3Ry
aW5ncy5oIFwKKwkJICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0ZC5oCitkbyA6CisgIGFzX2Fj
X0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAK
K2FjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFz
X2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQi
JGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAg
MQorX0FDRU9GCiAKLSAgICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgorZmkK
IAotICAgIExJQlM9IiRMSUJTICRQVEhSRUFEX0xJQlMiCitkb25lCiAKLSAgICAgICAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwogCi0jaW5jbHVkZSA8cHRocmVhZC5oPgotaW50IG1haW4odm9pZCkgewotICBwdGhyZWFk
X2F0Zm9yaygwLDAsMCk7Ci0gIHB0aHJlYWRfY3JlYXRlKDAsMCwwLDApOwotfQoraWYgdGVzdCAi
eCRweXRob250b29scyIgPSAieHkiOyB0aGVuIDoKIAotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6CisgICAgaWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJe
LyI7IHRoZW4gOgogCisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049
YGJhc2VuYW1lICRQWVRIT05QQVRIYAorCitlbGlmIHRlc3QgLXogIiRQWVRIT04iOyB0aGVuIDoK
KyAgUFlUSE9OPSJweXRob24iCiBlbHNlCi0gIGF4X2N2X3B0aHJlYWRfZmxhZ3M9ZmFpbGVkCisg
IGFzX2ZuX2Vycm9yICQ/ICJQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRl
IHBhdGgiICIkTElORU5PIiA1CiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAg
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRQWVRIT04iLCBzbyBpdCBjYW4gYmUgYSBw
cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRQWVRIT047IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRQWVRIT05QQVRIIGluCisg
IFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9IiRQWVRIT05QQVRI
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAg
KikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBp
biAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAg
YWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUwogCi0gICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgorICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgor
ICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAoraWYgdGVz
dCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKLSAgICBMREZM
QUdTPSIkc2F2ZWRfTERGTEFHUyIKIAotICAgIExJQlM9IiRzYXZlZF9MSUJTIgoraWYgdGVzdCB4
IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1Citm
aQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBvcnQg
c3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKK2lmIHRl
c3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYx
YAorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICAgIGFzX2ZuX2Vycm9yICQ/ICIkcHl0aG9u
X3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMyIgIiRM
SU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKIAorYWNfcHJl
dmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCithY19wcmV2aW91c19sZGZsYWdzPSRMREZMQUdTCith
Y19weXRob25fdmVyc2lvbj1gJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7
IFwKKyAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJWRVJTSU9O
IiknYAorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OLWNvbmZpZyIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJFBZVEhPTi1jb25m
aWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX3B5Y29uZmlnK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAk
cHljb25maWcgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfcHljb25maWc9
IiRweWNvbmZpZyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGgu
CisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3BhdGhfcHljb25maWc9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfcHljb25m
aWciICYmIGFjX2N2X3BhdGhfcHljb25maWc9Im5vIgorICA7OworZXNhYworZmkKK3B5Y29uZmln
PSRhY19jdl9wYXRoX3B5Y29uZmlnCitpZiB0ZXN0IC1uICIkcHljb25maWciOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkcHljb25maWci
ID4mNQorJGFzX2VjaG8gIiRweWNvbmZpZyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8i
ID4mNjsgfQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYXhfY3ZfcHRocmVhZF9mbGFncyIgPiY1Ci0kYXNfZWNobyAiJGF4X2N2X3B0aHJlYWRf
ZmxhZ3MiID4mNjsgfQotICAgIGlmIHRlc3QgIngkYXhfY3ZfcHRocmVhZF9mbGFncyIgPSB4ZmFp
bGVkOyB0aGVuCi0gICAgICAgIGFzX2ZuX2Vycm9yICQ/ICItcHRocmVhZCBkb2VzIG5vdCB3b3Jr
IiAiJExJTkVOTyIgNQotICAgIGZpCi0KLSAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJl
YWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKLSAg
ICBQVEhSRUFEX0xJQlM9IiIKIAogCitpZiB0ZXN0IHgiJHB5Y29uZmlnIiA9PSB4Im5vIjsgdGhl
biA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIGNsb2NrX2dldHRpbWUgaW4gLWxydCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
Y2xvY2tfZ2V0dGltZSBpbiAtbHJ0Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9y
dF9jbG9ja19nZXR0aW1lK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxy
dCAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCisgICAgICAgIENQUEZMQUdTPSIkQ0ZMQUdTIGAkUFlUSE9O
IC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAorICAgICAgICBwcmludCAiLUkiICsg
ZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiSU5DTFVERVBZIiknYCIKKyAgICBD
UFBGTEFHUz0iJENQUEZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZp
ZzsgXAorICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJD
RkxBR1MiKSdgIgorICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlz
dHV0aWxzLnN5c2NvbmZpZzsgXAorICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdl
dF9jb25maWdfdmFyKCJMSUJTIiknYCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAt
YyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgZGlzdHV0aWxz
LnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiU1lTTElCUyIpJ2AiCisgICAgTERGTEFHUz0iJExE
RkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCisgICAgICAg
IHByaW50ICItTCIgKyBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBsYXRfc3Bl
Y2lmaWM9MSxcCisgICAgICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidgIgorICAgIExE
RkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsg
XAorICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJMSU5L
Rk9SU0hBUkVEIiknYCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0
IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZp
Zy5nZXRfY29uZmlnX3ZhcigiTERGTEFHUyIpJ2AiCiAKLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50
ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBp
bnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0
aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVm
IF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgY2xvY2tfZ2V0dGltZSAoKTsK
LWludAotbWFpbiAoKQotewotcmV0dXJuIGNsb2NrX2dldHRpbWUgKCk7Ci0gIDsKLSAgcmV0dXJu
IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAg
YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9eWVzCiBlbHNlCi0gIGFjX2N2X2xpYl9ydF9jbG9j
a19nZXR0aW1lPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjUKLSRhc19l
Y2hvICIkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID4mNjsgfQotaWYgdGVzdCAieCRhY19j
dl9saWJfcnRfY2xvY2tfZ2V0dGltZSIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfTElCUlQgMQotX0FDRU9GCiAKLSAgTElCUz0iLWxy
dCAkTElCUyIKKyAgICAgICAgQ1BQRkxBR1M9IiRDRkxBR1MgYCRQWVRIT04tY29uZmlnIC0tY2Zs
YWdzYCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTi1jb25maWcgLS1sZGZsYWdzYCIK
IAogZmkKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl95
YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHlh
amwgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot
LyogZW5kIGNvbmZkZWZzLmguICAqLworYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJ
TkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVyX1B5dGhvbl9oIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9QeXRob25faCIgPSB4IiJ5ZXM7IHRoZW4g
OgogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl
cnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw
ZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2Vu
ZGlmCi1jaGFyIHlhamxfYWxsb2MgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiB5YWpsX2Fs
bG9jICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5r
ICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCiBlbHNl
Ci0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0
LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRl
c3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworICBhc19mbl9lcnJvciAk
PyAiVW5hYmxlIHRvIGZpbmQgUHl0aG9uIGRldmVsb3BtZW50IGhlYWRlcnMiICIkTElORU5PIiA1
CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX3lhamxf
eWFqbF9hbGxvYyIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mi
ID0geCIieWVzOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBI
QVZFX0xJQllBSkwgMQotX0FDRU9GCi0KLSAgTElCUz0iLWx5YWpsICRMSUJTIgogCi1lbHNlCi0g
IGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB5YWpsIiAiJExJTkVOTyIgNQotZmkKIAot
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZGVm
bGF0ZUNvcHkgaW4gLWx6IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBkZWZsYXRlQ29w
eSBpbiAtbHouLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkr
c2V0fSIgPSBzZXQ7IHRoZW4gOgorYXNfYWNfTGliPWAkYXNfZWNobyAiYWNfY3ZfbGliX3B5dGhv
biRhY19weXRob25fdmVyc2lvbicnX1B5QXJnX1BhcnNlVHVwbGUiIHwgJGFzX3RyX3NoYAoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgUHlBcmdf
UGFyc2VUdXBsZSBpbiAtbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgUHlBcmdfUGFyc2VUdXBsZSBpbiAtbHB5dGhvbiRhY19weXRob25fdmVy
c2lvbi4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyRhc19hY19MaWIrc2V0fVwiIiA9
IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCiAgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1seiAgJExJQlMiCitMSUJTPSItbHB5dGhv
biRhY19weXRob25fdmVyc2lvbiAgJExJQlMiCiBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKQEAgLTc2MzIsMTg5MyAr
NTM3NywxMTczIEBAIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
ICNpZmRlZiBfX2NwbHVzcGx1cwogZXh0ZXJuICJDIgogI2VuZGlmCi1jaGFyIGRlZmxhdGVDb3B5
ICgpOworY2hhciBQeUFyZ19QYXJzZVR1cGxlICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4g
ZGVmbGF0ZUNvcHkgKCk7CityZXR1cm4gUHlBcmdfUGFyc2VUdXBsZSAoKTsKICAgOwogICByZXR1
cm4gMDsKIH0KIF9BQ0VPRgogaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgot
ICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKKyAgZXZhbCAiJGFzX2FjX0xpYj15ZXMiCiBl
bHNlCi0gIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5vCisgIGV2YWwgIiRhc19hY19MaWI9bm8i
CiBmaQogcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCiAgICAg
Y29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKIExJQlM9JGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfel9kZWZsYXRlQ29w
eSIgPSB4IiJ5ZXM7IHRoZW4gOgorZXZhbCBhY19yZXM9XCQkYXNfYWNfTGliCisJICAgICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+
JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNf
TGliIlwiID0geCJ5ZXMiOyB0aGVuIDoKICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2Rl
ZmluZSBIQVZFX0xJQlogMQorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfTElCcHl0aG9uJGFjX3B5
dGhvbl92ZXJzaW9uIiB8ICRhc190cl9jcHBgIDEKIF9BQ0VPRgogCi0gIExJQlM9Ii1seiAkTElC
UyIKLQotZWxzZQotICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgemxpYiIgIiRMSU5F
Tk8iIDUKLWZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udiIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k
TElCUwotTElCUz0iLWxpY29udiAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCisgIExJQlM9Ii1scHl0aG9u
JGFjX3B5dGhvbl92ZXJzaW9uICRMSUJTIgogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFs
IHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1p
Z2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBp
dHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2Nw
bHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGxpYmljb252X29wZW4gKCk7Ci1pbnQK
LW1haW4gKCkKLXsKLXJldHVybiBsaWJpY29udl9vcGVuICgpOwotICA7Ci0gIHJldHVybiAwOwot
fQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2
X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwotZWxzZQotICBhY19jdl9saWJfaWNvbnZfbGli
aWNvbnZfb3Blbj1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY1Ci0k
YXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjY7IH0KLWlmIHRlc3Qg
IngkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID0geCIieWVzOyB0aGVuIDoKLSAgbGli
aWNvbnY9InkiCiBlbHNlCi0gIGxpYmljb252PSJuIgorICBhc19mbl9lcnJvciAkPyAiVW5hYmxl
IHRvIGZpbmQgYSBzdWl0YWJsZSBweXRob24gZGV2ZWxvcG1lbnQgbGlicmFyeSIgIiRMSU5FTk8i
IDUKIGZpCiAKK0NQUEZMQUdTPSRhY19wcmV2aW91c19jcHBmbGFncworTERMRkFHUz0kYWNfcHJl
dmlvdXNfbGRmbGFncwogCiAKLSMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCi0jIFRoZSBVbHRy
aXggNC4yIG1pcHMgYnVpbHRpbiBhbGxvY2EgZGVjbGFyZWQgYnkgYWxsb2NhLmggb25seSB3b3Jr
cwotIyBmb3IgY29uc3RhbnQgYXJndW1lbnRzLiAgVXNlbGVzcyEKLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmgiID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmguLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3Zfd29ya2luZ19hbGxvY2FfaCtzZXR9IiA9IHNldDsgdGhlbiA6Citm
aQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgdGVzdCAiJHthY19jdl9wYXRoX1hHRVRURVhUK3NldH0iID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUg
PGFsbG9jYS5oPgotaW50Ci1tYWluICgpCi17Ci1jaGFyICpwID0gKGNoYXIgKikgYWxsb2NhICgy
ICogc2l6ZW9mIChpbnQpKTsKLQkJCSAgaWYgKHApIHJldHVybiAwOwotICA7Ci0gIHJldHVybiAw
OwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFj
X2N2X3dvcmtpbmdfYWxsb2NhX2g9eWVzCi1lbHNlCi0gIGFjX2N2X3dvcmtpbmdfYWxsb2NhX2g9
bm8KKyAgY2FzZSAkWEdFVFRFWFQgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3Bh
dGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qg
d2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2
X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9Im5vIgorICA7OworZXNhYwog
ZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitYR0VUVEVYVD0kYWNfY3ZfcGF0aF9Y
R0VUVEVYVAoraWYgdGVzdCAtbiAiJFhHRVRURVhUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhHRVRURVhUIiA+JjUKKyRhc19lY2hv
ICIkWEdFVFRFWFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCi17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3dv
cmtpbmdfYWxsb2NhX2giID4mNQotJGFzX2VjaG8gIiRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+
JjY7IH0KLWlmIHRlc3QgJGFjX2N2X3dvcmtpbmdfYWxsb2NhX2ggPSB5ZXM7IHRoZW4KIAotJGFz
X2VjaG8gIiNkZWZpbmUgSEFWRV9BTExPQ0FfSCAxIiA+PmNvbmZkZWZzLmgKIAoraWYgdGVzdCB4
IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUg
dG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1CiBm
aQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBhbGxvY2EiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGFsbG9jYS4uLiAiID4mNjsg
fQotaWYgdGVzdCAiJHthY19jdl9mdW5jX2FsbG9jYV93b3JrcytzZXR9IiA9IHNldDsgdGhlbiA6
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGFzODY7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX0FTODYrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgogZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZkZWYgX19HTlVDX18KLSMgZGVm
aW5lIGFsbG9jYSBfX2J1aWx0aW5fYWxsb2NhCi0jZWxzZQotIyBpZmRlZiBfTVNDX1ZFUgotIyAg
aW5jbHVkZSA8bWFsbG9jLmg+Ci0jICBkZWZpbmUgYWxsb2NhIF9hbGxvY2EKLSMgZWxzZQotIyAg
aWZkZWYgSEFWRV9BTExPQ0FfSAotIyAgIGluY2x1ZGUgPGFsbG9jYS5oPgotIyAgZWxzZQotIyAg
IGlmZGVmIF9BSVgKLSAjcHJhZ21hIGFsbG9jYQotIyAgIGVsc2UKLSMgICAgaWZuZGVmIGFsbG9j
YSAvKiBwcmVkZWZpbmVkIGJ5IEhQIGNjICtPbGliY2FsbHMgKi8KLWNoYXIgKmFsbG9jYSAoKTsK
LSMgICAgZW5kaWYKLSMgICBlbmRpZgotIyAgZW5kaWYKLSMgZW5kaWYKLSNlbmRpZgotCi1pbnQK
LW1haW4gKCkKLXsKLWNoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDEpOwotCQkJCSAgICBpZiAo
cCkgcmV0dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3M9eWVzCi1l
bHNlCi0gIGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjUKLSRhc19lY2hvICIkYWNfY3Zf
ZnVuY19hbGxvY2Ffd29ya3MiID4mNjsgfQotCi1pZiB0ZXN0ICRhY19jdl9mdW5jX2FsbG9jYV93
b3JrcyA9IHllczsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX0FMTE9DQSAxIiA+PmNv
bmZkZWZzLmgKKyAgY2FzZSAkQVM4NiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9BUzg2PSIkQVM4NiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQVM4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9BUzg2
IiAmJiBhY19jdl9wYXRoX0FTODY9Im5vIgorICA7OworZXNhYworZmkKK0FTODY9JGFjX2N2X3Bh
dGhfQVM4NgoraWYgdGVzdCAtbiAiJEFTODYiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQVM4NiIgPiY1CiskYXNfZWNobyAiJEFTODYi
ID4mNjsgfQogZWxzZQotICAjIFRoZSBTVlIzIGxpYlBXIGFuZCBTVlI0IGxpYnVjYiBib3RoIGNv
bnRhaW4gaW5jb21wYXRpYmxlIGZ1bmN0aW9ucwotIyB0aGF0IGNhdXNlIHRyb3VibGUuICBTb21l
IHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2NhIG9yCi0jIGNvbnRhaW4gYSBidWdn
eSB2ZXJzaW9uLiAgSWYgeW91IHN0aWxsIHdhbnQgdG8gdXNlIHRoZWlyIGFsbG9jYSwKLSMgdXNl
IGFyIHRvIGV4dHJhY3QgYWxsb2NhLm8gZnJvbSB0aGVtIGluc3RlYWQgb2YgY29tcGlsaW5nIGFs
bG9jYS5jLgotCi1BTExPQ0E9XCR7TElCT0JKRElSfWFsbG9jYS4kYWNfb2JqZXh0Ci0KLSRhc19l
Y2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMuaAorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3MiID4mNQotJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgd2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzLi4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X29zX2NyYXkrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYg
dGVzdCB4IiR7QVM4Nn0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGFzODYsIHBsZWFzZSBpbnN0YWxsIGFzODYiICIkTElORU5PIiA1CitmaQorIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJsZDg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBsZDg2OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7
YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmIGRlZmluZWQgQ1JBWSAmJiAhIGRlZmlu
ZWQgQ1JBWTIKLXdlYmVjcmF5Ci0jZWxzZQotd2Vub3RiZWNyYXkKLSNlbmRpZgorICBjYXNlICRM
RDg2IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0xEODY9IiRMRDg2IiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikK
KyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAk
UEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNf
Y3ZfcGF0aF9MRDg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19z
YXZlX0lGUwogCi1fQUNFT0YKLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAy
PiY1IHwKLSAgJEVHUkVQICJ3ZWJlY3JheSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKLSAgYWNf
Y3Zfb3NfY3JheT15ZXMKLWVsc2UKLSAgYWNfY3Zfb3NfY3JheT1ubworICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9MRDg2IiAmJiBhY19jdl9wYXRoX0xEODY9Im5vIgorICA7OworZXNhYwogZmkKLXJt
IC1mIGNvbmZ0ZXN0KgotCitMRDg2PSRhY19jdl9wYXRoX0xEODYKK2lmIHRlc3QgLW4gIiRMRDg2
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJExEODYiID4mNQorJGFzX2VjaG8gIiRMRDg2IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9vc19jcmF5IiA+JjUKLSRhc19lY2hvICIkYWNfY3Zfb3NfY3JheSIg
PiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9vc19jcmF5ID0geWVzOyB0aGVuCi0gIGZvciBhY19mdW5j
IGluIF9nZXRiNjcgR0VUQjY3IGdldGI2NzsgZG8KLSAgICBhc19hY192YXI9YCRhc19lY2hvICJh
Y19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKLWFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJ
TkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNf
dmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2Rl
ZmluZSBDUkFZX1NUQUNLU0VHX0VORCAkYWNfZnVuYwotX0FDRU9GCiAKLSAgICBicmVhawotZmkK
IAotICBkb25lCitpZiB0ZXN0IHgiJHtMRDg2fSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGluc3RhbGwgbGQ4NiIgIiRMSU5F
Tk8iIDUKIGZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYSIgPiY1Ci0kYXNfZWNob19uICJjaGVj
a2luZyBzdGFjayBkaXJlY3Rpb24gZm9yIEMgYWxsb2NhLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIk
e2FjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uK3NldH0iID0gc2V0OyB0aGVuIDoKKyMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiYmNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSBiY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRo
X0JDQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl
bHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3Zf
Y19zdGFja19kaXJlY3Rpb249MAotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVm
YXVsdAotaW50Ci1maW5kX3N0YWNrX2RpcmVjdGlvbiAoKQotewotICBzdGF0aWMgY2hhciAqYWRk
ciA9IDA7Ci0gIGF1dG8gY2hhciBkdW1teTsKLSAgaWYgKGFkZHIgPT0gMCkKLSAgICB7Ci0gICAg
ICBhZGRyID0gJmR1bW15OwotICAgICAgcmV0dXJuIGZpbmRfc3RhY2tfZGlyZWN0aW9uICgpOwot
ICAgIH0KLSAgZWxzZQotICAgIHJldHVybiAoJmR1bW15ID4gYWRkcikgPyAxIDogLTE7Ci19Cisg
IGNhc2UgJEJDQyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CQ0M9IiRC
Q0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7Owor
ICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wYXRoX0JDQz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k
YXNfc2F2ZV9JRlMKIAotaW50Ci1tYWluICgpCi17Ci0gIHJldHVybiBmaW5kX3N0YWNrX2RpcmVj
dGlvbiAoKSA8IDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRo
ZW4gOgotICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0xCi1lbHNlCi0gIGFjX2N2X2Nfc3RhY2tf
ZGlyZWN0aW9uPS0xCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24u
b3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQ0Mi
ICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKKyAgOzsKK2VzYWMKIGZpCi0KK0JDQz0kYWNfY3ZfcGF0
aF9CQ0MKK2lmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQkNDIiA+JjUKKyRhc19lY2hvICIkQkNDIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIg
PiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjY7IH0KLWNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgU1RBQ0tfRElSRUNUSU9OICRhY19jdl9jX3N0YWNr
X2RpcmVjdGlvbgotX0FDRU9GCiAKIAoraWYgdGVzdCB4IiR7QkNDfSIgPT0geCJubyIKK3RoZW4K
KyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmNjLCBwbGVhc2UgaW5zdGFsbCBi
Y2MiICIkTElORU5PIiA1CiBmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJpYXNsIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBpYXNsOyBh
Y193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9JQVNMK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkSUFTTCBpbgor
ICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9JQVNMPSIkSUFTTCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf
SUFTTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK
IAotZm9yIGFjX2hlYWRlciBpbiAgXAotICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRs
LmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAotICAgICAgICAgICAg
ICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmlu
Zy5oIFwKLSAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBz
eXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCi0gICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5
cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAotICAgICAgICAgICAg
ICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5vIgorICA7OworZXNhYworZmkKK0lBU0w9JGFj
X2N2X3BhdGhfSUFTTAoraWYgdGVzdCAtbiAiJElBU0wiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSUFTTCIgPiY1CiskYXNfZWNobyAi
JElBU0wiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKLWRvIDoK
LSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFz
X3RyX3NoYAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIiRhY19oZWFk
ZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiBldmFsIHRlc3Qg
XCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3Ry
X2NwcGAgMQotX0FDRU9GCiAKK2lmIHRlc3QgeCIke0lBU0x9IiA9PSB4Im5vIgordGhlbgorICAg
IGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNsLCBwbGVhc2UgaW5zdGFsbCBpYXNs
IiAiJExJTkVOTyIgNQogZmkKIAotZG9uZQotCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVs
ICIkTElORU5PIiAidXVpZC91dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF91dWlkX2giICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiA9
IHgiInllczsgdGhlbiA6CiAKLSMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5k
IGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5OSIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMgdG8g
Qzk5Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zdGRib29sX2grc2V0fSIg
PSBzZXQ7IHRoZW4gOgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIgaW4gLWx1dWlkIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth
Y19jdl9saWJfdXVpZF91dWlkX2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHV1
aWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAog
LyogZW5kIGNvbmZkZWZzLmguICAqLwogCi0jaW5jbHVkZSA8c3RkYm9vbC5oPgotI2lmbmRlZiBi
b29sCi0gImVycm9yOiBib29sIGlzIG5vdCBkZWZpbmVkIgotI2VuZGlmCi0jaWZuZGVmIGZhbHNl
Ci0gImVycm9yOiBmYWxzZSBpcyBub3QgZGVmaW5lZCIKLSNlbmRpZgotI2lmIGZhbHNlCi0gImVy
cm9yOiBmYWxzZSBpcyBub3QgMCIKLSNlbmRpZgotI2lmbmRlZiB0cnVlCi0gImVycm9yOiB0cnVl
IGlzIG5vdCBkZWZpbmVkIgotI2VuZGlmCi0jaWYgdHJ1ZSAhPSAxCi0gImVycm9yOiB0cnVlIGlz
IG5vdCAxIgotI2VuZGlmCi0jaWZuZGVmIF9fYm9vbF90cnVlX2ZhbHNlX2FyZV9kZWZpbmVkCi0g
ImVycm9yOiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCBpcyBub3QgZGVmaW5lZCIKKy8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgor
ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg
R0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp
bGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCiAjZW5kaWYKLQot
CXN0cnVjdCBzIHsgX0Jvb2wgczogMTsgX0Jvb2wgdDsgfSBzOwotCi0JY2hhciBhW3RydWUgPT0g
MSA/IDEgOiAtMV07Ci0JY2hhciBiW2ZhbHNlID09IDAgPyAxIDogLTFdOwotCWNoYXIgY1tfX2Jv
b2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCA9PSAxID8gMSA6IC0xXTsKLQljaGFyIGRbKGJvb2wp
IDAuNSA9PSB0cnVlID8gMSA6IC0xXTsKLQlib29sIGUgPSAmczsKLQljaGFyIGZbKF9Cb29sKSAw
LjAgPT0gZmFsc2UgPyAxIDogLTFdOwotCWNoYXIgZ1t0cnVlXTsKLQljaGFyIGhbc2l6ZW9mIChf
Qm9vbCldOwotCWNoYXIgaVtzaXplb2Ygcy50XTsKLQllbnVtIHsgaiA9IGZhbHNlLCBrID0gdHJ1
ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAyNTYgfTsKLQkvKiBUaGUgZm9sbG93aW5n
IGZhaWxzIGZvcgotCSAgIEhQIGFDKysvQU5TSSBDIEIzOTEwQiBBLjA1LjU1IFtEZWMgMDQgMjAw
M10uICovCi0JX0Jvb2wgblttXTsKLQljaGFyIG9bc2l6ZW9mIG4gPT0gbSAqIHNpemVvZiBuWzBd
ID8gMSA6IC0xXTsKLQljaGFyIHBbLTEgLSAoX0Jvb2wpIDAgPCAwICYmIC0xIC0gKGJvb2wpIDAg
PCAwID8gMSA6IC0xXTsKLSMJaWYgZGVmaW5lZCBfX3hsY19fIHx8IGRlZmluZWQgX19HTlVDX18K
LQkgLyogQ2F0Y2ggYSBidWcgaW4gSUJNIEFJWCB4bGMgY29tcGlsZXIgdmVyc2lvbiA2LjAuMC4w
Ci0JICAgIHJlcG9ydGVkIGJ5IEphbWVzIExlbWxleSBvbiAyMDA1LTEwLTA1OyBzZWUKLQkgICAg
aHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMC9t
c2cwMDA4Ni5odG1sCi0JICAgIFRoaXMgdGVzdCBpcyBub3QgcXVpdGUgcmlnaHQsIHNpbmNlIHhs
YyBpcyBhbGxvd2VkIHRvCi0JICAgIHJlamVjdCB0aGlzIHByb2dyYW0sIGFzIHRoZSBpbml0aWFs
aXplciBmb3IgeGxjYnVnIGlzCi0JICAgIG5vdCBvbmUgb2YgdGhlIGZvcm1zIHRoYXQgQyByZXF1
aXJlcyBzdXBwb3J0IGZvci4KLQkgICAgSG93ZXZlciwgZG9pbmcgdGhlIHRlc3QgcmlnaHQgd291
bGQgcmVxdWlyZSBhIHJ1bnRpbWUKLQkgICAgdGVzdCwgYW5kIHRoYXQgd291bGQgbWFrZSBjcm9z
cy1jb21waWxhdGlvbiBoYXJkZXIuCi0JICAgIExldCB1cyBob3BlIHRoYXQgSUJNIGZpeGVzIHRo
ZSB4bGMgYnVnLCBhbmQgYWxzbyBhZGRzCi0JICAgIHN1cHBvcnQgZm9yIHRoaXMga2luZCBvZiBj
b25zdGFudCBleHByZXNzaW9uLiAgSW4gdGhlCi0JICAgIG1lYW50aW1lLCB0aGlzIHRlc3Qgd2ls
bCByZWplY3QgeGxjLCB3aGljaCBpcyBPSywgc2luY2UKLQkgICAgb3VyIHN0ZGJvb2wuaCBzdWJz
dGl0dXRlIHNob3VsZCBzdWZmaWNlLiAgV2UgYWxzbyB0ZXN0Ci0JICAgIHRoaXMgd2l0aCBHQ0Ms
IHdoZXJlIGl0IHNob3VsZCB3b3JrLCB0byBkZXRlY3QgbW9yZQotCSAgICBxdWlja2x5IHdoZXRo
ZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRlc3QgaW4gdGhlCi0JICAgIGZ1dHVyZS4gICovCi0J
IGNoYXIgZGlnc1tdID0gIjAxMjM0NTY3ODkiOwotCSBpbnQgeGxjYnVnID0gMSAvICgmKGRpZ3Mg
KyA1KVstMiArIChib29sKSAxXSA9PSAmZGlnc1s0XSA/IDEgOiAtMSk7Ci0jCWVuZGlmCi0JLyog
Q2F0Y2ggYSBidWcgaW4gYW4gSFAtVVggQyBjb21waWxlci4gIFNlZQotCSAgIGh0dHA6Ly9nY2Mu
Z251Lm9yZy9tbC9nY2MtcGF0Y2hlcy8yMDAzLTEyL21zZzAyMzAzLmh0bWwKLQkgICBodHRwOi8v
bGlzdHMuZ251Lm9yZy9hcmNoaXZlL2h0bWwvYnVnLWNvcmV1dGlscy8yMDA1LTExL21zZzAwMTYx
Lmh0bWwKLQkgKi8KLQlfQm9vbCBxID0gdHJ1ZTsKLQlfQm9vbCAqcHEgPSAmcTsKLQorY2hhciB1
dWlkX2NsZWFyICgpOwogaW50CiBtYWluICgpCiB7Ci0KLQkqcHEgfD0gcTsKLQkqcHEgfD0gISBx
OwotCS8qIFJlZmVyIHRvIGV2ZXJ5IGRlY2xhcmVkIHZhbHVlLCB0byBhdm9pZCBjb21waWxlciBv
cHRpbWl6YXRpb25zLiAgKi8KLQlyZXR1cm4gKCFhICsgIWIgKyAhYyArICFkICsgIWUgKyAhZiAr
ICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCi0JCSsgIW0gKyAhbiArICFvICsgIXAgKyAh
cSArICFwcSk7Ci0KK3JldHVybiB1dWlkX2NsZWFyICgpOwogICA7CiAgIHJldHVybiAwOwogfQog
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2
X2hlYWRlcl9zdGRib29sX2g9eWVzCi1lbHNlCi0gIGFjX2N2X2hlYWRlcl9zdGRib29sX2g9bm8K
LWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0
LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2hlYWRlcl9zdGRib29sX2giID4mNQotJGFzX2VjaG8gIiRhY19jdl9oZWFk
ZXJfc3RkYm9vbF9oIiA+JjY7IH0KLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgIl9Cb29s
IiAiYWNfY3ZfdHlwZV9fQm9vbCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRh
Y19jdl90eXBlX19Cb29sIiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKLSNkZWZpbmUgSEFWRV9fQk9PTCAxCi1fQUNFT0YKLQotCi1maQotCi1pZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYm9vbF9oID0geWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIEhB
VkVfU1REQk9PTF9IIDEiID4+Y29uZmRlZnMuaAotCi1maQotCi17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMvdHlwZXMuaCIg
PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmguLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfdHlwZV91aWRfdCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0g
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRl
IDxzeXMvdHlwZXMuaD4KLQotX0FDRU9GCi1pZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNf
ZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAidWlkX3QiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0g
IGFjX2N2X3R5cGVfdWlkX3Q9eWVzCi1lbHNlCi0gIGFjX2N2X3R5cGVfdWlkX3Q9bm8KLWZpCi1y
bSAtZiBjb25mdGVzdCoKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3R5
cGVfdWlkX3QiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfdHlwZV91aWRfdCA9IG5vOyB0aGVuCi0K
LSRhc19lY2hvICIjZGVmaW5lIHVpZF90IGludCIgPj5jb25mZGVmcy5oCi0KLQotJGFzX2VjaG8g
IiNkZWZpbmUgZ2lkX3QgaW50IiA+PmNvbmZkZWZzLmgKLQotZmkKLQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW5saW5lIiA+JjUKLSRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf
Y19pbmxpbmUrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgotZWxzZQotICBhY19jdl9jX2lubGluZT1ubwotZm9yIGFjX2t3IGluIGlubGluZSBfX2lubGlu
ZV9fIF9faW5saW5lOyBkbwotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZuZGVmIF9fY3BsdXNwbHVzCi10eXBl
ZGVmIGludCBmb29fdDsKLXN0YXRpYyAkYWNfa3cgZm9vX3Qgc3RhdGljX2ZvbyAoKSB7cmV0dXJu
IDA7IH0KLSRhY19rdyBmb29fdCBmb28gKCkge3JldHVybiAwOyB9Ci0jZW5kaWYKLQotX0FDRU9G
Ci1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2NfaW5s
aW5lPSRhY19rdworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9saWJfdXVpZF91dWlkX2NsZWFyPXllcworZWxzZQorICBhY19jdl9saWJfdXVpZF91dWlkX2Ns
ZWFyPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0Ci0gIHRlc3QgIiRhY19jdl9jX2lubGluZSIgIT0gbm8gJiYgYnJlYWsK
LWRvbmUKLQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3V1aWRf
dXVpZF9jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJ1dWlkPSJ5IgogZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19pbmxpbmUi
ID4mNQotJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2OyB9CiAKLWNhc2UgJGFjX2N2X2Nf
aW5saW5lIGluCi0gIGlubGluZSB8IHllcykgOzsKLSAgKikKLSAgICBjYXNlICRhY19jdl9jX2lu
bGluZSBpbgotICAgICAgbm8pIGFjX3ZhbD07OwotICAgICAgKikgYWNfdmFsPSRhY19jdl9jX2lu
bGluZTs7Ci0gICAgZXNhYwotICAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNpZm5kZWYg
X19jcGx1c3BsdXMKLSNkZWZpbmUgaW5saW5lICRhY192YWwKLSNlbmRpZgotX0FDRU9GCi0gICAg
OzsKLWVzYWMKIAotYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY19p
bnQxNl90IgotY2FzZSAkYWNfY3ZfY19pbnQxNl90IGluICMoCi0gIG5vfHllcykgOzsgIygKLSAg
KikKK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgaW50MTZfdCAkYWNf
Y3ZfY19pbnQxNl90Ci1fQUNFT0YKLTs7Ci1lc2FjCiAKLWFjX2ZuX2NfZmluZF9pbnRYX3QgIiRM
SU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKLWNhc2UgJGFjX2N2X2NfaW50MzJfdCBpbiAj
KAotICBub3x5ZXMpIDs7ICMoCi0gICopCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAidXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF9oIiA9IHgiInllczsgdGhlbiA6Cisg
IGxpYnV1aWQ9InkiCitmaQogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGlu
dDMyX3QgJGFjX2N2X2NfaW50MzJfdAotX0FDRU9GCi07OwotZXNhYwogCi1hY19mbl9jX2ZpbmRf
aW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0X3QiCi1jYXNlICRhY19jdl9jX2lu
dDY0X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQoraWYgdGVzdCAiJGxpYnV1aWQiICE9
ICJ5IjsgdGhlbiA6CiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgaW50NjRf
dCAkYWNfY3ZfY19pbnQ2NF90Ci1fQUNFT0YKLTs7Ci1lc2FjCisgICAgYXNfZm5fZXJyb3IgJD8g
ImNhbm5vdCBmaW5kIGEgdmFsaWQgdXVpZCBsaWJyYXJ5IiAiJExJTkVOTyIgNQogCi1hY19mbl9j
X2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIgImFjX2N2X2NfaW50OF90IgotY2FzZSAkYWNfY3Zf
Y19pbnQ4X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQorZmkKIAotY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBpbnQ4X3QgJGFjX2N2X2NfaW50OF90Ci1fQUNFT0YKLTs7
Ci1lc2FjCiAKLWFjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgIm1vZGVfdCIgImFjX2N2X3R5
cGVfbW9kZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
bW9kZV90IiA9IHgiInllczsgdGhlbiA6CithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJfY3Vyc2VzX2giICIkYWNfaW5jbHVkZXNf
ZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2N1cnNlc19oIiA9IHgiInllczsgdGhl
biA6CiAKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
Y2xlYXIgaW4gLWxjdXJzZXMuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2N1cnNl
c19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CiBlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sY3Vyc2VzICAk
TElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBt
b2RlX3QgaW50CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9p
ZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1
cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90
eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJD
IgorI2VuZGlmCitjaGFyIGNsZWFyICgpOworaW50CittYWluICgpCit7CityZXR1cm4gY2xlYXIg
KCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CiBfQUNFT0YKLQoraWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPXllcworZWxzZQorICBh
Y19jdl9saWJfY3Vyc2VzX2NsZWFyPW5vCiBmaQotCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F
Tk8iICJvZmZfdCIgImFjX2N2X3R5cGVfb2ZmX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlm
IHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZfdCIgPSB4IiJ5ZXM7IHRoZW4gOgotCitybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVl
eHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGli
X2N1cnNlc19jbGVhciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID4m
NjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA9IHgiInllczsgdGhlbiA6
CisgIGN1cnNlcz0ieSIKIGVsc2UKLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmlu
ZSBvZmZfdCBsb25nIGludAotX0FDRU9GCi0KKyAgY3Vyc2VzPSJuIgogZmkKIAotYWNfZm5fY19j
aGVja190eXBlICIkTElORU5PIiAicGlkX3QiICJhY19jdl90eXBlX3BpZF90IiAiJGFjX2luY2x1
ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcGlkX3QiID0geCIieWVzOyB0aGVu
IDoKIAogZWxzZQorICBjdXJzZXM9Im4iCitmaQogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
Ci0jZGVmaW5lIHBpZF90IGludAotX0FDRU9GCiAKLWZpCithY19mbl9jX2NoZWNrX2hlYWRlcl9t
b25ncmVsICIkTElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRh
Y19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbmN1cnNlc19oIiA9
IHgiInllczsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQiID4mNQotJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3Qg
IiR7YWNfY3ZfY19yZXN0cmljdCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vy
c2VzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMuLi4g
IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7
IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jdl9jX3Jl
c3RyaWN0PW5vCi0gICAjIFRoZSBvcmRlciBoZXJlIGNhdGVycyB0byB0aGUgZmFjdCB0aGF0IEMr
KyBkb2VzIG5vdCByZXF1aXJlIHJlc3RyaWN0LgotICAgZm9yIGFjX2t3IGluIF9fcmVzdHJpY3Qg
X19yZXN0cmljdF9fIF9SZXN0cmljdCByZXN0cmljdDsgZG8KLSAgICAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRM
SUJTCitMSUJTPSItbG5jdXJzZXMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotdHlwZWRlZiBpbnQgKiBp
bnRfcHRyOwotCWludCBmb28gKGludF9wdHIgJGFjX2t3IGlwKSB7Ci0JcmV0dXJuIGlwWzBdOwot
ICAgICAgIH0KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv
aWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0
dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3Rv
dHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAi
QyIKKyNlbmRpZgorY2hhciBjbGVhciAoKTsKIGludAogbWFpbiAoKQogewotaW50IHNbMV07Ci0J
aW50ICogJGFjX2t3IHQgPSBzOwotCXRbMF0gPSAwOwotCXJldHVybiBmb28odCkKK3JldHVybiBj
bGVhciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX3Jlc3RyaWN0PSRhY19rdworaWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfbmN1cnNlc19jbGVh
cj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9bm8KIGZpCi1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgICAg
dGVzdCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJyZWFrCi0gICBkb25lCi0KK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBm
aQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9jX3Jlc3RyaWN0IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfY19yZXN0cmljdCIgPiY2OyB9Ci0K
LSBjYXNlICRhY19jdl9jX3Jlc3RyaWN0IGluCi0gICByZXN0cmljdCkgOzsKLSAgIG5vKSAkYXNf
ZWNobyAiI2RlZmluZSByZXN0cmljdCAvKiovIiA+PmNvbmZkZWZzLmgKLSA7OwotICAgKikgIGNh
dCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgcmVzdHJpY3QgJGFjX2N2X2NfcmVzdHJp
Y3QKLV9BQ0VPRgotIDs7Ci0gZXNhYwotCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJz
aXplX3QiICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVz
dCAieCRhY19jdl90eXBlX3NpemVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgotCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9uY3Vyc2VzX2Ns
ZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBuY3Vy
c2VzPSJ5IgogZWxzZQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHNpemVf
dCB1bnNpZ25lZCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9Im4iCiBmaQogCi1hY19mbl9jX2No
ZWNrX3R5cGUgIiRMSU5FTk8iICJzc2l6ZV90IiAiYWNfY3ZfdHlwZV9zc2l6ZV90IiAiJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc3NpemVfdCIgPSB4IiJ5ZXM7
IHRoZW4gOgogCiBlbHNlCi0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgc3Np
emVfdCBpbnQKLV9BQ0VPRgotCisgIG5jdXJzZXM9Im4iCiBmaQogCi1hY19mbl9jX2NoZWNrX21l
bWJlciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxrc2l6ZSIgImFjX2N2X21lbWJlcl9z
dHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4
JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiA9IHgiInllczsgdGhlbiA6CiAK
LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9C
TEtTSVpFIDEKLV9BQ0VPRgoraWYgdGVzdCAiJGN1cnNlcyIgPSAibiIgJiYgdGVzdCAiJG5jdXJz
ZXMiID0gIm4iOyB0aGVuIDoKIAorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBh
IHN1aXRhYmxlIGN1cnNlcyBsaWJyYXJ5IiAiJExJTkVOTyIgNQogCiBmaQorIyBQcmVmZXIgbmN1
cnNlcyBvdmVyIGN1cnNlcyBpZiBib3RoIGFyZSBwcmVzZW50CitpZiB0ZXN0ICIkbmN1cnNlcyIg
PSAieSI7IHRoZW4gOgogCi1hY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVjdCBz
dGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsb2NrcyIgIiRh
Y19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRf
c3RfYmxvY2tzIiA9IHgiInllczsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MgMQotX0FDRU9GCisgICAgQ1VSU0VT
X0xJQlM9Ii1sbmN1cnNlcyIKIAorJGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNfSCA8
bmN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfU1RfQkxP
Q0tTIDEiID4+Y29uZmRlZnMuaAogCiBlbHNlCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoi
IGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIGZp
bGVibG9ja3MuJGFjX29iamV4dCIKLSA7OwotZXNhYwotCi1maQotCiAKLWFjX2ZuX2NfY2hlY2tf
bWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0YXQiICJzdF9yZGV2IiAiYWNfY3ZfbWVtYmVyX3N0
cnVjdF9zdGF0X3N0X3JkZXYiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNf
Y3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiID0geCIieWVzOyB0aGVuIDoKKyAgICBDVVJT
RVNfTElCUz0iLWxjdXJzZXMiCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUg
SEFWRV9TVFJVQ1RfU1RBVF9TVF9SREVWIDEKLV9BQ0VPRgorJGFzX2VjaG8gIiNkZWZpbmUgSU5D
TFVERV9DVVJTRVNfSCA8Y3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKIAogCiBmaQogCi1hY19mbl9j
X2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY191aW50MTZfdCIKLWNhc2UgJGFj
X2N2X2NfdWludDE2X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAotICAqKQogCiAKLWNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgdWludDE2X3QgJGFjX2N2X2NfdWludDE2X3QKLV9B
Q0VPRgotOzsKLSAgZXNhYwogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjMyIiAi
YWNfY3ZfY191aW50MzJfdCIKLWNhc2UgJGFjX2N2X2NfdWludDMyX3QgaW4gIygKLSAgbm98eWVz
KSA7OyAjKAotICAqKQogCi0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDMyX1QgMSIgPj5jb25mZGVm
cy5oCiAKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50MzJfdCAkYWNf
Y3ZfY191aW50MzJfdAotX0FDRU9GCi07OwotICBlc2FjCiAKLWFjX2ZuX2NfZmluZF91aW50WF90
ICIkTElORU5PIiAiNjQiICJhY19jdl9jX3VpbnQ2NF90IgotY2FzZSAkYWNfY3ZfY191aW50NjRf
dCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCitpZiB0ZXN0ICJ4JGFjX2N2X2Vudl9QS0dfQ09ORklH
X3NldCIgIT0gInhzZXQiOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9cGtnLWNv
bmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfcGF0aF9QS0dfQ09ORklHK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/Oltc
XC9dKikKKyAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CiAgICopCisgIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUEtH
X0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ2NF9UIDEiID4+Y29uZmRlZnMuaAotCisgIDs7
Citlc2FjCitmaQorUEtHX0NPTkZJRz0kYWNfY3ZfcGF0aF9QS0dfQ09ORklHCitpZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRQS0dfQ09ORklHIiA+JjUKKyRhc19lY2hvICIkUEtHX0NPTkZJRyIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKIAotY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50NjRfdCAkYWNfY3ZfY191aW50NjRfdAotX0FDRU9G
Ci07OwotICBlc2FjCiAKLWFjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiOCIgImFjX2N2
X2NfdWludDhfdCIKLWNhc2UgJGFjX2N2X2NfdWludDhfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMo
CitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRoZW4KKyAgYWNfcHRf
UEtHX0NPTkZJRz0kUEtHX0NPTkZJRworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBr
Zy1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX2FjX3B0
X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCisgIFtcXC9dKiB8ID86W1xc
L10qKQorICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19wdF9QS0dfQ09ORklHIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKICAgKikK
KyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAk
UEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNf
Y3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUwogCi0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDhfVCAxIiA+PmNv
bmZkZWZzLmgKLQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHVpbnQ4X3Qg
JGFjX2N2X2NfdWludDhfdAotX0FDRU9GCi07OwotICBlc2FjCi0KLWFjX2ZuX2NfY2hlY2tfdHlw
ZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVfcHRyZGlmZl90IiAiJGFjX2luY2x1
ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcHRyZGlmZl90IiA9IHgiInllczsg
dGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9QVFJESUZG
X1QgMQotX0FDRU9GCi0KLQorICA7OworZXNhYworZmkKK2FjX3B0X1BLR19DT05GSUc9JGFjX2N2
X3BhdGhfYWNfcHRfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAiJGFjX3B0X1BLR19DT05GSUciOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfcHRfUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJGFjX3B0X1BLR19DT05GSUciID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotIyBDaGVja3MgZm9yIGxp
YnJhcnkgZnVuY3Rpb25zLgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfZXJyb3Jf
YXRfbGluZStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxlcnJvci5oPgotaW50Ci1tYWluICgpCi17
Ci1lcnJvcl9hdF9saW5lICgwLCAwLCAiIiwgMCwgImFuIGVycm9yIG9jY3VycmVkIik7Ci0gIDsK
LSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKLSAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVzCisgIGlmIHRlc3QgIngkYWNfcHRf
UEtHX0NPTkZJRyIgPSB4OyB0aGVuCisgICAgUEtHX0NPTkZJRz0iIgorICBlbHNlCisgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg
PiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIFBLR19DT05GSUc9JGFjX3B0
X1BLR19DT05GSUcKKyAgZmkKIGVsc2UKLSAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9bm8KLWZp
Ci1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0
aF9QS0dfQ09ORklHIgogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUiID4mNQotJGFzX2VjaG8gIiRhY19j
dl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9saWJfZXJyb3JfYXRf
bGluZSA9IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIGVycm9yLiRhY19v
YmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBlcnJvci4kYWNfb2JqZXh0Igot
IDs7Ci1lc2FjCiAKIGZpCi0KLWZvciBhY19oZWFkZXIgaW4gdmZvcmsuaAotZG8gOgotICBhY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAidmZvcmsuaCIgImFjX2N2X2hlYWRl
cl92Zm9ya19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRl
cl92Zm9ya19oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
LSNkZWZpbmUgSEFWRV9WRk9SS19IIDEKLV9BQ0VPRgotCitpZiB0ZXN0IC1uICIkUEtHX0NPTkZJ
RyI7IHRoZW4KKwlfcGtnX21pbl92ZXJzaW9uPTAuOS4wCisJeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNp
b24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgcGtnLWNvbmZp
ZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uLi4uICIgPiY2OyB9CisJaWYg
JFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9u
OyB0aGVuCisJCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisJZWxzZQorCQl7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KKwkJUEtHX0NPTkZJRz0iIgorCWZpCiBmaQogCi1kb25lCi0KLWZvciBhY19mdW5j
IGluIGZvcmsgdmZvcmsKLWRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18k
YWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNf
ZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgi
eWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19l
Y2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VPRgotCi1maQotZG9uZQor
cGtnX2ZhaWxlZD1ubworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZ2xpYiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2xpYi4uLiAi
ID4mNjsgfQogCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9yayIgPSB4eWVzOyB0aGVuCi0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtp
bmcgZm9yayIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBmb3JrLi4uICIg
PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfZm9ya193b3JrcytzZXR9IiA9IHNldDsgdGhl
biA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgIiRjcm9z
c19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPWNyb3Nz
CitpZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0aGVuCisgICAgcGtnX2N2X2dsaWJfQ0ZMQUdT
PSIkZ2xpYl9DRkxBR1MiCisgZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgICBp
ZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMg
XCJnbGliLTIuMFwiIjsgfSA+JjUKKyAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJy
b3JzICJnbGliLTIuMCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9OyB0aGVuCisgIHBrZ19jdl9nbGliX0NGTEFHUz1gJFBLR19DT05GSUcgLS1j
ZmxhZ3MgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotCi0JICAvKiBCeSBSdWVkaWdlciBLdWhs
bWFubi4gKi8KLQkgIHJldHVybiBmb3JrICgpIDwgMDsKLQotICA7Ci0gIHJldHVybiAwOwotfQot
X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVu
Y19mb3JrX3dvcmtzPXllcworICBwa2dfZmFpbGVkPXllcworZmkKKyBlbHNlCisgICAgcGtnX2Zh
aWxlZD11bnRyaWVkCitmaQoraWYgdGVzdCAtbiAiJGdsaWJfTElCUyI7IHRoZW4KKyAgICBwa2df
Y3ZfZ2xpYl9MSUJTPSIkZ2xpYl9MSUJTIgorIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0
aGVuCisgICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwKKyAgICB7IHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJp
bnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1CisgICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAt
LXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAg
dGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgorICBwa2dfY3ZfZ2xpYl9MSUJTPWAkUEtHX0NP
TkZJRyAtLWxpYnMgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAKIGVsc2UKLSAgYWNfY3ZfZnVuY19m
b3JrX3dvcmtzPW5vCisgIHBrZ19mYWlsZWQ9eWVzCiBmaQotcm0gLWYgY29yZSAqLmNvcmUgY29y
ZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorIGVsc2UKKyAg
ICBwa2dfZmFpbGVkPXVudHJpZWQKIGZpCiAKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY1Ci0kYXNf
ZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9CiAKKworaWYgdGVzdCAkcGtnX2Zh
aWxlZCA9IHllczsgdGhlbgorICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCitpZiAkUEtHX0NP
TkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtn
X3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCiBlbHNlCi0gIGFjX2N2X2Z1bmNfZm9ya193b3Jr
cz0kYWNfY3ZfZnVuY19mb3JrCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZD1u
bwogZmkKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhlbgot
ICBjYXNlICRob3N0IGluCi0gICAgKi0qLWFtaWdhb3MqIHwgKi0qLW1zZG9zZGpncHAqKQotICAg
ICAgIyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZlIG9ubHkgYSBkdW1teSBmb3JrKCkg
c3R1YgotICAgICAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCi0gICAgICA7OwotICAgICopCi0g
ICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCi0gICAgICA7OwotICBlc2FjCi0gIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19j
dl9mdW5jX2Zvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+
JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19mb3JrX3dv
cmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KLWZpCi1hY19j
dl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1
bmNfdmZvcmsiID0geHllczsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHZmb3JrIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB3b3JraW5nIHZmb3JrLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1
bmNfdmZvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6
Ci0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9Y3Jvc3MKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotLyog
VGhhbmtzIHRvIFBhdWwgRWdnZXJ0IGZvciB0aGlzIHRlc3QuICAqLwotJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQKLSNpbmNsdWRlIDxzeXMvd2FpdC5oPgotI2lmZGVmIEhBVkVfVkZPUktfSAotIyBpbmNs
dWRlIDx2Zm9yay5oPgotI2VuZGlmCi0vKiBPbiBzb21lIHNwYXJjIHN5c3RlbXMsIGNoYW5nZXMg
YnkgdGhlIGNoaWxkIHRvIGxvY2FsIGFuZCBpbmNvbWluZwotICAgYXJndW1lbnQgcmVnaXN0ZXJz
IGFyZSBwcm9wYWdhdGVkIGJhY2sgdG8gdGhlIHBhcmVudC4gIFRoZSBjb21waWxlcgotICAgaXMg
dG9sZCBhYm91dCB0aGlzIHdpdGggI2luY2x1ZGUgPHZmb3JrLmg+LCBidXQgc29tZSBjb21waWxl
cnMKLSAgIChlLmcuIGdjYyAtTykgZG9uJ3QgZ3JvayA8dmZvcmsuaD4uICBUZXN0IGZvciB0aGlz
IGJ5IHVzaW5nIGEKLSAgIHN0YXRpYyB2YXJpYWJsZSB3aG9zZSBhZGRyZXNzIGlzIHB1dCBpbnRv
IGEgcmVnaXN0ZXIgdGhhdCBpcwotICAgY2xvYmJlcmVkIGJ5IHRoZSB2Zm9yay4gICovCi1zdGF0
aWMgdm9pZAotI2lmZGVmIF9fY3BsdXNwbHVzCi1zcGFyY19hZGRyZXNzX3Rlc3QgKGludCBhcmcp
Ci0jIGVsc2UKLXNwYXJjX2FkZHJlc3NfdGVzdCAoYXJnKSBpbnQgYXJnOwotI2VuZGlmCi17Ci0g
IHN0YXRpYyBwaWRfdCBjaGlsZDsKLSAgaWYgKCFjaGlsZCkgewotICAgIGNoaWxkID0gdmZvcmsg
KCk7Ci0gICAgaWYgKGNoaWxkIDwgMCkgewotICAgICAgcGVycm9yICgidmZvcmsiKTsKLSAgICAg
IF9leGl0KDIpOwotICAgIH0KLSAgICBpZiAoIWNoaWxkKSB7Ci0gICAgICBhcmcgPSBnZXRwaWQo
KTsKLSAgICAgIHdyaXRlKC0xLCAiIiwgMCk7Ci0gICAgICBfZXhpdCAoYXJnKTsKLSAgICB9Ci0g
IH0KLX0KKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVz
OyB0aGVuCisJICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJy
b3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKKyAgICAgICAgZWxzZQorCSAgICAg
ICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAi
IDI+JjFgCisgICAgICAgIGZpCisJIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29u
ZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdzCisJZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIgPiY1CiAK
LWludAotbWFpbiAoKQotewotICBwaWRfdCBwYXJlbnQgPSBnZXRwaWQgKCk7Ci0gIHBpZF90IGNo
aWxkOwotCi0gIHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7Ci0KLSAgY2hpbGQgPSB2Zm9yayAoKTsK
LQotICBpZiAoY2hpbGQgPT0gMCkgewotICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0ZXN0IGZvciBz
cGFyYyB2Zm9yayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKLSAgICAgICB0ZXN0IHVzZXMgbG90
cyBvZiBsb2NhbCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1hbnkgbG9jYWwKLSAgICAgICB2YXJp
YWJsZXMgYXMgbWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBpbmNsdWRpbmcgY29tcGlsZXIKLSAg
ICAgICB0ZW1wb3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9yIGdjYyAxLjQwLjMgb24g
YSBTb2xhcmlzCi0gICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3ZSB1c2UgOCB0byBiZSBzYWZlLiAg
QSBidWdneSBjb21waWxlciBzaG91bGQKLSAgICAgICByZXVzZSB0aGUgcmVnaXN0ZXIgb2YgcGFy
ZW50IGZvciBvbmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywKLSAgICAgICBzaW5jZSBpdCB3aWxs
IHRoaW5rIHRoYXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJlIHVzZWQgYW55IG1vcmUKLSAgICAg
ICBpbiB0aGlzIHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhlIGxvY2FsIHZhcmlhYmxlIHdpbGwg
dGh1cwotICAgICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFyZW50IHByb2Nlc3MuICAqLwotICAg
IHBpZF90Ci0gICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0cGlkKCksIHAyID0gZ2V0cGlkKCks
IHAzID0gZ2V0cGlkKCksCi0gICAgICBwNCA9IGdldHBpZCgpLCBwNSA9IGdldHBpZCgpLCBwNiA9
IGdldHBpZCgpLCBwNyA9IGdldHBpZCgpOwotICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0
aGF0IHAuLnA3IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1pZ2h0Ci0gICAgICAgdXNlIHRoZSBz
YW1lIGhhcmR3YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2NhbCB2YXJpYWJsZXMuICAqLwotICAg
IGlmIChwICE9IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8fCBwICE9IHA0Ci0JfHwgcCAhPSBw
NSB8fCBwICE9IHA2IHx8IHAgIT0gcDcpCi0gICAgICBfZXhpdCgxKTsKLQotICAgIC8qIE9uIHNv
bWUgc3lzdGVtcyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50
Ci0gICAgICAgZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3JzLiAgSWYgdGhlIGNoaWxkIGNsb3Nl
cyBhIGRlc2NyaXB0b3IKLSAgICAgICBiZWZvcmUgaXQgZXhlY3Mgb3IgZXhpdHMsIHRoaXMgbXVu
Z2VzIHRoZSBwYXJlbnQncyBkZXNjcmlwdG9yCi0gICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRo
aXMgYnkgY2xvc2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KLSAgICBfZXhpdChjbG9zZShm
aWxlbm8oc3Rkb3V0KSkgIT0gMCk7Ci0gIH0gZWxzZSB7Ci0gICAgaW50IHN0YXR1czsKLSAgICBz
dHJ1Y3Qgc3RhdCBzdDsKKwlhc19mbl9lcnJvciAkPyAiUGFja2FnZSByZXF1aXJlbWVudHMgKGds
aWItMi4wKSB3ZXJlIG5vdCBtZXQ6CiAKLSAgICB3aGlsZSAod2FpdCgmc3RhdHVzKSAhPSBjaGls
ZCkKLSAgICAgIDsKLSAgICByZXR1cm4gKAotCSAvKiBXYXMgdGhlcmUgc29tZSBwcm9ibGVtIHdp
dGggdmZvcmtpbmc/ICAqLwotCSBjaGlsZCA8IDAKKyRnbGliX1BLR19FUlJPUlMKIAotCSAvKiBE
aWQgdGhlIGNoaWxkIGZhaWw/ICAoVGhpcyBzaG91bGRuJ3QgaGFwcGVuLikgICovCi0JIHx8IHN0
YXR1cworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1lbnQg
dmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJl
Zml4LgogCi0JIC8qIERpZCB0aGUgdmZvcmsvY29tcGlsZXIgYnVnIG9jY3VyPyAgKi8KLQkgfHwg
cGFyZW50ICE9IGdldHBpZCgpCitBbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJv
bm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBu
ZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3Ig
bW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKK2VsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJp
ZWQ7IHRoZW4KKyAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCXsgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFz
X2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3Ig
JD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9s
ZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBl
bnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0aCB0byBwa2ctY29uZmlnLgogCi0J
IC8qIERpZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1cj8gICovCi0JIHx8IGZzdGF0KGZp
bGVubyhzdGRvdXQpLCAmc3QpICE9IDAKLQkgKTsKLSAgfQotfQotX0FDRU9GCi1pZiBhY19mbl9j
X3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz15ZXMK
K0FsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZpcm9ubWVudCB2YXJpYWJsZXMgZ2xp
Yl9DRkxBR1MKK2FuZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29u
ZmlnLgorU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuCisKK1Rv
IGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+
LgorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CiBl
bHNlCi0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KLWZpCi1ybSAtZiBjb3JlICouY29yZSBj
b3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Ci1maQorCWds
aWJfQ0ZMQUdTPSRwa2dfY3ZfZ2xpYl9DRkxBR1MKKwlnbGliX0xJQlM9JHBrZ19jdl9nbGliX0xJ
QlMKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KIAogZmkKLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY192Zm9ya193b3Jr
cyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID4mNjsgfQogCi1maTsK
LWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhlbgotICBhY19j
dl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCi0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX3Zmb3Jr
X3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1Ci0kYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MgZ3Vlc3Nl
ZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7fQorIyBDaGVjayBsaWJyYXJ5IHBh
dGgKK2lmIHRlc3QgIlwke2V4ZWNfcHJlZml4fS9saWIiID0gIiRsaWJkaXIiOyB0aGVuIDoKKyAg
aWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIiAmJiB0ZXN0ICIkcHJlZml4IiAhPSAiTk9O
RSI7IHRoZW4gOgorICBleGVjX3ByZWZpeD0kcHJlZml4CiBmaQorICAgIGlmIHRlc3QgIiRleGVj
X3ByZWZpeCIgPSAiTk9ORSI7IHRoZW4gOgorICBleGVjX3ByZWZpeD0kYWNfZGVmYXVsdF9wcmVm
aXgKK2ZpCisgICAgaWYgdGVzdCAtZCAiJHtleGVjX3ByZWZpeH0vbGliNjQiOyB0aGVuIDoKIAot
aWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KLQotJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX1ZGT1JLIDEiID4+Y29uZmRlZnMuaAorICAgICAgICBM
SUJfUEFUSD0ibGliNjQiCiAKIGVsc2UKIAotJGFzX2VjaG8gIiNkZWZpbmUgdmZvcmsgZm9yayIg
Pj5jb25mZGVmcy5oCisgICAgICAgIExJQl9QQVRIPSJsaWIiCiAKIGZpCi1pZiB0ZXN0ICJ4JGFj
X2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhB
VkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorZWxzZQogCi1maQorICAgIExJQl9QQVRI
PSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVjX3ByZWZpeCIgKyAxYH0iCiAKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVf
U09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMiID4mNQotJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMu
Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2Urc2V0fSIg
PSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICB3aGls
ZSA6OyBkbwotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v
KiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+IC8qIGZvciBvZmZf
dCAqLwotICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KLWludAotbWFpbiAoKQotewotaW50ICgqZnAp
IChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwotICAgICByZXR1cm4gZnNlZWtvIChzdGRp
biwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VP
RgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9zeXNfbGFy
Z2VmaWxlX3NvdXJjZT1ubzsgYnJlYWsKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQg
Y29uZmRlZnMuaC4gICovCi0jZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFIDEKLSNpbmNsdWRlIDxz
eXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCi0gICAgICNpbmNsdWRlIDxzdGRpby5oPgotaW50
Ci1tYWluICgpCi17Ci1pbnQgKCpmcCkgKEZJTEUgKiwgb2ZmX3QsIGludCkgPSBmc2Vla287Ci0g
ICAgIHJldHVybiBmc2Vla28gKHN0ZGluLCAwLCAwKSAmJiBmcCAoc3RkaW4sIDAsIDApOwotICA7
Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6Ci0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPTE7IGJyZWFrCiBmaQotcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9dW5r
bm93bgotICBicmVhawotZG9uZQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNQotJGFzX2Vj
aG8gIiRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2OyB9Ci1jYXNlICRhY19jdl9zeXNf
bGFyZ2VmaWxlX3NvdXJjZSBpbiAjKAotICBubyB8IHVua25vd24pIDs7Ci0gICopCi1jYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFICRhY19jdl9zeXNf
bGFyZ2VmaWxlX3NvdXJjZQotX0FDRU9GCi07OwotZXNhYwotcm0gLXJmIGNvbmZ0ZXN0KgotCi0j
IFdlIHVzZWQgdG8gdHJ5IGRlZmluaW5nIF9YT1BFTl9TT1VSQ0U9NTAwIHRvbywgdG8gd29yayBh
cm91bmQgYSBidWcKLSMgaW4gZ2xpYmMgMi4xLjMsIGJ1dCB0aGF0IGJyZWFrcyB0b28gbWFueSBv
dGhlciB0aGluZ3MuCi0jIElmIHlvdSB3YW50IGZzZWVrbyBhbmQgZnRlbGxvIHdpdGggZ2xpYmMs
IHVwZ3JhZGUgdG8gYSBmaXhlZCBnbGliYy4KLWlmIHRlc3QgJGFjX2N2X3N5c19sYXJnZWZpbGVf
c291cmNlICE9IHVua25vd247IHRoZW4KIAotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9GU0VFS08g
MSIgPj5jb25mZGVmcy5oCiAKLWZpCisjIENoZWNrcyBmb3IgbGlicmFyaWVzLgorYWNfZm5fY19j
aGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImJ6bGliLmgiICJhY19jdl9oZWFkZXJfYnps
aWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfYnps
aWJfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMgdHJhaWxp
bmcgc2xhc2giID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0
bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9m
dW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsrc2V0fSIgPSBzZXQ7IHRoZW4g
OgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
QloyX2J6RGVjb21wcmVzc0luaXQgaW4gLWxiejIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIk
e2FjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBzZXQ7IHRoZW4gOgog
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBybSAtZiBjb25mdGVzdC5zeW0g
Y29uZnRlc3QuZmlsZQotZWNobyA+Y29uZnRlc3QuZmlsZQotaWYgdGVzdCAiJGFzX2xuX3MiID0g
ImxuIC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0ZXN0LnN5bTsgdGhlbgotICBpZiB0
ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfbHN0YXRf
ZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubwotZWxzZQotICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKK0xJQlM9Ii1sYnoyICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0
CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy
cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl
IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k
aWYKK2NoYXIgQloyX2J6RGVjb21wcmVzc0luaXQgKCk7CiBpbnQKIG1haW4gKCkKIHsKLXN0cnVj
dCBzdGF0IHNidWY7Ci0gICAgIC8qIExpbnV4IHdpbGwgZGVyZWZlcmVuY2UgdGhlIHN5bWxpbmsg
YW5kIGZhaWwsIGFzIHJlcXVpcmVkIGJ5IFBPU0lYLgotCVRoYXQgaXMgYmV0dGVyIGluIHRoZSBz
ZW5zZSB0aGF0IGl0IG1lYW5zIHdlIHdpbGwgbm90Ci0JaGF2ZSB0byBjb21waWxlIGFuZCB1c2Ug
dGhlIGxzdGF0IHdyYXBwZXIuICAqLwotICAgICByZXR1cm4gbHN0YXQgKCJjb25mdGVzdC5zeW0v
IiwgJnNidWYpID09IDA7CityZXR1cm4gQloyX2J6RGVjb21wcmVzc0luaXQgKCk7CiAgIDsKICAg
cmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4g
OgotICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9eWVzCi1l
bHNlCi0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubwot
ZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29u
ZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNv
bmZ0ZXN0LiRhY19leHQKLWZpCi0KK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVu
IDoKKyAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdD15ZXMKIGVsc2UKLSAgIyBJ
ZiB0aGUgYGxuIC1zJyBjb21tYW5kIGZhaWxlZCwgdGhlbiB3ZSBwcm9iYWJseSBkb24ndCBldmVu
Ci0gICMgaGF2ZSBhbiBsc3RhdCBmdW5jdGlvbi4KLSAgYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVy
ZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCisgIGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVz
c0luaXQ9bm8KIGZpCi1ybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQotCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9i
ejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfYnoy
X0JaMl9iekRlY29tcHJlc3NJbml0IiA9IHgiInllczsgdGhlbiA6CisgIHpsaWI9IiR6bGliIC1E
SEFWRV9CWkxJQiAtbGJ6MiIKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3lt
bGluayIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNo
ZWRfc3ltbGluayIgPiY2OyB9Ci0KLXRlc3QgJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2Vz
X3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0j
ZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LIDEKLV9BQ0VPRgogCitmaQogCi1p
ZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIg
PSB4bm87IHRoZW4KLSAgY2FzZSAiICRMSUJPQkpTICIgaW4KLSAgKiIgbHN0YXQuJGFjX29iamV4
dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIGxzdGF0LiRhY19vYmpleHQiCi0gOzsK
LWVzYWMKIAotZmkKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJsem1h
LmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X2hlYWRlcl9sem1hX2giID0geCIieWVzOyB0aGVuIDoKIAoteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5o
IGRlZmluZXMgbWFrZWRldiIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHN5cy90
eXBlcy5oIGRlZmluZXMgbWFrZWRldi4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFk
ZXJfc3lzX3R5cGVzX2hfbWFrZWRlditzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem1hX3N0cmVhbV9kZWNv
ZGVyIGluIC1sbHptYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgbHptYV9zdHJlYW1f
ZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bWFf
bHptYV9zdHJlYW1fZGVjb2RlcitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxsem1hICAk
TElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKworLyogT3ZlcnJpZGUg
YW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hh
ciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1
aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g
ICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBsem1hX3N0
cmVhbV9kZWNvZGVyICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gbWFrZWRldigwLCAwKTsK
K3JldHVybiBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwogICA7CiAgIHJldHVybiAwOwogfQogX0FD
RU9GCiBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2hlYWRl
cl9zeXNfdHlwZXNfaF9tYWtlZGV2PXllcworICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9k
ZWNvZGVyPXllcwogZWxzZQotICBhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj1ubwor
ICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5vCiBmaQogcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCiAgICAgY29uZnRlc3QkYWNfZXhlZXh0
IGNvbmZ0ZXN0LiRhY19leHQKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYiID4mNQot
JGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIgPiY2OyB9Ci0KLWlm
IHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2ID0gbm87IHRoZW4KLWFjX2Zu
X2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvbWtkZXYuaCIgImFjX2N2X2hl
YWRlcl9zeXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19j
dl9oZWFkZXJfc3lzX21rZGV2X2giID0geCIieWVzOyB0aGVuIDoKLQotJGFzX2VjaG8gIiNkZWZp
bmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCi0KK0xJQlM9JGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlMKIGZpCi0KLQotCi0gIGlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCA9
IG5vOyB0aGVuCi0gICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN5
cy9zeXNtYWNyb3MuaCIgImFjX2N2X2hlYWRlcl9zeXNfc3lzbWFjcm9zX2giICIkYWNfaW5jbHVk
ZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgPSB4
IiJ5ZXM7IHRoZW4gOgotCi0kYXNfZWNobyAiI2RlZmluZSBNQUpPUl9JTl9TWVNNQUNST1MgMSIg
Pj5jb25mZGVmcy5oCi0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXIiID4mNjsgfQoraWYgdGVzdCAi
eCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyIiA9IHgiInllczsgdGhlbiA6Cisg
IHpsaWI9IiR6bGliIC1ESEFWRV9MWk1BIC1sbHptYSIKIGZpCiAKIAotICBmaQogZmkKIAotZm9y
IGFjX2hlYWRlciBpbiBzdGRsaWIuaAotZG8gOgotICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25n
cmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3RkbGliX2giICIkYWNfaW5j
bHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiA9IHgiInll
czsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9TVERM
SUJfSCAxCi1fQUNFT0YKLQotZmkKIAotZG9uZQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgImx6by9sem8xeC5oIiAiYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem9fbHpvMXhfaCIg
PSB4IiJ5ZXM7IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxvYyIgPiY1Ci0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSBtYWxsb2MuLi4gIiA+JjY7IH0K
LWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsK3NldH0iID0gc2V0OyB0aGVu
IDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIg
PSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9bm8KLWVsc2UKLSAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGx6bzIgICRMSUJTIgorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lm
IGRlZmluZWQgU1REQ19IRUFERVJTIHx8IGRlZmluZWQgSEFWRV9TVERMSUJfSAotIyBpbmNsdWRl
IDxzdGRsaWIuaD4KLSNlbHNlCi1jaGFyICptYWxsb2MgKCk7Ci0jZW5kaWYKIAorLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBsem8x
eF9kZWNvbXByZXNzICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gISBtYWxsb2MgKDApOwor
cmV0dXJuIGx6bzF4X2RlY29tcHJlc3MgKCk7CiAgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YK
LWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX21hbGxv
Y18wX25vbm51bGw9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9eWVzCiBlbHNlCi0gIGFjX2N2X2Z1bmNf
bWFsbG9jXzBfbm9ubnVsbD1ubworICBhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPW5v
CiBmaQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBj
b25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0g
Y29uZnRlc3QuJGFjX2V4dAorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA9IHgiInllczsgdGhlbiA6
CisgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCiBmaQoteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX21hbGxvY18wX25v
bm51bGwiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNjsg
fQotaWYgdGVzdCAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKLQot
JGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMSIgPj5jb25mZGVmcy5oCi0KLWVsc2UKLSAg
JGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMCIgPj5jb25mZGVmcy5oCi0KLSAgIGNhc2Ug
IiAkTElCT0JKUyAiIGluCi0gICoiIG1hbGxvYy4kYWNfb2JqZXh0ICIqICkgOzsKLSAgKikgTElC
T0JKUz0iJExJQk9CSlMgbWFsbG9jLiRhY19vYmpleHQiCi0gOzsKLWVzYWMKLQogCi0kYXNfZWNo
byAiI2RlZmluZSBtYWxsb2MgcnBsX21hbGxvYyIgPj5jb25mZGVmcy5oCiAKIGZpCiAKIAoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRp
bWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZCIgPiY1Ci0kYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNs
dWRlZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFkZXJfdGltZStzZXR9IiA9IHNl
dDsgdGhlbiA6CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfYWlv
X2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAor
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGFpbyAgJExJQlMiCitjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRlZnMu
aC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL3RpbWUuaD4KLSNp
bmNsdWRlIDx0aW1lLmg+CiAKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl
IHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg
dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu
dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitl
eHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgaW9fc2V0dXAgKCk7CiBpbnQKIG1haW4gKCkKIHsKLWlm
ICgoc3RydWN0IHRtICopIDApCi1yZXR1cm4gMDsKK3JldHVybiBpb19zZXR1cCAoKTsKICAgOwog
ICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgotICBhY19jdl9oZWFkZXJfdGltZT15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRM
SU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15ZXMKIGVsc2UKLSAgYWNf
Y3ZfaGVhZGVyX3RpbWU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl90aW1lIiA+JjUKLSRhc19lY2hv
ICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3RpbWUg
PSB5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgVElNRV9XSVRIX1NZU19USU1FIDEiID4+
Y29uZmRlZnMuaAotCisgIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9bm8KIGZpCi0KLQotCi0KLSAg
Zm9yIGFjX2hlYWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKLWRvIDoKLSAgYXNfYWNfSGVhZGVyPWAk
YXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAotYWNfZm5fY19j
aGVja19oZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVy
IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQKLSIKLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVh
ZGVyIlwiID0geCJ5ZXMiOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2Rl
ZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YK
LQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29u
ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZl
X0xJQlMKIGZpCi0KLWRvbmUKLQotCi0KLQotCi0KLQotCi0gIGZvciBhY19mdW5jIGluICRhY19m
dW5jX2xpc3QKLWRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVu
YyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIg
IiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsg
dGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJI
QVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VPRgotCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9haW9faW9fc2V0dXAi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjY7IH0KK2lmIHRlc3Qg
IngkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBzeXN0ZW1fYWlv
PSJ5IgorZWxzZQorICBzeXN0ZW1fYWlvPSJuIgogZmkKLWRvbmUKLQogCiAKLQotCi17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1r
dGltZSIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBta3RpbWUuLi4gIiA+
JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY193b3JraW5nX21rdGltZStzZXR9IiA9IHNldDsg
dGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIE1ENSBp
biAtbGNyeXB0by4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfY3J5cHRvX01ENStz
ZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0g
IGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY193
b3JraW5nX21rdGltZT1ubwotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sY3J5
cHRvICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLS8qIFRlc3QgcHJvZ3JhbSBmcm9tIFBhdWwgRWdnZXJ0
IGFuZCBUb255IExlbmVpcy4gICovCi0jaWZkZWYgVElNRV9XSVRIX1NZU19USU1FCi0jIGluY2x1
ZGUgPHN5cy90aW1lLmg+Ci0jIGluY2x1ZGUgPHRpbWUuaD4KLSNlbHNlCi0jIGlmZGVmIEhBVkVf
U1lTX1RJTUVfSAotIyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4KLSMgZWxzZQotIyAgaW5jbHVkZSA8
dGltZS5oPgotIyBlbmRpZgotI2VuZGlmCi0KLSNpbmNsdWRlIDxsaW1pdHMuaD4KLSNpbmNsdWRl
IDxzdGRsaWIuaD4KIAotI2lmZGVmIEhBVkVfVU5JU1REX0gKLSMgaW5jbHVkZSA8dW5pc3RkLmg+
Ci0jZW5kaWYKLQotI2lmbmRlZiBIQVZFX0FMQVJNCi0jIGRlZmluZSBhbGFybShYKSAvKiBlbXB0
eSAqLworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4g
ZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5
cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3
b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKICNl
bmRpZgotCi0vKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24gdG8gcnBsX3B1dGVudiBieSBvdGhl
ciBjb25maWcgdGVzdHMuICAqLwotI3VuZGVmIHB1dGVudgotCi1zdGF0aWMgdGltZV90IHRpbWVf
dF9tYXg7Ci1zdGF0aWMgdGltZV90IHRpbWVfdF9taW47Ci0KLS8qIFZhbHVlcyB3ZSdsbCB1c2Ug
dG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4gICovCi1zdGF0aWMgY29uc3QgY2hh
ciAqdHpfc3RyaW5nc1tdID0gewotICAoY29uc3QgY2hhciAqKSAwLCAiVFo9R01UMCIsICJUWj1K
U1QtOSIsCi0gICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6MDA6MDAsTTIuMy4wLzAwOjAwOjAw
IgotfTsKLSNkZWZpbmUgTl9TVFJJTkdTIChzaXplb2YgKHR6X3N0cmluZ3MpIC8gc2l6ZW9mICh0
el9zdHJpbmdzWzBdKSkKLQotLyogUmV0dXJuIDAgaWYgbWt0aW1lIGZhaWxzIHRvIGNvbnZlcnQg
YSBkYXRlIGluIHRoZSBzcHJpbmctZm9yd2FyZCBnYXAuCi0gICBCYXNlZCBvbiBhIHByb2JsZW0g
cmVwb3J0IGZyb20gQW5kcmVhcyBKYWVnZXIuICAqLwotc3RhdGljIGludAotc3ByaW5nX2Zvcndh
cmRfZ2FwICgpCi17Ci0gIC8qIGdsaWJjICh1cCB0byBhYm91dCAxOTk4LTEwLTA3KSBmYWlsZWQg
dGhpcyB0ZXN0LiAqLwotICBzdHJ1Y3QgdG0gdG07Ci0KLSAgLyogVXNlIHRoZSBwb3J0YWJsZSBQ
T1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCi0gICAgIGlu
c3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBkZXRlY3QgdGhlIGJ1
ZyBldmVuCi0gICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBleHRl
bnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCi0gICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGluc3Rh
bGxlZC4gICovCi0gIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIp
OwotCi0gIHRtLnRtX3llYXIgPSA5ODsKLSAgdG0udG1fbW9uID0gMzsKLSAgdG0udG1fbWRheSA9
IDU7Ci0gIHRtLnRtX2hvdXIgPSAyOwotICB0bS50bV9taW4gPSAwOwotICB0bS50bV9zZWMgPSAw
OwotICB0bS50bV9pc2RzdCA9IC0xOwotICByZXR1cm4gbWt0aW1lICgmdG0pICE9ICh0aW1lX3Qp
IC0xOwotfQotCi1zdGF0aWMgaW50Ci1ta3RpbWVfdGVzdDEgKHRpbWVfdCBub3cpCi17Ci0gIHN0
cnVjdCB0bSAqbHQ7Ci0gIHJldHVybiAhIChsdCA9IGxvY2FsdGltZSAoJm5vdykpIHx8IG1rdGlt
ZSAobHQpID09IG5vdzsKLX0KLQotc3RhdGljIGludAotbWt0aW1lX3Rlc3QgKHRpbWVfdCBub3cp
Ci17Ci0gIHJldHVybiAobWt0aW1lX3Rlc3QxIChub3cpCi0JICAmJiBta3RpbWVfdGVzdDEgKCh0
aW1lX3QpICh0aW1lX3RfbWF4IC0gbm93KSkKLQkgICYmIG1rdGltZV90ZXN0MSAoKHRpbWVfdCkg
KHRpbWVfdF9taW4gKyBub3cpKSk7Ci19Ci0KLXN0YXRpYyBpbnQKLWlyaXhfNl80X2J1ZyAoKQot
ewotICAvKiBCYXNlZCBvbiBjb2RlIGZyb20gQXJpZWwgRmFpZ29uLiAgKi8KLSAgc3RydWN0IHRt
IHRtOwotICB0bS50bV95ZWFyID0gOTY7Ci0gIHRtLnRtX21vbiA9IDM7Ci0gIHRtLnRtX21kYXkg
PSAwOwotICB0bS50bV9ob3VyID0gMDsKLSAgdG0udG1fbWluID0gMDsKLSAgdG0udG1fc2VjID0g
MDsKLSAgdG0udG1faXNkc3QgPSAtMTsKLSAgbWt0aW1lICgmdG0pOwotICByZXR1cm4gdG0udG1f
bW9uID09IDIgJiYgdG0udG1fbWRheSA9PSAzMTsKLX0KLQotc3RhdGljIGludAotYmlndGltZV90
ZXN0IChpbnQgaikKLXsKLSAgc3RydWN0IHRtIHRtOwotICB0aW1lX3Qgbm93OwotICB0bS50bV95
ZWFyID0gdG0udG1fbW9uID0gdG0udG1fbWRheSA9IHRtLnRtX2hvdXIgPSB0bS50bV9taW4gPSB0
bS50bV9zZWMgPSBqOwotICBub3cgPSBta3RpbWUgKCZ0bSk7Ci0gIGlmIChub3cgIT0gKHRpbWVf
dCkgLTEpCi0gICAgewotICAgICAgc3RydWN0IHRtICpsdCA9IGxvY2FsdGltZSAoJm5vdyk7Ci0g
ICAgICBpZiAoISAobHQKLQkgICAgICYmIGx0LT50bV95ZWFyID09IHRtLnRtX3llYXIKLQkgICAg
ICYmIGx0LT50bV9tb24gPT0gdG0udG1fbW9uCi0JICAgICAmJiBsdC0+dG1fbWRheSA9PSB0bS50
bV9tZGF5Ci0JICAgICAmJiBsdC0+dG1faG91ciA9PSB0bS50bV9ob3VyCi0JICAgICAmJiBsdC0+
dG1fbWluID09IHRtLnRtX21pbgotCSAgICAgJiYgbHQtPnRtX3NlYyA9PSB0bS50bV9zZWMKLQkg
ICAgICYmIGx0LT50bV95ZGF5ID09IHRtLnRtX3lkYXkKLQkgICAgICYmIGx0LT50bV93ZGF5ID09
IHRtLnRtX3dkYXkKLQkgICAgICYmICgobHQtPnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IGx0LT50
bV9pc2RzdCkKLQkJICA9PSAodG0udG1faXNkc3QgPCAwID8gLTEgOiAwIDwgdG0udG1faXNkc3Qp
KSkpCi0JcmV0dXJuIDA7Ci0gICAgfQotICByZXR1cm4gMTsKLX0KLQotc3RhdGljIGludAoteWVh
cl8yMDUwX3Rlc3QgKCkKLXsKLSAgLyogVGhlIGNvcnJlY3QgYW5zd2VyIGZvciAyMDUwLTAyLTAx
IDAwOjAwOjAwIGluIFBhY2lmaWMgdGltZSwKLSAgICAgaWdub3JpbmcgbGVhcCBzZWNvbmRzLiAg
Ki8KLSAgdW5zaWduZWQgbG9uZyBpbnQgYW5zd2VyID0gMjUyNzMxNTIwMFVMOwotCi0gIHN0cnVj
dCB0bSB0bTsKLSAgdGltZV90IHQ7Ci0gIHRtLnRtX3llYXIgPSAyMDUwIC0gMTkwMDsKLSAgdG0u
dG1fbW9uID0gMiAtIDE7Ci0gIHRtLnRtX21kYXkgPSAxOwotICB0bS50bV9ob3VyID0gdG0udG1f
bWluID0gdG0udG1fc2VjID0gMDsKLSAgdG0udG1faXNkc3QgPSAtMTsKLQotICAvKiBVc2UgdGhl
IHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUu
MCIKLSAgICAgaW5zdGVhZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRl
dGVjdCB0aGUgYnVnIGV2ZW4KLSAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhl
IE9sc29uIGV4dGVuc2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUKLSAgICAgZnVsbCB6b25laW5mbyB0
YWJsZXMgaW5zdGFsbGVkLiAgKi8KLSAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEu
MCxNMTAuNS4wIik7Ci0KLSAgdCA9IG1rdGltZSAoJnRtKTsKLQotICAvKiBDaGVjayB0aGF0IHRo
ZSByZXN1bHQgaXMgZWl0aGVyIGEgZmFpbHVyZSwgb3IgY2xvc2UgZW5vdWdoCi0gICAgIHRvIHRo
ZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdlIGNhbiBhc3N1bWUgdGhlIGRpc2NyZXBhbmN5IGlzCi0g
ICAgIGR1ZSB0byBsZWFwIHNlY29uZHMuICAqLwotICByZXR1cm4gKHQgPT0gKHRpbWVfdCkgLTEK
LQkgIHx8ICgwIDwgdCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAmJiB0IDw9IGFuc3dlciArIDEyMCkp
OwotfQotCitjaGFyIE1ENSAoKTsKIGludAogbWFpbiAoKQogewotICB0aW1lX3QgdCwgZGVsdGE7
Ci0gIGludCBpLCBqOwotCi0gIC8qIFRoaXMgdGVzdCBtYWtlcyBzb21lIGJ1Z2d5IG1rdGltZSBp
bXBsZW1lbnRhdGlvbnMgbG9vcC4KLSAgICAgR2l2ZSB1cCBhZnRlciA2MCBzZWNvbmRzOyBhIG1r
dGltZSBzbG93ZXIgdGhhbiB0aGF0Ci0gICAgIGlzbid0IHdvcnRoIHVzaW5nIGFueXdheS4gICov
Ci0gIGFsYXJtICg2MCk7Ci0KLSAgZm9yICg7OykKLSAgICB7Ci0gICAgICB0ID0gKHRpbWVfdF9t
YXggPDwgMSkgKyAxOwotICAgICAgaWYgKHQgPD0gdGltZV90X21heCkKLQlicmVhazsKLSAgICAg
IHRpbWVfdF9tYXggPSB0OwotICAgIH0KLSAgdGltZV90X21pbiA9IC0gKCh0aW1lX3QpIH4gKHRp
bWVfdCkgMCA9PSAodGltZV90KSAtMSkgLSB0aW1lX3RfbWF4OwotCi0gIGRlbHRhID0gdGltZV90
X21heCAvIDk5NzsgLyogYSBzdWl0YWJsZSBwcmltZSBudW1iZXIgKi8KLSAgZm9yIChpID0gMDsg
aSA8IE5fU1RSSU5HUzsgaSsrKQotICAgIHsKLSAgICAgIGlmICh0el9zdHJpbmdzW2ldKQotCXB1
dGVudiAoKGNoYXIqKSB0el9zdHJpbmdzW2ldKTsKLQotICAgICAgZm9yICh0ID0gMDsgdCA8PSB0
aW1lX3RfbWF4IC0gZGVsdGE7IHQgKz0gZGVsdGEpCi0JaWYgKCEgbWt0aW1lX3Rlc3QgKHQpKQot
CSAgcmV0dXJuIDE7Ci0gICAgICBpZiAoISAobWt0aW1lX3Rlc3QgKCh0aW1lX3QpIDEpCi0JICAg
ICAmJiBta3RpbWVfdGVzdCAoKHRpbWVfdCkgKDYwICogNjApKQotCSAgICAgJiYgbWt0aW1lX3Rl
c3QgKCh0aW1lX3QpICg2MCAqIDYwICogMjQpKSkpCi0JcmV0dXJuIDE7Ci0KLSAgICAgIGZvciAo
aiA9IDE7IDsgaiA8PD0gMSkKLQlpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQotCSAgcmV0dXJuIDE7
Ci0JZWxzZSBpZiAoSU5UX01BWCAvIDIgPCBqKQotCSAgYnJlYWs7Ci0gICAgICBpZiAoISBiaWd0
aW1lX3Rlc3QgKElOVF9NQVgpKQotCXJldHVybiAxOwotICAgIH0KLSAgcmV0dXJuICEgKGlyaXhf
Nl80X2J1ZyAoKSAmJiBzcHJpbmdfZm9yd2FyZF9nYXAgKCkgJiYgeWVhcl8yMDUwX3Rlc3QgKCkp
OworcmV0dXJuIE1ENSAoKTsKKyAgOworICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5f
Y190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWU9
eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9j
cnlwdG9fTUQ1PXllcwogZWxzZQotICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCi1maQot
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAotZmkKLQorICBhY19jdl9saWJfY3J5cHRvX01ENT1ubwogZmkKLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY193b3Jr
aW5nX21rdGltZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4m
NjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVuY193b3JraW5nX21rdGltZSA9IG5vOyB0aGVuCi0gIGNh
c2UgIiAkTElCT0JKUyAiIGluCi0gICoiIG1rdGltZS4kYWNfb2JqZXh0ICIqICkgOzsKLSAgKikg
TElCT0JKUz0iJExJQk9CSlMgbWt0aW1lLiRhY19vYmpleHQiCi0gOzsKLWVzYWMKLQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZp
Ci0KLQotCi0KLQotCi1mb3IgYWNfZnVuYyBpbiBnZXRwYWdlc2l6ZQotZG8gOgotICBhY19mbl9j
X2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6ZSIgImFjX2N2X2Z1bmNfZ2V0cGFnZXNp
emUiCi1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiID0geCIieWVzOyB0aGVuIDoK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX2NyeXB0b19NRDUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY2
OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9IHgiInllczsgdGhlbiA6CiAg
IGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9HRVRQQUdFU0laRSAxCisj
ZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKIF9BQ0VPRgogCisgIExJQlM9Ii1sY3J5cHRvICRMSUJT
IgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJjcnlwdG8iICIk
TElORU5PIiA1CiBmaQotZG9uZQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX21t
YXBfZml4ZWRfbWFwcGVkK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJm
cyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZz
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yK3Nl
dH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAg
aWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX21t
YXBfZml4ZWRfbWFwcGVkPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxl
eHQyZnMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLS8qIG1hbGxv
YyBtaWdodCBoYXZlIGJlZW4gcmVuYW1lZCBhcyBycGxfbWFsbG9jLiAqLwotI3VuZGVmIG1hbGxv
YwotCi0vKiBUaGFua3MgdG8gTWlrZSBIYWVydGVsIGFuZCBKaW0gQXZlcmEgZm9yIHRoaXMgdGVz
dC4KLSAgIEhlcmUgaXMgYSBtYXRyaXggb2YgbW1hcCBwb3NzaWJpbGl0aWVzOgotCW1tYXAgcHJp
dmF0ZSBub3QgZml4ZWQKLQltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJlbnRs
eSB1bm1hcHBlZAotCW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBw
ZWQKLQltbWFwIHNoYXJlZCBub3QgZml4ZWQKLQltbWFwIHNoYXJlZCBmaXhlZCBhdCBzb21ld2hl
cmUgY3VycmVudGx5IHVubWFwcGVkCi0JbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGFs
cmVhZHkgbWFwcGVkCi0gICBGb3IgcHJpdmF0ZSBtYXBwaW5ncywgd2Ugc2hvdWxkIHZlcmlmeSB0
aGF0IGNoYW5nZXMgY2Fubm90IGJlIHJlYWQoKQotICAgYmFjayBmcm9tIHRoZSBmaWxlLCBub3Ig
bW1hcCdzIGJhY2sgZnJvbSB0aGUgZmlsZSBhdCBhIGRpZmZlcmVudAotICAgYWRkcmVzcy4gIChU
aGVyZSBoYXZlIGJlZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRlIHdhcyBub3QgY29ycmVjdGx5Ci0g
ICBpbXBsZW1lbnRlZCBsaWtlIHRoZSBpbmZhbW91cyBpMzg2IHN2cjQuMCwgYW5kIHN5c3RlbXMg
d2hlcmUgdGhlCi0gICBWTSBwYWdlIGNhY2hlIHdhcyBub3QgY29oZXJlbnQgd2l0aCB0aGUgZmls
ZSBzeXN0ZW0gYnVmZmVyIGNhY2hlCi0gICBsaWtlIGVhcmx5IHZlcnNpb25zIG9mIEZyZWVCU0Qg
YW5kIHBvc3NpYmx5IGNvbnRlbXBvcmFyeSBOZXRCU0QuKQotICAgRm9yIHNoYXJlZCBtYXBwaW5n
cywgd2Ugc2hvdWxkIGNvbnZlcnNlbHkgdmVyaWZ5IHRoYXQgY2hhbmdlcyBnZXQKLSAgIHByb3Bh
Z2F0ZWQgYmFjayB0byBhbGwgdGhlIHBsYWNlcyB0aGV5J3JlIHN1cHBvc2VkIHRvIGJlLgotCi0g
ICBHcmVwIHdhbnRzIHByaXZhdGUgZml4ZWQgYWxyZWFkeSBtYXBwZWQuCi0gICBUaGUgbWFpbiB0
aGluZ3MgZ3JlcCBuZWVkcyB0byBrbm93IGFib3V0IG1tYXAgYXJlOgotICAgKiBkb2VzIGl0IGV4
aXN0IGFuZCBpcyBpdCBzYWZlIHRvIHdyaXRlIGludG8gdGhlIG1tYXAnZCBhcmVhCi0gICAqIGhv
dyB0byB1c2UgaXQgKEJTRCB2YXJpYW50cykgICovCi0KLSNpbmNsdWRlIDxmY250bC5oPgotI2lu
Y2x1ZGUgPHN5cy9tbWFuLmg+Ci0KLSNpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMgJiYgIWRlZmlu
ZWQgSEFWRV9TVERMSUJfSAotY2hhciAqbWFsbG9jICgpOwotI2VuZGlmCi0KLS8qIFRoaXMgbWVz
cyB3YXMgY29waWVkIGZyb20gdGhlIEdOVSBnZXRwYWdlc2l6ZS5oLiAgKi8KLSNpZm5kZWYgSEFW
RV9HRVRQQUdFU0laRQotIyBpZmRlZiBfU0NfUEFHRVNJWkUKLSMgIGRlZmluZSBnZXRwYWdlc2l6
ZSgpIHN5c2NvbmYoX1NDX1BBR0VTSVpFKQotIyBlbHNlIC8qIG5vIF9TQ19QQUdFU0laRSAqLwot
IyAgaWZkZWYgSEFWRV9TWVNfUEFSQU1fSAotIyAgIGluY2x1ZGUgPHN5cy9wYXJhbS5oPgotIyAg
IGlmZGVmIEVYRUNfUEFHRVNJWkUKLSMgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgRVhFQ19QQUdF
U0laRQotIyAgIGVsc2UgLyogbm8gRVhFQ19QQUdFU0laRSAqLwotIyAgICBpZmRlZiBOQlBHCi0j
ICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBOQlBHICogQ0xTSVpFCi0jICAgICBpZm5kZWYgQ0xT
SVpFCi0jICAgICAgZGVmaW5lIENMU0laRSAxCi0jICAgICBlbmRpZiAvKiBubyBDTFNJWkUgKi8K
LSMgICAgZWxzZSAvKiBubyBOQlBHICovCi0jICAgICBpZmRlZiBOQlBDCi0jICAgICAgZGVmaW5l
IGdldHBhZ2VzaXplKCkgTkJQQwotIyAgICAgZWxzZSAvKiBubyBOQlBDICovCi0jICAgICAgaWZk
ZWYgUEFHRVNJWkUKLSMgICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgUEFHRVNJWkUKLSMgICAg
ICBlbmRpZiAvKiBQQUdFU0laRSAqLwotIyAgICAgZW5kaWYgLyogbm8gTkJQQyAqLwotIyAgICBl
bmRpZiAvKiBubyBOQlBHICovCi0jICAgZW5kaWYgLyogbm8gRVhFQ19QQUdFU0laRSAqLwotIyAg
ZWxzZSAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCi0jICAgZGVmaW5lIGdldHBhZ2VzaXplKCkg
ODE5MgkvKiBwdW50IHRvdGFsbHkgKi8KLSMgIGVuZGlmIC8qIG5vIEhBVkVfU1lTX1BBUkFNX0gg
Ki8KLSMgZW5kaWYgLyogbm8gX1NDX1BBR0VTSVpFICovCi0KLSNlbmRpZiAvKiBubyBIQVZFX0dF
VFBBR0VTSVpFICovCiAKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRv
IGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl
IHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBw
cm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRl
cm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0MmZzX29wZW4yICgpOwogaW50CiBtYWluICgpCiB7Ci0g
IGNoYXIgKmRhdGEsICpkYXRhMiwgKmRhdGEzOwotICBjb25zdCBjaGFyICpjZGF0YTI7Ci0gIGlu
dCBpLCBwYWdlc2l6ZTsKLSAgaW50IGZkLCBmZDI7Ci0KLSAgcGFnZXNpemUgPSBnZXRwYWdlc2l6
ZSAoKTsKLQotICAvKiBGaXJzdCwgbWFrZSBhIGZpbGUgd2l0aCBzb21lIGtub3duIGdhcmJhZ2Ug
aW4gaXQuICovCi0gIGRhdGEgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsKLSAgaWYgKCFk
YXRhKQotICAgIHJldHVybiAxOwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKLSAg
ICAqKGRhdGEgKyBpKSA9IHJhbmQgKCk7Ci0gIHVtYXNrICgwKTsKLSAgZmQgPSBjcmVhdCAoImNv
bmZ0ZXN0Lm1tYXAiLCAwNjAwKTsKLSAgaWYgKGZkIDwgMCkKLSAgICByZXR1cm4gMjsKLSAgaWYg
KHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2VzaXplKQotICAgIHJldHVybiAzOwot
ICBjbG9zZSAoZmQpOwotCi0gIC8qIE5leHQsIGNoZWNrIHRoYXQgdGhlIHRhaWwgb2YgYSBwYWdl
IGlzIHplcm8tZmlsbGVkLiAgRmlsZSBtdXN0IGhhdmUKLSAgICAgbm9uLXplcm8gbGVuZ3RoLCBv
dGhlcndpc2Ugd2UgcmlzayBTSUdCVVMgZm9yIGVudGlyZSBwYWdlLiAgKi8KLSAgZmQyID0gb3Bl
biAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQgfCBPX1RSVU5DLCAwNjAwKTsKLSAg
aWYgKGZkMiA8IDApCi0gICAgcmV0dXJuIDQ7Ci0gIGNkYXRhMiA9ICIiOwotICBpZiAod3JpdGUg
KGZkMiwgY2RhdGEyLCAxKSAhPSAxKQotICAgIHJldHVybiA1OwotICBkYXRhMiA9IChjaGFyICop
IG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dSSVRFLCBNQVBfU0hBUkVELCBm
ZDIsIDBMKTsKLSAgaWYgKGRhdGEyID09IE1BUF9GQUlMRUQpCi0gICAgcmV0dXJuIDY7Ci0gIGZv
ciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQotICAgIGlmICgqKGRhdGEyICsgaSkpCi0gICAg
ICByZXR1cm4gNzsKLSAgY2xvc2UgKGZkMik7Ci0gIGlmIChtdW5tYXAgKGRhdGEyLCBwYWdlc2l6
ZSkpCi0gICAgcmV0dXJuIDg7Ci0KLSAgLyogTmV4dCwgdHJ5IHRvIG1tYXAgdGhlIGZpbGUgYXQg
YSBmaXhlZCBhZGRyZXNzIHdoaWNoIGFscmVhZHkgaGFzCi0gICAgIHNvbWV0aGluZyBlbHNlIGFs
bG9jYXRlZCBhdCBpdC4gIElmIHdlIGNhbiwgYWxzbyBtYWtlIHN1cmUgdGhhdAotICAgICB3ZSBz
ZWUgdGhlIHNhbWUgZ2FyYmFnZS4gICovCi0gIGZkID0gb3BlbiAoImNvbmZ0ZXN0Lm1tYXAiLCBP
X1JEV1IpOwotICBpZiAoZmQgPCAwKQotICAgIHJldHVybiA5OwotICBpZiAoZGF0YTIgIT0gbW1h
cCAoZGF0YTIsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dSSVRFLAotCQkgICAgIE1BUF9Q
UklWQVRFIHwgTUFQX0ZJWEVELCBmZCwgMEwpKQotICAgIHJldHVybiAxMDsKLSAgZm9yIChpID0g
MDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgaWYgKCooZGF0YSArIGkpICE9ICooZGF0YTIgKyBp
KSkKLSAgICAgIHJldHVybiAxMTsKLQotICAvKiBGaW5hbGx5LCBtYWtlIHN1cmUgdGhhdCBjaGFu
Z2VzIHRvIHRoZSBtYXBwZWQgYXJlYSBkbyBub3QKLSAgICAgcGVyY29sYXRlIGJhY2sgdG8gdGhl
IGZpbGUgYXMgc2VlbiBieSByZWFkKCkuICAoVGhpcyBpcyBhIGJ1ZyBvbgotICAgICBzb21lIHZh
cmlhbnRzIG9mIGkzODYgc3ZyNC4wLikgICovCi0gIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsg
KytpKQotICAgICooZGF0YTIgKyBpKSA9ICooZGF0YTIgKyBpKSArIDE7Ci0gIGRhdGEzID0gKGNo
YXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7Ci0gIGlmICghZGF0YTMpCi0gICAgcmV0dXJuIDEyOwot
ICBpZiAocmVhZCAoZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0gcGFnZXNpemUpCi0gICAgcmV0dXJu
IDEzOwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKLSAgICBpZiAoKihkYXRhICsg
aSkgIT0gKihkYXRhMyArIGkpKQotICAgICAgcmV0dXJuIDE0OwotICBjbG9zZSAoZmQpOworcmV0
dXJuIGV4dDJmc19vcGVuMiAoKTsKKyAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNf
Zm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9t
YXBwZWQ9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2
X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcwogZWxzZQotICBhY19jdl9mdW5jX21tYXBfZml4
ZWRfbWFwcGVkPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24u
b3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKLQorICBhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMj1ubwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCIgPiY1Ci0kYXNfZWNobyAi
JGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfZnVu
Y19tbWFwX2ZpeGVkX21hcHBlZCA9IHllczsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBIQVZF
X01NQVAgMSIgPj5jb25mZGVmcy5oCi0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitM
SUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotcm0gLWYgY29uZnRlc3QubW1hcCBjb25m
dGVzdC50eHQKLQotZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAotZG8gOgotICBhY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3Rk
bGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0
ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNk
ZWZpbmUgSEFWRV9TVERMSUJfSCAxCi1fQUNFT0YKLQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIg
PiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjY7IH0KK2lm
IHRlc3QgIngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID0geCIieWVzOyB0aGVuIDoK
KyAgbGliZXh0MmZzPSJ5IgorZWxzZQorICBsaWJleHQyZnM9Im4iCiBmaQogCi1kb25lCiAKLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEdOVSBs
aWJjIGNvbXBhdGlibGUgcmVhbGxvYyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgR05V
IGxpYmMgY29tcGF0aWJsZSByZWFsbG9jLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2Z1
bmNfcmVhbGxvY18wX25vbm51bGwrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZl
ciBpbiAtbGdjcnlwdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNo
X2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfZ2Ny
eXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHll
czsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9bm8KLWVsc2UKLSAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJf
c2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGdjcnlwdCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWYg
ZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICi0jIGluY2x1ZGUg
PHN0ZGxpYi5oPgotI2Vsc2UKLWNoYXIgKnJlYWxsb2MgKCk7Ci0jZW5kaWYKIAorLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBnY3J5
X21kX2hhc2hfYnVmZmVyICgpOwogaW50CiBtYWluICgpCiB7Ci1yZXR1cm4gISByZWFsbG9jICgw
LCAwKTsKK3JldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwogICA7CiAgIHJldHVybiAwOwog
fQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zf
ZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyPXllcwogZWxz
ZQotICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCisgIGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwogZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRl
c3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25m
dGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5
cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJnY3J5cHQ9InkiCitl
bHNlCisgIGxpYmdjcnlwdD0ibiIKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNQotJGFz
X2VjaG8gIiRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KLWlmIHRlc3QgJGFj
X2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwgPSB5ZXM7IHRoZW4gOgogCi0kYXNfZWNobyAiI2Rl
ZmluZSBIQVZFX1JFQUxMT0MgMSIgPj5jb25mZGVmcy5oCiAKKworICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZyIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZCBmbGFnLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2F4X2N2X3B0aHJlYWRfZmxhZ3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX1JFQUxM
T0MgMCIgPj5jb25mZGVmcy5oCiAKLSAgIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIHJlYWxs
b2MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRMSUJPQkpTIHJlYWxsb2MuJGFj
X29iamV4dCIKLSA7OwotZXNhYworICAgICAgICBheF9jdl9wdGhyZWFkX2ZsYWdzPS1wdGhyZWFk
CisKKyAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVB
RF9MREZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKKyAgICBQVEhSRUFEX0xJQlM9IiIKKwor
CisgICAgc2F2ZWRfQ0ZMQUdTPSIkQ0ZMQUdTIgorCisgICAgc2F2ZWRfTERGTEFHUz0iJExERkxB
R1MiCisKKyAgICBzYXZlZF9MSUJTPSIkTElCUyIKKworCisgICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQ
VEhSRUFEX0NGTEFHUyIKKworICAgIExERkxBR1M9IiRMREZMQUdTICRQVEhSRUFEX0xERkxBR1Mi
CisKKyAgICBMSUJTPSIkTElCUyAkUFRIUkVBRF9MSUJTIgorCisgICAgICAgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworI2luY2x1ZGUgPHB0aHJlYWQuaD4KK2ludCBtYWluKHZvaWQpIHsKKyAgcHRocmVhZF9hdGZv
cmsoMCwwLDApOworICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCwwKTsKK30KKworX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYXhfY3ZfcHRocmVh
ZF9mbGFncz1mYWlsZWQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorCisgICAg
Q0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgorCisgICAgTERGTEFHUz0iJHNhdmVkX0xERkxBR1MiCiAK
KyAgICBMSUJTPSIkc2F2ZWRfTElCUyIKIAotJGFzX2VjaG8gIiNkZWZpbmUgcmVhbGxvYyBycGxf
cmVhbGxvYyIgPj5jb25mZGVmcy5oCiAKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQorJGFzX2VjaG8g
IiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7IH0KKyAgICBpZiB0ZXN0ICJ4JGF4X2N2X3B0aHJl
YWRfZmxhZ3MiID0geGZhaWxlZDsgdGhlbgorICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0aHJl
YWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKKyAgICBmaQorCisgICAgUFRIUkVBRF9DRkxB
R1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgorICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0
aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MSUJTPSIiCisKIAogCi17ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4iID4m
NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3Rybmxlbi4uLiAiID4mNjsgfQot
aWYgdGVzdCAiJHthY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZytzZXR9IiA9IHNldDsgdGhlbiA6
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB5
YWpsX2FsbG9jIGluIC1seWFqbCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgeWFqbF9h
bGxvYyBpbiAtbHlhamwuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3lhamxfeWFq
bF9hbGxvYytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNf
Y3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitM
SUJTPSItbHlhamwgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciB5YWpsX2FsbG9jICgpOwogaW50CiBtYWluICgpCiB7Ci0KLSNkZWZpbmUgUyAiZm9vYmFy
IgotI2RlZmluZSBTX0xFTiAoc2l6ZW9mIFMgLSAxKQotCi0gIC8qIEF0IGxlYXN0IG9uZSBpbXBs
ZW1lbnRhdGlvbiBpcyBidWdneTogdGhhdCBvZiBBSVggNC4zIHdvdWxkCi0gICAgIGdpdmUgc3Ry
bmxlbiAoUywgMSkgPT0gMy4gICovCi0KLSAgaW50IGk7Ci0gIGZvciAoaSA9IDA7IGkgPCBTX0xF
TiArIDE7ICsraSkKLSAgICB7Ci0gICAgICBpbnQgZXhwZWN0ZWQgPSBpIDw9IFNfTEVOID8gaSA6
IFNfTEVOOwotICAgICAgaWYgKHN0cm5sZW4gKFMsIGkpICE9IGV4cGVjdGVkKQotCXJldHVybiAx
OwotICAgIH0KLSAgcmV0dXJuIDA7Ci0KK3JldHVybiB5YWpsX2FsbG9jICgpOwogICA7CiAgIHJl
dHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoK
LSAgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCiBlbHNlCi0g
IGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nPW5vCisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxs
b2M9bm8KIGZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIu
b3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu
YmVhbSBjb25mdGVzdC4kYWNfZXh0CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElC
Uz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQoraWYgdGVzdCAieCRh
Y19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHgiInllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKK19BQ0VPRgogCi1maQoteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5j
X3N0cm5sZW5fd29ya2luZyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3Jr
aW5nIiA+JjY7IH0KLXRlc3QgJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nID0gbm8gJiYgY2Fz
ZSAiICRMSUJPQkpTICIgaW4KLSAgKiIgc3Rybmxlbi4kYWNfb2JqZXh0ICIqICkgOzsKLSAgKikg
TElCT0JKUz0iJExJQk9CSlMgc3Rybmxlbi4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCisgIExJQlM9
Ii1seWFqbCAkTElCUyIKIAorZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQg
eWFqbCIgIiRMSU5FTk8iIDUKK2ZpCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9kIiA+JjUKLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9m
dW5jX3N0cnRvZCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHoiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1sei4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9saWJfel9kZWZsYXRlQ29weStzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxp
bmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KLWVsc2UKLSAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2
ZV9MSUJTPSRMSUJTCitMSUJTPSItbHogICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwogCi0kYWNfaW5jbHVk
ZXNfZGVmYXVsdAotI2lmbmRlZiBzdHJ0b2QKLWRvdWJsZSBzdHJ0b2QgKCk7CisvKiBPdmVycmlk
ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBj
aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAg
YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5
LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgogI2VuZGlmCitjaGFyIGRlZmxh
dGVDb3B5ICgpOwogaW50Ci1tYWluKCkKK21haW4gKCkKIHsKLSAgewotICAgIC8qIFNvbWUgdmVy
c2lvbnMgb2YgTGludXggc3RydG9kIG1pcy1wYXJzZSBzdHJpbmdzIHdpdGggbGVhZGluZyAnKycu
ICAqLwotICAgIGNoYXIgKnN0cmluZyA9ICIgKzY5IjsKLSAgICBjaGFyICp0ZXJtOwotICAgIGRv
dWJsZSB2YWx1ZTsKLSAgICB2YWx1ZSA9IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Ci0gICAgaWYg
KHZhbHVlICE9IDY5IHx8IHRlcm0gIT0gKHN0cmluZyArIDQpKQotICAgICAgcmV0dXJuIDE7Ci0g
IH0KLQotICB7Ci0gICAgLyogVW5kZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5zIHRoZSB3
cm9uZyB2YWx1ZSBmb3IgdGhlCi0gICAgICAgdGVybWluYXRpbmcgY2hhcmFjdGVyIHVuZGVyIHNv
bWUgY29uZGl0aW9ucy4gICovCi0gICAgY2hhciAqc3RyaW5nID0gIk5hTiI7Ci0gICAgY2hhciAq
dGVybTsKLSAgICBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOwotICAgIGlmICh0ZXJtICE9IHN0cmlu
ZyAmJiAqKHRlcm0gLSAxKSA9PSAwKQotICAgICAgcmV0dXJuIDE7Ci0gIH0KK3JldHVybiBkZWZs
YXRlQ29weSAoKTsKKyAgOwogICByZXR1cm4gMDsKIH0KLQogX0FDRU9GCi1pZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19zdHJ0b2Q9eWVzCitpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5
PXllcwogZWxzZQotICBhY19jdl9mdW5jX3N0cnRvZD1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3Jl
IGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKKyAgYWNf
Y3ZfbGliX3pfZGVmbGF0ZUNvcHk9bm8KIGZpCi0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf
ZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3N0cnRvZCIgPiY1Ci0k
YXNfZWNobyAiJGFjX2N2X2Z1bmNfc3RydG9kIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2Z1bmNf
c3RydG9kID0gbm87IHRoZW4KLSAgY2FzZSAiICRMSUJPQkpTICIgaW4KLSAgKiIgc3RydG9kLiRh
Y19vYmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBzdHJ0b2QuJGFjX29iamV4
dCIKLSA7OwotZXNhYworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xp
Yl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3pfZGVmbGF0ZUNv
cHkiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBIQVZFX0xJQlogMQorX0FDRU9GCiAKLWFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgInBv
dyIgImFjX2N2X2Z1bmNfcG93IgotaWYgdGVzdCAieCRhY19jdl9mdW5jX3BvdyIgPSB4IiJ5ZXM7
IHRoZW4gOgorICBMSUJTPSItbHogJExJQlMiCiAKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNv
dWxkIG5vdCBmaW5kIHpsaWIiICIkTElORU5PIiA1CiBmaQogCi1pZiB0ZXN0ICRhY19jdl9mdW5j
X3BvdyA9IG5vOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIHBvdyBpbiAtbG0iID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IHBvdyBpbiAtbG0uLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX21fcG93K3NldH0i
ID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udiIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252Li4uICIgPiY2OyB9CitpZiB0ZXN0
ICIke2FjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuK3NldH0iID0gc2V0OyB0aGVuIDoKICAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKICAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUwotTElCUz0iLWxtICAkTElCUyIKK0xJQlM9Ii1saWNvbnYgICRMSUJTIgogY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwogCkBAIC05NTI4LDU1ICs2NTUzLDQ1IEBAIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKICNpZmRlZiBfX2NwbHVzcGx1cwogZXh0ZXJuICJDIgogI2VuZGlm
Ci1jaGFyIHBvdyAoKTsKK2NoYXIgbGliaWNvbnZfb3BlbiAoKTsKIGludAogbWFpbiAoKQogewot
cmV0dXJuIHBvdyAoKTsKK3JldHVybiBsaWJpY29udl9vcGVuICgpOwogICA7CiAgIHJldHVybiAw
OwogfQogX0FDRU9GCiBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFj
X2N2X2xpYl9tX3Bvdz15ZXMKKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49eWVzCiBl
bHNlCi0gIGFjX2N2X2xpYl9tX3Bvdz1ubworICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Bl
bj1ubwogZmkKIHJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAog
ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CiBMSUJTPSRhY19jaGVja19s
aWJfc2F2ZV9MSUJTCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9saWJfbV9wb3ciID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfbV9w
b3ciID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfbV9wb3ciID0geCIieWVzOyB0aGVuIDoK
LSAgUE9XX0xJQj0tbG0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNQorJGFzX2VjaG8gIiRh
Y19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9pY29udl9saWJpY29udl9vcGVuIiA9IHgiInllczsgdGhlbiA6CisgIGxpYmljb252PSJ5Igog
ZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6
IGNhbm5vdCBmaW5kIGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9mIHBvdyIgPiY1Ci0k
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcg
ZGVmaW5pdGlvbiBvZiBwb3ciID4mMjt9Ci1maQotCisgIGxpYmljb252PSJuIgogZmkKIAotZmkK
IAotZm9yIGFjX2Z1bmMgaW4gIFwKLSAgICAgICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8g
Y2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3luYyBmdHJ1bmNhdGUgXAotICAgICAgICAgICAgICAg
IGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhvc3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRh
eSBcCi0gICAgICAgICAgICAgICAgaW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hy
IG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKLSAgICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBh
dGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2VsZWN0IHNldGVudiBcCi0gICAgICAgICAg
ICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0
cm5kdXAgXAotICAgICAgICAgICAgICAgIHN0cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0
cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0IFwKLSAgICAgICAgICAgICAgICB1bmFtZSBcCiAK
KyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCitmb3IgYWNfaGVhZGVyIGluIHlhamwveWFqbF92
ZXJzaW9uLmgKIGRvIDoKLSAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVu
YyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIg
IiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsg
dGhlbiA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJ5YWpsL3lh
amxfdmVyc2lvbi5oIiAiYWNfY3ZfaGVhZGVyX3lhamxfeWFqbF92ZXJzaW9uX2giICIkYWNfaW5j
bHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3lhamxfeWFqbF92ZXJzaW9u
X2giID0geCIieWVzOyB0aGVuIDoKICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmlu
ZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1bmMiIHwgJGFzX3RyX2NwcGAgMQorI2RlZmluZSBIQVZF
X1lBSkxfWUFKTF9WRVJTSU9OX0ggMQogX0FDRU9GCiAKIGZpCisKIGRvbmUKIAogCmRpZmYgLS1n
aXQgYS90b29scy9jb25maWd1cmUuYWMgYi90b29scy9jb25maWd1cmUuYWMKaW5kZXggNTdjODg3
ZC4uZGViODQ4ZCAxMDA2NDQKLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCisrKyBiL3Rvb2xzL2Nv
bmZpZ3VyZS5hYwpAQCAtMTksOSArMTksNiBAQCByZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5D
TFVERVMsIFBSRVBFTkRfTElCLCBcCiBBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5z
dGVhZCB3aGVuIHBvc3NpYmxlLl0pCiBdKQogCi1BQ19VU0VfU1lTVEVNX0VYVEVOU0lPTlMKLUFD
X0NBTk9OSUNBTF9IT1NUCi0KICMgTTQgTWFjcm8gaW5jbHVkZXMKIG00X2luY2x1ZGUoW200L3Nh
dmV2YXIubTRdKQogbTRfaW5jbHVkZShbbTQvZmVhdHVyZXMubTRdKQpAQCAtNzUsOSArNzIsNyBA
QCBBQ19BUkdfVkFSKFtCQ0NdLCBbUGF0aCB0byBiY2MgdG9vbF0pCiBBQ19BUkdfVkFSKFtJQVNM
XSwgW1BhdGggdG8gaWFzbCB0b29sXSkKIAogIyBDaGVja3MgZm9yIHByb2dyYW1zLgotQUNfUFJP
R19TRUQKIEFDX1BST0dfQ0MKLUFDX1BST0dfTE5fUwogQUNfUFJPR19NQUtFX1NFVAogQUNfUFJP
R19JTlNUQUxMCiBBQ19QQVRIX1BST0coW0JJU09OXSwgW2Jpc29uXSkKQEAgLTEzNyw3ICsxMzIs
NiBAQCBBQ19TVUJTVChsaWJleHQyZnMpCiBBQ19DSEVDS19MSUIoW2djcnlwdF0sIFtnY3J5X21k
X2hhc2hfYnVmZmVyXSwgW2xpYmdjcnlwdD0ieSJdLCBbbGliZ2NyeXB0PSJuIl0pCiBBQ19TVUJT
VChsaWJnY3J5cHQpCiBBWF9DSEVDS19QVEhSRUFECi1BQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2Nr
X2dldHRpbWVdKQogQUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwKICAgICBb
QUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5YWpsXSldKQogQUNfQ0hFQ0tfTElCKFt6XSwg
W2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0p
CkBAIC0xNDUsNTggKzEzOSw2IEBAIEFDX0NIRUNLX0xJQihbaWNvbnZdLCBbbGliaWNvbnZfb3Bl
bl0sIFtsaWJpY29udj0ieSJdLCBbbGliaWNvbnY9Im4iXSkKIEFDX1NVQlNUKGxpYmljb252KQog
CiAjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgotQUNfRlVOQ19BTExPQ0EKLUFDX0NIRUNLX0hF
QURFUlMoWyBcCi0gICAgICAgICAgICAgICAgYXJwYS9pbmV0LmggZmNudGwuaCBpbnR0eXBlcy5o
IGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCi0gICAgICAgICAgICAgICAgbmV0ZGIuaCBu
ZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50Lmggc3RkbGliLmggc3RyaW5nLmggXAotICAgICAg
ICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5oIHN5cy9tb3VudC5oIHN5
cy9wYXJhbS5oIFwKLSAgICAgICAgICAgICAgICBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBz
eXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCi0gICAgICAgICAgICAgICAgdW5pc3RkLmgg
eWFqbC95YWpsX3ZlcnNpb24uaCBcCi0gICAgICAgICAgICAgICAgXSkKLQotIyBDaGVja3MgZm9y
IHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgotQUNf
SEVBREVSX1NUREJPT0wKLUFDX1RZUEVfVUlEX1QKLUFDX0NfSU5MSU5FCi1BQ19UWVBFX0lOVDE2
X1QKLUFDX1RZUEVfSU5UMzJfVAotQUNfVFlQRV9JTlQ2NF9UCi1BQ19UWVBFX0lOVDhfVAotQUNf
VFlQRV9NT0RFX1QKLUFDX1RZUEVfT0ZGX1QKLUFDX1RZUEVfUElEX1QKLUFDX0NfUkVTVFJJQ1QK
LUFDX1RZUEVfU0laRV9UCi1BQ19UWVBFX1NTSVpFX1QKLUFDX0NIRUNLX01FTUJFUlMoW3N0cnVj
dCBzdGF0LnN0X2Jsa3NpemVdKQotQUNfU1RSVUNUX1NUX0JMT0NLUwotQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCi1BQ19UWVBFX1VJTlQxNl9UCi1BQ19UWVBFX1VJTlQz
Ml9UCi1BQ19UWVBFX1VJTlQ2NF9UCi1BQ19UWVBFX1VJTlQ4X1QKLUFDX0NIRUNLX1RZUEVTKFtw
dHJkaWZmX3RdKQotCi0jIENoZWNrcyBmb3IgbGlicmFyeSBmdW5jdGlvbnMuCi1BQ19GVU5DX0VS
Uk9SX0FUX0xJTkUKLUFDX0ZVTkNfRk9SSwotQUNfRlVOQ19GU0VFS08KLUFDX0ZVTkNfTFNUQVRf
Rk9MTE9XU19TTEFTSEVEX1NZTUxJTksKLUFDX0hFQURFUl9NQUpPUgotQUNfRlVOQ19NQUxMT0MK
LUFDX0ZVTkNfTUtUSU1FCi1BQ19GVU5DX01NQVAKLUFDX0ZVTkNfUkVBTExPQwotQUNfRlVOQ19T
VFJOTEVOCi1BQ19GVU5DX1NUUlRPRAotQUNfQ0hFQ0tfRlVOQ1MoWyBcCi0gICAgICAgICAgICAg
ICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5j
YXRlIFwKLSAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBn
ZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAotICAgICAgICAgICAgICAgIGluZXRfbnRvYSBpc2Fz
Y2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3ZlIG1lbXNldCBta2RpciBcCi0gICAgICAgICAg
ICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVj
dCBzZXRlbnYgXAotICAgICAgICAgICAgICAgIHNvY2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJj
c3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKLSAgICAgICAgICAgICAgICBzdHJwYnJrIHN0
cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNldCBcCi0gICAg
ICAgICAgICAgICAgdW5hbWUgXAotICAgICAgICAgICAgICAgIF0pCitBQ19DSEVDS19IRUFERVJT
KFt5YWpsL3lhamxfdmVyc2lvbi5oXSkKIAogQUNfT1VUUFVUKCkKLS0gCjEuNy4yLjUKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4is-0003Ym-Aj; Wed, 25 Apr 2012 16:05:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SN4iq-0003Yh-1l
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:05:40 +0000
Received: from [85.158.143.99:53386] by server-3.bemta-4.messagelabs.com id
	88/BB-05853-3D0289F4; Wed, 25 Apr 2012 16:05:39 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335369935!18874113!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Mzk4OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9857 invoked from network); 25 Apr 2012 16:05:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 16:05:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3PG5Tp6005914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Apr 2012 16:05:29 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3PG5RHi012216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Apr 2012 16:05:28 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3PG5RwK028780; Wed, 25 Apr 2012 11:05:27 -0500
MIME-Version: 1.0
Message-ID: <96c5a3ba-72c2-45c4-8860-08b59157ad40@default>
Date: Wed, 25 Apr 2012 09:05:19 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
	<a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
	<4F98399D0200007800080055@nat28.tlf.novell.com>
In-Reply-To: <4F98399D0200007800080055@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> >>> On 25.04.12 at 17:01, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Wednesday, April 25, 2012 3:27 AM
> >> To: Boris Ostrovsky; Dan Magenheimer
> >> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org
> >> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
> > supported by hardware
> >>
> >> >>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> >> > # HG changeset patch
> >> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> >> > # Date 1334875170 14400
> >> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> >> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> >> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> >> >
> >> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> >> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >> >
> >> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> >> > Acked-by: Wei Huang <wei.huang2@amd.com>
> >> > Tested-by: Wei Huang <wei.huang2@amd.com>
> >>
> >> So what's the status of the discussion around this patch? Were
> >> your concerns all addressed, Dan? Is there any re-submisson
> >> necessary/planned?
> >
> > My concerns will be addressed when there is a fully-functional
> > adequately-tested full-stack implementation, rather than "we
> > have a new instruction that should solve (part of) this problem,
> > let's turn it on by default."
> >
> > While I wish I could invest the time required to do (or
> > participate in) the testing, sadly I can't, so I understand
> > if my opinion is discarded.
> 
> As Keir had asked to get an ACK/NAK from you - is this then a NAK
> or a "don't care" or yet something else (it doesn't read anywhere
> close to an ACK in any case).

Something else ;-)

I certainly don't feel comfortable ACKing it.  I'd like
to see some testing that demonstrates the patch either improves
functionality or performance without breaking other things.
But if nobody else shares my concern, I don't feel that
I have the right to block it either.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4is-0003Ym-Aj; Wed, 25 Apr 2012 16:05:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1SN4iq-0003Yh-1l
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:05:40 +0000
Received: from [85.158.143.99:53386] by server-3.bemta-4.messagelabs.com id
	88/BB-05853-3D0289F4; Wed, 25 Apr 2012 16:05:39 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335369935!18874113!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Mzk4OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9857 invoked from network); 25 Apr 2012 16:05:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 16:05:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3PG5Tp6005914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Apr 2012 16:05:29 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3PG5RHi012216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Apr 2012 16:05:28 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3PG5RwK028780; Wed, 25 Apr 2012 11:05:27 -0500
MIME-Version: 1.0
Message-ID: <96c5a3ba-72c2-45c4-8860-08b59157ad40@default>
Date: Wed, 25 Apr 2012 09:05:19 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
	<a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
	<4F98399D0200007800080055@nat28.tlf.novell.com>
In-Reply-To: <4F98399D0200007800080055@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.huang2@amd.com, keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> 
> >>> On 25.04.12 at 17:01, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Wednesday, April 25, 2012 3:27 AM
> >> To: Boris Ostrovsky; Dan Magenheimer
> >> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org
> >> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
> > supported by hardware
> >>
> >> >>> On 20.04.12 at 04:21, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> >> > # HG changeset patch
> >> > # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> >> > # Date 1334875170 14400
> >> > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
> >> > # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
> >> > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
> >> >
> >> > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> >> > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >> >
> >> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> >> > Acked-by: Wei Huang <wei.huang2@amd.com>
> >> > Tested-by: Wei Huang <wei.huang2@amd.com>
> >>
> >> So what's the status of the discussion around this patch? Were
> >> your concerns all addressed, Dan? Is there any re-submisson
> >> necessary/planned?
> >
> > My concerns will be addressed when there is a fully-functional
> > adequately-tested full-stack implementation, rather than "we
> > have a new instruction that should solve (part of) this problem,
> > let's turn it on by default."
> >
> > While I wish I could invest the time required to do (or
> > participate in) the testing, sadly I can't, so I understand
> > if my opinion is discarded.
> 
> As Keir had asked to get an ACK/NAK from you - is this then a NAK
> or a "don't care" or yet something else (it doesn't read anywhere
> close to an ACK in any case).

Something else ;-)

I certainly don't feel comfortable ACKing it.  I'd like
to see some testing that demonstrates the patch either improves
functionality or performance without breaking other things.
But if nobody else shares my concern, I don't feel that
I have the right to block it either.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:07:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4kP-0003dJ-UD; Wed, 25 Apr 2012 16:07:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN4kN-0003dD-4S
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:07:16 +0000
Received: from [193.109.254.147:47642] by server-1.bemta-14.messagelabs.com id
	89/18-29372-231289F4; Wed, 25 Apr 2012 16:07:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335370033!3849349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27297 invoked from network); 25 Apr 2012 16:07:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:07:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 17:07:11 +0100
Message-ID: <1335370030.28015.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 17:07:10 +0100
In-Reply-To: <1335369353-13012-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/25] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTI1IGF0IDE2OjU1ICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBS
ZW1vdmUgYSBsb3Qgb2YgdW5uZWNlc3NhcnkgdGVzdHMuICBTcGVjaWZpY2FsbHksIHdlIG5vIGxv
bmdlciB0ZXN0Cj4gZm9yIHN0YW5kYXJkIFBPU0lYIGZhY2lsaXRpZXMgd2hpY2ggd2UgZXhwZWN0
IHRvIGJlIHByb3ZpZGVkCj4gZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNh
c2UgaGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgo+IAo+IFN3aXRjaCB0byBnZW5lcmF0aW5nIGNv
bmZpZy5oLmluIHdpdGggYXV0b2hlYWRlci4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3Nv
biA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPiBDYzogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KCkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVs
bEBjaXRyaXguY29tPgoKPiAKPiBDaGFuZ2VzIHNpbmNlIHY3Ogo+ICAqIFJlbW92ZWQgQVhfQ0hF
Q0tfUFRZRlVOQ1MgKHNudWNrIGluIGZyb20gcHJldmlvdXMgcGF0Y2gpCj4gLS0tCj4gIGF1dG9n
ZW4uc2ggICAgICAgICB8ICAgIDEgKwo+ICB0b29scy9jb25maWcuaC5pbiAgfCAgIDczICstCj4g
IHRvb2xzL2NvbmZpZ3VyZSAgICB8IDg4MjUgKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICB0b29scy9jb25maWd1cmUuYWMgfCAgIDYwICstCj4g
IDQgZmlsZXMgY2hhbmdlZCwgMjk4MSBpbnNlcnRpb25zKCspLCA1OTc4IGRlbGV0aW9ucygtKQo+
IAo+IGRpZmYgLS1naXQgYS9hdXRvZ2VuLnNoIGIvYXV0b2dlbi5zaAo+IGluZGV4IGMyODhiNzEu
LjU4YTcxY2UgMTAwNzU1Cj4gLS0tIGEvYXV0b2dlbi5zaAo+ICsrKyBiL2F1dG9nZW4uc2gKPiBA
QCAtMSwzICsxLDQgQEAKPiAgIyEvYmluL3NoIC1lCj4gIGNkIHRvb2xzCj4gIGF1dG9jb25mCj4g
K2F1dG9oZWFkZXIKPiBkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlnLmguaW4gYi90b29scy9jb25m
aWcuaC5pbgo+IGluZGV4IGY4Zjk2ZGMuLjE3Yzg5MTMgMTAwNjQ0Cj4gLS0tIGEvdG9vbHMvY29u
ZmlnLmguaW4KPiArKysgYi90b29scy9jb25maWcuaC5pbgo+IEBAIC0xLDE5ICsxLDY0IEBACj4g
LS8qCj4gLSAqIENvcHlyaWdodCAoQykgMjAxMgo+IC0gKgo+IC0gKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQo+IC0g
KiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSBhcyBwdWJsaXNoZWQKPiAtICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsg
dmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lhbAo+IC0gKiBleGNlcHRpb24gb24gbGlu
a2luZyBkZXNjcmliZWQgaW4gZmlsZSBMSUNFTlNFLgo+IC0gKgo+IC0gKiBUaGlzIHByb2dyYW0g
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKPiAtICog
YnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFu
dHkgb2YKPiAtICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ
VVJQT1NFLiAgU2VlIHRoZQo+IC0gKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug
Zm9yIG1vcmUgZGV0YWlscy4KPiAtICovCj4gKy8qIGNvbmZpZy5oLmluLiAgR2VuZXJhdGVkIGZy
b20gY29uZmlndXJlLmFjIGJ5IGF1dG9oZWFkZXIuICAqLwo+ICsKPiArLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KPiArI3VuZGVmIEhB
VkVfSU5UVFlQRVNfSAo+ICsKPiArLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBjcnlw
dG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KPiArI3VuZGVmIEhBVkVfTElCQ1JZUFRPCj4gKwo+
ICsvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHlhamwnIGxpYnJhcnkgKC1seWFqbCku
ICovCj4gKyN1bmRlZiBIQVZFX0xJQllBSkwKPiArCj4gKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgeicgbGlicmFyeSAoLWx6KS4gKi8KPiArI3VuZGVmIEhBVkVfTElCWgo+ICsKPiAr
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxtZW1vcnkuaD4gaGVhZGVyIGZpbGUuICov
Cj4gKyN1bmRlZiBIQVZFX01FTU9SWV9ICj4gKwo+ICsvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPHN0ZGludC5oPiBoZWFkZXIgZmlsZS4gKi8KPiArI3VuZGVmIEhBVkVfU1RESU5UX0gK
PiArCj4gKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkbGliLmg+IGhlYWRlciBm
aWxlLiAqLwo+ICsjdW5kZWYgSEFWRV9TVERMSUJfSAo+ICsKPiArLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDxzdHJpbmdzLmg+IGhlYWRlciBmaWxlLiAqLwo+ICsjdW5kZWYgSEFWRV9T
VFJJTkdTX0gKPiArCj4gKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5nLmg+
IGhlYWRlciBmaWxlLiAqLwo+ICsjdW5kZWYgSEFWRV9TVFJJTkdfSAo+ICsKPiArLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvc3RhdC5oPiBoZWFkZXIgZmlsZS4gKi8KPiArI3Vu
ZGVmIEhBVkVfU1lTX1NUQVRfSAo+ICsKPiArLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IDxzeXMvdHlwZXMuaD4gaGVhZGVyIGZpbGUuICovCj4gKyN1bmRlZiBIQVZFX1NZU19UWVBFU19I
Cj4gKwo+ICsvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHVuaXN0ZC5oPiBoZWFkZXIg
ZmlsZS4gKi8KPiArI3VuZGVmIEhBVkVfVU5JU1REX0gKPiAKPiAgLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDx5YWpsL3lhamxfdmVyc2lvbi5oPiBoZWFkZXIgZmlsZS4gKi8KPiAgI3Vu
ZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAo+IAo+IC0vKiBEZWZpbmUgY3Vyc2VzIGhlYWRl
ciB0byBpbmNsdWRlLiAqLwo+ICsvKiBEZWZpbmUgY3Vyc2VzIGhlYWRlciB0byB1c2UgKi8KPiAg
I3VuZGVmIElOQ0xVREVfQ1VSU0VTX0gKPiArCj4gKy8qIERlZmluZSB0byB0aGUgYWRkcmVzcyB3
aGVyZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLwo+ICsj
dW5kZWYgUEFDS0FHRV9CVUdSRVBPUlQKPiArCj4gKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1l
IG9mIHRoaXMgcGFja2FnZS4gKi8KPiArI3VuZGVmIFBBQ0tBR0VfTkFNRQo+ICsKPiArLyogRGVm
aW5lIHRvIHRoZSBmdWxsIG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLwo+ICsj
dW5kZWYgUEFDS0FHRV9TVFJJTkcKPiArCj4gKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBz
aG9ydCBuYW1lIG9mIHRoaXMgcGFja2FnZS4gKi8KPiArI3VuZGVmIFBBQ0tBR0VfVEFSTkFNRQo+
ICsKPiArLyogRGVmaW5lIHRvIHRoZSBob21lIHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KPiAr
I3VuZGVmIFBBQ0tBR0VfVVJMCj4gKwo+ICsvKiBEZWZpbmUgdG8gdGhlIHZlcnNpb24gb2YgdGhp
cyBwYWNrYWdlLiAqLwo+ICsjdW5kZWYgUEFDS0FHRV9WRVJTSU9OCj4gKwo+ICsvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgQU5TSSBDIGhlYWRlciBmaWxlcy4gKi8KPiArI3VuZGVmIFNU
RENfSEVBREVSUwo+IGRpZmYgLS1naXQgYS90b29scy9jb25maWd1cmUgYi90b29scy9jb25maWd1
cmUKPiBpbmRleCA4OTdlMDYxLi5kODkxOGZlIDEwMDc1NQo+IC0tLSBhL3Rvb2xzL2NvbmZpZ3Vy
ZQo+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZQo+IEBAIC01OTUsMTIgKzU5NSw4IEBAIGFjX2luY2x1
ZGVzX2RlZmF1bHQ9IlwKPiAgIyBpbmNsdWRlIDx1bmlzdGQuaD4KPiAgI2VuZGlmIgo+IAo+IC1h
Y19oZWFkZXJfbGlzdD0KPiAtYWNfZnVuY19saXN0PQo+ICBhY19zdWJzdF92YXJzPSdMVExJQk9C
SlMKPiAtUE9XX0xJQgo+ICBMSUJPQkpTCj4gLUFMTE9DQQo+ICBsaWJpY29udgo+ICBQVEhSRUFE
X0xJQlMKPiAgUFRIUkVBRF9MREZMQUdTCj4gQEAgLTYxNiw2ICs2MTIsOSBAQCBQS0dfQ09ORklH
X0xJQkRJUgo+ICBQS0dfQ09ORklHX1BBVEgKPiAgUEtHX0NPTkZJRwo+ICBDVVJTRVNfTElCUwo+
ICtFR1JFUAo+ICtHUkVQCj4gK0NQUAo+ICBweWNvbmZpZwo+ICBQWVRIT05QQVRICj4gIE9DQU1M
QlVJTEQKPiBAQCAtNjM1LDggKzYzNCwxMyBAQCBJTlNUQUxMX0RBVEEKPiAgSU5TVEFMTF9TQ1JJ
UFQKPiAgSU5TVEFMTF9QUk9HUkFNCj4gIFNFVF9NQUtFCj4gLUxOX1MKPiAtU0VECj4gK09CSkVY
VAo+ICtFWEVFWFQKPiArYWNfY3RfQ0MKPiArQ1BQRkxBR1MKPiArTERGTEFHUwo+ICtDRkxBR1MK
PiArQ0MKPiAgSUFTTAo+ICBCQ0MKPiAgTEQ4Ngo+IEBAIC02NjUsMjQgKzY2OSw2IEBAIHhlbmFw
aQo+ICB2dHBtCj4gIG1vbml0b3JzCj4gIGdpdGh0dHAKPiAtaG9zdF9vcwo+IC1ob3N0X3ZlbmRv
cgo+IC1ob3N0X2NwdQo+IC1ob3N0Cj4gLWJ1aWxkX29zCj4gLWJ1aWxkX3ZlbmRvcgo+IC1idWls
ZF9jcHUKPiAtYnVpbGQKPiAtRUdSRVAKPiAtR1JFUAo+IC1DUFAKPiAtT0JKRVhUCj4gLUVYRUVY
VAo+IC1hY19jdF9DQwo+IC1DUFBGTEFHUwo+IC1MREZMQUdTCj4gLUNGTEFHUwo+IC1DQwo+ICB0
YXJnZXRfYWxpYXMKPiAgaG9zdF9hbGlhcwo+ICBidWlsZF9hbGlhcwo+IEBAIC03NDAsMTIgKzcy
Niw2IEBAIGVuYWJsZV9kZWJ1Zwo+ICAgICAgICBhY19wcmVjaW91c192YXJzPSdidWlsZF9hbGlh
cwo+ICBob3N0X2FsaWFzCj4gIHRhcmdldF9hbGlhcwo+IC1DQwo+IC1DRkxBR1MKPiAtTERGTEFH
Uwo+IC1MSUJTCj4gLUNQUEZMQUdTCj4gLUNQUAo+ICBQUkVQRU5EX0lOQ0xVREVTCj4gIFBSRVBF
TkRfTElCCj4gIEFQUEVORF9JTkNMVURFUwo+IEBAIC03NjIsNiArNzQyLDEyIEBAIEFTODYKPiAg
TEQ4Ngo+ICBCQ0MKPiAgSUFTTAo+ICtDQwo+ICtDRkxBR1MKPiArTERGTEFHUwo+ICtMSUJTCj4g
K0NQUEZMQUdTCj4gK0NQUAo+ICBQS0dfQ09ORklHCj4gIFBLR19DT05GSUdfUEFUSAo+ICBQS0df
Q09ORklHX0xJQkRJUgo+IEBAIC0xMzY1LDEwICsxMzUxLDYgQEAgRmluZSB0dW5pbmcgb2YgdGhl
IGluc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKPiAgX0FDRU9GCj4gCj4gICAgY2F0IDw8XF9BQ0VP
Rgo+IC0KPiAtU3lzdGVtIHR5cGVzOgo+IC0gIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBm
b3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCj4gLSAgLS1ob3N0PUhPU1QgICAgICAgY3Jv
c3MtY29tcGlsZSB0byBidWlsZCBwcm9ncmFtcyB0byBydW4gb24gSE9TVCBbQlVJTERdCj4gIF9B
Q0VPRgo+ICBmaQo+IAo+IEBAIC0xMzk5LDE0ICsxMzgxLDYgQEAgT3B0aW9uYWwgRmVhdHVyZXM6
Cj4gICAgLS1kaXNhYmxlLWRlYnVnICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiB0b29s
cyAoZGVmYXVsdCBpcyBFTkFCTEVEKQo+IAo+ICBTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50
IHZhcmlhYmxlczoKPiAtICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQKPiAtICBDRkxB
R1MgICAgICBDIGNvbXBpbGVyIGZsYWdzCj4gLSAgTERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBl
LmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxpYnJhcmllcyBpbiBhCj4gLSAgICAgICAgICAg
ICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgo+IC0gIExJQlMgICAgICAgIGxpYnJh
cmllcyB0byBwYXNzIHRvIHRoZSBsaW5rZXIsIGUuZy4gLWw8bGlicmFyeT4KPiAtICBDUFBGTEFH
UyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3MsIGUuZy4gLUk8aW5jbHVk
ZSBkaXI+IGlmCj4gLSAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5k
YXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+Cj4gLSAgQ1BQICAgICAgICAgQyBwcmVwcm9jZXNz
b3IKPiAgICBQUkVQRU5EX0lOQ0xVREVTCj4gICAgICAgICAgICAgICAgTGlzdCBvZiBpbmNsdWRl
IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCj4gICAgUFJFUEVORF9M
SUIgTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRob3V0
IC1MKQo+IEBAIC0xNDI1LDYgKzEzOTksMTQgQEAgU29tZSBpbmZsdWVudGlhbCBlbnZpcm9ubWVu
dCB2YXJpYWJsZXM6Cj4gICAgTEQ4NiAgICAgICAgUGF0aCB0byBsZDg2IHRvb2wKPiAgICBCQ0Mg
ICAgICAgICBQYXRoIHRvIGJjYyB0b29sCj4gICAgSUFTTCAgICAgICAgUGF0aCB0byBpYXNsIHRv
b2wKPiArICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQKPiArICBDRkxBR1MgICAgICBD
IGNvbXBpbGVyIGZsYWdzCj4gKyAgTERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxp
YiBkaXI+IGlmIHlvdSBoYXZlIGxpYnJhcmllcyBpbiBhCj4gKyAgICAgICAgICAgICAgbm9uc3Rh
bmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgo+ICsgIExJQlMgICAgICAgIGxpYnJhcmllcyB0byBw
YXNzIHRvIHRoZSBsaW5rZXIsIGUuZy4gLWw8bGlicmFyeT4KPiArICBDUFBGTEFHUyAgICAoT2Jq
ZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlm
Cj4gKyAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5kYXJkIGRpcmVj
dG9yeSA8aW5jbHVkZSBkaXI+Cj4gKyAgQ1BQICAgICAgICAgQyBwcmVwcm9jZXNzb3IKPiAgICBQ
S0dfQ09ORklHICBwYXRoIHRvIHBrZy1jb25maWcgdXRpbGl0eQo+ICAgIFBLR19DT05GSUdfUEFU
SAo+ICAgICAgICAgICAgICAgIGRpcmVjdG9yaWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2Vh
cmNoIHBhdGgKPiBAQCAtMTc5NywzMTEgKzE3NzksNiBAQCBmaQo+ICAgIGFzX2ZuX3NldF9zdGF0
dXMgJGFjX3JldHZhbAo+IAo+ICB9ICMgYWNfZm5fY190cnlfbGluawo+IC0KPiAtIyBhY19mbl9j
X2NoZWNrX2Z1bmMgTElORU5PIEZVTkMgVkFSCj4gLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+IC0jIFRlc3RzIHdoZXRoZXIgRlVOQyBleGlzdHMsIHNldHRpbmcgdGhlIGNh
Y2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseQo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgKCkKPiAt
ewo+IC0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGlu
ZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkMi4uLiAiID4mNjsgfQo+IC1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNv
bmZkZWZzLmguICAqLwo+IC0vKiBEZWZpbmUgJDIgdG8gYW4gaW5ub2N1b3VzIHZhcmlhbnQsIGlu
IGNhc2UgPGxpbWl0cy5oPiBkZWNsYXJlcyAkMi4KPiAtICAgRm9yIGV4YW1wbGUsIEhQLVVYIDEx
aSA8bGltaXRzLmg+IGRlY2xhcmVzIGdldHRpbWVvZmRheS4gICovCj4gLSNkZWZpbmUgJDIgaW5u
b2N1b3VzXyQyCj4gLQo+IC0vKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9z
IGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsCj4gLSAgICB3aGljaCBjYW4gY29uZmxpY3Qg
d2l0aCBjaGFyICQyICgpOyBiZWxvdy4KPiAtICAgIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3Nl
cnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKPiAtICAgIDxsaW1pdHMuaD4gZXhp
c3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4gICovCj4gLQo+IC0jaWZkZWYgX19T
VERDX18KPiAtIyBpbmNsdWRlIDxsaW1pdHMuaD4KPiAtI2Vsc2UKPiAtIyBpbmNsdWRlIDxhc3Nl
cnQuaD4KPiAtI2VuZGlmCj4gLQo+IC0jdW5kZWYgJDIKPiAtCj4gLS8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIg
JDIgKCk7Cj4gLS8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25z
IHdoaWNoIGl0IGltcGxlbWVudHMKPiAtICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAg
U29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkCj4gLSAgICBzb21ldGhpbmcgc3RhcnRp
bmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8KPiAtI2lmIGRl
ZmluZWQgX19zdHViXyQyIHx8IGRlZmluZWQgX19zdHViX19fJDIKPiAtY2hva2UgbWUKPiAtI2Vu
ZGlmCj4gLQo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJldHVybiAkMiAoKTsKPiAtICA7Cj4g
LSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5F
Tk8iOyB0aGVuIDoKPiAtICBldmFsICIkMz15ZXMiCj4gLWVsc2UKPiAtICBldmFsICIkMz1ubyIK
PiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4g
LSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC1ldmFsIGFj
X3Jlcz1cJCQzCj4gLSAgICAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQo+IC0kYXNfZWNobyAiJGFjX3JlcyIgPiY2
OyB9Cj4gLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIg
PSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KPiAtCj4gLX0gIyBhY19mbl9j
X2NoZWNrX2Z1bmMKPiAtCj4gLSMgYWNfZm5fY19jaGVja190eXBlIExJTkVOTyBUWVBFIFZBUiBJ
TkNMVURFUwo+IC0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
PiAtIyBUZXN0cyB3aGV0aGVyIFRZUEUgZXhpc3RzIGFmdGVyIGhhdmluZyBpbmNsdWRlZCBJTkNM
VURFUywgc2V0dGluZyBjYWNoZQo+IC0jIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KPiAtYWNf
Zm5fY19jaGVja190eXBlICgpCj4gLXsKPiAtICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0g
YXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCj4gLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4m
NQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KPiAtaWYgZXZhbCAi
dGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBldmFsICIkMz1ubyIKPiAtICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAt
JDQKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1pZiAoc2l6ZW9mICgkMikpCj4gLSAgICAgICAg
cmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSQ0
Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtaWYgKHNpemVvZiAoKCQyKSkpCj4gLSAgICAgICAg
ICAgcmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBh
Y19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAgZXZh
bCAiJDM9eWVzIgo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gLWV2YWwgYWNfcmVz
PVwkJDMKPiAtICAgICAgICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0K
PiAtICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHgg
JiYgeyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQo+IC0KPiAtfSAjIGFjX2ZuX2NfY2hl
Y2tfdHlwZQo+IC0KPiAtIyBhY19mbl9jX2ZpbmRfaW50WF90IExJTkVOTyBCSVRTIFZBUgo+IC0j
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgRmluZHMgYSBzaWduZWQg
aW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIK
PiAtIyBhY2NvcmRpbmdseS4KPiAtYWNfZm5fY19maW5kX2ludFhfdCAoKQo+IC17Cj4gLSAgYXNf
bGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9
JGFzX2xpbmVub19zdGFjawo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIGludCQyX3QiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgaW50JDJfdC4uLiAiID4mNjsgfQo+IC1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGV2YWwgIiQzPW5vIgo+IC0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2ZXIgY2hlY2sg
YSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgo+IC0gICAgICMgdGhhbiBoYWxmIG9m
IHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCj4gLSAgICAgZm9yIGFjX3R5cGUgaW4gaW50JDJf
dCAnaW50JyAnbG9uZyBpbnQnIFwKPiAtICAgICAgICAnbG9uZyBsb25nIGludCcgJ3Nob3J0IGlu
dCcgJ3NpZ25lZCBjaGFyJzsgZG8KPiAtICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVk
ZXNfZGVmYXVsdAo+IC0gICAgICAgICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKPiAtaW50
Cj4gLW1haW4gKCkKPiAtewo+IC1zdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwg
KCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsK
PiAtdGVzdF9hcnJheSBbMF0gPSAwCj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1f
QUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZk
ZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVsdAo+IC0gICAgICAgICAgICAgICBlbnVt
IHsgTiA9ICQyIC8gMiAtIDEgfTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1zdGF0aWMgaW50
IHRlc3RfYXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikg
PDwgTikgLSAxKSAqIDIgKyAxKQo+IC0gICAgICAgICAgICAgICAgPCAoJGFjX3R5cGUpICgoKCgo
JGFjX3R5cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAyKSldOwo+IC10ZXN0X2FycmF5IFsw
XSA9IDAKPiAtCj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAgY2FzZSAk
YWNfdHlwZSBpbiAjKAo+IC0gIGludCQyX3QpIDoKPiAtICAgIGV2YWwgIiQzPXllcyIgOzsgIygK
PiAtICAqKSA6Cj4gLSAgICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Cj4gLWVzYWMKPiAtZmkKPiAt
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNf
ZXh0Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
Y29uZnRlc3QuJGFjX2V4dAo+IC0gICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQzIlwiID0geCJu
byI7IHRoZW4gOgo+IC0KPiAtZWxzZQo+IC0gIGJyZWFrCj4gLWZpCj4gLSAgICAgZG9uZQo+IC1m
aQo+IC1ldmFsIGFjX3Jlcz1cJCQzCj4gLSAgICAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQo+IC0kYXNfZWNobyAi
JGFjX3JlcyIgPiY2OyB9Cj4gLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xp
bmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KPiAtCj4g
LX0gIyBhY19mbl9jX2ZpbmRfaW50WF90Cj4gLQo+IC0jIGFjX2ZuX2NfY2hlY2tfbWVtYmVyIExJ
TkVOTyBBR0dSIE1FTUJFUiBWQVIgSU5DTFVERVMKPiAtIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgVHJpZXMgdG8gZmluZCBpZiB0aGUg
ZmllbGQgTUVNQkVSIGV4aXN0cyBpbiB0eXBlIEFHR1IsIGFmdGVyIGluY2x1ZGluZwo+IC0jIElO
Q0xVREVTLCBzZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KPiAtYWNfZm5f
Y19jaGVja19tZW1iZXIgKCkKPiAtewo+IC0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBh
c19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKPiAtICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMi4kMyIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4kMy4uLiAiID4mNjsgfQo+IC1pZiBl
dmFsICJ0ZXN0IFwiXCR7JDQrc2V0fVwiIiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kNQo+IC1pbnQKPiAt
bWFpbiAoKQo+IC17Cj4gLXN0YXRpYyAkMiBhY19hZ2dyOwo+IC1pZiAoYWNfYWdnci4kMykKPiAt
cmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgZXZhbCAiJDQ9eWVzIgo+IC1l
bHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0v
KiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSQ1Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtc3Rh
dGljICQyIGFjX2FnZ3I7Cj4gLWlmIChzaXplb2YgYWNfYWdnci4kMykKPiAtcmV0dXJuIDA7Cj4g
LSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgZXZhbCAiJDQ9eWVzIgo+IC1lbHNlCj4gLSAgZXZh
bCAiJDQ9bm8iCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtZmkKPiAtZXZhbCBhY19yZXM9
XCQkNAo+IC0gICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQo+
IC0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAm
JiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Cj4gLQo+IC19ICMgYWNfZm5fY19jaGVj
a19tZW1iZXIKPiAtCj4gLSMgYWNfZm5fY19maW5kX3VpbnRYX3QgTElORU5PIEJJVFMgVkFSCj4g
LSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgRmluZHMgYW4gdW5z
aWduZWQgaW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJs
ZSBWQVIKPiAtIyBhY2NvcmRpbmdseS4KPiAtYWNfZm5fY19maW5kX3VpbnRYX3QgKCkKPiAtewo+
IC0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5v
X3N0YWNrPSRhc19saW5lbm9fc3RhY2sKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB1aW50JDJfdC4uLiAiID4mNjsgfQo+IC1pZiBldmFsICJ0ZXN0IFwiXCR7JDMr
c2V0fVwiIiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAt
ZWxzZQo+IC0gIGV2YWwgIiQzPW5vIgo+IC0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2
ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgo+IC0gICAgICMgdGhh
biBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCj4gLSAgICAgZm9yIGFjX3R5cGUg
aW4gdWludCQyX3QgJ3Vuc2lnbmVkIGludCcgJ3Vuc2lnbmVkIGxvbmcgaW50JyBcCj4gLSAgICAg
ICAgJ3Vuc2lnbmVkIGxvbmcgbG9uZyBpbnQnICd1bnNpZ25lZCBzaG9ydCBpbnQnICd1bnNpZ25l
ZCBjaGFyJzsgZG8KPiAtICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVs
dAo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXN0YXRpYyBpbnQgdGVzdF9hcnJheSBbMSAtIDIg
KiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8gMiAtIDEpID09IDMp
XTsKPiAtdGVzdF9hcnJheSBbMF0gPSAwCj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+
IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0g
IGNhc2UgJGFjX3R5cGUgaW4gIygKPiAtICB1aW50JDJfdCkgOgo+IC0gICAgZXZhbCAiJDM9eWVz
IiA7OyAjKAo+IC0gICopIDoKPiAtICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKPiAtZXNhYwo+
IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKPiAtICAgICAgIGlmIGV2YWwgdGVzdCBcInhcJCIkMyJcIiA9IHgibm8iOyB0
aGVuIDoKPiAtCj4gLWVsc2UKPiAtICBicmVhawo+IC1maQo+IC0gICAgIGRvbmUKPiAtZmkKPiAt
ZXZhbCBhY19yZXM9XCQkMwo+IC0gICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19y
ZXMiID4mNjsgfQo+IC0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9f
c3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Cj4gLQo+IC19ICMg
YWNfZm5fY19maW5kX3VpbnRYX3QKPiAgY2F0ID5jb25maWcubG9nIDw8X0FDRU9GCj4gIFRoaXMg
ZmlsZSBjb250YWlucyBhbnkgbWVzc2FnZXMgcHJvZHVjZWQgYnkgY29tcGlsZXJzIHdoaWxlCj4g
IHJ1bm5pbmcgY29uZmlndXJlLCB0byBhaWQgZGVidWdnaW5nIGlmIGNvbmZpZ3VyZSBtYWtlcyBh
IG1pc3Rha2UuCj4gQEAgLTIzODYsMTEgKzIwNjMsNiBAQCAkYXNfZWNobyAiJGFzX21lOiBjcmVh
dGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KPiAgICA+JGNhY2hlX2ZpbGUKPiAgZmkKPiAK
PiAtYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3lzL3RpbWUuaCIKPiAtYXNfZm5fYXBw
ZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCj4gLWFzX2ZuX2FwcGVuZCBhY19mdW5jX2xp
c3QgIiBhbGFybSIKPiAtYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3RkbGliLmgiCj4g
LWFzX2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgo+ICAjIENoZWNrIHRo
YXQgdGhlIHByZWNpb3VzIHZhcmlhYmxlcyBzYXZlZCBpbiB0aGUgY2FjaGUgaGF2ZSBrZXB0IHRo
ZSBzYW1lCj4gICMgdmFsdWUuCj4gIGFjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQo+IEBAIC0yNTA4
LDE3MzAgKzIxODAsNDAgQEAgQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQg
d2hlbiBwb3NzaWJsZS4iID4mMjt9Cj4gCj4gIGZpCj4gCj4gLWFjX2V4dD1jCj4gLWFjX2NwcD0n
JENQUCAkQ1BQRkxBR1MnCj4gLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBj
b25mdGVzdC4kYWNfZXh0ID4mNScKPiAtYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScK
PiAtYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQo+IC1pZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNfd29yZD0kMgo+IC17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVu
Cj4gLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZv
ciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2Nj
Igo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAt
ZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+IC0KPiAtZmkKPiAtZmkKPiAtQ0M9
JGFjX2N2X3Byb2dfQ0MKPiAtaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQo+IC0kYXNfZWNo
byAiJENDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZp
Cj4gLQo+IC0KPiAtZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfQ0MiOyB0aGVuCj4gLSAg
YWNfY3RfQ0M9JENDCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgZ2NjOyBhY193
b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNl
dDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlm
IHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNf
Y3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+
IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0g
ICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZl
X0lGUwo+IC0KPiAtZmkKPiAtZmkKPiAtYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKPiAt
aWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQo+IC0kYXNfZWNobyAiJGFj
X2N0X0NDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZp
Cj4gLQo+IC0gIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgo+IC0gICAgQ0M9IiIKPiAt
ICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4g
LXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
PiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp
eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsKPiAt
ZXNhYwo+IC0gICAgQ0M9JGFjX2N0X0NDCj4gLSAgZmkKPiAtZWxzZQo+IC0gIENDPSIkYWNfY3Zf
cHJvZ19DQyIKPiAtZmkKPiAtCj4gLWlmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiAtICAgICAgICAg
IGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAtICAgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193
b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhl
biA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9J
RlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1jYyIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+IC0gICAgYnJlYWsg
Mgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAtCj4gLWZp
Cj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KPiAt
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+
JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNobyAibm8i
ID4mNjsgfQo+IC1maQo+IC0KPiAtCj4gLSAgZmkKPiAtZmkKPiAtaWYgdGVzdCAteiAiJENDIjsg
dGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgY2M7IGFjX3dvcmQ9JDIKPiAt
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgo+IC0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gLWVsc2UKPiAtICBhY19wcm9nX3JlamVjdGVkPW5vCj4gLWFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0g
IElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0g
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4g
LSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgaWYgdGVz
dCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVuCj4g
LSAgICAgICBhY19wcm9nX3JlamVjdGVkPXllcwo+IC0gICAgICAgY29udGludWUKPiAtICAgICBm
aQo+IC0gICAgYWNfY3ZfcHJvZ19DQz0iY2MiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
PiAtICAgIGJyZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVf
SUZTCj4gLQo+IC1pZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCj4gLSAgIyBX
ZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0
Lgo+IC0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwo+IC0gIHNoaWZ0Cj4gLSAgaWYgdGVzdCAk
IyAhPSAwOyB0aGVuCj4gLSAgICAjIFdlIGNob3NlIGEgZGlmZmVyZW50IGNvbXBpbGVyIGZyb20g
dGhlIGJvZ3VzIG9uZS4KPiAtICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1l
LCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KPiAtICAgICMgZmlyc3QgaWYgd2Ugc2V0IEND
IHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgo+IC0gICAgc2hp
ZnQKPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgo+IC0g
IGZpCj4gLWZpCj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4g
IiRDQyI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+
IC0kYXNfZWNobyAibm8iID4mNjsgfQo+IC1maQo+IC0KPiAtCj4gLWZpCj4gLWlmIHRlc3QgLXog
IiRDQyI7IHRoZW4KPiAtICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAg
Zm9yIGFjX3Byb2cgaW4gY2wuZXhlCj4gLSAgZG8KPiAtICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFj
X3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0
aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVz
dCAtbiAiJENDIjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgo+IC1mb3IgYXNfZGlyIGluICRQQVRICj4gLWRvCj4gLSAgSUZTPSRhc19zYXZl
X0lGUwo+IC0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gLSAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAtICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX0NDPSIkYWNf
dG9vbF9wcmVmaXgkYWNfcHJvZyIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+IC0gICAg
YnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAt
Cj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4gIiRDQyI7IHRo
ZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNo
byAibm8iID4mNjsgfQo+IC1maQo+IC0KPiAtCj4gLSAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFr
Cj4gLSAgZG9uZQo+IC1maQo+IC1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCj4gLSAgYWNfY3RfQ0M9
JENDCj4gLSAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCj4gLWRvCj4gLSAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICIkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAkYWNfcHJvZzsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4g
LSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0
ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0
aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVf
SUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19wcm9nIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4g
LSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+IC0KPiAtZmkKPiAt
ZmkKPiAtYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKPiAtaWYgdGVzdCAtbiAiJGFjX2N0
X0NDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfQ0MiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KPiAt
ZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4gLQo+IC0KPiAtICB0ZXN0
IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCj4gLWRvbmUKPiAtCj4gLSAgaWYgdGVzdCAieCRhY19j
dF9DQyIgPSB4OyB0aGVuCj4gLSAgICBDQz0iIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3Nz
X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJO
SU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4m
Mjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBDQz0kYWNfY3RfQ0MK
PiAtICBmaQo+IC1maQo+IC0KPiAtZmkKPiAtCj4gLQo+IC10ZXN0IC16ICIkQ0MiICYmIHsgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdk
JzoiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9
Cj4gLWFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQ
QVRICj4gLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsg
fQo+IC0KPiAtIyBQcm92aWRlIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgo+
IC0kYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBj
b21waWxlciB2ZXJzaW9uIiA+JjUKPiAtc2V0IFggJGFjX2NvbXBpbGUKPiAtYWNfY29tcGlsZXI9
JDIKPiAtZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbwo+IC0g
IHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKPiAtY2FzZSAiKCgkYWNf
dHJ5IiBpbgo+IC0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owo+
IC0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+IC1lc2FjCj4gLWV2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCj4gLSRhc19l
Y2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+IC0gIChldmFsICIkYWNfY29tcGlsZXIgJGFjX29w
dGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gIGlmIHRlc3Qg
LXMgY29uZnRlc3QuZXJyOyB0aGVuCj4gLSAgICBzZWQgJzEwYVwKPiAtLi4uIHJlc3Qgb2Ygc3Rk
ZXJyIG91dHB1dCBkZWxldGVkIC4uLgo+IC0gICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29u
ZnRlc3QuZXIxCj4gLSAgICBjYXQgY29uZnRlc3QuZXIxID4mNQo+IC0gIGZpCj4gLSAgcm0gLWYg
Y29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgo+IC0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH0KPiAtZG9uZQo+IC0KPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC1pbnQKPiAtbWFpbiAoKQo+
IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtYWNfY2xlYW5f
ZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMKPiAtYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9m
aWxlcyBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGIub3V0Igo+IC0jIFRyeSB0byBjcmVhdGUgYW4g
ZXhlY3V0YWJsZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNyZWdhcmQgYS5vdXQuCj4gLSMgSXQgd2ls
bCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBjb21waWxlcnMsIGFuZCBmaW5kaW5nIG91dCBhbiBp
bnR1aXRpb24KPiAtIyBvZiBleGVleHQuCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3JrcyIgPiY1Cj4g
LSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MuLi4gIiA+
JjY7IH0KPiAtYWNfbGlua19kZWZhdWx0PWAkYXNfZWNobyAiJGFjX2xpbmsiIHwgc2VkICdzLyAt
byAqY29uZnRlc3RbXiBdKi8vJ2AKPiAtCj4gLSMgVGhlIHBvc3NpYmxlIG91dHB1dCBmaWxlczoK
PiAtYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBhLmV4ZSBhX291dC5leGUg
Yi5vdXQgY29uZnRlc3QuKiIKPiAtCj4gLWFjX3JtZmlsZXM9Cj4gLWZvciBhY19maWxlIGluICRh
Y19maWxlcwo+IC1kbwo+IC0gIGNhc2UgJGFjX2ZpbGUgaW4KPiAtICAgICouJGFjX2V4dCB8ICou
eGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5t
YXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKPiAtICAgICogKSBhY19ybWZp
bGVzPSIkYWNfcm1maWxlcyAkYWNfZmlsZSI7Owo+IC0gIGVzYWMKPiAtZG9uZQo+IC1ybSAtZiAk
YWNfcm1maWxlcwo+IC0KPiAtaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKPiAtY2Fz
ZSAiKCgkYWNfdHJ5IiBpbgo+IC0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7Owo+IC0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+IC1lc2FjCj4gLWV2YWwgYWNf
dHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIi
Cj4gLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+IC0gIChldmFsICIkYWNfbGlua19k
ZWZhdWx0IikgMj4mNQo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0
YXR1cyA9IDA7IH07IHRoZW4gOgo+IC0gICMgQXV0b2NvbmYtMi4xMyBjb3VsZCBzZXQgdGhlIGFj
X2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgo+IC0jIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBu
bycsIG90aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQgdG8gYEVYRUVYVCA9IG5vJwo+IC0jIGluIGEg
TWFrZWZpbGUuICBXZSBzaG91bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4ZWV4dCBpZiBpdCB3YXMg
Y2FjaGVkLAo+IC0jIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNob3J0LWNpcmN1aXQgdGhpcyB0ZXN0
IGZvciBjb21waWxlcnMgdW5rbm93biB0bwo+IC0jIEF1dG9jb25mLgo+IC1mb3IgYWNfZmlsZSBp
biAkYWNfZmlsZXMgJycKPiAtZG8KPiAtICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUK
PiAtICBjYXNlICRhY19maWxlIGluCj4gLSAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMg
fCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAq
LmRTWU0gfCAqLm8gfCAqLm9iaiApCj4gLSAgICAgICA7Owo+IC0gICAgW2FiXS5vdXQgKQo+IC0g
ICAgICAgIyBXZSBmb3VuZCB0aGUgZGVmYXVsdCBleGVjdXRhYmxlLCBidXQgZXhlZXh0PScnIGlz
IG1vc3QKPiAtICAgICAgICMgY2VydGFpbmx5IHJpZ2h0Lgo+IC0gICAgICAgYnJlYWs7Owo+IC0g
ICAgKi4qICkKPiAtICAgICAgIGlmIHRlc3QgIiR7YWNfY3ZfZXhlZXh0K3NldH0iID0gc2V0ICYm
IHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5vOwo+IC0gICAgICAgdGhlbiA6OyBlbHNlCj4gLSAg
ICAgICAgICBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AK
PiAtICAgICAgIGZpCj4gLSAgICAgICAjIFdlIHNldCBhY19jdl9leGVleHQgaGVyZSBiZWNhdXNl
IHRoZSBsYXRlciB0ZXN0IGZvciBpdCBpcyBub3QKPiAtICAgICAgICMgc2FmZTogY3Jvc3MgY29t
cGlsZXJzIG1heSBub3QgYWRkIHRoZSBzdWZmaXggaWYgZ2l2ZW4gYW4gYC1vJwo+IC0gICAgICAg
IyBhcmd1bWVudCwgc28gd2UgbWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVh
ZHkuCj4gLSAgICAgICAjIEV2ZW4gaWYgdGhpcyBzZWN0aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFz
IHRoZSBhZHZhbnRhZ2Ugb2YKPiAtICAgICAgICMgYWN0dWFsbHkgd29ya2luZy4KPiAtICAgICAg
IGJyZWFrOzsKPiAtICAgICogKQo+IC0gICAgICAgYnJlYWs7Owo+IC0gIGVzYWMKPiAtZG9uZQo+
IC10ZXN0ICIkYWNfY3ZfZXhlZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KPiAtCj4gLWVsc2UK
PiAtICBhY19maWxlPScnCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRhY19maWxlIjsgdGhlbiA6Cj4g
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHBy
b2dyYW0gd2FzOiIgPiY1Cj4gLXNlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKPiAt
Cj4gLXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdk
JzoiID4mMjt9Cj4gLWFzX2ZuX2Vycm9yIDc3ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhl
Y3V0YWJsZXMKPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDUgOyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKPiAtJGFzX2VjaG8gInllcyIgPiY2OyB9Cj4gLWZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29t
cGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lLi4uICIgPiY2OyB9Cj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfZmls
ZSIgPiY1Cj4gLSRhc19lY2hvICIkYWNfZmlsZSIgPiY2OyB9Cj4gLWFjX2V4ZWV4dD0kYWNfY3Zf
ZXhlZXh0Cj4gLQo+IC1ybSAtZiAtciBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGNvbmZ0ZXN0JGFj
X2N2X2V4ZWV4dCBiLm91dAo+IC1hY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBz
dWZmaXggb2YgZXhlY3V0YWJsZXMiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3Vm
Zml4IG9mIGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9Cj4gLWlmIHsgeyBhY190cnk9IiRhY19saW5r
Igo+IC1jYXNlICIoKCRhY190cnkiIGluCj4gLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlf
ZWNobz1cJGFjX3RyeTs7Cj4gLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gLWVzYWMKPiAt
ZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5
X2VjaG9cIiIKPiAtJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cj4gLSAgKGV2YWwgIiRh
Y19saW5rIikgMj4mNQo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0
YXR1cyA9IDA7IH07IHRoZW4gOgo+IC0gICMgSWYgYm90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNv
bmZ0ZXN0JyBhcmUgYHByZXNlbnQnICh3ZWxsLCBvYnNlcnZhYmxlKQo+IC0jIGNhdGNoIGBjb25m
dGVzdC5leGUnLiAgRm9yIGluc3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3QnIHdpbGwK
PiAtIyB3b3JrIHByb3Blcmx5IChpLmUuLCByZWZlciB0byBgY29uZnRlc3QuZXhlJyksIHdoaWxl
IGl0IHdvbid0IHdpdGgKPiAtIyBgcm0nLgo+IC1mb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUg
Y29uZnRlc3QgY29uZnRlc3QuKjsgZG8KPiAtICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGlu
dWUKPiAtICBjYXNlICRhY19maWxlIGluCj4gLSAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50
ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYg
fCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7Cj4gLSAgICAqLiogKSBhY19jdl9leGVleHQ9YGV4
cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKPiAtICAgICAgICAgYnJlYWs7Owo+IC0g
ICAgKiApIGJyZWFrOzsKPiAtICBlc2FjCj4gLWRvbmUKPiAtZWxzZQo+IC0gIHsgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQo+IC0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cj4gLWFz
X2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0YWJsZXM6IGNhbm5v
dCBjb21waWxlIGFuZCBsaW5rCj4gLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMi
ICIkTElORU5PIiA1IDsgfQo+IC1maQo+IC1ybSAtZiBjb25mdGVzdCBjb25mdGVzdCRhY19jdl9l
eGVleHQKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9leGVleHQiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9Cj4g
LQo+IC1ybSAtZiBjb25mdGVzdC4kYWNfZXh0Cj4gLUVYRUVYVD0kYWNfY3ZfZXhlZXh0Cj4gLWFj
X2V4ZWV4dD0kRVhFRVhUCj4gLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaW5jbHVkZSA8c3RkaW8uaD4KPiAt
aW50Cj4gLW1haW4gKCkKPiAtewo+IC1GSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5vdXQiLCAi
dyIpOwo+IC0gcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAwOwo+IC0KPiAtICA7
Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWFjX2NsZWFuX2ZpbGVzPSIkYWNfY2xl
YW5fZmlsZXMgY29uZnRlc3Qub3V0Igo+IC0jIENoZWNrIHRoYXQgdGhlIGNvbXBpbGVyIHByb2R1
Y2VzIGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBub3QsIGVpdGhlcgo+IC0jIHRoZSBjb21w
aWxlciBpcyBicm9rZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCj4gLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29t
cGlsaW5nIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3Mg
Y29tcGlsaW5nLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciICE9IHll
czsgdGhlbgo+IC0gIHsgeyBhY190cnk9IiRhY19saW5rIgo+IC1jYXNlICIoKCRhY190cnkiIGlu
Cj4gLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cj4gLSAgKikg
YWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gLWVzYWMKPiAtZXZhbCBhY190cnlfZWNobz0iXCJcJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiAtJGFzX2VjaG8gIiRh
Y190cnlfZWNobyI7IH0gPiY1Cj4gLSAgKGV2YWwgIiRhY19saW5rIikgMj4mNQo+IC0gIGFjX3N0
YXR1cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KPiAtICBpZiB7IGFj
X3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVleHQnCj4gLSAgeyB7IGNhc2UgIigoJGFjX3RyeSIg
aW4KPiAtICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKPiAtICAq
KSBhY190cnlfZWNobz0kYWNfdHJ5OzsKPiAtZXNhYwo+IC1ldmFsIGFjX3RyeV9lY2hvPSJcIlwk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgo+IC0kYXNfZWNobyAi
JGFjX3RyeV9lY2hvIjsgfSA+JjUKPiAtICAoZXZhbCAiJGFjX3RyeSIpIDI+JjUKPiAtICBhY19z
dGF0dXM9JD8KPiAtICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8g
PSAkYWNfc3RhdHVzIiA+JjUKPiAtICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9OyB0aGVuCj4g
LSAgICBjcm9zc19jb21waWxpbmc9bm8KPiAtICBlbHNlCj4gLSAgICBpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiA9IG1heWJlOyB0aGVuCj4gLSAgICAgICBjcm9zc19jb21waWxpbmc9eWVzCj4g
LSAgICBlbHNlCj4gLSAgICAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogZXJy
b3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+IC1hc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biBD
IGNvbXBpbGVkIHByb2dyYW1zLgo+IC1JZiB5b3UgbWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNl
IFxgLS1ob3N0Jy4KPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5F
Tk8iIDUgOyB9Cj4gLSAgICBmaQo+IC0gIGZpCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkY3Jvc3NfY29tcGlsaW5nIiA+JjUKPiAtJGFz
X2VjaG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQo+IC0KPiAtcm0gLWYgY29uZnRlc3QuJGFj
X2V4dCBjb25mdGVzdCRhY19jdl9leGVleHQgY29uZnRlc3Qub3V0Cj4gLWFjX2NsZWFuX2ZpbGVz
PSRhY19jbGVhbl9maWxlc19zYXZlCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMiID4mNQo+IC0kYXNf
ZWNob19uICJjaGVja2luZyBmb3Igc3VmZml4IG9mIG9iamVjdCBmaWxlcy4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAtaW50
Cj4gLW1haW4gKCkKPiAtewo+IC0KPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9G
Cj4gLXJtIC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqCj4gLWlmIHsgeyBhY190cnk9IiRhY19j
b21waWxlIgo+IC1jYXNlICIoKCRhY190cnkiIGluCj4gLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBh
Y190cnlfZWNobz1cJGFjX3RyeTs7Cj4gLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gLWVz
YWMKPiAtZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAk
YWNfdHJ5X2VjaG9cIiIKPiAtJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cj4gLSAgKGV2
YWwgIiRhY19jb21waWxlIikgMj4mNQo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRl
c3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgo+IC0gIGZvciBhY19maWxlIGluIGNvbmZ0ZXN0
Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCj4gLSAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8
IGNvbnRpbnVlOwo+IC0gIGNhc2UgJGFjX2ZpbGUgaW4KPiAtICAgICouJGFjX2V4dCB8ICoueGNv
ZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAg
fCAqLmluZiB8ICouZFNZTSApIDs7Cj4gLSAgICAqKSBhY19jdl9vYmpleHQ9YGV4cHIgIiRhY19m
aWxlIiA6ICcuKlwuXCguKlwpJ2AKPiAtICAgICAgIGJyZWFrOzsKPiAtICBlc2FjCj4gLWRvbmUK
PiAtZWxzZQo+IC0gICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQo+
IC1zZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1Cj4gLQo+IC17IHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUK
PiAtJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+IC1hc19m
bl9lcnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIG9iamVjdCBmaWxlczogY2Fubm90
IGNvbXBpbGUKPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDUgOyB9Cj4gLWZpCj4gLXJtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFj
X2V4dAo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X29iamV4dCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7
IH0KPiAtT0JKRVhUPSRhY19jdl9vYmpleHQKPiAtYWNfb2JqZXh0PSRPQkpFWFQKPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFy
ZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyB3
aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAt
aW50Cj4gLW1haW4gKCkKPiAtewo+IC0jaWZuZGVmIF9fR05VQ19fCj4gLSAgICAgICBjaG9rZSBt
ZQo+IC0jZW5kaWYKPiAtCj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1p
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY29tcGlsZXJf
Z251PXllcwo+IC1lbHNlCj4gLSAgYWNfY29tcGlsZXJfZ251PW5vCj4gLWZpCj4gLXJtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1h
Y19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251Cj4gLQo+IC1maQo+IC17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGls
ZXJfZ251IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9Cj4g
LWlmIHRlc3QgJGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhlbgo+IC0gIEdDQz15ZXMKPiAtZWxz
ZQo+IC0gIEdDQz0KPiAtZmkKPiAtYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQo+IC1hY19z
YXZlX0NGTEFHUz0kQ0ZMQUdTCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1Cj4gLSRhc19lY2hvX24g
ImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9JGFjX2Nfd2Vy
cm9yX2ZsYWcKPiAtICAgYWNfY193ZXJyb3JfZmxhZz15ZXMKPiAtICAgYWNfY3ZfcHJvZ19jY19n
PW5vCj4gLSAgIENGTEFHUz0iLWciCj4gLSAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAtaW50Cj4gLW1h
aW4gKCkKPiAtewo+IC0KPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlm
IGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9wcm9nX2Nj
X2c9eWVzCj4gLWVsc2UKPiAtICBDRkxBR1M9IiIKPiAtICAgICAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+
IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1f
QUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0KPiAt
ZWxzZQo+IC0gIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwo+IC0gICAg
ICAgIENGTEFHUz0iLWciCj4gLSAgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC1pbnQKPiAtbWFp
biAoKQo+IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X3Byb2dfY2Nf
Zz15ZXMKPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICAgYWNfY193
ZXJyb3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUK
PiAtJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQo+IC1pZiB0ZXN0ICIkYWNfdGVz
dF9DRkxBR1MiID0gc2V0OyB0aGVuCj4gLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwo+IC1lbGlm
IHRlc3QgJGFjX2N2X3Byb2dfY2NfZyA9IHllczsgdGhlbgo+IC0gIGlmIHRlc3QgIiRHQ0MiID0g
eWVzOyB0aGVuCj4gLSAgICBDRkxBR1M9Ii1nIC1PMiIKPiAtICBlbHNlCj4gLSAgICBDRkxBR1M9
Ii1nIgo+IC0gIGZpCj4gLWVsc2UKPiAtICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgo+IC0g
ICAgQ0ZMQUdTPSItTzIiCj4gLSAgZWxzZQo+IC0gICAgQ0ZMQUdTPQo+IC0gIGZpCj4gLWZpCj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfY2NfYzg5K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgYWNfY3ZfcHJvZ19jY19jODk9bm8KPiAtYWNfc2F2
ZV9DQz0kQ0MKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+
IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRlIDxzdGRhcmcuaD4KPiAtI2luY2x1
ZGUgPHN0ZGlvLmg+Cj4gLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KPiAtI2luY2x1ZGUgPHN5cy9z
dGF0Lmg+Cj4gLS8qIE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20g
UkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KPiAtc3RydWN0IGJ1ZiB7IGludCB4OyB9Owo+IC1G
SUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOwo+IC1z
dGF0aWMgY2hhciAqZSAocCwgaSkKPiAtICAgICBjaGFyICoqcDsKPiAtICAgICBpbnQgaTsKPiAt
ewo+IC0gIHJldHVybiBwW2ldOwo+IC19Cj4gLXN0YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAo
Y2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikKPiAtewo+IC0gIGNoYXIgKnM7Cj4gLSAgdmFf
bGlzdCB2Owo+IC0gIHZhX3N0YXJ0ICh2LHApOwo+IC0gIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50
KSk7Cj4gLSAgdmFfZW5kICh2KTsKPiAtICByZXR1cm4gczsKPiAtfQo+IC0KPiAtLyogT1NGIDQu
MCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBo
YXMKPiAtICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhl
eCBjaGFyYWN0ZXIgY29uc3RhbnRzLgo+IC0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9y
IHVuZm9ydHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKPiAtICAgYXMgJ3gn
LiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRv
IGdldAo+IC0gICBwcm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5
cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCj4gLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdz
IG5lY2Vzc2FyeSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZwo+IC0gICB0aGF0
J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICovCj4gLWludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcg
PT0gMCA/IDEgOiAtMV07Cj4gLQo+IC0vKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kg
YnkgZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKPiAtICAgaW5zaWRl
IHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwo+IC0jZGVmaW5lIEZPTyh4KSAn
eCcKPiAtaW50IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07Cj4gLQo+IC1p
bnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsKPiAtc3RydWN0IHMxIHtpbnQgKCpmKSAoaW50IGEp
O307Cj4gLXN0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9Owo+IC1pbnQgcGFpcm5hbWVz
IChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGlu
dCksIGludCwgaW50KTsKPiAtaW50IGFyZ2M7Cj4gLWNoYXIgKiphcmd2Owo+IC1pbnQKPiAtbWFp
biAoKQo+IC17Cj4gLXJldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwg
YXJndiwgMSkgIT0gYXJndlsxXTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9G
Cj4gLWZvciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3Rk
IFwKPiAtICAgICAgIC1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05T
X18iCj4gLWRvCj4gLSAgQ0M9IiRhY19zYXZlX0NDICRhY19hcmciCj4gLSAgaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19h
cmcKPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAo+
IC0gIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCj4gLWRvbmUK
PiAtcm0gLWYgY29uZnRlc3QuJGFjX2V4dAo+IC1DQz0kYWNfc2F2ZV9DQwo+IC0KPiAtZmkKPiAt
IyBBQ19DQUNIRV9WQUwKPiAtY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KPiAtICB4KQo+
IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
bmUgbmVlZGVkIiA+JjUKPiAtJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKPiAtICB4
bm8pCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogdW5zdXBwb3J0ZWQiID4mNQo+IC0kYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7Owo+
IC0gICopCj4gLSAgICBDQz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKPiAtICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19j
ODkiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0gOzsKPiAtZXNh
Ywo+IC1pZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgo+IC0KPiAt
ZmkKPiAtCj4gLWFjX2V4dD1jCj4gLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCj4gLWFjX2NvbXBp
bGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKPiAtYWNf
bGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFH
UyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKPiAtYWNfY29tcGlsZXJfZ251PSRhY19jdl9j
X2NvbXBpbGVyX2dudQo+IC0KPiAtCj4gLWFjX2V4dD1jCj4gLWFjX2NwcD0nJENQUCAkQ1BQRkxB
R1MnCj4gLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ID4mNScKPiAtYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRD
UFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKPiAtYWNfY29tcGls
ZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+
JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3Iu
Li4gIiA+JjY7IH0KPiAtIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1lcyBhIGRpcmVjdG9y
eS4KPiAtaWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KPiAtICBDUFA9
Cj4gLWZpCj4gLWlmIHRlc3QgLXogIiRDUFAiOyB0aGVuCj4gLSAgaWYgdGVzdCAiJHthY19jdl9w
cm9nX0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKPiAtZWxzZQo+IC0gICAgICAjIERvdWJsZSBxdW90ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8g
YmUgZXhwYW5kZWQKPiAtICAgIGZvciBDUFAgaW4gIiRDQyAtRSIgIiRDQyAtRSAtdHJhZGl0aW9u
YWwtY3BwIiAiL2xpYi9jcHAiCj4gLSAgICBkbwo+IC0gICAgICBhY19wcmVwcm9jX29rPWZhbHNl
Cj4gLWZvciBhY19jX3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwo+IC1kbwo+IC0gICMgVXNl
IGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMK
PiAtICAjIHdpdGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jrcy4KPiAtICAjIFByZWZlciA8
bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKPiAt
ICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KPiAt
ICAjIE9uIHRoZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVy
J3MgcGFyc2VyLAo+IC0gICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlz
IGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaWZkZWYgX19T
VERDX18KPiAtIyBpbmNsdWRlIDxsaW1pdHMuaD4KPiAtI2Vsc2UKPiAtIyBpbmNsdWRlIDxhc3Nl
cnQuaD4KPiAtI2VuZGlmCj4gLSAgICAgICAgICAgICAgICAgICAgU3ludGF4IGVycm9yCj4gLV9B
Q0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKPiAtCj4gLWVsc2UK
PiAtICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCj4gLWNvbnRpbnVlCj4gLWZpCj4g
LXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKPiAtCj4gLSAg
IyBPSywgd29ya3Mgb24gc2FuZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50
IGhlYWRlcnMKPiAtICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93Lgo+IC0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAq
Lwo+IC0jaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+IC0gICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFs
aWQgaW5wdXQuCj4gLWNvbnRpbnVlCj4gLWVsc2UKPiAtICAjIFBhc3NlcyBib3RoIHRlc3RzLgo+
IC1hY19wcmVwcm9jX29rPToKPiAtYnJlYWsKPiAtZmkKPiAtcm0gLWYgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAo+IC0KPiAtZG9uZQo+IC0jIEJlY2F1c2Ugb2YgYGJy
ZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KPiAt
cm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX2V4dAo+IC1pZiAkYWNf
cHJlcHJvY19vazsgdGhlbiA6Cj4gLSAgYnJlYWsKPiAtZmkKPiAtCj4gLSAgICBkb25lCj4gLSAg
ICBhY19jdl9wcm9nX0NQUD0kQ1BQCj4gLQo+IC1maQo+IC0gIENQUD0kYWNfY3ZfcHJvZ19DUFAK
PiAtZWxzZQo+IC0gIGFjX2N2X3Byb2dfQ1BQPSRDUFAKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDUFAiID4mNQo+IC0kYXNfZWNobyAi
JENQUCIgPiY2OyB9Cj4gLWFjX3ByZXByb2Nfb2s9ZmFsc2UKPiAtZm9yIGFjX2NfcHJlcHJvY193
YXJuX2ZsYWcgaW4gJycgeWVzCj4gLWRvCj4gLSAgIyBVc2UgYSBoZWFkZXIgZmlsZSB0aGF0IGNv
bWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGliYwo+IC0gICMgd2l0aCBhIGZyZXNoIGNy
b3NzLWNvbXBpbGVyIHdvcmtzLgo+IC0gICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5o
PiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQo+IC0gICMgPGxpbWl0cy5oPiBleGlzdHMg
ZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgo+IC0gICMgT24gdGhlIE5lWFQsIGNjIC1F
IHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCj4gLSAgIyBub3Qg
anVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNh
c2UuCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0v
KiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpZmRlZiBfX1NURENfXwo+IC0jIGluY2x1ZGUgPGxp
bWl0cy5oPgo+IC0jZWxzZQo+IC0jIGluY2x1ZGUgPGFzc2VydC5oPgo+IC0jZW5kaWYKPiAtICAg
ICAgICAgICAgICAgICAgICBTeW50YXggZXJyb3IKPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5
X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+IC0KPiAtZWxzZQo+IC0gICMgQnJva2VuOiBmYWlscyBv
biB2YWxpZCBpbnB1dC4KPiAtY29udGludWUKPiAtZmkKPiAtcm0gLWYgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAo+IC0KPiAtICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNh
c2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwo+IC0gICMgY2FuIGJl
IGRldGVjdGVkIGFuZCBob3cuCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRlIDxhY19ub25l
eGlzdGVudC5oPgo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6Cj4gLSAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KPiAtY29udGludWUK
PiAtZWxzZQo+IC0gICMgUGFzc2VzIGJvdGggdGVzdHMuCj4gLWFjX3ByZXByb2Nfb2s9Ogo+IC1i
cmVhawo+IC1maQo+IC1ybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNf
ZXh0Cj4gLQo+IC1kb25lCj4gLSMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVM
U0UncyBjbGVhbmluZyBjb2RlIHdhcyBza2lwcGVkLgo+IC1ybSAtZiBjb25mdGVzdC5pIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0Cj4gLWlmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKPiAt
Cj4gLWVsc2UKPiAtICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGlu
IFxgJGFjX3B3ZCc6IiA+JjI7fQo+IC1hc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIk
Q1BQXCIgZmFpbHMgc2FuaXR5IGNoZWNrCj4gLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRl
dGFpbHMiICIkTElORU5PIiA1IDsgfQo+IC1maQo+IC0KPiAtYWNfZXh0PWMKPiAtYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKPiAtYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNv
bmZ0ZXN0LiRhY19leHQgPiY1Jwo+IC1hY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0
ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1Jwo+
IC1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cj4gLQo+IC0KPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3JlcCB0aGF0
IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgZ3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUuLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl9wYXRoX0dSRVArc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4K
PiAtICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UKPiAtICAjIExvb3AgdGhyb3VnaCB0aGUgdXNl
cidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAo+IC0gIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRI
X1NFUEFSQVRPUi91c3IveHBnNC9iaW4KPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19wcm9nIGluIGdyZXAg
Z2dyZXA7IGRvCj4gLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KPiAtICAgICAgYWNfcGF0aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4
ZWNfZXh0Igo+IC0gICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3gg
IiRhY19wYXRoX0dSRVAiOyB9IHx8IGNvbnRpbnVlCj4gLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRo
X0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KPiAtICAjIENoZWNrIGZvciBHTlUg
JGFjX3BhdGhfR1JFUAo+IC1jYXNlIGAiJGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGlu
Cj4gLSpHTlUqKQo+IC0gIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9H
UkVQX2ZvdW5kPTo7Owo+IC0qKQo+IC0gIGFjX2NvdW50PTAKPiAtICAkYXNfZWNob19uIDAxMjM0
NTY3ODkgPiJjb25mdGVzdC5pbiIKPiAtICB3aGlsZSA6Cj4gLSAgZG8KPiAtICAgIGNhdCAiY29u
ZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCj4gLSAgICBtdiAiY29uZnRl
c3QudG1wIiAiY29uZnRlc3QuaW4iCj4gLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5u
bCIKPiAtICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCj4gLSAgICAiJGFjX3Bh
dGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gpLScgPCAiY29uZnRlc3Qubmwi
ID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawo+IC0gICAgZGlmZiAiY29uZnRl
c3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhawo+IC0gICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCj4gLSAgICBpZiB0ZXN0
ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCj4gLSAgICAgICMgQmVz
dCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQo+
IC0gICAgICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiCj4gLSAgICAgIGFjX3BhdGhf
R1JFUF9tYXg9JGFjX2NvdW50Cj4gLSAgICBmaQo+IC0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMg
aW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAo+IC0gICAgdGVzdCAkYWNfY291bnQgLWd0IDEw
ICYmIGJyZWFrCj4gLSAgZG9uZQo+IC0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBj
b25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7Owo+IC1lc2FjCj4gLQo+IC0gICAgICAkYWNfcGF0aF9H
UkVQX2ZvdW5kICYmIGJyZWFrIDMKPiAtICAgIGRvbmUKPiAtICBkb25lCj4gLSAgZG9uZQo+IC1J
RlM9JGFzX3NhdmVfSUZTCj4gLSAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4K
PiAtICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGdyZXAgY291bGQgYmUgZm91bmQg
aW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQo+IC0gIGZp
Cj4gLWVsc2UKPiAtICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKPiAtZmkKPiAtCj4gLWZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0
aF9HUkVQIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9wYXRoX0dSRVAiID4mNjsgfQo+IC0gR1JF
UD0iJGFjX2N2X3BhdGhfR1JFUCIKPiAtCj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfRUdS
RVArc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4g
LWVsc2UKPiAtICBpZiBlY2hvIGEgfCAkR1JFUCAtRSAnKGF8YiknID4vZGV2L251bGwgMj4mMQo+
IC0gICB0aGVuIGFjX2N2X3BhdGhfRUdSRVA9IiRHUkVQIC1FIgo+IC0gICBlbHNlCj4gLSAgICAg
aWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgo+IC0gIGFjX3BhdGhfRUdSRVBfZm91bmQ9ZmFsc2UK
PiAtICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2Yg
UFJPR05BTUUtTElTVAo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
PiAtZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KPiAtZG8K
PiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
PiAtICAgIGZvciBhY19wcm9nIGluIGVncmVwOyBkbwo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgICAgIGFjX3BhdGhfRUdSRVA9
IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCj4gLSAgICAgIHsgdGVzdCAtZiAiJGFjX3Bh
dGhfRUdSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQo+
IC0jIENoZWNrIGZvciBHTlUgYWNfcGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZv
dW5kLgo+IC0gICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9FR1JFUAo+IC1jYXNlIGAiJGFjX3Bh
dGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgo+IC0qR05VKikKPiAtICBhY19jdl9wYXRoX0VH
UkVQPSIkYWNfcGF0aF9FR1JFUCIgYWNfcGF0aF9FR1JFUF9mb3VuZD06OzsKPiAtKikKPiAtICBh
Y19jb3VudD0wCj4gLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCj4gLSAg
d2hpbGUgOgo+IC0gIGRvCj4gLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4i
Y29uZnRlc3QudG1wIgo+IC0gICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgo+IC0g
ICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCj4gLSAgICAkYXNfZWNobyAnRUdSRVAn
ID4+ICJjb25mdGVzdC5ubCIKPiAtICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29u
ZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawo+IC0gICAgZGlm
ZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhawo+
IC0gICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCj4gLSAg
ICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgo+IC0g
ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl
dHRlciBvbmUKPiAtICAgICAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiCj4gLSAg
ICAgIGFjX3BhdGhfRUdSRVBfbWF4PSRhY19jb3VudAo+IC0gICAgZmkKPiAtICAgICMgMTAqKDJe
MTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKPiAtICAgIHRlc3QgJGFj
X2NvdW50IC1ndCAxMCAmJiBicmVhawo+IC0gIGRvbmUKPiAtICBybSAtZiBjb25mdGVzdC5pbiBj
b25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKPiAtZXNhYwo+IC0KPiAtICAg
ICAgJGFjX3BhdGhfRUdSRVBfZm91bmQgJiYgYnJlYWsgMwo+IC0gICAgZG9uZQo+IC0gIGRvbmUK
PiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAtICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9FR1JFUCI7IHRoZW4KPiAtICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGVncmVw
IGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRM
SU5FTk8iIDUKPiAtICBmaQo+IC1lbHNlCj4gLSAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAKPiAt
ZmkKPiAtCj4gLSAgIGZpCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9FR1JFUCIgPiY1Cj4gLSRhc19lY2hvICIkYWNf
Y3ZfcGF0aF9FR1JFUCIgPiY2OyB9Cj4gLSBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCj4gLQo+
IC0KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgQU5TSSBDIGhlYWRlciBmaWxlcyIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBB
TlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVy
X3N0ZGMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Cj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN0ZGxpYi5oPgo+IC0jaW5j
bHVkZSA8c3RkYXJnLmg+Cj4gLSNpbmNsdWRlIDxzdHJpbmcuaD4KPiAtI2luY2x1ZGUgPGZsb2F0
Lmg+Cj4gLQo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsK
PiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
Ogo+IC0gIGFjX2N2X2hlYWRlcl9zdGRjPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfaGVhZGVyX3N0
ZGM9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Cj4gLQo+IC1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHll
czsgdGhlbgo+IC0gICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwg
Y29udHJhcnkgdG8gQU5TSS4KPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN0cmluZy5o
Pgo+IC0KPiAtX0FDRU9GCj4gLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAy
PiY1IHwKPiAtICAkRUdSRVAgIm1lbWNociIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKPiAtCj4g
LWVsc2UKPiAtICBhY19jdl9oZWFkZXJfc3RkYz1ubwo+IC1maQo+IC1ybSAtZiBjb25mdGVzdCoK
PiAtCj4gLWZpCj4gLQo+IC1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgo+
IC0gICMgSVNDIDIuMC4yIHN0ZGxpYi5oIGRvZXMgbm90IGRlY2xhcmUgZnJlZSwgY29udHJhcnkg
dG8gQU5TSS4KPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN0ZGxpYi5oPgo+IC0KPiAt
X0FDRU9GCj4gLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKPiAt
ICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAg
YWNfY3ZfaGVhZGVyX3N0ZGM9bm8KPiAtZmkKPiAtcm0gLWYgY29uZnRlc3QqCj4gLQo+IC1maQo+
IC0KPiAtaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiAtICAjIC9iaW4v
Y2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcg
LWFuc2kuCj4gLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0g
IDoKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaW5jbHVkZSA8Y3R5cGUuaD4KPiAtI2lu
Y2x1ZGUgPHN0ZGxpYi5oPgo+IC0jaWYgKCgnICcgJiAweDBGRikgPT0gMHgwMjApCj4gLSMgZGVm
aW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykKPiAtIyBkZWZpbmUgVE9V
UFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMpKQo+IC0jZWxzZQo+
IC0jIGRlZmluZSBJU0xPV0VSKGMpIFwKPiAtICAgICAgICAgICAgICAgICAgKCgnYScgPD0gKGMp
ICYmIChjKSA8PSAnaScpIFwKPiAtICAgICAgICAgICAgICAgICAgICB8fCAoJ2onIDw9IChjKSAm
JiAoYykgPD0gJ3InKSBcCj4gLSAgICAgICAgICAgICAgICAgICAgfHwgKCdzJyA8PSAoYykgJiYg
KGMpIDw9ICd6JykpCj4gLSMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAoKGMpIHwg
MHg0MCkgOiAoYykpCj4gLSNlbmRpZgo+IC0KPiAtI2RlZmluZSBYT1IoZSwgZikgKCgoZSkgJiYg
IShmKSkgfHwgKCEoZSkgJiYgKGYpKSkKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC0gIGludCBp
Owo+IC0gIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKPiAtICAgIGlmIChYT1IgKGlzbG93ZXIg
KGkpLCBJU0xPV0VSIChpKSkKPiAtICAgICAgIHx8IHRvdXBwZXIgKGkpICE9IFRPVVBQRVIgKGkp
KQo+IC0gICAgICByZXR1cm4gMjsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYg
YWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAgYWNfY3Zf
aGVhZGVyX3N0ZGM9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4q
IGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+IC0gIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gLQo+IC1maQo+IC1m
aQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2hlYWRlcl9zdGRjIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3RkYyIgPiY2
OyB9Cj4gLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCj4gLQo+IC0kYXNf
ZWNobyAiI2RlZmluZSBTVERDX0hFQURFUlMgMSIgPj5jb25mZGVmcy5oCj4gLQo+IC1maQo+IC0K
PiAtIyBPbiBJUklYIDUuMywgc3lzL3R5cGVzIGFuZCBpbnR0eXBlcy5oIGFyZSBjb25mbGljdGlu
Zy4KPiAtZm9yIGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5oIHN0
cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBcCj4gLSAgICAgICAgICAgICAgICAgaW50dHlwZXMu
aCBzdGRpbnQuaCB1bmlzdGQuaAo+IC1kbyA6Cj4gLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAi
YWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAo+IC1hY19mbl9jX2NoZWNrX2hl
YWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNf
aW5jbHVkZXNfZGVmYXVsdAo+IC0iCj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVy
IlwiID0geCJ5ZXMiOyB0aGVuIDoKPiAtICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNk
ZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQo+IC1fQUNF
T0YKPiAtCj4gLWZpCj4gLQo+IC1kb25lCj4gLQo+IC0KPiAtCj4gLSAgYWNfZm5fY19jaGVja19o
ZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIm1pbml4L2NvbmZpZy5oIiAiYWNfY3ZfaGVhZGVyX21p
bml4X2NvbmZpZ19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3Zf
aGVhZGVyX21pbml4X2NvbmZpZ19oIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgTUlOSVg9eWVzCj4g
LWVsc2UKPiAtICBNSU5JWD0KPiAtZmkKPiAtCj4gLQo+IC0gIGlmIHRlc3QgIiRNSU5JWCIgPSB5
ZXM7IHRoZW4KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIgPj5jb25m
ZGVmcy5oCj4gLQo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+
Y29uZmRlZnMuaAo+IC0KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZk
ZWZzLmgKPiAtCj4gLSAgZmkKPiAtCj4gLQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VY
VEVOU0lPTlNfXyIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2Fm
ZSB0byBkZWZpbmUgX19FWFRFTlNJT05TX18uLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19j
dl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0K
PiAtIyAgICAgICAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKPiAtICAgICAgICAgJGFjX2luY2x1
ZGVzX2RlZmF1bHQKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC0KPiAtICA7Cj4gLSAgcmV0dXJu
IDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKPiAtICBhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXz15ZXMKPiAtZWxz
ZQo+IC0gIGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fPW5vCj4gLWZpCj4gLXJt
IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4
dAo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fIiA+JjUKPiAtJGFzX2VjaG8g
IiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIgPiY2OyB9Cj4gLSAgdGVzdCAk
YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18gPSB5ZXMgJiYKPiAtICAgICRhc19l
Y2hvICIjZGVmaW5lIF9fRVhURU5TSU9OU19fIDEiID4+Y29uZmRlZnMuaAo+IC0KPiAtICAkYXNf
ZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKPiAtCj4gLSAgJGFzX2Vj
aG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCj4gLQo+IC0gICRhc19lY2hv
ICIjZGVmaW5lIF9QT1NJWF9QVEhSRUFEX1NFTUFOVElDUyAxIiA+PmNvbmZkZWZzLmgKPiAtCj4g
LSAgJGFzX2VjaG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCj4gLQo+
IC0KPiAtIyBNYWtlIHN1cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgo+IC0kU0hFTEwgIiRhY19h
dXhfZGlyL2NvbmZpZy5zdWIiIHN1bjQgPi9kZXYvbnVsbCAyPiYxIHx8Cj4gLSAgYXNfZm5fZXJy
b3IgJD8gImNhbm5vdCBydW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5P
IiA1Cj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGJ1aWxkIHN5c3RlbSB0eXBlIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQg
c3lzdGVtIHR5cGUuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9idWlsZCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGFjX2J1aWxkX2FsaWFzPSRidWlsZF9hbGlhcwo+IC10ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9
IHggJiYKPiAtICBhY19idWlsZF9hbGlhcz1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuZ3Vl
c3MiYAo+IC10ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9IHggJiYKPiAtICBhc19mbl9lcnJvciAk
PyAiY2Fubm90IGd1ZXNzIGJ1aWxkIHR5cGU7IHlvdSBtdXN0IHNwZWNpZnkgb25lIiAiJExJTkVO
TyIgNQo+IC1hY19jdl9idWlsZD1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuc3ViIiAkYWNf
YnVpbGRfYWxpYXNgIHx8Cj4gLSAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9j
b25maWcuc3ViICRhY19idWlsZF9hbGlhcyBmYWlsZWQiICIkTElORU5PIiA1Cj4gLQo+IC1maQo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2J1aWxkIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9idWlsZCIgPiY2OyB9Cj4gLWNhc2UgJGFj
X2N2X2J1aWxkIGluCj4gLSotKi0qKSA7Owo+IC0qKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2
YWx1ZSBvZiBjYW5vbmljYWwgYnVpbGQiICIkTElORU5PIiA1IDs7Cj4gLWVzYWMKPiAtYnVpbGQ9
JGFjX2N2X2J1aWxkCj4gLWFjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKPiAtc2V0IHggJGFjX2N2
X2J1aWxkCj4gLXNoaWZ0Cj4gLWJ1aWxkX2NwdT0kMQo+IC1idWlsZF92ZW5kb3I9JDIKPiAtc2hp
ZnQ7IHNoaWZ0Cj4gLSMgUmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVz
ZWQgdG8gY3JlYXRlICQqLAo+IC0jIGV4Y2VwdCB3aXRoIG9sZCBzaGVsbHM6Cj4gLWJ1aWxkX29z
PSQqCj4gLUlGUz0kYWNfc2F2ZV9JRlMKPiAtY2FzZSAkYnVpbGRfb3MgaW4gKlwgKikgYnVpbGRf
b3M9YGVjaG8gIiRidWlsZF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKPiAtCj4gLQo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvc3Qgc3lz
dGVtIHR5cGUiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlLi4u
ICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfaG9zdCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgIngkaG9z
dF9hbGlhcyIgPSB4OyB0aGVuCj4gLSAgYWNfY3ZfaG9zdD0kYWNfY3ZfYnVpbGQKPiAtZWxzZQo+
IC0gIGFjX2N2X2hvc3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhvc3RfYWxp
YXNgIHx8Cj4gLSAgICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5z
dWIgJGhvc3RfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQo+IC1maQo+IC0KPiAtZmkKPiAteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9ob3N0
IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9ob3N0IiA+JjY7IH0KPiAtY2FzZSAkYWNfY3ZfaG9z
dCBpbgo+IC0qLSotKikgOzsKPiAtKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2Yg
Y2Fub25pY2FsIGhvc3QiICIkTElORU5PIiA1IDs7Cj4gLWVzYWMKPiAtaG9zdD0kYWNfY3ZfaG9z
dAo+IC1hY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCj4gLXNldCB4ICRhY19jdl9ob3N0Cj4gLXNo
aWZ0Cj4gLWhvc3RfY3B1PSQxCj4gLWhvc3RfdmVuZG9yPSQyCj4gLXNoaWZ0OyBzaGlmdAo+IC0j
IFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1c2VkIHRvIGNyZWF0ZSAk
KiwKPiAtIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgo+IC1ob3N0X29zPSQqCj4gLUlGUz0kYWNf
c2F2ZV9JRlMKPiAtY2FzZSAkaG9zdF9vcyBpbiAqXCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9v
cyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKPiAtCj4gLQo+IC0KPiAtIyBNNCBNYWNybyBpbmNs
dWRlcwo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0K
PiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+
IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4g
LQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLSMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQg
dXRpbGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KPiAtIyBzZXJp
YWwgMSAocGtnLWNvbmZpZy0wLjI0KQo+IC0jCj4gLSMgQ29weXJpZ2h0IMKpIDIwMDQgU2NvdHQg
SmFtZXMgUmVtbmFudCA8c2NvdHRAbmV0c3BsaXQuY29tPi4KPiAtIwo+IC0jIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5
Cj4gLSMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSBhcyBwdWJsaXNoZWQgYnkKPiAtIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRo
ZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgo+IC0jIChhdCB5b3VyIG9wdGlvbikgYW55
IGxhdGVyIHZlcnNpb24uCj4gLSMKPiAtIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4g
dGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0Cj4gLSMgV0lUSE9VVCBBTlkgV0FS
UkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgo+IC0jIE1FUkNIQU5U
QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05V
Cj4gLSMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgo+IC0jCj4gLSMg
WW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UKPiAtIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0
aGUgRnJlZSBTb2Z0d2FyZQo+IC0jIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSAt
IFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuCj4gLSMKPiAtIyBBcyBhIHNw
ZWNpYWwgZXhjZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91
Cj4gLSMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250
YWlucyBhCj4gLSMgY29uZmlndXJhdGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1dG9jb25mLCB5
b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIKPiAtIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMg
dGhhdCB5b3UgdXNlIGZvciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCj4gLQo+IC0jIFBLR19Q
Uk9HX1BLR19DT05GSUcoW01JTi1WRVJTSU9OXSkKPiAtIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCj4gLSMgUEtHX1BST0dfUEtHX0NPTkZJRwo+IC0KPiAtIyBQS0dfQ0hFQ0tf
RVhJU1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1GT1VORF0p
Cj4gLSMKPiAtIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVs
ZXMgZXhpc3RzLiAgU2ltaWxhcgo+IC0jIHRvIFBLR19DSEVDS19NT0RVTEVTKCksIGJ1dCBkb2Vz
IG5vdCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9ycy4KPiAtIwo+IC0jIFBsZWFzZSByZW1l
bWJlciB0aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCj4g
LSMgb25seSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZpZ3VyZS5hYywgc28gaWYgdGhl
IGZpcnN0IHBsYWNlCj4gLSMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBp
ZiBpdCBpcyB3aXRoaW4gYW4gImlmIiwgeW91Cj4gLSMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19F
WElTVFMgbWFudWFsbHkKPiAtIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IC0KPiAtCj4gLSMgX1BLR19DT05GSUcoW1ZBUklB
QkxFXSwgW0NPTU1BTkRdLCBbTU9EVUxFU10pCj4gLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgX1BLR19DT05GSUcKPiAtCj4gLSMgX1BLR19TSE9S
VF9FUlJPUlNfU1VQUE9SVEVECj4gLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAt
IyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKPiAtCj4gLQo+IC0jIFBLR19DSEVDS19NT0RV
TEVTKFZBUklBQkxFLVBSRUZJWCwgTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sCj4gLSMgW0FD
VElPTi1JRi1OT1QtRk9VTkRdKQo+IC0jCj4gLSMKPiAtIyBOb3RlIHRoYXQgaWYgdGhlcmUgaXMg
YSBwb3NzaWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bwo+IC0jIFBLR19DSEVDS19NT0RVTEVTIG1p
Z2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3VyZSB0byBpbmNsdWRlIGFuCj4gLSMgZXhw
bGljaXQgY2FsbCB0byBQS0dfUFJPR19QS0dfQ09ORklHIGluIHlvdXIgY29uZmlndXJlLmFjCj4g
LSMKPiAtIwo+IC0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgUEtHX0NIRUNLX01PRFVMRVMKPiAtCj4gLQo+IC0KPiAt
IyBXZSBkZWZpbmUsIHNlcGFyYXRlbHksIFBUSFJFQURfQ0ZMQUdTLCBfTERGTEFHUyBhbmQgX0xJ
QlMKPiAtIyBldmVuIHRob3VnaCBjdXJyZW50bHkgd2UgZG9uJ3Qgc2V0IHRoZW0gdmVyeSBzZXBh
cmF0ZWx5Lgo+IC0jIFRoaXMgbWVhbnMgdGhhdCB0aGUgbWFrZWZpbGVzIHdpbGwgbm90IG5lZWQg
dG8gY2hhbmdlIGluCj4gLSMgdGhlIGZ1dHVyZSBpZiB3ZSBtYWtlIHRoZSB0ZXN0IG1vcmUgc29w
aGlzdGljYXRlZC4KPiAtCj4gLQo+IC0KPiAtIyBXZSBpbnZva2UgQVhfUFRIUkVBRF9WQVJTIHdp
dGggdGhlIG5hbWUgb2YgYW5vdGhlciBtYWNybwo+IC0jIHdoaWNoIGlzIHRoZW4gZXhwYW5kZWQg
b25jZSBmb3IgZWFjaCB2YXJpYWJsZS4KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+
IC0jIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKPiAtCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJs
ZS1naXRodHRwIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfZ2l0aHR0cDsKPiAtZmkKPiAtCj4g
LQo+IC1pZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAg
ICBheF9jdl9naXRodHRwPSJuIgo+IC0KPiAtZWxpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9
ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3ZfZ2l0aHR0cD0ieSIKPiAtCj4gLWVsaWYg
dGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3ZfZ2l0aHR0cD0i
biIKPiAtCj4gLWZpCj4gLWdpdGh0dHA9JGF4X2N2X2dpdGh0dHAKPiAtCj4gLQo+IC0KPiAtIyBD
aGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtl
bmFibGVfbW9uaXRvcnMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gIGVuYWJsZXZhbD0kZW5hYmxl
X21vbml0b3JzOwo+IC1maQo+IC0KPiAtCj4gLWlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9
ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9tb25pdG9ycz0ibiIKPiAtCj4gLWVsaWYg
dGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9j
dl9tb25pdG9ycz0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4g
Ogo+IC0KPiAtICAgIGF4X2N2X21vbml0b3JzPSJ5Igo+IC0KPiAtZmkKPiAtbW9uaXRvcnM9JGF4
X2N2X21vbml0b3JzCj4gLQo+IC0KPiAtCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS12dHBt
IHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfdnRwbTsKPiAtZmkKPiAtCj4gLQo+IC1pZiB0ZXN0ICJ4
JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl92dHBtPSJuIgo+
IC0KPiAtZWxpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0g
ICAgYXhfY3ZfdnRwbT0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfdnRwbTsgdGhlbiA6
Cj4gLQo+IC0gICAgYXhfY3ZfdnRwbT0ibiIKPiAtCj4gLWZpCj4gLXZ0cG09JGF4X2N2X3Z0cG0K
PiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhlbmFwaSB3YXMgZ2l2ZW4u
Cj4gLWlmIHRlc3QgIiR7ZW5hYmxlX3hlbmFwaStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5h
YmxldmFsPSRlbmFibGVfeGVuYXBpOwo+IC1maQo+IC0KPiAtCj4gLWlmIHRlc3QgIngkZW5hYmxl
X3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3ZfeGVuYXBpPSJuIgo+IC0K
PiAtZWxpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAg
ICBheF9jdl94ZW5hcGk9InkiCj4gLQo+IC1lbGlmIHRlc3QgLXogJGF4X2N2X3hlbmFwaTsgdGhl
biA6Cj4gLQo+IC0gICAgYXhfY3ZfeGVuYXBpPSJuIgo+IC0KPiAtZmkKPiAteGVuYXBpPSRheF9j
dl94ZW5hcGkKPiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXB5dGhvbnRv
b2xzIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfcHl0aG9udG9vbHMrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgo+IC0gIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xzOwo+IC1maQo+IC0K
PiAtCj4gLWlmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKPiAt
Cj4gLSAgICBheF9jdl9weXRob250b29scz0ibiIKPiAtCj4gLWVsaWYgdGVzdCAieCRlbmFibGVf
cHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9weXRob250b29s
cz0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfcHl0aG9udG9vbHM7IHRoZW4gOgo+IC0K
PiAtICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5Igo+IC0KPiAtZmkKPiAtcHl0aG9udG9vbHM9JGF4
X2N2X3B5dGhvbnRvb2xzCj4gLQo+IC0KPiAtCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1v
Y2FtbHRvb2xzIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfb2NhbWx0b29scytzZXR9
IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKPiAtZmkK
PiAtCj4gLQo+IC1pZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoK
PiAtCj4gLSAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgo+IC0KPiAtZWxpZiB0ZXN0ICJ4JGVuYWJs
ZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3Zfb2NhbWx0b29s
cz0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6Cj4gLQo+
IC0gICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKPiAtCj4gLWZpCj4gLW9jYW1sdG9vbHM9JGF4X2N2
X29jYW1sdG9vbHMKPiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1pbml0
ZXJtIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7
IHRoZW4gOgo+IC0gIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOwo+IC1maQo+IC0KPiAtCj4g
LWlmIHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBh
eF9jdl9taW5pdGVybT0ibiIKPiAtCj4gLWVsaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0g
Inh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9taW5pdGVybT0ieSIKPiAtCj4gLWVsaWYg
dGVzdCAteiAkYXhfY3ZfbWluaXRlcm07IHRoZW4gOgo+IC0KPiAtICAgIGF4X2N2X21pbml0ZXJt
PSJuIgo+IC0KPiAtZmkKPiAtbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCj4gLQo+IC0KPiAtCj4g
LSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAi
JHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFi
bGVfbG9tb3VudDsKPiAtZmkKPiAtCj4gLQo+IC1pZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9
ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9sb21vdW50PSJuIgo+IC0KPiAtZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3Zf
bG9tb3VudD0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfbG9tb3VudDsgdGhlbiA6Cj4g
LQo+IC0gICAgYXhfY3ZfbG9tb3VudD0ibiIKPiAtCj4gLWZpCj4gLWxvbW91bnQ9JGF4X2N2X2xv
bW91bnQKPiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW92bWYgd2FzIGdp
dmVuLgo+IC1pZiB0ZXN0ICIke2VuYWJsZV9vdm1mK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICBl
bmFibGV2YWw9JGVuYWJsZV9vdm1mOwo+IC1maQo+IC0KPiAtCj4gLWlmIHRlc3QgIngkZW5hYmxl
X292bWYiID0gInhubyI7IHRoZW4gOgo+IC0KPiAtICAgIGF4X2N2X292bWY9Im4iCj4gLQo+IC1l
bGlmIHRlc3QgIngkZW5hYmxlX292bWYiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9j
dl9vdm1mPSJ5Igo+IC0KPiAtZWxpZiB0ZXN0IC16ICRheF9jdl9vdm1mOyB0aGVuIDoKPiAtCj4g
LSAgICBheF9jdl9vdm1mPSJuIgo+IC0KPiAtZmkKPiAtb3ZtZj0kYXhfY3Zfb3ZtZgo+ICsjIE00
IE1hY3JvIGluY2x1ZGVzCj4gCj4gCj4gCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1yb21i
aW9zIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfcm9tYmlvcytzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfcm9tYmlvczsKPiAtZmkKPiAKPiAKPiAtaWYg
dGVzdCAieCRlbmFibGVfcm9tYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLSAgICBheF9jdl9y
b21iaW9zPSJuIgo+IAo+IC1lbGlmIHRlc3QgIngkZW5hYmxlX3JvbWJpb3MiID0gInh5ZXMiOyB0
aGVuIDoKPiAKPiAtICAgIGF4X2N2X3JvbWJpb3M9InkiCj4gCj4gLWVsaWYgdGVzdCAteiAkYXhf
Y3Zfcm9tYmlvczsgdGhlbiA6Cj4gCj4gLSAgICBheF9jdl9yb21iaW9zPSJ5Igo+IAo+IC1maQo+
IC1yb21iaW9zPSRheF9jdl9yb21iaW9zCj4gCj4gCj4gCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVu
YWJsZS1zZWFiaW9zIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfc2VhYmlvcytzZXR9
IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfc2VhYmlvczsKPiAtZmkKPiAK
PiAKPiAtaWYgdGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLSAg
ICBheF9jdl9zZWFiaW9zPSJuIgo+IAo+IC1lbGlmIHRlc3QgIngkZW5hYmxlX3NlYWJpb3MiID0g
Inh5ZXMiOyB0aGVuIDoKPiAKPiAtICAgIGF4X2N2X3NlYWJpb3M9InkiCj4gCj4gLWVsaWYgdGVz
dCAteiAkYXhfY3Zfc2VhYmlvczsgdGhlbiA6Cj4gCj4gLSAgICBheF9jdl9zZWFiaW9zPSJ5Igo+
IAo+IC1maQo+IC1zZWFiaW9zPSRheF9jdl9zZWFiaW9zCj4gCj4gCj4gCj4gLSMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCj4gLWlmIHRlc3QgIiR7ZW5hYmxlX2RlYnVn
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICBlbmFibGV2YWw9JGVuYWJsZV9kZWJ1ZzsKPiAtZmkK
PiAKPiAKPiAtaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0gInhubyI7IHRoZW4gOgo+IAo+IC0g
ICAgYXhfY3ZfZGVidWc9Im4iCj4gCj4gLWVsaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0gInh5
ZXMiOyB0aGVuIDoKPiAKPiAtICAgIGF4X2N2X2RlYnVnPSJ5Igo+IAo+IC1lbGlmIHRlc3QgLXog
JGF4X2N2X2RlYnVnOyB0aGVuIDoKPiAKPiAtICAgIGF4X2N2X2RlYnVnPSJ5Igo+IAo+IC1maQo+
IC1kZWJ1Zz0kYXhfY3ZfZGVidWcKPiAKPiAKPiAKPiBAQCAtNDI0MCw5MzAgKzIyMjIsNDMyIEBA
IGRlYnVnPSRheF9jdl9kZWJ1Zwo+IAo+IAo+IAo+IC1mb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5D
TFVERVMKPiAtZG8KPiAtICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgo+IC1kb25lCj4g
LWZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCj4gLWRvCj4gLSAgICBQUkVQRU5EX0xERkxBR1Mr
PSIgLUwkbGRmbGFnIgo+IC1kb25lCj4gLWZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCj4g
LWRvCj4gLSAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgo+IC1kb25lCj4gLWZvciBsZGZs
YWcgaW4gJEFQUEVORF9MSUIKPiAtZG8KPiAtICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxh
ZyIKPiAtZG9uZQo+IC1DRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZM
QUdTIgo+IC1MREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFH
UyIKPiAKPiAKPiAKPiAKPiAKPiAKPiArIyBwa2cubTQgLSBNYWNyb3MgdG8gbG9jYXRlIGFuZCB1
dGlsaXNlIHBrZy1jb25maWcuICAgICAgICAgICAgLSotIEF1dG9jb25mIC0qLQo+ICsjIHNlcmlh
bCAxIChwa2ctY29uZmlnLTAuMjQpCj4gKyMKPiArIyBDb3B5cmlnaHQgwqkgMjAwNCBTY290dCBK
YW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+Lgo+ICsjCj4gKyMgVGhpcyBwcm9ncmFt
IGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkK
PiArIyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IGFzIHB1Ymxpc2hlZCBieQo+ICsjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhl
ciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCj4gKyMgKGF0IHlvdXIgb3B0aW9uKSBhbnkg
bGF0ZXIgdmVyc2lvbi4KPiArIwo+ICsjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0
aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKPiArIyBXSVRIT1VUIEFOWSBXQVJS
QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCj4gKyMgTUVSQ0hBTlRB
QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUK
PiArIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCj4gKyMKPiArIyBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZQo+ICsjIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRo
ZSBGcmVlIFNvZnR3YXJlCj4gKyMgRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlIC0g
U3VpdGUgMzMwLCBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVTQS4KPiArIwo+ICsjIEFzIGEgc3Bl
Y2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UK
PiArIyBkaXN0cmlidXRlIHRoaXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3JhbSB0aGF0IGNvbnRh
aW5zIGEKPiArIyBjb25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlv
dSBtYXkgaW5jbHVkZSBpdCB1bmRlcgo+ICsjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0
aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KPiAKPiArIyBQS0dfUFJP
R19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCj4gKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+ICsjIFBLR19QUk9HX1BLR19DT05GSUcKPiAKPiArIyBQS0dfQ0hFQ0tfRVhJ
U1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCj4g
KyMKPiArIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMg
ZXhpc3RzLiAgU2ltaWxhcgo+ICsjIHRvIFBLR19DSEVDS19NT0RVTEVTKCksIGJ1dCBkb2VzIG5v
dCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9ycy4KPiArIwo+ICsjIFBsZWFzZSByZW1lbWJl
ciB0aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCj4gKyMg
b25seSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZpZ3VyZS5hYywgc28gaWYgdGhlIGZp
cnN0IHBsYWNlCj4gKyMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBpZiBp
dCBpcyB3aXRoaW4gYW4gImlmIiwgeW91Cj4gKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElT
VFMgbWFudWFsbHkKPiArIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+IAo+ICsjIF9QS0dfQ09ORklHKFtWQVJJQUJMRV0s
IFtDT01NQU5EXSwgW01PRFVMRVNdKQo+ICsjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQo+ICsjIF9QS0dfQ09ORklHCj4gCj4gKyMgX1BLR19TSE9SVF9FUlJP
UlNfU1VQUE9SVEVECj4gKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiArIyBfUEtH
X1NIT1JUX0VSUk9SU19TVVBQT1JURUQKPiAKPiAKPiArIyBQS0dfQ0hFQ0tfTU9EVUxFUyhWQVJJ
QUJMRS1QUkVGSVgsIE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLAo+ICsjIFtBQ1RJT04tSUYt
Tk9ULUZPVU5EXSkKPiArIwo+ICsjCj4gKyMgTm90ZSB0aGF0IGlmIHRoZXJlIGlzIGEgcG9zc2li
aWxpdHkgdGhlIGZpcnN0IGNhbGwgdG8KPiArIyBQS0dfQ0hFQ0tfTU9EVUxFUyBtaWdodCBub3Qg
aGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgo+ICsjIGV4cGxpY2l0IGNh
bGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBpbiB5b3VyIGNvbmZpZ3VyZS5hYwo+ICsjCj4gKyMK
PiArIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+ICsjIFBLR19DSEVDS19NT0RVTEVTCj4gCj4gLSMgQ2hlY2tzIGZvciBwcm9n
cmFtcy4KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVuY2F0ZSBvdXRwdXQiID4mNQo+IC0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVuY2F0ZSBvdXRwdXQuLi4g
IiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wYXRoX1NFRCtzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gICAgICAgICAgICBh
Y19zY3JpcHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJi
YmJiYmJiYmJiYmJiYmJiYmJiYmJiYmIvCj4gLSAgICAgZm9yIGFjX2kgaW4gMSAyIDMgNCA1IDYg
NzsgZG8KPiAtICAgICAgIGFjX3NjcmlwdD0iJGFjX3NjcmlwdCRhc19ubCRhY19zY3JpcHQiCj4g
LSAgICAgZG9uZQo+IC0gICAgIGVjaG8gIiRhY19zY3JpcHQiIDI+L2Rldi9udWxsIHwgc2VkIDk5
cSA+Y29uZnRlc3Quc2VkCj4gLSAgICAgeyBhY19zY3JpcHQ9OyB1bnNldCBhY19zY3JpcHQ7fQo+
IC0gICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0aGVuCj4gLSAgYWNfcGF0aF9TRURfZm91bmQ9ZmFs
c2UKPiAtICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2gg
b2YgUFJPR05BTUUtTElTVAo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAt
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX3Byb2cgaW4gc2Vk
IGdzZWQ7IGRvCj4gLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KPiAtICAgICAgYWNfcGF0aF9TRUQ9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhl
Y19leHQiCj4gLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfU0VEIiAmJiAkYXNfdGVzdF94ICIk
YWNfcGF0aF9TRUQiOyB9IHx8IGNvbnRpbnVlCj4gLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX1NF
RCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgo+IC0gICMgQ2hlY2sgZm9yIEdOVSAkYWNf
cGF0aF9TRUQKPiAtY2FzZSBgIiRhY19wYXRoX1NFRCIgLS12ZXJzaW9uIDI+JjFgIGluCj4gLSpH
TlUqKQo+IC0gIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiIGFjX3BhdGhfU0VEX2ZvdW5k
PTo7Owo+IC0qKQo+IC0gIGFjX2NvdW50PTAKPiAtICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJj
b25mdGVzdC5pbiIKPiAtICB3aGlsZSA6Cj4gLSAgZG8KPiAtICAgIGNhdCAiY29uZnRlc3QuaW4i
ICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCj4gLSAgICBtdiAiY29uZnRlc3QudG1wIiAi
Y29uZnRlc3QuaW4iCj4gLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKPiAtICAg
ICRhc19lY2hvICcnID4+ICJjb25mdGVzdC5ubCIKPiAtICAgICIkYWNfcGF0aF9TRUQiIC1mIGNv
bmZ0ZXN0LnNlZCA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8
IGJyZWFrCj4gLSAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVs
bCAyPiYxIHx8IGJyZWFrCj4gLSAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2Nv
dW50PSRhc192YWwKPiAtICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfU0VEX21h
eC0wfTsgdGhlbgo+IC0gICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBs
b29raW5nIGZvciBhIGJldHRlciBvbmUKPiAtICAgICAgYWNfY3ZfcGF0aF9TRUQ9IiRhY19wYXRo
X1NFRCIKPiAtICAgICAgYWNfcGF0aF9TRURfbWF4PSRhY19jb3VudAo+IC0gICAgZmkKPiAtICAg
ICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKPiAtICAg
IHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawo+IC0gIGRvbmUKPiAtICBybSAtZiBjb25m
dGVzdC5pbiBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKPiAtZXNhYwo+
IAo+IC0gICAgICAkYWNfcGF0aF9TRURfZm91bmQgJiYgYnJlYWsgMwo+IC0gICAgZG9uZQo+IC0g
IGRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAtICBpZiB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9TRUQiOyB0aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBz
ZWQgY291bGQgYmUgZm91bmQgaW4gXCRQQVRIIiAiJExJTkVOTyIgNQo+IC0gIGZpCj4gLWVsc2UK
PiAtICBhY19jdl9wYXRoX1NFRD0kU0VECj4gLWZpCj4gCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9TRUQiID4mNQo+
IC0kYXNfZWNobyAiJGFjX2N2X3BhdGhfU0VEIiA+JjY7IH0KPiAtIFNFRD0iJGFjX2N2X3BhdGhf
U0VEIgo+IC0gIHJtIC1mIGNvbmZ0ZXN0LnNlZAo+ICsjIFdlIGRlZmluZSwgc2VwYXJhdGVseSwg
UFRIUkVBRF9DRkxBR1MsIF9MREZMQUdTIGFuZCBfTElCUwo+ICsjIGV2ZW4gdGhvdWdoIGN1cnJl
bnRseSB3ZSBkb24ndCBzZXQgdGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCj4gKyMgVGhpcyBtZWFucyB0
aGF0IHRoZSBtYWtlZmlsZXMgd2lsbCBub3QgbmVlZCB0byBjaGFuZ2UgaW4KPiArIyB0aGUgZnV0
dXJlIGlmIHdlIG1ha2UgdGhlIHRlc3QgbW9yZSBzb3BoaXN0aWNhdGVkLgo+IAo+IC1hY19leHQ9
Ywo+IC1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwo+IC1hY19jb21waWxlPSckQ0MgLWMgJENGTEFH
UyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCj4gLWFjX2xpbms9JyRDQyAtbyBjb25m
dGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4
dCAkTElCUyA+JjUnCj4gLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKPiAt
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1nY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dv
cmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVu
IDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVzdCAt
biAiJENDIjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgo+IC1mb3IgYXNfZGlyIGluICRQQVRICj4gLWRvCj4gLSAgSUZTPSRhc19zYXZlX0lG
Uwo+IC0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gLSAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAtICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rv
b2xfcHJlZml4fWdjYyIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+IC0gICAgYnJlYWsg
Mgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAKPiAtZmkK
PiAtZmkKPiAtQ0M9JGFjX2N2X3Byb2dfQ0MKPiAtaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+IC0g
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4m
NQo+IC0kYXNfZWNobyAiJENDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIg
PiY2OyB9Cj4gLWZpCj4gCj4gKyMgV2UgaW52b2tlIEFYX1BUSFJFQURfVkFSUyB3aXRoIHRoZSBu
YW1lIG9mIGFub3RoZXIgbWFjcm8KPiArIyB3aGljaCBpcyB0aGVuIGV4cGFuZGVkIG9uY2UgZm9y
IGVhY2ggdmFyaWFibGUuCj4gCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsg
dGhlbgo+IC0gIGFjX2N0X0NDPSRDQwo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15
IGdjYzsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mr
c2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVs
c2UKPiAtICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxz
ZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIg
aW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs
ZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9ImdjYyIKPiAtICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQo+IC0gICAgYnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlG
Uz0kYXNfc2F2ZV9JRlMKPiAKPiAtZmkKPiAtZmkKPiAtYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKPiAtaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQo+IC0kYXNf
ZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2
OyB9Cj4gLWZpCj4gCj4gLSAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCj4gLSAgICBD
Qz0iIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJu
ZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXll
cyA7Owo+IC1lc2FjCj4gLSAgICBDQz0kYWNfY3RfQ0MKPiAtICBmaQo+IC1lbHNlCj4gLSAgQ0M9
IiRhY19jdl9wcm9nX0NDIgo+IC1maQo+IAo+IC1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCj4gLSAg
ICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1j
YzsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFz
X3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfQ0M9
IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAg
IGJyZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4g
Cj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4gIiRDQyI7IHRo
ZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNo
byAibm8iID4mNjsgfQo+IC1maQo+IAo+IAo+IC0gIGZpCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRD
QyI7IHRoZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IGNjOyBhY193b3JkPSQy
Cj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRD
QyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLSAgYWNfcHJvZ19yZWplY3RlZD1ubwo+IC1hc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8K
PiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
PiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGlm
IHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhl
bgo+IC0gICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKPiAtICAgICAgIGNvbnRpbnVlCj4gLSAg
ICAgZmkKPiAtICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19z
YXZlX0lGUwo+IAo+IC1pZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCj4gLSAg
IyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIgdXNl
IGl0Lgo+IC0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwo+IC0gIHNoaWZ0Cj4gLSAgaWYgdGVz
dCAkIyAhPSAwOyB0aGVuCj4gLSAgICAjIFdlIGNob3NlIGEgZGlmZmVyZW50IGNvbXBpbGVyIGZy
b20gdGhlIGJvZ3VzIG9uZS4KPiAtICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2Vu
YW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KPiAtICAgICMgZmlyc3QgaWYgd2Ugc2V0
IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgo+IC0gICAg
c2hpZnQKPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgo+
IC0gIGZpCj4gLWZpCj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAt
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQo+IC0kYXNfZWNobyAibm8iID4mNjsgfQo+ICsjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKPiAr
Cj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KPiAraWYgdGVz
dCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgZW5hYmxldmFsPSRl
bmFibGVfZ2l0aHR0cDsKPiAgZmkKPiAKPiAKPiAtZmkKPiAtaWYgdGVzdCAteiAiJENDIjsgdGhl
bgo+IC0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAtICBmb3IgYWNfcHJv
ZyBpbiBjbC5leGUKPiAtICBkbwo+IC0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
YWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0g
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC1uICIkQ0Mi
OyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
Cj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZp
eCRhY19wcm9nIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4g
LSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+ICtpZiB0ZXN0ICJ4
JGVuYWJsZV9naXRodHRwIiA9ICJ4bm8iOyB0aGVuIDoKPiAKPiAtZmkKPiAtZmkKPiAtQ0M9JGFj
X2N2X3Byb2dfQ0MKPiAtaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQo+IC0kYXNfZWNobyAi
JENDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4g
KyAgICBheF9jdl9naXRodHRwPSJuIgo+IAo+ICtlbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAi
ID0gInh5ZXMiOyB0aGVuIDoKPiAKPiAtICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKPiAtICBk
b25lCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiAtICBhY19jdF9DQz0kQ0MKPiAt
ICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKPiAtZG8KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdv
cmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
PiAtc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KPiAt
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAt
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX3By
b2ciCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIKPiAtICBmaQo+
IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gKyAgICBheF9jdl9naXRodHRw
PSJ5Igo+ICsKPiArZWxpZiB0ZXN0IC16ICRheF9jdl9naXRodHRwOyB0aGVuIDoKPiArCj4gKyAg
ICBheF9jdl9naXRodHRwPSJuIgo+IAo+ICBmaQo+IC1maQo+IC1hY19jdF9DQz0kYWNfY3ZfcHJv
Z19hY19jdF9DQwo+IC1pZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCj4gLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Cj4g
LSRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQo+IC1lbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5v
IiA+JjY7IH0KPiAtZmkKPiArZ2l0aHR0cD0kYXhfY3ZfZ2l0aHR0cAo+IAo+IAo+IC0gIHRlc3Qg
LW4gIiRhY19jdF9DQyIgJiYgYnJlYWsKPiAtZG9uZQo+IAo+IC0gIGlmIHRlc3QgIngkYWNfY3Rf
Q0MiID0geDsgdGhlbgo+IC0gICAgQ0M9IiIKPiAtICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19j
b21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4gLXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsKPiAtZXNhYwo+IC0gICAgQ0M9JGFjX2N0X0NDCj4g
LSAgZmkKPiArIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KPiAr
aWYgdGVzdCAiJHtlbmFibGVfbW9uaXRvcnMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJs
ZXZhbD0kZW5hYmxlX21vbml0b3JzOwo+ICBmaQo+IAo+IC1maQo+IAo+ICtpZiB0ZXN0ICJ4JGVu
YWJsZV9tb25pdG9ycyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLXRlc3QgLXogIiRDQyIgJiYgeyB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19w
d2QnOiIgPiY1Cj4gLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KPiAtYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUg
OyB9Cj4gKyAgICBheF9jdl9tb25pdG9ycz0ibiIKPiAKPiAtIyBQcm92aWRlIHNvbWUgaW5mb3Jt
YXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgo+IC0kYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciB2ZXJzaW9uIiA+JjUKPiAtc2V0IFgg
JGFjX2NvbXBpbGUKPiAtYWNfY29tcGlsZXI9JDIKPiAtZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNp
b24gLXYgLVYgLXF2ZXJzaW9uOyBkbwo+IC0gIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNf
b3B0aW9uID4mNSIKPiAtY2FzZSAiKCgkYWNfdHJ5IiBpbgo+IC0gICpcIiogfCAqXGAqIHwgKlxc
KikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owo+IC0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+
IC1lc2FjCj4gLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogJGFjX3RyeV9lY2hvXCIiCj4gLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+IC0g
IChldmFsICIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgo+IC0g
IGFjX3N0YXR1cz0kPwo+IC0gIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCj4gLSAgICBz
ZWQgJzEwYVwKPiAtLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgo+IC0gICAg
ICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCj4gLSAgICBjYXQgY29uZnRlc3Qu
ZXIxID4mNQo+IC0gIGZpCj4gLSAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgo+IC0g
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMi
ID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KPiAtZG9uZQo+ICtlbGlmIHRlc3QgIngk
ZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsgdGhlbiA6Cj4gCj4gLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhl
IEdOVSBDIGNvbXBpbGVyIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBh
cmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfY19jb21waWxlcl9nbnUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiArICAgIGF4X2N2X21vbml0
b3JzPSJ5Igo+IAo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLSNpZm5kZWYgX19HTlVDX18KPiAt
ICAgICAgIGNob2tlIG1lCj4gLSNlbmRpZgo+ICtlbGlmIHRlc3QgLXogJGF4X2N2X21vbml0b3Jz
OyB0aGVuIDoKPiAKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jb21waWxlcl9nbnU9
eWVzCj4gLWVsc2UKPiAtICBhY19jb21waWxlcl9nbnU9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gLWFjX2N2
X2NfY29tcGlsZXJfZ251PSRhY19jb21waWxlcl9nbnUKPiArICAgIGF4X2N2X21vbml0b3JzPSJ5
Igo+IAo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX2Nv
bXBpbGVyX2dudSIgPiY2OyB9Cj4gLWlmIHRlc3QgJGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhl
bgo+IC0gIEdDQz15ZXMKPiAtZWxzZQo+IC0gIEdDQz0KPiAtZmkKPiAtYWNfdGVzdF9DRkxBR1M9
JHtDRkxBR1Mrc2V0fQo+IC1hY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAt
ZyIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4g
IiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4g
Ogo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19zYXZlX2Nf
d2Vycm9yX2ZsYWc9JGFjX2Nfd2Vycm9yX2ZsYWcKPiAtICAgYWNfY193ZXJyb3JfZmxhZz15ZXMK
PiAtICAgYWNfY3ZfcHJvZ19jY19nPW5vCj4gLSAgIENGTEFHUz0iLWciCj4gLSAgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+ICttb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKPiAKPiAtaW50Cj4gLW1haW4gKCkKPiAt
ewo+IAo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKPiAt
ZWxzZQo+IC0gIENGTEFHUz0iIgo+IC0gICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAKPiAtaW50Cj4gLW1h
aW4gKCkKPiAtewo+ICsjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtdnRwbSB3YXMgZ2l2ZW4uCj4g
K2lmIHRlc3QgIiR7ZW5hYmxlX3Z0cG0rc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZh
bD0kZW5hYmxlX3Z0cG07Cj4gK2ZpCj4gCj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9B
Q0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gCj4gLWVs
c2UKPiAtICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKPiAtICAgICAg
ICBDRkxBR1M9Ii1nIgo+IC0gICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICtpZiB0ZXN0ICJ4JGVuYWJs
ZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKPiAKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+ICsgICAg
YXhfY3ZfdnRwbT0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieHllcyI7
IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3Z0cG09InkiCj4gKwo+ICtlbGlmIHRlc3QgLXogJGF4
X2N2X3Z0cG07IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3Z0cG09Im4iCj4gCj4gLSAgOwo+IC0g
IHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfcHJvZ19jY19nPXllcwo+IC1maQo+IC1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuJGFjX2V4dAo+IC0gICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vy
cm9yX2ZsYWcKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X3Byb2df
Y2NfZyIgPiY2OyB9Cj4gLWlmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4KPiAt
ICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCj4gLWVsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0g
eWVzOyB0aGVuCj4gLSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KPiAtICAgIENGTEFHUz0i
LWcgLU8yIgo+IC0gIGVsc2UKPiAtICAgIENGTEFHUz0iLWciCj4gLSAgZmkKPiAtZWxzZQo+IC0g
IGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCj4gLSAgICBDRkxBR1M9Ii1PMiIKPiAtICBlbHNl
Cj4gLSAgICBDRkxBR1M9Cj4gLSAgZmkKPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4
OSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJ
U08gQzg5Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19jODkrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAt
ICBhY19jdl9wcm9nX2NjX2M4OT1ubwo+IC1hY19zYXZlX0NDPSRDQwo+IC1jYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
PiAtI2luY2x1ZGUgPHN0ZGFyZy5oPgo+IC0jaW5jbHVkZSA8c3RkaW8uaD4KPiAtI2luY2x1ZGUg
PHN5cy90eXBlcy5oPgo+IC0jaW5jbHVkZSA8c3lzL3N0YXQuaD4KPiAtLyogTW9zdCBvZiB0aGUg
Zm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYuc2guICAq
Lwo+IC1zdHJ1Y3QgYnVmIHsgaW50IHg7IH07Cj4gLUZJTEUgKiAoKnJjc29wZW4pIChzdHJ1Y3Qg
YnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Cj4gLXN0YXRpYyBjaGFyICplIChwLCBpKQo+IC0g
ICAgIGNoYXIgKipwOwo+IC0gICAgIGludCBpOwo+IC17Cj4gLSAgcmV0dXJuIHBbaV07Cj4gLX0K
PiAtc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwg
Li4uKQo+IC17Cj4gLSAgY2hhciAqczsKPiAtICB2YV9saXN0IHY7Cj4gLSAgdmFfc3RhcnQgKHYs
cCk7Cj4gLSAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKPiAtICB2YV9lbmQgKHYpOwo+IC0g
IHJldHVybiBzOwo+IC19Cj4gK3Z0cG09JGF4X2N2X3Z0cG0KPiAKPiAtLyogT1NGIDQuMCBDb21w
YXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMKPiAt
ICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFy
YWN0ZXIgY29uc3RhbnRzLgo+IC0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVuZm9y
dHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKPiAtICAgYXMgJ3gnLiAgVGhl
IGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAo+
IC0gICBwcm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21l
cyBvdXQgdHJ1ZSwgZm9yIGFuCj4gLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vz
c2FyeSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZwo+IC0gICB0aGF0J3MgdHJ1
ZSBvbmx5IHdpdGggLXN0ZC4gICovCj4gLWludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/
IDEgOiAtMV07Cj4gCj4gLS8qIElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZh
dWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFyYW1ldGVycwo+IC0gICBpbnNpZGUgc3RyaW5n
cyBhbmQgY2hhcmFjdGVyIGNvbnN0YW50cy4gICovCj4gLSNkZWZpbmUgRk9PKHgpICd4Jwo+IC1p
bnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6IC0xXTsKPiAKPiAtaW50IHRlc3Qg
KGludCBpLCBkb3VibGUgeCk7Cj4gLXN0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Owo+IC1z
dHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUgYSk7fTsKPiAtaW50IHBhaXJuYW1lcyAoaW50LCBj
aGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQs
IGludCk7Cj4gLWludCBhcmdjOwo+IC1jaGFyICoqYXJndjsKPiAtaW50Cj4gLW1haW4gKCkKPiAt
ewo+IC1yZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1mb3Ig
YWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBcCj4gLSAg
ICAgICAtQWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgo+IC1k
bwo+IC0gIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgo+IC0gIGlmIGFjX2ZuX2NfdHJ5X2NvbXBp
bGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCj4gKyMg
Q2hlY2sgd2hldGhlciAtLWVuYWJsZS14ZW5hcGkgd2FzIGdpdmVuLgo+ICtpZiB0ZXN0ICIke2Vu
YWJsZV94ZW5hcGkrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZhbD0kZW5hYmxlX3hl
bmFwaTsKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dAo+IC0gIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCj4gLWRv
bmUKPiAtcm0gLWYgY29uZnRlc3QuJGFjX2V4dAo+IC1DQz0kYWNfc2F2ZV9DQwo+ICsKPiArCj4g
K2lmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhf
Y3ZfeGVuYXBpPSJuIgo+ICsKPiArZWxpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInh5ZXMi
OyB0aGVuIDoKPiArCj4gKyAgICBheF9jdl94ZW5hcGk9InkiCj4gKwo+ICtlbGlmIHRlc3QgLXog
JGF4X2N2X3hlbmFwaTsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfeGVuYXBpPSJuIgo+IAo+ICBm
aQo+IC0jIEFDX0NBQ0hFX1ZBTAo+IC1jYXNlICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiBpbgo+IC0g
IHgpCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm9uZSBuZWVkZWQiID4mNQo+IC0kYXNfZWNobyAibm9uZSBuZWVkZWQiID4mNjsgfSA7Owo+
IC0gIHhubykKPiAtICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1Cj4gLSRhc19lY2hvICJ1bnN1cHBvcnRlZCIgPiY2OyB9
IDs7Cj4gLSAgKikKPiAtICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5Igo+IC0gICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9n
X2NjX2M4OSIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7Owo+
IC1lc2FjCj4gLWlmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6Cj4g
K3hlbmFwaT0kYXhfY3ZfeGVuYXBpCj4gKwo+IAo+ICsKPiArIyBDaGVjayB3aGV0aGVyIC0tZW5h
YmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KPiAraWYgdGVzdCAiJHtlbmFibGVfcHl0aG9udG9v
bHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xz
Owo+ICBmaQo+IAo+IC1hY19leHQ9Ywo+IC1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwo+IC1hY19j
b21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCj4g
LWFjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExE
RkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCj4gLWFjX2NvbXBpbGVyX2dudT0kYWNf
Y3ZfY19jb21waWxlcl9nbnUKPiAKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzIiA+JjUKPiAtJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3Jrcy4uLiAiID4mNjsgfQo+IC1MTl9TPSRhc19sbl9z
Cj4gLWlmIHRlc3QgIiRMTl9TIiA9ICJsbiAtcyI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiAtJGFzX2VjaG8gInll
cyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8sIHVzaW5nICRMTl9TIiA+JjUKPiAtJGFzX2VjaG8gIm5vLCB1c2lu
ZyAkTE5fUyIgPiY2OyB9Cj4gK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8i
OyB0aGVuIDoKPiArCj4gKyAgICBheF9jdl9weXRob250b29scz0ibiIKPiArCj4gK2VsaWYgdGVz
dCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKPiArCj4gKyAgICBheF9j
dl9weXRob250b29scz0ieSIKPiArCj4gK2VsaWYgdGVzdCAteiAkYXhfY3ZfcHl0aG9udG9vbHM7
IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5Igo+ICsKPiAgZmkKPiArcHl0
aG9udG9vbHM9JGF4X2N2X3B5dGhvbnRvb2xzCj4gCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChN
QUtFKSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNl
dHMgXCQoTUFLRSkuLi4gIiA+JjY7IH0KPiAtc2V0IHggJHtNQUtFLW1ha2V9Cj4gLWFjX21ha2U9
YCRhc19lY2hvICIkMiIgfCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAo+IC1p
ZiBldmFsICJ0ZXN0IFwiXCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0K3NldH1cIiIg
PSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAt
ICBjYXQgPmNvbmZ0ZXN0Lm1ha2UgPDxcX0FDRU9GCj4gLVNIRUxMID0gL2Jpbi9zaAo+IC1hbGw6
Cj4gLSAgICAgICBAZWNobyAnQEBAJSUlPSQoTUFLRSk9QEBAJSUlJwo+IC1fQUNFT0YKPiAtIyBH
TlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3
b3VsZCBjb25mdXNlIHVzLgo+IC1jYXNlIGAke01BS0UtbWFrZX0gLWYgY29uZnRlc3QubWFrZSAy
Pi9kZXYvbnVsbGAgaW4KPiAtICAqQEBAJSUlPT8qPUBAQCUlJSopCj4gLSAgICBldmFsIGFjX2N2
X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7Owo+IC0gICopCj4gLSAgICBldmFsIGFjX2N2
X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD1ubzs7Cj4gLWVzYWMKPiAtcm0gLWYgY29uZnRlc3Qu
bWFrZQo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xzIHdhcyBn
aXZlbi4KPiAraWYgdGVzdCAiJHtlbmFibGVfb2NhbWx0b29scytzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gKyAgZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKPiAgZmkKPiAtaWYgZXZhbCB0ZXN0
IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVzOyB0aGVuCj4gLSAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gLSRh
c19lY2hvICJ5ZXMiID4mNjsgfQo+IC0gIFNFVF9NQUtFPQo+IC1lbHNlCj4gLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KPiAtICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCj4gKwo+ICsK
PiAraWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsg
ICAgYXhfY3Zfb2NhbWx0b29scz0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0
b29scyIgPSAieHllcyI7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCj4g
Kwo+ICtlbGlmIHRlc3QgLXogJGF4X2N2X29jYW1sdG9vbHM7IHRoZW4gOgo+ICsKPiArICAgIGF4
X2N2X29jYW1sdG9vbHM9InkiCj4gKwo+ICBmaQo+ICtvY2FtbHRvb2xzPSRheF9jdl9vY2FtbHRv
b2xzCj4gCj4gLSMgRmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVyIGEgQyBw
cm9ncmFtIChmYXN0ZXIpLAo+IC0jIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBhbm90aGVy
LiAgQnV0IGF2b2lkIHRoZSBicm9rZW4gb3IKPiAtIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6Cj4g
LSMgU3lzViAvZXRjL2luc3RhbGwsIC91c3Ivc2Jpbi9pbnN0YWxsCj4gLSMgU3VuT1MgL3Vzci9l
dGMvaW5zdGFsbAo+IC0jIElSSVggL3NiaW4vaW5zdGFsbAo+IC0jIEFJWCAvYmluL2luc3RhbGwK
PiAtIyBBbWlnYU9TIC9DL2luc3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxv
cHB5IGRpc2NzCj4gLSMgQUlYIDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3
b3JrIHdpdGhvdXQgYSAtZyBmbGFnCj4gLSMgQUZTIC91c3IvYWZzd3MvYmluL2luc3RhbGwsIHdo
aWNoIG1pc2hhbmRsZXMgbm9uZXhpc3RlbnQgYXJncwo+IC0jIFNWUjQgL3Vzci91Y2IvaW5zdGFs
bCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCj4gLSMg
T1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBz
ZW1hbnRpYwo+IC0jIC4vaW5zdGFsbCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNyZWF0ZWQg
YnkgbWFrZSBmcm9tIC4vaW5zdGFsbC5zaC4KPiAtIyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0
aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZpbGVzLgo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3Rh
bGwiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0
YWxsLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgLXogIiRJTlNUQUxMIjsgdGhlbgo+IC1pZiB0ZXN0
ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2
ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgIyBBY2NvdW50
IGZvciBwZW9wbGUgd2hvIHB1dCB0cmFpbGluZyBzbGFzaGVzIGluIFBBVEggZWxlbWVudHMuCj4g
LWNhc2UgJGFzX2Rpci8gaW4gIygoCj4gLSAgLi8gfCAuLy8gfCAvW2NDXS8qIHwgXAo+IC0gIC9l
dGMvKiB8IC91c3Ivc2Jpbi8qIHwgL3Vzci9ldGMvKiB8IC9zYmluLyogfCAvdXNyL2Fmc3dzL2Jp
bi8qIHwgXAo+IC0gID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xc
L11JTlNUQUxMW1xcL10qIHwgXAo+IC0gIC91c3IvdWNiLyogKSA7Owo+IC0gICopCj4gLSAgICAj
IE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgo+
IC0gICAgIyBEb24ndCB1c2UgaW5zdGFsbGJzZCBmcm9tIE9TRiBzaW5jZSBpdCBpbnN0YWxscyBz
dHVmZiBhcyByb290Cj4gLSAgICAjIGJ5IGRlZmF1bHQuCj4gLSAgICBmb3IgYWNfcHJvZyBpbiBn
aW5zdGFsbCBzY29pbnN0IGluc3RhbGw7IGRvCj4gLSAgICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gICAgICAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgICAgICBpZiB0ZXN0ICRhY19wcm9nID0g
aW5zdGFsbCAmJgo+IC0gICAgICAgICAgIGdyZXAgZHNwbXNnICIkYXNfZGlyLyRhY19wcm9nJGFj
X2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4KPiAtICAgICAgICAgICAjIEFJWCBpbnN0
YWxsLiAgSXQgaGFzIGFuIGluY29tcGF0aWJsZSBjYWxsaW5nIGNvbnZlbnRpb24uCj4gLSAgICAg
ICAgICAgOgo+IC0gICAgICAgICBlbGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCj4gLSAg
ICAgICAgICAgZ3JlcCBwd3BsdXMgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2
L251bGwgMj4mMTsgdGhlbgo+IC0gICAgICAgICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxs
IHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgo+IC0gICAgICAgICAgIDoKPiAt
ICAgICAgICAgZWxzZQo+IC0gICAgICAgICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3Qu
dHdvIGNvbmZ0ZXN0LmRpcgo+IC0gICAgICAgICAgIGVjaG8gb25lID4gY29uZnRlc3Qub25lCj4g
LSAgICAgICAgICAgZWNobyB0d28gPiBjb25mdGVzdC50d28KPiAtICAgICAgICAgICBta2RpciBj
b25mdGVzdC5kaXIKPiAtICAgICAgICAgICBpZiAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4
dCIgLWMgY29uZnRlc3Qub25lIGNvbmZ0ZXN0LnR3byAiYHB3ZGAvY29uZnRlc3QuZGlyIiAmJgo+
IC0gICAgICAgICAgICAgdGVzdCAtcyBjb25mdGVzdC5vbmUgJiYgdGVzdCAtcyBjb25mdGVzdC50
d28gJiYKPiAtICAgICAgICAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAm
Jgo+IC0gICAgICAgICAgICAgdGVzdCAtcyBjb25mdGVzdC5kaXIvY29uZnRlc3QudHdvCj4gLSAg
ICAgICAgICAgdGhlbgo+IC0gICAgICAgICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGly
LyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgo+IC0gICAgICAgICAgICAgYnJlYWsgMwo+IC0gICAg
ICAgICAgIGZpCj4gLSAgICAgICAgIGZpCj4gLSAgICAgICBmaQo+IC0gICAgICBkb25lCj4gLSAg
ICBkb25lCj4gLSAgICA7Owo+IC1lc2FjCj4gCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZT
Cj4gCj4gLXJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgo+ICsj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgo+ICtpZiB0ZXN0ICIk
e2VuYWJsZV9taW5pdGVybStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgZW5hYmxldmFsPSRlbmFi
bGVfbWluaXRlcm07Cj4gK2ZpCj4gKwo+ICsKPiAraWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0i
ID0gInhubyI7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X21pbml0ZXJtPSJuIgo+ICsKPiArZWxp
ZiB0ZXN0ICJ4JGVuYWJsZV9taW5pdGVybSIgPSAieHllcyI7IHRoZW4gOgo+ICsKPiArICAgIGF4
X2N2X21pbml0ZXJtPSJ5Igo+ICsKPiArZWxpZiB0ZXN0IC16ICRheF9jdl9taW5pdGVybTsgdGhl
biA6Cj4gKwo+ICsgICAgYXhfY3ZfbWluaXRlcm09Im4iCj4gCj4gIGZpCj4gLSAgaWYgdGVzdCAi
JHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KPiAtICAgIElOU1RBTEw9JGFj
X2N2X3BhdGhfaW5zdGFsbAo+IC0gIGVsc2UKPiAtICAgICMgQXMgYSBsYXN0IHJlc29ydCwgdXNl
IHRoZSBzbG93IHNoZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKPiAtICAgICMgdmFsdWUgZm9y
IElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKPiAt
ICAgICMgYnJlYWsgb3RoZXIgcGFja2FnZXMgdXNpbmcgdGhlIGNhY2hlIGlmIHRoYXQgZGlyZWN0
b3J5IGlzCj4gLSAgICAjIHJlbW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZlIG5h
bWUuCj4gLSAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCj4gLSAgZmkKPiArbWluaXRlcm09JGF4
X2N2X21pbml0ZXJtCj4gKwo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21v
dW50IHdhcyBnaXZlbi4KPiAraWYgdGVzdCAiJHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gKyAgZW5hYmxldmFsPSRlbmFibGVfbG9tb3VudDsKPiAgZmkKPiAteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKPiAt
JGFzX2VjaG8gIiRJTlNUQUxMIiA+JjY7IH0KPiAKPiAtIyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1
bk9TNCBzaCBtaXNoYW5kbGVzIGJyYWNlcyBpbiAke3Zhci12YWx9Lgo+IC0jIEl0IHRoaW5rcyB0
aGUgZmlyc3QgY2xvc2UgYnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgo+IC10
ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0n
Cj4gCj4gLXRlc3QgLXogIiRJTlNUQUxMX1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5T
VEFMTH0nCj4gK2lmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInhubyI7IHRoZW4gOgo+IAo+
IC10ZXN0IC16ICIkSU5TVEFMTF9EQVRBIiAmJiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0g
NjQ0Jwo+ICsgICAgYXhfY3ZfbG9tb3VudD0ibiIKPiAKPiAtIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJiaXNvbiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4g
LXNldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Bh
dGhfQklTT04rc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2Cj4gLWVsc2UKPiAtICBjYXNlICRCSVNPTiBpbgo+IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+
IC0gIGFjX2N2X3BhdGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAgOzsKPiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElG
Uz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0
aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAtICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQo+IC0gICAgYnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlG
Uz0kYXNfc2F2ZV9JRlMKPiArZWxpZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsg
dGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfbG9tb3VudD0ieSIKPiArCj4gK2VsaWYgdGVzdCAteiAk
YXhfY3ZfbG9tb3VudDsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfbG9tb3VudD0ibiIKPiAKPiAt
ICA7Owo+IC1lc2FjCj4gIGZpCj4gLUJJU09OPSRhY19jdl9wYXRoX0JJU09OCj4gLWlmIHRlc3Qg
LW4gIiRCSVNPTiI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJEJJU09OIiA+JjUKPiAtJGFzX2VjaG8gIiRCSVNPTiIgPiY2OyB9Cj4g
LWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+IC0kYXNfZWNobyAibm8iID4mNjsgfQo+ICtsb21vdW50PSRheF9jdl9sb21v
dW50Cj4gKwo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vdm1mIHdhcyBnaXZl
bi4KPiAraWYgdGVzdCAiJHtlbmFibGVfb3ZtZitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgZW5h
YmxldmFsPSRlbmFibGVfb3ZtZjsKPiAgZmkKPiAKPiAKPiAtIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJmbGV4Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAt
c2V0IGR1bW15IGZsZXg7IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wYXRo
X0ZMRVgrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Cj4gLWVsc2UKPiAtICBjYXNlICRGTEVYIGluCj4gLSAgW1xcL10qIHwgPzpbXFwvXSopCj4gLSAg
YWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qg
d2l0aCBhIHBhdGguCj4gLSAgOzsKPiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNf
c2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9GTEVY
PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+IC0gICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19z
YXZlX0lGUwo+ICtpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4bm8iOyB0aGVuIDoKPiArCj4g
KyAgICBheF9jdl9vdm1mPSJuIgo+ICsKPiArZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4
eWVzIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3Zfb3ZtZj0ieSIKPiArCj4gK2VsaWYgdGVzdCAt
eiAkYXhfY3Zfb3ZtZjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3Zfb3ZtZj0ibiIKPiAKPiAtICA7
Owo+IC1lc2FjCj4gIGZpCj4gLUZMRVg9JGFjX2N2X3BhdGhfRkxFWAo+IC1pZiB0ZXN0IC1uICIk
RkxFWCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJEZMRVgiID4mNQo+IC0kYXNfZWNobyAiJEZMRVgiID4mNjsgfQo+IC1lbHNlCj4g
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArb3ZtZj0kYXhfY3Zfb3ZtZgo+ICsKPiArCj4g
Kwo+ICsjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtcm9tYmlvcyB3YXMgZ2l2ZW4uCj4gK2lmIHRl
c3QgIiR7ZW5hYmxlX3JvbWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZhbD0k
ZW5hYmxlX3JvbWJpb3M7Cj4gIGZpCj4gCj4gCj4gLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBk
dW1teSBwZXJsOyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QRVJM
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1l
bHNlCj4gLSAgY2FzZSAkUEVSTCBpbgo+IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+IC0gIGFjX2N2
X3BhdGhfUEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgo+IC0gIDs7Cj4gLSAgKikKPiAtICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVf
SUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+
IC0gICAgYnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9J
RlMKPiAraWYgdGVzdCAieCRlbmFibGVfcm9tYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsg
ICAgYXhfY3Zfcm9tYmlvcz0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfcm9tYmlvcyIg
PSAieHllcyI7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3JvbWJpb3M9InkiCj4gKwo+ICtlbGlm
IHRlc3QgLXogJGF4X2N2X3JvbWJpb3M7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3JvbWJpb3M9
InkiCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJM
PSJubyIKPiAtICA7Owo+IC1lc2FjCj4gIGZpCj4gLVBFUkw9JGFjX2N2X3BhdGhfUEVSTAo+IC1p
ZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJFBFUkwiID4mNQo+IC0kYXNfZWNobyAiJFBFUkwiID4mNjsg
fQo+IC1lbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArcm9tYmlvcz0kYXhfY3Zf
cm9tYmlvcwo+ICsKPiArCj4gKwo+ICsjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtc2VhYmlvcyB3
YXMgZ2l2ZW4uCj4gK2lmIHRlc3QgIiR7ZW5hYmxlX3NlYWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4g
Ogo+ICsgIGVuYWJsZXZhbD0kZW5hYmxlX3NlYWJpb3M7Cj4gK2ZpCj4gKwo+ICsKPiAraWYgdGVz
dCAieCRlbmFibGVfc2VhYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3Zfc2Vh
Ymlvcz0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieHllcyI7IHRo
ZW4gOgo+ICsKPiArICAgIGF4X2N2X3NlYWJpb3M9InkiCj4gKwo+ICtlbGlmIHRlc3QgLXogJGF4
X2N2X3NlYWJpb3M7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3NlYWJpb3M9InkiCj4gKwo+ICtm
aQo+ICtzZWFiaW9zPSRheF9jdl9zZWFiaW9zCj4gKwo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhl
ciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCj4gK2lmIHRlc3QgIiR7ZW5hYmxlX2RlYnVnK3Nl
dH0iID0gc2V0OyB0aGVuIDoKPiArICBlbmFibGV2YWw9JGVuYWJsZV9kZWJ1ZzsKPiArZmkKPiAr
Cj4gKwo+ICtpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsg
ICAgYXhfY3ZfZGVidWc9Im4iCj4gKwo+ICtlbGlmIHRlc3QgIngkZW5hYmxlX2RlYnVnIiA9ICJ4
eWVzIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfZGVidWc9InkiCj4gKwo+ICtlbGlmIHRlc3Qg
LXogJGF4X2N2X2RlYnVnOyB0aGVuIDoKPiArCj4gKyAgICBheF9jdl9kZWJ1Zz0ieSIKPiArCj4g
IGZpCj4gK2RlYnVnPSRheF9jdl9kZWJ1Zwo+ICsKPiArCj4gKwo+ICsKPiArCj4gKwo+ICsKPiAr
Cj4gK2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUwo+ICtkbwo+ICsgICAgUFJFUEVORF9D
RkxBR1MrPSIgLUkkY2ZsYWciCj4gK2RvbmUKPiArZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIK
PiArZG8KPiArICAgIFBSRVBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCj4gK2RvbmUKPiArZm9y
IGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMKPiArZG8KPiArICAgIEFQUEVORF9DRkxBR1MrPSIg
LUkkY2ZsYWciCj4gK2RvbmUKPiArZm9yIGxkZmxhZyBpbiAkQVBQRU5EX0xJQgo+ICtkbwo+ICsg
ICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgo+ICtkb25lCj4gK0NGTEFHUz0iJFBSRVBF
TkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCj4gK0xERkxBR1M9IiRQUkVQRU5EX0xE
RkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdTIgo+ICsKPiArCj4gCj4gCj4gLWlmIHRlc3Qg
eCIke1BFUkx9IiA9PSB4Im5vIgo+IC10aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxl
IHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3RhbGwgcGVybCIgIiRMSU5FTk8iIDUKPiAtZmkKPiAt
aWYgdGVzdCAieCR4YXBpIiA9ICJ4eSI7IHRoZW4gOgo+IAo+IC0gICAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgo+ICsKPiArCj4g
Kwo+ICsKPiArCj4gKwo+ICsKPiArCj4gKwo+ICsjIENoZWNrcyBmb3IgcHJvZ3JhbXMuCj4gK2Fj
X2V4dD1jCj4gK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCj4gK2FjX2NvbXBpbGU9JyRDQyAtYyAk
Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKPiArYWNfbGluaz0nJENDIC1v
IGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4k
YWNfZXh0ICRMSUJTID4mNScKPiArYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2du
dQo+ICtpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsg
YWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfQ1VSTCtzZXR9IiA9IHNl
dDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJENVUkwg
aW4KPiAtICBbXFwvXSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX0NVUkw9IiRDVVJMIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0g
ICopCj4gLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2
ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9DVVJMPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1nY2MiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFr
IDIKPiAgICBmaQo+IEBAIC01MTcxLDQ0ICsyNjU1LDM5IEBAIGRvbmUKPiAgICBkb25lCj4gIElG
Uz0kYXNfc2F2ZV9JRlMKPiAKPiAtICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19j
dl9wYXRoX0NVUkw9Im5vIgo+IC0gIDs7Cj4gLWVzYWMKPiAgZmkKPiAtQ1VSTD0kYWNfY3ZfcGF0
aF9DVVJMCj4gLWlmIHRlc3QgLW4gIiRDVVJMIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Cj4gLSRhc19lY2hvICIk
Q1VSTCIgPiY2OyB9Cj4gK2ZpCj4gK0NDPSRhY19jdl9wcm9nX0NDCj4gK2lmIHRlc3QgLW4gIiRD
QyI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJENDIiA+JjUKPiArJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAk
YXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+IC1pZiB0ZXN0IHgiJHtDVVJMfSIgPT0g
eCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwt
Y29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKPiAgZmkKPiAt
ICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieG1sMi1jb25maWciLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgeG1sMi1jb25maWc7IGFj
X3dvcmQ9JDIKPiAraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfQ0MiOyB0aGVuCj4gKyAgYWNfY3Rf
Q0M9JENDCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgZ2NjOyBhY193b3JkPSQy
Cj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YTUwrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+
ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBjYXNlICRYTUwgaW4KPiAt
ICBbXFwvXSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX1hNTD0iJFhNTCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAgOzsKPiAtICAqKQo+IC0g
IGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArICBpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJ
RlM9JGFzX3NhdmVfSUZTCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Bh
dGhfWE1MPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19h
Y19jdF9DQz0iZ2NjIgo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gICAgICBicmVhayAy
Cj4gICAgZmkKPiBAQCAtNTIxNiwzOSArMjY5NSw0MyBAQCBkb25lCj4gICAgZG9uZQo+ICBJRlM9
JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWE1MIiAmJiBhY19jdl9w
YXRoX1hNTD0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1YTUw9JGFjX2N2X3BhdGhfWE1M
Cj4gLWlmIHRlc3QgLW4gIiRYTUwiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYTUwiID4mNQo+IC0kYXNfZWNobyAiJFhNTCIgPiY2
OyB9Cj4gK2ZpCj4gK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCj4gK2lmIHRlc3QgLW4g
IiRhY19jdF9DQyI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2
OyB9Cj4gIGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0KPiAt
aWYgdGVzdCB4IiR7WE1MfSIgPT0geCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8g
IlVuYWJsZSB0byBmaW5kIHhtbDItY29uZmlnLCBwbGVhc2UgaW5zdGFsbCB4bWwyLWNvbmZpZyIg
IiRMSU5FTk8iIDUKPiAtZmkKPiAtCj4gKyAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVu
Cj4gKyAgICBDQz0iIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNf
dG9vbF93YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xf
d2FybmVkPXllcyA7Owo+ICtlc2FjCj4gKyAgICBDQz0kYWNfY3RfQ0MKPiArICBmaQo+ICtlbHNl
Cj4gKyAgQ0M9IiRhY19jdl9wcm9nX0NDIgo+ICBmaQo+IC1pZiB0ZXN0ICJ4JG9jYW1sdG9vbHMi
ID0gInh5IjsgdGhlbiA6Cj4gCj4gLSAgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYwo+IC0gIGlm
IHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjOyBh
Y193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiArICAgICAgICAgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiArICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3JkPSQyCj4g
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTEMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+
ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0IC1uICIkT0NBTUxDIjsg
dGhlbgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KPiArICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCj4gKyAgYWNfY3ZfcHJv
Z19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAgZWxzZQo+ICBh
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBB
VEgKPiBAQCAtNTI1Nyw3ICsyNzQwLDcgQEAgZG8KPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+
IC0gICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgo+ICsgICAg
YWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKPiAgICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTUyNjcsMjkgKzI3NTAsMzAgQEAg
SUZTPSRhc19zYXZlX0lGUwo+IAo+ICBmaQo+ICBmaQo+IC1PQ0FNTEM9JGFjX2N2X3Byb2dfT0NB
TUxDCj4gLWlmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEMiID4mNQo+IC0kYXNfZWNobyAi
JE9DQU1MQyIgPiY2OyB9Cj4gK0NDPSRhY19jdl9wcm9nX0NDCj4gK2lmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKPiArJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAkYXNf
ZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+ICsgIGZpCj4gIGZpCj4gLWlmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MQyI7IHRoZW4KPiAtICBhY19jdF9PQ0FNTEM9JE9DQU1MQwo+IC0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9jYW1sYzsgYWNfd29yZD0kMgo+ICtp
ZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJj
YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBj
YzsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxD
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0g
c2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAg
aWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09D
QU1MQz0iJGFjX2N0X09DQU1MQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4g
KyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+ICsgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gIGVsc2UKPiArICBhY19wcm9nX3JlamVjdGVk
PW5vCj4gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2Rp
ciBpbiAkUEFUSAo+ICBkbwo+IEBAIC01Mjk3LDcgKzI3ODEsMTEgQEAgZG8KPiAgICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9Im9jYW1sYyIKPiAr
ICAgIGlmIHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2Nj
IjsgdGhlbgo+ICsgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKPiArICAgICAgIGNvbnRpbnVl
Cj4gKyAgICAgZmkKPiArICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgo+ICAgICAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgPiY1Cj4gICAgICBicmVhayAyCj4gICAgZmkKPiBAQCAtNTMwNSw2MSArMjc5Myw0NCBA
QCBkb25lCj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gK2lmIHRlc3QgJGFjX3By
b2dfcmVqZWN0ZWQgPSB5ZXM7IHRoZW4KPiArICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBh
dGgsIHNvIG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCj4gKyAgc2V0IGR1bW15ICRhY19jdl9w
cm9nX0NDCj4gKyAgc2hpZnQKPiArICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KPiArICAgICMgV2Ug
Y2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgo+ICsgICAgIyBI
b3dldmVyLCBpdCBoYXMgdGhlIHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxsIGJlIGNo
b3Nlbgo+ICsgICAgIyBmaXJzdCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVz
ZSB0aGUgZnVsbCBmaWxlIG5hbWUuCj4gKyAgICBzaGlmdAo+ICsgICAgYWNfY3ZfcHJvZ19DQz0i
JGFzX2Rpci8kYWNfd29yZCR7MSsnICd9JEAiCj4gKyAgZmkKPiAgZmkKPiAgZmkKPiAtYWNfY3Rf
T0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQwo+IC1pZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfT0NBTUxDIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEMiID4m
NjsgfQo+ICtmaQo+ICtDQz0kYWNfY3ZfcHJvZ19DQwo+ICtpZiB0ZXN0IC1uICIkQ0MiOyB0aGVu
Cj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRD
QyIgPiY1Cj4gKyRhc19lY2hvICIkQ0MiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8g
Im5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQyIgPSB4OyB0
aGVuCj4gLSAgICBPQ0FNTEM9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3NzX2NvbXBp
bGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4g
LWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBPQ0FNTEM9JGFjX2N0X09DQU1M
Qwo+IC0gIGZpCj4gLWVsc2UKPiAtICBPQ0FNTEM9IiRhY19jdl9wcm9nX09DQU1MQyIKPiAtZmkK
PiAtCj4gLQo+IC0gIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KPiAtICAgICBPQ0FN
TFZFUlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxc
MXxwJ2AKPiAtICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjUKPiAtJGFzX2VjaG8gIk9D
YW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY2OyB9Cj4gLSAgICAgIyBJZiBPQ0FNTExJ
QiBpcyBzZXQsIHVzZSBpdAo+IC0gICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgo+
IC0gICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxD
IC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAo+IC0gICAgIGVsc2UKPiAtICAgICAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NBTUxMSUIgcHJl
dmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjUKPiAtJGFzX2VjaG8gIk9DQU1MTElCIHBy
ZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9Cj4gLSAgICAgZmkKPiAtICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NhbWwgbGli
cmFyeSBwYXRoIGlzICRPQ0FNTExJQiIgPiY1Cj4gLSRhc19lY2hvICJPQ2FtbCBsaWJyYXJ5IHBh
dGggaXMgJE9DQU1MTElCIiA+JjY7IH0KPiAtCj4gLQo+IAo+IC0KPiAtICAgICAjIGNoZWNraW5n
IGZvciBvY2FtbG9wdAo+IC0gICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
PiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxv
cHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgo+ICtmaQo+ICtpZiB0ZXN0IC16
ICIkQ0MiOyB0aGVuCj4gKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+ICsg
IGZvciBhY19wcm9nIGluIGNsLmV4ZQo+ICsgIGRvCj4gKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15ICRhY190b29sX3ByZWZpeCRhY19wcm9nOyBh
Y193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhl
biA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3Qg
LW4gIiRPQ0FNTE9QVCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX09DQU1MT1BUPSIkT0NBTUxPUFQi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICsgIGlmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KPiArICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0Lgo+ICBlbHNlCj4gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
PiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+IEBAIC01MzY4LDcgKzI4MzksNyBAQCBkbwo+ICAgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX09DQU1MT1BUPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sb3B0Igo+ICsgICAgYWNfY3ZfcHJvZ19DQz0iJGFjX3Rvb2xfcHJlZml4JGFj
X3Byb2ciCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBm
aQo+IEBAIC01Mzc4LDI4ICsyODQ5LDMyIEBAIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAg
ZmkKPiAtT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKPiAtaWYgdGVzdCAtbiAiJE9DQU1M
T1BUIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxPUFQiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7IH0KPiAr
Q0M9JGFjX2N2X3Byb2dfQ0MKPiAraWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQo+ICskYXNf
ZWNobyAiJENDIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4g
IGZpCj4gCj4gCj4gKyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCj4gKyAgZG9uZQo+ICBmaQo+
IC1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KPiAtICBhY19jdF9PQ0FN
TE9QVD0kT0NBTUxPUFQKPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9j
YW1sb3B0OyBhY193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiArICBhY19jdF9D
Qz0kQ0MKPiArICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKPiArZG8KPiArICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiArc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
PiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lm
IHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE9QVCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUPSIkYWNfY3RfT0NB
TUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICsgIGlmIHRlc3QgLW4g
IiRhY19jdF9DQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICBlbHNlCj4gIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+IEBAIC01NDA4
LDcgKzI4ODMsNyBAQCBkbwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAg
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9w
cm9nX2FjX2N0X09DQU1MT1BUPSJvY2FtbG9wdCIKPiArICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19wcm9nIgo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gICAgICBicmVhayAyCj4g
ICAgZmkKPiBAQCAtNTQxNiwxOSArMjg5MSwyMyBAQCBkb25lCj4gICAgZG9uZQo+ICBJRlM9JGFz
X3NhdmVfSUZTCj4gCj4gLWZpCj4gLWZpCj4gLWFjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MT1BUCj4gLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KPiAtICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09D
QU1MT1BUIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIgPiY2OyB9Cj4gK2ZpCj4g
K2ZpCj4gK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCj4gK2lmIHRlc3QgLW4gIiRhY19j
dF9DQyI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Cj4g
IGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3Qg
IngkYWNfY3RfT0NBTUxPUFQiID0geDsgdGhlbgo+IC0gICAgT0NBTUxPUFQ9Im5vIgo+ICsKPiAr
ICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCj4gK2RvbmUKPiArCj4gKyAgaWYgdGVzdCAi
eCRhY19jdF9DQyIgPSB4OyB0aGVuCj4gKyAgICBDQz0iIgo+ICAgIGVsc2UKPiAgICAgIGNhc2Ug
JGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAgeWVzOikKPiBAQCAtNTQzNiwz
OTYgKzI5MTUsNjQ5IEBAIHllczopCj4gICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiAgYWNf
dG9vbF93YXJuZWQ9eWVzIDs7Cj4gIGVzYWMKPiAtICAgIE9DQU1MT1BUPSRhY19jdF9PQ0FNTE9Q
VAo+ICsgICAgQ0M9JGFjX2N0X0NDCj4gICAgZmkKPiAtZWxzZQo+IC0gIE9DQU1MT1BUPSIkYWNf
Y3ZfcHJvZ19PQ0FNTE9QVCIKPiAgZmkKPiAKPiAtICAgICBPQ0FNTEJFU1Q9Ynl0ZQo+IC0gICAg
IGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCj4gLSAgICAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0
OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIgPiY1Cj4gLSRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIg
PiYyO30KPiAtICAgICBlbHNlCj4gLSAgICAgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBz
ZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCj4gLSAgICAgICBpZiB0ZXN0
ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgo+IC0gICAgICAgICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKPiAtJGFzX2VjaG8g
InZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsg
fQo+IC0gICAgICAgICAgIE9DQU1MT1BUPW5vCj4gLSAgICAgICBlbHNlCj4gLSAgICAgICAgICAg
T0NBTUxCRVNUPW9wdAo+ICtmaQo+ICsKPiArCj4gK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIg
PiY1Cj4gKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KPiAr
YXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBcJFBBVEgK
PiArU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Cj4g
Kwo+ICsjIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCj4gKyRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBp
bGVyIHZlcnNpb24iID4mNQo+ICtzZXQgWCAkYWNfY29tcGlsZQo+ICthY19jb21waWxlcj0kMgo+
ICtmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCj4gKyAgeyB7
IGFjX3RyeT0iJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1Igo+ICtjYXNlICIoKCRhY190cnki
IGluCj4gKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cj4gKyAg
KikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gK2VzYWMKPiArZXZhbCBhY190cnlfZWNobz0iXCJc
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiArJGFzX2VjaG8g
IiRhY190cnlfZWNobyI7IH0gPiY1Cj4gKyAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9u
ID4mNSIpIDI+Y29uZnRlc3QuZXJyCj4gKyAgYWNfc3RhdHVzPSQ/Cj4gKyAgaWYgdGVzdCAtcyBj
b25mdGVzdC5lcnI7IHRoZW4KPiArICAgIHNlZCAnMTBhXAo+ICsuLi4gcmVzdCBvZiBzdGRlcnIg
b3V0cHV0IGRlbGV0ZWQgLi4uCj4gKyAgICAgICAgIDEwcScgY29uZnRlc3QuZXJyID5jb25mdGVz
dC5lcjEKPiArICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1Cj4gKyAgZmkKPiArICBybSAtZiBjb25m
dGVzdC5lcjEgY29uZnRlc3QuZXJyCj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsg
fQo+ICtkb25lCj4gKwo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0Cj4gKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiArCj4gK2ludAo+ICttYWluICgpCj4gK3sK
PiArCj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4gK19BQ0VPRgo+ICthY19jbGVhbl9maWxl
c19zYXZlPSRhY19jbGVhbl9maWxlcwo+ICthY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVz
IGEub3V0IGEub3V0LmRTWU0gYS5leGUgYi5vdXQiCj4gKyMgVHJ5IHRvIGNyZWF0ZSBhbiBleGVj
dXRhYmxlIHdpdGhvdXQgLW8gZmlyc3QsIGRpc3JlZ2FyZCBhLm91dC4KPiArIyBJdCB3aWxsIGhl
bHAgdXMgZGlhZ25vc2UgYnJva2VuIGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGludHVp
dGlvbgo+ICsjIG9mIGV4ZWV4dC4KPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzIiA+JjUKPiArJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsg
fQo+ICthY19saW5rX2RlZmF1bHQ9YCRhc19lY2hvICIkYWNfbGluayIgfCBzZWQgJ3MvIC1vICpj
b25mdGVzdFteIF0qLy8nYAo+ICsKPiArIyBUaGUgcG9zc2libGUgb3V0cHV0IGZpbGVzOgo+ICth
Y19maWxlcz0iYS5vdXQgY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFfb3V0LmV4ZSBiLm91
dCBjb25mdGVzdC4qIgo+ICsKPiArYWNfcm1maWxlcz0KPiArZm9yIGFjX2ZpbGUgaW4gJGFjX2Zp
bGVzCj4gK2RvCj4gKyAgY2FzZSAkYWNfZmlsZSBpbgo+ICsgICAgKi4kYWNfZXh0IHwgKi54Y29m
ZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8
ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7Owo+ICsgICAgKiApIGFjX3JtZmlsZXM9
IiRhY19ybWZpbGVzICRhY19maWxlIjs7Cj4gKyAgZXNhYwo+ICtkb25lCj4gK3JtIC1mICRhY19y
bWZpbGVzCj4gKwo+ICtpZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19kZWZhdWx0Igo+ICtjYXNlICIo
KCRhY190cnkiIGluCj4gKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry
eTs7Cj4gKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gK2VzYWMKPiArZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiAr
JGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cj4gKyAgKGV2YWwgIiRhY19saW5rX2RlZmF1
bHQiKSAyPiY1Cj4gKyAgYWNfc3RhdHVzPSQ/Cj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVz
ID0gMDsgfTsgdGhlbiA6Cj4gKyAgIyBBdXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3Zf
ZXhlZXh0IHZhcmlhYmxlIHRvIGBubycuCj4gKyMgU28gaWdub3JlIGEgdmFsdWUgb2YgYG5vJywg
b3RoZXJ3aXNlIHRoaXMgd291bGQgbGVhZCB0byBgRVhFRVhUID0gbm8nCj4gKyMgaW4gYSBNYWtl
ZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUgYWNfY3ZfZXhlZXh0IGlmIGl0IHdhcyBjYWNo
ZWQsCj4gKyMgc28gdGhhdCB0aGUgdXNlciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9y
IGNvbXBpbGVycyB1bmtub3duIHRvCj4gKyMgQXV0b2NvbmYuCj4gK2ZvciBhY19maWxlIGluICRh
Y19maWxlcyAnJwo+ICtkbwo+ICsgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQo+ICsg
IGNhc2UgJGFjX2ZpbGUgaW4KPiArICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICou
ZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZ
TSB8ICoubyB8ICoub2JqICkKPiArICAgICAgIDs7Cj4gKyAgICBbYWJdLm91dCApCj4gKyAgICAg
ICAjIFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMgbW9z
dAo+ICsgICAgICAgIyBjZXJ0YWlubHkgcmlnaHQuCj4gKyAgICAgICBicmVhazs7Cj4gKyAgICAq
LiogKQo+ICsgICAgICAgaWYgdGVzdCAiJHthY19jdl9leGVleHQrc2V0fSIgPSBzZXQgJiYgdGVz
dCAiJGFjX2N2X2V4ZWV4dCIgIT0gbm87Cj4gKyAgICAgICB0aGVuIDo7IGVsc2UKPiArICAgICAg
ICAgIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAo+ICAg
ICAgICAgZmkKPiAtICAgICBmaQo+ICsgICAgICAgIyBXZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUg
YmVjYXVzZSB0aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMgbm90Cj4gKyAgICAgICAjIHNhZmU6IGNy
b3NzIGNvbXBpbGVycyBtYXkgbm90IGFkZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKPiAr
ICAgICAgICMgYXJndW1lbnQsIHNvIHdlIG1heSBuZWVkIHRvIGtub3cgaXQgYXQgdGhhdCBwb2lu
dCBhbHJlYWR5Lgo+ICsgICAgICAgIyBFdmVuIGlmIHRoaXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6
IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCj4gKyAgICAgICAjIGFjdHVhbGx5IHdvcmtpbmcuCj4g
KyAgICAgICBicmVhazs7Cj4gKyAgICAqICkKPiArICAgICAgIGJyZWFrOzsKPiArICBlc2FjCj4g
K2RvbmUKPiArdGVzdCAiJGFjX2N2X2V4ZWV4dCIgPSBubyAmJiBhY19jdl9leGVleHQ9Cj4gKwo+
ICtlbHNlCj4gKyAgYWNfZmlsZT0nJwo+ICtmaQo+ICtpZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRo
ZW4gOgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gKyRhc19lY2hvICIkYXNfbWU6IGZh
aWxlZCBwcm9ncmFtIHdhczoiID4mNQo+ICtzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQg
PiY1Cj4gKwo+ICt7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJy
b3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiArJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxg
JGFjX3B3ZCc6IiA+JjI7fQo+ICthc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBjYW5ub3QgY3Jl
YXRlIGV4ZWN1dGFibGVzCj4gK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIk
TElORU5PIiA1IDsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gKyRhc19lY2hvICJ5ZXMiID4mNjsgfQo+ICtm
aQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZSIgPiY1Cj4gKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZS4uLiAiID4m
NjsgfQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2ZpbGUiID4mNQo+ICskYXNfZWNobyAiJGFjX2ZpbGUiID4mNjsgfQo+ICthY19leGVleHQ9
JGFjX2N2X2V4ZWV4dAo+ICsKPiArcm0gLWYgLXIgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25m
dGVzdCRhY19jdl9leGVleHQgYi5vdXQKPiArYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVz
X3NhdmUKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxlcy4uLiAiID4mNjsgfQo+ICtpZiB7IHsgYWNfdHJ5PSIk
YWNfbGluayIKPiArY2FzZSAiKCgkYWNfdHJ5IiBpbgo+ICsgICpcIiogfCAqXGAqIHwgKlxcKikg
YWNfdHJ5X2VjaG89XCRhY190cnk7Owo+ICsgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+ICtl
c2FjCj4gK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
JGFjX3RyeV9lY2hvXCIiCj4gKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+ICsgIChl
dmFsICIkYWNfbGluayIpIDI+JjUKPiArICBhY19zdGF0dXM9JD8KPiArICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKPiArICB0ZXN0
ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKPiArICAjIElmIGJvdGggYGNvbmZ0ZXN0LmV4ZScg
YW5kIGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAod2VsbCwgb2JzZXJ2YWJsZSkKPiArIyBjYXRj
aCBgY29uZnRlc3QuZXhlJy4gIEZvciBpbnN0YW5jZSB3aXRoIEN5Z3dpbiwgYGxzIGNvbmZ0ZXN0
JyB3aWxsCj4gKyMgd29yayBwcm9wZXJseSAoaS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScp
LCB3aGlsZSBpdCB3b24ndCB3aXRoCj4gKyMgYHJtJy4KPiArZm9yIGFjX2ZpbGUgaW4gY29uZnRl
c3QuZXhlIGNvbmZ0ZXN0IGNvbmZ0ZXN0Lio7IGRvCj4gKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8
IGNvbnRpbnVlCj4gKyAgY2FzZSAkYWNfZmlsZSBpbgo+ICsgICAgKi4kYWNfZXh0IHwgKi54Y29m
ZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8
ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7Owo+ICsgICAgKi4qICkgYWNfY3ZfZXhl
ZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCj4gKyAgICAgICAgIGJyZWFr
OzsKPiArICAgICogKSBicmVhazs7Cj4gKyAgZXNhYwo+ICtkb25lCj4gK2Vsc2UKPiArICB7IHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjUKPiArJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7
fQo+ICthc19mbl9lcnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVz
OiBjYW5ub3QgY29tcGlsZSBhbmQgbGluawo+ICtTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBk
ZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KPiArZmkKPiArcm0gLWYgY29uZnRlc3QgY29uZnRlc3Qk
YWNfY3ZfZXhlZXh0Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfZXhlZXh0IiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdl9leGVleHQiID4m
NjsgfQo+IAo+ICtybSAtZiBjb25mdGVzdC4kYWNfZXh0Cj4gK0VYRUVYVD0kYWNfY3ZfZXhlZXh0
Cj4gK2FjX2V4ZWV4dD0kRVhFRVhUCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiArLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8c3RkaW8u
aD4KPiAraW50Cj4gK21haW4gKCkKPiArewo+ICtGSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5v
dXQiLCAidyIpOwo+ICsgcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAwOwo+IAo+
ICsgIDsKPiArICByZXR1cm4gMDsKPiArfQo+ICtfQUNFT0YKPiArYWNfY2xlYW5fZmlsZXM9IiRh
Y19jbGVhbl9maWxlcyBjb25mdGVzdC5vdXQiCj4gKyMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIg
cHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwgZWl0aGVyCj4gKyMgdGhl
IGNvbXBpbGVyIGlzIGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KPiAreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9z
cyBjb21waWxpbmciID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBj
cm9zcyBjb21waWxpbmcuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIg
IT0geWVzOyB0aGVuCj4gKyAgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCj4gK2Nhc2UgIigoJGFjX3Ry
eSIgaW4KPiArICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKPiAr
ICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKPiArZXNhYwo+ICtldmFsIGFjX3RyeV9lY2hvPSJc
IlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgo+ICskYXNfZWNo
byAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKPiArICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1Cj4gKyAg
YWNfc3RhdHVzPSQ/Cj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
XCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQo+ICsgIGlm
IHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCcKPiArICB7IHsgY2FzZSAiKCgkYWNf
dHJ5IiBpbgo+ICsgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owo+
ICsgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+ICtlc2FjCj4gK2V2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCj4gKyRhc19l
Y2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+ICsgIChldmFsICIkYWNfdHJ5IikgMj4mNQo+ICsg
IGFjX3N0YXR1cz0kPwo+ICsgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+ICsgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IH07IHRo
ZW4KPiArICAgIGNyb3NzX2NvbXBpbGluZz1ubwo+ICsgIGVsc2UKPiArICAgIGlmIHRlc3QgIiRj
cm9zc19jb21waWxpbmciID0gbWF5YmU7IHRoZW4KPiArICAgICAgIGNyb3NzX2NvbXBpbGluZz15
ZXMKPiArICAgIGVsc2UKPiArICAgICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQo+ICskYXNfZWNobyAiJGFzX21l
OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cj4gK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3Qg
cnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMuCj4gK0lmIHlvdSBtZWFudCB0byBjcm9zcyBjb21waWxl
LCB1c2UgXGAtLWhvc3QnLgo+ICtTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAi
JExJTkVOTyIgNSA7IH0KPiArICAgIGZpCj4gKyAgZmkKPiArZmkKPiAreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRjcm9zc19jb21waWxpbmciID4mNQo+
ICskYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIgPiY2OyB9Cj4gCj4gLSAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxjLm9wdAo+IC0gICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRo
ZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBk
dW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3Jt
IC1mIGNvbmZ0ZXN0LiRhY19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNvbmZ0ZXN0Lm91dAo+
ICthY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQo+ICt7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZp
bGVzIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmls
ZXMuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9vYmpleHQrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0
IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIk
T0NBTUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+
IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4g
JFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
Yy5vcHQiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIKPiAtICBm
aQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gKyAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICov
Cj4gCj4gLWZpCj4gLWZpCj4gLU9DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQK
PiAtaWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9QVCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQ0RPVE9QVCIgPiY1Cj4gLSRh
c19lY2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJu
byIgPiY2OyB9Cj4gLWZpCj4gK2ludAo+ICttYWluICgpCj4gK3sKPiAKPiArICA7Cj4gKyAgcmV0
dXJuIDA7Cj4gK30KPiArX0FDRU9GCj4gK3JtIC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqCj4g
K2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgo+ICtjYXNlICIoKCRhY190cnkiIGluCj4gKyAg
KlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cj4gKyAgKikgYWNfdHJ5
X2VjaG89JGFjX3RyeTs7Cj4gK2VzYWMKPiArZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiArJGFzX2VjaG8gIiRhY190cnlf
ZWNobyI7IH0gPiY1Cj4gKyAgKGV2YWwgIiRhY19jb21waWxlIikgMj4mNQo+ICsgIGFjX3N0YXR1
cz0kPwo+ICsgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh
Y19zdGF0dXMiID4mNQo+ICsgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgo+ICsgIGZv
ciBhY19maWxlIGluIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCj4gKyAg
dGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOwo+ICsgIGNhc2UgJGFjX2ZpbGUgaW4KPiAr
ICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwg
Ki5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSApIDs7Cj4gKyAgICAqKSBhY19j
dl9vYmpleHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKPiArICAgICAgIGJyZWFr
OzsKPiArICBlc2FjCj4gK2RvbmUKPiArZWxzZQo+ICsgICRhc19lY2hvICIkYXNfbWU6IGZhaWxl
ZCBwcm9ncmFtIHdhczoiID4mNQo+ICtzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1
Cj4gCj4gK3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNf
cHdkJzoiID4mMjt9Cj4gK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Yg
b2JqZWN0IGZpbGVzOiBjYW5ub3QgY29tcGlsZQo+ICtTZWUgXGBjb25maWcubG9nJyBmb3IgbW9y
ZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KPiAgZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3By
b2dfT0NBTUxDRE9UT1BUIjsgdGhlbgo+IC0gIGFjX2N0X09DQU1MQ0RPVE9QVD0kT0NBTUxDRE9U
T1BUCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMub3B0Iiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9jYW1sYy5vcHQ7
IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RP
VE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3JtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQg
Y29uZnRlc3QuJGFjX2V4dAo+ICtmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3Zf
b2JqZXh0IiA+JjY7IH0KPiArT0JKRVhUPSRhY19jdl9vYmpleHQKPiArYWNfb2JqZXh0PSRPQkpF
WFQKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3
aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQo+ICskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+
JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNldDsgdGhl
biA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN
TENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
PiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9
Im9jYW1sYy5vcHQiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIK
PiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMu
aC4gICovCj4gCj4gLWZpCj4gLWZpCj4gLWFjX2N0X09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTENET1RPUFQKPiAtaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRo
ZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N0X09DQU1MQ0RPVE9QVCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3RfT0NBTUxDRE9UT1BU
IiA+JjY7IH0KPiAraW50Cj4gK21haW4gKCkKPiArewo+ICsjaWZuZGVmIF9fR05VQ19fCj4gKyAg
ICAgICBjaG9rZSBtZQo+ICsjZW5kaWYKPiArCj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4g
K19BQ0VPRgo+ICtpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gKyAg
YWNfY29tcGlsZXJfZ251PXllcwo+ICBlbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0K
PiArICBhY19jb21waWxlcl9nbnU9bm8KPiAgZmkKPiArcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK2FjX2N2X2NfY29tcGlsZXJf
Z251PSRhY19jb21waWxlcl9nbnUKPiAKPiAtICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQ0RPVE9Q
VCIgPSB4OyB0aGVuCj4gLSAgICBPQ0FNTENET1RPUFQ9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNh
c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mMjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBPQ0FN
TENET1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAo+IC0gIGZpCj4gK2ZpCj4gK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9n
bnUiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KPiAraWYg
dGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCj4gKyAgR0NDPXllcwo+ICBlbHNlCj4g
LSAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCj4gKyAgR0NDPQo+ICBm
aQo+IC0KPiAtICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCj4gLSAg
ICAgICBUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAo+IC0gICAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIk
T0NBTUxWRVJTSU9OIiA7IHRoZW4KPiAtICAgICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKPiAtJGFzX2VjaG8gInZlcnNpb25zIGRpZmZlcnMg
ZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9Cj4gLSAgICAgICBlbHNl
Cj4gLSAgICAgICAgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKPiAtICAgICAgIGZpCj4gLSAgICAg
ZmkKPiAtCj4gLSAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0Cj4gLSAgICAgaWYgdGVz
dCAiJE9DQU1MT1BUIiAhPSAibm8iIDsgdGhlbgo+IC0gICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rv
b2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190
b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7IGFjX3dv
cmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3NldH0i
ID0gc2V0OyB0aGVuIDoKPiArYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQo+ICthY19zYXZl
X0NGTEFHUz0kQ0ZMQUdTCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1Cj4gKyRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHth
Y19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVu
Cj4gLSAgYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9
JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2df
T0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Igo+IC0gICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRv
bmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+ICsgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193
ZXJyb3JfZmxhZwo+ICsgICBhY19jX3dlcnJvcl9mbGFnPXllcwo+ICsgICBhY19jdl9wcm9nX2Nj
X2c9bm8KPiArICAgQ0ZMQUdTPSItZyIKPiArICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICovCj4gCj4gLWZpCj4gLWZp
Cj4gLU9DQU1MT1BURE9UT1BUPSRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUCj4gLWlmIHRlc3Qg
LW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKPiAtJGFzX2VjaG8g
IiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9Cj4gK2ludAo+ICttYWluICgpCj4gK3sKPiArCj4gKyAg
Owo+ICsgIHJldHVybiAwOwo+ICt9Cj4gK19BQ0VPRgo+ICtpZiBhY19mbl9jX3RyeV9jb21waWxl
ICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfcHJvZ19jY19nPXllcwo+ICBlbHNlCj4gLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
PiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtZmkKPiArICBDRkxBR1M9IiIKPiArICAgICAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRl
ZnMuaC4gICovCj4gCj4gK2ludAo+ICttYWluICgpCj4gK3sKPiAKPiAtZmkKPiAtaWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gLSAgYWNfY3RfT0NBTUxPUFRE
T1RPUFQ9JE9DQU1MT1BURE9UT1BUCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1z
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE9QVERPVE9QVCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BU
PSIkYWNfY3RfT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9y
IGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVD0ib2Nh
bWxvcHQub3B0Igo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4g
LSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+ICsgIDsKPiArICBy
ZXR1cm4gMDsKPiArfQo+ICtfQUNFT0YKPiAraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVO
TyI7IHRoZW4gOgo+ICsKPiArZWxzZQo+ICsgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193
ZXJyb3JfZmxhZwo+ICsgICAgICAgIENGTEFHUz0iLWciCj4gKyAgICAgICAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICov
Cj4gKwo+ICtpbnQKPiArbWFpbiAoKQo+ICt7Cj4gCj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9
Cj4gK19BQ0VPRgo+ICtpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4g
KyAgYWNfY3ZfcHJvZ19jY19nPXllcwo+ICBmaQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAgZmkKPiAtYWNfY3RfT0NBTUxP
UFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQKPiAtaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNQo+IC0k
YXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRh
c19lY2hvICJubyIgPiY2OyB9Cj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+ICBmaQo+IC0KPiAtICBpZiB0ZXN0ICJ4JGFjX2N0
X09DQU1MT1BURE9UT1BUIiA9IHg7IHRoZW4KPiAtICAgIE9DQU1MT1BURE9UT1BUPSJubyIKPiAr
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNf
ZXh0Cj4gKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwo+ICtmaQo+
ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X3Byb2dfY2NfZyIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KPiAr
aWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9IHNldDsgdGhlbgo+ICsgIENGTEFHUz0kYWNfc2F2
ZV9DRkxBR1MKPiArZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KPiArICBp
ZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgo+ICsgICAgQ0ZMQUdTPSItZyAtTzIiCj4gICAgZWxz
ZQo+IC0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgo+IC15ZXM6
KQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Cj4gLSRh
c19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3
aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiAtYWNfdG9vbF93YXJuZWQ9eWVzIDs7Cj4gLWVzYWMK
PiAtICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERPVE9QVAo+ICsgICAgQ0ZMQUdT
PSItZyIKPiAgICBmaQo+ICBlbHNlCj4gLSAgT0NBTUxPUFRET1RPUFQ9IiRhY19jdl9wcm9nX09D
QU1MT1BURE9UT1BUIgo+IC1maQo+IC0KPiAtICAgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVERPVE9Q
VCIgIT0gIm5vIjsgdGhlbgo+IC0gICAgICAgICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BU
IC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAo+IC0gICAgICAg
ICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KPiAtICAg
ICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuIiA+
JjUKPiAtJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0
IGRpc2NhcmRlZC4iID4mNjsgfQo+IC0gICAgICAgICAgZWxzZQo+IC0gICAgICAgICAgICAgT0NB
TUxPUFQ9JE9DQU1MT1BURE9UT1BUCj4gLSAgICAgICAgICBmaQo+IC0gICAgICAgIGZpCj4gLSAg
ICAgZmkKPiAtCj4gLQo+ICsgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCj4gKyAgICBDRkxB
R1M9Ii1PMiIKPiArICBlbHNlCj4gKyAgICBDRkxBR1M9Cj4gICAgZmkKPiArZmkKPiAreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlv
biB0byBhY2NlcHQgSVNPIEM4OSIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mg
b3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2Cj4gK2Vsc2UKPiArICBhY19jdl9wcm9nX2NjX2M4OT1ubwo+ICthY19zYXZlX0NDPSRD
Qwo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KPiArI2luY2x1ZGUgPHN0ZGFyZy5oPgo+ICsjaW5jbHVkZSA8c3Rk
aW8uaD4KPiArI2luY2x1ZGUgPHN5cy90eXBlcy5oPgo+ICsjaW5jbHVkZSA8c3lzL3N0YXQuaD4K
PiArLyogTW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43
J3Mgc3JjL2NvbmYuc2guICAqLwo+ICtzdHJ1Y3QgYnVmIHsgaW50IHg7IH07Cj4gK0ZJTEUgKiAo
KnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Cj4gK3N0YXRpYyBj
aGFyICplIChwLCBpKQo+ICsgICAgIGNoYXIgKipwOwo+ICsgICAgIGludCBpOwo+ICt7Cj4gKyAg
cmV0dXJuIHBbaV07Cj4gK30KPiArc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoq
LCBpbnQpLCBjaGFyICoqcCwgLi4uKQo+ICt7Cj4gKyAgY2hhciAqczsKPiArICB2YV9saXN0IHY7
Cj4gKyAgdmFfc3RhcnQgKHYscCk7Cj4gKyAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKPiAr
ICB2YV9lbmQgKHYpOwo+ICsgIHJldHVybiBzOwo+ICt9Cj4gCj4gKy8qIE9TRiA0LjAgQ29tcGFx
IGNjIGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQgaGFzCj4gKyAg
IGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hhcmFj
dGVyIGNvbnN0YW50cy4KPiArICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1
bmF0ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCj4gKyAgIGFzICd4Jy4gIFRoZSBm
b2xsb3dpbmcgaW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQKPiAr
ICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMg
b3V0IHRydWUsIGZvciBhbgo+ICsgICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3Nh
cnkgdG8gd3JpdGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKPiArICAgdGhhdCdzIHRydWUg
b25seSB3aXRoIC1zdGQuICAqLwo+ICtpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAx
IDogLTFdOwo+IAo+ICsvKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVs
dCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKPiArICAgaW5zaWRlIHN0cmluZ3Mg
YW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwo+ICsjZGVmaW5lIEZPTyh4KSAneCcKPiAraW50
IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07Cj4gCj4gLSAgIyBjaGVja2lu
ZyBmb3Igb2NhbWwgdG9wbGV2ZWwKPiAtICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0
aGVuCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHth
Y19jdl9wcm9nX09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgo+IC0gIGFj
X2N2X3Byb2dfT0NBTUw9IiRPQ0FNTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
Cj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+IC1mb3Ig
YXNfZGlyIGluICRQQVRICj4gK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOwo+ICtzdHJ1Y3Qg
czEge2ludCAoKmYpIChpbnQgYSk7fTsKPiArc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91YmxlIGEp
O307Cj4gK2ludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYg
Kiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOwo+ICtpbnQgYXJnYzsKPiArY2hhciAq
KmFyZ3Y7Cj4gK2ludAo+ICttYWluICgpCj4gK3sKPiArcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9
IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOwo+ICsgIDsKPiArICByZXR1
cm4gMDsKPiArfQo+ICtfQUNFT0YKPiArZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5
IC1xbGFuZ2x2bD1hbnNpIC1zdGQgXAo+ICsgICAgICAgLUFlICItQWEgLURfSFBVWF9TT1VSQ0Ui
ICItWGMgLURfX0VYVEVOU0lPTlNfXyIKPiAgZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7YWNfdG9vbF9w
cmVmaXh9b2NhbWwiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIK
PiAtICBmaQo+ICsgIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgo+ICsgIGlmIGFjX2ZuX2NfdHJ5
X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiArICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJn
Cj4gK2ZpCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKPiAr
ICB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSAieG5vIiAmJiBicmVhawo+ICBkb25lCj4g
LSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKPiAr
Q0M9JGFjX3NhdmVfQ0MKPiAKPiAgZmkKPiAtZmkKPiAtT0NBTUw9JGFjX2N2X3Byb2dfT0NBTUwK
PiAtaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUwiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1M
IiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gKyMgQUNfQ0FD
SEVfVkFMCj4gK2Nhc2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCj4gKyAgeCkKPiArICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRl
ZCIgPiY1Cj4gKyRhc19lY2hvICJub25lIG5lZWRlZCIgPiY2OyB9IDs7Cj4gKyAgeG5vKQo+ICsg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3Vw
cG9ydGVkIiA+JjUKPiArJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKPiArICAqKQo+
ICsgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCj4gKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUK
PiArJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Cj4gK2VzYWMKPiAraWYg
dGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0aGVuIDoKPiArCj4gIGZpCj4gCj4g
K2FjX2V4dD1jCj4gK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCj4gK2FjX2NvbXBpbGU9JyRDQyAt
YyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKPiArYWNfbGluaz0nJEND
IC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVz
dC4kYWNfZXh0ICRMSUJTID4mNScKPiArYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVy
X2dudQo+IAo+IC1maQo+IC1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTCI7IHRoZW4KPiAt
ICBhY19jdF9PQ0FNTD0kT0NBTUwKPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9j
YW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15
IG9jYW1sOyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIg
PiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQo
TUFLRSkuLi4gIiA+JjY7IH0KPiArc2V0IHggJHtNQUtFLW1ha2V9Cj4gK2FjX21ha2U9YCRhc19l
Y2hvICIkMiIgfCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAo+ICtpZiBldmFs
ICJ0ZXN0IFwiXCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0K3NldH1cIiIgPSBzZXQ7
IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0
ZXN0IC1uICIkYWNfY3RfT0NBTUwiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0i
JGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+
IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4g
JFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgo+IC0gICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAt
SUZTPSRhc19zYXZlX0lGUwo+IC0KPiAtZmkKPiAtZmkKPiAtYWNfY3RfT0NBTUw9JGFjX2N2X3By
b2dfYWNfY3RfT0NBTUwKPiAtaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgo+IC0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB
TUwiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4g
LSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4gLQo+IC0gIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUwiID0geDsgdGhlbgo+IC0gICAgT0NBTUw9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNy
b3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBX
QVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQi
ID4mMjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICsgIGNhdCA+Y29uZnRlc3QubWFrZSA8
PFxfQUNFT0YKPiArU0hFTEwgPSAvYmluL3NoCj4gK2FsbDoKPiArICAgICAgIEBlY2hvICdAQEAl
JSU9JChNQUtFKT1AQEAlJSUnCj4gK19BQ0VPRgo+ICsjIEdOVSBtYWtlIHNvbWV0aW1lcyBwcmlu
dHMgIm1ha2VbMV06IEVudGVyaW5nIC4uLiIsIHdoaWNoIHdvdWxkIGNvbmZ1c2UgdXMuCj4gK2Nh
c2UgYCR7TUFLRS1tYWtlfSAtZiBjb25mdGVzdC5tYWtlIDI+L2Rldi9udWxsYCBpbgo+ICsgICpA
QEAlJSU9Pyo9QEBAJSUlKikKPiArICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1f
c2V0PXllczs7Cj4gKyAgKikKPiArICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1f
c2V0PW5vOzsKPiAgZXNhYwo+IC0gICAgT0NBTUw9JGFjX2N0X09DQU1MCj4gLSAgZmkKPiArcm0g
LWYgY29uZnRlc3QubWFrZQo+ICtmaQo+ICtpZiBldmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2Vf
JHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2VjaG8gInllcyIgPiY2OyB9
Cj4gKyAgU0VUX01BS0U9Cj4gIGVsc2UKPiAtICBPQ0FNTD0iJGFjX2N2X3Byb2dfT0NBTUwiCj4g
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFr
ZX0iCj4gIGZpCj4gCj4gLQo+IC0gICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCj4gLSAgaWYgdGVz
dCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBh
Y193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gKyMgRmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVy
IGEgQyBwcm9ncmFtIChmYXN0ZXIpLAo+ICsjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBh
bm90aGVyLiAgQnV0IGF2b2lkIHRoZSBicm9rZW4gb3IKPiArIyBpbmNvbXBhdGlibGUgdmVyc2lv
bnM6Cj4gKyMgU3lzViAvZXRjL2luc3RhbGwsIC91c3Ivc2Jpbi9pbnN0YWxsCj4gKyMgU3VuT1Mg
L3Vzci9ldGMvaW5zdGFsbAo+ICsjIElSSVggL3NiaW4vaW5zdGFsbAo+ICsjIEFJWCAvYmluL2lu
c3RhbGwKPiArIyBBbWlnYU9TIC9DL2luc3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mg
b24gZmxvcHB5IGRpc2NzCj4gKyMgQUlYIDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9l
c24ndCB3b3JrIHdpdGhvdXQgYSAtZyBmbGFnCj4gKyMgQUZTIC91c3IvYWZzd3MvYmluL2luc3Rh
bGwsIHdoaWNoIG1pc2hhbmRsZXMgbm9uZXhpc3RlbnQgYXJncwo+ICsjIFNWUjQgL3Vzci91Y2Iv
aW5zdGFsbCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYi
Cj4gKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZl
cmVudCBzZW1hbnRpYwo+ICsjIC4vaW5zdGFsbCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNy
ZWF0ZWQgYnkgbWFrZSBmcm9tIC4vaW5zdGFsbC5zaC4KPiArIyBSZWplY3QgaW5zdGFsbCBwcm9n
cmFtcyB0aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZpbGVzLgo+ICt7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxl
IGluc3RhbGwiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJs
ZSBpbnN0YWxsLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgLXogIiRJTlNUQUxMIjsgdGhlbgo+ICtp
ZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRPQ0FNTERF
UCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
Cj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3NhdmVfSUZTCj4gICAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxkZXAiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJy
ZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gKyAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0
IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KPiArY2FzZSAkYXNfZGlyLyBpbiAj
KCgKPiArICAuLyB8IC4vLyB8IC9bY0NdLyogfCBcCj4gKyAgL2V0Yy8qIHwgL3Vzci9zYmluLyog
fCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCj4gKyAgPzpbXFwv
XW9zMltcXC9daW5zdGFsbFtcXC9dKiB8ID86W1xcL11PUzJbXFwvXUlOU1RBTExbXFwvXSogfCBc
Cj4gKyAgL3Vzci91Y2IvKiApIDs7Cj4gKyAgKikKPiArICAgICMgT1NGMSBhbmQgU0NPIE9EVCAz
LjAgaGF2ZSB0aGVpciBvd24gbmFtZXMgZm9yIGluc3RhbGwuCj4gKyAgICAjIERvbid0IHVzZSBp
bnN0YWxsYnNkIGZyb20gT1NGIHNpbmNlIGl0IGluc3RhbGxzIHN0dWZmIGFzIHJvb3QKPiArICAg
ICMgYnkgZGVmYXVsdC4KPiArICAgIGZvciBhY19wcm9nIGluIGdpbnN0YWxsIHNjb2luc3QgaW5z
dGFsbDsgZG8KPiArICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCj4gKyAgICAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNf
ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9
OyB0aGVuCj4gKyAgICAgICAgIGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCj4gKyAgICAg
ICAgICAgZ3JlcCBkc3Btc2cgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251
bGwgMj4mMTsgdGhlbgo+ICsgICAgICAgICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5j
b21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KPiArICAgICAgICAgICA6Cj4gKyAgICAgICAg
IGVsaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKPiArICAgICAgICAgICBncmVwIHB3cGx1
cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCj4g
KyAgICAgICAgICAgIyBwcm9ncmFtLXNwZWNpZmljIGluc3RhbGwgc2NyaXB0IHVzZWQgYnkgSFAg
cHdwbHVzLS1kb24ndCB1c2UuCj4gKyAgICAgICAgICAgOgo+ICsgICAgICAgICBlbHNlCj4gKyAg
ICAgICAgICAgcm0gLXJmIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRlc3QuZGlyCj4g
KyAgICAgICAgICAgZWNobyBvbmUgPiBjb25mdGVzdC5vbmUKPiArICAgICAgICAgICBlY2hvIHR3
byA+IGNvbmZ0ZXN0LnR3bwo+ICsgICAgICAgICAgIG1rZGlyIGNvbmZ0ZXN0LmRpcgo+ICsgICAg
ICAgICAgIGlmICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAtYyBjb25mdGVzdC5vbmUg
Y29uZnRlc3QudHdvICJgcHdkYC9jb25mdGVzdC5kaXIiICYmCj4gKyAgICAgICAgICAgICB0ZXN0
IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgo+ICsgICAgICAgICAg
ICAgdGVzdCAtcyBjb25mdGVzdC5kaXIvY29uZnRlc3Qub25lICYmCj4gKyAgICAgICAgICAgICB0
ZXN0IC1zIGNvbmZ0ZXN0LmRpci9jb25mdGVzdC50d28KPiArICAgICAgICAgICB0aGVuCj4gKyAg
ICAgICAgICAgICBhY19jdl9wYXRoX2luc3RhbGw9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19l
eHQgLWMiCj4gKyAgICAgICAgICAgICBicmVhayAzCj4gKyAgICAgICAgICAgZmkKPiArICAgICAg
ICAgZmkKPiArICAgICAgIGZpCj4gKyAgICAgIGRvbmUKPiArICAgIGRvbmUKPiArICAgIDs7Cj4g
K2VzYWMKPiArCj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gK3JtIC1yZiBjb25m
dGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgo+ICsKPiAgZmkKPiArICBpZiB0ZXN0
ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgo+ICsgICAgSU5TVEFMTD0k
YWNfY3ZfcGF0aF9pbnN0YWxsCj4gKyAgZWxzZQo+ICsgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1
c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQo+ICsgICAgIyB2YWx1ZSBm
b3IgSU5TVEFMTCB3aXRoaW4gYSBzb3VyY2UgZGlyZWN0b3J5LCBiZWNhdXNlIHRoYXQgd2lsbAo+
ICsgICAgIyBicmVhayBvdGhlciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBkaXJl
Y3RvcnkgaXMKPiArICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUg
bmFtZS4KPiArICAgIElOU1RBTEw9JGFjX2luc3RhbGxfc2gKPiArICBmaQo+ICBmaQo+IC1PQ0FN
TERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAo+IC1pZiB0ZXN0IC1uICIkT0NBTUxERVAiOyB0aGVu
Cj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRP
Q0FNTERFUCIgPiY1Cj4gLSRhc19lY2hvICIkT0NBTUxERVAiID4mNjsgfQo+IC1lbHNlCj4gLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
PiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtZmkKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKPiArJGFzX2VjaG8gIiRJTlNU
QUxMIiA+JjY7IH0KPiAKPiArIyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1bk9TNCBzaCBtaXNoYW5k
bGVzIGJyYWNlcyBpbiAke3Zhci12YWx9Lgo+ICsjIEl0IHRoaW5rcyB0aGUgZmlyc3QgY2xvc2Ug
YnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgo+ICt0ZXN0IC16ICIkSU5TVEFM
TF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCj4gCj4gLWZpCj4gLWlm
IHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MREVQIjsgdGhlbgo+IC0gIGFjX2N0X09DQU1MREVQ
PSRPQ0FNTERFUAo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgb2NhbWxk
ZXA7IGFjX3dvcmQ9JDIKPiArdGVzdCAteiAiJElOU1RBTExfU0NSSVBUIiAmJiBJTlNUQUxMX1ND
UklQVD0nJHtJTlNUQUxMfScKPiArCj4gK3Rlc3QgLXogIiRJTlNUQUxMX0RBVEEiICYmIElOU1RB
TExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCj4gKwo+ICsjIEV4dHJhY3QgdGhlIGZpcnN0IHdv
cmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAr
c2V0IGR1bW15IGJpc29uOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cGF0aF9CSVNPTitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KPiAt
ICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxERVAiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiArICBjYXNlICRCSVNPTiBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10q
KQo+ICsgIGFjX2N2X3BhdGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAg
IElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4g
ICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTERFUD0ib2NhbWxkZXAiCj4gKyAgICBhY19jdl9wYXRoX0JJU09OPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Cj4gICAgICBicmVhayAyCj4gICAgZmkKPiBAQCAtNTgzMyw1MyArMzU2NSwzOSBAQCBkb25lCj4g
ICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gKyAgOzsKPiArZXNhYwo+ICBmaQo+IC1m
aQo+IC1hY19jdF9PQ0FNTERFUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUAo+IC1pZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERFUCIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3RfT0NBTUxERVAiID4mNjsgfQo+ICtCSVNPTj0kYWNfY3ZfcGF0aF9CSVNPTgo+ICtp
ZiB0ZXN0IC1uICIkQklTT04iOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1Cj4gKyRhc19lY2hvICIkQklTT04iID4m
NjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtICBp
ZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7IHRoZW4KPiAtICAgIE9DQU1MREVQPSJubyIK
PiAtICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cj4gLXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsK
PiAtZXNhYwo+IC0gICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCj4gLSAgZmkKPiAtZWxzZQo+
IC0gIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKPiAtZmkKPiAtCj4gCj4gLSAgIyBj
aGVja2luZyBmb3Igb2NhbWxta3RvcAo+IC0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxta3RvcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKPiArIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJmbGV4Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KPiArc2V0IGR1bW15IGZsZXg7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+
ICAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVz
dCAiJHthY19jdl9wcm9nX09DQU1MTUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0
ICIke2FjX2N2X3BhdGhfRkxFWCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhl
bgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJE9DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKPiArICBjYXNlICRGTEVYIGluCj4gKyAgW1xcL10qIHwgPzpbXFwvXSopCj4g
KyAgYWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl
c3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0k
YXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCj4gKyAgICBhY19jdl9wYXRo
X0ZMRVg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gICAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC01ODg3LDM5ICszNjA1LDM5IEBA
IGRvbmUKPiAgICBkb25lCj4gIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiArICA7Owo+ICtlc2FjCj4g
IGZpCj4gLWZpCj4gLU9DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxNS1RPUAo+IC1pZiB0ZXN0
IC1uICIkT0NBTUxNS1RPUCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtUT1AiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1M
TUtUT1AiID4mNjsgfQo+ICtGTEVYPSRhY19jdl9wYXRoX0ZMRVgKPiAraWYgdGVzdCAtbiAiJEZM
RVgiOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRGTEVYIiA+JjUKPiArJGFzX2VjaG8gIiRGTEVYIiA+JjY7IH0KPiAgZWxzZQo+ICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gCj4gLWZpCj4gLWlmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCj4gLSAgYWNfY3RfT0NBTUxNS1RPUD0kT0NB
TUxNS1RPUAo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta3RvcCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBvY2FtbG1r
dG9wOyBhY193b3JkPSQyCj4gKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBwZXJsOyBh
Y193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9Q
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX1BFUkwrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAt
ICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MTUtUT1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCj4gKyAgY2FzZSAkUEVSTCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2
X3BhdGhfUEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgo+ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3NhdmVf
SUZTCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxNS1RPUD0ib2NhbWxta3RvcCIKPiArICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJl
YWsgMgo+ICAgIGZpCj4gQEAgLTU5MjcsNTMgKzM2NDUsNDYgQEAgZG9uZQo+ICAgIGRvbmUKPiAg
SUZTPSRhc19zYXZlX0lGUwo+IAo+ICsgIHRlc3QgLXogIiRhY19jdl9wYXRoX1BFUkwiICYmIGFj
X2N2X3BhdGhfUEVSTD0ibm8iCj4gKyAgOzsKPiArZXNhYwo+ICBmaQo+IC1maQo+IC1hY19jdF9P
Q0FNTE1LVE9QPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtUT1AKPiAtaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MTUtUT1AiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9QIiA+JjUKPiAtJGFzX2VjaG8gIiRh
Y19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KPiArUEVSTD0kYWNfY3ZfcGF0aF9QRVJMCj4gK2lmIHRl
c3QgLW4gIiRQRVJMIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkUEVSTCIgPiY1Cj4gKyRhc19lY2hvICIkUEVSTCIgPiY2OyB9Cj4g
IGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3Qg
IngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4OyB0aGVuCj4gLSAgICBPQ0FNTE1LVE9QPSJubyIKPiAt
ICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4g
LXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
PiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp
eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsKPiAt
ZXNhYwo+IC0gICAgT0NBTUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAo+IC0gIGZpCj4gLWVsc2UK
PiAtICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgo+IC1maQo+IAo+ICtpZiB0
ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kIHBlcmwsIHBsZWFzZSBpbnN0YWxsIHBlcmwiICIkTElORU5PIiA1Cj4gK2Zp
Cj4gK2lmIHRlc3QgIngkeGFwaSIgPSAieHkiOyB0aGVuIDoKPiAKPiAtICAjIGNoZWNraW5nIGZv
ciBvY2FtbG1rbGliCj4gLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGli
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0kMgo+ICsgICAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgo+ICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
K2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9DVVJMK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJE9DQU1MTUtM
SUIiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGNhc2UgJENVUkwgaW4KPiArICBbXFwvXSogfCA/Oltc
XC9dKikKPiArICBhY19jdl9wYXRoX0NVUkw9IiRDVVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiArICA7Owo+ICsgICopCj4gKyAgYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gIGRvCj4g
ICAgSUZTPSRhc19zYXZlX0lGUwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4g
ICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
PiAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19j
dl9wcm9nX09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKPiArICAgIGFj
X2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAgICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTU5ODEsMzkgKzM2
OTIsNDQgQEAgZG9uZQo+ICAgIGRvbmUKPiAgSUZTPSRhc19zYXZlX0lGUwo+IAo+ICsgIHRlc3Qg
LXogIiRhY19jdl9wYXRoX0NVUkwiICYmIGFjX2N2X3BhdGhfQ1VSTD0ibm8iCj4gKyAgOzsKPiAr
ZXNhYwo+ICBmaQo+IC1maQo+IC1PQ0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKPiAt
aWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LTElCIiA+JjUKPiAtJGFzX2VjaG8g
IiRPQ0FNTE1LTElCIiA+JjY7IH0KPiArQ1VSTD0kYWNfY3ZfcGF0aF9DVVJMCj4gK2lmIHRlc3Qg
LW4gIiRDVVJMIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Cj4gKyRhc19lY2hvICIkQ1VSTCIgPiY2OyB9Cj4gIGVs
c2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+ICtpZiB0ZXN0IHgi
JHtDVVJMfSIgPT0geCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8i
IDUKPiAgZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRoZW4KPiAt
ICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJvY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiAtc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKPiArICAgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAieG1sMi1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIKPiAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQo+ICAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0K
PiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2X3BhdGhfWE1MK3NldH0iID0gc2V0OyB0aGVuIDoKPiAg
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MTUtMSUIiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSIk
YWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gLWVs
c2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGNhc2UgJFhN
TCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2X3BhdGhfWE1MPSIkWE1MIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiArICA7Owo+ICsg
ICopCj4gKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNf
ZGlyIGluICRQQVRICj4gIGRvCj4gICAgSUZTPSRhc19zYXZlX0lGUwo+ICAgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9Im9jYW1sbWtsaWIi
Cj4gKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAg
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTYw
MjEsNDQgKzM3MzcsMzkgQEAgZG9uZQo+ICAgIGRvbmUKPiAgSUZTPSRhc19zYXZlX0lGUwo+IAo+
ICsgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hNTCIgJiYgYWNfY3ZfcGF0aF9YTUw9Im5vIgo+ICsg
IDs7Cj4gK2VzYWMKPiAgZmkKPiAtZmkKPiAtYWNfY3RfT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LTElCCj4gLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgo+
IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxNS0xJQiIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3RfT0NBTUxNS0xJQiIgPiY2OyB9
Cj4gK1hNTD0kYWNfY3ZfcGF0aF9YTUwKPiAraWYgdGVzdCAtbiAiJFhNTCI7IHRoZW4KPiArICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1
Cj4gKyRhc19lY2hvICIkWE1MIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJubyIg
PiY2OyB9Cj4gIGZpCj4gCj4gLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LTElCIiA9IHg7IHRo
ZW4KPiAtICAgIE9DQU1MTUtMSUI9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9
Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBPQ0FNTE1LTElCPSRhY19j
dF9PQ0FNTE1LTElCCj4gLSAgZmkKPiAtZWxzZQo+IC0gIE9DQU1MTUtMSUI9IiRhY19jdl9wcm9n
X09DQU1MTUtMSUIiCj4gKwo+ICtpZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgo+ICt0aGVuCj4g
KyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sMi1jb25maWcsIHBsZWFzZSBp
bnN0YWxsIHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQo+ICBmaQo+IAo+ICtmaQo+ICtpZiB0ZXN0
ICJ4JG9jYW1sdG9vbHMiID0gInh5IjsgdGhlbiA6Cj4gCj4gLSAgIyBjaGVja2luZyBmb3Igb2Nh
bWxkb2MKPiArICAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjCj4gICAgaWYgdGVzdCAtbiAiJGFj
X3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHth
Y190b29sX3ByZWZpeH1vY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQy
Cj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2Fj
X2N2X3Byb2dfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfT0NBTUxDK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgo+IC0gIGFj
X2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gKyAgaWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX09D
QU1MQz0iJE9DQU1MQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gIGVsc2UK
PiAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGlu
ICRQQVRICj4gQEAgLTYwNjcsNyArMzc3OCw3IEBAIGRvCj4gICAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2Mi
Cj4gKyAgICBhY19jdl9wcm9nX09DQU1MQz0iJHthY190b29sX3ByZWZpeH1vY2FtbGMiCj4gICAg
ICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02MDc3
LDEwICszNzg4LDEwIEBAIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAgZmkKPiAtT0NBTUxE
T0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKPiAtaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgo+
IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NB
TUxET0MiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KPiArT0NBTUxDPSRhY19j
dl9wcm9nX09DQU1MQwo+ICtpZiB0ZXN0IC1uICIkT0NBTUxDIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+JjUKPiAr
JGFzX2VjaG8gIiRPQ0FNTEMiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8gIm5vIiA+
JjY7IH0KPiBAQCAtNjA4OCwxNyArMzc5OSwxNyBAQCBmaQo+IAo+IAo+ICBmaQo+IC1pZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERPQyI7IHRoZW4KPiAtICBhY19jdF9PQ0FNTERPQz0kT0NB
TUxET0MKPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9jYW1sZG9jOyBh
Y193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQyI7IHRoZW4KPiArICBh
Y19jdF9PQ0FNTEM9JE9DQU1MQwo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2Nh
bWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15
IG9jYW1sYzsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgo+IC0g
IGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9IiRhY19jdF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQyI7IHRo
ZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0iJGFjX2N0X09DQU1MQyIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gIGVsc2UKPiAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gQEAgLTYxMDcsNyArMzgx
OCw3IEBAIGRvCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxET0M9Im9jYW1sZG9jIgo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9Im9j
YW1sYyIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZp
Cj4gQEAgLTYxMTcsMTcgKzM4MjgsMTcgQEAgSUZTPSRhc19zYXZlX0lGUwo+IAo+ICBmaQo+ICBm
aQo+IC1hY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQwo+IC1pZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERPQyIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQo+ICthY19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCj4gKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEMi
ID4mNQo+ICskYXNfZWNobyAiJGFjX2N0X09DQU1MQyIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAk
YXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxE
T0MiID0geDsgdGhlbgo+IC0gICAgT0NBTUxET0M9Im5vIgo+ICsgIGlmIHRlc3QgIngkYWNfY3Rf
T0NBTUxDIiA9IHg7IHRoZW4KPiArICAgIE9DQU1MQz0ibm8iCj4gICAgZWxzZQo+ICAgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgo+ICB5ZXM6KQo+IEBAIC02MTM1
LDI0ICszODQ2LDQxIEBAIHllczopCj4gICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiAgYWNf
dG9vbF93YXJuZWQ9eWVzIDs7Cj4gIGVzYWMKPiAtICAgIE9DQU1MRE9DPSRhY19jdF9PQ0FNTERP
Qwo+ICsgICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMKPiAgICBmaQo+ICBlbHNlCj4gLSAgT0NBTUxE
T0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgo+ICsgIE9DQU1MQz0iJGFjX2N2X3Byb2dfT0NBTUxD
Igo+ICBmaQo+IAo+IAo+IC0gICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQKPiAtICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxk
OyBhY193b3JkPSQyCj4gKyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgo+ICsgICAg
IE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4q
XCkkfFwxfHAnYAo+ICsgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT04iID4mNQo+ICskYXNfZWNo
byAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjY7IH0KPiArICAgICAjIElmIE9D
QU1MTElCIGlzIHNldCwgdXNlIGl0Cj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0
aGVuCj4gKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rldi9udWxsIHx8ICRP
Q0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRgCj4gKyAgICAgZWxzZQo+ICsgICAgICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ0FNTExJ
QiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQo+ICskYXNfZWNobyAiT0NBTUxM
SUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7IH0KPiArICAgICBmaQo+ICsg
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2Ft
bCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjUKPiArJGFzX2VjaG8gIk9DYW1sIGxpYnJh
cnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQo+ICsKPiArCj4gKwo+ICsKPiArICAgICAjIGNo
ZWNraW5nIGZvciBvY2FtbG9wdAo+ICsgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0
ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxE
IjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRo
ZW4KPiArICBhY19jdl9wcm9nX09DQU1MT1BUPSIkT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0Lgo+ICBlbHNlCj4gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+IEBAIC02MTYxLDcgKzM4ODksNyBAQCBk
bwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX09DQU1MQlVJTEQ9
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZCIKPiArICAgIGFjX2N2X3Byb2dfT0NBTUxPUFQ9
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
PiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02MTcxLDEwICszODk5LDEwIEBAIElGUz0kYXNf
c2F2ZV9JRlMKPiAKPiAgZmkKPiAgZmkKPiAtT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19PQ0FNTEJV
SUxECj4gLWlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIgPiY1Cj4gLSRh
c19lY2hvICIkT0NBTUxCVUlMRCIgPiY2OyB9Cj4gK09DQU1MT1BUPSRhY19jdl9wcm9nX09DQU1M
T1BUCj4gK2lmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BUIiA+JjUKPiArJGFzX2Vj
aG8gIiRPQ0FNTE9QVCIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsg
fQo+IEBAIC02MTgyLDE3ICszOTEwLDE3IEBAIGZpCj4gCj4gCj4gIGZpCj4gLWlmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiOyB0aGVuCj4gLSAgYWNfY3RfT0NBTUxCVUlMRD0kT0NB
TUxCVUlMRAo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBvY2FtbGJ1
aWxkOyBhY193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BUIjsgdGhl
bgo+ICsgIGFjX2N0X09DQU1MT1BUPSRPQ0FNTE9QVAo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgo+ICtzZXQgZHVtbXkgb2NhbWxvcHQ7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICAkYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHth
Y19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0
ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxCVUlMRCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9IiRhY19j
dF9PQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiArICBpZiB0
ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN
TE9QVD0iJGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
PiAgZWxzZQo+ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gIGZvciBh
c19kaXIgaW4gJFBBVEgKPiBAQCAtNjIwMSw3ICszOTI5LDcgQEAgZG8KPiAgICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj
dXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxk
Igo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0ib2NhbWxvcHQiCj4gICAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02MjExLDE3ICsz
OTM5LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAgZmkKPiAtYWNfY3RfT0NBTUxC
VUlMRD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxECj4gLWlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTEJVSUxEIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3Rf
T0NBTUxCVUlMRCIgPiY2OyB9Cj4gK2FjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09D
QU1MT1BUCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KPiArICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BU
IiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+
ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUxCVUlMRCIgPSB4OyB0aGVuCj4gLSAgICBPQ0FNTEJVSUxEPSJubyIKPiArICBpZiB0ZXN0ICJ4
JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KPiArICAgIE9DQU1MT1BUPSJubyIKPiAgICBlbHNl
Cj4gICAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4gIHllczop
Cj4gQEAgLTYyMjksNDQgKzM5NTcsODkgQEAgeWVzOikKPiAgJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjI7fQo+ICBhY190b29sX3dhcm5lZD15ZXMgOzsKPiAgZXNhYwo+IC0gICAgT0NBTUxCVUlMRD0k
YWNfY3RfT0NBTUxCVUlMRAo+ICsgICAgT0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCj4gICAgZmkK
PiAgZWxzZQo+IC0gIE9DQU1MQlVJTEQ9IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiCj4gKyAgT0NB
TUxPUFQ9IiRhY19jdl9wcm9nX09DQU1MT1BUIgo+ICBmaQo+IAo+ICsgICAgIE9DQU1MQkVTVD1i
eXRlCj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KPiArICAgICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogQ2Fubm90IGZp
bmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuIiA+JjUKPiArJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0
aW9uIG9ubHkuIiA+JjI7fQo+ICsgICAgIGVsc2UKPiArICAgICAgIFRNUFZFUlNJT049YCRPQ0FN
TE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKPiArICAg
ICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCj4gKyAg
ICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQo+
ICskYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2Fy
ZGVkLiIgPiY2OyB9Cj4gKyAgICAgICAgICAgT0NBTUxPUFQ9bm8KPiArICAgICAgIGVsc2UKPiAr
ICAgICAgICAgICBPQ0FNTEJFU1Q9b3B0Cj4gKyAgICAgICBmaQo+ICsgICAgIGZpCj4gCj4gLSAg
ICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLSAgICAgICAgaWYgdGVz
dCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgo+IAo+IC0gICAgICAgICAg
ICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5k
IE9jYW1sIiAiJExJTkVOTyIgNQo+IC1maQo+IC0gICAgICAgIG9jYW1sdG9vbHM9Im4iCj4gKyAg
ICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAo+ICsgICAgIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIK
PiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiArZWxzZQo+ICsgIGlmIHRl
c3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9
IiRPQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNl
Cj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBp
biAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgo+ICsgICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxjLm9wdCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsg
IGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiArZmkK
PiArT0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVAo+ICtpZiB0ZXN0IC1uICIk
T0NBTUxDRE9UT1BUIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKPiArJGFzX2VjaG8gIiRPQ0FNTENE
T1RPUFQiID4mNjsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArZmkK
PiArCj4gCj4gIGZpCj4gLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmFzaCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBiYXNoOyBhY193
b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCI7IHRoZW4KPiAr
ICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RPVE9QVAo+ICsgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gK3NldCBkdW1teSBvY2FtbGMub3B0OyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
PiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRl
c3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHth
Y19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJEJBU0ggaW4KPiAtICBb
XFwvXSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAg
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRh
Y19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RP
UFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9y
IGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9CQVNIPSIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5v
cHQiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+
IEBAIC02Mjc0LDU2ICs0MDQ3LDYzIEBAIGRvbmUKPiAgICBkb25lCj4gIElGUz0kYXNfc2F2ZV9J
RlMKPiAKPiAtICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9
Im5vIgo+IC0gIDs7Cj4gLWVzYWMKPiAgZmkKPiAtQkFTSD0kYWNfY3ZfcGF0aF9CQVNICj4gLWlm
IHRlc3QgLW4gIiRCQVNIIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkQkFTSCIgPiY1Cj4gLSRhc19lY2hvICIkQkFTSCIgPiY2OyB9
Cj4gK2ZpCj4gK2FjX2N0X09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RP
UFQKPiAraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KPiArICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQ0RP
VE9QVCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjY7IH0KPiAgZWxz
ZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC1pZiB0ZXN0IHgi
JHtCQVNIfSIgPT0geCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2giICIkTElORU5PIiA1Cj4gKyAgaWYgdGVz
dCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgo+ICsgICAgT0NBTUxDRE9UT1BUPSJu
byIKPiArICBlbHNlCj4gKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVk
IGluCj4gK3llczopCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0
IiA+JjUKPiArJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+ICthY190b29sX3dhcm5lZD15ZXMg
OzsKPiArZXNhYwo+ICsgICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKPiArICBm
aQo+ICtlbHNlCj4gKyAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCj4g
IGZpCj4gLWlmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhlbiA6Cj4gLQo+IC0gICAg
aWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyI7IHRoZW4gOgo+IAo+IC0gICAgICAgIFBZ
VEhPTlBBVEg9JFBZVEhPTgo+IC0gICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhg
Cj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MQ0RPVE9QVCIgIT0gIm5vIjsgdGhlbgo+ICsgICAgICAg
VE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpc
KC4qXCkkfFwxfHAnIGAKPiArICAgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1M
VkVSU0lPTiIgOyB0aGVuCj4gKyAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1s
Yy5vcHQgZGlzY2FyZGVkLiIgPiY1Cj4gKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsgfQo+ICsgICAgICAgZWxzZQo+ICsg
ICAgICAgICAgIE9DQU1MQz0kT0NBTUxDRE9UT1BUCj4gKyAgICAgICBmaQo+ICsgICAgIGZpCj4g
Cj4gLWVsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgo+IC0gIFBZVEhPTj0icHl0aG9uIgo+
IC1lbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3Qg
YW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKPiAtZmkKPiAtICAgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJFBZVEhPTiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCj4gKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0Cj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsg
dGhlbgo+ICsgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+ICsgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgJHth
Y190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICAk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBjYXNlICRQWVRIT05QQVRIIGluCj4g
LSAgW1xcL10qIHwgPzpbXFwvXSopCj4gLSAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9O
UEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAg
OzsKPiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAr
ICBpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19PQ0FN
TE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4g
IGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3NhdmVfSUZTCj4gICAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3BhdGhfUFlUSE9OUEFUSD0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Igo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Cj4gICAgICBicmVhayAyCj4gICAgZmkKPiBAQCAtNjMzMSw2MiArNDExMSwzOSBAQCBkb25lCj4g
ICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhf
UFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKPiAtICA7Owo+IC1lc2Fj
Cj4gIGZpCj4gLVBZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAo+IC1pZiB0ZXN0IC1u
ICIkUFlUSE9OUEFUSCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJFBZVEhPTlBBVEgiID4mNQo+IC0kYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQo+ICtmaQo+ICtPQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERP
VE9QVAo+ICtpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVERPVE9QVCIg
PiY1Cj4gKyRhc19lY2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAg
JGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAKPiAtaWYgdGVzdCB4IiR7UFlUSE9OUEFU
SH0iID09IHgibm8iCj4gLXRoZW4KPiAtICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCAkUFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQo+IC1maQo+IC0g
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
cHl0aG9uIHZlcnNpb24gPj0gMi4zICIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBw
eXRob24gdmVyc2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9Cj4gLWAkUFlUSE9OIC1jICdpbXBvcnQg
c3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKPiAtaWYg
dGVzdCAiJD8iICE9ICIwIgo+IC10aGVuCj4gLSAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAt
ViAyPiYxYAo+IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtICAgIGFzX2ZuX2Vycm9y
ICQ/ICIkcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9u
IGlzIDIuMyIgIiRMSU5FTk8iIDUKPiAtZWxzZQo+IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gLSRhc19lY2hvICJ5ZXMiID4m
NjsgfQo+ICBmaQo+IC0KPiAtYWNfcHJldmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCj4gLWFjX3By
ZXZpb3VzX2xkZmxhZ3M9JExERkxBR1MKPiAtYWNfcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLWMg
J2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gLSAgICBwcmludCBkaXN0dXRpbHMuc3lz
Y29uZmlnLmdldF9jb25maWdfdmFyKCJWRVJTSU9OIiknYAo+IC0jIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRQWVRIT04tY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiAtc2V0IGR1bW15ICRQWVRIT04tY29uZmlnOyBhY193b3JkPSQyCj4gK2lmIHRl
c3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIjsgdGhlbgo+ICsgIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAib2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
PiArc2V0IGR1bW15IG9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfcHljb25maWcrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2Fj
X2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBjYXNlICRweWNvbmZpZyBpbgo+
IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+IC0gIGFjX2N2X3BhdGhfcHljb25maWc9IiRweWNvbmZp
ZyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAgOzsK
PiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3Nh
dmVfSUZTCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3BhdGhfcHljb25m
aWc9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MT1BURE9UT1BUPSJvY2FtbG9wdC5vcHQiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02Mzk0LDEyNyArNDE1MSw2OCBAQCBkb25l
Cj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfcHljb25maWciICYmIGFjX2N2X3BhdGhfcHljb25maWc9Im5vIgo+IC0gIDs7Cj4gLWVzYWMK
PiAgZmkKPiAtcHljb25maWc9JGFjX2N2X3BhdGhfcHljb25maWcKPiAtaWYgdGVzdCAtbiAiJHB5
Y29uZmlnIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkcHljb25maWciID4mNQo+IC0kYXNfZWNobyAiJHB5Y29uZmlnIiA+JjY7IH0K
PiArZmkKPiArYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE
T1RPUFQKPiAraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgo+ICsgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB
TUxPUFRET1RPUFQiID4mNQo+ICskYXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7
IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC1p
ZiB0ZXN0IHgiJHB5Y29uZmlnIiA9PSB4Im5vIjsgdGhlbiA6Cj4gLQo+IC0gICAgICAgIENQUEZM
QUdTPSIkQ0ZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+
IC0gICAgICAgIHByaW50ICItSSIgKyBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFy
KCJJTkNMVURFUFkiKSdgIgo+IC0gICAgQ1BQRkxBR1M9IiRDUFBGTEFHUyBgJFBZVEhPTiAtYyAn
aW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKPiAtICAgICAgICBwcmludCBkaXN0dXRpbHMu
c3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJDRkxBR1MiKSdgIgo+IC0gICAgTERGTEFHUz0iJExE
RkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gLSAgICAg
ICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElCUyIpJ2AiCj4g
LSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNj
b25maWc7IFwKPiAtICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdf
dmFyKCJTWVNMSUJTIiknYCIKPiAtICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdp
bXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+IC0gICAgICAgIHByaW50ICItTCIgKyBkaXN0
dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBsYXRfc3BlY2lmaWM9MSxcCj4gLSAgICAg
ICAgc3RhbmRhcmRfbGliPTEpICsgIi9jb25maWciJ2AiCj4gLSAgICBMREZMQUdTPSIkTERGTEFH
UyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKPiAtICAgICAgICBw
cmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJMSU5LRk9SU0hBUkVEIikn
YCIKPiAtICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxz
LnN5c2NvbmZpZzsgXAo+IC0gICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2Nv
bmZpZ192YXIoIkxERkxBR1MiKSdgIgo+IC0KPiAtZWxzZQo+IC0KPiAtICAgICAgICBDUFBGTEFH
Uz0iJENGTEFHUyBgJFBZVEhPTi1jb25maWcgLS1jZmxhZ3NgIgo+IC0gICAgTERGTEFHUz0iJExE
RkxBR1MgYCRQWVRIT04tY29uZmlnIC0tbGRmbGFnc2AiCj4gLQo+IC1maQo+IC0KPiAtYWNfZm5f
Y19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVy
X1B5dGhvbl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVh
ZGVyX1B5dGhvbl9oIiA9IHgiInllczsgdGhlbiA6Cj4gLQo+ICsgIGlmIHRlc3QgIngkYWNfY3Rf
T0NBTUxPUFRET1RPUFQiID0geDsgdGhlbgo+ICsgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgo+ICsg
IGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAr
eWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+
ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtl
c2FjCj4gKyAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NBTUxPUFRET1RPUFQKPiArICBmaQo+
ICBlbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIFB5dGhvbiBkZXZlbG9w
bWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQo+ICsgIE9DQU1MT1BURE9UT1BUPSIkYWNfY3ZfcHJv
Z19PQ0FNTE9QVERPVE9QVCIKPiAgZmkKPiAKPiArICAgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVERP
VE9QVCIgIT0gIm5vIjsgdGhlbgo+ICsgICAgICAgICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9U
T1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAo+ICsgICAg
ICAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KPiAr
ICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiB2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQu
IiA+JjUKPiArJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQu
b3B0IGRpc2NhcmRlZC4iID4mNjsgfQo+ICsgICAgICAgICAgZWxzZQo+ICsgICAgICAgICAgICAg
T0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCj4gKyAgICAgICAgICBmaQo+ICsgICAgICAgIGZpCj4g
KyAgICAgZmkKPiAKPiAtYXNfYWNfTGliPWAkYXNfZWNobyAiYWNfY3ZfbGliX3B5dGhvbiRhY19w
eXRob25fdmVyc2lvbicnX1B5QXJnX1BhcnNlVHVwbGUiIHwgJGFzX3RyX3NoYAo+IC17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBQeUFyZ19QYXJz
ZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiA+JjUKPiAtJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNp
b24uLi4gIiA+JjY7IH0KPiAtaWYgZXZhbCAidGVzdCBcIlwkeyRhc19hY19MaWIrc2V0fVwiIiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWxweXRob24kYWNfcHl0aG9u
X3ZlcnNpb24gICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4gLS8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIg
UHlBcmdfUGFyc2VUdXBsZSAoKTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1yZXR1cm4gUHlB
cmdfUGFyc2VUdXBsZSAoKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4g
LWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBldmFsICIkYXNfYWNf
TGliPXllcyIKPiAtZWxzZQo+IC0gIGV2YWwgIiRhc19hY19MaWI9bm8iCj4gLWZpCj4gLXJtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3Qk
YWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElC
Uwo+IC1maQo+IC1ldmFsIGFjX3Jlcz1cJCRhc19hY19MaWIKPiAtICAgICAgICAgICAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1
Cj4gLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KPiAtaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19h
Y19MaWIiXCIgPSB4InllcyI7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
PiAtI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfTElCcHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiB8
ICRhc190cl9jcHBgIDEKPiAtX0FDRU9GCj4gLQo+IC0gIExJQlM9Ii1scHl0aG9uJGFjX3B5dGhv
bl92ZXJzaW9uICRMSUJTIgo+IAo+IC1lbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGEgc3VpdGFibGUgcHl0aG9uIGRldmVsb3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1
Cj4gLWZpCj4gKyAgZmkKPiAKPiAtQ1BQRkxBR1M9JGFjX3ByZXZpb3VzX2NwcGZsYWdzCj4gLUxE
TEZBR1M9JGFjX3ByZXZpb3VzX2xkZmxhZ3MKPiAKPiAKPiAtZmkKPiAtIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSB4Z2V0dGV4dDsgYWNfd29yZD0kMgo+ICsgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sIHRvcGxldmVsCj4gKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft
bCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cHJvZ19PQ0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJFhHRVRURVhUIGluCj4gLSAgW1xcL10qIHwgPzpbXFwv
XSopCj4gLSAgYWNfY3ZfcGF0aF9YR0VUVEVYVD0iJFhHRVRURVhUIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTCI7
IHRoZW4KPiArICBhY19jdl9wcm9nX09DQU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMK
PiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9YR0VUVEVYVD0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJy
ZWFrIDIKPiAgICBmaQo+IEBAIC02NTIyLDQ0ICs0MjIwLDM5IEBAIGRvbmUKPiAgICBkb25lCj4g
IElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAtICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIg
JiYgYWNfY3ZfcGF0aF9YR0VUVEVYVD0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1YR0VU
VEVYVD0kYWNfY3ZfcGF0aF9YR0VUVEVYVAo+IC1pZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVu
Cj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRY
R0VUVEVYVCIgPiY1Cj4gLSRhc19lY2hvICIkWEdFVFRFWFQiID4mNjsgfQo+ICtmaQo+ICtPQ0FN
TD0kYWNfY3ZfcHJvZ19PQ0FNTAo+ICtpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCj4gKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTCIgPiY1
Cj4gKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8gIm5v
IiA+JjY7IH0KPiAgZmkKPiAKPiAKPiAtaWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgo+
IC10aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeGdldHRleHQsIHBs
ZWFzZSBpbnN0YWxsIHhnZXR0ZXh0IiAiJExJTkVOTyIgNQo+ICBmaQo+IC0jIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgo+IC1zZXQgZHVtbXkgYXM4NjsgYWNfd29yZD0kMgo+ICtpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTCI7IHRoZW4KPiArICBhY19jdF9PQ0FNTD0kT0NBTUwKPiArICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiArc2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAg
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3Qg
IiR7YWNfY3ZfcGF0aF9BUzg2K3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19j
dl9wcm9nX2FjX2N0X09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgY2FzZSAkQVM4NiBpbgo+IC0gIFtcXC9dKiB8ID86
W1xcL10qKQo+IC0gIGFjX2N2X3BhdGhfQVM4Nj0iJEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgo+IC0gIDs7Cj4gLSAgKikKPiAtICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1M
IjsgdGhlbgo+ICsgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9IiRhY19jdF9PQ0FNTCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gK2Vsc2UKPiArYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gIGRvCj4gICAgSUZT
PSRhc19zYXZlX0lGUwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wYXRo
X0FTODY9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MPSJvY2FtbCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJl
YWsgMgo+ICAgIGZpCj4gQEAgLTY1NjcsNDQgKzQyNjAsNTMgQEAgZG9uZQo+ICAgIGRvbmUKPiAg
SUZTPSRhc19zYXZlX0lGUwo+IAo+IC0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0FTODYiICYmIGFj
X2N2X3BhdGhfQVM4Nj0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1BUzg2PSRhY19jdl9w
YXRoX0FTODYKPiAtaWYgdGVzdCAtbiAiJEFTODYiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRBUzg2IiA+JjUKPiAtJGFzX2VjaG8g
IiRBUzg2IiA+JjY7IH0KPiArZmkKPiArYWNfY3RfT0NBTUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUwKPiAraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUwiID4mNQo+ICsk
YXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJu
byIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC1pZiB0ZXN0IHgiJHtBUzg2fSIgPT0geCJubyIKPiAt
dGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGFzODYsIHBsZWFzZSBp
bnN0YWxsIGFzODYiICIkTElORU5PIiA1Cj4gKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTCIgPSB4
OyB0aGVuCj4gKyAgICBPQ0FNTD0ibm8iCj4gKyAgZWxzZQo+ICsgICAgY2FzZSAkY3Jvc3NfY29t
cGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgo+ICt5ZXM6KQo+ICt7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Cj4gKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30K
PiArYWNfdG9vbF93YXJuZWQ9eWVzIDs7Cj4gK2VzYWMKPiArICAgIE9DQU1MPSRhY19jdF9PQ0FN
TAo+ICsgIGZpCj4gK2Vsc2UKPiArICBPQ0FNTD0iJGFjX2N2X3Byb2dfT0NBTUwiCj4gIGZpCj4g
LSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAibGQ4NiIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBsZDg2OyBhY193b3JkPSQyCj4gKwo+ICsK
PiArICAjIGNoZWNraW5nIGZvciBvY2FtbGRlcAo+ICsgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+
ICtzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGRlcDsgYWNfd29yZD0kMgo+ICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfTEQ4NitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJExEODYgaW4KPiAtICBbXFwv
XSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX0xEODY9IiRMRDg2IiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FN
TERFUCI7IHRoZW4KPiArICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0k
YXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9M
RDg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19PQ0FN
TERFUD0iJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTY2MTIsNDQgKzQzMTQsMzkgQEAgZG9u
ZQo+ICAgIGRvbmUKPiAgSUZTPSRhc19zYXZlX0lGUwo+IAo+IC0gIHRlc3QgLXogIiRhY19jdl9w
YXRoX0xEODYiICYmIGFjX2N2X3BhdGhfTEQ4Nj0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+
IC1MRDg2PSRhY19jdl9wYXRoX0xEODYKPiAtaWYgdGVzdCAtbiAiJExEODYiOyB0aGVuCj4gLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRMRDg2IiA+
JjUKPiAtJGFzX2VjaG8gIiRMRDg2IiA+JjY7IH0KPiArZmkKPiArT0NBTUxERVA9JGFjX2N2X3By
b2dfT0NBTUxERVAKPiAraWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxERVAiID4mNQo+
ICskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJu
byIgPiY2OyB9Cj4gIGZpCj4gCj4gCj4gLWlmIHRlc3QgeCIke0xEODZ9IiA9PSB4Im5vIgo+IC10
aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGlu
c3RhbGwgbGQ4NiIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICJiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQg
ZHVtbXkgYmNjOyBhY193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MREVQ
IjsgdGhlbgo+ICsgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAo+ICsgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgo+ICtzZXQgZHVtbXkgb2NhbWxkZXA7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+
ICAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVz
dCAiJHthY19jdl9wYXRoX0JDQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJEJDQyBpbgo+IC0gIFtcXC9dKiB8
ID86W1xcL10qKQo+IC0gIGFjX2N2X3BhdGhfQkNDPSIkQkNDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN
TERFUCI7IHRoZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxE
RVAiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBk
bwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAg
YWNfY3ZfcGF0aF9CQ0M9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19j
dl9wcm9nX2FjX2N0X09DQU1MREVQPSJvY2FtbGRlcCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTY2NTcsMjgzICs0MzU0LDI0MSBAQCBk
b25lCj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2
X3BhdGhfQkNDIiAmJiBhY19jdl9wYXRoX0JDQz0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+
IC1CQ0M9JGFjX2N2X3BhdGhfQkNDCj4gLWlmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCj4gLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCQ0MiID4mNQo+
IC0kYXNfZWNobyAiJEJDQyIgPiY2OyB9Cj4gK2ZpCj4gK2FjX2N0X09DQU1MREVQPSRhY19jdl9w
cm9nX2FjX2N0X09DQU1MREVQCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4K
PiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N0X09DQU1MREVQIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9Cj4g
IGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0KPiAtaWYgdGVz
dCB4IiR7QkNDfSIgPT0geCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGJjYywgcGxlYXNlIGluc3RhbGwgYmNjIiAiJExJTkVOTyIgNQo+ICsgIGlmIHRl
c3QgIngkYWNfY3RfT0NBTUxERVAiID0geDsgdGhlbgo+ICsgICAgT0NBTUxERVA9Im5vIgo+ICsg
IGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAr
eWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+
ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtl
c2FjCj4gKyAgICBPQ0FNTERFUD0kYWNfY3RfT0NBTUxERVAKPiArICBmaQo+ICtlbHNlCj4gKyAg
T0NBTUxERVA9IiRhY19jdl9wcm9nX09DQU1MREVQIgo+ICBmaQo+IC0jIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImlhc2wiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgo+IC1zZXQgZHVtbXkgaWFzbDsgYWNfd29yZD0kMgo+ICsKPiArCj4gKyAgIyBjaGVja2luZyBm
b3Igb2NhbWxta3RvcAo+ICsgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAr
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3Rv
cCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICAk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9wYXRoX0lBU0wrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJElBU0wgaW4KPiAtICBbXFwvXSogfCA/Oltc
XC9dKikKPiAtICBhY19jdl9wYXRoX0lBU0w9IiRJQVNMIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsg
dGhlbgo+ICsgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJE9DQU1MTUtUT1AiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNf
c2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9JQVNM
PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19PQ0FNTE1L
VE9QPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCj4gICAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFz
X3NhdmVfSUZTCj4gLQo+IC0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0lBU0wiICYmIGFjX2N2X3Bh
dGhfSUFTTD0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+IC1maQo+IC1JQVNMPSRhY19jdl9wYXRoX0lB
U0wKPiAtaWYgdGVzdCAtbiAiJElBU0wiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJQVNMIiA+JjUKPiAtJGFzX2VjaG8gIiRJQVNM
IiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4gLQo+
IC0KPiAtaWYgdGVzdCB4IiR7SUFTTH0iID09IHgibm8iCj4gLXRoZW4KPiAtICAgIGFzX2ZuX2Vy
cm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNsLCBwbGVhc2UgaW5zdGFsbCBpYXNsIiAiJExJTkVO
TyIgNQo+IC1maQo+IC0KPiAtYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIg
InV1aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiA9IHgiInllczsg
dGhlbiA6Cj4gLQo+IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9saWJfdXVpZF91dWlkX2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUwo+IC1MSUJTPSItbHV1aWQgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4gLS8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+
IC0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKPiAtICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAt
I2VuZGlmCj4gLWNoYXIgdXVpZF9jbGVhciAoKTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1y
ZXR1cm4gdXVpZF9jbGVhciAoKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9G
Cj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9saWJf
dXVpZF91dWlkX2NsZWFyPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVh
cj1ubwo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKPiAtICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gLUxJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjUKPiAt
JGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KPiAtaWYgdGVzdCAi
eCRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgbGlidXVp
ZD0ieSIKPiAtZmkKPiAtCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiArSUZTPSRhc19zYXZl
X0lGUwo+IAo+ICBmaQo+IC0KPiAtCj4gLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRM
SU5FTk8iICJ1dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+
IC0gIGxpYnV1aWQ9InkiCj4gIGZpCj4gLQo+IC0KPiAtaWYgdGVzdCAiJGxpYnV1aWQiICE9ICJ5
IjsgdGhlbiA6Cj4gLQo+IC0gICAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGEgdmFsaWQg
dXVpZCBsaWJyYXJ5IiAiJExJTkVOTyIgNQo+IC0KPiArT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QCj4gK2lmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1
Cj4gKyRhc19lY2hvICIkT0NBTUxNS1RPUCIgPiY2OyB9Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNo
byAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+IC1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVs
ICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJfY3Vyc2VzX2giICIkYWNfaW5jbHVk
ZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfY3Vyc2VzX2giID0geCIieWVz
OyB0aGVuIDoKPiAtCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcy4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2Fj
X2N2X2xpYl9jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtmaQo+ICtpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgo+ICsgIGFjX2N0X09DQU1MTUtUT1A9
JE9DQU1MTUtUT1AKPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWt0b3Ai
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgb2Nh
bWxta3RvcDsgYWNfd29yZD0kMgo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKPiAgZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElCUz0i
LWxjdXJzZXMgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4gLS8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIg
Y2xlYXIgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0dXJuIGNsZWFyICgpOwo+IC0g
IDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2xpYl9jdXJzZXNfY2xlYXI9eWVzCj4gKyAgaWYg
dGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE1LVE9QPSIkYWNfY3RfT0NBTUxNS1RPUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gIGVsc2UKPiAtICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPW5vCj4gK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtk
bwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9wIgo+ICsgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiAr
SUZTPSRhc19zYXZlX0lGUwo+ICsKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2N1cnNlc19j
bGVhciIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPiY2OyB9Cj4g
LWlmIHRlc3QgIngkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0g
IGN1cnNlcz0ieSIKPiArYWNfY3RfT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1L
VE9QCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxNS1RP
UCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxNS1RPUCIgPiY2OyB9Cj4gIGVsc2UKPiAt
ICBjdXJzZXM9Im4iCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtCj4g
KyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KPiArICAgIE9DQU1MTUtU
T1A9Im5vIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93
YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29s
cyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xfd2FybmVk
PXllcyA7Owo+ICtlc2FjCj4gKyAgICBPQ0FNTE1LVE9QPSRhY19jdF9PQ0FNTE1LVE9QCj4gKyAg
ZmkKPiAgZWxzZQo+IC0gIGN1cnNlcz0ibiIKPiArICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QIgo+ICBmaQo+IAo+IAo+IC1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRl
c19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giID0geCIieWVz
OyB0aGVuIDoKPiAtCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7
YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICMgY2hlY2tp
bmcgZm9yIG9jYW1sbWtsaWIKPiArICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVu
Cj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
bWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVt
bXkgJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliOyBhY193b3JkPSQyCj4gK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
PiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUwo+IC1MSUJTPSItbG5jdXJzZXMgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4g
LS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9y
Lgo+IC0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUg
b2YgYSBHQ0MKPiAtICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIK
PiAtI2VuZGlmCj4gLWNoYXIgY2xlYXIgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0
dXJuIGNsZWFyICgpOwo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2xpYl9uY3Vyc2Vz
X2NsZWFyPXllcwo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgo+ICsgIGFjX2N2
X3Byb2dfT0NBTUxNS0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0Lgo+ICBlbHNlCj4gLSAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9bm8KPiArYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICtmb3IgYXNfZGlyIGluICRQQVRICj4g
K2RvCj4gKyAgSUZTPSRhc19zYXZlX0lGUwo+ICsgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCj4gKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KPiArICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gKyAg
ICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKPiAr
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUK
PiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiArCj4gIGZpCj4gLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0
IGNvbmZ0ZXN0LiRhY19leHQKPiAtTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICBmaQo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9saWJfbmN1cnNlc19j
bGVhciIgPiY2OyB9Cj4gLWlmIHRlc3QgIngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIi
eWVzOyB0aGVuIDoKPiAtICBuY3Vyc2VzPSJ5Igo+ICtPQ0FNTE1LTElCPSRhY19jdl9wcm9nX09D
QU1MTUtMSUIKPiAraWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LTElCIiA+JjUK
PiArJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KPiAgZWxzZQo+IC0gIG5jdXJzZXM9Im4i
Cj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAKPiAtZWxzZQo+IC0gIG5j
dXJzZXM9Im4iCj4gIGZpCj4gLQo+IC0KPiAtaWYgdGVzdCAiJGN1cnNlcyIgPSAibiIgJiYgdGVz
dCAiJG5jdXJzZXMiID0gIm4iOyB0aGVuIDoKPiAtCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5h
YmxlIHRvIGZpbmQgYSBzdWl0YWJsZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5FTk8iIDUKPiAraWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRoZW4KPiArICBhY19jdF9PQ0FNTE1L
TElCPSRPQ0FNTE1LTElCCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG1r
bGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15
IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj
X2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRo
ZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9PQ0FNTE1LTElCIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiAr
ICBJRlM9JGFzX3NhdmVfSUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAr
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+
ICsgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKPiArICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0k
YXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAtIyBQcmVmZXIgbmN1cnNlcyBvdmVyIGN1cnNlcyBpZiBi
b3RoIGFyZSBwcmVzZW50Cj4gLWlmIHRlc3QgIiRuY3Vyc2VzIiA9ICJ5IjsgdGhlbiA6Cj4gLQo+
IC0gICAgQ1VSU0VTX0xJQlM9Ii1sbmN1cnNlcyIKPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIElO
Q0xVREVfQ1VSU0VTX0ggPG5jdXJzZXMuaD4iID4+Y29uZmRlZnMuaAo+IC0KPiAtCj4gK2ZpCj4g
K2FjX2N0X09DQU1MTUtMSUI9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQgo+ICtpZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQo+ICskYXNf
ZWNobyAiJGFjX2N0X09DQU1MTUtMSUIiID4mNjsgfQo+ICBlbHNlCj4gLQo+IC0gICAgQ1VSU0VT
X0xJQlM9Ii1sY3Vyc2VzIgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNf
SCA8Y3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKPiAtCj4gLQo+ICsgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19lY2hvICJubyIg
PiY2OyB9Cj4gIGZpCj4gCj4gKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LTElCIiA9IHg7IHRo
ZW4KPiArICAgIE9DQU1MTUtMSUI9Im5vIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9
Cj4gK2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtlc2FjCj4gKyAgICBPQ0FNTE1LTElCPSRhY19j
dF9PQ0FNTE1LTElCCj4gKyAgZmkKPiArZWxzZQo+ICsgIE9DQU1MTUtMSUI9IiRhY19jdl9wcm9n
X09DQU1MTUtMSUIiCj4gK2ZpCj4gCj4gCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtaWYgdGVzdCAi
eCRhY19jdl9lbnZfUEtHX0NPTkZJR19zZXQiICE9ICJ4c2V0IjsgdGhlbgo+IC0gICAgICAgaWYg
dGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAiJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9cGtnLWNv
bmZpZzsgYWNfd29yZD0kMgo+ICsgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCj4gKyAgaWYgdGVz
dCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBh
Y193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QS0dfQ09ORklHK3NldH0i
ID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MRE9DK3NldH0iID0g
c2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAg
Y2FzZSAkUEtHX0NPTkZJRyBpbgo+IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+IC0gIGFjX2N2X3Bh
dGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgo+IC0gIDs7Cj4gLSAgKikKPiAtICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCj4gKyAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgo+ICsg
IGFjX2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCj4gK2Vsc2UKPiArYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
Ugo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gIGRvCj4gICAgSUZTPSRhc19zYXZlX0lGUwo+ICAg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wYXRoX1BLR19DT05GSUc9IiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19jdl9wcm9nX09DQU1MRE9DPSIke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sZG9jIgo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gICAg
ICBicmVhayAyCj4gICAgZmkKPiBAQCAtNjk0MSwxMyArNDU5NiwxMiBAQCBkb25lCj4gICAgZG9u
ZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1QS0dfQ09O
RklHPSRhY19jdl9wYXRoX1BLR19DT05GSUcKPiAtaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0
aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRQS0dfQ09ORklHIiA+JjUKPiAtJGFzX2VjaG8gIiRQS0dfQ09ORklHIiA+JjY7IH0KPiArZmkK
PiArT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKPiAraWYgdGVzdCAtbiAiJE9DQU1MRE9D
IjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkT0NBTUxET0MiID4mNQo+ICskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KPiAgZWxz
ZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gQEAgLTY5NTUsMjggKzQ2MDksMjYgQEAg
ZmkKPiAKPiAKPiAgZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRo
ZW4KPiAtICBhY19wdF9QS0dfQ09ORklHPSRQS0dfQ09ORklHCj4gLSAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJwa2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiAtc2V0IGR1bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKPiAraWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfT0NBTUxET0MiOyB0aGVuCj4gKyAgYWNfY3RfT0NBTUxET0M9JE9DQU1M
RE9DCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGRvYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBvY2FtbGRvYzsgYWNf
d29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfYWNfcHRfUEtHX0NPTkZJRytz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERP
QytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAg
ZWxzZQo+IC0gIGNhc2UgJGFjX3B0X1BLR19DT05GSUcgaW4KPiAtICBbXFwvXSogfCA/OltcXC9d
KikKPiAtICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19wdF9QS0dfQ09ORklHIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0g
ICopCj4gLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
RE9DPSIkYWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+
ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFz
X2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj
dXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0ib2Nh
bWxkb2MiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBm
aQo+IEBAIC02OTg0LDIwICs0NjM2LDE5IEBAIGRvbmUKPiAgICBkb25lCj4gIElGUz0kYXNfc2F2
ZV9JRlMKPiAKPiAtICA7Owo+IC1lc2FjCj4gIGZpCj4gLWFjX3B0X1BLR19DT05GSUc9JGFjX2N2
X3BhdGhfYWNfcHRfUEtHX0NPTkZJRwo+IC1pZiB0ZXN0IC1uICIkYWNfcHRfUEtHX0NPTkZJRyI7
IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX3B0X1BLR19DT05GSUciID4mNQo+IC0kYXNfZWNobyAiJGFjX3B0X1BLR19DT05GSUci
ID4mNjsgfQo+ICtmaQo+ICthY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERP
Qwo+ICtpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERPQyIgPiY1
Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFz
X2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05G
SUciID0geDsgdGhlbgo+IC0gICAgUEtHX0NPTkZJRz0iIgo+ICsgIGlmIHRlc3QgIngkYWNfY3Rf
T0NBTUxET0MiID0geDsgdGhlbgo+ICsgICAgT0NBTUxET0M9Im5vIgo+ICAgIGVsc2UKPiAgICAg
IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAgeWVzOikKPiBAQCAt
NzAwNSw2MjQgKzQ2NTYsNzE4IEBAIHllczopCj4gICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30K
PiAgYWNfdG9vbF93YXJuZWQ9eWVzIDs7Cj4gIGVzYWMKPiAtICAgIFBLR19DT05GSUc9JGFjX3B0
X1BLR19DT05GSUcKPiArICAgIE9DQU1MRE9DPSRhY19jdF9PQ0FNTERPQwo+ICAgIGZpCj4gIGVs
c2UKPiAtICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgo+IC1maQo+IC0KPiAt
ZmkKPiAtaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCj4gLSAgICAgICBfcGtnX21pbl92
ZXJzaW9uPTAuOS4wCj4gLSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQgbGVhc3QgdmVyc2lvbiAkX3BrZ19taW5f
dmVyc2lvbiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQgbGVh
c3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbi4uLiAiID4mNjsgfQo+IC0gICAgICAgaWYgJFBL
R19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uOyB0
aGVuCj4gLSAgICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQo+IC0kYXNfZWNobyAieWVzIiA+JjY7IH0KPiAtICAgICAg
IGVsc2UKPiAtICAgICAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtICAgICAg
ICAgICAgICAgUEtHX0NPTkZJRz0iIgo+IC0gICAgICAgZmkKPiAtZmkKPiAtCj4gLXBrZ19mYWls
ZWQ9bm8KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgZ2xpYiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBnbGliLi4uICIgPiY2
OyB9Cj4gLQo+IC1pZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0aGVuCj4gLSAgICBwa2dfY3Zf
Z2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIKPiAtIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUci
OyB0aGVuCj4gLSAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAo+IC0gICAgeyB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkUEtHX0NPTkZJRyAtLWV4aXN0
cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9ID4mNQo+IC0gICgkUEtHX0NPTkZJRyAt
LWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1Cj4gLSAgYWNfc3RhdHVzPSQ/
Cj4gLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0
YXR1cyIgPiY1Cj4gLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgo+IC0gIHBrZ19jdl9n
bGliX0NGTEFHUz1gJFBLR19DT05GSUcgLS1jZmxhZ3MgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAK
PiAtZWxzZQo+IC0gIHBrZ19mYWlsZWQ9eWVzCj4gLWZpCj4gLSBlbHNlCj4gLSAgICBwa2dfZmFp
bGVkPXVudHJpZWQKPiAtZmkKPiAtaWYgdGVzdCAtbiAiJGdsaWJfTElCUyI7IHRoZW4KPiAtICAg
IHBrZ19jdl9nbGliX0xJQlM9IiRnbGliX0xJQlMiCj4gLSBlbGlmIHRlc3QgLW4gIiRQS0dfQ09O
RklHIjsgdGhlbgo+IC0gICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwKPiAtICAgIHsg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1l
eGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGliLTIuMFwiIjsgfSA+JjUKPiAtICAoJFBLR19DT05G
SUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIikgMj4mNQo+IC0gIGFjX3N0YXR1
cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh
Y19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4KPiAtICBwa2df
Y3ZfZ2xpYl9MSUJTPWAkUEtHX0NPTkZJRyAtLWxpYnMgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAK
PiAtZWxzZQo+IC0gIHBrZ19mYWlsZWQ9eWVzCj4gLWZpCj4gLSBlbHNlCj4gLSAgICBwa2dfZmFp
bGVkPXVudHJpZWQKPiAtZmkKPiAtCj4gLQo+IC0KPiAtaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHll
czsgdGhlbgo+IC0gICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtCj4gLWlmICRQS0df
Q09ORklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAwLjIwOyB0aGVuCj4gLSAgICAgICAg
X3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkPXllcwo+IC1lbHNlCj4gLSAgICAgICAgX3BrZ19z
aG9ydF9lcnJvcnNfc3VwcG9ydGVkPW5vCj4gKyAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1M
RE9DIgo+ICBmaQo+IC0gICAgICAgIGlmIHRlc3QgJF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRl
ZCA9IHllczsgdGhlbgo+IC0gICAgICAgICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09O
RklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKPiAtICAg
ICAgICBlbHNlCj4gLSAgICAgICAgICAgICAgIGdsaWJfUEtHX0VSUk9SUz1gJFBLR19DT05GSUcg
LS1wcmludC1lcnJvcnMgImdsaWItMi4wIiAyPiYxYAo+IC0gICAgICAgIGZpCj4gLSAgICAgICAj
IFB1dCB0aGUgbmFzdHkgZXJyb3IgbWVzc2FnZSBpbiBjb25maWcubG9nIHdoZXJlIGl0IGJlbG9u
Z3MKPiAtICAgICAgIGVjaG8gIiRnbGliX1BLR19FUlJPUlMiID4mNQo+IC0KPiAtICAgICAgIGFz
X2ZuX2Vycm9yICQ/ICJQYWNrYWdlIHJlcXVpcmVtZW50cyAoZ2xpYi0yLjApIHdlcmUgbm90IG1l
dDoKPiAtCj4gLSRnbGliX1BLR19FUlJPUlMKPiAtCj4gLUNvbnNpZGVyIGFkanVzdGluZyB0aGUg
UEtHX0NPTkZJR19QQVRIIGVudmlyb25tZW50IHZhcmlhYmxlIGlmIHlvdQo+IC1pbnN0YWxsZWQg
c29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJlZml4Lgo+IC0KPiAtQWx0ZXJuYXRpdmVseSwg
eW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyBnbGliX0NGTEFHUwo+IC1hbmQg
Z2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KPiAtU2VlIHRo
ZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuIiAiJExJTkVOTyIgNQo+IC1l
bGlmIHRlc3QgJHBrZ19mYWlsZWQgPSB1bnRyaWVkOyB0aGVuCj4gLSAgICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNo
byAibm8iID4mNjsgfQo+IC0gICAgICAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Cj4gLSRhc19lY2hvICIkYXNfbWU6
IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KPiAtYXNfZm5fZXJyb3IgJD8gIlRoZSBwa2ct
Y29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3Vy
ZSBpdAo+IC1pcyBpbiB5b3VyIFBBVEggb3Igc2V0IHRoZSBQS0dfQ09ORklHIGVudmlyb25tZW50
IHZhcmlhYmxlIHRvIHRoZSBmdWxsCj4gLXBhdGggdG8gcGtnLWNvbmZpZy4KPiAKPiAtQWx0ZXJu
YXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyBnbGliX0NGTEFH
Uwo+IC1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4K
PiAtU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuCj4gCj4gLVRv
IGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+
Lgo+IC1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0K
PiArICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCj4gKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xf
cHJlZml4IjsgdGhlbgo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1vY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiArc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgo+
ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhl
biA6Cj4gKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gICAgICAgZ2xp
Yl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUwo+IC0gICAgICAgZ2xpYl9MSUJTPSRwa2dfY3Zf
Z2xpYl9MSUJTCj4gLSAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gLSRhc19lY2hvICJ5ZXMiID4mNjsgfQo+IC0KPiAtZmkK
PiAtCj4gLSMgQ2hlY2sgbGlicmFyeSBwYXRoCj4gLWlmIHRlc3QgIlwke2V4ZWNfcHJlZml4fS9s
aWIiID0gIiRsaWJkaXIiOyB0aGVuIDoKPiAtICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0gIk5P
TkUiICYmIHRlc3QgIiRwcmVmaXgiICE9ICJOT05FIjsgdGhlbiA6Cj4gLSAgZXhlY19wcmVmaXg9
JHByZWZpeAo+IC1maQo+IC0gICAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIjsgdGhl
biA6Cj4gLSAgZXhlY19wcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4Cj4gLWZpCj4gLSAgICBpZiB0
ZXN0IC1kICIke2V4ZWNfcHJlZml4fS9saWI2NCI7IHRoZW4gOgo+IC0KPiAtICAgICAgICBMSUJf
UEFUSD0ibGliNjQiCj4gLQo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgo+ICsg
IGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0Lgo+ICBlbHNlCj4gLQo+IC0gICAgICAgIExJQl9QQVRIPSJsaWIiCj4gK2Fz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFU
SAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+
ICsgICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQi
Cj4gKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiArICAgIGJyZWFrIDIKPiArICBmaQo+ICtk
b25lCj4gKyAgZG9uZQo+ICtJRlM9JGFzX3NhdmVfSUZTCj4gCj4gIGZpCj4gLQo+IC1lbHNlCj4g
LQo+IC0gICAgTElCX1BBVEg9IiR7bGliZGlyOmBleHByIGxlbmd0aCAiJGV4ZWNfcHJlZml4IiAr
IDFgfSIKPiAtCj4gIGZpCj4gLQo+IC0KPiAtIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KPiAtYWNf
Zm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImJ6bGliLmgiICJhY19jdl9oZWFk
ZXJfYnpsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hl
YWRlcl9iemxpYl9oIiA9IHgiInllczsgdGhlbiA6Cj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBCWjJfYnpEZWNvbXByZXNzSW5pdCBp
biAtbGJ6MiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBCWjJfYnpEZWNvbXByZXNz
SW5pdCBpbiAtbGJ6Mi4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloy
X2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4g
LUxJQlM9Ii1sYnoyICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC0vKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNo
YXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gLSNlbmRpZgo+IC1j
aGFyIEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJl
dHVybiBCWjJfYnpEZWNvbXByZXNzSW5pdCAoKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0K
PiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBh
Y19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0PXllcwo+ICtPQ0FNTEJVSUxEPSRhY19j
dl9wcm9nX09DQU1MQlVJTEQKPiAraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCj4gKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJV
SUxEIiA+JjUKPiArJGFzX2VjaG8gIiRPQ0FNTEJVSUxEIiA+JjY7IH0KPiAgZWxzZQo+IC0gIGFj
X2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVl
eHQgY29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gLWZp
Cj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3Zf
bGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY2OyB9Cj4gLWlmIHRlc3QgIngkYWNfY3Zf
bGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHpsaWI9
IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+
ICBmaQo+IAo+IAo+ICBmaQo+IC0KPiAtCj4gLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwg
IiRMSU5FTk8iICJsem1hLmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2x6bWFfaCIgPSB4IiJ5ZXM7IHRoZW4g
Ogo+IC0KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KPiAt
aWYgdGVzdCAiJHthY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyK3NldH0iID0gc2V0
OyB0aGVuIDoKPiAraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCI7IHRoZW4KPiAr
ICBhY19jdF9PQ0FNTEJVSUxEPSRPQ0FNTEJVSUxECj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiArc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICsk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAi
JHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCj4gLUxJQlM9Ii1sbHptYSAgJExJQlMiCj4gLWNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAt
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Cj4gLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQwo+IC0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLwo+IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+
IC0jZW5kaWYKPiAtY2hhciBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwo+IC1pbnQKPiAtbWFpbiAo
KQo+IC17Cj4gLXJldHVybiBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwo+IC0gIDsKPiAtICByZXR1
cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgo+IC0gIGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXI9eWVzCj4gKyAgaWYg
dGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTEJVSUxEPSIkYWNfY3RfT0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gIGVsc2UKPiAtICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5v
Cj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBp
biAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgo+ICsg
ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+
ICsgIGRvbmUKPiArSUZTPSRhc19zYXZlX0lGUwo+ICsKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gIGZpCj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGli
X2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPiY2OyB9Cj4gLWlmIHRlc3QgIngkYWNfY3ZfbGli
X2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHpsaWI9IiR6
bGliIC1ESEFWRV9MWk1BIC1sbHptYSIKPiArYWNfY3RfT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTEJVSUxECj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgo+
ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxCVUlMRCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxCVUlMRCIgPiY2OyB9
Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0KPiArICBp
ZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQlVJTEQiID0geDsgdGhlbgo+ICsgICAgT0NBTUxCVUlMRD0i
bm8iCj4gKyAgZWxzZQo+ICsgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgo+ICt5ZXM6KQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxl
dCIgPiY1Cj4gKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiArYWNfdG9vbF93YXJuZWQ9eWVz
IDs7Cj4gK2VzYWMKPiArICAgIE9DQU1MQlVJTEQ9JGFjX2N0X09DQU1MQlVJTEQKPiArICBmaQo+
ICtlbHNlCj4gKyAgT0NBTUxCVUlMRD0iJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCIKPiAgZmkKPiAK
PiAKPiAtYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImx6by9sem8xeC5o
IiAiYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlm
IHRlc3QgIngkYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiA9IHgiInllczsgdGhlbiA6Cj4gKyAg
ICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3Mg
aW4gLWxsem8yIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJl
c3MgaW4gLWxsem8yLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bzJfbHpv
MXhfZGVjb21wcmVzcytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElC
Uz0iLWxsem8yICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gKyAgICAgICAgaWYgdGVzdCAieCRl
bmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgo+IAo+IC0vKiBPdmVycmlkZSBhbnkg
R0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNoYXIg
YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAgIGJ1
aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g
ICovCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gLSNlbmRpZgo+IC1jaGFy
IGx6bzF4X2RlY29tcHJlc3MgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0dXJuIGx6
bzF4X2RlY29tcHJlc3MgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+
IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX2x6
bzJfbHpvMXhfZGVjb21wcmVzcz15ZXMKPiAtZWxzZQo+IC0gIGFjX2N2X2xpYl9sem8yX2x6bzF4
X2RlY29tcHJlc3M9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+
IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gKyAgICAgICAgICAgIGFzX2ZuX2Vycm9y
ICQ/ICJPY2FtbCB0b29scyBlbmFibGVkLCBidXQgdW5hYmxlIHRvIGZpbmQgT2NhbWwiICIkTElO
RU5PIiA1Cj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY2OyB9Cj4gLWlmIHRlc3QgIngk
YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHps
aWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCj4gKyAgICAgICAgb2NhbWx0b29scz0ibiIK
PiArCj4gIGZpCj4gCj4gK2ZpCj4gKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmFzaCIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBiYXNo
OyBhY193b3JkPSQyCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh
Y193b3JkLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0g
c2V0OyB0aGVuIDoKPiArICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICtlbHNlCj4gKyAg
Y2FzZSAkQkFTSCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2X3BhdGhfQkFT
SD0iJEJBU0giICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgo+
ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
Cj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiArICBJRlM9JGFzX3NhdmVfSUZTCj4gKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiArICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICsgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2X3BhdGhfQkFTSD0iJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJl
YWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiAKPiAr
ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9Im5vIgo+ICsg
IDs7Cj4gK2VzYWMKPiArZmkKPiArQkFTSD0kYWNfY3ZfcGF0aF9CQVNICj4gK2lmIHRlc3QgLW4g
IiRCQVNIIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQkFTSCIgPiY1Cj4gKyRhc19lY2hvICIkQkFTSCIgPiY2OyB9Cj4gK2Vsc2UK
PiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+ICtpZiB0ZXN0IHgiJHtC
QVNIfSIgPT0geCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBm
aW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2giICIkTElORU5PIiA1Cj4gK2ZpCj4gCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3Nl
dHVwIGluIC1sYWlvIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGlvX3NldHVwIGlu
IC1sYWlvLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2Fpb19pb19zZXR1cCtz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2FjX2V4dD1jCj4gK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1Mn
Cj4gK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0
ID4mNScKPiArYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBG
TEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKPiArYWNfY29tcGlsZXJf
Z251PSRhY19jdl9jX2NvbXBpbGVyX2dudQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUK
PiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IuLi4g
IiA+JjY7IH0KPiArIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1lcyBhIGRpcmVjdG9yeS4K
PiAraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KPiArICBDUFA9Cj4g
K2ZpCj4gK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCj4gKyAgaWYgdGVzdCAiJHthY19jdl9wcm9n
X0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
PiAgZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWxhaW8g
ICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4g
KyAgICAgICMgRG91YmxlIHF1b3RlcyBiZWNhdXNlIENQUCBuZWVkcyB0byBiZSBleHBhbmRlZAo+
ICsgICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRpb25hbC1jcHAiICIvbGli
L2NwcCIKPiArICAgIGRvCj4gKyAgICAgIGFjX3ByZXByb2Nfb2s9ZmFsc2UKPiArZm9yIGFjX2Nf
cHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCj4gK2RvCj4gKyAgIyBVc2UgYSBoZWFkZXIgZmls
ZSB0aGF0IGNvbWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGliYwo+ICsgICMgd2l0aCBh
IGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgo+ICsgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8g
PGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQo+ICsgICMgPGxpbWl0cy5o
PiBleGlzdHMgZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgo+ICsgICMgT24gdGhlIE5l
WFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCj4g
KyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRj
aCB0aGlzIGNhc2UuCj4gKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAo+ICAvKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC0vKiBPdmVycmlkZSBhbnkgR0ND
IGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNoYXIgYmVj
YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
Cj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gKyNpZmRlZiBfX1NURENfXwo+
ICsjIGluY2x1ZGUgPGxpbWl0cy5oPgo+ICsjZWxzZQo+ICsjIGluY2x1ZGUgPGFzc2VydC5oPgo+
ICAjZW5kaWYKPiAtY2hhciBpb19zZXR1cCAoKTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1y
ZXR1cm4gaW9fc2V0dXAgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gKyAgICAgICAg
ICAgICAgICAgICAgU3ludGF4IGVycm9yCj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5r
ICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15ZXMKPiAraWYg
YWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6Cj4gKwo+ICBlbHNlCj4gLSAgYWNfY3Zf
bGliX2Fpb19pb19zZXR1cD1ubwo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKPiAtICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf
ZXh0Cj4gLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKPiArICAjIEJyb2tlbjogZmFpbHMg
b24gdmFsaWQgaW5wdXQuCj4gK2NvbnRpbnVlCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY1
Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9Cj4gLWlmIHRlc3Qg
IngkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHN5c3RlbV9h
aW89InkiCj4gK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQK
PiArCj4gKyAgIyBPSywgd29ya3Mgb24gc2FuZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5v
bmV4aXN0ZW50IGhlYWRlcnMKPiArICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93Lgo+ICsgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArLyogZW5kIGNvbmZk
ZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KPiArX0FDRU9GCj4gK2lm
IGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+ICsgICMgQnJva2VuOiBzdWNjZXNz
IG9uIGludmFsaWQgaW5wdXQuCj4gK2NvbnRpbnVlCj4gIGVsc2UKPiAtICBzeXN0ZW1fYWlvPSJu
Igo+ICsgICMgUGFzc2VzIGJvdGggdGVzdHMuCj4gK2FjX3ByZXByb2Nfb2s9Ogo+ICticmVhawo+
ICtmaQo+ICtybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Cj4g
Kwo+ICtkb25lCj4gKyMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBj
bGVhbmluZyBjb2RlIHdhcyBza2lwcGVkLgo+ICtybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfZXh0Cj4gK2lmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKPiArICBicmVh
awo+ICBmaQo+IAo+ICsgICAgZG9uZQo+ICsgICAgYWNfY3ZfcHJvZ19DUFA9JENQUAo+IAo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBNRDUg
aW4gLWxjcnlwdG8iID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5
cHRvLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gK2ZpCj4gKyAg
Q1BQPSRhY19jdl9wcm9nX0NQUAo+ICBlbHNlCj4gLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k
TElCUwo+IC1MSUJTPSItbGNyeXB0byAgJExJQlMiCj4gLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArICBhY19jdl9wcm9nX0NQUD0kQ1BQCj4gK2ZpCj4gK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1BQIiA+JjUK
PiArJGFzX2VjaG8gIiRDUFAiID4mNjsgfQo+ICthY19wcmVwcm9jX29rPWZhbHNlCj4gK2ZvciBh
Y19jX3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwo+ICtkbwo+ICsgICMgVXNlIGEgaGVhZGVy
IGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKPiArICAjIHdp
dGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jrcy4KPiArICAjIFByZWZlciA8bGltaXRzLmg+
IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKPiArICAjIDxsaW1p
dHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KPiArICAjIE9uIHRo
ZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVyJ3MgcGFyc2Vy
LAo+ICsgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8g
Y2F0Y2ggdGhpcyBjYXNlLgo+ICsgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAtLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gLSAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+IC0gICBi
dWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHku
ICAqLwo+IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+ICsjaWZkZWYgX19TVERD
X18KPiArIyBpbmNsdWRlIDxsaW1pdHMuaD4KPiArI2Vsc2UKPiArIyBpbmNsdWRlIDxhc3NlcnQu
aD4KPiAgI2VuZGlmCj4gLWNoYXIgTUQ1ICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJl
dHVybiBNRDUgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gKyAgICAgICAgICAgICAg
ICAgICAgU3ludGF4IGVycm9yCj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCj4gK2lmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+ICsKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9jcnlw
dG9fTUQ1PW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtTElC
Uz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICsgICMgQnJva2VuOiBmYWlscyBvbiB2YWxpZCBp
bnB1dC4KPiArY29udGludWUKPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9j
cnlwdG9fTUQ1IiA9IHgiInllczsgdGhlbiA6Cj4gLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
Rgo+IC0jZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKPiArcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAo+ICsKPiArICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2Vz
LiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwo+ICsgICMgY2FuIGJlIGRl
dGVjdGVkIGFuZCBob3cuCj4gKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICovCj4gKyNpbmNsdWRlIDxhY19ub25leGlz
dGVudC5oPgo+ICBfQUNFT0YKPiAraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6
Cj4gKyAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KPiArY29udGludWUKPiAr
ZWxzZQo+ICsgICMgUGFzc2VzIGJvdGggdGVzdHMuCj4gK2FjX3ByZXByb2Nfb2s9Ogo+ICticmVh
awo+ICtmaQo+ICtybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0
Cj4gCj4gLSAgTElCUz0iLWxjcnlwdG8gJExJQlMiCj4gK2RvbmUKPiArIyBCZWNhdXNlIG9mIGBi
cmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCj4g
K3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKPiAraWYgJGFj
X3ByZXByb2Nfb2s7IHRoZW4gOgo+IAo+ICBlbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxk
IG5vdCBmaW5kIGxpYmNyeXB0byIgIiRMSU5FTk8iIDUKPiArICB7IHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiArJGFz
X2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+ICthc19mbl9lcnJv
ciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMgc2FuaXR5IGNoZWNrCj4gK1NlZSBc
YGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQo+ICBmaQo+IAo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBl
eHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
ZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3Zf
bGliX2V4dDJmc19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICthY19leHQ9Ywo+
ICthY19jcHA9JyRDUFAgJENQUEZMQUdTJwo+ICthY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAk
Q1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCj4gK2FjX2xpbms9JyRDQyAtbyBjb25mdGVz
dCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAk
TElCUyA+JjUnCj4gK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKPiArCj4g
Kwo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZSIgPiY1Cj4gKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZS4uLiAiID4m
NjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3BhdGhfR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWxleHQyZnMgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
PiArICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4KPiArICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFs
c2UKPiArICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2gg
b2YgUFJPR05BTUUtTElTVAo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KPiAr
ZG8KPiArICBJRlM9JGFzX3NhdmVfSUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KPiArICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dyZXA7IGRvCj4gKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiArICAgICAgYWNfcGF0
aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0Igo+ICsgICAgICB7IHRlc3QgLWYg
IiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0dSRVAiOyB9IHx8IGNvbnRp
bnVlCj4gKyMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBp
cyBmb3VuZC4KPiArICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAo+ICtjYXNlIGAiJGFj
X3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCj4gKypHTlUqKQo+ICsgIGFjX2N2X3BhdGhf
R1JFUD0iJGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7Owo+ICsqKQo+ICsgIGFj
X2NvdW50PTAKPiArICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKPiArICB3
aGlsZSA6Cj4gKyAgZG8KPiArICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJj
b25mdGVzdC50bXAiCj4gKyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCj4gKyAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKPiArICAgICRhc19lY2hvICdHUkVQJyA+
PiAiY29uZnRlc3QubmwiCj4gKyAgICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShj
YW5ub3QgbWF0Y2gpLScgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVs
bCB8fCBicmVhawo+ICsgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2
L251bGwgMj4mMSB8fCBicmVhawo+ICsgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBh
Y19jb3VudD0kYXNfdmFsCj4gKyAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dS
RVBfbWF4LTB9OyB0aGVuCj4gKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBr
ZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQo+ICsgICAgICBhY19jdl9wYXRoX0dSRVA9IiRh
Y19wYXRoX0dSRVAiCj4gKyAgICAgIGFjX3BhdGhfR1JFUF9tYXg9JGFjX2NvdW50Cj4gKyAgICBm
aQo+ICsgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3Vn
aAo+ICsgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCj4gKyAgZG9uZQo+ICsgIHJt
IC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7Owo+
ICtlc2FjCj4gCj4gLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2
b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUg
cmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQg
cHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4g
LWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIgZXh0MmZzX29wZW4yICgpOwo+IC1pbnQKPiAt
bWFpbiAoKQo+IC17Cj4gLXJldHVybiBleHQyZnNfb3BlbjIgKCk7Cj4gLSAgOwo+IC0gIHJldHVy
biAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhl
biA6Cj4gLSAgYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjI9eWVzCj4gKyAgICAgICRhY19w
YXRoX0dSRVBfZm91bmQgJiYgYnJlYWsgMwo+ICsgICAgZG9uZQo+ICsgIGRvbmUKPiArICBkb25l
Cj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiArICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9HUkVQIjsg
dGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgZ3JlcCBjb3VsZCBiZSBm
b3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1Cj4g
KyAgZmkKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPW5vCj4gKyAg
YWNfY3ZfcGF0aF9HUkVQPSRHUkVQCj4gIGZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKPiAtTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICsKPiAgZmkKPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0
MmZzX2V4dDJmc19vcGVuMiIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGliX2V4dDJmc19leHQy
ZnNfb3BlbjIiID4mNjsgfQo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29w
ZW4yIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgbGliZXh0MmZzPSJ5Igo+ICt7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1
Cj4gKyRhc19lY2hvICIkYWNfY3ZfcGF0aF9HUkVQIiA+JjY7IH0KPiArIEdSRVA9IiRhY19jdl9w
YXRoX0dSRVAiCj4gKwo+ICsKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgZWdyZXAiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
ZWdyZXAuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX0VHUkVQK3NldH0iID0g
c2V0OyB0aGVuIDoKPiArICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAg
bGliZXh0MmZzPSJuIgo+ICsgIGlmIGVjaG8gYSB8ICRHUkVQIC1FICcoYXxiKScgPi9kZXYvbnVs
bCAyPiYxCj4gKyAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCj4gKyAgIGVsc2UK
PiArICAgICBpZiB0ZXN0IC16ICIkRUdSRVAiOyB0aGVuCj4gKyAgYWNfcGF0aF9FR1JFUF9mb3Vu
ZD1mYWxzZQo+ICsgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3Ig
ZWFjaCBvZiBQUk9HTkFNRS1MSVNUCj4gKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgo+ICtmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2Jp
bgo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9Lgo+ICsgICAgZm9yIGFjX3Byb2cgaW4gZWdyZXA7IGRvCj4gKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiArICAgICAgYWNfcGF0
aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIKPiArICAgICAgeyB0ZXN0IC1m
ICIkYWNfcGF0aF9FR1JFUCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNv
bnRpbnVlCj4gKyMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0VHUkVQIGFuZCBzZWxlY3QgaXQgaWYg
aXQgaXMgZm91bmQuCj4gKyAgIyBDaGVjayBmb3IgR05VICRhY19wYXRoX0VHUkVQCj4gK2Nhc2Ug
YCIkYWNfcGF0aF9FR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCj4gKypHTlUqKQo+ICsgIGFjX2N2
X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VHUkVQX2ZvdW5kPTo7Owo+ICsq
KQo+ICsgIGFjX2NvdW50PTAKPiArICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5p
biIKPiArICB3aGlsZSA6Cj4gKyAgZG8KPiArICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVz
dC5pbiIgPiJjb25mdGVzdC50bXAiCj4gKyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3Qu
aW4iCj4gKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKPiArICAgICRhc19lY2hv
ICdFR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgo+ICsgICAgIiRhY19wYXRoX0VHUkVQIiAnRUdSRVAk
JyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCj4g
KyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8
IGJyZWFrCj4gKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192
YWwKPiArICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfRUdSRVBfbWF4LTB9OyB0
aGVuCj4gKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcg
Zm9yIGEgYmV0dGVyIG9uZQo+ICsgICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JF
UCIKPiArICAgICAgYWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50Cj4gKyAgICBmaQo+ICsgICAg
IyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAo+ICsgICAg
dGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCj4gKyAgZG9uZQo+ICsgIHJtIC1mIGNvbmZ0
ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7Owo+ICtlc2FjCj4g
Kwo+ICsgICAgICAkYWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBicmVhayAzCj4gKyAgICBkb25lCj4g
KyAgZG9uZQo+ICsgIGRvbmUKPiArSUZTPSRhc19zYXZlX0lGUwo+ICsgIGlmIHRlc3QgLXogIiRh
Y19jdl9wYXRoX0VHUkVQIjsgdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFi
bGUgZWdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQv
YmluIiAiJExJTkVOTyIgNQo+ICsgIGZpCj4gK2Vsc2UKPiArICBhY19jdl9wYXRoX0VHUkVQPSRF
R1JFUAo+ICBmaQo+IAo+ICsgICBmaQo+ICtmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQo+ICskYXNfZWNo
byAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQo+ICsgRUdSRVA9IiRhY19jdl9wYXRoX0VHUkVQ
Igo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBnY3J5X21kX2hhc2hfYnVmZmVyIGluIC1sZ2NyeXB0IiA+JjUKPiAtJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0K
PiAtaWYgdGVzdCAiJHthY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+ICsKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxlcyIgPiY1Cj4gKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3Qg
IiR7YWNfY3ZfaGVhZGVyX3N0ZGMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJT
Cj4gLUxJQlM9Ii1sZ2NyeXB0ICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAo+ICsgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8c3RkbGliLmg+
Cj4gKyNpbmNsdWRlIDxzdGRhcmcuaD4KPiArI2luY2x1ZGUgPHN0cmluZy5oPgo+ICsjaW5jbHVk
ZSA8ZmxvYXQuaD4KPiAKPiAtLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg
dG8gYXZvaWQgYW4gZXJyb3IuCj4gLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNo
IHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+IC0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1
bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwo+IC0jaWZkZWYgX19jcGx1c3Bs
dXMKPiAtZXh0ZXJuICJDIgo+IC0jZW5kaWYKPiAtY2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgp
Owo+ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLXJldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgp
Owo+ICsKPiAgICA7Cj4gICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4gLWlmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf
aGFzaF9idWZmZXI9eWVzCj4gK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVu
IDoKPiArICBhY19jdl9oZWFkZXJfc3RkYz15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9nY3J5
cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKPiAtICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0Cj4gLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKPiArICBhY19jdl9oZWFk
ZXJfc3RkYz1ubwo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1Cj4g
LSRhc19lY2hvICIkYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjY7IH0K
PiAtaWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID0geCIi
eWVzOyB0aGVuIDoKPiAtICBsaWJnY3J5cHQ9InkiCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+ICsKPiAraWYgdGVzdCAkYWNf
Y3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiArICAjIFN1bk9TIDQueCBzdHJpbmcuaCBkb2Vz
IG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFOU0kuCj4gKyAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICovCj4g
KyNpbmNsdWRlIDxzdHJpbmcuaD4KPiArCj4gK19BQ0VPRgo+ICtpZiAoZXZhbCAiJGFjX2NwcCBj
b25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Cj4gKyAgJEVHUkVQICJtZW1jaHIiID4vZGV2L251bGwg
Mj4mMTsgdGhlbiA6Cj4gKwo+ICBlbHNlCj4gLSAgbGliZ2NyeXB0PSJuIgo+ICsgIGFjX2N2X2hl
YWRlcl9zdGRjPW5vCj4gK2ZpCj4gK3JtIC1mIGNvbmZ0ZXN0Kgo+ICsKPiAgZmkKPiAKPiAraWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiArICAjIElTQyAyLjAuMiBzdGRs
aWIuaCBkb2VzIG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCj4gKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMu
aC4gICovCj4gKyNpbmNsdWRlIDxzdGRsaWIuaD4KPiAKPiArX0FDRU9GCj4gK2lmIChldmFsICIk
YWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKPiArICAkRUdSRVAgImZyZWUiID4vZGV2
L251bGwgMj4mMTsgdGhlbiA6Cj4gCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFkIGZsYWciID4mNQo+IC0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgcHRocmVhZCBmbGFnLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YXhf
Y3ZfcHRocmVhZF9mbGFncytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAgZWxzZQo+ICsgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCj4gK2ZpCj4gK3Jt
IC1mIGNvbmZ0ZXN0Kgo+IAo+IC0gICAgICAgIGF4X2N2X3B0aHJlYWRfZmxhZ3M9LXB0aHJlYWQK
PiArZmkKPiAKPiAtICAgIFBUSFJFQURfQ0ZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKPiAt
ICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCj4gLSAgICBQVEhSRUFE
X0xJQlM9IiIKPiAraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiArICAj
IC9iaW4vY2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3Mg
dXNpbmcgLWFuc2kuCj4gKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g
Ogo+ICsgIDoKPiArZWxzZQo+ICsgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiArLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8Y3R5cGUuaD4K
PiArI2luY2x1ZGUgPHN0ZGxpYi5oPgo+ICsjaWYgKCgnICcgJiAweDBGRikgPT0gMHgwMjApCj4g
KyMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykKPiArIyBkZWZp
bmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMpKQo+ICsj
ZWxzZQo+ICsjIGRlZmluZSBJU0xPV0VSKGMpIFwKPiArICAgICAgICAgICAgICAgICAgKCgnYScg
PD0gKGMpICYmIChjKSA8PSAnaScpIFwKPiArICAgICAgICAgICAgICAgICAgICB8fCAoJ2onIDw9
IChjKSAmJiAoYykgPD0gJ3InKSBcCj4gKyAgICAgICAgICAgICAgICAgICAgfHwgKCdzJyA8PSAo
YykgJiYgKGMpIDw9ICd6JykpCj4gKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAo
KGMpIHwgMHg0MCkgOiAoYykpCj4gKyNlbmRpZgo+IAo+ICsjZGVmaW5lIFhPUihlLCBmKSAoKChl
KSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQo+ICtpbnQKPiArbWFpbiAoKQo+ICt7Cj4gKyAg
aW50IGk7Cj4gKyAgZm9yIChpID0gMDsgaSA8IDI1NjsgaSsrKQo+ICsgICAgaWYgKFhPUiAoaXNs
b3dlciAoaSksIElTTE9XRVIgKGkpKQo+ICsgICAgICAgfHwgdG91cHBlciAoaSkgIT0gVE9VUFBF
UiAoaSkpCj4gKyAgICAgIHJldHVybiAyOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4gK19BQ0VPRgo+
ICtpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAKPiAtICAgIHNhdmVkX0NG
TEFHUz0iJENGTEFHUyIKPiArZWxzZQo+ICsgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCj4gK2ZpCj4g
K3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRl
c3QkYWNfZXhlZXh0IFwKPiArICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29u
ZnRlc3QuJGFjX2V4dAo+ICtmaQo+IAo+IC0gICAgc2F2ZWRfTERGTEFHUz0iJExERkxBR1MiCj4g
K2ZpCj4gK2ZpCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl9z
dGRjIiA+JjY7IH0KPiAraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiAK
PiAtICAgIHNhdmVkX0xJQlM9IiRMSUJTIgo+ICskYXNfZWNobyAiI2RlZmluZSBTVERDX0hFQURF
UlMgMSIgPj5jb25mZGVmcy5oCj4gCj4gK2ZpCj4gCj4gLSAgICBDRkxBR1M9IiRDRkxBR1MgJFBU
SFJFQURfQ0ZMQUdTIgo+ICsjIE9uIElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5cGVzLmgg
YXJlIGNvbmZsaWN0aW5nLgo+ICtmb3IgYWNfaGVhZGVyIGluIHN5cy90eXBlcy5oIHN5cy9zdGF0
Lmggc3RkbGliLmggc3RyaW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKPiArICAgICAgICAgICAg
ICAgICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0ZC5oCj4gK2RvIDoKPiArICBhc19hY19IZWFk
ZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCj4gK2Fj
X2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2Fj
X0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0Cj4gKyIKPiAraWYgZXZhbCB0ZXN0IFwieFwk
IiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgo+ICsgIGNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKPiArI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJf
Y3BwYCAxCj4gK19BQ0VPRgo+IAo+IC0gICAgTERGTEFHUz0iJExERkxBR1MgJFBUSFJFQURfTERG
TEFHUyIKPiArZmkKPiAKPiAtICAgIExJQlM9IiRMSUJTICRQVEhSRUFEX0xJQlMiCj4gK2RvbmUK
PiAKPiAtICAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAKPiAtI2luY2x1ZGUgPHB0aHJlYWQuaD4KPiAt
aW50IG1haW4odm9pZCkgewo+IC0gIHB0aHJlYWRfYXRmb3JrKDAsMCwwKTsKPiAtICBwdGhyZWFk
X2NyZWF0ZSgwLDAsMCwwKTsKPiAtfQo+ICtpZiB0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSI7
IHRoZW4gOgo+IAo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgo+ICsgICAgaWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyI7IHRoZW4gOgo+IAo+
ICsgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgo+ICsgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUg
JFBZVEhPTlBBVEhgCj4gKwo+ICtlbGlmIHRlc3QgLXogIiRQWVRIT04iOyB0aGVuIDoKPiArICBQ
WVRIT049InB5dGhvbiIKPiAgZWxzZQo+IC0gIGF4X2N2X3B0aHJlYWRfZmxhZ3M9ZmFpbGVkCj4g
KyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1
dGUgcGF0aCIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAo+ICsgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15ICRQWVRIT047IGFj
X3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiAr
ICBjYXNlICRQWVRIT05QQVRIIGluCj4gKyAgW1xcL10qIHwgPzpbXFwvXSopCj4gKyAgYWNfY3Zf
cGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElG
Uz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0
aF9QWVRIT05QQVRIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUK
PiArSUZTPSRhc19zYXZlX0lGUwo+IAo+IC0gICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgo+ICsg
IHRlc3QgLXogIiRhY19jdl9wYXRoX1BZVEhPTlBBVEgiICYmIGFjX2N2X3BhdGhfUFlUSE9OUEFU
SD0ibm8iCj4gKyAgOzsKPiArZXNhYwo+ICtmaQo+ICtQWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZ
VEhPTlBBVEgKPiAraWYgdGVzdCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQWVRIT05QQVRIIiA+JjUK
PiArJGFzX2VjaG8gIiRQWVRIT05QQVRIIiA+JjY7IH0KPiArZWxzZQo+ICsgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19lY2hv
ICJubyIgPiY2OyB9Cj4gK2ZpCj4gCj4gLSAgICBMREZMQUdTPSIkc2F2ZWRfTERGTEFHUyIKPiAK
PiAtICAgIExJQlM9IiRzYXZlZF9MSUJTIgo+ICtpZiB0ZXN0IHgiJHtQWVRIT05QQVRIfSIgPT0g
eCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kICRQWVRI
T04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1Cj4gK2ZpCj4gKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRob24g
dmVyc2lvbiA+PSAyLjMgIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2
ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KPiArYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7IHN5
cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAo+ICtpZiB0ZXN0ICIk
PyIgIT0gIjAiCj4gK3RoZW4KPiArICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFg
Cj4gKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIiRw
eXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgMi4z
IiAiJExJTkVOTyIgNQo+ICtlbHNlCj4gKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2VjaG8gInllcyIgPiY2OyB9Cj4g
K2ZpCj4gCj4gK2FjX3ByZXZpb3VzX2NwcGZsYWdzPSRDUFBGTEFHUwo+ICthY19wcmV2aW91c19s
ZGZsYWdzPSRMREZMQUdTCj4gK2FjX3B5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1jICdpbXBvcnQg
ZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+ICsgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5n
ZXRfY29uZmlnX3ZhcigiVkVSU0lPTiIpJ2AKPiArIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIkUFlUSE9OLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Cj4gK3NldCBkdW1teSAkUFlUSE9OLWNvbmZpZzsgYWNfd29yZD0kMgo+ICt7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4g
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0
ICIke2FjX2N2X3BhdGhfcHljb25maWcrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBjYXNlICRweWNvbmZpZyBpbgo+ICsgIFtc
XC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2X3BhdGhfcHljb25maWc9IiRweWNvbmZpZyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAq
KQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2Rp
ciBpbiAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNf
ZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0aF9weWNvbmZpZz0iJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsg
IGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiAKPiArICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9weWNvbmZpZyIgJiYgYWNfY3ZfcGF0aF9weWNvbmZpZz0ibm8iCj4gKyAg
OzsKPiArZXNhYwo+ICtmaQo+ICtweWNvbmZpZz0kYWNfY3ZfcGF0aF9weWNvbmZpZwo+ICtpZiB0
ZXN0IC1uICIkcHljb25maWciOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRweWNvbmZpZyIgPiY1Cj4gKyRhc19lY2hvICIkcHljb25m
aWciID4mNjsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAt
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRheF9jdl9w
dGhyZWFkX2ZsYWdzIiA+JjUKPiAtJGFzX2VjaG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7
IH0KPiAtICAgIGlmIHRlc3QgIngkYXhfY3ZfcHRocmVhZF9mbGFncyIgPSB4ZmFpbGVkOyB0aGVu
Cj4gLSAgICAgICAgYXNfZm5fZXJyb3IgJD8gIi1wdGhyZWFkIGRvZXMgbm90IHdvcmsiICIkTElO
RU5PIiA1Cj4gLSAgICBmaQo+IC0KPiAtICAgIFBUSFJFQURfQ0ZMQUdTPSIkYXhfY3ZfcHRocmVh
ZF9mbGFncyIKPiAtICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCj4g
LSAgICBQVEhSRUFEX0xJQlM9IiIKPiAKPiAKPiAraWYgdGVzdCB4IiRweWNvbmZpZyIgPT0geCJu
byI7IHRoZW4gOgo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBjbG9ja19nZXR0aW1lIGluIC1scnQiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgY2xvY2tfZ2V0dGltZSBpbiAtbHJ0Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3Qg
IiR7YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCj4gLUxJQlM9Ii1scnQgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiArICAgICAg
ICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25m
aWc7IFwKPiArICAgICAgICBwcmludCAiLUkiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29u
ZmlnX3ZhcigiSU5DTFVERVBZIiknYCIKPiArICAgIENQUEZMQUdTPSIkQ1BQRkxBR1MgYCRQWVRI
T04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gKyAgICAgICAgcHJpbnQgZGlz
dHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiQ0ZMQUdTIiknYCIKPiArICAgIExERkxB
R1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+
ICsgICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIkxJQlMi
KSdgIgo+ICsgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRp
bHMuc3lzY29uZmlnOyBcCj4gKyAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRf
Y29uZmlnX3ZhcigiU1lTTElCUyIpJ2AiCj4gKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhP
TiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKPiArICAgICAgICBwcmludCAiLUwi
ICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9uX2xpYihwbGF0X3NwZWNpZmljPTEsXAo+
ICsgICAgICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidgIgo+ICsgICAgTERGTEFHUz0i
JExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gKyAg
ICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElOS0ZPUlNI
QVJFRCIpJ2AiCj4gKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRp
c3R1dGlscy5zeXNjb25maWc7IFwKPiArICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmln
LmdldF9jb25maWdfdmFyKCJMREZMQUdTIiknYCIKPiAKPiAtLyogT3ZlcnJpZGUgYW55IEdDQyBp
bnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gLSAgIFVzZSBjaGFyIGJlY2F1
c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+IC0gICBidWlsdGlu
IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwo+
IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+IC0jZW5kaWYKPiAtY2hhciBjbG9j
a19nZXR0aW1lICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJldHVybiBjbG9ja19nZXR0
aW1lICgpOwo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5f
Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0
aW1lPXllcwo+ICBlbHNlCj4gLSAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9bm8KPiAtZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID4mNQo+IC0kYXNfZWNobyAi
JGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjY7IH0KPiAtaWYgdGVzdCAieCRhY19jdl9s
aWJfcnRfY2xvY2tfZ2V0dGltZSIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKPiAtI2RlZmluZSBIQVZFX0xJQlJUIDEKPiAtX0FDRU9GCj4gCj4gLSAgTElC
Uz0iLWxydCAkTElCUyIKPiArICAgICAgICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTi1jb25m
aWcgLS1jZmxhZ3NgIgo+ICsgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04tY29uZmlnIC0t
bGRmbGFnc2AiCj4gCj4gIGZpCj4gCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsIiA+JjUKPiAtJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2OyB9Cj4gLWlm
IHRlc3QgIiR7YWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYytzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWx5YWpsICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4g
K2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJQeXRob24uaCIgImFjX2N2
X2hlYWRlcl9QeXRob25faCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+ICtpZiB0ZXN0ICJ4JGFj
X2N2X2hlYWRlcl9QeXRob25faCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC0vKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNo
YXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gLSNlbmRpZgo+IC1j
aGFyIHlhamxfYWxsb2MgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0dXJuIHlhamxf
YWxsb2MgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX3lhamxfeWFqbF9h
bGxvYz15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KPiAtZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIFB5dGhvbiBkZXZl
bG9wbWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mi
ID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQo+IC1p
ZiB0ZXN0ICJ4JGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID0geCIieWVzOyB0aGVuIDoKPiAt
ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKPiAt
X0FDRU9GCj4gLQo+IC0gIExJQlM9Ii1seWFqbCAkTElCUyIKPiAKPiAtZWxzZQo+IC0gIGFzX2Zu
X2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB5YWpsIiAiJExJTkVOTyIgNQo+IC1maQo+IAo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBkZWZs
YXRlQ29weSBpbiAtbHoiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgZGVmbGF0ZUNv
cHkgaW4gLWx6Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX3pfZGVmbGF0ZUNv
cHkrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICthc19hY19MaWI9YCRhc19lY2hvICJhY19jdl9saWJf
cHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uJydfUHlBcmdfUGFyc2VUdXBsZSIgfCAkYXNfdHJfc2hg
Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQo+ICsk
YXNfZWNob19uICJjaGVja2luZyBmb3IgUHlBcmdfUGFyc2VUdXBsZSBpbiAtbHB5dGhvbiRhY19w
eXRob25fdmVyc2lvbi4uLiAiID4mNjsgfQo+ICtpZiBldmFsICJ0ZXN0IFwiXCR7JGFzX2FjX0xp
YitzZXR9XCIiID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+
ICBlbHNlCj4gICAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+IC1MSUJTPSItbHogICRM
SUJTIgo+ICtMSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiAgJExJQlMiCj4gIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZz
LmguICAqLwo+IAo+IEBAIC03NjMyLDE4OTMgKzUzNzcsMTE3MyBAQCBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gICNpZmRlZiBfX2NwbHVzcGx1cwo+ICBleHRl
cm4gIkMiCj4gICNlbmRpZgo+IC1jaGFyIGRlZmxhdGVDb3B5ICgpOwo+ICtjaGFyIFB5QXJnX1Bh
cnNlVHVwbGUgKCk7Cj4gIGludAo+ICBtYWluICgpCj4gIHsKPiAtcmV0dXJuIGRlZmxhdGVDb3B5
ICgpOwo+ICtyZXR1cm4gUHlBcmdfUGFyc2VUdXBsZSAoKTsKPiAgICA7Cj4gICAgcmV0dXJuIDA7
Cj4gIH0KPiAgX0FDRU9GCj4gIGlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
PiAtICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKPiArICBldmFsICIkYXNfYWNfTGliPXll
cyIKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5vCj4gKyAgZXZhbCAiJGFz
X2FjX0xpYj1ubyIKPiAgZmkKPiAgcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBcCj4gICAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICBM
SUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4m
NQo+IC0kYXNfZWNobyAiJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KPiAtaWYgdGVz
dCAieCRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICtldmFsIGFj
X3Jlcz1cJCRhc19hY19MaWIKPiArICAgICAgICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Cj4gKyRhc19lY2hvICIkYWNf
cmVzIiA+JjY7IH0KPiAraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19MaWIiXCIgPSB4InllcyI7
IHRoZW4gOgo+ICAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBIQVZFX0xJ
QlogMQo+ICsjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV9MSUJweXRob24kYWNfcHl0aG9uX3ZlcnNp
b24iIHwgJGFzX3RyX2NwcGAgMQo+ICBfQUNFT0YKPiAKPiAtICBMSUJTPSItbHogJExJQlMiCj4g
LQo+IC1lbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHpsaWIiICIkTElO
RU5PIiA1Cj4gLWZpCj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4mNQo+IC0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252Li4uICIgPiY2OyB9Cj4g
LWlmIHRlc3QgIiR7YWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4rc2V0fSIgPSBzZXQ7IHRo
ZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCj4gLUxJQlM9Ii1saWNvbnYgICRMSUJTIgo+IC1jYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KPiArICBMSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiAkTElCUyIKPiAKPiAt
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Cj4gLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQwo+IC0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLwo+IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+
IC0jZW5kaWYKPiAtY2hhciBsaWJpY29udl9vcGVuICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17
Cj4gLXJldHVybiBsaWJpY29udl9vcGVuICgpOwo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+
IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFj
X2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfbGliX2lj
b252X2xpYmljb252X29wZW49bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gLWZpCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xp
Ymljb252X29wZW4iID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9v
cGVuIiA+JjY7IH0KPiAtaWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIg
PSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIGxpYmljb252PSJ5Igo+ICBlbHNlCj4gLSAgbGliaWNvbnY9
Im4iCj4gKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgcHl0aG9u
IGRldmVsb3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1Cj4gIGZpCj4gCj4gK0NQUEZMQUdTPSRh
Y19wcmV2aW91c19jcHBmbGFncwo+ICtMRExGQUdTPSRhY19wcmV2aW91c19sZGZsYWdzCj4gCj4g
Cj4gLSMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCj4gLSMgVGhlIFVsdHJpeCA0LjIgbWlwcyBi
dWlsdGluIGFsbG9jYSBkZWNsYXJlZCBieSBhbGxvY2EuaCBvbmx5IHdvcmtzCj4gLSMgZm9yIGNv
bnN0YW50IGFyZ3VtZW50cy4gIFVzZWxlc3MhCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmgiID4mNQo+IC0kYXNf
ZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBhbGxvY2EuaC4uLiAiID4mNjsgfQo+IC1pZiB0
ZXN0ICIke2FjX2N2X3dvcmtpbmdfYWxsb2NhX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtmaQo+
ICsjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInhnZXR0ZXh0Iiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQy
Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhl
biA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+IC0jaW5jbHVkZSA8YWxsb2NhLmg+Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtY2hh
ciAqcCA9IChjaGFyICopIGFsbG9jYSAoMiAqIHNpemVvZiAoaW50KSk7Cj4gLSAgICAgICAgICAg
ICAgICAgICAgICAgICBpZiAocCkgcmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19
Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAg
YWNfY3Zfd29ya2luZ19hbGxvY2FfaD15ZXMKPiAtZWxzZQo+IC0gIGFjX2N2X3dvcmtpbmdfYWxs
b2NhX2g9bm8KPiArICBjYXNlICRYR0VUVEVYVCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+
ICsgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp
ZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+
ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+
ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
Cj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNf
Y3ZfcGF0aF9YR0VUVEVYVD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBk
b25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiArCj4gKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdF
VFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9Im5vIgo+ICsgIDs7Cj4gK2VzYWMKPiAgZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICtYR0VUVEVYVD0kYWNfY3ZfcGF0
aF9YR0VUVEVYVAo+ICtpZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1Cj4g
KyRhc19lY2hvICIkWEdFVFRFWFQiID4mNjsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5v
IiA+JjY7IH0KPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19j
dl93b3JraW5nX2FsbG9jYV9oIiA+JjY7IH0KPiAtaWYgdGVzdCAkYWNfY3Zfd29ya2luZ19hbGxv
Y2FfaCA9IHllczsgdGhlbgo+IAo+IC0kYXNfZWNobyAiI2RlZmluZSBIQVZFX0FMTE9DQV9IIDEi
ID4+Y29uZmRlZnMuaAo+IAo+ICtpZiB0ZXN0IHgiJHtYR0VUVEVYVH0iID09IHgibm8iCj4gK3Ro
ZW4KPiArICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNl
IGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1Cj4gIGZpCj4gLQo+IC17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhbGxvY2EiID4mNQo+IC0k
YXNfZWNob19uICJjaGVja2luZyBmb3IgYWxsb2NhLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7
YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgo+ICtzZXQgZHVtbXkgYXM4NjsgYWNfd29yZD0kMgo+ICt7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfQVM4NitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaWZkZWYgX19HTlVDX18K
PiAtIyBkZWZpbmUgYWxsb2NhIF9fYnVpbHRpbl9hbGxvY2EKPiAtI2Vsc2UKPiAtIyBpZmRlZiBf
TVNDX1ZFUgo+IC0jICBpbmNsdWRlIDxtYWxsb2MuaD4KPiAtIyAgZGVmaW5lIGFsbG9jYSBfYWxs
b2NhCj4gLSMgZWxzZQo+IC0jICBpZmRlZiBIQVZFX0FMTE9DQV9ICj4gLSMgICBpbmNsdWRlIDxh
bGxvY2EuaD4KPiAtIyAgZWxzZQo+IC0jICAgaWZkZWYgX0FJWAo+IC0gI3ByYWdtYSBhbGxvY2EK
PiAtIyAgIGVsc2UKPiAtIyAgICBpZm5kZWYgYWxsb2NhIC8qIHByZWRlZmluZWQgYnkgSFAgY2Mg
K09saWJjYWxscyAqLwo+IC1jaGFyICphbGxvY2EgKCk7Cj4gLSMgICAgZW5kaWYKPiAtIyAgIGVu
ZGlmCj4gLSMgIGVuZGlmCj4gLSMgZW5kaWYKPiAtI2VuZGlmCj4gLQo+IC1pbnQKPiAtbWFpbiAo
KQo+IC17Cj4gLWNoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDEpOwo+IC0gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGlmIChwKSByZXR1cm4gMDsKPiAtICA7Cj4gLSAgcmV0dXJu
IDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVu
IDoKPiAtICBhY19jdl9mdW5jX2FsbG9jYV93b3Jrcz15ZXMKPiAtZWxzZQo+IC0gIGFjX2N2X2Z1
bmNfYWxsb2NhX3dvcmtzPW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVu
Y19hbGxvY2Ffd29ya3MiID4mNjsgfQo+IC0KPiAtaWYgdGVzdCAkYWNfY3ZfZnVuY19hbGxvY2Ff
d29ya3MgPSB5ZXM7IHRoZW4KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBIDEi
ID4+Y29uZmRlZnMuaAo+ICsgIGNhc2UgJEFTODYgaW4KPiArICBbXFwvXSogfCA/OltcXC9dKikK
PiArICBhY19jdl9wYXRoX0FTODY9IiRBUzg2IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdCB3aXRoIGEgcGF0aC4KPiArICA7Owo+ICsgICopCj4gKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgo+ICtmb3IgYXNfZGlyIGluICRQQVRICj4gK2RvCj4gKyAgSUZT
PSRhc19zYXZlX0lGUwo+ICsgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiArICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gKyAgICBhY19jdl9wYXRo
X0FTODY9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKPiArICAgIGJyZWFrIDIKPiArICBmaQo+ICtkb25lCj4gKyAgZG9uZQo+ICtJRlM9
JGFzX3NhdmVfSUZTCj4gCj4gKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQVM4NiIgJiYgYWNfY3Zf
cGF0aF9BUzg2PSJubyIKPiArICA7Owo+ICtlc2FjCj4gK2ZpCj4gK0FTODY9JGFjX2N2X3BhdGhf
QVM4Ngo+ICtpZiB0ZXN0IC1uICIkQVM4NiI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEFTODYiID4mNQo+ICskYXNfZWNobyAiJEFT
ODYiID4mNjsgfQo+ICBlbHNlCj4gLSAgIyBUaGUgU1ZSMyBsaWJQVyBhbmQgU1ZSNCBsaWJ1Y2Ig
Ym90aCBjb250YWluIGluY29tcGF0aWJsZSBmdW5jdGlvbnMKPiAtIyB0aGF0IGNhdXNlIHRyb3Vi
bGUuICBTb21lIHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2NhIG9yCj4gLSMgY29u
dGFpbiBhIGJ1Z2d5IHZlcnNpb24uICBJZiB5b3Ugc3RpbGwgd2FudCB0byB1c2UgdGhlaXIgYWxs
b2NhLAo+IC0jIHVzZSBhciB0byBleHRyYWN0IGFsbG9jYS5vIGZyb20gdGhlbSBpbnN0ZWFkIG9m
IGNvbXBpbGluZyBhbGxvY2EuYy4KPiAtCj4gLUFMTE9DQT1cJHtMSUJPQkpESVJ9YWxsb2NhLiRh
Y19vYmpleHQKPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMu
aAo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gK2ZpCj4gCj4gCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBcYGFsbG9jYS5j
JyBuZWVkcyBDcmF5IGhvb2tzIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBc
YGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3Zfb3NfY3JheStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgeCIke0FTODZ9IiA9PSB4
Im5vIgo+ICt0aGVuCj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYXM4Niwg
cGxlYXNlIGluc3RhbGwgYXM4NiIgIiRMSU5FTk8iIDUKPiArZmkKPiArIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJsZDg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiArc2V0IGR1bW15IGxkODY7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19j
dl9wYXRoX0xEODYrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2Cj4gIGVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2lmIGRlZmluZWQgQ1JBWSAmJiAh
IGRlZmluZWQgQ1JBWTIKPiAtd2ViZWNyYXkKPiAtI2Vsc2UKPiAtd2Vub3RiZWNyYXkKPiAtI2Vu
ZGlmCj4gKyAgY2FzZSAkTEQ4NiBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2
X3BhdGhfTEQ4Nj0iJExEODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgo+ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiArICBJRlM9JGFzX3NhdmVf
SUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiArICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICsgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2X3BhdGhfTEQ4Nj0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+
ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9J
RlMKPiAKPiAtX0FDRU9GCj4gLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAy
PiY1IHwKPiAtICAkRUdSRVAgIndlYmVjcmF5IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgo+IC0g
IGFjX2N2X29zX2NyYXk9eWVzCj4gLWVsc2UKPiAtICBhY19jdl9vc19jcmF5PW5vCj4gKyAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfTEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKPiArICA7Owo+
ICtlc2FjCj4gIGZpCj4gLXJtIC1mIGNvbmZ0ZXN0Kgo+IC0KPiArTEQ4Nj0kYWNfY3ZfcGF0aF9M
RDg2Cj4gK2lmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkTEQ4NiIgPiY1Cj4gKyRhc19lY2hvICIkTEQ4
NiIgPiY2OyB9Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29z
X2NyYXkiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4mNjsgfQo+IC1pZiB0ZXN0
ICRhY19jdl9vc19jcmF5ID0geWVzOyB0aGVuCj4gLSAgZm9yIGFjX2Z1bmMgaW4gX2dldGI2NyBH
RVRCNjcgZ2V0YjY3OyBkbwo+IC0gICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18k
YWNfZnVuYyIgfCAkYXNfdHJfc2hgCj4gLWFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRh
Y19mdW5jIiAiJGFzX2FjX3ZhciIKPiAtaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIg
PSB4InllcyI7IHRoZW4gOgo+IC0KPiAtY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVm
aW5lIENSQVlfU1RBQ0tTRUdfRU5EICRhY19mdW5jCj4gLV9BQ0VPRgo+IAo+IC0gICAgYnJlYWsK
PiAtZmkKPiAKPiAtICBkb25lCj4gK2lmIHRlc3QgeCIke0xEODZ9IiA9PSB4Im5vIgo+ICt0aGVu
Cj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGluc3Rh
bGwgbGQ4NiIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYSIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHN0YWNrIGRpcmVjdGlvbiBmb3IgQyBhbGxvY2Eu
Li4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9jX3N0YWNrX2RpcmVjdGlvbitzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmNjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15IGJjYzsgYWNfd29y
ZD0kMgo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3BhdGhfQkNDK3NldH0iID0gc2V0OyB0aGVu
IDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAi
JGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFjX2N2X2Nfc3RhY2tfZGlyZWN0
aW9uPTAKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVsdAo+
IC1pbnQKPiAtZmluZF9zdGFja19kaXJlY3Rpb24gKCkKPiAtewo+IC0gIHN0YXRpYyBjaGFyICph
ZGRyID0gMDsKPiAtICBhdXRvIGNoYXIgZHVtbXk7Cj4gLSAgaWYgKGFkZHIgPT0gMCkKPiAtICAg
IHsKPiAtICAgICAgYWRkciA9ICZkdW1teTsKPiAtICAgICAgcmV0dXJuIGZpbmRfc3RhY2tfZGly
ZWN0aW9uICgpOwo+IC0gICAgfQo+IC0gIGVsc2UKPiAtICAgIHJldHVybiAoJmR1bW15ID4gYWRk
cikgPyAxIDogLTE7Cj4gLX0KPiArICBjYXNlICRCQ0MgaW4KPiArICBbXFwvXSogfCA/OltcXC9d
KikKPiArICBhY19jdl9wYXRoX0JDQz0iJEJDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElG
Uz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0
aF9CQ0M9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKPiArICAgIGJyZWFrIDIKPiArICBmaQo+ICtkb25lCj4gKyAgZG9uZQo+ICtJRlM9
JGFzX3NhdmVfSUZTCj4gCj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtICByZXR1cm4gZmluZF9z
dGFja19kaXJlY3Rpb24gKCkgPCAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9y
dW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0xCj4gLWVs
c2UKPiAtICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0tMQo+IC1maQo+IC1ybSAtZiBjb3JlICou
Y29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBc
Cj4gLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQK
PiArICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQ0MiICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKPiAr
ICA7Owo+ICtlc2FjCj4gIGZpCj4gLQo+ICtCQ0M9JGFjX2N2X3BhdGhfQkNDCj4gK2lmIHRlc3Qg
LW4gIiRCQ0MiOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRCQ0MiID4mNQo+ICskYXNfZWNobyAiJEJDQyIgPiY2OyB9Cj4gK2Vsc2UK
PiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+
JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY2OyB9Cj4gLWNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBTVEFDS19ESVJFQ1RJT04gJGFjX2N2X2Nf
c3RhY2tfZGlyZWN0aW9uCj4gLV9BQ0VPRgo+IAo+IAo+ICtpZiB0ZXN0IHgiJHtCQ0N9IiA9PSB4
Im5vIgo+ICt0aGVuCj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmNjLCBw
bGVhc2UgaW5zdGFsbCBiY2MiICIkTElORU5PIiA1Cj4gIGZpCj4gKyMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiaWFzbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Cj4gK3NldCBkdW1teSBpYXNsOyBhY193b3JkPSQyCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiArJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cGF0aF9JQVNMK3NldH0iID0gc2V0OyB0aGVuIDoKPiArICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgo+ICtlbHNlCj4gKyAgY2FzZSAkSUFTTCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+
ICsgIGFjX2N2X3BhdGhfSUFTTD0iJElBU0wiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgo+ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiArICBJRlM9
JGFzX3NhdmVfSUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiArICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICsgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2X3BhdGhf
SUFTTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0k
YXNfc2F2ZV9JRlMKPiAKPiAtZm9yIGFjX2hlYWRlciBpbiAgXAo+IC0gICAgICAgICAgICAgICAg
YXJwYS9pbmV0LmggZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2Mu
aCBcCj4gLSAgICAgICAgICAgICAgICBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRp
bnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCj4gLSAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lz
L2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCj4gLSAgICAgICAg
ICAgICAgICBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRl
cm1pb3MuaCBcCj4gLSAgICAgICAgICAgICAgICB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5o
IFwKPiArICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5v
Igo+ICsgIDs7Cj4gK2VzYWMKPiArZmkKPiArSUFTTD0kYWNfY3ZfcGF0aF9JQVNMCj4gK2lmIHRl
c3QgLW4gIiRJQVNMIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkSUFTTCIgPiY1Cj4gKyRhc19lY2hvICIkSUFTTCIgPiY2OyB9Cj4g
K2Vsc2UKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICtmaQo+IAo+IC1kbyA6Cj4gLSAg
YXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3Ry
X3NoYAo+IC1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiJGFjX2hlYWRl
ciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgZXZhbCB0ZXN0
IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAk
YXNfdHJfY3BwYCAxCj4gLV9BQ0VPRgo+IAo+ICtpZiB0ZXN0IHgiJHtJQVNMfSIgPT0geCJubyIK
PiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGlhc2wsIHBsZWFz
ZSBpbnN0YWxsIGlhc2wiICIkTElORU5PIiA1Cj4gIGZpCj4gCj4gLWRvbmUKPiAtCj4gK2FjX2Zu
X2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJ1dWlkL3V1aWQuaCIgImFjX2N2X2hl
YWRlcl91dWlkX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+ICtpZiB0ZXN0ICJ4JGFj
X2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC0jIENoZWNrcyBm
b3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0
ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5OSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0byBDOTkuLi4gIiA+JjY7IH0KPiAtaWYgdGVz
dCAiJHthY19jdl9oZWFkZXJfc3RkYm9vbF9oK3NldH0iID0gc2V0OyB0aGVuIDoKPiArICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1aWRf
Y2xlYXIgaW4gLWx1dWlkIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHV1aWRfY2xl
YXIgaW4gLWx1dWlkLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3V1aWRfdXVp
ZF9jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKPiAgZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKPiArICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4gK0xJQlM9Ii1sdXVpZCAgJExJ
QlMiCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyog
ZW5kIGNvbmZkZWZzLmguICAqLwo+IAo+IC0jaW5jbHVkZSA8c3RkYm9vbC5oPgo+IC0jaWZuZGVm
IGJvb2wKPiAtICJlcnJvcjogYm9vbCBpcyBub3QgZGVmaW5lZCIKPiAtI2VuZGlmCj4gLSNpZm5k
ZWYgZmFsc2UKPiAtICJlcnJvcjogZmFsc2UgaXMgbm90IGRlZmluZWQiCj4gLSNlbmRpZgo+IC0j
aWYgZmFsc2UKPiAtICJlcnJvcjogZmFsc2UgaXMgbm90IDAiCj4gLSNlbmRpZgo+IC0jaWZuZGVm
IHRydWUKPiAtICJlcnJvcjogdHJ1ZSBpcyBub3QgZGVmaW5lZCIKPiAtI2VuZGlmCj4gLSNpZiB0
cnVlICE9IDEKPiAtICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIKPiAtI2VuZGlmCj4gLSNpZm5kZWYg
X19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQKPiAtICJlcnJvcjogX19ib29sX3RydWVfZmFs
c2VfYXJlX2RlZmluZWQgaXMgbm90IGRlZmluZWQiCj4gKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50
ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2UgY2hhciBiZWNhdXNl
IGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiArICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAr
I2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiAgI2VuZGlmCj4gLQo+IC0gICAgICAg
c3RydWN0IHMgeyBfQm9vbCBzOiAxOyBfQm9vbCB0OyB9IHM7Cj4gLQo+IC0gICAgICAgY2hhciBh
W3RydWUgPT0gMSA/IDEgOiAtMV07Cj4gLSAgICAgICBjaGFyIGJbZmFsc2UgPT0gMCA/IDEgOiAt
MV07Cj4gLSAgICAgICBjaGFyIGNbX19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQgPT0gMSA/
IDEgOiAtMV07Cj4gLSAgICAgICBjaGFyIGRbKGJvb2wpIDAuNSA9PSB0cnVlID8gMSA6IC0xXTsK
PiAtICAgICAgIGJvb2wgZSA9ICZzOwo+IC0gICAgICAgY2hhciBmWyhfQm9vbCkgMC4wID09IGZh
bHNlID8gMSA6IC0xXTsKPiAtICAgICAgIGNoYXIgZ1t0cnVlXTsKPiAtICAgICAgIGNoYXIgaFtz
aXplb2YgKF9Cb29sKV07Cj4gLSAgICAgICBjaGFyIGlbc2l6ZW9mIHMudF07Cj4gLSAgICAgICBl
bnVtIHsgaiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAy
NTYgfTsKPiAtICAgICAgIC8qIFRoZSBmb2xsb3dpbmcgZmFpbHMgZm9yCj4gLSAgICAgICAgICBI
UCBhQysrL0FOU0kgQyBCMzkxMEIgQS4wNS41NSBbRGVjIDA0IDIwMDNdLiAqLwo+IC0gICAgICAg
X0Jvb2wgblttXTsKPiAtICAgICAgIGNoYXIgb1tzaXplb2YgbiA9PSBtICogc2l6ZW9mIG5bMF0g
PyAxIDogLTFdOwo+IC0gICAgICAgY2hhciBwWy0xIC0gKF9Cb29sKSAwIDwgMCAmJiAtMSAtIChi
b29sKSAwIDwgMCA/IDEgOiAtMV07Cj4gLSMgICAgICBpZiBkZWZpbmVkIF9feGxjX18gfHwgZGVm
aW5lZCBfX0dOVUNfXwo+IC0gICAgICAgIC8qIENhdGNoIGEgYnVnIGluIElCTSBBSVggeGxjIGNv
bXBpbGVyIHZlcnNpb24gNi4wLjAuMAo+IC0gICAgICAgICAgIHJlcG9ydGVkIGJ5IEphbWVzIExl
bWxleSBvbiAyMDA1LTEwLTA1OyBzZWUKPiAtICAgICAgICAgICBodHRwOi8vbGlzdHMuZ251Lm9y
Zy9hcmNoaXZlL2h0bWwvYnVnLWNvcmV1dGlscy8yMDA1LTEwL21zZzAwMDg2Lmh0bWwKPiAtICAg
ICAgICAgICBUaGlzIHRlc3QgaXMgbm90IHF1aXRlIHJpZ2h0LCBzaW5jZSB4bGMgaXMgYWxsb3dl
ZCB0bwo+IC0gICAgICAgICAgIHJlamVjdCB0aGlzIHByb2dyYW0sIGFzIHRoZSBpbml0aWFsaXpl
ciBmb3IgeGxjYnVnIGlzCj4gLSAgICAgICAgICAgbm90IG9uZSBvZiB0aGUgZm9ybXMgdGhhdCBD
IHJlcXVpcmVzIHN1cHBvcnQgZm9yLgo+IC0gICAgICAgICAgIEhvd2V2ZXIsIGRvaW5nIHRoZSB0
ZXN0IHJpZ2h0IHdvdWxkIHJlcXVpcmUgYSBydW50aW1lCj4gLSAgICAgICAgICAgdGVzdCwgYW5k
IHRoYXQgd291bGQgbWFrZSBjcm9zcy1jb21waWxhdGlvbiBoYXJkZXIuCj4gLSAgICAgICAgICAg
TGV0IHVzIGhvcGUgdGhhdCBJQk0gZml4ZXMgdGhlIHhsYyBidWcsIGFuZCBhbHNvIGFkZHMKPiAt
ICAgICAgICAgICBzdXBwb3J0IGZvciB0aGlzIGtpbmQgb2YgY29uc3RhbnQgZXhwcmVzc2lvbi4g
IEluIHRoZQo+IC0gICAgICAgICAgIG1lYW50aW1lLCB0aGlzIHRlc3Qgd2lsbCByZWplY3QgeGxj
LCB3aGljaCBpcyBPSywgc2luY2UKPiAtICAgICAgICAgICBvdXIgc3RkYm9vbC5oIHN1YnN0aXR1
dGUgc2hvdWxkIHN1ZmZpY2UuICBXZSBhbHNvIHRlc3QKPiAtICAgICAgICAgICB0aGlzIHdpdGgg
R0NDLCB3aGVyZSBpdCBzaG91bGQgd29yaywgdG8gZGV0ZWN0IG1vcmUKPiAtICAgICAgICAgICBx
dWlja2x5IHdoZXRoZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRlc3QgaW4gdGhlCj4gLSAgICAg
ICAgICAgZnV0dXJlLiAgKi8KPiAtICAgICAgICBjaGFyIGRpZ3NbXSA9ICIwMTIzNDU2Nzg5IjsK
PiAtICAgICAgICBpbnQgeGxjYnVnID0gMSAvICgmKGRpZ3MgKyA1KVstMiArIChib29sKSAxXSA9
PSAmZGlnc1s0XSA/IDEgOiAtMSk7Cj4gLSMgICAgICBlbmRpZgo+IC0gICAgICAgLyogQ2F0Y2gg
YSBidWcgaW4gYW4gSFAtVVggQyBjb21waWxlci4gIFNlZQo+IC0gICAgICAgICAgaHR0cDovL2dj
Yy5nbnUub3JnL21sL2djYy1wYXRjaGVzLzIwMDMtMTIvbXNnMDIzMDMuaHRtbAo+IC0gICAgICAg
ICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0x
MS9tc2cwMDE2MS5odG1sCj4gLSAgICAgICAgKi8KPiAtICAgICAgIF9Cb29sIHEgPSB0cnVlOwo+
IC0gICAgICAgX0Jvb2wgKnBxID0gJnE7Cj4gLQo+ICtjaGFyIHV1aWRfY2xlYXIgKCk7Cj4gIGlu
dAo+ICBtYWluICgpCj4gIHsKPiAtCj4gLSAgICAgICAqcHEgfD0gcTsKPiAtICAgICAgICpwcSB8
PSAhIHE7Cj4gLSAgICAgICAvKiBSZWZlciB0byBldmVyeSBkZWNsYXJlZCB2YWx1ZSwgdG8gYXZv
aWQgY29tcGlsZXIgb3B0aW1pemF0aW9ucy4gICovCj4gLSAgICAgICByZXR1cm4gKCFhICsgIWIg
KyAhYyArICFkICsgIWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCj4gLSAg
ICAgICAgICAgICAgICsgIW0gKyAhbiArICFvICsgIXAgKyAhcSArICFwcSk7Cj4gLQo+ICtyZXR1
cm4gdXVpZF9jbGVhciAoKTsKPiAgICA7Cj4gICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4g
LWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9oZWFk
ZXJfc3RkYm9vbF9oPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaD1ubwo+
IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjUKPiAtJGFzX2VjaG8gIiRh
Y19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjY7IH0KPiAtYWNfZm5fY19jaGVja190eXBlICIkTElO
RU5PIiAiX0Jvb2wiICJhY19jdl90eXBlX19Cb29sIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4g
LWlmIHRlc3QgIngkYWNfY3ZfdHlwZV9fQm9vbCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVfX0JPT0wgMQo+IC1fQUNFT0YK
PiAtCj4gLQo+IC1maQo+IC0KPiAtaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCA9IHll
czsgdGhlbgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9TVERCT09MX0ggMSIgPj5jb25m
ZGVmcy5oCj4gLQo+IC1maQo+IC0KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgiID4mNQo+IC0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmguLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl90eXBlX3VpZF90K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRl
IDxzeXMvdHlwZXMuaD4KPiAtCj4gLV9BQ0VPRgo+IC1pZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVz
dC4kYWNfZXh0IikgMj4mNSB8Cj4gLSAgJEVHUkVQICJ1aWRfdCIgPi9kZXYvbnVsbCAyPiYxOyB0
aGVuIDoKPiAtICBhY19jdl90eXBlX3VpZF90PXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfdHlwZV91
aWRfdD1ubwo+IC1maQo+IC1ybSAtZiBjb25mdGVzdCoKPiAtCj4gLWZpCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIg
PiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfdHlwZV91aWRfdCIgPiY2OyB9Cj4gLWlmIHRlc3QgJGFj
X2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgdWlkX3Qg
aW50IiA+PmNvbmZkZWZzLmgKPiAtCj4gLQo+IC0kYXNfZWNobyAiI2RlZmluZSBnaWRfdCBpbnQi
ID4+Y29uZmRlZnMuaAo+IC0KPiAtZmkKPiAtCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9jX2lubGlu
ZStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAt
ZWxzZQo+IC0gIGFjX2N2X2NfaW5saW5lPW5vCj4gLWZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxp
bmVfXyBfX2lubGluZTsgZG8KPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2lmbmRlZiBfX2NwbHVzcGx1
cwo+IC10eXBlZGVmIGludCBmb29fdDsKPiAtc3RhdGljICRhY19rdyBmb29fdCBzdGF0aWNfZm9v
ICgpIHtyZXR1cm4gMDsgfQo+IC0kYWNfa3cgZm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQo+IC0j
ZW5kaWYKPiAtCj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Cj4gLSAgYWNfY3ZfY19pbmxpbmU9JGFjX2t3Cj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsg
IiRMSU5FTk8iOyB0aGVuIDoKPiArICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPXllcwo+ICtl
bHNlCj4gKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj1ubwo+ICBmaQo+IC1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICB0
ZXN0ICIkYWNfY3ZfY19pbmxpbmUiICE9IG5vICYmIGJyZWFrCj4gLWRvbmUKPiAtCj4gK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29uZnRlc3Qk
YWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElC
Uwo+ICtmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xp
Yl91dWlkX3V1aWRfY2xlYXIiID4mNjsgfQo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2xpYl91dWlkX3V1
aWRfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKPiArICBsaWJ1dWlkPSJ5Igo+ICBmaQo+IC17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfaW5s
aW5lIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2OyB9Cj4gCj4gLWNhc2Ug
JGFjX2N2X2NfaW5saW5lIGluCj4gLSAgaW5saW5lIHwgeWVzKSA7Owo+IC0gICopCj4gLSAgICBj
YXNlICRhY19jdl9jX2lubGluZSBpbgo+IC0gICAgICBubykgYWNfdmFsPTs7Cj4gLSAgICAgICop
IGFjX3ZhbD0kYWNfY3ZfY19pbmxpbmU7Owo+IC0gICAgZXNhYwo+IC0gICAgY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgo+IC0jaWZuZGVmIF9fY3BsdXNwbHVzCj4gLSNkZWZpbmUgaW5saW5lICRh
Y192YWwKPiAtI2VuZGlmCj4gLV9BQ0VPRgo+IC0gICAgOzsKPiAtZXNhYwo+IAo+IC1hY19mbl9j
X2ZpbmRfaW50WF90ICIkTElORU5PIiAiMTYiICJhY19jdl9jX2ludDE2X3QiCj4gLWNhc2UgJGFj
X2N2X2NfaW50MTZfdCBpbiAjKAo+IC0gIG5vfHllcykgOzsgIygKPiAtICAqKQo+ICtmaQo+IAo+
IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgaW50MTZfdCAkYWNfY3ZfY19p
bnQxNl90Cj4gLV9BQ0VPRgo+IC07Owo+IC1lc2FjCj4gCj4gLWFjX2ZuX2NfZmluZF9pbnRYX3Qg
IiRMSU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKPiAtY2FzZSAkYWNfY3ZfY19pbnQzMl90
IGluICMoCj4gLSAgbm98eWVzKSA7OyAjKAo+IC0gICopCj4gK2FjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJ1dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF9oIiAiJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQiCj4gK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5
ZXM7IHRoZW4gOgo+ICsgIGxpYnV1aWQ9InkiCj4gK2ZpCj4gCj4gLWNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKPiAtI2RlZmluZSBpbnQzMl90ICRhY19jdl9jX2ludDMyX3QKPiAtX0FDRU9GCj4g
LTs7Cj4gLWVzYWMKPiAKPiAtYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjY0IiAiYWNf
Y3ZfY19pbnQ2NF90Igo+IC1jYXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKPiAtICBub3x5ZXMp
IDs7ICMoCj4gLSAgKikKPiAraWYgdGVzdCAiJGxpYnV1aWQiICE9ICJ5IjsgdGhlbiA6Cj4gCj4g
LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBpbnQ2NF90ICRhY19jdl9jX2lu
dDY0X3QKPiAtX0FDRU9GCj4gLTs7Cj4gLWVzYWMKPiArICAgIGFzX2ZuX2Vycm9yICQ/ICJjYW5u
b3QgZmluZCBhIHZhbGlkIHV1aWQgbGlicmFyeSIgIiRMSU5FTk8iIDUKPiAKPiAtYWNfZm5fY19m
aW5kX2ludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX2ludDhfdCIKPiAtY2FzZSAkYWNfY3Zf
Y19pbnQ4X3QgaW4gIygKPiAtICBub3x5ZXMpIDs7ICMoCj4gLSAgKikKPiArZmkKPiAKPiAtY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIGludDhfdCAkYWNfY3ZfY19pbnQ4X3QK
PiAtX0FDRU9GCj4gLTs7Cj4gLWVzYWMKPiAKPiAtYWNfZm5fY19jaGVja190eXBlICIkTElORU5P
IiAibW9kZV90IiAiYWNfY3ZfdHlwZV9tb2RlX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAt
aWYgdGVzdCAieCRhY19jdl90eXBlX21vZGVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICthY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJf
Y3Vyc2VzX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAraWYgdGVzdCAieCRhY19jdl9oZWFk
ZXJfY3Vyc2VzX2giID0geCIieWVzOyB0aGVuIDoKPiAKPiArICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vyc2VzIiA+
JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vyc2VzLi4uICIgPiY2
OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2N1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhl
biA6Cj4gKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+ICsgIGFjX2NoZWNr
X2xpYl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxjdXJzZXMgICRMSUJTIgo+ICtjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KPiAKPiAtY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIG1vZGVfdCBp
bnQKPiArLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4g
ZXJyb3IuCj4gKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4g
dHlwZSBvZiBhIEdDQwo+ICsgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5
cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwo+ICsjaWZkZWYgX19jcGx1c3BsdXMKPiArZXh0ZXJu
ICJDIgo+ICsjZW5kaWYKPiArY2hhciBjbGVhciAoKTsKPiAraW50Cj4gK21haW4gKCkKPiArewo+
ICtyZXR1cm4gY2xlYXIgKCk7Cj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4gIF9BQ0VPRgo+
IC0KPiAraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xp
Yl9jdXJzZXNfY2xlYXI9eWVzCj4gK2Vsc2UKPiArICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPW5v
Cj4gIGZpCj4gLQo+IC1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2
X3R5cGVfb2ZmX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl90
eXBlX29mZl90IiA9IHgiInllczsgdGhlbiA6Cj4gLQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKPiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0Cj4gK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKPiArZmkKPiAreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3Vy
c2VzX2NsZWFyIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA+JjY7
IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA9IHgiInllczsgdGhlbiA6
Cj4gKyAgY3Vyc2VzPSJ5Igo+ICBlbHNlCj4gLQo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
Cj4gLSNkZWZpbmUgb2ZmX3QgbG9uZyBpbnQKPiAtX0FDRU9GCj4gLQo+ICsgIGN1cnNlcz0ibiIK
PiAgZmkKPiAKPiAtYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAicGlkX3QiICJhY19jdl90
eXBlX3BpZF90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfdHlw
ZV9waWRfdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+ICBlbHNlCj4gKyAgY3Vyc2VzPSJuIgo+ICtm
aQo+IAo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgcGlkX3QgaW50Cj4g
LV9BQ0VPRgo+IAo+IC1maQo+ICthY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5P
IiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0Igo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giID0geCIieWVzOyB0aGVu
IDoKPiAKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciBDL0MrKyByZXN0cmljdCBrZXl3b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfY19yZXN0cmljdCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMi
ID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzLi4uICIg
PiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7
IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBhY19j
dl9jX3Jlc3RyaWN0PW5vCj4gLSAgICMgVGhlIG9yZGVyIGhlcmUgY2F0ZXJzIHRvIHRoZSBmYWN0
IHRoYXQgQysrIGRvZXMgbm90IHJlcXVpcmUgcmVzdHJpY3QuCj4gLSAgIGZvciBhY19rdyBpbiBf
X3Jlc3RyaWN0IF9fcmVzdHJpY3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7IGRvCj4gLSAgICAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsgIGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxuY3Vyc2VzICAkTElCUyIKPiArY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICAvKiBlbmQgY29uZmRlZnMuaC4g
ICovCj4gLXR5cGVkZWYgaW50ICogaW50X3B0cjsKPiAtICAgICAgIGludCBmb28gKGludF9wdHIg
JGFjX2t3IGlwKSB7Cj4gLSAgICAgICByZXR1cm4gaXBbMF07Cj4gLSAgICAgICB9Cj4gKwo+ICsv
KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K
PiArICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m
IGEgR0NDCj4gKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3Vs
ZCBzdGlsbCBhcHBseS4gICovCj4gKyNpZmRlZiBfX2NwbHVzcGx1cwo+ICtleHRlcm4gIkMiCj4g
KyNlbmRpZgo+ICtjaGFyIGNsZWFyICgpOwo+ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLWludCBz
WzFdOwo+IC0gICAgICAgaW50ICogJGFjX2t3IHQgPSBzOwo+IC0gICAgICAgdFswXSA9IDA7Cj4g
LSAgICAgICByZXR1cm4gZm9vKHQpCj4gK3JldHVybiBjbGVhciAoKTsKPiAgICA7Cj4gICAgcmV0
dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKPiAtICBhY19jdl9jX3Jlc3RyaWN0PSRhY19rdwo+ICtpZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9eWVzCj4g
K2Vsc2UKPiArICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj1ubwo+ICBmaQo+IC1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICAg
ICB0ZXN0ICIkYWNfY3ZfY19yZXN0cmljdCIgIT0gbm8gJiYgYnJlYWsKPiAtICAgZG9uZQo+IC0K
PiArcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gKyAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICtMSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfY19yZXN0cmljdCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfY19y
ZXN0cmljdCIgPiY2OyB9Cj4gLQo+IC0gY2FzZSAkYWNfY3ZfY19yZXN0cmljdCBpbgo+IC0gICBy
ZXN0cmljdCkgOzsKPiAtICAgbm8pICRhc19lY2hvICIjZGVmaW5lIHJlc3RyaWN0IC8qKi8iID4+
Y29uZmRlZnMuaAo+IC0gOzsKPiAtICAgKikgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAt
I2RlZmluZSByZXN0cmljdCAkYWNfY3ZfY19yZXN0cmljdAo+IC1fQUNFT0YKPiAtIDs7Cj4gLSBl
c2FjCj4gLQo+IC1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzaXplX3QiICJhY19jdl90
eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X3R5
cGVfc2l6ZV90IiA9IHgiInllczsgdGhlbiA6Cj4gLQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjUK
PiArJGFzX2VjaG8gIiRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPiY2OyB9Cj4gK2lmIHRlc3Qg
IngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKPiArICBuY3Vyc2Vz
PSJ5Igo+ICBlbHNlCj4gLQo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUg
c2l6ZV90IHVuc2lnbmVkIGludAo+IC1fQUNFT0YKPiAtCj4gKyAgbmN1cnNlcz0ibiIKPiAgZmkK
PiAKPiAtYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic3NpemVfdCIgImFjX2N2X3R5cGVf
c3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
c3NpemVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+ICBlbHNlCj4gLQo+IC1jYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgc3NpemVfdCBpbnQKPiAtX0FDRU9GCj4gLQo+ICsgIG5j
dXJzZXM9Im4iCj4gIGZpCj4gCj4gLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3Ry
dWN0IHN0YXQiICJzdF9ibGtzaXplIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsa3Np
emUiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3Ry
dWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC1jYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFIDEKPiAt
X0FDRU9GCj4gK2lmIHRlc3QgIiRjdXJzZXMiID0gIm4iICYmIHRlc3QgIiRuY3Vyc2VzIiA9ICJu
IjsgdGhlbiA6Cj4gCj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYSBzdWl0
YWJsZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5FTk8iIDUKPiAKPiAgZmkKPiArIyBQcmVmZXIgbmN1
cnNlcyBvdmVyIGN1cnNlcyBpZiBib3RoIGFyZSBwcmVzZW50Cj4gK2lmIHRlc3QgIiRuY3Vyc2Vz
IiA9ICJ5IjsgdGhlbiA6Cj4gCj4gLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3Ry
dWN0IHN0YXQiICJzdF9ibG9ja3MiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tz
IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVj
dF9zdGF0X3N0X2Jsb2NrcyIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTIDEKPiAtX0FD
RU9GCj4gKyAgICBDVVJTRVNfTElCUz0iLWxuY3Vyc2VzIgo+IAo+ICskYXNfZWNobyAiI2RlZmlu
ZSBJTkNMVURFX0NVUlNFU19IIDxuY3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKPiAKPiAtJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9TVF9CTE9DS1MgMSIgPj5jb25mZGVmcy5oCj4gCj4gIGVsc2UKPiAt
ICBjYXNlICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiAp
IDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9CSlMgZmlsZWJsb2Nrcy4kYWNfb2JqZXh0Igo+IC0g
OzsKPiAtZXNhYwo+IC0KPiAtZmkKPiAtCj4gCj4gLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElO
RU5PIiAic3RydWN0IHN0YXQiICJzdF9yZGV2IiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0
X3JkZXYiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9tZW1iZXJf
c3RydWN0X3N0YXRfc3RfcmRldiIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsgICAgQ1VSU0VTX0xJQlM9
Ii1sY3Vyc2VzIgo+IAo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgSEFW
RV9TVFJVQ1RfU1RBVF9TVF9SREVWIDEKPiAtX0FDRU9GCj4gKyRhc19lY2hvICIjZGVmaW5lIElO
Q0xVREVfQ1VSU0VTX0ggPGN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCj4gCj4gCj4gIGZpCj4gCj4g
LWFjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiMTYiICJhY19jdl9jX3VpbnQxNl90Igo+
IC1jYXNlICRhY19jdl9jX3VpbnQxNl90IGluICMoCj4gLSAgbm98eWVzKSA7OyAjKAo+IC0gICop
Cj4gCj4gCj4gLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSB1aW50MTZfdCAk
YWNfY3ZfY191aW50MTZfdAo+IC1fQUNFT0YKPiAtOzsKPiAtICBlc2FjCj4gCj4gLWFjX2ZuX2Nf
ZmluZF91aW50WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX3VpbnQzMl90Igo+IC1jYXNlICRh
Y19jdl9jX3VpbnQzMl90IGluICMoCj4gLSAgbm98eWVzKSA7OyAjKAo+IC0gICopCj4gCj4gLSRh
c19lY2hvICIjZGVmaW5lIF9VSU5UMzJfVCAxIiA+PmNvbmZkZWZzLmgKPiAKPiAKPiAtY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIHVpbnQzMl90ICRhY19jdl9jX3VpbnQzMl90
Cj4gLV9BQ0VPRgo+IC07Owo+IC0gIGVzYWMKPiAKPiAtYWNfZm5fY19maW5kX3VpbnRYX3QgIiRM
SU5FTk8iICI2NCIgImFjX2N2X2NfdWludDY0X3QiCj4gLWNhc2UgJGFjX2N2X2NfdWludDY0X3Qg
aW4gIygKPiAtICBub3x5ZXMpIDs7ICMoCj4gK2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05G
SUdfc2V0IiAhPSAieHNldCI7IHRoZW4KPiArICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9w
cmVmaXh9cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Cj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25maWc7IGFjX3dvcmQ9JDIKPiAr
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4g
Ogo+ICsgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBjYXNlICRQS0df
Q09ORklHIGluCj4gKyAgW1xcL10qIHwgPzpbXFwvXSopCj4gKyAgYWNfY3ZfcGF0aF9QS0dfQ09O
RklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCj4gKyAgOzsKPiAgICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9J
RlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0aF9QS0dfQ09ORklH
PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiArSUZTPSRhc19z
YXZlX0lGUwo+IAo+IC0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDY0X1QgMSIgPj5jb25mZGVmcy5o
Cj4gLQo+ICsgIDs7Cj4gK2VzYWMKPiArZmkKPiArUEtHX0NPTkZJRz0kYWNfY3ZfcGF0aF9QS0df
Q09ORklHCj4gK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1Cj4g
KyRhc19lY2hvICIkUEtHX0NPTkZJRyIgPiY2OyB9Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAi
bm8iID4mNjsgfQo+ICtmaQo+IAo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZp
bmUgdWludDY0X3QgJGFjX2N2X2NfdWludDY0X3QKPiAtX0FDRU9GCj4gLTs7Cj4gLSAgZXNhYwo+
IAo+IC1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX3VpbnQ4X3Qi
Cj4gLWNhc2UgJGFjX2N2X2NfdWludDhfdCBpbiAjKAo+IC0gIG5vfHllcykgOzsgIygKPiArZmkK
PiAraWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRoZW4KPiArICBhY19wdF9Q
S0dfQ09ORklHPSRQS0dfQ09ORklHCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJw
a2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0
IGR1bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9w
YXRoX2FjX3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCj4g
KyAgW1xcL10qIHwgPzpbXFwvXSopCj4gKyAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIk
YWNfcHRfUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCj4gKyAgOzsKPiAgICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9J
RlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0aF9hY19wdF9QS0df
Q09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiArSUZT
PSRhc19zYXZlX0lGUwo+IAo+IC0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDhfVCAxIiA+PmNvbmZk
ZWZzLmgKPiAtCj4gLQo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgdWlu
dDhfdCAkYWNfY3ZfY191aW50OF90Cj4gLV9BQ0VPRgo+IC07Owo+IC0gIGVzYWMKPiAtCj4gLWFj
X2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVfcHRyZGlm
Zl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfdHlwZV9wdHJk
aWZmX3QiID0geCIieWVzOyB0aGVuIDoKPiAtCj4gLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
PiAtI2RlZmluZSBIQVZFX1BUUkRJRkZfVCAxCj4gLV9BQ0VPRgo+IC0KPiAtCj4gKyAgOzsKPiAr
ZXNhYwo+ICtmaQo+ICthY19wdF9QS0dfQ09ORklHPSRhY19jdl9wYXRoX2FjX3B0X1BLR19DT05G
SUcKPiAraWYgdGVzdCAtbiAiJGFjX3B0X1BLR19DT05GSUciOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19wdF9QS0dfQ09ORklH
IiA+JjUKPiArJGFzX2VjaG8gIiRhY19wdF9QS0dfQ09ORklHIiA+JjY7IH0KPiArZWxzZQo+ICsg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC0jIENoZWNrcyBmb3IgbGli
cmFyeSBmdW5jdGlvbnMuCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIGVycm9yX2F0X2xpbmUiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2xpYl9l
cnJvcl9hdF9saW5lK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgo+IC1lbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRlIDxlcnJvci5oPgo+
IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLWVycm9yX2F0X2xpbmUgKDAsIDAsICIiLCAwLCAiYW4g
ZXJyb3Igb2NjdXJyZWQiKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4g
LWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9saWJfZXJy
b3JfYXRfbGluZT15ZXMKPiArICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05GSUciID0geDsgdGhl
bgo+ICsgICAgUEtHX0NPTkZJRz0iIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBp
bGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4g
K2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtlc2FjCj4gKyAgICBQS0dfQ09ORklHPSRhY19wdF9Q
S0dfQ09ORklHCj4gKyAgZmkKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPW5v
Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+
IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArICBQS0dfQ09ORklH
PSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjUK
PiAtJGFzX2VjaG8gIiRhY19jdl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9Cj4gLWlmIHRlc3Qg
JGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lID0gbm87IHRoZW4KPiAtICBjYXNlICIgJExJQk9CSlMg
IiBpbgo+IC0gICoiIGVycm9yLiRhY19vYmpleHQgIiogKSA7Owo+IC0gICopIExJQk9CSlM9IiRM
SUJPQkpTIGVycm9yLiRhY19vYmpleHQiCj4gLSA7Owo+IC1lc2FjCj4gCj4gIGZpCj4gLQo+IC1m
b3IgYWNfaGVhZGVyIGluIHZmb3JrLmgKPiAtZG8gOgo+IC0gIGFjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJ2Zm9yay5oIiAiYWNfY3ZfaGVhZGVyX3Zmb3JrX2giICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdmZvcmtfaCIgPSB4
IiJ5ZXM7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBI
QVZFX1ZGT1JLX0ggMQo+IC1fQUNFT0YKPiAtCj4gK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsg
dGhlbgo+ICsgICAgICAgX3BrZ19taW5fdmVyc2lvbj0wLjkuMAo+ICsgICAgICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0
IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQo+ICskYXNfZWNob19uICJjaGVj
a2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24uLi4g
IiA+JjY7IH0KPiArICAgICAgIGlmICRQS0dfQ09ORklHIC0tYXRsZWFzdC1wa2djb25maWctdmVy
c2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgo+ICsgICAgICAgICAgICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2Vj
aG8gInllcyIgPiY2OyB9Cj4gKyAgICAgICBlbHNlCj4gKyAgICAgICAgICAgICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19l
Y2hvICJubyIgPiY2OyB9Cj4gKyAgICAgICAgICAgICAgIFBLR19DT05GSUc9IiIKPiArICAgICAg
IGZpCj4gIGZpCj4gCj4gLWRvbmUKPiAtCj4gLWZvciBhY19mdW5jIGluIGZvcmsgdmZvcmsKPiAt
ZG8gOgo+IC0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFz
X3RyX3NoYAo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19h
Y192YXIiCj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVu
IDoKPiAtICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgYCRhc19lY2hvICJI
QVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKPiAtX0FDRU9GCj4gLQo+IC1maQo+IC1kb25l
Cj4gK3BrZ19mYWlsZWQ9bm8KPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgZ2xpYiIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBn
bGliLi4uICIgPiY2OyB9Cj4gCj4gLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrIiA9IHh5ZXM7
IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciB3b3JraW5nIGZvcmsiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29y
a2luZyBmb3JrLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19mb3JrX3dvcmtz
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1l
bHNlCj4gLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFj
X2N2X2Z1bmNfZm9ya193b3Jrcz1jcm9zcwo+ICtpZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0
aGVuCj4gKyAgICBwa2dfY3ZfZ2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIKPiArIGVsaWYgdGVz
dCAtbiAiJFBLR19DT05GSUciOyB0aGVuCj4gKyAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIg
JiYgXAo+ICsgICAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwk
UEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9ID4mNQo+
ICsgICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1
Cj4gKyAgYWNfc3RhdHVzPSQ/Cj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsg
dGhlbgo+ICsgIHBrZ19jdl9nbGliX0NGTEFHUz1gJFBLR19DT05GSUcgLS1jZmxhZ3MgImdsaWIt
Mi4wIiAyPi9kZXYvbnVsbGAKPiAgZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVk
ZXNfZGVmYXVsdAo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLQo+IC0gICAgICAgICAvKiBCeSBS
dWVkaWdlciBLdWhsbWFubi4gKi8KPiAtICAgICAgICAgcmV0dXJuIGZvcmsgKCkgPCAwOwo+IC0K
PiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKPiArICBw
a2dfZmFpbGVkPXllcwo+ICtmaQo+ICsgZWxzZQo+ICsgICAgcGtnX2ZhaWxlZD11bnRyaWVkCj4g
K2ZpCj4gK2lmIHRlc3QgLW4gIiRnbGliX0xJQlMiOyB0aGVuCj4gKyAgICBwa2dfY3ZfZ2xpYl9M
SUJTPSIkZ2xpYl9MSUJTIgo+ICsgZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KPiAr
ICAgIGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCj4gKyAgICB7IHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQt
ZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1Cj4gKyAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0t
cHJpbnQtZXJyb3JzICJnbGliLTIuMCIpIDI+JjUKPiArICBhY19zdGF0dXM9JD8KPiArICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUK
PiArICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuCj4gKyAgcGtnX2N2X2dsaWJfTElCUz1g
JFBLR19DT05GSUcgLS1saWJzICJnbGliLTIuMCIgMj4vZGV2L251bGxgCj4gIGVsc2UKPiAtICBh
Y19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KPiArICBwa2dfZmFpbGVkPXllcwo+ICBmaQo+IC1ybSAt
ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBcCj4gLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0
LiRhY19leHQKPiArIGVsc2UKPiArICAgIHBrZ19mYWlsZWQ9dW50cmllZAo+ICBmaQo+IAo+IC1m
aQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2Z1bmNfZm9ya193b3JrcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVuY19mb3JrX3dv
cmtzIiA+JjY7IH0KPiAKPiArCj4gK2lmIHRlc3QgJHBrZ19mYWlsZWQgPSB5ZXM7IHRoZW4KPiAr
ICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gKwo+ICtpZiAkUEtHX0NPTkZJRyAtLWF0
bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgo+ICsgICAgICAgIF9wa2dfc2hvcnRf
ZXJyb3JzX3N1cHBvcnRlZD15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz0k
YWNfY3ZfZnVuY19mb3JrCj4gKyAgICAgICAgX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkPW5v
Cj4gIGZpCj4gLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhl
bgo+IC0gIGNhc2UgJGhvc3QgaW4KPiAtICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3Bw
KikKPiAtICAgICAgIyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZlIG9ubHkgYSBkdW1t
eSBmb3JrKCkgc3R1Ygo+IC0gICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KPiAtICAgICAg
OzsKPiAtICAgICopCj4gLSAgICAgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKPiAtICAgICAg
OzsKPiAtICBlc2FjCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ug
b2YgY3Jvc3MgY29tcGlsYXRpb24iID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBy
ZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29t
cGlsYXRpb24iID4mMjt9Cj4gLWZpCj4gLWFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1
bmNfdmZvcmsKPiAtaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrIiA9IHh5ZXM7IHRoZW4KPiAt
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3
b3JraW5nIHZmb3JrIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgdmZv
cmsuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9mdW5jX3Zmb3JrX3dvcmtzK3NldH0i
ID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4g
LSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3M9Y3Jvc3MKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0vKiBUaGFu
a3MgdG8gUGF1bCBFZ2dlcnQgZm9yIHRoaXMgdGVzdC4gICovCj4gLSRhY19pbmNsdWRlc19kZWZh
dWx0Cj4gLSNpbmNsdWRlIDxzeXMvd2FpdC5oPgo+IC0jaWZkZWYgSEFWRV9WRk9SS19ICj4gLSMg
aW5jbHVkZSA8dmZvcmsuaD4KPiAtI2VuZGlmCj4gLS8qIE9uIHNvbWUgc3BhcmMgc3lzdGVtcywg
Y2hhbmdlcyBieSB0aGUgY2hpbGQgdG8gbG9jYWwgYW5kIGluY29taW5nCj4gLSAgIGFyZ3VtZW50
IHJlZ2lzdGVycyBhcmUgcHJvcGFnYXRlZCBiYWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGls
ZXIKPiAtICAgaXMgdG9sZCBhYm91dCB0aGlzIHdpdGggI2luY2x1ZGUgPHZmb3JrLmg+LCBidXQg
c29tZSBjb21waWxlcnMKPiAtICAgKGUuZy4gZ2NjIC1PKSBkb24ndCBncm9rIDx2Zm9yay5oPi4g
IFRlc3QgZm9yIHRoaXMgYnkgdXNpbmcgYQo+IC0gICBzdGF0aWMgdmFyaWFibGUgd2hvc2UgYWRk
cmVzcyBpcyBwdXQgaW50byBhIHJlZ2lzdGVyIHRoYXQgaXMKPiAtICAgY2xvYmJlcmVkIGJ5IHRo
ZSB2Zm9yay4gICovCj4gLXN0YXRpYyB2b2lkCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1zcGFy
Y19hZGRyZXNzX3Rlc3QgKGludCBhcmcpCj4gLSMgZWxzZQo+IC1zcGFyY19hZGRyZXNzX3Rlc3Qg
KGFyZykgaW50IGFyZzsKPiAtI2VuZGlmCj4gLXsKPiAtICBzdGF0aWMgcGlkX3QgY2hpbGQ7Cj4g
LSAgaWYgKCFjaGlsZCkgewo+IC0gICAgY2hpbGQgPSB2Zm9yayAoKTsKPiAtICAgIGlmIChjaGls
ZCA8IDApIHsKPiAtICAgICAgcGVycm9yICgidmZvcmsiKTsKPiAtICAgICAgX2V4aXQoMik7Cj4g
LSAgICB9Cj4gLSAgICBpZiAoIWNoaWxkKSB7Cj4gLSAgICAgIGFyZyA9IGdldHBpZCgpOwo+IC0g
ICAgICB3cml0ZSgtMSwgIiIsIDApOwo+IC0gICAgICBfZXhpdCAoYXJnKTsKPiAtICAgIH0KPiAt
ICB9Cj4gLX0KPiArICAgICAgICBpZiB0ZXN0ICRfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQg
PSB5ZXM7IHRoZW4KPiArICAgICAgICAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJ
RyAtLXNob3J0LWVycm9ycyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCj4gKyAgICAg
ICAgZWxzZQo+ICsgICAgICAgICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0t
cHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKPiArICAgICAgICBmaQo+ICsgICAgICAgIyBQ
dXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdz
Cj4gKyAgICAgICBlY2hvICIkZ2xpYl9QS0dfRVJST1JTIiA+JjUKPiAKPiAtaW50Cj4gLW1haW4g
KCkKPiAtewo+IC0gIHBpZF90IHBhcmVudCA9IGdldHBpZCAoKTsKPiAtICBwaWRfdCBjaGlsZDsK
PiAtCj4gLSAgc3BhcmNfYWRkcmVzc190ZXN0ICgwKTsKPiAtCj4gLSAgY2hpbGQgPSB2Zm9yayAo
KTsKPiAtCj4gLSAgaWYgKGNoaWxkID09IDApIHsKPiAtICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0
ZXN0IGZvciBzcGFyYyB2Zm9yayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKPiAtICAgICAgIHRl
c3QgdXNlcyBsb3RzIG9mIGxvY2FsIHZhcmlhYmxlcywgYXQgbGVhc3QgYXMgbWFueSBsb2NhbAo+
IC0gICAgICAgdmFyaWFibGVzIGFzIG1haW4gaGFzIGFsbG9jYXRlZCBzbyBmYXIgaW5jbHVkaW5n
IGNvbXBpbGVyCj4gLSAgICAgICB0ZW1wb3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9y
IGdjYyAxLjQwLjMgb24gYSBTb2xhcmlzCj4gLSAgICAgICA0LjEuMyBzcGFyYywgYnV0IHdlIHVz
ZSA4IHRvIGJlIHNhZmUuICBBIGJ1Z2d5IGNvbXBpbGVyIHNob3VsZAo+IC0gICAgICAgcmV1c2Ug
dGhlIHJlZ2lzdGVyIG9mIHBhcmVudCBmb3Igb25lIG9mIHRoZSBsb2NhbCB2YXJpYWJsZXMsCj4g
LSAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRoYXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJl
IHVzZWQgYW55IG1vcmUKPiAtICAgICAgIGluIHRoaXMgcm91dGluZS4gIEFzc2lnbmluZyB0byB0
aGUgbG9jYWwgdmFyaWFibGUgd2lsbCB0aHVzCj4gLSAgICAgICBtdW5nZSBwYXJlbnQgaW4gdGhl
IHBhcmVudCBwcm9jZXNzLiAgKi8KPiAtICAgIHBpZF90Cj4gLSAgICAgIHAgPSBnZXRwaWQoKSwg
cDEgPSBnZXRwaWQoKSwgcDIgPSBnZXRwaWQoKSwgcDMgPSBnZXRwaWQoKSwKPiAtICAgICAgcDQg
PSBnZXRwaWQoKSwgcDUgPSBnZXRwaWQoKSwgcDYgPSBnZXRwaWQoKSwgcDcgPSBnZXRwaWQoKTsK
PiAtICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3IGFyZSBsaXZlOyBvdGhl
cndpc2UsIGl0IG1pZ2h0Cj4gLSAgICAgICB1c2UgdGhlIHNhbWUgaGFyZHdhcmUgcmVnaXN0ZXIg
Zm9yIGFsbCA4IGxvY2FsIHZhcmlhYmxlcy4gICovCj4gLSAgICBpZiAocCAhPSBwMSB8fCBwICE9
IHAyIHx8IHAgIT0gcDMgfHwgcCAhPSBwNAo+IC0gICAgICAgfHwgcCAhPSBwNSB8fCBwICE9IHA2
IHx8IHAgIT0gcDcpCj4gLSAgICAgIF9leGl0KDEpOwo+IC0KPiAtICAgIC8qIE9uIHNvbWUgc3lz
dGVtcyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50Cj4gLSAg
ICAgICBmcm9tIGNoaWxkIGZpbGUgZGVzY3JpcHRvcnMuICBJZiB0aGUgY2hpbGQgY2xvc2VzIGEg
ZGVzY3JpcHRvcgo+IC0gICAgICAgYmVmb3JlIGl0IGV4ZWNzIG9yIGV4aXRzLCB0aGlzIG11bmdl
cyB0aGUgcGFyZW50J3MgZGVzY3JpcHRvcgo+IC0gICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRo
aXMgYnkgY2xvc2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KPiAtICAgIF9leGl0KGNsb3Nl
KGZpbGVubyhzdGRvdXQpKSAhPSAwKTsKPiAtICB9IGVsc2Ugewo+IC0gICAgaW50IHN0YXR1czsK
PiAtICAgIHN0cnVjdCBzdGF0IHN0Owo+ICsgICAgICAgYXNfZm5fZXJyb3IgJD8gIlBhY2thZ2Ug
cmVxdWlyZW1lbnRzIChnbGliLTIuMCkgd2VyZSBub3QgbWV0Ogo+IAo+IC0gICAgd2hpbGUgKHdh
aXQoJnN0YXR1cykgIT0gY2hpbGQpCj4gLSAgICAgIDsKPiAtICAgIHJldHVybiAoCj4gLSAgICAg
ICAgLyogV2FzIHRoZXJlIHNvbWUgcHJvYmxlbSB3aXRoIHZmb3JraW5nPyAgKi8KPiAtICAgICAg
ICBjaGlsZCA8IDAKPiArJGdsaWJfUEtHX0VSUk9SUwo+IAo+IC0gICAgICAgIC8qIERpZCB0aGUg
Y2hpbGQgZmFpbD8gIChUaGlzIHNob3VsZG4ndCBoYXBwZW4uKSAgKi8KPiAtICAgICAgICB8fCBz
dGF0dXMKPiArQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1l
bnQgdmFyaWFibGUgaWYgeW91Cj4gK2luc3RhbGxlZCBzb2Z0d2FyZSBpbiBhIG5vbi1zdGFuZGFy
ZCBwcmVmaXguCj4gCj4gLSAgICAgICAgLyogRGlkIHRoZSB2Zm9yay9jb21waWxlciBidWcgb2Nj
dXI/ICAqLwo+IC0gICAgICAgIHx8IHBhcmVudCAhPSBnZXRwaWQoKQo+ICtBbHRlcm5hdGl2ZWx5
LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCj4gK2Fu
ZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgo+ICtTZWUg
dGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy4iICIkTElORU5PIiA1Cj4g
K2VsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KPiArICAgICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19l
Y2hvICJubyIgPiY2OyB9Cj4gKyAgICAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiArJGFzX2VjaG8gIiRhc19t
ZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+ICthc19mbl9lcnJvciAkPyAiVGhlIHBr
Zy1jb25maWcgc2NyaXB0IGNvdWxkIG5vdCBiZSBmb3VuZCBvciBpcyB0b28gb2xkLiAgTWFrZSBz
dXJlIGl0Cj4gK2lzIGluIHlvdXIgUEFUSCBvciBzZXQgdGhlIFBLR19DT05GSUcgZW52aXJvbm1l
bnQgdmFyaWFibGUgdG8gdGhlIGZ1bGwKPiArcGF0aCB0byBwa2ctY29uZmlnLgo+IAo+IC0gICAg
ICAgIC8qIERpZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1cj8gICovCj4gLSAgICAgICAg
fHwgZnN0YXQoZmlsZW5vKHN0ZG91dCksICZzdCkgIT0gMAo+IC0gICAgICAgICk7Cj4gLSAgfQo+
IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAt
ICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPXllcwo+ICtBbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNl
dCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCj4gK2FuZCBnbGliX0xJQlMg
dG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgo+ICtTZWUgdGhlIHBrZy1jb25m
aWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy4KPiArCj4gK1RvIGdldCBwa2ctY29uZmlnLCBz
ZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+Lgo+ICtTZWUgXGBjb25maWcu
bG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KPiAgZWxzZQo+IC0gIGFjX2N2
X2Z1bmNfdmZvcmtfd29ya3M9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25m
dGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+IC0gIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gKyAgICAg
ICBnbGliX0NGTEFHUz0kcGtnX2N2X2dsaWJfQ0ZMQUdTCj4gKyAgICAgICBnbGliX0xJQlM9JHBr
Z19jdl9nbGliX0xJQlMKPiArICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2VjaG8gInllcyIgPiY2OyB9Cj4gCj4g
IGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVuY192Zm9y
a193b3JrcyIgPiY2OyB9Cj4gCj4gLWZpOwo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193
b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KPiAtICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9m
dW5jX3Zmb3JrCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBX
QVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9m
IGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogcmVz
dWx0ICRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21w
aWxhdGlvbiIgPiYyO30KPiArIyBDaGVjayBsaWJyYXJ5IHBhdGgKPiAraWYgdGVzdCAiXCR7ZXhl
Y19wcmVmaXh9L2xpYiIgPSAiJGxpYmRpciI7IHRoZW4gOgo+ICsgIGlmIHRlc3QgIiRleGVjX3By
ZWZpeCIgPSAiTk9ORSIgJiYgdGVzdCAiJHByZWZpeCIgIT0gIk5PTkUiOyB0aGVuIDoKPiArICBl
eGVjX3ByZWZpeD0kcHJlZml4Cj4gIGZpCj4gKyAgICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0g
Ik5PTkUiOyB0aGVuIDoKPiArICBleGVjX3ByZWZpeD0kYWNfZGVmYXVsdF9wcmVmaXgKPiArZmkK
PiArICAgIGlmIHRlc3QgLWQgIiR7ZXhlY19wcmVmaXh9L2xpYjY0IjsgdGhlbiA6Cj4gCj4gLWlm
IHRlc3QgIngkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCj4gLQo+IC0kYXNf
ZWNobyAiI2RlZmluZSBIQVZFX1dPUktJTkdfVkZPUksgMSIgPj5jb25mZGVmcy5oCj4gKyAgICAg
ICAgTElCX1BBVEg9ImxpYjY0Igo+IAo+ICBlbHNlCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIHZm
b3JrIGZvcmsiID4+Y29uZmRlZnMuaAo+ICsgICAgICAgIExJQl9QQVRIPSJsaWIiCj4gCj4gIGZp
Cj4gLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KPiAKPiAt
JGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX0ZPUksgMSIgPj5jb25mZGVmcy5oCj4gK2Vs
c2UKPiAKPiAtZmkKPiArICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVj
X3ByZWZpeCIgKyAxYH0iCj4gCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFy
Z2UgZmlsZXMiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgX0xBUkdFRklMRV9TT1VS
Q0UgdmFsdWUgbmVlZGVkIGZvciBsYXJnZSBmaWxlcy4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIk
e2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgd2hpbGUgOjsgZG8KPiAtICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8KPiAtICAg
ICAjaW5jbHVkZSA8c3RkaW8uaD4KPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1pbnQgKCpmcCkg
KEZJTEUgKiwgb2ZmX3QsIGludCkgPSBmc2Vla287Cj4gLSAgICAgcmV0dXJuIGZzZWVrbyAoc3Rk
aW4sIDAsIDApICYmIGZwIChzdGRpbiwgMCwgMCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19
Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAg
YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9bm87IGJyZWFrCj4gLWZpCj4gLXJtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhl
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2RlZmluZSBfTEFSR0VG
SUxFX1NPVVJDRSAxCj4gLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCj4g
LSAgICAgI2luY2x1ZGUgPHN0ZGlvLmg+Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtaW50ICgq
ZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwo+IC0gICAgIHJldHVybiBmc2Vla28g
KHN0ZGluLCAwLCAwKSAmJiBmcCAoc3RkaW4sIDAsIDApOwo+IC0gIDsKPiAtICByZXR1cm4gMDsK
PiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+
IC0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPTE7IGJyZWFrCj4gIGZpCj4gLXJtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT11
bmtub3duCj4gLSAgYnJlYWsKPiAtZG9uZQo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+
JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2OyB9Cj4gLWNh
c2UgJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIGluICMoCj4gLSAgbm8gfCB1bmtub3duKSA7
Owo+IC0gICopCj4gLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBfTEFSR0VG
SUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UKPiAtX0FDRU9GCj4gLTs7Cj4g
LWVzYWMKPiAtcm0gLXJmIGNvbmZ0ZXN0Kgo+IC0KPiAtIyBXZSB1c2VkIHRvIHRyeSBkZWZpbmlu
ZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5kIGEgYnVnCj4gLSMgaW4gZ2xp
YmMgMi4xLjMsIGJ1dCB0aGF0IGJyZWFrcyB0b28gbWFueSBvdGhlciB0aGluZ3MuCj4gLSMgSWYg
eW91IHdhbnQgZnNlZWtvIGFuZCBmdGVsbG8gd2l0aCBnbGliYywgdXBncmFkZSB0byBhIGZpeGVk
IGdsaWJjLgo+IC1pZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSAhPSB1bmtub3du
OyB0aGVuCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+Y29uZmRlZnMu
aAo+IAo+IC1maQo+ICsjIENoZWNrcyBmb3IgbGlicmFyaWVzLgo+ICthY19mbl9jX2NoZWNrX2hl
YWRlcl9tb25ncmVsICIkTElORU5PIiAiYnpsaWIuaCIgImFjX2N2X2hlYWRlcl9iemxpYl9oIiAi
JGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2J6bGliX2gi
ID0geCIieWVzOyB0aGVuIDoKPiAKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVzIHRyYWlsaW5n
IHNsYXNoIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0
bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2
X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaytzZXR9IiA9IHNldDsgdGhl
biA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9Cj4gK2lm
IHRlc3QgIiR7YWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCtzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIHJtIC1m
IGNvbmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCj4gLWVjaG8gPmNvbmZ0ZXN0LmZpbGUKPiAtaWYg
dGVzdCAiJGFzX2xuX3MiID0gImxuIC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0ZXN0
LnN5bTsgdGhlbgo+IC0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoK
PiAtICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KPiAt
ZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAr
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4gK0xJQlM9Ii1sYnoyICAkTElCUyIKPiAr
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICAvKiBlbmQgY29u
ZmRlZnMuaC4gICovCj4gLSRhY19pbmNsdWRlc19kZWZhdWx0Cj4gKwo+ICsvKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiArICAgVXNlIGNo
YXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gKyAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCj4gKyNpZmRlZiBfX2NwbHVzcGx1cwo+ICtleHRlcm4gIkMiCj4gKyNlbmRpZgo+ICtj
aGFyIEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwo+ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLXN0
cnVjdCBzdGF0IHNidWY7Cj4gLSAgICAgLyogTGludXggd2lsbCBkZXJlZmVyZW5jZSB0aGUgc3lt
bGluayBhbmQgZmFpbCwgYXMgcmVxdWlyZWQgYnkgUE9TSVguCj4gLSAgICAgICBUaGF0IGlzIGJl
dHRlciBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBtZWFucyB3ZSB3aWxsIG5vdAo+IC0gICAgICAgaGF2
ZSB0byBjb21waWxlIGFuZCB1c2UgdGhlIGxzdGF0IHdyYXBwZXIuICAqLwo+IC0gICAgIHJldHVy
biBsc3RhdCAoImNvbmZ0ZXN0LnN5bS8iLCAmc2J1ZikgPT0gMDsKPiArcmV0dXJuIEJaMl9iekRl
Y29tcHJlc3NJbml0ICgpOwo+ICAgIDsKPiAgICByZXR1cm4gMDsKPiAgfQo+ICBfQUNFT0YKPiAt
aWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfZnVuY19sc3Rh
dF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfZnVu
Y19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCj4gLWZpCj4gLXJtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAo+IC1maQo+IC0KPiAraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+
ICsgIGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9eWVzCj4gIGVsc2UKPiAtICAj
IElmIHRoZSBgbG4gLXMnIGNvbW1hbmQgZmFpbGVkLCB0aGVuIHdlIHByb2JhYmx5IGRvbid0IGV2
ZW4KPiAtICAjIGhhdmUgYW4gbHN0YXQgZnVuY3Rpb24uCj4gLSAgYWNfY3ZfZnVuY19sc3RhdF9k
ZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCj4gKyAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpE
ZWNvbXByZXNzSW5pdD1ubwo+ICBmaQo+IC1ybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmls
ZQo+IC0KPiArcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4g
KyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICtMSUJTPSRhY19jaGVj
a19saWJfc2F2ZV9MSUJTCj4gK2ZpCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1
Cj4gKyRhc19lY2hvICIkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY2OyB9
Cj4gK2lmIHRlc3QgIngkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPSB4IiJ5
ZXM7IHRoZW4gOgo+ICsgIHpsaWI9IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKPiAgZmkKPiAt
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9m
dW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID4mNQo+IC0kYXNfZWNobyAi
JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9Cj4g
LQo+IC10ZXN0ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsg
PSB5ZXMgJiYKPiAKPiAtY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIExTVEFU
X0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LIDEKPiAtX0FDRU9GCj4gCj4gK2ZpCj4gCj4gLWlmIHRl
c3QgIngkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rIiA9IHhu
bzsgdGhlbgo+IC0gIGNhc2UgIiAkTElCT0JKUyAiIGluCj4gLSAgKiIgbHN0YXQuJGFjX29iamV4
dCAiKiApIDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9CSlMgbHN0YXQuJGFjX29iamV4dCIKPiAt
IDs7Cj4gLWVzYWMKPiAKPiAtZmkKPiArYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJ
TkVOTyIgImx6bWEuaCIgImFjX2N2X2hlYWRlcl9sem1hX2giICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKPiAraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHptYV9oIiA9IHgiInllczsgdGhlbiA6Cj4g
Cj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hl
dGhlciBzeXMvdHlwZXMuaCBkZWZpbmVzIG1ha2VkZXYiID4mNQo+IC0kYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldi4uLiAiID4mNjsgfQo+IC1p
ZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2K3NldH0iID0gc2V0OyB0
aGVuIDoKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEiID4mNQo+ICskYXNfZWNob19uICJj
aGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KPiAr
aWYgdGVzdCAiJHthY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyK3NldH0iID0gc2V0
OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsgIGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxsem1hICAkTElCUyIKPiArY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICAvKiBlbmQgY29uZmRlZnMuaC4gICov
Cj4gLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KPiArCj4gKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50
ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2UgY2hhciBiZWNhdXNl
IGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiArICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAr
I2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiArI2VuZGlmCj4gK2NoYXIgbHptYV9z
dHJlYW1fZGVjb2RlciAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC1yZXR1cm4gbWFrZWRl
digwLCAwKTsKPiArcmV0dXJuIGx6bWFfc3RyZWFtX2RlY29kZXIgKCk7Cj4gICAgOwo+ICAgIHJl
dHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+ICBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6Cj4gLSAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXY9eWVzCj4gKyAgYWNf
Y3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2hl
YWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2PW5vCj4gKyAgYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJl
YW1fZGVjb2Rlcj1ubwo+ICBmaQo+ICBybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKPiAgICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4g
LQo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjUKPiAtJGFzX2VjaG8gIiRh
Y19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIgPiY2OyB9Cj4gLQo+IC1pZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiA9IG5vOyB0aGVuCj4gLWFjX2ZuX2NfY2hl
Y2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvbWtkZXYuaCIgImFjX2N2X2hlYWRlcl9z
eXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hl
YWRlcl9zeXNfbWtkZXZfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZp
bmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCj4gLQo+ICtMSUJTPSRhY19jaGVja19s
aWJfc2F2ZV9MSUJTCj4gIGZpCj4gLQo+IC0KPiAtCj4gLSAgaWYgdGVzdCAkYWNfY3ZfaGVhZGVy
X3N5c19ta2Rldl9oID0gbm87IHRoZW4KPiAtICAgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdy
ZWwgIiRMSU5FTk8iICJzeXMvc3lzbWFjcm9zLmgiICJhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jv
c19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N5
c19zeXNtYWNyb3NfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUg
TUFKT1JfSU5fU1lTTUFDUk9TIDEiID4+Y29uZmRlZnMuaAo+IC0KPiAreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbHptYV9sem1hX3N0
cmVhbV9kZWNvZGVyIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdl9saWJfbHptYV9sem1hX3N0cmVh
bV9kZWNvZGVyIiA+JjY7IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVh
bV9kZWNvZGVyIiA9IHgiInllczsgdGhlbiA6Cj4gKyAgemxpYj0iJHpsaWIgLURIQVZFX0xaTUEg
LWxsem1hIgo+ICBmaQo+IAo+IAo+IC0gIGZpCj4gIGZpCj4gCj4gLWZvciBhY19oZWFkZXIgaW4g
c3RkbGliLmgKPiAtZG8gOgo+IC0gIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5F
Tk8iICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgPSB4IiJ5ZXM7IHRoZW4g
Ogo+IC0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBIQVZFX1NURExJQl9I
IDEKPiAtX0FDRU9GCj4gLQo+IC1maQo+IAo+IC1kb25lCj4gK2FjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJsem8vbHpvMXguaCIgImFjX2N2X2hlYWRlcl9sem9fbHpvMXhf
aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem9f
bHpvMXhfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxvYyIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxv
Yy4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCtz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKPiArJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yLi4uICIgPiY2
OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcytzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0g
IGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKPiAtICBhY19jdl9mdW5j
X21hbGxvY18wX25vbm51bGw9bm8KPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4g
K0xJQlM9Ii1sbHpvMiAgJExJQlMiCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaWYgZGVmaW5lZCBTVERD
X0hFQURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICj4gLSMgaW5jbHVkZSA8c3RkbGliLmg+
Cj4gLSNlbHNlCj4gLWNoYXIgKm1hbGxvYyAoKTsKPiAtI2VuZGlmCj4gCj4gKy8qIE92ZXJyaWRl
IGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAr
ICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFw
cGx5LiAgKi8KPiArI2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiArI2VuZGlmCj4g
K2NoYXIgbHpvMXhfZGVjb21wcmVzcyAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC1yZXR1
cm4gISBtYWxsb2MgKDApOwo+ICtyZXR1cm4gbHpvMXhfZGVjb21wcmVzcyAoKTsKPiAgICA7Cj4g
ICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVO
TyI7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD15ZXMKPiAraWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xpYl9sem8yX2x6bzF4
X2RlY29tcHJlc3M9eWVzCj4gIGVsc2UKPiAtICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9
bm8KPiArICBhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPW5vCj4gIGZpCj4gLXJtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3Qu
JGFjX2V4dAo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
PiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKPiAgZmkKPiAtCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIg
PiY1Cj4gKyRhc19lY2hvICIkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY2OyB9
Cj4gK2lmIHRlc3QgIngkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7
IHRoZW4gOgo+ICsgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCj4gIGZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVu
Y19tYWxsb2NfMF9ub25udWxsIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9mdW5jX21hbGxvY18w
X25vbm51bGwiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwg
PSB5ZXM7IHRoZW4gOgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMSIgPj5j
b25mZGVmcy5oCj4gLQo+IC1lbHNlCj4gLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0Mg
MCIgPj5jb25mZGVmcy5oCj4gLQo+IC0gICBjYXNlICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIG1h
bGxvYy4kYWNfb2JqZXh0ICIqICkgOzsKPiAtICAqKSBMSUJPQkpTPSIkTElCT0JKUyBtYWxsb2Mu
JGFjX29iamV4dCIKPiAtIDs7Cj4gLWVzYWMKPiAtCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIG1h
bGxvYyBycGxfbWFsbG9jIiA+PmNvbmZkZWZzLmgKPiAKPiAgZmkKPiAKPiAKPiAteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBh
bmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZCIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBib3RoIGJlIGluY2x1ZGVk
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3RpbWUrc2V0fSIgPSBzZXQ7
IHRoZW4gOgo+ICsKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8iID4mNQo+ICskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8uLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9s
aWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAo+ICsgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxh
aW8gICRMSUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN5cy90eXBlcy5oPgo+IC0j
aW5jbHVkZSA8c3lzL3RpbWUuaD4KPiAtI2luY2x1ZGUgPHRpbWUuaD4KPiAKPiArLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gKyAgIFVz
ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+
ICsgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg
YXBwbHkuICAqLwo+ICsjaWZkZWYgX19jcGx1c3BsdXMKPiArZXh0ZXJuICJDIgo+ICsjZW5kaWYK
PiArY2hhciBpb19zZXR1cCAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC1pZiAoKHN0cnVj
dCB0bSAqKSAwKQo+IC1yZXR1cm4gMDsKPiArcmV0dXJuIGlvX3NldHVwICgpOwo+ICAgIDsKPiAg
ICByZXR1cm4gMDsKPiAgfQo+ICBfQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2hlYWRlcl90aW1lPXllcwo+ICtpZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15ZXMK
PiAgZWxzZQo+IC0gIGFjX2N2X2hlYWRlcl90aW1lPW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hl
YWRlcl90aW1lIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfdGltZSIgPiY2OyB9Cj4g
LWlmIHRlc3QgJGFjX2N2X2hlYWRlcl90aW1lID0geWVzOyB0aGVuCj4gLQo+IC0kYXNfZWNobyAi
I2RlZmluZSBUSU1FX1dJVEhfU1lTX1RJTUUgMSIgPj5jb25mZGVmcy5oCj4gLQo+ICsgIGFjX2N2
X2xpYl9haW9faW9fc2V0dXA9bm8KPiAgZmkKPiAtCj4gLQo+IC0KPiAtCj4gLSAgZm9yIGFjX2hl
YWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKPiAtZG8gOgo+IC0gIGFzX2FjX0hlYWRlcj1gJGFzX2Vj
aG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKPiAtYWNfZm5fY19jaGVj
a19oZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAi
JGFjX2luY2x1ZGVzX2RlZmF1bHQKPiAtIgo+IC1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hl
YWRlciJcIiA9IHgieWVzIjsgdGhlbiA6Cj4gLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+
IC0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKPiAt
X0FDRU9GCj4gLQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKPiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK0xJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKPiAgZmkKPiAtCj4gLWRvbmUKPiAtCj4gLQo+IC0KPiAtCj4g
LQo+IC0KPiAtCj4gLQo+IC0gIGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKPiAtZG8gOgo+
IC0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3No
YAo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIi
Cj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKPiAt
ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRh
Y19mdW5jIiB8ICRhc190cl9jcHBgIDEKPiAtX0FDRU9GCj4gLQo+ICt7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9haW9faW9fc2V0dXAi
ID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID4mNjsgfQo+ICtpZiB0
ZXN0ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKPiArICBzeXN0
ZW1fYWlvPSJ5Igo+ICtlbHNlCj4gKyAgc3lzdGVtX2Fpbz0ibiIKPiAgZmkKPiAtZG9uZQo+IC0K
PiAKPiAKPiAtCj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciB3b3JraW5nIG1rdGltZSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciB3b3JraW5nIG1rdGltZS4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNf
d29ya2luZ19ta3RpbWUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICt7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQo+
ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvLi4uICIgPiY2OyB9Cj4g
K2lmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiA9IHllczsgdGhlbiA6Cj4gLSAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1u
bwo+IC1lbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAo+ICsgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxjcnlwdG8gICRM
SUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gIC8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtLyogVGVzdCBwcm9ncmFtIGZyb20gUGF1bCBFZ2dlcnQg
YW5kIFRvbnkgTGVuZWlzLiAgKi8KPiAtI2lmZGVmIFRJTUVfV0lUSF9TWVNfVElNRQo+IC0jIGlu
Y2x1ZGUgPHN5cy90aW1lLmg+Cj4gLSMgaW5jbHVkZSA8dGltZS5oPgo+IC0jZWxzZQo+IC0jIGlm
ZGVmIEhBVkVfU1lTX1RJTUVfSAo+IC0jICBpbmNsdWRlIDxzeXMvdGltZS5oPgo+IC0jIGVsc2UK
PiAtIyAgaW5jbHVkZSA8dGltZS5oPgo+IC0jIGVuZGlmCj4gLSNlbmRpZgo+IC0KPiAtI2luY2x1
ZGUgPGxpbWl0cy5oPgo+IC0jaW5jbHVkZSA8c3RkbGliLmg+Cj4gCj4gLSNpZmRlZiBIQVZFX1VO
SVNURF9ICj4gLSMgaW5jbHVkZSA8dW5pc3RkLmg+Cj4gLSNlbmRpZgo+IC0KPiAtI2lmbmRlZiBI
QVZFX0FMQVJNCj4gLSMgZGVmaW5lIGFsYXJtKFgpIC8qIGVtcHR5ICovCj4gKy8qIE92ZXJyaWRl
IGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAr
ICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFw
cGx5LiAgKi8KPiArI2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiAgI2VuZGlmCj4g
LQo+IC0vKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24gdG8gcnBsX3B1dGVudiBieSBvdGhlciBj
b25maWcgdGVzdHMuICAqLwo+IC0jdW5kZWYgcHV0ZW52Cj4gLQo+IC1zdGF0aWMgdGltZV90IHRp
bWVfdF9tYXg7Cj4gLXN0YXRpYyB0aW1lX3QgdGltZV90X21pbjsKPiAtCj4gLS8qIFZhbHVlcyB3
ZSdsbCB1c2UgdG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4gICovCj4gLXN0YXRp
YyBjb25zdCBjaGFyICp0el9zdHJpbmdzW10gPSB7Cj4gLSAgKGNvbnN0IGNoYXIgKikgMCwgIlRa
PUdNVDAiLCAiVFo9SlNULTkiLAo+IC0gICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6MDA6MDAs
TTIuMy4wLzAwOjAwOjAwIgo+IC19Owo+IC0jZGVmaW5lIE5fU1RSSU5HUyAoc2l6ZW9mICh0el9z
dHJpbmdzKSAvIHNpemVvZiAodHpfc3RyaW5nc1swXSkpCj4gLQo+IC0vKiBSZXR1cm4gMCBpZiBt
a3RpbWUgZmFpbHMgdG8gY29udmVydCBhIGRhdGUgaW4gdGhlIHNwcmluZy1mb3J3YXJkIGdhcC4K
PiAtICAgQmFzZWQgb24gYSBwcm9ibGVtIHJlcG9ydCBmcm9tIEFuZHJlYXMgSmFlZ2VyLiAgKi8K
PiAtc3RhdGljIGludAo+IC1zcHJpbmdfZm9yd2FyZF9nYXAgKCkKPiAtewo+IC0gIC8qIGdsaWJj
ICh1cCB0byBhYm91dCAxOTk4LTEwLTA3KSBmYWlsZWQgdGhpcyB0ZXN0LiAqLwo+IC0gIHN0cnVj
dCB0bSB0bTsKPiAtCj4gLSAgLyogVXNlIHRoZSBwb3J0YWJsZSBQT1NJWC4xIHNwZWNpZmljYXRp
b24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCj4gLSAgICAgaW5zdGVhZCBvZiAiVFo9QW1l
cmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVnIGV2ZW4KPiAtICAgICBv
biBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xzb24gZXh0ZW5zaW9uLCBvciBkb24n
dCBoYXZlIHRoZQo+IC0gICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGluc3RhbGxlZC4gICovCj4g
LSAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7Cj4gLQo+IC0g
IHRtLnRtX3llYXIgPSA5ODsKPiAtICB0bS50bV9tb24gPSAzOwo+IC0gIHRtLnRtX21kYXkgPSA1
Owo+IC0gIHRtLnRtX2hvdXIgPSAyOwo+IC0gIHRtLnRtX21pbiA9IDA7Cj4gLSAgdG0udG1fc2Vj
ID0gMDsKPiAtICB0bS50bV9pc2RzdCA9IC0xOwo+IC0gIHJldHVybiBta3RpbWUgKCZ0bSkgIT0g
KHRpbWVfdCkgLTE7Cj4gLX0KPiAtCj4gLXN0YXRpYyBpbnQKPiAtbWt0aW1lX3Rlc3QxICh0aW1l
X3Qgbm93KQo+IC17Cj4gLSAgc3RydWN0IHRtICpsdDsKPiAtICByZXR1cm4gISAobHQgPSBsb2Nh
bHRpbWUgKCZub3cpKSB8fCBta3RpbWUgKGx0KSA9PSBub3c7Cj4gLX0KPiAtCj4gLXN0YXRpYyBp
bnQKPiAtbWt0aW1lX3Rlc3QgKHRpbWVfdCBub3cpCj4gLXsKPiAtICByZXR1cm4gKG1rdGltZV90
ZXN0MSAobm93KQo+IC0gICAgICAgICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3QpICh0aW1lX3Rf
bWF4IC0gbm93KSkKPiAtICAgICAgICAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAodGltZV90
X21pbiArIG5vdykpKTsKPiAtfQo+IC0KPiAtc3RhdGljIGludAo+IC1pcml4XzZfNF9idWcgKCkK
PiAtewo+IC0gIC8qIEJhc2VkIG9uIGNvZGUgZnJvbSBBcmllbCBGYWlnb24uICAqLwo+IC0gIHN0
cnVjdCB0bSB0bTsKPiAtICB0bS50bV95ZWFyID0gOTY7Cj4gLSAgdG0udG1fbW9uID0gMzsKPiAt
ICB0bS50bV9tZGF5ID0gMDsKPiAtICB0bS50bV9ob3VyID0gMDsKPiAtICB0bS50bV9taW4gPSAw
Owo+IC0gIHRtLnRtX3NlYyA9IDA7Cj4gLSAgdG0udG1faXNkc3QgPSAtMTsKPiAtICBta3RpbWUg
KCZ0bSk7Cj4gLSAgcmV0dXJuIHRtLnRtX21vbiA9PSAyICYmIHRtLnRtX21kYXkgPT0gMzE7Cj4g
LX0KPiAtCj4gLXN0YXRpYyBpbnQKPiAtYmlndGltZV90ZXN0IChpbnQgaikKPiAtewo+IC0gIHN0
cnVjdCB0bSB0bTsKPiAtICB0aW1lX3Qgbm93Owo+IC0gIHRtLnRtX3llYXIgPSB0bS50bV9tb24g
PSB0bS50bV9tZGF5ID0gdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRtLnRtX3NlYyA9IGo7Cj4g
LSAgbm93ID0gbWt0aW1lICgmdG0pOwo+IC0gIGlmIChub3cgIT0gKHRpbWVfdCkgLTEpCj4gLSAg
ICB7Cj4gLSAgICAgIHN0cnVjdCB0bSAqbHQgPSBsb2NhbHRpbWUgKCZub3cpOwo+IC0gICAgICBp
ZiAoISAobHQKPiAtICAgICAgICAgICAgJiYgbHQtPnRtX3llYXIgPT0gdG0udG1feWVhcgo+IC0g
ICAgICAgICAgICAmJiBsdC0+dG1fbW9uID09IHRtLnRtX21vbgo+IC0gICAgICAgICAgICAmJiBs
dC0+dG1fbWRheSA9PSB0bS50bV9tZGF5Cj4gLSAgICAgICAgICAgICYmIGx0LT50bV9ob3VyID09
IHRtLnRtX2hvdXIKPiAtICAgICAgICAgICAgJiYgbHQtPnRtX21pbiA9PSB0bS50bV9taW4KPiAt
ICAgICAgICAgICAgJiYgbHQtPnRtX3NlYyA9PSB0bS50bV9zZWMKPiAtICAgICAgICAgICAgJiYg
bHQtPnRtX3lkYXkgPT0gdG0udG1feWRheQo+IC0gICAgICAgICAgICAmJiBsdC0+dG1fd2RheSA9
PSB0bS50bV93ZGF5Cj4gLSAgICAgICAgICAgICYmICgobHQtPnRtX2lzZHN0IDwgMCA/IC0xIDog
MCA8IGx0LT50bV9pc2RzdCkKPiAtICAgICAgICAgICAgICAgICA9PSAodG0udG1faXNkc3QgPCAw
ID8gLTEgOiAwIDwgdG0udG1faXNkc3QpKSkpCj4gLSAgICAgICByZXR1cm4gMDsKPiAtICAgIH0K
PiAtICByZXR1cm4gMTsKPiAtfQo+IC0KPiAtc3RhdGljIGludAo+IC15ZWFyXzIwNTBfdGVzdCAo
KQo+IC17Cj4gLSAgLyogVGhlIGNvcnJlY3QgYW5zd2VyIGZvciAyMDUwLTAyLTAxIDAwOjAwOjAw
IGluIFBhY2lmaWMgdGltZSwKPiAtICAgICBpZ25vcmluZyBsZWFwIHNlY29uZHMuICAqLwo+IC0g
IHVuc2lnbmVkIGxvbmcgaW50IGFuc3dlciA9IDI1MjczMTUyMDBVTDsKPiAtCj4gLSAgc3RydWN0
IHRtIHRtOwo+IC0gIHRpbWVfdCB0Owo+IC0gIHRtLnRtX3llYXIgPSAyMDUwIC0gMTkwMDsKPiAt
ICB0bS50bV9tb24gPSAyIC0gMTsKPiAtICB0bS50bV9tZGF5ID0gMTsKPiAtICB0bS50bV9ob3Vy
ID0gdG0udG1fbWluID0gdG0udG1fc2VjID0gMDsKPiAtICB0bS50bV9pc2RzdCA9IC0xOwo+IC0K
PiAtICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBE
VCxNNC4xLjAsTTEwLjUuMCIKPiAtICAgICBpbnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZl
ciIgaW4gb3JkZXIgdG8gZGV0ZWN0IHRoZSBidWcgZXZlbgo+IC0gICAgIG9uIHN5c3RlbXMgdGhh
dCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBleHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCj4g
LSAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFsbGVkLiAgKi8KPiAtICBwdXRlbnYgKChj
aGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiKTsKPiAtCj4gLSAgdCA9IG1rdGltZSAo
JnRtKTsKPiAtCj4gLSAgLyogQ2hlY2sgdGhhdCB0aGUgcmVzdWx0IGlzIGVpdGhlciBhIGZhaWx1
cmUsIG9yIGNsb3NlIGVub3VnaAo+IC0gICAgIHRvIHRoZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdl
IGNhbiBhc3N1bWUgdGhlIGRpc2NyZXBhbmN5IGlzCj4gLSAgICAgZHVlIHRvIGxlYXAgc2Vjb25k
cy4gICovCj4gLSAgcmV0dXJuICh0ID09ICh0aW1lX3QpIC0xCj4gLSAgICAgICAgIHx8ICgwIDwg
dCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAmJiB0IDw9IGFuc3dlciArIDEyMCkpOwo+IC19Cj4gLQo+
ICtjaGFyIE1ENSAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC0gIHRpbWVfdCB0LCBkZWx0
YTsKPiAtICBpbnQgaSwgajsKPiAtCj4gLSAgLyogVGhpcyB0ZXN0IG1ha2VzIHNvbWUgYnVnZ3kg
bWt0aW1lIGltcGxlbWVudGF0aW9ucyBsb29wLgo+IC0gICAgIEdpdmUgdXAgYWZ0ZXIgNjAgc2Vj
b25kczsgYSBta3RpbWUgc2xvd2VyIHRoYW4gdGhhdAo+IC0gICAgIGlzbid0IHdvcnRoIHVzaW5n
IGFueXdheS4gICovCj4gLSAgYWxhcm0gKDYwKTsKPiAtCj4gLSAgZm9yICg7OykKPiAtICAgIHsK
PiAtICAgICAgdCA9ICh0aW1lX3RfbWF4IDw8IDEpICsgMTsKPiAtICAgICAgaWYgKHQgPD0gdGlt
ZV90X21heCkKPiAtICAgICAgIGJyZWFrOwo+IC0gICAgICB0aW1lX3RfbWF4ID0gdDsKPiAtICAg
IH0KPiAtICB0aW1lX3RfbWluID0gLSAoKHRpbWVfdCkgfiAodGltZV90KSAwID09ICh0aW1lX3Qp
IC0xKSAtIHRpbWVfdF9tYXg7Cj4gLQo+IC0gIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyog
YSBzdWl0YWJsZSBwcmltZSBudW1iZXIgKi8KPiAtICBmb3IgKGkgPSAwOyBpIDwgTl9TVFJJTkdT
OyBpKyspCj4gLSAgICB7Cj4gLSAgICAgIGlmICh0el9zdHJpbmdzW2ldKQo+IC0gICAgICAgcHV0
ZW52ICgoY2hhciopIHR6X3N0cmluZ3NbaV0pOwo+IC0KPiAtICAgICAgZm9yICh0ID0gMDsgdCA8
PSB0aW1lX3RfbWF4IC0gZGVsdGE7IHQgKz0gZGVsdGEpCj4gLSAgICAgICBpZiAoISBta3RpbWVf
dGVzdCAodCkpCj4gLSAgICAgICAgIHJldHVybiAxOwo+IC0gICAgICBpZiAoISAobWt0aW1lX3Rl
c3QgKCh0aW1lX3QpIDEpCj4gLSAgICAgICAgICAgICYmIG1rdGltZV90ZXN0ICgodGltZV90KSAo
NjAgKiA2MCkpCj4gLSAgICAgICAgICAgICYmIG1rdGltZV90ZXN0ICgodGltZV90KSAoNjAgKiA2
MCAqIDI0KSkpKQo+IC0gICAgICAgcmV0dXJuIDE7Cj4gLQo+IC0gICAgICBmb3IgKGogPSAxOyA7
IGogPDw9IDEpCj4gLSAgICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQo+IC0gICAgICAgICBy
ZXR1cm4gMTsKPiAtICAgICAgIGVsc2UgaWYgKElOVF9NQVggLyAyIDwgaikKPiAtICAgICAgICAg
YnJlYWs7Cj4gLSAgICAgIGlmICghIGJpZ3RpbWVfdGVzdCAoSU5UX01BWCkpCj4gLSAgICAgICBy
ZXR1cm4gMTsKPiAtICAgIH0KPiAtICByZXR1cm4gISAoaXJpeF82XzRfYnVnICgpICYmIHNwcmlu
Z19mb3J3YXJkX2dhcCAoKSAmJiB5ZWFyXzIwNTBfdGVzdCAoKSk7Cj4gK3JldHVybiBNRDUgKCk7
Cj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9y
dW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPXllcwo+
ICtpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfbGliX2Ny
eXB0b19NRDU9eWVzCj4gIGVsc2UKPiAtICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCj4g
LWZpCj4gLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQg
Y29uZnRlc3QkYWNfZXhlZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJl
YW0gY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC0KPiArICBhY19jdl9saWJfY3J5cHRvX01ENT1u
bwo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2Z1
bmNfd29ya2luZ19ta3RpbWUiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX3dvcmtpbmdf
bWt0aW1lID0gbm87IHRoZW4KPiAtICBjYXNlICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIG1rdGlt
ZS4kYWNfb2JqZXh0ICIqICkgOzsKPiAtICAqKSBMSUJPQkpTPSIkTElCT0JKUyBta3RpbWUuJGFj
X29iamV4dCIKPiAtIDs7Cj4gLWVzYWMKPiAtCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICBmaQo+IC0KPiAtCj4gLQo+
IC0KPiAtCj4gLQo+IC1mb3IgYWNfZnVuYyBpbiBnZXRwYWdlc2l6ZQo+IC1kbyA6Cj4gLSAgYWNf
Zm5fY19jaGVja19mdW5jICIkTElORU5PIiAiZ2V0cGFnZXNpemUiICJhY19jdl9mdW5jX2dldHBh
Z2VzaXplIgo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiID0geCIieWVzOyB0
aGVuIDoKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3ZfbGliX2NyeXB0
b19NRDUiID4mNjsgfQo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9IHgiInll
czsgdGhlbiA6Cj4gICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVf
R0VUUEFHRVNJWkUgMQo+ICsjZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKPiAgX0FDRU9GCj4gCj4g
KyAgTElCUz0iLWxjcnlwdG8gJExJQlMiCj4gKwo+ICtlbHNlCj4gKyAgYXNfZm5fZXJyb3IgJD8g
IkNvdWxkIG5vdCBmaW5kIGxpYmNyeXB0byIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtZG9uZQo+IAo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3
b3JraW5nIG1tYXAiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBtbWFw
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCtz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcyIgPiY1Cj4gKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0K
PiAraWYgdGVzdCAiJHthY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMitzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKPiAtICBhY19jdl9mdW5jX21tYXBf
Zml4ZWRfbWFwcGVkPW5vCj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Cj4gKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+ICtMSUJT
PSItbGV4dDJmcyAgJExJQlMiCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVs
dAo+IC0vKiBtYWxsb2MgbWlnaHQgaGF2ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8K
PiAtI3VuZGVmIG1hbGxvYwo+IC0KPiAtLyogVGhhbmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmlt
IEF2ZXJhIGZvciB0aGlzIHRlc3QuCj4gLSAgIEhlcmUgaXMgYSBtYXRyaXggb2YgbW1hcCBwb3Nz
aWJpbGl0aWVzOgo+IC0gICAgICAgbW1hcCBwcml2YXRlIG5vdCBmaXhlZAo+IC0gICAgICAgbW1h
cCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5tYXBwZWQKPiAtICAgICAg
IG1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKPiAtICAgICAg
IG1tYXAgc2hhcmVkIG5vdCBmaXhlZAo+IC0gICAgICAgbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29t
ZXdoZXJlIGN1cnJlbnRseSB1bm1hcHBlZAo+IC0gICAgICAgbW1hcCBzaGFyZWQgZml4ZWQgYXQg
c29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCj4gLSAgIEZvciBwcml2YXRlIG1hcHBpbmdzLCB3ZSBz
aG91bGQgdmVyaWZ5IHRoYXQgY2hhbmdlcyBjYW5ub3QgYmUgcmVhZCgpCj4gLSAgIGJhY2sgZnJv
bSB0aGUgZmlsZSwgbm9yIG1tYXAncyBiYWNrIGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQK
PiAtICAgYWRkcmVzcy4gIChUaGVyZSBoYXZlIGJlZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRlIHdh
cyBub3QgY29ycmVjdGx5Cj4gLSAgIGltcGxlbWVudGVkIGxpa2UgdGhlIGluZmFtb3VzIGkzODYg
c3ZyNC4wLCBhbmQgc3lzdGVtcyB3aGVyZSB0aGUKPiAtICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90
IGNvaGVyZW50IHdpdGggdGhlIGZpbGUgc3lzdGVtIGJ1ZmZlciBjYWNoZQo+IC0gICBsaWtlIGVh
cmx5IHZlcnNpb25zIG9mIEZyZWVCU0QgYW5kIHBvc3NpYmx5IGNvbnRlbXBvcmFyeSBOZXRCU0Qu
KQo+IC0gICBGb3Igc2hhcmVkIG1hcHBpbmdzLCB3ZSBzaG91bGQgY29udmVyc2VseSB2ZXJpZnkg
dGhhdCBjaGFuZ2VzIGdldAo+IC0gICBwcm9wYWdhdGVkIGJhY2sgdG8gYWxsIHRoZSBwbGFjZXMg
dGhleSdyZSBzdXBwb3NlZCB0byBiZS4KPiAtCj4gLSAgIEdyZXAgd2FudHMgcHJpdmF0ZSBmaXhl
ZCBhbHJlYWR5IG1hcHBlZC4KPiAtICAgVGhlIG1haW4gdGhpbmdzIGdyZXAgbmVlZHMgdG8ga25v
dyBhYm91dCBtbWFwIGFyZToKPiAtICAgKiBkb2VzIGl0IGV4aXN0IGFuZCBpcyBpdCBzYWZlIHRv
IHdyaXRlIGludG8gdGhlIG1tYXAnZCBhcmVhCj4gLSAgICogaG93IHRvIHVzZSBpdCAoQlNEIHZh
cmlhbnRzKSAgKi8KPiAtCj4gLSNpbmNsdWRlIDxmY250bC5oPgo+IC0jaW5jbHVkZSA8c3lzL21t
YW4uaD4KPiAtCj4gLSNpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMgJiYgIWRlZmluZWQgSEFWRV9T
VERMSUJfSAo+IC1jaGFyICptYWxsb2MgKCk7Cj4gLSNlbmRpZgo+IC0KPiAtLyogVGhpcyBtZXNz
IHdhcyBjb3BpZWQgZnJvbSB0aGUgR05VIGdldHBhZ2VzaXplLmguICAqLwo+IC0jaWZuZGVmIEhB
VkVfR0VUUEFHRVNJWkUKPiAtIyBpZmRlZiBfU0NfUEFHRVNJWkUKPiAtIyAgZGVmaW5lIGdldHBh
Z2VzaXplKCkgc3lzY29uZihfU0NfUEFHRVNJWkUpCj4gLSMgZWxzZSAvKiBubyBfU0NfUEFHRVNJ
WkUgKi8KPiAtIyAgaWZkZWYgSEFWRV9TWVNfUEFSQU1fSAo+IC0jICAgaW5jbHVkZSA8c3lzL3Bh
cmFtLmg+Cj4gLSMgICBpZmRlZiBFWEVDX1BBR0VTSVpFCj4gLSMgICAgZGVmaW5lIGdldHBhZ2Vz
aXplKCkgRVhFQ19QQUdFU0laRQo+IC0jICAgZWxzZSAvKiBubyBFWEVDX1BBR0VTSVpFICovCj4g
LSMgICAgaWZkZWYgTkJQRwo+IC0jICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBOQlBHICogQ0xT
SVpFCj4gLSMgICAgIGlmbmRlZiBDTFNJWkUKPiAtIyAgICAgIGRlZmluZSBDTFNJWkUgMQo+IC0j
ICAgICBlbmRpZiAvKiBubyBDTFNJWkUgKi8KPiAtIyAgICBlbHNlIC8qIG5vIE5CUEcgKi8KPiAt
IyAgICAgaWZkZWYgTkJQQwo+IC0jICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgTkJQQwo+IC0j
ICAgICBlbHNlIC8qIG5vIE5CUEMgKi8KPiAtIyAgICAgIGlmZGVmIFBBR0VTSVpFCj4gLSMgICAg
ICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgUEFHRVNJWkUKPiAtIyAgICAgIGVuZGlmIC8qIFBBR0VT
SVpFICovCj4gLSMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KPiAtIyAgICBlbmRpZiAvKiBubyBO
QlBHICovCj4gLSMgICBlbmRpZiAvKiBubyBFWEVDX1BBR0VTSVpFICovCj4gLSMgIGVsc2UgLyog
bm8gSEFWRV9TWVNfUEFSQU1fSCAqLwo+IC0jICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgODE5MiAg
LyogcHVudCB0b3RhbGx5ICovCj4gLSMgIGVuZGlmIC8qIG5vIEhBVkVfU1lTX1BBUkFNX0ggKi8K
PiAtIyBlbmRpZiAvKiBubyBfU0NfUEFHRVNJWkUgKi8KPiAtCj4gLSNlbmRpZiAvKiBubyBIQVZF
X0dFVFBBR0VTSVpFICovCj4gCj4gKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90
eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBt
YXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiArICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg
YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiArI2lmZGVmIF9fY3Bs
dXNwbHVzCj4gK2V4dGVybiAiQyIKPiArI2VuZGlmCj4gK2NoYXIgZXh0MmZzX29wZW4yICgpOwo+
ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLSAgY2hhciAqZGF0YSwgKmRhdGEyLCAqZGF0YTM7Cj4g
LSAgY29uc3QgY2hhciAqY2RhdGEyOwo+IC0gIGludCBpLCBwYWdlc2l6ZTsKPiAtICBpbnQgZmQs
IGZkMjsKPiAtCj4gLSAgcGFnZXNpemUgPSBnZXRwYWdlc2l6ZSAoKTsKPiAtCj4gLSAgLyogRmly
c3QsIG1ha2UgYSBmaWxlIHdpdGggc29tZSBrbm93biBnYXJiYWdlIGluIGl0LiAqLwo+IC0gIGRh
dGEgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsKPiAtICBpZiAoIWRhdGEpCj4gLSAgICBy
ZXR1cm4gMTsKPiAtICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKPiAtICAgICooZGF0
YSArIGkpID0gcmFuZCAoKTsKPiAtICB1bWFzayAoMCk7Cj4gLSAgZmQgPSBjcmVhdCAoImNvbmZ0
ZXN0Lm1tYXAiLCAwNjAwKTsKPiAtICBpZiAoZmQgPCAwKQo+IC0gICAgcmV0dXJuIDI7Cj4gLSAg
aWYgKHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2VzaXplKQo+IC0gICAgcmV0dXJu
IDM7Cj4gLSAgY2xvc2UgKGZkKTsKPiAtCj4gLSAgLyogTmV4dCwgY2hlY2sgdGhhdCB0aGUgdGFp
bCBvZiBhIHBhZ2UgaXMgemVyby1maWxsZWQuICBGaWxlIG11c3QgaGF2ZQo+IC0gICAgIG5vbi16
ZXJvIGxlbmd0aCwgb3RoZXJ3aXNlIHdlIHJpc2sgU0lHQlVTIGZvciBlbnRpcmUgcGFnZS4gICov
Cj4gLSAgZmQyID0gb3BlbiAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQgfCBPX1RS
VU5DLCAwNjAwKTsKPiAtICBpZiAoZmQyIDwgMCkKPiAtICAgIHJldHVybiA0Owo+IC0gIGNkYXRh
MiA9ICIiOwo+IC0gIGlmICh3cml0ZSAoZmQyLCBjZGF0YTIsIDEpICE9IDEpCj4gLSAgICByZXR1
cm4gNTsKPiAtICBkYXRhMiA9IChjaGFyICopIG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQg
fCBQUk9UX1dSSVRFLCBNQVBfU0hBUkVELCBmZDIsIDBMKTsKPiAtICBpZiAoZGF0YTIgPT0gTUFQ
X0ZBSUxFRCkKPiAtICAgIHJldHVybiA2Owo+IC0gIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsg
KytpKQo+IC0gICAgaWYgKCooZGF0YTIgKyBpKSkKPiAtICAgICAgcmV0dXJuIDc7Cj4gLSAgY2xv
c2UgKGZkMik7Cj4gLSAgaWYgKG11bm1hcCAoZGF0YTIsIHBhZ2VzaXplKSkKPiAtICAgIHJldHVy
biA4Owo+IC0KPiAtICAvKiBOZXh0LCB0cnkgdG8gbW1hcCB0aGUgZmlsZSBhdCBhIGZpeGVkIGFk
ZHJlc3Mgd2hpY2ggYWxyZWFkeSBoYXMKPiAtICAgICBzb21ldGhpbmcgZWxzZSBhbGxvY2F0ZWQg
YXQgaXQuICBJZiB3ZSBjYW4sIGFsc28gbWFrZSBzdXJlIHRoYXQKPiAtICAgICB3ZSBzZWUgdGhl
IHNhbWUgZ2FyYmFnZS4gICovCj4gLSAgZmQgPSBvcGVuICgiY29uZnRlc3QubW1hcCIsIE9fUkRX
Uik7Cj4gLSAgaWYgKGZkIDwgMCkKPiAtICAgIHJldHVybiA5Owo+IC0gIGlmIChkYXRhMiAhPSBt
bWFwIChkYXRhMiwgcGFnZXNpemUsIFBST1RfUkVBRCB8IFBST1RfV1JJVEUsCj4gLSAgICAgICAg
ICAgICAgICAgICAgTUFQX1BSSVZBVEUgfCBNQVBfRklYRUQsIGZkLCAwTCkpCj4gLSAgICByZXR1
cm4gMTA7Cj4gLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCj4gLSAgICBpZiAoKihk
YXRhICsgaSkgIT0gKihkYXRhMiArIGkpKQo+IC0gICAgICByZXR1cm4gMTE7Cj4gLQo+IC0gIC8q
IEZpbmFsbHksIG1ha2Ugc3VyZSB0aGF0IGNoYW5nZXMgdG8gdGhlIG1hcHBlZCBhcmVhIGRvIG5v
dAo+IC0gICAgIHBlcmNvbGF0ZSBiYWNrIHRvIHRoZSBmaWxlIGFzIHNlZW4gYnkgcmVhZCgpLiAg
KFRoaXMgaXMgYSBidWcgb24KPiAtICAgICBzb21lIHZhcmlhbnRzIG9mIGkzODYgc3ZyNC4wLikg
ICovCj4gLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCj4gLSAgICAqKGRhdGEyICsg
aSkgPSAqKGRhdGEyICsgaSkgKyAxOwo+IC0gIGRhdGEzID0gKGNoYXIgKikgbWFsbG9jIChwYWdl
c2l6ZSk7Cj4gLSAgaWYgKCFkYXRhMykKPiAtICAgIHJldHVybiAxMjsKPiAtICBpZiAocmVhZCAo
ZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0gcGFnZXNpemUpCj4gLSAgICByZXR1cm4gMTM7Cj4gLSAg
Zm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCj4gLSAgICBpZiAoKihkYXRhICsgaSkgIT0g
KihkYXRhMyArIGkpKQo+IC0gICAgICByZXR1cm4gMTQ7Cj4gLSAgY2xvc2UgKGZkKTsKPiArcmV0
dXJuIGV4dDJmc19vcGVuMiAoKTsKPiArICA7Cj4gICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9G
Cj4gLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNf
bW1hcF9maXhlZF9tYXBwZWQ9eWVzCj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKPiArICBhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj15ZXMKPiAgZWxzZQo+IC0g
IGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSAqLmNv
cmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+
IC0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4g
LWZpCj4gLQo+ICsgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPW5vCj4gIGZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVu
Y19tbWFwX2ZpeGVkX21hcHBlZCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVuY19tbWFwX2Zp
eGVkX21hcHBlZCIgPiY2OyB9Cj4gLWlmIHRlc3QgJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBw
ZWQgPSB5ZXM7IHRoZW4KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfTU1BUCAxIiA+PmNv
bmZkZWZzLmgKPiAtCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgXAo+ICsgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0k
YWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICBmaQo+IC1ybSAtZiBjb25mdGVzdC5tbWFwIGNvbmZ0
ZXN0LnR4dAo+IC0KPiAtZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAo+IC1kbyA6Cj4gLSAgYWNf
Zm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVh
ZGVyX3N0ZGxpYl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3Zf
aGVhZGVyX3N0ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVfU1RETElCX0ggMQo+IC1fQUNFT0YKPiAtCj4gK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4
dDJmc19leHQyZnNfb3BlbjIiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0
MmZzX29wZW4yIiA+JjY7IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19v
cGVuMiIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsgIGxpYmV4dDJmcz0ieSIKPiArZWxzZQo+ICsgIGxp
YmV4dDJmcz0ibiIKPiAgZmkKPiAKPiAtZG9uZQo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIHJlYWxs
b2MiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSBy
ZWFsbG9jLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9u
bnVsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQi
ID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAt
bGdjcnlwdC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X2xpYl9nY3J5cHRfZ2NyeV9t
ZF9oYXNoX2J1ZmZlcitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKPiAtICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCj4gLWVsc2UKPiAtICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUwo+ICtMSUJTPSItbGdjcnlwdCAgJExJQlMiCj4gK2NhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+IC0jaWYgZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9I
Cj4gLSMgaW5jbHVkZSA8c3RkbGliLmg+Cj4gLSNlbHNlCj4gLWNoYXIgKnJlYWxsb2MgKCk7Cj4g
LSNlbmRpZgo+IAo+ICsvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBh
dm9pZCBhbiBlcnJvci4KPiArICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl
IHJldHVybiB0eXBlIG9mIGEgR0NDCj4gKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50
IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCj4gKyNpZmRlZiBfX2NwbHVzcGx1cwo+
ICtleHRlcm4gIkMiCj4gKyNlbmRpZgo+ICtjaGFyIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7Cj4g
IGludAo+ICBtYWluICgpCj4gIHsKPiAtcmV0dXJuICEgcmVhbGxvYyAoMCwgMCk7Cj4gK3JldHVy
biBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwo+ICAgIDsKPiAgICByZXR1cm4gMDsKPiAgfQo+ICBf
QUNFT0YKPiAtaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3Zf
ZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKPiAraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVO
TyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj15ZXMK
PiAgZWxzZQo+IC0gIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9bm8KPiArICBhY19jdl9s
aWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9bm8KPiAgZmkKPiAtcm0gLWYgY29yZSAqLmNv
cmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+
IC0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4g
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29u
ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3Nh
dmVfTElCUwo+ICBmaQo+IC0KPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQo+
ICskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9
Cj4gK2lmIHRlc3QgIngkYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA9IHgi
InllczsgdGhlbiA6Cj4gKyAgbGliZ2NyeXB0PSJ5Igo+ICtlbHNlCj4gKyAgbGliZ2NyeXB0PSJu
Igo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2
X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX3Jl
YWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKPiAKPiAtJGFzX2VjaG8gIiNkZWZpbmUgSEFW
RV9SRUFMTE9DIDEiID4+Y29uZmRlZnMuaAo+IAo+ICsKPiArICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZyIgPiY1Cj4g
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciBwdGhyZWFkIGZsYWcuLi4gIiA+JjY7IH0KPiAraWYg
dGVzdCAiJHtheF9jdl9wdGhyZWFkX2ZsYWdzK3NldH0iID0gc2V0OyB0aGVuIDoKPiArICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFW
RV9SRUFMTE9DIDAiID4+Y29uZmRlZnMuaAo+IAo+IC0gICBjYXNlICIgJExJQk9CSlMgIiBpbgo+
IC0gICoiIHJlYWxsb2MuJGFjX29iamV4dCAiKiApIDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9C
SlMgcmVhbGxvYy4kYWNfb2JqZXh0Igo+IC0gOzsKPiAtZXNhYwo+ICsgICAgICAgIGF4X2N2X3B0
aHJlYWRfZmxhZ3M9LXB0aHJlYWQKPiArCj4gKyAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0
aHJlYWRfZmxhZ3MiCj4gKyAgICBQVEhSRUFEX0xERkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdz
Igo+ICsgICAgUFRIUkVBRF9MSUJTPSIiCj4gKwo+ICsKPiArICAgIHNhdmVkX0NGTEFHUz0iJENG
TEFHUyIKPiArCj4gKyAgICBzYXZlZF9MREZMQUdTPSIkTERGTEFHUyIKPiArCj4gKyAgICBzYXZl
ZF9MSUJTPSIkTElCUyIKPiArCj4gKwo+ICsgICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQVEhSRUFEX0NG
TEFHUyIKPiArCj4gKyAgICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgo+ICsK
PiArICAgIExJQlM9IiRMSUJTICRQVEhSRUFEX0xJQlMiCj4gKwo+ICsgICAgICAgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+ICsKPiArI2luY2x1ZGUgPHB0aHJlYWQuaD4KPiAraW50IG1haW4odm9pZCkgewo+ICsg
IHB0aHJlYWRfYXRmb3JrKDAsMCwwKTsKPiArICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCwwKTsKPiAr
fQo+ICsKPiArX0FDRU9GCj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
PiArCj4gK2Vsc2UKPiArICBheF9jdl9wdGhyZWFkX2ZsYWdzPWZhaWxlZAo+ICtmaQo+ICtybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKPiArICAgIGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gKwo+ICsgICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZM
QUdTIgo+ICsKPiArICAgIExERkxBR1M9IiRzYXZlZF9MREZMQUdTIgo+IAo+ICsgICAgTElCUz0i
JHNhdmVkX0xJQlMiCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIHJlYWxsb2MgcnBsX3JlYWxsb2Mi
ID4+Y29uZmRlZnMuaAo+IAo+ICBmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQo+ICskYXNfZWNobyAi
JGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNjsgfQo+ICsgICAgaWYgdGVzdCAieCRheF9jdl9wdGhy
ZWFkX2ZsYWdzIiA9IHhmYWlsZWQ7IHRoZW4KPiArICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0
aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKPiArICAgIGZpCj4gKwo+ICsgICAgUFRI
UkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgo+ICsgICAgUFRIUkVBRF9MREZMQUdT
PSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKPiArICAgIFBUSFJFQURfTElCUz0iIgo+ICsKPiAKPiAK
PiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
d29ya2luZyBzdHJubGVuIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcg
c3Rybmxlbi4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfc3Rybmxlbl93b3Jr
aW5nK3NldH0iID0gc2V0OyB0aGVuIDoKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4mNQo+ICskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwuLi4gIiA+JjY7IH0KPiAr
aWYgdGVzdCAiJHthY19jdl9saWJfeWFqbF95YWpsX2FsbG9jK3NldH0iID0gc2V0OyB0aGVuIDoK
PiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAiJGNy
b3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3Jr
aW5nPW5vCj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+ICtMSUJTPSItbHlhamwg
ICRMSUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4g
IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtJGFjX2luY2x1ZGVzX2RlZmF1bHQKPiArCj4gKy8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+
ICsgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKPiArICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KPiArI2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiAr
I2VuZGlmCj4gK2NoYXIgeWFqbF9hbGxvYyAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC0K
PiAtI2RlZmluZSBTICJmb29iYXIiCj4gLSNkZWZpbmUgU19MRU4gKHNpemVvZiBTIC0gMSkKPiAt
Cj4gLSAgLyogQXQgbGVhc3Qgb25lIGltcGxlbWVudGF0aW9uIGlzIGJ1Z2d5OiB0aGF0IG9mIEFJ
WCA0LjMgd291bGQKPiAtICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMuICAqLwo+IC0KPiAt
ICBpbnQgaTsKPiAtICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCj4gLSAgICB7Cj4g
LSAgICAgIGludCBleHBlY3RlZCA9IGkgPD0gU19MRU4gPyBpIDogU19MRU47Cj4gLSAgICAgIGlm
IChzdHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKPiAtICAgICAgIHJldHVybiAxOwo+IC0gICAg
fQo+IC0gIHJldHVybiAwOwo+IC0KPiArcmV0dXJuIHlhamxfYWxsb2MgKCk7Cj4gICAgOwo+ICAg
IHJldHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8i
OyB0aGVuIDoKPiAtICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXMKPiAraWYgYWNfZm5f
Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxs
b2M9eWVzCj4gIGVsc2UKPiAtICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz1ubwo+ICsgIGFj
X2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KPiAgZmkKPiAtcm0gLWYgY29yZSAqLmNvcmUgY29y
ZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+IC0gIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4gK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29uZnRlc3Qk
YWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElC
Uwo+ICBmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xp
Yl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2xpYl95YWpsX3lh
amxfYWxsb2MiID0geCIieWVzOyB0aGVuIDoKPiArICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
Cj4gKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKPiArX0FDRU9GCj4gCj4gLWZpCj4gLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJu
bGVuX3dvcmtpbmciID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5n
IiA+JjY7IH0KPiAtdGVzdCAkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcgPSBubyAmJiBjYXNl
ICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7Cj4gLSAg
KikgTElCT0JKUz0iJExJQk9CSlMgc3Rybmxlbi4kYWNfb2JqZXh0Igo+IC0gOzsKPiAtZXNhYwo+
ICsgIExJQlM9Ii1seWFqbCAkTElCUyIKPiAKPiArZWxzZQo+ICsgIGFzX2ZuX2Vycm9yICQ/ICJD
b3VsZCBub3QgZmluZCB5YWpsIiAiJExJTkVOTyIgNQo+ICtmaQo+IAo+IC17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZCIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZC4uLiAiID4mNjsg
fQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfc3RydG9kK3NldH0iID0gc2V0OyB0aGVuIDoKPiAr
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZGVm
bGF0ZUNvcHkgaW4gLWx6IiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGRlZmxhdGVD
b3B5IGluIC1sei4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X2xpYl96X2RlZmxhdGVD
b3B5K3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+
ICBlbHNlCj4gLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0g
IGFjX2N2X2Z1bmNfc3RydG9kPW5vCj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+
ICtMSUJTPSItbHogICRMSUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Cj4gIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAKPiAtJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQKPiAtI2lmbmRlZiBzdHJ0b2QKPiAtZG91YmxlIHN0cnRvZCAoKTsKPiArLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gKyAgIFVz
ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+
ICsgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg
YXBwbHkuICAqLwo+ICsjaWZkZWYgX19jcGx1c3BsdXMKPiArZXh0ZXJuICJDIgo+ICAjZW5kaWYK
PiArY2hhciBkZWZsYXRlQ29weSAoKTsKPiAgaW50Cj4gLW1haW4oKQo+ICttYWluICgpCj4gIHsK
PiAtICB7Cj4gLSAgICAvKiBTb21lIHZlcnNpb25zIG9mIExpbnV4IHN0cnRvZCBtaXMtcGFyc2Ug
c3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KPiAtICAgIGNoYXIgKnN0cmluZyA9ICIgKzY5
IjsKPiAtICAgIGNoYXIgKnRlcm07Cj4gLSAgICBkb3VibGUgdmFsdWU7Cj4gLSAgICB2YWx1ZSA9
IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Cj4gLSAgICBpZiAodmFsdWUgIT0gNjkgfHwgdGVybSAh
PSAoc3RyaW5nICsgNCkpCj4gLSAgICAgIHJldHVybiAxOwo+IC0gIH0KPiAtCj4gLSAgewo+IC0g
ICAgLyogVW5kZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5zIHRoZSB3cm9uZyB2YWx1ZSBm
b3IgdGhlCj4gLSAgICAgICB0ZXJtaW5hdGluZyBjaGFyYWN0ZXIgdW5kZXIgc29tZSBjb25kaXRp
b25zLiAgKi8KPiAtICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOwo+IC0gICAgY2hhciAqdGVybTsK
PiAtICAgIHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Cj4gLSAgICBpZiAodGVybSAhPSBzdHJpbmcg
JiYgKih0ZXJtIC0gMSkgPT0gMCkKPiAtICAgICAgcmV0dXJuIDE7Cj4gLSAgfQo+ICtyZXR1cm4g
ZGVmbGF0ZUNvcHkgKCk7Cj4gKyAgOwo+ICAgIHJldHVybiAwOwo+ICB9Cj4gLQo+ICBfQUNFT0YK
PiAtaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfZnVuY19z
dHJ0b2Q9eWVzCj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiArICBh
Y19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2Z1bmNfc3RydG9k
PW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBi
Yi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAo+ICsgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5v
Cj4gIGZpCj4gLQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKPiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK0xJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3N0cnRvZCIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRv
ZCA9IG5vOyB0aGVuCj4gLSAgY2FzZSAiICRMSUJPQkpTICIgaW4KPiAtICAqIiBzdHJ0b2QuJGFj
X29iamV4dCAiKiApIDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9CSlMgc3RydG9kLiRhY19vYmpl
eHQiCj4gLSA7Owo+IC1lc2FjCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4mNQo+ICskYXNfZWNobyAi
JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJf
el9kZWZsYXRlQ29weSIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsgIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKPiArI2RlZmluZSBIQVZFX0xJQlogMQo+ICtfQUNFT0YKPiAKPiAtYWNfZm5fY19jaGVj
a19mdW5jICIkTElORU5PIiAicG93IiAiYWNfY3ZfZnVuY19wb3ciCj4gLWlmIHRlc3QgIngkYWNf
Y3ZfZnVuY19wb3ciID0geCIieWVzOyB0aGVuIDoKPiArICBMSUJTPSItbHogJExJQlMiCj4gCj4g
K2Vsc2UKPiArICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgemxpYiIgIiRMSU5FTk8i
IDUKPiAgZmkKPiAKPiAtaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBubzsgdGhlbgo+IC0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHBvdyBp
biAtbG0iID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgcG93IGluIC1sbS4uLiAiID4m
NjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2xpYl9tX3BvdytzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGxp
Ymljb252X29wZW4gaW4gLWxpY29udiIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBs
aWJpY29udl9vcGVuIGluIC1saWNvbnYuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9s
aWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+ICAgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKPiAtTElCUz0iLWxtICAkTElCUyIKPiArTElCUz0iLWxpY29udiAgJExJQlMiCj4gIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZz
LmguICAqLwo+IAo+IEBAIC05NTI4LDU1ICs2NTUzLDQ1IEBAIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgI2lmZGVmIF9fY3BsdXNwbHVzCj4gIGV4dGVybiAi
QyIKPiAgI2VuZGlmCj4gLWNoYXIgcG93ICgpOwo+ICtjaGFyIGxpYmljb252X29wZW4gKCk7Cj4g
IGludAo+ICBtYWluICgpCj4gIHsKPiAtcmV0dXJuIHBvdyAoKTsKPiArcmV0dXJuIGxpYmljb252
X29wZW4gKCk7Cj4gICAgOwo+ICAgIHJldHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+ICBpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX21fcG93PXllcwo+
ICsgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwo+ICBlbHNlCj4gLSAgYWNfY3Zf
bGliX21fcG93PW5vCj4gKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KPiAgZmkK
PiAgcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gICAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICBMSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX21fcG93IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9saWJf
bV9wb3ciID4mNjsgfQo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9tX3BvdyIgPSB4IiJ5ZXM7IHRo
ZW4gOgo+IC0gIFBPV19MSUI9LWxtCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNQo+ICsk
YXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjY7IH0KPiAraWYgdGVz
dCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsg
IGxpYmljb252PSJ5Igo+ICBlbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5p
dGlvbiBvZiBwb3ciID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYW5ub3QgZmlu
ZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mMjt9Cj4gLWZpCj4gLQo+
ICsgIGxpYmljb252PSJuIgo+ICBmaQo+IAo+IC1maQo+IAo+IC1mb3IgYWNfZnVuYyBpbiAgXAo+
IC0gICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBm
ZGF0YXN5bmMgZnRydW5jYXRlIFwKPiAtICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0Ynlu
YW1lIGdldGhvc3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCj4gLSAgICAgICAgICAg
ICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQg
bWtkaXIgXAo+IC0gICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0
aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAo+IC0gICAgICAgICAgICAgICAgc29ja2V0
IHN0cmNhc2VjbXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAo+IC0g
ICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRv
dWwgc3RydG91bGwgdHpzZXQgXAo+IC0gICAgICAgICAgICAgICAgdW5hbWUgXAo+IAo+ICsjIENo
ZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgo+ICtmb3IgYWNfaGVhZGVyIGluIHlhamwveWFqbF92ZXJz
aW9uLmgKPiAgZG8gOgo+IC0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1
bmMiIHwgJGFzX3RyX3NoYAo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVu
YyIgIiRhc19hY192YXIiCj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5
ZXMiOyB0aGVuIDoKPiArICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAi
eWFqbC95YWpsX3ZlcnNpb24uaCIgImFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiAi
JGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3lhamxfeWFq
bF92ZXJzaW9uX2giID0geCIieWVzOyB0aGVuIDoKPiAgICBjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCj4gLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEK
PiArI2RlZmluZSBIQVZFX1lBSkxfWUFKTF9WRVJTSU9OX0ggMQo+ICBfQUNFT0YKPiAKPiAgZmkK
PiArCj4gIGRvbmUKPiAKPiAKPiBkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlndXJlLmFjIGIvdG9v
bHMvY29uZmlndXJlLmFjCj4gaW5kZXggNTdjODg3ZC4uZGViODQ4ZCAxMDA2NDQKPiAtLS0gYS90
b29scy9jb25maWd1cmUuYWMKPiArKysgYi90b29scy9jb25maWd1cmUuYWMKPiBAQCAtMTksOSAr
MTksNiBAQCByZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBc
Cj4gIEFQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBpbnN0ZWFkIHdoZW4gcG9zc2libGUu
XSkKPiAgXSkKPiAKPiAtQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCj4gLUFDX0NBTk9OSUNBTF9I
T1NUCj4gLQo+ICAjIE00IE1hY3JvIGluY2x1ZGVzCj4gIG00X2luY2x1ZGUoW200L3NhdmV2YXIu
bTRdKQo+ICBtNF9pbmNsdWRlKFttNC9mZWF0dXJlcy5tNF0pCj4gQEAgLTc1LDkgKzcyLDcgQEAg
QUNfQVJHX1ZBUihbQkNDXSwgW1BhdGggdG8gYmNjIHRvb2xdKQo+ICBBQ19BUkdfVkFSKFtJQVNM
XSwgW1BhdGggdG8gaWFzbCB0b29sXSkKPiAKPiAgIyBDaGVja3MgZm9yIHByb2dyYW1zLgo+IC1B
Q19QUk9HX1NFRAo+ICBBQ19QUk9HX0NDCj4gLUFDX1BST0dfTE5fUwo+ICBBQ19QUk9HX01BS0Vf
U0VUCj4gIEFDX1BST0dfSU5TVEFMTAo+ICBBQ19QQVRIX1BST0coW0JJU09OXSwgW2Jpc29uXSkK
PiBAQCAtMTM3LDcgKzEzMiw2IEBAIEFDX1NVQlNUKGxpYmV4dDJmcykKPiAgQUNfQ0hFQ0tfTElC
KFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdj
cnlwdD0ibiJdKQo+ICBBQ19TVUJTVChsaWJnY3J5cHQpCj4gIEFYX0NIRUNLX1BUSFJFQUQKPiAt
QUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1lXSkKPiAgQUNfQ0hFQ0tfTElCKFt5YWps
XSwgW3lhamxfYWxsb2NdLCBbXSwKPiAgICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5k
IHlhamxdKV0pCj4gIEFDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNfTVNH
X0VSUk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQo+IEBAIC0xNDUsNTggKzEzOSw2IEBAIEFD
X0NIRUNLX0xJQihbaWNvbnZdLCBbbGliaWNvbnZfb3Blbl0sIFtsaWJpY29udj0ieSJdLCBbbGli
aWNvbnY9Im4iXSkKPiAgQUNfU1VCU1QobGliaWNvbnYpCj4gCj4gICMgQ2hlY2tzIGZvciBoZWFk
ZXIgZmlsZXMuCj4gLUFDX0ZVTkNfQUxMT0NBCj4gLUFDX0NIRUNLX0hFQURFUlMoWyBcCj4gLSAg
ICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGludHR5cGVzLmggbGliaW50bC5oIGxp
bWl0cy5oIG1hbGxvYy5oIFwKPiAtICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5o
IHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKPiAtICAgICAgICAgICAgICAg
IHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5oIHN5cy9tb3VudC5oIHN5cy9wYXJhbS5o
IFwKPiAtICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3RhdHZmcy5oIHN5cy90aW1l
Lmggc3lzbG9nLmggdGVybWlvcy5oIFwKPiAtICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwv
eWFqbF92ZXJzaW9uLmggXAo+IC0gICAgICAgICAgICAgICAgXSkKPiAtCj4gLSMgQ2hlY2tzIGZv
ciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KPiAt
QUNfSEVBREVSX1NUREJPT0wKPiAtQUNfVFlQRV9VSURfVAo+IC1BQ19DX0lOTElORQo+IC1BQ19U
WVBFX0lOVDE2X1QKPiAtQUNfVFlQRV9JTlQzMl9UCj4gLUFDX1RZUEVfSU5UNjRfVAo+IC1BQ19U
WVBFX0lOVDhfVAo+IC1BQ19UWVBFX01PREVfVAo+IC1BQ19UWVBFX09GRl9UCj4gLUFDX1RZUEVf
UElEX1QKPiAtQUNfQ19SRVNUUklDVAo+IC1BQ19UWVBFX1NJWkVfVAo+IC1BQ19UWVBFX1NTSVpF
X1QKPiAtQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCj4gLUFDX1NU
UlVDVF9TVF9CTE9DS1MKPiAtQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfcmRldl0p
Cj4gLUFDX1RZUEVfVUlOVDE2X1QKPiAtQUNfVFlQRV9VSU5UMzJfVAo+IC1BQ19UWVBFX1VJTlQ2
NF9UCj4gLUFDX1RZUEVfVUlOVDhfVAo+IC1BQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKPiAt
Cj4gLSMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KPiAtQUNfRlVOQ19FUlJPUl9BVF9M
SU5FCj4gLUFDX0ZVTkNfRk9SSwo+IC1BQ19GVU5DX0ZTRUVLTwo+IC1BQ19GVU5DX0xTVEFUX0ZP
TExPV1NfU0xBU0hFRF9TWU1MSU5LCj4gLUFDX0hFQURFUl9NQUpPUgo+IC1BQ19GVU5DX01BTExP
Qwo+IC1BQ19GVU5DX01LVElNRQo+IC1BQ19GVU5DX01NQVAKPiAtQUNfRlVOQ19SRUFMTE9DCj4g
LUFDX0ZVTkNfU1RSTkxFTgo+IC1BQ19GVU5DX1NUUlRPRAo+IC1BQ19DSEVDS19GVU5DUyhbIFwK
PiAtICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIg
ZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCj4gLSAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5
bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAo+IC0gICAgICAgICAg
ICAgICAgaW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0
IG1rZGlyIFwKPiAtICAgICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBh
dGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKPiAtICAgICAgICAgICAgICAgIHNvY2tl
dCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKPiAt
ICAgICAgICAgICAgICAgIHN0cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0
b3VsIHN0cnRvdWxsIHR6c2V0IFwKPiAtICAgICAgICAgICAgICAgIHVuYW1lIFwKPiAtICAgICAg
ICAgICAgICAgIF0pCj4gK0FDX0NIRUNLX0hFQURFUlMoW3lhamwveWFqbF92ZXJzaW9uLmhdKQo+
IAo+ICBBQ19PVVRQVVQoKQo+IC0tCj4gMS43LjIuNQo+IAo+IAo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+
IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:07:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4kP-0003dJ-UD; Wed, 25 Apr 2012 16:07:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN4kN-0003dD-4S
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:07:16 +0000
Received: from [193.109.254.147:47642] by server-1.bemta-14.messagelabs.com id
	89/18-29372-231289F4; Wed, 25 Apr 2012 16:07:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335370033!3849349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27297 invoked from network); 25 Apr 2012 16:07:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:07:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 17:07:11 +0100
Message-ID: <1335370030.28015.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 17:07:10 +0100
In-Reply-To: <1335369353-13012-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/25] autoconf: trim the configure script;
 use autoheader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA0LTI1IGF0IDE2OjU1ICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBS
ZW1vdmUgYSBsb3Qgb2YgdW5uZWNlc3NhcnkgdGVzdHMuICBTcGVjaWZpY2FsbHksIHdlIG5vIGxv
bmdlciB0ZXN0Cj4gZm9yIHN0YW5kYXJkIFBPU0lYIGZhY2lsaXRpZXMgd2hpY2ggd2UgZXhwZWN0
IHRvIGJlIHByb3ZpZGVkCj4gZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNh
c2UgaGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgo+IAo+IFN3aXRjaCB0byBnZW5lcmF0aW5nIGNv
bmZpZy5oLmluIHdpdGggYXV0b2hlYWRlci4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3Nv
biA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPiBDYzogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KCkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVs
bEBjaXRyaXguY29tPgoKPiAKPiBDaGFuZ2VzIHNpbmNlIHY3Ogo+ICAqIFJlbW92ZWQgQVhfQ0hF
Q0tfUFRZRlVOQ1MgKHNudWNrIGluIGZyb20gcHJldmlvdXMgcGF0Y2gpCj4gLS0tCj4gIGF1dG9n
ZW4uc2ggICAgICAgICB8ICAgIDEgKwo+ICB0b29scy9jb25maWcuaC5pbiAgfCAgIDczICstCj4g
IHRvb2xzL2NvbmZpZ3VyZSAgICB8IDg4MjUgKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICB0b29scy9jb25maWd1cmUuYWMgfCAgIDYwICstCj4g
IDQgZmlsZXMgY2hhbmdlZCwgMjk4MSBpbnNlcnRpb25zKCspLCA1OTc4IGRlbGV0aW9ucygtKQo+
IAo+IGRpZmYgLS1naXQgYS9hdXRvZ2VuLnNoIGIvYXV0b2dlbi5zaAo+IGluZGV4IGMyODhiNzEu
LjU4YTcxY2UgMTAwNzU1Cj4gLS0tIGEvYXV0b2dlbi5zaAo+ICsrKyBiL2F1dG9nZW4uc2gKPiBA
QCAtMSwzICsxLDQgQEAKPiAgIyEvYmluL3NoIC1lCj4gIGNkIHRvb2xzCj4gIGF1dG9jb25mCj4g
K2F1dG9oZWFkZXIKPiBkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlnLmguaW4gYi90b29scy9jb25m
aWcuaC5pbgo+IGluZGV4IGY4Zjk2ZGMuLjE3Yzg5MTMgMTAwNjQ0Cj4gLS0tIGEvdG9vbHMvY29u
ZmlnLmguaW4KPiArKysgYi90b29scy9jb25maWcuaC5pbgo+IEBAIC0xLDE5ICsxLDY0IEBACj4g
LS8qCj4gLSAqIENvcHlyaWdodCAoQykgMjAxMgo+IC0gKgo+IC0gKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQo+IC0g
KiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSBhcyBwdWJsaXNoZWQKPiAtICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsg
dmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lhbAo+IC0gKiBleGNlcHRpb24gb24gbGlu
a2luZyBkZXNjcmliZWQgaW4gZmlsZSBMSUNFTlNFLgo+IC0gKgo+IC0gKiBUaGlzIHByb2dyYW0g
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKPiAtICog
YnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFu
dHkgb2YKPiAtICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ
VVJQT1NFLiAgU2VlIHRoZQo+IC0gKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug
Zm9yIG1vcmUgZGV0YWlscy4KPiAtICovCj4gKy8qIGNvbmZpZy5oLmluLiAgR2VuZXJhdGVkIGZy
b20gY29uZmlndXJlLmFjIGJ5IGF1dG9oZWFkZXIuICAqLwo+ICsKPiArLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KPiArI3VuZGVmIEhB
VkVfSU5UVFlQRVNfSAo+ICsKPiArLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBjcnlw
dG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KPiArI3VuZGVmIEhBVkVfTElCQ1JZUFRPCj4gKwo+
ICsvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHlhamwnIGxpYnJhcnkgKC1seWFqbCku
ICovCj4gKyN1bmRlZiBIQVZFX0xJQllBSkwKPiArCj4gKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgeicgbGlicmFyeSAoLWx6KS4gKi8KPiArI3VuZGVmIEhBVkVfTElCWgo+ICsKPiAr
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxtZW1vcnkuaD4gaGVhZGVyIGZpbGUuICov
Cj4gKyN1bmRlZiBIQVZFX01FTU9SWV9ICj4gKwo+ICsvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPHN0ZGludC5oPiBoZWFkZXIgZmlsZS4gKi8KPiArI3VuZGVmIEhBVkVfU1RESU5UX0gK
PiArCj4gKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkbGliLmg+IGhlYWRlciBm
aWxlLiAqLwo+ICsjdW5kZWYgSEFWRV9TVERMSUJfSAo+ICsKPiArLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDxzdHJpbmdzLmg+IGhlYWRlciBmaWxlLiAqLwo+ICsjdW5kZWYgSEFWRV9T
VFJJTkdTX0gKPiArCj4gKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5nLmg+
IGhlYWRlciBmaWxlLiAqLwo+ICsjdW5kZWYgSEFWRV9TVFJJTkdfSAo+ICsKPiArLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvc3RhdC5oPiBoZWFkZXIgZmlsZS4gKi8KPiArI3Vu
ZGVmIEhBVkVfU1lTX1NUQVRfSAo+ICsKPiArLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IDxzeXMvdHlwZXMuaD4gaGVhZGVyIGZpbGUuICovCj4gKyN1bmRlZiBIQVZFX1NZU19UWVBFU19I
Cj4gKwo+ICsvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHVuaXN0ZC5oPiBoZWFkZXIg
ZmlsZS4gKi8KPiArI3VuZGVmIEhBVkVfVU5JU1REX0gKPiAKPiAgLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDx5YWpsL3lhamxfdmVyc2lvbi5oPiBoZWFkZXIgZmlsZS4gKi8KPiAgI3Vu
ZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAo+IAo+IC0vKiBEZWZpbmUgY3Vyc2VzIGhlYWRl
ciB0byBpbmNsdWRlLiAqLwo+ICsvKiBEZWZpbmUgY3Vyc2VzIGhlYWRlciB0byB1c2UgKi8KPiAg
I3VuZGVmIElOQ0xVREVfQ1VSU0VTX0gKPiArCj4gKy8qIERlZmluZSB0byB0aGUgYWRkcmVzcyB3
aGVyZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLwo+ICsj
dW5kZWYgUEFDS0FHRV9CVUdSRVBPUlQKPiArCj4gKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1l
IG9mIHRoaXMgcGFja2FnZS4gKi8KPiArI3VuZGVmIFBBQ0tBR0VfTkFNRQo+ICsKPiArLyogRGVm
aW5lIHRvIHRoZSBmdWxsIG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLwo+ICsj
dW5kZWYgUEFDS0FHRV9TVFJJTkcKPiArCj4gKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBz
aG9ydCBuYW1lIG9mIHRoaXMgcGFja2FnZS4gKi8KPiArI3VuZGVmIFBBQ0tBR0VfVEFSTkFNRQo+
ICsKPiArLyogRGVmaW5lIHRvIHRoZSBob21lIHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KPiAr
I3VuZGVmIFBBQ0tBR0VfVVJMCj4gKwo+ICsvKiBEZWZpbmUgdG8gdGhlIHZlcnNpb24gb2YgdGhp
cyBwYWNrYWdlLiAqLwo+ICsjdW5kZWYgUEFDS0FHRV9WRVJTSU9OCj4gKwo+ICsvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgQU5TSSBDIGhlYWRlciBmaWxlcy4gKi8KPiArI3VuZGVmIFNU
RENfSEVBREVSUwo+IGRpZmYgLS1naXQgYS90b29scy9jb25maWd1cmUgYi90b29scy9jb25maWd1
cmUKPiBpbmRleCA4OTdlMDYxLi5kODkxOGZlIDEwMDc1NQo+IC0tLSBhL3Rvb2xzL2NvbmZpZ3Vy
ZQo+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZQo+IEBAIC01OTUsMTIgKzU5NSw4IEBAIGFjX2luY2x1
ZGVzX2RlZmF1bHQ9IlwKPiAgIyBpbmNsdWRlIDx1bmlzdGQuaD4KPiAgI2VuZGlmIgo+IAo+IC1h
Y19oZWFkZXJfbGlzdD0KPiAtYWNfZnVuY19saXN0PQo+ICBhY19zdWJzdF92YXJzPSdMVExJQk9C
SlMKPiAtUE9XX0xJQgo+ICBMSUJPQkpTCj4gLUFMTE9DQQo+ICBsaWJpY29udgo+ICBQVEhSRUFE
X0xJQlMKPiAgUFRIUkVBRF9MREZMQUdTCj4gQEAgLTYxNiw2ICs2MTIsOSBAQCBQS0dfQ09ORklH
X0xJQkRJUgo+ICBQS0dfQ09ORklHX1BBVEgKPiAgUEtHX0NPTkZJRwo+ICBDVVJTRVNfTElCUwo+
ICtFR1JFUAo+ICtHUkVQCj4gK0NQUAo+ICBweWNvbmZpZwo+ICBQWVRIT05QQVRICj4gIE9DQU1M
QlVJTEQKPiBAQCAtNjM1LDggKzYzNCwxMyBAQCBJTlNUQUxMX0RBVEEKPiAgSU5TVEFMTF9TQ1JJ
UFQKPiAgSU5TVEFMTF9QUk9HUkFNCj4gIFNFVF9NQUtFCj4gLUxOX1MKPiAtU0VECj4gK09CSkVY
VAo+ICtFWEVFWFQKPiArYWNfY3RfQ0MKPiArQ1BQRkxBR1MKPiArTERGTEFHUwo+ICtDRkxBR1MK
PiArQ0MKPiAgSUFTTAo+ICBCQ0MKPiAgTEQ4Ngo+IEBAIC02NjUsMjQgKzY2OSw2IEBAIHhlbmFw
aQo+ICB2dHBtCj4gIG1vbml0b3JzCj4gIGdpdGh0dHAKPiAtaG9zdF9vcwo+IC1ob3N0X3ZlbmRv
cgo+IC1ob3N0X2NwdQo+IC1ob3N0Cj4gLWJ1aWxkX29zCj4gLWJ1aWxkX3ZlbmRvcgo+IC1idWls
ZF9jcHUKPiAtYnVpbGQKPiAtRUdSRVAKPiAtR1JFUAo+IC1DUFAKPiAtT0JKRVhUCj4gLUVYRUVY
VAo+IC1hY19jdF9DQwo+IC1DUFBGTEFHUwo+IC1MREZMQUdTCj4gLUNGTEFHUwo+IC1DQwo+ICB0
YXJnZXRfYWxpYXMKPiAgaG9zdF9hbGlhcwo+ICBidWlsZF9hbGlhcwo+IEBAIC03NDAsMTIgKzcy
Niw2IEBAIGVuYWJsZV9kZWJ1Zwo+ICAgICAgICBhY19wcmVjaW91c192YXJzPSdidWlsZF9hbGlh
cwo+ICBob3N0X2FsaWFzCj4gIHRhcmdldF9hbGlhcwo+IC1DQwo+IC1DRkxBR1MKPiAtTERGTEFH
Uwo+IC1MSUJTCj4gLUNQUEZMQUdTCj4gLUNQUAo+ICBQUkVQRU5EX0lOQ0xVREVTCj4gIFBSRVBF
TkRfTElCCj4gIEFQUEVORF9JTkNMVURFUwo+IEBAIC03NjIsNiArNzQyLDEyIEBAIEFTODYKPiAg
TEQ4Ngo+ICBCQ0MKPiAgSUFTTAo+ICtDQwo+ICtDRkxBR1MKPiArTERGTEFHUwo+ICtMSUJTCj4g
K0NQUEZMQUdTCj4gK0NQUAo+ICBQS0dfQ09ORklHCj4gIFBLR19DT05GSUdfUEFUSAo+ICBQS0df
Q09ORklHX0xJQkRJUgo+IEBAIC0xMzY1LDEwICsxMzUxLDYgQEAgRmluZSB0dW5pbmcgb2YgdGhl
IGluc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKPiAgX0FDRU9GCj4gCj4gICAgY2F0IDw8XF9BQ0VP
Rgo+IC0KPiAtU3lzdGVtIHR5cGVzOgo+IC0gIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBm
b3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCj4gLSAgLS1ob3N0PUhPU1QgICAgICAgY3Jv
c3MtY29tcGlsZSB0byBidWlsZCBwcm9ncmFtcyB0byBydW4gb24gSE9TVCBbQlVJTERdCj4gIF9B
Q0VPRgo+ICBmaQo+IAo+IEBAIC0xMzk5LDE0ICsxMzgxLDYgQEAgT3B0aW9uYWwgRmVhdHVyZXM6
Cj4gICAgLS1kaXNhYmxlLWRlYnVnICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiB0b29s
cyAoZGVmYXVsdCBpcyBFTkFCTEVEKQo+IAo+ICBTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50
IHZhcmlhYmxlczoKPiAtICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQKPiAtICBDRkxB
R1MgICAgICBDIGNvbXBpbGVyIGZsYWdzCj4gLSAgTERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBl
LmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxpYnJhcmllcyBpbiBhCj4gLSAgICAgICAgICAg
ICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgo+IC0gIExJQlMgICAgICAgIGxpYnJh
cmllcyB0byBwYXNzIHRvIHRoZSBsaW5rZXIsIGUuZy4gLWw8bGlicmFyeT4KPiAtICBDUFBGTEFH
UyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3MsIGUuZy4gLUk8aW5jbHVk
ZSBkaXI+IGlmCj4gLSAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5k
YXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+Cj4gLSAgQ1BQICAgICAgICAgQyBwcmVwcm9jZXNz
b3IKPiAgICBQUkVQRU5EX0lOQ0xVREVTCj4gICAgICAgICAgICAgICAgTGlzdCBvZiBpbmNsdWRl
IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCj4gICAgUFJFUEVORF9M
SUIgTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRob3V0
IC1MKQo+IEBAIC0xNDI1LDYgKzEzOTksMTQgQEAgU29tZSBpbmZsdWVudGlhbCBlbnZpcm9ubWVu
dCB2YXJpYWJsZXM6Cj4gICAgTEQ4NiAgICAgICAgUGF0aCB0byBsZDg2IHRvb2wKPiAgICBCQ0Mg
ICAgICAgICBQYXRoIHRvIGJjYyB0b29sCj4gICAgSUFTTCAgICAgICAgUGF0aCB0byBpYXNsIHRv
b2wKPiArICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQKPiArICBDRkxBR1MgICAgICBD
IGNvbXBpbGVyIGZsYWdzCj4gKyAgTERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxp
YiBkaXI+IGlmIHlvdSBoYXZlIGxpYnJhcmllcyBpbiBhCj4gKyAgICAgICAgICAgICAgbm9uc3Rh
bmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgo+ICsgIExJQlMgICAgICAgIGxpYnJhcmllcyB0byBw
YXNzIHRvIHRoZSBsaW5rZXIsIGUuZy4gLWw8bGlicmFyeT4KPiArICBDUFBGTEFHUyAgICAoT2Jq
ZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlm
Cj4gKyAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5kYXJkIGRpcmVj
dG9yeSA8aW5jbHVkZSBkaXI+Cj4gKyAgQ1BQICAgICAgICAgQyBwcmVwcm9jZXNzb3IKPiAgICBQ
S0dfQ09ORklHICBwYXRoIHRvIHBrZy1jb25maWcgdXRpbGl0eQo+ICAgIFBLR19DT05GSUdfUEFU
SAo+ICAgICAgICAgICAgICAgIGRpcmVjdG9yaWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2Vh
cmNoIHBhdGgKPiBAQCAtMTc5NywzMTEgKzE3NzksNiBAQCBmaQo+ICAgIGFzX2ZuX3NldF9zdGF0
dXMgJGFjX3JldHZhbAo+IAo+ICB9ICMgYWNfZm5fY190cnlfbGluawo+IC0KPiAtIyBhY19mbl9j
X2NoZWNrX2Z1bmMgTElORU5PIEZVTkMgVkFSCj4gLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+IC0jIFRlc3RzIHdoZXRoZXIgRlVOQyBleGlzdHMsIHNldHRpbmcgdGhlIGNh
Y2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseQo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgKCkKPiAt
ewo+IC0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGlu
ZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkMi4uLiAiID4mNjsgfQo+IC1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNv
bmZkZWZzLmguICAqLwo+IC0vKiBEZWZpbmUgJDIgdG8gYW4gaW5ub2N1b3VzIHZhcmlhbnQsIGlu
IGNhc2UgPGxpbWl0cy5oPiBkZWNsYXJlcyAkMi4KPiAtICAgRm9yIGV4YW1wbGUsIEhQLVVYIDEx
aSA8bGltaXRzLmg+IGRlY2xhcmVzIGdldHRpbWVvZmRheS4gICovCj4gLSNkZWZpbmUgJDIgaW5u
b2N1b3VzXyQyCj4gLQo+IC0vKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9z
IGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsCj4gLSAgICB3aGljaCBjYW4gY29uZmxpY3Qg
d2l0aCBjaGFyICQyICgpOyBiZWxvdy4KPiAtICAgIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3Nl
cnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKPiAtICAgIDxsaW1pdHMuaD4gZXhp
c3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4gICovCj4gLQo+IC0jaWZkZWYgX19T
VERDX18KPiAtIyBpbmNsdWRlIDxsaW1pdHMuaD4KPiAtI2Vsc2UKPiAtIyBpbmNsdWRlIDxhc3Nl
cnQuaD4KPiAtI2VuZGlmCj4gLQo+IC0jdW5kZWYgJDIKPiAtCj4gLS8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIg
JDIgKCk7Cj4gLS8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25z
IHdoaWNoIGl0IGltcGxlbWVudHMKPiAtICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAg
U29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkCj4gLSAgICBzb21ldGhpbmcgc3RhcnRp
bmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8KPiAtI2lmIGRl
ZmluZWQgX19zdHViXyQyIHx8IGRlZmluZWQgX19zdHViX19fJDIKPiAtY2hva2UgbWUKPiAtI2Vu
ZGlmCj4gLQo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJldHVybiAkMiAoKTsKPiAtICA7Cj4g
LSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5F
Tk8iOyB0aGVuIDoKPiAtICBldmFsICIkMz15ZXMiCj4gLWVsc2UKPiAtICBldmFsICIkMz1ubyIK
PiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4g
LSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC1ldmFsIGFj
X3Jlcz1cJCQzCj4gLSAgICAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQo+IC0kYXNfZWNobyAiJGFjX3JlcyIgPiY2
OyB9Cj4gLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIg
PSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KPiAtCj4gLX0gIyBhY19mbl9j
X2NoZWNrX2Z1bmMKPiAtCj4gLSMgYWNfZm5fY19jaGVja190eXBlIExJTkVOTyBUWVBFIFZBUiBJ
TkNMVURFUwo+IC0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
PiAtIyBUZXN0cyB3aGV0aGVyIFRZUEUgZXhpc3RzIGFmdGVyIGhhdmluZyBpbmNsdWRlZCBJTkNM
VURFUywgc2V0dGluZyBjYWNoZQo+IC0jIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KPiAtYWNf
Zm5fY19jaGVja190eXBlICgpCj4gLXsKPiAtICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0g
YXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCj4gLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4m
NQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KPiAtaWYgZXZhbCAi
dGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBldmFsICIkMz1ubyIKPiAtICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAt
JDQKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1pZiAoc2l6ZW9mICgkMikpCj4gLSAgICAgICAg
cmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSQ0
Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtaWYgKHNpemVvZiAoKCQyKSkpCj4gLSAgICAgICAg
ICAgcmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBh
Y19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAgZXZh
bCAiJDM9eWVzIgo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gLWV2YWwgYWNfcmVz
PVwkJDMKPiAtICAgICAgICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0K
PiAtICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHgg
JiYgeyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQo+IC0KPiAtfSAjIGFjX2ZuX2NfY2hl
Y2tfdHlwZQo+IC0KPiAtIyBhY19mbl9jX2ZpbmRfaW50WF90IExJTkVOTyBCSVRTIFZBUgo+IC0j
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgRmluZHMgYSBzaWduZWQg
aW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIK
PiAtIyBhY2NvcmRpbmdseS4KPiAtYWNfZm5fY19maW5kX2ludFhfdCAoKQo+IC17Cj4gLSAgYXNf
bGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9
JGFzX2xpbmVub19zdGFjawo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIGludCQyX3QiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgaW50JDJfdC4uLiAiID4mNjsgfQo+IC1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGV2YWwgIiQzPW5vIgo+IC0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2ZXIgY2hlY2sg
YSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgo+IC0gICAgICMgdGhhbiBoYWxmIG9m
IHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCj4gLSAgICAgZm9yIGFjX3R5cGUgaW4gaW50JDJf
dCAnaW50JyAnbG9uZyBpbnQnIFwKPiAtICAgICAgICAnbG9uZyBsb25nIGludCcgJ3Nob3J0IGlu
dCcgJ3NpZ25lZCBjaGFyJzsgZG8KPiAtICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVk
ZXNfZGVmYXVsdAo+IC0gICAgICAgICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKPiAtaW50
Cj4gLW1haW4gKCkKPiAtewo+IC1zdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwg
KCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsK
PiAtdGVzdF9hcnJheSBbMF0gPSAwCj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1f
QUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZk
ZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVsdAo+IC0gICAgICAgICAgICAgICBlbnVt
IHsgTiA9ICQyIC8gMiAtIDEgfTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1zdGF0aWMgaW50
IHRlc3RfYXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikg
PDwgTikgLSAxKSAqIDIgKyAxKQo+IC0gICAgICAgICAgICAgICAgPCAoJGFjX3R5cGUpICgoKCgo
JGFjX3R5cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAyKSldOwo+IC10ZXN0X2FycmF5IFsw
XSA9IDAKPiAtCj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAgY2FzZSAk
YWNfdHlwZSBpbiAjKAo+IC0gIGludCQyX3QpIDoKPiAtICAgIGV2YWwgIiQzPXllcyIgOzsgIygK
PiAtICAqKSA6Cj4gLSAgICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Cj4gLWVzYWMKPiAtZmkKPiAt
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNf
ZXh0Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
Y29uZnRlc3QuJGFjX2V4dAo+IC0gICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQzIlwiID0geCJu
byI7IHRoZW4gOgo+IC0KPiAtZWxzZQo+IC0gIGJyZWFrCj4gLWZpCj4gLSAgICAgZG9uZQo+IC1m
aQo+IC1ldmFsIGFjX3Jlcz1cJCQzCj4gLSAgICAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQo+IC0kYXNfZWNobyAi
JGFjX3JlcyIgPiY2OyB9Cj4gLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xp
bmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KPiAtCj4g
LX0gIyBhY19mbl9jX2ZpbmRfaW50WF90Cj4gLQo+IC0jIGFjX2ZuX2NfY2hlY2tfbWVtYmVyIExJ
TkVOTyBBR0dSIE1FTUJFUiBWQVIgSU5DTFVERVMKPiAtIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgVHJpZXMgdG8gZmluZCBpZiB0aGUg
ZmllbGQgTUVNQkVSIGV4aXN0cyBpbiB0eXBlIEFHR1IsIGFmdGVyIGluY2x1ZGluZwo+IC0jIElO
Q0xVREVTLCBzZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KPiAtYWNfZm5f
Y19jaGVja19tZW1iZXIgKCkKPiAtewo+IC0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBh
c19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKPiAtICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMi4kMyIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4kMy4uLiAiID4mNjsgfQo+IC1pZiBl
dmFsICJ0ZXN0IFwiXCR7JDQrc2V0fVwiIiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kNQo+IC1pbnQKPiAt
bWFpbiAoKQo+IC17Cj4gLXN0YXRpYyAkMiBhY19hZ2dyOwo+IC1pZiAoYWNfYWdnci4kMykKPiAt
cmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgZXZhbCAiJDQ9eWVzIgo+IC1l
bHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0v
KiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSQ1Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtc3Rh
dGljICQyIGFjX2FnZ3I7Cj4gLWlmIChzaXplb2YgYWNfYWdnci4kMykKPiAtcmV0dXJuIDA7Cj4g
LSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgZXZhbCAiJDQ9eWVzIgo+IC1lbHNlCj4gLSAgZXZh
bCAiJDQ9bm8iCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtZmkKPiAtZXZhbCBhY19yZXM9
XCQkNAo+IC0gICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQo+
IC0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAm
JiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Cj4gLQo+IC19ICMgYWNfZm5fY19jaGVj
a19tZW1iZXIKPiAtCj4gLSMgYWNfZm5fY19maW5kX3VpbnRYX3QgTElORU5PIEJJVFMgVkFSCj4g
LSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgRmluZHMgYW4gdW5z
aWduZWQgaW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJs
ZSBWQVIKPiAtIyBhY2NvcmRpbmdseS4KPiAtYWNfZm5fY19maW5kX3VpbnRYX3QgKCkKPiAtewo+
IC0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5v
X3N0YWNrPSRhc19saW5lbm9fc3RhY2sKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciB1aW50JDJfdC4uLiAiID4mNjsgfQo+IC1pZiBldmFsICJ0ZXN0IFwiXCR7JDMr
c2V0fVwiIiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAt
ZWxzZQo+IC0gIGV2YWwgIiQzPW5vIgo+IC0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2
ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgo+IC0gICAgICMgdGhh
biBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCj4gLSAgICAgZm9yIGFjX3R5cGUg
aW4gdWludCQyX3QgJ3Vuc2lnbmVkIGludCcgJ3Vuc2lnbmVkIGxvbmcgaW50JyBcCj4gLSAgICAg
ICAgJ3Vuc2lnbmVkIGxvbmcgbG9uZyBpbnQnICd1bnNpZ25lZCBzaG9ydCBpbnQnICd1bnNpZ25l
ZCBjaGFyJzsgZG8KPiAtICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVs
dAo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXN0YXRpYyBpbnQgdGVzdF9hcnJheSBbMSAtIDIg
KiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8gMiAtIDEpID09IDMp
XTsKPiAtdGVzdF9hcnJheSBbMF0gPSAwCj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+
IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0g
IGNhc2UgJGFjX3R5cGUgaW4gIygKPiAtICB1aW50JDJfdCkgOgo+IC0gICAgZXZhbCAiJDM9eWVz
IiA7OyAjKAo+IC0gICopIDoKPiAtICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKPiAtZXNhYwo+
IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKPiAtICAgICAgIGlmIGV2YWwgdGVzdCBcInhcJCIkMyJcIiA9IHgibm8iOyB0
aGVuIDoKPiAtCj4gLWVsc2UKPiAtICBicmVhawo+IC1maQo+IC0gICAgIGRvbmUKPiAtZmkKPiAt
ZXZhbCBhY19yZXM9XCQkMwo+IC0gICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19y
ZXMiID4mNjsgfQo+IC0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9f
c3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Cj4gLQo+IC19ICMg
YWNfZm5fY19maW5kX3VpbnRYX3QKPiAgY2F0ID5jb25maWcubG9nIDw8X0FDRU9GCj4gIFRoaXMg
ZmlsZSBjb250YWlucyBhbnkgbWVzc2FnZXMgcHJvZHVjZWQgYnkgY29tcGlsZXJzIHdoaWxlCj4g
IHJ1bm5pbmcgY29uZmlndXJlLCB0byBhaWQgZGVidWdnaW5nIGlmIGNvbmZpZ3VyZSBtYWtlcyBh
IG1pc3Rha2UuCj4gQEAgLTIzODYsMTEgKzIwNjMsNiBAQCAkYXNfZWNobyAiJGFzX21lOiBjcmVh
dGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KPiAgICA+JGNhY2hlX2ZpbGUKPiAgZmkKPiAK
PiAtYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3lzL3RpbWUuaCIKPiAtYXNfZm5fYXBw
ZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCj4gLWFzX2ZuX2FwcGVuZCBhY19mdW5jX2xp
c3QgIiBhbGFybSIKPiAtYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3RkbGliLmgiCj4g
LWFzX2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgo+ICAjIENoZWNrIHRo
YXQgdGhlIHByZWNpb3VzIHZhcmlhYmxlcyBzYXZlZCBpbiB0aGUgY2FjaGUgaGF2ZSBrZXB0IHRo
ZSBzYW1lCj4gICMgdmFsdWUuCj4gIGFjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQo+IEBAIC0yNTA4
LDE3MzAgKzIxODAsNDAgQEAgQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQg
d2hlbiBwb3NzaWJsZS4iID4mMjt9Cj4gCj4gIGZpCj4gCj4gLWFjX2V4dD1jCj4gLWFjX2NwcD0n
JENQUCAkQ1BQRkxBR1MnCj4gLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBj
b25mdGVzdC4kYWNfZXh0ID4mNScKPiAtYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScK
PiAtYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQo+IC1pZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNfd29yZD0kMgo+IC17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVu
Cj4gLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZv
ciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2Nj
Igo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAt
ZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+IC0KPiAtZmkKPiAtZmkKPiAtQ0M9
JGFjX2N2X3Byb2dfQ0MKPiAtaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQo+IC0kYXNfZWNo
byAiJENDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZp
Cj4gLQo+IC0KPiAtZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfQ0MiOyB0aGVuCj4gLSAg
YWNfY3RfQ0M9JENDCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgZ2NjOyBhY193
b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNl
dDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlm
IHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNf
Y3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+
IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv
bnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0g
ICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZl
X0lGUwo+IC0KPiAtZmkKPiAtZmkKPiAtYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKPiAt
aWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQo+IC0kYXNfZWNobyAiJGFj
X2N0X0NDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZp
Cj4gLQo+IC0gIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgo+IC0gICAgQ0M9IiIKPiAt
ICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4g
LXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
PiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp
eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsKPiAt
ZXNhYwo+IC0gICAgQ0M9JGFjX2N0X0NDCj4gLSAgZmkKPiAtZWxzZQo+IC0gIENDPSIkYWNfY3Zf
cHJvZ19DQyIKPiAtZmkKPiAtCj4gLWlmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiAtICAgICAgICAg
IGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAtICAgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193
b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhl
biA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9J
RlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1jYyIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+IC0gICAgYnJlYWsg
Mgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAtCj4gLWZp
Cj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KPiAt
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+
JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNobyAibm8i
ID4mNjsgfQo+IC1maQo+IC0KPiAtCj4gLSAgZmkKPiAtZmkKPiAtaWYgdGVzdCAteiAiJENDIjsg
dGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgY2M7IGFjX3dvcmQ9JDIKPiAt
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgo+IC0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gLWVsc2UKPiAtICBhY19wcm9nX3JlamVjdGVkPW5vCj4gLWFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0g
IElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0g
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4g
LSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgaWYgdGVz
dCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVuCj4g
LSAgICAgICBhY19wcm9nX3JlamVjdGVkPXllcwo+IC0gICAgICAgY29udGludWUKPiAtICAgICBm
aQo+IC0gICAgYWNfY3ZfcHJvZ19DQz0iY2MiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
PiAtICAgIGJyZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVf
SUZTCj4gLQo+IC1pZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCj4gLSAgIyBX
ZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0
Lgo+IC0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwo+IC0gIHNoaWZ0Cj4gLSAgaWYgdGVzdCAk
IyAhPSAwOyB0aGVuCj4gLSAgICAjIFdlIGNob3NlIGEgZGlmZmVyZW50IGNvbXBpbGVyIGZyb20g
dGhlIGJvZ3VzIG9uZS4KPiAtICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1l
LCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KPiAtICAgICMgZmlyc3QgaWYgd2Ugc2V0IEND
IHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgo+IC0gICAgc2hp
ZnQKPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgo+IC0g
IGZpCj4gLWZpCj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4g
IiRDQyI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+
IC0kYXNfZWNobyAibm8iID4mNjsgfQo+IC1maQo+IC0KPiAtCj4gLWZpCj4gLWlmIHRlc3QgLXog
IiRDQyI7IHRoZW4KPiAtICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAg
Zm9yIGFjX3Byb2cgaW4gY2wuZXhlCj4gLSAgZG8KPiAtICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFj
X3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0
aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVz
dCAtbiAiJENDIjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgo+IC1mb3IgYXNfZGlyIGluICRQQVRICj4gLWRvCj4gLSAgSUZTPSRhc19zYXZl
X0lGUwo+IC0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gLSAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAtICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX0NDPSIkYWNf
dG9vbF9wcmVmaXgkYWNfcHJvZyIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+IC0gICAg
YnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAt
Cj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4gIiRDQyI7IHRo
ZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNo
byAibm8iID4mNjsgfQo+IC1maQo+IC0KPiAtCj4gLSAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFr
Cj4gLSAgZG9uZQo+IC1maQo+IC1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCj4gLSAgYWNfY3RfQ0M9
JENDCj4gLSAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCj4gLWRvCj4gLSAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICIkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAkYWNfcHJvZzsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4g
LSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0
ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0
aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVf
SUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19wcm9nIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4g
LSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+IC0KPiAtZmkKPiAt
ZmkKPiAtYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKPiAtaWYgdGVzdCAtbiAiJGFjX2N0
X0NDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfQ0MiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KPiAt
ZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4gLQo+IC0KPiAtICB0ZXN0
IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCj4gLWRvbmUKPiAtCj4gLSAgaWYgdGVzdCAieCRhY19j
dF9DQyIgPSB4OyB0aGVuCj4gLSAgICBDQz0iIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3Nz
X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJO
SU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4m
Mjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBDQz0kYWNfY3RfQ0MK
PiAtICBmaQo+IC1maQo+IC0KPiAtZmkKPiAtCj4gLQo+IC10ZXN0IC16ICIkQ0MiICYmIHsgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdk
JzoiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9
Cj4gLWFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQ
QVRICj4gLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsg
fQo+IC0KPiAtIyBQcm92aWRlIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgo+
IC0kYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBj
b21waWxlciB2ZXJzaW9uIiA+JjUKPiAtc2V0IFggJGFjX2NvbXBpbGUKPiAtYWNfY29tcGlsZXI9
JDIKPiAtZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbwo+IC0g
IHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKPiAtY2FzZSAiKCgkYWNf
dHJ5IiBpbgo+IC0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owo+
IC0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+IC1lc2FjCj4gLWV2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCj4gLSRhc19l
Y2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+IC0gIChldmFsICIkYWNfY29tcGlsZXIgJGFjX29w
dGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gIGlmIHRlc3Qg
LXMgY29uZnRlc3QuZXJyOyB0aGVuCj4gLSAgICBzZWQgJzEwYVwKPiAtLi4uIHJlc3Qgb2Ygc3Rk
ZXJyIG91dHB1dCBkZWxldGVkIC4uLgo+IC0gICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29u
ZnRlc3QuZXIxCj4gLSAgICBjYXQgY29uZnRlc3QuZXIxID4mNQo+IC0gIGZpCj4gLSAgcm0gLWYg
Y29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgo+IC0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH0KPiAtZG9uZQo+IC0KPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC1pbnQKPiAtbWFpbiAoKQo+
IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtYWNfY2xlYW5f
ZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMKPiAtYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9m
aWxlcyBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGIub3V0Igo+IC0jIFRyeSB0byBjcmVhdGUgYW4g
ZXhlY3V0YWJsZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNyZWdhcmQgYS5vdXQuCj4gLSMgSXQgd2ls
bCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBjb21waWxlcnMsIGFuZCBmaW5kaW5nIG91dCBhbiBp
bnR1aXRpb24KPiAtIyBvZiBleGVleHQuCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3JrcyIgPiY1Cj4g
LSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MuLi4gIiA+
JjY7IH0KPiAtYWNfbGlua19kZWZhdWx0PWAkYXNfZWNobyAiJGFjX2xpbmsiIHwgc2VkICdzLyAt
byAqY29uZnRlc3RbXiBdKi8vJ2AKPiAtCj4gLSMgVGhlIHBvc3NpYmxlIG91dHB1dCBmaWxlczoK
PiAtYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBhLmV4ZSBhX291dC5leGUg
Yi5vdXQgY29uZnRlc3QuKiIKPiAtCj4gLWFjX3JtZmlsZXM9Cj4gLWZvciBhY19maWxlIGluICRh
Y19maWxlcwo+IC1kbwo+IC0gIGNhc2UgJGFjX2ZpbGUgaW4KPiAtICAgICouJGFjX2V4dCB8ICou
eGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5t
YXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKPiAtICAgICogKSBhY19ybWZp
bGVzPSIkYWNfcm1maWxlcyAkYWNfZmlsZSI7Owo+IC0gIGVzYWMKPiAtZG9uZQo+IC1ybSAtZiAk
YWNfcm1maWxlcwo+IC0KPiAtaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKPiAtY2Fz
ZSAiKCgkYWNfdHJ5IiBpbgo+IC0gICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7Owo+IC0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+IC1lc2FjCj4gLWV2YWwgYWNf
dHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIi
Cj4gLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+IC0gIChldmFsICIkYWNfbGlua19k
ZWZhdWx0IikgMj4mNQo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0
YXR1cyA9IDA7IH07IHRoZW4gOgo+IC0gICMgQXV0b2NvbmYtMi4xMyBjb3VsZCBzZXQgdGhlIGFj
X2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgo+IC0jIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBu
bycsIG90aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQgdG8gYEVYRUVYVCA9IG5vJwo+IC0jIGluIGEg
TWFrZWZpbGUuICBXZSBzaG91bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4ZWV4dCBpZiBpdCB3YXMg
Y2FjaGVkLAo+IC0jIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNob3J0LWNpcmN1aXQgdGhpcyB0ZXN0
IGZvciBjb21waWxlcnMgdW5rbm93biB0bwo+IC0jIEF1dG9jb25mLgo+IC1mb3IgYWNfZmlsZSBp
biAkYWNfZmlsZXMgJycKPiAtZG8KPiAtICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUK
PiAtICBjYXNlICRhY19maWxlIGluCj4gLSAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMg
fCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAq
LmRTWU0gfCAqLm8gfCAqLm9iaiApCj4gLSAgICAgICA7Owo+IC0gICAgW2FiXS5vdXQgKQo+IC0g
ICAgICAgIyBXZSBmb3VuZCB0aGUgZGVmYXVsdCBleGVjdXRhYmxlLCBidXQgZXhlZXh0PScnIGlz
IG1vc3QKPiAtICAgICAgICMgY2VydGFpbmx5IHJpZ2h0Lgo+IC0gICAgICAgYnJlYWs7Owo+IC0g
ICAgKi4qICkKPiAtICAgICAgIGlmIHRlc3QgIiR7YWNfY3ZfZXhlZXh0K3NldH0iID0gc2V0ICYm
IHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5vOwo+IC0gICAgICAgdGhlbiA6OyBlbHNlCj4gLSAg
ICAgICAgICBhY19jdl9leGVleHQ9YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AK
PiAtICAgICAgIGZpCj4gLSAgICAgICAjIFdlIHNldCBhY19jdl9leGVleHQgaGVyZSBiZWNhdXNl
IHRoZSBsYXRlciB0ZXN0IGZvciBpdCBpcyBub3QKPiAtICAgICAgICMgc2FmZTogY3Jvc3MgY29t
cGlsZXJzIG1heSBub3QgYWRkIHRoZSBzdWZmaXggaWYgZ2l2ZW4gYW4gYC1vJwo+IC0gICAgICAg
IyBhcmd1bWVudCwgc28gd2UgbWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVh
ZHkuCj4gLSAgICAgICAjIEV2ZW4gaWYgdGhpcyBzZWN0aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFz
IHRoZSBhZHZhbnRhZ2Ugb2YKPiAtICAgICAgICMgYWN0dWFsbHkgd29ya2luZy4KPiAtICAgICAg
IGJyZWFrOzsKPiAtICAgICogKQo+IC0gICAgICAgYnJlYWs7Owo+IC0gIGVzYWMKPiAtZG9uZQo+
IC10ZXN0ICIkYWNfY3ZfZXhlZXh0IiA9IG5vICYmIGFjX2N2X2V4ZWV4dD0KPiAtCj4gLWVsc2UK
PiAtICBhY19maWxlPScnCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRhY19maWxlIjsgdGhlbiA6Cj4g
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHBy
b2dyYW0gd2FzOiIgPiY1Cj4gLXNlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKPiAt
Cj4gLXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4g
XGAkYWNfcHdkJzoiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdk
JzoiID4mMjt9Cj4gLWFzX2ZuX2Vycm9yIDc3ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhl
Y3V0YWJsZXMKPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDUgOyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKPiAtJGFzX2VjaG8gInllcyIgPiY2OyB9Cj4gLWZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29t
cGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lLi4uICIgPiY2OyB9Cj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfZmls
ZSIgPiY1Cj4gLSRhc19lY2hvICIkYWNfZmlsZSIgPiY2OyB9Cj4gLWFjX2V4ZWV4dD0kYWNfY3Zf
ZXhlZXh0Cj4gLQo+IC1ybSAtZiAtciBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGNvbmZ0ZXN0JGFj
X2N2X2V4ZWV4dCBiLm91dAo+IC1hY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBz
dWZmaXggb2YgZXhlY3V0YWJsZXMiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3Vm
Zml4IG9mIGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9Cj4gLWlmIHsgeyBhY190cnk9IiRhY19saW5r
Igo+IC1jYXNlICIoKCRhY190cnkiIGluCj4gLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlf
ZWNobz1cJGFjX3RyeTs7Cj4gLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gLWVzYWMKPiAt
ZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5
X2VjaG9cIiIKPiAtJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cj4gLSAgKGV2YWwgIiRh
Y19saW5rIikgMj4mNQo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0
YXR1cyA9IDA7IH07IHRoZW4gOgo+IC0gICMgSWYgYm90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNv
bmZ0ZXN0JyBhcmUgYHByZXNlbnQnICh3ZWxsLCBvYnNlcnZhYmxlKQo+IC0jIGNhdGNoIGBjb25m
dGVzdC5leGUnLiAgRm9yIGluc3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3QnIHdpbGwK
PiAtIyB3b3JrIHByb3Blcmx5IChpLmUuLCByZWZlciB0byBgY29uZnRlc3QuZXhlJyksIHdoaWxl
IGl0IHdvbid0IHdpdGgKPiAtIyBgcm0nLgo+IC1mb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUg
Y29uZnRlc3QgY29uZnRlc3QuKjsgZG8KPiAtICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGlu
dWUKPiAtICBjYXNlICRhY19maWxlIGluCj4gLSAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50
ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYg
fCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7Cj4gLSAgICAqLiogKSBhY19jdl9leGVleHQ9YGV4
cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKPiAtICAgICAgICAgYnJlYWs7Owo+IC0g
ICAgKiApIGJyZWFrOzsKPiAtICBlc2FjCj4gLWRvbmUKPiAtZWxzZQo+IC0gIHsgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
NQo+IC0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cj4gLWFz
X2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0YWJsZXM6IGNhbm5v
dCBjb21waWxlIGFuZCBsaW5rCj4gLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMi
ICIkTElORU5PIiA1IDsgfQo+IC1maQo+IC1ybSAtZiBjb25mdGVzdCBjb25mdGVzdCRhY19jdl9l
eGVleHQKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9leGVleHQiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9Cj4g
LQo+IC1ybSAtZiBjb25mdGVzdC4kYWNfZXh0Cj4gLUVYRUVYVD0kYWNfY3ZfZXhlZXh0Cj4gLWFj
X2V4ZWV4dD0kRVhFRVhUCj4gLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaW5jbHVkZSA8c3RkaW8uaD4KPiAt
aW50Cj4gLW1haW4gKCkKPiAtewo+IC1GSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5vdXQiLCAi
dyIpOwo+IC0gcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAwOwo+IC0KPiAtICA7
Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWFjX2NsZWFuX2ZpbGVzPSIkYWNfY2xl
YW5fZmlsZXMgY29uZnRlc3Qub3V0Igo+IC0jIENoZWNrIHRoYXQgdGhlIGNvbXBpbGVyIHByb2R1
Y2VzIGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBub3QsIGVpdGhlcgo+IC0jIHRoZSBjb21w
aWxlciBpcyBicm9rZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCj4gLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29t
cGlsaW5nIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3Mg
Y29tcGlsaW5nLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciICE9IHll
czsgdGhlbgo+IC0gIHsgeyBhY190cnk9IiRhY19saW5rIgo+IC1jYXNlICIoKCRhY190cnkiIGlu
Cj4gLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cj4gLSAgKikg
YWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gLWVzYWMKPiAtZXZhbCBhY190cnlfZWNobz0iXCJcJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiAtJGFzX2VjaG8gIiRh
Y190cnlfZWNobyI7IH0gPiY1Cj4gLSAgKGV2YWwgIiRhY19saW5rIikgMj4mNQo+IC0gIGFjX3N0
YXR1cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KPiAtICBpZiB7IGFj
X3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVleHQnCj4gLSAgeyB7IGNhc2UgIigoJGFjX3RyeSIg
aW4KPiAtICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKPiAtICAq
KSBhY190cnlfZWNobz0kYWNfdHJ5OzsKPiAtZXNhYwo+IC1ldmFsIGFjX3RyeV9lY2hvPSJcIlwk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgo+IC0kYXNfZWNobyAi
JGFjX3RyeV9lY2hvIjsgfSA+JjUKPiAtICAoZXZhbCAiJGFjX3RyeSIpIDI+JjUKPiAtICBhY19z
dGF0dXM9JD8KPiAtICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8g
PSAkYWNfc3RhdHVzIiA+JjUKPiAtICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9OyB0aGVuCj4g
LSAgICBjcm9zc19jb21waWxpbmc9bm8KPiAtICBlbHNlCj4gLSAgICBpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiA9IG1heWJlOyB0aGVuCj4gLSAgICAgICBjcm9zc19jb21waWxpbmc9eWVzCj4g
LSAgICBlbHNlCj4gLSAgICAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogZXJy
b3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+IC1hc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biBD
IGNvbXBpbGVkIHByb2dyYW1zLgo+IC1JZiB5b3UgbWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNl
IFxgLS1ob3N0Jy4KPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5F
Tk8iIDUgOyB9Cj4gLSAgICBmaQo+IC0gIGZpCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkY3Jvc3NfY29tcGlsaW5nIiA+JjUKPiAtJGFz
X2VjaG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQo+IC0KPiAtcm0gLWYgY29uZnRlc3QuJGFj
X2V4dCBjb25mdGVzdCRhY19jdl9leGVleHQgY29uZnRlc3Qub3V0Cj4gLWFjX2NsZWFuX2ZpbGVz
PSRhY19jbGVhbl9maWxlc19zYXZlCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXMiID4mNQo+IC0kYXNf
ZWNob19uICJjaGVja2luZyBmb3Igc3VmZml4IG9mIG9iamVjdCBmaWxlcy4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAtaW50
Cj4gLW1haW4gKCkKPiAtewo+IC0KPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9G
Cj4gLXJtIC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqCj4gLWlmIHsgeyBhY190cnk9IiRhY19j
b21waWxlIgo+IC1jYXNlICIoKCRhY190cnkiIGluCj4gLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBh
Y190cnlfZWNobz1cJGFjX3RyeTs7Cj4gLSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gLWVz
YWMKPiAtZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAk
YWNfdHJ5X2VjaG9cIiIKPiAtJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cj4gLSAgKGV2
YWwgIiRhY19jb21waWxlIikgMj4mNQo+IC0gIGFjX3N0YXR1cz0kPwo+IC0gICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+IC0gIHRl
c3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgo+IC0gIGZvciBhY19maWxlIGluIGNvbmZ0ZXN0
Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCj4gLSAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8
IGNvbnRpbnVlOwo+IC0gIGNhc2UgJGFjX2ZpbGUgaW4KPiAtICAgICouJGFjX2V4dCB8ICoueGNv
ZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAg
fCAqLmluZiB8ICouZFNZTSApIDs7Cj4gLSAgICAqKSBhY19jdl9vYmpleHQ9YGV4cHIgIiRhY19m
aWxlIiA6ICcuKlwuXCguKlwpJ2AKPiAtICAgICAgIGJyZWFrOzsKPiAtICBlc2FjCj4gLWRvbmUK
PiAtZWxzZQo+IC0gICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQo+
IC1zZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1Cj4gLQo+IC17IHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUK
PiAtJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+IC1hc19m
bl9lcnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIG9iamVjdCBmaWxlczogY2Fubm90
IGNvbXBpbGUKPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDUgOyB9Cj4gLWZpCj4gLXJtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFj
X2V4dAo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X29iamV4dCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7
IH0KPiAtT0JKRVhUPSRhY19jdl9vYmpleHQKPiAtYWNfb2JqZXh0PSRPQkpFWFQKPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFy
ZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyB3
aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAt
aW50Cj4gLW1haW4gKCkKPiAtewo+IC0jaWZuZGVmIF9fR05VQ19fCj4gLSAgICAgICBjaG9rZSBt
ZQo+IC0jZW5kaWYKPiAtCj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1p
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY29tcGlsZXJf
Z251PXllcwo+IC1lbHNlCj4gLSAgYWNfY29tcGlsZXJfZ251PW5vCj4gLWZpCj4gLXJtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1h
Y19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251Cj4gLQo+IC1maQo+IC17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGls
ZXJfZ251IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9Cj4g
LWlmIHRlc3QgJGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhlbgo+IC0gIEdDQz15ZXMKPiAtZWxz
ZQo+IC0gIEdDQz0KPiAtZmkKPiAtYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQo+IC1hY19z
YXZlX0NGTEFHUz0kQ0ZMQUdTCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1Cj4gLSRhc19lY2hvX24g
ImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9JGFjX2Nfd2Vy
cm9yX2ZsYWcKPiAtICAgYWNfY193ZXJyb3JfZmxhZz15ZXMKPiAtICAgYWNfY3ZfcHJvZ19jY19n
PW5vCj4gLSAgIENGTEFHUz0iLWciCj4gLSAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAtaW50Cj4gLW1h
aW4gKCkKPiAtewo+IC0KPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlm
IGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9wcm9nX2Nj
X2c9eWVzCj4gLWVsc2UKPiAtICBDRkxBR1M9IiIKPiAtICAgICAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+
IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1f
QUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0KPiAt
ZWxzZQo+IC0gIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwo+IC0gICAg
ICAgIENGTEFHUz0iLWciCj4gLSAgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC1pbnQKPiAtbWFp
biAoKQo+IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X3Byb2dfY2Nf
Zz15ZXMKPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICAgYWNfY193
ZXJyb3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUK
PiAtJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQo+IC1pZiB0ZXN0ICIkYWNfdGVz
dF9DRkxBR1MiID0gc2V0OyB0aGVuCj4gLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwo+IC1lbGlm
IHRlc3QgJGFjX2N2X3Byb2dfY2NfZyA9IHllczsgdGhlbgo+IC0gIGlmIHRlc3QgIiRHQ0MiID0g
eWVzOyB0aGVuCj4gLSAgICBDRkxBR1M9Ii1nIC1PMiIKPiAtICBlbHNlCj4gLSAgICBDRkxBR1M9
Ii1nIgo+IC0gIGZpCj4gLWVsc2UKPiAtICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgo+IC0g
ICAgQ0ZMQUdTPSItTzIiCj4gLSAgZWxzZQo+IC0gICAgQ0ZMQUdTPQo+IC0gIGZpCj4gLWZpCj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfY2NfYzg5K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgYWNfY3ZfcHJvZ19jY19jODk9bm8KPiAtYWNfc2F2
ZV9DQz0kQ0MKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+
IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRlIDxzdGRhcmcuaD4KPiAtI2luY2x1
ZGUgPHN0ZGlvLmg+Cj4gLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KPiAtI2luY2x1ZGUgPHN5cy9z
dGF0Lmg+Cj4gLS8qIE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20g
UkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KPiAtc3RydWN0IGJ1ZiB7IGludCB4OyB9Owo+IC1G
SUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOwo+IC1z
dGF0aWMgY2hhciAqZSAocCwgaSkKPiAtICAgICBjaGFyICoqcDsKPiAtICAgICBpbnQgaTsKPiAt
ewo+IC0gIHJldHVybiBwW2ldOwo+IC19Cj4gLXN0YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAo
Y2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikKPiAtewo+IC0gIGNoYXIgKnM7Cj4gLSAgdmFf
bGlzdCB2Owo+IC0gIHZhX3N0YXJ0ICh2LHApOwo+IC0gIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50
KSk7Cj4gLSAgdmFfZW5kICh2KTsKPiAtICByZXR1cm4gczsKPiAtfQo+IC0KPiAtLyogT1NGIDQu
MCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBo
YXMKPiAtICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhl
eCBjaGFyYWN0ZXIgY29uc3RhbnRzLgo+IC0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9y
IHVuZm9ydHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKPiAtICAgYXMgJ3gn
LiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRv
IGdldAo+IC0gICBwcm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5
cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCj4gLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdz
IG5lY2Vzc2FyeSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZwo+IC0gICB0aGF0
J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICovCj4gLWludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcg
PT0gMCA/IDEgOiAtMV07Cj4gLQo+IC0vKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kg
YnkgZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKPiAtICAgaW5zaWRl
IHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwo+IC0jZGVmaW5lIEZPTyh4KSAn
eCcKPiAtaW50IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07Cj4gLQo+IC1p
bnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsKPiAtc3RydWN0IHMxIHtpbnQgKCpmKSAoaW50IGEp
O307Cj4gLXN0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9Owo+IC1pbnQgcGFpcm5hbWVz
IChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGlu
dCksIGludCwgaW50KTsKPiAtaW50IGFyZ2M7Cj4gLWNoYXIgKiphcmd2Owo+IC1pbnQKPiAtbWFp
biAoKQo+IC17Cj4gLXJldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwg
YXJndiwgMSkgIT0gYXJndlsxXTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9G
Cj4gLWZvciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3Rk
IFwKPiAtICAgICAgIC1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05T
X18iCj4gLWRvCj4gLSAgQ0M9IiRhY19zYXZlX0NDICRhY19hcmciCj4gLSAgaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19h
cmcKPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAo+
IC0gIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCj4gLWRvbmUK
PiAtcm0gLWYgY29uZnRlc3QuJGFjX2V4dAo+IC1DQz0kYWNfc2F2ZV9DQwo+IC0KPiAtZmkKPiAt
IyBBQ19DQUNIRV9WQUwKPiAtY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KPiAtICB4KQo+
IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
bmUgbmVlZGVkIiA+JjUKPiAtJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKPiAtICB4
bm8pCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogdW5zdXBwb3J0ZWQiID4mNQo+IC0kYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7Owo+
IC0gICopCj4gLSAgICBDQz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKPiAtICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19j
ODkiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0gOzsKPiAtZXNh
Ywo+IC1pZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgo+IC0KPiAt
ZmkKPiAtCj4gLWFjX2V4dD1jCj4gLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCj4gLWFjX2NvbXBp
bGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKPiAtYWNf
bGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFH
UyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKPiAtYWNfY29tcGlsZXJfZ251PSRhY19jdl9j
X2NvbXBpbGVyX2dudQo+IC0KPiAtCj4gLWFjX2V4dD1jCj4gLWFjX2NwcD0nJENQUCAkQ1BQRkxB
R1MnCj4gLWFjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ID4mNScKPiAtYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRD
UFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKPiAtYWNfY29tcGls
ZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+
JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3Iu
Li4gIiA+JjY7IH0KPiAtIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1lcyBhIGRpcmVjdG9y
eS4KPiAtaWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KPiAtICBDUFA9
Cj4gLWZpCj4gLWlmIHRlc3QgLXogIiRDUFAiOyB0aGVuCj4gLSAgaWYgdGVzdCAiJHthY19jdl9w
cm9nX0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKPiAtZWxzZQo+IC0gICAgICAjIERvdWJsZSBxdW90ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8g
YmUgZXhwYW5kZWQKPiAtICAgIGZvciBDUFAgaW4gIiRDQyAtRSIgIiRDQyAtRSAtdHJhZGl0aW9u
YWwtY3BwIiAiL2xpYi9jcHAiCj4gLSAgICBkbwo+IC0gICAgICBhY19wcmVwcm9jX29rPWZhbHNl
Cj4gLWZvciBhY19jX3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwo+IC1kbwo+IC0gICMgVXNl
IGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMK
PiAtICAjIHdpdGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jrcy4KPiAtICAjIFByZWZlciA8
bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKPiAt
ICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KPiAt
ICAjIE9uIHRoZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVy
J3MgcGFyc2VyLAo+IC0gICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlz
IGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaWZkZWYgX19T
VERDX18KPiAtIyBpbmNsdWRlIDxsaW1pdHMuaD4KPiAtI2Vsc2UKPiAtIyBpbmNsdWRlIDxhc3Nl
cnQuaD4KPiAtI2VuZGlmCj4gLSAgICAgICAgICAgICAgICAgICAgU3ludGF4IGVycm9yCj4gLV9B
Q0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKPiAtCj4gLWVsc2UK
PiAtICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCj4gLWNvbnRpbnVlCj4gLWZpCj4g
LXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKPiAtCj4gLSAg
IyBPSywgd29ya3Mgb24gc2FuZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50
IGhlYWRlcnMKPiAtICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93Lgo+IC0gIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAq
Lwo+IC0jaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+IC0gICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFs
aWQgaW5wdXQuCj4gLWNvbnRpbnVlCj4gLWVsc2UKPiAtICAjIFBhc3NlcyBib3RoIHRlc3RzLgo+
IC1hY19wcmVwcm9jX29rPToKPiAtYnJlYWsKPiAtZmkKPiAtcm0gLWYgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAo+IC0KPiAtZG9uZQo+IC0jIEJlY2F1c2Ugb2YgYGJy
ZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KPiAt
cm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX2V4dAo+IC1pZiAkYWNf
cHJlcHJvY19vazsgdGhlbiA6Cj4gLSAgYnJlYWsKPiAtZmkKPiAtCj4gLSAgICBkb25lCj4gLSAg
ICBhY19jdl9wcm9nX0NQUD0kQ1BQCj4gLQo+IC1maQo+IC0gIENQUD0kYWNfY3ZfcHJvZ19DUFAK
PiAtZWxzZQo+IC0gIGFjX2N2X3Byb2dfQ1BQPSRDUFAKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDUFAiID4mNQo+IC0kYXNfZWNobyAi
JENQUCIgPiY2OyB9Cj4gLWFjX3ByZXByb2Nfb2s9ZmFsc2UKPiAtZm9yIGFjX2NfcHJlcHJvY193
YXJuX2ZsYWcgaW4gJycgeWVzCj4gLWRvCj4gLSAgIyBVc2UgYSBoZWFkZXIgZmlsZSB0aGF0IGNv
bWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGliYwo+IC0gICMgd2l0aCBhIGZyZXNoIGNy
b3NzLWNvbXBpbGVyIHdvcmtzLgo+IC0gICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5o
PiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQo+IC0gICMgPGxpbWl0cy5oPiBleGlzdHMg
ZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgo+IC0gICMgT24gdGhlIE5lWFQsIGNjIC1F
IHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCj4gLSAgIyBub3Qg
anVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNh
c2UuCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0v
KiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpZmRlZiBfX1NURENfXwo+IC0jIGluY2x1ZGUgPGxp
bWl0cy5oPgo+IC0jZWxzZQo+IC0jIGluY2x1ZGUgPGFzc2VydC5oPgo+IC0jZW5kaWYKPiAtICAg
ICAgICAgICAgICAgICAgICBTeW50YXggZXJyb3IKPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5
X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+IC0KPiAtZWxzZQo+IC0gICMgQnJva2VuOiBmYWlscyBv
biB2YWxpZCBpbnB1dC4KPiAtY29udGludWUKPiAtZmkKPiAtcm0gLWYgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAo+IC0KPiAtICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNh
c2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwo+IC0gICMgY2FuIGJl
IGRldGVjdGVkIGFuZCBob3cuCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRlIDxhY19ub25l
eGlzdGVudC5oPgo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6Cj4gLSAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KPiAtY29udGludWUK
PiAtZWxzZQo+IC0gICMgUGFzc2VzIGJvdGggdGVzdHMuCj4gLWFjX3ByZXByb2Nfb2s9Ogo+IC1i
cmVhawo+IC1maQo+IC1ybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNf
ZXh0Cj4gLQo+IC1kb25lCj4gLSMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVM
U0UncyBjbGVhbmluZyBjb2RlIHdhcyBza2lwcGVkLgo+IC1ybSAtZiBjb25mdGVzdC5pIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0Cj4gLWlmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKPiAt
Cj4gLWVsc2UKPiAtICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGlu
IFxgJGFjX3B3ZCc6IiA+JjI7fQo+IC1hc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIk
Q1BQXCIgZmFpbHMgc2FuaXR5IGNoZWNrCj4gLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRl
dGFpbHMiICIkTElORU5PIiA1IDsgfQo+IC1maQo+IC0KPiAtYWNfZXh0PWMKPiAtYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKPiAtYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNv
bmZ0ZXN0LiRhY19leHQgPiY1Jwo+IC1hY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0
ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1Jwo+
IC1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cj4gLQo+IC0KPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3JlcCB0aGF0
IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBm
b3IgZ3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUuLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl9wYXRoX0dSRVArc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4K
PiAtICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UKPiAtICAjIExvb3AgdGhyb3VnaCB0aGUgdXNl
cidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAo+IC0gIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRI
X1NFUEFSQVRPUi91c3IveHBnNC9iaW4KPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19wcm9nIGluIGdyZXAg
Z2dyZXA7IGRvCj4gLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KPiAtICAgICAgYWNfcGF0aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4
ZWNfZXh0Igo+IC0gICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3gg
IiRhY19wYXRoX0dSRVAiOyB9IHx8IGNvbnRpbnVlCj4gLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRo
X0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KPiAtICAjIENoZWNrIGZvciBHTlUg
JGFjX3BhdGhfR1JFUAo+IC1jYXNlIGAiJGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGlu
Cj4gLSpHTlUqKQo+IC0gIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9H
UkVQX2ZvdW5kPTo7Owo+IC0qKQo+IC0gIGFjX2NvdW50PTAKPiAtICAkYXNfZWNob19uIDAxMjM0
NTY3ODkgPiJjb25mdGVzdC5pbiIKPiAtICB3aGlsZSA6Cj4gLSAgZG8KPiAtICAgIGNhdCAiY29u
ZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCj4gLSAgICBtdiAiY29uZnRl
c3QudG1wIiAiY29uZnRlc3QuaW4iCj4gLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5u
bCIKPiAtICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCj4gLSAgICAiJGFjX3Bh
dGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gpLScgPCAiY29uZnRlc3Qubmwi
ID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawo+IC0gICAgZGlmZiAiY29uZnRl
c3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhawo+IC0gICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCj4gLSAgICBpZiB0ZXN0
ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCj4gLSAgICAgICMgQmVz
dCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQo+
IC0gICAgICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiCj4gLSAgICAgIGFjX3BhdGhf
R1JFUF9tYXg9JGFjX2NvdW50Cj4gLSAgICBmaQo+IC0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMg
aW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAo+IC0gICAgdGVzdCAkYWNfY291bnQgLWd0IDEw
ICYmIGJyZWFrCj4gLSAgZG9uZQo+IC0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBj
b25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7Owo+IC1lc2FjCj4gLQo+IC0gICAgICAkYWNfcGF0aF9H
UkVQX2ZvdW5kICYmIGJyZWFrIDMKPiAtICAgIGRvbmUKPiAtICBkb25lCj4gLSAgZG9uZQo+IC1J
RlM9JGFzX3NhdmVfSUZTCj4gLSAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4K
PiAtICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGdyZXAgY291bGQgYmUgZm91bmQg
aW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQo+IC0gIGZp
Cj4gLWVsc2UKPiAtICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKPiAtZmkKPiAtCj4gLWZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0
aF9HUkVQIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9wYXRoX0dSRVAiID4mNjsgfQo+IC0gR1JF
UD0iJGFjX2N2X3BhdGhfR1JFUCIKPiAtCj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfRUdS
RVArc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4g
LWVsc2UKPiAtICBpZiBlY2hvIGEgfCAkR1JFUCAtRSAnKGF8YiknID4vZGV2L251bGwgMj4mMQo+
IC0gICB0aGVuIGFjX2N2X3BhdGhfRUdSRVA9IiRHUkVQIC1FIgo+IC0gICBlbHNlCj4gLSAgICAg
aWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgo+IC0gIGFjX3BhdGhfRUdSRVBfZm91bmQ9ZmFsc2UK
PiAtICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2Yg
UFJPR05BTUUtTElTVAo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
PiAtZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KPiAtZG8K
PiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
PiAtICAgIGZvciBhY19wcm9nIGluIGVncmVwOyBkbwo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgICAgIGFjX3BhdGhfRUdSRVA9
IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCj4gLSAgICAgIHsgdGVzdCAtZiAiJGFjX3Bh
dGhfRUdSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQo+
IC0jIENoZWNrIGZvciBHTlUgYWNfcGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZv
dW5kLgo+IC0gICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9FR1JFUAo+IC1jYXNlIGAiJGFjX3Bh
dGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgo+IC0qR05VKikKPiAtICBhY19jdl9wYXRoX0VH
UkVQPSIkYWNfcGF0aF9FR1JFUCIgYWNfcGF0aF9FR1JFUF9mb3VuZD06OzsKPiAtKikKPiAtICBh
Y19jb3VudD0wCj4gLSAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCj4gLSAg
d2hpbGUgOgo+IC0gIGRvCj4gLSAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4i
Y29uZnRlc3QudG1wIgo+IC0gICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgo+IC0g
ICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCj4gLSAgICAkYXNfZWNobyAnRUdSRVAn
ID4+ICJjb25mdGVzdC5ubCIKPiAtICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29u
ZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawo+IC0gICAgZGlm
ZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhawo+
IC0gICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCj4gLSAg
ICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgo+IC0g
ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl
dHRlciBvbmUKPiAtICAgICAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiCj4gLSAg
ICAgIGFjX3BhdGhfRUdSRVBfbWF4PSRhY19jb3VudAo+IC0gICAgZmkKPiAtICAgICMgMTAqKDJe
MTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKPiAtICAgIHRlc3QgJGFj
X2NvdW50IC1ndCAxMCAmJiBicmVhawo+IC0gIGRvbmUKPiAtICBybSAtZiBjb25mdGVzdC5pbiBj
b25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKPiAtZXNhYwo+IC0KPiAtICAg
ICAgJGFjX3BhdGhfRUdSRVBfZm91bmQgJiYgYnJlYWsgMwo+IC0gICAgZG9uZQo+IC0gIGRvbmUK
PiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAtICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9FR1JFUCI7IHRoZW4KPiAtICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGVncmVw
IGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRM
SU5FTk8iIDUKPiAtICBmaQo+IC1lbHNlCj4gLSAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAKPiAt
ZmkKPiAtCj4gLSAgIGZpCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9FR1JFUCIgPiY1Cj4gLSRhc19lY2hvICIkYWNf
Y3ZfcGF0aF9FR1JFUCIgPiY2OyB9Cj4gLSBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCj4gLQo+
IC0KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgQU5TSSBDIGhlYWRlciBmaWxlcyIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBB
TlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVy
X3N0ZGMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Cj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN0ZGxpYi5oPgo+IC0jaW5j
bHVkZSA8c3RkYXJnLmg+Cj4gLSNpbmNsdWRlIDxzdHJpbmcuaD4KPiAtI2luY2x1ZGUgPGZsb2F0
Lmg+Cj4gLQo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLQo+IC0gIDsKPiAtICByZXR1cm4gMDsK
PiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
Ogo+IC0gIGFjX2N2X2hlYWRlcl9zdGRjPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfaGVhZGVyX3N0
ZGM9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0Cj4gLQo+IC1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHll
czsgdGhlbgo+IC0gICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwg
Y29udHJhcnkgdG8gQU5TSS4KPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN0cmluZy5o
Pgo+IC0KPiAtX0FDRU9GCj4gLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAy
PiY1IHwKPiAtICAkRUdSRVAgIm1lbWNociIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKPiAtCj4g
LWVsc2UKPiAtICBhY19jdl9oZWFkZXJfc3RkYz1ubwo+IC1maQo+IC1ybSAtZiBjb25mdGVzdCoK
PiAtCj4gLWZpCj4gLQo+IC1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgo+
IC0gICMgSVNDIDIuMC4yIHN0ZGxpYi5oIGRvZXMgbm90IGRlY2xhcmUgZnJlZSwgY29udHJhcnkg
dG8gQU5TSS4KPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN0ZGxpYi5oPgo+IC0KPiAt
X0FDRU9GCj4gLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKPiAt
ICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAg
YWNfY3ZfaGVhZGVyX3N0ZGM9bm8KPiAtZmkKPiAtcm0gLWYgY29uZnRlc3QqCj4gLQo+IC1maQo+
IC0KPiAtaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiAtICAjIC9iaW4v
Y2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcg
LWFuc2kuCj4gLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0g
IDoKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaW5jbHVkZSA8Y3R5cGUuaD4KPiAtI2lu
Y2x1ZGUgPHN0ZGxpYi5oPgo+IC0jaWYgKCgnICcgJiAweDBGRikgPT0gMHgwMjApCj4gLSMgZGVm
aW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykKPiAtIyBkZWZpbmUgVE9V
UFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMpKQo+IC0jZWxzZQo+
IC0jIGRlZmluZSBJU0xPV0VSKGMpIFwKPiAtICAgICAgICAgICAgICAgICAgKCgnYScgPD0gKGMp
ICYmIChjKSA8PSAnaScpIFwKPiAtICAgICAgICAgICAgICAgICAgICB8fCAoJ2onIDw9IChjKSAm
JiAoYykgPD0gJ3InKSBcCj4gLSAgICAgICAgICAgICAgICAgICAgfHwgKCdzJyA8PSAoYykgJiYg
KGMpIDw9ICd6JykpCj4gLSMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAoKGMpIHwg
MHg0MCkgOiAoYykpCj4gLSNlbmRpZgo+IC0KPiAtI2RlZmluZSBYT1IoZSwgZikgKCgoZSkgJiYg
IShmKSkgfHwgKCEoZSkgJiYgKGYpKSkKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC0gIGludCBp
Owo+IC0gIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKPiAtICAgIGlmIChYT1IgKGlzbG93ZXIg
KGkpLCBJU0xPV0VSIChpKSkKPiAtICAgICAgIHx8IHRvdXBwZXIgKGkpICE9IFRPVVBQRVIgKGkp
KQo+IC0gICAgICByZXR1cm4gMjsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYg
YWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLQo+IC1lbHNlCj4gLSAgYWNfY3Zf
aGVhZGVyX3N0ZGM9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4q
IGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+IC0gIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gLQo+IC1maQo+IC1m
aQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2hlYWRlcl9zdGRjIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3RkYyIgPiY2
OyB9Cj4gLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCj4gLQo+IC0kYXNf
ZWNobyAiI2RlZmluZSBTVERDX0hFQURFUlMgMSIgPj5jb25mZGVmcy5oCj4gLQo+IC1maQo+IC0K
PiAtIyBPbiBJUklYIDUuMywgc3lzL3R5cGVzIGFuZCBpbnR0eXBlcy5oIGFyZSBjb25mbGljdGlu
Zy4KPiAtZm9yIGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5oIHN0
cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBcCj4gLSAgICAgICAgICAgICAgICAgaW50dHlwZXMu
aCBzdGRpbnQuaCB1bmlzdGQuaAo+IC1kbyA6Cj4gLSAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAi
YWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAo+IC1hY19mbl9jX2NoZWNrX2hl
YWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNf
aW5jbHVkZXNfZGVmYXVsdAo+IC0iCj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVy
IlwiID0geCJ5ZXMiOyB0aGVuIDoKPiAtICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNk
ZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQo+IC1fQUNF
T0YKPiAtCj4gLWZpCj4gLQo+IC1kb25lCj4gLQo+IC0KPiAtCj4gLSAgYWNfZm5fY19jaGVja19o
ZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIm1pbml4L2NvbmZpZy5oIiAiYWNfY3ZfaGVhZGVyX21p
bml4X2NvbmZpZ19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3Zf
aGVhZGVyX21pbml4X2NvbmZpZ19oIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgTUlOSVg9eWVzCj4g
LWVsc2UKPiAtICBNSU5JWD0KPiAtZmkKPiAtCj4gLQo+IC0gIGlmIHRlc3QgIiRNSU5JWCIgPSB5
ZXM7IHRoZW4KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIgPj5jb25m
ZGVmcy5oCj4gLQo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+
Y29uZmRlZnMuaAo+IC0KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZk
ZWZzLmgKPiAtCj4gLSAgZmkKPiAtCj4gLQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VY
VEVOU0lPTlNfXyIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2Fm
ZSB0byBkZWZpbmUgX19FWFRFTlNJT05TX18uLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19j
dl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0K
PiAtIyAgICAgICAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKPiAtICAgICAgICAgJGFjX2luY2x1
ZGVzX2RlZmF1bHQKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC0KPiAtICA7Cj4gLSAgcmV0dXJu
IDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKPiAtICBhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXz15ZXMKPiAtZWxz
ZQo+IC0gIGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fPW5vCj4gLWZpCj4gLXJt
IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4
dAo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fIiA+JjUKPiAtJGFzX2VjaG8g
IiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIgPiY2OyB9Cj4gLSAgdGVzdCAk
YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18gPSB5ZXMgJiYKPiAtICAgICRhc19l
Y2hvICIjZGVmaW5lIF9fRVhURU5TSU9OU19fIDEiID4+Y29uZmRlZnMuaAo+IC0KPiAtICAkYXNf
ZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKPiAtCj4gLSAgJGFzX2Vj
aG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCj4gLQo+IC0gICRhc19lY2hv
ICIjZGVmaW5lIF9QT1NJWF9QVEhSRUFEX1NFTUFOVElDUyAxIiA+PmNvbmZkZWZzLmgKPiAtCj4g
LSAgJGFzX2VjaG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCj4gLQo+
IC0KPiAtIyBNYWtlIHN1cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgo+IC0kU0hFTEwgIiRhY19h
dXhfZGlyL2NvbmZpZy5zdWIiIHN1bjQgPi9kZXYvbnVsbCAyPiYxIHx8Cj4gLSAgYXNfZm5fZXJy
b3IgJD8gImNhbm5vdCBydW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5P
IiA1Cj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGJ1aWxkIHN5c3RlbSB0eXBlIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQg
c3lzdGVtIHR5cGUuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9idWlsZCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGFjX2J1aWxkX2FsaWFzPSRidWlsZF9hbGlhcwo+IC10ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9
IHggJiYKPiAtICBhY19idWlsZF9hbGlhcz1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuZ3Vl
c3MiYAo+IC10ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9IHggJiYKPiAtICBhc19mbl9lcnJvciAk
PyAiY2Fubm90IGd1ZXNzIGJ1aWxkIHR5cGU7IHlvdSBtdXN0IHNwZWNpZnkgb25lIiAiJExJTkVO
TyIgNQo+IC1hY19jdl9idWlsZD1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuc3ViIiAkYWNf
YnVpbGRfYWxpYXNgIHx8Cj4gLSAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9j
b25maWcuc3ViICRhY19idWlsZF9hbGlhcyBmYWlsZWQiICIkTElORU5PIiA1Cj4gLQo+IC1maQo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2J1aWxkIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9idWlsZCIgPiY2OyB9Cj4gLWNhc2UgJGFj
X2N2X2J1aWxkIGluCj4gLSotKi0qKSA7Owo+IC0qKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2
YWx1ZSBvZiBjYW5vbmljYWwgYnVpbGQiICIkTElORU5PIiA1IDs7Cj4gLWVzYWMKPiAtYnVpbGQ9
JGFjX2N2X2J1aWxkCj4gLWFjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKPiAtc2V0IHggJGFjX2N2
X2J1aWxkCj4gLXNoaWZ0Cj4gLWJ1aWxkX2NwdT0kMQo+IC1idWlsZF92ZW5kb3I9JDIKPiAtc2hp
ZnQ7IHNoaWZ0Cj4gLSMgUmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVz
ZWQgdG8gY3JlYXRlICQqLAo+IC0jIGV4Y2VwdCB3aXRoIG9sZCBzaGVsbHM6Cj4gLWJ1aWxkX29z
PSQqCj4gLUlGUz0kYWNfc2F2ZV9JRlMKPiAtY2FzZSAkYnVpbGRfb3MgaW4gKlwgKikgYnVpbGRf
b3M9YGVjaG8gIiRidWlsZF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKPiAtCj4gLQo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvc3Qgc3lz
dGVtIHR5cGUiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlLi4u
ICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfaG9zdCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgIngkaG9z
dF9hbGlhcyIgPSB4OyB0aGVuCj4gLSAgYWNfY3ZfaG9zdD0kYWNfY3ZfYnVpbGQKPiAtZWxzZQo+
IC0gIGFjX2N2X2hvc3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhvc3RfYWxp
YXNgIHx8Cj4gLSAgICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5z
dWIgJGhvc3RfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQo+IC1maQo+IC0KPiAtZmkKPiAteyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9ob3N0
IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9ob3N0IiA+JjY7IH0KPiAtY2FzZSAkYWNfY3ZfaG9z
dCBpbgo+IC0qLSotKikgOzsKPiAtKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2Yg
Y2Fub25pY2FsIGhvc3QiICIkTElORU5PIiA1IDs7Cj4gLWVzYWMKPiAtaG9zdD0kYWNfY3ZfaG9z
dAo+IC1hY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCj4gLXNldCB4ICRhY19jdl9ob3N0Cj4gLXNo
aWZ0Cj4gLWhvc3RfY3B1PSQxCj4gLWhvc3RfdmVuZG9yPSQyCj4gLXNoaWZ0OyBzaGlmdAo+IC0j
IFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1c2VkIHRvIGNyZWF0ZSAk
KiwKPiAtIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgo+IC1ob3N0X29zPSQqCj4gLUlGUz0kYWNf
c2F2ZV9JRlMKPiAtY2FzZSAkaG9zdF9vcyBpbiAqXCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9v
cyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKPiAtCj4gLQo+IC0KPiAtIyBNNCBNYWNybyBpbmNs
dWRlcwo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0K
PiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+
IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4g
LQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLSMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQg
dXRpbGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KPiAtIyBzZXJp
YWwgMSAocGtnLWNvbmZpZy0wLjI0KQo+IC0jCj4gLSMgQ29weXJpZ2h0IMKpIDIwMDQgU2NvdHQg
SmFtZXMgUmVtbmFudCA8c2NvdHRAbmV0c3BsaXQuY29tPi4KPiAtIwo+IC0jIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5
Cj4gLSMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSBhcyBwdWJsaXNoZWQgYnkKPiAtIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRo
ZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgo+IC0jIChhdCB5b3VyIG9wdGlvbikgYW55
IGxhdGVyIHZlcnNpb24uCj4gLSMKPiAtIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4g
dGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0Cj4gLSMgV0lUSE9VVCBBTlkgV0FS
UkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgo+IC0jIE1FUkNIQU5U
QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05V
Cj4gLSMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgo+IC0jCj4gLSMg
WW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UKPiAtIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0
aGUgRnJlZSBTb2Z0d2FyZQo+IC0jIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSAt
IFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuCj4gLSMKPiAtIyBBcyBhIHNw
ZWNpYWwgZXhjZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91
Cj4gLSMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250
YWlucyBhCj4gLSMgY29uZmlndXJhdGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1dG9jb25mLCB5
b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIKPiAtIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMg
dGhhdCB5b3UgdXNlIGZvciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCj4gLQo+IC0jIFBLR19Q
Uk9HX1BLR19DT05GSUcoW01JTi1WRVJTSU9OXSkKPiAtIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCj4gLSMgUEtHX1BST0dfUEtHX0NPTkZJRwo+IC0KPiAtIyBQS0dfQ0hFQ0tf
RVhJU1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1GT1VORF0p
Cj4gLSMKPiAtIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVs
ZXMgZXhpc3RzLiAgU2ltaWxhcgo+IC0jIHRvIFBLR19DSEVDS19NT0RVTEVTKCksIGJ1dCBkb2Vz
IG5vdCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9ycy4KPiAtIwo+IC0jIFBsZWFzZSByZW1l
bWJlciB0aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCj4g
LSMgb25seSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZpZ3VyZS5hYywgc28gaWYgdGhl
IGZpcnN0IHBsYWNlCj4gLSMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBp
ZiBpdCBpcyB3aXRoaW4gYW4gImlmIiwgeW91Cj4gLSMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19F
WElTVFMgbWFudWFsbHkKPiAtIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IC0KPiAtCj4gLSMgX1BLR19DT05GSUcoW1ZBUklB
QkxFXSwgW0NPTU1BTkRdLCBbTU9EVUxFU10pCj4gLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgX1BLR19DT05GSUcKPiAtCj4gLSMgX1BLR19TSE9S
VF9FUlJPUlNfU1VQUE9SVEVECj4gLSMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAt
IyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKPiAtCj4gLQo+IC0jIFBLR19DSEVDS19NT0RV
TEVTKFZBUklBQkxFLVBSRUZJWCwgTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sCj4gLSMgW0FD
VElPTi1JRi1OT1QtRk9VTkRdKQo+IC0jCj4gLSMKPiAtIyBOb3RlIHRoYXQgaWYgdGhlcmUgaXMg
YSBwb3NzaWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bwo+IC0jIFBLR19DSEVDS19NT0RVTEVTIG1p
Z2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3VyZSB0byBpbmNsdWRlIGFuCj4gLSMgZXhw
bGljaXQgY2FsbCB0byBQS0dfUFJPR19QS0dfQ09ORklHIGluIHlvdXIgY29uZmlndXJlLmFjCj4g
LSMKPiAtIwo+IC0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCj4gLSMgUEtHX0NIRUNLX01PRFVMRVMKPiAtCj4gLQo+IC0KPiAt
IyBXZSBkZWZpbmUsIHNlcGFyYXRlbHksIFBUSFJFQURfQ0ZMQUdTLCBfTERGTEFHUyBhbmQgX0xJ
QlMKPiAtIyBldmVuIHRob3VnaCBjdXJyZW50bHkgd2UgZG9uJ3Qgc2V0IHRoZW0gdmVyeSBzZXBh
cmF0ZWx5Lgo+IC0jIFRoaXMgbWVhbnMgdGhhdCB0aGUgbWFrZWZpbGVzIHdpbGwgbm90IG5lZWQg
dG8gY2hhbmdlIGluCj4gLSMgdGhlIGZ1dHVyZSBpZiB3ZSBtYWtlIHRoZSB0ZXN0IG1vcmUgc29w
aGlzdGljYXRlZC4KPiAtCj4gLQo+IC0KPiAtIyBXZSBpbnZva2UgQVhfUFRIUkVBRF9WQVJTIHdp
dGggdGhlIG5hbWUgb2YgYW5vdGhlciBtYWNybwo+IC0jIHdoaWNoIGlzIHRoZW4gZXhwYW5kZWQg
b25jZSBmb3IgZWFjaCB2YXJpYWJsZS4KPiAtCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtCj4gLQo+
IC0jIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKPiAtCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJs
ZS1naXRodHRwIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfZ2l0aHR0cDsKPiAtZmkKPiAtCj4g
LQo+IC1pZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAg
ICBheF9jdl9naXRodHRwPSJuIgo+IC0KPiAtZWxpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9
ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3ZfZ2l0aHR0cD0ieSIKPiAtCj4gLWVsaWYg
dGVzdCAteiAkYXhfY3ZfZ2l0aHR0cDsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3ZfZ2l0aHR0cD0i
biIKPiAtCj4gLWZpCj4gLWdpdGh0dHA9JGF4X2N2X2dpdGh0dHAKPiAtCj4gLQo+IC0KPiAtIyBD
aGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtl
bmFibGVfbW9uaXRvcnMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gIGVuYWJsZXZhbD0kZW5hYmxl
X21vbml0b3JzOwo+IC1maQo+IC0KPiAtCj4gLWlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9
ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9tb25pdG9ycz0ibiIKPiAtCj4gLWVsaWYg
dGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9j
dl9tb25pdG9ycz0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4g
Ogo+IC0KPiAtICAgIGF4X2N2X21vbml0b3JzPSJ5Igo+IC0KPiAtZmkKPiAtbW9uaXRvcnM9JGF4
X2N2X21vbml0b3JzCj4gLQo+IC0KPiAtCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS12dHBt
IHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfdnRwbTsKPiAtZmkKPiAtCj4gLQo+IC1pZiB0ZXN0ICJ4
JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl92dHBtPSJuIgo+
IC0KPiAtZWxpZiB0ZXN0ICJ4JGVuYWJsZV92dHBtIiA9ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0g
ICAgYXhfY3ZfdnRwbT0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfdnRwbTsgdGhlbiA6
Cj4gLQo+IC0gICAgYXhfY3ZfdnRwbT0ibiIKPiAtCj4gLWZpCj4gLXZ0cG09JGF4X2N2X3Z0cG0K
PiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhlbmFwaSB3YXMgZ2l2ZW4u
Cj4gLWlmIHRlc3QgIiR7ZW5hYmxlX3hlbmFwaStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5h
YmxldmFsPSRlbmFibGVfeGVuYXBpOwo+IC1maQo+IC0KPiAtCj4gLWlmIHRlc3QgIngkZW5hYmxl
X3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3ZfeGVuYXBpPSJuIgo+IC0K
PiAtZWxpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAg
ICBheF9jdl94ZW5hcGk9InkiCj4gLQo+IC1lbGlmIHRlc3QgLXogJGF4X2N2X3hlbmFwaTsgdGhl
biA6Cj4gLQo+IC0gICAgYXhfY3ZfeGVuYXBpPSJuIgo+IC0KPiAtZmkKPiAteGVuYXBpPSRheF9j
dl94ZW5hcGkKPiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXB5dGhvbnRv
b2xzIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfcHl0aG9udG9vbHMrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgo+IC0gIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xzOwo+IC1maQo+IC0K
PiAtCj4gLWlmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKPiAt
Cj4gLSAgICBheF9jdl9weXRob250b29scz0ibiIKPiAtCj4gLWVsaWYgdGVzdCAieCRlbmFibGVf
cHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9weXRob250b29s
cz0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfcHl0aG9udG9vbHM7IHRoZW4gOgo+IC0K
PiAtICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5Igo+IC0KPiAtZmkKPiAtcHl0aG9udG9vbHM9JGF4
X2N2X3B5dGhvbnRvb2xzCj4gLQo+IC0KPiAtCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1v
Y2FtbHRvb2xzIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfb2NhbWx0b29scytzZXR9
IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKPiAtZmkK
PiAtCj4gLQo+IC1pZiB0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoK
PiAtCj4gLSAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgo+IC0KPiAtZWxpZiB0ZXN0ICJ4JGVuYWJs
ZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3Zfb2NhbWx0b29s
cz0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6Cj4gLQo+
IC0gICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKPiAtCj4gLWZpCj4gLW9jYW1sdG9vbHM9JGF4X2N2
X29jYW1sdG9vbHMKPiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1pbml0
ZXJtIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7
IHRoZW4gOgo+IC0gIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOwo+IC1maQo+IC0KPiAtCj4g
LWlmIHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBh
eF9jdl9taW5pdGVybT0ibiIKPiAtCj4gLWVsaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0g
Inh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9taW5pdGVybT0ieSIKPiAtCj4gLWVsaWYg
dGVzdCAteiAkYXhfY3ZfbWluaXRlcm07IHRoZW4gOgo+IC0KPiAtICAgIGF4X2N2X21pbml0ZXJt
PSJuIgo+IC0KPiAtZmkKPiAtbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCj4gLQo+IC0KPiAtCj4g
LSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAi
JHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFi
bGVfbG9tb3VudDsKPiAtZmkKPiAtCj4gLQo+IC1pZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9
ICJ4bm8iOyB0aGVuIDoKPiAtCj4gLSAgICBheF9jdl9sb21vdW50PSJuIgo+IC0KPiAtZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6Cj4gLQo+IC0gICAgYXhfY3Zf
bG9tb3VudD0ieSIKPiAtCj4gLWVsaWYgdGVzdCAteiAkYXhfY3ZfbG9tb3VudDsgdGhlbiA6Cj4g
LQo+IC0gICAgYXhfY3ZfbG9tb3VudD0ibiIKPiAtCj4gLWZpCj4gLWxvbW91bnQ9JGF4X2N2X2xv
bW91bnQKPiAtCj4gLQo+IC0KPiAtIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW92bWYgd2FzIGdp
dmVuLgo+IC1pZiB0ZXN0ICIke2VuYWJsZV9vdm1mK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICBl
bmFibGV2YWw9JGVuYWJsZV9vdm1mOwo+IC1maQo+IC0KPiAtCj4gLWlmIHRlc3QgIngkZW5hYmxl
X292bWYiID0gInhubyI7IHRoZW4gOgo+IC0KPiAtICAgIGF4X2N2X292bWY9Im4iCj4gLQo+IC1l
bGlmIHRlc3QgIngkZW5hYmxlX292bWYiID0gInh5ZXMiOyB0aGVuIDoKPiAtCj4gLSAgICBheF9j
dl9vdm1mPSJ5Igo+IC0KPiAtZWxpZiB0ZXN0IC16ICRheF9jdl9vdm1mOyB0aGVuIDoKPiAtCj4g
LSAgICBheF9jdl9vdm1mPSJuIgo+IC0KPiAtZmkKPiAtb3ZtZj0kYXhfY3Zfb3ZtZgo+ICsjIE00
IE1hY3JvIGluY2x1ZGVzCj4gCj4gCj4gCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1yb21i
aW9zIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfcm9tYmlvcytzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfcm9tYmlvczsKPiAtZmkKPiAKPiAKPiAtaWYg
dGVzdCAieCRlbmFibGVfcm9tYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLSAgICBheF9jdl9y
b21iaW9zPSJuIgo+IAo+IC1lbGlmIHRlc3QgIngkZW5hYmxlX3JvbWJpb3MiID0gInh5ZXMiOyB0
aGVuIDoKPiAKPiAtICAgIGF4X2N2X3JvbWJpb3M9InkiCj4gCj4gLWVsaWYgdGVzdCAteiAkYXhf
Y3Zfcm9tYmlvczsgdGhlbiA6Cj4gCj4gLSAgICBheF9jdl9yb21iaW9zPSJ5Igo+IAo+IC1maQo+
IC1yb21iaW9zPSRheF9jdl9yb21iaW9zCj4gCj4gCj4gCj4gLSMgQ2hlY2sgd2hldGhlciAtLWVu
YWJsZS1zZWFiaW9zIHdhcyBnaXZlbi4KPiAtaWYgdGVzdCAiJHtlbmFibGVfc2VhYmlvcytzZXR9
IiA9IHNldDsgdGhlbiA6Cj4gLSAgZW5hYmxldmFsPSRlbmFibGVfc2VhYmlvczsKPiAtZmkKPiAK
PiAKPiAtaWYgdGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLSAg
ICBheF9jdl9zZWFiaW9zPSJuIgo+IAo+IC1lbGlmIHRlc3QgIngkZW5hYmxlX3NlYWJpb3MiID0g
Inh5ZXMiOyB0aGVuIDoKPiAKPiAtICAgIGF4X2N2X3NlYWJpb3M9InkiCj4gCj4gLWVsaWYgdGVz
dCAteiAkYXhfY3Zfc2VhYmlvczsgdGhlbiA6Cj4gCj4gLSAgICBheF9jdl9zZWFiaW9zPSJ5Igo+
IAo+IC1maQo+IC1zZWFiaW9zPSRheF9jdl9zZWFiaW9zCj4gCj4gCj4gCj4gLSMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCj4gLWlmIHRlc3QgIiR7ZW5hYmxlX2RlYnVn
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICBlbmFibGV2YWw9JGVuYWJsZV9kZWJ1ZzsKPiAtZmkK
PiAKPiAKPiAtaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0gInhubyI7IHRoZW4gOgo+IAo+IC0g
ICAgYXhfY3ZfZGVidWc9Im4iCj4gCj4gLWVsaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0gInh5
ZXMiOyB0aGVuIDoKPiAKPiAtICAgIGF4X2N2X2RlYnVnPSJ5Igo+IAo+IC1lbGlmIHRlc3QgLXog
JGF4X2N2X2RlYnVnOyB0aGVuIDoKPiAKPiAtICAgIGF4X2N2X2RlYnVnPSJ5Igo+IAo+IC1maQo+
IC1kZWJ1Zz0kYXhfY3ZfZGVidWcKPiAKPiAKPiAKPiBAQCAtNDI0MCw5MzAgKzIyMjIsNDMyIEBA
IGRlYnVnPSRheF9jdl9kZWJ1Zwo+IAo+IAo+IAo+IC1mb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5D
TFVERVMKPiAtZG8KPiAtICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgo+IC1kb25lCj4g
LWZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCj4gLWRvCj4gLSAgICBQUkVQRU5EX0xERkxBR1Mr
PSIgLUwkbGRmbGFnIgo+IC1kb25lCj4gLWZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCj4g
LWRvCj4gLSAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgo+IC1kb25lCj4gLWZvciBsZGZs
YWcgaW4gJEFQUEVORF9MSUIKPiAtZG8KPiAtICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxh
ZyIKPiAtZG9uZQo+IC1DRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZM
QUdTIgo+IC1MREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFH
UyIKPiAKPiAKPiAKPiAKPiAKPiAKPiArIyBwa2cubTQgLSBNYWNyb3MgdG8gbG9jYXRlIGFuZCB1
dGlsaXNlIHBrZy1jb25maWcuICAgICAgICAgICAgLSotIEF1dG9jb25mIC0qLQo+ICsjIHNlcmlh
bCAxIChwa2ctY29uZmlnLTAuMjQpCj4gKyMKPiArIyBDb3B5cmlnaHQgwqkgMjAwNCBTY290dCBK
YW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+Lgo+ICsjCj4gKyMgVGhpcyBwcm9ncmFt
IGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkK
PiArIyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IGFzIHB1Ymxpc2hlZCBieQo+ICsjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhl
ciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCj4gKyMgKGF0IHlvdXIgb3B0aW9uKSBhbnkg
bGF0ZXIgdmVyc2lvbi4KPiArIwo+ICsjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0
aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKPiArIyBXSVRIT1VUIEFOWSBXQVJS
QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCj4gKyMgTUVSQ0hBTlRB
QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUK
PiArIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCj4gKyMKPiArIyBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZQo+ICsjIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRo
ZSBGcmVlIFNvZnR3YXJlCj4gKyMgRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlIC0g
U3VpdGUgMzMwLCBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVTQS4KPiArIwo+ICsjIEFzIGEgc3Bl
Y2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UK
PiArIyBkaXN0cmlidXRlIHRoaXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3JhbSB0aGF0IGNvbnRh
aW5zIGEKPiArIyBjb25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlv
dSBtYXkgaW5jbHVkZSBpdCB1bmRlcgo+ICsjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0
aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KPiAKPiArIyBQS0dfUFJP
R19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCj4gKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+ICsjIFBLR19QUk9HX1BLR19DT05GSUcKPiAKPiArIyBQS0dfQ0hFQ0tfRVhJ
U1RTKE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLCBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCj4g
KyMKPiArIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMg
ZXhpc3RzLiAgU2ltaWxhcgo+ICsjIHRvIFBLR19DSEVDS19NT0RVTEVTKCksIGJ1dCBkb2VzIG5v
dCBzZXQgdmFyaWFibGVzIG9yIHByaW50IGVycm9ycy4KPiArIwo+ICsjIFBsZWFzZSByZW1lbWJl
ciB0aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCj4gKyMg
b25seSBhdCB0aGUgZmlyc3Qgb2NjdXJlbmNlIGluIGNvbmZpZ3VyZS5hYywgc28gaWYgdGhlIGZp
cnN0IHBsYWNlCj4gKyMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBpZiBp
dCBpcyB3aXRoaW4gYW4gImlmIiwgeW91Cj4gKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElT
VFMgbWFudWFsbHkKPiArIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+IAo+ICsjIF9QS0dfQ09ORklHKFtWQVJJQUJMRV0s
IFtDT01NQU5EXSwgW01PRFVMRVNdKQo+ICsjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQo+ICsjIF9QS0dfQ09ORklHCj4gCj4gKyMgX1BLR19TSE9SVF9FUlJP
UlNfU1VQUE9SVEVECj4gKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiArIyBfUEtH
X1NIT1JUX0VSUk9SU19TVVBQT1JURUQKPiAKPiAKPiArIyBQS0dfQ0hFQ0tfTU9EVUxFUyhWQVJJ
QUJMRS1QUkVGSVgsIE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9VTkRdLAo+ICsjIFtBQ1RJT04tSUYt
Tk9ULUZPVU5EXSkKPiArIwo+ICsjCj4gKyMgTm90ZSB0aGF0IGlmIHRoZXJlIGlzIGEgcG9zc2li
aWxpdHkgdGhlIGZpcnN0IGNhbGwgdG8KPiArIyBQS0dfQ0hFQ0tfTU9EVUxFUyBtaWdodCBub3Qg
aGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgo+ICsjIGV4cGxpY2l0IGNh
bGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBpbiB5b3VyIGNvbmZpZ3VyZS5hYwo+ICsjCj4gKyMK
PiArIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+ICsjIFBLR19DSEVDS19NT0RVTEVTCj4gCj4gLSMgQ2hlY2tzIGZvciBwcm9n
cmFtcy4KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVuY2F0ZSBvdXRwdXQiID4mNQo+IC0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVuY2F0ZSBvdXRwdXQuLi4g
IiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wYXRoX1NFRCtzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gICAgICAgICAgICBh
Y19zY3JpcHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJi
YmJiYmJiYmJiYmJiYmJiYmJiYmJiYmIvCj4gLSAgICAgZm9yIGFjX2kgaW4gMSAyIDMgNCA1IDYg
NzsgZG8KPiAtICAgICAgIGFjX3NjcmlwdD0iJGFjX3NjcmlwdCRhc19ubCRhY19zY3JpcHQiCj4g
LSAgICAgZG9uZQo+IC0gICAgIGVjaG8gIiRhY19zY3JpcHQiIDI+L2Rldi9udWxsIHwgc2VkIDk5
cSA+Y29uZnRlc3Quc2VkCj4gLSAgICAgeyBhY19zY3JpcHQ9OyB1bnNldCBhY19zY3JpcHQ7fQo+
IC0gICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0aGVuCj4gLSAgYWNfcGF0aF9TRURfZm91bmQ9ZmFs
c2UKPiAtICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2gg
b2YgUFJPR05BTUUtTElTVAo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAt
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX3Byb2cgaW4gc2Vk
IGdzZWQ7IGRvCj4gLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KPiAtICAgICAgYWNfcGF0aF9TRUQ9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhl
Y19leHQiCj4gLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfU0VEIiAmJiAkYXNfdGVzdF94ICIk
YWNfcGF0aF9TRUQiOyB9IHx8IGNvbnRpbnVlCj4gLSMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX1NF
RCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgo+IC0gICMgQ2hlY2sgZm9yIEdOVSAkYWNf
cGF0aF9TRUQKPiAtY2FzZSBgIiRhY19wYXRoX1NFRCIgLS12ZXJzaW9uIDI+JjFgIGluCj4gLSpH
TlUqKQo+IC0gIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiIGFjX3BhdGhfU0VEX2ZvdW5k
PTo7Owo+IC0qKQo+IC0gIGFjX2NvdW50PTAKPiAtICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJj
b25mdGVzdC5pbiIKPiAtICB3aGlsZSA6Cj4gLSAgZG8KPiAtICAgIGNhdCAiY29uZnRlc3QuaW4i
ICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCj4gLSAgICBtdiAiY29uZnRlc3QudG1wIiAi
Y29uZnRlc3QuaW4iCj4gLSAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKPiAtICAg
ICRhc19lY2hvICcnID4+ICJjb25mdGVzdC5ubCIKPiAtICAgICIkYWNfcGF0aF9TRUQiIC1mIGNv
bmZ0ZXN0LnNlZCA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8
IGJyZWFrCj4gLSAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVs
bCAyPiYxIHx8IGJyZWFrCj4gLSAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2Nv
dW50PSRhc192YWwKPiAtICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfU0VEX21h
eC0wfTsgdGhlbgo+IC0gICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBs
b29raW5nIGZvciBhIGJldHRlciBvbmUKPiAtICAgICAgYWNfY3ZfcGF0aF9TRUQ9IiRhY19wYXRo
X1NFRCIKPiAtICAgICAgYWNfcGF0aF9TRURfbWF4PSRhY19jb3VudAo+IC0gICAgZmkKPiAtICAg
ICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKPiAtICAg
IHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawo+IC0gIGRvbmUKPiAtICBybSAtZiBjb25m
dGVzdC5pbiBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKPiAtZXNhYwo+
IAo+IC0gICAgICAkYWNfcGF0aF9TRURfZm91bmQgJiYgYnJlYWsgMwo+IC0gICAgZG9uZQo+IC0g
IGRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAtICBpZiB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9TRUQiOyB0aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBz
ZWQgY291bGQgYmUgZm91bmQgaW4gXCRQQVRIIiAiJExJTkVOTyIgNQo+IC0gIGZpCj4gLWVsc2UK
PiAtICBhY19jdl9wYXRoX1NFRD0kU0VECj4gLWZpCj4gCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9TRUQiID4mNQo+
IC0kYXNfZWNobyAiJGFjX2N2X3BhdGhfU0VEIiA+JjY7IH0KPiAtIFNFRD0iJGFjX2N2X3BhdGhf
U0VEIgo+IC0gIHJtIC1mIGNvbmZ0ZXN0LnNlZAo+ICsjIFdlIGRlZmluZSwgc2VwYXJhdGVseSwg
UFRIUkVBRF9DRkxBR1MsIF9MREZMQUdTIGFuZCBfTElCUwo+ICsjIGV2ZW4gdGhvdWdoIGN1cnJl
bnRseSB3ZSBkb24ndCBzZXQgdGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCj4gKyMgVGhpcyBtZWFucyB0
aGF0IHRoZSBtYWtlZmlsZXMgd2lsbCBub3QgbmVlZCB0byBjaGFuZ2UgaW4KPiArIyB0aGUgZnV0
dXJlIGlmIHdlIG1ha2UgdGhlIHRlc3QgbW9yZSBzb3BoaXN0aWNhdGVkLgo+IAo+IC1hY19leHQ9
Ywo+IC1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwo+IC1hY19jb21waWxlPSckQ0MgLWMgJENGTEFH
UyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCj4gLWFjX2xpbms9JyRDQyAtbyBjb25m
dGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4
dCAkTElCUyA+JjUnCj4gLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKPiAt
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1nY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dv
cmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVu
IDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVzdCAt
biAiJENDIjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgo+IC1mb3IgYXNfZGlyIGluICRQQVRICj4gLWRvCj4gLSAgSUZTPSRhc19zYXZlX0lG
Uwo+IC0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gLSAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAtICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rv
b2xfcHJlZml4fWdjYyIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+IC0gICAgYnJlYWsg
Mgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9JRlMKPiAKPiAtZmkK
PiAtZmkKPiAtQ0M9JGFjX2N2X3Byb2dfQ0MKPiAtaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+IC0g
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4m
NQo+IC0kYXNfZWNobyAiJENDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIg
PiY2OyB9Cj4gLWZpCj4gCj4gKyMgV2UgaW52b2tlIEFYX1BUSFJFQURfVkFSUyB3aXRoIHRoZSBu
YW1lIG9mIGFub3RoZXIgbWFjcm8KPiArIyB3aGljaCBpcyB0aGVuIGV4cGFuZGVkIG9uY2UgZm9y
IGVhY2ggdmFyaWFibGUuCj4gCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsg
dGhlbgo+IC0gIGFjX2N0X0NDPSRDQwo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15
IGdjYzsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mr
c2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVs
c2UKPiAtICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxz
ZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIg
aW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs
ZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9ImdjYyIKPiAtICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQo+IC0gICAgYnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlG
Uz0kYXNfc2F2ZV9JRlMKPiAKPiAtZmkKPiAtZmkKPiAtYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNf
Y3RfQ0MKPiAtaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQo+IC0kYXNf
ZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2
OyB9Cj4gLWZpCj4gCj4gLSAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCj4gLSAgICBD
Qz0iIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJu
ZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXll
cyA7Owo+IC1lc2FjCj4gLSAgICBDQz0kYWNfY3RfQ0MKPiAtICBmaQo+IC1lbHNlCj4gLSAgQ0M9
IiRhY19jdl9wcm9nX0NDIgo+IC1maQo+IAo+IC1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCj4gLSAg
ICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1j
YzsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFz
X3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfQ0M9
IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAg
IGJyZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4g
Cj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3QgLW4gIiRDQyI7IHRo
ZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNo
byAibm8iID4mNjsgfQo+IC1maQo+IAo+IAo+IC0gIGZpCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRD
QyI7IHRoZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IGNjOyBhY193b3JkPSQy
Cj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRD
QyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLSAgYWNfcHJvZ19yZWplY3RlZD1ubwo+IC1hc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8K
PiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
PiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGlm
IHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhl
bgo+IC0gICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKPiAtICAgICAgIGNvbnRpbnVlCj4gLSAg
ICAgZmkKPiAtICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19z
YXZlX0lGUwo+IAo+IC1pZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCj4gLSAg
IyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIgdXNl
IGl0Lgo+IC0gIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQwo+IC0gIHNoaWZ0Cj4gLSAgaWYgdGVz
dCAkIyAhPSAwOyB0aGVuCj4gLSAgICAjIFdlIGNob3NlIGEgZGlmZmVyZW50IGNvbXBpbGVyIGZy
b20gdGhlIGJvZ3VzIG9uZS4KPiAtICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2Vu
YW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KPiAtICAgICMgZmlyc3QgaWYgd2Ugc2V0
IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgo+IC0gICAg
c2hpZnQKPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgo+
IC0gIGZpCj4gLWZpCj4gLWZpCj4gLWZpCj4gLUNDPSRhY19jdl9wcm9nX0NDCj4gLWlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJENDIiA+JjUKPiAtJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gLWVsc2UKPiAt
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQo+IC0kYXNfZWNobyAibm8iID4mNjsgfQo+ICsjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKPiAr
Cj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KPiAraWYgdGVz
dCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgZW5hYmxldmFsPSRl
bmFibGVfZ2l0aHR0cDsKPiAgZmkKPiAKPiAKPiAtZmkKPiAtaWYgdGVzdCAteiAiJENDIjsgdGhl
bgo+IC0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAtICBmb3IgYWNfcHJv
ZyBpbiBjbC5leGUKPiAtICBkbwo+IC0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
YWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0g
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBpZiB0ZXN0IC1uICIkQ0Mi
OyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
Cj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZp
eCRhY19wcm9nIgo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4g
LSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+ICtpZiB0ZXN0ICJ4
JGVuYWJsZV9naXRodHRwIiA9ICJ4bm8iOyB0aGVuIDoKPiAKPiAtZmkKPiAtZmkKPiAtQ0M9JGFj
X2N2X3Byb2dfQ0MKPiAtaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQo+IC0kYXNfZWNobyAi
JENDIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4g
KyAgICBheF9jdl9naXRodHRwPSJuIgo+IAo+ICtlbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAi
ID0gInh5ZXMiOyB0aGVuIDoKPiAKPiAtICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKPiAtICBk
b25lCj4gLWZpCj4gLWlmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiAtICBhY19jdF9DQz0kQ0MKPiAt
ICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKPiAtZG8KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdv
cmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
PiAtc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KPiAt
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAt
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX3By
b2ciCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIKPiAtICBmaQo+
IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gKyAgICBheF9jdl9naXRodHRw
PSJ5Igo+ICsKPiArZWxpZiB0ZXN0IC16ICRheF9jdl9naXRodHRwOyB0aGVuIDoKPiArCj4gKyAg
ICBheF9jdl9naXRodHRwPSJuIgo+IAo+ICBmaQo+IC1maQo+IC1hY19jdF9DQz0kYWNfY3ZfcHJv
Z19hY19jdF9DQwo+IC1pZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCj4gLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Cj4g
LSRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQo+IC1lbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5v
IiA+JjY7IH0KPiAtZmkKPiArZ2l0aHR0cD0kYXhfY3ZfZ2l0aHR0cAo+IAo+IAo+IC0gIHRlc3Qg
LW4gIiRhY19jdF9DQyIgJiYgYnJlYWsKPiAtZG9uZQo+IAo+IC0gIGlmIHRlc3QgIngkYWNfY3Rf
Q0MiID0geDsgdGhlbgo+IC0gICAgQ0M9IiIKPiAtICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19j
b21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4gLXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsKPiAtZXNhYwo+IC0gICAgQ0M9JGFjX2N0X0NDCj4g
LSAgZmkKPiArIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KPiAr
aWYgdGVzdCAiJHtlbmFibGVfbW9uaXRvcnMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJs
ZXZhbD0kZW5hYmxlX21vbml0b3JzOwo+ICBmaQo+IAo+IC1maQo+IAo+ICtpZiB0ZXN0ICJ4JGVu
YWJsZV9tb25pdG9ycyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLXRlc3QgLXogIiRDQyIgJiYgeyB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19w
d2QnOiIgPiY1Cj4gLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KPiAtYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKPiAtU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUg
OyB9Cj4gKyAgICBheF9jdl9tb25pdG9ycz0ibiIKPiAKPiAtIyBQcm92aWRlIHNvbWUgaW5mb3Jt
YXRpb24gYWJvdXQgdGhlIGNvbXBpbGVyLgo+IC0kYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciB2ZXJzaW9uIiA+JjUKPiAtc2V0IFgg
JGFjX2NvbXBpbGUKPiAtYWNfY29tcGlsZXI9JDIKPiAtZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNp
b24gLXYgLVYgLXF2ZXJzaW9uOyBkbwo+IC0gIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNf
b3B0aW9uID4mNSIKPiAtY2FzZSAiKCgkYWNfdHJ5IiBpbgo+IC0gICpcIiogfCAqXGAqIHwgKlxc
KikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owo+IC0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+
IC1lc2FjCj4gLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogJGFjX3RyeV9lY2hvXCIiCj4gLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+IC0g
IChldmFsICIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgo+IC0g
IGFjX3N0YXR1cz0kPwo+IC0gIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCj4gLSAgICBz
ZWQgJzEwYVwKPiAtLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgo+IC0gICAg
ICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCj4gLSAgICBjYXQgY29uZnRlc3Qu
ZXIxID4mNQo+IC0gIGZpCj4gLSAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgo+IC0g
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMi
ID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KPiAtZG9uZQo+ICtlbGlmIHRlc3QgIngk
ZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsgdGhlbiA6Cj4gCj4gLXsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhl
IEdOVSBDIGNvbXBpbGVyIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBh
cmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfY19jb21waWxlcl9nbnUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiArICAgIGF4X2N2X21vbml0
b3JzPSJ5Igo+IAo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLSNpZm5kZWYgX19HTlVDX18KPiAt
ICAgICAgIGNob2tlIG1lCj4gLSNlbmRpZgo+ICtlbGlmIHRlc3QgLXogJGF4X2N2X21vbml0b3Jz
OyB0aGVuIDoKPiAKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jb21waWxlcl9nbnU9
eWVzCj4gLWVsc2UKPiAtICBhY19jb21waWxlcl9nbnU9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gLWFjX2N2
X2NfY29tcGlsZXJfZ251PSRhY19jb21waWxlcl9nbnUKPiArICAgIGF4X2N2X21vbml0b3JzPSJ5
Igo+IAo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX2Nv
bXBpbGVyX2dudSIgPiY2OyB9Cj4gLWlmIHRlc3QgJGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhl
bgo+IC0gIEdDQz15ZXMKPiAtZWxzZQo+IC0gIEdDQz0KPiAtZmkKPiAtYWNfdGVzdF9DRkxBR1M9
JHtDRkxBR1Mrc2V0fQo+IC1hY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAt
ZyIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4g
IiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4g
Ogo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19zYXZlX2Nf
d2Vycm9yX2ZsYWc9JGFjX2Nfd2Vycm9yX2ZsYWcKPiAtICAgYWNfY193ZXJyb3JfZmxhZz15ZXMK
PiAtICAgYWNfY3ZfcHJvZ19jY19nPW5vCj4gLSAgIENGTEFHUz0iLWciCj4gLSAgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+ICttb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKPiAKPiAtaW50Cj4gLW1haW4gKCkKPiAt
ewo+IAo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKPiAt
ZWxzZQo+IC0gIENGTEFHUz0iIgo+IC0gICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAKPiAtaW50Cj4gLW1h
aW4gKCkKPiAtewo+ICsjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtdnRwbSB3YXMgZ2l2ZW4uCj4g
K2lmIHRlc3QgIiR7ZW5hYmxlX3Z0cG0rc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZh
bD0kZW5hYmxlX3Z0cG07Cj4gK2ZpCj4gCj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9B
Q0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gCj4gLWVs
c2UKPiAtICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKPiAtICAgICAg
ICBDRkxBR1M9Ii1nIgo+IC0gICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICtpZiB0ZXN0ICJ4JGVuYWJs
ZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKPiAKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+ICsgICAg
YXhfY3ZfdnRwbT0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieHllcyI7
IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3Z0cG09InkiCj4gKwo+ICtlbGlmIHRlc3QgLXogJGF4
X2N2X3Z0cG07IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3Z0cG09Im4iCj4gCj4gLSAgOwo+IC0g
IHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfcHJvZ19jY19nPXllcwo+IC1maQo+IC1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuJGFjX2V4dAo+IC0gICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vy
cm9yX2ZsYWcKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X3Byb2df
Y2NfZyIgPiY2OyB9Cj4gLWlmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4KPiAt
ICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCj4gLWVsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0g
eWVzOyB0aGVuCj4gLSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KPiAtICAgIENGTEFHUz0i
LWcgLU8yIgo+IC0gIGVsc2UKPiAtICAgIENGTEFHUz0iLWciCj4gLSAgZmkKPiAtZWxzZQo+IC0g
IGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCj4gLSAgICBDRkxBR1M9Ii1PMiIKPiAtICBlbHNl
Cj4gLSAgICBDRkxBR1M9Cj4gLSAgZmkKPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4
OSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJ
U08gQzg5Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19jODkrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAt
ICBhY19jdl9wcm9nX2NjX2M4OT1ubwo+IC1hY19zYXZlX0NDPSRDQwo+IC1jYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
PiAtI2luY2x1ZGUgPHN0ZGFyZy5oPgo+IC0jaW5jbHVkZSA8c3RkaW8uaD4KPiAtI2luY2x1ZGUg
PHN5cy90eXBlcy5oPgo+IC0jaW5jbHVkZSA8c3lzL3N0YXQuaD4KPiAtLyogTW9zdCBvZiB0aGUg
Zm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYuc2guICAq
Lwo+IC1zdHJ1Y3QgYnVmIHsgaW50IHg7IH07Cj4gLUZJTEUgKiAoKnJjc29wZW4pIChzdHJ1Y3Qg
YnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Cj4gLXN0YXRpYyBjaGFyICplIChwLCBpKQo+IC0g
ICAgIGNoYXIgKipwOwo+IC0gICAgIGludCBpOwo+IC17Cj4gLSAgcmV0dXJuIHBbaV07Cj4gLX0K
PiAtc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwg
Li4uKQo+IC17Cj4gLSAgY2hhciAqczsKPiAtICB2YV9saXN0IHY7Cj4gLSAgdmFfc3RhcnQgKHYs
cCk7Cj4gLSAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKPiAtICB2YV9lbmQgKHYpOwo+IC0g
IHJldHVybiBzOwo+IC19Cj4gK3Z0cG09JGF4X2N2X3Z0cG0KPiAKPiAtLyogT1NGIDQuMCBDb21w
YXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMKPiAt
ICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFy
YWN0ZXIgY29uc3RhbnRzLgo+IC0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVuZm9y
dHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKPiAtICAgYXMgJ3gnLiAgVGhl
IGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAo+
IC0gICBwcm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21l
cyBvdXQgdHJ1ZSwgZm9yIGFuCj4gLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vz
c2FyeSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZwo+IC0gICB0aGF0J3MgdHJ1
ZSBvbmx5IHdpdGggLXN0ZC4gICovCj4gLWludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/
IDEgOiAtMV07Cj4gCj4gLS8qIElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZh
dWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFyYW1ldGVycwo+IC0gICBpbnNpZGUgc3RyaW5n
cyBhbmQgY2hhcmFjdGVyIGNvbnN0YW50cy4gICovCj4gLSNkZWZpbmUgRk9PKHgpICd4Jwo+IC1p
bnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6IC0xXTsKPiAKPiAtaW50IHRlc3Qg
KGludCBpLCBkb3VibGUgeCk7Cj4gLXN0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Owo+IC1z
dHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUgYSk7fTsKPiAtaW50IHBhaXJuYW1lcyAoaW50LCBj
aGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQs
IGludCk7Cj4gLWludCBhcmdjOwo+IC1jaGFyICoqYXJndjsKPiAtaW50Cj4gLW1haW4gKCkKPiAt
ewo+IC1yZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1mb3Ig
YWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBcCj4gLSAg
ICAgICAtQWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgo+IC1k
bwo+IC0gIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgo+IC0gIGlmIGFjX2ZuX2NfdHJ5X2NvbXBp
bGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCj4gKyMg
Q2hlY2sgd2hldGhlciAtLWVuYWJsZS14ZW5hcGkgd2FzIGdpdmVuLgo+ICtpZiB0ZXN0ICIke2Vu
YWJsZV94ZW5hcGkrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZhbD0kZW5hYmxlX3hl
bmFwaTsKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dAo+IC0gIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCj4gLWRv
bmUKPiAtcm0gLWYgY29uZnRlc3QuJGFjX2V4dAo+IC1DQz0kYWNfc2F2ZV9DQwo+ICsKPiArCj4g
K2lmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhf
Y3ZfeGVuYXBpPSJuIgo+ICsKPiArZWxpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInh5ZXMi
OyB0aGVuIDoKPiArCj4gKyAgICBheF9jdl94ZW5hcGk9InkiCj4gKwo+ICtlbGlmIHRlc3QgLXog
JGF4X2N2X3hlbmFwaTsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfeGVuYXBpPSJuIgo+IAo+ICBm
aQo+IC0jIEFDX0NBQ0hFX1ZBTAo+IC1jYXNlICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiBpbgo+IC0g
IHgpCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm9uZSBuZWVkZWQiID4mNQo+IC0kYXNfZWNobyAibm9uZSBuZWVkZWQiID4mNjsgfSA7Owo+
IC0gIHhubykKPiAtICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1Cj4gLSRhc19lY2hvICJ1bnN1cHBvcnRlZCIgPiY2OyB9
IDs7Cj4gLSAgKikKPiAtICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5Igo+IC0gICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9n
X2NjX2M4OSIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7Owo+
IC1lc2FjCj4gLWlmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6Cj4g
K3hlbmFwaT0kYXhfY3ZfeGVuYXBpCj4gKwo+IAo+ICsKPiArIyBDaGVjayB3aGV0aGVyIC0tZW5h
YmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KPiAraWYgdGVzdCAiJHtlbmFibGVfcHl0aG9udG9v
bHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xz
Owo+ICBmaQo+IAo+IC1hY19leHQ9Ywo+IC1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwo+IC1hY19j
b21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCj4g
LWFjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExE
RkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCj4gLWFjX2NvbXBpbGVyX2dudT0kYWNf
Y3ZfY19jb21waWxlcl9nbnUKPiAKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzIiA+JjUKPiAtJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3Jrcy4uLiAiID4mNjsgfQo+IC1MTl9TPSRhc19sbl9z
Cj4gLWlmIHRlc3QgIiRMTl9TIiA9ICJsbiAtcyI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiAtJGFzX2VjaG8gInll
cyIgPiY2OyB9Cj4gLWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8sIHVzaW5nICRMTl9TIiA+JjUKPiAtJGFzX2VjaG8gIm5vLCB1c2lu
ZyAkTE5fUyIgPiY2OyB9Cj4gK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8i
OyB0aGVuIDoKPiArCj4gKyAgICBheF9jdl9weXRob250b29scz0ibiIKPiArCj4gK2VsaWYgdGVz
dCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKPiArCj4gKyAgICBheF9j
dl9weXRob250b29scz0ieSIKPiArCj4gK2VsaWYgdGVzdCAteiAkYXhfY3ZfcHl0aG9udG9vbHM7
IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5Igo+ICsKPiAgZmkKPiArcHl0
aG9udG9vbHM9JGF4X2N2X3B5dGhvbnRvb2xzCj4gCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChN
QUtFKSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNl
dHMgXCQoTUFLRSkuLi4gIiA+JjY7IH0KPiAtc2V0IHggJHtNQUtFLW1ha2V9Cj4gLWFjX21ha2U9
YCRhc19lY2hvICIkMiIgfCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAo+IC1p
ZiBldmFsICJ0ZXN0IFwiXCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0K3NldH1cIiIg
PSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAt
ICBjYXQgPmNvbmZ0ZXN0Lm1ha2UgPDxcX0FDRU9GCj4gLVNIRUxMID0gL2Jpbi9zaAo+IC1hbGw6
Cj4gLSAgICAgICBAZWNobyAnQEBAJSUlPSQoTUFLRSk9QEBAJSUlJwo+IC1fQUNFT0YKPiAtIyBH
TlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3
b3VsZCBjb25mdXNlIHVzLgo+IC1jYXNlIGAke01BS0UtbWFrZX0gLWYgY29uZnRlc3QubWFrZSAy
Pi9kZXYvbnVsbGAgaW4KPiAtICAqQEBAJSUlPT8qPUBAQCUlJSopCj4gLSAgICBldmFsIGFjX2N2
X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7Owo+IC0gICopCj4gLSAgICBldmFsIGFjX2N2
X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD1ubzs7Cj4gLWVzYWMKPiAtcm0gLWYgY29uZnRlc3Qu
bWFrZQo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xzIHdhcyBn
aXZlbi4KPiAraWYgdGVzdCAiJHtlbmFibGVfb2NhbWx0b29scytzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gKyAgZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKPiAgZmkKPiAtaWYgZXZhbCB0ZXN0
IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVzOyB0aGVuCj4gLSAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gLSRh
c19lY2hvICJ5ZXMiID4mNjsgfQo+IC0gIFNFVF9NQUtFPQo+IC1lbHNlCj4gLSAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KPiAtICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCj4gKwo+ICsK
PiAraWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsg
ICAgYXhfY3Zfb2NhbWx0b29scz0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0
b29scyIgPSAieHllcyI7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCj4g
Kwo+ICtlbGlmIHRlc3QgLXogJGF4X2N2X29jYW1sdG9vbHM7IHRoZW4gOgo+ICsKPiArICAgIGF4
X2N2X29jYW1sdG9vbHM9InkiCj4gKwo+ICBmaQo+ICtvY2FtbHRvb2xzPSRheF9jdl9vY2FtbHRv
b2xzCj4gCj4gLSMgRmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVyIGEgQyBw
cm9ncmFtIChmYXN0ZXIpLAo+IC0jIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBhbm90aGVy
LiAgQnV0IGF2b2lkIHRoZSBicm9rZW4gb3IKPiAtIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6Cj4g
LSMgU3lzViAvZXRjL2luc3RhbGwsIC91c3Ivc2Jpbi9pbnN0YWxsCj4gLSMgU3VuT1MgL3Vzci9l
dGMvaW5zdGFsbAo+IC0jIElSSVggL3NiaW4vaW5zdGFsbAo+IC0jIEFJWCAvYmluL2luc3RhbGwK
PiAtIyBBbWlnYU9TIC9DL2luc3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxv
cHB5IGRpc2NzCj4gLSMgQUlYIDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3
b3JrIHdpdGhvdXQgYSAtZyBmbGFnCj4gLSMgQUZTIC91c3IvYWZzd3MvYmluL2luc3RhbGwsIHdo
aWNoIG1pc2hhbmRsZXMgbm9uZXhpc3RlbnQgYXJncwo+IC0jIFNWUjQgL3Vzci91Y2IvaW5zdGFs
bCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCj4gLSMg
T1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBz
ZW1hbnRpYwo+IC0jIC4vaW5zdGFsbCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNyZWF0ZWQg
YnkgbWFrZSBmcm9tIC4vaW5zdGFsbC5zaC4KPiAtIyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0
aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZpbGVzLgo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3Rh
bGwiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0
YWxsLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgLXogIiRJTlNUQUxMIjsgdGhlbgo+IC1pZiB0ZXN0
ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2
ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgIyBBY2NvdW50
IGZvciBwZW9wbGUgd2hvIHB1dCB0cmFpbGluZyBzbGFzaGVzIGluIFBBVEggZWxlbWVudHMuCj4g
LWNhc2UgJGFzX2Rpci8gaW4gIygoCj4gLSAgLi8gfCAuLy8gfCAvW2NDXS8qIHwgXAo+IC0gIC9l
dGMvKiB8IC91c3Ivc2Jpbi8qIHwgL3Vzci9ldGMvKiB8IC9zYmluLyogfCAvdXNyL2Fmc3dzL2Jp
bi8qIHwgXAo+IC0gID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xc
L11JTlNUQUxMW1xcL10qIHwgXAo+IC0gIC91c3IvdWNiLyogKSA7Owo+IC0gICopCj4gLSAgICAj
IE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgo+
IC0gICAgIyBEb24ndCB1c2UgaW5zdGFsbGJzZCBmcm9tIE9TRiBzaW5jZSBpdCBpbnN0YWxscyBz
dHVmZiBhcyByb290Cj4gLSAgICAjIGJ5IGRlZmF1bHQuCj4gLSAgICBmb3IgYWNfcHJvZyBpbiBn
aW5zdGFsbCBzY29pbnN0IGluc3RhbGw7IGRvCj4gLSAgICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gICAgICAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgICAgICBpZiB0ZXN0ICRhY19wcm9nID0g
aW5zdGFsbCAmJgo+IC0gICAgICAgICAgIGdyZXAgZHNwbXNnICIkYXNfZGlyLyRhY19wcm9nJGFj
X2V4ZWNfZXh0IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4KPiAtICAgICAgICAgICAjIEFJWCBpbnN0
YWxsLiAgSXQgaGFzIGFuIGluY29tcGF0aWJsZSBjYWxsaW5nIGNvbnZlbnRpb24uCj4gLSAgICAg
ICAgICAgOgo+IC0gICAgICAgICBlbGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCj4gLSAg
ICAgICAgICAgZ3JlcCBwd3BsdXMgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2
L251bGwgMj4mMTsgdGhlbgo+IC0gICAgICAgICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxs
IHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgo+IC0gICAgICAgICAgIDoKPiAt
ICAgICAgICAgZWxzZQo+IC0gICAgICAgICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3Qu
dHdvIGNvbmZ0ZXN0LmRpcgo+IC0gICAgICAgICAgIGVjaG8gb25lID4gY29uZnRlc3Qub25lCj4g
LSAgICAgICAgICAgZWNobyB0d28gPiBjb25mdGVzdC50d28KPiAtICAgICAgICAgICBta2RpciBj
b25mdGVzdC5kaXIKPiAtICAgICAgICAgICBpZiAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4
dCIgLWMgY29uZnRlc3Qub25lIGNvbmZ0ZXN0LnR3byAiYHB3ZGAvY29uZnRlc3QuZGlyIiAmJgo+
IC0gICAgICAgICAgICAgdGVzdCAtcyBjb25mdGVzdC5vbmUgJiYgdGVzdCAtcyBjb25mdGVzdC50
d28gJiYKPiAtICAgICAgICAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAm
Jgo+IC0gICAgICAgICAgICAgdGVzdCAtcyBjb25mdGVzdC5kaXIvY29uZnRlc3QudHdvCj4gLSAg
ICAgICAgICAgdGhlbgo+IC0gICAgICAgICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGly
LyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgo+IC0gICAgICAgICAgICAgYnJlYWsgMwo+IC0gICAg
ICAgICAgIGZpCj4gLSAgICAgICAgIGZpCj4gLSAgICAgICBmaQo+IC0gICAgICBkb25lCj4gLSAg
ICBkb25lCj4gLSAgICA7Owo+IC1lc2FjCj4gCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZT
Cj4gCj4gLXJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgo+ICsj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgo+ICtpZiB0ZXN0ICIk
e2VuYWJsZV9taW5pdGVybStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgZW5hYmxldmFsPSRlbmFi
bGVfbWluaXRlcm07Cj4gK2ZpCj4gKwo+ICsKPiAraWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0i
ID0gInhubyI7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X21pbml0ZXJtPSJuIgo+ICsKPiArZWxp
ZiB0ZXN0ICJ4JGVuYWJsZV9taW5pdGVybSIgPSAieHllcyI7IHRoZW4gOgo+ICsKPiArICAgIGF4
X2N2X21pbml0ZXJtPSJ5Igo+ICsKPiArZWxpZiB0ZXN0IC16ICRheF9jdl9taW5pdGVybTsgdGhl
biA6Cj4gKwo+ICsgICAgYXhfY3ZfbWluaXRlcm09Im4iCj4gCj4gIGZpCj4gLSAgaWYgdGVzdCAi
JHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KPiAtICAgIElOU1RBTEw9JGFj
X2N2X3BhdGhfaW5zdGFsbAo+IC0gIGVsc2UKPiAtICAgICMgQXMgYSBsYXN0IHJlc29ydCwgdXNl
IHRoZSBzbG93IHNoZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKPiAtICAgICMgdmFsdWUgZm9y
IElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKPiAt
ICAgICMgYnJlYWsgb3RoZXIgcGFja2FnZXMgdXNpbmcgdGhlIGNhY2hlIGlmIHRoYXQgZGlyZWN0
b3J5IGlzCj4gLSAgICAjIHJlbW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZlIG5h
bWUuCj4gLSAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCj4gLSAgZmkKPiArbWluaXRlcm09JGF4
X2N2X21pbml0ZXJtCj4gKwo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21v
dW50IHdhcyBnaXZlbi4KPiAraWYgdGVzdCAiJHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gKyAgZW5hYmxldmFsPSRlbmFibGVfbG9tb3VudDsKPiAgZmkKPiAteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKPiAt
JGFzX2VjaG8gIiRJTlNUQUxMIiA+JjY7IH0KPiAKPiAtIyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1
bk9TNCBzaCBtaXNoYW5kbGVzIGJyYWNlcyBpbiAke3Zhci12YWx9Lgo+IC0jIEl0IHRoaW5rcyB0
aGUgZmlyc3QgY2xvc2UgYnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgo+IC10
ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0n
Cj4gCj4gLXRlc3QgLXogIiRJTlNUQUxMX1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5T
VEFMTH0nCj4gK2lmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInhubyI7IHRoZW4gOgo+IAo+
IC10ZXN0IC16ICIkSU5TVEFMTF9EQVRBIiAmJiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0g
NjQ0Jwo+ICsgICAgYXhfY3ZfbG9tb3VudD0ibiIKPiAKPiAtIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJiaXNvbiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4g
LXNldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gLSRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Bh
dGhfQklTT04rc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2Cj4gLWVsc2UKPiAtICBjYXNlICRCSVNPTiBpbgo+IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+
IC0gIGFjX2N2X3BhdGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAgOzsKPiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElG
Uz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0
aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAtICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQo+IC0gICAgYnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlG
Uz0kYXNfc2F2ZV9JRlMKPiArZWxpZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsg
dGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfbG9tb3VudD0ieSIKPiArCj4gK2VsaWYgdGVzdCAteiAk
YXhfY3ZfbG9tb3VudDsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfbG9tb3VudD0ibiIKPiAKPiAt
ICA7Owo+IC1lc2FjCj4gIGZpCj4gLUJJU09OPSRhY19jdl9wYXRoX0JJU09OCj4gLWlmIHRlc3Qg
LW4gIiRCSVNPTiI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJEJJU09OIiA+JjUKPiAtJGFzX2VjaG8gIiRCSVNPTiIgPiY2OyB9Cj4g
LWVsc2UKPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+IC0kYXNfZWNobyAibm8iID4mNjsgfQo+ICtsb21vdW50PSRheF9jdl9sb21v
dW50Cj4gKwo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vdm1mIHdhcyBnaXZl
bi4KPiAraWYgdGVzdCAiJHtlbmFibGVfb3ZtZitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgZW5h
YmxldmFsPSRlbmFibGVfb3ZtZjsKPiAgZmkKPiAKPiAKPiAtIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJmbGV4Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAt
c2V0IGR1bW15IGZsZXg7IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wYXRo
X0ZMRVgrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
Cj4gLWVsc2UKPiAtICBjYXNlICRGTEVYIGluCj4gLSAgW1xcL10qIHwgPzpbXFwvXSopCj4gLSAg
YWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qg
d2l0aCBhIHBhdGguCj4gLSAgOzsKPiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNf
c2F2ZV9JRlMKPiAtICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9GTEVY
PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+IC0gICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19z
YXZlX0lGUwo+ICtpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4bm8iOyB0aGVuIDoKPiArCj4g
KyAgICBheF9jdl9vdm1mPSJuIgo+ICsKPiArZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4
eWVzIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3Zfb3ZtZj0ieSIKPiArCj4gK2VsaWYgdGVzdCAt
eiAkYXhfY3Zfb3ZtZjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3Zfb3ZtZj0ibiIKPiAKPiAtICA7
Owo+IC1lc2FjCj4gIGZpCj4gLUZMRVg9JGFjX2N2X3BhdGhfRkxFWAo+IC1pZiB0ZXN0IC1uICIk
RkxFWCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJEZMRVgiID4mNQo+IC0kYXNfZWNobyAiJEZMRVgiID4mNjsgfQo+IC1lbHNlCj4g
LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArb3ZtZj0kYXhfY3Zfb3ZtZgo+ICsKPiArCj4g
Kwo+ICsjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtcm9tYmlvcyB3YXMgZ2l2ZW4uCj4gK2lmIHRl
c3QgIiR7ZW5hYmxlX3JvbWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgIGVuYWJsZXZhbD0k
ZW5hYmxlX3JvbWJpb3M7Cj4gIGZpCj4gCj4gCj4gLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBk
dW1teSBwZXJsOyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QRVJM
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1l
bHNlCj4gLSAgY2FzZSAkUEVSTCBpbgo+IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+IC0gIGFjX2N2
X3BhdGhfUEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgo+IC0gIDs7Cj4gLSAgKikKPiAtICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVf
SUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAtICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+
IC0gICAgYnJlYWsgMgo+IC0gIGZpCj4gLWRvbmUKPiAtICBkb25lCj4gLUlGUz0kYXNfc2F2ZV9J
RlMKPiAraWYgdGVzdCAieCRlbmFibGVfcm9tYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsg
ICAgYXhfY3Zfcm9tYmlvcz0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfcm9tYmlvcyIg
PSAieHllcyI7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3JvbWJpb3M9InkiCj4gKwo+ICtlbGlm
IHRlc3QgLXogJGF4X2N2X3JvbWJpb3M7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3JvbWJpb3M9
InkiCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJM
PSJubyIKPiAtICA7Owo+IC1lc2FjCj4gIGZpCj4gLVBFUkw9JGFjX2N2X3BhdGhfUEVSTAo+IC1p
ZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJFBFUkwiID4mNQo+IC0kYXNfZWNobyAiJFBFUkwiID4mNjsg
fQo+IC1lbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArcm9tYmlvcz0kYXhfY3Zf
cm9tYmlvcwo+ICsKPiArCj4gKwo+ICsjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtc2VhYmlvcyB3
YXMgZ2l2ZW4uCj4gK2lmIHRlc3QgIiR7ZW5hYmxlX3NlYWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4g
Ogo+ICsgIGVuYWJsZXZhbD0kZW5hYmxlX3NlYWJpb3M7Cj4gK2ZpCj4gKwo+ICsKPiAraWYgdGVz
dCAieCRlbmFibGVfc2VhYmlvcyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3Zfc2Vh
Ymlvcz0ibiIKPiArCj4gK2VsaWYgdGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieHllcyI7IHRo
ZW4gOgo+ICsKPiArICAgIGF4X2N2X3NlYWJpb3M9InkiCj4gKwo+ICtlbGlmIHRlc3QgLXogJGF4
X2N2X3NlYWJpb3M7IHRoZW4gOgo+ICsKPiArICAgIGF4X2N2X3NlYWJpb3M9InkiCj4gKwo+ICtm
aQo+ICtzZWFiaW9zPSRheF9jdl9zZWFiaW9zCj4gKwo+ICsKPiArCj4gKyMgQ2hlY2sgd2hldGhl
ciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCj4gK2lmIHRlc3QgIiR7ZW5hYmxlX2RlYnVnK3Nl
dH0iID0gc2V0OyB0aGVuIDoKPiArICBlbmFibGV2YWw9JGVuYWJsZV9kZWJ1ZzsKPiArZmkKPiAr
Cj4gKwo+ICtpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhlbiA6Cj4gKwo+ICsg
ICAgYXhfY3ZfZGVidWc9Im4iCj4gKwo+ICtlbGlmIHRlc3QgIngkZW5hYmxlX2RlYnVnIiA9ICJ4
eWVzIjsgdGhlbiA6Cj4gKwo+ICsgICAgYXhfY3ZfZGVidWc9InkiCj4gKwo+ICtlbGlmIHRlc3Qg
LXogJGF4X2N2X2RlYnVnOyB0aGVuIDoKPiArCj4gKyAgICBheF9jdl9kZWJ1Zz0ieSIKPiArCj4g
IGZpCj4gK2RlYnVnPSRheF9jdl9kZWJ1Zwo+ICsKPiArCj4gKwo+ICsKPiArCj4gKwo+ICsKPiAr
Cj4gK2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUwo+ICtkbwo+ICsgICAgUFJFUEVORF9D
RkxBR1MrPSIgLUkkY2ZsYWciCj4gK2RvbmUKPiArZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIK
PiArZG8KPiArICAgIFBSRVBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCj4gK2RvbmUKPiArZm9y
IGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMKPiArZG8KPiArICAgIEFQUEVORF9DRkxBR1MrPSIg
LUkkY2ZsYWciCj4gK2RvbmUKPiArZm9yIGxkZmxhZyBpbiAkQVBQRU5EX0xJQgo+ICtkbwo+ICsg
ICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgo+ICtkb25lCj4gK0NGTEFHUz0iJFBSRVBF
TkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCj4gK0xERkxBR1M9IiRQUkVQRU5EX0xE
RkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdTIgo+ICsKPiArCj4gCj4gCj4gLWlmIHRlc3Qg
eCIke1BFUkx9IiA9PSB4Im5vIgo+IC10aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxl
IHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3RhbGwgcGVybCIgIiRMSU5FTk8iIDUKPiAtZmkKPiAt
aWYgdGVzdCAieCR4YXBpIiA9ICJ4eSI7IHRoZW4gOgo+IAo+IC0gICAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgo+ICsKPiArCj4g
Kwo+ICsKPiArCj4gKwo+ICsKPiArCj4gKwo+ICsjIENoZWNrcyBmb3IgcHJvZ3JhbXMuCj4gK2Fj
X2V4dD1jCj4gK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCj4gK2FjX2NvbXBpbGU9JyRDQyAtYyAk
Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKPiArYWNfbGluaz0nJENDIC1v
IGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4k
YWNfZXh0ICRMSUJTID4mNScKPiArYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2du
dQo+ICtpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsg
YWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfQ1VSTCtzZXR9IiA9IHNl
dDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6
Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJENVUkwg
aW4KPiAtICBbXFwvXSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX0NVUkw9IiRDVVJMIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0g
ICopCj4gLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2
ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9DVVJMPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1nY2MiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFr
IDIKPiAgICBmaQo+IEBAIC01MTcxLDQ0ICsyNjU1LDM5IEBAIGRvbmUKPiAgICBkb25lCj4gIElG
Uz0kYXNfc2F2ZV9JRlMKPiAKPiAtICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19j
dl9wYXRoX0NVUkw9Im5vIgo+IC0gIDs7Cj4gLWVzYWMKPiAgZmkKPiAtQ1VSTD0kYWNfY3ZfcGF0
aF9DVVJMCj4gLWlmIHRlc3QgLW4gIiRDVVJMIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Cj4gLSRhc19lY2hvICIk
Q1VSTCIgPiY2OyB9Cj4gK2ZpCj4gK0NDPSRhY19jdl9wcm9nX0NDCj4gK2lmIHRlc3QgLW4gIiRD
QyI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJENDIiA+JjUKPiArJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAk
YXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+IC1pZiB0ZXN0IHgiJHtDVVJMfSIgPT0g
eCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwt
Y29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKPiAgZmkKPiAt
ICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieG1sMi1jb25maWciLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgeG1sMi1jb25maWc7IGFj
X3dvcmQ9JDIKPiAraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfQ0MiOyB0aGVuCj4gKyAgYWNfY3Rf
Q0M9JENDCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgZ2NjOyBhY193b3JkPSQy
Cj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YTUwrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+
ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBjYXNlICRYTUwgaW4KPiAt
ICBbXFwvXSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX1hNTD0iJFhNTCIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAgOzsKPiAtICAqKQo+IC0g
IGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArICBpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJ
RlM9JGFzX3NhdmVfSUZTCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Bh
dGhfWE1MPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19h
Y19jdF9DQz0iZ2NjIgo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gICAgICBicmVhayAy
Cj4gICAgZmkKPiBAQCAtNTIxNiwzOSArMjY5NSw0MyBAQCBkb25lCj4gICAgZG9uZQo+ICBJRlM9
JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWE1MIiAmJiBhY19jdl9w
YXRoX1hNTD0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1YTUw9JGFjX2N2X3BhdGhfWE1M
Cj4gLWlmIHRlc3QgLW4gIiRYTUwiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYTUwiID4mNQo+IC0kYXNfZWNobyAiJFhNTCIgPiY2
OyB9Cj4gK2ZpCj4gK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCj4gK2lmIHRlc3QgLW4g
IiRhY19jdF9DQyI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2
OyB9Cj4gIGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0KPiAt
aWYgdGVzdCB4IiR7WE1MfSIgPT0geCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8g
IlVuYWJsZSB0byBmaW5kIHhtbDItY29uZmlnLCBwbGVhc2UgaW5zdGFsbCB4bWwyLWNvbmZpZyIg
IiRMSU5FTk8iIDUKPiAtZmkKPiAtCj4gKyAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVu
Cj4gKyAgICBDQz0iIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNf
dG9vbF93YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo
b3N0IHRyaXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xf
d2FybmVkPXllcyA7Owo+ICtlc2FjCj4gKyAgICBDQz0kYWNfY3RfQ0MKPiArICBmaQo+ICtlbHNl
Cj4gKyAgQ0M9IiRhY19jdl9wcm9nX0NDIgo+ICBmaQo+IC1pZiB0ZXN0ICJ4JG9jYW1sdG9vbHMi
ID0gInh5IjsgdGhlbiA6Cj4gCj4gLSAgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYwo+IC0gIGlm
IHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjOyBh
Y193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiArICAgICAgICAgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiArICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3JkPSQyCj4g
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTEMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+
ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0IC1uICIkT0NBTUxDIjsg
dGhlbgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KPiArICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCj4gKyAgYWNfY3ZfcHJv
Z19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAgZWxzZQo+ICBh
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBB
VEgKPiBAQCAtNTI1Nyw3ICsyNzQwLDcgQEAgZG8KPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+
IC0gICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgo+ICsgICAg
YWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKPiAgICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTUyNjcsMjkgKzI3NTAsMzAgQEAg
SUZTPSRhc19zYXZlX0lGUwo+IAo+ICBmaQo+ICBmaQo+IC1PQ0FNTEM9JGFjX2N2X3Byb2dfT0NB
TUxDCj4gLWlmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEMiID4mNQo+IC0kYXNfZWNobyAi
JE9DQU1MQyIgPiY2OyB9Cj4gK0NDPSRhY19jdl9wcm9nX0NDCj4gK2lmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKPiArJGFzX2VjaG8gIiRDQyIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAkYXNf
ZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+ICsgIGZpCj4gIGZpCj4gLWlmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MQyI7IHRoZW4KPiAtICBhY19jdF9PQ0FNTEM9JE9DQU1MQwo+IC0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9jYW1sYzsgYWNfd29yZD0kMgo+ICtp
ZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJj
YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBj
YzsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxD
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0g
c2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAg
aWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQyI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09D
QU1MQz0iJGFjX2N0X09DQU1MQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4g
KyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+ICsgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gIGVsc2UKPiArICBhY19wcm9nX3JlamVjdGVk
PW5vCj4gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2Rp
ciBpbiAkUEFUSAo+ICBkbwo+IEBAIC01Mjk3LDcgKzI3ODEsMTEgQEAgZG8KPiAgICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9Im9jYW1sYyIKPiAr
ICAgIGlmIHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2Nj
IjsgdGhlbgo+ICsgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKPiArICAgICAgIGNvbnRpbnVl
Cj4gKyAgICAgZmkKPiArICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgo+ICAgICAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgPiY1Cj4gICAgICBicmVhayAyCj4gICAgZmkKPiBAQCAtNTMwNSw2MSArMjc5Myw0NCBA
QCBkb25lCj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gK2lmIHRlc3QgJGFjX3By
b2dfcmVqZWN0ZWQgPSB5ZXM7IHRoZW4KPiArICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBh
dGgsIHNvIG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCj4gKyAgc2V0IGR1bW15ICRhY19jdl9w
cm9nX0NDCj4gKyAgc2hpZnQKPiArICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KPiArICAgICMgV2Ug
Y2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgo+ICsgICAgIyBI
b3dldmVyLCBpdCBoYXMgdGhlIHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxsIGJlIGNo
b3Nlbgo+ICsgICAgIyBmaXJzdCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVz
ZSB0aGUgZnVsbCBmaWxlIG5hbWUuCj4gKyAgICBzaGlmdAo+ICsgICAgYWNfY3ZfcHJvZ19DQz0i
JGFzX2Rpci8kYWNfd29yZCR7MSsnICd9JEAiCj4gKyAgZmkKPiAgZmkKPiAgZmkKPiAtYWNfY3Rf
T0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQwo+IC1pZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxDIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfT0NBTUxDIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEMiID4m
NjsgfQo+ICtmaQo+ICtDQz0kYWNfY3ZfcHJvZ19DQwo+ICtpZiB0ZXN0IC1uICIkQ0MiOyB0aGVu
Cj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRD
QyIgPiY1Cj4gKyRhc19lY2hvICIkQ0MiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8g
Im5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQyIgPSB4OyB0
aGVuCj4gLSAgICBPQ0FNTEM9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3NzX2NvbXBp
bGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4g
LWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBPQ0FNTEM9JGFjX2N0X09DQU1M
Qwo+IC0gIGZpCj4gLWVsc2UKPiAtICBPQ0FNTEM9IiRhY19jdl9wcm9nX09DQU1MQyIKPiAtZmkK
PiAtCj4gLQo+IC0gIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KPiAtICAgICBPQ0FN
TFZFUlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxc
MXxwJ2AKPiAtICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjUKPiAtJGFzX2VjaG8gIk9D
YW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY2OyB9Cj4gLSAgICAgIyBJZiBPQ0FNTExJ
QiBpcyBzZXQsIHVzZSBpdAo+IC0gICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgo+
IC0gICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxD
IC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAo+IC0gICAgIGVsc2UKPiAtICAgICAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NBTUxMSUIgcHJl
dmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjUKPiAtJGFzX2VjaG8gIk9DQU1MTElCIHBy
ZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9Cj4gLSAgICAgZmkKPiAtICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogT0NhbWwgbGli
cmFyeSBwYXRoIGlzICRPQ0FNTExJQiIgPiY1Cj4gLSRhc19lY2hvICJPQ2FtbCBsaWJyYXJ5IHBh
dGggaXMgJE9DQU1MTElCIiA+JjY7IH0KPiAtCj4gLQo+IAo+IC0KPiAtICAgICAjIGNoZWNraW5n
IGZvciBvY2FtbG9wdAo+IC0gICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
PiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxv
cHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgo+ICtmaQo+ICtpZiB0ZXN0IC16
ICIkQ0MiOyB0aGVuCj4gKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+ICsg
IGZvciBhY19wcm9nIGluIGNsLmV4ZQo+ICsgIGRvCj4gKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15ICRhY190b29sX3ByZWZpeCRhY19wcm9nOyBh
Y193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhl
biA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3Qg
LW4gIiRPQ0FNTE9QVCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX09DQU1MT1BUPSIkT0NBTUxPUFQi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICsgIGlmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KPiArICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0Lgo+ICBlbHNlCj4gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
PiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+IEBAIC01MzY4LDcgKzI4MzksNyBAQCBkbwo+ICAgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX09DQU1MT1BUPSIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sb3B0Igo+ICsgICAgYWNfY3ZfcHJvZ19DQz0iJGFjX3Rvb2xfcHJlZml4JGFj
X3Byb2ciCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBm
aQo+IEBAIC01Mzc4LDI4ICsyODQ5LDMyIEBAIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAg
ZmkKPiAtT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKPiAtaWYgdGVzdCAtbiAiJE9DQU1M
T1BUIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxPUFQiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7IH0KPiAr
Q0M9JGFjX2N2X3Byb2dfQ0MKPiAraWYgdGVzdCAtbiAiJENDIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQo+ICskYXNf
ZWNobyAiJENDIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4g
IGZpCj4gCj4gCj4gKyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCj4gKyAgZG9uZQo+ICBmaQo+
IC1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KPiAtICBhY19jdF9PQ0FN
TE9QVD0kT0NBTUxPUFQKPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9j
YW1sb3B0OyBhY193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KPiArICBhY19jdF9D
Qz0kQ0MKPiArICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKPiArZG8KPiArICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiArc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
PiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lm
IHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE9QVCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUPSIkYWNfY3RfT0NB
TUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICsgIGlmIHRlc3QgLW4g
IiRhY19jdF9DQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICBlbHNlCj4gIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+IEBAIC01NDA4
LDcgKzI4ODMsNyBAQCBkbwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAg
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9w
cm9nX2FjX2N0X09DQU1MT1BUPSJvY2FtbG9wdCIKPiArICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19wcm9nIgo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gICAgICBicmVhayAyCj4g
ICAgZmkKPiBAQCAtNTQxNiwxOSArMjg5MSwyMyBAQCBkb25lCj4gICAgZG9uZQo+ICBJRlM9JGFz
X3NhdmVfSUZTCj4gCj4gLWZpCj4gLWZpCj4gLWFjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MT1BUCj4gLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KPiAtICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09D
QU1MT1BUIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIgPiY2OyB9Cj4gK2ZpCj4g
K2ZpCj4gK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCj4gK2lmIHRlc3QgLW4gIiRhY19j
dF9DQyI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Cj4g
IGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3Qg
IngkYWNfY3RfT0NBTUxPUFQiID0geDsgdGhlbgo+IC0gICAgT0NBTUxPUFQ9Im5vIgo+ICsKPiAr
ICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCj4gK2RvbmUKPiArCj4gKyAgaWYgdGVzdCAi
eCRhY19jdF9DQyIgPSB4OyB0aGVuCj4gKyAgICBDQz0iIgo+ICAgIGVsc2UKPiAgICAgIGNhc2Ug
JGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAgeWVzOikKPiBAQCAtNTQzNiwz
OTYgKzI5MTUsNjQ5IEBAIHllczopCj4gICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiAgYWNf
dG9vbF93YXJuZWQ9eWVzIDs7Cj4gIGVzYWMKPiAtICAgIE9DQU1MT1BUPSRhY19jdF9PQ0FNTE9Q
VAo+ICsgICAgQ0M9JGFjX2N0X0NDCj4gICAgZmkKPiAtZWxzZQo+IC0gIE9DQU1MT1BUPSIkYWNf
Y3ZfcHJvZ19PQ0FNTE9QVCIKPiAgZmkKPiAKPiAtICAgICBPQ0FNTEJFU1Q9Ynl0ZQo+IC0gICAg
IGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCj4gLSAgICAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0
OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIgPiY1Cj4gLSRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIg
PiYyO30KPiAtICAgICBlbHNlCj4gLSAgICAgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBz
ZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCj4gLSAgICAgICBpZiB0ZXN0
ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgo+IC0gICAgICAgICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKPiAtJGFzX2VjaG8g
InZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsg
fQo+IC0gICAgICAgICAgIE9DQU1MT1BUPW5vCj4gLSAgICAgICBlbHNlCj4gLSAgICAgICAgICAg
T0NBTUxCRVNUPW9wdAo+ICtmaQo+ICsKPiArCj4gK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIg
PiY1Cj4gKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KPiAr
YXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBcJFBBVEgK
PiArU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9Cj4g
Kwo+ICsjIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCj4gKyRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBp
bGVyIHZlcnNpb24iID4mNQo+ICtzZXQgWCAkYWNfY29tcGlsZQo+ICthY19jb21waWxlcj0kMgo+
ICtmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCj4gKyAgeyB7
IGFjX3RyeT0iJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1Igo+ICtjYXNlICIoKCRhY190cnki
IGluCj4gKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cj4gKyAg
KikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gK2VzYWMKPiArZXZhbCBhY190cnlfZWNobz0iXCJc
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiArJGFzX2VjaG8g
IiRhY190cnlfZWNobyI7IH0gPiY1Cj4gKyAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9u
ID4mNSIpIDI+Y29uZnRlc3QuZXJyCj4gKyAgYWNfc3RhdHVzPSQ/Cj4gKyAgaWYgdGVzdCAtcyBj
b25mdGVzdC5lcnI7IHRoZW4KPiArICAgIHNlZCAnMTBhXAo+ICsuLi4gcmVzdCBvZiBzdGRlcnIg
b3V0cHV0IGRlbGV0ZWQgLi4uCj4gKyAgICAgICAgIDEwcScgY29uZnRlc3QuZXJyID5jb25mdGVz
dC5lcjEKPiArICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1Cj4gKyAgZmkKPiArICBybSAtZiBjb25m
dGVzdC5lcjEgY29uZnRlc3QuZXJyCj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsg
fQo+ICtkb25lCj4gKwo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0Cj4gKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiArCj4gK2ludAo+ICttYWluICgpCj4gK3sK
PiArCj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4gK19BQ0VPRgo+ICthY19jbGVhbl9maWxl
c19zYXZlPSRhY19jbGVhbl9maWxlcwo+ICthY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVz
IGEub3V0IGEub3V0LmRTWU0gYS5leGUgYi5vdXQiCj4gKyMgVHJ5IHRvIGNyZWF0ZSBhbiBleGVj
dXRhYmxlIHdpdGhvdXQgLW8gZmlyc3QsIGRpc3JlZ2FyZCBhLm91dC4KPiArIyBJdCB3aWxsIGhl
bHAgdXMgZGlhZ25vc2UgYnJva2VuIGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGludHVp
dGlvbgo+ICsjIG9mIGV4ZWV4dC4KPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzIiA+JjUKPiArJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsg
fQo+ICthY19saW5rX2RlZmF1bHQ9YCRhc19lY2hvICIkYWNfbGluayIgfCBzZWQgJ3MvIC1vICpj
b25mdGVzdFteIF0qLy8nYAo+ICsKPiArIyBUaGUgcG9zc2libGUgb3V0cHV0IGZpbGVzOgo+ICth
Y19maWxlcz0iYS5vdXQgY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFfb3V0LmV4ZSBiLm91
dCBjb25mdGVzdC4qIgo+ICsKPiArYWNfcm1maWxlcz0KPiArZm9yIGFjX2ZpbGUgaW4gJGFjX2Zp
bGVzCj4gK2RvCj4gKyAgY2FzZSAkYWNfZmlsZSBpbgo+ICsgICAgKi4kYWNfZXh0IHwgKi54Y29m
ZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8
ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7Owo+ICsgICAgKiApIGFjX3JtZmlsZXM9
IiRhY19ybWZpbGVzICRhY19maWxlIjs7Cj4gKyAgZXNhYwo+ICtkb25lCj4gK3JtIC1mICRhY19y
bWZpbGVzCj4gKwo+ICtpZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19kZWZhdWx0Igo+ICtjYXNlICIo
KCRhY190cnkiIGluCj4gKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry
eTs7Cj4gKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Cj4gK2VzYWMKPiArZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiAr
JGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1Cj4gKyAgKGV2YWwgIiRhY19saW5rX2RlZmF1
bHQiKSAyPiY1Cj4gKyAgYWNfc3RhdHVzPSQ/Cj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVz
ID0gMDsgfTsgdGhlbiA6Cj4gKyAgIyBBdXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3Zf
ZXhlZXh0IHZhcmlhYmxlIHRvIGBubycuCj4gKyMgU28gaWdub3JlIGEgdmFsdWUgb2YgYG5vJywg
b3RoZXJ3aXNlIHRoaXMgd291bGQgbGVhZCB0byBgRVhFRVhUID0gbm8nCj4gKyMgaW4gYSBNYWtl
ZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUgYWNfY3ZfZXhlZXh0IGlmIGl0IHdhcyBjYWNo
ZWQsCj4gKyMgc28gdGhhdCB0aGUgdXNlciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9y
IGNvbXBpbGVycyB1bmtub3duIHRvCj4gKyMgQXV0b2NvbmYuCj4gK2ZvciBhY19maWxlIGluICRh
Y19maWxlcyAnJwo+ICtkbwo+ICsgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQo+ICsg
IGNhc2UgJGFjX2ZpbGUgaW4KPiArICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICou
ZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZ
TSB8ICoubyB8ICoub2JqICkKPiArICAgICAgIDs7Cj4gKyAgICBbYWJdLm91dCApCj4gKyAgICAg
ICAjIFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMgbW9z
dAo+ICsgICAgICAgIyBjZXJ0YWlubHkgcmlnaHQuCj4gKyAgICAgICBicmVhazs7Cj4gKyAgICAq
LiogKQo+ICsgICAgICAgaWYgdGVzdCAiJHthY19jdl9leGVleHQrc2V0fSIgPSBzZXQgJiYgdGVz
dCAiJGFjX2N2X2V4ZWV4dCIgIT0gbm87Cj4gKyAgICAgICB0aGVuIDo7IGVsc2UKPiArICAgICAg
ICAgIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAo+ICAg
ICAgICAgZmkKPiAtICAgICBmaQo+ICsgICAgICAgIyBXZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUg
YmVjYXVzZSB0aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMgbm90Cj4gKyAgICAgICAjIHNhZmU6IGNy
b3NzIGNvbXBpbGVycyBtYXkgbm90IGFkZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKPiAr
ICAgICAgICMgYXJndW1lbnQsIHNvIHdlIG1heSBuZWVkIHRvIGtub3cgaXQgYXQgdGhhdCBwb2lu
dCBhbHJlYWR5Lgo+ICsgICAgICAgIyBFdmVuIGlmIHRoaXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6
IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCj4gKyAgICAgICAjIGFjdHVhbGx5IHdvcmtpbmcuCj4g
KyAgICAgICBicmVhazs7Cj4gKyAgICAqICkKPiArICAgICAgIGJyZWFrOzsKPiArICBlc2FjCj4g
K2RvbmUKPiArdGVzdCAiJGFjX2N2X2V4ZWV4dCIgPSBubyAmJiBhY19jdl9leGVleHQ9Cj4gKwo+
ICtlbHNlCj4gKyAgYWNfZmlsZT0nJwo+ICtmaQo+ICtpZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRo
ZW4gOgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gKyRhc19lY2hvICIkYXNfbWU6IGZh
aWxlZCBwcm9ncmFtIHdhczoiID4mNQo+ICtzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQg
PiY1Cj4gKwo+ICt7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJy
b3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiArJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxg
JGFjX3B3ZCc6IiA+JjI7fQo+ICthc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBjYW5ub3QgY3Jl
YXRlIGV4ZWN1dGFibGVzCj4gK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIk
TElORU5PIiA1IDsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gKyRhc19lY2hvICJ5ZXMiID4mNjsgfQo+ICtm
aQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZSIgPiY1Cj4gKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZS4uLiAiID4m
NjsgfQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2ZpbGUiID4mNQo+ICskYXNfZWNobyAiJGFjX2ZpbGUiID4mNjsgfQo+ICthY19leGVleHQ9
JGFjX2N2X2V4ZWV4dAo+ICsKPiArcm0gLWYgLXIgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBjb25m
dGVzdCRhY19jdl9leGVleHQgYi5vdXQKPiArYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVz
X3NhdmUKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxlcy4uLiAiID4mNjsgfQo+ICtpZiB7IHsgYWNfdHJ5PSIk
YWNfbGluayIKPiArY2FzZSAiKCgkYWNfdHJ5IiBpbgo+ICsgICpcIiogfCAqXGAqIHwgKlxcKikg
YWNfdHJ5X2VjaG89XCRhY190cnk7Owo+ICsgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+ICtl
c2FjCj4gK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
JGFjX3RyeV9lY2hvXCIiCj4gKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+ICsgIChl
dmFsICIkYWNfbGluayIpIDI+JjUKPiArICBhY19zdGF0dXM9JD8KPiArICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKPiArICB0ZXN0
ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKPiArICAjIElmIGJvdGggYGNvbmZ0ZXN0LmV4ZScg
YW5kIGBjb25mdGVzdCcgYXJlIGBwcmVzZW50JyAod2VsbCwgb2JzZXJ2YWJsZSkKPiArIyBjYXRj
aCBgY29uZnRlc3QuZXhlJy4gIEZvciBpbnN0YW5jZSB3aXRoIEN5Z3dpbiwgYGxzIGNvbmZ0ZXN0
JyB3aWxsCj4gKyMgd29yayBwcm9wZXJseSAoaS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScp
LCB3aGlsZSBpdCB3b24ndCB3aXRoCj4gKyMgYHJtJy4KPiArZm9yIGFjX2ZpbGUgaW4gY29uZnRl
c3QuZXhlIGNvbmZ0ZXN0IGNvbmZ0ZXN0Lio7IGRvCj4gKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8
IGNvbnRpbnVlCj4gKyAgY2FzZSAkYWNfZmlsZSBpbgo+ICsgICAgKi4kYWNfZXh0IHwgKi54Y29m
ZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8
ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7Owo+ICsgICAgKi4qICkgYWNfY3ZfZXhl
ZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCj4gKyAgICAgICAgIGJyZWFr
OzsKPiArICAgICogKSBicmVhazs7Cj4gKyAgZXNhYwo+ICtkb25lCj4gK2Vsc2UKPiArICB7IHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjUKPiArJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7
fQo+ICthc19mbl9lcnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVz
OiBjYW5ub3QgY29tcGlsZSBhbmQgbGluawo+ICtTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBk
ZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KPiArZmkKPiArcm0gLWYgY29uZnRlc3QgY29uZnRlc3Qk
YWNfY3ZfZXhlZXh0Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfZXhlZXh0IiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdl9leGVleHQiID4m
NjsgfQo+IAo+ICtybSAtZiBjb25mdGVzdC4kYWNfZXh0Cj4gK0VYRUVYVD0kYWNfY3ZfZXhlZXh0
Cj4gK2FjX2V4ZWV4dD0kRVhFRVhUCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiArLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8c3RkaW8u
aD4KPiAraW50Cj4gK21haW4gKCkKPiArewo+ICtGSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5v
dXQiLCAidyIpOwo+ICsgcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAwOwo+IAo+
ICsgIDsKPiArICByZXR1cm4gMDsKPiArfQo+ICtfQUNFT0YKPiArYWNfY2xlYW5fZmlsZXM9IiRh
Y19jbGVhbl9maWxlcyBjb25mdGVzdC5vdXQiCj4gKyMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIg
cHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwgZWl0aGVyCj4gKyMgdGhl
IGNvbXBpbGVyIGlzIGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KPiAreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9z
cyBjb21waWxpbmciID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBj
cm9zcyBjb21waWxpbmcuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIg
IT0geWVzOyB0aGVuCj4gKyAgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCj4gK2Nhc2UgIigoJGFjX3Ry
eSIgaW4KPiArICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKPiAr
ICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKPiArZXNhYwo+ICtldmFsIGFjX3RyeV9lY2hvPSJc
IlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgo+ICskYXNfZWNo
byAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKPiArICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1Cj4gKyAg
YWNfc3RhdHVzPSQ/Cj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
XCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQo+ICsgIGlm
IHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCcKPiArICB7IHsgY2FzZSAiKCgkYWNf
dHJ5IiBpbgo+ICsgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owo+
ICsgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owo+ICtlc2FjCj4gK2V2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCj4gKyRhc19l
Y2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQo+ICsgIChldmFsICIkYWNfdHJ5IikgMj4mNQo+ICsg
IGFjX3N0YXR1cz0kPwo+ICsgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFwkPyA9ICRhY19zdGF0dXMiID4mNQo+ICsgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IH07IHRo
ZW4KPiArICAgIGNyb3NzX2NvbXBpbGluZz1ubwo+ICsgIGVsc2UKPiArICAgIGlmIHRlc3QgIiRj
cm9zc19jb21waWxpbmciID0gbWF5YmU7IHRoZW4KPiArICAgICAgIGNyb3NzX2NvbXBpbGluZz15
ZXMKPiArICAgIGVsc2UKPiArICAgICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQo+ICskYXNfZWNobyAiJGFzX21l
OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cj4gK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3Qg
cnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMuCj4gK0lmIHlvdSBtZWFudCB0byBjcm9zcyBjb21waWxl
LCB1c2UgXGAtLWhvc3QnLgo+ICtTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAi
JExJTkVOTyIgNSA7IH0KPiArICAgIGZpCj4gKyAgZmkKPiArZmkKPiAreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRjcm9zc19jb21waWxpbmciID4mNQo+
ICskYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIgPiY2OyB9Cj4gCj4gLSAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxjLm9wdAo+IC0gICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRo
ZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBk
dW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3Jt
IC1mIGNvbmZ0ZXN0LiRhY19leHQgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGNvbmZ0ZXN0Lm91dAo+
ICthY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQo+ICt7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZp
bGVzIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmplY3QgZmls
ZXMuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9vYmpleHQrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0
IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIk
T0NBTUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+
IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4g
JFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
Yy5vcHQiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIKPiAtICBm
aQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gKyAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICov
Cj4gCj4gLWZpCj4gLWZpCj4gLU9DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQK
PiAtaWYgdGVzdCAtbiAiJE9DQU1MQ0RPVE9QVCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQ0RPVE9QVCIgPiY1Cj4gLSRh
c19lY2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJu
byIgPiY2OyB9Cj4gLWZpCj4gK2ludAo+ICttYWluICgpCj4gK3sKPiAKPiArICA7Cj4gKyAgcmV0
dXJuIDA7Cj4gK30KPiArX0FDRU9GCj4gK3JtIC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqCj4g
K2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgo+ICtjYXNlICIoKCRhY190cnkiIGluCj4gKyAg
KlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cj4gKyAgKikgYWNfdHJ5
X2VjaG89JGFjX3RyeTs7Cj4gK2VzYWMKPiArZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKPiArJGFzX2VjaG8gIiRhY190cnlf
ZWNobyI7IH0gPiY1Cj4gKyAgKGV2YWwgIiRhY19jb21waWxlIikgMj4mNQo+ICsgIGFjX3N0YXR1
cz0kPwo+ICsgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh
Y19zdGF0dXMiID4mNQo+ICsgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgo+ICsgIGZv
ciBhY19maWxlIGluIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCj4gKyAg
dGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOwo+ICsgIGNhc2UgJGFjX2ZpbGUgaW4KPiAr
ICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwg
Ki5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSApIDs7Cj4gKyAgICAqKSBhY19j
dl9vYmpleHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKPiArICAgICAgIGJyZWFr
OzsKPiArICBlc2FjCj4gK2RvbmUKPiArZWxzZQo+ICsgICRhc19lY2hvICIkYXNfbWU6IGZhaWxl
ZCBwcm9ncmFtIHdhczoiID4mNQo+ICtzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1
Cj4gCj4gK3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNf
cHdkJzoiID4mMjt9Cj4gK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Yg
b2JqZWN0IGZpbGVzOiBjYW5ub3QgY29tcGlsZQo+ICtTZWUgXGBjb25maWcubG9nJyBmb3IgbW9y
ZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KPiAgZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3By
b2dfT0NBTUxDRE9UT1BUIjsgdGhlbgo+IC0gIGFjX2N0X09DQU1MQ0RPVE9QVD0kT0NBTUxDRE9U
T1BUCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMub3B0Iiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9jYW1sYy5vcHQ7
IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RP
VE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3JtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQg
Y29uZnRlc3QuJGFjX2V4dAo+ICtmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3Zf
b2JqZXh0IiA+JjY7IH0KPiArT0JKRVhUPSRhY19jdl9vYmpleHQKPiArYWNfb2JqZXh0PSRPQkpF
WFQKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3
aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQo+ICskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+
JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNldDsgdGhl
biA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN
TENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
PiAtZm9yIGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9
Im9jYW1sYy5vcHQiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIK
PiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMu
aC4gICovCj4gCj4gLWZpCj4gLWZpCj4gLWFjX2N0X09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTENET1RPUFQKPiAtaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRo
ZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N0X09DQU1MQ0RPVE9QVCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3RfT0NBTUxDRE9UT1BU
IiA+JjY7IH0KPiAraW50Cj4gK21haW4gKCkKPiArewo+ICsjaWZuZGVmIF9fR05VQ19fCj4gKyAg
ICAgICBjaG9rZSBtZQo+ICsjZW5kaWYKPiArCj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4g
K19BQ0VPRgo+ICtpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4gKyAg
YWNfY29tcGlsZXJfZ251PXllcwo+ICBlbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0K
PiArICBhY19jb21waWxlcl9nbnU9bm8KPiAgZmkKPiArcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK2FjX2N2X2NfY29tcGlsZXJf
Z251PSRhY19jb21waWxlcl9nbnUKPiAKPiAtICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQ0RPVE9Q
VCIgPSB4OyB0aGVuCj4gLSAgICBPQ0FNTENET1RPUFQ9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNh
c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mMjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBPQ0FN
TENET1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAo+IC0gIGZpCj4gK2ZpCj4gK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9n
bnUiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KPiAraWYg
dGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCj4gKyAgR0NDPXllcwo+ICBlbHNlCj4g
LSAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCj4gKyAgR0NDPQo+ICBm
aQo+IC0KPiAtICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCj4gLSAg
ICAgICBUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAo+IC0gICAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIk
T0NBTUxWRVJTSU9OIiA7IHRoZW4KPiAtICAgICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKPiAtJGFzX2VjaG8gInZlcnNpb25zIGRpZmZlcnMg
ZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9Cj4gLSAgICAgICBlbHNl
Cj4gLSAgICAgICAgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKPiAtICAgICAgIGZpCj4gLSAgICAg
ZmkKPiAtCj4gLSAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0Cj4gLSAgICAgaWYgdGVz
dCAiJE9DQU1MT1BUIiAhPSAibm8iIDsgdGhlbgo+IC0gICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rv
b2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190
b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7IGFjX3dv
cmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3NldH0i
ID0gc2V0OyB0aGVuIDoKPiArYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0fQo+ICthY19zYXZl
X0NGTEFHUz0kQ0ZMQUdTCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1Cj4gKyRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHth
Y19jdl9wcm9nX2NjX2crc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVu
Cj4gLSAgYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4gJFBBVEgKPiAtZG8KPiAtICBJRlM9
JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2df
T0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Igo+IC0gICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRv
bmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+ICsgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193
ZXJyb3JfZmxhZwo+ICsgICBhY19jX3dlcnJvcl9mbGFnPXllcwo+ICsgICBhY19jdl9wcm9nX2Nj
X2c9bm8KPiArICAgQ0ZMQUdTPSItZyIKPiArICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICovCj4gCj4gLWZpCj4gLWZp
Cj4gLU9DQU1MT1BURE9UT1BUPSRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUCj4gLWlmIHRlc3Qg
LW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKPiAtJGFzX2VjaG8g
IiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9Cj4gK2ludAo+ICttYWluICgpCj4gK3sKPiArCj4gKyAg
Owo+ICsgIHJldHVybiAwOwo+ICt9Cj4gK19BQ0VPRgo+ICtpZiBhY19mbl9jX3RyeV9jb21waWxl
ICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfcHJvZ19jY19nPXllcwo+ICBlbHNlCj4gLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
PiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtZmkKPiArICBDRkxBR1M9IiIKPiArICAgICAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRl
ZnMuaC4gICovCj4gCj4gK2ludAo+ICttYWluICgpCj4gK3sKPiAKPiAtZmkKPiAtaWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gLSAgYWNfY3RfT0NBTUxPUFRE
T1RPUFQ9JE9DQU1MT1BURE9UT1BUCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1z
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE9QVERPVE9QVCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BU
PSIkYWNfY3RfT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAtZm9y
IGFzX2RpciBpbiAkUEFUSAo+IC1kbwo+IC0gIElGUz0kYXNfc2F2ZV9JRlMKPiAtICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+IC0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVD0ib2Nh
bWxvcHQub3B0Igo+IC0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4g
LSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAtSUZTPSRhc19zYXZlX0lGUwo+ICsgIDsKPiArICBy
ZXR1cm4gMDsKPiArfQo+ICtfQUNFT0YKPiAraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVO
TyI7IHRoZW4gOgo+ICsKPiArZWxzZQo+ICsgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193
ZXJyb3JfZmxhZwo+ICsgICAgICAgIENGTEFHUz0iLWciCj4gKyAgICAgICAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICov
Cj4gKwo+ICtpbnQKPiArbWFpbiAoKQo+ICt7Cj4gCj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9
Cj4gK19BQ0VPRgo+ICtpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cj4g
KyAgYWNfY3ZfcHJvZ19jY19nPXllcwo+ICBmaQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAgZmkKPiAtYWNfY3RfT0NBTUxP
UFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQKPiAtaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNQo+IC0k
YXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRh
c19lY2hvICJubyIgPiY2OyB9Cj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+ICBmaQo+IC0KPiAtICBpZiB0ZXN0ICJ4JGFjX2N0
X09DQU1MT1BURE9UT1BUIiA9IHg7IHRoZW4KPiAtICAgIE9DQU1MT1BURE9UT1BUPSJubyIKPiAr
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNf
ZXh0Cj4gKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwo+ICtmaQo+
ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X3Byb2dfY2NfZyIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KPiAr
aWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9IHNldDsgdGhlbgo+ICsgIENGTEFHUz0kYWNfc2F2
ZV9DRkxBR1MKPiArZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5ZXM7IHRoZW4KPiArICBp
ZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgo+ICsgICAgQ0ZMQUdTPSItZyAtTzIiCj4gICAgZWxz
ZQo+IC0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgo+IC15ZXM6
KQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Cj4gLSRh
c19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3
aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiAtYWNfdG9vbF93YXJuZWQ9eWVzIDs7Cj4gLWVzYWMK
PiAtICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERPVE9QVAo+ICsgICAgQ0ZMQUdT
PSItZyIKPiAgICBmaQo+ICBlbHNlCj4gLSAgT0NBTUxPUFRET1RPUFQ9IiRhY19jdl9wcm9nX09D
QU1MT1BURE9UT1BUIgo+IC1maQo+IC0KPiAtICAgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVERPVE9Q
VCIgIT0gIm5vIjsgdGhlbgo+IC0gICAgICAgICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BU
IC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAo+IC0gICAgICAg
ICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KPiAtICAg
ICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuIiA+
JjUKPiAtJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0
IGRpc2NhcmRlZC4iID4mNjsgfQo+IC0gICAgICAgICAgZWxzZQo+IC0gICAgICAgICAgICAgT0NB
TUxPUFQ9JE9DQU1MT1BURE9UT1BUCj4gLSAgICAgICAgICBmaQo+IC0gICAgICAgIGZpCj4gLSAg
ICAgZmkKPiAtCj4gLQo+ICsgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCj4gKyAgICBDRkxB
R1M9Ii1PMiIKPiArICBlbHNlCj4gKyAgICBDRkxBR1M9Cj4gICAgZmkKPiArZmkKPiAreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJENDIG9wdGlv
biB0byBhY2NlcHQgSVNPIEM4OSIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkQ0Mg
b3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2Cj4gK2Vsc2UKPiArICBhY19jdl9wcm9nX2NjX2M4OT1ubwo+ICthY19zYXZlX0NDPSRD
Qwo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KPiArI2luY2x1ZGUgPHN0ZGFyZy5oPgo+ICsjaW5jbHVkZSA8c3Rk
aW8uaD4KPiArI2luY2x1ZGUgPHN5cy90eXBlcy5oPgo+ICsjaW5jbHVkZSA8c3lzL3N0YXQuaD4K
PiArLyogTW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43
J3Mgc3JjL2NvbmYuc2guICAqLwo+ICtzdHJ1Y3QgYnVmIHsgaW50IHg7IH07Cj4gK0ZJTEUgKiAo
KnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Cj4gK3N0YXRpYyBj
aGFyICplIChwLCBpKQo+ICsgICAgIGNoYXIgKipwOwo+ICsgICAgIGludCBpOwo+ICt7Cj4gKyAg
cmV0dXJuIHBbaV07Cj4gK30KPiArc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoq
LCBpbnQpLCBjaGFyICoqcCwgLi4uKQo+ICt7Cj4gKyAgY2hhciAqczsKPiArICB2YV9saXN0IHY7
Cj4gKyAgdmFfc3RhcnQgKHYscCk7Cj4gKyAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQpKTsKPiAr
ICB2YV9lbmQgKHYpOwo+ICsgIHJldHVybiBzOwo+ICt9Cj4gCj4gKy8qIE9TRiA0LjAgQ29tcGFx
IGNjIGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQgaGFzCj4gKyAg
IGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hhcmFj
dGVyIGNvbnN0YW50cy4KPiArICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1
bmF0ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCj4gKyAgIGFzICd4Jy4gIFRoZSBm
b2xsb3dpbmcgaW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQKPiAr
ICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMg
b3V0IHRydWUsIGZvciBhbgo+ICsgICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3Nh
cnkgdG8gd3JpdGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKPiArICAgdGhhdCdzIHRydWUg
b25seSB3aXRoIC1zdGQuICAqLwo+ICtpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAx
IDogLTFdOwo+IAo+ICsvKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVs
dCwgYnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKPiArICAgaW5zaWRlIHN0cmluZ3Mg
YW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwo+ICsjZGVmaW5lIEZPTyh4KSAneCcKPiAraW50
IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07Cj4gCj4gLSAgIyBjaGVja2lu
ZyBmb3Igb2NhbWwgdG9wbGV2ZWwKPiAtICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0
aGVuCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15
ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKPiAteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+IC0kYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHth
Y19jdl9wcm9nX09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgo+IC0gIGFj
X2N2X3Byb2dfT0NBTUw9IiRPQ0FNTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
Cj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+IC1mb3Ig
YXNfZGlyIGluICRQQVRICj4gK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOwo+ICtzdHJ1Y3Qg
czEge2ludCAoKmYpIChpbnQgYSk7fTsKPiArc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91YmxlIGEp
O307Cj4gK2ludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYg
Kiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOwo+ICtpbnQgYXJnYzsKPiArY2hhciAq
KmFyZ3Y7Cj4gK2ludAo+ICttYWluICgpCj4gK3sKPiArcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9
IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOwo+ICsgIDsKPiArICByZXR1
cm4gMDsKPiArfQo+ICtfQUNFT0YKPiArZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5
IC1xbGFuZ2x2bD1hbnNpIC1zdGQgXAo+ICsgICAgICAgLUFlICItQWEgLURfSFBVWF9TT1VSQ0Ui
ICItWGMgLURfX0VYVEVOU0lPTlNfXyIKPiAgZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7YWNfdG9vbF9w
cmVmaXh9b2NhbWwiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJyZWFrIDIK
PiAtICBmaQo+ICsgIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgo+ICsgIGlmIGFjX2ZuX2NfdHJ5
X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiArICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJn
Cj4gK2ZpCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKPiAr
ICB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSAieG5vIiAmJiBicmVhawo+ICBkb25lCj4g
LSAgZG9uZQo+IC1JRlM9JGFzX3NhdmVfSUZTCj4gK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKPiAr
Q0M9JGFjX3NhdmVfQ0MKPiAKPiAgZmkKPiAtZmkKPiAtT0NBTUw9JGFjX2N2X3Byb2dfT0NBTUwK
PiAtaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUwiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1M
IiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gKyMgQUNfQ0FD
SEVfVkFMCj4gK2Nhc2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCj4gKyAgeCkKPiArICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRl
ZCIgPiY1Cj4gKyRhc19lY2hvICJub25lIG5lZWRlZCIgPiY2OyB9IDs7Cj4gKyAgeG5vKQo+ICsg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3Vw
cG9ydGVkIiA+JjUKPiArJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKPiArICAqKQo+
ICsgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCj4gKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUK
PiArJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Cj4gK2VzYWMKPiAraWYg
dGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0aGVuIDoKPiArCj4gIGZpCj4gCj4g
K2FjX2V4dD1jCj4gK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCj4gK2FjX2NvbXBpbGU9JyRDQyAt
YyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKPiArYWNfbGluaz0nJEND
IC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVz
dC4kYWNfZXh0ICRMSUJTID4mNScKPiArYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVy
X2dudQo+IAo+IC1maQo+IC1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTCI7IHRoZW4KPiAt
ICBhY19jdF9PQ0FNTD0kT0NBTUwKPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9j
YW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15
IG9jYW1sOyBhY193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIg
PiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQo
TUFLRSkuLi4gIiA+JjY7IH0KPiArc2V0IHggJHtNQUtFLW1ha2V9Cj4gK2FjX21ha2U9YCRhc19l
Y2hvICIkMiIgfCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAo+ICtpZiBldmFs
ICJ0ZXN0IFwiXCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0K3NldH1cIiIgPSBzZXQ7
IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0
ZXN0IC1uICIkYWNfY3RfT0NBTUwiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0i
JGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiAtZWxzZQo+
IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gLWZvciBhc19kaXIgaW4g
JFBBVEgKPiAtZG8KPiAtICBJRlM9JGFzX3NhdmVfSUZTCj4gLSAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgo+IC0gICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1Cj4gLSAgICBicmVhayAyCj4gLSAgZmkKPiAtZG9uZQo+IC0gIGRvbmUKPiAt
SUZTPSRhc19zYXZlX0lGUwo+IC0KPiAtZmkKPiAtZmkKPiAtYWNfY3RfT0NBTUw9JGFjX2N2X3By
b2dfYWNfY3RfT0NBTUwKPiAtaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgo+IC0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB
TUwiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4g
LSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4gLQo+IC0gIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUwiID0geDsgdGhlbgo+IC0gICAgT0NBTUw9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNy
b3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBX
QVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQi
ID4mMjt9Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICsgIGNhdCA+Y29uZnRlc3QubWFrZSA8
PFxfQUNFT0YKPiArU0hFTEwgPSAvYmluL3NoCj4gK2FsbDoKPiArICAgICAgIEBlY2hvICdAQEAl
JSU9JChNQUtFKT1AQEAlJSUnCj4gK19BQ0VPRgo+ICsjIEdOVSBtYWtlIHNvbWV0aW1lcyBwcmlu
dHMgIm1ha2VbMV06IEVudGVyaW5nIC4uLiIsIHdoaWNoIHdvdWxkIGNvbmZ1c2UgdXMuCj4gK2Nh
c2UgYCR7TUFLRS1tYWtlfSAtZiBjb25mdGVzdC5tYWtlIDI+L2Rldi9udWxsYCBpbgo+ICsgICpA
QEAlJSU9Pyo9QEBAJSUlKikKPiArICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1f
c2V0PXllczs7Cj4gKyAgKikKPiArICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1f
c2V0PW5vOzsKPiAgZXNhYwo+IC0gICAgT0NBTUw9JGFjX2N0X09DQU1MCj4gLSAgZmkKPiArcm0g
LWYgY29uZnRlc3QubWFrZQo+ICtmaQo+ICtpZiBldmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2Vf
JHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2VjaG8gInllcyIgPiY2OyB9
Cj4gKyAgU0VUX01BS0U9Cj4gIGVsc2UKPiAtICBPQ0FNTD0iJGFjX2N2X3Byb2dfT0NBTUwiCj4g
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFr
ZX0iCj4gIGZpCj4gCj4gLQo+IC0gICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCj4gLSAgaWYgdGVz
dCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBh
Y193b3JkPSQyCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gKyMgRmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVy
IGEgQyBwcm9ncmFtIChmYXN0ZXIpLAo+ICsjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBh
bm90aGVyLiAgQnV0IGF2b2lkIHRoZSBicm9rZW4gb3IKPiArIyBpbmNvbXBhdGlibGUgdmVyc2lv
bnM6Cj4gKyMgU3lzViAvZXRjL2luc3RhbGwsIC91c3Ivc2Jpbi9pbnN0YWxsCj4gKyMgU3VuT1Mg
L3Vzci9ldGMvaW5zdGFsbAo+ICsjIElSSVggL3NiaW4vaW5zdGFsbAo+ICsjIEFJWCAvYmluL2lu
c3RhbGwKPiArIyBBbWlnYU9TIC9DL2luc3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mg
b24gZmxvcHB5IGRpc2NzCj4gKyMgQUlYIDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9l
c24ndCB3b3JrIHdpdGhvdXQgYSAtZyBmbGFnCj4gKyMgQUZTIC91c3IvYWZzd3MvYmluL2luc3Rh
bGwsIHdoaWNoIG1pc2hhbmRsZXMgbm9uZXhpc3RlbnQgYXJncwo+ICsjIFNWUjQgL3Vzci91Y2Iv
aW5zdGFsbCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYi
Cj4gKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZl
cmVudCBzZW1hbnRpYwo+ICsjIC4vaW5zdGFsbCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNy
ZWF0ZWQgYnkgbWFrZSBmcm9tIC4vaW5zdGFsbC5zaC4KPiArIyBSZWplY3QgaW5zdGFsbCBwcm9n
cmFtcyB0aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZpbGVzLgo+ICt7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21wYXRpYmxl
IGluc3RhbGwiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJs
ZSBpbnN0YWxsLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgLXogIiRJTlNUQUxMIjsgdGhlbgo+ICtp
ZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRPQ0FNTERF
UCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
Cj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3NhdmVfSUZTCj4gICAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAtICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+IC0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxkZXAiCj4gLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAtICAgIGJy
ZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gKyAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0
IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KPiArY2FzZSAkYXNfZGlyLyBpbiAj
KCgKPiArICAuLyB8IC4vLyB8IC9bY0NdLyogfCBcCj4gKyAgL2V0Yy8qIHwgL3Vzci9zYmluLyog
fCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCj4gKyAgPzpbXFwv
XW9zMltcXC9daW5zdGFsbFtcXC9dKiB8ID86W1xcL11PUzJbXFwvXUlOU1RBTExbXFwvXSogfCBc
Cj4gKyAgL3Vzci91Y2IvKiApIDs7Cj4gKyAgKikKPiArICAgICMgT1NGMSBhbmQgU0NPIE9EVCAz
LjAgaGF2ZSB0aGVpciBvd24gbmFtZXMgZm9yIGluc3RhbGwuCj4gKyAgICAjIERvbid0IHVzZSBp
bnN0YWxsYnNkIGZyb20gT1NGIHNpbmNlIGl0IGluc3RhbGxzIHN0dWZmIGFzIHJvb3QKPiArICAg
ICMgYnkgZGVmYXVsdC4KPiArICAgIGZvciBhY19wcm9nIGluIGdpbnN0YWxsIHNjb2luc3QgaW5z
dGFsbDsgZG8KPiArICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCj4gKyAgICAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNf
ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9
OyB0aGVuCj4gKyAgICAgICAgIGlmIHRlc3QgJGFjX3Byb2cgPSBpbnN0YWxsICYmCj4gKyAgICAg
ICAgICAgZ3JlcCBkc3Btc2cgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251
bGwgMj4mMTsgdGhlbgo+ICsgICAgICAgICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5j
b21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KPiArICAgICAgICAgICA6Cj4gKyAgICAgICAg
IGVsaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKPiArICAgICAgICAgICBncmVwIHB3cGx1
cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCj4g
KyAgICAgICAgICAgIyBwcm9ncmFtLXNwZWNpZmljIGluc3RhbGwgc2NyaXB0IHVzZWQgYnkgSFAg
cHdwbHVzLS1kb24ndCB1c2UuCj4gKyAgICAgICAgICAgOgo+ICsgICAgICAgICBlbHNlCj4gKyAg
ICAgICAgICAgcm0gLXJmIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gY29uZnRlc3QuZGlyCj4g
KyAgICAgICAgICAgZWNobyBvbmUgPiBjb25mdGVzdC5vbmUKPiArICAgICAgICAgICBlY2hvIHR3
byA+IGNvbmZ0ZXN0LnR3bwo+ICsgICAgICAgICAgIG1rZGlyIGNvbmZ0ZXN0LmRpcgo+ICsgICAg
ICAgICAgIGlmICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAtYyBjb25mdGVzdC5vbmUg
Y29uZnRlc3QudHdvICJgcHdkYC9jb25mdGVzdC5kaXIiICYmCj4gKyAgICAgICAgICAgICB0ZXN0
IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgo+ICsgICAgICAgICAg
ICAgdGVzdCAtcyBjb25mdGVzdC5kaXIvY29uZnRlc3Qub25lICYmCj4gKyAgICAgICAgICAgICB0
ZXN0IC1zIGNvbmZ0ZXN0LmRpci9jb25mdGVzdC50d28KPiArICAgICAgICAgICB0aGVuCj4gKyAg
ICAgICAgICAgICBhY19jdl9wYXRoX2luc3RhbGw9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19l
eHQgLWMiCj4gKyAgICAgICAgICAgICBicmVhayAzCj4gKyAgICAgICAgICAgZmkKPiArICAgICAg
ICAgZmkKPiArICAgICAgIGZpCj4gKyAgICAgIGRvbmUKPiArICAgIGRvbmUKPiArICAgIDs7Cj4g
K2VzYWMKPiArCj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gK3JtIC1yZiBjb25m
dGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgo+ICsKPiAgZmkKPiArICBpZiB0ZXN0
ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgo+ICsgICAgSU5TVEFMTD0k
YWNfY3ZfcGF0aF9pbnN0YWxsCj4gKyAgZWxzZQo+ICsgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1
c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQo+ICsgICAgIyB2YWx1ZSBm
b3IgSU5TVEFMTCB3aXRoaW4gYSBzb3VyY2UgZGlyZWN0b3J5LCBiZWNhdXNlIHRoYXQgd2lsbAo+
ICsgICAgIyBicmVhayBvdGhlciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBkaXJl
Y3RvcnkgaXMKPiArICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUg
bmFtZS4KPiArICAgIElOU1RBTEw9JGFjX2luc3RhbGxfc2gKPiArICBmaQo+ICBmaQo+IC1PQ0FN
TERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERFUAo+IC1pZiB0ZXN0IC1uICIkT0NBTUxERVAiOyB0aGVu
Cj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRP
Q0FNTERFUCIgPiY1Cj4gLSRhc19lY2hvICIkT0NBTUxERVAiID4mNjsgfQo+IC1lbHNlCj4gLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
PiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtZmkKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKPiArJGFzX2VjaG8gIiRJTlNU
QUxMIiA+JjY7IH0KPiAKPiArIyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1bk9TNCBzaCBtaXNoYW5k
bGVzIGJyYWNlcyBpbiAke3Zhci12YWx9Lgo+ICsjIEl0IHRoaW5rcyB0aGUgZmlyc3QgY2xvc2Ug
YnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgo+ICt0ZXN0IC16ICIkSU5TVEFM
TF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCj4gCj4gLWZpCj4gLWlm
IHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MREVQIjsgdGhlbgo+IC0gIGFjX2N0X09DQU1MREVQ
PSRPQ0FNTERFUAo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgb2NhbWxk
ZXA7IGFjX3dvcmQ9JDIKPiArdGVzdCAteiAiJElOU1RBTExfU0NSSVBUIiAmJiBJTlNUQUxMX1ND
UklQVD0nJHtJTlNUQUxMfScKPiArCj4gK3Rlc3QgLXogIiRJTlNUQUxMX0RBVEEiICYmIElOU1RB
TExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCj4gKwo+ICsjIEV4dHJhY3QgdGhlIGZpcnN0IHdv
cmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAr
c2V0IGR1bW15IGJpc29uOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cGF0aF9CSVNPTitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KPiAt
ICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxERVAiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiArICBjYXNlICRCSVNPTiBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10q
KQo+ICsgIGFjX2N2X3BhdGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAg
IElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4g
ICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTERFUD0ib2NhbWxkZXAiCj4gKyAgICBhY19jdl9wYXRoX0JJU09OPSIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Cj4gICAgICBicmVhayAyCj4gICAgZmkKPiBAQCAtNTgzMyw1MyArMzU2NSwzOSBAQCBkb25lCj4g
ICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gKyAgOzsKPiArZXNhYwo+ICBmaQo+IC1m
aQo+IC1hY19jdF9PQ0FNTERFUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUAo+IC1pZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERFUCIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3RfT0NBTUxERVAiID4mNjsgfQo+ICtCSVNPTj0kYWNfY3ZfcGF0aF9CSVNPTgo+ICtp
ZiB0ZXN0IC1uICIkQklTT04iOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1Cj4gKyRhc19lY2hvICIkQklTT04iID4m
NjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtICBp
ZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7IHRoZW4KPiAtICAgIE9DQU1MREVQPSJubyIK
PiAtICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cj4gLXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy
ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsK
PiAtZXNhYwo+IC0gICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCj4gLSAgZmkKPiAtZWxzZQo+
IC0gIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKPiAtZmkKPiAtCj4gCj4gLSAgIyBj
aGVja2luZyBmb3Igb2NhbWxta3RvcAo+IC0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxta3RvcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKPiArIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJmbGV4Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KPiArc2V0IGR1bW15IGZsZXg7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+
ICAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVz
dCAiJHthY19jdl9wcm9nX09DQU1MTUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0
ICIke2FjX2N2X3BhdGhfRkxFWCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhl
bgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJE9DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0Lgo+IC1lbHNlCj4gLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKPiArICBjYXNlICRGTEVYIGluCj4gKyAgW1xcL10qIHwgPzpbXFwvXSopCj4g
KyAgYWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl
c3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0k
YXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCj4gKyAgICBhY19jdl9wYXRo
X0ZMRVg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gICAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC01ODg3LDM5ICszNjA1LDM5IEBA
IGRvbmUKPiAgICBkb25lCj4gIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiArICA7Owo+ICtlc2FjCj4g
IGZpCj4gLWZpCj4gLU9DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxNS1RPUAo+IC1pZiB0ZXN0
IC1uICIkT0NBTUxNS1RPUCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtUT1AiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1M
TUtUT1AiID4mNjsgfQo+ICtGTEVYPSRhY19jdl9wYXRoX0ZMRVgKPiAraWYgdGVzdCAtbiAiJEZM
RVgiOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRGTEVYIiA+JjUKPiArJGFzX2VjaG8gIiRGTEVYIiA+JjY7IH0KPiAgZWxzZQo+ICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gCj4gLWZpCj4gLWlmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCj4gLSAgYWNfY3RfT0NBTUxNS1RPUD0kT0NB
TUxNS1RPUAo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta3RvcCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBvY2FtbG1r
dG9wOyBhY193b3JkPSQyCj4gKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBwZXJsOyBh
Y193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9Q
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX1BFUkwrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAt
ICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MTUtUT1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KPiAtZWxzZQo+IC1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCj4gKyAgY2FzZSAkUEVSTCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2
X3BhdGhfUEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgo+ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3NhdmVf
SUZTCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxNS1RPUD0ib2NhbWxta3RvcCIKPiArICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJl
YWsgMgo+ICAgIGZpCj4gQEAgLTU5MjcsNTMgKzM2NDUsNDYgQEAgZG9uZQo+ICAgIGRvbmUKPiAg
SUZTPSRhc19zYXZlX0lGUwo+IAo+ICsgIHRlc3QgLXogIiRhY19jdl9wYXRoX1BFUkwiICYmIGFj
X2N2X3BhdGhfUEVSTD0ibm8iCj4gKyAgOzsKPiArZXNhYwo+ICBmaQo+IC1maQo+IC1hY19jdF9P
Q0FNTE1LVE9QPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtUT1AKPiAtaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MTUtUT1AiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9QIiA+JjUKPiAtJGFzX2VjaG8gIiRh
Y19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KPiArUEVSTD0kYWNfY3ZfcGF0aF9QRVJMCj4gK2lmIHRl
c3QgLW4gIiRQRVJMIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkUEVSTCIgPiY1Cj4gKyRhc19lY2hvICIkUEVSTCIgPiY2OyB9Cj4g
IGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3Qg
IngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4OyB0aGVuCj4gLSAgICBPQ0FNTE1LVE9QPSJubyIKPiAt
ICBlbHNlCj4gLSAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4g
LXllczopCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUK
PiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp
eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+IC1hY190b29sX3dhcm5lZD15ZXMgOzsKPiAt
ZXNhYwo+IC0gICAgT0NBTUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAo+IC0gIGZpCj4gLWVsc2UK
PiAtICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgo+IC1maQo+IAo+ICtpZiB0
ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kIHBlcmwsIHBsZWFzZSBpbnN0YWxsIHBlcmwiICIkTElORU5PIiA1Cj4gK2Zp
Cj4gK2lmIHRlc3QgIngkeGFwaSIgPSAieHkiOyB0aGVuIDoKPiAKPiAtICAjIGNoZWNraW5nIGZv
ciBvY2FtbG1rbGliCj4gLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0g
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGli
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0kMgo+ICsgICAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgo+ICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
K2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9DVVJMK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJE9DQU1MTUtM
SUIiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gLWVsc2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGNhc2UgJENVUkwgaW4KPiArICBbXFwvXSogfCA/Oltc
XC9dKikKPiArICBhY19jdl9wYXRoX0NVUkw9IiRDVVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiArICA7Owo+ICsgICopCj4gKyAgYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gIGRvCj4g
ICAgSUZTPSRhc19zYXZlX0lGUwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4g
ICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
PiAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19j
dl9wcm9nX09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKPiArICAgIGFj
X2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAgICAgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTU5ODEsMzkgKzM2
OTIsNDQgQEAgZG9uZQo+ICAgIGRvbmUKPiAgSUZTPSRhc19zYXZlX0lGUwo+IAo+ICsgIHRlc3Qg
LXogIiRhY19jdl9wYXRoX0NVUkwiICYmIGFjX2N2X3BhdGhfQ1VSTD0ibm8iCj4gKyAgOzsKPiAr
ZXNhYwo+ICBmaQo+IC1maQo+IC1PQ0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKPiAt
aWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LTElCIiA+JjUKPiAtJGFzX2VjaG8g
IiRPQ0FNTE1LTElCIiA+JjY7IH0KPiArQ1VSTD0kYWNfY3ZfcGF0aF9DVVJMCj4gK2lmIHRlc3Qg
LW4gIiRDVVJMIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1Cj4gKyRhc19lY2hvICIkQ1VSTCIgPiY2OyB9Cj4gIGVs
c2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+ICtpZiB0ZXN0IHgi
JHtDVVJMfSIgPT0geCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8i
IDUKPiAgZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRoZW4KPiAt
ICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJvY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiAtc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKPiArICAgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAieG1sMi1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIKPiAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQo+ICAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0K
PiAtaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2X3BhdGhfWE1MK3NldH0iID0gc2V0OyB0aGVuIDoKPiAg
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MTUtMSUIiOyB0aGVuCj4gLSAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSIk
YWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gLWVs
c2UKPiAtYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGNhc2UgJFhN
TCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2X3BhdGhfWE1MPSIkWE1MIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiArICA7Owo+ICsg
ICopCj4gKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNf
ZGlyIGluICRQQVRICj4gIGRvCj4gICAgSUZTPSRhc19zYXZlX0lGUwo+ICAgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9Im9jYW1sbWtsaWIi
Cj4gKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiAg
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTYw
MjEsNDQgKzM3MzcsMzkgQEAgZG9uZQo+ICAgIGRvbmUKPiAgSUZTPSRhc19zYXZlX0lGUwo+IAo+
ICsgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hNTCIgJiYgYWNfY3ZfcGF0aF9YTUw9Im5vIgo+ICsg
IDs7Cj4gK2VzYWMKPiAgZmkKPiAtZmkKPiAtYWNfY3RfT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE1LTElCCj4gLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgo+
IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxNS0xJQiIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3RfT0NBTUxNS0xJQiIgPiY2OyB9
Cj4gK1hNTD0kYWNfY3ZfcGF0aF9YTUwKPiAraWYgdGVzdCAtbiAiJFhNTCI7IHRoZW4KPiArICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1
Cj4gKyRhc19lY2hvICIkWE1MIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJubyIg
PiY2OyB9Cj4gIGZpCj4gCj4gLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LTElCIiA9IHg7IHRo
ZW4KPiAtICAgIE9DQU1MTUtMSUI9Im5vIgo+IC0gIGVsc2UKPiAtICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAteWVzOikKPiAteyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9
Cj4gLWFjX3Rvb2xfd2FybmVkPXllcyA7Owo+IC1lc2FjCj4gLSAgICBPQ0FNTE1LTElCPSRhY19j
dF9PQ0FNTE1LTElCCj4gLSAgZmkKPiAtZWxzZQo+IC0gIE9DQU1MTUtMSUI9IiRhY19jdl9wcm9n
X09DQU1MTUtMSUIiCj4gKwo+ICtpZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgo+ICt0aGVuCj4g
KyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sMi1jb25maWcsIHBsZWFzZSBp
bnN0YWxsIHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQo+ICBmaQo+IAo+ICtmaQo+ICtpZiB0ZXN0
ICJ4JG9jYW1sdG9vbHMiID0gInh5IjsgdGhlbiA6Cj4gCj4gLSAgIyBjaGVja2luZyBmb3Igb2Nh
bWxkb2MKPiArICAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjCj4gICAgaWYgdGVzdCAtbiAiJGFj
X3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHth
Y190b29sX3ByZWZpeH1vY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQy
Cj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2Fj
X2N2X3Byb2dfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfT0NBTUxDK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgo+IC0gIGFj
X2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gKyAgaWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX09D
QU1MQz0iJE9DQU1MQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gIGVsc2UK
PiAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGlu
ICRQQVRICj4gQEAgLTYwNjcsNyArMzc3OCw3IEBAIGRvCj4gICAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KPiAtICAgIGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2Mi
Cj4gKyAgICBhY19jdl9wcm9nX09DQU1MQz0iJHthY190b29sX3ByZWZpeH1vY2FtbGMiCj4gICAg
ICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02MDc3
LDEwICszNzg4LDEwIEBAIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAgZmkKPiAtT0NBTUxE
T0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKPiAtaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgo+
IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NB
TUxET0MiID4mNQo+IC0kYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KPiArT0NBTUxDPSRhY19j
dl9wcm9nX09DQU1MQwo+ICtpZiB0ZXN0IC1uICIkT0NBTUxDIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+JjUKPiAr
JGFzX2VjaG8gIiRPQ0FNTEMiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8gIm5vIiA+
JjY7IH0KPiBAQCAtNjA4OCwxNyArMzc5OSwxNyBAQCBmaQo+IAo+IAo+ICBmaQo+IC1pZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERPQyI7IHRoZW4KPiAtICBhY19jdF9PQ0FNTERPQz0kT0NB
TUxET0MKPiAtICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15IG9jYW1sZG9jOyBh
Y193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQyI7IHRoZW4KPiArICBh
Y19jdF9PQ0FNTEM9JE9DQU1MQwo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2Nh
bWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15
IG9jYW1sYzsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgo+IC0g
IGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9IiRhY19jdF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQyI7IHRo
ZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0iJGFjX2N0X09DQU1MQyIgIyBMZXQgdGhl
IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gIGVsc2UKPiAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gQEAgLTYxMDcsNyArMzgx
OCw3IEBAIGRvCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxET0M9Im9jYW1sZG9jIgo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEM9Im9j
YW1sYyIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZp
Cj4gQEAgLTYxMTcsMTcgKzM4MjgsMTcgQEAgSUZTPSRhc19zYXZlX0lGUwo+IAo+ICBmaQo+ICBm
aQo+IC1hY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQwo+IC1pZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERPQyIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQo+ICthY19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCj4gKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEMi
ID4mNQo+ICskYXNfZWNobyAiJGFjX2N0X09DQU1MQyIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAk
YXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxE
T0MiID0geDsgdGhlbgo+IC0gICAgT0NBTUxET0M9Im5vIgo+ICsgIGlmIHRlc3QgIngkYWNfY3Rf
T0NBTUxDIiA9IHg7IHRoZW4KPiArICAgIE9DQU1MQz0ibm8iCj4gICAgZWxzZQo+ICAgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgo+ICB5ZXM6KQo+IEBAIC02MTM1
LDI0ICszODQ2LDQxIEBAIHllczopCj4gICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiAgYWNf
dG9vbF93YXJuZWQ9eWVzIDs7Cj4gIGVzYWMKPiAtICAgIE9DQU1MRE9DPSRhY19jdF9PQ0FNTERP
Qwo+ICsgICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMKPiAgICBmaQo+ICBlbHNlCj4gLSAgT0NBTUxE
T0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgo+ICsgIE9DQU1MQz0iJGFjX2N2X3Byb2dfT0NBTUxD
Igo+ICBmaQo+IAo+IAo+IC0gICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQKPiAtICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCj4gLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxk
OyBhY193b3JkPSQyCj4gKyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgo+ICsgICAg
IE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4q
XCkkfFwxfHAnYAo+ICsgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT04iID4mNQo+ICskYXNfZWNo
byAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjY7IH0KPiArICAgICAjIElmIE9D
QU1MTElCIGlzIHNldCwgdXNlIGl0Cj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0
aGVuCj4gKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rldi9udWxsIHx8ICRP
Q0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRgCj4gKyAgICAgZWxzZQo+ICsgICAgICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ0FNTExJ
QiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQo+ICskYXNfZWNobyAiT0NBTUxM
SUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7IH0KPiArICAgICBmaQo+ICsg
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2Ft
bCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjUKPiArJGFzX2VjaG8gIk9DYW1sIGxpYnJh
cnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQo+ICsKPiArCj4gKwo+ICsKPiArICAgICAjIGNo
ZWNraW5nIGZvciBvY2FtbG9wdAo+ICsgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0
ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxE
IjsgdGhlbgo+IC0gIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRo
ZW4KPiArICBhY19jdl9wcm9nX09DQU1MT1BUPSIkT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0Lgo+ICBlbHNlCj4gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+IEBAIC02MTYxLDcgKzM4ODksNyBAQCBk
bwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wcm9nX09DQU1MQlVJTEQ9
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZCIKPiArICAgIGFjX2N2X3Byb2dfT0NBTUxPUFQ9
IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
PiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02MTcxLDEwICszODk5LDEwIEBAIElGUz0kYXNf
c2F2ZV9JRlMKPiAKPiAgZmkKPiAgZmkKPiAtT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19PQ0FNTEJV
SUxECj4gLWlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIgPiY1Cj4gLSRh
c19lY2hvICIkT0NBTUxCVUlMRCIgPiY2OyB9Cj4gK09DQU1MT1BUPSRhY19jdl9wcm9nX09DQU1M
T1BUCj4gK2lmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BUIiA+JjUKPiArJGFzX2Vj
aG8gIiRPQ0FNTE9QVCIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsg
fQo+IEBAIC02MTgyLDE3ICszOTEwLDE3IEBAIGZpCj4gCj4gCj4gIGZpCj4gLWlmIHRlc3QgLXog
IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiOyB0aGVuCj4gLSAgYWNfY3RfT0NBTUxCVUlMRD0kT0NB
TUxCVUlMRAo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBvY2FtbGJ1
aWxkOyBhY193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BUIjsgdGhl
bgo+ICsgIGFjX2N0X09DQU1MT1BUPSRPQ0FNTE9QVAo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgo+ICtzZXQgZHVtbXkgb2NhbWxvcHQ7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICAkYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHth
Y19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0
ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxCVUlMRCI7IHRoZW4KPiAtICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9IiRhY19j
dF9PQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiArICBpZiB0
ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN
TE9QVD0iJGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
PiAgZWxzZQo+ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gIGZvciBh
c19kaXIgaW4gJFBBVEgKPiBAQCAtNjIwMSw3ICszOTI5LDcgQEAgZG8KPiAgICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj
dXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxk
Igo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0ib2NhbWxvcHQiCj4gICAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02MjExLDE3ICsz
OTM5LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAgZmkKPiAtYWNfY3RfT0NBTUxC
VUlMRD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxECj4gLWlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTEJVSUxEIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3Rf
T0NBTUxCVUlMRCIgPiY2OyB9Cj4gK2FjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09D
QU1MT1BUCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KPiArICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BU
IiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIgPiY2OyB9Cj4gIGVsc2UKPiAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+
ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0gIGlmIHRlc3QgIngkYWNfY3RfT0NB
TUxCVUlMRCIgPSB4OyB0aGVuCj4gLSAgICBPQ0FNTEJVSUxEPSJubyIKPiArICBpZiB0ZXN0ICJ4
JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KPiArICAgIE9DQU1MT1BUPSJubyIKPiAgICBlbHNl
Cj4gICAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCj4gIHllczop
Cj4gQEAgLTYyMjksNDQgKzM5NTcsODkgQEAgeWVzOikKPiAgJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjI7fQo+ICBhY190b29sX3dhcm5lZD15ZXMgOzsKPiAgZXNhYwo+IC0gICAgT0NBTUxCVUlMRD0k
YWNfY3RfT0NBTUxCVUlMRAo+ICsgICAgT0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCj4gICAgZmkK
PiAgZWxzZQo+IC0gIE9DQU1MQlVJTEQ9IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiCj4gKyAgT0NB
TUxPUFQ9IiRhY19jdl9wcm9nX09DQU1MT1BUIgo+ICBmaQo+IAo+ICsgICAgIE9DQU1MQkVTVD1i
eXRlCj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KPiArICAgICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogQ2Fubm90IGZp
bmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuIiA+JjUKPiArJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0
aW9uIG9ubHkuIiA+JjI7fQo+ICsgICAgIGVsc2UKPiArICAgICAgIFRNUFZFUlNJT049YCRPQ0FN
TE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKPiArICAg
ICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCj4gKyAg
ICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQo+
ICskYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2Fy
ZGVkLiIgPiY2OyB9Cj4gKyAgICAgICAgICAgT0NBTUxPUFQ9bm8KPiArICAgICAgIGVsc2UKPiAr
ICAgICAgICAgICBPQ0FNTEJFU1Q9b3B0Cj4gKyAgICAgICBmaQo+ICsgICAgIGZpCj4gCj4gLSAg
ICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLSAgICAgICAgaWYgdGVz
dCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgo+IAo+IC0gICAgICAgICAg
ICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5k
IE9jYW1sIiAiJExJTkVOTyIgNQo+IC1maQo+IC0gICAgICAgIG9jYW1sdG9vbHM9Im4iCj4gKyAg
ICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAo+ICsgICAgIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIK
PiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiArZWxzZQo+ICsgIGlmIHRl
c3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9
IiRPQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNl
Cj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBp
biAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgo+ICsgICAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2Nh
bWxjLm9wdCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsg
IGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiArZmkK
PiArT0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVAo+ICtpZiB0ZXN0IC1uICIk
T0NBTUxDRE9UT1BUIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKPiArJGFzX2VjaG8gIiRPQ0FNTENE
T1RPUFQiID4mNjsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiArZmkK
PiArCj4gCj4gIGZpCj4gLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmFzaCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBiYXNoOyBhY193
b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCI7IHRoZW4KPiAr
ICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RPVE9QVAo+ICsgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gK3NldCBkdW1teSBvY2FtbGMub3B0OyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
PiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRl
c3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHth
Y19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJEJBU0ggaW4KPiAtICBb
XFwvXSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAg
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRh
Y19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RP
UFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9y
IGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9CQVNIPSIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5v
cHQiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+
IEBAIC02Mjc0LDU2ICs0MDQ3LDYzIEBAIGRvbmUKPiAgICBkb25lCj4gIElGUz0kYXNfc2F2ZV9J
RlMKPiAKPiAtICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9
Im5vIgo+IC0gIDs7Cj4gLWVzYWMKPiAgZmkKPiAtQkFTSD0kYWNfY3ZfcGF0aF9CQVNICj4gLWlm
IHRlc3QgLW4gIiRCQVNIIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkQkFTSCIgPiY1Cj4gLSRhc19lY2hvICIkQkFTSCIgPiY2OyB9
Cj4gK2ZpCj4gK2FjX2N0X09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RP
UFQKPiAraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KPiArICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQ0RP
VE9QVCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjY7IH0KPiAgZWxz
ZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC1pZiB0ZXN0IHgi
JHtCQVNIfSIgPT0geCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2giICIkTElORU5PIiA1Cj4gKyAgaWYgdGVz
dCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgo+ICsgICAgT0NBTUxDRE9UT1BUPSJu
byIKPiArICBlbHNlCj4gKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVk
IGluCj4gK3llczopCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0
IiA+JjUKPiArJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQo+ICthY190b29sX3dhcm5lZD15ZXMg
OzsKPiArZXNhYwo+ICsgICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKPiArICBm
aQo+ICtlbHNlCj4gKyAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCj4g
IGZpCj4gLWlmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhlbiA6Cj4gLQo+IC0gICAg
aWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyI7IHRoZW4gOgo+IAo+IC0gICAgICAgIFBZ
VEhPTlBBVEg9JFBZVEhPTgo+IC0gICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhg
Cj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MQ0RPVE9QVCIgIT0gIm5vIjsgdGhlbgo+ICsgICAgICAg
VE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpc
KC4qXCkkfFwxfHAnIGAKPiArICAgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1M
VkVSU0lPTiIgOyB0aGVuCj4gKyAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1s
Yy5vcHQgZGlzY2FyZGVkLiIgPiY1Cj4gKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsgfQo+ICsgICAgICAgZWxzZQo+ICsg
ICAgICAgICAgIE9DQU1MQz0kT0NBTUxDRE9UT1BUCj4gKyAgICAgICBmaQo+ICsgICAgIGZpCj4g
Cj4gLWVsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgo+IC0gIFBZVEhPTj0icHl0aG9uIgo+
IC1lbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3Qg
YW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKPiAtZmkKPiAtICAgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJFBZVEhPTiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCj4gKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0Cj4gKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsg
dGhlbgo+ICsgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+ICsgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgJHth
Y190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICAk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIk
e2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBjYXNlICRQWVRIT05QQVRIIGluCj4g
LSAgW1xcL10qIHwgPzpbXFwvXSopCj4gLSAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9O
UEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAg
OzsKPiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAr
ICBpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19PQ0FN
TE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4g
IGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3NhdmVfSUZTCj4gICAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3BhdGhfUFlUSE9OUEFUSD0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0Igo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
Cj4gICAgICBicmVhayAyCj4gICAgZmkKPiBAQCAtNjMzMSw2MiArNDExMSwzOSBAQCBkb25lCj4g
ICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhf
UFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKPiAtICA7Owo+IC1lc2Fj
Cj4gIGZpCj4gLVBZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAo+IC1pZiB0ZXN0IC1u
ICIkUFlUSE9OUEFUSCI7IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJFBZVEhPTlBBVEgiID4mNQo+IC0kYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQo+ICtmaQo+ICtPQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERP
VE9QVAo+ICtpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVERPVE9QVCIg
PiY1Cj4gKyRhc19lY2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAg
JGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAKPiAtaWYgdGVzdCB4IiR7UFlUSE9OUEFU
SH0iID09IHgibm8iCj4gLXRoZW4KPiAtICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCAkUFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQo+IC1maQo+IC0g
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
cHl0aG9uIHZlcnNpb24gPj0gMi4zICIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBw
eXRob24gdmVyc2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9Cj4gLWAkUFlUSE9OIC1jICdpbXBvcnQg
c3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKPiAtaWYg
dGVzdCAiJD8iICE9ICIwIgo+IC10aGVuCj4gLSAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAt
ViAyPiYxYAo+IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtICAgIGFzX2ZuX2Vycm9y
ICQ/ICIkcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9u
IGlzIDIuMyIgIiRMSU5FTk8iIDUKPiAtZWxzZQo+IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gLSRhc19lY2hvICJ5ZXMiID4m
NjsgfQo+ICBmaQo+IC0KPiAtYWNfcHJldmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCj4gLWFjX3By
ZXZpb3VzX2xkZmxhZ3M9JExERkxBR1MKPiAtYWNfcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLWMg
J2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gLSAgICBwcmludCBkaXN0dXRpbHMuc3lz
Y29uZmlnLmdldF9jb25maWdfdmFyKCJWRVJTSU9OIiknYAo+IC0jIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRQWVRIT04tY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiAtc2V0IGR1bW15ICRQWVRIT04tY29uZmlnOyBhY193b3JkPSQyCj4gK2lmIHRl
c3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIjsgdGhlbgo+ICsgIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAib2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
PiArc2V0IGR1bW15IG9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfcHljb25maWcrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2Fj
X2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBjYXNlICRweWNvbmZpZyBpbgo+
IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+IC0gIGFjX2N2X3BhdGhfcHljb25maWc9IiRweWNvbmZp
ZyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gLSAgOzsK
PiAtICAqKQo+IC0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArICBp
ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCj4gIGZvciBhc19kaXIgaW4gJFBBVEgKPiAgZG8KPiAgICBJRlM9JGFzX3Nh
dmVfSUZTCj4gICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAgICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICAgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiAtICAgIGFjX2N2X3BhdGhfcHljb25m
aWc9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MT1BURE9UT1BUPSJvY2FtbG9wdC5vcHQiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKPiAgICAgIGJyZWFrIDIKPiAgICBmaQo+IEBAIC02Mzk0LDEyNyArNDE1MSw2OCBAQCBkb25l
Cj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfcHljb25maWciICYmIGFjX2N2X3BhdGhfcHljb25maWc9Im5vIgo+IC0gIDs7Cj4gLWVzYWMK
PiAgZmkKPiAtcHljb25maWc9JGFjX2N2X3BhdGhfcHljb25maWcKPiAtaWYgdGVzdCAtbiAiJHB5
Y29uZmlnIjsgdGhlbgo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkcHljb25maWciID4mNQo+IC0kYXNfZWNobyAiJHB5Y29uZmlnIiA+JjY7IH0K
PiArZmkKPiArYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE
T1RPUFQKPiAraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgo+ICsgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB
TUxPUFRET1RPUFQiID4mNQo+ICskYXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7
IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC1p
ZiB0ZXN0IHgiJHB5Y29uZmlnIiA9PSB4Im5vIjsgdGhlbiA6Cj4gLQo+IC0gICAgICAgIENQUEZM
QUdTPSIkQ0ZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+
IC0gICAgICAgIHByaW50ICItSSIgKyBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFy
KCJJTkNMVURFUFkiKSdgIgo+IC0gICAgQ1BQRkxBR1M9IiRDUFBGTEFHUyBgJFBZVEhPTiAtYyAn
aW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKPiAtICAgICAgICBwcmludCBkaXN0dXRpbHMu
c3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJDRkxBR1MiKSdgIgo+IC0gICAgTERGTEFHUz0iJExE
RkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gLSAgICAg
ICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElCUyIpJ2AiCj4g
LSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNj
b25maWc7IFwKPiAtICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdf
dmFyKCJTWVNMSUJTIiknYCIKPiAtICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdp
bXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+IC0gICAgICAgIHByaW50ICItTCIgKyBkaXN0
dXRpbHMuc3lzY29uZmlnLmdldF9weXRob25fbGliKHBsYXRfc3BlY2lmaWM9MSxcCj4gLSAgICAg
ICAgc3RhbmRhcmRfbGliPTEpICsgIi9jb25maWciJ2AiCj4gLSAgICBMREZMQUdTPSIkTERGTEFH
UyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKPiAtICAgICAgICBw
cmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFyKCJMSU5LRk9SU0hBUkVEIikn
YCIKPiAtICAgIExERkxBR1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxz
LnN5c2NvbmZpZzsgXAo+IC0gICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2Nv
bmZpZ192YXIoIkxERkxBR1MiKSdgIgo+IC0KPiAtZWxzZQo+IC0KPiAtICAgICAgICBDUFBGTEFH
Uz0iJENGTEFHUyBgJFBZVEhPTi1jb25maWcgLS1jZmxhZ3NgIgo+IC0gICAgTERGTEFHUz0iJExE
RkxBR1MgYCRQWVRIT04tY29uZmlnIC0tbGRmbGFnc2AiCj4gLQo+IC1maQo+IC0KPiAtYWNfZm5f
Y19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVy
X1B5dGhvbl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVh
ZGVyX1B5dGhvbl9oIiA9IHgiInllczsgdGhlbiA6Cj4gLQo+ICsgIGlmIHRlc3QgIngkYWNfY3Rf
T0NBTUxPUFRET1RPUFQiID0geDsgdGhlbgo+ICsgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgo+ICsg
IGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAr
eWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+
ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtl
c2FjCj4gKyAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NBTUxPUFRET1RPUFQKPiArICBmaQo+
ICBlbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIFB5dGhvbiBkZXZlbG9w
bWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQo+ICsgIE9DQU1MT1BURE9UT1BUPSIkYWNfY3ZfcHJv
Z19PQ0FNTE9QVERPVE9QVCIKPiAgZmkKPiAKPiArICAgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVERP
VE9QVCIgIT0gIm5vIjsgdGhlbgo+ICsgICAgICAgICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9U
T1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAo+ICsgICAg
ICAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KPiAr
ICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiB2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQu
IiA+JjUKPiArJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQu
b3B0IGRpc2NhcmRlZC4iID4mNjsgfQo+ICsgICAgICAgICAgZWxzZQo+ICsgICAgICAgICAgICAg
T0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCj4gKyAgICAgICAgICBmaQo+ICsgICAgICAgIGZpCj4g
KyAgICAgZmkKPiAKPiAtYXNfYWNfTGliPWAkYXNfZWNobyAiYWNfY3ZfbGliX3B5dGhvbiRhY19w
eXRob25fdmVyc2lvbicnX1B5QXJnX1BhcnNlVHVwbGUiIHwgJGFzX3RyX3NoYAo+IC17ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBQeUFyZ19QYXJz
ZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiA+JjUKPiAtJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNp
b24uLi4gIiA+JjY7IH0KPiAtaWYgZXZhbCAidGVzdCBcIlwkeyRhc19hY19MaWIrc2V0fVwiIiA9
IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0g
IGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWxweXRob24kYWNfcHl0aG9u
X3ZlcnNpb24gICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4gLS8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIg
UHlBcmdfUGFyc2VUdXBsZSAoKTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1yZXR1cm4gUHlB
cmdfUGFyc2VUdXBsZSAoKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4g
LWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBldmFsICIkYXNfYWNf
TGliPXllcyIKPiAtZWxzZQo+IC0gIGV2YWwgIiRhc19hY19MaWI9bm8iCj4gLWZpCj4gLXJtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3Qk
YWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElC
Uwo+IC1maQo+IC1ldmFsIGFjX3Jlcz1cJCRhc19hY19MaWIKPiAtICAgICAgICAgICAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1
Cj4gLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KPiAtaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19h
Y19MaWIiXCIgPSB4InllcyI7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
PiAtI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfTElCcHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiB8
ICRhc190cl9jcHBgIDEKPiAtX0FDRU9GCj4gLQo+IC0gIExJQlM9Ii1scHl0aG9uJGFjX3B5dGhv
bl92ZXJzaW9uICRMSUJTIgo+IAo+IC1lbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGEgc3VpdGFibGUgcHl0aG9uIGRldmVsb3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1
Cj4gLWZpCj4gKyAgZmkKPiAKPiAtQ1BQRkxBR1M9JGFjX3ByZXZpb3VzX2NwcGZsYWdzCj4gLUxE
TEZBR1M9JGFjX3ByZXZpb3VzX2xkZmxhZ3MKPiAKPiAKPiAtZmkKPiAtIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCj4gLXNldCBkdW1teSB4Z2V0dGV4dDsgYWNfd29yZD0kMgo+ICsgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sIHRvcGxldmVsCj4gKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft
bCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cHJvZ19PQ0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJFhHRVRURVhUIGluCj4gLSAgW1xcL10qIHwgPzpbXFwv
XSopCj4gLSAgYWNfY3ZfcGF0aF9YR0VUVEVYVD0iJFhHRVRURVhUIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTCI7
IHRoZW4KPiArICBhY19jdl9wcm9nX09DQU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMK
PiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9YR0VUVEVYVD0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJy
ZWFrIDIKPiAgICBmaQo+IEBAIC02NTIyLDQ0ICs0MjIwLDM5IEBAIGRvbmUKPiAgICBkb25lCj4g
IElGUz0kYXNfc2F2ZV9JRlMKPiAKPiAtICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIg
JiYgYWNfY3ZfcGF0aF9YR0VUVEVYVD0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1YR0VU
VEVYVD0kYWNfY3ZfcGF0aF9YR0VUVEVYVAo+IC1pZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVu
Cj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRY
R0VUVEVYVCIgPiY1Cj4gLSRhc19lY2hvICIkWEdFVFRFWFQiID4mNjsgfQo+ICtmaQo+ICtPQ0FN
TD0kYWNfY3ZfcHJvZ19PQ0FNTAo+ICtpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCj4gKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTCIgPiY1
Cj4gKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFzX2VjaG8gIm5v
IiA+JjY7IH0KPiAgZmkKPiAKPiAKPiAtaWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgo+
IC10aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeGdldHRleHQsIHBs
ZWFzZSBpbnN0YWxsIHhnZXR0ZXh0IiAiJExJTkVOTyIgNQo+ICBmaQo+IC0jIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgo+IC1zZXQgZHVtbXkgYXM4NjsgYWNfd29yZD0kMgo+ICtpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTCI7IHRoZW4KPiArICBhY19jdF9PQ0FNTD0kT0NBTUwKPiArICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiArc2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAg
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3Qg
IiR7YWNfY3ZfcGF0aF9BUzg2K3NldH0iID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19j
dl9wcm9nX2FjX2N0X09DQU1MK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgY2FzZSAkQVM4NiBpbgo+IC0gIFtcXC9dKiB8ID86
W1xcL10qKQo+IC0gIGFjX2N2X3BhdGhfQVM4Nj0iJEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgo+IC0gIDs7Cj4gLSAgKikKPiAtICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1M
IjsgdGhlbgo+ICsgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9IiRhY19jdF9PQ0FNTCIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCj4gK2Vsc2UKPiArYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gIGRvCj4gICAgSUZT
PSRhc19zYXZlX0lGUwo+ICAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wYXRo
X0FTODY9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MPSJvY2FtbCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICAgICAgYnJl
YWsgMgo+ICAgIGZpCj4gQEAgLTY1NjcsNDQgKzQyNjAsNTMgQEAgZG9uZQo+ICAgIGRvbmUKPiAg
SUZTPSRhc19zYXZlX0lGUwo+IAo+IC0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0FTODYiICYmIGFj
X2N2X3BhdGhfQVM4Nj0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1BUzg2PSRhY19jdl9w
YXRoX0FTODYKPiAtaWYgdGVzdCAtbiAiJEFTODYiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRBUzg2IiA+JjUKPiAtJGFzX2VjaG8g
IiRBUzg2IiA+JjY7IH0KPiArZmkKPiArYWNfY3RfT0NBTUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUwKPiAraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUwiID4mNQo+ICsk
YXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJu
byIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC1pZiB0ZXN0IHgiJHtBUzg2fSIgPT0geCJubyIKPiAt
dGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGFzODYsIHBsZWFzZSBp
bnN0YWxsIGFzODYiICIkTElORU5PIiA1Cj4gKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTCIgPSB4
OyB0aGVuCj4gKyAgICBPQ0FNTD0ibm8iCj4gKyAgZWxzZQo+ICsgICAgY2FzZSAkY3Jvc3NfY29t
cGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgo+ICt5ZXM6KQo+ICt7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Cj4gKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30K
PiArYWNfdG9vbF93YXJuZWQ9eWVzIDs7Cj4gK2VzYWMKPiArICAgIE9DQU1MPSRhY19jdF9PQ0FN
TAo+ICsgIGZpCj4gK2Vsc2UKPiArICBPQ0FNTD0iJGFjX2N2X3Byb2dfT0NBTUwiCj4gIGZpCj4g
LSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAibGQ4NiIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCj4gLXNldCBkdW1teSBsZDg2OyBhY193b3JkPSQyCj4gKwo+ICsK
PiArICAjIGNoZWNraW5nIGZvciBvY2FtbGRlcAo+ICsgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+
ICtzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGRlcDsgYWNfd29yZD0kMgo+ICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+
IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfTEQ4NitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJExEODYgaW4KPiAtICBbXFwv
XSogfCA/OltcXC9dKikKPiAtICBhY19jdl9wYXRoX0xEODY9IiRMRDg2IiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FN
TERFUCI7IHRoZW4KPiArICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0k
YXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9M
RDg2PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19PQ0FN
TERFUD0iJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTY2MTIsNDQgKzQzMTQsMzkgQEAgZG9u
ZQo+ICAgIGRvbmUKPiAgSUZTPSRhc19zYXZlX0lGUwo+IAo+IC0gIHRlc3QgLXogIiRhY19jdl9w
YXRoX0xEODYiICYmIGFjX2N2X3BhdGhfTEQ4Nj0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+
IC1MRDg2PSRhY19jdl9wYXRoX0xEODYKPiAtaWYgdGVzdCAtbiAiJExEODYiOyB0aGVuCj4gLSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRMRDg2IiA+
JjUKPiAtJGFzX2VjaG8gIiRMRDg2IiA+JjY7IH0KPiArZmkKPiArT0NBTUxERVA9JGFjX2N2X3By
b2dfT0NBTUxERVAKPiAraWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxERVAiID4mNQo+
ICskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KPiAgZWxzZQo+ICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gICRhc19lY2hvICJu
byIgPiY2OyB9Cj4gIGZpCj4gCj4gCj4gLWlmIHRlc3QgeCIke0xEODZ9IiA9PSB4Im5vIgo+IC10
aGVuCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGlu
c3RhbGwgbGQ4NiIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICJiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+IC1zZXQg
ZHVtbXkgYmNjOyBhY193b3JkPSQyCj4gK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MREVQ
IjsgdGhlbgo+ICsgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAo+ICsgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgo+ICtzZXQgZHVtbXkgb2NhbWxkZXA7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+
ICAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVz
dCAiJHthY19jdl9wYXRoX0JDQytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJEJDQyBpbgo+IC0gIFtcXC9dKiB8
ID86W1xcL10qKQo+IC0gIGFjX2N2X3BhdGhfQkNDPSIkQkNDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN
TERFUCI7IHRoZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxE
RVAiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBk
bwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAg
YWNfY3ZfcGF0aF9CQ0M9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19j
dl9wcm9nX2FjX2N0X09DQU1MREVQPSJvY2FtbGRlcCIKPiAgICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQo+ICAgICAgYnJlYWsgMgo+ICAgIGZpCj4gQEAgLTY2NTcsMjgzICs0MzU0LDI0MSBAQCBk
b25lCj4gICAgZG9uZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgdGVzdCAteiAiJGFjX2N2
X3BhdGhfQkNDIiAmJiBhY19jdl9wYXRoX0JDQz0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+
IC1CQ0M9JGFjX2N2X3BhdGhfQkNDCj4gLWlmIHRlc3QgLW4gIiRCQ0MiOyB0aGVuCj4gLSAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCQ0MiID4mNQo+
IC0kYXNfZWNobyAiJEJDQyIgPiY2OyB9Cj4gK2ZpCj4gK2FjX2N0X09DQU1MREVQPSRhY19jdl9w
cm9nX2FjX2N0X09DQU1MREVQCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4K
PiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N0X09DQU1MREVQIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9Cj4g
IGVsc2UKPiAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICAkYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0KPiAtaWYgdGVz
dCB4IiR7QkNDfSIgPT0geCJubyIKPiAtdGhlbgo+IC0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGJjYywgcGxlYXNlIGluc3RhbGwgYmNjIiAiJExJTkVOTyIgNQo+ICsgIGlmIHRl
c3QgIngkYWNfY3RfT0NBTUxERVAiID0geDsgdGhlbgo+ICsgICAgT0NBTUxERVA9Im5vIgo+ICsg
IGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAr
eWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+
ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtl
c2FjCj4gKyAgICBPQ0FNTERFUD0kYWNfY3RfT0NBTUxERVAKPiArICBmaQo+ICtlbHNlCj4gKyAg
T0NBTUxERVA9IiRhY19jdl9wcm9nX09DQU1MREVQIgo+ICBmaQo+IC0jIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImlhc2wiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgo+IC1zZXQgZHVtbXkgaWFzbDsgYWNfd29yZD0kMgo+ICsKPiArCj4gKyAgIyBjaGVja2luZyBm
b3Igb2NhbWxta3RvcAo+ICsgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KPiAr
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3Rv
cCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKPiAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICAk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9wYXRoX0lBU0wrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtpZiB0ZXN0ICIke2FjX2N2
X3Byb2dfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhc2UgJElBU0wgaW4KPiAtICBbXFwvXSogfCA/Oltc
XC9dKikKPiAtICBhY19jdl9wYXRoX0lBU0w9IiRJQVNMIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0gICopCj4gLSAgYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsg
dGhlbgo+ICsgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJE9DQU1MTUtUT1AiICMgTGV0IHRoZSB1
c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFzX2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNf
c2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9JQVNM
PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19PQ0FNTE1L
VE9QPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3AiCj4gICAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAtICBmaQo+IC1kb25lCj4gLSAgZG9uZQo+IC1JRlM9JGFz
X3NhdmVfSUZTCj4gLQo+IC0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0lBU0wiICYmIGFjX2N2X3Bh
dGhfSUFTTD0ibm8iCj4gLSAgOzsKPiAtZXNhYwo+IC1maQo+IC1JQVNMPSRhY19jdl9wYXRoX0lB
U0wKPiAtaWYgdGVzdCAtbiAiJElBU0wiOyB0aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJQVNMIiA+JjUKPiAtJGFzX2VjaG8gIiRJQVNM
IiA+JjY7IH0KPiAtZWxzZQo+IC0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gLSRhc19lY2hvICJubyIgPiY2OyB9Cj4gLWZpCj4gLQo+
IC0KPiAtaWYgdGVzdCB4IiR7SUFTTH0iID09IHgibm8iCj4gLXRoZW4KPiAtICAgIGFzX2ZuX2Vy
cm9yICQ/ICJVbmFibGUgdG8gZmluZCBpYXNsLCBwbGVhc2UgaW5zdGFsbCBpYXNsIiAiJExJTkVO
TyIgNQo+IC1maQo+IC0KPiAtYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIg
InV1aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiA9IHgiInllczsg
dGhlbiA6Cj4gLQo+IC0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAi
JHthY19jdl9saWJfdXVpZF91dWlkX2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUwo+IC1MSUJTPSItbHV1aWQgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4gLS8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+
IC0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKPiAtICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAt
I2VuZGlmCj4gLWNoYXIgdXVpZF9jbGVhciAoKTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1y
ZXR1cm4gdXVpZF9jbGVhciAoKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9G
Cj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9saWJf
dXVpZF91dWlkX2NsZWFyPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVh
cj1ubwo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKPiAtICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gLUxJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjUKPiAt
JGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KPiAtaWYgdGVzdCAi
eCRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgbGlidXVp
ZD0ieSIKPiAtZmkKPiAtCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiArSUZTPSRhc19zYXZl
X0lGUwo+IAo+ICBmaQo+IC0KPiAtCj4gLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRM
SU5FTk8iICJ1dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+
IC0gIGxpYnV1aWQ9InkiCj4gIGZpCj4gLQo+IC0KPiAtaWYgdGVzdCAiJGxpYnV1aWQiICE9ICJ5
IjsgdGhlbiA6Cj4gLQo+IC0gICAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGEgdmFsaWQg
dXVpZCBsaWJyYXJ5IiAiJExJTkVOTyIgNQo+IC0KPiArT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QCj4gK2lmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1
Cj4gKyRhc19lY2hvICIkT0NBTUxNS1RPUCIgPiY2OyB9Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNo
byAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+IC1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVs
ICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJfY3Vyc2VzX2giICIkYWNfaW5jbHVk
ZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfY3Vyc2VzX2giID0geCIieWVz
OyB0aGVuIDoKPiAtCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcy4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2Fj
X2N2X2xpYl9jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtmaQo+ICtpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgo+ICsgIGFjX2N0X09DQU1MTUtUT1A9
JE9DQU1MTUtUT1AKPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWt0b3Ai
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVtbXkgb2Nh
bWxta3RvcDsgYWNfd29yZD0kMgo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf
T0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKPiAgZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElCUz0i
LWxjdXJzZXMgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4gLS8qIE92ZXJyaWRlIGFueSBH
Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIg
Y2xlYXIgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0dXJuIGNsZWFyICgpOwo+IC0g
IDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2xpYl9jdXJzZXNfY2xlYXI9eWVzCj4gKyAgaWYg
dGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE1LVE9QPSIkYWNfY3RfT0NBTUxNS1RPUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gIGVsc2UKPiAtICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPW5vCj4gK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtk
bwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9wIgo+ICsgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiAr
SUZTPSRhc19zYXZlX0lGUwo+ICsKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2N1cnNlc19j
bGVhciIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPiY2OyB9Cj4g
LWlmIHRlc3QgIngkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0g
IGN1cnNlcz0ieSIKPiArYWNfY3RfT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1L
VE9QCj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgo+ICsgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxNS1RP
UCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxNS1RPUCIgPiY2OyB9Cj4gIGVsc2UKPiAt
ICBjdXJzZXM9Im4iCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtCj4g
KyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KPiArICAgIE9DQU1MTUtU
T1A9Im5vIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93
YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29s
cyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4gK2FjX3Rvb2xfd2FybmVk
PXllcyA7Owo+ICtlc2FjCj4gKyAgICBPQ0FNTE1LVE9QPSRhY19jdF9PQ0FNTE1LVE9QCj4gKyAg
ZmkKPiAgZWxzZQo+IC0gIGN1cnNlcz0ibiIKPiArICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19P
Q0FNTE1LVE9QIgo+ICBmaQo+IAo+IAo+IC1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIk
TElORU5PIiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRl
c19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giID0geCIieWVz
OyB0aGVuIDoKPiAtCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7
YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICMgY2hlY2tp
bmcgZm9yIG9jYW1sbWtsaWIKPiArICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVu
Cj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
bWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgo+ICtzZXQgZHVt
bXkgJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliOyBhY193b3JkPSQyCj4gK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK
PiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUwo+IC1MSUJTPSItbG5jdXJzZXMgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtCj4g
LS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9y
Lgo+IC0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUg
b2YgYSBHQ0MKPiAtICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4gLWV4dGVybiAiQyIK
PiAtI2VuZGlmCj4gLWNoYXIgY2xlYXIgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0
dXJuIGNsZWFyICgpOwo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2xpYl9uY3Vyc2Vz
X2NsZWFyPXllcwo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgo+ICsgIGFjX2N2
X3Byb2dfT0NBTUxNS0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo
ZSB0ZXN0Lgo+ICBlbHNlCj4gLSAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9bm8KPiArYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICtmb3IgYXNfZGlyIGluICRQQVRICj4g
K2RvCj4gKyAgSUZTPSRhc19zYXZlX0lGUwo+ICsgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCj4gKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KPiArICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gKyAg
ICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKPiAr
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUK
PiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiArCj4gIGZpCj4gLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0
IGNvbmZ0ZXN0LiRhY19leHQKPiAtTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICBmaQo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9saWJfbmN1cnNlc19j
bGVhciIgPiY2OyB9Cj4gLWlmIHRlc3QgIngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIi
eWVzOyB0aGVuIDoKPiAtICBuY3Vyc2VzPSJ5Igo+ICtPQ0FNTE1LTElCPSRhY19jdl9wcm9nX09D
QU1MTUtMSUIKPiAraWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LTElCIiA+JjUK
PiArJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KPiAgZWxzZQo+IC0gIG5jdXJzZXM9Im4i
Cj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAKPiAtZWxzZQo+IC0gIG5j
dXJzZXM9Im4iCj4gIGZpCj4gLQo+IC0KPiAtaWYgdGVzdCAiJGN1cnNlcyIgPSAibiIgJiYgdGVz
dCAiJG5jdXJzZXMiID0gIm4iOyB0aGVuIDoKPiAtCj4gLSAgICBhc19mbl9lcnJvciAkPyAiVW5h
YmxlIHRvIGZpbmQgYSBzdWl0YWJsZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5FTk8iIDUKPiAraWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRoZW4KPiArICBhY19jdF9PQ0FNTE1L
TElCPSRPQ0FNTE1LTElCCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG1r
bGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15
IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj
X2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRo
ZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9PQ0FNTE1LTElCIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KPiArZWxzZQo+ICthc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiAr
ICBJRlM9JGFzX3NhdmVfSUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiAr
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+
ICsgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKPiArICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0k
YXNfc2F2ZV9JRlMKPiAKPiAgZmkKPiAtIyBQcmVmZXIgbmN1cnNlcyBvdmVyIGN1cnNlcyBpZiBi
b3RoIGFyZSBwcmVzZW50Cj4gLWlmIHRlc3QgIiRuY3Vyc2VzIiA9ICJ5IjsgdGhlbiA6Cj4gLQo+
IC0gICAgQ1VSU0VTX0xJQlM9Ii1sbmN1cnNlcyIKPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIElO
Q0xVREVfQ1VSU0VTX0ggPG5jdXJzZXMuaD4iID4+Y29uZmRlZnMuaAo+IC0KPiAtCj4gK2ZpCj4g
K2FjX2N0X09DQU1MTUtMSUI9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQgo+ICtpZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQo+ICskYXNf
ZWNobyAiJGFjX2N0X09DQU1MTUtMSUIiID4mNjsgfQo+ICBlbHNlCj4gLQo+IC0gICAgQ1VSU0VT
X0xJQlM9Ii1sY3Vyc2VzIgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgSU5DTFVERV9DVVJTRVNf
SCA8Y3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKPiAtCj4gLQo+ICsgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19lY2hvICJubyIg
PiY2OyB9Cj4gIGZpCj4gCj4gKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LTElCIiA9IHg7IHRo
ZW4KPiArICAgIE9DQU1MTUtMSUI9Im5vIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2Nv
bXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9
Cj4gK2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtlc2FjCj4gKyAgICBPQ0FNTE1LTElCPSRhY19j
dF9PQ0FNTE1LTElCCj4gKyAgZmkKPiArZWxzZQo+ICsgIE9DQU1MTUtMSUI9IiRhY19jdl9wcm9n
X09DQU1MTUtMSUIiCj4gK2ZpCj4gCj4gCj4gLQo+IC0KPiAtCj4gLQo+IC0KPiAtaWYgdGVzdCAi
eCRhY19jdl9lbnZfUEtHX0NPTkZJR19zZXQiICE9ICJ4c2V0IjsgdGhlbgo+IC0gICAgICAgaWYg
dGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+IC0gICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAiJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KPiAtc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9cGtnLWNv
bmZpZzsgYWNfd29yZD0kMgo+ICsgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCj4gKyAgaWYgdGVz
dCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0g
bmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBh
Y193b3JkPSQyCj4gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiAgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9QS0dfQ09ORklHK3NldH0i
ID0gc2V0OyB0aGVuIDoKPiAraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MRE9DK3NldH0iID0g
c2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAg
Y2FzZSAkUEtHX0NPTkZJRyBpbgo+IC0gIFtcXC9dKiB8ID86W1xcL10qKQo+IC0gIGFjX2N2X3Bh
dGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgo+IC0gIDs7Cj4gLSAgKikKPiAtICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCj4gKyAgaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgo+ICsg
IGFjX2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCj4gK2Vsc2UKPiArYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
Ugo+ICBmb3IgYXNfZGlyIGluICRQQVRICj4gIGRvCj4gICAgSUZTPSRhc19zYXZlX0lGUwo+ICAg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gICAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiAgICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCj4gLSAgICBhY19jdl9wYXRoX1BLR19DT05GSUc9IiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICBhY19jdl9wcm9nX09DQU1MRE9DPSIke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sZG9jIgo+ICAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gICAg
ICBicmVhayAyCj4gICAgZmkKPiBAQCAtNjk0MSwxMyArNDU5NiwxMiBAQCBkb25lCj4gICAgZG9u
ZQo+ICBJRlM9JGFzX3NhdmVfSUZTCj4gCj4gLSAgOzsKPiAtZXNhYwo+ICBmaQo+IC1QS0dfQ09O
RklHPSRhY19jdl9wYXRoX1BLR19DT05GSUcKPiAtaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0
aGVuCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRQS0dfQ09ORklHIiA+JjUKPiAtJGFzX2VjaG8gIiRQS0dfQ09ORklHIiA+JjY7IH0KPiArZmkK
PiArT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKPiAraWYgdGVzdCAtbiAiJE9DQU1MRE9D
IjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkT0NBTUxET0MiID4mNQo+ICskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KPiAgZWxz
ZQo+ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gICRhc19lY2hvICJubyIgPiY2OyB9Cj4gQEAgLTY5NTUsMjggKzQ2MDksMjYgQEAg
ZmkKPiAKPiAKPiAgZmkKPiAtaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRo
ZW4KPiAtICBhY19wdF9QS0dfQ09ORklHPSRQS0dfQ09ORklHCj4gLSAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJwa2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KPiAtc2V0IGR1bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKPiAraWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfT0NBTUxET0MiOyB0aGVuCj4gKyAgYWNfY3RfT0NBTUxET0M9JE9DQU1M
RE9DCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGRvYyIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBvY2FtbGRvYzsgYWNf
d29yZD0kMgo+ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfYWNfcHRfUEtHX0NPTkZJRytz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERP
QytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAg
ZWxzZQo+IC0gIGNhc2UgJGFjX3B0X1BLR19DT05GSUcgaW4KPiAtICBbXFwvXSogfCA/OltcXC9d
KikKPiAtICBhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUc9IiRhY19wdF9QS0dfQ09ORklHIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KPiAtICA7Owo+IC0g
ICopCj4gLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgo+ICsgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRoZW4KPiArICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
RE9DPSIkYWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgo+
ICtlbHNlCj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiAgZm9yIGFz
X2RpciBpbiAkUEFUSAo+ICBkbwo+ICAgIElGUz0kYXNfc2F2ZV9JRlMKPiAgICB0ZXN0IC16ICIk
YXNfZGlyIiAmJiBhc19kaXI9Lgo+ICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj
dXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgo+IC0gICAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0ib2Nh
bWxkb2MiCj4gICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiAgICAgIGJyZWFrIDIKPiAgICBm
aQo+IEBAIC02OTg0LDIwICs0NjM2LDE5IEBAIGRvbmUKPiAgICBkb25lCj4gIElGUz0kYXNfc2F2
ZV9JRlMKPiAKPiAtICA7Owo+IC1lc2FjCj4gIGZpCj4gLWFjX3B0X1BLR19DT05GSUc9JGFjX2N2
X3BhdGhfYWNfcHRfUEtHX0NPTkZJRwo+IC1pZiB0ZXN0IC1uICIkYWNfcHRfUEtHX0NPTkZJRyI7
IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX3B0X1BLR19DT05GSUciID4mNQo+IC0kYXNfZWNobyAiJGFjX3B0X1BLR19DT05GSUci
ID4mNjsgfQo+ICtmaQo+ICthY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERP
Qwo+ICtpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERPQyIgPiY1
Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQo+ICBlbHNlCj4gICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAgJGFz
X2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAKPiAtICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05G
SUciID0geDsgdGhlbgo+IC0gICAgUEtHX0NPTkZJRz0iIgo+ICsgIGlmIHRlc3QgIngkYWNfY3Rf
T0NBTUxET0MiID0geDsgdGhlbgo+ICsgICAgT0NBTUxET0M9Im5vIgo+ICAgIGVsc2UKPiAgICAg
IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAgeWVzOikKPiBAQCAt
NzAwNSw2MjQgKzQ2NTYsNzE4IEBAIHllczopCj4gICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30K
PiAgYWNfdG9vbF93YXJuZWQ9eWVzIDs7Cj4gIGVzYWMKPiAtICAgIFBLR19DT05GSUc9JGFjX3B0
X1BLR19DT05GSUcKPiArICAgIE9DQU1MRE9DPSRhY19jdF9PQ0FNTERPQwo+ICAgIGZpCj4gIGVs
c2UKPiAtICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgo+IC1maQo+IC0KPiAt
ZmkKPiAtaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCj4gLSAgICAgICBfcGtnX21pbl92
ZXJzaW9uPTAuOS4wCj4gLSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQgbGVhc3QgdmVyc2lvbiAkX3BrZ19taW5f
dmVyc2lvbiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQgbGVh
c3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbi4uLiAiID4mNjsgfQo+IC0gICAgICAgaWYgJFBL
R19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uOyB0
aGVuCj4gLSAgICAgICAgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQo+IC0kYXNfZWNobyAieWVzIiA+JjY7IH0KPiAtICAgICAg
IGVsc2UKPiAtICAgICAgICAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtICAgICAg
ICAgICAgICAgUEtHX0NPTkZJRz0iIgo+IC0gICAgICAgZmkKPiAtZmkKPiAtCj4gLXBrZ19mYWls
ZWQ9bm8KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgZ2xpYiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBnbGliLi4uICIgPiY2
OyB9Cj4gLQo+IC1pZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0aGVuCj4gLSAgICBwa2dfY3Zf
Z2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIKPiAtIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUci
OyB0aGVuCj4gLSAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIgJiYgXAo+IC0gICAgeyB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkUEtHX0NPTkZJRyAtLWV4aXN0
cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9ID4mNQo+IC0gICgkUEtHX0NPTkZJRyAt
LWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1Cj4gLSAgYWNfc3RhdHVzPSQ/
Cj4gLSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0
YXR1cyIgPiY1Cj4gLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgo+IC0gIHBrZ19jdl9n
bGliX0NGTEFHUz1gJFBLR19DT05GSUcgLS1jZmxhZ3MgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAK
PiAtZWxzZQo+IC0gIHBrZ19mYWlsZWQ9eWVzCj4gLWZpCj4gLSBlbHNlCj4gLSAgICBwa2dfZmFp
bGVkPXVudHJpZWQKPiAtZmkKPiAtaWYgdGVzdCAtbiAiJGdsaWJfTElCUyI7IHRoZW4KPiAtICAg
IHBrZ19jdl9nbGliX0xJQlM9IiRnbGliX0xJQlMiCj4gLSBlbGlmIHRlc3QgLW4gIiRQS0dfQ09O
RklHIjsgdGhlbgo+IC0gICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwKPiAtICAgIHsg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1l
eGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGliLTIuMFwiIjsgfSA+JjUKPiAtICAoJFBLR19DT05G
SUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIikgMj4mNQo+IC0gIGFjX3N0YXR1
cz0kPwo+IC0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh
Y19zdGF0dXMiID4mNQo+IC0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4KPiAtICBwa2df
Y3ZfZ2xpYl9MSUJTPWAkUEtHX0NPTkZJRyAtLWxpYnMgImdsaWItMi4wIiAyPi9kZXYvbnVsbGAK
PiAtZWxzZQo+IC0gIHBrZ19mYWlsZWQ9eWVzCj4gLWZpCj4gLSBlbHNlCj4gLSAgICBwa2dfZmFp
bGVkPXVudHJpZWQKPiAtZmkKPiAtCj4gLQo+IC0KPiAtaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHll
czsgdGhlbgo+IC0gICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKPiAtJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAtCj4gLWlmICRQS0df
Q09ORklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAwLjIwOyB0aGVuCj4gLSAgICAgICAg
X3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkPXllcwo+IC1lbHNlCj4gLSAgICAgICAgX3BrZ19z
aG9ydF9lcnJvcnNfc3VwcG9ydGVkPW5vCj4gKyAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1M
RE9DIgo+ICBmaQo+IC0gICAgICAgIGlmIHRlc3QgJF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRl
ZCA9IHllczsgdGhlbgo+IC0gICAgICAgICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09O
RklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKPiAtICAg
ICAgICBlbHNlCj4gLSAgICAgICAgICAgICAgIGdsaWJfUEtHX0VSUk9SUz1gJFBLR19DT05GSUcg
LS1wcmludC1lcnJvcnMgImdsaWItMi4wIiAyPiYxYAo+IC0gICAgICAgIGZpCj4gLSAgICAgICAj
IFB1dCB0aGUgbmFzdHkgZXJyb3IgbWVzc2FnZSBpbiBjb25maWcubG9nIHdoZXJlIGl0IGJlbG9u
Z3MKPiAtICAgICAgIGVjaG8gIiRnbGliX1BLR19FUlJPUlMiID4mNQo+IC0KPiAtICAgICAgIGFz
X2ZuX2Vycm9yICQ/ICJQYWNrYWdlIHJlcXVpcmVtZW50cyAoZ2xpYi0yLjApIHdlcmUgbm90IG1l
dDoKPiAtCj4gLSRnbGliX1BLR19FUlJPUlMKPiAtCj4gLUNvbnNpZGVyIGFkanVzdGluZyB0aGUg
UEtHX0NPTkZJR19QQVRIIGVudmlyb25tZW50IHZhcmlhYmxlIGlmIHlvdQo+IC1pbnN0YWxsZWQg
c29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJlZml4Lgo+IC0KPiAtQWx0ZXJuYXRpdmVseSwg
eW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyBnbGliX0NGTEFHUwo+IC1hbmQg
Z2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KPiAtU2VlIHRo
ZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuIiAiJExJTkVOTyIgNQo+IC1l
bGlmIHRlc3QgJHBrZ19mYWlsZWQgPSB1bnRyaWVkOyB0aGVuCj4gLSAgICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+IC0kYXNfZWNo
byAibm8iID4mNjsgfQo+IC0gICAgICAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1Cj4gLSRhc19lY2hvICIkYXNfbWU6
IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KPiAtYXNfZm5fZXJyb3IgJD8gIlRoZSBwa2ct
Y29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3Vy
ZSBpdAo+IC1pcyBpbiB5b3VyIFBBVEggb3Igc2V0IHRoZSBQS0dfQ09ORklHIGVudmlyb25tZW50
IHZhcmlhYmxlIHRvIHRoZSBmdWxsCj4gLXBhdGggdG8gcGtnLWNvbmZpZy4KPiAKPiAtQWx0ZXJu
YXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyBnbGliX0NGTEFH
Uwo+IC1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4K
PiAtU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZvciBtb3JlIGRldGFpbHMuCj4gCj4gLVRv
IGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+
Lgo+IC1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0K
PiArICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCj4gKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xf
cHJlZml4IjsgdGhlbgo+ICsgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1vY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiArc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgo+
ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhl
biA6Cj4gKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gICAgICAgZ2xp
Yl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUwo+IC0gICAgICAgZ2xpYl9MSUJTPSRwa2dfY3Zf
Z2xpYl9MSUJTCj4gLSAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IHllcyIgPiY1Cj4gLSRhc19lY2hvICJ5ZXMiID4mNjsgfQo+IC0KPiAtZmkK
PiAtCj4gLSMgQ2hlY2sgbGlicmFyeSBwYXRoCj4gLWlmIHRlc3QgIlwke2V4ZWNfcHJlZml4fS9s
aWIiID0gIiRsaWJkaXIiOyB0aGVuIDoKPiAtICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0gIk5P
TkUiICYmIHRlc3QgIiRwcmVmaXgiICE9ICJOT05FIjsgdGhlbiA6Cj4gLSAgZXhlY19wcmVmaXg9
JHByZWZpeAo+IC1maQo+IC0gICAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIjsgdGhl
biA6Cj4gLSAgZXhlY19wcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4Cj4gLWZpCj4gLSAgICBpZiB0
ZXN0IC1kICIke2V4ZWNfcHJlZml4fS9saWI2NCI7IHRoZW4gOgo+IC0KPiAtICAgICAgICBMSUJf
UEFUSD0ibGliNjQiCj4gLQo+ICsgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgo+ICsg
IGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJE9DQU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJy
aWRlIHRoZSB0ZXN0Lgo+ICBlbHNlCj4gLQo+IC0gICAgICAgIExJQl9QQVRIPSJsaWIiCj4gK2Fz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFU
SAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+
ICsgICAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQi
Cj4gKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKPiArICAgIGJyZWFrIDIKPiArICBmaQo+ICtk
b25lCj4gKyAgZG9uZQo+ICtJRlM9JGFzX3NhdmVfSUZTCj4gCj4gIGZpCj4gLQo+IC1lbHNlCj4g
LQo+IC0gICAgTElCX1BBVEg9IiR7bGliZGlyOmBleHByIGxlbmd0aCAiJGV4ZWNfcHJlZml4IiAr
IDFgfSIKPiAtCj4gIGZpCj4gLQo+IC0KPiAtIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KPiAtYWNf
Zm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImJ6bGliLmgiICJhY19jdl9oZWFk
ZXJfYnpsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hl
YWRlcl9iemxpYl9oIiA9IHgiInllczsgdGhlbiA6Cj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBCWjJfYnpEZWNvbXByZXNzSW5pdCBp
biAtbGJ6MiIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBCWjJfYnpEZWNvbXByZXNz
SW5pdCBpbiAtbGJ6Mi4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2xpYl9iejJfQloy
X2J6RGVjb21wcmVzc0luaXQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4g
LUxJQlM9Ii1sYnoyICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC0vKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNo
YXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gLSNlbmRpZgo+IC1j
aGFyIEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJl
dHVybiBCWjJfYnpEZWNvbXByZXNzSW5pdCAoKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0K
PiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBh
Y19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0PXllcwo+ICtPQ0FNTEJVSUxEPSRhY19j
dl9wcm9nX09DQU1MQlVJTEQKPiAraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCj4gKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTEJV
SUxEIiA+JjUKPiArJGFzX2VjaG8gIiRPQ0FNTEJVSUxEIiA+JjY7IH0KPiAgZWxzZQo+IC0gIGFj
X2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVl
eHQgY29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gLWZp
Cj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3Zf
bGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY2OyB9Cj4gLWlmIHRlc3QgIngkYWNfY3Zf
bGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHpsaWI9
IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+
ICBmaQo+IAo+IAo+ICBmaQo+IC0KPiAtCj4gLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwg
IiRMSU5FTk8iICJsem1hLmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2x6bWFfaCIgPSB4IiJ5ZXM7IHRoZW4g
Ogo+IC0KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KPiAt
aWYgdGVzdCAiJHthY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyK3NldH0iID0gc2V0
OyB0aGVuIDoKPiAraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCI7IHRoZW4KPiAr
ICBhY19jdF9PQ0FNTEJVSUxEPSRPQ0FNTEJVSUxECj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiArc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICsk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAi
JHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCj4gLUxJQlM9Ii1sbHptYSAgJExJQlMiCj4gLWNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAt
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Cj4gLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQwo+IC0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLwo+IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+
IC0jZW5kaWYKPiAtY2hhciBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwo+IC1pbnQKPiAtbWFpbiAo
KQo+IC17Cj4gLXJldHVybiBsem1hX3N0cmVhbV9kZWNvZGVyICgpOwo+IC0gIDsKPiAtICByZXR1
cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgo+IC0gIGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXI9eWVzCj4gKyAgaWYg
dGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCj4gKyAgYWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTEJVSUxEPSIkYWNfY3RfT0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCj4gIGVsc2UKPiAtICBhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyPW5v
Cj4gK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBp
biAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgo+ICsgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgo+ICsg
ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+
ICsgIGRvbmUKPiArSUZTPSRhc19zYXZlX0lGUwo+ICsKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gIGZpCj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGli
X2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPiY2OyB9Cj4gLWlmIHRlc3QgIngkYWNfY3ZfbGli
X2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHpsaWI9IiR6
bGliIC1ESEFWRV9MWk1BIC1sbHptYSIKPiArYWNfY3RfT0NBTUxCVUlMRD0kYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTEJVSUxECj4gK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgo+
ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxCVUlMRCIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3RfT0NBTUxCVUlMRCIgPiY2OyB9
Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IC0KPiArICBp
ZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQlVJTEQiID0geDsgdGhlbgo+ICsgICAgT0NBTUxCVUlMRD0i
bm8iCj4gKyAgZWxzZQo+ICsgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgo+ICt5ZXM6KQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxl
dCIgPiY1Cj4gKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KPiArYWNfdG9vbF93YXJuZWQ9eWVz
IDs7Cj4gK2VzYWMKPiArICAgIE9DQU1MQlVJTEQ9JGFjX2N0X09DQU1MQlVJTEQKPiArICBmaQo+
ICtlbHNlCj4gKyAgT0NBTUxCVUlMRD0iJGFjX2N2X3Byb2dfT0NBTUxCVUlMRCIKPiAgZmkKPiAK
PiAKPiAtYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgImx6by9sem8xeC5o
IiAiYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlm
IHRlc3QgIngkYWNfY3ZfaGVhZGVyX2x6b19sem8xeF9oIiA9IHgiInllczsgdGhlbiA6Cj4gKyAg
ICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6Cj4gCj4gLXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3Mg
aW4gLWxsem8yIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJl
c3MgaW4gLWxsem8yLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bzJfbHpv
MXhfZGVjb21wcmVzcytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElC
Uz0iLWxsem8yICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gKyAgICAgICAgaWYgdGVzdCAieCRl
bmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgo+IAo+IC0vKiBPdmVycmlkZSBhbnkg
R0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNoYXIg
YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAgIGJ1
aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g
ICovCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gLSNlbmRpZgo+IC1jaGFy
IGx6bzF4X2RlY29tcHJlc3MgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0dXJuIGx6
bzF4X2RlY29tcHJlc3MgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+
IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX2x6
bzJfbHpvMXhfZGVjb21wcmVzcz15ZXMKPiAtZWxzZQo+IC0gIGFjX2N2X2xpYl9sem8yX2x6bzF4
X2RlY29tcHJlc3M9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+
IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gKyAgICAgICAgICAgIGFzX2ZuX2Vycm9y
ICQ/ICJPY2FtbCB0b29scyBlbmFibGVkLCBidXQgdW5hYmxlIHRvIGZpbmQgT2NhbWwiICIkTElO
RU5PIiA1Cj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY2OyB9Cj4gLWlmIHRlc3QgIngk
YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHps
aWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCj4gKyAgICAgICAgb2NhbWx0b29scz0ibiIK
PiArCj4gIGZpCj4gCj4gK2ZpCj4gKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmFzaCIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCj4gK3NldCBkdW1teSBiYXNo
OyBhY193b3JkPSQyCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh
Y193b3JkLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0g
c2V0OyB0aGVuIDoKPiArICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICtlbHNlCj4gKyAg
Y2FzZSAkQkFTSCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2X3BhdGhfQkFT
SD0iJEJBU0giICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgo+
ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S
Cj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiArICBJRlM9JGFzX3NhdmVfSUZTCj4gKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiArICAgIGZvciBhY19leGVjX2V4dCBpbiAn
JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICsgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2X3BhdGhfQkFTSD0iJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJl
YWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiAKPiAr
ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9Im5vIgo+ICsg
IDs7Cj4gK2VzYWMKPiArZmkKPiArQkFTSD0kYWNfY3ZfcGF0aF9CQVNICj4gK2lmIHRlc3QgLW4g
IiRCQVNIIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQkFTSCIgPiY1Cj4gKyRhc19lY2hvICIkQkFTSCIgPiY2OyB9Cj4gK2Vsc2UK
PiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IAo+IAo+ICtpZiB0ZXN0IHgiJHtC
QVNIfSIgPT0geCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBm
aW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2giICIkTElORU5PIiA1Cj4gK2ZpCj4gCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3Nl
dHVwIGluIC1sYWlvIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGlvX3NldHVwIGlu
IC1sYWlvLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2Fpb19pb19zZXR1cCtz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2FjX2V4dD1jCj4gK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1Mn
Cj4gK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0
ID4mNScKPiArYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBG
TEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKPiArYWNfY29tcGlsZXJf
Z251PSRhY19jdl9jX2NvbXBpbGVyX2dudQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUK
PiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IuLi4g
IiA+JjY7IH0KPiArIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1lcyBhIGRpcmVjdG9yeS4K
PiAraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KPiArICBDUFA9Cj4g
K2ZpCj4gK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCj4gKyAgaWYgdGVzdCAiJHthY19jdl9wcm9n
X0NQUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
PiAgZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWxhaW8g
ICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4g
KyAgICAgICMgRG91YmxlIHF1b3RlcyBiZWNhdXNlIENQUCBuZWVkcyB0byBiZSBleHBhbmRlZAo+
ICsgICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRpb25hbC1jcHAiICIvbGli
L2NwcCIKPiArICAgIGRvCj4gKyAgICAgIGFjX3ByZXByb2Nfb2s9ZmFsc2UKPiArZm9yIGFjX2Nf
cHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCj4gK2RvCj4gKyAgIyBVc2UgYSBoZWFkZXIgZmls
ZSB0aGF0IGNvbWVzIHdpdGggZ2NjLCBzbyBjb25maWd1cmluZyBnbGliYwo+ICsgICMgd2l0aCBh
IGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgo+ICsgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8g
PGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQo+ICsgICMgPGxpbWl0cy5o
PiBleGlzdHMgZXZlbiBvbiBmcmVlc3RhbmRpbmcgY29tcGlsZXJzLgo+ICsgICMgT24gdGhlIE5l
WFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCj4g
KyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRj
aCB0aGlzIGNhc2UuCj4gKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAo+ICAvKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLQo+IC0vKiBPdmVycmlkZSBhbnkgR0ND
IGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNoYXIgYmVj
YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
Cj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gKyNpZmRlZiBfX1NURENfXwo+
ICsjIGluY2x1ZGUgPGxpbWl0cy5oPgo+ICsjZWxzZQo+ICsjIGluY2x1ZGUgPGFzc2VydC5oPgo+
ICAjZW5kaWYKPiAtY2hhciBpb19zZXR1cCAoKTsKPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1y
ZXR1cm4gaW9fc2V0dXAgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gKyAgICAgICAg
ICAgICAgICAgICAgU3ludGF4IGVycm9yCj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5r
ICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15ZXMKPiAraWYg
YWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6Cj4gKwo+ICBlbHNlCj4gLSAgYWNfY3Zf
bGliX2Fpb19pb19zZXR1cD1ubwo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKPiAtICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf
ZXh0Cj4gLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKPiArICAjIEJyb2tlbjogZmFpbHMg
b24gdmFsaWQgaW5wdXQuCj4gK2NvbnRpbnVlCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY1
Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9Cj4gLWlmIHRlc3Qg
IngkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIHN5c3RlbV9h
aW89InkiCj4gK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQK
PiArCj4gKyAgIyBPSywgd29ya3Mgb24gc2FuZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5v
bmV4aXN0ZW50IGhlYWRlcnMKPiArICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93Lgo+ICsgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArLyogZW5kIGNvbmZk
ZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KPiArX0FDRU9GCj4gK2lm
IGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+ICsgICMgQnJva2VuOiBzdWNjZXNz
IG9uIGludmFsaWQgaW5wdXQuCj4gK2NvbnRpbnVlCj4gIGVsc2UKPiAtICBzeXN0ZW1fYWlvPSJu
Igo+ICsgICMgUGFzc2VzIGJvdGggdGVzdHMuCj4gK2FjX3ByZXByb2Nfb2s9Ogo+ICticmVhawo+
ICtmaQo+ICtybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Cj4g
Kwo+ICtkb25lCj4gKyMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBj
bGVhbmluZyBjb2RlIHdhcyBza2lwcGVkLgo+ICtybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfZXh0Cj4gK2lmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKPiArICBicmVh
awo+ICBmaQo+IAo+ICsgICAgZG9uZQo+ICsgICAgYWNfY3ZfcHJvZ19DUFA9JENQUAo+IAo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBNRDUg
aW4gLWxjcnlwdG8iID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5
cHRvLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gK2ZpCj4gKyAg
Q1BQPSRhY19jdl9wcm9nX0NQUAo+ICBlbHNlCj4gLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k
TElCUwo+IC1MSUJTPSItbGNyeXB0byAgJExJQlMiCj4gLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArICBhY19jdl9wcm9nX0NQUD0kQ1BQCj4gK2ZpCj4gK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1BQIiA+JjUK
PiArJGFzX2VjaG8gIiRDUFAiID4mNjsgfQo+ICthY19wcmVwcm9jX29rPWZhbHNlCj4gK2ZvciBh
Y19jX3ByZXByb2Nfd2Fybl9mbGFnIGluICcnIHllcwo+ICtkbwo+ICsgICMgVXNlIGEgaGVhZGVy
IGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKPiArICAjIHdp
dGggYSBmcmVzaCBjcm9zcy1jb21waWxlciB3b3Jrcy4KPiArICAjIFByZWZlciA8bGltaXRzLmg+
IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKPiArICAjIDxsaW1p
dHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KPiArICAjIE9uIHRo
ZSBOZVhULCBjYyAtRSBydW5zIHRoZSBjb2RlIHRocm91Z2ggdGhlIGNvbXBpbGVyJ3MgcGFyc2Vy
LAo+ICsgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8g
Y2F0Y2ggdGhpcyBjYXNlLgo+ICsgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0KPiAtLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gLSAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+IC0gICBi
dWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHku
ICAqLwo+IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+ICsjaWZkZWYgX19TVERD
X18KPiArIyBpbmNsdWRlIDxsaW1pdHMuaD4KPiArI2Vsc2UKPiArIyBpbmNsdWRlIDxhc3NlcnQu
aD4KPiAgI2VuZGlmCj4gLWNoYXIgTUQ1ICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJl
dHVybiBNRDUgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gKyAgICAgICAgICAgICAg
ICAgICAgU3ludGF4IGVycm9yCj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCj4gK2lmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgo+ICsKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9jcnlw
dG9fTUQ1PW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtTElC
Uz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICsgICMgQnJva2VuOiBmYWlscyBvbiB2YWxpZCBp
bnB1dC4KPiArY29udGludWUKPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9j
cnlwdG9fTUQ1IiA9IHgiInllczsgdGhlbiA6Cj4gLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
Rgo+IC0jZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKPiArcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAo+ICsKPiArICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2Vz
LiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwo+ICsgICMgY2FuIGJlIGRl
dGVjdGVkIGFuZCBob3cuCj4gKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICovCj4gKyNpbmNsdWRlIDxhY19ub25leGlz
dGVudC5oPgo+ICBfQUNFT0YKPiAraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6
Cj4gKyAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KPiArY29udGludWUKPiAr
ZWxzZQo+ICsgICMgUGFzc2VzIGJvdGggdGVzdHMuCj4gK2FjX3ByZXByb2Nfb2s9Ogo+ICticmVh
awo+ICtmaQo+ICtybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0
Cj4gCj4gLSAgTElCUz0iLWxjcnlwdG8gJExJQlMiCj4gK2RvbmUKPiArIyBCZWNhdXNlIG9mIGBi
cmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCj4g
K3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKPiAraWYgJGFj
X3ByZXByb2Nfb2s7IHRoZW4gOgo+IAo+ICBlbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxk
IG5vdCBmaW5kIGxpYmNyeXB0byIgIiRMSU5FTk8iIDUKPiArICB7IHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiArJGFz
X2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+ICthc19mbl9lcnJv
ciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMgc2FuaXR5IGNoZWNrCj4gK1NlZSBc
YGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQo+ICBmaQo+IAo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBl
eHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Ig
ZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3Zf
bGliX2V4dDJmc19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICthY19leHQ9Ywo+
ICthY19jcHA9JyRDUFAgJENQUEZMQUdTJwo+ICthY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAk
Q1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCj4gK2FjX2xpbms9JyRDQyAtbyBjb25mdGVz
dCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAk
TElCUyA+JjUnCj4gK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKPiArCj4g
Kwo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZSIgPiY1Cj4gKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZS4uLiAiID4m
NjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3BhdGhfR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWxleHQyZnMgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
PiArICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4KPiArICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFs
c2UKPiArICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2gg
b2YgUFJPR05BTUUtTElTVAo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KPiAr
ZG8KPiArICBJRlM9JGFzX3NhdmVfSUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KPiArICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dyZXA7IGRvCj4gKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiArICAgICAgYWNfcGF0
aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0Igo+ICsgICAgICB7IHRlc3QgLWYg
IiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0dSRVAiOyB9IHx8IGNvbnRp
bnVlCj4gKyMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBp
cyBmb3VuZC4KPiArICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAo+ICtjYXNlIGAiJGFj
X3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCj4gKypHTlUqKQo+ICsgIGFjX2N2X3BhdGhf
R1JFUD0iJGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7Owo+ICsqKQo+ICsgIGFj
X2NvdW50PTAKPiArICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKPiArICB3
aGlsZSA6Cj4gKyAgZG8KPiArICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJj
b25mdGVzdC50bXAiCj4gKyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCj4gKyAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKPiArICAgICRhc19lY2hvICdHUkVQJyA+
PiAiY29uZnRlc3QubmwiCj4gKyAgICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShj
YW5ub3QgbWF0Y2gpLScgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVs
bCB8fCBicmVhawo+ICsgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2
L251bGwgMj4mMSB8fCBicmVhawo+ICsgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBh
Y19jb3VudD0kYXNfdmFsCj4gKyAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dS
RVBfbWF4LTB9OyB0aGVuCj4gKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBr
ZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQo+ICsgICAgICBhY19jdl9wYXRoX0dSRVA9IiRh
Y19wYXRoX0dSRVAiCj4gKyAgICAgIGFjX3BhdGhfR1JFUF9tYXg9JGFjX2NvdW50Cj4gKyAgICBm
aQo+ICsgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3Vn
aAo+ICsgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCj4gKyAgZG9uZQo+ICsgIHJt
IC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7Owo+
ICtlc2FjCj4gCj4gLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2
b2lkIGFuIGVycm9yLgo+IC0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUg
cmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAtICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQg
cHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAtI2lmZGVmIF9fY3BsdXNwbHVzCj4g
LWV4dGVybiAiQyIKPiAtI2VuZGlmCj4gLWNoYXIgZXh0MmZzX29wZW4yICgpOwo+IC1pbnQKPiAt
bWFpbiAoKQo+IC17Cj4gLXJldHVybiBleHQyZnNfb3BlbjIgKCk7Cj4gLSAgOwo+IC0gIHJldHVy
biAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhl
biA6Cj4gLSAgYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjI9eWVzCj4gKyAgICAgICRhY19w
YXRoX0dSRVBfZm91bmQgJiYgYnJlYWsgMwo+ICsgICAgZG9uZQo+ICsgIGRvbmUKPiArICBkb25l
Cj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiArICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9HUkVQIjsg
dGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgZ3JlcCBjb3VsZCBiZSBm
b3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1Cj4g
KyAgZmkKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPW5vCj4gKyAg
YWNfY3ZfcGF0aF9HUkVQPSRHUkVQCj4gIGZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKPiAtTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICsKPiAgZmkKPiAteyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0
MmZzX2V4dDJmc19vcGVuMiIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfbGliX2V4dDJmc19leHQy
ZnNfb3BlbjIiID4mNjsgfQo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29w
ZW4yIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgbGliZXh0MmZzPSJ5Igo+ICt7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1
Cj4gKyRhc19lY2hvICIkYWNfY3ZfcGF0aF9HUkVQIiA+JjY7IH0KPiArIEdSRVA9IiRhY19jdl9w
YXRoX0dSRVAiCj4gKwo+ICsKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgZWdyZXAiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
ZWdyZXAuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX0VHUkVQK3NldH0iID0g
c2V0OyB0aGVuIDoKPiArICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAg
bGliZXh0MmZzPSJuIgo+ICsgIGlmIGVjaG8gYSB8ICRHUkVQIC1FICcoYXxiKScgPi9kZXYvbnVs
bCAyPiYxCj4gKyAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCj4gKyAgIGVsc2UK
PiArICAgICBpZiB0ZXN0IC16ICIkRUdSRVAiOyB0aGVuCj4gKyAgYWNfcGF0aF9FR1JFUF9mb3Vu
ZD1mYWxzZQo+ICsgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3Ig
ZWFjaCBvZiBQUk9HTkFNRS1MSVNUCj4gKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgo+ICtmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2Jp
bgo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9Lgo+ICsgICAgZm9yIGFjX3Byb2cgaW4gZWdyZXA7IGRvCj4gKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiArICAgICAgYWNfcGF0
aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIKPiArICAgICAgeyB0ZXN0IC1m
ICIkYWNfcGF0aF9FR1JFUCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNv
bnRpbnVlCj4gKyMgQ2hlY2sgZm9yIEdOVSBhY19wYXRoX0VHUkVQIGFuZCBzZWxlY3QgaXQgaWYg
aXQgaXMgZm91bmQuCj4gKyAgIyBDaGVjayBmb3IgR05VICRhY19wYXRoX0VHUkVQCj4gK2Nhc2Ug
YCIkYWNfcGF0aF9FR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCj4gKypHTlUqKQo+ICsgIGFjX2N2
X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VHUkVQX2ZvdW5kPTo7Owo+ICsq
KQo+ICsgIGFjX2NvdW50PTAKPiArICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5p
biIKPiArICB3aGlsZSA6Cj4gKyAgZG8KPiArICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVz
dC5pbiIgPiJjb25mdGVzdC50bXAiCj4gKyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3Qu
aW4iCj4gKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKPiArICAgICRhc19lY2hv
ICdFR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgo+ICsgICAgIiRhY19wYXRoX0VHUkVQIiAnRUdSRVAk
JyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCj4g
KyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8
IGJyZWFrCj4gKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192
YWwKPiArICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfRUdSRVBfbWF4LTB9OyB0
aGVuCj4gKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcg
Zm9yIGEgYmV0dGVyIG9uZQo+ICsgICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JF
UCIKPiArICAgICAgYWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50Cj4gKyAgICBmaQo+ICsgICAg
IyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAo+ICsgICAg
dGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCj4gKyAgZG9uZQo+ICsgIHJtIC1mIGNvbmZ0
ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7Owo+ICtlc2FjCj4g
Kwo+ICsgICAgICAkYWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBicmVhayAzCj4gKyAgICBkb25lCj4g
KyAgZG9uZQo+ICsgIGRvbmUKPiArSUZTPSRhc19zYXZlX0lGUwo+ICsgIGlmIHRlc3QgLXogIiRh
Y19jdl9wYXRoX0VHUkVQIjsgdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFi
bGUgZWdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQv
YmluIiAiJExJTkVOTyIgNQo+ICsgIGZpCj4gK2Vsc2UKPiArICBhY19jdl9wYXRoX0VHUkVQPSRF
R1JFUAo+ICBmaQo+IAo+ICsgICBmaQo+ICtmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQo+ICskYXNfZWNo
byAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQo+ICsgRUdSRVA9IiRhY19jdl9wYXRoX0VHUkVQ
Igo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBnY3J5X21kX2hhc2hfYnVmZmVyIGluIC1sZ2NyeXB0IiA+JjUKPiAtJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0K
PiAtaWYgdGVzdCAiJHthY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+ICsKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxlcyIgPiY1Cj4gKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3Qg
IiR7YWNfY3ZfaGVhZGVyX3N0ZGMrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJT
Cj4gLUxJQlM9Ii1sZ2NyeXB0ICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAo+ICsgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8c3RkbGliLmg+
Cj4gKyNpbmNsdWRlIDxzdGRhcmcuaD4KPiArI2luY2x1ZGUgPHN0cmluZy5oPgo+ICsjaW5jbHVk
ZSA8ZmxvYXQuaD4KPiAKPiAtLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg
dG8gYXZvaWQgYW4gZXJyb3IuCj4gLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNo
IHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+IC0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1
bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwo+IC0jaWZkZWYgX19jcGx1c3Bs
dXMKPiAtZXh0ZXJuICJDIgo+IC0jZW5kaWYKPiAtY2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgp
Owo+ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLXJldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgp
Owo+ICsKPiAgICA7Cj4gICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4gLWlmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf
aGFzaF9idWZmZXI9eWVzCj4gK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVu
IDoKPiArICBhY19jdl9oZWFkZXJfc3RkYz15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9nY3J5
cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubwo+IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKPiAtICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0Cj4gLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKPiArICBhY19jdl9oZWFk
ZXJfc3RkYz1ubwo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1Cj4g
LSRhc19lY2hvICIkYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjY7IH0K
PiAtaWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID0geCIi
eWVzOyB0aGVuIDoKPiAtICBsaWJnY3J5cHQ9InkiCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+ICsKPiAraWYgdGVzdCAkYWNf
Y3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiArICAjIFN1bk9TIDQueCBzdHJpbmcuaCBkb2Vz
IG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFOU0kuCj4gKyAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMuaC4gICovCj4g
KyNpbmNsdWRlIDxzdHJpbmcuaD4KPiArCj4gK19BQ0VPRgo+ICtpZiAoZXZhbCAiJGFjX2NwcCBj
b25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Cj4gKyAgJEVHUkVQICJtZW1jaHIiID4vZGV2L251bGwg
Mj4mMTsgdGhlbiA6Cj4gKwo+ICBlbHNlCj4gLSAgbGliZ2NyeXB0PSJuIgo+ICsgIGFjX2N2X2hl
YWRlcl9zdGRjPW5vCj4gK2ZpCj4gK3JtIC1mIGNvbmZ0ZXN0Kgo+ICsKPiAgZmkKPiAKPiAraWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiArICAjIElTQyAyLjAuMiBzdGRs
aWIuaCBkb2VzIG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCj4gKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsvKiBlbmQgY29uZmRlZnMu
aC4gICovCj4gKyNpbmNsdWRlIDxzdGRsaWIuaD4KPiAKPiArX0FDRU9GCj4gK2lmIChldmFsICIk
YWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKPiArICAkRUdSRVAgImZyZWUiID4vZGV2
L251bGwgMj4mMTsgdGhlbiA6Cj4gCj4gLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFkIGZsYWciID4mNQo+IC0kYXNfZWNob19u
ICJjaGVja2luZyBmb3IgcHRocmVhZCBmbGFnLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YXhf
Y3ZfcHRocmVhZF9mbGFncytzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAgZWxzZQo+ICsgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCj4gK2ZpCj4gK3Jt
IC1mIGNvbmZ0ZXN0Kgo+IAo+IC0gICAgICAgIGF4X2N2X3B0aHJlYWRfZmxhZ3M9LXB0aHJlYWQK
PiArZmkKPiAKPiAtICAgIFBUSFJFQURfQ0ZMQUdTPSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKPiAt
ICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCj4gLSAgICBQVEhSRUFE
X0xJQlM9IiIKPiAraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiArICAj
IC9iaW4vY2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3Mg
dXNpbmcgLWFuc2kuCj4gKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g
Ogo+ICsgIDoKPiArZWxzZQo+ICsgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiArLyogZW5kIGNvbmZkZWZzLmguICAqLwo+ICsjaW5jbHVkZSA8Y3R5cGUuaD4K
PiArI2luY2x1ZGUgPHN0ZGxpYi5oPgo+ICsjaWYgKCgnICcgJiAweDBGRikgPT0gMHgwMjApCj4g
KyMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykKPiArIyBkZWZp
bmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMpKQo+ICsj
ZWxzZQo+ICsjIGRlZmluZSBJU0xPV0VSKGMpIFwKPiArICAgICAgICAgICAgICAgICAgKCgnYScg
PD0gKGMpICYmIChjKSA8PSAnaScpIFwKPiArICAgICAgICAgICAgICAgICAgICB8fCAoJ2onIDw9
IChjKSAmJiAoYykgPD0gJ3InKSBcCj4gKyAgICAgICAgICAgICAgICAgICAgfHwgKCdzJyA8PSAo
YykgJiYgKGMpIDw9ICd6JykpCj4gKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAo
KGMpIHwgMHg0MCkgOiAoYykpCj4gKyNlbmRpZgo+IAo+ICsjZGVmaW5lIFhPUihlLCBmKSAoKChl
KSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQo+ICtpbnQKPiArbWFpbiAoKQo+ICt7Cj4gKyAg
aW50IGk7Cj4gKyAgZm9yIChpID0gMDsgaSA8IDI1NjsgaSsrKQo+ICsgICAgaWYgKFhPUiAoaXNs
b3dlciAoaSksIElTTE9XRVIgKGkpKQo+ICsgICAgICAgfHwgdG91cHBlciAoaSkgIT0gVE9VUFBF
UiAoaSkpCj4gKyAgICAgIHJldHVybiAyOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4gK19BQ0VPRgo+
ICtpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAKPiAtICAgIHNhdmVkX0NG
TEFHUz0iJENGTEFHUyIKPiArZWxzZQo+ICsgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCj4gK2ZpCj4g
K3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRl
c3QkYWNfZXhlZXh0IFwKPiArICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29u
ZnRlc3QuJGFjX2V4dAo+ICtmaQo+IAo+IC0gICAgc2F2ZWRfTERGTEFHUz0iJExERkxBR1MiCj4g
K2ZpCj4gK2ZpCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl9z
dGRjIiA+JjY7IH0KPiAraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KPiAK
PiAtICAgIHNhdmVkX0xJQlM9IiRMSUJTIgo+ICskYXNfZWNobyAiI2RlZmluZSBTVERDX0hFQURF
UlMgMSIgPj5jb25mZGVmcy5oCj4gCj4gK2ZpCj4gCj4gLSAgICBDRkxBR1M9IiRDRkxBR1MgJFBU
SFJFQURfQ0ZMQUdTIgo+ICsjIE9uIElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5cGVzLmgg
YXJlIGNvbmZsaWN0aW5nLgo+ICtmb3IgYWNfaGVhZGVyIGluIHN5cy90eXBlcy5oIHN5cy9zdGF0
Lmggc3RkbGliLmggc3RyaW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKPiArICAgICAgICAgICAg
ICAgICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0ZC5oCj4gK2RvIDoKPiArICBhc19hY19IZWFk
ZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCj4gK2Fj
X2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2Fj
X0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0Cj4gKyIKPiAraWYgZXZhbCB0ZXN0IFwieFwk
IiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgo+ICsgIGNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKPiArI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJf
Y3BwYCAxCj4gK19BQ0VPRgo+IAo+IC0gICAgTERGTEFHUz0iJExERkxBR1MgJFBUSFJFQURfTERG
TEFHUyIKPiArZmkKPiAKPiAtICAgIExJQlM9IiRMSUJTICRQVEhSRUFEX0xJQlMiCj4gK2RvbmUK
PiAKPiAtICAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAKPiAtI2luY2x1ZGUgPHB0aHJlYWQuaD4KPiAt
aW50IG1haW4odm9pZCkgewo+IC0gIHB0aHJlYWRfYXRmb3JrKDAsMCwwKTsKPiAtICBwdGhyZWFk
X2NyZWF0ZSgwLDAsMCwwKTsKPiAtfQo+ICtpZiB0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSI7
IHRoZW4gOgo+IAo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRo
ZW4gOgo+ICsgICAgaWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyI7IHRoZW4gOgo+IAo+
ICsgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgo+ICsgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUg
JFBZVEhPTlBBVEhgCj4gKwo+ICtlbGlmIHRlc3QgLXogIiRQWVRIT04iOyB0aGVuIDoKPiArICBQ
WVRIT049InB5dGhvbiIKPiAgZWxzZQo+IC0gIGF4X2N2X3B0aHJlYWRfZmxhZ3M9ZmFpbGVkCj4g
KyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1
dGUgcGF0aCIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAo+ICsgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15ICRQWVRIT047IGFj
X3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIg
PSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiAr
ICBjYXNlICRQWVRIT05QQVRIIGluCj4gKyAgW1xcL10qIHwgPzpbXFwvXSopCj4gKyAgYWNfY3Zf
cGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElG
Uz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0
aF9QWVRIT05QQVRIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUK
PiArSUZTPSRhc19zYXZlX0lGUwo+IAo+IC0gICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZMQUdTIgo+ICsg
IHRlc3QgLXogIiRhY19jdl9wYXRoX1BZVEhPTlBBVEgiICYmIGFjX2N2X3BhdGhfUFlUSE9OUEFU
SD0ibm8iCj4gKyAgOzsKPiArZXNhYwo+ICtmaQo+ICtQWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZ
VEhPTlBBVEgKPiAraWYgdGVzdCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQWVRIT05QQVRIIiA+JjUK
PiArJGFzX2VjaG8gIiRQWVRIT05QQVRIIiA+JjY7IH0KPiArZWxzZQo+ICsgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19lY2hv
ICJubyIgPiY2OyB9Cj4gK2ZpCj4gCj4gLSAgICBMREZMQUdTPSIkc2F2ZWRfTERGTEFHUyIKPiAK
PiAtICAgIExJQlM9IiRzYXZlZF9MSUJTIgo+ICtpZiB0ZXN0IHgiJHtQWVRIT05QQVRIfSIgPT0g
eCJubyIKPiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kICRQWVRI
T04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1Cj4gK2ZpCj4gKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRob24g
dmVyc2lvbiA+PSAyLjMgIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2
ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KPiArYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7IHN5
cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAo+ICtpZiB0ZXN0ICIk
PyIgIT0gIjAiCj4gK3RoZW4KPiArICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFg
Cj4gKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIiRw
eXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgMi4z
IiAiJExJTkVOTyIgNQo+ICtlbHNlCj4gKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2VjaG8gInllcyIgPiY2OyB9Cj4g
K2ZpCj4gCj4gK2FjX3ByZXZpb3VzX2NwcGZsYWdzPSRDUFBGTEFHUwo+ICthY19wcmV2aW91c19s
ZGZsYWdzPSRMREZMQUdTCj4gK2FjX3B5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1jICdpbXBvcnQg
ZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+ICsgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5n
ZXRfY29uZmlnX3ZhcigiVkVSU0lPTiIpJ2AKPiArIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIkUFlUSE9OLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Cj4gK3NldCBkdW1teSAkUFlUSE9OLWNvbmZpZzsgYWNfd29yZD0kMgo+ICt7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4g
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0
ICIke2FjX2N2X3BhdGhfcHljb25maWcrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBjYXNlICRweWNvbmZpZyBpbgo+ICsgIFtc
XC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2X3BhdGhfcHljb25maWc9IiRweWNvbmZpZyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAq
KQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2Rp
ciBpbiAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNf
ZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0aF9weWNvbmZpZz0iJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsg
IGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiAKPiArICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9weWNvbmZpZyIgJiYgYWNfY3ZfcGF0aF9weWNvbmZpZz0ibm8iCj4gKyAg
OzsKPiArZXNhYwo+ICtmaQo+ICtweWNvbmZpZz0kYWNfY3ZfcGF0aF9weWNvbmZpZwo+ICtpZiB0
ZXN0IC1uICIkcHljb25maWciOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRweWNvbmZpZyIgPiY1Cj4gKyRhc19lY2hvICIkcHljb25m
aWciID4mNjsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5vIiA+JjY7IH0KPiAgZmkKPiAt
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRheF9jdl9w
dGhyZWFkX2ZsYWdzIiA+JjUKPiAtJGFzX2VjaG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjY7
IH0KPiAtICAgIGlmIHRlc3QgIngkYXhfY3ZfcHRocmVhZF9mbGFncyIgPSB4ZmFpbGVkOyB0aGVu
Cj4gLSAgICAgICAgYXNfZm5fZXJyb3IgJD8gIi1wdGhyZWFkIGRvZXMgbm90IHdvcmsiICIkTElO
RU5PIiA1Cj4gLSAgICBmaQo+IC0KPiAtICAgIFBUSFJFQURfQ0ZMQUdTPSIkYXhfY3ZfcHRocmVh
ZF9mbGFncyIKPiAtICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCj4g
LSAgICBQVEhSRUFEX0xJQlM9IiIKPiAKPiAKPiAraWYgdGVzdCB4IiRweWNvbmZpZyIgPT0geCJu
byI7IHRoZW4gOgo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBjbG9ja19nZXR0aW1lIGluIC1scnQiID4mNQo+IC0kYXNfZWNob19uICJj
aGVja2luZyBmb3IgY2xvY2tfZ2V0dGltZSBpbiAtbHJ0Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3Qg
IiR7YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+IC0gICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCj4gLUxJQlM9Ii1scnQgICRMSUJTIgo+IC1jYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiArICAgICAg
ICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25m
aWc7IFwKPiArICAgICAgICBwcmludCAiLUkiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29u
ZmlnX3ZhcigiSU5DTFVERVBZIiknYCIKPiArICAgIENQUEZMQUdTPSIkQ1BQRkxBR1MgYCRQWVRI
T04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gKyAgICAgICAgcHJpbnQgZGlz
dHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiQ0ZMQUdTIiknYCIKPiArICAgIExERkxB
R1M9IiRMREZMQUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAo+
ICsgICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIkxJQlMi
KSdgIgo+ICsgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRp
bHMuc3lzY29uZmlnOyBcCj4gKyAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRf
Y29uZmlnX3ZhcigiU1lTTElCUyIpJ2AiCj4gKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhP
TiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKPiArICAgICAgICBwcmludCAiLUwi
ICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9uX2xpYihwbGF0X3NwZWNpZmljPTEsXAo+
ICsgICAgICAgIHN0YW5kYXJkX2xpYj0xKSArICIvY29uZmlnIidgIgo+ICsgICAgTERGTEFHUz0i
JExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCj4gKyAg
ICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElOS0ZPUlNI
QVJFRCIpJ2AiCj4gKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRp
c3R1dGlscy5zeXNjb25maWc7IFwKPiArICAgICAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmln
LmdldF9jb25maWdfdmFyKCJMREZMQUdTIiknYCIKPiAKPiAtLyogT3ZlcnJpZGUgYW55IEdDQyBp
bnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gLSAgIFVzZSBjaGFyIGJlY2F1
c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+IC0gICBidWlsdGlu
IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwo+
IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+IC0jZW5kaWYKPiAtY2hhciBjbG9j
a19nZXR0aW1lICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLXJldHVybiBjbG9ja19nZXR0
aW1lICgpOwo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5f
Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0
aW1lPXllcwo+ICBlbHNlCj4gLSAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9bm8KPiAtZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gLWZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID4mNQo+IC0kYXNfZWNobyAi
JGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjY7IH0KPiAtaWYgdGVzdCAieCRhY19jdl9s
aWJfcnRfY2xvY2tfZ2V0dGltZSIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKPiAtI2RlZmluZSBIQVZFX0xJQlJUIDEKPiAtX0FDRU9GCj4gCj4gLSAgTElC
Uz0iLWxydCAkTElCUyIKPiArICAgICAgICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTi1jb25m
aWcgLS1jZmxhZ3NgIgo+ICsgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04tY29uZmlnIC0t
bGRmbGFnc2AiCj4gCj4gIGZpCj4gCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsIiA+JjUKPiAtJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2OyB9Cj4gLWlm
IHRlc3QgIiR7YWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYytzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAtZWxzZQo+IC0gIGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlM9JExJQlMKPiAtTElCUz0iLWx5YWpsICAkTElCUyIKPiAtY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4g
K2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJQeXRob24uaCIgImFjX2N2
X2hlYWRlcl9QeXRob25faCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+ICtpZiB0ZXN0ICJ4JGFj
X2N2X2hlYWRlcl9QeXRob25faCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC0vKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiAtICAgVXNlIGNo
YXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gLSAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1leHRlcm4gIkMiCj4gLSNlbmRpZgo+IC1j
aGFyIHlhamxfYWxsb2MgKCk7Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtcmV0dXJuIHlhamxf
YWxsb2MgKCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX3lhamxfeWFqbF9h
bGxvYz15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KPiAtZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIFB5dGhvbiBkZXZl
bG9wbWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mi
ID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQo+IC1p
ZiB0ZXN0ICJ4JGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID0geCIieWVzOyB0aGVuIDoKPiAt
ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKPiAt
X0FDRU9GCj4gLQo+IC0gIExJQlM9Ii1seWFqbCAkTElCUyIKPiAKPiAtZWxzZQo+IC0gIGFzX2Zu
X2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB5YWpsIiAiJExJTkVOTyIgNQo+IC1maQo+IAo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBkZWZs
YXRlQ29weSBpbiAtbHoiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgZGVmbGF0ZUNv
cHkgaW4gLWx6Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfbGliX3pfZGVmbGF0ZUNv
cHkrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICthc19hY19MaWI9YCRhc19lY2hvICJhY19jdl9saWJf
cHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uJydfUHlBcmdfUGFyc2VUdXBsZSIgfCAkYXNfdHJfc2hg
Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQo+ICsk
YXNfZWNob19uICJjaGVja2luZyBmb3IgUHlBcmdfUGFyc2VUdXBsZSBpbiAtbHB5dGhvbiRhY19w
eXRob25fdmVyc2lvbi4uLiAiID4mNjsgfQo+ICtpZiBldmFsICJ0ZXN0IFwiXCR7JGFzX2FjX0xp
YitzZXR9XCIiID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+
ICBlbHNlCj4gICAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+IC1MSUJTPSItbHogICRM
SUJTIgo+ICtMSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiAgJExJQlMiCj4gIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZz
LmguICAqLwo+IAo+IEBAIC03NjMyLDE4OTMgKzUzNzcsMTE3MyBAQCBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gICNpZmRlZiBfX2NwbHVzcGx1cwo+ICBleHRl
cm4gIkMiCj4gICNlbmRpZgo+IC1jaGFyIGRlZmxhdGVDb3B5ICgpOwo+ICtjaGFyIFB5QXJnX1Bh
cnNlVHVwbGUgKCk7Cj4gIGludAo+ICBtYWluICgpCj4gIHsKPiAtcmV0dXJuIGRlZmxhdGVDb3B5
ICgpOwo+ICtyZXR1cm4gUHlBcmdfUGFyc2VUdXBsZSAoKTsKPiAgICA7Cj4gICAgcmV0dXJuIDA7
Cj4gIH0KPiAgX0FDRU9GCj4gIGlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
PiAtICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKPiArICBldmFsICIkYXNfYWNfTGliPXll
cyIKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5vCj4gKyAgZXZhbCAiJGFz
X2FjX0xpYj1ubyIKPiAgZmkKPiAgcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBcCj4gICAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICBM
SUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4m
NQo+IC0kYXNfZWNobyAiJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KPiAtaWYgdGVz
dCAieCRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICtldmFsIGFj
X3Jlcz1cJCRhc19hY19MaWIKPiArICAgICAgICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Cj4gKyRhc19lY2hvICIkYWNf
cmVzIiA+JjY7IH0KPiAraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19MaWIiXCIgPSB4InllcyI7
IHRoZW4gOgo+ICAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBIQVZFX0xJ
QlogMQo+ICsjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV9MSUJweXRob24kYWNfcHl0aG9uX3ZlcnNp
b24iIHwgJGFzX3RyX2NwcGAgMQo+ICBfQUNFT0YKPiAKPiAtICBMSUJTPSItbHogJExJQlMiCj4g
LQo+IC1lbHNlCj4gLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHpsaWIiICIkTElO
RU5PIiA1Cj4gLWZpCj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4mNQo+IC0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252Li4uICIgPiY2OyB9Cj4g
LWlmIHRlc3QgIiR7YWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4rc2V0fSIgPSBzZXQ7IHRo
ZW4gOgo+IC0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gLWVsc2UKPiAtICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCj4gLUxJQlM9Ii1saWNvbnYgICRMSUJTIgo+IC1jYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KPiArICBMSUJTPSItbHB5dGhvbiRhY19weXRob25fdmVyc2lvbiAkTElCUyIKPiAKPiAt
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
Cj4gLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQwo+IC0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLwo+IC0jaWZkZWYgX19jcGx1c3BsdXMKPiAtZXh0ZXJuICJDIgo+
IC0jZW5kaWYKPiAtY2hhciBsaWJpY29udl9vcGVuICgpOwo+IC1pbnQKPiAtbWFpbiAoKQo+IC17
Cj4gLXJldHVybiBsaWJpY29udl9vcGVuICgpOwo+IC0gIDsKPiAtICByZXR1cm4gMDsKPiAtfQo+
IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFj
X2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfbGliX2lj
b252X2xpYmljb252X29wZW49bm8KPiAtZmkKPiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAo+IC1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCj4gLWZpCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xp
Ymljb252X29wZW4iID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9v
cGVuIiA+JjY7IH0KPiAtaWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIg
PSB4IiJ5ZXM7IHRoZW4gOgo+IC0gIGxpYmljb252PSJ5Igo+ICBlbHNlCj4gLSAgbGliaWNvbnY9
Im4iCj4gKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGEgc3VpdGFibGUgcHl0aG9u
IGRldmVsb3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1Cj4gIGZpCj4gCj4gK0NQUEZMQUdTPSRh
Y19wcmV2aW91c19jcHBmbGFncwo+ICtMRExGQUdTPSRhY19wcmV2aW91c19sZGZsYWdzCj4gCj4g
Cj4gLSMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCj4gLSMgVGhlIFVsdHJpeCA0LjIgbWlwcyBi
dWlsdGluIGFsbG9jYSBkZWNsYXJlZCBieSBhbGxvY2EuaCBvbmx5IHdvcmtzCj4gLSMgZm9yIGNv
bnN0YW50IGFyZ3VtZW50cy4gIFVzZWxlc3MhCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmgiID4mNQo+IC0kYXNf
ZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBhbGxvY2EuaC4uLiAiID4mNjsgfQo+IC1pZiB0
ZXN0ICIke2FjX2N2X3dvcmtpbmdfYWxsb2NhX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICtmaQo+
ICsjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInhnZXR0ZXh0Iiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQy
Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhl
biA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+IC0jaW5jbHVkZSA8YWxsb2NhLmg+Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtY2hh
ciAqcCA9IChjaGFyICopIGFsbG9jYSAoMiAqIHNpemVvZiAoaW50KSk7Cj4gLSAgICAgICAgICAg
ICAgICAgICAgICAgICBpZiAocCkgcmV0dXJuIDA7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19
Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAg
YWNfY3Zfd29ya2luZ19hbGxvY2FfaD15ZXMKPiAtZWxzZQo+IC0gIGFjX2N2X3dvcmtpbmdfYWxs
b2NhX2g9bm8KPiArICBjYXNlICRYR0VUVEVYVCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+
ICsgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp
ZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+
ICsgIElGUz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+
ICsgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
Cj4gKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNf
Y3ZfcGF0aF9YR0VUVEVYVD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBk
b25lCj4gK0lGUz0kYXNfc2F2ZV9JRlMKPiArCj4gKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdF
VFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9Im5vIgo+ICsgIDs7Cj4gK2VzYWMKPiAgZmkK
PiAtcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gLSAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICtYR0VUVEVYVD0kYWNfY3ZfcGF0
aF9YR0VUVEVYVAo+ICtpZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1Cj4g
KyRhc19lY2hvICIkWEdFVFRFWFQiID4mNjsgfQo+ICtlbHNlCj4gKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKPiArJGFzX2VjaG8gIm5v
IiA+JjY7IH0KPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19j
dl93b3JraW5nX2FsbG9jYV9oIiA+JjY7IH0KPiAtaWYgdGVzdCAkYWNfY3Zfd29ya2luZ19hbGxv
Y2FfaCA9IHllczsgdGhlbgo+IAo+IC0kYXNfZWNobyAiI2RlZmluZSBIQVZFX0FMTE9DQV9IIDEi
ID4+Y29uZmRlZnMuaAo+IAo+ICtpZiB0ZXN0IHgiJHtYR0VUVEVYVH0iID09IHgibm8iCj4gK3Ro
ZW4KPiArICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNl
IGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1Cj4gIGZpCj4gLQo+IC17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhbGxvY2EiID4mNQo+IC0k
YXNfZWNob19uICJjaGVja2luZyBmb3IgYWxsb2NhLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7
YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgImFzODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgo+ICtzZXQgZHVtbXkgYXM4NjsgYWNfd29yZD0kMgo+ICt7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cj4gKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfQVM4NitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaWZkZWYgX19HTlVDX18K
PiAtIyBkZWZpbmUgYWxsb2NhIF9fYnVpbHRpbl9hbGxvY2EKPiAtI2Vsc2UKPiAtIyBpZmRlZiBf
TVNDX1ZFUgo+IC0jICBpbmNsdWRlIDxtYWxsb2MuaD4KPiAtIyAgZGVmaW5lIGFsbG9jYSBfYWxs
b2NhCj4gLSMgZWxzZQo+IC0jICBpZmRlZiBIQVZFX0FMTE9DQV9ICj4gLSMgICBpbmNsdWRlIDxh
bGxvY2EuaD4KPiAtIyAgZWxzZQo+IC0jICAgaWZkZWYgX0FJWAo+IC0gI3ByYWdtYSBhbGxvY2EK
PiAtIyAgIGVsc2UKPiAtIyAgICBpZm5kZWYgYWxsb2NhIC8qIHByZWRlZmluZWQgYnkgSFAgY2Mg
K09saWJjYWxscyAqLwo+IC1jaGFyICphbGxvY2EgKCk7Cj4gLSMgICAgZW5kaWYKPiAtIyAgIGVu
ZGlmCj4gLSMgIGVuZGlmCj4gLSMgZW5kaWYKPiAtI2VuZGlmCj4gLQo+IC1pbnQKPiAtbWFpbiAo
KQo+IC17Cj4gLWNoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDEpOwo+IC0gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGlmIChwKSByZXR1cm4gMDsKPiAtICA7Cj4gLSAgcmV0dXJu
IDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVu
IDoKPiAtICBhY19jdl9mdW5jX2FsbG9jYV93b3Jrcz15ZXMKPiAtZWxzZQo+IC0gIGFjX2N2X2Z1
bmNfYWxsb2NhX3dvcmtzPW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVu
Y19hbGxvY2Ffd29ya3MiID4mNjsgfQo+IC0KPiAtaWYgdGVzdCAkYWNfY3ZfZnVuY19hbGxvY2Ff
d29ya3MgPSB5ZXM7IHRoZW4KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBIDEi
ID4+Y29uZmRlZnMuaAo+ICsgIGNhc2UgJEFTODYgaW4KPiArICBbXFwvXSogfCA/OltcXC9dKikK
PiArICBhY19jdl9wYXRoX0FTODY9IiRBUzg2IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdCB3aXRoIGEgcGF0aC4KPiArICA7Owo+ICsgICopCj4gKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgo+ICtmb3IgYXNfZGlyIGluICRQQVRICj4gK2RvCj4gKyAgSUZT
PSRhc19zYXZlX0lGUwo+ICsgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCj4gKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KPiArICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCj4gKyAgICBhY19jdl9wYXRo
X0FTODY9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKPiArICAgIGJyZWFrIDIKPiArICBmaQo+ICtkb25lCj4gKyAgZG9uZQo+ICtJRlM9
JGFzX3NhdmVfSUZTCj4gCj4gKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQVM4NiIgJiYgYWNfY3Zf
cGF0aF9BUzg2PSJubyIKPiArICA7Owo+ICtlc2FjCj4gK2ZpCj4gK0FTODY9JGFjX2N2X3BhdGhf
QVM4Ngo+ICtpZiB0ZXN0IC1uICIkQVM4NiI7IHRoZW4KPiArICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEFTODYiID4mNQo+ICskYXNfZWNobyAiJEFT
ODYiID4mNjsgfQo+ICBlbHNlCj4gLSAgIyBUaGUgU1ZSMyBsaWJQVyBhbmQgU1ZSNCBsaWJ1Y2Ig
Ym90aCBjb250YWluIGluY29tcGF0aWJsZSBmdW5jdGlvbnMKPiAtIyB0aGF0IGNhdXNlIHRyb3Vi
bGUuICBTb21lIHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2NhIG9yCj4gLSMgY29u
dGFpbiBhIGJ1Z2d5IHZlcnNpb24uICBJZiB5b3Ugc3RpbGwgd2FudCB0byB1c2UgdGhlaXIgYWxs
b2NhLAo+IC0jIHVzZSBhciB0byBleHRyYWN0IGFsbG9jYS5vIGZyb20gdGhlbSBpbnN0ZWFkIG9m
IGNvbXBpbGluZyBhbGxvY2EuYy4KPiAtCj4gLUFMTE9DQT1cJHtMSUJPQkpESVJ9YWxsb2NhLiRh
Y19vYmpleHQKPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMu
aAo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gK2ZpCj4gCj4gCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBcYGFsbG9jYS5j
JyBuZWVkcyBDcmF5IGhvb2tzIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBc
YGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3Zfb3NfY3JheStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK2lmIHRlc3QgeCIke0FTODZ9IiA9PSB4
Im5vIgo+ICt0aGVuCj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYXM4Niwg
cGxlYXNlIGluc3RhbGwgYXM4NiIgIiRMSU5FTk8iIDUKPiArZmkKPiArIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJsZDg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KPiArc2V0IGR1bW15IGxkODY7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19j
dl9wYXRoX0xEODYrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2Cj4gIGVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2lmIGRlZmluZWQgQ1JBWSAmJiAh
IGRlZmluZWQgQ1JBWTIKPiAtd2ViZWNyYXkKPiAtI2Vsc2UKPiAtd2Vub3RiZWNyYXkKPiAtI2Vu
ZGlmCj4gKyAgY2FzZSAkTEQ4NiBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+ICsgIGFjX2N2
X3BhdGhfTEQ4Nj0iJExEODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgo+ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiArICBJRlM9JGFzX3NhdmVf
SUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiArICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICsgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2X3BhdGhfTEQ4Nj0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQo+
ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0kYXNfc2F2ZV9J
RlMKPiAKPiAtX0FDRU9GCj4gLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAy
PiY1IHwKPiAtICAkRUdSRVAgIndlYmVjcmF5IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgo+IC0g
IGFjX2N2X29zX2NyYXk9eWVzCj4gLWVsc2UKPiAtICBhY19jdl9vc19jcmF5PW5vCj4gKyAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfTEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKPiArICA7Owo+
ICtlc2FjCj4gIGZpCj4gLXJtIC1mIGNvbmZ0ZXN0Kgo+IC0KPiArTEQ4Nj0kYWNfY3ZfcGF0aF9M
RDg2Cj4gK2lmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkTEQ4NiIgPiY1Cj4gKyRhc19lY2hvICIkTEQ4
NiIgPiY2OyB9Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29z
X2NyYXkiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4mNjsgfQo+IC1pZiB0ZXN0
ICRhY19jdl9vc19jcmF5ID0geWVzOyB0aGVuCj4gLSAgZm9yIGFjX2Z1bmMgaW4gX2dldGI2NyBH
RVRCNjcgZ2V0YjY3OyBkbwo+IC0gICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18k
YWNfZnVuYyIgfCAkYXNfdHJfc2hgCj4gLWFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRh
Y19mdW5jIiAiJGFzX2FjX3ZhciIKPiAtaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIg
PSB4InllcyI7IHRoZW4gOgo+IC0KPiAtY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVm
aW5lIENSQVlfU1RBQ0tTRUdfRU5EICRhY19mdW5jCj4gLV9BQ0VPRgo+IAo+IC0gICAgYnJlYWsK
PiAtZmkKPiAKPiAtICBkb25lCj4gK2lmIHRlc3QgeCIke0xEODZ9IiA9PSB4Im5vIgo+ICt0aGVu
Cj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgbGQ4NiwgcGxlYXNlIGluc3Rh
bGwgbGQ4NiIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYSIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIHN0YWNrIGRpcmVjdGlvbiBmb3IgQyBhbGxvY2Eu
Li4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9jX3N0YWNrX2RpcmVjdGlvbitzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmNjIiwgc28gaXQg
Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0IGR1bW15IGJjYzsgYWNfd29y
ZD0kMgo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X3BhdGhfQkNDK3NldH0iID0gc2V0OyB0aGVu
IDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAi
JGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFjX2N2X2Nfc3RhY2tfZGlyZWN0
aW9uPTAKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVsdAo+
IC1pbnQKPiAtZmluZF9zdGFja19kaXJlY3Rpb24gKCkKPiAtewo+IC0gIHN0YXRpYyBjaGFyICph
ZGRyID0gMDsKPiAtICBhdXRvIGNoYXIgZHVtbXk7Cj4gLSAgaWYgKGFkZHIgPT0gMCkKPiAtICAg
IHsKPiAtICAgICAgYWRkciA9ICZkdW1teTsKPiAtICAgICAgcmV0dXJuIGZpbmRfc3RhY2tfZGly
ZWN0aW9uICgpOwo+IC0gICAgfQo+IC0gIGVsc2UKPiAtICAgIHJldHVybiAoJmR1bW15ID4gYWRk
cikgPyAxIDogLTE7Cj4gLX0KPiArICBjYXNlICRCQ0MgaW4KPiArICBbXFwvXSogfCA/OltcXC9d
KikKPiArICBhY19jdl9wYXRoX0JDQz0iJEJDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCj4gKyAgOzsKPiArICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElG
Uz0kYXNfc2F2ZV9JRlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0
aF9CQ0M9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCj4gKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKPiArICAgIGJyZWFrIDIKPiArICBmaQo+ICtkb25lCj4gKyAgZG9uZQo+ICtJRlM9
JGFzX3NhdmVfSUZTCj4gCj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtICByZXR1cm4gZmluZF9z
dGFja19kaXJlY3Rpb24gKCkgPCAwOwo+IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9y
dW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0xCj4gLWVs
c2UKPiAtICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0tMQo+IC1maQo+IC1ybSAtZiBjb3JlICou
Y29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBc
Cj4gLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQK
PiArICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQ0MiICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKPiAr
ICA7Owo+ICtlc2FjCj4gIGZpCj4gLQo+ICtCQ0M9JGFjX2N2X3BhdGhfQkNDCj4gK2lmIHRlc3Qg
LW4gIiRCQ0MiOyB0aGVuCj4gKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRCQ0MiID4mNQo+ICskYXNfZWNobyAiJEJDQyIgPiY2OyB9Cj4gK2Vsc2UK
PiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+
JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY2OyB9Cj4gLWNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBTVEFDS19ESVJFQ1RJT04gJGFjX2N2X2Nf
c3RhY2tfZGlyZWN0aW9uCj4gLV9BQ0VPRgo+IAo+IAo+ICtpZiB0ZXN0IHgiJHtCQ0N9IiA9PSB4
Im5vIgo+ICt0aGVuCj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmNjLCBw
bGVhc2UgaW5zdGFsbCBiY2MiICIkTElORU5PIiA1Cj4gIGZpCj4gKyMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAiaWFzbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Cj4gK3NldCBkdW1teSBpYXNsOyBhY193b3JkPSQyCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKPiArJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3Zf
cGF0aF9JQVNMK3NldH0iID0gc2V0OyB0aGVuIDoKPiArICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgo+ICtlbHNlCj4gKyAgY2FzZSAkSUFTTCBpbgo+ICsgIFtcXC9dKiB8ID86W1xcL10qKQo+
ICsgIGFjX2N2X3BhdGhfSUFTTD0iJElBU0wiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgo+ICsgIDs7Cj4gKyAgKikKPiArICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCj4gK2ZvciBhc19kaXIgaW4gJFBBVEgKPiArZG8KPiArICBJRlM9
JGFzX3NhdmVfSUZTCj4gKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KPiArICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwo+ICsgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KPiArICAgIGFjX2N2X3BhdGhf
SUFTTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKPiArICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQo+ICsgICAgYnJlYWsgMgo+ICsgIGZpCj4gK2RvbmUKPiArICBkb25lCj4gK0lGUz0k
YXNfc2F2ZV9JRlMKPiAKPiAtZm9yIGFjX2hlYWRlciBpbiAgXAo+IC0gICAgICAgICAgICAgICAg
YXJwYS9pbmV0LmggZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2Mu
aCBcCj4gLSAgICAgICAgICAgICAgICBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRp
bnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCj4gLSAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lz
L2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCj4gLSAgICAgICAg
ICAgICAgICBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRl
cm1pb3MuaCBcCj4gLSAgICAgICAgICAgICAgICB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5o
IFwKPiArICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9JQVNMIiAmJiBhY19jdl9wYXRoX0lBU0w9Im5v
Igo+ICsgIDs7Cj4gK2VzYWMKPiArZmkKPiArSUFTTD0kYWNfY3ZfcGF0aF9JQVNMCj4gK2lmIHRl
c3QgLW4gIiRJQVNMIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkSUFTTCIgPiY1Cj4gKyRhc19lY2hvICIkSUFTTCIgPiY2OyB9Cj4g
K2Vsc2UKPiArICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQo+ICskYXNfZWNobyAibm8iID4mNjsgfQo+ICtmaQo+IAo+IC1kbyA6Cj4gLSAg
YXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3Ry
X3NoYAo+IC1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiJGFjX2hlYWRl
ciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgZXZhbCB0ZXN0
IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAk
YXNfdHJfY3BwYCAxCj4gLV9BQ0VPRgo+IAo+ICtpZiB0ZXN0IHgiJHtJQVNMfSIgPT0geCJubyIK
PiArdGhlbgo+ICsgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGlhc2wsIHBsZWFz
ZSBpbnN0YWxsIGlhc2wiICIkTElORU5PIiA1Cj4gIGZpCj4gCj4gLWRvbmUKPiAtCj4gK2FjX2Zu
X2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJ1dWlkL3V1aWQuaCIgImFjX2N2X2hl
YWRlcl91dWlkX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+ICtpZiB0ZXN0ICJ4JGFj
X2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC0jIENoZWNrcyBm
b3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCj4g
LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0
ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5OSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0byBDOTkuLi4gIiA+JjY7IH0KPiAtaWYgdGVz
dCAiJHthY19jdl9oZWFkZXJfc3RkYm9vbF9oK3NldH0iID0gc2V0OyB0aGVuIDoKPiArICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1aWRf
Y2xlYXIgaW4gLWx1dWlkIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHV1aWRfY2xl
YXIgaW4gLWx1dWlkLi4uICIgPiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3V1aWRfdXVp
ZF9jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKPiAgZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKPiArICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4gK0xJQlM9Ii1sdXVpZCAgJExJ
QlMiCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyog
ZW5kIGNvbmZkZWZzLmguICAqLwo+IAo+IC0jaW5jbHVkZSA8c3RkYm9vbC5oPgo+IC0jaWZuZGVm
IGJvb2wKPiAtICJlcnJvcjogYm9vbCBpcyBub3QgZGVmaW5lZCIKPiAtI2VuZGlmCj4gLSNpZm5k
ZWYgZmFsc2UKPiAtICJlcnJvcjogZmFsc2UgaXMgbm90IGRlZmluZWQiCj4gLSNlbmRpZgo+IC0j
aWYgZmFsc2UKPiAtICJlcnJvcjogZmFsc2UgaXMgbm90IDAiCj4gLSNlbmRpZgo+IC0jaWZuZGVm
IHRydWUKPiAtICJlcnJvcjogdHJ1ZSBpcyBub3QgZGVmaW5lZCIKPiAtI2VuZGlmCj4gLSNpZiB0
cnVlICE9IDEKPiAtICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIKPiAtI2VuZGlmCj4gLSNpZm5kZWYg
X19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQKPiAtICJlcnJvcjogX19ib29sX3RydWVfZmFs
c2VfYXJlX2RlZmluZWQgaXMgbm90IGRlZmluZWQiCj4gKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50
ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2UgY2hhciBiZWNhdXNl
IGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiArICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAr
I2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiAgI2VuZGlmCj4gLQo+IC0gICAgICAg
c3RydWN0IHMgeyBfQm9vbCBzOiAxOyBfQm9vbCB0OyB9IHM7Cj4gLQo+IC0gICAgICAgY2hhciBh
W3RydWUgPT0gMSA/IDEgOiAtMV07Cj4gLSAgICAgICBjaGFyIGJbZmFsc2UgPT0gMCA/IDEgOiAt
MV07Cj4gLSAgICAgICBjaGFyIGNbX19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQgPT0gMSA/
IDEgOiAtMV07Cj4gLSAgICAgICBjaGFyIGRbKGJvb2wpIDAuNSA9PSB0cnVlID8gMSA6IC0xXTsK
PiAtICAgICAgIGJvb2wgZSA9ICZzOwo+IC0gICAgICAgY2hhciBmWyhfQm9vbCkgMC4wID09IGZh
bHNlID8gMSA6IC0xXTsKPiAtICAgICAgIGNoYXIgZ1t0cnVlXTsKPiAtICAgICAgIGNoYXIgaFtz
aXplb2YgKF9Cb29sKV07Cj4gLSAgICAgICBjaGFyIGlbc2l6ZW9mIHMudF07Cj4gLSAgICAgICBl
bnVtIHsgaiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAy
NTYgfTsKPiAtICAgICAgIC8qIFRoZSBmb2xsb3dpbmcgZmFpbHMgZm9yCj4gLSAgICAgICAgICBI
UCBhQysrL0FOU0kgQyBCMzkxMEIgQS4wNS41NSBbRGVjIDA0IDIwMDNdLiAqLwo+IC0gICAgICAg
X0Jvb2wgblttXTsKPiAtICAgICAgIGNoYXIgb1tzaXplb2YgbiA9PSBtICogc2l6ZW9mIG5bMF0g
PyAxIDogLTFdOwo+IC0gICAgICAgY2hhciBwWy0xIC0gKF9Cb29sKSAwIDwgMCAmJiAtMSAtIChi
b29sKSAwIDwgMCA/IDEgOiAtMV07Cj4gLSMgICAgICBpZiBkZWZpbmVkIF9feGxjX18gfHwgZGVm
aW5lZCBfX0dOVUNfXwo+IC0gICAgICAgIC8qIENhdGNoIGEgYnVnIGluIElCTSBBSVggeGxjIGNv
bXBpbGVyIHZlcnNpb24gNi4wLjAuMAo+IC0gICAgICAgICAgIHJlcG9ydGVkIGJ5IEphbWVzIExl
bWxleSBvbiAyMDA1LTEwLTA1OyBzZWUKPiAtICAgICAgICAgICBodHRwOi8vbGlzdHMuZ251Lm9y
Zy9hcmNoaXZlL2h0bWwvYnVnLWNvcmV1dGlscy8yMDA1LTEwL21zZzAwMDg2Lmh0bWwKPiAtICAg
ICAgICAgICBUaGlzIHRlc3QgaXMgbm90IHF1aXRlIHJpZ2h0LCBzaW5jZSB4bGMgaXMgYWxsb3dl
ZCB0bwo+IC0gICAgICAgICAgIHJlamVjdCB0aGlzIHByb2dyYW0sIGFzIHRoZSBpbml0aWFsaXpl
ciBmb3IgeGxjYnVnIGlzCj4gLSAgICAgICAgICAgbm90IG9uZSBvZiB0aGUgZm9ybXMgdGhhdCBD
IHJlcXVpcmVzIHN1cHBvcnQgZm9yLgo+IC0gICAgICAgICAgIEhvd2V2ZXIsIGRvaW5nIHRoZSB0
ZXN0IHJpZ2h0IHdvdWxkIHJlcXVpcmUgYSBydW50aW1lCj4gLSAgICAgICAgICAgdGVzdCwgYW5k
IHRoYXQgd291bGQgbWFrZSBjcm9zcy1jb21waWxhdGlvbiBoYXJkZXIuCj4gLSAgICAgICAgICAg
TGV0IHVzIGhvcGUgdGhhdCBJQk0gZml4ZXMgdGhlIHhsYyBidWcsIGFuZCBhbHNvIGFkZHMKPiAt
ICAgICAgICAgICBzdXBwb3J0IGZvciB0aGlzIGtpbmQgb2YgY29uc3RhbnQgZXhwcmVzc2lvbi4g
IEluIHRoZQo+IC0gICAgICAgICAgIG1lYW50aW1lLCB0aGlzIHRlc3Qgd2lsbCByZWplY3QgeGxj
LCB3aGljaCBpcyBPSywgc2luY2UKPiAtICAgICAgICAgICBvdXIgc3RkYm9vbC5oIHN1YnN0aXR1
dGUgc2hvdWxkIHN1ZmZpY2UuICBXZSBhbHNvIHRlc3QKPiAtICAgICAgICAgICB0aGlzIHdpdGgg
R0NDLCB3aGVyZSBpdCBzaG91bGQgd29yaywgdG8gZGV0ZWN0IG1vcmUKPiAtICAgICAgICAgICBx
dWlja2x5IHdoZXRoZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRlc3QgaW4gdGhlCj4gLSAgICAg
ICAgICAgZnV0dXJlLiAgKi8KPiAtICAgICAgICBjaGFyIGRpZ3NbXSA9ICIwMTIzNDU2Nzg5IjsK
PiAtICAgICAgICBpbnQgeGxjYnVnID0gMSAvICgmKGRpZ3MgKyA1KVstMiArIChib29sKSAxXSA9
PSAmZGlnc1s0XSA/IDEgOiAtMSk7Cj4gLSMgICAgICBlbmRpZgo+IC0gICAgICAgLyogQ2F0Y2gg
YSBidWcgaW4gYW4gSFAtVVggQyBjb21waWxlci4gIFNlZQo+IC0gICAgICAgICAgaHR0cDovL2dj
Yy5nbnUub3JnL21sL2djYy1wYXRjaGVzLzIwMDMtMTIvbXNnMDIzMDMuaHRtbAo+IC0gICAgICAg
ICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0x
MS9tc2cwMDE2MS5odG1sCj4gLSAgICAgICAgKi8KPiAtICAgICAgIF9Cb29sIHEgPSB0cnVlOwo+
IC0gICAgICAgX0Jvb2wgKnBxID0gJnE7Cj4gLQo+ICtjaGFyIHV1aWRfY2xlYXIgKCk7Cj4gIGlu
dAo+ICBtYWluICgpCj4gIHsKPiAtCj4gLSAgICAgICAqcHEgfD0gcTsKPiAtICAgICAgICpwcSB8
PSAhIHE7Cj4gLSAgICAgICAvKiBSZWZlciB0byBldmVyeSBkZWNsYXJlZCB2YWx1ZSwgdG8gYXZv
aWQgY29tcGlsZXIgb3B0aW1pemF0aW9ucy4gICovCj4gLSAgICAgICByZXR1cm4gKCFhICsgIWIg
KyAhYyArICFkICsgIWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCj4gLSAg
ICAgICAgICAgICAgICsgIW0gKyAhbiArICFvICsgIXAgKyAhcSArICFwcSk7Cj4gLQo+ICtyZXR1
cm4gdXVpZF9jbGVhciAoKTsKPiAgICA7Cj4gICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4g
LWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9oZWFk
ZXJfc3RkYm9vbF9oPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaD1ubwo+
IC1maQo+IC1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKPiAtZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjUKPiAtJGFzX2VjaG8gIiRh
Y19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjY7IH0KPiAtYWNfZm5fY19jaGVja190eXBlICIkTElO
RU5PIiAiX0Jvb2wiICJhY19jdl90eXBlX19Cb29sIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4g
LWlmIHRlc3QgIngkYWNfY3ZfdHlwZV9fQm9vbCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVfX0JPT0wgMQo+IC1fQUNFT0YK
PiAtCj4gLQo+IC1maQo+IC0KPiAtaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCA9IHll
czsgdGhlbgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9TVERCT09MX0ggMSIgPj5jb25m
ZGVmcy5oCj4gLQo+IC1maQo+IC0KPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgiID4mNQo+IC0kYXNfZWNo
b19uICJjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmguLi4gIiA+JjY7IH0KPiAtaWYg
dGVzdCAiJHthY19jdl90eXBlX3VpZF90K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRl
IDxzeXMvdHlwZXMuaD4KPiAtCj4gLV9BQ0VPRgo+IC1pZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVz
dC4kYWNfZXh0IikgMj4mNSB8Cj4gLSAgJEVHUkVQICJ1aWRfdCIgPi9kZXYvbnVsbCAyPiYxOyB0
aGVuIDoKPiAtICBhY19jdl90eXBlX3VpZF90PXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfdHlwZV91
aWRfdD1ubwo+IC1maQo+IC1ybSAtZiBjb25mdGVzdCoKPiAtCj4gLWZpCj4gLXsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIg
PiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfdHlwZV91aWRfdCIgPiY2OyB9Cj4gLWlmIHRlc3QgJGFj
X2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgdWlkX3Qg
aW50IiA+PmNvbmZkZWZzLmgKPiAtCj4gLQo+IC0kYXNfZWNobyAiI2RlZmluZSBnaWRfdCBpbnQi
ID4+Y29uZmRlZnMuaAo+IC0KPiAtZmkKPiAtCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9jX2lubGlu
ZStzZXR9IiA9IHNldDsgdGhlbiA6Cj4gLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAt
ZWxzZQo+IC0gIGFjX2N2X2NfaW5saW5lPW5vCj4gLWZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxp
bmVfXyBfX2lubGluZTsgZG8KPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2lmbmRlZiBfX2NwbHVzcGx1
cwo+IC10eXBlZGVmIGludCBmb29fdDsKPiAtc3RhdGljICRhY19rdyBmb29fdCBzdGF0aWNfZm9v
ICgpIHtyZXR1cm4gMDsgfQo+IC0kYWNfa3cgZm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQo+IC0j
ZW5kaWYKPiAtCj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg
dGhlbiA6Cj4gLSAgYWNfY3ZfY19pbmxpbmU9JGFjX2t3Cj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsg
IiRMSU5FTk8iOyB0aGVuIDoKPiArICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPXllcwo+ICtl
bHNlCj4gKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj1ubwo+ICBmaQo+IC1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICB0
ZXN0ICIkYWNfY3ZfY19pbmxpbmUiICE9IG5vICYmIGJyZWFrCj4gLWRvbmUKPiAtCj4gK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29uZnRlc3Qk
YWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElC
Uwo+ICtmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xp
Yl91dWlkX3V1aWRfY2xlYXIiID4mNjsgfQo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2xpYl91dWlkX3V1
aWRfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKPiArICBsaWJ1dWlkPSJ5Igo+ICBmaQo+IC17ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfaW5s
aW5lIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2OyB9Cj4gCj4gLWNhc2Ug
JGFjX2N2X2NfaW5saW5lIGluCj4gLSAgaW5saW5lIHwgeWVzKSA7Owo+IC0gICopCj4gLSAgICBj
YXNlICRhY19jdl9jX2lubGluZSBpbgo+IC0gICAgICBubykgYWNfdmFsPTs7Cj4gLSAgICAgICop
IGFjX3ZhbD0kYWNfY3ZfY19pbmxpbmU7Owo+IC0gICAgZXNhYwo+IC0gICAgY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgo+IC0jaWZuZGVmIF9fY3BsdXNwbHVzCj4gLSNkZWZpbmUgaW5saW5lICRh
Y192YWwKPiAtI2VuZGlmCj4gLV9BQ0VPRgo+IC0gICAgOzsKPiAtZXNhYwo+IAo+IC1hY19mbl9j
X2ZpbmRfaW50WF90ICIkTElORU5PIiAiMTYiICJhY19jdl9jX2ludDE2X3QiCj4gLWNhc2UgJGFj
X2N2X2NfaW50MTZfdCBpbiAjKAo+IC0gIG5vfHllcykgOzsgIygKPiAtICAqKQo+ICtmaQo+IAo+
IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgaW50MTZfdCAkYWNfY3ZfY19p
bnQxNl90Cj4gLV9BQ0VPRgo+IC07Owo+IC1lc2FjCj4gCj4gLWFjX2ZuX2NfZmluZF9pbnRYX3Qg
IiRMSU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKPiAtY2FzZSAkYWNfY3ZfY19pbnQzMl90
IGluICMoCj4gLSAgbm98eWVzKSA7OyAjKAo+IC0gICopCj4gK2FjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJ1dWlkLmgiICJhY19jdl9oZWFkZXJfdXVpZF9oIiAiJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQiCj4gK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5
ZXM7IHRoZW4gOgo+ICsgIGxpYnV1aWQ9InkiCj4gK2ZpCj4gCj4gLWNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKPiAtI2RlZmluZSBpbnQzMl90ICRhY19jdl9jX2ludDMyX3QKPiAtX0FDRU9GCj4g
LTs7Cj4gLWVzYWMKPiAKPiAtYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjY0IiAiYWNf
Y3ZfY19pbnQ2NF90Igo+IC1jYXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKPiAtICBub3x5ZXMp
IDs7ICMoCj4gLSAgKikKPiAraWYgdGVzdCAiJGxpYnV1aWQiICE9ICJ5IjsgdGhlbiA6Cj4gCj4g
LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBpbnQ2NF90ICRhY19jdl9jX2lu
dDY0X3QKPiAtX0FDRU9GCj4gLTs7Cj4gLWVzYWMKPiArICAgIGFzX2ZuX2Vycm9yICQ/ICJjYW5u
b3QgZmluZCBhIHZhbGlkIHV1aWQgbGlicmFyeSIgIiRMSU5FTk8iIDUKPiAKPiAtYWNfZm5fY19m
aW5kX2ludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX2ludDhfdCIKPiAtY2FzZSAkYWNfY3Zf
Y19pbnQ4X3QgaW4gIygKPiAtICBub3x5ZXMpIDs7ICMoCj4gLSAgKikKPiArZmkKPiAKPiAtY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIGludDhfdCAkYWNfY3ZfY19pbnQ4X3QK
PiAtX0FDRU9GCj4gLTs7Cj4gLWVzYWMKPiAKPiAtYWNfZm5fY19jaGVja190eXBlICIkTElORU5P
IiAibW9kZV90IiAiYWNfY3ZfdHlwZV9tb2RlX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAt
aWYgdGVzdCAieCRhY19jdl90eXBlX21vZGVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICthY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJf
Y3Vyc2VzX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAraWYgdGVzdCAieCRhY19jdl9oZWFk
ZXJfY3Vyc2VzX2giID0geCIieWVzOyB0aGVuIDoKPiAKPiArICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vyc2VzIiA+
JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sY3Vyc2VzLi4uICIgPiY2
OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2N1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhl
biA6Cj4gKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+ICsgIGFjX2NoZWNr
X2xpYl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxjdXJzZXMgICRMSUJTIgo+ICtjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KPiAKPiAtY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIG1vZGVfdCBp
bnQKPiArLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4g
ZXJyb3IuCj4gKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4g
dHlwZSBvZiBhIEdDQwo+ICsgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5
cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwo+ICsjaWZkZWYgX19jcGx1c3BsdXMKPiArZXh0ZXJu
ICJDIgo+ICsjZW5kaWYKPiArY2hhciBjbGVhciAoKTsKPiAraW50Cj4gK21haW4gKCkKPiArewo+
ICtyZXR1cm4gY2xlYXIgKCk7Cj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICt9Cj4gIF9BQ0VPRgo+
IC0KPiAraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xp
Yl9jdXJzZXNfY2xlYXI9eWVzCj4gK2Vsc2UKPiArICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPW5v
Cj4gIGZpCj4gLQo+IC1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2
X3R5cGVfb2ZmX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl90
eXBlX29mZl90IiA9IHgiInllczsgdGhlbiA6Cj4gLQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKPiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0Cj4gK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKPiArZmkKPiAreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3Vy
c2VzX2NsZWFyIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA+JjY7
IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA9IHgiInllczsgdGhlbiA6
Cj4gKyAgY3Vyc2VzPSJ5Igo+ICBlbHNlCj4gLQo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
Cj4gLSNkZWZpbmUgb2ZmX3QgbG9uZyBpbnQKPiAtX0FDRU9GCj4gLQo+ICsgIGN1cnNlcz0ibiIK
PiAgZmkKPiAKPiAtYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAicGlkX3QiICJhY19jdl90
eXBlX3BpZF90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfdHlw
ZV9waWRfdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+ICBlbHNlCj4gKyAgY3Vyc2VzPSJuIgo+ICtm
aQo+IAo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgcGlkX3QgaW50Cj4g
LV9BQ0VPRgo+IAo+IC1maQo+ICthY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5P
IiAibmN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0Igo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giID0geCIieWVzOyB0aGVu
IDoKPiAKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZCIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciBDL0MrKyByZXN0cmljdCBrZXl3b3JkLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNf
Y3ZfY19yZXN0cmljdCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMi
ID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzLi4uICIg
PiY2OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7
IHRoZW4gOgo+ICAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBhY19j
dl9jX3Jlc3RyaWN0PW5vCj4gLSAgICMgVGhlIG9yZGVyIGhlcmUgY2F0ZXJzIHRvIHRoZSBmYWN0
IHRoYXQgQysrIGRvZXMgbm90IHJlcXVpcmUgcmVzdHJpY3QuCj4gLSAgIGZvciBhY19rdyBpbiBf
X3Jlc3RyaWN0IF9fcmVzdHJpY3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7IGRvCj4gLSAgICAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsgIGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxuY3Vyc2VzICAkTElCUyIKPiArY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICAvKiBlbmQgY29uZmRlZnMuaC4g
ICovCj4gLXR5cGVkZWYgaW50ICogaW50X3B0cjsKPiAtICAgICAgIGludCBmb28gKGludF9wdHIg
JGFjX2t3IGlwKSB7Cj4gLSAgICAgICByZXR1cm4gaXBbMF07Cj4gLSAgICAgICB9Cj4gKwo+ICsv
KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K
PiArICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m
IGEgR0NDCj4gKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3Vs
ZCBzdGlsbCBhcHBseS4gICovCj4gKyNpZmRlZiBfX2NwbHVzcGx1cwo+ICtleHRlcm4gIkMiCj4g
KyNlbmRpZgo+ICtjaGFyIGNsZWFyICgpOwo+ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLWludCBz
WzFdOwo+IC0gICAgICAgaW50ICogJGFjX2t3IHQgPSBzOwo+IC0gICAgICAgdFswXSA9IDA7Cj4g
LSAgICAgICByZXR1cm4gZm9vKHQpCj4gK3JldHVybiBjbGVhciAoKTsKPiAgICA7Cj4gICAgcmV0
dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKPiAtICBhY19jdl9jX3Jlc3RyaWN0PSRhY19rdwo+ICtpZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9eWVzCj4g
K2Vsc2UKPiArICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj1ubwo+ICBmaQo+IC1ybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICAg
ICB0ZXN0ICIkYWNfY3ZfY19yZXN0cmljdCIgIT0gbm8gJiYgYnJlYWsKPiAtICAgZG9uZQo+IC0K
PiArcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gKyAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICtMSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfY19yZXN0cmljdCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfY19y
ZXN0cmljdCIgPiY2OyB9Cj4gLQo+IC0gY2FzZSAkYWNfY3ZfY19yZXN0cmljdCBpbgo+IC0gICBy
ZXN0cmljdCkgOzsKPiAtICAgbm8pICRhc19lY2hvICIjZGVmaW5lIHJlc3RyaWN0IC8qKi8iID4+
Y29uZmRlZnMuaAo+IC0gOzsKPiAtICAgKikgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAt
I2RlZmluZSByZXN0cmljdCAkYWNfY3ZfY19yZXN0cmljdAo+IC1fQUNFT0YKPiAtIDs7Cj4gLSBl
c2FjCj4gLQo+IC1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzaXplX3QiICJhY19jdl90
eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X3R5
cGVfc2l6ZV90IiA9IHgiInllczsgdGhlbiA6Cj4gLQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjUK
PiArJGFzX2VjaG8gIiRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPiY2OyB9Cj4gK2lmIHRlc3Qg
IngkYWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKPiArICBuY3Vyc2Vz
PSJ5Igo+ICBlbHNlCj4gLQo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUg
c2l6ZV90IHVuc2lnbmVkIGludAo+IC1fQUNFT0YKPiAtCj4gKyAgbmN1cnNlcz0ibiIKPiAgZmkK
PiAKPiAtYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic3NpemVfdCIgImFjX2N2X3R5cGVf
c3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X3R5cGVf
c3NpemVfdCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+ICBlbHNlCj4gLQo+IC1jYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgc3NpemVfdCBpbnQKPiAtX0FDRU9GCj4gLQo+ICsgIG5j
dXJzZXM9Im4iCj4gIGZpCj4gCj4gLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3Ry
dWN0IHN0YXQiICJzdF9ibGtzaXplIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsa3Np
emUiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3Ry
dWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC1jYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFIDEKPiAt
X0FDRU9GCj4gK2lmIHRlc3QgIiRjdXJzZXMiID0gIm4iICYmIHRlc3QgIiRuY3Vyc2VzIiA9ICJu
IjsgdGhlbiA6Cj4gCj4gKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYSBzdWl0
YWJsZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5FTk8iIDUKPiAKPiAgZmkKPiArIyBQcmVmZXIgbmN1
cnNlcyBvdmVyIGN1cnNlcyBpZiBib3RoIGFyZSBwcmVzZW50Cj4gK2lmIHRlc3QgIiRuY3Vyc2Vz
IiA9ICJ5IjsgdGhlbiA6Cj4gCj4gLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3Ry
dWN0IHN0YXQiICJzdF9ibG9ja3MiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tz
IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVj
dF9zdGF0X3N0X2Jsb2NrcyIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTIDEKPiAtX0FD
RU9GCj4gKyAgICBDVVJTRVNfTElCUz0iLWxuY3Vyc2VzIgo+IAo+ICskYXNfZWNobyAiI2RlZmlu
ZSBJTkNMVURFX0NVUlNFU19IIDxuY3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKPiAKPiAtJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9TVF9CTE9DS1MgMSIgPj5jb25mZGVmcy5oCj4gCj4gIGVsc2UKPiAt
ICBjYXNlICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiAp
IDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9CSlMgZmlsZWJsb2Nrcy4kYWNfb2JqZXh0Igo+IC0g
OzsKPiAtZXNhYwo+IC0KPiAtZmkKPiAtCj4gCj4gLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElO
RU5PIiAic3RydWN0IHN0YXQiICJzdF9yZGV2IiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0
X3JkZXYiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9tZW1iZXJf
c3RydWN0X3N0YXRfc3RfcmRldiIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsgICAgQ1VSU0VTX0xJQlM9
Ii1sY3Vyc2VzIgo+IAo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgSEFW
RV9TVFJVQ1RfU1RBVF9TVF9SREVWIDEKPiAtX0FDRU9GCj4gKyRhc19lY2hvICIjZGVmaW5lIElO
Q0xVREVfQ1VSU0VTX0ggPGN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCj4gCj4gCj4gIGZpCj4gCj4g
LWFjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiMTYiICJhY19jdl9jX3VpbnQxNl90Igo+
IC1jYXNlICRhY19jdl9jX3VpbnQxNl90IGluICMoCj4gLSAgbm98eWVzKSA7OyAjKAo+IC0gICop
Cj4gCj4gCj4gLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSB1aW50MTZfdCAk
YWNfY3ZfY191aW50MTZfdAo+IC1fQUNFT0YKPiAtOzsKPiAtICBlc2FjCj4gCj4gLWFjX2ZuX2Nf
ZmluZF91aW50WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX3VpbnQzMl90Igo+IC1jYXNlICRh
Y19jdl9jX3VpbnQzMl90IGluICMoCj4gLSAgbm98eWVzKSA7OyAjKAo+IC0gICopCj4gCj4gLSRh
c19lY2hvICIjZGVmaW5lIF9VSU5UMzJfVCAxIiA+PmNvbmZkZWZzLmgKPiAKPiAKPiAtY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIHVpbnQzMl90ICRhY19jdl9jX3VpbnQzMl90
Cj4gLV9BQ0VPRgo+IC07Owo+IC0gIGVzYWMKPiAKPiAtYWNfZm5fY19maW5kX3VpbnRYX3QgIiRM
SU5FTk8iICI2NCIgImFjX2N2X2NfdWludDY0X3QiCj4gLWNhc2UgJGFjX2N2X2NfdWludDY0X3Qg
aW4gIygKPiAtICBub3x5ZXMpIDs7ICMoCj4gK2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05G
SUdfc2V0IiAhPSAieHNldCI7IHRoZW4KPiArICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KPiArICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9w
cmVmaXh9cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu
Cj4gK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25maWc7IGFjX3dvcmQ9JDIKPiAr
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KPiAraWYgdGVzdCAiJHthY19jdl9wYXRoX1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4g
Ogo+ICsgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBjYXNlICRQS0df
Q09ORklHIGluCj4gKyAgW1xcL10qIHwgPzpbXFwvXSopCj4gKyAgYWNfY3ZfcGF0aF9QS0dfQ09O
RklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCj4gKyAgOzsKPiAgICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9J
RlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0aF9QS0dfQ09ORklH
PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiArSUZTPSRhc19z
YXZlX0lGUwo+IAo+IC0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDY0X1QgMSIgPj5jb25mZGVmcy5o
Cj4gLQo+ICsgIDs7Cj4gK2VzYWMKPiArZmkKPiArUEtHX0NPTkZJRz0kYWNfY3ZfcGF0aF9QS0df
Q09ORklHCj4gK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgo+ICsgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1Cj4g
KyRhc19lY2hvICIkUEtHX0NPTkZJRyIgPiY2OyB9Cj4gK2Vsc2UKPiArICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQo+ICskYXNfZWNobyAi
bm8iID4mNjsgfQo+ICtmaQo+IAo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZp
bmUgdWludDY0X3QgJGFjX2N2X2NfdWludDY0X3QKPiAtX0FDRU9GCj4gLTs7Cj4gLSAgZXNhYwo+
IAo+IC1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX3VpbnQ4X3Qi
Cj4gLWNhc2UgJGFjX2N2X2NfdWludDhfdCBpbiAjKAo+IC0gIG5vfHllcykgOzsgIygKPiArZmkK
PiAraWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRoZW4KPiArICBhY19wdF9Q
S0dfQ09ORklHPSRQS0dfQ09ORklHCj4gKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJw
a2ctY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KPiArc2V0
IGR1bW15IHBrZy1jb25maWc7IGFjX3dvcmQ9JDIKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQo+ICskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9w
YXRoX2FjX3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICsgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2Cj4gK2Vsc2UKPiArICBjYXNlICRhY19wdF9QS0dfQ09ORklHIGluCj4g
KyAgW1xcL10qIHwgPzpbXFwvXSopCj4gKyAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIk
YWNfcHRfUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCj4gKyAgOzsKPiAgICAqKQo+ICsgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKPiArZm9yIGFzX2RpciBpbiAkUEFUSAo+ICtkbwo+ICsgIElGUz0kYXNfc2F2ZV9J
RlMKPiArICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgo+ICsgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCj4gKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgo+ICsgICAgYWNfY3ZfcGF0aF9hY19wdF9QS0df
Q09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igo+ICsgICAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgPiY1Cj4gKyAgICBicmVhayAyCj4gKyAgZmkKPiArZG9uZQo+ICsgIGRvbmUKPiArSUZT
PSRhc19zYXZlX0lGUwo+IAo+IC0kYXNfZWNobyAiI2RlZmluZSBfVUlOVDhfVCAxIiA+PmNvbmZk
ZWZzLmgKPiAtCj4gLQo+IC1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgdWlu
dDhfdCAkYWNfY3ZfY191aW50OF90Cj4gLV9BQ0VPRgo+IC07Owo+IC0gIGVzYWMKPiAtCj4gLWFj
X2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVfcHRyZGlm
Zl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfdHlwZV9wdHJk
aWZmX3QiID0geCIieWVzOyB0aGVuIDoKPiAtCj4gLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
PiAtI2RlZmluZSBIQVZFX1BUUkRJRkZfVCAxCj4gLV9BQ0VPRgo+IC0KPiAtCj4gKyAgOzsKPiAr
ZXNhYwo+ICtmaQo+ICthY19wdF9QS0dfQ09ORklHPSRhY19jdl9wYXRoX2FjX3B0X1BLR19DT05G
SUcKPiAraWYgdGVzdCAtbiAiJGFjX3B0X1BLR19DT05GSUciOyB0aGVuCj4gKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19wdF9QS0dfQ09ORklH
IiA+JjUKPiArJGFzX2VjaG8gIiRhY19wdF9QS0dfQ09ORklHIiA+JjY7IH0KPiArZWxzZQo+ICsg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gIGZpCj4gCj4gLQo+IC0jIENoZWNrcyBmb3IgbGli
cmFyeSBmdW5jdGlvbnMuCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIGVycm9yX2F0X2xpbmUiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2xpYl9l
cnJvcl9hdF9saW5lK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgo+IC1lbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAo+IC0vKiBlbmQgY29uZmRlZnMuaC4gICovCj4gLSNpbmNsdWRlIDxlcnJvci5oPgo+
IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLWVycm9yX2F0X2xpbmUgKDAsIDAsICIiLCAwLCAiYW4g
ZXJyb3Igb2NjdXJyZWQiKTsKPiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4g
LWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9saWJfZXJy
b3JfYXRfbGluZT15ZXMKPiArICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05GSUciID0geDsgdGhl
bgo+ICsgICAgUEtHX0NPTkZJRz0iIgo+ICsgIGVsc2UKPiArICAgIGNhc2UgJGNyb3NzX2NvbXBp
bGluZzokYWNfdG9vbF93YXJuZWQgaW4KPiAreWVzOikKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQo+ICskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cj4g
K2FjX3Rvb2xfd2FybmVkPXllcyA7Owo+ICtlc2FjCj4gKyAgICBQS0dfQ09ORklHPSRhY19wdF9Q
S0dfQ09ORklHCj4gKyAgZmkKPiAgZWxzZQo+IC0gIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPW5v
Cj4gLWZpCj4gLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+
IC0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArICBQS0dfQ09ORklH
PSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjUK
PiAtJGFzX2VjaG8gIiRhY19jdl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9Cj4gLWlmIHRlc3Qg
JGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lID0gbm87IHRoZW4KPiAtICBjYXNlICIgJExJQk9CSlMg
IiBpbgo+IC0gICoiIGVycm9yLiRhY19vYmpleHQgIiogKSA7Owo+IC0gICopIExJQk9CSlM9IiRM
SUJPQkpTIGVycm9yLiRhY19vYmpleHQiCj4gLSA7Owo+IC1lc2FjCj4gCj4gIGZpCj4gLQo+IC1m
b3IgYWNfaGVhZGVyIGluIHZmb3JrLmgKPiAtZG8gOgo+IC0gIGFjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJ2Zm9yay5oIiAiYWNfY3ZfaGVhZGVyX3Zmb3JrX2giICIkYWNf
aW5jbHVkZXNfZGVmYXVsdCIKPiAtaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdmZvcmtfaCIgPSB4
IiJ5ZXM7IHRoZW4gOgo+IC0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBI
QVZFX1ZGT1JLX0ggMQo+IC1fQUNFT0YKPiAtCj4gK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsg
dGhlbgo+ICsgICAgICAgX3BrZ19taW5fdmVyc2lvbj0wLjkuMAo+ICsgICAgICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0
IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQo+ICskYXNfZWNob19uICJjaGVj
a2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24uLi4g
IiA+JjY7IH0KPiArICAgICAgIGlmICRQS0dfQ09ORklHIC0tYXRsZWFzdC1wa2djb25maWctdmVy
c2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgo+ICsgICAgICAgICAgICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2Vj
aG8gInllcyIgPiY2OyB9Cj4gKyAgICAgICBlbHNlCj4gKyAgICAgICAgICAgICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19l
Y2hvICJubyIgPiY2OyB9Cj4gKyAgICAgICAgICAgICAgIFBLR19DT05GSUc9IiIKPiArICAgICAg
IGZpCj4gIGZpCj4gCj4gLWRvbmUKPiAtCj4gLWZvciBhY19mdW5jIGluIGZvcmsgdmZvcmsKPiAt
ZG8gOgo+IC0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFz
X3RyX3NoYAo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19h
Y192YXIiCj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVu
IDoKPiAtICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgYCRhc19lY2hvICJI
QVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKPiAtX0FDRU9GCj4gLQo+IC1maQo+IC1kb25l
Cj4gK3BrZ19mYWlsZWQ9bm8KPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgZ2xpYiIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBn
bGliLi4uICIgPiY2OyB9Cj4gCj4gLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrIiA9IHh5ZXM7
IHRoZW4KPiAtICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciB3b3JraW5nIGZvcmsiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29y
a2luZyBmb3JrLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19mb3JrX3dvcmtz
K3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1l
bHNlCj4gLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFj
X2N2X2Z1bmNfZm9ya193b3Jrcz1jcm9zcwo+ICtpZiB0ZXN0IC1uICIkZ2xpYl9DRkxBR1MiOyB0
aGVuCj4gKyAgICBwa2dfY3ZfZ2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIKPiArIGVsaWYgdGVz
dCAtbiAiJFBLR19DT05GSUciOyB0aGVuCj4gKyAgICBpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyIg
JiYgXAo+ICsgICAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwk
UEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9ID4mNQo+
ICsgICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1
Cj4gKyAgYWNfc3RhdHVzPSQ/Cj4gKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Cj4gKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsg
dGhlbgo+ICsgIHBrZ19jdl9nbGliX0NGTEFHUz1gJFBLR19DT05GSUcgLS1jZmxhZ3MgImdsaWIt
Mi4wIiAyPi9kZXYvbnVsbGAKPiAgZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVk
ZXNfZGVmYXVsdAo+IC1pbnQKPiAtbWFpbiAoKQo+IC17Cj4gLQo+IC0gICAgICAgICAvKiBCeSBS
dWVkaWdlciBLdWhsbWFubi4gKi8KPiAtICAgICAgICAgcmV0dXJuIGZvcmsgKCkgPCAwOwo+IC0K
PiAtICA7Cj4gLSAgcmV0dXJuIDA7Cj4gLX0KPiAtX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKPiArICBw
a2dfZmFpbGVkPXllcwo+ICtmaQo+ICsgZWxzZQo+ICsgICAgcGtnX2ZhaWxlZD11bnRyaWVkCj4g
K2ZpCj4gK2lmIHRlc3QgLW4gIiRnbGliX0xJQlMiOyB0aGVuCj4gKyAgICBwa2dfY3ZfZ2xpYl9M
SUJTPSIkZ2xpYl9MSUJTIgo+ICsgZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KPiAr
ICAgIGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCj4gKyAgICB7IHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQt
ZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1Cj4gKyAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0t
cHJpbnQtZXJyb3JzICJnbGliLTIuMCIpIDI+JjUKPiArICBhY19zdGF0dXM9JD8KPiArICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUK
PiArICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuCj4gKyAgcGtnX2N2X2dsaWJfTElCUz1g
JFBLR19DT05GSUcgLS1saWJzICJnbGliLTIuMCIgMj4vZGV2L251bGxgCj4gIGVsc2UKPiAtICBh
Y19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KPiArICBwa2dfZmFpbGVkPXllcwo+ICBmaQo+IC1ybSAt
ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBcCj4gLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0
LiRhY19leHQKPiArIGVsc2UKPiArICAgIHBrZ19mYWlsZWQ9dW50cmllZAo+ICBmaQo+IAo+IC1m
aQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFj
X2N2X2Z1bmNfZm9ya193b3JrcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVuY19mb3JrX3dv
cmtzIiA+JjY7IH0KPiAKPiArCj4gK2lmIHRlc3QgJHBrZ19mYWlsZWQgPSB5ZXM7IHRoZW4KPiAr
ICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1Cj4gKyRhc19lY2hvICJubyIgPiY2OyB9Cj4gKwo+ICtpZiAkUEtHX0NPTkZJRyAtLWF0
bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgo+ICsgICAgICAgIF9wa2dfc2hvcnRf
ZXJyb3JzX3N1cHBvcnRlZD15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz0k
YWNfY3ZfZnVuY19mb3JrCj4gKyAgICAgICAgX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkPW5v
Cj4gIGZpCj4gLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhl
bgo+IC0gIGNhc2UgJGhvc3QgaW4KPiAtICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3Bw
KikKPiAtICAgICAgIyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZlIG9ubHkgYSBkdW1t
eSBmb3JrKCkgc3R1Ygo+IC0gICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KPiAtICAgICAg
OzsKPiAtICAgICopCj4gLSAgICAgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKPiAtICAgICAg
OzsKPiAtICBlc2FjCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ug
b2YgY3Jvc3MgY29tcGlsYXRpb24iID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBy
ZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29t
cGlsYXRpb24iID4mMjt9Cj4gLWZpCj4gLWFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1
bmNfdmZvcmsKPiAtaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrIiA9IHh5ZXM7IHRoZW4KPiAt
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3
b3JraW5nIHZmb3JrIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgdmZv
cmsuLi4gIiA+JjY7IH0KPiAtaWYgdGVzdCAiJHthY19jdl9mdW5jX3Zmb3JrX3dvcmtzK3NldH0i
ID0gc2V0OyB0aGVuIDoKPiAtICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4g
LSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3M9Y3Jvc3MKPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAtLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0vKiBUaGFu
a3MgdG8gUGF1bCBFZ2dlcnQgZm9yIHRoaXMgdGVzdC4gICovCj4gLSRhY19pbmNsdWRlc19kZWZh
dWx0Cj4gLSNpbmNsdWRlIDxzeXMvd2FpdC5oPgo+IC0jaWZkZWYgSEFWRV9WRk9SS19ICj4gLSMg
aW5jbHVkZSA8dmZvcmsuaD4KPiAtI2VuZGlmCj4gLS8qIE9uIHNvbWUgc3BhcmMgc3lzdGVtcywg
Y2hhbmdlcyBieSB0aGUgY2hpbGQgdG8gbG9jYWwgYW5kIGluY29taW5nCj4gLSAgIGFyZ3VtZW50
IHJlZ2lzdGVycyBhcmUgcHJvcGFnYXRlZCBiYWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGls
ZXIKPiAtICAgaXMgdG9sZCBhYm91dCB0aGlzIHdpdGggI2luY2x1ZGUgPHZmb3JrLmg+LCBidXQg
c29tZSBjb21waWxlcnMKPiAtICAgKGUuZy4gZ2NjIC1PKSBkb24ndCBncm9rIDx2Zm9yay5oPi4g
IFRlc3QgZm9yIHRoaXMgYnkgdXNpbmcgYQo+IC0gICBzdGF0aWMgdmFyaWFibGUgd2hvc2UgYWRk
cmVzcyBpcyBwdXQgaW50byBhIHJlZ2lzdGVyIHRoYXQgaXMKPiAtICAgY2xvYmJlcmVkIGJ5IHRo
ZSB2Zm9yay4gICovCj4gLXN0YXRpYyB2b2lkCj4gLSNpZmRlZiBfX2NwbHVzcGx1cwo+IC1zcGFy
Y19hZGRyZXNzX3Rlc3QgKGludCBhcmcpCj4gLSMgZWxzZQo+IC1zcGFyY19hZGRyZXNzX3Rlc3Qg
KGFyZykgaW50IGFyZzsKPiAtI2VuZGlmCj4gLXsKPiAtICBzdGF0aWMgcGlkX3QgY2hpbGQ7Cj4g
LSAgaWYgKCFjaGlsZCkgewo+IC0gICAgY2hpbGQgPSB2Zm9yayAoKTsKPiAtICAgIGlmIChjaGls
ZCA8IDApIHsKPiAtICAgICAgcGVycm9yICgidmZvcmsiKTsKPiAtICAgICAgX2V4aXQoMik7Cj4g
LSAgICB9Cj4gLSAgICBpZiAoIWNoaWxkKSB7Cj4gLSAgICAgIGFyZyA9IGdldHBpZCgpOwo+IC0g
ICAgICB3cml0ZSgtMSwgIiIsIDApOwo+IC0gICAgICBfZXhpdCAoYXJnKTsKPiAtICAgIH0KPiAt
ICB9Cj4gLX0KPiArICAgICAgICBpZiB0ZXN0ICRfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQg
PSB5ZXM7IHRoZW4KPiArICAgICAgICAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJ
RyAtLXNob3J0LWVycm9ycyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCj4gKyAgICAg
ICAgZWxzZQo+ICsgICAgICAgICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0t
cHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKPiArICAgICAgICBmaQo+ICsgICAgICAgIyBQ
dXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdz
Cj4gKyAgICAgICBlY2hvICIkZ2xpYl9QS0dfRVJST1JTIiA+JjUKPiAKPiAtaW50Cj4gLW1haW4g
KCkKPiAtewo+IC0gIHBpZF90IHBhcmVudCA9IGdldHBpZCAoKTsKPiAtICBwaWRfdCBjaGlsZDsK
PiAtCj4gLSAgc3BhcmNfYWRkcmVzc190ZXN0ICgwKTsKPiAtCj4gLSAgY2hpbGQgPSB2Zm9yayAo
KTsKPiAtCj4gLSAgaWYgKGNoaWxkID09IDApIHsKPiAtICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0
ZXN0IGZvciBzcGFyYyB2Zm9yayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKPiAtICAgICAgIHRl
c3QgdXNlcyBsb3RzIG9mIGxvY2FsIHZhcmlhYmxlcywgYXQgbGVhc3QgYXMgbWFueSBsb2NhbAo+
IC0gICAgICAgdmFyaWFibGVzIGFzIG1haW4gaGFzIGFsbG9jYXRlZCBzbyBmYXIgaW5jbHVkaW5n
IGNvbXBpbGVyCj4gLSAgICAgICB0ZW1wb3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9y
IGdjYyAxLjQwLjMgb24gYSBTb2xhcmlzCj4gLSAgICAgICA0LjEuMyBzcGFyYywgYnV0IHdlIHVz
ZSA4IHRvIGJlIHNhZmUuICBBIGJ1Z2d5IGNvbXBpbGVyIHNob3VsZAo+IC0gICAgICAgcmV1c2Ug
dGhlIHJlZ2lzdGVyIG9mIHBhcmVudCBmb3Igb25lIG9mIHRoZSBsb2NhbCB2YXJpYWJsZXMsCj4g
LSAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRoYXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJl
IHVzZWQgYW55IG1vcmUKPiAtICAgICAgIGluIHRoaXMgcm91dGluZS4gIEFzc2lnbmluZyB0byB0
aGUgbG9jYWwgdmFyaWFibGUgd2lsbCB0aHVzCj4gLSAgICAgICBtdW5nZSBwYXJlbnQgaW4gdGhl
IHBhcmVudCBwcm9jZXNzLiAgKi8KPiAtICAgIHBpZF90Cj4gLSAgICAgIHAgPSBnZXRwaWQoKSwg
cDEgPSBnZXRwaWQoKSwgcDIgPSBnZXRwaWQoKSwgcDMgPSBnZXRwaWQoKSwKPiAtICAgICAgcDQg
PSBnZXRwaWQoKSwgcDUgPSBnZXRwaWQoKSwgcDYgPSBnZXRwaWQoKSwgcDcgPSBnZXRwaWQoKTsK
PiAtICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3IGFyZSBsaXZlOyBvdGhl
cndpc2UsIGl0IG1pZ2h0Cj4gLSAgICAgICB1c2UgdGhlIHNhbWUgaGFyZHdhcmUgcmVnaXN0ZXIg
Zm9yIGFsbCA4IGxvY2FsIHZhcmlhYmxlcy4gICovCj4gLSAgICBpZiAocCAhPSBwMSB8fCBwICE9
IHAyIHx8IHAgIT0gcDMgfHwgcCAhPSBwNAo+IC0gICAgICAgfHwgcCAhPSBwNSB8fCBwICE9IHA2
IHx8IHAgIT0gcDcpCj4gLSAgICAgIF9leGl0KDEpOwo+IC0KPiAtICAgIC8qIE9uIHNvbWUgc3lz
dGVtcyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50Cj4gLSAg
ICAgICBmcm9tIGNoaWxkIGZpbGUgZGVzY3JpcHRvcnMuICBJZiB0aGUgY2hpbGQgY2xvc2VzIGEg
ZGVzY3JpcHRvcgo+IC0gICAgICAgYmVmb3JlIGl0IGV4ZWNzIG9yIGV4aXRzLCB0aGlzIG11bmdl
cyB0aGUgcGFyZW50J3MgZGVzY3JpcHRvcgo+IC0gICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRo
aXMgYnkgY2xvc2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KPiAtICAgIF9leGl0KGNsb3Nl
KGZpbGVubyhzdGRvdXQpKSAhPSAwKTsKPiAtICB9IGVsc2Ugewo+IC0gICAgaW50IHN0YXR1czsK
PiAtICAgIHN0cnVjdCBzdGF0IHN0Owo+ICsgICAgICAgYXNfZm5fZXJyb3IgJD8gIlBhY2thZ2Ug
cmVxdWlyZW1lbnRzIChnbGliLTIuMCkgd2VyZSBub3QgbWV0Ogo+IAo+IC0gICAgd2hpbGUgKHdh
aXQoJnN0YXR1cykgIT0gY2hpbGQpCj4gLSAgICAgIDsKPiAtICAgIHJldHVybiAoCj4gLSAgICAg
ICAgLyogV2FzIHRoZXJlIHNvbWUgcHJvYmxlbSB3aXRoIHZmb3JraW5nPyAgKi8KPiAtICAgICAg
ICBjaGlsZCA8IDAKPiArJGdsaWJfUEtHX0VSUk9SUwo+IAo+IC0gICAgICAgIC8qIERpZCB0aGUg
Y2hpbGQgZmFpbD8gIChUaGlzIHNob3VsZG4ndCBoYXBwZW4uKSAgKi8KPiAtICAgICAgICB8fCBz
dGF0dXMKPiArQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1l
bnQgdmFyaWFibGUgaWYgeW91Cj4gK2luc3RhbGxlZCBzb2Z0d2FyZSBpbiBhIG5vbi1zdGFuZGFy
ZCBwcmVmaXguCj4gCj4gLSAgICAgICAgLyogRGlkIHRoZSB2Zm9yay9jb21waWxlciBidWcgb2Nj
dXI/ICAqLwo+IC0gICAgICAgIHx8IHBhcmVudCAhPSBnZXRwaWQoKQo+ICtBbHRlcm5hdGl2ZWx5
LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCj4gK2Fu
ZCBnbGliX0xJQlMgdG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgo+ICtTZWUg
dGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy4iICIkTElORU5PIiA1Cj4g
K2VsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KPiArICAgICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cj4gKyRhc19l
Y2hvICJubyIgPiY2OyB9Cj4gKyAgICAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKPiArJGFzX2VjaG8gIiRhc19t
ZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQo+ICthc19mbl9lcnJvciAkPyAiVGhlIHBr
Zy1jb25maWcgc2NyaXB0IGNvdWxkIG5vdCBiZSBmb3VuZCBvciBpcyB0b28gb2xkLiAgTWFrZSBz
dXJlIGl0Cj4gK2lzIGluIHlvdXIgUEFUSCBvciBzZXQgdGhlIFBLR19DT05GSUcgZW52aXJvbm1l
bnQgdmFyaWFibGUgdG8gdGhlIGZ1bGwKPiArcGF0aCB0byBwa2ctY29uZmlnLgo+IAo+IC0gICAg
ICAgIC8qIERpZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1cj8gICovCj4gLSAgICAgICAg
fHwgZnN0YXQoZmlsZW5vKHN0ZG91dCksICZzdCkgIT0gMAo+IC0gICAgICAgICk7Cj4gLSAgfQo+
IC19Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAt
ICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPXllcwo+ICtBbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNl
dCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCj4gK2FuZCBnbGliX0xJQlMg
dG8gYXZvaWQgdGhlIG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgo+ICtTZWUgdGhlIHBrZy1jb25m
aWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy4KPiArCj4gK1RvIGdldCBwa2ctY29uZmlnLCBz
ZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVkZXNrdG9wLm9yZy8+Lgo+ICtTZWUgXGBjb25maWcu
bG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KPiAgZWxzZQo+IC0gIGFjX2N2
X2Z1bmNfdmZvcmtfd29ya3M9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25m
dGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+IC0gIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4gLWZpCj4gKyAgICAg
ICBnbGliX0NGTEFHUz0kcGtnX2N2X2dsaWJfQ0ZMQUdTCj4gKyAgICAgICBnbGliX0xJQlM9JHBr
Z19jdl9nbGliX0xJQlMKPiArICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKPiArJGFzX2VjaG8gInllcyIgPiY2OyB9Cj4gCj4g
IGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVuY192Zm9y
a193b3JrcyIgPiY2OyB9Cj4gCj4gLWZpOwo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193
b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KPiAtICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9m
dW5jX3Zmb3JrCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBX
QVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9m
IGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUKPiAtJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogcmVz
dWx0ICRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21w
aWxhdGlvbiIgPiYyO30KPiArIyBDaGVjayBsaWJyYXJ5IHBhdGgKPiAraWYgdGVzdCAiXCR7ZXhl
Y19wcmVmaXh9L2xpYiIgPSAiJGxpYmRpciI7IHRoZW4gOgo+ICsgIGlmIHRlc3QgIiRleGVjX3By
ZWZpeCIgPSAiTk9ORSIgJiYgdGVzdCAiJHByZWZpeCIgIT0gIk5PTkUiOyB0aGVuIDoKPiArICBl
eGVjX3ByZWZpeD0kcHJlZml4Cj4gIGZpCj4gKyAgICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0g
Ik5PTkUiOyB0aGVuIDoKPiArICBleGVjX3ByZWZpeD0kYWNfZGVmYXVsdF9wcmVmaXgKPiArZmkK
PiArICAgIGlmIHRlc3QgLWQgIiR7ZXhlY19wcmVmaXh9L2xpYjY0IjsgdGhlbiA6Cj4gCj4gLWlm
IHRlc3QgIngkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCj4gLQo+IC0kYXNf
ZWNobyAiI2RlZmluZSBIQVZFX1dPUktJTkdfVkZPUksgMSIgPj5jb25mZGVmcy5oCj4gKyAgICAg
ICAgTElCX1BBVEg9ImxpYjY0Igo+IAo+ICBlbHNlCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIHZm
b3JrIGZvcmsiID4+Y29uZmRlZnMuaAo+ICsgICAgICAgIExJQl9QQVRIPSJsaWIiCj4gCj4gIGZp
Cj4gLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KPiAKPiAt
JGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX0ZPUksgMSIgPj5jb25mZGVmcy5oCj4gK2Vs
c2UKPiAKPiAtZmkKPiArICAgIExJQl9QQVRIPSIke2xpYmRpcjpgZXhwciBsZW5ndGggIiRleGVj
X3ByZWZpeCIgKyAxYH0iCj4gCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFy
Z2UgZmlsZXMiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgX0xBUkdFRklMRV9TT1VS
Q0UgdmFsdWUgbmVlZGVkIGZvciBsYXJnZSBmaWxlcy4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIk
e2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlK3NldH0iID0gc2V0OyB0aGVuIDoKPiAtICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+IC1lbHNlCj4gLSAgd2hpbGUgOjsgZG8KPiAtICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8KPiAtICAg
ICAjaW5jbHVkZSA8c3RkaW8uaD4KPiAtaW50Cj4gLW1haW4gKCkKPiAtewo+IC1pbnQgKCpmcCkg
KEZJTEUgKiwgb2ZmX3QsIGludCkgPSBmc2Vla287Cj4gLSAgICAgcmV0dXJuIGZzZWVrbyAoc3Rk
aW4sIDAsIDApICYmIGZwIChzdGRpbiwgMCwgMCk7Cj4gLSAgOwo+IC0gIHJldHVybiAwOwo+IC19
Cj4gLV9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAg
YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9bm87IGJyZWFrCj4gLWZpCj4gLXJtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNfZXhl
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0Cj4gLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2RlZmluZSBfTEFSR0VG
SUxFX1NPVVJDRSAxCj4gLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCj4g
LSAgICAgI2luY2x1ZGUgPHN0ZGlvLmg+Cj4gLWludAo+IC1tYWluICgpCj4gLXsKPiAtaW50ICgq
ZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwo+IC0gICAgIHJldHVybiBmc2Vla28g
KHN0ZGluLCAwLCAwKSAmJiBmcCAoc3RkaW4sIDAsIDApOwo+IC0gIDsKPiAtICByZXR1cm4gMDsK
PiAtfQo+IC1fQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+
IC0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPTE7IGJyZWFrCj4gIGZpCj4gLXJtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+IC0gICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiAtICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT11
bmtub3duCj4gLSAgYnJlYWsKPiAtZG9uZQo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+
JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2OyB9Cj4gLWNh
c2UgJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIGluICMoCj4gLSAgbm8gfCB1bmtub3duKSA7
Owo+IC0gICopCj4gLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBfTEFSR0VG
SUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UKPiAtX0FDRU9GCj4gLTs7Cj4g
LWVzYWMKPiAtcm0gLXJmIGNvbmZ0ZXN0Kgo+IC0KPiAtIyBXZSB1c2VkIHRvIHRyeSBkZWZpbmlu
ZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5kIGEgYnVnCj4gLSMgaW4gZ2xp
YmMgMi4xLjMsIGJ1dCB0aGF0IGJyZWFrcyB0b28gbWFueSBvdGhlciB0aGluZ3MuCj4gLSMgSWYg
eW91IHdhbnQgZnNlZWtvIGFuZCBmdGVsbG8gd2l0aCBnbGliYywgdXBncmFkZSB0byBhIGZpeGVk
IGdsaWJjLgo+IC1pZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSAhPSB1bmtub3du
OyB0aGVuCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+Y29uZmRlZnMu
aAo+IAo+IC1maQo+ICsjIENoZWNrcyBmb3IgbGlicmFyaWVzLgo+ICthY19mbl9jX2NoZWNrX2hl
YWRlcl9tb25ncmVsICIkTElORU5PIiAiYnpsaWIuaCIgImFjX2N2X2hlYWRlcl9iemxpYl9oIiAi
JGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2J6bGliX2gi
ID0geCIieWVzOyB0aGVuIDoKPiAKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVzIHRyYWlsaW5n
IHNsYXNoIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0
bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2
X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaytzZXR9IiA9IHNldDsgdGhl
biA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyIiA+JjUKPiArJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyLi4uICIgPiY2OyB9Cj4gK2lm
IHRlc3QgIiR7YWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCtzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIHJtIC1m
IGNvbmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCj4gLWVjaG8gPmNvbmZ0ZXN0LmZpbGUKPiAtaWYg
dGVzdCAiJGFzX2xuX3MiID0gImxuIC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0ZXN0
LnN5bTsgdGhlbgo+IC0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoK
PiAtICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KPiAt
ZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAr
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4gK0xJQlM9Ii1sYnoyICAkTElCUyIKPiAr
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICAvKiBlbmQgY29u
ZmRlZnMuaC4gICovCj4gLSRhY19pbmNsdWRlc19kZWZhdWx0Cj4gKwo+ICsvKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KPiArICAgVXNlIGNo
YXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCj4gKyAg
IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs
eS4gICovCj4gKyNpZmRlZiBfX2NwbHVzcGx1cwo+ICtleHRlcm4gIkMiCj4gKyNlbmRpZgo+ICtj
aGFyIEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwo+ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLXN0
cnVjdCBzdGF0IHNidWY7Cj4gLSAgICAgLyogTGludXggd2lsbCBkZXJlZmVyZW5jZSB0aGUgc3lt
bGluayBhbmQgZmFpbCwgYXMgcmVxdWlyZWQgYnkgUE9TSVguCj4gLSAgICAgICBUaGF0IGlzIGJl
dHRlciBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBtZWFucyB3ZSB3aWxsIG5vdAo+IC0gICAgICAgaGF2
ZSB0byBjb21waWxlIGFuZCB1c2UgdGhlIGxzdGF0IHdyYXBwZXIuICAqLwo+IC0gICAgIHJldHVy
biBsc3RhdCAoImNvbmZ0ZXN0LnN5bS8iLCAmc2J1ZikgPT0gMDsKPiArcmV0dXJuIEJaMl9iekRl
Y29tcHJlc3NJbml0ICgpOwo+ICAgIDsKPiAgICByZXR1cm4gMDsKPiAgfQo+ICBfQUNFT0YKPiAt
aWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfZnVuY19sc3Rh
dF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXllcwo+IC1lbHNlCj4gLSAgYWNfY3ZfZnVu
Y19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCj4gLWZpCj4gLXJtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAo+IC1maQo+IC0KPiAraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+
ICsgIGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9eWVzCj4gIGVsc2UKPiAtICAj
IElmIHRoZSBgbG4gLXMnIGNvbW1hbmQgZmFpbGVkLCB0aGVuIHdlIHByb2JhYmx5IGRvbid0IGV2
ZW4KPiAtICAjIGhhdmUgYW4gbHN0YXQgZnVuY3Rpb24uCj4gLSAgYWNfY3ZfZnVuY19sc3RhdF9k
ZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCj4gKyAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpE
ZWNvbXByZXNzSW5pdD1ubwo+ICBmaQo+IC1ybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmls
ZQo+IC0KPiArcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4g
KyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICtMSUJTPSRhY19jaGVj
a19saWJfc2F2ZV9MSUJTCj4gK2ZpCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY1
Cj4gKyRhc19lY2hvICIkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPiY2OyB9
Cj4gK2lmIHRlc3QgIngkYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPSB4IiJ5
ZXM7IHRoZW4gOgo+ICsgIHpsaWI9IiR6bGliIC1ESEFWRV9CWkxJQiAtbGJ6MiIKPiAgZmkKPiAt
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9m
dW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID4mNQo+IC0kYXNfZWNobyAi
JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9Cj4g
LQo+IC10ZXN0ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsg
PSB5ZXMgJiYKPiAKPiAtY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIExTVEFU
X0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LIDEKPiAtX0FDRU9GCj4gCj4gK2ZpCj4gCj4gLWlmIHRl
c3QgIngkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rIiA9IHhu
bzsgdGhlbgo+IC0gIGNhc2UgIiAkTElCT0JKUyAiIGluCj4gLSAgKiIgbHN0YXQuJGFjX29iamV4
dCAiKiApIDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9CSlMgbHN0YXQuJGFjX29iamV4dCIKPiAt
IDs7Cj4gLWVzYWMKPiAKPiAtZmkKPiArYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJ
TkVOTyIgImx6bWEuaCIgImFjX2N2X2hlYWRlcl9sem1hX2giICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKPiAraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHptYV9oIiA9IHgiInllczsgdGhlbiA6Cj4g
Cj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hl
dGhlciBzeXMvdHlwZXMuaCBkZWZpbmVzIG1ha2VkZXYiID4mNQo+IC0kYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldi4uLiAiID4mNjsgfQo+IC1p
ZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2K3NldH0iID0gc2V0OyB0
aGVuIDoKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEiID4mNQo+ICskYXNfZWNob19uICJj
aGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAtbGx6bWEuLi4gIiA+JjY7IH0KPiAr
aWYgdGVzdCAiJHthY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyK3NldH0iID0gc2V0
OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICsgIGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxsem1hICAkTElCUyIKPiArY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAo+ICAvKiBlbmQgY29uZmRlZnMuaC4gICov
Cj4gLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KPiArCj4gKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50
ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2UgY2hhciBiZWNhdXNl
IGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiArICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiAr
I2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiArI2VuZGlmCj4gK2NoYXIgbHptYV9z
dHJlYW1fZGVjb2RlciAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC1yZXR1cm4gbWFrZWRl
digwLCAwKTsKPiArcmV0dXJuIGx6bWFfc3RyZWFtX2RlY29kZXIgKCk7Cj4gICAgOwo+ICAgIHJl
dHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+ICBpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6Cj4gLSAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXY9eWVzCj4gKyAgYWNf
Y3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2hl
YWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2PW5vCj4gKyAgYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJl
YW1fZGVjb2Rlcj1ubwo+ICBmaQo+ICBybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKPiAgICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4g
LQo+IC1maQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjUKPiAtJGFzX2VjaG8gIiRh
Y19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIgPiY2OyB9Cj4gLQo+IC1pZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiA9IG5vOyB0aGVuCj4gLWFjX2ZuX2NfY2hl
Y2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvbWtkZXYuaCIgImFjX2N2X2hlYWRlcl9z
eXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hl
YWRlcl9zeXNfbWtkZXZfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZp
bmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCj4gLQo+ICtMSUJTPSRhY19jaGVja19s
aWJfc2F2ZV9MSUJTCj4gIGZpCj4gLQo+IC0KPiAtCj4gLSAgaWYgdGVzdCAkYWNfY3ZfaGVhZGVy
X3N5c19ta2Rldl9oID0gbm87IHRoZW4KPiAtICAgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdy
ZWwgIiRMSU5FTk8iICJzeXMvc3lzbWFjcm9zLmgiICJhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jv
c19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N5
c19zeXNtYWNyb3NfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUg
TUFKT1JfSU5fU1lTTUFDUk9TIDEiID4+Y29uZmRlZnMuaAo+IC0KPiAreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbHptYV9sem1hX3N0
cmVhbV9kZWNvZGVyIiA+JjUKPiArJGFzX2VjaG8gIiRhY19jdl9saWJfbHptYV9sem1hX3N0cmVh
bV9kZWNvZGVyIiA+JjY7IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJfbHptYV9sem1hX3N0cmVh
bV9kZWNvZGVyIiA9IHgiInllczsgdGhlbiA6Cj4gKyAgemxpYj0iJHpsaWIgLURIQVZFX0xaTUEg
LWxsem1hIgo+ICBmaQo+IAo+IAo+IC0gIGZpCj4gIGZpCj4gCj4gLWZvciBhY19oZWFkZXIgaW4g
c3RkbGliLmgKPiAtZG8gOgo+IC0gIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5F
Tk8iICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0Igo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgPSB4IiJ5ZXM7IHRoZW4g
Ogo+IC0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKPiAtI2RlZmluZSBIQVZFX1NURExJQl9I
IDEKPiAtX0FDRU9GCj4gLQo+IC1maQo+IAo+IC1kb25lCj4gK2FjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJsem8vbHpvMXguaCIgImFjX2N2X2hlYWRlcl9sem9fbHpvMXhf
aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9sem9f
bHpvMXhfaCIgPSB4IiJ5ZXM7IHRoZW4gOgo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxvYyIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxv
Yy4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCtz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKPiArJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yLi4uICIgPiY2
OyB9Cj4gK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcytzZXR9IiA9
IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0g
IGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKPiAtICBhY19jdl9mdW5j
X21hbGxvY18wX25vbm51bGw9bm8KPiAtZWxzZQo+IC0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCj4g
K0xJQlM9Ii1sbHpvMiAgJExJQlMiCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0jaWYgZGVmaW5lZCBTVERD
X0hFQURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICj4gLSMgaW5jbHVkZSA8c3RkbGliLmg+
Cj4gLSNlbHNlCj4gLWNoYXIgKm1hbGxvYyAoKTsKPiAtI2VuZGlmCj4gCj4gKy8qIE92ZXJyaWRl
IGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAr
ICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFw
cGx5LiAgKi8KPiArI2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiArI2VuZGlmCj4g
K2NoYXIgbHpvMXhfZGVjb21wcmVzcyAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC1yZXR1
cm4gISBtYWxsb2MgKDApOwo+ICtyZXR1cm4gbHpvMXhfZGVjb21wcmVzcyAoKTsKPiAgICA7Cj4g
ICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9GCj4gLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVO
TyI7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD15ZXMKPiAraWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xpYl9sem8yX2x6bzF4
X2RlY29tcHJlc3M9eWVzCj4gIGVsc2UKPiAtICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9
bm8KPiArICBhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPW5vCj4gIGZpCj4gLXJtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3Qu
JGFjX2V4dAo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
PiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKPiAgZmkKPiAtCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIg
PiY1Cj4gKyRhc19lY2hvICIkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPiY2OyB9
Cj4gK2lmIHRlc3QgIngkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7
IHRoZW4gOgo+ICsgIHpsaWI9IiR6bGliIC1ESEFWRV9MWk8xWCAtbGx6bzIiCj4gIGZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVu
Y19tYWxsb2NfMF9ub25udWxsIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9mdW5jX21hbGxvY18w
X25vbm51bGwiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwg
PSB5ZXM7IHRoZW4gOgo+IC0KPiAtJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0MgMSIgPj5j
b25mZGVmcy5oCj4gLQo+IC1lbHNlCj4gLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxMT0Mg
MCIgPj5jb25mZGVmcy5oCj4gLQo+IC0gICBjYXNlICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIG1h
bGxvYy4kYWNfb2JqZXh0ICIqICkgOzsKPiAtICAqKSBMSUJPQkpTPSIkTElCT0JKUyBtYWxsb2Mu
JGFjX29iamV4dCIKPiAtIDs7Cj4gLWVzYWMKPiAtCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIG1h
bGxvYyBycGxfbWFsbG9jIiA+PmNvbmZkZWZzLmgKPiAKPiAgZmkKPiAKPiAKPiAteyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBh
bmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZCIgPiY1Cj4gLSRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBib3RoIGJlIGluY2x1ZGVk
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3RpbWUrc2V0fSIgPSBzZXQ7
IHRoZW4gOgo+ICsKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8iID4mNQo+ICskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8uLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9s
aWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAo+ICsgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxh
aW8gICRMSUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
Cj4gIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtI2luY2x1ZGUgPHN5cy90eXBlcy5oPgo+IC0j
aW5jbHVkZSA8c3lzL3RpbWUuaD4KPiAtI2luY2x1ZGUgPHRpbWUuaD4KPiAKPiArLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gKyAgIFVz
ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+
ICsgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg
YXBwbHkuICAqLwo+ICsjaWZkZWYgX19jcGx1c3BsdXMKPiArZXh0ZXJuICJDIgo+ICsjZW5kaWYK
PiArY2hhciBpb19zZXR1cCAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC1pZiAoKHN0cnVj
dCB0bSAqKSAwKQo+IC1yZXR1cm4gMDsKPiArcmV0dXJuIGlvX3NldHVwICgpOwo+ICAgIDsKPiAg
ICByZXR1cm4gMDsKPiAgfQo+ICBfQUNFT0YKPiAtaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2hlYWRlcl90aW1lPXllcwo+ICtpZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15ZXMK
PiAgZWxzZQo+IC0gIGFjX2N2X2hlYWRlcl90aW1lPW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC17
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hl
YWRlcl90aW1lIiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfdGltZSIgPiY2OyB9Cj4g
LWlmIHRlc3QgJGFjX2N2X2hlYWRlcl90aW1lID0geWVzOyB0aGVuCj4gLQo+IC0kYXNfZWNobyAi
I2RlZmluZSBUSU1FX1dJVEhfU1lTX1RJTUUgMSIgPj5jb25mZGVmcy5oCj4gLQo+ICsgIGFjX2N2
X2xpYl9haW9faW9fc2V0dXA9bm8KPiAgZmkKPiAtCj4gLQo+IC0KPiAtCj4gLSAgZm9yIGFjX2hl
YWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKPiAtZG8gOgo+IC0gIGFzX2FjX0hlYWRlcj1gJGFzX2Vj
aG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKPiAtYWNfZm5fY19jaGVj
a19oZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAi
JGFjX2luY2x1ZGVzX2RlZmF1bHQKPiAtIgo+IC1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hl
YWRlciJcIiA9IHgieWVzIjsgdGhlbiA6Cj4gLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+
IC0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKPiAt
X0FDRU9GCj4gLQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKPiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK0xJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKPiAgZmkKPiAtCj4gLWRvbmUKPiAtCj4gLQo+IC0KPiAtCj4g
LQo+IC0KPiAtCj4gLQo+IC0gIGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKPiAtZG8gOgo+
IC0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3No
YAo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIi
Cj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKPiAt
ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCj4gLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRh
Y19mdW5jIiB8ICRhc190cl9jcHBgIDEKPiAtX0FDRU9GCj4gLQo+ICt7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9haW9faW9fc2V0dXAi
ID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID4mNjsgfQo+ICtpZiB0
ZXN0ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKPiArICBzeXN0
ZW1fYWlvPSJ5Igo+ICtlbHNlCj4gKyAgc3lzdGVtX2Fpbz0ibiIKPiAgZmkKPiAtZG9uZQo+IC0K
PiAKPiAKPiAtCj4gLQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciB3b3JraW5nIG1rdGltZSIgPiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5n
IGZvciB3b3JraW5nIG1rdGltZS4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNf
d29ya2luZ19ta3RpbWUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICt7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQo+
ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvLi4uICIgPiY2OyB9Cj4g
K2lmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIgPSBzZXQ7IHRoZW4gOgo+ICAg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Cj4gIGVsc2UKPiAtICBpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiA9IHllczsgdGhlbiA6Cj4gLSAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1u
bwo+IC1lbHNlCj4gLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAo+ICsgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKPiArTElCUz0iLWxjcnlwdG8gICRM
SUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gIC8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtLyogVGVzdCBwcm9ncmFtIGZyb20gUGF1bCBFZ2dlcnQg
YW5kIFRvbnkgTGVuZWlzLiAgKi8KPiAtI2lmZGVmIFRJTUVfV0lUSF9TWVNfVElNRQo+IC0jIGlu
Y2x1ZGUgPHN5cy90aW1lLmg+Cj4gLSMgaW5jbHVkZSA8dGltZS5oPgo+IC0jZWxzZQo+IC0jIGlm
ZGVmIEhBVkVfU1lTX1RJTUVfSAo+IC0jICBpbmNsdWRlIDxzeXMvdGltZS5oPgo+IC0jIGVsc2UK
PiAtIyAgaW5jbHVkZSA8dGltZS5oPgo+IC0jIGVuZGlmCj4gLSNlbmRpZgo+IC0KPiAtI2luY2x1
ZGUgPGxpbWl0cy5oPgo+IC0jaW5jbHVkZSA8c3RkbGliLmg+Cj4gCj4gLSNpZmRlZiBIQVZFX1VO
SVNURF9ICj4gLSMgaW5jbHVkZSA8dW5pc3RkLmg+Cj4gLSNlbmRpZgo+IC0KPiAtI2lmbmRlZiBI
QVZFX0FMQVJNCj4gLSMgZGVmaW5lIGFsYXJtKFgpIC8qIGVtcHR5ICovCj4gKy8qIE92ZXJyaWRl
IGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2Ug
Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiAr
ICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFw
cGx5LiAgKi8KPiArI2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiAgI2VuZGlmCj4g
LQo+IC0vKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24gdG8gcnBsX3B1dGVudiBieSBvdGhlciBj
b25maWcgdGVzdHMuICAqLwo+IC0jdW5kZWYgcHV0ZW52Cj4gLQo+IC1zdGF0aWMgdGltZV90IHRp
bWVfdF9tYXg7Cj4gLXN0YXRpYyB0aW1lX3QgdGltZV90X21pbjsKPiAtCj4gLS8qIFZhbHVlcyB3
ZSdsbCB1c2UgdG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4gICovCj4gLXN0YXRp
YyBjb25zdCBjaGFyICp0el9zdHJpbmdzW10gPSB7Cj4gLSAgKGNvbnN0IGNoYXIgKikgMCwgIlRa
PUdNVDAiLCAiVFo9SlNULTkiLAo+IC0gICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6MDA6MDAs
TTIuMy4wLzAwOjAwOjAwIgo+IC19Owo+IC0jZGVmaW5lIE5fU1RSSU5HUyAoc2l6ZW9mICh0el9z
dHJpbmdzKSAvIHNpemVvZiAodHpfc3RyaW5nc1swXSkpCj4gLQo+IC0vKiBSZXR1cm4gMCBpZiBt
a3RpbWUgZmFpbHMgdG8gY29udmVydCBhIGRhdGUgaW4gdGhlIHNwcmluZy1mb3J3YXJkIGdhcC4K
PiAtICAgQmFzZWQgb24gYSBwcm9ibGVtIHJlcG9ydCBmcm9tIEFuZHJlYXMgSmFlZ2VyLiAgKi8K
PiAtc3RhdGljIGludAo+IC1zcHJpbmdfZm9yd2FyZF9nYXAgKCkKPiAtewo+IC0gIC8qIGdsaWJj
ICh1cCB0byBhYm91dCAxOTk4LTEwLTA3KSBmYWlsZWQgdGhpcyB0ZXN0LiAqLwo+IC0gIHN0cnVj
dCB0bSB0bTsKPiAtCj4gLSAgLyogVXNlIHRoZSBwb3J0YWJsZSBQT1NJWC4xIHNwZWNpZmljYXRp
b24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCj4gLSAgICAgaW5zdGVhZCBvZiAiVFo9QW1l
cmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVnIGV2ZW4KPiAtICAgICBv
biBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xzb24gZXh0ZW5zaW9uLCBvciBkb24n
dCBoYXZlIHRoZQo+IC0gICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGluc3RhbGxlZC4gICovCj4g
LSAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7Cj4gLQo+IC0g
IHRtLnRtX3llYXIgPSA5ODsKPiAtICB0bS50bV9tb24gPSAzOwo+IC0gIHRtLnRtX21kYXkgPSA1
Owo+IC0gIHRtLnRtX2hvdXIgPSAyOwo+IC0gIHRtLnRtX21pbiA9IDA7Cj4gLSAgdG0udG1fc2Vj
ID0gMDsKPiAtICB0bS50bV9pc2RzdCA9IC0xOwo+IC0gIHJldHVybiBta3RpbWUgKCZ0bSkgIT0g
KHRpbWVfdCkgLTE7Cj4gLX0KPiAtCj4gLXN0YXRpYyBpbnQKPiAtbWt0aW1lX3Rlc3QxICh0aW1l
X3Qgbm93KQo+IC17Cj4gLSAgc3RydWN0IHRtICpsdDsKPiAtICByZXR1cm4gISAobHQgPSBsb2Nh
bHRpbWUgKCZub3cpKSB8fCBta3RpbWUgKGx0KSA9PSBub3c7Cj4gLX0KPiAtCj4gLXN0YXRpYyBp
bnQKPiAtbWt0aW1lX3Rlc3QgKHRpbWVfdCBub3cpCj4gLXsKPiAtICByZXR1cm4gKG1rdGltZV90
ZXN0MSAobm93KQo+IC0gICAgICAgICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3QpICh0aW1lX3Rf
bWF4IC0gbm93KSkKPiAtICAgICAgICAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAodGltZV90
X21pbiArIG5vdykpKTsKPiAtfQo+IC0KPiAtc3RhdGljIGludAo+IC1pcml4XzZfNF9idWcgKCkK
PiAtewo+IC0gIC8qIEJhc2VkIG9uIGNvZGUgZnJvbSBBcmllbCBGYWlnb24uICAqLwo+IC0gIHN0
cnVjdCB0bSB0bTsKPiAtICB0bS50bV95ZWFyID0gOTY7Cj4gLSAgdG0udG1fbW9uID0gMzsKPiAt
ICB0bS50bV9tZGF5ID0gMDsKPiAtICB0bS50bV9ob3VyID0gMDsKPiAtICB0bS50bV9taW4gPSAw
Owo+IC0gIHRtLnRtX3NlYyA9IDA7Cj4gLSAgdG0udG1faXNkc3QgPSAtMTsKPiAtICBta3RpbWUg
KCZ0bSk7Cj4gLSAgcmV0dXJuIHRtLnRtX21vbiA9PSAyICYmIHRtLnRtX21kYXkgPT0gMzE7Cj4g
LX0KPiAtCj4gLXN0YXRpYyBpbnQKPiAtYmlndGltZV90ZXN0IChpbnQgaikKPiAtewo+IC0gIHN0
cnVjdCB0bSB0bTsKPiAtICB0aW1lX3Qgbm93Owo+IC0gIHRtLnRtX3llYXIgPSB0bS50bV9tb24g
PSB0bS50bV9tZGF5ID0gdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRtLnRtX3NlYyA9IGo7Cj4g
LSAgbm93ID0gbWt0aW1lICgmdG0pOwo+IC0gIGlmIChub3cgIT0gKHRpbWVfdCkgLTEpCj4gLSAg
ICB7Cj4gLSAgICAgIHN0cnVjdCB0bSAqbHQgPSBsb2NhbHRpbWUgKCZub3cpOwo+IC0gICAgICBp
ZiAoISAobHQKPiAtICAgICAgICAgICAgJiYgbHQtPnRtX3llYXIgPT0gdG0udG1feWVhcgo+IC0g
ICAgICAgICAgICAmJiBsdC0+dG1fbW9uID09IHRtLnRtX21vbgo+IC0gICAgICAgICAgICAmJiBs
dC0+dG1fbWRheSA9PSB0bS50bV9tZGF5Cj4gLSAgICAgICAgICAgICYmIGx0LT50bV9ob3VyID09
IHRtLnRtX2hvdXIKPiAtICAgICAgICAgICAgJiYgbHQtPnRtX21pbiA9PSB0bS50bV9taW4KPiAt
ICAgICAgICAgICAgJiYgbHQtPnRtX3NlYyA9PSB0bS50bV9zZWMKPiAtICAgICAgICAgICAgJiYg
bHQtPnRtX3lkYXkgPT0gdG0udG1feWRheQo+IC0gICAgICAgICAgICAmJiBsdC0+dG1fd2RheSA9
PSB0bS50bV93ZGF5Cj4gLSAgICAgICAgICAgICYmICgobHQtPnRtX2lzZHN0IDwgMCA/IC0xIDog
MCA8IGx0LT50bV9pc2RzdCkKPiAtICAgICAgICAgICAgICAgICA9PSAodG0udG1faXNkc3QgPCAw
ID8gLTEgOiAwIDwgdG0udG1faXNkc3QpKSkpCj4gLSAgICAgICByZXR1cm4gMDsKPiAtICAgIH0K
PiAtICByZXR1cm4gMTsKPiAtfQo+IC0KPiAtc3RhdGljIGludAo+IC15ZWFyXzIwNTBfdGVzdCAo
KQo+IC17Cj4gLSAgLyogVGhlIGNvcnJlY3QgYW5zd2VyIGZvciAyMDUwLTAyLTAxIDAwOjAwOjAw
IGluIFBhY2lmaWMgdGltZSwKPiAtICAgICBpZ25vcmluZyBsZWFwIHNlY29uZHMuICAqLwo+IC0g
IHVuc2lnbmVkIGxvbmcgaW50IGFuc3dlciA9IDI1MjczMTUyMDBVTDsKPiAtCj4gLSAgc3RydWN0
IHRtIHRtOwo+IC0gIHRpbWVfdCB0Owo+IC0gIHRtLnRtX3llYXIgPSAyMDUwIC0gMTkwMDsKPiAt
ICB0bS50bV9tb24gPSAyIC0gMTsKPiAtICB0bS50bV9tZGF5ID0gMTsKPiAtICB0bS50bV9ob3Vy
ID0gdG0udG1fbWluID0gdG0udG1fc2VjID0gMDsKPiAtICB0bS50bV9pc2RzdCA9IC0xOwo+IC0K
PiAtICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBE
VCxNNC4xLjAsTTEwLjUuMCIKPiAtICAgICBpbnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZl
ciIgaW4gb3JkZXIgdG8gZGV0ZWN0IHRoZSBidWcgZXZlbgo+IC0gICAgIG9uIHN5c3RlbXMgdGhh
dCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBleHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCj4g
LSAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFsbGVkLiAgKi8KPiAtICBwdXRlbnYgKChj
aGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiKTsKPiAtCj4gLSAgdCA9IG1rdGltZSAo
JnRtKTsKPiAtCj4gLSAgLyogQ2hlY2sgdGhhdCB0aGUgcmVzdWx0IGlzIGVpdGhlciBhIGZhaWx1
cmUsIG9yIGNsb3NlIGVub3VnaAo+IC0gICAgIHRvIHRoZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdl
IGNhbiBhc3N1bWUgdGhlIGRpc2NyZXBhbmN5IGlzCj4gLSAgICAgZHVlIHRvIGxlYXAgc2Vjb25k
cy4gICovCj4gLSAgcmV0dXJuICh0ID09ICh0aW1lX3QpIC0xCj4gLSAgICAgICAgIHx8ICgwIDwg
dCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAmJiB0IDw9IGFuc3dlciArIDEyMCkpOwo+IC19Cj4gLQo+
ICtjaGFyIE1ENSAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC0gIHRpbWVfdCB0LCBkZWx0
YTsKPiAtICBpbnQgaSwgajsKPiAtCj4gLSAgLyogVGhpcyB0ZXN0IG1ha2VzIHNvbWUgYnVnZ3kg
bWt0aW1lIGltcGxlbWVudGF0aW9ucyBsb29wLgo+IC0gICAgIEdpdmUgdXAgYWZ0ZXIgNjAgc2Vj
b25kczsgYSBta3RpbWUgc2xvd2VyIHRoYW4gdGhhdAo+IC0gICAgIGlzbid0IHdvcnRoIHVzaW5n
IGFueXdheS4gICovCj4gLSAgYWxhcm0gKDYwKTsKPiAtCj4gLSAgZm9yICg7OykKPiAtICAgIHsK
PiAtICAgICAgdCA9ICh0aW1lX3RfbWF4IDw8IDEpICsgMTsKPiAtICAgICAgaWYgKHQgPD0gdGlt
ZV90X21heCkKPiAtICAgICAgIGJyZWFrOwo+IC0gICAgICB0aW1lX3RfbWF4ID0gdDsKPiAtICAg
IH0KPiAtICB0aW1lX3RfbWluID0gLSAoKHRpbWVfdCkgfiAodGltZV90KSAwID09ICh0aW1lX3Qp
IC0xKSAtIHRpbWVfdF9tYXg7Cj4gLQo+IC0gIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyog
YSBzdWl0YWJsZSBwcmltZSBudW1iZXIgKi8KPiAtICBmb3IgKGkgPSAwOyBpIDwgTl9TVFJJTkdT
OyBpKyspCj4gLSAgICB7Cj4gLSAgICAgIGlmICh0el9zdHJpbmdzW2ldKQo+IC0gICAgICAgcHV0
ZW52ICgoY2hhciopIHR6X3N0cmluZ3NbaV0pOwo+IC0KPiAtICAgICAgZm9yICh0ID0gMDsgdCA8
PSB0aW1lX3RfbWF4IC0gZGVsdGE7IHQgKz0gZGVsdGEpCj4gLSAgICAgICBpZiAoISBta3RpbWVf
dGVzdCAodCkpCj4gLSAgICAgICAgIHJldHVybiAxOwo+IC0gICAgICBpZiAoISAobWt0aW1lX3Rl
c3QgKCh0aW1lX3QpIDEpCj4gLSAgICAgICAgICAgICYmIG1rdGltZV90ZXN0ICgodGltZV90KSAo
NjAgKiA2MCkpCj4gLSAgICAgICAgICAgICYmIG1rdGltZV90ZXN0ICgodGltZV90KSAoNjAgKiA2
MCAqIDI0KSkpKQo+IC0gICAgICAgcmV0dXJuIDE7Cj4gLQo+IC0gICAgICBmb3IgKGogPSAxOyA7
IGogPDw9IDEpCj4gLSAgICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQo+IC0gICAgICAgICBy
ZXR1cm4gMTsKPiAtICAgICAgIGVsc2UgaWYgKElOVF9NQVggLyAyIDwgaikKPiAtICAgICAgICAg
YnJlYWs7Cj4gLSAgICAgIGlmICghIGJpZ3RpbWVfdGVzdCAoSU5UX01BWCkpCj4gLSAgICAgICBy
ZXR1cm4gMTsKPiAtICAgIH0KPiAtICByZXR1cm4gISAoaXJpeF82XzRfYnVnICgpICYmIHNwcmlu
Z19mb3J3YXJkX2dhcCAoKSAmJiB5ZWFyXzIwNTBfdGVzdCAoKSk7Cj4gK3JldHVybiBNRDUgKCk7
Cj4gKyAgOwo+ICsgIHJldHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9y
dW4gIiRMSU5FTk8iOyB0aGVuIDoKPiAtICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPXllcwo+
ICtpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gKyAgYWNfY3ZfbGliX2Ny
eXB0b19NRDU9eWVzCj4gIGVsc2UKPiAtICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCj4g
LWZpCj4gLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQg
Y29uZnRlc3QkYWNfZXhlZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJl
YW0gY29uZnRlc3QuJGFjX2V4dAo+IC1maQo+IC0KPiArICBhY19jdl9saWJfY3J5cHRvX01ENT1u
bwo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2Z1
bmNfd29ya2luZ19ta3RpbWUiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX3dvcmtpbmdf
bWt0aW1lID0gbm87IHRoZW4KPiAtICBjYXNlICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIG1rdGlt
ZS4kYWNfb2JqZXh0ICIqICkgOzsKPiAtICAqKSBMSUJPQkpTPSIkTElCT0JKUyBta3RpbWUuJGFj
X29iamV4dCIKPiAtIDs7Cj4gLWVzYWMKPiAtCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICBmaQo+IC0KPiAtCj4gLQo+
IC0KPiAtCj4gLQo+IC1mb3IgYWNfZnVuYyBpbiBnZXRwYWdlc2l6ZQo+IC1kbyA6Cj4gLSAgYWNf
Zm5fY19jaGVja19mdW5jICIkTElORU5PIiAiZ2V0cGFnZXNpemUiICJhY19jdl9mdW5jX2dldHBh
Z2VzaXplIgo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiID0geCIieWVzOyB0
aGVuIDoKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1Cj4gKyRhc19lY2hvICIkYWNfY3ZfbGliX2NyeXB0
b19NRDUiID4mNjsgfQo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9IHgiInll
czsgdGhlbiA6Cj4gICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVf
R0VUUEFHRVNJWkUgMQo+ICsjZGVmaW5lIEhBVkVfTElCQ1JZUFRPIDEKPiAgX0FDRU9GCj4gCj4g
KyAgTElCUz0iLWxjcnlwdG8gJExJQlMiCj4gKwo+ICtlbHNlCj4gKyAgYXNfZm5fZXJyb3IgJD8g
IkNvdWxkIG5vdCBmaW5kIGxpYmNyeXB0byIgIiRMSU5FTk8iIDUKPiAgZmkKPiAtZG9uZQo+IAo+
IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3
b3JraW5nIG1tYXAiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBtbWFw
Li4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCtz
ZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcyIgPiY1Cj4gKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0K
PiAraWYgdGVzdCAiJHthY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMitzZXR9IiA9IHNldDsg
dGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKPiAtICBhY19jdl9mdW5jX21tYXBf
Zml4ZWRfbWFwcGVkPW5vCj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0Cj4gKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+ICtMSUJT
PSItbGV4dDJmcyAgJExJQlMiCj4gK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmguICAqLwo+IC0kYWNfaW5jbHVkZXNfZGVmYXVs
dAo+IC0vKiBtYWxsb2MgbWlnaHQgaGF2ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8K
PiAtI3VuZGVmIG1hbGxvYwo+IC0KPiAtLyogVGhhbmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmlt
IEF2ZXJhIGZvciB0aGlzIHRlc3QuCj4gLSAgIEhlcmUgaXMgYSBtYXRyaXggb2YgbW1hcCBwb3Nz
aWJpbGl0aWVzOgo+IC0gICAgICAgbW1hcCBwcml2YXRlIG5vdCBmaXhlZAo+IC0gICAgICAgbW1h
cCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5tYXBwZWQKPiAtICAgICAg
IG1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKPiAtICAgICAg
IG1tYXAgc2hhcmVkIG5vdCBmaXhlZAo+IC0gICAgICAgbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29t
ZXdoZXJlIGN1cnJlbnRseSB1bm1hcHBlZAo+IC0gICAgICAgbW1hcCBzaGFyZWQgZml4ZWQgYXQg
c29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCj4gLSAgIEZvciBwcml2YXRlIG1hcHBpbmdzLCB3ZSBz
aG91bGQgdmVyaWZ5IHRoYXQgY2hhbmdlcyBjYW5ub3QgYmUgcmVhZCgpCj4gLSAgIGJhY2sgZnJv
bSB0aGUgZmlsZSwgbm9yIG1tYXAncyBiYWNrIGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQK
PiAtICAgYWRkcmVzcy4gIChUaGVyZSBoYXZlIGJlZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRlIHdh
cyBub3QgY29ycmVjdGx5Cj4gLSAgIGltcGxlbWVudGVkIGxpa2UgdGhlIGluZmFtb3VzIGkzODYg
c3ZyNC4wLCBhbmQgc3lzdGVtcyB3aGVyZSB0aGUKPiAtICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90
IGNvaGVyZW50IHdpdGggdGhlIGZpbGUgc3lzdGVtIGJ1ZmZlciBjYWNoZQo+IC0gICBsaWtlIGVh
cmx5IHZlcnNpb25zIG9mIEZyZWVCU0QgYW5kIHBvc3NpYmx5IGNvbnRlbXBvcmFyeSBOZXRCU0Qu
KQo+IC0gICBGb3Igc2hhcmVkIG1hcHBpbmdzLCB3ZSBzaG91bGQgY29udmVyc2VseSB2ZXJpZnkg
dGhhdCBjaGFuZ2VzIGdldAo+IC0gICBwcm9wYWdhdGVkIGJhY2sgdG8gYWxsIHRoZSBwbGFjZXMg
dGhleSdyZSBzdXBwb3NlZCB0byBiZS4KPiAtCj4gLSAgIEdyZXAgd2FudHMgcHJpdmF0ZSBmaXhl
ZCBhbHJlYWR5IG1hcHBlZC4KPiAtICAgVGhlIG1haW4gdGhpbmdzIGdyZXAgbmVlZHMgdG8ga25v
dyBhYm91dCBtbWFwIGFyZToKPiAtICAgKiBkb2VzIGl0IGV4aXN0IGFuZCBpcyBpdCBzYWZlIHRv
IHdyaXRlIGludG8gdGhlIG1tYXAnZCBhcmVhCj4gLSAgICogaG93IHRvIHVzZSBpdCAoQlNEIHZh
cmlhbnRzKSAgKi8KPiAtCj4gLSNpbmNsdWRlIDxmY250bC5oPgo+IC0jaW5jbHVkZSA8c3lzL21t
YW4uaD4KPiAtCj4gLSNpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMgJiYgIWRlZmluZWQgSEFWRV9T
VERMSUJfSAo+IC1jaGFyICptYWxsb2MgKCk7Cj4gLSNlbmRpZgo+IC0KPiAtLyogVGhpcyBtZXNz
IHdhcyBjb3BpZWQgZnJvbSB0aGUgR05VIGdldHBhZ2VzaXplLmguICAqLwo+IC0jaWZuZGVmIEhB
VkVfR0VUUEFHRVNJWkUKPiAtIyBpZmRlZiBfU0NfUEFHRVNJWkUKPiAtIyAgZGVmaW5lIGdldHBh
Z2VzaXplKCkgc3lzY29uZihfU0NfUEFHRVNJWkUpCj4gLSMgZWxzZSAvKiBubyBfU0NfUEFHRVNJ
WkUgKi8KPiAtIyAgaWZkZWYgSEFWRV9TWVNfUEFSQU1fSAo+IC0jICAgaW5jbHVkZSA8c3lzL3Bh
cmFtLmg+Cj4gLSMgICBpZmRlZiBFWEVDX1BBR0VTSVpFCj4gLSMgICAgZGVmaW5lIGdldHBhZ2Vz
aXplKCkgRVhFQ19QQUdFU0laRQo+IC0jICAgZWxzZSAvKiBubyBFWEVDX1BBR0VTSVpFICovCj4g
LSMgICAgaWZkZWYgTkJQRwo+IC0jICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBOQlBHICogQ0xT
SVpFCj4gLSMgICAgIGlmbmRlZiBDTFNJWkUKPiAtIyAgICAgIGRlZmluZSBDTFNJWkUgMQo+IC0j
ICAgICBlbmRpZiAvKiBubyBDTFNJWkUgKi8KPiAtIyAgICBlbHNlIC8qIG5vIE5CUEcgKi8KPiAt
IyAgICAgaWZkZWYgTkJQQwo+IC0jICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgTkJQQwo+IC0j
ICAgICBlbHNlIC8qIG5vIE5CUEMgKi8KPiAtIyAgICAgIGlmZGVmIFBBR0VTSVpFCj4gLSMgICAg
ICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgUEFHRVNJWkUKPiAtIyAgICAgIGVuZGlmIC8qIFBBR0VT
SVpFICovCj4gLSMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KPiAtIyAgICBlbmRpZiAvKiBubyBO
QlBHICovCj4gLSMgICBlbmRpZiAvKiBubyBFWEVDX1BBR0VTSVpFICovCj4gLSMgIGVsc2UgLyog
bm8gSEFWRV9TWVNfUEFSQU1fSCAqLwo+IC0jICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgODE5MiAg
LyogcHVudCB0b3RhbGx5ICovCj4gLSMgIGVuZGlmIC8qIG5vIEhBVkVfU1lTX1BBUkFNX0ggKi8K
PiAtIyBlbmRpZiAvKiBubyBfU0NfUEFHRVNJWkUgKi8KPiAtCj4gLSNlbmRpZiAvKiBubyBIQVZF
X0dFVFBBR0VTSVpFICovCj4gCj4gKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90
eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+ICsgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBt
YXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKPiArICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg
YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KPiArI2lmZGVmIF9fY3Bs
dXNwbHVzCj4gK2V4dGVybiAiQyIKPiArI2VuZGlmCj4gK2NoYXIgZXh0MmZzX29wZW4yICgpOwo+
ICBpbnQKPiAgbWFpbiAoKQo+ICB7Cj4gLSAgY2hhciAqZGF0YSwgKmRhdGEyLCAqZGF0YTM7Cj4g
LSAgY29uc3QgY2hhciAqY2RhdGEyOwo+IC0gIGludCBpLCBwYWdlc2l6ZTsKPiAtICBpbnQgZmQs
IGZkMjsKPiAtCj4gLSAgcGFnZXNpemUgPSBnZXRwYWdlc2l6ZSAoKTsKPiAtCj4gLSAgLyogRmly
c3QsIG1ha2UgYSBmaWxlIHdpdGggc29tZSBrbm93biBnYXJiYWdlIGluIGl0LiAqLwo+IC0gIGRh
dGEgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsKPiAtICBpZiAoIWRhdGEpCj4gLSAgICBy
ZXR1cm4gMTsKPiAtICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKPiAtICAgICooZGF0
YSArIGkpID0gcmFuZCAoKTsKPiAtICB1bWFzayAoMCk7Cj4gLSAgZmQgPSBjcmVhdCAoImNvbmZ0
ZXN0Lm1tYXAiLCAwNjAwKTsKPiAtICBpZiAoZmQgPCAwKQo+IC0gICAgcmV0dXJuIDI7Cj4gLSAg
aWYgKHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2VzaXplKQo+IC0gICAgcmV0dXJu
IDM7Cj4gLSAgY2xvc2UgKGZkKTsKPiAtCj4gLSAgLyogTmV4dCwgY2hlY2sgdGhhdCB0aGUgdGFp
bCBvZiBhIHBhZ2UgaXMgemVyby1maWxsZWQuICBGaWxlIG11c3QgaGF2ZQo+IC0gICAgIG5vbi16
ZXJvIGxlbmd0aCwgb3RoZXJ3aXNlIHdlIHJpc2sgU0lHQlVTIGZvciBlbnRpcmUgcGFnZS4gICov
Cj4gLSAgZmQyID0gb3BlbiAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQgfCBPX1RS
VU5DLCAwNjAwKTsKPiAtICBpZiAoZmQyIDwgMCkKPiAtICAgIHJldHVybiA0Owo+IC0gIGNkYXRh
MiA9ICIiOwo+IC0gIGlmICh3cml0ZSAoZmQyLCBjZGF0YTIsIDEpICE9IDEpCj4gLSAgICByZXR1
cm4gNTsKPiAtICBkYXRhMiA9IChjaGFyICopIG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQg
fCBQUk9UX1dSSVRFLCBNQVBfU0hBUkVELCBmZDIsIDBMKTsKPiAtICBpZiAoZGF0YTIgPT0gTUFQ
X0ZBSUxFRCkKPiAtICAgIHJldHVybiA2Owo+IC0gIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsg
KytpKQo+IC0gICAgaWYgKCooZGF0YTIgKyBpKSkKPiAtICAgICAgcmV0dXJuIDc7Cj4gLSAgY2xv
c2UgKGZkMik7Cj4gLSAgaWYgKG11bm1hcCAoZGF0YTIsIHBhZ2VzaXplKSkKPiAtICAgIHJldHVy
biA4Owo+IC0KPiAtICAvKiBOZXh0LCB0cnkgdG8gbW1hcCB0aGUgZmlsZSBhdCBhIGZpeGVkIGFk
ZHJlc3Mgd2hpY2ggYWxyZWFkeSBoYXMKPiAtICAgICBzb21ldGhpbmcgZWxzZSBhbGxvY2F0ZWQg
YXQgaXQuICBJZiB3ZSBjYW4sIGFsc28gbWFrZSBzdXJlIHRoYXQKPiAtICAgICB3ZSBzZWUgdGhl
IHNhbWUgZ2FyYmFnZS4gICovCj4gLSAgZmQgPSBvcGVuICgiY29uZnRlc3QubW1hcCIsIE9fUkRX
Uik7Cj4gLSAgaWYgKGZkIDwgMCkKPiAtICAgIHJldHVybiA5Owo+IC0gIGlmIChkYXRhMiAhPSBt
bWFwIChkYXRhMiwgcGFnZXNpemUsIFBST1RfUkVBRCB8IFBST1RfV1JJVEUsCj4gLSAgICAgICAg
ICAgICAgICAgICAgTUFQX1BSSVZBVEUgfCBNQVBfRklYRUQsIGZkLCAwTCkpCj4gLSAgICByZXR1
cm4gMTA7Cj4gLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCj4gLSAgICBpZiAoKihk
YXRhICsgaSkgIT0gKihkYXRhMiArIGkpKQo+IC0gICAgICByZXR1cm4gMTE7Cj4gLQo+IC0gIC8q
IEZpbmFsbHksIG1ha2Ugc3VyZSB0aGF0IGNoYW5nZXMgdG8gdGhlIG1hcHBlZCBhcmVhIGRvIG5v
dAo+IC0gICAgIHBlcmNvbGF0ZSBiYWNrIHRvIHRoZSBmaWxlIGFzIHNlZW4gYnkgcmVhZCgpLiAg
KFRoaXMgaXMgYSBidWcgb24KPiAtICAgICBzb21lIHZhcmlhbnRzIG9mIGkzODYgc3ZyNC4wLikg
ICovCj4gLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCj4gLSAgICAqKGRhdGEyICsg
aSkgPSAqKGRhdGEyICsgaSkgKyAxOwo+IC0gIGRhdGEzID0gKGNoYXIgKikgbWFsbG9jIChwYWdl
c2l6ZSk7Cj4gLSAgaWYgKCFkYXRhMykKPiAtICAgIHJldHVybiAxMjsKPiAtICBpZiAocmVhZCAo
ZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0gcGFnZXNpemUpCj4gLSAgICByZXR1cm4gMTM7Cj4gLSAg
Zm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCj4gLSAgICBpZiAoKihkYXRhICsgaSkgIT0g
KihkYXRhMyArIGkpKQo+IC0gICAgICByZXR1cm4gMTQ7Cj4gLSAgY2xvc2UgKGZkKTsKPiArcmV0
dXJuIGV4dDJmc19vcGVuMiAoKTsKPiArICA7Cj4gICAgcmV0dXJuIDA7Cj4gIH0KPiAgX0FDRU9G
Cj4gLWlmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNf
bW1hcF9maXhlZF9tYXBwZWQ9eWVzCj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKPiArICBhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj15ZXMKPiAgZWxzZQo+IC0g
IGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9bm8KPiAtZmkKPiAtcm0gLWYgY29yZSAqLmNv
cmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+
IC0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4g
LWZpCj4gLQo+ICsgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPW5vCj4gIGZpCj4gLXsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVu
Y19tbWFwX2ZpeGVkX21hcHBlZCIgPiY1Cj4gLSRhc19lY2hvICIkYWNfY3ZfZnVuY19tbWFwX2Zp
eGVkX21hcHBlZCIgPiY2OyB9Cj4gLWlmIHRlc3QgJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBw
ZWQgPSB5ZXM7IHRoZW4KPiAtCj4gLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfTU1BUCAxIiA+PmNv
bmZkZWZzLmgKPiAtCj4gK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgXAo+ICsgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0k
YWNfY2hlY2tfbGliX3NhdmVfTElCUwo+ICBmaQo+IC1ybSAtZiBjb25mdGVzdC5tbWFwIGNvbmZ0
ZXN0LnR4dAo+IC0KPiAtZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAo+IC1kbyA6Cj4gLSAgYWNf
Zm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVh
ZGVyX3N0ZGxpYl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gLWlmIHRlc3QgIngkYWNfY3Zf
aGVhZGVyX3N0ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6Cj4gLSAgY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgo+IC0jZGVmaW5lIEhBVkVfU1RETElCX0ggMQo+IC1fQUNFT0YKPiAtCj4gK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4
dDJmc19leHQyZnNfb3BlbjIiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0
MmZzX29wZW4yIiA+JjY7IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19v
cGVuMiIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsgIGxpYmV4dDJmcz0ieSIKPiArZWxzZQo+ICsgIGxp
YmV4dDJmcz0ibiIKPiAgZmkKPiAKPiAtZG9uZQo+IAo+IC17ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIHJlYWxs
b2MiID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSBy
ZWFsbG9jLi4uICIgPiY2OyB9Cj4gLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9u
bnVsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQi
ID4mNQo+ICskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZlciBpbiAt
bGdjcnlwdC4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X2xpYl9nY3J5cHRfZ2NyeV9t
ZF9oYXNoX2J1ZmZlcitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKPiAgZWxzZQo+IC0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKPiAtICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCj4gLWVsc2UKPiAtICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUwo+ICtMSUJTPSItbGdjcnlwdCAgJExJQlMiCj4gK2NhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+IC0jaWYgZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9I
Cj4gLSMgaW5jbHVkZSA8c3RkbGliLmg+Cj4gLSNlbHNlCj4gLWNoYXIgKnJlYWxsb2MgKCk7Cj4g
LSNlbmRpZgo+IAo+ICsvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBh
dm9pZCBhbiBlcnJvci4KPiArICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl
IHJldHVybiB0eXBlIG9mIGEgR0NDCj4gKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50
IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCj4gKyNpZmRlZiBfX2NwbHVzcGx1cwo+
ICtleHRlcm4gIkMiCj4gKyNlbmRpZgo+ICtjaGFyIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7Cj4g
IGludAo+ICBtYWluICgpCj4gIHsKPiAtcmV0dXJuICEgcmVhbGxvYyAoMCwgMCk7Cj4gK3JldHVy
biBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwo+ICAgIDsKPiAgICByZXR1cm4gMDsKPiAgfQo+ICBf
QUNFT0YKPiAtaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3Zf
ZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKPiAraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVO
TyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj15ZXMK
PiAgZWxzZQo+IC0gIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9bm8KPiArICBhY19jdl9s
aWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9bm8KPiAgZmkKPiAtcm0gLWYgY29yZSAqLmNv
cmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+
IC0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4g
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29u
ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3Nh
dmVfTElCUwo+ICBmaQo+IC0KPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQo+
ICskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9
Cj4gK2lmIHRlc3QgIngkYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA9IHgi
InllczsgdGhlbiA6Cj4gKyAgbGliZ2NyeXB0PSJ5Igo+ICtlbHNlCj4gKyAgbGliZ2NyeXB0PSJu
Igo+ICBmaQo+IC17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2
X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX3Jl
YWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKPiAKPiAtJGFzX2VjaG8gIiNkZWZpbmUgSEFW
RV9SRUFMTE9DIDEiID4+Y29uZmRlZnMuaAo+IAo+ICsKPiArICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZyIgPiY1Cj4g
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciBwdGhyZWFkIGZsYWcuLi4gIiA+JjY7IH0KPiAraWYg
dGVzdCAiJHtheF9jdl9wdGhyZWFkX2ZsYWdzK3NldH0iID0gc2V0OyB0aGVuIDoKPiArICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFW
RV9SRUFMTE9DIDAiID4+Y29uZmRlZnMuaAo+IAo+IC0gICBjYXNlICIgJExJQk9CSlMgIiBpbgo+
IC0gICoiIHJlYWxsb2MuJGFjX29iamV4dCAiKiApIDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9C
SlMgcmVhbGxvYy4kYWNfb2JqZXh0Igo+IC0gOzsKPiAtZXNhYwo+ICsgICAgICAgIGF4X2N2X3B0
aHJlYWRfZmxhZ3M9LXB0aHJlYWQKPiArCj4gKyAgICBQVEhSRUFEX0NGTEFHUz0iJGF4X2N2X3B0
aHJlYWRfZmxhZ3MiCj4gKyAgICBQVEhSRUFEX0xERkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdz
Igo+ICsgICAgUFRIUkVBRF9MSUJTPSIiCj4gKwo+ICsKPiArICAgIHNhdmVkX0NGTEFHUz0iJENG
TEFHUyIKPiArCj4gKyAgICBzYXZlZF9MREZMQUdTPSIkTERGTEFHUyIKPiArCj4gKyAgICBzYXZl
ZF9MSUJTPSIkTElCUyIKPiArCj4gKwo+ICsgICAgQ0ZMQUdTPSIkQ0ZMQUdTICRQVEhSRUFEX0NG
TEFHUyIKPiArCj4gKyAgICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgo+ICsK
PiArICAgIExJQlM9IiRMSUJTICRQVEhSRUFEX0xJQlMiCj4gKwo+ICsgICAgICAgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiArLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwo+ICsKPiArI2luY2x1ZGUgPHB0aHJlYWQuaD4KPiAraW50IG1haW4odm9pZCkgewo+ICsg
IHB0aHJlYWRfYXRmb3JrKDAsMCwwKTsKPiArICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCwwKTsKPiAr
fQo+ICsKPiArX0FDRU9GCj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
PiArCj4gK2Vsc2UKPiArICBheF9jdl9wdGhyZWFkX2ZsYWdzPWZhaWxlZAo+ICtmaQo+ICtybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKPiArICAgIGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gKwo+ICsgICAgQ0ZMQUdTPSIkc2F2ZWRfQ0ZM
QUdTIgo+ICsKPiArICAgIExERkxBR1M9IiRzYXZlZF9MREZMQUdTIgo+IAo+ICsgICAgTElCUz0i
JHNhdmVkX0xJQlMiCj4gCj4gLSRhc19lY2hvICIjZGVmaW5lIHJlYWxsb2MgcnBsX3JlYWxsb2Mi
ID4+Y29uZmRlZnMuaAo+IAo+ICBmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQo+ICskYXNfZWNobyAi
JGF4X2N2X3B0aHJlYWRfZmxhZ3MiID4mNjsgfQo+ICsgICAgaWYgdGVzdCAieCRheF9jdl9wdGhy
ZWFkX2ZsYWdzIiA9IHhmYWlsZWQ7IHRoZW4KPiArICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0
aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5FTk8iIDUKPiArICAgIGZpCj4gKwo+ICsgICAgUFRI
UkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgo+ICsgICAgUFRIUkVBRF9MREZMQUdT
PSIkYXhfY3ZfcHRocmVhZF9mbGFncyIKPiArICAgIFBUSFJFQURfTElCUz0iIgo+ICsKPiAKPiAK
PiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
d29ya2luZyBzdHJubGVuIiA+JjUKPiAtJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcg
c3Rybmxlbi4uLiAiID4mNjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfc3Rybmxlbl93b3Jr
aW5nK3NldH0iID0gc2V0OyB0aGVuIDoKPiAreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4mNQo+ICskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwuLi4gIiA+JjY7IH0KPiAr
aWYgdGVzdCAiJHthY19jdl9saWJfeWFqbF95YWpsX2FsbG9jK3NldH0iID0gc2V0OyB0aGVuIDoK
PiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+ICBlbHNlCj4gLSAgaWYgdGVzdCAiJGNy
b3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0gIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3Jr
aW5nPW5vCj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0Cj4gKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+ICtMSUJTPSItbHlhamwg
ICRMSUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cj4g
IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAtJGFjX2luY2x1ZGVzX2RlZmF1bHQKPiArCj4gKy8q
IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgo+
ICsgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKPiArICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KPiArI2lmZGVmIF9fY3BsdXNwbHVzCj4gK2V4dGVybiAiQyIKPiAr
I2VuZGlmCj4gK2NoYXIgeWFqbF9hbGxvYyAoKTsKPiAgaW50Cj4gIG1haW4gKCkKPiAgewo+IC0K
PiAtI2RlZmluZSBTICJmb29iYXIiCj4gLSNkZWZpbmUgU19MRU4gKHNpemVvZiBTIC0gMSkKPiAt
Cj4gLSAgLyogQXQgbGVhc3Qgb25lIGltcGxlbWVudGF0aW9uIGlzIGJ1Z2d5OiB0aGF0IG9mIEFJ
WCA0LjMgd291bGQKPiAtICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMuICAqLwo+IC0KPiAt
ICBpbnQgaTsKPiAtICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCj4gLSAgICB7Cj4g
LSAgICAgIGludCBleHBlY3RlZCA9IGkgPD0gU19MRU4gPyBpIDogU19MRU47Cj4gLSAgICAgIGlm
IChzdHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKPiAtICAgICAgIHJldHVybiAxOwo+IC0gICAg
fQo+IC0gIHJldHVybiAwOwo+IC0KPiArcmV0dXJuIHlhamxfYWxsb2MgKCk7Cj4gICAgOwo+ICAg
IHJldHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+IC1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8i
OyB0aGVuIDoKPiAtICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXMKPiAraWYgYWNfZm5f
Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgo+ICsgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxs
b2M9eWVzCj4gIGVsc2UKPiAtICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz1ubwo+ICsgIGFj
X2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KPiAgZmkKPiAtcm0gLWYgY29yZSAqLmNvcmUgY29y
ZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAo+IC0gIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Cj4gK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAo+ICsgICAgY29uZnRlc3Qk
YWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKPiArTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElC
Uwo+ICBmaQo+ICt7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQo+ICskYXNfZWNobyAiJGFjX2N2X2xp
Yl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQo+ICtpZiB0ZXN0ICJ4JGFjX2N2X2xpYl95YWpsX3lh
amxfYWxsb2MiID0geCIieWVzOyB0aGVuIDoKPiArICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
Cj4gKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKPiArX0FDRU9GCj4gCj4gLWZpCj4gLXsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJu
bGVuX3dvcmtpbmciID4mNQo+IC0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5n
IiA+JjY7IH0KPiAtdGVzdCAkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcgPSBubyAmJiBjYXNl
ICIgJExJQk9CSlMgIiBpbgo+IC0gICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7Cj4gLSAg
KikgTElCT0JKUz0iJExJQk9CSlMgc3Rybmxlbi4kYWNfb2JqZXh0Igo+IC0gOzsKPiAtZXNhYwo+
ICsgIExJQlM9Ii1seWFqbCAkTElCUyIKPiAKPiArZWxzZQo+ICsgIGFzX2ZuX2Vycm9yICQ/ICJD
b3VsZCBub3QgZmluZCB5YWpsIiAiJExJTkVOTyIgNQo+ICtmaQo+IAo+IC17ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZCIg
PiY1Cj4gLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZC4uLiAiID4mNjsg
fQo+IC1pZiB0ZXN0ICIke2FjX2N2X2Z1bmNfc3RydG9kK3NldH0iID0gc2V0OyB0aGVuIDoKPiAr
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZGVm
bGF0ZUNvcHkgaW4gLWx6IiA+JjUKPiArJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGRlZmxhdGVD
b3B5IGluIC1sei4uLiAiID4mNjsgfQo+ICtpZiB0ZXN0ICIke2FjX2N2X2xpYl96X2RlZmxhdGVD
b3B5K3NldH0iID0gc2V0OyB0aGVuIDoKPiAgICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgo+
ICBlbHNlCj4gLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgo+IC0g
IGFjX2N2X2Z1bmNfc3RydG9kPW5vCj4gLWVsc2UKPiAtICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0Cj4gKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwo+
ICtMSUJTPSItbHogICRMSUJTIgo+ICtjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0Cj4gIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KPiAKPiAtJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQKPiAtI2lmbmRlZiBzdHJ0b2QKPiAtZG91YmxlIHN0cnRvZCAoKTsKPiArLyogT3ZlcnJp
ZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCj4gKyAgIFVz
ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwo+
ICsgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg
YXBwbHkuICAqLwo+ICsjaWZkZWYgX19jcGx1c3BsdXMKPiArZXh0ZXJuICJDIgo+ICAjZW5kaWYK
PiArY2hhciBkZWZsYXRlQ29weSAoKTsKPiAgaW50Cj4gLW1haW4oKQo+ICttYWluICgpCj4gIHsK
PiAtICB7Cj4gLSAgICAvKiBTb21lIHZlcnNpb25zIG9mIExpbnV4IHN0cnRvZCBtaXMtcGFyc2Ug
c3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KPiAtICAgIGNoYXIgKnN0cmluZyA9ICIgKzY5
IjsKPiAtICAgIGNoYXIgKnRlcm07Cj4gLSAgICBkb3VibGUgdmFsdWU7Cj4gLSAgICB2YWx1ZSA9
IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Cj4gLSAgICBpZiAodmFsdWUgIT0gNjkgfHwgdGVybSAh
PSAoc3RyaW5nICsgNCkpCj4gLSAgICAgIHJldHVybiAxOwo+IC0gIH0KPiAtCj4gLSAgewo+IC0g
ICAgLyogVW5kZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5zIHRoZSB3cm9uZyB2YWx1ZSBm
b3IgdGhlCj4gLSAgICAgICB0ZXJtaW5hdGluZyBjaGFyYWN0ZXIgdW5kZXIgc29tZSBjb25kaXRp
b25zLiAgKi8KPiAtICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOwo+IC0gICAgY2hhciAqdGVybTsK
PiAtICAgIHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Cj4gLSAgICBpZiAodGVybSAhPSBzdHJpbmcg
JiYgKih0ZXJtIC0gMSkgPT0gMCkKPiAtICAgICAgcmV0dXJuIDE7Cj4gLSAgfQo+ICtyZXR1cm4g
ZGVmbGF0ZUNvcHkgKCk7Cj4gKyAgOwo+ICAgIHJldHVybiAwOwo+ICB9Cj4gLQo+ICBfQUNFT0YK
PiAtaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfZnVuY19z
dHJ0b2Q9eWVzCj4gK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKPiArICBh
Y19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKPiAgZWxzZQo+IC0gIGFjX2N2X2Z1bmNfc3RydG9k
PW5vCj4gLWZpCj4gLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBi
Yi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKPiAtICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAo+ICsgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5v
Cj4gIGZpCj4gLQo+ICtybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IFwKPiArICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Cj4gK0xJQlM9JGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlMKPiAgZmkKPiAteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3N0cnRvZCIgPiY1Cj4gLSRhc19lY2hv
ICIkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNjsgfQo+IC1pZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRv
ZCA9IG5vOyB0aGVuCj4gLSAgY2FzZSAiICRMSUJPQkpTICIgaW4KPiAtICAqIiBzdHJ0b2QuJGFj
X29iamV4dCAiKiApIDs7Cj4gLSAgKikgTElCT0JKUz0iJExJQk9CSlMgc3RydG9kLiRhY19vYmpl
eHQiCj4gLSA7Owo+IC1lc2FjCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4mNQo+ICskYXNfZWNobyAi
JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KPiAraWYgdGVzdCAieCRhY19jdl9saWJf
el9kZWZsYXRlQ29weSIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsgIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKPiArI2RlZmluZSBIQVZFX0xJQlogMQo+ICtfQUNFT0YKPiAKPiAtYWNfZm5fY19jaGVj
a19mdW5jICIkTElORU5PIiAicG93IiAiYWNfY3ZfZnVuY19wb3ciCj4gLWlmIHRlc3QgIngkYWNf
Y3ZfZnVuY19wb3ciID0geCIieWVzOyB0aGVuIDoKPiArICBMSUJTPSItbHogJExJQlMiCj4gCj4g
K2Vsc2UKPiArICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgemxpYiIgIiRMSU5FTk8i
IDUKPiAgZmkKPiAKPiAtaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBubzsgdGhlbgo+IC0gIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHBvdyBp
biAtbG0iID4mNQo+IC0kYXNfZWNob19uICJjaGVja2luZyBmb3IgcG93IGluIC1sbS4uLiAiID4m
NjsgfQo+IC1pZiB0ZXN0ICIke2FjX2N2X2xpYl9tX3BvdytzZXR9IiA9IHNldDsgdGhlbiA6Cj4g
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGxp
Ymljb252X29wZW4gaW4gLWxpY29udiIgPiY1Cj4gKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBs
aWJpY29udl9vcGVuIGluIC1saWNvbnYuLi4gIiA+JjY7IH0KPiAraWYgdGVzdCAiJHthY19jdl9s
aWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6Cj4gICAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKPiAgZWxzZQo+ICAgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKPiAtTElCUz0iLWxtICAkTElCUyIKPiArTElCUz0iLWxpY29udiAgJExJQlMiCj4gIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgLyogZW5kIGNvbmZkZWZz
LmguICAqLwo+IAo+IEBAIC05NTI4LDU1ICs2NTUzLDQ1IEBAIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKPiAgI2lmZGVmIF9fY3BsdXNwbHVzCj4gIGV4dGVybiAi
QyIKPiAgI2VuZGlmCj4gLWNoYXIgcG93ICgpOwo+ICtjaGFyIGxpYmljb252X29wZW4gKCk7Cj4g
IGludAo+ICBtYWluICgpCj4gIHsKPiAtcmV0dXJuIHBvdyAoKTsKPiArcmV0dXJuIGxpYmljb252
X29wZW4gKCk7Cj4gICAgOwo+ICAgIHJldHVybiAwOwo+ICB9Cj4gIF9BQ0VPRgo+ICBpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cj4gLSAgYWNfY3ZfbGliX21fcG93PXllcwo+
ICsgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwo+ICBlbHNlCj4gLSAgYWNfY3Zf
bGliX21fcG93PW5vCj4gKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KPiAgZmkK
PiAgcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCj4gICAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAo+ICBMSUJTPSRhY19jaGVja19saWJf
c2F2ZV9MSUJTCj4gIGZpCj4gLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX21fcG93IiA+JjUKPiAtJGFzX2VjaG8gIiRhY19jdl9saWJf
bV9wb3ciID4mNjsgfQo+IC1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9tX3BvdyIgPSB4IiJ5ZXM7IHRo
ZW4gOgo+IC0gIFBPV19MSUI9LWxtCj4gK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNQo+ICsk
YXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjY7IH0KPiAraWYgdGVz
dCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgo+ICsg
IGxpYmljb252PSJ5Igo+ICBlbHNlCj4gLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5p
dGlvbiBvZiBwb3ciID4mNQo+IC0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYW5ub3QgZmlu
ZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mMjt9Cj4gLWZpCj4gLQo+
ICsgIGxpYmljb252PSJuIgo+ICBmaQo+IAo+IC1maQo+IAo+IC1mb3IgYWNfZnVuYyBpbiAgXAo+
IC0gICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBm
ZGF0YXN5bmMgZnRydW5jYXRlIFwKPiAtICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0Ynlu
YW1lIGdldGhvc3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCj4gLSAgICAgICAgICAg
ICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQg
bWtkaXIgXAo+IC0gICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0
aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAo+IC0gICAgICAgICAgICAgICAgc29ja2V0
IHN0cmNhc2VjbXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAo+IC0g
ICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRv
dWwgc3RydG91bGwgdHpzZXQgXAo+IC0gICAgICAgICAgICAgICAgdW5hbWUgXAo+IAo+ICsjIENo
ZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgo+ICtmb3IgYWNfaGVhZGVyIGluIHlhamwveWFqbF92ZXJz
aW9uLmgKPiAgZG8gOgo+IC0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1
bmMiIHwgJGFzX3RyX3NoYAo+IC1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVu
YyIgIiRhc19hY192YXIiCj4gLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5
ZXMiOyB0aGVuIDoKPiArICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAi
eWFqbC95YWpsX3ZlcnNpb24uaCIgImFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiAi
JGFjX2luY2x1ZGVzX2RlZmF1bHQiCj4gK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3lhamxfeWFq
bF92ZXJzaW9uX2giID0geCIieWVzOyB0aGVuIDoKPiAgICBjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCj4gLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEK
PiArI2RlZmluZSBIQVZFX1lBSkxfWUFKTF9WRVJTSU9OX0ggMQo+ICBfQUNFT0YKPiAKPiAgZmkK
PiArCj4gIGRvbmUKPiAKPiAKPiBkaWZmIC0tZ2l0IGEvdG9vbHMvY29uZmlndXJlLmFjIGIvdG9v
bHMvY29uZmlndXJlLmFjCj4gaW5kZXggNTdjODg3ZC4uZGViODQ4ZCAxMDA2NDQKPiAtLS0gYS90
b29scy9jb25maWd1cmUuYWMKPiArKysgYi90b29scy9jb25maWd1cmUuYWMKPiBAQCAtMTksOSAr
MTksNiBAQCByZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBc
Cj4gIEFQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBpbnN0ZWFkIHdoZW4gcG9zc2libGUu
XSkKPiAgXSkKPiAKPiAtQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCj4gLUFDX0NBTk9OSUNBTF9I
T1NUCj4gLQo+ICAjIE00IE1hY3JvIGluY2x1ZGVzCj4gIG00X2luY2x1ZGUoW200L3NhdmV2YXIu
bTRdKQo+ICBtNF9pbmNsdWRlKFttNC9mZWF0dXJlcy5tNF0pCj4gQEAgLTc1LDkgKzcyLDcgQEAg
QUNfQVJHX1ZBUihbQkNDXSwgW1BhdGggdG8gYmNjIHRvb2xdKQo+ICBBQ19BUkdfVkFSKFtJQVNM
XSwgW1BhdGggdG8gaWFzbCB0b29sXSkKPiAKPiAgIyBDaGVja3MgZm9yIHByb2dyYW1zLgo+IC1B
Q19QUk9HX1NFRAo+ICBBQ19QUk9HX0NDCj4gLUFDX1BST0dfTE5fUwo+ICBBQ19QUk9HX01BS0Vf
U0VUCj4gIEFDX1BST0dfSU5TVEFMTAo+ICBBQ19QQVRIX1BST0coW0JJU09OXSwgW2Jpc29uXSkK
PiBAQCAtMTM3LDcgKzEzMiw2IEBAIEFDX1NVQlNUKGxpYmV4dDJmcykKPiAgQUNfQ0hFQ0tfTElC
KFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdj
cnlwdD0ibiJdKQo+ICBBQ19TVUJTVChsaWJnY3J5cHQpCj4gIEFYX0NIRUNLX1BUSFJFQUQKPiAt
QUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1lXSkKPiAgQUNfQ0hFQ0tfTElCKFt5YWps
XSwgW3lhamxfYWxsb2NdLCBbXSwKPiAgICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5k
IHlhamxdKV0pCj4gIEFDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNfTVNH
X0VSUk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQo+IEBAIC0xNDUsNTggKzEzOSw2IEBAIEFD
X0NIRUNLX0xJQihbaWNvbnZdLCBbbGliaWNvbnZfb3Blbl0sIFtsaWJpY29udj0ieSJdLCBbbGli
aWNvbnY9Im4iXSkKPiAgQUNfU1VCU1QobGliaWNvbnYpCj4gCj4gICMgQ2hlY2tzIGZvciBoZWFk
ZXIgZmlsZXMuCj4gLUFDX0ZVTkNfQUxMT0NBCj4gLUFDX0NIRUNLX0hFQURFUlMoWyBcCj4gLSAg
ICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGludHR5cGVzLmggbGliaW50bC5oIGxp
bWl0cy5oIG1hbGxvYy5oIFwKPiAtICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5o
IHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKPiAtICAgICAgICAgICAgICAg
IHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5oIHN5cy9tb3VudC5oIHN5cy9wYXJhbS5o
IFwKPiAtICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3RhdHZmcy5oIHN5cy90aW1l
Lmggc3lzbG9nLmggdGVybWlvcy5oIFwKPiAtICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwv
eWFqbF92ZXJzaW9uLmggXAo+IC0gICAgICAgICAgICAgICAgXSkKPiAtCj4gLSMgQ2hlY2tzIGZv
ciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KPiAt
QUNfSEVBREVSX1NUREJPT0wKPiAtQUNfVFlQRV9VSURfVAo+IC1BQ19DX0lOTElORQo+IC1BQ19U
WVBFX0lOVDE2X1QKPiAtQUNfVFlQRV9JTlQzMl9UCj4gLUFDX1RZUEVfSU5UNjRfVAo+IC1BQ19U
WVBFX0lOVDhfVAo+IC1BQ19UWVBFX01PREVfVAo+IC1BQ19UWVBFX09GRl9UCj4gLUFDX1RZUEVf
UElEX1QKPiAtQUNfQ19SRVNUUklDVAo+IC1BQ19UWVBFX1NJWkVfVAo+IC1BQ19UWVBFX1NTSVpF
X1QKPiAtQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCj4gLUFDX1NU
UlVDVF9TVF9CTE9DS1MKPiAtQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfcmRldl0p
Cj4gLUFDX1RZUEVfVUlOVDE2X1QKPiAtQUNfVFlQRV9VSU5UMzJfVAo+IC1BQ19UWVBFX1VJTlQ2
NF9UCj4gLUFDX1RZUEVfVUlOVDhfVAo+IC1BQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKPiAt
Cj4gLSMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KPiAtQUNfRlVOQ19FUlJPUl9BVF9M
SU5FCj4gLUFDX0ZVTkNfRk9SSwo+IC1BQ19GVU5DX0ZTRUVLTwo+IC1BQ19GVU5DX0xTVEFUX0ZP
TExPV1NfU0xBU0hFRF9TWU1MSU5LCj4gLUFDX0hFQURFUl9NQUpPUgo+IC1BQ19GVU5DX01BTExP
Qwo+IC1BQ19GVU5DX01LVElNRQo+IC1BQ19GVU5DX01NQVAKPiAtQUNfRlVOQ19SRUFMTE9DCj4g
LUFDX0ZVTkNfU1RSTkxFTgo+IC1BQ19GVU5DX1NUUlRPRAo+IC1BQ19DSEVDS19GVU5DUyhbIFwK
PiAtICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIg
ZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCj4gLSAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5
bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAo+IC0gICAgICAgICAg
ICAgICAgaW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0
IG1rZGlyIFwKPiAtICAgICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBh
dGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKPiAtICAgICAgICAgICAgICAgIHNvY2tl
dCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKPiAt
ICAgICAgICAgICAgICAgIHN0cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0
b3VsIHN0cnRvdWxsIHR6c2V0IFwKPiAtICAgICAgICAgICAgICAgIHVuYW1lIFwKPiAtICAgICAg
ICAgICAgICAgIF0pCj4gK0FDX0NIRUNLX0hFQURFUlMoW3lhamwveWFqbF92ZXJzaW9uLmhdKQo+
IAo+ICBBQ19PVVRQVVQoKQo+IC0tCj4gMS43LjIuNQo+IAo+IAo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+
IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:08:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4lE-0003hL-3g; Wed, 25 Apr 2012 16:08:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN4lC-0003h6-Q9
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:08:07 +0000
Received: from [85.158.139.83:6268] by server-9.bemta-5.messagelabs.com id
	22/0B-09826-661289F4; Wed, 25 Apr 2012 16:08:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335370085!21528466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15131 invoked from network); 25 Apr 2012 16:08:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:08:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:08:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 17:08:04 +0100
Message-ID: <1335370083.28015.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 17:08:03 +0100
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v8 00/25] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> This incorporates changes from review.
> 
> These have already been acked, apart from 04/25,

I just acked it, I remember it from last time and was happy with it
apart from the stray PTYFUNC test.

> and could go into the tree very soon:

Yes.

> 
>   01/25 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
>   02/25 libxl: support multiple libxl__ev_fds for the same fd
>   03/25 libxl: event API: new facilities for waiting for subprocesses
> ! 04/25 autoconf: trim the configure script; use autoheader
>   05/25 autoconf: New test for openpty et al.
>   06/25 libxl: provide libxl__remove_file et al.
>   07/25 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
>   08/25 libxl: Clean up setdefault in do_domain_create
>   09/25 libxl: provide libxl__datacopier_*
>   10/25 libxl: provide libxl__openpty_*
>   11/25 libxl: ao: Convert libxl_run_bootloader
>   12/25 libxl: make libxl_create_logfile const-correct
>   13/25 libxl: log bootloader output
>   14/25 libxl: Allow AO_GC and EGC_GC even if not used
>   15/25 libxl: remove ctx->waitpid_instead
> 
> These are the remaining meat; all except 19/25 have been posted before
> and some have been acked:
>   
>   16/25 libxl: change some structures to unit arrays
>   17/25 libxl: ao: convert libxl__spawn_*
>   18/25 libxl: make libxl_create run bootloader via callback
> * 19/25 libxl: Fix an ao completion bug; document locking policy
>   20/25 libxl: provide progress reporting for long-running operations
>   21/25 libxl: remove malloc failure handling from NEW_EVENT
>   22/25 libxl: convert console callback to libxl_asyncprogress_how
>   23/25 libxl: clarify definition of "slow" operation
>   24/25 libxl: child processes cleanups
>   25/25 libxl: aborting bootloader invocation when domain dioes
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:08:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4lE-0003hL-3g; Wed, 25 Apr 2012 16:08:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SN4lC-0003h6-Q9
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:08:07 +0000
Received: from [85.158.139.83:6268] by server-9.bemta-5.messagelabs.com id
	22/0B-09826-661289F4; Wed, 25 Apr 2012 16:08:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335370085!21528466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15131 invoked from network); 25 Apr 2012 16:08:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:08:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:08:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 17:08:04 +0100
Message-ID: <1335370083.28015.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 17:08:03 +0100
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v8 00/25] libxl: subprocess handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> This incorporates changes from review.
> 
> These have already been acked, apart from 04/25,

I just acked it, I remember it from last time and was happy with it
apart from the stray PTYFUNC test.

> and could go into the tree very soon:

Yes.

> 
>   01/25 libxl: handle POLLERR, POLLHUP, POLLNVAL properly
>   02/25 libxl: support multiple libxl__ev_fds for the same fd
>   03/25 libxl: event API: new facilities for waiting for subprocesses
> ! 04/25 autoconf: trim the configure script; use autoheader
>   05/25 autoconf: New test for openpty et al.
>   06/25 libxl: provide libxl__remove_file et al.
>   07/25 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds
>   08/25 libxl: Clean up setdefault in do_domain_create
>   09/25 libxl: provide libxl__datacopier_*
>   10/25 libxl: provide libxl__openpty_*
>   11/25 libxl: ao: Convert libxl_run_bootloader
>   12/25 libxl: make libxl_create_logfile const-correct
>   13/25 libxl: log bootloader output
>   14/25 libxl: Allow AO_GC and EGC_GC even if not used
>   15/25 libxl: remove ctx->waitpid_instead
> 
> These are the remaining meat; all except 19/25 have been posted before
> and some have been acked:
>   
>   16/25 libxl: change some structures to unit arrays
>   17/25 libxl: ao: convert libxl__spawn_*
>   18/25 libxl: make libxl_create run bootloader via callback
> * 19/25 libxl: Fix an ao completion bug; document locking policy
>   20/25 libxl: provide progress reporting for long-running operations
>   21/25 libxl: remove malloc failure handling from NEW_EVENT
>   22/25 libxl: convert console callback to libxl_asyncprogress_how
>   23/25 libxl: clarify definition of "slow" operation
>   24/25 libxl: child processes cleanups
>   25/25 libxl: aborting bootloader invocation when domain dioes
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pM-00045G-AV; Wed, 25 Apr 2012 16:12:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pK-00044w-10
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:22 +0000
Received: from [193.109.254.147:22288] by server-12.bemta-14.messagelabs.com
	id 46/06-05898-562289F4; Wed, 25 Apr 2012 16:12:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16624 invoked from network); 25 Apr 2012 16:12:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137894"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bU-Rr; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rh-QZ;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:47 +0100
Message-ID: <1335369353-13012-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/25] libxl: Fix an ao completion bug;
	document locking policy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document the concurrent access policies for libxl__ao and libxl__egc,
and their corresponding gcs.

Fix a violation of the policy:

If an ao was submitted and a callback requested, and while the
initiating function was still running on the original thread, the ao
is completed on another thread, the completing thread would improperly
concurrently access the ao with the initiating thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 +++++++
 tools/libxl/libxl_internal.h |   23 ++++++++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 2f559d5..7e8d002 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -897,6 +897,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
 
 static void egc_run_callbacks(libxl__egc *egc)
 {
+    /*
+     * The callbacks must happen with the ctx unlocked.
+     * See the comment near #define EGC_GC in libxl_internal.h and
+     * those in the definitions of libxl__egc and libxl__ao.
+     */
     EGC_GC;
     libxl_event *ev, *ev_tmp;
 
@@ -910,9 +915,11 @@ static void egc_run_callbacks(libxl__egc *egc)
                              entry_for_callback, ao_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
         ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        CTX_LOCK;
         ao->notified = 1;
         if (!ao->in_initiator)
             libxl__ao__destroy(CTX, ao);
+        CTX_UNLOCK;
     }
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c238e86..26e0713 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -369,7 +369,8 @@ struct libxl__gc {
 };
 
 struct libxl__egc {
-    /* for event-generating functions only */
+    /* For event-generating functions only.
+     * The egc and its gc may be accessed only on the creating thread. */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
@@ -379,6 +380,20 @@ struct libxl__egc {
 #define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
 
 struct libxl__ao {
+    /*
+     * An ao and its gc may be accessed only with the ctx lock held.
+     *
+     * Special exception: If an ao has been added to
+     * egc->aos_for_callback, the thread owning the egc may remove the
+     * ao from that list and make the callback without holding the
+     * lock.
+     *
+     * Corresponding restriction: An ao may be added only to one
+     * egc->aos_for_callback, once; rc and how must already have been
+     * set and may not be subsequently modified.  (This restriction is
+     * easily and obviously met since the ao is queued for callback
+     * only in libxl__ao_complete.)
+     */
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
@@ -1356,6 +1371,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * should in any case not find it necessary to call egc-creators from
  * within libxl.
  *
+ * The callbacks must all take place with the ctx unlocked because
+ * the application is entitled to reenter libxl from them.  This
+ * would be bad not because the lock is not recursive (it is) but
+ * because the application might make blocking libxl calls which
+ * would hold the lock unreasonably long.
+ *
  * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
  * with the ctx *unlocked*.  So the right pattern has the EGC_...
  * macro calls on the outside of the CTX_... ones.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pM-00045G-AV; Wed, 25 Apr 2012 16:12:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pK-00044w-10
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:22 +0000
Received: from [193.109.254.147:22288] by server-12.bemta-14.messagelabs.com
	id 46/06-05898-562289F4; Wed, 25 Apr 2012 16:12:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16624 invoked from network); 25 Apr 2012 16:12:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137894"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bU-Rr; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rh-QZ;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:47 +0100
Message-ID: <1335369353-13012-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/25] libxl: Fix an ao completion bug;
	document locking policy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document the concurrent access policies for libxl__ao and libxl__egc,
and their corresponding gcs.

Fix a violation of the policy:

If an ao was submitted and a callback requested, and while the
initiating function was still running on the original thread, the ao
is completed on another thread, the completing thread would improperly
concurrently access the ao with the initiating thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 +++++++
 tools/libxl/libxl_internal.h |   23 ++++++++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 2f559d5..7e8d002 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -897,6 +897,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
 
 static void egc_run_callbacks(libxl__egc *egc)
 {
+    /*
+     * The callbacks must happen with the ctx unlocked.
+     * See the comment near #define EGC_GC in libxl_internal.h and
+     * those in the definitions of libxl__egc and libxl__ao.
+     */
     EGC_GC;
     libxl_event *ev, *ev_tmp;
 
@@ -910,9 +915,11 @@ static void egc_run_callbacks(libxl__egc *egc)
                              entry_for_callback, ao_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
         ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        CTX_LOCK;
         ao->notified = 1;
         if (!ao->in_initiator)
             libxl__ao__destroy(CTX, ao);
+        CTX_UNLOCK;
     }
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c238e86..26e0713 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -369,7 +369,8 @@ struct libxl__gc {
 };
 
 struct libxl__egc {
-    /* for event-generating functions only */
+    /* For event-generating functions only.
+     * The egc and its gc may be accessed only on the creating thread. */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
@@ -379,6 +380,20 @@ struct libxl__egc {
 #define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
 
 struct libxl__ao {
+    /*
+     * An ao and its gc may be accessed only with the ctx lock held.
+     *
+     * Special exception: If an ao has been added to
+     * egc->aos_for_callback, the thread owning the egc may remove the
+     * ao from that list and make the callback without holding the
+     * lock.
+     *
+     * Corresponding restriction: An ao may be added only to one
+     * egc->aos_for_callback, once; rc and how must already have been
+     * set and may not be subsequently modified.  (This restriction is
+     * easily and obviously met since the ao is queued for callback
+     * only in libxl__ao_complete.)
+     */
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
@@ -1356,6 +1371,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * should in any case not find it necessary to call egc-creators from
  * within libxl.
  *
+ * The callbacks must all take place with the ctx unlocked because
+ * the application is entitled to reenter libxl from them.  This
+ * would be bad not because the lock is not recursive (it is) but
+ * because the application might make blocking libxl calls which
+ * would hold the lock unreasonably long.
+ *
  * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
  * with the ctx *unlocked*.  So the right pattern has the EGC_...
  * macro calls on the outside of the CTX_... ones.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pN-00045m-Gc; Wed, 25 Apr 2012 16:12:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pL-000452-RM
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:24 +0000
Received: from [193.109.254.147:63279] by server-7.bemta-14.messagelabs.com id
	F7/8E-01627-762289F4; Wed, 25 Apr 2012 16:12:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16716 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bZ-Ua; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rl-Rd;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:48 +0100
Message-ID: <1335369353-13012-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/25] libxl: provide progress reporting for
	long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used for reporting, during domain creation, that the
console is ready.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v7:
 * If aop->how.callback, actually add the aop to the for_callback list (!)
 * Document the threadsafety of aop's, and make appropriate cross-references.
 * Allocate the actual aop from its thread's egc; do not free it.
 * Remove pointless code motion of libxl__ao_create.
 * Minor formatting fixes.
---
 tools/libxl/libxl.h          |   45 ++++++++++++++++++++++++++
 tools/libxl/libxl_event.c    |   72 ++++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |   35 ++++++++++++++++++++
 3 files changed, 149 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b497430..7bd6231 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -435,6 +435,51 @@ typedef struct {
     } u;
 } libxl_asyncop_how;
 
+/*
+ * Some more complex asynchronous operations can report intermediate
+ * progress.  How this is to be reported is controlled, for each
+ * function, by a parameter
+ *    libxl_asyncprogress_how *aop_FOO_how;
+ * for each kind of progress FOO supported by that function.  Each
+ * such kind of progress is associated with an event type.
+ *
+ * The function description will document whether, when, and how
+ * many times, the intermediate progress will be reported, and
+ * what the corresponding event type(s) are.
+ *
+ * If aop_FOO_how==NULL, intermediate progress reports are discarded.
+ *
+ * If aop_FOO_how->callback==NULL, intermediate progress reports
+ * generate libxl events which can be obtained from libxl_event_wait
+ * or libxl_event_check.
+ *
+ * If aop_FOO_how->callback!=NULL, libxl will report intermediate
+ * progress by calling callback(ctx, &event, for_callback).
+ *
+ * The rules for these events are otherwise the same as those for
+ * ordinary events.  The reentrancy and threading rules for the
+ * callback are the same as those for ao completion callbacks.
+ *
+ * Note that the callback, if provided, is responsible for freeing
+ * the event.
+ *
+ * If callbacks are requested, they will be made, and returned, before
+ * the long-running libxl operation is considered finished (so if the
+ * long-running libxl operation was invoked with ao_how==NULL then any
+ * callbacks will occur strictly before the long-running operation
+ * returns).  However, the callbacks may occur on any thread.
+ *
+ * In general, otherwise, no promises are made about the relative
+ * order of callbacks in a multithreaded program.  In particular
+ * different callbacks relating to the same long-running operation may
+ * be delivered out of order.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback);
+    libxl_ev_user for_event; /* always used */
+    void *for_callback; /* passed to callback */
+} libxl_asyncprogress_how;
 
 #define LIBXL_VERSION 0
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 7e8d002..02deea5 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -898,18 +898,29 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
 static void egc_run_callbacks(libxl__egc *egc)
 {
     /*
-     * The callbacks must happen with the ctx unlocked.
-     * See the comment near #define EGC_GC in libxl_internal.h and
-     * those in the definitions of libxl__egc and libxl__ao.
+     * The callbacks must happen with the ctx unlocked.  See the
+     * comment near #define EGC_GC in libxl_internal.h and those in
+     * the definitions of libxl__egc, libxl__ao and libxl__aop.
      */
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+    libxl__aop_occurred *aop, *aop_tmp;
 
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
 
+    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
+        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
+
+        CTX_LOCK;
+        aop->ao->progress_reports_outstanding--;
+        libxl__ao_complete_check_progress_reports(egc, aop->ao);
+        CTX_UNLOCK;
+    }
+
     libxl__ao *ao, *ao_tmp;
     LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
                              entry_for_callback, ao_tmp) {
@@ -1292,6 +1303,7 @@ void libxl__ao_abort(libxl__ao *ao)
     assert(ao->magic == LIBXL__AO_MAGIC);
     assert(ao->in_initiator);
     assert(!ao->complete);
+    assert(!ao->progress_reports_outstanding);
     libxl__ao__destroy(CTX, ao);
 }
 
@@ -1302,6 +1314,24 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
     ao->complete = 1;
     ao->rc = rc;
 
+    libxl__ao_complete_check_progress_reports(egc, ao);
+}
+
+void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+{
+    /*
+     * We don't consider an ao complete if it has any outstanding
+     * callbacks.  These callbacks might be outstanding on other
+     * threads, queued up in the other threads' egc's.  Those threads
+     * will, after making the callback, take out the lock again,
+     * decrement progress_reports_outstanding, and call us again.
+     */
+
+    assert(ao->progress_reports_outstanding >= 0);
+
+    if (!ao->complete || ao->progress_reports_outstanding)
+        return;
+
     if (ao->poller) {
         assert(ao->in_initiator);
         if (!ao->constructing)
@@ -1351,6 +1381,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     return NULL;
 }
 
+
 int libxl__ao_inprogress(libxl__ao *ao)
 {
     AO_GC;
@@ -1408,6 +1439,41 @@ int libxl__ao_inprogress(libxl__ao *ao)
 }
 
 
+/* progress reporting */
+
+/* The application indicates a desire to ignore events by passing NULL
+ * for how.  But we want to copy *how.  So we have this dummy function
+ * whose address is stored in callback if the app passed how==NULL. */
+static void dummy_asyncprogress_callback_ignore
+  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
+
+void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                               const libxl_asyncprogress_how *from_app) {
+    if (from_app)
+        *in_state = *from_app;
+    else
+        in_state->callback = dummy_asyncprogress_callback_ignore;
+}
+
+void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+        const libxl_asyncprogress_how *how, libxl_event *ev)
+{
+    ev->for_user = how->for_event;
+    if (how->callback == dummy_asyncprogress_callback_ignore) {
+        /* ignore */
+    } else if (how->callback) {
+        libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
+        ao->progress_reports_outstanding++;
+        aop->ao = ao;
+        aop->ev = ev;
+        aop->how = how;
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aops_for_callback, aop, entry);
+    } else {
+        libxl__event_occurred(egc, ev);
+    }
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 26e0713..d9dfd6d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -118,6 +118,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
+typedef struct libxl__aop_occurred libxl__aop_occurred;
 
 _hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
@@ -374,6 +375,21 @@ struct libxl__egc {
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback;
+};
+
+struct libxl__aop_occurred {
+    /*
+     * An aop belongs to, and may be accessed only on, the thread
+     * which created it.  It normally lives in that thread's egc.
+     *
+     * While an aop exists, it corresponds to one refcount in
+     * ao->progress_reports_outstanding, preventing ao destruction.
+     */
+    LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry;
+    libxl__ao *ao;
+    libxl_event *ev;
+    const libxl_asyncprogress_how *how;
 };
 
 #define LIBXL__AO_MAGIC              0xA0FACE00ul
@@ -396,6 +412,7 @@ struct libxl__ao {
      */
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
+    int progress_reports_outstanding;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1393,6 +1410,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
         LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
+        LIBXL_TAILQ_INIT(&(egc).aops_for_callback);     \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1439,6 +1457,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *        pointer to the internal event generation request routines
  *        libxl__evgen_FOO, so that at some point a CALLBACK will be
  *        made when the operation is complete.
+ *      - if the operation provides progress reports, the aop_how(s)
+ *        must be copied into the per-operation structure using
+ *        libxl__ao_progress_gethow.
  *
  * - If initiation is successful, the initiating function needs
  *   to run libxl__ao_inprogress right before unlocking and
@@ -1448,6 +1469,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   call libxl__ao_abort before unlocking and returning whatever
  *   error code is appropriate (AO_ABORT macro).
  *
+ * - If the operation supports progress reports, it may generate
+ *   suitable events with NEW_EVENT and report them with
+ *   libxl__ao_progress_report (with the ctx locked).
+ *
  * - Later, some callback function, whose callback has been requested
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
@@ -1503,8 +1528,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
+/* Can be called at any time.  Use is essential for any aop user. */
+_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                                       const libxl_asyncprogress_how *from_app);
+
+/* Must be called with the ctx locked.  Will fill in ev->for_user,
+ * so caller need not do that. */
+_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+   const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */);
+
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*);
 
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pN-00045m-Gc; Wed, 25 Apr 2012 16:12:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pL-000452-RM
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:24 +0000
Received: from [193.109.254.147:63279] by server-7.bemta-14.messagelabs.com id
	F7/8E-01627-762289F4; Wed, 25 Apr 2012 16:12:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16716 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bZ-Ua; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rl-Rd;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:48 +0100
Message-ID: <1335369353-13012-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/25] libxl: provide progress reporting for
	long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used for reporting, during domain creation, that the
console is ready.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes since v7:
 * If aop->how.callback, actually add the aop to the for_callback list (!)
 * Document the threadsafety of aop's, and make appropriate cross-references.
 * Allocate the actual aop from its thread's egc; do not free it.
 * Remove pointless code motion of libxl__ao_create.
 * Minor formatting fixes.
---
 tools/libxl/libxl.h          |   45 ++++++++++++++++++++++++++
 tools/libxl/libxl_event.c    |   72 ++++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |   35 ++++++++++++++++++++
 3 files changed, 149 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b497430..7bd6231 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -435,6 +435,51 @@ typedef struct {
     } u;
 } libxl_asyncop_how;
 
+/*
+ * Some more complex asynchronous operations can report intermediate
+ * progress.  How this is to be reported is controlled, for each
+ * function, by a parameter
+ *    libxl_asyncprogress_how *aop_FOO_how;
+ * for each kind of progress FOO supported by that function.  Each
+ * such kind of progress is associated with an event type.
+ *
+ * The function description will document whether, when, and how
+ * many times, the intermediate progress will be reported, and
+ * what the corresponding event type(s) are.
+ *
+ * If aop_FOO_how==NULL, intermediate progress reports are discarded.
+ *
+ * If aop_FOO_how->callback==NULL, intermediate progress reports
+ * generate libxl events which can be obtained from libxl_event_wait
+ * or libxl_event_check.
+ *
+ * If aop_FOO_how->callback!=NULL, libxl will report intermediate
+ * progress by calling callback(ctx, &event, for_callback).
+ *
+ * The rules for these events are otherwise the same as those for
+ * ordinary events.  The reentrancy and threading rules for the
+ * callback are the same as those for ao completion callbacks.
+ *
+ * Note that the callback, if provided, is responsible for freeing
+ * the event.
+ *
+ * If callbacks are requested, they will be made, and returned, before
+ * the long-running libxl operation is considered finished (so if the
+ * long-running libxl operation was invoked with ao_how==NULL then any
+ * callbacks will occur strictly before the long-running operation
+ * returns).  However, the callbacks may occur on any thread.
+ *
+ * In general, otherwise, no promises are made about the relative
+ * order of callbacks in a multithreaded program.  In particular
+ * different callbacks relating to the same long-running operation may
+ * be delivered out of order.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback);
+    libxl_ev_user for_event; /* always used */
+    void *for_callback; /* passed to callback */
+} libxl_asyncprogress_how;
 
 #define LIBXL_VERSION 0
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 7e8d002..02deea5 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -898,18 +898,29 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
 static void egc_run_callbacks(libxl__egc *egc)
 {
     /*
-     * The callbacks must happen with the ctx unlocked.
-     * See the comment near #define EGC_GC in libxl_internal.h and
-     * those in the definitions of libxl__egc and libxl__ao.
+     * The callbacks must happen with the ctx unlocked.  See the
+     * comment near #define EGC_GC in libxl_internal.h and those in
+     * the definitions of libxl__egc, libxl__ao and libxl__aop.
      */
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+    libxl__aop_occurred *aop, *aop_tmp;
 
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
 
+    LIBXL_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry);
+        aop->how->callback(CTX, aop->ev, aop->how->for_callback);
+
+        CTX_LOCK;
+        aop->ao->progress_reports_outstanding--;
+        libxl__ao_complete_check_progress_reports(egc, aop->ao);
+        CTX_UNLOCK;
+    }
+
     libxl__ao *ao, *ao_tmp;
     LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
                              entry_for_callback, ao_tmp) {
@@ -1292,6 +1303,7 @@ void libxl__ao_abort(libxl__ao *ao)
     assert(ao->magic == LIBXL__AO_MAGIC);
     assert(ao->in_initiator);
     assert(!ao->complete);
+    assert(!ao->progress_reports_outstanding);
     libxl__ao__destroy(CTX, ao);
 }
 
@@ -1302,6 +1314,24 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
     ao->complete = 1;
     ao->rc = rc;
 
+    libxl__ao_complete_check_progress_reports(egc, ao);
+}
+
+void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+{
+    /*
+     * We don't consider an ao complete if it has any outstanding
+     * callbacks.  These callbacks might be outstanding on other
+     * threads, queued up in the other threads' egc's.  Those threads
+     * will, after making the callback, take out the lock again,
+     * decrement progress_reports_outstanding, and call us again.
+     */
+
+    assert(ao->progress_reports_outstanding >= 0);
+
+    if (!ao->complete || ao->progress_reports_outstanding)
+        return;
+
     if (ao->poller) {
         assert(ao->in_initiator);
         if (!ao->constructing)
@@ -1351,6 +1381,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     return NULL;
 }
 
+
 int libxl__ao_inprogress(libxl__ao *ao)
 {
     AO_GC;
@@ -1408,6 +1439,41 @@ int libxl__ao_inprogress(libxl__ao *ao)
 }
 
 
+/* progress reporting */
+
+/* The application indicates a desire to ignore events by passing NULL
+ * for how.  But we want to copy *how.  So we have this dummy function
+ * whose address is stored in callback if the app passed how==NULL. */
+static void dummy_asyncprogress_callback_ignore
+  (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { }
+
+void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                               const libxl_asyncprogress_how *from_app) {
+    if (from_app)
+        *in_state = *from_app;
+    else
+        in_state->callback = dummy_asyncprogress_callback_ignore;
+}
+
+void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+        const libxl_asyncprogress_how *how, libxl_event *ev)
+{
+    ev->for_user = how->for_event;
+    if (how->callback == dummy_asyncprogress_callback_ignore) {
+        /* ignore */
+    } else if (how->callback) {
+        libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
+        ao->progress_reports_outstanding++;
+        aop->ao = ao;
+        aop->ev = ev;
+        aop->how = how;
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aops_for_callback, aop, entry);
+    } else {
+        libxl__event_occurred(egc, ev);
+    }
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 26e0713..d9dfd6d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -118,6 +118,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
+typedef struct libxl__aop_occurred libxl__aop_occurred;
 
 _hidden void libxl__alloc_failed(libxl_ctx *, const char *func,
                          size_t nmemb, size_t size) __attribute__((noreturn));
@@ -374,6 +375,21 @@ struct libxl__egc {
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
     LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback;
+};
+
+struct libxl__aop_occurred {
+    /*
+     * An aop belongs to, and may be accessed only on, the thread
+     * which created it.  It normally lives in that thread's egc.
+     *
+     * While an aop exists, it corresponds to one refcount in
+     * ao->progress_reports_outstanding, preventing ao destruction.
+     */
+    LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry;
+    libxl__ao *ao;
+    libxl_event *ev;
+    const libxl_asyncprogress_how *how;
 };
 
 #define LIBXL__AO_MAGIC              0xA0FACE00ul
@@ -396,6 +412,7 @@ struct libxl__ao {
      */
     uint32_t magic;
     unsigned constructing:1, in_initiator:1, complete:1, notified:1;
+    int progress_reports_outstanding;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1393,6 +1410,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
         LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
+        LIBXL_TAILQ_INIT(&(egc).aops_for_callback);     \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1439,6 +1457,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *        pointer to the internal event generation request routines
  *        libxl__evgen_FOO, so that at some point a CALLBACK will be
  *        made when the operation is complete.
+ *      - if the operation provides progress reports, the aop_how(s)
+ *        must be copied into the per-operation structure using
+ *        libxl__ao_progress_gethow.
  *
  * - If initiation is successful, the initiating function needs
  *   to run libxl__ao_inprogress right before unlocking and
@@ -1448,6 +1469,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   call libxl__ao_abort before unlocking and returning whatever
  *   error code is appropriate (AO_ABORT macro).
  *
+ * - If the operation supports progress reports, it may generate
+ *   suitable events with NEW_EVENT and report them with
+ *   libxl__ao_progress_report (with the ctx locked).
+ *
  * - Later, some callback function, whose callback has been requested
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
@@ -1503,8 +1528,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
+/* Can be called at any time.  Use is essential for any aop user. */
+_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state,
+                                       const libxl_asyncprogress_how *from_app);
+
+/* Must be called with the ctx locked.  Will fill in ev->for_user,
+ * so caller need not do that. */
+_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
+   const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */);
+
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*);
 
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pN-00045b-3b; Wed, 25 Apr 2012 16:12:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pL-000451-Oa
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:23 +0000
Received: from [193.109.254.147:22448] by server-11.bemta-14.messagelabs.com
	id 34/B7-05858-662289F4; Wed, 25 Apr 2012 16:12:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16709 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bb-01; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rp-UI;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:49 +0100
Message-ID: <1335369353-13012-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/25] libxl: remove malloc failure handling
	from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to use libxl__zalloc, where allocation failure is fatal.

Also remove a spurious semicolon from the helper macro.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    2 --
 tools/libxl/libxl_event.c    |    8 +-------
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9238916..38e376c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -779,7 +779,6 @@ static void domain_death_occurred(libxl__egc *egc,
     *evg_upd = evg_next;
 
     libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
-    if (!ev) return;
 
     libxl__event_occurred(egc, ev);
 
@@ -866,7 +865,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                if (!ev) goto out;
                 
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 02deea5..f726fc2 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -985,13 +985,7 @@ libxl_event *libxl__event_new(libxl__egc *egc,
 {
     libxl_event *ev;
 
-    ev = malloc(sizeof(*ev));
-    if (!ev) {
-        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
-        return NULL;
-    }
-
-    memset(ev, 0, sizeof(*ev));
+    ev = libxl__zalloc(0,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d9dfd6d..4adbb5f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -664,10 +664,10 @@ _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
                                       uint32_t domid);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
-   * If allocation fails, calls _disaster, and returns NULL. */
+   * Cannot fail. */
 
 #define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
     /* Convenience macro. */
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pN-00045b-3b; Wed, 25 Apr 2012 16:12:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pL-000451-Oa
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:23 +0000
Received: from [193.109.254.147:22448] by server-11.bemta-14.messagelabs.com
	id 34/B7-05858-662289F4; Wed, 25 Apr 2012 16:12:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16709 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZS-0007bb-01; Wed, 25 Apr 2012 15:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003Rp-UI;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:49 +0100
Message-ID: <1335369353-13012-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/25] libxl: remove malloc failure handling
	from NEW_EVENT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to use libxl__zalloc, where allocation failure is fatal.

Also remove a spurious semicolon from the helper macro.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    2 --
 tools/libxl/libxl_event.c    |    8 +-------
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9238916..38e376c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -779,7 +779,6 @@ static void domain_death_occurred(libxl__egc *egc,
     *evg_upd = evg_next;
 
     libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
-    if (!ev) return;
 
     libxl__event_occurred(egc, ev);
 
@@ -866,7 +865,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                if (!ev) goto out;
                 
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 02deea5..f726fc2 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -985,13 +985,7 @@ libxl_event *libxl__event_new(libxl__egc *egc,
 {
     libxl_event *ev;
 
-    ev = malloc(sizeof(*ev));
-    if (!ev) {
-        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
-        return NULL;
-    }
-
-    memset(ev, 0, sizeof(*ev));
+    ev = libxl__zalloc(0,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d9dfd6d..4adbb5f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -664,10 +664,10 @@ _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
                                       uint32_t domid);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
-   * If allocation fails, calls _disaster, and returns NULL. */
+   * Cannot fail. */
 
 #define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
     /* Convenience macro. */
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pP-00046U-43; Wed, 25 Apr 2012 16:12:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pM-000453-2H
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:24 +0000
Received: from [85.158.138.51:65325] by server-1.bemta-3.messagelabs.com id
	5C/36-11491-762289F4; Wed, 25 Apr 2012 16:12:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335370342!23596696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b6-BY; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003R5-9P;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:39 +0100
Message-ID: <1335369353-13012-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/25] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Use libxl__ev_child_inuse rather than testing pid directly.
 * Fix a code style error.
 * Properly initialise the sub-operations' aos in _init.
 * Bugfixes.
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  713 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 419 insertions(+), 343 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b6ff270..9238916 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fb90aed..3087146 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -495,7 +495,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..bdc4cb4 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl->ao);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,217 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    return pid;
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
+
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl->ao);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
-        }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-    libxl__ptr_add(gc, output);
-    return output;
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-out_err:
-    free(output);
-    return NULL;
-}
-
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    assert(bl->ao);
+    bl->diskpath = NULL;
+    bl->openpty.ao = bl->ao;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
+    bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl->ao);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl->ao);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
-        goto out;
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        rc = 0;
+        goto out_ok;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+ out_ok:
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl->ao);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +332,188 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
+
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-        goto out_close;
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl->ao);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f4a2718..7247b57 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -593,8 +593,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2aa32cc..b9de14f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -450,6 +451,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1544,6 +1546,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pP-00046U-43; Wed, 25 Apr 2012 16:12:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pM-000453-2H
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:24 +0000
Received: from [85.158.138.51:65325] by server-1.bemta-3.messagelabs.com id
	5C/36-11491-762289F4; Wed, 25 Apr 2012 16:12:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335370342!23596696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007b6-BY; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003R5-9P;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:39 +0100
Message-ID: <1335369353-13012-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/25] libxl: ao: Convert libxl_run_bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert libxl_run_bootloader to an ao_how-taking function.

It's implemented in terms of libxl__bootloader_run, which can be used
internally.  The resulting code is pretty much a rewrite.

Significant changes include:

- We direct the bootloader's results to a file, not a pipe.  This
  makes it simpler to deal with as we don't have to read it
  concurrently along with everything else.

- We now issue a warning if we find unexpected statements in the
  bootloader results.

- The arrangements for buffering of bootloader input and output
  are completely changed.  Now we have a fixed limit of 64k
  on output, and 4k on input, and discard the oldest data when
  this overflows (which it shouldn't).  There is no timeout
  any more.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes since v6:
 * Use libxl__ev_child_inuse rather than testing pid directly.
 * Fix a code style error.
 * Properly initialise the sub-operations' aos in _init.
 * Bugfixes.
---
 tools/libxl/libxl.c            |    4 +
 tools/libxl/libxl.h            |    3 +-
 tools/libxl/libxl_bootloader.c |  713 +++++++++++++++++++++-------------------
 tools/libxl/libxl_create.c     |    8 +-
 tools/libxl/libxl_internal.h   |   34 ++
 5 files changed, 419 insertions(+), 343 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b6ff270..9238916 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1748,6 +1748,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
      * For other device types assume that the blktap2 process is
      * needed by the soon to be started domain and do nothing.
      */
+    /*
+     * FIXME
+     * This appears to leak the disk in failure paths
+     */
 
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fb90aed..3087146 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -495,7 +495,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx);
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
-                         uint32_t domid);
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how);
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b50944a..bdc4cb4 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <utmp.h>
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
@@ -22,67 +23,80 @@
 
 #include "libxl_internal.h"
 
-#define XENCONSOLED_BUF_SIZE 16
-#define BOOTLOADER_BUF_SIZE 4096
-#define BOOTLOADER_TIMEOUT 1
+#define BOOTLOADER_BUF_OUT 65536
+#define BOOTLOADER_BUF_IN   4096
 
-static char **make_bootloader_args(libxl__gc *gc,
-                                   libxl_domain_build_info *info,
-                                   uint32_t domid,
-                                   const char *fifo, char *disk)
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op);
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status);
+
+/*----- bootloader arguments -----*/
+
+static void bootloader_arg(libxl__bootloader_state *bl, const char *arg)
+{
+    assert(bl->nargs < bl->argsspace);
+    bl->args[bl->nargs++] = arg;
+}
+
+static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl)
 {
-    flexarray_t *args;
-    int nr = 0;
+    const libxl_domain_build_info *info = bl->info;
 
-    args = flexarray_make(1, 1);
-    if (!args)
-        return NULL;
+    bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args);
 
-    flexarray_set(args, nr++, (char *)info->u.pv.bootloader);
+    GCNEW_ARRAY(bl->args, bl->argsspace);
+
+#define ARG(arg) bootloader_arg(bl, (arg))
+
+    ARG(info->u.pv.bootloader);
 
     if (info->u.pv.kernel.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s",
-                                                 info->u.pv.kernel.path));
+        ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path));
     if (info->u.pv.ramdisk.path)
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
+        ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
-        flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
+        ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline));
 
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
-    flexarray_set(args, nr++, "--output-format=simple0");
-    flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
+    ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath));
+    ARG("--output-format=simple0");
+    ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir));
 
     if (info->u.pv.bootloader_args) {
         char **p = info->u.pv.bootloader_args;
         while (*p) {
-            flexarray_set(args, nr++, *p);
+            ARG(*p);
             p++;
         }
     }
 
-    flexarray_set(args, nr++, disk);
+    ARG(bl->diskpath);
 
-    /* Sentinal for execv */
-    flexarray_set(args, nr++, NULL);
+    /* Sentinel for execv */
+    ARG(NULL);
 
-    return (char **) flexarray_contents(args); /* Frees args */
+#undef ARG
 }
 
-static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len)
+/*----- synchronous subroutines -----*/
+
+static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl,
+                                 char *slave_path, size_t slave_path_len)
 {
+    STATE_AO_GC(bl->ao);
     struct termios termattr;
-    int ret;
-
-    ret = openpty(master, slave, NULL, NULL, NULL);
-    if (ret < 0)
-        return -1;
-
-    ret = ttyname_r(*slave, slave_path, slave_path_len);
-    if (ret == -1) {
-        close(*master);
-        close(*slave);
-        *master = *slave = -1;
-        return -1;
+    int r, rc;
+    int slave = libxl__carefd_fd(bl->ptys[1].slave);
+    int master = libxl__carefd_fd(bl->ptys[1].master);
+
+    r = ttyname_r(slave, slave_path, slave_path_len);
+    if (r == -1) {
+        LOGE(ERROR,"ttyname_r failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     /*
@@ -95,310 +109,217 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_
      * semantics on Solaris, so don't try to set any attributes
      * for it.
      */
-#if !defined(__sun__) && !defined(__NetBSD__)
-    tcgetattr(*master, &termattr);
+    tcgetattr(master, &termattr);
     cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-
-    close(*slave);
-    *slave = -1;
-#else
-    tcgetattr(*slave, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*slave, TCSANOW, &termattr);
-#endif
-
-    fcntl(*master, F_SETFL, O_NDELAY);
-    fcntl(*master, F_SETFD, FD_CLOEXEC);
+    tcsetattr(master, TCSANOW, &termattr);
 
     return 0;
+
+ out:
+    return rc;
 }
 
-static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
-{
-    struct termios termattr;
-    pid_t pid = forkpty(master, NULL, NULL, NULL);
-    if (pid == -1)
-        return -1;
-    else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
-        return -1;
-    }
+static const char *bootloader_result_command(libxl__gc *gc, const char *buf,
+                         const char *prefix, size_t prefixlen) {
+    if (strncmp(buf, prefix, prefixlen))
+        return 0;
 
-    /*
-     * On Solaris, the master pty side does not have terminal semantics,
-     * so don't try to set any attributes, as it will fail.
-     */
-#if !defined(__sun__)
-    tcgetattr(*master, &termattr);
-    cfmakeraw(&termattr);
-    tcsetattr(*master, TCSANOW, &termattr);
-#endif
+    const char *rhs = buf + prefixlen;
+    if (!CTYPE(isspace,*rhs))
+        return 0;
 
-    fcntl(*master, F_SETFL, O_NDELAY);
+    while (CTYPE(isspace,*rhs))
+        rhs++;
 
-    return pid;
+    LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs);
+
+    return rhs;
 }
 
-/*
- * filedescriptors:
- *   fifo_fd        - bootstring output from the bootloader
- *   xenconsoled_fd - input/output from/to xenconsole
- *   bootloader_fd  - input/output from/to pty that controls the bootloader
- * The filedescriptors are NDELAY, so it's ok to try to read
- * bigger chunks than may be available, to keep e.g. curses
- * screen redraws in the bootloader efficient. xenconsoled_fd is the side that
- * gets xenconsole input, which will be keystrokes, so a small number
- * is sufficient. bootloader_fd is pygrub output, which will be curses screen
- * updates, so a larger number (1024) is appropriate there.
- *
- * For writeable descriptors, only include them in the set for select
- * if there is actual data to write, otherwise this would loop too fast,
- * eating up CPU time.
- */
-static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd)
+static int parse_bootloader_result(libxl__egc *egc,
+                                   libxl__bootloader_state *bl)
 {
-    int ret;
-
-    size_t nr_out = 0, size_out = 0;
-    char *output = NULL;
-    struct timeval wait;
-
-    /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */
-    int xenconsoled_prod = 0, xenconsoled_cons = 0;
-    char xenconsoled_buf[XENCONSOLED_BUF_SIZE];
-    /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */
-    int bootloader_prod = 0, bootloader_cons = 0;
-    char bootloader_buf[BOOTLOADER_BUF_SIZE];
-
-    while(1) {
-        fd_set wsel, rsel;
-        int nfds;
-
-        /* Set timeout to 1s before starting to discard data */
-        wait.tv_sec = BOOTLOADER_TIMEOUT;
-        wait.tv_usec = 0;
-
-        /* Move buffers around to drop already consumed data */
-        if (xenconsoled_cons > 0) {
-            xenconsoled_prod -= xenconsoled_cons;
-            memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons],
-                    xenconsoled_prod);
-            xenconsoled_cons = 0;
-        }
-        if (bootloader_cons > 0) {
-            bootloader_prod -= bootloader_cons;
-            memmove(bootloader_buf, &bootloader_buf[bootloader_cons],
-                    bootloader_prod);
-            bootloader_cons = 0;
-        }
-
-        FD_ZERO(&rsel);
-        FD_SET(fifo_fd, &rsel);
-        nfds = fifo_fd + 1;
-        if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(xenconsoled_fd, &rsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        } 
-        if (bootloader_prod < BOOTLOADER_BUF_SIZE) {
-            /* The buffer is not full, try to read more data */
-            FD_SET(bootloader_fd, &rsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        FD_ZERO(&wsel);
-        if (bootloader_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(xenconsoled_fd, &wsel);
-            nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds;
-        }
-        if (xenconsoled_prod > 0) {
-            /* The buffer has data to consume */
-            FD_SET(bootloader_fd, &wsel);
-            nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds;
-        }
-
-        if (xenconsoled_prod == XENCONSOLED_BUF_SIZE ||
-            bootloader_prod == BOOTLOADER_BUF_SIZE)
-            ret = select(nfds, &rsel, &wsel, NULL, &wait);
-        else
-            ret = select(nfds, &rsel, &wsel, NULL, NULL);
-        if (ret < 0) {
-            if (errno == EINTR)
-                continue;
-            goto out_err;
-        }
-
-        /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */
-        if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) {
-            /* Drop the buffer */
-            xenconsoled_prod = 0;
-            xenconsoled_cons = 0;
-        } else if (FD_ISSET(xenconsoled_fd, &rsel)) {
-            ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_prod += ret;
-        }
-        if (FD_ISSET(bootloader_fd, &wsel)) {
-            ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                xenconsoled_cons += ret;
-        }
+    STATE_AO_GC(bl->ao);
+    char buf[PATH_MAX*2];
+    FILE *f = 0;
+    int rc = ERROR_FAIL;
+    libxl_domain_build_info *info = bl->info;
+
+    f = fopen(bl->outputpath, "r");
+    if (!f) {
+        LOGE(ERROR,"open bootloader output file %s", bl->outputpath);
+        goto out;
+    }
 
-        /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */
-        if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) {
-            /* Drop the buffer */
-            bootloader_prod = 0;
-            bootloader_cons = 0;
-        } else if (FD_ISSET(bootloader_fd, &rsel)) {
-            ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_prod += ret;
+    for (;;) {
+        /* Read a nul-terminated "line" and put the result in
+         * buf, and its length (not including the nul) in l */
+        int l = 0, c;
+        while ((c = getc(f)) != EOF && c != '\0') {
+            if (l < sizeof(buf)-1)
+                buf[l] = c;
+            l++;
         }
-        if (FD_ISSET(xenconsoled_fd, &wsel)) {
-            ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons);
-            if (ret < 0 && errno != EIO && errno != EAGAIN)
-                goto out_err;
-            if (ret > 0)
-                bootloader_cons += ret;
-        }
-
-        if (FD_ISSET(fifo_fd, &rsel)) {
-            if (size_out - nr_out < 256) {
-                char *temp;
-                size_t new_size = size_out == 0 ? 32 : size_out * 2;
-
-                temp = realloc(output, new_size);
-                if (temp == NULL)
-                    goto out_err;
-                output = temp;
-                memset(output + size_out, 0, new_size - size_out);
-                size_out = new_size;
+        if (c == EOF) {
+            if (ferror(f)) {
+                LOGE(ERROR,"read bootloader output file %s", bl->outputpath);
+                goto out;
             }
-
-            ret = read(fifo_fd, output + nr_out, size_out - nr_out);
-            if (ret > 0)
-                  nr_out += ret;
-            if (ret == 0)
+            if (!l)
                 break;
         }
-    }
+        if (l >= sizeof(buf)) {
+            LOG(WARN,"bootloader output contained"
+                " overly long item `%.150s...'", buf);
+            continue;
+        }
+        buf[l] = 0;
 
-    libxl__ptr_add(gc, output);
-    return output;
+        const char *rhs;
+#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1)))
 
-out_err:
-    free(output);
-    return NULL;
-}
-
-static void parse_bootloader_result(libxl__gc *gc,
-                                    libxl_domain_build_info *info,
-                                    const char *o)
-{
-    while (*o != '\0') {
-        if (strncmp("kernel ", o, strlen("kernel ")) == 0) {
+        if (COMMAND("kernel")) {
             free(info->u.pv.kernel.path);
-            info->u.pv.kernel.path = strdup(o + strlen("kernel "));
+            info->u.pv.kernel.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.kernel);
             unlink(info->u.pv.kernel.path);
-        } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) {
+        } else if (COMMAND("ramdisk")) {
             free(info->u.pv.ramdisk.path);
-            info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk "));
+            info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs);
             libxl__file_reference_map(&info->u.pv.ramdisk);
             unlink(info->u.pv.ramdisk.path);
-        } else if (strncmp("args ", o, strlen("args ")) == 0) {
+        } else if (COMMAND("args")) {
             free(info->u.pv.cmdline);
-            info->u.pv.cmdline = strdup(o + strlen("args "));
+            info->u.pv.cmdline = libxl__strdup(NULL, rhs);
+        } else if (l) {
+            LOG(WARN, "unexpected output from bootloader: `%s'", buf);
         }
-
-        o = o + strlen(o) + 1;
     }
+    rc = 0;
+
+ out:
+    if (f) fclose(f);
+    return rc;
 }
 
-int libxl_run_bootloader(libxl_ctx *ctx,
-                         libxl_domain_build_info *info,
-                         libxl_device_disk *disk,
-                         uint32_t domid)
+
+/*----- init and cleanup -----*/
+
+void libxl__bootloader_init(libxl__bootloader_state *bl)
+{
+    assert(bl->ao);
+    bl->diskpath = NULL;
+    bl->openpty.ao = bl->ao;
+    bl->ptys[0].master = bl->ptys[0].slave = 0;
+    bl->ptys[1].master = bl->ptys[1].slave = 0;
+    libxl__ev_child_init(&bl->child);
+    bl->keystrokes.ao = bl->ao;  libxl__datacopier_init(&bl->keystrokes);
+    bl->display.ao = bl->ao;     libxl__datacopier_init(&bl->display);
+}
+
+static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
 {
-    GC_INIT(ctx);
-    int ret, rc = 0;
-    char *fifo = NULL;
-    char *diskpath = NULL;
-    char **args = NULL;
+    STATE_AO_GC(bl->ao);
+    int i;
 
-    char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
-    char *tempdir;
+    if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
+    if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    char *dom_console_xs_path;
-    char dom_console_slave_tty_path[PATH_MAX];
+    if (bl->diskpath) {
+        libxl_device_disk_local_detach(CTX, bl->disk);
+        free(bl->diskpath);
+        bl->diskpath = 0;
+    }
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    for (i=0; i<2; i++) {
+        libxl__carefd_close(bl->ptys[i].master);
+        libxl__carefd_close(bl->ptys[i].slave);
+    }
+}
+
+static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
+{
+    uint32_t domid = bl->domid;
+    bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid);
+    bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
+}
 
-    int xenconsoled_fd = -1, xenconsoled_slave = -1;
-    int bootloader_fd = -1, fifo_fd = -1;
+static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
+                                int rc)
+{
+    bootloader_cleanup(egc, bl);
+    bl->callback(egc, bl, rc);
+}
 
-    int blrc;
-    pid_t pid;
-    char *blout;
+/*----- main flow of control -----*/
 
-    struct stat st_buf;
+void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
+{
+    STATE_AO_GC(bl->ao);
+    libxl_domain_build_info *info = bl->info;
+    int rc, r;
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    libxl__bootloader_init(bl);
 
-    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
-        goto out;
+    if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) {
+        rc = 0;
+        goto out_ok;
+    }
 
-    rc = libxl__domain_build_info_setdefault(gc, info);
-    if (rc) goto out;
+    bootloader_setpaths(gc, bl);
 
-    rc = ERROR_INVAL;
-    if (!disk)
+    for (;;) {
+        r = mkdir(bl->outputdir, 0600);
+        if (!r) break;
+        if (errno == EINTR) continue;
+        if (errno == EEXIST) break;
+        LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    rc = ERROR_FAIL;
-    ret = mkdir("/var/run/libxl/", S_IRWXU);
-    if (ret < 0 && errno != EEXIST)
+    for (;;) {
+        r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600);
+        if (r>=0) { close(r); break; }
+        if (errno == EINTR) continue;
+        LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath);
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    ret = stat("/var/run/libxl/", &st_buf);
-    if (ret < 0)
+    bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk);
+    if (!bl->diskpath) {
+        rc = ERROR_FAIL;
         goto out;
+    }
 
-    if (!S_ISDIR(st_buf.st_mode))
-        goto out;
+    make_bootloader_args(gc, bl);
 
-    tempdir = mkdtemp(tempdir_template);
-    if (tempdir == NULL)
-        goto out;
+    bl->openpty.ao = ao;
+    bl->openpty.callback = bootloader_gotptys;
+    bl->openpty.count = 2;
+    bl->openpty.results = bl->ptys;
+    rc = libxl__openptys(&bl->openpty, 0,0);
+    if (rc) goto out;
 
-    ret = asprintf(&fifo, "%s/fifo", tempdir);
-    if (ret < 0) {
-        fifo = NULL;
-        goto out_close;
-    }
+    return;
 
-    ret = mkfifo(fifo, 0600);
-    if (ret < 0) {
-        goto out_close;
-    }
+ out:
+    assert(rc);
+ out_ok:
+    bootloader_callback(egc, bl, rc);
+}
 
-    diskpath = libxl_device_disk_local_attach(ctx, disk);
-    if (!diskpath) {
-        goto out_close;
-    }
+static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
+    STATE_AO_GC(bl->ao);
+    int rc, r;
 
-    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
-    if (args == NULL) {
-        rc = ERROR_NOMEM;
-        goto out_close;
+    if (bl->openpty.rc) {
+        rc = bl->openpty.rc;
+        goto out;
     }
 
     /*
@@ -411,76 +332,188 @@ int libxl_run_bootloader(libxl_ctx *ctx,
      * where we copy characters between the two master fds, as well as
      * listening on the bootloader's fifo for the results.
      */
-    ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave,
+
+    char *dom_console_xs_path;
+    char dom_console_slave_tty_path[PATH_MAX];
+    rc = setup_xenconsoled_pty(egc, bl,
                                &dom_console_slave_tty_path[0],
                                sizeof(dom_console_slave_tty_path));
-    if (ret < 0) {
-        goto out_close;
+    if (rc) goto out;
+
+    char *dompath = libxl__xs_get_dompath(gc, bl->domid);
+    if (!dompath) { rc = ERROR_FAIL; goto out; }
+
+    dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath);
+
+    rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s",
+                         dom_console_slave_tty_path);
+    if (rc) {
+        LOGE(ERROR,"xs write console path %s := %s failed",
+             dom_console_xs_path, dom_console_slave_tty_path);
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
-    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    int bootloader_master = libxl__carefd_fd(bl->ptys[0].master);
+    int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master);
+
+    libxl_fd_set_nonblock(CTX, bootloader_master, 1);
+    libxl_fd_set_nonblock(CTX, xenconsole_master, 1);
+
+    bl->keystrokes.writefd   = bl->display.readfd   = bootloader_master;
+    bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty";
+
+    bl->keystrokes.readfd   = bl->display.writefd   = xenconsole_master;
+    bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty";
+
+    bl->keystrokes.ao = ao;
+    bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT;
+    bl->keystrokes.copywhat =
+        GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid);
+    bl->keystrokes.callback = bootloader_keystrokes_copyfail;
+    rc = libxl__datacopier_start(&bl->keystrokes);
+    if (rc) goto out;
+
+    bl->display.ao = ao;
+    bl->display.maxsz = BOOTLOADER_BUF_IN;
+    bl->display.copywhat =
+        GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid);
+    bl->display.callback = bootloader_display_copyfail;
+    rc = libxl__datacopier_start(&bl->display);
+    if (rc) goto out;
+
+    LOG(DEBUG, "executing bootloader: %s", bl->args[0]);
+    for (const char **blarg = bl->args;
+         *blarg;
+         blarg++)
+        LOG(DEBUG, "  bootloader arg: %s", *blarg);
+
+    struct termios termattr;
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
-    if (pid < 0) {
-        goto out_close;
+    pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished);
+    if (pid == -1) {
+        rc = ERROR_FAIL;
+        goto out;
     }
 
-    while (1) {
-        if (waitpid(pid, &blrc, WNOHANG) == pid)
-            goto out_close;
+    if (!pid) {
+        /* child */
+        r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
+        if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
+        setenv("TERM", "vt100", 1);
+        libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args);
+        exit(-1);
+    }
 
-        fifo_fd = open(fifo, O_RDONLY);
-        if (fifo_fd > -1)
-            break;
+    /* parent */
 
-        if (errno == EINTR)
-            continue;
+    /*
+     * On Solaris, the master pty side does not have terminal semantics,
+     * so don't try to set any attributes, as it will fail.
+     */
+#if !defined(__sun__)
+    tcgetattr(bootloader_master, &termattr);
+    cfmakeraw(&termattr);
+    tcsetattr(bootloader_master, TCSANOW, &termattr);
+#endif
+
+    return;
+
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-        goto out_close;
+/* perhaps one of these will be called, but perhaps not */
+static void bootloader_copyfail(libxl__egc *egc, const char *which,
+       libxl__bootloader_state *bl, int onwrite, int errnoval)
+{
+    STATE_AO_GC(bl->ao);
+    int r;
+
+    if (!onwrite && !errnoval)
+        LOG(ERROR, "unexpected eof copying %s", which);
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+    if (libxl__ev_child_inuse(&bl->child)) {
+        r = kill(bl->child.pid, SIGTERM);
+        if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]",
+                    (unsigned long)bl->child.pid);
     }
+    bl->rc = ERROR_FAIL;
+}
+static void bootloader_keystrokes_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+    bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval);
+}
+static void bootloader_display_copyfail(libxl__egc *egc,
+       libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display);
+    bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval);
+}
 
-    fcntl(fifo_fd, F_SETFL, O_NDELAY);
+static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
+                                pid_t pid, int status)
+{
+    libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child);
+    STATE_AO_GC(bl->ao);
+    int rc;
 
-    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
-    if (blout == NULL) {
-        goto out_close;
+    libxl__datacopier_kill(&bl->keystrokes);
+    libxl__datacopier_kill(&bl->display);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
+                                      pid, status);
+        rc = ERROR_FAIL;
+        goto out;
+    } else {
+        LOG(DEBUG, "bootloader completed");
     }
 
-    pid = waitpid(pid, &blrc, 0);
-    if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) {
-        goto out_close;
+    if (bl->rc) {
+        /* datacopier went wrong */
+        rc = bl->rc;
+        goto out;
     }
 
-    parse_bootloader_result(gc, info, blout);
+    rc = parse_bootloader_result(egc, bl);
+    if (rc) goto out;
 
     rc = 0;
-out_close:
-    if (diskpath) {
-        libxl_device_disk_local_detach(ctx, disk);
-        free(diskpath);
-    }
-    if (fifo_fd > -1)
-        close(fifo_fd);
-    if (bootloader_fd > -1)
-        close(bootloader_fd);
-    if (xenconsoled_fd > -1)
-        close(xenconsoled_fd);
-    if (xenconsoled_slave > -1)
-        close(xenconsoled_slave);
-
-    if (fifo) {
-        unlink(fifo);
-        free(fifo);
-    }
+    LOG(DEBUG, "bootloader execution successful");
 
-    rmdir(tempdir);
+ out:
+    bootloader_callback(egc, bl, rc);
+}
 
-    free(args);
+/*----- entrypoint for external callers -----*/
 
-out:
-    GC_FREE;
-    return rc;
+static void run_bootloader_done(libxl__egc *egc,
+                                libxl__bootloader_state *st, int rc)
+{
+    libxl__ao_complete(egc, st->ao, rc);
+}
+
+int libxl_run_bootloader(libxl_ctx *ctx,
+                         libxl_domain_build_info *info,
+                         libxl_device_disk *disk,
+                         uint32_t domid,
+                         libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx,domid,ao_how);
+    libxl__bootloader_state *bl;
+
+    GCNEW(bl);
+    bl->ao = ao;
+    bl->callback = run_bootloader_done;
+    bl->info = info;
+    bl->disk = disk;
+    bl->domid = domid;
+    libxl__bootloader_run(egc, bl);
+    return AO_INPROGRESS;
 }
 
 /*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f4a2718..7247b57 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -593,8 +593,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (ret) goto error_out;
     }
 
-    if ( restore_fd < 0 ) {
-        ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
+    libxl_device_disk *bootdisk =
+        d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
+    if (restore_fd < 0 && bootdisk) {
+        ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid,
+                                   0 /* fixme-ao */);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to run bootloader: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2aa32cc..b9de14f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -42,6 +42,7 @@
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/wait.h>
+#include <sys/socket.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -450,6 +451,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_directory(libxl__gc *gc, const char *path);
 _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path);
 
+
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
@@ -1544,6 +1546,38 @@ int libxl__openptys(libxl__openpty_state *op,
                     const struct winsize *winp);
 
 
+/*----- bootloader -----*/
+
+typedef struct libxl__bootloader_state libxl__bootloader_state;
+typedef void libxl__run_bootloader_callback(libxl__egc*,
+                                libxl__bootloader_state*, int rc);
+
+struct libxl__bootloader_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    libxl__run_bootloader_callback *callback;
+    libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */
+    libxl_device_disk *disk;
+    uint32_t domid;
+    /* private to libxl__run_bootloader */
+    char *outputpath, *outputdir;
+    char *diskpath; /* not from gc, represents actually attached disk */
+    libxl__openpty_state openpty;
+    libxl__openpty_result ptys[2];  /* [0] is for bootloader */
+    libxl__ev_child child;
+    int nargs, argsspace;
+    const char **args;
+    libxl__datacopier_state keystrokes, display;
+    int rc;
+};
+
+_hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
+
+/* Will definitely call st->callback, perhaps reentrantly.
+ * If callback is passed rc==0, will have updated st->info appropriately */
+_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pM-00045S-NJ; Wed, 25 Apr 2012 16:12:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pL-000451-99
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:23 +0000
Received: from [193.109.254.147:18025] by server-11.bemta-14.messagelabs.com
	id D2/B7-05858-662289F4; Wed, 25 Apr 2012 16:12:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16684 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bG-H5; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RD-DO;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:41 +0100
Message-ID: <1335369353-13012-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/25] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 734a5dc..91e34de 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index bdc4cb4..1534bae 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -236,6 +236,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -258,6 +262,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -269,6 +275,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -308,6 +330,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
  out:
     assert(rc);
  out_ok:
+    free(logfile_tmp);
     bootloader_callback(egc, bl, rc);
 }
 
@@ -465,6 +488,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b9de14f..4610f01 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1498,6 +1498,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1560,7 +1561,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pM-00045S-NJ; Wed, 25 Apr 2012 16:12:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN4pL-000451-99
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:23 +0000
Received: from [193.109.254.147:18025] by server-11.bemta-14.messagelabs.com
	id D2/B7-05858-662289F4; Wed, 25 Apr 2012 16:12:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335370340!626465!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16684 invoked from network); 25 Apr 2012 16:12:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 16:12:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12137895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 16:12:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 17:12:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SN4ZR-0007bG-H5; Wed, 25 Apr 2012 15:55:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SN4ZR-0003RD-DO;
	Wed, 25 Apr 2012 16:55:57 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 25 Apr 2012 16:55:41 +0100
Message-ID: <1335369353-13012-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/25] libxl: log bootloader output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding a new log feature to libxl__datacopier, and then
using it.

If the bootloader exits nonzero we print the log filename in a log
message from libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c    |   10 ++++++++++
 tools/libxl/libxl_bootloader.c |   24 ++++++++++++++++++++++++
 tools/libxl/libxl_internal.h   |    3 ++-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 734a5dc..91e34de 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
             libxl__ev_fd_deregister(gc, &dc->toread);
             break;
         }
+        if (dc->log) {
+            int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log);
+            if (wrote != r) {
+                assert(ferror(dc->log));
+                assert(errno);
+                LOGE(ERROR, "error logging %s", dc->copywhat);
+                datacopier_callback(egc, dc, 0, errno);
+                return;
+            }
+        }
         buf->used += r;
         dc->used += r;
         assert(buf->used <= sizeof(buf->buf));
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index bdc4cb4..1534bae 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -236,6 +236,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
         libxl__carefd_close(bl->ptys[i].master);
         libxl__carefd_close(bl->ptys[i].slave);
     }
+    if (bl->display.log) {
+        fclose(bl->display.log);
+        bl->display.log = NULL;
+    }
 }
 
 static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
@@ -258,6 +262,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
     libxl_domain_build_info *info = bl->info;
+    uint32_t domid = bl->domid;
+    char *logfile_tmp = NULL;
     int rc, r;
 
     libxl__bootloader_init(bl);
@@ -269,6 +275,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
     bootloader_setpaths(gc, bl);
 
+    const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid);
+    rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp);
+    if (rc) goto out;
+
+    /* Transfer ownership of log filename to bl and the gc */
+    bl->logfile = logfile_tmp;
+    libxl__ptr_add(gc, logfile_tmp);
+    logfile_tmp = NULL;
+
+    bl->display.log = fopen(bl->logfile, "a");
+    if (!bl->display.log) {
+        LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
     for (;;) {
         r = mkdir(bl->outputdir, 0600);
         if (!r) break;
@@ -308,6 +330,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
  out:
     assert(rc);
  out_ok:
+    free(logfile_tmp);
     bootloader_callback(egc, bl, rc);
 }
 
@@ -465,6 +488,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child,
     libxl__datacopier_kill(&bl->display);
 
     if (status) {
+        LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile);
         libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader",
                                       pid, status);
         rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b9de14f..4610f01 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1498,6 +1498,7 @@ struct libxl__datacopier_state {
     int readfd, writefd;
     ssize_t maxsz;
     const char *copywhat, *readwhat, *writewhat; /* for error msgs */
+    FILE *log; /* gets a copy of everything */
     libxl__datacopier_callback *callback;
     /* remaining fields are private to datacopier */
     libxl__ev_fd toread, towrite;
@@ -1560,7 +1561,7 @@ struct libxl__bootloader_state {
     libxl_device_disk *disk;
     uint32_t domid;
     /* private to libxl__run_bootloader */
-    char *outputpath, *outputdir;
+    char *outputpath, *outputdir, *logfile;
     char *diskpath; /* not from gc, represents actually attached disk */
     libxl__openpty_state openpty;
     libxl__openpty_result ptys[2];  /* [0] is for bootloader */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:13:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:13:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pv-0004JD-Q6; Wed, 25 Apr 2012 16:12:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SN4pu-0004Ho-7k
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:58 +0000
Received: from [85.158.138.51:10853] by server-10.bemta-3.messagelabs.com id
	44/71-29478-782289F4; Wed, 25 Apr 2012 16:12:55 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335370373!23764503!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17239 invoked from network); 25 Apr 2012 16:12:54 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 16:12:54 -0000
Received: from mail76-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 16:12:48 +0000
Received: from mail76-va3 (localhost [127.0.0.1])	by mail76-va3-R.bigfish.com
	(Postfix) with ESMTP id 6DD04360523;
	Wed, 25 Apr 2012 16:12:48 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail76-va3 (localhost.localdomain [127.0.0.1]) by mail76-va3
	(MessageSwitch) id 1335370356933414_7041;
	Wed, 25 Apr 2012 16:12:36 +0000 (UTC)
Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.241])	by
	mail76-va3.bigfish.com (Postfix) with ESMTP id CF4802000B0;
	Wed, 25 Apr 2012 16:12:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 16:12:34 +0000
X-WSS-ID: 0M31MCW-01-GYW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B6F610280A7;	Wed, 25 Apr 2012 11:12:31 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 11:13:07 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:12:30 -0500
Message-ID: <4F982098.8070003@amd.com>
Date: Wed, 25 Apr 2012 11:04:40 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Dan Magenheimer <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
	<a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
	<4F98399D0200007800080055@nat28.tlf.novell.com>
	<96c5a3ba-72c2-45c4-8860-08b59157ad40@default>
In-Reply-To: <96c5a3ba-72c2-45c4-8860-08b59157ad40@default>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, keir@xen.org,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/2012 11:05 AM, Dan Magenheimer wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Subject: RE: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>
>>>>> On 25.04.12 at 17:01, Dan Magenheimer<dan.magenheimer@oracle.com>  wrote:
>>>>   From: Jan Beulich [mailto:JBeulich@suse.com]
>>>> Sent: Wednesday, April 25, 2012 3:27 AM
>>>> To: Boris Ostrovsky; Dan Magenheimer
>>>> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org
>>>> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
>>> supported by hardware
>>>>>>> On 20.04.12 at 04:21, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>>>> # HG changeset patch
>>>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>>> # Date 1334875170 14400
>>>>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>>>>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>>>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>>>>
>>>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>>>>
>>>>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>>> Acked-by: Wei Huang<wei.huang2@amd.com>
>>>>> Tested-by: Wei Huang<wei.huang2@amd.com>
>>>> So what's the status of the discussion around this patch? Were
>>>> your concerns all addressed, Dan? Is there any re-submisson
>>>> necessary/planned?
>>> My concerns will be addressed when there is a fully-functional
>>> adequately-tested full-stack implementation, rather than "we
>>> have a new instruction that should solve (part of) this problem,
>>> let's turn it on by default."
>>>
>>> While I wish I could invest the time required to do (or
>>> participate in) the testing, sadly I can't, so I understand
>>> if my opinion is discarded.
>> As Keir had asked to get an ACK/NAK from you - is this then a NAK
>> or a "don't care" or yet something else (it doesn't read anywhere
>> close to an ACK in any case).
> Something else ;-)
>
> I certainly don't feel comfortable ACKing it.  I'd like
> to see some testing that demonstrates the patch either improves
> functionality or performance without breaking other things.
> But if nobody else shares my concern, I don't feel that
> I have the right to block it either.

We can provide some rdtsc performance numbers. Regarding functionality, 
it is relatively hard to prove unless Dan has some more specific ideas 
of testing it. I think the hardware rdtsc scaling is inline with 
software-based emulated approach.

-Wei
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 16:13:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 16:13:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN4pv-0004JD-Q6; Wed, 25 Apr 2012 16:12:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1SN4pu-0004Ho-7k
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 16:12:58 +0000
Received: from [85.158.138.51:10853] by server-10.bemta-3.messagelabs.com id
	44/71-29478-782289F4; Wed, 25 Apr 2012 16:12:55 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335370373!23764503!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17239 invoked from network); 25 Apr 2012 16:12:54 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 16:12:54 -0000
Received: from mail76-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 16:12:48 +0000
Received: from mail76-va3 (localhost [127.0.0.1])	by mail76-va3-R.bigfish.com
	(Postfix) with ESMTP id 6DD04360523;
	Wed, 25 Apr 2012 16:12:48 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail76-va3 (localhost.localdomain [127.0.0.1]) by mail76-va3
	(MessageSwitch) id 1335370356933414_7041;
	Wed, 25 Apr 2012 16:12:36 +0000 (UTC)
Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.241])	by
	mail76-va3.bigfish.com (Postfix) with ESMTP id CF4802000B0;
	Wed, 25 Apr 2012 16:12:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 16:12:34 +0000
X-WSS-ID: 0M31MCW-01-GYW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B6F610280A7;	Wed, 25 Apr 2012 11:12:31 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 11:13:07 -0500
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 11:12:30 -0500
Message-ID: <4F982098.8070003@amd.com>
Date: Wed, 25 Apr 2012 11:04:40 -0500
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Dan Magenheimer <dan.magenheimer@oracle.com>
References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com>
	<4F97DF91020000780007FE82@nat28.tlf.novell.com>
	<a20feeca-9cdd-4c71-a705-d7d77b791a35@default>
	<4F98399D0200007800080055@nat28.tlf.novell.com>
	<96c5a3ba-72c2-45c4-8860-08b59157ad40@default>
In-Reply-To: <96c5a3ba-72c2-45c4-8860-08b59157ad40@default>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, keir@xen.org,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/2012 11:05 AM, Dan Magenheimer wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Subject: RE: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>
>>>>> On 25.04.12 at 17:01, Dan Magenheimer<dan.magenheimer@oracle.com>  wrote:
>>>>   From: Jan Beulich [mailto:JBeulich@suse.com]
>>>> Sent: Wednesday, April 25, 2012 3:27 AM
>>>> To: Boris Ostrovsky; Dan Magenheimer
>>>> Cc: wei.huang2@amd.com; xen-devel; keir@xen.org
>>>> Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
>>> supported by hardware
>>>>>>> On 20.04.12 at 04:21, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>>>> # HG changeset patch
>>>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>>> # Date 1334875170 14400
>>>>> # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18
>>>>> # Parent  7c777cb8f705411b77c551f34ba88bdc09e38ab8
>>>>> svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
>>>>>
>>>>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
>>>>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
>>>>>
>>>>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>>> Acked-by: Wei Huang<wei.huang2@amd.com>
>>>>> Tested-by: Wei Huang<wei.huang2@amd.com>
>>>> So what's the status of the discussion around this patch? Were
>>>> your concerns all addressed, Dan? Is there any re-submisson
>>>> necessary/planned?
>>> My concerns will be addressed when there is a fully-functional
>>> adequately-tested full-stack implementation, rather than "we
>>> have a new instruction that should solve (part of) this problem,
>>> let's turn it on by default."
>>>
>>> While I wish I could invest the time required to do (or
>>> participate in) the testing, sadly I can't, so I understand
>>> if my opinion is discarded.
>> As Keir had asked to get an ACK/NAK from you - is this then a NAK
>> or a "don't care" or yet something else (it doesn't read anywhere
>> close to an ACK in any case).
> Something else ;-)
>
> I certainly don't feel comfortable ACKing it.  I'd like
> to see some testing that demonstrates the patch either improves
> functionality or performance without breaking other things.
> But if nobody else shares my concern, I don't feel that
> I have the right to block it either.

We can provide some rdtsc performance numbers. Regarding functionality, 
it is relatively hard to prove unless Dan has some more specific ideas 
of testing it. I think the hardware rdtsc scaling is inline with 
software-based emulated approach.

-Wei
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 17:15:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 17:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN5nw-0005aN-BF; Wed, 25 Apr 2012 17:15:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SN5nv-0005aI-NJ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 17:14:59 +0000
Received: from [85.158.139.83:23008] by server-12.bemta-5.messagelabs.com id
	A3/08-05587-211389F4; Wed, 25 Apr 2012 17:14:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335374098!14224432!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21158 invoked from network); 25 Apr 2012 17:14:58 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 17:14:58 -0000
Received: by wibhn6 with SMTP id hn6so334522wib.14
	for <xen-devel@lists.xen.org>; Wed, 25 Apr 2012 10:14:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=odt3ehmoA1X3ElysXwE0PxCREIvR0wMCaelUeoMOk4k=;
	b=s/G3fcwhzPfrCqRQxCcMqvdvhgATgCXAcVl2lIkoukkWxyYgpaoO40ziKL6htNMCwx
	fwS67X9FX2CCGaH5gQR18cnFhz/IHlBtqIjZ6QCM+b/KMlwAn0rBhcT4xZ3TLQwr5X8H
	gxgAshfX1lTSsoN8KJHz074SMqRubeJoze9a1nSy05iVDWShH6EkGVEoPrejbUtxyvut
	IDhinP6NnopxxP6r/tioQXUF2yZGurXOirMnoZCHtLSO1OtMBtFgo+jHh/NBe0GCZVAX
	FTQ1iQzVdctnOLwYZx4FddYXX0EsmJDgFSUiLnLFZllP/Ebhl0Vei5YrMrcBeLfzeuJc
	/0qA==
Received: by 10.180.80.70 with SMTP id p6mr2200832wix.21.1335374097803;
	Wed, 25 Apr 2012 10:14:57 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id ff9sm38493411wib.2.2012.04.25.10.14.55
	(version=SSLv3 cipher=OTHER); Wed, 25 Apr 2012 10:14:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Apr 2012 18:14:49 +0100
From: Keir Fraser <keir@xen.org>
To: <wei.huang2@amd.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBBDEF99.3EECC%keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0jButqym1gqmiRcE6h6hgraF5+ww==
In-Reply-To: <4F982098.8070003@amd.com>
Mime-version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/04/2012 17:04, "Wei Huang" <wei.huang2@amd.com> wrote:

>> I certainly don't feel comfortable ACKing it.  I'd like
>> to see some testing that demonstrates the patch either improves
>> functionality or performance without breaking other things.
>> But if nobody else shares my concern, I don't feel that
>> I have the right to block it either.
> 
> We can provide some rdtsc performance numbers. Regarding functionality,
> it is relatively hard to prove unless Dan has some more specific ideas
> of testing it. I think the hardware rdtsc scaling is inline with
> software-based emulated approach.

I've put it in to xen-unstable. I'm not sure about putting into 4.1 for the
forthcoming release from that branch.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 17:15:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 17:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN5nw-0005aN-BF; Wed, 25 Apr 2012 17:15:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SN5nv-0005aI-NJ
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 17:14:59 +0000
Received: from [85.158.139.83:23008] by server-12.bemta-5.messagelabs.com id
	A3/08-05587-211389F4; Wed, 25 Apr 2012 17:14:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335374098!14224432!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21158 invoked from network); 25 Apr 2012 17:14:58 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 17:14:58 -0000
Received: by wibhn6 with SMTP id hn6so334522wib.14
	for <xen-devel@lists.xen.org>; Wed, 25 Apr 2012 10:14:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=odt3ehmoA1X3ElysXwE0PxCREIvR0wMCaelUeoMOk4k=;
	b=s/G3fcwhzPfrCqRQxCcMqvdvhgATgCXAcVl2lIkoukkWxyYgpaoO40ziKL6htNMCwx
	fwS67X9FX2CCGaH5gQR18cnFhz/IHlBtqIjZ6QCM+b/KMlwAn0rBhcT4xZ3TLQwr5X8H
	gxgAshfX1lTSsoN8KJHz074SMqRubeJoze9a1nSy05iVDWShH6EkGVEoPrejbUtxyvut
	IDhinP6NnopxxP6r/tioQXUF2yZGurXOirMnoZCHtLSO1OtMBtFgo+jHh/NBe0GCZVAX
	FTQ1iQzVdctnOLwYZx4FddYXX0EsmJDgFSUiLnLFZllP/Ebhl0Vei5YrMrcBeLfzeuJc
	/0qA==
Received: by 10.180.80.70 with SMTP id p6mr2200832wix.21.1335374097803;
	Wed, 25 Apr 2012 10:14:57 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id ff9sm38493411wib.2.2012.04.25.10.14.55
	(version=SSLv3 cipher=OTHER); Wed, 25 Apr 2012 10:14:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Apr 2012 18:14:49 +0100
From: Keir Fraser <keir@xen.org>
To: <wei.huang2@amd.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <CBBDEF99.3EECC%keir@xen.org>
Thread-Topic: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is
	supported by hardware
Thread-Index: Ac0jButqym1gqmiRcE6h6hgraF5+ww==
In-Reply-To: <4F982098.8070003@amd.com>
Mime-version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/04/2012 17:04, "Wei Huang" <wei.huang2@amd.com> wrote:

>> I certainly don't feel comfortable ACKing it.  I'd like
>> to see some testing that demonstrates the patch either improves
>> functionality or performance without breaking other things.
>> But if nobody else shares my concern, I don't feel that
>> I have the right to block it either.
> 
> We can provide some rdtsc performance numbers. Regarding functionality,
> it is relatively hard to prove unless Dan has some more specific ideas
> of testing it. I think the hardware rdtsc scaling is inline with
> software-based emulated approach.

I've put it in to xen-unstable. I'm not sure about putting into 4.1 for the
forthcoming release from that branch.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 17:18:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 17:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN5qQ-0005f9-TG; Wed, 25 Apr 2012 17:17:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN5qP-0005f2-MT
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 17:17:34 +0000
Received: from [85.158.138.51:23057] by server-3.bemta-3.messagelabs.com id
	13/0D-04048-CA1389F4; Wed, 25 Apr 2012 17:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335374252!23694989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 25 Apr 2012 17:17:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 17:17:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12139747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 17:17:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 18:17:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SN5qN-00086w-IO;
	Wed, 25 Apr 2012 17:17:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SN5qN-0001YB-7J;
	Wed, 25 Apr 2012 18:17:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12752-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 18:17:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12752: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12752 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12752/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12742
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12742 pass in 12752
 test-i386-i386-pair   4 host-install/dst_host(4) broken in 12742 pass in 12752

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12742 never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 17:18:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 17:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN5qQ-0005f9-TG; Wed, 25 Apr 2012 17:17:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN5qP-0005f2-MT
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 17:17:34 +0000
Received: from [85.158.138.51:23057] by server-3.bemta-3.messagelabs.com id
	13/0D-04048-CA1389F4; Wed, 25 Apr 2012 17:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335374252!23694989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 25 Apr 2012 17:17:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 17:17:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="12139747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 17:17:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 18:17:31 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SN5qN-00086w-IO;
	Wed, 25 Apr 2012 17:17:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SN5qN-0001YB-7J;
	Wed, 25 Apr 2012 18:17:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12752-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 18:17:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12752: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12752 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12752/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12742
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12742 pass in 12752
 test-i386-i386-pair   4 host-install/dst_host(4) broken in 12742 pass in 12752

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12742 never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 18:39:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 18:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN77Z-0006Vt-4A; Wed, 25 Apr 2012 18:39:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SN77Y-0006Vo-Fo
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 18:39:20 +0000
Received: from [85.158.139.83:10696] by server-4.bemta-5.messagelabs.com id
	F3/65-10788-7D4489F4; Wed, 25 Apr 2012 18:39:19 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335379157!25488060!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30431 invoked from network); 25 Apr 2012 18:39:18 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 18:39:18 -0000
Received: by ghbz17 with SMTP id z17so481960ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 11:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=aSrIVTiJqIelYjYNRU4iHrKGkYBWjP5Ft7EVsmSEooo=;
	b=k/WvPmr5WXVbvDYW5wBAiQ09VDyZGuy5n5zNZ2/fHY2H6EsAR+gu/cp0AzM1nqNo/T
	VQMBusuDx25Mkr7l446NONGoMmpRhbHFfW4jwcwNkabWS9CkTIBHaNvupmGZTzG42KvL
	AO7J/dPpsQtmOptZ2F63arM1IMD5dx0DJkKXk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=aSrIVTiJqIelYjYNRU4iHrKGkYBWjP5Ft7EVsmSEooo=;
	b=FhRRkorHX2pzX14liadxbTi7XWyRCmCE+GQBVv/pdkWDozXLjE3rRpozpTIc4ul7GN
	aKKhMr2LLOZpiPCPSXCrna7WeuxCVErRlY6cwgRI/ehYwpbLwaSM63rV4hOANWtwaD0d
	eEc4JloQyDIN7ojjyYTz9LBe50H/pp7DOLqJx2Y/3FjwAheqDONd9qJZoOKeJmYgOwTV
	FduSggBjaufSaHHl6+tax+bVRGFisgKzPyyBE8jc1hmqdwABZn7LZjcLBT9cJdqLsFoM
	edF9fJTSEMDTjIdiAOC2kA3eoLTaw/K1dT00H3xbzmhisc5IqEzm7O4JfbD83ja4XcWP
	KrPw==
Received: by 10.182.222.2 with SMTP id qi2mr5264845obc.27.1335379157309;
	Wed, 25 Apr 2012 11:39:17 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id a8sm523577oea.8.2012.04.25.11.39.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Apr 2012 11:39:15 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: be41f3b599d9bba572814368b80fa7eae5423dcb
Message-Id: <be41f3b599d9bba57281.1335379132@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Wed, 25 Apr 2012 11:38:52 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQmpKW/k7RQufVLyYALN+1IqCOnqCI/vLiI1zijC4QBfx/AUc3244T0/LkEyjgKsQf5pMek8
Cc: keir@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1 of 2] xen/hvm: Add get_shadow_gs_base()
	wrapper function
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a wrapper function to the HVM function table that returns the shadow GS base.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 6ef297a3761f -r be41f3b599d9 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/arch/x86/hvm/svm/svm.c	Wed Apr 25 11:35:29 2012 -0700
@@ -645,6 +645,13 @@ static void svm_set_segment_register(str
         svm_vmload(vmcb);
 }
 
+static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+
+    return vmcb->kerngsbase;
+}
+
 static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -1983,6 +1990,7 @@ static struct hvm_function_table __read_
     .guest_x86_mode       = svm_guest_x86_mode,
     .get_segment_register = svm_get_segment_register,
     .set_segment_register = svm_set_segment_register,
+    .get_shadow_gs_base   = svm_get_shadow_gs_base,
     .update_host_cr3      = svm_update_host_cr3,
     .update_guest_cr      = svm_update_guest_cr,
     .update_guest_efer    = svm_update_guest_efer,
diff -r 6ef297a3761f -r be41f3b599d9 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Wed Apr 25 11:35:29 2012 -0700
@@ -942,6 +942,15 @@ static void vmx_set_segment_register(str
     vmx_vmcs_exit(v);
 }
 
+static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
+{
+#ifdef __x86_64__
+    return v->arch.hvm_vmx.shadow_gs;
+#else
+    return 0;
+#endif
+}
+
 static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
@@ -1522,6 +1531,7 @@ static struct hvm_function_table __read_
     .guest_x86_mode       = vmx_guest_x86_mode,
     .get_segment_register = vmx_get_segment_register,
     .set_segment_register = vmx_set_segment_register,
+    .get_shadow_gs_base   = vmx_get_shadow_gs_base,
     .update_host_cr3      = vmx_update_host_cr3,
     .update_guest_cr      = vmx_update_guest_cr,
     .update_guest_efer    = vmx_update_guest_efer,
diff -r 6ef297a3761f -r be41f3b599d9 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/include/asm-x86/hvm/hvm.h	Wed Apr 25 11:35:29 2012 -0700
@@ -106,6 +106,7 @@ struct hvm_function_table {
                                  struct segment_register *reg);
     void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
+    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
 
     /* 
      * Re-set the value of CR3 that Xen runs on when handling VM exits.
@@ -305,6 +306,11 @@ hvm_set_segment_register(struct vcpu *v,
     hvm_funcs.set_segment_register(v, seg, reg);
 }
 
+static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
+{
+    return hvm_funcs.get_shadow_gs_base(v);
+}
+
 #define is_viridian_domain(_d)                                             \
  (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 18:39:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 18:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN77Z-0006Vt-4A; Wed, 25 Apr 2012 18:39:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SN77Y-0006Vo-Fo
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 18:39:20 +0000
Received: from [85.158.139.83:10696] by server-4.bemta-5.messagelabs.com id
	F3/65-10788-7D4489F4; Wed, 25 Apr 2012 18:39:19 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335379157!25488060!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30431 invoked from network); 25 Apr 2012 18:39:18 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 18:39:18 -0000
Received: by ghbz17 with SMTP id z17so481960ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 11:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=aSrIVTiJqIelYjYNRU4iHrKGkYBWjP5Ft7EVsmSEooo=;
	b=k/WvPmr5WXVbvDYW5wBAiQ09VDyZGuy5n5zNZ2/fHY2H6EsAR+gu/cp0AzM1nqNo/T
	VQMBusuDx25Mkr7l446NONGoMmpRhbHFfW4jwcwNkabWS9CkTIBHaNvupmGZTzG42KvL
	AO7J/dPpsQtmOptZ2F63arM1IMD5dx0DJkKXk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=aSrIVTiJqIelYjYNRU4iHrKGkYBWjP5Ft7EVsmSEooo=;
	b=FhRRkorHX2pzX14liadxbTi7XWyRCmCE+GQBVv/pdkWDozXLjE3rRpozpTIc4ul7GN
	aKKhMr2LLOZpiPCPSXCrna7WeuxCVErRlY6cwgRI/ehYwpbLwaSM63rV4hOANWtwaD0d
	eEc4JloQyDIN7ojjyYTz9LBe50H/pp7DOLqJx2Y/3FjwAheqDONd9qJZoOKeJmYgOwTV
	FduSggBjaufSaHHl6+tax+bVRGFisgKzPyyBE8jc1hmqdwABZn7LZjcLBT9cJdqLsFoM
	edF9fJTSEMDTjIdiAOC2kA3eoLTaw/K1dT00H3xbzmhisc5IqEzm7O4JfbD83ja4XcWP
	KrPw==
Received: by 10.182.222.2 with SMTP id qi2mr5264845obc.27.1335379157309;
	Wed, 25 Apr 2012 11:39:17 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id a8sm523577oea.8.2012.04.25.11.39.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Apr 2012 11:39:15 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: be41f3b599d9bba572814368b80fa7eae5423dcb
Message-Id: <be41f3b599d9bba57281.1335379132@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Wed, 25 Apr 2012 11:38:52 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQmpKW/k7RQufVLyYALN+1IqCOnqCI/vLiI1zijC4QBfx/AUc3244T0/LkEyjgKsQf5pMek8
Cc: keir@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1 of 2] xen/hvm: Add get_shadow_gs_base()
	wrapper function
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a wrapper function to the HVM function table that returns the shadow GS base.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 6ef297a3761f -r be41f3b599d9 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/arch/x86/hvm/svm/svm.c	Wed Apr 25 11:35:29 2012 -0700
@@ -645,6 +645,13 @@ static void svm_set_segment_register(str
         svm_vmload(vmcb);
 }
 
+static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+
+    return vmcb->kerngsbase;
+}
+
 static int svm_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -1983,6 +1990,7 @@ static struct hvm_function_table __read_
     .guest_x86_mode       = svm_guest_x86_mode,
     .get_segment_register = svm_get_segment_register,
     .set_segment_register = svm_set_segment_register,
+    .get_shadow_gs_base   = svm_get_shadow_gs_base,
     .update_host_cr3      = svm_update_host_cr3,
     .update_guest_cr      = svm_update_guest_cr,
     .update_guest_efer    = svm_update_guest_efer,
diff -r 6ef297a3761f -r be41f3b599d9 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Wed Apr 25 11:35:29 2012 -0700
@@ -942,6 +942,15 @@ static void vmx_set_segment_register(str
     vmx_vmcs_exit(v);
 }
 
+static unsigned long vmx_get_shadow_gs_base(struct vcpu *v)
+{
+#ifdef __x86_64__
+    return v->arch.hvm_vmx.shadow_gs;
+#else
+    return 0;
+#endif
+}
+
 static int vmx_set_guest_pat(struct vcpu *v, u64 gpat)
 {
     if ( !cpu_has_vmx_pat || !paging_mode_hap(v->domain) )
@@ -1522,6 +1531,7 @@ static struct hvm_function_table __read_
     .guest_x86_mode       = vmx_guest_x86_mode,
     .get_segment_register = vmx_get_segment_register,
     .set_segment_register = vmx_set_segment_register,
+    .get_shadow_gs_base   = vmx_get_shadow_gs_base,
     .update_host_cr3      = vmx_update_host_cr3,
     .update_guest_cr      = vmx_update_guest_cr,
     .update_guest_efer    = vmx_update_guest_efer,
diff -r 6ef297a3761f -r be41f3b599d9 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Mon Apr 23 15:16:34 2012 -0700
+++ b/xen/include/asm-x86/hvm/hvm.h	Wed Apr 25 11:35:29 2012 -0700
@@ -106,6 +106,7 @@ struct hvm_function_table {
                                  struct segment_register *reg);
     void (*set_segment_register)(struct vcpu *v, enum x86_segment seg,
                                  struct segment_register *reg);
+    unsigned long (*get_shadow_gs_base)(struct vcpu *v);
 
     /* 
      * Re-set the value of CR3 that Xen runs on when handling VM exits.
@@ -305,6 +306,11 @@ hvm_set_segment_register(struct vcpu *v,
     hvm_funcs.set_segment_register(v, seg, reg);
 }
 
+static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
+{
+    return hvm_funcs.get_shadow_gs_base(v);
+}
+
 #define is_viridian_domain(_d)                                             \
  (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 18:39:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 18:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN77b-0006WD-HR; Wed, 25 Apr 2012 18:39:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SN77a-0006W1-BC
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 18:39:22 +0000
Received: from [85.158.138.51:11963] by server-7.bemta-3.messagelabs.com id
	BF/44-03078-9D4489F4; Wed, 25 Apr 2012 18:39:21 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335379159!23759425!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1492 invoked from network); 25 Apr 2012 18:39:20 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 18:39:20 -0000
Received: by yenl11 with SMTP id l11so473980yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 11:39:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=luyh3oFM4a+at1P2iy4RPlexwKmdt6oSUdbIzy9T4wo=;
	b=OLgYqr1DZ3bg1Z45JcYUFwXPboSihgQ2x9QmTbHib1JOZ+21EZIevffIMyofseoFdK
	UqnuK9cFFpGqXloM369+r5l0zsA/B+WpPqQYCr+GwccEjDbCtzzfHGla0vAsdqDrWkeg
	u7EaPdZ41kaOjQe2o/2k70MOf/ST7PcSgfcUA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc:x-gm-message-state;
	bh=luyh3oFM4a+at1P2iy4RPlexwKmdt6oSUdbIzy9T4wo=;
	b=DBakzkAH8PL5n/N9j1tmt85c7EDOy1gRU8u4ofnoYmnUoRPwEnt8HeILYDrb2KlkDf
	C62bdrVci/6BHX48BDTELq0nfmHpRcA0asQWHBK7hDpAKGjTabHhqqD7cq5+XjxQ7hY2
	3fIUkYiyQMeG7iksLJQ6kj6z3/a9l7OhWGgcmPDj4m63xkrBjcbmO2YgUsyao6376MT7
	V4eKEbKkEpI5o84OTWuUcPlqw89NUf7s3HSoOwrKogQjgkg2XGZ0kTm/IR69Grghgyfj
	asLApgHgfu7OmtXZ1EKHSD5d0/dTDSlVZzF+n+xA98tUIeWJ/am4mqXvMFNpuj9nB8Kx
	MGPQ==
Received: by 10.60.20.38 with SMTP id k6mr5092956oee.26.1335379159174;
	Wed, 25 Apr 2012 11:39:19 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id a8sm523577oea.8.2012.04.25.11.39.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Apr 2012 11:39:18 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1f39b9fe704f40f394e015683ab472d572f059dc
Message-Id: <1f39b9fe704f40f394e0.1335379133@vollum>
In-Reply-To: <be41f3b599d9bba57281.1335379132@vollum>
References: <be41f3b599d9bba57281.1335379132@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Wed, 25 Apr 2012 11:38:53 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQmpioO1qBTHAfg8Ow44lIfD/st+y9RXMplzzjvqYoj6Ig/0LEnVfvfhnuy2sKbVO5tvefUP
Cc: keir@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to HVM
	VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Apr 25 11:35:29 2012 -0700
+++ b/xen/arch/x86/domctl.c	Wed Apr 25 11:35:43 2012 -0700
@@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
         c.nat->user_regs.es = sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs = sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base = sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs = sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+        {
+            c.nat->gs_base_kernel = sreg.base;
+            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
+        }
+        else
+        {
+            c.nat->gs_base_user = sreg.base;
+            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
+        }
+#endif
     }
     else
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 18:39:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 18:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN77b-0006WD-HR; Wed, 25 Apr 2012 18:39:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SN77a-0006W1-BC
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 18:39:22 +0000
Received: from [85.158.138.51:11963] by server-7.bemta-3.messagelabs.com id
	BF/44-03078-9D4489F4; Wed, 25 Apr 2012 18:39:21 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335379159!23759425!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1492 invoked from network); 25 Apr 2012 18:39:20 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 18:39:20 -0000
Received: by yenl11 with SMTP id l11so473980yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 11:39:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=luyh3oFM4a+at1P2iy4RPlexwKmdt6oSUdbIzy9T4wo=;
	b=OLgYqr1DZ3bg1Z45JcYUFwXPboSihgQ2x9QmTbHib1JOZ+21EZIevffIMyofseoFdK
	UqnuK9cFFpGqXloM369+r5l0zsA/B+WpPqQYCr+GwccEjDbCtzzfHGla0vAsdqDrWkeg
	u7EaPdZ41kaOjQe2o/2k70MOf/ST7PcSgfcUA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc:x-gm-message-state;
	bh=luyh3oFM4a+at1P2iy4RPlexwKmdt6oSUdbIzy9T4wo=;
	b=DBakzkAH8PL5n/N9j1tmt85c7EDOy1gRU8u4ofnoYmnUoRPwEnt8HeILYDrb2KlkDf
	C62bdrVci/6BHX48BDTELq0nfmHpRcA0asQWHBK7hDpAKGjTabHhqqD7cq5+XjxQ7hY2
	3fIUkYiyQMeG7iksLJQ6kj6z3/a9l7OhWGgcmPDj4m63xkrBjcbmO2YgUsyao6376MT7
	V4eKEbKkEpI5o84OTWuUcPlqw89NUf7s3HSoOwrKogQjgkg2XGZ0kTm/IR69Grghgyfj
	asLApgHgfu7OmtXZ1EKHSD5d0/dTDSlVZzF+n+xA98tUIeWJ/am4mqXvMFNpuj9nB8Kx
	MGPQ==
Received: by 10.60.20.38 with SMTP id k6mr5092956oee.26.1335379159174;
	Wed, 25 Apr 2012 11:39:19 -0700 (PDT)
Received: from [127.0.1.1] (108-237-46-57.lightspeed.sntcca.sbcglobal.net.
	[108.237.46.57])
	by mx.google.com with ESMTPS id a8sm523577oea.8.2012.04.25.11.39.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Apr 2012 11:39:18 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1f39b9fe704f40f394e015683ab472d572f059dc
Message-Id: <1f39b9fe704f40f394e0.1335379133@vollum>
In-Reply-To: <be41f3b599d9bba57281.1335379132@vollum>
References: <be41f3b599d9bba57281.1335379132@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Wed, 25 Apr 2012 11:38:53 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQmpioO1qBTHAfg8Ow44lIfD/st+y9RXMplzzjvqYoj6Ig/0LEnVfvfhnuy2sKbVO5tvefUP
Cc: keir@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to HVM
	VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Apr 25 11:35:29 2012 -0700
+++ b/xen/arch/x86/domctl.c	Wed Apr 25 11:35:43 2012 -0700
@@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
         c.nat->user_regs.es = sreg.sel;
         hvm_get_segment_register(v, x86_seg_fs, &sreg);
         c.nat->user_regs.fs = sreg.sel;
+#ifdef __x86_64__
+        c.nat->fs_base = sreg.base;
+#endif
         hvm_get_segment_register(v, x86_seg_gs, &sreg);
         c.nat->user_regs.gs = sreg.sel;
+#ifdef __x86_64__
+        if ( ring_0(&c.nat->user_regs) )
+        {
+            c.nat->gs_base_kernel = sreg.base;
+            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
+        }
+        else
+        {
+            c.nat->gs_base_user = sreg.base;
+            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
+        }
+#endif
     }
     else
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 18:47:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 18:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN7FC-0006sC-GR; Wed, 25 Apr 2012 18:47:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SN7FA-0006s7-Lf
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 18:47:12 +0000
Received: from [85.158.138.51:53908] by server-9.bemta-3.messagelabs.com id
	68/BD-26691-FA6489F4; Wed, 25 Apr 2012 18:47:11 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335379629!14848315!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21390 invoked from network); 25 Apr 2012 18:47:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 18:47:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="24544619"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 14:47:09 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 25 Apr 2012
	14:47:09 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 25 Apr 2012 14:47:06 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0ZWR9ARh6Q+IeQTf6lbeolog3qzQJuTy6Q
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334309880.14560.14.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >
> > Yea so the entire SMBIOS table begins with the "struct
> > smbios_entry_point" which is not present in what I pass in. I have N
> > structs (possibly some of the same type) that start with a "struct
> > smbios_structure_header". The gotcha is that the "length" field only
> > defines the fixed portion of each of the SMBIOS structs. There can be
> > any number of strings following that struct of varying length.
> 
> Ah, that's the bit I had forgotten...
> 
> >  Then entire structure is doubly terminated with "\0\0". What I wanted
> > to avoid is having to put the parsing code in hvmloader to reparse for
> > each struct, which was already done by the tools. A simple approach is
> > to use the <length><blob> scheme.
> 
> Yes, I see now why this is necessary, thanks for plugging away at my
> understanding ;-)
> 
> Ian.
> 

Sorry I did not get back sooner, I was out on vacation. So it sounds like I can make another go at this now. Briefly what I plan to do:
 - Pass in the firmware chunks as a list of blobs in struct xc_hvm_build_args to libxc
 - Return the base address where the chunks were loaded for each to the caller
 - The base address, size and checksum for each will be stored in xenstore
 - HVMLOADER will fetch the firmware chunks when building the tables etc.
 - I will address the issues brought up regarding the SMBIOS processing code.

Is it OK if I introduce a shared header in xen/include/public/hvm to collect all the BIOS/FW related xenstore values in one place? Something like hvm_fw_defs.h?

Thanks
Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 18:47:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 18:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN7FC-0006sC-GR; Wed, 25 Apr 2012 18:47:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SN7FA-0006s7-Lf
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 18:47:12 +0000
Received: from [85.158.138.51:53908] by server-9.bemta-3.messagelabs.com id
	68/BD-26691-FA6489F4; Wed, 25 Apr 2012 18:47:11 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335379629!14848315!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21390 invoked from network); 25 Apr 2012 18:47:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 18:47:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,481,1330923600"; d="scan'208";a="24544619"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 14:47:09 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 25 Apr 2012
	14:47:09 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 25 Apr 2012 14:47:06 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0ZWR9ARh6Q+IeQTf6lbeolog3qzQJuTy6Q
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net>
	<CB8D757A.2EB53%keir.xen@gmail.com>
	<20120320092412.GA3544@ocelot.phlegethon.org>
	<20120322112612.GG37468@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720724FB1BE65@FTLPMAILBOX02.citrite.net>
	<1333531815.20300.11.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE52E7@FTLPMAILBOX02.citrite.net>
	<1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334309880.14560.14.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >
> > Yea so the entire SMBIOS table begins with the "struct
> > smbios_entry_point" which is not present in what I pass in. I have N
> > structs (possibly some of the same type) that start with a "struct
> > smbios_structure_header". The gotcha is that the "length" field only
> > defines the fixed portion of each of the SMBIOS structs. There can be
> > any number of strings following that struct of varying length.
> 
> Ah, that's the bit I had forgotten...
> 
> >  Then entire structure is doubly terminated with "\0\0". What I wanted
> > to avoid is having to put the parsing code in hvmloader to reparse for
> > each struct, which was already done by the tools. A simple approach is
> > to use the <length><blob> scheme.
> 
> Yes, I see now why this is necessary, thanks for plugging away at my
> understanding ;-)
> 
> Ian.
> 

Sorry I did not get back sooner, I was out on vacation. So it sounds like I can make another go at this now. Briefly what I plan to do:
 - Pass in the firmware chunks as a list of blobs in struct xc_hvm_build_args to libxc
 - Return the base address where the chunks were loaded for each to the caller
 - The base address, size and checksum for each will be stored in xenstore
 - HVMLOADER will fetch the firmware chunks when building the tables etc.
 - I will address the issues brought up regarding the SMBIOS processing code.

Is it OK if I introduce a shared header in xen/include/public/hvm to collect all the BIOS/FW related xenstore values in one place? Something like hvm_fw_defs.h?

Thanks
Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 20:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 20:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN8VM-0008IF-RL; Wed, 25 Apr 2012 20:08:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SN8VM-0008IA-12
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 20:08:00 +0000
Received: from [85.158.143.99:28973] by server-2.bemta-4.messagelabs.com id
	8C/CB-17550-F99589F4; Wed, 25 Apr 2012 20:07:59 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335384478!24367102!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31836 invoked from network); 25 Apr 2012 20:07:58 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 20:07:58 -0000
Received: from mail60-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 20:07:58 +0000
Received: from mail60-am1 (localhost [127.0.0.1])	by mail60-am1-R.bigfish.com
	(Postfix) with ESMTP id 56C89400E7;
	Wed, 25 Apr 2012 20:07:58 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1
	(MessageSwitch) id 1335384476757380_31897;
	Wed, 25 Apr 2012 20:07:56 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.241])	by
	mail60-am1.bigfish.com (Postfix) with ESMTP id B3E8546006E;
	Wed, 25 Apr 2012 20:07:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 20:07:55 +0000
X-WSS-ID: 0M31X95-02-6XE-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29A7AC80D6;	Wed, 25 Apr 2012 15:07:53 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 15:08:30 -0500
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 15:07:53 -0500
Message-ID: <4F985999.6030401@amd.com>
Date: Wed, 25 Apr 2012 16:07:53 -0400
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CBBDEF99.3EECC%keir@xen.org>
In-Reply-To: <CBBDEF99.3EECC%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, wei.huang2@amd.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/2012 01:14 PM, Keir Fraser wrote:
> On 25/04/2012 17:04, "Wei Huang"<wei.huang2@amd.com>  wrote:
>
>>> I certainly don't feel comfortable ACKing it.  I'd like
>>> to see some testing that demonstrates the patch either improves
>>> functionality or performance without breaking other things.
>>> But if nobody else shares my concern, I don't feel that
>>> I have the right to block it either.
>>
>> We can provide some rdtsc performance numbers. Regarding functionality,
>> it is relatively hard to prove unless Dan has some more specific ideas
>> of testing it. I think the hardware rdtsc scaling is inline with
>> software-based emulated approach.
>
> I've put it in to xen-unstable. I'm not sure about putting into 4.1 for the
> forthcoming release from that branch.

As far as performance numbers are concerned, with this patch applied 
(i.e. native execution) RDTSC instruction executed in a loop takes about 
150ns per iteration. That's including a few instructions for loop control.

With full SW emulation (pre-patch) the same loop is executed in roughly 6us.

Obviously this is not a realistic scenario but it gives a feel of what 
the patch provides.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 20:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 20:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN8VM-0008IF-RL; Wed, 25 Apr 2012 20:08:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SN8VM-0008IA-12
	for xen-devel@lists.xen.org; Wed, 25 Apr 2012 20:08:00 +0000
Received: from [85.158.143.99:28973] by server-2.bemta-4.messagelabs.com id
	8C/CB-17550-F99589F4; Wed, 25 Apr 2012 20:07:59 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335384478!24367102!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31836 invoked from network); 25 Apr 2012 20:07:58 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Apr 2012 20:07:58 -0000
Received: from mail60-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 20:07:58 +0000
Received: from mail60-am1 (localhost [127.0.0.1])	by mail60-am1-R.bigfish.com
	(Postfix) with ESMTP id 56C89400E7;
	Wed, 25 Apr 2012 20:07:58 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25he5bh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1
	(MessageSwitch) id 1335384476757380_31897;
	Wed, 25 Apr 2012 20:07:56 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.241])	by
	mail60-am1.bigfish.com (Postfix) with ESMTP id B3E8546006E;
	Wed, 25 Apr 2012 20:07:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Apr 2012 20:07:55 +0000
X-WSS-ID: 0M31X95-02-6XE-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29A7AC80D6;	Wed, 25 Apr 2012 15:07:53 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 25 Apr 2012 15:08:30 -0500
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Apr 2012 15:07:53 -0500
Message-ID: <4F985999.6030401@amd.com>
Date: Wed, 25 Apr 2012 16:07:53 -0400
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CBBDEF99.3EECC%keir@xen.org>
In-Reply-To: <CBBDEF99.3EECC%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, wei.huang2@amd.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC
 scaling is supported by hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/25/2012 01:14 PM, Keir Fraser wrote:
> On 25/04/2012 17:04, "Wei Huang"<wei.huang2@amd.com>  wrote:
>
>>> I certainly don't feel comfortable ACKing it.  I'd like
>>> to see some testing that demonstrates the patch either improves
>>> functionality or performance without breaking other things.
>>> But if nobody else shares my concern, I don't feel that
>>> I have the right to block it either.
>>
>> We can provide some rdtsc performance numbers. Regarding functionality,
>> it is relatively hard to prove unless Dan has some more specific ideas
>> of testing it. I think the hardware rdtsc scaling is inline with
>> software-based emulated approach.
>
> I've put it in to xen-unstable. I'm not sure about putting into 4.1 for the
> forthcoming release from that branch.

As far as performance numbers are concerned, with this patch applied 
(i.e. native execution) RDTSC instruction executed in a loop takes about 
150ns per iteration. That's including a few instructions for loop control.

With full SW emulation (pre-patch) the same loop is executed in roughly 6us.

Obviously this is not a realistic scenario but it gives a feel of what 
the patch provides.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 20:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 20:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN8yk-0008WK-HM; Wed, 25 Apr 2012 20:38:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN8yj-0008WF-Az
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 20:38:21 +0000
Received: from [85.158.143.99:6643] by server-1.bemta-4.messagelabs.com id
	04/44-20925-CB0689F4; Wed, 25 Apr 2012 20:38:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335386299!24369382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25545 invoked from network); 25 Apr 2012 20:38:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 20:38:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,483,1330905600"; d="scan'208";a="12142051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 20:38:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 21:38:18 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SN8yg-0000r1-Op;
	Wed, 25 Apr 2012 20:38:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SN8yg-0007So-No;
	Wed, 25 Apr 2012 21:38:18 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12753-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 21:38:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12753: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12753 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12753/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7ba11d9b1d23
baseline version:
 xen                  1a8b47d80157

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7ba11d9b1d23
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 7ba11d9b1d23
+ branch=xen-unstable
+ revision=7ba11d9b1d23
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7ba11d9b1d23 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 26 changesets with 65 changes to 41 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 20:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 20:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN8yk-0008WK-HM; Wed, 25 Apr 2012 20:38:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SN8yj-0008WF-Az
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 20:38:21 +0000
Received: from [85.158.143.99:6643] by server-1.bemta-4.messagelabs.com id
	04/44-20925-CB0689F4; Wed, 25 Apr 2012 20:38:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335386299!24369382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjE4MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25545 invoked from network); 25 Apr 2012 20:38:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 20:38:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,483,1330905600"; d="scan'208";a="12142051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 20:38:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Apr 2012 21:38:18 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SN8yg-0000r1-Op;
	Wed, 25 Apr 2012 20:38:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SN8yg-0007So-No;
	Wed, 25 Apr 2012 21:38:18 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12753-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Apr 2012 21:38:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12753: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12753 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12753/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12743

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7ba11d9b1d23
baseline version:
 xen                  1a8b47d80157

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7ba11d9b1d23
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 7ba11d9b1d23
+ branch=xen-unstable
+ revision=7ba11d9b1d23
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7ba11d9b1d23 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 26 changesets with 65 changes to 41 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 20:48:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 20:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN97r-0000Ga-Jd; Wed, 25 Apr 2012 20:47:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN97p-0000GS-E8
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 20:47:45 +0000
Received: from [85.158.138.51:41321] by server-12.bemta-3.messagelabs.com id
	D1/03-29760-0F2689F4; Wed, 25 Apr 2012 20:47:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335386863!23663160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30939 invoked from network); 25 Apr 2012 20:47:43 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 20:47:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN97l-000FVT-Ch; Wed, 25 Apr 2012 20:47:41 +0000
Date: Wed, 25 Apr 2012 21:47:41 +0100
From: Tim Deegan <tim@xen.org>
To: Ross Philipson <Ross.Philipson@citrix.com>
Message-ID: <20120425204741.GH51354@ocelot.phlegethon.org>
References: <1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 14:47 -0400 on 25 Apr (1335365226), Ross Philipson wrote:
> Is it OK if I introduce a shared header in xen/include/public/hvm to
> collect all the BIOS/FW related xenstore values in one place?
> Something like hvm_fw_defs.h?

If at all possible, can you put that header somewhere under tools/ ?
AIUI it doesn't describe a hypervisor interface. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 20:48:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 20:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN97r-0000Ga-Jd; Wed, 25 Apr 2012 20:47:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SN97p-0000GS-E8
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 20:47:45 +0000
Received: from [85.158.138.51:41321] by server-12.bemta-3.messagelabs.com id
	D1/03-29760-0F2689F4; Wed, 25 Apr 2012 20:47:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335386863!23663160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30939 invoked from network); 25 Apr 2012 20:47:43 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Apr 2012 20:47:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SN97l-000FVT-Ch; Wed, 25 Apr 2012 20:47:41 +0000
Date: Wed, 25 Apr 2012 21:47:41 +0100
From: Tim Deegan <tim@xen.org>
To: Ross Philipson <Ross.Philipson@citrix.com>
Message-ID: <20120425204741.GH51354@ocelot.phlegethon.org>
References: <1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 14:47 -0400 on 25 Apr (1335365226), Ross Philipson wrote:
> Is it OK if I introduce a shared header in xen/include/public/hvm to
> collect all the BIOS/FW related xenstore values in one place?
> Something like hvm_fw_defs.h?

If at all possible, can you put that header somewhere under tools/ ?
AIUI it doesn't describe a hypervisor interface. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 21:05:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 21:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN9P5-0000Sh-71; Wed, 25 Apr 2012 21:05:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SN9P4-0000Sc-9i
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 21:05:34 +0000
Received: from [85.158.138.51:4737] by server-6.bemta-3.messagelabs.com id
	DD/C4-05145-D17689F4; Wed, 25 Apr 2012 21:05:33 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335387931!23763417!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32747 invoked from network); 25 Apr 2012 21:05:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 21:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,483,1330923600"; d="scan'208";a="24549645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 17:05:30 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 25 Apr 2012
	17:05:30 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Wed, 25 Apr 2012 17:05:27 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0jJKxYgvOqxkZbTimolQ+TVJdwngAAmp3g
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D8104B9@FTLPMAILBOX02.citrite.net>
References: <1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
	<20120425204741.GH51354@ocelot.phlegethon.org>
In-Reply-To: <20120425204741.GH51354@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Wednesday, April 25, 2012 4:48 PM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> Hi,
> 
> At 14:47 -0400 on 25 Apr (1335365226), Ross Philipson wrote:
> > Is it OK if I introduce a shared header in xen/include/public/hvm to
> > collect all the BIOS/FW related xenstore values in one place?
> > Something like hvm_fw_defs.h?
> 
> If at all possible, can you put that header somewhere under tools/ ?
> AIUI it doesn't describe a hypervisor interface.
> 
> Tim.

Yea I can do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Apr 25 21:05:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Apr 2012 21:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SN9P5-0000Sh-71; Wed, 25 Apr 2012 21:05:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1SN9P4-0000Sc-9i
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 21:05:34 +0000
Received: from [85.158.138.51:4737] by server-6.bemta-3.messagelabs.com id
	DD/C4-05145-D17689F4; Wed, 25 Apr 2012 21:05:33 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335387931!23763417!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk0NzA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32747 invoked from network); 25 Apr 2012 21:05:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 21:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,483,1330923600"; d="scan'208";a="24549645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Apr 2012 17:05:30 -0400
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 25 Apr 2012
	17:05:30 -0400
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Wed, 25 Apr 2012 17:05:27 -0400
Thread-Topic: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
Thread-Index: Ac0jJKxYgvOqxkZbTimolQ+TVJdwngAAmp3g
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D8104B9@FTLPMAILBOX02.citrite.net>
References: <1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
	<20120425204741.GH51354@ocelot.phlegethon.org>
In-Reply-To: <20120425204741.GH51354@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Wednesday, April 25, 2012 4:48 PM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> Hi,
> 
> At 14:47 -0400 on 25 Apr (1335365226), Ross Philipson wrote:
> > Is it OK if I introduce a shared header in xen/include/public/hvm to
> > collect all the BIOS/FW related xenstore values in one place?
> > Something like hvm_fw_defs.h?
> 
> If at all possible, can you put that header somewhere under tools/ ?
> AIUI it doesn't describe a hypervisor interface.
> 
> Tim.

Yea I can do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 01:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 01:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNDBZ-0005Yi-Co; Thu, 26 Apr 2012 01:07:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNDBX-0005Yd-KH
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 01:07:51 +0000
Received: from [85.158.138.51:49690] by server-2.bemta-3.messagelabs.com id
	EB/57-09269-6EF989F4; Thu, 26 Apr 2012 01:07:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335402468!23789037!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NTI5MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7409 invoked from network); 26 Apr 2012 01:07:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 01:07:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3Q17gMS001329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 01:07:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3Q17fGl007350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 01:07:41 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3Q17esu002785; Wed, 25 Apr 2012 20:07:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Apr 2012 18:07:40 -0700
Date: Wed, 25 Apr 2012 18:07:29 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425180729.6a8f7127@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi, 

(Assume VPID is available and enabled.)

I'm trying to figure the TLB stuff with VPIDs. I understand from the
poorly written chapter in the intel manual that if an HVM vcpu is running
then only the TLBs tagged with the vcpu.VPID will be used. If xen
or a PV guest is running, then VPID 0 TLBs are what will be used. 

Now I understand the hvm_asid_flush_vcpu upon new guest cr3, will jsut
create a new asid/vpid, so the older vcpu.vpid tlb entries will just not
be used.

However, I don't understand the use of hvm_asid_flush_core which
it appears will cause all HVM vcpu's to get new vpid/asid, hence, discard
all previously used VPID tagged TLBs. In particular, consider a PV
guest:

write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs -> hvm_asid_flush_core(). 

Since the PV guest is only using VPID 0 tagged TLBs, why do we need to
flush all TLBs for all HVM guests? 

thanks
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 01:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 01:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNDBZ-0005Yi-Co; Thu, 26 Apr 2012 01:07:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNDBX-0005Yd-KH
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 01:07:51 +0000
Received: from [85.158.138.51:49690] by server-2.bemta-3.messagelabs.com id
	EB/57-09269-6EF989F4; Thu, 26 Apr 2012 01:07:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335402468!23789037!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NTI5MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7409 invoked from network); 26 Apr 2012 01:07:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 01:07:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3Q17gMS001329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 01:07:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3Q17fGl007350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 01:07:41 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3Q17esu002785; Wed, 25 Apr 2012 20:07:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Apr 2012 18:07:40 -0700
Date: Wed, 25 Apr 2012 18:07:29 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120425180729.6a8f7127@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi, 

(Assume VPID is available and enabled.)

I'm trying to figure the TLB stuff with VPIDs. I understand from the
poorly written chapter in the intel manual that if an HVM vcpu is running
then only the TLBs tagged with the vcpu.VPID will be used. If xen
or a PV guest is running, then VPID 0 TLBs are what will be used. 

Now I understand the hvm_asid_flush_vcpu upon new guest cr3, will jsut
create a new asid/vpid, so the older vcpu.vpid tlb entries will just not
be used.

However, I don't understand the use of hvm_asid_flush_core which
it appears will cause all HVM vcpu's to get new vpid/asid, hence, discard
all previously used VPID tagged TLBs. In particular, consider a PV
guest:

write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs -> hvm_asid_flush_core(). 

Since the PV guest is only using VPID 0 tagged TLBs, why do we need to
flush all TLBs for all HVM guests? 

thanks
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 02:16:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 02:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNEFG-0006H2-Mq; Thu, 26 Apr 2012 02:15:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNEFF-0006Gv-6o
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 02:15:45 +0000
Received: from [85.158.143.35:12675] by server-1.bemta-4.messagelabs.com id
	BB/FC-20925-0DFA89F4; Thu, 26 Apr 2012 02:15:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335406543!14919523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30007 invoked from network); 26 Apr 2012 02:15:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 02:15:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,484,1330905600"; d="scan'208";a="12143993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 02:15:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 03:15:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNEFB-0002u1-Pa;
	Thu, 26 Apr 2012 02:15:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNEFB-0001ZM-Jr;
	Thu, 26 Apr 2012 03:15:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12754-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 03:15:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12754: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12754 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12754/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12753

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a4e7fce6ee2b
baseline version:
 xen                  7ba11d9b1d23

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4e7fce6ee2b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a4e7fce6ee2b
+ branch=xen-unstable
+ revision=a4e7fce6ee2b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4e7fce6ee2b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 02:16:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 02:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNEFG-0006H2-Mq; Thu, 26 Apr 2012 02:15:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNEFF-0006Gv-6o
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 02:15:45 +0000
Received: from [85.158.143.35:12675] by server-1.bemta-4.messagelabs.com id
	BB/FC-20925-0DFA89F4; Thu, 26 Apr 2012 02:15:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335406543!14919523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30007 invoked from network); 26 Apr 2012 02:15:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 02:15:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,484,1330905600"; d="scan'208";a="12143993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 02:15:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 03:15:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNEFB-0002u1-Pa;
	Thu, 26 Apr 2012 02:15:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNEFB-0001ZM-Jr;
	Thu, 26 Apr 2012 03:15:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12754-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 03:15:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12754: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12754 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12754/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12753

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a4e7fce6ee2b
baseline version:
 xen                  7ba11d9b1d23

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4e7fce6ee2b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a4e7fce6ee2b
+ branch=xen-unstable
+ revision=a4e7fce6ee2b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4e7fce6ee2b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 03:01:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 03:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNEwo-0006Zi-IC; Thu, 26 Apr 2012 03:00:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNEwm-0006Zb-EL
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 03:00:44 +0000
Received: from [85.158.143.35:25175] by server-2.bemta-4.messagelabs.com id
	CD/5D-17550-B5AB89F4; Thu, 26 Apr 2012 03:00:43 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335409240!11634273!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTMxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29291 invoked from network); 26 Apr 2012 03:00:42 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-2.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 03:00:42 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Wed, 25 Apr
	2012 23:00:39 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 25 Apr 2012 22:00:18 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 08:30:14 +0530
MIME-Version: 1.0
X-Mercurial-Node: ec8e99606fbea7eb2ed2ad8b2ec6ce650f575d01
Message-ID: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Apr 2012 11:00:31 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042523003900401
Cc: xuesen.guo@hitachiconsulting.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Thu Apr 26 10:57:09 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return 1;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 03:01:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 03:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNEwo-0006Zi-IC; Thu, 26 Apr 2012 03:00:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNEwm-0006Zb-EL
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 03:00:44 +0000
Received: from [85.158.143.35:25175] by server-2.bemta-4.messagelabs.com id
	CD/5D-17550-B5AB89F4; Thu, 26 Apr 2012 03:00:43 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335409240!11634273!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTMxMTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29291 invoked from network); 26 Apr 2012 03:00:42 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-2.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 03:00:42 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Wed, 25 Apr
	2012 23:00:39 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Wed, 25 Apr 2012 22:00:18 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 08:30:14 +0530
MIME-Version: 1.0
X-Mercurial-Node: ec8e99606fbea7eb2ed2ad8b2ec6ce650f575d01
Message-ID: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Apr 2012 11:00:31 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042523003900401
Cc: xuesen.guo@hitachiconsulting.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>

diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Thu Apr 26 10:57:09 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,6 +204,27 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return 1;
+		}
+
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+
+		image = image + payload_offset;
+		st.st_size = payload_length;
+	}
+	
 	size = st.st_size;
 
 	usize = xc_dom_check_gzip(xch, image, st.st_size);

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 06:49:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 06:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNIVS-0007hC-Lf; Thu, 26 Apr 2012 06:48:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SNIVR-0007h7-Kj
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 06:48:45 +0000
Received: from [85.158.139.83:2604] by server-2.bemta-5.messagelabs.com id
	0C/C8-17016-CCFE89F4; Thu, 26 Apr 2012 06:48:44 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335422921!18198668!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7738 invoked from network); 26 Apr 2012 06:48:43 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 06:48:43 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id B1B5310210F36;
	Wed, 25 Apr 2012 23:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id e6ScK9ZCOR5N; Wed, 25 Apr 2012 23:48:39 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id BF15C10210F33;
	Wed, 25 Apr 2012 23:48:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
Date: Wed, 25 Apr 2012 23:48:38 -0700
Message-Id: <EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
	<alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1933526598445806702=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1933526598445806702==
Content-Type: multipart/alternative; boundary="Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A"


--Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 25, 2012, at 8:50 AM, Stefano Stabellini wrote:

> It looks like the disk was opened correctly, maybe more logging will
> tell us what is going wrong.
> Could you please try the following patch?
>=20


domid: 1
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram =
set to 4M.
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:628: Init blktap pipes
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:603: Created /var/run/tap directory
Could not open /var/run/tap/qemu-read-1
xen be: console-0: backend state: Unknown -> Initialising
char device redirected to /dev/pts/2
xen be: console-0: backend state: Initialising -> InitWait
xen be: console-0: frontend not ready, ignoring
xen be: console-0: bind evtchn port 70
xen be: console-0: ring mfn 412787, remote port 2, local port 70, limit =
1048576
xen be: console-0: backend state: InitWait -> Connected
xen be: qdisk-51712: backend state: Unknown -> Initialising
xen be: qdisk-51712: frontend state: Unknown -> Initialising
DEBUG blk_init 587
DEBUG blk_init 602 filename=3D/var/finnix/finnix-104.iso
DEBUG blk_init 613 protocol=3Draw
DEBUG blk_init 622
DEBUG blk_init 636
xen be: qdisk-51712: create new bdrv (xenbus setup)
DEBUG blk_init 659
xen be: qdisk-51712: type "tap", fileproto "raw", filename =
"/var/finnix/finnix-104.iso", size 121708544 (116 MB)
xen be: qdisk-51712: backend state: Initialising -> InitWait
xen be: qdisk-51712: frontend not ready (yet)
xs_read(): target get error. /local/domain/1/target.
xen be: console-0: backend update: state
xen be: console-0: frontend update: tty
xen be: console-0: backend update: hotplug-status
xen be: console-0: backend update: state
xen be: console-0: backend update: state
xen be: qdisk-51712: backend update: state
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: feature-barrier
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: info
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: sector-size
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: sectors
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: hotplug-status
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: state
xen be: qdisk-51712: frontend not ready (yet)
xen be core: displaystate setup failed
(qemu) (qemu) xen be: console-0: backlog piling up, nobody listening?



--Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 25, 2012, at 8:50 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">It looks like =
the disk was opened correctly, maybe more logging will<br>tell us what =
is going wrong.<br>Could you please try the following =
patch?<br><br></span></blockquote></div><br><div><br></div><div><div>domid=
: 1</div><div>Warning: vlan 0 is not connected to host =
network</div><div>-videoram option does not work with cirrus vga device =
model. Videoram set to =
4M.</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen=
/hw/xen_blktap.c:628: Init blktap =
pipes</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-x=
en/hw/xen_blktap.c:603: Created /var/run/tap directory</div><div>Could =
not open /var/run/tap/qemu-read-1</div><div>xen be: console-0: backend =
state: Unknown -&gt; Initialising</div><div>char device redirected to =
/dev/pts/2</div><div>xen be: console-0: backend state: Initialising =
-&gt; InitWait</div><div>xen be: console-0: frontend not ready, =
ignoring</div><div>xen be: console-0: bind evtchn port 70</div><div>xen =
be: console-0: ring mfn 412787, remote port 2, local port 70, limit =
1048576</div><div>xen be: console-0: backend state: InitWait -&gt; =
Connected</div><div>xen be: qdisk-51712: backend state: Unknown -&gt; =
Initialising</div><div>xen be: qdisk-51712: frontend state: Unknown =
-&gt; Initialising</div><div>DEBUG blk_init 587</div><div>DEBUG blk_init =
602 filename=3D/var/finnix/finnix-104.iso</div><div>DEBUG blk_init 613 =
protocol=3Draw</div><div>DEBUG blk_init 622</div><div>DEBUG blk_init =
636</div><div>xen be: qdisk-51712: create new bdrv (xenbus =
setup)</div><div>DEBUG blk_init 659</div><div>xen be: qdisk-51712: type =
"tap", fileproto "raw", filename "/var/finnix/finnix-104.iso", size =
121708544 (116 MB)</div><div>xen be: qdisk-51712: backend state: =
Initialising -&gt; InitWait</div><div>xen be: qdisk-51712: frontend not =
ready (yet)</div><div>xs_read(): target get error. =
/local/domain/1/target.</div><div>xen be: console-0: backend update: =
state</div><div>xen be: console-0: frontend update: tty</div><div>xen =
be: console-0: backend update: hotplug-status</div><div>xen be: =
console-0: backend update: state</div><div>xen be: console-0: backend =
update: state</div><div>xen be: qdisk-51712: backend update: =
state</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: =
feature-barrier</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: info</div><div>xen =
be: qdisk-51712: frontend not ready (yet)</div><div>xen be: qdisk-51712: =
backend update: sector-size</div><div>xen be: qdisk-51712: frontend not =
ready (yet)</div><div>xen be: qdisk-51712: backend update: =
sectors</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: =
hotplug-status</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: state</div><div>xen =
be: qdisk-51712: frontend not ready (yet)</div><div>xen be core: =
displaystate setup failed</div><div>(qemu) (qemu) xen be: console-0: =
backlog piling up, nobody =
listening?</div></div><div><br></div><div><br></div></body></html>=

--Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A--


--===============1933526598445806702==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1933526598445806702==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 06:49:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 06:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNIVS-0007hC-Lf; Thu, 26 Apr 2012 06:48:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SNIVR-0007h7-Kj
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 06:48:45 +0000
Received: from [85.158.139.83:2604] by server-2.bemta-5.messagelabs.com id
	0C/C8-17016-CCFE89F4; Thu, 26 Apr 2012 06:48:44 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335422921!18198668!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7738 invoked from network); 26 Apr 2012 06:48:43 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 06:48:43 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id B1B5310210F36;
	Wed, 25 Apr 2012 23:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id e6ScK9ZCOR5N; Wed, 25 Apr 2012 23:48:39 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id BF15C10210F33;
	Wed, 25 Apr 2012 23:48:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
Date: Wed, 25 Apr 2012 23:48:38 -0700
Message-Id: <EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
	<alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1933526598445806702=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1933526598445806702==
Content-Type: multipart/alternative; boundary="Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A"


--Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 25, 2012, at 8:50 AM, Stefano Stabellini wrote:

> It looks like the disk was opened correctly, maybe more logging will
> tell us what is going wrong.
> Could you please try the following patch?
>=20


domid: 1
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram =
set to 4M.
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:628: Init blktap pipes
=
/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap=
.c:603: Created /var/run/tap directory
Could not open /var/run/tap/qemu-read-1
xen be: console-0: backend state: Unknown -> Initialising
char device redirected to /dev/pts/2
xen be: console-0: backend state: Initialising -> InitWait
xen be: console-0: frontend not ready, ignoring
xen be: console-0: bind evtchn port 70
xen be: console-0: ring mfn 412787, remote port 2, local port 70, limit =
1048576
xen be: console-0: backend state: InitWait -> Connected
xen be: qdisk-51712: backend state: Unknown -> Initialising
xen be: qdisk-51712: frontend state: Unknown -> Initialising
DEBUG blk_init 587
DEBUG blk_init 602 filename=3D/var/finnix/finnix-104.iso
DEBUG blk_init 613 protocol=3Draw
DEBUG blk_init 622
DEBUG blk_init 636
xen be: qdisk-51712: create new bdrv (xenbus setup)
DEBUG blk_init 659
xen be: qdisk-51712: type "tap", fileproto "raw", filename =
"/var/finnix/finnix-104.iso", size 121708544 (116 MB)
xen be: qdisk-51712: backend state: Initialising -> InitWait
xen be: qdisk-51712: frontend not ready (yet)
xs_read(): target get error. /local/domain/1/target.
xen be: console-0: backend update: state
xen be: console-0: frontend update: tty
xen be: console-0: backend update: hotplug-status
xen be: console-0: backend update: state
xen be: console-0: backend update: state
xen be: qdisk-51712: backend update: state
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: feature-barrier
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: info
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: sector-size
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: sectors
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: hotplug-status
xen be: qdisk-51712: frontend not ready (yet)
xen be: qdisk-51712: backend update: state
xen be: qdisk-51712: frontend not ready (yet)
xen be core: displaystate setup failed
(qemu) (qemu) xen be: console-0: backlog piling up, nobody listening?



--Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 25, 2012, at 8:50 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">It looks like =
the disk was opened correctly, maybe more logging will<br>tell us what =
is going wrong.<br>Could you please try the following =
patch?<br><br></span></blockquote></div><br><div><br></div><div><div>domid=
: 1</div><div>Warning: vlan 0 is not connected to host =
network</div><div>-videoram option does not work with cirrus vga device =
model. Videoram set to =
4M.</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen=
/hw/xen_blktap.c:628: Init blktap =
pipes</div><div>/home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-x=
en/hw/xen_blktap.c:603: Created /var/run/tap directory</div><div>Could =
not open /var/run/tap/qemu-read-1</div><div>xen be: console-0: backend =
state: Unknown -&gt; Initialising</div><div>char device redirected to =
/dev/pts/2</div><div>xen be: console-0: backend state: Initialising =
-&gt; InitWait</div><div>xen be: console-0: frontend not ready, =
ignoring</div><div>xen be: console-0: bind evtchn port 70</div><div>xen =
be: console-0: ring mfn 412787, remote port 2, local port 70, limit =
1048576</div><div>xen be: console-0: backend state: InitWait -&gt; =
Connected</div><div>xen be: qdisk-51712: backend state: Unknown -&gt; =
Initialising</div><div>xen be: qdisk-51712: frontend state: Unknown =
-&gt; Initialising</div><div>DEBUG blk_init 587</div><div>DEBUG blk_init =
602 filename=3D/var/finnix/finnix-104.iso</div><div>DEBUG blk_init 613 =
protocol=3Draw</div><div>DEBUG blk_init 622</div><div>DEBUG blk_init =
636</div><div>xen be: qdisk-51712: create new bdrv (xenbus =
setup)</div><div>DEBUG blk_init 659</div><div>xen be: qdisk-51712: type =
"tap", fileproto "raw", filename "/var/finnix/finnix-104.iso", size =
121708544 (116 MB)</div><div>xen be: qdisk-51712: backend state: =
Initialising -&gt; InitWait</div><div>xen be: qdisk-51712: frontend not =
ready (yet)</div><div>xs_read(): target get error. =
/local/domain/1/target.</div><div>xen be: console-0: backend update: =
state</div><div>xen be: console-0: frontend update: tty</div><div>xen =
be: console-0: backend update: hotplug-status</div><div>xen be: =
console-0: backend update: state</div><div>xen be: console-0: backend =
update: state</div><div>xen be: qdisk-51712: backend update: =
state</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: =
feature-barrier</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: info</div><div>xen =
be: qdisk-51712: frontend not ready (yet)</div><div>xen be: qdisk-51712: =
backend update: sector-size</div><div>xen be: qdisk-51712: frontend not =
ready (yet)</div><div>xen be: qdisk-51712: backend update: =
sectors</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: =
hotplug-status</div><div>xen be: qdisk-51712: frontend not ready =
(yet)</div><div>xen be: qdisk-51712: backend update: state</div><div>xen =
be: qdisk-51712: frontend not ready (yet)</div><div>xen be core: =
displaystate setup failed</div><div>(qemu) (qemu) xen be: console-0: =
backlog piling up, nobody =
listening?</div></div><div><br></div><div><br></div></body></html>=

--Apple-Mail=_582A16E6-FDD3-4236-A146-F76D31A1FA7A--


--===============1933526598445806702==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1933526598445806702==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 07:24:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJ3A-00085t-Lu; Thu, 26 Apr 2012 07:23:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SNJ38-00085o-Tv
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 07:23:35 +0000
Received: from [85.158.139.83:3386] by server-5.bemta-5.messagelabs.com id
	86/8C-13566-6F7F89F4; Thu, 26 Apr 2012 07:23:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335425013!18203976!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16634 invoked from network); 26 Apr 2012 07:23:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:23:33 -0000
Received: by werf13 with SMTP id f13so649608wer.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 26 Apr 2012 00:23:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=RIl8ZeSMaVlXB7OAAiICii+avCRFnKcxlQFU6/P71sI=;
	b=l2jczoUkzSMZHu2ziJL6q9kpSa/LRW1kv8OVcakkLv6nCa0JDeETrb1XcVkwHlVmkB
	QSf9a6jdMLn+bTk0yrsDkrt+dkkU2P+NZ7xLXWy1r9WiCXtmGlcMLOIAYlmV/pEL0y/X
	fzBmVe9iMqrJ5uDB3QEaQv7aokhmHGjCxmGGzL0wZc0Pnn8dSBv5+XPuq1lL6+NXgIap
	Ludwn5YMU/f7TB8FE+Zj7RmD/DTgkwua/qyHmmy+cVZBLephfOfWm6Ue+CfNATzCtKIX
	XiflNGXHV3Dipig/tAebeUf2V4stUSXB3RFd/VCr9H1seBSZNkClGNUp7wilCo76XFmV
	CsiQ==
Received: by 10.216.138.135 with SMTP id a7mr3593186wej.19.1335425013123;
	Thu, 26 Apr 2012 00:23:33 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id fn2sm8251712wib.0.2012.04.26.00.23.32
	(version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 00:23:32 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Apr 2012 08:23:29 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CBBEB681.319A3%keir.xen@gmail.com>
Thread-Topic: [help]: VPID tagged TLBs question.
Thread-Index: Ac0jfXoZOXaKg8Fkv0W6bSZ36mQw8g==
In-Reply-To: <20120425180729.6a8f7127@mantra.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> However, I don't understand the use of hvm_asid_flush_core which
> it appears will cause all HVM vcpu's to get new vpid/asid, hence, discard
> all previously used VPID tagged TLBs. In particular, consider a PV
> guest:
> 
> write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs -> hvm_asid_flush_core().
> 
> Since the PV guest is only using VPID 0 tagged TLBs, why do we need to
> flush all TLBs for all HVM guests?

It's just being conservative, as callers of write_cr3 may assume that the
TLB is entirely flushed, for all guests.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 07:24:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJ3A-00085t-Lu; Thu, 26 Apr 2012 07:23:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SNJ38-00085o-Tv
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 07:23:35 +0000
Received: from [85.158.139.83:3386] by server-5.bemta-5.messagelabs.com id
	86/8C-13566-6F7F89F4; Thu, 26 Apr 2012 07:23:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335425013!18203976!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16634 invoked from network); 26 Apr 2012 07:23:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:23:33 -0000
Received: by werf13 with SMTP id f13so649608wer.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 26 Apr 2012 00:23:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=RIl8ZeSMaVlXB7OAAiICii+avCRFnKcxlQFU6/P71sI=;
	b=l2jczoUkzSMZHu2ziJL6q9kpSa/LRW1kv8OVcakkLv6nCa0JDeETrb1XcVkwHlVmkB
	QSf9a6jdMLn+bTk0yrsDkrt+dkkU2P+NZ7xLXWy1r9WiCXtmGlcMLOIAYlmV/pEL0y/X
	fzBmVe9iMqrJ5uDB3QEaQv7aokhmHGjCxmGGzL0wZc0Pnn8dSBv5+XPuq1lL6+NXgIap
	Ludwn5YMU/f7TB8FE+Zj7RmD/DTgkwua/qyHmmy+cVZBLephfOfWm6Ue+CfNATzCtKIX
	XiflNGXHV3Dipig/tAebeUf2V4stUSXB3RFd/VCr9H1seBSZNkClGNUp7wilCo76XFmV
	CsiQ==
Received: by 10.216.138.135 with SMTP id a7mr3593186wej.19.1335425013123;
	Thu, 26 Apr 2012 00:23:33 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id fn2sm8251712wib.0.2012.04.26.00.23.32
	(version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 00:23:32 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Apr 2012 08:23:29 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CBBEB681.319A3%keir.xen@gmail.com>
Thread-Topic: [help]: VPID tagged TLBs question.
Thread-Index: Ac0jfXoZOXaKg8Fkv0W6bSZ36mQw8g==
In-Reply-To: <20120425180729.6a8f7127@mantra.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> However, I don't understand the use of hvm_asid_flush_core which
> it appears will cause all HVM vcpu's to get new vpid/asid, hence, discard
> all previously used VPID tagged TLBs. In particular, consider a PV
> guest:
> 
> write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs -> hvm_asid_flush_core().
> 
> Since the PV guest is only using VPID 0 tagged TLBs, why do we need to
> flush all TLBs for all HVM guests?

It's just being conservative, as callers of write_cr3 may assume that the
TLB is entirely flushed, for all guests.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 07:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJ9s-0008EN-IJ; Thu, 26 Apr 2012 07:30:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNJ9r-0008EH-D9
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 07:30:31 +0000
Received: from [85.158.138.51:15637] by server-2.bemta-3.messagelabs.com id
	C3/C2-09269-699F89F4; Thu, 26 Apr 2012 07:30:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335425429!15926268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27824 invoked from network); 26 Apr 2012 07:30:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12146558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:30:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:30:29 +0100
Message-ID: <1335425428.4881.52.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Thu, 26 Apr 2012 08:30:28 +0100
In-Reply-To: <CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(putting xen-devel back, please watch your cc lines)
On Wed, 2012-04-25 at 20:45 +0100, Sandi Romih wrote:
> 
> On Apr 25, 2012 6:38 PM, "Ian Campbell" <Ian.Campbell@citrix.com>
> wrote:
> >
> > On Tue, 2012-04-24 at 21:28 +0100, Sandi Romih wrote:
> >
> > > What I did discover is that the VM boot is halted by the vif
> option in
> > > my cfg file.
> >
> > What do you mean "halted"? You mean that pygrub fails if you have
> the
> > vif line and succeeds if you do not?
> 
> Well, I guess I should have used the word pauses, as the vm is still
> running okay but it does not proceed beyond a certain point. When I
> comment out the vif line the boot process does not stop, it proceeds
> normally.

So this is now a different failure mode to the one which you originally
reported (pygrub failed)?

What does your guest config look like now that you have resolved the
pygrub issue?

Can you provide a full log of the failing boot with a vif enabled to the
point of the hang?

Are your hotplug scripts set up properly?

What does "brctl show" say while the guest is running (with the vif
enabled)?

What does "xenstore-ls -fp" show while the guest is sat waiting?

http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen has a list of other
potentially useful logs/info which you should consider including.

> > >  disk =
> > > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > > 'phy:/dev/xen-dom0/oi_boot,xvda,w' ]
> >
> > Can I download oi161a.iso from somewhere so I can try for myself?
> 
> Yes, you can download it from here:
> http://openindiana.org/download/ 

I can only find oi-dev-151a-x86.iso and oi-dev-151a-text-x86.iso here
(and the usb stick equivalents).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 07:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJ9s-0008EN-IJ; Thu, 26 Apr 2012 07:30:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNJ9r-0008EH-D9
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 07:30:31 +0000
Received: from [85.158.138.51:15637] by server-2.bemta-3.messagelabs.com id
	C3/C2-09269-699F89F4; Thu, 26 Apr 2012 07:30:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335425429!15926268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27824 invoked from network); 26 Apr 2012 07:30:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12146558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:30:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:30:29 +0100
Message-ID: <1335425428.4881.52.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Thu, 26 Apr 2012 08:30:28 +0100
In-Reply-To: <CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(putting xen-devel back, please watch your cc lines)
On Wed, 2012-04-25 at 20:45 +0100, Sandi Romih wrote:
> 
> On Apr 25, 2012 6:38 PM, "Ian Campbell" <Ian.Campbell@citrix.com>
> wrote:
> >
> > On Tue, 2012-04-24 at 21:28 +0100, Sandi Romih wrote:
> >
> > > What I did discover is that the VM boot is halted by the vif
> option in
> > > my cfg file.
> >
> > What do you mean "halted"? You mean that pygrub fails if you have
> the
> > vif line and succeeds if you do not?
> 
> Well, I guess I should have used the word pauses, as the vm is still
> running okay but it does not proceed beyond a certain point. When I
> comment out the vif line the boot process does not stop, it proceeds
> normally.

So this is now a different failure mode to the one which you originally
reported (pygrub failed)?

What does your guest config look like now that you have resolved the
pygrub issue?

Can you provide a full log of the failing boot with a vif enabled to the
point of the hang?

Are your hotplug scripts set up properly?

What does "brctl show" say while the guest is running (with the vif
enabled)?

What does "xenstore-ls -fp" show while the guest is sat waiting?

http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen has a list of other
potentially useful logs/info which you should consider including.

> > >  disk =
> > > [ 'file:/mnt/media/comp_files/os-iso/oi151a.iso,xvdc:cdrom,r' ,
> > > 'phy:/dev/xen-dom0/oi_boot,xvda,w' ]
> >
> > Can I download oi161a.iso from somewhere so I can try for myself?
> 
> Yes, you can download it from here:
> http://openindiana.org/download/ 

I can only find oi-dev-151a-x86.iso and oi-dev-151a-text-x86.iso here
(and the usb stick equivalents).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 07:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJIc-0008PE-Iq; Thu, 26 Apr 2012 07:39:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNJIb-0008P9-HG
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 07:39:33 +0000
Received: from [85.158.143.99:40308] by server-1.bemta-4.messagelabs.com id
	18/09-20925-4BBF89F4; Thu, 26 Apr 2012 07:39:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335425971!20083406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23878 invoked from network); 26 Apr 2012 07:39:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12146747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:39:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:39:11 +0100
Message-ID: <1335425950.4881.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Date: Thu, 26 Apr 2012 08:39:10 +0100
In-Reply-To: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
References: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 04:00 +0100, Xuesen Guo wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels
> 
> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> 
> diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
> --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/xcutils/readnotes.c	Thu Apr 26 10:57:09 2012 +0800
> @@ -18,6 +18,48 @@
>  
>  static xc_interface *xch;
>  
> +/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
> +/* We add support of bzImage kernel */
> +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> +struct setup_header {
> +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> +	uint8_t  setup_sects;
> +	uint16_t root_flags;
> +	uint32_t syssize;
> +	uint16_t ram_size;
> +	uint16_t vid_mode;
> +	uint16_t root_dev;
> +	uint16_t boot_flag;
> +	uint16_t jump;
> +	uint32_t header;
> +#define HDR_MAGIC  "HdrS"
> +#define HDR_MAGIC_SZ 4
> +	uint16_t version;
> +#define VERSION(h,l) (((h)<<8) | (l))
> +	uint32_t realmode_swtch;
> +	uint16_t start_sys;
> +	uint16_t kernel_version;
> +	uint8_t  type_of_loader;
> +	uint8_t  loadflags;
> +	uint16_t setup_move_size;
> +	uint32_t code32_start;
> +	uint32_t ramdisk_image;
> +	uint32_t ramdisk_size;
> +	uint32_t bootsect_kludge;
> +	uint16_t heap_end_ptr;
> +	uint16_t _pad1;
> +	uint32_t cmd_line_ptr;
> +	uint32_t initrd_addr_max;
> +	uint32_t kernel_alignment;
> +	uint8_t  relocatable_kernel;
> +	uint8_t  _pad2[3];
> +	uint32_t cmdline_size;
> +	uint32_t hardware_subarch;
> +	uint64_t hardware_subarch_data;
> +	uint32_t payload_offset;
> +	uint32_t payload_length;
> +} __attribute__((packed));
> +
>  static void print_string_note(const char *prefix, struct elf_binary *elf,
>  			      const elf_note *note)
>  {
> @@ -131,6 +173,9 @@ int main(int argc, char **argv)
>  	const elf_shdr *shdr;
>  	int notes_found = 0;
>  
> +	struct setup_header *hdr;
> +	uint64_t payload_offset, payload_length;
> +
>  	if (argc != 2)
>  	{
>  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> @@ -159,6 +204,27 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return 1;
> +		}
> +
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;

Up to this point this is all the same as xc_dom_probe_bzimage_kernel and
therefore looks to me to be safe and correct.

However xc_dom_probe_bzimage_kernel has some additional checks before it
trusts the offset and length. Specifically it compares them against the
size of the on disk kernel image:
    if ( payload_offset >= dom->kernel_size )
    {
        xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload offset overflow",
                     __FUNCTION__);
        return -EINVAL;
    }
    if ( (payload_offset + payload_length) > dom->kernel_size )
    {
        xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload length overflow",
                     __FUNCTION__);
        return -EINVAL;
    }

I think you likely want to retain some similar check here, using
st.st_size as the boundary instead of dom->kernel_size.

> +
> +		image = image + payload_offset;
> +		st.st_size = payload_length;
> +	}
> +	
>  	size = st.st_size;

The usage of size vs st.st_size in the existing code is not very
obvious, IMHO it would be preferable to consistently always use size
from this point on, since changing st.st_size has the possibility of
surprise. IOW the tail here would be:

		image = image + payload_offset;
		size = payload_length
	} else {
		size = st.st_size;
 	}

and then use size and not st.st_size for the remainder of the function.

Ian.

>  	usize = xc_dom_check_gzip(xch, image, st.st_size);
> 
> This e-mail is intended solely for the person or entity to which it is addressed
> and may contain confidential and/or privileged information. Any review, dissemination,
> copying, printing or other use of this e-mail by persons or entities other than the 
> addressee is prohibited. If you have received this e-mail in error, please contact
> the sender immediately and delete the material from any computer.
> To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 07:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJIc-0008PE-Iq; Thu, 26 Apr 2012 07:39:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNJIb-0008P9-HG
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 07:39:33 +0000
Received: from [85.158.143.99:40308] by server-1.bemta-4.messagelabs.com id
	18/09-20925-4BBF89F4; Thu, 26 Apr 2012 07:39:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1335425971!20083406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23878 invoked from network); 26 Apr 2012 07:39:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12146747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:39:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:39:11 +0100
Message-ID: <1335425950.4881.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Date: Thu, 26 Apr 2012 08:39:10 +0100
In-Reply-To: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
References: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 04:00 +0100, Xuesen Guo wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels
> 
> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> 
> diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
> --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/xcutils/readnotes.c	Thu Apr 26 10:57:09 2012 +0800
> @@ -18,6 +18,48 @@
>  
>  static xc_interface *xch;
>  
> +/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
> +/* We add support of bzImage kernel */
> +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> +struct setup_header {
> +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> +	uint8_t  setup_sects;
> +	uint16_t root_flags;
> +	uint32_t syssize;
> +	uint16_t ram_size;
> +	uint16_t vid_mode;
> +	uint16_t root_dev;
> +	uint16_t boot_flag;
> +	uint16_t jump;
> +	uint32_t header;
> +#define HDR_MAGIC  "HdrS"
> +#define HDR_MAGIC_SZ 4
> +	uint16_t version;
> +#define VERSION(h,l) (((h)<<8) | (l))
> +	uint32_t realmode_swtch;
> +	uint16_t start_sys;
> +	uint16_t kernel_version;
> +	uint8_t  type_of_loader;
> +	uint8_t  loadflags;
> +	uint16_t setup_move_size;
> +	uint32_t code32_start;
> +	uint32_t ramdisk_image;
> +	uint32_t ramdisk_size;
> +	uint32_t bootsect_kludge;
> +	uint16_t heap_end_ptr;
> +	uint16_t _pad1;
> +	uint32_t cmd_line_ptr;
> +	uint32_t initrd_addr_max;
> +	uint32_t kernel_alignment;
> +	uint8_t  relocatable_kernel;
> +	uint8_t  _pad2[3];
> +	uint32_t cmdline_size;
> +	uint32_t hardware_subarch;
> +	uint64_t hardware_subarch_data;
> +	uint32_t payload_offset;
> +	uint32_t payload_length;
> +} __attribute__((packed));
> +
>  static void print_string_note(const char *prefix, struct elf_binary *elf,
>  			      const elf_note *note)
>  {
> @@ -131,6 +173,9 @@ int main(int argc, char **argv)
>  	const elf_shdr *shdr;
>  	int notes_found = 0;
>  
> +	struct setup_header *hdr;
> +	uint64_t payload_offset, payload_length;
> +
>  	if (argc != 2)
>  	{
>  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> @@ -159,6 +204,27 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return 1;
> +		}
> +
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;

Up to this point this is all the same as xc_dom_probe_bzimage_kernel and
therefore looks to me to be safe and correct.

However xc_dom_probe_bzimage_kernel has some additional checks before it
trusts the offset and length. Specifically it compares them against the
size of the on disk kernel image:
    if ( payload_offset >= dom->kernel_size )
    {
        xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload offset overflow",
                     __FUNCTION__);
        return -EINVAL;
    }
    if ( (payload_offset + payload_length) > dom->kernel_size )
    {
        xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload length overflow",
                     __FUNCTION__);
        return -EINVAL;
    }

I think you likely want to retain some similar check here, using
st.st_size as the boundary instead of dom->kernel_size.

> +
> +		image = image + payload_offset;
> +		st.st_size = payload_length;
> +	}
> +	
>  	size = st.st_size;

The usage of size vs st.st_size in the existing code is not very
obvious, IMHO it would be preferable to consistently always use size
from this point on, since changing st.st_size has the possibility of
surprise. IOW the tail here would be:

		image = image + payload_offset;
		size = payload_length
	} else {
		size = st.st_size;
 	}

and then use size and not st.st_size for the remainder of the function.

Ian.

>  	usize = xc_dom_check_gzip(xch, image, st.st_size);
> 
> This e-mail is intended solely for the person or entity to which it is addressed
> and may contain confidential and/or privileged information. Any review, dissemination,
> copying, printing or other use of this e-mail by persons or entities other than the 
> addressee is prohibited. If you have received this e-mail in error, please contact
> the sender immediately and delete the material from any computer.
> To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 07:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJP5-00008Y-Hg; Thu, 26 Apr 2012 07:46:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNJP3-00008S-KH
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 07:46:13 +0000
Received: from [193.109.254.147:27189] by server-6.bemta-14.messagelabs.com id
	40/1C-02047-44DF89F4; Thu, 26 Apr 2012 07:46:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335426372!6434291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16384 invoked from network); 26 Apr 2012 07:46:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12147111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:46:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:46:11 +0100
Message-ID: <1335426370.4881.63.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Thu, 26 Apr 2012 08:46:10 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A10D8104B9@FTLPMAILBOX02.citrite.net>
References: <1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
	<20120425204741.GH51354@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D8104B9@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 22:05 +0100, Ross Philipson wrote:
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: Wednesday, April 25, 2012 4:48 PM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > Hi,
> > 
> > At 14:47 -0400 on 25 Apr (1335365226), Ross Philipson wrote:
> > > Is it OK if I introduce a shared header in xen/include/public/hvm to
> > > collect all the BIOS/FW related xenstore values in one place?
> > > Something like hvm_fw_defs.h?
> > 
> > If at all possible, can you put that header somewhere under tools/ ?
> > AIUI it doesn't describe a hypervisor interface.
> > 
> > Tim.
> 
> Yea I can do that.

There isn't an existing good place which is shared between hvmloader and
libxc/libxl (other than public). Perhaps add a new subdir under
tools/include? xen-internal perhaps? xen-tools?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 07:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 07:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNJP5-00008Y-Hg; Thu, 26 Apr 2012 07:46:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNJP3-00008S-KH
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 07:46:13 +0000
Received: from [193.109.254.147:27189] by server-6.bemta-14.messagelabs.com id
	40/1C-02047-44DF89F4; Thu, 26 Apr 2012 07:46:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335426372!6434291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16384 invoked from network); 26 Apr 2012 07:46:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 07:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12147111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:46:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:46:11 +0100
Message-ID: <1335426370.4881.63.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Thu, 26 Apr 2012 08:46:10 +0100
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A10D8104B9@FTLPMAILBOX02.citrite.net>
References: <1333620502.937.60.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE543E@FTLPMAILBOX02.citrite.net>
	<1334067702.5394.18.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE5864@FTLPMAILBOX02.citrite.net>
	<1334072343.5394.58.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FCE58CF@FTLPMAILBOX02.citrite.net>
	<1334133870.5394.70.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724FEBD913@FTLPMAILBOX02.citrite.net>
	<1334309880.14560.14.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D810447@FTLPMAILBOX02.citrite.net>
	<20120425204741.GH51354@ocelot.phlegethon.org>
	<831D55AF5A11D64C9B4B43F59EEBF720A10D8104B9@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 22:05 +0100, Ross Philipson wrote:
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: Wednesday, April 25, 2012 4:48 PM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > Hi,
> > 
> > At 14:47 -0400 on 25 Apr (1335365226), Ross Philipson wrote:
> > > Is it OK if I introduce a shared header in xen/include/public/hvm to
> > > collect all the BIOS/FW related xenstore values in one place?
> > > Something like hvm_fw_defs.h?
> > 
> > If at all possible, can you put that header somewhere under tools/ ?
> > AIUI it doesn't describe a hypervisor interface.
> > 
> > Tim.
> 
> Yea I can do that.

There isn't an existing good place which is shared between hvmloader and
libxc/libxl (other than public). Perhaps add a new subdir under
tools/include? xen-internal perhaps? xen-tools?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKEw-0000tA-UW; Thu, 26 Apr 2012 08:39:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNKEw-0000t5-1U
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:39:50 +0000
Received: from [193.109.254.147:24867] by server-12.bemta-14.messagelabs.com
	id 2E/F2-05898-5D9099F4; Thu, 26 Apr 2012 08:39:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335429588!725032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1924 invoked from network); 26 Apr 2012 08:39:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 08:39:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12148696"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:39:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 09:39:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNKEu-0005Z3-11;
	Thu, 26 Apr 2012 08:39:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNKEt-0001fe-Uk;
	Thu, 26 Apr 2012 09:39:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12755-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 09:39:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12755: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12755 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12755/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12754

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a4e7fce6ee2b
baseline version:
 xen                  a4e7fce6ee2b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKEw-0000tA-UW; Thu, 26 Apr 2012 08:39:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNKEw-0000t5-1U
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:39:50 +0000
Received: from [193.109.254.147:24867] by server-12.bemta-14.messagelabs.com
	id 2E/F2-05898-5D9099F4; Thu, 26 Apr 2012 08:39:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335429588!725032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1924 invoked from network); 26 Apr 2012 08:39:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 08:39:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12148696"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:39:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 09:39:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNKEu-0005Z3-11;
	Thu, 26 Apr 2012 08:39:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNKEt-0001fe-Uk;
	Thu, 26 Apr 2012 09:39:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12755-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 09:39:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12755: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12755 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12755/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12754

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a4e7fce6ee2b
baseline version:
 xen                  a4e7fce6ee2b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:50:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKOq-0001HJ-Pk; Thu, 26 Apr 2012 08:50:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNKOo-0001HB-Rx
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:50:03 +0000
Received: from [85.158.139.83:9496] by server-3.bemta-5.messagelabs.com id
	72/54-25237-93C099F4; Thu, 26 Apr 2012 08:50:01 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335430197!25610404!1
X-Originating-IP: [205.139.110.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjEzOS4xMTAuMzcgPT4gNTgzNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21381 invoked from network); 26 Apr 2012 08:49:58 -0000
Received: from service56-us.mimecast.com (HELO service56-us.mimecast.com)
	(205.139.110.37)
	by server-5.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 08:49:58 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service56-us.mimecast.com; Thu, 26 Apr
	2012 04:49:53 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 03:49:48 -0500
Received: from [10.67.7.194] (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 14:19:45 +0530
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335425950.4881.59.camel@dagon.hellion.org.uk>
References: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
	<1335425950.4881.59.camel@dagon.hellion.org.uk>
Organization: Sierra Atlantic
Date: Thu, 26 Apr 2012 16:50:02 +0800
Message-ID: <1335430202.4742.11.camel@goosenl-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042604495300602
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Xuesen.Guo@hitachiconsulting.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5414332124988364012=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5414332124988364012==
Content-Type: multipart/alternative; boundary="=-SPx70R9x5q3+niTb9dOF"

--=-SPx70R9x5q3+niTb9dOF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Many thanks for your comments.
I will resend the patch according to your suggestions.

--Xuesen


On Thu, 2012-04-26 at 08:39 +0100, Ian Campbell wrote:

> On Thu, 2012-04-26 at 04:00 +0100, Xuesen Guo wrote:
> > Add the check of bzImage kernel and make it work
> > with RHEL 6 bzipped kernels
> >=20
> > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> >=20
> > diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
> > --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
> > +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 10:57:09 2012 +0800
> > @@ -18,6 +18,48 @@
> > =20
> >  static xc_interface *xch;
> > =20
> > +/* According to the implemation of xc_dom_probe_bzimage_kernel() funct=
ion */
> > +/* We add support of bzImage kernel */
> > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > +struct setup_header {
> > +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > +=09uint8_t  setup_sects;
> > +=09uint16_t root_flags;
> > +=09uint32_t syssize;
> > +=09uint16_t ram_size;
> > +=09uint16_t vid_mode;
> > +=09uint16_t root_dev;
> > +=09uint16_t boot_flag;
> > +=09uint16_t jump;
> > +=09uint32_t header;
> > +#define HDR_MAGIC  "HdrS"
> > +#define HDR_MAGIC_SZ 4
> > +=09uint16_t version;
> > +#define VERSION(h,l) (((h)<<8) | (l))
> > +=09uint32_t realmode_swtch;
> > +=09uint16_t start_sys;
> > +=09uint16_t kernel_version;
> > +=09uint8_t  type_of_loader;
> > +=09uint8_t  loadflags;
> > +=09uint16_t setup_move_size;
> > +=09uint32_t code32_start;
> > +=09uint32_t ramdisk_image;
> > +=09uint32_t ramdisk_size;
> > +=09uint32_t bootsect_kludge;
> > +=09uint16_t heap_end_ptr;
> > +=09uint16_t _pad1;
> > +=09uint32_t cmd_line_ptr;
> > +=09uint32_t initrd_addr_max;
> > +=09uint32_t kernel_alignment;
> > +=09uint8_t  relocatable_kernel;
> > +=09uint8_t  _pad2[3];
> > +=09uint32_t cmdline_size;
> > +=09uint32_t hardware_subarch;
> > +=09uint64_t hardware_subarch_data;
> > +=09uint32_t payload_offset;
> > +=09uint32_t payload_length;
> > +} __attribute__((packed));
> > +
> >  static void print_string_note(const char *prefix, struct elf_binary *e=
lf,
> >  =09=09=09      const elf_note *note)
> >  {
> > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> >  =09const elf_shdr *shdr;
> >  =09int notes_found =3D 0;
> > =20
> > +=09struct setup_header *hdr;
> > +=09uint64_t payload_offset, payload_length;
> > +
> >  =09if (argc !=3D 2)
> >  =09{
> >  =09=09fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > @@ -159,6 +204,27 @@ int main(int argc, char **argv)
> >  =09=09fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> >  =09=09return 1;
> >  =09}
> > +=09
> > +=09/* Check the magic of bzImage kernel */
> > +=09hdr =3D (struct setup_header *)image;
> > +=09if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=3D 0 )
> > +=09{
> > +=09=09if ( hdr->version < VERSION(2,8) )
> > +=09=09{
> > +=09=09=09printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr-=
>version);
> > +=09=09=09return 1;
> > +=09=09}
> > +
> > +=09=09/* upcast to 64 bits to avoid overflow */
> > +=09=09/* setup_sects is u8 and so cannot overflow */
> > +=09=09payload_offset =3D (hdr->setup_sects + 1) * 512;
> > +=09=09payload_offset +=3D hdr->payload_offset;
> > +=09=09payload_length =3D hdr->payload_length;
>=20
> Up to this point this is all the same as xc_dom_probe_bzimage_kernel and
> therefore looks to me to be safe and correct.
>=20
> However xc_dom_probe_bzimage_kernel has some additional checks before it
> trusts the offset and length. Specifically it compares them against the
> size of the on disk kernel image:
>     if ( payload_offset >=3D dom->kernel_size )
>     {
>         xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload offset ove=
rflow",
>                      __FUNCTION__);
>         return -EINVAL;
>     }
>     if ( (payload_offset + payload_length) > dom->kernel_size )
>     {
>         xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload length ove=
rflow",
>                      __FUNCTION__);
>         return -EINVAL;
>     }
>=20
> I think you likely want to retain some similar check here, using
> st.st_size as the boundary instead of dom->kernel_size.
>=20
> > +
> > +=09=09image =3D image + payload_offset;
> > +=09=09st.st_size =3D payload_length;
> > +=09}
> > +=09
> >  =09size =3D st.st_size;
>=20
> The usage of size vs st.st_size in the existing code is not very
> obvious, IMHO it would be preferable to consistently always use size
> from this point on, since changing st.st_size has the possibility of
> surprise. IOW the tail here would be:
>=20
> =09=09image =3D image + payload_offset;
> =09=09size =3D payload_length
> =09} else {
> =09=09size =3D st.st_size;
>  =09}
>=20
> and then use size and not st.st_size for the remainder of the function.
>=20
> Ian.
>=20
> >  =09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
> >=20
> > This e-mail is intended solely for the person or entity to which it is =
addressed
> > and may contain confidential and/or privileged information. Any review,=
 dissemination,
> > copying, printing or other use of this e-mail by persons or entities ot=
her than the=20
> > addressee is prohibited. If you have received this e-mail in error, ple=
ase contact
> > the sender immediately and delete the material from any computer.
> > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com=20
> > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> >=20
> >=20
> >=20
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>=20
>=20
>=20


--=-SPx70R9x5q3+niTb9dOF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.32.2">
</HEAD>
<BODY>
Many thanks for your comments.<BR>
I will resend the patch according to your suggestions.<BR>
<BR>
--Xuesen<BR>
<BR>
<BR>
On Thu, 2012-04-26 at 08:39 +0100, Ian Campbell wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
On Thu, 2012-04-26 at 04:00 +0100, Xuesen Guo wrote:
&gt; Add the check of bzImage kernel and make it work
&gt; with RHEL 6 bzipped kernels
&gt;=20
&gt; Signed-off-by: Xuesen Guo &lt;<A HREF=3D"mailto:Xuesen.Guo@hitachicons=
ulting.com">Xuesen.Guo@hitachiconsulting.com</A>&gt;
&gt;=20
&gt; diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
&gt; --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
&gt; +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 10:57:09 2012 +0800
&gt; @@ -18,6 +18,48 @@
&gt; =20
&gt;  static xc_interface *xch;
&gt; =20
&gt; +/* According to the implemation of xc_dom_probe_bzimage_kernel() func=
tion */
&gt; +/* We add support of bzImage kernel */
&gt; +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
&gt; +struct setup_header {
&gt; +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
&gt; +=09uint8_t  setup_sects;
&gt; +=09uint16_t root_flags;
&gt; +=09uint32_t syssize;
&gt; +=09uint16_t ram_size;
&gt; +=09uint16_t vid_mode;
&gt; +=09uint16_t root_dev;
&gt; +=09uint16_t boot_flag;
&gt; +=09uint16_t jump;
&gt; +=09uint32_t header;
&gt; +#define HDR_MAGIC  &quot;HdrS&quot;
&gt; +#define HDR_MAGIC_SZ 4
&gt; +=09uint16_t version;
&gt; +#define VERSION(h,l) (((h)&lt;&lt;8) | (l))
&gt; +=09uint32_t realmode_swtch;
&gt; +=09uint16_t start_sys;
&gt; +=09uint16_t kernel_version;
&gt; +=09uint8_t  type_of_loader;
&gt; +=09uint8_t  loadflags;
&gt; +=09uint16_t setup_move_size;
&gt; +=09uint32_t code32_start;
&gt; +=09uint32_t ramdisk_image;
&gt; +=09uint32_t ramdisk_size;
&gt; +=09uint32_t bootsect_kludge;
&gt; +=09uint16_t heap_end_ptr;
&gt; +=09uint16_t _pad1;
&gt; +=09uint32_t cmd_line_ptr;
&gt; +=09uint32_t initrd_addr_max;
&gt; +=09uint32_t kernel_alignment;
&gt; +=09uint8_t  relocatable_kernel;
&gt; +=09uint8_t  _pad2[3];
&gt; +=09uint32_t cmdline_size;
&gt; +=09uint32_t hardware_subarch;
&gt; +=09uint64_t hardware_subarch_data;
&gt; +=09uint32_t payload_offset;
&gt; +=09uint32_t payload_length;
&gt; +} __attribute__((packed));
&gt; +
&gt;  static void print_string_note(const char *prefix, struct elf_binary *=
elf,
&gt;  =09=09=09      const elf_note *note)
&gt;  {
&gt; @@ -131,6 +173,9 @@ int main(int argc, char **argv)
&gt;  =09const elf_shdr *shdr;
&gt;  =09int notes_found =3D 0;
&gt; =20
&gt; +=09struct setup_header *hdr;
&gt; +=09uint64_t payload_offset, payload_length;
&gt; +
&gt;  =09if (argc !=3D 2)
&gt;  =09{
&gt;  =09=09fprintf(stderr, &quot;Usage: readnotes &lt;elfimage&gt;\n&quot;=
);
&gt; @@ -159,6 +204,27 @@ int main(int argc, char **argv)
&gt;  =09=09fprintf(stderr, &quot;Unable to map %s: %s\n&quot;, f, strerror=
(errno));
&gt;  =09=09return 1;
&gt;  =09}
&gt; +=09
&gt; +=09/* Check the magic of bzImage kernel */
&gt; +=09hdr =3D (struct setup_header *)image;
&gt; +=09if ( memcmp(&amp;hdr-&gt;header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=3D 0=
 )
&gt; +=09{
&gt; +=09=09if ( hdr-&gt;version &lt; VERSION(2,8) )
&gt; +=09=09{
&gt; +=09=09=09printf(&quot;%s: boot protocol too old (%04x)&quot;, __FUNCT=
ION__, hdr-&gt;version);
&gt; +=09=09=09return 1;
&gt; +=09=09}
&gt; +
&gt; +=09=09/* upcast to 64 bits to avoid overflow */
&gt; +=09=09/* setup_sects is u8 and so cannot overflow */
&gt; +=09=09payload_offset =3D (hdr-&gt;setup_sects + 1) * 512;
&gt; +=09=09payload_offset +=3D hdr-&gt;payload_offset;
&gt; +=09=09payload_length =3D hdr-&gt;payload_length;

Up to this point this is all the same as xc_dom_probe_bzimage_kernel and
therefore looks to me to be safe and correct.

However xc_dom_probe_bzimage_kernel has some additional checks before it
trusts the offset and length. Specifically it compares them against the
size of the on disk kernel image:
    if ( payload_offset &gt;=3D dom-&gt;kernel_size )
    {
        xc_dom_panic(dom-&gt;xch, XC_INVALID_KERNEL, &quot;%s: payload offs=
et overflow&quot;,
                     __FUNCTION__);
        return -EINVAL;
    }
    if ( (payload_offset + payload_length) &gt; dom-&gt;kernel_size )
    {
        xc_dom_panic(dom-&gt;xch, XC_INVALID_KERNEL, &quot;%s: payload leng=
th overflow&quot;,
                     __FUNCTION__);
        return -EINVAL;
    }

I think you likely want to retain some similar check here, using
st.st_size as the boundary instead of dom-&gt;kernel_size.

&gt; +
&gt; +=09=09image =3D image + payload_offset;
&gt; +=09=09st.st_size =3D payload_length;
&gt; +=09}
&gt; +=09
&gt;  =09size =3D st.st_size;

The usage of size vs st.st_size in the existing code is not very
obvious, IMHO it would be preferable to consistently always use size
from this point on, since changing st.st_size has the possibility of
surprise. IOW the tail here would be:

=09=09image =3D image + payload_offset;
=09=09size =3D payload_length
=09} else {
=09=09size =3D st.st_size;
 =09}

and then use size and not st.st_size for the remainder of the function.

Ian.

&gt;  =09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
&gt;=20
&gt; This e-mail is intended solely for the person or entity to which it is=
 addressed
&gt; and may contain confidential and/or privileged information. Any review=
, dissemination,
&gt; copying, printing or other use of this e-mail by persons or entities o=
ther than the=20
&gt; addressee is prohibited. If you have received this e-mail in error, pl=
ease contact
&gt; the sender immediately and delete the material from any computer.
&gt; To unsubscribe send an email to: <A HREF=3D"mailto:Unsubscribe@hitachi=
consulting.com">Unsubscribe@hitachiconsulting.com</A>=20
&gt; Hitachi Consulting (China) Co., Ltd. (HCCD0411)
&gt;=20
&gt;=20
&gt;=20
&gt; _______________________________________________
&gt; Xen-devel mailing list
&gt; <A HREF=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</A>
&gt; <A HREF=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</A>



</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>
--=-SPx70R9x5q3+niTb9dOF--



--===============5414332124988364012==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5414332124988364012==--



From xen-devel-bounces@lists.xen.org Thu Apr 26 08:50:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKOq-0001HJ-Pk; Thu, 26 Apr 2012 08:50:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNKOo-0001HB-Rx
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:50:03 +0000
Received: from [85.158.139.83:9496] by server-3.bemta-5.messagelabs.com id
	72/54-25237-93C099F4; Thu, 26 Apr 2012 08:50:01 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335430197!25610404!1
X-Originating-IP: [205.139.110.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjEzOS4xMTAuMzcgPT4gNTgzNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21381 invoked from network); 26 Apr 2012 08:49:58 -0000
Received: from service56-us.mimecast.com (HELO service56-us.mimecast.com)
	(205.139.110.37)
	by server-5.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 08:49:58 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service56-us.mimecast.com; Thu, 26 Apr
	2012 04:49:53 -0400
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 03:49:48 -0500
Received: from [10.67.7.194] (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 14:19:45 +0530
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335425950.4881.59.camel@dagon.hellion.org.uk>
References: <ec8e99606fbea7eb2ed2.1335409231@localhost6.localdomain6>
	<1335425950.4881.59.camel@dagon.hellion.org.uk>
Organization: Sierra Atlantic
Date: Thu, 26 Apr 2012 16:50:02 +0800
Message-ID: <1335430202.4742.11.camel@goosenl-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042604495300602
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Xuesen.Guo@hitachiconsulting.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5414332124988364012=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5414332124988364012==
Content-Type: multipart/alternative; boundary="=-SPx70R9x5q3+niTb9dOF"

--=-SPx70R9x5q3+niTb9dOF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Many thanks for your comments.
I will resend the patch according to your suggestions.

--Xuesen


On Thu, 2012-04-26 at 08:39 +0100, Ian Campbell wrote:

> On Thu, 2012-04-26 at 04:00 +0100, Xuesen Guo wrote:
> > Add the check of bzImage kernel and make it work
> > with RHEL 6 bzipped kernels
> >=20
> > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> >=20
> > diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
> > --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
> > +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 10:57:09 2012 +0800
> > @@ -18,6 +18,48 @@
> > =20
> >  static xc_interface *xch;
> > =20
> > +/* According to the implemation of xc_dom_probe_bzimage_kernel() funct=
ion */
> > +/* We add support of bzImage kernel */
> > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > +struct setup_header {
> > +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > +=09uint8_t  setup_sects;
> > +=09uint16_t root_flags;
> > +=09uint32_t syssize;
> > +=09uint16_t ram_size;
> > +=09uint16_t vid_mode;
> > +=09uint16_t root_dev;
> > +=09uint16_t boot_flag;
> > +=09uint16_t jump;
> > +=09uint32_t header;
> > +#define HDR_MAGIC  "HdrS"
> > +#define HDR_MAGIC_SZ 4
> > +=09uint16_t version;
> > +#define VERSION(h,l) (((h)<<8) | (l))
> > +=09uint32_t realmode_swtch;
> > +=09uint16_t start_sys;
> > +=09uint16_t kernel_version;
> > +=09uint8_t  type_of_loader;
> > +=09uint8_t  loadflags;
> > +=09uint16_t setup_move_size;
> > +=09uint32_t code32_start;
> > +=09uint32_t ramdisk_image;
> > +=09uint32_t ramdisk_size;
> > +=09uint32_t bootsect_kludge;
> > +=09uint16_t heap_end_ptr;
> > +=09uint16_t _pad1;
> > +=09uint32_t cmd_line_ptr;
> > +=09uint32_t initrd_addr_max;
> > +=09uint32_t kernel_alignment;
> > +=09uint8_t  relocatable_kernel;
> > +=09uint8_t  _pad2[3];
> > +=09uint32_t cmdline_size;
> > +=09uint32_t hardware_subarch;
> > +=09uint64_t hardware_subarch_data;
> > +=09uint32_t payload_offset;
> > +=09uint32_t payload_length;
> > +} __attribute__((packed));
> > +
> >  static void print_string_note(const char *prefix, struct elf_binary *e=
lf,
> >  =09=09=09      const elf_note *note)
> >  {
> > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> >  =09const elf_shdr *shdr;
> >  =09int notes_found =3D 0;
> > =20
> > +=09struct setup_header *hdr;
> > +=09uint64_t payload_offset, payload_length;
> > +
> >  =09if (argc !=3D 2)
> >  =09{
> >  =09=09fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > @@ -159,6 +204,27 @@ int main(int argc, char **argv)
> >  =09=09fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> >  =09=09return 1;
> >  =09}
> > +=09
> > +=09/* Check the magic of bzImage kernel */
> > +=09hdr =3D (struct setup_header *)image;
> > +=09if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=3D 0 )
> > +=09{
> > +=09=09if ( hdr->version < VERSION(2,8) )
> > +=09=09{
> > +=09=09=09printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr-=
>version);
> > +=09=09=09return 1;
> > +=09=09}
> > +
> > +=09=09/* upcast to 64 bits to avoid overflow */
> > +=09=09/* setup_sects is u8 and so cannot overflow */
> > +=09=09payload_offset =3D (hdr->setup_sects + 1) * 512;
> > +=09=09payload_offset +=3D hdr->payload_offset;
> > +=09=09payload_length =3D hdr->payload_length;
>=20
> Up to this point this is all the same as xc_dom_probe_bzimage_kernel and
> therefore looks to me to be safe and correct.
>=20
> However xc_dom_probe_bzimage_kernel has some additional checks before it
> trusts the offset and length. Specifically it compares them against the
> size of the on disk kernel image:
>     if ( payload_offset >=3D dom->kernel_size )
>     {
>         xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload offset ove=
rflow",
>                      __FUNCTION__);
>         return -EINVAL;
>     }
>     if ( (payload_offset + payload_length) > dom->kernel_size )
>     {
>         xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: payload length ove=
rflow",
>                      __FUNCTION__);
>         return -EINVAL;
>     }
>=20
> I think you likely want to retain some similar check here, using
> st.st_size as the boundary instead of dom->kernel_size.
>=20
> > +
> > +=09=09image =3D image + payload_offset;
> > +=09=09st.st_size =3D payload_length;
> > +=09}
> > +=09
> >  =09size =3D st.st_size;
>=20
> The usage of size vs st.st_size in the existing code is not very
> obvious, IMHO it would be preferable to consistently always use size
> from this point on, since changing st.st_size has the possibility of
> surprise. IOW the tail here would be:
>=20
> =09=09image =3D image + payload_offset;
> =09=09size =3D payload_length
> =09} else {
> =09=09size =3D st.st_size;
>  =09}
>=20
> and then use size and not st.st_size for the remainder of the function.
>=20
> Ian.
>=20
> >  =09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
> >=20
> > This e-mail is intended solely for the person or entity to which it is =
addressed
> > and may contain confidential and/or privileged information. Any review,=
 dissemination,
> > copying, printing or other use of this e-mail by persons or entities ot=
her than the=20
> > addressee is prohibited. If you have received this e-mail in error, ple=
ase contact
> > the sender immediately and delete the material from any computer.
> > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com=20
> > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> >=20
> >=20
> >=20
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>=20
>=20
>=20


--=-SPx70R9x5q3+niTb9dOF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.32.2">
</HEAD>
<BODY>
Many thanks for your comments.<BR>
I will resend the patch according to your suggestions.<BR>
<BR>
--Xuesen<BR>
<BR>
<BR>
On Thu, 2012-04-26 at 08:39 +0100, Ian Campbell wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
On Thu, 2012-04-26 at 04:00 +0100, Xuesen Guo wrote:
&gt; Add the check of bzImage kernel and make it work
&gt; with RHEL 6 bzipped kernels
&gt;=20
&gt; Signed-off-by: Xuesen Guo &lt;<A HREF=3D"mailto:Xuesen.Guo@hitachicons=
ulting.com">Xuesen.Guo@hitachiconsulting.com</A>&gt;
&gt;=20
&gt; diff -r d690c7e896a2 -r ec8e99606fbe tools/xcutils/readnotes.c
&gt; --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
&gt; +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 10:57:09 2012 +0800
&gt; @@ -18,6 +18,48 @@
&gt; =20
&gt;  static xc_interface *xch;
&gt; =20
&gt; +/* According to the implemation of xc_dom_probe_bzimage_kernel() func=
tion */
&gt; +/* We add support of bzImage kernel */
&gt; +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
&gt; +struct setup_header {
&gt; +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
&gt; +=09uint8_t  setup_sects;
&gt; +=09uint16_t root_flags;
&gt; +=09uint32_t syssize;
&gt; +=09uint16_t ram_size;
&gt; +=09uint16_t vid_mode;
&gt; +=09uint16_t root_dev;
&gt; +=09uint16_t boot_flag;
&gt; +=09uint16_t jump;
&gt; +=09uint32_t header;
&gt; +#define HDR_MAGIC  &quot;HdrS&quot;
&gt; +#define HDR_MAGIC_SZ 4
&gt; +=09uint16_t version;
&gt; +#define VERSION(h,l) (((h)&lt;&lt;8) | (l))
&gt; +=09uint32_t realmode_swtch;
&gt; +=09uint16_t start_sys;
&gt; +=09uint16_t kernel_version;
&gt; +=09uint8_t  type_of_loader;
&gt; +=09uint8_t  loadflags;
&gt; +=09uint16_t setup_move_size;
&gt; +=09uint32_t code32_start;
&gt; +=09uint32_t ramdisk_image;
&gt; +=09uint32_t ramdisk_size;
&gt; +=09uint32_t bootsect_kludge;
&gt; +=09uint16_t heap_end_ptr;
&gt; +=09uint16_t _pad1;
&gt; +=09uint32_t cmd_line_ptr;
&gt; +=09uint32_t initrd_addr_max;
&gt; +=09uint32_t kernel_alignment;
&gt; +=09uint8_t  relocatable_kernel;
&gt; +=09uint8_t  _pad2[3];
&gt; +=09uint32_t cmdline_size;
&gt; +=09uint32_t hardware_subarch;
&gt; +=09uint64_t hardware_subarch_data;
&gt; +=09uint32_t payload_offset;
&gt; +=09uint32_t payload_length;
&gt; +} __attribute__((packed));
&gt; +
&gt;  static void print_string_note(const char *prefix, struct elf_binary *=
elf,
&gt;  =09=09=09      const elf_note *note)
&gt;  {
&gt; @@ -131,6 +173,9 @@ int main(int argc, char **argv)
&gt;  =09const elf_shdr *shdr;
&gt;  =09int notes_found =3D 0;
&gt; =20
&gt; +=09struct setup_header *hdr;
&gt; +=09uint64_t payload_offset, payload_length;
&gt; +
&gt;  =09if (argc !=3D 2)
&gt;  =09{
&gt;  =09=09fprintf(stderr, &quot;Usage: readnotes &lt;elfimage&gt;\n&quot;=
);
&gt; @@ -159,6 +204,27 @@ int main(int argc, char **argv)
&gt;  =09=09fprintf(stderr, &quot;Unable to map %s: %s\n&quot;, f, strerror=
(errno));
&gt;  =09=09return 1;
&gt;  =09}
&gt; +=09
&gt; +=09/* Check the magic of bzImage kernel */
&gt; +=09hdr =3D (struct setup_header *)image;
&gt; +=09if ( memcmp(&amp;hdr-&gt;header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=3D 0=
 )
&gt; +=09{
&gt; +=09=09if ( hdr-&gt;version &lt; VERSION(2,8) )
&gt; +=09=09{
&gt; +=09=09=09printf(&quot;%s: boot protocol too old (%04x)&quot;, __FUNCT=
ION__, hdr-&gt;version);
&gt; +=09=09=09return 1;
&gt; +=09=09}
&gt; +
&gt; +=09=09/* upcast to 64 bits to avoid overflow */
&gt; +=09=09/* setup_sects is u8 and so cannot overflow */
&gt; +=09=09payload_offset =3D (hdr-&gt;setup_sects + 1) * 512;
&gt; +=09=09payload_offset +=3D hdr-&gt;payload_offset;
&gt; +=09=09payload_length =3D hdr-&gt;payload_length;

Up to this point this is all the same as xc_dom_probe_bzimage_kernel and
therefore looks to me to be safe and correct.

However xc_dom_probe_bzimage_kernel has some additional checks before it
trusts the offset and length. Specifically it compares them against the
size of the on disk kernel image:
    if ( payload_offset &gt;=3D dom-&gt;kernel_size )
    {
        xc_dom_panic(dom-&gt;xch, XC_INVALID_KERNEL, &quot;%s: payload offs=
et overflow&quot;,
                     __FUNCTION__);
        return -EINVAL;
    }
    if ( (payload_offset + payload_length) &gt; dom-&gt;kernel_size )
    {
        xc_dom_panic(dom-&gt;xch, XC_INVALID_KERNEL, &quot;%s: payload leng=
th overflow&quot;,
                     __FUNCTION__);
        return -EINVAL;
    }

I think you likely want to retain some similar check here, using
st.st_size as the boundary instead of dom-&gt;kernel_size.

&gt; +
&gt; +=09=09image =3D image + payload_offset;
&gt; +=09=09st.st_size =3D payload_length;
&gt; +=09}
&gt; +=09
&gt;  =09size =3D st.st_size;

The usage of size vs st.st_size in the existing code is not very
obvious, IMHO it would be preferable to consistently always use size
from this point on, since changing st.st_size has the possibility of
surprise. IOW the tail here would be:

=09=09image =3D image + payload_offset;
=09=09size =3D payload_length
=09} else {
=09=09size =3D st.st_size;
 =09}

and then use size and not st.st_size for the remainder of the function.

Ian.

&gt;  =09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
&gt;=20
&gt; This e-mail is intended solely for the person or entity to which it is=
 addressed
&gt; and may contain confidential and/or privileged information. Any review=
, dissemination,
&gt; copying, printing or other use of this e-mail by persons or entities o=
ther than the=20
&gt; addressee is prohibited. If you have received this e-mail in error, pl=
ease contact
&gt; the sender immediately and delete the material from any computer.
&gt; To unsubscribe send an email to: <A HREF=3D"mailto:Unsubscribe@hitachi=
consulting.com">Unsubscribe@hitachiconsulting.com</A>=20
&gt; Hitachi Consulting (China) Co., Ltd. (HCCD0411)
&gt;=20
&gt;=20
&gt;=20
&gt; _______________________________________________
&gt; Xen-devel mailing list
&gt; <A HREF=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</A>
&gt; <A HREF=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</A>



</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>
--=-SPx70R9x5q3+niTb9dOF--



--===============5414332124988364012==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5414332124988364012==--



From xen-devel-bounces@lists.xen.org Thu Apr 26 08:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKPD-0001IQ-6Y; Thu, 26 Apr 2012 08:50:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SNKPB-0001IH-9w
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:50:25 +0000
Received: from [85.158.143.99:60787] by server-1.bemta-4.messagelabs.com id
	E8/62-20925-05C099F4; Thu, 26 Apr 2012 08:50:24 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335430193!20072863!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzcwMjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7391 invoked from network); 26 Apr 2012 08:50:18 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 08:50:18 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 26 Apr 2012 08:08:22 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 26 Apr 2012 08:07:29 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3Q84ldA1888268
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 18:04:47 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3Q8BVUH018315
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 18:11:32 +1000
Received: from [9.124.35.157] ([9.124.35.157])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3Q8BRrb018175; Thu, 26 Apr 2012 18:11:27 +1000
Message-ID: <4F990321.60208@linux.vnet.ibm.com>
Date: Thu, 26 Apr 2012 13:41:13 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
In-Reply-To: <20120424095923.GS15413@redhat.com>
x-cbid: 12042522-7014-0000-0000-000000FBC8B4
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
[...]
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 42b7393..edf56d4 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>>   		prepare_to_wait(&vcpu->wq,&wait, TASK_INTERRUPTIBLE);
>>
>>   		if (kvm_arch_vcpu_runnable(vcpu)) {
>> +			/*
>> +			 * This is the only safe place to reset unhalt flag.
>> +			 * otherwise it results in loosing the notification
>> +			 * which eventually can result in vcpu hangs.
>> +			 */
> Why this is the only safe place? Why clearing it in kvm/x86.c just after
> call to kvm_vcpu_block() if KVM_REQ_UNHALT is set is not safe enough?
>

Yes, You are Right. The acceptable window to reset the flag can be
extended till there. and Good point about that is it removes the need
for having the stubs for other archs and simplifies everything a lot. 
Thanks for that.

[ When I was experimenting with request bit, clearing request bit in the 
same place was causing vm hang after some 16 iteration of stress test. I 
had carried the same impression. Now I have done stress testing
to ensure that the change works.  Basically as you know, my fear was 
loosing kick(s) leads to vm hang eventually. ]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKPD-0001IQ-6Y; Thu, 26 Apr 2012 08:50:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SNKPB-0001IH-9w
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:50:25 +0000
Received: from [85.158.143.99:60787] by server-1.bemta-4.messagelabs.com id
	E8/62-20925-05C099F4; Thu, 26 Apr 2012 08:50:24 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335430193!20072863!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzcwMjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7391 invoked from network); 26 Apr 2012 08:50:18 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 08:50:18 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 26 Apr 2012 08:08:22 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 26 Apr 2012 08:07:29 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3Q84ldA1888268
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 18:04:47 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3Q8BVUH018315
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 18:11:32 +1000
Received: from [9.124.35.157] ([9.124.35.157])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3Q8BRrb018175; Thu, 26 Apr 2012 18:11:27 +1000
Message-ID: <4F990321.60208@linux.vnet.ibm.com>
Date: Thu, 26 Apr 2012 13:41:13 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
In-Reply-To: <20120424095923.GS15413@redhat.com>
x-cbid: 12042522-7014-0000-0000-000000FBC8B4
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
[...]
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 42b7393..edf56d4 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>>   		prepare_to_wait(&vcpu->wq,&wait, TASK_INTERRUPTIBLE);
>>
>>   		if (kvm_arch_vcpu_runnable(vcpu)) {
>> +			/*
>> +			 * This is the only safe place to reset unhalt flag.
>> +			 * otherwise it results in loosing the notification
>> +			 * which eventually can result in vcpu hangs.
>> +			 */
> Why this is the only safe place? Why clearing it in kvm/x86.c just after
> call to kvm_vcpu_block() if KVM_REQ_UNHALT is set is not safe enough?
>

Yes, You are Right. The acceptable window to reset the flag can be
extended till there. and Good point about that is it removes the need
for having the stubs for other archs and simplifies everything a lot. 
Thanks for that.

[ When I was experimenting with request bit, clearing request bit in the 
same place was causing vm hang after some 16 iteration of stress test. I 
had carried the same impression. Now I have done stress testing
to ensure that the change works.  Basically as you know, my fear was 
loosing kick(s) leads to vm hang eventually. ]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKSt-0001Yt-W9; Thu, 26 Apr 2012 08:54:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNKSt-0001Yi-7h
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:54:15 +0000
Received: from [85.158.143.35:7534] by server-1.bemta-4.messagelabs.com id
	51/A8-20925-63D099F4; Thu, 26 Apr 2012 08:54:14 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335430446!13557343!1
X-Originating-IP: [205.139.110.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjEzOS4xMTAuMzcgPT4gNjUwOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7461 invoked from network); 26 Apr 2012 08:54:07 -0000
Received: from service56-us.mimecast.com (HELO service56-us.mimecast.com)
	(205.139.110.37)
	by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 08:54:07 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service56-us.mimecast.com; Thu, 26 Apr
	2012 04:54:02 -0400
Received: from HCAZUSCH2.hitachiconsulting.net (172.16.1.120) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 03:53:58 -0500
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 03:53:57 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 14:23:51 +0530
MIME-Version: 1.0
X-Mercurial-Node: 27a6422ac06df8bef75dcef2bc0f617ed9a4e104
Message-ID: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Apr 2012 16:54:09 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042604540300102
Cc: xuesen.guo@hitachiconsulting.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>

---
Changed since v1:
  * add additional checks of the offset and length
  * not changing st.st_size, use size instead of st.st_size

diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,13 +204,45 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
-	size = st.st_size;
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return 1;
+		}
 
-	usize = xc_dom_check_gzip(xch, image, st.st_size);
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+		
+		if ( payload_offset >= st.st_size )
+		{
+			printf("%s: payload offset overflow", __FUNCTION__);
+			return 1;
+		}
+		if ( (payload_offset + payload_length) > st.st_size )
+		{
+			printf("%s: payload length overflow", __FUNCTION__);
+			return 1;
+		}
+
+		image = image + payload_offset;
+		size = payload_length;
+	} else {
+		size = st.st_size;
+	}
+
+	usize = xc_dom_check_gzip(xch, image, size);
 	if (usize)
 	{
 		tmp = malloc(usize);
-		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
+		xc_dom_do_gunzip(xch, image, size, tmp, usize);
 		image = tmp;
 		size = usize;
 	}

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKSt-0001Yt-W9; Thu, 26 Apr 2012 08:54:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNKSt-0001Yi-7h
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:54:15 +0000
Received: from [85.158.143.35:7534] by server-1.bemta-4.messagelabs.com id
	51/A8-20925-63D099F4; Thu, 26 Apr 2012 08:54:14 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335430446!13557343!1
X-Originating-IP: [205.139.110.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjEzOS4xMTAuMzcgPT4gNjUwOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7461 invoked from network); 26 Apr 2012 08:54:07 -0000
Received: from service56-us.mimecast.com (HELO service56-us.mimecast.com)
	(205.139.110.37)
	by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 08:54:07 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service56-us.mimecast.com; Thu, 26 Apr
	2012 04:54:02 -0400
Received: from HCAZUSCH2.hitachiconsulting.net (172.16.1.120) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 03:53:58 -0500
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 03:53:57 -0500
Received: from localhost6.localdomain6 (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 14:23:51 +0530
MIME-Version: 1.0
X-Mercurial-Node: 27a6422ac06df8bef75dcef2bc0f617ed9a4e104
Message-ID: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Apr 2012 16:54:09 +0800
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042604540300102
Cc: xuesen.guo@hitachiconsulting.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add the check of bzImage kernel and make it work
with RHEL 6 bzipped kernels

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>

---
Changed since v1:
  * add additional checks of the offset and length
  * not changing st.st_size, use size instead of st.st_size

diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary *elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,13 +204,45 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
-	size = st.st_size;
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
+			return 1;
+		}
 
-	usize = xc_dom_check_gzip(xch, image, st.st_size);
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+		
+		if ( payload_offset >= st.st_size )
+		{
+			printf("%s: payload offset overflow", __FUNCTION__);
+			return 1;
+		}
+		if ( (payload_offset + payload_length) > st.st_size )
+		{
+			printf("%s: payload length overflow", __FUNCTION__);
+			return 1;
+		}
+
+		image = image + payload_offset;
+		size = payload_length;
+	} else {
+		size = st.st_size;
+	}
+
+	usize = xc_dom_check_gzip(xch, image, size);
 	if (usize)
 	{
 		tmp = malloc(usize);
-		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
+		xc_dom_do_gunzip(xch, image, size, tmp, usize);
 		image = tmp;
 		size = usize;
 	}

This e-mail is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. Any review, dissemination,
copying, printing or other use of this e-mail by persons or entities other than the 
addressee is prohibited. If you have received this e-mail in error, please contact
the sender immediately and delete the material from any computer.
To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
Hitachi Consulting (China) Co., Ltd. (HCCD0411)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKVa-0001il-Ig; Thu, 26 Apr 2012 08:57:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKVZ-0001ib-EA
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 08:57:01 +0000
Received: from [85.158.138.51:30707] by server-10.bemta-3.messagelabs.com id
	CB/74-29478-CDD099F4; Thu, 26 Apr 2012 08:57:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335430619!23845301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25819 invoked from network); 26 Apr 2012 08:57:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 08:57:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:56:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 09:56:58 +0100
Message-ID: <1335430617.28015.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 09:56:57 +0100
In-Reply-To: <1335369353-13012-18-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-18-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/25] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> libxl__spawn_spawn becomes a callback-style asynchronous function.
> The implementation is now in terms of libxl__ev_* including
> libxl_ev_child.
> 
> All the callers need to be updated.  This includes the device model
> spawning functions libxl__create_device_model and
> libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
> and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
> abolished; instead the dm spawner calls back.
> 
> (The choice of which kind of device model to create is lifted out of
> what used to be libxl__create_device_model, because that function was
> indirectly recursive.  Recursive callback-style operations are clumsy
> because they require a pointer indirection for the nested states.)
> 
> Waiting for proper device model startup it is no longer notionally
> optional.  Previously the code appeared to tolerate this by passing
> NULL for various libxl__spawner_starting* parameters to device model
> spawners.  However, this was not used anywhere.
> 
> Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
> no longer supported.  It remains as an unused formal parameter to
> avoid updating, in this patch, all the call sites which pass NULL.
> libxl__wait_for_offspring is in any case itself an obsolete function,
> so this wrinkle will go away when its callers are updated to use the
> event system.  Consequently libxl__spawn_check is also abolished.
> 
> The "console ready" callback also remains unchanged in this patch.
> The API for this needs to be reviewed in the context of the event
> series and its reentrancy restrictions documented.
> 
> Thus their callers need to be updated.  These are the domain creation
> functions libxl_domain_create_new and _restore.  These functions now
> take ao_hows, and have a private state structure.
> 
> However domain creation remains not completely converted to the event
> mechanism; in particular it runs the outward-facing function
> libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
> happens in the current code this is not a bug because none of the rest
> of the functionality surrounding the bootloader call will mind if the
> event loop is reentered in the middle of its execution.
> 
> The file-scope function libxl__set_fd_flag which was used by the
> previous spawn arrangements becomes unused and is removed; other
> places in libxl can use libxl_fd_set_nonblock and
> libxl_fd_set_cloexec, which of course remain.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Changes since v7:

Based on this, and a fairly cursory glance through the new version:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

>  * Rename libxl__spawn_stubdom to libxl__spawn_stub_dm (and ..._state);
>    rename the state's stubdom_* members to dm_*.
>  * Eliminate the union between the two dm creation states in
>    libxl__domain_create_state.  Instead, the domain creation code
>    simply uses libxl__stub_dm_spawn_state.dm directly, if we're
>    taking the local dm path.
>  * Remove a spurious "break".
>  * In domain creation, move the PV non-qemu case into the switch.
>  * Code style fixes.
>  * Constify some convenience aliases.
>  * Improve comments (including typo fixes).
> ---
>  tools/libxl/libxl.h          |   14 ++-
>  tools/libxl/libxl_create.c   |  206 +++++++++++++++++++-----
>  tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
>  tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
>  tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
>  tools/libxl/xl_cmdimpl.c     |    6 +-
>  6 files changed, 683 insertions(+), 402 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKVa-0001il-Ig; Thu, 26 Apr 2012 08:57:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKVZ-0001ib-EA
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 08:57:01 +0000
Received: from [85.158.138.51:30707] by server-10.bemta-3.messagelabs.com id
	CB/74-29478-CDD099F4; Thu, 26 Apr 2012 08:57:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335430619!23845301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25819 invoked from network); 26 Apr 2012 08:57:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 08:57:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:56:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 09:56:58 +0100
Message-ID: <1335430617.28015.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 09:56:57 +0100
In-Reply-To: <1335369353-13012-18-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-18-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/25] libxl: ao: convert libxl__spawn_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> libxl__spawn_spawn becomes a callback-style asynchronous function.
> The implementation is now in terms of libxl__ev_* including
> libxl_ev_child.
> 
> All the callers need to be updated.  This includes the device model
> spawning functions libxl__create_device_model and
> libxl__create_stubdom; these are replaced with libxl__spawn_local_dm
> and libxl__spawn_stubdom.  libxl__confirm_device_model_startup is
> abolished; instead the dm spawner calls back.
> 
> (The choice of which kind of device model to create is lifted out of
> what used to be libxl__create_device_model, because that function was
> indirectly recursive.  Recursive callback-style operations are clumsy
> because they require a pointer indirection for the nested states.)
> 
> Waiting for proper device model startup it is no longer notionally
> optional.  Previously the code appeared to tolerate this by passing
> NULL for various libxl__spawner_starting* parameters to device model
> spawners.  However, this was not used anywhere.
> 
> Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is
> no longer supported.  It remains as an unused formal parameter to
> avoid updating, in this patch, all the call sites which pass NULL.
> libxl__wait_for_offspring is in any case itself an obsolete function,
> so this wrinkle will go away when its callers are updated to use the
> event system.  Consequently libxl__spawn_check is also abolished.
> 
> The "console ready" callback also remains unchanged in this patch.
> The API for this needs to be reviewed in the context of the event
> series and its reentrancy restrictions documented.
> 
> Thus their callers need to be updated.  These are the domain creation
> functions libxl_domain_create_new and _restore.  These functions now
> take ao_hows, and have a private state structure.
> 
> However domain creation remains not completely converted to the event
> mechanism; in particular it runs the outward-facing function
> libxl_run_bootloader with a NULL ao_how, which is quite wrong.  As it
> happens in the current code this is not a bug because none of the rest
> of the functionality surrounding the bootloader call will mind if the
> event loop is reentered in the middle of its execution.
> 
> The file-scope function libxl__set_fd_flag which was used by the
> previous spawn arrangements becomes unused and is removed; other
> places in libxl can use libxl_fd_set_nonblock and
> libxl_fd_set_cloexec, which of course remain.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Changes since v7:

Based on this, and a fairly cursory glance through the new version:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

>  * Rename libxl__spawn_stubdom to libxl__spawn_stub_dm (and ..._state);
>    rename the state's stubdom_* members to dm_*.
>  * Eliminate the union between the two dm creation states in
>    libxl__domain_create_state.  Instead, the domain creation code
>    simply uses libxl__stub_dm_spawn_state.dm directly, if we're
>    taking the local dm path.
>  * Remove a spurious "break".
>  * In domain creation, move the PV non-qemu case into the switch.
>  * Code style fixes.
>  * Constify some convenience aliases.
>  * Improve comments (including typo fixes).
> ---
>  tools/libxl/libxl.h          |   14 ++-
>  tools/libxl/libxl_create.c   |  206 +++++++++++++++++++-----
>  tools/libxl/libxl_dm.c       |  219 +++++++++++++++-----------
>  tools/libxl/libxl_exec.c     |  354 +++++++++++++++++++++---------------------
>  tools/libxl/libxl_internal.h |  286 +++++++++++++++++++++++-----------
>  tools/libxl/xl_cmdimpl.c     |    6 +-
>  6 files changed, 683 insertions(+), 402 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:58:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKX6-0001pT-1V; Thu, 26 Apr 2012 08:58:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKX3-0001pH-VQ
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 08:58:34 +0000
Received: from [85.158.139.83:47355] by server-4.bemta-5.messagelabs.com id
	B9/11-10788-93E099F4; Thu, 26 Apr 2012 08:58:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335430712!25612271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30907 invoked from network); 26 Apr 2012 08:58:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 08:58:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:58:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 09:58:31 +0100
Message-ID: <1335430710.28015.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 09:58:30 +0100
In-Reply-To: <1335369353-13012-20-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-20-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/25] libxl: Fix an ao completion bug;
	document locking policy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> Document the concurrent access policies for libxl__ao and libxl__egc,
> and their corresponding gcs.
> 
> Fix a violation of the policy:
> 
> If an ao was submitted and a callback requested, and while the
> initiating function was still running on the original thread, the ao
> is completed on another thread, the completing thread would improperly
> concurrently access the ao with the initiating thread.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_event.c    |    7 +++++++
>  tools/libxl/libxl_internal.h |   23 ++++++++++++++++++++++-
>  2 files changed, 29 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 2f559d5..7e8d002 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -897,6 +897,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
>  
>  static void egc_run_callbacks(libxl__egc *egc)
>  {
> +    /*
> +     * The callbacks must happen with the ctx unlocked.
> +     * See the comment near #define EGC_GC in libxl_internal.h and
> +     * those in the definitions of libxl__egc and libxl__ao.
> +     */
>      EGC_GC;
>      libxl_event *ev, *ev_tmp;
>  
> @@ -910,9 +915,11 @@ static void egc_run_callbacks(libxl__egc *egc)
>                               entry_for_callback, ao_tmp) {
>          LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
>          ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
> +        CTX_LOCK;
>          ao->notified = 1;
>          if (!ao->in_initiator)
>              libxl__ao__destroy(CTX, ao);
> +        CTX_UNLOCK;
>      }
>  }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index c238e86..26e0713 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -369,7 +369,8 @@ struct libxl__gc {
>  };
>  
>  struct libxl__egc {
> -    /* for event-generating functions only */
> +    /* For event-generating functions only.
> +     * The egc and its gc may be accessed only on the creating thread. */
>      struct libxl__gc gc;
>      struct libxl__event_list occurred_for_callback;
>      LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
> @@ -379,6 +380,20 @@ struct libxl__egc {
>  #define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
>  
>  struct libxl__ao {
> +    /*
> +     * An ao and its gc may be accessed only with the ctx lock held.
> +     *
> +     * Special exception: If an ao has been added to
> +     * egc->aos_for_callback, the thread owning the egc may remove the
> +     * ao from that list and make the callback without holding the
> +     * lock.
> +     *
> +     * Corresponding restriction: An ao may be added only to one
> +     * egc->aos_for_callback, once; rc and how must already have been
> +     * set and may not be subsequently modified.  (This restriction is
> +     * easily and obviously met since the ao is queued for callback
> +     * only in libxl__ao_complete.)
> +     */
>      uint32_t magic;
>      unsigned constructing:1, in_initiator:1, complete:1, notified:1;
>      int rc;
> @@ -1356,6 +1371,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>   * should in any case not find it necessary to call egc-creators from
>   * within libxl.
>   *
> + * The callbacks must all take place with the ctx unlocked because
> + * the application is entitled to reenter libxl from them.  This
> + * would be bad not because the lock is not recursive (it is) but
> + * because the application might make blocking libxl calls which
> + * would hold the lock unreasonably long.
> + *
>   * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
>   * with the ctx *unlocked*.  So the right pattern has the EGC_...
>   * macro calls on the outside of the CTX_... ones.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 08:58:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 08:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKX6-0001pT-1V; Thu, 26 Apr 2012 08:58:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKX3-0001pH-VQ
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 08:58:34 +0000
Received: from [85.158.139.83:47355] by server-4.bemta-5.messagelabs.com id
	B9/11-10788-93E099F4; Thu, 26 Apr 2012 08:58:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335430712!25612271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30907 invoked from network); 26 Apr 2012 08:58:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 08:58:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:58:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 09:58:31 +0100
Message-ID: <1335430710.28015.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 09:58:30 +0100
In-Reply-To: <1335369353-13012-20-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-20-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/25] libxl: Fix an ao completion bug;
	document locking policy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> Document the concurrent access policies for libxl__ao and libxl__egc,
> and their corresponding gcs.
> 
> Fix a violation of the policy:
> 
> If an ao was submitted and a callback requested, and while the
> initiating function was still running on the original thread, the ao
> is completed on another thread, the completing thread would improperly
> concurrently access the ao with the initiating thread.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_event.c    |    7 +++++++
>  tools/libxl/libxl_internal.h |   23 ++++++++++++++++++++++-
>  2 files changed, 29 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 2f559d5..7e8d002 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -897,6 +897,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
>  
>  static void egc_run_callbacks(libxl__egc *egc)
>  {
> +    /*
> +     * The callbacks must happen with the ctx unlocked.
> +     * See the comment near #define EGC_GC in libxl_internal.h and
> +     * those in the definitions of libxl__egc and libxl__ao.
> +     */
>      EGC_GC;
>      libxl_event *ev, *ev_tmp;
>  
> @@ -910,9 +915,11 @@ static void egc_run_callbacks(libxl__egc *egc)
>                               entry_for_callback, ao_tmp) {
>          LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
>          ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
> +        CTX_LOCK;
>          ao->notified = 1;
>          if (!ao->in_initiator)
>              libxl__ao__destroy(CTX, ao);
> +        CTX_UNLOCK;
>      }
>  }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index c238e86..26e0713 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -369,7 +369,8 @@ struct libxl__gc {
>  };
>  
>  struct libxl__egc {
> -    /* for event-generating functions only */
> +    /* For event-generating functions only.
> +     * The egc and its gc may be accessed only on the creating thread. */
>      struct libxl__gc gc;
>      struct libxl__event_list occurred_for_callback;
>      LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
> @@ -379,6 +380,20 @@ struct libxl__egc {
>  #define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
>  
>  struct libxl__ao {
> +    /*
> +     * An ao and its gc may be accessed only with the ctx lock held.
> +     *
> +     * Special exception: If an ao has been added to
> +     * egc->aos_for_callback, the thread owning the egc may remove the
> +     * ao from that list and make the callback without holding the
> +     * lock.
> +     *
> +     * Corresponding restriction: An ao may be added only to one
> +     * egc->aos_for_callback, once; rc and how must already have been
> +     * set and may not be subsequently modified.  (This restriction is
> +     * easily and obviously met since the ao is queued for callback
> +     * only in libxl__ao_complete.)
> +     */
>      uint32_t magic;
>      unsigned constructing:1, in_initiator:1, complete:1, notified:1;
>      int rc;
> @@ -1356,6 +1371,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>   * should in any case not find it necessary to call egc-creators from
>   * within libxl.
>   *
> + * The callbacks must all take place with the ctx unlocked because
> + * the application is entitled to reenter libxl from them.  This
> + * would be bad not because the lock is not recursive (it is) but
> + * because the application might make blocking libxl calls which
> + * would hold the lock unreasonably long.
> + *
>   * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
>   * with the ctx *unlocked*.  So the right pattern has the EGC_...
>   * macro calls on the outside of the CTX_... ones.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:02:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKau-00025B-P3; Thu, 26 Apr 2012 09:02:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKat-000253-MU
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:02:31 +0000
Received: from [85.158.143.99:23420] by server-1.bemta-4.messagelabs.com id
	A7/C6-20925-62F099F4; Thu, 26 Apr 2012 09:02:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335430936!20075625!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26519 invoked from network); 26 Apr 2012 09:02:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:02:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:02:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:02:16 +0100
Message-ID: <1335430935.28015.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 10:02:15 +0100
In-Reply-To: <1335369353-13012-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/25] libxl: provide progress reporting for
 long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> This will be used for reporting, during domain creation, that the
> console is ready.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes since v7:
>  * If aop->how.callback, actually add the aop to the for_callback list (!)
>  * Document the threadsafety of aop's, and make appropriate cross-references.
>  * Allocate the actual aop from its thread's egc; do not free it.
>  * Remove pointless code motion of libxl__ao_create.
>  * Minor formatting fixes.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:02:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKau-00025B-P3; Thu, 26 Apr 2012 09:02:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKat-000253-MU
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:02:31 +0000
Received: from [85.158.143.99:23420] by server-1.bemta-4.messagelabs.com id
	A7/C6-20925-62F099F4; Thu, 26 Apr 2012 09:02:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335430936!20075625!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26519 invoked from network); 26 Apr 2012 09:02:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:02:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:02:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:02:16 +0100
Message-ID: <1335430935.28015.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 10:02:15 +0100
In-Reply-To: <1335369353-13012-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/25] libxl: provide progress reporting for
 long-running operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> This will be used for reporting, during domain creation, that the
> console is ready.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes since v7:
>  * If aop->how.callback, actually add the aop to the for_callback list (!)
>  * Document the threadsafety of aop's, and make appropriate cross-references.
>  * Allocate the actual aop from its thread's egc; do not free it.
>  * Remove pointless code motion of libxl__ao_create.
>  * Minor formatting fixes.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKc4-0002A2-7x; Thu, 26 Apr 2012 09:03:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKc2-00029n-NT
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:03:42 +0000
Received: from [85.158.143.99:30958] by server-2.bemta-4.messagelabs.com id
	1E/1D-17550-E6F099F4; Thu, 26 Apr 2012 09:03:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335431021!24781548!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15293 invoked from network); 26 Apr 2012 09:03:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:03:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149314"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:03:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:03:40 +0100
Message-ID: <1335431019.28015.65.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 10:03:39 +0100
In-Reply-To: <1335369353-13012-25-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-25-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/25] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> is now moved elsewhere, as follows:
> 
> * The "logging version of fork", which is what it was billed as, is now
>   xl_fork, which also dies on failure.
> 
> * Closing the xenstore handle in the child is now done in
>   libxl__ev_child_fork, which is the only remaining place where fork
>   is called in libxl.
> 
> * We provide a new function libxl__ev_child_xenstore_reopen for
>   in-libxl children to make the ctx useable for xenstore again.
> 
> * Consequently libxl__spawn_record_pid now no longer needs to mess
>   about with its own xenstore handle.  As a bonus it can now just use
>   libxl__xs_write.
> 
> Also, since we have now converted all the forkers in libxl, we can
> always honour the fork_replacement childproc hook - so do so.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKc4-0002A2-7x; Thu, 26 Apr 2012 09:03:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKc2-00029n-NT
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:03:42 +0000
Received: from [85.158.143.99:30958] by server-2.bemta-4.messagelabs.com id
	1E/1D-17550-E6F099F4; Thu, 26 Apr 2012 09:03:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335431021!24781548!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxNg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15293 invoked from network); 26 Apr 2012 09:03:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:03:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149314"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:03:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:03:40 +0100
Message-ID: <1335431019.28015.65.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 10:03:39 +0100
In-Reply-To: <1335369353-13012-25-git-send-email-ian.jackson@eu.citrix.com>
References: <1335369353-13012-1-git-send-email-ian.jackson@eu.citrix.com>
	<1335369353-13012-25-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 24/25] libxl: child processes cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-04-25 at 16:55 +0100, Ian Jackson wrote:
> Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> is now moved elsewhere, as follows:
> 
> * The "logging version of fork", which is what it was billed as, is now
>   xl_fork, which also dies on failure.
> 
> * Closing the xenstore handle in the child is now done in
>   libxl__ev_child_fork, which is the only remaining place where fork
>   is called in libxl.
> 
> * We provide a new function libxl__ev_child_xenstore_reopen for
>   in-libxl children to make the ctx useable for xenstore again.
> 
> * Consequently libxl__spawn_record_pid now no longer needs to mess
>   about with its own xenstore handle.  As a bonus it can now just use
>   libxl__xs_write.
> 
> Also, since we have now converted all the forkers in libxl, we can
> always honour the fork_replacement childproc hook - so do so.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:07:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKfk-0002Lg-UU; Thu, 26 Apr 2012 09:07:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKfj-0002LY-HU
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 09:07:31 +0000
Received: from [85.158.138.51:37533] by server-11.bemta-3.messagelabs.com id
	A8/F5-18894-250199F4; Thu, 26 Apr 2012 09:07:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335431249!22067786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11614 invoked from network); 26 Apr 2012 09:07:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:07:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149407"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:07:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:07:28 +0100
Message-ID: <1335431247.28015.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Date: Thu, 26 Apr 2012 10:07:27 +0100
In-Reply-To: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 09:54 +0100, Xuesen Guo wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels
> 
> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>

Thanks, I think is now equivalent to xc_dom_probe_bzimage_kernel(),
which has been security audited, and therefore:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> ---
> Changed since v1:
>   * add additional checks of the offset and length
>   * not changing st.st_size, use size instead of st.st_size
> 
> diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> @@ -18,6 +18,48 @@
>  
>  static xc_interface *xch;
>  
> +/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
> +/* We add support of bzImage kernel */
> +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> +struct setup_header {
> +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> +	uint8_t  setup_sects;
> +	uint16_t root_flags;
> +	uint32_t syssize;
> +	uint16_t ram_size;
> +	uint16_t vid_mode;
> +	uint16_t root_dev;
> +	uint16_t boot_flag;
> +	uint16_t jump;
> +	uint32_t header;
> +#define HDR_MAGIC  "HdrS"
> +#define HDR_MAGIC_SZ 4
> +	uint16_t version;
> +#define VERSION(h,l) (((h)<<8) | (l))
> +	uint32_t realmode_swtch;
> +	uint16_t start_sys;
> +	uint16_t kernel_version;
> +	uint8_t  type_of_loader;
> +	uint8_t  loadflags;
> +	uint16_t setup_move_size;
> +	uint32_t code32_start;
> +	uint32_t ramdisk_image;
> +	uint32_t ramdisk_size;
> +	uint32_t bootsect_kludge;
> +	uint16_t heap_end_ptr;
> +	uint16_t _pad1;
> +	uint32_t cmd_line_ptr;
> +	uint32_t initrd_addr_max;
> +	uint32_t kernel_alignment;
> +	uint8_t  relocatable_kernel;
> +	uint8_t  _pad2[3];
> +	uint32_t cmdline_size;
> +	uint32_t hardware_subarch;
> +	uint64_t hardware_subarch_data;
> +	uint32_t payload_offset;
> +	uint32_t payload_length;
> +} __attribute__((packed));
> +
>  static void print_string_note(const char *prefix, struct elf_binary *elf,
>  			      const elf_note *note)
>  {
> @@ -131,6 +173,9 @@ int main(int argc, char **argv)
>  	const elf_shdr *shdr;
>  	int notes_found = 0;
>  
> +	struct setup_header *hdr;
> +	uint64_t payload_offset, payload_length;
> +
>  	if (argc != 2)
>  	{
>  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> @@ -159,13 +204,45 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> -	size = st.st_size;
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return 1;
> +		}
>  
> -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;
> +		
> +		if ( payload_offset >= st.st_size )
> +		{
> +			printf("%s: payload offset overflow", __FUNCTION__);
> +			return 1;
> +		}
> +		if ( (payload_offset + payload_length) > st.st_size )
> +		{
> +			printf("%s: payload length overflow", __FUNCTION__);
> +			return 1;
> +		}
> +
> +		image = image + payload_offset;
> +		size = payload_length;
> +	} else {
> +		size = st.st_size;
> +	}
> +
> +	usize = xc_dom_check_gzip(xch, image, size);
>  	if (usize)
>  	{
>  		tmp = malloc(usize);
> -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
>  		image = tmp;
>  		size = usize;
>  	}
> 
> This e-mail is intended solely for the person or entity to which it is addressed
> and may contain confidential and/or privileged information. Any review, dissemination,
> copying, printing or other use of this e-mail by persons or entities other than the 
> addressee is prohibited. If you have received this e-mail in error, please contact
> the sender immediately and delete the material from any computer.
> To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:07:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKfk-0002Lg-UU; Thu, 26 Apr 2012 09:07:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKfj-0002LY-HU
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 09:07:31 +0000
Received: from [85.158.138.51:37533] by server-11.bemta-3.messagelabs.com id
	A8/F5-18894-250199F4; Thu, 26 Apr 2012 09:07:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335431249!22067786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11614 invoked from network); 26 Apr 2012 09:07:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:07:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149407"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:07:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:07:28 +0100
Message-ID: <1335431247.28015.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Date: Thu, 26 Apr 2012 10:07:27 +0100
In-Reply-To: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 09:54 +0100, Xuesen Guo wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels
> 
> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>

Thanks, I think is now equivalent to xc_dom_probe_bzimage_kernel(),
which has been security audited, and therefore:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> ---
> Changed since v1:
>   * add additional checks of the offset and length
>   * not changing st.st_size, use size instead of st.st_size
> 
> diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> @@ -18,6 +18,48 @@
>  
>  static xc_interface *xch;
>  
> +/* According to the implemation of xc_dom_probe_bzimage_kernel() function */
> +/* We add support of bzImage kernel */
> +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> +struct setup_header {
> +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> +	uint8_t  setup_sects;
> +	uint16_t root_flags;
> +	uint32_t syssize;
> +	uint16_t ram_size;
> +	uint16_t vid_mode;
> +	uint16_t root_dev;
> +	uint16_t boot_flag;
> +	uint16_t jump;
> +	uint32_t header;
> +#define HDR_MAGIC  "HdrS"
> +#define HDR_MAGIC_SZ 4
> +	uint16_t version;
> +#define VERSION(h,l) (((h)<<8) | (l))
> +	uint32_t realmode_swtch;
> +	uint16_t start_sys;
> +	uint16_t kernel_version;
> +	uint8_t  type_of_loader;
> +	uint8_t  loadflags;
> +	uint16_t setup_move_size;
> +	uint32_t code32_start;
> +	uint32_t ramdisk_image;
> +	uint32_t ramdisk_size;
> +	uint32_t bootsect_kludge;
> +	uint16_t heap_end_ptr;
> +	uint16_t _pad1;
> +	uint32_t cmd_line_ptr;
> +	uint32_t initrd_addr_max;
> +	uint32_t kernel_alignment;
> +	uint8_t  relocatable_kernel;
> +	uint8_t  _pad2[3];
> +	uint32_t cmdline_size;
> +	uint32_t hardware_subarch;
> +	uint64_t hardware_subarch_data;
> +	uint32_t payload_offset;
> +	uint32_t payload_length;
> +} __attribute__((packed));
> +
>  static void print_string_note(const char *prefix, struct elf_binary *elf,
>  			      const elf_note *note)
>  {
> @@ -131,6 +173,9 @@ int main(int argc, char **argv)
>  	const elf_shdr *shdr;
>  	int notes_found = 0;
>  
> +	struct setup_header *hdr;
> +	uint64_t payload_offset, payload_length;
> +
>  	if (argc != 2)
>  	{
>  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> @@ -159,13 +204,45 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> -	size = st.st_size;
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return 1;
> +		}
>  
> -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;
> +		
> +		if ( payload_offset >= st.st_size )
> +		{
> +			printf("%s: payload offset overflow", __FUNCTION__);
> +			return 1;
> +		}
> +		if ( (payload_offset + payload_length) > st.st_size )
> +		{
> +			printf("%s: payload length overflow", __FUNCTION__);
> +			return 1;
> +		}
> +
> +		image = image + payload_offset;
> +		size = payload_length;
> +	} else {
> +		size = st.st_size;
> +	}
> +
> +	usize = xc_dom_check_gzip(xch, image, size);
>  	if (usize)
>  	{
>  		tmp = malloc(usize);
> -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
>  		image = tmp;
>  		size = usize;
>  	}
> 
> This e-mail is intended solely for the person or entity to which it is addressed
> and may contain confidential and/or privileged information. Any review, dissemination,
> copying, printing or other use of this e-mail by persons or entities other than the 
> addressee is prohibited. If you have received this e-mail in error, please contact
> the sender immediately and delete the material from any computer.
> To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:09:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKhT-0002V4-JR; Thu, 26 Apr 2012 09:09:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNKhS-0002Ub-6A
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 09:09:18 +0000
Received: from [85.158.143.35:42290] by server-3.bemta-4.messagelabs.com id
	47/DE-05853-DB0199F4; Thu, 26 Apr 2012 09:09:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335431329!13559174!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23611 invoked from network); 26 Apr 2012 09:08:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:08:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNKgx-000HRe-5m; Thu, 26 Apr 2012 09:08:47 +0000
Date: Thu, 26 Apr 2012 10:08:47 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120426090847.GA67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120424160643.531daf88@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:06 -0700 on 24 Apr (1335283603), Mukesh Rathor wrote:
> On Tue, 24 Apr 2012 10:36:26 +0100
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > > On Thu, 19 Apr 2012 15:15:27 +0100
> > > Tim Deegan <tim@xen.org> wrote:
> 
> >you still have this mapping.  You should take a PGT_writeable_page
> >typecount, too, if the foreign domain isn't in paging_mode_external
> 
> Ok, I've it as:
>     if (paging_mode_external(fdom)) {
>         if (get_page_from_pagenr(mfn, fdom) == 0)
> 	    failed = 1;
>     } else {
>         if (get_page_and_type_from_pagenr(mfn, PGT_writable_page, fdom,0,0))
>             failed = 1;
>     }
> 
> But then later fails when it tries to pin the page,
> MMUEXT_PIN_L4_TABLE, from the lib at:

What's trying to pin an l4 table?  I thought your hybrid dom0 didn't use
the PV MMU.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:09:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKhT-0002V4-JR; Thu, 26 Apr 2012 09:09:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNKhS-0002Ub-6A
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 09:09:18 +0000
Received: from [85.158.143.35:42290] by server-3.bemta-4.messagelabs.com id
	47/DE-05853-DB0199F4; Thu, 26 Apr 2012 09:09:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335431329!13559174!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23611 invoked from network); 26 Apr 2012 09:08:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:08:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNKgx-000HRe-5m; Thu, 26 Apr 2012 09:08:47 +0000
Date: Thu, 26 Apr 2012 10:08:47 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120426090847.GA67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120424160643.531daf88@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:06 -0700 on 24 Apr (1335283603), Mukesh Rathor wrote:
> On Tue, 24 Apr 2012 10:36:26 +0100
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > > On Thu, 19 Apr 2012 15:15:27 +0100
> > > Tim Deegan <tim@xen.org> wrote:
> 
> >you still have this mapping.  You should take a PGT_writeable_page
> >typecount, too, if the foreign domain isn't in paging_mode_external
> 
> Ok, I've it as:
>     if (paging_mode_external(fdom)) {
>         if (get_page_from_pagenr(mfn, fdom) == 0)
> 	    failed = 1;
>     } else {
>         if (get_page_and_type_from_pagenr(mfn, PGT_writable_page, fdom,0,0))
>             failed = 1;
>     }
> 
> But then later fails when it tries to pin the page,
> MMUEXT_PIN_L4_TABLE, from the lib at:

What's trying to pin an l4 table?  I thought your hybrid dom0 didn't use
the PV MMU.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:13:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:13:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKkx-0002hU-7w; Thu, 26 Apr 2012 09:12:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNKkw-0002hN-78
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:12:54 +0000
Received: from [85.158.143.35:9561] by server-1.bemta-4.messagelabs.com id
	C6/19-20925-591199F4; Thu, 26 Apr 2012 09:12:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335431572!14961936!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29743 invoked from network); 26 Apr 2012 09:12:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:12:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNKkr-000HSh-LG; Thu, 26 Apr 2012 09:12:49 +0000
Date: Thu, 26 Apr 2012 10:12:49 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120426091249.GB67043@ocelot.phlegethon.org>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3] x86/mem_sharing: Improve performance
	of rmap, fix cascading bugs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:48 -0400 on 24 Apr (1335282500), Andres Lagar-Cavilla wrote:
> This is a repost of patches 2 and 3 of the series initially posted on Apr 12th.
> 
> The first patch has been split into two functionally isolated patches as per
> Tim Deegan's request.


Applied, thanks.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:13:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:13:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKkx-0002hU-7w; Thu, 26 Apr 2012 09:12:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNKkw-0002hN-78
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:12:54 +0000
Received: from [85.158.143.35:9561] by server-1.bemta-4.messagelabs.com id
	C6/19-20925-591199F4; Thu, 26 Apr 2012 09:12:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335431572!14961936!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29743 invoked from network); 26 Apr 2012 09:12:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:12:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNKkr-000HSh-LG; Thu, 26 Apr 2012 09:12:49 +0000
Date: Thu, 26 Apr 2012 10:12:49 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120426091249.GB67043@ocelot.phlegethon.org>
References: <patchbomb.1335296900@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1335296900@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3] x86/mem_sharing: Improve performance
	of rmap, fix cascading bugs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:48 -0400 on 24 Apr (1335282500), Andres Lagar-Cavilla wrote:
> This is a repost of patches 2 and 3 of the series initially posted on Apr 12th.
> 
> The first patch has been split into two functionally isolated patches as per
> Tim Deegan's request.


Applied, thanks.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKl6-0002iK-KB; Thu, 26 Apr 2012 09:13:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNKl5-0002i4-0g
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:13:03 +0000
Received: from [85.158.139.83:10371] by server-5.bemta-5.messagelabs.com id
	03/03-13566-E91199F4; Thu, 26 Apr 2012 09:13:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335431580!14315369!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3OTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3056 invoked from network); 26 Apr 2012 09:13:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:13:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Apr 2012 10:12:59 +0100
Message-Id: <4F992DCF0200007800080283@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Apr 2012 10:13:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <xuesen.guo@hitachiconsulting.com>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
In-Reply-To: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com> wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels

I fail to see the relation of the term "bzipped" above to the actual patch.

Jan

> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> 
> ---
> Changed since v1:
>   * add additional checks of the offset and length
>   * not changing st.st_size, use size instead of st.st_size
> 
> diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> @@ -18,6 +18,48 @@
>  
>  static xc_interface *xch;
>  
> +/* According to the implemation of xc_dom_probe_bzimage_kernel() function 
> */
> +/* We add support of bzImage kernel */
> +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> +struct setup_header {
> +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> +	uint8_t  setup_sects;
> +	uint16_t root_flags;
> +	uint32_t syssize;
> +	uint16_t ram_size;
> +	uint16_t vid_mode;
> +	uint16_t root_dev;
> +	uint16_t boot_flag;
> +	uint16_t jump;
> +	uint32_t header;
> +#define HDR_MAGIC  "HdrS"
> +#define HDR_MAGIC_SZ 4
> +	uint16_t version;
> +#define VERSION(h,l) (((h)<<8) | (l))
> +	uint32_t realmode_swtch;
> +	uint16_t start_sys;
> +	uint16_t kernel_version;
> +	uint8_t  type_of_loader;
> +	uint8_t  loadflags;
> +	uint16_t setup_move_size;
> +	uint32_t code32_start;
> +	uint32_t ramdisk_image;
> +	uint32_t ramdisk_size;
> +	uint32_t bootsect_kludge;
> +	uint16_t heap_end_ptr;
> +	uint16_t _pad1;
> +	uint32_t cmd_line_ptr;
> +	uint32_t initrd_addr_max;
> +	uint32_t kernel_alignment;
> +	uint8_t  relocatable_kernel;
> +	uint8_t  _pad2[3];
> +	uint32_t cmdline_size;
> +	uint32_t hardware_subarch;
> +	uint64_t hardware_subarch_data;
> +	uint32_t payload_offset;
> +	uint32_t payload_length;
> +} __attribute__((packed));
> +
>  static void print_string_note(const char *prefix, struct elf_binary *elf,
>  			      const elf_note *note)
>  {
> @@ -131,6 +173,9 @@ int main(int argc, char **argv)
>  	const elf_shdr *shdr;
>  	int notes_found = 0;
>  
> +	struct setup_header *hdr;
> +	uint64_t payload_offset, payload_length;
> +
>  	if (argc != 2)
>  	{
>  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> @@ -159,13 +204,45 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> -	size = st.st_size;
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return 1;
> +		}
>  
> -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;
> +		
> +		if ( payload_offset >= st.st_size )
> +		{
> +			printf("%s: payload offset overflow", __FUNCTION__);
> +			return 1;
> +		}
> +		if ( (payload_offset + payload_length) > st.st_size )
> +		{
> +			printf("%s: payload length overflow", __FUNCTION__);
> +			return 1;
> +		}
> +
> +		image = image + payload_offset;
> +		size = payload_length;
> +	} else {
> +		size = st.st_size;
> +	}
> +
> +	usize = xc_dom_check_gzip(xch, image, size);
>  	if (usize)
>  	{
>  		tmp = malloc(usize);
> -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
>  		image = tmp;
>  		size = usize;
>  	}
> 
> This e-mail is intended solely for the person or entity to which it is 
> addressed
> and may contain confidential and/or privileged information. Any review, 
> dissemination,
> copying, printing or other use of this e-mail by persons or entities other 
> than the 
> addressee is prohibited. If you have received this e-mail in error, please 
> contact
> the sender immediately and delete the material from any computer.
> To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKl6-0002iK-KB; Thu, 26 Apr 2012 09:13:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNKl5-0002i4-0g
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:13:03 +0000
Received: from [85.158.139.83:10371] by server-5.bemta-5.messagelabs.com id
	03/03-13566-E91199F4; Thu, 26 Apr 2012 09:13:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335431580!14315369!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3OTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3056 invoked from network); 26 Apr 2012 09:13:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:13:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Apr 2012 10:12:59 +0100
Message-Id: <4F992DCF0200007800080283@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Apr 2012 10:13:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <xuesen.guo@hitachiconsulting.com>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
In-Reply-To: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com> wrote:
> Add the check of bzImage kernel and make it work
> with RHEL 6 bzipped kernels

I fail to see the relation of the term "bzipped" above to the actual patch.

Jan

> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> 
> ---
> Changed since v1:
>   * add additional checks of the offset and length
>   * not changing st.st_size, use size instead of st.st_size
> 
> diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> @@ -18,6 +18,48 @@
>  
>  static xc_interface *xch;
>  
> +/* According to the implemation of xc_dom_probe_bzimage_kernel() function 
> */
> +/* We add support of bzImage kernel */
> +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> +struct setup_header {
> +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> +	uint8_t  setup_sects;
> +	uint16_t root_flags;
> +	uint32_t syssize;
> +	uint16_t ram_size;
> +	uint16_t vid_mode;
> +	uint16_t root_dev;
> +	uint16_t boot_flag;
> +	uint16_t jump;
> +	uint32_t header;
> +#define HDR_MAGIC  "HdrS"
> +#define HDR_MAGIC_SZ 4
> +	uint16_t version;
> +#define VERSION(h,l) (((h)<<8) | (l))
> +	uint32_t realmode_swtch;
> +	uint16_t start_sys;
> +	uint16_t kernel_version;
> +	uint8_t  type_of_loader;
> +	uint8_t  loadflags;
> +	uint16_t setup_move_size;
> +	uint32_t code32_start;
> +	uint32_t ramdisk_image;
> +	uint32_t ramdisk_size;
> +	uint32_t bootsect_kludge;
> +	uint16_t heap_end_ptr;
> +	uint16_t _pad1;
> +	uint32_t cmd_line_ptr;
> +	uint32_t initrd_addr_max;
> +	uint32_t kernel_alignment;
> +	uint8_t  relocatable_kernel;
> +	uint8_t  _pad2[3];
> +	uint32_t cmdline_size;
> +	uint32_t hardware_subarch;
> +	uint64_t hardware_subarch_data;
> +	uint32_t payload_offset;
> +	uint32_t payload_length;
> +} __attribute__((packed));
> +
>  static void print_string_note(const char *prefix, struct elf_binary *elf,
>  			      const elf_note *note)
>  {
> @@ -131,6 +173,9 @@ int main(int argc, char **argv)
>  	const elf_shdr *shdr;
>  	int notes_found = 0;
>  
> +	struct setup_header *hdr;
> +	uint64_t payload_offset, payload_length;
> +
>  	if (argc != 2)
>  	{
>  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> @@ -159,13 +204,45 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
>  		return 1;
>  	}
> -	size = st.st_size;
> +	
> +	/* Check the magic of bzImage kernel */
> +	hdr = (struct setup_header *)image;
> +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> +	{
> +		if ( hdr->version < VERSION(2,8) )
> +		{
> +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> +			return 1;
> +		}
>  
> -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> +		/* upcast to 64 bits to avoid overflow */
> +		/* setup_sects is u8 and so cannot overflow */
> +		payload_offset = (hdr->setup_sects + 1) * 512;
> +		payload_offset += hdr->payload_offset;
> +		payload_length = hdr->payload_length;
> +		
> +		if ( payload_offset >= st.st_size )
> +		{
> +			printf("%s: payload offset overflow", __FUNCTION__);
> +			return 1;
> +		}
> +		if ( (payload_offset + payload_length) > st.st_size )
> +		{
> +			printf("%s: payload length overflow", __FUNCTION__);
> +			return 1;
> +		}
> +
> +		image = image + payload_offset;
> +		size = payload_length;
> +	} else {
> +		size = st.st_size;
> +	}
> +
> +	usize = xc_dom_check_gzip(xch, image, size);
>  	if (usize)
>  	{
>  		tmp = malloc(usize);
> -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
>  		image = tmp;
>  		size = usize;
>  	}
> 
> This e-mail is intended solely for the person or entity to which it is 
> addressed
> and may contain confidential and/or privileged information. Any review, 
> dissemination,
> copying, printing or other use of this e-mail by persons or entities other 
> than the 
> addressee is prohibited. If you have received this e-mail in error, please 
> contact
> the sender immediately and delete the material from any computer.
> To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:13:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKlF-0002jg-0i; Thu, 26 Apr 2012 09:13:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNKlE-0002jO-BY
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:13:12 +0000
Received: from [85.158.139.83:56705] by server-8.bemta-5.messagelabs.com id
	16/C8-26964-7A1199F4; Thu, 26 Apr 2012 09:13:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335431590!25569451!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26235 invoked from network); 26 Apr 2012 09:13:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:13:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNKlC-000HSz-AJ; Thu, 26 Apr 2012 09:13:10 +0000
Date: Thu, 26 Apr 2012 10:13:10 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120426091310.GC67043@ocelot.phlegethon.org>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
	<5be9a05f17fd38f9c09f.1335295218@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5be9a05f17fd38f9c09f.1335295218@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mem_sharing: Fix saved mfns stat
	for failed unsharing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:20 -0400 on 24 Apr (1335280818), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> 
> If unsharing fails, the decrease of the nr_saved_mfns stat was not being
> undone. This would result in an underflow of the stat, as the retry would later
> decrease the counter again.

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:13:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKlF-0002jg-0i; Thu, 26 Apr 2012 09:13:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNKlE-0002jO-BY
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:13:12 +0000
Received: from [85.158.139.83:56705] by server-8.bemta-5.messagelabs.com id
	16/C8-26964-7A1199F4; Thu, 26 Apr 2012 09:13:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335431590!25569451!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26235 invoked from network); 26 Apr 2012 09:13:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 09:13:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNKlC-000HSz-AJ; Thu, 26 Apr 2012 09:13:10 +0000
Date: Thu, 26 Apr 2012 10:13:10 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120426091310.GC67043@ocelot.phlegethon.org>
References: <patchbomb.1335295217@xdev.gridcentric.ca>
	<5be9a05f17fd38f9c09f.1335295218@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5be9a05f17fd38f9c09f.1335295218@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mem_sharing: Fix saved mfns stat
	for failed unsharing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:20 -0400 on 24 Apr (1335280818), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> 
> If unsharing fails, the decrease of the nr_saved_mfns stat was not being
> undone. This would result in an underflow of the stat, as the retry would later
> decrease the counter again.

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:20:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKru-000389-Sp; Thu, 26 Apr 2012 09:20:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKrt-000384-OE
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:20:06 +0000
Received: from [193.109.254.147:19197] by server-10.bemta-14.messagelabs.com
	id 3D/F8-05847-543199F4; Thu, 26 Apr 2012 09:20:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335432004!6423061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31698 invoked from network); 26 Apr 2012 09:20:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:20:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:20:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:20:03 +0100
Message-ID: <1335432002.28015.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 26 Apr 2012 10:20:02 +0100
In-Reply-To: <4F992DCF0200007800080283@nat28.tlf.novell.com>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xuesen.guo@hitachiconsulting.com" <xuesen.guo@hitachiconsulting.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
> >>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com> wrote:
> > Add the check of bzImage kernel and make it work
> > with RHEL 6 bzipped kernels
> 
> I fail to see the relation of the term "bzipped" above to the actual patch.

Oh yes, this is a common misconception (which I failed to notice in my
review).

The "bz" in bzImage does not refer to the bzip compression algorithm.
Rather it refers to "big zImage". It's a historical thing because the
original zImage compressor was restricted to <1M (or something) of RAM
at decompression time and bzImage was introduced to cope with more and
therefore worked for larger kernels. Obviously 1M is very limiting to in
practice everyone uses bzImage today...

Now of course today, just to add to the confusion, bzImage can support
multiple compression algorithms, including the original z, but also
bzip2, lzma and xz.

Ian

> 
> Jan
> 
> > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > 
> > ---
> > Changed since v1:
> >   * add additional checks of the offset and length
> >   * not changing st.st_size, use size instead of st.st_size
> > 
> > diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> > --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> > +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> > @@ -18,6 +18,48 @@
> >  
> >  static xc_interface *xch;
> >  
> > +/* According to the implemation of xc_dom_probe_bzimage_kernel() function 
> > */
> > +/* We add support of bzImage kernel */
> > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > +struct setup_header {
> > +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > +	uint8_t  setup_sects;
> > +	uint16_t root_flags;
> > +	uint32_t syssize;
> > +	uint16_t ram_size;
> > +	uint16_t vid_mode;
> > +	uint16_t root_dev;
> > +	uint16_t boot_flag;
> > +	uint16_t jump;
> > +	uint32_t header;
> > +#define HDR_MAGIC  "HdrS"
> > +#define HDR_MAGIC_SZ 4
> > +	uint16_t version;
> > +#define VERSION(h,l) (((h)<<8) | (l))
> > +	uint32_t realmode_swtch;
> > +	uint16_t start_sys;
> > +	uint16_t kernel_version;
> > +	uint8_t  type_of_loader;
> > +	uint8_t  loadflags;
> > +	uint16_t setup_move_size;
> > +	uint32_t code32_start;
> > +	uint32_t ramdisk_image;
> > +	uint32_t ramdisk_size;
> > +	uint32_t bootsect_kludge;
> > +	uint16_t heap_end_ptr;
> > +	uint16_t _pad1;
> > +	uint32_t cmd_line_ptr;
> > +	uint32_t initrd_addr_max;
> > +	uint32_t kernel_alignment;
> > +	uint8_t  relocatable_kernel;
> > +	uint8_t  _pad2[3];
> > +	uint32_t cmdline_size;
> > +	uint32_t hardware_subarch;
> > +	uint64_t hardware_subarch_data;
> > +	uint32_t payload_offset;
> > +	uint32_t payload_length;
> > +} __attribute__((packed));
> > +
> >  static void print_string_note(const char *prefix, struct elf_binary *elf,
> >  			      const elf_note *note)
> >  {
> > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> >  	const elf_shdr *shdr;
> >  	int notes_found = 0;
> >  
> > +	struct setup_header *hdr;
> > +	uint64_t payload_offset, payload_length;
> > +
> >  	if (argc != 2)
> >  	{
> >  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > @@ -159,13 +204,45 @@ int main(int argc, char **argv)
> >  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> >  		return 1;
> >  	}
> > -	size = st.st_size;
> > +	
> > +	/* Check the magic of bzImage kernel */
> > +	hdr = (struct setup_header *)image;
> > +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> > +	{
> > +		if ( hdr->version < VERSION(2,8) )
> > +		{
> > +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> > +			return 1;
> > +		}
> >  
> > -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> > +		/* upcast to 64 bits to avoid overflow */
> > +		/* setup_sects is u8 and so cannot overflow */
> > +		payload_offset = (hdr->setup_sects + 1) * 512;
> > +		payload_offset += hdr->payload_offset;
> > +		payload_length = hdr->payload_length;
> > +		
> > +		if ( payload_offset >= st.st_size )
> > +		{
> > +			printf("%s: payload offset overflow", __FUNCTION__);
> > +			return 1;
> > +		}
> > +		if ( (payload_offset + payload_length) > st.st_size )
> > +		{
> > +			printf("%s: payload length overflow", __FUNCTION__);
> > +			return 1;
> > +		}
> > +
> > +		image = image + payload_offset;
> > +		size = payload_length;
> > +	} else {
> > +		size = st.st_size;
> > +	}
> > +
> > +	usize = xc_dom_check_gzip(xch, image, size);
> >  	if (usize)
> >  	{
> >  		tmp = malloc(usize);
> > -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> > +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
> >  		image = tmp;
> >  		size = usize;
> >  	}
> > 
> > This e-mail is intended solely for the person or entity to which it is 
> > addressed
> > and may contain confidential and/or privileged information. Any review, 
> > dissemination,
> > copying, printing or other use of this e-mail by persons or entities other 
> > than the 
> > addressee is prohibited. If you have received this e-mail in error, please 
> > contact
> > the sender immediately and delete the material from any computer.
> > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org 
> > http://lists.xen.org/xen-devel 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:20:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNKru-000389-Sp; Thu, 26 Apr 2012 09:20:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNKrt-000384-OE
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:20:06 +0000
Received: from [193.109.254.147:19197] by server-10.bemta-14.messagelabs.com
	id 3D/F8-05847-543199F4; Thu, 26 Apr 2012 09:20:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335432004!6423061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31698 invoked from network); 26 Apr 2012 09:20:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:20:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12149726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 09:20:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:20:03 +0100
Message-ID: <1335432002.28015.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 26 Apr 2012 10:20:02 +0100
In-Reply-To: <4F992DCF0200007800080283@nat28.tlf.novell.com>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xuesen.guo@hitachiconsulting.com" <xuesen.guo@hitachiconsulting.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
> >>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com> wrote:
> > Add the check of bzImage kernel and make it work
> > with RHEL 6 bzipped kernels
> 
> I fail to see the relation of the term "bzipped" above to the actual patch.

Oh yes, this is a common misconception (which I failed to notice in my
review).

The "bz" in bzImage does not refer to the bzip compression algorithm.
Rather it refers to "big zImage". It's a historical thing because the
original zImage compressor was restricted to <1M (or something) of RAM
at decompression time and bzImage was introduced to cope with more and
therefore worked for larger kernels. Obviously 1M is very limiting to in
practice everyone uses bzImage today...

Now of course today, just to add to the confusion, bzImage can support
multiple compression algorithms, including the original z, but also
bzip2, lzma and xz.

Ian

> 
> Jan
> 
> > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > 
> > ---
> > Changed since v1:
> >   * add additional checks of the offset and length
> >   * not changing st.st_size, use size instead of st.st_size
> > 
> > diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> > --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> > +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> > @@ -18,6 +18,48 @@
> >  
> >  static xc_interface *xch;
> >  
> > +/* According to the implemation of xc_dom_probe_bzimage_kernel() function 
> > */
> > +/* We add support of bzImage kernel */
> > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > +struct setup_header {
> > +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > +	uint8_t  setup_sects;
> > +	uint16_t root_flags;
> > +	uint32_t syssize;
> > +	uint16_t ram_size;
> > +	uint16_t vid_mode;
> > +	uint16_t root_dev;
> > +	uint16_t boot_flag;
> > +	uint16_t jump;
> > +	uint32_t header;
> > +#define HDR_MAGIC  "HdrS"
> > +#define HDR_MAGIC_SZ 4
> > +	uint16_t version;
> > +#define VERSION(h,l) (((h)<<8) | (l))
> > +	uint32_t realmode_swtch;
> > +	uint16_t start_sys;
> > +	uint16_t kernel_version;
> > +	uint8_t  type_of_loader;
> > +	uint8_t  loadflags;
> > +	uint16_t setup_move_size;
> > +	uint32_t code32_start;
> > +	uint32_t ramdisk_image;
> > +	uint32_t ramdisk_size;
> > +	uint32_t bootsect_kludge;
> > +	uint16_t heap_end_ptr;
> > +	uint16_t _pad1;
> > +	uint32_t cmd_line_ptr;
> > +	uint32_t initrd_addr_max;
> > +	uint32_t kernel_alignment;
> > +	uint8_t  relocatable_kernel;
> > +	uint8_t  _pad2[3];
> > +	uint32_t cmdline_size;
> > +	uint32_t hardware_subarch;
> > +	uint64_t hardware_subarch_data;
> > +	uint32_t payload_offset;
> > +	uint32_t payload_length;
> > +} __attribute__((packed));
> > +
> >  static void print_string_note(const char *prefix, struct elf_binary *elf,
> >  			      const elf_note *note)
> >  {
> > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> >  	const elf_shdr *shdr;
> >  	int notes_found = 0;
> >  
> > +	struct setup_header *hdr;
> > +	uint64_t payload_offset, payload_length;
> > +
> >  	if (argc != 2)
> >  	{
> >  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > @@ -159,13 +204,45 @@ int main(int argc, char **argv)
> >  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> >  		return 1;
> >  	}
> > -	size = st.st_size;
> > +	
> > +	/* Check the magic of bzImage kernel */
> > +	hdr = (struct setup_header *)image;
> > +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> > +	{
> > +		if ( hdr->version < VERSION(2,8) )
> > +		{
> > +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> > +			return 1;
> > +		}
> >  
> > -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> > +		/* upcast to 64 bits to avoid overflow */
> > +		/* setup_sects is u8 and so cannot overflow */
> > +		payload_offset = (hdr->setup_sects + 1) * 512;
> > +		payload_offset += hdr->payload_offset;
> > +		payload_length = hdr->payload_length;
> > +		
> > +		if ( payload_offset >= st.st_size )
> > +		{
> > +			printf("%s: payload offset overflow", __FUNCTION__);
> > +			return 1;
> > +		}
> > +		if ( (payload_offset + payload_length) > st.st_size )
> > +		{
> > +			printf("%s: payload length overflow", __FUNCTION__);
> > +			return 1;
> > +		}
> > +
> > +		image = image + payload_offset;
> > +		size = payload_length;
> > +	} else {
> > +		size = st.st_size;
> > +	}
> > +
> > +	usize = xc_dom_check_gzip(xch, image, size);
> >  	if (usize)
> >  	{
> >  		tmp = malloc(usize);
> > -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> > +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
> >  		image = tmp;
> >  		size = usize;
> >  	}
> > 
> > This e-mail is intended solely for the person or entity to which it is 
> > addressed
> > and may contain confidential and/or privileged information. Any review, 
> > dissemination,
> > copying, printing or other use of this e-mail by persons or entities other 
> > than the 
> > addressee is prohibited. If you have received this e-mail in error, please 
> > contact
> > the sender immediately and delete the material from any computer.
> > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org 
> > http://lists.xen.org/xen-devel 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 09:40:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLBP-0003Jp-24; Thu, 26 Apr 2012 09:40:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SNLBN-0003Jh-23
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:40:13 +0000
Received: from [85.158.143.35:49325] by server-2.bemta-4.messagelabs.com id
	5F/DB-17550-CF7199F4; Thu, 26 Apr 2012 09:40:12 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335433210!8796648!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13814 invoked from network); 26 Apr 2012 09:40:11 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:40:11 -0000
Received: by eeit10 with SMTP id t10so559677eei.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 02:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=T/OojnYmKhCFMB+IhOtEWhC+2efq0IQ56yCc3Orxf58=;
	b=P7zTonER5pIvPRfokLf6ICLuRVDCo8x22NC8VHGvtL8+EPAis+9poAC6saIR4a7wjm
	woGC/Ks6BdHUyLgizUoCvh1y1xb4UcOtz4Dq53AQhZmKCQJvNRl0YzZYMhl7f3UQAtQ3
	4E7ENopRNgETmME90MKE3hP2ABPdEmmBB0uqOhd5T/yUMHSqXU7vOFeZ9SCWfwpC9K12
	BOPQIqSN3iNh6VhTddJPvRONAJQSGNGRbEN9i7RNOjJykK4OLjJMkPUwQi4ebFmOAR47
	oZYiGhJXw98GTFmjVN9IgQW/Wh0oIpFMzA1CDn+2ACi3ZoPOgkjm9GPxjl6gFT72uNzn
	v2Rw==
MIME-Version: 1.0
Received: by 10.14.94.193 with SMTP id n41mr1237095eef.27.1335433210271; Thu,
	26 Apr 2012 02:40:10 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Thu, 26 Apr 2012 02:40:10 -0700 (PDT)
In-Reply-To: <1335425428.4881.52.camel@dagon.hellion.org.uk>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
Date: Thu, 26 Apr 2012 11:40:10 +0200
Message-ID: <CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0065963226188844112=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0065963226188844112==
Content-Type: multipart/alternative; boundary=bcaec52be87d1e98a604be91c65e

--bcaec52be87d1e98a604be91c65e
Content-Type: text/plain; charset=ISO-8859-1

So this is now a different failure mode to the one which you originally
> reported (pygrub failed)?
>

I am not sure if it is a different fault.
It started with the bootloader: -3 error. In my search to find the possible
cause for this error, I found that there was a connection with the vif line
in my config file.
I have tried two different methods of starting the vm (one with pybrub and
the second without), and if my memory serves me right, removing the vif
from the config file resulted in the vm operating as it should.

With the bootloader = "/usr/bin/pygrub" line in the file, the vm boots if
the vif line is not there, and causes the bootloader: -3 error when the vif
line is present.
Without the bootloader line, using kernel, ramdisk and extra options, the
vm starts to boot. However, if the vif line is present, the install pauses
and stops at approximately 28 CPU seconds (in my case), which is midway
through its hardware detection procedure. The vm just stays in b state.
Without the vif line, the vm boots all the way without pausing at the 28
CPU seconds.


>
> What does your guest config look like now that you have resolved the
> pygrub issue?
>

* *I will send you the two different cfg files I have used, when I get home
later.


>
> Can you provide a full log of the failing boot with a vif enabled to the
> point of the hang?
>
>
Will do this later too.


> Are your hotplug scripts set up properly?
>

That I dont know, I have not dealt with these scripts yet since beginning
my 'adventures' with xen.
How do I know if they are correct, or if they need to be modified?


>
> What does "brctl show" say while the guest is running (with the vif
> enabled)?
>
> What does "xenstore-ls -fp" show while the guest is sat waiting?
>

I will also try get these outputs to you later.



I can only find oi-dev-151a-x86.iso and oi-dev-151a-text-x86.iso here
> (and the usb stick equivalents).
>

It is the oi-dev-151a-x86.iso. I just renamed it to shorten the name a bit.






So, what I am trying to determine is whether the vif problems I see are
related to the bootloader/pygrub error I get.

I get the feeling like there is something missing in my Debian Dom0;
libreries, some program(s) or something else. But I dont know what......

Thanks for your help so far in this matter, I appreciate the time you are
taking to do this.

Regards

Sandi

--bcaec52be87d1e98a604be91c65e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">So this is now a different failure mode to the one which =
you originally<br>

reported (pygrub failed)?<br></blockquote><div><br></div><div><div class=3D=
"gmail_extra">I am not sure if it is a different fault.</div><div class=3D"=
gmail_extra">It started with the bootloader: -3 error. In my search to find=
 the possible cause for this error, I found that there was a connection wit=
h the vif line in my config file.</div>
<div class=3D"gmail_extra">I have tried two different=A0methods=A0of starti=
ng the vm (one with pybrub and the second without), and if my memory serves=
 me right, removing the vif from the config file resulted in the vm operati=
ng as it should.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">With the bo=
otloader =3D &quot;/usr/bin/pygrub&quot; line in the file, the vm boots if =
the vif line is not there, and causes the bootloader: -3 error when the vif=
 line is present.</div>
<div class=3D"gmail_extra">Without the bootloader line, using kernel, ramdi=
sk and extra options, the vm starts to boot. However, if the vif line is pr=
esent, the install pauses and stops at=A0approximately=A028 CPU seconds (in=
 my case), which is midway through its hardware detection procedure. The vm=
 just stays in b state. Without the vif line, the vm boots all the way with=
out pausing at the 28 CPU seconds.</div>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What does your guest config look like now that you have resolved the<br>
pygrub issue?<br></blockquote><div><br></div><div><i>=A0</i>I will send you=
 the two different cfg files I have used, when I get home later.</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<br>
Can you provide a full log of the failing boot with a vif enabled to the<br=
>
point of the hang?<br>
<br></blockquote><div><br></div><div>Will do this later too.</div><div>=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
Are your hotplug scripts set up properly?<br></blockquote><div><br></div><d=
iv>That I dont know, I have not dealt with these scripts yet since beginnin=
g my &#39;adventures&#39; with xen.</div><div>How do I know if they are cor=
rect, or if they need to be modified?</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<br>
What does &quot;brctl show&quot; say while the guest is running (with the v=
if<br>
enabled)?<br>
<br>
What does &quot;xenstore-ls -fp&quot; show while the guest is sat waiting?<=
br></blockquote><div><br></div><div>I will also try get these outputs to yo=
u later.</div><div>=A0</div><div><br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
I can only find oi-dev-151a-x86.iso and oi-dev-151a-text-x86.iso here<br>
(and the usb stick equivalents).<br></blockquote><div>=A0</div><div>It is t=
he oi-dev-151a-x86.iso. I just renamed it to shorten the name a bit.=A0</di=
v><div><br></div><div><br></div><div><br></div><div>=A0</div></div></div><d=
iv class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">S=
o, what I am trying to determine is=A0whether=A0the vif problems I see are =
related to the bootloader/pygrub error I get.</div><div class=3D"gmail_extr=
a"><br>
</div><div class=3D"gmail_extra">I get the feeling like there is something =
missing in my Debian Dom0; libreries, some program(s) or something else. Bu=
t I dont know what......</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">
Thanks for your help so far in this matter, I=A0appreciate=A0the time you a=
re taking to do this.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Regards</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">
Sandi</div>

--bcaec52be87d1e98a604be91c65e--


--===============0065963226188844112==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0065963226188844112==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 09:40:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLBP-0003Jp-24; Thu, 26 Apr 2012 09:40:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SNLBN-0003Jh-23
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:40:13 +0000
Received: from [85.158.143.35:49325] by server-2.bemta-4.messagelabs.com id
	5F/DB-17550-CF7199F4; Thu, 26 Apr 2012 09:40:12 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335433210!8796648!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13814 invoked from network); 26 Apr 2012 09:40:11 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 09:40:11 -0000
Received: by eeit10 with SMTP id t10so559677eei.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 02:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=T/OojnYmKhCFMB+IhOtEWhC+2efq0IQ56yCc3Orxf58=;
	b=P7zTonER5pIvPRfokLf6ICLuRVDCo8x22NC8VHGvtL8+EPAis+9poAC6saIR4a7wjm
	woGC/Ks6BdHUyLgizUoCvh1y1xb4UcOtz4Dq53AQhZmKCQJvNRl0YzZYMhl7f3UQAtQ3
	4E7ENopRNgETmME90MKE3hP2ABPdEmmBB0uqOhd5T/yUMHSqXU7vOFeZ9SCWfwpC9K12
	BOPQIqSN3iNh6VhTddJPvRONAJQSGNGRbEN9i7RNOjJykK4OLjJMkPUwQi4ebFmOAR47
	oZYiGhJXw98GTFmjVN9IgQW/Wh0oIpFMzA1CDn+2ACi3ZoPOgkjm9GPxjl6gFT72uNzn
	v2Rw==
MIME-Version: 1.0
Received: by 10.14.94.193 with SMTP id n41mr1237095eef.27.1335433210271; Thu,
	26 Apr 2012 02:40:10 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Thu, 26 Apr 2012 02:40:10 -0700 (PDT)
In-Reply-To: <1335425428.4881.52.camel@dagon.hellion.org.uk>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
Date: Thu, 26 Apr 2012 11:40:10 +0200
Message-ID: <CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============0065963226188844112=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0065963226188844112==
Content-Type: multipart/alternative; boundary=bcaec52be87d1e98a604be91c65e

--bcaec52be87d1e98a604be91c65e
Content-Type: text/plain; charset=ISO-8859-1

So this is now a different failure mode to the one which you originally
> reported (pygrub failed)?
>

I am not sure if it is a different fault.
It started with the bootloader: -3 error. In my search to find the possible
cause for this error, I found that there was a connection with the vif line
in my config file.
I have tried two different methods of starting the vm (one with pybrub and
the second without), and if my memory serves me right, removing the vif
from the config file resulted in the vm operating as it should.

With the bootloader = "/usr/bin/pygrub" line in the file, the vm boots if
the vif line is not there, and causes the bootloader: -3 error when the vif
line is present.
Without the bootloader line, using kernel, ramdisk and extra options, the
vm starts to boot. However, if the vif line is present, the install pauses
and stops at approximately 28 CPU seconds (in my case), which is midway
through its hardware detection procedure. The vm just stays in b state.
Without the vif line, the vm boots all the way without pausing at the 28
CPU seconds.


>
> What does your guest config look like now that you have resolved the
> pygrub issue?
>

* *I will send you the two different cfg files I have used, when I get home
later.


>
> Can you provide a full log of the failing boot with a vif enabled to the
> point of the hang?
>
>
Will do this later too.


> Are your hotplug scripts set up properly?
>

That I dont know, I have not dealt with these scripts yet since beginning
my 'adventures' with xen.
How do I know if they are correct, or if they need to be modified?


>
> What does "brctl show" say while the guest is running (with the vif
> enabled)?
>
> What does "xenstore-ls -fp" show while the guest is sat waiting?
>

I will also try get these outputs to you later.



I can only find oi-dev-151a-x86.iso and oi-dev-151a-text-x86.iso here
> (and the usb stick equivalents).
>

It is the oi-dev-151a-x86.iso. I just renamed it to shorten the name a bit.






So, what I am trying to determine is whether the vif problems I see are
related to the bootloader/pygrub error I get.

I get the feeling like there is something missing in my Debian Dom0;
libreries, some program(s) or something else. But I dont know what......

Thanks for your help so far in this matter, I appreciate the time you are
taking to do this.

Regards

Sandi

--bcaec52be87d1e98a604be91c65e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">So this is now a different failure mode to the one which =
you originally<br>

reported (pygrub failed)?<br></blockquote><div><br></div><div><div class=3D=
"gmail_extra">I am not sure if it is a different fault.</div><div class=3D"=
gmail_extra">It started with the bootloader: -3 error. In my search to find=
 the possible cause for this error, I found that there was a connection wit=
h the vif line in my config file.</div>
<div class=3D"gmail_extra">I have tried two different=A0methods=A0of starti=
ng the vm (one with pybrub and the second without), and if my memory serves=
 me right, removing the vif from the config file resulted in the vm operati=
ng as it should.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">With the bo=
otloader =3D &quot;/usr/bin/pygrub&quot; line in the file, the vm boots if =
the vif line is not there, and causes the bootloader: -3 error when the vif=
 line is present.</div>
<div class=3D"gmail_extra">Without the bootloader line, using kernel, ramdi=
sk and extra options, the vm starts to boot. However, if the vif line is pr=
esent, the install pauses and stops at=A0approximately=A028 CPU seconds (in=
 my case), which is midway through its hardware detection procedure. The vm=
 just stays in b state. Without the vif line, the vm boots all the way with=
out pausing at the 28 CPU seconds.</div>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What does your guest config look like now that you have resolved the<br>
pygrub issue?<br></blockquote><div><br></div><div><i>=A0</i>I will send you=
 the two different cfg files I have used, when I get home later.</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<br>
Can you provide a full log of the failing boot with a vif enabled to the<br=
>
point of the hang?<br>
<br></blockquote><div><br></div><div>Will do this later too.</div><div>=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
Are your hotplug scripts set up properly?<br></blockquote><div><br></div><d=
iv>That I dont know, I have not dealt with these scripts yet since beginnin=
g my &#39;adventures&#39; with xen.</div><div>How do I know if they are cor=
rect, or if they need to be modified?</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<br>
What does &quot;brctl show&quot; say while the guest is running (with the v=
if<br>
enabled)?<br>
<br>
What does &quot;xenstore-ls -fp&quot; show while the guest is sat waiting?<=
br></blockquote><div><br></div><div>I will also try get these outputs to yo=
u later.</div><div>=A0</div><div><br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
I can only find oi-dev-151a-x86.iso and oi-dev-151a-text-x86.iso here<br>
(and the usb stick equivalents).<br></blockquote><div>=A0</div><div>It is t=
he oi-dev-151a-x86.iso. I just renamed it to shorten the name a bit.=A0</di=
v><div><br></div><div><br></div><div><br></div><div>=A0</div></div></div><d=
iv class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">S=
o, what I am trying to determine is=A0whether=A0the vif problems I see are =
related to the bootloader/pygrub error I get.</div><div class=3D"gmail_extr=
a"><br>
</div><div class=3D"gmail_extra">I get the feeling like there is something =
missing in my Debian Dom0; libreries, some program(s) or something else. Bu=
t I dont know what......</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">
Thanks for your help so far in this matter, I=A0appreciate=A0the time you a=
re taking to do this.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Regards</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">
Sandi</div>

--bcaec52be87d1e98a604be91c65e--


--===============0065963226188844112==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0065963226188844112==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 09:52:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLMw-0003Yt-FZ; Thu, 26 Apr 2012 09:52:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNLMv-0003Yj-7A
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:52:09 +0000
Received: from [85.158.143.99:46762] by server-3.bemta-4.messagelabs.com id
	85/A8-05853-7CA199F4; Thu, 26 Apr 2012 09:52:07 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335433926!18981120!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTMyNzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10368 invoked from network); 26 Apr 2012 09:52:07 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 09:52:07 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Thu, 26 Apr
	2012 05:52:04 -0400
Received: from HCAZUSCH2.hitachiconsulting.net (172.16.1.120) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 04:52:02 -0500
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 04:52:01 -0500
Received: from [10.67.7.194] (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 15:20:54 +0530
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335432002.28015.78.camel@zakaz.uk.xensource.com>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
	<1335432002.28015.78.camel@zakaz.uk.xensource.com>
Organization: Sierra Atlantic
Date: Thu, 26 Apr 2012 17:51:11 +0800
Message-ID: <1335433871.4742.18.camel@goosenl-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042605520500201
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Xuesen.Guo@hitachiconsulting.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3467935560755890166=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3467935560755890166==
Content-Type: multipart/alternative; boundary="=-aZaC9Ufja/c88rSEtweD"

--=-aZaC9Ufja/c88rSEtweD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I fixed the confusion, shall I need to resend this patch?
------------------------------------------------------------------------
readnote: Add bzImage kernel support

Add the check of bzImage kernel and make it work
with RHEL 6 big zImage kernel

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
Changed since v1:
  * add additional checks of the offset and length
  * not changing st.st_size, use size instead of st.st_size
 =20
---
Changed since v2:
  * changing decription bzipped kernels to big zImage kernel


Thanks!
Xuesen=20

On Thu, 2012-04-26 at 10:20 +0100, Ian Campbell wrote:

> On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
> > >>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>=
 wrote:
> > > Add the check of bzImage kernel and make it work
> > > with RHEL 6 bzipped kernels
> >=20
> > I fail to see the relation of the term "bzipped" above to the actual pa=
tch.
>=20
> Oh yes, this is a common misconception (which I failed to notice in my
> review).
>=20
> The "bz" in bzImage does not refer to the bzip compression algorithm.
> Rather it refers to "big zImage". It's a historical thing because the
> original zImage compressor was restricted to <1M (or something) of RAM
> at decompression time and bzImage was introduced to cope with more and
> therefore worked for larger kernels. Obviously 1M is very limiting to in
> practice everyone uses bzImage today...
>=20
> Now of course today, just to add to the confusion, bzImage can support
> multiple compression algorithms, including the original z, but also
> bzip2, lzma and xz.
>=20
> Ian
>=20
> >=20
> > Jan
> >=20
> > > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > >=20
> > > ---
> > > Changed since v1:
> > >   * add additional checks of the offset and length
> > >   * not changing st.st_size, use size instead of st.st_size
> > >=20
> > > diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> > > --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
> > > +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 16:53:17 2012 +0800
> > > @@ -18,6 +18,48 @@
> > > =20
> > >  static xc_interface *xch;
> > > =20
> > > +/* According to the implemation of xc_dom_probe_bzimage_kernel() fun=
ction=20
> > > */
> > > +/* We add support of bzImage kernel */
> > > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > > +struct setup_header {
> > > +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > > +=09uint8_t  setup_sects;
> > > +=09uint16_t root_flags;
> > > +=09uint32_t syssize;
> > > +=09uint16_t ram_size;
> > > +=09uint16_t vid_mode;
> > > +=09uint16_t root_dev;
> > > +=09uint16_t boot_flag;
> > > +=09uint16_t jump;
> > > +=09uint32_t header;
> > > +#define HDR_MAGIC  "HdrS"
> > > +#define HDR_MAGIC_SZ 4
> > > +=09uint16_t version;
> > > +#define VERSION(h,l) (((h)<<8) | (l))
> > > +=09uint32_t realmode_swtch;
> > > +=09uint16_t start_sys;
> > > +=09uint16_t kernel_version;
> > > +=09uint8_t  type_of_loader;
> > > +=09uint8_t  loadflags;
> > > +=09uint16_t setup_move_size;
> > > +=09uint32_t code32_start;
> > > +=09uint32_t ramdisk_image;
> > > +=09uint32_t ramdisk_size;
> > > +=09uint32_t bootsect_kludge;
> > > +=09uint16_t heap_end_ptr;
> > > +=09uint16_t _pad1;
> > > +=09uint32_t cmd_line_ptr;
> > > +=09uint32_t initrd_addr_max;
> > > +=09uint32_t kernel_alignment;
> > > +=09uint8_t  relocatable_kernel;
> > > +=09uint8_t  _pad2[3];
> > > +=09uint32_t cmdline_size;
> > > +=09uint32_t hardware_subarch;
> > > +=09uint64_t hardware_subarch_data;
> > > +=09uint32_t payload_offset;
> > > +=09uint32_t payload_length;
> > > +} __attribute__((packed));
> > > +
> > >  static void print_string_note(const char *prefix, struct elf_binary =
*elf,
> > >  =09=09=09      const elf_note *note)
> > >  {
> > > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> > >  =09const elf_shdr *shdr;
> > >  =09int notes_found =3D 0;
> > > =20
> > > +=09struct setup_header *hdr;
> > > +=09uint64_t payload_offset, payload_length;
> > > +
> > >  =09if (argc !=3D 2)
> > >  =09{
> > >  =09=09fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > > @@ -159,13 +204,45 @@ int main(int argc, char **argv)
> > >  =09=09fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> > >  =09=09return 1;
> > >  =09}
> > > -=09size =3D st.st_size;
> > > +=09
> > > +=09/* Check the magic of bzImage kernel */
> > > +=09hdr =3D (struct setup_header *)image;
> > > +=09if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=3D 0 )
> > > +=09{
> > > +=09=09if ( hdr->version < VERSION(2,8) )
> > > +=09=09{
> > > +=09=09=09printf("%s: boot protocol too old (%04x)", __FUNCTION__, hd=
r->version);
> > > +=09=09=09return 1;
> > > +=09=09}
> > > =20
> > > -=09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
> > > +=09=09/* upcast to 64 bits to avoid overflow */
> > > +=09=09/* setup_sects is u8 and so cannot overflow */
> > > +=09=09payload_offset =3D (hdr->setup_sects + 1) * 512;
> > > +=09=09payload_offset +=3D hdr->payload_offset;
> > > +=09=09payload_length =3D hdr->payload_length;
> > > +=09=09
> > > +=09=09if ( payload_offset >=3D st.st_size )
> > > +=09=09{
> > > +=09=09=09printf("%s: payload offset overflow", __FUNCTION__);
> > > +=09=09=09return 1;
> > > +=09=09}
> > > +=09=09if ( (payload_offset + payload_length) > st.st_size )
> > > +=09=09{
> > > +=09=09=09printf("%s: payload length overflow", __FUNCTION__);
> > > +=09=09=09return 1;
> > > +=09=09}
> > > +
> > > +=09=09image =3D image + payload_offset;
> > > +=09=09size =3D payload_length;
> > > +=09} else {
> > > +=09=09size =3D st.st_size;
> > > +=09}
> > > +
> > > +=09usize =3D xc_dom_check_gzip(xch, image, size);
> > >  =09if (usize)
> > >  =09{
> > >  =09=09tmp =3D malloc(usize);
> > > -=09=09xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> > > +=09=09xc_dom_do_gunzip(xch, image, size, tmp, usize);
> > >  =09=09image =3D tmp;
> > >  =09=09size =3D usize;
> > >  =09}
> > >=20
> > > This e-mail is intended solely for the person or entity to which it i=
s=20
> > > addressed
> > > and may contain confidential and/or privileged information. Any revie=
w,=20
> > > dissemination,
> > > copying, printing or other use of this e-mail by persons or entities =
other=20
> > > than the=20
> > > addressee is prohibited. If you have received this e-mail in error, p=
lease=20
> > > contact
> > > the sender immediately and delete the material from any computer.
> > > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com=20
> > > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> > >=20
> > >=20
> > >=20
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org=20
> > > http://lists.xen.org/xen-devel=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>=20
>=20
>=20


--=-aZaC9Ufja/c88rSEtweD
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.32.2">
</HEAD>
<BODY>
I fixed the confusion, shall I need to resend this patch?<BR>
------------------------------------------------------------------------<BR=
>
readnote: Add bzImage kernel support<BR>
<BR>
Add the check of bzImage kernel and make it work<BR>
with RHEL 6 big zImage kernel<BR>
<BR>
Signed-off-by: Xuesen Guo &lt;<A HREF=3D"mailto:Xuesen.Guo@hitachiconsultin=
g.com">Xuesen.Guo@hitachiconsulting.com</A>&gt;<BR>
Acked-by: Ian Campbell &lt;<A HREF=3D"mailto:ian.campbell@citrix.com">ian.c=
ampbell@citrix.com</A>&gt;<BR>
<BR>
---<BR>
Changed since v1:<BR>
&nbsp; * add additional checks of the offset and length<BR>
&nbsp; * not changing st.st_size, use size instead of st.st_size<BR>
&nbsp; <BR>
---<BR>
Changed since v2:<BR>
&nbsp; * changing decription bzipped kernels to big zImage kernel<BR>
<BR>
<BR>
Thanks!<BR>
Xuesen <BR>
<BR>
On Thu, 2012-04-26 at 10:20 +0100, Ian Campbell wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
&gt; &gt;&gt;&gt; On 26.04.12 at 10:54, Xuesen Guo &lt;<A HREF=3D"mailto:Xu=
esen.Guo@hitachiconsulting.com">Xuesen.Guo@hitachiconsulting.com</A>&gt; wr=
ote:
&gt; &gt; Add the check of bzImage kernel and make it work
&gt; &gt; with RHEL 6 bzipped kernels
&gt;=20
&gt; I fail to see the relation of the term &quot;bzipped&quot; above to th=
e actual patch.

Oh yes, this is a common misconception (which I failed to notice in my
review).

The &quot;bz&quot; in bzImage does not refer to the bzip compression algori=
thm.
Rather it refers to &quot;big zImage&quot;. It's a historical thing because=
 the
original zImage compressor was restricted to &lt;1M (or something) of RAM
at decompression time and bzImage was introduced to cope with more and
therefore worked for larger kernels. Obviously 1M is very limiting to in
practice everyone uses bzImage today...

Now of course today, just to add to the confusion, bzImage can support
multiple compression algorithms, including the original z, but also
bzip2, lzma and xz.

Ian

&gt;=20
&gt; Jan
&gt;=20
&gt; &gt; Signed-off-by: Xuesen Guo &lt;<A HREF=3D"mailto:Xuesen.Guo@hitach=
iconsulting.com">Xuesen.Guo@hitachiconsulting.com</A>&gt;
&gt; &gt;=20
&gt; &gt; ---
&gt; &gt; Changed since v1:
&gt; &gt;   * add additional checks of the offset and length
&gt; &gt;   * not changing st.st_size, use size instead of st.st_size
&gt; &gt;=20
&gt; &gt; diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
&gt; &gt; --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
&gt; &gt; +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 16:53:17 2012 +0800
&gt; &gt; @@ -18,6 +18,48 @@
&gt; &gt; =20
&gt; &gt;  static xc_interface *xch;
&gt; &gt; =20
&gt; &gt; +/* According to the implemation of xc_dom_probe_bzimage_kernel()=
 function=20
&gt; &gt; */
&gt; &gt; +/* We add support of bzImage kernel */
&gt; &gt; +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
&gt; &gt; +struct setup_header {
&gt; &gt; +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
&gt; &gt; +=09uint8_t  setup_sects;
&gt; &gt; +=09uint16_t root_flags;
&gt; &gt; +=09uint32_t syssize;
&gt; &gt; +=09uint16_t ram_size;
&gt; &gt; +=09uint16_t vid_mode;
&gt; &gt; +=09uint16_t root_dev;
&gt; &gt; +=09uint16_t boot_flag;
&gt; &gt; +=09uint16_t jump;
&gt; &gt; +=09uint32_t header;
&gt; &gt; +#define HDR_MAGIC  &quot;HdrS&quot;
&gt; &gt; +#define HDR_MAGIC_SZ 4
&gt; &gt; +=09uint16_t version;
&gt; &gt; +#define VERSION(h,l) (((h)&lt;&lt;8) | (l))
&gt; &gt; +=09uint32_t realmode_swtch;
&gt; &gt; +=09uint16_t start_sys;
&gt; &gt; +=09uint16_t kernel_version;
&gt; &gt; +=09uint8_t  type_of_loader;
&gt; &gt; +=09uint8_t  loadflags;
&gt; &gt; +=09uint16_t setup_move_size;
&gt; &gt; +=09uint32_t code32_start;
&gt; &gt; +=09uint32_t ramdisk_image;
&gt; &gt; +=09uint32_t ramdisk_size;
&gt; &gt; +=09uint32_t bootsect_kludge;
&gt; &gt; +=09uint16_t heap_end_ptr;
&gt; &gt; +=09uint16_t _pad1;
&gt; &gt; +=09uint32_t cmd_line_ptr;
&gt; &gt; +=09uint32_t initrd_addr_max;
&gt; &gt; +=09uint32_t kernel_alignment;
&gt; &gt; +=09uint8_t  relocatable_kernel;
&gt; &gt; +=09uint8_t  _pad2[3];
&gt; &gt; +=09uint32_t cmdline_size;
&gt; &gt; +=09uint32_t hardware_subarch;
&gt; &gt; +=09uint64_t hardware_subarch_data;
&gt; &gt; +=09uint32_t payload_offset;
&gt; &gt; +=09uint32_t payload_length;
&gt; &gt; +} __attribute__((packed));
&gt; &gt; +
&gt; &gt;  static void print_string_note(const char *prefix, struct elf_bin=
ary *elf,
&gt; &gt;  =09=09=09      const elf_note *note)
&gt; &gt;  {
&gt; &gt; @@ -131,6 +173,9 @@ int main(int argc, char **argv)
&gt; &gt;  =09const elf_shdr *shdr;
&gt; &gt;  =09int notes_found =3D 0;
&gt; &gt; =20
&gt; &gt; +=09struct setup_header *hdr;
&gt; &gt; +=09uint64_t payload_offset, payload_length;
&gt; &gt; +
&gt; &gt;  =09if (argc !=3D 2)
&gt; &gt;  =09{
&gt; &gt;  =09=09fprintf(stderr, &quot;Usage: readnotes &lt;elfimage&gt;\n&=
quot;);
&gt; &gt; @@ -159,13 +204,45 @@ int main(int argc, char **argv)
&gt; &gt;  =09=09fprintf(stderr, &quot;Unable to map %s: %s\n&quot;, f, str=
error(errno));
&gt; &gt;  =09=09return 1;
&gt; &gt;  =09}
&gt; &gt; -=09size =3D st.st_size;
&gt; &gt; +=09
&gt; &gt; +=09/* Check the magic of bzImage kernel */
&gt; &gt; +=09hdr =3D (struct setup_header *)image;
&gt; &gt; +=09if ( memcmp(&amp;hdr-&gt;header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=
=3D 0 )
&gt; &gt; +=09{
&gt; &gt; +=09=09if ( hdr-&gt;version &lt; VERSION(2,8) )
&gt; &gt; +=09=09{
&gt; &gt; +=09=09=09printf(&quot;%s: boot protocol too old (%04x)&quot;, __=
FUNCTION__, hdr-&gt;version);
&gt; &gt; +=09=09=09return 1;
&gt; &gt; +=09=09}
&gt; &gt; =20
&gt; &gt; -=09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
&gt; &gt; +=09=09/* upcast to 64 bits to avoid overflow */
&gt; &gt; +=09=09/* setup_sects is u8 and so cannot overflow */
&gt; &gt; +=09=09payload_offset =3D (hdr-&gt;setup_sects + 1) * 512;
&gt; &gt; +=09=09payload_offset +=3D hdr-&gt;payload_offset;
&gt; &gt; +=09=09payload_length =3D hdr-&gt;payload_length;
&gt; &gt; +=09=09
&gt; &gt; +=09=09if ( payload_offset &gt;=3D st.st_size )
&gt; &gt; +=09=09{
&gt; &gt; +=09=09=09printf(&quot;%s: payload offset overflow&quot;, __FUNCT=
ION__);
&gt; &gt; +=09=09=09return 1;
&gt; &gt; +=09=09}
&gt; &gt; +=09=09if ( (payload_offset + payload_length) &gt; st.st_size )
&gt; &gt; +=09=09{
&gt; &gt; +=09=09=09printf(&quot;%s: payload length overflow&quot;, __FUNCT=
ION__);
&gt; &gt; +=09=09=09return 1;
&gt; &gt; +=09=09}
&gt; &gt; +
&gt; &gt; +=09=09image =3D image + payload_offset;
&gt; &gt; +=09=09size =3D payload_length;
&gt; &gt; +=09} else {
&gt; &gt; +=09=09size =3D st.st_size;
&gt; &gt; +=09}
&gt; &gt; +
&gt; &gt; +=09usize =3D xc_dom_check_gzip(xch, image, size);
&gt; &gt;  =09if (usize)
&gt; &gt;  =09{
&gt; &gt;  =09=09tmp =3D malloc(usize);
&gt; &gt; -=09=09xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
&gt; &gt; +=09=09xc_dom_do_gunzip(xch, image, size, tmp, usize);
&gt; &gt;  =09=09image =3D tmp;
&gt; &gt;  =09=09size =3D usize;
&gt; &gt;  =09}
&gt; &gt;=20
&gt; &gt; This e-mail is intended solely for the person or entity to which =
it is=20
&gt; &gt; addressed
&gt; &gt; and may contain confidential and/or privileged information. Any r=
eview,=20
&gt; &gt; dissemination,
&gt; &gt; copying, printing or other use of this e-mail by persons or entit=
ies other=20
&gt; &gt; than the=20
&gt; &gt; addressee is prohibited. If you have received this e-mail in erro=
r, please=20
&gt; &gt; contact
&gt; &gt; the sender immediately and delete the material from any computer.
&gt; &gt; To unsubscribe send an email to: <A HREF=3D"mailto:Unsubscribe@hi=
tachiconsulting.com">Unsubscribe@hitachiconsulting.com</A>=20
&gt; &gt; Hitachi Consulting (China) Co., Ltd. (HCCD0411)
&gt; &gt;=20
&gt; &gt;=20
&gt; &gt;=20
&gt; &gt; _______________________________________________
&gt; &gt; Xen-devel mailing list
&gt; &gt; <A HREF=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.or=
g</A>=20
&gt; &gt; <A HREF=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/x=
en-devel</A>=20
&gt;=20
&gt;=20
&gt;=20
&gt; _______________________________________________
&gt; Xen-devel mailing list
&gt; <A HREF=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</A>
&gt; <A HREF=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</A>



</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>
--=-aZaC9Ufja/c88rSEtweD--



--===============3467935560755890166==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3467935560755890166==--



From xen-devel-bounces@lists.xen.org Thu Apr 26 09:52:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 09:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLMw-0003Yt-FZ; Thu, 26 Apr 2012 09:52:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNLMv-0003Yj-7A
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 09:52:09 +0000
Received: from [85.158.143.99:46762] by server-3.bemta-4.messagelabs.com id
	85/A8-05853-7CA199F4; Thu, 26 Apr 2012 09:52:07 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335433926!18981120!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTMyNzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10368 invoked from network); 26 Apr 2012 09:52:07 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 09:52:07 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Thu, 26 Apr
	2012 05:52:04 -0400
Received: from HCAZUSCH2.hitachiconsulting.net (172.16.1.120) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 04:52:02 -0500
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 04:52:01 -0500
Received: from [10.67.7.194] (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Thu, 26 Apr 2012 15:20:54 +0530
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335432002.28015.78.camel@zakaz.uk.xensource.com>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
	<1335432002.28015.78.camel@zakaz.uk.xensource.com>
Organization: Sierra Atlantic
Date: Thu, 26 Apr 2012 17:51:11 +0800
Message-ID: <1335433871.4742.18.camel@goosenl-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042605520500201
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Xuesen.Guo@hitachiconsulting.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3467935560755890166=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3467935560755890166==
Content-Type: multipart/alternative; boundary="=-aZaC9Ufja/c88rSEtweD"

--=-aZaC9Ufja/c88rSEtweD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I fixed the confusion, shall I need to resend this patch?
------------------------------------------------------------------------
readnote: Add bzImage kernel support

Add the check of bzImage kernel and make it work
with RHEL 6 big zImage kernel

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
Changed since v1:
  * add additional checks of the offset and length
  * not changing st.st_size, use size instead of st.st_size
 =20
---
Changed since v2:
  * changing decription bzipped kernels to big zImage kernel


Thanks!
Xuesen=20

On Thu, 2012-04-26 at 10:20 +0100, Ian Campbell wrote:

> On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
> > >>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>=
 wrote:
> > > Add the check of bzImage kernel and make it work
> > > with RHEL 6 bzipped kernels
> >=20
> > I fail to see the relation of the term "bzipped" above to the actual pa=
tch.
>=20
> Oh yes, this is a common misconception (which I failed to notice in my
> review).
>=20
> The "bz" in bzImage does not refer to the bzip compression algorithm.
> Rather it refers to "big zImage". It's a historical thing because the
> original zImage compressor was restricted to <1M (or something) of RAM
> at decompression time and bzImage was introduced to cope with more and
> therefore worked for larger kernels. Obviously 1M is very limiting to in
> practice everyone uses bzImage today...
>=20
> Now of course today, just to add to the confusion, bzImage can support
> multiple compression algorithms, including the original z, but also
> bzip2, lzma and xz.
>=20
> Ian
>=20
> >=20
> > Jan
> >=20
> > > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > >=20
> > > ---
> > > Changed since v1:
> > >   * add additional checks of the offset and length
> > >   * not changing st.st_size, use size instead of st.st_size
> > >=20
> > > diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> > > --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
> > > +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 16:53:17 2012 +0800
> > > @@ -18,6 +18,48 @@
> > > =20
> > >  static xc_interface *xch;
> > > =20
> > > +/* According to the implemation of xc_dom_probe_bzimage_kernel() fun=
ction=20
> > > */
> > > +/* We add support of bzImage kernel */
> > > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > > +struct setup_header {
> > > +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > > +=09uint8_t  setup_sects;
> > > +=09uint16_t root_flags;
> > > +=09uint32_t syssize;
> > > +=09uint16_t ram_size;
> > > +=09uint16_t vid_mode;
> > > +=09uint16_t root_dev;
> > > +=09uint16_t boot_flag;
> > > +=09uint16_t jump;
> > > +=09uint32_t header;
> > > +#define HDR_MAGIC  "HdrS"
> > > +#define HDR_MAGIC_SZ 4
> > > +=09uint16_t version;
> > > +#define VERSION(h,l) (((h)<<8) | (l))
> > > +=09uint32_t realmode_swtch;
> > > +=09uint16_t start_sys;
> > > +=09uint16_t kernel_version;
> > > +=09uint8_t  type_of_loader;
> > > +=09uint8_t  loadflags;
> > > +=09uint16_t setup_move_size;
> > > +=09uint32_t code32_start;
> > > +=09uint32_t ramdisk_image;
> > > +=09uint32_t ramdisk_size;
> > > +=09uint32_t bootsect_kludge;
> > > +=09uint16_t heap_end_ptr;
> > > +=09uint16_t _pad1;
> > > +=09uint32_t cmd_line_ptr;
> > > +=09uint32_t initrd_addr_max;
> > > +=09uint32_t kernel_alignment;
> > > +=09uint8_t  relocatable_kernel;
> > > +=09uint8_t  _pad2[3];
> > > +=09uint32_t cmdline_size;
> > > +=09uint32_t hardware_subarch;
> > > +=09uint64_t hardware_subarch_data;
> > > +=09uint32_t payload_offset;
> > > +=09uint32_t payload_length;
> > > +} __attribute__((packed));
> > > +
> > >  static void print_string_note(const char *prefix, struct elf_binary =
*elf,
> > >  =09=09=09      const elf_note *note)
> > >  {
> > > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> > >  =09const elf_shdr *shdr;
> > >  =09int notes_found =3D 0;
> > > =20
> > > +=09struct setup_header *hdr;
> > > +=09uint64_t payload_offset, payload_length;
> > > +
> > >  =09if (argc !=3D 2)
> > >  =09{
> > >  =09=09fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > > @@ -159,13 +204,45 @@ int main(int argc, char **argv)
> > >  =09=09fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> > >  =09=09return 1;
> > >  =09}
> > > -=09size =3D st.st_size;
> > > +=09
> > > +=09/* Check the magic of bzImage kernel */
> > > +=09hdr =3D (struct setup_header *)image;
> > > +=09if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=3D 0 )
> > > +=09{
> > > +=09=09if ( hdr->version < VERSION(2,8) )
> > > +=09=09{
> > > +=09=09=09printf("%s: boot protocol too old (%04x)", __FUNCTION__, hd=
r->version);
> > > +=09=09=09return 1;
> > > +=09=09}
> > > =20
> > > -=09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
> > > +=09=09/* upcast to 64 bits to avoid overflow */
> > > +=09=09/* setup_sects is u8 and so cannot overflow */
> > > +=09=09payload_offset =3D (hdr->setup_sects + 1) * 512;
> > > +=09=09payload_offset +=3D hdr->payload_offset;
> > > +=09=09payload_length =3D hdr->payload_length;
> > > +=09=09
> > > +=09=09if ( payload_offset >=3D st.st_size )
> > > +=09=09{
> > > +=09=09=09printf("%s: payload offset overflow", __FUNCTION__);
> > > +=09=09=09return 1;
> > > +=09=09}
> > > +=09=09if ( (payload_offset + payload_length) > st.st_size )
> > > +=09=09{
> > > +=09=09=09printf("%s: payload length overflow", __FUNCTION__);
> > > +=09=09=09return 1;
> > > +=09=09}
> > > +
> > > +=09=09image =3D image + payload_offset;
> > > +=09=09size =3D payload_length;
> > > +=09} else {
> > > +=09=09size =3D st.st_size;
> > > +=09}
> > > +
> > > +=09usize =3D xc_dom_check_gzip(xch, image, size);
> > >  =09if (usize)
> > >  =09{
> > >  =09=09tmp =3D malloc(usize);
> > > -=09=09xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> > > +=09=09xc_dom_do_gunzip(xch, image, size, tmp, usize);
> > >  =09=09image =3D tmp;
> > >  =09=09size =3D usize;
> > >  =09}
> > >=20
> > > This e-mail is intended solely for the person or entity to which it i=
s=20
> > > addressed
> > > and may contain confidential and/or privileged information. Any revie=
w,=20
> > > dissemination,
> > > copying, printing or other use of this e-mail by persons or entities =
other=20
> > > than the=20
> > > addressee is prohibited. If you have received this e-mail in error, p=
lease=20
> > > contact
> > > the sender immediately and delete the material from any computer.
> > > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com=20
> > > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> > >=20
> > >=20
> > >=20
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org=20
> > > http://lists.xen.org/xen-devel=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>=20
>=20
>=20


--=-aZaC9Ufja/c88rSEtweD
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.32.2">
</HEAD>
<BODY>
I fixed the confusion, shall I need to resend this patch?<BR>
------------------------------------------------------------------------<BR=
>
readnote: Add bzImage kernel support<BR>
<BR>
Add the check of bzImage kernel and make it work<BR>
with RHEL 6 big zImage kernel<BR>
<BR>
Signed-off-by: Xuesen Guo &lt;<A HREF=3D"mailto:Xuesen.Guo@hitachiconsultin=
g.com">Xuesen.Guo@hitachiconsulting.com</A>&gt;<BR>
Acked-by: Ian Campbell &lt;<A HREF=3D"mailto:ian.campbell@citrix.com">ian.c=
ampbell@citrix.com</A>&gt;<BR>
<BR>
---<BR>
Changed since v1:<BR>
&nbsp; * add additional checks of the offset and length<BR>
&nbsp; * not changing st.st_size, use size instead of st.st_size<BR>
&nbsp; <BR>
---<BR>
Changed since v2:<BR>
&nbsp; * changing decription bzipped kernels to big zImage kernel<BR>
<BR>
<BR>
Thanks!<BR>
Xuesen <BR>
<BR>
On Thu, 2012-04-26 at 10:20 +0100, Ian Campbell wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
&gt; &gt;&gt;&gt; On 26.04.12 at 10:54, Xuesen Guo &lt;<A HREF=3D"mailto:Xu=
esen.Guo@hitachiconsulting.com">Xuesen.Guo@hitachiconsulting.com</A>&gt; wr=
ote:
&gt; &gt; Add the check of bzImage kernel and make it work
&gt; &gt; with RHEL 6 bzipped kernels
&gt;=20
&gt; I fail to see the relation of the term &quot;bzipped&quot; above to th=
e actual patch.

Oh yes, this is a common misconception (which I failed to notice in my
review).

The &quot;bz&quot; in bzImage does not refer to the bzip compression algori=
thm.
Rather it refers to &quot;big zImage&quot;. It's a historical thing because=
 the
original zImage compressor was restricted to &lt;1M (or something) of RAM
at decompression time and bzImage was introduced to cope with more and
therefore worked for larger kernels. Obviously 1M is very limiting to in
practice everyone uses bzImage today...

Now of course today, just to add to the confusion, bzImage can support
multiple compression algorithms, including the original z, but also
bzip2, lzma and xz.

Ian

&gt;=20
&gt; Jan
&gt;=20
&gt; &gt; Signed-off-by: Xuesen Guo &lt;<A HREF=3D"mailto:Xuesen.Guo@hitach=
iconsulting.com">Xuesen.Guo@hitachiconsulting.com</A>&gt;
&gt; &gt;=20
&gt; &gt; ---
&gt; &gt; Changed since v1:
&gt; &gt;   * add additional checks of the offset and length
&gt; &gt;   * not changing st.st_size, use size instead of st.st_size
&gt; &gt;=20
&gt; &gt; diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
&gt; &gt; --- a/tools/xcutils/readnotes.c=09Thu Apr 05 11:06:03 2012 +0100
&gt; &gt; +++ b/tools/xcutils/readnotes.c=09Thu Apr 26 16:53:17 2012 +0800
&gt; &gt; @@ -18,6 +18,48 @@
&gt; &gt; =20
&gt; &gt;  static xc_interface *xch;
&gt; &gt; =20
&gt; &gt; +/* According to the implemation of xc_dom_probe_bzimage_kernel()=
 function=20
&gt; &gt; */
&gt; &gt; +/* We add support of bzImage kernel */
&gt; &gt; +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
&gt; &gt; +struct setup_header {
&gt; &gt; +=09uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
&gt; &gt; +=09uint8_t  setup_sects;
&gt; &gt; +=09uint16_t root_flags;
&gt; &gt; +=09uint32_t syssize;
&gt; &gt; +=09uint16_t ram_size;
&gt; &gt; +=09uint16_t vid_mode;
&gt; &gt; +=09uint16_t root_dev;
&gt; &gt; +=09uint16_t boot_flag;
&gt; &gt; +=09uint16_t jump;
&gt; &gt; +=09uint32_t header;
&gt; &gt; +#define HDR_MAGIC  &quot;HdrS&quot;
&gt; &gt; +#define HDR_MAGIC_SZ 4
&gt; &gt; +=09uint16_t version;
&gt; &gt; +#define VERSION(h,l) (((h)&lt;&lt;8) | (l))
&gt; &gt; +=09uint32_t realmode_swtch;
&gt; &gt; +=09uint16_t start_sys;
&gt; &gt; +=09uint16_t kernel_version;
&gt; &gt; +=09uint8_t  type_of_loader;
&gt; &gt; +=09uint8_t  loadflags;
&gt; &gt; +=09uint16_t setup_move_size;
&gt; &gt; +=09uint32_t code32_start;
&gt; &gt; +=09uint32_t ramdisk_image;
&gt; &gt; +=09uint32_t ramdisk_size;
&gt; &gt; +=09uint32_t bootsect_kludge;
&gt; &gt; +=09uint16_t heap_end_ptr;
&gt; &gt; +=09uint16_t _pad1;
&gt; &gt; +=09uint32_t cmd_line_ptr;
&gt; &gt; +=09uint32_t initrd_addr_max;
&gt; &gt; +=09uint32_t kernel_alignment;
&gt; &gt; +=09uint8_t  relocatable_kernel;
&gt; &gt; +=09uint8_t  _pad2[3];
&gt; &gt; +=09uint32_t cmdline_size;
&gt; &gt; +=09uint32_t hardware_subarch;
&gt; &gt; +=09uint64_t hardware_subarch_data;
&gt; &gt; +=09uint32_t payload_offset;
&gt; &gt; +=09uint32_t payload_length;
&gt; &gt; +} __attribute__((packed));
&gt; &gt; +
&gt; &gt;  static void print_string_note(const char *prefix, struct elf_bin=
ary *elf,
&gt; &gt;  =09=09=09      const elf_note *note)
&gt; &gt;  {
&gt; &gt; @@ -131,6 +173,9 @@ int main(int argc, char **argv)
&gt; &gt;  =09const elf_shdr *shdr;
&gt; &gt;  =09int notes_found =3D 0;
&gt; &gt; =20
&gt; &gt; +=09struct setup_header *hdr;
&gt; &gt; +=09uint64_t payload_offset, payload_length;
&gt; &gt; +
&gt; &gt;  =09if (argc !=3D 2)
&gt; &gt;  =09{
&gt; &gt;  =09=09fprintf(stderr, &quot;Usage: readnotes &lt;elfimage&gt;\n&=
quot;);
&gt; &gt; @@ -159,13 +204,45 @@ int main(int argc, char **argv)
&gt; &gt;  =09=09fprintf(stderr, &quot;Unable to map %s: %s\n&quot;, f, str=
error(errno));
&gt; &gt;  =09=09return 1;
&gt; &gt;  =09}
&gt; &gt; -=09size =3D st.st_size;
&gt; &gt; +=09
&gt; &gt; +=09/* Check the magic of bzImage kernel */
&gt; &gt; +=09hdr =3D (struct setup_header *)image;
&gt; &gt; +=09if ( memcmp(&amp;hdr-&gt;header, HDR_MAGIC, HDR_MAGIC_SZ) =3D=
=3D 0 )
&gt; &gt; +=09{
&gt; &gt; +=09=09if ( hdr-&gt;version &lt; VERSION(2,8) )
&gt; &gt; +=09=09{
&gt; &gt; +=09=09=09printf(&quot;%s: boot protocol too old (%04x)&quot;, __=
FUNCTION__, hdr-&gt;version);
&gt; &gt; +=09=09=09return 1;
&gt; &gt; +=09=09}
&gt; &gt; =20
&gt; &gt; -=09usize =3D xc_dom_check_gzip(xch, image, st.st_size);
&gt; &gt; +=09=09/* upcast to 64 bits to avoid overflow */
&gt; &gt; +=09=09/* setup_sects is u8 and so cannot overflow */
&gt; &gt; +=09=09payload_offset =3D (hdr-&gt;setup_sects + 1) * 512;
&gt; &gt; +=09=09payload_offset +=3D hdr-&gt;payload_offset;
&gt; &gt; +=09=09payload_length =3D hdr-&gt;payload_length;
&gt; &gt; +=09=09
&gt; &gt; +=09=09if ( payload_offset &gt;=3D st.st_size )
&gt; &gt; +=09=09{
&gt; &gt; +=09=09=09printf(&quot;%s: payload offset overflow&quot;, __FUNCT=
ION__);
&gt; &gt; +=09=09=09return 1;
&gt; &gt; +=09=09}
&gt; &gt; +=09=09if ( (payload_offset + payload_length) &gt; st.st_size )
&gt; &gt; +=09=09{
&gt; &gt; +=09=09=09printf(&quot;%s: payload length overflow&quot;, __FUNCT=
ION__);
&gt; &gt; +=09=09=09return 1;
&gt; &gt; +=09=09}
&gt; &gt; +
&gt; &gt; +=09=09image =3D image + payload_offset;
&gt; &gt; +=09=09size =3D payload_length;
&gt; &gt; +=09} else {
&gt; &gt; +=09=09size =3D st.st_size;
&gt; &gt; +=09}
&gt; &gt; +
&gt; &gt; +=09usize =3D xc_dom_check_gzip(xch, image, size);
&gt; &gt;  =09if (usize)
&gt; &gt;  =09{
&gt; &gt;  =09=09tmp =3D malloc(usize);
&gt; &gt; -=09=09xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
&gt; &gt; +=09=09xc_dom_do_gunzip(xch, image, size, tmp, usize);
&gt; &gt;  =09=09image =3D tmp;
&gt; &gt;  =09=09size =3D usize;
&gt; &gt;  =09}
&gt; &gt;=20
&gt; &gt; This e-mail is intended solely for the person or entity to which =
it is=20
&gt; &gt; addressed
&gt; &gt; and may contain confidential and/or privileged information. Any r=
eview,=20
&gt; &gt; dissemination,
&gt; &gt; copying, printing or other use of this e-mail by persons or entit=
ies other=20
&gt; &gt; than the=20
&gt; &gt; addressee is prohibited. If you have received this e-mail in erro=
r, please=20
&gt; &gt; contact
&gt; &gt; the sender immediately and delete the material from any computer.
&gt; &gt; To unsubscribe send an email to: <A HREF=3D"mailto:Unsubscribe@hi=
tachiconsulting.com">Unsubscribe@hitachiconsulting.com</A>=20
&gt; &gt; Hitachi Consulting (China) Co., Ltd. (HCCD0411)
&gt; &gt;=20
&gt; &gt;=20
&gt; &gt;=20
&gt; &gt; _______________________________________________
&gt; &gt; Xen-devel mailing list
&gt; &gt; <A HREF=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.or=
g</A>=20
&gt; &gt; <A HREF=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/x=
en-devel</A>=20
&gt;=20
&gt;=20
&gt;=20
&gt; _______________________________________________
&gt; Xen-devel mailing list
&gt; <A HREF=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</A>
&gt; <A HREF=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</A>



</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>
--=-aZaC9Ufja/c88rSEtweD--



--===============3467935560755890166==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3467935560755890166==--



From xen-devel-bounces@lists.xen.org Thu Apr 26 10:10:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLeb-0003no-AD; Thu, 26 Apr 2012 10:10:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNLeZ-0003nj-S4
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 10:10:23 +0000
Received: from [85.158.139.83:32442] by server-3.bemta-5.messagelabs.com id
	EC/DD-25237-F0F199F4; Thu, 26 Apr 2012 10:10:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335435021!22877050!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12567 invoked from network); 26 Apr 2012 10:10:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 10:10:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNLeW-000Hfs-Bx; Thu, 26 Apr 2012 10:10:20 +0000
Date: Thu, 26 Apr 2012 11:10:20 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120426101020.GD67043@ocelot.phlegethon.org>
References: <20120424122434.5bf077e7@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120424122434.5bf077e7@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] get_page*, paging modes, shadow paging...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:24 -0700 on 24 Apr (1335270274), Mukesh Rathor wrote:
> The get_page*, paging modes, etc... have gotten pretty complex. It
> would be tremendously helpful if you can please talk about this a bit
> at xen summit. Could do it in parallel session, or main, doesn't
> matter. Just going over these in introductory manner, would be great
> help and highly appreciated. Are you coming to the xen summit?

I wasn't planning to, but I'll look into it.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 10:10:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLeb-0003no-AD; Thu, 26 Apr 2012 10:10:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNLeZ-0003nj-S4
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 10:10:23 +0000
Received: from [85.158.139.83:32442] by server-3.bemta-5.messagelabs.com id
	EC/DD-25237-F0F199F4; Thu, 26 Apr 2012 10:10:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335435021!22877050!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12567 invoked from network); 26 Apr 2012 10:10:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 10:10:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNLeW-000Hfs-Bx; Thu, 26 Apr 2012 10:10:20 +0000
Date: Thu, 26 Apr 2012 11:10:20 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120426101020.GD67043@ocelot.phlegethon.org>
References: <20120424122434.5bf077e7@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120424122434.5bf077e7@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] get_page*, paging modes, shadow paging...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:24 -0700 on 24 Apr (1335270274), Mukesh Rathor wrote:
> The get_page*, paging modes, etc... have gotten pretty complex. It
> would be tremendously helpful if you can please talk about this a bit
> at xen summit. Could do it in parallel session, or main, doesn't
> matter. Just going over these in introductory manner, would be great
> help and highly appreciated. Are you coming to the xen summit?

I wasn't planning to, but I'll look into it.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 10:14:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLiJ-0003ui-VG; Thu, 26 Apr 2012 10:14:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SNLiI-0003uZ-Hc
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 10:14:14 +0000
Received: from [85.158.139.83:27169] by server-8.bemta-5.messagelabs.com id
	C0/55-26964-5FF199F4; Thu, 26 Apr 2012 10:14:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335435251!18241051!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10706 invoked from network); 26 Apr 2012 10:14:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 10:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330923600"; d="scan'208";a="24562726"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 06:14:11 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012
	06:14:10 -0400
Message-ID: <4F991FF1.6000007@citrix.com>
Date: Thu, 26 Apr 2012 11:14:09 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: tobias.geiger@vido.info, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: use the pirq number to check
	the	pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/04/12 16:11, Stefano Stabellini wrote:
> In pirq_check_eoi_map use the pirq number rather than the Linux irq
> number to check whether an eoi is needed in the pirq_eoi_map.

What buggy behaviour does this patch fix?  It would be nice if this was
included in the patch description.

David

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Tobias Geiger <tobias.geiger@vido.info>
> ---
>  drivers/xen/events.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 4b33acd..0a8a17c 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
>  
>  static bool pirq_check_eoi_map(unsigned irq)
>  {
> -	return test_bit(irq, pirq_eoi_map);
> +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
>  }
>  
>  static bool pirq_needs_eoi_flag(unsigned irq)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 10:14:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLiJ-0003ui-VG; Thu, 26 Apr 2012 10:14:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SNLiI-0003uZ-Hc
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 10:14:14 +0000
Received: from [85.158.139.83:27169] by server-8.bemta-5.messagelabs.com id
	C0/55-26964-5FF199F4; Thu, 26 Apr 2012 10:14:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335435251!18241051!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10706 invoked from network); 26 Apr 2012 10:14:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 10:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330923600"; d="scan'208";a="24562726"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 06:14:11 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012
	06:14:10 -0400
Message-ID: <4F991FF1.6000007@citrix.com>
Date: Thu, 26 Apr 2012 11:14:09 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: tobias.geiger@vido.info, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: use the pirq number to check
	the	pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/04/12 16:11, Stefano Stabellini wrote:
> In pirq_check_eoi_map use the pirq number rather than the Linux irq
> number to check whether an eoi is needed in the pirq_eoi_map.

What buggy behaviour does this patch fix?  It would be nice if this was
included in the patch description.

David

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Tobias Geiger <tobias.geiger@vido.info>
> ---
>  drivers/xen/events.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 4b33acd..0a8a17c 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
>  
>  static bool pirq_check_eoi_map(unsigned irq)
>  {
> -	return test_bit(irq, pirq_eoi_map);
> +	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
>  }
>  
>  static bool pirq_needs_eoi_flag(unsigned irq)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 10:27:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLuK-00049I-7K; Thu, 26 Apr 2012 10:26:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNLuI-00049D-B2
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 10:26:38 +0000
Received: from [193.109.254.147:8462] by server-4.bemta-14.messagelabs.com id
	06/ED-11570-DD2299F4; Thu, 26 Apr 2012 10:26:37 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335435995!6471106!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29459 invoked from network); 26 Apr 2012 10:26:37 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 10:26:37 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNLuF-0006Yf-65
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 03:26:35 -0700
Date: Thu, 26 Apr 2012 03:26:35 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335435995180-5667212.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25249:a4e7fce6ee2b)
vi Makefile # removed dist-kernel to not compile kernel
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb

-------------------------
Recent regression:
-------------
- CRITICAL - PV domU unable to start, freeze on config parsing, with this
output and nothing else:
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
-------------
- On hvm domU start, domU work also this output on xl create:
libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
range, valid values are within range from 1 to 65535
-------------------------

If you need further details tell me and I will post back


--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 10:27:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNLuK-00049I-7K; Thu, 26 Apr 2012 10:26:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNLuI-00049D-B2
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 10:26:38 +0000
Received: from [193.109.254.147:8462] by server-4.bemta-14.messagelabs.com id
	06/ED-11570-DD2299F4; Thu, 26 Apr 2012 10:26:37 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335435995!6471106!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29459 invoked from network); 26 Apr 2012 10:26:37 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 10:26:37 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNLuF-0006Yf-65
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 03:26:35 -0700
Date: Thu, 26 Apr 2012 03:26:35 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335435995180-5667212.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25249:a4e7fce6ee2b)
vi Makefile # removed dist-kernel to not compile kernel
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb

-------------------------
Recent regression:
-------------
- CRITICAL - PV domU unable to start, freeze on config parsing, with this
output and nothing else:
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
-------------
- On hvm domU start, domU work also this output on xl create:
libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
range, valid values are within range from 1 to 65535
-------------------------

If you need further details tell me and I will post back


--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 10:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMJi-0004PF-GA; Thu, 26 Apr 2012 10:52:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNMJh-0004PA-QA
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 10:52:54 +0000
Received: from [85.158.139.83:2198] by server-9.bemta-5.messagelabs.com id
	02/63-09826-509299F4; Thu, 26 Apr 2012 10:52:53 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335437570!25591572!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2681 invoked from network); 26 Apr 2012 10:52:51 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 10:52:51 -0000
Received: by qcsc20 with SMTP id c20so788510qcs.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 03:52:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=0ko7jC0eZq6CDAciarBT72n9ucmm1f1+yXOh8atxnSo=;
	b=JECvPaxKPlHsHj6KUY+/dC68nDWYHzcdY8jjB0QyJsWC1VC8vMxrFg07K2nY1JZlGm
	DWQS+DNu7A8Zd41ywlC6qoJes2VqqVIHyNruQiBm7SLlRMsJ87euAWBgUotBtldvLXAx
	sfhIyENPhqO62hVyH67oQ+6FKYDz+Hv3LGq06vc6LIb+9ECxE2cx9Cxvk6Ygpvhlm+2t
	mwe0mHngIZdaQ8A0qhbpNQJa4fXFIsSGr903XxYnc8Hmp/hzUnT9tO8TYMCQp4dSanxW
	NfJr8BUzE+o15JR8zeGhI0+QRMKELHP5xErqUIKr02PAc9i3bVdh01cxHiFhHAFfPuk8
	AdCQ==
MIME-Version: 1.0
Received: by 10.224.175.69 with SMTP id w5mr382698qaz.49.1335437570151; Thu,
	26 Apr 2012 03:52:50 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 03:52:50 -0700 (PDT)
Date: Thu, 26 Apr 2012 11:52:50 +0100
X-Google-Sender-Auth: ddfMElp_lkoCOKKyn3KMPfffat0
Message-ID: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=20cf303b4119fd13b604be92c94f
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--20cf303b4119fd13b604be92c94f
Content-Type: text/plain; charset=ISO-8859-1

Recently I pulled in new changesets from xen- and qemu-unstable, and
when creating a PV guest I'm getting errors like the stack trace
below.  Is this likely to be caused by QEMU using AIO?  It this a bug
in Xen or in the Debian kernel?  Is there an easy way to turn off aio
using a config file so I can see if it is qemu's aio?

The config file is attached, for reference.

 -George

[  408.127439] BUG: unable to handle kernel paging request at af00003e
[  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
[  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
[  408.144532] Oops: 0000 [#1] SMP
[  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
[  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
x_tables xen_evtchn xenfs bridge stp loop snd_p]
[  408.194797]
[  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
(2.6.32-5-xen-686 #1) PowerEdge R710
[  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
[  408.210485] EIP is at set_page_dirty+0x1e/0x4a
[  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
[  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
[  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
[  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
task=f3de50c0 task.ti=f33be000)
[  408.241508] Stack:
[  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
f4f0c500 c10dc048
[  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
c1006767 00000000 00000000
[  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
0000000c 00001000 00000000
[  408.267509] Call Trace:
[  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
[  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
[  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
[  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
[  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
[  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
[  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
[  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
[  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
[  408.320376]  [<c1006770>] ? check_events+0x8/0xc
[  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
[  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
[  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
[  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
[  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
[  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
[  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
[  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
[  408.382512] CR2: 00000000af00003e
[  408.385894] ---[ end trace 9ce48eb2f06897bf ]---

--20cf303b4119fd13b604be92c94f
Content-Type: application/octet-stream; name="pv.cfg"
Content-Disposition: attachment; filename="pv.cfg"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h1hozzzz0

IwojIENvbmZpZ3VyYXRpb24gZmlsZSBmb3IgdGhlIFhlbiBpbnN0YW5jZSBkb21uZXQsIGNyZWF0
ZWQKIyBieSB4ZW4tdG9vbHMgNC4yIG9uIFR1ZSBNYXIgMjAgMTc6MTQ6MjAgMjAxMi4KIwoKIwoj
ICBLZXJuZWwgKyBtZW1vcnkgc2l6ZQojCgoKYm9vdGxvYWRlciA9ICdweWdydWInCgp2Y3B1cyAg
ICAgICA9ICcxJwptZW1vcnkgICAgICA9ICcxMjgnCgojCiMgIERpc2sgZGV2aWNlKHMpLgojCnJv
b3QgICAgICAgID0gJy9kZXYveHZkYTIgcm8nCmRpc2sgICAgICAgID0gWwogICAgICAgICAgICAg
ICAgICAnZmlsZTovdm0vZG9tYWlucy9wdi9kaXNrLmltZyx4dmRhMix3JywKICAgICAgICAgICAg
ICAgICAgJ2ZpbGU6L3ZtL2RvbWFpbnMvcHYvc3dhcC5pbWcseHZkYTEsdycsCiAgICAgICAgICAg
ICAgXQoKCiMKIyAgUGh5c2ljYWwgdm9sdW1lcwojCgoKIwojICBIb3N0bmFtZQojCm5hbWUgICAg
ICAgID0gJ3B2JwoKIwojICBOZXR3b3JraW5nCiMKZGhjcCAgICAgICAgPSAnZGhjcCcKdmlmICAg
ICAgICAgPSBbICdtYWM9MDA6MTY6M0U6NEI6NkU6RDksYnJpZGdlPXhlbmJyMCcgXQojdmlmICAg
ICAgICAgPSBbICdtYWM9MDA6MTY6M0U6NEI6NkU6RDksYnJpZGdlPXhlbmJyMCxiYWNrZW5kPWRv
bW5ldCcgXQpuZXRpZj0ieWVzIgpleHRyYT0iY29uc29sZT1odmMwIHhlbmNvbnM9dHR5IGlvbW11
PXNvZnQiCgojCiMgIEJlaGF2aW91cgojCm9uX3Bvd2Vyb2ZmID0gJ2Rlc3Ryb3knCm9uX3JlYm9v
dCAgID0gJ3Jlc3RhcnQnCm9uX2NyYXNoICAgID0gJ3Jlc3RhcnQnCgoKCg==
--20cf303b4119fd13b604be92c94f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--20cf303b4119fd13b604be92c94f--


From xen-devel-bounces@lists.xen.org Thu Apr 26 10:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 10:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMJi-0004PF-GA; Thu, 26 Apr 2012 10:52:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNMJh-0004PA-QA
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 10:52:54 +0000
Received: from [85.158.139.83:2198] by server-9.bemta-5.messagelabs.com id
	02/63-09826-509299F4; Thu, 26 Apr 2012 10:52:53 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335437570!25591572!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2681 invoked from network); 26 Apr 2012 10:52:51 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 10:52:51 -0000
Received: by qcsc20 with SMTP id c20so788510qcs.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 03:52:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=0ko7jC0eZq6CDAciarBT72n9ucmm1f1+yXOh8atxnSo=;
	b=JECvPaxKPlHsHj6KUY+/dC68nDWYHzcdY8jjB0QyJsWC1VC8vMxrFg07K2nY1JZlGm
	DWQS+DNu7A8Zd41ywlC6qoJes2VqqVIHyNruQiBm7SLlRMsJ87euAWBgUotBtldvLXAx
	sfhIyENPhqO62hVyH67oQ+6FKYDz+Hv3LGq06vc6LIb+9ECxE2cx9Cxvk6Ygpvhlm+2t
	mwe0mHngIZdaQ8A0qhbpNQJa4fXFIsSGr903XxYnc8Hmp/hzUnT9tO8TYMCQp4dSanxW
	NfJr8BUzE+o15JR8zeGhI0+QRMKELHP5xErqUIKr02PAc9i3bVdh01cxHiFhHAFfPuk8
	AdCQ==
MIME-Version: 1.0
Received: by 10.224.175.69 with SMTP id w5mr382698qaz.49.1335437570151; Thu,
	26 Apr 2012 03:52:50 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 03:52:50 -0700 (PDT)
Date: Thu, 26 Apr 2012 11:52:50 +0100
X-Google-Sender-Auth: ddfMElp_lkoCOKKyn3KMPfffat0
Message-ID: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=20cf303b4119fd13b604be92c94f
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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

--20cf303b4119fd13b604be92c94f
Content-Type: text/plain; charset=ISO-8859-1

Recently I pulled in new changesets from xen- and qemu-unstable, and
when creating a PV guest I'm getting errors like the stack trace
below.  Is this likely to be caused by QEMU using AIO?  It this a bug
in Xen or in the Debian kernel?  Is there an easy way to turn off aio
using a config file so I can see if it is qemu's aio?

The config file is attached, for reference.

 -George

[  408.127439] BUG: unable to handle kernel paging request at af00003e
[  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
[  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
[  408.144532] Oops: 0000 [#1] SMP
[  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
[  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
x_tables xen_evtchn xenfs bridge stp loop snd_p]
[  408.194797]
[  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
(2.6.32-5-xen-686 #1) PowerEdge R710
[  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
[  408.210485] EIP is at set_page_dirty+0x1e/0x4a
[  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
[  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
[  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
[  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
task=f3de50c0 task.ti=f33be000)
[  408.241508] Stack:
[  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
f4f0c500 c10dc048
[  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
c1006767 00000000 00000000
[  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
0000000c 00001000 00000000
[  408.267509] Call Trace:
[  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
[  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
[  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
[  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
[  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
[  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
[  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
[  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
[  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
[  408.320376]  [<c1006770>] ? check_events+0x8/0xc
[  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
[  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
[  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
[  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
[  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
[  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
[  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
[  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
[  408.382512] CR2: 00000000af00003e
[  408.385894] ---[ end trace 9ce48eb2f06897bf ]---

--20cf303b4119fd13b604be92c94f
Content-Type: application/octet-stream; name="pv.cfg"
Content-Disposition: attachment; filename="pv.cfg"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h1hozzzz0

IwojIENvbmZpZ3VyYXRpb24gZmlsZSBmb3IgdGhlIFhlbiBpbnN0YW5jZSBkb21uZXQsIGNyZWF0
ZWQKIyBieSB4ZW4tdG9vbHMgNC4yIG9uIFR1ZSBNYXIgMjAgMTc6MTQ6MjAgMjAxMi4KIwoKIwoj
ICBLZXJuZWwgKyBtZW1vcnkgc2l6ZQojCgoKYm9vdGxvYWRlciA9ICdweWdydWInCgp2Y3B1cyAg
ICAgICA9ICcxJwptZW1vcnkgICAgICA9ICcxMjgnCgojCiMgIERpc2sgZGV2aWNlKHMpLgojCnJv
b3QgICAgICAgID0gJy9kZXYveHZkYTIgcm8nCmRpc2sgICAgICAgID0gWwogICAgICAgICAgICAg
ICAgICAnZmlsZTovdm0vZG9tYWlucy9wdi9kaXNrLmltZyx4dmRhMix3JywKICAgICAgICAgICAg
ICAgICAgJ2ZpbGU6L3ZtL2RvbWFpbnMvcHYvc3dhcC5pbWcseHZkYTEsdycsCiAgICAgICAgICAg
ICAgXQoKCiMKIyAgUGh5c2ljYWwgdm9sdW1lcwojCgoKIwojICBIb3N0bmFtZQojCm5hbWUgICAg
ICAgID0gJ3B2JwoKIwojICBOZXR3b3JraW5nCiMKZGhjcCAgICAgICAgPSAnZGhjcCcKdmlmICAg
ICAgICAgPSBbICdtYWM9MDA6MTY6M0U6NEI6NkU6RDksYnJpZGdlPXhlbmJyMCcgXQojdmlmICAg
ICAgICAgPSBbICdtYWM9MDA6MTY6M0U6NEI6NkU6RDksYnJpZGdlPXhlbmJyMCxiYWNrZW5kPWRv
bW5ldCcgXQpuZXRpZj0ieWVzIgpleHRyYT0iY29uc29sZT1odmMwIHhlbmNvbnM9dHR5IGlvbW11
PXNvZnQiCgojCiMgIEJlaGF2aW91cgojCm9uX3Bvd2Vyb2ZmID0gJ2Rlc3Ryb3knCm9uX3JlYm9v
dCAgID0gJ3Jlc3RhcnQnCm9uX2NyYXNoICAgID0gJ3Jlc3RhcnQnCgoKCg==
--20cf303b4119fd13b604be92c94f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--20cf303b4119fd13b604be92c94f--


From xen-devel-bounces@lists.xen.org Thu Apr 26 11:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMQK-0004Zk-Gq; Thu, 26 Apr 2012 10:59:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNMQI-0004Zf-QG
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 10:59:43 +0000
Received: from [85.158.139.83:10717] by server-8.bemta-5.messagelabs.com id
	E4/52-26964-E9A299F4; Thu, 26 Apr 2012 10:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335437980!25068039!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20051 invoked from network); 26 Apr 2012 10:59:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 10:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:59:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 11:59:40 +0100
Message-ID: <1335437978.28015.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 11:59:38 +0100
In-Reply-To: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> Recently I pulled in new changesets from xen- and qemu-unstable, and
> when creating a PV guest I'm getting errors like the stack trace
> below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> using a config file so I can see if it is qemu's aio?
> 
> The config file is attached, for reference.

Which revision of the Debian kernel is this?

It looks like Squeeze, which was a fairly old snapshot of Jeremy's
Xen.git -- it's certainly not impossible that there were latent AIO bugs
in there and Stefano has been fixing these sort of things in recent
kernels too. So it's very possible we need to backport some fix.

Ian.

> 
>  -George
> 
> [  408.127439] BUG: unable to handle kernel paging request at af00003e
> [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> [  408.144532] Oops: 0000 [#1] SMP
> [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> x_tables xen_evtchn xenfs bridge stp loop snd_p]
> [  408.194797]
> [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> (2.6.32-5-xen-686 #1) PowerEdge R710
> [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> task=f3de50c0 task.ti=f33be000)
> [  408.241508] Stack:
> [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> f4f0c500 c10dc048
> [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> c1006767 00000000 00000000
> [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> 0000000c 00001000 00000000
> [  408.267509] Call Trace:
> [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> [  408.382512] CR2: 00000000af00003e
> [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMQK-0004Zk-Gq; Thu, 26 Apr 2012 10:59:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNMQI-0004Zf-QG
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 10:59:43 +0000
Received: from [85.158.139.83:10717] by server-8.bemta-5.messagelabs.com id
	E4/52-26964-E9A299F4; Thu, 26 Apr 2012 10:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335437980!25068039!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20051 invoked from network); 26 Apr 2012 10:59:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 10:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:59:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 11:59:40 +0100
Message-ID: <1335437978.28015.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 11:59:38 +0100
In-Reply-To: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> Recently I pulled in new changesets from xen- and qemu-unstable, and
> when creating a PV guest I'm getting errors like the stack trace
> below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> using a config file so I can see if it is qemu's aio?
> 
> The config file is attached, for reference.

Which revision of the Debian kernel is this?

It looks like Squeeze, which was a fairly old snapshot of Jeremy's
Xen.git -- it's certainly not impossible that there were latent AIO bugs
in there and Stefano has been fixing these sort of things in recent
kernels too. So it's very possible we need to backport some fix.

Ian.

> 
>  -George
> 
> [  408.127439] BUG: unable to handle kernel paging request at af00003e
> [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> [  408.144532] Oops: 0000 [#1] SMP
> [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> x_tables xen_evtchn xenfs bridge stp loop snd_p]
> [  408.194797]
> [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> (2.6.32-5-xen-686 #1) PowerEdge R710
> [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> task=f3de50c0 task.ti=f33be000)
> [  408.241508] Stack:
> [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> f4f0c500 c10dc048
> [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> c1006767 00000000 00000000
> [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> 0000000c 00001000 00000000
> [  408.267509] Call Trace:
> [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> [  408.382512] CR2: 00000000af00003e
> [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMZH-0004lH-Jc; Thu, 26 Apr 2012 11:08:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNMZF-0004lC-Is
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:08:57 +0000
Received: from [85.158.139.83:35718] by server-2.bemta-5.messagelabs.com id
	20/99-17016-8CC299F4; Thu, 26 Apr 2012 11:08:56 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335438535!25521921!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20945 invoked from network); 26 Apr 2012 11:08:56 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:08:56 -0000
Received: by qabg40 with SMTP id g40so1588551qab.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 04:08:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Xzuj6TT9SvWOm55I7LN/gHHsNKXn1aF6Jj/DdLsK3Ak=;
	b=k/NEsf6rnoge79iK9Ppi9F3bnvCa+cfQWRtBEVBkA9q2dQXAzY91nwmVeutc3oSe9q
	NbXgDQ5T0DHu1qaV/n9P/BX/DMHJsJVlP0rbszP0HVgocNrA2wFf7wO0Osyb6VMyxhgx
	KSjS/p45PMIV2zlwc/W9OzNiswe9W2sUfuNZJ2qiuWoXd0/BsUzbKIAIbDR1eJrzyE/w
	YHVHY5wijaZkRtaMw52CYDtUfpx7407+tdjy3qVDeA3q3Ab0vrBIV+EHdzaq38RDugO9
	yMEQ3waLLDyz8au7igf/wOB+DTH+pgPvRDxoLFQrDRparnjr3GALsFusWKMnNbeQwSsv
	jofg==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr4784476qao.23.1335438534728; Thu,
	26 Apr 2012 04:08:54 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 04:08:54 -0700 (PDT)
In-Reply-To: <1335437978.28015.103.camel@zakaz.uk.xensource.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
Date: Thu, 26 Apr 2012 12:08:54 +0100
X-Google-Sender-Auth: 4HJP65JVSmTAzwWw6hV-auqctYA
Message-ID: <CAFLBxZYyAafFzm90StT1imrkzo80LZXu8aYPhgOG-sjVWLXOQQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 11:59 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
>> Recently I pulled in new changesets from xen- and qemu-unstable, and
>> when creating a PV guest I'm getting errors like the stack trace
>> below. =A0Is this likely to be caused by QEMU using AIO? =A0It this a bug
>> in Xen or in the Debian kernel? =A0Is there an easy way to turn off aio
>> using a config file so I can see if it is qemu's aio?
>>
>> The config file is attached, for reference.
>
> Which revision of the Debian kernel is this?
>
> It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> Xen.git -- it's certainly not impossible that there were latent AIO bugs
> in there and Stefano has been fixing these sort of things in recent
> kernels too. So it's very possible we need to backport some fix.

The package info is below.  It is from squeeze, since (AFAIK) that's
the latest "stable" release (and thus what people are likely to be
using)

 -George

# dpkg -s linux-image-2.6.32-5-xen-686
Package: linux-image-2.6.32-5-xen-686
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 78524
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: i386
Source: linux-2.6
Version: 2.6.32-41
Provides: linux-image, linux-image-2.6, linux-modules-2.6.32-5-xen-686
Depends: module-init-tools, linux-base (>=3D 2.6.32-41), initramfs-tools (>=
=3D 0.55)
Pre-Depends: debconf | debconf-2.0
Recommends: firmware-linux-free (>=3D 2.6.32), libc6-xen
Suggests: linux-doc-2.6.32, grub
Breaks: initramfs-tools (<< 0.55), lilo (<< 22.8-8.2~)
Description: Linux 2.6.32 for modern PCs, Xen dom0 support
 The Linux kernel 2.6.32 and modules for use on PCs with Intel Pentium
 Pro/II/III/4/4M/D/M, Xeon, Celeron, Core or Atom; AMD Geode NX, Athlon
 (K7), Duron, Opteron, Sempron, Turion or Phenom; Transmeta Efficeon; or
 VIA C7 processors.
 .
 This kernel also runs on a Xen hypervisor.  It supports both privileged
 (dom0) and unprivileged (domU) operation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMZH-0004lH-Jc; Thu, 26 Apr 2012 11:08:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNMZF-0004lC-Is
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:08:57 +0000
Received: from [85.158.139.83:35718] by server-2.bemta-5.messagelabs.com id
	20/99-17016-8CC299F4; Thu, 26 Apr 2012 11:08:56 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335438535!25521921!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20945 invoked from network); 26 Apr 2012 11:08:56 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:08:56 -0000
Received: by qabg40 with SMTP id g40so1588551qab.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 04:08:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Xzuj6TT9SvWOm55I7LN/gHHsNKXn1aF6Jj/DdLsK3Ak=;
	b=k/NEsf6rnoge79iK9Ppi9F3bnvCa+cfQWRtBEVBkA9q2dQXAzY91nwmVeutc3oSe9q
	NbXgDQ5T0DHu1qaV/n9P/BX/DMHJsJVlP0rbszP0HVgocNrA2wFf7wO0Osyb6VMyxhgx
	KSjS/p45PMIV2zlwc/W9OzNiswe9W2sUfuNZJ2qiuWoXd0/BsUzbKIAIbDR1eJrzyE/w
	YHVHY5wijaZkRtaMw52CYDtUfpx7407+tdjy3qVDeA3q3Ab0vrBIV+EHdzaq38RDugO9
	yMEQ3waLLDyz8au7igf/wOB+DTH+pgPvRDxoLFQrDRparnjr3GALsFusWKMnNbeQwSsv
	jofg==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr4784476qao.23.1335438534728; Thu,
	26 Apr 2012 04:08:54 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 04:08:54 -0700 (PDT)
In-Reply-To: <1335437978.28015.103.camel@zakaz.uk.xensource.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
Date: Thu, 26 Apr 2012 12:08:54 +0100
X-Google-Sender-Auth: 4HJP65JVSmTAzwWw6hV-auqctYA
Message-ID: <CAFLBxZYyAafFzm90StT1imrkzo80LZXu8aYPhgOG-sjVWLXOQQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 11:59 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
>> Recently I pulled in new changesets from xen- and qemu-unstable, and
>> when creating a PV guest I'm getting errors like the stack trace
>> below. =A0Is this likely to be caused by QEMU using AIO? =A0It this a bug
>> in Xen or in the Debian kernel? =A0Is there an easy way to turn off aio
>> using a config file so I can see if it is qemu's aio?
>>
>> The config file is attached, for reference.
>
> Which revision of the Debian kernel is this?
>
> It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> Xen.git -- it's certainly not impossible that there were latent AIO bugs
> in there and Stefano has been fixing these sort of things in recent
> kernels too. So it's very possible we need to backport some fix.

The package info is below.  It is from squeeze, since (AFAIK) that's
the latest "stable" release (and thus what people are likely to be
using)

 -George

# dpkg -s linux-image-2.6.32-5-xen-686
Package: linux-image-2.6.32-5-xen-686
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 78524
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: i386
Source: linux-2.6
Version: 2.6.32-41
Provides: linux-image, linux-image-2.6, linux-modules-2.6.32-5-xen-686
Depends: module-init-tools, linux-base (>=3D 2.6.32-41), initramfs-tools (>=
=3D 0.55)
Pre-Depends: debconf | debconf-2.0
Recommends: firmware-linux-free (>=3D 2.6.32), libc6-xen
Suggests: linux-doc-2.6.32, grub
Breaks: initramfs-tools (<< 0.55), lilo (<< 22.8-8.2~)
Description: Linux 2.6.32 for modern PCs, Xen dom0 support
 The Linux kernel 2.6.32 and modules for use on PCs with Intel Pentium
 Pro/II/III/4/4M/D/M, Xeon, Celeron, Core or Atom; AMD Geode NX, Athlon
 (K7), Duron, Opteron, Sempron, Turion or Phenom; Transmeta Efficeon; or
 VIA C7 processors.
 .
 This kernel also runs on a Xen hypervisor.  It supports both privileged
 (dom0) and unprivileged (domU) operation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:11:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMbO-0004sb-3t; Thu, 26 Apr 2012 11:11:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNMbN-0004sW-H6
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:11:09 +0000
Received: from [85.158.139.83:54153] by server-9.bemta-5.messagelabs.com id
	27/28-09826-C4D299F4; Thu, 26 Apr 2012 11:11:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335438667!21727866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8499 invoked from network); 26 Apr 2012 11:11:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:11:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:11:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 12:11:07 +0100
Date: Thu, 26 Apr 2012 12:17:21 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F991FF1.6000007@citrix.com>
Message-ID: <alpine.DEB.2.00.1204261216030.26786@kaball-desktop>
References: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F991FF1.6000007@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "tobias.geiger@vido.info" <tobias.geiger@vido.info>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: use the pirq number to check the
 pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, David Vrabel wrote:
> On 25/04/12 16:11, Stefano Stabellini wrote:
> > In pirq_check_eoi_map use the pirq number rather than the Linux irq
> > number to check whether an eoi is needed in the pirq_eoi_map.
> 
> What buggy behaviour does this patch fix?  It would be nice if this was
> included in the patch description.

The irq number is not always identical to the pirq number so if we
wrongly use the irq number to check the pirq_eoi_map we are going to
check for the wrong pirq to EOI. As a consequence some interrupts might
not be EOI'ed by the guest correctly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:11:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMbO-0004sb-3t; Thu, 26 Apr 2012 11:11:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNMbN-0004sW-H6
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:11:09 +0000
Received: from [85.158.139.83:54153] by server-9.bemta-5.messagelabs.com id
	27/28-09826-C4D299F4; Thu, 26 Apr 2012 11:11:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335438667!21727866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8499 invoked from network); 26 Apr 2012 11:11:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:11:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:11:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 12:11:07 +0100
Date: Thu, 26 Apr 2012 12:17:21 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F991FF1.6000007@citrix.com>
Message-ID: <alpine.DEB.2.00.1204261216030.26786@kaball-desktop>
References: <1335366698-19875-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F991FF1.6000007@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "tobias.geiger@vido.info" <tobias.geiger@vido.info>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: use the pirq number to check the
 pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, David Vrabel wrote:
> On 25/04/12 16:11, Stefano Stabellini wrote:
> > In pirq_check_eoi_map use the pirq number rather than the Linux irq
> > number to check whether an eoi is needed in the pirq_eoi_map.
> 
> What buggy behaviour does this patch fix?  It would be nice if this was
> included in the patch description.

The irq number is not always identical to the pirq number so if we
wrongly use the irq number to check the pirq_eoi_map we are going to
check for the wrong pirq to EOI. As a consequence some interrupts might
not be EOI'ed by the guest correctly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:14:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMek-00052p-OS; Thu, 26 Apr 2012 11:14:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNMej-00052e-3o
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:14:37 +0000
Received: from [85.158.143.35:47195] by server-2.bemta-4.messagelabs.com id
	61/66-17550-C1E299F4; Thu, 26 Apr 2012 11:14:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335438875!13775895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12279 invoked from network); 26 Apr 2012 11:14:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:14:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:14:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 12:14:34 +0100
Message-ID: <1335438873.28015.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 12:14:33 +0100
In-Reply-To: <CAFLBxZYyAafFzm90StT1imrkzo80LZXu8aYPhgOG-sjVWLXOQQ@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<CAFLBxZYyAafFzm90StT1imrkzo80LZXu8aYPhgOG-sjVWLXOQQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 12:08 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 11:59 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> >> Recently I pulled in new changesets from xen- and qemu-unstable, and
> >> when creating a PV guest I'm getting errors like the stack trace
> >> below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> >> in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> >> using a config file so I can see if it is qemu's aio?
> >>
> >> The config file is attached, for reference.
> >
> > Which revision of the Debian kernel is this?
> >
> > It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> > Xen.git -- it's certainly not impossible that there were latent AIO bugs
> > in there and Stefano has been fixing these sort of things in recent
> > kernels too. So it's very possible we need to backport some fix.
> 
> The package info is below.  It is from squeeze, since (AFAIK) that's
> the latest "stable" release (and thus what people are likely to be
> using)

Right, it's also the latest available kernel package for Squeeze, which
is what I wanted to check. Not that I've been aware of any AIO fixes
recently anyway.

> 
>  -George
> 
> # dpkg -s linux-image-2.6.32-5-xen-686
> Package: linux-image-2.6.32-5-xen-686
> Status: install ok installed
> Priority: optional
> Section: kernel
> Installed-Size: 78524
> Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
> Architecture: i386
> Source: linux-2.6
> Version: 2.6.32-41
> Provides: linux-image, linux-image-2.6, linux-modules-2.6.32-5-xen-686
> Depends: module-init-tools, linux-base (>= 2.6.32-41), initramfs-tools (>= 0.55)
> Pre-Depends: debconf | debconf-2.0
> Recommends: firmware-linux-free (>= 2.6.32), libc6-xen
> Suggests: linux-doc-2.6.32, grub
> Breaks: initramfs-tools (<< 0.55), lilo (<< 22.8-8.2~)
> Description: Linux 2.6.32 for modern PCs, Xen dom0 support
>  The Linux kernel 2.6.32 and modules for use on PCs with Intel Pentium
>  Pro/II/III/4/4M/D/M, Xeon, Celeron, Core or Atom; AMD Geode NX, Athlon
>  (K7), Duron, Opteron, Sempron, Turion or Phenom; Transmeta Efficeon; or
>  VIA C7 processors.
>  .
>  This kernel also runs on a Xen hypervisor.  It supports both privileged
>  (dom0) and unprivileged (domU) operation.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:14:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMek-00052p-OS; Thu, 26 Apr 2012 11:14:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNMej-00052e-3o
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:14:37 +0000
Received: from [85.158.143.35:47195] by server-2.bemta-4.messagelabs.com id
	61/66-17550-C1E299F4; Thu, 26 Apr 2012 11:14:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335438875!13775895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12279 invoked from network); 26 Apr 2012 11:14:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:14:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:14:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 12:14:34 +0100
Message-ID: <1335438873.28015.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 12:14:33 +0100
In-Reply-To: <CAFLBxZYyAafFzm90StT1imrkzo80LZXu8aYPhgOG-sjVWLXOQQ@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<CAFLBxZYyAafFzm90StT1imrkzo80LZXu8aYPhgOG-sjVWLXOQQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 12:08 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 11:59 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> >> Recently I pulled in new changesets from xen- and qemu-unstable, and
> >> when creating a PV guest I'm getting errors like the stack trace
> >> below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> >> in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> >> using a config file so I can see if it is qemu's aio?
> >>
> >> The config file is attached, for reference.
> >
> > Which revision of the Debian kernel is this?
> >
> > It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> > Xen.git -- it's certainly not impossible that there were latent AIO bugs
> > in there and Stefano has been fixing these sort of things in recent
> > kernels too. So it's very possible we need to backport some fix.
> 
> The package info is below.  It is from squeeze, since (AFAIK) that's
> the latest "stable" release (and thus what people are likely to be
> using)

Right, it's also the latest available kernel package for Squeeze, which
is what I wanted to check. Not that I've been aware of any AIO fixes
recently anyway.

> 
>  -George
> 
> # dpkg -s linux-image-2.6.32-5-xen-686
> Package: linux-image-2.6.32-5-xen-686
> Status: install ok installed
> Priority: optional
> Section: kernel
> Installed-Size: 78524
> Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
> Architecture: i386
> Source: linux-2.6
> Version: 2.6.32-41
> Provides: linux-image, linux-image-2.6, linux-modules-2.6.32-5-xen-686
> Depends: module-init-tools, linux-base (>= 2.6.32-41), initramfs-tools (>= 0.55)
> Pre-Depends: debconf | debconf-2.0
> Recommends: firmware-linux-free (>= 2.6.32), libc6-xen
> Suggests: linux-doc-2.6.32, grub
> Breaks: initramfs-tools (<< 0.55), lilo (<< 22.8-8.2~)
> Description: Linux 2.6.32 for modern PCs, Xen dom0 support
>  The Linux kernel 2.6.32 and modules for use on PCs with Intel Pentium
>  Pro/II/III/4/4M/D/M, Xeon, Celeron, Core or Atom; AMD Geode NX, Athlon
>  (K7), Duron, Opteron, Sempron, Turion or Phenom; Transmeta Efficeon; or
>  VIA C7 processors.
>  .
>  This kernel also runs on a Xen hypervisor.  It supports both privileged
>  (dom0) and unprivileged (domU) operation.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMhA-00059X-9c; Thu, 26 Apr 2012 11:17:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNMh9-00059P-5q
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:17:07 +0000
Received: from [85.158.143.35:59876] by server-1.bemta-4.messagelabs.com id
	B7/E3-20925-2BE299F4; Thu, 26 Apr 2012 11:17:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335439025!6569247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27500 invoked from network); 26 Apr 2012 11:17:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:17:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 12:17:05 +0100
Date: Thu, 26 Apr 2012 12:23:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335437978.28015.103.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Ian Campbell wrote:
> On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> > Recently I pulled in new changesets from xen- and qemu-unstable, and
> > when creating a PV guest I'm getting errors like the stack trace
> > below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> > in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> > using a config file so I can see if it is qemu's aio?
> > 
> > The config file is attached, for reference.
> 
> Which revision of the Debian kernel is this?
> 
> It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> Xen.git -- it's certainly not impossible that there were latent AIO bugs
> in there and Stefano has been fixing these sort of things in recent
> kernels too. So it's very possible we need to backport some fix.

Right.


> > [  408.127439] BUG: unable to handle kernel paging request at af00003e
> > [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> > [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> > [  408.144532] Oops: 0000 [#1] SMP
> > [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> > [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> > x_tables xen_evtchn xenfs bridge stp loop snd_p]
> > [  408.194797]
> > [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> > (2.6.32-5-xen-686 #1) PowerEdge R710
> > [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> > [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> > [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> > [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> > [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> > [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> > task=f3de50c0 task.ti=f33be000)
> > [  408.241508] Stack:
> > [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> > f4f0c500 c10dc048
> > [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> > c1006767 00000000 00000000
> > [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> > 0000000c 00001000 00000000
> > [  408.267509] Call Trace:
> > [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> > [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> > [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> > [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> > [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> > [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> > [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> > [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> > [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> > [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> > [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> > [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> > [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> > [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> > [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> > 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> > [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> > [  408.382512] CR2: 00000000af00003e
> > [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---
 
This looks like a classic direct_IO/AIO not working bug: it could be
because the m2p_override is not working correctly or it might not even
be present at all in this kernel (it went upstream in 2.6.38).
It only started showing now because qemu-xen-traditional switched to
O_DIRECT.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMhA-00059X-9c; Thu, 26 Apr 2012 11:17:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNMh9-00059P-5q
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:17:07 +0000
Received: from [85.158.143.35:59876] by server-1.bemta-4.messagelabs.com id
	B7/E3-20925-2BE299F4; Thu, 26 Apr 2012 11:17:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335439025!6569247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27500 invoked from network); 26 Apr 2012 11:17:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:17:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 12:17:05 +0100
Date: Thu, 26 Apr 2012 12:23:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335437978.28015.103.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Ian Campbell wrote:
> On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> > Recently I pulled in new changesets from xen- and qemu-unstable, and
> > when creating a PV guest I'm getting errors like the stack trace
> > below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> > in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> > using a config file so I can see if it is qemu's aio?
> > 
> > The config file is attached, for reference.
> 
> Which revision of the Debian kernel is this?
> 
> It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> Xen.git -- it's certainly not impossible that there were latent AIO bugs
> in there and Stefano has been fixing these sort of things in recent
> kernels too. So it's very possible we need to backport some fix.

Right.


> > [  408.127439] BUG: unable to handle kernel paging request at af00003e
> > [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> > [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> > [  408.144532] Oops: 0000 [#1] SMP
> > [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> > [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> > x_tables xen_evtchn xenfs bridge stp loop snd_p]
> > [  408.194797]
> > [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> > (2.6.32-5-xen-686 #1) PowerEdge R710
> > [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> > [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> > [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> > [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> > [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> > [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> > task=f3de50c0 task.ti=f33be000)
> > [  408.241508] Stack:
> > [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> > f4f0c500 c10dc048
> > [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> > c1006767 00000000 00000000
> > [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> > 0000000c 00001000 00000000
> > [  408.267509] Call Trace:
> > [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> > [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> > [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> > [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> > [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> > [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> > [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> > [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> > [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> > [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> > [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> > [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> > [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> > [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> > [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> > 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> > [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> > [  408.382512] CR2: 00000000af00003e
> > [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---
 
This looks like a classic direct_IO/AIO not working bug: it could be
because the m2p_override is not working correctly or it might not even
be present at all in this kernel (it went upstream in 2.6.38).
It only started showing now because qemu-xen-traditional switched to
O_DIRECT.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:19:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMjH-0005Hp-Qn; Thu, 26 Apr 2012 11:19:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNMjF-0005Hc-OU
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:19:17 +0000
Received: from [85.158.143.35:4523] by server-2.bemta-4.messagelabs.com id
	2B/3E-17550-53F299F4; Thu, 26 Apr 2012 11:19:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335439156!14131285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8348 invoked from network); 26 Apr 2012 11:19:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:19:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 12:19:15 +0100
Message-ID: <1335439154.28015.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 26 Apr 2012 12:19:14 +0100
In-Reply-To: <alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 12:23 +0100, Stefano Stabellini wrote:
> On Thu, 26 Apr 2012, Ian Campbell wrote:
> > On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> > > Recently I pulled in new changesets from xen- and qemu-unstable, and
> > > when creating a PV guest I'm getting errors like the stack trace
> > > below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> > > in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> > > using a config file so I can see if it is qemu's aio?
> > > 
> > > The config file is attached, for reference.
> > 
> > Which revision of the Debian kernel is this?
> > 
> > It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> > Xen.git -- it's certainly not impossible that there were latent AIO bugs
> > in there and Stefano has been fixing these sort of things in recent
> > kernels too. So it's very possible we need to backport some fix.
> 
> Right.
> 
> 
> > > [  408.127439] BUG: unable to handle kernel paging request at af00003e
> > > [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> > > [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> > > [  408.144532] Oops: 0000 [#1] SMP
> > > [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> > > [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> > > x_tables xen_evtchn xenfs bridge stp loop snd_p]
> > > [  408.194797]
> > > [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> > > (2.6.32-5-xen-686 #1) PowerEdge R710
> > > [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> > > [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> > > [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> > > [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> > > [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> > > [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> > > task=f3de50c0 task.ti=f33be000)
> > > [  408.241508] Stack:
> > > [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> > > f4f0c500 c10dc048
> > > [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> > > c1006767 00000000 00000000
> > > [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> > > 0000000c 00001000 00000000
> > > [  408.267509] Call Trace:
> > > [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> > > [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> > > [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> > > [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> > > [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> > > [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> > > [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> > > [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> > > [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> > > [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> > > [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> > > [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> > > [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> > > [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> > > [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> > > 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> > > [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> > > [  408.382512] CR2: 00000000af00003e
> > > [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---
>  
> This looks like a classic direct_IO/AIO not working bug: it could be
> because the m2p_override is not working correctly or it might not even
> be present at all in this kernel (it went upstream in 2.6.38).
> It only started showing now because qemu-xen-traditional switched to
> O_DIRECT.

This kernel had VM_FOREIGN and PageForeign etc rather than the
m2p_override. Could be that we need to extend VM_FOREIGN to cover rant
mapped pages?

That's actually a fair chunk of dev work, not just a simple backport.

However this kernel does have blktap so why is qemu based AIO being used
at all?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:19:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNMjH-0005Hp-Qn; Thu, 26 Apr 2012 11:19:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNMjF-0005Hc-OU
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:19:17 +0000
Received: from [85.158.143.35:4523] by server-2.bemta-4.messagelabs.com id
	2B/3E-17550-53F299F4; Thu, 26 Apr 2012 11:19:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335439156!14131285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8348 invoked from network); 26 Apr 2012 11:19:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="12152740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:19:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 12:19:15 +0100
Message-ID: <1335439154.28015.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 26 Apr 2012 12:19:14 +0100
In-Reply-To: <alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 12:23 +0100, Stefano Stabellini wrote:
> On Thu, 26 Apr 2012, Ian Campbell wrote:
> > On Thu, 2012-04-26 at 11:52 +0100, George Dunlap wrote:
> > > Recently I pulled in new changesets from xen- and qemu-unstable, and
> > > when creating a PV guest I'm getting errors like the stack trace
> > > below.  Is this likely to be caused by QEMU using AIO?  It this a bug
> > > in Xen or in the Debian kernel?  Is there an easy way to turn off aio
> > > using a config file so I can see if it is qemu's aio?
> > > 
> > > The config file is attached, for reference.
> > 
> > Which revision of the Debian kernel is this?
> > 
> > It looks like Squeeze, which was a fairly old snapshot of Jeremy's
> > Xen.git -- it's certainly not impossible that there were latent AIO bugs
> > in there and Stefano has been fixing these sort of things in recent
> > kernels too. So it's very possible we need to backport some fix.
> 
> Right.
> 
> 
> > > [  408.127439] BUG: unable to handle kernel paging request at af00003e
> > > [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> > > [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> > > [  408.144532] Oops: 0000 [#1] SMP
> > > [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> > > [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> > > x_tables xen_evtchn xenfs bridge stp loop snd_p]
> > > [  408.194797]
> > > [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> > > (2.6.32-5-xen-686 #1) PowerEdge R710
> > > [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> > > [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> > > [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> > > [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> > > [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> > > [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> > > task=f3de50c0 task.ti=f33be000)
> > > [  408.241508] Stack:
> > > [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> > > f4f0c500 c10dc048
> > > [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> > > c1006767 00000000 00000000
> > > [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> > > 0000000c 00001000 00000000
> > > [  408.267509] Call Trace:
> > > [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> > > [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> > > [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> > > [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> > > [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> > > [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> > > [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> > > [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> > > [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> > > [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> > > [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> > > [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> > > [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> > > [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> > > [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> > > 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> > > [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> > > [  408.382512] CR2: 00000000af00003e
> > > [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---
>  
> This looks like a classic direct_IO/AIO not working bug: it could be
> because the m2p_override is not working correctly or it might not even
> be present at all in this kernel (it went upstream in 2.6.38).
> It only started showing now because qemu-xen-traditional switched to
> O_DIRECT.

This kernel had VM_FOREIGN and PageForeign etc rather than the
m2p_override. Could be that we need to extend VM_FOREIGN to cover rant
mapped pages?

That's actually a fair chunk of dev work, not just a simple backport.

However this kernel does have blktap so why is qemu based AIO being used
at all?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:48:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNBX-0005vr-9L; Thu, 26 Apr 2012 11:48:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SNNBU-0005vm-S3
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:48:29 +0000
Received: from [85.158.143.35:3851] by server-1.bemta-4.messagelabs.com id
	7D/A2-20925-C06399F4; Thu, 26 Apr 2012 11:48:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335440905!11698662!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14810 invoked from network); 26 Apr 2012 11:48:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:48:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192176380"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:48:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 07:48:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SNNBQ-0006Sw-KF;
	Thu, 26 Apr 2012 12:48:24 +0100
Message-ID: <4F99360E.2010201@citrix.com>
Date: Thu, 26 Apr 2012 12:48:30 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com>
In-Reply-To: <4F982F18.2080902@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Thanks for this mammoth patch.  My comments are below.
>
> Roger Pau Monne writes ("[Xen-devel] [PATCH v3 3/5] libxl: call hotplug s=
cripts from libxl for vbd"):
>> This is a rather big change, that adds the necessary machinery to perform
>> hotplug script calling from libxl for Linux. This patch launches the nec=
essary
>> scripts to attach and detach PHY and TAP backend types (Qemu doesn't
>> use hotplug scripts).
>>
>> Here's a list of the major changes introduced:
>
> Can you please wrap your commit messages to no more than 75
> characters ?  Some vcs's indent them.  And of course they get indented
> when we reply leading to wrap damage.
>
>>   * libxl__devices_destroy no longer calls libxl__device_destroy, and in=
stead
>>     calls libxl__initiate_device_remove, so we can disconnect the device=
 and
>>     execute the necessary hotplug scripts instead of just deleting the b=
ackend
>>     entries. So libxl__devices_destroy now uses the event library, and s=
o does
>>     libxl_domain_destroy.
>
> So we no longer have any function which will synchronously and
> immediately destroy a domain and throw away everything to do with it.
> Is it actually the case that you think such a function cannot be
> provided ?

It can be provided, but we should create another command or add an
option to "destroy" (like -f), that doesn't wait for backend
disconnection and just nukes both frontend/backend xenstore entries.
This will also prevent us from executing hotplug scripts, and could lead
to unexpected results.

With this series we wait for the backend to disconnect for 10s, and if
it doesn't respond we nuke the frontend and wait for another 10s. If
after that it fails to disconnect we nuke the remaining backend xenstore
entries.

>>   * Added a check in xen-hotplug-common.sh, so scripts are only executed=
 from
>>     udev when using xend. xl adds a disable_udev=3Dy to xenstore private=
 directory
>>     and with the modification of the udev rules every call from udev gets
>>     HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is=
 passed
>>     and points to a value, the hotplug script is not executed.
>
> WDYM "points to a value"?  Did you just mean "is set to a nonempty
> value" ?  I'm not convinced by the name of this variable.  Shouldn't
> it have Xen in the name, and specify its own sense ?  Eg,
> XEN_HOTPLUG_DISABLE or something ?

This was decided with Ian Campbell, but I have no strong feelings one
way or another, so I don't mind changing it, please read my comment =

below regarding the naming.

>> +SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"tap*", ENV{HOTPLUG_GATE}=3D"=
/libxl/$env{XENBUS_PATH}/disable_udev", RUN+=3D"/etc/xen/scripts/blktap $en=
v{ACTION}"
> ...
>> +# Hack to prevent the execution of hotplug scripts from udev if the dom=
ain
>> +# has been launched from libxl
>> +if [ -n "${HOTPLUG_GATE}" ]&&  \
>> +   `xenstore-read "$HOTPLUG_GATE">/dev/null 2>&1`; then
>> +    exit 0
>> +fi
>
> Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
> like the idea of being able to pass some random other xenstore path.

Anyway, I will have to pass an environmental variable when calling the =

script from udev, I can rename this to UDEV_CALL=3D1 if that sounds better.

> Also: this xenstore path should be a relative path, ie one relative to
> the xenstore home of domain running this part of the tools.  That way
> the scripts can be easily and automatically disabled for dom0 and
> enabled in driver domains.

Something like:

/libxl/<domid>/disable_udev?

So that it embraces the whole domain instead of just applying to a =

single device?

>
>> +    /* compatibility addon to keep udev rules */
>> +    flexarray_append(private, "disable_udev");
>> +    flexarray_append(private, "y");
>
> We would normally use "1" for true in xenstore.
  >
>>       libxl__device_generic_add(gc,&device,
>> -                             libxl__xs_kvs_of_flexarray(gc, back, back-=
>count),
>> -                             libxl__xs_kvs_of_flexarray(gc, front, fron=
t->count));
>> +                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
>> +                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
>> +                    libxl__xs_kvs_of_flexarray(gc, private, private->co=
unt));
>> +
>> +    switch(disk->backend) {
>> +    case LIBXL_DISK_BACKEND_PHY:
>> +    case LIBXL_DISK_BACKEND_TAP:
>> +        rc =3D libxl__initiate_device_add(egc, ao,&device);
>> +        if (rc) goto out_free;
>> +        break;
>> +    case LIBXL_DISK_BACKEND_QDISK:
>> +    default:
>> +        libxl__ao_complete(egc, ao, 0);
>> +        break;
>> +    }
>
> Does this really need no confirmation from qemu ?

Qemu is not even started here, and it doesn't use any kind of hotplug
scripts, so I think I can safely say yes.

>
>>   out_free:
>> +    flexarray_free(private);
>> +out_free_b:
>>       flexarray_free(back);
>> +out_free_f:
>>       flexarray_free(front);
>
> It would be much better to allocate these from the gc somehow.
> Failing that, perhaps we could initialise them to NULL and free
> them iff necessary on the exit path:

Ok.

>    out:
>        ...
>        if (back)  flexarray_free(back);
>        if (front) flexarray_free(front);
> etc.
>
>>   int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>> @@ -1442,7 +1484,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint=
32_t domid,
>>       if (rc !=3D 0) goto out;
>>
>>       rc =3D libxl__initiate_device_remove(egc, ao,&device);
>> -    if (rc) goto out;
>> +    switch(rc) {
>> +    case 1:
>> +        /* event added */
>
> I think this terminology "event added" is confusingly wrong.  What you
> mean is "event queued", I think.  You should change this everywhere.
> But before you do that, please see what I write below about your
> approach to libxl__initiate_device_remove.

Ok.

>> @@ -1666,11 +1719,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t =
domid, libxl_device_disk *disk)
>>       ret =3D 0;
>>
>>       libxl_device_disk_remove(ctx, domid, disks + i, 0);
>> -    libxl_device_disk_add(ctx, domid, disk);
>> +    libxl_device_disk_add(ctx, domid, disk, 0);
>
> This needs a /* fixme-ao */ because inside-libxl callers are not
> allowed to invent an ao_how*, even NULL.  You need to mark every
> occurrence of these that way.

Ok.

>> @@ -1884,8 +1937,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t =
domid, libxl_device_nic *nic)
>>       flexarray_append(front, libxl__sprintf(gc,
>>                                       LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic=
->mac)));
>>       libxl__device_generic_add(gc,&device,
>> -                             libxl__xs_kvs_of_flexarray(gc, back, back-=
>count),
>> -                             libxl__xs_kvs_of_flexarray(gc, front, fron=
t->count));
>> +                            libxl__xs_kvs_of_flexarray(gc, back, back->=
count),
>> +                            libxl__xs_kvs_of_flexarray(gc, front, front=
->count),
>> +                            NULL);
>
> Likewise.  Also unintentional indentation change ?  (In several more
> places, too.)

Ok, I will try to spot these.

>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 3675afe..de598ad 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_dom=
ain_config *d_config,
>>       store_libxl_entry(gc, domid,&d_config->b_info);
>>
>>       for (i =3D 0; i<  d_config->num_disks; i++) {
>> -        ret =3D libxl_device_disk_add(ctx, domid,&d_config->disks[i]);
>> +        ret =3D libxl_device_disk_add(ctx, domid,&d_config->disks[i], 0=
);
>
> Here in xl simply passing 0 is correct.
>
>> +char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
>> +{
>> +    return libxl__sprintf(gc, "/libxl/backend/%s/%u/%d",
>> +                          libxl__device_kind_to_string(device->backend_=
kind),
>> +                          device->domid, device->devid);
>> +}
>
> Did you want to use GCSPRINTF ?

Changed, thanks.

>
>> +    rc =3D libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
>
> This is not correct.  You need to do something more with the exit
> status of the hotplug script than simply throwing it away as you do in
> hotplug_exited.  libxl__device_hotplug needs to take a callback from
> the caller so that it can notify the caller when the hotplug script
> has exited.
>
> You need to not allow the ao to complete until the hotplug script has
> exited.  Otherwise you will enter hotplug_exited after the
> libxl__hotplug_state has been destroyed with the ao.

Ok, I think I've changed most of this stuff, and unified device =

addition/destruction on the same event, since it's just a matter of wait =

-> execute hotplug.

> If it's too slow and you need to time out, you need to send the
> hotplug script a signal, and then wait for it to exit.  If necessary
> that signal could be SIGKILL; SIGKILL can be relied on to cause the
> hotplug script to actually terminate and thus the hotplug_exited
> callback to occur.
>

Where is the best place to handle this? From what I see, we have no =

helper for doing this, so I guess I will have to use waitpid or =

something similar?

>> +/*
>> + * Return codes:
>> + * 1 Success and event(s) HAVE BEEN added
>> + * 0 Success and NO events were added
>> + *<  0 Error
>> + *
>> + * Since this function can be called several times, and several events
>> + * can be added to the same context, the user has to call
>> + * libxl__ao_complete when necessary (if no events are added).
>> + */
>>   int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>>                                     libxl__device *dev)
>
> This comment should be in the header file near the declaration.
> And indeed if you had put it there you would have discovered another
> comment already there describing the old behaviour, which you have now
> left behind as an erroneous comment.

Done.

> And I think the new interface is entirely wrong.  How does the caller
> know when to complete the ao if libxl__initiate_device_remove never
> calls back ?
>
> You need to split this into two functions: one with the current
> interface which is a simple wrapper, used for all the existing call
> sites, and one which never completes any ao but which always makes a
> callback when the operation is complete.  That callback should be used
> by the caller of libxl__initiate_device_remove to do whatever it needs
> to, which might include completing the ao.

I understand what you are saying, but I have trouble thinking of a =

correct way to do this, since multiple events can be added to the same =

ao, and the libxl__initiate_device_remove "callback" will be called more =

than once, how do I know when I have to call ao_complete?

> At the moment, AFAICT from reading your code, the caller's ao will be
> completed by the first nontrivial device remove to complete, ie a bug.
>
>> -int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>> +int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
>> +                               libxl__device *dev)
> ...
>> +    rc =3D libxl__ev_devstate_wait(gc,&aorm->ds, device_add_callback,
>> +                                 state_path, XenbusStateInitWait,
>> +                                 LIBXL_INIT_TIMEOUT * 1000);
>> +    if (rc) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device =
%"
>> +                                          PRIu32, dev->devid);
>> +        libxl__ev_devstate_cancel(gc,&aorm->ds);
>
> This cancel is not necessary, because device_add_cleanup will do
> this.  (Or at least it should do; I haven't checked.)

Removed.

>> +        goto out_fail;
>> +    }
>> +
>> +    return 0;
>> +
>> +out_fail:
>> +    assert(rc);
>> +    device_add_cleanup(gc, aorm);
>> +    return rc;
>> +out_ok:
>
> ^ blank line needed after the return.
>
>> +    rc =3D libxl__device_hotplug(gc, dev, CONNECT);
>> +    libxl__ao_complete(egc, ao, 0);
>> +    return rc;
>> +}
>
> Some of my comments about initiate_device_remove's callback probably
> apply here too.  In particular, I have found it is often better to
> make a callback-queueing function always call the callback right away,
> recursively, on the error path.  The result is that the function can
> return void, which simplifies callers considerably.
>
> Whichever way you do it you do need to document your choices about
> reentrancy.
>
>> +static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
>> +                           pid_t pid, int status)
>> +{
>> +    libxl__hotplug_state *hs =3D CONTAINER_OF(child, *hs, child);
>> +    EGC_GC;
>> +
>> +    if (status) {
>> +        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
>> +                                                  : LIBXL__LOG_WARNING,
>> +                                      "hotplug child", pid, status);
>> +    }
>
> As I say, this needs to make a callback.

Sure.

>> +int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **=
env)
>> +{
>
> It would be better IMO to call this function "launch" or something,
> since it doesn't actually call exec in the parent (which is what I
> think a function called "exec" should do).

libxl__hotplug_launch it is.

>> +    libxl__hotplug_state *hs;
>> +
>> +    hs =3D libxl__zalloc(gc, sizeof(*hs));
>
> How about
>      GCNEW(hs)
> ?
>
>> +    if (!pid) {
>> +        /* child */
>> +        signal(SIGCHLD, SIG_DFL);
>
> What is this for ?  Is the problem that children of libxl otherwise
> inherit a weird SIGCHLD disposition ?  If so you need to fix this in
> libxl__exec, probably in a separate patch - and you probably need to
> sort out sigprocmask too in case the libxl caller has set up something
> weird.  This is something that ought to go in a new patch.
>
>> +    if (libxl__ev_child_inuse(&hs->child)) {
>> +        hs->rc =3D rc;
>
> Under what circumstances will rc!=3D0 here ?  Surely that is the success
> path?  It might be easier simply to have "out:" be only the error
> path.  The success path always has _inuse and the failure path never
> does.
>
>> +/* Action to pass to hotplug caller functions */
>> +typedef enum {
>> +    CONNECT =3D 1,
>> +    DISCONNECT =3D 2
>> +} libxl__hotplug_action;
>
> These names are rather too generic, I think.

I've changed them to HOTPLUG_CONNECT and HOTPLUG_DISCONNECT.

>> +typedef struct libxl__hotplug_state libxl__hotplug_state;
>> +
>> +struct libxl__hotplug_state {
>> +    /* public, result, caller may only read in callback */
>> +    int rc;
>> +    /* private for implementation */
>> +    libxl__ev_child child;
>> +};
>
> And this is where the callback member ought to go, in the public
> part, with a note saying it should be set by the caller.
>
> Is there any provision for timeout here ?  Would here be a good place
> to do the timeout, rather than higher up the stack ?
>
> Also you might find it better to move the args and env and so forth
> into the hotplug_state.  That way, for example, you can actually
> produce a useful message when the script fails.
>
>> +/*
>> + * libxl__hotplug_exec is an internal function that should not be used
>> + * directly, all hotplug script calls have to implement and use
>> + * libxl__device_hotplug.
>> + */
>> +_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
>> +                                  libxl__hotplug_action action);
>> +_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
>> +                                char **env);
>
> Why does libxl__hotplug_exec need to be declared here at all then ?
> Could it be static in libxl_hotplug.c ?

No, because libxl_linux uses libxl_hotplug_launch, which is supposed to =

be a common launcher for both Linux and NetBSD.

>
>> +/* Hotplug scripts helpers */
>> +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
>> +{
>> +    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>
> Why not use CTX ?  For that matter, if you use my new LOG macros you
> don't need to refer to CTX at all.
>
>> +    script =3D libxl__xs_read(gc, XBT_NULL,
>> +                            libxl__sprintf(gc, "%s/%s", be_path, "scrip=
t"));
>> +    if (!script) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %=
s",
>> +                                          be_path);
>
> You need to log the errno.
>
>> +    f_env =3D flexarray_make(9, 1);
>> +    if (!f_env) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>> +                   "unable to create environment array");
>> +        return NULL;
>> +    }
>
> Isn't this an allocation failure which should be dealt with by
> libxl__alloc_failed ?

Done, I think we should set a macro for

libxl__alloc_failed(ctx, __func__, 0,0);

Because I'm using that on more than one place.
>
>> +    flexarray_set(f_env, nr++, "XENBUS_TYPE");
>> +    flexarray_set(f_env, nr++, (char *)
>> +                  libxl__device_kind_to_string(dev->backend_kind));
>
> Why is the cast needed ?

Not sure, probably slipped from some other place, it's removed now.

>
>> +    flexarray_set(f_env, nr++, "XENBUS_PATH");
>> +    flexarray_set(f_env, nr++,
>> +                  libxl__sprintf(gc, "backend/%s/%u/%d",
>> +                  libxl__device_kind_to_string(dev->backend_kind),
>> +                  dev->domid, dev->devid));
>
> GCSPRINTF might help shorten this ?

Done.

>
> For that matter, you've called libxl__device_kind_to_string twice.
> Calling it only once would make this easier to read.
>
> I won't comment any more on places where I think GCSPRINTF,
> LOG/LOGE/LOGEV and CTX might usefully replace what you have written.

I'm trying to spot most of them, but it's quite difficult. Are we going =

to do a massive replace of this at some point?

>
>> +    env =3D get_hotplug_env(gc, dev);
>> +    if (!env)
>> +        return -1;
>
> Surely this should never fail as it just results in allocation failure ?
>
> This function seems to be supposed to return an rc value, so return -1
> is wrong.
>
>> +    args =3D (char **) flexarray_contents(f_args);
>
> Why is the cast needed ?
>
>> +    what =3D libxl__sprintf(gc, "%s %s", args[0],
>> +                          action =3D=3D CONNECT ? "connect" : "disconne=
ct");
>
> Surely
>
>    action =3D=3D CONNECT ? "connect" :
>    action =3D=3D DISCONNECT ? "disconnect" : abort()
>
> ?

Done!

>> +    rc =3D libxl__hotplug_exec(gc, args[0], args, env);
>> +    if (rc) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scrip=
ts for "
>> +                                          "device %"PRIu32, dev->devid);
>
> libxl__hotplug_exec ought to do all the logging.  That means that all
> the information needed to do so should be passed to it, including the
> domid (which you don't currently log) and the device id.  That should
> probably be filled in by its caller in the libxl__hotplug_state
> struct.
>
>> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlev=
el/xl/xl.c
>> index c4f7c52..ce7a2b2 100644
>> --- a/tools/python/xen/lowlevel/xl/xl.c
>> +++ b/tools/python/xen/lowlevel/xl/xl.c
>> @@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self,=
 PyObject *args)
>>       int domid;
>>       if ( !PyArg_ParseTuple(args, "i",&domid) )
>>           return NULL;
>> -    if ( libxl_domain_destroy(self->ctx, domid) ) {
>> +    if ( libxl_domain_destroy(self->ctx, domid, NULL) ) {
>
> I think this is correct.  Or, at least, we don't currently provide any
> asynchronous capability in the Python code and I don't mind not doing
> so.
>
> Ian.

Thanks for the review!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:48:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNBX-0005vr-9L; Thu, 26 Apr 2012 11:48:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SNNBU-0005vm-S3
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 11:48:29 +0000
Received: from [85.158.143.35:3851] by server-1.bemta-4.messagelabs.com id
	7D/A2-20925-C06399F4; Thu, 26 Apr 2012 11:48:28 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335440905!11698662!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14810 invoked from network); 26 Apr 2012 11:48:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:48:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192176380"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 07:48:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 07:48:24 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SNNBQ-0006Sw-KF;
	Thu, 26 Apr 2012 12:48:24 +0100
Message-ID: <4F99360E.2010201@citrix.com>
Date: Thu, 26 Apr 2012 12:48:30 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com>
In-Reply-To: <4F982F18.2080902@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson escribi=F3:
> Thanks for this mammoth patch.  My comments are below.
>
> Roger Pau Monne writes ("[Xen-devel] [PATCH v3 3/5] libxl: call hotplug s=
cripts from libxl for vbd"):
>> This is a rather big change, that adds the necessary machinery to perform
>> hotplug script calling from libxl for Linux. This patch launches the nec=
essary
>> scripts to attach and detach PHY and TAP backend types (Qemu doesn't
>> use hotplug scripts).
>>
>> Here's a list of the major changes introduced:
>
> Can you please wrap your commit messages to no more than 75
> characters ?  Some vcs's indent them.  And of course they get indented
> when we reply leading to wrap damage.
>
>>   * libxl__devices_destroy no longer calls libxl__device_destroy, and in=
stead
>>     calls libxl__initiate_device_remove, so we can disconnect the device=
 and
>>     execute the necessary hotplug scripts instead of just deleting the b=
ackend
>>     entries. So libxl__devices_destroy now uses the event library, and s=
o does
>>     libxl_domain_destroy.
>
> So we no longer have any function which will synchronously and
> immediately destroy a domain and throw away everything to do with it.
> Is it actually the case that you think such a function cannot be
> provided ?

It can be provided, but we should create another command or add an
option to "destroy" (like -f), that doesn't wait for backend
disconnection and just nukes both frontend/backend xenstore entries.
This will also prevent us from executing hotplug scripts, and could lead
to unexpected results.

With this series we wait for the backend to disconnect for 10s, and if
it doesn't respond we nuke the frontend and wait for another 10s. If
after that it fails to disconnect we nuke the remaining backend xenstore
entries.

>>   * Added a check in xen-hotplug-common.sh, so scripts are only executed=
 from
>>     udev when using xend. xl adds a disable_udev=3Dy to xenstore private=
 directory
>>     and with the modification of the udev rules every call from udev gets
>>     HOTPLUG_GATE passed, that points to disable_udev. If HOTPLUG_GATE is=
 passed
>>     and points to a value, the hotplug script is not executed.
>
> WDYM "points to a value"?  Did you just mean "is set to a nonempty
> value" ?  I'm not convinced by the name of this variable.  Shouldn't
> it have Xen in the name, and specify its own sense ?  Eg,
> XEN_HOTPLUG_DISABLE or something ?

This was decided with Ian Campbell, but I have no strong feelings one
way or another, so I don't mind changing it, please read my comment =

below regarding the naming.

>> +SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"tap*", ENV{HOTPLUG_GATE}=3D"=
/libxl/$env{XENBUS_PATH}/disable_udev", RUN+=3D"/etc/xen/scripts/blktap $en=
v{ACTION}"
> ...
>> +# Hack to prevent the execution of hotplug scripts from udev if the dom=
ain
>> +# has been launched from libxl
>> +if [ -n "${HOTPLUG_GATE}" ]&&  \
>> +   `xenstore-read "$HOTPLUG_GATE">/dev/null 2>&1`; then
>> +    exit 0
>> +fi
>
> Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
> like the idea of being able to pass some random other xenstore path.

Anyway, I will have to pass an environmental variable when calling the =

script from udev, I can rename this to UDEV_CALL=3D1 if that sounds better.

> Also: this xenstore path should be a relative path, ie one relative to
> the xenstore home of domain running this part of the tools.  That way
> the scripts can be easily and automatically disabled for dom0 and
> enabled in driver domains.

Something like:

/libxl/<domid>/disable_udev?

So that it embraces the whole domain instead of just applying to a =

single device?

>
>> +    /* compatibility addon to keep udev rules */
>> +    flexarray_append(private, "disable_udev");
>> +    flexarray_append(private, "y");
>
> We would normally use "1" for true in xenstore.
  >
>>       libxl__device_generic_add(gc,&device,
>> -                             libxl__xs_kvs_of_flexarray(gc, back, back-=
>count),
>> -                             libxl__xs_kvs_of_flexarray(gc, front, fron=
t->count));
>> +                    libxl__xs_kvs_of_flexarray(gc, back, back->count),
>> +                    libxl__xs_kvs_of_flexarray(gc, front, front->count),
>> +                    libxl__xs_kvs_of_flexarray(gc, private, private->co=
unt));
>> +
>> +    switch(disk->backend) {
>> +    case LIBXL_DISK_BACKEND_PHY:
>> +    case LIBXL_DISK_BACKEND_TAP:
>> +        rc =3D libxl__initiate_device_add(egc, ao,&device);
>> +        if (rc) goto out_free;
>> +        break;
>> +    case LIBXL_DISK_BACKEND_QDISK:
>> +    default:
>> +        libxl__ao_complete(egc, ao, 0);
>> +        break;
>> +    }
>
> Does this really need no confirmation from qemu ?

Qemu is not even started here, and it doesn't use any kind of hotplug
scripts, so I think I can safely say yes.

>
>>   out_free:
>> +    flexarray_free(private);
>> +out_free_b:
>>       flexarray_free(back);
>> +out_free_f:
>>       flexarray_free(front);
>
> It would be much better to allocate these from the gc somehow.
> Failing that, perhaps we could initialise them to NULL and free
> them iff necessary on the exit path:

Ok.

>    out:
>        ...
>        if (back)  flexarray_free(back);
>        if (front) flexarray_free(front);
> etc.
>
>>   int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>> @@ -1442,7 +1484,18 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint=
32_t domid,
>>       if (rc !=3D 0) goto out;
>>
>>       rc =3D libxl__initiate_device_remove(egc, ao,&device);
>> -    if (rc) goto out;
>> +    switch(rc) {
>> +    case 1:
>> +        /* event added */
>
> I think this terminology "event added" is confusingly wrong.  What you
> mean is "event queued", I think.  You should change this everywhere.
> But before you do that, please see what I write below about your
> approach to libxl__initiate_device_remove.

Ok.

>> @@ -1666,11 +1719,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t =
domid, libxl_device_disk *disk)
>>       ret =3D 0;
>>
>>       libxl_device_disk_remove(ctx, domid, disks + i, 0);
>> -    libxl_device_disk_add(ctx, domid, disk);
>> +    libxl_device_disk_add(ctx, domid, disk, 0);
>
> This needs a /* fixme-ao */ because inside-libxl callers are not
> allowed to invent an ao_how*, even NULL.  You need to mark every
> occurrence of these that way.

Ok.

>> @@ -1884,8 +1937,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t =
domid, libxl_device_nic *nic)
>>       flexarray_append(front, libxl__sprintf(gc,
>>                                       LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic=
->mac)));
>>       libxl__device_generic_add(gc,&device,
>> -                             libxl__xs_kvs_of_flexarray(gc, back, back-=
>count),
>> -                             libxl__xs_kvs_of_flexarray(gc, front, fron=
t->count));
>> +                            libxl__xs_kvs_of_flexarray(gc, back, back->=
count),
>> +                            libxl__xs_kvs_of_flexarray(gc, front, front=
->count),
>> +                            NULL);
>
> Likewise.  Also unintentional indentation change ?  (In several more
> places, too.)

Ok, I will try to spot these.

>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 3675afe..de598ad 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -598,7 +598,7 @@ static int do_domain_create(libxl__gc *gc, libxl_dom=
ain_config *d_config,
>>       store_libxl_entry(gc, domid,&d_config->b_info);
>>
>>       for (i =3D 0; i<  d_config->num_disks; i++) {
>> -        ret =3D libxl_device_disk_add(ctx, domid,&d_config->disks[i]);
>> +        ret =3D libxl_device_disk_add(ctx, domid,&d_config->disks[i], 0=
);
>
> Here in xl simply passing 0 is correct.
>
>> +char *libxl__device_private_path(libxl__gc *gc, libxl__device *device)
>> +{
>> +    return libxl__sprintf(gc, "/libxl/backend/%s/%u/%d",
>> +                          libxl__device_kind_to_string(device->backend_=
kind),
>> +                          device->domid, device->devid);
>> +}
>
> Did you want to use GCSPRINTF ?

Changed, thanks.

>
>> +    rc =3D libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
>
> This is not correct.  You need to do something more with the exit
> status of the hotplug script than simply throwing it away as you do in
> hotplug_exited.  libxl__device_hotplug needs to take a callback from
> the caller so that it can notify the caller when the hotplug script
> has exited.
>
> You need to not allow the ao to complete until the hotplug script has
> exited.  Otherwise you will enter hotplug_exited after the
> libxl__hotplug_state has been destroyed with the ao.

Ok, I think I've changed most of this stuff, and unified device =

addition/destruction on the same event, since it's just a matter of wait =

-> execute hotplug.

> If it's too slow and you need to time out, you need to send the
> hotplug script a signal, and then wait for it to exit.  If necessary
> that signal could be SIGKILL; SIGKILL can be relied on to cause the
> hotplug script to actually terminate and thus the hotplug_exited
> callback to occur.
>

Where is the best place to handle this? From what I see, we have no =

helper for doing this, so I guess I will have to use waitpid or =

something similar?

>> +/*
>> + * Return codes:
>> + * 1 Success and event(s) HAVE BEEN added
>> + * 0 Success and NO events were added
>> + *<  0 Error
>> + *
>> + * Since this function can be called several times, and several events
>> + * can be added to the same context, the user has to call
>> + * libxl__ao_complete when necessary (if no events are added).
>> + */
>>   int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
>>                                     libxl__device *dev)
>
> This comment should be in the header file near the declaration.
> And indeed if you had put it there you would have discovered another
> comment already there describing the old behaviour, which you have now
> left behind as an erroneous comment.

Done.

> And I think the new interface is entirely wrong.  How does the caller
> know when to complete the ao if libxl__initiate_device_remove never
> calls back ?
>
> You need to split this into two functions: one with the current
> interface which is a simple wrapper, used for all the existing call
> sites, and one which never completes any ao but which always makes a
> callback when the operation is complete.  That callback should be used
> by the caller of libxl__initiate_device_remove to do whatever it needs
> to, which might include completing the ao.

I understand what you are saying, but I have trouble thinking of a =

correct way to do this, since multiple events can be added to the same =

ao, and the libxl__initiate_device_remove "callback" will be called more =

than once, how do I know when I have to call ao_complete?

> At the moment, AFAICT from reading your code, the caller's ao will be
> completed by the first nontrivial device remove to complete, ie a bug.
>
>> -int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>> +int libxl__initiate_device_add(libxl__egc *egc, libxl__ao *ao,
>> +                               libxl__device *dev)
> ...
>> +    rc =3D libxl__ev_devstate_wait(gc,&aorm->ds, device_add_callback,
>> +                                 state_path, XenbusStateInitWait,
>> +                                 LIBXL_INIT_TIMEOUT * 1000);
>> +    if (rc) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to initialize device =
%"
>> +                                          PRIu32, dev->devid);
>> +        libxl__ev_devstate_cancel(gc,&aorm->ds);
>
> This cancel is not necessary, because device_add_cleanup will do
> this.  (Or at least it should do; I haven't checked.)

Removed.

>> +        goto out_fail;
>> +    }
>> +
>> +    return 0;
>> +
>> +out_fail:
>> +    assert(rc);
>> +    device_add_cleanup(gc, aorm);
>> +    return rc;
>> +out_ok:
>
> ^ blank line needed after the return.
>
>> +    rc =3D libxl__device_hotplug(gc, dev, CONNECT);
>> +    libxl__ao_complete(egc, ao, 0);
>> +    return rc;
>> +}
>
> Some of my comments about initiate_device_remove's callback probably
> apply here too.  In particular, I have found it is often better to
> make a callback-queueing function always call the callback right away,
> recursively, on the error path.  The result is that the function can
> return void, which simplifies callers considerably.
>
> Whichever way you do it you do need to document your choices about
> reentrancy.
>
>> +static void hotplug_exited(libxl__egc *egc, libxl__ev_child *child,
>> +                           pid_t pid, int status)
>> +{
>> +    libxl__hotplug_state *hs =3D CONTAINER_OF(child, *hs, child);
>> +    EGC_GC;
>> +
>> +    if (status) {
>> +        libxl_report_child_exitstatus(CTX, hs->rc ? LIBXL__LOG_ERROR
>> +                                                  : LIBXL__LOG_WARNING,
>> +                                      "hotplug child", pid, status);
>> +    }
>
> As I say, this needs to make a callback.

Sure.

>> +int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args, char **=
env)
>> +{
>
> It would be better IMO to call this function "launch" or something,
> since it doesn't actually call exec in the parent (which is what I
> think a function called "exec" should do).

libxl__hotplug_launch it is.

>> +    libxl__hotplug_state *hs;
>> +
>> +    hs =3D libxl__zalloc(gc, sizeof(*hs));
>
> How about
>      GCNEW(hs)
> ?
>
>> +    if (!pid) {
>> +        /* child */
>> +        signal(SIGCHLD, SIG_DFL);
>
> What is this for ?  Is the problem that children of libxl otherwise
> inherit a weird SIGCHLD disposition ?  If so you need to fix this in
> libxl__exec, probably in a separate patch - and you probably need to
> sort out sigprocmask too in case the libxl caller has set up something
> weird.  This is something that ought to go in a new patch.
>
>> +    if (libxl__ev_child_inuse(&hs->child)) {
>> +        hs->rc =3D rc;
>
> Under what circumstances will rc!=3D0 here ?  Surely that is the success
> path?  It might be easier simply to have "out:" be only the error
> path.  The success path always has _inuse and the failure path never
> does.
>
>> +/* Action to pass to hotplug caller functions */
>> +typedef enum {
>> +    CONNECT =3D 1,
>> +    DISCONNECT =3D 2
>> +} libxl__hotplug_action;
>
> These names are rather too generic, I think.

I've changed them to HOTPLUG_CONNECT and HOTPLUG_DISCONNECT.

>> +typedef struct libxl__hotplug_state libxl__hotplug_state;
>> +
>> +struct libxl__hotplug_state {
>> +    /* public, result, caller may only read in callback */
>> +    int rc;
>> +    /* private for implementation */
>> +    libxl__ev_child child;
>> +};
>
> And this is where the callback member ought to go, in the public
> part, with a note saying it should be set by the caller.
>
> Is there any provision for timeout here ?  Would here be a good place
> to do the timeout, rather than higher up the stack ?
>
> Also you might find it better to move the args and env and so forth
> into the hotplug_state.  That way, for example, you can actually
> produce a useful message when the script fails.
>
>> +/*
>> + * libxl__hotplug_exec is an internal function that should not be used
>> + * directly, all hotplug script calls have to implement and use
>> + * libxl__device_hotplug.
>> + */
>> +_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
>> +                                  libxl__hotplug_action action);
>> +_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **args,
>> +                                char **env);
>
> Why does libxl__hotplug_exec need to be declared here at all then ?
> Could it be static in libxl_hotplug.c ?

No, because libxl_linux uses libxl_hotplug_launch, which is supposed to =

be a common launcher for both Linux and NetBSD.

>
>> +/* Hotplug scripts helpers */
>> +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
>> +{
>> +    libxl_ctx *ctx =3D libxl__gc_owner(gc);
>
> Why not use CTX ?  For that matter, if you use my new LOG macros you
> don't need to refer to CTX at all.
>
>> +    script =3D libxl__xs_read(gc, XBT_NULL,
>> +                            libxl__sprintf(gc, "%s/%s", be_path, "scrip=
t"));
>> +    if (!script) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %=
s",
>> +                                          be_path);
>
> You need to log the errno.
>
>> +    f_env =3D flexarray_make(9, 1);
>> +    if (!f_env) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>> +                   "unable to create environment array");
>> +        return NULL;
>> +    }
>
> Isn't this an allocation failure which should be dealt with by
> libxl__alloc_failed ?

Done, I think we should set a macro for

libxl__alloc_failed(ctx, __func__, 0,0);

Because I'm using that on more than one place.
>
>> +    flexarray_set(f_env, nr++, "XENBUS_TYPE");
>> +    flexarray_set(f_env, nr++, (char *)
>> +                  libxl__device_kind_to_string(dev->backend_kind));
>
> Why is the cast needed ?

Not sure, probably slipped from some other place, it's removed now.

>
>> +    flexarray_set(f_env, nr++, "XENBUS_PATH");
>> +    flexarray_set(f_env, nr++,
>> +                  libxl__sprintf(gc, "backend/%s/%u/%d",
>> +                  libxl__device_kind_to_string(dev->backend_kind),
>> +                  dev->domid, dev->devid));
>
> GCSPRINTF might help shorten this ?

Done.

>
> For that matter, you've called libxl__device_kind_to_string twice.
> Calling it only once would make this easier to read.
>
> I won't comment any more on places where I think GCSPRINTF,
> LOG/LOGE/LOGEV and CTX might usefully replace what you have written.

I'm trying to spot most of them, but it's quite difficult. Are we going =

to do a massive replace of this at some point?

>
>> +    env =3D get_hotplug_env(gc, dev);
>> +    if (!env)
>> +        return -1;
>
> Surely this should never fail as it just results in allocation failure ?
>
> This function seems to be supposed to return an rc value, so return -1
> is wrong.
>
>> +    args =3D (char **) flexarray_contents(f_args);
>
> Why is the cast needed ?
>
>> +    what =3D libxl__sprintf(gc, "%s %s", args[0],
>> +                          action =3D=3D CONNECT ? "connect" : "disconne=
ct");
>
> Surely
>
>    action =3D=3D CONNECT ? "connect" :
>    action =3D=3D DISCONNECT ? "disconnect" : abort()
>
> ?

Done!

>> +    rc =3D libxl__hotplug_exec(gc, args[0], args, env);
>> +    if (rc) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable execute hotplug scrip=
ts for "
>> +                                          "device %"PRIu32, dev->devid);
>
> libxl__hotplug_exec ought to do all the logging.  That means that all
> the information needed to do so should be passed to it, including the
> domid (which you don't currently log) and the device id.  That should
> probably be filled in by its caller in the libxl__hotplug_state
> struct.
>
>> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlev=
el/xl/xl.c
>> index c4f7c52..ce7a2b2 100644
>> --- a/tools/python/xen/lowlevel/xl/xl.c
>> +++ b/tools/python/xen/lowlevel/xl/xl.c
>> @@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self,=
 PyObject *args)
>>       int domid;
>>       if ( !PyArg_ParseTuple(args, "i",&domid) )
>>           return NULL;
>> -    if ( libxl_domain_destroy(self->ctx, domid) ) {
>> +    if ( libxl_domain_destroy(self->ctx, domid, NULL) ) {
>
> I think this is correct.  Or, at least, we don't currently provide any
> asynchronous capability in the Python code and I don't mind not doing
> so.
>
> Ian.

Thanks for the review!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNId-0006Kl-Qx; Thu, 26 Apr 2012 11:55:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNNIb-0006Kc-RM
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 11:55:50 +0000
Received: from [85.158.139.83:44459] by server-5.bemta-5.messagelabs.com id
	26/BE-13566-4C7399F4; Thu, 26 Apr 2012 11:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335441347!25604848!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18547 invoked from network); 26 Apr 2012 11:55:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:55:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12153917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:55:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 12:55:18 +0100
Message-ID: <1335441317.28015.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 12:55:17 +0100
In-Reply-To: <1335435995180-5667212.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, George.Dunlap@citrix.com, Dieter
	Bloms <dieter@bloms.de>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 11:26 +0100, Fantu wrote:
> Dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
> usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
> 25249:a4e7fce6ee2b)
> vi Makefile # removed dist-kernel to not compile kernel

xen-unstable.hg hasn't (or shouldn't have been) building a kernel for a
long time -- are you really seeing it do so?

> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
> 
> -------------------------
> Recent regression:
> -------------
> - CRITICAL - PV domU unable to start, freeze on config parsing, with this
> output and nothing else:
> xl create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg

Can you run with "xl -vvv create"?

What is in lucid.cfg?

> -------------
> - On hvm domU start, domU work also this output on xl create:
> libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
> range, valid values are within range from 1 to 65535

This is no doubt an issue with 25244:e428eae1838c (CCing author). I
suspect the problem is that you are not setting any scheduler options
but it is unconditionally setting them. I think what it really should be
doing, is reading the current settings, updating those which the user
has specified and writing them back. I'm not sure how best to achieve
that in the libxl api though (CCing some scheduler folks)

> -------------------------
> 
> If you need further details tell me and I will post back
> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 11:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 11:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNId-0006Kl-Qx; Thu, 26 Apr 2012 11:55:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNNIb-0006Kc-RM
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 11:55:50 +0000
Received: from [85.158.139.83:44459] by server-5.bemta-5.messagelabs.com id
	26/BE-13566-4C7399F4; Thu, 26 Apr 2012 11:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335441347!25604848!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18547 invoked from network); 26 Apr 2012 11:55:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 11:55:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12153917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 11:55:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 12:55:18 +0100
Message-ID: <1335441317.28015.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 12:55:17 +0100
In-Reply-To: <1335435995180-5667212.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, George.Dunlap@citrix.com, Dieter
	Bloms <dieter@bloms.de>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 11:26 +0100, Fantu wrote:
> Dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
> usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
> 25249:a4e7fce6ee2b)
> vi Makefile # removed dist-kernel to not compile kernel

xen-unstable.hg hasn't (or shouldn't have been) building a kernel for a
long time -- are you really seeing it do so?

> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
> 
> -------------------------
> Recent regression:
> -------------
> - CRITICAL - PV domU unable to start, freeze on config parsing, with this
> output and nothing else:
> xl create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg

Can you run with "xl -vvv create"?

What is in lucid.cfg?

> -------------
> - On hvm domU start, domU work also this output on xl create:
> libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
> range, valid values are within range from 1 to 65535

This is no doubt an issue with 25244:e428eae1838c (CCing author). I
suspect the problem is that you are not setting any scheduler options
but it is unconditionally setting them. I think what it really should be
doing, is reading the current settings, updating those which the user
has specified and writing them back. I'm not sure how best to achieve
that in the libxl api though (CCing some scheduler folks)

> -------------------------
> 
> If you need further details tell me and I will post back
> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:01:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNO4-0006dL-7y; Thu, 26 Apr 2012 12:01:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNNO2-0006d5-C0
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:01:26 +0000
Received: from [85.158.143.35:53445] by server-3.bemta-4.messagelabs.com id
	9C/4C-05853-519399F4; Thu, 26 Apr 2012 12:01:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335441678!10574421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13127 invoked from network); 26 Apr 2012 12:01:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12154049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 12:01:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 13:01:17 +0100
Date: Thu, 26 Apr 2012 13:07:32 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335439154.28015.119.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Ian Campbell wrote:
> > > > [  408.127439] BUG: unable to handle kernel paging request at af00003e
> > > > [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> > > > [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> > > > [  408.144532] Oops: 0000 [#1] SMP
> > > > [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> > > > [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> > > > x_tables xen_evtchn xenfs bridge stp loop snd_p]
> > > > [  408.194797]
> > > > [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> > > > (2.6.32-5-xen-686 #1) PowerEdge R710
> > > > [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> > > > [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> > > > [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> > > > [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> > > > [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> > > > [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> > > > task=f3de50c0 task.ti=f33be000)
> > > > [  408.241508] Stack:
> > > > [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> > > > f4f0c500 c10dc048
> > > > [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> > > > c1006767 00000000 00000000
> > > > [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> > > > 0000000c 00001000 00000000
> > > > [  408.267509] Call Trace:
> > > > [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> > > > [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> > > > [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> > > > [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> > > > [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> > > > [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> > > > [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> > > > [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> > > > [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > > [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> > > > [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > > [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> > > > [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> > > > [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> > > > [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> > > > [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> > > > [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> > > > 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> > > > [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> > > > [  408.382512] CR2: 00000000af00003e
> > > > [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---
> >  
> > This looks like a classic direct_IO/AIO not working bug: it could be
> > because the m2p_override is not working correctly or it might not even
> > be present at all in this kernel (it went upstream in 2.6.38).
> > It only started showing now because qemu-xen-traditional switched to
> > O_DIRECT.
> 
> This kernel had VM_FOREIGN and PageForeign etc rather than the
> m2p_override. Could be that we need to extend VM_FOREIGN to cover rant
> mapped pages?
> 
> That's actually a fair chunk of dev work, not just a simple backport.
> 
> However this kernel does have blktap so why is qemu based AIO being used
> at all?
 
If blktap is present and working then libxl only uses QEMU for
qcow/qcow2 disk images.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:01:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNO4-0006dL-7y; Thu, 26 Apr 2012 12:01:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNNO2-0006d5-C0
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:01:26 +0000
Received: from [85.158.143.35:53445] by server-3.bemta-4.messagelabs.com id
	9C/4C-05853-519399F4; Thu, 26 Apr 2012 12:01:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335441678!10574421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13127 invoked from network); 26 Apr 2012 12:01:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12154049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 12:01:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 13:01:17 +0100
Date: Thu, 26 Apr 2012 13:07:32 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335439154.28015.119.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Ian Campbell wrote:
> > > > [  408.127439] BUG: unable to handle kernel paging request at af00003e
> > > > [  408.133612] IP: [<c10941f8>] set_page_dirty+0x1e/0x4a
> > > > [  408.138726] *pdpt = 0000000033232027 *pde = 0000000000000000
> > > > [  408.144532] Oops: 0000 [#1] SMP
> > > > [  408.147825] last sysfs file: /sys/devices/vif-1-0/uevent
> > > > [  408.153200] Modules linked in: xt_physdev iptable_filter ip_tables
> > > > x_tables xen_evtchn xenfs bridge stp loop snd_p]
> > > > [  408.194797]
> > > > [  408.196359] Pid: 1942, comm: qemu-system-i38 Not tainted
> > > > (2.6.32-5-xen-686 #1) PowerEdge R710
> > > > [  408.204938] EIP: 0061:[<c10941f8>] EFLAGS: 00010286 CPU: 0
> > > > [  408.210485] EIP is at set_page_dirty+0x1e/0x4a
> > > > [  408.214991] EAX: af000006 EBX: 00000000 ECX: c4ad7680 EDX: 41000001
> > > > [  408.221317] ESI: c4ad7680 EDI: f4f0c54c EBP: f3353200 ESP: f33bfdb8
> > > > [  408.227644]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> > > > [  408.233104] Process qemu-system-i38 (pid: 1942, ti=f33be000
> > > > task=f3de50c0 task.ti=f33be000)
> > > > [  408.241508] Stack:
> > > > [  408.243588]  c10944f0 00000000 f4f0c500 c10d991a f33533c8 f3353200
> > > > f4f0c500 c10dc048
> > > > [  408.251128] <0> 00000001 00001000 00000000 c10dcc44 00000001
> > > > c1006767 00000000 00000000
> > > > [  408.259189] <0> d4646070 00000000 f2f0869c f3ff4900 00000000
> > > > 0000000c 00001000 00000000
> > > > [  408.267509] Call Trace:
> > > > [  408.270025]  [<c10944f0>] ? set_page_dirty_lock+0x22/0x30
> > > > [  408.275486]  [<c10d991a>] ? bio_set_pages_dirty+0x22/0x2f
> > > > [  408.280944]  [<c10dc048>] ? dio_bio_submit+0x3c/0x57
> > > > [  408.285970]  [<c10dcc44>] ? __blockdev_direct_IO+0x903/0xaed
> > > > [  408.291691]  [<c1006767>] ? xen_restore_fl_direct_end+0x0/0x1
> > > > [  408.297500]  [<f62a2494>] ? ext3_direct_IO+0xed/0x18d [ext3]
> > > > [  408.303219]  [<f62a2e2b>] ? ext3_get_block+0x0/0xd1 [ext3]
> > > > [  408.308764]  [<c1090687>] ? generic_file_aio_read+0xf9/0x57b
> > > > [  408.314483]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > > [  408.320376]  [<c1006770>] ? check_events+0x8/0xc
> > > > [  408.325056]  [<c1006040>] ? xen_force_evtchn_callback+0xc/0x10
> > > > [  408.330949]  [<c109058e>] ? generic_file_aio_read+0x0/0x57b
> > > > [  408.336584]  [<c10e3725>] ? aio_rw_vect_retry+0x61/0x122
> > > > [  408.341955]  [<c10e45fa>] ? aio_run_iocb+0x61/0xef
> > > > [  408.346809]  [<c10e4ec9>] ? sys_io_submit+0x409/0x49c
> > > > [  408.351923]  [<c1008f9c>] ? syscall_call+0x7/0xb
> > > > [  408.356600] Code: c3 f6 00 10 75 04 f0 80 08 10 31 c0 c3 89 c1 8b
> > > > 40 10 8b 11 f7 c2 00 00 01 00 74 07 b8 ec 71 3d
> > > > [  408.375492] EIP: [<c10941f8>] set_page_dirty+0x1e/0x4a SS:ESP 0069:f33bfdb8
> > > > [  408.382512] CR2: 00000000af00003e
> > > > [  408.385894] ---[ end trace 9ce48eb2f06897bf ]---
> >  
> > This looks like a classic direct_IO/AIO not working bug: it could be
> > because the m2p_override is not working correctly or it might not even
> > be present at all in this kernel (it went upstream in 2.6.38).
> > It only started showing now because qemu-xen-traditional switched to
> > O_DIRECT.
> 
> This kernel had VM_FOREIGN and PageForeign etc rather than the
> m2p_override. Could be that we need to extend VM_FOREIGN to cover rant
> mapped pages?
> 
> That's actually a fair chunk of dev work, not just a simple backport.
> 
> However this kernel does have blktap so why is qemu based AIO being used
> at all?
 
If blktap is present and working then libxl only uses QEMU for
qcow/qcow2 disk images.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:06:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNSs-0006sK-19; Thu, 26 Apr 2012 12:06:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNNSp-0006sD-TN
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 12:06:24 +0000
Received: from [85.158.139.83:41916] by server-11.bemta-5.messagelabs.com id
	EB/EC-12959-F3A399F4; Thu, 26 Apr 2012 12:06:23 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335441981!25606743!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2890 invoked from network); 26 Apr 2012 12:06:22 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 12:06:22 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNNSn-00060j-1x
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 05:06:21 -0700
Date: Thu, 26 Apr 2012 05:06:21 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335441981052-5667398.post@n5.nabble.com>
In-Reply-To: <1335441317.28015.127.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
> Can you run with "xl -vvv create"?
> What is in lucid.cfg?
> 

Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl
configuration file used:
-------------------------------
lucid.cfg
---------
name="lucid"
vcpus=2
memory=512
disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
'/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader = '/usr/bin/pygrub'
-------------------------------

xl -vvv create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda1, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda2, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=tap
libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
# And after freeze



--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667398.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:06:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNSs-0006sK-19; Thu, 26 Apr 2012 12:06:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNNSp-0006sD-TN
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 12:06:24 +0000
Received: from [85.158.139.83:41916] by server-11.bemta-5.messagelabs.com id
	EB/EC-12959-F3A399F4; Thu, 26 Apr 2012 12:06:23 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335441981!25606743!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2890 invoked from network); 26 Apr 2012 12:06:22 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 12:06:22 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNNSn-00060j-1x
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 05:06:21 -0700
Date: Thu, 26 Apr 2012 05:06:21 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335441981052-5667398.post@n5.nabble.com>
In-Reply-To: <1335441317.28015.127.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
> Can you run with "xl -vvv create"?
> What is in lucid.cfg?
> 

Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl
configuration file used:
-------------------------------
lucid.cfg
---------
name="lucid"
vcpus=2
memory=512
disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
'/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader = '/usr/bin/pygrub'
-------------------------------

xl -vvv create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda1, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda2, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=tap
libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
# And after freeze



--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667398.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:06:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNT7-0006tP-DN; Thu, 26 Apr 2012 12:06:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNNT5-0006t7-N7
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:06:39 +0000
Received: from [85.158.143.35:23304] by server-2.bemta-4.messagelabs.com id
	AE/74-17550-F4A399F4; Thu, 26 Apr 2012 12:06:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335441998!11701427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1455 invoked from network); 26 Apr 2012 12:06:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12154207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 12:06:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 13:06:37 +0100
Message-ID: <1335441996.28015.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 26 Apr 2012 13:06:36 +0100
In-Reply-To: <4F99360E.2010201@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDEyOjQ4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIEphY2tzb24gZXNjcmliacOzOgo+ID4gVGhhbmtzIGZvciB0aGlzIG1hbW1vdGggcGF0
Y2guICBNeSBjb21tZW50cyBhcmUgYmVsb3cuCj4gPgo+ID4gUm9nZXIgUGF1IE1vbm5lIHdyaXRl
cyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB2MyAzLzVdIGxpYnhsOiBjYWxsIGhvdHBsdWcgc2NyaXB0
cyBmcm9tIGxpYnhsIGZvciB2YmQiKToKPiA+PiBUaGlzIGlzIGEgcmF0aGVyIGJpZyBjaGFuZ2Us
IHRoYXQgYWRkcyB0aGUgbmVjZXNzYXJ5IG1hY2hpbmVyeSB0byBwZXJmb3JtCj4gPj4gaG90cGx1
ZyBzY3JpcHQgY2FsbGluZyBmcm9tIGxpYnhsIGZvciBMaW51eC4gVGhpcyBwYXRjaCBsYXVuY2hl
cyB0aGUgbmVjZXNzYXJ5Cj4gPj4gc2NyaXB0cyB0byBhdHRhY2ggYW5kIGRldGFjaCBQSFkgYW5k
IFRBUCBiYWNrZW5kIHR5cGVzIChRZW11IGRvZXNuJ3QKPiA+PiB1c2UgaG90cGx1ZyBzY3JpcHRz
KS4KPiA+Pgo+ID4+IEhlcmUncyBhIGxpc3Qgb2YgdGhlIG1ham9yIGNoYW5nZXMgaW50cm9kdWNl
ZDoKPiA+Cj4gPiBDYW4geW91IHBsZWFzZSB3cmFwIHlvdXIgY29tbWl0IG1lc3NhZ2VzIHRvIG5v
IG1vcmUgdGhhbiA3NQo+ID4gY2hhcmFjdGVycyA/ICBTb21lIHZjcydzIGluZGVudCB0aGVtLiAg
QW5kIG9mIGNvdXJzZSB0aGV5IGdldCBpbmRlbnRlZAo+ID4gd2hlbiB3ZSByZXBseSBsZWFkaW5n
IHRvIHdyYXAgZGFtYWdlLgo+ID4KPiA+PiAgICogbGlieGxfX2RldmljZXNfZGVzdHJveSBubyBs
b25nZXIgY2FsbHMgbGlieGxfX2RldmljZV9kZXN0cm95LCBhbmQgaW5zdGVhZAo+ID4+ICAgICBj
YWxscyBsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSwgc28gd2UgY2FuIGRpc2Nvbm5lY3Qg
dGhlIGRldmljZSBhbmQKPiA+PiAgICAgZXhlY3V0ZSB0aGUgbmVjZXNzYXJ5IGhvdHBsdWcgc2Ny
aXB0cyBpbnN0ZWFkIG9mIGp1c3QgZGVsZXRpbmcgdGhlIGJhY2tlbmQKPiA+PiAgICAgZW50cmll
cy4gU28gbGlieGxfX2RldmljZXNfZGVzdHJveSBub3cgdXNlcyB0aGUgZXZlbnQgbGlicmFyeSwg
YW5kIHNvIGRvZXMKPiA+PiAgICAgbGlieGxfZG9tYWluX2Rlc3Ryb3kuCj4gPgo+ID4gU28gd2Ug
bm8gbG9uZ2VyIGhhdmUgYW55IGZ1bmN0aW9uIHdoaWNoIHdpbGwgc3luY2hyb25vdXNseSBhbmQK
PiA+IGltbWVkaWF0ZWx5IGRlc3Ryb3kgYSBkb21haW4gYW5kIHRocm93IGF3YXkgZXZlcnl0aGlu
ZyB0byBkbyB3aXRoIGl0Lgo+ID4gSXMgaXQgYWN0dWFsbHkgdGhlIGNhc2UgdGhhdCB5b3UgdGhp
bmsgc3VjaCBhIGZ1bmN0aW9uIGNhbm5vdCBiZQo+ID4gcHJvdmlkZWQgPwo+IAo+IEl0IGNhbiBi
ZSBwcm92aWRlZCwgYnV0IHdlIHNob3VsZCBjcmVhdGUgYW5vdGhlciBjb21tYW5kIG9yIGFkZCBh
bgo+IG9wdGlvbiB0byAiZGVzdHJveSIgKGxpa2UgLWYpLCB0aGF0IGRvZXNuJ3Qgd2FpdCBmb3Ig
YmFja2VuZAo+IGRpc2Nvbm5lY3Rpb24gYW5kIGp1c3QgbnVrZXMgYm90aCBmcm9udGVuZC9iYWNr
ZW5kIHhlbnN0b3JlIGVudHJpZXMuCj4gVGhpcyB3aWxsIGFsc28gcHJldmVudCB1cyBmcm9tIGV4
ZWN1dGluZyBob3RwbHVnIHNjcmlwdHMsIGFuZCBjb3VsZCBsZWFkCj4gdG8gdW5leHBlY3RlZCBy
ZXN1bHRzLgoKV2UgaGF2ZSBhIHBsYW4gb2YgYWN0aW9uIHRvIGZpeCB0aGlzIHByb3Blcmx5IGlu
IDQuMyAodmlhIHRoZSBEcml2ZXIgRG9tCnByb3RvY29sLCB3aGljaCBzZXBhcmF0ZXMgdGhlIGJh
Y2tlbmQgZnJvbSB0aGUgaG90cGx1ZyBpbmZvKS4KCkl0IHdvdWxkIElNSE8gYmUgYWNjZXB0YWJs
ZSBmb3IgNC4yIHRvIGtlZXAgb24gc2ltcGx5IG51a2luZyB0aGUKYmFja2VuZCwgYW5kIGFjY2Vw
dGluZyB0aGUgZG93bnNpZGVzIHdoaWNoIHRoaXMgZW50YWlscy4gQUZBSUsgdGhpcyBpcwpub3Qg
YSByZWdyZXNzaW9uIHZzIFhlbmQgLS0geGVuZCBhbHNvIGp1c3QgbnVrZXMgdGhlIGJhY2tlbmQg
KHBsZWFzZQpjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcgYWJvdXQgdGhpcykuCgo+ID4+ICAgKiBB
ZGRlZCBhIGNoZWNrIGluIHhlbi1ob3RwbHVnLWNvbW1vbi5zaCwgc28gc2NyaXB0cyBhcmUgb25s
eSBleGVjdXRlZCBmcm9tCj4gPj4gICAgIHVkZXYgd2hlbiB1c2luZyB4ZW5kLiB4bCBhZGRzIGEg
ZGlzYWJsZV91ZGV2PXkgdG8geGVuc3RvcmUgcHJpdmF0ZSBkaXJlY3RvcnkKPiA+PiAgICAgYW5k
IHdpdGggdGhlIG1vZGlmaWNhdGlvbiBvZiB0aGUgdWRldiBydWxlcyBldmVyeSBjYWxsIGZyb20g
dWRldiBnZXRzCj4gPj4gICAgIEhPVFBMVUdfR0FURSBwYXNzZWQsIHRoYXQgcG9pbnRzIHRvIGRp
c2FibGVfdWRldi4gSWYgSE9UUExVR19HQVRFIGlzIHBhc3NlZAo+ID4+ICAgICBhbmQgcG9pbnRz
IHRvIGEgdmFsdWUsIHRoZSBob3RwbHVnIHNjcmlwdCBpcyBub3QgZXhlY3V0ZWQuCj4gPgo+ID4g
V0RZTSAicG9pbnRzIHRvIGEgdmFsdWUiPyAgRGlkIHlvdSBqdXN0IG1lYW4gImlzIHNldCB0byBh
IG5vbmVtcHR5Cj4gPiB2YWx1ZSIgPyAgSSdtIG5vdCBjb252aW5jZWQgYnkgdGhlIG5hbWUgb2Yg
dGhpcyB2YXJpYWJsZS4gIFNob3VsZG4ndAo+ID4gaXQgaGF2ZSBYZW4gaW4gdGhlIG5hbWUsIGFu
ZCBzcGVjaWZ5IGl0cyBvd24gc2Vuc2UgPyAgRWcsCj4gPiBYRU5fSE9UUExVR19ESVNBQkxFIG9y
IHNvbWV0aGluZyA/Cj4gCj4gVGhpcyB3YXMgZGVjaWRlZCB3aXRoIElhbiBDYW1wYmVsbCwKClBs
ZWFzZSBkbyBmZWVsIGZyZWUgdG8gdGFrZSBteSBoYWxmLWJha2VkIHN1Z2dlc3Rpb25zIGFuZCBt
YWtlIHRoZW0Kc2Vuc2libGUgOy0pCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:06:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNT7-0006tP-DN; Thu, 26 Apr 2012 12:06:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNNT5-0006t7-N7
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:06:39 +0000
Received: from [85.158.143.35:23304] by server-2.bemta-4.messagelabs.com id
	AE/74-17550-F4A399F4; Thu, 26 Apr 2012 12:06:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335441998!11701427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1455 invoked from network); 26 Apr 2012 12:06:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12154207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 12:06:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 13:06:37 +0100
Message-ID: <1335441996.28015.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 26 Apr 2012 13:06:36 +0100
In-Reply-To: <4F99360E.2010201@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDEyOjQ4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIEphY2tzb24gZXNjcmliacOzOgo+ID4gVGhhbmtzIGZvciB0aGlzIG1hbW1vdGggcGF0
Y2guICBNeSBjb21tZW50cyBhcmUgYmVsb3cuCj4gPgo+ID4gUm9nZXIgUGF1IE1vbm5lIHdyaXRl
cyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB2MyAzLzVdIGxpYnhsOiBjYWxsIGhvdHBsdWcgc2NyaXB0
cyBmcm9tIGxpYnhsIGZvciB2YmQiKToKPiA+PiBUaGlzIGlzIGEgcmF0aGVyIGJpZyBjaGFuZ2Us
IHRoYXQgYWRkcyB0aGUgbmVjZXNzYXJ5IG1hY2hpbmVyeSB0byBwZXJmb3JtCj4gPj4gaG90cGx1
ZyBzY3JpcHQgY2FsbGluZyBmcm9tIGxpYnhsIGZvciBMaW51eC4gVGhpcyBwYXRjaCBsYXVuY2hl
cyB0aGUgbmVjZXNzYXJ5Cj4gPj4gc2NyaXB0cyB0byBhdHRhY2ggYW5kIGRldGFjaCBQSFkgYW5k
IFRBUCBiYWNrZW5kIHR5cGVzIChRZW11IGRvZXNuJ3QKPiA+PiB1c2UgaG90cGx1ZyBzY3JpcHRz
KS4KPiA+Pgo+ID4+IEhlcmUncyBhIGxpc3Qgb2YgdGhlIG1ham9yIGNoYW5nZXMgaW50cm9kdWNl
ZDoKPiA+Cj4gPiBDYW4geW91IHBsZWFzZSB3cmFwIHlvdXIgY29tbWl0IG1lc3NhZ2VzIHRvIG5v
IG1vcmUgdGhhbiA3NQo+ID4gY2hhcmFjdGVycyA/ICBTb21lIHZjcydzIGluZGVudCB0aGVtLiAg
QW5kIG9mIGNvdXJzZSB0aGV5IGdldCBpbmRlbnRlZAo+ID4gd2hlbiB3ZSByZXBseSBsZWFkaW5n
IHRvIHdyYXAgZGFtYWdlLgo+ID4KPiA+PiAgICogbGlieGxfX2RldmljZXNfZGVzdHJveSBubyBs
b25nZXIgY2FsbHMgbGlieGxfX2RldmljZV9kZXN0cm95LCBhbmQgaW5zdGVhZAo+ID4+ICAgICBj
YWxscyBsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSwgc28gd2UgY2FuIGRpc2Nvbm5lY3Qg
dGhlIGRldmljZSBhbmQKPiA+PiAgICAgZXhlY3V0ZSB0aGUgbmVjZXNzYXJ5IGhvdHBsdWcgc2Ny
aXB0cyBpbnN0ZWFkIG9mIGp1c3QgZGVsZXRpbmcgdGhlIGJhY2tlbmQKPiA+PiAgICAgZW50cmll
cy4gU28gbGlieGxfX2RldmljZXNfZGVzdHJveSBub3cgdXNlcyB0aGUgZXZlbnQgbGlicmFyeSwg
YW5kIHNvIGRvZXMKPiA+PiAgICAgbGlieGxfZG9tYWluX2Rlc3Ryb3kuCj4gPgo+ID4gU28gd2Ug
bm8gbG9uZ2VyIGhhdmUgYW55IGZ1bmN0aW9uIHdoaWNoIHdpbGwgc3luY2hyb25vdXNseSBhbmQK
PiA+IGltbWVkaWF0ZWx5IGRlc3Ryb3kgYSBkb21haW4gYW5kIHRocm93IGF3YXkgZXZlcnl0aGlu
ZyB0byBkbyB3aXRoIGl0Lgo+ID4gSXMgaXQgYWN0dWFsbHkgdGhlIGNhc2UgdGhhdCB5b3UgdGhp
bmsgc3VjaCBhIGZ1bmN0aW9uIGNhbm5vdCBiZQo+ID4gcHJvdmlkZWQgPwo+IAo+IEl0IGNhbiBi
ZSBwcm92aWRlZCwgYnV0IHdlIHNob3VsZCBjcmVhdGUgYW5vdGhlciBjb21tYW5kIG9yIGFkZCBh
bgo+IG9wdGlvbiB0byAiZGVzdHJveSIgKGxpa2UgLWYpLCB0aGF0IGRvZXNuJ3Qgd2FpdCBmb3Ig
YmFja2VuZAo+IGRpc2Nvbm5lY3Rpb24gYW5kIGp1c3QgbnVrZXMgYm90aCBmcm9udGVuZC9iYWNr
ZW5kIHhlbnN0b3JlIGVudHJpZXMuCj4gVGhpcyB3aWxsIGFsc28gcHJldmVudCB1cyBmcm9tIGV4
ZWN1dGluZyBob3RwbHVnIHNjcmlwdHMsIGFuZCBjb3VsZCBsZWFkCj4gdG8gdW5leHBlY3RlZCBy
ZXN1bHRzLgoKV2UgaGF2ZSBhIHBsYW4gb2YgYWN0aW9uIHRvIGZpeCB0aGlzIHByb3Blcmx5IGlu
IDQuMyAodmlhIHRoZSBEcml2ZXIgRG9tCnByb3RvY29sLCB3aGljaCBzZXBhcmF0ZXMgdGhlIGJh
Y2tlbmQgZnJvbSB0aGUgaG90cGx1ZyBpbmZvKS4KCkl0IHdvdWxkIElNSE8gYmUgYWNjZXB0YWJs
ZSBmb3IgNC4yIHRvIGtlZXAgb24gc2ltcGx5IG51a2luZyB0aGUKYmFja2VuZCwgYW5kIGFjY2Vw
dGluZyB0aGUgZG93bnNpZGVzIHdoaWNoIHRoaXMgZW50YWlscy4gQUZBSUsgdGhpcyBpcwpub3Qg
YSByZWdyZXNzaW9uIHZzIFhlbmQgLS0geGVuZCBhbHNvIGp1c3QgbnVrZXMgdGhlIGJhY2tlbmQg
KHBsZWFzZQpjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcgYWJvdXQgdGhpcykuCgo+ID4+ICAgKiBB
ZGRlZCBhIGNoZWNrIGluIHhlbi1ob3RwbHVnLWNvbW1vbi5zaCwgc28gc2NyaXB0cyBhcmUgb25s
eSBleGVjdXRlZCBmcm9tCj4gPj4gICAgIHVkZXYgd2hlbiB1c2luZyB4ZW5kLiB4bCBhZGRzIGEg
ZGlzYWJsZV91ZGV2PXkgdG8geGVuc3RvcmUgcHJpdmF0ZSBkaXJlY3RvcnkKPiA+PiAgICAgYW5k
IHdpdGggdGhlIG1vZGlmaWNhdGlvbiBvZiB0aGUgdWRldiBydWxlcyBldmVyeSBjYWxsIGZyb20g
dWRldiBnZXRzCj4gPj4gICAgIEhPVFBMVUdfR0FURSBwYXNzZWQsIHRoYXQgcG9pbnRzIHRvIGRp
c2FibGVfdWRldi4gSWYgSE9UUExVR19HQVRFIGlzIHBhc3NlZAo+ID4+ICAgICBhbmQgcG9pbnRz
IHRvIGEgdmFsdWUsIHRoZSBob3RwbHVnIHNjcmlwdCBpcyBub3QgZXhlY3V0ZWQuCj4gPgo+ID4g
V0RZTSAicG9pbnRzIHRvIGEgdmFsdWUiPyAgRGlkIHlvdSBqdXN0IG1lYW4gImlzIHNldCB0byBh
IG5vbmVtcHR5Cj4gPiB2YWx1ZSIgPyAgSSdtIG5vdCBjb252aW5jZWQgYnkgdGhlIG5hbWUgb2Yg
dGhpcyB2YXJpYWJsZS4gIFNob3VsZG4ndAo+ID4gaXQgaGF2ZSBYZW4gaW4gdGhlIG5hbWUsIGFu
ZCBzcGVjaWZ5IGl0cyBvd24gc2Vuc2UgPyAgRWcsCj4gPiBYRU5fSE9UUExVR19ESVNBQkxFIG9y
IHNvbWV0aGluZyA/Cj4gCj4gVGhpcyB3YXMgZGVjaWRlZCB3aXRoIElhbiBDYW1wYmVsbCwKClBs
ZWFzZSBkbyBmZWVsIGZyZWUgdG8gdGFrZSBteSBoYWxmLWJha2VkIHN1Z2dlc3Rpb25zIGFuZCBt
YWtlIHRoZW0Kc2Vuc2libGUgOy0pCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:13:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNZ3-0007BC-8R; Thu, 26 Apr 2012 12:12:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SNNZ2-0007B5-1U
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:12:48 +0000
Received: from [85.158.138.51:39531] by server-7.bemta-3.messagelabs.com id
	43/26-03078-FBB399F4; Thu, 26 Apr 2012 12:12:47 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335442364!23915368!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12083 invoked from network); 26 Apr 2012 12:12:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="24564958"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:12:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:12:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SNNYx-0006xS-Kc;
	Thu, 26 Apr 2012 13:12:43 +0100
Message-ID: <4F993BC1.3070504@citrix.com>
Date: Thu, 26 Apr 2012 13:12:49 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com>
	<1335441996.28015.131.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335441996.28015.131.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBUaHUsIDIwMTItMDQtMjYgYXQgMTI6NDggKzAx
MDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gSWFuIEphY2tzb24gZXNjcmliacOzOgo+Pj4g
VGhhbmtzIGZvciB0aGlzIG1hbW1vdGggcGF0Y2guICBNeSBjb21tZW50cyBhcmUgYmVsb3cuCj4+
Pgo+Pj4gUm9nZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB2MyAzLzVd
IGxpYnhsOiBjYWxsIGhvdHBsdWcgc2NyaXB0cyBmcm9tIGxpYnhsIGZvciB2YmQiKToKPj4+PiBU
aGlzIGlzIGEgcmF0aGVyIGJpZyBjaGFuZ2UsIHRoYXQgYWRkcyB0aGUgbmVjZXNzYXJ5IG1hY2hp
bmVyeSB0byBwZXJmb3JtCj4+Pj4gaG90cGx1ZyBzY3JpcHQgY2FsbGluZyBmcm9tIGxpYnhsIGZv
ciBMaW51eC4gVGhpcyBwYXRjaCBsYXVuY2hlcyB0aGUgbmVjZXNzYXJ5Cj4+Pj4gc2NyaXB0cyB0
byBhdHRhY2ggYW5kIGRldGFjaCBQSFkgYW5kIFRBUCBiYWNrZW5kIHR5cGVzIChRZW11IGRvZXNu
J3QKPj4+PiB1c2UgaG90cGx1ZyBzY3JpcHRzKS4KPj4+Pgo+Pj4+IEhlcmUncyBhIGxpc3Qgb2Yg
dGhlIG1ham9yIGNoYW5nZXMgaW50cm9kdWNlZDoKPj4+IENhbiB5b3UgcGxlYXNlIHdyYXAgeW91
ciBjb21taXQgbWVzc2FnZXMgdG8gbm8gbW9yZSB0aGFuIDc1Cj4+PiBjaGFyYWN0ZXJzID8gIFNv
bWUgdmNzJ3MgaW5kZW50IHRoZW0uICBBbmQgb2YgY291cnNlIHRoZXkgZ2V0IGluZGVudGVkCj4+
PiB3aGVuIHdlIHJlcGx5IGxlYWRpbmcgdG8gd3JhcCBkYW1hZ2UuCj4+Pgo+Pj4+ICAgICogbGli
eGxfX2RldmljZXNfZGVzdHJveSBubyBsb25nZXIgY2FsbHMgbGlieGxfX2RldmljZV9kZXN0cm95
LCBhbmQgaW5zdGVhZAo+Pj4+ICAgICAgY2FsbHMgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1v
dmUsIHNvIHdlIGNhbiBkaXNjb25uZWN0IHRoZSBkZXZpY2UgYW5kCj4+Pj4gICAgICBleGVjdXRl
IHRoZSBuZWNlc3NhcnkgaG90cGx1ZyBzY3JpcHRzIGluc3RlYWQgb2YganVzdCBkZWxldGluZyB0
aGUgYmFja2VuZAo+Pj4+ICAgICAgZW50cmllcy4gU28gbGlieGxfX2RldmljZXNfZGVzdHJveSBu
b3cgdXNlcyB0aGUgZXZlbnQgbGlicmFyeSwgYW5kIHNvIGRvZXMKPj4+PiAgICAgIGxpYnhsX2Rv
bWFpbl9kZXN0cm95Lgo+Pj4gU28gd2Ugbm8gbG9uZ2VyIGhhdmUgYW55IGZ1bmN0aW9uIHdoaWNo
IHdpbGwgc3luY2hyb25vdXNseSBhbmQKPj4+IGltbWVkaWF0ZWx5IGRlc3Ryb3kgYSBkb21haW4g
YW5kIHRocm93IGF3YXkgZXZlcnl0aGluZyB0byBkbyB3aXRoIGl0Lgo+Pj4gSXMgaXQgYWN0dWFs
bHkgdGhlIGNhc2UgdGhhdCB5b3UgdGhpbmsgc3VjaCBhIGZ1bmN0aW9uIGNhbm5vdCBiZQo+Pj4g
cHJvdmlkZWQgPwo+PiBJdCBjYW4gYmUgcHJvdmlkZWQsIGJ1dCB3ZSBzaG91bGQgY3JlYXRlIGFu
b3RoZXIgY29tbWFuZCBvciBhZGQgYW4KPj4gb3B0aW9uIHRvICJkZXN0cm95IiAobGlrZSAtZiks
IHRoYXQgZG9lc24ndCB3YWl0IGZvciBiYWNrZW5kCj4+IGRpc2Nvbm5lY3Rpb24gYW5kIGp1c3Qg
bnVrZXMgYm90aCBmcm9udGVuZC9iYWNrZW5kIHhlbnN0b3JlIGVudHJpZXMuCj4+IFRoaXMgd2ls
bCBhbHNvIHByZXZlbnQgdXMgZnJvbSBleGVjdXRpbmcgaG90cGx1ZyBzY3JpcHRzLCBhbmQgY291
bGQgbGVhZAo+PiB0byB1bmV4cGVjdGVkIHJlc3VsdHMuCj4KPiBXZSBoYXZlIGEgcGxhbiBvZiBh
Y3Rpb24gdG8gZml4IHRoaXMgcHJvcGVybHkgaW4gNC4zICh2aWEgdGhlIERyaXZlciBEb20KPiBw
cm90b2NvbCwgd2hpY2ggc2VwYXJhdGVzIHRoZSBiYWNrZW5kIGZyb20gdGhlIGhvdHBsdWcgaW5m
bykuCj4KPiBJdCB3b3VsZCBJTUhPIGJlIGFjY2VwdGFibGUgZm9yIDQuMiB0byBrZWVwIG9uIHNp
bXBseSBudWtpbmcgdGhlCj4gYmFja2VuZCwgYW5kIGFjY2VwdGluZyB0aGUgZG93bnNpZGVzIHdo
aWNoIHRoaXMgZW50YWlscy4gQUZBSUsgdGhpcyBpcwo+IG5vdCBhIHJlZ3Jlc3Npb24gdnMgWGVu
ZCAtLSB4ZW5kIGFsc28ganVzdCBudWtlcyB0aGUgYmFja2VuZCAocGxlYXNlCj4gY29ycmVjdCBt
ZSBpZiBJIGFtIHdyb25nIGFib3V0IHRoaXMpLgoKVGhpcyBpcyBvayBpZiB3ZSBleGVjdXRlIGhv
dHBsdWcgc2NyaXB0cyB3aXRoIHVkZXYsIGJlY2F1c2UgdGhleSBhcmUgCmV4ZWN1dGVkIHdoZW4g
dGhlICJwaHlzaWNhbCIgZGV2aWNlIGlzIGRlc3Ryb3llZCwgYnV0IGlmIHdlIGhhdmUgdG8gCmxh
dW5jaCB0aGUgc2NyaXB0cyBmcm9tIHRoZSB0b29sc3RhY2ssIHRoZSBvbmx5IHdheSB0byBrbm93
IHRoYXQgdGhlIApwaHlzaWNhbCBkZXZpY2UgaXMgbm8gbG9uZ2VyIGluIHVzZSBpcyBieSB3YXRj
aGluZyB4ZW5zdG9yZSBiYWNrZW5kIAplbnRyaWVzLCB0aGF0J3Mgd2h5IHdlIGNhbm5vdCBudWtl
IHRoZW0gdW5sZXNzIGl0IGlzIG91ciBsYXN0IG9wdGlvbi4KCj4+Pj4gICAgKiBBZGRlZCBhIGNo
ZWNrIGluIHhlbi1ob3RwbHVnLWNvbW1vbi5zaCwgc28gc2NyaXB0cyBhcmUgb25seSBleGVjdXRl
ZCBmcm9tCj4+Pj4gICAgICB1ZGV2IHdoZW4gdXNpbmcgeGVuZC4geGwgYWRkcyBhIGRpc2FibGVf
dWRldj15IHRvIHhlbnN0b3JlIHByaXZhdGUgZGlyZWN0b3J5Cj4+Pj4gICAgICBhbmQgd2l0aCB0
aGUgbW9kaWZpY2F0aW9uIG9mIHRoZSB1ZGV2IHJ1bGVzIGV2ZXJ5IGNhbGwgZnJvbSB1ZGV2IGdl
dHMKPj4+PiAgICAgIEhPVFBMVUdfR0FURSBwYXNzZWQsIHRoYXQgcG9pbnRzIHRvIGRpc2FibGVf
dWRldi4gSWYgSE9UUExVR19HQVRFIGlzIHBhc3NlZAo+Pj4+ICAgICAgYW5kIHBvaW50cyB0byBh
IHZhbHVlLCB0aGUgaG90cGx1ZyBzY3JpcHQgaXMgbm90IGV4ZWN1dGVkLgo+Pj4gV0RZTSAicG9p
bnRzIHRvIGEgdmFsdWUiPyAgRGlkIHlvdSBqdXN0IG1lYW4gImlzIHNldCB0byBhIG5vbmVtcHR5
Cj4+PiB2YWx1ZSIgPyAgSSdtIG5vdCBjb252aW5jZWQgYnkgdGhlIG5hbWUgb2YgdGhpcyB2YXJp
YWJsZS4gIFNob3VsZG4ndAo+Pj4gaXQgaGF2ZSBYZW4gaW4gdGhlIG5hbWUsIGFuZCBzcGVjaWZ5
IGl0cyBvd24gc2Vuc2UgPyAgRWcsCj4+PiBYRU5fSE9UUExVR19ESVNBQkxFIG9yIHNvbWV0aGlu
ZyA/Cj4+IFRoaXMgd2FzIGRlY2lkZWQgd2l0aCBJYW4gQ2FtcGJlbGwsCj4KPiBQbGVhc2UgZG8g
ZmVlbCBmcmVlIHRvIHRha2UgbXkgaGFsZi1iYWtlZCBzdWdnZXN0aW9ucyBhbmQgbWFrZSB0aGVt
Cj4gc2Vuc2libGUgOy0pCj4KPiBJYW4uCj4KPgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:13:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNZ3-0007BC-8R; Thu, 26 Apr 2012 12:12:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SNNZ2-0007B5-1U
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:12:48 +0000
Received: from [85.158.138.51:39531] by server-7.bemta-3.messagelabs.com id
	43/26-03078-FBB399F4; Thu, 26 Apr 2012 12:12:47 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335442364!23915368!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12083 invoked from network); 26 Apr 2012 12:12:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="24564958"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 08:12:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 08:12:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SNNYx-0006xS-Kc;
	Thu, 26 Apr 2012 13:12:43 +0100
Message-ID: <4F993BC1.3070504@citrix.com>
Date: Thu, 26 Apr 2012 13:12:49 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com>
	<1335441996.28015.131.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335441996.28015.131.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SWFuIENhbXBiZWxsIGVzY3JpYmnDszoKPiBPbiBUaHUsIDIwMTItMDQtMjYgYXQgMTI6NDggKzAx
MDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gSWFuIEphY2tzb24gZXNjcmliacOzOgo+Pj4g
VGhhbmtzIGZvciB0aGlzIG1hbW1vdGggcGF0Y2guICBNeSBjb21tZW50cyBhcmUgYmVsb3cuCj4+
Pgo+Pj4gUm9nZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB2MyAzLzVd
IGxpYnhsOiBjYWxsIGhvdHBsdWcgc2NyaXB0cyBmcm9tIGxpYnhsIGZvciB2YmQiKToKPj4+PiBU
aGlzIGlzIGEgcmF0aGVyIGJpZyBjaGFuZ2UsIHRoYXQgYWRkcyB0aGUgbmVjZXNzYXJ5IG1hY2hp
bmVyeSB0byBwZXJmb3JtCj4+Pj4gaG90cGx1ZyBzY3JpcHQgY2FsbGluZyBmcm9tIGxpYnhsIGZv
ciBMaW51eC4gVGhpcyBwYXRjaCBsYXVuY2hlcyB0aGUgbmVjZXNzYXJ5Cj4+Pj4gc2NyaXB0cyB0
byBhdHRhY2ggYW5kIGRldGFjaCBQSFkgYW5kIFRBUCBiYWNrZW5kIHR5cGVzIChRZW11IGRvZXNu
J3QKPj4+PiB1c2UgaG90cGx1ZyBzY3JpcHRzKS4KPj4+Pgo+Pj4+IEhlcmUncyBhIGxpc3Qgb2Yg
dGhlIG1ham9yIGNoYW5nZXMgaW50cm9kdWNlZDoKPj4+IENhbiB5b3UgcGxlYXNlIHdyYXAgeW91
ciBjb21taXQgbWVzc2FnZXMgdG8gbm8gbW9yZSB0aGFuIDc1Cj4+PiBjaGFyYWN0ZXJzID8gIFNv
bWUgdmNzJ3MgaW5kZW50IHRoZW0uICBBbmQgb2YgY291cnNlIHRoZXkgZ2V0IGluZGVudGVkCj4+
PiB3aGVuIHdlIHJlcGx5IGxlYWRpbmcgdG8gd3JhcCBkYW1hZ2UuCj4+Pgo+Pj4+ICAgICogbGli
eGxfX2RldmljZXNfZGVzdHJveSBubyBsb25nZXIgY2FsbHMgbGlieGxfX2RldmljZV9kZXN0cm95
LCBhbmQgaW5zdGVhZAo+Pj4+ICAgICAgY2FsbHMgbGlieGxfX2luaXRpYXRlX2RldmljZV9yZW1v
dmUsIHNvIHdlIGNhbiBkaXNjb25uZWN0IHRoZSBkZXZpY2UgYW5kCj4+Pj4gICAgICBleGVjdXRl
IHRoZSBuZWNlc3NhcnkgaG90cGx1ZyBzY3JpcHRzIGluc3RlYWQgb2YganVzdCBkZWxldGluZyB0
aGUgYmFja2VuZAo+Pj4+ICAgICAgZW50cmllcy4gU28gbGlieGxfX2RldmljZXNfZGVzdHJveSBu
b3cgdXNlcyB0aGUgZXZlbnQgbGlicmFyeSwgYW5kIHNvIGRvZXMKPj4+PiAgICAgIGxpYnhsX2Rv
bWFpbl9kZXN0cm95Lgo+Pj4gU28gd2Ugbm8gbG9uZ2VyIGhhdmUgYW55IGZ1bmN0aW9uIHdoaWNo
IHdpbGwgc3luY2hyb25vdXNseSBhbmQKPj4+IGltbWVkaWF0ZWx5IGRlc3Ryb3kgYSBkb21haW4g
YW5kIHRocm93IGF3YXkgZXZlcnl0aGluZyB0byBkbyB3aXRoIGl0Lgo+Pj4gSXMgaXQgYWN0dWFs
bHkgdGhlIGNhc2UgdGhhdCB5b3UgdGhpbmsgc3VjaCBhIGZ1bmN0aW9uIGNhbm5vdCBiZQo+Pj4g
cHJvdmlkZWQgPwo+PiBJdCBjYW4gYmUgcHJvdmlkZWQsIGJ1dCB3ZSBzaG91bGQgY3JlYXRlIGFu
b3RoZXIgY29tbWFuZCBvciBhZGQgYW4KPj4gb3B0aW9uIHRvICJkZXN0cm95IiAobGlrZSAtZiks
IHRoYXQgZG9lc24ndCB3YWl0IGZvciBiYWNrZW5kCj4+IGRpc2Nvbm5lY3Rpb24gYW5kIGp1c3Qg
bnVrZXMgYm90aCBmcm9udGVuZC9iYWNrZW5kIHhlbnN0b3JlIGVudHJpZXMuCj4+IFRoaXMgd2ls
bCBhbHNvIHByZXZlbnQgdXMgZnJvbSBleGVjdXRpbmcgaG90cGx1ZyBzY3JpcHRzLCBhbmQgY291
bGQgbGVhZAo+PiB0byB1bmV4cGVjdGVkIHJlc3VsdHMuCj4KPiBXZSBoYXZlIGEgcGxhbiBvZiBh
Y3Rpb24gdG8gZml4IHRoaXMgcHJvcGVybHkgaW4gNC4zICh2aWEgdGhlIERyaXZlciBEb20KPiBw
cm90b2NvbCwgd2hpY2ggc2VwYXJhdGVzIHRoZSBiYWNrZW5kIGZyb20gdGhlIGhvdHBsdWcgaW5m
bykuCj4KPiBJdCB3b3VsZCBJTUhPIGJlIGFjY2VwdGFibGUgZm9yIDQuMiB0byBrZWVwIG9uIHNp
bXBseSBudWtpbmcgdGhlCj4gYmFja2VuZCwgYW5kIGFjY2VwdGluZyB0aGUgZG93bnNpZGVzIHdo
aWNoIHRoaXMgZW50YWlscy4gQUZBSUsgdGhpcyBpcwo+IG5vdCBhIHJlZ3Jlc3Npb24gdnMgWGVu
ZCAtLSB4ZW5kIGFsc28ganVzdCBudWtlcyB0aGUgYmFja2VuZCAocGxlYXNlCj4gY29ycmVjdCBt
ZSBpZiBJIGFtIHdyb25nIGFib3V0IHRoaXMpLgoKVGhpcyBpcyBvayBpZiB3ZSBleGVjdXRlIGhv
dHBsdWcgc2NyaXB0cyB3aXRoIHVkZXYsIGJlY2F1c2UgdGhleSBhcmUgCmV4ZWN1dGVkIHdoZW4g
dGhlICJwaHlzaWNhbCIgZGV2aWNlIGlzIGRlc3Ryb3llZCwgYnV0IGlmIHdlIGhhdmUgdG8gCmxh
dW5jaCB0aGUgc2NyaXB0cyBmcm9tIHRoZSB0b29sc3RhY2ssIHRoZSBvbmx5IHdheSB0byBrbm93
IHRoYXQgdGhlIApwaHlzaWNhbCBkZXZpY2UgaXMgbm8gbG9uZ2VyIGluIHVzZSBpcyBieSB3YXRj
aGluZyB4ZW5zdG9yZSBiYWNrZW5kIAplbnRyaWVzLCB0aGF0J3Mgd2h5IHdlIGNhbm5vdCBudWtl
IHRoZW0gdW5sZXNzIGl0IGlzIG91ciBsYXN0IG9wdGlvbi4KCj4+Pj4gICAgKiBBZGRlZCBhIGNo
ZWNrIGluIHhlbi1ob3RwbHVnLWNvbW1vbi5zaCwgc28gc2NyaXB0cyBhcmUgb25seSBleGVjdXRl
ZCBmcm9tCj4+Pj4gICAgICB1ZGV2IHdoZW4gdXNpbmcgeGVuZC4geGwgYWRkcyBhIGRpc2FibGVf
dWRldj15IHRvIHhlbnN0b3JlIHByaXZhdGUgZGlyZWN0b3J5Cj4+Pj4gICAgICBhbmQgd2l0aCB0
aGUgbW9kaWZpY2F0aW9uIG9mIHRoZSB1ZGV2IHJ1bGVzIGV2ZXJ5IGNhbGwgZnJvbSB1ZGV2IGdl
dHMKPj4+PiAgICAgIEhPVFBMVUdfR0FURSBwYXNzZWQsIHRoYXQgcG9pbnRzIHRvIGRpc2FibGVf
dWRldi4gSWYgSE9UUExVR19HQVRFIGlzIHBhc3NlZAo+Pj4+ICAgICAgYW5kIHBvaW50cyB0byBh
IHZhbHVlLCB0aGUgaG90cGx1ZyBzY3JpcHQgaXMgbm90IGV4ZWN1dGVkLgo+Pj4gV0RZTSAicG9p
bnRzIHRvIGEgdmFsdWUiPyAgRGlkIHlvdSBqdXN0IG1lYW4gImlzIHNldCB0byBhIG5vbmVtcHR5
Cj4+PiB2YWx1ZSIgPyAgSSdtIG5vdCBjb252aW5jZWQgYnkgdGhlIG5hbWUgb2YgdGhpcyB2YXJp
YWJsZS4gIFNob3VsZG4ndAo+Pj4gaXQgaGF2ZSBYZW4gaW4gdGhlIG5hbWUsIGFuZCBzcGVjaWZ5
IGl0cyBvd24gc2Vuc2UgPyAgRWcsCj4+PiBYRU5fSE9UUExVR19ESVNBQkxFIG9yIHNvbWV0aGlu
ZyA/Cj4+IFRoaXMgd2FzIGRlY2lkZWQgd2l0aCBJYW4gQ2FtcGJlbGwsCj4KPiBQbGVhc2UgZG8g
ZmVlbCBmcmVlIHRvIHRha2UgbXkgaGFsZi1iYWtlZCBzdWdnZXN0aW9ucyBhbmQgbWFrZSB0aGVt
Cj4gc2Vuc2libGUgOy0pCj4KPiBJYW4uCj4KPgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNZN-0007CS-LD; Thu, 26 Apr 2012 12:13:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNNZL-0007CE-Gb
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:13:07 +0000
Received: from [85.158.143.35:27376] by server-1.bemta-4.messagelabs.com id
	E5/A6-20925-2DB399F4; Thu, 26 Apr 2012 12:13:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335442358!8822508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19989 invoked from network); 26 Apr 2012 12:12:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:12:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12154334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 12:12:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 13:12:37 +0100
Date: Thu, 26 Apr 2012 13:18:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204261317160.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
	<alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
	<EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Sam Mulvey wrote:
> On Apr 25, 2012, at 8:50 AM, Stefano Stabellini wrote:
> 
>       It looks like the disk was opened correctly, maybe more logging will
>       tell us what is going wrong.
>       Could you please try the following patch?
> 
> domid: 1
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603: Created /var/run/tap directory
> Could not open /var/run/tap/qemu-read-1
> xen be: console-0: backend state: Unknown -> Initialising
> char device redirected to /dev/pts/2
> xen be: console-0: backend state: Initialising -> InitWait
> xen be: console-0: frontend not ready, ignoring
> xen be: console-0: bind evtchn port 70
> xen be: console-0: ring mfn 412787, remote port 2, local port 70, limit 1048576
> xen be: console-0: backend state: InitWait -> Connected
> xen be: qdisk-51712: backend state: Unknown -> Initialising
> xen be: qdisk-51712: frontend state: Unknown -> Initialising
> DEBUG blk_init 587
> DEBUG blk_init 602 filename=/var/finnix/finnix-104.iso
> DEBUG blk_init 613 protocol=raw
> DEBUG blk_init 622
> DEBUG blk_init 636
> xen be: qdisk-51712: create new bdrv (xenbus setup)
> DEBUG blk_init 659
> xen be: qdisk-51712: type "tap", fileproto "raw", filename "/var/finnix/finnix-104.iso", size 121708544 (116 MB)
> xen be: qdisk-51712: backend state: Initialising -> InitWait
> xen be: qdisk-51712: frontend not ready (yet)
> xs_read(): target get error. /local/domain/1/target.
> xen be: console-0: backend update: state
> xen be: console-0: frontend update: tty
> xen be: console-0: backend update: hotplug-status
> xen be: console-0: backend update: state
> xen be: console-0: backend update: state
> xen be: qdisk-51712: backend update: state
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: feature-barrier
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: info
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: sector-size
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: sectors
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: hotplug-status
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: state
> xen be: qdisk-51712: frontend not ready (yet)
> xen be core: displaystate setup failed
> (qemu) (qemu) xen be: console-0: backlog piling up, nobody listening?
 
It looks like the backend (QEMU) is waiting for the client to connect,
but it never happens.
Are you sure that blkfront is compiled in the guest's kernel?
I fail to see how this could work with XenD but not with Xl.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNZN-0007CS-LD; Thu, 26 Apr 2012 12:13:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNNZL-0007CE-Gb
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:13:07 +0000
Received: from [85.158.143.35:27376] by server-1.bemta-4.messagelabs.com id
	E5/A6-20925-2DB399F4; Thu, 26 Apr 2012 12:13:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335442358!8822508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19989 invoked from network); 26 Apr 2012 12:12:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:12:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12154334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 12:12:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 13:12:37 +0100
Date: Thu, 26 Apr 2012 13:18:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
Message-ID: <alpine.DEB.2.00.1204261317160.26786@kaball-desktop>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
	<alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
	<EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Sam Mulvey wrote:
> On Apr 25, 2012, at 8:50 AM, Stefano Stabellini wrote:
> 
>       It looks like the disk was opened correctly, maybe more logging will
>       tell us what is going wrong.
>       Could you please try the following patch?
> 
> domid: 1
> Warning: vlan 0 is not connected to host network
> -videoram option does not work with cirrus vga device model. Videoram set to 4M.
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:628: Init blktap pipes
> /home/sam/build/debug/xen/src/xen-4.1.2/tools/ioemu-qemu-xen/hw/xen_blktap.c:603: Created /var/run/tap directory
> Could not open /var/run/tap/qemu-read-1
> xen be: console-0: backend state: Unknown -> Initialising
> char device redirected to /dev/pts/2
> xen be: console-0: backend state: Initialising -> InitWait
> xen be: console-0: frontend not ready, ignoring
> xen be: console-0: bind evtchn port 70
> xen be: console-0: ring mfn 412787, remote port 2, local port 70, limit 1048576
> xen be: console-0: backend state: InitWait -> Connected
> xen be: qdisk-51712: backend state: Unknown -> Initialising
> xen be: qdisk-51712: frontend state: Unknown -> Initialising
> DEBUG blk_init 587
> DEBUG blk_init 602 filename=/var/finnix/finnix-104.iso
> DEBUG blk_init 613 protocol=raw
> DEBUG blk_init 622
> DEBUG blk_init 636
> xen be: qdisk-51712: create new bdrv (xenbus setup)
> DEBUG blk_init 659
> xen be: qdisk-51712: type "tap", fileproto "raw", filename "/var/finnix/finnix-104.iso", size 121708544 (116 MB)
> xen be: qdisk-51712: backend state: Initialising -> InitWait
> xen be: qdisk-51712: frontend not ready (yet)
> xs_read(): target get error. /local/domain/1/target.
> xen be: console-0: backend update: state
> xen be: console-0: frontend update: tty
> xen be: console-0: backend update: hotplug-status
> xen be: console-0: backend update: state
> xen be: console-0: backend update: state
> xen be: qdisk-51712: backend update: state
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: feature-barrier
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: info
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: sector-size
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: sectors
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: hotplug-status
> xen be: qdisk-51712: frontend not ready (yet)
> xen be: qdisk-51712: backend update: state
> xen be: qdisk-51712: frontend not ready (yet)
> xen be core: displaystate setup failed
> (qemu) (qemu) xen be: console-0: backlog piling up, nobody listening?
 
It looks like the backend (QEMU) is waiting for the client to connect,
but it never happens.
Are you sure that blkfront is compiled in the guest's kernel?
I fail to see how this could work with XenD but not with Xl.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 12:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNgb-0007Wv-Kx; Thu, 26 Apr 2012 12:20:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SNNga-0007Wq-Ag
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:20:36 +0000
Received: from [85.158.138.51:38207] by server-10.bemta-3.messagelabs.com id
	31/70-29478-19D399F4; Thu, 26 Apr 2012 12:20:33 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335442830!12919274!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7742 invoked from network); 26 Apr 2012 12:20:32 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 12:20:32 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 73A93102110EA;
	Thu, 26 Apr 2012 05:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Xfk8a9Qjb8OO; Thu, 26 Apr 2012 05:20:27 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 4BC37102110E7;
	Thu, 26 Apr 2012 05:20:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204261317160.26786@kaball-desktop>
Date: Thu, 26 Apr 2012 05:20:26 -0700
Message-Id: <CB570752-6B77-4DEF-A3A0-6B904C3146F4@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
	<alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
	<EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
	<alpine.DEB.2.00.1204261317160.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4139198701446866993=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4139198701446866993==
Content-Type: multipart/alternative; boundary="Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8"


--Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 26, 2012, at 5:18 AM, Stefano Stabellini wrote:

> It looks like the backend (QEMU) is waiting for the client to connect,
> but it never happens.
> Are you sure that blkfront is compiled in the guest's kernel?
> I fail to see how this could work with XenD but not with Xl.

It loads as a module in the initrd.    This guest is Finnix, a livecd =
which explicitly supports Xen.   I use it pretty frequently for testing =
or occasionally recovery stuff.

http://www.finnix.org/Finnix_for_VPS_providers#Xen


-Sam=

--Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 26, 2012, at 5:18 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">It looks like =
the backend (QEMU) is waiting for the client to connect,<br>but it never =
happens.<br>Are you sure that blkfront is compiled in the guest's =
kernel?<br>I fail to see how this could work with XenD but not with =
Xl.<br></span></blockquote></div><br><div>It loads as a module in the =
initrd. &nbsp; &nbsp;This guest is Finnix, a livecd which explicitly =
supports Xen. &nbsp; I use it pretty frequently for testing or =
occasionally recovery stuff.</div><div><br></div><div><a =
href=3D"http://www.finnix.org/Finnix_for_VPS_providers#Xen">http://www.fin=
nix.org/Finnix_for_VPS_providers#Xen</a></div><div><br></div><div><br></di=
v><div>-Sam</div></body></html>=

--Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8--


--===============4139198701446866993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4139198701446866993==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 12:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNNgb-0007Wv-Kx; Thu, 26 Apr 2012 12:20:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sam@tacomatelematics.com>) id 1SNNga-0007Wq-Ag
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:20:36 +0000
Received: from [85.158.138.51:38207] by server-10.bemta-3.messagelabs.com id
	31/70-29478-19D399F4; Thu, 26 Apr 2012 12:20:33 +0000
X-Env-Sender: sam@tacomatelematics.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335442830!12919274!1
X-Originating-IP: [173.160.255.210]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7742 invoked from network); 26 Apr 2012 12:20:32 -0000
Received: from tacomatelematics.com (HELO mail.tacomatelematics.com)
	(173.160.255.210)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 12:20:32 -0000
Received: from localhost (vac [127.0.0.1])
	by mail.tacomatelematics.com (Postfix) with ESMTP id 73A93102110EA;
	Thu, 26 Apr 2012 05:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tacomatelematics.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2
	tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001]
	autolearn=ham
Received: from mail.tacomatelematics.com ([127.0.0.1])
	by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Xfk8a9Qjb8OO; Thu, 26 Apr 2012 05:20:27 -0700 (PDT)
Received: from h100.sol.tact (unknown [131.191.104.174])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: sam@tacomatelematics.com)
	by mail.tacomatelematics.com (Postfix) with ESMTPSA id 4BC37102110E7;
	Thu, 26 Apr 2012 05:20:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Sam Mulvey <sam@tacomatelematics.com>
In-Reply-To: <alpine.DEB.2.00.1204261317160.26786@kaball-desktop>
Date: Thu, 26 Apr 2012 05:20:26 -0700
Message-Id: <CB570752-6B77-4DEF-A3A0-6B904C3146F4@tacomatelematics.com>
References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com>
	<alpine.DEB.2.00.1204241128400.26786@kaball-desktop>
	<9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com>
	<alpine.DEB.2.00.1204241356300.26786@kaball-desktop>
	<FEDDFC6D-1511-465D-B2D3-4758065CA730@tacomatelematics.com>
	<alpine.DEB.2.00.1204241751340.26786@kaball-desktop>
	<BAAC0D3A-E53E-4A81-BFFD-4B05AC86F8F8@tacomatelematics.com>
	<alpine.DEB.2.00.1204251637190.26786@kaball-desktop>
	<EADAF45F-3DFD-4E16-94CD-C6BCFCB19E81@tacomatelematics.com>
	<alpine.DEB.2.00.1204261317160.26786@kaball-desktop>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] no console when using xl toolstack xen 4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4139198701446866993=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4139198701446866993==
Content-Type: multipart/alternative; boundary="Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8"


--Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 26, 2012, at 5:18 AM, Stefano Stabellini wrote:

> It looks like the backend (QEMU) is waiting for the client to connect,
> but it never happens.
> Are you sure that blkfront is compiled in the guest's kernel?
> I fail to see how this could work with XenD but not with Xl.

It loads as a module in the initrd.    This guest is Finnix, a livecd =
which explicitly supports Xen.   I use it pretty frequently for testing =
or occasionally recovery stuff.

http://www.finnix.org/Finnix_for_VPS_providers#Xen


-Sam=

--Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 26, 2012, at 5:18 AM, Stefano Stabellini =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">It looks like =
the backend (QEMU) is waiting for the client to connect,<br>but it never =
happens.<br>Are you sure that blkfront is compiled in the guest's =
kernel?<br>I fail to see how this could work with XenD but not with =
Xl.<br></span></blockquote></div><br><div>It loads as a module in the =
initrd. &nbsp; &nbsp;This guest is Finnix, a livecd which explicitly =
supports Xen. &nbsp; I use it pretty frequently for testing or =
occasionally recovery stuff.</div><div><br></div><div><a =
href=3D"http://www.finnix.org/Finnix_for_VPS_providers#Xen">http://www.fin=
nix.org/Finnix_for_VPS_providers#Xen</a></div><div><br></div><div><br></di=
v><div>-Sam</div></body></html>=

--Apple-Mail=_D0EEC620-96A9-4014-AC2A-AB7EA20AD2B8--


--===============4139198701446866993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4139198701446866993==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 12:45:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:45:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNO44-0007oD-77; Thu, 26 Apr 2012 12:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SNO42-0007nl-KK
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:44:50 +0000
Received: from [85.158.138.51:49913] by server-9.bemta-3.messagelabs.com id
	73/A0-26691-143499F4; Thu, 26 Apr 2012 12:44:49 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335444287!23952648!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_23,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21440 invoked from network); 26 Apr 2012 12:44:48 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:44:48 -0000
Received: by bkty15 with SMTP id y15so1113706bkt.32
	for <multiple recipients>; Thu, 26 Apr 2012 05:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=fIFltkWYN4/1trFXAlyENA0h3Ynqpt38Tkp0GsyVpiQ=;
	b=jMR1ltFF6jC4FJwIDB7hpjSZIVbEf+/9cJaZEECJyYIgP5LP0cOAuA9pTtX8sgATtp
	3HV1s6Ux3ZaNZpKtnDL9hZp6wX4+4nwDcPKrEMi1lt3WhUFtTQgLthLyoWHmPU3463rR
	div1PssSI9mVTP+4WpNe2yc0Kpbqk1vqWZtiu7h7bGja8I73xtmos4By0XAJLPt0omK2
	K/pp36eXBN0oQkJAA8Gq2hu3gBLwX2Or+8JNs5Tzu3x/Daioe7zal9x67ucrYh2vYxeJ
	jA5zZlvWPJKrEViuFqDM4Q0JZer83O9cjn+ubNNUmwnAoqZ1UrdHIW8jh32AhVYwigFU
	WHFQ==
Received: by 10.205.133.11 with SMTP id hw11mr2292503bkc.12.1335444287556;
	Thu, 26 Apr 2012 05:44:47 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id e20sm5453244bkv.10.2012.04.26.05.44.45
	(version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 05:44:46 -0700 (PDT)
Message-ID: <4F99433C.8040505@xen.org>
Date: Thu, 26 Apr 2012 13:44:44 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-api@lists.xen.org, 
	xen-arm@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] Changes to mailing lists (i.e. archiving of old lists)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3513679024534402111=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3513679024534402111==
Content-Type: multipart/alternative;
 boundary="------------010406080209060802050908"

This is a multi-part message in MIME format.
--------------010406080209060802050908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

I have archived a number of mailing lists that have been inactive, because
a) they have fulfilled their purpose (i.e. the project for which they 
were created was completed or archived)
b) they have been inactive for a year
c) the discussion related to these are now happening elsewhere (e.g. on 
xen-devel)

What does archiving mean:

  * I moved the list to the Archived section of http://lists.xen.org/
  * I moved the list into emergency moderation (every post will be
    moderated) and new user
  * I removed the list from http://lists.xen.org/cgi-bin/mailman/listinfo

The lists that were archived are: xen-bugs, xen-cim, xen-introspect, 
xen-tools, xen-ia64-devel, xen-research, xen-japanese.

I have hidden a numer of other lists, hidden is like archived except 
that I have not listed them on http://lists.xen.org/ - in other words, 
the lists are still there, but they are not referenced. These were: 
ova-devel, xen-merge, xm-test-changelog, xm-test-devel & xen-community

This should make finding the right xen list much easier and be less 
confusing to newcomers. Please let me know, if there are any objections.

Regards
Lars

--------------010406080209060802050908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    I have archived a number of mailing lists that have been inactive,
    because<br>
    a) they have fulfilled their purpose (i.e. the project for which
    they were created was completed or archived)<br>
    b) they have been inactive for a year<br>
    c) the discussion related to these are now happening elsewhere (e.g.
    on xen-devel)<br>
    <br>
    What does archiving mean:<br>
    <ul>
      <li>I moved the list to the Archived section of
        <a class="moz-txt-link-freetext" href="http://lists.xen.org/">http://lists.xen.org/</a>&nbsp;</li>
      <li>I moved the list into emergency moderation (every post will be
        moderated) and new user</li>
      <li>I removed the list from
        <a class="moz-txt-link-freetext" href="http://lists.xen.org/cgi-bin/mailman/listinfo">http://lists.xen.org/cgi-bin/mailman/listinfo</a></li>
    </ul>
    <p>The lists that were archived are: xen-bugs, xen-cim,
      xen-introspect, xen-tools, xen-ia64-devel, xen-research,
      xen-japanese.<br>
    </p>
    I have hidden a numer of other lists, hidden is like archived except
    that I have not listed them on <a class="moz-txt-link-freetext" href="http://lists.xen.org/">http://lists.xen.org/</a> - in other
    words, the lists are still there, but they are not referenced. These
    were: ova-devel, xen-merge, xm-test-changelog, xm-test-devel &amp;
    xen-community<br>
    <br>
    This should make finding the right xen list much easier and be less
    confusing to newcomers. Please let me know, if there are any
    objections.<br>
    <br>
    Regards<br>
    Lars<br>
  </body>
</html>

--------------010406080209060802050908--


--===============3513679024534402111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3513679024534402111==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 12:45:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 12:45:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNO44-0007oD-77; Thu, 26 Apr 2012 12:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SNO42-0007nl-KK
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 12:44:50 +0000
Received: from [85.158.138.51:49913] by server-9.bemta-3.messagelabs.com id
	73/A0-26691-143499F4; Thu, 26 Apr 2012 12:44:49 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335444287!23952648!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_23,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21440 invoked from network); 26 Apr 2012 12:44:48 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 12:44:48 -0000
Received: by bkty15 with SMTP id y15so1113706bkt.32
	for <multiple recipients>; Thu, 26 Apr 2012 05:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=fIFltkWYN4/1trFXAlyENA0h3Ynqpt38Tkp0GsyVpiQ=;
	b=jMR1ltFF6jC4FJwIDB7hpjSZIVbEf+/9cJaZEECJyYIgP5LP0cOAuA9pTtX8sgATtp
	3HV1s6Ux3ZaNZpKtnDL9hZp6wX4+4nwDcPKrEMi1lt3WhUFtTQgLthLyoWHmPU3463rR
	div1PssSI9mVTP+4WpNe2yc0Kpbqk1vqWZtiu7h7bGja8I73xtmos4By0XAJLPt0omK2
	K/pp36eXBN0oQkJAA8Gq2hu3gBLwX2Or+8JNs5Tzu3x/Daioe7zal9x67ucrYh2vYxeJ
	jA5zZlvWPJKrEViuFqDM4Q0JZer83O9cjn+ubNNUmwnAoqZ1UrdHIW8jh32AhVYwigFU
	WHFQ==
Received: by 10.205.133.11 with SMTP id hw11mr2292503bkc.12.1335444287556;
	Thu, 26 Apr 2012 05:44:47 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id e20sm5453244bkv.10.2012.04.26.05.44.45
	(version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 05:44:46 -0700 (PDT)
Message-ID: <4F99433C.8040505@xen.org>
Date: Thu, 26 Apr 2012 13:44:44 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-api@lists.xen.org, 
	xen-arm@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] Changes to mailing lists (i.e. archiving of old lists)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3513679024534402111=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3513679024534402111==
Content-Type: multipart/alternative;
 boundary="------------010406080209060802050908"

This is a multi-part message in MIME format.
--------------010406080209060802050908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

I have archived a number of mailing lists that have been inactive, because
a) they have fulfilled their purpose (i.e. the project for which they 
were created was completed or archived)
b) they have been inactive for a year
c) the discussion related to these are now happening elsewhere (e.g. on 
xen-devel)

What does archiving mean:

  * I moved the list to the Archived section of http://lists.xen.org/
  * I moved the list into emergency moderation (every post will be
    moderated) and new user
  * I removed the list from http://lists.xen.org/cgi-bin/mailman/listinfo

The lists that were archived are: xen-bugs, xen-cim, xen-introspect, 
xen-tools, xen-ia64-devel, xen-research, xen-japanese.

I have hidden a numer of other lists, hidden is like archived except 
that I have not listed them on http://lists.xen.org/ - in other words, 
the lists are still there, but they are not referenced. These were: 
ova-devel, xen-merge, xm-test-changelog, xm-test-devel & xen-community

This should make finding the right xen list much easier and be less 
confusing to newcomers. Please let me know, if there are any objections.

Regards
Lars

--------------010406080209060802050908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    I have archived a number of mailing lists that have been inactive,
    because<br>
    a) they have fulfilled their purpose (i.e. the project for which
    they were created was completed or archived)<br>
    b) they have been inactive for a year<br>
    c) the discussion related to these are now happening elsewhere (e.g.
    on xen-devel)<br>
    <br>
    What does archiving mean:<br>
    <ul>
      <li>I moved the list to the Archived section of
        <a class="moz-txt-link-freetext" href="http://lists.xen.org/">http://lists.xen.org/</a>&nbsp;</li>
      <li>I moved the list into emergency moderation (every post will be
        moderated) and new user</li>
      <li>I removed the list from
        <a class="moz-txt-link-freetext" href="http://lists.xen.org/cgi-bin/mailman/listinfo">http://lists.xen.org/cgi-bin/mailman/listinfo</a></li>
    </ul>
    <p>The lists that were archived are: xen-bugs, xen-cim,
      xen-introspect, xen-tools, xen-ia64-devel, xen-research,
      xen-japanese.<br>
    </p>
    I have hidden a numer of other lists, hidden is like archived except
    that I have not listed them on <a class="moz-txt-link-freetext" href="http://lists.xen.org/">http://lists.xen.org/</a> - in other
    words, the lists are still there, but they are not referenced. These
    were: ova-devel, xen-merge, xm-test-changelog, xm-test-devel &amp;
    xen-community<br>
    <br>
    This should make finding the right xen list much easier and be less
    confusing to newcomers. Please let me know, if there are any
    objections.<br>
    <br>
    Regards<br>
    Lars<br>
  </body>
</html>

--------------010406080209060802050908--


--===============3513679024534402111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3513679024534402111==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 13:03:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOLX-0000GD-82; Thu, 26 Apr 2012 13:02:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNOLV-0000G8-7Z
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:02:53 +0000
Received: from [85.158.143.35:26527] by server-3.bemta-4.messagelabs.com id
	D7/D8-05853-C77499F4; Thu, 26 Apr 2012 13:02:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335445371!10585165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30247 invoked from network); 26 Apr 2012 13:02:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12155677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:02:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 14:02:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SNOLS-0007oM-RM; Thu, 26 Apr 2012 13:02:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SNOLS-0004UA-QS;
	Thu, 26 Apr 2012 14:02:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20377.18296.235567.918003@mariner.uk.xensource.com>
Date: Thu, 26 Apr 2012 14:02:48 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F99360E.2010201@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your reply.  I see you didn't reply to all of my comments.
Do you plan to address the others later ?

Roger Pau Monne writes ("Fwd: Re: [Xen-devel] [PATCH v3 3/5] libxl: call ho=
tplug scripts from libxl for vbd"):
> Ian Jackson escribi=F3:
> > So we no longer have any function which will synchronously and
> > immediately destroy a domain and throw away everything to do with it.
> > Is it actually the case that you think such a function cannot be
> > provided ?
> =

> It can be provided, but we should create another command or add an
> option to "destroy" (like -f), that doesn't wait for backend
> disconnection and just nukes both frontend/backend xenstore entries.
> This will also prevent us from executing hotplug scripts, and could lead
> to unexpected results.

Quite so.  But it is important to be able to disregard a
malfunctioning driver domain.  That would make it possible to shut
down all the guests using it, destroy the driver domain itself, and
restart it in a hopefully good state, for example.

> With this series we wait for the backend to disconnect for 10s, and if
> it doesn't respond we nuke the frontend and wait for another 10s. If
> after that it fails to disconnect we nuke the remaining backend xenstore
> entries.

I think we need to think about these timeouts.  At the very least
they're policy which should probably not be hardcoded in libxl; and
arguably people might want to be able to specify infinite ("I trust my
guest or driver domain and never want to pull the rug out from under
its feet") or zero ("this guest or driver domain has gone wrong and I
want it killed, now").

> >> +# Hack to prevent the execution of hotplug scripts from udev if the d=
omain
> >> +# has been launched from libxl
> >> +if [ -n "${HOTPLUG_GATE}" ]&&  \
> >> +   `xenstore-read "$HOTPLUG_GATE">/dev/null 2>&1`; then
> >> +    exit 0
> >> +fi
> >
> > Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
> > like the idea of being able to pass some random other xenstore path.
> =

> Anyway, I will have to pass an environmental variable when calling the
> script from udev, I can rename this to UDEV_CALL=3D1 if that sounds bette=
r.

Perhaps it would be better to do things the other way around, and have
an env var for the case where we're _not_ calling the script from
udev ?  After all, udev config is configuration (at least on my
distros) which the user may not update when the software is updated.

> > Also: this xenstore path should be a relative path, ie one relative to
> > the xenstore home of domain running this part of the tools.  That way
> > the scripts can be easily and automatically disabled for dom0 and
> > enabled in driver domains.
> =

> Something like:
> =

> /libxl/<domid>/disable_udev?
> =

> So that it embraces the whole domain instead of just applying to a
> single device?

Yes, except you want
  /local/domain/<domid>/libxl/disable_udev
or some such so that <domid> can access it via the relative path
  libxl/disable_udev
without needing to know its own domid.

> >> +    switch(disk->backend) {
> >> +    case LIBXL_DISK_BACKEND_PHY:
> >> +    case LIBXL_DISK_BACKEND_TAP:
> >> +        rc =3D libxl__initiate_device_add(egc, ao,&device);
> >> +        if (rc) goto out_free;
> >> +        break;
> >> +    case LIBXL_DISK_BACKEND_QDISK:
> >> +    default:
> >> +        libxl__ao_complete(egc, ao, 0);
> >> +        break;
> >> +    }
> >
> > Does this really need no confirmation from qemu ?
> =

> Qemu is not even started here, and it doesn't use any kind of hotplug
> scripts, so I think I can safely say yes.

Uh, what, LIBXL_DISK_BACKEND_QDISK but qemu is not started ?  How is
that possible ?

> >> +    rc =3D libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
> >
> > This is not correct.  You need to do something more with the exit
> > status of the hotplug script than simply throwing it away as you do in
> > hotplug_exited.  libxl__device_hotplug needs to take a callback from
> > the caller so that it can notify the caller when the hotplug script
> > has exited.
> >
> > You need to not allow the ao to complete until the hotplug script has
> > exited.  Otherwise you will enter hotplug_exited after the
> > libxl__hotplug_state has been destroyed with the ao.
> =

> Ok, I think I've changed most of this stuff, and unified device
> addition/destruction on the same event, since it's just a matter of wait
> -> execute hotplug.

I'm not sure I quite understand your response, but OK :-).

> > If it's too slow and you need to time out, you need to send the
> > hotplug script a signal, and then wait for it to exit.  If necessary
> > that signal could be SIGKILL; SIGKILL can be relied on to cause the
> > hotplug script to actually terminate and thus the hotplug_exited
> > callback to occur.
> =

> Where is the best place to handle this? From what I see, we have no
> helper for doing this, so I guess I will have to use waitpid or
> something similar?

You must not use waitpid yourself.  libxl__ev_child_fork will do all
of that and simply call yo back when the child exits.

You can call kill on the pid at any time (provided that 1. you have
the ctx lock held and 2. the libxl__ev_child state struct is still
"inuse" ie still has the pid in it).

> > And I think the new interface is entirely wrong.  How does the caller
> > know when to complete the ao if libxl__initiate_device_remove never
> > calls back ?
> >
> > You need to split this into two functions: one with the current
> > interface which is a simple wrapper, used for all the existing call
> > sites, and one which never completes any ao but which always makes a
> > callback when the operation is complete.  That callback should be used
> > by the caller of libxl__initiate_device_remove to do whatever it needs
> > to, which might include completing the ao.
> =

> I understand what you are saying, but I have trouble thinking of a
> correct way to do this, since multiple events can be added to the same
> ao, and the libxl__initiate_device_remove "callback" will be called more
> than once, how do I know when I have to call ao_complete?

You have to maintain a data structure of some kind that tells you
whether you're expecting more callbacks and what they are.

> >> +/* Action to pass to hotplug caller functions */
> >> +typedef enum {
> >> +    CONNECT =3D 1,
> >> +    DISCONNECT =3D 2
> >> +} libxl__hotplug_action;
> >
> > These names are rather too generic, I think.
> =

> I've changed them to HOTPLUG_CONNECT and HOTPLUG_DISCONNECT.

Sounds good.

> >> +/*
> >> + * libxl__hotplug_exec is an internal function that should not be used
> >> + * directly, all hotplug script calls have to implement and use
> >> + * libxl__device_hotplug.
> >> + */
> >> +_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
> >> +                                  libxl__hotplug_action action);
> >> +_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **arg=
s,
> >> +                                char **env);
> >
> > Why does libxl__hotplug_exec need to be declared here at all then ?
> > Could it be static in libxl_hotplug.c ?
> =

> No, because libxl_linux uses libxl_hotplug_launch, which is supposed to
> be a common launcher for both Linux and NetBSD.

Ah right.

> >> +    f_env =3D flexarray_make(9, 1);
> >> +    if (!f_env) {
> >> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >> +                   "unable to create environment array");
> >> +        return NULL;
> >> +    }
> >
> > Isn't this an allocation failure which should be dealt with by
> > libxl__alloc_failed ?
> =

> Done, I think we should set a macro for
> =

> libxl__alloc_failed(ctx, __func__, 0,0);
> =

> Because I'm using that on more than one place.

Sure.  A helper macro for that would be fine.

> > For that matter, you've called libxl__device_kind_to_string twice.
> > Calling it only once would make this easier to read.
> >
> > I won't comment any more on places where I think GCSPRINTF,
> > LOG/LOGE/LOGEV and CTX might usefully replace what you have written.
> =

> I'm trying to spot most of them, but it's quite difficult. Are we going
> to do a massive replace of this at some point?

I'm not sure.  I don't currently have any plans to do so before 4.2.

But in new code it would be better to use the shorter convenience
macros simply to reduce the amount of nearly- meaningless repetition.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:03:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOLX-0000GD-82; Thu, 26 Apr 2012 13:02:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNOLV-0000G8-7Z
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:02:53 +0000
Received: from [85.158.143.35:26527] by server-3.bemta-4.messagelabs.com id
	D7/D8-05853-C77499F4; Thu, 26 Apr 2012 13:02:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1335445371!10585165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30247 invoked from network); 26 Apr 2012 13:02:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12155677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:02:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 14:02:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SNOLS-0007oM-RM; Thu, 26 Apr 2012 13:02:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SNOLS-0004UA-QS;
	Thu, 26 Apr 2012 14:02:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20377.18296.235567.918003@mariner.uk.xensource.com>
Date: Thu, 26 Apr 2012 14:02:48 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4F99360E.2010201@citrix.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your reply.  I see you didn't reply to all of my comments.
Do you plan to address the others later ?

Roger Pau Monne writes ("Fwd: Re: [Xen-devel] [PATCH v3 3/5] libxl: call ho=
tplug scripts from libxl for vbd"):
> Ian Jackson escribi=F3:
> > So we no longer have any function which will synchronously and
> > immediately destroy a domain and throw away everything to do with it.
> > Is it actually the case that you think such a function cannot be
> > provided ?
> =

> It can be provided, but we should create another command or add an
> option to "destroy" (like -f), that doesn't wait for backend
> disconnection and just nukes both frontend/backend xenstore entries.
> This will also prevent us from executing hotplug scripts, and could lead
> to unexpected results.

Quite so.  But it is important to be able to disregard a
malfunctioning driver domain.  That would make it possible to shut
down all the guests using it, destroy the driver domain itself, and
restart it in a hopefully good state, for example.

> With this series we wait for the backend to disconnect for 10s, and if
> it doesn't respond we nuke the frontend and wait for another 10s. If
> after that it fails to disconnect we nuke the remaining backend xenstore
> entries.

I think we need to think about these timeouts.  At the very least
they're policy which should probably not be hardcoded in libxl; and
arguably people might want to be able to specify infinite ("I trust my
guest or driver domain and never want to pull the rug out from under
its feet") or zero ("this guest or driver domain has gone wrong and I
want it killed, now").

> >> +# Hack to prevent the execution of hotplug scripts from udev if the d=
omain
> >> +# has been launched from libxl
> >> +if [ -n "${HOTPLUG_GATE}" ]&&  \
> >> +   `xenstore-read "$HOTPLUG_GATE">/dev/null 2>&1`; then
> >> +    exit 0
> >> +fi
> >
> > Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
> > like the idea of being able to pass some random other xenstore path.
> =

> Anyway, I will have to pass an environmental variable when calling the
> script from udev, I can rename this to UDEV_CALL=3D1 if that sounds bette=
r.

Perhaps it would be better to do things the other way around, and have
an env var for the case where we're _not_ calling the script from
udev ?  After all, udev config is configuration (at least on my
distros) which the user may not update when the software is updated.

> > Also: this xenstore path should be a relative path, ie one relative to
> > the xenstore home of domain running this part of the tools.  That way
> > the scripts can be easily and automatically disabled for dom0 and
> > enabled in driver domains.
> =

> Something like:
> =

> /libxl/<domid>/disable_udev?
> =

> So that it embraces the whole domain instead of just applying to a
> single device?

Yes, except you want
  /local/domain/<domid>/libxl/disable_udev
or some such so that <domid> can access it via the relative path
  libxl/disable_udev
without needing to know its own domid.

> >> +    switch(disk->backend) {
> >> +    case LIBXL_DISK_BACKEND_PHY:
> >> +    case LIBXL_DISK_BACKEND_TAP:
> >> +        rc =3D libxl__initiate_device_add(egc, ao,&device);
> >> +        if (rc) goto out_free;
> >> +        break;
> >> +    case LIBXL_DISK_BACKEND_QDISK:
> >> +    default:
> >> +        libxl__ao_complete(egc, ao, 0);
> >> +        break;
> >> +    }
> >
> > Does this really need no confirmation from qemu ?
> =

> Qemu is not even started here, and it doesn't use any kind of hotplug
> scripts, so I think I can safely say yes.

Uh, what, LIBXL_DISK_BACKEND_QDISK but qemu is not started ?  How is
that possible ?

> >> +    rc =3D libxl__device_hotplug(gc, aorm->dev, DISCONNECT);
> >
> > This is not correct.  You need to do something more with the exit
> > status of the hotplug script than simply throwing it away as you do in
> > hotplug_exited.  libxl__device_hotplug needs to take a callback from
> > the caller so that it can notify the caller when the hotplug script
> > has exited.
> >
> > You need to not allow the ao to complete until the hotplug script has
> > exited.  Otherwise you will enter hotplug_exited after the
> > libxl__hotplug_state has been destroyed with the ao.
> =

> Ok, I think I've changed most of this stuff, and unified device
> addition/destruction on the same event, since it's just a matter of wait
> -> execute hotplug.

I'm not sure I quite understand your response, but OK :-).

> > If it's too slow and you need to time out, you need to send the
> > hotplug script a signal, and then wait for it to exit.  If necessary
> > that signal could be SIGKILL; SIGKILL can be relied on to cause the
> > hotplug script to actually terminate and thus the hotplug_exited
> > callback to occur.
> =

> Where is the best place to handle this? From what I see, we have no
> helper for doing this, so I guess I will have to use waitpid or
> something similar?

You must not use waitpid yourself.  libxl__ev_child_fork will do all
of that and simply call yo back when the child exits.

You can call kill on the pid at any time (provided that 1. you have
the ctx lock held and 2. the libxl__ev_child state struct is still
"inuse" ie still has the pid in it).

> > And I think the new interface is entirely wrong.  How does the caller
> > know when to complete the ao if libxl__initiate_device_remove never
> > calls back ?
> >
> > You need to split this into two functions: one with the current
> > interface which is a simple wrapper, used for all the existing call
> > sites, and one which never completes any ao but which always makes a
> > callback when the operation is complete.  That callback should be used
> > by the caller of libxl__initiate_device_remove to do whatever it needs
> > to, which might include completing the ao.
> =

> I understand what you are saying, but I have trouble thinking of a
> correct way to do this, since multiple events can be added to the same
> ao, and the libxl__initiate_device_remove "callback" will be called more
> than once, how do I know when I have to call ao_complete?

You have to maintain a data structure of some kind that tells you
whether you're expecting more callbacks and what they are.

> >> +/* Action to pass to hotplug caller functions */
> >> +typedef enum {
> >> +    CONNECT =3D 1,
> >> +    DISCONNECT =3D 2
> >> +} libxl__hotplug_action;
> >
> > These names are rather too generic, I think.
> =

> I've changed them to HOTPLUG_CONNECT and HOTPLUG_DISCONNECT.

Sounds good.

> >> +/*
> >> + * libxl__hotplug_exec is an internal function that should not be used
> >> + * directly, all hotplug script calls have to implement and use
> >> + * libxl__device_hotplug.
> >> + */
> >> +_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
> >> +                                  libxl__hotplug_action action);
> >> +_hidden int libxl__hotplug_exec(libxl__gc *gc, char *arg0, char **arg=
s,
> >> +                                char **env);
> >
> > Why does libxl__hotplug_exec need to be declared here at all then ?
> > Could it be static in libxl_hotplug.c ?
> =

> No, because libxl_linux uses libxl_hotplug_launch, which is supposed to
> be a common launcher for both Linux and NetBSD.

Ah right.

> >> +    f_env =3D flexarray_make(9, 1);
> >> +    if (!f_env) {
> >> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >> +                   "unable to create environment array");
> >> +        return NULL;
> >> +    }
> >
> > Isn't this an allocation failure which should be dealt with by
> > libxl__alloc_failed ?
> =

> Done, I think we should set a macro for
> =

> libxl__alloc_failed(ctx, __func__, 0,0);
> =

> Because I'm using that on more than one place.

Sure.  A helper macro for that would be fine.

> > For that matter, you've called libxl__device_kind_to_string twice.
> > Calling it only once would make this easier to read.
> >
> > I won't comment any more on places where I think GCSPRINTF,
> > LOG/LOGE/LOGEV and CTX might usefully replace what you have written.
> =

> I'm trying to spot most of them, but it's quite difficult. Are we going
> to do a massive replace of this at some point?

I'm not sure.  I don't currently have any plans to do so before 4.2.

But in new code it would be better to use the shorter convenience
macros simply to reduce the amount of nearly- meaningless repetition.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNORr-0000Q8-37; Thu, 26 Apr 2012 13:09:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNORp-0000Q1-L7
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:09:26 +0000
Received: from [85.158.139.83:36302] by server-8.bemta-5.messagelabs.com id
	14/62-26964-409499F4; Thu, 26 Apr 2012 13:09:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335445764!25545576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14093 invoked from network); 26 Apr 2012 13:09:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:09:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12155846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:09:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:09:23 +0100
Message-ID: <1335445762.28015.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 14:09:22 +0100
In-Reply-To: <20377.18296.235567.918003@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com>	<4F99360E.2010201@citrix.com>
	<20377.18296.235567.918003@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDE0OjAyICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBU
aGFua3MgZm9yIHlvdXIgcmVwbHkuICBJIHNlZSB5b3UgZGlkbid0IHJlcGx5IHRvIGFsbCBvZiBt
eSBjb21tZW50cy4KPiBEbyB5b3UgcGxhbiB0byBhZGRyZXNzIHRoZSBvdGhlcnMgbGF0ZXIgPwo+
IAo+IFJvZ2VyIFBhdSBNb25uZSB3cml0ZXMgKCJGd2Q6IFJlOiBbWGVuLWRldmVsXSBbUEFUQ0gg
djMgMy81XSBsaWJ4bDogY2FsbCBob3RwbHVnIHNjcmlwdHMgZnJvbSBsaWJ4bCBmb3IgdmJkIik6
Cj4gPiBJYW4gSmFja3NvbiBlc2NyaWJpw7M6Cj4gPiA+IFNvIHdlIG5vIGxvbmdlciBoYXZlIGFu
eSBmdW5jdGlvbiB3aGljaCB3aWxsIHN5bmNocm9ub3VzbHkgYW5kCj4gPiA+IGltbWVkaWF0ZWx5
IGRlc3Ryb3kgYSBkb21haW4gYW5kIHRocm93IGF3YXkgZXZlcnl0aGluZyB0byBkbyB3aXRoIGl0
Lgo+ID4gPiBJcyBpdCBhY3R1YWxseSB0aGUgY2FzZSB0aGF0IHlvdSB0aGluayBzdWNoIGEgZnVu
Y3Rpb24gY2Fubm90IGJlCj4gPiA+IHByb3ZpZGVkID8KPiA+IAo+ID4gSXQgY2FuIGJlIHByb3Zp
ZGVkLCBidXQgd2Ugc2hvdWxkIGNyZWF0ZSBhbm90aGVyIGNvbW1hbmQgb3IgYWRkIGFuCj4gPiBv
cHRpb24gdG8gImRlc3Ryb3kiIChsaWtlIC1mKSwgdGhhdCBkb2Vzbid0IHdhaXQgZm9yIGJhY2tl
bmQKPiA+IGRpc2Nvbm5lY3Rpb24gYW5kIGp1c3QgbnVrZXMgYm90aCBmcm9udGVuZC9iYWNrZW5k
IHhlbnN0b3JlIGVudHJpZXMuCj4gPiBUaGlzIHdpbGwgYWxzbyBwcmV2ZW50IHVzIGZyb20gZXhl
Y3V0aW5nIGhvdHBsdWcgc2NyaXB0cywgYW5kIGNvdWxkIGxlYWQKPiA+IHRvIHVuZXhwZWN0ZWQg
cmVzdWx0cy4KPiAKPiBRdWl0ZSBzby4gIEJ1dCBpdCBpcyBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0
byBkaXNyZWdhcmQgYQo+IG1hbGZ1bmN0aW9uaW5nIGRyaXZlciBkb21haW4uICBUaGF0IHdvdWxk
IG1ha2UgaXQgcG9zc2libGUgdG8gc2h1dAo+IGRvd24gYWxsIHRoZSBndWVzdHMgdXNpbmcgaXQs
IGRlc3Ryb3kgdGhlIGRyaXZlciBkb21haW4gaXRzZWxmLCBhbmQKPiByZXN0YXJ0IGl0IGluIGEg
aG9wZWZ1bGx5IGdvb2Qgc3RhdGUsIGZvciBleGFtcGxlLgo+IAo+ID4gV2l0aCB0aGlzIHNlcmll
cyB3ZSB3YWl0IGZvciB0aGUgYmFja2VuZCB0byBkaXNjb25uZWN0IGZvciAxMHMsIGFuZCBpZgo+
ID4gaXQgZG9lc24ndCByZXNwb25kIHdlIG51a2UgdGhlIGZyb250ZW5kIGFuZCB3YWl0IGZvciBh
bm90aGVyIDEwcy4gSWYKPiA+IGFmdGVyIHRoYXQgaXQgZmFpbHMgdG8gZGlzY29ubmVjdCB3ZSBu
dWtlIHRoZSByZW1haW5pbmcgYmFja2VuZCB4ZW5zdG9yZQo+ID4gZW50cmllcy4KPiAKPiBJIHRo
aW5rIHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhlc2UgdGltZW91dHMuICBBdCB0aGUgdmVyeSBs
ZWFzdAo+IHRoZXkncmUgcG9saWN5IHdoaWNoIHNob3VsZCBwcm9iYWJseSBub3QgYmUgaGFyZGNv
ZGVkIGluIGxpYnhsOyBhbmQKPiBhcmd1YWJseSBwZW9wbGUgbWlnaHQgd2FudCB0byBiZSBhYmxl
IHRvIHNwZWNpZnkgaW5maW5pdGUgKCJJIHRydXN0IG15Cj4gZ3Vlc3Qgb3IgZHJpdmVyIGRvbWFp
biBhbmQgbmV2ZXIgd2FudCB0byBwdWxsIHRoZSBydWcgb3V0IGZyb20gdW5kZXIKPiBpdHMgZmVl
dCIpIG9yIHplcm8gKCJ0aGlzIGd1ZXN0IG9yIGRyaXZlciBkb21haW4gaGFzIGdvbmUgd3Jvbmcg
YW5kIEkKPiB3YW50IGl0IGtpbGxlZCwgbm93IikuCgpVbmxlc3MgdGhlIHNhbWUgaXMgZ29pbmcg
dG8gYmUgdHJ1ZSBvZiB0aGUgZXZlbnR1YWwgc29sdXRpb24gKHdoaWNoIEkKc3VwcG9zZSBpdCBt
YXkgd2VsbCBiZT8pIHdlIHNob3VsZCBiZSB3YXJ5IG9mIG92ZXIgZW5naW5lZXJpbmcgdGhlCmlu
dGVyaW0gc29sdXRpb24gZm9yIDQuMi4KCj4gPiA+PiArIyBIYWNrIHRvIHByZXZlbnQgdGhlIGV4
ZWN1dGlvbiBvZiBob3RwbHVnIHNjcmlwdHMgZnJvbSB1ZGV2IGlmIHRoZSBkb21haW4KPiA+ID4+
ICsjIGhhcyBiZWVuIGxhdW5jaGVkIGZyb20gbGlieGwKPiA+ID4+ICtpZiBbIC1uICIke0hPVFBM
VUdfR0FURX0iIF0mJiAgXAo+ID4gPj4gKyAgIGB4ZW5zdG9yZS1yZWFkICIkSE9UUExVR19HQVRF
Ij4vZGV2L251bGwgMj4mMWA7IHRoZW4KPiA+ID4+ICsgICAgZXhpdCAwCj4gPiA+PiArZmkKPiA+
ID4KPiA+ID4gT2ggSSBzZWUuICBIbW0uICBXaHkgc2hvdWxkIHRoaXMgc3RyaW5nIG5vdCBiZSBm
aXhlZCA/ICBJJ20gbm90IHN1cmUgSQo+ID4gPiBsaWtlIHRoZSBpZGVhIG9mIGJlaW5nIGFibGUg
dG8gcGFzcyBzb21lIHJhbmRvbSBvdGhlciB4ZW5zdG9yZSBwYXRoLgo+ID4gCj4gPiBBbnl3YXks
IEkgd2lsbCBoYXZlIHRvIHBhc3MgYW4gZW52aXJvbm1lbnRhbCB2YXJpYWJsZSB3aGVuIGNhbGxp
bmcgdGhlCj4gPiBzY3JpcHQgZnJvbSB1ZGV2LCBJIGNhbiByZW5hbWUgdGhpcyB0byBVREVWX0NB
TEw9MSBpZiB0aGF0IHNvdW5kcyBiZXR0ZXIuCj4gCj4gUGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0
ZXIgdG8gZG8gdGhpbmdzIHRoZSBvdGhlciB3YXkgYXJvdW5kLCBhbmQgaGF2ZQo+IGFuIGVudiB2
YXIgZm9yIHRoZSBjYXNlIHdoZXJlIHdlJ3JlIF9ub3RfIGNhbGxpbmcgdGhlIHNjcmlwdCBmcm9t
Cj4gdWRldiA/ICBBZnRlciBhbGwsIHVkZXYgY29uZmlnIGlzIGNvbmZpZ3VyYXRpb24gKGF0IGxl
YXN0IG9uIG15Cj4gZGlzdHJvcykgd2hpY2ggdGhlIHVzZXIgbWF5IG5vdCB1cGRhdGUgd2hlbiB0
aGUgc29mdHdhcmUgaXMgdXBkYXRlZC4KCkl0IHdhcyBteSBzdWdnZXN0aW9uIHRvIGRvIGl0IHRo
aXMgd2F5IHNvIHRoYXQgd2UgZG9uJ3QgZW5kIHVwIHdpdGggYQp2ZXN0aWdpYWwgZW52IHZhciB3
aGljaCBtdXN0IGFsd2F5cyBiZSBzZXQgZm9yIG5vIHJlYWwgcmVhc29uIGFmdGVyCndlJ3ZlIHJl
bW92ZWQgdGhlIHVkZXYgcGF0aCBhbHRvZ2V0aGVyLgoKSSBkb24ndCByZWFsbHkgbWluZCB0aG91
Z2gsIHdlIGNvdWxkIGxpdmUgd2l0aCB0aGF0IHZlc3RpZ2lhbCB0aGluZywgb3IKaGF2ZSBhbm90
aGVyLCBlYXNpZXIsIHRyYW5zaXRpb24gYSBmZXcgcmVsZWFzZXMgZG93biB0aGUgbGluZS4KCklh
bi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNORr-0000Q8-37; Thu, 26 Apr 2012 13:09:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNORp-0000Q1-L7
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:09:26 +0000
Received: from [85.158.139.83:36302] by server-8.bemta-5.messagelabs.com id
	14/62-26964-409499F4; Thu, 26 Apr 2012 13:09:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335445764!25545576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14093 invoked from network); 26 Apr 2012 13:09:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:09:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12155846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:09:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:09:23 +0100
Message-ID: <1335445762.28015.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 14:09:22 +0100
In-Reply-To: <20377.18296.235567.918003@mariner.uk.xensource.com>
References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com>
	<1334928211-29856-4-git-send-email-roger.pau@citrix.com>
	<20373.34767.584624.953798@mariner.uk.xensource.com>
	<4F982F18.2080902@citrix.com>	<4F99360E.2010201@citrix.com>
	<20377.18296.235567.918003@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts
 from libxl for vbd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDE0OjAyICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBU
aGFua3MgZm9yIHlvdXIgcmVwbHkuICBJIHNlZSB5b3UgZGlkbid0IHJlcGx5IHRvIGFsbCBvZiBt
eSBjb21tZW50cy4KPiBEbyB5b3UgcGxhbiB0byBhZGRyZXNzIHRoZSBvdGhlcnMgbGF0ZXIgPwo+
IAo+IFJvZ2VyIFBhdSBNb25uZSB3cml0ZXMgKCJGd2Q6IFJlOiBbWGVuLWRldmVsXSBbUEFUQ0gg
djMgMy81XSBsaWJ4bDogY2FsbCBob3RwbHVnIHNjcmlwdHMgZnJvbSBsaWJ4bCBmb3IgdmJkIik6
Cj4gPiBJYW4gSmFja3NvbiBlc2NyaWJpw7M6Cj4gPiA+IFNvIHdlIG5vIGxvbmdlciBoYXZlIGFu
eSBmdW5jdGlvbiB3aGljaCB3aWxsIHN5bmNocm9ub3VzbHkgYW5kCj4gPiA+IGltbWVkaWF0ZWx5
IGRlc3Ryb3kgYSBkb21haW4gYW5kIHRocm93IGF3YXkgZXZlcnl0aGluZyB0byBkbyB3aXRoIGl0
Lgo+ID4gPiBJcyBpdCBhY3R1YWxseSB0aGUgY2FzZSB0aGF0IHlvdSB0aGluayBzdWNoIGEgZnVu
Y3Rpb24gY2Fubm90IGJlCj4gPiA+IHByb3ZpZGVkID8KPiA+IAo+ID4gSXQgY2FuIGJlIHByb3Zp
ZGVkLCBidXQgd2Ugc2hvdWxkIGNyZWF0ZSBhbm90aGVyIGNvbW1hbmQgb3IgYWRkIGFuCj4gPiBv
cHRpb24gdG8gImRlc3Ryb3kiIChsaWtlIC1mKSwgdGhhdCBkb2Vzbid0IHdhaXQgZm9yIGJhY2tl
bmQKPiA+IGRpc2Nvbm5lY3Rpb24gYW5kIGp1c3QgbnVrZXMgYm90aCBmcm9udGVuZC9iYWNrZW5k
IHhlbnN0b3JlIGVudHJpZXMuCj4gPiBUaGlzIHdpbGwgYWxzbyBwcmV2ZW50IHVzIGZyb20gZXhl
Y3V0aW5nIGhvdHBsdWcgc2NyaXB0cywgYW5kIGNvdWxkIGxlYWQKPiA+IHRvIHVuZXhwZWN0ZWQg
cmVzdWx0cy4KPiAKPiBRdWl0ZSBzby4gIEJ1dCBpdCBpcyBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0
byBkaXNyZWdhcmQgYQo+IG1hbGZ1bmN0aW9uaW5nIGRyaXZlciBkb21haW4uICBUaGF0IHdvdWxk
IG1ha2UgaXQgcG9zc2libGUgdG8gc2h1dAo+IGRvd24gYWxsIHRoZSBndWVzdHMgdXNpbmcgaXQs
IGRlc3Ryb3kgdGhlIGRyaXZlciBkb21haW4gaXRzZWxmLCBhbmQKPiByZXN0YXJ0IGl0IGluIGEg
aG9wZWZ1bGx5IGdvb2Qgc3RhdGUsIGZvciBleGFtcGxlLgo+IAo+ID4gV2l0aCB0aGlzIHNlcmll
cyB3ZSB3YWl0IGZvciB0aGUgYmFja2VuZCB0byBkaXNjb25uZWN0IGZvciAxMHMsIGFuZCBpZgo+
ID4gaXQgZG9lc24ndCByZXNwb25kIHdlIG51a2UgdGhlIGZyb250ZW5kIGFuZCB3YWl0IGZvciBh
bm90aGVyIDEwcy4gSWYKPiA+IGFmdGVyIHRoYXQgaXQgZmFpbHMgdG8gZGlzY29ubmVjdCB3ZSBu
dWtlIHRoZSByZW1haW5pbmcgYmFja2VuZCB4ZW5zdG9yZQo+ID4gZW50cmllcy4KPiAKPiBJIHRo
aW5rIHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhlc2UgdGltZW91dHMuICBBdCB0aGUgdmVyeSBs
ZWFzdAo+IHRoZXkncmUgcG9saWN5IHdoaWNoIHNob3VsZCBwcm9iYWJseSBub3QgYmUgaGFyZGNv
ZGVkIGluIGxpYnhsOyBhbmQKPiBhcmd1YWJseSBwZW9wbGUgbWlnaHQgd2FudCB0byBiZSBhYmxl
IHRvIHNwZWNpZnkgaW5maW5pdGUgKCJJIHRydXN0IG15Cj4gZ3Vlc3Qgb3IgZHJpdmVyIGRvbWFp
biBhbmQgbmV2ZXIgd2FudCB0byBwdWxsIHRoZSBydWcgb3V0IGZyb20gdW5kZXIKPiBpdHMgZmVl
dCIpIG9yIHplcm8gKCJ0aGlzIGd1ZXN0IG9yIGRyaXZlciBkb21haW4gaGFzIGdvbmUgd3Jvbmcg
YW5kIEkKPiB3YW50IGl0IGtpbGxlZCwgbm93IikuCgpVbmxlc3MgdGhlIHNhbWUgaXMgZ29pbmcg
dG8gYmUgdHJ1ZSBvZiB0aGUgZXZlbnR1YWwgc29sdXRpb24gKHdoaWNoIEkKc3VwcG9zZSBpdCBt
YXkgd2VsbCBiZT8pIHdlIHNob3VsZCBiZSB3YXJ5IG9mIG92ZXIgZW5naW5lZXJpbmcgdGhlCmlu
dGVyaW0gc29sdXRpb24gZm9yIDQuMi4KCj4gPiA+PiArIyBIYWNrIHRvIHByZXZlbnQgdGhlIGV4
ZWN1dGlvbiBvZiBob3RwbHVnIHNjcmlwdHMgZnJvbSB1ZGV2IGlmIHRoZSBkb21haW4KPiA+ID4+
ICsjIGhhcyBiZWVuIGxhdW5jaGVkIGZyb20gbGlieGwKPiA+ID4+ICtpZiBbIC1uICIke0hPVFBM
VUdfR0FURX0iIF0mJiAgXAo+ID4gPj4gKyAgIGB4ZW5zdG9yZS1yZWFkICIkSE9UUExVR19HQVRF
Ij4vZGV2L251bGwgMj4mMWA7IHRoZW4KPiA+ID4+ICsgICAgZXhpdCAwCj4gPiA+PiArZmkKPiA+
ID4KPiA+ID4gT2ggSSBzZWUuICBIbW0uICBXaHkgc2hvdWxkIHRoaXMgc3RyaW5nIG5vdCBiZSBm
aXhlZCA/ICBJJ20gbm90IHN1cmUgSQo+ID4gPiBsaWtlIHRoZSBpZGVhIG9mIGJlaW5nIGFibGUg
dG8gcGFzcyBzb21lIHJhbmRvbSBvdGhlciB4ZW5zdG9yZSBwYXRoLgo+ID4gCj4gPiBBbnl3YXks
IEkgd2lsbCBoYXZlIHRvIHBhc3MgYW4gZW52aXJvbm1lbnRhbCB2YXJpYWJsZSB3aGVuIGNhbGxp
bmcgdGhlCj4gPiBzY3JpcHQgZnJvbSB1ZGV2LCBJIGNhbiByZW5hbWUgdGhpcyB0byBVREVWX0NB
TEw9MSBpZiB0aGF0IHNvdW5kcyBiZXR0ZXIuCj4gCj4gUGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0
ZXIgdG8gZG8gdGhpbmdzIHRoZSBvdGhlciB3YXkgYXJvdW5kLCBhbmQgaGF2ZQo+IGFuIGVudiB2
YXIgZm9yIHRoZSBjYXNlIHdoZXJlIHdlJ3JlIF9ub3RfIGNhbGxpbmcgdGhlIHNjcmlwdCBmcm9t
Cj4gdWRldiA/ICBBZnRlciBhbGwsIHVkZXYgY29uZmlnIGlzIGNvbmZpZ3VyYXRpb24gKGF0IGxl
YXN0IG9uIG15Cj4gZGlzdHJvcykgd2hpY2ggdGhlIHVzZXIgbWF5IG5vdCB1cGRhdGUgd2hlbiB0
aGUgc29mdHdhcmUgaXMgdXBkYXRlZC4KCkl0IHdhcyBteSBzdWdnZXN0aW9uIHRvIGRvIGl0IHRo
aXMgd2F5IHNvIHRoYXQgd2UgZG9uJ3QgZW5kIHVwIHdpdGggYQp2ZXN0aWdpYWwgZW52IHZhciB3
aGljaCBtdXN0IGFsd2F5cyBiZSBzZXQgZm9yIG5vIHJlYWwgcmVhc29uIGFmdGVyCndlJ3ZlIHJl
bW92ZWQgdGhlIHVkZXYgcGF0aCBhbHRvZ2V0aGVyLgoKSSBkb24ndCByZWFsbHkgbWluZCB0aG91
Z2gsIHdlIGNvdWxkIGxpdmUgd2l0aCB0aGF0IHZlc3RpZ2lhbCB0aGluZywgb3IKaGF2ZSBhbm90
aGVyLCBlYXNpZXIsIHRyYW5zaXRpb24gYSBmZXcgcmVsZWFzZXMgZG93biB0aGUgbGluZS4KCklh
bi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:10:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOSI-0000S9-G6; Thu, 26 Apr 2012 13:09:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SNOSH-0000Rz-4a
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:09:53 +0000
Received: from [85.158.143.99:49293] by server-3.bemta-4.messagelabs.com id
	E0/C4-05853-029499F4; Thu, 26 Apr 2012 13:09:52 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335445789!22018376!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17628 invoked from network); 26 Apr 2012 13:09:51 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:09:51 -0000
Received: by dajx4 with SMTP id x4so1776169daj.28
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:to:mime-version:x-mailer;
	bh=PhhANlmWWI6iV5lsMCZe/pPjB5Wo9cZz+LxsknsUnCg=;
	b=1FoUMUujLmGBMHbgZpPmz5AWKBHgIuujJqEdoZXSugICbMq6wmXLGTXFY9sdk5YNsq
	8JuGwpQbznfyi2NbmyN5JxdgsTCU6HI1BNhe7D+j+LGhpjjnRSW+Zq6NRy7iF9ng4tM5
	8QOH9Ninl6odhT2nbmIQLFBoJ3BniDggVi5Fm6Tr9d89FWnUPVSOvsgrQki63CrYqxzJ
	Ar+ZuYp2ihUtjyTNas3TQQTNSdZV39of8fetix/8ojjAMkijjepnfwWLx5pVcUoLyarA
	dtR/PloHhnSumKeZ/cX9NWkql4/fw9omLj+tvSJ0aVRKYu2Ap8QuDgsmfAF9ftqiN3jS
	dduQ==
Received: by 10.68.194.71 with SMTP id hu7mr3630116pbc.158.1335445789369;
	Thu, 26 Apr 2012 06:09:49 -0700 (PDT)
Received: from [10.30.0.13] ([159.226.43.35])
	by mx.google.com with ESMTPS id o9sm3254197pbe.60.2012.04.26.06.09.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 06:09:48 -0700 (PDT)
From: wang zhihao <accept.acm@gmail.com>
Date: Thu, 26 Apr 2012 21:09:44 +0800
Message-Id: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] How to avoid this error "bits/predefs.h No such file or
	directory" when compiling XEN?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1807241726539057845=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1807241726539057845==
Content-Type: multipart/alternative; boundary=Apple-Mail-1-656299358


--Apple-Mail-1-656299358
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi , All

I try to compile xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on =
ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal =
error: bits/predefs.h No such file or directory". I wonder it's a thing =
related to 32bits and 64bits. How to solve this problem? Thank you.


Here are my steps:

[ Install prerequisites. ]

sudo apt-get install git
sudo apt-get install mercurial
sudo apt-get install zlib1g-dev
sudo apt-get install libncurses5-dev
sudo apt-get install python-dev
sudo apt-get install libssl-dev pkg-config (These are shipped with =
ubuntu11.10)
sudo apt-get install xorg-dev
sudo apt-get install uuid-dev
sudo apt-get install libyajl-dev
sudo apt-get install libaio-dev
sudo apt-get install libglib2.0-dev
sudo apt-get install bison
sudo apt-get install flex
sudo apt-get install gettext
sudo apt-get install iasl
sudo apt-get install bcc
sudo apt-get install markdown
sudo apt-get install udev

[ Clone the repository. ]

hg clone http://xenbits.xensource.com/xen-unstable.hg

[ Build it. ]

./configure
make world


-------------
Regards
Wang zhihao=

--Apple-Mail-1-656299358
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi , =
All<div><br></div><div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">I try to compile =
xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on =
ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal =
error: bits/predefs.h No such file or directory". I wonder it's a thing =
related to 32bits and 64bits. How to solve this problem? Thank =
you.</div></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">Here =
are my steps:</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">[ =
Install prerequisites. ]</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install git</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install mercurial</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install zlib1g-dev</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install =
libncurses5-dev</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install python-dev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install libssl-dev pkg-config (These are shipped with =
ubuntu11.10)</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install xorg-dev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install uuid-dev</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install =
libyajl-dev</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install libaio-dev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install libglib2.0-dev</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install bison</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install flex</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install gettext</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install iasl</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install bcc</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install markdown</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install udev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; =
min-height: 25px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">[ Clone the repository. ]</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; =
min-height: 25px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">hg clone <a =
href=3D"http://xenbits.xensource.com/xen-unstable.hg">http://xenbits.xenso=
urce.com/xen-unstable.hg</a></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">[ =
Build it. ]</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; =
">./configure</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">make =
world</div><div><br></div><div><br></div><div>-------------</div><div>Rega=
rds</div><div>Wang zhihao</div></div></body></html>=

--Apple-Mail-1-656299358--


--===============1807241726539057845==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1807241726539057845==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 13:10:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOSI-0000S9-G6; Thu, 26 Apr 2012 13:09:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SNOSH-0000Rz-4a
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:09:53 +0000
Received: from [85.158.143.99:49293] by server-3.bemta-4.messagelabs.com id
	E0/C4-05853-029499F4; Thu, 26 Apr 2012 13:09:52 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335445789!22018376!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17628 invoked from network); 26 Apr 2012 13:09:51 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:09:51 -0000
Received: by dajx4 with SMTP id x4so1776169daj.28
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:subject:date:message-id:to:mime-version:x-mailer;
	bh=PhhANlmWWI6iV5lsMCZe/pPjB5Wo9cZz+LxsknsUnCg=;
	b=1FoUMUujLmGBMHbgZpPmz5AWKBHgIuujJqEdoZXSugICbMq6wmXLGTXFY9sdk5YNsq
	8JuGwpQbznfyi2NbmyN5JxdgsTCU6HI1BNhe7D+j+LGhpjjnRSW+Zq6NRy7iF9ng4tM5
	8QOH9Ninl6odhT2nbmIQLFBoJ3BniDggVi5Fm6Tr9d89FWnUPVSOvsgrQki63CrYqxzJ
	Ar+ZuYp2ihUtjyTNas3TQQTNSdZV39of8fetix/8ojjAMkijjepnfwWLx5pVcUoLyarA
	dtR/PloHhnSumKeZ/cX9NWkql4/fw9omLj+tvSJ0aVRKYu2Ap8QuDgsmfAF9ftqiN3jS
	dduQ==
Received: by 10.68.194.71 with SMTP id hu7mr3630116pbc.158.1335445789369;
	Thu, 26 Apr 2012 06:09:49 -0700 (PDT)
Received: from [10.30.0.13] ([159.226.43.35])
	by mx.google.com with ESMTPS id o9sm3254197pbe.60.2012.04.26.06.09.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 06:09:48 -0700 (PDT)
From: wang zhihao <accept.acm@gmail.com>
Date: Thu, 26 Apr 2012 21:09:44 +0800
Message-Id: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] How to avoid this error "bits/predefs.h No such file or
	directory" when compiling XEN?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1807241726539057845=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1807241726539057845==
Content-Type: multipart/alternative; boundary=Apple-Mail-1-656299358


--Apple-Mail-1-656299358
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi , All

I try to compile xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on =
ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal =
error: bits/predefs.h No such file or directory". I wonder it's a thing =
related to 32bits and 64bits. How to solve this problem? Thank you.


Here are my steps:

[ Install prerequisites. ]

sudo apt-get install git
sudo apt-get install mercurial
sudo apt-get install zlib1g-dev
sudo apt-get install libncurses5-dev
sudo apt-get install python-dev
sudo apt-get install libssl-dev pkg-config (These are shipped with =
ubuntu11.10)
sudo apt-get install xorg-dev
sudo apt-get install uuid-dev
sudo apt-get install libyajl-dev
sudo apt-get install libaio-dev
sudo apt-get install libglib2.0-dev
sudo apt-get install bison
sudo apt-get install flex
sudo apt-get install gettext
sudo apt-get install iasl
sudo apt-get install bcc
sudo apt-get install markdown
sudo apt-get install udev

[ Clone the repository. ]

hg clone http://xenbits.xensource.com/xen-unstable.hg

[ Build it. ]

./configure
make world


-------------
Regards
Wang zhihao=

--Apple-Mail-1-656299358
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi , =
All<div><br></div><div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">I try to compile =
xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on =
ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal =
error: bits/predefs.h No such file or directory". I wonder it's a thing =
related to 32bits and 64bits. How to solve this problem? Thank =
you.</div></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">Here =
are my steps:</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">[ =
Install prerequisites. ]</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install git</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install mercurial</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install zlib1g-dev</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install =
libncurses5-dev</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install python-dev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install libssl-dev pkg-config (These are shipped with =
ubuntu11.10)</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install xorg-dev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install uuid-dev</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install =
libyajl-dev</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install libaio-dev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install libglib2.0-dev</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install bison</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install flex</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install gettext</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install iasl</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">sudo apt-get install bcc</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">sudo =
apt-get install markdown</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">sudo apt-get install udev</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; =
min-height: 25px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">[ Clone the repository. ]</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; =
min-height: 25px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; ">hg clone <a =
href=3D"http://xenbits.xensource.com/xen-unstable.hg">http://xenbits.xenso=
urce.com/xen-unstable.hg</a></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; ">[ =
Build it. ]</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; min-height: 25px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 18px/normal Monaco; =
">./configure</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
18px/normal Monaco; ">make =
world</div><div><br></div><div><br></div><div>-------------</div><div>Rega=
rds</div><div>Wang zhihao</div></div></body></html>=

--Apple-Mail-1-656299358--


--===============1807241726539057845==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1807241726539057845==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 13:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOWf-0000lj-CV; Thu, 26 Apr 2012 13:14:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNOWd-0000lb-TC
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:14:24 +0000
Received: from [193.109.254.147:18181] by server-12.bemta-14.messagelabs.com
	id 9B/B0-05898-F2A499F4; Thu, 26 Apr 2012 13:14:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335446060!1275392!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27639 invoked from network); 26 Apr 2012 13:14:21 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:14:21 -0000
Received: by qabg40 with SMTP id g40so1662482qab.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:14:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=0eZBpm6Yi6gRshhYzf1uyJWkDI+isJkgAoVf0mlwNXE=;
	b=Kte4d/iz2dznxvZeZspaHx2v0r8lfRrrNJL+/7HbIGee2+QN6MrFPhUXuX+4yWh3Y0
	Aus93URRZFqf3atnfoMok9q77Gp9m85ivjXSxaKOxgw6ihcIDKsBGAQB2qxAUM4wjKEY
	bvLKGtOsC5aEgddgkHczyzUCt7TBNiXRcc4GWC+e/zGoQtrQhIhSKl7wcB3X3Szf2/sa
	vSroEH1UvbZfODLMXVQBw0BRaMhEOVvsaSwVgnNDc5c0/ip2df3tE/JA07M1cknOO9AD
	xnApcbQb7dGhX8pmxKDBB84cN8orcgSf1Sikdc4/FlJ3noxPOKxZJbu87oFmSVjM5P5S
	wSiQ==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr5139498qao.23.1335446060618; Thu,
	26 Apr 2012 06:14:20 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 06:14:20 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
Date: Thu, 26 Apr 2012 14:14:20 +0100
X-Google-Sender-Auth: hkxCMFiacFKnWSSlvkPsl0sPiWg
Message-ID: <CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> However this kernel does have blktap so why is qemu based AIO being used
>> at all?
>
> If blktap is present and working then libxl only uses QEMU for
> qcow/qcow2 disk images.

Hmm -- except that the process that's dying is clearly QEMU, and the
disk images are definitely not qcow*, and Ian seems to think this
kernel has blktap (how could I tell?), so something's not right.

Is there a command-line way to disable aio?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOWf-0000lj-CV; Thu, 26 Apr 2012 13:14:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNOWd-0000lb-TC
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:14:24 +0000
Received: from [193.109.254.147:18181] by server-12.bemta-14.messagelabs.com
	id 9B/B0-05898-F2A499F4; Thu, 26 Apr 2012 13:14:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1335446060!1275392!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27639 invoked from network); 26 Apr 2012 13:14:21 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:14:21 -0000
Received: by qabg40 with SMTP id g40so1662482qab.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:14:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=0eZBpm6Yi6gRshhYzf1uyJWkDI+isJkgAoVf0mlwNXE=;
	b=Kte4d/iz2dznxvZeZspaHx2v0r8lfRrrNJL+/7HbIGee2+QN6MrFPhUXuX+4yWh3Y0
	Aus93URRZFqf3atnfoMok9q77Gp9m85ivjXSxaKOxgw6ihcIDKsBGAQB2qxAUM4wjKEY
	bvLKGtOsC5aEgddgkHczyzUCt7TBNiXRcc4GWC+e/zGoQtrQhIhSKl7wcB3X3Szf2/sa
	vSroEH1UvbZfODLMXVQBw0BRaMhEOVvsaSwVgnNDc5c0/ip2df3tE/JA07M1cknOO9AD
	xnApcbQb7dGhX8pmxKDBB84cN8orcgSf1Sikdc4/FlJ3noxPOKxZJbu87oFmSVjM5P5S
	wSiQ==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr5139498qao.23.1335446060618; Thu,
	26 Apr 2012 06:14:20 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 06:14:20 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
Date: Thu, 26 Apr 2012 14:14:20 +0100
X-Google-Sender-Auth: hkxCMFiacFKnWSSlvkPsl0sPiWg
Message-ID: <CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> However this kernel does have blktap so why is qemu based AIO being used
>> at all?
>
> If blktap is present and working then libxl only uses QEMU for
> qcow/qcow2 disk images.

Hmm -- except that the process that's dying is clearly QEMU, and the
disk images are definitely not qcow*, and Ian seems to think this
kernel has blktap (how could I tell?), so something's not right.

Is there a command-line way to disable aio?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:25:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOgl-0000wk-IO; Thu, 26 Apr 2012 13:24:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNOgk-0000wf-Bc
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:24:50 +0000
Received: from [85.158.138.51:59281] by server-3.bemta-3.messagelabs.com id
	B0/AC-04048-1AC499F4; Thu, 26 Apr 2012 13:24:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335446688!23852361!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1880 invoked from network); 26 Apr 2012 13:24:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:24:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12156304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:24:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:24:48 +0100
Message-ID: <1335446686.28015.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 14:24:46 +0100
In-Reply-To: <CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:14 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> >> However this kernel does have blktap so why is qemu based AIO being used
> >> at all?
> >
> > If blktap is present and working then libxl only uses QEMU for
> > qcow/qcow2 disk images.
> 
> Hmm -- except that the process that's dying is clearly QEMU, and the
> disk images are definitely not qcow*, and Ian seems to think this
> kernel has blktap (how could I tell?), so something's not right.

It looks like it is a module -- lsmod should confirm, maybe it's a
simple as loading it?

(if so let me know and I'll be sure to include that when I write up
"installing a Debian Dom0")

> 
> Is there a command-line way to disable aio?
> 
>  -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:25:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOgl-0000wk-IO; Thu, 26 Apr 2012 13:24:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNOgk-0000wf-Bc
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:24:50 +0000
Received: from [85.158.138.51:59281] by server-3.bemta-3.messagelabs.com id
	B0/AC-04048-1AC499F4; Thu, 26 Apr 2012 13:24:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335446688!23852361!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1880 invoked from network); 26 Apr 2012 13:24:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:24:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12156304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:24:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:24:48 +0100
Message-ID: <1335446686.28015.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 14:24:46 +0100
In-Reply-To: <CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:14 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> >> However this kernel does have blktap so why is qemu based AIO being used
> >> at all?
> >
> > If blktap is present and working then libxl only uses QEMU for
> > qcow/qcow2 disk images.
> 
> Hmm -- except that the process that's dying is clearly QEMU, and the
> disk images are definitely not qcow*, and Ian seems to think this
> kernel has blktap (how could I tell?), so something's not right.

It looks like it is a module -- lsmod should confirm, maybe it's a
simple as loading it?

(if so let me know and I'll be sure to include that when I write up
"installing a Debian Dom0")

> 
> Is there a command-line way to disable aio?
> 
>  -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:43:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOyS-0001BX-AU; Thu, 26 Apr 2012 13:43:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNOyR-0001BS-6N
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:43:07 +0000
Received: from [85.158.139.83:21077] by server-3.bemta-5.messagelabs.com id
	BF/22-25237-AE0599F4; Thu, 26 Apr 2012 13:43:06 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335447784!18400345!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22060 invoked from network); 26 Apr 2012 13:43:05 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:43:05 -0000
Received: by qabg40 with SMTP id g40so1685018qab.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4qOEL5wUg1TNtq1meGdUJZZPHvVq+qfWTM5Tw5EnpgA=;
	b=LSNbpw7Rdyh2Xsb8sbtNO3S79iWLrRxTu4jOvDH14OffhMTT166MOr/kzqNi6l+SzV
	ftvptpGHB9DcmwmciFAO2x1sLUbRSfaRWotKumFAwUZ0HJd9MBzJQD+J8Po4Ew9Zin2c
	K69qAZXKaIHNkWLB119e0yIPfpeVQSxQVGWac3PDU9TourzQZz+0itBtv6lbH4sZgQZG
	JfhAlBFpyoeVclSiHDAJRXRMouk1L+TUjaj8lRPGicUDkxQhHj4F33OK9OhlqxQ80Xg2
	9f7CbJIGwsgcZt5zEAXpinz7kvmLRKXTgKdsvujV46+Bbpne7qE9WdA6N23UJwbiPbHd
	vLBQ==
MIME-Version: 1.0
Received: by 10.229.135.210 with SMTP id o18mr1514910qct.109.1335447783316;
	Thu, 26 Apr 2012 06:43:03 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 06:43:03 -0700 (PDT)
In-Reply-To: <1335446686.28015.150.camel@zakaz.uk.xensource.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
Date: Thu, 26 Apr 2012 14:43:03 +0100
X-Google-Sender-Auth: Ejx3iTpqK0SdSI-Djd7xoOoZoFQ
Message-ID: <CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 2:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-04-26 at 14:14 +0100, George Dunlap wrote:
>> On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> However this kernel does have blktap so why is qemu based AIO being used
>> >> at all?
>> >
>> > If blktap is present and working then libxl only uses QEMU for
>> > qcow/qcow2 disk images.
>>
>> Hmm -- except that the process that's dying is clearly QEMU, and the
>> disk images are definitely not qcow*, and Ian seems to think this
>> kernel has blktap (how could I tell?), so something's not right.
>
> It looks like it is a module -- lsmod should confirm, maybe it's a
> simple as loading it?
>
> (if so let me know and I'll be sure to include that when I write up
> "installing a Debian Dom0")

Indeed, blktap was *not* loaded, and "modprobe blktap" seems make things work.

Should this be done in one of the initscripts?  Or perhaps by xl?

It would still be good to get the AIO stuff fixed in some way, as I'm
sure I'm not the only one who's going to run into this problem.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:43:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNOyS-0001BX-AU; Thu, 26 Apr 2012 13:43:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNOyR-0001BS-6N
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:43:07 +0000
Received: from [85.158.139.83:21077] by server-3.bemta-5.messagelabs.com id
	BF/22-25237-AE0599F4; Thu, 26 Apr 2012 13:43:06 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335447784!18400345!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22060 invoked from network); 26 Apr 2012 13:43:05 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:43:05 -0000
Received: by qabg40 with SMTP id g40so1685018qab.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4qOEL5wUg1TNtq1meGdUJZZPHvVq+qfWTM5Tw5EnpgA=;
	b=LSNbpw7Rdyh2Xsb8sbtNO3S79iWLrRxTu4jOvDH14OffhMTT166MOr/kzqNi6l+SzV
	ftvptpGHB9DcmwmciFAO2x1sLUbRSfaRWotKumFAwUZ0HJd9MBzJQD+J8Po4Ew9Zin2c
	K69qAZXKaIHNkWLB119e0yIPfpeVQSxQVGWac3PDU9TourzQZz+0itBtv6lbH4sZgQZG
	JfhAlBFpyoeVclSiHDAJRXRMouk1L+TUjaj8lRPGicUDkxQhHj4F33OK9OhlqxQ80Xg2
	9f7CbJIGwsgcZt5zEAXpinz7kvmLRKXTgKdsvujV46+Bbpne7qE9WdA6N23UJwbiPbHd
	vLBQ==
MIME-Version: 1.0
Received: by 10.229.135.210 with SMTP id o18mr1514910qct.109.1335447783316;
	Thu, 26 Apr 2012 06:43:03 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 06:43:03 -0700 (PDT)
In-Reply-To: <1335446686.28015.150.camel@zakaz.uk.xensource.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
Date: Thu, 26 Apr 2012 14:43:03 +0100
X-Google-Sender-Auth: Ejx3iTpqK0SdSI-Djd7xoOoZoFQ
Message-ID: <CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 2:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-04-26 at 14:14 +0100, George Dunlap wrote:
>> On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> However this kernel does have blktap so why is qemu based AIO being used
>> >> at all?
>> >
>> > If blktap is present and working then libxl only uses QEMU for
>> > qcow/qcow2 disk images.
>>
>> Hmm -- except that the process that's dying is clearly QEMU, and the
>> disk images are definitely not qcow*, and Ian seems to think this
>> kernel has blktap (how could I tell?), so something's not right.
>
> It looks like it is a module -- lsmod should confirm, maybe it's a
> simple as loading it?
>
> (if so let me know and I'll be sure to include that when I write up
> "installing a Debian Dom0")

Indeed, blktap was *not* loaded, and "modprobe blktap" seems make things work.

Should this be done in one of the initscripts?  Or perhaps by xl?

It would still be good to get the AIO stuff fixed in some way, as I'm
sure I'm not the only one who's going to run into this problem.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:47:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:47:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNP2D-0001IX-Uu; Thu, 26 Apr 2012 13:47:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNP2C-0001IQ-H5
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:47:00 +0000
Received: from [85.158.139.83:22248] by server-11.bemta-5.messagelabs.com id
	10/0E-12959-3D1599F4; Thu, 26 Apr 2012 13:46:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335448017!25671432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18808 invoked from network); 26 Apr 2012 13:46:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:46:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:46:57 +0100
Message-ID: <1335448015.28015.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 14:46:55 +0100
In-Reply-To: <CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:43 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 2:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-26 at 14:14 +0100, George Dunlap wrote:
> >> On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> However this kernel does have blktap so why is qemu based AIO being used
> >> >> at all?
> >> >
> >> > If blktap is present and working then libxl only uses QEMU for
> >> > qcow/qcow2 disk images.
> >>
> >> Hmm -- except that the process that's dying is clearly QEMU, and the
> >> disk images are definitely not qcow*, and Ian seems to think this
> >> kernel has blktap (how could I tell?), so something's not right.
> >
> > It looks like it is a module -- lsmod should confirm, maybe it's a
> > simple as loading it?
> >
> > (if so let me know and I'll be sure to include that when I write up
> > "installing a Debian Dom0")
> 
> Indeed, blktap was *not* loaded, and "modprobe blktap" seems make things work.
> 
> Should this be done in one of the initscripts?  Or perhaps by xl?

xencommons should do it, IMHO.

> It would still be good to get the AIO stuff fixed in some way, as I'm
> sure I'm not the only one who's going to run into this problem.

Stefano has fixed it in the upstream kernel. I'm afraid there is no
realistic chance of it being fixed in the squeeze kernel at this stage.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:47:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:47:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNP2D-0001IX-Uu; Thu, 26 Apr 2012 13:47:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNP2C-0001IQ-H5
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:47:00 +0000
Received: from [85.158.139.83:22248] by server-11.bemta-5.messagelabs.com id
	10/0E-12959-3D1599F4; Thu, 26 Apr 2012 13:46:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1335448017!25671432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18808 invoked from network); 26 Apr 2012 13:46:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:46:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:46:57 +0100
Message-ID: <1335448015.28015.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 14:46:55 +0100
In-Reply-To: <CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:43 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 2:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-26 at 14:14 +0100, George Dunlap wrote:
> >> On Thu, Apr 26, 2012 at 1:07 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> However this kernel does have blktap so why is qemu based AIO being used
> >> >> at all?
> >> >
> >> > If blktap is present and working then libxl only uses QEMU for
> >> > qcow/qcow2 disk images.
> >>
> >> Hmm -- except that the process that's dying is clearly QEMU, and the
> >> disk images are definitely not qcow*, and Ian seems to think this
> >> kernel has blktap (how could I tell?), so something's not right.
> >
> > It looks like it is a module -- lsmod should confirm, maybe it's a
> > simple as loading it?
> >
> > (if so let me know and I'll be sure to include that when I write up
> > "installing a Debian Dom0")
> 
> Indeed, blktap was *not* loaded, and "modprobe blktap" seems make things work.
> 
> Should this be done in one of the initscripts?  Or perhaps by xl?

xencommons should do it, IMHO.

> It would still be good to get the AIO stuff fixed in some way, as I'm
> sure I'm not the only one who's going to run into this problem.

Stefano has fixed it in the upstream kernel. I'm afraid there is no
realistic chance of it being fixed in the squeeze kernel at this stage.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:49:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNP4K-0001OT-Fk; Thu, 26 Apr 2012 13:49:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNP4J-0001ON-Hz
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 13:49:11 +0000
Received: from [85.158.138.51:5081] by server-12.bemta-3.messagelabs.com id
	D2/67-29760-652599F4; Thu, 26 Apr 2012 13:49:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335448149!23950205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12760 invoked from network); 26 Apr 2012 13:49:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:49:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:49:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:49:08 +0100
Message-ID: <1335448147.28015.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 14:49:07 +0100
In-Reply-To: <1335441981052-5667398.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<1335441981052-5667398.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 13:06 +0100, Fantu wrote:
> Ian Campbell-10 wrote
> > 
> > Can you run with "xl -vvv create"?
> > What is in lucid.cfg?
> > 
> 
> Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl
> configuration file used:
> -------------------------------
> lucid.cfg
> ---------
> name="lucid"
> vcpus=2
> memory=512
> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
> vif=['bridge=xenbr0']
> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> bootloader = '/usr/bin/pygrub'
> -------------------------------
> 
> xl -vvv create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda1, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda2 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda2, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=tap
> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
> # And after freeze

I coincidentally just saw something like this and it turned out to be
because I needed to set "PYTHON_PREFIX_ARG = --install-layout=deb" in
Config.mk.

What happens if you run "pygrub /mnt/vm/disks/lucid.disk1.xm"?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:49:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNP4K-0001OT-Fk; Thu, 26 Apr 2012 13:49:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNP4J-0001ON-Hz
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 13:49:11 +0000
Received: from [85.158.138.51:5081] by server-12.bemta-3.messagelabs.com id
	D2/67-29760-652599F4; Thu, 26 Apr 2012 13:49:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335448149!23950205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12760 invoked from network); 26 Apr 2012 13:49:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:49:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:49:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 14:49:08 +0100
Message-ID: <1335448147.28015.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 14:49:07 +0100
In-Reply-To: <1335441981052-5667398.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<1335441981052-5667398.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 13:06 +0100, Fantu wrote:
> Ian Campbell-10 wrote
> > 
> > Can you run with "xl -vvv create"?
> > What is in lucid.cfg?
> > 
> 
> Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl
> configuration file used:
> -------------------------------
> lucid.cfg
> ---------
> name="lucid"
> vcpus=2
> memory=512
> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
> vif=['bridge=xenbr0']
> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> bootloader = '/usr/bin/pygrub'
> -------------------------------
> 
> xl -vvv create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda1, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda2 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda2, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=tap
> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
> # And after freeze

I coincidentally just saw something like this and it turned out to be
because I needed to set "PYTHON_PREFIX_ARG = --install-layout=deb" in
Config.mk.

What happens if you run "pygrub /mnt/vm/disks/lucid.disk1.xm"?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:56:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPAy-0001bR-Bu; Thu, 26 Apr 2012 13:56:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNPAw-0001bL-R1
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:56:03 +0000
Received: from [85.158.143.99:60563] by server-2.bemta-4.messagelabs.com id
	5C/18-17550-2F3599F4; Thu, 26 Apr 2012 13:56:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335448559!15775193!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11636 invoked from network); 26 Apr 2012 13:56:00 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:56:00 -0000
Received: by qcsc20 with SMTP id c20so907893qcs.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=MyappYn+E0JjuITPslzIyaD9ryzuj87Ap7eAVTC7luE=;
	b=bkUxM51XRmXu1E1ERDZj0DWu6QT/aoK86ZLkr5F27+fPAyWRkR9ewYLNWqO6FFt9DO
	r4vc9XTouv5TpkGllQWZIoFiBLvsGJ1EXAFCCu3IpfqLycXi3ucXvJqOBbeLZfmKgXDF
	Vl+rCKAFNtXSN/+95llZG7xzIPAlEEJAftnj/Tlu5wqrP3pFj1m7i6zGazyktDaYHP4e
	0Chz9UpEeotUazRbf0YPPZt2cefT0W0jjgITQuaLypPjr1GicUwVNCJ0VbqbDK9n+80s
	+UhRLGkeN3KvMaDU6HZLRSKP0RxV6z9tQijmyukgrgMHezh0vzWnXolzkrpcCLiynoyg
	30NQ==
MIME-Version: 1.0
Received: by 10.229.135.78 with SMTP id m14mr1536777qct.129.1335448558165;
	Thu, 26 Apr 2012 06:55:58 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 06:55:58 -0700 (PDT)
In-Reply-To: <1335448015.28015.151.camel@zakaz.uk.xensource.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
Date: Thu, 26 Apr 2012 14:55:58 +0100
X-Google-Sender-Auth: Pu4MWSmmhnx0cv8KnT-EbZErbeo
Message-ID: <CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> It would still be good to get the AIO stuff fixed in some way, as I'm
>> sure I'm not the only one who's going to run into this problem.
>
> Stefano has fixed it in the upstream kernel. I'm afraid there is no
> realistic chance of it being fixed in the squeeze kernel at this stage.

Any chance we could get AIO disabled in the squeeze kernel then?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:56:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPAy-0001bR-Bu; Thu, 26 Apr 2012 13:56:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNPAw-0001bL-R1
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 13:56:03 +0000
Received: from [85.158.143.99:60563] by server-2.bemta-4.messagelabs.com id
	5C/18-17550-2F3599F4; Thu, 26 Apr 2012 13:56:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1335448559!15775193!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11636 invoked from network); 26 Apr 2012 13:56:00 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 13:56:00 -0000
Received: by qcsc20 with SMTP id c20so907893qcs.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 06:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=MyappYn+E0JjuITPslzIyaD9ryzuj87Ap7eAVTC7luE=;
	b=bkUxM51XRmXu1E1ERDZj0DWu6QT/aoK86ZLkr5F27+fPAyWRkR9ewYLNWqO6FFt9DO
	r4vc9XTouv5TpkGllQWZIoFiBLvsGJ1EXAFCCu3IpfqLycXi3ucXvJqOBbeLZfmKgXDF
	Vl+rCKAFNtXSN/+95llZG7xzIPAlEEJAftnj/Tlu5wqrP3pFj1m7i6zGazyktDaYHP4e
	0Chz9UpEeotUazRbf0YPPZt2cefT0W0jjgITQuaLypPjr1GicUwVNCJ0VbqbDK9n+80s
	+UhRLGkeN3KvMaDU6HZLRSKP0RxV6z9tQijmyukgrgMHezh0vzWnXolzkrpcCLiynoyg
	30NQ==
MIME-Version: 1.0
Received: by 10.229.135.78 with SMTP id m14mr1536777qct.129.1335448558165;
	Thu, 26 Apr 2012 06:55:58 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Thu, 26 Apr 2012 06:55:58 -0700 (PDT)
In-Reply-To: <1335448015.28015.151.camel@zakaz.uk.xensource.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
Date: Thu, 26 Apr 2012 14:55:58 +0100
X-Google-Sender-Auth: Pu4MWSmmhnx0cv8KnT-EbZErbeo
Message-ID: <CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> It would still be good to get the AIO stuff fixed in some way, as I'm
>> sure I'm not the only one who's going to run into this problem.
>
> Stefano has fixed it in the upstream kernel. I'm afraid there is no
> realistic chance of it being fixed in the squeeze kernel at this stage.

Any chance we could get AIO disabled in the squeeze kernel then?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:57:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPC8-0001ec-QE; Thu, 26 Apr 2012 13:57:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNPC7-0001eW-C1
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 13:57:15 +0000
Received: from [85.158.139.83:63280] by server-1.bemta-5.messagelabs.com id
	19/45-28458-A34599F4; Thu, 26 Apr 2012 13:57:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335448632!21761286!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30081 invoked from network); 26 Apr 2012 13:57:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 13:57:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNPC4-0005kl-B4
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 06:57:12 -0700
Date: Thu, 26 Apr 2012 06:57:12 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335448632335-5667689.post@n5.nabble.com>
In-Reply-To: <1335448147.28015.152.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<1335441981052-5667398.post@n5.nabble.com>
	<1335448147.28015.152.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pygrub /mnt/vm/disks/lucid.disk1.xm
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 20, in <module>
    import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667689.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 13:57:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 13:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPC8-0001ec-QE; Thu, 26 Apr 2012 13:57:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNPC7-0001eW-C1
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 13:57:15 +0000
Received: from [85.158.139.83:63280] by server-1.bemta-5.messagelabs.com id
	19/45-28458-A34599F4; Thu, 26 Apr 2012 13:57:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335448632!21761286!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30081 invoked from network); 26 Apr 2012 13:57:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 13:57:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNPC4-0005kl-B4
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 06:57:12 -0700
Date: Thu, 26 Apr 2012 06:57:12 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335448632335-5667689.post@n5.nabble.com>
In-Reply-To: <1335448147.28015.152.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<1335441981052-5667398.post@n5.nabble.com>
	<1335448147.28015.152.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pygrub /mnt/vm/disks/lucid.disk1.xm
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 20, in <module>
    import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667689.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPF8-0001sV-C5; Thu, 26 Apr 2012 14:00:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNPF7-0001sI-0n
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:00:21 +0000
Received: from [85.158.138.51:41940] by server-12.bemta-3.messagelabs.com id
	56/59-29760-4F4599F4; Thu, 26 Apr 2012 14:00:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335448819!23859525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17121 invoked from network); 26 Apr 2012 14:00:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:00:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 15:00:19 +0100
Message-ID: <1335448817.28015.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 15:00:17 +0100
In-Reply-To: <CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
	<CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:55 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> It would still be good to get the AIO stuff fixed in some way, as I'm
> >> sure I'm not the only one who's going to run into this problem.
> >
> > Stefano has fixed it in the upstream kernel. I'm afraid there is no
> > realistic chance of it being fixed in the squeeze kernel at this stage.
> 
> Any chance we could get AIO disabled in the squeeze kernel then?

I don't think so, that would break legitimate uses of AIO.

We could potentially ensure that Xen/qemu doesn't try to use AIO on
older kernels but AIUI you were running a newer version than provided in
Squeeze so that isn't something we can fix in Debian?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPF8-0001sV-C5; Thu, 26 Apr 2012 14:00:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNPF7-0001sI-0n
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:00:21 +0000
Received: from [85.158.138.51:41940] by server-12.bemta-3.messagelabs.com id
	56/59-29760-4F4599F4; Thu, 26 Apr 2012 14:00:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335448819!23859525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17121 invoked from network); 26 Apr 2012 14:00:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:00:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 15:00:19 +0100
Message-ID: <1335448817.28015.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 26 Apr 2012 15:00:17 +0100
In-Reply-To: <CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
	<CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:55 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> It would still be good to get the AIO stuff fixed in some way, as I'm
> >> sure I'm not the only one who's going to run into this problem.
> >
> > Stefano has fixed it in the upstream kernel. I'm afraid there is no
> > realistic chance of it being fixed in the squeeze kernel at this stage.
> 
> Any chance we could get AIO disabled in the squeeze kernel then?

I don't think so, that would break legitimate uses of AIO.

We could potentially ensure that Xen/qemu doesn't try to use AIO on
older kernels but AIUI you were running a newer version than provided in
Squeeze so that isn't something we can fix in Debian?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:04:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPId-00024m-5Q; Thu, 26 Apr 2012 14:03:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNPIc-00024b-7I
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:03:58 +0000
Received: from [85.158.138.51:28786] by server-12.bemta-3.messagelabs.com id
	68/98-29760-DC5599F4; Thu, 26 Apr 2012 14:03:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335449036!12943714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26122 invoked from network); 26 Apr 2012 14:03:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:03:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:03:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 15:03:56 +0100
Date: Thu, 26 Apr 2012 15:10:11 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335448817.28015.155.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204261508480.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com> 
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
	<CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
	<1335448817.28015.155.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Ian Campbell wrote:
> On Thu, 2012-04-26 at 14:55 +0100, George Dunlap wrote:
> > On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> It would still be good to get the AIO stuff fixed in some way, as I'm
> > >> sure I'm not the only one who's going to run into this problem.
> > >
> > > Stefano has fixed it in the upstream kernel. I'm afraid there is no
> > > realistic chance of it being fixed in the squeeze kernel at this stage.
> > 
> > Any chance we could get AIO disabled in the squeeze kernel then?
> 
> I don't think so, that would break legitimate uses of AIO.
> 
> We could potentially ensure that Xen/qemu doesn't try to use AIO on
> older kernels but AIUI you were running a newer version than provided in
> Squeeze so that isn't something we can fix in Debian?

We could add a patch in Debian to disable AIO and O_DIRECT in QEMU.

Otherwise I don't really know what we could do upstream to detect
whether a kernel has a buggy O_DIRECT/AIO implementation or not.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:04:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPId-00024m-5Q; Thu, 26 Apr 2012 14:03:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNPIc-00024b-7I
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:03:58 +0000
Received: from [85.158.138.51:28786] by server-12.bemta-3.messagelabs.com id
	68/98-29760-DC5599F4; Thu, 26 Apr 2012 14:03:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335449036!12943714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26122 invoked from network); 26 Apr 2012 14:03:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:03:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12157809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:03:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 15:03:56 +0100
Date: Thu, 26 Apr 2012 15:10:11 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335448817.28015.155.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1204261508480.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com> 
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
	<CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
	<1335448817.28015.155.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012, Ian Campbell wrote:
> On Thu, 2012-04-26 at 14:55 +0100, George Dunlap wrote:
> > On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> It would still be good to get the AIO stuff fixed in some way, as I'm
> > >> sure I'm not the only one who's going to run into this problem.
> > >
> > > Stefano has fixed it in the upstream kernel. I'm afraid there is no
> > > realistic chance of it being fixed in the squeeze kernel at this stage.
> > 
> > Any chance we could get AIO disabled in the squeeze kernel then?
> 
> I don't think so, that would break legitimate uses of AIO.
> 
> We could potentially ensure that Xen/qemu doesn't try to use AIO on
> older kernels but AIUI you were running a newer version than provided in
> Squeeze so that isn't something we can fix in Debian?

We could add a patch in Debian to disable AIO and O_DIRECT in QEMU.

Otherwise I don't really know what we could do upstream to detect
whether a kernel has a buggy O_DIRECT/AIO implementation or not.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:18:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPWM-0002L4-Jb; Thu, 26 Apr 2012 14:18:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNPWL-0002Kw-5D
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:18:09 +0000
Received: from [193.109.254.147:41306] by server-1.bemta-14.messagelabs.com id
	13/57-29372-029599F4; Thu, 26 Apr 2012 14:18:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335449886!798771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19419 invoked from network); 26 Apr 2012 14:18:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:18:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12158317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:18:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 15:18:05 +0100
Message-ID: <1335449884.28015.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 26 Apr 2012 15:18:04 +0100
In-Reply-To: <alpine.DEB.2.00.1204261508480.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
	<CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
	<1335448817.28015.155.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261508480.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 15:10 +0100, Stefano Stabellini wrote:
> On Thu, 26 Apr 2012, Ian Campbell wrote:
> > On Thu, 2012-04-26 at 14:55 +0100, George Dunlap wrote:
> > > On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > >> It would still be good to get the AIO stuff fixed in some way, as I'm
> > > >> sure I'm not the only one who's going to run into this problem.
> > > >
> > > > Stefano has fixed it in the upstream kernel. I'm afraid there is no
> > > > realistic chance of it being fixed in the squeeze kernel at this stage.
> > > 
> > > Any chance we could get AIO disabled in the squeeze kernel then?
> > 
> > I don't think so, that would break legitimate uses of AIO.
> > 
> > We could potentially ensure that Xen/qemu doesn't try to use AIO on
> > older kernels but AIUI you were running a newer version than provided in
> > Squeeze so that isn't something we can fix in Debian?
> 
> We could add a patch in Debian to disable AIO and O_DIRECT in QEMU.

AUIU Qemu in this case is not the qemu in Debian, it's the one from
xen-unstable.

> Otherwise I don't really know what we could do upstream to detect
> whether a kernel has a buggy O_DIRECT/AIO implementation or not.

Me neither.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:18:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPWM-0002L4-Jb; Thu, 26 Apr 2012 14:18:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNPWL-0002Kw-5D
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:18:09 +0000
Received: from [193.109.254.147:41306] by server-1.bemta-14.messagelabs.com id
	13/57-29372-029599F4; Thu, 26 Apr 2012 14:18:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335449886!798771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19419 invoked from network); 26 Apr 2012 14:18:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:18:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12158317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:18:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 15:18:05 +0100
Message-ID: <1335449884.28015.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 26 Apr 2012 15:18:04 +0100
In-Reply-To: <alpine.DEB.2.00.1204261508480.26786@kaball-desktop>
References: <CAFLBxZZjaRprdo_-ADpyB1bmfOW2zxTjaDCcSTFL90wNMLX4Vg@mail.gmail.com>
	<1335437978.28015.103.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261218410.26786@kaball-desktop>
	<1335439154.28015.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261306350.26786@kaball-desktop>
	<CAFLBxZY0=HMRDAvM_mzw+tVK0JDvBFG59beLpKV2c39Zk6u2fQ@mail.gmail.com>
	<1335446686.28015.150.camel@zakaz.uk.xensource.com>
	<CAFLBxZbQyfZkm1OC6F3pXN7cznaM0mv0L_9JBKswG51yKRZpaQ@mail.gmail.com>
	<1335448015.28015.151.camel@zakaz.uk.xensource.com>
	<CAFLBxZYMZ_kyamNfW_OV7thGv7yYT9tY2vgEQeiJ_jP46f5beg@mail.gmail.com>
	<1335448817.28015.155.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204261508480.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 15:10 +0100, Stefano Stabellini wrote:
> On Thu, 26 Apr 2012, Ian Campbell wrote:
> > On Thu, 2012-04-26 at 14:55 +0100, George Dunlap wrote:
> > > On Thu, Apr 26, 2012 at 2:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > >> It would still be good to get the AIO stuff fixed in some way, as I'm
> > > >> sure I'm not the only one who's going to run into this problem.
> > > >
> > > > Stefano has fixed it in the upstream kernel. I'm afraid there is no
> > > > realistic chance of it being fixed in the squeeze kernel at this stage.
> > > 
> > > Any chance we could get AIO disabled in the squeeze kernel then?
> > 
> > I don't think so, that would break legitimate uses of AIO.
> > 
> > We could potentially ensure that Xen/qemu doesn't try to use AIO on
> > older kernels but AIUI you were running a newer version than provided in
> > Squeeze so that isn't something we can fix in Debian?
> 
> We could add a patch in Debian to disable AIO and O_DIRECT in QEMU.

AUIU Qemu in this case is not the qemu in Debian, it's the one from
xen-unstable.

> Otherwise I don't really know what we could do upstream to detect
> whether a kernel has a buggy O_DIRECT/AIO implementation or not.

Me neither.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPaH-0002Sb-C9; Thu, 26 Apr 2012 14:22:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNPaF-0002SS-OC
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:22:11 +0000
Received: from [85.158.143.99:32080] by server-3.bemta-4.messagelabs.com id
	0A/67-05853-21A599F4; Thu, 26 Apr 2012 14:22:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335450130!20088138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27175 invoked from network); 26 Apr 2012 14:22:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:22:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12158414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:21:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 15:21:57 +0100
Message-ID: <1335450116.28015.157.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 15:21:56 +0100
In-Reply-To: <1335448632335-5667689.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<1335441981052-5667398.post@n5.nabble.com>
	<1335448147.28015.152.camel@zakaz.uk.xensource.com>
	<1335448632335-5667689.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:57 +0100, Fantu wrote:
> pygrub /mnt/vm/disks/lucid.disk1.xm
> Traceback (most recent call last):
>   File "/usr/bin/pygrub", line 20, in <module>
>     import xen.lowlevel.xc
> ImportError: No module named xen.lowlevel.xc

This is the same symptoms as the PYTHON_PREFIX_ARG issue I described.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPaH-0002Sb-C9; Thu, 26 Apr 2012 14:22:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNPaF-0002SS-OC
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:22:11 +0000
Received: from [85.158.143.99:32080] by server-3.bemta-4.messagelabs.com id
	0A/67-05853-21A599F4; Thu, 26 Apr 2012 14:22:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335450130!20088138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27175 invoked from network); 26 Apr 2012 14:22:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:22:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="12158414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 14:21:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 15:21:57 +0100
Message-ID: <1335450116.28015.157.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 15:21:56 +0100
In-Reply-To: <1335448632335-5667689.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<1335441981052-5667398.post@n5.nabble.com>
	<1335448147.28015.152.camel@zakaz.uk.xensource.com>
	<1335448632335-5667689.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 14:57 +0100, Fantu wrote:
> pygrub /mnt/vm/disks/lucid.disk1.xm
> Traceback (most recent call last):
>   File "/usr/bin/pygrub", line 20, in <module>
>     import xen.lowlevel.xc
> ImportError: No module named xen.lowlevel.xc

This is the same symptoms as the PYTHON_PREFIX_ARG issue I described.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPhg-0002dE-9q; Thu, 26 Apr 2012 14:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPhf-0002d5-7Q
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:29:51 +0000
Received: from [85.158.143.99:55523] by server-1.bemta-4.messagelabs.com id
	0A/93-20925-EDB599F4; Thu, 26 Apr 2012 14:29:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335450588!24844637!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28368 invoked from network); 26 Apr 2012 14:29:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:29:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="24572632"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-Ni;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2783a97c5d5de4ac7b36883646c4183cab33b3ba
Message-ID: <2783a97c5d5de4ac7b36.1335450373@kodo2>
In-Reply-To: <patchbomb.1335450371@kodo2>
References: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:13 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] tools: Install pv bootloaders in libexec
 rather than /usr/bin
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pygrub and xenpvnetboot are meant to be run by tools, and not by the user,
and thus should be in /usr/lib/xen/bin rather than /usr/bin.

Because most config files will still have an absolute path pointing to
/usr/bin/pygrub, make a symbolic link that we will deprecate.

diff -r b810908dea7d -r 2783a97c5d5d tools/misc/Makefile
--- a/tools/misc/Makefile	Thu Apr 26 15:09:35 2012 +0100
+++ b/tools/misc/Makefile	Thu Apr 26 15:23:56 2012 +0100
@@ -18,7 +18,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount
 SUBDIRS-$(CONFIG_MINITERM) += miniterm
 SUBDIRS := $(SUBDIRS-y)
 
-INSTALL_BIN-y := xencons xenpvnetboot
+INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
@@ -27,6 +27,9 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
 
+INSTALL_PRIVBIN-y := xenpvnetboot
+INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y)
+
 # Include configure output (config.h) to headers search path
 CFLAGS += -I$(XEN_ROOT)/tools
 
@@ -41,8 +44,10 @@ build: $(TARGETS)
 install: build
 	$(INSTALL_DIR) $(DESTDIR)$(BINDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PYTHON_PROG) $(INSTALL_BIN) $(DESTDIR)$(BINDIR)
 	$(INSTALL_PYTHON_PROG) $(INSTALL_SBIN) $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PYTHON_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(PRIVATE_BINDIR)
 	set -e; for d in $(SUBDIRS); do $(MAKE) -C $$d install-recurse; done
 
 .PHONY: clean
diff -r b810908dea7d -r 2783a97c5d5d tools/pygrub/Makefile
--- a/tools/pygrub/Makefile	Thu Apr 26 15:09:35 2012 +0100
+++ b/tools/pygrub/Makefile	Thu Apr 26 15:23:56 2012 +0100
@@ -11,9 +11,11 @@ build:
 .PHONY: install
 install: all
 	CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \
-		$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force
-	$(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(BINDIR)/pygrub
+		$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
+		--install-scripts=$(DESTDIR)/$(PRIVATE_BINDIR) --force
+	$(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub
 	$(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot
+	ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR)
 
 .PHONY: clean
 clean:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPhg-0002dE-9q; Thu, 26 Apr 2012 14:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPhf-0002d5-7Q
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:29:51 +0000
Received: from [85.158.143.99:55523] by server-1.bemta-4.messagelabs.com id
	0A/93-20925-EDB599F4; Thu, 26 Apr 2012 14:29:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335450588!24844637!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28368 invoked from network); 26 Apr 2012 14:29:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:29:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="24572632"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-Ni;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2783a97c5d5de4ac7b36883646c4183cab33b3ba
Message-ID: <2783a97c5d5de4ac7b36.1335450373@kodo2>
In-Reply-To: <patchbomb.1335450371@kodo2>
References: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:13 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] tools: Install pv bootloaders in libexec
 rather than /usr/bin
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pygrub and xenpvnetboot are meant to be run by tools, and not by the user,
and thus should be in /usr/lib/xen/bin rather than /usr/bin.

Because most config files will still have an absolute path pointing to
/usr/bin/pygrub, make a symbolic link that we will deprecate.

diff -r b810908dea7d -r 2783a97c5d5d tools/misc/Makefile
--- a/tools/misc/Makefile	Thu Apr 26 15:09:35 2012 +0100
+++ b/tools/misc/Makefile	Thu Apr 26 15:23:56 2012 +0100
@@ -18,7 +18,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount
 SUBDIRS-$(CONFIG_MINITERM) += miniterm
 SUBDIRS := $(SUBDIRS-y)
 
-INSTALL_BIN-y := xencons xenpvnetboot
+INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
@@ -27,6 +27,9 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
 
+INSTALL_PRIVBIN-y := xenpvnetboot
+INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y)
+
 # Include configure output (config.h) to headers search path
 CFLAGS += -I$(XEN_ROOT)/tools
 
@@ -41,8 +44,10 @@ build: $(TARGETS)
 install: build
 	$(INSTALL_DIR) $(DESTDIR)$(BINDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PYTHON_PROG) $(INSTALL_BIN) $(DESTDIR)$(BINDIR)
 	$(INSTALL_PYTHON_PROG) $(INSTALL_SBIN) $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PYTHON_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(PRIVATE_BINDIR)
 	set -e; for d in $(SUBDIRS); do $(MAKE) -C $$d install-recurse; done
 
 .PHONY: clean
diff -r b810908dea7d -r 2783a97c5d5d tools/pygrub/Makefile
--- a/tools/pygrub/Makefile	Thu Apr 26 15:09:35 2012 +0100
+++ b/tools/pygrub/Makefile	Thu Apr 26 15:23:56 2012 +0100
@@ -11,9 +11,11 @@ build:
 .PHONY: install
 install: all
 	CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \
-		$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force
-	$(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(BINDIR)/pygrub
+		$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
+		--install-scripts=$(DESTDIR)/$(PRIVATE_BINDIR) --force
+	$(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub
 	$(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot
+	ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR)
 
 .PHONY: clean
 clean:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPhg-0002dK-L7; Thu, 26 Apr 2012 14:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPhf-0002d5-NM
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:29:51 +0000
Received: from [85.158.143.99:55571] by server-1.bemta-4.messagelabs.com id
	7E/93-20925-FDB599F4; Thu, 26 Apr 2012 14:29:51 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335450588!24844637!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28394 invoked from network); 26 Apr 2012 14:29:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="24572633"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-OX;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: 1e09187be21dc9e7e6aab4b5b7b4605b25ec1954
Message-ID: <1e09187be21dc9e7e6aa.1335450374@kodo2>
In-Reply-To: <patchbomb.1335450371@kodo2>
References: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:14 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] libxl: Warn that /usr/bin/pygrub is
	deprecated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 2783a97c5d5d -r 1e09187be21d tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Apr 26 15:23:56 2012 +0100
+++ b/tools/libxl/libxl_bootloader.c	Thu Apr 26 15:23:56 2012 +0100
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <string.h>
 
 #include "libxl_internal.h"
 
@@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
+    if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) )
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
+                   "WARNING: bootloader='/usr/bin/pygrub' "             \
+                   "is deprecated; use bootloader='pygrub' instead");
+    
     bootloader = libxl__abs_path(gc, info->u.pv.bootloader,
                                  libxl__libexec_path());
     if ( bootloader == NULL ) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPhg-0002dK-L7; Thu, 26 Apr 2012 14:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPhf-0002d5-NM
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:29:51 +0000
Received: from [85.158.143.99:55571] by server-1.bemta-4.messagelabs.com id
	7E/93-20925-FDB599F4; Thu, 26 Apr 2012 14:29:51 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335450588!24844637!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMzk4NzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28394 invoked from network); 26 Apr 2012 14:29:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="24572633"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-OX;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: 1e09187be21dc9e7e6aab4b5b7b4605b25ec1954
Message-ID: <1e09187be21dc9e7e6aa.1335450374@kodo2>
In-Reply-To: <patchbomb.1335450371@kodo2>
References: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:14 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] libxl: Warn that /usr/bin/pygrub is
	deprecated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 2783a97c5d5d -r 1e09187be21d tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Apr 26 15:23:56 2012 +0100
+++ b/tools/libxl/libxl_bootloader.c	Thu Apr 26 15:23:56 2012 +0100
@@ -15,6 +15,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#include <string.h>
 
 #include "libxl_internal.h"
 
@@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
+    if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) )
+        LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
+                   "WARNING: bootloader='/usr/bin/pygrub' "             \
+                   "is deprecated; use bootloader='pygrub' instead");
+    
     bootloader = libxl__abs_path(gc, info->u.pv.bootloader,
                                  libxl__libexec_path());
     if ( bootloader == NULL ) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPiH-0002hC-F1; Thu, 26 Apr 2012 14:30:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPiF-0002gi-Bv
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:30:27 +0000
Received: from [193.109.254.147:54590] by server-12.bemta-14.messagelabs.com
	id C0/6E-05898-20C599F4; Thu, 26 Apr 2012 14:30:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335450608!6467619!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29082 invoked from network); 26 Apr 2012 14:30:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:30:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192208153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-NG;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: b810908dea7d328aa88c9d6399b96bfd906e5cca
Message-ID: <b810908dea7d328aa88c.1335450372@kodo2>
In-Reply-To: <patchbomb.1335450371@kodo2>
References: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] libxl: Look for bootloader in libexec
	path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the full path for a bootloader (such as pygrub or xenpvnetboot) is not
given, look for it in the libexec path.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r b4cbf273b1cb -r b810908dea7d tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Apr 26 15:09:35 2012 +0100
@@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
+    const char *bootloader = NULL;
 
     char *dom_console_xs_path;
     char dom_console_slave_tty_path[PATH_MAX];
@@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
+    bootloader = libxl__abs_path(gc, info->u.pv.bootloader,
+                                 libxl__libexec_path());
+    if ( bootloader == NULL ) {
+        rc = ERROR_NOMEM;
+        goto out_close;
+    }
+
     /*
      * We need to present the bootloader's tty as a pty slave that xenconsole
      * can access.  Since the bootloader itself needs a pty slave,
@@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
     libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
+    pid = fork_exec_bootloader(&bootloader_fd, bootloader, args);
     if (pid < 0) {
         goto out_close;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPiH-0002hC-F1; Thu, 26 Apr 2012 14:30:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPiF-0002gi-Bv
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:30:27 +0000
Received: from [193.109.254.147:54590] by server-12.bemta-14.messagelabs.com
	id C0/6E-05898-20C599F4; Thu, 26 Apr 2012 14:30:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335450608!6467619!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29082 invoked from network); 26 Apr 2012 14:30:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:30:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192208153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-NG;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: b810908dea7d328aa88c9d6399b96bfd906e5cca
Message-ID: <b810908dea7d328aa88c.1335450372@kodo2>
In-Reply-To: <patchbomb.1335450371@kodo2>
References: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] libxl: Look for bootloader in libexec
	path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the full path for a bootloader (such as pygrub or xenpvnetboot) is not
given, look for it in the libexec path.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r b4cbf273b1cb -r b810908dea7d tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Wed Feb 29 16:30:34 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Apr 26 15:09:35 2012 +0100
@@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
+    const char *bootloader = NULL;
 
     char *dom_console_xs_path;
     char dom_console_slave_tty_path[PATH_MAX];
@@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
+    bootloader = libxl__abs_path(gc, info->u.pv.bootloader,
+                                 libxl__libexec_path());
+    if ( bootloader == NULL ) {
+        rc = ERROR_NOMEM;
+        goto out_close;
+    }
+
     /*
      * We need to present the bootloader's tty as a pty slave that xenconsole
      * can access.  Since the bootloader itself needs a pty slave,
@@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
     libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
 
-    pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
+    pid = fork_exec_bootloader(&bootloader_fd, bootloader, args);
     if (pid < 0) {
         goto out_close;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPiG-0002h2-2J; Thu, 26 Apr 2012 14:30:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPiE-0002gi-VU
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:30:27 +0000
Received: from [193.109.254.147:54562] by server-12.bemta-14.messagelabs.com
	id 7F/5E-05898-20C599F4; Thu, 26 Apr 2012 14:30:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335450608!6467619!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29202 invoked from network); 26 Apr 2012 14:30:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192208151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-Mk;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:11 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] tools: Move bootloaders to libexec
	directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pygrub and xenpvnetboot are meant to be run by tools, and not by the user,
and thus should be in /usr/lib/xen/bin rather than /usr/bin.  This patch 
series:
* Causes libxl to look in the libexec dir if a full path is not specified
* Moves pygrub and xenpvnetboot into the libexec dir
* For compatibility with existing configs, puts a link to pygrub in /usr/bin
* Warns the user that /usr/bin/pygrub is deprecated

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:30:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNPiG-0002h2-2J; Thu, 26 Apr 2012 14:30:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNPiE-0002gi-VU
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 14:30:27 +0000
Received: from [193.109.254.147:54562] by server-12.bemta-14.messagelabs.com
	id 7F/5E-05898-20C599F4; Thu, 26 Apr 2012 14:30:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335450608!6467619!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29202 invoked from network); 26 Apr 2012 14:30:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192208151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:29:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 10:29:47 -0400
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNPha-0000SF-Mk;
	Thu, 26 Apr 2012 15:29:46 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1335450371@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 26 Apr 2012 15:26:11 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] tools: Move bootloaders to libexec
	directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

pygrub and xenpvnetboot are meant to be run by tools, and not by the user,
and thus should be in /usr/lib/xen/bin rather than /usr/bin.  This patch 
series:
* Causes libxl to look in the libexec dir if a full path is not specified
* Moves pygrub and xenpvnetboot into the libexec dir
* For compatibility with existing configs, puts a link to pygrub in /usr/bin
* Warns the user that /usr/bin/pygrub is deprecated

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:54:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQ4y-0003Gh-PQ; Thu, 26 Apr 2012 14:53:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SNQ4x-0003Gc-I3
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:53:55 +0000
Received: from [85.158.143.99:31441] by server-2.bemta-4.messagelabs.com id
	CA/AD-17550-281699F4; Thu, 26 Apr 2012 14:53:54 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335452032!25393218!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12911 invoked from network); 26 Apr 2012 14:53:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192214541"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:53:52 -0400
Received: from [10.80.3.206] (10.80.3.206) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012
	10:53:52 -0400
Message-ID: <4F99617F.8000002@citrix.com>
Date: Thu, 26 Apr 2012 15:53:51 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/12 17:30, Ian Campbell wrote:
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
>
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>
> Ian.
Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be 
backported to 4.0 and 4.1?

Thanks,

Malcolm

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 14:54:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 14:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQ4y-0003Gh-PQ; Thu, 26 Apr 2012 14:53:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1SNQ4x-0003Gc-I3
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 14:53:55 +0000
Received: from [85.158.143.99:31441] by server-2.bemta-4.messagelabs.com id
	CA/AD-17550-281699F4; Thu, 26 Apr 2012 14:53:54 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335452032!25393218!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12911 invoked from network); 26 Apr 2012 14:53:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 14:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="192214541"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 10:53:52 -0400
Received: from [10.80.3.206] (10.80.3.206) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012
	10:53:52 -0400
Message-ID: <4F99617F.8000002@citrix.com>
Date: Thu, 26 Apr 2012 15:53:51 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/04/12 17:30, Ian Campbell wrote:
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
>
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>
> Ian.
Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be 
backported to 4.0 and 4.1?

Thanks,

Malcolm

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:17:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQRV-0003nb-L8; Thu, 26 Apr 2012 15:17:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qi.zhezhi@gmail.com>) id 1SNQRU-0003nV-1Z
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 15:17:12 +0000
Received: from [85.158.143.35:6066] by server-2.bemta-4.messagelabs.com id
	0D/7E-17550-7F6699F4; Thu, 26 Apr 2012 15:17:11 +0000
X-Env-Sender: qi.zhezhi@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335453428!6701647!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12958 invoked from network); 26 Apr 2012 15:17:09 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 15:17:09 -0000
Received: by yenr5 with SMTP id r5so1164288yen.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 08:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=fP4k13KKO8hkl5f7uJNWDrAy2f6XNTvIgoz6CkBk9Vg=;
	b=piARbf0e0G+uHl0OyQKwkuz7OAivTWBdSet4tekFXIhjH/1zL3ZqFtZ04TMYxDBDEa
	oZV/wwwDShZNSsKnAp04mXvhjXTZm3JVeWN9aBhzJmrXCyLxSpB9Xru3ys27op9TKND7
	ZeGjEiTRNdaatsL/R4JV8QFDT4QBp8Z1sRcfokTYWA2XhkqHad75zkRPY88blH1J5Yw8
	0OBwHM54PTBauRNh/fIZwEjDrskWJB7tH+eE1C46rdHswBu0inPhK9E+YTJpsc3YMvUG
	QFVn4+9HbRQFe4sME5e9Ts/Oc1GR74CnRqA2p82SXplYPMg6qgrBNr4D20Wu/QobrlyT
	oOeQ==
MIME-Version: 1.0
Received: by 10.50.88.165 with SMTP id bh5mr5676860igb.10.1335453427683; Thu,
	26 Apr 2012 08:17:07 -0700 (PDT)
Received: by 10.43.126.9 with HTTP; Thu, 26 Apr 2012 08:17:07 -0700 (PDT)
Date: Thu, 26 Apr 2012 23:17:07 +0800
Message-ID: <CAPL=jHe94J38Zp2p3fjKGSbfD1uB_P-bE69O6oXxXa57XF6Ohg@mail.gmail.com>
From: =?GB2312?B?xuvV3Nau?= <qi.zhezhi@gmail.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] Xen bonding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2109509915122025990=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2109509915122025990==
Content-Type: multipart/alternative; boundary=e89a8f3ba1592bd05104be967b8f

--e89a8f3ba1592bd05104be967b8f
Content-Type: text/plain; charset=ISO-8859-1

*Hi all,
I'm not quiet sure the most reasonable way to dealing with bonding on
xenserver.
My configuration is as follow.
It was ok if i do nothing, but When I tried to 'service network restart',
the bond is break.
Then, /proc/net/bonding/pbond:
Slave Interface: eth0 eth1  was  down
bonding MII status: down

My questions are:
how to deal with this situation?
how to avoid the bond breading when 'service network restart'
what's the most standard way to make bond on xenserver(phy)?

#XEN
setting==============================================================Begin
/bin/cat > /etc/xen/xend-config.sxp << "EOF"
(xend-unix-server yes)
(xend-unix-path /var/lib/xend/xend-socket)
(xend-relocation-hosts-allow ' ')
(network-script 'network-bridge-bonding netdev=bond0')
(vif-script vif-bridge)
(dom0-cpus 2)
(keymap 'en-us')
EOF
#XEN
setting==============================================================End

#Network interface
bonding================================================Begin
cat > /etc/sysconfig/network-scripts/ifcfg-eth0 << "EOF"
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=yes
EOF

cat > /etc/sysconfig/network-scripts/ifcfg-eth1 << "EOF"
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=yes
EOF

# Network Bonding
cat > /etc/sysconfig/network-scripts/ifcfg-bond0 << "EOF"
DEVICE=bond0
BOOTPROTO=static
BROADCAST=1.1.1.1
IPADDR=1.1.1.1
NETMASK=255.255.255.255
GATEWAY=1.1.1.1
ONBOOT=yes
TYPE=Ethernet
EOF

cat >> /etc/modprobe.conf << "EOF"
alias bond0 bonding
options bond0 miimon=100 mode=6
EOF
#Network interface
bonding================================================End

Thank you all
Best Regards,
Jasonqi

*

--e89a8f3ba1592bd05104be967b8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<b>Hi all,<br>I&#39;m not quiet sure the most reasonable way to dealing wit=
h bonding on xenserver.<br>My configuration is as follow.<br>It was ok if i=
 do nothing, but When I tried to &#39;service network restart&#39;, the bon=
d is break.<br>
Then, /proc/net/bonding/pbond:<br>Slave Interface: eth0 eth1=A0 was=A0 down=
<br>bonding MII status: down<br><br><span style=3D"color:rgb(255,0,0)">My q=
uestions are:</span><br>how to deal with this situation?<br>how to avoid th=
e bond breading when &#39;service network restart&#39;<br>
what&#39;s the most standard way to make bond on xenserver(phy)?<br><br>#XE=
N setting=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DBegin<br>/bin/cat &gt; /etc/xe=
n/xend-config.sxp &lt;&lt; &quot;EOF&quot;<br>
(xend-unix-server yes)<br>(xend-unix-path /var/lib/xend/xend-socket)<br>(xe=
nd-relocation-hosts-allow &#39; &#39;)<br>(network-script &#39;network-brid=
ge-bonding netdev=3Dbond0&#39;)<br>(vif-script vif-bridge)<br>(dom0-cpus 2)=
<br>
(keymap &#39;en-us&#39;)<br>EOF<br>#XEN setting=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3DEnd<br><br>#Network interface bonding=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DBegin<br>cat &gt; /etc/sysconfig/=
network-scripts/ifcfg-eth0 &lt;&lt; &quot;EOF&quot;<br>
DEVICE=3Deth0<br>BOOTPROTO=3Dnone<br>ONBOOT=3Dyes<br>MASTER=3Dbond0<br>SLAV=
E=3Dyes<br>USERCTL=3Dyes<br>EOF<br><br>cat &gt; /etc/sysconfig/network-scri=
pts/ifcfg-eth1 &lt;&lt; &quot;EOF&quot;<br>DEVICE=3Deth1<br>BOOTPROTO=3Dnon=
e<br>ONBOOT=3Dyes<br>
MASTER=3Dbond0<br>SLAVE=3Dyes<br>USERCTL=3Dyes<br>EOF<br><br># Network Bond=
ing<br>cat &gt; /etc/sysconfig/network-scripts/ifcfg-bond0 &lt;&lt; &quot;E=
OF&quot;<br>DEVICE=3Dbond0<br>BOOTPROTO=3Dstatic<br>BROADCAST=3D1.1.1.1<br>=
IPADDR=3D1.1.1.1<br>
NETMASK=3D255.255.255.255<br>GATEWAY=3D1.1.1.1<br>ONBOOT=3Dyes<br>TYPE=3DEt=
hernet<br>EOF<br><br>cat &gt;&gt; /etc/modprobe.conf &lt;&lt; &quot;EOF&quo=
t;<br>alias bond0 bonding<br>options bond0 miimon=3D100 mode=3D6<br>EOF<br>=
#Network interface bonding=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3DEnd<br>
<br>Thank you all <br>Best Regards,<br>Jasonqi<br><br></b><br>

--e89a8f3ba1592bd05104be967b8f--


--===============2109509915122025990==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2109509915122025990==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 15:17:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQRV-0003nb-L8; Thu, 26 Apr 2012 15:17:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qi.zhezhi@gmail.com>) id 1SNQRU-0003nV-1Z
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 15:17:12 +0000
Received: from [85.158.143.35:6066] by server-2.bemta-4.messagelabs.com id
	0D/7E-17550-7F6699F4; Thu, 26 Apr 2012 15:17:11 +0000
X-Env-Sender: qi.zhezhi@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335453428!6701647!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12958 invoked from network); 26 Apr 2012 15:17:09 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 15:17:09 -0000
Received: by yenr5 with SMTP id r5so1164288yen.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 08:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=fP4k13KKO8hkl5f7uJNWDrAy2f6XNTvIgoz6CkBk9Vg=;
	b=piARbf0e0G+uHl0OyQKwkuz7OAivTWBdSet4tekFXIhjH/1zL3ZqFtZ04TMYxDBDEa
	oZV/wwwDShZNSsKnAp04mXvhjXTZm3JVeWN9aBhzJmrXCyLxSpB9Xru3ys27op9TKND7
	ZeGjEiTRNdaatsL/R4JV8QFDT4QBp8Z1sRcfokTYWA2XhkqHad75zkRPY88blH1J5Yw8
	0OBwHM54PTBauRNh/fIZwEjDrskWJB7tH+eE1C46rdHswBu0inPhK9E+YTJpsc3YMvUG
	QFVn4+9HbRQFe4sME5e9Ts/Oc1GR74CnRqA2p82SXplYPMg6qgrBNr4D20Wu/QobrlyT
	oOeQ==
MIME-Version: 1.0
Received: by 10.50.88.165 with SMTP id bh5mr5676860igb.10.1335453427683; Thu,
	26 Apr 2012 08:17:07 -0700 (PDT)
Received: by 10.43.126.9 with HTTP; Thu, 26 Apr 2012 08:17:07 -0700 (PDT)
Date: Thu, 26 Apr 2012 23:17:07 +0800
Message-ID: <CAPL=jHe94J38Zp2p3fjKGSbfD1uB_P-bE69O6oXxXa57XF6Ohg@mail.gmail.com>
From: =?GB2312?B?xuvV3Nau?= <qi.zhezhi@gmail.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] Xen bonding
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2109509915122025990=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2109509915122025990==
Content-Type: multipart/alternative; boundary=e89a8f3ba1592bd05104be967b8f

--e89a8f3ba1592bd05104be967b8f
Content-Type: text/plain; charset=ISO-8859-1

*Hi all,
I'm not quiet sure the most reasonable way to dealing with bonding on
xenserver.
My configuration is as follow.
It was ok if i do nothing, but When I tried to 'service network restart',
the bond is break.
Then, /proc/net/bonding/pbond:
Slave Interface: eth0 eth1  was  down
bonding MII status: down

My questions are:
how to deal with this situation?
how to avoid the bond breading when 'service network restart'
what's the most standard way to make bond on xenserver(phy)?

#XEN
setting==============================================================Begin
/bin/cat > /etc/xen/xend-config.sxp << "EOF"
(xend-unix-server yes)
(xend-unix-path /var/lib/xend/xend-socket)
(xend-relocation-hosts-allow ' ')
(network-script 'network-bridge-bonding netdev=bond0')
(vif-script vif-bridge)
(dom0-cpus 2)
(keymap 'en-us')
EOF
#XEN
setting==============================================================End

#Network interface
bonding================================================Begin
cat > /etc/sysconfig/network-scripts/ifcfg-eth0 << "EOF"
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=yes
EOF

cat > /etc/sysconfig/network-scripts/ifcfg-eth1 << "EOF"
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=yes
EOF

# Network Bonding
cat > /etc/sysconfig/network-scripts/ifcfg-bond0 << "EOF"
DEVICE=bond0
BOOTPROTO=static
BROADCAST=1.1.1.1
IPADDR=1.1.1.1
NETMASK=255.255.255.255
GATEWAY=1.1.1.1
ONBOOT=yes
TYPE=Ethernet
EOF

cat >> /etc/modprobe.conf << "EOF"
alias bond0 bonding
options bond0 miimon=100 mode=6
EOF
#Network interface
bonding================================================End

Thank you all
Best Regards,
Jasonqi

*

--e89a8f3ba1592bd05104be967b8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<b>Hi all,<br>I&#39;m not quiet sure the most reasonable way to dealing wit=
h bonding on xenserver.<br>My configuration is as follow.<br>It was ok if i=
 do nothing, but When I tried to &#39;service network restart&#39;, the bon=
d is break.<br>
Then, /proc/net/bonding/pbond:<br>Slave Interface: eth0 eth1=A0 was=A0 down=
<br>bonding MII status: down<br><br><span style=3D"color:rgb(255,0,0)">My q=
uestions are:</span><br>how to deal with this situation?<br>how to avoid th=
e bond breading when &#39;service network restart&#39;<br>
what&#39;s the most standard way to make bond on xenserver(phy)?<br><br>#XE=
N setting=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DBegin<br>/bin/cat &gt; /etc/xe=
n/xend-config.sxp &lt;&lt; &quot;EOF&quot;<br>
(xend-unix-server yes)<br>(xend-unix-path /var/lib/xend/xend-socket)<br>(xe=
nd-relocation-hosts-allow &#39; &#39;)<br>(network-script &#39;network-brid=
ge-bonding netdev=3Dbond0&#39;)<br>(vif-script vif-bridge)<br>(dom0-cpus 2)=
<br>
(keymap &#39;en-us&#39;)<br>EOF<br>#XEN setting=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3DEnd<br><br>#Network interface bonding=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DBegin<br>cat &gt; /etc/sysconfig/=
network-scripts/ifcfg-eth0 &lt;&lt; &quot;EOF&quot;<br>
DEVICE=3Deth0<br>BOOTPROTO=3Dnone<br>ONBOOT=3Dyes<br>MASTER=3Dbond0<br>SLAV=
E=3Dyes<br>USERCTL=3Dyes<br>EOF<br><br>cat &gt; /etc/sysconfig/network-scri=
pts/ifcfg-eth1 &lt;&lt; &quot;EOF&quot;<br>DEVICE=3Deth1<br>BOOTPROTO=3Dnon=
e<br>ONBOOT=3Dyes<br>
MASTER=3Dbond0<br>SLAVE=3Dyes<br>USERCTL=3Dyes<br>EOF<br><br># Network Bond=
ing<br>cat &gt; /etc/sysconfig/network-scripts/ifcfg-bond0 &lt;&lt; &quot;E=
OF&quot;<br>DEVICE=3Dbond0<br>BOOTPROTO=3Dstatic<br>BROADCAST=3D1.1.1.1<br>=
IPADDR=3D1.1.1.1<br>
NETMASK=3D255.255.255.255<br>GATEWAY=3D1.1.1.1<br>ONBOOT=3Dyes<br>TYPE=3DEt=
hernet<br>EOF<br><br>cat &gt;&gt; /etc/modprobe.conf &lt;&lt; &quot;EOF&quo=
t;<br>alias bond0 bonding<br>options bond0 miimon=3D100 mode=3D6<br>EOF<br>=
#Network interface bonding=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3DEnd<br>
<br>Thank you all <br>Best Regards,<br>Jasonqi<br><br></b><br>

--e89a8f3ba1592bd05104be967b8f--


--===============2109509915122025990==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2109509915122025990==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQY3-00041j-M8; Thu, 26 Apr 2012 15:23:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNQY2-00041d-As
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:23:58 +0000
Received: from [193.109.254.147:20923] by server-11.bemta-14.messagelabs.com
	id 6E/28-05858-D88699F4; Thu, 26 Apr 2012 15:23:57 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335453835!6494672!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27850 invoked from network); 26 Apr 2012 15:23:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 15:23:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNQXz-0002Qu-9u
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:23:55 -0700
Date: Thu, 26 Apr 2012 08:23:55 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335453835300-5667919.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25249:a4e7fce6ee2b)
vi Makefile # removed dist-kernel to not compile kernel
-------------------------
vi Config.mk # qemu upstream unstable and seabios upstream unstable for
various spice and qxl bugfix
------------
QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
SEABIOS_UPSTREAM_TAG ?= rel-1.7.0
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb

Tested it on Windows XP domU with this xl configuration file:
-------------------------------
XP.cfg
--------- 
name='XP'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
#disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
boot='cd'
xen_platform_pci=1
viridian=1
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
#vnc=1
#vncunused=1
#vnclisten="0.0.0.0"
#keymap="it"
spice=1
spicehost="0.0.0.0"
spiceport=6000
spicedisable_ticketing=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
stdvga=1
#device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
#videoram=128
#device_model_args=["-vga qxl"]
-------------------------------
With stdvga option domU is working but graphic performance is poor with
spice.


With QXL vga option domU 
-------------------------------
videoram=128
device_model_args=["-vga qxl"]
stdvga=0
-------------------------------
DomU not start, from qemu log:
qemu-system-i386: -vga qxl: invalid option

But the option is correct and if I add:
device_model_override="/usr/lib/xen/bin/qemu-debug.sh"

qemu-debug.sh launches the same qemu-system-i386 with same options and domU
starts.
DomU sees the QXL vga but only with 4 mb allocated and/or usabled instead of
64 mb of qemu default.

We need domUs with good graphic performance, also with high resolution and
also multimedia.
We can not use gfx passthrough on our dom0s because of hardware limitation
of dell server.
QXL seems to be the only way to go.

We are testing this setup several months without success on xen.
Some initial xl and qemu ram/videoram bugs are now fixed but may be there
are other in xen not found for now.

We noticed one particular thing:

without qxl:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000

with qxl:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->0000000038000000
  ENTRY ADDRESS: 0000000000100000

The total memory with qxl should be equal or major than total memory without
qxl.
There is something wrong about videoram, i don't know if in xl or other part
of xen.

Please someone help me to solve this problem?

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5667919.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQY3-00041j-M8; Thu, 26 Apr 2012 15:23:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNQY2-00041d-As
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:23:58 +0000
Received: from [193.109.254.147:20923] by server-11.bemta-14.messagelabs.com
	id 6E/28-05858-D88699F4; Thu, 26 Apr 2012 15:23:57 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335453835!6494672!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27850 invoked from network); 26 Apr 2012 15:23:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 15:23:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNQXz-0002Qu-9u
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 08:23:55 -0700
Date: Thu, 26 Apr 2012 08:23:55 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335453835300-5667919.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25249:a4e7fce6ee2b)
vi Makefile # removed dist-kernel to not compile kernel
-------------------------
vi Config.mk # qemu upstream unstable and seabios upstream unstable for
various spice and qxl bugfix
------------
QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
SEABIOS_UPSTREAM_TAG ?= rel-1.7.0
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb

Tested it on Windows XP domU with this xl configuration file:
-------------------------------
XP.cfg
--------- 
name='XP'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
#disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
boot='cd'
xen_platform_pci=1
viridian=1
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
#vnc=1
#vncunused=1
#vnclisten="0.0.0.0"
#keymap="it"
spice=1
spicehost="0.0.0.0"
spiceport=6000
spicedisable_ticketing=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
stdvga=1
#device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
#videoram=128
#device_model_args=["-vga qxl"]
-------------------------------
With stdvga option domU is working but graphic performance is poor with
spice.


With QXL vga option domU 
-------------------------------
videoram=128
device_model_args=["-vga qxl"]
stdvga=0
-------------------------------
DomU not start, from qemu log:
qemu-system-i386: -vga qxl: invalid option

But the option is correct and if I add:
device_model_override="/usr/lib/xen/bin/qemu-debug.sh"

qemu-debug.sh launches the same qemu-system-i386 with same options and domU
starts.
DomU sees the QXL vga but only with 4 mb allocated and/or usabled instead of
64 mb of qemu default.

We need domUs with good graphic performance, also with high resolution and
also multimedia.
We can not use gfx passthrough on our dom0s because of hardware limitation
of dell server.
QXL seems to be the only way to go.

We are testing this setup several months without success on xen.
Some initial xl and qemu ram/videoram bugs are now fixed but may be there
are other in xen not found for now.

We noticed one particular thing:

without qxl:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000

with qxl:
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->0000000038000000
  ENTRY ADDRESS: 0000000000100000

The total memory with qxl should be equal or major than total memory without
qxl.
There is something wrong about videoram, i don't know if in xl or other part
of xen.

Please someone help me to solve this problem?

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5667919.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:39:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQmx-0004CD-7Z; Thu, 26 Apr 2012 15:39:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNQmv-0004C8-Tt
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:39:22 +0000
Received: from [85.158.143.35:21144] by server-3.bemta-4.messagelabs.com id
	FF/15-05853-92C699F4; Thu, 26 Apr 2012 15:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335454759!8856011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25738 invoked from network); 26 Apr 2012 15:39:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 15:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12160767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 15:39:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 16:39:18 +0100
Message-ID: <1335454757.28015.160.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 16:39:17 +0100
In-Reply-To: <1335453835300-5667919.post@n5.nabble.com>
References: <1335453835300-5667919.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Zhou
	Peng <zhoupeng@nfs.iscas.ac.cn>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CCing Zhou Peng who originally added spice support to xl. Zhou, are you
interested in supporting this feature?

On Thu, 2012-04-26 at 16:23 +0100, Fantu wrote:
> Dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
> usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
> 25249:a4e7fce6ee2b)
> vi Makefile # removed dist-kernel to not compile kernel
> -------------------------
> vi Config.mk # qemu upstream unstable and seabios upstream unstable for
> various spice and qxl bugfix
> ------------
> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
> SEABIOS_UPSTREAM_TAG ?= rel-1.7.0
> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
> 
> Tested it on Windows XP domU with this xl configuration file:
> -------------------------------
> XP.cfg
> --------- 
> name='XP'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> #disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> boot='cd'
> xen_platform_pci=1
> viridian=1
> device_model_version="qemu-xen"
> #device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> #vnc=1
> #vncunused=1
> #vnclisten="0.0.0.0"
> #keymap="it"
> spice=1
> spicehost="0.0.0.0"
> spiceport=6000
> spicedisable_ticketing=1
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> stdvga=1
> #device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
> #videoram=128
> #device_model_args=["-vga qxl"]
> -------------------------------
> With stdvga option domU is working but graphic performance is poor with
> spice.
> 
> 
> With QXL vga option domU 
> -------------------------------
> videoram=128
> device_model_args=["-vga qxl"]
> stdvga=0
> -------------------------------
> DomU not start, from qemu log:
> qemu-system-i386: -vga qxl: invalid option
> 
> But the option is correct and if I add:
> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> 
> qemu-debug.sh launches the same qemu-system-i386 with same options and domU
> starts.
> DomU sees the QXL vga but only with 4 mb allocated and/or usabled instead of
> 64 mb of qemu default.
> 
> We need domUs with good graphic performance, also with high resolution and
> also multimedia.
> We can not use gfx passthrough on our dom0s because of hardware limitation
> of dell server.
> QXL seems to be the only way to go.
> 
> We are testing this setup several months without success on xen.
> Some initial xl and qemu ram/videoram bugs are now fixed but may be there
> are other in xen not found for now.
> 
> We noticed one particular thing:
> 
> without qxl:
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> 
> with qxl:
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->0000000038000000
>   ENTRY ADDRESS: 0000000000100000
> 
> The total memory with qxl should be equal or major than total memory without
> qxl.
> There is something wrong about videoram, i don't know if in xl or other part
> of xen.
> 
> Please someone help me to solve this problem?
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5667919.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:39:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQmx-0004CD-7Z; Thu, 26 Apr 2012 15:39:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNQmv-0004C8-Tt
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:39:22 +0000
Received: from [85.158.143.35:21144] by server-3.bemta-4.messagelabs.com id
	FF/15-05853-92C699F4; Thu, 26 Apr 2012 15:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335454759!8856011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25738 invoked from network); 26 Apr 2012 15:39:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 15:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12160767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 15:39:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 16:39:18 +0100
Message-ID: <1335454757.28015.160.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 26 Apr 2012 16:39:17 +0100
In-Reply-To: <1335453835300-5667919.post@n5.nabble.com>
References: <1335453835300-5667919.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Zhou
	Peng <zhoupeng@nfs.iscas.ac.cn>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CCing Zhou Peng who originally added spice support to xl. Zhou, are you
interested in supporting this feature?

On Thu, 2012-04-26 at 16:23 +0100, Fantu wrote:
> Dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
> usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
> 25249:a4e7fce6ee2b)
> vi Makefile # removed dist-kernel to not compile kernel
> -------------------------
> vi Config.mk # qemu upstream unstable and seabios upstream unstable for
> various spice and qxl bugfix
> ------------
> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
> SEABIOS_UPSTREAM_TAG ?= rel-1.7.0
> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
> 
> Tested it on Windows XP domU with this xl configuration file:
> -------------------------------
> XP.cfg
> --------- 
> name='XP'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> #disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
> boot='cd'
> xen_platform_pci=1
> viridian=1
> device_model_version="qemu-xen"
> #device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> #vnc=1
> #vncunused=1
> #vnclisten="0.0.0.0"
> #keymap="it"
> spice=1
> spicehost="0.0.0.0"
> spiceport=6000
> spicedisable_ticketing=1
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> stdvga=1
> #device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
> #videoram=128
> #device_model_args=["-vga qxl"]
> -------------------------------
> With stdvga option domU is working but graphic performance is poor with
> spice.
> 
> 
> With QXL vga option domU 
> -------------------------------
> videoram=128
> device_model_args=["-vga qxl"]
> stdvga=0
> -------------------------------
> DomU not start, from qemu log:
> qemu-system-i386: -vga qxl: invalid option
> 
> But the option is correct and if I add:
> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
> 
> qemu-debug.sh launches the same qemu-system-i386 with same options and domU
> starts.
> DomU sees the QXL vga but only with 4 mb allocated and/or usabled instead of
> 64 mb of qemu default.
> 
> We need domUs with good graphic performance, also with high resolution and
> also multimedia.
> We can not use gfx passthrough on our dom0s because of hardware limitation
> of dell server.
> QXL seems to be the only way to go.
> 
> We are testing this setup several months without success on xen.
> Some initial xl and qemu ram/videoram bugs are now fixed but may be there
> are other in xen not found for now.
> 
> We noticed one particular thing:
> 
> without qxl:
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> 
> with qxl:
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->0000000038000000
>   ENTRY ADDRESS: 0000000000100000
> 
> The total memory with qxl should be equal or major than total memory without
> qxl.
> There is something wrong about videoram, i don't know if in xl or other part
> of xen.
> 
> Please someone help me to solve this problem?
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5667919.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:39:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQnA-0004Ci-KD; Thu, 26 Apr 2012 15:39:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNQn8-0004CS-Tt
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:39:35 +0000
Received: from [85.158.143.35:21823] by server-1.bemta-4.messagelabs.com id
	D7/63-20925-63C699F4; Thu, 26 Apr 2012 15:39:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335454771!6704452!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7640 invoked from network); 26 Apr 2012 15:39:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 15:39:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QFdNPt026482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 15:39:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QFdM1k019957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 15:39:22 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QFdKsS023398; Thu, 26 Apr 2012 10:39:20 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 08:39:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 517E44031D; Thu, 26 Apr 2012 11:33:46 -0400 (EDT)
Date: Thu, 26 Apr 2012 11:33:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120426153346.GC26830@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
	<CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
	<20120424162321.GH3213@phenom.dumpdata.com>
	<CAF1ivSYFp7duSCNb+_5teM83icx1O-rY0YVFm7Laq_JLZuzerw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSYFp7duSCNb+_5teM83icx1O-rY0YVFm7Laq_JLZuzerw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >>
> >> unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> >> {
> >> =A0 =A0 =A0 =A0 struct physdev_apic apic_op;
> >> =A0 =A0 =A0 =A0 int ret;
> >>
> >> =A0 =A0 =A0 =A0 apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
> >> =A0 =A0 =A0 =A0 apic_op.reg =3D reg;
> >> =A0 =A0 =A0 =A0 ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &ap=
ic_op);
> >> =A0 =A0 =A0 =A0 if (!ret)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic_op.value;
> >>
> >> =A0 =A0 =A0 =A0 /* emulate register */
> >> =A0 =A0 =A0 =A0 if (reg =3D=3D 0x1)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
> >> =A0 =A0 =A0 =A0 else if (reg =3D=3D 0x0)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
> >> =A0 =A0 =A0 =A0 else
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
> >
> > =A0 =A0 =A0 =A0return 0xfd;
> =

> Where does this magic number 0xfd come from?
> =

> Both native_io_apic_read and xen_io_apic_read does not return 0xfd on err=
or.

That is correct. But that is what it should have been. Suresh
pointed that out sometime and I managed to lose that part in one of the
commits. The earlier patch of this version did that.

Thought thinking about it this some I am not sure if 0xff is a better
choice... In the end it probably does not matter the slighest.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:39:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQnA-0004Ci-KD; Thu, 26 Apr 2012 15:39:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNQn8-0004CS-Tt
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:39:35 +0000
Received: from [85.158.143.35:21823] by server-1.bemta-4.messagelabs.com id
	D7/63-20925-63C699F4; Thu, 26 Apr 2012 15:39:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335454771!6704452!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7640 invoked from network); 26 Apr 2012 15:39:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 15:39:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QFdNPt026482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 15:39:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QFdM1k019957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 15:39:22 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QFdKsS023398; Thu, 26 Apr 2012 10:39:20 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 08:39:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 517E44031D; Thu, 26 Apr 2012 11:33:46 -0400 (EDT)
Date: Thu, 26 Apr 2012 11:33:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Lin Ming <mlin@ss.pku.edu.cn>
Message-ID: <20120426153346.GC26830@phenom.dumpdata.com>
References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com>
	<1334920396.2863.16.camel@hp6530s>
	<1334925508.28331.63.camel@zakaz.uk.xensource.com>
	<20120420164150.GC31062@phenom.dumpdata.com>
	<CAF1ivSamaYzQDwjFqRGrnQ+fCr0D4vLGuG4JRBZ3_GD_y8yY=A@mail.gmail.com>
	<20120423151123.GC24481@phenom.dumpdata.com>
	<CAF1ivSY1GAkqU2gN0P22Tb0pmwagam5UUVMABSgnoH3+C+TY+A@mail.gmail.com>
	<20120424162321.GH3213@phenom.dumpdata.com>
	<CAF1ivSYFp7duSCNb+_5teM83icx1O-rY0YVFm7Laq_JLZuzerw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1ivSYFp7duSCNb+_5teM83icx1O-rY0YVFm7Laq_JLZuzerw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/apic: implement io apic read with
 hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >>
> >> unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
> >> {
> >> =A0 =A0 =A0 =A0 struct physdev_apic apic_op;
> >> =A0 =A0 =A0 =A0 int ret;
> >>
> >> =A0 =A0 =A0 =A0 apic_op.apic_physbase =3D mpc_ioapic_addr(apic);
> >> =A0 =A0 =A0 =A0 apic_op.reg =3D reg;
> >> =A0 =A0 =A0 =A0 ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &ap=
ic_op);
> >> =A0 =A0 =A0 =A0 if (!ret)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic_op.value;
> >>
> >> =A0 =A0 =A0 =A0 /* emulate register */
> >> =A0 =A0 =A0 =A0 if (reg =3D=3D 0x1)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020;
> >> =A0 =A0 =A0 =A0 else if (reg =3D=3D 0x0)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24;
> >> =A0 =A0 =A0 =A0 else
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
> >
> > =A0 =A0 =A0 =A0return 0xfd;
> =

> Where does this magic number 0xfd come from?
> =

> Both native_io_apic_read and xen_io_apic_read does not return 0xfd on err=
or.

That is correct. But that is what it should have been. Suresh
pointed that out sometime and I managed to lose that part in one of the
commits. The earlier patch of this version did that.

Thought thinking about it this some I am not sure if 0xff is a better
choice... In the end it probably does not matter the slighest.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:47:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQu9-0004VF-Gg; Thu, 26 Apr 2012 15:46:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNQu7-0004V7-Uv
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:46:48 +0000
Received: from [85.158.138.51:55200] by server-7.bemta-3.messagelabs.com id
	49/DA-03078-7ED699F4; Thu, 26 Apr 2012 15:46:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335455204!23932718!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4822 invoked from network); 26 Apr 2012 15:46:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 15:46:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QFkaTj007887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 15:46:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QFkZCh019119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 15:46:36 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QFkZtE006855; Thu, 26 Apr 2012 10:46:35 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 08:46:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 721EF4031D; Thu, 26 Apr 2012 11:41:01 -0400 (EDT)
Date: Thu, 26 Apr 2012 11:41:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Message-ID: <20120426154101.GD26830@phenom.dumpdata.com>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
	<alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
	<20120425112335.GA20868@lst.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120425112335.GA20868@lst.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 01:23:35PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote:
> > That is true, in fact I couldn't figure out what I had to implement just
> > reading the comment. So I went through the blkback code and tried to
> > understand what I had to do, but I got it wrong.
> > 
> > Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
> > is supposed to have the same semantics as REQ_FLUSH, that implies a
> > preflush if nr_segments > 0, not a postflush like I did.
> 
> It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA
> into BLKIF_OP_FLUSH_DISKCACHE.

I think that is what remained of the BARRIER request.
> 
> REQ_FLUSH either is a pre flush or a pure flush without a data transfer,
> and REQ_FUA is a post flush.  So to get the proper semantics you'll have
> to do both, _and_ sequence it so that no operation starts before the
> previous one finished.

If I were to emulate the SCSI SYNC command which one would it be?

I think REQ_FLUSH? In which I would think that the blkfront needs to
get rid of the REQ_FUA part?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:47:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNQu9-0004VF-Gg; Thu, 26 Apr 2012 15:46:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNQu7-0004V7-Uv
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:46:48 +0000
Received: from [85.158.138.51:55200] by server-7.bemta-3.messagelabs.com id
	49/DA-03078-7ED699F4; Thu, 26 Apr 2012 15:46:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335455204!23932718!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4822 invoked from network); 26 Apr 2012 15:46:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 15:46:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QFkaTj007887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 15:46:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QFkZCh019119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 15:46:36 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QFkZtE006855; Thu, 26 Apr 2012 10:46:35 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 08:46:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 721EF4031D; Thu, 26 Apr 2012 11:41:01 -0400 (EDT)
Date: Thu, 26 Apr 2012 11:41:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Message-ID: <20120426154101.GD26830@phenom.dumpdata.com>
References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120425084524.GA17537@lst.de>
	<1335344565.28015.7.camel@zakaz.uk.xensource.com>
	<20120425102024.GA19800@lst.de>
	<alpine.DEB.2.00.1204251213480.26786@kaball-desktop>
	<20120425112335.GA20868@lst.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120425112335.GA20868@lst.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement
 BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 01:23:35PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote:
> > That is true, in fact I couldn't figure out what I had to implement just
> > reading the comment. So I went through the blkback code and tried to
> > understand what I had to do, but I got it wrong.
> > 
> > Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE
> > is supposed to have the same semantics as REQ_FLUSH, that implies a
> > preflush if nr_segments > 0, not a postflush like I did.
> 
> It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA
> into BLKIF_OP_FLUSH_DISKCACHE.

I think that is what remained of the BARRIER request.
> 
> REQ_FLUSH either is a pre flush or a pure flush without a data transfer,
> and REQ_FUA is a post flush.  So to get the proper semantics you'll have
> to do both, _and_ sequence it so that no operation starts before the
> previous one finished.

If I were to emulate the SCSI SYNC command which one would it be?

I think REQ_FLUSH? In which I would think that the blkfront needs to
get rid of the REQ_FUA part?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNR3G-0004g8-H1; Thu, 26 Apr 2012 15:56:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNR3F-0004g3-Vf
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:56:14 +0000
Received: from [85.158.138.51:39344] by server-5.bemta-3.messagelabs.com id
	24/9E-17113-D10799F4; Thu, 26 Apr 2012 15:56:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335455771!23884414!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2778 invoked from network); 26 Apr 2012 15:56:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 15:56:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QFu8Fj015405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 15:56:09 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QFu73X021118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 15:56:07 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QFu733014489; Thu, 26 Apr 2012 10:56:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 08:56:06 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4726C4031D; Thu, 26 Apr 2012 11:50:33 -0400 (EDT)
Date: Thu, 26 Apr 2012 11:50:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120426155033.GE26830@phenom.dumpdata.com>
References: <4F97F58A.8090409@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F97F58A.8090409@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
> Since there have been requests about that driver to get backported into 3.2, I
> was interested to find out what or how much would be gained by that.
> 
> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which
> was not very successful as the drivers bail out of the init function because the
> first call to acpi_processor_register_performance() returns -ENODEV. There is
> some frequency scaling when running without Xen, so I need to do some more
> debugging there.

Did you back-port the other components - the ones that turn off the native
frequency scalling?

      provide disable_cpufreq() function to disable the API.
	xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
      xen/cpufreq: Disable the cpu frequency scaling drivers from loading
> 
> The second system was an Intel one (4 core i7 920@2.67GHz) which was
> successfully loading the driver. Via xenpm I can see the various frequencies and
> also see them being changed. However the cpuidle data out of xenpm looks a bit odd:
> 
> #> xenpm get-cpuidle-states 0
> Max C-state: C7
> 
> cpu id               : 0
> total C-states       : 2
> idle time(ms)        : 10819311
> C0                   : transition [00000000000000000001]
>                        residency  [00000000000000005398 ms]
> C1                   : transition [00000000000000000001]
>                        residency  [00000000000010819311 ms]
> pc3                  : [00000000000000000000 ms]
> pc6                  : [00000000000000000000 ms]
> pc7                  : [00000000000000000000 ms]
> cc3                  : [00000000000000000000 ms]
> cc6                  : [00000000000000000000 ms]
> 
> Also gathering samples over 30s does look like only C0 and C1 are used. This

Yes. 
> might be because C1E support is enabled in BIOS but when looking at the
> intel_idle data in sysfs when running without a hypervisor will show C3 and C6
> for the cores. That could have been just a wrong output, so I plugged in a power
> meter and compared a kernel running natively and running as dom0 (with and
> without the acpi-processor driver).
> 
> Native: 175W
> dom0:   183W (with only marginal difference between with or without the
>               processor driver)
> [yes, the system has a somewhat high base consumption which I attribute to a
> ridiculously dimensioned graphics subsystem to be running a text console]
> 
> This I would take as C3 and C6 really not being used and the frequency scaling

To go in deeper modes there is also a need to backport a Xen unstable
hypercall which will allow the kernel to detect the other states besides
C0-C2.

"XEN_SET_PDC query was implemented in c/s 23783:
    "ACPI: add _PDC input override mechanism".
    

> having no impact on the idle system is not that much surprising. But if that was
> true it would also limit the usefulness of the turbo mode which I understand
> would also be limited by the c-state of the other cores.

Hm, I should double-check that - but somehow I thought that Xen independetly
checks for TurboMode and if the P-states are in, then they are activated.

> 
> Do I misread the data I see? Or maybe its a known limitation? In case it is
> worth doing more research I'll gladly try things and gather more data.

Just missing some patches. 

Oh, and this one:
      xen/acpi: Fix Kconfig dependency on CPU_FREQ

Hmm.. I think a patch disappeared somewhere.

> 
> Thanks,
> Stefan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 15:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 15:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNR3G-0004g8-H1; Thu, 26 Apr 2012 15:56:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNR3F-0004g3-Vf
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:56:14 +0000
Received: from [85.158.138.51:39344] by server-5.bemta-3.messagelabs.com id
	24/9E-17113-D10799F4; Thu, 26 Apr 2012 15:56:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335455771!23884414!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2778 invoked from network); 26 Apr 2012 15:56:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 15:56:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QFu8Fj015405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 15:56:09 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QFu73X021118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 15:56:07 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QFu733014489; Thu, 26 Apr 2012 10:56:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 08:56:06 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4726C4031D; Thu, 26 Apr 2012 11:50:33 -0400 (EDT)
Date: Thu, 26 Apr 2012 11:50:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120426155033.GE26830@phenom.dumpdata.com>
References: <4F97F58A.8090409@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F97F58A.8090409@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor
	driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
> Since there have been requests about that driver to get backported into 3.2, I
> was interested to find out what or how much would be gained by that.
> 
> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which
> was not very successful as the drivers bail out of the init function because the
> first call to acpi_processor_register_performance() returns -ENODEV. There is
> some frequency scaling when running without Xen, so I need to do some more
> debugging there.

Did you back-port the other components - the ones that turn off the native
frequency scalling?

      provide disable_cpufreq() function to disable the API.
	xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
      xen/cpufreq: Disable the cpu frequency scaling drivers from loading
> 
> The second system was an Intel one (4 core i7 920@2.67GHz) which was
> successfully loading the driver. Via xenpm I can see the various frequencies and
> also see them being changed. However the cpuidle data out of xenpm looks a bit odd:
> 
> #> xenpm get-cpuidle-states 0
> Max C-state: C7
> 
> cpu id               : 0
> total C-states       : 2
> idle time(ms)        : 10819311
> C0                   : transition [00000000000000000001]
>                        residency  [00000000000000005398 ms]
> C1                   : transition [00000000000000000001]
>                        residency  [00000000000010819311 ms]
> pc3                  : [00000000000000000000 ms]
> pc6                  : [00000000000000000000 ms]
> pc7                  : [00000000000000000000 ms]
> cc3                  : [00000000000000000000 ms]
> cc6                  : [00000000000000000000 ms]
> 
> Also gathering samples over 30s does look like only C0 and C1 are used. This

Yes. 
> might be because C1E support is enabled in BIOS but when looking at the
> intel_idle data in sysfs when running without a hypervisor will show C3 and C6
> for the cores. That could have been just a wrong output, so I plugged in a power
> meter and compared a kernel running natively and running as dom0 (with and
> without the acpi-processor driver).
> 
> Native: 175W
> dom0:   183W (with only marginal difference between with or without the
>               processor driver)
> [yes, the system has a somewhat high base consumption which I attribute to a
> ridiculously dimensioned graphics subsystem to be running a text console]
> 
> This I would take as C3 and C6 really not being used and the frequency scaling

To go in deeper modes there is also a need to backport a Xen unstable
hypercall which will allow the kernel to detect the other states besides
C0-C2.

"XEN_SET_PDC query was implemented in c/s 23783:
    "ACPI: add _PDC input override mechanism".
    

> having no impact on the idle system is not that much surprising. But if that was
> true it would also limit the usefulness of the turbo mode which I understand
> would also be limited by the c-state of the other cores.

Hm, I should double-check that - but somehow I thought that Xen independetly
checks for TurboMode and if the P-states are in, then they are activated.

> 
> Do I misread the data I see? Or maybe its a known limitation? In case it is
> worth doing more research I'll gladly try things and gather more data.

Just missing some patches. 

Oh, and this one:
      xen/acpi: Fix Kconfig dependency on CPU_FREQ

Hmm.. I think a patch disappeared somewhere.

> 
> Thanks,
> Stefan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 16:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 16:26:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNRVd-0005Lp-6p; Thu, 26 Apr 2012 16:25:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SNRVc-0005Lk-H5
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 16:25:32 +0000
Received: from [85.158.143.35:49541] by server-3.bemta-4.messagelabs.com id
	2C/EC-05853-BF6799F4; Thu, 26 Apr 2012 16:25:31 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335457530!14101333!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6195 invoked from network); 26 Apr 2012 16:25:30 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-21.messagelabs.com with SMTP;
	26 Apr 2012 16:25:30 -0000
Received: from p5b2e39c2.dip.t-dialin.net ([91.46.57.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SNRVa-0001Bb-0J; Thu, 26 Apr 2012 16:25:30 +0000
Message-ID: <4F9976F8.8040502@canonical.com>
Date: Thu, 26 Apr 2012 18:25:28 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F97F58A.8090409@canonical.com>
	<20120426155033.GE26830@phenom.dumpdata.com>
In-Reply-To: <20120426155033.GE26830@phenom.dumpdata.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor
 driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7413593064046783372=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7413593064046783372==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigCEB2AD89CFDA2F503AE61094"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCEB2AD89CFDA2F503AE61094
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
>> Since there have been requests about that driver to get backported int=
o 3.2, I
>> was interested to find out what or how much would be gained by that.
>>
>> The first system I tried was an AMD based one (8 core Opteron 6128@2GH=
z). Which
>> was not very successful as the drivers bail out of the init function b=
ecause the
>> first call to acpi_processor_register_performance() returns -ENODEV. T=
here is
>> some frequency scaling when running without Xen, so I need to do some =
more
>> debugging there.
>=20
> Did you back-port the other components - the ones that turn off the nat=
ive
> frequency scalling?
>=20
>       provide disable_cpufreq() function to disable the API.
> 	xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
>       xen/cpufreq: Disable the cpu frequency scaling drivers from loadi=
ng
>>

Yes, here is the full set for reference:

* xen/cpufreq: Disable the cpu frequency scaling drivers from loading.
* xen/acpi: Remove the WARN's as they just create noise.
* xen/acpi: Fix Kconfig dependency on CPU_FREQ
* xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
* xen/acpi-processor: C and P-state driver that uploads said data to hype=
r
* provide disable_cpufreq() function to disable the API.

>> The second system was an Intel one (4 core i7 920@2.67GHz) which was
>> successfully loading the driver. Via xenpm I can see the various frequ=
encies and
>> also see them being changed. However the cpuidle data out of xenpm loo=
ks a bit odd:
>>
>> #> xenpm get-cpuidle-states 0
>> Max C-state: C7
>>
>> cpu id               : 0
>> total C-states       : 2
>> idle time(ms)        : 10819311
>> C0                   : transition [00000000000000000001]
>>                        residency  [00000000000000005398 ms]
>> C1                   : transition [00000000000000000001]
>>                        residency  [00000000000010819311 ms]
>> pc3                  : [00000000000000000000 ms]
>> pc6                  : [00000000000000000000 ms]
>> pc7                  : [00000000000000000000 ms]
>> cc3                  : [00000000000000000000 ms]
>> cc6                  : [00000000000000000000 ms]
>>
>> Also gathering samples over 30s does look like only C0 and C1 are used=
=2E This
>=20
> Yes.=20
>> might be because C1E support is enabled in BIOS but when looking at th=
e
>> intel_idle data in sysfs when running without a hypervisor will show C=
3 and C6
>> for the cores. That could have been just a wrong output, so I plugged =
in a power
>> meter and compared a kernel running natively and running as dom0 (with=
 and
>> without the acpi-processor driver).
>>
>> Native: 175W
>> dom0:   183W (with only marginal difference between with or without th=
e
>>               processor driver)
>> [yes, the system has a somewhat high base consumption which I attribut=
e to a
>> ridiculously dimensioned graphics subsystem to be running a text conso=
le]
>>
>> This I would take as C3 and C6 really not being used and the frequency=
 scaling
>=20
> To go in deeper modes there is also a need to backport a Xen unstable
> hypercall which will allow the kernel to detect the other states beside=
s
> C0-C2.
>=20
> "XEN_SET_PDC query was implemented in c/s 23783:
>     "ACPI: add _PDC input override mechanism".
>    =20

I see. There is a kernel patch about enabling MWAIT that refers to that..=
=2E

>=20
>> having no impact on the idle system is not that much surprising. But i=
f that was
>> true it would also limit the usefulness of the turbo mode which I unde=
rstand
>> would also be limited by the c-state of the other cores.
>=20
> Hm, I should double-check that - but somehow I thought that Xen indepen=
detly
> checks for TurboMode and if the P-states are in, then they are activate=
d.
>=20
Turbo mode should be enabled. I had been only looking at a generic overvi=
ew
about it on Intel site which sounded like it  would make more of a differ=
ence on
how much one core could get overclocked related to how many cores are act=
ive
(and I translated active or not into deeper c-states or not).
Looking at the verbose output of turbostat it seems not to make that much=

difference whether 2-4 cores are running. A single core alone could get o=
ne more
increment in clock stepping. That does not immediately sound a lot. And o=
f
course how much or long the higher clock is used depends on other factors=
 as
well and is not under OS control.

In the end it is probably quite dynamic and hard to come up with hard fac=
ts to
prove its value. Though if I can lower the idle power usage by reaching a=
 bit
further, that would greatly help to justify the effort and potential risk=
 of
backporting...

>>
>> Do I misread the data I see? Or maybe its a known limitation? In case =
it is
>> worth doing more research I'll gladly try things and gather more data.=

>=20
> Just missing some patches.=20
>=20
> Oh, and this one:
>       xen/acpi: Fix Kconfig dependency on CPU_FREQ
>=20
> Hmm.. I think a patch disappeared somewhere.
>=20
>>
>> Thanks,
>> Stefan
>>
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--------------enigCEB2AD89CFDA2F503AE61094
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPmXb4AAoJEOhnXe7L7s6jmYoP/RgylFM4I1tCCFN+Hm3r2gAg
cJ2jAM7ww39Mxhe4Yp3+O6l9cI4GS2i4PY/pdZfnbv6Rfe/3DdVMjpzS11TOtBO3
IbTUzfPYKvtYI6dIds45Vlgbx35NwAyzapPkTZYVmPy3OFL5dCo53M4vtXlx7uiP
VXpE7qmaAnJjNeTM/0yMAc9opeZMYVi5sDhTRr7/9XZfEjoJw2ygOGFnWrnunuGA
zM15cw38nanccG2YJ/ut8CeK0I0SjXissnwTaAOTC96jJXXNqgleXXYTFHa7aJQQ
emvmqjdKADWsRzZMtiyYNI1Wq9oACCauMueSoLeBnFkedtg2Zha7mHT+5ipL9av6
mLyCv9o02g8i8mrB2yajLWvC4Kj5VoBmQvPKqO9DrfFN23Wx+jaLx5buwZgMDc5J
S3n/WFYj/Tg3rN1NV/9zKuUTwOsOaZeXyc9mh3W5YY/S32HUIHn8npeBH1vZ9Zbb
Ciwaqp11af8cIqp/ntmy7+SWUZbRE/QJa5S3TDrfh8XPFeTdZ+qI9TNxQC2mELQV
/jugmoFp6TF7RuVmTr3G5JA+UfYhv57zzGtZNtHRkag3D4n9qtUHm/VxoiEZgnRg
LXkgH54lV3yigyJOvYTGrM+Us1aef9kqvSv6dlrMJOd1RWoqV8vFjT8HOmY5EwhY
Q1KWQ/fWnBkD+rLdV6mW
=MsbZ
-----END PGP SIGNATURE-----

--------------enigCEB2AD89CFDA2F503AE61094--


--===============7413593064046783372==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7413593064046783372==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 16:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 16:26:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNRVd-0005Lp-6p; Thu, 26 Apr 2012 16:25:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1SNRVc-0005Lk-H5
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 16:25:32 +0000
Received: from [85.158.143.35:49541] by server-3.bemta-4.messagelabs.com id
	2C/EC-05853-BF6799F4; Thu, 26 Apr 2012 16:25:31 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335457530!14101333!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6195 invoked from network); 26 Apr 2012 16:25:30 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-21.messagelabs.com with SMTP;
	26 Apr 2012 16:25:30 -0000
Received: from p5b2e39c2.dip.t-dialin.net ([91.46.57.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1SNRVa-0001Bb-0J; Thu, 26 Apr 2012 16:25:30 +0000
Message-ID: <4F9976F8.8040502@canonical.com>
Date: Thu, 26 Apr 2012 18:25:28 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F97F58A.8090409@canonical.com>
	<20120426155033.GE26830@phenom.dumpdata.com>
In-Reply-To: <20120426155033.GE26830@phenom.dumpdata.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor
 driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============7413593064046783372=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7413593064046783372==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigCEB2AD89CFDA2F503AE61094"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCEB2AD89CFDA2F503AE61094
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
>> Since there have been requests about that driver to get backported int=
o 3.2, I
>> was interested to find out what or how much would be gained by that.
>>
>> The first system I tried was an AMD based one (8 core Opteron 6128@2GH=
z). Which
>> was not very successful as the drivers bail out of the init function b=
ecause the
>> first call to acpi_processor_register_performance() returns -ENODEV. T=
here is
>> some frequency scaling when running without Xen, so I need to do some =
more
>> debugging there.
>=20
> Did you back-port the other components - the ones that turn off the nat=
ive
> frequency scalling?
>=20
>       provide disable_cpufreq() function to disable the API.
> 	xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
>       xen/cpufreq: Disable the cpu frequency scaling drivers from loadi=
ng
>>

Yes, here is the full set for reference:

* xen/cpufreq: Disable the cpu frequency scaling drivers from loading.
* xen/acpi: Remove the WARN's as they just create noise.
* xen/acpi: Fix Kconfig dependency on CPU_FREQ
* xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
* xen/acpi-processor: C and P-state driver that uploads said data to hype=
r
* provide disable_cpufreq() function to disable the API.

>> The second system was an Intel one (4 core i7 920@2.67GHz) which was
>> successfully loading the driver. Via xenpm I can see the various frequ=
encies and
>> also see them being changed. However the cpuidle data out of xenpm loo=
ks a bit odd:
>>
>> #> xenpm get-cpuidle-states 0
>> Max C-state: C7
>>
>> cpu id               : 0
>> total C-states       : 2
>> idle time(ms)        : 10819311
>> C0                   : transition [00000000000000000001]
>>                        residency  [00000000000000005398 ms]
>> C1                   : transition [00000000000000000001]
>>                        residency  [00000000000010819311 ms]
>> pc3                  : [00000000000000000000 ms]
>> pc6                  : [00000000000000000000 ms]
>> pc7                  : [00000000000000000000 ms]
>> cc3                  : [00000000000000000000 ms]
>> cc6                  : [00000000000000000000 ms]
>>
>> Also gathering samples over 30s does look like only C0 and C1 are used=
=2E This
>=20
> Yes.=20
>> might be because C1E support is enabled in BIOS but when looking at th=
e
>> intel_idle data in sysfs when running without a hypervisor will show C=
3 and C6
>> for the cores. That could have been just a wrong output, so I plugged =
in a power
>> meter and compared a kernel running natively and running as dom0 (with=
 and
>> without the acpi-processor driver).
>>
>> Native: 175W
>> dom0:   183W (with only marginal difference between with or without th=
e
>>               processor driver)
>> [yes, the system has a somewhat high base consumption which I attribut=
e to a
>> ridiculously dimensioned graphics subsystem to be running a text conso=
le]
>>
>> This I would take as C3 and C6 really not being used and the frequency=
 scaling
>=20
> To go in deeper modes there is also a need to backport a Xen unstable
> hypercall which will allow the kernel to detect the other states beside=
s
> C0-C2.
>=20
> "XEN_SET_PDC query was implemented in c/s 23783:
>     "ACPI: add _PDC input override mechanism".
>    =20

I see. There is a kernel patch about enabling MWAIT that refers to that..=
=2E

>=20
>> having no impact on the idle system is not that much surprising. But i=
f that was
>> true it would also limit the usefulness of the turbo mode which I unde=
rstand
>> would also be limited by the c-state of the other cores.
>=20
> Hm, I should double-check that - but somehow I thought that Xen indepen=
detly
> checks for TurboMode and if the P-states are in, then they are activate=
d.
>=20
Turbo mode should be enabled. I had been only looking at a generic overvi=
ew
about it on Intel site which sounded like it  would make more of a differ=
ence on
how much one core could get overclocked related to how many cores are act=
ive
(and I translated active or not into deeper c-states or not).
Looking at the verbose output of turbostat it seems not to make that much=

difference whether 2-4 cores are running. A single core alone could get o=
ne more
increment in clock stepping. That does not immediately sound a lot. And o=
f
course how much or long the higher clock is used depends on other factors=
 as
well and is not under OS control.

In the end it is probably quite dynamic and hard to come up with hard fac=
ts to
prove its value. Though if I can lower the idle power usage by reaching a=
 bit
further, that would greatly help to justify the effort and potential risk=
 of
backporting...

>>
>> Do I misread the data I see? Or maybe its a known limitation? In case =
it is
>> worth doing more research I'll gladly try things and gather more data.=

>=20
> Just missing some patches.=20
>=20
> Oh, and this one:
>       xen/acpi: Fix Kconfig dependency on CPU_FREQ
>=20
> Hmm.. I think a patch disappeared somewhere.
>=20
>>
>> Thanks,
>> Stefan
>>
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--------------enigCEB2AD89CFDA2F503AE61094
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPmXb4AAoJEOhnXe7L7s6jmYoP/RgylFM4I1tCCFN+Hm3r2gAg
cJ2jAM7ww39Mxhe4Yp3+O6l9cI4GS2i4PY/pdZfnbv6Rfe/3DdVMjpzS11TOtBO3
IbTUzfPYKvtYI6dIds45Vlgbx35NwAyzapPkTZYVmPy3OFL5dCo53M4vtXlx7uiP
VXpE7qmaAnJjNeTM/0yMAc9opeZMYVi5sDhTRr7/9XZfEjoJw2ygOGFnWrnunuGA
zM15cw38nanccG2YJ/ut8CeK0I0SjXissnwTaAOTC96jJXXNqgleXXYTFHa7aJQQ
emvmqjdKADWsRzZMtiyYNI1Wq9oACCauMueSoLeBnFkedtg2Zha7mHT+5ipL9av6
mLyCv9o02g8i8mrB2yajLWvC4Kj5VoBmQvPKqO9DrfFN23Wx+jaLx5buwZgMDc5J
S3n/WFYj/Tg3rN1NV/9zKuUTwOsOaZeXyc9mh3W5YY/S32HUIHn8npeBH1vZ9Zbb
Ciwaqp11af8cIqp/ntmy7+SWUZbRE/QJa5S3TDrfh8XPFeTdZ+qI9TNxQC2mELQV
/jugmoFp6TF7RuVmTr3G5JA+UfYhv57zzGtZNtHRkag3D4n9qtUHm/VxoiEZgnRg
LXkgH54lV3yigyJOvYTGrM+Us1aef9kqvSv6dlrMJOd1RWoqV8vFjT8HOmY5EwhY
Q1KWQ/fWnBkD+rLdV6mW
=MsbZ
-----END PGP SIGNATURE-----

--------------enigCEB2AD89CFDA2F503AE61094--


--===============7413593064046783372==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7413593064046783372==--


From xen-devel-bounces@lists.xen.org Thu Apr 26 17:04:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:04:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNS70-0005g7-Ky; Thu, 26 Apr 2012 17:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNS6y-0005g2-MX
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:04:08 +0000
Received: from [85.158.143.99:36717] by server-2.bemta-4.messagelabs.com id
	73/00-17550-800899F4; Thu, 26 Apr 2012 17:04:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335459846!14235171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 26 Apr 2012 17:04:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 17:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12162800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 17:03:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 18:03:58 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNS6o-00014W-B2;
	Thu, 26 Apr 2012 17:03:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNS6o-0002vO-4q;
	Thu, 26 Apr 2012 18:03:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12756-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 18:03:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12756: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12756 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12756/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  107285938c50
baseline version:
 xen                  a4e7fce6ee2b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=107285938c50
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 107285938c50
+ branch=xen-unstable
+ revision=107285938c50
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 107285938c50 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 8 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 17:04:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:04:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNS70-0005g7-Ky; Thu, 26 Apr 2012 17:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNS6y-0005g2-MX
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:04:08 +0000
Received: from [85.158.143.99:36717] by server-2.bemta-4.messagelabs.com id
	73/00-17550-800899F4; Thu, 26 Apr 2012 17:04:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335459846!14235171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 26 Apr 2012 17:04:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 17:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12162800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 17:03:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 18:03:58 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNS6o-00014W-B2;
	Thu, 26 Apr 2012 17:03:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNS6o-0002vO-4q;
	Thu, 26 Apr 2012 18:03:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12756-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 18:03:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12756: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12756 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12756/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12755

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  107285938c50
baseline version:
 xen                  a4e7fce6ee2b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=107285938c50
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 107285938c50
+ branch=xen-unstable
+ revision=107285938c50
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 107285938c50 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 8 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 17:10:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNSCs-0005qa-JC; Thu, 26 Apr 2012 17:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNSCq-0005qR-9x
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:10:12 +0000
Received: from [85.158.143.35:55679] by server-2.bemta-4.messagelabs.com id
	D4/44-17550-371899F4; Thu, 26 Apr 2012 17:10:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335460208!15033871!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17107 invoked from network); 26 Apr 2012 17:10:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 17:10:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QHA1FG003511
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 17:10:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QHA09l002067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 17:10:01 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QHA0JA005552; Thu, 26 Apr 2012 12:10:00 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 10:10:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8D7814031D; Thu, 26 Apr 2012 13:04:26 -0400 (EDT)
Date: Thu, 26 Apr 2012 13:04:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120426170426.GI26830@phenom.dumpdata.com>
References: <4F97F58A.8090409@canonical.com>
	<20120426155033.GE26830@phenom.dumpdata.com>
	<4F9976F8.8040502@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9976F8.8040502@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor
 driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote:
> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote:
> > On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
> >> Since there have been requests about that driver to get backported into 3.2, I
> >> was interested to find out what or how much would be gained by that.
> >>
> >> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which
> >> was not very successful as the drivers bail out of the init function because the
> >> first call to acpi_processor_register_performance() returns -ENODEV. There is
> >> some frequency scaling when running without Xen, so I need to do some more
> >> debugging there.
> > 
> > Did you back-port the other components - the ones that turn off the native
> > frequency scalling?
> > 
> >       provide disable_cpufreq() function to disable the API.
> > 	xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
> >       xen/cpufreq: Disable the cpu frequency scaling drivers from loading
> >>
> 
> Yes, here is the full set for reference:
> 
> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading.
> * xen/acpi: Remove the WARN's as they just create noise.
> * xen/acpi: Fix Kconfig dependency on CPU_FREQ
> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
> * xen/acpi-processor: C and P-state driver that uploads said data to hyper
> * provide disable_cpufreq() function to disable the API.

The one thing that I forgot to mention about the:
 xen/cpufreq: Disable the cpu frequency scaling drivers from loading.

is that it also fixes a bug - which is that without this, the acpi-cpufreq
would run and change the frequency states based on what dom0 thought was good.
Which meant that Xen hypervisor would run with somebody behind its back
changing the P-states - and would lower the performance in some case
a lot (especially if one used the dom0_max_vcpus=X).
.. snip..
> >> Native: 175W
> >> dom0:   183W (with only marginal difference between with or without the
> >>               processor driver)

What happens if you run it xen-acpi-processor.off=1 ?

(That should inhibit the driver from uploading the power management data).

Is the value ~200w?

> >> [yes, the system has a somewhat high base consumption which I attribute to a
> >> ridiculously dimensioned graphics subsystem to be running a text console]

Heh.
> >>
> >> This I would take as C3 and C6 really not being used and the frequency scaling
> > 
> > To go in deeper modes there is also a need to backport a Xen unstable
> > hypercall which will allow the kernel to detect the other states besides
> > C0-C2.
> > 
> > "XEN_SET_PDC query was implemented in c/s 23783:
> >     "ACPI: add _PDC input override mechanism".
> >     
> 
> I see. There is a kernel patch about enabling MWAIT that refers to that...

Yeah, I should see about back-porting it in Xen 4.1..

> 
> > 
> >> having no impact on the idle system is not that much surprising. But if that was
> >> true it would also limit the usefulness of the turbo mode which I understand
> >> would also be limited by the c-state of the other cores.
> > 
> > Hm, I should double-check that - but somehow I thought that Xen independetly
> > checks for TurboMode and if the P-states are in, then they are activated.
> > 
> Turbo mode should be enabled. I had been only looking at a generic overview
> about it on Intel site which sounded like it  would make more of a difference on
> how much one core could get overclocked related to how many cores are active
> (and I translated active or not into deeper c-states or not).
> Looking at the verbose output of turbostat it seems not to make that much
> difference whether 2-4 cores are running. A single core alone could get one more
> increment in clock stepping. That does not immediately sound a lot. And of
> course how much or long the higher clock is used depends on other factors as
> well and is not under OS control.
> 
> In the end it is probably quite dynamic and hard to come up with hard facts to
> prove its value. Though if I can lower the idle power usage by reaching a bit
> further, that would greatly help to justify the effort and potential risk of
> backporting...

Did you see the P-states dipping? I don't really know how much using C-states
beyond C-2 matters on baremetal in terms of saving power?

> 
> >>
> >> Do I misread the data I see? Or maybe its a known limitation? In case it is
> >> worth doing more research I'll gladly try things and gather more data.

This patchset was driven more by the performance needs. Somehow (and I am not
sure how), using the PM, makes the whole system work much faster. That was
what Ian found out when he ran the Phorenix benchmark.

But looking back, perhaps the reason for this was that the native
cpufreq scaling drivers were running in the back changing the machine's
power states without consulting the Xen hypervisor.

> > 
> > Just missing some patches. 
> > 
> > Oh, and this one:
> >       xen/acpi: Fix Kconfig dependency on CPU_FREQ
> > 
> > Hmm.. I think a patch disappeared somewhere.
> > 
> >>
> >> Thanks,
> >> Stefan
> >>
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 17:10:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNSCs-0005qa-JC; Thu, 26 Apr 2012 17:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNSCq-0005qR-9x
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:10:12 +0000
Received: from [85.158.143.35:55679] by server-2.bemta-4.messagelabs.com id
	D4/44-17550-371899F4; Thu, 26 Apr 2012 17:10:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1335460208!15033871!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17107 invoked from network); 26 Apr 2012 17:10:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 17:10:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QHA1FG003511
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 17:10:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QHA09l002067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 17:10:01 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QHA0JA005552; Thu, 26 Apr 2012 12:10:00 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 10:10:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8D7814031D; Thu, 26 Apr 2012 13:04:26 -0400 (EDT)
Date: Thu, 26 Apr 2012 13:04:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120426170426.GI26830@phenom.dumpdata.com>
References: <4F97F58A.8090409@canonical.com>
	<20120426155033.GE26830@phenom.dumpdata.com>
	<4F9976F8.8040502@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9976F8.8040502@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor
 driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote:
> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote:
> > On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
> >> Since there have been requests about that driver to get backported into 3.2, I
> >> was interested to find out what or how much would be gained by that.
> >>
> >> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which
> >> was not very successful as the drivers bail out of the init function because the
> >> first call to acpi_processor_register_performance() returns -ENODEV. There is
> >> some frequency scaling when running without Xen, so I need to do some more
> >> debugging there.
> > 
> > Did you back-port the other components - the ones that turn off the native
> > frequency scalling?
> > 
> >       provide disable_cpufreq() function to disable the API.
> > 	xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
> >       xen/cpufreq: Disable the cpu frequency scaling drivers from loading
> >>
> 
> Yes, here is the full set for reference:
> 
> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading.
> * xen/acpi: Remove the WARN's as they just create noise.
> * xen/acpi: Fix Kconfig dependency on CPU_FREQ
> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
> * xen/acpi-processor: C and P-state driver that uploads said data to hyper
> * provide disable_cpufreq() function to disable the API.

The one thing that I forgot to mention about the:
 xen/cpufreq: Disable the cpu frequency scaling drivers from loading.

is that it also fixes a bug - which is that without this, the acpi-cpufreq
would run and change the frequency states based on what dom0 thought was good.
Which meant that Xen hypervisor would run with somebody behind its back
changing the P-states - and would lower the performance in some case
a lot (especially if one used the dom0_max_vcpus=X).
.. snip..
> >> Native: 175W
> >> dom0:   183W (with only marginal difference between with or without the
> >>               processor driver)

What happens if you run it xen-acpi-processor.off=1 ?

(That should inhibit the driver from uploading the power management data).

Is the value ~200w?

> >> [yes, the system has a somewhat high base consumption which I attribute to a
> >> ridiculously dimensioned graphics subsystem to be running a text console]

Heh.
> >>
> >> This I would take as C3 and C6 really not being used and the frequency scaling
> > 
> > To go in deeper modes there is also a need to backport a Xen unstable
> > hypercall which will allow the kernel to detect the other states besides
> > C0-C2.
> > 
> > "XEN_SET_PDC query was implemented in c/s 23783:
> >     "ACPI: add _PDC input override mechanism".
> >     
> 
> I see. There is a kernel patch about enabling MWAIT that refers to that...

Yeah, I should see about back-porting it in Xen 4.1..

> 
> > 
> >> having no impact on the idle system is not that much surprising. But if that was
> >> true it would also limit the usefulness of the turbo mode which I understand
> >> would also be limited by the c-state of the other cores.
> > 
> > Hm, I should double-check that - but somehow I thought that Xen independetly
> > checks for TurboMode and if the P-states are in, then they are activated.
> > 
> Turbo mode should be enabled. I had been only looking at a generic overview
> about it on Intel site which sounded like it  would make more of a difference on
> how much one core could get overclocked related to how many cores are active
> (and I translated active or not into deeper c-states or not).
> Looking at the verbose output of turbostat it seems not to make that much
> difference whether 2-4 cores are running. A single core alone could get one more
> increment in clock stepping. That does not immediately sound a lot. And of
> course how much or long the higher clock is used depends on other factors as
> well and is not under OS control.
> 
> In the end it is probably quite dynamic and hard to come up with hard facts to
> prove its value. Though if I can lower the idle power usage by reaching a bit
> further, that would greatly help to justify the effort and potential risk of
> backporting...

Did you see the P-states dipping? I don't really know how much using C-states
beyond C-2 matters on baremetal in terms of saving power?

> 
> >>
> >> Do I misread the data I see? Or maybe its a known limitation? In case it is
> >> worth doing more research I'll gladly try things and gather more data.

This patchset was driven more by the performance needs. Somehow (and I am not
sure how), using the PM, makes the whole system work much faster. That was
what Ian found out when he ran the Phorenix benchmark.

But looking back, perhaps the reason for this was that the native
cpufreq scaling drivers were running in the back changing the machine's
power states without consulting the Xen hypervisor.

> > 
> > Just missing some patches. 
> > 
> > Oh, and this one:
> >       xen/acpi: Fix Kconfig dependency on CPU_FREQ
> > 
> > Hmm.. I think a patch disappeared somewhere.
> > 
> >>
> >> Thanks,
> >> Stefan
> >>
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 17:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNSFo-0005yB-64; Thu, 26 Apr 2012 17:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNSFm-0005y6-VJ
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:13:15 +0000
Received: from [85.158.143.35:59968] by server-1.bemta-4.messagelabs.com id
	FE/C0-20925-A22899F4; Thu, 26 Apr 2012 17:13:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335460392!14106561!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10900 invoked from network); 26 Apr 2012 17:13:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 17:13:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330923600"; d="scan'208";a="192247330"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:12:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 13:12:31 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SNSF0-000341-6t; Thu, 26 Apr 2012 18:12:26 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 26 Apr 2012 18:18:57 +0100
Message-ID: <1335460737-9463-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, hch@lst.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] xen_disk: use bdrv_aio_flush instead of
	bdrv_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use bdrv_aio_flush instead of bdrv_flush.

Make sure to call bdrv_aio_writev/readv after the presync bdrv_aio_flush is fully
completed and make sure to call the postsync bdrv_aio_flush after
bdrv_aio_writev/readv is fully completed.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |   22 ++++++++++++++++++----
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 49e53b7..cf06243 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -66,6 +66,7 @@ struct ioreq {
     QEMUIOVector        v;
     int                 presync;
     int                 postsync;
+    uint8_t             mapped;
 
     /* grant mapping */
     uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -242,7 +243,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
     XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
     int i;
 
-    if (ioreq->v.niov == 0) {
+    if (ioreq->v.niov == 0 || ioreq->mapped == 0) {
         return;
     }
     if (batch_maps) {
@@ -268,6 +269,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
             ioreq->page[i] = NULL;
         }
     }
+    ioreq->mapped = 0;
 }
 
 static int ioreq_map(struct ioreq *ioreq)
@@ -275,7 +277,7 @@ static int ioreq_map(struct ioreq *ioreq)
     XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
     int i;
 
-    if (ioreq->v.niov == 0) {
+    if (ioreq->v.niov == 0 || ioreq->mapped == 1) {
         return 0;
     }
     if (batch_maps) {
@@ -307,9 +309,12 @@ static int ioreq_map(struct ioreq *ioreq)
             ioreq->blkdev->cnt_map++;
         }
     }
+    ioreq->mapped = 1;
     return 0;
 }
 
+static int ioreq_runio_qemu_aio(struct ioreq *ioreq);
+
 static void qemu_aio_complete(void *opaque, int ret)
 {
     struct ioreq *ioreq = opaque;
@@ -321,11 +326,19 @@ static void qemu_aio_complete(void *opaque, int ret)
     }
 
     ioreq->aio_inflight--;
+    if (ioreq->presync) {
+        ioreq->presync = 0;
+        ioreq_runio_qemu_aio(ioreq);
+        return;
+    }
     if (ioreq->aio_inflight > 0) {
         return;
     }
     if (ioreq->postsync) {
-        bdrv_flush(ioreq->blkdev->bs);
+        ioreq->postsync = 0;
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+        return;
     }
 
     ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
@@ -345,7 +358,8 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 
     ioreq->aio_inflight++;
     if (ioreq->presync) {
-        bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+        return 0;
     }
 
     switch (ioreq->req.operation) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 17:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNSFo-0005yB-64; Thu, 26 Apr 2012 17:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SNSFm-0005y6-VJ
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:13:15 +0000
Received: from [85.158.143.35:59968] by server-1.bemta-4.messagelabs.com id
	FE/C0-20925-A22899F4; Thu, 26 Apr 2012 17:13:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335460392!14106561!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDcyNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10900 invoked from network); 26 Apr 2012 17:13:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 17:13:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330923600"; d="scan'208";a="192247330"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 13:12:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Apr 2012 13:12:31 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1SNSF0-000341-6t; Thu, 26 Apr 2012 18:12:26 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 26 Apr 2012 18:18:57 +0100
Message-ID: <1335460737-9463-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: kwolf@redhat.com, xen-devel@lists.xensource.com, hch@lst.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] xen_disk: use bdrv_aio_flush instead of
	bdrv_flush
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use bdrv_aio_flush instead of bdrv_flush.

Make sure to call bdrv_aio_writev/readv after the presync bdrv_aio_flush is fully
completed and make sure to call the postsync bdrv_aio_flush after
bdrv_aio_writev/readv is fully completed.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_disk.c |   22 ++++++++++++++++++----
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 49e53b7..cf06243 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -66,6 +66,7 @@ struct ioreq {
     QEMUIOVector        v;
     int                 presync;
     int                 postsync;
+    uint8_t             mapped;
 
     /* grant mapping */
     uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -242,7 +243,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
     XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
     int i;
 
-    if (ioreq->v.niov == 0) {
+    if (ioreq->v.niov == 0 || ioreq->mapped == 0) {
         return;
     }
     if (batch_maps) {
@@ -268,6 +269,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
             ioreq->page[i] = NULL;
         }
     }
+    ioreq->mapped = 0;
 }
 
 static int ioreq_map(struct ioreq *ioreq)
@@ -275,7 +277,7 @@ static int ioreq_map(struct ioreq *ioreq)
     XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
     int i;
 
-    if (ioreq->v.niov == 0) {
+    if (ioreq->v.niov == 0 || ioreq->mapped == 1) {
         return 0;
     }
     if (batch_maps) {
@@ -307,9 +309,12 @@ static int ioreq_map(struct ioreq *ioreq)
             ioreq->blkdev->cnt_map++;
         }
     }
+    ioreq->mapped = 1;
     return 0;
 }
 
+static int ioreq_runio_qemu_aio(struct ioreq *ioreq);
+
 static void qemu_aio_complete(void *opaque, int ret)
 {
     struct ioreq *ioreq = opaque;
@@ -321,11 +326,19 @@ static void qemu_aio_complete(void *opaque, int ret)
     }
 
     ioreq->aio_inflight--;
+    if (ioreq->presync) {
+        ioreq->presync = 0;
+        ioreq_runio_qemu_aio(ioreq);
+        return;
+    }
     if (ioreq->aio_inflight > 0) {
         return;
     }
     if (ioreq->postsync) {
-        bdrv_flush(ioreq->blkdev->bs);
+        ioreq->postsync = 0;
+        ioreq->aio_inflight++;
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+        return;
     }
 
     ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
@@ -345,7 +358,8 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 
     ioreq->aio_inflight++;
     if (ioreq->presync) {
-        bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */
+        bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq);
+        return 0;
     }
 
     switch (ioreq->req.operation) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 17:55:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:55:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNSuO-0006IZ-NA; Thu, 26 Apr 2012 17:55:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SNSuM-0006IU-VV
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:55:11 +0000
Received: from [85.158.143.35:55962] by server-3.bemta-4.messagelabs.com id
	58/02-05853-EFB899F4; Thu, 26 Apr 2012 17:55:10 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335462907!14188167!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=0.8 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	SUBJECT_EXCESS_BASE64,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15704 invoked from network); 26 Apr 2012 17:55:09 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 17:55:09 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SNSuG-0001pK-S1
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 19:55:05 +0200
Received: from c-174-61-233-112.hsd1.wa.comcast.net ([174.61.233.112])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 19:55:04 +0200
Received: from Christian.Limpach by c-174-61-233-112.hsd1.wa.comcast.net with
	local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 19:55:04 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Limpach <Christian.Limpach@gmail.com>
Date: Thu, 26 Apr 2012 17:50:34 +0000 (UTC)
Lines: 17
Message-ID: <loom.20120426T194820-467@post.gmane.org>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<2b109c735483d07e494b0dc14256d1f93b150595.1332430810.git.julien.grall@citrix.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 174.61.233.112 (Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162
	Safari/535.19)
Subject: Re: [Xen-devel]
	=?utf-8?q?=5BXEN=5D=5BRFC_PATCH_05/15=5D_hvm=3A_Modif?=
	=?utf-8?q?y_hvm=5Fop?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall <julien.grall <at> citrix.com> writes:

> This patch remove useless hvm_param due to structure modification
> and bind the new hypercalls to handle ioreq servers and pci.
>
> +            case HVM_PARAM_IO_PFN_LAST:
> +                if ( (d->arch.hvm_domain.params[HVM_PARAM_IO_PFN_LAST]) )
> +                    rc = -EINVAL;
  +                break;
>              case HVM_PARAM_CALLBACK_IRQ:
>                  hvm_set_callback_via(d, a.value);
>                  hvm_latch_shinfo_size(d);

Above has a missing break statement.

    christian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 17:55:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 17:55:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNSuO-0006IZ-NA; Thu, 26 Apr 2012 17:55:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SNSuM-0006IU-VV
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 17:55:11 +0000
Received: from [85.158.143.35:55962] by server-3.bemta-4.messagelabs.com id
	58/02-05853-EFB899F4; Thu, 26 Apr 2012 17:55:10 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335462907!14188167!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=0.8 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	SUBJECT_EXCESS_BASE64,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15704 invoked from network); 26 Apr 2012 17:55:09 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Apr 2012 17:55:09 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1SNSuG-0001pK-S1
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 19:55:05 +0200
Received: from c-174-61-233-112.hsd1.wa.comcast.net ([174.61.233.112])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 19:55:04 +0200
Received: from Christian.Limpach by c-174-61-233-112.hsd1.wa.comcast.net with
	local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 19:55:04 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Christian Limpach <Christian.Limpach@gmail.com>
Date: Thu, 26 Apr 2012 17:50:34 +0000 (UTC)
Lines: 17
Message-ID: <loom.20120426T194820-467@post.gmane.org>
References: <cover.1332430810.git.julien.grall@citrix.com>
	<2b109c735483d07e494b0dc14256d1f93b150595.1332430810.git.julien.grall@citrix.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 174.61.233.112 (Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162
	Safari/535.19)
Subject: Re: [Xen-devel]
	=?utf-8?q?=5BXEN=5D=5BRFC_PATCH_05/15=5D_hvm=3A_Modif?=
	=?utf-8?q?y_hvm=5Fop?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall <julien.grall <at> citrix.com> writes:

> This patch remove useless hvm_param due to structure modification
> and bind the new hypercalls to handle ioreq servers and pci.
>
> +            case HVM_PARAM_IO_PFN_LAST:
> +                if ( (d->arch.hvm_domain.params[HVM_PARAM_IO_PFN_LAST]) )
> +                    rc = -EINVAL;
  +                break;
>              case HVM_PARAM_CALLBACK_IRQ:
>                  hvm_set_callback_via(d, a.value);
>                  hvm_latch_shinfo_size(d);

Above has a missing break statement.

    christian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTHd-0006c5-Tv; Thu, 26 Apr 2012 18:19:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNTHb-0006c0-Nx
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:19:11 +0000
Received: from [85.158.143.35:46784] by server-2.bemta-4.messagelabs.com id
	61/90-17550-F91999F4; Thu, 26 Apr 2012 18:19:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335464348!13125389!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7230 invoked from network); 26 Apr 2012 18:19:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:19:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIJ0i3015341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:19:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIIx8r022726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:18:59 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIIwmP013023; Thu, 26 Apr 2012 13:18:58 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:18:58 -0700
Date: Thu, 26 Apr 2012 11:18:48 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120426111848.34e43e75@mantra.us.oracle.com>
In-Reply-To: <20120426090847.GA67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012 10:08:47 +0100
Tim Deegan <tim@xen.org> wrote:

> At 16:06 -0700 on 24 Apr (1335283603), Mukesh Rathor wrote:
> > On Tue, 24 Apr 2012 10:36:26 +0100
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > > > On Thu, 19 Apr 2012 15:15:27 +0100
> > > > Tim Deegan <tim@xen.org> wrote:
> > 
> > >you still have this mapping.  You should take a PGT_writeable_page
> > >typecount, too, if the foreign domain isn't in paging_mode_external
> > 
> > Ok, I've it as:
> >     if (paging_mode_external(fdom)) {
> >         if (get_page_from_pagenr(mfn, fdom) == 0)
> > 	    failed = 1;
> >     } else {
> >         if (get_page_and_type_from_pagenr(mfn, PGT_writable_page,
> > fdom,0,0)) failed = 1;
> >     }
> > 
> > But then later fails when it tries to pin the page,
> > MMUEXT_PIN_L4_TABLE, from the lib at:
> 
> What's trying to pin an l4 table?  I thought your hybrid dom0 didn't
> use the PV MMU.
> 
> Tim.

Right, hybrid doesn't use PV mmu. 
Here, xl/xc is building a pv guest while running on *hybrid* dom0. 
As a result, privcmd is calling this function to map
foreign mfns to pfns: 

xc_dom_x86.c:
      arch_setup_bootlate -> pin_table -> xc_mmuext_op().

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTHd-0006c5-Tv; Thu, 26 Apr 2012 18:19:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNTHb-0006c0-Nx
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:19:11 +0000
Received: from [85.158.143.35:46784] by server-2.bemta-4.messagelabs.com id
	61/90-17550-F91999F4; Thu, 26 Apr 2012 18:19:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335464348!13125389!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7230 invoked from network); 26 Apr 2012 18:19:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:19:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIJ0i3015341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:19:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIIx8r022726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:18:59 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIIwmP013023; Thu, 26 Apr 2012 13:18:58 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:18:58 -0700
Date: Thu, 26 Apr 2012 11:18:48 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120426111848.34e43e75@mantra.us.oracle.com>
In-Reply-To: <20120426090847.GA67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012 10:08:47 +0100
Tim Deegan <tim@xen.org> wrote:

> At 16:06 -0700 on 24 Apr (1335283603), Mukesh Rathor wrote:
> > On Tue, 24 Apr 2012 10:36:26 +0100
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > > > On Thu, 19 Apr 2012 15:15:27 +0100
> > > > Tim Deegan <tim@xen.org> wrote:
> > 
> > >you still have this mapping.  You should take a PGT_writeable_page
> > >typecount, too, if the foreign domain isn't in paging_mode_external
> > 
> > Ok, I've it as:
> >     if (paging_mode_external(fdom)) {
> >         if (get_page_from_pagenr(mfn, fdom) == 0)
> > 	    failed = 1;
> >     } else {
> >         if (get_page_and_type_from_pagenr(mfn, PGT_writable_page,
> > fdom,0,0)) failed = 1;
> >     }
> > 
> > But then later fails when it tries to pin the page,
> > MMUEXT_PIN_L4_TABLE, from the lib at:
> 
> What's trying to pin an l4 table?  I thought your hybrid dom0 didn't
> use the PV MMU.
> 
> Tim.

Right, hybrid doesn't use PV mmu. 
Here, xl/xc is building a pv guest while running on *hybrid* dom0. 
As a result, privcmd is calling this function to map
foreign mfns to pfns: 

xc_dom_x86.c:
      arch_setup_bootlate -> pin_table -> xc_mmuext_op().

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:31:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTT3-0006n9-BV; Thu, 26 Apr 2012 18:31:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTT1-0006n4-Sr
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:31:00 +0000
Received: from [85.158.143.35:23104] by server-3.bemta-4.messagelabs.com id
	BC/88-05853-364999F4; Thu, 26 Apr 2012 18:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335465057!8873694!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22586 invoked from network); 26 Apr 2012 18:30:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:30:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIUq68024283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:30:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIUpCX002682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:30:51 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIUpFc031538; Thu, 26 Apr 2012 13:30:51 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:30:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7166640028; Thu, 26 Apr 2012 14:25:17 -0400 (EDT)
Date: Thu, 26 Apr 2012 14:25:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120426182517.GA24459@phenom.dumpdata.com>
References: <201204241904.03726.tobias.geiger@vido.info>
	<20120424173601.GA27353@phenom.dumpdata.com>
	<4F973726.9010405@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F973726.9010405@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 01:28:38AM +0200, Tobias Geiger wrote:
> Am 24.04.2012 19:36, schrieb Konrad Rzeszutek Wilk:
> >On Tue, Apr 24, 2012 at 07:04:03PM +0200, Tobias Geiger wrote:
> >>Hi,
> >>
> >>i'm not sure if i understood the new acpi xen cpufreq driver - here's the
> >>output when loading  xen_acpi_processor module in linux 3.4:
> >>
> >>dom0 dmesg:
> >>
> >>[   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
> >>[   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
> >>[   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
> >>[   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
> >>[   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
> >>[   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
> >>[   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14

So your DSDT has:

   External (\_PR_.CPUF, DeviceObj)
    External (\_PR_.CPUE, DeviceObj)
    External (\_PR_.CPUD, DeviceObj)
    External (\_PR_.CPUC, DeviceObj)
    External (\_PR_.CPUB, DeviceObj)
    External (\_PR_.CPUA, DeviceObj)
    External (\_PR_.CPU9, DeviceObj)
    External (\_PR_.CPU8, DeviceObj)
    External (\_PR_.CPU7, DeviceObj)
    External (\_PR_.CPU6, DeviceObj)
    External (\_PR_.CPU5, DeviceObj)
    External (\_PR_.CPU4, DeviceObj)
    External (\_PR_.CPU3, DeviceObj)
    External (\_PR_.CPU2, DeviceObj)
    External (\_PR_.CPU1, DeviceObj)
    External (\_PR_.CPU0, DeviceObj)

And along with some other stuff in the DSDT it advertises that
it has 16 CPUs and it sets up even sixteen _CST and _PST data structures.

But you only have eight. This is really a BIOS bug.

However, let me fix it in the driver so that you don't get that error.
(I had a similar fix in the driver for dealing with the P-states
but didn't do it for the C-states).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:31:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTT3-0006n9-BV; Thu, 26 Apr 2012 18:31:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTT1-0006n4-Sr
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:31:00 +0000
Received: from [85.158.143.35:23104] by server-3.bemta-4.messagelabs.com id
	BC/88-05853-364999F4; Thu, 26 Apr 2012 18:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1335465057!8873694!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22586 invoked from network); 26 Apr 2012 18:30:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:30:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIUq68024283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:30:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIUpCX002682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:30:51 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIUpFc031538; Thu, 26 Apr 2012 13:30:51 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:30:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7166640028; Thu, 26 Apr 2012 14:25:17 -0400 (EDT)
Date: Thu, 26 Apr 2012 14:25:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120426182517.GA24459@phenom.dumpdata.com>
References: <201204241904.03726.tobias.geiger@vido.info>
	<20120424173601.GA27353@phenom.dumpdata.com>
	<4F973726.9010405@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F973726.9010405@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen acpi cpufreq driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Apr 25, 2012 at 01:28:38AM +0200, Tobias Geiger wrote:
> Am 24.04.2012 19:36, schrieb Konrad Rzeszutek Wilk:
> >On Tue, Apr 24, 2012 at 07:04:03PM +0200, Tobias Geiger wrote:
> >>Hi,
> >>
> >>i'm not sure if i understood the new acpi xen cpufreq driver - here's the
> >>output when loading  xen_acpi_processor module in linux 3.4:
> >>
> >>dom0 dmesg:
> >>
> >>[   32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8
> >>[   32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9
> >>[   32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU10
> >>[   32.728164] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU11
> >>[   32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12
> >>[   32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13
> >>[   32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14

So your DSDT has:

   External (\_PR_.CPUF, DeviceObj)
    External (\_PR_.CPUE, DeviceObj)
    External (\_PR_.CPUD, DeviceObj)
    External (\_PR_.CPUC, DeviceObj)
    External (\_PR_.CPUB, DeviceObj)
    External (\_PR_.CPUA, DeviceObj)
    External (\_PR_.CPU9, DeviceObj)
    External (\_PR_.CPU8, DeviceObj)
    External (\_PR_.CPU7, DeviceObj)
    External (\_PR_.CPU6, DeviceObj)
    External (\_PR_.CPU5, DeviceObj)
    External (\_PR_.CPU4, DeviceObj)
    External (\_PR_.CPU3, DeviceObj)
    External (\_PR_.CPU2, DeviceObj)
    External (\_PR_.CPU1, DeviceObj)
    External (\_PR_.CPU0, DeviceObj)

And along with some other stuff in the DSDT it advertises that
it has 16 CPUs and it sets up even sixteen _CST and _PST data structures.

But you only have eight. This is really a BIOS bug.

However, let me fix it in the driver so that you don't get that error.
(I had a similar fix in the driver for dealing with the P-states
but didn't do it for the C-states).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:34:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTW5-0006tH-Da; Thu, 26 Apr 2012 18:34:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNTW3-0006t2-Fp
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:34:07 +0000
Received: from [193.109.254.147:15068] by server-5.bemta-14.messagelabs.com id
	1E/A9-30733-E15999F4; Thu, 26 Apr 2012 18:34:06 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335465243!837411!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15517 invoked from network); 26 Apr 2012 18:34:05 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:34:05 -0000
Received: by pbcuo5 with SMTP id uo5so28298pbc.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 11:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=esPy4y7mjErTSNollkaR8PSAIXf6xUK6UmnhgPafkyU=;
	b=Xjy0dC6o6LsD8zYy4WBWR0Fu4rLmNdNdvbsyME09mLQoCTY0/uv4xgizrqO3iQG5I1
	h6R2mNpsoeCBz6xF91Wg5HyIVpX0CB0B3DGzqPmQ2IIDgrGNAIIVbMeLhec/HgWxRrxj
	Em1LWBgt4PBND8PrIc0mBsWMvtbg7LWG24xe4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc:x-gm-message-state;
	bh=esPy4y7mjErTSNollkaR8PSAIXf6xUK6UmnhgPafkyU=;
	b=bSIiOWeOoaap4lYHG05lHtLxZ3Fs3/jOKBluwruwx0w/llEz7FwupFBDhWauDHveow
	JXfb/lrMRZWHtr+gVHbtWwIYISNAE+hZWgXZNPgI8qoegDptdpgbcTSJVZAv8mOpdAI4
	jvpLeCdPsJ1jEQeazLs6MUKJRZbnQxT1X3KmugHFMRGUJTFXSxFNAkoyi7pY61Nu6Tf3
	BVSnqLiaiYp8/rwKBt4XeK5uwhRFviNf64TPiHTeaCfcn2wgqwluFVIoxlyszv59O/Yh
	nonpdKBx5WNcA8gRFTZ3JyJMlYvBJ06zATTPqp1rckV1kHMYlH2M1cv4AOfq4ZGV6way
	CSMw==
Received: by 10.68.216.225 with SMTP id ot1mr17216902pbc.46.1335465243536;
	Thu, 26 Apr 2012 11:34:03 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id ud10sm3982536pbc.25.2012.04.26.11.34.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 11:34:02 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f12cf785738f97260ebff4a97d94df3ebd1b6aec
Message-Id: <f12cf785738f97260ebf.1335465210@vollum>
In-Reply-To: <patchbomb.1335465209@vollum>
References: <patchbomb.1335465209@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Thu, 26 Apr 2012 11:33:30 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnu2e6WWvJIK9RRRLQPplSdeYxSgKlmFFbTHZZom/otWC9SBtnLNAgSusRLuzkQcwXh0Rqo
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Split ept_set_entry()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/p2m-ept.c |  60 ++++++++++++++++++++++++++++------------------
 1 files changed, 37 insertions(+), 23 deletions(-)


Split ept_set_entry() such that mapping and unmapping of the page tables and ept_sync occurrs outside of it.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 63eb1343cbdb -r f12cf785738f xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:53 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:54 2012 -0700
@@ -272,14 +272,15 @@ static int ept_next_level(struct p2m_dom
 }
 
 /*
- * ept_set_entry() computes 'need_modify_vtd_table' for itself,
+ * __ept_set_entry() computes 'need_modify_vtd_table' for itself,
  * by observing whether any gfn->mfn translations are modified.
  */
 static int
-ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
-              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+__ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+                unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
+                ept_entry_t *table, ept_entry_t *old_entry, bool_t *needs_sync)
 {
-    ept_entry_t *table, *ept_entry = NULL;
+    ept_entry_t *ept_entry = NULL;
     unsigned long gfn_remainder = gfn;
     unsigned long offset = 0;
     u32 index;
@@ -288,11 +289,9 @@ ept_set_entry(struct p2m_domain *p2m, un
     int ret = 0;
     bool_t direct_mmio = (p2mt == p2m_mmio_direct);
     uint8_t ipat = 0;
-    int need_modify_vtd_table = 1;
-    int vtd_pte_present = 0;
-    int needs_sync = 1;
+    bool_t need_modify_vtd_table = 1;
+    bool_t vtd_pte_present = 0;
     struct domain *d = p2m->domain;
-    ept_entry_t old_entry = { .epte = 0 };
 
     /*
      * the caller must make sure:
@@ -305,12 +304,6 @@ ept_set_entry(struct p2m_domain *p2m, un
          (order % EPT_TABLE_ORDER) )
         return 0;
 
-    ASSERT((target == 2 && hvm_hap_has_1gb(d)) ||
-           (target == 1 && hvm_hap_has_2mb(d)) ||
-           (target == 0));
-
-    table = map_domain_page(ept_get_asr(d));
-
     for ( i = ept_get_wl(d); i > target; i-- )
     {
         ret = ept_next_level(p2m, 0, &table, &gfn_remainder, i);
@@ -327,7 +320,7 @@ ept_set_entry(struct p2m_domain *p2m, un
 
     ept_entry = table + index;
 
-    /* In case VT-d uses same page table, this flag is needed by VT-d */ 
+    /* In case VT-d uses same page table, this flag is needed by VT-d */
     vtd_pte_present = is_epte_present(ept_entry) ? 1 : 0;
 
     /*
@@ -352,7 +345,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * the intermediate tables will be freed below after the ept flush
          *
          * Read-then-write is OK because we hold the p2m lock. */
-        old_entry = *ept_entry;
+        old_entry->epte = ept_entry->epte;
 
         if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
              (p2mt == p2m_ram_paging_in) )
@@ -369,7 +362,7 @@ ept_set_entry(struct p2m_domain *p2m, un
 
             new_entry.mfn = mfn_x(mfn);
 
-            if ( old_entry.mfn == new_entry.mfn )
+            if ( old_entry->mfn == new_entry.mfn )
                 need_modify_vtd_table = 0;
 
             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
@@ -435,12 +428,7 @@ ept_set_entry(struct p2m_domain *p2m, un
     /* Success */
     rv = 1;
 
-out:
-    unmap_domain_page(table);
-
-    if ( needs_sync )
-        ept_sync_domain(p2m->domain);
-
+ out:
     if ( rv && iommu_enabled && need_iommu(p2m->domain) && need_modify_vtd_table )
     {
         if ( iommu_hap_pt_share )
@@ -473,6 +461,32 @@ out:
         }
     }
 
+    return rv;
+}
+
+static int
+ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
+              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+{
+    ept_entry_t *table;
+    int target = order / EPT_TABLE_ORDER;
+    int rv = 0;
+    bool_t needs_sync = 1;
+    struct domain *d = p2m->domain;
+    ept_entry_t old_entry = { .epte = 0 };
+
+    ASSERT((target == 2 && hvm_hap_has_1gb(d)) ||
+           (target == 1 && hvm_hap_has_2mb(d)) ||
+           (target == 0));
+
+    table = map_domain_page(ept_get_asr(d));
+    rv = __ept_set_entry(p2m, gfn, mfn, order, p2mt, p2ma, table, &old_entry,
+                         &needs_sync);
+    unmap_domain_page(table);
+
+    if ( needs_sync )
+        ept_sync_domain(p2m->domain);
+
     /* Release the old intermediate tables, if any.  This has to be the
        last thing we do, after the ept_sync_domain() and removal
        from the iommu tables, so as to avoid a potential

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:34:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTW5-0006tH-Da; Thu, 26 Apr 2012 18:34:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNTW3-0006t2-Fp
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:34:07 +0000
Received: from [193.109.254.147:15068] by server-5.bemta-14.messagelabs.com id
	1E/A9-30733-E15999F4; Thu, 26 Apr 2012 18:34:06 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335465243!837411!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15517 invoked from network); 26 Apr 2012 18:34:05 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:34:05 -0000
Received: by pbcuo5 with SMTP id uo5so28298pbc.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 11:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=esPy4y7mjErTSNollkaR8PSAIXf6xUK6UmnhgPafkyU=;
	b=Xjy0dC6o6LsD8zYy4WBWR0Fu4rLmNdNdvbsyME09mLQoCTY0/uv4xgizrqO3iQG5I1
	h6R2mNpsoeCBz6xF91Wg5HyIVpX0CB0B3DGzqPmQ2IIDgrGNAIIVbMeLhec/HgWxRrxj
	Em1LWBgt4PBND8PrIc0mBsWMvtbg7LWG24xe4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc:x-gm-message-state;
	bh=esPy4y7mjErTSNollkaR8PSAIXf6xUK6UmnhgPafkyU=;
	b=bSIiOWeOoaap4lYHG05lHtLxZ3Fs3/jOKBluwruwx0w/llEz7FwupFBDhWauDHveow
	JXfb/lrMRZWHtr+gVHbtWwIYISNAE+hZWgXZNPgI8qoegDptdpgbcTSJVZAv8mOpdAI4
	jvpLeCdPsJ1jEQeazLs6MUKJRZbnQxT1X3KmugHFMRGUJTFXSxFNAkoyi7pY61Nu6Tf3
	BVSnqLiaiYp8/rwKBt4XeK5uwhRFviNf64TPiHTeaCfcn2wgqwluFVIoxlyszv59O/Yh
	nonpdKBx5WNcA8gRFTZ3JyJMlYvBJ06zATTPqp1rckV1kHMYlH2M1cv4AOfq4ZGV6way
	CSMw==
Received: by 10.68.216.225 with SMTP id ot1mr17216902pbc.46.1335465243536;
	Thu, 26 Apr 2012 11:34:03 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id ud10sm3982536pbc.25.2012.04.26.11.34.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 11:34:02 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f12cf785738f97260ebff4a97d94df3ebd1b6aec
Message-Id: <f12cf785738f97260ebf.1335465210@vollum>
In-Reply-To: <patchbomb.1335465209@vollum>
References: <patchbomb.1335465209@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Thu, 26 Apr 2012 11:33:30 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnu2e6WWvJIK9RRRLQPplSdeYxSgKlmFFbTHZZom/otWC9SBtnLNAgSusRLuzkQcwXh0Rqo
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Split ept_set_entry()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/p2m-ept.c |  60 ++++++++++++++++++++++++++++------------------
 1 files changed, 37 insertions(+), 23 deletions(-)


Split ept_set_entry() such that mapping and unmapping of the page tables and ept_sync occurrs outside of it.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r 63eb1343cbdb -r f12cf785738f xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:53 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:54 2012 -0700
@@ -272,14 +272,15 @@ static int ept_next_level(struct p2m_dom
 }
 
 /*
- * ept_set_entry() computes 'need_modify_vtd_table' for itself,
+ * __ept_set_entry() computes 'need_modify_vtd_table' for itself,
  * by observing whether any gfn->mfn translations are modified.
  */
 static int
-ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
-              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+__ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+                unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
+                ept_entry_t *table, ept_entry_t *old_entry, bool_t *needs_sync)
 {
-    ept_entry_t *table, *ept_entry = NULL;
+    ept_entry_t *ept_entry = NULL;
     unsigned long gfn_remainder = gfn;
     unsigned long offset = 0;
     u32 index;
@@ -288,11 +289,9 @@ ept_set_entry(struct p2m_domain *p2m, un
     int ret = 0;
     bool_t direct_mmio = (p2mt == p2m_mmio_direct);
     uint8_t ipat = 0;
-    int need_modify_vtd_table = 1;
-    int vtd_pte_present = 0;
-    int needs_sync = 1;
+    bool_t need_modify_vtd_table = 1;
+    bool_t vtd_pte_present = 0;
     struct domain *d = p2m->domain;
-    ept_entry_t old_entry = { .epte = 0 };
 
     /*
      * the caller must make sure:
@@ -305,12 +304,6 @@ ept_set_entry(struct p2m_domain *p2m, un
          (order % EPT_TABLE_ORDER) )
         return 0;
 
-    ASSERT((target == 2 && hvm_hap_has_1gb(d)) ||
-           (target == 1 && hvm_hap_has_2mb(d)) ||
-           (target == 0));
-
-    table = map_domain_page(ept_get_asr(d));
-
     for ( i = ept_get_wl(d); i > target; i-- )
     {
         ret = ept_next_level(p2m, 0, &table, &gfn_remainder, i);
@@ -327,7 +320,7 @@ ept_set_entry(struct p2m_domain *p2m, un
 
     ept_entry = table + index;
 
-    /* In case VT-d uses same page table, this flag is needed by VT-d */ 
+    /* In case VT-d uses same page table, this flag is needed by VT-d */
     vtd_pte_present = is_epte_present(ept_entry) ? 1 : 0;
 
     /*
@@ -352,7 +345,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * the intermediate tables will be freed below after the ept flush
          *
          * Read-then-write is OK because we hold the p2m lock. */
-        old_entry = *ept_entry;
+        old_entry->epte = ept_entry->epte;
 
         if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
              (p2mt == p2m_ram_paging_in) )
@@ -369,7 +362,7 @@ ept_set_entry(struct p2m_domain *p2m, un
 
             new_entry.mfn = mfn_x(mfn);
 
-            if ( old_entry.mfn == new_entry.mfn )
+            if ( old_entry->mfn == new_entry.mfn )
                 need_modify_vtd_table = 0;
 
             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
@@ -435,12 +428,7 @@ ept_set_entry(struct p2m_domain *p2m, un
     /* Success */
     rv = 1;
 
-out:
-    unmap_domain_page(table);
-
-    if ( needs_sync )
-        ept_sync_domain(p2m->domain);
-
+ out:
     if ( rv && iommu_enabled && need_iommu(p2m->domain) && need_modify_vtd_table )
     {
         if ( iommu_hap_pt_share )
@@ -473,6 +461,32 @@ out:
         }
     }
 
+    return rv;
+}
+
+static int
+ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
+              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+{
+    ept_entry_t *table;
+    int target = order / EPT_TABLE_ORDER;
+    int rv = 0;
+    bool_t needs_sync = 1;
+    struct domain *d = p2m->domain;
+    ept_entry_t old_entry = { .epte = 0 };
+
+    ASSERT((target == 2 && hvm_hap_has_1gb(d)) ||
+           (target == 1 && hvm_hap_has_2mb(d)) ||
+           (target == 0));
+
+    table = map_domain_page(ept_get_asr(d));
+    rv = __ept_set_entry(p2m, gfn, mfn, order, p2mt, p2ma, table, &old_entry,
+                         &needs_sync);
+    unmap_domain_page(table);
+
+    if ( needs_sync )
+        ept_sync_domain(p2m->domain);
+
     /* Release the old intermediate tables, if any.  This has to be the
        last thing we do, after the ept_sync_domain() and removal
        from the iommu tables, so as to avoid a potential

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:34:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTW5-0006tP-QL; Thu, 26 Apr 2012 18:34:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNTW4-0006sm-Ah
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:34:08 +0000
Received: from [85.158.143.99:56473] by server-2.bemta-4.messagelabs.com id
	5F/19-17550-025999F4; Thu, 26 Apr 2012 18:34:08 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335465241!19064635!2
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28595 invoked from network); 26 Apr 2012 18:34:06 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:34:06 -0000
Received: by mail-pz0-f41.google.com with SMTP id x4so2234699daj.28
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 11:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=4N7qQoBstkMzDl57GI4+20I8ds2TiHU2t5ROG09P06c=;
	b=wrnXEKVaA/96NIA2z4FAk41mFPZsdKwi5DJ2L0lf6WYyg2fTYJs2X5nZrFa4aCifLD
	NTtAyCVWkuUbavcrQ96BFZp4Qelba56gyoZPMk4EOs04HdzcWhGlLCIl81ejNSHZ98qH
	G9wEMLuBj9VagqWkzZAj0WA/sC9HFXu/6jHzY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc:x-gm-message-state;
	bh=4N7qQoBstkMzDl57GI4+20I8ds2TiHU2t5ROG09P06c=;
	b=TTB50uh4T6gH5XKitmkjz8oTmUpE7G234LLuhjxWe33gyq8y4RTxl++bZSfETpis3c
	hK5nfohZCWGMh7lOvxMByxA7Pdfhi1YrnXzvAbMlO7j2Ov1in7vZzPHeIniWXlUT1xvE
	H7efmb4dOaOER1PP1wVEQURRok82LDrj6OSJn3rtvK1Q1C7sx+A9u3fZhM1bGpZtFx5/
	TIrXf1xQUt9btf0AolMTCmdghfq/IDNpWpJiBSrtlYaj6dR4tZlW5//77flngGKSlmez
	Z5nQrYH8m5Zwc2sR78lxEnL6MYNJls48GwrZNUR0QRMIJZCIHdXDE+czgNRE1YDsB8Q0
	Slug==
Received: by 10.68.226.168 with SMTP id rt8mr17148454pbc.103.1335465245889;
	Thu, 26 Apr 2012 11:34:05 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id ud10sm3982536pbc.25.2012.04.26.11.34.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 11:34:04 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2f695c43ce229ac9488f64e1928b308929ea5e09
Message-Id: <2f695c43ce229ac9488f.1335465211@vollum>
In-Reply-To: <patchbomb.1335465209@vollum>
References: <patchbomb.1335465209@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Thu, 26 Apr 2012 11:33:31 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQldw9ekwaS3V8Z9cAQ7j5X2ZEVOpxmyTX69Oy2mcD7QH1LA9KUTd6roBiLhTzZzsDpNrf6M
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 2] mem_access: Add xc_hvm_mem_access_bulk()
	API
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_misc.c           |  51 ++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h           |  11 +++++++
 xen/arch/x86/hvm/hvm.c          |  45 ++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m-ept.c       |  61 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m-pt.c        |   1 +
 xen/arch/x86/mm/p2m.c           |  36 ++++++++++++++++++++++++
 xen/include/asm-x86/p2m.h       |  18 +++++++++++-
 xen/include/public/hvm/hvm_op.h |  18 ++++++++++++
 8 files changed, 240 insertions(+), 1 deletions(-)


int xc_hvm_set_mem_access_bulk(
    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
    xen_pfn_t *arr, int *err, uint64_t num);

Set the array of guest physical addresses to a specific mem_access type.
Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combination of
HVM_access_ + (rwx), and HVM_access_rx2rw.
When a gfn cannot be set to the specified access, its respective field in
@err is set to the corresponding errno value.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r f12cf785738f -r 2f695c43ce22 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/tools/libxc/xc_misc.c	Thu Apr 26 11:25:50 2012 -0700
@@ -570,6 +570,57 @@ int xc_hvm_set_mem_access(
     return rc;
 }
 
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t mem_access,
+    xen_pfn_t *arr, int *err, uint64_t nr)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_access_bulk, arg);
+    DECLARE_HYPERCALL_BOUNCE(arr, sizeof(xen_pfn_t) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(err, sizeof(int) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    int rc;
+
+    arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+    if ( arg == NULL )
+    {
+        PERROR("Could not allocate memory for xc_hvm_set_mem_access_bulk hypercall");
+        return -1;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, arr) ) {
+        PERROR("Could not bounce arr for xc_hvm_set_mem_access_bulk hypercall");
+        rc = -1;
+        goto out;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, err) ) {
+        PERROR("Could not bounce err for xc_hvm_set_mem_access_bulk hypercall");
+        rc = -1;
+        goto out;
+    }
+
+    arg->domid         = dom;
+    arg->hvmmem_access = mem_access;
+    arg->nr            = nr;
+    set_xen_guest_handle(arg->arr, arr);
+    set_xen_guest_handle(arg->err, err);
+
+    hypercall.op     = __HYPERVISOR_hvm_op;
+    hypercall.arg[0] = HVMOP_set_mem_access_bulk;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+    rc = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, arg);
+    xc_hypercall_bounce_post(xch, arr);
+    xc_hypercall_bounce_post(xch, err);
+
+    return rc;
+}
+
 int xc_hvm_get_mem_access(
     xc_interface *xch, domid_t dom, uint64_t pfn, hvmmem_access_t* mem_access)
 {
diff -r f12cf785738f -r 2f695c43ce22 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Apr 25 19:29:54 2012 -0700
+++ b/tools/libxc/xenctrl.h	Thu Apr 26 11:25:50 2012 -0700
@@ -1568,6 +1568,17 @@ int xc_hvm_set_mem_access(
     xc_interface *xch, domid_t dom, hvmmem_access_t memaccess, uint64_t first_pfn, uint64_t nr);
 
 /*
+ * Set the arry of pfns to a specific access.
+ * When a pfn cannot be set to the specified access, its respective field in
+ * @err is set to the corresponding errno value.
+ * Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combination of
+ * HVM_access_ + (rwx), and HVM_access_rx2rw
+ */
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
+    xen_pfn_t *arr, int *err, uint64_t num);
+
+/*
  * Gets the mem access for the given page (returned in memacess on success)
  */
 int xc_hvm_get_mem_access(
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/hvm/hvm.c	Thu Apr 26 11:25:50 2012 -0700
@@ -4197,6 +4197,51 @@ long do_hvm_op(unsigned long op, XEN_GUE
         break;
     }
 
+    case HVMOP_set_mem_access_bulk:
+    {
+        struct xen_hvm_set_mem_access_bulk a;
+        struct domain *d;
+        xen_pfn_t *arr = 0;
+        int *err = 0;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = -EINVAL;
+
+        if ( !is_hvm_domain(d) )
+            goto param_fail9;
+
+        rc = -ENOMEM;
+        arr = xmalloc_array(xen_pfn_t, a.nr);
+        if (!arr)
+            goto param_fail9;
+
+        err = xmalloc_array(int, a.nr);
+        if (!err)
+            goto param_fail9;
+
+        if ( copy_from_guest(arr, a.arr, a.nr) )
+            goto param_fail9;
+
+        rc = p2m_set_access_bulk(d, arr, err, a.nr, a.hvmmem_access);
+
+        if ( copy_to_guest(a.err, err, a.nr) )
+            goto param_fail9;
+
+    param_fail9:
+        rcu_unlock_domain(d);
+        if (arr)
+            xfree(arr);
+        if (err)
+            xfree(err);
+        break;
+    }
+
     case HVMOP_get_mem_access:
     {
         struct xen_hvm_get_mem_access a;
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 11:25:50 2012 -0700
@@ -597,6 +597,66 @@ out:
     return mfn;
 }
 
+static int
+ept_set_entry_bulk(struct p2m_domain *p2m, xen_pfn_t *arr, int *err,
+                   uint64_t nr, unsigned int order, p2m_access_t p2ma)
+{
+    unsigned long pfn;
+    p2m_access_t a;
+    p2m_type_t t;
+    mfn_t mfn;
+    ept_entry_t *table;
+    int target = order / EPT_TABLE_ORDER;
+    int rc;
+    bool_t needs_sync, bulk_needs_sync = 0;
+    struct domain *d = p2m->domain;
+    ept_entry_t *old_entries = 0;
+
+    ASSERT((target == 2 && hvm_hap_has_1gb(d)) ||
+           (target == 1 && hvm_hap_has_2mb(d)) ||
+           (target == 0));
+
+    old_entries = xzalloc_array(ept_entry_t, nr);
+    if ( !old_entries )
+        return 0;
+
+    memset(err, 0, nr * sizeof(int));
+    table = map_domain_page(ept_get_asr(d));
+    for ( pfn = 0; pfn < nr; pfn++ )
+    {
+        if ( arr[pfn] > domain_get_maximum_gpfn(d) )
+        {
+            err[pfn] = -EINVAL;
+            continue;
+        }
+
+        needs_sync = 1;
+        mfn = ept_get_entry(p2m, arr[pfn], &t, &a, 0, NULL);
+        rc = __ept_set_entry(p2m, arr[pfn], mfn, order, t, p2ma, table,
+                             &old_entries[pfn], &needs_sync);
+        if (rc == 0)
+            err[pfn] = -ENOMEM;
+
+        if ( needs_sync )
+            bulk_needs_sync = 1;
+    }
+    unmap_domain_page(table);
+
+    if ( bulk_needs_sync )
+        ept_sync_domain(p2m->domain);
+
+    /* Release the old intermediate tables, if any.  This has to be the
+       last thing we do, after the ept_sync_domain() and removal
+       from the iommu tables, so as to avoid a potential
+       use-after-free. */
+    for ( pfn = 0; pfn < nr; pfn++ )
+        if ( is_epte_present(&old_entries[pfn]) )
+            ept_free_entry(p2m, &old_entries[pfn], target);
+
+    /* Success */
+    return 1;
+}
+
 /* WARNING: Only caller doesn't care about PoD pages.  So this function will
  * always return 0 for PoD pages, not populate them.  If that becomes necessary,
  * pass a p2m_query_t type along to distinguish. */
@@ -808,6 +868,7 @@ static void ept_change_entry_type_global
 void ept_p2m_init(struct p2m_domain *p2m)
 {
     p2m->set_entry = ept_set_entry;
+    p2m->set_entry_bulk = ept_set_entry_bulk;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
     p2m->audit_p2m = NULL;
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Apr 26 11:25:50 2012 -0700
@@ -1139,6 +1139,7 @@ long p2m_pt_audit_p2m(struct p2m_domain 
 void p2m_pt_init(struct p2m_domain *p2m)
 {
     p2m->set_entry = p2m_set_entry;
+    p2m->set_entry_bulk = NULL;
     p2m->get_entry = p2m_gfn_to_mfn;
     p2m->change_entry_type_global = p2m_change_type_global;
     p2m->write_p2m_entry = paging_write_p2m_entry;
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 26 11:25:50 2012 -0700
@@ -1334,6 +1334,42 @@ int p2m_set_mem_access(struct domain *d,
     return rc;
 }
 
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    p2m_access_t a;
+    p2m_access_t memaccess[] = {
+        p2m_access_n,
+        p2m_access_r,
+        p2m_access_w,
+        p2m_access_rw,
+        p2m_access_x,
+        p2m_access_rx,
+        p2m_access_wx,
+        p2m_access_rwx,
+        p2m_access_rx2rw,
+        p2m_access_n2rwx,
+        p2m->default_access,
+    };
+    int rc = 0;
+
+    ASSERT(p2m->set_entry_bulk);
+
+    if ( (unsigned) access >= HVMMEM_access_default )
+        return -EINVAL;
+
+    a = memaccess[access];
+
+    p2m_lock(p2m);
+    if ( p2m->set_entry_bulk(p2m, arr, err, nr, PAGE_ORDER_4K, a) == 0 )
+        rc = -ENOMEM;
+    p2m_unlock(p2m);
+
+    return rc;
+}
+
+
 /* Get access type for a pfn
  * If pfn == -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn, 
diff -r f12cf785738f -r 2f695c43ce22 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 26 11:25:50 2012 -0700
@@ -232,6 +232,13 @@ struct p2m_domain {
                                        mfn_t mfn, unsigned int page_order,
                                        p2m_type_t p2mt,
                                        p2m_access_t p2ma);
+    int                (*set_entry_bulk)(struct p2m_domain *p2m,
+                                         xen_pfn_t *arr,
+                                         int *err,
+                                         uint64_t nr,
+                                         unsigned int order,
+                                         p2m_access_t p2ma);
+
     mfn_t              (*get_entry   )(struct p2m_domain *p2m,
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,
@@ -568,6 +575,11 @@ void p2m_mem_access_resume(struct domain
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn, 
                        uint32_t nr, hvmmem_access_t access);
 
+/* Set access type for an array of pfns. set_mem_access success or failure is
+ * returned in the err array. */
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access);
+
 /* Get access type for a pfn
  * If pfn == -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn, 
@@ -583,7 +595,11 @@ static inline int p2m_set_mem_access(str
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)
 { return -EINVAL; }
-static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn, 
+static inline int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr,
+                                      int *err, uint64_t nr,
+                                      hvmmem_access_t access)
+{ return -EINVAL; }
+static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
                                      hvmmem_access_t *access)
 { return -EINVAL; }
 #endif
diff -r f12cf785738f -r 2f695c43ce22 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/include/public/hvm/hvm_op.h	Thu Apr 26 11:25:50 2012 -0700
@@ -261,4 +261,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_inject_m
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define HVMOP_set_mem_access_bulk      17
+/* Notify that a array of pfns is to have specific access types */
+struct xen_hvm_set_mem_access_bulk {
+    /* Domain to be updated. */
+    domid_t domid;
+    /* Memory type */
+    uint16_t hvmmem_access; /* hvm_access_t */
+    /* Array of pfns */
+    XEN_GUEST_HANDLE_64(xen_pfn_t) arr;
+    XEN_GUEST_HANDLE_64(int) err ;
+    /* Number of entries */
+    uint64_t nr;
+};
+typedef struct xen_hvm_set_mem_access_bulk xen_hvm_set_mem_access_bulk_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_mem_access_bulk_t);
+#endif
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:34:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTW5-0006tP-QL; Thu, 26 Apr 2012 18:34:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNTW4-0006sm-Ah
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:34:08 +0000
Received: from [85.158.143.99:56473] by server-2.bemta-4.messagelabs.com id
	5F/19-17550-025999F4; Thu, 26 Apr 2012 18:34:08 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335465241!19064635!2
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28595 invoked from network); 26 Apr 2012 18:34:06 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:34:06 -0000
Received: by mail-pz0-f41.google.com with SMTP id x4so2234699daj.28
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 11:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=4N7qQoBstkMzDl57GI4+20I8ds2TiHU2t5ROG09P06c=;
	b=wrnXEKVaA/96NIA2z4FAk41mFPZsdKwi5DJ2L0lf6WYyg2fTYJs2X5nZrFa4aCifLD
	NTtAyCVWkuUbavcrQ96BFZp4Qelba56gyoZPMk4EOs04HdzcWhGlLCIl81ejNSHZ98qH
	G9wEMLuBj9VagqWkzZAj0WA/sC9HFXu/6jHzY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc:x-gm-message-state;
	bh=4N7qQoBstkMzDl57GI4+20I8ds2TiHU2t5ROG09P06c=;
	b=TTB50uh4T6gH5XKitmkjz8oTmUpE7G234LLuhjxWe33gyq8y4RTxl++bZSfETpis3c
	hK5nfohZCWGMh7lOvxMByxA7Pdfhi1YrnXzvAbMlO7j2Ov1in7vZzPHeIniWXlUT1xvE
	H7efmb4dOaOER1PP1wVEQURRok82LDrj6OSJn3rtvK1Q1C7sx+A9u3fZhM1bGpZtFx5/
	TIrXf1xQUt9btf0AolMTCmdghfq/IDNpWpJiBSrtlYaj6dR4tZlW5//77flngGKSlmez
	Z5nQrYH8m5Zwc2sR78lxEnL6MYNJls48GwrZNUR0QRMIJZCIHdXDE+czgNRE1YDsB8Q0
	Slug==
Received: by 10.68.226.168 with SMTP id rt8mr17148454pbc.103.1335465245889;
	Thu, 26 Apr 2012 11:34:05 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id ud10sm3982536pbc.25.2012.04.26.11.34.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 11:34:04 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2f695c43ce229ac9488f64e1928b308929ea5e09
Message-Id: <2f695c43ce229ac9488f.1335465211@vollum>
In-Reply-To: <patchbomb.1335465209@vollum>
References: <patchbomb.1335465209@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Thu, 26 Apr 2012 11:33:31 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQldw9ekwaS3V8Z9cAQ7j5X2ZEVOpxmyTX69Oy2mcD7QH1LA9KUTd6roBiLhTzZzsDpNrf6M
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 2] mem_access: Add xc_hvm_mem_access_bulk()
	API
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_misc.c           |  51 ++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h           |  11 +++++++
 xen/arch/x86/hvm/hvm.c          |  45 ++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m-ept.c       |  61 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m-pt.c        |   1 +
 xen/arch/x86/mm/p2m.c           |  36 ++++++++++++++++++++++++
 xen/include/asm-x86/p2m.h       |  18 +++++++++++-
 xen/include/public/hvm/hvm_op.h |  18 ++++++++++++
 8 files changed, 240 insertions(+), 1 deletions(-)


int xc_hvm_set_mem_access_bulk(
    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
    xen_pfn_t *arr, int *err, uint64_t num);

Set the array of guest physical addresses to a specific mem_access type.
Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combination of
HVM_access_ + (rwx), and HVM_access_rx2rw.
When a gfn cannot be set to the specified access, its respective field in
@err is set to the corresponding errno value.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

diff -r f12cf785738f -r 2f695c43ce22 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/tools/libxc/xc_misc.c	Thu Apr 26 11:25:50 2012 -0700
@@ -570,6 +570,57 @@ int xc_hvm_set_mem_access(
     return rc;
 }
 
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t mem_access,
+    xen_pfn_t *arr, int *err, uint64_t nr)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_access_bulk, arg);
+    DECLARE_HYPERCALL_BOUNCE(arr, sizeof(xen_pfn_t) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(err, sizeof(int) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    int rc;
+
+    arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+    if ( arg == NULL )
+    {
+        PERROR("Could not allocate memory for xc_hvm_set_mem_access_bulk hypercall");
+        return -1;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, arr) ) {
+        PERROR("Could not bounce arr for xc_hvm_set_mem_access_bulk hypercall");
+        rc = -1;
+        goto out;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, err) ) {
+        PERROR("Could not bounce err for xc_hvm_set_mem_access_bulk hypercall");
+        rc = -1;
+        goto out;
+    }
+
+    arg->domid         = dom;
+    arg->hvmmem_access = mem_access;
+    arg->nr            = nr;
+    set_xen_guest_handle(arg->arr, arr);
+    set_xen_guest_handle(arg->err, err);
+
+    hypercall.op     = __HYPERVISOR_hvm_op;
+    hypercall.arg[0] = HVMOP_set_mem_access_bulk;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+    rc = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, arg);
+    xc_hypercall_bounce_post(xch, arr);
+    xc_hypercall_bounce_post(xch, err);
+
+    return rc;
+}
+
 int xc_hvm_get_mem_access(
     xc_interface *xch, domid_t dom, uint64_t pfn, hvmmem_access_t* mem_access)
 {
diff -r f12cf785738f -r 2f695c43ce22 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Apr 25 19:29:54 2012 -0700
+++ b/tools/libxc/xenctrl.h	Thu Apr 26 11:25:50 2012 -0700
@@ -1568,6 +1568,17 @@ int xc_hvm_set_mem_access(
     xc_interface *xch, domid_t dom, hvmmem_access_t memaccess, uint64_t first_pfn, uint64_t nr);
 
 /*
+ * Set the arry of pfns to a specific access.
+ * When a pfn cannot be set to the specified access, its respective field in
+ * @err is set to the corresponding errno value.
+ * Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combination of
+ * HVM_access_ + (rwx), and HVM_access_rx2rw
+ */
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
+    xen_pfn_t *arr, int *err, uint64_t num);
+
+/*
  * Gets the mem access for the given page (returned in memacess on success)
  */
 int xc_hvm_get_mem_access(
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/hvm/hvm.c	Thu Apr 26 11:25:50 2012 -0700
@@ -4197,6 +4197,51 @@ long do_hvm_op(unsigned long op, XEN_GUE
         break;
     }
 
+    case HVMOP_set_mem_access_bulk:
+    {
+        struct xen_hvm_set_mem_access_bulk a;
+        struct domain *d;
+        xen_pfn_t *arr = 0;
+        int *err = 0;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = -EINVAL;
+
+        if ( !is_hvm_domain(d) )
+            goto param_fail9;
+
+        rc = -ENOMEM;
+        arr = xmalloc_array(xen_pfn_t, a.nr);
+        if (!arr)
+            goto param_fail9;
+
+        err = xmalloc_array(int, a.nr);
+        if (!err)
+            goto param_fail9;
+
+        if ( copy_from_guest(arr, a.arr, a.nr) )
+            goto param_fail9;
+
+        rc = p2m_set_access_bulk(d, arr, err, a.nr, a.hvmmem_access);
+
+        if ( copy_to_guest(a.err, err, a.nr) )
+            goto param_fail9;
+
+    param_fail9:
+        rcu_unlock_domain(d);
+        if (arr)
+            xfree(arr);
+        if (err)
+            xfree(err);
+        break;
+    }
+
     case HVMOP_get_mem_access:
     {
         struct xen_hvm_get_mem_access a;
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 11:25:50 2012 -0700
@@ -597,6 +597,66 @@ out:
     return mfn;
 }
 
+static int
+ept_set_entry_bulk(struct p2m_domain *p2m, xen_pfn_t *arr, int *err,
+                   uint64_t nr, unsigned int order, p2m_access_t p2ma)
+{
+    unsigned long pfn;
+    p2m_access_t a;
+    p2m_type_t t;
+    mfn_t mfn;
+    ept_entry_t *table;
+    int target = order / EPT_TABLE_ORDER;
+    int rc;
+    bool_t needs_sync, bulk_needs_sync = 0;
+    struct domain *d = p2m->domain;
+    ept_entry_t *old_entries = 0;
+
+    ASSERT((target == 2 && hvm_hap_has_1gb(d)) ||
+           (target == 1 && hvm_hap_has_2mb(d)) ||
+           (target == 0));
+
+    old_entries = xzalloc_array(ept_entry_t, nr);
+    if ( !old_entries )
+        return 0;
+
+    memset(err, 0, nr * sizeof(int));
+    table = map_domain_page(ept_get_asr(d));
+    for ( pfn = 0; pfn < nr; pfn++ )
+    {
+        if ( arr[pfn] > domain_get_maximum_gpfn(d) )
+        {
+            err[pfn] = -EINVAL;
+            continue;
+        }
+
+        needs_sync = 1;
+        mfn = ept_get_entry(p2m, arr[pfn], &t, &a, 0, NULL);
+        rc = __ept_set_entry(p2m, arr[pfn], mfn, order, t, p2ma, table,
+                             &old_entries[pfn], &needs_sync);
+        if (rc == 0)
+            err[pfn] = -ENOMEM;
+
+        if ( needs_sync )
+            bulk_needs_sync = 1;
+    }
+    unmap_domain_page(table);
+
+    if ( bulk_needs_sync )
+        ept_sync_domain(p2m->domain);
+
+    /* Release the old intermediate tables, if any.  This has to be the
+       last thing we do, after the ept_sync_domain() and removal
+       from the iommu tables, so as to avoid a potential
+       use-after-free. */
+    for ( pfn = 0; pfn < nr; pfn++ )
+        if ( is_epte_present(&old_entries[pfn]) )
+            ept_free_entry(p2m, &old_entries[pfn], target);
+
+    /* Success */
+    return 1;
+}
+
 /* WARNING: Only caller doesn't care about PoD pages.  So this function will
  * always return 0 for PoD pages, not populate them.  If that becomes necessary,
  * pass a p2m_query_t type along to distinguish. */
@@ -808,6 +868,7 @@ static void ept_change_entry_type_global
 void ept_p2m_init(struct p2m_domain *p2m)
 {
     p2m->set_entry = ept_set_entry;
+    p2m->set_entry_bulk = ept_set_entry_bulk;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
     p2m->audit_p2m = NULL;
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Apr 26 11:25:50 2012 -0700
@@ -1139,6 +1139,7 @@ long p2m_pt_audit_p2m(struct p2m_domain 
 void p2m_pt_init(struct p2m_domain *p2m)
 {
     p2m->set_entry = p2m_set_entry;
+    p2m->set_entry_bulk = NULL;
     p2m->get_entry = p2m_gfn_to_mfn;
     p2m->change_entry_type_global = p2m_change_type_global;
     p2m->write_p2m_entry = paging_write_p2m_entry;
diff -r f12cf785738f -r 2f695c43ce22 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 26 11:25:50 2012 -0700
@@ -1334,6 +1334,42 @@ int p2m_set_mem_access(struct domain *d,
     return rc;
 }
 
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    p2m_access_t a;
+    p2m_access_t memaccess[] = {
+        p2m_access_n,
+        p2m_access_r,
+        p2m_access_w,
+        p2m_access_rw,
+        p2m_access_x,
+        p2m_access_rx,
+        p2m_access_wx,
+        p2m_access_rwx,
+        p2m_access_rx2rw,
+        p2m_access_n2rwx,
+        p2m->default_access,
+    };
+    int rc = 0;
+
+    ASSERT(p2m->set_entry_bulk);
+
+    if ( (unsigned) access >= HVMMEM_access_default )
+        return -EINVAL;
+
+    a = memaccess[access];
+
+    p2m_lock(p2m);
+    if ( p2m->set_entry_bulk(p2m, arr, err, nr, PAGE_ORDER_4K, a) == 0 )
+        rc = -ENOMEM;
+    p2m_unlock(p2m);
+
+    return rc;
+}
+
+
 /* Get access type for a pfn
  * If pfn == -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn, 
diff -r f12cf785738f -r 2f695c43ce22 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 26 11:25:50 2012 -0700
@@ -232,6 +232,13 @@ struct p2m_domain {
                                        mfn_t mfn, unsigned int page_order,
                                        p2m_type_t p2mt,
                                        p2m_access_t p2ma);
+    int                (*set_entry_bulk)(struct p2m_domain *p2m,
+                                         xen_pfn_t *arr,
+                                         int *err,
+                                         uint64_t nr,
+                                         unsigned int order,
+                                         p2m_access_t p2ma);
+
     mfn_t              (*get_entry   )(struct p2m_domain *p2m,
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,
@@ -568,6 +575,11 @@ void p2m_mem_access_resume(struct domain
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn, 
                        uint32_t nr, hvmmem_access_t access);
 
+/* Set access type for an array of pfns. set_mem_access success or failure is
+ * returned in the err array. */
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access);
+
 /* Get access type for a pfn
  * If pfn == -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn, 
@@ -583,7 +595,11 @@ static inline int p2m_set_mem_access(str
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)
 { return -EINVAL; }
-static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn, 
+static inline int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr,
+                                      int *err, uint64_t nr,
+                                      hvmmem_access_t access)
+{ return -EINVAL; }
+static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
                                      hvmmem_access_t *access)
 { return -EINVAL; }
 #endif
diff -r f12cf785738f -r 2f695c43ce22 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h	Wed Apr 25 19:29:54 2012 -0700
+++ b/xen/include/public/hvm/hvm_op.h	Thu Apr 26 11:25:50 2012 -0700
@@ -261,4 +261,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_inject_m
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define HVMOP_set_mem_access_bulk      17
+/* Notify that a array of pfns is to have specific access types */
+struct xen_hvm_set_mem_access_bulk {
+    /* Domain to be updated. */
+    domid_t domid;
+    /* Memory type */
+    uint16_t hvmmem_access; /* hvm_access_t */
+    /* Array of pfns */
+    XEN_GUEST_HANDLE_64(xen_pfn_t) arr;
+    XEN_GUEST_HANDLE_64(int) err ;
+    /* Number of entries */
+    uint64_t nr;
+};
+typedef struct xen_hvm_set_mem_access_bulk xen_hvm_set_mem_access_bulk_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_mem_access_bulk_t);
+#endif
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTW2-0006st-0X; Thu, 26 Apr 2012 18:34:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNTW0-0006sm-OE
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:34:04 +0000
Received: from [85.158.143.99:35843] by server-2.bemta-4.messagelabs.com id
	27/19-17550-C15999F4; Thu, 26 Apr 2012 18:34:04 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335465241!19064635!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28188 invoked from network); 26 Apr 2012 18:34:03 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:34:03 -0000
Received: by dajx4 with SMTP id x4so2234699daj.28
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 11:34:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=iy0hqlF9V+9ihPcg1ZVE33srDdXU3VSL2V8kkus2P2U=;
	b=PbGoBr6jfUkH/1WKuJG5ENQ+0cbhrgCn9n5oM1HK6FIvx9V9vHfF+CRtHkTuzmWCoc
	xF0FNYEVrEMqo3LnxpVOybkLxpmfvGmwHDYtZHVepQOUKA3Axhv7T0QuruiU8PS1KBYD
	mX3nhngp4zNYc0ZgB6NyK46P4Bdo0vozc+Ve0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc:x-gm-message-state;
	bh=iy0hqlF9V+9ihPcg1ZVE33srDdXU3VSL2V8kkus2P2U=;
	b=e2LSzp59c03i2bqtoFfG1uXEE37e/j54rfMkk+X4Mp8F2WJ7nsn3eYK8dHj+QW/+Oq
	cCs/0QzqyXExJhZp2EHZ+aHdy2UjbFRIeqeReCLeJhOD2arI7uEpdlE6q1XKoyZcwu2q
	AbnyFiZ4WzAhasmAfr5l5Xbe1C17ZLhgENQoDudqT6khD2XYBN4w4YQckW90M5SxhpX9
	znWt9mpnYpo7btJFCtJH+6DL+v3j5ZaLbZmfhbNSTqaVP1GFSZFHyNPVHeAUGGFkz4XK
	bQz30fSHuSMGYvvOgQpeIohR4DGsBJnsny83RTMmIam9YnfQ9S6ILzcxrUreR+6YJmR5
	bPGA==
Received: by 10.68.227.226 with SMTP id sd2mr5269291pbc.49.1335465241129;
	Thu, 26 Apr 2012 11:34:01 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id ud10sm3982536pbc.25.2012.04.26.11.33.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 11:33:59 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335465209@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Thu, 26 Apr 2012 11:33:29 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnPd39PWmFBPqj3SqeyaxQgT3cfAuD14WPnxpItyDOwml/KBWx1fAUjUF8Ucg1vSxyxxR/m
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access type
 for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the mem_access type needs to be changed for multiple discontiguous gfns, calling xc_hvm_set_mem_access() multiple times does not perform very well. The main pain points are the multiple libxc calls themselves plus the multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() calls for each ept_set_entry(gfn). The following patches adds a new mem_access API that sets the mem_access type for an array of guest physical addresses in one libxc call with minimal map_domain_page() / unmap_domain_page() and ept_sync_domain() calls.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTW2-0006st-0X; Thu, 26 Apr 2012 18:34:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNTW0-0006sm-OE
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 18:34:04 +0000
Received: from [85.158.143.99:35843] by server-2.bemta-4.messagelabs.com id
	27/19-17550-C15999F4; Thu, 26 Apr 2012 18:34:04 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335465241!19064635!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28188 invoked from network); 26 Apr 2012 18:34:03 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:34:03 -0000
Received: by dajx4 with SMTP id x4so2234699daj.28
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 11:34:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=iy0hqlF9V+9ihPcg1ZVE33srDdXU3VSL2V8kkus2P2U=;
	b=PbGoBr6jfUkH/1WKuJG5ENQ+0cbhrgCn9n5oM1HK6FIvx9V9vHfF+CRtHkTuzmWCoc
	xF0FNYEVrEMqo3LnxpVOybkLxpmfvGmwHDYtZHVepQOUKA3Axhv7T0QuruiU8PS1KBYD
	mX3nhngp4zNYc0ZgB6NyK46P4Bdo0vozc+Ve0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc:x-gm-message-state;
	bh=iy0hqlF9V+9ihPcg1ZVE33srDdXU3VSL2V8kkus2P2U=;
	b=e2LSzp59c03i2bqtoFfG1uXEE37e/j54rfMkk+X4Mp8F2WJ7nsn3eYK8dHj+QW/+Oq
	cCs/0QzqyXExJhZp2EHZ+aHdy2UjbFRIeqeReCLeJhOD2arI7uEpdlE6q1XKoyZcwu2q
	AbnyFiZ4WzAhasmAfr5l5Xbe1C17ZLhgENQoDudqT6khD2XYBN4w4YQckW90M5SxhpX9
	znWt9mpnYpo7btJFCtJH+6DL+v3j5ZaLbZmfhbNSTqaVP1GFSZFHyNPVHeAUGGFkz4XK
	bQz30fSHuSMGYvvOgQpeIohR4DGsBJnsny83RTMmIam9YnfQ9S6ILzcxrUreR+6YJmR5
	bPGA==
Received: by 10.68.227.226 with SMTP id sd2mr5269291pbc.49.1335465241129;
	Thu, 26 Apr 2012 11:34:01 -0700 (PDT)
Received: from [127.0.1.1] (c-69-181-20-64.hsd1.ca.comcast.net. [69.181.20.64])
	by mx.google.com with ESMTPS id ud10sm3982536pbc.25.2012.04.26.11.33.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Apr 2012 11:33:59 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335465209@vollum>
User-Agent: Mercurial-patchbomb/2.1.2+14-709924be3d04
Date: Thu, 26 Apr 2012 11:33:29 -0700
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnPd39PWmFBPqj3SqeyaxQgT3cfAuD14WPnxpItyDOwml/KBWx1fAUjUF8Ucg1vSxyxxR/m
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access type
 for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When the mem_access type needs to be changed for multiple discontiguous gfns, calling xc_hvm_set_mem_access() multiple times does not perform very well. The main pain points are the multiple libxc calls themselves plus the multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() calls for each ept_set_entry(gfn). The following patches adds a new mem_access API that sets the mem_access type for an array of guest physical addresses in one libxc call with minimal map_domain_page() / unmap_domain_page() and ept_sync_domain() calls.

Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX5-00074D-88; Thu, 26 Apr 2012 18:35:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX4-00073j-FV
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:10 +0000
Received: from [85.158.139.83:5026] by server-3.bemta-5.messagelabs.com id
	DD/85-25237-D55999F4; Thu, 26 Apr 2012 18:35:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335465307!25669485!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3570 invoked from network); 26 Apr 2012 18:35:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ3Ob028594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2k8027942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ2L4002011; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 83FDE4031C; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:25 -0400
Message-Id: <1335464965-24767-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] xen/acpi: Workaround broken BIOSes
	exporting non-existing C-states.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We did a similar check for the P-states but did not do it for
the C-states. What we want to do is ignore cases where the DSDT
has definition for sixteen CPUs, but the machine only has eight
CPUs and we get:
xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14

Reported-by: Tobias Geiger <tobias.geiger@vido.info>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-acpi-processor.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
index 174b565..0b48579 100644
--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -128,7 +128,10 @@ static int push_cxx_to_hypervisor(struct acpi_processor *_pr)
 			pr_debug("     C%d: %s %d uS\n",
 				 cx->type, cx->desc, (u32)cx->latency);
 		}
-	} else
+	} else if (ret != -EINVAL)
+		/* EINVAL means the ACPI ID is incorrect - meaning the ACPI
+		 * table is referencing a non-existing CPU - which can happen
+		 * with broken ACPI tables. */
 		pr_err(DRV_NAME "(CX): Hypervisor error (%d) for ACPI CPU%u\n",
 		       ret, _pr->acpi_id);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX5-00074D-88; Thu, 26 Apr 2012 18:35:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX4-00073j-FV
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:10 +0000
Received: from [85.158.139.83:5026] by server-3.bemta-5.messagelabs.com id
	DD/85-25237-D55999F4; Thu, 26 Apr 2012 18:35:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335465307!25669485!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3570 invoked from network); 26 Apr 2012 18:35:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ3Ob028594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2k8027942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ2L4002011; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 83FDE4031C; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:25 -0400
Message-Id: <1335464965-24767-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] xen/acpi: Workaround broken BIOSes
	exporting non-existing C-states.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We did a similar check for the P-states but did not do it for
the C-states. What we want to do is ignore cases where the DSDT
has definition for sixteen CPUs, but the machine only has eight
CPUs and we get:
xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14

Reported-by: Tobias Geiger <tobias.geiger@vido.info>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-acpi-processor.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
index 174b565..0b48579 100644
--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -128,7 +128,10 @@ static int push_cxx_to_hypervisor(struct acpi_processor *_pr)
 			pr_debug("     C%d: %s %d uS\n",
 				 cx->type, cx->desc, (u32)cx->latency);
 		}
-	} else
+	} else if (ret != -EINVAL)
+		/* EINVAL means the ACPI ID is incorrect - meaning the ACPI
+		 * table is referencing a non-existing CPU - which can happen
+		 * with broken ACPI tables. */
 		pr_err(DRV_NAME "(CX): Hypervisor error (%d) for ACPI CPU%u\n",
 		       ret, _pr->acpi_id);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX2-00073J-EE; Thu, 26 Apr 2012 18:35:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX1-00072w-BD
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:07 +0000
Received: from [85.158.143.35:5136] by server-2.bemta-4.messagelabs.com id
	07/A9-17550-A55999F4; Thu, 26 Apr 2012 18:35:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335465304!13793401!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22320 invoked from network); 26 Apr 2012 18:35:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:06 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ3tT032479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2Ih027938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ1Qu001956; Thu, 26 Apr 2012 13:35:01 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4B7B840028; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:21 -0400
Message-Id: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH] fixes for v3.4-rc4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Going to ask Linus to pull these patches for 3.4-rc4.

 arch/x86/xen/enlighten.c         |    4 +++-
 arch/x86/xen/smp.c               |   15 +++++++++++++++
 drivers/xen/events.c             |    2 +-
 drivers/xen/xen-acpi-processor.c |    5 ++++-
 4 files changed, 23 insertions(+), 3 deletions(-)

Konrad Rzeszutek Wilk (3):
      xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.
      xen/smp: Fix crash when booting with ACPI hotplug CPUs.
      xen/acpi: Workaround broken BIOSes exporting non-existing C-states.

Stefano Stabellini (1):
      xen: use the pirq number to check the pirq_eoi_map


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX2-00073J-EE; Thu, 26 Apr 2012 18:35:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX1-00072w-BD
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:07 +0000
Received: from [85.158.143.35:5136] by server-2.bemta-4.messagelabs.com id
	07/A9-17550-A55999F4; Thu, 26 Apr 2012 18:35:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335465304!13793401!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22320 invoked from network); 26 Apr 2012 18:35:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:06 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ3tT032479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2Ih027938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ1Qu001956; Thu, 26 Apr 2012 13:35:01 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4B7B840028; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:21 -0400
Message-Id: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH] fixes for v3.4-rc4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Going to ask Linus to pull these patches for 3.4-rc4.

 arch/x86/xen/enlighten.c         |    4 +++-
 arch/x86/xen/smp.c               |   15 +++++++++++++++
 drivers/xen/events.c             |    2 +-
 drivers/xen/xen-acpi-processor.c |    5 ++++-
 4 files changed, 23 insertions(+), 3 deletions(-)

Konrad Rzeszutek Wilk (3):
      xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.
      xen/smp: Fix crash when booting with ACPI hotplug CPUs.
      xen/acpi: Workaround broken BIOSes exporting non-existing C-states.

Stefano Stabellini (1):
      xen: use the pirq number to check the pirq_eoi_map


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX6-00074b-Mg; Thu, 26 Apr 2012 18:35:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX4-00073k-J4
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:10 +0000
Received: from [85.158.138.51:19118] by server-9.bemta-3.messagelabs.com id
	A3/17-26691-D55999F4; Thu, 26 Apr 2012 18:35:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335465307!15048273!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3851 invoked from network); 26 Apr 2012 18:35:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ312028593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:03 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2SM027933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ1Hi024454; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 749E2402FB; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:24 -0400
Message-Id: <1335464965-24767-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] xen/smp: Fix crash when booting with ACPI
	hotplug CPUs.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we boot on a machine that can hotplug CPUs and we
are using 'dom0_max_vcpus=X' on the Xen hypervisor line
to clip the amount of CPUs available to the initial domain,
we get this:

(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
.. snip..
DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
.. snip.
SMP: Allowing 64 CPUs, 32 hotplug CPUs
installing Xen timer for CPU 7
cpu 7 spinlock event irq 361
NMI watchdog: disabled (cpu7): hardware events not enabled
Brought up 8 CPUs
.. snip..
	[acpi processor finds the CPUs are not initialized and starts calling
	arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
CPU 8 got hotplugged
CPU 9 got hotplugged
CPU 10 got hotplugged
.. snip..
initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
calling  erst_init+0x0/0x2bb @ 1

	[and the scheduler sticks newly started tasks on the new CPUs, but
	said CPUs cannot be initialized b/c the hypervisor has limited the
	amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
	The spinlock tries to kick the other CPU, but the structure for that
	is not initialized and we crash.]
BUG: unable to handle kernel paging request at fffffffffffffed8
IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
PGD 180d067 PUD 180e067 PMD 0
Oops: 0002 [#1] SMP
CPU 7
Modules linked in:

Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282

With this patch, we cap the amount of vCPUS that the initial domain
can run, to exactly what dom0_max_vcpus=X has specified.

In the future, if there is a hypercall that will allow a running
domain to expand past its initial set of vCPUS, this patch should
be re-evaluated.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/smp.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..05da787 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -178,6 +178,7 @@ static void __init xen_fill_possible_map(void)
 static void __init xen_filter_cpu_maps(void)
 {
 	int i, rc;
+	unsigned int subtract;
 
 	if (!xen_initial_domain())
 		return;
@@ -192,8 +193,22 @@ static void __init xen_filter_cpu_maps(void)
 		} else {
 			set_cpu_possible(i, false);
 			set_cpu_present(i, false);
+			subtract++;
 		}
 	}
+#ifdef CONFIG_HOTPLUG_CPU
+	/* This is akin to using 'nr_cpus' on the Linux command line.
+	 * Which is OK as when we use 'dom0_max_vcpus=X' we can only
+	 * have up to X, while nr_cpu_ids is greater than X. This
+	 * normally is not a problem, except when CPU hotplugging
+	 * is involved and then there might be more than X CPUs
+	 * in the guest - which will not work as there is no
+	 * hypercall to expand the max number of VCPUs an already
+	 * running guest has. So cap it up to X. */
+	if (subtract)
+		nr_cpu_ids = nr_cpu_ids - subtract;
+#endif
+
 }
 
 static void __init xen_smp_prepare_boot_cpu(void)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX6-00074b-Mg; Thu, 26 Apr 2012 18:35:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX4-00073k-J4
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:10 +0000
Received: from [85.158.138.51:19118] by server-9.bemta-3.messagelabs.com id
	A3/17-26691-D55999F4; Thu, 26 Apr 2012 18:35:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335465307!15048273!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3851 invoked from network); 26 Apr 2012 18:35:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ312028593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:03 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2SM027933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ1Hi024454; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 749E2402FB; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:24 -0400
Message-Id: <1335464965-24767-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] xen/smp: Fix crash when booting with ACPI
	hotplug CPUs.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we boot on a machine that can hotplug CPUs and we
are using 'dom0_max_vcpus=X' on the Xen hypervisor line
to clip the amount of CPUs available to the initial domain,
we get this:

(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
.. snip..
DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
.. snip.
SMP: Allowing 64 CPUs, 32 hotplug CPUs
installing Xen timer for CPU 7
cpu 7 spinlock event irq 361
NMI watchdog: disabled (cpu7): hardware events not enabled
Brought up 8 CPUs
.. snip..
	[acpi processor finds the CPUs are not initialized and starts calling
	arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
CPU 8 got hotplugged
CPU 9 got hotplugged
CPU 10 got hotplugged
.. snip..
initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
calling  erst_init+0x0/0x2bb @ 1

	[and the scheduler sticks newly started tasks on the new CPUs, but
	said CPUs cannot be initialized b/c the hypervisor has limited the
	amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
	The spinlock tries to kick the other CPU, but the structure for that
	is not initialized and we crash.]
BUG: unable to handle kernel paging request at fffffffffffffed8
IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
PGD 180d067 PUD 180e067 PMD 0
Oops: 0002 [#1] SMP
CPU 7
Modules linked in:

Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282

With this patch, we cap the amount of vCPUS that the initial domain
can run, to exactly what dom0_max_vcpus=X has specified.

In the future, if there is a hypercall that will allow a running
domain to expand past its initial set of vCPUS, this patch should
be re-evaluated.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/smp.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac691..05da787 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -178,6 +178,7 @@ static void __init xen_fill_possible_map(void)
 static void __init xen_filter_cpu_maps(void)
 {
 	int i, rc;
+	unsigned int subtract;
 
 	if (!xen_initial_domain())
 		return;
@@ -192,8 +193,22 @@ static void __init xen_filter_cpu_maps(void)
 		} else {
 			set_cpu_possible(i, false);
 			set_cpu_present(i, false);
+			subtract++;
 		}
 	}
+#ifdef CONFIG_HOTPLUG_CPU
+	/* This is akin to using 'nr_cpus' on the Linux command line.
+	 * Which is OK as when we use 'dom0_max_vcpus=X' we can only
+	 * have up to X, while nr_cpu_ids is greater than X. This
+	 * normally is not a problem, except when CPU hotplugging
+	 * is involved and then there might be more than X CPUs
+	 * in the guest - which will not work as there is no
+	 * hypercall to expand the max number of VCPUs an already
+	 * running guest has. So cap it up to X. */
+	if (subtract)
+		nr_cpu_ids = nr_cpu_ids - subtract;
+#endif
+
 }
 
 static void __init xen_smp_prepare_boot_cpu(void)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX2-00073U-Pw; Thu, 26 Apr 2012 18:35:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX1-00072x-Be
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:07 +0000
Received: from [85.158.143.35:35534] by server-3.bemta-4.messagelabs.com id
	28/EA-05853-A55999F4; Thu, 26 Apr 2012 18:35:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335465304!13126687!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 864 invoked from network); 26 Apr 2012 18:35:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ32f032476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2aL010912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ1Zg001978; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 55CB840027; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:22 -0400
Message-Id: <1335464965-24767-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] xen/enlighten: Disable MWAIT_LEAF so that
	acpi-pad won't be loaded.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are exactly four users of __monitor and __mwait:

 - cstate.c (which allows acpi_processor_ffh_cstate_enter to be called
   when the cpuidle API drivers are used. However patch
   "cpuidle: replace xen access to x86 pm_idle and default_idle"
   provides a mechanism to disable the cpuidle and use safe_halt.
 - smpboot (which allows mwait_play_dead to be called). However
   safe_halt is always used so we skip that.
 - intel_idle (same deal as above).
 - acpi_pad.c. This the one that we do not want to run as we
   will hit the below crash.

Why do we want to expose MWAIT_LEAF in the first place?
We want it for the xen-acpi-processor driver - which uploads
C-states to the hypervisor. If MWAIT_LEAF is set, the cstate.c
sets the proper address in the C-states so that the hypervisor
can benefit from using the MWAIT functionality. And that is
the sole reason for using it.

Without this patch, if a module performs mwait or monitor we
get this:

invalid opcode: 0000 [#1] SMP
CPU 2
.. snip..
Pid: 5036, comm: insmod Tainted: G           O 3.4.0-rc2upstream-dirty #2 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffffa000a017>]  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
RSP: e02b:ffff8801c298bf18  EFLAGS: 00010282
RAX: ffff8801c298a010 RBX: ffffffffa03b2000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801c29800d8 RDI: ffff8801ff097200
RBP: ffff8801c298bf18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa000a000 R14: 0000005148db7294 R15: 0000000000000003
FS:  00007fbb364f2700(0000) GS:ffff8801ff08c000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000179f038 CR3: 00000001c9469000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process insmod (pid: 5036, threadinfo ffff8801c298a000, task ffff8801c29cd7e0)
Stack:
 ffff8801c298bf48 ffffffff81002124 ffffffffa03b2000 00000000000081fd
 000000000178f010 000000000178f030 ffff8801c298bf78 ffffffff810c41e6
 00007fff3fb30db9 00007fff3fb30db9 00000000000081fd 0000000000010000
Call Trace:
 [<ffffffff81002124>] do_one_initcall+0x124/0x170
 [<ffffffff810c41e6>] sys_init_module+0xc6/0x220
 [<ffffffff815b15b9>] system_call_fastpath+0x16/0x1b
Code: <0f> 01 c8 31 c0 0f 01 c9 c9 c3 00 00 00 00 00 00 00 00 00 00 00 00
RIP  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
 RSP <ffff8801c298bf18>
---[ end trace 16582fc8a3d1e29a ]---
Kernel panic - not syncing: Fatal exception

With this module (which is what acpi_pad.c would hit):

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("mwait_check_and_back");
MODULE_LICENSE("GPL");
MODULE_VERSION();

static int __init mwait_check_init(void)
{
	__monitor((void *)&current_thread_info()->flags, 0, 0);
	__mwait(0, 0);
	return 0;
}
static void __exit mwait_check_exit(void)
{
}
module_init(mwait_check_init);
module_exit(mwait_check_exit);

Reported-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..407008d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -349,9 +349,11 @@ static void __init xen_init_cpuid_mask(void)
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 	if ((cx & xsave_mask) != xsave_mask)
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
-
+#if !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && \
+    !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
 	if (xen_check_mwait())
 		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
+#endif
 }
 
 static void xen_set_debugreg(int reg, unsigned long val)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX2-00073U-Pw; Thu, 26 Apr 2012 18:35:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX1-00072x-Be
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:07 +0000
Received: from [85.158.143.35:35534] by server-3.bemta-4.messagelabs.com id
	28/EA-05853-A55999F4; Thu, 26 Apr 2012 18:35:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335465304!13126687!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 864 invoked from network); 26 Apr 2012 18:35:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:06 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ32f032476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ2aL010912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ1Zg001978; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 55CB840027; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:22 -0400
Message-Id: <1335464965-24767-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] xen/enlighten: Disable MWAIT_LEAF so that
	acpi-pad won't be loaded.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are exactly four users of __monitor and __mwait:

 - cstate.c (which allows acpi_processor_ffh_cstate_enter to be called
   when the cpuidle API drivers are used. However patch
   "cpuidle: replace xen access to x86 pm_idle and default_idle"
   provides a mechanism to disable the cpuidle and use safe_halt.
 - smpboot (which allows mwait_play_dead to be called). However
   safe_halt is always used so we skip that.
 - intel_idle (same deal as above).
 - acpi_pad.c. This the one that we do not want to run as we
   will hit the below crash.

Why do we want to expose MWAIT_LEAF in the first place?
We want it for the xen-acpi-processor driver - which uploads
C-states to the hypervisor. If MWAIT_LEAF is set, the cstate.c
sets the proper address in the C-states so that the hypervisor
can benefit from using the MWAIT functionality. And that is
the sole reason for using it.

Without this patch, if a module performs mwait or monitor we
get this:

invalid opcode: 0000 [#1] SMP
CPU 2
.. snip..
Pid: 5036, comm: insmod Tainted: G           O 3.4.0-rc2upstream-dirty #2 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffffa000a017>]  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
RSP: e02b:ffff8801c298bf18  EFLAGS: 00010282
RAX: ffff8801c298a010 RBX: ffffffffa03b2000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801c29800d8 RDI: ffff8801ff097200
RBP: ffff8801c298bf18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa000a000 R14: 0000005148db7294 R15: 0000000000000003
FS:  00007fbb364f2700(0000) GS:ffff8801ff08c000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000179f038 CR3: 00000001c9469000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process insmod (pid: 5036, threadinfo ffff8801c298a000, task ffff8801c29cd7e0)
Stack:
 ffff8801c298bf48 ffffffff81002124 ffffffffa03b2000 00000000000081fd
 000000000178f010 000000000178f030 ffff8801c298bf78 ffffffff810c41e6
 00007fff3fb30db9 00007fff3fb30db9 00000000000081fd 0000000000010000
Call Trace:
 [<ffffffff81002124>] do_one_initcall+0x124/0x170
 [<ffffffff810c41e6>] sys_init_module+0xc6/0x220
 [<ffffffff815b15b9>] system_call_fastpath+0x16/0x1b
Code: <0f> 01 c8 31 c0 0f 01 c9 c9 c3 00 00 00 00 00 00 00 00 00 00 00 00
RIP  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
 RSP <ffff8801c298bf18>
---[ end trace 16582fc8a3d1e29a ]---
Kernel panic - not syncing: Fatal exception

With this module (which is what acpi_pad.c would hit):

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("mwait_check_and_back");
MODULE_LICENSE("GPL");
MODULE_VERSION();

static int __init mwait_check_init(void)
{
	__monitor((void *)&current_thread_info()->flags, 0, 0);
	__mwait(0, 0);
	return 0;
}
static void __exit mwait_check_exit(void)
{
}
module_init(mwait_check_init);
module_exit(mwait_check_exit);

Reported-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51beb..407008d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -349,9 +349,11 @@ static void __init xen_init_cpuid_mask(void)
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 	if ((cx & xsave_mask) != xsave_mask)
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
-
+#if !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && \
+    !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
 	if (xen_check_mwait())
 		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
+#endif
 }
 
 static void xen_set_debugreg(int reg, unsigned long val)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX8-00075D-3S; Thu, 26 Apr 2012 18:35:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX6-00074Y-UC
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:13 +0000
Received: from [85.158.143.99:62507] by server-1.bemta-4.messagelabs.com id
	C2/33-20925-065999F4; Thu, 26 Apr 2012 18:35:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335465309!24878220!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12984 invoked from network); 26 Apr 2012 18:35:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ3wQ028600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ21U016293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ2GL001865; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 643F8402D7; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:23 -0400
Message-Id: <1335464965-24767-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/4] xen: use the pirq number to check the
	pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

In pirq_check_eoi_map use the pirq number rather than the Linux irq
number to check whether an eoi is needed in the pirq_eoi_map.

The reason is that the irq number is not always identical to the
pirq number so if we wrongly use the irq number to check the
pirq_eoi_map we are going to check for the wrong pirq to EOI.

As a consequence some interrupts might not be EOI'ed by the
guest correctly.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Tobias Geiger <tobias.geiger@vido.info>
[v1: Added some extra wording to git commit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4b33acd..0a8a17c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 
 static bool pirq_check_eoi_map(unsigned irq)
 {
-	return test_bit(irq, pirq_eoi_map);
+	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
 
 static bool pirq_needs_eoi_flag(unsigned irq)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:35:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTX8-00075D-3S; Thu, 26 Apr 2012 18:35:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNTX6-00074Y-UC
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:35:13 +0000
Received: from [85.158.143.99:62507] by server-1.bemta-4.messagelabs.com id
	C2/33-20925-065999F4; Thu, 26 Apr 2012 18:35:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1335465309!24878220!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12984 invoked from network); 26 Apr 2012 18:35:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 18:35:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QIZ3wQ028600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 18:35:04 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QIZ21U016293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 18:35:02 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QIZ2GL001865; Thu, 26 Apr 2012 13:35:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 11:35:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 643F8402D7; Thu, 26 Apr 2012 14:29:28 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 26 Apr 2012 14:29:23 -0400
Message-Id: <1335464965-24767-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
References: <1335464965-24767-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/4] xen: use the pirq number to check the
	pirq_eoi_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

In pirq_check_eoi_map use the pirq number rather than the Linux irq
number to check whether an eoi is needed in the pirq_eoi_map.

The reason is that the irq number is not always identical to the
pirq number so if we wrongly use the irq number to check the
pirq_eoi_map we are going to check for the wrong pirq to EOI.

As a consequence some interrupts might not be EOI'ed by the
guest correctly.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Tobias Geiger <tobias.geiger@vido.info>
[v1: Added some extra wording to git commit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4b33acd..0a8a17c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 
 static bool pirq_check_eoi_map(unsigned irq)
 {
-	return test_bit(irq, pirq_eoi_map);
+	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
 
 static bool pirq_needs_eoi_flag(unsigned irq)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:44:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTfw-00084p-6p; Thu, 26 Apr 2012 18:44:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SNTfv-00084k-AF
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:44:19 +0000
Received: from [85.158.138.51:65079] by server-6.bemta-3.messagelabs.com id
	C6/F3-05145-287999F4; Thu, 26 Apr 2012 18:44:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335465857!23962329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32490 invoked from network); 26 Apr 2012 18:44:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12164409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 18:44:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 19:44:16 +0100
Received: from spare.cam.xci-test.com ([10.80.2.76]
	helo=qabil.uk.xensource.com)	by norwich.cam.xci-test.com with esmtp
	(Exim
	4.72)	(envelope-from <david.vrabel@citrix.com>)	id 1SNTfs-0001oN-KA;
	Thu, 26 Apr 2012 18:44:16 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Apr 2012 19:44:06 +0100
Message-ID: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: correctly check for pending events when
	restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
called even if no events were pending.  This resulted in (depending on
workload) about a 100 times as many xen_version hypercalls as
necessary.

Fix this by correcting the sense of the conditional jump.

This seems to give a significant performance benefit for some
workloads.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
I'd prefer to do more testing and benchmarking but the gains appear to
be significant.  e.g., lmbench3's 'lat_proc fork' test has improved
from 404 us to 357 us (~11% faster).
---
 arch/x86/xen/xen-asm.S |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
index 79d7362..3e45aa0 100644
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
 
 	/* check for unmasked and pending */
 	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
-	jz 1f
+	jnz 1f
 2:	call check_events
 1:
 ENDPATCH(xen_restore_fl_direct)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 18:44:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 18:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNTfw-00084p-6p; Thu, 26 Apr 2012 18:44:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SNTfv-00084k-AF
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 18:44:19 +0000
Received: from [85.158.138.51:65079] by server-6.bemta-3.messagelabs.com id
	C6/F3-05145-287999F4; Thu, 26 Apr 2012 18:44:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335465857!23962329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32490 invoked from network); 26 Apr 2012 18:44:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 18:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12164409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 18:44:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 19:44:16 +0100
Received: from spare.cam.xci-test.com ([10.80.2.76]
	helo=qabil.uk.xensource.com)	by norwich.cam.xci-test.com with esmtp
	(Exim
	4.72)	(envelope-from <david.vrabel@citrix.com>)	id 1SNTfs-0001oN-KA;
	Thu, 26 Apr 2012 18:44:16 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Apr 2012 19:44:06 +0100
Message-ID: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: correctly check for pending events when
	restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
called even if no events were pending.  This resulted in (depending on
workload) about a 100 times as many xen_version hypercalls as
necessary.

Fix this by correcting the sense of the conditional jump.

This seems to give a significant performance benefit for some
workloads.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
I'd prefer to do more testing and benchmarking but the gains appear to
be significant.  e.g., lmbench3's 'lat_proc fork' test has improved
from 404 us to 357 us (~11% faster).
---
 arch/x86/xen/xen-asm.S |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
index 79d7362..3e45aa0 100644
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
 
 	/* check for unmasked and pending */
 	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
-	jz 1f
+	jnz 1f
 2:	call check_events
 1:
 ENDPATCH(xen_restore_fl_direct)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 19:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 19:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNU7e-0008Im-Oi; Thu, 26 Apr 2012 19:12:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNU7d-0008Ih-AT
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 19:12:57 +0000
Received: from [85.158.138.51:33259] by server-3.bemta-3.messagelabs.com id
	5E/17-04048-83E999F4; Thu, 26 Apr 2012 19:12:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335467575!23859500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3338 invoked from network); 26 Apr 2012 19:12:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 19:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12164645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 19:12:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 20:12:53 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNU7Z-00026F-9Z;
	Thu, 26 Apr 2012 19:12:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNU7Z-0007R4-8M;
	Thu, 26 Apr 2012 20:12:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12757-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 20:12:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12757: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12757 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12757/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12742
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 12752
 test-i386-i386-xl             5 xen-boot                    fail pass in 12752
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-amd64-amd64-pv           5 xen-boot                    fail pass in 12752
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12742 pass in 12757
 test-i386-i386-pair   4 host-install/dst_host(4) broken in 12742 pass in 12757

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12742 never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 19:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 19:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNU7e-0008Im-Oi; Thu, 26 Apr 2012 19:12:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNU7d-0008Ih-AT
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 19:12:57 +0000
Received: from [85.158.138.51:33259] by server-3.bemta-3.messagelabs.com id
	5E/17-04048-83E999F4; Thu, 26 Apr 2012 19:12:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335467575!23859500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQ5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3338 invoked from network); 26 Apr 2012 19:12:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 19:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="12164645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Apr 2012 19:12:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Apr 2012 20:12:53 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNU7Z-00026F-9Z;
	Thu, 26 Apr 2012 19:12:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNU7Z-0007R4-8M;
	Thu, 26 Apr 2012 20:12:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12757-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Apr 2012 20:12:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12757: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12757 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12757/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12742
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 12752
 test-i386-i386-xl             5 xen-boot                    fail pass in 12752
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-amd64-amd64-pv           5 xen-boot                    fail pass in 12752
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12742 pass in 12757
 test-i386-i386-pair   4 host-install/dst_host(4) broken in 12742 pass in 12757

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12742 never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 19:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 19:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNUoZ-0000Cv-Pv; Thu, 26 Apr 2012 19:57:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNUoY-0000Cq-47
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 19:57:18 +0000
Received: from [85.158.139.83:5941] by server-12.bemta-5.messagelabs.com id
	02/0E-01344-D98A99F4; Thu, 26 Apr 2012 19:57:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335470236!18332308!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16598 invoked from network); 26 Apr 2012 19:57:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 19:57:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNUoS-000JTy-TG; Thu, 26 Apr 2012 19:57:12 +0000
Date: Thu, 26 Apr 2012 20:57:12 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120426195712.GG67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
	<20120426111848.34e43e75@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120426111848.34e43e75@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:18 -0700 on 26 Apr (1335439128), Mukesh Rathor wrote:
> On Thu, 26 Apr 2012 10:08:47 +0100
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 16:06 -0700 on 24 Apr (1335283603), Mukesh Rathor wrote:
> > > On Tue, 24 Apr 2012 10:36:26 +0100
> > > Tim Deegan <tim@xen.org> wrote:
> > > 
> > > > At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > > > > On Thu, 19 Apr 2012 15:15:27 +0100
> > > > > Tim Deegan <tim@xen.org> wrote:
> > > 
> > > >you still have this mapping.  You should take a PGT_writeable_page
> > > >typecount, too, if the foreign domain isn't in paging_mode_external
> > > 
> > > Ok, I've it as:
> > >     if (paging_mode_external(fdom)) {
> > >         if (get_page_from_pagenr(mfn, fdom) == 0)
> > > 	    failed = 1;
> > >     } else {
> > >         if (get_page_and_type_from_pagenr(mfn, PGT_writable_page,
> > > fdom,0,0)) failed = 1;
> > >     }
> > > 
> > > But then later fails when it tries to pin the page,
> > > MMUEXT_PIN_L4_TABLE, from the lib at:
> > 
> > What's trying to pin an l4 table?  I thought your hybrid dom0 didn't
> > use the PV MMU.
> > 
> > Tim.
> 
> Right, hybrid doesn't use PV mmu. 
> Here, xl/xc is building a pv guest while running on *hybrid* dom0. 

Oh, I see.  This is the domU's L4.  In that case I suspect that what's
missing is the translation from GFNs to MFNs in the domU. 

To do that, we may finally have to reintroduce the dreaded 'tell me what
MFN backs this domU GFN' call, so the dom0 tools can build proper
pagetables and p2m for the pv domU.  Or have you already taken care of
that?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 19:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 19:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNUoZ-0000Cv-Pv; Thu, 26 Apr 2012 19:57:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNUoY-0000Cq-47
	for Xen-devel@lists.xensource.com; Thu, 26 Apr 2012 19:57:18 +0000
Received: from [85.158.139.83:5941] by server-12.bemta-5.messagelabs.com id
	02/0E-01344-D98A99F4; Thu, 26 Apr 2012 19:57:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335470236!18332308!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16598 invoked from network); 26 Apr 2012 19:57:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 19:57:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNUoS-000JTy-TG; Thu, 26 Apr 2012 19:57:12 +0000
Date: Thu, 26 Apr 2012 20:57:12 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120426195712.GG67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
	<20120426111848.34e43e75@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120426111848.34e43e75@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:18 -0700 on 26 Apr (1335439128), Mukesh Rathor wrote:
> On Thu, 26 Apr 2012 10:08:47 +0100
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 16:06 -0700 on 24 Apr (1335283603), Mukesh Rathor wrote:
> > > On Tue, 24 Apr 2012 10:36:26 +0100
> > > Tim Deegan <tim@xen.org> wrote:
> > > 
> > > > At 18:37 -0700 on 23 Apr (1335206229), Mukesh Rathor wrote:
> > > > > On Thu, 19 Apr 2012 15:15:27 +0100
> > > > > Tim Deegan <tim@xen.org> wrote:
> > > 
> > > >you still have this mapping.  You should take a PGT_writeable_page
> > > >typecount, too, if the foreign domain isn't in paging_mode_external
> > > 
> > > Ok, I've it as:
> > >     if (paging_mode_external(fdom)) {
> > >         if (get_page_from_pagenr(mfn, fdom) == 0)
> > > 	    failed = 1;
> > >     } else {
> > >         if (get_page_and_type_from_pagenr(mfn, PGT_writable_page,
> > > fdom,0,0)) failed = 1;
> > >     }
> > > 
> > > But then later fails when it tries to pin the page,
> > > MMUEXT_PIN_L4_TABLE, from the lib at:
> > 
> > What's trying to pin an l4 table?  I thought your hybrid dom0 didn't
> > use the PV MMU.
> > 
> > Tim.
> 
> Right, hybrid doesn't use PV mmu. 
> Here, xl/xc is building a pv guest while running on *hybrid* dom0. 

Oh, I see.  This is the domU's L4.  In that case I suspect that what's
missing is the translation from GFNs to MFNs in the domU. 

To do that, we may finally have to reintroduce the dreaded 'tell me what
MFN backs this domU GFN' call, so the dom0 tools can build proper
pagetables and p2m for the pv domU.  Or have you already taken care of
that?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNV4e-0000TI-CV; Thu, 26 Apr 2012 20:13:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNV4c-0000TD-Ah
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 20:13:54 +0000
Received: from [193.109.254.147:9002] by server-4.bemta-14.messagelabs.com id
	C1/5B-11570-18CA99F4; Thu, 26 Apr 2012 20:13:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335471231!4063350!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12974 invoked from network); 26 Apr 2012 20:13:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 20:13:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKDnWJ005551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:13:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKDmbb013350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:13:49 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKDmFC027111; Thu, 26 Apr 2012 15:13:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:13:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8EAE1402FB; Thu, 26 Apr 2012 16:08:14 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:08:14 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120426200814.GA1130@phenom.dumpdata.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 07:44:06PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> called even if no events were pending.  This resulted in (depending on
> workload) about a 100 times as many xen_version hypercalls as
> necessary.
> 
> Fix this by correcting the sense of the conditional jump.
> 
> This seems to give a significant performance benefit for some
> workloads.
> 

Will put stable@kernel.org here as well.

Thx!
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> I'd prefer to do more testing and benchmarking but the gains appear to
> be significant.  e.g., lmbench3's 'lat_proc fork' test has improved
> from 404 us to 357 us (~11% faster).
> ---
>  arch/x86/xen/xen-asm.S |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> index 79d7362..3e45aa0 100644
> --- a/arch/x86/xen/xen-asm.S
> +++ b/arch/x86/xen/xen-asm.S
> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>  
>  	/* check for unmasked and pending */
>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> -	jz 1f
> +	jnz 1f
>  2:	call check_events
>  1:
>  ENDPATCH(xen_restore_fl_direct)
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNV4e-0000TI-CV; Thu, 26 Apr 2012 20:13:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNV4c-0000TD-Ah
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 20:13:54 +0000
Received: from [193.109.254.147:9002] by server-4.bemta-14.messagelabs.com id
	C1/5B-11570-18CA99F4; Thu, 26 Apr 2012 20:13:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335471231!4063350!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12974 invoked from network); 26 Apr 2012 20:13:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 20:13:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKDnWJ005551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:13:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKDmbb013350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:13:49 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKDmFC027111; Thu, 26 Apr 2012 15:13:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:13:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8EAE1402FB; Thu, 26 Apr 2012 16:08:14 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:08:14 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120426200814.GA1130@phenom.dumpdata.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 07:44:06PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> called even if no events were pending.  This resulted in (depending on
> workload) about a 100 times as many xen_version hypercalls as
> necessary.
> 
> Fix this by correcting the sense of the conditional jump.
> 
> This seems to give a significant performance benefit for some
> workloads.
> 

Will put stable@kernel.org here as well.

Thx!
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> I'd prefer to do more testing and benchmarking but the gains appear to
> be significant.  e.g., lmbench3's 'lat_proc fork' test has improved
> from 404 us to 357 us (~11% faster).
> ---
>  arch/x86/xen/xen-asm.S |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> index 79d7362..3e45aa0 100644
> --- a/arch/x86/xen/xen-asm.S
> +++ b/arch/x86/xen/xen-asm.S
> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>  
>  	/* check for unmasked and pending */
>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> -	jz 1f
> +	jnz 1f
>  2:	call check_events
>  1:
>  ENDPATCH(xen_restore_fl_direct)
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVAa-0000bW-6y; Thu, 26 Apr 2012 20:20:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christian.limpach@gmail.com>) id 1SNVAY-0000bR-VK
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 20:20:03 +0000
Received: from [85.158.139.83:19626] by server-10.bemta-5.messagelabs.com id
	F7/A0-08260-2FDA99F4; Thu, 26 Apr 2012 20:20:02 +0000
X-Env-Sender: christian.limpach@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335471600!22971493!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3495 invoked from network); 26 Apr 2012 20:20:01 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 20:20:01 -0000
Received: by qcsc20 with SMTP id c20so7336qcs.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 13:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:content-transfer-encoding;
	bh=x9tDxD974RczXIh6/8CLVsZbF9wCrreGh4MbikHFLSI=;
	b=ZUCApsEPpXQlS+fiRQgL/Aoj+h+yP5Eu9wbdQZmTb93S4+onMysDhTXAsJbBMpRRQP
	QvcmZt2tz/RM9NcRKBBPLfIhYsCop5Wk6jvv1X26M+fmvnRWQE69VQKc9lE0RvwImJl3
	xuQQuKh52cpfmuYjhdCjHbzSxstQa922HwbcDan0nDJhaPLwh3tlknwrtRwjDQI4ZqjQ
	97qcTyDAb3M0OWSCzeOBZPL1gyS31n5Jqrct9OSBmhO5y+u1ysxMBC5jNYNoGVzRlB77
	WtsnSAj6LN6uY2TyxdKvVjfKEsSpqb0U7575fY5ZfKnnL29Fp3U3FU554Hxr8Nec56/D
	xgzA==
MIME-Version: 1.0
Received: by 10.224.34.9 with SMTP id j9mr5601735qad.14.1335471600380; Thu, 26
	Apr 2012 13:20:00 -0700 (PDT)
Received: by 10.229.184.11 with HTTP; Thu, 26 Apr 2012 13:20:00 -0700 (PDT)
In-Reply-To: <patchbomb.1335465209@vollum>
References: <patchbomb.1335465209@vollum>
Date: Thu, 26 Apr 2012 13:20:00 -0700
Message-ID: <CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
From: Christian Limpach <christian.limpach@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Christian.Limpach@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 11:33 AM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> When the mem_access type needs to be changed for multiple discontiguous gfns, calling xc_hvm_set_mem_access() multiple times does not perform very well. The main pain points are the multiple libxc calls themselves plus the multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() calls for each ept_set_entry(gfn). The following patches adds a new mem_access API that sets the mem_access type for an array of guest physical addresses in one libxc call with minimal map_domain_page() / unmap_domain_page() and ept_sync_domain() calls.


Are you sure that your bulk code actually works?  It seems to me that
your __ept_set_entry function assumes that table still points to the
top of the p2m.  The "for ( i = ept_get_wl(d); i > target; i-- )" loop
will walk the table, and so in the subsequent calls from your bulk
loop, this won't work?

I think you need something like an iterator, the context of which can
be passed around...

Also, the call to ept_get_entry in your bulk loop will do a walk in
every iteration, it seems a bit arbitrary to only (try to) avoid one
and not the other.  But I guess the "win" is from reducing the number
of ept_sync_domain calls.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVAa-0000bW-6y; Thu, 26 Apr 2012 20:20:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christian.limpach@gmail.com>) id 1SNVAY-0000bR-VK
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 20:20:03 +0000
Received: from [85.158.139.83:19626] by server-10.bemta-5.messagelabs.com id
	F7/A0-08260-2FDA99F4; Thu, 26 Apr 2012 20:20:02 +0000
X-Env-Sender: christian.limpach@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335471600!22971493!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3495 invoked from network); 26 Apr 2012 20:20:01 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 20:20:01 -0000
Received: by qcsc20 with SMTP id c20so7336qcs.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 13:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:content-transfer-encoding;
	bh=x9tDxD974RczXIh6/8CLVsZbF9wCrreGh4MbikHFLSI=;
	b=ZUCApsEPpXQlS+fiRQgL/Aoj+h+yP5Eu9wbdQZmTb93S4+onMysDhTXAsJbBMpRRQP
	QvcmZt2tz/RM9NcRKBBPLfIhYsCop5Wk6jvv1X26M+fmvnRWQE69VQKc9lE0RvwImJl3
	xuQQuKh52cpfmuYjhdCjHbzSxstQa922HwbcDan0nDJhaPLwh3tlknwrtRwjDQI4ZqjQ
	97qcTyDAb3M0OWSCzeOBZPL1gyS31n5Jqrct9OSBmhO5y+u1ysxMBC5jNYNoGVzRlB77
	WtsnSAj6LN6uY2TyxdKvVjfKEsSpqb0U7575fY5ZfKnnL29Fp3U3FU554Hxr8Nec56/D
	xgzA==
MIME-Version: 1.0
Received: by 10.224.34.9 with SMTP id j9mr5601735qad.14.1335471600380; Thu, 26
	Apr 2012 13:20:00 -0700 (PDT)
Received: by 10.229.184.11 with HTTP; Thu, 26 Apr 2012 13:20:00 -0700 (PDT)
In-Reply-To: <patchbomb.1335465209@vollum>
References: <patchbomb.1335465209@vollum>
Date: Thu, 26 Apr 2012 13:20:00 -0700
Message-ID: <CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
From: Christian Limpach <christian.limpach@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Christian.Limpach@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 11:33 AM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> When the mem_access type needs to be changed for multiple discontiguous gfns, calling xc_hvm_set_mem_access() multiple times does not perform very well. The main pain points are the multiple libxc calls themselves plus the multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() calls for each ept_set_entry(gfn). The following patches adds a new mem_access API that sets the mem_access type for an array of guest physical addresses in one libxc call with minimal map_domain_page() / unmap_domain_page() and ept_sync_domain() calls.


Are you sure that your bulk code actually works?  It seems to me that
your __ept_set_entry function assumes that table still points to the
top of the p2m.  The "for ( i = ept_get_wl(d); i > target; i-- )" loop
will walk the table, and so in the subsequent calls from your bulk
loop, this won't work?

I think you need something like an iterator, the context of which can
be passed around...

Also, the call to ept_get_entry in your bulk loop will do a walk in
every iteration, it seems a bit arbitrary to only (try to) avoid one
and not the other.  But I guess the "win" is from reducing the number
of ept_sync_domain calls.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVeC-0000pC-Nf; Thu, 26 Apr 2012 20:50:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNVeB-0000p7-HC
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 20:50:39 +0000
Received: from [193.109.254.147:52823] by server-7.bemta-14.messagelabs.com id
	AB/0C-01627-E15B99F4; Thu, 26 Apr 2012 20:50:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335473434!849524!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7802 invoked from network); 26 Apr 2012 20:50:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 20:50:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKoQPZ000424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:50:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKoOTD000904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:50:25 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKoOgb029554; Thu, 26 Apr 2012 15:50:24 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:50:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 513F2402FB; Thu, 26 Apr 2012 16:44:50 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:44:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120426204450.GA7392@phenom.dumpdata.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-6-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334067984-7706-6-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	=?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= <mirq-linux@rere.qmqm.pl>,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 06/10] net: add support for
 per-paged-fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBBcHIgMTAsIDIwMTIgYXQgMDM6MjY6MjBQTSArMDEwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IEVudGl0aWVzIHdoaWNoIGNhcmUgYWJvdXQgdGhlIGNvbXBsZXRlIGxpZmVjeWNsZSBv
ZiBwYWdlcyB3aGljaCB0aGV5IGluamVjdAo+IGludG8gdGhlIG5ldHdvcmsgc3RhY2sgdmlhIGFu
IHNrYiBwYWdlZCBmcmFnbWVudCBjYW4gY2hvb3NlIHRvIHNldCB0aGlzCj4gZGVzdHJ1Y3RvciBp
biBvcmRlciB0byByZWNlaXZlIGEgY2FsbGJhY2sgd2hlbiB0aGUgc3RhY2sgaXMgcmVhbGx5IGZp
bmlzaGVkCj4gd2l0aCBhIHBhZ2UgKGluY2x1ZGluZyBhbGwgY2xvbmVzLCByZXRyYW5zbWl0cywg
cHVsbC11cHMgZXRjIGV0YykuCj4gCj4gVGhpcyBkZXN0cnVjdG9yIHdpbGwgYWx3YXlzIGJlIHBy
b3BhZ2F0ZWQgYWxvbmdzaWRlIHRoZSBzdHJ1Y3QgcGFnZSB3aGVuCj4gY29weWluZyBza2JfZnJh
Z190LT5wYWdlLiBUaGlzIGlzIHRoZSByZWFzb24gSSBjaG9zZSB0byBlbWJlZCB0aGUgZGVzdHJ1
Y3RvciBpbgo+IGEgInN0cnVjdCB7IH0gcGFnZSIgd2l0aGluIHRoZSBza2JfZnJhZ190LCByYXRo
ZXIgdGhhbiBhcyBhIHNlcGFyYXRlIGZpZWxkLAo+IHNpbmNlIGl0IGFsbG93cyBleGlzdGluZyBj
b2RlIHdoaWNoIHByb3BhZ2F0ZXMgLT5mcmFnc1tOXS5wYWdlIHRvIEp1c3QKPiBXb3JrKHRtKS4K
PiAKPiBXaGVuIHRoZSBkZXN0cnVjdG9yIGlzIHByZXNlbnQgdGhlIHBhZ2UgcmVmZXJlbmNlIGNv
dW50aW5nIGlzIGRvbmUgc2xpZ2h0bHkKPiBkaWZmZXJlbnRseS4gTm8gcmVmZXJlbmNlcyBhcmUg
aGVsZCBieSB0aGUgbmV0d29yayBzdGFjayBvbiB0aGUgc3RydWN0IHBhZ2UgKGl0Cj4gaXMgdXAg
dG8gdGhlIGNhbGxlciB0byBtYW5hZ2UgdGhpcyBhcyBuZWNlc3NhcnkpIGluc3RlYWQgdGhlIG5l
dHdvcmsgc3RhY2sgd2lsbAo+IHRyYWNrIHJlZmVyZW5jZXMgdmlhIHRoZSBjb3VudCBlbWJlZGRl
ZCBpbiB0aGUgZGVzdHJ1Y3RvciBzdHJ1Y3R1cmUuIFdoZW4gdGhpcwo+IHJlZmVyZW5jZSBjb3Vu
dCByZWFjaGVzIHplcm8gdGhlbiB0aGUgZGVzdHJ1Y3RvciB3aWxsIGJlIGNhbGxlZCBhbmQgdGhl
IGNhbGxlcgo+IGNhbiB0YWtlIHRoZSBuZWNlc2FyeSBzdGVwcyB0byByZWxlYXNlIHRoZSBwYWdl
IChpLmUuIHJlbGVhc2UgdGhlIHN0cnVjdCBwYWdlCj4gcmVmZXJlbmNlIGl0c2VsZikuCj4gCj4g
VGhlIGludGVudGlvbiBpcyB0aGF0IGNhbGxlcnMgY2FuIHVzZSB0aGlzIGNhbGxiYWNrIHRvIGRl
bGF5IGNvbXBsZXRpb24gdG8KPiBfdGhlaXJfIGNhbGxlcnMgdW50aWwgdGhlIG5ldHdvcmsgc3Rh
Y2sgaGFzIGNvbXBsZXRlbHkgcmVsZWFzZWQgdGhlIHBhZ2UsIGluCj4gb3JkZXIgdG8gcHJldmVu
dCB1c2UtYWZ0ZXItZnJlZSBvciBtb2RpZmljYXRpb24gb2YgZGF0YSBwYWdlcyB3aGljaCBhcmUg
c3RpbGwKPiBpbiB1c2UgYnkgdGhlIHN0YWNrLgo+IAo+IEl0IGlzIGFsbG93YWJsZSAoaW5kZWVk
IGV4cGVjdGVkKSBmb3IgYSBjYWxsZXIgdG8gc2hhcmUgYSBzaW5nbGUgZGVzdHJ1Y3Rvcgo+IGlu
c3RhbmNlIGJldHdlZW4gbXVsdGlwbGUgcGFnZXMgaW5qZWN0ZWQgaW50byB0aGUgc3RhY2sgZS5n
LiBhIGdyb3VwIG9mIHBhZ2VzCj4gaW5jbHVkZWQgaW4gYSBzaW5nbGUgaGlnaGVyIGxldmVsIG9w
ZXJhdGlvbiBtaWdodCBzaGFyZSBhIGRlc3RydWN0b3Igd2hpY2ggaXMKPiB1c2VkIHRvIGNvbXBs
ZXRlIHRoYXQgaGlnaGVyIGxldmVsIG9wZXJhdGlvbi4KPiAKPiBXaXRoIHRoaXMgY2hhbmdlIGFu
ZCB0aGUgcHJldmlvdXMgdHdvIGNoYW5nZXMgdG8gc2hpbmZvIGFsaWdubWVudCBhbmQgZmllbGQK
PiBvcmRlcnJpbmcgaXQgaXMgbm93IHRoZSBjYXNlIHR5aGF0IG9uIGEgNjQgYml0IHN5c3RlbSB3
aXRoIDY0IGJ5dGUgY2FjaGUgbGluZXMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5e
Xl4gLSB0aGF0LgoKPiBldmVyeXRoaW5nIGZyb20gbnJfZnJhZ3MgdW50aWwgdGhlIGVuZCBvZiBm
cmFnc1swXSBpcyBvbiB0aGUgc2FtZSBjYWNoZWxpbmUuCj4gCj4gU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiBDYzogIkRhdmlkIFMuIE1pbGxl
ciIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+Cj4gQ2M6IEVyaWMgRHVtYXpldCA8ZXJpYy5kdW1hemV0
QGdtYWlsLmNvbT4KPiBDYzogIk1pY2hhxYIgTWlyb3PFgmF3IiA8bWlycS1saW51eEByZXJlLnFt
cW0ucGw+Cj4gQ2M6IG5ldGRldkB2Z2VyLmtlcm5lbC5vcmcKPiAtLS0KPiAgaW5jbHVkZS9saW51
eC9za2J1ZmYuaCB8ICAgNDMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKwo+ICBuZXQvY29yZS9za2J1ZmYuYyAgICAgIHwgICAxNyArKysrKysrKysrKysrKysrKwo+
ICAyIGZpbGVzIGNoYW5nZWQsIDYwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCj4gCj4g
ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvc2tidWZmLmggYi9pbmNsdWRlL2xpbnV4L3NrYnVm
Zi5oCj4gaW5kZXggZjBhZTM5Yy4uNmFjMjgzZSAxMDA2NDQKPiAtLS0gYS9pbmNsdWRlL2xpbnV4
L3NrYnVmZi5oCj4gKysrIGIvaW5jbHVkZS9saW51eC9za2J1ZmYuaAo+IEBAIC0xNjYsOSArMTY2
LDE1IEBAIHN0cnVjdCBza19idWZmOwo+ICAKPiAgdHlwZWRlZiBzdHJ1Y3Qgc2tiX2ZyYWdfc3Ry
dWN0IHNrYl9mcmFnX3Q7Cj4gIAo+ICtzdHJ1Y3Qgc2tiX2ZyYWdfZGVzdHJ1Y3RvciB7Cj4gKwlh
dG9taWNfdCByZWY7Cj4gKwlpbnQgKCpkZXN0cm95KShzdHJ1Y3Qgc2tiX2ZyYWdfZGVzdHJ1Y3Rv
ciAqZGVzdHJ1Y3Rvcik7Cj4gK307Cj4gKwo+ICBzdHJ1Y3Qgc2tiX2ZyYWdfc3RydWN0IHsKPiAg
CXN0cnVjdCB7Cj4gIAkJc3RydWN0IHBhZ2UgKnA7Cj4gKwkJc3RydWN0IHNrYl9mcmFnX2Rlc3Ry
dWN0b3IgKmRlc3RydWN0b3I7Cj4gIAl9IHBhZ2U7Cj4gICNpZiAoQklUU19QRVJfTE9ORyA+IDMy
KSB8fCAoUEFHRV9TSVpFID49IDY1NTM2KQo+ICAJX191MzIgcGFnZV9vZmZzZXQ7Cj4gQEAgLTEy
MjEsNiArMTIyNywzMSBAQCBzdGF0aWMgaW5saW5lIGludCBza2JfcGFnZWxlbihjb25zdCBzdHJ1
Y3Qgc2tfYnVmZiAqc2tiKQo+ICB9Cj4gIAo+ICAvKioKPiArICogc2tiX2ZyYWdfc2V0X2Rlc3Ry
dWN0b3IgLSBzZXQgZGVzdHJ1Y3RvciBmb3IgYSBwYWdlZCBmcmFnbWVudAo+ICsgKiBAc2tiOiBi
dWZmZXIgY29udGFpbmluZyBmcmFnbWVudCB0byBiZSBpbml0aWFsaXNlZAo+ICsgKiBAaTogcGFn
ZWQgZnJhZ21lbnQgaW5kZXggdG8gaW5pdGlhbGlzZQo+ICsgKiBAZGVzdHJveTogdGhlIGRlc3Ry
dWN0b3IgdG8gdXNlIGZvciB0aGlzIGZyYWdtZW50Cj4gKyAqCj4gKyAqIFNldHMgQGRlc3Ryb3kg
YXMgdGhlIGRlc3RydWN0b3IgdG8gYmUgY2FsbGVkIHdoZW4gYWxsIHJlZmVyZW5jZXMgdG8KPiAr
ICogdGhlIGZyYWcgQGkgaW4gQHNrYiAodHJhY2tlZCBvdmVyIHNrYl9jbG9uZSwgcmV0cmFuc21p
dCwgcHVsbC11cHMsCj4gKyAqIGV0YykgYXJlIHJlbGVhc2VkLgo+ICsgKgo+ICsgKiBXaGVuIGEg
ZGVzdHJ1Y3RvciBpcyBzZXQgdGhlbiByZWZlcmVuY2UgY291bnRpbmcgaXMgcGVyZm9ybWVkIG9u
Cj4gKyAqIEBkZXN0cm95LT5yZWYuIFdoZW4gdGhlIHJlZiByZWFjaGVzIHplcm8gdGhlbiBAZGVz
dHJveS0+ZGVzdHJveQo+ICsgKiB3aWxsIGJlIGNhbGxlZC4gVGhlIGNhbGxlciBpcyByZXNwb25z
aWJsZSBmb3IgaG9sZGluZyBhbmQgbWFuYWdpbmcKPiArICogYW55IG90aGVyIHJlZmVyZW5jZXMg
KHN1Y2ggYSB0aGUgc3RydWN0IHBhZ2UgcmVmZXJlbmNlIGNvdW50KS4KPiArICoKPiArICogVGhp
cyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBiZWZvcmUgYW55IHVzZSBvZiBza2JfZnJhZ19yZWYo
KSBvcgo+ICsgKiBza2JfZnJhZ191bnJlZigpLgo+ICsgKi8KPiArc3RhdGljIGlubGluZSB2b2lk
IHNrYl9mcmFnX3NldF9kZXN0cnVjdG9yKHN0cnVjdCBza19idWZmICpza2IsIGludCBpLAo+ICsJ
CQkJCSAgIHN0cnVjdCBza2JfZnJhZ19kZXN0cnVjdG9yICpkZXN0cm95KQo+ICt7Cj4gKwlza2Jf
ZnJhZ190ICpmcmFnID0gJnNrYl9zaGluZm8oc2tiKS0+ZnJhZ3NbaV07Cj4gKwlmcmFnLT5wYWdl
LmRlc3RydWN0b3IgPSBkZXN0cm95Owo+ICt9Cj4gKwo+ICsvKioKPiAgICogX19za2JfZmlsbF9w
YWdlX2Rlc2MgLSBpbml0aWFsaXNlIGEgcGFnZWQgZnJhZ21lbnQgaW4gYW4gc2tiCj4gICAqIEBz
a2I6IGJ1ZmZlciBjb250YWluaW5nIGZyYWdtZW50IHRvIGJlIGluaXRpYWxpc2VkCj4gICAqIEBp
OiBwYWdlZCBmcmFnbWVudCBpbmRleCB0byBpbml0aWFsaXNlCj4gQEAgLTEyMzksNiArMTI3MCw3
IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfX3NrYl9maWxsX3BhZ2VfZGVzYyhzdHJ1Y3Qgc2tfYnVm
ZiAqc2tiLCBpbnQgaSwKPiAgCXNrYl9mcmFnX3QgKmZyYWcgPSAmc2tiX3NoaW5mbyhza2IpLT5m
cmFnc1tpXTsKPiAgCj4gIAlmcmFnLT5wYWdlLnAJCSAgPSBwYWdlOwo+ICsJZnJhZy0+cGFnZS5k
ZXN0cnVjdG9yICAgICA9IE5VTEw7Cj4gIAlmcmFnLT5wYWdlX29mZnNldAkgID0gb2ZmOwo+ICAJ
c2tiX2ZyYWdfc2l6ZV9zZXQoZnJhZywgc2l6ZSk7Cj4gIH0KPiBAQCAtMTc0Myw2ICsxNzc1LDkg
QEAgc3RhdGljIGlubGluZSBzdHJ1Y3QgcGFnZSAqc2tiX2ZyYWdfcGFnZShjb25zdCBza2JfZnJh
Z190ICpmcmFnKQo+ICAJcmV0dXJuIGZyYWctPnBhZ2UucDsKPiAgfQo+ICAKPiArZXh0ZXJuIHZv
aWQgc2tiX2ZyYWdfZGVzdHJ1Y3Rvcl9yZWYoc3RydWN0IHNrYl9mcmFnX2Rlc3RydWN0b3IgKmRl
c3Ryb3kpOwo+ICtleHRlcm4gdm9pZCBza2JfZnJhZ19kZXN0cnVjdG9yX3VucmVmKHN0cnVjdCBz
a2JfZnJhZ19kZXN0cnVjdG9yICpkZXN0cm95KTsKPiArCj4gIC8qKgo+ICAgKiBfX3NrYl9mcmFn
X3JlZiAtIHRha2UgYW4gYWRkaXRpb24gcmVmZXJlbmNlIG9uIGEgcGFnZWQgZnJhZ21lbnQuCj4g
ICAqIEBmcmFnOiB0aGUgcGFnZWQgZnJhZ21lbnQKPiBAQCAtMTc1MSw2ICsxNzg2LDEwIEBAIHN0
YXRpYyBpbmxpbmUgc3RydWN0IHBhZ2UgKnNrYl9mcmFnX3BhZ2UoY29uc3Qgc2tiX2ZyYWdfdCAq
ZnJhZykKPiAgICovCj4gIHN0YXRpYyBpbmxpbmUgdm9pZCBfX3NrYl9mcmFnX3JlZihza2JfZnJh
Z190ICpmcmFnKQo+ICB7Cj4gKwlpZiAodW5saWtlbHkoZnJhZy0+cGFnZS5kZXN0cnVjdG9yKSkg
ewo+ICsJCXNrYl9mcmFnX2Rlc3RydWN0b3JfcmVmKGZyYWctPnBhZ2UuZGVzdHJ1Y3Rvcik7Cj4g
KwkJcmV0dXJuOwo+ICsJfQo+ICAJZ2V0X3BhZ2Uoc2tiX2ZyYWdfcGFnZShmcmFnKSk7Cj4gIH0K
PiAgCj4gQEAgLTE3NzQsNiArMTgxMywxMCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgc2tiX2ZyYWdf
cmVmKHN0cnVjdCBza19idWZmICpza2IsIGludCBmKQo+ICAgKi8KPiAgc3RhdGljIGlubGluZSB2
b2lkIF9fc2tiX2ZyYWdfdW5yZWYoc2tiX2ZyYWdfdCAqZnJhZykKPiAgewo+ICsJaWYgKHVubGlr
ZWx5KGZyYWctPnBhZ2UuZGVzdHJ1Y3RvcikpIHsKPiArCQlza2JfZnJhZ19kZXN0cnVjdG9yX3Vu
cmVmKGZyYWctPnBhZ2UuZGVzdHJ1Y3Rvcik7Cj4gKwkJcmV0dXJuOwo+ICsJfQo+ICAJcHV0X3Bh
Z2Uoc2tiX2ZyYWdfcGFnZShmcmFnKSk7Cj4gIH0KPiAgCj4gZGlmZiAtLWdpdCBhL25ldC9jb3Jl
L3NrYnVmZi5jIGIvbmV0L2NvcmUvc2tidWZmLmMKPiBpbmRleCBiOGE0MWQ2Li45ZWM4OGNlIDEw
MDY0NAo+IC0tLSBhL25ldC9jb3JlL3NrYnVmZi5jCj4gKysrIGIvbmV0L2NvcmUvc2tidWZmLmMK
PiBAQCAtMzQ5LDYgKzM0OSwyMyBAQCBzdHJ1Y3Qgc2tfYnVmZiAqZGV2X2FsbG9jX3NrYih1bnNp
Z25lZCBpbnQgbGVuZ3RoKQo+ICB9Cj4gIEVYUE9SVF9TWU1CT0woZGV2X2FsbG9jX3NrYik7Cj4g
IAo+ICt2b2lkIHNrYl9mcmFnX2Rlc3RydWN0b3JfcmVmKHN0cnVjdCBza2JfZnJhZ19kZXN0cnVj
dG9yICpkZXN0cm95KQo+ICt7Cj4gKwlCVUdfT04oZGVzdHJveSA9PSBOVUxMKTsKPiArCWF0b21p
Y19pbmMoJmRlc3Ryb3ktPnJlZik7Cj4gK30KPiArRVhQT1JUX1NZTUJPTChza2JfZnJhZ19kZXN0
cnVjdG9yX3JlZik7Cj4gKwo+ICt2b2lkIHNrYl9mcmFnX2Rlc3RydWN0b3JfdW5yZWYoc3RydWN0
IHNrYl9mcmFnX2Rlc3RydWN0b3IgKmRlc3Ryb3kpCj4gK3sKPiArCWlmIChkZXN0cm95ID09IE5V
TEwpCj4gKwkJcmV0dXJuOwo+ICsKPiArCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZkZXN0cm95
LT5yZWYpKQo+ICsJCWRlc3Ryb3ktPmRlc3Ryb3koZGVzdHJveSk7Cj4gK30KPiArRVhQT1JUX1NZ
TUJPTChza2JfZnJhZ19kZXN0cnVjdG9yX3VucmVmKTsKPiArCj4gIHN0YXRpYyB2b2lkIHNrYl9k
cm9wX2xpc3Qoc3RydWN0IHNrX2J1ZmYgKipsaXN0cCkKPiAgewo+ICAJc3RydWN0IHNrX2J1ZmYg
Kmxpc3QgPSAqbGlzdHA7Cj4gLS0gCj4gMS43LjIuNQo+IAo+IAo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+
IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVeC-0000pC-Nf; Thu, 26 Apr 2012 20:50:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNVeB-0000p7-HC
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 20:50:39 +0000
Received: from [193.109.254.147:52823] by server-7.bemta-14.messagelabs.com id
	AB/0C-01627-E15B99F4; Thu, 26 Apr 2012 20:50:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335473434!849524!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7802 invoked from network); 26 Apr 2012 20:50:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 20:50:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKoQPZ000424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:50:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKoOTD000904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:50:25 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKoOgb029554; Thu, 26 Apr 2012 15:50:24 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:50:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 513F2402FB; Thu, 26 Apr 2012 16:44:50 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:44:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120426204450.GA7392@phenom.dumpdata.com>
References: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
	<1334067984-7706-6-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334067984-7706-6-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Wei Liu <wei.liu2@citrix.com>, Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
	=?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= <mirq-linux@rere.qmqm.pl>,
	xen-devel@lists.xen.org, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH 06/10] net: add support for
 per-paged-fragment destructors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBBcHIgMTAsIDIwMTIgYXQgMDM6MjY6MjBQTSArMDEwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IEVudGl0aWVzIHdoaWNoIGNhcmUgYWJvdXQgdGhlIGNvbXBsZXRlIGxpZmVjeWNsZSBv
ZiBwYWdlcyB3aGljaCB0aGV5IGluamVjdAo+IGludG8gdGhlIG5ldHdvcmsgc3RhY2sgdmlhIGFu
IHNrYiBwYWdlZCBmcmFnbWVudCBjYW4gY2hvb3NlIHRvIHNldCB0aGlzCj4gZGVzdHJ1Y3RvciBp
biBvcmRlciB0byByZWNlaXZlIGEgY2FsbGJhY2sgd2hlbiB0aGUgc3RhY2sgaXMgcmVhbGx5IGZp
bmlzaGVkCj4gd2l0aCBhIHBhZ2UgKGluY2x1ZGluZyBhbGwgY2xvbmVzLCByZXRyYW5zbWl0cywg
cHVsbC11cHMgZXRjIGV0YykuCj4gCj4gVGhpcyBkZXN0cnVjdG9yIHdpbGwgYWx3YXlzIGJlIHBy
b3BhZ2F0ZWQgYWxvbmdzaWRlIHRoZSBzdHJ1Y3QgcGFnZSB3aGVuCj4gY29weWluZyBza2JfZnJh
Z190LT5wYWdlLiBUaGlzIGlzIHRoZSByZWFzb24gSSBjaG9zZSB0byBlbWJlZCB0aGUgZGVzdHJ1
Y3RvciBpbgo+IGEgInN0cnVjdCB7IH0gcGFnZSIgd2l0aGluIHRoZSBza2JfZnJhZ190LCByYXRo
ZXIgdGhhbiBhcyBhIHNlcGFyYXRlIGZpZWxkLAo+IHNpbmNlIGl0IGFsbG93cyBleGlzdGluZyBj
b2RlIHdoaWNoIHByb3BhZ2F0ZXMgLT5mcmFnc1tOXS5wYWdlIHRvIEp1c3QKPiBXb3JrKHRtKS4K
PiAKPiBXaGVuIHRoZSBkZXN0cnVjdG9yIGlzIHByZXNlbnQgdGhlIHBhZ2UgcmVmZXJlbmNlIGNv
dW50aW5nIGlzIGRvbmUgc2xpZ2h0bHkKPiBkaWZmZXJlbnRseS4gTm8gcmVmZXJlbmNlcyBhcmUg
aGVsZCBieSB0aGUgbmV0d29yayBzdGFjayBvbiB0aGUgc3RydWN0IHBhZ2UgKGl0Cj4gaXMgdXAg
dG8gdGhlIGNhbGxlciB0byBtYW5hZ2UgdGhpcyBhcyBuZWNlc3NhcnkpIGluc3RlYWQgdGhlIG5l
dHdvcmsgc3RhY2sgd2lsbAo+IHRyYWNrIHJlZmVyZW5jZXMgdmlhIHRoZSBjb3VudCBlbWJlZGRl
ZCBpbiB0aGUgZGVzdHJ1Y3RvciBzdHJ1Y3R1cmUuIFdoZW4gdGhpcwo+IHJlZmVyZW5jZSBjb3Vu
dCByZWFjaGVzIHplcm8gdGhlbiB0aGUgZGVzdHJ1Y3RvciB3aWxsIGJlIGNhbGxlZCBhbmQgdGhl
IGNhbGxlcgo+IGNhbiB0YWtlIHRoZSBuZWNlc2FyeSBzdGVwcyB0byByZWxlYXNlIHRoZSBwYWdl
IChpLmUuIHJlbGVhc2UgdGhlIHN0cnVjdCBwYWdlCj4gcmVmZXJlbmNlIGl0c2VsZikuCj4gCj4g
VGhlIGludGVudGlvbiBpcyB0aGF0IGNhbGxlcnMgY2FuIHVzZSB0aGlzIGNhbGxiYWNrIHRvIGRl
bGF5IGNvbXBsZXRpb24gdG8KPiBfdGhlaXJfIGNhbGxlcnMgdW50aWwgdGhlIG5ldHdvcmsgc3Rh
Y2sgaGFzIGNvbXBsZXRlbHkgcmVsZWFzZWQgdGhlIHBhZ2UsIGluCj4gb3JkZXIgdG8gcHJldmVu
dCB1c2UtYWZ0ZXItZnJlZSBvciBtb2RpZmljYXRpb24gb2YgZGF0YSBwYWdlcyB3aGljaCBhcmUg
c3RpbGwKPiBpbiB1c2UgYnkgdGhlIHN0YWNrLgo+IAo+IEl0IGlzIGFsbG93YWJsZSAoaW5kZWVk
IGV4cGVjdGVkKSBmb3IgYSBjYWxsZXIgdG8gc2hhcmUgYSBzaW5nbGUgZGVzdHJ1Y3Rvcgo+IGlu
c3RhbmNlIGJldHdlZW4gbXVsdGlwbGUgcGFnZXMgaW5qZWN0ZWQgaW50byB0aGUgc3RhY2sgZS5n
LiBhIGdyb3VwIG9mIHBhZ2VzCj4gaW5jbHVkZWQgaW4gYSBzaW5nbGUgaGlnaGVyIGxldmVsIG9w
ZXJhdGlvbiBtaWdodCBzaGFyZSBhIGRlc3RydWN0b3Igd2hpY2ggaXMKPiB1c2VkIHRvIGNvbXBs
ZXRlIHRoYXQgaGlnaGVyIGxldmVsIG9wZXJhdGlvbi4KPiAKPiBXaXRoIHRoaXMgY2hhbmdlIGFu
ZCB0aGUgcHJldmlvdXMgdHdvIGNoYW5nZXMgdG8gc2hpbmZvIGFsaWdubWVudCBhbmQgZmllbGQK
PiBvcmRlcnJpbmcgaXQgaXMgbm93IHRoZSBjYXNlIHR5aGF0IG9uIGEgNjQgYml0IHN5c3RlbSB3
aXRoIDY0IGJ5dGUgY2FjaGUgbGluZXMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5e
Xl4gLSB0aGF0LgoKPiBldmVyeXRoaW5nIGZyb20gbnJfZnJhZ3MgdW50aWwgdGhlIGVuZCBvZiBm
cmFnc1swXSBpcyBvbiB0aGUgc2FtZSBjYWNoZWxpbmUuCj4gCj4gU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiBDYzogIkRhdmlkIFMuIE1pbGxl
ciIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+Cj4gQ2M6IEVyaWMgRHVtYXpldCA8ZXJpYy5kdW1hemV0
QGdtYWlsLmNvbT4KPiBDYzogIk1pY2hhxYIgTWlyb3PFgmF3IiA8bWlycS1saW51eEByZXJlLnFt
cW0ucGw+Cj4gQ2M6IG5ldGRldkB2Z2VyLmtlcm5lbC5vcmcKPiAtLS0KPiAgaW5jbHVkZS9saW51
eC9za2J1ZmYuaCB8ICAgNDMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKwo+ICBuZXQvY29yZS9za2J1ZmYuYyAgICAgIHwgICAxNyArKysrKysrKysrKysrKysrKwo+
ICAyIGZpbGVzIGNoYW5nZWQsIDYwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCj4gCj4g
ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvc2tidWZmLmggYi9pbmNsdWRlL2xpbnV4L3NrYnVm
Zi5oCj4gaW5kZXggZjBhZTM5Yy4uNmFjMjgzZSAxMDA2NDQKPiAtLS0gYS9pbmNsdWRlL2xpbnV4
L3NrYnVmZi5oCj4gKysrIGIvaW5jbHVkZS9saW51eC9za2J1ZmYuaAo+IEBAIC0xNjYsOSArMTY2
LDE1IEBAIHN0cnVjdCBza19idWZmOwo+ICAKPiAgdHlwZWRlZiBzdHJ1Y3Qgc2tiX2ZyYWdfc3Ry
dWN0IHNrYl9mcmFnX3Q7Cj4gIAo+ICtzdHJ1Y3Qgc2tiX2ZyYWdfZGVzdHJ1Y3RvciB7Cj4gKwlh
dG9taWNfdCByZWY7Cj4gKwlpbnQgKCpkZXN0cm95KShzdHJ1Y3Qgc2tiX2ZyYWdfZGVzdHJ1Y3Rv
ciAqZGVzdHJ1Y3Rvcik7Cj4gK307Cj4gKwo+ICBzdHJ1Y3Qgc2tiX2ZyYWdfc3RydWN0IHsKPiAg
CXN0cnVjdCB7Cj4gIAkJc3RydWN0IHBhZ2UgKnA7Cj4gKwkJc3RydWN0IHNrYl9mcmFnX2Rlc3Ry
dWN0b3IgKmRlc3RydWN0b3I7Cj4gIAl9IHBhZ2U7Cj4gICNpZiAoQklUU19QRVJfTE9ORyA+IDMy
KSB8fCAoUEFHRV9TSVpFID49IDY1NTM2KQo+ICAJX191MzIgcGFnZV9vZmZzZXQ7Cj4gQEAgLTEy
MjEsNiArMTIyNywzMSBAQCBzdGF0aWMgaW5saW5lIGludCBza2JfcGFnZWxlbihjb25zdCBzdHJ1
Y3Qgc2tfYnVmZiAqc2tiKQo+ICB9Cj4gIAo+ICAvKioKPiArICogc2tiX2ZyYWdfc2V0X2Rlc3Ry
dWN0b3IgLSBzZXQgZGVzdHJ1Y3RvciBmb3IgYSBwYWdlZCBmcmFnbWVudAo+ICsgKiBAc2tiOiBi
dWZmZXIgY29udGFpbmluZyBmcmFnbWVudCB0byBiZSBpbml0aWFsaXNlZAo+ICsgKiBAaTogcGFn
ZWQgZnJhZ21lbnQgaW5kZXggdG8gaW5pdGlhbGlzZQo+ICsgKiBAZGVzdHJveTogdGhlIGRlc3Ry
dWN0b3IgdG8gdXNlIGZvciB0aGlzIGZyYWdtZW50Cj4gKyAqCj4gKyAqIFNldHMgQGRlc3Ryb3kg
YXMgdGhlIGRlc3RydWN0b3IgdG8gYmUgY2FsbGVkIHdoZW4gYWxsIHJlZmVyZW5jZXMgdG8KPiAr
ICogdGhlIGZyYWcgQGkgaW4gQHNrYiAodHJhY2tlZCBvdmVyIHNrYl9jbG9uZSwgcmV0cmFuc21p
dCwgcHVsbC11cHMsCj4gKyAqIGV0YykgYXJlIHJlbGVhc2VkLgo+ICsgKgo+ICsgKiBXaGVuIGEg
ZGVzdHJ1Y3RvciBpcyBzZXQgdGhlbiByZWZlcmVuY2UgY291bnRpbmcgaXMgcGVyZm9ybWVkIG9u
Cj4gKyAqIEBkZXN0cm95LT5yZWYuIFdoZW4gdGhlIHJlZiByZWFjaGVzIHplcm8gdGhlbiBAZGVz
dHJveS0+ZGVzdHJveQo+ICsgKiB3aWxsIGJlIGNhbGxlZC4gVGhlIGNhbGxlciBpcyByZXNwb25z
aWJsZSBmb3IgaG9sZGluZyBhbmQgbWFuYWdpbmcKPiArICogYW55IG90aGVyIHJlZmVyZW5jZXMg
KHN1Y2ggYSB0aGUgc3RydWN0IHBhZ2UgcmVmZXJlbmNlIGNvdW50KS4KPiArICoKPiArICogVGhp
cyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBiZWZvcmUgYW55IHVzZSBvZiBza2JfZnJhZ19yZWYo
KSBvcgo+ICsgKiBza2JfZnJhZ191bnJlZigpLgo+ICsgKi8KPiArc3RhdGljIGlubGluZSB2b2lk
IHNrYl9mcmFnX3NldF9kZXN0cnVjdG9yKHN0cnVjdCBza19idWZmICpza2IsIGludCBpLAo+ICsJ
CQkJCSAgIHN0cnVjdCBza2JfZnJhZ19kZXN0cnVjdG9yICpkZXN0cm95KQo+ICt7Cj4gKwlza2Jf
ZnJhZ190ICpmcmFnID0gJnNrYl9zaGluZm8oc2tiKS0+ZnJhZ3NbaV07Cj4gKwlmcmFnLT5wYWdl
LmRlc3RydWN0b3IgPSBkZXN0cm95Owo+ICt9Cj4gKwo+ICsvKioKPiAgICogX19za2JfZmlsbF9w
YWdlX2Rlc2MgLSBpbml0aWFsaXNlIGEgcGFnZWQgZnJhZ21lbnQgaW4gYW4gc2tiCj4gICAqIEBz
a2I6IGJ1ZmZlciBjb250YWluaW5nIGZyYWdtZW50IHRvIGJlIGluaXRpYWxpc2VkCj4gICAqIEBp
OiBwYWdlZCBmcmFnbWVudCBpbmRleCB0byBpbml0aWFsaXNlCj4gQEAgLTEyMzksNiArMTI3MCw3
IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfX3NrYl9maWxsX3BhZ2VfZGVzYyhzdHJ1Y3Qgc2tfYnVm
ZiAqc2tiLCBpbnQgaSwKPiAgCXNrYl9mcmFnX3QgKmZyYWcgPSAmc2tiX3NoaW5mbyhza2IpLT5m
cmFnc1tpXTsKPiAgCj4gIAlmcmFnLT5wYWdlLnAJCSAgPSBwYWdlOwo+ICsJZnJhZy0+cGFnZS5k
ZXN0cnVjdG9yICAgICA9IE5VTEw7Cj4gIAlmcmFnLT5wYWdlX29mZnNldAkgID0gb2ZmOwo+ICAJ
c2tiX2ZyYWdfc2l6ZV9zZXQoZnJhZywgc2l6ZSk7Cj4gIH0KPiBAQCAtMTc0Myw2ICsxNzc1LDkg
QEAgc3RhdGljIGlubGluZSBzdHJ1Y3QgcGFnZSAqc2tiX2ZyYWdfcGFnZShjb25zdCBza2JfZnJh
Z190ICpmcmFnKQo+ICAJcmV0dXJuIGZyYWctPnBhZ2UucDsKPiAgfQo+ICAKPiArZXh0ZXJuIHZv
aWQgc2tiX2ZyYWdfZGVzdHJ1Y3Rvcl9yZWYoc3RydWN0IHNrYl9mcmFnX2Rlc3RydWN0b3IgKmRl
c3Ryb3kpOwo+ICtleHRlcm4gdm9pZCBza2JfZnJhZ19kZXN0cnVjdG9yX3VucmVmKHN0cnVjdCBz
a2JfZnJhZ19kZXN0cnVjdG9yICpkZXN0cm95KTsKPiArCj4gIC8qKgo+ICAgKiBfX3NrYl9mcmFn
X3JlZiAtIHRha2UgYW4gYWRkaXRpb24gcmVmZXJlbmNlIG9uIGEgcGFnZWQgZnJhZ21lbnQuCj4g
ICAqIEBmcmFnOiB0aGUgcGFnZWQgZnJhZ21lbnQKPiBAQCAtMTc1MSw2ICsxNzg2LDEwIEBAIHN0
YXRpYyBpbmxpbmUgc3RydWN0IHBhZ2UgKnNrYl9mcmFnX3BhZ2UoY29uc3Qgc2tiX2ZyYWdfdCAq
ZnJhZykKPiAgICovCj4gIHN0YXRpYyBpbmxpbmUgdm9pZCBfX3NrYl9mcmFnX3JlZihza2JfZnJh
Z190ICpmcmFnKQo+ICB7Cj4gKwlpZiAodW5saWtlbHkoZnJhZy0+cGFnZS5kZXN0cnVjdG9yKSkg
ewo+ICsJCXNrYl9mcmFnX2Rlc3RydWN0b3JfcmVmKGZyYWctPnBhZ2UuZGVzdHJ1Y3Rvcik7Cj4g
KwkJcmV0dXJuOwo+ICsJfQo+ICAJZ2V0X3BhZ2Uoc2tiX2ZyYWdfcGFnZShmcmFnKSk7Cj4gIH0K
PiAgCj4gQEAgLTE3NzQsNiArMTgxMywxMCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgc2tiX2ZyYWdf
cmVmKHN0cnVjdCBza19idWZmICpza2IsIGludCBmKQo+ICAgKi8KPiAgc3RhdGljIGlubGluZSB2
b2lkIF9fc2tiX2ZyYWdfdW5yZWYoc2tiX2ZyYWdfdCAqZnJhZykKPiAgewo+ICsJaWYgKHVubGlr
ZWx5KGZyYWctPnBhZ2UuZGVzdHJ1Y3RvcikpIHsKPiArCQlza2JfZnJhZ19kZXN0cnVjdG9yX3Vu
cmVmKGZyYWctPnBhZ2UuZGVzdHJ1Y3Rvcik7Cj4gKwkJcmV0dXJuOwo+ICsJfQo+ICAJcHV0X3Bh
Z2Uoc2tiX2ZyYWdfcGFnZShmcmFnKSk7Cj4gIH0KPiAgCj4gZGlmZiAtLWdpdCBhL25ldC9jb3Jl
L3NrYnVmZi5jIGIvbmV0L2NvcmUvc2tidWZmLmMKPiBpbmRleCBiOGE0MWQ2Li45ZWM4OGNlIDEw
MDY0NAo+IC0tLSBhL25ldC9jb3JlL3NrYnVmZi5jCj4gKysrIGIvbmV0L2NvcmUvc2tidWZmLmMK
PiBAQCAtMzQ5LDYgKzM0OSwyMyBAQCBzdHJ1Y3Qgc2tfYnVmZiAqZGV2X2FsbG9jX3NrYih1bnNp
Z25lZCBpbnQgbGVuZ3RoKQo+ICB9Cj4gIEVYUE9SVF9TWU1CT0woZGV2X2FsbG9jX3NrYik7Cj4g
IAo+ICt2b2lkIHNrYl9mcmFnX2Rlc3RydWN0b3JfcmVmKHN0cnVjdCBza2JfZnJhZ19kZXN0cnVj
dG9yICpkZXN0cm95KQo+ICt7Cj4gKwlCVUdfT04oZGVzdHJveSA9PSBOVUxMKTsKPiArCWF0b21p
Y19pbmMoJmRlc3Ryb3ktPnJlZik7Cj4gK30KPiArRVhQT1JUX1NZTUJPTChza2JfZnJhZ19kZXN0
cnVjdG9yX3JlZik7Cj4gKwo+ICt2b2lkIHNrYl9mcmFnX2Rlc3RydWN0b3JfdW5yZWYoc3RydWN0
IHNrYl9mcmFnX2Rlc3RydWN0b3IgKmRlc3Ryb3kpCj4gK3sKPiArCWlmIChkZXN0cm95ID09IE5V
TEwpCj4gKwkJcmV0dXJuOwo+ICsKPiArCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZkZXN0cm95
LT5yZWYpKQo+ICsJCWRlc3Ryb3ktPmRlc3Ryb3koZGVzdHJveSk7Cj4gK30KPiArRVhQT1JUX1NZ
TUJPTChza2JfZnJhZ19kZXN0cnVjdG9yX3VucmVmKTsKPiArCj4gIHN0YXRpYyB2b2lkIHNrYl9k
cm9wX2xpc3Qoc3RydWN0IHNrX2J1ZmYgKipsaXN0cCkKPiAgewo+ICAJc3RydWN0IHNrX2J1ZmYg
Kmxpc3QgPSAqbGlzdHA7Cj4gLS0gCj4gMS43LjIuNQo+IAo+IAo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+
IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVki-0000xk-Jh; Thu, 26 Apr 2012 20:57:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNVkh-0000xd-Fy
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 20:57:23 +0000
Received: from [85.158.143.99:61910] by server-1.bemta-4.messagelabs.com id
	31/94-20925-2B6B99F4; Thu, 26 Apr 2012 20:57:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335473840!25472156!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9230 invoked from network); 26 Apr 2012 20:57:21 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 20:57:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKvGWl017488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:57:17 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKvGOk017173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:57:16 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKvF87001634; Thu, 26 Apr 2012 15:57:15 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:57:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4A6FB402FB; Thu, 26 Apr 2012 16:51:42 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:51:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120426205142.GA30926@phenom.dumpdata.com>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
	<1334949673-25632-2-git-send-email-msw@amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334949673-25632-2-git-send-email-msw@amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Joe Jin <joe.jin@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in
 statistics sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 07:21:13PM +0000, Matt Wilson wrote:
> This is a port of a patch in the XenoLinux 2.6.18 tree:
> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56
> 
> Fix blkback sysfs race
> 
> Read blkback statistics info after remove vbd device(s) kernel
> will crash.

Looks pretty reasonable.

> 
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> Acked-by: Jan Beulich <jbeulich@novell.com>
> [Ported to Linux 3.x]
> Signed-off-by: Matt Wilson <msw@amazon.com>
> ---
>  drivers/block/xen-blkback/xenbus.c |   20 +++++++++++++++++---
>  1 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index da19506..74d4810 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -21,6 +21,8 @@
>  #include <xen/grant_table.h>
>  #include "common.h"
>  
> +static DEFINE_RWLOCK(sysfs_read_lock);
> +
>  struct backend_info {
>  	struct xenbus_device	*dev;
>  	struct xen_blkif	*blkif;
> @@ -225,10 +227,20 @@ int __init xen_blkif_interface_init(void)
>  				   struct device_attribute *attr,	\
>  				   char *buf)				\
>  	{								\
> -		struct xenbus_device *dev = to_xenbus_device(_dev);	\
> -		struct backend_info *be = dev_get_drvdata(&dev->dev);	\
> +		ssize_t ret = -ENODEV;					\
> +		struct xenbus_device *dev;				\
> +		struct backend_info *be;				\
>  									\
> -		return sprintf(buf, format, ##args);			\
> +		if (!get_device(_dev))					\
> +			return ret;					\
> +		dev = to_xenbus_device(_dev);				\
> +		read_lock(&sysfs_read_lock);				\
> +		be = (struct backend_info *) dev_get_drvdata(&dev->dev);\
> +		if (be != NULL)						\
> +			ret = sprintf(buf, format, ##args);		\
> +		read_unlock(&sysfs_read_lock);				\
> +		put_device(_dev);					\
> +		return ret;						\
>  	}								\
>  	static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
>  
> @@ -353,6 +365,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
>  
>  	DPRINTK("");
>  
> +	write_lock(&sysfs_read_lock);
>  	if (be->major || be->minor)
>  		xenvbd_sysfs_delif(dev);
>  
> @@ -371,6 +384,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
>  
>  	kfree(be);
>  	dev_set_drvdata(&dev->dev, NULL);
> +	write_unlock(&sysfs_read_lock);
>  	return 0;
>  }
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVki-0000xk-Jh; Thu, 26 Apr 2012 20:57:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNVkh-0000xd-Fy
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 20:57:23 +0000
Received: from [85.158.143.99:61910] by server-1.bemta-4.messagelabs.com id
	31/94-20925-2B6B99F4; Thu, 26 Apr 2012 20:57:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335473840!25472156!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MjA4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9230 invoked from network); 26 Apr 2012 20:57:21 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 20:57:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKvGWl017488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:57:17 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKvGOk017173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:57:16 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKvF87001634; Thu, 26 Apr 2012 15:57:15 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:57:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4A6FB402FB; Thu, 26 Apr 2012 16:51:42 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:51:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120426205142.GA30926@phenom.dumpdata.com>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
	<1334949673-25632-2-git-send-email-msw@amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334949673-25632-2-git-send-email-msw@amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Joe Jin <joe.jin@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in
 statistics sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 07:21:13PM +0000, Matt Wilson wrote:
> This is a port of a patch in the XenoLinux 2.6.18 tree:
> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56
> 
> Fix blkback sysfs race
> 
> Read blkback statistics info after remove vbd device(s) kernel
> will crash.

Looks pretty reasonable.

> 
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> Acked-by: Jan Beulich <jbeulich@novell.com>
> [Ported to Linux 3.x]
> Signed-off-by: Matt Wilson <msw@amazon.com>
> ---
>  drivers/block/xen-blkback/xenbus.c |   20 +++++++++++++++++---
>  1 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index da19506..74d4810 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -21,6 +21,8 @@
>  #include <xen/grant_table.h>
>  #include "common.h"
>  
> +static DEFINE_RWLOCK(sysfs_read_lock);
> +
>  struct backend_info {
>  	struct xenbus_device	*dev;
>  	struct xen_blkif	*blkif;
> @@ -225,10 +227,20 @@ int __init xen_blkif_interface_init(void)
>  				   struct device_attribute *attr,	\
>  				   char *buf)				\
>  	{								\
> -		struct xenbus_device *dev = to_xenbus_device(_dev);	\
> -		struct backend_info *be = dev_get_drvdata(&dev->dev);	\
> +		ssize_t ret = -ENODEV;					\
> +		struct xenbus_device *dev;				\
> +		struct backend_info *be;				\
>  									\
> -		return sprintf(buf, format, ##args);			\
> +		if (!get_device(_dev))					\
> +			return ret;					\
> +		dev = to_xenbus_device(_dev);				\
> +		read_lock(&sysfs_read_lock);				\
> +		be = (struct backend_info *) dev_get_drvdata(&dev->dev);\
> +		if (be != NULL)						\
> +			ret = sprintf(buf, format, ##args);		\
> +		read_unlock(&sysfs_read_lock);				\
> +		put_device(_dev);					\
> +		return ret;						\
>  	}								\
>  	static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
>  
> @@ -353,6 +365,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
>  
>  	DPRINTK("");
>  
> +	write_lock(&sysfs_read_lock);
>  	if (be->major || be->minor)
>  		xenvbd_sysfs_delif(dev);
>  
> @@ -371,6 +384,7 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
>  
>  	kfree(be);
>  	dev_set_drvdata(&dev->dev, NULL);
> +	write_unlock(&sysfs_read_lock);
>  	return 0;
>  }
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:58:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVli-00010h-28; Thu, 26 Apr 2012 20:58:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNVlg-00010a-K1
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 20:58:24 +0000
Received: from [85.158.139.83:29216] by server-8.bemta-5.messagelabs.com id
	1D/D3-26964-FE6B99F4; Thu, 26 Apr 2012 20:58:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335473901!25679360!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31369 invoked from network); 26 Apr 2012 20:58:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 20:58:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKwGFe007981
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:58:17 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKwFnD014621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:58:16 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKwFAJ024565; Thu, 26 Apr 2012 15:58:15 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:58:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C1AFA402FB; Thu, 26 Apr 2012 16:52:41 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:52:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120426205241.GB30926@phenom.dumpdata.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
	<20120417144318.GA28477@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204241153380.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204241153380.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH v4] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 11:55:43AM +0100, Stefano Stabellini wrote:
> This patch is a significant performance improvement for the
> m2p_override: about 6% using the gntdev device.
> 
> Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> is a great performance benefit because it means issuing one hypercall
> total rather than two hypercall per page.
> If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> going to be batched together, otherwise they are issued one at a time.
> 
> Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> m2p_add/remove_override calls forces paravirt_lazy_mode to
> PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> 
> However it is not safe to call arch_enter_lazy_mmu_mode if we are in
> interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
> check for both conditions before doing so.
> 
> Changes in v4:
> - rebased on 3.4-rc4: all the m2p_override users call gnttab_unmap_refs
> and gnttab_map_refs;
> - check whether we are in interrupt context and the lazy_mode we are in
> before calling arch_enter/leave_lazy_mmu_mode.
> 
> Changes in v3:
> - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> can be called in interrupt context.
> 

The only thing that I would do differently is to use a bool for lazy. But
I can do myself.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index e570c6f..a18a3e8 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -38,6 +38,7 @@
>  #include <linux/vmalloc.h>
>  #include <linux/uaccess.h>
>  #include <linux/io.h>
> +#include <linux/hardirq.h>
>  
>  #include <xen/xen.h>
>  #include <xen/interface/xen.h>
> @@ -826,7 +827,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  		    struct gnttab_map_grant_ref *kmap_ops,
>  		    struct page **pages, unsigned int count)
>  {
> -	int i, ret;
> +	int i, ret, lazy = 0;
>  	pte_t *pte;
>  	unsigned long mfn;
>  
> @@ -837,6 +838,11 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> +		arch_enter_lazy_mmu_mode();
> +		lazy = 1;
> +	}
> +
>  	for (i = 0; i < count; i++) {
>  		/* Do not add to override if the map failed. */
>  		if (map_ops[i].status)
> @@ -855,6 +861,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  			return ret;
>  	}
>  
> +	if (lazy)
> +		arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_map_refs);
> @@ -862,7 +871,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  		      struct page **pages, unsigned int count, bool clear_pte)
>  {
> -	int i, ret;
> +	int i, ret, lazy = 0;
>  
>  	ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
>  	if (ret)
> @@ -871,12 +880,20 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> +		arch_enter_lazy_mmu_mode();
> +		lazy = 1;
> +	}
> +
>  	for (i = 0; i < count; i++) {
>  		ret = m2p_remove_override(pages[i], clear_pte);
>  		if (ret)
>  			return ret;
>  	}
>  
> +	if (lazy)
> +		arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 20:58:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 20:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNVli-00010h-28; Thu, 26 Apr 2012 20:58:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNVlg-00010a-K1
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 20:58:24 +0000
Received: from [85.158.139.83:29216] by server-8.bemta-5.messagelabs.com id
	1D/D3-26964-FE6B99F4; Thu, 26 Apr 2012 20:58:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335473901!25679360!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njc0MA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31369 invoked from network); 26 Apr 2012 20:58:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 20:58:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QKwGFe007981
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 20:58:17 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QKwFnD014621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 20:58:16 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QKwFAJ024565; Thu, 26 Apr 2012 15:58:15 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 13:58:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C1AFA402FB; Thu, 26 Apr 2012 16:52:41 -0400 (EDT)
Date: Thu, 26 Apr 2012 16:52:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120426205241.GB30926@phenom.dumpdata.com>
References: <1334075375-25442-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120417130340.GA25593@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204171457360.26786@kaball-desktop>
	<20120417144318.GA28477@phenom.dumpdata.com>
	<alpine.DEB.2.00.1204241153380.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1204241153380.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH v4] xen: enter/exit lazy_mmu_mode around
 m2p_override calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Apr 24, 2012 at 11:55:43AM +0100, Stefano Stabellini wrote:
> This patch is a significant performance improvement for the
> m2p_override: about 6% using the gntdev device.
> 
> Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
> __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
> is a great performance benefit because it means issuing one hypercall
> total rather than two hypercall per page.
> If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
> going to be batched together, otherwise they are issued one at a time.
> 
> Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
> m2p_add/remove_override calls forces paravirt_lazy_mode to
> PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
> 
> However it is not safe to call arch_enter_lazy_mmu_mode if we are in
> interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
> check for both conditions before doing so.
> 
> Changes in v4:
> - rebased on 3.4-rc4: all the m2p_override users call gnttab_unmap_refs
> and gnttab_map_refs;
> - check whether we are in interrupt context and the lazy_mode we are in
> before calling arch_enter/leave_lazy_mmu_mode.
> 
> Changes in v3:
> - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
> can be called in interrupt context.
> 

The only thing that I would do differently is to use a bool for lazy. But
I can do myself.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index e570c6f..a18a3e8 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -38,6 +38,7 @@
>  #include <linux/vmalloc.h>
>  #include <linux/uaccess.h>
>  #include <linux/io.h>
> +#include <linux/hardirq.h>
>  
>  #include <xen/xen.h>
>  #include <xen/interface/xen.h>
> @@ -826,7 +827,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  		    struct gnttab_map_grant_ref *kmap_ops,
>  		    struct page **pages, unsigned int count)
>  {
> -	int i, ret;
> +	int i, ret, lazy = 0;
>  	pte_t *pte;
>  	unsigned long mfn;
>  
> @@ -837,6 +838,11 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> +		arch_enter_lazy_mmu_mode();
> +		lazy = 1;
> +	}
> +
>  	for (i = 0; i < count; i++) {
>  		/* Do not add to override if the map failed. */
>  		if (map_ops[i].status)
> @@ -855,6 +861,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  			return ret;
>  	}
>  
> +	if (lazy)
> +		arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_map_refs);
> @@ -862,7 +871,7 @@ EXPORT_SYMBOL_GPL(gnttab_map_refs);
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  		      struct page **pages, unsigned int count, bool clear_pte)
>  {
> -	int i, ret;
> +	int i, ret, lazy = 0;
>  
>  	ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, count);
>  	if (ret)
> @@ -871,12 +880,20 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> +	if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
> +		arch_enter_lazy_mmu_mode();
> +		lazy = 1;
> +	}
> +
>  	for (i = 0; i < count; i++) {
>  		ret = m2p_remove_override(pages[i], clear_pte);
>  		if (ret)
>  			return ret;
>  	}
>  
> +	if (lazy)
> +		arch_leave_lazy_mmu_mode();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 21:26:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 21:26:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNWC9-0001Mi-JI; Thu, 26 Apr 2012 21:25:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNWC7-0001Md-FJ
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 21:25:44 +0000
Received: from [85.158.143.35:28028] by server-2.bemta-4.messagelabs.com id
	E6/C4-17550-65DB99F4; Thu, 26 Apr 2012 21:25:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335475538!12797452!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9695 invoked from network); 26 Apr 2012 21:25:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 21:25:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNWBv-000Jj7-Nj; Thu, 26 Apr 2012 21:25:31 +0000
Date: Thu, 26 Apr 2012 22:25:31 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120426212531.GH67043@ocelot.phlegethon.org>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk"
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> > > But actually, the first cs introduced this issue is 24770. When win8
> > > booting and if hpet is enabled, it will use hpet as the time source
> > > and there have lots of hpet access and EPT violation. In EPT violation
> > > handler, it call get_gfn_type_access to get the mfn. The cs 24770
> > > introduces the gfn_lock for p2m lookups, and then the issue happens.
> > > After I removed the gfn_lock, the issue goes. But in latest xen, even
> > > I remove this lock, it still shows high cpu utilization.
> > 
> > It would seem then that even the briefest lock-protected critical section would
> > cause this? In the mmio case, the p2m lock taken in the hap fault handler is
> > held during the actual lookup, and for a couple of branch instructions
> > afterwards.
> > 
> > In latest Xen, with lock removed for get_gfn, on which lock is time spent?
> Still the p2m_lock.

Can you please try the attached patch?  I think you'll need this one
plus the ones that take the locks out of the hpet code. 

This patch makes the p2m lock into an rwlock and adjusts a number of the
paths that don't update the p2m so they only take the read lock.  It's a
bit rough but I can boot 16-way win7 guest with it.

N.B. Since rwlocks don't show up the the existing lock profiling, please
don't try to use the lock-profiling numbers to see if it's helping!

Andres, this is basically the big-hammer version of your "take a
pagecount" changes, plus the change you made to hvmemul_rep_movs().
If this works I intend to follow it up with a patch to make some of the
read-modify-write paths avoid taking the lock (by using a
compare-exchange operation so they only take the lock on a write).  If
that succeeds I might drop put_gfn() altogether. 

But first it will need a lot of tidying up.  Noticeably missing:
 - SVM code equivalents to the vmx.c changes
 - grant-table operations still use the lock, because frankly I 
   could not follow the current code, and it's quite late in the evening.
I also have a long list of uglinesses in the mm code that I found while
writing this lot. 

Keir, I have no objection to later replacing this with something better
than an rwlock. :)  Or with making a NUMA-friendly rwlock
implementation, since I really expect this to be heavily read-mostly
when paging/sharing/pod are not enabled.

Cheers,

Tim.
--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=get-page-from-gfn

# HG changeset patch
# Parent 107285938c50f82667bd4d014820b439a077c22c

diff -r 107285938c50 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domain.c	Thu Apr 26 22:00:25 2012 +0100
@@ -716,7 +716,7 @@ int arch_set_info_guest(
 {
     struct domain *d = v->domain;
     unsigned long cr3_gfn;
-    unsigned long cr3_pfn = INVALID_MFN;
+    struct page_info *cr3_page;
     unsigned long flags, cr4;
     unsigned int i;
     int rc = 0, compat;
@@ -925,46 +925,45 @@ int arch_set_info_guest(
     if ( !compat )
     {
         cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_base_page_table)) )
+        if ( !cr3_page )
         {
-            put_gfn(d, cr3_gfn);
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+        if ( !paging_mode_refcounts(d)
+             && !get_page_type(cr3_page, PGT_base_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
-        v->arch.guest_table = pagetable_from_pfn(cr3_pfn);
-        put_gfn(d, cr3_gfn);
+        v->arch.guest_table = pagetable_from_page(cr3_page);
 #ifdef __x86_64__
         if ( c.nat->ctrlreg[1] )
         {
             cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]);
-            cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+            cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-            if ( !mfn_valid(cr3_pfn) ||
-                 (paging_mode_refcounts(d)
-                  ? !get_page(mfn_to_page(cr3_pfn), d)
-                  : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                       PGT_base_page_table)) )
+            if ( !cr3_page ||
+                 (!paging_mode_refcounts(d)
+                  && !get_page_type(cr3_page, PGT_base_page_table)) )
             {
-                cr3_pfn = pagetable_get_pfn(v->arch.guest_table);
+                if (cr3_page)
+                    put_page(cr3_page);
+                cr3_page = pagetable_get_page(v->arch.guest_table);
                 v->arch.guest_table = pagetable_null();
                 if ( paging_mode_refcounts(d) )
-                    put_page(mfn_to_page(cr3_pfn));
+                    put_page(cr3_page);
                 else
-                    put_page_and_type(mfn_to_page(cr3_pfn));
-                put_gfn(d, cr3_gfn); 
+                    put_page_and_type(cr3_page);
                 destroy_gdt(v);
                 return -EINVAL;
             }
 
-            v->arch.guest_table_user = pagetable_from_pfn(cr3_pfn);
-            put_gfn(d, cr3_gfn); 
+            v->arch.guest_table_user = pagetable_from_page(cr3_page);
         }
         else if ( !(flags & VGCF_in_kernel) )
         {
@@ -977,23 +976,25 @@ int arch_set_info_guest(
         l4_pgentry_t *l4tab;
 
         cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_l3_page_table)) )
+        if ( !cr3_page)
         {
-            put_gfn(d, cr3_gfn); 
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+
+        if (!paging_mode_refcounts(d)
+            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
         l4tab = __va(pagetable_get_paddr(v->arch.guest_table));
-        *l4tab = l4e_from_pfn(
-            cr3_pfn, _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
-        put_gfn(d, cr3_gfn); 
+        *l4tab = l4e_from_pfn(page_to_mfn(cr3_page),
+            _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
 #endif
     }
 
@@ -1064,7 +1065,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     struct domain *d = v->domain;
     void *mapping;
     vcpu_info_t *new_info;
-    unsigned long mfn;
+    struct page_info *page;
     int i;
 
     if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) )
@@ -1077,19 +1078,20 @@ map_vcpu_info(struct vcpu *v, unsigned l
     if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) )
         return -EINVAL;
 
-    mfn = get_gfn_untyped(d, gfn);
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gfn); 
+        put_page(page);
         return -EINVAL;
     }
 
-    mapping = map_domain_page_global(mfn);
+    mapping = __map_domain_page_global(page);
     if ( mapping == NULL )
     {
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gfn); 
+        put_page_and_type(page);
         return -ENOMEM;
     }
 
@@ -1106,7 +1108,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     }
 
     v->vcpu_info = new_info;
-    v->arch.pv_vcpu.vcpu_info_mfn = mfn;
+    v->arch.pv_vcpu.vcpu_info_mfn = page_to_mfn(page);
 
     /* Set new vcpu_info pointer /before/ setting pending flags. */
     wmb();
@@ -1119,7 +1121,6 @@ map_vcpu_info(struct vcpu *v, unsigned l
     for ( i = 0; i < BITS_PER_EVTCHN_WORD(d); i++ )
         set_bit(i, &vcpu_info(v, evtchn_pending_sel));
 
-    put_gfn(d, gfn); 
     return 0;
 }
 
diff -r 107285938c50 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domctl.c	Thu Apr 26 22:00:25 2012 +0100
@@ -202,16 +202,16 @@ long arch_do_domctl(
 
                 for ( j = 0; j < k; j++ )
                 {
-                    unsigned long type = 0, mfn = get_gfn_untyped(d, arr[j]);
+                    unsigned long type = 0;
 
-                    page = mfn_to_page(mfn);
+                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
 
-                    if ( unlikely(!mfn_valid(mfn)) ||
-                         unlikely(is_xen_heap_mfn(mfn)) )
+                    if ( unlikely(!page) ||
+                         unlikely(is_xen_heap_page(page)) )
                         type = XEN_DOMCTL_PFINFO_XTAB;
                     else if ( xsm_getpageframeinfo(page) != 0 )
                         ;
-                    else if ( likely(get_page(page, d)) )
+                    else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
                         {
@@ -231,13 +231,10 @@ long arch_do_domctl(
 
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |= XEN_DOMCTL_PFINFO_LPINTAB;
+                    }
 
+                    if ( page )
                         put_page(page);
-                    }
-                    else
-                        type = XEN_DOMCTL_PFINFO_XTAB;
-
-                    put_gfn(d, arr[j]);
                     arr[j] = type;
                 }
 
@@ -304,21 +301,21 @@ long arch_do_domctl(
             {      
                 struct page_info *page;
                 unsigned long gfn = arr32[j];
-                unsigned long mfn = get_gfn_untyped(d, gfn);
 
-                page = mfn_to_page(mfn);
+                page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
 
                 if ( domctl->cmd == XEN_DOMCTL_getpageframeinfo3)
                     arr32[j] = 0;
 
-                if ( unlikely(!mfn_valid(mfn)) ||
-                     unlikely(is_xen_heap_mfn(mfn)) )
+                if ( unlikely(!page) ||
+                     unlikely(is_xen_heap_page(page)) )
                     arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
                 else if ( xsm_getpageframeinfo(page) != 0 )
                 {
-                    put_gfn(d, gfn); 
+                    put_page(page);
                     continue;
-                } else if ( likely(get_page(page, d)) )
+                }
+                else
                 {
                     unsigned long type = 0;
 
@@ -341,12 +338,10 @@ long arch_do_domctl(
                     if ( page->u.inuse.type_info & PGT_pinned )
                         type |= XEN_DOMCTL_PFINFO_LPINTAB;
                     arr32[j] |= type;
+                }
+
+                if ( page )
                     put_page(page);
-                }
-                else
-                    arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
-
-                put_gfn(d, gfn); 
             }
 
             if ( copy_to_guest_offset(domctl->u.getpageframeinfo2.array,
@@ -419,7 +414,7 @@ long arch_do_domctl(
     {
         struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long gmfn = domctl->u.hypercall_init.gmfn;
-        unsigned long mfn;
+        struct page_info *page;
         void *hypercall_page;
 
         ret = -ESRCH;
@@ -433,26 +428,25 @@ long arch_do_domctl(
             break;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
 
         ret = -EACCES;
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn); 
+            if ( page )
+                put_page(page);
             rcu_unlock_domain(d);
             break;
         }
 
         ret = 0;
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
+        put_page_and_type(page);
 
-        put_gfn(d, gmfn); 
         rcu_unlock_domain(d);
     }
     break;
diff -r 107285938c50 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/emulate.c	Thu Apr 26 22:00:25 2012 +0100
@@ -60,34 +60,25 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    struct page_info *ram_page;
     int rc;
 
     /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+    ram_page = get_page_from_gfn(curr->domain, ram_gfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         p2m_mem_paging_populate(curr->domain, ram_gfn);
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_RETRY;
     }
 
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
-        {
-            put_gfn(curr->domain, ram_gfn);
-            return X86EMUL_RETRY;
-        }
-    put_gfn(curr->domain, ram_gfn);
-
     /*
      * Weird-sized accesses have undefined behaviour: we discard writes
      * and read all-ones.
@@ -98,8 +89,8 @@ static int hvmemul_do_io(
         ASSERT(p_data != NULL); /* cannot happen with a REP prefix */
         if ( dir == IOREQ_READ )
             memset(p_data, ~0, size);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -120,8 +111,8 @@ static int hvmemul_do_io(
             unsigned int bytes = vio->mmio_large_write_bytes;
             if ( (addr >= pa) && ((addr + size) <= (pa + bytes)) )
             {
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -133,8 +124,8 @@ static int hvmemul_do_io(
             {
                 memcpy(p_data, &vio->mmio_large_read[addr - pa],
                        size);
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -148,8 +139,8 @@ static int hvmemul_do_io(
         vio->io_state = HVMIO_none;
         if ( p_data == NULL )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_UNHANDLEABLE;
         }
         goto finish_access;
@@ -159,13 +150,13 @@ static int hvmemul_do_io(
              (addr == (vio->mmio_large_write_pa +
                        vio->mmio_large_write_bytes)) )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_RETRY;
         }
     default:
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -173,8 +164,8 @@ static int hvmemul_do_io(
     {
         gdprintk(XENLOG_WARNING, "WARNING: io already pending (%d)?\n",
                  p->state);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -226,8 +217,8 @@ static int hvmemul_do_io(
 
     if ( rc != X86EMUL_OKAY )
     {
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return rc;
     }
 
@@ -263,8 +254,8 @@ static int hvmemul_do_io(
         }
     }
 
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        put_page(mfn_to_page(mfn_x(ram_mfn)));
+    if ( ram_page )
+        put_page(ram_page);
     return X86EMUL_OKAY;
 }
 
@@ -686,7 +677,6 @@ static int hvmemul_rep_movs(
     p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
-    struct two_gfns tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -714,25 +704,17 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
-                 current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 P2M_ALLOC, &tg);
+    /* Check for MMIO ops */
+    (void) get_gfn_query_unlocked(current->domain, sgpa >> PAGE_SHIFT, &sp2mt);
+    (void) get_gfn_query_unlocked(current->domain, dgpa >> PAGE_SHIFT, &dp2mt);
 
-    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( sp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
-    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( dp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +729,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +738,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +749,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 107285938c50 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Thu Apr 26 22:00:25 2012 +0100
@@ -395,48 +395,41 @@ int prepare_ring_for_helper(
 {
     struct page_info *page;
     p2m_type_t p2mt;
-    unsigned long mfn;
     void *va;
 
-    mfn = mfn_x(get_gfn_unshare(d, gmfn, &p2mt));
-    if ( !p2m_is_ram(p2mt) )
-    {
-        put_gfn(d, gmfn);
-        return -EINVAL;
-    }
+    page = get_page_from_gfn(d, gmfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         return -ENOENT;
     }
-    ASSERT(mfn_valid(mfn));
-
-    page = mfn_to_page(mfn);
-    if ( !get_page_and_type(page, d, PGT_writable_page) )
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn);
+        put_page(page);
         return -EINVAL;
     }
 
-    va = map_domain_page_global(mfn);
+    va = __map_domain_page_global(page);
     if ( va == NULL )
     {
         put_page_and_type(page);
-        put_gfn(d, gmfn);
         return -ENOMEM;
     }
 
     *_va = va;
     *_page = page;
 
-    put_gfn(d, gmfn);
-
     return 0;
 }
 
@@ -1607,8 +1600,8 @@ int hvm_mov_from_cr(unsigned int cr, uns
 int hvm_set_cr0(unsigned long value)
 {
     struct vcpu *v = current;
-    p2m_type_t p2mt;
-    unsigned long gfn, mfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    unsigned long gfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    struct page_info *page;
 
     HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR0 value = %lx", value);
 
@@ -1647,23 +1640,20 @@ int hvm_set_cr0(unsigned long value)
         {
             /* The guest CR3 must be pointing to the guest physical. */
             gfn = v->arch.hvm_vcpu.guest_cr[3]>>PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(v->domain, gfn, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-                 !get_page(mfn_to_page(mfn), v->domain))
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, gfn);
-                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx (mfn=%lx)\n",
-                         v->arch.hvm_vcpu.guest_cr[3], mfn);
+                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx\n",
+                         v->arch.hvm_vcpu.guest_cr[3]);
                 domain_crash(v->domain);
                 return X86EMUL_UNHANDLEABLE;
             }
 
             /* Now arch.guest_table points to machine physical. */
-            v->arch.guest_table = pagetable_from_pfn(mfn);
+            v->arch.guest_table = pagetable_from_page(page);
 
             HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx, mfn = %lx",
-                        v->arch.hvm_vcpu.guest_cr[3], mfn);
-            put_gfn(v->domain, gfn);
+                        v->arch.hvm_vcpu.guest_cr[3], page_to_mfn(page));
         }
     }
     else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) )
@@ -1738,26 +1728,21 @@ int hvm_set_cr0(unsigned long value)
 
 int hvm_set_cr3(unsigned long value)
 {
-    unsigned long mfn;
-    p2m_type_t p2mt;
     struct vcpu *v = current;
+    struct page_info *page;
 
     if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
          (value != v->arch.hvm_vcpu.guest_cr[3]) )
     {
         /* Shadow-mode CR3 change. Check PDBR and update refcounts. */
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "CR3 value = %lx", value);
-        mfn = mfn_x(get_gfn(v->domain, value >> PAGE_SHIFT, &p2mt));
-        if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-             !get_page(mfn_to_page(mfn), v->domain) )
-        {
-              put_gfn(v->domain, value >> PAGE_SHIFT);
-              goto bad_cr3;
-        }
+        page = get_page_from_gfn(v->domain, value >> PAGE_SHIFT,
+                                 NULL, P2M_ALLOC);
+        if ( !page )
+            goto bad_cr3;
 
         put_page(pagetable_get_page(v->arch.guest_table));
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        put_gfn(v->domain, value >> PAGE_SHIFT);
+        v->arch.guest_table = pagetable_from_page(page);
 
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
     }
@@ -1914,46 +1899,29 @@ int hvm_virtual_to_linear_addr(
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
     void *map;
-    unsigned long mfn;
     p2m_type_t p2mt;
-    struct page_info *pg;
+    struct page_info *page;
     struct domain *d = current->domain;
-    int rc;
-
-    mfn = mfn_x(writable
-                ? get_gfn_unshare(d, gfn, &p2mt)
-                : get_gfn(d, gfn, &p2mt));
-    if ( (p2m_is_shared(p2mt) && writable) || !p2m_is_ram(p2mt) )
+
+    page = get_page_from_gfn(d, gfn, &p2mt,
+                             writable ? P2M_UNSHARE : P2M_ALLOC);
+    if ( (p2m_is_shared(p2mt) && writable) || !page )
     {
-        put_gfn(d, gfn);
+        if ( page )
+            put_page(page);
         return NULL;
     }
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gfn);
+        put_page(page);
         p2m_mem_paging_populate(d, gfn);
         return NULL;
     }
 
-    ASSERT(mfn_valid(mfn));
-
     if ( writable )
-        paging_mark_dirty(d, mfn);
-
-    /* Get a ref on the page, considering that it could be shared */
-    pg = mfn_to_page(mfn);
-    rc = get_page(pg, d);
-    if ( !rc && !writable )
-        /* Page could be shared */
-        rc = get_page(pg, dom_cow);
-    if ( !rc )
-    {
-        put_gfn(d, gfn);
-        return NULL;
-    }
-
-    map = map_domain_page(mfn);
-    put_gfn(d, gfn);
+        paging_mark_dirty(d, page_to_mfn(page));
+
+    map = __map_domain_page(page);
     return map;
 }
 
@@ -2358,7 +2326,8 @@ static enum hvm_copy_result __hvm_copy(
     void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2402,32 +2371,33 @@ static enum hvm_copy_result __hvm_copy(
             gfn = addr >> PAGE_SHIFT;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( flags & HVMCOPY_to_guest )
         {
@@ -2437,12 +2407,12 @@ static enum hvm_copy_result __hvm_copy(
                 if ( xchg(&lastpage, gfn) != gfn )
                     gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                              " memory page. gfn=%#lx, mfn=%#lx\n",
-                             gfn, mfn);
+                             gfn, page_to_mfn(page));
             }
             else
             {
                 memcpy(p, buf, count);
-                paging_mark_dirty(curr->domain, mfn);
+                paging_mark_dirty(curr->domain, page_to_mfn(page));
             }
         }
         else
@@ -2455,7 +2425,7 @@ static enum hvm_copy_result __hvm_copy(
         addr += count;
         buf  += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -2464,7 +2434,8 @@ static enum hvm_copy_result __hvm_copy(
 static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2500,32 +2471,35 @@ static enum hvm_copy_result __hvm_clear(
             return HVMCOPY_bad_gva_to_gfn;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( p2mt == p2m_ram_ro )
         {
@@ -2533,19 +2507,19 @@ static enum hvm_copy_result __hvm_clear(
             if ( xchg(&lastpage, gfn) != gfn )
                 gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                         " memory page. gfn=%#lx, mfn=%#lx\n",
-                        gfn, mfn);
+                         gfn, page_to_mfn(page));
         }
         else
         {
             memset(p, 0x00, count);
-            paging_mark_dirty(curr->domain, mfn);
+            paging_mark_dirty(curr->domain, page_to_mfn(page));
         }
 
         unmap_domain_page(p);
 
         addr += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -4000,35 +3974,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
 
         for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
         {
-            p2m_type_t t;
-            mfn_t mfn = get_gfn_unshare(d, pfn, &t);
-            if ( p2m_is_paging(t) )
+            struct page_info *page;
+            page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
+            if ( page )
             {
-                put_gfn(d, pfn);
-                p2m_mem_paging_populate(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            if( p2m_is_shared(t) )
-            {
-                /* If it insists on not unsharing itself, crash the domain 
-                 * rather than crashing the host down in mark dirty */
-                gdprintk(XENLOG_WARNING,
-                         "shared pfn 0x%lx modified?\n", pfn);
-                domain_crash(d);
-                put_gfn(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            
-            if ( mfn_x(mfn) != INVALID_MFN )
-            {
-                paging_mark_dirty(d, mfn_x(mfn));
+                paging_mark_dirty(d, page_to_mfn(page));
                 /* These are most probably not page tables any more */
                 /* don't take a long time and don't die either */
-                sh_remove_shadows(d->vcpu[0], mfn, 1, 0);
+                sh_remove_shadows(d->vcpu[0], _mfn(page_to_mfn(page)), 1, 0);
+                put_page(page);
             }
-            put_gfn(d, pfn);
         }
 
     param_fail3:
diff -r 107285938c50 xen/arch/x86/hvm/stdvga.c
--- a/xen/arch/x86/hvm/stdvga.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/stdvga.c	Thu Apr 26 22:00:25 2012 +0100
@@ -482,7 +482,8 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_to_guest_phys(data, &tmp, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                            d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     /*
                      * The only case we handle is vga_mem <-> vga_mem.
                      * Anything else disables caching and leaves it to qemu-dm.
@@ -490,11 +491,12 @@ static int mmio_move(struct hvm_hw_stdvg
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
+                    ASSERT(!dp);
                     stdvga_mem_write(data, tmp, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 data += sign * p->size;
                 addr += sign * p->size;
@@ -508,15 +510,16 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_from_guest_phys(&tmp, data, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                        d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
                     tmp = stdvga_mem_read(data, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 stdvga_mem_write(addr, tmp, p->size);
                 data += sign * p->size;
diff -r 107285938c50 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/viridian.c	Thu Apr 26 22:00:25 2012 +0100
@@ -134,18 +134,19 @@ void dump_apic_assist(struct vcpu *v)
 static void enable_hypercall_page(struct domain *d)
 {
     unsigned long gmfn = d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     /*
      * We set the bit 31 in %eax (reserved field in the Viridian hypercall
@@ -162,15 +163,14 @@ static void enable_hypercall_page(struct
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 void initialize_apic_assist(struct vcpu *v)
 {
     struct domain *d = v->domain;
     unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
     /*
@@ -183,22 +183,22 @@ void initialize_apic_assist(struct vcpu 
      * details of how Windows uses the page.
      */
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     *(u32 *)p = 0;
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
diff -r 107285938c50 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 26 22:00:25 2012 +0100
@@ -480,17 +480,16 @@ static void vmx_vmcs_save(struct vcpu *v
 static int vmx_restore_cr0_cr3(
     struct vcpu *v, unsigned long cr0, unsigned long cr3)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
 
     if ( paging_mode_shadow(v->domain) )
     {
         if ( cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3);
                 return -EINVAL;
             }
@@ -499,9 +498,8 @@ static int vmx_restore_cr0_cr3(
         if ( hvm_paging_enabled(v) )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( cr0 & X86_CR0_PG )
-            put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+        v->arch.guest_table =
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = cr0 | X86_CR0_ET;
@@ -1026,8 +1024,9 @@ static void vmx_set_interrupt_shadow(str
 
 static void vmx_load_pdptrs(struct vcpu *v)
 {
-    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn;
+    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3];
     uint64_t *guest_pdptrs;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
 
@@ -1038,24 +1037,19 @@ static void vmx_load_pdptrs(struct vcpu 
     if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
 
-    mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-    if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || 
-         /* If we didn't succeed in unsharing, get_page will fail
-          * (page still belongs to dom_cow) */
-         !get_page(mfn_to_page(mfn), v->domain) )
+    page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE);
+    if ( !page )
     {
         /* Ideally you don't want to crash but rather go into a wait 
          * queue, but this is the wrong place. We're holding at least
          * the paging lock */
         gdprintk(XENLOG_ERR,
-                 "Bad cr3 on load pdptrs gfn %lx mfn %lx type %d\n",
-                 cr3 >> PAGE_SHIFT, mfn, (int) p2mt);
-        put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+                 "Bad cr3 on load pdptrs gfn %lx type %d\n",
+                 cr3 >> PAGE_SHIFT, (int) p2mt);
         goto crash;
     }
-    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
-
-    p = map_domain_page(mfn);
+
+    p = __map_domain_page(page);
 
     guest_pdptrs = (uint64_t *)(p + (cr3 & ~PAGE_MASK));
 
@@ -1081,7 +1075,7 @@ static void vmx_load_pdptrs(struct vcpu 
     vmx_vmcs_exit(v);
 
     unmap_domain_page(p);
-    put_page(mfn_to_page(mfn));
+    put_page(page);
     return;
 
  crash:
diff -r 107285938c50 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm.c	Thu Apr 26 22:00:25 2012 +0100
@@ -651,7 +651,8 @@ int map_ldt_shadow_page(unsigned int off
 {
     struct vcpu *v = current;
     struct domain *d = v->domain;
-    unsigned long gmfn, mfn;
+    unsigned long gmfn;
+    struct page_info *page;
     l1_pgentry_t l1e, nl1e;
     unsigned long gva = v->arch.pv_vcpu.ldt_base + (off << PAGE_SHIFT);
     int okay;
@@ -663,28 +664,24 @@ int map_ldt_shadow_page(unsigned int off
         return 0;
 
     gmfn = l1e_get_pfn(l1e);
-    mfn = get_gfn_untyped(d, gmfn);
-    if ( unlikely(!mfn_valid(mfn)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+    if ( unlikely(!page) )
+        return 0;
+
+    okay = get_page_type(page, PGT_seg_desc_page);
+    if ( unlikely(!okay) )
     {
-        put_gfn(d, gmfn); 
+        put_page(page);
         return 0;
     }
 
-    okay = get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page);
-    if ( unlikely(!okay) )
-    {
-        put_gfn(d, gmfn); 
-        return 0;
-    }
-
-    nl1e = l1e_from_pfn(mfn, l1e_get_flags(l1e) | _PAGE_RW);
+    nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW);
 
     spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock);
     l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e);
     v->arch.pv_vcpu.shadow_ldt_mapcnt++;
     spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock);
 
-    put_gfn(d, gmfn); 
     return 1;
 }
 
@@ -1819,7 +1816,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
 {
     l1_pgentry_t ol1e;
     struct domain *pt_dom = pt_vcpu->domain;
-    p2m_type_t p2mt;
     int rc = 0;
 
     if ( unlikely(__copy_from_user(&ol1e, pl1e, sizeof(ol1e)) != 0) )
@@ -1835,22 +1831,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
     if ( l1e_get_flags(nl1e) & _PAGE_PRESENT )
     {
         /* Translate foreign guest addresses. */
-        unsigned long mfn, gfn;
-        gfn = l1e_get_pfn(nl1e);
-        mfn = mfn_x(get_gfn(pg_dom, gfn, &p2mt));
-        if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) )
+        struct page_info *page = NULL;
+        if ( paging_mode_translate(pg_dom) )
         {
-            put_gfn(pg_dom, gfn);
-            return -EINVAL;
+            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, P2M_ALLOC);
+            if ( !page )
+                return -EINVAL;
+            nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(nl1e));
         }
-        ASSERT((mfn & ~(PADDR_MASK >> PAGE_SHIFT)) == 0);
-        nl1e = l1e_from_pfn(mfn, l1e_get_flags(nl1e));
 
         if ( unlikely(l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)) )
         {
             MEM_LOG("Bad L1 flags %x",
                     l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom));
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return -EINVAL;
         }
 
@@ -1860,15 +1855,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
             adjust_guest_l1e(nl1e, pt_dom);
             if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                               preserve_ad) )
+            {
+                if ( page )
+                    put_page(page);
                 return 0;
-            put_gfn(pg_dom, gfn);
+            }
+            if ( page )
+                put_page(page);
             return -EBUSY;
         }
 
         switch ( rc = get_page_from_l1e(nl1e, pt_dom, pg_dom) )
         {
         default:
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return rc;
         case 0:
             break;
@@ -1876,7 +1877,9 @@ static int mod_l1_entry(l1_pgentry_t *pl
             l1e_remove_flags(nl1e, _PAGE_RW);
             break;
         }
-        
+        if ( page )
+            put_page(page);
+
         adjust_guest_l1e(nl1e, pt_dom);
         if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                     preserve_ad)) )
@@ -1884,7 +1887,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
             ol1e = nl1e;
             rc = -EBUSY;
         }
-        put_gfn(pg_dom, gfn);
     }
     else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                      preserve_ad)) )
@@ -3042,7 +3044,6 @@ int do_mmuext_op(
             type = PGT_l4_page_table;
 
         pin_page: {
-            unsigned long mfn;
             struct page_info *page;
 
             /* Ignore pinning of invalid paging levels. */
@@ -3052,25 +3053,28 @@ int do_mmuext_op(
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            rc = get_page_and_type_from_pagenr(mfn, type, pg_owner, 0, 1);
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
+            {
+                rc = -EINVAL;
+                break;
+            }
+
+            rc = get_page_type_preemptible(page, type);
             okay = !rc;
             if ( unlikely(!okay) )
             {
                 if ( rc == -EINTR )
                     rc = -EAGAIN;
                 else if ( rc != -EAGAIN )
-                    MEM_LOG("Error while pinning mfn %lx", mfn);
-                put_gfn(pg_owner, op.arg1.mfn);
+                    MEM_LOG("Error while pinning mfn %lx", page_to_mfn(page));
+                put_page(page);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( (rc = xsm_memory_pin_page(d, page)) != 0 )
             {
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
@@ -3078,16 +3082,15 @@ int do_mmuext_op(
             if ( unlikely(test_and_set_bit(_PGT_pinned,
                                            &page->u.inuse.type_info)) )
             {
-                MEM_LOG("Mfn %lx already pinned", mfn);
+                MEM_LOG("Mfn %lx already pinned", page_to_mfn(page));
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
 
             /* A page is dirtied when its pin status is set. */
-            paging_mark_dirty(pg_owner, mfn);
-           
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             /* We can race domain destruction (domain_relinquish_resources). */
             if ( unlikely(pg_owner != d) )
             {
@@ -3099,35 +3102,29 @@ int do_mmuext_op(
                 spin_unlock(&pg_owner->page_alloc_lock);
                 if ( drop_ref )
                     put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
             }
 
             break;
         }
 
         case MMUEXT_UNPIN_TABLE: {
-            unsigned long mfn;
             struct page_info *page;
 
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            if ( unlikely(!(okay = get_page_from_pagenr(mfn, pg_owner))) )
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
             {
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx bad domain", mfn);
+                MEM_LOG("Mfn %lx bad domain", op.arg1.mfn);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( !test_and_clear_bit(_PGT_pinned, &page->u.inuse.type_info) )
             {
                 okay = 0;
                 put_page(page);
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx not pinned", mfn);
+                MEM_LOG("Mfn %lx not pinned", op.arg1.mfn);
                 break;
             }
 
@@ -3135,40 +3132,43 @@ int do_mmuext_op(
             put_page(page);
 
             /* A page is dirtied when its pin status is cleared. */
-            paging_mark_dirty(pg_owner, mfn);
-
-            put_gfn(pg_owner, op.arg1.mfn);
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             break;
         }
 
         case MMUEXT_NEW_BASEPTR:
-            okay = new_guest_cr3(get_gfn_untyped(d, op.arg1.mfn));
-            put_gfn(d, op.arg1.mfn);
+            okay = (!paging_mode_translate(d)
+                    && new_guest_cr3(op.arg1.mfn));
             break;
+
         
 #ifdef __x86_64__
         case MMUEXT_NEW_USER_BASEPTR: {
-            unsigned long old_mfn, mfn;
-
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            if ( mfn != 0 )
+            unsigned long old_mfn;
+
+            if ( paging_mode_translate(current->domain) )
+            {
+                okay = 0;
+                break;
+            }
+
+            if ( op.arg1.mfn != 0 )
             {
                 if ( paging_mode_refcounts(d) )
-                    okay = get_page_from_pagenr(mfn, d);
+                    okay = get_page_from_pagenr(op.arg1.mfn, d);
                 else
                     okay = !get_page_and_type_from_pagenr(
-                        mfn, PGT_root_page_table, d, 0, 0);
+                        op.arg1.mfn, PGT_root_page_table, d, 0, 0);
                 if ( unlikely(!okay) )
                 {
-                    put_gfn(d, op.arg1.mfn);
-                    MEM_LOG("Error while installing new mfn %lx", mfn);
+                    MEM_LOG("Error while installing new mfn %lx", op.arg1.mfn);
                     break;
                 }
             }
 
             old_mfn = pagetable_get_pfn(curr->arch.guest_table_user);
-            curr->arch.guest_table_user = pagetable_from_pfn(mfn);
-            put_gfn(d, op.arg1.mfn);
+            curr->arch.guest_table_user = pagetable_from_pfn(op.arg1.mfn);
 
             if ( old_mfn != 0 )
             {
@@ -3283,28 +3283,26 @@ int do_mmuext_op(
         }
 
         case MMUEXT_CLEAR_PAGE: {
-            unsigned long mfn;
+            struct page_info *page;
             unsigned char *ptr;
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
+            page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( !page || get_page_type(page, PGT_writable_page) )
             {
-                put_gfn(d, op.arg1.mfn);
-                MEM_LOG("Error while clearing mfn %lx", mfn);
+                if ( page )
+                    put_page(page);
+                MEM_LOG("Error while clearing mfn %lx", op.arg1.mfn);
                 break;
             }
 
             /* A page is dirtied when it's being cleared. */
-            paging_mark_dirty(d, mfn);
-
-            ptr = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(page));
+
+            ptr = fixmap_domain_page(page_to_mfn(page));
             clear_page(ptr);
             fixunmap_domain_page(ptr);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
+            put_page_and_type(page);
             break;
         }
 
@@ -3312,42 +3310,38 @@ int do_mmuext_op(
         {
             const unsigned char *src;
             unsigned char *dst;
-            unsigned long src_mfn, mfn;
-
-            src_mfn = get_gfn_untyped(d, op.arg2.src_mfn);
-            okay = get_page_from_pagenr(src_mfn, d);
+            struct page_info *src_page, *dst_page;
+
+            src_page = get_page_from_gfn(d, op.arg2.src_mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!src_page) )
+            {
+                okay = 0;
+                MEM_LOG("Error while copying from mfn %lx", op.arg2.src_mfn);
+                break;
+            }
+
+            dst_page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            okay = (dst_page && get_page_type(dst_page, PGT_writable_page));
             if ( unlikely(!okay) )
             {
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying from mfn %lx", src_mfn);
+                put_page(src_page);
+                if ( dst_page )
+                    put_page(dst_page);
+                MEM_LOG("Error while copying to mfn %lx", op.arg1.mfn);
                 break;
             }
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
-            {
-                put_gfn(d, op.arg1.mfn);
-                put_page(mfn_to_page(src_mfn));
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying to mfn %lx", mfn);
-                break;
-            }
-
             /* A page is dirtied when it's being copied to. */
-            paging_mark_dirty(d, mfn);
-
-            src = map_domain_page(src_mfn);
-            dst = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(dst_page));
+
+            src = __map_domain_page(src_page);
+            dst = fixmap_domain_page(page_to_mfn(dst_page));
             copy_page(dst, src);
             fixunmap_domain_page(dst);
             unmap_domain_page(src);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
-            put_page(mfn_to_page(src_mfn));
-            put_gfn(d, op.arg2.src_mfn);
+            put_page_and_type(dst_page);
+            put_page(src_page);
             break;
         }
 
@@ -3538,29 +3532,26 @@ int do_mmu_update(
 
             req.ptr -= cmd;
             gmfn = req.ptr >> PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(pt_owner, gmfn, &p2mt));
-            if ( !p2m_is_valid(p2mt) )
-                mfn = INVALID_MFN;
+            page = get_page_from_gfn(pt_owner, gmfn, &p2mt, P2M_ALLOC);
 
             if ( p2m_is_paged(p2mt) )
             {
-                put_gfn(pt_owner, gmfn);
+                ASSERT(!page);
                 p2m_mem_paging_populate(pg_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
 
-            if ( unlikely(!get_page_from_pagenr(mfn, pt_owner)) )
+            if ( unlikely(!page) )
             {
                 MEM_LOG("Could not get page for normal update");
-                put_gfn(pt_owner, gmfn);
                 break;
             }
 
+            mfn = page_to_mfn(page);
             va = map_domain_page_with_cache(mfn, &mapcache);
             va = (void *)((unsigned long)va +
                           (unsigned long)(req.ptr & ~PAGE_MASK));
-            page = mfn_to_page(mfn);
 
             if ( page_lock(page) )
             {
@@ -3569,22 +3560,23 @@ int do_mmu_update(
                 case PGT_l1_page_table:
                 {
                     l1_pgentry_t l1e = l1e_from_intpte(req.val);
-                    p2m_type_t l1e_p2mt;
-                    unsigned long l1egfn = l1e_get_pfn(l1e), l1emfn;
-    
-                    l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
+                    p2m_type_t l1e_p2mt = p2m_ram_rw;
+                    struct page_info *target = NULL;
+
+                    if ( paging_mode_translate(pg_owner) )
+                        target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
+                                                   &l1e_p2mt, P2M_ALLOC);
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
-                        put_gfn(pg_owner, l1egfn);
+                        if ( target )
+                            put_page(target);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in == l1e_p2mt && 
-                                !mfn_valid(l1emfn) )
+                    else if ( p2m_ram_paging_in == l1e_p2mt && !target )
                     {
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3601,7 +3593,8 @@ int do_mmu_update(
                             rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
                             if ( rc )
                             {
-                                put_gfn(pg_owner, l1egfn);
+                                if ( target )
+                                    put_page(target);
                                 /* Notify helper, don't care about errors, will not
                                  * sleep on wq, since we're a foreign domain. */
                                 (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
@@ -3614,112 +3607,22 @@ int do_mmu_update(
                     rc = mod_l1_entry(va, l1e, mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
                                       pg_owner);
-                    put_gfn(pg_owner, l1egfn);
+                    if ( target )
+                        put_page(target);
                 }
                 break;
                 case PGT_l2_page_table:
-                {
-                    l2_pgentry_t l2e = l2e_from_intpte(req.val);
-                    p2m_type_t l2e_p2mt;
-                    unsigned long l2egfn = l2e_get_pfn(l2e), l2emfn;
-
-                    l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
-
-                    if ( p2m_is_paged(l2e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l2e_p2mt && 
-                                !mfn_valid(l2emfn) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l2e_p2mt )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-
-                    rc = mod_l2_entry(va, l2e, mfn,
+                    rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
-                    put_gfn(pg_owner, l2egfn);
-                }
-                break;
+                    break;
                 case PGT_l3_page_table:
-                {
-                    l3_pgentry_t l3e = l3e_from_intpte(req.val);
-                    p2m_type_t l3e_p2mt;
-                    unsigned long l3egfn = l3e_get_pfn(l3e), l3emfn;
-
-                    l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
-
-                    if ( p2m_is_paged(l3e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l3e_p2mt && 
-                                !mfn_valid(l3emfn) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l3e_p2mt )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l3_entry(va, l3e, mfn,
+                    rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l3egfn);
-                }
-                break;
+                    break;
 #if CONFIG_PAGING_LEVELS >= 4
                 case PGT_l4_page_table:
-                {
-                    l4_pgentry_t l4e = l4e_from_intpte(req.val);
-                    p2m_type_t l4e_p2mt;
-                    unsigned long l4egfn = l4e_get_pfn(l4e), l4emfn;
-
-                    l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
-
-                    if ( p2m_is_paged(l4e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l4e_p2mt && 
-                                !mfn_valid(l4emfn) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l4e_p2mt )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l4_entry(va, l4e, mfn,
+                    rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l4egfn);
-                }
                 break;
 #endif
                 case PGT_writable_page:
@@ -3742,7 +3645,6 @@ int do_mmu_update(
 
             unmap_domain_page_with_cache(va, &mapcache);
             put_page(page);
-            put_gfn(pt_owner, gmfn);
         }
         break;
 
diff -r 107285938c50 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/guest_walk.c	Thu Apr 26 22:00:25 2012 +0100
@@ -94,39 +94,37 @@ static inline void *map_domain_gfn(struc
                                    p2m_type_t *p2mt,
                                    uint32_t *rc) 
 {
-    p2m_access_t p2ma;
+    struct page_info *page;
     void *map;
 
     /* Translate the gfn, unsharing if shared */
-    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, 
-                               P2M_ALLOC | P2M_UNSHARE, NULL);
+    page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), p2mt, NULL,
+                                  P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
     if ( p2m_is_shared(*p2mt) )
     {
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         *rc = _PAGE_SHARED;
         return NULL;
     }
-    if ( !p2m_is_ram(*p2mt) ) 
+    if ( !page )
     {
-        __put_gfn(p2m, gfn_x(gfn));
         *rc |= _PAGE_PRESENT;
         return NULL;
     }
+    *mfn = _mfn(page_to_mfn(page));
     ASSERT(mfn_valid(mfn_x(*mfn)));
-    
-    /* Get an extra ref to the page to ensure liveness of the map.
-     * Then we can safely put gfn */
-    page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn)));
+
     map = map_domain_page(mfn_x(*mfn));
-    __put_gfn(p2m, gfn_x(gfn));
     return map;
 }
 
diff -r 107285938c50 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/hap/guest_walk.c	Thu Apr 26 22:00:25 2012 +0100
@@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     mfn_t top_mfn;
     void *top_map;
     p2m_type_t p2mt;
-    p2m_access_t p2ma;
     walk_t gw;
     unsigned long top_gfn;
+    struct page_info *top_page;
 
     /* Get the top-level table's MFN */
     top_gfn = cr3 >> PAGE_SHIFT;
-    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, 
-                                  P2M_ALLOC | P2M_UNSHARE, NULL);
+    top_page = get_page_from_gfn_p2m(p2m->domain, p2m, top_gfn,
+                                     &p2mt, NULL, P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         pfec[0] = PFEC_page_paged;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
     {
         pfec[0] = PFEC_page_shared;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         return INVALID_GFN;
     }
-    if ( !p2m_is_ram(p2mt) )
+    if ( !top_page )
     {
         pfec[0] &= ~PFEC_page_present;
-        __put_gfn(p2m, top_gfn);
+        put_page(top_page);
         return INVALID_GFN;
     }
+    top_mfn = _mfn(page_to_mfn(top_page));
 
     /* Map the top-level table and call the tree-walker */
     ASSERT(mfn_valid(mfn_x(top_mfn)));
@@ -91,31 +94,30 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 #endif
     missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map);
     unmap_domain_page(top_map);
-    __put_gfn(p2m, top_gfn);
+    put_page(top_page);
 
     /* Interpret the answer */
     if ( missing == 0 )
     {
         gfn_t gfn = guest_l1e_get_gfn(gw.l1e);
-        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
-                                  P2M_ALLOC | P2M_UNSHARE, NULL); 
+        struct page_info *page;
+        page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), &p2mt,
+                                     NULL, P2M_ALLOC | P2M_UNSHARE);
+        if ( page )
+            put_page(page);
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
             pfec[0] = PFEC_page_paged;
-            __put_gfn(p2m, gfn_x(gfn));
             p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
         {
             pfec[0] = PFEC_page_shared;
-            __put_gfn(p2m, gfn_x(gfn));
             return INVALID_GFN;
         }
 
-        __put_gfn(p2m, gfn_x(gfn));
-
         if ( page_order )
             *page_order = guest_walk_to_page_order(&gw);
 
diff -r 107285938c50 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Thu Apr 26 22:00:25 2012 +0100
@@ -166,13 +166,39 @@ declare_mm_lock(nestedp2m)
  * and later mutate it.
  */
 
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
+/* P2M lock is become an rwlock, purely so we can implement
+ * get_page_from_gfn.  The mess below is a ghastly hack to make a
+ * recursive rwlock.  If it works I'll come back and fix up the
+ * order-contraints magic. */
+
+static inline void p2m_lock(struct p2m_domain *p)
+{
+    if ( p->wcpu != current->processor )
+    {
+        write_lock(&p->lock);
+        p->wcpu = current->processor;
+        ASSERT(p->wcount == 0);
+    }
+    p->wcount++;
+}
+
+static inline void p2m_unlock(struct p2m_domain *p)
+{
+    ASSERT(p->wcpu == current->processor);
+    if (--(p->wcount) == 0)
+    {
+        p->wcpu = -1;
+        write_unlock(&p->lock);
+    }
+}
+
+#define gfn_lock(p,g,o)       p2m_lock(p)
+#define gfn_unlock(p,g,o)     p2m_unlock(p)
+#define p2m_read_lock(p)      read_lock(&(p)->lock)
+#define p2m_read_unlock(p)    read_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   ((p)->wcpu == current->processor)
+#define gfn_locked_by_me(p,g) p2m_locked_by_me(p)
+
 
 /* Sharing per page lock
  *
@@ -203,8 +229,8 @@ declare_mm_order_constraint(per_page_sha
  * counts, page lists, sweep parameters. */
 
 declare_mm_lock(pod)
-#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
-#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_lock(p) do { p2m_lock(p); mm_lock(pod, &(p)->pod.lock); } while (0)
+#define pod_unlock(p) do { mm_unlock(&(p)->pod.lock); p2m_unlock(p);} while (0)
 #define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
 
 /* Page alloc lock (per-domain)
diff -r 107285938c50 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 26 22:00:25 2012 +0100
@@ -71,7 +71,9 @@ boolean_param("hap_2mb", opt_hap_2mb);
 /* Init the datastructures for later use by the p2m code */
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
-    mm_lock_init(&p2m->lock);
+    rwlock_init(&p2m->lock);
+    p2m->wcount = 0;
+    p2m->wcpu = -1;
     mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
@@ -207,6 +209,61 @@ void __put_gfn(struct p2m_domain *p2m, u
     gfn_unlock(p2m, gfn, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page. */
+struct page_info *get_page_from_gfn_p2m(
+    struct domain *d, struct p2m_domain *p2m, unsigned long gfn,
+    p2m_type_t *t, p2m_access_t *a, p2m_query_t q)
+{
+    struct page_info *page = NULL;
+    p2m_access_t _a;
+    p2m_type_t _t;
+    mfn_t mfn;
+
+    /* Allow t or a to be NULL */
+    t = t ?: &_t;
+    a = a ?: &_a;
+
+    if ( likely(!p2m_locked_by_me(p2m)) )
+    {
+        /* Fast path: look up and get out */
+        p2m_read_lock(p2m);
+        mfn = __get_gfn_type_access(p2m, gfn, t, a, 0, NULL, 0);
+        if ( (p2m_is_ram(*t) || p2m_is_grant(*t))
+             && mfn_valid(mfn)
+             && !((q & P2M_UNSHARE) && p2m_is_shared(*t)) )
+        {
+            page = mfn_to_page(mfn);
+            if ( !get_page(page, d)
+                 /* Page could be shared */
+                 && !get_page(page, dom_cow) )
+                page = NULL;
+        }
+        p2m_read_unlock(p2m);
+
+        if ( page )
+            return page;
+
+        /* Error path: not a suitable GFN at all */
+        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) )
+            return NULL;
+    }
+
+    /* Slow path: take the write lock and do fixups */
+    p2m_lock(p2m);
+    mfn = get_gfn_type_access(p2m, gfn, t, a, q, NULL);
+    if ( p2m_is_ram(*t) && mfn_valid(mfn) )
+    {
+        page = mfn_to_page(mfn);
+        if ( !get_page(page, d) )
+            page = NULL;
+    }
+    put_gfn(d, gfn);
+    p2m_unlock(p2m);
+
+    return page;
+}
+
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 107285938c50 xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/physdev.c	Thu Apr 26 22:00:25 2012 +0100
@@ -306,26 +306,27 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
     case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
+        struct page_info *page;
 
         ret = -EFAULT;
         if ( copy_from_guest(&info, arg, 1) != 0 )
             break;
 
         ret = -EINVAL;
-        mfn = get_gfn_untyped(current->domain, info.gmfn);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), v->domain,
-                                PGT_writable_page) )
+        page = get_page_from_gfn(current->domain, info.gmfn, NULL, P2M_ALLOC);
+        if ( !page )
+            break;
+        if ( !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(current->domain, info.gmfn);
+            put_page(page);
             break;
         }
+        mfn = page_to_mfn(page);
 
         if ( cmpxchg(&v->domain->arch.pv_domain.pirq_eoi_map_mfn,
                      0, mfn) != 0 )
         {
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -EBUSY;
             break;
         }
@@ -335,14 +336,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         {
             v->domain->arch.pv_domain.pirq_eoi_map_mfn = 0;
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -ENOSPC;
             break;
         }
         if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
             v->domain->arch.pv_domain.auto_unmask = 1;
 
-        put_gfn(current->domain, info.gmfn);
         ret = 0;
         break;
     }
diff -r 107285938c50 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/traps.c	Thu Apr 26 22:00:25 2012 +0100
@@ -662,9 +662,9 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
     case 0:
     {
         void *hypercall_page;
-        unsigned long mfn;
         unsigned long gmfn = val >> 12;
         unsigned int idx  = val & 0xfff;
+        struct page_info *page;
 
         if ( idx > 0 )
         {
@@ -674,24 +674,23 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
             return 0;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
-
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn);
+            if ( page )
+                put_page(page);
             gdprintk(XENLOG_WARNING,
                      "Bad GMFN %lx (MFN %lx) to MSR %08x\n",
-                     gmfn, mfn, base + idx);
+                     gmfn, page_to_mfn(page), base + idx);
             return 0;
         }
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gmfn);
+        put_page_and_type(page);
         break;
     }
 
@@ -2374,7 +2373,8 @@ static int emulate_privileged_op(struct 
             break;
 
         case 3: {/* Write CR3 */
-            unsigned long mfn, gfn;
+            unsigned long gfn;
+            struct page_info *page;
             domain_lock(v->domain);
             if ( !is_pv_32on64_vcpu(v) )
             {
@@ -2384,9 +2384,10 @@ static int emulate_privileged_op(struct 
                 gfn = compat_cr3_to_pfn(*reg);
 #endif
             }
-            mfn = get_gfn_untyped(v->domain, gfn);
-            rc = new_guest_cr3(mfn);
-            put_gfn(v->domain, gfn);
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            rc = page ? new_guest_cr3(page_to_mfn(page)) : 0;
+            if ( page )
+                put_page(page);
             domain_unlock(v->domain);
             if ( rc == 0 ) /* not okay */
                 goto fail;
diff -r 107285938c50 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 26 22:00:25 2012 +0100
@@ -192,7 +192,10 @@ typedef unsigned int p2m_query_t;
 /* Per-p2m-table state */
 struct p2m_domain {
     /* Lock that protects updates to the p2m */
-    mm_lock_t          lock;
+    rwlock_t           lock;
+    int                wcpu;
+    int                wcount;
+    const char        *wfunc;
 
     /* Shadow translated domain: p2m mapping */
     pagetable_t        phys_table;
@@ -377,6 +380,33 @@ static inline mfn_t get_gfn_query_unlock
     return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page.
+ * This makes sure the page doesn't get freed (or shared) underfoot,
+ * and should be used by any path that intends to write to the backing page.
+ * Returns NULL if the page is not backed by RAM.
+ * The caller is responsible for calling put_page() afterwards. */
+struct page_info *get_page_from_gfn_p2m(struct domain *d,
+                                        struct p2m_domain *p2m,
+                                        unsigned long gfn,
+                                        p2m_type_t *t, p2m_access_t *a,
+                                        p2m_query_t q);
+
+static inline struct page_info *get_page_from_gfn(
+    struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
+{
+    struct page_info *page;
+
+    if ( paging_mode_translate(d) )
+        return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q);
+
+    /* Non-translated guests see 1-1 RAM mappings everywhere */
+    if (t)
+        *t = p2m_ram_rw;
+    page = __mfn_to_page(gfn);
+    return get_page(page, d) ? page : NULL;
+}
+
+
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)
 {
diff -r 107285938c50 xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/xsm/flask/hooks.c	Thu Apr 26 22:00:25 2012 +0100
@@ -1318,6 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
+    struct page_info *page;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1333,7 +1334,8 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+    mfn = page ? page_to_mfn(page) : INVALID_MFN;
 
     ad.sdom = d;
     ad.tdom = f;
@@ -1342,7 +1344,8 @@ static int flask_mmu_normal_update(struc
 
     rc = get_mfn_sid(fmfn, &fsid);
 
-    put_gfn(f, fmfn);
+    if ( page )
+        put_page(page);
 
     if ( rc )
         return rc;

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--qDbXVdCdHGoSgWSk--


From xen-devel-bounces@lists.xen.org Thu Apr 26 21:26:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 21:26:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNWC9-0001Mi-JI; Thu, 26 Apr 2012 21:25:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNWC7-0001Md-FJ
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 21:25:44 +0000
Received: from [85.158.143.35:28028] by server-2.bemta-4.messagelabs.com id
	E6/C4-17550-65DB99F4; Thu, 26 Apr 2012 21:25:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335475538!12797452!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9695 invoked from network); 26 Apr 2012 21:25:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 21:25:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNWBv-000Jj7-Nj; Thu, 26 Apr 2012 21:25:31 +0000
Date: Thu, 26 Apr 2012 22:25:31 +0100
From: Tim Deegan <tim@xen.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Message-ID: <20120426212531.GH67043@ocelot.phlegethon.org>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk"
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> > > But actually, the first cs introduced this issue is 24770. When win8
> > > booting and if hpet is enabled, it will use hpet as the time source
> > > and there have lots of hpet access and EPT violation. In EPT violation
> > > handler, it call get_gfn_type_access to get the mfn. The cs 24770
> > > introduces the gfn_lock for p2m lookups, and then the issue happens.
> > > After I removed the gfn_lock, the issue goes. But in latest xen, even
> > > I remove this lock, it still shows high cpu utilization.
> > 
> > It would seem then that even the briefest lock-protected critical section would
> > cause this? In the mmio case, the p2m lock taken in the hap fault handler is
> > held during the actual lookup, and for a couple of branch instructions
> > afterwards.
> > 
> > In latest Xen, with lock removed for get_gfn, on which lock is time spent?
> Still the p2m_lock.

Can you please try the attached patch?  I think you'll need this one
plus the ones that take the locks out of the hpet code. 

This patch makes the p2m lock into an rwlock and adjusts a number of the
paths that don't update the p2m so they only take the read lock.  It's a
bit rough but I can boot 16-way win7 guest with it.

N.B. Since rwlocks don't show up the the existing lock profiling, please
don't try to use the lock-profiling numbers to see if it's helping!

Andres, this is basically the big-hammer version of your "take a
pagecount" changes, plus the change you made to hvmemul_rep_movs().
If this works I intend to follow it up with a patch to make some of the
read-modify-write paths avoid taking the lock (by using a
compare-exchange operation so they only take the lock on a write).  If
that succeeds I might drop put_gfn() altogether. 

But first it will need a lot of tidying up.  Noticeably missing:
 - SVM code equivalents to the vmx.c changes
 - grant-table operations still use the lock, because frankly I 
   could not follow the current code, and it's quite late in the evening.
I also have a long list of uglinesses in the mm code that I found while
writing this lot. 

Keir, I have no objection to later replacing this with something better
than an rwlock. :)  Or with making a NUMA-friendly rwlock
implementation, since I really expect this to be heavily read-mostly
when paging/sharing/pod are not enabled.

Cheers,

Tim.
--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=get-page-from-gfn

# HG changeset patch
# Parent 107285938c50f82667bd4d014820b439a077c22c

diff -r 107285938c50 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domain.c	Thu Apr 26 22:00:25 2012 +0100
@@ -716,7 +716,7 @@ int arch_set_info_guest(
 {
     struct domain *d = v->domain;
     unsigned long cr3_gfn;
-    unsigned long cr3_pfn = INVALID_MFN;
+    struct page_info *cr3_page;
     unsigned long flags, cr4;
     unsigned int i;
     int rc = 0, compat;
@@ -925,46 +925,45 @@ int arch_set_info_guest(
     if ( !compat )
     {
         cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_base_page_table)) )
+        if ( !cr3_page )
         {
-            put_gfn(d, cr3_gfn);
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+        if ( !paging_mode_refcounts(d)
+             && !get_page_type(cr3_page, PGT_base_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
-        v->arch.guest_table = pagetable_from_pfn(cr3_pfn);
-        put_gfn(d, cr3_gfn);
+        v->arch.guest_table = pagetable_from_page(cr3_page);
 #ifdef __x86_64__
         if ( c.nat->ctrlreg[1] )
         {
             cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]);
-            cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+            cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-            if ( !mfn_valid(cr3_pfn) ||
-                 (paging_mode_refcounts(d)
-                  ? !get_page(mfn_to_page(cr3_pfn), d)
-                  : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                       PGT_base_page_table)) )
+            if ( !cr3_page ||
+                 (!paging_mode_refcounts(d)
+                  && !get_page_type(cr3_page, PGT_base_page_table)) )
             {
-                cr3_pfn = pagetable_get_pfn(v->arch.guest_table);
+                if (cr3_page)
+                    put_page(cr3_page);
+                cr3_page = pagetable_get_page(v->arch.guest_table);
                 v->arch.guest_table = pagetable_null();
                 if ( paging_mode_refcounts(d) )
-                    put_page(mfn_to_page(cr3_pfn));
+                    put_page(cr3_page);
                 else
-                    put_page_and_type(mfn_to_page(cr3_pfn));
-                put_gfn(d, cr3_gfn); 
+                    put_page_and_type(cr3_page);
                 destroy_gdt(v);
                 return -EINVAL;
             }
 
-            v->arch.guest_table_user = pagetable_from_pfn(cr3_pfn);
-            put_gfn(d, cr3_gfn); 
+            v->arch.guest_table_user = pagetable_from_page(cr3_page);
         }
         else if ( !(flags & VGCF_in_kernel) )
         {
@@ -977,23 +976,25 @@ int arch_set_info_guest(
         l4_pgentry_t *l4tab;
 
         cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_l3_page_table)) )
+        if ( !cr3_page)
         {
-            put_gfn(d, cr3_gfn); 
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+
+        if (!paging_mode_refcounts(d)
+            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
         l4tab = __va(pagetable_get_paddr(v->arch.guest_table));
-        *l4tab = l4e_from_pfn(
-            cr3_pfn, _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
-        put_gfn(d, cr3_gfn); 
+        *l4tab = l4e_from_pfn(page_to_mfn(cr3_page),
+            _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
 #endif
     }
 
@@ -1064,7 +1065,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     struct domain *d = v->domain;
     void *mapping;
     vcpu_info_t *new_info;
-    unsigned long mfn;
+    struct page_info *page;
     int i;
 
     if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) )
@@ -1077,19 +1078,20 @@ map_vcpu_info(struct vcpu *v, unsigned l
     if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) )
         return -EINVAL;
 
-    mfn = get_gfn_untyped(d, gfn);
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gfn); 
+        put_page(page);
         return -EINVAL;
     }
 
-    mapping = map_domain_page_global(mfn);
+    mapping = __map_domain_page_global(page);
     if ( mapping == NULL )
     {
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gfn); 
+        put_page_and_type(page);
         return -ENOMEM;
     }
 
@@ -1106,7 +1108,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     }
 
     v->vcpu_info = new_info;
-    v->arch.pv_vcpu.vcpu_info_mfn = mfn;
+    v->arch.pv_vcpu.vcpu_info_mfn = page_to_mfn(page);
 
     /* Set new vcpu_info pointer /before/ setting pending flags. */
     wmb();
@@ -1119,7 +1121,6 @@ map_vcpu_info(struct vcpu *v, unsigned l
     for ( i = 0; i < BITS_PER_EVTCHN_WORD(d); i++ )
         set_bit(i, &vcpu_info(v, evtchn_pending_sel));
 
-    put_gfn(d, gfn); 
     return 0;
 }
 
diff -r 107285938c50 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domctl.c	Thu Apr 26 22:00:25 2012 +0100
@@ -202,16 +202,16 @@ long arch_do_domctl(
 
                 for ( j = 0; j < k; j++ )
                 {
-                    unsigned long type = 0, mfn = get_gfn_untyped(d, arr[j]);
+                    unsigned long type = 0;
 
-                    page = mfn_to_page(mfn);
+                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
 
-                    if ( unlikely(!mfn_valid(mfn)) ||
-                         unlikely(is_xen_heap_mfn(mfn)) )
+                    if ( unlikely(!page) ||
+                         unlikely(is_xen_heap_page(page)) )
                         type = XEN_DOMCTL_PFINFO_XTAB;
                     else if ( xsm_getpageframeinfo(page) != 0 )
                         ;
-                    else if ( likely(get_page(page, d)) )
+                    else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
                         {
@@ -231,13 +231,10 @@ long arch_do_domctl(
 
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |= XEN_DOMCTL_PFINFO_LPINTAB;
+                    }
 
+                    if ( page )
                         put_page(page);
-                    }
-                    else
-                        type = XEN_DOMCTL_PFINFO_XTAB;
-
-                    put_gfn(d, arr[j]);
                     arr[j] = type;
                 }
 
@@ -304,21 +301,21 @@ long arch_do_domctl(
             {      
                 struct page_info *page;
                 unsigned long gfn = arr32[j];
-                unsigned long mfn = get_gfn_untyped(d, gfn);
 
-                page = mfn_to_page(mfn);
+                page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
 
                 if ( domctl->cmd == XEN_DOMCTL_getpageframeinfo3)
                     arr32[j] = 0;
 
-                if ( unlikely(!mfn_valid(mfn)) ||
-                     unlikely(is_xen_heap_mfn(mfn)) )
+                if ( unlikely(!page) ||
+                     unlikely(is_xen_heap_page(page)) )
                     arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
                 else if ( xsm_getpageframeinfo(page) != 0 )
                 {
-                    put_gfn(d, gfn); 
+                    put_page(page);
                     continue;
-                } else if ( likely(get_page(page, d)) )
+                }
+                else
                 {
                     unsigned long type = 0;
 
@@ -341,12 +338,10 @@ long arch_do_domctl(
                     if ( page->u.inuse.type_info & PGT_pinned )
                         type |= XEN_DOMCTL_PFINFO_LPINTAB;
                     arr32[j] |= type;
+                }
+
+                if ( page )
                     put_page(page);
-                }
-                else
-                    arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
-
-                put_gfn(d, gfn); 
             }
 
             if ( copy_to_guest_offset(domctl->u.getpageframeinfo2.array,
@@ -419,7 +414,7 @@ long arch_do_domctl(
     {
         struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long gmfn = domctl->u.hypercall_init.gmfn;
-        unsigned long mfn;
+        struct page_info *page;
         void *hypercall_page;
 
         ret = -ESRCH;
@@ -433,26 +428,25 @@ long arch_do_domctl(
             break;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
 
         ret = -EACCES;
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn); 
+            if ( page )
+                put_page(page);
             rcu_unlock_domain(d);
             break;
         }
 
         ret = 0;
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
+        put_page_and_type(page);
 
-        put_gfn(d, gmfn); 
         rcu_unlock_domain(d);
     }
     break;
diff -r 107285938c50 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/emulate.c	Thu Apr 26 22:00:25 2012 +0100
@@ -60,34 +60,25 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    struct page_info *ram_page;
     int rc;
 
     /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+    ram_page = get_page_from_gfn(curr->domain, ram_gfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         p2m_mem_paging_populate(curr->domain, ram_gfn);
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_RETRY;
     }
 
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
-        {
-            put_gfn(curr->domain, ram_gfn);
-            return X86EMUL_RETRY;
-        }
-    put_gfn(curr->domain, ram_gfn);
-
     /*
      * Weird-sized accesses have undefined behaviour: we discard writes
      * and read all-ones.
@@ -98,8 +89,8 @@ static int hvmemul_do_io(
         ASSERT(p_data != NULL); /* cannot happen with a REP prefix */
         if ( dir == IOREQ_READ )
             memset(p_data, ~0, size);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -120,8 +111,8 @@ static int hvmemul_do_io(
             unsigned int bytes = vio->mmio_large_write_bytes;
             if ( (addr >= pa) && ((addr + size) <= (pa + bytes)) )
             {
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -133,8 +124,8 @@ static int hvmemul_do_io(
             {
                 memcpy(p_data, &vio->mmio_large_read[addr - pa],
                        size);
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -148,8 +139,8 @@ static int hvmemul_do_io(
         vio->io_state = HVMIO_none;
         if ( p_data == NULL )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_UNHANDLEABLE;
         }
         goto finish_access;
@@ -159,13 +150,13 @@ static int hvmemul_do_io(
              (addr == (vio->mmio_large_write_pa +
                        vio->mmio_large_write_bytes)) )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_RETRY;
         }
     default:
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -173,8 +164,8 @@ static int hvmemul_do_io(
     {
         gdprintk(XENLOG_WARNING, "WARNING: io already pending (%d)?\n",
                  p->state);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -226,8 +217,8 @@ static int hvmemul_do_io(
 
     if ( rc != X86EMUL_OKAY )
     {
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return rc;
     }
 
@@ -263,8 +254,8 @@ static int hvmemul_do_io(
         }
     }
 
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        put_page(mfn_to_page(mfn_x(ram_mfn)));
+    if ( ram_page )
+        put_page(ram_page);
     return X86EMUL_OKAY;
 }
 
@@ -686,7 +677,6 @@ static int hvmemul_rep_movs(
     p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
-    struct two_gfns tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -714,25 +704,17 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
-                 current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 P2M_ALLOC, &tg);
+    /* Check for MMIO ops */
+    (void) get_gfn_query_unlocked(current->domain, sgpa >> PAGE_SHIFT, &sp2mt);
+    (void) get_gfn_query_unlocked(current->domain, dgpa >> PAGE_SHIFT, &dp2mt);
 
-    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( sp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
-    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( dp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +729,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +738,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +749,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 107285938c50 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Thu Apr 26 22:00:25 2012 +0100
@@ -395,48 +395,41 @@ int prepare_ring_for_helper(
 {
     struct page_info *page;
     p2m_type_t p2mt;
-    unsigned long mfn;
     void *va;
 
-    mfn = mfn_x(get_gfn_unshare(d, gmfn, &p2mt));
-    if ( !p2m_is_ram(p2mt) )
-    {
-        put_gfn(d, gmfn);
-        return -EINVAL;
-    }
+    page = get_page_from_gfn(d, gmfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         return -ENOENT;
     }
-    ASSERT(mfn_valid(mfn));
-
-    page = mfn_to_page(mfn);
-    if ( !get_page_and_type(page, d, PGT_writable_page) )
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn);
+        put_page(page);
         return -EINVAL;
     }
 
-    va = map_domain_page_global(mfn);
+    va = __map_domain_page_global(page);
     if ( va == NULL )
     {
         put_page_and_type(page);
-        put_gfn(d, gmfn);
         return -ENOMEM;
     }
 
     *_va = va;
     *_page = page;
 
-    put_gfn(d, gmfn);
-
     return 0;
 }
 
@@ -1607,8 +1600,8 @@ int hvm_mov_from_cr(unsigned int cr, uns
 int hvm_set_cr0(unsigned long value)
 {
     struct vcpu *v = current;
-    p2m_type_t p2mt;
-    unsigned long gfn, mfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    unsigned long gfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    struct page_info *page;
 
     HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR0 value = %lx", value);
 
@@ -1647,23 +1640,20 @@ int hvm_set_cr0(unsigned long value)
         {
             /* The guest CR3 must be pointing to the guest physical. */
             gfn = v->arch.hvm_vcpu.guest_cr[3]>>PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(v->domain, gfn, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-                 !get_page(mfn_to_page(mfn), v->domain))
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, gfn);
-                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx (mfn=%lx)\n",
-                         v->arch.hvm_vcpu.guest_cr[3], mfn);
+                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx\n",
+                         v->arch.hvm_vcpu.guest_cr[3]);
                 domain_crash(v->domain);
                 return X86EMUL_UNHANDLEABLE;
             }
 
             /* Now arch.guest_table points to machine physical. */
-            v->arch.guest_table = pagetable_from_pfn(mfn);
+            v->arch.guest_table = pagetable_from_page(page);
 
             HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx, mfn = %lx",
-                        v->arch.hvm_vcpu.guest_cr[3], mfn);
-            put_gfn(v->domain, gfn);
+                        v->arch.hvm_vcpu.guest_cr[3], page_to_mfn(page));
         }
     }
     else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) )
@@ -1738,26 +1728,21 @@ int hvm_set_cr0(unsigned long value)
 
 int hvm_set_cr3(unsigned long value)
 {
-    unsigned long mfn;
-    p2m_type_t p2mt;
     struct vcpu *v = current;
+    struct page_info *page;
 
     if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
          (value != v->arch.hvm_vcpu.guest_cr[3]) )
     {
         /* Shadow-mode CR3 change. Check PDBR and update refcounts. */
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "CR3 value = %lx", value);
-        mfn = mfn_x(get_gfn(v->domain, value >> PAGE_SHIFT, &p2mt));
-        if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-             !get_page(mfn_to_page(mfn), v->domain) )
-        {
-              put_gfn(v->domain, value >> PAGE_SHIFT);
-              goto bad_cr3;
-        }
+        page = get_page_from_gfn(v->domain, value >> PAGE_SHIFT,
+                                 NULL, P2M_ALLOC);
+        if ( !page )
+            goto bad_cr3;
 
         put_page(pagetable_get_page(v->arch.guest_table));
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        put_gfn(v->domain, value >> PAGE_SHIFT);
+        v->arch.guest_table = pagetable_from_page(page);
 
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
     }
@@ -1914,46 +1899,29 @@ int hvm_virtual_to_linear_addr(
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
     void *map;
-    unsigned long mfn;
     p2m_type_t p2mt;
-    struct page_info *pg;
+    struct page_info *page;
     struct domain *d = current->domain;
-    int rc;
-
-    mfn = mfn_x(writable
-                ? get_gfn_unshare(d, gfn, &p2mt)
-                : get_gfn(d, gfn, &p2mt));
-    if ( (p2m_is_shared(p2mt) && writable) || !p2m_is_ram(p2mt) )
+
+    page = get_page_from_gfn(d, gfn, &p2mt,
+                             writable ? P2M_UNSHARE : P2M_ALLOC);
+    if ( (p2m_is_shared(p2mt) && writable) || !page )
     {
-        put_gfn(d, gfn);
+        if ( page )
+            put_page(page);
         return NULL;
     }
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gfn);
+        put_page(page);
         p2m_mem_paging_populate(d, gfn);
         return NULL;
     }
 
-    ASSERT(mfn_valid(mfn));
-
     if ( writable )
-        paging_mark_dirty(d, mfn);
-
-    /* Get a ref on the page, considering that it could be shared */
-    pg = mfn_to_page(mfn);
-    rc = get_page(pg, d);
-    if ( !rc && !writable )
-        /* Page could be shared */
-        rc = get_page(pg, dom_cow);
-    if ( !rc )
-    {
-        put_gfn(d, gfn);
-        return NULL;
-    }
-
-    map = map_domain_page(mfn);
-    put_gfn(d, gfn);
+        paging_mark_dirty(d, page_to_mfn(page));
+
+    map = __map_domain_page(page);
     return map;
 }
 
@@ -2358,7 +2326,8 @@ static enum hvm_copy_result __hvm_copy(
     void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2402,32 +2371,33 @@ static enum hvm_copy_result __hvm_copy(
             gfn = addr >> PAGE_SHIFT;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( flags & HVMCOPY_to_guest )
         {
@@ -2437,12 +2407,12 @@ static enum hvm_copy_result __hvm_copy(
                 if ( xchg(&lastpage, gfn) != gfn )
                     gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                              " memory page. gfn=%#lx, mfn=%#lx\n",
-                             gfn, mfn);
+                             gfn, page_to_mfn(page));
             }
             else
             {
                 memcpy(p, buf, count);
-                paging_mark_dirty(curr->domain, mfn);
+                paging_mark_dirty(curr->domain, page_to_mfn(page));
             }
         }
         else
@@ -2455,7 +2425,7 @@ static enum hvm_copy_result __hvm_copy(
         addr += count;
         buf  += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -2464,7 +2434,8 @@ static enum hvm_copy_result __hvm_copy(
 static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2500,32 +2471,35 @@ static enum hvm_copy_result __hvm_clear(
             return HVMCOPY_bad_gva_to_gfn;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( p2mt == p2m_ram_ro )
         {
@@ -2533,19 +2507,19 @@ static enum hvm_copy_result __hvm_clear(
             if ( xchg(&lastpage, gfn) != gfn )
                 gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                         " memory page. gfn=%#lx, mfn=%#lx\n",
-                        gfn, mfn);
+                         gfn, page_to_mfn(page));
         }
         else
         {
             memset(p, 0x00, count);
-            paging_mark_dirty(curr->domain, mfn);
+            paging_mark_dirty(curr->domain, page_to_mfn(page));
         }
 
         unmap_domain_page(p);
 
         addr += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -4000,35 +3974,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
 
         for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
         {
-            p2m_type_t t;
-            mfn_t mfn = get_gfn_unshare(d, pfn, &t);
-            if ( p2m_is_paging(t) )
+            struct page_info *page;
+            page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
+            if ( page )
             {
-                put_gfn(d, pfn);
-                p2m_mem_paging_populate(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            if( p2m_is_shared(t) )
-            {
-                /* If it insists on not unsharing itself, crash the domain 
-                 * rather than crashing the host down in mark dirty */
-                gdprintk(XENLOG_WARNING,
-                         "shared pfn 0x%lx modified?\n", pfn);
-                domain_crash(d);
-                put_gfn(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            
-            if ( mfn_x(mfn) != INVALID_MFN )
-            {
-                paging_mark_dirty(d, mfn_x(mfn));
+                paging_mark_dirty(d, page_to_mfn(page));
                 /* These are most probably not page tables any more */
                 /* don't take a long time and don't die either */
-                sh_remove_shadows(d->vcpu[0], mfn, 1, 0);
+                sh_remove_shadows(d->vcpu[0], _mfn(page_to_mfn(page)), 1, 0);
+                put_page(page);
             }
-            put_gfn(d, pfn);
         }
 
     param_fail3:
diff -r 107285938c50 xen/arch/x86/hvm/stdvga.c
--- a/xen/arch/x86/hvm/stdvga.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/stdvga.c	Thu Apr 26 22:00:25 2012 +0100
@@ -482,7 +482,8 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_to_guest_phys(data, &tmp, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                            d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     /*
                      * The only case we handle is vga_mem <-> vga_mem.
                      * Anything else disables caching and leaves it to qemu-dm.
@@ -490,11 +491,12 @@ static int mmio_move(struct hvm_hw_stdvg
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
+                    ASSERT(!dp);
                     stdvga_mem_write(data, tmp, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 data += sign * p->size;
                 addr += sign * p->size;
@@ -508,15 +510,16 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_from_guest_phys(&tmp, data, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                        d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
                     tmp = stdvga_mem_read(data, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 stdvga_mem_write(addr, tmp, p->size);
                 data += sign * p->size;
diff -r 107285938c50 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/viridian.c	Thu Apr 26 22:00:25 2012 +0100
@@ -134,18 +134,19 @@ void dump_apic_assist(struct vcpu *v)
 static void enable_hypercall_page(struct domain *d)
 {
     unsigned long gmfn = d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     /*
      * We set the bit 31 in %eax (reserved field in the Viridian hypercall
@@ -162,15 +163,14 @@ static void enable_hypercall_page(struct
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 void initialize_apic_assist(struct vcpu *v)
 {
     struct domain *d = v->domain;
     unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
     /*
@@ -183,22 +183,22 @@ void initialize_apic_assist(struct vcpu 
      * details of how Windows uses the page.
      */
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     *(u32 *)p = 0;
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
diff -r 107285938c50 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 26 22:00:25 2012 +0100
@@ -480,17 +480,16 @@ static void vmx_vmcs_save(struct vcpu *v
 static int vmx_restore_cr0_cr3(
     struct vcpu *v, unsigned long cr0, unsigned long cr3)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
 
     if ( paging_mode_shadow(v->domain) )
     {
         if ( cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3);
                 return -EINVAL;
             }
@@ -499,9 +498,8 @@ static int vmx_restore_cr0_cr3(
         if ( hvm_paging_enabled(v) )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( cr0 & X86_CR0_PG )
-            put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+        v->arch.guest_table =
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = cr0 | X86_CR0_ET;
@@ -1026,8 +1024,9 @@ static void vmx_set_interrupt_shadow(str
 
 static void vmx_load_pdptrs(struct vcpu *v)
 {
-    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn;
+    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3];
     uint64_t *guest_pdptrs;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
 
@@ -1038,24 +1037,19 @@ static void vmx_load_pdptrs(struct vcpu 
     if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
 
-    mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-    if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || 
-         /* If we didn't succeed in unsharing, get_page will fail
-          * (page still belongs to dom_cow) */
-         !get_page(mfn_to_page(mfn), v->domain) )
+    page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE);
+    if ( !page )
     {
         /* Ideally you don't want to crash but rather go into a wait 
          * queue, but this is the wrong place. We're holding at least
          * the paging lock */
         gdprintk(XENLOG_ERR,
-                 "Bad cr3 on load pdptrs gfn %lx mfn %lx type %d\n",
-                 cr3 >> PAGE_SHIFT, mfn, (int) p2mt);
-        put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+                 "Bad cr3 on load pdptrs gfn %lx type %d\n",
+                 cr3 >> PAGE_SHIFT, (int) p2mt);
         goto crash;
     }
-    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
-
-    p = map_domain_page(mfn);
+
+    p = __map_domain_page(page);
 
     guest_pdptrs = (uint64_t *)(p + (cr3 & ~PAGE_MASK));
 
@@ -1081,7 +1075,7 @@ static void vmx_load_pdptrs(struct vcpu 
     vmx_vmcs_exit(v);
 
     unmap_domain_page(p);
-    put_page(mfn_to_page(mfn));
+    put_page(page);
     return;
 
  crash:
diff -r 107285938c50 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm.c	Thu Apr 26 22:00:25 2012 +0100
@@ -651,7 +651,8 @@ int map_ldt_shadow_page(unsigned int off
 {
     struct vcpu *v = current;
     struct domain *d = v->domain;
-    unsigned long gmfn, mfn;
+    unsigned long gmfn;
+    struct page_info *page;
     l1_pgentry_t l1e, nl1e;
     unsigned long gva = v->arch.pv_vcpu.ldt_base + (off << PAGE_SHIFT);
     int okay;
@@ -663,28 +664,24 @@ int map_ldt_shadow_page(unsigned int off
         return 0;
 
     gmfn = l1e_get_pfn(l1e);
-    mfn = get_gfn_untyped(d, gmfn);
-    if ( unlikely(!mfn_valid(mfn)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+    if ( unlikely(!page) )
+        return 0;
+
+    okay = get_page_type(page, PGT_seg_desc_page);
+    if ( unlikely(!okay) )
     {
-        put_gfn(d, gmfn); 
+        put_page(page);
         return 0;
     }
 
-    okay = get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page);
-    if ( unlikely(!okay) )
-    {
-        put_gfn(d, gmfn); 
-        return 0;
-    }
-
-    nl1e = l1e_from_pfn(mfn, l1e_get_flags(l1e) | _PAGE_RW);
+    nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW);
 
     spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock);
     l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e);
     v->arch.pv_vcpu.shadow_ldt_mapcnt++;
     spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock);
 
-    put_gfn(d, gmfn); 
     return 1;
 }
 
@@ -1819,7 +1816,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
 {
     l1_pgentry_t ol1e;
     struct domain *pt_dom = pt_vcpu->domain;
-    p2m_type_t p2mt;
     int rc = 0;
 
     if ( unlikely(__copy_from_user(&ol1e, pl1e, sizeof(ol1e)) != 0) )
@@ -1835,22 +1831,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
     if ( l1e_get_flags(nl1e) & _PAGE_PRESENT )
     {
         /* Translate foreign guest addresses. */
-        unsigned long mfn, gfn;
-        gfn = l1e_get_pfn(nl1e);
-        mfn = mfn_x(get_gfn(pg_dom, gfn, &p2mt));
-        if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) )
+        struct page_info *page = NULL;
+        if ( paging_mode_translate(pg_dom) )
         {
-            put_gfn(pg_dom, gfn);
-            return -EINVAL;
+            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, P2M_ALLOC);
+            if ( !page )
+                return -EINVAL;
+            nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(nl1e));
         }
-        ASSERT((mfn & ~(PADDR_MASK >> PAGE_SHIFT)) == 0);
-        nl1e = l1e_from_pfn(mfn, l1e_get_flags(nl1e));
 
         if ( unlikely(l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)) )
         {
             MEM_LOG("Bad L1 flags %x",
                     l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom));
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return -EINVAL;
         }
 
@@ -1860,15 +1855,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
             adjust_guest_l1e(nl1e, pt_dom);
             if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                               preserve_ad) )
+            {
+                if ( page )
+                    put_page(page);
                 return 0;
-            put_gfn(pg_dom, gfn);
+            }
+            if ( page )
+                put_page(page);
             return -EBUSY;
         }
 
         switch ( rc = get_page_from_l1e(nl1e, pt_dom, pg_dom) )
         {
         default:
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return rc;
         case 0:
             break;
@@ -1876,7 +1877,9 @@ static int mod_l1_entry(l1_pgentry_t *pl
             l1e_remove_flags(nl1e, _PAGE_RW);
             break;
         }
-        
+        if ( page )
+            put_page(page);
+
         adjust_guest_l1e(nl1e, pt_dom);
         if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                     preserve_ad)) )
@@ -1884,7 +1887,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
             ol1e = nl1e;
             rc = -EBUSY;
         }
-        put_gfn(pg_dom, gfn);
     }
     else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                      preserve_ad)) )
@@ -3042,7 +3044,6 @@ int do_mmuext_op(
             type = PGT_l4_page_table;
 
         pin_page: {
-            unsigned long mfn;
             struct page_info *page;
 
             /* Ignore pinning of invalid paging levels. */
@@ -3052,25 +3053,28 @@ int do_mmuext_op(
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            rc = get_page_and_type_from_pagenr(mfn, type, pg_owner, 0, 1);
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
+            {
+                rc = -EINVAL;
+                break;
+            }
+
+            rc = get_page_type_preemptible(page, type);
             okay = !rc;
             if ( unlikely(!okay) )
             {
                 if ( rc == -EINTR )
                     rc = -EAGAIN;
                 else if ( rc != -EAGAIN )
-                    MEM_LOG("Error while pinning mfn %lx", mfn);
-                put_gfn(pg_owner, op.arg1.mfn);
+                    MEM_LOG("Error while pinning mfn %lx", page_to_mfn(page));
+                put_page(page);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( (rc = xsm_memory_pin_page(d, page)) != 0 )
             {
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
@@ -3078,16 +3082,15 @@ int do_mmuext_op(
             if ( unlikely(test_and_set_bit(_PGT_pinned,
                                            &page->u.inuse.type_info)) )
             {
-                MEM_LOG("Mfn %lx already pinned", mfn);
+                MEM_LOG("Mfn %lx already pinned", page_to_mfn(page));
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
 
             /* A page is dirtied when its pin status is set. */
-            paging_mark_dirty(pg_owner, mfn);
-           
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             /* We can race domain destruction (domain_relinquish_resources). */
             if ( unlikely(pg_owner != d) )
             {
@@ -3099,35 +3102,29 @@ int do_mmuext_op(
                 spin_unlock(&pg_owner->page_alloc_lock);
                 if ( drop_ref )
                     put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
             }
 
             break;
         }
 
         case MMUEXT_UNPIN_TABLE: {
-            unsigned long mfn;
             struct page_info *page;
 
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            if ( unlikely(!(okay = get_page_from_pagenr(mfn, pg_owner))) )
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
             {
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx bad domain", mfn);
+                MEM_LOG("Mfn %lx bad domain", op.arg1.mfn);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( !test_and_clear_bit(_PGT_pinned, &page->u.inuse.type_info) )
             {
                 okay = 0;
                 put_page(page);
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx not pinned", mfn);
+                MEM_LOG("Mfn %lx not pinned", op.arg1.mfn);
                 break;
             }
 
@@ -3135,40 +3132,43 @@ int do_mmuext_op(
             put_page(page);
 
             /* A page is dirtied when its pin status is cleared. */
-            paging_mark_dirty(pg_owner, mfn);
-
-            put_gfn(pg_owner, op.arg1.mfn);
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             break;
         }
 
         case MMUEXT_NEW_BASEPTR:
-            okay = new_guest_cr3(get_gfn_untyped(d, op.arg1.mfn));
-            put_gfn(d, op.arg1.mfn);
+            okay = (!paging_mode_translate(d)
+                    && new_guest_cr3(op.arg1.mfn));
             break;
+
         
 #ifdef __x86_64__
         case MMUEXT_NEW_USER_BASEPTR: {
-            unsigned long old_mfn, mfn;
-
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            if ( mfn != 0 )
+            unsigned long old_mfn;
+
+            if ( paging_mode_translate(current->domain) )
+            {
+                okay = 0;
+                break;
+            }
+
+            if ( op.arg1.mfn != 0 )
             {
                 if ( paging_mode_refcounts(d) )
-                    okay = get_page_from_pagenr(mfn, d);
+                    okay = get_page_from_pagenr(op.arg1.mfn, d);
                 else
                     okay = !get_page_and_type_from_pagenr(
-                        mfn, PGT_root_page_table, d, 0, 0);
+                        op.arg1.mfn, PGT_root_page_table, d, 0, 0);
                 if ( unlikely(!okay) )
                 {
-                    put_gfn(d, op.arg1.mfn);
-                    MEM_LOG("Error while installing new mfn %lx", mfn);
+                    MEM_LOG("Error while installing new mfn %lx", op.arg1.mfn);
                     break;
                 }
             }
 
             old_mfn = pagetable_get_pfn(curr->arch.guest_table_user);
-            curr->arch.guest_table_user = pagetable_from_pfn(mfn);
-            put_gfn(d, op.arg1.mfn);
+            curr->arch.guest_table_user = pagetable_from_pfn(op.arg1.mfn);
 
             if ( old_mfn != 0 )
             {
@@ -3283,28 +3283,26 @@ int do_mmuext_op(
         }
 
         case MMUEXT_CLEAR_PAGE: {
-            unsigned long mfn;
+            struct page_info *page;
             unsigned char *ptr;
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
+            page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( !page || get_page_type(page, PGT_writable_page) )
             {
-                put_gfn(d, op.arg1.mfn);
-                MEM_LOG("Error while clearing mfn %lx", mfn);
+                if ( page )
+                    put_page(page);
+                MEM_LOG("Error while clearing mfn %lx", op.arg1.mfn);
                 break;
             }
 
             /* A page is dirtied when it's being cleared. */
-            paging_mark_dirty(d, mfn);
-
-            ptr = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(page));
+
+            ptr = fixmap_domain_page(page_to_mfn(page));
             clear_page(ptr);
             fixunmap_domain_page(ptr);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
+            put_page_and_type(page);
             break;
         }
 
@@ -3312,42 +3310,38 @@ int do_mmuext_op(
         {
             const unsigned char *src;
             unsigned char *dst;
-            unsigned long src_mfn, mfn;
-
-            src_mfn = get_gfn_untyped(d, op.arg2.src_mfn);
-            okay = get_page_from_pagenr(src_mfn, d);
+            struct page_info *src_page, *dst_page;
+
+            src_page = get_page_from_gfn(d, op.arg2.src_mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!src_page) )
+            {
+                okay = 0;
+                MEM_LOG("Error while copying from mfn %lx", op.arg2.src_mfn);
+                break;
+            }
+
+            dst_page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            okay = (dst_page && get_page_type(dst_page, PGT_writable_page));
             if ( unlikely(!okay) )
             {
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying from mfn %lx", src_mfn);
+                put_page(src_page);
+                if ( dst_page )
+                    put_page(dst_page);
+                MEM_LOG("Error while copying to mfn %lx", op.arg1.mfn);
                 break;
             }
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
-            {
-                put_gfn(d, op.arg1.mfn);
-                put_page(mfn_to_page(src_mfn));
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying to mfn %lx", mfn);
-                break;
-            }
-
             /* A page is dirtied when it's being copied to. */
-            paging_mark_dirty(d, mfn);
-
-            src = map_domain_page(src_mfn);
-            dst = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(dst_page));
+
+            src = __map_domain_page(src_page);
+            dst = fixmap_domain_page(page_to_mfn(dst_page));
             copy_page(dst, src);
             fixunmap_domain_page(dst);
             unmap_domain_page(src);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
-            put_page(mfn_to_page(src_mfn));
-            put_gfn(d, op.arg2.src_mfn);
+            put_page_and_type(dst_page);
+            put_page(src_page);
             break;
         }
 
@@ -3538,29 +3532,26 @@ int do_mmu_update(
 
             req.ptr -= cmd;
             gmfn = req.ptr >> PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(pt_owner, gmfn, &p2mt));
-            if ( !p2m_is_valid(p2mt) )
-                mfn = INVALID_MFN;
+            page = get_page_from_gfn(pt_owner, gmfn, &p2mt, P2M_ALLOC);
 
             if ( p2m_is_paged(p2mt) )
             {
-                put_gfn(pt_owner, gmfn);
+                ASSERT(!page);
                 p2m_mem_paging_populate(pg_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
 
-            if ( unlikely(!get_page_from_pagenr(mfn, pt_owner)) )
+            if ( unlikely(!page) )
             {
                 MEM_LOG("Could not get page for normal update");
-                put_gfn(pt_owner, gmfn);
                 break;
             }
 
+            mfn = page_to_mfn(page);
             va = map_domain_page_with_cache(mfn, &mapcache);
             va = (void *)((unsigned long)va +
                           (unsigned long)(req.ptr & ~PAGE_MASK));
-            page = mfn_to_page(mfn);
 
             if ( page_lock(page) )
             {
@@ -3569,22 +3560,23 @@ int do_mmu_update(
                 case PGT_l1_page_table:
                 {
                     l1_pgentry_t l1e = l1e_from_intpte(req.val);
-                    p2m_type_t l1e_p2mt;
-                    unsigned long l1egfn = l1e_get_pfn(l1e), l1emfn;
-    
-                    l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
+                    p2m_type_t l1e_p2mt = p2m_ram_rw;
+                    struct page_info *target = NULL;
+
+                    if ( paging_mode_translate(pg_owner) )
+                        target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
+                                                   &l1e_p2mt, P2M_ALLOC);
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
-                        put_gfn(pg_owner, l1egfn);
+                        if ( target )
+                            put_page(target);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in == l1e_p2mt && 
-                                !mfn_valid(l1emfn) )
+                    else if ( p2m_ram_paging_in == l1e_p2mt && !target )
                     {
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3601,7 +3593,8 @@ int do_mmu_update(
                             rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
                             if ( rc )
                             {
-                                put_gfn(pg_owner, l1egfn);
+                                if ( target )
+                                    put_page(target);
                                 /* Notify helper, don't care about errors, will not
                                  * sleep on wq, since we're a foreign domain. */
                                 (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
@@ -3614,112 +3607,22 @@ int do_mmu_update(
                     rc = mod_l1_entry(va, l1e, mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
                                       pg_owner);
-                    put_gfn(pg_owner, l1egfn);
+                    if ( target )
+                        put_page(target);
                 }
                 break;
                 case PGT_l2_page_table:
-                {
-                    l2_pgentry_t l2e = l2e_from_intpte(req.val);
-                    p2m_type_t l2e_p2mt;
-                    unsigned long l2egfn = l2e_get_pfn(l2e), l2emfn;
-
-                    l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
-
-                    if ( p2m_is_paged(l2e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l2e_p2mt && 
-                                !mfn_valid(l2emfn) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l2e_p2mt )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-
-                    rc = mod_l2_entry(va, l2e, mfn,
+                    rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
-                    put_gfn(pg_owner, l2egfn);
-                }
-                break;
+                    break;
                 case PGT_l3_page_table:
-                {
-                    l3_pgentry_t l3e = l3e_from_intpte(req.val);
-                    p2m_type_t l3e_p2mt;
-                    unsigned long l3egfn = l3e_get_pfn(l3e), l3emfn;
-
-                    l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
-
-                    if ( p2m_is_paged(l3e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l3e_p2mt && 
-                                !mfn_valid(l3emfn) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l3e_p2mt )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l3_entry(va, l3e, mfn,
+                    rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l3egfn);
-                }
-                break;
+                    break;
 #if CONFIG_PAGING_LEVELS >= 4
                 case PGT_l4_page_table:
-                {
-                    l4_pgentry_t l4e = l4e_from_intpte(req.val);
-                    p2m_type_t l4e_p2mt;
-                    unsigned long l4egfn = l4e_get_pfn(l4e), l4emfn;
-
-                    l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
-
-                    if ( p2m_is_paged(l4e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l4e_p2mt && 
-                                !mfn_valid(l4emfn) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l4e_p2mt )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l4_entry(va, l4e, mfn,
+                    rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l4egfn);
-                }
                 break;
 #endif
                 case PGT_writable_page:
@@ -3742,7 +3645,6 @@ int do_mmu_update(
 
             unmap_domain_page_with_cache(va, &mapcache);
             put_page(page);
-            put_gfn(pt_owner, gmfn);
         }
         break;
 
diff -r 107285938c50 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/guest_walk.c	Thu Apr 26 22:00:25 2012 +0100
@@ -94,39 +94,37 @@ static inline void *map_domain_gfn(struc
                                    p2m_type_t *p2mt,
                                    uint32_t *rc) 
 {
-    p2m_access_t p2ma;
+    struct page_info *page;
     void *map;
 
     /* Translate the gfn, unsharing if shared */
-    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, 
-                               P2M_ALLOC | P2M_UNSHARE, NULL);
+    page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), p2mt, NULL,
+                                  P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
     if ( p2m_is_shared(*p2mt) )
     {
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         *rc = _PAGE_SHARED;
         return NULL;
     }
-    if ( !p2m_is_ram(*p2mt) ) 
+    if ( !page )
     {
-        __put_gfn(p2m, gfn_x(gfn));
         *rc |= _PAGE_PRESENT;
         return NULL;
     }
+    *mfn = _mfn(page_to_mfn(page));
     ASSERT(mfn_valid(mfn_x(*mfn)));
-    
-    /* Get an extra ref to the page to ensure liveness of the map.
-     * Then we can safely put gfn */
-    page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn)));
+
     map = map_domain_page(mfn_x(*mfn));
-    __put_gfn(p2m, gfn_x(gfn));
     return map;
 }
 
diff -r 107285938c50 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/hap/guest_walk.c	Thu Apr 26 22:00:25 2012 +0100
@@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     mfn_t top_mfn;
     void *top_map;
     p2m_type_t p2mt;
-    p2m_access_t p2ma;
     walk_t gw;
     unsigned long top_gfn;
+    struct page_info *top_page;
 
     /* Get the top-level table's MFN */
     top_gfn = cr3 >> PAGE_SHIFT;
-    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, 
-                                  P2M_ALLOC | P2M_UNSHARE, NULL);
+    top_page = get_page_from_gfn_p2m(p2m->domain, p2m, top_gfn,
+                                     &p2mt, NULL, P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         pfec[0] = PFEC_page_paged;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
     {
         pfec[0] = PFEC_page_shared;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         return INVALID_GFN;
     }
-    if ( !p2m_is_ram(p2mt) )
+    if ( !top_page )
     {
         pfec[0] &= ~PFEC_page_present;
-        __put_gfn(p2m, top_gfn);
+        put_page(top_page);
         return INVALID_GFN;
     }
+    top_mfn = _mfn(page_to_mfn(top_page));
 
     /* Map the top-level table and call the tree-walker */
     ASSERT(mfn_valid(mfn_x(top_mfn)));
@@ -91,31 +94,30 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 #endif
     missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map);
     unmap_domain_page(top_map);
-    __put_gfn(p2m, top_gfn);
+    put_page(top_page);
 
     /* Interpret the answer */
     if ( missing == 0 )
     {
         gfn_t gfn = guest_l1e_get_gfn(gw.l1e);
-        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
-                                  P2M_ALLOC | P2M_UNSHARE, NULL); 
+        struct page_info *page;
+        page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), &p2mt,
+                                     NULL, P2M_ALLOC | P2M_UNSHARE);
+        if ( page )
+            put_page(page);
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
             pfec[0] = PFEC_page_paged;
-            __put_gfn(p2m, gfn_x(gfn));
             p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
         {
             pfec[0] = PFEC_page_shared;
-            __put_gfn(p2m, gfn_x(gfn));
             return INVALID_GFN;
         }
 
-        __put_gfn(p2m, gfn_x(gfn));
-
         if ( page_order )
             *page_order = guest_walk_to_page_order(&gw);
 
diff -r 107285938c50 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Thu Apr 26 22:00:25 2012 +0100
@@ -166,13 +166,39 @@ declare_mm_lock(nestedp2m)
  * and later mutate it.
  */
 
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
+/* P2M lock is become an rwlock, purely so we can implement
+ * get_page_from_gfn.  The mess below is a ghastly hack to make a
+ * recursive rwlock.  If it works I'll come back and fix up the
+ * order-contraints magic. */
+
+static inline void p2m_lock(struct p2m_domain *p)
+{
+    if ( p->wcpu != current->processor )
+    {
+        write_lock(&p->lock);
+        p->wcpu = current->processor;
+        ASSERT(p->wcount == 0);
+    }
+    p->wcount++;
+}
+
+static inline void p2m_unlock(struct p2m_domain *p)
+{
+    ASSERT(p->wcpu == current->processor);
+    if (--(p->wcount) == 0)
+    {
+        p->wcpu = -1;
+        write_unlock(&p->lock);
+    }
+}
+
+#define gfn_lock(p,g,o)       p2m_lock(p)
+#define gfn_unlock(p,g,o)     p2m_unlock(p)
+#define p2m_read_lock(p)      read_lock(&(p)->lock)
+#define p2m_read_unlock(p)    read_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   ((p)->wcpu == current->processor)
+#define gfn_locked_by_me(p,g) p2m_locked_by_me(p)
+
 
 /* Sharing per page lock
  *
@@ -203,8 +229,8 @@ declare_mm_order_constraint(per_page_sha
  * counts, page lists, sweep parameters. */
 
 declare_mm_lock(pod)
-#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
-#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_lock(p) do { p2m_lock(p); mm_lock(pod, &(p)->pod.lock); } while (0)
+#define pod_unlock(p) do { mm_unlock(&(p)->pod.lock); p2m_unlock(p);} while (0)
 #define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
 
 /* Page alloc lock (per-domain)
diff -r 107285938c50 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 26 22:00:25 2012 +0100
@@ -71,7 +71,9 @@ boolean_param("hap_2mb", opt_hap_2mb);
 /* Init the datastructures for later use by the p2m code */
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
-    mm_lock_init(&p2m->lock);
+    rwlock_init(&p2m->lock);
+    p2m->wcount = 0;
+    p2m->wcpu = -1;
     mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
@@ -207,6 +209,61 @@ void __put_gfn(struct p2m_domain *p2m, u
     gfn_unlock(p2m, gfn, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page. */
+struct page_info *get_page_from_gfn_p2m(
+    struct domain *d, struct p2m_domain *p2m, unsigned long gfn,
+    p2m_type_t *t, p2m_access_t *a, p2m_query_t q)
+{
+    struct page_info *page = NULL;
+    p2m_access_t _a;
+    p2m_type_t _t;
+    mfn_t mfn;
+
+    /* Allow t or a to be NULL */
+    t = t ?: &_t;
+    a = a ?: &_a;
+
+    if ( likely(!p2m_locked_by_me(p2m)) )
+    {
+        /* Fast path: look up and get out */
+        p2m_read_lock(p2m);
+        mfn = __get_gfn_type_access(p2m, gfn, t, a, 0, NULL, 0);
+        if ( (p2m_is_ram(*t) || p2m_is_grant(*t))
+             && mfn_valid(mfn)
+             && !((q & P2M_UNSHARE) && p2m_is_shared(*t)) )
+        {
+            page = mfn_to_page(mfn);
+            if ( !get_page(page, d)
+                 /* Page could be shared */
+                 && !get_page(page, dom_cow) )
+                page = NULL;
+        }
+        p2m_read_unlock(p2m);
+
+        if ( page )
+            return page;
+
+        /* Error path: not a suitable GFN at all */
+        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) )
+            return NULL;
+    }
+
+    /* Slow path: take the write lock and do fixups */
+    p2m_lock(p2m);
+    mfn = get_gfn_type_access(p2m, gfn, t, a, q, NULL);
+    if ( p2m_is_ram(*t) && mfn_valid(mfn) )
+    {
+        page = mfn_to_page(mfn);
+        if ( !get_page(page, d) )
+            page = NULL;
+    }
+    put_gfn(d, gfn);
+    p2m_unlock(p2m);
+
+    return page;
+}
+
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 107285938c50 xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/physdev.c	Thu Apr 26 22:00:25 2012 +0100
@@ -306,26 +306,27 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
     case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
+        struct page_info *page;
 
         ret = -EFAULT;
         if ( copy_from_guest(&info, arg, 1) != 0 )
             break;
 
         ret = -EINVAL;
-        mfn = get_gfn_untyped(current->domain, info.gmfn);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), v->domain,
-                                PGT_writable_page) )
+        page = get_page_from_gfn(current->domain, info.gmfn, NULL, P2M_ALLOC);
+        if ( !page )
+            break;
+        if ( !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(current->domain, info.gmfn);
+            put_page(page);
             break;
         }
+        mfn = page_to_mfn(page);
 
         if ( cmpxchg(&v->domain->arch.pv_domain.pirq_eoi_map_mfn,
                      0, mfn) != 0 )
         {
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -EBUSY;
             break;
         }
@@ -335,14 +336,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         {
             v->domain->arch.pv_domain.pirq_eoi_map_mfn = 0;
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -ENOSPC;
             break;
         }
         if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
             v->domain->arch.pv_domain.auto_unmask = 1;
 
-        put_gfn(current->domain, info.gmfn);
         ret = 0;
         break;
     }
diff -r 107285938c50 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/traps.c	Thu Apr 26 22:00:25 2012 +0100
@@ -662,9 +662,9 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
     case 0:
     {
         void *hypercall_page;
-        unsigned long mfn;
         unsigned long gmfn = val >> 12;
         unsigned int idx  = val & 0xfff;
+        struct page_info *page;
 
         if ( idx > 0 )
         {
@@ -674,24 +674,23 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
             return 0;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
-
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn);
+            if ( page )
+                put_page(page);
             gdprintk(XENLOG_WARNING,
                      "Bad GMFN %lx (MFN %lx) to MSR %08x\n",
-                     gmfn, mfn, base + idx);
+                     gmfn, page_to_mfn(page), base + idx);
             return 0;
         }
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gmfn);
+        put_page_and_type(page);
         break;
     }
 
@@ -2374,7 +2373,8 @@ static int emulate_privileged_op(struct 
             break;
 
         case 3: {/* Write CR3 */
-            unsigned long mfn, gfn;
+            unsigned long gfn;
+            struct page_info *page;
             domain_lock(v->domain);
             if ( !is_pv_32on64_vcpu(v) )
             {
@@ -2384,9 +2384,10 @@ static int emulate_privileged_op(struct 
                 gfn = compat_cr3_to_pfn(*reg);
 #endif
             }
-            mfn = get_gfn_untyped(v->domain, gfn);
-            rc = new_guest_cr3(mfn);
-            put_gfn(v->domain, gfn);
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            rc = page ? new_guest_cr3(page_to_mfn(page)) : 0;
+            if ( page )
+                put_page(page);
             domain_unlock(v->domain);
             if ( rc == 0 ) /* not okay */
                 goto fail;
diff -r 107285938c50 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 26 22:00:25 2012 +0100
@@ -192,7 +192,10 @@ typedef unsigned int p2m_query_t;
 /* Per-p2m-table state */
 struct p2m_domain {
     /* Lock that protects updates to the p2m */
-    mm_lock_t          lock;
+    rwlock_t           lock;
+    int                wcpu;
+    int                wcount;
+    const char        *wfunc;
 
     /* Shadow translated domain: p2m mapping */
     pagetable_t        phys_table;
@@ -377,6 +380,33 @@ static inline mfn_t get_gfn_query_unlock
     return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page.
+ * This makes sure the page doesn't get freed (or shared) underfoot,
+ * and should be used by any path that intends to write to the backing page.
+ * Returns NULL if the page is not backed by RAM.
+ * The caller is responsible for calling put_page() afterwards. */
+struct page_info *get_page_from_gfn_p2m(struct domain *d,
+                                        struct p2m_domain *p2m,
+                                        unsigned long gfn,
+                                        p2m_type_t *t, p2m_access_t *a,
+                                        p2m_query_t q);
+
+static inline struct page_info *get_page_from_gfn(
+    struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
+{
+    struct page_info *page;
+
+    if ( paging_mode_translate(d) )
+        return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q);
+
+    /* Non-translated guests see 1-1 RAM mappings everywhere */
+    if (t)
+        *t = p2m_ram_rw;
+    page = __mfn_to_page(gfn);
+    return get_page(page, d) ? page : NULL;
+}
+
+
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)
 {
diff -r 107285938c50 xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/xsm/flask/hooks.c	Thu Apr 26 22:00:25 2012 +0100
@@ -1318,6 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
+    struct page_info *page;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1333,7 +1334,8 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+    mfn = page ? page_to_mfn(page) : INVALID_MFN;
 
     ad.sdom = d;
     ad.tdom = f;
@@ -1342,7 +1344,8 @@ static int flask_mmu_normal_update(struc
 
     rc = get_mfn_sid(fmfn, &fsid);
 
-    put_gfn(f, fmfn);
+    if ( page )
+        put_page(page);
 
     if ( rc )
         return rc;

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--qDbXVdCdHGoSgWSk--


From xen-devel-bounces@lists.xen.org Thu Apr 26 21:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 21:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNWY5-0001aq-RN; Thu, 26 Apr 2012 21:48:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNWY4-0001al-Hq
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 21:48:24 +0000
Received: from [85.158.143.35:32304] by server-1.bemta-4.messagelabs.com id
	CD/36-20925-7A2C99F4; Thu, 26 Apr 2012 21:48:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335476901!13807369!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODA3NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22729 invoked from network); 26 Apr 2012 21:48:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 21:48:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QLm2vd019932
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 21:48:03 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QLlwOE026250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 21:47:59 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QLluDI000990; Thu, 26 Apr 2012 16:47:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 14:47:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BF6AA402FB; Thu, 26 Apr 2012 17:42:22 -0400 (EDT)
Date: Thu, 26 Apr 2012 17:42:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julia Lawall <Julia.Lawall@lip6.fr>, FlorianSchandinat@gmx.de
Message-ID: <20120426214222.GA11289@phenom.dumpdata.com>
References: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, linux-fbdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] drivers/video/xen-fbfront.c: add missing
 cleanup code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 11:57:40AM +0200, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
> 
> The operations in the subsequent error-handling code appear to be also
> useful here.

How about doing it this way?
Florian, are you OK me carrying this patch in my tree for Linus or would
you prefer to do it?

commit a833fb9973b47cb30d1086e73f20b62a425bcd85
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Apr 22 11:57:40 2012 +0200

    drivers/video/xen-fbfront.c: add missing cleanup code
    
    The operations in the subsequent error-handling code appear to be also
    useful here.
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    [v1: Collapse some of the error handling functions]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cb4529c..aa42160 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -458,26 +458,31 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 	xenfb_init_shared_page(info, fb_info);
 
 	ret = xenfb_connect_backend(dev, info);
-	if (ret < 0)
-		goto error;
+	if (ret < 0) {
+		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
+		goto error_fb;
+	}
 
 	ret = register_framebuffer(fb_info);
 	if (ret) {
-		fb_deferred_io_cleanup(fb_info);
-		fb_dealloc_cmap(&fb_info->cmap);
-		framebuffer_release(fb_info);
 		xenbus_dev_fatal(dev, ret, "register_framebuffer");
-		goto error;
+		goto error_fb;
 	}
 	info->fb_info = fb_info;
 
 	xenfb_make_preferred_console();
 	return 0;
 
- error_nomem:
-	ret = -ENOMEM;
-	xenbus_dev_fatal(dev, ret, "allocating device memory");
- error:
+error_fb:
+	fb_deferred_io_cleanup(fb_info);
+	fb_dealloc_cmap(&fb_info->cmap);
+	framebuffer_release(fb_info);
+error_nomem:
+	if (!ret) {
+		ret = -ENOMEM;
+		xenbus_dev_fatal(dev, ret, "allocating device memory");
+	}
+error:
 	xenfb_remove(dev);
 	return ret;
 }



> 
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
> 
> ---
> Not tested.
> 
>  drivers/video/xen-fbfront.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index cb4529c..b0bd59c 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -458,8 +458,13 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
>  	xenfb_init_shared_page(info, fb_info);
>  
>  	ret = xenfb_connect_backend(dev, info);
> -	if (ret < 0)
> +	if (ret < 0) {
> +		fb_deferred_io_cleanup(fb_info);
> +		fb_dealloc_cmap(&fb_info->cmap);
> +		framebuffer_release(fb_info);
> +		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
>  		goto error;
> +	}
>  
>  	ret = register_framebuffer(fb_info);
>  	if (ret) {
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 21:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 21:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNWY5-0001aq-RN; Thu, 26 Apr 2012 21:48:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNWY4-0001al-Hq
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 21:48:24 +0000
Received: from [85.158.143.35:32304] by server-1.bemta-4.messagelabs.com id
	CD/36-20925-7A2C99F4; Thu, 26 Apr 2012 21:48:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335476901!13807369!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODA3NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22729 invoked from network); 26 Apr 2012 21:48:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Apr 2012 21:48:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3QLm2vd019932
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Apr 2012 21:48:03 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3QLlwOE026250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Apr 2012 21:47:59 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3QLluDI000990; Thu, 26 Apr 2012 16:47:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 14:47:56 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BF6AA402FB; Thu, 26 Apr 2012 17:42:22 -0400 (EDT)
Date: Thu, 26 Apr 2012 17:42:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julia Lawall <Julia.Lawall@lip6.fr>, FlorianSchandinat@gmx.de
Message-ID: <20120426214222.GA11289@phenom.dumpdata.com>
References: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, linux-fbdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] drivers/video/xen-fbfront.c: add missing
 cleanup code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 22, 2012 at 11:57:40AM +0200, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
> 
> The operations in the subsequent error-handling code appear to be also
> useful here.

How about doing it this way?
Florian, are you OK me carrying this patch in my tree for Linus or would
you prefer to do it?

commit a833fb9973b47cb30d1086e73f20b62a425bcd85
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Apr 22 11:57:40 2012 +0200

    drivers/video/xen-fbfront.c: add missing cleanup code
    
    The operations in the subsequent error-handling code appear to be also
    useful here.
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    [v1: Collapse some of the error handling functions]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cb4529c..aa42160 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -458,26 +458,31 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 	xenfb_init_shared_page(info, fb_info);
 
 	ret = xenfb_connect_backend(dev, info);
-	if (ret < 0)
-		goto error;
+	if (ret < 0) {
+		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
+		goto error_fb;
+	}
 
 	ret = register_framebuffer(fb_info);
 	if (ret) {
-		fb_deferred_io_cleanup(fb_info);
-		fb_dealloc_cmap(&fb_info->cmap);
-		framebuffer_release(fb_info);
 		xenbus_dev_fatal(dev, ret, "register_framebuffer");
-		goto error;
+		goto error_fb;
 	}
 	info->fb_info = fb_info;
 
 	xenfb_make_preferred_console();
 	return 0;
 
- error_nomem:
-	ret = -ENOMEM;
-	xenbus_dev_fatal(dev, ret, "allocating device memory");
- error:
+error_fb:
+	fb_deferred_io_cleanup(fb_info);
+	fb_dealloc_cmap(&fb_info->cmap);
+	framebuffer_release(fb_info);
+error_nomem:
+	if (!ret) {
+		ret = -ENOMEM;
+		xenbus_dev_fatal(dev, ret, "allocating device memory");
+	}
+error:
 	xenfb_remove(dev);
 	return ret;
 }



> 
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
> 
> ---
> Not tested.
> 
>  drivers/video/xen-fbfront.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index cb4529c..b0bd59c 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -458,8 +458,13 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
>  	xenfb_init_shared_page(info, fb_info);
>  
>  	ret = xenfb_connect_backend(dev, info);
> -	if (ret < 0)
> +	if (ret < 0) {
> +		fb_deferred_io_cleanup(fb_info);
> +		fb_dealloc_cmap(&fb_info->cmap);
> +		framebuffer_release(fb_info);
> +		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
>  		goto error;
> +	}
>  
>  	ret = register_framebuffer(fb_info);
>  	if (ret) {
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 22:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 22:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNXND-0001tl-4X; Thu, 26 Apr 2012 22:41:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNXNC-0001tg-8f
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 22:41:14 +0000
Received: from [85.158.143.99:60480] by server-3.bemta-4.messagelabs.com id
	BC/10-05853-90FC99F4; Thu, 26 Apr 2012 22:41:13 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335480070!17933273!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31840 invoked from network); 26 Apr 2012 22:41:11 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 22:41:11 -0000
Received: by lboi15 with SMTP id i15so102176lbo.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 15:41:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=8wVlU8qqb19CqYGAJdXJt309Ib9I+0630mCF+5bb9qw=;
	b=1BrryEtM56/Rhr13AYcllU0NaevxGMivQgjkBtOC5CJjXWGMO64jLe0U1xTCZaw7/L
	uE8jtkdvzwpEZSmNaqXjSVjbR6c3YQVtynYiT9ymYT/cOur1aRQv+PeS0BasgsgIbpFH
	z7A+oQDk3+35XTIMpZ5E9LWw90aG2KOHc3C5M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=8wVlU8qqb19CqYGAJdXJt309Ib9I+0630mCF+5bb9qw=;
	b=TOxs3AwiDg5VGCBsYXuM7AIG7R0cDJuCjDImLnGdsCB5toqgxGBdlJcMk0B0t7rdP7
	kd/6a5UUuXRsfMoflY9Yo0hoJ4962VeuckjxCJXEKlkZy/4/Rzhe0Xp8Yt1HABI3aS3h
	RvNjV+0m94RBljuqkG7R86TNNTKIEHFIXR/3O5twE1OD9axSR4cHVQfmWEJysJXFQi00
	kCOOGAVKlyd2CI6HIvdAvRHuVVt7u9uhTw7VSj7Qtpus2Aq6f8lrLowKOiIKkZcchqTM
	/iOVey7FjTRJBLa49HvtQ+X68YXnwABU7eMRV/CCT3yozgDcgnf+RRm1BFyP5nWfJLoq
	vIDg==
MIME-Version: 1.0
Received: by 10.112.30.1 with SMTP id o1mr4272485lbh.3.1335480070039; Thu, 26
	Apr 2012 15:41:10 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 15:41:10 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
Date: Thu, 26 Apr 2012 15:41:10 -0700
Message-ID: <CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQkuLEshhefMzHsa4v9zDPCYNnMWmp6YF/dMVzhIMpOg3G7wV4FbAZfngNEqUgW28PCIVyHZ
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 1:20 PM, Christian Limpach
<christian.limpach@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 11:33 AM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
>> When the mem_access type needs to be changed for multiple discontiguous =
gfns, calling xc_hvm_set_mem_access() multiple times does not perform very =
well. The main pain points are the multiple libxc calls themselves plus the=
 multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() cal=
ls for each ept_set_entry(gfn). The following patches adds a new mem_access=
 API that sets the mem_access type for an array of guest physical addresses=
 in one libxc call with minimal map_domain_page() / unmap_domain_page() and=
 ept_sync_domain() calls.
>
>
> Are you sure that your bulk code actually works? =A0It seems to me that
> your __ept_set_entry function assumes that table still points to the
> top of the p2m. =A0The "for ( i =3D ept_get_wl(d); i > target; i-- )" loop
> will walk the table, and so in the subsequent calls from your bulk
> loop, this won't work?
>
> I think you need something like an iterator, the context of which can
> be passed around...

Duh! You are right. My test code has been giving me a false positive.
I completely misread how ept_next_level() works.

> Also, the call to ept_get_entry in your bulk loop will do a walk in
> every iteration, it seems a bit arbitrary to only (try to) avoid one
> and not the other. =A0But I guess the "win" is from reducing the number
> of ept_sync_domain calls.

You are right. I was mainly focusing on removing the multiple libxc
calls and reducing the ept_sync_domain calls. I thought removing the
map and unmap of the p2m top page was an extra optimization which I
obviously messed up. I will rework the patch to only stick with the
original optimization I had in mind.

Thanks,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Apr 26 22:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Apr 2012 22:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNXND-0001tl-4X; Thu, 26 Apr 2012 22:41:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNXNC-0001tg-8f
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 22:41:14 +0000
Received: from [85.158.143.99:60480] by server-3.bemta-4.messagelabs.com id
	BC/10-05853-90FC99F4; Thu, 26 Apr 2012 22:41:13 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335480070!17933273!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31840 invoked from network); 26 Apr 2012 22:41:11 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 22:41:11 -0000
Received: by lboi15 with SMTP id i15so102176lbo.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 15:41:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=8wVlU8qqb19CqYGAJdXJt309Ib9I+0630mCF+5bb9qw=;
	b=1BrryEtM56/Rhr13AYcllU0NaevxGMivQgjkBtOC5CJjXWGMO64jLe0U1xTCZaw7/L
	uE8jtkdvzwpEZSmNaqXjSVjbR6c3YQVtynYiT9ymYT/cOur1aRQv+PeS0BasgsgIbpFH
	z7A+oQDk3+35XTIMpZ5E9LWw90aG2KOHc3C5M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=8wVlU8qqb19CqYGAJdXJt309Ib9I+0630mCF+5bb9qw=;
	b=TOxs3AwiDg5VGCBsYXuM7AIG7R0cDJuCjDImLnGdsCB5toqgxGBdlJcMk0B0t7rdP7
	kd/6a5UUuXRsfMoflY9Yo0hoJ4962VeuckjxCJXEKlkZy/4/Rzhe0Xp8Yt1HABI3aS3h
	RvNjV+0m94RBljuqkG7R86TNNTKIEHFIXR/3O5twE1OD9axSR4cHVQfmWEJysJXFQi00
	kCOOGAVKlyd2CI6HIvdAvRHuVVt7u9uhTw7VSj7Qtpus2Aq6f8lrLowKOiIKkZcchqTM
	/iOVey7FjTRJBLa49HvtQ+X68YXnwABU7eMRV/CCT3yozgDcgnf+RRm1BFyP5nWfJLoq
	vIDg==
MIME-Version: 1.0
Received: by 10.112.30.1 with SMTP id o1mr4272485lbh.3.1335480070039; Thu, 26
	Apr 2012 15:41:10 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 15:41:10 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
Date: Thu, 26 Apr 2012 15:41:10 -0700
Message-ID: <CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQkuLEshhefMzHsa4v9zDPCYNnMWmp6YF/dMVzhIMpOg3G7wV4FbAZfngNEqUgW28PCIVyHZ
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 1:20 PM, Christian Limpach
<christian.limpach@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 11:33 AM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
>> When the mem_access type needs to be changed for multiple discontiguous =
gfns, calling xc_hvm_set_mem_access() multiple times does not perform very =
well. The main pain points are the multiple libxc calls themselves plus the=
 multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() cal=
ls for each ept_set_entry(gfn). The following patches adds a new mem_access=
 API that sets the mem_access type for an array of guest physical addresses=
 in one libxc call with minimal map_domain_page() / unmap_domain_page() and=
 ept_sync_domain() calls.
>
>
> Are you sure that your bulk code actually works? =A0It seems to me that
> your __ept_set_entry function assumes that table still points to the
> top of the p2m. =A0The "for ( i =3D ept_get_wl(d); i > target; i-- )" loop
> will walk the table, and so in the subsequent calls from your bulk
> loop, this won't work?
>
> I think you need something like an iterator, the context of which can
> be passed around...

Duh! You are right. My test code has been giving me a false positive.
I completely misread how ept_next_level() works.

> Also, the call to ept_get_entry in your bulk loop will do a walk in
> every iteration, it seems a bit arbitrary to only (try to) avoid one
> and not the other. =A0But I guess the "win" is from reducing the number
> of ept_sync_domain calls.

You are right. I was mainly focusing on removing the multiple libxc
calls and reducing the ept_sync_domain calls. I thought removing the
map and unmap of the p2m top page was an extra optimization which I
obviously messed up. I will rework the patch to only stick with the
original optimization I had in mind.

Thanks,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:16:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNYqs-0002iy-At; Fri, 27 Apr 2012 00:15:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNYqq-0002it-WE
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 00:15:57 +0000
Received: from [193.109.254.147:62987] by server-2.bemta-14.messagelabs.com id
	90/05-19409-C35E99F4; Fri, 27 Apr 2012 00:15:56 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335485753!6553564!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20760 invoked from network); 27 Apr 2012 00:15:54 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 00:15:54 -0000
Received: by lboi15 with SMTP id i15so146063lbo.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 17:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=rchMN0MWwR0QUtisWjf79oLDBZRG0y3NJ6vjdIslO6o=;
	b=ThMjzeYNhFI3E6U+0tlG7b3f5pFsJzYJNl28PXOien9wWJxJmDw5LE3w5Gleh9PeSL
	lNRsob92ugJAvAhyMRXBYSQkA77n+UZy1+wvRoeBgFj7IEO/+QNZdDq35qieZsBCu3Uq
	IhttAwsHbVAU75x4fyAVeg/ndIWLGAU5uXIcs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=rchMN0MWwR0QUtisWjf79oLDBZRG0y3NJ6vjdIslO6o=;
	b=Olg9VxxbFptQJIQQ+nB4dnUydShyWL0upRwg/blPT1lSztZQwNyM1mCqNg2fpBoDQh
	D047db15gc5MLCmhQKpC4h0gKe+6OdYMzILhz+PN9zTsR5Ii8l7Dn1E5qU6drk4THM/z
	LApbsyMM8kYA5ibAvmYwsP4RWR2HR+fxh9z0sX145Qot8yAx/VjWFYXfrfWOp/NmJ0Ia
	abUKqS9/nphDtg7X8gNuMo3rjfVA52GF44LK7YrqFDbYyCo2/Jllpvt3TJkIBnTEO1xI
	rxIQcvdu3jzpV1S2eHiNjdanbP/8mzed+K7toHUX6E9E9iUZzYECgHHL+3LFg0S/JBdc
	kGdw==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr4398282lbm.31.1335485753518; Thu,
	26 Apr 2012 17:15:53 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 17:15:53 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
Date: Thu, 26 Apr 2012 17:15:53 -0700
Message-ID: <CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQnznG47w2nHwkxFm4ePkNaGMJkXvrBAnOTZKQv7tuzd9nfkxjxSY/wlIUinbaJDyKA6kZgp
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 3:41 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Thu, Apr 26, 2012 at 1:20 PM, Christian Limpach
> <christian.limpach@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 11:33 AM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>> When the mem_access type needs to be changed for multiple discontiguous=
 gfns, calling xc_hvm_set_mem_access() multiple times does not perform very=
 well. The main pain points are the multiple libxc calls themselves plus th=
e multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() ca=
lls for each ept_set_entry(gfn). The following patches adds a new mem_acces=
s API that sets the mem_access type for an array of guest physical addresse=
s in one libxc call with minimal map_domain_page() / unmap_domain_page() an=
d ept_sync_domain() calls.
>>
>>
>> Are you sure that your bulk code actually works? =A0It seems to me that
>> your __ept_set_entry function assumes that table still points to the
>> top of the p2m. =A0The "for ( i =3D ept_get_wl(d); i > target; i-- )" lo=
op
>> will walk the table, and so in the subsequent calls from your bulk
>> loop, this won't work?
>>
>> I think you need something like an iterator, the context of which can
>> be passed around...
>
> Duh! You are right. My test code has been giving me a false positive.
> I completely misread how ept_next_level() works.
>
>> Also, the call to ept_get_entry in your bulk loop will do a walk in
>> every iteration, it seems a bit arbitrary to only (try to) avoid one
>> and not the other. =A0But I guess the "win" is from reducing the number
>> of ept_sync_domain calls.
>
> You are right. I was mainly focusing on removing the multiple libxc
> calls and reducing the ept_sync_domain calls. I thought removing the
> map and unmap of the p2m top page was an extra optimization which I
> obviously messed up. I will rework the patch to only stick with the
> original optimization I had in mind.

Does this look correct now?

Thanks,
Aravindh

changeset:   25252:b1bde8691257
summary:     x86/mm: Split ept_set_entry()

diff -r 63eb1343cbdb -r b1bde8691257 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:53 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 17:10:29 2012 -0700
@@ -272,12 +272,13 @@ static int ept_next_level(struct p2m_dom
 }

 /*
- * ept_set_entry() computes 'need_modify_vtd_table' for itself,
+ * __ept_set_entry() computes 'need_modify_vtd_table' for itself,
  * by observing whether any gfn->mfn translations are modified.
  */
 static int
-ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
-              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+__ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+                unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
+                ept_entry_t *old_entry, bool_t *needs_sync)
 {
     ept_entry_t *table, *ept_entry =3D NULL;
     unsigned long gfn_remainder =3D gfn;
@@ -288,11 +289,9 @@ ept_set_entry(struct p2m_domain *p2m, un
     int ret =3D 0;
     bool_t direct_mmio =3D (p2mt =3D=3D p2m_mmio_direct);
     uint8_t ipat =3D 0;
-    int need_modify_vtd_table =3D 1;
-    int vtd_pte_present =3D 0;
-    int needs_sync =3D 1;
+    bool_t need_modify_vtd_table =3D 1;
+    bool_t vtd_pte_present =3D 0;
     struct domain *d =3D p2m->domain;
-    ept_entry_t old_entry =3D { .epte =3D 0 };

     /*
      * the caller must make sure:
@@ -305,10 +304,6 @@ ept_set_entry(struct p2m_domain *p2m, un
          (order % EPT_TABLE_ORDER) )
         return 0;

-    ASSERT((target =3D=3D 2 && hvm_hap_has_1gb(d)) ||
-           (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
-           (target =3D=3D 0));
-
     table =3D map_domain_page(ept_get_asr(d));

     for ( i =3D ept_get_wl(d); i > target; i-- )
@@ -352,7 +347,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * the intermediate tables will be freed below after the ept flush
          *
          * Read-then-write is OK because we hold the p2m lock. */
-        old_entry =3D *ept_entry;
+        old_entry->epte =3D ept_entry->epte;

         if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
              (p2mt =3D=3D p2m_ram_paging_in) )
@@ -369,7 +364,7 @@ ept_set_entry(struct p2m_domain *p2m, un

             new_entry.mfn =3D mfn_x(mfn);

-            if ( old_entry.mfn =3D=3D new_entry.mfn )
+            if ( old_entry->mfn =3D=3D new_entry.mfn )
                 need_modify_vtd_table =3D 0;

             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
@@ -438,9 +433,6 @@ ept_set_entry(struct p2m_domain *p2m, un
 out:
     unmap_domain_page(table);

-    if ( needs_sync )
-        ept_sync_domain(p2m->domain);
-
     if ( rv && iommu_enabled && need_iommu(p2m->domain) &&
need_modify_vtd_table )
     {
         if ( iommu_hap_pt_share )
@@ -473,6 +465,28 @@ out:
         }
     }

+    return rv;
+}
+
+static int
+ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+{
+    int target =3D order / EPT_TABLE_ORDER;
+    int rv =3D 0;
+    bool_t needs_sync =3D 1;
+    ept_entry_t old_entry =3D { .epte =3D 0 };
+
+    ASSERT((target =3D=3D 2 && hvm_hap_has_1gb(d)) ||
+           (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
+           (target =3D=3D 0));
+
+    rv =3D __ept_set_entry(p2m, gfn, mfn, order, p2mt, p2ma, &old_entry,
+                         &needs_sync);
+
+    if ( needs_sync )
+        ept_sync_domain(p2m->domain);
+
     /* Release the old intermediate tables, if any.  This has to be the
        last thing we do, after the ept_sync_domain() and removal
        from the iommu tables, so as to avoid a potential

changeset:   25253:07225bc67197
summary:     mem_access: Add xc_hvm_mem_access_bulk() API

diff -r b1bde8691257 -r 07225bc67197 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/tools/libxc/xc_misc.c	Thu Apr 26 17:10:35 2012 -0700
@@ -570,6 +570,57 @@ int xc_hvm_set_mem_access(
     return rc;
 }

+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t mem_access,
+    xen_pfn_t *arr, int *err, uint64_t nr)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_access_bulk, arg);
+    DECLARE_HYPERCALL_BOUNCE(arr, sizeof(xen_pfn_t) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(err, sizeof(int) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    int rc;
+
+    arg =3D xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+    if ( arg =3D=3D NULL )
+    {
+        PERROR("Could not allocate memory for
xc_hvm_set_mem_access_bulk hypercall");
+        return -1;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, arr) ) {
+        PERROR("Could not bounce arr for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, err) ) {
+        PERROR("Could not bounce err for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    arg->domid         =3D dom;
+    arg->hvmmem_access =3D mem_access;
+    arg->nr            =3D nr;
+    set_xen_guest_handle(arg->arr, arr);
+    set_xen_guest_handle(arg->err, err);
+
+    hypercall.op     =3D __HYPERVISOR_hvm_op;
+    hypercall.arg[0] =3D HVMOP_set_mem_access_bulk;
+    hypercall.arg[1] =3D HYPERCALL_BUFFER_AS_ARG(arg);
+
+    rc =3D do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, arg);
+    xc_hypercall_bounce_post(xch, arr);
+    xc_hypercall_bounce_post(xch, err);
+
+    return rc;
+}
+
 int xc_hvm_get_mem_access(
     xc_interface *xch, domid_t dom, uint64_t pfn, hvmmem_access_t* mem_acc=
ess)
 {
diff -r b1bde8691257 -r 07225bc67197 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Apr 26 17:10:29 2012 -0700
+++ b/tools/libxc/xenctrl.h	Thu Apr 26 17:10:35 2012 -0700
@@ -1568,6 +1568,17 @@ int xc_hvm_set_mem_access(
     xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
uint64_t first_pfn, uint64_t nr);

 /*
+ * Set the arry of pfns to a specific access.
+ * When a pfn cannot be set to the specified access, its respective field =
in
+ * @err is set to the corresponding errno value.
+ * Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combinati=
on of
+ * HVM_access_ + (rwx), and HVM_access_rx2rw
+ */
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
+    xen_pfn_t *arr, int *err, uint64_t num);
+
+/*
  * Gets the mem access for the given page (returned in memacess on success)
  */
 int xc_hvm_get_mem_access(
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/hvm/hvm.c	Thu Apr 26 17:10:35 2012 -0700
@@ -4197,6 +4197,51 @@ long do_hvm_op(unsigned long op, XEN_GUE
         break;
     }

+    case HVMOP_set_mem_access_bulk:
+    {
+        struct xen_hvm_set_mem_access_bulk a;
+        struct domain *d;
+        xen_pfn_t *arr =3D 0;
+        int *err =3D 0;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc =3D rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        if ( rc !=3D 0 )
+            return rc;
+
+        rc =3D -EINVAL;
+
+        if ( !is_hvm_domain(d) )
+            goto param_fail9;
+
+        rc =3D -ENOMEM;
+        arr =3D xmalloc_array(xen_pfn_t, a.nr);
+        if (!arr)
+            goto param_fail9;
+
+        err =3D xmalloc_array(int, a.nr);
+        if (!err)
+            goto param_fail9;
+
+        if ( copy_from_guest(arr, a.arr, a.nr) )
+            goto param_fail9;
+
+        rc =3D p2m_set_access_bulk(d, arr, err, a.nr, a.hvmmem_access);
+
+        if ( copy_to_guest(a.err, err, a.nr) )
+            goto param_fail9;
+
+    param_fail9:
+        rcu_unlock_domain(d);
+        if (arr)
+            xfree(arr);
+        if (err)
+            xfree(err);
+        break;
+    }
+
     case HVMOP_get_mem_access:
     {
         struct xen_hvm_get_mem_access a;
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 17:10:35 2012 -0700
@@ -597,6 +597,63 @@ out:
     return mfn;
 }

+static int
+ept_set_entry_bulk(struct p2m_domain *p2m, xen_pfn_t *arr, int *err,
+                   uint64_t nr, unsigned int order, p2m_access_t p2ma)
+{
+    unsigned long pfn;
+    p2m_access_t a;
+    p2m_type_t t;
+    mfn_t mfn;
+    int target =3D order / EPT_TABLE_ORDER;
+    int rc;
+    bool_t needs_sync, bulk_needs_sync =3D 0;
+    struct domain *d =3D p2m->domain;
+    ept_entry_t *old_entries =3D 0;
+
+    ASSERT((target =3D=3D 2 && hvm_hap_has_1gb(d)) ||
+           (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
+           (target =3D=3D 0));
+
+    old_entries =3D xzalloc_array(ept_entry_t, nr);
+    if ( !old_entries )
+        return 0;
+
+    memset(err, 0, nr * sizeof(int));
+    for ( pfn =3D 0; pfn < nr; pfn++ )
+    {
+        if ( arr[pfn] > domain_get_maximum_gpfn(d) )
+        {
+            err[pfn] =3D -EINVAL;
+            continue;
+        }
+
+        needs_sync =3D 1;
+        mfn =3D ept_get_entry(p2m, arr[pfn], &t, &a, 0, NULL);
+        rc =3D __ept_set_entry(p2m, arr[pfn], mfn, order, t, p2ma,
+                             &old_entries[pfn], &needs_sync);
+        if (rc =3D=3D 0)
+            err[pfn] =3D -ENOMEM;
+
+        if ( needs_sync )
+            bulk_needs_sync =3D 1;
+    }
+
+    if ( bulk_needs_sync )
+        ept_sync_domain(p2m->domain);
+
+    /* Release the old intermediate tables, if any.  This has to be the
+       last thing we do, after the ept_sync_domain() and removal
+       from the iommu tables, so as to avoid a potential
+       use-after-free. */
+    for ( pfn =3D 0; pfn < nr; pfn++ )
+        if ( is_epte_present(&old_entries[pfn]) )
+            ept_free_entry(p2m, &old_entries[pfn], target);
+
+    /* Success */
+    return 1;
+}
+
 /* WARNING: Only caller doesn't care about PoD pages.  So this function wi=
ll
  * always return 0 for PoD pages, not populate them.  If that becomes
necessary,
  * pass a p2m_query_t type along to distinguish. */
@@ -808,6 +865,7 @@ static void ept_change_entry_type_global
 void ept_p2m_init(struct p2m_domain *p2m)
 {
     p2m->set_entry =3D ept_set_entry;
+    p2m->set_entry_bulk =3D ept_set_entry_bulk;
     p2m->get_entry =3D ept_get_entry;
     p2m->change_entry_type_global =3D ept_change_entry_type_global;
     p2m->audit_p2m =3D NULL;
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Apr 26 17:10:35 2012 -0700
@@ -1139,6 +1139,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
 void p2m_pt_init(struct p2m_domain *p2m)
 {
     p2m->set_entry =3D p2m_set_entry;
+    p2m->set_entry_bulk =3D NULL;
     p2m->get_entry =3D p2m_gfn_to_mfn;
     p2m->change_entry_type_global =3D p2m_change_type_global;
     p2m->write_p2m_entry =3D paging_write_p2m_entry;
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 26 17:10:35 2012 -0700
@@ -1334,6 +1334,42 @@ int p2m_set_mem_access(struct domain *d,
     return rc;
 }

+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access)
+{
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+    p2m_access_t a;
+    p2m_access_t memaccess[] =3D {
+        p2m_access_n,
+        p2m_access_r,
+        p2m_access_w,
+        p2m_access_rw,
+        p2m_access_x,
+        p2m_access_rx,
+        p2m_access_wx,
+        p2m_access_rwx,
+        p2m_access_rx2rw,
+        p2m_access_n2rwx,
+        p2m->default_access,
+    };
+    int rc =3D 0;
+
+    ASSERT(p2m->set_entry_bulk);
+
+    if ( (unsigned) access >=3D HVMMEM_access_default )
+        return -EINVAL;
+
+    a =3D memaccess[access];
+
+    p2m_lock(p2m);
+    if ( p2m->set_entry_bulk(p2m, arr, err, nr, PAGE_ORDER_4K, a) =3D=3D 0=
 )
+        rc =3D -ENOMEM;
+    p2m_unlock(p2m);
+
+    return rc;
+}
+
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
diff -r b1bde8691257 -r 07225bc67197 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 26 17:10:35 2012 -0700
@@ -232,6 +232,13 @@ struct p2m_domain {
                                        mfn_t mfn, unsigned int page_order,
                                        p2m_type_t p2mt,
                                        p2m_access_t p2ma);
+    int                (*set_entry_bulk)(struct p2m_domain *p2m,
+                                         xen_pfn_t *arr,
+                                         int *err,
+                                         uint64_t nr,
+                                         unsigned int order,
+                                         p2m_access_t p2ma);
+
     mfn_t              (*get_entry   )(struct p2m_domain *p2m,
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,
@@ -568,6 +575,11 @@ void p2m_mem_access_resume(struct domain
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn,
                        uint32_t nr, hvmmem_access_t access);

+/* Set access type for an array of pfns. set_mem_access success or failure=
 is
+ * returned in the err array. */
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access);
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
@@ -583,7 +595,11 @@ static inline int p2m_set_mem_access(str
                                      unsigned long start_pfn,
                                      uint32_t nr, hvmmem_access_t access)
 { return -EINVAL; }
-static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
+static inline int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr,
+                                      int *err, uint64_t nr,
+                                      hvmmem_access_t access)
+{ return -EINVAL; }
+static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
                                      hvmmem_access_t *access)
 { return -EINVAL; }
 #endif
diff -r b1bde8691257 -r 07225bc67197 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/include/public/hvm/hvm_op.h	Thu Apr 26 17:10:35 2012 -0700
@@ -261,4 +261,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_inject_m

 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */

+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define HVMOP_set_mem_access_bulk      17
+/* Notify that a array of pfns is to have specific access types */
+struct xen_hvm_set_mem_access_bulk {
+    /* Domain to be updated. */
+    domid_t domid;
+    /* Memory type */
+    uint16_t hvmmem_access; /* hvm_access_t */
+    /* Array of pfns */
+    XEN_GUEST_HANDLE_64(xen_pfn_t) arr;
+    XEN_GUEST_HANDLE_64(int) err ;
+    /* Number of entries */
+    uint64_t nr;
+};
+typedef struct xen_hvm_set_mem_access_bulk xen_hvm_set_mem_access_bulk_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_mem_access_bulk_t);
+#endif
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:16:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNYqs-0002iy-At; Fri, 27 Apr 2012 00:15:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNYqq-0002it-WE
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 00:15:57 +0000
Received: from [193.109.254.147:62987] by server-2.bemta-14.messagelabs.com id
	90/05-19409-C35E99F4; Fri, 27 Apr 2012 00:15:56 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335485753!6553564!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20760 invoked from network); 27 Apr 2012 00:15:54 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 00:15:54 -0000
Received: by lboi15 with SMTP id i15so146063lbo.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 17:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=rchMN0MWwR0QUtisWjf79oLDBZRG0y3NJ6vjdIslO6o=;
	b=ThMjzeYNhFI3E6U+0tlG7b3f5pFsJzYJNl28PXOien9wWJxJmDw5LE3w5Gleh9PeSL
	lNRsob92ugJAvAhyMRXBYSQkA77n+UZy1+wvRoeBgFj7IEO/+QNZdDq35qieZsBCu3Uq
	IhttAwsHbVAU75x4fyAVeg/ndIWLGAU5uXIcs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=rchMN0MWwR0QUtisWjf79oLDBZRG0y3NJ6vjdIslO6o=;
	b=Olg9VxxbFptQJIQQ+nB4dnUydShyWL0upRwg/blPT1lSztZQwNyM1mCqNg2fpBoDQh
	D047db15gc5MLCmhQKpC4h0gKe+6OdYMzILhz+PN9zTsR5Ii8l7Dn1E5qU6drk4THM/z
	LApbsyMM8kYA5ibAvmYwsP4RWR2HR+fxh9z0sX145Qot8yAx/VjWFYXfrfWOp/NmJ0Ia
	abUKqS9/nphDtg7X8gNuMo3rjfVA52GF44LK7YrqFDbYyCo2/Jllpvt3TJkIBnTEO1xI
	rxIQcvdu3jzpV1S2eHiNjdanbP/8mzed+K7toHUX6E9E9iUZzYECgHHL+3LFg0S/JBdc
	kGdw==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr4398282lbm.31.1335485753518; Thu,
	26 Apr 2012 17:15:53 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 17:15:53 -0700 (PDT)
X-Originating-IP: [69.181.20.64]
In-Reply-To: <CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
Date: Thu, 26 Apr 2012 17:15:53 -0700
Message-ID: <CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQnznG47w2nHwkxFm4ePkNaGMJkXvrBAnOTZKQv7tuzd9nfkxjxSY/wlIUinbaJDyKA6kZgp
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 3:41 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Thu, Apr 26, 2012 at 1:20 PM, Christian Limpach
> <christian.limpach@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 11:33 AM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>> When the mem_access type needs to be changed for multiple discontiguous=
 gfns, calling xc_hvm_set_mem_access() multiple times does not perform very=
 well. The main pain points are the multiple libxc calls themselves plus th=
e multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() ca=
lls for each ept_set_entry(gfn). The following patches adds a new mem_acces=
s API that sets the mem_access type for an array of guest physical addresse=
s in one libxc call with minimal map_domain_page() / unmap_domain_page() an=
d ept_sync_domain() calls.
>>
>>
>> Are you sure that your bulk code actually works? =A0It seems to me that
>> your __ept_set_entry function assumes that table still points to the
>> top of the p2m. =A0The "for ( i =3D ept_get_wl(d); i > target; i-- )" lo=
op
>> will walk the table, and so in the subsequent calls from your bulk
>> loop, this won't work?
>>
>> I think you need something like an iterator, the context of which can
>> be passed around...
>
> Duh! You are right. My test code has been giving me a false positive.
> I completely misread how ept_next_level() works.
>
>> Also, the call to ept_get_entry in your bulk loop will do a walk in
>> every iteration, it seems a bit arbitrary to only (try to) avoid one
>> and not the other. =A0But I guess the "win" is from reducing the number
>> of ept_sync_domain calls.
>
> You are right. I was mainly focusing on removing the multiple libxc
> calls and reducing the ept_sync_domain calls. I thought removing the
> map and unmap of the p2m top page was an extra optimization which I
> obviously messed up. I will rework the patch to only stick with the
> original optimization I had in mind.

Does this look correct now?

Thanks,
Aravindh

changeset:   25252:b1bde8691257
summary:     x86/mm: Split ept_set_entry()

diff -r 63eb1343cbdb -r b1bde8691257 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Wed Apr 25 19:29:53 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 17:10:29 2012 -0700
@@ -272,12 +272,13 @@ static int ept_next_level(struct p2m_dom
 }

 /*
- * ept_set_entry() computes 'need_modify_vtd_table' for itself,
+ * __ept_set_entry() computes 'need_modify_vtd_table' for itself,
  * by observing whether any gfn->mfn translations are modified.
  */
 static int
-ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
-              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+__ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+                unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
+                ept_entry_t *old_entry, bool_t *needs_sync)
 {
     ept_entry_t *table, *ept_entry =3D NULL;
     unsigned long gfn_remainder =3D gfn;
@@ -288,11 +289,9 @@ ept_set_entry(struct p2m_domain *p2m, un
     int ret =3D 0;
     bool_t direct_mmio =3D (p2mt =3D=3D p2m_mmio_direct);
     uint8_t ipat =3D 0;
-    int need_modify_vtd_table =3D 1;
-    int vtd_pte_present =3D 0;
-    int needs_sync =3D 1;
+    bool_t need_modify_vtd_table =3D 1;
+    bool_t vtd_pte_present =3D 0;
     struct domain *d =3D p2m->domain;
-    ept_entry_t old_entry =3D { .epte =3D 0 };

     /*
      * the caller must make sure:
@@ -305,10 +304,6 @@ ept_set_entry(struct p2m_domain *p2m, un
          (order % EPT_TABLE_ORDER) )
         return 0;

-    ASSERT((target =3D=3D 2 && hvm_hap_has_1gb(d)) ||
-           (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
-           (target =3D=3D 0));
-
     table =3D map_domain_page(ept_get_asr(d));

     for ( i =3D ept_get_wl(d); i > target; i-- )
@@ -352,7 +347,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * the intermediate tables will be freed below after the ept flush
          *
          * Read-then-write is OK because we hold the p2m lock. */
-        old_entry =3D *ept_entry;
+        old_entry->epte =3D ept_entry->epte;

         if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
              (p2mt =3D=3D p2m_ram_paging_in) )
@@ -369,7 +364,7 @@ ept_set_entry(struct p2m_domain *p2m, un

             new_entry.mfn =3D mfn_x(mfn);

-            if ( old_entry.mfn =3D=3D new_entry.mfn )
+            if ( old_entry->mfn =3D=3D new_entry.mfn )
                 need_modify_vtd_table =3D 0;

             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
@@ -438,9 +433,6 @@ ept_set_entry(struct p2m_domain *p2m, un
 out:
     unmap_domain_page(table);

-    if ( needs_sync )
-        ept_sync_domain(p2m->domain);
-
     if ( rv && iommu_enabled && need_iommu(p2m->domain) &&
need_modify_vtd_table )
     {
         if ( iommu_hap_pt_share )
@@ -473,6 +465,28 @@ out:
         }
     }

+    return rv;
+}
+
+static int
+ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+{
+    int target =3D order / EPT_TABLE_ORDER;
+    int rv =3D 0;
+    bool_t needs_sync =3D 1;
+    ept_entry_t old_entry =3D { .epte =3D 0 };
+
+    ASSERT((target =3D=3D 2 && hvm_hap_has_1gb(d)) ||
+           (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
+           (target =3D=3D 0));
+
+    rv =3D __ept_set_entry(p2m, gfn, mfn, order, p2mt, p2ma, &old_entry,
+                         &needs_sync);
+
+    if ( needs_sync )
+        ept_sync_domain(p2m->domain);
+
     /* Release the old intermediate tables, if any.  This has to be the
        last thing we do, after the ept_sync_domain() and removal
        from the iommu tables, so as to avoid a potential

changeset:   25253:07225bc67197
summary:     mem_access: Add xc_hvm_mem_access_bulk() API

diff -r b1bde8691257 -r 07225bc67197 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/tools/libxc/xc_misc.c	Thu Apr 26 17:10:35 2012 -0700
@@ -570,6 +570,57 @@ int xc_hvm_set_mem_access(
     return rc;
 }

+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t mem_access,
+    xen_pfn_t *arr, int *err, uint64_t nr)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_access_bulk, arg);
+    DECLARE_HYPERCALL_BOUNCE(arr, sizeof(xen_pfn_t) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(err, sizeof(int) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    int rc;
+
+    arg =3D xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+    if ( arg =3D=3D NULL )
+    {
+        PERROR("Could not allocate memory for
xc_hvm_set_mem_access_bulk hypercall");
+        return -1;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, arr) ) {
+        PERROR("Could not bounce arr for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, err) ) {
+        PERROR("Could not bounce err for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    arg->domid         =3D dom;
+    arg->hvmmem_access =3D mem_access;
+    arg->nr            =3D nr;
+    set_xen_guest_handle(arg->arr, arr);
+    set_xen_guest_handle(arg->err, err);
+
+    hypercall.op     =3D __HYPERVISOR_hvm_op;
+    hypercall.arg[0] =3D HVMOP_set_mem_access_bulk;
+    hypercall.arg[1] =3D HYPERCALL_BUFFER_AS_ARG(arg);
+
+    rc =3D do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, arg);
+    xc_hypercall_bounce_post(xch, arr);
+    xc_hypercall_bounce_post(xch, err);
+
+    return rc;
+}
+
 int xc_hvm_get_mem_access(
     xc_interface *xch, domid_t dom, uint64_t pfn, hvmmem_access_t* mem_acc=
ess)
 {
diff -r b1bde8691257 -r 07225bc67197 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Apr 26 17:10:29 2012 -0700
+++ b/tools/libxc/xenctrl.h	Thu Apr 26 17:10:35 2012 -0700
@@ -1568,6 +1568,17 @@ int xc_hvm_set_mem_access(
     xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
uint64_t first_pfn, uint64_t nr);

 /*
+ * Set the arry of pfns to a specific access.
+ * When a pfn cannot be set to the specified access, its respective field =
in
+ * @err is set to the corresponding errno value.
+ * Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combinati=
on of
+ * HVM_access_ + (rwx), and HVM_access_rx2rw
+ */
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
+    xen_pfn_t *arr, int *err, uint64_t num);
+
+/*
  * Gets the mem access for the given page (returned in memacess on success)
  */
 int xc_hvm_get_mem_access(
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/hvm/hvm.c	Thu Apr 26 17:10:35 2012 -0700
@@ -4197,6 +4197,51 @@ long do_hvm_op(unsigned long op, XEN_GUE
         break;
     }

+    case HVMOP_set_mem_access_bulk:
+    {
+        struct xen_hvm_set_mem_access_bulk a;
+        struct domain *d;
+        xen_pfn_t *arr =3D 0;
+        int *err =3D 0;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc =3D rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        if ( rc !=3D 0 )
+            return rc;
+
+        rc =3D -EINVAL;
+
+        if ( !is_hvm_domain(d) )
+            goto param_fail9;
+
+        rc =3D -ENOMEM;
+        arr =3D xmalloc_array(xen_pfn_t, a.nr);
+        if (!arr)
+            goto param_fail9;
+
+        err =3D xmalloc_array(int, a.nr);
+        if (!err)
+            goto param_fail9;
+
+        if ( copy_from_guest(arr, a.arr, a.nr) )
+            goto param_fail9;
+
+        rc =3D p2m_set_access_bulk(d, arr, err, a.nr, a.hvmmem_access);
+
+        if ( copy_to_guest(a.err, err, a.nr) )
+            goto param_fail9;
+
+    param_fail9:
+        rcu_unlock_domain(d);
+        if (arr)
+            xfree(arr);
+        if (err)
+            xfree(err);
+        break;
+    }
+
     case HVMOP_get_mem_access:
     {
         struct xen_hvm_get_mem_access a;
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Apr 26 17:10:35 2012 -0700
@@ -597,6 +597,63 @@ out:
     return mfn;
 }

+static int
+ept_set_entry_bulk(struct p2m_domain *p2m, xen_pfn_t *arr, int *err,
+                   uint64_t nr, unsigned int order, p2m_access_t p2ma)
+{
+    unsigned long pfn;
+    p2m_access_t a;
+    p2m_type_t t;
+    mfn_t mfn;
+    int target =3D order / EPT_TABLE_ORDER;
+    int rc;
+    bool_t needs_sync, bulk_needs_sync =3D 0;
+    struct domain *d =3D p2m->domain;
+    ept_entry_t *old_entries =3D 0;
+
+    ASSERT((target =3D=3D 2 && hvm_hap_has_1gb(d)) ||
+           (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
+           (target =3D=3D 0));
+
+    old_entries =3D xzalloc_array(ept_entry_t, nr);
+    if ( !old_entries )
+        return 0;
+
+    memset(err, 0, nr * sizeof(int));
+    for ( pfn =3D 0; pfn < nr; pfn++ )
+    {
+        if ( arr[pfn] > domain_get_maximum_gpfn(d) )
+        {
+            err[pfn] =3D -EINVAL;
+            continue;
+        }
+
+        needs_sync =3D 1;
+        mfn =3D ept_get_entry(p2m, arr[pfn], &t, &a, 0, NULL);
+        rc =3D __ept_set_entry(p2m, arr[pfn], mfn, order, t, p2ma,
+                             &old_entries[pfn], &needs_sync);
+        if (rc =3D=3D 0)
+            err[pfn] =3D -ENOMEM;
+
+        if ( needs_sync )
+            bulk_needs_sync =3D 1;
+    }
+
+    if ( bulk_needs_sync )
+        ept_sync_domain(p2m->domain);
+
+    /* Release the old intermediate tables, if any.  This has to be the
+       last thing we do, after the ept_sync_domain() and removal
+       from the iommu tables, so as to avoid a potential
+       use-after-free. */
+    for ( pfn =3D 0; pfn < nr; pfn++ )
+        if ( is_epte_present(&old_entries[pfn]) )
+            ept_free_entry(p2m, &old_entries[pfn], target);
+
+    /* Success */
+    return 1;
+}
+
 /* WARNING: Only caller doesn't care about PoD pages.  So this function wi=
ll
  * always return 0 for PoD pages, not populate them.  If that becomes
necessary,
  * pass a p2m_query_t type along to distinguish. */
@@ -808,6 +865,7 @@ static void ept_change_entry_type_global
 void ept_p2m_init(struct p2m_domain *p2m)
 {
     p2m->set_entry =3D ept_set_entry;
+    p2m->set_entry_bulk =3D ept_set_entry_bulk;
     p2m->get_entry =3D ept_get_entry;
     p2m->change_entry_type_global =3D ept_change_entry_type_global;
     p2m->audit_p2m =3D NULL;
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Apr 26 17:10:35 2012 -0700
@@ -1139,6 +1139,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
 void p2m_pt_init(struct p2m_domain *p2m)
 {
     p2m->set_entry =3D p2m_set_entry;
+    p2m->set_entry_bulk =3D NULL;
     p2m->get_entry =3D p2m_gfn_to_mfn;
     p2m->change_entry_type_global =3D p2m_change_type_global;
     p2m->write_p2m_entry =3D paging_write_p2m_entry;
diff -r b1bde8691257 -r 07225bc67197 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/arch/x86/mm/p2m.c	Thu Apr 26 17:10:35 2012 -0700
@@ -1334,6 +1334,42 @@ int p2m_set_mem_access(struct domain *d,
     return rc;
 }

+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access)
+{
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+    p2m_access_t a;
+    p2m_access_t memaccess[] =3D {
+        p2m_access_n,
+        p2m_access_r,
+        p2m_access_w,
+        p2m_access_rw,
+        p2m_access_x,
+        p2m_access_rx,
+        p2m_access_wx,
+        p2m_access_rwx,
+        p2m_access_rx2rw,
+        p2m_access_n2rwx,
+        p2m->default_access,
+    };
+    int rc =3D 0;
+
+    ASSERT(p2m->set_entry_bulk);
+
+    if ( (unsigned) access >=3D HVMMEM_access_default )
+        return -EINVAL;
+
+    a =3D memaccess[access];
+
+    p2m_lock(p2m);
+    if ( p2m->set_entry_bulk(p2m, arr, err, nr, PAGE_ORDER_4K, a) =3D=3D 0=
 )
+        rc =3D -ENOMEM;
+    p2m_unlock(p2m);
+
+    return rc;
+}
+
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
diff -r b1bde8691257 -r 07225bc67197 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/include/asm-x86/p2m.h	Thu Apr 26 17:10:35 2012 -0700
@@ -232,6 +232,13 @@ struct p2m_domain {
                                        mfn_t mfn, unsigned int page_order,
                                        p2m_type_t p2mt,
                                        p2m_access_t p2ma);
+    int                (*set_entry_bulk)(struct p2m_domain *p2m,
+                                         xen_pfn_t *arr,
+                                         int *err,
+                                         uint64_t nr,
+                                         unsigned int order,
+                                         p2m_access_t p2ma);
+
     mfn_t              (*get_entry   )(struct p2m_domain *p2m,
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,
@@ -568,6 +575,11 @@ void p2m_mem_access_resume(struct domain
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn,
                        uint32_t nr, hvmmem_access_t access);

+/* Set access type for an array of pfns. set_mem_access success or failure=
 is
+ * returned in the err array. */
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access);
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
@@ -583,7 +595,11 @@ static inline int p2m_set_mem_access(str
                                      unsigned long start_pfn,
                                      uint32_t nr, hvmmem_access_t access)
 { return -EINVAL; }
-static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
+static inline int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr,
+                                      int *err, uint64_t nr,
+                                      hvmmem_access_t access)
+{ return -EINVAL; }
+static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
                                      hvmmem_access_t *access)
 { return -EINVAL; }
 #endif
diff -r b1bde8691257 -r 07225bc67197 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h	Thu Apr 26 17:10:29 2012 -0700
+++ b/xen/include/public/hvm/hvm_op.h	Thu Apr 26 17:10:35 2012 -0700
@@ -261,4 +261,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_inject_m

 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */

+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define HVMOP_set_mem_access_bulk      17
+/* Notify that a array of pfns is to have specific access types */
+struct xen_hvm_set_mem_access_bulk {
+    /* Domain to be updated. */
+    domid_t domid;
+    /* Memory type */
+    uint16_t hvmmem_access; /* hvm_access_t */
+    /* Array of pfns */
+    XEN_GUEST_HANDLE_64(xen_pfn_t) arr;
+    XEN_GUEST_HANDLE_64(int) err ;
+    /* Number of entries */
+    uint64_t nr;
+};
+typedef struct xen_hvm_set_mem_access_bulk xen_hvm_set_mem_access_bulk_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_mem_access_bulk_t);
+#endif
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:45:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZJH-0002yl-0B; Fri, 27 Apr 2012 00:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNZJE-0002yg-Vf
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 00:45:17 +0000
Received: from [85.158.143.35:39327] by server-1.bemta-4.messagelabs.com id
	2E/AD-20925-C1CE99F4; Fri, 27 Apr 2012 00:45:16 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335487513!6747820!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTM0NDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15059 invoked from network); 27 Apr 2012 00:45:15 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 00:45:15 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Thu, 26 Apr
	2012 20:45:12 -0400
Received: from HCAZUSCH2.hitachiconsulting.net (172.16.1.120) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 19:45:09 -0500
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 19:45:08 -0500
Received: from [10.67.7.194] (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Fri, 27 Apr 2012 06:15:05 +0530
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335433871.4742.18.camel@goosenl-desktop>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
	<1335432002.28015.78.camel@zakaz.uk.xensource.com>
	<1335433871.4742.18.camel@goosenl-desktop>
Organization: Sierra Atlantic
Date: Fri, 27 Apr 2012 08:45:27 +0800
Message-ID: <1335487527.4742.19.camel@goosenl-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042620451200601
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Xuesen.Guo@hitachiconsulting.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# Parent d690c7e896a26c54a5ab85458824059de72d5cba
readnote: Add bzImage kernel support

Add the check of bzImage kernel and make it work
with RHEL 6 big zImage kernel

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
Changed since v1:
  * add additional checks of the offset and length
  * not changing st.st_size, use size instead of st.st_size
  
---
Changed since v2:
  * changing decription bzipped kernels to big zImage kernel

diff -r d690c7e896a2 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:16 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel()
function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary
*elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,13 +204,45 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
-	size = st.st_size;
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__,
hdr->version);
+			return 1;
+		}
 
-	usize = xc_dom_check_gzip(xch, image, st.st_size);
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+		
+		if ( payload_offset >= st.st_size )
+		{
+			printf("%s: payload offset overflow", __FUNCTION__);
+			return 1;
+		}
+		if ( (payload_offset + payload_length) > st.st_size )
+		{
+			printf("%s: payload length overflow", __FUNCTION__);
+			return 1;
+		}
+
+		image = image + payload_offset;
+		size = payload_length;
+	} else {
+		size = st.st_size;
+	}
+
+	usize = xc_dom_check_gzip(xch, image, size);
 	if (usize)
 	{
 		tmp = malloc(usize);
-		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
+		xc_dom_do_gunzip(xch, image, size, tmp, usize);
 		image = tmp;
 		size = usize;
 	}


On Thu, 2012-04-26 at 17:51 +0800, Xuesen Guo wrote:
> I fixed the confusion, shall I need to resend this patch?
> ------------------------------------------------------------------------
> readnote: Add bzImage kernel support
> 
> Add the check of bzImage kernel and make it work
> with RHEL 6 big zImage kernel
> 
> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ---
> Changed since v1:
>   * add additional checks of the offset and length
>   * not changing st.st_size, use size instead of st.st_size
>   
> ---
> Changed since v2:
>   * changing decription bzipped kernels to big zImage kernel
> 
> 
> Thanks!
> Xuesen 
> 
> On Thu, 2012-04-26 at 10:20 +0100, Ian Campbell wrote: 
> > On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
> > > >>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com> wrote:
> > > > Add the check of bzImage kernel and make it work
> > > > with RHEL 6 bzipped kernels
> > > 
> > > I fail to see the relation of the term "bzipped" above to the actual patch.
> > 
> > Oh yes, this is a common misconception (which I failed to notice in my
> > review).
> > 
> > The "bz" in bzImage does not refer to the bzip compression algorithm.
> > Rather it refers to "big zImage". It's a historical thing because the
> > original zImage compressor was restricted to <1M (or something) of RAM
> > at decompression time and bzImage was introduced to cope with more and
> > therefore worked for larger kernels. Obviously 1M is very limiting to in
> > practice everyone uses bzImage today...
> > 
> > Now of course today, just to add to the confusion, bzImage can support
> > multiple compression algorithms, including the original z, but also
> > bzip2, lzma and xz.
> > 
> > Ian
> > 
> > > 
> > > Jan
> > > 
> > > > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > > > 
> > > > ---
> > > > Changed since v1:
> > > >   * add additional checks of the offset and length
> > > >   * not changing st.st_size, use size instead of st.st_size
> > > > 
> > > > diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> > > > --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> > > > +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> > > > @@ -18,6 +18,48 @@
> > > >  
> > > >  static xc_interface *xch;
> > > >  
> > > > +/* According to the implemation of xc_dom_probe_bzimage_kernel() function 
> > > > */
> > > > +/* We add support of bzImage kernel */
> > > > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > > > +struct setup_header {
> > > > +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > > > +	uint8_t  setup_sects;
> > > > +	uint16_t root_flags;
> > > > +	uint32_t syssize;
> > > > +	uint16_t ram_size;
> > > > +	uint16_t vid_mode;
> > > > +	uint16_t root_dev;
> > > > +	uint16_t boot_flag;
> > > > +	uint16_t jump;
> > > > +	uint32_t header;
> > > > +#define HDR_MAGIC  "HdrS"
> > > > +#define HDR_MAGIC_SZ 4
> > > > +	uint16_t version;
> > > > +#define VERSION(h,l) (((h)<<8) | (l))
> > > > +	uint32_t realmode_swtch;
> > > > +	uint16_t start_sys;
> > > > +	uint16_t kernel_version;
> > > > +	uint8_t  type_of_loader;
> > > > +	uint8_t  loadflags;
> > > > +	uint16_t setup_move_size;
> > > > +	uint32_t code32_start;
> > > > +	uint32_t ramdisk_image;
> > > > +	uint32_t ramdisk_size;
> > > > +	uint32_t bootsect_kludge;
> > > > +	uint16_t heap_end_ptr;
> > > > +	uint16_t _pad1;
> > > > +	uint32_t cmd_line_ptr;
> > > > +	uint32_t initrd_addr_max;
> > > > +	uint32_t kernel_alignment;
> > > > +	uint8_t  relocatable_kernel;
> > > > +	uint8_t  _pad2[3];
> > > > +	uint32_t cmdline_size;
> > > > +	uint32_t hardware_subarch;
> > > > +	uint64_t hardware_subarch_data;
> > > > +	uint32_t payload_offset;
> > > > +	uint32_t payload_length;
> > > > +} __attribute__((packed));
> > > > +
> > > >  static void print_string_note(const char *prefix, struct elf_binary *elf,
> > > >  			      const elf_note *note)
> > > >  {
> > > > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> > > >  	const elf_shdr *shdr;
> > > >  	int notes_found = 0;
> > > >  
> > > > +	struct setup_header *hdr;
> > > > +	uint64_t payload_offset, payload_length;
> > > > +
> > > >  	if (argc != 2)
> > > >  	{
> > > >  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > > > @@ -159,13 +204,45 @@ int main(int argc, char **argv)
> > > >  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> > > >  		return 1;
> > > >  	}
> > > > -	size = st.st_size;
> > > > +	
> > > > +	/* Check the magic of bzImage kernel */
> > > > +	hdr = (struct setup_header *)image;
> > > > +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> > > > +	{
> > > > +		if ( hdr->version < VERSION(2,8) )
> > > > +		{
> > > > +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> > > > +			return 1;
> > > > +		}
> > > >  
> > > > -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> > > > +		/* upcast to 64 bits to avoid overflow */
> > > > +		/* setup_sects is u8 and so cannot overflow */
> > > > +		payload_offset = (hdr->setup_sects + 1) * 512;
> > > > +		payload_offset += hdr->payload_offset;
> > > > +		payload_length = hdr->payload_length;
> > > > +		
> > > > +		if ( payload_offset >= st.st_size )
> > > > +		{
> > > > +			printf("%s: payload offset overflow", __FUNCTION__);
> > > > +			return 1;
> > > > +		}
> > > > +		if ( (payload_offset + payload_length) > st.st_size )
> > > > +		{
> > > > +			printf("%s: payload length overflow", __FUNCTION__);
> > > > +			return 1;
> > > > +		}
> > > > +
> > > > +		image = image + payload_offset;
> > > > +		size = payload_length;
> > > > +	} else {
> > > > +		size = st.st_size;
> > > > +	}
> > > > +
> > > > +	usize = xc_dom_check_gzip(xch, image, size);
> > > >  	if (usize)
> > > >  	{
> > > >  		tmp = malloc(usize);
> > > > -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> > > > +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
> > > >  		image = tmp;
> > > >  		size = usize;
> > > >  	}
> > > > 
> > > > This e-mail is intended solely for the person or entity to which it is 
> > > > addressed
> > > > and may contain confidential and/or privileged information. Any review, 
> > > > dissemination,
> > > > copying, printing or other use of this e-mail by persons or entities other 
> > > > than the 
> > > > addressee is prohibited. If you have received this e-mail in error, please 
> > > > contact
> > > > the sender immediately and delete the material from any computer.
> > > > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> > > > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org 
> > > > http://lists.xen.org/xen-devel 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > 
> > 
> > 
> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:45:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZJH-0002yl-0B; Fri, 27 Apr 2012 00:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xuesen.guo@hitachiconsulting.com>)
	id 1SNZJE-0002yg-Vf
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 00:45:17 +0000
Received: from [85.158.143.35:39327] by server-1.bemta-4.messagelabs.com id
	2E/AD-20925-C1CE99F4; Fri, 27 Apr 2012 00:45:16 +0000
X-Env-Sender: xuesen.guo@hitachiconsulting.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335487513!6747820!1
X-Originating-IP: [207.211.31.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjIxMS4zMS41NSA9PiAxNTM0NDg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15059 invoked from network); 27 Apr 2012 00:45:15 -0000
Received: from service55-us.mimecast.com (HELO service55-us.mimecast.com)
	(207.211.31.55)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 00:45:15 -0000
Received: from HCAZUSCH1.hitachiconsulting.net (63.148.190.198
	[63.148.190.198]) (Using TLS) by service55-us.mimecast.com; Thu, 26 Apr
	2012 20:45:12 -0400
Received: from HCAZUSCH2.hitachiconsulting.net (172.16.1.120) by
	HCAZUSCH1.hitachiconsulting.net (172.16.1.119) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 19:45:09 -0500
Received: from HCAZINEXCH2.hitachiconsulting.net (172.16.125.109) by
	HCAZUSCH2.hitachiconsulting.net (172.16.1.120) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 19:45:08 -0500
Received: from [10.67.7.194] (10.67.7.194) by
	HCAZINEXCH2.hitachiconsulting.net (172.16.125.103) with Microsoft SMTP
	Server (TLS) id 14.1.270.1; Fri, 27 Apr 2012 06:15:05 +0530
From: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1335433871.4742.18.camel@goosenl-desktop>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
	<1335432002.28015.78.camel@zakaz.uk.xensource.com>
	<1335433871.4742.18.camel@goosenl-desktop>
Organization: Sierra Atlantic
Date: Fri, 27 Apr 2012 08:45:27 +0800
Message-ID: <1335487527.4742.19.camel@goosenl-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Originating-IP: [10.67.7.194]
X-MC-Unique: 112042620451200601
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Xuesen.Guo@hitachiconsulting.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# Parent d690c7e896a26c54a5ab85458824059de72d5cba
readnote: Add bzImage kernel support

Add the check of bzImage kernel and make it work
with RHEL 6 big zImage kernel

Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
Changed since v1:
  * add additional checks of the offset and length
  * not changing st.st_size, use size instead of st.st_size
  
---
Changed since v2:
  * changing decription bzipped kernels to big zImage kernel

diff -r d690c7e896a2 tools/xcutils/readnotes.c
--- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
+++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:16 2012 +0800
@@ -18,6 +18,48 @@
 
 static xc_interface *xch;
 
+/* According to the implemation of xc_dom_probe_bzimage_kernel()
function */
+/* We add support of bzImage kernel */
+/* Copied from tools/libxc/xc_doom_bzImageloader.c */
+struct setup_header {
+	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+	uint8_t  setup_sects;
+	uint16_t root_flags;
+	uint32_t syssize;
+	uint16_t ram_size;
+	uint16_t vid_mode;
+	uint16_t root_dev;
+	uint16_t boot_flag;
+	uint16_t jump;
+	uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+	uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+	uint32_t realmode_swtch;
+	uint16_t start_sys;
+	uint16_t kernel_version;
+	uint8_t  type_of_loader;
+	uint8_t  loadflags;
+	uint16_t setup_move_size;
+	uint32_t code32_start;
+	uint32_t ramdisk_image;
+	uint32_t ramdisk_size;
+	uint32_t bootsect_kludge;
+	uint16_t heap_end_ptr;
+	uint16_t _pad1;
+	uint32_t cmd_line_ptr;
+	uint32_t initrd_addr_max;
+	uint32_t kernel_alignment;
+	uint8_t  relocatable_kernel;
+	uint8_t  _pad2[3];
+	uint32_t cmdline_size;
+	uint32_t hardware_subarch;
+	uint64_t hardware_subarch_data;
+	uint32_t payload_offset;
+	uint32_t payload_length;
+} __attribute__((packed));
+
 static void print_string_note(const char *prefix, struct elf_binary
*elf,
 			      const elf_note *note)
 {
@@ -131,6 +173,9 @@ int main(int argc, char **argv)
 	const elf_shdr *shdr;
 	int notes_found = 0;
 
+	struct setup_header *hdr;
+	uint64_t payload_offset, payload_length;
+
 	if (argc != 2)
 	{
 		fprintf(stderr, "Usage: readnotes <elfimage>\n");
@@ -159,13 +204,45 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
 		return 1;
 	}
-	size = st.st_size;
+	
+	/* Check the magic of bzImage kernel */
+	hdr = (struct setup_header *)image;
+	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
+	{
+		if ( hdr->version < VERSION(2,8) )
+		{
+			printf("%s: boot protocol too old (%04x)", __FUNCTION__,
hdr->version);
+			return 1;
+		}
 
-	usize = xc_dom_check_gzip(xch, image, st.st_size);
+		/* upcast to 64 bits to avoid overflow */
+		/* setup_sects is u8 and so cannot overflow */
+		payload_offset = (hdr->setup_sects + 1) * 512;
+		payload_offset += hdr->payload_offset;
+		payload_length = hdr->payload_length;
+		
+		if ( payload_offset >= st.st_size )
+		{
+			printf("%s: payload offset overflow", __FUNCTION__);
+			return 1;
+		}
+		if ( (payload_offset + payload_length) > st.st_size )
+		{
+			printf("%s: payload length overflow", __FUNCTION__);
+			return 1;
+		}
+
+		image = image + payload_offset;
+		size = payload_length;
+	} else {
+		size = st.st_size;
+	}
+
+	usize = xc_dom_check_gzip(xch, image, size);
 	if (usize)
 	{
 		tmp = malloc(usize);
-		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
+		xc_dom_do_gunzip(xch, image, size, tmp, usize);
 		image = tmp;
 		size = usize;
 	}


On Thu, 2012-04-26 at 17:51 +0800, Xuesen Guo wrote:
> I fixed the confusion, shall I need to resend this patch?
> ------------------------------------------------------------------------
> readnote: Add bzImage kernel support
> 
> Add the check of bzImage kernel and make it work
> with RHEL 6 big zImage kernel
> 
> Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ---
> Changed since v1:
>   * add additional checks of the offset and length
>   * not changing st.st_size, use size instead of st.st_size
>   
> ---
> Changed since v2:
>   * changing decription bzipped kernels to big zImage kernel
> 
> 
> Thanks!
> Xuesen 
> 
> On Thu, 2012-04-26 at 10:20 +0100, Ian Campbell wrote: 
> > On Thu, 2012-04-26 at 10:13 +0100, Jan Beulich wrote:
> > > >>> On 26.04.12 at 10:54, Xuesen Guo <Xuesen.Guo@hitachiconsulting.com> wrote:
> > > > Add the check of bzImage kernel and make it work
> > > > with RHEL 6 bzipped kernels
> > > 
> > > I fail to see the relation of the term "bzipped" above to the actual patch.
> > 
> > Oh yes, this is a common misconception (which I failed to notice in my
> > review).
> > 
> > The "bz" in bzImage does not refer to the bzip compression algorithm.
> > Rather it refers to "big zImage". It's a historical thing because the
> > original zImage compressor was restricted to <1M (or something) of RAM
> > at decompression time and bzImage was introduced to cope with more and
> > therefore worked for larger kernels. Obviously 1M is very limiting to in
> > practice everyone uses bzImage today...
> > 
> > Now of course today, just to add to the confusion, bzImage can support
> > multiple compression algorithms, including the original z, but also
> > bzip2, lzma and xz.
> > 
> > Ian
> > 
> > > 
> > > Jan
> > > 
> > > > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > > > 
> > > > ---
> > > > Changed since v1:
> > > >   * add additional checks of the offset and length
> > > >   * not changing st.st_size, use size instead of st.st_size
> > > > 
> > > > diff -r d690c7e896a2 -r 27a6422ac06d tools/xcutils/readnotes.c
> > > > --- a/tools/xcutils/readnotes.c	Thu Apr 05 11:06:03 2012 +0100
> > > > +++ b/tools/xcutils/readnotes.c	Thu Apr 26 16:53:17 2012 +0800
> > > > @@ -18,6 +18,48 @@
> > > >  
> > > >  static xc_interface *xch;
> > > >  
> > > > +/* According to the implemation of xc_dom_probe_bzimage_kernel() function 
> > > > */
> > > > +/* We add support of bzImage kernel */
> > > > +/* Copied from tools/libxc/xc_doom_bzImageloader.c */
> > > > +struct setup_header {
> > > > +	uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
> > > > +	uint8_t  setup_sects;
> > > > +	uint16_t root_flags;
> > > > +	uint32_t syssize;
> > > > +	uint16_t ram_size;
> > > > +	uint16_t vid_mode;
> > > > +	uint16_t root_dev;
> > > > +	uint16_t boot_flag;
> > > > +	uint16_t jump;
> > > > +	uint32_t header;
> > > > +#define HDR_MAGIC  "HdrS"
> > > > +#define HDR_MAGIC_SZ 4
> > > > +	uint16_t version;
> > > > +#define VERSION(h,l) (((h)<<8) | (l))
> > > > +	uint32_t realmode_swtch;
> > > > +	uint16_t start_sys;
> > > > +	uint16_t kernel_version;
> > > > +	uint8_t  type_of_loader;
> > > > +	uint8_t  loadflags;
> > > > +	uint16_t setup_move_size;
> > > > +	uint32_t code32_start;
> > > > +	uint32_t ramdisk_image;
> > > > +	uint32_t ramdisk_size;
> > > > +	uint32_t bootsect_kludge;
> > > > +	uint16_t heap_end_ptr;
> > > > +	uint16_t _pad1;
> > > > +	uint32_t cmd_line_ptr;
> > > > +	uint32_t initrd_addr_max;
> > > > +	uint32_t kernel_alignment;
> > > > +	uint8_t  relocatable_kernel;
> > > > +	uint8_t  _pad2[3];
> > > > +	uint32_t cmdline_size;
> > > > +	uint32_t hardware_subarch;
> > > > +	uint64_t hardware_subarch_data;
> > > > +	uint32_t payload_offset;
> > > > +	uint32_t payload_length;
> > > > +} __attribute__((packed));
> > > > +
> > > >  static void print_string_note(const char *prefix, struct elf_binary *elf,
> > > >  			      const elf_note *note)
> > > >  {
> > > > @@ -131,6 +173,9 @@ int main(int argc, char **argv)
> > > >  	const elf_shdr *shdr;
> > > >  	int notes_found = 0;
> > > >  
> > > > +	struct setup_header *hdr;
> > > > +	uint64_t payload_offset, payload_length;
> > > > +
> > > >  	if (argc != 2)
> > > >  	{
> > > >  		fprintf(stderr, "Usage: readnotes <elfimage>\n");
> > > > @@ -159,13 +204,45 @@ int main(int argc, char **argv)
> > > >  		fprintf(stderr, "Unable to map %s: %s\n", f, strerror(errno));
> > > >  		return 1;
> > > >  	}
> > > > -	size = st.st_size;
> > > > +	
> > > > +	/* Check the magic of bzImage kernel */
> > > > +	hdr = (struct setup_header *)image;
> > > > +	if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) == 0 )
> > > > +	{
> > > > +		if ( hdr->version < VERSION(2,8) )
> > > > +		{
> > > > +			printf("%s: boot protocol too old (%04x)", __FUNCTION__, hdr->version);
> > > > +			return 1;
> > > > +		}
> > > >  
> > > > -	usize = xc_dom_check_gzip(xch, image, st.st_size);
> > > > +		/* upcast to 64 bits to avoid overflow */
> > > > +		/* setup_sects is u8 and so cannot overflow */
> > > > +		payload_offset = (hdr->setup_sects + 1) * 512;
> > > > +		payload_offset += hdr->payload_offset;
> > > > +		payload_length = hdr->payload_length;
> > > > +		
> > > > +		if ( payload_offset >= st.st_size )
> > > > +		{
> > > > +			printf("%s: payload offset overflow", __FUNCTION__);
> > > > +			return 1;
> > > > +		}
> > > > +		if ( (payload_offset + payload_length) > st.st_size )
> > > > +		{
> > > > +			printf("%s: payload length overflow", __FUNCTION__);
> > > > +			return 1;
> > > > +		}
> > > > +
> > > > +		image = image + payload_offset;
> > > > +		size = payload_length;
> > > > +	} else {
> > > > +		size = st.st_size;
> > > > +	}
> > > > +
> > > > +	usize = xc_dom_check_gzip(xch, image, size);
> > > >  	if (usize)
> > > >  	{
> > > >  		tmp = malloc(usize);
> > > > -		xc_dom_do_gunzip(xch, image, st.st_size, tmp, usize);
> > > > +		xc_dom_do_gunzip(xch, image, size, tmp, usize);
> > > >  		image = tmp;
> > > >  		size = usize;
> > > >  	}
> > > > 
> > > > This e-mail is intended solely for the person or entity to which it is 
> > > > addressed
> > > > and may contain confidential and/or privileged information. Any review, 
> > > > dissemination,
> > > > copying, printing or other use of this e-mail by persons or entities other 
> > > > than the 
> > > > addressee is prohibited. If you have received this e-mail in error, please 
> > > > contact
> > > > the sender immediately and delete the material from any computer.
> > > > To unsubscribe send an email to: Unsubscribe@hitachiconsulting.com 
> > > > Hitachi Consulting (China) Co., Ltd. (HCCD0411)
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org 
> > > > http://lists.xen.org/xen-devel 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > 
> > 
> > 
> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:47:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZKZ-00031q-F7; Fri, 27 Apr 2012 00:46:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SNZKY-00031j-Ai
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 00:46:38 +0000
Received: from [85.158.143.99:4487] by server-2.bemta-4.messagelabs.com id
	AD/A4-17550-D6CE99F4; Fri, 27 Apr 2012 00:46:37 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335487595!25447412!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIzNjI5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1172 invoked from network); 27 Apr 2012 00:46:36 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 00:46:36 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 26 Apr 2012 17:46:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="93653437"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Apr 2012 17:46:34 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 26 Apr 2012 17:46:33 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 08:46:32 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoABqsUeA//9EJFA=
Date: Fri, 27 Apr 2012 00:46:32 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
In-Reply-To: <20120426212531.GH67043@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Friday, April 27, 2012 5:26 AM
> To: Zhang, Yang Z
> Cc: andres@lagarcavilla.org; Keir Fraser; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] lock in vhpet
> 
> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> > > > But actually, the first cs introduced this issue is 24770. When
> > > > win8 booting and if hpet is enabled, it will use hpet as the time
> > > > source and there have lots of hpet access and EPT violation. In
> > > > EPT violation handler, it call get_gfn_type_access to get the mfn.
> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and then the issue
> happens.
> > > > After I removed the gfn_lock, the issue goes. But in latest xen,
> > > > even I remove this lock, it still shows high cpu utilization.
> > >
> > > It would seem then that even the briefest lock-protected critical
> > > section would cause this? In the mmio case, the p2m lock taken in
> > > the hap fault handler is held during the actual lookup, and for a
> > > couple of branch instructions afterwards.
> > >
> > > In latest Xen, with lock removed for get_gfn, on which lock is time spent?
> > Still the p2m_lock.
> 
> Can you please try the attached patch?  I think you'll need this one plus the
> ones that take the locks out of the hpet code.
> 
> This patch makes the p2m lock into an rwlock and adjusts a number of the
> paths that don't update the p2m so they only take the read lock.  It's a bit
> rough but I can boot 16-way win7 guest with it.

This really a great work! Now, the win7 guest is booting very fast and never saw the BSOD again.
But the changes are so large in your patch. I think we need to do more sanity testing to avoid any regressions. After you finish all the work, I'd like to do a whole testing.:)

> N.B. Since rwlocks don't show up the the existing lock profiling, please don't try
> to use the lock-profiling numbers to see if it's helping!
> 
> Andres, this is basically the big-hammer version of your "take a pagecount"
> changes, plus the change you made to hvmemul_rep_movs().
> If this works I intend to follow it up with a patch to make some of the
> read-modify-write paths avoid taking the lock (by using a compare-exchange
> operation so they only take the lock on a write).  If that succeeds I might drop
> put_gfn() altogether.
> 
> But first it will need a lot of tidying up.  Noticeably missing:
>  - SVM code equivalents to the vmx.c changes
>  - grant-table operations still use the lock, because frankly I
>    could not follow the current code, and it's quite late in the evening.
> I also have a long list of uglinesses in the mm code that I found while writing
> this lot.
> 
> Keir, I have no objection to later replacing this with something better than an
> rwlock. :)  Or with making a NUMA-friendly rwlock implementation, since I
> really expect this to be heavily read-mostly when paging/sharing/pod are not
> enabled.
> 
> Cheers,
> 
> Tim.

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:47:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZKZ-00031q-F7; Fri, 27 Apr 2012 00:46:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SNZKY-00031j-Ai
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 00:46:38 +0000
Received: from [85.158.143.99:4487] by server-2.bemta-4.messagelabs.com id
	AD/A4-17550-D6CE99F4; Fri, 27 Apr 2012 00:46:37 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335487595!25447412!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIzNjI5\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1172 invoked from network); 27 Apr 2012 00:46:36 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 00:46:36 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 26 Apr 2012 17:46:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="93653437"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Apr 2012 17:46:34 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 26 Apr 2012 17:46:33 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 08:46:32 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoABqsUeA//9EJFA=
Date: Fri, 27 Apr 2012 00:46:32 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
In-Reply-To: <20120426212531.GH67043@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Friday, April 27, 2012 5:26 AM
> To: Zhang, Yang Z
> Cc: andres@lagarcavilla.org; Keir Fraser; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] lock in vhpet
> 
> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> > > > But actually, the first cs introduced this issue is 24770. When
> > > > win8 booting and if hpet is enabled, it will use hpet as the time
> > > > source and there have lots of hpet access and EPT violation. In
> > > > EPT violation handler, it call get_gfn_type_access to get the mfn.
> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and then the issue
> happens.
> > > > After I removed the gfn_lock, the issue goes. But in latest xen,
> > > > even I remove this lock, it still shows high cpu utilization.
> > >
> > > It would seem then that even the briefest lock-protected critical
> > > section would cause this? In the mmio case, the p2m lock taken in
> > > the hap fault handler is held during the actual lookup, and for a
> > > couple of branch instructions afterwards.
> > >
> > > In latest Xen, with lock removed for get_gfn, on which lock is time spent?
> > Still the p2m_lock.
> 
> Can you please try the attached patch?  I think you'll need this one plus the
> ones that take the locks out of the hpet code.
> 
> This patch makes the p2m lock into an rwlock and adjusts a number of the
> paths that don't update the p2m so they only take the read lock.  It's a bit
> rough but I can boot 16-way win7 guest with it.

This really a great work! Now, the win7 guest is booting very fast and never saw the BSOD again.
But the changes are so large in your patch. I think we need to do more sanity testing to avoid any regressions. After you finish all the work, I'd like to do a whole testing.:)

> N.B. Since rwlocks don't show up the the existing lock profiling, please don't try
> to use the lock-profiling numbers to see if it's helping!
> 
> Andres, this is basically the big-hammer version of your "take a pagecount"
> changes, plus the change you made to hvmemul_rep_movs().
> If this works I intend to follow it up with a patch to make some of the
> read-modify-write paths avoid taking the lock (by using a compare-exchange
> operation so they only take the lock on a write).  If that succeeds I might drop
> put_gfn() altogether.
> 
> But first it will need a lot of tidying up.  Noticeably missing:
>  - SVM code equivalents to the vmx.c changes
>  - grant-table operations still use the lock, because frankly I
>    could not follow the current code, and it's quite late in the evening.
> I also have a long list of uglinesses in the mm code that I found while writing
> this lot.
> 
> Keir, I have no objection to later replacing this with something better than an
> rwlock. :)  Or with making a NUMA-friendly rwlock implementation, since I
> really expect this to be heavily read-mostly when paging/sharing/pod are not
> enabled.
> 
> Cheers,
> 
> Tim.

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZPS-0003ED-7t; Fri, 27 Apr 2012 00:51:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNZPQ-0003E6-UP
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 00:51:41 +0000
Received: from [85.158.143.99:20962] by server-2.bemta-4.messagelabs.com id
	F6/26-17550-C9DE99F4; Fri, 27 Apr 2012 00:51:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335487898!22093771!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMTY1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMTY1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11186 invoked from network); 27 Apr 2012 00:51:38 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-7.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 00:51:38 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id A06C84B007C;
	Thu, 26 Apr 2012 17:51:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=p9sfOytCc1AmTAzggVTWW/oN4ZAin51PabYZEGp9jfFd
	yDPBE1XG56ylF73ofvFeuCJusFPo2y7TgLFjj03AhRGNUgFxFk9l2u2/QZYOW7+u
	8gGEYQcykkC1alxJWxTUo4gZKOKTT8qXEIQQ+h8q4iJQwJLB2k+icrG5Xrq2kqk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=bbOLl9JeJVLFE2Yo47mp/vTPaJ4=; b=fPC4MDW1
	LH0WLZ6kW3W/PS23VtVEf3Uoy4yN2oL3/G5/qmx2wRVL9+dfsSaqr3LygEI4FmH3
	/RLp25q7AcfSAe81SRaMI8Ocfs8Swo+mWDr53w53Onnj0hXnICz6cPuVh89hMhVp
	XlEfouq/mekQaaAYXI9xBpg0PpNwdZJzuCs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 432FA4B0062; 
	Thu, 26 Apr 2012 17:51:37 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Apr 2012 17:51:37 -0700
Message-ID: <1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
Date: Thu, 26 Apr 2012 17:51:37 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George.Dunlap@eu.citrix.com, Keir Fraser <keir@xen.org>, olaf@aepfle.de,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Tim Deegan [mailto:tim@xen.org]
>> Sent: Friday, April 27, 2012 5:26 AM
>> To: Zhang, Yang Z
>> Cc: andres@lagarcavilla.org; Keir Fraser; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] lock in vhpet
>>
>> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
>> > > > But actually, the first cs introduced this issue is 24770. When
>> > > > win8 booting and if hpet is enabled, it will use hpet as the time
>> > > > source and there have lots of hpet access and EPT violation. In
>> > > > EPT violation handler, it call get_gfn_type_access to get the mfn.
>> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and then the
>> issue
>> happens.
>> > > > After I removed the gfn_lock, the issue goes. But in latest xen,
>> > > > even I remove this lock, it still shows high cpu utilization.
>> > >
>> > > It would seem then that even the briefest lock-protected critical
>> > > section would cause this? In the mmio case, the p2m lock taken in
>> > > the hap fault handler is held during the actual lookup, and for a
>> > > couple of branch instructions afterwards.
>> > >
>> > > In latest Xen, with lock removed for get_gfn, on which lock is time
>> spent?
>> > Still the p2m_lock.
>>
>> Can you please try the attached patch?  I think you'll need this one
>> plus the
>> ones that take the locks out of the hpet code.
>>
>> This patch makes the p2m lock into an rwlock and adjusts a number of the
>> paths that don't update the p2m so they only take the read lock.  It's a
>> bit
>> rough but I can boot 16-way win7 guest with it.

That is great news.

Tim, thanks for the amazing work. I'm poring over the patch presently, and
will shoot at it with everything I've got testing-wise.

I'm taking the liberty of pulling in Olaf (paging) and George (PoD) as the
changeset affects those subsystems.

Andres

>
> This really a great work! Now, the win7 guest is booting very fast and
> never saw the BSOD again.
> But the changes are so large in your patch. I think we need to do more
> sanity testing to avoid any regressions. After you finish all the work,
> I'd like to do a whole testing.:)
>
>> N.B. Since rwlocks don't show up the the existing lock profiling, please
>> don't try
>> to use the lock-profiling numbers to see if it's helping!
>>
>> Andres, this is basically the big-hammer version of your "take a
>> pagecount"
>> changes, plus the change you made to hvmemul_rep_movs().
>> If this works I intend to follow it up with a patch to make some of the
>> read-modify-write paths avoid taking the lock (by using a
>> compare-exchange
>> operation so they only take the lock on a write).  If that succeeds I
>> might drop
>> put_gfn() altogether.
>>
>> But first it will need a lot of tidying up.  Noticeably missing:
>>  - SVM code equivalents to the vmx.c changes
>>  - grant-table operations still use the lock, because frankly I
>>    could not follow the current code, and it's quite late in the
>> evening.
>> I also have a long list of uglinesses in the mm code that I found while
>> writing
>> this lot.
>>
>> Keir, I have no objection to later replacing this with something better
>> than an
>> rwlock. :)  Or with making a NUMA-friendly rwlock implementation, since
>> I
>> really expect this to be heavily read-mostly when paging/sharing/pod are
>> not
>> enabled.
>>
>> Cheers,
>>
>> Tim.
>
> best regards
> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 00:52:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 00:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZPS-0003ED-7t; Fri, 27 Apr 2012 00:51:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNZPQ-0003E6-UP
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 00:51:41 +0000
Received: from [85.158.143.99:20962] by server-2.bemta-4.messagelabs.com id
	F6/26-17550-C9DE99F4; Fri, 27 Apr 2012 00:51:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335487898!22093771!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMTY1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMTY1\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11186 invoked from network); 27 Apr 2012 00:51:38 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-7.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 00:51:38 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id A06C84B007C;
	Thu, 26 Apr 2012 17:51:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=p9sfOytCc1AmTAzggVTWW/oN4ZAin51PabYZEGp9jfFd
	yDPBE1XG56ylF73ofvFeuCJusFPo2y7TgLFjj03AhRGNUgFxFk9l2u2/QZYOW7+u
	8gGEYQcykkC1alxJWxTUo4gZKOKTT8qXEIQQ+h8q4iJQwJLB2k+icrG5Xrq2kqk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=bbOLl9JeJVLFE2Yo47mp/vTPaJ4=; b=fPC4MDW1
	LH0WLZ6kW3W/PS23VtVEf3Uoy4yN2oL3/G5/qmx2wRVL9+dfsSaqr3LygEI4FmH3
	/RLp25q7AcfSAe81SRaMI8Ocfs8Swo+mWDr53w53Onnj0hXnICz6cPuVh89hMhVp
	XlEfouq/mekQaaAYXI9xBpg0PpNwdZJzuCs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 432FA4B0062; 
	Thu, 26 Apr 2012 17:51:37 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Apr 2012 17:51:37 -0700
Message-ID: <1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
Date: Thu, 26 Apr 2012 17:51:37 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George.Dunlap@eu.citrix.com, Keir Fraser <keir@xen.org>, olaf@aepfle.de,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> -----Original Message-----
>> From: Tim Deegan [mailto:tim@xen.org]
>> Sent: Friday, April 27, 2012 5:26 AM
>> To: Zhang, Yang Z
>> Cc: andres@lagarcavilla.org; Keir Fraser; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] lock in vhpet
>>
>> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
>> > > > But actually, the first cs introduced this issue is 24770. When
>> > > > win8 booting and if hpet is enabled, it will use hpet as the time
>> > > > source and there have lots of hpet access and EPT violation. In
>> > > > EPT violation handler, it call get_gfn_type_access to get the mfn.
>> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and then the
>> issue
>> happens.
>> > > > After I removed the gfn_lock, the issue goes. But in latest xen,
>> > > > even I remove this lock, it still shows high cpu utilization.
>> > >
>> > > It would seem then that even the briefest lock-protected critical
>> > > section would cause this? In the mmio case, the p2m lock taken in
>> > > the hap fault handler is held during the actual lookup, and for a
>> > > couple of branch instructions afterwards.
>> > >
>> > > In latest Xen, with lock removed for get_gfn, on which lock is time
>> spent?
>> > Still the p2m_lock.
>>
>> Can you please try the attached patch?  I think you'll need this one
>> plus the
>> ones that take the locks out of the hpet code.
>>
>> This patch makes the p2m lock into an rwlock and adjusts a number of the
>> paths that don't update the p2m so they only take the read lock.  It's a
>> bit
>> rough but I can boot 16-way win7 guest with it.

That is great news.

Tim, thanks for the amazing work. I'm poring over the patch presently, and
will shoot at it with everything I've got testing-wise.

I'm taking the liberty of pulling in Olaf (paging) and George (PoD) as the
changeset affects those subsystems.

Andres

>
> This really a great work! Now, the win7 guest is booting very fast and
> never saw the BSOD again.
> But the changes are so large in your patch. I think we need to do more
> sanity testing to avoid any regressions. After you finish all the work,
> I'd like to do a whole testing.:)
>
>> N.B. Since rwlocks don't show up the the existing lock profiling, please
>> don't try
>> to use the lock-profiling numbers to see if it's helping!
>>
>> Andres, this is basically the big-hammer version of your "take a
>> pagecount"
>> changes, plus the change you made to hvmemul_rep_movs().
>> If this works I intend to follow it up with a patch to make some of the
>> read-modify-write paths avoid taking the lock (by using a
>> compare-exchange
>> operation so they only take the lock on a write).  If that succeeds I
>> might drop
>> put_gfn() altogether.
>>
>> But first it will need a lot of tidying up.  Noticeably missing:
>>  - SVM code equivalents to the vmx.c changes
>>  - grant-table operations still use the lock, because frankly I
>>    could not follow the current code, and it's quite late in the
>> evening.
>> I also have a long list of uglinesses in the mm code that I found while
>> writing
>> this lot.
>>
>> Keir, I have no objection to later replacing this with something better
>> than an
>> rwlock. :)  Or with making a NUMA-friendly rwlock implementation, since
>> I
>> really expect this to be heavily read-mostly when paging/sharing/pod are
>> not
>> enabled.
>>
>> Cheers,
>>
>> Tim.
>
> best regards
> yang
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 01:06:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZda-0007E1-NI; Fri, 27 Apr 2012 01:06:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christian.limpach@gmail.com>) id 1SNZdY-0007Dw-Bz
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 01:06:16 +0000
Received: from [85.158.138.51:57852] by server-6.bemta-3.messagelabs.com id
	42/D0-05145-701F99F4; Fri, 27 Apr 2012 01:06:15 +0000
X-Env-Sender: christian.limpach@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335488773!23849476!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8778 invoked from network); 27 Apr 2012 01:06:14 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 01:06:14 -0000
Received: by qaeb19 with SMTP id b19so77347qae.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 18:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:content-transfer-encoding;
	bh=5FPzyEnbVBXMagO30D8doF4g5Z4WAGGqClPU+9jwuWc=;
	b=f97QLhgQCWvGTzrzLasXJ2deAjjL0IbL4zDAkKPRQabX0fZxtFUHqKs47FsQhDEBEO
	udO2NSpt8vb0YaPEeuDd35aWWuhjCH2WdqdwyPRzhu2DWbwXqr+XebnFmoM5TZmckZN6
	DIHq2zfNC3/Uy25ZHlgdkVg2rXQ0SCjC80lsWBGh6JW5ZMnpX45Yc+N0B5/cE9VOeD5W
	6fffg/G/4ZEKzzcWhyBNBnDiInIjwGOPypLid/vY3UduoSZ8QuyqyZKW+1BjQP6DpZNX
	Qwa7wQjtXAwPBAYMEBz+ZIQK3Nur+56uWsUkNEE3wV6FyP/QsOP1jQ05PdEEXsjw7c67
	VtzA==
MIME-Version: 1.0
Received: by 10.224.184.70 with SMTP id cj6mr7151955qab.77.1335488773043; Thu,
	26 Apr 2012 18:06:13 -0700 (PDT)
Received: by 10.229.184.11 with HTTP; Thu, 26 Apr 2012 18:06:13 -0700 (PDT)
In-Reply-To: <CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
Date: Thu, 26 Apr 2012 18:06:13 -0700
Message-ID: <CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
From: Christian Limpach <christian.limpach@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Christian.Limpach@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 5:15 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> Does this look correct now?

It addresses the issues I've pointed out, but:
- you should leave the ASSERT where it is, or is there a reason to move it?
- this is wrong:
> - =A0 =A0 =A0 =A0old_entry =3D *ept_entry;
> + =A0 =A0 =A0 =A0old_entry->epte =3D ept_entry->epte;
You should follow the code and see what uses old_entry and you'll see
that within the function old_entry->mfn is used (your diff changes the
line that uses it) and ept_free_entry also accesses mfn.
- are you sure you can move the ept_sync_domain call past the iommu code?

I made a similar change a while ago, though it is for a more specific
case, updating the ept table to "clean" the vram tracking.  My change
is:
- clear needs_sync when setting the type to logdirty for a leaf entry
         if ( !is_epte_present(ept_entry) ||
             (!target && p2mt =3D=3D p2m_ram_logdirty) )
            needs_sync =3D 0;
- only call ept_free_entry in the non-leaf case
    if ( target && is_epte_present(&old_entry) )
        ept_free_entry(p2m, &old_entry, target);
- call ept_sync_domain from hap_clean_vram_tracking

Maybe you can do something similar, for example passing in a hint
whether ept_sync_domain needs to be done or not.  In my case, the
reasoning is that all the entries changed from hap_clean_vram_tracking
are leaf entries, so ept_free_entry will never be called and thus
ept_sync_domain can be deferred.  I didn't think through/consider the
iommu case since that code is commented out in my tree.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 01:06:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZda-0007E1-NI; Fri, 27 Apr 2012 01:06:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christian.limpach@gmail.com>) id 1SNZdY-0007Dw-Bz
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 01:06:16 +0000
Received: from [85.158.138.51:57852] by server-6.bemta-3.messagelabs.com id
	42/D0-05145-701F99F4; Fri, 27 Apr 2012 01:06:15 +0000
X-Env-Sender: christian.limpach@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1335488773!23849476!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8778 invoked from network); 27 Apr 2012 01:06:14 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 01:06:14 -0000
Received: by qaeb19 with SMTP id b19so77347qae.11
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 18:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:content-transfer-encoding;
	bh=5FPzyEnbVBXMagO30D8doF4g5Z4WAGGqClPU+9jwuWc=;
	b=f97QLhgQCWvGTzrzLasXJ2deAjjL0IbL4zDAkKPRQabX0fZxtFUHqKs47FsQhDEBEO
	udO2NSpt8vb0YaPEeuDd35aWWuhjCH2WdqdwyPRzhu2DWbwXqr+XebnFmoM5TZmckZN6
	DIHq2zfNC3/Uy25ZHlgdkVg2rXQ0SCjC80lsWBGh6JW5ZMnpX45Yc+N0B5/cE9VOeD5W
	6fffg/G/4ZEKzzcWhyBNBnDiInIjwGOPypLid/vY3UduoSZ8QuyqyZKW+1BjQP6DpZNX
	Qwa7wQjtXAwPBAYMEBz+ZIQK3Nur+56uWsUkNEE3wV6FyP/QsOP1jQ05PdEEXsjw7c67
	VtzA==
MIME-Version: 1.0
Received: by 10.224.184.70 with SMTP id cj6mr7151955qab.77.1335488773043; Thu,
	26 Apr 2012 18:06:13 -0700 (PDT)
Received: by 10.229.184.11 with HTTP; Thu, 26 Apr 2012 18:06:13 -0700 (PDT)
In-Reply-To: <CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
Date: Thu, 26 Apr 2012 18:06:13 -0700
Message-ID: <CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
From: Christian Limpach <christian.limpach@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Christian.Limpach@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 5:15 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> Does this look correct now?

It addresses the issues I've pointed out, but:
- you should leave the ASSERT where it is, or is there a reason to move it?
- this is wrong:
> - =A0 =A0 =A0 =A0old_entry =3D *ept_entry;
> + =A0 =A0 =A0 =A0old_entry->epte =3D ept_entry->epte;
You should follow the code and see what uses old_entry and you'll see
that within the function old_entry->mfn is used (your diff changes the
line that uses it) and ept_free_entry also accesses mfn.
- are you sure you can move the ept_sync_domain call past the iommu code?

I made a similar change a while ago, though it is for a more specific
case, updating the ept table to "clean" the vram tracking.  My change
is:
- clear needs_sync when setting the type to logdirty for a leaf entry
         if ( !is_epte_present(ept_entry) ||
             (!target && p2mt =3D=3D p2m_ram_logdirty) )
            needs_sync =3D 0;
- only call ept_free_entry in the non-leaf case
    if ( target && is_epte_present(&old_entry) )
        ept_free_entry(p2m, &old_entry, target);
- call ept_sync_domain from hap_clean_vram_tracking

Maybe you can do something similar, for example passing in a hint
whether ept_sync_domain needs to be done or not.  In my case, the
reasoning is that all the entries changed from hap_clean_vram_tracking
are leaf entries, so ept_free_entry will never be called and thus
ept_sync_domain can be deferred.  I didn't think through/consider the
iommu case since that code is commented out in my tree.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 01:25:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZvP-0007Rj-Oh; Fri, 27 Apr 2012 01:24:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SNZvO-0007Re-56
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 01:24:42 +0000
Received: from [193.109.254.147:21260] by server-6.bemta-14.messagelabs.com id
	B9/A8-02047-955F99F4; Fri, 27 Apr 2012 01:24:41 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335489880!4091714!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyMjQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4249 invoked from network); 27 Apr 2012 01:24:40 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-5.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 01:24:40 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Apr 2012 18:24:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="135952894"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 26 Apr 2012 18:24:38 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 26 Apr 2012 18:24:38 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 09:24:36 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoABqsUeA//9EJFD//wqOgP/9iB6Q
Date: Fri, 27 Apr 2012 01:24:36 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F8A94@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
	<1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Friday, April 27, 2012 8:52 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; Keir Fraser; xen-devel@lists.xensource.com; olaf@aepfle.de;
> George.Dunlap@eu.citrix.com
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xen.org]
> >> Sent: Friday, April 27, 2012 5:26 AM
> >> To: Zhang, Yang Z
> >> Cc: andres@lagarcavilla.org; Keir Fraser;
> >> xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] lock in vhpet
> >>
> >> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> >> > > > But actually, the first cs introduced this issue is 24770. When
> >> > > > win8 booting and if hpet is enabled, it will use hpet as the
> >> > > > time source and there have lots of hpet access and EPT
> >> > > > violation. In EPT violation handler, it call get_gfn_type_access to get
> the mfn.
> >> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and then
> >> > > > the
> >> issue
> >> happens.
> >> > > > After I removed the gfn_lock, the issue goes. But in latest
> >> > > > xen, even I remove this lock, it still shows high cpu utilization.
> >> > >
> >> > > It would seem then that even the briefest lock-protected critical
> >> > > section would cause this? In the mmio case, the p2m lock taken in
> >> > > the hap fault handler is held during the actual lookup, and for a
> >> > > couple of branch instructions afterwards.
> >> > >
> >> > > In latest Xen, with lock removed for get_gfn, on which lock is
> >> > > time
> >> spent?
> >> > Still the p2m_lock.
> >>
> >> Can you please try the attached patch?  I think you'll need this one
> >> plus the ones that take the locks out of the hpet code.
> >>
> >> This patch makes the p2m lock into an rwlock and adjusts a number of
> >> the paths that don't update the p2m so they only take the read lock.
> >> It's a bit rough but I can boot 16-way win7 guest with it.
> 
> That is great news.
> 
> Tim, thanks for the amazing work. I'm poring over the patch presently, and will
> shoot at it with everything I've got testing-wise.
> 
> I'm taking the liberty of pulling in Olaf (paging) and George (PoD) as the
> changeset affects those subsystems.

But win8 guest shows BSOD with 32 VCPUs. :(
The reason of BSOD is : SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (ACPI.sys)


best regards
yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 01:25:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNZvP-0007Rj-Oh; Fri, 27 Apr 2012 01:24:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SNZvO-0007Re-56
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 01:24:42 +0000
Received: from [193.109.254.147:21260] by server-6.bemta-14.messagelabs.com id
	B9/A8-02047-955F99F4; Fri, 27 Apr 2012 01:24:41 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335489880!4091714!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyMjQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4249 invoked from network); 27 Apr 2012 01:24:40 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-5.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 01:24:40 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Apr 2012 18:24:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="135952894"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 26 Apr 2012 18:24:38 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 26 Apr 2012 18:24:38 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 09:24:36 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoABqsUeA//9EJFD//wqOgP/9iB6Q
Date: Fri, 27 Apr 2012 01:24:36 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F8A94@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
	<1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Friday, April 27, 2012 8:52 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; Keir Fraser; xen-devel@lists.xensource.com; olaf@aepfle.de;
> George.Dunlap@eu.citrix.com
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xen.org]
> >> Sent: Friday, April 27, 2012 5:26 AM
> >> To: Zhang, Yang Z
> >> Cc: andres@lagarcavilla.org; Keir Fraser;
> >> xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] lock in vhpet
> >>
> >> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> >> > > > But actually, the first cs introduced this issue is 24770. When
> >> > > > win8 booting and if hpet is enabled, it will use hpet as the
> >> > > > time source and there have lots of hpet access and EPT
> >> > > > violation. In EPT violation handler, it call get_gfn_type_access to get
> the mfn.
> >> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and then
> >> > > > the
> >> issue
> >> happens.
> >> > > > After I removed the gfn_lock, the issue goes. But in latest
> >> > > > xen, even I remove this lock, it still shows high cpu utilization.
> >> > >
> >> > > It would seem then that even the briefest lock-protected critical
> >> > > section would cause this? In the mmio case, the p2m lock taken in
> >> > > the hap fault handler is held during the actual lookup, and for a
> >> > > couple of branch instructions afterwards.
> >> > >
> >> > > In latest Xen, with lock removed for get_gfn, on which lock is
> >> > > time
> >> spent?
> >> > Still the p2m_lock.
> >>
> >> Can you please try the attached patch?  I think you'll need this one
> >> plus the ones that take the locks out of the hpet code.
> >>
> >> This patch makes the p2m lock into an rwlock and adjusts a number of
> >> the paths that don't update the p2m so they only take the read lock.
> >> It's a bit rough but I can boot 16-way win7 guest with it.
> 
> That is great news.
> 
> Tim, thanks for the amazing work. I'm poring over the patch presently, and will
> shoot at it with everything I've got testing-wise.
> 
> I'm taking the liberty of pulling in Olaf (paging) and George (PoD) as the
> changeset affects those subsystems.

But win8 guest shows BSOD with 32 VCPUs. :(
The reason of BSOD is : SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (ACPI.sys)


best regards
yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 01:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:36:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNa6k-0007b9-VM; Fri, 27 Apr 2012 01:36:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNa6j-0007b4-Of
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 01:36:26 +0000
Received: from [85.158.143.99:63468] by server-2.bemta-4.messagelabs.com id
	A4/35-17550-918F99F4; Fri, 27 Apr 2012 01:36:25 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335490582!20152415!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27975 invoked from network); 27 Apr 2012 01:36:23 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 01:36:23 -0000
Received: by lahe6 with SMTP id e6so172696lah.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=MxlKlNFGngulXGR83rRMkeDpmW9d2cE2s9SiZQFZggk=;
	b=VnDIttCg/E3ycfeWVCnaeCmu5sZWrCFGitcx3i4HbCDBhgKQKN+vIEIzD84t3r9O++
	DAv5Hymf3paBGP2e4lzDqi4IEOTRXAsSzqBAsqpCXTHzVEyFF6HRuPpqDNVsS9PMbz6c
	BkXi2I7tzh617lt1P/XLRCHvYdVAyNQreTLoI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=MxlKlNFGngulXGR83rRMkeDpmW9d2cE2s9SiZQFZggk=;
	b=Yxm3jBa0tqtvLQhZH0oQVrN/ikXFpVpZZ1lhyOpzdbtsXXCYbJ/SH4CbZis8mFYihI
	WLbAH6scFos8HtDHemV8Iji9lY5MtckFOZJYB2BVE/oZjcNxwRPVxn1jHlXDHCPsRSt5
	oZJd+dORIOHw+jwUX/Hg8HPnP/zn7huNDKMbgvrAXtBK6tzuiNOFUiLFfeT4Vs4GrhZr
	vNPZHyIhQp1piu3N4LMjLZuwu+R9900YiHryr11w7zYvka5VNgw0O5LJRlq1c8HZUk/K
	jJcwGD6e6Yv0mUbMg/5LBVAoK8Qbrt31uK1chRFwIMyp+NYTZYAbhzoVp9sZnDE5URRC
	FsPw==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr8599578lab.29.1335490581252;
	Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
X-Originating-IP: [174.234.81.129]
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
In-Reply-To: <CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
Date: Thu, 26 Apr 2012 18:36:21 -0700
Message-ID: <CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQnS5S+kN6waRKRy8tKLfGjqcWMAePy8vVZjfld1oBwCrUL6Txbdt/NZw3yDYaEcylEt6zdu
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6886508737425108488=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6886508737425108488==
Content-Type: multipart/alternative; boundary=bcaec54fbd3cb2499204be9f213b

--bcaec54fbd3cb2499204be9f213b
Content-Type: text/plain; charset=ISO-8859-1

On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.com>
wrote:
>
> On Thu, Apr 26, 2012 at 5:15 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
> > Does this look correct now?
>
> It addresses the issues I've pointed out, but:
> - you should leave the ASSERT where it is, or is there a reason to move
it?

Ok, I will move the ASSERT back to where it was.

> - this is wrong:
> > -        old_entry = *ept_entry;
> > +        old_entry->epte = ept_entry->epte;
> You should follow the code and see what uses old_entry and you'll see
> that within the function old_entry->mfn is used (your diff changes the
> line that uses it) and ept_free_entry also accesses mfn.

I will fix that.

> - are you sure you can move the ept_sync_domain call past the iommu code?
>

I was hoping Tim would give me feedback about that.

> I made a similar change a while ago, though it is for a more specific
> case, updating the ept table to "clean" the vram tracking.  My change
> is:
> - clear needs_sync when setting the type to logdirty for a leaf entry
>         if ( !is_epte_present(ept_entry) ||
>             (!target && p2mt == p2m_ram_logdirty) )
>            needs_sync = 0;
> - only call ept_free_entry in the non-leaf case
>    if ( target && is_epte_present(&old_entry) )
>        ept_free_entry(p2m, &old_entry, target);
> - call ept_sync_domain from hap_clean_vram_tracking
>
> Maybe you can do something similar, for example passing in a hint
> whether ept_sync_domain needs to be done or not.  In my case, the
> reasoning is that all the entries changed from hap_clean_vram_tracking
> are leaf entries, so ept_free_entry will never be called and thus
> ept_sync_domain can be deferred.  I didn't think through/consider the
> iommu case since that code is commented out in my tree.
>

I thought about doing that initially. But then in the bulk case I would
always have to call ept_sync_domain() to be on the safe side. But if the
iommu case forces me down that path, then I guess I have no choice.

Aravindh

--bcaec54fbd3cb2499204be9f213b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Apr 26, 2012 6:06 PM, &quot;Christian Limpach&quot; &lt;<a href=3D"mailt=
o:christian.limpach@gmail.com">christian.limpach@gmail.com</a>&gt; wrote:<b=
r>
&gt;<br>
&gt; On Thu, Apr 26, 2012 at 5:15 PM, Aravindh Puthiyaparambil<br>
&gt; &lt;<a href=3D"mailto:aravindh@virtuata.com">aravindh@virtuata.com</a>=
&gt; wrote:<br>
&gt; &gt; Does this look correct now?<br>
&gt;<br>
&gt; It addresses the issues I&#39;ve pointed out, but:<br>
&gt; - you should leave the ASSERT where it is, or is there a reason to mov=
e it?</p>
<p>Ok, I will move the ASSERT back to where it was.</p>
<p>&gt; - this is wrong:<br>
&gt; &gt; - =A0 =A0 =A0 =A0old_entry =3D *ept_entry;<br>
&gt; &gt; + =A0 =A0 =A0 =A0old_entry-&gt;epte =3D ept_entry-&gt;epte;<br>
&gt; You should follow the code and see what uses old_entry and you&#39;ll =
see<br>
&gt; that within the function old_entry-&gt;mfn is used (your diff changes =
the<br>
&gt; line that uses it) and ept_free_entry also accesses mfn.</p>
<p>I will fix that.</p>
<p>&gt; - are you sure you can move the ept_sync_domain call past the iommu=
 code?<br>
&gt;</p>
<p>I was hoping Tim would give me feedback about that.</p>
<p>&gt; I made a similar change a while ago, though it is for a more specif=
ic<br>
&gt; case, updating the ept table to &quot;clean&quot; the vram tracking. =
=A0My change<br>
&gt; is:<br>
&gt; - clear needs_sync when setting the type to logdirty for a leaf entry<=
br>
&gt; =A0 =A0 =A0 =A0 if ( !is_epte_present(ept_entry) ||<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 (!target &amp;&amp; p2mt =3D=3D p2m_ram_logdir=
ty) )<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0needs_sync =3D 0;<br>
&gt; - only call ept_free_entry in the non-leaf case<br>
&gt; =A0 =A0if ( target &amp;&amp; is_epte_present(&amp;old_entry) )<br>
&gt; =A0 =A0 =A0 =A0ept_free_entry(p2m, &amp;old_entry, target);<br>
&gt; - call ept_sync_domain from hap_clean_vram_tracking<br>
&gt;<br>
&gt; Maybe you can do something similar, for example passing in a hint<br>
&gt; whether ept_sync_domain needs to be done or not. =A0In my case, the<br=
>
&gt; reasoning is that all the entries changed from hap_clean_vram_tracking=
<br>
&gt; are leaf entries, so ept_free_entry will never be called and thus<br>
&gt; ept_sync_domain can be deferred. =A0I didn&#39;t think through/conside=
r the<br>
&gt; iommu case since that code is commented out in my tree.<br>
&gt;</p>
<p>I thought about doing that initially. But then in the bulk case I would =
always have to call ept_sync_domain() to be on the safe side. But if the io=
mmu case forces me down that path, then I guess I have no choice.</p>
<p>Aravindh</p>

--bcaec54fbd3cb2499204be9f213b--


--===============6886508737425108488==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6886508737425108488==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 01:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:36:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNa6k-0007b9-VM; Fri, 27 Apr 2012 01:36:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNa6j-0007b4-Of
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 01:36:26 +0000
Received: from [85.158.143.99:63468] by server-2.bemta-4.messagelabs.com id
	A4/35-17550-918F99F4; Fri, 27 Apr 2012 01:36:25 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335490582!20152415!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27975 invoked from network); 27 Apr 2012 01:36:23 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 01:36:23 -0000
Received: by lahe6 with SMTP id e6so172696lah.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=MxlKlNFGngulXGR83rRMkeDpmW9d2cE2s9SiZQFZggk=;
	b=VnDIttCg/E3ycfeWVCnaeCmu5sZWrCFGitcx3i4HbCDBhgKQKN+vIEIzD84t3r9O++
	DAv5Hymf3paBGP2e4lzDqi4IEOTRXAsSzqBAsqpCXTHzVEyFF6HRuPpqDNVsS9PMbz6c
	BkXi2I7tzh617lt1P/XLRCHvYdVAyNQreTLoI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=MxlKlNFGngulXGR83rRMkeDpmW9d2cE2s9SiZQFZggk=;
	b=Yxm3jBa0tqtvLQhZH0oQVrN/ikXFpVpZZ1lhyOpzdbtsXXCYbJ/SH4CbZis8mFYihI
	WLbAH6scFos8HtDHemV8Iji9lY5MtckFOZJYB2BVE/oZjcNxwRPVxn1jHlXDHCPsRSt5
	oZJd+dORIOHw+jwUX/Hg8HPnP/zn7huNDKMbgvrAXtBK6tzuiNOFUiLFfeT4Vs4GrhZr
	vNPZHyIhQp1piu3N4LMjLZuwu+R9900YiHryr11w7zYvka5VNgw0O5LJRlq1c8HZUk/K
	jJcwGD6e6Yv0mUbMg/5LBVAoK8Qbrt31uK1chRFwIMyp+NYTZYAbhzoVp9sZnDE5URRC
	FsPw==
MIME-Version: 1.0
Received: by 10.152.108.171 with SMTP id hl11mr8599578lab.29.1335490581252;
	Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
X-Originating-IP: [174.234.81.129]
Received: by 10.112.47.100 with HTTP; Thu, 26 Apr 2012 18:36:21 -0700 (PDT)
In-Reply-To: <CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
Date: Thu, 26 Apr 2012 18:36:21 -0700
Message-ID: <CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQnS5S+kN6waRKRy8tKLfGjqcWMAePy8vVZjfld1oBwCrUL6Txbdt/NZw3yDYaEcylEt6zdu
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6886508737425108488=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6886508737425108488==
Content-Type: multipart/alternative; boundary=bcaec54fbd3cb2499204be9f213b

--bcaec54fbd3cb2499204be9f213b
Content-Type: text/plain; charset=ISO-8859-1

On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.com>
wrote:
>
> On Thu, Apr 26, 2012 at 5:15 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
> > Does this look correct now?
>
> It addresses the issues I've pointed out, but:
> - you should leave the ASSERT where it is, or is there a reason to move
it?

Ok, I will move the ASSERT back to where it was.

> - this is wrong:
> > -        old_entry = *ept_entry;
> > +        old_entry->epte = ept_entry->epte;
> You should follow the code and see what uses old_entry and you'll see
> that within the function old_entry->mfn is used (your diff changes the
> line that uses it) and ept_free_entry also accesses mfn.

I will fix that.

> - are you sure you can move the ept_sync_domain call past the iommu code?
>

I was hoping Tim would give me feedback about that.

> I made a similar change a while ago, though it is for a more specific
> case, updating the ept table to "clean" the vram tracking.  My change
> is:
> - clear needs_sync when setting the type to logdirty for a leaf entry
>         if ( !is_epte_present(ept_entry) ||
>             (!target && p2mt == p2m_ram_logdirty) )
>            needs_sync = 0;
> - only call ept_free_entry in the non-leaf case
>    if ( target && is_epte_present(&old_entry) )
>        ept_free_entry(p2m, &old_entry, target);
> - call ept_sync_domain from hap_clean_vram_tracking
>
> Maybe you can do something similar, for example passing in a hint
> whether ept_sync_domain needs to be done or not.  In my case, the
> reasoning is that all the entries changed from hap_clean_vram_tracking
> are leaf entries, so ept_free_entry will never be called and thus
> ept_sync_domain can be deferred.  I didn't think through/consider the
> iommu case since that code is commented out in my tree.
>

I thought about doing that initially. But then in the bulk case I would
always have to call ept_sync_domain() to be on the safe side. But if the
iommu case forces me down that path, then I guess I have no choice.

Aravindh

--bcaec54fbd3cb2499204be9f213b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Apr 26, 2012 6:06 PM, &quot;Christian Limpach&quot; &lt;<a href=3D"mailt=
o:christian.limpach@gmail.com">christian.limpach@gmail.com</a>&gt; wrote:<b=
r>
&gt;<br>
&gt; On Thu, Apr 26, 2012 at 5:15 PM, Aravindh Puthiyaparambil<br>
&gt; &lt;<a href=3D"mailto:aravindh@virtuata.com">aravindh@virtuata.com</a>=
&gt; wrote:<br>
&gt; &gt; Does this look correct now?<br>
&gt;<br>
&gt; It addresses the issues I&#39;ve pointed out, but:<br>
&gt; - you should leave the ASSERT where it is, or is there a reason to mov=
e it?</p>
<p>Ok, I will move the ASSERT back to where it was.</p>
<p>&gt; - this is wrong:<br>
&gt; &gt; - =A0 =A0 =A0 =A0old_entry =3D *ept_entry;<br>
&gt; &gt; + =A0 =A0 =A0 =A0old_entry-&gt;epte =3D ept_entry-&gt;epte;<br>
&gt; You should follow the code and see what uses old_entry and you&#39;ll =
see<br>
&gt; that within the function old_entry-&gt;mfn is used (your diff changes =
the<br>
&gt; line that uses it) and ept_free_entry also accesses mfn.</p>
<p>I will fix that.</p>
<p>&gt; - are you sure you can move the ept_sync_domain call past the iommu=
 code?<br>
&gt;</p>
<p>I was hoping Tim would give me feedback about that.</p>
<p>&gt; I made a similar change a while ago, though it is for a more specif=
ic<br>
&gt; case, updating the ept table to &quot;clean&quot; the vram tracking. =
=A0My change<br>
&gt; is:<br>
&gt; - clear needs_sync when setting the type to logdirty for a leaf entry<=
br>
&gt; =A0 =A0 =A0 =A0 if ( !is_epte_present(ept_entry) ||<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 (!target &amp;&amp; p2mt =3D=3D p2m_ram_logdir=
ty) )<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0needs_sync =3D 0;<br>
&gt; - only call ept_free_entry in the non-leaf case<br>
&gt; =A0 =A0if ( target &amp;&amp; is_epte_present(&amp;old_entry) )<br>
&gt; =A0 =A0 =A0 =A0ept_free_entry(p2m, &amp;old_entry, target);<br>
&gt; - call ept_sync_domain from hap_clean_vram_tracking<br>
&gt;<br>
&gt; Maybe you can do something similar, for example passing in a hint<br>
&gt; whether ept_sync_domain needs to be done or not. =A0In my case, the<br=
>
&gt; reasoning is that all the entries changed from hap_clean_vram_tracking=
<br>
&gt; are leaf entries, so ept_free_entry will never be called and thus<br>
&gt; ept_sync_domain can be deferred. =A0I didn&#39;t think through/conside=
r the<br>
&gt; iommu case since that code is commented out in my tree.<br>
&gt;</p>
<p>I thought about doing that initially. But then in the bulk case I would =
always have to call ept_sync_domain() to be on the safe side. But if the io=
mmu case forces me down that path, then I guess I have no choice.</p>
<p>Aravindh</p>

--bcaec54fbd3cb2499204be9f213b--


--===============6886508737425108488==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6886508737425108488==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 01:56:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNaQB-0007mx-Q4; Fri, 27 Apr 2012 01:56:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNaQ9-0007ms-OH
	for Xen-devel@lists.xensource.com; Fri, 27 Apr 2012 01:56:29 +0000
Received: from [193.109.254.147:29496] by server-1.bemta-14.messagelabs.com id
	0E/5D-29372-DCCF99F4; Fri, 27 Apr 2012 01:56:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335491786!6534744!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODA3NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18389 invoked from network); 27 Apr 2012 01:56:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 01:56:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R1uJbT005105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 01:56:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3R1uIEc023688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Apr 2012 01:56:18 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3R1uIhT006993; Thu, 26 Apr 2012 20:56:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 18:56:17 -0700
Date: Thu, 26 Apr 2012 18:56:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120426185605.48f27816@mantra.us.oracle.com>
In-Reply-To: <20120426195712.GG67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
	<20120426111848.34e43e75@mantra.us.oracle.com>
	<20120426195712.GG67043@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012 20:57:12 +0100
Tim Deegan <tim@xen.org> wrote:

> At 11:18 -0700 on 26 Apr (1335439128), Mukesh Rathor wrote:
> > On Thu, 26 Apr 2012 10:08:47 +0100
> 
> Oh, I see.  This is the domU's L4.  In that case I suspect that what's
> missing is the translation from GFNs to MFNs in the domU. 
> 
> To do that, we may finally have to reintroduce the dreaded 'tell me
> what MFN backs this domU GFN' call, so the dom0 tools can build proper
> pagetables and p2m for the pv domU.  Or have you already taken care of
> that?


The tools get an array of the PV domU mfn's. Next to build pagetables, it
needs to map them. It does via privcmd. I generate needed pfn space (not
virtual address space) via ballooning. Next I need to map each pfn to 
the domU mfns. This is a pv guest being built. So, these are mfns' that
don't need looking up. This mapping is temporary, while the guest is being 
built. For building a hybrid domU, it doesn't need to pin the L4 as the 
hybrid guest doesn't use PV MMU. So, these mfn's that are mapped just 
need temporary page count. 

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 01:56:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 01:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNaQB-0007mx-Q4; Fri, 27 Apr 2012 01:56:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNaQ9-0007ms-OH
	for Xen-devel@lists.xensource.com; Fri, 27 Apr 2012 01:56:29 +0000
Received: from [193.109.254.147:29496] by server-1.bemta-14.messagelabs.com id
	0E/5D-29372-DCCF99F4; Fri, 27 Apr 2012 01:56:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335491786!6534744!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODA3NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18389 invoked from network); 27 Apr 2012 01:56:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 01:56:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R1uJbT005105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 01:56:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3R1uIEc023688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Apr 2012 01:56:18 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3R1uIhT006993; Thu, 26 Apr 2012 20:56:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 18:56:17 -0700
Date: Thu, 26 Apr 2012 18:56:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120426185605.48f27816@mantra.us.oracle.com>
In-Reply-To: <20120426195712.GG67043@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
	<20120426111848.34e43e75@mantra.us.oracle.com>
	<20120426195712.GG67043@ocelot.phlegethon.org>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
 foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012 20:57:12 +0100
Tim Deegan <tim@xen.org> wrote:

> At 11:18 -0700 on 26 Apr (1335439128), Mukesh Rathor wrote:
> > On Thu, 26 Apr 2012 10:08:47 +0100
> 
> Oh, I see.  This is the domU's L4.  In that case I suspect that what's
> missing is the translation from GFNs to MFNs in the domU. 
> 
> To do that, we may finally have to reintroduce the dreaded 'tell me
> what MFN backs this domU GFN' call, so the dom0 tools can build proper
> pagetables and p2m for the pv domU.  Or have you already taken care of
> that?


The tools get an array of the PV domU mfn's. Next to build pagetables, it
needs to map them. It does via privcmd. I generate needed pfn space (not
virtual address space) via ballooning. Next I need to map each pfn to 
the domU mfns. This is a pv guest being built. So, these are mfns' that
don't need looking up. This mapping is temporary, while the guest is being 
built. For building a hybrid domU, it doesn't need to pin the L4 as the 
hybrid guest doesn't use PV MMU. So, these mfn's that are mapped just 
need temporary page count. 

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 02:25:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 02:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNars-0008KW-9d; Fri, 27 Apr 2012 02:25:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SNarr-0008KR-9B
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 02:25:07 +0000
Received: from [85.158.143.35:16838] by server-2.bemta-4.messagelabs.com id
	95/E6-17550-2830A9F4; Fri, 27 Apr 2012 02:25:06 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335493504!6754540!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyMjQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16477 invoked from network); 27 Apr 2012 02:25:05 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-21.messagelabs.com with SMTP;
	27 Apr 2012 02:25:05 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Apr 2012 19:25:03 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="135969334"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 26 Apr 2012 19:25:03 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 26 Apr 2012 19:25:02 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.253]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 10:24:46 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
Thread-Index: AQHNIq/V54kBi/eM90qyGlGwzH8c4Zat6ukQ
Date: Fri, 27 Apr 2012 02:24:46 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD9079D@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
	<4F96690D020000780007F810@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
	<4F97BB12020000780007FDB2@nat28.tlf.novell.com>
In-Reply-To: <4F97BB12020000780007FDB2@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> > Qemu only emulate the device which is assigned to guest, but it does not
> > emulate the physic device's whole bus path. Seems allowing guest request
> > enabling looks reasonable, but I think it's only applicable for "per device
> > feature(that unnecessary to enable the whole pci path)".
> 
> No - if the guest asks the host to call pci_enable_ltr(), it'll imply enabling
> for the entire path (as that's what the call results in). Which imo is better
> than enabling a feature upfront, just in case.
> 

For purpose of guest asking the host to call pci_enable_ltr(), there are two probable ways:
a. According to PCIE spec, "software must not enable LTR in an Endpoint unless the Root Complex and all intermediate Switches indicate support for LTR". That means Qemu has to emulate the entire path of platform, so that guest can detect whether endpoint device can be enabled firstly.
b. using pv guest mode, let the host call pci_enable_ltr().

Obviously, the two ways are not very good for this case. For the first way, we can emulate the entire path when qemu support PCIE emulation. But currently it's better to enable ltr/obff in pciback driver.

Thanks,
-Xudong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 02:25:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 02:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNars-0008KW-9d; Fri, 27 Apr 2012 02:25:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SNarr-0008KR-9B
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 02:25:07 +0000
Received: from [85.158.143.35:16838] by server-2.bemta-4.messagelabs.com id
	95/E6-17550-2830A9F4; Fri, 27 Apr 2012 02:25:06 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1335493504!6754540!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyMjQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16477 invoked from network); 27 Apr 2012 02:25:05 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-21.messagelabs.com with SMTP;
	27 Apr 2012 02:25:05 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Apr 2012 19:25:03 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="135969334"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 26 Apr 2012 19:25:03 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 26 Apr 2012 19:25:02 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.253]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 10:24:46 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
	pciback
Thread-Index: AQHNIq/V54kBi/eM90qyGlGwzH8c4Zat6ukQ
Date: Fri, 27 Apr 2012 02:24:46 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FD9079D@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FD2997D@SHSMSX101.ccr.corp.intel.com>
	<4F9525E4020000780007F350@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3ABAA@SHSMSX101.ccr.corp.intel.com>
	<4F96690D020000780007F810@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FD3D58C@SHSMSX101.ccr.corp.intel.com>
	<4F97BB12020000780007FDB2@nat28.tlf.novell.com>
In-Reply-To: <4F97BB12020000780007FDB2@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
 pciback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> > Qemu only emulate the device which is assigned to guest, but it does not
> > emulate the physic device's whole bus path. Seems allowing guest request
> > enabling looks reasonable, but I think it's only applicable for "per device
> > feature(that unnecessary to enable the whole pci path)".
> 
> No - if the guest asks the host to call pci_enable_ltr(), it'll imply enabling
> for the entire path (as that's what the call results in). Which imo is better
> than enabling a feature upfront, just in case.
> 

For purpose of guest asking the host to call pci_enable_ltr(), there are two probable ways:
a. According to PCIE spec, "software must not enable LTR in an Endpoint unless the Root Complex and all intermediate Switches indicate support for LTR". That means Qemu has to emulate the entire path of platform, so that guest can detect whether endpoint device can be enabled firstly.
b. using pv guest mode, let the host call pci_enable_ltr().

Obviously, the two ways are not very good for this case. For the first way, we can emulate the entire path when qemu support PCIE emulation. But currently it's better to enable ltr/obff in pciback driver.

Thanks,
-Xudong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 02:40:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 02:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNb6a-0008Vx-PV; Fri, 27 Apr 2012 02:40:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNb6Z-0008Vs-4p
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 02:40:19 +0000
Received: from [193.109.254.147:35045] by server-10.bemta-14.messagelabs.com
	id B7/62-05847-1170A9F4; Fri, 27 Apr 2012 02:40:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335494415!4090580!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTQ3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 27 Apr 2012 02:40:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 02:40:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R2eD9h029388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 02:40:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3R2eDQT004780
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 02:40:13 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3R2eDUp026703
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 21:40:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 19:40:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B28FF402FB; Thu, 26 Apr 2012 22:34:39 -0400 (EDT)
Date: Thu, 26 Apr 2012 22:34:39 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20120427023439.GB26931@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for domain
 0: 694017 > 694016
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I am not sure how this is happening, but I can only reproduce this
is I use the "max" parameter in the 'dom0_mem=*:max:*' combination:

sh-4.1# xl info | grep dom0_mem
xen_commandline        : cpuinfo dom0_mem=1G,max:2711M cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=


02:32:22 # 19 :/sys/devices/system/xen_memory/xen_memory0/ 
> cat /proc/meminfo |grep Direct
DirectMap4k:     2776516 kB
DirectMap2M:           0 kB

02:33:11 # 23 :/sys/devices/system/xen_memory/xen_memory0/
> echo 2776516 > target_kb

(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (239 of 256)
(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)
(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)

>
The value that it decided it was Ok with was: 2776510kB which is 6 pages short
of the goal and that makes the messages disappear.

Any ideas of what that might be? Could it be the shared_info, hypercall page,
start_info, xenconsole and some other ones are the magic 6 pages which
inhibit how much we can balloon up to?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 02:40:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 02:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNb6a-0008Vx-PV; Fri, 27 Apr 2012 02:40:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNb6Z-0008Vs-4p
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 02:40:19 +0000
Received: from [193.109.254.147:35045] by server-10.bemta-14.messagelabs.com
	id B7/62-05847-1170A9F4; Fri, 27 Apr 2012 02:40:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335494415!4090580!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTQ3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 27 Apr 2012 02:40:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 02:40:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R2eD9h029388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 02:40:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3R2eDQT004780
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 02:40:13 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3R2eDUp026703
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 21:40:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 19:40:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B28FF402FB; Thu, 26 Apr 2012 22:34:39 -0400 (EDT)
Date: Thu, 26 Apr 2012 22:34:39 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20120427023439.GB26931@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for domain
 0: 694017 > 694016
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I am not sure how this is happening, but I can only reproduce this
is I use the "max" parameter in the 'dom0_mem=*:max:*' combination:

sh-4.1# xl info | grep dom0_mem
xen_commandline        : cpuinfo dom0_mem=1G,max:2711M cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=


02:32:22 # 19 :/sys/devices/system/xen_memory/xen_memory0/ 
> cat /proc/meminfo |grep Direct
DirectMap4k:     2776516 kB
DirectMap2M:           0 kB

02:33:11 # 23 :/sys/devices/system/xen_memory/xen_memory0/
> echo 2776516 > target_kb

(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (239 of 256)
(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)
(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)

>
The value that it decided it was Ok with was: 2776510kB which is 6 pages short
of the goal and that makes the messages disappear.

Any ideas of what that might be? Could it be the shared_info, hypercall page,
start_info, xenconsole and some other ones are the magic 6 pages which
inhibit how much we can balloon up to?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 03:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 03:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNbS4-0000Gq-Oi; Fri, 27 Apr 2012 03:02:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNbS2-0000Gl-O1
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 03:02:31 +0000
Received: from [85.158.139.83:34080] by server-8.bemta-5.messagelabs.com id
	3B/7F-26964-54C0A9F4; Fri, 27 Apr 2012 03:02:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335495748!25031524!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjI5MTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22477 invoked from network); 27 Apr 2012 03:02:29 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-182.messagelabs.com with SMTP;
	27 Apr 2012 03:02:29 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 988567EC065;
	Thu, 26 Apr 2012 20:02:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DLO7k1K1zee0mHUlF24e+5GkXLkgXV4H8/DfgDxWGKlh
	aeisfFcfewLWSe2cMYRXIDbhn5VIHno/XglDtkouVRlVwj78FzKY7BQmBpAiozGC
	rgSm/hKEJuy+0gfGfcLN0nKYlQbazYgn0bhAf9PKSIEO5rgLxl1gJrl0McsMErg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=GlIINmx+5L0BEz58oTOtX0eUW9s=; b=dq+mLFFa
	PyV0PR+o8f39NY3Q5BNM65ekKBpOxKXTv0YGYICrxgXCWMgHT226/Nh0qe+ioOBa
	R0CNcukP1MhAlhV/ypVi7OEb1SKHw57vKDYBNwLq7gqGaU6dxww9HjobOwEtuhlY
	Sow4yP8J5i1C1w9DlMy8hxig5U2Dg6WJ6jY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 59F087EC063; 
	Thu, 26 Apr 2012 20:02:27 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Apr 2012 20:02:27 -0700
Message-ID: <23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120426212531.GH67043@ocelot.phlegethon.org>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
Date: Thu, 26 Apr 2012 20:02:27 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
>> > > But actually, the first cs introduced this issue is 24770. When win8
>> > > booting and if hpet is enabled, it will use hpet as the time source
>> > > and there have lots of hpet access and EPT violation. In EPT
>> violation
>> > > handler, it call get_gfn_type_access to get the mfn. The cs 24770
>> > > introduces the gfn_lock for p2m lookups, and then the issue happens.
>> > > After I removed the gfn_lock, the issue goes. But in latest xen,
>> even
>> > > I remove this lock, it still shows high cpu utilization.
>> >
>> > It would seem then that even the briefest lock-protected critical
>> section would
>> > cause this? In the mmio case, the p2m lock taken in the hap fault
>> handler is
>> > held during the actual lookup, and for a couple of branch instructions
>> > afterwards.
>> >
>> > In latest Xen, with lock removed for get_gfn, on which lock is time
>> spent?
>> Still the p2m_lock.
>
> Can you please try the attached patch?  I think you'll need this one
> plus the ones that take the locks out of the hpet code.

Right off the bat I'm getting a multitude of
(XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
And a hung dom0 during initramfs. I'm a little baffled as to why, but it's
there (32 bit dom0, XenServer6).

>
> This patch makes the p2m lock into an rwlock and adjusts a number of the
> paths that don't update the p2m so they only take the read lock.  It's a
> bit rough but I can boot 16-way win7 guest with it.
>
> N.B. Since rwlocks don't show up the the existing lock profiling, please
> don't try to use the lock-profiling numbers to see if it's helping!
>
> Andres, this is basically the big-hammer version of your "take a
> pagecount" changes, plus the change you made to hvmemul_rep_movs().
> If this works I intend to follow it up with a patch to make some of the
> read-modify-write paths avoid taking the lock (by using a
> compare-exchange operation so they only take the lock on a write).  If
> that succeeds I might drop put_gfn() altogether.

You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
There are code paths that do get_gfn_query -> p2m_change_type -> put_gfn.
But I guess those could lock the p2m up-front if they become the only
consumers of put_gfn left.

>
> But first it will need a lot of tidying up.  Noticeably missing:
>  - SVM code equivalents to the vmx.c changes

load_pdptrs doesn't exist on svm. There are a couple of debugging
get_gfn_query that can be made unlocked. And svm_vmcb_restore needs
similar treatment to what you did in vmx.c. The question is who will be
able to test it...

>  - grant-table operations still use the lock, because frankly I
>    could not follow the current code, and it's quite late in the evening.

It's pretty complex with serious nesting, and ifdef's for arm and 32 bit.
gfn_to_mfn_private callers will suffer from altering the current meaning,
as put_gfn resolves to the right thing for the ifdef'ed arch. The other
user is grant_transfer which also relies on the page *not* having an extra
ref in steal_page. So it's a prime candidate to be left alone.

> I also have a long list of uglinesses in the mm code that I found

Uh, ugly stuff, how could that have happened?

I have a few preliminary observations on the patch. Pasting relevant bits
here, since the body of the patch seems to have been lost by the email
thread:

@@ -977,23 +976,25 @@ int arch_set_info_guest(
...
+
+        if (!paging_mode_refcounts(d)
+            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
replace with && !get_page_type() )

@@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
             gfn = addr >> PAGE_SHIFT;
         }

-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
same logic when checking p2m_is_shared). Not truly related to your patch
bit since we're at it.

Same, further down
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
Last two lines are redundant

@@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
    case HVMOP_modified_memory: a lot of error checking has been removed.
At the very least:
if ( page )
{ ...
} else {
    rc = -EINVAL;
    goto param_fail3;
}

arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing checking
for target gfns of mmu updates of l2/3/4 entries. It seems that this
wouldn't work anyways, that's why you killed it?

+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
...
+    if ( !top_page )
     {
         pfec[0] &= ~PFEC_page_present;
-        __put_gfn(p2m, top_gfn);
+        put_page(top_page);
top_page is NULL here, remove put_page

get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
locking is already done by get_gfn_type_access/__put_gfn

(hope those observations made sense without inlining them in the actual
patch)

Andres




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 03:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 03:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNbS4-0000Gq-Oi; Fri, 27 Apr 2012 03:02:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNbS2-0000Gl-O1
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 03:02:31 +0000
Received: from [85.158.139.83:34080] by server-8.bemta-5.messagelabs.com id
	3B/7F-26964-54C0A9F4; Fri, 27 Apr 2012 03:02:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335495748!25031524!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjI5MTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22477 invoked from network); 27 Apr 2012 03:02:29 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-182.messagelabs.com with SMTP;
	27 Apr 2012 03:02:29 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 988567EC065;
	Thu, 26 Apr 2012 20:02:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DLO7k1K1zee0mHUlF24e+5GkXLkgXV4H8/DfgDxWGKlh
	aeisfFcfewLWSe2cMYRXIDbhn5VIHno/XglDtkouVRlVwj78FzKY7BQmBpAiozGC
	rgSm/hKEJuy+0gfGfcLN0nKYlQbazYgn0bhAf9PKSIEO5rgLxl1gJrl0McsMErg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=GlIINmx+5L0BEz58oTOtX0eUW9s=; b=dq+mLFFa
	PyV0PR+o8f39NY3Q5BNM65ekKBpOxKXTv0YGYICrxgXCWMgHT226/Nh0qe+ioOBa
	R0CNcukP1MhAlhV/ypVi7OEb1SKHw57vKDYBNwLq7gqGaU6dxww9HjobOwEtuhlY
	Sow4yP8J5i1C1w9DlMy8hxig5U2Dg6WJ6jY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 59F087EC063; 
	Thu, 26 Apr 2012 20:02:27 -0700 (PDT)
Received: from 184.175.4.22 (proxying for 184.175.4.22)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Apr 2012 20:02:27 -0700
Message-ID: <23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120426212531.GH67043@ocelot.phlegethon.org>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
Date: Thu, 26 Apr 2012 20:02:27 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
>> > > But actually, the first cs introduced this issue is 24770. When win8
>> > > booting and if hpet is enabled, it will use hpet as the time source
>> > > and there have lots of hpet access and EPT violation. In EPT
>> violation
>> > > handler, it call get_gfn_type_access to get the mfn. The cs 24770
>> > > introduces the gfn_lock for p2m lookups, and then the issue happens.
>> > > After I removed the gfn_lock, the issue goes. But in latest xen,
>> even
>> > > I remove this lock, it still shows high cpu utilization.
>> >
>> > It would seem then that even the briefest lock-protected critical
>> section would
>> > cause this? In the mmio case, the p2m lock taken in the hap fault
>> handler is
>> > held during the actual lookup, and for a couple of branch instructions
>> > afterwards.
>> >
>> > In latest Xen, with lock removed for get_gfn, on which lock is time
>> spent?
>> Still the p2m_lock.
>
> Can you please try the attached patch?  I think you'll need this one
> plus the ones that take the locks out of the hpet code.

Right off the bat I'm getting a multitude of
(XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
And a hung dom0 during initramfs. I'm a little baffled as to why, but it's
there (32 bit dom0, XenServer6).

>
> This patch makes the p2m lock into an rwlock and adjusts a number of the
> paths that don't update the p2m so they only take the read lock.  It's a
> bit rough but I can boot 16-way win7 guest with it.
>
> N.B. Since rwlocks don't show up the the existing lock profiling, please
> don't try to use the lock-profiling numbers to see if it's helping!
>
> Andres, this is basically the big-hammer version of your "take a
> pagecount" changes, plus the change you made to hvmemul_rep_movs().
> If this works I intend to follow it up with a patch to make some of the
> read-modify-write paths avoid taking the lock (by using a
> compare-exchange operation so they only take the lock on a write).  If
> that succeeds I might drop put_gfn() altogether.

You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
There are code paths that do get_gfn_query -> p2m_change_type -> put_gfn.
But I guess those could lock the p2m up-front if they become the only
consumers of put_gfn left.

>
> But first it will need a lot of tidying up.  Noticeably missing:
>  - SVM code equivalents to the vmx.c changes

load_pdptrs doesn't exist on svm. There are a couple of debugging
get_gfn_query that can be made unlocked. And svm_vmcb_restore needs
similar treatment to what you did in vmx.c. The question is who will be
able to test it...

>  - grant-table operations still use the lock, because frankly I
>    could not follow the current code, and it's quite late in the evening.

It's pretty complex with serious nesting, and ifdef's for arm and 32 bit.
gfn_to_mfn_private callers will suffer from altering the current meaning,
as put_gfn resolves to the right thing for the ifdef'ed arch. The other
user is grant_transfer which also relies on the page *not* having an extra
ref in steal_page. So it's a prime candidate to be left alone.

> I also have a long list of uglinesses in the mm code that I found

Uh, ugly stuff, how could that have happened?

I have a few preliminary observations on the patch. Pasting relevant bits
here, since the body of the patch seems to have been lost by the email
thread:

@@ -977,23 +976,25 @@ int arch_set_info_guest(
...
+
+        if (!paging_mode_refcounts(d)
+            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
replace with && !get_page_type() )

@@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
             gfn = addr >> PAGE_SHIFT;
         }

-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
same logic when checking p2m_is_shared). Not truly related to your patch
bit since we're at it.

Same, further down
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
Last two lines are redundant

@@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
    case HVMOP_modified_memory: a lot of error checking has been removed.
At the very least:
if ( page )
{ ...
} else {
    rc = -EINVAL;
    goto param_fail3;
}

arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing checking
for target gfns of mmu updates of l2/3/4 entries. It seems that this
wouldn't work anyways, that's why you killed it?

+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
...
+    if ( !top_page )
     {
         pfec[0] &= ~PFEC_page_present;
-        __put_gfn(p2m, top_gfn);
+        put_page(top_page);
top_page is NULL here, remove put_page

get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
locking is already done by get_gfn_type_access/__put_gfn

(hope those observations made sense without inlining them in the actual
patch)

Andres




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 03:10:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 03:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNbZN-0000Tk-Ta; Fri, 27 Apr 2012 03:10:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNbZN-0000Tf-3F
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 03:10:05 +0000
Received: from [85.158.143.99:6717] by server-2.bemta-4.messagelabs.com id
	8A/05-17550-C0E0A9F4; Fri, 27 Apr 2012 03:10:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335496202!18436121!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11845 invoked from network); 27 Apr 2012 03:10:03 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 03:10:03 -0000
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227])
	by acsinet14.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R2Ubiw015024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 02:30:37 GMT
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R2UVGS025947
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 02:30:32 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3R2UUVj024617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Apr 2012 02:30:31 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3R2UU6j022301; Thu, 26 Apr 2012 21:30:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 19:30:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 51325402FB; Thu, 26 Apr 2012 22:24:56 -0400 (EDT)
Date: Thu, 26 Apr 2012 22:24:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120427022456.GA26931@phenom.dumpdata.com>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
	<1334949673-25632-2-git-send-email-msw@amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334949673-25632-2-git-send-email-msw@amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
Cc: Joe Jin <joe.jin@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in
 statistics sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 07:21:13PM +0000, Matt Wilson wrote:
> This is a port of a patch in the XenoLinux 2.6.18 tree:
> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56
> 
> Fix blkback sysfs race

So with this patch I keep on getting this:

[  128.274290] switch: port 2(vif1.0) entered disabled state
[  128.855442] BUG: sleeping function called from invalid context at /home/konrad/ssd/linux/kernel/mutex.c:85
[  128.855628] in_atomic(): 1, irqs_disabled(): 0, pid: 46, name: xenwatch
[  128.855757] Pid: 46, comm: xenwatch Tainted: G           O 3.4.0-rc4upstream-00103-g7e4325c-dirty #1
[  128.855917] Call Trace:
[  128.856062]  [<ffffffff810983ea>] __might_sleep+0xda/0x100
[  128.856215]  [<ffffffff815a9267>] mutex_lock+0x27/0x50
[  128.856351]  [<ffffffff811b3039>] sysfs_get_dirent+0x29/0x80
[  128.856495]  [<ffffffff811b4d7b>] sysfs_remove_group+0x2b/0x100
[  128.856626]  [<ffffffff81393a20>] xenvbd_sysfs_delif+0x20/0x50
[  128.856756]  [<ffffffff81394518>] xen_blkbk_remove+0xe8/0xf0
[  128.856895]  [<ffffffff8131c768>] xenbus_dev_remove+0x38/0x70
[  128.857041]  [<ffffffff81381601>] __device_release_driver+0x61/0xc0
[  128.857177]  [<ffffffff81381778>] device_release_driver+0x28/0x40
[  128.857323]  [<ffffffff81380896>] bus_remove_device+0x106/0x140
[  128.857459]  [<ffffffff8137e868>] device_del+0x118/0x1c0
[  128.857580]  [<ffffffff8137e921>] device_unregister+0x11/0x20
[  128.857712]  [<ffffffff8139376a>] frontend_changed+0xba/0x350
[  128.857851]  [<ffffffff810337f9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[  128.857982]  [<ffffffff8109928d>] ? finish_task_switch+0x4d/0x100
[  128.858106]  [<ffffffff8131ca18>] xenbus_otherend_changed+0xa8/0xb0
[  128.858236]  [<ffffffff815ab629>] ? _raw_spin_unlock_irqrestore+0x19/0x30
[  128.858368]  [<ffffffff8131cc2b>] frontend_changed+0xb/0x10
[  128.858522]  [<ffffffff8131ad3b>] xenwatch_thread+0xcb/0x190
[  128.858655]  [<ffffffff8108ec40>] ? wake_up_bit+0x40/0x40
[  128.858801]  [<ffffffff8131ac70>] ? xenbus_thread+0x320/0x320
[  128.858965]  [<ffffffff8108e716>] kthread+0x96/0xa0
[  128.859097]  [<ffffffff815b3564>] kernel_thread_helper+0x4/0x10
[  128.859235]  [<ffffffff815abb78>] ? retint_restore_args+0x5/0x6
[  128.859371]  [<ffffffff815b3560>] ? gs_change+0x13/0x13
[  128.859542] BUG: scheduling while atomic: xenwatch/46/0x00000002

whenever a guest is powered off.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 03:10:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 03:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNbZN-0000Tk-Ta; Fri, 27 Apr 2012 03:10:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNbZN-0000Tf-3F
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 03:10:05 +0000
Received: from [85.158.143.99:6717] by server-2.bemta-4.messagelabs.com id
	8A/05-17550-C0E0A9F4; Fri, 27 Apr 2012 03:10:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335496202!18436121!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11845 invoked from network); 27 Apr 2012 03:10:03 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 03:10:03 -0000
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227])
	by acsinet14.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R2Ubiw015024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 02:30:37 GMT
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3R2UVGS025947
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 02:30:32 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3R2UUVj024617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Apr 2012 02:30:31 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3R2UU6j022301; Thu, 26 Apr 2012 21:30:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Apr 2012 19:30:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 51325402FB; Thu, 26 Apr 2012 22:24:56 -0400 (EDT)
Date: Thu, 26 Apr 2012 22:24:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120427022456.GA26931@phenom.dumpdata.com>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
	<1334949673-25632-2-git-send-email-msw@amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1334949673-25632-2-git-send-email-msw@amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
Cc: Joe Jin <joe.jin@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in
 statistics sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 20, 2012 at 07:21:13PM +0000, Matt Wilson wrote:
> This is a port of a patch in the XenoLinux 2.6.18 tree:
> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56
> 
> Fix blkback sysfs race

So with this patch I keep on getting this:

[  128.274290] switch: port 2(vif1.0) entered disabled state
[  128.855442] BUG: sleeping function called from invalid context at /home/konrad/ssd/linux/kernel/mutex.c:85
[  128.855628] in_atomic(): 1, irqs_disabled(): 0, pid: 46, name: xenwatch
[  128.855757] Pid: 46, comm: xenwatch Tainted: G           O 3.4.0-rc4upstream-00103-g7e4325c-dirty #1
[  128.855917] Call Trace:
[  128.856062]  [<ffffffff810983ea>] __might_sleep+0xda/0x100
[  128.856215]  [<ffffffff815a9267>] mutex_lock+0x27/0x50
[  128.856351]  [<ffffffff811b3039>] sysfs_get_dirent+0x29/0x80
[  128.856495]  [<ffffffff811b4d7b>] sysfs_remove_group+0x2b/0x100
[  128.856626]  [<ffffffff81393a20>] xenvbd_sysfs_delif+0x20/0x50
[  128.856756]  [<ffffffff81394518>] xen_blkbk_remove+0xe8/0xf0
[  128.856895]  [<ffffffff8131c768>] xenbus_dev_remove+0x38/0x70
[  128.857041]  [<ffffffff81381601>] __device_release_driver+0x61/0xc0
[  128.857177]  [<ffffffff81381778>] device_release_driver+0x28/0x40
[  128.857323]  [<ffffffff81380896>] bus_remove_device+0x106/0x140
[  128.857459]  [<ffffffff8137e868>] device_del+0x118/0x1c0
[  128.857580]  [<ffffffff8137e921>] device_unregister+0x11/0x20
[  128.857712]  [<ffffffff8139376a>] frontend_changed+0xba/0x350
[  128.857851]  [<ffffffff810337f9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[  128.857982]  [<ffffffff8109928d>] ? finish_task_switch+0x4d/0x100
[  128.858106]  [<ffffffff8131ca18>] xenbus_otherend_changed+0xa8/0xb0
[  128.858236]  [<ffffffff815ab629>] ? _raw_spin_unlock_irqrestore+0x19/0x30
[  128.858368]  [<ffffffff8131cc2b>] frontend_changed+0xb/0x10
[  128.858522]  [<ffffffff8131ad3b>] xenwatch_thread+0xcb/0x190
[  128.858655]  [<ffffffff8108ec40>] ? wake_up_bit+0x40/0x40
[  128.858801]  [<ffffffff8131ac70>] ? xenbus_thread+0x320/0x320
[  128.858965]  [<ffffffff8108e716>] kthread+0x96/0xa0
[  128.859097]  [<ffffffff815b3564>] kernel_thread_helper+0x4/0x10
[  128.859235]  [<ffffffff815abb78>] ? retint_restore_args+0x5/0x6
[  128.859371]  [<ffffffff815b3560>] ? gs_change+0x13/0x13
[  128.859542] BUG: scheduling while atomic: xenwatch/46/0x00000002

whenever a guest is powered off.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 05:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 05:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNdWj-0001DB-OK; Fri, 27 Apr 2012 05:15:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SNdWi-0001D6-5b
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 05:15:28 +0000
Received: from [85.158.138.51:51700] by server-10.bemta-3.messagelabs.com id
	C1/5A-29478-F6B2A9F4; Fri, 27 Apr 2012 05:15:27 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335503724!19965498!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 27 Apr 2012 05:15:26 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 05:15:26 -0000
Received: by obbtb18 with SMTP id tb18so691198obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Apr 2012 22:15:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=NB+CwF0bhnj79zLPVmIa+sZJrkNL5rwFZTm/E3/E4X0=;
	b=gXZgN+2ILcLZyV+8DSl2y3mcIcVVhc35LtnN9YSeCE4X4zfVwJIWGv1poqy5auQ1w4
	tvIEVVdsv6lmMwohJTyGNU3DnwfXtmKxnb7Q8MiBw91CVlmjcljmO5Q6GFNTaHt8/2UX
	esZw8L8fuePwNmyHBQTpUfBaCJfQ7fyM2QP77pwKh7uZ2A19d1MMlN3aMUfM7EgD3ClB
	bmWF4JfiDSdGf9j3bb36vZrZJt7FebNmCv/8NboFRimomJg7lQ07C7WloFd7B3+1MTrP
	TVqvESH16p+rmHutFUFj0yhOf1lwMIO2sgRt4cXe8VNNVLm06khX0Jdf3MSGKqjQJU6L
	YRmw==
MIME-Version: 1.0
Received: by 10.60.23.138 with SMTP id m10mr12141751oef.12.1335503723911; Thu,
	26 Apr 2012 22:15:23 -0700 (PDT)
Received: by 10.182.77.134 with HTTP; Thu, 26 Apr 2012 22:15:23 -0700 (PDT)
In-Reply-To: <1335454757.28015.160.camel@zakaz.uk.xensource.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Apr 2012 13:15:23 +0800
Message-ID: <CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Fantu,

Thanks for your response.

xl doesn't support qxl-related option at the moment.
I will test upstream-qemu-xen these days, and if it works well
with qxl device, I will be glad to add qxl support to xl.

Best,

On Thu, Apr 26, 2012 at 11:39 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> CCing Zhou Peng who originally added spice support to xl. Zhou, are you
> interested in supporting this feature?
>
> On Thu, 2012-04-26 at 16:23 +0100, Fantu wrote:
>> Dom0:
>> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
>> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice=
 and
>> usb redirection.
>> -------------------------
>> /etc/modules
>> ------------
>> loop max_loop=3D64
>> xenfs
>> xen-evtchn
>> blktap
>> -------------------------
>> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset=
 is
>> 25249:a4e7fce6ee2b)
>> vi Makefile # removed dist-kernel to not compile kernel
>> -------------------------
>> vi Config.mk # qemu upstream unstable and seabios upstream unstable for
>> various spice and qxl bugfix
>> ------------
>> QEMU_UPSTREAM_URL ?=3D git://git.qemu.org/qemu.git
>> SEABIOS_UPSTREAM_URL ?=3D git://git.seabios.org/seabios.git
>> SEABIOS_UPSTREAM_TAG ?=3D rel-1.7.0
>> -------------------------
>> Added some patches:
>> - autoconf: add variable for pass arbitrary options to qemu upstream v3
>> - tools: Improve make deb
>> -------------------------
>> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
>> --enable-qemuu-debug
>> -------------------------
>> make deb
>>
>> Tested it on Windows XP domU with this xl configuration file:
>> -------------------------------
>> XP.cfg
>> ---------
>> name=3D'XP'
>> builder=3D"hvm"
>> memory=3D1024
>> vcpus=3D2
>> hap=3D1
>> pae=3D1
>> acpi=3D1
>> apic=3D1
>> nx=3D1
>> vif=3D['bridge=3Dxenbr0']
>> #vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit']
>> #disk=3D['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
>> disk=3D['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>> boot=3D'cd'
>> xen_platform_pci=3D1
>> viridian=3D1
>> device_model_version=3D"qemu-xen"
>> #device_model_override=3D"/usr/lib/xen/bin/qemu-debug.sh"
>> #vnc=3D1
>> #vncunused=3D1
>> #vnclisten=3D"0.0.0.0"
>> #keymap=3D"it"
>> spice=3D1
>> spicehost=3D"0.0.0.0"
>> spiceport=3D6000
>> spicedisable_ticketing=3D1
>> on_poweroff=3D"destroy"
>> on_reboot=3D"restart"
>> on_crash=3D"destroy"
>> stdvga=3D1
>> #device_model_args=3D["-vga qxl -global qxl-vga.vram_size_mb=3D16"]
>> #videoram=3D128
>> #device_model_args=3D["-vga qxl"]
>> -------------------------------
>> With stdvga option domU is working but graphic performance is poor with
>> spice.
>>
>>
>> With QXL vga option domU
>> -------------------------------
>> videoram=3D128
>> device_model_args=3D["-vga qxl"]
>> stdvga=3D0
>> -------------------------------
>> DomU not start, from qemu log:
>> qemu-system-i386: -vga qxl: invalid option
>>
>> But the option is correct and if I add:
>> device_model_override=3D"/usr/lib/xen/bin/qemu-debug.sh"
>>
>> qemu-debug.sh launches the same qemu-system-i386 with same options and d=
omU
>> starts.
>> DomU sees the QXL vga but only with 4 mb allocated and/or usabled instea=
d of
>> 64 mb of qemu default.
>>
>> We need domUs with good graphic performance, also with high resolution a=
nd
>> also multimedia.
>> We can not use gfx passthrough on our dom0s because of hardware limitati=
on
>> of dell server.
>> QXL seems to be the only way to go.
>>
>> We are testing this setup several months without success on xen.
>> Some initial xl and qemu ram/videoram bugs are now fixed but may be there
>> are other in xen not found for now.
>>
>> We noticed one particular thing:
>>
>> without qxl:
>> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>> =A0 Loader: =A0 =A0 =A0 =A00000000000100000->000000000019dc88
>> =A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000->000000003f800000
>> =A0 ENTRY ADDRESS: 0000000000100000
>>
>> with qxl:
>> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>> =A0 Loader: =A0 =A0 =A0 =A00000000000100000->000000000019dc88
>> =A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000->0000000038000000
>> =A0 ENTRY ADDRESS: 0000000000100000
>>
>> The total memory with qxl should be equal or major than total memory wit=
hout
>> qxl.
>> There is something wrong about videoram, i don't know if in xl or other =
part
>> of xen.
>>
>> Please someone help me to solve this problem?
>>
>> --
>> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to=
-get-QXL-vga-working-tp5667919p5667919.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 05:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 05:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNdWj-0001DB-OK; Fri, 27 Apr 2012 05:15:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SNdWi-0001D6-5b
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 05:15:28 +0000
Received: from [85.158.138.51:51700] by server-10.bemta-3.messagelabs.com id
	C1/5A-29478-F6B2A9F4; Fri, 27 Apr 2012 05:15:27 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335503724!19965498!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 27 Apr 2012 05:15:26 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 05:15:26 -0000
Received: by obbtb18 with SMTP id tb18so691198obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Apr 2012 22:15:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=NB+CwF0bhnj79zLPVmIa+sZJrkNL5rwFZTm/E3/E4X0=;
	b=gXZgN+2ILcLZyV+8DSl2y3mcIcVVhc35LtnN9YSeCE4X4zfVwJIWGv1poqy5auQ1w4
	tvIEVVdsv6lmMwohJTyGNU3DnwfXtmKxnb7Q8MiBw91CVlmjcljmO5Q6GFNTaHt8/2UX
	esZw8L8fuePwNmyHBQTpUfBaCJfQ7fyM2QP77pwKh7uZ2A19d1MMlN3aMUfM7EgD3ClB
	bmWF4JfiDSdGf9j3bb36vZrZJt7FebNmCv/8NboFRimomJg7lQ07C7WloFd7B3+1MTrP
	TVqvESH16p+rmHutFUFj0yhOf1lwMIO2sgRt4cXe8VNNVLm06khX0Jdf3MSGKqjQJU6L
	YRmw==
MIME-Version: 1.0
Received: by 10.60.23.138 with SMTP id m10mr12141751oef.12.1335503723911; Thu,
	26 Apr 2012 22:15:23 -0700 (PDT)
Received: by 10.182.77.134 with HTTP; Thu, 26 Apr 2012 22:15:23 -0700 (PDT)
In-Reply-To: <1335454757.28015.160.camel@zakaz.uk.xensource.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Apr 2012 13:15:23 +0800
Message-ID: <CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Fantu,

Thanks for your response.

xl doesn't support qxl-related option at the moment.
I will test upstream-qemu-xen these days, and if it works well
with qxl device, I will be glad to add qxl support to xl.

Best,

On Thu, Apr 26, 2012 at 11:39 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> CCing Zhou Peng who originally added spice support to xl. Zhou, are you
> interested in supporting this feature?
>
> On Thu, 2012-04-26 at 16:23 +0100, Fantu wrote:
>> Dom0:
>> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
>> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice=
 and
>> usb redirection.
>> -------------------------
>> /etc/modules
>> ------------
>> loop max_loop=3D64
>> xenfs
>> xen-evtchn
>> blktap
>> -------------------------
>> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset=
 is
>> 25249:a4e7fce6ee2b)
>> vi Makefile # removed dist-kernel to not compile kernel
>> -------------------------
>> vi Config.mk # qemu upstream unstable and seabios upstream unstable for
>> various spice and qxl bugfix
>> ------------
>> QEMU_UPSTREAM_URL ?=3D git://git.qemu.org/qemu.git
>> SEABIOS_UPSTREAM_URL ?=3D git://git.seabios.org/seabios.git
>> SEABIOS_UPSTREAM_TAG ?=3D rel-1.7.0
>> -------------------------
>> Added some patches:
>> - autoconf: add variable for pass arbitrary options to qemu upstream v3
>> - tools: Improve make deb
>> -------------------------
>> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
>> --enable-qemuu-debug
>> -------------------------
>> make deb
>>
>> Tested it on Windows XP domU with this xl configuration file:
>> -------------------------------
>> XP.cfg
>> ---------
>> name=3D'XP'
>> builder=3D"hvm"
>> memory=3D1024
>> vcpus=3D2
>> hap=3D1
>> pae=3D1
>> acpi=3D1
>> apic=3D1
>> nx=3D1
>> vif=3D['bridge=3Dxenbr0']
>> #vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit']
>> #disk=3D['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
>> disk=3D['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>> boot=3D'cd'
>> xen_platform_pci=3D1
>> viridian=3D1
>> device_model_version=3D"qemu-xen"
>> #device_model_override=3D"/usr/lib/xen/bin/qemu-debug.sh"
>> #vnc=3D1
>> #vncunused=3D1
>> #vnclisten=3D"0.0.0.0"
>> #keymap=3D"it"
>> spice=3D1
>> spicehost=3D"0.0.0.0"
>> spiceport=3D6000
>> spicedisable_ticketing=3D1
>> on_poweroff=3D"destroy"
>> on_reboot=3D"restart"
>> on_crash=3D"destroy"
>> stdvga=3D1
>> #device_model_args=3D["-vga qxl -global qxl-vga.vram_size_mb=3D16"]
>> #videoram=3D128
>> #device_model_args=3D["-vga qxl"]
>> -------------------------------
>> With stdvga option domU is working but graphic performance is poor with
>> spice.
>>
>>
>> With QXL vga option domU
>> -------------------------------
>> videoram=3D128
>> device_model_args=3D["-vga qxl"]
>> stdvga=3D0
>> -------------------------------
>> DomU not start, from qemu log:
>> qemu-system-i386: -vga qxl: invalid option
>>
>> But the option is correct and if I add:
>> device_model_override=3D"/usr/lib/xen/bin/qemu-debug.sh"
>>
>> qemu-debug.sh launches the same qemu-system-i386 with same options and d=
omU
>> starts.
>> DomU sees the QXL vga but only with 4 mb allocated and/or usabled instea=
d of
>> 64 mb of qemu default.
>>
>> We need domUs with good graphic performance, also with high resolution a=
nd
>> also multimedia.
>> We can not use gfx passthrough on our dom0s because of hardware limitati=
on
>> of dell server.
>> QXL seems to be the only way to go.
>>
>> We are testing this setup several months without success on xen.
>> Some initial xl and qemu ram/videoram bugs are now fixed but may be there
>> are other in xen not found for now.
>>
>> We noticed one particular thing:
>>
>> without qxl:
>> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>> =A0 Loader: =A0 =A0 =A0 =A00000000000100000->000000000019dc88
>> =A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000->000000003f800000
>> =A0 ENTRY ADDRESS: 0000000000100000
>>
>> with qxl:
>> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>> =A0 Loader: =A0 =A0 =A0 =A00000000000100000->000000000019dc88
>> =A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000->0000000038000000
>> =A0 ENTRY ADDRESS: 0000000000100000
>>
>> The total memory with qxl should be equal or major than total memory wit=
hout
>> qxl.
>> There is something wrong about videoram, i don't know if in xl or other =
part
>> of xen.
>>
>> Please someone help me to solve this problem?
>>
>> --
>> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to=
-get-QXL-vga-working-tp5667919p5667919.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 06:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 06:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNejo-0001vA-PP; Fri, 27 Apr 2012 06:33:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNejn-0001v3-04
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 06:33:03 +0000
Received: from [193.109.254.147:64794] by server-7.bemta-14.messagelabs.com id
	3A/59-01627-E9D3A9F4; Fri, 27 Apr 2012 06:33:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335508381!6558453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY2OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9378 invoked from network); 27 Apr 2012 06:33:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 06:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,489,1330905600"; d="scan'208";a="12168889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 06:33:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Apr 2012 07:33:00 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNejk-0006TX-BQ;
	Fri, 27 Apr 2012 06:33:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNejk-0003pL-An;
	Fri, 27 Apr 2012 07:33:00 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12758-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Apr 2012 07:33:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12758: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12758 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12758/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12756
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12756
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12756

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12756 blocked in 12758

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  107285938c50
baseline version:
 xen                  107285938c50

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 06:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 06:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNejo-0001vA-PP; Fri, 27 Apr 2012 06:33:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNejn-0001v3-04
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 06:33:03 +0000
Received: from [193.109.254.147:64794] by server-7.bemta-14.messagelabs.com id
	3A/59-01627-E9D3A9F4; Fri, 27 Apr 2012 06:33:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335508381!6558453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY2OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9378 invoked from network); 27 Apr 2012 06:33:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 06:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,489,1330905600"; d="scan'208";a="12168889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 06:33:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Apr 2012 07:33:00 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNejk-0006TX-BQ;
	Fri, 27 Apr 2012 06:33:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNejk-0003pL-An;
	Fri, 27 Apr 2012 07:33:00 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12758-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Apr 2012 07:33:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12758: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12758 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12758/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12756
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12756
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12756

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12756 blocked in 12758

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  107285938c50
baseline version:
 xen                  107285938c50

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:22:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgQa-000307-0N; Fri, 27 Apr 2012 08:21:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SNgQX-000302-A2
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:21:18 +0000
Received: from [85.158.139.83:41310] by server-11.bemta-5.messagelabs.com id
	74/64-12959-CF65A9F4; Fri, 27 Apr 2012 08:21:16 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335514875!21796431!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4496 invoked from network); 27 Apr 2012 08:21:15 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 08:21:15 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 40BD01C14001;
	Fri, 27 Apr 2012 10:21:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=LjSgpK1WNgQqjKVxMglCpptv4zE=; b=io
	cCvFDx37w3k4tEQL0f+xHnnVQLJDZ+EWaeyrBOMiSSlAV2ixERsfLfui4lE0zu6u
	mnoyiBtX1b6pHT7hP1iJFttr/jaiWVifQDjJOwiq8A+GPNIQos98LX5lOfvtQcxp
	mEPu2E2VwIrPL4vFuqfurN61LfFYBk+1SCKgKinH8cfsCN+RkjN1S9WROxZ5IW+S
	URkRuzYgRPOaJ6KpRIpqQfbyFiIkFf67qsPTUmcvIK3b0Ni7ZWf6tf0lS60nIl8w
	mOr+GNBF4JFzjdFhNY0P+bwQWSiaLf3SQJcaOuNWuMnxMD8RcRR1DrQRZMLTkOrV
	iTsfFZ+twO/Q4fnA2FPxkqv5JXKegR3Sls4TWQ2tb+KWCcyfop3dEl9mheScMi1/
	1D1m3+dCiOfmjV/1gQ9gClYADU/yEvBSQpTxMUATTCxZrTQDffjDcOBUbyFkRPHv
	JqJ9Oj4k3nN/2QsONoJcg2tjHH8hUZR9bRCHk11yrxxbJWXEYYRUFOPfGLymHSAZ
	9aXfS/QKpArgvdIPWZ+1FXJtu7J4NredC6dMPm7qsH19GEzXM64PkPT5cO7q4E4O
	J3o0jx6JtAc8s/ItMuwZWKWY9EbQ4iG7QXX0dMy2Af0tk2WuQpqZzzCm9sYPJ1ex
	xcXcaA6IBiQzoHm1dmDExVpW8B7M0kRjjNUXbOLCc=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 14AED1C14002; Fri, 27 Apr 2012 10:21:14 +0200 (CEST)
Date: Fri, 27 Apr 2012 10:21:14 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120427082114.GA28258@bloms.de>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1UWUbFP1cBYEclgG"
Content-Disposition: inline
In-Reply-To: <1335441317.28015.127.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, George.Dunlap@citrix.com
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Apr 26, Ian Campbell wrote:

> This is no doubt an issue with 25244:e428eae1838c (CCing author). I
> suspect the problem is that you are not setting any scheduler options
> but it is unconditionally setting them. I think what it really should be
> doing, is reading the current settings, updating those which the user
> has specified and writing them back. I'm not sure how best to achieve
> that in the libxl api though (CCing some scheduler folks)

yes, this is an issue with my patch :(
All default values has to be 0, but only for the credit(2) scheduler
cpu_weight must not.
So I made a patch, which set a default of 256 when the cpu_weight isn't set
and credit(2) is used and let it 0 when the scheduler sedf is used.

Please try the attached patch and see if it solve this issue.


--=20
Best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--1UWUbFP1cBYEclgG
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="set_correct_default_credit_weight.diff"

libxl: set correct credit cpu weight, when no one is specified in the config file

all default values have to be set to 0, but for the credit(2) scheduler
cpu_weight has to be 256 by default.
So if the weight isn't given in the confgfile we use 256 for the credit(2)
scheduler and 0 for sedf

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c246211..ec2e3af 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -62,12 +62,18 @@ int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *s
       ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
       break;
     case LIBXL_SCHEDULER_CREDIT:
-      credit_info.weight = scparams->weight;
+      if (scparams->weight)
+          credit_info.weight = scparams->weight;
+      else
+          credit_info.weight = 256;
       credit_info.cap = scparams->cap;
       ret=libxl_sched_credit_domain_set(ctx, domid, &credit_info);
       break;
     case LIBXL_SCHEDULER_CREDIT2:
-      credit2_info.weight = scparams->weight;
+      if (scparams->weight)
+          credit2_info.weight = scparams->weight;
+      else
+          credit_info.weight = 256;
       ret=libxl_sched_credit2_domain_set(ctx, domid, &credit2_info);
       break;
     default:

--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1UWUbFP1cBYEclgG--


From xen-devel-bounces@lists.xen.org Fri Apr 27 08:22:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgQa-000307-0N; Fri, 27 Apr 2012 08:21:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dieter@bloms.de>) id 1SNgQX-000302-A2
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:21:18 +0000
Received: from [85.158.139.83:41310] by server-11.bemta-5.messagelabs.com id
	74/64-12959-CF65A9F4; Fri, 27 Apr 2012 08:21:16 +0000
X-Env-Sender: dieter@bloms.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335514875!21796431!1
X-Originating-IP: [84.200.248.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4496 invoked from network); 27 Apr 2012 08:21:15 -0000
Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 08:21:15 -0000
Received: from smtp.bloms.de (localhost [127.0.0.1])
	by smtp.bloms.de (Postfix) with ESMTP id 40BD01C14001;
	Fri, 27 Apr 2012 10:21:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to
	:cc:subject:message-id:references:mime-version:content-type
	:in-reply-to; s=selector1; bh=LjSgpK1WNgQqjKVxMglCpptv4zE=; b=io
	cCvFDx37w3k4tEQL0f+xHnnVQLJDZ+EWaeyrBOMiSSlAV2ixERsfLfui4lE0zu6u
	mnoyiBtX1b6pHT7hP1iJFttr/jaiWVifQDjJOwiq8A+GPNIQos98LX5lOfvtQcxp
	mEPu2E2VwIrPL4vFuqfurN61LfFYBk+1SCKgKinH8cfsCN+RkjN1S9WROxZ5IW+S
	URkRuzYgRPOaJ6KpRIpqQfbyFiIkFf67qsPTUmcvIK3b0Ni7ZWf6tf0lS60nIl8w
	mOr+GNBF4JFzjdFhNY0P+bwQWSiaLf3SQJcaOuNWuMnxMD8RcRR1DrQRZMLTkOrV
	iTsfFZ+twO/Q4fnA2FPxkqv5JXKegR3Sls4TWQ2tb+KWCcyfop3dEl9mheScMi1/
	1D1m3+dCiOfmjV/1gQ9gClYADU/yEvBSQpTxMUATTCxZrTQDffjDcOBUbyFkRPHv
	JqJ9Oj4k3nN/2QsONoJcg2tjHH8hUZR9bRCHk11yrxxbJWXEYYRUFOPfGLymHSAZ
	9aXfS/QKpArgvdIPWZ+1FXJtu7J4NredC6dMPm7qsH19GEzXM64PkPT5cO7q4E4O
	J3o0jx6JtAc8s/ItMuwZWKWY9EbQ4iG7QXX0dMy2Af0tk2WuQpqZzzCm9sYPJ1ex
	xcXcaA6IBiQzoHm1dmDExVpW8B7M0kRjjNUXbOLCc=
Received: by smtp.bloms.de (Postfix, from userid 1000)
	id 14AED1C14002; Fri, 27 Apr 2012 10:21:14 +0200 (CEST)
Date: Fri, 27 Apr 2012 10:21:14 +0200
From: Dieter Bloms <dieter@bloms.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120427082114.GA28258@bloms.de>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1UWUbFP1cBYEclgG"
Content-Disposition: inline
In-Reply-To: <1335441317.28015.127.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, George.Dunlap@citrix.com
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Apr 26, Ian Campbell wrote:

> This is no doubt an issue with 25244:e428eae1838c (CCing author). I
> suspect the problem is that you are not setting any scheduler options
> but it is unconditionally setting them. I think what it really should be
> doing, is reading the current settings, updating those which the user
> has specified and writing them back. I'm not sure how best to achieve
> that in the libxl api though (CCing some scheduler folks)

yes, this is an issue with my patch :(
All default values has to be 0, but only for the credit(2) scheduler
cpu_weight must not.
So I made a patch, which set a default of 256 when the cpu_weight isn't set
and credit(2) is used and let it 0 when the scheduler sedf is used.

Please try the attached patch and see if it solve this issue.


--=20
Best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
=46rom field.

--1UWUbFP1cBYEclgG
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="set_correct_default_credit_weight.diff"

libxl: set correct credit cpu weight, when no one is specified in the config file

all default values have to be set to 0, but for the credit(2) scheduler
cpu_weight has to be 256 by default.
So if the weight isn't given in the confgfile we use 256 for the credit(2)
scheduler and 0 for sedf

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c246211..ec2e3af 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -62,12 +62,18 @@ int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *s
       ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
       break;
     case LIBXL_SCHEDULER_CREDIT:
-      credit_info.weight = scparams->weight;
+      if (scparams->weight)
+          credit_info.weight = scparams->weight;
+      else
+          credit_info.weight = 256;
       credit_info.cap = scparams->cap;
       ret=libxl_sched_credit_domain_set(ctx, domid, &credit_info);
       break;
     case LIBXL_SCHEDULER_CREDIT2:
-      credit2_info.weight = scparams->weight;
+      if (scparams->weight)
+          credit2_info.weight = scparams->weight;
+      else
+          credit_info.weight = 256;
       ret=libxl_sched_credit2_domain_set(ctx, domid, &credit2_info);
       break;
     default:

--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1UWUbFP1cBYEclgG--


From xen-devel-bounces@lists.xen.org Fri Apr 27 08:37:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgfH-00039m-GC; Fri, 27 Apr 2012 08:36:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SNgfF-00039h-He
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:36:29 +0000
Received: from [85.158.138.51:44314] by server-6.bemta-3.messagelabs.com id
	8F/14-05145-C8A5A9F4; Fri, 27 Apr 2012 08:36:28 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335515786!22266257!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyMjQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5378 invoked from network); 27 Apr 2012 08:36:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-174.messagelabs.com with SMTP;
	27 Apr 2012 08:36:27 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 27 Apr 2012 01:36:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="136068774"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 27 Apr 2012 01:36:25 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 27 Apr 2012 01:36:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 16:36:23 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "andres@lagarcavilla.org"
	<andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoABqsUeA//9EJFD//wqOgP/9iB6Q//qVqJA=
Date: Fri, 27 Apr 2012 08:36:23 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F9006@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
	<1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Zhang, Yang Z
> Sent: Friday, April 27, 2012 9:25 AM
> To: andres@lagarcavilla.org
> Cc: Tim Deegan; Keir Fraser; xen-devel@lists.xensource.com; olaf@aepfle.de;
> George.Dunlap@eu.citrix.com
> Subject: RE: [Xen-devel] lock in vhpet
> 
> 
> > -----Original Message-----
> > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > Sent: Friday, April 27, 2012 8:52 AM
> > To: Zhang, Yang Z
> > Cc: Tim Deegan; Keir Fraser; xen-devel@lists.xensource.com;
> > olaf@aepfle.de; George.Dunlap@eu.citrix.com
> > Subject: RE: [Xen-devel] lock in vhpet
> >
> > >> -----Original Message-----
> > >> From: Tim Deegan [mailto:tim@xen.org]
> > >> Sent: Friday, April 27, 2012 5:26 AM
> > >> To: Zhang, Yang Z
> > >> Cc: andres@lagarcavilla.org; Keir Fraser;
> > >> xen-devel@lists.xensource.com
> > >> Subject: Re: [Xen-devel] lock in vhpet
> > >>
> > >> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> > >> > > > But actually, the first cs introduced this issue is 24770.
> > >> > > > When
> > >> > > > win8 booting and if hpet is enabled, it will use hpet as the
> > >> > > > time source and there have lots of hpet access and EPT
> > >> > > > violation. In EPT violation handler, it call
> > >> > > > get_gfn_type_access to get
> > the mfn.
> > >> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and
> > >> > > > then the
> > >> issue
> > >> happens.
> > >> > > > After I removed the gfn_lock, the issue goes. But in latest
> > >> > > > xen, even I remove this lock, it still shows high cpu utilization.
> > >> > >
> > >> > > It would seem then that even the briefest lock-protected
> > >> > > critical section would cause this? In the mmio case, the p2m
> > >> > > lock taken in the hap fault handler is held during the actual
> > >> > > lookup, and for a couple of branch instructions afterwards.
> > >> > >
> > >> > > In latest Xen, with lock removed for get_gfn, on which lock is
> > >> > > time
> > >> spent?
> > >> > Still the p2m_lock.
> > >>
> > >> Can you please try the attached patch?  I think you'll need this
> > >> one plus the ones that take the locks out of the hpet code.
> > >>
> > >> This patch makes the p2m lock into an rwlock and adjusts a number
> > >> of the paths that don't update the p2m so they only take the read lock.
> > >> It's a bit rough but I can boot 16-way win7 guest with it.
> >
> > That is great news.
> >
> > Tim, thanks for the amazing work. I'm poring over the patch presently,
> > and will shoot at it with everything I've got testing-wise.
> >
> > I'm taking the liberty of pulling in Olaf (paging) and George (PoD) as
> > the changeset affects those subsystems.
> 
> But win8 guest shows BSOD with 32 VCPUs. :( The reason of BSOD is :
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (ACPI.sys)
> 
Um....., I find this issue is related to xl not hypervisor.  
Will send a patch to fix it later.

yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:37:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgfH-00039m-GC; Fri, 27 Apr 2012 08:36:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SNgfF-00039h-He
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:36:29 +0000
Received: from [85.158.138.51:44314] by server-6.bemta-3.messagelabs.com id
	8F/14-05145-C8A5A9F4; Fri, 27 Apr 2012 08:36:28 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335515786!22266257!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyMjQx\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5378 invoked from network); 27 Apr 2012 08:36:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-174.messagelabs.com with SMTP;
	27 Apr 2012 08:36:27 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 27 Apr 2012 01:36:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="136068774"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 27 Apr 2012 01:36:25 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 27 Apr 2012 01:36:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.213]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.136]) with mapi id
	14.01.0355.002; Fri, 27 Apr 2012 16:36:23 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "andres@lagarcavilla.org"
	<andres@lagarcavilla.org>
Thread-Topic: [Xen-devel] lock in vhpet
Thread-Index: Ac0eCQwXJG/pjIlt90WVAZCixCEkDQDGHugQABTqmCsAIL0OEP//f4gA//57d2CAApdigP//edFQgACUawD//3mnoABqsUeA//9EJFD//wqOgP/9iB6Q//qVqJA=
Date: Fri, 27 Apr 2012 08:36:23 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0F9006@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0F1154@SHSMSX101.ccr.corp.intel.com>
	<20120423091445.GA17920@ocelot.phlegethon.org>
	<2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F89B1@SHSMSX101.ccr.corp.intel.com>
	<1ae7df4c843a32fd11425470ab161046.squirrel@webmail.lagarcavilla.org> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Zhang, Yang Z
> Sent: Friday, April 27, 2012 9:25 AM
> To: andres@lagarcavilla.org
> Cc: Tim Deegan; Keir Fraser; xen-devel@lists.xensource.com; olaf@aepfle.de;
> George.Dunlap@eu.citrix.com
> Subject: RE: [Xen-devel] lock in vhpet
> 
> 
> > -----Original Message-----
> > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > Sent: Friday, April 27, 2012 8:52 AM
> > To: Zhang, Yang Z
> > Cc: Tim Deegan; Keir Fraser; xen-devel@lists.xensource.com;
> > olaf@aepfle.de; George.Dunlap@eu.citrix.com
> > Subject: RE: [Xen-devel] lock in vhpet
> >
> > >> -----Original Message-----
> > >> From: Tim Deegan [mailto:tim@xen.org]
> > >> Sent: Friday, April 27, 2012 5:26 AM
> > >> To: Zhang, Yang Z
> > >> Cc: andres@lagarcavilla.org; Keir Fraser;
> > >> xen-devel@lists.xensource.com
> > >> Subject: Re: [Xen-devel] lock in vhpet
> > >>
> > >> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> > >> > > > But actually, the first cs introduced this issue is 24770.
> > >> > > > When
> > >> > > > win8 booting and if hpet is enabled, it will use hpet as the
> > >> > > > time source and there have lots of hpet access and EPT
> > >> > > > violation. In EPT violation handler, it call
> > >> > > > get_gfn_type_access to get
> > the mfn.
> > >> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and
> > >> > > > then the
> > >> issue
> > >> happens.
> > >> > > > After I removed the gfn_lock, the issue goes. But in latest
> > >> > > > xen, even I remove this lock, it still shows high cpu utilization.
> > >> > >
> > >> > > It would seem then that even the briefest lock-protected
> > >> > > critical section would cause this? In the mmio case, the p2m
> > >> > > lock taken in the hap fault handler is held during the actual
> > >> > > lookup, and for a couple of branch instructions afterwards.
> > >> > >
> > >> > > In latest Xen, with lock removed for get_gfn, on which lock is
> > >> > > time
> > >> spent?
> > >> > Still the p2m_lock.
> > >>
> > >> Can you please try the attached patch?  I think you'll need this
> > >> one plus the ones that take the locks out of the hpet code.
> > >>
> > >> This patch makes the p2m lock into an rwlock and adjusts a number
> > >> of the paths that don't update the p2m so they only take the read lock.
> > >> It's a bit rough but I can boot 16-way win7 guest with it.
> >
> > That is great news.
> >
> > Tim, thanks for the amazing work. I'm poring over the patch presently,
> > and will shoot at it with everything I've got testing-wise.
> >
> > I'm taking the liberty of pulling in Olaf (paging) and George (PoD) as
> > the changeset affects those subsystems.
> 
> But win8 guest shows BSOD with 32 VCPUs. :( The reason of BSOD is :
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (ACPI.sys)
> 
Um....., I find this issue is related to xl not hypervisor.  
Will send a patch to fix it later.

yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:46:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgoG-0003WF-AK; Fri, 27 Apr 2012 08:45:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNgoF-0003W6-22
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:45:47 +0000
Received: from [193.109.254.147:50013] by server-7.bemta-14.messagelabs.com id
	8D/44-01627-9BC5A9F4; Fri, 27 Apr 2012 08:45:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335516342!4133241!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDAwMDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21396 invoked from network); 27 Apr 2012 08:45:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 08:45:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330923600"; d="scan'208";a="24605195"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 04:45:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 04:45:41 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNgo9-00006e-IQ;
	Fri, 27 Apr 2012 09:45:41 +0100
Message-ID: <4F9A5C79.2090604@eu.citrix.com>
Date: Fri, 27 Apr 2012 09:44:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Dieter Bloms <dieter@bloms.de>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de>
In-Reply-To: <20120427082114.GA28258@bloms.de>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/04/12 09:21, Dieter Bloms wrote:
> yes, this is an issue with my patch :( All default values has to be 0, 
> but only for the credit(2) scheduler cpu_weight must not. So I made a 
> patch, which set a default of 256 when the cpu_weight isn't set and 
> credit(2) is used and let it 0 when the scheduler sedf is used. Please 
> try the attached patch and see if it solve this issue. 
Dieter,

Thanks for the patch.  However, I'd really rather avoid putting 
scheduler defaults in xl if we can at all avoid it.  Defaults should be 
set in one place, and that should be in the scheduling code itself.

I think what we really want to do is is any of the parameters are set, 
after the domain is first created, to read the scheduling parameters for 
the domain (which will be the defaults), change the ones that are set in 
the config file, and then write the whole structure back.  That 
shouldn't be too hard, as libxl__sched_set_params() is called after the 
domain itself is created; the main thing is how to tell 
libxl__sched_set_params() which parameters actually need to be set, and 
which should be left alone.

Are you up for doing that?  If not, I can put it on my to-do list.

Thanks,
  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:46:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgoG-0003WF-AK; Fri, 27 Apr 2012 08:45:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNgoF-0003W6-22
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:45:47 +0000
Received: from [193.109.254.147:50013] by server-7.bemta-14.messagelabs.com id
	8D/44-01627-9BC5A9F4; Fri, 27 Apr 2012 08:45:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335516342!4133241!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDAwMDY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21396 invoked from network); 27 Apr 2012 08:45:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 08:45:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330923600"; d="scan'208";a="24605195"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 04:45:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 04:45:41 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNgo9-00006e-IQ;
	Fri, 27 Apr 2012 09:45:41 +0100
Message-ID: <4F9A5C79.2090604@eu.citrix.com>
Date: Fri, 27 Apr 2012 09:44:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Dieter Bloms <dieter@bloms.de>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de>
In-Reply-To: <20120427082114.GA28258@bloms.de>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/04/12 09:21, Dieter Bloms wrote:
> yes, this is an issue with my patch :( All default values has to be 0, 
> but only for the credit(2) scheduler cpu_weight must not. So I made a 
> patch, which set a default of 256 when the cpu_weight isn't set and 
> credit(2) is used and let it 0 when the scheduler sedf is used. Please 
> try the attached patch and see if it solve this issue. 
Dieter,

Thanks for the patch.  However, I'd really rather avoid putting 
scheduler defaults in xl if we can at all avoid it.  Defaults should be 
set in one place, and that should be in the scheduling code itself.

I think what we really want to do is is any of the parameters are set, 
after the domain is first created, to read the scheduling parameters for 
the domain (which will be the defaults), change the ones that are set in 
the config file, and then write the whole structure back.  That 
shouldn't be too hard, as libxl__sched_set_params() is called after the 
domain itself is created; the main thing is how to tell 
libxl__sched_set_params() which parameters actually need to be set, and 
which should be left alone.

Are you up for doing that?  If not, I can put it on my to-do list.

Thanks,
  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgpm-0003cI-Q3; Fri, 27 Apr 2012 08:47:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNgpl-0003c8-6M
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:47:21 +0000
Received: from [85.158.138.51:25623] by server-10.bemta-3.messagelabs.com id
	24/06-29478-81D5A9F4; Fri, 27 Apr 2012 08:47:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335516439!13072522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY2OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21783 invoked from network); 27 Apr 2012 08:47:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 08:47:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12171336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 08:47:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 09:47:18 +0100
Message-ID: <1335516436.28015.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 27 Apr 2012 09:47:16 +0100
In-Reply-To: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> called even if no events were pending.

In actual fact it seems that the callback was actually being called if
and only if no events were pending? Which makes me wonder how it used to
work at all!

> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> index 79d7362..3e45aa0 100644
> --- a/arch/x86/xen/xen-asm.S
> +++ b/arch/x86/xen/xen-asm.S
> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>  
>  	/* check for unmasked and pending */
>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> -	jz 1f
> +	jnz 1f
>  2:	call check_events
>  1:

Took me a while, this is a bit tricksy (and it may well be too early for
me to be decoding it) since the check here is trying to check both
pending and masked in a single cmpw, but I think this is correct. It
will call check_events now only when the combined mask+pending word is
0x0001 (aka unmasked, pending).

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Does xen_irq_enable_direct have the same sort of issue? No, in that case
we are doing a straight forward test of pending without involving masked
(since it has just unmasked) and so jz is correct.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgpm-0003cI-Q3; Fri, 27 Apr 2012 08:47:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNgpl-0003c8-6M
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:47:21 +0000
Received: from [85.158.138.51:25623] by server-10.bemta-3.messagelabs.com id
	24/06-29478-81D5A9F4; Fri, 27 Apr 2012 08:47:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335516439!13072522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY2OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21783 invoked from network); 27 Apr 2012 08:47:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 08:47:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12171336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 08:47:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 09:47:18 +0100
Message-ID: <1335516436.28015.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 27 Apr 2012 09:47:16 +0100
In-Reply-To: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> called even if no events were pending.

In actual fact it seems that the callback was actually being called if
and only if no events were pending? Which makes me wonder how it used to
work at all!

> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> index 79d7362..3e45aa0 100644
> --- a/arch/x86/xen/xen-asm.S
> +++ b/arch/x86/xen/xen-asm.S
> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>  
>  	/* check for unmasked and pending */
>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> -	jz 1f
> +	jnz 1f
>  2:	call check_events
>  1:

Took me a while, this is a bit tricksy (and it may well be too early for
me to be decoding it) since the check here is trying to check both
pending and masked in a single cmpw, but I think this is correct. It
will call check_events now only when the combined mask+pending word is
0x0001 (aka unmasked, pending).

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Does xen_irq_enable_direct have the same sort of issue? No, in that case
we are doing a straight forward test of pending without involving masked
(since it has just unmasked) and so jz is correct.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:48:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:48:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgqz-0003iq-8v; Fri, 27 Apr 2012 08:48:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNgqx-0003ii-RC
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 08:48:35 +0000
Received: from [85.158.143.99:43958] by server-1.bemta-4.messagelabs.com id
	04/E9-20925-36D5A9F4; Fri, 27 Apr 2012 08:48:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335516514!14316739!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6479 invoked from network); 27 Apr 2012 08:48:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 08:48:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNgqu-000MPQ-Rh; Fri, 27 Apr 2012 08:48:32 +0000
Date: Fri, 27 Apr 2012 09:48:32 +0100
From: Tim Deegan <tim@xen.org>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <20120427084832.GA86045@ocelot.phlegethon.org>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Christian.Limpach@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
	type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:36 -0700 on 26 Apr (1335465381), Aravindh Puthiyaparambil wrote:
> > - this is wrong:
> > > -        old_entry = *ept_entry;
> > > +        old_entry->epte = ept_entry->epte;
> > You should follow the code and see what uses old_entry and you'll see
> > that within the function old_entry->mfn is used (your diff changes the
> > line that uses it) and ept_free_entry also accesses mfn.
> 
> I will fix that.
> 
> > - are you sure you can move the ept_sync_domain call past the iommu code?
> >
> 
> I was hoping Tim would give me feedback about that.

I'm afraid I won't be able to review this code until next week.  This
change is already too late for the 4.2 freeze, though, so there's plenty
of time to get it right after we branch.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:48:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:48:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgqz-0003iq-8v; Fri, 27 Apr 2012 08:48:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNgqx-0003ii-RC
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 08:48:35 +0000
Received: from [85.158.143.99:43958] by server-1.bemta-4.messagelabs.com id
	04/E9-20925-36D5A9F4; Fri, 27 Apr 2012 08:48:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335516514!14316739!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6479 invoked from network); 27 Apr 2012 08:48:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 08:48:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNgqu-000MPQ-Rh; Fri, 27 Apr 2012 08:48:32 +0000
Date: Fri, 27 Apr 2012 09:48:32 +0100
From: Tim Deegan <tim@xen.org>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <20120427084832.GA86045@ocelot.phlegethon.org>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Christian.Limpach@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
	type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:36 -0700 on 26 Apr (1335465381), Aravindh Puthiyaparambil wrote:
> > - this is wrong:
> > > -        old_entry = *ept_entry;
> > > +        old_entry->epte = ept_entry->epte;
> > You should follow the code and see what uses old_entry and you'll see
> > that within the function old_entry->mfn is used (your diff changes the
> > line that uses it) and ept_free_entry also accesses mfn.
> 
> I will fix that.
> 
> > - are you sure you can move the ept_sync_domain call past the iommu code?
> >
> 
> I was hoping Tim would give me feedback about that.

I'm afraid I won't be able to review this code until next week.  This
change is already too late for the 4.2 freeze, though, so there's plenty
of time to get it right after we branch.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:52:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgu3-0003xY-U0; Fri, 27 Apr 2012 08:51:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNgu2-0003xM-9a
	for Xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:51:46 +0000
Received: from [85.158.143.35:47412] by server-2.bemta-4.messagelabs.com id
	F1/55-17550-12E5A9F4; Fri, 27 Apr 2012 08:51:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335516704!14257581!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3946 invoked from network); 27 Apr 2012 08:51:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 08:51:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNgtx-000MQR-Se; Fri, 27 Apr 2012 08:51:41 +0000
Date: Fri, 27 Apr 2012 09:51:41 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120427085141.GB86045@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
	<20120426111848.34e43e75@mantra.us.oracle.com>
	<20120426195712.GG67043@ocelot.phlegethon.org>
	<20120426185605.48f27816@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120426185605.48f27816@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:56 -0700 on 26 Apr (1335466565), Mukesh Rathor wrote:
> The tools get an array of the PV domU mfn's. Next to build pagetables, it
> needs to map them. It does via privcmd. I generate needed pfn space (not
> virtual address space) via ballooning. Next I need to map each pfn to 
> the domU mfns. This is a pv guest being built. So, these are mfns' that
> don't need looking up.

I'm sorry, my brain was addled from staring at spinlock code too long.
Of course, since the domU is PV you already have MFNs. 

In that case, I can't think of any obvious reasons for the failure.
you'll just have to dig a bit further -- see exactly which entry it's
complaining about, whether it matches what the dom0 tools thought they
put there, and what you would expect to be there.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:52:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgu3-0003xY-U0; Fri, 27 Apr 2012 08:51:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNgu2-0003xM-9a
	for Xen-devel@lists.xensource.com; Fri, 27 Apr 2012 08:51:46 +0000
Received: from [85.158.143.35:47412] by server-2.bemta-4.messagelabs.com id
	F1/55-17550-12E5A9F4; Fri, 27 Apr 2012 08:51:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335516704!14257581!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3946 invoked from network); 27 Apr 2012 08:51:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 08:51:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNgtx-000MQR-Se; Fri, 27 Apr 2012 08:51:41 +0000
Date: Fri, 27 Apr 2012 09:51:41 +0100
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120427085141.GB86045@ocelot.phlegethon.org>
References: <20120413182952.504e2775@mantra.us.oracle.com>
	<20120419141527.GB23663@ocelot.phlegethon.org>
	<20120423183709.5636656f@mantra.us.oracle.com>
	<20120424093626.GC34721@ocelot.phlegethon.org>
	<20120424160643.531daf88@mantra.us.oracle.com>
	<20120426090847.GA67043@ocelot.phlegethon.org>
	<20120426111848.34e43e75@mantra.us.oracle.com>
	<20120426195712.GG67043@ocelot.phlegethon.org>
	<20120426185605.48f27816@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120426185605.48f27816@mantra.us.oracle.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [hybrid]: code review for function mapping pfn to
	foreign mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:56 -0700 on 26 Apr (1335466565), Mukesh Rathor wrote:
> The tools get an array of the PV domU mfn's. Next to build pagetables, it
> needs to map them. It does via privcmd. I generate needed pfn space (not
> virtual address space) via ballooning. Next I need to map each pfn to 
> the domU mfns. This is a pv guest being built. So, these are mfns' that
> don't need looking up.

I'm sorry, my brain was addled from staring at spinlock code too long.
Of course, since the domU is PV you already have MFNs. 

In that case, I can't think of any obvious reasons for the failure.
you'll just have to dig a bit further -- see exactly which entry it's
complaining about, whether it matches what the dom0 tools thought they
put there, and what you would expect to be there.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgxT-000497-Iy; Fri, 27 Apr 2012 08:55:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNgxR-00048x-Iv
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 08:55:17 +0000
Received: from [85.158.143.35:65476] by server-3.bemta-4.messagelabs.com id
	93/D4-05853-4FE5A9F4; Fri, 27 Apr 2012 08:55:16 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335516914!13194741!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6762 invoked from network); 27 Apr 2012 08:55:15 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 08:55:15 -0000
Received: by obbwd18 with SMTP id wd18so964552obb.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 01:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=H4u+iBbCA/gaujwWvY50gt46+RC9rpqMGtwYKtxVX2U=;
	b=ZaS3lBetvjRq5i6lFFx3S+rmnZWlElKGDJQWbyDMpdQBDQq+JNJ7cAQax9knJbXA0E
	2hvLcqDWfxa/8Z/rqI7/W/pzbUC2RPOttPS5/SEmCdGjBnNyA3dxWfyie6lMGL2gy6iu
	HYtJjh17gKtu5oQfWoRPOmI99bT2bVKdmW0yFfpdnfWEmUNbP+N6DcI+U2O/6a59go+U
	ebhAeHpbLDcPWPJGwc0yNjIH18qGs/H5mEHnDokmekbtrT+8+axnG9t946W1s+XOxF/y
	KODzNehuk+raeilp5sEztairrICxpONRUx8LP1QhY9vZPEdjaKs3YehYyxG81CfqGNg9
	W4/A==
MIME-Version: 1.0
Received: by 10.182.111.3 with SMTP id ie3mr13280288obb.14.1335516913319; Fri,
	27 Apr 2012 01:55:13 -0700 (PDT)
Received: by 10.182.29.169 with HTTP; Fri, 27 Apr 2012 01:55:13 -0700 (PDT)
In-Reply-To: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
References: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
Date: Fri, 27 Apr 2012 09:55:13 +0100
X-Google-Sender-Auth: De2xgZtkMoIcB5cUo-Fl_SZZFR4
Message-ID: <CAFLBxZYpBuy-3mq0U4H46jreH0G0E4Rvi-OP1sxmakxdaCgrVA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: wang zhihao <accept.acm@gmail.com>,
	=?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to avoid this error "bits/predefs.h No such
 file or directory" when compiling XEN?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 2:09 PM, wang zhihao <accept.acm@gmail.com> wrote:
> Hi , All
>
> I try to compile xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on
> ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal error:
> bits/predefs.h No such file or directory". I wonder it's a thing related to
> 32bits and 64bits. How to solve this problem? Thank you.

I had the same problem; it appears that tgcbios needs a 32-bit libc to
compile in 32 bits (full error message below).  This solved it for me:

sudo apt-get install libc6-dev-i386

We should probably add that to one of the compile-time checks.  Roger,
do you have time to add that in?

Wang: BTW, in the future it's helpful to include more of the
compilation than just the final error message.

 -George

make -C tcgbios all
make[10]: Entering directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios'
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
-mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-exceptions
-fno-builtin -msoft-float
-I/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
-I.. -I../..  -c -o tcgbios.o tcgbios.c
In file included from /usr/include/stdint.h:26:0,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include/stdint.h:3,
                 from ../rombios_compat.h:8,
                 from tcgbios.c:24:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such
file or directory
compilation terminated.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 08:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 08:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNgxT-000497-Iy; Fri, 27 Apr 2012 08:55:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SNgxR-00048x-Iv
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 08:55:17 +0000
Received: from [85.158.143.35:65476] by server-3.bemta-4.messagelabs.com id
	93/D4-05853-4FE5A9F4; Fri, 27 Apr 2012 08:55:16 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1335516914!13194741!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6762 invoked from network); 27 Apr 2012 08:55:15 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 08:55:15 -0000
Received: by obbwd18 with SMTP id wd18so964552obb.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 01:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=H4u+iBbCA/gaujwWvY50gt46+RC9rpqMGtwYKtxVX2U=;
	b=ZaS3lBetvjRq5i6lFFx3S+rmnZWlElKGDJQWbyDMpdQBDQq+JNJ7cAQax9knJbXA0E
	2hvLcqDWfxa/8Z/rqI7/W/pzbUC2RPOttPS5/SEmCdGjBnNyA3dxWfyie6lMGL2gy6iu
	HYtJjh17gKtu5oQfWoRPOmI99bT2bVKdmW0yFfpdnfWEmUNbP+N6DcI+U2O/6a59go+U
	ebhAeHpbLDcPWPJGwc0yNjIH18qGs/H5mEHnDokmekbtrT+8+axnG9t946W1s+XOxF/y
	KODzNehuk+raeilp5sEztairrICxpONRUx8LP1QhY9vZPEdjaKs3YehYyxG81CfqGNg9
	W4/A==
MIME-Version: 1.0
Received: by 10.182.111.3 with SMTP id ie3mr13280288obb.14.1335516913319; Fri,
	27 Apr 2012 01:55:13 -0700 (PDT)
Received: by 10.182.29.169 with HTTP; Fri, 27 Apr 2012 01:55:13 -0700 (PDT)
In-Reply-To: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
References: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
Date: Fri, 27 Apr 2012 09:55:13 +0100
X-Google-Sender-Auth: De2xgZtkMoIcB5cUo-Fl_SZZFR4
Message-ID: <CAFLBxZYpBuy-3mq0U4H46jreH0G0E4Rvi-OP1sxmakxdaCgrVA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: wang zhihao <accept.acm@gmail.com>,
	=?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to avoid this error "bits/predefs.h No such
 file or directory" when compiling XEN?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 2:09 PM, wang zhihao <accept.acm@gmail.com> wrote:
> Hi , All
>
> I try to compile xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on
> ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal error:
> bits/predefs.h No such file or directory". I wonder it's a thing related to
> 32bits and 64bits. How to solve this problem? Thank you.

I had the same problem; it appears that tgcbios needs a 32-bit libc to
compile in 32 bits (full error message below).  This solved it for me:

sudo apt-get install libc6-dev-i386

We should probably add that to one of the compile-time checks.  Roger,
do you have time to add that in?

Wang: BTW, in the future it's helpful to include more of the
compilation than just the final error message.

 -George

make -C tcgbios all
make[10]: Entering directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios'
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
-mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-exceptions
-fno-builtin -msoft-float
-I/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
-I.. -I../..  -c -o tcgbios.o tcgbios.c
In file included from /usr/include/stdint.h:26:0,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include/stdint.h:3,
                 from ../rombios_compat.h:8,
                 from tcgbios.c:24:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such
file or directory
compilation terminated.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:03:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNh5G-0004Oo-I4; Fri, 27 Apr 2012 09:03:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNh5D-0004Oj-Eg
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:03:21 +0000
Received: from [85.158.138.51:61303] by server-10.bemta-3.messagelabs.com id
	88/5A-29478-6D06A9F4; Fri, 27 Apr 2012 09:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335517397!24121295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10552 invoked from network); 27 Apr 2012 09:03:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12171730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 09:03:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:03:16 +0100
Message-ID: <1335517395.28015.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Fri, 27 Apr 2012 10:03:15 +0100
In-Reply-To: <CAFLBxZYpBuy-3mq0U4H46jreH0G0E4Rvi-OP1sxmakxdaCgrVA@mail.gmail.com>
References: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
	<CAFLBxZYpBuy-3mq0U4H46jreH0G0E4Rvi-OP1sxmakxdaCgrVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: wang zhihao <accept.acm@gmail.com>, xen-devel <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] How to avoid this error "bits/predefs.h No such
 file or directory" when compiling XEN?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 09:55 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 2:09 PM, wang zhihao <accept.acm@gmail.com> wrote:
> > Hi , All
> >
> > I try to compile xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on
> > ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal error:
> > bits/predefs.h No such file or directory". I wonder it's a thing related to
> > 32bits and 64bits. How to solve this problem? Thank you.
> 
> I had the same problem; it appears that tgcbios needs a 32-bit libc to
> compile in 32 bits (full error message below).  This solved it for me:

What is tgcbios?

> sudo apt-get install libc6-dev-i386
> 
> We should probably add that to one of the compile-time checks.  Roger,
> do you have time to add that in?

Also please add it to the dependencies in the README.

> 
> Wang: BTW, in the future it's helpful to include more of the
> compilation than just the final error message.
> 
>  -George
> 
> make -C tcgbios all
> make[10]: Entering directory
> `/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios'
> gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g
> -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> -Wdeclaration-after-statement -Wno-unused-but-set-variable
> -D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d  -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
> -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-exceptions
> -fno-builtin -msoft-float
> -I/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
> -I.. -I../..  -c -o tcgbios.o tcgbios.c
> In file included from /usr/include/stdint.h:26:0,
>                  from /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include/stdint.h:3,
>                  from ../rombios_compat.h:8,
>                  from tcgbios.c:24:
> /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such
> file or directory
> compilation terminated.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:03:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNh5G-0004Oo-I4; Fri, 27 Apr 2012 09:03:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNh5D-0004Oj-Eg
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:03:21 +0000
Received: from [85.158.138.51:61303] by server-10.bemta-3.messagelabs.com id
	88/5A-29478-6D06A9F4; Fri, 27 Apr 2012 09:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335517397!24121295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10552 invoked from network); 27 Apr 2012 09:03:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12171730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 09:03:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:03:16 +0100
Message-ID: <1335517395.28015.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Fri, 27 Apr 2012 10:03:15 +0100
In-Reply-To: <CAFLBxZYpBuy-3mq0U4H46jreH0G0E4Rvi-OP1sxmakxdaCgrVA@mail.gmail.com>
References: <93F12F72-659C-48CD-9E3C-886A2C48353C@gmail.com>
	<CAFLBxZYpBuy-3mq0U4H46jreH0G0E4Rvi-OP1sxmakxdaCgrVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: wang zhihao <accept.acm@gmail.com>, xen-devel <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] How to avoid this error "bits/predefs.h No such
 file or directory" when compiling XEN?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 09:55 +0100, George Dunlap wrote:
> On Thu, Apr 26, 2012 at 2:09 PM, wang zhihao <accept.acm@gmail.com> wrote:
> > Hi , All
> >
> > I try to compile xen-unstable.hg(25249:a4e7fce6ee2b) from source repo on
> > ubuntu11.10-amd64. It complains "/usr/include/features.h:323:26 fatal error:
> > bits/predefs.h No such file or directory". I wonder it's a thing related to
> > 32bits and 64bits. How to solve this problem? Thank you.
> 
> I had the same problem; it appears that tgcbios needs a 32-bit libc to
> compile in 32 bits (full error message below).  This solved it for me:

What is tgcbios?

> sudo apt-get install libc6-dev-i386
> 
> We should probably add that to one of the compile-time checks.  Roger,
> do you have time to add that in?

Also please add it to the dependencies in the README.

> 
> Wang: BTW, in the future it's helpful to include more of the
> compilation than just the final error message.
> 
>  -George
> 
> make -C tcgbios all
> make[10]: Entering directory
> `/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios'
> gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g
> -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> -Wdeclaration-after-statement -Wno-unused-but-set-variable
> -D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d  -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
> -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-exceptions
> -fno-builtin -msoft-float
> -I/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
> -I.. -I../..  -c -o tcgbios.o tcgbios.c
> In file included from /usr/include/stdint.h:26:0,
>                  from /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include/stdint.h:3,
>                  from ../rombios_compat.h:8,
>                  from tcgbios.c:24:
> /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such
> file or directory
> compilation terminated.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNh9z-0004Wj-9A; Fri, 27 Apr 2012 09:08:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNh9y-0004WZ-3E
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 09:08:14 +0000
Received: from [193.109.254.147:34729] by server-1.bemta-14.messagelabs.com id
	2A/77-29372-DF16A9F4; Fri, 27 Apr 2012 09:08:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335517690!6586992!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 27 Apr 2012 09:08:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:08:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12171867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 09:08:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:08:09 +0100
Message-ID: <1335517688.28015.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 27 Apr 2012 10:08:08 +0100
In-Reply-To: <4F9A5C79.2090604@eu.citrix.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 09:44 +0100, George Dunlap wrote:
> On 27/04/12 09:21, Dieter Bloms wrote:
> > yes, this is an issue with my patch :( All default values has to be 0, 
> > but only for the credit(2) scheduler cpu_weight must not. So I made a 
> > patch, which set a default of 256 when the cpu_weight isn't set and 
> > credit(2) is used and let it 0 when the scheduler sedf is used. Please 
> > try the attached patch and see if it solve this issue. 
> Dieter,
> 
> Thanks for the patch.  However, I'd really rather avoid putting 
> scheduler defaults in xl if we can at all avoid it.  Defaults should be 
> set in one place, and that should be in the scheduling code itself.
> 
> I think what we really want to do is is any of the parameters are set, 
> after the domain is first created, to read the scheduling parameters for 
> the domain (which will be the defaults), change the ones that are set in 
> the config file, and then write the whole structure back.  That 
> shouldn't be too hard, as libxl__sched_set_params() is called after the 
> domain itself is created;

I guess the low level libxl_sched_*_params_set should take care of this?

>  the main thing is how to tell 
> libxl__sched_set_params() which parameters actually need to be set, and 
> which should be left alone.

Do all of the fields have a spare discriminating value which could mean
"the default". Ideally it would be zero but it doesn't have to be.
Otherwise we can adjust the libxl API to make one available (usually ~0
or similar), the IDL can express these sorts of concepts (see the uses
of init_val).

It may be appropriate to add a libxl__sched_FOO_domain__setdefaults,
which params_set could call to fully initialise the struct (by calling
get...)

> Are you up for doing that?  If not, I can put it on my to-do list.
> 
> Thanks,
>   -George
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNh9z-0004Wj-9A; Fri, 27 Apr 2012 09:08:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNh9y-0004WZ-3E
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 09:08:14 +0000
Received: from [193.109.254.147:34729] by server-1.bemta-14.messagelabs.com id
	2A/77-29372-DF16A9F4; Fri, 27 Apr 2012 09:08:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335517690!6586992!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 27 Apr 2012 09:08:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:08:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12171867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 09:08:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:08:09 +0100
Message-ID: <1335517688.28015.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 27 Apr 2012 10:08:08 +0100
In-Reply-To: <4F9A5C79.2090604@eu.citrix.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 09:44 +0100, George Dunlap wrote:
> On 27/04/12 09:21, Dieter Bloms wrote:
> > yes, this is an issue with my patch :( All default values has to be 0, 
> > but only for the credit(2) scheduler cpu_weight must not. So I made a 
> > patch, which set a default of 256 when the cpu_weight isn't set and 
> > credit(2) is used and let it 0 when the scheduler sedf is used. Please 
> > try the attached patch and see if it solve this issue. 
> Dieter,
> 
> Thanks for the patch.  However, I'd really rather avoid putting 
> scheduler defaults in xl if we can at all avoid it.  Defaults should be 
> set in one place, and that should be in the scheduling code itself.
> 
> I think what we really want to do is is any of the parameters are set, 
> after the domain is first created, to read the scheduling parameters for 
> the domain (which will be the defaults), change the ones that are set in 
> the config file, and then write the whole structure back.  That 
> shouldn't be too hard, as libxl__sched_set_params() is called after the 
> domain itself is created;

I guess the low level libxl_sched_*_params_set should take care of this?

>  the main thing is how to tell 
> libxl__sched_set_params() which parameters actually need to be set, and 
> which should be left alone.

Do all of the fields have a spare discriminating value which could mean
"the default". Ideally it would be zero but it doesn't have to be.
Otherwise we can adjust the libxl API to make one available (usually ~0
or similar), the IDL can express these sorts of concepts (see the uses
of init_val).

It may be appropriate to add a libxl__sched_FOO_domain__setdefaults,
which params_set could call to fully initialise the struct (by calling
get...)

> Are you up for doing that?  If not, I can put it on my to-do list.
> 
> Thanks,
>   -George
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:21:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:21:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhM2-0004jN-Ib; Fri, 27 Apr 2012 09:20:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SNhM0-0004jI-G6
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:20:40 +0000
Received: from [85.158.138.51:62209] by server-3.bemta-3.messagelabs.com id
	32/3E-04048-7E46A9F4; Fri, 27 Apr 2012 09:20:39 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335518438!16154845!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1ODM3MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 27 Apr 2012 09:20:38 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:20:38 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=OZus/PqjD6IWzytKDLNomR+ckVekDEXtz2v2WsePKow34nvSWR02xpRA
	MX7DgNLzK8Ofx3oPMg/OSpwHrCbxMlUdV68xBCBgGubtwP0JYTXCA27hf
	bnbkKZh1zp8IsXRFjuBPZvZfRWhxi0zbvLMkblp1QwgE3Fii/MCeNYcPF
	vOXAYYvhtY/4wnRTQ3jqfUj3JsE5Wl5OgR9rVnkOXjgng33uEYYcC99A8
	GB0cQYWu+RsMSlbc9jIQM2dZN2PP2;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1335518439; x=1367054439;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=nhC7iBtYTKxpLIzT/4nJe0dV/yQNyN0z6qMwSTUX910=;
	b=jP/teVvSiQyup2RFqhBak4rgK4SzN6hG+OhKSMFMfE1HLQtoYM7Bjo8T
	WoJ5Dp6OZBTlBd3Q5B0SE5jkV0TOXMtdiFUNH40a30ohc0b3OUe4J94SO
	rZ72jst93l3QLjqOwySpERYQCEHILzh4VzsrXJViPr7hRoG1pQhXKSTm+
	YD8dJHZKqKL2FceDQCyNnRH4x3h5bCG1MpdKGBjB/mYgI58AJT0UOxzLL
	/DA5DLzXmkQkYdyDHIcbrJAm0m4NY;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="92286643"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 27 Apr 2012 11:20:38 +0200
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="133216057"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 27 Apr 2012 11:20:38 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 2397E95B15D
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:20:38 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 27 Apr 2012 11:20:37 +0200
Message-ID: <95424045.BJ4a0xs4Vr@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] docs: add vpmu description to
	xen-command-line.markdown
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
# Date 1335517766 -7200
# Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565
# Parent  107285938c50f82667bd4d014820b439a077c22c

Add a short description to the vpmu boot option in the
xen-command-line.markdown


Signed-off-by:  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


diff -r 107285938c50 docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown	Thu Apr 26 10:03:08 2012 +0100
+++ b/docs/misc/xen-command-line.markdown	Fri Apr 27 11:09:26 2012 +0200
@@ -543,7 +543,28 @@ console even after dom0 has been started
 relinquish control to dom0.
 
 ### vpid
+
 ### vpmu
+> `= ( bts )`
+
+> Default: `off`
+
+Switch on the virtualized performance monitoring unit for HVM guests.
+
+If the current cpu isn't supported a message like  
+'VPMU: Initialization failed. ...'  
+is printed on the hypervisor serial log.
+
+For some Intel Nehalem processors a quirk handling exist for an unknown
+wrong behaviour (see handle_pmc_quirk()).
+
+If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
+feature is switched on on Intel processors supporting this feature.
+
+*Warning:*
+As the BTS virtualisation is not 100% safe and because of the nehalem quirk
+don't use the vpmu flag on production systems with Intel cpus!
+
 ### vti\_vhpt\_size
 ### vti\_vtlb\_size
 ### watchdog


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:21:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:21:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhM2-0004jN-Ib; Fri, 27 Apr 2012 09:20:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SNhM0-0004jI-G6
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:20:40 +0000
Received: from [85.158.138.51:62209] by server-3.bemta-3.messagelabs.com id
	32/3E-04048-7E46A9F4; Fri, 27 Apr 2012 09:20:39 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335518438!16154845!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1ODM3MQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 27 Apr 2012 09:20:38 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:20:38 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=OZus/PqjD6IWzytKDLNomR+ckVekDEXtz2v2WsePKow34nvSWR02xpRA
	MX7DgNLzK8Ofx3oPMg/OSpwHrCbxMlUdV68xBCBgGubtwP0JYTXCA27hf
	bnbkKZh1zp8IsXRFjuBPZvZfRWhxi0zbvLMkblp1QwgE3Fii/MCeNYcPF
	vOXAYYvhtY/4wnRTQ3jqfUj3JsE5Wl5OgR9rVnkOXjgng33uEYYcC99A8
	GB0cQYWu+RsMSlbc9jIQM2dZN2PP2;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1335518439; x=1367054439;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=nhC7iBtYTKxpLIzT/4nJe0dV/yQNyN0z6qMwSTUX910=;
	b=jP/teVvSiQyup2RFqhBak4rgK4SzN6hG+OhKSMFMfE1HLQtoYM7Bjo8T
	WoJ5Dp6OZBTlBd3Q5B0SE5jkV0TOXMtdiFUNH40a30ohc0b3OUe4J94SO
	rZ72jst93l3QLjqOwySpERYQCEHILzh4VzsrXJViPr7hRoG1pQhXKSTm+
	YD8dJHZKqKL2FceDQCyNnRH4x3h5bCG1MpdKGBjB/mYgI58AJT0UOxzLL
	/DA5DLzXmkQkYdyDHIcbrJAm0m4NY;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="92286643"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 27 Apr 2012 11:20:38 +0200
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="133216057"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 27 Apr 2012 11:20:38 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 2397E95B15D
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:20:38 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 27 Apr 2012 11:20:37 +0200
Message-ID: <95424045.BJ4a0xs4Vr@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] docs: add vpmu description to
	xen-command-line.markdown
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
# Date 1335517766 -7200
# Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565
# Parent  107285938c50f82667bd4d014820b439a077c22c

Add a short description to the vpmu boot option in the
xen-command-line.markdown


Signed-off-by:  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


diff -r 107285938c50 docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown	Thu Apr 26 10:03:08 2012 +0100
+++ b/docs/misc/xen-command-line.markdown	Fri Apr 27 11:09:26 2012 +0200
@@ -543,7 +543,28 @@ console even after dom0 has been started
 relinquish control to dom0.
 
 ### vpid
+
 ### vpmu
+> `= ( bts )`
+
+> Default: `off`
+
+Switch on the virtualized performance monitoring unit for HVM guests.
+
+If the current cpu isn't supported a message like  
+'VPMU: Initialization failed. ...'  
+is printed on the hypervisor serial log.
+
+For some Intel Nehalem processors a quirk handling exist for an unknown
+wrong behaviour (see handle_pmc_quirk()).
+
+If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
+feature is switched on on Intel processors supporting this feature.
+
+*Warning:*
+As the BTS virtualisation is not 100% safe and because of the nehalem quirk
+don't use the vpmu flag on production systems with Intel cpus!
+
 ### vti\_vhpt\_size
 ### vti\_vtlb\_size
 ### watchdog


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:24:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhP0-0004r8-BE; Fri, 27 Apr 2012 09:23:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNhOz-0004r3-2Y
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 09:23:45 +0000
Received: from [193.109.254.147:16102] by server-11.bemta-14.messagelabs.com
	id 75/38-05858-0A56A9F4; Fri, 27 Apr 2012 09:23:44 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335518622!6590392!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22306 invoked from network); 27 Apr 2012 09:23:43 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 09:23:43 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNhOv-0002d6-Ft
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 02:23:41 -0700
Date: Fri, 27 Apr 2012 02:23:41 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335518621483-5669805.post@n5.nabble.com>
In-Reply-To: <CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Clpob3UgUGVuZyB3cm90ZQo+IAo+IEhpIEZhbnR1LAo+IAo+IFRoYW5rcyBmb3IgeW91ciByZXNw
b25zZS4KPiAKPiB4bCBkb2Vzbid0IHN1cHBvcnQgcXhsLXJlbGF0ZWQgb3B0aW9uIGF0IHRoZSBt
b21lbnQuCj4gSSB3aWxsIHRlc3QgdXBzdHJlYW0tcWVtdS14ZW4gdGhlc2UgZGF5cywgYW5kIGlm
IGl0IHdvcmtzIHdlbGwKPiB3aXRoIHF4bCBkZXZpY2UsIEkgd2lsbCBiZSBnbGFkIHRvIGFkZCBx
eGwgc3VwcG9ydCB0byB4bC4KPiAKPiBCZXN0LAo+IAo+IE9uIFRodSwgQXByIDI2LCAyMDEyIGF0
IDExOjM5IFBNLCBJYW4gQ2FtcGJlbGwgJmx0O0lhbi5DYW1wYmVsbEAmZ3Q7Cj4gd3JvdGU6Cj4+
IENDaW5nIFpob3UgUGVuZyB3aG8gb3JpZ2luYWxseSBhZGRlZCBzcGljZSBzdXBwb3J0IHRvIHhs
LiBaaG91LCBhcmUgeW91Cj4+IGludGVyZXN0ZWQgaW4gc3VwcG9ydGluZyB0aGlzIGZlYXR1cmU/
Cj4+Cj4+IE9uIFRodSwgMjAxMi0wNC0yNiBhdCAxNjoyMyArMDEwMCwgRmFudHUgd3JvdGU6Cj4+
PiBEb20wOgo+Pj4gV2hlZXp5IDY0IGJpdCB3aXRoIGtlcm5lbCBmcm9tIHBhY2thZ2UgbGludXgt
aW1hZ2UtMy4yLjAtMi1hbWQ2NCB2ZXJzaW9uCj4+PiAzLjIuMTUtMSwgcGFja2FnZSBibGt0YXAt
ZGttcyBhbmQgYWxsIGRlcGVuZGVuY3kgcGFja2FnZXMgZm9yIHhlbiwgc3BpY2UKPj4+IGFuZAo+
Pj4gdXNiIHJlZGlyZWN0aW9uLgo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gL2V0
Yy9tb2R1bGVzCj4+PiAtLS0tLS0tLS0tLS0KPj4+IGxvb3AgbWF4X2xvb3A9NjQKPj4+IHhlbmZz
Cj4+PiB4ZW4tZXZ0Y2huCj4+PiBibGt0YXAKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
Pj4+IGhnIGNsb25lIGh0dHA6Ly94ZW5iaXRzLnhlbi5vcmcveGVuLXVuc3RhYmxlLmhnIChpbiB0
aGlzIGJ1aWxkIGNoYW5nZXNldAo+Pj4gaXMKPj4+IDI1MjQ5OmE0ZTdmY2U2ZWUyYikKPj4+IHZp
IE1ha2VmaWxlICMgcmVtb3ZlZCBkaXN0LWtlcm5lbCB0byBub3QgY29tcGlsZSBrZXJuZWwKPj4+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IHZpIENvbmZpZy5tayAjIHFlbXUgdXBzdHJl
YW0gdW5zdGFibGUgYW5kIHNlYWJpb3MgdXBzdHJlYW0gdW5zdGFibGUgZm9yCj4+PiB2YXJpb3Vz
IHNwaWNlIGFuZCBxeGwgYnVnZml4Cj4+PiAtLS0tLS0tLS0tLS0KPj4+IFFFTVVfVVBTVFJFQU1f
VVJMID89IGdpdDovL2dpdC5xZW11Lm9yZy9xZW11LmdpdAo+Pj4gU0VBQklPU19VUFNUUkVBTV9V
UkwgPz0gZ2l0Oi8vZ2l0LnNlYWJpb3Mub3JnL3NlYWJpb3MuZ2l0Cj4+PiBTRUFCSU9TX1VQU1RS
RUFNX1RBRyA/PSByZWwtMS43LjAKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IEFk
ZGVkIHNvbWUgcGF0Y2hlczoKPj4+IC0gYXV0b2NvbmY6IGFkZCB2YXJpYWJsZSBmb3IgcGFzcyBh
cmJpdHJhcnkgb3B0aW9ucyB0byBxZW11IHVwc3RyZWFtIHYzCj4+PiAtIHRvb2xzOiBJbXByb3Zl
IG1ha2UgZGViCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+PiAuL2NvbmZpZ3VyZSAt
LWVuYWJsZS1xZW11dS1zcGljZSAtLWVuYWJsZS1xZW11dS11c2JyZWRpcgo+Pj4gLS1lbmFibGUt
cWVtdXUtZGVidWcKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IG1ha2UgZGViCj4+
Pgo+Pj4gVGVzdGVkIGl0IG9uIFdpbmRvd3MgWFAgZG9tVSB3aXRoIHRoaXMgeGwgY29uZmlndXJh
dGlvbiBmaWxlOgo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gWFAuY2Zn
Cj4+PiAtLS0tLS0tLS0KPj4+IG5hbWU9J1hQJwo+Pj4gYnVpbGRlcj0iaHZtIgo+Pj4gbWVtb3J5
PTEwMjQKPj4+IHZjcHVzPTIKPj4+IGhhcD0xCj4+PiBwYWU9MQo+Pj4gYWNwaT0xCj4+PiBhcGlj
PTEKPj4+IG54PTEKPj4+IHZpZj1bJ2JyaWRnZT14ZW5icjAnXQo+Pj4gI3ZmYj1bJ3ZuYz0xLHZu
Y3VudXNlZD0xLHZuY2xpc3Rlbj0wLjAuMC4wLGtleW1hcD1pdCddCj4+PiAjZGlzaz1bJy9tbnQv
dm0vZGlza3MvWFAuZGlzazEueG0scmF3LGhkYSxydycsJyxyYXcsaGRiLHJvLGNkcm9tJ10KPj4+
IGRpc2s9WycvbW50L3ZtL2Rpc2tzL1hQLmRpc2sxLnhtLHJhdyxoZGEscncnXQo+Pj4gYm9vdD0n
Y2QnCj4+PiB4ZW5fcGxhdGZvcm1fcGNpPTEKPj4+IHZpcmlkaWFuPTEKPj4+IGRldmljZV9tb2Rl
bF92ZXJzaW9uPSJxZW11LXhlbiIKPj4+ICNkZXZpY2VfbW9kZWxfb3ZlcnJpZGU9Ii91c3IvbGli
L3hlbi9iaW4vcWVtdS1kZWJ1Zy5zaCIKPj4+ICN2bmM9MQo+Pj4gI3ZuY3VudXNlZD0xCj4+PiAj
dm5jbGlzdGVuPSIwLjAuMC4wIgo+Pj4gI2tleW1hcD0iaXQiCj4+PiBzcGljZT0xCj4+PiBzcGlj
ZWhvc3Q9IjAuMC4wLjAiCj4+PiBzcGljZXBvcnQ9NjAwMAo+Pj4gc3BpY2VkaXNhYmxlX3RpY2tl
dGluZz0xCj4+PiBvbl9wb3dlcm9mZj0iZGVzdHJveSIKPj4+IG9uX3JlYm9vdD0icmVzdGFydCIK
Pj4+IG9uX2NyYXNoPSJkZXN0cm95Igo+Pj4gc3RkdmdhPTEKPj4+ICNkZXZpY2VfbW9kZWxfYXJn
cz1bIi12Z2EgcXhsIC1nbG9iYWwgcXhsLXZnYS52cmFtX3NpemVfbWI9MTYiXQo+Pj4gI3ZpZGVv
cmFtPTEyOAo+Pj4gI2RldmljZV9tb2RlbF9hcmdzPVsiLXZnYSBxeGwiXQo+Pj4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gV2l0aCBzdGR2Z2Egb3B0aW9uIGRvbVUgaXMgd29y
a2luZyBidXQgZ3JhcGhpYyBwZXJmb3JtYW5jZSBpcyBwb29yIHdpdGgKPj4+IHNwaWNlLgo+Pj4K
Pj4+Cj4+PiBXaXRoIFFYTCB2Z2Egb3B0aW9uIGRvbVUKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KPj4+IHZpZGVvcmFtPTEyOAo+Pj4gZGV2aWNlX21vZGVsX2FyZ3M9WyItdmdh
IHF4bCJdCj4+PiBzdGR2Z2E9MAo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+
Pj4gRG9tVSBub3Qgc3RhcnQsIGZyb20gcWVtdSBsb2c6Cj4+PiBxZW11LXN5c3RlbS1pMzg2OiAt
dmdhIHF4bDogaW52YWxpZCBvcHRpb24KPj4+Cj4+PiBCdXQgdGhlIG9wdGlvbiBpcyBjb3JyZWN0
IGFuZCBpZiBJIGFkZDoKPj4+IGRldmljZV9tb2RlbF9vdmVycmlkZT0iL3Vzci9saWIveGVuL2Jp
bi9xZW11LWRlYnVnLnNoIgo+Pj4KPj4+IHFlbXUtZGVidWcuc2ggbGF1bmNoZXMgdGhlIHNhbWUg
cWVtdS1zeXN0ZW0taTM4NiB3aXRoIHNhbWUgb3B0aW9ucyBhbmQKPj4+IGRvbVUKPj4+IHN0YXJ0
cy4KPj4+IERvbVUgc2VlcyB0aGUgUVhMIHZnYSBidXQgb25seSB3aXRoIDQgbWIgYWxsb2NhdGVk
IGFuZC9vciB1c2FibGVkCj4+PiBpbnN0ZWFkIG9mCj4+PiA2NCBtYiBvZiBxZW11IGRlZmF1bHQu
Cj4+Pgo+Pj4gV2UgbmVlZCBkb21VcyB3aXRoIGdvb2QgZ3JhcGhpYyBwZXJmb3JtYW5jZSwgYWxz
byB3aXRoIGhpZ2ggcmVzb2x1dGlvbgo+Pj4gYW5kCj4+PiBhbHNvIG11bHRpbWVkaWEuCj4+PiBX
ZSBjYW4gbm90IHVzZSBnZnggcGFzc3Rocm91Z2ggb24gb3VyIGRvbTBzIGJlY2F1c2Ugb2YgaGFy
ZHdhcmUKPj4+IGxpbWl0YXRpb24KPj4+IG9mIGRlbGwgc2VydmVyLgo+Pj4gUVhMIHNlZW1zIHRv
IGJlIHRoZSBvbmx5IHdheSB0byBnby4KPj4+Cj4+PiBXZSBhcmUgdGVzdGluZyB0aGlzIHNldHVw
IHNldmVyYWwgbW9udGhzIHdpdGhvdXQgc3VjY2VzcyBvbiB4ZW4uCj4+PiBTb21lIGluaXRpYWwg
eGwgYW5kIHFlbXUgcmFtL3ZpZGVvcmFtIGJ1Z3MgYXJlIG5vdyBmaXhlZCBidXQgbWF5IGJlCj4+
PiB0aGVyZQo+Pj4gYXJlIG90aGVyIGluIHhlbiBub3QgZm91bmQgZm9yIG5vdy4KPj4+Cj4+PiBX
ZSBub3RpY2VkIG9uZSBwYXJ0aWN1bGFyIHRoaW5nOgo+Pj4KPj4+IHdpdGhvdXQgcXhsOgo+Pj4g
eGM6IGluZm86IFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+Pj4gwqAgTG9hZGVyOiDCoCDC
oCDCoCDCoDAwMDAwMDAwMDAxMDAwMDAtPjAwMDAwMDAwMDAxOWRjODgKPj4+IMKgIFRPVEFMOiDC
oCDCoCDCoCDCoCAwMDAwMDAwMDAwMDAwMDAwLT4wMDAwMDAwMDNmODAwMDAwCj4+PiDCoCBFTlRS
WSBBRERSRVNTOiAwMDAwMDAwMDAwMTAwMDAwCj4+Pgo+Pj4gd2l0aCBxeGw6Cj4+PiB4YzogaW5m
bzogVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4+PiDCoCBMb2FkZXI6IMKgIMKgIMKgIMKg
MDAwMDAwMDAwMDEwMDAwMC0+MDAwMDAwMDAwMDE5ZGM4OAo+Pj4gwqAgVE9UQUw6IMKgIMKgIMKg
IMKgIDAwMDAwMDAwMDAwMDAwMDAtPjAwMDAwMDAwMzgwMDAwMDAKPj4+IMKgIEVOVFJZIEFERFJF
U1M6IDAwMDAwMDAwMDAxMDAwMDAKPj4+Cj4+PiBUaGUgdG90YWwgbWVtb3J5IHdpdGggcXhsIHNo
b3VsZCBiZSBlcXVhbCBvciBtYWpvciB0aGFuIHRvdGFsIG1lbW9yeQo+Pj4gd2l0aG91dAo+Pj4g
cXhsLgo+Pj4gVGhlcmUgaXMgc29tZXRoaW5nIHdyb25nIGFib3V0IHZpZGVvcmFtLCBpIGRvbid0
IGtub3cgaWYgaW4geGwgb3Igb3RoZXIKPj4+IHBhcnQKPj4+IG9mIHhlbi4KPj4+Cj4+PiBQbGVh
c2Ugc29tZW9uZSBoZWxwIG1lIHRvIHNvbHZlIHRoaXMgcHJvYmxlbT8KPj4+Cj4+PiAtLQo+Pj4g
VmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDoKPj4+IGh0dHA6Ly94ZW4uMTA0NTcxMi5uNS5u
YWJibGUuY29tL1VuYWJsZS10by1nZXQtUVhMLXZnYS13b3JraW5nLXRwNTY2NzkxOXA1NjY3OTE5
Lmh0bWwKPj4+IFNlbnQgZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0
IE5hYmJsZS5jb20uCj4+Pgo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KPj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4+IFhlbi1kZXZlbEAueGVu
Cj4+PiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPj4KPj4KPj4KPj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+PiBYZW4tZGV2ZWxALnhlbgo+PiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwKPiAKPiAKPiAKPiAtLSAKPiBaaG91IFBlbmcKPiAKPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4t
ZGV2ZWxALnhlbgo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+IAoKClRoYW5rcyBm
b3IgcmVwbHksIGFib3V0IFFYTCBzb21lIHBhdGNoZXMgbmVlZCB0byBiZSBiYWNrcG9ydGVkIGZy
b20gcWVtdQp1cHN0cmVhbSB1bnN0YWJsZSB0byBxZW11IHVwc3RyZWFtIHhlbiwgbm93IEkgZG9u
J3Qga25vdyBleGFjdGx5IHdoaWNoIG9mCnRoZW0gc29sdmUgdGhlIGRvbVUgYm9vdCBwcm9ibGVt
IHdpdGggc3BpY2UgYW5kIHF4bCwgd2l0aCBxZW11IGFuZCBzZWFiaW9zCm9mIHhlbiAoMS4wLjEp
IGRvZXNuJ3Qgd29yayB3aGlsZSB3aXRoIHFlbXUgYW5kIHNlYWJpb3MgdW5zdGFibGUgaXQgZG9l
cy4KVGhlcmUgYXJlIGFsc28gc29tZSB2aWRlb3JhbSBidWcgb3IgcHJvYmxlbSBvbiB4ZW4sIHBy
b2JhYmx5IGJ1Z2ZpeC9wYXRjaAphcmUgbmVjZXNzYXJ5IGFsc28gb3V0c2lkZSBvZiBsaWJ4bCwg
SSB0cmllZCB0byBsb29rIGZvciB0aGUgcHJvYmxlbSBhbmQKc29sdmUgaXQgbXlzZWxmIGJ1dCBJ
IGRvbid0IGhhdmUgZW5vdWdoIGtub3dsZWRnZSBub3cuCgotLQpWaWV3IHRoaXMgbWVzc2FnZSBp
biBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9VbmFibGUtdG8tZ2V0
LVFYTC12Z2Etd29ya2luZy10cDU2Njc5MTlwNTY2OTgwNS5odG1sClNlbnQgZnJvbSB0aGUgWGVu
IC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:24:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhP0-0004r8-BE; Fri, 27 Apr 2012 09:23:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNhOz-0004r3-2Y
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 09:23:45 +0000
Received: from [193.109.254.147:16102] by server-11.bemta-14.messagelabs.com
	id 75/38-05858-0A56A9F4; Fri, 27 Apr 2012 09:23:44 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335518622!6590392!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22306 invoked from network); 27 Apr 2012 09:23:43 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 09:23:43 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNhOv-0002d6-Ft
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 02:23:41 -0700
Date: Fri, 27 Apr 2012 02:23:41 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335518621483-5669805.post@n5.nabble.com>
In-Reply-To: <CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Clpob3UgUGVuZyB3cm90ZQo+IAo+IEhpIEZhbnR1LAo+IAo+IFRoYW5rcyBmb3IgeW91ciByZXNw
b25zZS4KPiAKPiB4bCBkb2Vzbid0IHN1cHBvcnQgcXhsLXJlbGF0ZWQgb3B0aW9uIGF0IHRoZSBt
b21lbnQuCj4gSSB3aWxsIHRlc3QgdXBzdHJlYW0tcWVtdS14ZW4gdGhlc2UgZGF5cywgYW5kIGlm
IGl0IHdvcmtzIHdlbGwKPiB3aXRoIHF4bCBkZXZpY2UsIEkgd2lsbCBiZSBnbGFkIHRvIGFkZCBx
eGwgc3VwcG9ydCB0byB4bC4KPiAKPiBCZXN0LAo+IAo+IE9uIFRodSwgQXByIDI2LCAyMDEyIGF0
IDExOjM5IFBNLCBJYW4gQ2FtcGJlbGwgJmx0O0lhbi5DYW1wYmVsbEAmZ3Q7Cj4gd3JvdGU6Cj4+
IENDaW5nIFpob3UgUGVuZyB3aG8gb3JpZ2luYWxseSBhZGRlZCBzcGljZSBzdXBwb3J0IHRvIHhs
LiBaaG91LCBhcmUgeW91Cj4+IGludGVyZXN0ZWQgaW4gc3VwcG9ydGluZyB0aGlzIGZlYXR1cmU/
Cj4+Cj4+IE9uIFRodSwgMjAxMi0wNC0yNiBhdCAxNjoyMyArMDEwMCwgRmFudHUgd3JvdGU6Cj4+
PiBEb20wOgo+Pj4gV2hlZXp5IDY0IGJpdCB3aXRoIGtlcm5lbCBmcm9tIHBhY2thZ2UgbGludXgt
aW1hZ2UtMy4yLjAtMi1hbWQ2NCB2ZXJzaW9uCj4+PiAzLjIuMTUtMSwgcGFja2FnZSBibGt0YXAt
ZGttcyBhbmQgYWxsIGRlcGVuZGVuY3kgcGFja2FnZXMgZm9yIHhlbiwgc3BpY2UKPj4+IGFuZAo+
Pj4gdXNiIHJlZGlyZWN0aW9uLgo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gL2V0
Yy9tb2R1bGVzCj4+PiAtLS0tLS0tLS0tLS0KPj4+IGxvb3AgbWF4X2xvb3A9NjQKPj4+IHhlbmZz
Cj4+PiB4ZW4tZXZ0Y2huCj4+PiBibGt0YXAKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
Pj4+IGhnIGNsb25lIGh0dHA6Ly94ZW5iaXRzLnhlbi5vcmcveGVuLXVuc3RhYmxlLmhnIChpbiB0
aGlzIGJ1aWxkIGNoYW5nZXNldAo+Pj4gaXMKPj4+IDI1MjQ5OmE0ZTdmY2U2ZWUyYikKPj4+IHZp
IE1ha2VmaWxlICMgcmVtb3ZlZCBkaXN0LWtlcm5lbCB0byBub3QgY29tcGlsZSBrZXJuZWwKPj4+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IHZpIENvbmZpZy5tayAjIHFlbXUgdXBzdHJl
YW0gdW5zdGFibGUgYW5kIHNlYWJpb3MgdXBzdHJlYW0gdW5zdGFibGUgZm9yCj4+PiB2YXJpb3Vz
IHNwaWNlIGFuZCBxeGwgYnVnZml4Cj4+PiAtLS0tLS0tLS0tLS0KPj4+IFFFTVVfVVBTVFJFQU1f
VVJMID89IGdpdDovL2dpdC5xZW11Lm9yZy9xZW11LmdpdAo+Pj4gU0VBQklPU19VUFNUUkVBTV9V
UkwgPz0gZ2l0Oi8vZ2l0LnNlYWJpb3Mub3JnL3NlYWJpb3MuZ2l0Cj4+PiBTRUFCSU9TX1VQU1RS
RUFNX1RBRyA/PSByZWwtMS43LjAKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IEFk
ZGVkIHNvbWUgcGF0Y2hlczoKPj4+IC0gYXV0b2NvbmY6IGFkZCB2YXJpYWJsZSBmb3IgcGFzcyBh
cmJpdHJhcnkgb3B0aW9ucyB0byBxZW11IHVwc3RyZWFtIHYzCj4+PiAtIHRvb2xzOiBJbXByb3Zl
IG1ha2UgZGViCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+PiAuL2NvbmZpZ3VyZSAt
LWVuYWJsZS1xZW11dS1zcGljZSAtLWVuYWJsZS1xZW11dS11c2JyZWRpcgo+Pj4gLS1lbmFibGUt
cWVtdXUtZGVidWcKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IG1ha2UgZGViCj4+
Pgo+Pj4gVGVzdGVkIGl0IG9uIFdpbmRvd3MgWFAgZG9tVSB3aXRoIHRoaXMgeGwgY29uZmlndXJh
dGlvbiBmaWxlOgo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gWFAuY2Zn
Cj4+PiAtLS0tLS0tLS0KPj4+IG5hbWU9J1hQJwo+Pj4gYnVpbGRlcj0iaHZtIgo+Pj4gbWVtb3J5
PTEwMjQKPj4+IHZjcHVzPTIKPj4+IGhhcD0xCj4+PiBwYWU9MQo+Pj4gYWNwaT0xCj4+PiBhcGlj
PTEKPj4+IG54PTEKPj4+IHZpZj1bJ2JyaWRnZT14ZW5icjAnXQo+Pj4gI3ZmYj1bJ3ZuYz0xLHZu
Y3VudXNlZD0xLHZuY2xpc3Rlbj0wLjAuMC4wLGtleW1hcD1pdCddCj4+PiAjZGlzaz1bJy9tbnQv
dm0vZGlza3MvWFAuZGlzazEueG0scmF3LGhkYSxydycsJyxyYXcsaGRiLHJvLGNkcm9tJ10KPj4+
IGRpc2s9WycvbW50L3ZtL2Rpc2tzL1hQLmRpc2sxLnhtLHJhdyxoZGEscncnXQo+Pj4gYm9vdD0n
Y2QnCj4+PiB4ZW5fcGxhdGZvcm1fcGNpPTEKPj4+IHZpcmlkaWFuPTEKPj4+IGRldmljZV9tb2Rl
bF92ZXJzaW9uPSJxZW11LXhlbiIKPj4+ICNkZXZpY2VfbW9kZWxfb3ZlcnJpZGU9Ii91c3IvbGli
L3hlbi9iaW4vcWVtdS1kZWJ1Zy5zaCIKPj4+ICN2bmM9MQo+Pj4gI3ZuY3VudXNlZD0xCj4+PiAj
dm5jbGlzdGVuPSIwLjAuMC4wIgo+Pj4gI2tleW1hcD0iaXQiCj4+PiBzcGljZT0xCj4+PiBzcGlj
ZWhvc3Q9IjAuMC4wLjAiCj4+PiBzcGljZXBvcnQ9NjAwMAo+Pj4gc3BpY2VkaXNhYmxlX3RpY2tl
dGluZz0xCj4+PiBvbl9wb3dlcm9mZj0iZGVzdHJveSIKPj4+IG9uX3JlYm9vdD0icmVzdGFydCIK
Pj4+IG9uX2NyYXNoPSJkZXN0cm95Igo+Pj4gc3RkdmdhPTEKPj4+ICNkZXZpY2VfbW9kZWxfYXJn
cz1bIi12Z2EgcXhsIC1nbG9iYWwgcXhsLXZnYS52cmFtX3NpemVfbWI9MTYiXQo+Pj4gI3ZpZGVv
cmFtPTEyOAo+Pj4gI2RldmljZV9tb2RlbF9hcmdzPVsiLXZnYSBxeGwiXQo+Pj4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gV2l0aCBzdGR2Z2Egb3B0aW9uIGRvbVUgaXMgd29y
a2luZyBidXQgZ3JhcGhpYyBwZXJmb3JtYW5jZSBpcyBwb29yIHdpdGgKPj4+IHNwaWNlLgo+Pj4K
Pj4+Cj4+PiBXaXRoIFFYTCB2Z2Egb3B0aW9uIGRvbVUKPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KPj4+IHZpZGVvcmFtPTEyOAo+Pj4gZGV2aWNlX21vZGVsX2FyZ3M9WyItdmdh
IHF4bCJdCj4+PiBzdGR2Z2E9MAo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+
Pj4gRG9tVSBub3Qgc3RhcnQsIGZyb20gcWVtdSBsb2c6Cj4+PiBxZW11LXN5c3RlbS1pMzg2OiAt
dmdhIHF4bDogaW52YWxpZCBvcHRpb24KPj4+Cj4+PiBCdXQgdGhlIG9wdGlvbiBpcyBjb3JyZWN0
IGFuZCBpZiBJIGFkZDoKPj4+IGRldmljZV9tb2RlbF9vdmVycmlkZT0iL3Vzci9saWIveGVuL2Jp
bi9xZW11LWRlYnVnLnNoIgo+Pj4KPj4+IHFlbXUtZGVidWcuc2ggbGF1bmNoZXMgdGhlIHNhbWUg
cWVtdS1zeXN0ZW0taTM4NiB3aXRoIHNhbWUgb3B0aW9ucyBhbmQKPj4+IGRvbVUKPj4+IHN0YXJ0
cy4KPj4+IERvbVUgc2VlcyB0aGUgUVhMIHZnYSBidXQgb25seSB3aXRoIDQgbWIgYWxsb2NhdGVk
IGFuZC9vciB1c2FibGVkCj4+PiBpbnN0ZWFkIG9mCj4+PiA2NCBtYiBvZiBxZW11IGRlZmF1bHQu
Cj4+Pgo+Pj4gV2UgbmVlZCBkb21VcyB3aXRoIGdvb2QgZ3JhcGhpYyBwZXJmb3JtYW5jZSwgYWxz
byB3aXRoIGhpZ2ggcmVzb2x1dGlvbgo+Pj4gYW5kCj4+PiBhbHNvIG11bHRpbWVkaWEuCj4+PiBX
ZSBjYW4gbm90IHVzZSBnZnggcGFzc3Rocm91Z2ggb24gb3VyIGRvbTBzIGJlY2F1c2Ugb2YgaGFy
ZHdhcmUKPj4+IGxpbWl0YXRpb24KPj4+IG9mIGRlbGwgc2VydmVyLgo+Pj4gUVhMIHNlZW1zIHRv
IGJlIHRoZSBvbmx5IHdheSB0byBnby4KPj4+Cj4+PiBXZSBhcmUgdGVzdGluZyB0aGlzIHNldHVw
IHNldmVyYWwgbW9udGhzIHdpdGhvdXQgc3VjY2VzcyBvbiB4ZW4uCj4+PiBTb21lIGluaXRpYWwg
eGwgYW5kIHFlbXUgcmFtL3ZpZGVvcmFtIGJ1Z3MgYXJlIG5vdyBmaXhlZCBidXQgbWF5IGJlCj4+
PiB0aGVyZQo+Pj4gYXJlIG90aGVyIGluIHhlbiBub3QgZm91bmQgZm9yIG5vdy4KPj4+Cj4+PiBX
ZSBub3RpY2VkIG9uZSBwYXJ0aWN1bGFyIHRoaW5nOgo+Pj4KPj4+IHdpdGhvdXQgcXhsOgo+Pj4g
eGM6IGluZm86IFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+Pj4gwqAgTG9hZGVyOiDCoCDC
oCDCoCDCoDAwMDAwMDAwMDAxMDAwMDAtPjAwMDAwMDAwMDAxOWRjODgKPj4+IMKgIFRPVEFMOiDC
oCDCoCDCoCDCoCAwMDAwMDAwMDAwMDAwMDAwLT4wMDAwMDAwMDNmODAwMDAwCj4+PiDCoCBFTlRS
WSBBRERSRVNTOiAwMDAwMDAwMDAwMTAwMDAwCj4+Pgo+Pj4gd2l0aCBxeGw6Cj4+PiB4YzogaW5m
bzogVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4+PiDCoCBMb2FkZXI6IMKgIMKgIMKgIMKg
MDAwMDAwMDAwMDEwMDAwMC0+MDAwMDAwMDAwMDE5ZGM4OAo+Pj4gwqAgVE9UQUw6IMKgIMKgIMKg
IMKgIDAwMDAwMDAwMDAwMDAwMDAtPjAwMDAwMDAwMzgwMDAwMDAKPj4+IMKgIEVOVFJZIEFERFJF
U1M6IDAwMDAwMDAwMDAxMDAwMDAKPj4+Cj4+PiBUaGUgdG90YWwgbWVtb3J5IHdpdGggcXhsIHNo
b3VsZCBiZSBlcXVhbCBvciBtYWpvciB0aGFuIHRvdGFsIG1lbW9yeQo+Pj4gd2l0aG91dAo+Pj4g
cXhsLgo+Pj4gVGhlcmUgaXMgc29tZXRoaW5nIHdyb25nIGFib3V0IHZpZGVvcmFtLCBpIGRvbid0
IGtub3cgaWYgaW4geGwgb3Igb3RoZXIKPj4+IHBhcnQKPj4+IG9mIHhlbi4KPj4+Cj4+PiBQbGVh
c2Ugc29tZW9uZSBoZWxwIG1lIHRvIHNvbHZlIHRoaXMgcHJvYmxlbT8KPj4+Cj4+PiAtLQo+Pj4g
VmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDoKPj4+IGh0dHA6Ly94ZW4uMTA0NTcxMi5uNS5u
YWJibGUuY29tL1VuYWJsZS10by1nZXQtUVhMLXZnYS13b3JraW5nLXRwNTY2NzkxOXA1NjY3OTE5
Lmh0bWwKPj4+IFNlbnQgZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0
IE5hYmJsZS5jb20uCj4+Pgo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KPj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4+IFhlbi1kZXZlbEAueGVu
Cj4+PiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPj4KPj4KPj4KPj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+PiBYZW4tZGV2ZWxALnhlbgo+PiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwKPiAKPiAKPiAKPiAtLSAKPiBaaG91IFBlbmcKPiAKPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4t
ZGV2ZWxALnhlbgo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+IAoKClRoYW5rcyBm
b3IgcmVwbHksIGFib3V0IFFYTCBzb21lIHBhdGNoZXMgbmVlZCB0byBiZSBiYWNrcG9ydGVkIGZy
b20gcWVtdQp1cHN0cmVhbSB1bnN0YWJsZSB0byBxZW11IHVwc3RyZWFtIHhlbiwgbm93IEkgZG9u
J3Qga25vdyBleGFjdGx5IHdoaWNoIG9mCnRoZW0gc29sdmUgdGhlIGRvbVUgYm9vdCBwcm9ibGVt
IHdpdGggc3BpY2UgYW5kIHF4bCwgd2l0aCBxZW11IGFuZCBzZWFiaW9zCm9mIHhlbiAoMS4wLjEp
IGRvZXNuJ3Qgd29yayB3aGlsZSB3aXRoIHFlbXUgYW5kIHNlYWJpb3MgdW5zdGFibGUgaXQgZG9l
cy4KVGhlcmUgYXJlIGFsc28gc29tZSB2aWRlb3JhbSBidWcgb3IgcHJvYmxlbSBvbiB4ZW4sIHBy
b2JhYmx5IGJ1Z2ZpeC9wYXRjaAphcmUgbmVjZXNzYXJ5IGFsc28gb3V0c2lkZSBvZiBsaWJ4bCwg
SSB0cmllZCB0byBsb29rIGZvciB0aGUgcHJvYmxlbSBhbmQKc29sdmUgaXQgbXlzZWxmIGJ1dCBJ
IGRvbid0IGhhdmUgZW5vdWdoIGtub3dsZWRnZSBub3cuCgotLQpWaWV3IHRoaXMgbWVzc2FnZSBp
biBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9VbmFibGUtdG8tZ2V0
LVFYTC12Z2Etd29ya2luZy10cDU2Njc5MTlwNTY2OTgwNS5odG1sClNlbnQgZnJvbSB0aGUgWGVu
IC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhS3-0004z3-VE; Fri, 27 Apr 2012 09:26:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNhS2-0004yv-BI
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 09:26:55 +0000
Received: from [193.109.254.147:29075] by server-8.bemta-14.messagelabs.com id
	9C/2C-23244-D566A9F4; Fri, 27 Apr 2012 09:26:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335518809!6645787!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4849 invoked from network); 27 Apr 2012 09:26:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 09:26:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNhRt-000McR-4p; Fri, 27 Apr 2012 09:26:45 +0000
Date: Fri, 27 Apr 2012 10:26:45 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120427092645.GC86045@ocelot.phlegethon.org>
References: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx"
Content-Disposition: inline
In-Reply-To: <23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 20:02 -0700 on 26 Apr (1335470547), Andres Lagar-Cavilla wrote:
> > Can you please try the attached patch?  I think you'll need this one
> > plus the ones that take the locks out of the hpet code.
> 
> Right off the bat I'm getting a multitude of
> (XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
> And a hung dom0 during initramfs. I'm a little baffled as to why, but it's
> there (32 bit dom0, XenServer6).

Curses, I knew there'd be one somewhere.  I've been replacing
get_page_and_type_from_pagenr()s (which return 0 for success) with
old-school get_page_type()s (which return 1 for success) and not always
getting the right number of inversions.  That's a horrible horrible
beartrap of an API, BTW, which had me cursing at the screen, but I had
enough on my plate yesterday without touching _that_ code too!

> > Andres, this is basically the big-hammer version of your "take a
> > pagecount" changes, plus the change you made to hvmemul_rep_movs().
> > If this works I intend to follow it up with a patch to make some of the
> > read-modify-write paths avoid taking the lock (by using a
> > compare-exchange operation so they only take the lock on a write).  If
> > that succeeds I might drop put_gfn() altogether.
> 
> You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
> There are code paths that do get_gfn_query -> p2m_change_type -> put_gfn.
> But I guess those could lock the p2m up-front if they become the only
> consumers of put_gfn left.

Well, that's more or less what happens now.  I was thinking of replacing
any remaining

 (implicit) lock ; read ; think a bit ; maybe write ; unlock

code with the fast-path-friendlier:

 read ; think ; maybe-cmpxchg (and on failure undo or retry 

which avoids taking the write lock altogether if there's no work to do. 
But maybe there aren't many of those left now.  Obviously any path
which will always write should just take the write-lock first. 
 
> >  - grant-table operations still use the lock, because frankly I
> >    could not follow the current code, and it's quite late in the evening.
> 
> It's pretty complex with serious nesting, and ifdef's for arm and 32 bit.
> gfn_to_mfn_private callers will suffer from altering the current meaning,
> as put_gfn resolves to the right thing for the ifdef'ed arch. The other
> user is grant_transfer which also relies on the page *not* having an extra
> ref in steal_page. So it's a prime candidate to be left alone.

Sadly, I think it's not.  The PV backends will be doing lots of grant
ops, which shouldn't get serialized against all other P2M lookups. 

> > I also have a long list of uglinesses in the mm code that I found
> 
> Uh, ugly stuff, how could that have happened?

I can't imagine. :)  Certainly nothing to do with me thinking "I'll
clean that up when I get some time."

> I have a few preliminary observations on the patch. Pasting relevant bits
> here, since the body of the patch seems to have been lost by the email
> thread:
> 
> @@ -977,23 +976,25 @@ int arch_set_info_guest(
> ...
> +
> +        if (!paging_mode_refcounts(d)
> +            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
> replace with && !get_page_type() )

Yep.

> @@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
>              gfn = addr >> PAGE_SHIFT;
>          }
> 
> -        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
> +        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
> replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
> same logic when checking p2m_is_shared). Not truly related to your patch
> bit since we're at it.

OK, but not in this patch.

> Same, further down
> -        if ( !p2m_is_ram(p2mt) )
> +        if ( !page )
>          {
> -            put_gfn(curr->domain, gfn);
> +            if ( page )
> +                put_page(page);
> Last two lines are redundant

Yep.

> @@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
>     case HVMOP_modified_memory: a lot of error checking has been removed.

Yes, but it was bogus - there's a race between the actual modification
and the call, during which anything might have happened.  The best we
can do is throw log-dirty bits at everything, and the caller can't do
anything with the error anyway.

When I come to tidy up I'll just add a new mark_gfn_dirty function
and skip the pointless gfn->mfn->gfn translation on this path.

> arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing checking
> for target gfns of mmu updates of l2/3/4 entries. It seems that this
> wouldn't work anyways, that's why you killed it?

Yeah - since only L1es can point at foreign mappings it was all just
noise, and even if there had been real p2m lookups on those paths there
was no equivalent to the translate-in-place that happens in
mod_l1_entry so it would have been broken in a much worse way.

> +++ b/xen/arch/x86/mm/hap/guest_walk.c
> @@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
> ...
> +    if ( !top_page )
>      {
>          pfec[0] &= ~PFEC_page_present;
> -        __put_gfn(p2m, top_gfn);
> +        put_page(top_page);
> top_page is NULL here, remove put_page

Yep.

> get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
> locking is already done by get_gfn_type_access/__put_gfn

Yeah, but I was writing that with half an eye on killing that lock. :) 
I'll drop them for now.

> (hope those observations made sense without inlining them in the actual
> patch)

Yes, absolutely - thanks for the review!

If we can get this to work well enough I'll tidy it up into a sensible
series next week.   In the meantime, an updated verison of the
monster patch is attached. 

Cheers,

Tim.

--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=get-page-from-gfn

# HG changeset patch
# Parent 107285938c50f82667bd4d014820b439a077c22c

diff -r 107285938c50 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domain.c	Fri Apr 27 10:23:28 2012 +0100
@@ -716,7 +716,7 @@ int arch_set_info_guest(
 {
     struct domain *d = v->domain;
     unsigned long cr3_gfn;
-    unsigned long cr3_pfn = INVALID_MFN;
+    struct page_info *cr3_page;
     unsigned long flags, cr4;
     unsigned int i;
     int rc = 0, compat;
@@ -925,46 +925,45 @@ int arch_set_info_guest(
     if ( !compat )
     {
         cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_base_page_table)) )
+        if ( !cr3_page )
         {
-            put_gfn(d, cr3_gfn);
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+        if ( !paging_mode_refcounts(d)
+             && !get_page_type(cr3_page, PGT_base_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
-        v->arch.guest_table = pagetable_from_pfn(cr3_pfn);
-        put_gfn(d, cr3_gfn);
+        v->arch.guest_table = pagetable_from_page(cr3_page);
 #ifdef __x86_64__
         if ( c.nat->ctrlreg[1] )
         {
             cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]);
-            cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+            cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-            if ( !mfn_valid(cr3_pfn) ||
-                 (paging_mode_refcounts(d)
-                  ? !get_page(mfn_to_page(cr3_pfn), d)
-                  : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                       PGT_base_page_table)) )
+            if ( !cr3_page ||
+                 (!paging_mode_refcounts(d)
+                  && !get_page_type(cr3_page, PGT_base_page_table)) )
             {
-                cr3_pfn = pagetable_get_pfn(v->arch.guest_table);
+                if (cr3_page)
+                    put_page(cr3_page);
+                cr3_page = pagetable_get_page(v->arch.guest_table);
                 v->arch.guest_table = pagetable_null();
                 if ( paging_mode_refcounts(d) )
-                    put_page(mfn_to_page(cr3_pfn));
+                    put_page(cr3_page);
                 else
-                    put_page_and_type(mfn_to_page(cr3_pfn));
-                put_gfn(d, cr3_gfn); 
+                    put_page_and_type(cr3_page);
                 destroy_gdt(v);
                 return -EINVAL;
             }
 
-            v->arch.guest_table_user = pagetable_from_pfn(cr3_pfn);
-            put_gfn(d, cr3_gfn); 
+            v->arch.guest_table_user = pagetable_from_page(cr3_page);
         }
         else if ( !(flags & VGCF_in_kernel) )
         {
@@ -977,23 +976,25 @@ int arch_set_info_guest(
         l4_pgentry_t *l4tab;
 
         cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_l3_page_table)) )
+        if ( !cr3_page)
         {
-            put_gfn(d, cr3_gfn); 
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+
+        if (!paging_mode_refcounts(d)
+            && !get_page_type(cr3_page, PGT_l3_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
         l4tab = __va(pagetable_get_paddr(v->arch.guest_table));
-        *l4tab = l4e_from_pfn(
-            cr3_pfn, _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
-        put_gfn(d, cr3_gfn); 
+        *l4tab = l4e_from_pfn(page_to_mfn(cr3_page),
+            _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
 #endif
     }
 
@@ -1064,7 +1065,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     struct domain *d = v->domain;
     void *mapping;
     vcpu_info_t *new_info;
-    unsigned long mfn;
+    struct page_info *page;
     int i;
 
     if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) )
@@ -1077,19 +1078,20 @@ map_vcpu_info(struct vcpu *v, unsigned l
     if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) )
         return -EINVAL;
 
-    mfn = get_gfn_untyped(d, gfn);
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gfn); 
+        put_page(page);
         return -EINVAL;
     }
 
-    mapping = map_domain_page_global(mfn);
+    mapping = __map_domain_page_global(page);
     if ( mapping == NULL )
     {
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gfn); 
+        put_page_and_type(page);
         return -ENOMEM;
     }
 
@@ -1106,7 +1108,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     }
 
     v->vcpu_info = new_info;
-    v->arch.pv_vcpu.vcpu_info_mfn = mfn;
+    v->arch.pv_vcpu.vcpu_info_mfn = page_to_mfn(page);
 
     /* Set new vcpu_info pointer /before/ setting pending flags. */
     wmb();
@@ -1119,7 +1121,6 @@ map_vcpu_info(struct vcpu *v, unsigned l
     for ( i = 0; i < BITS_PER_EVTCHN_WORD(d); i++ )
         set_bit(i, &vcpu_info(v, evtchn_pending_sel));
 
-    put_gfn(d, gfn); 
     return 0;
 }
 
diff -r 107285938c50 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domctl.c	Fri Apr 27 10:23:28 2012 +0100
@@ -202,16 +202,16 @@ long arch_do_domctl(
 
                 for ( j = 0; j < k; j++ )
                 {
-                    unsigned long type = 0, mfn = get_gfn_untyped(d, arr[j]);
+                    unsigned long type = 0;
 
-                    page = mfn_to_page(mfn);
+                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
 
-                    if ( unlikely(!mfn_valid(mfn)) ||
-                         unlikely(is_xen_heap_mfn(mfn)) )
+                    if ( unlikely(!page) ||
+                         unlikely(is_xen_heap_page(page)) )
                         type = XEN_DOMCTL_PFINFO_XTAB;
                     else if ( xsm_getpageframeinfo(page) != 0 )
                         ;
-                    else if ( likely(get_page(page, d)) )
+                    else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
                         {
@@ -231,13 +231,10 @@ long arch_do_domctl(
 
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |= XEN_DOMCTL_PFINFO_LPINTAB;
+                    }
 
+                    if ( page )
                         put_page(page);
-                    }
-                    else
-                        type = XEN_DOMCTL_PFINFO_XTAB;
-
-                    put_gfn(d, arr[j]);
                     arr[j] = type;
                 }
 
@@ -304,21 +301,21 @@ long arch_do_domctl(
             {      
                 struct page_info *page;
                 unsigned long gfn = arr32[j];
-                unsigned long mfn = get_gfn_untyped(d, gfn);
 
-                page = mfn_to_page(mfn);
+                page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
 
                 if ( domctl->cmd == XEN_DOMCTL_getpageframeinfo3)
                     arr32[j] = 0;
 
-                if ( unlikely(!mfn_valid(mfn)) ||
-                     unlikely(is_xen_heap_mfn(mfn)) )
+                if ( unlikely(!page) ||
+                     unlikely(is_xen_heap_page(page)) )
                     arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
                 else if ( xsm_getpageframeinfo(page) != 0 )
                 {
-                    put_gfn(d, gfn); 
+                    put_page(page);
                     continue;
-                } else if ( likely(get_page(page, d)) )
+                }
+                else
                 {
                     unsigned long type = 0;
 
@@ -341,12 +338,10 @@ long arch_do_domctl(
                     if ( page->u.inuse.type_info & PGT_pinned )
                         type |= XEN_DOMCTL_PFINFO_LPINTAB;
                     arr32[j] |= type;
+                }
+
+                if ( page )
                     put_page(page);
-                }
-                else
-                    arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
-
-                put_gfn(d, gfn); 
             }
 
             if ( copy_to_guest_offset(domctl->u.getpageframeinfo2.array,
@@ -419,7 +414,7 @@ long arch_do_domctl(
     {
         struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long gmfn = domctl->u.hypercall_init.gmfn;
-        unsigned long mfn;
+        struct page_info *page;
         void *hypercall_page;
 
         ret = -ESRCH;
@@ -433,26 +428,25 @@ long arch_do_domctl(
             break;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
 
         ret = -EACCES;
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn); 
+            if ( page )
+                put_page(page);
             rcu_unlock_domain(d);
             break;
         }
 
         ret = 0;
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
+        put_page_and_type(page);
 
-        put_gfn(d, gmfn); 
         rcu_unlock_domain(d);
     }
     break;
diff -r 107285938c50 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/emulate.c	Fri Apr 27 10:23:28 2012 +0100
@@ -60,34 +60,25 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    struct page_info *ram_page;
     int rc;
 
     /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+    ram_page = get_page_from_gfn(curr->domain, ram_gfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         p2m_mem_paging_populate(curr->domain, ram_gfn);
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_RETRY;
     }
 
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
-        {
-            put_gfn(curr->domain, ram_gfn);
-            return X86EMUL_RETRY;
-        }
-    put_gfn(curr->domain, ram_gfn);
-
     /*
      * Weird-sized accesses have undefined behaviour: we discard writes
      * and read all-ones.
@@ -98,8 +89,8 @@ static int hvmemul_do_io(
         ASSERT(p_data != NULL); /* cannot happen with a REP prefix */
         if ( dir == IOREQ_READ )
             memset(p_data, ~0, size);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -120,8 +111,8 @@ static int hvmemul_do_io(
             unsigned int bytes = vio->mmio_large_write_bytes;
             if ( (addr >= pa) && ((addr + size) <= (pa + bytes)) )
             {
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -133,8 +124,8 @@ static int hvmemul_do_io(
             {
                 memcpy(p_data, &vio->mmio_large_read[addr - pa],
                        size);
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -148,8 +139,8 @@ static int hvmemul_do_io(
         vio->io_state = HVMIO_none;
         if ( p_data == NULL )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_UNHANDLEABLE;
         }
         goto finish_access;
@@ -159,13 +150,13 @@ static int hvmemul_do_io(
              (addr == (vio->mmio_large_write_pa +
                        vio->mmio_large_write_bytes)) )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_RETRY;
         }
     default:
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -173,8 +164,8 @@ static int hvmemul_do_io(
     {
         gdprintk(XENLOG_WARNING, "WARNING: io already pending (%d)?\n",
                  p->state);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -226,8 +217,8 @@ static int hvmemul_do_io(
 
     if ( rc != X86EMUL_OKAY )
     {
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return rc;
     }
 
@@ -263,8 +254,8 @@ static int hvmemul_do_io(
         }
     }
 
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        put_page(mfn_to_page(mfn_x(ram_mfn)));
+    if ( ram_page )
+        put_page(ram_page);
     return X86EMUL_OKAY;
 }
 
@@ -686,7 +677,6 @@ static int hvmemul_rep_movs(
     p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
-    struct two_gfns tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -714,25 +704,17 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
-                 current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 P2M_ALLOC, &tg);
+    /* Check for MMIO ops */
+    (void) get_gfn_query_unlocked(current->domain, sgpa >> PAGE_SHIFT, &sp2mt);
+    (void) get_gfn_query_unlocked(current->domain, dgpa >> PAGE_SHIFT, &dp2mt);
 
-    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( sp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
-    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( dp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +729,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +738,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +749,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 107285938c50 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Fri Apr 27 10:23:28 2012 +0100
@@ -395,48 +395,41 @@ int prepare_ring_for_helper(
 {
     struct page_info *page;
     p2m_type_t p2mt;
-    unsigned long mfn;
     void *va;
 
-    mfn = mfn_x(get_gfn_unshare(d, gmfn, &p2mt));
-    if ( !p2m_is_ram(p2mt) )
-    {
-        put_gfn(d, gmfn);
-        return -EINVAL;
-    }
+    page = get_page_from_gfn(d, gmfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         return -ENOENT;
     }
-    ASSERT(mfn_valid(mfn));
-
-    page = mfn_to_page(mfn);
-    if ( !get_page_and_type(page, d, PGT_writable_page) )
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn);
+        put_page(page);
         return -EINVAL;
     }
 
-    va = map_domain_page_global(mfn);
+    va = __map_domain_page_global(page);
     if ( va == NULL )
     {
         put_page_and_type(page);
-        put_gfn(d, gmfn);
         return -ENOMEM;
     }
 
     *_va = va;
     *_page = page;
 
-    put_gfn(d, gmfn);
-
     return 0;
 }
 
@@ -1607,8 +1600,8 @@ int hvm_mov_from_cr(unsigned int cr, uns
 int hvm_set_cr0(unsigned long value)
 {
     struct vcpu *v = current;
-    p2m_type_t p2mt;
-    unsigned long gfn, mfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    unsigned long gfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    struct page_info *page;
 
     HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR0 value = %lx", value);
 
@@ -1647,23 +1640,20 @@ int hvm_set_cr0(unsigned long value)
         {
             /* The guest CR3 must be pointing to the guest physical. */
             gfn = v->arch.hvm_vcpu.guest_cr[3]>>PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(v->domain, gfn, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-                 !get_page(mfn_to_page(mfn), v->domain))
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, gfn);
-                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx (mfn=%lx)\n",
-                         v->arch.hvm_vcpu.guest_cr[3], mfn);
+                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx\n",
+                         v->arch.hvm_vcpu.guest_cr[3]);
                 domain_crash(v->domain);
                 return X86EMUL_UNHANDLEABLE;
             }
 
             /* Now arch.guest_table points to machine physical. */
-            v->arch.guest_table = pagetable_from_pfn(mfn);
+            v->arch.guest_table = pagetable_from_page(page);
 
             HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx, mfn = %lx",
-                        v->arch.hvm_vcpu.guest_cr[3], mfn);
-            put_gfn(v->domain, gfn);
+                        v->arch.hvm_vcpu.guest_cr[3], page_to_mfn(page));
         }
     }
     else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) )
@@ -1738,26 +1728,21 @@ int hvm_set_cr0(unsigned long value)
 
 int hvm_set_cr3(unsigned long value)
 {
-    unsigned long mfn;
-    p2m_type_t p2mt;
     struct vcpu *v = current;
+    struct page_info *page;
 
     if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
          (value != v->arch.hvm_vcpu.guest_cr[3]) )
     {
         /* Shadow-mode CR3 change. Check PDBR and update refcounts. */
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "CR3 value = %lx", value);
-        mfn = mfn_x(get_gfn(v->domain, value >> PAGE_SHIFT, &p2mt));
-        if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-             !get_page(mfn_to_page(mfn), v->domain) )
-        {
-              put_gfn(v->domain, value >> PAGE_SHIFT);
-              goto bad_cr3;
-        }
+        page = get_page_from_gfn(v->domain, value >> PAGE_SHIFT,
+                                 NULL, P2M_ALLOC);
+        if ( !page )
+            goto bad_cr3;
 
         put_page(pagetable_get_page(v->arch.guest_table));
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        put_gfn(v->domain, value >> PAGE_SHIFT);
+        v->arch.guest_table = pagetable_from_page(page);
 
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
     }
@@ -1914,46 +1899,29 @@ int hvm_virtual_to_linear_addr(
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
     void *map;
-    unsigned long mfn;
     p2m_type_t p2mt;
-    struct page_info *pg;
+    struct page_info *page;
     struct domain *d = current->domain;
-    int rc;
-
-    mfn = mfn_x(writable
-                ? get_gfn_unshare(d, gfn, &p2mt)
-                : get_gfn(d, gfn, &p2mt));
-    if ( (p2m_is_shared(p2mt) && writable) || !p2m_is_ram(p2mt) )
+
+    page = get_page_from_gfn(d, gfn, &p2mt,
+                             writable ? P2M_UNSHARE : P2M_ALLOC);
+    if ( (p2m_is_shared(p2mt) && writable) || !page )
     {
-        put_gfn(d, gfn);
+        if ( page )
+            put_page(page);
         return NULL;
     }
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gfn);
+        put_page(page);
         p2m_mem_paging_populate(d, gfn);
         return NULL;
     }
 
-    ASSERT(mfn_valid(mfn));
-
     if ( writable )
-        paging_mark_dirty(d, mfn);
-
-    /* Get a ref on the page, considering that it could be shared */
-    pg = mfn_to_page(mfn);
-    rc = get_page(pg, d);
-    if ( !rc && !writable )
-        /* Page could be shared */
-        rc = get_page(pg, dom_cow);
-    if ( !rc )
-    {
-        put_gfn(d, gfn);
-        return NULL;
-    }
-
-    map = map_domain_page(mfn);
-    put_gfn(d, gfn);
+        paging_mark_dirty(d, page_to_mfn(page));
+
+    map = __map_domain_page(page);
     return map;
 }
 
@@ -2358,7 +2326,8 @@ static enum hvm_copy_result __hvm_copy(
     void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2402,32 +2371,33 @@ static enum hvm_copy_result __hvm_copy(
             gfn = addr >> PAGE_SHIFT;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( flags & HVMCOPY_to_guest )
         {
@@ -2437,12 +2407,12 @@ static enum hvm_copy_result __hvm_copy(
                 if ( xchg(&lastpage, gfn) != gfn )
                     gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                              " memory page. gfn=%#lx, mfn=%#lx\n",
-                             gfn, mfn);
+                             gfn, page_to_mfn(page));
             }
             else
             {
                 memcpy(p, buf, count);
-                paging_mark_dirty(curr->domain, mfn);
+                paging_mark_dirty(curr->domain, page_to_mfn(page));
             }
         }
         else
@@ -2455,7 +2425,7 @@ static enum hvm_copy_result __hvm_copy(
         addr += count;
         buf  += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -2464,7 +2434,8 @@ static enum hvm_copy_result __hvm_copy(
 static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2500,32 +2471,35 @@ static enum hvm_copy_result __hvm_clear(
             return HVMCOPY_bad_gva_to_gfn;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( p2mt == p2m_ram_ro )
         {
@@ -2533,19 +2507,19 @@ static enum hvm_copy_result __hvm_clear(
             if ( xchg(&lastpage, gfn) != gfn )
                 gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                         " memory page. gfn=%#lx, mfn=%#lx\n",
-                        gfn, mfn);
+                         gfn, page_to_mfn(page));
         }
         else
         {
             memset(p, 0x00, count);
-            paging_mark_dirty(curr->domain, mfn);
+            paging_mark_dirty(curr->domain, page_to_mfn(page));
         }
 
         unmap_domain_page(p);
 
         addr += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -4000,35 +3974,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
 
         for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
         {
-            p2m_type_t t;
-            mfn_t mfn = get_gfn_unshare(d, pfn, &t);
-            if ( p2m_is_paging(t) )
+            struct page_info *page;
+            page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
+            if ( page )
             {
-                put_gfn(d, pfn);
-                p2m_mem_paging_populate(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            if( p2m_is_shared(t) )
-            {
-                /* If it insists on not unsharing itself, crash the domain 
-                 * rather than crashing the host down in mark dirty */
-                gdprintk(XENLOG_WARNING,
-                         "shared pfn 0x%lx modified?\n", pfn);
-                domain_crash(d);
-                put_gfn(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            
-            if ( mfn_x(mfn) != INVALID_MFN )
-            {
-                paging_mark_dirty(d, mfn_x(mfn));
+                paging_mark_dirty(d, page_to_mfn(page));
                 /* These are most probably not page tables any more */
                 /* don't take a long time and don't die either */
-                sh_remove_shadows(d->vcpu[0], mfn, 1, 0);
+                sh_remove_shadows(d->vcpu[0], _mfn(page_to_mfn(page)), 1, 0);
+                put_page(page);
             }
-            put_gfn(d, pfn);
         }
 
     param_fail3:
diff -r 107285938c50 xen/arch/x86/hvm/stdvga.c
--- a/xen/arch/x86/hvm/stdvga.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/stdvga.c	Fri Apr 27 10:23:28 2012 +0100
@@ -482,7 +482,8 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_to_guest_phys(data, &tmp, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                            d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     /*
                      * The only case we handle is vga_mem <-> vga_mem.
                      * Anything else disables caching and leaves it to qemu-dm.
@@ -490,11 +491,12 @@ static int mmio_move(struct hvm_hw_stdvg
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
+                    ASSERT(!dp);
                     stdvga_mem_write(data, tmp, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 data += sign * p->size;
                 addr += sign * p->size;
@@ -508,15 +510,16 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_from_guest_phys(&tmp, data, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                        d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
                     tmp = stdvga_mem_read(data, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 stdvga_mem_write(addr, tmp, p->size);
                 data += sign * p->size;
diff -r 107285938c50 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/viridian.c	Fri Apr 27 10:23:28 2012 +0100
@@ -134,18 +134,19 @@ void dump_apic_assist(struct vcpu *v)
 static void enable_hypercall_page(struct domain *d)
 {
     unsigned long gmfn = d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     /*
      * We set the bit 31 in %eax (reserved field in the Viridian hypercall
@@ -162,15 +163,14 @@ static void enable_hypercall_page(struct
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 void initialize_apic_assist(struct vcpu *v)
 {
     struct domain *d = v->domain;
     unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
     /*
@@ -183,22 +183,22 @@ void initialize_apic_assist(struct vcpu 
      * details of how Windows uses the page.
      */
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     *(u32 *)p = 0;
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
diff -r 107285938c50 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Apr 27 10:23:28 2012 +0100
@@ -480,17 +480,16 @@ static void vmx_vmcs_save(struct vcpu *v
 static int vmx_restore_cr0_cr3(
     struct vcpu *v, unsigned long cr0, unsigned long cr3)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
 
     if ( paging_mode_shadow(v->domain) )
     {
         if ( cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3);
                 return -EINVAL;
             }
@@ -499,9 +498,8 @@ static int vmx_restore_cr0_cr3(
         if ( hvm_paging_enabled(v) )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( cr0 & X86_CR0_PG )
-            put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+        v->arch.guest_table =
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = cr0 | X86_CR0_ET;
@@ -1026,8 +1024,9 @@ static void vmx_set_interrupt_shadow(str
 
 static void vmx_load_pdptrs(struct vcpu *v)
 {
-    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn;
+    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3];
     uint64_t *guest_pdptrs;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
 
@@ -1038,24 +1037,19 @@ static void vmx_load_pdptrs(struct vcpu 
     if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
 
-    mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-    if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || 
-         /* If we didn't succeed in unsharing, get_page will fail
-          * (page still belongs to dom_cow) */
-         !get_page(mfn_to_page(mfn), v->domain) )
+    page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE);
+    if ( !page )
     {
         /* Ideally you don't want to crash but rather go into a wait 
          * queue, but this is the wrong place. We're holding at least
          * the paging lock */
         gdprintk(XENLOG_ERR,
-                 "Bad cr3 on load pdptrs gfn %lx mfn %lx type %d\n",
-                 cr3 >> PAGE_SHIFT, mfn, (int) p2mt);
-        put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+                 "Bad cr3 on load pdptrs gfn %lx type %d\n",
+                 cr3 >> PAGE_SHIFT, (int) p2mt);
         goto crash;
     }
-    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
-
-    p = map_domain_page(mfn);
+
+    p = __map_domain_page(page);
 
     guest_pdptrs = (uint64_t *)(p + (cr3 & ~PAGE_MASK));
 
@@ -1081,7 +1075,7 @@ static void vmx_load_pdptrs(struct vcpu 
     vmx_vmcs_exit(v);
 
     unmap_domain_page(p);
-    put_page(mfn_to_page(mfn));
+    put_page(page);
     return;
 
  crash:
diff -r 107285938c50 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm.c	Fri Apr 27 10:23:28 2012 +0100
@@ -651,7 +651,8 @@ int map_ldt_shadow_page(unsigned int off
 {
     struct vcpu *v = current;
     struct domain *d = v->domain;
-    unsigned long gmfn, mfn;
+    unsigned long gmfn;
+    struct page_info *page;
     l1_pgentry_t l1e, nl1e;
     unsigned long gva = v->arch.pv_vcpu.ldt_base + (off << PAGE_SHIFT);
     int okay;
@@ -663,28 +664,24 @@ int map_ldt_shadow_page(unsigned int off
         return 0;
 
     gmfn = l1e_get_pfn(l1e);
-    mfn = get_gfn_untyped(d, gmfn);
-    if ( unlikely(!mfn_valid(mfn)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+    if ( unlikely(!page) )
+        return 0;
+
+    okay = get_page_type(page, PGT_seg_desc_page);
+    if ( unlikely(!okay) )
     {
-        put_gfn(d, gmfn); 
+        put_page(page);
         return 0;
     }
 
-    okay = get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page);
-    if ( unlikely(!okay) )
-    {
-        put_gfn(d, gmfn); 
-        return 0;
-    }
-
-    nl1e = l1e_from_pfn(mfn, l1e_get_flags(l1e) | _PAGE_RW);
+    nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW);
 
     spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock);
     l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e);
     v->arch.pv_vcpu.shadow_ldt_mapcnt++;
     spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock);
 
-    put_gfn(d, gmfn); 
     return 1;
 }
 
@@ -1819,7 +1816,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
 {
     l1_pgentry_t ol1e;
     struct domain *pt_dom = pt_vcpu->domain;
-    p2m_type_t p2mt;
     int rc = 0;
 
     if ( unlikely(__copy_from_user(&ol1e, pl1e, sizeof(ol1e)) != 0) )
@@ -1835,22 +1831,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
     if ( l1e_get_flags(nl1e) & _PAGE_PRESENT )
     {
         /* Translate foreign guest addresses. */
-        unsigned long mfn, gfn;
-        gfn = l1e_get_pfn(nl1e);
-        mfn = mfn_x(get_gfn(pg_dom, gfn, &p2mt));
-        if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) )
+        struct page_info *page = NULL;
+        if ( paging_mode_translate(pg_dom) )
         {
-            put_gfn(pg_dom, gfn);
-            return -EINVAL;
+            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, P2M_ALLOC);
+            if ( !page )
+                return -EINVAL;
+            nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(nl1e));
         }
-        ASSERT((mfn & ~(PADDR_MASK >> PAGE_SHIFT)) == 0);
-        nl1e = l1e_from_pfn(mfn, l1e_get_flags(nl1e));
 
         if ( unlikely(l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)) )
         {
             MEM_LOG("Bad L1 flags %x",
                     l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom));
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return -EINVAL;
         }
 
@@ -1860,15 +1855,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
             adjust_guest_l1e(nl1e, pt_dom);
             if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                               preserve_ad) )
+            {
+                if ( page )
+                    put_page(page);
                 return 0;
-            put_gfn(pg_dom, gfn);
+            }
+            if ( page )
+                put_page(page);
             return -EBUSY;
         }
 
         switch ( rc = get_page_from_l1e(nl1e, pt_dom, pg_dom) )
         {
         default:
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return rc;
         case 0:
             break;
@@ -1876,7 +1877,9 @@ static int mod_l1_entry(l1_pgentry_t *pl
             l1e_remove_flags(nl1e, _PAGE_RW);
             break;
         }
-        
+        if ( page )
+            put_page(page);
+
         adjust_guest_l1e(nl1e, pt_dom);
         if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                     preserve_ad)) )
@@ -1884,7 +1887,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
             ol1e = nl1e;
             rc = -EBUSY;
         }
-        put_gfn(pg_dom, gfn);
     }
     else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                      preserve_ad)) )
@@ -3042,7 +3044,6 @@ int do_mmuext_op(
             type = PGT_l4_page_table;
 
         pin_page: {
-            unsigned long mfn;
             struct page_info *page;
 
             /* Ignore pinning of invalid paging levels. */
@@ -3052,25 +3053,28 @@ int do_mmuext_op(
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            rc = get_page_and_type_from_pagenr(mfn, type, pg_owner, 0, 1);
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
+            {
+                rc = -EINVAL;
+                break;
+            }
+
+            rc = get_page_type_preemptible(page, type);
             okay = !rc;
             if ( unlikely(!okay) )
             {
                 if ( rc == -EINTR )
                     rc = -EAGAIN;
                 else if ( rc != -EAGAIN )
-                    MEM_LOG("Error while pinning mfn %lx", mfn);
-                put_gfn(pg_owner, op.arg1.mfn);
+                    MEM_LOG("Error while pinning mfn %lx", page_to_mfn(page));
+                put_page(page);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( (rc = xsm_memory_pin_page(d, page)) != 0 )
             {
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
@@ -3078,16 +3082,15 @@ int do_mmuext_op(
             if ( unlikely(test_and_set_bit(_PGT_pinned,
                                            &page->u.inuse.type_info)) )
             {
-                MEM_LOG("Mfn %lx already pinned", mfn);
+                MEM_LOG("Mfn %lx already pinned", page_to_mfn(page));
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
 
             /* A page is dirtied when its pin status is set. */
-            paging_mark_dirty(pg_owner, mfn);
-           
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             /* We can race domain destruction (domain_relinquish_resources). */
             if ( unlikely(pg_owner != d) )
             {
@@ -3099,35 +3102,29 @@ int do_mmuext_op(
                 spin_unlock(&pg_owner->page_alloc_lock);
                 if ( drop_ref )
                     put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
             }
 
             break;
         }
 
         case MMUEXT_UNPIN_TABLE: {
-            unsigned long mfn;
             struct page_info *page;
 
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            if ( unlikely(!(okay = get_page_from_pagenr(mfn, pg_owner))) )
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
             {
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx bad domain", mfn);
+                MEM_LOG("Mfn %lx bad domain", op.arg1.mfn);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( !test_and_clear_bit(_PGT_pinned, &page->u.inuse.type_info) )
             {
                 okay = 0;
                 put_page(page);
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx not pinned", mfn);
+                MEM_LOG("Mfn %lx not pinned", op.arg1.mfn);
                 break;
             }
 
@@ -3135,40 +3132,43 @@ int do_mmuext_op(
             put_page(page);
 
             /* A page is dirtied when its pin status is cleared. */
-            paging_mark_dirty(pg_owner, mfn);
-
-            put_gfn(pg_owner, op.arg1.mfn);
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             break;
         }
 
         case MMUEXT_NEW_BASEPTR:
-            okay = new_guest_cr3(get_gfn_untyped(d, op.arg1.mfn));
-            put_gfn(d, op.arg1.mfn);
+            okay = (!paging_mode_translate(d)
+                    && new_guest_cr3(op.arg1.mfn));
             break;
+
         
 #ifdef __x86_64__
         case MMUEXT_NEW_USER_BASEPTR: {
-            unsigned long old_mfn, mfn;
-
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            if ( mfn != 0 )
+            unsigned long old_mfn;
+
+            if ( paging_mode_translate(current->domain) )
+            {
+                okay = 0;
+                break;
+            }
+
+            if ( op.arg1.mfn != 0 )
             {
                 if ( paging_mode_refcounts(d) )
-                    okay = get_page_from_pagenr(mfn, d);
+                    okay = get_page_from_pagenr(op.arg1.mfn, d);
                 else
                     okay = !get_page_and_type_from_pagenr(
-                        mfn, PGT_root_page_table, d, 0, 0);
+                        op.arg1.mfn, PGT_root_page_table, d, 0, 0);
                 if ( unlikely(!okay) )
                 {
-                    put_gfn(d, op.arg1.mfn);
-                    MEM_LOG("Error while installing new mfn %lx", mfn);
+                    MEM_LOG("Error while installing new mfn %lx", op.arg1.mfn);
                     break;
                 }
             }
 
             old_mfn = pagetable_get_pfn(curr->arch.guest_table_user);
-            curr->arch.guest_table_user = pagetable_from_pfn(mfn);
-            put_gfn(d, op.arg1.mfn);
+            curr->arch.guest_table_user = pagetable_from_pfn(op.arg1.mfn);
 
             if ( old_mfn != 0 )
             {
@@ -3283,28 +3283,26 @@ int do_mmuext_op(
         }
 
         case MMUEXT_CLEAR_PAGE: {
-            unsigned long mfn;
+            struct page_info *page;
             unsigned char *ptr;
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
+            page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( !page || !get_page_type(page, PGT_writable_page) )
             {
-                put_gfn(d, op.arg1.mfn);
-                MEM_LOG("Error while clearing mfn %lx", mfn);
+                if ( page )
+                    put_page(page);
+                MEM_LOG("Error while clearing mfn %lx", op.arg1.mfn);
                 break;
             }
 
             /* A page is dirtied when it's being cleared. */
-            paging_mark_dirty(d, mfn);
-
-            ptr = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(page));
+
+            ptr = fixmap_domain_page(page_to_mfn(page));
             clear_page(ptr);
             fixunmap_domain_page(ptr);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
+            put_page_and_type(page);
             break;
         }
 
@@ -3312,42 +3310,38 @@ int do_mmuext_op(
         {
             const unsigned char *src;
             unsigned char *dst;
-            unsigned long src_mfn, mfn;
-
-            src_mfn = get_gfn_untyped(d, op.arg2.src_mfn);
-            okay = get_page_from_pagenr(src_mfn, d);
+            struct page_info *src_page, *dst_page;
+
+            src_page = get_page_from_gfn(d, op.arg2.src_mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!src_page) )
+            {
+                okay = 0;
+                MEM_LOG("Error while copying from mfn %lx", op.arg2.src_mfn);
+                break;
+            }
+
+            dst_page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            okay = (dst_page && get_page_type(dst_page, PGT_writable_page));
             if ( unlikely(!okay) )
             {
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying from mfn %lx", src_mfn);
+                put_page(src_page);
+                if ( dst_page )
+                    put_page(dst_page);
+                MEM_LOG("Error while copying to mfn %lx", op.arg1.mfn);
                 break;
             }
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
-            {
-                put_gfn(d, op.arg1.mfn);
-                put_page(mfn_to_page(src_mfn));
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying to mfn %lx", mfn);
-                break;
-            }
-
             /* A page is dirtied when it's being copied to. */
-            paging_mark_dirty(d, mfn);
-
-            src = map_domain_page(src_mfn);
-            dst = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(dst_page));
+
+            src = __map_domain_page(src_page);
+            dst = fixmap_domain_page(page_to_mfn(dst_page));
             copy_page(dst, src);
             fixunmap_domain_page(dst);
             unmap_domain_page(src);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
-            put_page(mfn_to_page(src_mfn));
-            put_gfn(d, op.arg2.src_mfn);
+            put_page_and_type(dst_page);
+            put_page(src_page);
             break;
         }
 
@@ -3538,29 +3532,26 @@ int do_mmu_update(
 
             req.ptr -= cmd;
             gmfn = req.ptr >> PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(pt_owner, gmfn, &p2mt));
-            if ( !p2m_is_valid(p2mt) )
-                mfn = INVALID_MFN;
+            page = get_page_from_gfn(pt_owner, gmfn, &p2mt, P2M_ALLOC);
 
             if ( p2m_is_paged(p2mt) )
             {
-                put_gfn(pt_owner, gmfn);
+                ASSERT(!page);
                 p2m_mem_paging_populate(pg_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
 
-            if ( unlikely(!get_page_from_pagenr(mfn, pt_owner)) )
+            if ( unlikely(!page) )
             {
                 MEM_LOG("Could not get page for normal update");
-                put_gfn(pt_owner, gmfn);
                 break;
             }
 
+            mfn = page_to_mfn(page);
             va = map_domain_page_with_cache(mfn, &mapcache);
             va = (void *)((unsigned long)va +
                           (unsigned long)(req.ptr & ~PAGE_MASK));
-            page = mfn_to_page(mfn);
 
             if ( page_lock(page) )
             {
@@ -3569,22 +3560,23 @@ int do_mmu_update(
                 case PGT_l1_page_table:
                 {
                     l1_pgentry_t l1e = l1e_from_intpte(req.val);
-                    p2m_type_t l1e_p2mt;
-                    unsigned long l1egfn = l1e_get_pfn(l1e), l1emfn;
-    
-                    l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
+                    p2m_type_t l1e_p2mt = p2m_ram_rw;
+                    struct page_info *target = NULL;
+
+                    if ( paging_mode_translate(pg_owner) )
+                        target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
+                                                   &l1e_p2mt, P2M_ALLOC);
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
-                        put_gfn(pg_owner, l1egfn);
+                        if ( target )
+                            put_page(target);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in == l1e_p2mt && 
-                                !mfn_valid(l1emfn) )
+                    else if ( p2m_ram_paging_in == l1e_p2mt && !target )
                     {
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3601,7 +3593,8 @@ int do_mmu_update(
                             rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
                             if ( rc )
                             {
-                                put_gfn(pg_owner, l1egfn);
+                                if ( target )
+                                    put_page(target);
                                 /* Notify helper, don't care about errors, will not
                                  * sleep on wq, since we're a foreign domain. */
                                 (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
@@ -3614,112 +3607,22 @@ int do_mmu_update(
                     rc = mod_l1_entry(va, l1e, mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
                                       pg_owner);
-                    put_gfn(pg_owner, l1egfn);
+                    if ( target )
+                        put_page(target);
                 }
                 break;
                 case PGT_l2_page_table:
-                {
-                    l2_pgentry_t l2e = l2e_from_intpte(req.val);
-                    p2m_type_t l2e_p2mt;
-                    unsigned long l2egfn = l2e_get_pfn(l2e), l2emfn;
-
-                    l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
-
-                    if ( p2m_is_paged(l2e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l2e_p2mt && 
-                                !mfn_valid(l2emfn) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l2e_p2mt )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-
-                    rc = mod_l2_entry(va, l2e, mfn,
+                    rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
-                    put_gfn(pg_owner, l2egfn);
-                }
-                break;
+                    break;
                 case PGT_l3_page_table:
-                {
-                    l3_pgentry_t l3e = l3e_from_intpte(req.val);
-                    p2m_type_t l3e_p2mt;
-                    unsigned long l3egfn = l3e_get_pfn(l3e), l3emfn;
-
-                    l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
-
-                    if ( p2m_is_paged(l3e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l3e_p2mt && 
-                                !mfn_valid(l3emfn) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l3e_p2mt )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l3_entry(va, l3e, mfn,
+                    rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l3egfn);
-                }
-                break;
+                    break;
 #if CONFIG_PAGING_LEVELS >= 4
                 case PGT_l4_page_table:
-                {
-                    l4_pgentry_t l4e = l4e_from_intpte(req.val);
-                    p2m_type_t l4e_p2mt;
-                    unsigned long l4egfn = l4e_get_pfn(l4e), l4emfn;
-
-                    l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
-
-                    if ( p2m_is_paged(l4e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l4e_p2mt && 
-                                !mfn_valid(l4emfn) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l4e_p2mt )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l4_entry(va, l4e, mfn,
+                    rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l4egfn);
-                }
                 break;
 #endif
                 case PGT_writable_page:
@@ -3742,7 +3645,6 @@ int do_mmu_update(
 
             unmap_domain_page_with_cache(va, &mapcache);
             put_page(page);
-            put_gfn(pt_owner, gmfn);
         }
         break;
 
diff -r 107285938c50 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/guest_walk.c	Fri Apr 27 10:23:28 2012 +0100
@@ -94,39 +94,37 @@ static inline void *map_domain_gfn(struc
                                    p2m_type_t *p2mt,
                                    uint32_t *rc) 
 {
-    p2m_access_t p2ma;
+    struct page_info *page;
     void *map;
 
     /* Translate the gfn, unsharing if shared */
-    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, 
-                               P2M_ALLOC | P2M_UNSHARE, NULL);
+    page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), p2mt, NULL,
+                                  P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
     if ( p2m_is_shared(*p2mt) )
     {
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         *rc = _PAGE_SHARED;
         return NULL;
     }
-    if ( !p2m_is_ram(*p2mt) ) 
+    if ( !page )
     {
-        __put_gfn(p2m, gfn_x(gfn));
         *rc |= _PAGE_PRESENT;
         return NULL;
     }
+    *mfn = _mfn(page_to_mfn(page));
     ASSERT(mfn_valid(mfn_x(*mfn)));
-    
-    /* Get an extra ref to the page to ensure liveness of the map.
-     * Then we can safely put gfn */
-    page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn)));
+
     map = map_domain_page(mfn_x(*mfn));
-    __put_gfn(p2m, gfn_x(gfn));
     return map;
 }
 
diff -r 107285938c50 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/hap/guest_walk.c	Fri Apr 27 10:23:28 2012 +0100
@@ -54,34 +54,36 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     mfn_t top_mfn;
     void *top_map;
     p2m_type_t p2mt;
-    p2m_access_t p2ma;
     walk_t gw;
     unsigned long top_gfn;
+    struct page_info *top_page;
 
     /* Get the top-level table's MFN */
     top_gfn = cr3 >> PAGE_SHIFT;
-    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, 
-                                  P2M_ALLOC | P2M_UNSHARE, NULL);
+    top_page = get_page_from_gfn_p2m(p2m->domain, p2m, top_gfn,
+                                     &p2mt, NULL, P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         pfec[0] = PFEC_page_paged;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
     {
         pfec[0] = PFEC_page_shared;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         return INVALID_GFN;
     }
-    if ( !p2m_is_ram(p2mt) )
+    if ( !top_page )
     {
         pfec[0] &= ~PFEC_page_present;
-        __put_gfn(p2m, top_gfn);
         return INVALID_GFN;
     }
+    top_mfn = _mfn(page_to_mfn(top_page));
 
     /* Map the top-level table and call the tree-walker */
     ASSERT(mfn_valid(mfn_x(top_mfn)));
@@ -91,31 +93,30 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 #endif
     missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map);
     unmap_domain_page(top_map);
-    __put_gfn(p2m, top_gfn);
+    put_page(top_page);
 
     /* Interpret the answer */
     if ( missing == 0 )
     {
         gfn_t gfn = guest_l1e_get_gfn(gw.l1e);
-        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
-                                  P2M_ALLOC | P2M_UNSHARE, NULL); 
+        struct page_info *page;
+        page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), &p2mt,
+                                     NULL, P2M_ALLOC | P2M_UNSHARE);
+        if ( page )
+            put_page(page);
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
             pfec[0] = PFEC_page_paged;
-            __put_gfn(p2m, gfn_x(gfn));
             p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
         {
             pfec[0] = PFEC_page_shared;
-            __put_gfn(p2m, gfn_x(gfn));
             return INVALID_GFN;
         }
 
-        __put_gfn(p2m, gfn_x(gfn));
-
         if ( page_order )
             *page_order = guest_walk_to_page_order(&gw);
 
diff -r 107285938c50 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Fri Apr 27 10:23:28 2012 +0100
@@ -166,13 +166,39 @@ declare_mm_lock(nestedp2m)
  * and later mutate it.
  */
 
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
+/* P2M lock is become an rwlock, purely so we can implement
+ * get_page_from_gfn.  The mess below is a ghastly hack to make a
+ * recursive rwlock.  If it works I'll come back and fix up the
+ * order-contraints magic. */
+
+static inline void p2m_lock(struct p2m_domain *p)
+{
+    if ( p->wcpu != current->processor )
+    {
+        write_lock(&p->lock);
+        p->wcpu = current->processor;
+        ASSERT(p->wcount == 0);
+    }
+    p->wcount++;
+}
+
+static inline void p2m_unlock(struct p2m_domain *p)
+{
+    ASSERT(p->wcpu == current->processor);
+    if (--(p->wcount) == 0)
+    {
+        p->wcpu = -1;
+        write_unlock(&p->lock);
+    }
+}
+
+#define gfn_lock(p,g,o)       p2m_lock(p)
+#define gfn_unlock(p,g,o)     p2m_unlock(p)
+#define p2m_read_lock(p)      read_lock(&(p)->lock)
+#define p2m_read_unlock(p)    read_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   ((p)->wcpu == current->processor)
+#define gfn_locked_by_me(p,g) p2m_locked_by_me(p)
+
 
 /* Sharing per page lock
  *
@@ -203,8 +229,8 @@ declare_mm_order_constraint(per_page_sha
  * counts, page lists, sweep parameters. */
 
 declare_mm_lock(pod)
-#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
-#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_lock(p) do { p2m_lock(p); mm_lock(pod, &(p)->pod.lock); } while (0)
+#define pod_unlock(p) do { mm_unlock(&(p)->pod.lock); p2m_unlock(p);} while (0)
 #define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
 
 /* Page alloc lock (per-domain)
diff -r 107285938c50 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Fri Apr 27 10:23:28 2012 +0100
@@ -71,7 +71,9 @@ boolean_param("hap_2mb", opt_hap_2mb);
 /* Init the datastructures for later use by the p2m code */
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
-    mm_lock_init(&p2m->lock);
+    rwlock_init(&p2m->lock);
+    p2m->wcount = 0;
+    p2m->wcpu = -1;
     mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
@@ -207,6 +209,59 @@ void __put_gfn(struct p2m_domain *p2m, u
     gfn_unlock(p2m, gfn, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page. */
+struct page_info *get_page_from_gfn_p2m(
+    struct domain *d, struct p2m_domain *p2m, unsigned long gfn,
+    p2m_type_t *t, p2m_access_t *a, p2m_query_t q)
+{
+    struct page_info *page = NULL;
+    p2m_access_t _a;
+    p2m_type_t _t;
+    mfn_t mfn;
+
+    /* Allow t or a to be NULL */
+    t = t ?: &_t;
+    a = a ?: &_a;
+
+    if ( likely(!p2m_locked_by_me(p2m)) )
+    {
+        /* Fast path: look up and get out */
+        p2m_read_lock(p2m);
+        mfn = __get_gfn_type_access(p2m, gfn, t, a, 0, NULL, 0);
+        if ( (p2m_is_ram(*t) || p2m_is_grant(*t))
+             && mfn_valid(mfn)
+             && !((q & P2M_UNSHARE) && p2m_is_shared(*t)) )
+        {
+            page = mfn_to_page(mfn);
+            if ( !get_page(page, d)
+                 /* Page could be shared */
+                 && !get_page(page, dom_cow) )
+                page = NULL;
+        }
+        p2m_read_unlock(p2m);
+
+        if ( page )
+            return page;
+
+        /* Error path: not a suitable GFN at all */
+        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) )
+            return NULL;
+    }
+
+    /* Slow path: take the write lock and do fixups */
+    mfn = get_gfn_type_access(p2m, gfn, t, a, q, NULL);
+    if ( p2m_is_ram(*t) && mfn_valid(mfn) )
+    {
+        page = mfn_to_page(mfn);
+        if ( !get_page(page, d) )
+            page = NULL;
+    }
+    put_gfn(d, gfn);
+
+    return page;
+}
+
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 107285938c50 xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/physdev.c	Fri Apr 27 10:23:28 2012 +0100
@@ -306,26 +306,27 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
     case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
+        struct page_info *page;
 
         ret = -EFAULT;
         if ( copy_from_guest(&info, arg, 1) != 0 )
             break;
 
         ret = -EINVAL;
-        mfn = get_gfn_untyped(current->domain, info.gmfn);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), v->domain,
-                                PGT_writable_page) )
+        page = get_page_from_gfn(current->domain, info.gmfn, NULL, P2M_ALLOC);
+        if ( !page )
+            break;
+        if ( !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(current->domain, info.gmfn);
+            put_page(page);
             break;
         }
+        mfn = page_to_mfn(page);
 
         if ( cmpxchg(&v->domain->arch.pv_domain.pirq_eoi_map_mfn,
                      0, mfn) != 0 )
         {
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -EBUSY;
             break;
         }
@@ -335,14 +336,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         {
             v->domain->arch.pv_domain.pirq_eoi_map_mfn = 0;
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -ENOSPC;
             break;
         }
         if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
             v->domain->arch.pv_domain.auto_unmask = 1;
 
-        put_gfn(current->domain, info.gmfn);
         ret = 0;
         break;
     }
diff -r 107285938c50 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/traps.c	Fri Apr 27 10:23:28 2012 +0100
@@ -662,9 +662,9 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
     case 0:
     {
         void *hypercall_page;
-        unsigned long mfn;
         unsigned long gmfn = val >> 12;
         unsigned int idx  = val & 0xfff;
+        struct page_info *page;
 
         if ( idx > 0 )
         {
@@ -674,24 +674,23 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
             return 0;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
-
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn);
+            if ( page )
+                put_page(page);
             gdprintk(XENLOG_WARNING,
                      "Bad GMFN %lx (MFN %lx) to MSR %08x\n",
-                     gmfn, mfn, base + idx);
+                     gmfn, page_to_mfn(page), base + idx);
             return 0;
         }
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gmfn);
+        put_page_and_type(page);
         break;
     }
 
@@ -2374,7 +2373,8 @@ static int emulate_privileged_op(struct 
             break;
 
         case 3: {/* Write CR3 */
-            unsigned long mfn, gfn;
+            unsigned long gfn;
+            struct page_info *page;
             domain_lock(v->domain);
             if ( !is_pv_32on64_vcpu(v) )
             {
@@ -2384,9 +2384,10 @@ static int emulate_privileged_op(struct 
                 gfn = compat_cr3_to_pfn(*reg);
 #endif
             }
-            mfn = get_gfn_untyped(v->domain, gfn);
-            rc = new_guest_cr3(mfn);
-            put_gfn(v->domain, gfn);
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            rc = page ? new_guest_cr3(page_to_mfn(page)) : 0;
+            if ( page )
+                put_page(page);
             domain_unlock(v->domain);
             if ( rc == 0 ) /* not okay */
                 goto fail;
diff -r 107285938c50 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/include/asm-x86/p2m.h	Fri Apr 27 10:23:28 2012 +0100
@@ -192,7 +192,10 @@ typedef unsigned int p2m_query_t;
 /* Per-p2m-table state */
 struct p2m_domain {
     /* Lock that protects updates to the p2m */
-    mm_lock_t          lock;
+    rwlock_t           lock;
+    int                wcpu;
+    int                wcount;
+    const char        *wfunc;
 
     /* Shadow translated domain: p2m mapping */
     pagetable_t        phys_table;
@@ -377,6 +380,33 @@ static inline mfn_t get_gfn_query_unlock
     return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page.
+ * This makes sure the page doesn't get freed (or shared) underfoot,
+ * and should be used by any path that intends to write to the backing page.
+ * Returns NULL if the page is not backed by RAM.
+ * The caller is responsible for calling put_page() afterwards. */
+struct page_info *get_page_from_gfn_p2m(struct domain *d,
+                                        struct p2m_domain *p2m,
+                                        unsigned long gfn,
+                                        p2m_type_t *t, p2m_access_t *a,
+                                        p2m_query_t q);
+
+static inline struct page_info *get_page_from_gfn(
+    struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
+{
+    struct page_info *page;
+
+    if ( paging_mode_translate(d) )
+        return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q);
+
+    /* Non-translated guests see 1-1 RAM mappings everywhere */
+    if (t)
+        *t = p2m_ram_rw;
+    page = __mfn_to_page(gfn);
+    return get_page(page, d) ? page : NULL;
+}
+
+
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)
 {
diff -r 107285938c50 xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/xsm/flask/hooks.c	Fri Apr 27 10:23:28 2012 +0100
@@ -1318,6 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
+    struct page_info *page;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1333,7 +1334,8 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+    mfn = page ? page_to_mfn(page) : INVALID_MFN;
 
     ad.sdom = d;
     ad.tdom = f;
@@ -1342,7 +1344,8 @@ static int flask_mmu_normal_update(struc
 
     rc = get_mfn_sid(fmfn, &fsid);
 
-    put_gfn(f, fmfn);
+    if ( page )
+        put_page(page);
 
     if ( rc )
         return rc;

--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--zYM0uCDKw75PZbzx--


From xen-devel-bounces@lists.xen.org Fri Apr 27 09:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhS3-0004z3-VE; Fri, 27 Apr 2012 09:26:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SNhS2-0004yv-BI
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 09:26:55 +0000
Received: from [193.109.254.147:29075] by server-8.bemta-14.messagelabs.com id
	9C/2C-23244-D566A9F4; Fri, 27 Apr 2012 09:26:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335518809!6645787!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4849 invoked from network); 27 Apr 2012 09:26:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 09:26:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SNhRt-000McR-4p; Fri, 27 Apr 2012 09:26:45 +0000
Date: Fri, 27 Apr 2012 10:26:45 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120427092645.GC86045@ocelot.phlegethon.org>
References: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx"
Content-Disposition: inline
In-Reply-To: <23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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


--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 20:02 -0700 on 26 Apr (1335470547), Andres Lagar-Cavilla wrote:
> > Can you please try the attached patch?  I think you'll need this one
> > plus the ones that take the locks out of the hpet code.
> 
> Right off the bat I'm getting a multitude of
> (XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
> And a hung dom0 during initramfs. I'm a little baffled as to why, but it's
> there (32 bit dom0, XenServer6).

Curses, I knew there'd be one somewhere.  I've been replacing
get_page_and_type_from_pagenr()s (which return 0 for success) with
old-school get_page_type()s (which return 1 for success) and not always
getting the right number of inversions.  That's a horrible horrible
beartrap of an API, BTW, which had me cursing at the screen, but I had
enough on my plate yesterday without touching _that_ code too!

> > Andres, this is basically the big-hammer version of your "take a
> > pagecount" changes, plus the change you made to hvmemul_rep_movs().
> > If this works I intend to follow it up with a patch to make some of the
> > read-modify-write paths avoid taking the lock (by using a
> > compare-exchange operation so they only take the lock on a write).  If
> > that succeeds I might drop put_gfn() altogether.
> 
> You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
> There are code paths that do get_gfn_query -> p2m_change_type -> put_gfn.
> But I guess those could lock the p2m up-front if they become the only
> consumers of put_gfn left.

Well, that's more or less what happens now.  I was thinking of replacing
any remaining

 (implicit) lock ; read ; think a bit ; maybe write ; unlock

code with the fast-path-friendlier:

 read ; think ; maybe-cmpxchg (and on failure undo or retry 

which avoids taking the write lock altogether if there's no work to do. 
But maybe there aren't many of those left now.  Obviously any path
which will always write should just take the write-lock first. 
 
> >  - grant-table operations still use the lock, because frankly I
> >    could not follow the current code, and it's quite late in the evening.
> 
> It's pretty complex with serious nesting, and ifdef's for arm and 32 bit.
> gfn_to_mfn_private callers will suffer from altering the current meaning,
> as put_gfn resolves to the right thing for the ifdef'ed arch. The other
> user is grant_transfer which also relies on the page *not* having an extra
> ref in steal_page. So it's a prime candidate to be left alone.

Sadly, I think it's not.  The PV backends will be doing lots of grant
ops, which shouldn't get serialized against all other P2M lookups. 

> > I also have a long list of uglinesses in the mm code that I found
> 
> Uh, ugly stuff, how could that have happened?

I can't imagine. :)  Certainly nothing to do with me thinking "I'll
clean that up when I get some time."

> I have a few preliminary observations on the patch. Pasting relevant bits
> here, since the body of the patch seems to have been lost by the email
> thread:
> 
> @@ -977,23 +976,25 @@ int arch_set_info_guest(
> ...
> +
> +        if (!paging_mode_refcounts(d)
> +            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
> replace with && !get_page_type() )

Yep.

> @@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
>              gfn = addr >> PAGE_SHIFT;
>          }
> 
> -        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
> +        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
> replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
> same logic when checking p2m_is_shared). Not truly related to your patch
> bit since we're at it.

OK, but not in this patch.

> Same, further down
> -        if ( !p2m_is_ram(p2mt) )
> +        if ( !page )
>          {
> -            put_gfn(curr->domain, gfn);
> +            if ( page )
> +                put_page(page);
> Last two lines are redundant

Yep.

> @@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
>     case HVMOP_modified_memory: a lot of error checking has been removed.

Yes, but it was bogus - there's a race between the actual modification
and the call, during which anything might have happened.  The best we
can do is throw log-dirty bits at everything, and the caller can't do
anything with the error anyway.

When I come to tidy up I'll just add a new mark_gfn_dirty function
and skip the pointless gfn->mfn->gfn translation on this path.

> arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing checking
> for target gfns of mmu updates of l2/3/4 entries. It seems that this
> wouldn't work anyways, that's why you killed it?

Yeah - since only L1es can point at foreign mappings it was all just
noise, and even if there had been real p2m lookups on those paths there
was no equivalent to the translate-in-place that happens in
mod_l1_entry so it would have been broken in a much worse way.

> +++ b/xen/arch/x86/mm/hap/guest_walk.c
> @@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
> ...
> +    if ( !top_page )
>      {
>          pfec[0] &= ~PFEC_page_present;
> -        __put_gfn(p2m, top_gfn);
> +        put_page(top_page);
> top_page is NULL here, remove put_page

Yep.

> get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
> locking is already done by get_gfn_type_access/__put_gfn

Yeah, but I was writing that with half an eye on killing that lock. :) 
I'll drop them for now.

> (hope those observations made sense without inlining them in the actual
> patch)

Yes, absolutely - thanks for the review!

If we can get this to work well enough I'll tidy it up into a sensible
series next week.   In the meantime, an updated verison of the
monster patch is attached. 

Cheers,

Tim.

--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=get-page-from-gfn

# HG changeset patch
# Parent 107285938c50f82667bd4d014820b439a077c22c

diff -r 107285938c50 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domain.c	Fri Apr 27 10:23:28 2012 +0100
@@ -716,7 +716,7 @@ int arch_set_info_guest(
 {
     struct domain *d = v->domain;
     unsigned long cr3_gfn;
-    unsigned long cr3_pfn = INVALID_MFN;
+    struct page_info *cr3_page;
     unsigned long flags, cr4;
     unsigned int i;
     int rc = 0, compat;
@@ -925,46 +925,45 @@ int arch_set_info_guest(
     if ( !compat )
     {
         cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_base_page_table)) )
+        if ( !cr3_page )
         {
-            put_gfn(d, cr3_gfn);
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+        if ( !paging_mode_refcounts(d)
+             && !get_page_type(cr3_page, PGT_base_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
-        v->arch.guest_table = pagetable_from_pfn(cr3_pfn);
-        put_gfn(d, cr3_gfn);
+        v->arch.guest_table = pagetable_from_page(cr3_page);
 #ifdef __x86_64__
         if ( c.nat->ctrlreg[1] )
         {
             cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]);
-            cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+            cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-            if ( !mfn_valid(cr3_pfn) ||
-                 (paging_mode_refcounts(d)
-                  ? !get_page(mfn_to_page(cr3_pfn), d)
-                  : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                       PGT_base_page_table)) )
+            if ( !cr3_page ||
+                 (!paging_mode_refcounts(d)
+                  && !get_page_type(cr3_page, PGT_base_page_table)) )
             {
-                cr3_pfn = pagetable_get_pfn(v->arch.guest_table);
+                if (cr3_page)
+                    put_page(cr3_page);
+                cr3_page = pagetable_get_page(v->arch.guest_table);
                 v->arch.guest_table = pagetable_null();
                 if ( paging_mode_refcounts(d) )
-                    put_page(mfn_to_page(cr3_pfn));
+                    put_page(cr3_page);
                 else
-                    put_page_and_type(mfn_to_page(cr3_pfn));
-                put_gfn(d, cr3_gfn); 
+                    put_page_and_type(cr3_page);
                 destroy_gdt(v);
                 return -EINVAL;
             }
 
-            v->arch.guest_table_user = pagetable_from_pfn(cr3_pfn);
-            put_gfn(d, cr3_gfn); 
+            v->arch.guest_table_user = pagetable_from_page(cr3_page);
         }
         else if ( !(flags & VGCF_in_kernel) )
         {
@@ -977,23 +976,25 @@ int arch_set_info_guest(
         l4_pgentry_t *l4tab;
 
         cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]);
-        cr3_pfn = get_gfn_untyped(d, cr3_gfn);
+        cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
-        if ( !mfn_valid(cr3_pfn) ||
-             (paging_mode_refcounts(d)
-              ? !get_page(mfn_to_page(cr3_pfn), d)
-              : !get_page_and_type(mfn_to_page(cr3_pfn), d,
-                                   PGT_l3_page_table)) )
+        if ( !cr3_page)
         {
-            put_gfn(d, cr3_gfn); 
+            destroy_gdt(v);
+            return -EINVAL;
+        }
+
+        if (!paging_mode_refcounts(d)
+            && !get_page_type(cr3_page, PGT_l3_page_table) )
+        {
+            put_page(cr3_page);
             destroy_gdt(v);
             return -EINVAL;
         }
 
         l4tab = __va(pagetable_get_paddr(v->arch.guest_table));
-        *l4tab = l4e_from_pfn(
-            cr3_pfn, _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
-        put_gfn(d, cr3_gfn); 
+        *l4tab = l4e_from_pfn(page_to_mfn(cr3_page),
+            _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED);
 #endif
     }
 
@@ -1064,7 +1065,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     struct domain *d = v->domain;
     void *mapping;
     vcpu_info_t *new_info;
-    unsigned long mfn;
+    struct page_info *page;
     int i;
 
     if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) )
@@ -1077,19 +1078,20 @@ map_vcpu_info(struct vcpu *v, unsigned l
     if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) )
         return -EINVAL;
 
-    mfn = get_gfn_untyped(d, gfn);
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gfn); 
+        put_page(page);
         return -EINVAL;
     }
 
-    mapping = map_domain_page_global(mfn);
+    mapping = __map_domain_page_global(page);
     if ( mapping == NULL )
     {
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gfn); 
+        put_page_and_type(page);
         return -ENOMEM;
     }
 
@@ -1106,7 +1108,7 @@ map_vcpu_info(struct vcpu *v, unsigned l
     }
 
     v->vcpu_info = new_info;
-    v->arch.pv_vcpu.vcpu_info_mfn = mfn;
+    v->arch.pv_vcpu.vcpu_info_mfn = page_to_mfn(page);
 
     /* Set new vcpu_info pointer /before/ setting pending flags. */
     wmb();
@@ -1119,7 +1121,6 @@ map_vcpu_info(struct vcpu *v, unsigned l
     for ( i = 0; i < BITS_PER_EVTCHN_WORD(d); i++ )
         set_bit(i, &vcpu_info(v, evtchn_pending_sel));
 
-    put_gfn(d, gfn); 
     return 0;
 }
 
diff -r 107285938c50 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/domctl.c	Fri Apr 27 10:23:28 2012 +0100
@@ -202,16 +202,16 @@ long arch_do_domctl(
 
                 for ( j = 0; j < k; j++ )
                 {
-                    unsigned long type = 0, mfn = get_gfn_untyped(d, arr[j]);
+                    unsigned long type = 0;
 
-                    page = mfn_to_page(mfn);
+                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
 
-                    if ( unlikely(!mfn_valid(mfn)) ||
-                         unlikely(is_xen_heap_mfn(mfn)) )
+                    if ( unlikely(!page) ||
+                         unlikely(is_xen_heap_page(page)) )
                         type = XEN_DOMCTL_PFINFO_XTAB;
                     else if ( xsm_getpageframeinfo(page) != 0 )
                         ;
-                    else if ( likely(get_page(page, d)) )
+                    else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
                         {
@@ -231,13 +231,10 @@ long arch_do_domctl(
 
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |= XEN_DOMCTL_PFINFO_LPINTAB;
+                    }
 
+                    if ( page )
                         put_page(page);
-                    }
-                    else
-                        type = XEN_DOMCTL_PFINFO_XTAB;
-
-                    put_gfn(d, arr[j]);
                     arr[j] = type;
                 }
 
@@ -304,21 +301,21 @@ long arch_do_domctl(
             {      
                 struct page_info *page;
                 unsigned long gfn = arr32[j];
-                unsigned long mfn = get_gfn_untyped(d, gfn);
 
-                page = mfn_to_page(mfn);
+                page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
 
                 if ( domctl->cmd == XEN_DOMCTL_getpageframeinfo3)
                     arr32[j] = 0;
 
-                if ( unlikely(!mfn_valid(mfn)) ||
-                     unlikely(is_xen_heap_mfn(mfn)) )
+                if ( unlikely(!page) ||
+                     unlikely(is_xen_heap_page(page)) )
                     arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
                 else if ( xsm_getpageframeinfo(page) != 0 )
                 {
-                    put_gfn(d, gfn); 
+                    put_page(page);
                     continue;
-                } else if ( likely(get_page(page, d)) )
+                }
+                else
                 {
                     unsigned long type = 0;
 
@@ -341,12 +338,10 @@ long arch_do_domctl(
                     if ( page->u.inuse.type_info & PGT_pinned )
                         type |= XEN_DOMCTL_PFINFO_LPINTAB;
                     arr32[j] |= type;
+                }
+
+                if ( page )
                     put_page(page);
-                }
-                else
-                    arr32[j] |= XEN_DOMCTL_PFINFO_XTAB;
-
-                put_gfn(d, gfn); 
             }
 
             if ( copy_to_guest_offset(domctl->u.getpageframeinfo2.array,
@@ -419,7 +414,7 @@ long arch_do_domctl(
     {
         struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long gmfn = domctl->u.hypercall_init.gmfn;
-        unsigned long mfn;
+        struct page_info *page;
         void *hypercall_page;
 
         ret = -ESRCH;
@@ -433,26 +428,25 @@ long arch_do_domctl(
             break;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
 
         ret = -EACCES;
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn); 
+            if ( page )
+                put_page(page);
             rcu_unlock_domain(d);
             break;
         }
 
         ret = 0;
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
+        put_page_and_type(page);
 
-        put_gfn(d, gmfn); 
         rcu_unlock_domain(d);
     }
     break;
diff -r 107285938c50 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/emulate.c	Fri Apr 27 10:23:28 2012 +0100
@@ -60,34 +60,25 @@ static int hvmemul_do_io(
     ioreq_t *p = get_ioreq(curr);
     unsigned long ram_gfn = paddr_to_pfn(ram_gpa);
     p2m_type_t p2mt;
-    mfn_t ram_mfn;
+    struct page_info *ram_page;
     int rc;
 
     /* Check for paged out page */
-    ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
+    ram_page = get_page_from_gfn(curr->domain, ram_gfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         p2m_mem_paging_populate(curr->domain, ram_gfn);
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(curr->domain, ram_gfn); 
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_RETRY;
     }
 
-    /* Maintain a ref on the mfn to ensure liveness. Put the gfn
-     * to avoid potential deadlock wrt event channel lock, later. */
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        if ( !get_page(mfn_to_page(mfn_x(ram_mfn)),
-             curr->domain) )
-        {
-            put_gfn(curr->domain, ram_gfn);
-            return X86EMUL_RETRY;
-        }
-    put_gfn(curr->domain, ram_gfn);
-
     /*
      * Weird-sized accesses have undefined behaviour: we discard writes
      * and read all-ones.
@@ -98,8 +89,8 @@ static int hvmemul_do_io(
         ASSERT(p_data != NULL); /* cannot happen with a REP prefix */
         if ( dir == IOREQ_READ )
             memset(p_data, ~0, size);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -120,8 +111,8 @@ static int hvmemul_do_io(
             unsigned int bytes = vio->mmio_large_write_bytes;
             if ( (addr >= pa) && ((addr + size) <= (pa + bytes)) )
             {
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -133,8 +124,8 @@ static int hvmemul_do_io(
             {
                 memcpy(p_data, &vio->mmio_large_read[addr - pa],
                        size);
-                if ( mfn_valid(mfn_x(ram_mfn)) )
-                    put_page(mfn_to_page(mfn_x(ram_mfn)));
+                if ( ram_page )
+                    put_page(ram_page);
                 return X86EMUL_OKAY;
             }
         }
@@ -148,8 +139,8 @@ static int hvmemul_do_io(
         vio->io_state = HVMIO_none;
         if ( p_data == NULL )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_UNHANDLEABLE;
         }
         goto finish_access;
@@ -159,13 +150,13 @@ static int hvmemul_do_io(
              (addr == (vio->mmio_large_write_pa +
                        vio->mmio_large_write_bytes)) )
         {
-            if ( mfn_valid(mfn_x(ram_mfn)) )
-                put_page(mfn_to_page(mfn_x(ram_mfn)));
+            if ( ram_page )
+                put_page(ram_page);
             return X86EMUL_RETRY;
         }
     default:
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -173,8 +164,8 @@ static int hvmemul_do_io(
     {
         gdprintk(XENLOG_WARNING, "WARNING: io already pending (%d)?\n",
                  p->state);
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -226,8 +217,8 @@ static int hvmemul_do_io(
 
     if ( rc != X86EMUL_OKAY )
     {
-        if ( mfn_valid(mfn_x(ram_mfn)) )
-            put_page(mfn_to_page(mfn_x(ram_mfn)));
+        if ( ram_page )
+            put_page(ram_page);
         return rc;
     }
 
@@ -263,8 +254,8 @@ static int hvmemul_do_io(
         }
     }
 
-    if ( mfn_valid(mfn_x(ram_mfn)) )
-        put_page(mfn_to_page(mfn_x(ram_mfn)));
+    if ( ram_page )
+        put_page(ram_page);
     return X86EMUL_OKAY;
 }
 
@@ -686,7 +677,6 @@ static int hvmemul_rep_movs(
     p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
-    struct two_gfns tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -714,25 +704,17 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
-                 current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 P2M_ALLOC, &tg);
+    /* Check for MMIO ops */
+    (void) get_gfn_query_unlocked(current->domain, sgpa >> PAGE_SHIFT, &sp2mt);
+    (void) get_gfn_query_unlocked(current->domain, dgpa >> PAGE_SHIFT, &dp2mt);
 
-    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( sp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
-    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
-    {
-        rc = hvmemul_do_mmio(
+    if ( dp2mt == p2m_mmio_dm )
+        return hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_two_gfns(&tg);
-        return rc;
-    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -747,10 +729,7 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -759,10 +738,7 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
-    {
-        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
-    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -773,7 +749,6 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 107285938c50 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Fri Apr 27 10:23:28 2012 +0100
@@ -395,48 +395,41 @@ int prepare_ring_for_helper(
 {
     struct page_info *page;
     p2m_type_t p2mt;
-    unsigned long mfn;
     void *va;
 
-    mfn = mfn_x(get_gfn_unshare(d, gmfn, &p2mt));
-    if ( !p2m_is_ram(p2mt) )
-    {
-        put_gfn(d, gmfn);
-        return -EINVAL;
-    }
+    page = get_page_from_gfn(d, gmfn, &p2mt, P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
     {
-        put_gfn(d, gmfn);
+        if ( page )
+            put_page(page);
         return -ENOENT;
     }
-    ASSERT(mfn_valid(mfn));
-
-    page = mfn_to_page(mfn);
-    if ( !get_page_and_type(page, d, PGT_writable_page) )
+    if ( !page )
+        return -EINVAL;
+
+    if ( !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn);
+        put_page(page);
         return -EINVAL;
     }
 
-    va = map_domain_page_global(mfn);
+    va = __map_domain_page_global(page);
     if ( va == NULL )
     {
         put_page_and_type(page);
-        put_gfn(d, gmfn);
         return -ENOMEM;
     }
 
     *_va = va;
     *_page = page;
 
-    put_gfn(d, gmfn);
-
     return 0;
 }
 
@@ -1607,8 +1600,8 @@ int hvm_mov_from_cr(unsigned int cr, uns
 int hvm_set_cr0(unsigned long value)
 {
     struct vcpu *v = current;
-    p2m_type_t p2mt;
-    unsigned long gfn, mfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    unsigned long gfn, old_value = v->arch.hvm_vcpu.guest_cr[0];
+    struct page_info *page;
 
     HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR0 value = %lx", value);
 
@@ -1647,23 +1640,20 @@ int hvm_set_cr0(unsigned long value)
         {
             /* The guest CR3 must be pointing to the guest physical. */
             gfn = v->arch.hvm_vcpu.guest_cr[3]>>PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(v->domain, gfn, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-                 !get_page(mfn_to_page(mfn), v->domain))
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, gfn);
-                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx (mfn=%lx)\n",
-                         v->arch.hvm_vcpu.guest_cr[3], mfn);
+                gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx\n",
+                         v->arch.hvm_vcpu.guest_cr[3]);
                 domain_crash(v->domain);
                 return X86EMUL_UNHANDLEABLE;
             }
 
             /* Now arch.guest_table points to machine physical. */
-            v->arch.guest_table = pagetable_from_pfn(mfn);
+            v->arch.guest_table = pagetable_from_page(page);
 
             HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx, mfn = %lx",
-                        v->arch.hvm_vcpu.guest_cr[3], mfn);
-            put_gfn(v->domain, gfn);
+                        v->arch.hvm_vcpu.guest_cr[3], page_to_mfn(page));
         }
     }
     else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) )
@@ -1738,26 +1728,21 @@ int hvm_set_cr0(unsigned long value)
 
 int hvm_set_cr3(unsigned long value)
 {
-    unsigned long mfn;
-    p2m_type_t p2mt;
     struct vcpu *v = current;
+    struct page_info *page;
 
     if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
          (value != v->arch.hvm_vcpu.guest_cr[3]) )
     {
         /* Shadow-mode CR3 change. Check PDBR and update refcounts. */
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "CR3 value = %lx", value);
-        mfn = mfn_x(get_gfn(v->domain, value >> PAGE_SHIFT, &p2mt));
-        if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) ||
-             !get_page(mfn_to_page(mfn), v->domain) )
-        {
-              put_gfn(v->domain, value >> PAGE_SHIFT);
-              goto bad_cr3;
-        }
+        page = get_page_from_gfn(v->domain, value >> PAGE_SHIFT,
+                                 NULL, P2M_ALLOC);
+        if ( !page )
+            goto bad_cr3;
 
         put_page(pagetable_get_page(v->arch.guest_table));
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        put_gfn(v->domain, value >> PAGE_SHIFT);
+        v->arch.guest_table = pagetable_from_page(page);
 
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
     }
@@ -1914,46 +1899,29 @@ int hvm_virtual_to_linear_addr(
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
     void *map;
-    unsigned long mfn;
     p2m_type_t p2mt;
-    struct page_info *pg;
+    struct page_info *page;
     struct domain *d = current->domain;
-    int rc;
-
-    mfn = mfn_x(writable
-                ? get_gfn_unshare(d, gfn, &p2mt)
-                : get_gfn(d, gfn, &p2mt));
-    if ( (p2m_is_shared(p2mt) && writable) || !p2m_is_ram(p2mt) )
+
+    page = get_page_from_gfn(d, gfn, &p2mt,
+                             writable ? P2M_UNSHARE : P2M_ALLOC);
+    if ( (p2m_is_shared(p2mt) && writable) || !page )
     {
-        put_gfn(d, gfn);
+        if ( page )
+            put_page(page);
         return NULL;
     }
     if ( p2m_is_paging(p2mt) )
     {
-        put_gfn(d, gfn);
+        put_page(page);
         p2m_mem_paging_populate(d, gfn);
         return NULL;
     }
 
-    ASSERT(mfn_valid(mfn));
-
     if ( writable )
-        paging_mark_dirty(d, mfn);
-
-    /* Get a ref on the page, considering that it could be shared */
-    pg = mfn_to_page(mfn);
-    rc = get_page(pg, d);
-    if ( !rc && !writable )
-        /* Page could be shared */
-        rc = get_page(pg, dom_cow);
-    if ( !rc )
-    {
-        put_gfn(d, gfn);
-        return NULL;
-    }
-
-    map = map_domain_page(mfn);
-    put_gfn(d, gfn);
+        paging_mark_dirty(d, page_to_mfn(page));
+
+    map = __map_domain_page(page);
     return map;
 }
 
@@ -2358,7 +2326,8 @@ static enum hvm_copy_result __hvm_copy(
     void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2402,32 +2371,33 @@ static enum hvm_copy_result __hvm_copy(
             gfn = addr >> PAGE_SHIFT;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( flags & HVMCOPY_to_guest )
         {
@@ -2437,12 +2407,12 @@ static enum hvm_copy_result __hvm_copy(
                 if ( xchg(&lastpage, gfn) != gfn )
                     gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                              " memory page. gfn=%#lx, mfn=%#lx\n",
-                             gfn, mfn);
+                             gfn, page_to_mfn(page));
             }
             else
             {
                 memcpy(p, buf, count);
-                paging_mark_dirty(curr->domain, mfn);
+                paging_mark_dirty(curr->domain, page_to_mfn(page));
             }
         }
         else
@@ -2455,7 +2425,7 @@ static enum hvm_copy_result __hvm_copy(
         addr += count;
         buf  += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -2464,7 +2434,8 @@ static enum hvm_copy_result __hvm_copy(
 static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 {
     struct vcpu *curr = current;
-    unsigned long gfn, mfn;
+    unsigned long gfn;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
     int count, todo = size;
@@ -2500,32 +2471,35 @@ static enum hvm_copy_result __hvm_clear(
             return HVMCOPY_bad_gva_to_gfn;
         }
 
-        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+        page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE);
 
         if ( p2m_is_paging(p2mt) )
         {
+            if ( page )
+                put_page(page);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_gfn_shared;
         }
         if ( p2m_is_grant(p2mt) )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_unhandleable;
         }
-        if ( !p2m_is_ram(p2mt) )
+        if ( !page )
         {
-            put_gfn(curr->domain, gfn);
+            if ( page )
+                put_page(page);
             return HVMCOPY_bad_gfn_to_mfn;
         }
-        ASSERT(mfn_valid(mfn));
-
-        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
         if ( p2mt == p2m_ram_ro )
         {
@@ -2533,19 +2507,19 @@ static enum hvm_copy_result __hvm_clear(
             if ( xchg(&lastpage, gfn) != gfn )
                 gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
                         " memory page. gfn=%#lx, mfn=%#lx\n",
-                        gfn, mfn);
+                         gfn, page_to_mfn(page));
         }
         else
         {
             memset(p, 0x00, count);
-            paging_mark_dirty(curr->domain, mfn);
+            paging_mark_dirty(curr->domain, page_to_mfn(page));
         }
 
         unmap_domain_page(p);
 
         addr += count;
         todo -= count;
-        put_gfn(curr->domain, gfn);
+        put_page(page);
     }
 
     return HVMCOPY_okay;
@@ -4000,35 +3974,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
 
         for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
         {
-            p2m_type_t t;
-            mfn_t mfn = get_gfn_unshare(d, pfn, &t);
-            if ( p2m_is_paging(t) )
+            struct page_info *page;
+            page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
+            if ( page )
             {
-                put_gfn(d, pfn);
-                p2m_mem_paging_populate(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            if( p2m_is_shared(t) )
-            {
-                /* If it insists on not unsharing itself, crash the domain 
-                 * rather than crashing the host down in mark dirty */
-                gdprintk(XENLOG_WARNING,
-                         "shared pfn 0x%lx modified?\n", pfn);
-                domain_crash(d);
-                put_gfn(d, pfn);
-                rc = -EINVAL;
-                goto param_fail3;
-            }
-            
-            if ( mfn_x(mfn) != INVALID_MFN )
-            {
-                paging_mark_dirty(d, mfn_x(mfn));
+                paging_mark_dirty(d, page_to_mfn(page));
                 /* These are most probably not page tables any more */
                 /* don't take a long time and don't die either */
-                sh_remove_shadows(d->vcpu[0], mfn, 1, 0);
+                sh_remove_shadows(d->vcpu[0], _mfn(page_to_mfn(page)), 1, 0);
+                put_page(page);
             }
-            put_gfn(d, pfn);
         }
 
     param_fail3:
diff -r 107285938c50 xen/arch/x86/hvm/stdvga.c
--- a/xen/arch/x86/hvm/stdvga.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/stdvga.c	Fri Apr 27 10:23:28 2012 +0100
@@ -482,7 +482,8 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_to_guest_phys(data, &tmp, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                            d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     /*
                      * The only case we handle is vga_mem <-> vga_mem.
                      * Anything else disables caching and leaves it to qemu-dm.
@@ -490,11 +491,12 @@ static int mmio_move(struct hvm_hw_stdvg
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
+                    ASSERT(!dp);
                     stdvga_mem_write(data, tmp, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 data += sign * p->size;
                 addr += sign * p->size;
@@ -508,15 +510,16 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_from_guest_phys(&tmp, data, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
+                    struct page_info *dp = get_page_from_gfn(
+                        d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC);
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
                     {
-                        put_gfn(d, data >> PAGE_SHIFT);
+                        if ( dp )
+                            put_page(dp);
                         return 0;
                     }
                     tmp = stdvga_mem_read(data, p->size);
-                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 stdvga_mem_write(addr, tmp, p->size);
                 data += sign * p->size;
diff -r 107285938c50 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/viridian.c	Fri Apr 27 10:23:28 2012 +0100
@@ -134,18 +134,19 @@ void dump_apic_assist(struct vcpu *v)
 static void enable_hypercall_page(struct domain *d)
 {
     unsigned long gmfn = d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     /*
      * We set the bit 31 in %eax (reserved field in the Viridian hypercall
@@ -162,15 +163,14 @@ static void enable_hypercall_page(struct
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 void initialize_apic_assist(struct vcpu *v)
 {
     struct domain *d = v->domain;
     unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn;
-    unsigned long mfn = get_gfn_untyped(d, gmfn);
+    struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
     uint8_t *p;
 
     /*
@@ -183,22 +183,22 @@ void initialize_apic_assist(struct vcpu 
      * details of how Windows uses the page.
      */
 
-    if ( !mfn_valid(mfn) ||
-         !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+    if ( !page || !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(d, gmfn); 
-        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn);
+        if ( page )
+            put_page(page);
+        gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
+                 page_to_mfn(page));
         return;
     }
 
-    p = map_domain_page(mfn);
+    p = __map_domain_page(page);
 
     *(u32 *)p = 0;
 
     unmap_domain_page(p);
 
-    put_page_and_type(mfn_to_page(mfn));
-    put_gfn(d, gmfn); 
+    put_page_and_type(page);
 }
 
 int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
diff -r 107285938c50 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Apr 27 10:23:28 2012 +0100
@@ -480,17 +480,16 @@ static void vmx_vmcs_save(struct vcpu *v
 static int vmx_restore_cr0_cr3(
     struct vcpu *v, unsigned long cr0, unsigned long cr3)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
 
     if ( paging_mode_shadow(v->domain) )
     {
         if ( cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3);
                 return -EINVAL;
             }
@@ -499,9 +498,8 @@ static int vmx_restore_cr0_cr3(
         if ( hvm_paging_enabled(v) )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( cr0 & X86_CR0_PG )
-            put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+        v->arch.guest_table =
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = cr0 | X86_CR0_ET;
@@ -1026,8 +1024,9 @@ static void vmx_set_interrupt_shadow(str
 
 static void vmx_load_pdptrs(struct vcpu *v)
 {
-    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn;
+    unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3];
     uint64_t *guest_pdptrs;
+    struct page_info *page;
     p2m_type_t p2mt;
     char *p;
 
@@ -1038,24 +1037,19 @@ static void vmx_load_pdptrs(struct vcpu 
     if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
 
-    mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-    if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || 
-         /* If we didn't succeed in unsharing, get_page will fail
-          * (page still belongs to dom_cow) */
-         !get_page(mfn_to_page(mfn), v->domain) )
+    page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE);
+    if ( !page )
     {
         /* Ideally you don't want to crash but rather go into a wait 
          * queue, but this is the wrong place. We're holding at least
          * the paging lock */
         gdprintk(XENLOG_ERR,
-                 "Bad cr3 on load pdptrs gfn %lx mfn %lx type %d\n",
-                 cr3 >> PAGE_SHIFT, mfn, (int) p2mt);
-        put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+                 "Bad cr3 on load pdptrs gfn %lx type %d\n",
+                 cr3 >> PAGE_SHIFT, (int) p2mt);
         goto crash;
     }
-    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
-
-    p = map_domain_page(mfn);
+
+    p = __map_domain_page(page);
 
     guest_pdptrs = (uint64_t *)(p + (cr3 & ~PAGE_MASK));
 
@@ -1081,7 +1075,7 @@ static void vmx_load_pdptrs(struct vcpu 
     vmx_vmcs_exit(v);
 
     unmap_domain_page(p);
-    put_page(mfn_to_page(mfn));
+    put_page(page);
     return;
 
  crash:
diff -r 107285938c50 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm.c	Fri Apr 27 10:23:28 2012 +0100
@@ -651,7 +651,8 @@ int map_ldt_shadow_page(unsigned int off
 {
     struct vcpu *v = current;
     struct domain *d = v->domain;
-    unsigned long gmfn, mfn;
+    unsigned long gmfn;
+    struct page_info *page;
     l1_pgentry_t l1e, nl1e;
     unsigned long gva = v->arch.pv_vcpu.ldt_base + (off << PAGE_SHIFT);
     int okay;
@@ -663,28 +664,24 @@ int map_ldt_shadow_page(unsigned int off
         return 0;
 
     gmfn = l1e_get_pfn(l1e);
-    mfn = get_gfn_untyped(d, gmfn);
-    if ( unlikely(!mfn_valid(mfn)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+    if ( unlikely(!page) )
+        return 0;
+
+    okay = get_page_type(page, PGT_seg_desc_page);
+    if ( unlikely(!okay) )
     {
-        put_gfn(d, gmfn); 
+        put_page(page);
         return 0;
     }
 
-    okay = get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page);
-    if ( unlikely(!okay) )
-    {
-        put_gfn(d, gmfn); 
-        return 0;
-    }
-
-    nl1e = l1e_from_pfn(mfn, l1e_get_flags(l1e) | _PAGE_RW);
+    nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW);
 
     spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock);
     l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e);
     v->arch.pv_vcpu.shadow_ldt_mapcnt++;
     spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock);
 
-    put_gfn(d, gmfn); 
     return 1;
 }
 
@@ -1819,7 +1816,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
 {
     l1_pgentry_t ol1e;
     struct domain *pt_dom = pt_vcpu->domain;
-    p2m_type_t p2mt;
     int rc = 0;
 
     if ( unlikely(__copy_from_user(&ol1e, pl1e, sizeof(ol1e)) != 0) )
@@ -1835,22 +1831,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
     if ( l1e_get_flags(nl1e) & _PAGE_PRESENT )
     {
         /* Translate foreign guest addresses. */
-        unsigned long mfn, gfn;
-        gfn = l1e_get_pfn(nl1e);
-        mfn = mfn_x(get_gfn(pg_dom, gfn, &p2mt));
-        if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) )
+        struct page_info *page = NULL;
+        if ( paging_mode_translate(pg_dom) )
         {
-            put_gfn(pg_dom, gfn);
-            return -EINVAL;
+            page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, P2M_ALLOC);
+            if ( !page )
+                return -EINVAL;
+            nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(nl1e));
         }
-        ASSERT((mfn & ~(PADDR_MASK >> PAGE_SHIFT)) == 0);
-        nl1e = l1e_from_pfn(mfn, l1e_get_flags(nl1e));
 
         if ( unlikely(l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)) )
         {
             MEM_LOG("Bad L1 flags %x",
                     l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom));
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return -EINVAL;
         }
 
@@ -1860,15 +1855,21 @@ static int mod_l1_entry(l1_pgentry_t *pl
             adjust_guest_l1e(nl1e, pt_dom);
             if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                               preserve_ad) )
+            {
+                if ( page )
+                    put_page(page);
                 return 0;
-            put_gfn(pg_dom, gfn);
+            }
+            if ( page )
+                put_page(page);
             return -EBUSY;
         }
 
         switch ( rc = get_page_from_l1e(nl1e, pt_dom, pg_dom) )
         {
         default:
-            put_gfn(pg_dom, gfn);
+            if ( page )
+                put_page(page);
             return rc;
         case 0:
             break;
@@ -1876,7 +1877,9 @@ static int mod_l1_entry(l1_pgentry_t *pl
             l1e_remove_flags(nl1e, _PAGE_RW);
             break;
         }
-        
+        if ( page )
+            put_page(page);
+
         adjust_guest_l1e(nl1e, pt_dom);
         if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                     preserve_ad)) )
@@ -1884,7 +1887,6 @@ static int mod_l1_entry(l1_pgentry_t *pl
             ol1e = nl1e;
             rc = -EBUSY;
         }
-        put_gfn(pg_dom, gfn);
     }
     else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
                                      preserve_ad)) )
@@ -3042,7 +3044,6 @@ int do_mmuext_op(
             type = PGT_l4_page_table;
 
         pin_page: {
-            unsigned long mfn;
             struct page_info *page;
 
             /* Ignore pinning of invalid paging levels. */
@@ -3052,25 +3053,28 @@ int do_mmuext_op(
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            rc = get_page_and_type_from_pagenr(mfn, type, pg_owner, 0, 1);
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
+            {
+                rc = -EINVAL;
+                break;
+            }
+
+            rc = get_page_type_preemptible(page, type);
             okay = !rc;
             if ( unlikely(!okay) )
             {
                 if ( rc == -EINTR )
                     rc = -EAGAIN;
                 else if ( rc != -EAGAIN )
-                    MEM_LOG("Error while pinning mfn %lx", mfn);
-                put_gfn(pg_owner, op.arg1.mfn);
+                    MEM_LOG("Error while pinning mfn %lx", page_to_mfn(page));
+                put_page(page);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( (rc = xsm_memory_pin_page(d, page)) != 0 )
             {
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
@@ -3078,16 +3082,15 @@ int do_mmuext_op(
             if ( unlikely(test_and_set_bit(_PGT_pinned,
                                            &page->u.inuse.type_info)) )
             {
-                MEM_LOG("Mfn %lx already pinned", mfn);
+                MEM_LOG("Mfn %lx already pinned", page_to_mfn(page));
                 put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
                 okay = 0;
                 break;
             }
 
             /* A page is dirtied when its pin status is set. */
-            paging_mark_dirty(pg_owner, mfn);
-           
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             /* We can race domain destruction (domain_relinquish_resources). */
             if ( unlikely(pg_owner != d) )
             {
@@ -3099,35 +3102,29 @@ int do_mmuext_op(
                 spin_unlock(&pg_owner->page_alloc_lock);
                 if ( drop_ref )
                     put_page_and_type(page);
-                put_gfn(pg_owner, op.arg1.mfn);
             }
 
             break;
         }
 
         case MMUEXT_UNPIN_TABLE: {
-            unsigned long mfn;
             struct page_info *page;
 
             if ( paging_mode_refcounts(pg_owner) )
                 break;
 
-            mfn = get_gfn_untyped(pg_owner, op.arg1.mfn);
-            if ( unlikely(!(okay = get_page_from_pagenr(mfn, pg_owner))) )
+            page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!page) )
             {
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx bad domain", mfn);
+                MEM_LOG("Mfn %lx bad domain", op.arg1.mfn);
                 break;
             }
 
-            page = mfn_to_page(mfn);
-
             if ( !test_and_clear_bit(_PGT_pinned, &page->u.inuse.type_info) )
             {
                 okay = 0;
                 put_page(page);
-                put_gfn(pg_owner, op.arg1.mfn);
-                MEM_LOG("Mfn %lx not pinned", mfn);
+                MEM_LOG("Mfn %lx not pinned", op.arg1.mfn);
                 break;
             }
 
@@ -3135,40 +3132,43 @@ int do_mmuext_op(
             put_page(page);
 
             /* A page is dirtied when its pin status is cleared. */
-            paging_mark_dirty(pg_owner, mfn);
-
-            put_gfn(pg_owner, op.arg1.mfn);
+            paging_mark_dirty(pg_owner, page_to_mfn(page));
+
             break;
         }
 
         case MMUEXT_NEW_BASEPTR:
-            okay = new_guest_cr3(get_gfn_untyped(d, op.arg1.mfn));
-            put_gfn(d, op.arg1.mfn);
+            okay = (!paging_mode_translate(d)
+                    && new_guest_cr3(op.arg1.mfn));
             break;
+
         
 #ifdef __x86_64__
         case MMUEXT_NEW_USER_BASEPTR: {
-            unsigned long old_mfn, mfn;
-
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            if ( mfn != 0 )
+            unsigned long old_mfn;
+
+            if ( paging_mode_translate(current->domain) )
+            {
+                okay = 0;
+                break;
+            }
+
+            if ( op.arg1.mfn != 0 )
             {
                 if ( paging_mode_refcounts(d) )
-                    okay = get_page_from_pagenr(mfn, d);
+                    okay = get_page_from_pagenr(op.arg1.mfn, d);
                 else
                     okay = !get_page_and_type_from_pagenr(
-                        mfn, PGT_root_page_table, d, 0, 0);
+                        op.arg1.mfn, PGT_root_page_table, d, 0, 0);
                 if ( unlikely(!okay) )
                 {
-                    put_gfn(d, op.arg1.mfn);
-                    MEM_LOG("Error while installing new mfn %lx", mfn);
+                    MEM_LOG("Error while installing new mfn %lx", op.arg1.mfn);
                     break;
                 }
             }
 
             old_mfn = pagetable_get_pfn(curr->arch.guest_table_user);
-            curr->arch.guest_table_user = pagetable_from_pfn(mfn);
-            put_gfn(d, op.arg1.mfn);
+            curr->arch.guest_table_user = pagetable_from_pfn(op.arg1.mfn);
 
             if ( old_mfn != 0 )
             {
@@ -3283,28 +3283,26 @@ int do_mmuext_op(
         }
 
         case MMUEXT_CLEAR_PAGE: {
-            unsigned long mfn;
+            struct page_info *page;
             unsigned char *ptr;
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
+            page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            if ( !page || !get_page_type(page, PGT_writable_page) )
             {
-                put_gfn(d, op.arg1.mfn);
-                MEM_LOG("Error while clearing mfn %lx", mfn);
+                if ( page )
+                    put_page(page);
+                MEM_LOG("Error while clearing mfn %lx", op.arg1.mfn);
                 break;
             }
 
             /* A page is dirtied when it's being cleared. */
-            paging_mark_dirty(d, mfn);
-
-            ptr = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(page));
+
+            ptr = fixmap_domain_page(page_to_mfn(page));
             clear_page(ptr);
             fixunmap_domain_page(ptr);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
+            put_page_and_type(page);
             break;
         }
 
@@ -3312,42 +3310,38 @@ int do_mmuext_op(
         {
             const unsigned char *src;
             unsigned char *dst;
-            unsigned long src_mfn, mfn;
-
-            src_mfn = get_gfn_untyped(d, op.arg2.src_mfn);
-            okay = get_page_from_pagenr(src_mfn, d);
+            struct page_info *src_page, *dst_page;
+
+            src_page = get_page_from_gfn(d, op.arg2.src_mfn, NULL, P2M_ALLOC);
+            if ( unlikely(!src_page) )
+            {
+                okay = 0;
+                MEM_LOG("Error while copying from mfn %lx", op.arg2.src_mfn);
+                break;
+            }
+
+            dst_page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC);
+            okay = (dst_page && get_page_type(dst_page, PGT_writable_page));
             if ( unlikely(!okay) )
             {
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying from mfn %lx", src_mfn);
+                put_page(src_page);
+                if ( dst_page )
+                    put_page(dst_page);
+                MEM_LOG("Error while copying to mfn %lx", op.arg1.mfn);
                 break;
             }
 
-            mfn = get_gfn_untyped(d, op.arg1.mfn);
-            okay = !get_page_and_type_from_pagenr(
-                mfn, PGT_writable_page, d, 0, 0);
-            if ( unlikely(!okay) )
-            {
-                put_gfn(d, op.arg1.mfn);
-                put_page(mfn_to_page(src_mfn));
-                put_gfn(d, op.arg2.src_mfn);
-                MEM_LOG("Error while copying to mfn %lx", mfn);
-                break;
-            }
-
             /* A page is dirtied when it's being copied to. */
-            paging_mark_dirty(d, mfn);
-
-            src = map_domain_page(src_mfn);
-            dst = fixmap_domain_page(mfn);
+            paging_mark_dirty(d, page_to_mfn(dst_page));
+
+            src = __map_domain_page(src_page);
+            dst = fixmap_domain_page(page_to_mfn(dst_page));
             copy_page(dst, src);
             fixunmap_domain_page(dst);
             unmap_domain_page(src);
 
-            put_page_and_type(mfn_to_page(mfn));
-            put_gfn(d, op.arg1.mfn);
-            put_page(mfn_to_page(src_mfn));
-            put_gfn(d, op.arg2.src_mfn);
+            put_page_and_type(dst_page);
+            put_page(src_page);
             break;
         }
 
@@ -3538,29 +3532,26 @@ int do_mmu_update(
 
             req.ptr -= cmd;
             gmfn = req.ptr >> PAGE_SHIFT;
-            mfn = mfn_x(get_gfn(pt_owner, gmfn, &p2mt));
-            if ( !p2m_is_valid(p2mt) )
-                mfn = INVALID_MFN;
+            page = get_page_from_gfn(pt_owner, gmfn, &p2mt, P2M_ALLOC);
 
             if ( p2m_is_paged(p2mt) )
             {
-                put_gfn(pt_owner, gmfn);
+                ASSERT(!page);
                 p2m_mem_paging_populate(pg_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
 
-            if ( unlikely(!get_page_from_pagenr(mfn, pt_owner)) )
+            if ( unlikely(!page) )
             {
                 MEM_LOG("Could not get page for normal update");
-                put_gfn(pt_owner, gmfn);
                 break;
             }
 
+            mfn = page_to_mfn(page);
             va = map_domain_page_with_cache(mfn, &mapcache);
             va = (void *)((unsigned long)va +
                           (unsigned long)(req.ptr & ~PAGE_MASK));
-            page = mfn_to_page(mfn);
 
             if ( page_lock(page) )
             {
@@ -3569,22 +3560,23 @@ int do_mmu_update(
                 case PGT_l1_page_table:
                 {
                     l1_pgentry_t l1e = l1e_from_intpte(req.val);
-                    p2m_type_t l1e_p2mt;
-                    unsigned long l1egfn = l1e_get_pfn(l1e), l1emfn;
-    
-                    l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
+                    p2m_type_t l1e_p2mt = p2m_ram_rw;
+                    struct page_info *target = NULL;
+
+                    if ( paging_mode_translate(pg_owner) )
+                        target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
+                                                   &l1e_p2mt, P2M_ALLOC);
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
-                        put_gfn(pg_owner, l1egfn);
+                        if ( target )
+                            put_page(target);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in == l1e_p2mt && 
-                                !mfn_valid(l1emfn) )
+                    else if ( p2m_ram_paging_in == l1e_p2mt && !target )
                     {
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3601,7 +3593,8 @@ int do_mmu_update(
                             rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
                             if ( rc )
                             {
-                                put_gfn(pg_owner, l1egfn);
+                                if ( target )
+                                    put_page(target);
                                 /* Notify helper, don't care about errors, will not
                                  * sleep on wq, since we're a foreign domain. */
                                 (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
@@ -3614,112 +3607,22 @@ int do_mmu_update(
                     rc = mod_l1_entry(va, l1e, mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
                                       pg_owner);
-                    put_gfn(pg_owner, l1egfn);
+                    if ( target )
+                        put_page(target);
                 }
                 break;
                 case PGT_l2_page_table:
-                {
-                    l2_pgentry_t l2e = l2e_from_intpte(req.val);
-                    p2m_type_t l2e_p2mt;
-                    unsigned long l2egfn = l2e_get_pfn(l2e), l2emfn;
-
-                    l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
-
-                    if ( p2m_is_paged(l2e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l2e_p2mt && 
-                                !mfn_valid(l2emfn) )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l2e_p2mt )
-                    {
-                        put_gfn(pg_owner, l2egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-
-                    rc = mod_l2_entry(va, l2e, mfn,
+                    rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
-                    put_gfn(pg_owner, l2egfn);
-                }
-                break;
+                    break;
                 case PGT_l3_page_table:
-                {
-                    l3_pgentry_t l3e = l3e_from_intpte(req.val);
-                    p2m_type_t l3e_p2mt;
-                    unsigned long l3egfn = l3e_get_pfn(l3e), l3emfn;
-
-                    l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
-
-                    if ( p2m_is_paged(l3e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l3e_p2mt && 
-                                !mfn_valid(l3emfn) )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l3e_p2mt )
-                    {
-                        put_gfn(pg_owner, l3egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l3_entry(va, l3e, mfn,
+                    rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l3egfn);
-                }
-                break;
+                    break;
 #if CONFIG_PAGING_LEVELS >= 4
                 case PGT_l4_page_table:
-                {
-                    l4_pgentry_t l4e = l4e_from_intpte(req.val);
-                    p2m_type_t l4e_p2mt;
-                    unsigned long l4egfn = l4e_get_pfn(l4e), l4emfn;
-
-                    l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
-
-                    if ( p2m_is_paged(l4e_p2mt) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in == l4e_p2mt && 
-                                !mfn_valid(l4emfn) )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_shared == l4e_p2mt )
-                    {
-                        put_gfn(pg_owner, l4egfn);
-                        MEM_LOG("Unexpected attempt to map shared page.\n");
-                        break;
-                    }
-
-                    rc = mod_l4_entry(va, l4e, mfn,
+                    rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v);
-                    put_gfn(pg_owner, l4egfn);
-                }
                 break;
 #endif
                 case PGT_writable_page:
@@ -3742,7 +3645,6 @@ int do_mmu_update(
 
             unmap_domain_page_with_cache(va, &mapcache);
             put_page(page);
-            put_gfn(pt_owner, gmfn);
         }
         break;
 
diff -r 107285938c50 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/guest_walk.c	Fri Apr 27 10:23:28 2012 +0100
@@ -94,39 +94,37 @@ static inline void *map_domain_gfn(struc
                                    p2m_type_t *p2mt,
                                    uint32_t *rc) 
 {
-    p2m_access_t p2ma;
+    struct page_info *page;
     void *map;
 
     /* Translate the gfn, unsharing if shared */
-    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, 
-                               P2M_ALLOC | P2M_UNSHARE, NULL);
+    page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), p2mt, NULL,
+                                  P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
     if ( p2m_is_shared(*p2mt) )
     {
-        __put_gfn(p2m, gfn_x(gfn));
+        if ( page )
+            put_page(page);
         *rc = _PAGE_SHARED;
         return NULL;
     }
-    if ( !p2m_is_ram(*p2mt) ) 
+    if ( !page )
     {
-        __put_gfn(p2m, gfn_x(gfn));
         *rc |= _PAGE_PRESENT;
         return NULL;
     }
+    *mfn = _mfn(page_to_mfn(page));
     ASSERT(mfn_valid(mfn_x(*mfn)));
-    
-    /* Get an extra ref to the page to ensure liveness of the map.
-     * Then we can safely put gfn */
-    page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn)));
+
     map = map_domain_page(mfn_x(*mfn));
-    __put_gfn(p2m, gfn_x(gfn));
     return map;
 }
 
diff -r 107285938c50 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/hap/guest_walk.c	Fri Apr 27 10:23:28 2012 +0100
@@ -54,34 +54,36 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     mfn_t top_mfn;
     void *top_map;
     p2m_type_t p2mt;
-    p2m_access_t p2ma;
     walk_t gw;
     unsigned long top_gfn;
+    struct page_info *top_page;
 
     /* Get the top-level table's MFN */
     top_gfn = cr3 >> PAGE_SHIFT;
-    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, 
-                                  P2M_ALLOC | P2M_UNSHARE, NULL);
+    top_page = get_page_from_gfn_p2m(p2m->domain, p2m, top_gfn,
+                                     &p2mt, NULL, P2M_ALLOC | P2M_UNSHARE);
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         pfec[0] = PFEC_page_paged;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
     {
         pfec[0] = PFEC_page_shared;
-        __put_gfn(p2m, top_gfn);
+        if ( top_page )
+            put_page(top_page);
         return INVALID_GFN;
     }
-    if ( !p2m_is_ram(p2mt) )
+    if ( !top_page )
     {
         pfec[0] &= ~PFEC_page_present;
-        __put_gfn(p2m, top_gfn);
         return INVALID_GFN;
     }
+    top_mfn = _mfn(page_to_mfn(top_page));
 
     /* Map the top-level table and call the tree-walker */
     ASSERT(mfn_valid(mfn_x(top_mfn)));
@@ -91,31 +93,30 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 #endif
     missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map);
     unmap_domain_page(top_map);
-    __put_gfn(p2m, top_gfn);
+    put_page(top_page);
 
     /* Interpret the answer */
     if ( missing == 0 )
     {
         gfn_t gfn = guest_l1e_get_gfn(gw.l1e);
-        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
-                                  P2M_ALLOC | P2M_UNSHARE, NULL); 
+        struct page_info *page;
+        page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), &p2mt,
+                                     NULL, P2M_ALLOC | P2M_UNSHARE);
+        if ( page )
+            put_page(page);
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
             pfec[0] = PFEC_page_paged;
-            __put_gfn(p2m, gfn_x(gfn));
             p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
         {
             pfec[0] = PFEC_page_shared;
-            __put_gfn(p2m, gfn_x(gfn));
             return INVALID_GFN;
         }
 
-        __put_gfn(p2m, gfn_x(gfn));
-
         if ( page_order )
             *page_order = guest_walk_to_page_order(&gw);
 
diff -r 107285938c50 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/mm-locks.h	Fri Apr 27 10:23:28 2012 +0100
@@ -166,13 +166,39 @@ declare_mm_lock(nestedp2m)
  * and later mutate it.
  */
 
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
+/* P2M lock is become an rwlock, purely so we can implement
+ * get_page_from_gfn.  The mess below is a ghastly hack to make a
+ * recursive rwlock.  If it works I'll come back and fix up the
+ * order-contraints magic. */
+
+static inline void p2m_lock(struct p2m_domain *p)
+{
+    if ( p->wcpu != current->processor )
+    {
+        write_lock(&p->lock);
+        p->wcpu = current->processor;
+        ASSERT(p->wcount == 0);
+    }
+    p->wcount++;
+}
+
+static inline void p2m_unlock(struct p2m_domain *p)
+{
+    ASSERT(p->wcpu == current->processor);
+    if (--(p->wcount) == 0)
+    {
+        p->wcpu = -1;
+        write_unlock(&p->lock);
+    }
+}
+
+#define gfn_lock(p,g,o)       p2m_lock(p)
+#define gfn_unlock(p,g,o)     p2m_unlock(p)
+#define p2m_read_lock(p)      read_lock(&(p)->lock)
+#define p2m_read_unlock(p)    read_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   ((p)->wcpu == current->processor)
+#define gfn_locked_by_me(p,g) p2m_locked_by_me(p)
+
 
 /* Sharing per page lock
  *
@@ -203,8 +229,8 @@ declare_mm_order_constraint(per_page_sha
  * counts, page lists, sweep parameters. */
 
 declare_mm_lock(pod)
-#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
-#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_lock(p) do { p2m_lock(p); mm_lock(pod, &(p)->pod.lock); } while (0)
+#define pod_unlock(p) do { mm_unlock(&(p)->pod.lock); p2m_unlock(p);} while (0)
 #define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
 
 /* Page alloc lock (per-domain)
diff -r 107285938c50 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Fri Apr 27 10:23:28 2012 +0100
@@ -71,7 +71,9 @@ boolean_param("hap_2mb", opt_hap_2mb);
 /* Init the datastructures for later use by the p2m code */
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
-    mm_lock_init(&p2m->lock);
+    rwlock_init(&p2m->lock);
+    p2m->wcount = 0;
+    p2m->wcpu = -1;
     mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
@@ -207,6 +209,59 @@ void __put_gfn(struct p2m_domain *p2m, u
     gfn_unlock(p2m, gfn, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page. */
+struct page_info *get_page_from_gfn_p2m(
+    struct domain *d, struct p2m_domain *p2m, unsigned long gfn,
+    p2m_type_t *t, p2m_access_t *a, p2m_query_t q)
+{
+    struct page_info *page = NULL;
+    p2m_access_t _a;
+    p2m_type_t _t;
+    mfn_t mfn;
+
+    /* Allow t or a to be NULL */
+    t = t ?: &_t;
+    a = a ?: &_a;
+
+    if ( likely(!p2m_locked_by_me(p2m)) )
+    {
+        /* Fast path: look up and get out */
+        p2m_read_lock(p2m);
+        mfn = __get_gfn_type_access(p2m, gfn, t, a, 0, NULL, 0);
+        if ( (p2m_is_ram(*t) || p2m_is_grant(*t))
+             && mfn_valid(mfn)
+             && !((q & P2M_UNSHARE) && p2m_is_shared(*t)) )
+        {
+            page = mfn_to_page(mfn);
+            if ( !get_page(page, d)
+                 /* Page could be shared */
+                 && !get_page(page, dom_cow) )
+                page = NULL;
+        }
+        p2m_read_unlock(p2m);
+
+        if ( page )
+            return page;
+
+        /* Error path: not a suitable GFN at all */
+        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) )
+            return NULL;
+    }
+
+    /* Slow path: take the write lock and do fixups */
+    mfn = get_gfn_type_access(p2m, gfn, t, a, q, NULL);
+    if ( p2m_is_ram(*t) && mfn_valid(mfn) )
+    {
+        page = mfn_to_page(mfn);
+        if ( !get_page(page, d) )
+            page = NULL;
+    }
+    put_gfn(d, gfn);
+
+    return page;
+}
+
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 107285938c50 xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/physdev.c	Fri Apr 27 10:23:28 2012 +0100
@@ -306,26 +306,27 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
     case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
+        struct page_info *page;
 
         ret = -EFAULT;
         if ( copy_from_guest(&info, arg, 1) != 0 )
             break;
 
         ret = -EINVAL;
-        mfn = get_gfn_untyped(current->domain, info.gmfn);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), v->domain,
-                                PGT_writable_page) )
+        page = get_page_from_gfn(current->domain, info.gmfn, NULL, P2M_ALLOC);
+        if ( !page )
+            break;
+        if ( !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(current->domain, info.gmfn);
+            put_page(page);
             break;
         }
+        mfn = page_to_mfn(page);
 
         if ( cmpxchg(&v->domain->arch.pv_domain.pirq_eoi_map_mfn,
                      0, mfn) != 0 )
         {
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -EBUSY;
             break;
         }
@@ -335,14 +336,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         {
             v->domain->arch.pv_domain.pirq_eoi_map_mfn = 0;
             put_page_and_type(mfn_to_page(mfn));
-            put_gfn(current->domain, info.gmfn);
             ret = -ENOSPC;
             break;
         }
         if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
             v->domain->arch.pv_domain.auto_unmask = 1;
 
-        put_gfn(current->domain, info.gmfn);
         ret = 0;
         break;
     }
diff -r 107285938c50 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/arch/x86/traps.c	Fri Apr 27 10:23:28 2012 +0100
@@ -662,9 +662,9 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
     case 0:
     {
         void *hypercall_page;
-        unsigned long mfn;
         unsigned long gmfn = val >> 12;
         unsigned int idx  = val & 0xfff;
+        struct page_info *page;
 
         if ( idx > 0 )
         {
@@ -674,24 +674,23 @@ int wrmsr_hypervisor_regs(uint32_t idx, 
             return 0;
         }
 
-        mfn = get_gfn_untyped(d, gmfn);
-
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) )
+        page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+        if ( !page || !get_page_type(page, PGT_writable_page) )
         {
-            put_gfn(d, gmfn);
+            if ( page )
+                put_page(page);
             gdprintk(XENLOG_WARNING,
                      "Bad GMFN %lx (MFN %lx) to MSR %08x\n",
-                     gmfn, mfn, base + idx);
+                     gmfn, page_to_mfn(page), base + idx);
             return 0;
         }
 
-        hypercall_page = map_domain_page(mfn);
+        hypercall_page = __map_domain_page(page);
         hypercall_page_initialise(d, hypercall_page);
         unmap_domain_page(hypercall_page);
 
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gmfn);
+        put_page_and_type(page);
         break;
     }
 
@@ -2374,7 +2373,8 @@ static int emulate_privileged_op(struct 
             break;
 
         case 3: {/* Write CR3 */
-            unsigned long mfn, gfn;
+            unsigned long gfn;
+            struct page_info *page;
             domain_lock(v->domain);
             if ( !is_pv_32on64_vcpu(v) )
             {
@@ -2384,9 +2384,10 @@ static int emulate_privileged_op(struct 
                 gfn = compat_cr3_to_pfn(*reg);
 #endif
             }
-            mfn = get_gfn_untyped(v->domain, gfn);
-            rc = new_guest_cr3(mfn);
-            put_gfn(v->domain, gfn);
+            page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC);
+            rc = page ? new_guest_cr3(page_to_mfn(page)) : 0;
+            if ( page )
+                put_page(page);
             domain_unlock(v->domain);
             if ( rc == 0 ) /* not okay */
                 goto fail;
diff -r 107285938c50 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/include/asm-x86/p2m.h	Fri Apr 27 10:23:28 2012 +0100
@@ -192,7 +192,10 @@ typedef unsigned int p2m_query_t;
 /* Per-p2m-table state */
 struct p2m_domain {
     /* Lock that protects updates to the p2m */
-    mm_lock_t          lock;
+    rwlock_t           lock;
+    int                wcpu;
+    int                wcount;
+    const char        *wfunc;
 
     /* Shadow translated domain: p2m mapping */
     pagetable_t        phys_table;
@@ -377,6 +380,33 @@ static inline mfn_t get_gfn_query_unlock
     return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0);
 }
 
+/* Atomically look up a GFN and take a reference count on the backing page.
+ * This makes sure the page doesn't get freed (or shared) underfoot,
+ * and should be used by any path that intends to write to the backing page.
+ * Returns NULL if the page is not backed by RAM.
+ * The caller is responsible for calling put_page() afterwards. */
+struct page_info *get_page_from_gfn_p2m(struct domain *d,
+                                        struct p2m_domain *p2m,
+                                        unsigned long gfn,
+                                        p2m_type_t *t, p2m_access_t *a,
+                                        p2m_query_t q);
+
+static inline struct page_info *get_page_from_gfn(
+    struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
+{
+    struct page_info *page;
+
+    if ( paging_mode_translate(d) )
+        return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q);
+
+    /* Non-translated guests see 1-1 RAM mappings everywhere */
+    if (t)
+        *t = p2m_ram_rw;
+    page = __mfn_to_page(gfn);
+    return get_page(page, d) ? page : NULL;
+}
+
+
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)
 {
diff -r 107285938c50 xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/xsm/flask/hooks.c	Fri Apr 27 10:23:28 2012 +0100
@@ -1318,6 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
+    struct page_info *page;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1333,7 +1334,8 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+    mfn = page ? page_to_mfn(page) : INVALID_MFN;
 
     ad.sdom = d;
     ad.tdom = f;
@@ -1342,7 +1344,8 @@ static int flask_mmu_normal_update(struc
 
     rc = get_mfn_sid(fmfn, &fsid);
 
-    put_gfn(f, fmfn);
+    if ( page )
+        put_page(page);
 
     if ( rc )
         return rc;

--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--zYM0uCDKw75PZbzx--


From xen-devel-bounces@lists.xen.org Fri Apr 27 09:30:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhV2-00058o-RO; Fri, 27 Apr 2012 09:30:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNhV1-00058j-2C
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:29:59 +0000
Received: from [193.109.254.147:48534] by server-3.bemta-14.messagelabs.com id
	DD/18-23274-6176A9F4; Fri, 27 Apr 2012 09:29:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335518997!4142671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2295 invoked from network); 27 Apr 2012 09:29:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:29:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12172731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 09:29:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:29:57 +0100
Message-ID: <1335518995.28015.186.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Date: Fri, 27 Apr 2012 10:29:55 +0100
In-Reply-To: <95424045.BJ4a0xs4Vr@amur>
References: <95424045.BJ4a0xs4Vr@amur>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: add vpmu description to
 xen-command-line.markdown
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 10:20 +0100, Dietmar Hahn wrote:
> # HG changeset patch
> # User Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> # Date 1335517766 -7200
> # Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565
> # Parent  107285938c50f82667bd4d014820b439a077c22c
> 
> Add a short description to the vpmu boot option in the
> xen-command-line.markdown
> 
> 
> Signed-off-by:  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Can't we just blacklist systems with the nehalem quirk and otherwise
enable it?

Ian.

> 
> 
> diff -r 107285938c50 docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown	Thu Apr 26 10:03:08 2012 +0100
> +++ b/docs/misc/xen-command-line.markdown	Fri Apr 27 11:09:26 2012 +0200
> @@ -543,7 +543,28 @@ console even after dom0 has been started
>  relinquish control to dom0.
>  
>  ### vpid
> +
>  ### vpmu
> +> `= ( bts )`
> +
> +> Default: `off`
> +
> +Switch on the virtualized performance monitoring unit for HVM guests.
> +
> +If the current cpu isn't supported a message like  
> +'VPMU: Initialization failed. ...'  
> +is printed on the hypervisor serial log.
> +
> +For some Intel Nehalem processors a quirk handling exist for an unknown
> +wrong behaviour (see handle_pmc_quirk()).
> +
> +If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
> +feature is switched on on Intel processors supporting this feature.
> +
> +*Warning:*
> +As the BTS virtualisation is not 100% safe and because of the nehalem quirk
> +don't use the vpmu flag on production systems with Intel cpus!
> +
>  ### vti\_vhpt\_size
>  ### vti\_vtlb\_size
>  ### watchdog
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:30:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhV2-00058o-RO; Fri, 27 Apr 2012 09:30:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNhV1-00058j-2C
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:29:59 +0000
Received: from [193.109.254.147:48534] by server-3.bemta-14.messagelabs.com id
	DD/18-23274-6176A9F4; Fri, 27 Apr 2012 09:29:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335518997!4142671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2295 invoked from network); 27 Apr 2012 09:29:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 09:29:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="12172731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 09:29:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:29:57 +0100
Message-ID: <1335518995.28015.186.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Date: Fri, 27 Apr 2012 10:29:55 +0100
In-Reply-To: <95424045.BJ4a0xs4Vr@amur>
References: <95424045.BJ4a0xs4Vr@amur>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: add vpmu description to
 xen-command-line.markdown
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 10:20 +0100, Dietmar Hahn wrote:
> # HG changeset patch
> # User Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> # Date 1335517766 -7200
> # Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565
> # Parent  107285938c50f82667bd4d014820b439a077c22c
> 
> Add a short description to the vpmu boot option in the
> xen-command-line.markdown
> 
> 
> Signed-off-by:  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Can't we just blacklist systems with the nehalem quirk and otherwise
enable it?

Ian.

> 
> 
> diff -r 107285938c50 docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown	Thu Apr 26 10:03:08 2012 +0100
> +++ b/docs/misc/xen-command-line.markdown	Fri Apr 27 11:09:26 2012 +0200
> @@ -543,7 +543,28 @@ console even after dom0 has been started
>  relinquish control to dom0.
>  
>  ### vpid
> +
>  ### vpmu
> +> `= ( bts )`
> +
> +> Default: `off`
> +
> +Switch on the virtualized performance monitoring unit for HVM guests.
> +
> +If the current cpu isn't supported a message like  
> +'VPMU: Initialization failed. ...'  
> +is printed on the hypervisor serial log.
> +
> +For some Intel Nehalem processors a quirk handling exist for an unknown
> +wrong behaviour (see handle_pmc_quirk()).
> +
> +If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
> +feature is switched on on Intel processors supporting this feature.
> +
> +*Warning:*
> +As the BTS virtualisation is not 100% safe and because of the nehalem quirk
> +don't use the vpmu flag on production systems with Intel cpus!
> +
>  ### vti\_vhpt\_size
>  ### vti\_vtlb\_size
>  ### watchdog
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:32:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhWp-0005Fv-BB; Fri, 27 Apr 2012 09:31:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SNhWo-0005Fm-6U
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:31:50 +0000
Received: from [85.158.138.51:55585] by server-10.bemta-3.messagelabs.com id
	0D/79-29478-5876A9F4; Fri, 27 Apr 2012 09:31:49 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335519108!24056854!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTA1NTM4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20917 invoked from network); 27 Apr 2012 09:31:48 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 09:31:48 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SNhWl-0005hy-FE; Fri, 27 Apr 2012 10:31:47 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Fri, 27 Apr 2012
	10:31:38 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Fri, 27 Apr 2012 10:31:38 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0kWIvwJ6ayIhZMTu6xaDcs5q75Sw==
Message-ID: <4F9A677A.3050800@newcastle.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
	<20120418164351.GS7013@ocelot.phlegethon.org>
	<4F8EF575.6000002@newcastle.ac.uk>
	<20120420081629.GB39206@ocelot.phlegethon.org>
In-Reply-To: <20120420081629.GB39206@ocelot.phlegethon.org>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/20/2012 09:16 AM, Tim Deegan wrote:
>
> At 18:10 +0100 on 18 Apr (1334772613), Francisco Rocha wrote:
> > On 04/18/2012 05:43 PM, Tim Deegan wrote:
> > >
> > > At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > > > Hi Tim,
> > > >
> > > > I was thinking about changing my approach.
> > > >
> > > > I think that for now I will leave those pages off because I am
> > > > mostly interested in protecting other areas.
> > > >
> > > > Those accesses for now are inevitable to get the VM to properly
> > > > operate. Now, the question is if it is possible to use page table
> > > > entries to do what I want to do.
> > > >
> > > > The objective would be to use a bit flag that would determine if
> > > > the pages are returned when a call to map_foreign_range is made.
> > > > So, my final objective would be that only pages used for the three
> > > > operations you describe are accessible to Dom0.
> > > > Everything that is not BIOS and related, Qemu or PV backend
> > > > drivers will not be returned.
> > > >
> > > > From what I see in the header files you use 12-bits from a 24-bit
> > > > flag (x86_64). Can we do it? This would again take us to controlling
> > > > access at get_page_from_l1e(), right?
> > >
> > > Are you talking about the count_info and type_info fields?  yes, I 
> think
> > > you can probably put a new flag or two in there.
> > >
> > I was thinking about the ones used in page table entries
> > (_PAGE_PRESENT|RW, etc).
>
> Oh.  That's probably not so suitable for access control since (a) there
> may be more that one PTE pointing to the same page, even controlled by
> different domains, and what if they have different flags? and (b) given
> a page number you can't easily find a PTE that points to it to look at
> the bits.
>
> Th type_info and count_info fields, on the other hand, exist once per
> page and are entirely under Xen's control.
>
> > > Choosing which pages
> > > qemu can map will be interesting, though -- it needs to map 
> anything the
> > > VM uses for I/O.  But maybe you can just define the things you protect
> > > and declare taht they can't be used for I/O.  That sounds easier. :)
> > >
> > The objective is to protect the kernel and its data structures.
> > That is why I was considering the flags I previously mentioned.
> > There is one denominated _PAGE_GUEST_KERNEL.
>
> That's part of the 64-bit PV interface; if the guest is 32-bit or HVM it
> won't be used like that.  I think you'll have to modify the kernel to
> explicitly tell Xen which pages are kernel ones (wih a hypercall) and
> then remember that with a bit in the count_info/type_info.
>
Hi Tim,

I have been changing a xen kernel driver to test the idea of
telling the hypervisor.
 From what I have read guests have the pfn -> mfn table, but
I am not able to find a function to make the conversion. I was
using the pfn because the mfn_valid at the hypervisor level
was saying the mfn was valid. :-) So, the pfn_to_mfn function
at guest level gets the mfn but from the guest point of view,
is that correct?
How can I get the mfn from the pfn/gmfn? I am using a 32-bit
guest.
>
>
> Cheers,
>
> Tim.
>
Cheers,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 09:32:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 09:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhWp-0005Fv-BB; Fri, 27 Apr 2012 09:31:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SNhWo-0005Fm-6U
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 09:31:50 +0000
Received: from [85.158.138.51:55585] by server-10.bemta-3.messagelabs.com id
	0D/79-29478-5876A9F4; Fri, 27 Apr 2012 09:31:49 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335519108!24056854!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gMTA1NTM4\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20917 invoked from network); 27 Apr 2012 09:31:48 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 09:31:48 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1SNhWl-0005hy-FE; Fri, 27 Apr 2012 10:31:47 +0100
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Fri, 27 Apr 2012
	10:31:38 +0100
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Tim Deegan <tim@xen.org>
Date: Fri, 27 Apr 2012 10:31:38 +0100
Thread-Topic: [Xen-devel] reserve e820 ram
Thread-Index: Ac0kWIvwJ6ayIhZMTu6xaDcs5q75Sw==
Message-ID: <4F9A677A.3050800@newcastle.ac.uk>
References: <20120405103729.GE14774@ocelot.phlegethon.org>
	<20120411115849.GA14661@ocelot.phlegethon.org>
	<5E615268CEC26C4E920B9D9911A2307C0345ECC5B6A0@EXCCR03.campus.ncl.ac.uk>
	<20120418120236.GB7013@ocelot.phlegethon.org>
	<4F8ED17C.4090203@newcastle.ac.uk>
	<20120418164351.GS7013@ocelot.phlegethon.org>
	<4F8EF575.6000002@newcastle.ac.uk>
	<20120420081629.GB39206@ocelot.phlegethon.org>
In-Reply-To: <20120420081629.GB39206@ocelot.phlegethon.org>
Accept-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329
	Thunderbird/11.0.1
acceptlanguage: en-GB
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] reserve e820 ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/20/2012 09:16 AM, Tim Deegan wrote:
>
> At 18:10 +0100 on 18 Apr (1334772613), Francisco Rocha wrote:
> > On 04/18/2012 05:43 PM, Tim Deegan wrote:
> > >
> > > At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > > > Hi Tim,
> > > >
> > > > I was thinking about changing my approach.
> > > >
> > > > I think that for now I will leave those pages off because I am
> > > > mostly interested in protecting other areas.
> > > >
> > > > Those accesses for now are inevitable to get the VM to properly
> > > > operate. Now, the question is if it is possible to use page table
> > > > entries to do what I want to do.
> > > >
> > > > The objective would be to use a bit flag that would determine if
> > > > the pages are returned when a call to map_foreign_range is made.
> > > > So, my final objective would be that only pages used for the three
> > > > operations you describe are accessible to Dom0.
> > > > Everything that is not BIOS and related, Qemu or PV backend
> > > > drivers will not be returned.
> > > >
> > > > From what I see in the header files you use 12-bits from a 24-bit
> > > > flag (x86_64). Can we do it? This would again take us to controlling
> > > > access at get_page_from_l1e(), right?
> > >
> > > Are you talking about the count_info and type_info fields?  yes, I 
> think
> > > you can probably put a new flag or two in there.
> > >
> > I was thinking about the ones used in page table entries
> > (_PAGE_PRESENT|RW, etc).
>
> Oh.  That's probably not so suitable for access control since (a) there
> may be more that one PTE pointing to the same page, even controlled by
> different domains, and what if they have different flags? and (b) given
> a page number you can't easily find a PTE that points to it to look at
> the bits.
>
> Th type_info and count_info fields, on the other hand, exist once per
> page and are entirely under Xen's control.
>
> > > Choosing which pages
> > > qemu can map will be interesting, though -- it needs to map 
> anything the
> > > VM uses for I/O.  But maybe you can just define the things you protect
> > > and declare taht they can't be used for I/O.  That sounds easier. :)
> > >
> > The objective is to protect the kernel and its data structures.
> > That is why I was considering the flags I previously mentioned.
> > There is one denominated _PAGE_GUEST_KERNEL.
>
> That's part of the 64-bit PV interface; if the guest is 32-bit or HVM it
> won't be used like that.  I think you'll have to modify the kernel to
> explicitly tell Xen which pages are kernel ones (wih a hypercall) and
> then remember that with a bit in the count_info/type_info.
>
Hi Tim,

I have been changing a xen kernel driver to test the idea of
telling the hypervisor.
 From what I have read guests have the pfn -> mfn table, but
I am not able to find a function to make the conversion. I was
using the pfn because the mfn_valid at the hypervisor level
was saying the mfn was valid. :-) So, the pfn_to_mfn function
at guest level gets the mfn but from the guest point of view,
is that correct?
How can I get the mfn from the pfn/gmfn? I am using a 32-bit
guest.
>
>
> Cheers,
>
> Tim.
>
Cheers,
Francisco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 10:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 10:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhyF-0005cq-Ta; Fri, 27 Apr 2012 10:00:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SNhyE-0005cl-Lx
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 10:00:10 +0000
Received: from [85.158.138.51:31251] by server-9.bemta-3.messagelabs.com id
	29/F0-26691-92E6A9F4; Fri, 27 Apr 2012 10:00:09 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335520808!15150966!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIyMDA4NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5797 invoked from network); 27 Apr 2012 10:00:09 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 10:00:09 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=fXkTIaMd3utQ2YSGCVAWorck5dvHsxMJ8fmyxP/I2/WTVQHDHZpn0QV9
	O7S+q2+i69v+dhEalUaGXJvHPi9f11tKj3i7DiwL6frhTIiBdQwu66ERM
	JRcZai8lFvuY0stTJZzZOeiIcDu+jw99C59rU/45RlRWAHxbMPLA4JanC
	HZ7yPYAq2R5LF8yYZZRljzFzQ5lKjmpKG3wVR0W0XHposFBZYRRgd6E8/
	pGZFBgTTG+YA7d6TqvyOeP+aPAg6j;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1335520809; x=1367056809;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=AJAU1pKVjixOE4PA/p1l7rP0gjSO3ZFnnq7uwn4AdD0=;
	b=Fpt7Q2sfuB0se1BROO92inJjw/6hHSD7Xa7C5IXypd8KdMliIaRMa/E7
	qOPPmhzXFraN1bgYxp5asFyArl8ITAcoXjyNerPF0OuFmsv3iqfbE0aGD
	9aDqlxaoQ4CrQp2ivWxZanMqoFbGsAdOtkgFleiKNYRm2vXWj1wnHkT4c
	6KvuDe+NDv4p0OgeeLnzbO3W3OBsz1Vi3/lXL10eMq9Huhzro0S2/LPM5
	2R4VlbP43yxZPWtrJ7uMORU8aACC2;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="108956958"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Apr 2012 12:00:08 +0200
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="133219868"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 27 Apr 2012 12:00:08 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 2E938969078;
	Fri, 27 Apr 2012 12:00:08 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Fri, 27 Apr 2012 12:00:07 +0200
Message-ID: <111323271.SeLlmTYo0t@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <1335518995.28015.186.camel@zakaz.uk.xensource.com>
References: <95424045.BJ4a0xs4Vr@amur>
	<1335518995.28015.186.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: add vpmu description to
	xen-command-line.markdown
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Freitag 27 April 2012, 10:29:55 schrieb Ian Campbell:
> On Fri, 2012-04-27 at 10:20 +0100, Dietmar Hahn wrote:
> > # HG changeset patch
> > # User Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> > # Date 1335517766 -7200
> > # Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565
> > # Parent  107285938c50f82667bd4d014820b439a077c22c
> > 
> > Add a short description to the vpmu boot option in the
> > xen-command-line.markdown
> > 
> > 
> > Signed-off-by:  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Can't we just blacklist systems with the nehalem quirk and otherwise
> enable it?

I'm not sure how to create a blacklist. The problem is, the processor models
named in the check_pmc_quirk() function were found be doing some performance
counter tests with machines accessible be me and looking what happens.
As some other models may have the same PMU the hang may occur on other machines
too.
Maybe we can change the policy to switch always on the vpmu stuff for the
AMD cpus and enforce a flag for Intel?

Dietmar.

> 
> Ian.
> 
> > 
> > 
> > diff -r 107285938c50 docs/misc/xen-command-line.markdown
> > --- a/docs/misc/xen-command-line.markdown	Thu Apr 26 10:03:08 2012 +0100
> > +++ b/docs/misc/xen-command-line.markdown	Fri Apr 27 11:09:26 2012 +0200
> > @@ -543,7 +543,28 @@ console even after dom0 has been started
> >  relinquish control to dom0.
> >  
> >  ### vpid
> > +
> >  ### vpmu
> > +> `= ( bts )`
> > +
> > +> Default: `off`
> > +
> > +Switch on the virtualized performance monitoring unit for HVM guests.
> > +
> > +If the current cpu isn't supported a message like  
> > +'VPMU: Initialization failed. ...'  
> > +is printed on the hypervisor serial log.
> > +
> > +For some Intel Nehalem processors a quirk handling exist for an unknown
> > +wrong behaviour (see handle_pmc_quirk()).
> > +
> > +If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
> > +feature is switched on on Intel processors supporting this feature.
> > +
> > +*Warning:*
> > +As the BTS virtualisation is not 100% safe and because of the nehalem quirk
> > +don't use the vpmu flag on production systems with Intel cpus!
> > +
> >  ### vti\_vhpt\_size
> >  ### vti\_vtlb\_size
> >  ### watchdog

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 10:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 10:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNhyF-0005cq-Ta; Fri, 27 Apr 2012 10:00:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SNhyE-0005cl-Lx
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 10:00:10 +0000
Received: from [85.158.138.51:31251] by server-9.bemta-3.messagelabs.com id
	29/F0-26691-92E6A9F4; Fri, 27 Apr 2012 10:00:09 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335520808!15150966!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIyMDA4NQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5797 invoked from network); 27 Apr 2012 10:00:09 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 10:00:09 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=fXkTIaMd3utQ2YSGCVAWorck5dvHsxMJ8fmyxP/I2/WTVQHDHZpn0QV9
	O7S+q2+i69v+dhEalUaGXJvHPi9f11tKj3i7DiwL6frhTIiBdQwu66ERM
	JRcZai8lFvuY0stTJZzZOeiIcDu+jw99C59rU/45RlRWAHxbMPLA4JanC
	HZ7yPYAq2R5LF8yYZZRljzFzQ5lKjmpKG3wVR0W0XHposFBZYRRgd6E8/
	pGZFBgTTG+YA7d6TqvyOeP+aPAg6j;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1335520809; x=1367056809;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=AJAU1pKVjixOE4PA/p1l7rP0gjSO3ZFnnq7uwn4AdD0=;
	b=Fpt7Q2sfuB0se1BROO92inJjw/6hHSD7Xa7C5IXypd8KdMliIaRMa/E7
	qOPPmhzXFraN1bgYxp5asFyArl8ITAcoXjyNerPF0OuFmsv3iqfbE0aGD
	9aDqlxaoQ4CrQp2ivWxZanMqoFbGsAdOtkgFleiKNYRm2vXWj1wnHkT4c
	6KvuDe+NDv4p0OgeeLnzbO3W3OBsz1Vi3/lXL10eMq9Huhzro0S2/LPM5
	2R4VlbP43yxZPWtrJ7uMORU8aACC2;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="108956958"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Apr 2012 12:00:08 +0200
X-IronPort-AV: E=Sophos;i="4.75,490,1330902000"; d="scan'208";a="133219868"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 27 Apr 2012 12:00:08 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 2E938969078;
	Fri, 27 Apr 2012 12:00:08 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Fri, 27 Apr 2012 12:00:07 +0200
Message-ID: <111323271.SeLlmTYo0t@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <1335518995.28015.186.camel@zakaz.uk.xensource.com>
References: <95424045.BJ4a0xs4Vr@amur>
	<1335518995.28015.186.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: add vpmu description to
	xen-command-line.markdown
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Freitag 27 April 2012, 10:29:55 schrieb Ian Campbell:
> On Fri, 2012-04-27 at 10:20 +0100, Dietmar Hahn wrote:
> > # HG changeset patch
> > # User Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> > # Date 1335517766 -7200
> > # Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565
> > # Parent  107285938c50f82667bd4d014820b439a077c22c
> > 
> > Add a short description to the vpmu boot option in the
> > xen-command-line.markdown
> > 
> > 
> > Signed-off-by:  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Can't we just blacklist systems with the nehalem quirk and otherwise
> enable it?

I'm not sure how to create a blacklist. The problem is, the processor models
named in the check_pmc_quirk() function were found be doing some performance
counter tests with machines accessible be me and looking what happens.
As some other models may have the same PMU the hang may occur on other machines
too.
Maybe we can change the policy to switch always on the vpmu stuff for the
AMD cpus and enforce a flag for Intel?

Dietmar.

> 
> Ian.
> 
> > 
> > 
> > diff -r 107285938c50 docs/misc/xen-command-line.markdown
> > --- a/docs/misc/xen-command-line.markdown	Thu Apr 26 10:03:08 2012 +0100
> > +++ b/docs/misc/xen-command-line.markdown	Fri Apr 27 11:09:26 2012 +0200
> > @@ -543,7 +543,28 @@ console even after dom0 has been started
> >  relinquish control to dom0.
> >  
> >  ### vpid
> > +
> >  ### vpmu
> > +> `= ( bts )`
> > +
> > +> Default: `off`
> > +
> > +Switch on the virtualized performance monitoring unit for HVM guests.
> > +
> > +If the current cpu isn't supported a message like  
> > +'VPMU: Initialization failed. ...'  
> > +is printed on the hypervisor serial log.
> > +
> > +For some Intel Nehalem processors a quirk handling exist for an unknown
> > +wrong behaviour (see handle_pmc_quirk()).
> > +
> > +If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
> > +feature is switched on on Intel processors supporting this feature.
> > +
> > +*Warning:*
> > +As the BTS virtualisation is not 100% safe and because of the nehalem quirk
> > +don't use the vpmu flag on production systems with Intel cpus!
> > +
> >  ### vti\_vhpt\_size
> >  ### vti\_vtlb\_size
> >  ### watchdog

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 10:19:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 10:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNiGq-0005pz-P8; Fri, 27 Apr 2012 10:19:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SNiGp-0005pu-6V
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 10:19:23 +0000
Received: from [85.158.139.83:39056] by server-10.bemta-5.messagelabs.com id
	F4/83-08260-AA27A9F4; Fri, 27 Apr 2012 10:19:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335521960!25237676!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDc2NDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21104 invoked from network); 27 Apr 2012 10:19:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 10:19:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330923600"; d="scan'208";a="192370392"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 06:19:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 06:19:19 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SNi3q-0001FN-TV;
	Fri, 27 Apr 2012 11:05:58 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 27 Apr 2012 11:06:06 +0100
Message-ID: <1335521166-5984-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] rombios: remove sdtint.h dependency
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hardcode uint8_t, uint16_t and uint32_t typedefs, so we no longer need
stdint.h

Resolves problem reported by Wang Zhihao on 64bit Ubuntu systems:

make -C tcgbios all
make[10]: Entering directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios'
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
-mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-exceptions
-fno-builtin -msoft-float
-I/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
-I.. -I../..  -c -o tcgbios.o tcgbios.c
In file included from /usr/include/stdint.h:26:0,
                 from
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/include/stdint.h:3,
                 from ../rombios_compat.h:8,
                 from tcgbios.c:24:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such
file or directory
compilation terminated.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/firmware/rombios/32bit/rombios_compat.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/firmware/rombios/32bit/rombios_compat.h b/tools/firmware/rombios/32bit/rombios_compat.h
index f33e3e7..c0ae415 100644
--- a/tools/firmware/rombios/32bit/rombios_compat.h
+++ b/tools/firmware/rombios/32bit/rombios_compat.h
@@ -5,10 +5,13 @@
  * Compatibility functions and structures for transitioning between
  * 16 bit Bochs BIOS and 32 bit BIOS code.
  */
-#include <stdint.h>
 
 #define ADDR_FROM_SEG_OFF(seg, off)  (void *)((((uint32_t)(seg)) << 4) + (off))
 
+typedef unsigned char uint8_t;
+typedef unsigned short int uint16_t;
+typedef unsigned int uint32_t;
+
 typedef uint8_t  Bit8u;
 typedef uint16_t Bit16u;
 typedef uint32_t Bit32u;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 10:19:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 10:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNiGq-0005pz-P8; Fri, 27 Apr 2012 10:19:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SNiGp-0005pu-6V
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 10:19:23 +0000
Received: from [85.158.139.83:39056] by server-10.bemta-5.messagelabs.com id
	F4/83-08260-AA27A9F4; Fri, 27 Apr 2012 10:19:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1335521960!25237676!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDc2NDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21104 invoked from network); 27 Apr 2012 10:19:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 10:19:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330923600"; d="scan'208";a="192370392"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 06:19:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 06:19:19 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SNi3q-0001FN-TV;
	Fri, 27 Apr 2012 11:05:58 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 27 Apr 2012 11:06:06 +0100
Message-ID: <1335521166-5984-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] rombios: remove sdtint.h dependency
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hardcode uint8_t, uint16_t and uint32_t typedefs, so we no longer need
stdint.h

Resolves problem reported by Wang Zhihao on 64bit Ubuntu systems:

make -C tcgbios all
make[10]: Entering directory
`/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios'
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
-mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-exceptions
-fno-builtin -msoft-float
-I/home/gdunlap/hg/open-source/xen-upstream.hg/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
-I.. -I../..  -c -o tcgbios.o tcgbios.c
In file included from /usr/include/stdint.h:26:0,
                 from
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/include/stdint.h:3,
                 from ../rombios_compat.h:8,
                 from tcgbios.c:24:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such
file or directory
compilation terminated.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/firmware/rombios/32bit/rombios_compat.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/firmware/rombios/32bit/rombios_compat.h b/tools/firmware/rombios/32bit/rombios_compat.h
index f33e3e7..c0ae415 100644
--- a/tools/firmware/rombios/32bit/rombios_compat.h
+++ b/tools/firmware/rombios/32bit/rombios_compat.h
@@ -5,10 +5,13 @@
  * Compatibility functions and structures for transitioning between
  * 16 bit Bochs BIOS and 32 bit BIOS code.
  */
-#include <stdint.h>
 
 #define ADDR_FROM_SEG_OFF(seg, off)  (void *)((((uint32_t)(seg)) << 4) + (off))
 
+typedef unsigned char uint8_t;
+typedef unsigned short int uint16_t;
+typedef unsigned int uint32_t;
+
 typedef uint8_t  Bit8u;
 typedef uint16_t Bit16u;
 typedef uint32_t Bit32u;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 10:46:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 10:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNigw-000639-3Y; Fri, 27 Apr 2012 10:46:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SNigt-000634-Mo
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 10:46:19 +0000
Received: from [85.158.143.35:38298] by server-1.bemta-4.messagelabs.com id
	AE/D4-20925-BF87A9F4; Fri, 27 Apr 2012 10:46:19 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335523574!13922075!1
X-Originating-IP: [202.81.31.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNjkyNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31628 invoked from network); 27 Apr 2012 10:46:17 -0000
Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 10:46:17 -0000
Received: from /spool/local
	by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 27 Apr 2012 10:38:10 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 27 Apr 2012 10:38:05 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3RAjxHh36569214
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 20:46:00 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3RAjwBJ018938
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 20:45:59 +1000
Received: from [9.79.196.225] ([9.79.196.225])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3RAjpBi018823; Fri, 27 Apr 2012 20:45:52 +1000
Message-ID: <4F9A78CF.7070005@linux.vnet.ibm.com>
Date: Fri, 27 Apr 2012 16:15:35 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
In-Reply-To: <20120424095923.GS15413@redhat.com>
x-cbid: 12042700-1618-0000-0000-0000016A604D
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>
>> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>>
>> The presence of these hypercalls is indicated to guest via
>> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>>
>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>> Signed-off-by: Suzuki Poulose<suzuki@in.ibm.com>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> ---
[...]
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		/*
>> +		 * Setting unhalt flag here can result in spurious runnable
>> +		 * state when unhalt reset does not happen in vcpu_block.
>> +		 * But that is harmless since that should soon result in halt.
>> +		 */
>> +		vcpu->arch.pv.pv_unhalted = 1;
>> +		/* We need everybody see unhalt before vcpu unblocks */
>> +		smp_mb();
>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
> This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> can use one of reserved delivery modes as PV delivery mode. We will
> disallow guest to trigger it through apic interface, so this will not be
> part of ABI and can be changed at will.
>

I think it is interesting ( Perhaps more reasonable way of doing it).
I am not too familiar with lapic source. So, pardon me if my questions 
are stupid.

Something like below is what I deciphered from your suggestion which is 
working.

kvm/x86.c
=========
kvm_pv_kick_cpu_op()
{

  struct kvm_lapic_irq lapic_irq;

  lapic_irq.shorthand = 0;
  lapic_irq.dest_mode = 0;
  lapic_irq.dest_id = apicid;

  lapic_irq.delivery_mode = PV_DELIVERY_MODE;
  kvm_irq_delivery_to_apic(kvm, 0, &lapic_irq );

}

kvm/lapic.c
==========
_apic_accept_irq()
{
...
case APIC_DM_REMRD:
                 result = 1;
                 vcpu->pv_unhalted = 1
                 smp_mb();
                 kvm_make_request(KVM_REQ_EVENT, vcpu);
                 kvm_vcpu_kick(vcpu);
                 break;

...
}

here using PV_DELIVERY_MODE = APIC_DM_REMRD, which was unused.

OR
1) Are you asking to remove vcpu->pv_unhalted flag and replace with an irq?
2) are you talking about some reserved fields in struct local_apic instead
of APIC_DM_REMRD what I have used above?
[ Honestly, arch/x86/include/asm/apicdef.h had too much of info to 
digest :( ]

3) I am not sure about: disallow guest to trigger it through apic 
interface part also.(mean howto?)
4) And one more question, So you think it takes care of migration part
   (in case we are removing pv_unhalted flag)?

It would be helpful if you can give little more explanation/ pointer to 
Documentation.

Ingo is keen to see whole ticketlock/Xen/KVM patch in one go.
and anyhow since this does not cause any ABI change, I hope you don't 
mind if
I do only the vcpu->pv_unhalted change you suggested now [ having 
pv_unhalted reset  in vcpu_run if
you meant something else than code I have above ], so that whole series 
get fair amount time for testing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 10:46:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 10:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNigw-000639-3Y; Fri, 27 Apr 2012 10:46:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SNigt-000634-Mo
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 10:46:19 +0000
Received: from [85.158.143.35:38298] by server-1.bemta-4.messagelabs.com id
	AE/D4-20925-BF87A9F4; Fri, 27 Apr 2012 10:46:19 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335523574!13922075!1
X-Originating-IP: [202.81.31.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNjkyNTM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31628 invoked from network); 27 Apr 2012 10:46:17 -0000
Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 10:46:17 -0000
Received: from /spool/local
	by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Fri, 27 Apr 2012 10:38:10 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 27 Apr 2012 10:38:05 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3RAjxHh36569214
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 20:46:00 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3RAjwBJ018938
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 20:45:59 +1000
Received: from [9.79.196.225] ([9.79.196.225])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3RAjpBi018823; Fri, 27 Apr 2012 20:45:52 +1000
Message-ID: <4F9A78CF.7070005@linux.vnet.ibm.com>
Date: Fri, 27 Apr 2012 16:15:35 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
In-Reply-To: <20120424095923.GS15413@redhat.com>
x-cbid: 12042700-1618-0000-0000-0000016A604D
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>
>> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>>
>> The presence of these hypercalls is indicated to guest via
>> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>>
>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>> Signed-off-by: Suzuki Poulose<suzuki@in.ibm.com>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> ---
[...]
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		/*
>> +		 * Setting unhalt flag here can result in spurious runnable
>> +		 * state when unhalt reset does not happen in vcpu_block.
>> +		 * But that is harmless since that should soon result in halt.
>> +		 */
>> +		vcpu->arch.pv.pv_unhalted = 1;
>> +		/* We need everybody see unhalt before vcpu unblocks */
>> +		smp_mb();
>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
> This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> can use one of reserved delivery modes as PV delivery mode. We will
> disallow guest to trigger it through apic interface, so this will not be
> part of ABI and can be changed at will.
>

I think it is interesting ( Perhaps more reasonable way of doing it).
I am not too familiar with lapic source. So, pardon me if my questions 
are stupid.

Something like below is what I deciphered from your suggestion which is 
working.

kvm/x86.c
=========
kvm_pv_kick_cpu_op()
{

  struct kvm_lapic_irq lapic_irq;

  lapic_irq.shorthand = 0;
  lapic_irq.dest_mode = 0;
  lapic_irq.dest_id = apicid;

  lapic_irq.delivery_mode = PV_DELIVERY_MODE;
  kvm_irq_delivery_to_apic(kvm, 0, &lapic_irq );

}

kvm/lapic.c
==========
_apic_accept_irq()
{
...
case APIC_DM_REMRD:
                 result = 1;
                 vcpu->pv_unhalted = 1
                 smp_mb();
                 kvm_make_request(KVM_REQ_EVENT, vcpu);
                 kvm_vcpu_kick(vcpu);
                 break;

...
}

here using PV_DELIVERY_MODE = APIC_DM_REMRD, which was unused.

OR
1) Are you asking to remove vcpu->pv_unhalted flag and replace with an irq?
2) are you talking about some reserved fields in struct local_apic instead
of APIC_DM_REMRD what I have used above?
[ Honestly, arch/x86/include/asm/apicdef.h had too much of info to 
digest :( ]

3) I am not sure about: disallow guest to trigger it through apic 
interface part also.(mean howto?)
4) And one more question, So you think it takes care of migration part
   (in case we are removing pv_unhalted flag)?

It would be helpful if you can give little more explanation/ pointer to 
Documentation.

Ingo is keen to see whole ticketlock/Xen/KVM patch in one go.
and anyhow since this does not cause any ABI change, I hope you don't 
mind if
I do only the vcpu->pv_unhalted change you suggested now [ having 
pv_unhalted reset  in vcpu_run if
you meant something else than code I have above ], so that whole series 
get fair amount time for testing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:42:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjYI-0006No-Rk; Fri, 27 Apr 2012 11:41:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SNjYG-0006Nj-M4
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 11:41:28 +0000
Received: from [85.158.138.51:55113] by server-5.bemta-3.messagelabs.com id
	6C/93-17113-7E58A9F4; Fri, 27 Apr 2012 11:41:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335526885!19764307!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDc2NDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 27 Apr 2012 11:41:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 11:41:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330923600"; d="scan'208";a="192378853"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 07:41:19 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 27 Apr 2012
	07:41:18 -0400
Message-ID: <4F9A85DD.9070308@citrix.com>
Date: Fri, 27 Apr 2012 12:41:17 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335516436.28015.169.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/04/12 09:47, Ian Campbell wrote:
> On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
>> called even if no events were pending.
> 
> In actual fact it seems that the callback was actually being called if
> and only if no events were pending?

Or if events are masked, but this wasn't as bad as it sounds as Xen
would not actually do the upcall.

> Which makes me wonder how it used to work at all!

Xen would have to raise an event during a local_save_flags() /
local_restore_flags() /and/ after missing the call to
xen_force_evtchn_callback(), the guest would have to do no more
hypercalls at all.  This is possible I guess but seems really unlikely
to me.

>> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
>> index 79d7362..3e45aa0 100644
>> --- a/arch/x86/xen/xen-asm.S
>> +++ b/arch/x86/xen/xen-asm.S
>> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>>  
>>  	/* check for unmasked and pending */
>>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
>> -	jz 1f
>> +	jnz 1f
>>  2:	call check_events
>>  1:
> 
> Took me a while, this is a bit tricksy (and it may well be too early for
> me to be decoding it) since the check here is trying to check both
> pending and masked in a single cmpw, but I think this is correct. It
> will call check_events now only when the combined mask+pending word is
> 0x0001 (aka unmasked, pending).
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Does xen_irq_enable_direct have the same sort of issue? No, in that case
> we are doing a straight forward test of pending without involving masked
> (since it has just unmasked) and so jz is correct.

Thanks for the review.  This was a tricky one to pin down.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:42:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjYI-0006No-Rk; Fri, 27 Apr 2012 11:41:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1SNjYG-0006Nj-M4
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 11:41:28 +0000
Received: from [85.158.138.51:55113] by server-5.bemta-3.messagelabs.com id
	6C/93-17113-7E58A9F4; Fri, 27 Apr 2012 11:41:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335526885!19764307!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDc2NDM=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32193 invoked from network); 27 Apr 2012 11:41:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 11:41:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,490,1330923600"; d="scan'208";a="192378853"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 07:41:19 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 27 Apr 2012
	07:41:18 -0400
Message-ID: <4F9A85DD.9070308@citrix.com>
Date: Fri, 27 Apr 2012 12:41:17 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335516436.28015.169.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/04/12 09:47, Ian Campbell wrote:
> On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
>> called even if no events were pending.
> 
> In actual fact it seems that the callback was actually being called if
> and only if no events were pending?

Or if events are masked, but this wasn't as bad as it sounds as Xen
would not actually do the upcall.

> Which makes me wonder how it used to work at all!

Xen would have to raise an event during a local_save_flags() /
local_restore_flags() /and/ after missing the call to
xen_force_evtchn_callback(), the guest would have to do no more
hypercalls at all.  This is possible I guess but seems really unlikely
to me.

>> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
>> index 79d7362..3e45aa0 100644
>> --- a/arch/x86/xen/xen-asm.S
>> +++ b/arch/x86/xen/xen-asm.S
>> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>>  
>>  	/* check for unmasked and pending */
>>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
>> -	jz 1f
>> +	jnz 1f
>>  2:	call check_events
>>  1:
> 
> Took me a while, this is a bit tricksy (and it may well be too early for
> me to be decoding it) since the check here is trying to check both
> pending and masked in a single cmpw, but I think this is correct. It
> will call check_events now only when the combined mask+pending word is
> 0x0001 (aka unmasked, pending).
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Does xen_irq_enable_direct have the same sort of issue? No, in that case
> we are doing a straight forward test of pending without involving masked
> (since it has just unmasked) and so jz is correct.

Thanks for the review.  This was a tricky one to pin down.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:42:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjYg-0006P1-DT; Fri, 27 Apr 2012 11:41:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNjYf-0006Or-JT
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 11:41:53 +0000
Received: from [85.158.143.35:27317] by server-3.bemta-4.messagelabs.com id
	70/47-05853-0068A9F4; Fri, 27 Apr 2012 11:41:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335526911!6725108!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15822 invoked from network); 27 Apr 2012 11:41:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 11:41:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 12:41:50 +0100
Message-Id: <4F9AA23102000078000806DA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 12:42:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Ian Campbell" <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335516436.28015.169.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>> 
>> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
>> called even if no events were pending.
> 
> In actual fact it seems that the callback was actually being called if
> and only if no events were pending? Which makes me wonder how it used to
> work at all!
> 
>> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
>> index 79d7362..3e45aa0 100644
>> --- a/arch/x86/xen/xen-asm.S
>> +++ b/arch/x86/xen/xen-asm.S
>> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>>  
>>  	/* check for unmasked and pending */
>>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
>> -	jz 1f
>> +	jnz 1f
>>  2:	call check_events
>>  1:
> 
> Took me a while, this is a bit tricksy (and it may well be too early for
> me to be decoding it) since the check here is trying to check both
> pending and masked in a single cmpw, but I think this is correct. It
> will call check_events now only when the combined mask+pending word is
> 0x0001 (aka unmasked, pending).

It is _too much_ trickery, as it implies that the pending field, when set,
will always be 1. This is not sanctioned by the specification (quoting
the hypervisor's xen/include/public/xen.h):

     * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
     * a pending notification for a particular VCPU. It is then cleared 
     * by the guest OS /before/ checking for pending work, thus avoiding

Note that it says "non-zero", not "1".

But yes, this isn't the fault of the patch here, so this is also not an
objection to this patch.

And yes, it can still be done with a single compare afaict, just not
directly on the memory operand.

Jan

> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Does xen_irq_enable_direct have the same sort of issue? No, in that case
> we are doing a straight forward test of pending without involving masked
> (since it has just unmasked) and so jz is correct.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:42:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjYg-0006P1-DT; Fri, 27 Apr 2012 11:41:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNjYf-0006Or-JT
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 11:41:53 +0000
Received: from [85.158.143.35:27317] by server-3.bemta-4.messagelabs.com id
	70/47-05853-0068A9F4; Fri, 27 Apr 2012 11:41:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1335526911!6725108!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15822 invoked from network); 27 Apr 2012 11:41:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 11:41:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 12:41:50 +0100
Message-Id: <4F9AA23102000078000806DA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 12:42:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Ian Campbell" <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335516436.28015.169.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>> 
>> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
>> called even if no events were pending.
> 
> In actual fact it seems that the callback was actually being called if
> and only if no events were pending? Which makes me wonder how it used to
> work at all!
> 
>> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
>> index 79d7362..3e45aa0 100644
>> --- a/arch/x86/xen/xen-asm.S
>> +++ b/arch/x86/xen/xen-asm.S
>> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>>  
>>  	/* check for unmasked and pending */
>>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
>> -	jz 1f
>> +	jnz 1f
>>  2:	call check_events
>>  1:
> 
> Took me a while, this is a bit tricksy (and it may well be too early for
> me to be decoding it) since the check here is trying to check both
> pending and masked in a single cmpw, but I think this is correct. It
> will call check_events now only when the combined mask+pending word is
> 0x0001 (aka unmasked, pending).

It is _too much_ trickery, as it implies that the pending field, when set,
will always be 1. This is not sanctioned by the specification (quoting
the hypervisor's xen/include/public/xen.h):

     * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
     * a pending notification for a particular VCPU. It is then cleared 
     * by the guest OS /before/ checking for pending work, thus avoiding

Note that it says "non-zero", not "1".

But yes, this isn't the fault of the patch here, so this is also not an
objection to this patch.

And yes, it can still be done with a single compare afaict, just not
directly on the memory operand.

Jan

> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Does xen_irq_enable_direct have the same sort of issue? No, in that case
> we are doing a straight forward test of pending without involving masked
> (since it has just unmasked) and so jz is correct.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:53:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjjO-0006gx-IZ; Fri, 27 Apr 2012 11:52:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNjjN-0006gs-8H
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 11:52:57 +0000
Received: from [85.158.143.99:63386] by server-2.bemta-4.messagelabs.com id
	3D/75-17550-8988A9F4; Fri, 27 Apr 2012 11:52:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335527574!25569587!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2991 invoked from network); 27 Apr 2012 11:52:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 11:52:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 12:52:53 +0100
Message-Id: <4F9AA4C602000078000806F2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 12:53:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120427023439.GB26931@phenom.dumpdata.com>
In-Reply-To: <20120427023439.GB26931@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for
 domain 0: 694017 > 694016
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 04:34, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> I am not sure how this is happening, but I can only reproduce this
> is I use the "max" parameter in the 'dom0_mem=*:max:*' combination:

Of course - without the ",max:" there just isn't any limit for Dom0.

> sh-4.1# xl info | grep dom0_mem
> xen_commandline        : cpuinfo dom0_mem=1G,max:2711M cpufreq=verbose 
> com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=
> 
> 
> 02:32:22 # 19 :/sys/devices/system/xen_memory/xen_memory0/ 
>> cat /proc/meminfo |grep Direct
> DirectMap4k:     2776516 kB
> DirectMap2M:           0 kB
> 
> 02:33:11 # 23 :/sys/devices/system/xen_memory/xen_memory0/
>> echo 2776516 > target_kb
> 
> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 
> (239 of 256)
> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 
> of 17)
> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 
> of 17)
> 
>>
> The value that it decided it was Ok with was: 2776510kB which is 6 pages 
> short of the goal and that makes the messages disappear.

How would that be? 2711MiB = 2776064kiB, which 446k off the value
above. And apart from that, the value above isn't even divisible by 4
(i.e. not an even number of pages).

> Any ideas of what that might be? Could it be the shared_info, hypercall page,
> start_info, xenconsole and some other ones are the magic 6 pages which
> inhibit how much we can balloon up to?

Not likely: The hypercall page is in kernel (image) memory, and there's
no console page at all fro Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:53:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjjO-0006gx-IZ; Fri, 27 Apr 2012 11:52:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNjjN-0006gs-8H
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 11:52:57 +0000
Received: from [85.158.143.99:63386] by server-2.bemta-4.messagelabs.com id
	3D/75-17550-8988A9F4; Fri, 27 Apr 2012 11:52:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335527574!25569587!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2991 invoked from network); 27 Apr 2012 11:52:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 11:52:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 12:52:53 +0100
Message-Id: <4F9AA4C602000078000806F2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 12:53:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120427023439.GB26931@phenom.dumpdata.com>
In-Reply-To: <20120427023439.GB26931@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for
 domain 0: 694017 > 694016
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 04:34, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> I am not sure how this is happening, but I can only reproduce this
> is I use the "max" parameter in the 'dom0_mem=*:max:*' combination:

Of course - without the ",max:" there just isn't any limit for Dom0.

> sh-4.1# xl info | grep dom0_mem
> xen_commandline        : cpuinfo dom0_mem=1G,max:2711M cpufreq=verbose 
> com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=
> 
> 
> 02:32:22 # 19 :/sys/devices/system/xen_memory/xen_memory0/ 
>> cat /proc/meminfo |grep Direct
> DirectMap4k:     2776516 kB
> DirectMap2M:           0 kB
> 
> 02:33:11 # 23 :/sys/devices/system/xen_memory/xen_memory0/
>> echo 2776516 > target_kb
> 
> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 
> (239 of 256)
> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 
> of 17)
> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 
> of 17)
> 
>>
> The value that it decided it was Ok with was: 2776510kB which is 6 pages 
> short of the goal and that makes the messages disappear.

How would that be? 2711MiB = 2776064kiB, which 446k off the value
above. And apart from that, the value above isn't even divisible by 4
(i.e. not an even number of pages).

> Any ideas of what that might be? Could it be the shared_info, hypercall page,
> start_info, xenconsole and some other ones are the magic 6 pages which
> inhibit how much we can balloon up to?

Not likely: The hypercall page is in kernel (image) memory, and there's
no console page at all fro Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:58:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjoa-0006pH-F5; Fri, 27 Apr 2012 11:58:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNjoY-0006p9-L9
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 11:58:18 +0000
Received: from [85.158.143.99:54019] by server-1.bemta-4.messagelabs.com id
	22/66-20925-9D98A9F4; Fri, 27 Apr 2012 11:58:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335527896!20279466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8059 invoked from network); 27 Apr 2012 11:58:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 11:58:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12176420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 11:58:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 12:58:15 +0100
Message-ID: <1335527893.28015.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 27 Apr 2012 12:58:13 +0100
In-Reply-To: <4F9AA23102000078000806DA@nat28.tlf.novell.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >> 
> >> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> >> called even if no events were pending.
> > 
> > In actual fact it seems that the callback was actually being called if
> > and only if no events were pending? Which makes me wonder how it used to
> > work at all!
> > 
> >> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> >> index 79d7362..3e45aa0 100644
> >> --- a/arch/x86/xen/xen-asm.S
> >> +++ b/arch/x86/xen/xen-asm.S
> >> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
> >>  
> >>  	/* check for unmasked and pending */
> >>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> >> -	jz 1f
> >> +	jnz 1f
> >>  2:	call check_events
> >>  1:
> > 
> > Took me a while, this is a bit tricksy (and it may well be too early for
> > me to be decoding it) since the check here is trying to check both
> > pending and masked in a single cmpw, but I think this is correct. It
> > will call check_events now only when the combined mask+pending word is
> > 0x0001 (aka unmasked, pending).
> 
> It is _too much_ trickery, as it implies that the pending field, when set,
> will always be 1. This is not sanctioned by the specification (quoting
> the hypervisor's xen/include/public/xen.h):
> 
>      * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
>      * a pending notification for a particular VCPU. It is then cleared 
>      * by the guest OS /before/ checking for pending work, thus avoiding
> 
> Note that it says "non-zero", not "1".

Hrm, has it ever not been 1 in practice? i.e. could we legitimately
tighten the spec?

> But yes, this isn't the fault of the patch here, so this is also not an
> objection to this patch.
> 
> And yes, it can still be done with a single compare afaict, just not
> directly on the memory operand.

Code size is also a concern here since this sequence of instructions is
used for inline patching (not sure what the size limit actually is
though).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 11:58:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 11:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjoa-0006pH-F5; Fri, 27 Apr 2012 11:58:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNjoY-0006p9-L9
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 11:58:18 +0000
Received: from [85.158.143.99:54019] by server-1.bemta-4.messagelabs.com id
	22/66-20925-9D98A9F4; Fri, 27 Apr 2012 11:58:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335527896!20279466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8059 invoked from network); 27 Apr 2012 11:58:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 11:58:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12176420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 11:58:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 12:58:15 +0100
Message-ID: <1335527893.28015.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 27 Apr 2012 12:58:13 +0100
In-Reply-To: <4F9AA23102000078000806DA@nat28.tlf.novell.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >> 
> >> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> >> called even if no events were pending.
> > 
> > In actual fact it seems that the callback was actually being called if
> > and only if no events were pending? Which makes me wonder how it used to
> > work at all!
> > 
> >> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> >> index 79d7362..3e45aa0 100644
> >> --- a/arch/x86/xen/xen-asm.S
> >> +++ b/arch/x86/xen/xen-asm.S
> >> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
> >>  
> >>  	/* check for unmasked and pending */
> >>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> >> -	jz 1f
> >> +	jnz 1f
> >>  2:	call check_events
> >>  1:
> > 
> > Took me a while, this is a bit tricksy (and it may well be too early for
> > me to be decoding it) since the check here is trying to check both
> > pending and masked in a single cmpw, but I think this is correct. It
> > will call check_events now only when the combined mask+pending word is
> > 0x0001 (aka unmasked, pending).
> 
> It is _too much_ trickery, as it implies that the pending field, when set,
> will always be 1. This is not sanctioned by the specification (quoting
> the hypervisor's xen/include/public/xen.h):
> 
>      * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
>      * a pending notification for a particular VCPU. It is then cleared 
>      * by the guest OS /before/ checking for pending work, thus avoiding
> 
> Note that it says "non-zero", not "1".

Hrm, has it ever not been 1 in practice? i.e. could we legitimately
tighten the spec?

> But yes, this isn't the fault of the patch here, so this is also not an
> objection to this patch.
> 
> And yes, it can still be done with a single compare afaict, just not
> directly on the memory operand.

Code size is also a concern here since this sequence of instructions is
used for inline patching (not sure what the size limit actually is
though).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjvn-00079D-7E; Fri, 27 Apr 2012 12:05:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <johnfmccabe@gmail.com>) id 1SMoiG-0002HQ-G4
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 23:00:00 +0000
Received: from [85.158.138.51:43277] by server-9.bemta-3.messagelabs.com id
	B5/9D-26691-F60379F4; Tue, 24 Apr 2012 22:59:59 +0000
X-Env-Sender: johnfmccabe@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335308398!23598863!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19155 invoked from network); 24 Apr 2012 22:59:59 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 22:59:59 -0000
Received: by qafl39 with SMTP id l39so516562qaf.9
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 15:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=X71IO4EUpcY7BRBHvp+mefTFKpqQYe3dTiEuuquSN5U=;
	b=pE8gr000HfnuWsd3LB06brnFpJuACKg1PIdeScQS20srNuFcMXjXc+oZDcXYBe7+oY
	ssdR2rVDc3YosAtlxBMhScF9dGINwd4aTXWdyxiNnBYOTRo/gAMvahXTWV4OU8fnYp6k
	Bn5s/YidVS7UHn9BkHcqKeFPdVY+lW+uTHEsgkbql8QZGhV27lVBxF4c8BTtwyVNUsJo
	iKY409goCXmdxKn769NaGultnICXnMixrRZEWmtLBNIICYXWVQnWJPGUNWxxVZzDfPTs
	XVQaWSM38m9QqqrY8zWW3rviKJXJB7486TxYmF05s/R+UIOY3rrSz/Zj0vCmbn8A2/lh
	9Krw==
MIME-Version: 1.0
Received: by 10.224.196.136 with SMTP id eg8mr575682qab.50.1335308397784; Tue,
	24 Apr 2012 15:59:57 -0700 (PDT)
Received: by 10.229.165.207 with HTTP; Tue, 24 Apr 2012 15:59:57 -0700 (PDT)
Date: Tue, 24 Apr 2012 18:59:57 -0400
Message-ID: <CAN4v=fFiurdG_4DZyiXb85kihpZNvMLfCprLcsy9DfsTq_e-_w@mail.gmail.com>
From: John McCabe <johnfmccabe@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:05:45 +0000
Subject: [Xen-devel] hmmmmm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

root@pr-prodxen:/home/jmccabe# xm new test1.utopiaimage.local
Unexpected error: <type 'exceptions.ImportError'>

Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
  File "/usr/lib/xen-4.0/bin/xm", line 8, in <module>
    main.main(sys.argv)
  File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3620, in main
    _, rc = _run_cmd(cmd, cmd_name, args)
  File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3644, in _run_cmd
    return True, cmd(args)
  File "<string>", line 1, in <lambda>
  File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 1449, in
xm_importcommand
    cmd = __import__(command, globals(), locals(), 'xen.xm')
  File "/usr/lib/xen-4.0/lib/python/xen/xm/new.py", line 26, in <module>
    from xen.xm.xenapi_create import *
  File "/usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py", line 22,
in <module>
    from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
ImportError: No module named xmlproc

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjvn-00079D-7E; Fri, 27 Apr 2012 12:05:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <johnfmccabe@gmail.com>) id 1SMoiG-0002HQ-G4
	for xen-devel@lists.xensource.com; Tue, 24 Apr 2012 23:00:00 +0000
Received: from [85.158.138.51:43277] by server-9.bemta-3.messagelabs.com id
	B5/9D-26691-F60379F4; Tue, 24 Apr 2012 22:59:59 +0000
X-Env-Sender: johnfmccabe@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1335308398!23598863!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19155 invoked from network); 24 Apr 2012 22:59:59 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Apr 2012 22:59:59 -0000
Received: by qafl39 with SMTP id l39so516562qaf.9
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Apr 2012 15:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=X71IO4EUpcY7BRBHvp+mefTFKpqQYe3dTiEuuquSN5U=;
	b=pE8gr000HfnuWsd3LB06brnFpJuACKg1PIdeScQS20srNuFcMXjXc+oZDcXYBe7+oY
	ssdR2rVDc3YosAtlxBMhScF9dGINwd4aTXWdyxiNnBYOTRo/gAMvahXTWV4OU8fnYp6k
	Bn5s/YidVS7UHn9BkHcqKeFPdVY+lW+uTHEsgkbql8QZGhV27lVBxF4c8BTtwyVNUsJo
	iKY409goCXmdxKn769NaGultnICXnMixrRZEWmtLBNIICYXWVQnWJPGUNWxxVZzDfPTs
	XVQaWSM38m9QqqrY8zWW3rviKJXJB7486TxYmF05s/R+UIOY3rrSz/Zj0vCmbn8A2/lh
	9Krw==
MIME-Version: 1.0
Received: by 10.224.196.136 with SMTP id eg8mr575682qab.50.1335308397784; Tue,
	24 Apr 2012 15:59:57 -0700 (PDT)
Received: by 10.229.165.207 with HTTP; Tue, 24 Apr 2012 15:59:57 -0700 (PDT)
Date: Tue, 24 Apr 2012 18:59:57 -0400
Message-ID: <CAN4v=fFiurdG_4DZyiXb85kihpZNvMLfCprLcsy9DfsTq_e-_w@mail.gmail.com>
From: John McCabe <johnfmccabe@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:05:45 +0000
Subject: [Xen-devel] hmmmmm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

root@pr-prodxen:/home/jmccabe# xm new test1.utopiaimage.local
Unexpected error: <type 'exceptions.ImportError'>

Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
  File "/usr/lib/xen-4.0/bin/xm", line 8, in <module>
    main.main(sys.argv)
  File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3620, in main
    _, rc = _run_cmd(cmd, cmd_name, args)
  File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3644, in _run_cmd
    return True, cmd(args)
  File "<string>", line 1, in <lambda>
  File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 1449, in
xm_importcommand
    cmd = __import__(command, globals(), locals(), 'xen.xm')
  File "/usr/lib/xen-4.0/lib/python/xen/xm/new.py", line 26, in <module>
    from xen.xm.xenapi_create import *
  File "/usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py", line 22,
in <module>
    from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
ImportError: No module named xmlproc

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjws-0007Ce-MW; Fri, 27 Apr 2012 12:06:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1SMxJz-0005NI-LH
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:11:31 +0000
Received: from [193.109.254.147:38202] by server-5.bemta-14.messagelabs.com id
	02/12-30733-2B1B79F4; Wed, 25 Apr 2012 08:11:30 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335341489!6188469!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26884 invoked from network); 25 Apr 2012 08:11:30 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:11:30 -0000
Received: by wibhj13 with SMTP id hj13so4138415wib.6
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 01:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dVj6LIygU7xjLX8LEjmjYfPmOktJiVXBYSEUVRKqxRU=;
	b=I3lWoT+SeKKUQYaupkvuc0XkjjiDIsE6u78whnWqGJ5TLcLTxpstp+AcpoxEjn1r0g
	bXBTASR9esMoChcMT9+6o6in7JKeVZo9/onfBMFyKX0sec4pIBeZQ+KnwKWRn9WpQP7K
	KUHl5h85oQA1arocv1O0CBul5qHjYc8ags8MZwbDMjn6AHc3L/9/+Piav6DY1GYPsCPg
	qPfQemOpsW4Bx43zEhHEGWzruEPugn3R61BSgZnxh6jLM+stpjAa9w68l62TsRES1P0D
	ckn/Ol9RwDmlz7Vt5hJQPhYQ5MG9cBTCxojxmf8lj+IrtsqmajO+gJ40B3qFE7CIZH4H
	+jdg==
Received: by 10.180.104.137 with SMTP id ge9mr4133560wib.20.1335341489577;
	Wed, 25 Apr 2012 01:11:29 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id n8sm56190121wix.10.2012.04.25.01.11.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Apr 2012 01:11:28 -0700 (PDT)
Date: Wed, 25 Apr 2012 10:11:25 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Message-ID: <20120425081125.GA19849@gmail.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<m2aa21o7pk.fsf@firstfloor.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <m2aa21o7pk.fsf@firstfloor.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:06:53 +0000
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, tony.luck@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	torvalds@linux-foundation.org, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* Andi Kleen <andi@firstfloor.org> wrote:

> Borislav Petkov <bp@amd64.org> writes:
> 
> > Because, if you'd hooked into it, just imagine one fine day, when we
> > remove mcelog support, what screaming the xen people will be doing when
> > mcelog doesn't work anymore.
> 
> That's simple. /dev/mcelog is a widely used user space ABI 
> [...]

*COUGH* *SPLUTTER* *LAUGH*.

Thanks for making my day with the self-serving exaggeration of 
the year.

In truth /dev/mcelog is one of the crappiest ABIs Linux has - 
full stop. As a result it's barely used by anyone who can avoid 
it - its main usecase is the utility you wrote for it and some 
enterprise folks who desperately need that data and don't care 
how they get it. The mcelog user-space utility sucks too, 
understandably.

Nevertheless we probably have to keep the ABI around until a 
truly better replacement is out there (the RAS daemon for 
example) and mcelog usage eclipses to obscurity, but by all 
means we want to limit its further spreading /dev/mcelog to 
areas it has not polluted yet ...

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjws-0007Ce-MW; Fri, 27 Apr 2012 12:06:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1SMxJz-0005NI-LH
	for xen-devel@lists.xensource.com; Wed, 25 Apr 2012 08:11:31 +0000
Received: from [193.109.254.147:38202] by server-5.bemta-14.messagelabs.com id
	02/12-30733-2B1B79F4; Wed, 25 Apr 2012 08:11:30 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335341489!6188469!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26884 invoked from network); 25 Apr 2012 08:11:30 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Apr 2012 08:11:30 -0000
Received: by wibhj13 with SMTP id hj13so4138415wib.6
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Apr 2012 01:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dVj6LIygU7xjLX8LEjmjYfPmOktJiVXBYSEUVRKqxRU=;
	b=I3lWoT+SeKKUQYaupkvuc0XkjjiDIsE6u78whnWqGJ5TLcLTxpstp+AcpoxEjn1r0g
	bXBTASR9esMoChcMT9+6o6in7JKeVZo9/onfBMFyKX0sec4pIBeZQ+KnwKWRn9WpQP7K
	KUHl5h85oQA1arocv1O0CBul5qHjYc8ags8MZwbDMjn6AHc3L/9/+Piav6DY1GYPsCPg
	qPfQemOpsW4Bx43zEhHEGWzruEPugn3R61BSgZnxh6jLM+stpjAa9w68l62TsRES1P0D
	ckn/Ol9RwDmlz7Vt5hJQPhYQ5MG9cBTCxojxmf8lj+IrtsqmajO+gJ40B3qFE7CIZH4H
	+jdg==
Received: by 10.180.104.137 with SMTP id ge9mr4133560wib.20.1335341489577;
	Wed, 25 Apr 2012 01:11:29 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id n8sm56190121wix.10.2012.04.25.01.11.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Apr 2012 01:11:28 -0700 (PDT)
Date: Wed, 25 Apr 2012 10:11:25 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Message-ID: <20120425081125.GA19849@gmail.com>
References: <DE8DF0795D48FD4CA783C40EC8292335154EFC@SHSMSX101.ccr.corp.intel.com>
	<20120421041454.GA29704@phenom.dumpdata.com>
	<20120421104502.GB17005@aftab.osrc.amd.com>
	<m2aa21o7pk.fsf@firstfloor.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <m2aa21o7pk.fsf@firstfloor.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:06:53 +0000
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, tony.luck@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	torvalds@linux-foundation.org, linux-edac@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* Andi Kleen <andi@firstfloor.org> wrote:

> Borislav Petkov <bp@amd64.org> writes:
> 
> > Because, if you'd hooked into it, just imagine one fine day, when we
> > remove mcelog support, what screaming the xen people will be doing when
> > mcelog doesn't work anymore.
> 
> That's simple. /dev/mcelog is a widely used user space ABI 
> [...]

*COUGH* *SPLUTTER* *LAUGH*.

Thanks for making my day with the self-serving exaggeration of 
the year.

In truth /dev/mcelog is one of the crappiest ABIs Linux has - 
full stop. As a result it's barely used by anyone who can avoid 
it - its main usecase is the utility you wrote for it and some 
enterprise folks who desperately need that data and don't care 
how they get it. The mcelog user-space utility sucks too, 
understandably.

Nevertheless we probably have to keep the ABI around until a 
truly better replacement is out there (the RAS daemon for 
example) and mcelog usage eclipses to obscurity, but by all 
means we want to limit its further spreading /dev/mcelog to 
areas it has not polluted yet ...

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:08:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjxm-0007Gd-5q; Fri, 27 Apr 2012 12:07:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNRiG-0005XD-Uq
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 16:38:37 +0000
Received: from [193.109.254.147:29659] by server-11.bemta-14.messagelabs.com
	id 00/04-05858-C0A799F4; Thu, 26 Apr 2012 16:38:36 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335458309!6507026!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27139 invoked from network); 26 Apr 2012 16:38:30 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 16:38:30 -0000
Received: by lahe6 with SMTP id e6so1311603lah.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 09:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=XVkIdGhhOgjAde2DVN6CDluvQhxtuU/8ub5SF3aJMWg=;
	b=Pp56mvM4hpuEPaLNAHneIyJhqVXhFbkby410RMm2/j0/z460DPht0RjH5o1ARTaK1x
	v63NlSIxHLAmGSAdhMsDfmOgcAc+4xTUCMvv0j8AvwqLrDK1pmH5/dbWOYU4NTBnMRFi
	eF5/XFSgDQjkWMnSiKRP+7yjNPMpl2kwueOeJG8RkTcDbluhWNsETcIc3kgetz8w6gAK
	dFXTQTZnAe0DMP2HCzGpBBSykH6wTwYBCSF/WNDSicbfECG/s0Q7TzwGZGOMnGNf5n4R
	1HA/wnqo9hByeBYtuGskvJXSTGICudfiirtqn2eKayV5HVXVmthDzPk8LlfEBqaOvFIT
	yh/w==
MIME-Version: 1.0
Received: by 10.112.99.198 with SMTP id es6mr3464450lbb.66.1335458309154; Thu,
	26 Apr 2012 09:38:29 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Thu, 26 Apr 2012 09:38:29 -0700 (PDT)
Date: Thu, 26 Apr 2012 12:38:29 -0400
Message-ID: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
From: misiu godfrey <misiu.godfrey@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:07:49 +0000
Subject: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2678186708539197823=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2678186708539197823==
Content-Type: multipart/alternative; boundary=14dae9d67bb421280a04be979ef0

--14dae9d67bb421280a04be979ef0
Content-Type: text/plain; charset=ISO-8859-1

Hello Xen community,

This is my first time reporting a bug, so please let me know if I make
any faux-pas so that I may correct them in the future.

I checked out Xen-4.1-testing from the Mercurial repository on
Wednesday (4/25/12) and attempted to compile it with "make world" on a
machine running a
recent install of Debian 6 (squeeze) and encountered an error
described in the following text (tail-end of stderr):

...
git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
 ioemu-remote.tmp
Cloning into ioemu-remote.tmp...
remote: Counting objects: 80598, done.
remote: Compressing objects: 100% (22869/22869), done.
remote: Total 80598 (delta 60933), reused 76719 (delta 57621)
Receiving objects: 100% (80598/80598), 29.20 MiB | 6.08 MiB/s, done.
Resolving deltas: 100% (60933/60933), done.
+ [ a2d2123a7dfc4d116011d51f48df786a3b853537 ]
+ cd ioemu-remote.tmp
+ git branch -D dummy
+ :
+ git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537
fatal: reference is not a tree: a2d2123a7dfc4d116011d51f48df786a3b853537
make[1]: *** [ioemu-dir-find] Error 128
make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'
make: *** [tools/ioemu-dir] Error 2

I later determined that the error could be isolated within "make tools"

Curiously, I was able to checkout and compile code from the same
repository the previous day (4/24/12) on the same machine without any
problems.  I have not managed to find any previous bug or
configuration problems that quite match up to this, but I did notice
that there was a single revision to the repository between these two
periods.  The revision in question can be found at
"xenbits.xen.org/hg/xen-4.1-testing.hg/rev/99517f769cc8" and
specifically refers to the area in question (QEMU git access).

I have now attempted to compile the current (4/25/12) release of
4.1-testing on two different machines, both running Debian 6, and
obtained the same results (shown above).

I hope I have provided enough information to address the situation and
if, to my embarrassment, it turns out to be an issue on my end I would
appreciate advice as to how to overcome the problem.

Thanks,
Misiu.

--14dae9d67bb421280a04be979ef0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span>Hello Xen community,</span><br><br><span>This is my first time report=
ing a bug, so please let me know if I make</span><br><span>any faux-pas so =
that I may correct them in the future.</span><br>
<br><span>I checked out Xen-4.1-testing from the Mercurial repository on</s=
pan><br><span>Wednesday (4/25/12) and attempted to compile it with &quot;ma=
ke world&quot; on a machine running a</span><br><span>recent install of Deb=
ian 6 (squeeze) and encountered an error</span><br>

<span>described in the following text (tail-end of stderr):</span><br><br><=
span>...</span><br><span>git clone git://</span><a href=3D"http://xenbits.x=
ensource.com/qemu-xen-4.1-testing.git" target=3D"_blank">xenbits.xensource.=
com/qemu-xen-4.1-testing.git</a><span>=A0ioemu-remote.tmp</span><br>

<span>Cloning into ioemu-remote.tmp...</span><br><span>remote: Counting obj=
ects: 80598, done.</span><br><span>remote: Compressing objects: 100%=A0</sp=
an><a href=3D"tel:%2822869%2F22869" value=3D"+12286922869" target=3D"_blank=
">(22869/22869</a><span>), done.</span><br>

<span>remote: Total 80598 (delta 60933), reused 76719 (delta 57621)</span><=
br><span>Receiving objects: 100%=A0</span><a href=3D"tel:%2880598%2F80598" =
value=3D"+18059880598" target=3D"_blank">(80598/80598</a><span>), 29.20 MiB=
 | 6.08 MiB/s, done.</span><br>

<span>Resolving deltas: 100%=A0</span><a href=3D"tel:%2860933%2F60933" valu=
e=3D"+16093360933" target=3D"_blank">(60933/60933</a><span>), done.</span><=
br><span>+ [ a2d2123a7dfc4d116011d51f48df78</span><span>6a3b853537 ]</span>=
<br>

<span>+ cd ioemu-remote.tmp</span><br><span>+ git branch -D dummy</span><br=
><span>+ :</span><br><span>+ git checkout -b dummy a2d2123a7dfc4d116011d51f=
48df78</span><span>6a3b853537</span><br>
<span>fatal: reference is not a tree: a2d2123a7dfc4d116011d51f48df78</span>=
<span>6a3b853537</span><br><span>make[1]: *** [ioemu-dir-find] Error 128</s=
pan><br><span>make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-</span><s=
pan>testing.hg/tools&#39;</span><br>

<span>make: *** [tools/ioemu-dir] Error 2</span><br><br>I later determined =
that the error could be isolated within &quot;make tools&quot;<br><br><span=
>Curiously, I was able to checkout and compile code from the same</span><br=
>
<span>repository the previous day (4/24/12) on the same machine without any=
</span><br>
<span>problems. =A0I have not managed to find any previous bug or</span><br=
><span>configuration problems that quite match up to this, but I did notice=
</span><br><span>that there was a single revision to the repository between=
 these two</span><br>

<span>periods. =A0The revision in question can be found at</span><br><span>=
&quot;</span><a href=3D"http://xenbits.xen.org/hg/xen-4.1-testing.hg/rev/99=
517f769cc8" target=3D"_blank">xenbits.xen.org/hg/xen-4.1-testing.hg/rev/995=
17f769cc8</a><span>&quot; and</span><br>

<span>specifically refers to the area in question (QEMU git access).</span>=
<br><br><span>I have now attempted to compile the current (4/25/12) release=
 of</span><br><span>4.1-testing on two different machines, both running Deb=
ian 6, and</span><br>

<span>obtained the same results (shown above).</span><br><br><span>I hope I=
 have provided enough information to address the situation and</span><br><s=
pan>if, to my embarrassment, it turns out to be an issue on my end I would<=
/span><br>

<span>appreciate advice as to how to overcome the problem.</span><br><br><s=
pan>Thanks,</span><br><span>Misiu.</span>


--14dae9d67bb421280a04be979ef0--


--===============2678186708539197823==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2678186708539197823==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 12:08:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjxm-0007Gd-5q; Fri, 27 Apr 2012 12:07:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNRiG-0005XD-Uq
	for xen-devel@lists.xen.org; Thu, 26 Apr 2012 16:38:37 +0000
Received: from [193.109.254.147:29659] by server-11.bemta-14.messagelabs.com
	id 00/04-05858-C0A799F4; Thu, 26 Apr 2012 16:38:36 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1335458309!6507026!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27139 invoked from network); 26 Apr 2012 16:38:30 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 16:38:30 -0000
Received: by lahe6 with SMTP id e6so1311603lah.32
	for <xen-devel@lists.xen.org>; Thu, 26 Apr 2012 09:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=XVkIdGhhOgjAde2DVN6CDluvQhxtuU/8ub5SF3aJMWg=;
	b=Pp56mvM4hpuEPaLNAHneIyJhqVXhFbkby410RMm2/j0/z460DPht0RjH5o1ARTaK1x
	v63NlSIxHLAmGSAdhMsDfmOgcAc+4xTUCMvv0j8AvwqLrDK1pmH5/dbWOYU4NTBnMRFi
	eF5/XFSgDQjkWMnSiKRP+7yjNPMpl2kwueOeJG8RkTcDbluhWNsETcIc3kgetz8w6gAK
	dFXTQTZnAe0DMP2HCzGpBBSykH6wTwYBCSF/WNDSicbfECG/s0Q7TzwGZGOMnGNf5n4R
	1HA/wnqo9hByeBYtuGskvJXSTGICudfiirtqn2eKayV5HVXVmthDzPk8LlfEBqaOvFIT
	yh/w==
MIME-Version: 1.0
Received: by 10.112.99.198 with SMTP id es6mr3464450lbb.66.1335458309154; Thu,
	26 Apr 2012 09:38:29 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Thu, 26 Apr 2012 09:38:29 -0700 (PDT)
Date: Thu, 26 Apr 2012 12:38:29 -0400
Message-ID: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
From: misiu godfrey <misiu.godfrey@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:07:49 +0000
Subject: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2678186708539197823=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2678186708539197823==
Content-Type: multipart/alternative; boundary=14dae9d67bb421280a04be979ef0

--14dae9d67bb421280a04be979ef0
Content-Type: text/plain; charset=ISO-8859-1

Hello Xen community,

This is my first time reporting a bug, so please let me know if I make
any faux-pas so that I may correct them in the future.

I checked out Xen-4.1-testing from the Mercurial repository on
Wednesday (4/25/12) and attempted to compile it with "make world" on a
machine running a
recent install of Debian 6 (squeeze) and encountered an error
described in the following text (tail-end of stderr):

...
git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
 ioemu-remote.tmp
Cloning into ioemu-remote.tmp...
remote: Counting objects: 80598, done.
remote: Compressing objects: 100% (22869/22869), done.
remote: Total 80598 (delta 60933), reused 76719 (delta 57621)
Receiving objects: 100% (80598/80598), 29.20 MiB | 6.08 MiB/s, done.
Resolving deltas: 100% (60933/60933), done.
+ [ a2d2123a7dfc4d116011d51f48df786a3b853537 ]
+ cd ioemu-remote.tmp
+ git branch -D dummy
+ :
+ git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537
fatal: reference is not a tree: a2d2123a7dfc4d116011d51f48df786a3b853537
make[1]: *** [ioemu-dir-find] Error 128
make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'
make: *** [tools/ioemu-dir] Error 2

I later determined that the error could be isolated within "make tools"

Curiously, I was able to checkout and compile code from the same
repository the previous day (4/24/12) on the same machine without any
problems.  I have not managed to find any previous bug or
configuration problems that quite match up to this, but I did notice
that there was a single revision to the repository between these two
periods.  The revision in question can be found at
"xenbits.xen.org/hg/xen-4.1-testing.hg/rev/99517f769cc8" and
specifically refers to the area in question (QEMU git access).

I have now attempted to compile the current (4/25/12) release of
4.1-testing on two different machines, both running Debian 6, and
obtained the same results (shown above).

I hope I have provided enough information to address the situation and
if, to my embarrassment, it turns out to be an issue on my end I would
appreciate advice as to how to overcome the problem.

Thanks,
Misiu.

--14dae9d67bb421280a04be979ef0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span>Hello Xen community,</span><br><br><span>This is my first time report=
ing a bug, so please let me know if I make</span><br><span>any faux-pas so =
that I may correct them in the future.</span><br>
<br><span>I checked out Xen-4.1-testing from the Mercurial repository on</s=
pan><br><span>Wednesday (4/25/12) and attempted to compile it with &quot;ma=
ke world&quot; on a machine running a</span><br><span>recent install of Deb=
ian 6 (squeeze) and encountered an error</span><br>

<span>described in the following text (tail-end of stderr):</span><br><br><=
span>...</span><br><span>git clone git://</span><a href=3D"http://xenbits.x=
ensource.com/qemu-xen-4.1-testing.git" target=3D"_blank">xenbits.xensource.=
com/qemu-xen-4.1-testing.git</a><span>=A0ioemu-remote.tmp</span><br>

<span>Cloning into ioemu-remote.tmp...</span><br><span>remote: Counting obj=
ects: 80598, done.</span><br><span>remote: Compressing objects: 100%=A0</sp=
an><a href=3D"tel:%2822869%2F22869" value=3D"+12286922869" target=3D"_blank=
">(22869/22869</a><span>), done.</span><br>

<span>remote: Total 80598 (delta 60933), reused 76719 (delta 57621)</span><=
br><span>Receiving objects: 100%=A0</span><a href=3D"tel:%2880598%2F80598" =
value=3D"+18059880598" target=3D"_blank">(80598/80598</a><span>), 29.20 MiB=
 | 6.08 MiB/s, done.</span><br>

<span>Resolving deltas: 100%=A0</span><a href=3D"tel:%2860933%2F60933" valu=
e=3D"+16093360933" target=3D"_blank">(60933/60933</a><span>), done.</span><=
br><span>+ [ a2d2123a7dfc4d116011d51f48df78</span><span>6a3b853537 ]</span>=
<br>

<span>+ cd ioemu-remote.tmp</span><br><span>+ git branch -D dummy</span><br=
><span>+ :</span><br><span>+ git checkout -b dummy a2d2123a7dfc4d116011d51f=
48df78</span><span>6a3b853537</span><br>
<span>fatal: reference is not a tree: a2d2123a7dfc4d116011d51f48df78</span>=
<span>6a3b853537</span><br><span>make[1]: *** [ioemu-dir-find] Error 128</s=
pan><br><span>make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-</span><s=
pan>testing.hg/tools&#39;</span><br>

<span>make: *** [tools/ioemu-dir] Error 2</span><br><br>I later determined =
that the error could be isolated within &quot;make tools&quot;<br><br><span=
>Curiously, I was able to checkout and compile code from the same</span><br=
>
<span>repository the previous day (4/24/12) on the same machine without any=
</span><br>
<span>problems. =A0I have not managed to find any previous bug or</span><br=
><span>configuration problems that quite match up to this, but I did notice=
</span><br><span>that there was a single revision to the repository between=
 these two</span><br>

<span>periods. =A0The revision in question can be found at</span><br><span>=
&quot;</span><a href=3D"http://xenbits.xen.org/hg/xen-4.1-testing.hg/rev/99=
517f769cc8" target=3D"_blank">xenbits.xen.org/hg/xen-4.1-testing.hg/rev/995=
17f769cc8</a><span>&quot; and</span><br>

<span>specifically refers to the area in question (QEMU git access).</span>=
<br><br><span>I have now attempted to compile the current (4/25/12) release=
 of</span><br><span>4.1-testing on two different machines, both running Deb=
ian 6, and</span><br>

<span>obtained the same results (shown above).</span><br><br><span>I hope I=
 have provided enough information to address the situation and</span><br><s=
pan>if, to my embarrassment, it turns out to be an issue on my end I would<=
/span><br>

<span>appreciate advice as to how to overcome the problem.</span><br><br><s=
pan>Thanks,</span><br><span>Misiu.</span>


--14dae9d67bb421280a04be979ef0--


--===============2678186708539197823==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2678186708539197823==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 12:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjyb-0007Lp-KA; Fri, 27 Apr 2012 12:08:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SNRBu-0005Ev-1P
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 16:05:10 +0000
Received: from [85.158.143.99:17414] by server-3.bemta-4.messagelabs.com id
	0D/77-05853-532799F4; Thu, 26 Apr 2012 16:05:09 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335456305!19049272!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA1Nzc5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30886 invoked from network); 26 Apr 2012 16:05:08 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 16:05:08 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 26 Apr 2012 21:35:04 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 26 Apr 2012 21:35:01 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3QG4wLU4071620
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 21:35:01 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3QLZYrV031272
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 07:35:35 +1000
Received: from [9.77.121.107] ([9.77.121.107])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3QLZVKT031071; Fri, 27 Apr 2012 07:35:32 +1000
Message-ID: <4F997216.6080804@linux.vnet.ibm.com>
Date: Thu, 26 Apr 2012 21:34:38 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Rob Landley <rob@landley.net>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
	<4F997058.6070509@landley.net>
In-Reply-To: <4F997058.6070509@landley.net>
x-cbid: 12042616-8878-0000-0000-00000230932A
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:08:40 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/26/2012 09:27 PM, Rob Landley wrote:
> On 04/23/2012 05:00 AM, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
> ...
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>> @@ -0,0 +1,59 @@
>> +KVM Hypercalls Documentation
>> +===========================
>> +Template for documentation is
>> +The documenenation for hypercalls should inlcude
>
> What does the line about templates mean/
>
> documenenation? inlcude?

I think I should correct some redundant statements here. The template is 
meant for current "structure / layout of hypercall documentation".

>
>> +1. Hypercall name, value.
>> +2. Architecture(s)
>> +3. status (deprecated, obsolete, active)
>> +4. Purpose
>> +
>> +
>> +1. KVM_HC_VAPIC_POLL_IRQ
>> +------------------------
>> +value: 1
>> +Architecture: x86
>> +Purpose:
>
> Purpose: none.
>

Will add this when I respin the patch soon

> Rob

Thanks for review.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjyb-0007Lp-KA; Fri, 27 Apr 2012 12:08:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SNRBu-0005Ev-1P
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 16:05:10 +0000
Received: from [85.158.143.99:17414] by server-3.bemta-4.messagelabs.com id
	0D/77-05853-532799F4; Thu, 26 Apr 2012 16:05:09 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335456305!19049272!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA1Nzc5NA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30886 invoked from network); 26 Apr 2012 16:05:08 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Apr 2012 16:05:08 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 26 Apr 2012 21:35:04 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 26 Apr 2012 21:35:01 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3QG4wLU4071620
	for <xen-devel@lists.xensource.com>; Thu, 26 Apr 2012 21:35:01 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3QLZYrV031272
	for <xen-devel@lists.xensource.com>; Fri, 27 Apr 2012 07:35:35 +1000
Received: from [9.77.121.107] ([9.77.121.107])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3QLZVKT031071; Fri, 27 Apr 2012 07:35:32 +1000
Message-ID: <4F997216.6080804@linux.vnet.ibm.com>
Date: Thu, 26 Apr 2012 21:34:38 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Rob Landley <rob@landley.net>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
	<4F997058.6070509@landley.net>
In-Reply-To: <4F997058.6070509@landley.net>
x-cbid: 12042616-8878-0000-0000-00000230932A
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:08:40 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/26/2012 09:27 PM, Rob Landley wrote:
> On 04/23/2012 05:00 AM, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
> ...
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>> @@ -0,0 +1,59 @@
>> +KVM Hypercalls Documentation
>> +===========================
>> +Template for documentation is
>> +The documenenation for hypercalls should inlcude
>
> What does the line about templates mean/
>
> documenenation? inlcude?

I think I should correct some redundant statements here. The template is 
meant for current "structure / layout of hypercall documentation".

>
>> +1. Hypercall name, value.
>> +2. Architecture(s)
>> +3. status (deprecated, obsolete, active)
>> +4. Purpose
>> +
>> +
>> +1. KVM_HC_VAPIC_POLL_IRQ
>> +------------------------
>> +value: 1
>> +Architecture: x86
>> +Purpose:
>
> Purpose: none.
>

Will add this when I respin the patch soon

> Rob

Thanks for review.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:09:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjz9-0007Ql-3A; Fri, 27 Apr 2012 12:09:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rob@landley.net>) id 1SNR4P-0004id-Ka
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:57:25 +0000
Received: from [85.158.143.99:35049] by server-1.bemta-4.messagelabs.com id
	CB/99-20925-460799F4; Thu, 26 Apr 2012 15:57:24 +0000
X-Env-Sender: rob@landley.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335455843!25442460!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 843 invoked from network); 26 Apr 2012 15:57:24 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 15:57:24 -0000
Received: by obbtb18 with SMTP id tb18so2185987obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Apr 2012 08:57:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=TjkmvxCeFvOTlPEdvlfsfX9G0nFaxR33IJo4WTeXNiA=;
	b=CPY+MtgwWpJTLnIUdAaRw7/X6IvkPDq5KiS/oGxcrLKJwOMKjBMoq0pkHQONRFDVxE
	om7abzb+IltFVRP+99uPyRzgbTIk+glP3NKIpFn8Ad8fh8SmfdSkdnK/RiYowhbUcu47
	RwkwWRVg6aqisnQQqDCIHV0mTtZnC4iBhOC5UOKDTPZEdnJN69+zb2u+qeSn/er3T8Is
	nV4TpT0bn+MMn0m9MrEtpeRGDROnTs1KnPE5mn33BbrtB3ILFRFIAj1oOA2mwLGXtpch
	5V5gWrhc8QWIaYLTeVjgQXgjMyGg+DihWbrIz+qzOYr3THgTC+6h9ED+cgmhJ5WWT6g8
	LKdw==
Received: by 10.182.152.72 with SMTP id uw8mr9555228obb.73.1335455842606;
	Thu, 26 Apr 2012 08:57:22 -0700 (PDT)
Received: from [192.168.1.2] (cpe-70-112-201-3.austin.res.rr.com.
	[70.112.201.3])
	by mx.google.com with ESMTPS id r8sm3201516oer.6.2012.04.26.08.57.19
	(version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 08:57:20 -0700 (PDT)
Message-ID: <4F997058.6070509@landley.net>
Date: Thu, 26 Apr 2012 10:57:12 -0500
From: Rob Landley <rob@landley.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
X-Gm-Message-State: ALoCoQnxl6STrvZkCcN52ihCY8FIBa/L5Nui+wpCGgY+ZindpEE8a9fmVsfNAxxiC1lp+XroFA28
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:09:13 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 05:00 AM, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 
...
> --- /dev/null
> +++ b/Documentation/virtual/kvm/hypercalls.txt
> @@ -0,0 +1,59 @@
> +KVM Hypercalls Documentation
> +===========================
> +Template for documentation is
> +The documenenation for hypercalls should inlcude

What does the line about templates mean/

documenenation? inlcude?

> +1. Hypercall name, value.
> +2. Architecture(s)
> +3. status (deprecated, obsolete, active)
> +4. Purpose
> +
> +
> +1. KVM_HC_VAPIC_POLL_IRQ
> +------------------------
> +value: 1
> +Architecture: x86
> +Purpose:

Purpose: none.

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:09:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNjz9-0007Ql-3A; Fri, 27 Apr 2012 12:09:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rob@landley.net>) id 1SNR4P-0004id-Ka
	for xen-devel@lists.xensource.com; Thu, 26 Apr 2012 15:57:25 +0000
Received: from [85.158.143.99:35049] by server-1.bemta-4.messagelabs.com id
	CB/99-20925-460799F4; Thu, 26 Apr 2012 15:57:24 +0000
X-Env-Sender: rob@landley.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335455843!25442460!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 843 invoked from network); 26 Apr 2012 15:57:24 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Apr 2012 15:57:24 -0000
Received: by obbtb18 with SMTP id tb18so2185987obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Apr 2012 08:57:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=TjkmvxCeFvOTlPEdvlfsfX9G0nFaxR33IJo4WTeXNiA=;
	b=CPY+MtgwWpJTLnIUdAaRw7/X6IvkPDq5KiS/oGxcrLKJwOMKjBMoq0pkHQONRFDVxE
	om7abzb+IltFVRP+99uPyRzgbTIk+glP3NKIpFn8Ad8fh8SmfdSkdnK/RiYowhbUcu47
	RwkwWRVg6aqisnQQqDCIHV0mTtZnC4iBhOC5UOKDTPZEdnJN69+zb2u+qeSn/er3T8Is
	nV4TpT0bn+MMn0m9MrEtpeRGDROnTs1KnPE5mn33BbrtB3ILFRFIAj1oOA2mwLGXtpch
	5V5gWrhc8QWIaYLTeVjgQXgjMyGg+DihWbrIz+qzOYr3THgTC+6h9ED+cgmhJ5WWT6g8
	LKdw==
Received: by 10.182.152.72 with SMTP id uw8mr9555228obb.73.1335455842606;
	Thu, 26 Apr 2012 08:57:22 -0700 (PDT)
Received: from [192.168.1.2] (cpe-70-112-201-3.austin.res.rr.com.
	[70.112.201.3])
	by mx.google.com with ESMTPS id r8sm3201516oer.6.2012.04.26.08.57.19
	(version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 08:57:20 -0700 (PDT)
Message-ID: <4F997058.6070509@landley.net>
Date: Thu, 26 Apr 2012 10:57:12 -0500
From: Rob Landley <rob@landley.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423100034.30893.81866.sendpatchset@codeblue.in.ibm.com>
X-Gm-Message-State: ALoCoQnxl6STrvZkCcN52ihCY8FIBa/L5Nui+wpCGgY+ZindpEE8a9fmVsfNAxxiC1lp+XroFA28
X-Mailman-Approved-At: Fri, 27 Apr 2012 12:09:13 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 05:00 AM, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 
...
> --- /dev/null
> +++ b/Documentation/virtual/kvm/hypercalls.txt
> @@ -0,0 +1,59 @@
> +KVM Hypercalls Documentation
> +===========================
> +Template for documentation is
> +The documenenation for hypercalls should inlcude

What does the line about templates mean/

documenenation? inlcude?

> +1. Hypercall name, value.
> +2. Architecture(s)
> +3. status (deprecated, obsolete, active)
> +4. Purpose
> +
> +
> +1. KVM_HC_VAPIC_POLL_IRQ
> +------------------------
> +value: 1
> +Architecture: x86
> +Purpose:

Purpose: none.

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:15:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNk59-0007sP-1w; Fri, 27 Apr 2012 12:15:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNk58-0007sK-Au
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 12:15:26 +0000
Received: from [193.109.254.147:46599] by server-3.bemta-14.messagelabs.com id
	4A/43-23274-DDD8A9F4; Fri, 27 Apr 2012 12:15:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335528922!957901!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19842 invoked from network); 27 Apr 2012 12:15:23 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 12:15:23 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNk53-0006wz-Qp
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 05:15:21 -0700
Date: Fri, 27 Apr 2012 05:15:21 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335528921825-5670111.post@n5.nabble.com>
In-Reply-To: <1335517688.28015.180.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

About second issue apllying patch seem solved.
About first also with this change:

vi Config.mk
PYTHON_PREFIX_ARG = --install-layout=deb

not work, show different error:
Parsing config file /etc/xen/lucid.cfg
libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
-3

pygrub /mnt/vm/disks/lucid.disk1.xm 
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 822, in <module>
    raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel


--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:15:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNk59-0007sP-1w; Fri, 27 Apr 2012 12:15:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNk58-0007sK-Au
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 12:15:26 +0000
Received: from [193.109.254.147:46599] by server-3.bemta-14.messagelabs.com id
	4A/43-23274-DDD8A9F4; Fri, 27 Apr 2012 12:15:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1335528922!957901!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19842 invoked from network); 27 Apr 2012 12:15:23 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 12:15:23 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNk53-0006wz-Qp
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 05:15:21 -0700
Date: Fri, 27 Apr 2012 05:15:21 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335528921825-5670111.post@n5.nabble.com>
In-Reply-To: <1335517688.28015.180.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

About second issue apllying patch seem solved.
About first also with this change:

vi Config.mk
PYTHON_PREFIX_ARG = --install-layout=deb

not work, show different error:
Parsing config file /etc/xen/lucid.cfg
libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
-3

pygrub /mnt/vm/disks/lucid.disk1.xm 
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 822, in <module>
    raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel


--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:24:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:24:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkDM-00081p-16; Fri, 27 Apr 2012 12:23:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNkDL-00081k-4k
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 12:23:55 +0000
Received: from [85.158.139.83:16173] by server-9.bemta-5.messagelabs.com id
	F9/1D-09826-ADF8A9F4; Fri, 27 Apr 2012 12:23:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335529433!21917807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5507 invoked from network); 27 Apr 2012 12:23:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 12:23:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12177031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 12:23:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 13:23:52 +0100
Message-ID: <1335529430.28015.194.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 13:23:50 +0100
In-Reply-To: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 17:38 +0100, misiu godfrey wrote:
> Hello Xen community,
> 
> This is my first time reporting a bug, so please let me know if I make
> any faux-pas so that I may correct them in the future.
> 
> I checked out Xen-4.1-testing from the Mercurial repository on
> Wednesday (4/25/12)

Are you using the staging or non-staging version? What was the exact URL
you cloned?

[...]
> + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537
> fatal: reference is not a tree:
> a2d2123a7dfc4d116011d51f48df786a3b853537

This seems to be there now and it "works for me" (tm). Might just have
been skew with the staging tree -- can you try again?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:24:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:24:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkDM-00081p-16; Fri, 27 Apr 2012 12:23:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNkDL-00081k-4k
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 12:23:55 +0000
Received: from [85.158.139.83:16173] by server-9.bemta-5.messagelabs.com id
	F9/1D-09826-ADF8A9F4; Fri, 27 Apr 2012 12:23:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335529433!21917807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5507 invoked from network); 27 Apr 2012 12:23:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 12:23:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12177031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 12:23:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 13:23:52 +0100
Message-ID: <1335529430.28015.194.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 13:23:50 +0100
In-Reply-To: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-04-26 at 17:38 +0100, misiu godfrey wrote:
> Hello Xen community,
> 
> This is my first time reporting a bug, so please let me know if I make
> any faux-pas so that I may correct them in the future.
> 
> I checked out Xen-4.1-testing from the Mercurial repository on
> Wednesday (4/25/12)

Are you using the staging or non-staging version? What was the exact URL
you cloned?

[...]
> + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537
> fatal: reference is not a tree:
> a2d2123a7dfc4d116011d51f48df786a3b853537

This seems to be there now and it "works for me" (tm). Might just have
been skew with the staging tree -- can you try again?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkR6-0008Dm-Jr; Fri, 27 Apr 2012 12:38:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNkR4-0008Dh-M2
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 12:38:06 +0000
Received: from [85.158.138.51:29179] by server-12.bemta-3.messagelabs.com id
	1A/CE-29760-D239A9F4; Fri, 27 Apr 2012 12:38:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335530284!24041791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26895 invoked from network); 27 Apr 2012 12:38:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 12:38:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12177306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 12:38:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 13:38:04 +0100
Message-ID: <1335530282.28015.197.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McCabe <johnfmccabe@gmail.com>
Date: Fri, 27 Apr 2012 13:38:02 +0100
In-Reply-To: <CAN4v=fFiurdG_4DZyiXb85kihpZNvMLfCprLcsy9DfsTq_e-_w@mail.gmail.com>
References: <CAN4v=fFiurdG_4DZyiXb85kihpZNvMLfCprLcsy9DfsTq_e-_w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] hmmmmm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 23:59 +0100, John McCabe wrote:
> root@pr-prodxen:/home/jmccabe# xm new test1.utopiaimage.local
> Unexpected error: <type 'exceptions.ImportError'>
> 
> Please report to xen-devel@lists.xensource.com
> Traceback (most recent call last):
>   File "/usr/lib/xen-4.0/bin/xm", line 8, in <module>
>     main.main(sys.argv)
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3620, in main
>     _, rc = _run_cmd(cmd, cmd_name, args)
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3644, in _run_cmd
>     return True, cmd(args)
>   File "<string>", line 1, in <lambda>
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 1449, in
> xm_importcommand
>     cmd = __import__(command, globals(), locals(), 'xen.xm')
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/new.py", line 26, in <module>
>     from xen.xm.xenapi_create import *
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py", line 22,
> in <module>
>     from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
> ImportError: No module named xmlproc

You appear to be missing whichever package provides xmlproc (python-xml
perhaps?)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkR6-0008Dm-Jr; Fri, 27 Apr 2012 12:38:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNkR4-0008Dh-M2
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 12:38:06 +0000
Received: from [85.158.138.51:29179] by server-12.bemta-3.messagelabs.com id
	1A/CE-29760-D239A9F4; Fri, 27 Apr 2012 12:38:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335530284!24041791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26895 invoked from network); 27 Apr 2012 12:38:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 12:38:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12177306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 12:38:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 13:38:04 +0100
Message-ID: <1335530282.28015.197.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McCabe <johnfmccabe@gmail.com>
Date: Fri, 27 Apr 2012 13:38:02 +0100
In-Reply-To: <CAN4v=fFiurdG_4DZyiXb85kihpZNvMLfCprLcsy9DfsTq_e-_w@mail.gmail.com>
References: <CAN4v=fFiurdG_4DZyiXb85kihpZNvMLfCprLcsy9DfsTq_e-_w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] hmmmmm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-04-24 at 23:59 +0100, John McCabe wrote:
> root@pr-prodxen:/home/jmccabe# xm new test1.utopiaimage.local
> Unexpected error: <type 'exceptions.ImportError'>
> 
> Please report to xen-devel@lists.xensource.com
> Traceback (most recent call last):
>   File "/usr/lib/xen-4.0/bin/xm", line 8, in <module>
>     main.main(sys.argv)
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3620, in main
>     _, rc = _run_cmd(cmd, cmd_name, args)
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3644, in _run_cmd
>     return True, cmd(args)
>   File "<string>", line 1, in <lambda>
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 1449, in
> xm_importcommand
>     cmd = __import__(command, globals(), locals(), 'xen.xm')
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/new.py", line 26, in <module>
>     from xen.xm.xenapi_create import *
>   File "/usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py", line 22,
> in <module>
>     from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
> ImportError: No module named xmlproc

You appear to be missing whichever package provides xmlproc (python-xml
perhaps?)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:46:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkYs-0008Q4-IC; Fri, 27 Apr 2012 12:46:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNkYq-0008Pz-BD
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 12:46:08 +0000
Received: from [85.158.138.51:41059] by server-1.bemta-3.messagelabs.com id
	AA/A3-11491-F059A9F4; Fri, 27 Apr 2012 12:46:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335530765!13126189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14657 invoked from network); 27 Apr 2012 12:46:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 12:46:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 13:46:04 +0100
Message-Id: <4F9AB141020000780008075D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 13:46:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
	<1335527893.28015.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335527893.28015.191.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 13:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
>> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
>> >> From: David Vrabel <david.vrabel@citrix.com>
>> >> 
>> >> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
>> >> called even if no events were pending.
>> > 
>> > In actual fact it seems that the callback was actually being called if
>> > and only if no events were pending? Which makes me wonder how it used to
>> > work at all!
>> > 
>> >> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
>> >> index 79d7362..3e45aa0 100644
>> >> --- a/arch/x86/xen/xen-asm.S
>> >> +++ b/arch/x86/xen/xen-asm.S
>> >> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>> >>  
>> >>  	/* check for unmasked and pending */
>> >>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
>> >> -	jz 1f
>> >> +	jnz 1f
>> >>  2:	call check_events
>> >>  1:
>> > 
>> > Took me a while, this is a bit tricksy (and it may well be too early for
>> > me to be decoding it) since the check here is trying to check both
>> > pending and masked in a single cmpw, but I think this is correct. It
>> > will call check_events now only when the combined mask+pending word is
>> > 0x0001 (aka unmasked, pending).
>> 
>> It is _too much_ trickery, as it implies that the pending field, when set,
>> will always be 1. This is not sanctioned by the specification (quoting
>> the hypervisor's xen/include/public/xen.h):
>> 
>>      * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
>>      * a pending notification for a particular VCPU. It is then cleared 
>>      * by the guest OS /before/ checking for pending work, thus avoiding
>> 
>> Note that it says "non-zero", not "1".
> 
> Hrm, has it ever not been 1 in practice?

I don't think so.

> i.e. could we legitimately tighten the spec?

I wouldn't want to recommend this. In particular, we can't all of the
sudden keep guests from storing other non-zero values in here.

While I'm not in favor of this either, what we could do is specify that
Xen will only ever write 0 or 1 in here, while other non-zero values
are okay to be used by guests.

>> But yes, this isn't the fault of the patch here, so this is also not an
>> objection to this patch.
>> 
>> And yes, it can still be done with a single compare afaict, just not
>> directly on the memory operand.
> 
> Code size is also a concern here since this sequence of instructions is
> used for inline patching (not sure what the size limit actually is
> though).

Oh yes, didn't think of that aspect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:46:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkYs-0008Q4-IC; Fri, 27 Apr 2012 12:46:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNkYq-0008Pz-BD
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 12:46:08 +0000
Received: from [85.158.138.51:41059] by server-1.bemta-3.messagelabs.com id
	AA/A3-11491-F059A9F4; Fri, 27 Apr 2012 12:46:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1335530765!13126189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14657 invoked from network); 27 Apr 2012 12:46:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 12:46:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 13:46:04 +0100
Message-Id: <4F9AB141020000780008075D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 13:46:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
	<1335527893.28015.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335527893.28015.191.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 13:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
>> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
>> >> From: David Vrabel <david.vrabel@citrix.com>
>> >> 
>> >> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
>> >> called even if no events were pending.
>> > 
>> > In actual fact it seems that the callback was actually being called if
>> > and only if no events were pending? Which makes me wonder how it used to
>> > work at all!
>> > 
>> >> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
>> >> index 79d7362..3e45aa0 100644
>> >> --- a/arch/x86/xen/xen-asm.S
>> >> +++ b/arch/x86/xen/xen-asm.S
>> >> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
>> >>  
>> >>  	/* check for unmasked and pending */
>> >>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
>> >> -	jz 1f
>> >> +	jnz 1f
>> >>  2:	call check_events
>> >>  1:
>> > 
>> > Took me a while, this is a bit tricksy (and it may well be too early for
>> > me to be decoding it) since the check here is trying to check both
>> > pending and masked in a single cmpw, but I think this is correct. It
>> > will call check_events now only when the combined mask+pending word is
>> > 0x0001 (aka unmasked, pending).
>> 
>> It is _too much_ trickery, as it implies that the pending field, when set,
>> will always be 1. This is not sanctioned by the specification (quoting
>> the hypervisor's xen/include/public/xen.h):
>> 
>>      * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
>>      * a pending notification for a particular VCPU. It is then cleared 
>>      * by the guest OS /before/ checking for pending work, thus avoiding
>> 
>> Note that it says "non-zero", not "1".
> 
> Hrm, has it ever not been 1 in practice?

I don't think so.

> i.e. could we legitimately tighten the spec?

I wouldn't want to recommend this. In particular, we can't all of the
sudden keep guests from storing other non-zero values in here.

While I'm not in favor of this either, what we could do is specify that
Xen will only ever write 0 or 1 in here, while other non-zero values
are okay to be used by guests.

>> But yes, this isn't the fault of the patch here, so this is also not an
>> objection to this patch.
>> 
>> And yes, it can still be done with a single compare afaict, just not
>> directly on the memory operand.
> 
> Code size is also a concern here since this sequence of instructions is
> used for inline patching (not sure what the size limit actually is
> though).

Oh yes, didn't think of that aspect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:49:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkbo-00006L-Ua; Fri, 27 Apr 2012 12:49:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNkbn-00006A-Jt
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 12:49:11 +0000
Received: from [85.158.143.35:22144] by server-3.bemta-4.messagelabs.com id
	19/C8-05853-6C59A9F4; Fri, 27 Apr 2012 12:49:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335530949!13898931!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31159 invoked from network); 27 Apr 2012 12:49:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 12:49:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 13:49:09 +0100
Message-Id: <4F9AB1F90200007800080769@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 13:49:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <be41f3b599d9bba57281.1335379132@vollum>
	<1f39b9fe704f40f394e0.1335379133@vollum>
In-Reply-To: <1f39b9fe704f40f394e0.1335379133@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to
 HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 20:38, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Given that we're in feature freeze right now - is this actually fixing some
shortcoming somewhere? Otherwise it may need to wait until 4.2 is out.

Jan

> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Wed Apr 25 11:35:29 2012 -0700
> +++ b/xen/arch/x86/domctl.c	Wed Apr 25 11:35:43 2012 -0700
> @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
>          c.nat->user_regs.es = sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs = sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base = sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs = sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +        {
> +            c.nat->gs_base_kernel = sreg.base;
> +            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
> +        }
> +        else
> +        {
> +            c.nat->gs_base_user = sreg.base;
> +            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
> +        }
> +#endif
>      }
>      else
>      {




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 12:49:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 12:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkbo-00006L-Ua; Fri, 27 Apr 2012 12:49:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SNkbn-00006A-Jt
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 12:49:11 +0000
Received: from [85.158.143.35:22144] by server-3.bemta-4.messagelabs.com id
	19/C8-05853-6C59A9F4; Fri, 27 Apr 2012 12:49:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335530949!13898931!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31159 invoked from network); 27 Apr 2012 12:49:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 12:49:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 13:49:09 +0100
Message-Id: <4F9AB1F90200007800080769@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 13:49:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Aravindh Puthiyaparambil" <aravindh@virtuata.com>
References: <be41f3b599d9bba57281.1335379132@vollum>
	<1f39b9fe704f40f394e0.1335379133@vollum>
In-Reply-To: <1f39b9fe704f40f394e0.1335379133@vollum>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to
 HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.04.12 at 20:38, Aravindh Puthiyaparambil <aravindh@virtuata.com> wrote:
> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()

Given that we're in feature freeze right now - is this actually fixing some
shortcoming somewhere? Otherwise it may need to wait until 4.2 is out.

Jan

> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> 
> diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Wed Apr 25 11:35:29 2012 -0700
> +++ b/xen/arch/x86/domctl.c	Wed Apr 25 11:35:43 2012 -0700
> @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
>          c.nat->user_regs.es = sreg.sel;
>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>          c.nat->user_regs.fs = sreg.sel;
> +#ifdef __x86_64__
> +        c.nat->fs_base = sreg.base;
> +#endif
>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>          c.nat->user_regs.gs = sreg.sel;
> +#ifdef __x86_64__
> +        if ( ring_0(&c.nat->user_regs) )
> +        {
> +            c.nat->gs_base_kernel = sreg.base;
> +            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
> +        }
> +        else
> +        {
> +            c.nat->gs_base_user = sreg.base;
> +            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
> +        }
> +#endif
>      }
>      else
>      {




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 13:10:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 13:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkvx-0000hT-SF; Fri, 27 Apr 2012 13:10:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNkvw-0000hK-Rh
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 13:10:01 +0000
Received: from [85.158.138.51:39239] by server-5.bemta-3.messagelabs.com id
	0E/E9-17113-7AA9A9F4; Fri, 27 Apr 2012 13:09:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335532198!15192634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1540 invoked from network); 27 Apr 2012 13:09:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 13:09:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12178048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 13:09:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 14:09:58 +0100
Message-ID: <1335532197.28015.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 27 Apr 2012 14:09:57 +0100
In-Reply-To: <4F9AB141020000780008075D@nat28.tlf.novell.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
	<1335527893.28015.191.camel@zakaz.uk.xensource.com>
	<4F9AB141020000780008075D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 13:46 +0100, Jan Beulich wrote:
> >>> On 27.04.12 at 13:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
> >> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
> >> >> From: David Vrabel <david.vrabel@citrix.com>
> >> >> 
> >> >> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> >> >> called even if no events were pending.
> >> > 
> >> > In actual fact it seems that the callback was actually being called if
> >> > and only if no events were pending? Which makes me wonder how it used to
> >> > work at all!
> >> > 
> >> >> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> >> >> index 79d7362..3e45aa0 100644
> >> >> --- a/arch/x86/xen/xen-asm.S
> >> >> +++ b/arch/x86/xen/xen-asm.S
> >> >> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
> >> >>  
> >> >>  	/* check for unmasked and pending */
> >> >>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> >> >> -	jz 1f
> >> >> +	jnz 1f
> >> >>  2:	call check_events
> >> >>  1:
> >> > 
> >> > Took me a while, this is a bit tricksy (and it may well be too early for
> >> > me to be decoding it) since the check here is trying to check both
> >> > pending and masked in a single cmpw, but I think this is correct. It
> >> > will call check_events now only when the combined mask+pending word is
> >> > 0x0001 (aka unmasked, pending).
> >> 
> >> It is _too much_ trickery, as it implies that the pending field, when set,
> >> will always be 1. This is not sanctioned by the specification (quoting
> >> the hypervisor's xen/include/public/xen.h):
> >> 
> >>      * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
> >>      * a pending notification for a particular VCPU. It is then cleared 
> >>      * by the guest OS /before/ checking for pending work, thus avoiding
> >> 
> >> Note that it says "non-zero", not "1".
> > 
> > Hrm, has it ever not been 1 in practice?
> 
> I don't think so.
> 
> > i.e. could we legitimately tighten the spec?
> 
> I wouldn't want to recommend this. In particular, we can't all of the
> sudden keep guests from storing other non-zero values in here.

Could they be doing this? Whatever they put there is going to get
clobbered by Xen whenever it injects an event, isn't it? Or do you mean
that a guest can force an upcall by writing non-zero itself? Do guests
actually do that? (why?)

> While I'm not in favor of this either, what we could do is specify that
> Xen will only ever write 0 or 1 in here, while other non-zero values
> are okay to be used by guests.

Does Xen ever clear an upcall, isn't that always the guest? Xen only
ever writes 1, at least as far as I can see...

What do you think of the following?

diff -r 107285938c50 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/include/public/xen.h	Fri Apr 27 14:09:00 2012 +0100
@@ -559,16 +559,18 @@ typedef struct vcpu_time_info vcpu_time_
 
 struct vcpu_info {
     /*
-     * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
-     * a pending notification for a particular VCPU. It is then cleared 
-     * by the guest OS /before/ checking for pending work, thus avoiding
-     * a set-and-check race. Note that the mask is only accessed by Xen
-     * on the CPU that is currently hosting the VCPU. This means that the
-     * pending and mask flags can be updated by the guest without special
-     * synchronisation (i.e., no need for the x86 LOCK prefix).
-     * This may seem suboptimal because if the pending flag is set by
-     * a different CPU then an IPI may be scheduled even when the mask
-     * is set. However, note:
+     * 'evtchn_upcall_pending' is written to '1' by Xen to indicate a
+     * pending notification for a particular VCPU. Xen will never
+     * write any other value but it is legitimate for a guest to store
+     * any other non-zero value here to trigger an upcall. It is then
+     * cleared by the guest OS /before/ checking for pending work,
+     * thus avoiding a set-and-check race. Note that the mask is only
+     * accessed by Xen on the CPU that is currently hosting the
+     * VCPU. This means that the pending and mask flags can be updated
+     * by the guest without special synchronisation (i.e., no need for
+     * the x86 LOCK prefix).  This may seem suboptimal because if the
+     * pending flag is set by a different CPU then an IPI may be
+     * scheduled even when the mask is set. However, note:
      *  1. The task of 'interrupt holdoff' is covered by the per-event-
      *     channel mask bits. A 'noisy' event that is continually being
      *     triggered can be masked at source at this very precise



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 13:10:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 13:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNkvx-0000hT-SF; Fri, 27 Apr 2012 13:10:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNkvw-0000hK-Rh
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 13:10:01 +0000
Received: from [85.158.138.51:39239] by server-5.bemta-3.messagelabs.com id
	0E/E9-17113-7AA9A9F4; Fri, 27 Apr 2012 13:09:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1335532198!15192634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1540 invoked from network); 27 Apr 2012 13:09:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 13:09:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12178048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 13:09:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 14:09:58 +0100
Message-ID: <1335532197.28015.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 27 Apr 2012 14:09:57 +0100
In-Reply-To: <4F9AB141020000780008075D@nat28.tlf.novell.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
	<1335527893.28015.191.camel@zakaz.uk.xensource.com>
	<4F9AB141020000780008075D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 13:46 +0100, Jan Beulich wrote:
> >>> On 27.04.12 at 13:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
> >> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Thu, 2012-04-26 at 19:44 +0100, David Vrabel wrote:
> >> >> From: David Vrabel <david.vrabel@citrix.com>
> >> >> 
> >> >> In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
> >> >> called even if no events were pending.
> >> > 
> >> > In actual fact it seems that the callback was actually being called if
> >> > and only if no events were pending? Which makes me wonder how it used to
> >> > work at all!
> >> > 
> >> >> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> >> >> index 79d7362..3e45aa0 100644
> >> >> --- a/arch/x86/xen/xen-asm.S
> >> >> +++ b/arch/x86/xen/xen-asm.S
> >> >> @@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
> >> >>  
> >> >>  	/* check for unmasked and pending */
> >> >>  	cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> >> >> -	jz 1f
> >> >> +	jnz 1f
> >> >>  2:	call check_events
> >> >>  1:
> >> > 
> >> > Took me a while, this is a bit tricksy (and it may well be too early for
> >> > me to be decoding it) since the check here is trying to check both
> >> > pending and masked in a single cmpw, but I think this is correct. It
> >> > will call check_events now only when the combined mask+pending word is
> >> > 0x0001 (aka unmasked, pending).
> >> 
> >> It is _too much_ trickery, as it implies that the pending field, when set,
> >> will always be 1. This is not sanctioned by the specification (quoting
> >> the hypervisor's xen/include/public/xen.h):
> >> 
> >>      * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
> >>      * a pending notification for a particular VCPU. It is then cleared 
> >>      * by the guest OS /before/ checking for pending work, thus avoiding
> >> 
> >> Note that it says "non-zero", not "1".
> > 
> > Hrm, has it ever not been 1 in practice?
> 
> I don't think so.
> 
> > i.e. could we legitimately tighten the spec?
> 
> I wouldn't want to recommend this. In particular, we can't all of the
> sudden keep guests from storing other non-zero values in here.

Could they be doing this? Whatever they put there is going to get
clobbered by Xen whenever it injects an event, isn't it? Or do you mean
that a guest can force an upcall by writing non-zero itself? Do guests
actually do that? (why?)

> While I'm not in favor of this either, what we could do is specify that
> Xen will only ever write 0 or 1 in here, while other non-zero values
> are okay to be used by guests.

Does Xen ever clear an upcall, isn't that always the guest? Xen only
ever writes 1, at least as far as I can see...

What do you think of the following?

diff -r 107285938c50 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Thu Apr 26 10:03:08 2012 +0100
+++ b/xen/include/public/xen.h	Fri Apr 27 14:09:00 2012 +0100
@@ -559,16 +559,18 @@ typedef struct vcpu_time_info vcpu_time_
 
 struct vcpu_info {
     /*
-     * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
-     * a pending notification for a particular VCPU. It is then cleared 
-     * by the guest OS /before/ checking for pending work, thus avoiding
-     * a set-and-check race. Note that the mask is only accessed by Xen
-     * on the CPU that is currently hosting the VCPU. This means that the
-     * pending and mask flags can be updated by the guest without special
-     * synchronisation (i.e., no need for the x86 LOCK prefix).
-     * This may seem suboptimal because if the pending flag is set by
-     * a different CPU then an IPI may be scheduled even when the mask
-     * is set. However, note:
+     * 'evtchn_upcall_pending' is written to '1' by Xen to indicate a
+     * pending notification for a particular VCPU. Xen will never
+     * write any other value but it is legitimate for a guest to store
+     * any other non-zero value here to trigger an upcall. It is then
+     * cleared by the guest OS /before/ checking for pending work,
+     * thus avoiding a set-and-check race. Note that the mask is only
+     * accessed by Xen on the CPU that is currently hosting the
+     * VCPU. This means that the pending and mask flags can be updated
+     * by the guest without special synchronisation (i.e., no need for
+     * the x86 LOCK prefix).  This may seem suboptimal because if the
+     * pending flag is set by a different CPU then an IPI may be
+     * scheduled even when the mask is set. However, note:
      *  1. The task of 'interrupt holdoff' is covered by the per-event-
      *     channel mask bits. A 'noisy' event that is continually being
      *     triggered can be masked at source at this very precise



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 13:20:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 13:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNl5F-0000sz-0m; Fri, 27 Apr 2012 13:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNl5E-0000su-3Z
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 13:19:36 +0000
Received: from [85.158.143.35:25996] by server-1.bemta-4.messagelabs.com id
	6A/FC-20925-7EC9A9F4; Fri, 27 Apr 2012 13:19:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335532774!14298738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10865 invoked from network); 27 Apr 2012 13:19:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 13:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12178246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 13:19:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 14:19:33 +0100
Message-ID: <1335532771.28015.209.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 27 Apr 2012 14:19:31 +0100
In-Reply-To: <1335528921825-5670111.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote:
> About second issue apllying patch seem solved.
> About first also with this change:
> 
> vi Config.mk
> PYTHON_PREFIX_ARG = --install-layout=deb
> 
> not work, show different error:
> Parsing config file /etc/xen/lucid.cfg
> libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
> -3
> 
> pygrub /mnt/vm/disks/lucid.disk1.xm 
> Traceback (most recent call last):
>   File "/usr/bin/pygrub", line 822, in <module>
>     raise RuntimeError, "Unable to find partition containing kernel"
> RuntimeError: Unable to find partition containing kernel

Have you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that
would cause these sorts of failures.

There is no partition table in lucid.disk1.xm, right? I don't use the
split partition scheme myself so I don't know what state it is in.

What sort of filesystem is on lucid.disk1.xm?

Looking at the history of pygrub I don't see anything of interest which
might potentially have broken it (other than the above libfsimage
issue), changes have been rather few lately. Do you know when it last
worked? If so then doing a bisect (just running pygrub, not booting
guests) might be helpful.

Ian.

> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 13:20:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 13:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNl5F-0000sz-0m; Fri, 27 Apr 2012 13:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNl5E-0000su-3Z
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 13:19:36 +0000
Received: from [85.158.143.35:25996] by server-1.bemta-4.messagelabs.com id
	6A/FC-20925-7EC9A9F4; Fri, 27 Apr 2012 13:19:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1335532774!14298738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10865 invoked from network); 27 Apr 2012 13:19:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 13:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12178246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 13:19:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 14:19:33 +0100
Message-ID: <1335532771.28015.209.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 27 Apr 2012 14:19:31 +0100
In-Reply-To: <1335528921825-5670111.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote:
> About second issue apllying patch seem solved.
> About first also with this change:
> 
> vi Config.mk
> PYTHON_PREFIX_ARG = --install-layout=deb
> 
> not work, show different error:
> Parsing config file /etc/xen/lucid.cfg
> libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
> -3
> 
> pygrub /mnt/vm/disks/lucid.disk1.xm 
> Traceback (most recent call last):
>   File "/usr/bin/pygrub", line 822, in <module>
>     raise RuntimeError, "Unable to find partition containing kernel"
> RuntimeError: Unable to find partition containing kernel

Have you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that
would cause these sorts of failures.

There is no partition table in lucid.disk1.xm, right? I don't use the
split partition scheme myself so I don't know what state it is in.

What sort of filesystem is on lucid.disk1.xm?

Looking at the history of pygrub I don't see anything of interest which
might potentially have broken it (other than the above libfsimage
issue), changes have been rather few lately. Do you know when it last
worked? If so then doing a bisect (just running pygrub, not booting
guests) might be helpful.

Ian.

> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 13:51:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 13:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNlZz-0001BB-S0; Fri, 27 Apr 2012 13:51:23 +0000
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 1SNlZy-0001B6-Dp
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 13:51:22 +0000
Received: from [193.109.254.147:19669] by server-9.bemta-14.messagelabs.com id
	92/1F-05787-954AA9F4; Fri, 27 Apr 2012 13:51:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335534676!6641877!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19893 invoked from network); 27 Apr 2012 13:51:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 13:51:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 14:51:15 +0100
Message-Id: <4F9AC08702000078000807B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 14:51:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
	<1335527893.28015.191.camel@zakaz.uk.xensource.com>
	<4F9AB141020000780008075D@nat28.tlf.novell.com>
	<1335532197.28015.205.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335532197.28015.205.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 15:09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-27 at 13:46 +0100, Jan Beulich wrote:
>> >>> On 27.04.12 at 13:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
>> >> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > Hrm, has it ever not been 1 in practice?
>> 
>> I don't think so.
>> 
>> > i.e. could we legitimately tighten the spec?
>> 
>> I wouldn't want to recommend this. In particular, we can't all of the
>> sudden keep guests from storing other non-zero values in here.
> 
> Could they be doing this? Whatever they put there is going to get
> clobbered by Xen whenever it injects an event, isn't it? Or do you mean
> that a guest can force an upcall by writing non-zero itself? Do guests
> actually do that? (why?)

Yes, there is such a case even in Linux - see unmask_evtchn(). And
tightening an existing spec in ways that affect things we don't
control seems undesirable (and unnecessary here).

>> While I'm not in favor of this either, what we could do is specify that
>> Xen will only ever write 0 or 1 in here, while other non-zero values
>> are okay to be used by guests.
> 
> Does Xen ever clear an upcall, isn't that always the guest? Xen only
> ever writes 1, at least as far as I can see...

Oh, yes, you're right of course.

> What do you think of the following?

Reads okay.

Jan

> --- a/xen/include/public/xen.h	Thu Apr 26 10:03:08 2012 +0100
> +++ b/xen/include/public/xen.h	Fri Apr 27 14:09:00 2012 +0100
> @@ -559,16 +559,18 @@ typedef struct vcpu_time_info vcpu_time_
>  
>  struct vcpu_info {
>      /*
> -     * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
> -     * a pending notification for a particular VCPU. It is then cleared 
> -     * by the guest OS /before/ checking for pending work, thus avoiding
> -     * a set-and-check race. Note that the mask is only accessed by Xen
> -     * on the CPU that is currently hosting the VCPU. This means that the
> -     * pending and mask flags can be updated by the guest without special
> -     * synchronisation (i.e., no need for the x86 LOCK prefix).
> -     * This may seem suboptimal because if the pending flag is set by
> -     * a different CPU then an IPI may be scheduled even when the mask
> -     * is set. However, note:
> +     * 'evtchn_upcall_pending' is written to '1' by Xen to indicate a
> +     * pending notification for a particular VCPU. Xen will never
> +     * write any other value but it is legitimate for a guest to store
> +     * any other non-zero value here to trigger an upcall. It is then
> +     * cleared by the guest OS /before/ checking for pending work,
> +     * thus avoiding a set-and-check race. Note that the mask is only
> +     * accessed by Xen on the CPU that is currently hosting the
> +     * VCPU. This means that the pending and mask flags can be updated
> +     * by the guest without special synchronisation (i.e., no need for
> +     * the x86 LOCK prefix).  This may seem suboptimal because if the
> +     * pending flag is set by a different CPU then an IPI may be
> +     * scheduled even when the mask is set. However, note:
>       *  1. The task of 'interrupt holdoff' is covered by the per-event-
>       *     channel mask bits. A 'noisy' event that is continually being
>       *     triggered can be masked at source at this very precise




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 13:51:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 13:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNlZz-0001BB-S0; Fri, 27 Apr 2012 13:51:23 +0000
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 1SNlZy-0001B6-Dp
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 13:51:22 +0000
Received: from [193.109.254.147:19669] by server-9.bemta-14.messagelabs.com id
	92/1F-05787-954AA9F4; Fri, 27 Apr 2012 13:51:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335534676!6641877!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19893 invoked from network); 27 Apr 2012 13:51:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Apr 2012 13:51:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 27 Apr 2012 14:51:15 +0100
Message-Id: <4F9AC08702000078000807B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 27 Apr 2012 14:51:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1335465846-22229-1-git-send-email-david.vrabel@citrix.com>
	<1335516436.28015.169.camel@zakaz.uk.xensource.com>
	<4F9AA23102000078000806DA@nat28.tlf.novell.com>
	<1335527893.28015.191.camel@zakaz.uk.xensource.com>
	<4F9AB141020000780008075D@nat28.tlf.novell.com>
	<1335532197.28015.205.camel@zakaz.uk.xensource.com>
In-Reply-To: <1335532197.28015.205.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: correctly check for pending events
 when restoring irq flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.04.12 at 15:09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-04-27 at 13:46 +0100, Jan Beulich wrote:
>> >>> On 27.04.12 at 13:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2012-04-27 at 12:42 +0100, Jan Beulich wrote:
>> >> >>> On 27.04.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > Hrm, has it ever not been 1 in practice?
>> 
>> I don't think so.
>> 
>> > i.e. could we legitimately tighten the spec?
>> 
>> I wouldn't want to recommend this. In particular, we can't all of the
>> sudden keep guests from storing other non-zero values in here.
> 
> Could they be doing this? Whatever they put there is going to get
> clobbered by Xen whenever it injects an event, isn't it? Or do you mean
> that a guest can force an upcall by writing non-zero itself? Do guests
> actually do that? (why?)

Yes, there is such a case even in Linux - see unmask_evtchn(). And
tightening an existing spec in ways that affect things we don't
control seems undesirable (and unnecessary here).

>> While I'm not in favor of this either, what we could do is specify that
>> Xen will only ever write 0 or 1 in here, while other non-zero values
>> are okay to be used by guests.
> 
> Does Xen ever clear an upcall, isn't that always the guest? Xen only
> ever writes 1, at least as far as I can see...

Oh, yes, you're right of course.

> What do you think of the following?

Reads okay.

Jan

> --- a/xen/include/public/xen.h	Thu Apr 26 10:03:08 2012 +0100
> +++ b/xen/include/public/xen.h	Fri Apr 27 14:09:00 2012 +0100
> @@ -559,16 +559,18 @@ typedef struct vcpu_time_info vcpu_time_
>  
>  struct vcpu_info {
>      /*
> -     * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
> -     * a pending notification for a particular VCPU. It is then cleared 
> -     * by the guest OS /before/ checking for pending work, thus avoiding
> -     * a set-and-check race. Note that the mask is only accessed by Xen
> -     * on the CPU that is currently hosting the VCPU. This means that the
> -     * pending and mask flags can be updated by the guest without special
> -     * synchronisation (i.e., no need for the x86 LOCK prefix).
> -     * This may seem suboptimal because if the pending flag is set by
> -     * a different CPU then an IPI may be scheduled even when the mask
> -     * is set. However, note:
> +     * 'evtchn_upcall_pending' is written to '1' by Xen to indicate a
> +     * pending notification for a particular VCPU. Xen will never
> +     * write any other value but it is legitimate for a guest to store
> +     * any other non-zero value here to trigger an upcall. It is then
> +     * cleared by the guest OS /before/ checking for pending work,
> +     * thus avoiding a set-and-check race. Note that the mask is only
> +     * accessed by Xen on the CPU that is currently hosting the
> +     * VCPU. This means that the pending and mask flags can be updated
> +     * by the guest without special synchronisation (i.e., no need for
> +     * the x86 LOCK prefix).  This may seem suboptimal because if the
> +     * pending flag is set by a different CPU then an IPI may be
> +     * scheduled even when the mask is set. However, note:
>       *  1. The task of 'interrupt holdoff' is covered by the per-event-
>       *     channel mask bits. A 'noisy' event that is continually being
>       *     triggered can be masked at source at this very precise




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNlzU-0001kp-0a; Fri, 27 Apr 2012 14:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNlzR-0001ki-Io
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:17:41 +0000
Received: from [85.158.143.35:22313] by server-2.bemta-4.messagelabs.com id
	3F/0A-17550-48AAA9F4; Fri, 27 Apr 2012 14:17:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335536259!14232556!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAyMTcyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10900 invoked from network); 27 Apr 2012 14:17:39 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-10.tower-21.messagelabs.com with SMTP;
	27 Apr 2012 14:17:39 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8176C604079;
	Fri, 27 Apr 2012 07:17:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=pFBrfQ+OR+uOmDvUyGOOqypCKQr2q4jjQsEGL/R1UK0I
	i57N48LuZkCD+FYwS8Yk9b32pWSY+E4Z+P+iFkB/jJ50gizhdm0DCQYyn7Jz2qyL
	y0noA+tb+jhf5h+TwJWzIryXeJal3zE0Adhgp7uZ2B59IshIigIBNnEs1OQpiL4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=TPTHN4dRUJs49z3+4G3eOLC3Gw4=; b=Ly5gbMvj
	TgU7Ew6FHEdgcRYIERKP9xvlWrda5noUHZSl59o2PJMWQB5pjVIfo6dlQ2QkX6dK
	zlg8hWbGsIvI0ctDO0tGj707WM6gAlMjeShUsYfzTfXcda/2fT/YK67QtTHPq4Rq
	4ehR/VrZWofUdIkaSNBRpJxpMFV/5/zlLyo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 0B8B0604078; 
	Fri, 27 Apr 2012 07:17:37 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 27 Apr 2012 07:17:38 -0700
Message-ID: <f4e47a5963602c92042cd2800499801c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120427092645.GC86045@ocelot.phlegethon.org>
References: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
	<20120427092645.GC86045@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 07:17:38 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 20:02 -0700 on 26 Apr (1335470547), Andres Lagar-Cavilla wrote:
>> > Can you please try the attached patch?  I think you'll need this one
>> > plus the ones that take the locks out of the hpet code.
>>
>> Right off the bat I'm getting a multitude of
>> (XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
>> And a hung dom0 during initramfs. I'm a little baffled as to why, but
>> it's
>> there (32 bit dom0, XenServer6).
>
> Curses, I knew there'd be one somewhere.  I've been replacing
> get_page_and_type_from_pagenr()s (which return 0 for success) with
> old-school get_page_type()s (which return 1 for success) and not always
> getting the right number of inversions.  That's a horrible horrible
> beartrap of an API, BTW, which had me cursing at the screen, but I had
> enough on my plate yesterday without touching _that_ code too!

Found more bugs. Some were predating this (xsm not calling put_gfn after
get_gfn_untyped, etc). Some were new (get_gfn_untyped not arch
independent).

I will be sending you shortly a small patch series on top of your mosnter
patch purely for RFC. Feel free to merge all, pick out bug fixes, etc.

Andres
>
>> > Andres, this is basically the big-hammer version of your "take a
>> > pagecount" changes, plus the change you made to hvmemul_rep_movs().
>> > If this works I intend to follow it up with a patch to make some of
>> the
>> > read-modify-write paths avoid taking the lock (by using a
>> > compare-exchange operation so they only take the lock on a write).  If
>> > that succeeds I might drop put_gfn() altogether.
>>
>> You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
>> There are code paths that do get_gfn_query -> p2m_change_type ->
>> put_gfn.
>> But I guess those could lock the p2m up-front if they become the only
>> consumers of put_gfn left.
>
> Well, that's more or less what happens now.  I was thinking of replacing
> any remaining
>
>  (implicit) lock ; read ; think a bit ; maybe write ; unlock
>
> code with the fast-path-friendlier:
>
>  read ; think ; maybe-cmpxchg (and on failure undo or retry
>
> which avoids taking the write lock altogether if there's no work to do.
> But maybe there aren't many of those left now.  Obviously any path
> which will always write should just take the write-lock first.
>
>> >  - grant-table operations still use the lock, because frankly I
>> >    could not follow the current code, and it's quite late in the
>> evening.
>>
>> It's pretty complex with serious nesting, and ifdef's for arm and 32
>> bit.
>> gfn_to_mfn_private callers will suffer from altering the current
>> meaning,
>> as put_gfn resolves to the right thing for the ifdef'ed arch. The other
>> user is grant_transfer which also relies on the page *not* having an
>> extra
>> ref in steal_page. So it's a prime candidate to be left alone.
>
> Sadly, I think it's not.  The PV backends will be doing lots of grant
> ops, which shouldn't get serialized against all other P2M lookups.
>
>> > I also have a long list of uglinesses in the mm code that I found
>>
>> Uh, ugly stuff, how could that have happened?
>
> I can't imagine. :)  Certainly nothing to do with me thinking "I'll
> clean that up when I get some time."
>
>> I have a few preliminary observations on the patch. Pasting relevant
>> bits
>> here, since the body of the patch seems to have been lost by the email
>> thread:
>>
>> @@ -977,23 +976,25 @@ int arch_set_info_guest(
>> ...
>> +
>> +        if (!paging_mode_refcounts(d)
>> +            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
>> replace with && !get_page_type() )
>
> Yep.
>
>> @@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
>>              gfn = addr >> PAGE_SHIFT;
>>          }
>>
>> -        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
>> +        page = get_page_from_gfn(curr->domain, gfn, &p2mt,
>> P2M_UNSHARE);
>> replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
>> same logic when checking p2m_is_shared). Not truly related to your patch
>> bit since we're at it.
>
> OK, but not in this patch.
>
>> Same, further down
>> -        if ( !p2m_is_ram(p2mt) )
>> +        if ( !page )
>>          {
>> -            put_gfn(curr->domain, gfn);
>> +            if ( page )
>> +                put_page(page);
>> Last two lines are redundant
>
> Yep.
>
>> @@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
>>     case HVMOP_modified_memory: a lot of error checking has been
>> removed.
>
> Yes, but it was bogus - there's a race between the actual modification
> and the call, during which anything might have happened.  The best we
> can do is throw log-dirty bits at everything, and the caller can't do
> anything with the error anyway.
>
> When I come to tidy up I'll just add a new mark_gfn_dirty function
> and skip the pointless gfn->mfn->gfn translation on this path.
>
>> arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing
>> checking
>> for target gfns of mmu updates of l2/3/4 entries. It seems that this
>> wouldn't work anyways, that's why you killed it?
>
> Yeah - since only L1es can point at foreign mappings it was all just
> noise, and even if there had been real p2m lookups on those paths there
> was no equivalent to the translate-in-place that happens in
> mod_l1_entry so it would have been broken in a much worse way.
>
>> +++ b/xen/arch/x86/mm/hap/guest_walk.c
>> @@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>> ...
>> +    if ( !top_page )
>>      {
>>          pfec[0] &= ~PFEC_page_present;
>> -        __put_gfn(p2m, top_gfn);
>> +        put_page(top_page);
>> top_page is NULL here, remove put_page
>
> Yep.
>
>> get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
>> locking is already done by get_gfn_type_access/__put_gfn
>
> Yeah, but I was writing that with half an eye on killing that lock. :)
> I'll drop them for now.
>
>> (hope those observations made sense without inlining them in the actual
>> patch)
>
> Yes, absolutely - thanks for the review!
>
> If we can get this to work well enough I'll tidy it up into a sensible
> series next week.   In the meantime, an updated verison of the
> monster patch is attached.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNlzU-0001kp-0a; Fri, 27 Apr 2012 14:17:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNlzR-0001ki-Io
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:17:41 +0000
Received: from [85.158.143.35:22313] by server-2.bemta-4.messagelabs.com id
	3F/0A-17550-48AAA9F4; Fri, 27 Apr 2012 14:17:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1335536259!14232556!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAyMTcyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10900 invoked from network); 27 Apr 2012 14:17:39 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-10.tower-21.messagelabs.com with SMTP;
	27 Apr 2012 14:17:39 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8176C604079;
	Fri, 27 Apr 2012 07:17:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=pFBrfQ+OR+uOmDvUyGOOqypCKQr2q4jjQsEGL/R1UK0I
	i57N48LuZkCD+FYwS8Yk9b32pWSY+E4Z+P+iFkB/jJ50gizhdm0DCQYyn7Jz2qyL
	y0noA+tb+jhf5h+TwJWzIryXeJal3zE0Adhgp7uZ2B59IshIigIBNnEs1OQpiL4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=TPTHN4dRUJs49z3+4G3eOLC3Gw4=; b=Ly5gbMvj
	TgU7Ew6FHEdgcRYIERKP9xvlWrda5noUHZSl59o2PJMWQB5pjVIfo6dlQ2QkX6dK
	zlg8hWbGsIvI0ctDO0tGj707WM6gAlMjeShUsYfzTfXcda/2fT/YK67QtTHPq4Rq
	4ehR/VrZWofUdIkaSNBRpJxpMFV/5/zlLyo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 0B8B0604078; 
	Fri, 27 Apr 2012 07:17:37 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 27 Apr 2012 07:17:38 -0700
Message-ID: <f4e47a5963602c92042cd2800499801c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120427092645.GC86045@ocelot.phlegethon.org>
References: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
	<20120427092645.GC86045@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 07:17:38 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 20:02 -0700 on 26 Apr (1335470547), Andres Lagar-Cavilla wrote:
>> > Can you please try the attached patch?  I think you'll need this one
>> > plus the ones that take the locks out of the hpet code.
>>
>> Right off the bat I'm getting a multitude of
>> (XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
>> And a hung dom0 during initramfs. I'm a little baffled as to why, but
>> it's
>> there (32 bit dom0, XenServer6).
>
> Curses, I knew there'd be one somewhere.  I've been replacing
> get_page_and_type_from_pagenr()s (which return 0 for success) with
> old-school get_page_type()s (which return 1 for success) and not always
> getting the right number of inversions.  That's a horrible horrible
> beartrap of an API, BTW, which had me cursing at the screen, but I had
> enough on my plate yesterday without touching _that_ code too!

Found more bugs. Some were predating this (xsm not calling put_gfn after
get_gfn_untyped, etc). Some were new (get_gfn_untyped not arch
independent).

I will be sending you shortly a small patch series on top of your mosnter
patch purely for RFC. Feel free to merge all, pick out bug fixes, etc.

Andres
>
>> > Andres, this is basically the big-hammer version of your "take a
>> > pagecount" changes, plus the change you made to hvmemul_rep_movs().
>> > If this works I intend to follow it up with a patch to make some of
>> the
>> > read-modify-write paths avoid taking the lock (by using a
>> > compare-exchange operation so they only take the lock on a write).  If
>> > that succeeds I might drop put_gfn() altogether.
>>
>> You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
>> There are code paths that do get_gfn_query -> p2m_change_type ->
>> put_gfn.
>> But I guess those could lock the p2m up-front if they become the only
>> consumers of put_gfn left.
>
> Well, that's more or less what happens now.  I was thinking of replacing
> any remaining
>
>  (implicit) lock ; read ; think a bit ; maybe write ; unlock
>
> code with the fast-path-friendlier:
>
>  read ; think ; maybe-cmpxchg (and on failure undo or retry
>
> which avoids taking the write lock altogether if there's no work to do.
> But maybe there aren't many of those left now.  Obviously any path
> which will always write should just take the write-lock first.
>
>> >  - grant-table operations still use the lock, because frankly I
>> >    could not follow the current code, and it's quite late in the
>> evening.
>>
>> It's pretty complex with serious nesting, and ifdef's for arm and 32
>> bit.
>> gfn_to_mfn_private callers will suffer from altering the current
>> meaning,
>> as put_gfn resolves to the right thing for the ifdef'ed arch. The other
>> user is grant_transfer which also relies on the page *not* having an
>> extra
>> ref in steal_page. So it's a prime candidate to be left alone.
>
> Sadly, I think it's not.  The PV backends will be doing lots of grant
> ops, which shouldn't get serialized against all other P2M lookups.
>
>> > I also have a long list of uglinesses in the mm code that I found
>>
>> Uh, ugly stuff, how could that have happened?
>
> I can't imagine. :)  Certainly nothing to do with me thinking "I'll
> clean that up when I get some time."
>
>> I have a few preliminary observations on the patch. Pasting relevant
>> bits
>> here, since the body of the patch seems to have been lost by the email
>> thread:
>>
>> @@ -977,23 +976,25 @@ int arch_set_info_guest(
>> ...
>> +
>> +        if (!paging_mode_refcounts(d)
>> +            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
>> replace with && !get_page_type() )
>
> Yep.
>
>> @@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
>>              gfn = addr >> PAGE_SHIFT;
>>          }
>>
>> -        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
>> +        page = get_page_from_gfn(curr->domain, gfn, &p2mt,
>> P2M_UNSHARE);
>> replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
>> same logic when checking p2m_is_shared). Not truly related to your patch
>> bit since we're at it.
>
> OK, but not in this patch.
>
>> Same, further down
>> -        if ( !p2m_is_ram(p2mt) )
>> +        if ( !page )
>>          {
>> -            put_gfn(curr->domain, gfn);
>> +            if ( page )
>> +                put_page(page);
>> Last two lines are redundant
>
> Yep.
>
>> @@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
>>     case HVMOP_modified_memory: a lot of error checking has been
>> removed.
>
> Yes, but it was bogus - there's a race between the actual modification
> and the call, during which anything might have happened.  The best we
> can do is throw log-dirty bits at everything, and the caller can't do
> anything with the error anyway.
>
> When I come to tidy up I'll just add a new mark_gfn_dirty function
> and skip the pointless gfn->mfn->gfn translation on this path.
>
>> arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing
>> checking
>> for target gfns of mmu updates of l2/3/4 entries. It seems that this
>> wouldn't work anyways, that's why you killed it?
>
> Yeah - since only L1es can point at foreign mappings it was all just
> noise, and even if there had been real p2m lookups on those paths there
> was no equivalent to the translate-in-place that happens in
> mod_l1_entry so it would have been broken in a much worse way.
>
>> +++ b/xen/arch/x86/mm/hap/guest_walk.c
>> @@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>> ...
>> +    if ( !top_page )
>>      {
>>          pfec[0] &= ~PFEC_page_present;
>> -        __put_gfn(p2m, top_gfn);
>> +        put_page(top_page);
>> top_page is NULL here, remove put_page
>
> Yep.
>
>> get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
>> locking is already done by get_gfn_type_access/__put_gfn
>
> Yeah, but I was writing that with half an eye on killing that lock. :)
> I'll drop them for now.
>
>> (hope those observations made sense without inlining them in the actual
>> patch)
>
> Yes, absolutely - thanks for the review!
>
> If we can get this to work well enough I'll tidy it up into a sensible
> series next week.   In the meantime, an updated verison of the
> monster patch is attached.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:28:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:28:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNm9K-00020C-9y; Fri, 27 Apr 2012 14:27:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNm9J-000207-Fl
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:27:53 +0000
Received: from [85.158.139.83:23483] by server-11.bemta-5.messagelabs.com id
	52/58-12959-8ECAA9F4; Fri, 27 Apr 2012 14:27:52 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335536870!21868607!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2692 invoked from network); 27 Apr 2012 14:27:51 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 14:27:51 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNm9F-0002qH-Uh
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 07:27:49 -0700
Date: Fri, 27 Apr 2012 07:27:49 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335536869945-5670447.post@n5.nabble.com>
In-Reply-To: <1335532771.28015.209.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
> On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote:
>> About second issue apllying patch seem solved.
>> About first also with this change:
>> 
>> vi Config.mk
>> PYTHON_PREFIX_ARG = --install-layout=deb
>> 
>> not work, show different error:
>> Parsing config file /etc/xen/lucid.cfg
>> libxl: error: libxl_create.c:603:do_domain_create: failed to run
>> bootloader:
>> -3
>> 
>> pygrub /mnt/vm/disks/lucid.disk1.xm 
>> Traceback (most recent call last):
>>   File "/usr/bin/pygrub", line 822, in <module>
>>     raise RuntimeError, "Unable to find partition containing kernel"
>> RuntimeError: Unable to find partition containing kernel
> 
> Have you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that
> would cause these sorts of failures.
> 
> There is no partition table in lucid.disk1.xm, right? I don't use the
> split partition scheme myself so I don't know what state it is in.
> 
> What sort of filesystem is on lucid.disk1.xm?
> 
> Looking at the history of pygrub I don't see anything of interest which
> might potentially have broken it (other than the above libfsimage
> issue), changes have been rather few lately. Do you know when it last
> worked? If so then doing a bisect (just running pygrub, not booting
> guests) might be helpful.
> 
> Ian.
> 
>> 
>> 
>> --
>> View this message in context:
>> http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 

Lucid disk1 is ext4 partition, on old xen-unstable test build was working,
also without change of python prefix, monday I retry with full clean build
and also to latest changeset

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670447.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:28:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:28:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNm9K-00020C-9y; Fri, 27 Apr 2012 14:27:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNm9J-000207-Fl
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:27:53 +0000
Received: from [85.158.139.83:23483] by server-11.bemta-5.messagelabs.com id
	52/58-12959-8ECAA9F4; Fri, 27 Apr 2012 14:27:52 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1335536870!21868607!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2692 invoked from network); 27 Apr 2012 14:27:51 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Apr 2012 14:27:51 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SNm9F-0002qH-Uh
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 07:27:49 -0700
Date: Fri, 27 Apr 2012 07:27:49 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335536869945-5670447.post@n5.nabble.com>
In-Reply-To: <1335532771.28015.209.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
> On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote:
>> About second issue apllying patch seem solved.
>> About first also with this change:
>> 
>> vi Config.mk
>> PYTHON_PREFIX_ARG = --install-layout=deb
>> 
>> not work, show different error:
>> Parsing config file /etc/xen/lucid.cfg
>> libxl: error: libxl_create.c:603:do_domain_create: failed to run
>> bootloader:
>> -3
>> 
>> pygrub /mnt/vm/disks/lucid.disk1.xm 
>> Traceback (most recent call last):
>>   File "/usr/bin/pygrub", line 822, in <module>
>>     raise RuntimeError, "Unable to find partition containing kernel"
>> RuntimeError: Unable to find partition containing kernel
> 
> Have you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that
> would cause these sorts of failures.
> 
> There is no partition table in lucid.disk1.xm, right? I don't use the
> split partition scheme myself so I don't know what state it is in.
> 
> What sort of filesystem is on lucid.disk1.xm?
> 
> Looking at the history of pygrub I don't see anything of interest which
> might potentially have broken it (other than the above libfsimage
> issue), changes have been rather few lately. Do you know when it last
> worked? If so then doing a bisect (just running pygrub, not booting
> guests) might be helpful.
> 
> Ian.
> 
>> 
>> 
>> --
>> View this message in context:
>> http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 

Lucid disk1 is ext4 partition, on old xen-unstable test build was working,
also without change of python prefix, monday I retry with full clean build
and also to latest changeset

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670447.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:31:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmC9-00025i-VH; Fri, 27 Apr 2012 14:30:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNmC8-00025a-AG
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:30:48 +0000
Received: from [85.158.138.51:11373] by server-8.bemta-3.messagelabs.com id
	3F/87-24428-79DAA9F4; Fri, 27 Apr 2012 14:30:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335537045!24066459!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTcxMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 27 Apr 2012 14:30:45 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-174.messagelabs.com with SMTP;
	27 Apr 2012 14:30:45 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 21F1D714075;
	Fri, 27 Apr 2012 07:30:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Y1Y73+D99FCwy1Sd15a+HftvplITV2dfFAPVqSX/0koV
	IsUh1hSyPPCgZVMS6OC6aEnuK5/smtVxC8qYJCCtVEltAKIl4XpvS7qnXeSWkdoe
	cjmwQczhqny3K4JVCNbgNH/oJhR5fumIuAbOoh56PfVqkiKal5yp5ttlZNG3fSA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=khFT7jjrAdj1CcG2uGzZEtCO3VE=; b=TNs2GdWLsA0
	Wr6LibzJ2yDnvPGZsqVfjiOVK/FdHjgLrldlih3bWkSnCJA2mDambc/8a462giv4
	RdLugBokCyzfnksu1bAlhO+gh7BVmSCdytIAfkUm9u0mOwWq7Gcx7XmHEmGgjghg
	WGm/y5uB3W9EA1Dne0LPrv9ylstIUBAE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 90C2371406A; 
	Fri, 27 Apr 2012 07:30:43 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 42634eca923f4861984d3a6590dce901c7ace9f7
Message-Id: <42634eca923f4861984d.1335537381@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335537380@xdev.gridcentric.ca>
References: <patchbomb.1335537380@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 10:36:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 2] Use get page from gfn also in svm code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/svm/svm.c |  20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)


And clean up some unnecessary uses of get_gfn locked.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 310e84676db3 -r 42634eca923f xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -232,8 +232,7 @@ static int svm_vmcb_save(struct vcpu *v,
 
 static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
 
@@ -250,10 +249,10 @@ static int svm_vmcb_restore(struct vcpu 
     {
         if ( c->cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, c->cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, c->cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n",
                          c->cr3);
                 return -EINVAL;
@@ -263,9 +262,8 @@ static int svm_vmcb_restore(struct vcpu 
         if ( v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( c->cr0 & X86_CR0_PG )
-            put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
+        v->arch.guest_table = 
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = c->cr0 | X86_CR0_ET;
@@ -1321,8 +1319,7 @@ static void svm_do_nested_pgfault(struct
         p2m = p2m_get_p2m(v);
         _d.gpa = gpa;
         _d.qualification = 0;
-        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL);
-        __put_gfn(p2m, gfn);
+        mfn = __get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL, 0);
         _d.mfn = mfn_x(mfn);
         
         __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
@@ -1343,8 +1340,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL);
-    __put_gfn(p2m, gfn);
+    mfn = __get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL, 0);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:31:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmC9-00025i-VH; Fri, 27 Apr 2012 14:30:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNmC8-00025a-AG
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:30:48 +0000
Received: from [85.158.138.51:11373] by server-8.bemta-3.messagelabs.com id
	3F/87-24428-79DAA9F4; Fri, 27 Apr 2012 14:30:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1335537045!24066459!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxOTcxMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 27 Apr 2012 14:30:45 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-174.messagelabs.com with SMTP;
	27 Apr 2012 14:30:45 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 21F1D714075;
	Fri, 27 Apr 2012 07:30:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Y1Y73+D99FCwy1Sd15a+HftvplITV2dfFAPVqSX/0koV
	IsUh1hSyPPCgZVMS6OC6aEnuK5/smtVxC8qYJCCtVEltAKIl4XpvS7qnXeSWkdoe
	cjmwQczhqny3K4JVCNbgNH/oJhR5fumIuAbOoh56PfVqkiKal5yp5ttlZNG3fSA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=khFT7jjrAdj1CcG2uGzZEtCO3VE=; b=TNs2GdWLsA0
	Wr6LibzJ2yDnvPGZsqVfjiOVK/FdHjgLrldlih3bWkSnCJA2mDambc/8a462giv4
	RdLugBokCyzfnksu1bAlhO+gh7BVmSCdytIAfkUm9u0mOwWq7Gcx7XmHEmGgjghg
	WGm/y5uB3W9EA1Dne0LPrv9ylstIUBAE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 90C2371406A; 
	Fri, 27 Apr 2012 07:30:43 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 42634eca923f4861984d3a6590dce901c7ace9f7
Message-Id: <42634eca923f4861984d.1335537381@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335537380@xdev.gridcentric.ca>
References: <patchbomb.1335537380@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 10:36:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 2] Use get page from gfn also in svm code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/svm/svm.c |  20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)


And clean up some unnecessary uses of get_gfn locked.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 310e84676db3 -r 42634eca923f xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -232,8 +232,7 @@ static int svm_vmcb_save(struct vcpu *v,
 
 static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
 
@@ -250,10 +249,10 @@ static int svm_vmcb_restore(struct vcpu 
     {
         if ( c->cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, c->cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, c->cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n",
                          c->cr3);
                 return -EINVAL;
@@ -263,9 +262,8 @@ static int svm_vmcb_restore(struct vcpu 
         if ( v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( c->cr0 & X86_CR0_PG )
-            put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
+        v->arch.guest_table = 
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = c->cr0 | X86_CR0_ET;
@@ -1321,8 +1319,7 @@ static void svm_do_nested_pgfault(struct
         p2m = p2m_get_p2m(v);
         _d.gpa = gpa;
         _d.qualification = 0;
-        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL);
-        __put_gfn(p2m, gfn);
+        mfn = __get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL, 0);
         _d.mfn = mfn_x(mfn);
         
         __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
@@ -1343,8 +1340,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL);
-    __put_gfn(p2m, gfn);
+    mfn = __get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL, 0);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:31:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmCC-00025x-Ah; Fri, 27 Apr 2012 14:30:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNmCB-00025c-0k
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:30:51 +0000
Received: from [85.158.138.51:20502] by server-5.bemta-3.messagelabs.com id
	34/FB-17113-89DAA9F4; Fri, 27 Apr 2012 14:30:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335537045!16223232!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxNjgw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxNjgw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31979 invoked from network); 27 Apr 2012 14:30:46 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-12.tower-174.messagelabs.com with SMTP;
	27 Apr 2012 14:30:46 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id D07E1714085;
	Fri, 27 Apr 2012 07:30:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=gU8+eURIqAvzgw2fqJwMJQs/6WuywTo6Hfvi9Xw6Rs3n
	RwE/MiprzGBC9fYT4C/5iFTC4TJ65r7UMeEn3ST29930luNAUbG6Y6m5OzOiko3m
	dGRqOHruGw0rIAeTpEz+DU4862moCky7pfkSOJRW/rTpONb2yOlUZ7rKzDTeRkU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=2izeqkmnIDmejRCWuRxGiUe2DdQ=; b=kLhuDCKFXkn
	nTucKppulU9VT/ChNDQ3wX7lm0YMv7TUmPq0yBBXC1OXdpFnhMzEmL4A0sn4GeRG
	0ld8zCT4CQpdotjswH0n4scIlm4c2A4Ys4YUzYzTIwNGwXBQp7Mz8nCtfgGxvsVW
	I2SbQT9wQfcXmx8u/bo94PE8efHG3kZ0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 4E6E871406A; 
	Fri, 27 Apr 2012 07:30:44 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a840e45febc25969d5dec14bb2c0fb60c258f6d3
Message-Id: <a840e45febc25969d5de.1335537382@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335537380@xdev.gridcentric.ca>
References: <patchbomb.1335537380@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 10:36:22 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 2] Expand use of get_page_from_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c         |  48 ++++++++++++++++++----------------------------
 xen/common/memory.c       |   9 +++++++-
 xen/common/tmem_xen.c     |  26 +++++++++---------------
 xen/include/asm-x86/p2m.h |  11 ----------
 xen/xsm/flask/hooks.c     |  19 ++++++++++++++---
 5 files changed, 52 insertions(+), 61 deletions(-)


Cover more users in common/memory.c, arch/x86/mm.c, xsm and tmem.

Fix bugs on xsm for get_gfn_untyped and get_page_from_gfn.

Eliminate altogether get_gfn_untyped.

Add appropriate ifdefe'ery in common code so that ARM doesn't whine.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 42634eca923f -r a840e45febc2 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3731,18 +3731,17 @@ static int create_grant_pte_mapping(
     adjust_guest_l1e(nl1e, d);
 
     gmfn = pte_addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)pte_addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3773,7 +3772,6 @@ static int create_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
 
     return rc;
 }
@@ -3788,18 +3786,17 @@ static int destroy_grant_pte_mapping(
     l1_pgentry_t ol1e;
 
     gmfn = addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3844,7 +3841,6 @@ static int destroy_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
     return rc;
 }
 
@@ -4367,11 +4363,12 @@ long set_gdt(struct vcpu *v,
     /* Check the pages in the new GDT. */
     for ( i = 0; i < nr_pages; i++ )
     {
+        struct page_info *page;
         pfns[i] = frames[i];
-        mfn = frames[i] = get_gfn_untyped(d, frames[i]);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
+        page = get_page_from_gfn(d, frames[i], NULL, P2M_ALLOC);
+        if ( !page || !get_page_type(page, PGT_seg_desc_page) )
             goto fail;
+        mfn = frames[i] = page_to_mfn(page);
     }
 
     /* Tear down the old GDT. */
@@ -4384,7 +4381,6 @@ long set_gdt(struct vcpu *v,
         v->arch.pv_vcpu.gdt_frames[i] = frames[i];
         l1e_write(&v->arch.perdomain_ptes[i],
                   l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
-        put_gfn(d, pfns[i]);
     }
 
     xfree(pfns);
@@ -4394,7 +4390,6 @@ long set_gdt(struct vcpu *v,
     while ( i-- > 0 )
     {
         put_page_and_type(mfn_to_page(frames[i]));
-        put_gfn(d, pfns[i]);
     }
     xfree(pfns);
     return -EINVAL;
@@ -4440,21 +4435,16 @@ long do_update_descriptor(u64 pa, u64 de
 
     *(u64 *)&d = desc;
 
-    mfn = get_gfn_untyped(dom, gmfn);
+    page = get_page_from_gfn(dom, gmfn, NULL, P2M_ALLOC);
     if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) ||
-         !mfn_valid(mfn) ||
+         !page ||
          !check_descriptor(dom, &d) )
     {
-        put_gfn(dom, gmfn);
+        if ( page )
+            put_page(page);
         return -EINVAL;
     }
-
-    page = mfn_to_page(mfn);
-    if ( unlikely(!get_page(page, dom)) )
-    {
-        put_gfn(dom, gmfn);
-        return -EINVAL;
-    }
+    mfn = page_to_mfn(page);
 
     /* Check if the given frame is in use in an unsafe context. */
     switch ( page->u.inuse.type_info & PGT_type_mask )
@@ -4482,7 +4472,6 @@ long do_update_descriptor(u64 pa, u64 de
 
  out:
     put_page(page);
-    put_gfn(dom, gmfn);
 
     return ret;
 }
@@ -4529,6 +4518,7 @@ static int xenmem_add_to_physmap_once(
     unsigned long gfn = 0; /* gcc ... */
     unsigned long prev_mfn, mfn = 0, gpfn, idx;
     int rc;
+    p2m_type_t p2mt;
 
     switch ( xatp->space )
     {
@@ -4617,7 +4607,7 @@ static int xenmem_add_to_physmap_once(
         put_page(page);
 
     /* Remove previously mapped page if it was present. */
-    prev_mfn = get_gfn_untyped(d, xatp->gpfn);
+    prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt));
     if ( mfn_valid(prev_mfn) )
     {
         if ( is_xen_heap_mfn(prev_mfn) )
diff -r 42634eca923f -r a840e45febc2 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -694,7 +694,14 @@ long do_memory_op(unsigned long cmd, XEN
 
         domain_lock(d);
 
-        mfn = get_gfn_untyped(d, xrfp.gpfn);
+#ifdef CONFIG_X86
+        {
+            p2m_type_t p2mt;
+            mfn = mfn_x(get_gfn(d, xrfp.gpfn, &p2mt));
+        }
+#else
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+#endif
 
         if ( mfn_valid(mfn) )
             guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
diff -r 42634eca923f -r a840e45febc2 xen/common/tmem_xen.c
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -107,30 +107,25 @@ static inline void cli_put_page(tmem_cli
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
-    unsigned long cli_mfn;
     p2m_type_t t;
     struct page_info *page;
-    int ret;
 
-    cli_mfn = mfn_x(get_gfn(current->domain, cmfn, &t));
-    if ( t != p2m_ram_rw || !mfn_valid(cli_mfn) )
+    page = get_page_from_gfn(current->domain, cmfn, &t, P2M_ALLOC);
+    if ( !page || t != p2m_ram_rw )
     {
-            put_gfn(current->domain, (unsigned long) cmfn);
-            return NULL;
+        if ( page )
+            put_page(page);
     }
-    page = mfn_to_page(cli_mfn);
-    if ( cli_write )
-        ret = get_page_and_type(page, current->domain, PGT_writable_page);
-    else
-        ret = get_page(page, current->domain);
-    if ( !ret )
+
+    if ( cli_write && !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(current->domain, (unsigned long) cmfn);
+        put_page(page);
         return NULL;
     }
-    *pcli_mfn = cli_mfn;
+
+    *pcli_mfn = page_to_mfn(page);
     *pcli_pfp = (pfp_t *)page;
-    return map_domain_page(cli_mfn);
+    return map_domain_page(*pcli_mfn);
 }
 
 static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
@@ -144,7 +139,6 @@ static inline void cli_put_page(tmem_cli
     else
         put_page((struct page_info *)cli_pfp);
     unmap_domain_page(cli_va);
-    put_gfn(current->domain, (unsigned long) cmfn);
 }
 #endif
 
diff -r 42634eca923f -r a840e45febc2 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -342,17 +342,6 @@ static inline mfn_t get_gfn_type(struct 
 #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \
                                               P2M_ALLOC | P2M_UNSHARE)
 
-/* Compatibility function exporting the old untyped interface */
-static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
-{
-    mfn_t mfn;
-    p2m_type_t t;
-    mfn = get_gfn(d, gpfn, &t);
-    if ( p2m_is_valid(t) )
-        return mfn_x(mfn);
-    return INVALID_MFN;
-}
-
 /* Will release the p2m_lock for this gfn entry. */
 void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
diff -r 42634eca923f -r a840e45febc2 xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1318,7 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
-    struct page_info *page;
+    struct page_info *page = NULL;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1334,9 +1334,12 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), NULL, P2M_ALLOC);
     mfn = page ? page_to_mfn(page) : INVALID_MFN;
-
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+#endif
     ad.sdom = d;
     ad.tdom = f;
     ad.memory.pte = fpte;
@@ -1373,6 +1376,7 @@ static int flask_update_va_mapping(struc
     int rc = 0;
     u32 psid;
     u32 map_perms = MMU__MAP_READ;
+    struct page_info *page = NULL;
     unsigned long mfn;
     struct domain_security_struct *dsec;
 
@@ -1384,8 +1388,15 @@ static int flask_update_va_mapping(struc
 
     dsec = d->ssid;
 
-    mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(pte), NULL, P2M_ALLOC);
+    mfn = (page) ? page_to_mfn(page) : INVALID_MFN;
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(pte));
+#endif
     rc = get_mfn_sid(mfn, &psid);
+    if ( page )
+        put_page(page);
     if ( rc )
         return rc;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:31:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmCC-00025x-Ah; Fri, 27 Apr 2012 14:30:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNmCB-00025c-0k
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:30:51 +0000
Received: from [85.158.138.51:20502] by server-5.bemta-3.messagelabs.com id
	34/FB-17113-89DAA9F4; Fri, 27 Apr 2012 14:30:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335537045!16223232!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxNjgw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxNjgw\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31979 invoked from network); 27 Apr 2012 14:30:46 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-12.tower-174.messagelabs.com with SMTP;
	27 Apr 2012 14:30:46 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id D07E1714085;
	Fri, 27 Apr 2012 07:30:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=gU8+eURIqAvzgw2fqJwMJQs/6WuywTo6Hfvi9Xw6Rs3n
	RwE/MiprzGBC9fYT4C/5iFTC4TJ65r7UMeEn3ST29930luNAUbG6Y6m5OzOiko3m
	dGRqOHruGw0rIAeTpEz+DU4862moCky7pfkSOJRW/rTpONb2yOlUZ7rKzDTeRkU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=2izeqkmnIDmejRCWuRxGiUe2DdQ=; b=kLhuDCKFXkn
	nTucKppulU9VT/ChNDQ3wX7lm0YMv7TUmPq0yBBXC1OXdpFnhMzEmL4A0sn4GeRG
	0ld8zCT4CQpdotjswH0n4scIlm4c2A4Ys4YUzYzTIwNGwXBQp7Mz8nCtfgGxvsVW
	I2SbQT9wQfcXmx8u/bo94PE8efHG3kZ0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 4E6E871406A; 
	Fri, 27 Apr 2012 07:30:44 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a840e45febc25969d5dec14bb2c0fb60c258f6d3
Message-Id: <a840e45febc25969d5de.1335537382@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335537380@xdev.gridcentric.ca>
References: <patchbomb.1335537380@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 10:36:22 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 2] Expand use of get_page_from_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c         |  48 ++++++++++++++++++----------------------------
 xen/common/memory.c       |   9 +++++++-
 xen/common/tmem_xen.c     |  26 +++++++++---------------
 xen/include/asm-x86/p2m.h |  11 ----------
 xen/xsm/flask/hooks.c     |  19 ++++++++++++++---
 5 files changed, 52 insertions(+), 61 deletions(-)


Cover more users in common/memory.c, arch/x86/mm.c, xsm and tmem.

Fix bugs on xsm for get_gfn_untyped and get_page_from_gfn.

Eliminate altogether get_gfn_untyped.

Add appropriate ifdefe'ery in common code so that ARM doesn't whine.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 42634eca923f -r a840e45febc2 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3731,18 +3731,17 @@ static int create_grant_pte_mapping(
     adjust_guest_l1e(nl1e, d);
 
     gmfn = pte_addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)pte_addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3773,7 +3772,6 @@ static int create_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
 
     return rc;
 }
@@ -3788,18 +3786,17 @@ static int destroy_grant_pte_mapping(
     l1_pgentry_t ol1e;
 
     gmfn = addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3844,7 +3841,6 @@ static int destroy_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
     return rc;
 }
 
@@ -4367,11 +4363,12 @@ long set_gdt(struct vcpu *v,
     /* Check the pages in the new GDT. */
     for ( i = 0; i < nr_pages; i++ )
     {
+        struct page_info *page;
         pfns[i] = frames[i];
-        mfn = frames[i] = get_gfn_untyped(d, frames[i]);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
+        page = get_page_from_gfn(d, frames[i], NULL, P2M_ALLOC);
+        if ( !page || !get_page_type(page, PGT_seg_desc_page) )
             goto fail;
+        mfn = frames[i] = page_to_mfn(page);
     }
 
     /* Tear down the old GDT. */
@@ -4384,7 +4381,6 @@ long set_gdt(struct vcpu *v,
         v->arch.pv_vcpu.gdt_frames[i] = frames[i];
         l1e_write(&v->arch.perdomain_ptes[i],
                   l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
-        put_gfn(d, pfns[i]);
     }
 
     xfree(pfns);
@@ -4394,7 +4390,6 @@ long set_gdt(struct vcpu *v,
     while ( i-- > 0 )
     {
         put_page_and_type(mfn_to_page(frames[i]));
-        put_gfn(d, pfns[i]);
     }
     xfree(pfns);
     return -EINVAL;
@@ -4440,21 +4435,16 @@ long do_update_descriptor(u64 pa, u64 de
 
     *(u64 *)&d = desc;
 
-    mfn = get_gfn_untyped(dom, gmfn);
+    page = get_page_from_gfn(dom, gmfn, NULL, P2M_ALLOC);
     if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) ||
-         !mfn_valid(mfn) ||
+         !page ||
          !check_descriptor(dom, &d) )
     {
-        put_gfn(dom, gmfn);
+        if ( page )
+            put_page(page);
         return -EINVAL;
     }
-
-    page = mfn_to_page(mfn);
-    if ( unlikely(!get_page(page, dom)) )
-    {
-        put_gfn(dom, gmfn);
-        return -EINVAL;
-    }
+    mfn = page_to_mfn(page);
 
     /* Check if the given frame is in use in an unsafe context. */
     switch ( page->u.inuse.type_info & PGT_type_mask )
@@ -4482,7 +4472,6 @@ long do_update_descriptor(u64 pa, u64 de
 
  out:
     put_page(page);
-    put_gfn(dom, gmfn);
 
     return ret;
 }
@@ -4529,6 +4518,7 @@ static int xenmem_add_to_physmap_once(
     unsigned long gfn = 0; /* gcc ... */
     unsigned long prev_mfn, mfn = 0, gpfn, idx;
     int rc;
+    p2m_type_t p2mt;
 
     switch ( xatp->space )
     {
@@ -4617,7 +4607,7 @@ static int xenmem_add_to_physmap_once(
         put_page(page);
 
     /* Remove previously mapped page if it was present. */
-    prev_mfn = get_gfn_untyped(d, xatp->gpfn);
+    prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt));
     if ( mfn_valid(prev_mfn) )
     {
         if ( is_xen_heap_mfn(prev_mfn) )
diff -r 42634eca923f -r a840e45febc2 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -694,7 +694,14 @@ long do_memory_op(unsigned long cmd, XEN
 
         domain_lock(d);
 
-        mfn = get_gfn_untyped(d, xrfp.gpfn);
+#ifdef CONFIG_X86
+        {
+            p2m_type_t p2mt;
+            mfn = mfn_x(get_gfn(d, xrfp.gpfn, &p2mt));
+        }
+#else
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+#endif
 
         if ( mfn_valid(mfn) )
             guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
diff -r 42634eca923f -r a840e45febc2 xen/common/tmem_xen.c
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -107,30 +107,25 @@ static inline void cli_put_page(tmem_cli
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
-    unsigned long cli_mfn;
     p2m_type_t t;
     struct page_info *page;
-    int ret;
 
-    cli_mfn = mfn_x(get_gfn(current->domain, cmfn, &t));
-    if ( t != p2m_ram_rw || !mfn_valid(cli_mfn) )
+    page = get_page_from_gfn(current->domain, cmfn, &t, P2M_ALLOC);
+    if ( !page || t != p2m_ram_rw )
     {
-            put_gfn(current->domain, (unsigned long) cmfn);
-            return NULL;
+        if ( page )
+            put_page(page);
     }
-    page = mfn_to_page(cli_mfn);
-    if ( cli_write )
-        ret = get_page_and_type(page, current->domain, PGT_writable_page);
-    else
-        ret = get_page(page, current->domain);
-    if ( !ret )
+
+    if ( cli_write && !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(current->domain, (unsigned long) cmfn);
+        put_page(page);
         return NULL;
     }
-    *pcli_mfn = cli_mfn;
+
+    *pcli_mfn = page_to_mfn(page);
     *pcli_pfp = (pfp_t *)page;
-    return map_domain_page(cli_mfn);
+    return map_domain_page(*pcli_mfn);
 }
 
 static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
@@ -144,7 +139,6 @@ static inline void cli_put_page(tmem_cli
     else
         put_page((struct page_info *)cli_pfp);
     unmap_domain_page(cli_va);
-    put_gfn(current->domain, (unsigned long) cmfn);
 }
 #endif
 
diff -r 42634eca923f -r a840e45febc2 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -342,17 +342,6 @@ static inline mfn_t get_gfn_type(struct 
 #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \
                                               P2M_ALLOC | P2M_UNSHARE)
 
-/* Compatibility function exporting the old untyped interface */
-static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
-{
-    mfn_t mfn;
-    p2m_type_t t;
-    mfn = get_gfn(d, gpfn, &t);
-    if ( p2m_is_valid(t) )
-        return mfn_x(mfn);
-    return INVALID_MFN;
-}
-
 /* Will release the p2m_lock for this gfn entry. */
 void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
diff -r 42634eca923f -r a840e45febc2 xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1318,7 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
-    struct page_info *page;
+    struct page_info *page = NULL;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1334,9 +1334,12 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), NULL, P2M_ALLOC);
     mfn = page ? page_to_mfn(page) : INVALID_MFN;
-
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+#endif
     ad.sdom = d;
     ad.tdom = f;
     ad.memory.pte = fpte;
@@ -1373,6 +1376,7 @@ static int flask_update_va_mapping(struc
     int rc = 0;
     u32 psid;
     u32 map_perms = MMU__MAP_READ;
+    struct page_info *page = NULL;
     unsigned long mfn;
     struct domain_security_struct *dsec;
 
@@ -1384,8 +1388,15 @@ static int flask_update_va_mapping(struc
 
     dsec = d->ssid;
 
-    mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(pte), NULL, P2M_ALLOC);
+    mfn = (page) ? page_to_mfn(page) : INVALID_MFN;
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(pte));
+#endif
     rc = get_mfn_sid(mfn, &psid);
+    if ( page )
+        put_page(page);
     if ( rc )
         return rc;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:31:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmCI-00026b-Np; Fri, 27 Apr 2012 14:30:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNmCH-00026P-GJ
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:30:57 +0000
Received: from [193.109.254.147:36755] by server-10.bemta-14.messagelabs.com
	id 21/62-05847-0ADAA9F4; Fri, 27 Apr 2012 14:30:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335537044!6639358!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMjIyOTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24336 invoked from network); 27 Apr 2012 14:30:44 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 14:30:44 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 38B8B71406B;
	Fri, 27 Apr 2012 07:30:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=PnMur+lIQE3pcT1sdQj4FM
	by1QQ0E8LiXl4caZ0E1R6U3MuFWPdOCkxyM+KHyMUZ5Kgx5BfJwflC2ccPP8Svv3
	cZZIKbR+P4u0izcbO7bW4fbUp8FvyPOOCPI6roh7MMBCp+0VpfDO4Dq9JXXS6uoW
	7Ru6DxjdmefkxHtauBG+o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=kQV4BnOS0saV
	HMWzFxs75FLJ7zc=; b=GMXp5+N14KP2cRGcNoSsSQitCm10VBZSliLfFG11LBI1
	1o1X+EO3MMp2+DXuOEj93RG7NcyjCyManeUYMaGB2BEmOokoe/EW6jlb01s3ldQJ
	Dp18ZYWVOMi79vrc7xXcW7NxW5wna9+Uqi9j6R9d7Cw44VAKxn/NnjYNZDPNcws=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id C852E71406A; 
	Fri, 27 Apr 2012 07:30:42 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335537380@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 10:36:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 2] RFC More get-page-from-gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RFC, expanding the monster patch with more call sites and bugfixes.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavaill.org>

 xen/arch/x86/hvm/svm/svm.c |  20 +++++++-----------
 xen/arch/x86/mm.c          |  48 ++++++++++++++++++---------------------------
 xen/common/memory.c        |   9 +++++++-
 xen/common/tmem_xen.c      |  26 +++++++++---------------
 xen/include/asm-x86/p2m.h  |  11 ----------
 xen/xsm/flask/hooks.c      |  19 ++++++++++++++---
 6 files changed, 60 insertions(+), 73 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:31:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmCI-00026b-Np; Fri, 27 Apr 2012 14:30:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNmCH-00026P-GJ
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:30:57 +0000
Received: from [193.109.254.147:36755] by server-10.bemta-14.messagelabs.com
	id 21/62-05847-0ADAA9F4; Fri, 27 Apr 2012 14:30:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335537044!6639358!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMjIyOTU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24336 invoked from network); 27 Apr 2012 14:30:44 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 14:30:44 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 38B8B71406B;
	Fri, 27 Apr 2012 07:30:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=PnMur+lIQE3pcT1sdQj4FM
	by1QQ0E8LiXl4caZ0E1R6U3MuFWPdOCkxyM+KHyMUZ5Kgx5BfJwflC2ccPP8Svv3
	cZZIKbR+P4u0izcbO7bW4fbUp8FvyPOOCPI6roh7MMBCp+0VpfDO4Dq9JXXS6uoW
	7Ru6DxjdmefkxHtauBG+o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=kQV4BnOS0saV
	HMWzFxs75FLJ7zc=; b=GMXp5+N14KP2cRGcNoSsSQitCm10VBZSliLfFG11LBI1
	1o1X+EO3MMp2+DXuOEj93RG7NcyjCyManeUYMaGB2BEmOokoe/EW6jlb01s3ldQJ
	Dp18ZYWVOMi79vrc7xXcW7NxW5wna9+Uqi9j6R9d7Cw44VAKxn/NnjYNZDPNcws=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id C852E71406A; 
	Fri, 27 Apr 2012 07:30:42 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335537380@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 10:36:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 2] RFC More get-page-from-gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RFC, expanding the monster patch with more call sites and bugfixes.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavaill.org>

 xen/arch/x86/hvm/svm/svm.c |  20 +++++++-----------
 xen/arch/x86/mm.c          |  48 ++++++++++++++++++---------------------------
 xen/common/memory.c        |   9 +++++++-
 xen/common/tmem_xen.c      |  26 +++++++++---------------
 xen/include/asm-x86/p2m.h  |  11 ----------
 xen/xsm/flask/hooks.c      |  19 ++++++++++++++---
 6 files changed, 60 insertions(+), 73 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:37:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmHw-0002Xq-LY; Fri, 27 Apr 2012 14:36:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNmHv-0002Xh-Ff
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:36:47 +0000
Received: from [85.158.139.83:2924] by server-11.bemta-5.messagelabs.com id
	85/78-12959-EFEAA9F4; Fri, 27 Apr 2012 14:36:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335537405!25136058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8281 invoked from network); 27 Apr 2012 14:36:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 14:36:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12180453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 14:36:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 15:36:43 +0100
Message-ID: <1335537402.28015.227.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 27 Apr 2012 15:36:42 +0100
In-Reply-To: <1335536869945-5670447.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
	<1335536869945-5670447.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
> Lucid disk1 is ext4 partition, on old xen-unstable test build was working,

Do you know what changeset that was?

> also without change of python prefix, monday I retry with full clean build
> and also to latest changeset



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:37:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmHw-0002Xq-LY; Fri, 27 Apr 2012 14:36:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNmHv-0002Xh-Ff
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:36:47 +0000
Received: from [85.158.139.83:2924] by server-11.bemta-5.messagelabs.com id
	85/78-12959-EFEAA9F4; Fri, 27 Apr 2012 14:36:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335537405!25136058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8281 invoked from network); 27 Apr 2012 14:36:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 14:36:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12180453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 14:36:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 15:36:43 +0100
Message-ID: <1335537402.28015.227.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 27 Apr 2012 15:36:42 +0100
In-Reply-To: <1335536869945-5670447.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
	<1335536869945-5670447.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
> Lucid disk1 is ext4 partition, on old xen-unstable test build was working,

Do you know what changeset that was?

> also without change of python prefix, monday I retry with full clean build
> and also to latest changeset



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:37:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:37:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmIE-0002Yk-2K; Fri, 27 Apr 2012 14:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNmIC-0002YM-F5
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:37:04 +0000
Received: from [85.158.143.35:58287] by server-1.bemta-4.messagelabs.com id
	08/4C-20925-F0FAA9F4; Fri, 27 Apr 2012 14:37:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335537421!12905659!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5OTUxMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5218 invoked from network); 27 Apr 2012 14:37:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 14:37:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3REax4N015271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 14:37:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3REav94010682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Apr 2012 14:36:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3REav8o008473; Fri, 27 Apr 2012 09:36:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Apr 2012 07:36:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0FD8E402FB; Fri, 27 Apr 2012 10:31:23 -0400 (EDT)
Date: Fri, 27 Apr 2012 10:31:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120427143122.GD9186@phenom.dumpdata.com>
References: <20120427023439.GB26931@phenom.dumpdata.com>
	<4F9AA4C602000078000806F2@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9AA4C602000078000806F2@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for
 domain 0: 694017 > 694016
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> How would that be? 2711MiB = 2776064kiB, which 446k off the value
> above. And apart from that, the value above isn't even divisible by 4

I messed up on that. Redid the numbers and I was off.

> (i.e. not an even number of pages).

To make this a bit easier I used 'dom0_max=max:3G', which means
(with this swiss-cheese type E820 on this Intel box):

[    0.000000] Released 75745 pages of unused memory

so I should have 75745 pages left to play with. But what I found is that
I can only go up to 786415 which is 17 pages short of the 786432 goal.

Here are the steps:

$cat `find /sys -name current_kb`
2842816
$echo $((3*1024*1024))
3145728
$echo "3145728" > `find /sys -name target_kb`
$cat `find /sys -name current_kb`
3145660
$xl dmesg | tail
(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 786433 (786432) > 786432
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)

> > Any ideas of what that might be? Could it be the shared_info, hypercall page,
> > start_info, xenconsole and some other ones are the magic 6 pages which
> > inhibit how much we can balloon up to?
> 
> Not likely: The hypercall page is in kernel (image) memory, and there's
> no console page at all fro Dom0.

17 pages.. Hmm
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:37:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:37:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmIE-0002Yk-2K; Fri, 27 Apr 2012 14:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SNmIC-0002YM-F5
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:37:04 +0000
Received: from [85.158.143.35:58287] by server-1.bemta-4.messagelabs.com id
	08/4C-20925-F0FAA9F4; Fri, 27 Apr 2012 14:37:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1335537421!12905659!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5OTUxMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5218 invoked from network); 27 Apr 2012 14:37:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Apr 2012 14:37:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3REax4N015271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 14:37:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3REav94010682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Apr 2012 14:36:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3REav8o008473; Fri, 27 Apr 2012 09:36:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Apr 2012 07:36:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0FD8E402FB; Fri, 27 Apr 2012 10:31:23 -0400 (EDT)
Date: Fri, 27 Apr 2012 10:31:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120427143122.GD9186@phenom.dumpdata.com>
References: <20120427023439.GB26931@phenom.dumpdata.com>
	<4F9AA4C602000078000806F2@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9AA4C602000078000806F2@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for
 domain 0: 694017 > 694016
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> How would that be? 2711MiB = 2776064kiB, which 446k off the value
> above. And apart from that, the value above isn't even divisible by 4

I messed up on that. Redid the numbers and I was off.

> (i.e. not an even number of pages).

To make this a bit easier I used 'dom0_max=max:3G', which means
(with this swiss-cheese type E820 on this Intel box):

[    0.000000] Released 75745 pages of unused memory

so I should have 75745 pages left to play with. But what I found is that
I can only go up to 786415 which is 17 pages short of the 786432 goal.

Here are the steps:

$cat `find /sys -name current_kb`
2842816
$echo $((3*1024*1024))
3145728
$echo "3145728" > `find /sys -name target_kb`
$cat `find /sys -name current_kb`
3145660
$xl dmesg | tail
(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 786433 (786432) > 786432
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)

> > Any ideas of what that might be? Could it be the shared_info, hypercall page,
> > start_info, xenconsole and some other ones are the magic 6 pages which
> > inhibit how much we can balloon up to?
> 
> Not likely: The hypercall page is in kernel (image) memory, and there's
> no console page at all fro Dom0.

17 pages.. Hmm
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:39:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmKg-0002lO-S5; Fri, 27 Apr 2012 14:39:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1SNmKf-0002lE-2z
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:39:37 +0000
Received: from [85.158.143.35:10474] by server-1.bemta-4.messagelabs.com id
	74/7F-20925-8AFAA9F4; Fri, 27 Apr 2012 14:39:36 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335537573!14610284!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6478 invoked from network); 27 Apr 2012 14:39:34 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 14:39:34 -0000
Received: by bkwj5 with SMTP id j5so650144bkw.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Apr 2012 07:39:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=T3Dr5wHwCGMUSwydI/cIpVeXsMkZfc3TqctJGfX7MXY=;
	b=HwdU81LFwKdYKfuS8WdI4SLmVOL45OrU8emskqlRv1okyxyLjh3zOywZAu1a5kN77U
	/on5qy/xso9Z6Pf0miKhisobzfuMVO8QKEfbPlR5JBN5EcMhFJ9E6VkYOw1e3qWGRvUk
	k6RcFHOsKDE/zn1QSZgVnqr2tn2imvo2AWO9HSndNB0bY8t84xyHCIVv6sFnHOQ0HSe7
	mDZhztfwAOTovGJO/UpOJOJkQXwp/75tmxwA4UDpi4dJLfBFnT1ePHkm4zagIVQBpbgl
	WWrBiFYY2lXlHzEI67VNN4ABGAfuTDHzvv4QQGv0pqF3jD+Ya67iN6ofY770hbMd/56X
	/RIQ==
MIME-Version: 1.0
Received: by 10.205.124.9 with SMTP id gm9mr1284352bkc.29.1335537572515; Fri,
	27 Apr 2012 07:39:32 -0700 (PDT)
Received: by 10.204.114.138 with HTTP; Fri, 27 Apr 2012 07:39:32 -0700 (PDT)
In-Reply-To: <20120425123115.GC51354@ocelot.phlegethon.org>
References: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
	<20120425123115.GC51354@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 09:39:32 -0500
Message-ID: <CAKLFbfw4SEiPkSui3x06fnfhnt3Gn_5exB8J1bdRd+ZjChAoTg@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Cc: todd.deshane@xen.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2523448808349643608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2523448808349643608==
Content-Type: multipart/alternative; boundary=000e0ce0d5ca98115604beaa1244

--000e0ce0d5ca98115604beaa1244
Content-Type: text/plain; charset=ISO-8859-1

Thanks Tim.

I am interested in working with the implementation of XOAR. Is there are
place to start (wiki/roadmap) etc. ?

~ SDK



On Wed, Apr 25, 2012 at 7:31 AM, Tim Deegan <tim@xen.org> wrote:

> At 23:36 -0500 on 24 Apr (1335310591), Srujan Kotikela wrote:
> > Hi All,
> >
> > I just saw  http://vimeo.com/38636349 by todd. Nice plans for securing
> xen.
> >
> > May I know who is leading/implementing XOAR ideas and Dom0
> disaggregation?
>
> I believe the XCP/xapi developers are looking into implementing it.  You
> could also look at Qubes OS, which uses a lot of similar ideas in a
> desktop setting.
>
> Tim.
>

--000e0ce0d5ca98115604beaa1244
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Tim.<div><br></div><div>I am interested in working with the implemen=
tation of XOAR. Is there are place to start (wiki/roadmap) etc. ?</div><div=
><br clear=3D"all">~ SDK<br><br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 2=
5, 2012 at 7:31 AM, Tim Deegan <span dir=3D"ltr">&lt;<a href=3D"mailto:tim@=
xen.org" target=3D"_blank">tim@xen.org</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">At 23:36 -0500 on 24 Apr (133531059=
1), Srujan Kotikela wrote:<br>
&gt; Hi All,<br>
&gt;<br>
&gt; I just saw =A0<a href=3D"http://vimeo.com/38636349" target=3D"_blank">=
http://vimeo.com/38636349</a> by todd. Nice plans for securing xen.<br>
&gt;<br>
&gt; May I know who is leading/implementing XOAR ideas and Dom0 disaggregat=
ion?<br>
<br>
</div></div>I believe the XCP/xapi developers are looking into implementing=
 it. =A0You<br>
could also look at Qubes OS, which uses a lot of similar ideas in a<br>
desktop setting.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>

--000e0ce0d5ca98115604beaa1244--


--===============2523448808349643608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2523448808349643608==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 14:39:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmKg-0002lO-S5; Fri, 27 Apr 2012 14:39:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1SNmKf-0002lE-2z
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 14:39:37 +0000
Received: from [85.158.143.35:10474] by server-1.bemta-4.messagelabs.com id
	74/7F-20925-8AFAA9F4; Fri, 27 Apr 2012 14:39:36 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335537573!14610284!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6478 invoked from network); 27 Apr 2012 14:39:34 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 14:39:34 -0000
Received: by bkwj5 with SMTP id j5so650144bkw.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Apr 2012 07:39:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=T3Dr5wHwCGMUSwydI/cIpVeXsMkZfc3TqctJGfX7MXY=;
	b=HwdU81LFwKdYKfuS8WdI4SLmVOL45OrU8emskqlRv1okyxyLjh3zOywZAu1a5kN77U
	/on5qy/xso9Z6Pf0miKhisobzfuMVO8QKEfbPlR5JBN5EcMhFJ9E6VkYOw1e3qWGRvUk
	k6RcFHOsKDE/zn1QSZgVnqr2tn2imvo2AWO9HSndNB0bY8t84xyHCIVv6sFnHOQ0HSe7
	mDZhztfwAOTovGJO/UpOJOJkQXwp/75tmxwA4UDpi4dJLfBFnT1ePHkm4zagIVQBpbgl
	WWrBiFYY2lXlHzEI67VNN4ABGAfuTDHzvv4QQGv0pqF3jD+Ya67iN6ofY770hbMd/56X
	/RIQ==
MIME-Version: 1.0
Received: by 10.205.124.9 with SMTP id gm9mr1284352bkc.29.1335537572515; Fri,
	27 Apr 2012 07:39:32 -0700 (PDT)
Received: by 10.204.114.138 with HTTP; Fri, 27 Apr 2012 07:39:32 -0700 (PDT)
In-Reply-To: <20120425123115.GC51354@ocelot.phlegethon.org>
References: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
	<20120425123115.GC51354@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 09:39:32 -0500
Message-ID: <CAKLFbfw4SEiPkSui3x06fnfhnt3Gn_5exB8J1bdRd+ZjChAoTg@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Cc: todd.deshane@xen.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============2523448808349643608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2523448808349643608==
Content-Type: multipart/alternative; boundary=000e0ce0d5ca98115604beaa1244

--000e0ce0d5ca98115604beaa1244
Content-Type: text/plain; charset=ISO-8859-1

Thanks Tim.

I am interested in working with the implementation of XOAR. Is there are
place to start (wiki/roadmap) etc. ?

~ SDK



On Wed, Apr 25, 2012 at 7:31 AM, Tim Deegan <tim@xen.org> wrote:

> At 23:36 -0500 on 24 Apr (1335310591), Srujan Kotikela wrote:
> > Hi All,
> >
> > I just saw  http://vimeo.com/38636349 by todd. Nice plans for securing
> xen.
> >
> > May I know who is leading/implementing XOAR ideas and Dom0
> disaggregation?
>
> I believe the XCP/xapi developers are looking into implementing it.  You
> could also look at Qubes OS, which uses a lot of similar ideas in a
> desktop setting.
>
> Tim.
>

--000e0ce0d5ca98115604beaa1244
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Tim.<div><br></div><div>I am interested in working with the implemen=
tation of XOAR. Is there are place to start (wiki/roadmap) etc. ?</div><div=
><br clear=3D"all">~ SDK<br><br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 2=
5, 2012 at 7:31 AM, Tim Deegan <span dir=3D"ltr">&lt;<a href=3D"mailto:tim@=
xen.org" target=3D"_blank">tim@xen.org</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">At 23:36 -0500 on 24 Apr (133531059=
1), Srujan Kotikela wrote:<br>
&gt; Hi All,<br>
&gt;<br>
&gt; I just saw =A0<a href=3D"http://vimeo.com/38636349" target=3D"_blank">=
http://vimeo.com/38636349</a> by todd. Nice plans for securing xen.<br>
&gt;<br>
&gt; May I know who is leading/implementing XOAR ideas and Dom0 disaggregat=
ion?<br>
<br>
</div></div>I believe the XCP/xapi developers are looking into implementing=
 it. =A0You<br>
could also look at Qubes OS, which uses a lot of similar ideas in a<br>
desktop setting.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>

--000e0ce0d5ca98115604beaa1244--


--===============2523448808349643608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2523448808349643608==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 14:46:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmR9-00031d-RG; Fri, 27 Apr 2012 14:46:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNmR8-00031X-6r
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:46:18 +0000
Received: from [85.158.138.51:18948] by server-12.bemta-3.messagelabs.com id
	DE/D3-29760-931BA9F4; Fri, 27 Apr 2012 14:46:17 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335537974!19803923!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDAyMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22331 invoked from network); 27 Apr 2012 14:46:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 14:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330923600"; d="scan'208";a="24617500"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 10:46:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:46:12 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNmR2-0005gd-46;
	Fri, 27 Apr 2012 15:46:12 +0100
Message-ID: <4F9AB0F8.10102@eu.citrix.com>
Date: Fri, 27 Apr 2012 15:45:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<1f4b55806de9e7109ff6.1334150274@Solace>
In-Reply-To: <1f4b55806de9e7109ff6.1334150274@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the
 scheduler know about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> Basic idea is: cpu-affinity tells where a vcpu can run,
> while node-affinity tells where (in terms of on what NUMA nodes,
> but that of course imply a set of CPUs) all the vcpus of the
> domain should/prefer to run... Problems starts when you have
> both of them speaking at the same time!
>
> Respecting vcpu-affinity should remain the primary concern, thus
> what we do here is add some two-step logic here and there in the
> scheduler (i.e., where vcpu-affinity related decisions are being
> undertaken). During the first step, we check the `&&` of vcpu and
> node affinity masks, aiming at giving some precedence to the CPUs
> that are both suitable and preferrable for the domain. However,
> if that fails in finding a valid CPU, the node-affinity is just
> ignored and, in the second step, we just fallback to vcpu-affinity,
> as the original behaviour was.
>
> Both the introduced overhead and the benefits this provides has
> to be investigated and compared against each other, possibly in
> varying conditions and running different workloads.
>
> Finally, although still at the RFC level, efforts have been made
> to write the code in a flexible enough fashion so that, if we
> ever want to introduce further balancing steps, it shouldn't be
> too much of a pain.
>
> TODO: * Better investigate and test interactions with cpupools.
>        * Test, verify and benchmark. Then test, verify and benchmark
>          again, and again and again. What I know as of know is that
>          it does not explode that easily, but whether it works properly
>          and, more important, brings any benefit, this has to be
>          proven (and yes, I'm out running these tests and benchs already,
>          but do not esitate to manifest your will for helping with
>          that :-D).
>        * Add some counter/stats, e.g., to serve the purpose outlined
>          right above.
>
> XXX I'm benchmarking this just right now, and peeking at the results
>      they don't seem too bad. Numbers are mostly close to the case where
>      the VM is already pinned to a node when created. I'll post the
>      results as soon as I can, and I'll be happy to investigate any issue,
>      if you feel like the approach could be the right one.
Hey Dario,

Sorry for the long delay in reviewing this.

Overall I think the approach is good.  A few points:
>   /*
> + * Node Balancing
> + */
> +#define CSCHED_BALANCE_NODE_AFFINITY    1
> +#define CSCHED_BALANCE_CPU_AFFINITY     0
> +#define CSCHED_BALANCE_START_STEP       CSCHED_BALANCE_NODE_AFFINITY
> +#define CSCHED_BALANCE_END_STEP         CSCHED_BALANCE_CPU_AFFINITY
> +
> +
This thing of defining "START_STEP" and "END_STEP" seems a bit fragile.  
I think it would be better to always start at 0, and go until 
CSCHED_BALANCE_MAX.
> +    /*
> +     * Let's cache domain's dom->node_affinity here as an
> +     * optimization for a couple of hot paths. In fact,
> +     * knowing  whether or not dom->node_affinity has changed
> +     * would allow us to avoid rebuilding node_affinity_cpumask
> +     * (below) duing node balancing and/or scheduling.
> +     */
> +    nodemask_t node_affinity_cache;
> +    /* Basing on what dom->node_affinity says,
> +     * on what CPUs would we like to run most? */
> +    cpumask_t node_affinity_cpumask;
I think the comments here need to be more clear.  The main points are:
* node_affinity_cpumask is the dom->node_affinity translated from a 
nodemask into a cpumask
* Because doing the nodemask -> cpumask translation may be expensive, 
node_affinity_cache stores the last translated value, so we can avoid 
doing the translation if nothing has changed.

> +#define csched_balance(__step) \
> +    for ( (__step) = CSCHED_BALANCE_START_STEP; \
> +          (__step)>= CSCHED_BALANCE_END_STEP; \
> +          (__step)-- )
I don't like this.  For one, it's fragile; if for some reason you 
switched NODE_AFFINITY and CPU_AFFINITY above, suddenly this loop would 
go the wrong direction.

I don't think there's any reason not to just use "for(step=0; step < 
CSCHED_BALANCE_MAX; step++)" -- it's not ugly and it means you know 
exactly what's going on without having to go search for the macro.

> +
> +/*
> + * Sort-of conversion between node-affinity and vcpu-affinity for the domain,
> + * i.e., a cpumask containing all the cpus from all the set nodes in the
> + * node-affinity mask of the domain.
This needs to be clearer -- vcpu-affinity doesn't have anything to do 
with this function, and there's nothing "sort-of" about the conversion. :-)

I think you mean to say, "Create a cpumask from the node affinity mask."
> + *
> + * Notice that we completely forget about serializing this (both here and
> + * in the various sites where node_affinity_cpumask is used) against
> + * d->node_affinity_lock. That would be hard to do properly, as that lock
> + * is a non IRQ-safe one, and it would be nearly impossible to access it
> + * from the scheduling code. However, although this leaves some room for
> + * races with code paths that updates d->node_affinity, it all should still
> + * be fine, considering:
> + *  (1) d->node_affinity updates are going to be quite rare;
> + *  (2) this balancing logic is kind-of "best effort" anyway;
> + *  (3) given (1), any inconsistencies are likely to be fixed by the next
> + *      call to this same function without risking going into instability.
> + *
> + * XXX Validate (via testing/benchmarking) whether this is true, as it
> + *     likely sounds to be, or it causes unexpected issues.
Ack.
> +/* Put together the cpumask we are going to use for this balancing step */
> +static int
> +csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
> +{
> +    struct domain *d = vc->domain;
> +    struct csched_dom *sdom = CSCHED_DOM(d);
> +
> +    /*
> +     * Only two possible steps exists for now: node and vcpu affinity.
> +     * If this domain does not have a node-affinity or is affine to all the
> +     * nodes, just return th vcpu-affinity mask (for *this* vcpu) and
> +     * stop the balancing process.
> +     */
> +    if ( !d->has_node_affinity || nodes_full(d->node_affinity) ||
> +         step == CSCHED_BALANCE_CPU_AFFINITY )
> +    {
> +        cpumask_copy(mask, vc->cpu_affinity);
> +        return CSCHED_BALANCE_CPU_AFFINITY;
> +    }
Hmm -- this mechanism seems kind of fragile.  It seems like returning -1 
or something, and having the caller call "continue", would be easier for 
future coders (potentially you or I) to reason about.
> +    /*
> +     * XXX As of now (with only two possible steps, this is easy and readable
> +     *     enough. If more steps become necessary at some point in time, we
> +     *     can keep an array of cpumask_t in dom_data and return the proper
> +     *     element via step-indexing such an array. Of course, we can turn
> +     *     this like that even right now... Thoughts?
> +     */
Beware of early optimization. :-)  Just make sure to mark this down for 
something to look at for profiling.
>   static inline void
> +__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask)
> +{
> +    CSCHED_STAT_CRANK(tickle_idlers_some);
> +    if ( opt_tickle_one_idle )
> +    {
> +        this_cpu(last_tickle_cpu) =
> +            cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask);
> +        cpumask_set_cpu(this_cpu(last_tickle_cpu), mask);
> +    }
> +    else
> +        cpumask_or(mask, mask, idle_mask);
> +}
I don't see any reason to make this into a function -- it's only called 
once, and it's not that long.  Unless you're concerned about too many 
indentations making the lines too short?
> +            csched_balance(balance_step)
>               {
Again, I'd make this a for() loop.
>      sdom->dom = dom;
> +    /*
> +     *XXX This would be 'The Right Thing', but as it is still too
> +     *    early and d->node_affinity has not settled yet, maybe we
> +     *    can just init the two masks with something like all-nodes
> +     *    and all-cpus and rely on the first balancing call for
> +     *    having them updated?
> +     */
> +    csched_build_balance_cpumask(sdom);
We might as well do what you've got here, unless it's likely to produce 
garbage.  This isn't exactly a hot path. :-)

Other than that, looks good -- Thanks!

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 14:46:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 14:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmR9-00031d-RG; Fri, 27 Apr 2012 14:46:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SNmR8-00031X-6r
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 14:46:18 +0000
Received: from [85.158.138.51:18948] by server-12.bemta-3.messagelabs.com id
	DE/D3-29760-931BA9F4; Fri, 27 Apr 2012 14:46:17 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1335537974!19803923!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDAyMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22331 invoked from network); 27 Apr 2012 14:46:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 14:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330923600"; d="scan'208";a="24617500"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 10:46:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 10:46:12 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SNmR2-0005gd-46;
	Fri, 27 Apr 2012 15:46:12 +0100
Message-ID: <4F9AB0F8.10102@eu.citrix.com>
Date: Fri, 27 Apr 2012 15:45:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1334150267@Solace>
	<1f4b55806de9e7109ff6.1334150274@Solace>
In-Reply-To: <1f4b55806de9e7109ff6.1334150274@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the
 scheduler know about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/04/12 14:17, Dario Faggioli wrote:
> Basic idea is: cpu-affinity tells where a vcpu can run,
> while node-affinity tells where (in terms of on what NUMA nodes,
> but that of course imply a set of CPUs) all the vcpus of the
> domain should/prefer to run... Problems starts when you have
> both of them speaking at the same time!
>
> Respecting vcpu-affinity should remain the primary concern, thus
> what we do here is add some two-step logic here and there in the
> scheduler (i.e., where vcpu-affinity related decisions are being
> undertaken). During the first step, we check the `&&` of vcpu and
> node affinity masks, aiming at giving some precedence to the CPUs
> that are both suitable and preferrable for the domain. However,
> if that fails in finding a valid CPU, the node-affinity is just
> ignored and, in the second step, we just fallback to vcpu-affinity,
> as the original behaviour was.
>
> Both the introduced overhead and the benefits this provides has
> to be investigated and compared against each other, possibly in
> varying conditions and running different workloads.
>
> Finally, although still at the RFC level, efforts have been made
> to write the code in a flexible enough fashion so that, if we
> ever want to introduce further balancing steps, it shouldn't be
> too much of a pain.
>
> TODO: * Better investigate and test interactions with cpupools.
>        * Test, verify and benchmark. Then test, verify and benchmark
>          again, and again and again. What I know as of know is that
>          it does not explode that easily, but whether it works properly
>          and, more important, brings any benefit, this has to be
>          proven (and yes, I'm out running these tests and benchs already,
>          but do not esitate to manifest your will for helping with
>          that :-D).
>        * Add some counter/stats, e.g., to serve the purpose outlined
>          right above.
>
> XXX I'm benchmarking this just right now, and peeking at the results
>      they don't seem too bad. Numbers are mostly close to the case where
>      the VM is already pinned to a node when created. I'll post the
>      results as soon as I can, and I'll be happy to investigate any issue,
>      if you feel like the approach could be the right one.
Hey Dario,

Sorry for the long delay in reviewing this.

Overall I think the approach is good.  A few points:
>   /*
> + * Node Balancing
> + */
> +#define CSCHED_BALANCE_NODE_AFFINITY    1
> +#define CSCHED_BALANCE_CPU_AFFINITY     0
> +#define CSCHED_BALANCE_START_STEP       CSCHED_BALANCE_NODE_AFFINITY
> +#define CSCHED_BALANCE_END_STEP         CSCHED_BALANCE_CPU_AFFINITY
> +
> +
This thing of defining "START_STEP" and "END_STEP" seems a bit fragile.  
I think it would be better to always start at 0, and go until 
CSCHED_BALANCE_MAX.
> +    /*
> +     * Let's cache domain's dom->node_affinity here as an
> +     * optimization for a couple of hot paths. In fact,
> +     * knowing  whether or not dom->node_affinity has changed
> +     * would allow us to avoid rebuilding node_affinity_cpumask
> +     * (below) duing node balancing and/or scheduling.
> +     */
> +    nodemask_t node_affinity_cache;
> +    /* Basing on what dom->node_affinity says,
> +     * on what CPUs would we like to run most? */
> +    cpumask_t node_affinity_cpumask;
I think the comments here need to be more clear.  The main points are:
* node_affinity_cpumask is the dom->node_affinity translated from a 
nodemask into a cpumask
* Because doing the nodemask -> cpumask translation may be expensive, 
node_affinity_cache stores the last translated value, so we can avoid 
doing the translation if nothing has changed.

> +#define csched_balance(__step) \
> +    for ( (__step) = CSCHED_BALANCE_START_STEP; \
> +          (__step)>= CSCHED_BALANCE_END_STEP; \
> +          (__step)-- )
I don't like this.  For one, it's fragile; if for some reason you 
switched NODE_AFFINITY and CPU_AFFINITY above, suddenly this loop would 
go the wrong direction.

I don't think there's any reason not to just use "for(step=0; step < 
CSCHED_BALANCE_MAX; step++)" -- it's not ugly and it means you know 
exactly what's going on without having to go search for the macro.

> +
> +/*
> + * Sort-of conversion between node-affinity and vcpu-affinity for the domain,
> + * i.e., a cpumask containing all the cpus from all the set nodes in the
> + * node-affinity mask of the domain.
This needs to be clearer -- vcpu-affinity doesn't have anything to do 
with this function, and there's nothing "sort-of" about the conversion. :-)

I think you mean to say, "Create a cpumask from the node affinity mask."
> + *
> + * Notice that we completely forget about serializing this (both here and
> + * in the various sites where node_affinity_cpumask is used) against
> + * d->node_affinity_lock. That would be hard to do properly, as that lock
> + * is a non IRQ-safe one, and it would be nearly impossible to access it
> + * from the scheduling code. However, although this leaves some room for
> + * races with code paths that updates d->node_affinity, it all should still
> + * be fine, considering:
> + *  (1) d->node_affinity updates are going to be quite rare;
> + *  (2) this balancing logic is kind-of "best effort" anyway;
> + *  (3) given (1), any inconsistencies are likely to be fixed by the next
> + *      call to this same function without risking going into instability.
> + *
> + * XXX Validate (via testing/benchmarking) whether this is true, as it
> + *     likely sounds to be, or it causes unexpected issues.
Ack.
> +/* Put together the cpumask we are going to use for this balancing step */
> +static int
> +csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
> +{
> +    struct domain *d = vc->domain;
> +    struct csched_dom *sdom = CSCHED_DOM(d);
> +
> +    /*
> +     * Only two possible steps exists for now: node and vcpu affinity.
> +     * If this domain does not have a node-affinity or is affine to all the
> +     * nodes, just return th vcpu-affinity mask (for *this* vcpu) and
> +     * stop the balancing process.
> +     */
> +    if ( !d->has_node_affinity || nodes_full(d->node_affinity) ||
> +         step == CSCHED_BALANCE_CPU_AFFINITY )
> +    {
> +        cpumask_copy(mask, vc->cpu_affinity);
> +        return CSCHED_BALANCE_CPU_AFFINITY;
> +    }
Hmm -- this mechanism seems kind of fragile.  It seems like returning -1 
or something, and having the caller call "continue", would be easier for 
future coders (potentially you or I) to reason about.
> +    /*
> +     * XXX As of now (with only two possible steps, this is easy and readable
> +     *     enough. If more steps become necessary at some point in time, we
> +     *     can keep an array of cpumask_t in dom_data and return the proper
> +     *     element via step-indexing such an array. Of course, we can turn
> +     *     this like that even right now... Thoughts?
> +     */
Beware of early optimization. :-)  Just make sure to mark this down for 
something to look at for profiling.
>   static inline void
> +__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask)
> +{
> +    CSCHED_STAT_CRANK(tickle_idlers_some);
> +    if ( opt_tickle_one_idle )
> +    {
> +        this_cpu(last_tickle_cpu) =
> +            cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask);
> +        cpumask_set_cpu(this_cpu(last_tickle_cpu), mask);
> +    }
> +    else
> +        cpumask_or(mask, mask, idle_mask);
> +}
I don't see any reason to make this into a function -- it's only called 
once, and it's not that long.  Unless you're concerned about too many 
indentations making the lines too short?
> +            csched_balance(balance_step)
>               {
Again, I'd make this a for() loop.
>      sdom->dom = dom;
> +    /*
> +     *XXX This would be 'The Right Thing', but as it is still too
> +     *    early and d->node_affinity has not settled yet, maybe we
> +     *    can just init the two masks with something like all-nodes
> +     *    and all-cpus and rely on the first balancing call for
> +     *    having them updated?
> +     */
> +    csched_build_balance_cpumask(sdom);
We might as well do what you've got here, unless it's likely to produce 
garbage.  This isn't exactly a hot path. :-)

Other than that, looks good -- Thanks!

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:03:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmhJ-0003E8-JK; Fri, 27 Apr 2012 15:03:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SNmhI-0003E3-1y
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 15:03:00 +0000
Received: from [193.109.254.147:36279] by server-9.bemta-14.messagelabs.com id
	7B/9D-05787-325BA9F4; Fri, 27 Apr 2012 15:02:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335538978!6657327!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16374 invoked from network); 27 Apr 2012 15:02:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:02:58 -0000
Received: by eeit10 with SMTP id t10so236953eei.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 08:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SSZ62vHUaXYqCq9GZnrCvOhR8cEzKGE/dxkyvAaM22c=;
	b=xwUDFiRoEh2o+j+8GYejKYX2d4qddsz/8vK7lzqqbPjzWPDAvGFnw8eLSEfZqRwUYD
	5NqsQKWyrfIDlDDHlw43crfKgQoUmRxczQQE0mA8W7XHtWMksw7naR1QPVJlQraAh9Uv
	TQswCaXDsfPG287Jc4oE+d44FVj6JhFtomNG+yIPkbuk7Oa0d52lK7mbs8CZDZduulY2
	nr8Ztlnaw0EcTlIkf8zAWJYTzt6RGeUjzeMHwgaMeIgNHH1OfWmGwgnUS0EZX6owJM24
	cWJl2YgWT0M4vzGSfCPwhX2LyZA3fRYgKYv6NLDiwETHS+2umaWVe2a/V+l2gKVQF8ni
	ET6w==
Received: by 10.213.28.148 with SMTP id m20mr471055ebc.41.1335538978277;
	Fri, 27 Apr 2012 08:02:58 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id n56sm31722309eeb.4.2012.04.27.08.02.56
	(version=SSLv3 cipher=OTHER); Fri, 27 Apr 2012 08:02:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 27 Apr 2012 16:02:46 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <CBC073A6.3F0F5%keir@xen.org>
Thread-Topic: [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to HVM VCPU
	context
Thread-Index: Ac0khs3DPHeLgiy8cEm68MzzVdw/Iw==
In-Reply-To: <4F9AB1F90200007800080769@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to
 HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/04/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 25.04.12 at 20:38, Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>>> wrote:
>> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> 
> Given that we're in feature freeze right now - is this actually fixing some
> shortcoming somewhere? Otherwise it may need to wait until 4.2 is out.

I think we can make a judgement call on this one that it is obviously safe
to check it in. Even if the patch is buggy, it's only filling in data fields
with garbage, which were uninitialised garbage in the first place.

 -- Keir

> Jan
> 
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> 
>> diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c Wed Apr 25 11:35:29 2012 -0700
>> +++ b/xen/arch/x86/domctl.c Wed Apr 25 11:35:43 2012 -0700
>> @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
>>          c.nat->user_regs.es = sreg.sel;
>>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>>          c.nat->user_regs.fs = sreg.sel;
>> +#ifdef __x86_64__
>> +        c.nat->fs_base = sreg.base;
>> +#endif
>>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>          c.nat->user_regs.gs = sreg.sel;
>> +#ifdef __x86_64__
>> +        if ( ring_0(&c.nat->user_regs) )
>> +        {
>> +            c.nat->gs_base_kernel = sreg.base;
>> +            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
>> +        }
>> +        else
>> +        {
>> +            c.nat->gs_base_user = sreg.base;
>> +            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
>> +        }
>> +#endif
>>      }
>>      else
>>      {
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:03:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmhJ-0003E8-JK; Fri, 27 Apr 2012 15:03:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SNmhI-0003E3-1y
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 15:03:00 +0000
Received: from [193.109.254.147:36279] by server-9.bemta-14.messagelabs.com id
	7B/9D-05787-325BA9F4; Fri, 27 Apr 2012 15:02:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335538978!6657327!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16374 invoked from network); 27 Apr 2012 15:02:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:02:58 -0000
Received: by eeit10 with SMTP id t10so236953eei.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 08:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SSZ62vHUaXYqCq9GZnrCvOhR8cEzKGE/dxkyvAaM22c=;
	b=xwUDFiRoEh2o+j+8GYejKYX2d4qddsz/8vK7lzqqbPjzWPDAvGFnw8eLSEfZqRwUYD
	5NqsQKWyrfIDlDDHlw43crfKgQoUmRxczQQE0mA8W7XHtWMksw7naR1QPVJlQraAh9Uv
	TQswCaXDsfPG287Jc4oE+d44FVj6JhFtomNG+yIPkbuk7Oa0d52lK7mbs8CZDZduulY2
	nr8Ztlnaw0EcTlIkf8zAWJYTzt6RGeUjzeMHwgaMeIgNHH1OfWmGwgnUS0EZX6owJM24
	cWJl2YgWT0M4vzGSfCPwhX2LyZA3fRYgKYv6NLDiwETHS+2umaWVe2a/V+l2gKVQF8ni
	ET6w==
Received: by 10.213.28.148 with SMTP id m20mr471055ebc.41.1335538978277;
	Fri, 27 Apr 2012 08:02:58 -0700 (PDT)
Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id n56sm31722309eeb.4.2012.04.27.08.02.56
	(version=SSLv3 cipher=OTHER); Fri, 27 Apr 2012 08:02:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 27 Apr 2012 16:02:46 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Aravindh Puthiyaparambil <aravindh@virtuata.com>
Message-ID: <CBC073A6.3F0F5%keir@xen.org>
Thread-Topic: [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to HVM VCPU
	context
Thread-Index: Ac0khs3DPHeLgiy8cEm68MzzVdw/Iw==
In-Reply-To: <4F9AB1F90200007800080769@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to
 HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/04/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 25.04.12 at 20:38, Aravindh Puthiyaparambil <aravindh@virtuata.com>
>>>> wrote:
>> Add FS and GS base to the HVM VCPU context returned by xc_vcpu_getcontext()
> 
> Given that we're in feature freeze right now - is this actually fixing some
> shortcoming somewhere? Otherwise it may need to wait until 4.2 is out.

I think we can make a judgement call on this one that it is obviously safe
to check it in. Even if the patch is buggy, it's only filling in data fields
with garbage, which were uninitialised garbage in the first place.

 -- Keir

> Jan
> 
>> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> 
>> diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c Wed Apr 25 11:35:29 2012 -0700
>> +++ b/xen/arch/x86/domctl.c Wed Apr 25 11:35:43 2012 -0700
>> @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
>>          c.nat->user_regs.es = sreg.sel;
>>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
>>          c.nat->user_regs.fs = sreg.sel;
>> +#ifdef __x86_64__
>> +        c.nat->fs_base = sreg.base;
>> +#endif
>>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
>>          c.nat->user_regs.gs = sreg.sel;
>> +#ifdef __x86_64__
>> +        if ( ring_0(&c.nat->user_regs) )
>> +        {
>> +            c.nat->gs_base_kernel = sreg.base;
>> +            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
>> +        }
>> +        else
>> +        {
>> +            c.nat->gs_base_user = sreg.base;
>> +            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
>> +        }
>> +#endif
>>      }
>>      else
>>      {
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:21:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmyP-0003Rt-9j; Fri, 27 Apr 2012 15:20:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SNmyN-0003Ro-OM
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:20:40 +0000
Received: from [85.158.143.35:19616] by server-2.bemta-4.messagelabs.com id
	FE/0B-17550-649BA9F4; Fri, 27 Apr 2012 15:20:38 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335540027!13957573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20090 invoked from network); 27 Apr 2012 15:20:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:20:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; 
   d="scan'";a="12181707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:20:27 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:20:27 +0100
Message-ID: <1335540025.2488.67.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 27 Apr 2012 17:20:25 +0200
In-Reply-To: <1335517688.28015.180.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5560424805605324617=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5560424805605324617==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Dc7ahrhV1dd2nZH7i1al"

--=-Dc7ahrhV1dd2nZH7i1al
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote:=20
> > I think what we really want to do is is any of the parameters are set,=
=20
> > after the domain is first created, to read the scheduling parameters fo=
r=20
> > the domain (which will be the defaults), change the ones that are set i=
n=20
> > the config file, and then write the whole structure back.  That=20
> > shouldn't be too hard, as libxl__sched_set_params() is called after the=
=20
> > domain itself is created;
>=20
> I guess the low level libxl_sched_*_params_set should take care of this?
>=20
Possibly, but there's more I'm not sure I understand in the patch (the
original patch, the one that has been checked-in on Wednesday):

+int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_par=
ams *scparams)
+{
+    libxl_ctx *ctx =3D libxl__gc_owner(gc);
+    libxl_scheduler sched;
+    libxl_sched_sedf_domain sedf_info;
+    libxl_sched_credit_domain credit_info;
+    libxl_sched_credit2_domain credit2_info;
+    int ret;
+
+    sched =3D libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      sedf_info.period =3D scparams->period;
+      sedf_info.slice =3D scparams->slice;
+      sedf_info.latency =3D scparams->latency;
+      sedf_info.extratime =3D scparams->extratime;
+      sedf_info.weight =3D scparams->weight;
+      ret=3Dlibxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      credit_info.weight =3D scparams->weight;
<snip>

sched gets the return value of libxl_get_scheduler() which, if I'm not
wrong , read the "default" xen scheduler for this boot, i.e., the one
specified by the "sched=3D" boot command line or whatever the default for
that is (credit1).

After that it decides what libxl_sched_*_domain_set() to call basing
right on that value. What I'm missing is what prevents the domain in
question to be part of a cpupool (e.g., by specifying "poolid=3D" in its
config file as well) for which the scheduler is a different one.

It seems to me that, in such case, we will be setting the wrong set of
parameters anyway, independently on how well we manage in putting a
default in place for them... Am I missing something? If not, as I
haven't found any way of finding out what scheduler is actually being
used for a specific domain, shouldn't we add or mimic that (going
through cpupool, perhaps, I haven't checked yet)?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Dc7ahrhV1dd2nZH7i1al
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+auTkACgkQk4XaBE3IOsRB1gCfZgywyW7lgdlSMHxrDlMrmR85
b4gAoJ/5Q3nOeIPj6QG8rMlmgm7HU/5K
=MRWO
-----END PGP SIGNATURE-----

--=-Dc7ahrhV1dd2nZH7i1al--


--===============5560424805605324617==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5560424805605324617==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 15:21:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNmyP-0003Rt-9j; Fri, 27 Apr 2012 15:20:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SNmyN-0003Ro-OM
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:20:40 +0000
Received: from [85.158.143.35:19616] by server-2.bemta-4.messagelabs.com id
	FE/0B-17550-649BA9F4; Fri, 27 Apr 2012 15:20:38 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1335540027!13957573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20090 invoked from network); 27 Apr 2012 15:20:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:20:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; 
   d="scan'";a="12181707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:20:27 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:20:27 +0100
Message-ID: <1335540025.2488.67.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 27 Apr 2012 17:20:25 +0200
In-Reply-To: <1335517688.28015.180.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============5560424805605324617=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5560424805605324617==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Dc7ahrhV1dd2nZH7i1al"

--=-Dc7ahrhV1dd2nZH7i1al
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote:=20
> > I think what we really want to do is is any of the parameters are set,=
=20
> > after the domain is first created, to read the scheduling parameters fo=
r=20
> > the domain (which will be the defaults), change the ones that are set i=
n=20
> > the config file, and then write the whole structure back.  That=20
> > shouldn't be too hard, as libxl__sched_set_params() is called after the=
=20
> > domain itself is created;
>=20
> I guess the low level libxl_sched_*_params_set should take care of this?
>=20
Possibly, but there's more I'm not sure I understand in the patch (the
original patch, the one that has been checked-in on Wednesday):

+int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_par=
ams *scparams)
+{
+    libxl_ctx *ctx =3D libxl__gc_owner(gc);
+    libxl_scheduler sched;
+    libxl_sched_sedf_domain sedf_info;
+    libxl_sched_credit_domain credit_info;
+    libxl_sched_credit2_domain credit2_info;
+    int ret;
+
+    sched =3D libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      sedf_info.period =3D scparams->period;
+      sedf_info.slice =3D scparams->slice;
+      sedf_info.latency =3D scparams->latency;
+      sedf_info.extratime =3D scparams->extratime;
+      sedf_info.weight =3D scparams->weight;
+      ret=3Dlibxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      credit_info.weight =3D scparams->weight;
<snip>

sched gets the return value of libxl_get_scheduler() which, if I'm not
wrong , read the "default" xen scheduler for this boot, i.e., the one
specified by the "sched=3D" boot command line or whatever the default for
that is (credit1).

After that it decides what libxl_sched_*_domain_set() to call basing
right on that value. What I'm missing is what prevents the domain in
question to be part of a cpupool (e.g., by specifying "poolid=3D" in its
config file as well) for which the scheduler is a different one.

It seems to me that, in such case, we will be setting the wrong set of
parameters anyway, independently on how well we manage in putting a
default in place for them... Am I missing something? If not, as I
haven't found any way of finding out what scheduler is actually being
used for a specific domain, shouldn't we add or mimic that (going
through cpupool, perhaps, I haven't checked yet)?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Dc7ahrhV1dd2nZH7i1al
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+auTkACgkQk4XaBE3IOsRB1gCfZgywyW7lgdlSMHxrDlMrmR85
b4gAoJ/5Q3nOeIPj6QG8rMlmgm7HU/5K
=MRWO
-----END PGP SIGNATURE-----

--=-Dc7ahrhV1dd2nZH7i1al--


--===============5560424805605324617==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5560424805605324617==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 15:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNn1F-0003YL-2H; Fri, 27 Apr 2012 15:23:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNn1C-0003YE-PB
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 15:23:35 +0000
Received: from [85.158.138.51:28850] by server-9.bemta-3.messagelabs.com id
	82/77-26691-5F9BA9F4; Fri, 27 Apr 2012 15:23:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335540212!24186498!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7487 invoked from network); 27 Apr 2012 15:23:32 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:23:32 -0000
Received: by lahe6 with SMTP id e6so713231lah.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 08:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=BgVb6I2yYZU1aRf++Lu70rwE4xXEcW3dcbKSs9Snaew=;
	b=0KeLXXzFeXx4UkK7Yzh/ZjJY7GGHQTWPxL6PKr9N2E1qS82B5d0yJdFGxNdGXhKpgp
	6FPEIjvxq2GV6TV2oTS9uGL13VTs8ydpBFd9YmBkDHDIeTPaM9X3WQ+AIiNGLQuz63Vb
	EzYz5jtz0HXxsmZok0N7BvRljYshSSPiIAg8Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=BgVb6I2yYZU1aRf++Lu70rwE4xXEcW3dcbKSs9Snaew=;
	b=Sccq7ZGd04h8dnRHDhzy5ipVqXhNE1x4jgWfhLR/BqsePLnXjbsmlUWWocMWe3kt5s
	cZQBydl5es1NWm+EDsA0/4d3WvY1X1oLdgVZIn5OJND99dfByuiVeeTqr6ZvomJ8/+DM
	uPPfA91qvID0Y4BLwCVYL8h0B0v01wk5B1yJuzfZjwLTxcJizjCutXsvCGAe2zTqdlEf
	RtAWmFhxfIzEhjZ7MsVX6T1U6P4p1RGTfmnfHJQFlKxuzAKMySf9oWhrCNiSTPQhBOci
	HXy+Xf1c6lyZupKtchGCwV/rtda8D898IT93Fm0meIqA1NRIZvDHZx+Gq8sD8v0rOuYZ
	dAVQ==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr5672068lbm.31.1335540211662; Fri,
	27 Apr 2012 08:23:31 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 08:23:31 -0700 (PDT)
X-Originating-IP: [174.234.81.129]
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 08:23:31 -0700 (PDT)
In-Reply-To: <CBC073A6.3F0F5%keir@xen.org>
References: <4F9AB1F90200007800080769@nat28.tlf.novell.com>
	<CBC073A6.3F0F5%keir@xen.org>
Date: Fri, 27 Apr 2012 08:23:31 -0700
Message-ID: <CAB10MZDNy2i39+=3g6j1q32wEZkJ0R6NL4a7nvOWLTXr0axcWg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Keir Fraser <keir@xen.org>
X-Gm-Message-State: ALoCoQkVUmaCZ4SHvv3oRUDTFlcJfi6MspAattjg48vZ7t/JbBjFZ+BILnlfWygL90JWRRG7Jkh/
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to
	HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4860593334940739884=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4860593334940739884==
Content-Type: multipart/alternative; boundary=bcaec555543ae63f9704beaaaf33

--bcaec555543ae63f9704beaaaf33
Content-Type: text/plain; charset=ISO-8859-1

On Apr 27, 2012 8:02 AM, "Keir Fraser" <keir@xen.org> wrote:
>
> On 27/04/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>>> On 25.04.12 at 20:38, Aravindh Puthiyaparambil <aravindh@virtuata.com
>
> >>>> wrote:
> >> Add FS and GS base to the HVM VCPU context returned by
xc_vcpu_getcontext()
> >
> > Given that we're in feature freeze right now - is this actually fixing
some
> > shortcoming somewhere? Otherwise it may need to wait until 4.2 is out.
>
> I think we can make a judgement call on this one that it is obviously safe
> to check it in. Even if the patch is buggy, it's only filling in data
fields
> with garbage, which were uninitialised garbage in the first place.
>

It will be helpful if this can make it into 4.2. It does provide useful
info for Windows guests.

Thanks,
Aravindh

>  -- Keir
>
> > Jan
> >
> >> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >>
> >> diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
> >> --- a/xen/arch/x86/domctl.c Wed Apr 25 11:35:29 2012 -0700
> >> +++ b/xen/arch/x86/domctl.c Wed Apr 25 11:35:43 2012 -0700
> >> @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
> >>          c.nat->user_regs.es = sreg.sel;
> >>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
> >>          c.nat->user_regs.fs = sreg.sel;
> >> +#ifdef __x86_64__
> >> +        c.nat->fs_base = sreg.base;
> >> +#endif
> >>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
> >>          c.nat->user_regs.gs = sreg.sel;
> >> +#ifdef __x86_64__
> >> +        if ( ring_0(&c.nat->user_regs) )
> >> +        {
> >> +            c.nat->gs_base_kernel = sreg.base;
> >> +            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
> >> +        }
> >> +        else
> >> +        {
> >> +            c.nat->gs_base_user = sreg.base;
> >> +            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
> >> +        }
> >> +#endif
> >>      }
> >>      else
> >>      {
> >
> >
> >
>
>

--bcaec555543ae63f9704beaaaf33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Apr 27, 2012 8:02 AM, &quot;Keir Fraser&quot; &lt;<a href=3D"mailto:keir=
@xen.org">keir@xen.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On 27/04/2012 13:49, &quot;Jan Beulich&quot; &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;&gt;&gt;&gt; On 25.04.12 at 20:38, Aravindh Puthiyaparambil &lt;<a=
 href=3D"mailto:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt;&gt;&gt;&gt; wrote:<br>
&gt; &gt;&gt; Add FS and GS base to the HVM VCPU context returned by xc_vcp=
u_getcontext()<br>
&gt; &gt;<br>
&gt; &gt; Given that we&#39;re in feature freeze right now - is this actual=
ly fixing some<br>
&gt; &gt; shortcoming somewhere? Otherwise it may need to wait until 4.2 is=
 out.<br>
&gt;<br>
&gt; I think we can make a judgement call on this one that it is obviously =
safe<br>
&gt; to check it in. Even if the patch is buggy, it&#39;s only filling in d=
ata fields<br>
&gt; with garbage, which were uninitialised garbage in the first place.<br>
&gt;</p>
<p>It will be helpful if this can make it into 4.2. It does provide useful =
info for Windows guests.</p>
<p>Thanks,<br>
Aravindh</p>
<p>&gt; =A0-- Keir<br>
&gt;<br>
&gt; &gt; Jan<br>
&gt; &gt;<br>
&gt; &gt;&gt; Signed-off-by: Aravindh Puthiyaparambil &lt;<a href=3D"mailto=
:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c<br=
>
&gt; &gt;&gt; --- a/xen/arch/x86/domctl.c Wed Apr 25 11:35:29 2012 -0700<br=
>
&gt; &gt;&gt; +++ b/xen/arch/x86/domctl.c Wed Apr 25 11:35:43 2012 -0700<br=
>
&gt; &gt;&gt; @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *=
v,<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;<a href=3D"http://user_regs.es">=
user_regs.es</a> =3D sreg.sel;<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &a=
mp;sreg);<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;user_regs.fs =3D sreg.sel;<br>
&gt; &gt;&gt; +#ifdef __x86_64__<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0c.nat-&gt;fs_base =3D sreg.base;<br>
&gt; &gt;&gt; +#endif<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &a=
mp;sreg);<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;<a href=3D"http://user_regs.gs">=
user_regs.gs</a> =3D sreg.sel;<br>
&gt; &gt;&gt; +#ifdef __x86_64__<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0if ( ring_0(&amp;c.nat-&gt;user_regs) )<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0{<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_kernel =3D sreg.ba=
se;<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_user =3D hvm_get_s=
hadow_gs_base(v);<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0else<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0{<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_user =3D sreg.base=
;<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_kernel =3D hvm_get=
_shadow_gs_base(v);<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt;&gt; +#endif<br>
&gt; &gt;&gt; =A0 =A0 =A0}<br>
&gt; &gt;&gt; =A0 =A0 =A0else<br>
&gt; &gt;&gt; =A0 =A0 =A0{<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
</p>

--bcaec555543ae63f9704beaaaf33--


--===============4860593334940739884==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4860593334940739884==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 15:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNn1F-0003YL-2H; Fri, 27 Apr 2012 15:23:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNn1C-0003YE-PB
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 15:23:35 +0000
Received: from [85.158.138.51:28850] by server-9.bemta-3.messagelabs.com id
	82/77-26691-5F9BA9F4; Fri, 27 Apr 2012 15:23:33 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1335540212!24186498!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7487 invoked from network); 27 Apr 2012 15:23:32 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:23:32 -0000
Received: by lahe6 with SMTP id e6so713231lah.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 08:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=BgVb6I2yYZU1aRf++Lu70rwE4xXEcW3dcbKSs9Snaew=;
	b=0KeLXXzFeXx4UkK7Yzh/ZjJY7GGHQTWPxL6PKr9N2E1qS82B5d0yJdFGxNdGXhKpgp
	6FPEIjvxq2GV6TV2oTS9uGL13VTs8ydpBFd9YmBkDHDIeTPaM9X3WQ+AIiNGLQuz63Vb
	EzYz5jtz0HXxsmZok0N7BvRljYshSSPiIAg8Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=BgVb6I2yYZU1aRf++Lu70rwE4xXEcW3dcbKSs9Snaew=;
	b=Sccq7ZGd04h8dnRHDhzy5ipVqXhNE1x4jgWfhLR/BqsePLnXjbsmlUWWocMWe3kt5s
	cZQBydl5es1NWm+EDsA0/4d3WvY1X1oLdgVZIn5OJND99dfByuiVeeTqr6ZvomJ8/+DM
	uPPfA91qvID0Y4BLwCVYL8h0B0v01wk5B1yJuzfZjwLTxcJizjCutXsvCGAe2zTqdlEf
	RtAWmFhxfIzEhjZ7MsVX6T1U6P4p1RGTfmnfHJQFlKxuzAKMySf9oWhrCNiSTPQhBOci
	HXy+Xf1c6lyZupKtchGCwV/rtda8D898IT93Fm0meIqA1NRIZvDHZx+Gq8sD8v0rOuYZ
	dAVQ==
MIME-Version: 1.0
Received: by 10.112.44.42 with SMTP id b10mr5672068lbm.31.1335540211662; Fri,
	27 Apr 2012 08:23:31 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 08:23:31 -0700 (PDT)
X-Originating-IP: [174.234.81.129]
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 08:23:31 -0700 (PDT)
In-Reply-To: <CBC073A6.3F0F5%keir@xen.org>
References: <4F9AB1F90200007800080769@nat28.tlf.novell.com>
	<CBC073A6.3F0F5%keir@xen.org>
Date: Fri, 27 Apr 2012 08:23:31 -0700
Message-ID: <CAB10MZDNy2i39+=3g6j1q32wEZkJ0R6NL4a7nvOWLTXr0axcWg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Keir Fraser <keir@xen.org>
X-Gm-Message-State: ALoCoQkVUmaCZ4SHvv3oRUDTFlcJfi6MspAattjg48vZ7t/JbBjFZ+BILnlfWygL90JWRRG7Jkh/
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] [v3] xen/x86: Add FS and GS base to
	HVM VCPU context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============4860593334940739884=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4860593334940739884==
Content-Type: multipart/alternative; boundary=bcaec555543ae63f9704beaaaf33

--bcaec555543ae63f9704beaaaf33
Content-Type: text/plain; charset=ISO-8859-1

On Apr 27, 2012 8:02 AM, "Keir Fraser" <keir@xen.org> wrote:
>
> On 27/04/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>>> On 25.04.12 at 20:38, Aravindh Puthiyaparambil <aravindh@virtuata.com
>
> >>>> wrote:
> >> Add FS and GS base to the HVM VCPU context returned by
xc_vcpu_getcontext()
> >
> > Given that we're in feature freeze right now - is this actually fixing
some
> > shortcoming somewhere? Otherwise it may need to wait until 4.2 is out.
>
> I think we can make a judgement call on this one that it is obviously safe
> to check it in. Even if the patch is buggy, it's only filling in data
fields
> with garbage, which were uninitialised garbage in the first place.
>

It will be helpful if this can make it into 4.2. It does provide useful
info for Windows guests.

Thanks,
Aravindh

>  -- Keir
>
> > Jan
> >
> >> Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >>
> >> diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c
> >> --- a/xen/arch/x86/domctl.c Wed Apr 25 11:35:29 2012 -0700
> >> +++ b/xen/arch/x86/domctl.c Wed Apr 25 11:35:43 2012 -0700
> >> @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *v,
> >>          c.nat->user_regs.es = sreg.sel;
> >>          hvm_get_segment_register(v, x86_seg_fs, &sreg);
> >>          c.nat->user_regs.fs = sreg.sel;
> >> +#ifdef __x86_64__
> >> +        c.nat->fs_base = sreg.base;
> >> +#endif
> >>          hvm_get_segment_register(v, x86_seg_gs, &sreg);
> >>          c.nat->user_regs.gs = sreg.sel;
> >> +#ifdef __x86_64__
> >> +        if ( ring_0(&c.nat->user_regs) )
> >> +        {
> >> +            c.nat->gs_base_kernel = sreg.base;
> >> +            c.nat->gs_base_user = hvm_get_shadow_gs_base(v);
> >> +        }
> >> +        else
> >> +        {
> >> +            c.nat->gs_base_user = sreg.base;
> >> +            c.nat->gs_base_kernel = hvm_get_shadow_gs_base(v);
> >> +        }
> >> +#endif
> >>      }
> >>      else
> >>      {
> >
> >
> >
>
>

--bcaec555543ae63f9704beaaaf33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Apr 27, 2012 8:02 AM, &quot;Keir Fraser&quot; &lt;<a href=3D"mailto:keir=
@xen.org">keir@xen.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On 27/04/2012 13:49, &quot;Jan Beulich&quot; &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;&gt;&gt;&gt; On 25.04.12 at 20:38, Aravindh Puthiyaparambil &lt;<a=
 href=3D"mailto:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt;&gt;&gt;&gt; wrote:<br>
&gt; &gt;&gt; Add FS and GS base to the HVM VCPU context returned by xc_vcp=
u_getcontext()<br>
&gt; &gt;<br>
&gt; &gt; Given that we&#39;re in feature freeze right now - is this actual=
ly fixing some<br>
&gt; &gt; shortcoming somewhere? Otherwise it may need to wait until 4.2 is=
 out.<br>
&gt;<br>
&gt; I think we can make a judgement call on this one that it is obviously =
safe<br>
&gt; to check it in. Even if the patch is buggy, it&#39;s only filling in d=
ata fields<br>
&gt; with garbage, which were uninitialised garbage in the first place.<br>
&gt;</p>
<p>It will be helpful if this can make it into 4.2. It does provide useful =
info for Windows guests.</p>
<p>Thanks,<br>
Aravindh</p>
<p>&gt; =A0-- Keir<br>
&gt;<br>
&gt; &gt; Jan<br>
&gt; &gt;<br>
&gt; &gt;&gt; Signed-off-by: Aravindh Puthiyaparambil &lt;<a href=3D"mailto=
:aravindh@virtuata.com">aravindh@virtuata.com</a>&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; diff -r be41f3b599d9 -r 1f39b9fe704f xen/arch/x86/domctl.c<br=
>
&gt; &gt;&gt; --- a/xen/arch/x86/domctl.c Wed Apr 25 11:35:29 2012 -0700<br=
>
&gt; &gt;&gt; +++ b/xen/arch/x86/domctl.c Wed Apr 25 11:35:43 2012 -0700<br=
>
&gt; &gt;&gt; @@ -1590,8 +1590,23 @@ void arch_get_info_guest(struct vcpu *=
v,<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;<a href=3D"http://user_regs.es">=
user_regs.es</a> =3D sreg.sel;<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_fs, &a=
mp;sreg);<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;user_regs.fs =3D sreg.sel;<br>
&gt; &gt;&gt; +#ifdef __x86_64__<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0c.nat-&gt;fs_base =3D sreg.base;<br>
&gt; &gt;&gt; +#endif<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0hvm_get_segment_register(v, x86_seg_gs, &a=
mp;sreg);<br>
&gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0c.nat-&gt;<a href=3D"http://user_regs.gs">=
user_regs.gs</a> =3D sreg.sel;<br>
&gt; &gt;&gt; +#ifdef __x86_64__<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0if ( ring_0(&amp;c.nat-&gt;user_regs) )<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0{<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_kernel =3D sreg.ba=
se;<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_user =3D hvm_get_s=
hadow_gs_base(v);<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0else<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0{<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_user =3D sreg.base=
;<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0 =A0 =A0c.nat-&gt;gs_base_kernel =3D hvm_get=
_shadow_gs_base(v);<br>
&gt; &gt;&gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt;&gt; +#endif<br>
&gt; &gt;&gt; =A0 =A0 =A0}<br>
&gt; &gt;&gt; =A0 =A0 =A0else<br>
&gt; &gt;&gt; =A0 =A0 =A0{<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
</p>

--bcaec555543ae63f9704beaaaf33--


--===============4860593334940739884==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4860593334940739884==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 15:29:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNn6L-0003jz-R1; Fri, 27 Apr 2012 15:28:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNn6K-0003ju-V8
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:28:53 +0000
Received: from [85.158.143.99:25564] by server-2.bemta-4.messagelabs.com id
	02/54-17550-43BBA9F4; Fri, 27 Apr 2012 15:28:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335540529!24677689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15314 invoked from network); 27 Apr 2012 15:28:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:28:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12181919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:28:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:28:27 +0100
Message-ID: <1335540505.28015.228.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 27 Apr 2012 16:28:25 +0100
In-Reply-To: <1335540025.2488.67.camel@Abyss>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335540025.2488.67.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 16:20 +0100, Dario Faggioli wrote:
> On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote: 
> > > I think what we really want to do is is any of the parameters are set, 
> > > after the domain is first created, to read the scheduling parameters for 
> > > the domain (which will be the defaults), change the ones that are set in 
> > > the config file, and then write the whole structure back.  That 
> > > shouldn't be too hard, as libxl__sched_set_params() is called after the 
> > > domain itself is created;
> > 
> > I guess the low level libxl_sched_*_params_set should take care of this?
> > 
> Possibly, but there's more I'm not sure I understand in the patch (the
> original patch, the one that has been checked-in on Wednesday):
> 
> +int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    libxl_scheduler sched;
> +    libxl_sched_sedf_domain sedf_info;
> +    libxl_sched_credit_domain credit_info;
> +    libxl_sched_credit2_domain credit2_info;
> +    int ret;
> +
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      sedf_info.period = scparams->period;
> +      sedf_info.slice = scparams->slice;
> +      sedf_info.latency = scparams->latency;
> +      sedf_info.extratime = scparams->extratime;
> +      sedf_info.weight = scparams->weight;
> +      ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      credit_info.weight = scparams->weight;
> <snip>
> 
> sched gets the return value of libxl_get_scheduler() which, if I'm not
> wrong , read the "default" xen scheduler for this boot, i.e., the one
> specified by the "sched=" boot command line or whatever the default for
> that is (credit1).
> 
> After that it decides what libxl_sched_*_domain_set() to call basing
> right on that value. What I'm missing is what prevents the domain in
> question to be part of a cpupool (e.g., by specifying "poolid=" in its
> config file as well) for which the scheduler is a different one.
> 
> It seems to me that, in such case, we will be setting the wrong set of
> parameters anyway, independently on how well we manage in putting a
> default in place for them... Am I missing something? If not, as I
> haven't found any way of finding out what scheduler is actually being
> used for a specific domain, shouldn't we add or mimic that (going
> through cpupool, perhaps, I haven't checked yet)?

I think you are right. Should we have libxl_gfet_domain_scheduler (or
some such) which implements the appropriate logic?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:29:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNn6L-0003jz-R1; Fri, 27 Apr 2012 15:28:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNn6K-0003ju-V8
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:28:53 +0000
Received: from [85.158.143.99:25564] by server-2.bemta-4.messagelabs.com id
	02/54-17550-43BBA9F4; Fri, 27 Apr 2012 15:28:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335540529!24677689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15314 invoked from network); 27 Apr 2012 15:28:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:28:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12181919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:28:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:28:27 +0100
Message-ID: <1335540505.28015.228.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 27 Apr 2012 16:28:25 +0100
In-Reply-To: <1335540025.2488.67.camel@Abyss>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335540025.2488.67.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 16:20 +0100, Dario Faggioli wrote:
> On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote: 
> > > I think what we really want to do is is any of the parameters are set, 
> > > after the domain is first created, to read the scheduling parameters for 
> > > the domain (which will be the defaults), change the ones that are set in 
> > > the config file, and then write the whole structure back.  That 
> > > shouldn't be too hard, as libxl__sched_set_params() is called after the 
> > > domain itself is created;
> > 
> > I guess the low level libxl_sched_*_params_set should take care of this?
> > 
> Possibly, but there's more I'm not sure I understand in the patch (the
> original patch, the one that has been checked-in on Wednesday):
> 
> +int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    libxl_scheduler sched;
> +    libxl_sched_sedf_domain sedf_info;
> +    libxl_sched_credit_domain credit_info;
> +    libxl_sched_credit2_domain credit2_info;
> +    int ret;
> +
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      sedf_info.period = scparams->period;
> +      sedf_info.slice = scparams->slice;
> +      sedf_info.latency = scparams->latency;
> +      sedf_info.extratime = scparams->extratime;
> +      sedf_info.weight = scparams->weight;
> +      ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      credit_info.weight = scparams->weight;
> <snip>
> 
> sched gets the return value of libxl_get_scheduler() which, if I'm not
> wrong , read the "default" xen scheduler for this boot, i.e., the one
> specified by the "sched=" boot command line or whatever the default for
> that is (credit1).
> 
> After that it decides what libxl_sched_*_domain_set() to call basing
> right on that value. What I'm missing is what prevents the domain in
> question to be part of a cpupool (e.g., by specifying "poolid=" in its
> config file as well) for which the scheduler is a different one.
> 
> It seems to me that, in such case, we will be setting the wrong set of
> parameters anyway, independently on how well we manage in putting a
> default in place for them... Am I missing something? If not, as I
> haven't found any way of finding out what scheduler is actually being
> used for a specific domain, shouldn't we add or mimic that (going
> through cpupool, perhaps, I haven't checked yet)?

I think you are right. Should we have libxl_gfet_domain_scheduler (or
some such) which implements the appropriate logic?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:35:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:35:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnCl-0003tV-NR; Fri, 27 Apr 2012 15:35:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SNnCj-0003tQ-Ot
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:35:30 +0000
Received: from [193.109.254.147:17366] by server-11.bemta-14.messagelabs.com
	id FE/D6-05858-1CCBA9F4; Fri, 27 Apr 2012 15:35:29 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335540927!4219720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21753 invoked from network); 27 Apr 2012 15:35:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:35:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; 
   d="scan'";a="12182050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:35:26 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:35:26 +0100
Message-ID: <1335540924.2488.73.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 27 Apr 2012 17:35:24 +0200
In-Reply-To: <1335540505.28015.228.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335540025.2488.67.camel@Abyss>
	<1335540505.28015.228.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3719922256132598410=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3719922256132598410==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-dWJhboYq9NnaZ4qAzlqf"

--=-dWJhboYq9NnaZ4qAzlqf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-27 at 16:28 +0100, Ian Campbell wrote:=20
> > It seems to me that, in such case, we will be setting the wrong set of
> > parameters anyway, independently on how well we manage in putting a
> > default in place for them... Am I missing something? If not, as I
> > haven't found any way of finding out what scheduler is actually being
> > used for a specific domain, shouldn't we add or mimic that (going
> > through cpupool, perhaps, I haven't checked yet)?
>=20
> I think you are right. Should we have libxl_gfet_domain_scheduler (or
> some such) which implements the appropriate logic?
>=20
If we want to keep the patch (and I'm sure we want, as having the
possibility to set scheduling parameters in the config file kills a
regression against xm, and it's a very nice feature after all :-D) I
think we should.

I can look into that if you want. I'm also trying to figure out if a
default value for the various parameters of the various scheduler can be
"elected". It doesn't look like an easy thing to do, e.g., consider sedf
wants time values for "period" and "slice", so virtually any unsigned
value is meaningful, although, yes, period=3D0 or slice=3D0 barely make
sense, and thus maybe we can use these...

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-dWJhboYq9NnaZ4qAzlqf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+avLwACgkQk4XaBE3IOsQdrQCgo1KUl7ac+uPDjRi/gJ4gX0qo
G6IAoIy+WPwakaIu33vxAelFm7D5giGp
=8YBm
-----END PGP SIGNATURE-----

--=-dWJhboYq9NnaZ4qAzlqf--


--===============3719922256132598410==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3719922256132598410==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 15:35:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:35:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnCl-0003tV-NR; Fri, 27 Apr 2012 15:35:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1SNnCj-0003tQ-Ot
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:35:30 +0000
Received: from [193.109.254.147:17366] by server-11.bemta-14.messagelabs.com
	id FE/D6-05858-1CCBA9F4; Fri, 27 Apr 2012 15:35:29 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1335540927!4219720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21753 invoked from network); 27 Apr 2012 15:35:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:35:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; 
   d="scan'";a="12182050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:35:26 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:35:26 +0100
Message-ID: <1335540924.2488.73.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 27 Apr 2012 17:35:24 +0200
In-Reply-To: <1335540505.28015.228.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335540025.2488.67.camel@Abyss>
	<1335540505.28015.228.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3719922256132598410=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3719922256132598410==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-dWJhboYq9NnaZ4qAzlqf"

--=-dWJhboYq9NnaZ4qAzlqf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-04-27 at 16:28 +0100, Ian Campbell wrote:=20
> > It seems to me that, in such case, we will be setting the wrong set of
> > parameters anyway, independently on how well we manage in putting a
> > default in place for them... Am I missing something? If not, as I
> > haven't found any way of finding out what scheduler is actually being
> > used for a specific domain, shouldn't we add or mimic that (going
> > through cpupool, perhaps, I haven't checked yet)?
>=20
> I think you are right. Should we have libxl_gfet_domain_scheduler (or
> some such) which implements the appropriate logic?
>=20
If we want to keep the patch (and I'm sure we want, as having the
possibility to set scheduling parameters in the config file kills a
regression against xm, and it's a very nice feature after all :-D) I
think we should.

I can look into that if you want. I'm also trying to figure out if a
default value for the various parameters of the various scheduler can be
"elected". It doesn't look like an easy thing to do, e.g., consider sedf
wants time values for "period" and "slice", so virtually any unsigned
value is meaningful, although, yes, period=3D0 or slice=3D0 barely make
sense, and thus maybe we can use these...

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-dWJhboYq9NnaZ4qAzlqf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk+avLwACgkQk4XaBE3IOsQdrQCgo1KUl7ac+uPDjRi/gJ4gX0qo
G6IAoIy+WPwakaIu33vxAelFm7D5giGp
=8YBm
-----END PGP SIGNATURE-----

--=-dWJhboYq9NnaZ4qAzlqf--


--===============3719922256132598410==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3719922256132598410==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 15:38:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:38:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnFj-0003yf-AZ; Fri, 27 Apr 2012 15:38:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNnFh-0003yZ-EL
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:38:33 +0000
Received: from [85.158.138.51:18833] by server-8.bemta-3.messagelabs.com id
	70/4F-24428-87DBA9F4; Fri, 27 Apr 2012 15:38:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335541111!16235003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22608 invoked from network); 27 Apr 2012 15:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12182090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:38:29 +0100
Message-ID: <1335541108.28015.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 27 Apr 2012 16:38:28 +0100
In-Reply-To: <1335540924.2488.73.camel@Abyss>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335540025.2488.67.camel@Abyss>
	<1335540505.28015.228.camel@zakaz.uk.xensource.com>
	<1335540924.2488.73.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 16:35 +0100, Dario Faggioli wrote:
> On Fri, 2012-04-27 at 16:28 +0100, Ian Campbell wrote: 
> > > It seems to me that, in such case, we will be setting the wrong set of
> > > parameters anyway, independently on how well we manage in putting a
> > > default in place for them... Am I missing something? If not, as I
> > > haven't found any way of finding out what scheduler is actually being
> > > used for a specific domain, shouldn't we add or mimic that (going
> > > through cpupool, perhaps, I haven't checked yet)?
> > 
> > I think you are right. Should we have libxl_gfet_domain_scheduler (or
> > some such) which implements the appropriate logic?
> > 
> If we want to keep the patch (and I'm sure we want, as having the
> possibility to set scheduling parameters in the config file kills a
> regression against xm, and it's a very nice feature after all :-D) I
> think we should.
> 
> I can look into that if you want. I'm also trying to figure out if a
> default value for the various parameters of the various scheduler can be
> "elected". It doesn't look like an easy thing to do, e.g., consider sedf
> wants time values for "period" and "slice", so virtually any unsigned
> value is meaningful, although, yes, period=0 or slice=0 barely make
> sense, and thus maybe we can use these...

There's always ~(TYPE)0 for whatever the type is...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:38:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:38:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnFj-0003yf-AZ; Fri, 27 Apr 2012 15:38:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNnFh-0003yZ-EL
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:38:33 +0000
Received: from [85.158.138.51:18833] by server-8.bemta-3.messagelabs.com id
	70/4F-24428-87DBA9F4; Fri, 27 Apr 2012 15:38:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1335541111!16235003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22608 invoked from network); 27 Apr 2012 15:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12182090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 15:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 16:38:29 +0100
Message-ID: <1335541108.28015.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 27 Apr 2012 16:38:28 +0100
In-Reply-To: <1335540924.2488.73.camel@Abyss>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335540025.2488.67.camel@Abyss>
	<1335540505.28015.228.camel@zakaz.uk.xensource.com>
	<1335540924.2488.73.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dieter Bloms <dieter@bloms.de>, Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 16:35 +0100, Dario Faggioli wrote:
> On Fri, 2012-04-27 at 16:28 +0100, Ian Campbell wrote: 
> > > It seems to me that, in such case, we will be setting the wrong set of
> > > parameters anyway, independently on how well we manage in putting a
> > > default in place for them... Am I missing something? If not, as I
> > > haven't found any way of finding out what scheduler is actually being
> > > used for a specific domain, shouldn't we add or mimic that (going
> > > through cpupool, perhaps, I haven't checked yet)?
> > 
> > I think you are right. Should we have libxl_gfet_domain_scheduler (or
> > some such) which implements the appropriate logic?
> > 
> If we want to keep the patch (and I'm sure we want, as having the
> possibility to set scheduling parameters in the config file kills a
> regression against xm, and it's a very nice feature after all :-D) I
> think we should.
> 
> I can look into that if you want. I'm also trying to figure out if a
> default value for the various parameters of the various scheduler can be
> "elected". It doesn't look like an easy thing to do, e.g., consider sedf
> wants time values for "period" and "slice", so virtually any unsigned
> value is meaningful, although, yes, period=0 or slice=0 barely make
> sense, and thus maybe we can use these...

There's always ~(TYPE)0 for whatever the type is...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:54:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnUI-0004GU-1D; Fri, 27 Apr 2012 15:53:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SNnUG-0004GP-Il
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:53:36 +0000
Received: from [85.158.143.35:40932] by server-3.bemta-4.messagelabs.com id
	3C/AD-05853-FF0CA9F4; Fri, 27 Apr 2012 15:53:35 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335542013!14619055!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10860 invoked from network); 27 Apr 2012 15:53:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	27 Apr 2012 15:53:34 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3RFrMsQ000656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 11:53:22 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3RFrJUg031378; Fri, 27 Apr 2012 11:53:20 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 084B318D495; Fri, 27 Apr 2012 18:53:19 +0300 (IDT)
Date: Fri, 27 Apr 2012 18:53:18 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120427155318.GI6833@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
	<4F9A78CF.7070005@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9A78CF.7070005@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 04:15:35PM +0530, Raghavendra K T wrote:
> On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> >On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
> >>From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
> >>
> >>KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
> >>
> >>The presence of these hypercalls is indicated to guest via
> >>KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> >>
> >>Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
> >>Signed-off-by: Suzuki Poulose<suzuki@in.ibm.com>
> >>Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
> >>---
> [...]
> >>+/*
> >>+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
> >>+ *
> >>+ * @apicid - apicid of vcpu to be kicked.
> >>+ */
> >>+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> >>+{
> >>+	struct kvm_vcpu *vcpu = NULL;
> >>+	int i;
> >>+
> >>+	kvm_for_each_vcpu(i, vcpu, kvm) {
> >>+		if (!kvm_apic_present(vcpu))
> >>+			continue;
> >>+
> >>+		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> >>+			break;
> >>+	}
> >>+	if (vcpu) {
> >>+		/*
> >>+		 * Setting unhalt flag here can result in spurious runnable
> >>+		 * state when unhalt reset does not happen in vcpu_block.
> >>+		 * But that is harmless since that should soon result in halt.
> >>+		 */
> >>+		vcpu->arch.pv.pv_unhalted = 1;
> >>+		/* We need everybody see unhalt before vcpu unblocks */
> >>+		smp_mb();
> >>+		kvm_vcpu_kick(vcpu);
> >>+	}
> >>+}
> >This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> >can use one of reserved delivery modes as PV delivery mode. We will
> >disallow guest to trigger it through apic interface, so this will not be
> >part of ABI and can be changed at will.
> >
> 
> I think it is interesting ( Perhaps more reasonable way of doing it).
> I am not too familiar with lapic source. So, pardon me if my
> questions are stupid.
> 
> Something like below is what I deciphered from your suggestion which
> is working.
> 
> kvm/x86.c
> =========
> kvm_pv_kick_cpu_op()
> {
> 
>  struct kvm_lapic_irq lapic_irq;
> 
>  lapic_irq.shorthand = 0;
>  lapic_irq.dest_mode = 0;
>  lapic_irq.dest_id = apicid;
> 
>  lapic_irq.delivery_mode = PV_DELIVERY_MODE;
>  kvm_irq_delivery_to_apic(kvm, 0, &lapic_irq );
> 
> }
> 
> kvm/lapic.c
> ==========
> _apic_accept_irq()
> {
> ...
> case APIC_DM_REMRD:
>                 result = 1;
>                 vcpu->pv_unhalted = 1
>                 smp_mb();
>                 kvm_make_request(KVM_REQ_EVENT, vcpu);
>                 kvm_vcpu_kick(vcpu);
>                 break;
> 
> ...
> }
> 
> here using PV_DELIVERY_MODE = APIC_DM_REMRD, which was unused.
> 
Yes, this is what I mean except that PV_DELIVERY_MODE should be
number defined as reserved by Intel spec.

> OR
> 1) Are you asking to remove vcpu->pv_unhalted flag and replace with an irq?
I would like to remove vcpu->pv_unhalted, but do not see how to do that,
so I do not asking that :)
 
> 2) are you talking about some reserved fields in struct local_apic instead
> of APIC_DM_REMRD what I have used above?
Delivery modes 011b and 111b are reserved. We can use one if them.

> [ Honestly, arch/x86/include/asm/apicdef.h had too much of info to
> digest :( ]
> 
> 3) I am not sure about: disallow guest to trigger it through apic
> interface part also.(mean howto?)
I mean we should disallow guest to set delivery mode to reserved values
through apic interface.

> 4) And one more question, So you think it takes care of migration part
>   (in case we are removing pv_unhalted flag)?
No, since I am not asking for removing pv_unhalted flag. I want to reuse
code that we already have to deliver the unhalt event.

> 
> It would be helpful if you can give little more explanation/ pointer
> to Documentation.
> 
> Ingo is keen to see whole ticketlock/Xen/KVM patch in one go.
> and anyhow since this does not cause any ABI change, I hope you
> don't mind if
> I do only the vcpu->pv_unhalted change you suggested now [ having
> pv_unhalted reset  in vcpu_run if
> you meant something else than code I have above ], so that whole
> series get fair amount time for testing.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 15:54:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 15:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnUI-0004GU-1D; Fri, 27 Apr 2012 15:53:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SNnUG-0004GP-Il
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 15:53:36 +0000
Received: from [85.158.143.35:40932] by server-3.bemta-4.messagelabs.com id
	3C/AD-05853-FF0CA9F4; Fri, 27 Apr 2012 15:53:35 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1335542013!14619055!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NDQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10860 invoked from network); 27 Apr 2012 15:53:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	27 Apr 2012 15:53:34 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3RFrMsQ000656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Apr 2012 11:53:22 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3RFrJUg031378; Fri, 27 Apr 2012 11:53:20 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 084B318D495; Fri, 27 Apr 2012 18:53:19 +0300 (IDT)
Date: Fri, 27 Apr 2012 18:53:18 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120427155318.GI6833@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
	<4F9A78CF.7070005@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9A78CF.7070005@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 04:15:35PM +0530, Raghavendra K T wrote:
> On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> >On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
> >>From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
> >>
> >>KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
> >>
> >>The presence of these hypercalls is indicated to guest via
> >>KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
> >>
> >>Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
> >>Signed-off-by: Suzuki Poulose<suzuki@in.ibm.com>
> >>Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
> >>---
> [...]
> >>+/*
> >>+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
> >>+ *
> >>+ * @apicid - apicid of vcpu to be kicked.
> >>+ */
> >>+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> >>+{
> >>+	struct kvm_vcpu *vcpu = NULL;
> >>+	int i;
> >>+
> >>+	kvm_for_each_vcpu(i, vcpu, kvm) {
> >>+		if (!kvm_apic_present(vcpu))
> >>+			continue;
> >>+
> >>+		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> >>+			break;
> >>+	}
> >>+	if (vcpu) {
> >>+		/*
> >>+		 * Setting unhalt flag here can result in spurious runnable
> >>+		 * state when unhalt reset does not happen in vcpu_block.
> >>+		 * But that is harmless since that should soon result in halt.
> >>+		 */
> >>+		vcpu->arch.pv.pv_unhalted = 1;
> >>+		/* We need everybody see unhalt before vcpu unblocks */
> >>+		smp_mb();
> >>+		kvm_vcpu_kick(vcpu);
> >>+	}
> >>+}
> >This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> >can use one of reserved delivery modes as PV delivery mode. We will
> >disallow guest to trigger it through apic interface, so this will not be
> >part of ABI and can be changed at will.
> >
> 
> I think it is interesting ( Perhaps more reasonable way of doing it).
> I am not too familiar with lapic source. So, pardon me if my
> questions are stupid.
> 
> Something like below is what I deciphered from your suggestion which
> is working.
> 
> kvm/x86.c
> =========
> kvm_pv_kick_cpu_op()
> {
> 
>  struct kvm_lapic_irq lapic_irq;
> 
>  lapic_irq.shorthand = 0;
>  lapic_irq.dest_mode = 0;
>  lapic_irq.dest_id = apicid;
> 
>  lapic_irq.delivery_mode = PV_DELIVERY_MODE;
>  kvm_irq_delivery_to_apic(kvm, 0, &lapic_irq );
> 
> }
> 
> kvm/lapic.c
> ==========
> _apic_accept_irq()
> {
> ...
> case APIC_DM_REMRD:
>                 result = 1;
>                 vcpu->pv_unhalted = 1
>                 smp_mb();
>                 kvm_make_request(KVM_REQ_EVENT, vcpu);
>                 kvm_vcpu_kick(vcpu);
>                 break;
> 
> ...
> }
> 
> here using PV_DELIVERY_MODE = APIC_DM_REMRD, which was unused.
> 
Yes, this is what I mean except that PV_DELIVERY_MODE should be
number defined as reserved by Intel spec.

> OR
> 1) Are you asking to remove vcpu->pv_unhalted flag and replace with an irq?
I would like to remove vcpu->pv_unhalted, but do not see how to do that,
so I do not asking that :)
 
> 2) are you talking about some reserved fields in struct local_apic instead
> of APIC_DM_REMRD what I have used above?
Delivery modes 011b and 111b are reserved. We can use one if them.

> [ Honestly, arch/x86/include/asm/apicdef.h had too much of info to
> digest :( ]
> 
> 3) I am not sure about: disallow guest to trigger it through apic
> interface part also.(mean howto?)
I mean we should disallow guest to set delivery mode to reserved values
through apic interface.

> 4) And one more question, So you think it takes care of migration part
>   (in case we are removing pv_unhalted flag)?
No, since I am not asking for removing pv_unhalted flag. I want to reuse
code that we already have to deliver the unhalt event.

> 
> It would be helpful if you can give little more explanation/ pointer
> to Documentation.
> 
> Ingo is keen to see whole ticketlock/Xen/KVM patch in one go.
> and anyhow since this does not cause any ABI change, I hope you
> don't mind if
> I do only the vcpu->pv_unhalted change you suggested now [ having
> pv_unhalted reset  in vcpu_run if
> you meant something else than code I have above ], so that whole
> series get fair amount time for testing.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 16:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 16:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnlg-0004xn-O5; Fri, 27 Apr 2012 16:11:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNnlf-0004xi-9D
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 16:11:35 +0000
Received: from [85.158.143.99:4737] by server-3.bemta-4.messagelabs.com id
	FD/6F-05853-635CA9F4; Fri, 27 Apr 2012 16:11:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335543093!22217612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19573 invoked from network); 27 Apr 2012 16:11:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 16:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12183180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 16:11:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 17:11:04 +0100
Message-ID: <1335543062.28015.234.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 17:11:02 +0100
In-Reply-To: <CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 16:58 +0100, misiu godfrey wrote:
> 
> 
> On Fri, Apr 27, 2012 at 8:23 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
> 
>         > Are you using the staging or non-staging version? What was
>         the exact URL 
>         > you cloned?
> 
> 
> I have, to my knowledge, been using the non-staging version.
> The exact URL I have been cloning is:
> "http://xenbits.xen.org/hg/xen-4.1-testing.hg"

That is the non-staging tree, good.


>         [...]
>         > + git checkout -b dummy
>         a2d2123a7dfc4d116011d51f48df786a3b853537
>         > fatal: reference is not a tree:
>         > a2d2123a7dfc4d116011d51f48df786a3b853537
>         
>         
>         This seems to be there now and it "works for me" (tm). Might
>         just have
>         been skew with the staging tree -- can you try again?
> 
> 
> I just re-ran "make world" on both of my machines to the
> same erroneous result.  Specifically, I am running two Debian 6
> machines, one of which is in a VMware virtual machine running over
> Windows 7 (for testing), and the other is a Sun Ultra 40.

I use Debian 6 too, without issue, so I surmise this isn't a git issue.

If you cd into the ioemu-remote dir then what do:
	git show a2d2123a7dfc4d116011d51f48df786a3b853537
	git show origin/master
say?

What happens if you then run "git fetch origin" in that dir?

>From the top-level what does "make tools/ioemu-dir-force-update" do?

Last resort you could try nuking the ioemu-remote dir and rebuilding.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 16:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 16:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNnlg-0004xn-O5; Fri, 27 Apr 2012 16:11:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNnlf-0004xi-9D
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 16:11:35 +0000
Received: from [85.158.143.99:4737] by server-3.bemta-4.messagelabs.com id
	FD/6F-05853-635CA9F4; Fri, 27 Apr 2012 16:11:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1335543093!22217612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19573 invoked from network); 27 Apr 2012 16:11:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 16:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="12183180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 16:11:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 17:11:04 +0100
Message-ID: <1335543062.28015.234.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 17:11:02 +0100
In-Reply-To: <CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 16:58 +0100, misiu godfrey wrote:
> 
> 
> On Fri, Apr 27, 2012 at 8:23 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
> 
>         > Are you using the staging or non-staging version? What was
>         the exact URL 
>         > you cloned?
> 
> 
> I have, to my knowledge, been using the non-staging version.
> The exact URL I have been cloning is:
> "http://xenbits.xen.org/hg/xen-4.1-testing.hg"

That is the non-staging tree, good.


>         [...]
>         > + git checkout -b dummy
>         a2d2123a7dfc4d116011d51f48df786a3b853537
>         > fatal: reference is not a tree:
>         > a2d2123a7dfc4d116011d51f48df786a3b853537
>         
>         
>         This seems to be there now and it "works for me" (tm). Might
>         just have
>         been skew with the staging tree -- can you try again?
> 
> 
> I just re-ran "make world" on both of my machines to the
> same erroneous result.  Specifically, I am running two Debian 6
> machines, one of which is in a VMware virtual machine running over
> Windows 7 (for testing), and the other is a Sun Ultra 40.

I use Debian 6 too, without issue, so I surmise this isn't a git issue.

If you cd into the ioemu-remote dir then what do:
	git show a2d2123a7dfc4d116011d51f48df786a3b853537
	git show origin/master
say?

What happens if you then run "git fetch origin" in that dir?

>From the top-level what does "make tools/ioemu-dir-force-update" do?

Last resort you could try nuking the ioemu-remote dir and rebuilding.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 16:31:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 16:31:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNo4U-000598-J5; Fri, 27 Apr 2012 16:31:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SNo4T-000593-7g
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 16:31:01 +0000
Received: from [193.109.254.147:30304] by server-6.bemta-14.messagelabs.com id
	5F/39-02047-4C9CA9F4; Fri, 27 Apr 2012 16:31:00 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335544258!6656046!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEzNjMwOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29666 invoked from network); 27 Apr 2012 16:30:59 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 16:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="371664624"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2012 16:30:57 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.61.119.60])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with SMTP id
	q3RGUtPQ007132; Fri, 27 Apr 2012 16:30:56 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Fri, 27 Apr 2012 19:30:55 +0300
Date: Fri, 27 Apr 2012 19:30:55 +0300
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120427163055.GA6464@US-SEA-R8XVZTX>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
	<1334949673-25632-2-git-send-email-msw@amazon.com>
	<20120427022456.GA26931@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120427022456.GA26931@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Joe Jin <joe.jin@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in
 statistics sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 07:24:56PM -0700, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 20, 2012 at 07:21:13PM +0000, Matt Wilson wrote:
> > This is a port of a patch in the XenoLinux 2.6.18 tree:
> > http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56
> > 
> > Fix blkback sysfs race
> 
> So with this patch I keep on getting this:
> 
> [  128.274290] switch: port 2(vif1.0) entered disabled state
...
> [  128.859542] BUG: scheduling while atomic: xenwatch/46/0x00000002
> 
> whenever a guest is powered off.

Oops. I hadn't had a chance to do testing of the patch, I just noticed
that the upstream version didn't have it.

I'll tweak it a bit, do some testing, and resubmit when it works.
--
msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 16:31:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 16:31:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNo4U-000598-J5; Fri, 27 Apr 2012 16:31:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SNo4T-000593-7g
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 16:31:01 +0000
Received: from [193.109.254.147:30304] by server-6.bemta-14.messagelabs.com id
	5F/39-02047-4C9CA9F4; Fri, 27 Apr 2012 16:31:00 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335544258!6656046!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEzNjMwOA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29666 invoked from network); 27 Apr 2012 16:30:59 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 16:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="371664624"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2012 16:30:57 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.61.119.60])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with SMTP id
	q3RGUtPQ007132; Fri, 27 Apr 2012 16:30:56 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Fri, 27 Apr 2012 19:30:55 +0300
Date: Fri, 27 Apr 2012 19:30:55 +0300
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120427163055.GA6464@US-SEA-R8XVZTX>
References: <1334949673-25632-1-git-send-email-msw@amazon.com>
	<1334949673-25632-2-git-send-email-msw@amazon.com>
	<20120427022456.GA26931@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120427022456.GA26931@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Joe Jin <joe.jin@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] [PATCH] xen/blkback: add locking in
 statistics sysfs show functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 07:24:56PM -0700, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 20, 2012 at 07:21:13PM +0000, Matt Wilson wrote:
> > This is a port of a patch in the XenoLinux 2.6.18 tree:
> > http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/f47c07325a56
> > 
> > Fix blkback sysfs race
> 
> So with this patch I keep on getting this:
> 
> [  128.274290] switch: port 2(vif1.0) entered disabled state
...
> [  128.859542] BUG: scheduling while atomic: xenwatch/46/0x00000002
> 
> whenever a guest is powered off.

Oops. I hadn't had a chance to do testing of the patch, I just noticed
that the upstream version didn't have it.

I'll tweak it a bit, do some testing, and resubmit when it works.
--
msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 17:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 17:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNoaO-0005Px-Ck; Fri, 27 Apr 2012 17:04:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNoaM-0005Ps-Ib
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 17:03:58 +0000
Received: from [85.158.139.83:40791] by server-8.bemta-5.messagelabs.com id
	B3/57-26964-D71DA9F4; Fri, 27 Apr 2012 17:03:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335546236!21563659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2333 invoked from network); 27 Apr 2012 17:03:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 17:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="12183821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 17:03:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Apr 2012 18:03:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNoaK-0002iR-6Z;
	Fri, 27 Apr 2012 17:03:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNoaK-0005Ur-22;
	Fri, 27 Apr 2012 18:03:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12759-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Apr 2012 18:03:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12759: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12759 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12759/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12757
 test-i386-i386-xl             5 xen-boot                    fail pass in 12752
 test-i386-i386-pv             5 xen-boot                    fail pass in 12757
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12757 pass in 12759
 test-amd64-amd64-xl           5 xen-boot           fail in 12757 pass in 12759
 test-amd64-amd64-pv           5 xen-boot           fail in 12757 pass in 12759

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 17:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 17:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNoaO-0005Px-Ck; Fri, 27 Apr 2012 17:04:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNoaM-0005Ps-Ib
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 17:03:58 +0000
Received: from [85.158.139.83:40791] by server-8.bemta-5.messagelabs.com id
	B3/57-26964-D71DA9F4; Fri, 27 Apr 2012 17:03:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1335546236!21563659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2333 invoked from network); 27 Apr 2012 17:03:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 17:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="12183821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 17:03:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Apr 2012 18:03:56 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNoaK-0002iR-6Z;
	Fri, 27 Apr 2012 17:03:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNoaK-0005Ur-22;
	Fri, 27 Apr 2012 18:03:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12759-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Apr 2012 18:03:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12759: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12759 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12759/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12757
 test-i386-i386-xl             5 xen-boot                    fail pass in 12752
 test-i386-i386-pv             5 xen-boot                    fail pass in 12757
 test-amd64-i386-pv            5 xen-boot                    fail pass in 12739
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12757 pass in 12759
 test-amd64-amd64-xl           5 xen-boot           fail in 12757 pass in 12759
 test-amd64-amd64-pv           5 xen-boot           fail in 12757 pass in 12759

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl            5 xen-boot              fail in 12739 like 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                41f45f5e60e6db84898b609f7f62ace90f842fdd
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 17:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 17:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNp7I-0005tF-DU; Fri, 27 Apr 2012 17:38:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christian.limpach@gmail.com>) id 1SNp7H-0005tA-3H
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 17:37:59 +0000
Received: from [85.158.143.35:21639] by server-3.bemta-4.messagelabs.com id
	57/F9-05853-679DA9F4; Fri, 27 Apr 2012 17:37:58 +0000
X-Env-Sender: christian.limpach@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335548276!13772583!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1552 invoked from network); 27 Apr 2012 17:37:57 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 17:37:57 -0000
Received: by qaeb19 with SMTP id b19so556148qae.11
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 10:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:content-transfer-encoding;
	bh=uu4drfQz+hVtiJNDOXIj6YUpdMFxpeZthV+nhjPoSxM=;
	b=x6M6bVz2O3MNkiIfCUEa49f1p6Y1l5a1Vwn5sOG/wZMy5zJkKuUA5eZxL3dxozSVAe
	+1MDa7I0heQdhlYGiqogQ+zuQD8JvX32aCTGrNmbzpLdHP1nfi967JublOtYQYm7MUN3
	5z25bL+O9ceoU/+OlNLqn523dIiMRezJAvpJn73RiEfhB08zoJMvh9ucDsnlP+WB/YM1
	tSdclydH1XL8lEZYLPOvMRTr8tgwc6Ix5WQtmk21CoO13R64ihQYRmOvd6k26vNFe+RP
	6ZsogAj54/q58FZaPyX//22sh14uOyioGsKzmNTBUmQaw9lYQc4idn2knDz3ZBLrQWsR
	zLNQ==
MIME-Version: 1.0
Received: by 10.224.182.130 with SMTP id cc2mr5740100qab.27.1335548275705;
	Fri, 27 Apr 2012 10:37:55 -0700 (PDT)
Received: by 10.229.184.11 with HTTP; Fri, 27 Apr 2012 10:37:55 -0700 (PDT)
In-Reply-To: <CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
Date: Fri, 27 Apr 2012 10:37:55 -0700
Message-ID: <CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
From: Christian Limpach <christian.limpach@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Christian.Limpach@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
>
> On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.com>
> wrote:
>>
>> Maybe you can do something similar, for example passing in a hint
>> whether ept_sync_domain needs to be done or not. =A0In my case, the
>> reasoning is that all the entries changed from hap_clean_vram_tracking
>> are leaf entries, so ept_free_entry will never be called and thus
>> ept_sync_domain can be deferred. =A0I didn't think through/consider the
>> iommu case since that code is commented out in my tree.
>
> I thought about doing that initially. But then in the bulk case I would
> always have to call ept_sync_domain() to be on the safe side. But if the
> iommu case forces me down that path, then I guess I have no choice.

I think you should re-consider.  It would avoid adding the extra
wrapper, which makes this code a lot less readable.  Plus it avoids
the need for the old_entries array.

Let me re-iterate:
- if it's a leaf entry, then there's no need to call ept_free_entry
- if you don't need to call ept_free_entry, then you can defer
ept_sync_domain (subject to the iommu case)
- you could pass in a pointer to a bool to indicate to the caller that
ept_sync_domain was deferred and that the caller needs to do it, with
a NULL pointer indicating that the caller doesn't support defer

     christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 17:38:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 17:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNp7I-0005tF-DU; Fri, 27 Apr 2012 17:38:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <christian.limpach@gmail.com>) id 1SNp7H-0005tA-3H
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 17:37:59 +0000
Received: from [85.158.143.35:21639] by server-3.bemta-4.messagelabs.com id
	57/F9-05853-679DA9F4; Fri, 27 Apr 2012 17:37:58 +0000
X-Env-Sender: christian.limpach@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335548276!13772583!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1552 invoked from network); 27 Apr 2012 17:37:57 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 17:37:57 -0000
Received: by qaeb19 with SMTP id b19so556148qae.11
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 10:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:content-transfer-encoding;
	bh=uu4drfQz+hVtiJNDOXIj6YUpdMFxpeZthV+nhjPoSxM=;
	b=x6M6bVz2O3MNkiIfCUEa49f1p6Y1l5a1Vwn5sOG/wZMy5zJkKuUA5eZxL3dxozSVAe
	+1MDa7I0heQdhlYGiqogQ+zuQD8JvX32aCTGrNmbzpLdHP1nfi967JublOtYQYm7MUN3
	5z25bL+O9ceoU/+OlNLqn523dIiMRezJAvpJn73RiEfhB08zoJMvh9ucDsnlP+WB/YM1
	tSdclydH1XL8lEZYLPOvMRTr8tgwc6Ix5WQtmk21CoO13R64ihQYRmOvd6k26vNFe+RP
	6ZsogAj54/q58FZaPyX//22sh14uOyioGsKzmNTBUmQaw9lYQc4idn2knDz3ZBLrQWsR
	zLNQ==
MIME-Version: 1.0
Received: by 10.224.182.130 with SMTP id cc2mr5740100qab.27.1335548275705;
	Fri, 27 Apr 2012 10:37:55 -0700 (PDT)
Received: by 10.229.184.11 with HTTP; Fri, 27 Apr 2012 10:37:55 -0700 (PDT)
In-Reply-To: <CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
Date: Fri, 27 Apr 2012 10:37:55 -0700
Message-ID: <CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
From: Christian Limpach <christian.limpach@gmail.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Christian.Limpach@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
>
> On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.com>
> wrote:
>>
>> Maybe you can do something similar, for example passing in a hint
>> whether ept_sync_domain needs to be done or not. =A0In my case, the
>> reasoning is that all the entries changed from hap_clean_vram_tracking
>> are leaf entries, so ept_free_entry will never be called and thus
>> ept_sync_domain can be deferred. =A0I didn't think through/consider the
>> iommu case since that code is commented out in my tree.
>
> I thought about doing that initially. But then in the bulk case I would
> always have to call ept_sync_domain() to be on the safe side. But if the
> iommu case forces me down that path, then I guess I have no choice.

I think you should re-consider.  It would avoid adding the extra
wrapper, which makes this code a lot less readable.  Plus it avoids
the need for the old_entries array.

Let me re-iterate:
- if it's a leaf entry, then there's no need to call ept_free_entry
- if you don't need to call ept_free_entry, then you can defer
ept_sync_domain (subject to the iommu case)
- you could pass in a pointer to a bool to indicate to the caller that
ept_sync_domain was deferred and that the caller needs to do it, with
a NULL pointer indicating that the caller doesn't support defer

     christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpdd-0006F4-3o; Fri, 27 Apr 2012 18:11:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SNpdb-0006Ez-3Z
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:11:23 +0000
Received: from [85.158.143.99:53747] by server-3.bemta-4.messagelabs.com id
	7F/1A-05853-A41EA9F4; Fri, 27 Apr 2012 18:11:22 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335550279!14405460!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27863 invoked from network); 27 Apr 2012 18:11:20 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:11:20 -0000
Received: by eaaf11 with SMTP id f11so280821eaa.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AWsVVioY6zIYM+j0qPY3gC8+o/UHhAyahu+BA9S/i8g=;
	b=Igg6w2o+lSIOsQms5A1JUg7LFuGvxnQQNdUdjX2g0K5XUVr2OnM9P2cniBZcrhF0Li
	brf/eh/sCOI5mssAkSBDMGZO796GNwKDgDu3Ug+qkNBCTFv1LwoVDp08XH45LbetY86Y
	rhBnY+4L5vVIJyUpj1yzKwuheRJSAN1tj57n8Hpge6NX/Fb+soS53eGUJPT4n0tCOZSx
	9OuHNX26t6CfgTiYIu6fMbqkWf3z1xU1GVZ7l9XjAeY2Jv8fInnfAPcKc39slkJmGqzD
	JooRzSzDL18RNo9+6YUKBHCbM6zqHdsw8ZtUrqB+tDrEVoQ+7Dyd2Dg+5i4LmBSriAHH
	cyaw==
MIME-Version: 1.0
Received: by 10.14.94.193 with SMTP id n41mr3046406eef.27.1335550279218; Fri,
	27 Apr 2012 11:11:19 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Fri, 27 Apr 2012 11:11:19 -0700 (PDT)
In-Reply-To: <CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
Date: Fri, 27 Apr 2012 20:11:19 +0200
Message-ID: <CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1592711413674331942=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1592711413674331942==
Content-Type: multipart/alternative; boundary=bcaec52be87df8f92704bead0730

--bcaec52be87df8f92704bead0730
Content-Type: text/plain; charset=ISO-8859-1

Ian,

Please see some of the output you have requested below.


>> What does your guest config look like now that you have resolved the
>> pygrub issue?
>>
>
 disk = [
'file:/home/sandi/oi151a.iso,xvdc:cdrom,r',
'phy:/dev/xen-dom0/oi_boot,xvda,w',
]

 vif = ['bridge=eth0,mac=00:16:3e:00:8f:d8']

 vcpus = 2
 cpus = "2-3"
 memory = 2048
 name = "oi"

 kernel = "/etc/xen/kernels/oi151a/unix"
 ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
 extra = "/platform/i86xpv/kernel/amd64/unix -B console=ttya"

 on_shutdown = "destroy"
 on_reboot = "restart"
 on_crash = "destroy"

 pci = [ '05:00.0' ]



>
>
>>
>> Can you provide a full log of the failing boot with a vif enabled to the
>> point of the hang?
>>
>>
I will send these logs if you like, if the data I have included here is of
not help.



>> What does "brctl show" say while the guest is running (with the vif
>> enabled)?
>>
>> What does "xenstore-ls -fp" show while the guest is sat waiting?
>>
>
> [root@xen-srv sandi]# brctl show
bridge name bridge id STP enabled interfaces

[root@xen-srv sandi]# xenstore-ls -fp
/tool = ""   (n0)
/tool/xenstored = ""   (n0)
/local = ""   (n0)
/local/domain = ""   (n0)
/local/domain/0 = ""   (n0)
/local/domain/0/name = "Domain-0"   (n0)
/local/domain/0/memory = ""   (n0)
/local/domain/0/memory/target = "2097152"   (n0)
/local/domain/0/memory/static-max = "2097152"   (n0)
/local/domain/0/memory/freemem-slack = "3773506"   (n0)
/local/domain/0/device-model = ""   (n0)
/local/domain/0/device-model/2 = ""   (n0)
/local/domain/0/device-model/2/state = "running"   (n0)
/local/domain/0/backend = ""   (n0)
/local/domain/0/backend/qdisk = ""   (n0)
/local/domain/0/backend/qdisk/2 = ""   (n0)
/local/domain/0/backend/qdisk/2/51744 = ""   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/frontend =
"/local/domain/2/device/vbd/51744"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/params = "aio:/home/sandi/oi151a.iso"
  (n0,r2)
/local/domain/0/backend/qdisk/2/51744/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/online = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/removable = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/bootable = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/state = "4"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/dev = "xvdc"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/type = "qdisk"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/mode = "r"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/device-type = "cdrom"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/feature-barrier = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/info = "5"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/sector-size = "512"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/sectors = "1643348"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/hotplug-status = "connected"   (n0,r2)
/local/domain/0/backend/vbd = ""   (n0)
/local/domain/0/backend/vbd/2 = ""   (n0)
/local/domain/0/backend/vbd/2/51712 = ""   (n0,r2)
/local/domain/0/backend/vbd/2/51712/frontend =
"/local/domain/2/device/vbd/51712"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/physical-device = "fe:2"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/params = "/dev/xen-dom0/oi_boot"
(n0,r2)
/local/domain/0/backend/vbd/2/51712/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/online = "1"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/removable = "0"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/bootable = "1"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/state = "4"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/dev = "xvda"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/type = "phy"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/mode = "w"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/device-type = "disk"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/feature-flush-cache = "1"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/sectors = "83886080"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/info = "0"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/sector-size = "512"   (n0,r2)
/local/domain/0/backend/vif = ""   (n0)
/local/domain/0/backend/vif/2 = ""   (n0)
/local/domain/0/backend/vif/2/0 = ""   (n0,r2)
/local/domain/0/backend/vif/2/0/frontend = "/local/domain/2/device/vif/0"
(n0,r2)
/local/domain/0/backend/vif/2/0/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/vif/2/0/online = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/state = "2"   (n0,r2)
/local/domain/0/backend/vif/2/0/script = "/etc/xen/scripts/vif-bridge"
(n0,r2)
/local/domain/0/backend/vif/2/0/mac = "00:16:3e:00:8f:d8"   (n0,r2)
/local/domain/0/backend/vif/2/0/bridge = "eth0"   (n0,r2)
/local/domain/0/backend/vif/2/0/handle = "0"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-sg = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-gso-tcpv4 = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-rx-copy = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-rx-flip = "0"   (n0,r2)
/local/domain/0/backend/console = ""   (n0)
/local/domain/0/backend/console/2 = ""   (n0)
/local/domain/0/backend/console/2/0 = ""   (n0,r2)
/local/domain/0/backend/console/2/0/frontend = "/local/domain/2/console"
(n0,r2)
/local/domain/0/backend/console/2/0/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/console/2/0/online = "1"   (n0,r2)
/local/domain/0/backend/console/2/0/state = "4"   (n0,r2)
/local/domain/0/backend/console/2/0/domain = "oi"   (n0,r2)
/local/domain/0/backend/console/2/0/protocol = "vt100"   (n0,r2)
/local/domain/0/backend/console/2/0/hotplug-status = "connected"   (n0,r2)
/local/domain/0/backend/pci = ""   (n0)
/local/domain/0/backend/pci/2 = ""   (n0)
/local/domain/0/backend/pci/2/0 = ""   (n0,r2)
/local/domain/0/backend/pci/2/0/frontend = "/local/domain/2/device/pci/0"
(n0,r2)
/local/domain/0/backend/pci/2/0/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/pci/2/0/online = "1"   (n0,r2)
/local/domain/0/backend/pci/2/0/state = "3"   (n0,r2)
/local/domain/0/backend/pci/2/0/domain = "oi"   (n0,r2)
/local/domain/0/backend/pci/2/0/key-0 = "0000:05:00.0"   (n0,r2)
/local/domain/0/backend/pci/2/0/dev-0 = "0000:05:00.0"   (n0,r2)
/local/domain/0/backend/pci/2/0/opts-0 = "msitranslate=1,power_mgmt=0"
(n0,r2)
/local/domain/0/backend/pci/2/0/state-0 = "3"   (n0,r2)
/local/domain/0/backend/pci/2/0/num_devs = "1"   (n0,r2)
/local/domain/0/backend/pci/2/0/vdev-0 = "0000:05:00.00"   (n0,r2)
/local/domain/0/backend/pci/2/0/root-0 = "0000:05"   (n0,r2)
/local/domain/0/backend/pci/2/0/root_num = "1"   (n0,r2)
/local/domain/2 = ""   (n0,r2)
/local/domain/2/vm = "/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4"   (n0,r2)
/local/domain/2/name = "oi"   (n0,r2)
/local/domain/2/cpu = ""   (n0,r2)
/local/domain/2/cpu/0 = ""   (n0,r2)
/local/domain/2/cpu/0/availability = "online"   (n0,r2)
/local/domain/2/cpu/1 = ""   (n0,r2)
/local/domain/2/cpu/1/availability = "online"   (n0,r2)
/local/domain/2/memory = ""   (n0,r2)
/local/domain/2/memory/static-max = "2097152"   (n0,r2)
/local/domain/2/memory/target = "2097152"   (n0,r2)
/local/domain/2/memory/videoram = "0"   (n0,r2)
/local/domain/2/device = ""   (n0,r2)
/local/domain/2/device/suspend = ""   (n0,r2)
/local/domain/2/device/suspend/event-channel = ""   (n2)
/local/domain/2/device/vbd = ""   (n0,r2)
/local/domain/2/device/vbd/51744 = ""   (n2,r0)
/local/domain/2/device/vbd/51744/backend =
"/local/domain/0/backend/qdisk/2/51744"   (n2,r0)
/local/domain/2/device/vbd/51744/backend-id = "0"   (n2,r0)
/local/domain/2/device/vbd/51744/state = "4"   (n2,r0)
/local/domain/2/device/vbd/51744/virtual-device = "51744"   (n2,r0)
/local/domain/2/device/vbd/51744/device-type = "cdrom"   (n2,r0)
/local/domain/2/device/vbd/51744/media-req = "none"   (n2,r0)
/local/domain/2/device/vbd/51744/ring-ref = "266"   (n2,r0)
/local/domain/2/device/vbd/51744/event-channel = "13"   (n2,r0)
/local/domain/2/device/vbd/51744/protocol = "x86_64-abi"   (n2,r0)
/local/domain/2/device/vbd/51712 = ""   (n2,r0)
/local/domain/2/device/vbd/51712/backend =
"/local/domain/0/backend/vbd/2/51712"   (n2,r0)
/local/domain/2/device/vbd/51712/backend-id = "0"   (n2,r0)
/local/domain/2/device/vbd/51712/state = "4"   (n2,r0)
/local/domain/2/device/vbd/51712/virtual-device = "51712"   (n2,r0)
/local/domain/2/device/vbd/51712/device-type = "disk"   (n2,r0)
/local/domain/2/device/vbd/51712/media-req = "none"   (n2,r0)
/local/domain/2/device/vbd/51712/ring-ref = "267"   (n2,r0)
/local/domain/2/device/vbd/51712/event-channel = "14"   (n2,r0)
/local/domain/2/device/vbd/51712/protocol = "x86_64-abi"   (n2,r0)
/local/domain/2/device/vif = ""   (n0,r2)
/local/domain/2/device/vif/0 = ""   (n2,r0)
/local/domain/2/device/vif/0/backend = "/local/domain/0/backend/vif/2/0"
(n2,r0)
/local/domain/2/device/vif/0/backend-id = "0"   (n2,r0)
/local/domain/2/device/vif/0/state = "4"   (n2,r0)
/local/domain/2/device/vif/0/handle = "0"   (n2,r0)
/local/domain/2/device/vif/0/mac = "00:16:3e:00:8f:d8"   (n2,r0)
/local/domain/2/device/vif/0/tx-ring-ref = "8"   (n2,r0)
/local/domain/2/device/vif/0/rx-ring-ref = "9"   (n2,r0)
/local/domain/2/device/vif/0/event-channel = "12"   (n2,r0)
/local/domain/2/device/vif/0/feature-rx-notify = "1"   (n2,r0)
/local/domain/2/device/vif/0/request-rx-copy = "1"   (n2,r0)
/local/domain/2/device/pci = ""   (n0,r2)
/local/domain/2/device/pci/0 = ""   (n2,r0)
/local/domain/2/device/pci/0/backend = "/local/domain/0/backend/pci/2/0"
(n2,r0)
/local/domain/2/device/pci/0/backend-id = "0"   (n2,r0)
/local/domain/2/device/pci/0/state = "1"   (n2,r0)
/local/domain/2/control = ""   (n0,r2)
/local/domain/2/control/shutdown = ""   (n2)
/local/domain/2/control/platform-feature-multiprocessor-suspend = "1"
(n0,r2)
/local/domain/2/control/platform-feature-xs_reset_watches = "1"   (n0,r2)
/local/domain/2/data = ""   (n2)
/local/domain/2/domid = "2"   (n0,r2)
/local/domain/2/store = ""   (n0,r2)
/local/domain/2/store/port = "1"   (n0,r2)
/local/domain/2/store/ring-ref = "4891896"   (n0,r2)
/local/domain/2/console = ""   (n2,r0)
/local/domain/2/console/backend = "/local/domain/0/backend/console/2/0"
(n2,r0)
/local/domain/2/console/backend-id = "0"   (n2,r0)
/local/domain/2/console/limit = "1048576"   (n2,r0)
/local/domain/2/console/type = "ioemu"   (n2,r0)
/local/domain/2/console/output = "pty"   (n2,r0)
/local/domain/2/console/port = "2"   (n2,r0)
/local/domain/2/console/ring-ref = "4891895"   (n2,r0)
/local/domain/2/console/tty = "/dev/pts/4"   (n2,r0)
/local/domain/2/hvmloader = ""   (n0,r2)
/local/domain/2/hvmloader/bios = "rombios"   (n0,r2)
/local/domain/2/image = ""   (n0,r2)
/local/domain/2/image/device-model-pid = "4029"   (n0,r2)
/vm = ""   (n0)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4 = ""   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/uuid =
"897494e6-60a2-47e4-aaa0-826ef89d63e4"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/name = "oi"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image = ""   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ostype = "linux"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/kernel =
"/etc/xen/kernels/oi151a/unix"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ramdisk =
"/etc/xen/kernels/oi151a/boot_archive"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/cmdline =
"/platform/i86xpv/kernel/amd64/unix -B console=ttya"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/start_time = "1335549687.10"
(n0,r2)
/libxl = ""   (n0)
/libxl/2 = ""   (n0)
/libxl/2/dm-version = "qemu_xen_traditional"   (n0)


Hope this output helps out...

Best regards

Sandi

--bcaec52be87df8f92704bead0730
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Ian,</div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">Please see some of the output you have requested =
below.<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><br>
What does your guest config look like now that you have resolved the<br>
pygrub issue?<br></blockquote><div></div></div></div></div></blockquote><di=
v><br></div><div>=A0disk =3D [</div><div><span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre">	</span>&#39;file:/home/sandi/oi151a.iso,xvdc:cdrom,=
r&#39;,</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>&#39;=
phy:/dev/xen-dom0/oi_boot,xvda,w&#39;,</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre">	</span>]</div><div><br></div><div>=A0vif =
=3D [&#39;bridge=3Deth0,mac=3D00:16:3e:00:8f:d8&#39;]=A0</div>
<div><br></div><div>=A0vcpus =3D 2</div><div>=A0cpus =3D &quot;2-3&quot;</d=
iv><div>=A0memory =3D 2048</div><div>=A0name =3D &quot;oi&quot;</div><div><=
br></div><div>=A0kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot;</div><=
div>=A0ramdisk =3D &quot;/etc/xen/kernels/oi151a/boot_archive&quot;</div>
<div>=A0extra =3D &quot;/platform/i86xpv/kernel/amd64/unix -B console=3Dtty=
a&quot;</div><div><br></div><div>=A0on_shutdown =3D &quot;destroy&quot;</di=
v><div>=A0on_reboot =3D &quot;restart&quot;</div><div>=A0on_crash =3D &quot=
;destroy&quot;</div>
<div><br></div><div>=A0pci =3D [ &#39;05:00.0&#39; ]</div><div><br></div><d=
iv>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">
<div class=3D"im"><div>=A0</div></div><div class=3D"im"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<br>
Can you provide a full log of the failing boot with a vif enabled to the<br=
>
point of the hang?<br>
<br></blockquote><div></div></div><div class=3D"im"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"></blockquote></div></div></div></blockquote><div><br></div><div>I w=
ill send these logs if you like, if the data I have included here is of not=
 help.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<br>
What does &quot;brctl show&quot; say while the guest is running (with the v=
if<br>
enabled)?<br>
<br>
What does &quot;xenstore-ls -fp&quot; show while the guest is sat waiting?<=
br></blockquote><div><br></div></div></div></div></blockquote><div>[root@xe=
n-srv sandi]# brctl show</div><div>bridge name<span class=3D"Apple-tab-span=
" style=3D"white-space:pre">	</span>bridge id<span class=3D"Apple-tab-span"=
 style=3D"white-space:pre">		</span>STP enabled<span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre">	</span>interfaces</div>
<div><br></div><div>[root@xen-srv sandi]# xenstore-ls -fp</div><div>/tool =
=3D &quot;&quot; =A0 (n0)</div><div>/tool/xenstored =3D &quot;&quot; =A0 (n=
0)</div><div>/local =3D &quot;&quot; =A0 (n0)</div><div>/local/domain =3D &=
quot;&quot; =A0 (n0)</div>
<div>/local/domain/0 =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/0/na=
me =3D &quot;Domain-0&quot; =A0 (n0)</div><div>/local/domain/0/memory =3D &=
quot;&quot; =A0 (n0)</div><div>/local/domain/0/memory/target =3D &quot;2097=
152&quot; =A0 (n0)</div>
<div>/local/domain/0/memory/static-max =3D &quot;2097152&quot; =A0 (n0)</di=
v><div>/local/domain/0/memory/freemem-slack =3D &quot;3773506&quot; =A0 (n0=
)</div><div>/local/domain/0/device-model =3D &quot;&quot; =A0 (n0)</div><di=
v>/local/domain/0/device-model/2 =3D &quot;&quot; =A0 (n0)</div>
<div>/local/domain/0/device-model/2/state =3D &quot;running&quot; =A0 (n0)<=
/div><div>/local/domain/0/backend =3D &quot;&quot; =A0 (n0)</div><div>/loca=
l/domain/0/backend/qdisk =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/=
0/backend/qdisk/2 =3D &quot;&quot; =A0 (n0)</div>
<div>/local/domain/0/backend/qdisk/2/51744 =3D &quot;&quot; =A0 (n0,r2)</di=
v><div>/local/domain/0/backend/qdisk/2/51744/frontend =3D &quot;/local/doma=
in/2/device/vbd/51744&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/q=
disk/2/51744/params =3D &quot;aio:/home/sandi/oi151a.iso&quot; =A0 (n0,r2)<=
/div>
<div>/local/domain/0/backend/qdisk/2/51744/frontend-id =3D &quot;2&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/online =3D &quo=
t;1&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/remov=
able =3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/bootable =3D &quot;1&quot; =A0 (=
n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/state =3D &quot;4&qu=
ot; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/dev =3D &qu=
ot;xvdc&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/type =3D &quot;qdisk&quot; =A0 (=
n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/mode =3D &quot;r&quo=
t; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/device-type =
=3D &quot;cdrom&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/feature-barrier =3D &quot;1&quot=
; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/info =3D &quo=
t;5&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/secto=
r-size =3D &quot;512&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/sectors =3D &quot;1643348&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/hotplug-status =
=3D &quot;connected&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd=
 =3D &quot;&quot; =A0 (n0)</div>
<div>/local/domain/0/backend/vbd/2 =3D &quot;&quot; =A0 (n0)</div><div>/loc=
al/domain/0/backend/vbd/2/51712 =3D &quot;&quot; =A0 (n0,r2)</div><div>/loc=
al/domain/0/backend/vbd/2/51712/frontend =3D &quot;/local/domain/2/device/v=
bd/51712&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/physical-device =3D &quot;fe:2&quo=
t; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/params =3D &qu=
ot;/dev/xen-dom0/oi_boot&quot; =A0 (n0,r2)</div><div>/local/domain/0/backen=
d/vbd/2/51712/frontend-id =3D &quot;2&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/online =3D &quot;1&quot; =A0 (n0,r=
2)</div><div>/local/domain/0/backend/vbd/2/51712/removable =3D &quot;0&quot=
; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/bootable =3D &q=
uot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/state =3D &quot;4&quot; =A0 (n0,r2=
)</div><div>/local/domain/0/backend/vbd/2/51712/dev =3D &quot;xvda&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/type =3D &quot;ph=
y&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/mode =3D &quot;w&quot; =A0 (n0,r2)=
</div><div>/local/domain/0/backend/vbd/2/51712/device-type =3D &quot;disk&q=
uot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/feature-flus=
h-cache =3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/sectors =3D &quot;83886080&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/info =3D &quot;0&=
quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/sector-size=
 =3D &quot;512&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif =3D &quot;&quot; =A0 (n0)</div><div>/local=
/domain/0/backend/vif/2 =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/0=
/backend/vif/2/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/0/bac=
kend/vif/2/0/frontend =3D &quot;/local/domain/2/device/vif/0&quot; =A0 (n0,=
r2)</div>
<div>/local/domain/0/backend/vif/2/0/frontend-id =3D &quot;2&quot; =A0 (n0,=
r2)</div><div>/local/domain/0/backend/vif/2/0/online =3D &quot;1&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/vif/2/0/state =3D &quot;2&quot; =
=A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif/2/0/script =3D &quot;/etc/xen/scripts/vif-=
bridge&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vif/2/0/mac =3D =
&quot;00:16:3e:00:8f:d8&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend=
/vif/2/0/bridge =3D &quot;eth0&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif/2/0/handle =3D &quot;0&quot; =A0 (n0,r2)</=
div><div>/local/domain/0/backend/vif/2/0/feature-sg =3D &quot;1&quot; =A0 (=
n0,r2)</div><div>/local/domain/0/backend/vif/2/0/feature-gso-tcpv4 =3D &quo=
t;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif/2/0/feature-rx-copy =3D &quot;1&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/vif/2/0/feature-rx-flip =3D &quot=
;0&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/console =3D &quot;&q=
uot; =A0 (n0)</div>
<div>/local/domain/0/backend/console/2 =3D &quot;&quot; =A0 (n0)</div><div>=
/local/domain/0/backend/console/2/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>=
/local/domain/0/backend/console/2/0/frontend =3D &quot;/local/domain/2/cons=
ole&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/console/2/0/frontend-id =3D &quot;2&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/console/2/0/online =3D &quot;1&qu=
ot; =A0 (n0,r2)</div><div>/local/domain/0/backend/console/2/0/state =3D &qu=
ot;4&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/console/2/0/domain =3D &quot;oi&quot; =A0 (n0,=
r2)</div><div>/local/domain/0/backend/console/2/0/protocol =3D &quot;vt100&=
quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/console/2/0/hotplug-sta=
tus =3D &quot;connected&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci =3D &quot;&quot; =A0 (n0)</div><div>/local=
/domain/0/backend/pci/2 =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/0=
/backend/pci/2/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/0/bac=
kend/pci/2/0/frontend =3D &quot;/local/domain/2/device/pci/0&quot; =A0 (n0,=
r2)</div>
<div>/local/domain/0/backend/pci/2/0/frontend-id =3D &quot;2&quot; =A0 (n0,=
r2)</div><div>/local/domain/0/backend/pci/2/0/online =3D &quot;1&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/pci/2/0/state =3D &quot;3&quot; =
=A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci/2/0/domain =3D &quot;oi&quot; =A0 (n0,r2)<=
/div><div>/local/domain/0/backend/pci/2/0/key-0 =3D &quot;0000:05:00.0&quot=
; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/dev-0 =3D &quot;000=
0:05:00.0&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci/2/0/opts-0 =3D &quot;msitranslate=3D1,powe=
r_mgmt=3D0&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/stat=
e-0 =3D &quot;3&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0=
/num_devs =3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci/2/0/vdev-0 =3D &quot;0000:05:00.00&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/root-0 =3D &quot;0000=
:05&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/root_num =
=3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/2 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/2=
/vm =3D &quot;/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4&quot; =A0 (n0,r2)</d=
iv><div>/local/domain/2/name =3D &quot;oi&quot; =A0 (n0,r2)</div><div>/loca=
l/domain/2/cpu =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/cpu/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/do=
main/2/cpu/0/availability =3D &quot;online&quot; =A0 (n0,r2)</div><div>/loc=
al/domain/2/cpu/1 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/2/cp=
u/1/availability =3D &quot;online&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/memory =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/d=
omain/2/memory/static-max =3D &quot;2097152&quot; =A0 (n0,r2)</div><div>/lo=
cal/domain/2/memory/target =3D &quot;2097152&quot; =A0 (n0,r2)</div><div>/l=
ocal/domain/2/memory/videoram =3D &quot;0&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/device =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/d=
omain/2/device/suspend =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain=
/2/device/suspend/event-channel =3D &quot;&quot; =A0 (n2)</div><div>/local/=
domain/2/device/vbd =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/device/vbd/51744 =3D &quot;&quot; =A0 (n2,r0)</div><di=
v>/local/domain/2/device/vbd/51744/backend =3D &quot;/local/domain/0/backen=
d/qdisk/2/51744&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/5174=
4/backend-id =3D &quot;0&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51744/state =3D &quot;4&quot; =A0 (n2,r0)</=
div><div>/local/domain/2/device/vbd/51744/virtual-device =3D &quot;51744&qu=
ot; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51744/device-type =3D =
&quot;cdrom&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51744/media-req =3D &quot;none&quot; =A0 (n=
2,r0)</div><div>/local/domain/2/device/vbd/51744/ring-ref =3D &quot;266&quo=
t; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51744/event-channel =3D=
 &quot;13&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51744/protocol =3D &quot;x86_64-abi&quot; =
=A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51712 =3D &quot;&quot; =A0=
 (n2,r0)</div><div>/local/domain/2/device/vbd/51712/backend =3D &quot;/loca=
l/domain/0/backend/vbd/2/51712&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51712/backend-id =3D &quot;0&quot; =A0 (n2,=
r0)</div><div>/local/domain/2/device/vbd/51712/state =3D &quot;4&quot; =A0 =
(n2,r0)</div><div>/local/domain/2/device/vbd/51712/virtual-device =3D &quot=
;51712&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51712/device-type =3D &quot;disk&quot; =A0 =
(n2,r0)</div><div>/local/domain/2/device/vbd/51712/media-req =3D &quot;none=
&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51712/ring-ref =3D =
&quot;267&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51712/event-channel =3D &quot;14&quot; =A0 =
(n2,r0)</div><div>/local/domain/2/device/vbd/51712/protocol =3D &quot;x86_6=
4-abi&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vif =3D &quot;&quo=
t; =A0 (n0,r2)</div>
<div>/local/domain/2/device/vif/0 =3D &quot;&quot; =A0 (n2,r0)</div><div>/l=
ocal/domain/2/device/vif/0/backend =3D &quot;/local/domain/0/backend/vif/2/=
0&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vif/0/backend-id =3D &=
quot;0&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vif/0/state =3D &quot;4&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/device/vif/0/handle =3D &quot;0&quot; =A0 (n2,r0)</div=
><div>/local/domain/2/device/vif/0/mac =3D &quot;00:16:3e:00:8f:d8&quot; =
=A0 (n2,r0)</div>
<div>/local/domain/2/device/vif/0/tx-ring-ref =3D &quot;8&quot; =A0 (n2,r0)=
</div><div>/local/domain/2/device/vif/0/rx-ring-ref =3D &quot;9&quot; =A0 (=
n2,r0)</div><div>/local/domain/2/device/vif/0/event-channel =3D &quot;12&qu=
ot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vif/0/feature-rx-notify =3D &quot;1&quot; =A0 (=
n2,r0)</div><div>/local/domain/2/device/vif/0/request-rx-copy =3D &quot;1&q=
uot; =A0 (n2,r0)</div><div>/local/domain/2/device/pci =3D &quot;&quot; =A0 =
(n0,r2)</div>
<div>/local/domain/2/device/pci/0 =3D &quot;&quot; =A0 (n2,r0)</div><div>/l=
ocal/domain/2/device/pci/0/backend =3D &quot;/local/domain/0/backend/pci/2/=
0&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/pci/0/backend-id =3D &=
quot;0&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/pci/0/state =3D &quot;1&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/control =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/=
domain/2/control/shutdown =3D &quot;&quot; =A0 (n2)</div><div>/local/domain=
/2/control/platform-feature-multiprocessor-suspend =3D &quot;1&quot; =A0 (n=
0,r2)</div>
<div>/local/domain/2/control/platform-feature-xs_reset_watches =3D &quot;1&=
quot; =A0 (n0,r2)</div><div>/local/domain/2/data =3D &quot;&quot; =A0 (n2)<=
/div><div>/local/domain/2/domid =3D &quot;2&quot; =A0 (n0,r2)</div><div>/lo=
cal/domain/2/store =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/store/port =3D &quot;1&quot; =A0 (n0,r2)</div><div>/lo=
cal/domain/2/store/ring-ref =3D &quot;4891896&quot; =A0 (n0,r2)</div><div>/=
local/domain/2/console =3D &quot;&quot; =A0 (n2,r0)</div><div>/local/domain=
/2/console/backend =3D &quot;/local/domain/0/backend/console/2/0&quot; =A0 =
(n2,r0)</div>
<div>/local/domain/2/console/backend-id =3D &quot;0&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/console/limit =3D &quot;1048576&quot; =A0 (n2,r0)</div=
><div>/local/domain/2/console/type =3D &quot;ioemu&quot; =A0 (n2,r0)</div><=
div>/local/domain/2/console/output =3D &quot;pty&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/console/port =3D &quot;2&quot; =A0 (n2,r0)</div><div>/=
local/domain/2/console/ring-ref =3D &quot;4891895&quot; =A0 (n2,r0)</div><d=
iv>/local/domain/2/console/tty =3D &quot;/dev/pts/4&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/hvmloader =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/hvmloader/bios =3D &quot;rombios&quot; =A0 (n0,r2)</di=
v><div>/local/domain/2/image =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/=
domain/2/image/device-model-pid =3D &quot;4029&quot; =A0 (n0,r2)</div><div>=
/vm =3D &quot;&quot; =A0 (n0)</div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4 =3D &quot;&quot; =A0 (n0,r2)<=
/div><div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/uuid =3D &quot;897494e6-=
60a2-47e4-aaa0-826ef89d63e4&quot; =A0 (n0,r2)</div><div>/vm/897494e6-60a2-4=
7e4-aaa0-826ef89d63e4/name =3D &quot;oi&quot; =A0 (n0,r2)</div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image =3D &quot;&quot; =A0 (n=
0,r2)</div><div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ostype =3D &=
quot;linux&quot; =A0 (n0,r2)</div><div>/vm/897494e6-60a2-47e4-aaa0-826ef89d=
63e4/image/kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot; =A0 (n0,r2)<=
/div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ramdisk =3D &quot;/etc/=
xen/kernels/oi151a/boot_archive&quot; =A0 (n0,r2)</div><div>/vm/897494e6-60=
a2-47e4-aaa0-826ef89d63e4/image/cmdline =3D &quot;/platform/i86xpv/kernel/a=
md64/unix -B console=3Dttya&quot; =A0 (n0,r2)</div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/start_time =3D &quot;13355496=
87.10&quot; =A0 (n0,r2)</div><div>/libxl =3D &quot;&quot; =A0 (n0)</div><di=
v>/libxl/2 =3D &quot;&quot; =A0 (n0)</div><div>/libxl/2/dm-version =3D &quo=
t;qemu_xen_traditional&quot; =A0 (n0)</div>
<div><br></div><div><br></div><div>Hope this output helps out...</div><div>=
<br></div><div>Best regards</div><div><br></div><div>Sandi</div></div></div=
>

--bcaec52be87df8f92704bead0730--


--===============1592711413674331942==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1592711413674331942==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 18:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpdd-0006F4-3o; Fri, 27 Apr 2012 18:11:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SNpdb-0006Ez-3Z
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:11:23 +0000
Received: from [85.158.143.99:53747] by server-3.bemta-4.messagelabs.com id
	7F/1A-05853-A41EA9F4; Fri, 27 Apr 2012 18:11:22 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335550279!14405460!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27863 invoked from network); 27 Apr 2012 18:11:20 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:11:20 -0000
Received: by eaaf11 with SMTP id f11so280821eaa.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AWsVVioY6zIYM+j0qPY3gC8+o/UHhAyahu+BA9S/i8g=;
	b=Igg6w2o+lSIOsQms5A1JUg7LFuGvxnQQNdUdjX2g0K5XUVr2OnM9P2cniBZcrhF0Li
	brf/eh/sCOI5mssAkSBDMGZO796GNwKDgDu3Ug+qkNBCTFv1LwoVDp08XH45LbetY86Y
	rhBnY+4L5vVIJyUpj1yzKwuheRJSAN1tj57n8Hpge6NX/Fb+soS53eGUJPT4n0tCOZSx
	9OuHNX26t6CfgTiYIu6fMbqkWf3z1xU1GVZ7l9XjAeY2Jv8fInnfAPcKc39slkJmGqzD
	JooRzSzDL18RNo9+6YUKBHCbM6zqHdsw8ZtUrqB+tDrEVoQ+7Dyd2Dg+5i4LmBSriAHH
	cyaw==
MIME-Version: 1.0
Received: by 10.14.94.193 with SMTP id n41mr3046406eef.27.1335550279218; Fri,
	27 Apr 2012 11:11:19 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Fri, 27 Apr 2012 11:11:19 -0700 (PDT)
In-Reply-To: <CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
Date: Fri, 27 Apr 2012 20:11:19 +0200
Message-ID: <CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1592711413674331942=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1592711413674331942==
Content-Type: multipart/alternative; boundary=bcaec52be87df8f92704bead0730

--bcaec52be87df8f92704bead0730
Content-Type: text/plain; charset=ISO-8859-1

Ian,

Please see some of the output you have requested below.


>> What does your guest config look like now that you have resolved the
>> pygrub issue?
>>
>
 disk = [
'file:/home/sandi/oi151a.iso,xvdc:cdrom,r',
'phy:/dev/xen-dom0/oi_boot,xvda,w',
]

 vif = ['bridge=eth0,mac=00:16:3e:00:8f:d8']

 vcpus = 2
 cpus = "2-3"
 memory = 2048
 name = "oi"

 kernel = "/etc/xen/kernels/oi151a/unix"
 ramdisk = "/etc/xen/kernels/oi151a/boot_archive"
 extra = "/platform/i86xpv/kernel/amd64/unix -B console=ttya"

 on_shutdown = "destroy"
 on_reboot = "restart"
 on_crash = "destroy"

 pci = [ '05:00.0' ]



>
>
>>
>> Can you provide a full log of the failing boot with a vif enabled to the
>> point of the hang?
>>
>>
I will send these logs if you like, if the data I have included here is of
not help.



>> What does "brctl show" say while the guest is running (with the vif
>> enabled)?
>>
>> What does "xenstore-ls -fp" show while the guest is sat waiting?
>>
>
> [root@xen-srv sandi]# brctl show
bridge name bridge id STP enabled interfaces

[root@xen-srv sandi]# xenstore-ls -fp
/tool = ""   (n0)
/tool/xenstored = ""   (n0)
/local = ""   (n0)
/local/domain = ""   (n0)
/local/domain/0 = ""   (n0)
/local/domain/0/name = "Domain-0"   (n0)
/local/domain/0/memory = ""   (n0)
/local/domain/0/memory/target = "2097152"   (n0)
/local/domain/0/memory/static-max = "2097152"   (n0)
/local/domain/0/memory/freemem-slack = "3773506"   (n0)
/local/domain/0/device-model = ""   (n0)
/local/domain/0/device-model/2 = ""   (n0)
/local/domain/0/device-model/2/state = "running"   (n0)
/local/domain/0/backend = ""   (n0)
/local/domain/0/backend/qdisk = ""   (n0)
/local/domain/0/backend/qdisk/2 = ""   (n0)
/local/domain/0/backend/qdisk/2/51744 = ""   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/frontend =
"/local/domain/2/device/vbd/51744"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/params = "aio:/home/sandi/oi151a.iso"
  (n0,r2)
/local/domain/0/backend/qdisk/2/51744/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/online = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/removable = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/bootable = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/state = "4"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/dev = "xvdc"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/type = "qdisk"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/mode = "r"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/device-type = "cdrom"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/feature-barrier = "1"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/info = "5"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/sector-size = "512"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/sectors = "1643348"   (n0,r2)
/local/domain/0/backend/qdisk/2/51744/hotplug-status = "connected"   (n0,r2)
/local/domain/0/backend/vbd = ""   (n0)
/local/domain/0/backend/vbd/2 = ""   (n0)
/local/domain/0/backend/vbd/2/51712 = ""   (n0,r2)
/local/domain/0/backend/vbd/2/51712/frontend =
"/local/domain/2/device/vbd/51712"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/physical-device = "fe:2"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/params = "/dev/xen-dom0/oi_boot"
(n0,r2)
/local/domain/0/backend/vbd/2/51712/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/online = "1"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/removable = "0"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/bootable = "1"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/state = "4"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/dev = "xvda"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/type = "phy"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/mode = "w"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/device-type = "disk"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/feature-flush-cache = "1"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/sectors = "83886080"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/info = "0"   (n0,r2)
/local/domain/0/backend/vbd/2/51712/sector-size = "512"   (n0,r2)
/local/domain/0/backend/vif = ""   (n0)
/local/domain/0/backend/vif/2 = ""   (n0)
/local/domain/0/backend/vif/2/0 = ""   (n0,r2)
/local/domain/0/backend/vif/2/0/frontend = "/local/domain/2/device/vif/0"
(n0,r2)
/local/domain/0/backend/vif/2/0/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/vif/2/0/online = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/state = "2"   (n0,r2)
/local/domain/0/backend/vif/2/0/script = "/etc/xen/scripts/vif-bridge"
(n0,r2)
/local/domain/0/backend/vif/2/0/mac = "00:16:3e:00:8f:d8"   (n0,r2)
/local/domain/0/backend/vif/2/0/bridge = "eth0"   (n0,r2)
/local/domain/0/backend/vif/2/0/handle = "0"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-sg = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-gso-tcpv4 = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-rx-copy = "1"   (n0,r2)
/local/domain/0/backend/vif/2/0/feature-rx-flip = "0"   (n0,r2)
/local/domain/0/backend/console = ""   (n0)
/local/domain/0/backend/console/2 = ""   (n0)
/local/domain/0/backend/console/2/0 = ""   (n0,r2)
/local/domain/0/backend/console/2/0/frontend = "/local/domain/2/console"
(n0,r2)
/local/domain/0/backend/console/2/0/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/console/2/0/online = "1"   (n0,r2)
/local/domain/0/backend/console/2/0/state = "4"   (n0,r2)
/local/domain/0/backend/console/2/0/domain = "oi"   (n0,r2)
/local/domain/0/backend/console/2/0/protocol = "vt100"   (n0,r2)
/local/domain/0/backend/console/2/0/hotplug-status = "connected"   (n0,r2)
/local/domain/0/backend/pci = ""   (n0)
/local/domain/0/backend/pci/2 = ""   (n0)
/local/domain/0/backend/pci/2/0 = ""   (n0,r2)
/local/domain/0/backend/pci/2/0/frontend = "/local/domain/2/device/pci/0"
(n0,r2)
/local/domain/0/backend/pci/2/0/frontend-id = "2"   (n0,r2)
/local/domain/0/backend/pci/2/0/online = "1"   (n0,r2)
/local/domain/0/backend/pci/2/0/state = "3"   (n0,r2)
/local/domain/0/backend/pci/2/0/domain = "oi"   (n0,r2)
/local/domain/0/backend/pci/2/0/key-0 = "0000:05:00.0"   (n0,r2)
/local/domain/0/backend/pci/2/0/dev-0 = "0000:05:00.0"   (n0,r2)
/local/domain/0/backend/pci/2/0/opts-0 = "msitranslate=1,power_mgmt=0"
(n0,r2)
/local/domain/0/backend/pci/2/0/state-0 = "3"   (n0,r2)
/local/domain/0/backend/pci/2/0/num_devs = "1"   (n0,r2)
/local/domain/0/backend/pci/2/0/vdev-0 = "0000:05:00.00"   (n0,r2)
/local/domain/0/backend/pci/2/0/root-0 = "0000:05"   (n0,r2)
/local/domain/0/backend/pci/2/0/root_num = "1"   (n0,r2)
/local/domain/2 = ""   (n0,r2)
/local/domain/2/vm = "/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4"   (n0,r2)
/local/domain/2/name = "oi"   (n0,r2)
/local/domain/2/cpu = ""   (n0,r2)
/local/domain/2/cpu/0 = ""   (n0,r2)
/local/domain/2/cpu/0/availability = "online"   (n0,r2)
/local/domain/2/cpu/1 = ""   (n0,r2)
/local/domain/2/cpu/1/availability = "online"   (n0,r2)
/local/domain/2/memory = ""   (n0,r2)
/local/domain/2/memory/static-max = "2097152"   (n0,r2)
/local/domain/2/memory/target = "2097152"   (n0,r2)
/local/domain/2/memory/videoram = "0"   (n0,r2)
/local/domain/2/device = ""   (n0,r2)
/local/domain/2/device/suspend = ""   (n0,r2)
/local/domain/2/device/suspend/event-channel = ""   (n2)
/local/domain/2/device/vbd = ""   (n0,r2)
/local/domain/2/device/vbd/51744 = ""   (n2,r0)
/local/domain/2/device/vbd/51744/backend =
"/local/domain/0/backend/qdisk/2/51744"   (n2,r0)
/local/domain/2/device/vbd/51744/backend-id = "0"   (n2,r0)
/local/domain/2/device/vbd/51744/state = "4"   (n2,r0)
/local/domain/2/device/vbd/51744/virtual-device = "51744"   (n2,r0)
/local/domain/2/device/vbd/51744/device-type = "cdrom"   (n2,r0)
/local/domain/2/device/vbd/51744/media-req = "none"   (n2,r0)
/local/domain/2/device/vbd/51744/ring-ref = "266"   (n2,r0)
/local/domain/2/device/vbd/51744/event-channel = "13"   (n2,r0)
/local/domain/2/device/vbd/51744/protocol = "x86_64-abi"   (n2,r0)
/local/domain/2/device/vbd/51712 = ""   (n2,r0)
/local/domain/2/device/vbd/51712/backend =
"/local/domain/0/backend/vbd/2/51712"   (n2,r0)
/local/domain/2/device/vbd/51712/backend-id = "0"   (n2,r0)
/local/domain/2/device/vbd/51712/state = "4"   (n2,r0)
/local/domain/2/device/vbd/51712/virtual-device = "51712"   (n2,r0)
/local/domain/2/device/vbd/51712/device-type = "disk"   (n2,r0)
/local/domain/2/device/vbd/51712/media-req = "none"   (n2,r0)
/local/domain/2/device/vbd/51712/ring-ref = "267"   (n2,r0)
/local/domain/2/device/vbd/51712/event-channel = "14"   (n2,r0)
/local/domain/2/device/vbd/51712/protocol = "x86_64-abi"   (n2,r0)
/local/domain/2/device/vif = ""   (n0,r2)
/local/domain/2/device/vif/0 = ""   (n2,r0)
/local/domain/2/device/vif/0/backend = "/local/domain/0/backend/vif/2/0"
(n2,r0)
/local/domain/2/device/vif/0/backend-id = "0"   (n2,r0)
/local/domain/2/device/vif/0/state = "4"   (n2,r0)
/local/domain/2/device/vif/0/handle = "0"   (n2,r0)
/local/domain/2/device/vif/0/mac = "00:16:3e:00:8f:d8"   (n2,r0)
/local/domain/2/device/vif/0/tx-ring-ref = "8"   (n2,r0)
/local/domain/2/device/vif/0/rx-ring-ref = "9"   (n2,r0)
/local/domain/2/device/vif/0/event-channel = "12"   (n2,r0)
/local/domain/2/device/vif/0/feature-rx-notify = "1"   (n2,r0)
/local/domain/2/device/vif/0/request-rx-copy = "1"   (n2,r0)
/local/domain/2/device/pci = ""   (n0,r2)
/local/domain/2/device/pci/0 = ""   (n2,r0)
/local/domain/2/device/pci/0/backend = "/local/domain/0/backend/pci/2/0"
(n2,r0)
/local/domain/2/device/pci/0/backend-id = "0"   (n2,r0)
/local/domain/2/device/pci/0/state = "1"   (n2,r0)
/local/domain/2/control = ""   (n0,r2)
/local/domain/2/control/shutdown = ""   (n2)
/local/domain/2/control/platform-feature-multiprocessor-suspend = "1"
(n0,r2)
/local/domain/2/control/platform-feature-xs_reset_watches = "1"   (n0,r2)
/local/domain/2/data = ""   (n2)
/local/domain/2/domid = "2"   (n0,r2)
/local/domain/2/store = ""   (n0,r2)
/local/domain/2/store/port = "1"   (n0,r2)
/local/domain/2/store/ring-ref = "4891896"   (n0,r2)
/local/domain/2/console = ""   (n2,r0)
/local/domain/2/console/backend = "/local/domain/0/backend/console/2/0"
(n2,r0)
/local/domain/2/console/backend-id = "0"   (n2,r0)
/local/domain/2/console/limit = "1048576"   (n2,r0)
/local/domain/2/console/type = "ioemu"   (n2,r0)
/local/domain/2/console/output = "pty"   (n2,r0)
/local/domain/2/console/port = "2"   (n2,r0)
/local/domain/2/console/ring-ref = "4891895"   (n2,r0)
/local/domain/2/console/tty = "/dev/pts/4"   (n2,r0)
/local/domain/2/hvmloader = ""   (n0,r2)
/local/domain/2/hvmloader/bios = "rombios"   (n0,r2)
/local/domain/2/image = ""   (n0,r2)
/local/domain/2/image/device-model-pid = "4029"   (n0,r2)
/vm = ""   (n0)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4 = ""   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/uuid =
"897494e6-60a2-47e4-aaa0-826ef89d63e4"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/name = "oi"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image = ""   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ostype = "linux"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/kernel =
"/etc/xen/kernels/oi151a/unix"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ramdisk =
"/etc/xen/kernels/oi151a/boot_archive"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/cmdline =
"/platform/i86xpv/kernel/amd64/unix -B console=ttya"   (n0,r2)
/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/start_time = "1335549687.10"
(n0,r2)
/libxl = ""   (n0)
/libxl/2 = ""   (n0)
/libxl/2/dm-version = "qemu_xen_traditional"   (n0)


Hope this output helps out...

Best regards

Sandi

--bcaec52be87df8f92704bead0730
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Ian,</div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">Please see some of the output you have requested =
below.<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><br>
What does your guest config look like now that you have resolved the<br>
pygrub issue?<br></blockquote><div></div></div></div></div></blockquote><di=
v><br></div><div>=A0disk =3D [</div><div><span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre">	</span>&#39;file:/home/sandi/oi151a.iso,xvdc:cdrom,=
r&#39;,</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>&#39;=
phy:/dev/xen-dom0/oi_boot,xvda,w&#39;,</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre">	</span>]</div><div><br></div><div>=A0vif =
=3D [&#39;bridge=3Deth0,mac=3D00:16:3e:00:8f:d8&#39;]=A0</div>
<div><br></div><div>=A0vcpus =3D 2</div><div>=A0cpus =3D &quot;2-3&quot;</d=
iv><div>=A0memory =3D 2048</div><div>=A0name =3D &quot;oi&quot;</div><div><=
br></div><div>=A0kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot;</div><=
div>=A0ramdisk =3D &quot;/etc/xen/kernels/oi151a/boot_archive&quot;</div>
<div>=A0extra =3D &quot;/platform/i86xpv/kernel/amd64/unix -B console=3Dtty=
a&quot;</div><div><br></div><div>=A0on_shutdown =3D &quot;destroy&quot;</di=
v><div>=A0on_reboot =3D &quot;restart&quot;</div><div>=A0on_crash =3D &quot=
;destroy&quot;</div>
<div><br></div><div>=A0pci =3D [ &#39;05:00.0&#39; ]</div><div><br></div><d=
iv>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">
<div class=3D"im"><div>=A0</div></div><div class=3D"im"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<br>
Can you provide a full log of the failing boot with a vif enabled to the<br=
>
point of the hang?<br>
<br></blockquote><div></div></div><div class=3D"im"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"></blockquote></div></div></div></blockquote><div><br></div><div>I w=
ill send these logs if you like, if the data I have included here is of not=
 help.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<br>
What does &quot;brctl show&quot; say while the guest is running (with the v=
if<br>
enabled)?<br>
<br>
What does &quot;xenstore-ls -fp&quot; show while the guest is sat waiting?<=
br></blockquote><div><br></div></div></div></div></blockquote><div>[root@xe=
n-srv sandi]# brctl show</div><div>bridge name<span class=3D"Apple-tab-span=
" style=3D"white-space:pre">	</span>bridge id<span class=3D"Apple-tab-span"=
 style=3D"white-space:pre">		</span>STP enabled<span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre">	</span>interfaces</div>
<div><br></div><div>[root@xen-srv sandi]# xenstore-ls -fp</div><div>/tool =
=3D &quot;&quot; =A0 (n0)</div><div>/tool/xenstored =3D &quot;&quot; =A0 (n=
0)</div><div>/local =3D &quot;&quot; =A0 (n0)</div><div>/local/domain =3D &=
quot;&quot; =A0 (n0)</div>
<div>/local/domain/0 =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/0/na=
me =3D &quot;Domain-0&quot; =A0 (n0)</div><div>/local/domain/0/memory =3D &=
quot;&quot; =A0 (n0)</div><div>/local/domain/0/memory/target =3D &quot;2097=
152&quot; =A0 (n0)</div>
<div>/local/domain/0/memory/static-max =3D &quot;2097152&quot; =A0 (n0)</di=
v><div>/local/domain/0/memory/freemem-slack =3D &quot;3773506&quot; =A0 (n0=
)</div><div>/local/domain/0/device-model =3D &quot;&quot; =A0 (n0)</div><di=
v>/local/domain/0/device-model/2 =3D &quot;&quot; =A0 (n0)</div>
<div>/local/domain/0/device-model/2/state =3D &quot;running&quot; =A0 (n0)<=
/div><div>/local/domain/0/backend =3D &quot;&quot; =A0 (n0)</div><div>/loca=
l/domain/0/backend/qdisk =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/=
0/backend/qdisk/2 =3D &quot;&quot; =A0 (n0)</div>
<div>/local/domain/0/backend/qdisk/2/51744 =3D &quot;&quot; =A0 (n0,r2)</di=
v><div>/local/domain/0/backend/qdisk/2/51744/frontend =3D &quot;/local/doma=
in/2/device/vbd/51744&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/q=
disk/2/51744/params =3D &quot;aio:/home/sandi/oi151a.iso&quot; =A0 (n0,r2)<=
/div>
<div>/local/domain/0/backend/qdisk/2/51744/frontend-id =3D &quot;2&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/online =3D &quo=
t;1&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/remov=
able =3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/bootable =3D &quot;1&quot; =A0 (=
n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/state =3D &quot;4&qu=
ot; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/dev =3D &qu=
ot;xvdc&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/type =3D &quot;qdisk&quot; =A0 (=
n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/mode =3D &quot;r&quo=
t; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/device-type =
=3D &quot;cdrom&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/feature-barrier =3D &quot;1&quot=
; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/info =3D &quo=
t;5&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/secto=
r-size =3D &quot;512&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/qdisk/2/51744/sectors =3D &quot;1643348&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/qdisk/2/51744/hotplug-status =
=3D &quot;connected&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd=
 =3D &quot;&quot; =A0 (n0)</div>
<div>/local/domain/0/backend/vbd/2 =3D &quot;&quot; =A0 (n0)</div><div>/loc=
al/domain/0/backend/vbd/2/51712 =3D &quot;&quot; =A0 (n0,r2)</div><div>/loc=
al/domain/0/backend/vbd/2/51712/frontend =3D &quot;/local/domain/2/device/v=
bd/51712&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/physical-device =3D &quot;fe:2&quo=
t; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/params =3D &qu=
ot;/dev/xen-dom0/oi_boot&quot; =A0 (n0,r2)</div><div>/local/domain/0/backen=
d/vbd/2/51712/frontend-id =3D &quot;2&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/online =3D &quot;1&quot; =A0 (n0,r=
2)</div><div>/local/domain/0/backend/vbd/2/51712/removable =3D &quot;0&quot=
; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/bootable =3D &q=
uot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/state =3D &quot;4&quot; =A0 (n0,r2=
)</div><div>/local/domain/0/backend/vbd/2/51712/dev =3D &quot;xvda&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/type =3D &quot;ph=
y&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/mode =3D &quot;w&quot; =A0 (n0,r2)=
</div><div>/local/domain/0/backend/vbd/2/51712/device-type =3D &quot;disk&q=
uot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/feature-flus=
h-cache =3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vbd/2/51712/sectors =3D &quot;83886080&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/info =3D &quot;0&=
quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vbd/2/51712/sector-size=
 =3D &quot;512&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif =3D &quot;&quot; =A0 (n0)</div><div>/local=
/domain/0/backend/vif/2 =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/0=
/backend/vif/2/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/0/bac=
kend/vif/2/0/frontend =3D &quot;/local/domain/2/device/vif/0&quot; =A0 (n0,=
r2)</div>
<div>/local/domain/0/backend/vif/2/0/frontend-id =3D &quot;2&quot; =A0 (n0,=
r2)</div><div>/local/domain/0/backend/vif/2/0/online =3D &quot;1&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/vif/2/0/state =3D &quot;2&quot; =
=A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif/2/0/script =3D &quot;/etc/xen/scripts/vif-=
bridge&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/vif/2/0/mac =3D =
&quot;00:16:3e:00:8f:d8&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend=
/vif/2/0/bridge =3D &quot;eth0&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif/2/0/handle =3D &quot;0&quot; =A0 (n0,r2)</=
div><div>/local/domain/0/backend/vif/2/0/feature-sg =3D &quot;1&quot; =A0 (=
n0,r2)</div><div>/local/domain/0/backend/vif/2/0/feature-gso-tcpv4 =3D &quo=
t;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/vif/2/0/feature-rx-copy =3D &quot;1&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/vif/2/0/feature-rx-flip =3D &quot=
;0&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/console =3D &quot;&q=
uot; =A0 (n0)</div>
<div>/local/domain/0/backend/console/2 =3D &quot;&quot; =A0 (n0)</div><div>=
/local/domain/0/backend/console/2/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>=
/local/domain/0/backend/console/2/0/frontend =3D &quot;/local/domain/2/cons=
ole&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/console/2/0/frontend-id =3D &quot;2&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/console/2/0/online =3D &quot;1&qu=
ot; =A0 (n0,r2)</div><div>/local/domain/0/backend/console/2/0/state =3D &qu=
ot;4&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/console/2/0/domain =3D &quot;oi&quot; =A0 (n0,=
r2)</div><div>/local/domain/0/backend/console/2/0/protocol =3D &quot;vt100&=
quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/console/2/0/hotplug-sta=
tus =3D &quot;connected&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci =3D &quot;&quot; =A0 (n0)</div><div>/local=
/domain/0/backend/pci/2 =3D &quot;&quot; =A0 (n0)</div><div>/local/domain/0=
/backend/pci/2/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/0/bac=
kend/pci/2/0/frontend =3D &quot;/local/domain/2/device/pci/0&quot; =A0 (n0,=
r2)</div>
<div>/local/domain/0/backend/pci/2/0/frontend-id =3D &quot;2&quot; =A0 (n0,=
r2)</div><div>/local/domain/0/backend/pci/2/0/online =3D &quot;1&quot; =A0 =
(n0,r2)</div><div>/local/domain/0/backend/pci/2/0/state =3D &quot;3&quot; =
=A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci/2/0/domain =3D &quot;oi&quot; =A0 (n0,r2)<=
/div><div>/local/domain/0/backend/pci/2/0/key-0 =3D &quot;0000:05:00.0&quot=
; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/dev-0 =3D &quot;000=
0:05:00.0&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci/2/0/opts-0 =3D &quot;msitranslate=3D1,powe=
r_mgmt=3D0&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/stat=
e-0 =3D &quot;3&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0=
/num_devs =3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/0/backend/pci/2/0/vdev-0 =3D &quot;0000:05:00.00&quot; =
=A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/root-0 =3D &quot;0000=
:05&quot; =A0 (n0,r2)</div><div>/local/domain/0/backend/pci/2/0/root_num =
=3D &quot;1&quot; =A0 (n0,r2)</div>
<div>/local/domain/2 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/2=
/vm =3D &quot;/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4&quot; =A0 (n0,r2)</d=
iv><div>/local/domain/2/name =3D &quot;oi&quot; =A0 (n0,r2)</div><div>/loca=
l/domain/2/cpu =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/cpu/0 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/do=
main/2/cpu/0/availability =3D &quot;online&quot; =A0 (n0,r2)</div><div>/loc=
al/domain/2/cpu/1 =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain/2/cp=
u/1/availability =3D &quot;online&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/memory =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/d=
omain/2/memory/static-max =3D &quot;2097152&quot; =A0 (n0,r2)</div><div>/lo=
cal/domain/2/memory/target =3D &quot;2097152&quot; =A0 (n0,r2)</div><div>/l=
ocal/domain/2/memory/videoram =3D &quot;0&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/device =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/d=
omain/2/device/suspend =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/domain=
/2/device/suspend/event-channel =3D &quot;&quot; =A0 (n2)</div><div>/local/=
domain/2/device/vbd =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/device/vbd/51744 =3D &quot;&quot; =A0 (n2,r0)</div><di=
v>/local/domain/2/device/vbd/51744/backend =3D &quot;/local/domain/0/backen=
d/qdisk/2/51744&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/5174=
4/backend-id =3D &quot;0&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51744/state =3D &quot;4&quot; =A0 (n2,r0)</=
div><div>/local/domain/2/device/vbd/51744/virtual-device =3D &quot;51744&qu=
ot; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51744/device-type =3D =
&quot;cdrom&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51744/media-req =3D &quot;none&quot; =A0 (n=
2,r0)</div><div>/local/domain/2/device/vbd/51744/ring-ref =3D &quot;266&quo=
t; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51744/event-channel =3D=
 &quot;13&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51744/protocol =3D &quot;x86_64-abi&quot; =
=A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51712 =3D &quot;&quot; =A0=
 (n2,r0)</div><div>/local/domain/2/device/vbd/51712/backend =3D &quot;/loca=
l/domain/0/backend/vbd/2/51712&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51712/backend-id =3D &quot;0&quot; =A0 (n2,=
r0)</div><div>/local/domain/2/device/vbd/51712/state =3D &quot;4&quot; =A0 =
(n2,r0)</div><div>/local/domain/2/device/vbd/51712/virtual-device =3D &quot=
;51712&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51712/device-type =3D &quot;disk&quot; =A0 =
(n2,r0)</div><div>/local/domain/2/device/vbd/51712/media-req =3D &quot;none=
&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vbd/51712/ring-ref =3D =
&quot;267&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vbd/51712/event-channel =3D &quot;14&quot; =A0 =
(n2,r0)</div><div>/local/domain/2/device/vbd/51712/protocol =3D &quot;x86_6=
4-abi&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vif =3D &quot;&quo=
t; =A0 (n0,r2)</div>
<div>/local/domain/2/device/vif/0 =3D &quot;&quot; =A0 (n2,r0)</div><div>/l=
ocal/domain/2/device/vif/0/backend =3D &quot;/local/domain/0/backend/vif/2/=
0&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/vif/0/backend-id =3D &=
quot;0&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vif/0/state =3D &quot;4&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/device/vif/0/handle =3D &quot;0&quot; =A0 (n2,r0)</div=
><div>/local/domain/2/device/vif/0/mac =3D &quot;00:16:3e:00:8f:d8&quot; =
=A0 (n2,r0)</div>
<div>/local/domain/2/device/vif/0/tx-ring-ref =3D &quot;8&quot; =A0 (n2,r0)=
</div><div>/local/domain/2/device/vif/0/rx-ring-ref =3D &quot;9&quot; =A0 (=
n2,r0)</div><div>/local/domain/2/device/vif/0/event-channel =3D &quot;12&qu=
ot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/vif/0/feature-rx-notify =3D &quot;1&quot; =A0 (=
n2,r0)</div><div>/local/domain/2/device/vif/0/request-rx-copy =3D &quot;1&q=
uot; =A0 (n2,r0)</div><div>/local/domain/2/device/pci =3D &quot;&quot; =A0 =
(n0,r2)</div>
<div>/local/domain/2/device/pci/0 =3D &quot;&quot; =A0 (n2,r0)</div><div>/l=
ocal/domain/2/device/pci/0/backend =3D &quot;/local/domain/0/backend/pci/2/=
0&quot; =A0 (n2,r0)</div><div>/local/domain/2/device/pci/0/backend-id =3D &=
quot;0&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/device/pci/0/state =3D &quot;1&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/control =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/=
domain/2/control/shutdown =3D &quot;&quot; =A0 (n2)</div><div>/local/domain=
/2/control/platform-feature-multiprocessor-suspend =3D &quot;1&quot; =A0 (n=
0,r2)</div>
<div>/local/domain/2/control/platform-feature-xs_reset_watches =3D &quot;1&=
quot; =A0 (n0,r2)</div><div>/local/domain/2/data =3D &quot;&quot; =A0 (n2)<=
/div><div>/local/domain/2/domid =3D &quot;2&quot; =A0 (n0,r2)</div><div>/lo=
cal/domain/2/store =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/store/port =3D &quot;1&quot; =A0 (n0,r2)</div><div>/lo=
cal/domain/2/store/ring-ref =3D &quot;4891896&quot; =A0 (n0,r2)</div><div>/=
local/domain/2/console =3D &quot;&quot; =A0 (n2,r0)</div><div>/local/domain=
/2/console/backend =3D &quot;/local/domain/0/backend/console/2/0&quot; =A0 =
(n2,r0)</div>
<div>/local/domain/2/console/backend-id =3D &quot;0&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/console/limit =3D &quot;1048576&quot; =A0 (n2,r0)</div=
><div>/local/domain/2/console/type =3D &quot;ioemu&quot; =A0 (n2,r0)</div><=
div>/local/domain/2/console/output =3D &quot;pty&quot; =A0 (n2,r0)</div>
<div>/local/domain/2/console/port =3D &quot;2&quot; =A0 (n2,r0)</div><div>/=
local/domain/2/console/ring-ref =3D &quot;4891895&quot; =A0 (n2,r0)</div><d=
iv>/local/domain/2/console/tty =3D &quot;/dev/pts/4&quot; =A0 (n2,r0)</div>=
<div>/local/domain/2/hvmloader =3D &quot;&quot; =A0 (n0,r2)</div>
<div>/local/domain/2/hvmloader/bios =3D &quot;rombios&quot; =A0 (n0,r2)</di=
v><div>/local/domain/2/image =3D &quot;&quot; =A0 (n0,r2)</div><div>/local/=
domain/2/image/device-model-pid =3D &quot;4029&quot; =A0 (n0,r2)</div><div>=
/vm =3D &quot;&quot; =A0 (n0)</div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4 =3D &quot;&quot; =A0 (n0,r2)<=
/div><div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/uuid =3D &quot;897494e6-=
60a2-47e4-aaa0-826ef89d63e4&quot; =A0 (n0,r2)</div><div>/vm/897494e6-60a2-4=
7e4-aaa0-826ef89d63e4/name =3D &quot;oi&quot; =A0 (n0,r2)</div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image =3D &quot;&quot; =A0 (n=
0,r2)</div><div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ostype =3D &=
quot;linux&quot; =A0 (n0,r2)</div><div>/vm/897494e6-60a2-47e4-aaa0-826ef89d=
63e4/image/kernel =3D &quot;/etc/xen/kernels/oi151a/unix&quot; =A0 (n0,r2)<=
/div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/image/ramdisk =3D &quot;/etc/=
xen/kernels/oi151a/boot_archive&quot; =A0 (n0,r2)</div><div>/vm/897494e6-60=
a2-47e4-aaa0-826ef89d63e4/image/cmdline =3D &quot;/platform/i86xpv/kernel/a=
md64/unix -B console=3Dttya&quot; =A0 (n0,r2)</div>
<div>/vm/897494e6-60a2-47e4-aaa0-826ef89d63e4/start_time =3D &quot;13355496=
87.10&quot; =A0 (n0,r2)</div><div>/libxl =3D &quot;&quot; =A0 (n0)</div><di=
v>/libxl/2 =3D &quot;&quot; =A0 (n0)</div><div>/libxl/2/dm-version =3D &quo=
t;qemu_xen_traditional&quot; =A0 (n0)</div>
<div><br></div><div><br></div><div>Hope this output helps out...</div><div>=
<br></div><div>Best regards</div><div><br></div><div>Sandi</div></div></div=
>

--bcaec52be87df8f92704bead0730--


--===============1592711413674331942==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1592711413674331942==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 18:16:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpiI-0006Ou-27; Fri, 27 Apr 2012 18:16:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNpiG-0006Ol-FQ
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:16:12 +0000
Received: from [85.158.138.51:43026] by server-4.bemta-3.messagelabs.com id
	B6/D7-15341-B62EA9F4; Fri, 27 Apr 2012 18:16:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335550571!24186619!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29684 invoked from network); 27 Apr 2012 18:16:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:16:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="12184545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 18:16:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 19:16:10 +0100
Message-ID: <1335550569.4881.74.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 19:16:09 +0100
In-Reply-To: <CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
	<1335543062.28015.234.camel@zakaz.uk.xensource.com>
	<CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(readding xen-devel, please watch the CC lines)
On Fri, 2012-04-27 at 17:41 +0100, misiu godfrey wrote:
> On 4/27/12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > If you cd into the ioemu-remote dir then what do:
> > 	git show a2d2123a7dfc4d116011d51f48df786a3b853537
> > 	git show origin/master
> > say?

[...]

Thanks for all that.

I've just thought to actually check the staging vs. regular trees:
http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.1-testing.git;a=summary
http://xenbits.xen.org/gitweb/?p=qemu-xen-4.1-testing.git;a=summary
and it turns out that the regular tree is lagging behind the staging
one, including the very commits in question, sorry for not looking at
this sooner.

These aren't supposed to get out of sync with the main repos, so clearly
something is up. I've CC'd Ian Jackson who looks after this stuff but
unfortunately he's on vacation until some time late next week.

As a workaround you could set QEMU_REMOTE in .config (or edit Config.mk)
to refer to git://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git
instead of the non-staging version.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:16:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpiI-0006Ou-27; Fri, 27 Apr 2012 18:16:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNpiG-0006Ol-FQ
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:16:12 +0000
Received: from [85.158.138.51:43026] by server-4.bemta-3.messagelabs.com id
	B6/D7-15341-B62EA9F4; Fri, 27 Apr 2012 18:16:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1335550571!24186619!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29684 invoked from network); 27 Apr 2012 18:16:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:16:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="12184545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 18:16:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 19:16:10 +0100
Message-ID: <1335550569.4881.74.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 19:16:09 +0100
In-Reply-To: <CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
	<1335543062.28015.234.camel@zakaz.uk.xensource.com>
	<CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(readding xen-devel, please watch the CC lines)
On Fri, 2012-04-27 at 17:41 +0100, misiu godfrey wrote:
> On 4/27/12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > If you cd into the ioemu-remote dir then what do:
> > 	git show a2d2123a7dfc4d116011d51f48df786a3b853537
> > 	git show origin/master
> > say?

[...]

Thanks for all that.

I've just thought to actually check the staging vs. regular trees:
http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.1-testing.git;a=summary
http://xenbits.xen.org/gitweb/?p=qemu-xen-4.1-testing.git;a=summary
and it turns out that the regular tree is lagging behind the staging
one, including the very commits in question, sorry for not looking at
this sooner.

These aren't supposed to get out of sync with the main repos, so clearly
something is up. I've CC'd Ian Jackson who looks after this stuff but
unfortunately he's on vacation until some time late next week.

As a workaround you could set QEMU_REMOTE in .config (or edit Config.mk)
to refer to git://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git
instead of the non-staging version.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpls-0006Y0-MA; Fri, 27 Apr 2012 18:19:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNplq-0006Xq-QR
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:19:54 +0000
Received: from [85.158.143.35:52404] by server-1.bemta-4.messagelabs.com id
	61/84-20925-943EA9F4; Fri, 27 Apr 2012 18:19:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335550792!13776093!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25708 invoked from network); 27 Apr 2012 18:19:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:19:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="12184592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 18:19:52 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 19:19:52 +0100
Message-ID: <1335550792.4881.76.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Fri, 27 Apr 2012 19:19:52 +0100
In-Reply-To: <CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 19:11 +0100, Sandi Romih wrote:

>         
> [root@xen-srv sandi]# brctl show
> bridge name bridge id STP enabled interfaces

You don't appear to have setup any bridges on your host.

http://wiki.xen.org/wiki/HostConfiguration/Networking should lead you
through the necessary steps.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpls-0006Y0-MA; Fri, 27 Apr 2012 18:19:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SNplq-0006Xq-QR
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:19:54 +0000
Received: from [85.158.143.35:52404] by server-1.bemta-4.messagelabs.com id
	61/84-20925-943EA9F4; Fri, 27 Apr 2012 18:19:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1335550792!13776093!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25708 invoked from network); 27 Apr 2012 18:19:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:19:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="12184592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 18:19:52 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Apr 2012 19:19:52 +0100
Message-ID: <1335550792.4881.76.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Fri, 27 Apr 2012 19:19:52 +0100
In-Reply-To: <CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-04-27 at 19:11 +0100, Sandi Romih wrote:

>         
> [root@xen-srv sandi]# brctl show
> bridge name bridge id STP enabled interfaces

You don't appear to have setup any bridges on your host.

http://wiki.xen.org/wiki/HostConfiguration/Networking should lead you
through the necessary steps.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:25:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpqx-0006iL-GV; Fri, 27 Apr 2012 18:25:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNpqv-0006iE-3G
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:25:09 +0000
Received: from [193.109.254.147:49965] by server-3.bemta-14.messagelabs.com id
	83/BF-23274-484EA9F4; Fri, 27 Apr 2012 18:25:08 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335551106!6667176!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8296 invoked from network); 27 Apr 2012 18:25:07 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:25:07 -0000
Received: by lahe6 with SMTP id e6so859191lah.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:25:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=0cAC8ktliCVQZhv10P4O0pO+cQWhoH18lllijDCgkA8=;
	b=OrkSWTgcLjPmy0LRUqbKs9JpVzW6BZzDKAt58QsXneFUzYntGKN0JrjaczK2/UHwst
	GBRHNk8jXWaGsXQZ2Gtw1LZpyn54OasPAAxi5E5HxwXJnWR8iCn6px6SpOne/+HnHZ5w
	Wajkn4BU2UV8EHjXH4PMMwTmlK/VpCOnCqkrk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=0cAC8ktliCVQZhv10P4O0pO+cQWhoH18lllijDCgkA8=;
	b=dTsetDyFH1vu8VXXpHPcs42FcGurk6BJO/eZOYg+N8GHs0dYsVZKWsWnkItnERzlYa
	gJwXVdhJvlJzEPTAEaHLHJMNyIeJOa7YSbS/i2BuYcTKr0HGQO8OTcGbZZ8JZgXOdDm/
	2mOyiHwRFJToOHDBGmoHdkpvynTz5Wh3xoE2dCmI1EYZXS3QltEnq2FoUBXX4MdzrsuD
	D9qYhWg22ljlYUfLbPxNEpCB7Sep3KJXNIWKRUXYOAjj0itR2DFCncS7WoGBHwGSYMVy
	MBqOWfJIce5ji+4i3qFWMMvMlmrF6Gsn7FcmnwvCMbTDD+smu0q7ef7t7yx8/3heEJR1
	nKiQ==
MIME-Version: 1.0
Received: by 10.152.105.197 with SMTP id go5mr4434192lab.43.1335551106634;
	Fri, 27 Apr 2012 11:25:06 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 11:25:06 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
	<CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
Date: Fri, 27 Apr 2012 11:25:06 -0700
Message-ID: <CAB10MZAbS73A5162MMxs9LzkEzNHYO-tGtrpk-H9_NpRuEAGuw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQnYlgIdy5fF9nMVSlQqhkVzNVTy38qmxea4GGG0/k7jeIREokS5WTwopixKAssXcqhXMg0v
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 10:37 AM, Christian Limpach
<christian.limpach@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
>>
>> On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.co=
m>
>> wrote:
>>>
>>> Maybe you can do something similar, for example passing in a hint
>>> whether ept_sync_domain needs to be done or not. =A0In my case, the
>>> reasoning is that all the entries changed from hap_clean_vram_tracking
>>> are leaf entries, so ept_free_entry will never be called and thus
>>> ept_sync_domain can be deferred. =A0I didn't think through/consider the
>>> iommu case since that code is commented out in my tree.
>>
>> I thought about doing that initially. But then in the bulk case I would
>> always have to call ept_sync_domain() to be on the safe side. But if the
>> iommu case forces me down that path, then I guess I have no choice.
>
> I think you should re-consider. =A0It would avoid adding the extra
> wrapper, which makes this code a lot less readable. =A0Plus it avoids
> the need for the old_entries array.
>
> Let me re-iterate:
> - if it's a leaf entry, then there's no need to call ept_free_entry
> - if you don't need to call ept_free_entry, then you can defer
> ept_sync_domain (subject to the iommu case)
> - you could pass in a pointer to a bool to indicate to the caller that
> ept_sync_domain was deferred and that the caller needs to do it, with
> a NULL pointer indicating that the caller doesn't support defer

I understand now and like this approach. I will rework the patch and
send it out.

Thanks,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:25:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpqx-0006iL-GV; Fri, 27 Apr 2012 18:25:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNpqv-0006iE-3G
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:25:09 +0000
Received: from [193.109.254.147:49965] by server-3.bemta-14.messagelabs.com id
	83/BF-23274-484EA9F4; Fri, 27 Apr 2012 18:25:08 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1335551106!6667176!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8296 invoked from network); 27 Apr 2012 18:25:07 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:25:07 -0000
Received: by lahe6 with SMTP id e6so859191lah.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:25:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=0cAC8ktliCVQZhv10P4O0pO+cQWhoH18lllijDCgkA8=;
	b=OrkSWTgcLjPmy0LRUqbKs9JpVzW6BZzDKAt58QsXneFUzYntGKN0JrjaczK2/UHwst
	GBRHNk8jXWaGsXQZ2Gtw1LZpyn54OasPAAxi5E5HxwXJnWR8iCn6px6SpOne/+HnHZ5w
	Wajkn4BU2UV8EHjXH4PMMwTmlK/VpCOnCqkrk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=0cAC8ktliCVQZhv10P4O0pO+cQWhoH18lllijDCgkA8=;
	b=dTsetDyFH1vu8VXXpHPcs42FcGurk6BJO/eZOYg+N8GHs0dYsVZKWsWnkItnERzlYa
	gJwXVdhJvlJzEPTAEaHLHJMNyIeJOa7YSbS/i2BuYcTKr0HGQO8OTcGbZZ8JZgXOdDm/
	2mOyiHwRFJToOHDBGmoHdkpvynTz5Wh3xoE2dCmI1EYZXS3QltEnq2FoUBXX4MdzrsuD
	D9qYhWg22ljlYUfLbPxNEpCB7Sep3KJXNIWKRUXYOAjj0itR2DFCncS7WoGBHwGSYMVy
	MBqOWfJIce5ji+4i3qFWMMvMlmrF6Gsn7FcmnwvCMbTDD+smu0q7ef7t7yx8/3heEJR1
	nKiQ==
MIME-Version: 1.0
Received: by 10.152.105.197 with SMTP id go5mr4434192lab.43.1335551106634;
	Fri, 27 Apr 2012 11:25:06 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 11:25:06 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
	<CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
Date: Fri, 27 Apr 2012 11:25:06 -0700
Message-ID: <CAB10MZAbS73A5162MMxs9LzkEzNHYO-tGtrpk-H9_NpRuEAGuw@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQnYlgIdy5fF9nMVSlQqhkVzNVTy38qmxea4GGG0/k7jeIREokS5WTwopixKAssXcqhXMg0v
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 10:37 AM, Christian Limpach
<christian.limpach@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
>>
>> On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.co=
m>
>> wrote:
>>>
>>> Maybe you can do something similar, for example passing in a hint
>>> whether ept_sync_domain needs to be done or not. =A0In my case, the
>>> reasoning is that all the entries changed from hap_clean_vram_tracking
>>> are leaf entries, so ept_free_entry will never be called and thus
>>> ept_sync_domain can be deferred. =A0I didn't think through/consider the
>>> iommu case since that code is commented out in my tree.
>>
>> I thought about doing that initially. But then in the bulk case I would
>> always have to call ept_sync_domain() to be on the safe side. But if the
>> iommu case forces me down that path, then I guess I have no choice.
>
> I think you should re-consider. =A0It would avoid adding the extra
> wrapper, which makes this code a lot less readable. =A0Plus it avoids
> the need for the old_entries array.
>
> Let me re-iterate:
> - if it's a leaf entry, then there's no need to call ept_free_entry
> - if you don't need to call ept_free_entry, then you can defer
> ept_sync_domain (subject to the iommu case)
> - you could pass in a pointer to a bool to indicate to the caller that
> ept_sync_domain was deferred and that the caller needs to do it, with
> a NULL pointer indicating that the caller doesn't support defer

I understand now and like this approach. I will rework the patch and
send it out.

Thanks,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpsU-0006mo-WB; Fri, 27 Apr 2012 18:26:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNpsT-0006me-TS
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:26:46 +0000
Received: from [85.158.139.83:6782] by server-11.bemta-5.messagelabs.com id
	F9/80-12959-5E4EA9F4; Fri, 27 Apr 2012 18:26:45 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335551203!25838025!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11527 invoked from network); 27 Apr 2012 18:26:44 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:26:44 -0000
Received: by lahe6 with SMTP id e6so860446lah.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:26:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=1B5fv2AR843zZqyeQhIfk4q6rItp6TB9zfUVvT2v+Vo=;
	b=wvwQCMWaklwEQKiwxvGhmZ03BKp+WLbtjVeciKaNzDoFS5NOj/1Cjto0dkH/vfMOB7
	fmjyaBmrqgZwWxUPah+5G3p3MkzCsYTXZiWpYbOs7JSdjk5kgCwZFvRRP6sfTHuiXPBV
	r/2u1W7cAzp5wRprr4UZD3/e6WvMOFlMglSr8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=1B5fv2AR843zZqyeQhIfk4q6rItp6TB9zfUVvT2v+Vo=;
	b=XPX2e0yz8LNaZqHb10YgU6Xledwjpe54dHVuzclrYzhKmQgLZwtK1TrPMGOcRTKkiS
	ijKqPAVOzMl8rIb7k6gNNPujObRrWHY9gmMi7/YGvQ+GFpTPiiUDg2hPzFbeq4tllDg4
	aL3rKyRJdFIDEmJCuz002k1UwulrmMAzaGNNLktkpkX7YVh1Vq0d8Jm4dMkpR/DFJA+2
	g6nnksnCq0zwFYezA19lpTCeWRnan/Xy9UiJLkyZ87bY3BD3Fh/J9RuNCzIIJFB3bhU/
	H98vgmU8ywFJEX7GV93mNNS5eJ3gt8Ii+7x1q+Bu/iC9jq0Zx4OJl+qzDBlVVrplvXiE
	/IoA==
MIME-Version: 1.0
Received: by 10.152.129.74 with SMTP id nu10mr11353327lab.50.1335551202928;
	Fri, 27 Apr 2012 11:26:42 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 11:26:42 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <20120427084832.GA86045@ocelot.phlegethon.org>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
	<20120427084832.GA86045@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 11:26:42 -0700
Message-ID: <CAB10MZA=w3=EBsp2yqq5t2YXKhi2u9+m22r90b3Z7uVY0C1cFQ@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQkXGNErChF9v5WLyegdPu+V7AvVROHipbRfYt9JO70xqdE0aO7f5RdBSym0p+crh0TuauLQ
Cc: Christian.Limpach@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 1:48 AM, Tim Deegan <tim@xen.org> wrote:
> At 18:36 -0700 on 26 Apr (1335465381), Aravindh Puthiyaparambil wrote:
>> > - this is wrong:
>> > > - =A0 =A0 =A0 =A0old_entry =3D *ept_entry;
>> > > + =A0 =A0 =A0 =A0old_entry->epte =3D ept_entry->epte;
>> > You should follow the code and see what uses old_entry and you'll see
>> > that within the function old_entry->mfn is used (your diff changes the
>> > line that uses it) and ept_free_entry also accesses mfn.
>>
>> I will fix that.
>>
>> > - are you sure you can move the ept_sync_domain call past the iommu co=
de?
>> >
>>
>> I was hoping Tim would give me feedback about that.
>
> I'm afraid I won't be able to review this code until next week. =A0This
> change is already too late for the 4.2 freeze, though, so there's plenty
> of time to get it right after we branch.

Not a problem. This can wait for post 4.2. By then I would have
reworked it the way Christian was mentioning.

Thanks,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 18:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 18:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNpsU-0006mo-WB; Fri, 27 Apr 2012 18:26:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNpsT-0006me-TS
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:26:46 +0000
Received: from [85.158.139.83:6782] by server-11.bemta-5.messagelabs.com id
	F9/80-12959-5E4EA9F4; Fri, 27 Apr 2012 18:26:45 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1335551203!25838025!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11527 invoked from network); 27 Apr 2012 18:26:44 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:26:44 -0000
Received: by lahe6 with SMTP id e6so860446lah.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:26:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=1B5fv2AR843zZqyeQhIfk4q6rItp6TB9zfUVvT2v+Vo=;
	b=wvwQCMWaklwEQKiwxvGhmZ03BKp+WLbtjVeciKaNzDoFS5NOj/1Cjto0dkH/vfMOB7
	fmjyaBmrqgZwWxUPah+5G3p3MkzCsYTXZiWpYbOs7JSdjk5kgCwZFvRRP6sfTHuiXPBV
	r/2u1W7cAzp5wRprr4UZD3/e6WvMOFlMglSr8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=1B5fv2AR843zZqyeQhIfk4q6rItp6TB9zfUVvT2v+Vo=;
	b=XPX2e0yz8LNaZqHb10YgU6Xledwjpe54dHVuzclrYzhKmQgLZwtK1TrPMGOcRTKkiS
	ijKqPAVOzMl8rIb7k6gNNPujObRrWHY9gmMi7/YGvQ+GFpTPiiUDg2hPzFbeq4tllDg4
	aL3rKyRJdFIDEmJCuz002k1UwulrmMAzaGNNLktkpkX7YVh1Vq0d8Jm4dMkpR/DFJA+2
	g6nnksnCq0zwFYezA19lpTCeWRnan/Xy9UiJLkyZ87bY3BD3Fh/J9RuNCzIIJFB3bhU/
	H98vgmU8ywFJEX7GV93mNNS5eJ3gt8Ii+7x1q+Bu/iC9jq0Zx4OJl+qzDBlVVrplvXiE
	/IoA==
MIME-Version: 1.0
Received: by 10.152.129.74 with SMTP id nu10mr11353327lab.50.1335551202928;
	Fri, 27 Apr 2012 11:26:42 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 11:26:42 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <20120427084832.GA86045@ocelot.phlegethon.org>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
	<20120427084832.GA86045@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 11:26:42 -0700
Message-ID: <CAB10MZA=w3=EBsp2yqq5t2YXKhi2u9+m22r90b3Z7uVY0C1cFQ@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQkXGNErChF9v5WLyegdPu+V7AvVROHipbRfYt9JO70xqdE0aO7f5RdBSym0p+crh0TuauLQ
Cc: Christian.Limpach@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 1:48 AM, Tim Deegan <tim@xen.org> wrote:
> At 18:36 -0700 on 26 Apr (1335465381), Aravindh Puthiyaparambil wrote:
>> > - this is wrong:
>> > > - =A0 =A0 =A0 =A0old_entry =3D *ept_entry;
>> > > + =A0 =A0 =A0 =A0old_entry->epte =3D ept_entry->epte;
>> > You should follow the code and see what uses old_entry and you'll see
>> > that within the function old_entry->mfn is used (your diff changes the
>> > line that uses it) and ept_free_entry also accesses mfn.
>>
>> I will fix that.
>>
>> > - are you sure you can move the ept_sync_domain call past the iommu co=
de?
>> >
>>
>> I was hoping Tim would give me feedback about that.
>
> I'm afraid I won't be able to review this code until next week. =A0This
> change is already too late for the 4.2 freeze, though, so there's plenty
> of time to get it right after we branch.

Not a problem. This can wait for post 4.2. By then I would have
reworked it the way Christian was mentioning.

Thanks,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:09:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsOu-0007sN-7W; Fri, 27 Apr 2012 21:08:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsOt-0007sI-1b
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 21:08:23 +0000
Received: from [193.109.254.147:58865] by server-1.bemta-14.messagelabs.com id
	CC/9A-29372-6CA0B9F4; Fri, 27 Apr 2012 21:08:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335560900!6691652!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjM0MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28093 invoked from network); 27 Apr 2012 21:08:21 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-13.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 21:08:21 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3474B4B007C;
	Fri, 27 Apr 2012 14:08:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=WPNzOBBnlSMpdHvx8AtDiWS7lZw0/8s6EnfbFHk4AXmP
	cZbXlaw06c4JU0WJzs32cLQS3+9Rm8eXh3n9ibS1yOOg508H4W45BWd4LnddVAXx
	C+HX7A3Itf7pYTeu6VbVWLpNxetwvoicxTEi0x2MOq+eqmiUYCDzOLF85Sb2Ujc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xm2XFVmRSCSOgg10yZRYtY+ho54=; b=sKxr9r5o
	Oets8fTbDubN16smhjtZlJT9+/POLzEcAbxlayTB3pCG2tATilwVFQOVzQFL3dJ8
	l1p9a0eq6RpaiG6NH7+hwWHMdJ8T6EW8FsfEUoJYZXx/IZKuYoaqfmreRYRjjVaD
	xbuiMpU9X84EbPUtxVaiAK8PtPukiyMupUQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 8B0254B006D; 
	Fri, 27 Apr 2012 14:08:19 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 27 Apr 2012 14:08:20 -0700
Message-ID: <ed59d3a342e079902f20b76e360644a1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120427092645.GC86045@ocelot.phlegethon.org>
References: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
	<20120427092645.GC86045@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 14:08:20 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, oalf@aepfle.de,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, George.Dunlap@eu.citrix.com
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 20:02 -0700 on 26 Apr (1335470547), Andres Lagar-Cavilla wrote:
>> > Can you please try the attached patch?  I think you'll need this one
>> > plus the ones that take the locks out of the hpet code.
>>
>> Right off the bat I'm getting a multitude of
>> (XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
>> And a hung dom0 during initramfs. I'm a little baffled as to why, but
>> it's
>> there (32 bit dom0, XenServer6).
>
> Curses, I knew there'd be one somewhere.  I've been replacing
> get_page_and_type_from_pagenr()s (which return 0 for success) with
> old-school get_page_type()s (which return 1 for success) and not always
> getting the right number of inversions.  That's a horrible horrible
> beartrap of an API, BTW, which had me cursing at the screen, but I had
> enough on my plate yesterday without touching _that_ code too!
>

I now am quite pleased with the testing results on our end. I have a
four-patch series to top up your monster patch, which I'll submit shortly.
I encourage everyone interested to test this (obviously a lot of code is
touched). Including AMD, as I've expanded the code to touch svm too.

>> > Andres, this is basically the big-hammer version of your "take a
>> > pagecount" changes, plus the change you made to hvmemul_rep_movs().
>> > If this works I intend to follow it up with a patch to make some of
>> the
>> > read-modify-write paths avoid taking the lock (by using a
>> > compare-exchange operation so they only take the lock on a write).  If
>> > that succeeds I might drop put_gfn() altogether.
>>
>> You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
>> There are code paths that do get_gfn_query -> p2m_change_type ->
>> put_gfn.
>> But I guess those could lock the p2m up-front if they become the only
>> consumers of put_gfn left.
>
> Well, that's more or less what happens now.  I was thinking of replacing
> any remaining
>
>  (implicit) lock ; read ; think a bit ; maybe write ; unlock
>
> code with the fast-path-friendlier:
>
>  read ; think ; maybe-cmpxchg (and on failure undo or retry
>
> which avoids taking the write lock altogether if there's no work to do.
> But maybe there aren't many of those left now.  Obviously any path
> which will always write should just take the write-lock first.

After my four patches there aren't really any paths like the above left
(exhaustion disclaimer). I believe one or two iterative paths (like
HVMOP_set_mem_type) could be optimized to take the p2m lock up front,
instead of many get_gfn's.

The nice thing about get_gfn/put_gfn is that it will allow for seamless
(har har) transition to a fine-grained p2m. But then maybe we won't ever
need that with a p2m rwlock.

>
>> >  - grant-table operations still use the lock, because frankly I
>> >    could not follow the current code, and it's quite late in the
>> evening.
>>
>> It's pretty complex with serious nesting, and ifdef's for arm and 32
>> bit.
>> gfn_to_mfn_private callers will suffer from altering the current
>> meaning,
>> as put_gfn resolves to the right thing for the ifdef'ed arch. The other
>> user is grant_transfer which also relies on the page *not* having an
>> extra
>> ref in steal_page. So it's a prime candidate to be left alone.
>
> Sadly, I think it's not.  The PV backends will be doing lots of grant
> ops, which shouldn't get serialized against all other P2M lookups.
>

Those are addressed in my patch series now, which should case waves of panic.

Andres

>> > I also have a long list of uglinesses in the mm code that I found
>>
>> Uh, ugly stuff, how could that have happened?
>
> I can't imagine. :)  Certainly nothing to do with me thinking "I'll
> clean that up when I get some time."
>
>> I have a few preliminary observations on the patch. Pasting relevant
>> bits
>> here, since the body of the patch seems to have been lost by the email
>> thread:
>>
>> @@ -977,23 +976,25 @@ int arch_set_info_guest(
>> ...
>> +
>> +        if (!paging_mode_refcounts(d)
>> +            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
>> replace with && !get_page_type() )
>
> Yep.
>
>> @@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
>>              gfn = addr >> PAGE_SHIFT;
>>          }
>>
>> -        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
>> +        page = get_page_from_gfn(curr->domain, gfn, &p2mt,
>> P2M_UNSHARE);
>> replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
>> same logic when checking p2m_is_shared). Not truly related to your patch
>> bit since we're at it.
>
> OK, but not in this patch.
>
>> Same, further down
>> -        if ( !p2m_is_ram(p2mt) )
>> +        if ( !page )
>>          {
>> -            put_gfn(curr->domain, gfn);
>> +            if ( page )
>> +                put_page(page);
>> Last two lines are redundant
>
> Yep.
>
>> @@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
>>     case HVMOP_modified_memory: a lot of error checking has been
>> removed.
>
> Yes, but it was bogus - there's a race between the actual modification
> and the call, during which anything might have happened.  The best we
> can do is throw log-dirty bits at everything, and the caller can't do
> anything with the error anyway.
>
> When I come to tidy up I'll just add a new mark_gfn_dirty function
> and skip the pointless gfn->mfn->gfn translation on this path.
>
>> arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing
>> checking
>> for target gfns of mmu updates of l2/3/4 entries. It seems that this
>> wouldn't work anyways, that's why you killed it?
>
> Yeah - since only L1es can point at foreign mappings it was all just
> noise, and even if there had been real p2m lookups on those paths there
> was no equivalent to the translate-in-place that happens in
> mod_l1_entry so it would have been broken in a much worse way.
>
>> +++ b/xen/arch/x86/mm/hap/guest_walk.c
>> @@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>> ...
>> +    if ( !top_page )
>>      {
>>          pfec[0] &= ~PFEC_page_present;
>> -        __put_gfn(p2m, top_gfn);
>> +        put_page(top_page);
>> top_page is NULL here, remove put_page
>
> Yep.
>
>> get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
>> locking is already done by get_gfn_type_access/__put_gfn
>
> Yeah, but I was writing that with half an eye on killing that lock. :)
> I'll drop them for now.
>
>> (hope those observations made sense without inlining them in the actual
>> patch)
>
> Yes, absolutely - thanks for the review!
>
> If we can get this to work well enough I'll tidy it up into a sensible
> series next week.   In the meantime, an updated verison of the
> monster patch is attached.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:09:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsOu-0007sN-7W; Fri, 27 Apr 2012 21:08:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsOt-0007sI-1b
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 21:08:23 +0000
Received: from [193.109.254.147:58865] by server-1.bemta-14.messagelabs.com id
	CC/9A-29372-6CA0B9F4; Fri, 27 Apr 2012 21:08:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335560900!6691652!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjM0MjI=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28093 invoked from network); 27 Apr 2012 21:08:21 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-13.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 21:08:21 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3474B4B007C;
	Fri, 27 Apr 2012 14:08:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=WPNzOBBnlSMpdHvx8AtDiWS7lZw0/8s6EnfbFHk4AXmP
	cZbXlaw06c4JU0WJzs32cLQS3+9Rm8eXh3n9ibS1yOOg508H4W45BWd4LnddVAXx
	C+HX7A3Itf7pYTeu6VbVWLpNxetwvoicxTEi0x2MOq+eqmiUYCDzOLF85Sb2Ujc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xm2XFVmRSCSOgg10yZRYtY+ho54=; b=sKxr9r5o
	Oets8fTbDubN16smhjtZlJT9+/POLzEcAbxlayTB3pCG2tATilwVFQOVzQFL3dJ8
	l1p9a0eq6RpaiG6NH7+hwWHMdJ8T6EW8FsfEUoJYZXx/IZKuYoaqfmreRYRjjVaD
	xbuiMpU9X84EbPUtxVaiAK8PtPukiyMupUQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 8B0254B006D; 
	Fri, 27 Apr 2012 14:08:19 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 27 Apr 2012 14:08:20 -0700
Message-ID: <ed59d3a342e079902f20b76e360644a1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120427092645.GC86045@ocelot.phlegethon.org>
References: <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F2A20@SHSMSX101.ccr.corp.intel.com>
	<20120424091646.GB34721@ocelot.phlegethon.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F452D@SHSMSX101.ccr.corp.intel.com>
	<958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F45FC@SHSMSX101.ccr.corp.intel.com>
	<dfb5bcde9672a20ef3d6b3ad846a40e3.squirrel@webmail.lagarcavilla.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0F4684@SHSMSX101.ccr.corp.intel.com>
	<20120426212531.GH67043@ocelot.phlegethon.org>
	<23c9d6057801250ebf2a9713a1bc5af3.squirrel@webmail.lagarcavilla.org>
	<20120427092645.GC86045@ocelot.phlegethon.org>
Date: Fri, 27 Apr 2012 14:08:20 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, oalf@aepfle.de,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, George.Dunlap@eu.citrix.com
Subject: Re: [Xen-devel] lock in vhpet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 20:02 -0700 on 26 Apr (1335470547), Andres Lagar-Cavilla wrote:
>> > Can you please try the attached patch?  I think you'll need this one
>> > plus the ones that take the locks out of the hpet code.
>>
>> Right off the bat I'm getting a multitude of
>> (XEN) mm.c:3294:d0 Error while clearing mfn 100cbb7
>> And a hung dom0 during initramfs. I'm a little baffled as to why, but
>> it's
>> there (32 bit dom0, XenServer6).
>
> Curses, I knew there'd be one somewhere.  I've been replacing
> get_page_and_type_from_pagenr()s (which return 0 for success) with
> old-school get_page_type()s (which return 1 for success) and not always
> getting the right number of inversions.  That's a horrible horrible
> beartrap of an API, BTW, which had me cursing at the screen, but I had
> enough on my plate yesterday without touching _that_ code too!
>

I now am quite pleased with the testing results on our end. I have a
four-patch series to top up your monster patch, which I'll submit shortly.
I encourage everyone interested to test this (obviously a lot of code is
touched). Including AMD, as I've expanded the code to touch svm too.

>> > Andres, this is basically the big-hammer version of your "take a
>> > pagecount" changes, plus the change you made to hvmemul_rep_movs().
>> > If this works I intend to follow it up with a patch to make some of
>> the
>> > read-modify-write paths avoid taking the lock (by using a
>> > compare-exchange operation so they only take the lock on a write).  If
>> > that succeeds I might drop put_gfn() altogether.
>>
>> You mean cmpxchg the whole p2m entry? I don't think I parse the plan.
>> There are code paths that do get_gfn_query -> p2m_change_type ->
>> put_gfn.
>> But I guess those could lock the p2m up-front if they become the only
>> consumers of put_gfn left.
>
> Well, that's more or less what happens now.  I was thinking of replacing
> any remaining
>
>  (implicit) lock ; read ; think a bit ; maybe write ; unlock
>
> code with the fast-path-friendlier:
>
>  read ; think ; maybe-cmpxchg (and on failure undo or retry
>
> which avoids taking the write lock altogether if there's no work to do.
> But maybe there aren't many of those left now.  Obviously any path
> which will always write should just take the write-lock first.

After my four patches there aren't really any paths like the above left
(exhaustion disclaimer). I believe one or two iterative paths (like
HVMOP_set_mem_type) could be optimized to take the p2m lock up front,
instead of many get_gfn's.

The nice thing about get_gfn/put_gfn is that it will allow for seamless
(har har) transition to a fine-grained p2m. But then maybe we won't ever
need that with a p2m rwlock.

>
>> >  - grant-table operations still use the lock, because frankly I
>> >    could not follow the current code, and it's quite late in the
>> evening.
>>
>> It's pretty complex with serious nesting, and ifdef's for arm and 32
>> bit.
>> gfn_to_mfn_private callers will suffer from altering the current
>> meaning,
>> as put_gfn resolves to the right thing for the ifdef'ed arch. The other
>> user is grant_transfer which also relies on the page *not* having an
>> extra
>> ref in steal_page. So it's a prime candidate to be left alone.
>
> Sadly, I think it's not.  The PV backends will be doing lots of grant
> ops, which shouldn't get serialized against all other P2M lookups.
>

Those are addressed in my patch series now, which should case waves of panic.

Andres

>> > I also have a long list of uglinesses in the mm code that I found
>>
>> Uh, ugly stuff, how could that have happened?
>
> I can't imagine. :)  Certainly nothing to do with me thinking "I'll
> clean that up when I get some time."
>
>> I have a few preliminary observations on the patch. Pasting relevant
>> bits
>> here, since the body of the patch seems to have been lost by the email
>> thread:
>>
>> @@ -977,23 +976,25 @@ int arch_set_info_guest(
>> ...
>> +
>> +        if (!paging_mode_refcounts(d)
>> +            && !get_page_and_type(cr3_page, d, PGT_l3_page_table) )
>> replace with && !get_page_type() )
>
> Yep.
>
>> @@ -2404,32 +2373,33 @@ static enum hvm_copy_result __hvm_copy(
>>              gfn = addr >> PAGE_SHIFT;
>>          }
>>
>> -        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
>> +        page = get_page_from_gfn(curr->domain, gfn, &p2mt,
>> P2M_UNSHARE);
>> replace with (flags & HVMCOPY_to_guest) ? P2M_UNSHARE : P2M_ALLOC (and
>> same logic when checking p2m_is_shared). Not truly related to your patch
>> bit since we're at it.
>
> OK, but not in this patch.
>
>> Same, further down
>> -        if ( !p2m_is_ram(p2mt) )
>> +        if ( !page )
>>          {
>> -            put_gfn(curr->domain, gfn);
>> +            if ( page )
>> +                put_page(page);
>> Last two lines are redundant
>
> Yep.
>
>> @@ -4019,35 +3993,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
>>     case HVMOP_modified_memory: a lot of error checking has been
>> removed.
>
> Yes, but it was bogus - there's a race between the actual modification
> and the call, during which anything might have happened.  The best we
> can do is throw log-dirty bits at everything, and the caller can't do
> anything with the error anyway.
>
> When I come to tidy up I'll just add a new mark_gfn_dirty function
> and skip the pointless gfn->mfn->gfn translation on this path.
>
>> arch/x86/mm.c:do_mmu_update -> you blew up all the paging/sharing
>> checking
>> for target gfns of mmu updates of l2/3/4 entries. It seems that this
>> wouldn't work anyways, that's why you killed it?
>
> Yeah - since only L1es can point at foreign mappings it was all just
> noise, and even if there had been real p2m lookups on those paths there
> was no equivalent to the translate-in-place that happens in
> mod_l1_entry so it would have been broken in a much worse way.
>
>> +++ b/xen/arch/x86/mm/hap/guest_walk.c
>> @@ -54,34 +54,37 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
>> ...
>> +    if ( !top_page )
>>      {
>>          pfec[0] &= ~PFEC_page_present;
>> -        __put_gfn(p2m, top_gfn);
>> +        put_page(top_page);
>> top_page is NULL here, remove put_page
>
> Yep.
>
>> get_page_from_gfn_p2m, slow path: no need for p2m_lock/unlock since
>> locking is already done by get_gfn_type_access/__put_gfn
>
> Yeah, but I was writing that with half an eye on killing that lock. :)
> I'll drop them for now.
>
>> (hope those observations made sense without inlining them in the actual
>> patch)
>
> Yes, absolutely - thanks for the review!
>
> If we can get this to work well enough I'll tidy it up into a sensible
> series next week.   In the meantime, an updated verison of the
> monster patch is attached.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRQ-0007yG-FL; Fri, 27 Apr 2012 21:11:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRO-0007xT-Tz
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:59 +0000
Received: from [193.109.254.147:6740] by server-1.bemta-14.messagelabs.com id
	5E/DB-29372-26B0B9F4; Fri, 27 Apr 2012 21:10:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335561055!6694123!2
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjE4MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2750 invoked from network); 27 Apr 2012 21:10:57 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 21:10:57 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 96E6B714083;
	Fri, 27 Apr 2012 14:10:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=rWyHvIEXFyZCxOeazSjMVIM6Jo1+dvhIM9x7CIDI528y
	gRaVA2onKydifAu6ZWOlljQf3xjnM9diFfT7wbLz83D6iHH3dLsrwamM11Uyp9dD
	1BjQjOciP9bLpAz/lY10S4aFo/CFKVPXPZUxgZYaj5M9zXanidDNXqcdXXDMHOU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EbRaj7BQ8rQxtdBCmSz1tFIyU8M=; b=eiwH8bbesJP
	S0FasfQwkFMV0ei9mZZ5eQ5eqfxrzGPRKYtchYdn3tJ38hrwAD/nJpyl9TGkrIJG
	U3caV3wkTMSn0RPzqtIMdy1Ob0k1ZhXgpcpBtWJEdCratpXj2siX26jVsGs5hi3D
	4AM/OOM3fpRIeIJGRgfmH7sDY/R7bgBE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 1046E71406B; 
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8674ecae829caca1c8f6a1574cc2ebfb643c9ec6
Message-Id: <8674ecae829caca1c8f6.1335561381@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 4 of 4] Expand use of get_page_from_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c         |  48 ++++++++++++++++++----------------------------
 xen/common/memory.c       |   9 +++++++-
 xen/common/tmem_xen.c     |  26 +++++++++---------------
 xen/include/asm-x86/p2m.h |  11 ----------
 xen/xsm/flask/hooks.c     |  19 ++++++++++++++---
 5 files changed, 52 insertions(+), 61 deletions(-)


Replace get_gfn* calls in common/memory.c, arch/x86/mm.c, xsm, and tmem.

Fix bugs on xsm for get_gfn_untyped and get_page_from_gfn.

Eliminate altogether get_gfn_untyped.

Add appropriate ifdefe'ery in common code so that ARM isn't trapped.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 07fda1825c29 -r 8674ecae829c xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3731,18 +3731,17 @@ static int create_grant_pte_mapping(
     adjust_guest_l1e(nl1e, d);
 
     gmfn = pte_addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)pte_addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3773,7 +3772,6 @@ static int create_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
 
     return rc;
 }
@@ -3788,18 +3786,17 @@ static int destroy_grant_pte_mapping(
     l1_pgentry_t ol1e;
 
     gmfn = addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3844,7 +3841,6 @@ static int destroy_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
     return rc;
 }
 
@@ -4367,11 +4363,12 @@ long set_gdt(struct vcpu *v,
     /* Check the pages in the new GDT. */
     for ( i = 0; i < nr_pages; i++ )
     {
+        struct page_info *page;
         pfns[i] = frames[i];
-        mfn = frames[i] = get_gfn_untyped(d, frames[i]);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
+        page = get_page_from_gfn(d, frames[i], NULL, P2M_ALLOC);
+        if ( !page || !get_page_type(page, PGT_seg_desc_page) )
             goto fail;
+        mfn = frames[i] = page_to_mfn(page);
     }
 
     /* Tear down the old GDT. */
@@ -4384,7 +4381,6 @@ long set_gdt(struct vcpu *v,
         v->arch.pv_vcpu.gdt_frames[i] = frames[i];
         l1e_write(&v->arch.perdomain_ptes[i],
                   l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
-        put_gfn(d, pfns[i]);
     }
 
     xfree(pfns);
@@ -4394,7 +4390,6 @@ long set_gdt(struct vcpu *v,
     while ( i-- > 0 )
     {
         put_page_and_type(mfn_to_page(frames[i]));
-        put_gfn(d, pfns[i]);
     }
     xfree(pfns);
     return -EINVAL;
@@ -4440,21 +4435,16 @@ long do_update_descriptor(u64 pa, u64 de
 
     *(u64 *)&d = desc;
 
-    mfn = get_gfn_untyped(dom, gmfn);
+    page = get_page_from_gfn(dom, gmfn, NULL, P2M_ALLOC);
     if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) ||
-         !mfn_valid(mfn) ||
+         !page ||
          !check_descriptor(dom, &d) )
     {
-        put_gfn(dom, gmfn);
+        if ( page )
+            put_page(page);
         return -EINVAL;
     }
-
-    page = mfn_to_page(mfn);
-    if ( unlikely(!get_page(page, dom)) )
-    {
-        put_gfn(dom, gmfn);
-        return -EINVAL;
-    }
+    mfn = page_to_mfn(page);
 
     /* Check if the given frame is in use in an unsafe context. */
     switch ( page->u.inuse.type_info & PGT_type_mask )
@@ -4482,7 +4472,6 @@ long do_update_descriptor(u64 pa, u64 de
 
  out:
     put_page(page);
-    put_gfn(dom, gmfn);
 
     return ret;
 }
@@ -4529,6 +4518,7 @@ static int xenmem_add_to_physmap_once(
     unsigned long gfn = 0; /* gcc ... */
     unsigned long prev_mfn, mfn = 0, gpfn, idx;
     int rc;
+    p2m_type_t p2mt;
 
     switch ( xatp->space )
     {
@@ -4617,7 +4607,7 @@ static int xenmem_add_to_physmap_once(
         put_page(page);
 
     /* Remove previously mapped page if it was present. */
-    prev_mfn = get_gfn_untyped(d, xatp->gpfn);
+    prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt));
     if ( mfn_valid(prev_mfn) )
     {
         if ( is_xen_heap_mfn(prev_mfn) )
diff -r 07fda1825c29 -r 8674ecae829c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -694,7 +694,14 @@ long do_memory_op(unsigned long cmd, XEN
 
         domain_lock(d);
 
-        mfn = get_gfn_untyped(d, xrfp.gpfn);
+#ifdef CONFIG_X86
+        {
+            p2m_type_t p2mt;
+            mfn = mfn_x(get_gfn(d, xrfp.gpfn, &p2mt));
+        }
+#else
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+#endif
 
         if ( mfn_valid(mfn) )
             guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
diff -r 07fda1825c29 -r 8674ecae829c xen/common/tmem_xen.c
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -107,30 +107,25 @@ static inline void cli_put_page(tmem_cli
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
-    unsigned long cli_mfn;
     p2m_type_t t;
     struct page_info *page;
-    int ret;
 
-    cli_mfn = mfn_x(get_gfn(current->domain, cmfn, &t));
-    if ( t != p2m_ram_rw || !mfn_valid(cli_mfn) )
+    page = get_page_from_gfn(current->domain, cmfn, &t, P2M_ALLOC);
+    if ( !page || t != p2m_ram_rw )
     {
-            put_gfn(current->domain, (unsigned long) cmfn);
-            return NULL;
+        if ( page )
+            put_page(page);
     }
-    page = mfn_to_page(cli_mfn);
-    if ( cli_write )
-        ret = get_page_and_type(page, current->domain, PGT_writable_page);
-    else
-        ret = get_page(page, current->domain);
-    if ( !ret )
+
+    if ( cli_write && !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(current->domain, (unsigned long) cmfn);
+        put_page(page);
         return NULL;
     }
-    *pcli_mfn = cli_mfn;
+
+    *pcli_mfn = page_to_mfn(page);
     *pcli_pfp = (pfp_t *)page;
-    return map_domain_page(cli_mfn);
+    return map_domain_page(*pcli_mfn);
 }
 
 static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
@@ -144,7 +139,6 @@ static inline void cli_put_page(tmem_cli
     else
         put_page((struct page_info *)cli_pfp);
     unmap_domain_page(cli_va);
-    put_gfn(current->domain, (unsigned long) cmfn);
 }
 #endif
 
diff -r 07fda1825c29 -r 8674ecae829c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -350,17 +350,6 @@ static inline mfn_t get_gfn_type(struct 
 #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \
                                               P2M_ALLOC | P2M_UNSHARE)
 
-/* Compatibility function exporting the old untyped interface */
-static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
-{
-    mfn_t mfn;
-    p2m_type_t t;
-    mfn = get_gfn(d, gpfn, &t);
-    if ( p2m_is_valid(t) )
-        return mfn_x(mfn);
-    return INVALID_MFN;
-}
-
 /* Will release the p2m_lock for this gfn entry. */
 void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
diff -r 07fda1825c29 -r 8674ecae829c xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1318,7 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
-    struct page_info *page;
+    struct page_info *page = NULL;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1334,9 +1334,12 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), NULL, P2M_ALLOC);
     mfn = page ? page_to_mfn(page) : INVALID_MFN;
-
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+#endif
     ad.sdom = d;
     ad.tdom = f;
     ad.memory.pte = fpte;
@@ -1373,6 +1376,7 @@ static int flask_update_va_mapping(struc
     int rc = 0;
     u32 psid;
     u32 map_perms = MMU__MAP_READ;
+    struct page_info *page = NULL;
     unsigned long mfn;
     struct domain_security_struct *dsec;
 
@@ -1384,8 +1388,15 @@ static int flask_update_va_mapping(struc
 
     dsec = d->ssid;
 
-    mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(pte), NULL, P2M_ALLOC);
+    mfn = (page) ? page_to_mfn(page) : INVALID_MFN;
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(pte));
+#endif
     rc = get_mfn_sid(mfn, &psid);
+    if ( page )
+        put_page(page);
     if ( rc )
         return rc;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRQ-0007yG-FL; Fri, 27 Apr 2012 21:11:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRO-0007xT-Tz
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:59 +0000
Received: from [193.109.254.147:6740] by server-1.bemta-14.messagelabs.com id
	5E/DB-29372-26B0B9F4; Fri, 27 Apr 2012 21:10:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335561055!6694123!2
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjE4MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2750 invoked from network); 27 Apr 2012 21:10:57 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 21:10:57 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 96E6B714083;
	Fri, 27 Apr 2012 14:10:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=rWyHvIEXFyZCxOeazSjMVIM6Jo1+dvhIM9x7CIDI528y
	gRaVA2onKydifAu6ZWOlljQf3xjnM9diFfT7wbLz83D6iHH3dLsrwamM11Uyp9dD
	1BjQjOciP9bLpAz/lY10S4aFo/CFKVPXPZUxgZYaj5M9zXanidDNXqcdXXDMHOU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EbRaj7BQ8rQxtdBCmSz1tFIyU8M=; b=eiwH8bbesJP
	S0FasfQwkFMV0ei9mZZ5eQ5eqfxrzGPRKYtchYdn3tJ38hrwAD/nJpyl9TGkrIJG
	U3caV3wkTMSn0RPzqtIMdy1Ob0k1ZhXgpcpBtWJEdCratpXj2siX26jVsGs5hi3D
	4AM/OOM3fpRIeIJGRgfmH7sDY/R7bgBE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 1046E71406B; 
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8674ecae829caca1c8f6a1574cc2ebfb643c9ec6
Message-Id: <8674ecae829caca1c8f6.1335561381@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:21 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 4 of 4] Expand use of get_page_from_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c         |  48 ++++++++++++++++++----------------------------
 xen/common/memory.c       |   9 +++++++-
 xen/common/tmem_xen.c     |  26 +++++++++---------------
 xen/include/asm-x86/p2m.h |  11 ----------
 xen/xsm/flask/hooks.c     |  19 ++++++++++++++---
 5 files changed, 52 insertions(+), 61 deletions(-)


Replace get_gfn* calls in common/memory.c, arch/x86/mm.c, xsm, and tmem.

Fix bugs on xsm for get_gfn_untyped and get_page_from_gfn.

Eliminate altogether get_gfn_untyped.

Add appropriate ifdefe'ery in common code so that ARM isn't trapped.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 07fda1825c29 -r 8674ecae829c xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3731,18 +3731,17 @@ static int create_grant_pte_mapping(
     adjust_guest_l1e(nl1e, d);
 
     gmfn = pte_addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)pte_addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3773,7 +3772,6 @@ static int create_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
 
     return rc;
 }
@@ -3788,18 +3786,17 @@ static int destroy_grant_pte_mapping(
     l1_pgentry_t ol1e;
 
     gmfn = addr >> PAGE_SHIFT;
-    mfn = get_gfn_untyped(d, gmfn);
-
-    if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) )
+    page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+
+    if ( unlikely(!page) )
     {
-        put_gfn(d, gmfn);
         MEM_LOG("Could not get page for normal update");
         return GNTST_general_error;
     }
     
+    mfn = page_to_mfn(page);
     va = map_domain_page(mfn);
     va = (void *)((unsigned long)va + ((unsigned long)addr & ~PAGE_MASK));
-    page = mfn_to_page(mfn);
 
     if ( !page_lock(page) )
     {
@@ -3844,7 +3841,6 @@ static int destroy_grant_pte_mapping(
  failed:
     unmap_domain_page(va);
     put_page(page);
-    put_gfn(d, gmfn);
     return rc;
 }
 
@@ -4367,11 +4363,12 @@ long set_gdt(struct vcpu *v,
     /* Check the pages in the new GDT. */
     for ( i = 0; i < nr_pages; i++ )
     {
+        struct page_info *page;
         pfns[i] = frames[i];
-        mfn = frames[i] = get_gfn_untyped(d, frames[i]);
-        if ( !mfn_valid(mfn) ||
-             !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
+        page = get_page_from_gfn(d, frames[i], NULL, P2M_ALLOC);
+        if ( !page || !get_page_type(page, PGT_seg_desc_page) )
             goto fail;
+        mfn = frames[i] = page_to_mfn(page);
     }
 
     /* Tear down the old GDT. */
@@ -4384,7 +4381,6 @@ long set_gdt(struct vcpu *v,
         v->arch.pv_vcpu.gdt_frames[i] = frames[i];
         l1e_write(&v->arch.perdomain_ptes[i],
                   l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
-        put_gfn(d, pfns[i]);
     }
 
     xfree(pfns);
@@ -4394,7 +4390,6 @@ long set_gdt(struct vcpu *v,
     while ( i-- > 0 )
     {
         put_page_and_type(mfn_to_page(frames[i]));
-        put_gfn(d, pfns[i]);
     }
     xfree(pfns);
     return -EINVAL;
@@ -4440,21 +4435,16 @@ long do_update_descriptor(u64 pa, u64 de
 
     *(u64 *)&d = desc;
 
-    mfn = get_gfn_untyped(dom, gmfn);
+    page = get_page_from_gfn(dom, gmfn, NULL, P2M_ALLOC);
     if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) ||
-         !mfn_valid(mfn) ||
+         !page ||
          !check_descriptor(dom, &d) )
     {
-        put_gfn(dom, gmfn);
+        if ( page )
+            put_page(page);
         return -EINVAL;
     }
-
-    page = mfn_to_page(mfn);
-    if ( unlikely(!get_page(page, dom)) )
-    {
-        put_gfn(dom, gmfn);
-        return -EINVAL;
-    }
+    mfn = page_to_mfn(page);
 
     /* Check if the given frame is in use in an unsafe context. */
     switch ( page->u.inuse.type_info & PGT_type_mask )
@@ -4482,7 +4472,6 @@ long do_update_descriptor(u64 pa, u64 de
 
  out:
     put_page(page);
-    put_gfn(dom, gmfn);
 
     return ret;
 }
@@ -4529,6 +4518,7 @@ static int xenmem_add_to_physmap_once(
     unsigned long gfn = 0; /* gcc ... */
     unsigned long prev_mfn, mfn = 0, gpfn, idx;
     int rc;
+    p2m_type_t p2mt;
 
     switch ( xatp->space )
     {
@@ -4617,7 +4607,7 @@ static int xenmem_add_to_physmap_once(
         put_page(page);
 
     /* Remove previously mapped page if it was present. */
-    prev_mfn = get_gfn_untyped(d, xatp->gpfn);
+    prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt));
     if ( mfn_valid(prev_mfn) )
     {
         if ( is_xen_heap_mfn(prev_mfn) )
diff -r 07fda1825c29 -r 8674ecae829c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -694,7 +694,14 @@ long do_memory_op(unsigned long cmd, XEN
 
         domain_lock(d);
 
-        mfn = get_gfn_untyped(d, xrfp.gpfn);
+#ifdef CONFIG_X86
+        {
+            p2m_type_t p2mt;
+            mfn = mfn_x(get_gfn(d, xrfp.gpfn, &p2mt));
+        }
+#else
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+#endif
 
         if ( mfn_valid(mfn) )
             guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
diff -r 07fda1825c29 -r 8674ecae829c xen/common/tmem_xen.c
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -107,30 +107,25 @@ static inline void cli_put_page(tmem_cli
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
-    unsigned long cli_mfn;
     p2m_type_t t;
     struct page_info *page;
-    int ret;
 
-    cli_mfn = mfn_x(get_gfn(current->domain, cmfn, &t));
-    if ( t != p2m_ram_rw || !mfn_valid(cli_mfn) )
+    page = get_page_from_gfn(current->domain, cmfn, &t, P2M_ALLOC);
+    if ( !page || t != p2m_ram_rw )
     {
-            put_gfn(current->domain, (unsigned long) cmfn);
-            return NULL;
+        if ( page )
+            put_page(page);
     }
-    page = mfn_to_page(cli_mfn);
-    if ( cli_write )
-        ret = get_page_and_type(page, current->domain, PGT_writable_page);
-    else
-        ret = get_page(page, current->domain);
-    if ( !ret )
+
+    if ( cli_write && !get_page_type(page, PGT_writable_page) )
     {
-        put_gfn(current->domain, (unsigned long) cmfn);
+        put_page(page);
         return NULL;
     }
-    *pcli_mfn = cli_mfn;
+
+    *pcli_mfn = page_to_mfn(page);
     *pcli_pfp = (pfp_t *)page;
-    return map_domain_page(cli_mfn);
+    return map_domain_page(*pcli_mfn);
 }
 
 static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
@@ -144,7 +139,6 @@ static inline void cli_put_page(tmem_cli
     else
         put_page((struct page_info *)cli_pfp);
     unmap_domain_page(cli_va);
-    put_gfn(current->domain, (unsigned long) cmfn);
 }
 #endif
 
diff -r 07fda1825c29 -r 8674ecae829c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -350,17 +350,6 @@ static inline mfn_t get_gfn_type(struct 
 #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \
                                               P2M_ALLOC | P2M_UNSHARE)
 
-/* Compatibility function exporting the old untyped interface */
-static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
-{
-    mfn_t mfn;
-    p2m_type_t t;
-    mfn = get_gfn(d, gpfn, &t);
-    if ( p2m_is_valid(t) )
-        return mfn_x(mfn);
-    return INVALID_MFN;
-}
-
 /* Will release the p2m_lock for this gfn entry. */
 void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
diff -r 07fda1825c29 -r 8674ecae829c xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1318,7 +1318,7 @@ static int flask_mmu_normal_update(struc
     struct domain_security_struct *dsec;
     u32 fsid;
     struct avc_audit_data ad;
-    struct page_info *page;
+    struct page_info *page = NULL;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1334,9 +1334,12 @@ static int flask_mmu_normal_update(struc
         map_perms |= MMU__MAP_WRITE;
 
     AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), P2M_ALLOC);
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), NULL, P2M_ALLOC);
     mfn = page ? page_to_mfn(page) : INVALID_MFN;
-
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+#endif
     ad.sdom = d;
     ad.tdom = f;
     ad.memory.pte = fpte;
@@ -1373,6 +1376,7 @@ static int flask_update_va_mapping(struc
     int rc = 0;
     u32 psid;
     u32 map_perms = MMU__MAP_READ;
+    struct page_info *page = NULL;
     unsigned long mfn;
     struct domain_security_struct *dsec;
 
@@ -1384,8 +1388,15 @@ static int flask_update_va_mapping(struc
 
     dsec = d->ssid;
 
-    mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
+#if CONFIG_X86
+    page = get_page_from_gfn(f, l1e_get_pfn(pte), NULL, P2M_ALLOC);
+    mfn = (page) ? page_to_mfn(page) : INVALID_MFN;
+#else
+    mfn = gmfn_to_mfn(f, l1e_get_pfn(pte));
+#endif
     rc = get_mfn_sid(mfn, &psid);
+    if ( page )
+        put_page(page);
     if ( rc )
         return rc;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRN-0007xD-P5; Fri, 27 Apr 2012 21:10:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRM-0007x0-9k
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:56 +0000
Received: from [85.158.143.99:49285] by server-3.bemta-4.messagelabs.com id
	06/9D-05853-F5B0B9F4; Fri, 27 Apr 2012 21:10:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335561054!25284671!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMTU5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26539 invoked from network); 27 Apr 2012 21:10:54 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 21:10:54 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 8871171406F;
	Fri, 27 Apr 2012 14:10:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=mZYrJUbQ5PjDNSEQ/0Oij5
	B7l4nmMe0TbGNeTgA+t3rL3yfB7LxW2JM/NAOUQamJBkdCk7g2E5amrff40sLhII
	XbM0QdILgc7mvWe4+v/UOO5VDK+wMyKBG4VtKJSoqm7zgfPbfOPyV+ViTOrJ41mc
	pFCvf8o0aaam1lSalac5k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=2beaQHUr8w8w
	TZ/TI/u8GS8NYDA=; b=Py401O+Lullh/Fkm2SKzeqxgD+Nl9X3zQ56PxEow1fFJ
	qqeitSywLILapLGJB4vkv0KOHNmlZGb+iYpMDUGpOZE8gMj0chRPJVwRRVg+a+sU
	4jVN3vXHOtU4WXyP744jMvDAH6UVxUgDgQobzQ2F3O48vhrknf8NFNTtP9uPSJQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 09FE771406B; 
	Fri, 27 Apr 2012 14:10:52 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:17 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 4] RFC top up to experimental p2m rwlock
	patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Extending the core idea form Tim's patch, and bug fixing galore.

Our testing works quite smoothly with this in place.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

 xen/arch/x86/mm.c               |    2 +-
 xen/arch/x86/mm/shadow/common.c |    5 -
 xen/include/asm-x86/mm.h        |    1 -
 xen/common/grant_table.c        |  231 ++++++++++++++++-----------------------
 xen/arch/x86/hvm/svm/svm.c      |   20 +--
 xen/arch/x86/mm.c               |   48 +++-----
 xen/common/memory.c             |    9 +-
 xen/common/tmem_xen.c           |   26 +--
 xen/include/asm-x86/p2m.h       |   11 -
 xen/xsm/flask/hooks.c           |   19 ++-
 10 files changed, 155 insertions(+), 217 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRN-0007xD-P5; Fri, 27 Apr 2012 21:10:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRM-0007x0-9k
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:56 +0000
Received: from [85.158.143.99:49285] by server-3.bemta-4.messagelabs.com id
	06/9D-05853-F5B0B9F4; Fri, 27 Apr 2012 21:10:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335561054!25284671!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAyMTU5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26539 invoked from network); 27 Apr 2012 21:10:54 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 21:10:54 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 8871171406F;
	Fri, 27 Apr 2012 14:10:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=mZYrJUbQ5PjDNSEQ/0Oij5
	B7l4nmMe0TbGNeTgA+t3rL3yfB7LxW2JM/NAOUQamJBkdCk7g2E5amrff40sLhII
	XbM0QdILgc7mvWe4+v/UOO5VDK+wMyKBG4VtKJSoqm7zgfPbfOPyV+ViTOrJ41mc
	pFCvf8o0aaam1lSalac5k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=2beaQHUr8w8w
	TZ/TI/u8GS8NYDA=; b=Py401O+Lullh/Fkm2SKzeqxgD+Nl9X3zQ56PxEow1fFJ
	qqeitSywLILapLGJB4vkv0KOHNmlZGb+iYpMDUGpOZE8gMj0chRPJVwRRVg+a+sU
	4jVN3vXHOtU4WXyP744jMvDAH6UVxUgDgQobzQ2F3O48vhrknf8NFNTtP9uPSJQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 09FE771406B; 
	Fri, 27 Apr 2012 14:10:52 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:17 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 0 of 4] RFC top up to experimental p2m rwlock
	patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Extending the core idea form Tim's patch, and bug fixing galore.

Our testing works quite smoothly with this in place.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

 xen/arch/x86/mm.c               |    2 +-
 xen/arch/x86/mm/shadow/common.c |    5 -
 xen/include/asm-x86/mm.h        |    1 -
 xen/common/grant_table.c        |  231 ++++++++++++++++-----------------------
 xen/arch/x86/hvm/svm/svm.c      |   20 +--
 xen/arch/x86/mm.c               |   48 +++-----
 xen/common/memory.c             |    9 +-
 xen/common/tmem_xen.c           |   26 +--
 xen/include/asm-x86/p2m.h       |   11 -
 xen/xsm/flask/hooks.c           |   19 ++-
 10 files changed, 155 insertions(+), 217 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRQ-0007y5-32; Fri, 27 Apr 2012 21:11:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRN-0007xC-Tp
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:59 +0000
Received: from [193.109.254.147:6707] by server-2.bemta-14.messagelabs.com id
	2E/54-19409-16B0B9F4; Fri, 27 Apr 2012 21:10:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335561055!6694123!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjE4MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2742 invoked from network); 27 Apr 2012 21:10:56 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 21:10:56 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 2CCA571406F;
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mUBiTTqTETE8XpFOfDm1941NK0qCHihgBvvK3GHTYTpt
	T44S+CaTYab+TtlFu/kHktAcok9WX7WnCm3UpSHMCJh34UHQi26y5gQicRl7A4Bx
	KD9i0hV4SRUQcTesYP7Coqq1+HMDZDHqly0eHXh2jabCDRnayjSGXDw+OTaAxyg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=rP16ZsX//FjSU8cRFSonaqIAM6U=; b=rTa7uzxaTVU
	TZm3FN4dhIHcnQMLHXl1rOEG+Qf3ic0pjbsfXU/N9bhPyz35G64M2y7bcc+rcfl0
	8ZrvSxIhmjnroWZ+TZtX3r2qPqoDWBmmJomidYqpYzdax3hCCr8BqquCns5nWCNJ
	zpH1IQ/LUR3uzD9kwus8A79hnWB8Iy+M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 7EEC771406B; 
	Fri, 27 Apr 2012 14:10:54 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: ea86428536014294400013285ed35b2a0a18b52a
Message-Id: <ea864285360142944000.1335561379@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:19 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 4] Grant table: Adopt get_page_from_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/common/grant_table.c |  231 +++++++++++++++++++---------------------------
 1 files changed, 94 insertions(+), 137 deletions(-)


This requires some careful re-engineering of __get_paged_frame and its callers.
Functions that previously returned gfn's to be put now return pages to be put.

Tested with Win7 + Citrix PV drivers guest, using speedtest for networking
(yes!) plus the loginVSI framework to constantly hit disk.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 00034349414e -r ea8642853601 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -107,18 +107,6 @@ static unsigned inline int max_nr_maptra
     return (max_nr_grant_frames * MAX_MAPTRACK_TO_GRANTS_RATIO);
 }
 
-#ifdef CONFIG_X86
-#define gfn_to_mfn_private(_d, _gfn) ({                     \
-    p2m_type_t __p2mt;                                      \
-    unsigned long __x;                                      \
-    __x = mfn_x(get_gfn_unshare((_d), (_gfn), &__p2mt));    \
-    if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) )   \
-        __x = INVALID_MFN;                                  \
-    __x; })
-#else
-#define gfn_to_mfn_private(_d, _gfn) gmfn_to_mfn(_d, _gfn)
-#endif
-
 #define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
 #define shared_entry_v1(t, e) \
     ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
@@ -141,41 +129,41 @@ shared_entry_header(struct grant_table *
 #define active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
-/* Check if the page has been paged out. If rc == GNTST_okay, caller must do put_gfn(rd, gfn) */
-static int __get_paged_frame(unsigned long gfn, unsigned long *frame, int readonly, struct domain *rd)
+/* Check if the page has been paged out, or needs unsharing. 
+   If rc == GNTST_okay, *page contains the page struct with a ref taken.
+   Caller must do put_page(*page).
+   If any error, *page = NULL, *frame = INVALID_MFN, no ref taken. */
+static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct page_info **page,
+                                int readonly, struct domain *rd)
 {
     int rc = GNTST_okay;
 #if defined(P2M_PAGED_TYPES) || defined(P2M_SHARED_TYPES)
     p2m_type_t p2mt;
-    mfn_t mfn;
-
-    if ( readonly )
-        mfn = get_gfn(rd, gfn, &p2mt);
-    else
+
+    *page = get_page_from_gfn(rd, gfn, &p2mt, 
+                              (readonly) ? P2M_ALLOC : P2M_UNSHARE);
+    if ( !(*page) )
     {
-        mfn = get_gfn_unshare(rd, gfn, &p2mt);
+        *frame = INVALID_MFN;
         if ( p2m_is_shared(p2mt) )
+            return GNTST_eagain;
+        if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(rd, gfn);
+            p2m_mem_paging_populate(rd, gfn);
             return GNTST_eagain;
         }
+        return GNTST_bad_page;
     }
-
-    if ( p2m_is_valid(p2mt) ) {
-        *frame = mfn_x(mfn);
-        if ( p2m_is_paging(p2mt) )
-        {
-            put_gfn(rd, gfn);
-            p2m_mem_paging_populate(rd, gfn);
-            rc = GNTST_eagain;
-        }
-    } else {
-       put_gfn(rd, gfn);
-       *frame = INVALID_MFN;
-       rc = GNTST_bad_page;
+    *frame = page_to_mfn(*page);
+#else
+    *frame = gmfn_to_mfn(rd, gfn);
+    *page = mfn_valid(*frame) ? mfn_to_page(*frame) : NULL;
+    if ( (!(*page)) || (!get_page(*page, rd)) )
+    {
+        *frame = INVALID_MFN;
+        *page = NULL;
+        rc = GNTST_bad_page;
     }
-#else
-    *frame = readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, gfn);
 #endif
 
     return rc;
@@ -470,12 +458,11 @@ static void
 __gnttab_map_grant_ref(
     struct gnttab_map_grant_ref *op)
 {
-    struct domain *ld, *rd, *owner;
+    struct domain *ld, *rd, *owner = NULL;
     struct vcpu   *led;
     int            handle;
-    unsigned long  gfn = INVALID_GFN;
     unsigned long  frame = 0, nr_gets = 0;
-    struct page_info *pg;
+    struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
     u32            act_pin;
@@ -573,13 +560,11 @@ __gnttab_map_grant_ref(
         {
             unsigned long frame;
 
-            gfn = sha1 ? sha1->frame : sha2->full_page.frame;
-            rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd);
+            unsigned long gfn = sha1 ? sha1->frame : sha2->full_page.frame;
+            rc = __get_paged_frame(gfn, &frame, &pg, 
+                                    !!(op->flags & GNTMAP_readonly), rd);
             if ( rc != GNTST_okay )
-            {
-                gfn = INVALID_GFN;
                 goto unlock_out_clear;
-            }
             act->gfn = gfn;
             act->domid = ld->domain_id;
             act->frame = frame;
@@ -606,9 +591,17 @@ __gnttab_map_grant_ref(
 
     spin_unlock(&rd->grant_table->lock);
 
-    pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL;
-
-    if ( !pg || (owner = page_get_owner_and_reference(pg)) == dom_io )
+    /* pg may be set, with a refcount included, from __get_paged_frame */
+    if ( !pg )
+    {
+        pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL;
+        if ( pg )
+            owner = page_get_owner_and_reference(pg);
+    }
+    else
+        owner = page_get_owner(pg);
+
+    if ( !pg || (owner == dom_io) )
     {
         /* Only needed the reference to confirm dom_io ownership. */
         if ( pg )
@@ -708,8 +701,6 @@ __gnttab_map_grant_ref(
     op->handle       = handle;
     op->status       = GNTST_okay;
 
-    if ( gfn != INVALID_GFN )
-        put_gfn(rd, gfn);
     rcu_unlock_domain(rd);
     return;
 
@@ -748,8 +739,6 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    if ( gfn != INVALID_GFN )
-        put_gfn(rd, gfn);
     spin_unlock(&rd->grant_table->lock);
     op->status = rc;
     put_maptrack_handle(ld->grant_table, handle);
@@ -1479,7 +1468,16 @@ gnttab_transfer(
             return -EFAULT;
         }
 
-        mfn = gfn_to_mfn_private(d, gop.mfn);
+#ifdef CONFIG_X86
+        {
+            p2m_type_t __p2mt;
+            mfn = mfn_x(get_gfn_unshare(d, gop.mfn, &__p2mt));
+            if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) )
+                mfn = INVALID_MFN;
+        }
+#else
+        mfn = gmfn_to_mfn(d, gop.mfn)
+#endif
 
         /* Check the passed page frame for basic validity. */
         if ( unlikely(!mfn_valid(mfn)) )
@@ -1723,15 +1721,14 @@ static void __fixup_status_for_pin(const
 }
 
 /* Grab a frame number from a grant entry and update the flags and pin
-   count as appropriate.  Note that this does *not* update the page
-   type or reference counts, and does not check that the mfn is
-   actually valid. If *gfn != INVALID_GFN, and rc == GNTST_okay, then
-   we leave this function holding the p2m entry for *gfn in *owning_domain */
+   count as appropriate. If rc == GNTST_okay, note that this *does* 
+   take one ref count on the target page, stored in *page.
+   If there is any error, *page = NULL, no ref taken. */
 static int
 __acquire_grant_for_copy(
     struct domain *rd, unsigned long gref, struct domain *ld, int readonly,
-    unsigned long *frame, unsigned long *gfn, unsigned *page_off, unsigned *length,
-    unsigned allow_transitive, struct domain **owning_domain)
+    unsigned long *frame, struct page_info **page, 
+    unsigned *page_off, unsigned *length, unsigned allow_transitive)
 {
     grant_entry_v1_t *sha1;
     grant_entry_v2_t *sha2;
@@ -1746,11 +1743,9 @@ __acquire_grant_for_copy(
     unsigned trans_page_off;
     unsigned trans_length;
     int is_sub_page;
-    struct domain *ignore;
     s16 rc = GNTST_okay;
 
-    *owning_domain = NULL;
-    *gfn = INVALID_GFN;
+    *page = NULL;
 
     spin_lock(&rd->grant_table->lock);
 
@@ -1827,14 +1822,13 @@ __acquire_grant_for_copy(
             spin_unlock(&rd->grant_table->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd,
-                                          readonly, &grant_frame, gfn,
-                                          &trans_page_off, &trans_length,
-                                          0, &ignore);
+                                          readonly, &grant_frame, page,
+                                          &trans_page_off, &trans_length, 0);
 
             spin_lock(&rd->grant_table->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_pin(act, status);
-	        rcu_unlock_domain(td);
+                rcu_unlock_domain(td);
                 spin_unlock(&rd->grant_table->lock);
                 return rc;
             }
@@ -1846,56 +1840,49 @@ __acquire_grant_for_copy(
             if ( act->pin != old_pin )
             {
                 __fixup_status_for_pin(act, status);
-	        rcu_unlock_domain(td);
+                rcu_unlock_domain(td);
                 spin_unlock(&rd->grant_table->lock);
+                put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ld, readonly,
-                                                frame, gfn, page_off, length,
-                                                allow_transitive,
-                                                owning_domain);
+                                                frame, page, page_off, length,
+                                                allow_transitive);
             }
 
             /* The actual remote remote grant may or may not be a
                sub-page, but we always treat it as one because that
                blocks mappings of transitive grants. */
             is_sub_page = 1;
-            *owning_domain = td;
             act->gfn = -1ul;
         }
         else if ( sha1 )
         {
-            *gfn = sha1->frame;
-            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
+            rc = __get_paged_frame(sha1->frame, &grant_frame, page, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = *gfn;
+            act->gfn = sha1->frame;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
-            *owning_domain = rd;
         }
         else if ( !(sha2->hdr.flags & GTF_sub_page) )
         {
-            *gfn = sha2->full_page.frame;
-            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
+            rc = __get_paged_frame(sha2->full_page.frame, &grant_frame, page, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = *gfn;
+            act->gfn = sha2->full_page.frame;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
-            *owning_domain = rd;
         }
         else
         {
-            *gfn = sha2->sub_page.frame;
-            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
+            rc = __get_paged_frame(sha2->sub_page.frame, &grant_frame, page, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = *gfn;
+            act->gfn = sha2->sub_page.frame;
             is_sub_page = 1;
             trans_page_off = sha2->sub_page.page_off;
             trans_length = sha2->sub_page.length;
-            *owning_domain = rd;
         }
 
         if ( !act->pin )
@@ -1911,7 +1898,9 @@ __acquire_grant_for_copy(
     }
     else
     {
-        *owning_domain = rd;
+        ASSERT(mfn_valid(act->frame));
+        *page = mfn_to_page(act->frame);
+        (void)page_get_owner_and_reference(*page);
     }
 
     act->pin += readonly ? GNTPIN_hstr_inc : GNTPIN_hstw_inc;
@@ -1930,11 +1919,11 @@ __gnttab_copy(
     struct gnttab_copy *op)
 {
     struct domain *sd = NULL, *dd = NULL;
-    struct domain *source_domain = NULL, *dest_domain = NULL;
-    unsigned long s_frame, d_frame, s_gfn = INVALID_GFN, d_gfn = INVALID_GFN;
+    unsigned long s_frame, d_frame;
+    struct page_info *s_pg = NULL, *d_pg = NULL;
     char *sp, *dp;
     s16 rc = GNTST_okay;
-    int have_d_grant = 0, have_s_grant = 0, have_s_ref = 0;
+    int have_d_grant = 0, have_s_grant = 0;
     int src_is_gref, dest_is_gref;
 
     if ( ((op->source.offset + op->len) > PAGE_SIZE) ||
@@ -1972,82 +1961,54 @@ __gnttab_copy(
     {
         unsigned source_off, source_len;
         rc = __acquire_grant_for_copy(sd, op->source.u.ref, current->domain, 1,
-                                      &s_frame, &s_gfn, &source_off, &source_len, 1,
-                                      &source_domain);
+                                      &s_frame, &s_pg, &source_off, &source_len, 1);
         if ( rc != GNTST_okay )
             goto error_out;
         have_s_grant = 1;
         if ( op->source.offset < source_off ||
              op->len > source_len )
-            PIN_FAIL(error_put_s_gfn, GNTST_general_error,
+            PIN_FAIL(error_out, GNTST_general_error,
                      "copy source out of bounds: %d < %d || %d > %d\n",
                      op->source.offset, source_off,
                      op->len, source_len);
     }
     else
     {
-#ifdef CONFIG_X86
-        s_gfn = op->source.u.gmfn;
-        rc = __get_paged_frame(op->source.u.gmfn, &s_frame, 1, sd);
+        rc = __get_paged_frame(op->source.u.gmfn, &s_frame, &s_pg, 1, sd);
         if ( rc != GNTST_okay )
-            goto error_out;
-#else
-        s_frame = gmfn_to_mfn(sd, op->source.u.gmfn);        
-#endif
-        source_domain = sd;
+            PIN_FAIL(error_out, rc,
+                     "source frame %lx invalid.\n", s_frame);
     }
-    if ( unlikely(!mfn_valid(s_frame)) )
-        PIN_FAIL(error_put_s_gfn, GNTST_general_error,
-                 "source frame %lx invalid.\n", s_frame);
-    /* For the source frame, the page could still be shared, so
-     * don't assume ownership by source_domain */
-    if ( !page_get_owner_and_reference(mfn_to_page(s_frame)) )
-    {
-        if ( !sd->is_dying )
-            gdprintk(XENLOG_WARNING, "Could not get src frame %lx\n", s_frame);
-        rc = GNTST_general_error;
-        goto error_put_s_gfn;
-    }
-    have_s_ref = 1;
 
     if ( dest_is_gref )
     {
         unsigned dest_off, dest_len;
         rc = __acquire_grant_for_copy(dd, op->dest.u.ref, current->domain, 0,
-                                      &d_frame, &d_gfn, &dest_off, &dest_len, 1,
-                                      &dest_domain);
+                                      &d_frame, &d_pg, &dest_off, &dest_len, 1);
         if ( rc != GNTST_okay )
-            goto error_put_s_gfn;
+            goto error_out;
         have_d_grant = 1;
         if ( op->dest.offset < dest_off ||
              op->len > dest_len )
-            PIN_FAIL(error_put_d_gfn, GNTST_general_error,
+            PIN_FAIL(error_out, GNTST_general_error,
                      "copy dest out of bounds: %d < %d || %d > %d\n",
                      op->dest.offset, dest_off,
                      op->len, dest_len);
     }
     else
     {
-#ifdef CONFIG_X86
-        d_gfn = op->dest.u.gmfn;
-        rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, 0, dd);
+        rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, &d_pg, 0, dd);
         if ( rc != GNTST_okay )
-            goto error_put_s_gfn;
-#else
-        d_frame = gmfn_to_mfn(dd, op->dest.u.gmfn);
-#endif
-        dest_domain = dd;
+            PIN_FAIL(error_out, rc,
+                     "destination frame %lx invalid.\n", d_frame);
     }
-    if ( unlikely(!mfn_valid(d_frame)) )
-        PIN_FAIL(error_put_d_gfn, GNTST_general_error,
-                 "destination frame %lx invalid.\n", d_frame);
-    if ( !get_page_and_type(mfn_to_page(d_frame), dest_domain,
-                            PGT_writable_page) )
+
+    if ( !get_page_type(d_pg, PGT_writable_page) )
     {
         if ( !dd->is_dying )
             gdprintk(XENLOG_WARNING, "Could not get dst frame %lx\n", d_frame);
         rc = GNTST_general_error;
-        goto error_put_d_gfn;
+        goto error_out;
     }
 
     sp = map_domain_page(s_frame);
@@ -2060,16 +2021,12 @@ __gnttab_copy(
 
     gnttab_mark_dirty(dd, d_frame);
 
-    put_page_and_type(mfn_to_page(d_frame));
- error_put_d_gfn:
-    if ( (d_gfn != INVALID_GFN) && (dest_domain) )
-        put_gfn(dest_domain, d_gfn);
- error_put_s_gfn:
-    if ( (s_gfn != INVALID_GFN) && (source_domain) )
-        put_gfn(source_domain, s_gfn);
+    put_page_type(d_pg);
  error_out:
-    if ( have_s_ref )
-        put_page(mfn_to_page(s_frame));
+    if ( d_pg )
+        put_page(d_pg);
+    if ( s_pg )
+        put_page(s_pg);
     if ( have_s_grant )
         __release_grant_for_copy(sd, op->source.u.ref, 1);
     if ( have_d_grant )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRQ-0007y5-32; Fri, 27 Apr 2012 21:11:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRN-0007xC-Tp
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:59 +0000
Received: from [193.109.254.147:6707] by server-2.bemta-14.messagelabs.com id
	2E/54-19409-16B0B9F4; Fri, 27 Apr 2012 21:10:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1335561055!6694123!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMjE4MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2742 invoked from network); 27 Apr 2012 21:10:56 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	27 Apr 2012 21:10:56 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 2CCA571406F;
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mUBiTTqTETE8XpFOfDm1941NK0qCHihgBvvK3GHTYTpt
	T44S+CaTYab+TtlFu/kHktAcok9WX7WnCm3UpSHMCJh34UHQi26y5gQicRl7A4Bx
	KD9i0hV4SRUQcTesYP7Coqq1+HMDZDHqly0eHXh2jabCDRnayjSGXDw+OTaAxyg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=rP16ZsX//FjSU8cRFSonaqIAM6U=; b=rTa7uzxaTVU
	TZm3FN4dhIHcnQMLHXl1rOEG+Qf3ic0pjbsfXU/N9bhPyz35G64M2y7bcc+rcfl0
	8ZrvSxIhmjnroWZ+TZtX3r2qPqoDWBmmJomidYqpYzdax3hCCr8BqquCns5nWCNJ
	zpH1IQ/LUR3uzD9kwus8A79hnWB8Iy+M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 7EEC771406B; 
	Fri, 27 Apr 2012 14:10:54 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: ea86428536014294400013285ed35b2a0a18b52a
Message-Id: <ea864285360142944000.1335561379@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:19 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 2 of 4] Grant table: Adopt get_page_from_gfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/common/grant_table.c |  231 +++++++++++++++++++---------------------------
 1 files changed, 94 insertions(+), 137 deletions(-)


This requires some careful re-engineering of __get_paged_frame and its callers.
Functions that previously returned gfn's to be put now return pages to be put.

Tested with Win7 + Citrix PV drivers guest, using speedtest for networking
(yes!) plus the loginVSI framework to constantly hit disk.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 00034349414e -r ea8642853601 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -107,18 +107,6 @@ static unsigned inline int max_nr_maptra
     return (max_nr_grant_frames * MAX_MAPTRACK_TO_GRANTS_RATIO);
 }
 
-#ifdef CONFIG_X86
-#define gfn_to_mfn_private(_d, _gfn) ({                     \
-    p2m_type_t __p2mt;                                      \
-    unsigned long __x;                                      \
-    __x = mfn_x(get_gfn_unshare((_d), (_gfn), &__p2mt));    \
-    if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) )   \
-        __x = INVALID_MFN;                                  \
-    __x; })
-#else
-#define gfn_to_mfn_private(_d, _gfn) gmfn_to_mfn(_d, _gfn)
-#endif
-
 #define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
 #define shared_entry_v1(t, e) \
     ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
@@ -141,41 +129,41 @@ shared_entry_header(struct grant_table *
 #define active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
-/* Check if the page has been paged out. If rc == GNTST_okay, caller must do put_gfn(rd, gfn) */
-static int __get_paged_frame(unsigned long gfn, unsigned long *frame, int readonly, struct domain *rd)
+/* Check if the page has been paged out, or needs unsharing. 
+   If rc == GNTST_okay, *page contains the page struct with a ref taken.
+   Caller must do put_page(*page).
+   If any error, *page = NULL, *frame = INVALID_MFN, no ref taken. */
+static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct page_info **page,
+                                int readonly, struct domain *rd)
 {
     int rc = GNTST_okay;
 #if defined(P2M_PAGED_TYPES) || defined(P2M_SHARED_TYPES)
     p2m_type_t p2mt;
-    mfn_t mfn;
-
-    if ( readonly )
-        mfn = get_gfn(rd, gfn, &p2mt);
-    else
+
+    *page = get_page_from_gfn(rd, gfn, &p2mt, 
+                              (readonly) ? P2M_ALLOC : P2M_UNSHARE);
+    if ( !(*page) )
     {
-        mfn = get_gfn_unshare(rd, gfn, &p2mt);
+        *frame = INVALID_MFN;
         if ( p2m_is_shared(p2mt) )
+            return GNTST_eagain;
+        if ( p2m_is_paging(p2mt) )
         {
-            put_gfn(rd, gfn);
+            p2m_mem_paging_populate(rd, gfn);
             return GNTST_eagain;
         }
+        return GNTST_bad_page;
     }
-
-    if ( p2m_is_valid(p2mt) ) {
-        *frame = mfn_x(mfn);
-        if ( p2m_is_paging(p2mt) )
-        {
-            put_gfn(rd, gfn);
-            p2m_mem_paging_populate(rd, gfn);
-            rc = GNTST_eagain;
-        }
-    } else {
-       put_gfn(rd, gfn);
-       *frame = INVALID_MFN;
-       rc = GNTST_bad_page;
+    *frame = page_to_mfn(*page);
+#else
+    *frame = gmfn_to_mfn(rd, gfn);
+    *page = mfn_valid(*frame) ? mfn_to_page(*frame) : NULL;
+    if ( (!(*page)) || (!get_page(*page, rd)) )
+    {
+        *frame = INVALID_MFN;
+        *page = NULL;
+        rc = GNTST_bad_page;
     }
-#else
-    *frame = readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, gfn);
 #endif
 
     return rc;
@@ -470,12 +458,11 @@ static void
 __gnttab_map_grant_ref(
     struct gnttab_map_grant_ref *op)
 {
-    struct domain *ld, *rd, *owner;
+    struct domain *ld, *rd, *owner = NULL;
     struct vcpu   *led;
     int            handle;
-    unsigned long  gfn = INVALID_GFN;
     unsigned long  frame = 0, nr_gets = 0;
-    struct page_info *pg;
+    struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
     u32            act_pin;
@@ -573,13 +560,11 @@ __gnttab_map_grant_ref(
         {
             unsigned long frame;
 
-            gfn = sha1 ? sha1->frame : sha2->full_page.frame;
-            rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd);
+            unsigned long gfn = sha1 ? sha1->frame : sha2->full_page.frame;
+            rc = __get_paged_frame(gfn, &frame, &pg, 
+                                    !!(op->flags & GNTMAP_readonly), rd);
             if ( rc != GNTST_okay )
-            {
-                gfn = INVALID_GFN;
                 goto unlock_out_clear;
-            }
             act->gfn = gfn;
             act->domid = ld->domain_id;
             act->frame = frame;
@@ -606,9 +591,17 @@ __gnttab_map_grant_ref(
 
     spin_unlock(&rd->grant_table->lock);
 
-    pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL;
-
-    if ( !pg || (owner = page_get_owner_and_reference(pg)) == dom_io )
+    /* pg may be set, with a refcount included, from __get_paged_frame */
+    if ( !pg )
+    {
+        pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL;
+        if ( pg )
+            owner = page_get_owner_and_reference(pg);
+    }
+    else
+        owner = page_get_owner(pg);
+
+    if ( !pg || (owner == dom_io) )
     {
         /* Only needed the reference to confirm dom_io ownership. */
         if ( pg )
@@ -708,8 +701,6 @@ __gnttab_map_grant_ref(
     op->handle       = handle;
     op->status       = GNTST_okay;
 
-    if ( gfn != INVALID_GFN )
-        put_gfn(rd, gfn);
     rcu_unlock_domain(rd);
     return;
 
@@ -748,8 +739,6 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    if ( gfn != INVALID_GFN )
-        put_gfn(rd, gfn);
     spin_unlock(&rd->grant_table->lock);
     op->status = rc;
     put_maptrack_handle(ld->grant_table, handle);
@@ -1479,7 +1468,16 @@ gnttab_transfer(
             return -EFAULT;
         }
 
-        mfn = gfn_to_mfn_private(d, gop.mfn);
+#ifdef CONFIG_X86
+        {
+            p2m_type_t __p2mt;
+            mfn = mfn_x(get_gfn_unshare(d, gop.mfn, &__p2mt));
+            if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) )
+                mfn = INVALID_MFN;
+        }
+#else
+        mfn = gmfn_to_mfn(d, gop.mfn)
+#endif
 
         /* Check the passed page frame for basic validity. */
         if ( unlikely(!mfn_valid(mfn)) )
@@ -1723,15 +1721,14 @@ static void __fixup_status_for_pin(const
 }
 
 /* Grab a frame number from a grant entry and update the flags and pin
-   count as appropriate.  Note that this does *not* update the page
-   type or reference counts, and does not check that the mfn is
-   actually valid. If *gfn != INVALID_GFN, and rc == GNTST_okay, then
-   we leave this function holding the p2m entry for *gfn in *owning_domain */
+   count as appropriate. If rc == GNTST_okay, note that this *does* 
+   take one ref count on the target page, stored in *page.
+   If there is any error, *page = NULL, no ref taken. */
 static int
 __acquire_grant_for_copy(
     struct domain *rd, unsigned long gref, struct domain *ld, int readonly,
-    unsigned long *frame, unsigned long *gfn, unsigned *page_off, unsigned *length,
-    unsigned allow_transitive, struct domain **owning_domain)
+    unsigned long *frame, struct page_info **page, 
+    unsigned *page_off, unsigned *length, unsigned allow_transitive)
 {
     grant_entry_v1_t *sha1;
     grant_entry_v2_t *sha2;
@@ -1746,11 +1743,9 @@ __acquire_grant_for_copy(
     unsigned trans_page_off;
     unsigned trans_length;
     int is_sub_page;
-    struct domain *ignore;
     s16 rc = GNTST_okay;
 
-    *owning_domain = NULL;
-    *gfn = INVALID_GFN;
+    *page = NULL;
 
     spin_lock(&rd->grant_table->lock);
 
@@ -1827,14 +1822,13 @@ __acquire_grant_for_copy(
             spin_unlock(&rd->grant_table->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd,
-                                          readonly, &grant_frame, gfn,
-                                          &trans_page_off, &trans_length,
-                                          0, &ignore);
+                                          readonly, &grant_frame, page,
+                                          &trans_page_off, &trans_length, 0);
 
             spin_lock(&rd->grant_table->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_pin(act, status);
-	        rcu_unlock_domain(td);
+                rcu_unlock_domain(td);
                 spin_unlock(&rd->grant_table->lock);
                 return rc;
             }
@@ -1846,56 +1840,49 @@ __acquire_grant_for_copy(
             if ( act->pin != old_pin )
             {
                 __fixup_status_for_pin(act, status);
-	        rcu_unlock_domain(td);
+                rcu_unlock_domain(td);
                 spin_unlock(&rd->grant_table->lock);
+                put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ld, readonly,
-                                                frame, gfn, page_off, length,
-                                                allow_transitive,
-                                                owning_domain);
+                                                frame, page, page_off, length,
+                                                allow_transitive);
             }
 
             /* The actual remote remote grant may or may not be a
                sub-page, but we always treat it as one because that
                blocks mappings of transitive grants. */
             is_sub_page = 1;
-            *owning_domain = td;
             act->gfn = -1ul;
         }
         else if ( sha1 )
         {
-            *gfn = sha1->frame;
-            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
+            rc = __get_paged_frame(sha1->frame, &grant_frame, page, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = *gfn;
+            act->gfn = sha1->frame;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
-            *owning_domain = rd;
         }
         else if ( !(sha2->hdr.flags & GTF_sub_page) )
         {
-            *gfn = sha2->full_page.frame;
-            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
+            rc = __get_paged_frame(sha2->full_page.frame, &grant_frame, page, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = *gfn;
+            act->gfn = sha2->full_page.frame;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
-            *owning_domain = rd;
         }
         else
         {
-            *gfn = sha2->sub_page.frame;
-            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
+            rc = __get_paged_frame(sha2->sub_page.frame, &grant_frame, page, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = *gfn;
+            act->gfn = sha2->sub_page.frame;
             is_sub_page = 1;
             trans_page_off = sha2->sub_page.page_off;
             trans_length = sha2->sub_page.length;
-            *owning_domain = rd;
         }
 
         if ( !act->pin )
@@ -1911,7 +1898,9 @@ __acquire_grant_for_copy(
     }
     else
     {
-        *owning_domain = rd;
+        ASSERT(mfn_valid(act->frame));
+        *page = mfn_to_page(act->frame);
+        (void)page_get_owner_and_reference(*page);
     }
 
     act->pin += readonly ? GNTPIN_hstr_inc : GNTPIN_hstw_inc;
@@ -1930,11 +1919,11 @@ __gnttab_copy(
     struct gnttab_copy *op)
 {
     struct domain *sd = NULL, *dd = NULL;
-    struct domain *source_domain = NULL, *dest_domain = NULL;
-    unsigned long s_frame, d_frame, s_gfn = INVALID_GFN, d_gfn = INVALID_GFN;
+    unsigned long s_frame, d_frame;
+    struct page_info *s_pg = NULL, *d_pg = NULL;
     char *sp, *dp;
     s16 rc = GNTST_okay;
-    int have_d_grant = 0, have_s_grant = 0, have_s_ref = 0;
+    int have_d_grant = 0, have_s_grant = 0;
     int src_is_gref, dest_is_gref;
 
     if ( ((op->source.offset + op->len) > PAGE_SIZE) ||
@@ -1972,82 +1961,54 @@ __gnttab_copy(
     {
         unsigned source_off, source_len;
         rc = __acquire_grant_for_copy(sd, op->source.u.ref, current->domain, 1,
-                                      &s_frame, &s_gfn, &source_off, &source_len, 1,
-                                      &source_domain);
+                                      &s_frame, &s_pg, &source_off, &source_len, 1);
         if ( rc != GNTST_okay )
             goto error_out;
         have_s_grant = 1;
         if ( op->source.offset < source_off ||
              op->len > source_len )
-            PIN_FAIL(error_put_s_gfn, GNTST_general_error,
+            PIN_FAIL(error_out, GNTST_general_error,
                      "copy source out of bounds: %d < %d || %d > %d\n",
                      op->source.offset, source_off,
                      op->len, source_len);
     }
     else
     {
-#ifdef CONFIG_X86
-        s_gfn = op->source.u.gmfn;
-        rc = __get_paged_frame(op->source.u.gmfn, &s_frame, 1, sd);
+        rc = __get_paged_frame(op->source.u.gmfn, &s_frame, &s_pg, 1, sd);
         if ( rc != GNTST_okay )
-            goto error_out;
-#else
-        s_frame = gmfn_to_mfn(sd, op->source.u.gmfn);        
-#endif
-        source_domain = sd;
+            PIN_FAIL(error_out, rc,
+                     "source frame %lx invalid.\n", s_frame);
     }
-    if ( unlikely(!mfn_valid(s_frame)) )
-        PIN_FAIL(error_put_s_gfn, GNTST_general_error,
-                 "source frame %lx invalid.\n", s_frame);
-    /* For the source frame, the page could still be shared, so
-     * don't assume ownership by source_domain */
-    if ( !page_get_owner_and_reference(mfn_to_page(s_frame)) )
-    {
-        if ( !sd->is_dying )
-            gdprintk(XENLOG_WARNING, "Could not get src frame %lx\n", s_frame);
-        rc = GNTST_general_error;
-        goto error_put_s_gfn;
-    }
-    have_s_ref = 1;
 
     if ( dest_is_gref )
     {
         unsigned dest_off, dest_len;
         rc = __acquire_grant_for_copy(dd, op->dest.u.ref, current->domain, 0,
-                                      &d_frame, &d_gfn, &dest_off, &dest_len, 1,
-                                      &dest_domain);
+                                      &d_frame, &d_pg, &dest_off, &dest_len, 1);
         if ( rc != GNTST_okay )
-            goto error_put_s_gfn;
+            goto error_out;
         have_d_grant = 1;
         if ( op->dest.offset < dest_off ||
              op->len > dest_len )
-            PIN_FAIL(error_put_d_gfn, GNTST_general_error,
+            PIN_FAIL(error_out, GNTST_general_error,
                      "copy dest out of bounds: %d < %d || %d > %d\n",
                      op->dest.offset, dest_off,
                      op->len, dest_len);
     }
     else
     {
-#ifdef CONFIG_X86
-        d_gfn = op->dest.u.gmfn;
-        rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, 0, dd);
+        rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, &d_pg, 0, dd);
         if ( rc != GNTST_okay )
-            goto error_put_s_gfn;
-#else
-        d_frame = gmfn_to_mfn(dd, op->dest.u.gmfn);
-#endif
-        dest_domain = dd;
+            PIN_FAIL(error_out, rc,
+                     "destination frame %lx invalid.\n", d_frame);
     }
-    if ( unlikely(!mfn_valid(d_frame)) )
-        PIN_FAIL(error_put_d_gfn, GNTST_general_error,
-                 "destination frame %lx invalid.\n", d_frame);
-    if ( !get_page_and_type(mfn_to_page(d_frame), dest_domain,
-                            PGT_writable_page) )
+
+    if ( !get_page_type(d_pg, PGT_writable_page) )
     {
         if ( !dd->is_dying )
             gdprintk(XENLOG_WARNING, "Could not get dst frame %lx\n", d_frame);
         rc = GNTST_general_error;
-        goto error_put_d_gfn;
+        goto error_out;
     }
 
     sp = map_domain_page(s_frame);
@@ -2060,16 +2021,12 @@ __gnttab_copy(
 
     gnttab_mark_dirty(dd, d_frame);
 
-    put_page_and_type(mfn_to_page(d_frame));
- error_put_d_gfn:
-    if ( (d_gfn != INVALID_GFN) && (dest_domain) )
-        put_gfn(dest_domain, d_gfn);
- error_put_s_gfn:
-    if ( (s_gfn != INVALID_GFN) && (source_domain) )
-        put_gfn(source_domain, s_gfn);
+    put_page_type(d_pg);
  error_out:
-    if ( have_s_ref )
-        put_page(mfn_to_page(s_frame));
+    if ( d_pg )
+        put_page(d_pg);
+    if ( s_pg )
+        put_page(s_pg);
     if ( have_s_grant )
         __release_grant_for_copy(sd, op->source.u.ref, 1);
     if ( have_d_grant )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRP-0007xv-MJ; Fri, 27 Apr 2012 21:10:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRO-0007xI-FL
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:58 +0000
Received: from [85.158.143.99:49385] by server-1.bemta-4.messagelabs.com id
	8A/42-20925-16B0B9F4; Fri, 27 Apr 2012 21:10:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335561056!20343885!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxOTE3\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxOTE3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32379 invoked from network); 27 Apr 2012 21:10:56 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-4.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 21:10:56 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id D6DF5714075;
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=lWxCUN/V8vCwGWzk66wn8moYRQwytZguyDuPgDFP8kHI
	iRehf2qgBiGMDdAhsc/ntn7hPJvVFAkSo43vO1KKn3jw/SqhRqq0CYI1Zjbe9nT+
	8hfnPJtbp5bNAX8i7yXa/n1hD+4fjQsGBz6QAWzJFZBFyGN5QnAlz/IvID2nMyY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=YKvgzmPMboBcF7czHhFj+QF97tI=; b=K7wMMI8WjwV
	zl5zYnJ9Fpd3Uz6QqI8sOf4igHkfQYalVYzpmMH9u5bQ2Ulrm91VS8pY+YrqaLe9
	jZAn0PpCi7/kCeegbJ6hXsxCVecVl+TbHkecAhV4cLa5VPKIszJjkYzDAoA3oUCG
	HtPoK36El6cwlB3c3dsJCdRqJkubs1+E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 5B96871406B; 
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 07fda1825c295acf01786edc8e7fbd1732a76449
Message-Id: <07fda1825c295acf0178.1335561380@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 4] Use get page from gfn also in svm code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/svm/svm.c |  20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)


And clean up some unnecessary uses of get_gfn locked.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r ea8642853601 -r 07fda1825c29 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -232,8 +232,7 @@ static int svm_vmcb_save(struct vcpu *v,
 
 static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
 
@@ -250,10 +249,10 @@ static int svm_vmcb_restore(struct vcpu 
     {
         if ( c->cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, c->cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, c->cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n",
                          c->cr3);
                 return -EINVAL;
@@ -263,9 +262,8 @@ static int svm_vmcb_restore(struct vcpu 
         if ( v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( c->cr0 & X86_CR0_PG )
-            put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
+        v->arch.guest_table = 
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = c->cr0 | X86_CR0_ET;
@@ -1321,8 +1319,7 @@ static void svm_do_nested_pgfault(struct
         p2m = p2m_get_p2m(v);
         _d.gpa = gpa;
         _d.qualification = 0;
-        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL);
-        __put_gfn(p2m, gfn);
+        mfn = __get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL, 0);
         _d.mfn = mfn_x(mfn);
         
         __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
@@ -1343,8 +1340,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL);
-    __put_gfn(p2m, gfn);
+    mfn = __get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL, 0);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRP-0007xv-MJ; Fri, 27 Apr 2012 21:10:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRO-0007xI-FL
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:58 +0000
Received: from [85.158.143.99:49385] by server-1.bemta-4.messagelabs.com id
	8A/42-20925-16B0B9F4; Fri, 27 Apr 2012 21:10:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1335561056!20343885!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxOTE3\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxOTE3\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32379 invoked from network); 27 Apr 2012 21:10:56 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-4.tower-216.messagelabs.com with SMTP;
	27 Apr 2012 21:10:56 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id D6DF5714075;
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=lWxCUN/V8vCwGWzk66wn8moYRQwytZguyDuPgDFP8kHI
	iRehf2qgBiGMDdAhsc/ntn7hPJvVFAkSo43vO1KKn3jw/SqhRqq0CYI1Zjbe9nT+
	8hfnPJtbp5bNAX8i7yXa/n1hD+4fjQsGBz6QAWzJFZBFyGN5QnAlz/IvID2nMyY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=YKvgzmPMboBcF7czHhFj+QF97tI=; b=K7wMMI8WjwV
	zl5zYnJ9Fpd3Uz6QqI8sOf4igHkfQYalVYzpmMH9u5bQ2Ulrm91VS8pY+YrqaLe9
	jZAn0PpCi7/kCeegbJ6hXsxCVecVl+TbHkecAhV4cLa5VPKIszJjkYzDAoA3oUCG
	HtPoK36El6cwlB3c3dsJCdRqJkubs1+E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 5B96871406B; 
	Fri, 27 Apr 2012 14:10:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 07fda1825c295acf01786edc8e7fbd1732a76449
Message-Id: <07fda1825c295acf0178.1335561380@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 3 of 4] Use get page from gfn also in svm code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/hvm/svm/svm.c |  20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)


And clean up some unnecessary uses of get_gfn locked.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r ea8642853601 -r 07fda1825c29 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -232,8 +232,7 @@ static int svm_vmcb_save(struct vcpu *v,
 
 static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
 {
-    unsigned long mfn = 0;
-    p2m_type_t p2mt;
+    struct page_info *page = NULL;
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
 
@@ -250,10 +249,10 @@ static int svm_vmcb_restore(struct vcpu 
     {
         if ( c->cr0 & X86_CR0_PG )
         {
-            mfn = mfn_x(get_gfn(v->domain, c->cr3 >> PAGE_SHIFT, &p2mt));
-            if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) )
+            page = get_page_from_gfn(v->domain, c->cr3 >> PAGE_SHIFT,
+                                     NULL, P2M_ALLOC);
+            if ( !page )
             {
-                put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
                 gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n",
                          c->cr3);
                 return -EINVAL;
@@ -263,9 +262,8 @@ static int svm_vmcb_restore(struct vcpu 
         if ( v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG )
             put_page(pagetable_get_page(v->arch.guest_table));
 
-        v->arch.guest_table = pagetable_from_pfn(mfn);
-        if ( c->cr0 & X86_CR0_PG )
-            put_gfn(v->domain, c->cr3 >> PAGE_SHIFT);
+        v->arch.guest_table = 
+            page ? pagetable_from_page(page) : pagetable_null();
     }
 
     v->arch.hvm_vcpu.guest_cr[0] = c->cr0 | X86_CR0_ET;
@@ -1321,8 +1319,7 @@ static void svm_do_nested_pgfault(struct
         p2m = p2m_get_p2m(v);
         _d.gpa = gpa;
         _d.qualification = 0;
-        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL);
-        __put_gfn(p2m, gfn);
+        mfn = __get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL, 0);
         _d.mfn = mfn_x(mfn);
         
         __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
@@ -1343,8 +1340,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL);
-    __put_gfn(p2m, gfn);
+    mfn = __get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL, 0);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
          gpa, mfn_x(mfn), p2mt);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRP-0007xj-9V; Fri, 27 Apr 2012 21:10:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRN-0007x2-1N
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:57 +0000
Received: from [85.158.139.83:53219] by server-12.bemta-5.messagelabs.com id
	7D/52-01344-06B0B9F4; Fri, 27 Apr 2012 21:10:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335561054!18506164!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAyMTcyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4140 invoked from network); 27 Apr 2012 21:10:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-182.messagelabs.com with SMTP;
	27 Apr 2012 21:10:55 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 497B9714070;
	Fri, 27 Apr 2012 14:10:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ES+vE+nh5yoDbonJ1C4860pgV7rNaPY0eYG9PQ/7YqYv
	iyFiWu2N10SUx7V2zuja84w5c0cW/SsW54C8CTsRRJAN5bSA7kXCSvFD4CnsSFVb
	WDbkPBqrxkFO0i3w1/Fu0D5A4AnVzpEZe8+SdvCG1pf3tPQ3ZZKu4csniL4k1zY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=RNk+cneKoRDQPgw6/qnvYlq8fOs=; b=Qcmlf+E0MCV
	psfhh9r8QJxWQ0nP4ivsAcYuBR7LBfN3BRRRucC+lMPWpCvp3cbBxc8DV+KBc497
	CoJZs/7ZQY90DQsirSqJ5S6ye/7BJ6vYUfZPvG2hpOM7muJJbA9mZYstPSIIMpZy
	yJHEGHzg8npBejNezCvs9smrA3lkIf5M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id B8CE971406B; 
	Fri, 27 Apr 2012 14:10:53 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 00034349414ec903179d000ea517fadd8fc3745f
Message-Id: <00034349414ec903179d.1335561378@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:18 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 4] x86/mm: Eliminate _shadow_mode_refcounts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c               |  2 +-
 xen/arch/x86/mm/shadow/common.c |  5 -----
 xen/include/asm-x86/mm.h        |  1 -
 3 files changed, 1 insertions(+), 7 deletions(-)


Replace it with the proper paging_mode_refcounts. This was causing spurious
and abundant verbiage from Xen for the

 !get_page(page, d) && !get_page(page, dom_cow)

sequence in get_page_from_gfn

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 40938dc16dfa -r 00034349414e xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2167,7 +2167,7 @@ int get_page(struct page_info *page, str
     if ( owner != NULL )
         put_page(page);
 
-    if ( !_shadow_mode_refcounts(domain) && !domain->is_dying )
+    if ( !paging_mode_refcounts(domain) && !domain->is_dying )
         gdprintk(XENLOG_INFO,
                  "Error pfn %lx: rd=%p, od=%p, caf=%08lx, taf=%"
                  PRtype_info "\n",
diff -r 40938dc16dfa -r 00034349414e xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -105,11 +105,6 @@ static int __init shadow_audit_key_init(
 __initcall(shadow_audit_key_init);
 #endif /* SHADOW_AUDIT */
 
-int _shadow_mode_refcounts(struct domain *d)
-{
-    return shadow_mode_refcounts(d);
-}
-
 
 /**************************************************************************/
 /* x86 emulator support for the shadow code
diff -r 40938dc16dfa -r 00034349414e xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -331,7 +331,6 @@ static inline void *__page_to_virt(const
 
 int free_page_type(struct page_info *page, unsigned long type,
                    int preemptible);
-int _shadow_mode_refcounts(struct domain *d);
 
 int is_iomem_page(unsigned long mfn);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 21:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 21:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNsRP-0007xj-9V; Fri, 27 Apr 2012 21:10:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SNsRN-0007x2-1N
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 21:10:57 +0000
Received: from [85.158.139.83:53219] by server-12.bemta-5.messagelabs.com id
	7D/52-01344-06B0B9F4; Fri, 27 Apr 2012 21:10:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335561054!18506164!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAyMTcyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4140 invoked from network); 27 Apr 2012 21:10:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-182.messagelabs.com with SMTP;
	27 Apr 2012 21:10:55 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 497B9714070;
	Fri, 27 Apr 2012 14:10:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ES+vE+nh5yoDbonJ1C4860pgV7rNaPY0eYG9PQ/7YqYv
	iyFiWu2N10SUx7V2zuja84w5c0cW/SsW54C8CTsRRJAN5bSA7kXCSvFD4CnsSFVb
	WDbkPBqrxkFO0i3w1/Fu0D5A4AnVzpEZe8+SdvCG1pf3tPQ3ZZKu4csniL4k1zY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=RNk+cneKoRDQPgw6/qnvYlq8fOs=; b=Qcmlf+E0MCV
	psfhh9r8QJxWQ0nP4ivsAcYuBR7LBfN3BRRRucC+lMPWpCvp3cbBxc8DV+KBc497
	CoJZs/7ZQY90DQsirSqJ5S6ye/7BJ6vYUfZPvG2hpOM7muJJbA9mZYstPSIIMpZy
	yJHEGHzg8npBejNezCvs9smrA3lkIf5M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id B8CE971406B; 
	Fri, 27 Apr 2012 14:10:53 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 00034349414ec903179d000ea517fadd8fc3745f
Message-Id: <00034349414ec903179d.1335561378@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1335561377@xdev.gridcentric.ca>
References: <patchbomb.1335561377@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Apr 2012 17:16:18 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, keir@xen.org, andres@gridcentric.ca,
	tim@xen.org
Subject: [Xen-devel] [PATCH 1 of 4] x86/mm: Eliminate _shadow_mode_refcounts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c               |  2 +-
 xen/arch/x86/mm/shadow/common.c |  5 -----
 xen/include/asm-x86/mm.h        |  1 -
 3 files changed, 1 insertions(+), 7 deletions(-)


Replace it with the proper paging_mode_refcounts. This was causing spurious
and abundant verbiage from Xen for the

 !get_page(page, d) && !get_page(page, dom_cow)

sequence in get_page_from_gfn

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 40938dc16dfa -r 00034349414e xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2167,7 +2167,7 @@ int get_page(struct page_info *page, str
     if ( owner != NULL )
         put_page(page);
 
-    if ( !_shadow_mode_refcounts(domain) && !domain->is_dying )
+    if ( !paging_mode_refcounts(domain) && !domain->is_dying )
         gdprintk(XENLOG_INFO,
                  "Error pfn %lx: rd=%p, od=%p, caf=%08lx, taf=%"
                  PRtype_info "\n",
diff -r 40938dc16dfa -r 00034349414e xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -105,11 +105,6 @@ static int __init shadow_audit_key_init(
 __initcall(shadow_audit_key_init);
 #endif /* SHADOW_AUDIT */
 
-int _shadow_mode_refcounts(struct domain *d)
-{
-    return shadow_mode_refcounts(d);
-}
-
 
 /**************************************************************************/
 /* x86 emulator support for the shadow code
diff -r 40938dc16dfa -r 00034349414e xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -331,7 +331,6 @@ static inline void *__page_to_virt(const
 
 int free_page_type(struct page_info *page, unsigned long type,
                    int preemptible);
-int _shadow_mode_refcounts(struct domain *d);
 
 int is_iomem_page(unsigned long mfn);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 22:51:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 22:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNtzh-0000g1-Ng; Fri, 27 Apr 2012 22:50:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNtzg-0000fw-A3
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 22:50:28 +0000
Received: from [193.109.254.147:57769] by server-1.bemta-14.messagelabs.com id
	47/50-29372-3B22B9F4; Fri, 27 Apr 2012 22:50:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335567026!6686863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25964 invoked from network); 27 Apr 2012 22:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 22:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,493,1330905600"; d="scan'208";a="12185886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 22:50:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Apr 2012 23:50:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNtzd-0004g1-Cv;
	Fri, 27 Apr 2012 22:50:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNtzd-00059Z-CX;
	Fri, 27 Apr 2012 23:50:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12760-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Apr 2012 23:50:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12760: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12760 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12760/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12756
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 12758
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 12758

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  107285938c50

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=9dda0efd8ce1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 9dda0efd8ce1
+ branch=xen-unstable
+ revision=9dda0efd8ce1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 9dda0efd8ce1 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 22:51:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 22:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNtzh-0000g1-Ng; Fri, 27 Apr 2012 22:50:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SNtzg-0000fw-A3
	for xen-devel@lists.xensource.com; Fri, 27 Apr 2012 22:50:28 +0000
Received: from [193.109.254.147:57769] by server-1.bemta-14.messagelabs.com id
	47/50-29372-3B22B9F4; Fri, 27 Apr 2012 22:50:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1335567026!6686863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc0OQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25964 invoked from network); 27 Apr 2012 22:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 22:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,493,1330905600"; d="scan'208";a="12185886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Apr 2012 22:50:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Apr 2012 23:50:25 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SNtzd-0004g1-Cv;
	Fri, 27 Apr 2012 22:50:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SNtzd-00059Z-CX;
	Fri, 27 Apr 2012 23:50:25 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12760-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Apr 2012 23:50:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12760: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12760 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12760/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12756
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 12758
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 12758

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  107285938c50

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=9dda0efd8ce1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 9dda0efd8ce1
+ branch=xen-unstable
+ revision=9dda0efd8ce1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 9dda0efd8ce1 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Apr 27 23:07:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 23:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNuFS-0000tP-9E; Fri, 27 Apr 2012 23:06:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SNuFQ-0000tK-BF
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 23:06:44 +0000
Received: from [193.109.254.147:14108] by server-10.bemta-14.messagelabs.com
	id 45/8E-05847-3862B9F4; Fri, 27 Apr 2012 23:06:43 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335568002!6724466!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 27 Apr 2012 23:06:42 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 23:06:42 -0000
Received: by eaaf11 with SMTP id f11so317447eaa.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 16:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Q1gWAIrSht3CMhmq+fNCQhACAsph/oMMW9CCLJ2Pu6I=;
	b=y2hvbRasbRhgMltfpi52mvrEU65isdu/lVXdMg/5Plkh93/+26BBAf1eCZjG9u/9zE
	egVB3grcOWSz0AXQfQl0Drb7xehnmhi6Pie4ozfF8s+ADLqwx4FZLOAmocoMBizBfa46
	RvPU+bF0xzVYux6UHwe+62HScc4bIsSM7mZk17g4M0aGNFsEIGLowq2uOZsH/0f8CWaC
	CStNGX4+RRloiAbo4DZNHm/+eZFo1fkEeJ7ye1O+1Pbd5LqiW6vU8R/STU4od077gCCf
	QMljyk8c2vbLbWOQSdku62kA/25DI53F6bzxHGyZriweqWDmV/Wvi6Gb5NhZ2xT+N40c
	xazA==
MIME-Version: 1.0
Received: by 10.213.110.7 with SMTP id l7mr913913ebp.7.1335568002354; Fri, 27
	Apr 2012 16:06:42 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Fri, 27 Apr 2012 16:06:42 -0700 (PDT)
In-Reply-To: <1335550792.4881.76.camel@dagon.hellion.org.uk>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
	<1335550792.4881.76.camel@dagon.hellion.org.uk>
Date: Sat, 28 Apr 2012 01:06:42 +0200
Message-ID: <CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6669231586495614634=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6669231586495614634==
Content-Type: multipart/alternative; boundary=0015174766f85a8f1204beb128fa

--0015174766f85a8f1204beb128fa
Content-Type: text/plain; charset=ISO-8859-1

> You don't appear to have setup any bridges on your host.
>
> http://wiki.xen.org/wiki/HostConfiguration/Networking should lead you
> through the necessary steps.
>
> Ian.
>
>
Ian,

Thanks for that. It looks like it has sorted out the issue.

I am surprised that I did NOT have to setup my networking in this manner
when I first installed openindiana. I just configured the vm with vif =
bridge=eth0, and it worked.


I had a feeling it was something silly...

Thanks for your time and patience.

Regards

Sandi

--0015174766f85a8f1204beb128fa
Content-Type: text/html; charset=ISO-8859-1

<div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
</div>You don&#39;t appear to have setup any bridges on your host.<br>
<br>
<a href="http://wiki.xen.org/wiki/HostConfiguration/Networking" target="_blank">http://wiki.xen.org/wiki/HostConfiguration/Networking</a> should lead you<br>
through the necessary steps.<br>
<span class="HOEnZb"><font color="#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_extra">Ian,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for that. It looks like it has sorted out the issue.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I am surprised that I did NOT have to setup my networking in this manner when I first installed openindiana. I just configured the vm with vif = bridge=eth0, and it worked.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I had a feeling it was something silly...</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your time and patience.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Regards</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sandi</div><div><br></div></div>

--0015174766f85a8f1204beb128fa--


--===============6669231586495614634==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6669231586495614634==--


From xen-devel-bounces@lists.xen.org Fri Apr 27 23:07:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Apr 2012 23:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNuFS-0000tP-9E; Fri, 27 Apr 2012 23:06:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1SNuFQ-0000tK-BF
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 23:06:44 +0000
Received: from [193.109.254.147:14108] by server-10.bemta-14.messagelabs.com
	id 45/8E-05847-3862B9F4; Fri, 27 Apr 2012 23:06:43 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335568002!6724466!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 27 Apr 2012 23:06:42 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 23:06:42 -0000
Received: by eaaf11 with SMTP id f11so317447eaa.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 16:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Q1gWAIrSht3CMhmq+fNCQhACAsph/oMMW9CCLJ2Pu6I=;
	b=y2hvbRasbRhgMltfpi52mvrEU65isdu/lVXdMg/5Plkh93/+26BBAf1eCZjG9u/9zE
	egVB3grcOWSz0AXQfQl0Drb7xehnmhi6Pie4ozfF8s+ADLqwx4FZLOAmocoMBizBfa46
	RvPU+bF0xzVYux6UHwe+62HScc4bIsSM7mZk17g4M0aGNFsEIGLowq2uOZsH/0f8CWaC
	CStNGX4+RRloiAbo4DZNHm/+eZFo1fkEeJ7ye1O+1Pbd5LqiW6vU8R/STU4od077gCCf
	QMljyk8c2vbLbWOQSdku62kA/25DI53F6bzxHGyZriweqWDmV/Wvi6Gb5NhZ2xT+N40c
	xazA==
MIME-Version: 1.0
Received: by 10.213.110.7 with SMTP id l7mr913913ebp.7.1335568002354; Fri, 27
	Apr 2012 16:06:42 -0700 (PDT)
Received: by 10.213.35.138 with HTTP; Fri, 27 Apr 2012 16:06:42 -0700 (PDT)
In-Reply-To: <1335550792.4881.76.camel@dagon.hellion.org.uk>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
	<1335550792.4881.76.camel@dagon.hellion.org.uk>
Date: Sat, 28 Apr 2012 01:06:42 +0200
Message-ID: <CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6669231586495614634=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6669231586495614634==
Content-Type: multipart/alternative; boundary=0015174766f85a8f1204beb128fa

--0015174766f85a8f1204beb128fa
Content-Type: text/plain; charset=ISO-8859-1

> You don't appear to have setup any bridges on your host.
>
> http://wiki.xen.org/wiki/HostConfiguration/Networking should lead you
> through the necessary steps.
>
> Ian.
>
>
Ian,

Thanks for that. It looks like it has sorted out the issue.

I am surprised that I did NOT have to setup my networking in this manner
when I first installed openindiana. I just configured the vm with vif =
bridge=eth0, and it worked.


I had a feeling it was something silly...

Thanks for your time and patience.

Regards

Sandi

--0015174766f85a8f1204beb128fa
Content-Type: text/html; charset=ISO-8859-1

<div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
</div>You don&#39;t appear to have setup any bridges on your host.<br>
<br>
<a href="http://wiki.xen.org/wiki/HostConfiguration/Networking" target="_blank">http://wiki.xen.org/wiki/HostConfiguration/Networking</a> should lead you<br>
through the necessary steps.<br>
<span class="HOEnZb"><font color="#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_extra">Ian,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for that. It looks like it has sorted out the issue.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I am surprised that I did NOT have to setup my networking in this manner when I first installed openindiana. I just configured the vm with vif = bridge=eth0, and it worked.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I had a feeling it was something silly...</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your time and patience.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Regards</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sandi</div><div><br></div></div>

--0015174766f85a8f1204beb128fa--


--===============6669231586495614634==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6669231586495614634==--


From xen-devel-bounces@lists.xen.org Sat Apr 28 01:26:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 01:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNwPb-0005dK-7T; Sat, 28 Apr 2012 01:25:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNwPZ-0005dF-In
	for Xen-devel@lists.xensource.com; Sat, 28 Apr 2012 01:25:21 +0000
Received: from [85.158.139.83:48316] by server-12.bemta-5.messagelabs.com id
	07/DD-01344-0074B9F4; Sat, 28 Apr 2012 01:25:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335576318!14610246!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5OTUxMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11542 invoked from network); 28 Apr 2012 01:25:19 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Apr 2012 01:25:19 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3S1PEn4028740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 28 Apr 2012 01:25:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3S1PEb8023552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 28 Apr 2012 01:25:14 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3S1PDV5026102; Fri, 27 Apr 2012 20:25:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Apr 2012 18:25:13 -0700
Date: Fri, 27 Apr 2012 18:25:01 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120427182501.197681ff@mantra.us.oracle.com>
In-Reply-To: <CBBEB681.319A3%keir.xen@gmail.com>
References: <20120425180729.6a8f7127@mantra.us.oracle.com>
	<CBBEB681.319A3%keir.xen@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012 08:23:29 +0100
Keir Fraser <keir.xen@gmail.com> wrote:

> On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
> 
> > However, I don't understand the use of hvm_asid_flush_core which
> > it appears will cause all HVM vcpu's to get new vpid/asid, hence,
> > discard all previously used VPID tagged TLBs. In particular,
> > consider a PV guest:
> > 
> > write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs ->
> > hvm_asid_flush_core().
> > 
> > Since the PV guest is only using VPID 0 tagged TLBs, why do we need
> > to flush all TLBs for all HVM guests?
> 
> It's just being conservative, as callers of write_cr3 may assume that
> the TLB is entirely flushed, for all guests.

Well, for write_cr3 path at least, we just need to invalidate all TLBs
in the local pcpu. So it seems for this path we could just do 
invvpid with type 2, ie, invalidate all vpids except 0. Prob also need
to do 'invept 2'. what do you think, worth it?

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 01:26:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 01:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNwPb-0005dK-7T; Sat, 28 Apr 2012 01:25:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SNwPZ-0005dF-In
	for Xen-devel@lists.xensource.com; Sat, 28 Apr 2012 01:25:21 +0000
Received: from [85.158.139.83:48316] by server-12.bemta-5.messagelabs.com id
	07/DD-01344-0074B9F4; Sat, 28 Apr 2012 01:25:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1335576318!14610246!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5OTUxMA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11542 invoked from network); 28 Apr 2012 01:25:19 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Apr 2012 01:25:19 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3S1PEn4028740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 28 Apr 2012 01:25:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3S1PEb8023552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 28 Apr 2012 01:25:14 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3S1PDV5026102; Fri, 27 Apr 2012 20:25:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Apr 2012 18:25:13 -0700
Date: Fri, 27 Apr 2012 18:25:01 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120427182501.197681ff@mantra.us.oracle.com>
In-Reply-To: <CBBEB681.319A3%keir.xen@gmail.com>
References: <20120425180729.6a8f7127@mantra.us.oracle.com>
	<CBBEB681.319A3%keir.xen@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 26 Apr 2012 08:23:29 +0100
Keir Fraser <keir.xen@gmail.com> wrote:

> On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
> 
> > However, I don't understand the use of hvm_asid_flush_core which
> > it appears will cause all HVM vcpu's to get new vpid/asid, hence,
> > discard all previously used VPID tagged TLBs. In particular,
> > consider a PV guest:
> > 
> > write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs ->
> > hvm_asid_flush_core().
> > 
> > Since the PV guest is only using VPID 0 tagged TLBs, why do we need
> > to flush all TLBs for all HVM guests?
> 
> It's just being conservative, as callers of write_cr3 may assume that
> the TLB is entirely flushed, for all guests.

Well, for write_cr3 path at least, we just need to invalidate all TLBs
in the local pcpu. So it seems for this path we could just do 
invvpid with type 2, ie, invalidate all vpids except 0. Prob also need
to do 'invept 2'. what do you think, worth it?

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 04:23:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 04:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNzB3-0007Ly-6j; Sat, 28 Apr 2012 04:22:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNzB0-0007Lt-Tn
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 04:22:31 +0000
Received: from [85.158.139.83:13427] by server-9.bemta-5.messagelabs.com id
	54/BD-09826-6807B9F4; Sat, 28 Apr 2012 04:22:30 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335586947!18530037!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7515 invoked from network); 28 Apr 2012 04:22:28 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 04:22:28 -0000
Received: by lboi15 with SMTP id i15so1120400lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 21:22:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6Yb8GQAYXQEI4/mKsnE7gLz80DS4dOl0GtFbQ3HgGuE=;
	b=p1rkwvbceYgPO3fI5iYg75z6kGKnfh5nFQTS9mCHOZ7Vzt6vTCximcjVExNOOpFAXa
	4htCElhWnR6aLnG4Wdq9eTSeVSz2n0yA8FggIuO1lW/PLlM1wg0x8L94uCtkxDQcQ0y+
	IOVUFxxsLuuWU+yD4pkwlIozhCGnx4NJ8wonE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=6Yb8GQAYXQEI4/mKsnE7gLz80DS4dOl0GtFbQ3HgGuE=;
	b=hvoa7mtdV6xhsVwTpuQegVJFnTLL/A9REWB43WsfUpDTQafOuV+t9hGLDvwHPxCMoz
	yKmhVXNIOsyUDiPepylBKcJb1HOEICJvu5aCxM9MXzcA02/IVikdoHAHg/0XMnFg+1B6
	SIcEzo9U69cStNBWlTQFHI1pqoHz7j2JcszMgvNo1Sw24BDOPc9UE7nys6lafUdbbEfh
	JoR6CLt/Fpj8CyRyYVgRhIFLDpX7dh/eOnGN1R6wp3ovzu+fgWXM+sfzW+66eFJJ9Bal
	8IWLvQDKj8fGEXBv9qlf84cAzdRxTUAj0/Wfyx9IojeZX45mZpgdoxbom1m2EdEYhq3z
	wiYQ==
MIME-Version: 1.0
Received: by 10.152.148.101 with SMTP id tr5mr12557200lab.36.1335586946870;
	Fri, 27 Apr 2012 21:22:26 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 21:22:26 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <CAB10MZAbS73A5162MMxs9LzkEzNHYO-tGtrpk-H9_NpRuEAGuw@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
	<CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
	<CAB10MZAbS73A5162MMxs9LzkEzNHYO-tGtrpk-H9_NpRuEAGuw@mail.gmail.com>
Date: Fri, 27 Apr 2012 21:22:26 -0700
Message-ID: <CAB10MZDCWd27=Wd4x2iZa5EMxV3_L3bLgyqf7hgP+ACzOV_=Dg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQkwwD73jI9nZea7IQAR6hIjHT/3aQskXPrSTln1UEWahwFSnCB5AIBJ30dNGSi4ORaH0bBf
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 11:25 AM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Fri, Apr 27, 2012 at 10:37 AM, Christian Limpach
> <christian.limpach@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>>
>>> On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.c=
om>
>>> wrote:
>>>>
>>>> Maybe you can do something similar, for example passing in a hint
>>>> whether ept_sync_domain needs to be done or not. =A0In my case, the
>>>> reasoning is that all the entries changed from hap_clean_vram_tracking
>>>> are leaf entries, so ept_free_entry will never be called and thus
>>>> ept_sync_domain can be deferred. =A0I didn't think through/consider the
>>>> iommu case since that code is commented out in my tree.
>>>
>>> I thought about doing that initially. But then in the bulk case I would
>>> always have to call ept_sync_domain() to be on the safe side. But if the
>>> iommu case forces me down that path, then I guess I have no choice.
>>
>> I think you should re-consider. =A0It would avoid adding the extra
>> wrapper, which makes this code a lot less readable. =A0Plus it avoids
>> the need for the old_entries array.
>>
>> Let me re-iterate:
>> - if it's a leaf entry, then there's no need to call ept_free_entry
>> - if you don't need to call ept_free_entry, then you can defer
>> ept_sync_domain (subject to the iommu case)
>> - you could pass in a pointer to a bool to indicate to the caller that
>> ept_sync_domain was deferred and that the caller needs to do it, with
>> a NULL pointer indicating that the caller doesn't support defer

How does this look?

changeset:   25257:2c05bdb052ea
user:        Aravindh Puthiyaparambil <aravindh@virtuata.com>
date:        Fri Apr 27 20:28:37 2012 -0700
summary:     x86/mm: Add sync deferred option to p2m->set_entry()

diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/mem_sharing.c	Fri Apr 27 20:28:37 2012 -0700
@@ -1272,7 +1272,7 @@ int relinquish_shared_pages(struct domai
             /* Clear out the p2m entry so no one else may try to
              * unshare */
             p2m->set_entry(p2m, gfn, _mfn(0), PAGE_ORDER_4K,
-                            p2m_invalid, p2m_access_rwx);
+                            p2m_invalid, p2m_access_rwx, NULL);
             count++;
         }

diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/p2m-ept.c	Fri Apr 27 20:28:37 2012 -0700
@@ -274,10 +274,13 @@ static int ept_next_level(struct p2m_dom
 /*
  * ept_set_entry() computes 'need_modify_vtd_table' for itself,
  * by observing whether any gfn->mfn translations are modified.
+ * If sync_deferred is not NULL, then the caller will take care of
+ * calling ept_sync_domain() in the cases where it can be deferred.
  */
 static int
 ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
-              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
+              bool_t *sync_deferred)
 {
     ept_entry_t *table, *ept_entry =3D NULL;
     unsigned long gfn_remainder =3D gfn;
@@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, un
     int needs_sync =3D 1;
     struct domain *d =3D p2m->domain;
     ept_entry_t old_entry =3D { .epte =3D 0 };
+    bool_t _sync_deferred =3D 0;

     /*
      * the caller must make sure:
@@ -309,6 +313,9 @@ ept_set_entry(struct p2m_domain *p2m, un
            (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
            (target =3D=3D 0));

+    if (sync_deferred)
+        *sync_deferred =3D 1;
+
     table =3D map_domain_page(ept_get_asr(d));

     for ( i =3D ept_get_wl(d); i > target; i-- )
@@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un

         /* No need to flush if the old entry wasn't valid */
         if ( !is_epte_present(ept_entry) )
+        {
             needs_sync =3D 0;
+            if ( sync_deferred )
+                *sync_deferred =3D 0;
+        }

         /* If we're replacing a non-leaf entry with a leaf entry
(1GiB or 2MiB),
          * the intermediate tables will be freed below after the ept flush
@@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un

         ASSERT(is_epte_superpage(ept_entry));

+        if ( sync_deferred )
+            _sync_deferred =3D 1;
+
         split_ept_entry =3D atomic_read_ept_entry(ept_entry);

         if ( !ept_split_super_page(p2m, &split_ept_entry, i, target) )
@@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un
 out:
     unmap_domain_page(table);

-    if ( needs_sync )
+    if ( needs_sync && !_sync_deferred )
         ept_sync_domain(p2m->domain);

     if ( rv && iommu_enabled && need_iommu(p2m->domain) &&
need_modify_vtd_table )
@@ -727,7 +741,8 @@ void ept_change_entry_emt_with_range(str
                     order =3D level * EPT_TABLE_ORDER;
                     if ( need_modify_ept_entry(p2m, gfn, mfn,
                           e.ipat, e.emt, e.sa_p2mt) )
-                        ept_set_entry(p2m, gfn, mfn, order,
e.sa_p2mt, e.access);
+                        ept_set_entry(p2m, gfn, mfn, order,
e.sa_p2mt, e.access,
+                                      NULL);
                     gfn +=3D trunk;
                     break;
                 }
@@ -737,7 +752,7 @@ void ept_change_entry_emt_with_range(str
         else /* gfn assigned with 4k */
         {
             if ( need_modify_ept_entry(p2m, gfn, mfn, e.ipat, e.emt,
e.sa_p2mt) )
-                ept_set_entry(p2m, gfn, mfn, order, e.sa_p2mt, e.access);
+                ept_set_entry(p2m, gfn, mfn, order, e.sa_p2mt, e.access, N=
ULL);
         }
     }
     p2m_unlock(p2m);
diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/p2m-pt.c	Fri Apr 27 20:28:37 2012 -0700
@@ -291,7 +291,8 @@ p2m_next_level(struct p2m_domain *p2m, m
 // Returns 0 on error (out of memory)
 static int
 p2m_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
-              unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
+              unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma,
+              bool_t *unused)
 {
     // XXX -- this might be able to be faster iff current->domain =3D=3D d
     mfn_t table_mfn =3D pagetable_get_mfn(p2m_get_pagetable(p2m));
diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/p2m.c	Fri Apr 27 20:28:37 2012 -0700
@@ -227,7 +227,7 @@ int set_p2m_entry(struct p2m_domain *p2m
         else
             order =3D 0;

-        if ( !p2m->set_entry(p2m, gfn, mfn, order, p2mt, p2ma) )
+        if ( !p2m->set_entry(p2m, gfn, mfn, order, p2mt, p2ma, NULL) )
             rc =3D 0;
         gfn +=3D 1ul << order;
         if ( mfn_x(mfn) !=3D INVALID_MFN )
@@ -1199,14 +1199,14 @@ bool_t p2m_mem_access_check(unsigned lon

     if ( access_w && p2ma =3D=3D p2m_access_rx2rw )
     {
-        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rw, NULL);
         gfn_unlock(p2m, gfn, 0);
         return 1;
     }
     else if ( p2ma =3D=3D p2m_access_n2rwx )
     {
         ASSERT(access_w || access_r || access_x);
-        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rwx, NULL);
     }
     gfn_unlock(p2m, gfn, 0);

@@ -1228,7 +1228,8 @@ bool_t p2m_mem_access_check(unsigned lon
             {
                 /* A listener is not required, so clear the access
restrictions */
                 gfn_lock(p2m, gfn, 0);
-                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rwx);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
+                               p2m_access_rwx, NULL);
                 gfn_unlock(p2m, gfn, 0);
             }
             return 1;
@@ -1292,6 +1293,7 @@ int p2m_set_mem_access(struct domain *d,
     p2m_type_t t;
     mfn_t mfn;
     int rc =3D 0;
+    bool_t sync_deferred =3D 1;

     /* N.B. _not_ static: initializer depends on p2m->default_access */
     p2m_access_t memaccess[] =3D {
@@ -1324,12 +1326,17 @@ int p2m_set_mem_access(struct domain *d,
     for ( pfn =3D start_pfn; pfn < start_pfn + nr; pfn++ )
     {
         mfn =3D p2m->get_entry(p2m, pfn, &t, &_a, 0, NULL);
-        if ( p2m->set_entry(p2m, pfn, mfn, PAGE_ORDER_4K, t, a) =3D=3D 0 )
+        if ( p2m->set_entry(p2m, pfn, mfn, PAGE_ORDER_4K, t, a, &sync_defe=
rred)
+             =3D=3D 0 )
         {
             rc =3D -ENOMEM;
             break;
         }
     }
+
+    if ( sync_deferred )
+        ept_sync_domain(p2m->domain);
+
     p2m_unlock(p2m);
     return rc;
 }
diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/include/asm-x86/p2m.h	Fri Apr 27 20:28:37 2012 -0700
@@ -231,7 +231,8 @@ struct p2m_domain {
                                        unsigned long gfn,
                                        mfn_t mfn, unsigned int page_order,
                                        p2m_type_t p2mt,
-                                       p2m_access_t p2ma);
+                                       p2m_access_t p2ma,
+                                       bool_t *sync_deferred);
     mfn_t              (*get_entry   )(struct p2m_domain *p2m,
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,

changeset:   25258:5a0d60bb536b
user:        Aravindh Puthiyaparambil <aravindh@virtuata.com>
date:        Fri Apr 27 21:10:59 2012 -0700
summary:     mem_access: Add xc_hvm_mem_access_bulk() API

diff -r 2c05bdb052ea -r 5a0d60bb536b tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Fri Apr 27 20:28:37 2012 -0700
+++ b/tools/libxc/xc_misc.c	Fri Apr 27 21:10:59 2012 -0700
@@ -570,6 +570,57 @@ int xc_hvm_set_mem_access(
     return rc;
 }

+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t mem_access,
+    xen_pfn_t *arr, int *err, uint64_t nr)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_access_bulk, arg);
+    DECLARE_HYPERCALL_BOUNCE(arr, sizeof(xen_pfn_t) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(err, sizeof(int) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    int rc;
+
+    arg =3D xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+    if ( arg =3D=3D NULL )
+    {
+        PERROR("Could not allocate memory for
xc_hvm_set_mem_access_bulk hypercall");
+        return -1;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, arr) ) {
+        PERROR("Could not bounce arr for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, err) ) {
+        PERROR("Could not bounce err for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    arg->domid         =3D dom;
+    arg->hvmmem_access =3D mem_access;
+    arg->nr            =3D nr;
+    set_xen_guest_handle(arg->arr, arr);
+    set_xen_guest_handle(arg->err, err);
+
+    hypercall.op     =3D __HYPERVISOR_hvm_op;
+    hypercall.arg[0] =3D HVMOP_set_mem_access_bulk;
+    hypercall.arg[1] =3D HYPERCALL_BUFFER_AS_ARG(arg);
+
+    rc =3D do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, arg);
+    xc_hypercall_bounce_post(xch, arr);
+    xc_hypercall_bounce_post(xch, err);
+
+    return rc;
+}
+
 int xc_hvm_get_mem_access(
     xc_interface *xch, domid_t dom, uint64_t pfn, hvmmem_access_t* mem_acc=
ess)
 {
diff -r 2c05bdb052ea -r 5a0d60bb536b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Apr 27 20:28:37 2012 -0700
+++ b/tools/libxc/xenctrl.h	Fri Apr 27 21:10:59 2012 -0700
@@ -1568,6 +1568,17 @@ int xc_hvm_set_mem_access(
     xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
uint64_t first_pfn, uint64_t nr);

 /*
+ * Set the arry of pfns to a specific access.
+ * When a pfn cannot be set to the specified access, its respective field =
in
+ * @err is set to the corresponding errno value.
+ * Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combinati=
on of
+ * HVM_access_ + (rwx), and HVM_access_rx2rw
+ */
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
+    xen_pfn_t *arr, int *err, uint64_t num);
+
+/*
  * Gets the mem access for the given page (returned in memacess on success)
  */
 int xc_hvm_get_mem_access(
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/arch/x86/hvm/hvm.c	Fri Apr 27 21:10:59 2012 -0700
@@ -4197,6 +4197,51 @@ long do_hvm_op(unsigned long op, XEN_GUE
         break;
     }

+    case HVMOP_set_mem_access_bulk:
+    {
+        struct xen_hvm_set_mem_access_bulk a;
+        struct domain *d;
+        xen_pfn_t *arr =3D 0;
+        int *err =3D 0;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc =3D rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        if ( rc !=3D 0 )
+            return rc;
+
+        rc =3D -EINVAL;
+
+        if ( !is_hvm_domain(d) )
+            goto param_fail9;
+
+        rc =3D -ENOMEM;
+        arr =3D xmalloc_array(xen_pfn_t, a.nr);
+        if (!arr)
+            goto param_fail9;
+
+        err =3D xmalloc_array(int, a.nr);
+        if (!err)
+            goto param_fail9;
+
+        if ( copy_from_guest(arr, a.arr, a.nr) )
+            goto param_fail9;
+
+        rc =3D p2m_set_access_bulk(d, arr, err, a.nr, a.hvmmem_access);
+
+        if ( copy_to_guest(a.err, err, a.nr) )
+            goto param_fail9;
+
+    param_fail9:
+        rcu_unlock_domain(d);
+        if (arr)
+            xfree(arr);
+        if (err)
+            xfree(err);
+        break;
+    }
+
     case HVMOP_get_mem_access:
     {
         struct xen_hvm_get_mem_access a;
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/arch/x86/mm/p2m.c	Fri Apr 27 21:10:59 2012 -0700
@@ -1341,6 +1341,61 @@ int p2m_set_mem_access(struct domain *d,
     return rc;
 }

+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access)
+{
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+    unsigned long pfn;
+    p2m_access_t a, _a;
+    p2m_type_t t;
+    p2m_access_t memaccess[] =3D {
+        p2m_access_n,
+        p2m_access_r,
+        p2m_access_w,
+        p2m_access_rw,
+        p2m_access_x,
+        p2m_access_rx,
+        p2m_access_wx,
+        p2m_access_rwx,
+        p2m_access_rx2rw,
+        p2m_access_n2rwx,
+        p2m->default_access,
+    };
+    mfn_t mfn;
+    int rc;
+    bool_t sync_deferred =3D 1;
+
+    if ( (unsigned) access >=3D HVMMEM_access_default )
+        return -EINVAL;
+
+    a =3D memaccess[access];
+
+    p2m_lock(p2m);
+
+    for ( pfn =3D 0; pfn < nr; pfn++ )
+    {
+        if ( arr[pfn] > domain_get_maximum_gpfn(d) )
+        {
+            err[pfn] =3D -EINVAL;
+            continue;
+        }
+
+        mfn =3D p2m->get_entry(p2m, arr[pfn], &t, &_a, 0, NULL);
+        rc =3D p2m->set_entry(p2m, arr[pfn], mfn, PAGE_ORDER_4K, t, a,
+                            &sync_deferred);
+        if ( rc =3D=3D 0 )
+            err[pfn] =3D -ENOMEM;
+    }
+
+    if ( sync_deferred )
+        ept_sync_domain(p2m->domain);
+
+    p2m_unlock(p2m);
+
+    return 0;
+}
+
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/include/asm-x86/p2m.h	Fri Apr 27 21:10:59 2012 -0700
@@ -574,6 +574,11 @@ void p2m_mem_access_resume(struct domain
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn,
                        uint32_t nr, hvmmem_access_t access);

+/* Set access type for an array of pfns. set_mem_access success or failure=
 is
+ * returned in the err array. */
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access);
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
@@ -589,7 +594,11 @@ static inline int p2m_set_mem_access(str
                                      unsigned long start_pfn,
                                      uint32_t nr, hvmmem_access_t access)
 { return -EINVAL; }
-static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
+static inline int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr,
+                                      int *err, uint64_t nr,
+                                      hvmmem_access_t access)
+{ return -EINVAL; }
+static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
                                      hvmmem_access_t *access)
 { return -EINVAL; }
 #endif
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/include/public/hvm/hvm_op.h	Fri Apr 27 21:10:59 2012 -0700
@@ -261,4 +261,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_inject_m

 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */

+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define HVMOP_set_mem_access_bulk      17
+/* Notify that a array of pfns is to have specific access types */
+struct xen_hvm_set_mem_access_bulk {
+    /* Domain to be updated. */
+    domid_t domid;
+    /* Memory type */
+    uint16_t hvmmem_access; /* hvm_access_t */
+    /* Array of pfns */
+    XEN_GUEST_HANDLE_64(xen_pfn_t) arr;
+    XEN_GUEST_HANDLE_64(int) err ;
+    /* Number of entries */
+    uint64_t nr;
+};
+typedef struct xen_hvm_set_mem_access_bulk xen_hvm_set_mem_access_bulk_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_mem_access_bulk_t);
+#endif
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 04:23:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 04:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SNzB3-0007Ly-6j; Sat, 28 Apr 2012 04:22:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1SNzB0-0007Lt-Tn
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 04:22:31 +0000
Received: from [85.158.139.83:13427] by server-9.bemta-5.messagelabs.com id
	54/BD-09826-6807B9F4; Sat, 28 Apr 2012 04:22:30 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1335586947!18530037!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7515 invoked from network); 28 Apr 2012 04:22:28 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 04:22:28 -0000
Received: by lboi15 with SMTP id i15so1120400lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 21:22:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6Yb8GQAYXQEI4/mKsnE7gLz80DS4dOl0GtFbQ3HgGuE=;
	b=p1rkwvbceYgPO3fI5iYg75z6kGKnfh5nFQTS9mCHOZ7Vzt6vTCximcjVExNOOpFAXa
	4htCElhWnR6aLnG4Wdq9eTSeVSz2n0yA8FggIuO1lW/PLlM1wg0x8L94uCtkxDQcQ0y+
	IOVUFxxsLuuWU+yD4pkwlIozhCGnx4NJ8wonE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=6Yb8GQAYXQEI4/mKsnE7gLz80DS4dOl0GtFbQ3HgGuE=;
	b=hvoa7mtdV6xhsVwTpuQegVJFnTLL/A9REWB43WsfUpDTQafOuV+t9hGLDvwHPxCMoz
	yKmhVXNIOsyUDiPepylBKcJb1HOEICJvu5aCxM9MXzcA02/IVikdoHAHg/0XMnFg+1B6
	SIcEzo9U69cStNBWlTQFHI1pqoHz7j2JcszMgvNo1Sw24BDOPc9UE7nys6lafUdbbEfh
	JoR6CLt/Fpj8CyRyYVgRhIFLDpX7dh/eOnGN1R6wp3ovzu+fgWXM+sfzW+66eFJJ9Bal
	8IWLvQDKj8fGEXBv9qlf84cAzdRxTUAj0/Wfyx9IojeZX45mZpgdoxbom1m2EdEYhq3z
	wiYQ==
MIME-Version: 1.0
Received: by 10.152.148.101 with SMTP id tr5mr12557200lab.36.1335586946870;
	Fri, 27 Apr 2012 21:22:26 -0700 (PDT)
Received: by 10.112.47.100 with HTTP; Fri, 27 Apr 2012 21:22:26 -0700 (PDT)
X-Originating-IP: [108.237.46.73]
In-Reply-To: <CAB10MZAbS73A5162MMxs9LzkEzNHYO-tGtrpk-H9_NpRuEAGuw@mail.gmail.com>
References: <patchbomb.1335465209@vollum>
	<CAHDtvhrmhhgxMYg4Lguums83tgsp6z+RDipj2ZkN7MvMNk+zbw@mail.gmail.com>
	<CAB10MZB4XOhROFD1f2g9CXJhJYqnCa=34agjU43grHx3kP9CqA@mail.gmail.com>
	<CAB10MZDp4nPLFaFHzjEaE-pF20hmLJQwOsVQCuU9y5zR221zLg@mail.gmail.com>
	<CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>
	<CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com>
	<CAHDtvhq_C-bkDajEXeN0Z-y0=xfVOcCXU4pTz=WRVVwTyuxW0A@mail.gmail.com>
	<CAB10MZAbS73A5162MMxs9LzkEzNHYO-tGtrpk-H9_NpRuEAGuw@mail.gmail.com>
Date: Fri, 27 Apr 2012 21:22:26 -0700
Message-ID: <CAB10MZDCWd27=Wd4x2iZa5EMxV3_L3bLgyqf7hgP+ACzOV_=Dg@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
X-Gm-Message-State: ALoCoQkwwD73jI9nZea7IQAR6hIjHT/3aQskXPrSTln1UEWahwFSnCB5AIBJ30dNGSi4ORaH0bBf
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access
 type for an array of gfns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Apr 27, 2012 at 11:25 AM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Fri, Apr 27, 2012 at 10:37 AM, Christian Limpach
> <christian.limpach@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>>>
>>> On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.c=
om>
>>> wrote:
>>>>
>>>> Maybe you can do something similar, for example passing in a hint
>>>> whether ept_sync_domain needs to be done or not. =A0In my case, the
>>>> reasoning is that all the entries changed from hap_clean_vram_tracking
>>>> are leaf entries, so ept_free_entry will never be called and thus
>>>> ept_sync_domain can be deferred. =A0I didn't think through/consider the
>>>> iommu case since that code is commented out in my tree.
>>>
>>> I thought about doing that initially. But then in the bulk case I would
>>> always have to call ept_sync_domain() to be on the safe side. But if the
>>> iommu case forces me down that path, then I guess I have no choice.
>>
>> I think you should re-consider. =A0It would avoid adding the extra
>> wrapper, which makes this code a lot less readable. =A0Plus it avoids
>> the need for the old_entries array.
>>
>> Let me re-iterate:
>> - if it's a leaf entry, then there's no need to call ept_free_entry
>> - if you don't need to call ept_free_entry, then you can defer
>> ept_sync_domain (subject to the iommu case)
>> - you could pass in a pointer to a bool to indicate to the caller that
>> ept_sync_domain was deferred and that the caller needs to do it, with
>> a NULL pointer indicating that the caller doesn't support defer

How does this look?

changeset:   25257:2c05bdb052ea
user:        Aravindh Puthiyaparambil <aravindh@virtuata.com>
date:        Fri Apr 27 20:28:37 2012 -0700
summary:     x86/mm: Add sync deferred option to p2m->set_entry()

diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/mem_sharing.c	Fri Apr 27 20:28:37 2012 -0700
@@ -1272,7 +1272,7 @@ int relinquish_shared_pages(struct domai
             /* Clear out the p2m entry so no one else may try to
              * unshare */
             p2m->set_entry(p2m, gfn, _mfn(0), PAGE_ORDER_4K,
-                            p2m_invalid, p2m_access_rwx);
+                            p2m_invalid, p2m_access_rwx, NULL);
             count++;
         }

diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/p2m-ept.c	Fri Apr 27 20:28:37 2012 -0700
@@ -274,10 +274,13 @@ static int ept_next_level(struct p2m_dom
 /*
  * ept_set_entry() computes 'need_modify_vtd_table' for itself,
  * by observing whether any gfn->mfn translations are modified.
+ * If sync_deferred is not NULL, then the caller will take care of
+ * calling ept_sync_domain() in the cases where it can be deferred.
  */
 static int
 ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
-              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+              unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
+              bool_t *sync_deferred)
 {
     ept_entry_t *table, *ept_entry =3D NULL;
     unsigned long gfn_remainder =3D gfn;
@@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, un
     int needs_sync =3D 1;
     struct domain *d =3D p2m->domain;
     ept_entry_t old_entry =3D { .epte =3D 0 };
+    bool_t _sync_deferred =3D 0;

     /*
      * the caller must make sure:
@@ -309,6 +313,9 @@ ept_set_entry(struct p2m_domain *p2m, un
            (target =3D=3D 1 && hvm_hap_has_2mb(d)) ||
            (target =3D=3D 0));

+    if (sync_deferred)
+        *sync_deferred =3D 1;
+
     table =3D map_domain_page(ept_get_asr(d));

     for ( i =3D ept_get_wl(d); i > target; i-- )
@@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un

         /* No need to flush if the old entry wasn't valid */
         if ( !is_epte_present(ept_entry) )
+        {
             needs_sync =3D 0;
+            if ( sync_deferred )
+                *sync_deferred =3D 0;
+        }

         /* If we're replacing a non-leaf entry with a leaf entry
(1GiB or 2MiB),
          * the intermediate tables will be freed below after the ept flush
@@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un

         ASSERT(is_epte_superpage(ept_entry));

+        if ( sync_deferred )
+            _sync_deferred =3D 1;
+
         split_ept_entry =3D atomic_read_ept_entry(ept_entry);

         if ( !ept_split_super_page(p2m, &split_ept_entry, i, target) )
@@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un
 out:
     unmap_domain_page(table);

-    if ( needs_sync )
+    if ( needs_sync && !_sync_deferred )
         ept_sync_domain(p2m->domain);

     if ( rv && iommu_enabled && need_iommu(p2m->domain) &&
need_modify_vtd_table )
@@ -727,7 +741,8 @@ void ept_change_entry_emt_with_range(str
                     order =3D level * EPT_TABLE_ORDER;
                     if ( need_modify_ept_entry(p2m, gfn, mfn,
                           e.ipat, e.emt, e.sa_p2mt) )
-                        ept_set_entry(p2m, gfn, mfn, order,
e.sa_p2mt, e.access);
+                        ept_set_entry(p2m, gfn, mfn, order,
e.sa_p2mt, e.access,
+                                      NULL);
                     gfn +=3D trunk;
                     break;
                 }
@@ -737,7 +752,7 @@ void ept_change_entry_emt_with_range(str
         else /* gfn assigned with 4k */
         {
             if ( need_modify_ept_entry(p2m, gfn, mfn, e.ipat, e.emt,
e.sa_p2mt) )
-                ept_set_entry(p2m, gfn, mfn, order, e.sa_p2mt, e.access);
+                ept_set_entry(p2m, gfn, mfn, order, e.sa_p2mt, e.access, N=
ULL);
         }
     }
     p2m_unlock(p2m);
diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/p2m-pt.c	Fri Apr 27 20:28:37 2012 -0700
@@ -291,7 +291,8 @@ p2m_next_level(struct p2m_domain *p2m, m
 // Returns 0 on error (out of memory)
 static int
 p2m_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
-              unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
+              unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma,
+              bool_t *unused)
 {
     // XXX -- this might be able to be faster iff current->domain =3D=3D d
     mfn_t table_mfn =3D pagetable_get_mfn(p2m_get_pagetable(p2m));
diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/arch/x86/mm/p2m.c	Fri Apr 27 20:28:37 2012 -0700
@@ -227,7 +227,7 @@ int set_p2m_entry(struct p2m_domain *p2m
         else
             order =3D 0;

-        if ( !p2m->set_entry(p2m, gfn, mfn, order, p2mt, p2ma) )
+        if ( !p2m->set_entry(p2m, gfn, mfn, order, p2mt, p2ma, NULL) )
             rc =3D 0;
         gfn +=3D 1ul << order;
         if ( mfn_x(mfn) !=3D INVALID_MFN )
@@ -1199,14 +1199,14 @@ bool_t p2m_mem_access_check(unsigned lon

     if ( access_w && p2ma =3D=3D p2m_access_rx2rw )
     {
-        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rw, NULL);
         gfn_unlock(p2m, gfn, 0);
         return 1;
     }
     else if ( p2ma =3D=3D p2m_access_n2rwx )
     {
         ASSERT(access_w || access_r || access_x);
-        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rwx, NULL);
     }
     gfn_unlock(p2m, gfn, 0);

@@ -1228,7 +1228,8 @@ bool_t p2m_mem_access_check(unsigned lon
             {
                 /* A listener is not required, so clear the access
restrictions */
                 gfn_lock(p2m, gfn, 0);
-                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rwx);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
+                               p2m_access_rwx, NULL);
                 gfn_unlock(p2m, gfn, 0);
             }
             return 1;
@@ -1292,6 +1293,7 @@ int p2m_set_mem_access(struct domain *d,
     p2m_type_t t;
     mfn_t mfn;
     int rc =3D 0;
+    bool_t sync_deferred =3D 1;

     /* N.B. _not_ static: initializer depends on p2m->default_access */
     p2m_access_t memaccess[] =3D {
@@ -1324,12 +1326,17 @@ int p2m_set_mem_access(struct domain *d,
     for ( pfn =3D start_pfn; pfn < start_pfn + nr; pfn++ )
     {
         mfn =3D p2m->get_entry(p2m, pfn, &t, &_a, 0, NULL);
-        if ( p2m->set_entry(p2m, pfn, mfn, PAGE_ORDER_4K, t, a) =3D=3D 0 )
+        if ( p2m->set_entry(p2m, pfn, mfn, PAGE_ORDER_4K, t, a, &sync_defe=
rred)
+             =3D=3D 0 )
         {
             rc =3D -ENOMEM;
             break;
         }
     }
+
+    if ( sync_deferred )
+        ept_sync_domain(p2m->domain);
+
     p2m_unlock(p2m);
     return rc;
 }
diff -r 9dda0efd8ce1 -r 2c05bdb052ea xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Apr 27 17:57:55 2012 +0200
+++ b/xen/include/asm-x86/p2m.h	Fri Apr 27 20:28:37 2012 -0700
@@ -231,7 +231,8 @@ struct p2m_domain {
                                        unsigned long gfn,
                                        mfn_t mfn, unsigned int page_order,
                                        p2m_type_t p2mt,
-                                       p2m_access_t p2ma);
+                                       p2m_access_t p2ma,
+                                       bool_t *sync_deferred);
     mfn_t              (*get_entry   )(struct p2m_domain *p2m,
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,

changeset:   25258:5a0d60bb536b
user:        Aravindh Puthiyaparambil <aravindh@virtuata.com>
date:        Fri Apr 27 21:10:59 2012 -0700
summary:     mem_access: Add xc_hvm_mem_access_bulk() API

diff -r 2c05bdb052ea -r 5a0d60bb536b tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Fri Apr 27 20:28:37 2012 -0700
+++ b/tools/libxc/xc_misc.c	Fri Apr 27 21:10:59 2012 -0700
@@ -570,6 +570,57 @@ int xc_hvm_set_mem_access(
     return rc;
 }

+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t mem_access,
+    xen_pfn_t *arr, int *err, uint64_t nr)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_access_bulk, arg);
+    DECLARE_HYPERCALL_BOUNCE(arr, sizeof(xen_pfn_t) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(err, sizeof(int) * nr,
+                             XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    int rc;
+
+    arg =3D xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+    if ( arg =3D=3D NULL )
+    {
+        PERROR("Could not allocate memory for
xc_hvm_set_mem_access_bulk hypercall");
+        return -1;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, arr) ) {
+        PERROR("Could not bounce arr for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    if ( xc_hypercall_bounce_pre(xch, err) ) {
+        PERROR("Could not bounce err for xc_hvm_set_mem_access_bulk
hypercall");
+        rc =3D -1;
+        goto out;
+    }
+
+    arg->domid         =3D dom;
+    arg->hvmmem_access =3D mem_access;
+    arg->nr            =3D nr;
+    set_xen_guest_handle(arg->arr, arr);
+    set_xen_guest_handle(arg->err, err);
+
+    hypercall.op     =3D __HYPERVISOR_hvm_op;
+    hypercall.arg[0] =3D HVMOP_set_mem_access_bulk;
+    hypercall.arg[1] =3D HYPERCALL_BUFFER_AS_ARG(arg);
+
+    rc =3D do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, arg);
+    xc_hypercall_bounce_post(xch, arr);
+    xc_hypercall_bounce_post(xch, err);
+
+    return rc;
+}
+
 int xc_hvm_get_mem_access(
     xc_interface *xch, domid_t dom, uint64_t pfn, hvmmem_access_t* mem_acc=
ess)
 {
diff -r 2c05bdb052ea -r 5a0d60bb536b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Apr 27 20:28:37 2012 -0700
+++ b/tools/libxc/xenctrl.h	Fri Apr 27 21:10:59 2012 -0700
@@ -1568,6 +1568,17 @@ int xc_hvm_set_mem_access(
     xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
uint64_t first_pfn, uint64_t nr);

 /*
+ * Set the arry of pfns to a specific access.
+ * When a pfn cannot be set to the specified access, its respective field =
in
+ * @err is set to the corresponding errno value.
+ * Allowed types are HVMMEM_access_default, HVMMEM_access_n, any combinati=
on of
+ * HVM_access_ + (rwx), and HVM_access_rx2rw
+ */
+int xc_hvm_set_mem_access_bulk(
+    xc_interface *xch, domid_t dom, hvmmem_access_t memaccess,
+    xen_pfn_t *arr, int *err, uint64_t num);
+
+/*
  * Gets the mem access for the given page (returned in memacess on success)
  */
 int xc_hvm_get_mem_access(
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/arch/x86/hvm/hvm.c	Fri Apr 27 21:10:59 2012 -0700
@@ -4197,6 +4197,51 @@ long do_hvm_op(unsigned long op, XEN_GUE
         break;
     }

+    case HVMOP_set_mem_access_bulk:
+    {
+        struct xen_hvm_set_mem_access_bulk a;
+        struct domain *d;
+        xen_pfn_t *arr =3D 0;
+        int *err =3D 0;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc =3D rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        if ( rc !=3D 0 )
+            return rc;
+
+        rc =3D -EINVAL;
+
+        if ( !is_hvm_domain(d) )
+            goto param_fail9;
+
+        rc =3D -ENOMEM;
+        arr =3D xmalloc_array(xen_pfn_t, a.nr);
+        if (!arr)
+            goto param_fail9;
+
+        err =3D xmalloc_array(int, a.nr);
+        if (!err)
+            goto param_fail9;
+
+        if ( copy_from_guest(arr, a.arr, a.nr) )
+            goto param_fail9;
+
+        rc =3D p2m_set_access_bulk(d, arr, err, a.nr, a.hvmmem_access);
+
+        if ( copy_to_guest(a.err, err, a.nr) )
+            goto param_fail9;
+
+    param_fail9:
+        rcu_unlock_domain(d);
+        if (arr)
+            xfree(arr);
+        if (err)
+            xfree(err);
+        break;
+    }
+
     case HVMOP_get_mem_access:
     {
         struct xen_hvm_get_mem_access a;
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/arch/x86/mm/p2m.c	Fri Apr 27 21:10:59 2012 -0700
@@ -1341,6 +1341,61 @@ int p2m_set_mem_access(struct domain *d,
     return rc;
 }

+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access)
+{
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+    unsigned long pfn;
+    p2m_access_t a, _a;
+    p2m_type_t t;
+    p2m_access_t memaccess[] =3D {
+        p2m_access_n,
+        p2m_access_r,
+        p2m_access_w,
+        p2m_access_rw,
+        p2m_access_x,
+        p2m_access_rx,
+        p2m_access_wx,
+        p2m_access_rwx,
+        p2m_access_rx2rw,
+        p2m_access_n2rwx,
+        p2m->default_access,
+    };
+    mfn_t mfn;
+    int rc;
+    bool_t sync_deferred =3D 1;
+
+    if ( (unsigned) access >=3D HVMMEM_access_default )
+        return -EINVAL;
+
+    a =3D memaccess[access];
+
+    p2m_lock(p2m);
+
+    for ( pfn =3D 0; pfn < nr; pfn++ )
+    {
+        if ( arr[pfn] > domain_get_maximum_gpfn(d) )
+        {
+            err[pfn] =3D -EINVAL;
+            continue;
+        }
+
+        mfn =3D p2m->get_entry(p2m, arr[pfn], &t, &_a, 0, NULL);
+        rc =3D p2m->set_entry(p2m, arr[pfn], mfn, PAGE_ORDER_4K, t, a,
+                            &sync_deferred);
+        if ( rc =3D=3D 0 )
+            err[pfn] =3D -ENOMEM;
+    }
+
+    if ( sync_deferred )
+        ept_sync_domain(p2m->domain);
+
+    p2m_unlock(p2m);
+
+    return 0;
+}
+
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/include/asm-x86/p2m.h	Fri Apr 27 21:10:59 2012 -0700
@@ -574,6 +574,11 @@ void p2m_mem_access_resume(struct domain
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn,
                        uint32_t nr, hvmmem_access_t access);

+/* Set access type for an array of pfns. set_mem_access success or failure=
 is
+ * returned in the err array. */
+int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr, int *err,
+                        uint64_t nr, hvmmem_access_t access);
+
 /* Get access type for a pfn
  * If pfn =3D=3D -1ul, gets the default access type */
 int p2m_get_mem_access(struct domain *d, unsigned long pfn,
@@ -589,7 +594,11 @@ static inline int p2m_set_mem_access(str
                                      unsigned long start_pfn,
                                      uint32_t nr, hvmmem_access_t access)
 { return -EINVAL; }
-static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
+static inline int p2m_set_access_bulk(struct domain *d, xen_pfn_t *arr,
+                                      int *err, uint64_t nr,
+                                      hvmmem_access_t access)
+{ return -EINVAL; }
+static inline int p2m_get_mem_access(struct domain *d, unsigned long pfn,
                                      hvmmem_access_t *access)
 { return -EINVAL; }
 #endif
diff -r 2c05bdb052ea -r 5a0d60bb536b xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h	Fri Apr 27 20:28:37 2012 -0700
+++ b/xen/include/public/hvm/hvm_op.h	Fri Apr 27 21:10:59 2012 -0700
@@ -261,4 +261,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_inject_m

 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */

+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define HVMOP_set_mem_access_bulk      17
+/* Notify that a array of pfns is to have specific access types */
+struct xen_hvm_set_mem_access_bulk {
+    /* Domain to be updated. */
+    domid_t domid;
+    /* Memory type */
+    uint16_t hvmmem_access; /* hvm_access_t */
+    /* Array of pfns */
+    XEN_GUEST_HANDLE_64(xen_pfn_t) arr;
+    XEN_GUEST_HANDLE_64(int) err ;
+    /* Number of entries */
+    uint64_t nr;
+};
+typedef struct xen_hvm_set_mem_access_bulk xen_hvm_set_mem_access_bulk_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_mem_access_bulk_t);
+#endif
+
 #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 05:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 05:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0El-0007rF-EY; Sat, 28 Apr 2012 05:30:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SO0Ej-0007rA-67
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 05:30:25 +0000
Received: from [85.158.138.51:6664] by server-2.bemta-3.messagelabs.com id
	8E/BA-09269-0708B9F4; Sat, 28 Apr 2012 05:30:24 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335591022!20153509!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24059 invoked from network); 28 Apr 2012 05:30:23 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 05:30:23 -0000
Received: by qcsc20 with SMTP id c20so941461qcs.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=E4IiXMEHIcoA4fpk/GW+3CEBeld5X4zLHQ+Xjk4usmg=;
	b=d2UrAbAmhk+5yEDMAjazqmJeQk1Bxjmj3J3/6YXl4NvxJj77lteuwdrT1wTVFUJWC0
	SjIQP5UmD6qWeUqFUzVRfsTzCk5Xc5eZJDOLb5pVkEvQKOn32MRTS+av+2/S65Zusg/J
	iYg3Kj3lrRPVIhR02C5Dny3WxjC48as9nsN+z+UBDarn+rI8BQpCQGOXfkR8b+NePL9x
	c8IP2d3ywNFlcqXDur9FVIXsXzw8OF3tKgoNoph09j6cMu7fqgtRMqhHB0ouXZ1V/+1g
	g/xDoH7K8340L4kUgiSPKVpQKraVZWjktSRe/AAUh0KBEFKfKbmxFPagI3bGu3YtY7vx
	7gdg==
MIME-Version: 1.0
Received: by 10.224.174.206 with SMTP id u14mr11150153qaz.90.1335591021894;
	Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Apr 2012 22:30:21 -0700
Message-ID: <CAGU+autW+k_3MQGkP7f4MRMV+TUGnFbhuKYkAPaaThGGUC7Sqg@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1536861568804058914=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1536861568804058914==
Content-Type: multipart/alternative; boundary=485b397dd69d6cda3904beb68438

--485b397dd69d6cda3904beb68438
Content-Type: text/plain; charset=ISO-8859-1

On Apr 12, 2012 9:32 AM, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
>
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>

I know this comes late in the day but if possible please consider
25218:cf2de273869f, 25255:fd04ba0aa4fa and 25256:9dda0efd8ce1 for backport
to 4.1.3.

Thanks,
AP

--485b397dd69d6cda3904beb68438
Content-Type: text/html; charset=ISO-8859-1

<p><br>
On Apr 12, 2012 9:32 AM, &quot;Ian Campbell&quot; &lt;<a href="mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; The time has come for another round of stable releases.<br>
&gt;<br>
&gt; Please send (or resend) any outstanding backport requests for 4.0.4 and<br>
&gt; 4.1.3 before Friday 20 April.<br>
&gt;<br>
&gt; Note that 4.0.4 will likely be the last release in the 4.0.x branch.<br>
&gt;</p>
<p>I know this comes late in the day but if possible please consider 25218:cf2de273869f, 25255:fd04ba0aa4fa and 25256:9dda0efd8ce1 for backport to 4.1.3.</p>
<p>Thanks,<br>
AP<br>
</p>

--485b397dd69d6cda3904beb68438--


--===============1536861568804058914==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1536861568804058914==--


From xen-devel-bounces@lists.xen.org Sat Apr 28 05:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 05:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0El-0007rF-EY; Sat, 28 Apr 2012 05:30:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <apxeng@gmail.com>) id 1SO0Ej-0007rA-67
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 05:30:25 +0000
Received: from [85.158.138.51:6664] by server-2.bemta-3.messagelabs.com id
	8E/BA-09269-0708B9F4; Sat, 28 Apr 2012 05:30:24 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335591022!20153509!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24059 invoked from network); 28 Apr 2012 05:30:23 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 05:30:23 -0000
Received: by qcsc20 with SMTP id c20so941461qcs.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=E4IiXMEHIcoA4fpk/GW+3CEBeld5X4zLHQ+Xjk4usmg=;
	b=d2UrAbAmhk+5yEDMAjazqmJeQk1Bxjmj3J3/6YXl4NvxJj77lteuwdrT1wTVFUJWC0
	SjIQP5UmD6qWeUqFUzVRfsTzCk5Xc5eZJDOLb5pVkEvQKOn32MRTS+av+2/S65Zusg/J
	iYg3Kj3lrRPVIhR02C5Dny3WxjC48as9nsN+z+UBDarn+rI8BQpCQGOXfkR8b+NePL9x
	c8IP2d3ywNFlcqXDur9FVIXsXzw8OF3tKgoNoph09j6cMu7fqgtRMqhHB0ouXZ1V/+1g
	g/xDoH7K8340L4kUgiSPKVpQKraVZWjktSRe/AAUh0KBEFKfKbmxFPagI3bGu3YtY7vx
	7gdg==
MIME-Version: 1.0
Received: by 10.224.174.206 with SMTP id u14mr11150153qaz.90.1335591021894;
	Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
Received: by 10.229.163.204 with HTTP; Fri, 27 Apr 2012 22:30:21 -0700 (PDT)
In-Reply-To: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
References: <1334248235.16387.134.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Apr 2012 22:30:21 -0700
Message-ID: <CAGU+autW+k_3MQGkP7f4MRMV+TUGnFbhuKYkAPaaThGGUC7Sqg@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable
	releases
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1536861568804058914=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1536861568804058914==
Content-Type: multipart/alternative; boundary=485b397dd69d6cda3904beb68438

--485b397dd69d6cda3904beb68438
Content-Type: text/plain; charset=ISO-8859-1

On Apr 12, 2012 9:32 AM, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
>
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>

I know this comes late in the day but if possible please consider
25218:cf2de273869f, 25255:fd04ba0aa4fa and 25256:9dda0efd8ce1 for backport
to 4.1.3.

Thanks,
AP

--485b397dd69d6cda3904beb68438
Content-Type: text/html; charset=ISO-8859-1

<p><br>
On Apr 12, 2012 9:32 AM, &quot;Ian Campbell&quot; &lt;<a href="mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; The time has come for another round of stable releases.<br>
&gt;<br>
&gt; Please send (or resend) any outstanding backport requests for 4.0.4 and<br>
&gt; 4.1.3 before Friday 20 April.<br>
&gt;<br>
&gt; Note that 4.0.4 will likely be the last release in the 4.0.x branch.<br>
&gt;</p>
<p>I know this comes late in the day but if possible please consider 25218:cf2de273869f, 25255:fd04ba0aa4fa and 25256:9dda0efd8ce1 for backport to 4.1.3.</p>
<p>Thanks,<br>
AP<br>
</p>

--485b397dd69d6cda3904beb68438--


--===============1536861568804058914==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1536861568804058914==--


From xen-devel-bounces@lists.xen.org Sat Apr 28 05:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 05:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0T1-000839-Rt; Sat, 28 Apr 2012 05:45:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SO0T0-000834-N2
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 05:45:10 +0000
Received: from [85.158.138.51:46533] by server-9.bemta-3.messagelabs.com id
	F2/0C-26691-5E38B9F4; Sat, 28 Apr 2012 05:45:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335591908!20154439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjgzMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12883 invoked from network); 28 Apr 2012 05:45:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 05:45:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,494,1330905600"; d="scan'208";a="12187050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 05:45:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 28 Apr 2012 06:45:08 +0100
Message-ID: <1335591907.4881.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Sat, 28 Apr 2012 06:45:07 +0100
In-Reply-To: <CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
	<1335550792.4881.76.camel@dagon.hellion.org.uk>
	<CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-28 at 00:06 +0100, Sandi Romih wrote:
> 
> 
>         
>         
>         You don't appear to have setup any bridges on your host.
>         
>         http://wiki.xen.org/wiki/HostConfiguration/Networking should
>         lead you
>         through the necessary steps.
>         
>         Ian.
>         
> 
> 
> Ian,
> 
> 
> Thanks for that. It looks like it has sorted out the issue.

Great!

> I am surprised that I did NOT have to setup my networking in this
> manner when I first installed openindiana. I just configured the vm
> with vif = bridge=eth0, and it worked.

FWIW this is a difference between xm and xl, perhaps you used xm the
first time?

> Thanks for your time and patience.

No problem!

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 05:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 05:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0T1-000839-Rt; Sat, 28 Apr 2012 05:45:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SO0T0-000834-N2
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 05:45:10 +0000
Received: from [85.158.138.51:46533] by server-9.bemta-3.messagelabs.com id
	F2/0C-26691-5E38B9F4; Sat, 28 Apr 2012 05:45:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1335591908!20154439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjgzMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12883 invoked from network); 28 Apr 2012 05:45:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 05:45:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,494,1330905600"; d="scan'208";a="12187050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 05:45:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 28 Apr 2012 06:45:08 +0100
Message-ID: <1335591907.4881.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Sat, 28 Apr 2012 06:45:07 +0100
In-Reply-To: <CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
	<1335550792.4881.76.camel@dagon.hellion.org.uk>
	<CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-28 at 00:06 +0100, Sandi Romih wrote:
> 
> 
>         
>         
>         You don't appear to have setup any bridges on your host.
>         
>         http://wiki.xen.org/wiki/HostConfiguration/Networking should
>         lead you
>         through the necessary steps.
>         
>         Ian.
>         
> 
> 
> Ian,
> 
> 
> Thanks for that. It looks like it has sorted out the issue.

Great!

> I am surprised that I did NOT have to setup my networking in this
> manner when I first installed openindiana. I just configured the vm
> with vif = bridge=eth0, and it worked.

FWIW this is a difference between xm and xl, perhaps you used xm the
first time?

> Thanks for your time and patience.

No problem!

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 05:46:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 05:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0TM-00084E-DA; Sat, 28 Apr 2012 05:45:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SO0TL-000844-78
	for Xen-devel@lists.xensource.com; Sat, 28 Apr 2012 05:45:31 +0000
Received: from [85.158.143.99:34784] by server-1.bemta-4.messagelabs.com id
	F0/64-20925-AF38B9F4; Sat, 28 Apr 2012 05:45:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335591929!19265459!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31171 invoked from network); 28 Apr 2012 05:45:29 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 05:45:29 -0000
Received: by wibhj13 with SMTP id hj13so1060567wib.6
	for <Xen-devel@lists.xensource.com>;
	Fri, 27 Apr 2012 22:45:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=40S2Jmcd/C/yIm9K3qrdjKQz3VWqC+CIk4I5x7kMmWM=;
	b=afCmiUd0W3iVKD2k7v61a1lraPL+R1ZPoGguYCcBO3EFuaYgRXSa/WA5Uq+0kJm2Y9
	0ngeqG7U9vsWovEjZimgFm5Gs4EZhtqlIq/Np2P6w1Wexx3hYh438NHLhFe01uRAQKtf
	cmHxF8KGNIrDUMeggFGTueBZTfX4dYgOYRdEupG/ESi6sYJZJPlPqwL4dBetndF0DNeG
	j0okecpmESFj8ViY6BdnB3Nbv2sJ1sc8OR/PY4z6iM590Zcd5ZmmkhRB/t5LPavLMA56
	Wk5g2WLFB0j266SoGt+kn6C++2HHOd1qejm1qhYs1QzBclrsFk4FgpC8NPTuDvGL17U+
	Ix6A==
Received: by 10.216.135.196 with SMTP id u46mr8261062wei.114.1335591928574;
	Fri, 27 Apr 2012 22:45:28 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id u9sm9765512wix.0.2012.04.27.22.45.24
	(version=SSLv3 cipher=OTHER); Fri, 27 Apr 2012 22:45:28 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 28 Apr 2012 06:45:20 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <CBC14280.31BFE%keir.xen@gmail.com>
Thread-Topic: [help]: VPID tagged TLBs question.
Thread-Index: Ac0lAhjPQFohlqlX6UKIAejyrNDtgQ==
In-Reply-To: <20120427182501.197681ff@mantra.us.oracle.com>
Mime-version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/04/2012 02:25, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> On Thu, 26 Apr 2012 08:23:29 +0100
> Keir Fraser <keir.xen@gmail.com> wrote:
> 
>> On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
>> 
>>> However, I don't understand the use of hvm_asid_flush_core which
>>> it appears will cause all HVM vcpu's to get new vpid/asid, hence,
>>> discard all previously used VPID tagged TLBs. In particular,
>>> consider a PV guest:
>>> 
>>> write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs ->
>>> hvm_asid_flush_core().
>>> 
>>> Since the PV guest is only using VPID 0 tagged TLBs, why do we need
>>> to flush all TLBs for all HVM guests?
>> 
>> It's just being conservative, as callers of write_cr3 may assume that
>> the TLB is entirely flushed, for all guests.
> 
> Well, for write_cr3 path at least, we just need to invalidate all TLBs
> in the local pcpu. So it seems for this path we could just do
> invvpid with type 2, ie, invalidate all vpids except 0. Prob also need
> to do 'invept 2'. what do you think, worth it?

Try lashing it up and measure it. :-) My guess would be that it is not worth
it.

Our current algorithm minimises INVVPID instructions, just eats through the
VPID space instead. Depending on the cost of INVVPID, versus the cost of
having never-used-again stale tagged entries clogging up the TLB, our
algorithm may be a bit better or worse than one that more aggressively uses
INVVPID. My guess (which is only a guess!) is that the difference will be
totally insignificant and unmeasurable.

 -- Keir

> thanks,
> Mukesh
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 05:46:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 05:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0TM-00084E-DA; Sat, 28 Apr 2012 05:45:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SO0TL-000844-78
	for Xen-devel@lists.xensource.com; Sat, 28 Apr 2012 05:45:31 +0000
Received: from [85.158.143.99:34784] by server-1.bemta-4.messagelabs.com id
	F0/64-20925-AF38B9F4; Sat, 28 Apr 2012 05:45:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1335591929!19265459!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31171 invoked from network); 28 Apr 2012 05:45:29 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 05:45:29 -0000
Received: by wibhj13 with SMTP id hj13so1060567wib.6
	for <Xen-devel@lists.xensource.com>;
	Fri, 27 Apr 2012 22:45:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=40S2Jmcd/C/yIm9K3qrdjKQz3VWqC+CIk4I5x7kMmWM=;
	b=afCmiUd0W3iVKD2k7v61a1lraPL+R1ZPoGguYCcBO3EFuaYgRXSa/WA5Uq+0kJm2Y9
	0ngeqG7U9vsWovEjZimgFm5Gs4EZhtqlIq/Np2P6w1Wexx3hYh438NHLhFe01uRAQKtf
	cmHxF8KGNIrDUMeggFGTueBZTfX4dYgOYRdEupG/ESi6sYJZJPlPqwL4dBetndF0DNeG
	j0okecpmESFj8ViY6BdnB3Nbv2sJ1sc8OR/PY4z6iM590Zcd5ZmmkhRB/t5LPavLMA56
	Wk5g2WLFB0j266SoGt+kn6C++2HHOd1qejm1qhYs1QzBclrsFk4FgpC8NPTuDvGL17U+
	Ix6A==
Received: by 10.216.135.196 with SMTP id u46mr8261062wei.114.1335591928574;
	Fri, 27 Apr 2012 22:45:28 -0700 (PDT)
Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com.
	[217.43.89.104])
	by mx.google.com with ESMTPS id u9sm9765512wix.0.2012.04.27.22.45.24
	(version=SSLv3 cipher=OTHER); Fri, 27 Apr 2012 22:45:28 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 28 Apr 2012 06:45:20 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <CBC14280.31BFE%keir.xen@gmail.com>
Thread-Topic: [help]: VPID tagged TLBs question.
Thread-Index: Ac0lAhjPQFohlqlX6UKIAejyrNDtgQ==
In-Reply-To: <20120427182501.197681ff@mantra.us.oracle.com>
Mime-version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [help]: VPID tagged TLBs question.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/04/2012 02:25, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> On Thu, 26 Apr 2012 08:23:29 +0100
> Keir Fraser <keir.xen@gmail.com> wrote:
> 
>> On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
>> 
>>> However, I don't understand the use of hvm_asid_flush_core which
>>> it appears will cause all HVM vcpu's to get new vpid/asid, hence,
>>> discard all previously used VPID tagged TLBs. In particular,
>>> consider a PV guest:
>>> 
>>> write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs ->
>>> hvm_asid_flush_core().
>>> 
>>> Since the PV guest is only using VPID 0 tagged TLBs, why do we need
>>> to flush all TLBs for all HVM guests?
>> 
>> It's just being conservative, as callers of write_cr3 may assume that
>> the TLB is entirely flushed, for all guests.
> 
> Well, for write_cr3 path at least, we just need to invalidate all TLBs
> in the local pcpu. So it seems for this path we could just do
> invvpid with type 2, ie, invalidate all vpids except 0. Prob also need
> to do 'invept 2'. what do you think, worth it?

Try lashing it up and measure it. :-) My guess would be that it is not worth
it.

Our current algorithm minimises INVVPID instructions, just eats through the
VPID space instead. Depending on the cost of INVVPID, versus the cost of
having never-used-again stale tagged entries clogging up the TLB, our
algorithm may be a bit better or worse than one that more aggressively uses
INVVPID. My guess (which is only a guess!) is that the difference will be
totally insignificant and unmeasurable.

 -- Keir

> thanks,
> Mukesh
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 06:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 06:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0kF-0008ST-41; Sat, 28 Apr 2012 06:02:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SO0kD-0008SO-Ip
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 06:02:57 +0000
Received: from [85.158.143.35:7296] by server-2.bemta-4.messagelabs.com id
	F9/02-17550-0188B9F4; Sat, 28 Apr 2012 06:02:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335592975!11933013!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjgzMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14882 invoked from network); 28 Apr 2012 06:02:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 06:02:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,494,1330905600"; d="scan'208";a="12187090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 06:01:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Apr 2012 07:01:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SO0iy-00075g-W4;
	Sat, 28 Apr 2012 06:01:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SO0iy-0001lx-VK;
	Sat, 28 Apr 2012 07:01:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Apr 2012 07:01:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12761: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12761 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12761/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12760

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  9dda0efd8ce1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 06:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 06:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0kF-0008ST-41; Sat, 28 Apr 2012 06:02:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SO0kD-0008SO-Ip
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 06:02:57 +0000
Received: from [85.158.143.35:7296] by server-2.bemta-4.messagelabs.com id
	F9/02-17550-0188B9F4; Sat, 28 Apr 2012 06:02:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335592975!11933013!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjgzMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14882 invoked from network); 28 Apr 2012 06:02:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 06:02:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,494,1330905600"; d="scan'208";a="12187090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 06:01:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Apr 2012 07:01:41 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SO0iy-00075g-W4;
	Sat, 28 Apr 2012 06:01:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SO0iy-0001lx-VK;
	Sat, 28 Apr 2012 07:01:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Apr 2012 07:01:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12761: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12761 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12761/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12760

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  9dda0efd8ce1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 06:12:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 06:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0t7-0000Bo-4N; Sat, 28 Apr 2012 06:12:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SO0t5-0000Bj-N7
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 06:12:07 +0000
Received: from [85.158.139.83:21311] by server-5.bemta-5.messagelabs.com id
	F2/62-13566-63A8B9F4; Sat, 28 Apr 2012 06:12:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335593526!22011023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjgzMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7306 invoked from network); 28 Apr 2012 06:12:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 06:12:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,494,1330905600"; d="scan'208";a="12187155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 06:12:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 28 Apr 2012 07:12:05 +0100
Message-ID: <1335593525.4881.79.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Sat, 28 Apr 2012 07:12:05 +0100
In-Reply-To: <CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
	<1335550792.4881.76.camel@dagon.hellion.org.uk>
	<CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-28 at 00:06 +0100, Sandi Romih wrote:
> I had a feeling it was something silly... 

By the way I updated a few pages on the wiki (e.g.
http://wiki.xen.org/wiki/Getting_Started) to make the need to do this
more obvious, since the HostConfiguration/Networking was not clearly
linked to from the main landing pages.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 06:12:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 06:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO0t7-0000Bo-4N; Sat, 28 Apr 2012 06:12:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SO0t5-0000Bj-N7
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 06:12:07 +0000
Received: from [85.158.139.83:21311] by server-5.bemta-5.messagelabs.com id
	F2/62-13566-63A8B9F4; Sat, 28 Apr 2012 06:12:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1335593526!22011023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjgzMw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7306 invoked from network); 28 Apr 2012 06:12:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 06:12:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,494,1330905600"; d="scan'208";a="12187155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 06:12:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 28 Apr 2012 07:12:05 +0100
Message-ID: <1335593525.4881.79.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Sat, 28 Apr 2012 07:12:05 +0100
In-Reply-To: <CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
References: <CAFoWEVMTBhBO1hgW0qeYKLeLwCKrigd5a0VFKT7S_5qi7KK9UQ@mail.gmail.com>
	<1335170516.30700.12.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1204231226500.26786@kaball-desktop>
	<1335180628.4347.1.camel@zakaz.uk.xensource.com>
	<CAFoWEVNEYDN+C_bvdRihuNSaBNnAYfXmjvErdZLf7QfQKfDLyA@mail.gmail.com>
	<1335371921.28015.56.camel@zakaz.uk.xensource.com>
	<CAFoWEVOkg5q9iyKcxM_LAkBgiBC_xCiVLqfFDGAtt2HzuWr9Rw@mail.gmail.com>
	<1335425428.4881.52.camel@dagon.hellion.org.uk>
	<CAFoWEVNPqez_eR2jLOu0DtbH+-qDsWJyuzfxpC1QMzgzLqQwbQ@mail.gmail.com>
	<CAFoWEVOyKn2Rq42qOX19W4YzwXSz+vpXqfOB++C=iFY42SLaBw@mail.gmail.com>
	<1335550792.4881.76.camel@dagon.hellion.org.uk>
	<CAFoWEVPa39pgWs8FyOoMOin7x5cNo3hjQKj-8b-od5xO71FLug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Failed to run bootloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-04-28 at 00:06 +0100, Sandi Romih wrote:
> I had a feeling it was something silly... 

By the way I updated a few pages on the wiki (e.g.
http://wiki.xen.org/wiki/Getting_Started) to make the need to do this
more obvious, since the HostConfiguration/Networking was not clearly
linked to from the main landing pages.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 12:07:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 12:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO6Qg-0002Gh-VA; Sat, 28 Apr 2012 12:07:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1SO6Qf-0002GU-HA
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 12:07:09 +0000
Received: from [193.109.254.147:13779] by server-3.bemta-14.messagelabs.com id
	01/61-23274-C6DDB9F4; Sat, 28 Apr 2012 12:07:08 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335614827!4302836!1
X-Originating-IP: [77.238.189.195]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24330 invoked from network); 28 Apr 2012 12:07:08 -0000
Received: from nm13-vm0.bullet.mail.ird.yahoo.com (HELO
	nm13-vm0.bullet.mail.ird.yahoo.com) (77.238.189.195)
	by server-7.tower-27.messagelabs.com with SMTP;
	28 Apr 2012 12:07:08 -0000
Received: from [77.238.189.232] by nm13.bullet.mail.ird.yahoo.com with NNFMP;
	28 Apr 2012 12:07:07 -0000
Received: from [212.82.108.238] by tm13.bullet.mail.ird.yahoo.com with NNFMP;
	28 Apr 2012 12:07:07 -0000
Received: from [127.0.0.1] by omp1003.mail.ird.yahoo.com with NNFMP;
	28 Apr 2012 12:07:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 148512.95231.bm@omp1003.mail.ird.yahoo.com
Received: (qmail 82015 invoked by uid 60001); 28 Apr 2012 12:07:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1335614826; bh=LplVYO1U+JnGou9E+1XmVXVSTHq6UyOu5lhhXE0AFVw=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=tp/TxWSsWFnQ4vMBE49MI1SZcYARFif4Bhk+5E7JAj6p9dHmiKZ4r05rXhGnR+uGqL7lXIwMuT/BijPy9pm0WFcY58gF2ojqAq8CX6rz8CBCLBMwMdNHwf7hZxa5xmAAHl6d71k8d4I1ArvLI/AERbL9WLWaVzQROJK4gSi9S5E=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=n9asjdC5EQPviTZGgXDbbOA/Q5m4mV1JIkV2cRDY8nidokQBm8yuAbnsqWNeb5+ZsH+K9PSJAVcfGAvVvQ+TX+rQgeIoj9bUlPQJ81zHTHQwNhT7T0IbltVXo636cZ2QcYOXYXB/IiPfOQz9NoLlvWrlHmf+5D/BrpQZ5GpCBr4=;
X-YMail-OSG: e8_n.coVM1nPZ4u5chrp.G7yU_D0bTs9pwCb8GVNCPx.c3L
	5AJ2oPrSC1P5sSXUxsKVdkl0efa5eNWLW3SCXPe6_9Ydtv3lrwsYIaSrSdSI
	q.TVBaCCaN23wLiJUI0gHHpl0Syhd7H4yBX7UL_hvJQk5KCnI4VjQaMX.Fic
	2dKyKq2Fa2dLZUO4cCqPSmZ82B.8Wb1XTa9oXXHyqP6cjnxgQZzp.KEuPYnO
	hC6m6cOawx24RaKcCaNcrhS1JAaXq8QvFXZ5N_cR..PC_nKyTOWHdisJ3ehP
	gBqieHtsww5iHE.U6CQfleOVw.CenRlwNa0a7V5Nh3IEpYEyF04EfZOkhzlN
	ABe8Uhc2Co5wPKKw5ExcNpS0gahWx8fcwf138wsUEy1OM970Xo2PzwaX8n6k
	2b0PD2JrCgqUo3OFucpuNu_wBhVw9mjJaL1C0v_g-
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 28 Apr 2012 13:07:06 BST
X-Mailer: YahooMailWebService/0.8.117.340979
Message-ID: <1335614826.76812.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 28 Apr 2012 13:07:06 +0100 (BST)
From: David TECHER <davidtecher@yahoo.fr>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Xen VGA PassThrough NVIDIA: include pci-stub case for
	changeset 25240
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6223901398864008297=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6223901398864008297==
Content-Type: multipart/alternative; boundary="62747910-54864027-1335614826=:76812"

--62747910-54864027-1335614826=:76812
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0AFor concerned persons like me that compil Xen with PassThrough NVI=
DIA, modifications introduced for changeset 25240 are limited (for the mome=
nt) for pciback.=0A=0AI am used to biding device using pci-stub (device : V=
ideo Card).=0A=0ACommenting out modifications introduced for this changeset=
 is not a good choice (I approve!). This is the only fix I found - since I =
am not a Xen expert - to be able to use NVIDIA patches for revision >=3D 25=
240=0A=0AMay it be possible to include case for devices with pci-stub usage=
?=0A=0A-=0A667 /* 668 static int libxl_pcidev_assignable(libxl_ctx *ctx, li=
bxl_device_pci *pcidev) 669 { 670     libxl_device_pci *pcidevs; 671     in=
t num, i; 672  673     pcidevs =3D libxl_device_pci_list_assignable(ctx, &n=
um); 674     for (i =3D 0; i < num; i++) { 675         if (pcidevs[i].domai=
n =3D=3D pcidev->domain && 676             pcidevs[i].bus =3D=3D pcidev->bu=
s && 677             pcidevs[i].dev =3D=3D pcidev->dev && 678             p=
cidevs[i].func =3D=3D pcidev->func) 679         { 680             return 1;=
 681         } 682     } 683     return 0; 684 } 685 */ 686 int libxl__devi=
ce_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int sta=
rting) 687 { 688     libxl_ctx *ctx =3D libxl__gc_owner(gc); 689     unsign=
ed int orig_vdev, pfunc_mask; 690     libxl_device_pci *assigned; 691     i=
nt num_assigned, i, rc; 692     int stubdomid =3D 0; 693  694     rc =3D li=
bxl__device_pci_setdefault(gc, pcidev); 695     if (rc) goto out; 696  697 =
/*    if
 (!libxl_pcidev_assignable(ctx, pcidev)) { 698         LIBXL__LOG(ctx, LIBX=
L__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable", 699              =
      pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func); 700         =
rc =3D ERROR_FAIL; 701         goto out; 702     } 703 */=0A--Kind regards=
=0A
--62747910-54864027-1335614826=:76812
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div>Hi,</div><div><b=
r></div><div>For concerned persons like me that compil Xen with PassThrough=
 NVIDIA, modifications introduced for changeset 25240 are limited (for the =
moment) for pciback.</div><div><br></div><div>I am used to biding device us=
ing pci-stub (device : Video Card).</div><div><br></div>=0A<div>Commenting =
out modifications introduced for this changeset is not a good choice (I app=
rove!). This is the only fix I found - since I am not a Xen expert - to be =
able to use NVIDIA patches for revision &gt;=3D 25240<br></div><br>May it b=
e possible to include case for devices with pci-stub usage?<div><br></div><=
div>-</div><pre> 667 /*=0A 668 static int libxl_pcidev_assignable(libxl_ctx=
 *ctx, libxl_device_pci *pcidev)=0A 669 {=0A 670     libxl_device_pci *pcid=
evs;=0A 671     int num, i;=0A 672 =0A 673     pcidevs =3D libxl_device_pci=
_list_assignable(ctx, &amp;num);=0A 674     for (i =3D 0; i &lt; num; i++) =
{=0A 675         if (pcidevs[i].domain =3D=3D pcidev-&gt;domain &amp;&amp;=
=0A 676             pcidevs[i].bus =3D=3D pcidev-&gt;bus &amp;&amp;=0A 677 =
            pcidevs[i].dev =3D=3D pcidev-&gt;dev &amp;&amp;=0A 678         =
    pcidevs[i].func =3D=3D pcidev-&gt;func)=0A 679         {=0A 680        =
     return 1;=0A 681         }=0A 682     }=0A 683     return 0;=0A 684 }=
=0A 685 */=0A 686 int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, =
libxl_device_pci *pcidev, int starting)=0A 687 {=0A 688     libxl_ctx *ctx =
=3D libxl__gc_owner(gc);=0A 689     unsigned int orig_vdev, pfunc_mask;=0A =
690     libxl_device_pci *assigned;=0A 691     int num_assigned, i, rc;=0A =
692     int stubdomid =3D 0;=0A 693 =0A 694     rc =3D libxl__device_pci_se=
tdefault(gc, pcidev);=0A 695     if (rc) goto out;=0A 696 =0A 697 /*    if =
(!libxl_pcidev_assignable(ctx, pcidev)) {=0A 698         LIBXL__LOG(ctx, LI=
BXL__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable",=0A 699         =
           pcidev-&gt;domain, pcidev-&gt;bus, pcidev-&gt;dev, pcidev-&gt;fu=
nc);=0A 700         rc =3D ERROR_FAIL;=0A 701         goto out;=0A 702     =
}=0A 703 */</pre><div>--Kind regards</div></div></body></html>
--62747910-54864027-1335614826=:76812--


--===============6223901398864008297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6223901398864008297==--


From xen-devel-bounces@lists.xen.org Sat Apr 28 12:07:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 12:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO6Qg-0002Gh-VA; Sat, 28 Apr 2012 12:07:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1SO6Qf-0002GU-HA
	for xen-devel@lists.xen.org; Sat, 28 Apr 2012 12:07:09 +0000
Received: from [193.109.254.147:13779] by server-3.bemta-14.messagelabs.com id
	01/61-23274-C6DDB9F4; Sat, 28 Apr 2012 12:07:08 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335614827!4302836!1
X-Originating-IP: [77.238.189.195]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24330 invoked from network); 28 Apr 2012 12:07:08 -0000
Received: from nm13-vm0.bullet.mail.ird.yahoo.com (HELO
	nm13-vm0.bullet.mail.ird.yahoo.com) (77.238.189.195)
	by server-7.tower-27.messagelabs.com with SMTP;
	28 Apr 2012 12:07:08 -0000
Received: from [77.238.189.232] by nm13.bullet.mail.ird.yahoo.com with NNFMP;
	28 Apr 2012 12:07:07 -0000
Received: from [212.82.108.238] by tm13.bullet.mail.ird.yahoo.com with NNFMP;
	28 Apr 2012 12:07:07 -0000
Received: from [127.0.0.1] by omp1003.mail.ird.yahoo.com with NNFMP;
	28 Apr 2012 12:07:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 148512.95231.bm@omp1003.mail.ird.yahoo.com
Received: (qmail 82015 invoked by uid 60001); 28 Apr 2012 12:07:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1335614826; bh=LplVYO1U+JnGou9E+1XmVXVSTHq6UyOu5lhhXE0AFVw=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=tp/TxWSsWFnQ4vMBE49MI1SZcYARFif4Bhk+5E7JAj6p9dHmiKZ4r05rXhGnR+uGqL7lXIwMuT/BijPy9pm0WFcY58gF2ojqAq8CX6rz8CBCLBMwMdNHwf7hZxa5xmAAHl6d71k8d4I1ArvLI/AERbL9WLWaVzQROJK4gSi9S5E=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=n9asjdC5EQPviTZGgXDbbOA/Q5m4mV1JIkV2cRDY8nidokQBm8yuAbnsqWNeb5+ZsH+K9PSJAVcfGAvVvQ+TX+rQgeIoj9bUlPQJ81zHTHQwNhT7T0IbltVXo636cZ2QcYOXYXB/IiPfOQz9NoLlvWrlHmf+5D/BrpQZ5GpCBr4=;
X-YMail-OSG: e8_n.coVM1nPZ4u5chrp.G7yU_D0bTs9pwCb8GVNCPx.c3L
	5AJ2oPrSC1P5sSXUxsKVdkl0efa5eNWLW3SCXPe6_9Ydtv3lrwsYIaSrSdSI
	q.TVBaCCaN23wLiJUI0gHHpl0Syhd7H4yBX7UL_hvJQk5KCnI4VjQaMX.Fic
	2dKyKq2Fa2dLZUO4cCqPSmZ82B.8Wb1XTa9oXXHyqP6cjnxgQZzp.KEuPYnO
	hC6m6cOawx24RaKcCaNcrhS1JAaXq8QvFXZ5N_cR..PC_nKyTOWHdisJ3ehP
	gBqieHtsww5iHE.U6CQfleOVw.CenRlwNa0a7V5Nh3IEpYEyF04EfZOkhzlN
	ABe8Uhc2Co5wPKKw5ExcNpS0gahWx8fcwf138wsUEy1OM970Xo2PzwaX8n6k
	2b0PD2JrCgqUo3OFucpuNu_wBhVw9mjJaL1C0v_g-
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 28 Apr 2012 13:07:06 BST
X-Mailer: YahooMailWebService/0.8.117.340979
Message-ID: <1335614826.76812.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 28 Apr 2012 13:07:06 +0100 (BST)
From: David TECHER <davidtecher@yahoo.fr>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Xen VGA PassThrough NVIDIA: include pci-stub case for
	changeset 25240
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============6223901398864008297=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6223901398864008297==
Content-Type: multipart/alternative; boundary="62747910-54864027-1335614826=:76812"

--62747910-54864027-1335614826=:76812
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0AFor concerned persons like me that compil Xen with PassThrough NVI=
DIA, modifications introduced for changeset 25240 are limited (for the mome=
nt) for pciback.=0A=0AI am used to biding device using pci-stub (device : V=
ideo Card).=0A=0ACommenting out modifications introduced for this changeset=
 is not a good choice (I approve!). This is the only fix I found - since I =
am not a Xen expert - to be able to use NVIDIA patches for revision >=3D 25=
240=0A=0AMay it be possible to include case for devices with pci-stub usage=
?=0A=0A-=0A667 /* 668 static int libxl_pcidev_assignable(libxl_ctx *ctx, li=
bxl_device_pci *pcidev) 669 { 670     libxl_device_pci *pcidevs; 671     in=
t num, i; 672  673     pcidevs =3D libxl_device_pci_list_assignable(ctx, &n=
um); 674     for (i =3D 0; i < num; i++) { 675         if (pcidevs[i].domai=
n =3D=3D pcidev->domain && 676             pcidevs[i].bus =3D=3D pcidev->bu=
s && 677             pcidevs[i].dev =3D=3D pcidev->dev && 678             p=
cidevs[i].func =3D=3D pcidev->func) 679         { 680             return 1;=
 681         } 682     } 683     return 0; 684 } 685 */ 686 int libxl__devi=
ce_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int sta=
rting) 687 { 688     libxl_ctx *ctx =3D libxl__gc_owner(gc); 689     unsign=
ed int orig_vdev, pfunc_mask; 690     libxl_device_pci *assigned; 691     i=
nt num_assigned, i, rc; 692     int stubdomid =3D 0; 693  694     rc =3D li=
bxl__device_pci_setdefault(gc, pcidev); 695     if (rc) goto out; 696  697 =
/*    if
 (!libxl_pcidev_assignable(ctx, pcidev)) { 698         LIBXL__LOG(ctx, LIBX=
L__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable", 699              =
      pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func); 700         =
rc =3D ERROR_FAIL; 701         goto out; 702     } 703 */=0A--Kind regards=
=0A
--62747910-54864027-1335614826=:76812
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div>Hi,</div><div><b=
r></div><div>For concerned persons like me that compil Xen with PassThrough=
 NVIDIA, modifications introduced for changeset 25240 are limited (for the =
moment) for pciback.</div><div><br></div><div>I am used to biding device us=
ing pci-stub (device : Video Card).</div><div><br></div>=0A<div>Commenting =
out modifications introduced for this changeset is not a good choice (I app=
rove!). This is the only fix I found - since I am not a Xen expert - to be =
able to use NVIDIA patches for revision &gt;=3D 25240<br></div><br>May it b=
e possible to include case for devices with pci-stub usage?<div><br></div><=
div>-</div><pre> 667 /*=0A 668 static int libxl_pcidev_assignable(libxl_ctx=
 *ctx, libxl_device_pci *pcidev)=0A 669 {=0A 670     libxl_device_pci *pcid=
evs;=0A 671     int num, i;=0A 672 =0A 673     pcidevs =3D libxl_device_pci=
_list_assignable(ctx, &amp;num);=0A 674     for (i =3D 0; i &lt; num; i++) =
{=0A 675         if (pcidevs[i].domain =3D=3D pcidev-&gt;domain &amp;&amp;=
=0A 676             pcidevs[i].bus =3D=3D pcidev-&gt;bus &amp;&amp;=0A 677 =
            pcidevs[i].dev =3D=3D pcidev-&gt;dev &amp;&amp;=0A 678         =
    pcidevs[i].func =3D=3D pcidev-&gt;func)=0A 679         {=0A 680        =
     return 1;=0A 681         }=0A 682     }=0A 683     return 0;=0A 684 }=
=0A 685 */=0A 686 int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, =
libxl_device_pci *pcidev, int starting)=0A 687 {=0A 688     libxl_ctx *ctx =
=3D libxl__gc_owner(gc);=0A 689     unsigned int orig_vdev, pfunc_mask;=0A =
690     libxl_device_pci *assigned;=0A 691     int num_assigned, i, rc;=0A =
692     int stubdomid =3D 0;=0A 693 =0A 694     rc =3D libxl__device_pci_se=
tdefault(gc, pcidev);=0A 695     if (rc) goto out;=0A 696 =0A 697 /*    if =
(!libxl_pcidev_assignable(ctx, pcidev)) {=0A 698         LIBXL__LOG(ctx, LI=
BXL__LOG_ERROR, "PCI device %x:%x:%x.%x is not assignable",=0A 699         =
           pcidev-&gt;domain, pcidev-&gt;bus, pcidev-&gt;dev, pcidev-&gt;fu=
nc);=0A 700         rc =3D ERROR_FAIL;=0A 701         goto out;=0A 702     =
}=0A 703 */</pre><div>--Kind regards</div></div></body></html>
--62747910-54864027-1335614826=:76812--


--===============6223901398864008297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6223901398864008297==--


From xen-devel-bounces@lists.xen.org Sat Apr 28 15:15:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 15:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO9MP-0003Mh-4O; Sat, 28 Apr 2012 15:14:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1SO9MN-0003Mc-J7
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 15:14:55 +0000
Received: from [85.158.143.99:32235] by server-2.bemta-4.messagelabs.com id
	30/BD-17550-E690C9F4; Sat, 28 Apr 2012 15:14:54 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335626093!18639166!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4067 invoked from network); 28 Apr 2012 15:14:53 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-6.tower-216.messagelabs.com with SMTP;
	28 Apr 2012 15:14:53 -0000
Received: from linux-bhi8.site ([::ffff:147.2.207.77])
	by mail.novell.com with ESMTP; Sat, 28 Apr 2012 09:14:41 -0600
MIME-Version: 1.0
X-Mercurial-Node: 4a6043e1434a458506c30c687ac0cc1fd6ac6a08
Message-Id: <4a6043e1434a458506c3.1335626069@linux-bhi8.site>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sat, 28 Apr 2012 23:14:29 +0800
From: Bamvor Jian Zhang <bjzhang@suse.com>
To: xen-devel@lists.xensource.com
Cc: bjzhang@suse.com
Subject: [Xen-devel] [PATCH] [mq]: patch_libxl_get_console_tty.diff
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

diff -r 9dda0efd8ce1 -r 4a6043e1434a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/tools/libxl/libxl.c	Sat Apr 28 22:36:56 2012 +0800
@@ -15,6 +15,8 @@
  */
 
 #include "libxl_osdeps.h"
+//#include "libxl_osdeps.h"
+//#include "libxl_osdeps.h"
 
 #include "libxl_internal.h"
 
@@ -1173,6 +1175,29 @@ int libxl_primary_console_exec(libxl_ctx
     return rc;
 }
 
+int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path)
+{
+    GC_INIT(ctx);
+    char *dom_path = 0;
+    char *tty_path = 0, *os_type_path = 0, *vm_uuid_path = 0;
+    char *tty = 0, *os_type = 0, *vm_uuid = 0; 
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    vm_uuid_path = libxl__sprintf(gc, "%s/vm", dom_path);
+    vm_uuid = libxl__xs_read(gc, XBT_NULL, vm_uuid_path);
+    os_type_path = libxl__sprintf(gc, "%s/image/ostype", vm_uuid);
+    os_type = libxl__xs_read(gc, XBT_NULL, os_type_path);
+    if ( !strcmp("hvm", os_type)) {
+        tty_path = libxl__sprintf(gc, "%s/serial/0/tty", dom_path);
+    } else {
+        tty_path = libxl__sprintf(gc, "%s/console/tty", dom_path);
+    } 
+    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+    *path = strdup(tty);
+    GC_FREE;
+    return 0;
+}
+
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
     GC_INIT(ctx);
diff -r 9dda0efd8ce1 -r 4a6043e1434a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Apr 27 17:57:55 2012 +0200
+++ b/tools/libxl/libxl.h	Sat Apr 28 22:36:56 2012 +0800
@@ -534,6 +534,10 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * case of HVM guests, and before libxl_run_bootloader in case of PV
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
+/* libxl_get_console_tty get the tty path from xenstore according to the 
+ * domain id. 
+ */
+int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path);
 
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 15:15:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 15:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO9MP-0003Mh-4O; Sat, 28 Apr 2012 15:14:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1SO9MN-0003Mc-J7
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 15:14:55 +0000
Received: from [85.158.143.99:32235] by server-2.bemta-4.messagelabs.com id
	30/BD-17550-E690C9F4; Sat, 28 Apr 2012 15:14:54 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335626093!18639166!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4067 invoked from network); 28 Apr 2012 15:14:53 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-6.tower-216.messagelabs.com with SMTP;
	28 Apr 2012 15:14:53 -0000
Received: from linux-bhi8.site ([::ffff:147.2.207.77])
	by mail.novell.com with ESMTP; Sat, 28 Apr 2012 09:14:41 -0600
MIME-Version: 1.0
X-Mercurial-Node: 4a6043e1434a458506c30c687ac0cc1fd6ac6a08
Message-Id: <4a6043e1434a458506c3.1335626069@linux-bhi8.site>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sat, 28 Apr 2012 23:14:29 +0800
From: Bamvor Jian Zhang <bjzhang@suse.com>
To: xen-devel@lists.xensource.com
Cc: bjzhang@suse.com
Subject: [Xen-devel] [PATCH] [mq]: patch_libxl_get_console_tty.diff
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

diff -r 9dda0efd8ce1 -r 4a6043e1434a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Apr 27 17:57:55 2012 +0200
+++ b/tools/libxl/libxl.c	Sat Apr 28 22:36:56 2012 +0800
@@ -15,6 +15,8 @@
  */
 
 #include "libxl_osdeps.h"
+//#include "libxl_osdeps.h"
+//#include "libxl_osdeps.h"
 
 #include "libxl_internal.h"
 
@@ -1173,6 +1175,29 @@ int libxl_primary_console_exec(libxl_ctx
     return rc;
 }
 
+int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path)
+{
+    GC_INIT(ctx);
+    char *dom_path = 0;
+    char *tty_path = 0, *os_type_path = 0, *vm_uuid_path = 0;
+    char *tty = 0, *os_type = 0, *vm_uuid = 0; 
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    vm_uuid_path = libxl__sprintf(gc, "%s/vm", dom_path);
+    vm_uuid = libxl__xs_read(gc, XBT_NULL, vm_uuid_path);
+    os_type_path = libxl__sprintf(gc, "%s/image/ostype", vm_uuid);
+    os_type = libxl__xs_read(gc, XBT_NULL, os_type_path);
+    if ( !strcmp("hvm", os_type)) {
+        tty_path = libxl__sprintf(gc, "%s/serial/0/tty", dom_path);
+    } else {
+        tty_path = libxl__sprintf(gc, "%s/console/tty", dom_path);
+    } 
+    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+    *path = strdup(tty);
+    GC_FREE;
+    return 0;
+}
+
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
     GC_INIT(ctx);
diff -r 9dda0efd8ce1 -r 4a6043e1434a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Apr 27 17:57:55 2012 +0200
+++ b/tools/libxl/libxl.h	Sat Apr 28 22:36:56 2012 +0800
@@ -534,6 +534,10 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * case of HVM guests, and before libxl_run_bootloader in case of PV
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
+/* libxl_get_console_tty get the tty path from xenstore according to the 
+ * domain id. 
+ */
+int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path);
 
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 15:56:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 15:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO9zs-0003am-D9; Sat, 28 Apr 2012 15:55:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SO9zq-0003ah-Sv
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 15:55:42 +0000
Received: from [85.158.143.99:56085] by server-1.bemta-4.messagelabs.com id
	07/5C-20925-EF21C9F4; Sat, 28 Apr 2012 15:55:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335628540!25351474!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6365 invoked from network); 28 Apr 2012 15:55:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Apr 2012 15:55:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SO9zm-0001c0-I8; Sat, 28 Apr 2012 15:55:38 +0000
Date: Sat, 28 Apr 2012 16:55:38 +0100
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20120428155538.GA6132@ocelot.phlegethon.org>
References: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
	<20120425123115.GC51354@ocelot.phlegethon.org>
	<CAKLFbfw4SEiPkSui3x06fnfhnt3Gn_5exB8J1bdRd+ZjChAoTg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfw4SEiPkSui3x06fnfhnt3Gn_5exB8J1bdRd+ZjChAoTg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: todd.deshane@xen.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 09:39 -0500 on 27 Apr (1335519572), Srujan Kotikela wrote:
> I am interested in working with the implementation of XOAR. Is there are
> place to start (wiki/roadmap) etc. ?

Great!  As I said:

> > I believe the XCP/xapi developers are looking into implementing it.  You
> > could also look at Qubes OS, which uses a lot of similar ideas in a
> > desktop setting.

XCP devlopment hppens on the xen-api mailing list: 
http://lists.xen.org/mailman/listinfo/xen-api

Qubes OS is here: http://qubes-os.org/

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 15:56:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 15:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SO9zs-0003am-D9; Sat, 28 Apr 2012 15:55:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SO9zq-0003ah-Sv
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 15:55:42 +0000
Received: from [85.158.143.99:56085] by server-1.bemta-4.messagelabs.com id
	07/5C-20925-EF21C9F4; Sat, 28 Apr 2012 15:55:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335628540!25351474!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6365 invoked from network); 28 Apr 2012 15:55:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Apr 2012 15:55:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SO9zm-0001c0-I8; Sat, 28 Apr 2012 15:55:38 +0000
Date: Sat, 28 Apr 2012 16:55:38 +0100
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20120428155538.GA6132@ocelot.phlegethon.org>
References: <CAKLFbfxh++LcNEjQqOZHEnKnD9Jgo=SEToBfKG2-6p3dV4zThQ@mail.gmail.com>
	<20120425123115.GC51354@ocelot.phlegethon.org>
	<CAKLFbfw4SEiPkSui3x06fnfhnt3Gn_5exB8J1bdRd+ZjChAoTg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfw4SEiPkSui3x06fnfhnt3Gn_5exB8J1bdRd+ZjChAoTg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: todd.deshane@xen.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Regd. XOAR and Dom0 disaggregation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 09:39 -0500 on 27 Apr (1335519572), Srujan Kotikela wrote:
> I am interested in working with the implementation of XOAR. Is there are
> place to start (wiki/roadmap) etc. ?

Great!  As I said:

> > I believe the XCP/xapi developers are looking into implementing it.  You
> > could also look at Qubes OS, which uses a lot of similar ideas in a
> > desktop setting.

XCP devlopment hppens on the xen-api mailing list: 
http://lists.xen.org/mailman/listinfo/xen-api

Qubes OS is here: http://qubes-os.org/

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 16:57:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 16:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOAx3-0004IS-C1; Sat, 28 Apr 2012 16:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOAx1-0004IN-P8
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 16:56:52 +0000
Received: from [85.158.143.99:5142] by server-1.bemta-4.messagelabs.com id
	50/D8-20925-3512C9F4; Sat, 28 Apr 2012 16:56:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335632209!18156694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njg5Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 28 Apr 2012 16:56:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 16:56:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,497,1330905600"; d="scan'208";a="12189480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 16:56:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Apr 2012 17:56:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOAwy-0002Ay-4p;
	Sat, 28 Apr 2012 16:56:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOAwx-0000jD-Ut;
	Sat, 28 Apr 2012 17:56:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Apr 2012 17:56:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12762: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12762 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12762/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12694
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     12 guest-saverestore.2       fail REGR. vs. 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                f1c84a5cb52ee2915457b481c756fcc1dfe6a471
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Apr 28 16:57:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Apr 2012 16:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOAx3-0004IS-C1; Sat, 28 Apr 2012 16:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOAx1-0004IN-P8
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 16:56:52 +0000
Received: from [85.158.143.99:5142] by server-1.bemta-4.messagelabs.com id
	50/D8-20925-3512C9F4; Sat, 28 Apr 2012 16:56:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335632209!18156694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njg5Mw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 28 Apr 2012 16:56:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Apr 2012 16:56:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,497,1330905600"; d="scan'208";a="12189480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Apr 2012 16:56:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Apr 2012 17:56:48 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOAwy-0002Ay-4p;
	Sat, 28 Apr 2012 16:56:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOAwx-0000jD-Ut;
	Sat, 28 Apr 2012 17:56:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Apr 2012 17:56:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12762: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12762 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12762/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12694
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     12 guest-saverestore.2       fail REGR. vs. 12694

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                f1c84a5cb52ee2915457b481c756fcc1dfe6a471
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 06:16:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 06:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SONPt-0003Cp-38; Sun, 29 Apr 2012 06:15:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SONPr-0003Ck-1w
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 06:15:27 +0000
Received: from [85.158.143.35:31686] by server-2.bemta-4.messagelabs.com id
	B6/56-17550-E7CDC9F4; Sun, 29 Apr 2012 06:15:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335680125!14055014!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9391 invoked from network); 29 Apr 2012 06:15:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Apr 2012 06:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,499,1330905600"; d="scan'208";a="12191326"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Apr 2012 06:15:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 29 Apr 2012 07:15:23 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SONPn-0006II-LT;
	Sun, 29 Apr 2012 06:15:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SONPn-0008TE-Kd;
	Sun, 29 Apr 2012 07:15:23 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12763-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Apr 2012 07:15:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12763: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12763 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12763/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           9 guest-start                 fail pass in 12761

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12761

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  9dda0efd8ce1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 06:16:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 06:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SONPt-0003Cp-38; Sun, 29 Apr 2012 06:15:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SONPr-0003Ck-1w
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 06:15:27 +0000
Received: from [85.158.143.35:31686] by server-2.bemta-4.messagelabs.com id
	B6/56-17550-E7CDC9F4; Sun, 29 Apr 2012 06:15:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1335680125!14055014!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njg5Ng==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9391 invoked from network); 29 Apr 2012 06:15:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Apr 2012 06:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,499,1330905600"; d="scan'208";a="12191326"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Apr 2012 06:15:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 29 Apr 2012 07:15:23 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SONPn-0006II-LT;
	Sun, 29 Apr 2012 06:15:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SONPn-0008TE-Kd;
	Sun, 29 Apr 2012 07:15:23 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12763-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Apr 2012 07:15:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12763: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12763 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12763/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           9 guest-start                 fail pass in 12761

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12761

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  9dda0efd8ce1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU19-0005ac-Ky; Sun, 29 Apr 2012 13:18:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOU17-0005aX-Sv
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:18:22 +0000
Received: from [193.109.254.147:34377] by server-8.bemta-14.messagelabs.com id
	88/10-23244-D9F3D9F4; Sun, 29 Apr 2012 13:18:21 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335705499!14944!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13227 invoked from network); 29 Apr 2012 13:18:20 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	29 Apr 2012 13:18:20 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDI9W8020719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:18:09 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3TDI3rf006499; Sun, 29 Apr 2012 09:18:04 -0400
Message-ID: <4F9D3F8B.9010805@redhat.com>
Date: Sun, 29 Apr 2012 16:18:03 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
In-Reply-To: <20120424095923.GS15413@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/2012 12:59 PM, Gleb Natapov wrote:
> >  
> > +/*
> > + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> > + *
> > + * @apicid - apicid of vcpu to be kicked.
> > + */
> > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> > +{
> > +	struct kvm_vcpu *vcpu = NULL;
> > +	int i;
> > +
> > +	kvm_for_each_vcpu(i, vcpu, kvm) {
> > +		if (!kvm_apic_present(vcpu))
> > +			continue;
> > +
> > +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> > +			break;
> > +	}
> > +	if (vcpu) {
> > +		/*
> > +		 * Setting unhalt flag here can result in spurious runnable
> > +		 * state when unhalt reset does not happen in vcpu_block.
> > +		 * But that is harmless since that should soon result in halt.
> > +		 */
> > +		vcpu->arch.pv.pv_unhalted = 1;
> > +		/* We need everybody see unhalt before vcpu unblocks */
> > +		smp_mb();
> > +		kvm_vcpu_kick(vcpu);
> > +	}
> > +}
> This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> can use one of reserved delivery modes as PV delivery mode. We will
> disallow guest to trigger it through apic interface, so this will not be
> part of ABI and can be changed at will.
>

I'm not thrilled about this.  Those delivery modes will eventually
become unreserved.  We can have a kvm_lookup_apic_id() that is shared
among implementations.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU19-0005ac-Ky; Sun, 29 Apr 2012 13:18:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOU17-0005aX-Sv
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:18:22 +0000
Received: from [193.109.254.147:34377] by server-8.bemta-14.messagelabs.com id
	88/10-23244-D9F3D9F4; Sun, 29 Apr 2012 13:18:21 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1335705499!14944!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13227 invoked from network); 29 Apr 2012 13:18:20 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	29 Apr 2012 13:18:20 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDI9W8020719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:18:09 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3TDI3rf006499; Sun, 29 Apr 2012 09:18:04 -0400
Message-ID: <4F9D3F8B.9010805@redhat.com>
Date: Sun, 29 Apr 2012 16:18:03 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
In-Reply-To: <20120424095923.GS15413@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/24/2012 12:59 PM, Gleb Natapov wrote:
> >  
> > +/*
> > + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> > + *
> > + * @apicid - apicid of vcpu to be kicked.
> > + */
> > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> > +{
> > +	struct kvm_vcpu *vcpu = NULL;
> > +	int i;
> > +
> > +	kvm_for_each_vcpu(i, vcpu, kvm) {
> > +		if (!kvm_apic_present(vcpu))
> > +			continue;
> > +
> > +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> > +			break;
> > +	}
> > +	if (vcpu) {
> > +		/*
> > +		 * Setting unhalt flag here can result in spurious runnable
> > +		 * state when unhalt reset does not happen in vcpu_block.
> > +		 * But that is harmless since that should soon result in halt.
> > +		 */
> > +		vcpu->arch.pv.pv_unhalted = 1;
> > +		/* We need everybody see unhalt before vcpu unblocks */
> > +		smp_mb();
> > +		kvm_vcpu_kick(vcpu);
> > +	}
> > +}
> This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> can use one of reserved delivery modes as PV delivery mode. We will
> disallow guest to trigger it through apic interface, so this will not be
> part of ABI and can be changed at will.
>

I'm not thrilled about this.  Those delivery modes will eventually
become unreserved.  We can have a kvm_lookup_apic_id() that is shared
among implementations.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:21:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU3S-0005fA-Ej; Sun, 29 Apr 2012 13:20:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOU3Q-0005f2-Gq
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:20:44 +0000
Received: from [85.158.138.51:21633] by server-9.bemta-3.messagelabs.com id
	F8/F8-26691-B204D9F4; Sun, 29 Apr 2012 13:20:43 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335705642!24386294!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMjg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6777 invoked from network); 29 Apr 2012 13:20:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	29 Apr 2012 13:20:42 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDKZU3004712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:20:35 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3TDKVJb017628; Sun, 29 Apr 2012 09:20:32 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id F028518D495; Sun, 29 Apr 2012 16:20:30 +0300 (IDT)
Date: Sun, 29 Apr 2012 16:20:30 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120429132030.GB15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9D3F8B.9010805@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 29, 2012 at 04:18:03PM +0300, Avi Kivity wrote:
> On 04/24/2012 12:59 PM, Gleb Natapov wrote:
> > >  
> > > +/*
> > > + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> > > + *
> > > + * @apicid - apicid of vcpu to be kicked.
> > > + */
> > > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> > > +{
> > > +	struct kvm_vcpu *vcpu = NULL;
> > > +	int i;
> > > +
> > > +	kvm_for_each_vcpu(i, vcpu, kvm) {
> > > +		if (!kvm_apic_present(vcpu))
> > > +			continue;
> > > +
> > > +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> > > +			break;
> > > +	}
> > > +	if (vcpu) {
> > > +		/*
> > > +		 * Setting unhalt flag here can result in spurious runnable
> > > +		 * state when unhalt reset does not happen in vcpu_block.
> > > +		 * But that is harmless since that should soon result in halt.
> > > +		 */
> > > +		vcpu->arch.pv.pv_unhalted = 1;
> > > +		/* We need everybody see unhalt before vcpu unblocks */
> > > +		smp_mb();
> > > +		kvm_vcpu_kick(vcpu);
> > > +	}
> > > +}
> > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > can use one of reserved delivery modes as PV delivery mode. We will
> > disallow guest to trigger it through apic interface, so this will not be
> > part of ABI and can be changed at will.
> >
> 
> I'm not thrilled about this.  Those delivery modes will eventually
> become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> among implementations.
> 
This is only internal implementation. If they become unreserved we will
use something else.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:21:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU3S-0005fA-Ej; Sun, 29 Apr 2012 13:20:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOU3Q-0005f2-Gq
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:20:44 +0000
Received: from [85.158.138.51:21633] by server-9.bemta-3.messagelabs.com id
	F8/F8-26691-B204D9F4; Sun, 29 Apr 2012 13:20:43 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1335705642!24386294!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMjg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6777 invoked from network); 29 Apr 2012 13:20:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	29 Apr 2012 13:20:42 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDKZU3004712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:20:35 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3TDKVJb017628; Sun, 29 Apr 2012 09:20:32 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id F028518D495; Sun, 29 Apr 2012 16:20:30 +0300 (IDT)
Date: Sun, 29 Apr 2012 16:20:30 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120429132030.GB15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9D3F8B.9010805@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 29, 2012 at 04:18:03PM +0300, Avi Kivity wrote:
> On 04/24/2012 12:59 PM, Gleb Natapov wrote:
> > >  
> > > +/*
> > > + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> > > + *
> > > + * @apicid - apicid of vcpu to be kicked.
> > > + */
> > > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> > > +{
> > > +	struct kvm_vcpu *vcpu = NULL;
> > > +	int i;
> > > +
> > > +	kvm_for_each_vcpu(i, vcpu, kvm) {
> > > +		if (!kvm_apic_present(vcpu))
> > > +			continue;
> > > +
> > > +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> > > +			break;
> > > +	}
> > > +	if (vcpu) {
> > > +		/*
> > > +		 * Setting unhalt flag here can result in spurious runnable
> > > +		 * state when unhalt reset does not happen in vcpu_block.
> > > +		 * But that is harmless since that should soon result in halt.
> > > +		 */
> > > +		vcpu->arch.pv.pv_unhalted = 1;
> > > +		/* We need everybody see unhalt before vcpu unblocks */
> > > +		smp_mb();
> > > +		kvm_vcpu_kick(vcpu);
> > > +	}
> > > +}
> > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > can use one of reserved delivery modes as PV delivery mode. We will
> > disallow guest to trigger it through apic interface, so this will not be
> > part of ABI and can be changed at will.
> >
> 
> I'm not thrilled about this.  Those delivery modes will eventually
> become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> among implementations.
> 
This is only internal implementation. If they become unreserved we will
use something else.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:26:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:26:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU8f-0005q9-9q; Sun, 29 Apr 2012 13:26:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOU8e-0005q3-EE
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:26:08 +0000
Received: from [85.158.143.99:33990] by server-3.bemta-4.messagelabs.com id
	DD/0C-05853-F614D9F4; Sun, 29 Apr 2012 13:26:07 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335705966!24840265!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29716 invoked from network); 29 Apr 2012 13:26:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	29 Apr 2012 13:26:06 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDPvDI011335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:25:58 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDPm7Y004858; Sun, 29 Apr 2012 09:25:48 -0400
Message-ID: <4F9D415B.7010103@redhat.com>
Date: Sun, 29 Apr 2012 16:25:47 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 12:59 PM, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>
>  #endif
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index e216ba0..dad475b 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
>  		u64 length;
>  		u64 status;
>  	} osvw;
> +	/* pv related host specific info */
> +	struct {
> +		int pv_unhalted;
> +	} pv;
>  };

'bool'.  Or maybe push into vcpu->requests.

>  
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 4044ce0..7fc9be6 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
>  	case KVM_CAP_PCI_2_3:
> +	case KVM_CAP_PV_UNHALT:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:

Redundant, since we can infer this from KVM_GET_SUPPORTED_CPUID.  But
please indicate this in the documentation.

>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		/*
> +		 * Setting unhalt flag here can result in spurious runnable
> +		 * state when unhalt reset does not happen in vcpu_block.
> +		 * But that is harmless since that should soon result in halt.
> +		 */
> +		vcpu->arch.pv.pv_unhalted = 1;
> +		/* We need everybody see unhalt before vcpu unblocks */
> +		smp_mb();

smp_wmb().

> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +
>
>  /*
>   * hypercalls use architecture specific
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 42b7393..edf56d4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>  
>  		if (kvm_arch_vcpu_runnable(vcpu)) {
> +			/*
> +			 * This is the only safe place to reset unhalt flag.
> +			 * otherwise it results in loosing the notification
> +			 * which eventually can result in vcpu hangs.
> +			 */
> +			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
> +			/* preventing reordering should be enough here */
> +			barrier();
>  			kvm_make_request(KVM_REQ_UNHALT, vcpu);
>  			break;
>  		}
>

Hm, what about reusing KVM_REQ_UNHALT?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:26:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:26:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU8f-0005q9-9q; Sun, 29 Apr 2012 13:26:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOU8e-0005q3-EE
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:26:08 +0000
Received: from [85.158.143.99:33990] by server-3.bemta-4.messagelabs.com id
	DD/0C-05853-F614D9F4; Sun, 29 Apr 2012 13:26:07 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335705966!24840265!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29716 invoked from network); 29 Apr 2012 13:26:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	29 Apr 2012 13:26:06 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDPvDI011335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:25:58 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDPm7Y004858; Sun, 29 Apr 2012 09:25:48 -0400
Message-ID: <4F9D415B.7010103@redhat.com>
Date: Sun, 29 Apr 2012 16:25:47 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 12:59 PM, Raghavendra K T wrote:
> From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>
>  #endif
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index e216ba0..dad475b 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
>  		u64 length;
>  		u64 status;
>  	} osvw;
> +	/* pv related host specific info */
> +	struct {
> +		int pv_unhalted;
> +	} pv;
>  };

'bool'.  Or maybe push into vcpu->requests.

>  
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 4044ce0..7fc9be6 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
>  	case KVM_CAP_PCI_2_3:
> +	case KVM_CAP_PV_UNHALT:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:

Redundant, since we can infer this from KVM_GET_SUPPORTED_CPUID.  But
please indicate this in the documentation.

>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		/*
> +		 * Setting unhalt flag here can result in spurious runnable
> +		 * state when unhalt reset does not happen in vcpu_block.
> +		 * But that is harmless since that should soon result in halt.
> +		 */
> +		vcpu->arch.pv.pv_unhalted = 1;
> +		/* We need everybody see unhalt before vcpu unblocks */
> +		smp_mb();

smp_wmb().

> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +
>
>  /*
>   * hypercalls use architecture specific
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 42b7393..edf56d4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>  
>  		if (kvm_arch_vcpu_runnable(vcpu)) {
> +			/*
> +			 * This is the only safe place to reset unhalt flag.
> +			 * otherwise it results in loosing the notification
> +			 * which eventually can result in vcpu hangs.
> +			 */
> +			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
> +			/* preventing reordering should be enough here */
> +			barrier();
>  			kvm_make_request(KVM_REQ_UNHALT, vcpu);
>  			break;
>  		}
>

Hm, what about reusing KVM_REQ_UNHALT?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU98-0005ro-PR; Sun, 29 Apr 2012 13:26:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOU96-0005rc-QY
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:26:37 +0000
Received: from [85.158.139.83:24603] by server-4.bemta-5.messagelabs.com id
	3F/76-10788-B814D9F4; Sun, 29 Apr 2012 13:26:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335705994!18758962!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12081 invoked from network); 29 Apr 2012 13:26:35 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	29 Apr 2012 13:26:35 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDQRdX010726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:26:27 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDQLf7005039; Sun, 29 Apr 2012 09:26:22 -0400
Message-ID: <4F9D417D.1050105@redhat.com>
Date: Sun, 29 Apr 2012 16:26:21 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com>
In-Reply-To: <20120429132030.GB15413@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > can use one of reserved delivery modes as PV delivery mode. We will
> > > disallow guest to trigger it through apic interface, so this will not be
> > > part of ABI and can be changed at will.
> > >
> > 
> > I'm not thrilled about this.  Those delivery modes will eventually
> > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > among implementations.
> > 
> This is only internal implementation. If they become unreserved we will
> use something else.
>

Yeah, I'm thinking of that time.  Why do something temporary and fragile?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOU98-0005ro-PR; Sun, 29 Apr 2012 13:26:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOU96-0005rc-QY
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:26:37 +0000
Received: from [85.158.139.83:24603] by server-4.bemta-5.messagelabs.com id
	3F/76-10788-B814D9F4; Sun, 29 Apr 2012 13:26:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335705994!18758962!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12081 invoked from network); 29 Apr 2012 13:26:35 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	29 Apr 2012 13:26:35 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDQRdX010726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:26:27 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDQLf7005039; Sun, 29 Apr 2012 09:26:22 -0400
Message-ID: <4F9D417D.1050105@redhat.com>
Date: Sun, 29 Apr 2012 16:26:21 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com>
In-Reply-To: <20120429132030.GB15413@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > can use one of reserved delivery modes as PV delivery mode. We will
> > > disallow guest to trigger it through apic interface, so this will not be
> > > part of ABI and can be changed at will.
> > >
> > 
> > I'm not thrilled about this.  Those delivery modes will eventually
> > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > among implementations.
> > 
> This is only internal implementation. If they become unreserved we will
> use something else.
>

Yeah, I'm thinking of that time.  Why do something temporary and fragile?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOUAh-00060I-Cr; Sun, 29 Apr 2012 13:28:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOUAf-000605-C8
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:28:13 +0000
Received: from [85.158.138.51:56671] by server-2.bemta-3.messagelabs.com id
	9B/A7-09269-CE14D9F4; Sun, 29 Apr 2012 13:28:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335706090!24339255!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMjg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2836 invoked from network); 29 Apr 2012 13:28:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	29 Apr 2012 13:28:11 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDS4Z6011524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:28:04 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDRxIJ005203; Sun, 29 Apr 2012 09:27:59 -0400
Message-ID: <4F9D41DE.3080100@redhat.com>
Date: Sun, 29 Apr 2012 16:27:58 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 2/5] kvm : Fold pv_unhalt flag into
 GET_MP_STATE ioctl to aid migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 01:00 PM, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 6faa550..7354c1b 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
>  int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
>  				    struct kvm_mp_state *mp_state)
>  {
> -	mp_state->mp_state = vcpu->arch.mp_state;
> +	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED &&
> +				vcpu->arch.pv.pv_unhalted) ?
> +	KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
>  	return 0;
>  }

Not pretty.  Suggest rewriting using an if.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOUAh-00060I-Cr; Sun, 29 Apr 2012 13:28:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOUAf-000605-C8
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:28:13 +0000
Received: from [85.158.138.51:56671] by server-2.bemta-3.messagelabs.com id
	9B/A7-09269-CE14D9F4; Sun, 29 Apr 2012 13:28:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1335706090!24339255!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMjg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2836 invoked from network); 29 Apr 2012 13:28:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	29 Apr 2012 13:28:11 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDS4Z6011524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:28:04 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDRxIJ005203; Sun, 29 Apr 2012 09:27:59 -0400
Message-ID: <4F9D41DE.3080100@redhat.com>
Date: Sun, 29 Apr 2012 16:27:58 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 2/5] kvm : Fold pv_unhalt flag into
 GET_MP_STATE ioctl to aid migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/23/2012 01:00 PM, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 6faa550..7354c1b 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
>  int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
>  				    struct kvm_mp_state *mp_state)
>  {
> -	mp_state->mp_state = vcpu->arch.mp_state;
> +	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED &&
> +				vcpu->arch.pv.pv_unhalted) ?
> +	KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
>  	return 0;
>  }

Not pretty.  Suggest rewriting using an if.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:53:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOUYV-0006ay-AV; Sun, 29 Apr 2012 13:52:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOUYU-0006ar-4F
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:52:50 +0000
Received: from [85.158.143.99:29289] by server-2.bemta-4.messagelabs.com id
	0C/0C-17550-1B74D9F4; Sun, 29 Apr 2012 13:52:49 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335707567!25419018!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7722 invoked from network); 29 Apr 2012 13:52:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	29 Apr 2012 13:52:48 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDqTdI009660
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:52:29 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDqRJE008704; Sun, 29 Apr 2012 09:52:28 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 903A018D495; Sun, 29 Apr 2012 16:52:27 +0300 (IDT)
Date: Sun, 29 Apr 2012 16:52:27 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120429135227.GC15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com> <4F9D417D.1050105@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9D417D.1050105@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 29, 2012 at 04:26:21PM +0300, Avi Kivity wrote:
> On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > > can use one of reserved delivery modes as PV delivery mode. We will
> > > > disallow guest to trigger it through apic interface, so this will not be
> > > > part of ABI and can be changed at will.
> > > >
> > > 
> > > I'm not thrilled about this.  Those delivery modes will eventually
> > > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > > among implementations.
> > > 
> > This is only internal implementation. If they become unreserved we will
> > use something else.
> >
> 
> Yeah, I'm thinking of that time.  Why do something temporary and fragile?
> 
Why is it fragile? Just by unreserving the value Intel will not break
KVM. Only when KVM will implement apic feature that unreserves the value
we will have to change internal implementation and use another value,
but this will be done by the same patch that does unreserving. The
unreserving may even never happen. Meanwhile kvm_irq_delivery_to_apic()
will likely be optimized to use hash for unicast delivery and unhalt
hypercall will benefit from it immediately.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 13:53:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 13:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOUYV-0006ay-AV; Sun, 29 Apr 2012 13:52:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOUYU-0006ar-4F
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 13:52:50 +0000
Received: from [85.158.143.99:29289] by server-2.bemta-4.messagelabs.com id
	0C/0C-17550-1B74D9F4; Sun, 29 Apr 2012 13:52:49 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335707567!25419018!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzQ=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7722 invoked from network); 29 Apr 2012 13:52:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	29 Apr 2012 13:52:48 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3TDqTdI009660
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 29 Apr 2012 09:52:29 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3TDqRJE008704; Sun, 29 Apr 2012 09:52:28 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 903A018D495; Sun, 29 Apr 2012 16:52:27 +0300 (IDT)
Date: Sun, 29 Apr 2012 16:52:27 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120429135227.GC15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com> <4F9D417D.1050105@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9D417D.1050105@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 29, 2012 at 04:26:21PM +0300, Avi Kivity wrote:
> On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > > can use one of reserved delivery modes as PV delivery mode. We will
> > > > disallow guest to trigger it through apic interface, so this will not be
> > > > part of ABI and can be changed at will.
> > > >
> > > 
> > > I'm not thrilled about this.  Those delivery modes will eventually
> > > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > > among implementations.
> > > 
> > This is only internal implementation. If they become unreserved we will
> > use something else.
> >
> 
> Yeah, I'm thinking of that time.  Why do something temporary and fragile?
> 
Why is it fragile? Just by unreserving the value Intel will not break
KVM. Only when KVM will implement apic feature that unreserves the value
we will have to change internal implementation and use another value,
but this will be done by the same patch that does unreserving. The
unreserving may even never happen. Meanwhile kvm_irq_delivery_to_apic()
will likely be optimized to use hash for unicast delivery and unhalt
hypercall will benefit from it immediately.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 15:22:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 15:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOVwa-00072K-ER; Sun, 29 Apr 2012 15:21:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOVwZ-00072C-8u
	for xen-devel@lists.xen.org; Sun, 29 Apr 2012 15:21:47 +0000
Received: from [85.158.143.35:51665] by server-3.bemta-4.messagelabs.com id
	E0/46-05853-A8C5D9F4; Sun, 29 Apr 2012 15:21:46 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335712904!14959925!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22454 invoked from network); 29 Apr 2012 15:21:45 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Apr 2012 15:21:45 -0000
Received: by pbbro12 with SMTP id ro12so2018492pbb.32
	for <xen-devel@lists.xen.org>; Sun, 29 Apr 2012 08:21:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer;
	bh=2ZQd0XMVSWnn+/wOHXMiAZz4alpGGWsBAPEWVHhYCc8=;
	b=l12OZVZ4xY1d1dQOzGGZuVrK0465NVgtXPllQlv4O410xpt/eG3DSwebriA0yvDGJo
	tQCEodWYHRnzWQv/JyXqESmx18tIbTzHr5KGT2kGxGCyYtdKOlVH5Qi9SUUO272zVLyF
	t/1/b0IsuIbdk/B/tD0y5pkFEiiHUUXcbq5u7Qh8F3BRNMfwXChMZOrw65khvC5M4sZq
	0i96Wsl6U0jgkcN8QPApm/zQutdKtQeYdJ9AkHZ56l9cvsOE5L2Iwn+SDU/yVBDhzWU7
	oax66cjjUIN+bcEcNQoR9vci4/rQqFAL7AuixHOX0xuDtJRJyXBQn2OfO/MDe/muoiAq
	VfCA==
Received: by 10.68.223.234 with SMTP id qx10mr16907754pbc.154.1335712903874;
	Sun, 29 Apr 2012 08:21:43 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id tv5sm9265940pbc.35.2012.04.29.08.21.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 29 Apr 2012 08:21:43 -0700 (PDT)
From: wang zhihao <accept.acm@gmail.com>
Date: Sun, 29 Apr 2012 23:21:36 +0800
Message-Id: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgLCBBbGwKCkkgJ20gYSBncmVlbiBoYW5kIGFuZCBpbnRlcmVzdGVkIGluIG9wZW4gc291cmNl
IGRldmVsb3BtZW50LiBJIGhhdmUgYSBnZW5lcmFsIHF1ZXN0aW9uIKGwSG93IHRvIHRlc3QgbXkg
cGF0Y2ggYmVmb3JlIEkgcG9zdCBpdCB0byBwdWJsaWM/obEgSG9wZSB5b3UgZ3V5cyBnaXZlIG1l
IHNvbWUgc3VnZ2VzdGlvbnMuIDogKQoKRmlyc3RseSwgSSBjYW4gcmUtY29tcGlsZSB0aGUgY29k
ZSwgdG8gYXNzdXJlIG5vIHN5bnRheCBlcnJvci4gSG93ZXZlcixJIGRvbid0IGtub3cgaG93IHRv
IHRlc3QgbXkgcGF0Y2gncyBmdW5jdGlvbiBpcyByaWdodCBvciBub3QuIFNvbWUgc29mdHdhcmUg
cmVxdWlyZXMgdW5pdCB0ZXN0IGZvciBlYWNoIGZ1bmN0aW9uLiBJcyB0aGVyZSBhbnl0aGluZyBz
aW1pbGFyIGluIHhlbiBwcm9qZWN0PwoKVGhhbmsgeW91IHZlcnkgbXVjaCEKCkJlc3QgUmVnYXJk
cwpXYW5nIFpoaWhhbwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sun Apr 29 15:22:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 15:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOVwa-00072K-ER; Sun, 29 Apr 2012 15:21:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOVwZ-00072C-8u
	for xen-devel@lists.xen.org; Sun, 29 Apr 2012 15:21:47 +0000
Received: from [85.158.143.35:51665] by server-3.bemta-4.messagelabs.com id
	E0/46-05853-A8C5D9F4; Sun, 29 Apr 2012 15:21:46 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335712904!14959925!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22454 invoked from network); 29 Apr 2012 15:21:45 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Apr 2012 15:21:45 -0000
Received: by pbbro12 with SMTP id ro12so2018492pbb.32
	for <xen-devel@lists.xen.org>; Sun, 29 Apr 2012 08:21:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer;
	bh=2ZQd0XMVSWnn+/wOHXMiAZz4alpGGWsBAPEWVHhYCc8=;
	b=l12OZVZ4xY1d1dQOzGGZuVrK0465NVgtXPllQlv4O410xpt/eG3DSwebriA0yvDGJo
	tQCEodWYHRnzWQv/JyXqESmx18tIbTzHr5KGT2kGxGCyYtdKOlVH5Qi9SUUO272zVLyF
	t/1/b0IsuIbdk/B/tD0y5pkFEiiHUUXcbq5u7Qh8F3BRNMfwXChMZOrw65khvC5M4sZq
	0i96Wsl6U0jgkcN8QPApm/zQutdKtQeYdJ9AkHZ56l9cvsOE5L2Iwn+SDU/yVBDhzWU7
	oax66cjjUIN+bcEcNQoR9vci4/rQqFAL7AuixHOX0xuDtJRJyXBQn2OfO/MDe/muoiAq
	VfCA==
Received: by 10.68.223.234 with SMTP id qx10mr16907754pbc.154.1335712903874;
	Sun, 29 Apr 2012 08:21:43 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id tv5sm9265940pbc.35.2012.04.29.08.21.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 29 Apr 2012 08:21:43 -0700 (PDT)
From: wang zhihao <accept.acm@gmail.com>
Date: Sun, 29 Apr 2012 23:21:36 +0800
Message-Id: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgLCBBbGwKCkkgJ20gYSBncmVlbiBoYW5kIGFuZCBpbnRlcmVzdGVkIGluIG9wZW4gc291cmNl
IGRldmVsb3BtZW50LiBJIGhhdmUgYSBnZW5lcmFsIHF1ZXN0aW9uIKGwSG93IHRvIHRlc3QgbXkg
cGF0Y2ggYmVmb3JlIEkgcG9zdCBpdCB0byBwdWJsaWM/obEgSG9wZSB5b3UgZ3V5cyBnaXZlIG1l
IHNvbWUgc3VnZ2VzdGlvbnMuIDogKQoKRmlyc3RseSwgSSBjYW4gcmUtY29tcGlsZSB0aGUgY29k
ZSwgdG8gYXNzdXJlIG5vIHN5bnRheCBlcnJvci4gSG93ZXZlcixJIGRvbid0IGtub3cgaG93IHRv
IHRlc3QgbXkgcGF0Y2gncyBmdW5jdGlvbiBpcyByaWdodCBvciBub3QuIFNvbWUgc29mdHdhcmUg
cmVxdWlyZXMgdW5pdCB0ZXN0IGZvciBlYWNoIGZ1bmN0aW9uLiBJcyB0aGVyZSBhbnl0aGluZyBz
aW1pbGFyIGluIHhlbiBwcm9qZWN0PwoKVGhhbmsgeW91IHZlcnkgbXVjaCEKCkJlc3QgUmVnYXJk
cwpXYW5nIFpoaWhhbwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sun Apr 29 17:31:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 17:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOXwy-0008LF-Iv; Sun, 29 Apr 2012 17:30:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOXww-0008LA-Ry
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 17:30:19 +0000
Received: from [85.158.143.35:25741] by server-1.bemta-4.messagelabs.com id
	C9/10-20925-AAA7D9F4; Sun, 29 Apr 2012 17:30:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335720616!14966371!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njg5OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19244 invoked from network); 29 Apr 2012 17:30:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Apr 2012 17:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,500,1330905600"; d="scan'208";a="12194297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Apr 2012 17:30:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 29 Apr 2012 18:30:16 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOXwu-0001Xf-Ik;
	Sun, 29 Apr 2012 17:30:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOXwu-0003uO-Fq;
	Sun, 29 Apr 2012 18:30:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Apr 2012 18:30:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12764: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12764 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12764/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694
 test-i386-i386-pv             5 xen-boot         fail in 12762 REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 12762
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 12762
 test-amd64-amd64-xl-sedf    12 guest-saverestore.2 fail in 12762 pass in 12764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12762 never pass

version targeted for testing:
 linux                f1c84a5cb52ee2915457b481c756fcc1dfe6a471
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Apr 29 17:31:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Apr 2012 17:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOXwy-0008LF-Iv; Sun, 29 Apr 2012 17:30:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOXww-0008LA-Ry
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 17:30:19 +0000
Received: from [85.158.143.35:25741] by server-1.bemta-4.messagelabs.com id
	C9/10-20925-AAA7D9F4; Sun, 29 Apr 2012 17:30:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1335720616!14966371!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njg5OA==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19244 invoked from network); 29 Apr 2012 17:30:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Apr 2012 17:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,500,1330905600"; d="scan'208";a="12194297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Apr 2012 17:30:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 29 Apr 2012 18:30:16 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOXwu-0001Xf-Ik;
	Sun, 29 Apr 2012 17:30:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOXwu-0003uO-Fq;
	Sun, 29 Apr 2012 18:30:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Apr 2012 18:30:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12764: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12764 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12764/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12694
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 12694
 test-i386-i386-pv             5 xen-boot         fail in 12762 REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 12762
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 12762
 test-amd64-amd64-xl-sedf    12 guest-saverestore.2 fail in 12762 pass in 12764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 12762 never pass

version targeted for testing:
 linux                f1c84a5cb52ee2915457b481c756fcc1dfe6a471
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 06:01:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 06:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOjf7-0008ND-RF; Mon, 30 Apr 2012 06:00:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOjf6-0008N8-Ay
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 06:00:40 +0000
Received: from [85.158.138.51:36974] by server-10.bemta-3.messagelabs.com id
	97/79-29478-78A2E9F4; Mon, 30 Apr 2012 06:00:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335765638!22595579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjkwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27750 invoked from network); 30 Apr 2012 06:00:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 06:00:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,502,1330905600"; d="scan'208";a="12196373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Apr 2012 06:00:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Apr 2012 07:00:37 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOjf3-0005UL-Ln;
	Mon, 30 Apr 2012 06:00:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOjf3-0002gV-IQ;
	Mon, 30 Apr 2012 07:00:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12765-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Apr 2012 07:00:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12765: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12765 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12765/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 12763
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 12763
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12763
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 12763
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 12763
 test-amd64-amd64-xl           9 guest-start        fail in 12763 pass in 12765

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12763 like 12761

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12763 never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  9dda0efd8ce1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 06:01:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 06:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOjf7-0008ND-RF; Mon, 30 Apr 2012 06:00:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOjf6-0008N8-Ay
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 06:00:40 +0000
Received: from [85.158.138.51:36974] by server-10.bemta-3.messagelabs.com id
	97/79-29478-78A2E9F4; Mon, 30 Apr 2012 06:00:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1335765638!22595579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjkwMg==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27750 invoked from network); 30 Apr 2012 06:00:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 06:00:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,502,1330905600"; d="scan'208";a="12196373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Apr 2012 06:00:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Apr 2012 07:00:37 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOjf3-0005UL-Ln;
	Mon, 30 Apr 2012 06:00:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOjf3-0002gV-IQ;
	Mon, 30 Apr 2012 07:00:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12765-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Apr 2012 07:00:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12765: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12765 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12765/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 12763
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 12763
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12763
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 12763
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 12763
 test-amd64-amd64-xl           9 guest-start        fail in 12763 pass in 12765

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12763 like 12761

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12763 never pass

version targeted for testing:
 xen                  9dda0efd8ce1
baseline version:
 xen                  9dda0efd8ce1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 07:46:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 07:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlIu-0000TZ-Fh; Mon, 30 Apr 2012 07:45:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SOlIt-0000TU-5k
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 07:45:51 +0000
Received: from [85.158.138.51:44555] by server-10.bemta-3.messagelabs.com id
	FE/3C-29478-E234E9F4; Mon, 30 Apr 2012 07:45:50 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335771945!24283403!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxMDU0MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32165 invoked from network); 30 Apr 2012 07:45:48 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Apr 2012 07:45:48 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 30 Apr 2012 13:15:44 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 30 Apr 2012 13:15:12 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3U7jBTJ18219072
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 13:15:11 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3UDEwOs023757
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 23:14:59 +1000
Received: from [9.79.220.210] ([9.79.220.210])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3UDEoOp023427; Mon, 30 Apr 2012 23:14:51 +1000
Message-ID: <4F9E42F6.8050108@linux.vnet.ibm.com>
Date: Mon, 30 Apr 2012 13:14:54 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<4F9D415B.7010103@redhat.com>
In-Reply-To: <4F9D415B.7010103@redhat.com>
x-cbid: 12043007-2674-0000-0000-000004379E01
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thanks Avi, for the review.

On 04/29/2012 06:55 PM, Avi Kivity wrote:
> On 04/23/2012 12:59 PM, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>
>> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>>
>> The presence of these hypercalls is indicated to guest via
>> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>>
>>   #endif
>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>> index e216ba0..dad475b 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
>>   		u64 length;
>>   		u64 status;
>>   	} osvw;
>> +	/* pv related host specific info */
>> +	struct {
>> +		int pv_unhalted;
>> +	} pv;
>>   };
>
> 'bool'.  Or maybe push into vcpu->requests.

Ok. I think you meant
+	struct {
+		bool pv_unhalted;
+	} pv;

and as discussed in old series (V4), cleaner implementation having
vcpu request, would still need a flag to prevent vcpu hang, so back to
having one flag.

>
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 4044ce0..7fc9be6 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>   	case KVM_CAP_ASYNC_PF:
>>   	case KVM_CAP_GET_TSC_KHZ:
>>   	case KVM_CAP_PCI_2_3:
>> +	case KVM_CAP_PV_UNHALT:
>>   		r = 1;
>>   		break;
>>   	case KVM_CAP_COALESCED_MMIO:
>
> Redundant, since we can infer this from KVM_GET_SUPPORTED_CPUID.  But
> please indicate this in the documentation.
>

Ok. will mention that in documentation added for KVM_CAP_PV_UNHALT.

>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		/*
>> +		 * Setting unhalt flag here can result in spurious runnable
>> +		 * state when unhalt reset does not happen in vcpu_block.
>> +		 * But that is harmless since that should soon result in halt.
>> +		 */
>> +		vcpu->arch.pv.pv_unhalted = 1;
>> +		/* We need everybody see unhalt before vcpu unblocks */
>> +		smp_mb();
>
> smp_wmb().
>

Done.

>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
>> +
>>
>>   /*
>>    * hypercalls use architecture specific
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 42b7393..edf56d4 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>>   		prepare_to_wait(&vcpu->wq,&wait, TASK_INTERRUPTIBLE);
>>
>>   		if (kvm_arch_vcpu_runnable(vcpu)) {
>> +			/*
>> +			 * This is the only safe place to reset unhalt flag.
>> +			 * otherwise it results in loosing the notification
>> +			 * which eventually can result in vcpu hangs.
>> +			 */
>> +			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
>> +			/* preventing reordering should be enough here */
>> +			barrier();
>>   			kvm_make_request(KVM_REQ_UNHALT, vcpu);
>>   			break;
>>   		}
>>
>
> Hm, what about reusing KVM_REQ_UNHALT?
>

Yes, I had experimented this for some time without success.
For e.g. having
make_request(KVM_REQ_UNHALT, vcpu) directly from kick hypercall.

It would still need a flag. (did not get any alternative so far except
the  workaround posted in V4) :(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 07:46:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 07:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlIu-0000TZ-Fh; Mon, 30 Apr 2012 07:45:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SOlIt-0000TU-5k
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 07:45:51 +0000
Received: from [85.158.138.51:44555] by server-10.bemta-3.messagelabs.com id
	FE/3C-29478-E234E9F4; Mon, 30 Apr 2012 07:45:50 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1335771945!24283403!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxMDU0MDA=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32165 invoked from network); 30 Apr 2012 07:45:48 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Apr 2012 07:45:48 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 30 Apr 2012 13:15:44 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 30 Apr 2012 13:15:12 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3U7jBTJ18219072
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 13:15:11 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3UDEwOs023757
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 23:14:59 +1000
Received: from [9.79.220.210] ([9.79.220.210])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3UDEoOp023427; Mon, 30 Apr 2012 23:14:51 +1000
Message-ID: <4F9E42F6.8050108@linux.vnet.ibm.com>
Date: Mon, 30 Apr 2012 13:14:54 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<4F9D415B.7010103@redhat.com>
In-Reply-To: <4F9D415B.7010103@redhat.com>
x-cbid: 12043007-2674-0000-0000-000004379E01
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thanks Avi, for the review.

On 04/29/2012 06:55 PM, Avi Kivity wrote:
> On 04/23/2012 12:59 PM, Raghavendra K T wrote:
>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>
>> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>>
>> The presence of these hypercalls is indicated to guest via
>> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>>
>>   #endif
>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>> index e216ba0..dad475b 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -481,6 +481,10 @@ struct kvm_vcpu_arch {
>>   		u64 length;
>>   		u64 status;
>>   	} osvw;
>> +	/* pv related host specific info */
>> +	struct {
>> +		int pv_unhalted;
>> +	} pv;
>>   };
>
> 'bool'.  Or maybe push into vcpu->requests.

Ok. I think you meant
+	struct {
+		bool pv_unhalted;
+	} pv;

and as discussed in old series (V4), cleaner implementation having
vcpu request, would still need a flag to prevent vcpu hang, so back to
having one flag.

>
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 4044ce0..7fc9be6 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>   	case KVM_CAP_ASYNC_PF:
>>   	case KVM_CAP_GET_TSC_KHZ:
>>   	case KVM_CAP_PCI_2_3:
>> +	case KVM_CAP_PV_UNHALT:
>>   		r = 1;
>>   		break;
>>   	case KVM_CAP_COALESCED_MMIO:
>
> Redundant, since we can infer this from KVM_GET_SUPPORTED_CPUID.  But
> please indicate this in the documentation.
>

Ok. will mention that in documentation added for KVM_CAP_PV_UNHALT.

>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		/*
>> +		 * Setting unhalt flag here can result in spurious runnable
>> +		 * state when unhalt reset does not happen in vcpu_block.
>> +		 * But that is harmless since that should soon result in halt.
>> +		 */
>> +		vcpu->arch.pv.pv_unhalted = 1;
>> +		/* We need everybody see unhalt before vcpu unblocks */
>> +		smp_mb();
>
> smp_wmb().
>

Done.

>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
>> +
>>
>>   /*
>>    * hypercalls use architecture specific
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 42b7393..edf56d4 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>>   		prepare_to_wait(&vcpu->wq,&wait, TASK_INTERRUPTIBLE);
>>
>>   		if (kvm_arch_vcpu_runnable(vcpu)) {
>> +			/*
>> +			 * This is the only safe place to reset unhalt flag.
>> +			 * otherwise it results in loosing the notification
>> +			 * which eventually can result in vcpu hangs.
>> +			 */
>> +			kvm_arch_vcpu_reset_pv_unhalted(vcpu);
>> +			/* preventing reordering should be enough here */
>> +			barrier();
>>   			kvm_make_request(KVM_REQ_UNHALT, vcpu);
>>   			break;
>>   		}
>>
>
> Hm, what about reusing KVM_REQ_UNHALT?
>

Yes, I had experimented this for some time without success.
For e.g. having
make_request(KVM_REQ_UNHALT, vcpu) directly from kick hypercall.

It would still need a flag. (did not get any alternative so far except
the  workaround posted in V4) :(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 07:47:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 07:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlJi-0000VC-Sl; Mon, 30 Apr 2012 07:46:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SOlJh-0000V1-BK
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 07:46:41 +0000
Received: from [85.158.143.99:45313] by server-2.bemta-4.messagelabs.com id
	DD/12-17550-0634E9F4; Mon, 30 Apr 2012 07:46:40 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335771966!18285716!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAxODc4MzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12534 invoked from network); 30 Apr 2012 07:46:35 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Apr 2012 07:46:35 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 30 Apr 2012 13:16:05 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 30 Apr 2012 13:16:04 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3U7k3Jm3473506
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 13:16:03 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3UDFoqY026513
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 23:15:51 +1000
Received: from [9.79.220.210] ([9.79.220.210])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3UDFdSd025956; Mon, 30 Apr 2012 23:15:40 +1000
Message-ID: <4F9E4328.6060000@linux.vnet.ibm.com>
Date: Mon, 30 Apr 2012 13:15:44 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
	<4F9D41DE.3080100@redhat.com>
In-Reply-To: <4F9D41DE.3080100@redhat.com>
x-cbid: 12043007-3864-0000-0000-0000027CD409
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 2/5] kvm : Fold pv_unhalt flag into
 GET_MP_STATE ioctl to aid migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/29/2012 06:57 PM, Avi Kivity wrote:
> On 04/23/2012 01:00 PM, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> ---
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 6faa550..7354c1b 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
>>   int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
>>   				    struct kvm_mp_state *mp_state)
>>   {
>> -	mp_state->mp_state = vcpu->arch.mp_state;
>> +	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED&&
>> +				vcpu->arch.pv.pv_unhalted) ?
>> +	KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
>>   	return 0;
>>   }
>
> Not pretty.  Suggest rewriting using an if.
>

Ok.. 'll rewrite.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 07:47:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 07:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlJi-0000VC-Sl; Mon, 30 Apr 2012 07:46:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SOlJh-0000V1-BK
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 07:46:41 +0000
Received: from [85.158.143.99:45313] by server-2.bemta-4.messagelabs.com id
	DD/12-17550-0634E9F4; Mon, 30 Apr 2012 07:46:40 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335771966!18285716!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAxODc4MzU=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12534 invoked from network); 30 Apr 2012 07:46:35 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Apr 2012 07:46:35 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 30 Apr 2012 13:16:05 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 30 Apr 2012 13:16:04 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q3U7k3Jm3473506
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 13:16:03 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q3UDFoqY026513
	for <xen-devel@lists.xensource.com>; Mon, 30 Apr 2012 23:15:51 +1000
Received: from [9.79.220.210] ([9.79.220.210])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q3UDFdSd025956; Mon, 30 Apr 2012 23:15:40 +1000
Message-ID: <4F9E4328.6060000@linux.vnet.ibm.com>
Date: Mon, 30 Apr 2012 13:15:44 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423100002.30893.60584.sendpatchset@codeblue.in.ibm.com>
	<4F9D41DE.3080100@redhat.com>
In-Reply-To: <4F9D41DE.3080100@redhat.com>
x-cbid: 12043007-3864-0000-0000-0000027CD409
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 2/5] kvm : Fold pv_unhalt flag into
 GET_MP_STATE ioctl to aid migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/29/2012 06:57 PM, Avi Kivity wrote:
> On 04/23/2012 01:00 PM, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> ---
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 6faa550..7354c1b 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -5691,7 +5691,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
>>   int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
>>   				    struct kvm_mp_state *mp_state)
>>   {
>> -	mp_state->mp_state = vcpu->arch.mp_state;
>> +	mp_state->mp_state = (vcpu->arch.mp_state == KVM_MP_STATE_HALTED&&
>> +				vcpu->arch.pv.pv_unhalted) ?
>> +	KVM_MP_STATE_RUNNABLE : vcpu->arch.mp_state;
>>   	return 0;
>>   }
>
> Not pretty.  Suggest rewriting using an if.
>

Ok.. 'll rewrite.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpg-0001M9-6z; Mon, 30 Apr 2012 08:19:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jana@saout.de>) id 1SOZsy-0000fM-4E
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 19:34:20 +0000
Received: from [85.158.143.99:42701] by server-2.bemta-4.messagelabs.com id
	71/C3-17550-BB79D9F4; Sun, 29 Apr 2012 19:34:19 +0000
X-Env-Sender: jana@saout.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335728058!20449820!1
X-Originating-IP: [78.46.99.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31659 invoked from network); 29 Apr 2012 19:34:18 -0000
Received: from websrv.saout.de (HELO websrv.saout.de) (78.46.99.52)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Apr 2012 19:34:18 -0000
Received: from [IPv6:2001:6f8:13b1:1001:2677:3ff:fe1e:917c] (unknown
	[IPv6:2001:6f8:13b1:1001:2677:3ff:fe1e:917c])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mail.saout.de (Postfix) with ESMTPSA id B7E96C14E
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Apr 2012 21:34:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saout.de; s=default;
	t=1335728056; bh=djfmij4aMMvp5KmFoS9UXnyeMFek1ES7YA7AAThPugk=;
	h=Message-ID:Subject:From:Date;
	b=lrMWOE1UfMhYhMK9y9HTtJDyytQcPkG1HmZeZTTOoWh27va1OdJYs34HQyK1M9Z4g
	wCodEn9RASP4UWhJ6mMhIZg1dX7UhFBFzhQwahsJkOuaEtReGI2qMJX4Tsgbj6ru0w
	IZXSwkbVCJyUxDoHvA8sFTucEEep5jypUBpcMM5s=
Message-ID: <1335728058.4574.18.camel@localhost>
From: Jana Saout <jana@saout.de>
To: xen-devel@lists.xensource.com
Date: Sun, 29 Apr 2012 21:34:18 +0200
X-Mailer: Evolution 3.4.1 
Mime-Version: 1.0
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Subject: [Xen-devel] Self-ballooning question / cache issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I have been testing autoballooning on a production Xen system today
(with cleancache + frontswap on Xen-provided tmem).  For most of the
idle or CPU-centric VMs it seems to work just fine.

However, on one of the web-serving VMs, there is also a cron job running
every few minutes which runs over a rather large directory (plus, this
directory is on OCFS2 so this is a rather time-consuming process).  Now,
if the dcache/inode cache is large enough (which it was before, since
the VM got allocated 4 GB and is only using 1-2 most of the time), this
was not a problem.

Now, with self-ballooning, the memory gets reduced to somewhat between 1
and 2 GB and after a few minutes the load is going through the ceiling.
Jobs reading through said directories are piling up (stuck in D state,
waiting for the FS).  And most of the time kswapd is spinning at 100%.
If I deactivate self-ballooning and assign the VM 3 GB, everything goes
back to normal after a few minutes. (and, "ls -l" on said directory is
served from the cache again).

Now, I am aware that said problem is a self-made one.  The directory was
not actually supposed to contain that many files and the next job not
waiting for the previous job to terminate is cause for trouble - but
still, I would consider this a possible regression since it seems
self-ballooning is constantly thrashing the VM's caches.  Not all caches
can be saved in cleancache.

What about an additional tunable: a user-specified amount of pages that
is added on top of the computed target number of pages?  This way, one
could manually reserve a bit more room for other types of caches. (in
fact, I might try this myself, since it shouldn't be too hard to do so)

Any opinions on this?

Thank you,

	Jana



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpg-0001M9-6z; Mon, 30 Apr 2012 08:19:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jana@saout.de>) id 1SOZsy-0000fM-4E
	for xen-devel@lists.xensource.com; Sun, 29 Apr 2012 19:34:20 +0000
Received: from [85.158.143.99:42701] by server-2.bemta-4.messagelabs.com id
	71/C3-17550-BB79D9F4; Sun, 29 Apr 2012 19:34:19 +0000
X-Env-Sender: jana@saout.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1335728058!20449820!1
X-Originating-IP: [78.46.99.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31659 invoked from network); 29 Apr 2012 19:34:18 -0000
Received: from websrv.saout.de (HELO websrv.saout.de) (78.46.99.52)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Apr 2012 19:34:18 -0000
Received: from [IPv6:2001:6f8:13b1:1001:2677:3ff:fe1e:917c] (unknown
	[IPv6:2001:6f8:13b1:1001:2677:3ff:fe1e:917c])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mail.saout.de (Postfix) with ESMTPSA id B7E96C14E
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Apr 2012 21:34:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saout.de; s=default;
	t=1335728056; bh=djfmij4aMMvp5KmFoS9UXnyeMFek1ES7YA7AAThPugk=;
	h=Message-ID:Subject:From:Date;
	b=lrMWOE1UfMhYhMK9y9HTtJDyytQcPkG1HmZeZTTOoWh27va1OdJYs34HQyK1M9Z4g
	wCodEn9RASP4UWhJ6mMhIZg1dX7UhFBFzhQwahsJkOuaEtReGI2qMJX4Tsgbj6ru0w
	IZXSwkbVCJyUxDoHvA8sFTucEEep5jypUBpcMM5s=
Message-ID: <1335728058.4574.18.camel@localhost>
From: Jana Saout <jana@saout.de>
To: xen-devel@lists.xensource.com
Date: Sun, 29 Apr 2012 21:34:18 +0200
X-Mailer: Evolution 3.4.1 
Mime-Version: 1.0
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Subject: [Xen-devel] Self-ballooning question / cache issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I have been testing autoballooning on a production Xen system today
(with cleancache + frontswap on Xen-provided tmem).  For most of the
idle or CPU-centric VMs it seems to work just fine.

However, on one of the web-serving VMs, there is also a cron job running
every few minutes which runs over a rather large directory (plus, this
directory is on OCFS2 so this is a rather time-consuming process).  Now,
if the dcache/inode cache is large enough (which it was before, since
the VM got allocated 4 GB and is only using 1-2 most of the time), this
was not a problem.

Now, with self-ballooning, the memory gets reduced to somewhat between 1
and 2 GB and after a few minutes the load is going through the ceiling.
Jobs reading through said directories are piling up (stuck in D state,
waiting for the FS).  And most of the time kswapd is spinning at 100%.
If I deactivate self-ballooning and assign the VM 3 GB, everything goes
back to normal after a few minutes. (and, "ls -l" on said directory is
served from the cache again).

Now, I am aware that said problem is a self-made one.  The directory was
not actually supposed to contain that many files and the next job not
waiting for the previous job to terminate is cause for trouble - but
still, I would consider this a possible regression since it seems
self-ballooning is constantly thrashing the VM's caches.  Not all caches
can be saved in cleancache.

What about an additional tunable: a user-specified amount of pages that
is added on top of the computed target number of pages?  This way, one
could manually reserve a bit more room for other types of caches. (in
fact, I might try this myself, since it shouldn't be too hard to do so)

Any opinions on this?

Thank you,

	Jana



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpt-0001Or-OH; Mon, 30 Apr 2012 08:19:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOlps-0001OH-8c
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:19:56 +0000
Received: from [85.158.138.51:62434] by server-3.bemta-3.messagelabs.com id
	5F/04-04048-B2B4E9F4; Mon, 30 Apr 2012 08:19:55 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335773991!24387117!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21514 invoked from network); 30 Apr 2012 08:19:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	30 Apr 2012 08:19:51 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U8JfYk025474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 04:19:41 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3U8JZbs000503; Mon, 30 Apr 2012 04:19:36 -0400
Message-ID: <4F9E4B17.7060909@redhat.com>
Date: Mon, 30 Apr 2012 11:19:35 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<4F9D415B.7010103@redhat.com> <4F9E42F6.8050108@linux.vnet.ibm.com>
In-Reply-To: <4F9E42F6.8050108@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/30/2012 10:44 AM, Raghavendra K T wrote:
>> Hm, what about reusing KVM_REQ_UNHALT?
>>
>
>
> Yes, I had experimented this for some time without success.
> For e.g. having
> make_request(KVM_REQ_UNHALT, vcpu) directly from kick hypercall.
>
> It would still need a flag. (did not get any alternative so far except
> the  workaround posted in V4) :(
>

Okay.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpt-0001Or-OH; Mon, 30 Apr 2012 08:19:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOlps-0001OH-8c
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:19:56 +0000
Received: from [85.158.138.51:62434] by server-3.bemta-3.messagelabs.com id
	5F/04-04048-B2B4E9F4; Mon, 30 Apr 2012 08:19:55 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1335773991!24387117!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21514 invoked from network); 30 Apr 2012 08:19:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	30 Apr 2012 08:19:51 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U8JfYk025474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 04:19:41 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3U8JZbs000503; Mon, 30 Apr 2012 04:19:36 -0400
Message-ID: <4F9E4B17.7060909@redhat.com>
Date: Mon, 30 Apr 2012 11:19:35 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<4F9D415B.7010103@redhat.com> <4F9E42F6.8050108@linux.vnet.ibm.com>
In-Reply-To: <4F9E42F6.8050108@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/30/2012 10:44 AM, Raghavendra K T wrote:
>> Hm, what about reusing KVM_REQ_UNHALT?
>>
>
>
> Yes, I had experimented this for some time without success.
> For e.g. having
> make_request(KVM_REQ_UNHALT, vcpu) directly from kick hypercall.
>
> It would still need a flag. (did not get any alternative so far except
> the  workaround posted in V4) :(
>

Okay.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpf-0001M0-S1; Mon, 30 Apr 2012 08:19:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <FlorianSchandinat@gmx.de>) id 1SOHMs-0005iT-2G
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 23:47:58 +0000
Received: from [85.158.139.83:37752] by server-10.bemta-5.messagelabs.com id
	24/42-08260-DA18C9F4; Sat, 28 Apr 2012 23:47:57 +0000
X-Env-Sender: FlorianSchandinat@gmx.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335656875!23231367!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyNzkxNDI=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9834 invoked from network); 28 Apr 2012 23:47:56 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-4.tower-182.messagelabs.com with SMTP;
	28 Apr 2012 23:47:56 -0000
Received: (qmail invoked by alias); 28 Apr 2012 23:47:54 -0000
Received: from dslb-092-074-253-070.pools.arcor-ip.net (EHLO [192.168.0.9])
	[92.74.253.70]
	by mail.gmx.net (mp019) with SMTP; 29 Apr 2012 01:47:54 +0200
X-Authenticated: #10250065
X-Provags-ID: V01U2FsdGVkX1/mhxoKEa3mL2YDX/5we44v80LJQzBiiS0Ia1MhA3
	YPexr62dGrvvsw
Message-ID: <4F9C819E.4030205@gmx.de>
Date: Sat, 28 Apr 2012 23:47:42 +0000
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
	<20120426214222.GA11289@phenom.dumpdata.com>
In-Reply-To: <20120426214222.GA11289@phenom.dumpdata.com>
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Julia Lawall <Julia.Lawall@lip6.fr>, linux-fbdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] drivers/video/xen-fbfront.c: add missing
 cleanup code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On 04/26/2012 09:42 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 22, 2012 at 11:57:40AM +0200, Julia Lawall wrote:
>> From: Julia Lawall <Julia.Lawall@lip6.fr>
>>
>> The operations in the subsequent error-handling code appear to be also
>> useful here.
> 
> How about doing it this way?

Looks good to me.

> Florian, are you OK me carrying this patch in my tree for Linus or would
> you prefer to do it?

Yes, I'm okay with you carrying this patch. Feel free to add
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>


Best regards,

Florian Tobias Schandinat

> 
> commit a833fb9973b47cb30d1086e73f20b62a425bcd85
> Author: Julia Lawall <Julia.Lawall@lip6.fr>
> Date:   Sun Apr 22 11:57:40 2012 +0200
> 
>     drivers/video/xen-fbfront.c: add missing cleanup code
>     
>     The operations in the subsequent error-handling code appear to be also
>     useful here.
>     
>     Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>     [v1: Collapse some of the error handling functions]
>     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index cb4529c..aa42160 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -458,26 +458,31 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
>  	xenfb_init_shared_page(info, fb_info);
>  
>  	ret = xenfb_connect_backend(dev, info);
> -	if (ret < 0)
> -		goto error;
> +	if (ret < 0) {
> +		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
> +		goto error_fb;
> +	}
>  
>  	ret = register_framebuffer(fb_info);
>  	if (ret) {
> -		fb_deferred_io_cleanup(fb_info);
> -		fb_dealloc_cmap(&fb_info->cmap);
> -		framebuffer_release(fb_info);
>  		xenbus_dev_fatal(dev, ret, "register_framebuffer");
> -		goto error;
> +		goto error_fb;
>  	}
>  	info->fb_info = fb_info;
>  
>  	xenfb_make_preferred_console();
>  	return 0;
>  
> - error_nomem:
> -	ret = -ENOMEM;
> -	xenbus_dev_fatal(dev, ret, "allocating device memory");
> - error:
> +error_fb:
> +	fb_deferred_io_cleanup(fb_info);
> +	fb_dealloc_cmap(&fb_info->cmap);
> +	framebuffer_release(fb_info);
> +error_nomem:
> +	if (!ret) {
> +		ret = -ENOMEM;
> +		xenbus_dev_fatal(dev, ret, "allocating device memory");
> +	}
> +error:
>  	xenfb_remove(dev);
>  	return ret;
>  }
> 
> 
> 
>>
>> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>>
>> ---
>> Not tested.
>>
>>  drivers/video/xen-fbfront.c |    7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
>> index cb4529c..b0bd59c 100644
>> --- a/drivers/video/xen-fbfront.c
>> +++ b/drivers/video/xen-fbfront.c
>> @@ -458,8 +458,13 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
>>  	xenfb_init_shared_page(info, fb_info);
>>  
>>  	ret = xenfb_connect_backend(dev, info);
>> -	if (ret < 0)
>> +	if (ret < 0) {
>> +		fb_deferred_io_cleanup(fb_info);
>> +		fb_dealloc_cmap(&fb_info->cmap);
>> +		framebuffer_release(fb_info);
>> +		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
>>  		goto error;
>> +	}
>>  
>>  	ret = register_framebuffer(fb_info);
>>  	if (ret) {
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpf-0001M0-S1; Mon, 30 Apr 2012 08:19:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <FlorianSchandinat@gmx.de>) id 1SOHMs-0005iT-2G
	for xen-devel@lists.xensource.com; Sat, 28 Apr 2012 23:47:58 +0000
Received: from [85.158.139.83:37752] by server-10.bemta-5.messagelabs.com id
	24/42-08260-DA18C9F4; Sat, 28 Apr 2012 23:47:57 +0000
X-Env-Sender: FlorianSchandinat@gmx.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1335656875!23231367!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyNzkxNDI=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9834 invoked from network); 28 Apr 2012 23:47:56 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-4.tower-182.messagelabs.com with SMTP;
	28 Apr 2012 23:47:56 -0000
Received: (qmail invoked by alias); 28 Apr 2012 23:47:54 -0000
Received: from dslb-092-074-253-070.pools.arcor-ip.net (EHLO [192.168.0.9])
	[92.74.253.70]
	by mail.gmx.net (mp019) with SMTP; 29 Apr 2012 01:47:54 +0200
X-Authenticated: #10250065
X-Provags-ID: V01U2FsdGVkX1/mhxoKEa3mL2YDX/5we44v80LJQzBiiS0Ia1MhA3
	YPexr62dGrvvsw
Message-ID: <4F9C819E.4030205@gmx.de>
Date: Sat, 28 Apr 2012 23:47:42 +0000
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1335088660-13219-1-git-send-email-Julia.Lawall@lip6.fr>
	<20120426214222.GA11289@phenom.dumpdata.com>
In-Reply-To: <20120426214222.GA11289@phenom.dumpdata.com>
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Julia Lawall <Julia.Lawall@lip6.fr>, linux-fbdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] drivers/video/xen-fbfront.c: add missing
 cleanup code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On 04/26/2012 09:42 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 22, 2012 at 11:57:40AM +0200, Julia Lawall wrote:
>> From: Julia Lawall <Julia.Lawall@lip6.fr>
>>
>> The operations in the subsequent error-handling code appear to be also
>> useful here.
> 
> How about doing it this way?

Looks good to me.

> Florian, are you OK me carrying this patch in my tree for Linus or would
> you prefer to do it?

Yes, I'm okay with you carrying this patch. Feel free to add
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>


Best regards,

Florian Tobias Schandinat

> 
> commit a833fb9973b47cb30d1086e73f20b62a425bcd85
> Author: Julia Lawall <Julia.Lawall@lip6.fr>
> Date:   Sun Apr 22 11:57:40 2012 +0200
> 
>     drivers/video/xen-fbfront.c: add missing cleanup code
>     
>     The operations in the subsequent error-handling code appear to be also
>     useful here.
>     
>     Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>     [v1: Collapse some of the error handling functions]
>     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index cb4529c..aa42160 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -458,26 +458,31 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
>  	xenfb_init_shared_page(info, fb_info);
>  
>  	ret = xenfb_connect_backend(dev, info);
> -	if (ret < 0)
> -		goto error;
> +	if (ret < 0) {
> +		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
> +		goto error_fb;
> +	}
>  
>  	ret = register_framebuffer(fb_info);
>  	if (ret) {
> -		fb_deferred_io_cleanup(fb_info);
> -		fb_dealloc_cmap(&fb_info->cmap);
> -		framebuffer_release(fb_info);
>  		xenbus_dev_fatal(dev, ret, "register_framebuffer");
> -		goto error;
> +		goto error_fb;
>  	}
>  	info->fb_info = fb_info;
>  
>  	xenfb_make_preferred_console();
>  	return 0;
>  
> - error_nomem:
> -	ret = -ENOMEM;
> -	xenbus_dev_fatal(dev, ret, "allocating device memory");
> - error:
> +error_fb:
> +	fb_deferred_io_cleanup(fb_info);
> +	fb_dealloc_cmap(&fb_info->cmap);
> +	framebuffer_release(fb_info);
> +error_nomem:
> +	if (!ret) {
> +		ret = -ENOMEM;
> +		xenbus_dev_fatal(dev, ret, "allocating device memory");
> +	}
> +error:
>  	xenfb_remove(dev);
>  	return ret;
>  }
> 
> 
> 
>>
>> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>>
>> ---
>> Not tested.
>>
>>  drivers/video/xen-fbfront.c |    7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
>> index cb4529c..b0bd59c 100644
>> --- a/drivers/video/xen-fbfront.c
>> +++ b/drivers/video/xen-fbfront.c
>> @@ -458,8 +458,13 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
>>  	xenfb_init_shared_page(info, fb_info);
>>  
>>  	ret = xenfb_connect_backend(dev, info);
>> -	if (ret < 0)
>> +	if (ret < 0) {
>> +		fb_deferred_io_cleanup(fb_info);
>> +		fb_dealloc_cmap(&fb_info->cmap);
>> +		framebuffer_release(fb_info);
>> +		xenbus_dev_fatal(dev, ret, "xenfb_connect_backend");
>>  		goto error;
>> +	}
>>  
>>  	ret = register_framebuffer(fb_info);
>>  	if (ret) {
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpe-0001Lc-P4; Mon, 30 Apr 2012 08:19:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNnYb-0004Ny-6D
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 15:58:05 +0000
Received: from [193.109.254.147:51808] by server-1.bemta-14.messagelabs.com id
	4D/09-29372-C02CA9F4; Fri, 27 Apr 2012 15:58:04 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335542283!6653340!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29248 invoked from network); 27 Apr 2012 15:58:03 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:58:03 -0000
Received: by lboi15 with SMTP id i15so746999lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 08:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kWNTYA6J03BWxv5fh4ZinVCxO4Y5B9ITnlxXvtKQPbU=;
	b=fxOggRSPnGDMtHRTt98V/458VwF7A+1xX3W66WOUj7knl0G4bh4VrnFvSV8Rbobqyr
	xQrw+dXdT4j3eXSoOL9zlAPAPO54AkgUoBFrj4xbtNYqdfiSmeIVVbaB33x9Jv9umVcv
	xdPbyWD33EHqg7GoCq/yIuDg5w/okQldbNIn6cVV6YpVDAghhrbGiZpc4nyG0P9npX8q
	H2tHbUgueL5c9msk2irephoIyCYVtSa0RTin8DCvg87+e4pV5DKkFTKBF/xFkKRlFyc8
	SsirItYmkeB81nt8cNeLhFNG6is+LrUi8c4blyU3RyC1ZtIbRbjigbyewjnMTDWTzOX+
	4EZw==
MIME-Version: 1.0
Received: by 10.112.99.198 with SMTP id es6mr5364487lbb.66.1335542282761; Fri,
	27 Apr 2012 08:58:02 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Fri, 27 Apr 2012 08:58:02 -0700 (PDT)
In-Reply-To: <1335529430.28015.194.camel@zakaz.uk.xensource.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Apr 2012 11:58:02 -0400
Message-ID: <CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
From: misiu godfrey <misiu.godfrey@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8648787745298208291=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8648787745298208291==
Content-Type: multipart/alternative; boundary=14dae9d67bb458b65c04beab2b5a

--14dae9d67bb458b65c04beab2b5a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 27, 2012 at 8:23 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> Are you using the staging or non-staging version? What was the exact URL

> you cloned?
>

I have, to my knowledge, been using the non-staging version.
The exact URL I have been cloning is: "
http://xenbits.xen.org/hg/xen-4.1-testing.hg"


>
> [...]
> > + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537
> > fatal: reference is not a tree:
> > a2d2123a7dfc4d116011d51f48df786a3b853537
>
> This seems to be there now and it "works for me" (tm). Might just have
> been skew with the staging tree -- can you try again?
>

I just re-ran "make world" on both of my machines to the
same erroneous result.  Specifically, I am running two Debian 6 machines,
one of which is in a VMware virtual machine running over Windows 7 (for
testing), and the other is a Sun Ultra 40.

Misiu.

--14dae9d67bb458b65c04beab2b5a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Apr 2=
7, 2012 at 8:23 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</s=
pan> wrote:</div>

<div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Are you =
using the staging or non-staging version? What was the exact URL=A0</blockq=
uote>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt; you cloned?<br></blockquote><div><br></=
div><div>I have, to my knowledge, been using the non-staging version.</div>

<div>The exact URL I have been cloning is: &quot;<a href=3D"http://xenbits.=
xen.org/hg/xen-4.1-testing.hg" target=3D"_blank">http://xenbits.xen.org/hg/=
xen-4.1-testing.hg</a>&quot;</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">


<br>
[...]<br>
<div>&gt; + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537<=
br>
&gt; fatal: reference is not a tree:<br>
&gt; a2d2123a7dfc4d116011d51f48df786a3b853537<br>
<br>
</div>This seems to be there now and it &quot;works for me&quot; (tm). Migh=
t just have<br>
been skew with the staging tree -- can you try again?<br></blockquote><div>=
<br></div><div>I just re-ran &quot;make world&quot; on both of my machines =
to the same=A0erroneous=A0result. =A0Specifically, I am running two Debian =
6 machines, one of which is in a VMware virtual machine running over Window=
s 7 (for testing), and the other is a Sun Ultra 40.</div>
<div><br></div><div>Misiu.</div>
</div><br></div>

--14dae9d67bb458b65c04beab2b5a--


--===============8648787745298208291==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8648787745298208291==--


From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpe-0001Lc-P4; Mon, 30 Apr 2012 08:19:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNnYb-0004Ny-6D
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 15:58:05 +0000
Received: from [193.109.254.147:51808] by server-1.bemta-14.messagelabs.com id
	4D/09-29372-C02CA9F4; Fri, 27 Apr 2012 15:58:04 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1335542283!6653340!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29248 invoked from network); 27 Apr 2012 15:58:03 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 15:58:03 -0000
Received: by lboi15 with SMTP id i15so746999lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 08:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kWNTYA6J03BWxv5fh4ZinVCxO4Y5B9ITnlxXvtKQPbU=;
	b=fxOggRSPnGDMtHRTt98V/458VwF7A+1xX3W66WOUj7knl0G4bh4VrnFvSV8Rbobqyr
	xQrw+dXdT4j3eXSoOL9zlAPAPO54AkgUoBFrj4xbtNYqdfiSmeIVVbaB33x9Jv9umVcv
	xdPbyWD33EHqg7GoCq/yIuDg5w/okQldbNIn6cVV6YpVDAghhrbGiZpc4nyG0P9npX8q
	H2tHbUgueL5c9msk2irephoIyCYVtSa0RTin8DCvg87+e4pV5DKkFTKBF/xFkKRlFyc8
	SsirItYmkeB81nt8cNeLhFNG6is+LrUi8c4blyU3RyC1ZtIbRbjigbyewjnMTDWTzOX+
	4EZw==
MIME-Version: 1.0
Received: by 10.112.99.198 with SMTP id es6mr5364487lbb.66.1335542282761; Fri,
	27 Apr 2012 08:58:02 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Fri, 27 Apr 2012 08:58:02 -0700 (PDT)
In-Reply-To: <1335529430.28015.194.camel@zakaz.uk.xensource.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Apr 2012 11:58:02 -0400
Message-ID: <CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
From: misiu godfrey <misiu.godfrey@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============8648787745298208291=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8648787745298208291==
Content-Type: multipart/alternative; boundary=14dae9d67bb458b65c04beab2b5a

--14dae9d67bb458b65c04beab2b5a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 27, 2012 at 8:23 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> Are you using the staging or non-staging version? What was the exact URL

> you cloned?
>

I have, to my knowledge, been using the non-staging version.
The exact URL I have been cloning is: "
http://xenbits.xen.org/hg/xen-4.1-testing.hg"


>
> [...]
> > + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537
> > fatal: reference is not a tree:
> > a2d2123a7dfc4d116011d51f48df786a3b853537
>
> This seems to be there now and it "works for me" (tm). Might just have
> been skew with the staging tree -- can you try again?
>

I just re-ran "make world" on both of my machines to the
same erroneous result.  Specifically, I am running two Debian 6 machines,
one of which is in a VMware virtual machine running over Windows 7 (for
testing), and the other is a Sun Ultra 40.

Misiu.

--14dae9d67bb458b65c04beab2b5a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Apr 2=
7, 2012 at 8:23 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</s=
pan> wrote:</div>

<div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Are you =
using the staging or non-staging version? What was the exact URL=A0</blockq=
uote>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt; you cloned?<br></blockquote><div><br></=
div><div>I have, to my knowledge, been using the non-staging version.</div>

<div>The exact URL I have been cloning is: &quot;<a href=3D"http://xenbits.=
xen.org/hg/xen-4.1-testing.hg" target=3D"_blank">http://xenbits.xen.org/hg/=
xen-4.1-testing.hg</a>&quot;</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">


<br>
[...]<br>
<div>&gt; + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537<=
br>
&gt; fatal: reference is not a tree:<br>
&gt; a2d2123a7dfc4d116011d51f48df786a3b853537<br>
<br>
</div>This seems to be there now and it &quot;works for me&quot; (tm). Migh=
t just have<br>
been skew with the staging tree -- can you try again?<br></blockquote><div>=
<br></div><div>I just re-ran &quot;make world&quot; on both of my machines =
to the same=A0erroneous=A0result. =A0Specifically, I am running two Debian =
6 machines, one of which is in a VMware virtual machine running over Window=
s 7 (for testing), and the other is a Sun Ultra 40.</div>
<div><br></div><div>Misiu.</div>
</div><br></div>

--14dae9d67bb458b65c04beab2b5a--


--===============8648787745298208291==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8648787745298208291==--


From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpf-0001Lr-Go; Mon, 30 Apr 2012 08:19:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNqHY-0007Nz-QC
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:52:41 +0000
Received: from [85.158.143.99:63757] by server-3.bemta-4.messagelabs.com id
	A7/EC-05853-8FAEA9F4; Fri, 27 Apr 2012 18:52:40 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335552757!18078623!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32541 invoked from network); 27 Apr 2012 18:52:38 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:52:38 -0000
Received: by lboi15 with SMTP id i15so884465lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:52:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=4aLpj9L7a0u+16173RlYm9fNDWwMeAXWyLdr5WKj6XU=;
	b=pK5cKrEG6w4Vx+XGqXq7A5DCPq7UPwGml7fCOfyyf7g7YnYcABOnktX0elYZLMl+TS
	1aR9O7llgEtfnmuLQiFbxQfIk1mrZU/NiOl40B9SYmcEXv62RhovBWIOFG70CvuAGun6
	dKecFRCwB1NMysdyIzL0f6VwGRVs6wgkNh/ZU8MZzzPRQR8fMN2elp16Pzzx5wiW0jDB
	6gOye42dxomvFWqs5UKts0XmczQulekkvE3CkHZwPW5RBfRt2tUP/+N7uWLBT7w8jiJP
	pjWEYjHEh5Pmu42iRxjVVmlYSoWW45EjXWeDjp1/ZpVaVs9WiZMB2UyeD422Yezb8m/F
	DlwA==
MIME-Version: 1.0
Received: by 10.112.85.200 with SMTP id j8mr5838341lbz.80.1335552756497; Fri,
	27 Apr 2012 11:52:36 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Fri, 27 Apr 2012 11:52:36 -0700 (PDT)
In-Reply-To: <1335550569.4881.74.camel@dagon.hellion.org.uk>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
	<1335543062.28015.234.camel@zakaz.uk.xensource.com>
	<CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
	<1335550569.4881.74.camel@dagon.hellion.org.uk>
Date: Fri, 27 Apr 2012 14:52:36 -0400
Message-ID: <CAMVU=Qind0vv4hiM-9SikL55MrSM5SohQkknDXLp5+fRLU33GA@mail.gmail.com>
From: Misiu Godfrey <misiu.godfrey@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3607955890781570681=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3607955890781570681==
Content-Type: multipart/alternative; boundary=bcaec554d60ca13c2604bead9bb3

--bcaec554d60ca13c2604bead9bb3
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 27, 2012 at 2:16 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> >
> > As a workaround you could set QEMU_REMOTE in .config (or edit Config.mk)
> > to refer to git://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git
> > instead of the non-staging version.
>
>
I have implemented the workaround and everything is compiling fine so far
as I can see.  Thanks for your help, and I will keep an eye out for some
sort of re-synch in the future.

Misiu.

--bcaec554d60ca13c2604bead9bb3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, Apr 27, 2012 =
at 2:16 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbe=
ll@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt;<br>&gt; As a workaround you could set Q=
EMU_REMOTE in .config (or edit Config.mk)<br>&gt; to refer to git://<a href=
=3D"http://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git" target=
=3D"_blank">xenbits.xensource.com/staging/qemu-xen-4.1-testing.git</a><br>
&gt; instead of the non-staging version.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div>=A0</div></div>I have implemented the workaround and everything is =
compiling fine so far as I can see. =A0Thanks for your help, and I will kee=
p an eye out for some sort of re-synch in the future.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Misiu.</div=
>

--bcaec554d60ca13c2604bead9bb3--


--===============3607955890781570681==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3607955890781570681==--


From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpf-0001Lr-Go; Mon, 30 Apr 2012 08:19:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNqHY-0007Nz-QC
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 18:52:41 +0000
Received: from [85.158.143.99:63757] by server-3.bemta-4.messagelabs.com id
	A7/EC-05853-8FAEA9F4; Fri, 27 Apr 2012 18:52:40 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335552757!18078623!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32541 invoked from network); 27 Apr 2012 18:52:38 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 18:52:38 -0000
Received: by lboi15 with SMTP id i15so884465lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 11:52:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=4aLpj9L7a0u+16173RlYm9fNDWwMeAXWyLdr5WKj6XU=;
	b=pK5cKrEG6w4Vx+XGqXq7A5DCPq7UPwGml7fCOfyyf7g7YnYcABOnktX0elYZLMl+TS
	1aR9O7llgEtfnmuLQiFbxQfIk1mrZU/NiOl40B9SYmcEXv62RhovBWIOFG70CvuAGun6
	dKecFRCwB1NMysdyIzL0f6VwGRVs6wgkNh/ZU8MZzzPRQR8fMN2elp16Pzzx5wiW0jDB
	6gOye42dxomvFWqs5UKts0XmczQulekkvE3CkHZwPW5RBfRt2tUP/+N7uWLBT7w8jiJP
	pjWEYjHEh5Pmu42iRxjVVmlYSoWW45EjXWeDjp1/ZpVaVs9WiZMB2UyeD422Yezb8m/F
	DlwA==
MIME-Version: 1.0
Received: by 10.112.85.200 with SMTP id j8mr5838341lbz.80.1335552756497; Fri,
	27 Apr 2012 11:52:36 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Fri, 27 Apr 2012 11:52:36 -0700 (PDT)
In-Reply-To: <1335550569.4881.74.camel@dagon.hellion.org.uk>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
	<1335543062.28015.234.camel@zakaz.uk.xensource.com>
	<CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
	<1335550569.4881.74.camel@dagon.hellion.org.uk>
Date: Fri, 27 Apr 2012 14:52:36 -0400
Message-ID: <CAMVU=Qind0vv4hiM-9SikL55MrSM5SohQkknDXLp5+fRLU33GA@mail.gmail.com>
From: Misiu Godfrey <misiu.godfrey@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============3607955890781570681=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3607955890781570681==
Content-Type: multipart/alternative; boundary=bcaec554d60ca13c2604bead9bb3

--bcaec554d60ca13c2604bead9bb3
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 27, 2012 at 2:16 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> >
> > As a workaround you could set QEMU_REMOTE in .config (or edit Config.mk)
> > to refer to git://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git
> > instead of the non-staging version.
>
>
I have implemented the workaround and everything is compiling fine so far
as I can see.  Thanks for your help, and I will keep an eye out for some
sort of re-synch in the future.

Misiu.

--bcaec554d60ca13c2604bead9bb3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, Apr 27, 2012 =
at 2:16 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbe=
ll@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt;<br>&gt; As a workaround you could set Q=
EMU_REMOTE in .config (or edit Config.mk)<br>&gt; to refer to git://<a href=
=3D"http://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git" target=
=3D"_blank">xenbits.xensource.com/staging/qemu-xen-4.1-testing.git</a><br>
&gt; instead of the non-staging version.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div>=A0</div></div>I have implemented the workaround and everything is =
compiling fine so far as I can see. =A0Thanks for your help, and I will kee=
p an eye out for some sort of re-synch in the future.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Misiu.</div=
>

--bcaec554d60ca13c2604bead9bb3--


--===============3607955890781570681==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3607955890781570681==--


From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpf-0001Lj-4P; Mon, 30 Apr 2012 08:19:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNoG9-0005Ju-Q7
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 16:43:06 +0000
Received: from [85.158.143.99:20592] by server-1.bemta-4.messagelabs.com id
	9C/01-20925-99CCA9F4; Fri, 27 Apr 2012 16:43:05 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335544983!18554629!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16640 invoked from network); 27 Apr 2012 16:43:03 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 16:43:03 -0000
Received: by lboi15 with SMTP id i15so785500lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 09:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type; bh=g1wYXtFZATd5lsANtMm0l5WFPUQQhlALlGg83f1dQDQ=;
	b=NAkCWYzoLWcJ6xqxw+Yj5kp3ne436+hBTtX90+Zk2y2EQr0LS1lGgROCwOsgJPHeM7
	WiPxlZWQDXntgnC2cUD3WIGxdiIrMAj52vIcSauefKUKF901gM4ZUtwceLsdKVXLt265
	7M4/PFYnZf/PjIH8NuY6uAv3Gv6qWpFpdzJu/+4rT18eTiigwNKGFvj+Yx6QnFUxROpC
	yUZ1UdiAXkpaSrDOjN9T07yvgwVPnxAQCoQ18Rj+AxPF+tWzKx4L4YkEC0DiejG/Nn4f
	oZANSSZ/0x4gBoZKoIpE4fBB4hYXspZUtBxkaXsUk+mrGb5MZOf9jJB4KdqOT7K3XJhZ
	5edw==
MIME-Version: 1.0
Received: by 10.112.48.6 with SMTP id h6mr5581229lbn.94.1335544982988; Fri, 27
	Apr 2012 09:43:02 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Fri, 27 Apr 2012 09:43:02 -0700 (PDT)
In-Reply-To: <CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
	<1335543062.28015.234.camel@zakaz.uk.xensource.com>
	<CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
Date: Fri, 27 Apr 2012 12:43:02 -0400
Message-ID: <CAMVU=Qhf+Rc17_KzYLfOf-=gMhwLQZnoPFQ-M-3wMyJUeRX4Bw@mail.gmail.com>
From: misiu godfrey <misiu.godfrey@gmail.com>
Cc: xen-devel <xen-devel@lists.xen.org>
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Subject: [Xen-devel] Fwd:  Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 12:41:28 -0400
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
To: Ian Campbell <Ian.Campbell@citrix.com>

On 4/27/12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> If you cd into the ioemu-remote dir then what do:
> 	git show a2d2123a7dfc4d116011d51f48df786a3b853537
> 	git show origin/master
> say?

For the following results I assume "ioemu-remote dir" refers to
"ioemu-remote.tmp, as there is no such directory "ioemu-remote"
present.  My file listing is as shown:

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools# ls
blktap	       debugger  include	   libxen    ocaml     security
vtpm_manager  xenpaging  xm-test
blktap2        examples  ioemu-remote.tmp  libxl     pygrub    sv	
xcutils       xenpmd
check	       firmware  libaio		   Makefile  python    tests	
xenbackendd   xenstat
console        flask	 libfsimage	   memshr    remus     vnet	
xenballoon    xenstore
cross-install  hotplug	 libxc		   misc      Rules.mk  vtpm	 xenmon
   xentrace

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools# cd ioemu-remote.tmp/

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#
git show a2d2123a7dfc4d116011d51f48df786a3b853537
fatal: bad object a2d2123a7dfc4d116011d51f48df786a3b853537

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#
git show origin/master
commit 06d2e688405932841e9a1c27e2eaaef315298a66
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Thu Mar 1 18:58:27 2012 +0000

    qemu-xen: ignore console disconnect events for console/0

    The first console has a different location compared to other PV devices
    (console, rather than device/console/0) and doesn't obey the xenstore
    state protocol. We already special case the first console in con_init
    and con_initialise, we should also do it in con_disconnect.

    This patch should be applied to 4.1 too.

    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    (cherry picked from commit 2503d4d5a29e7af8dffd1e11229e11c1917d2ccf)

diff --git a/hw/xen_console.c b/hw/xen_console.c
index 0a2374c..f036b8d 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -253,6 +253,8 @@ static void con_disconnect(struct XenDevice *xendev)
 {
     struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);

+    if (!xendev->dev)
+        return;
     if (con->chr)
         qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
     xen_be_unbind_evtchn(&con->xendev);
(END)


> What happens if you then run "git fetch origin" in that dir?

"git fetch origin" seems to complete without any feedback, as shown:
root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#
git fetch origin
root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#


> From the top-level what does "make tools/ioemu-dir-force-update" do?

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg# make
tools/ioemu-dir-force-update
make -C tools ioemu-dir-force-update
make[1]: Entering directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'
set -ex; \
	if [ "a2d2123a7dfc4d116011d51f48df786a3b853537" ]; then \
		cd ioemu-remote; \
		git fetch origin; \
		git reset --hard a2d2123a7dfc4d116011d51f48df786a3b853537; \
	fi
+ [ a2d2123a7dfc4d116011d51f48df786a3b853537 ]
+ cd ioemu-remote
cd: 1: can't cd to ioemu-remote
make[1]: *** [ioemu-dir-force-update] Error 2
make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'
make: *** [tools/ioemu-dir-force-update] Error 2
root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg#


> Last resort you could try nuking the ioemu-remote dir and rebuilding.

I removed the ioemu-remote.tmp dir and remade to the same result.

Misiu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:20:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlpf-0001Lj-4P; Mon, 30 Apr 2012 08:19:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1SNoG9-0005Ju-Q7
	for xen-devel@lists.xen.org; Fri, 27 Apr 2012 16:43:06 +0000
Received: from [85.158.143.99:20592] by server-1.bemta-4.messagelabs.com id
	9C/01-20925-99CCA9F4; Fri, 27 Apr 2012 16:43:05 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335544983!18554629!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16640 invoked from network); 27 Apr 2012 16:43:03 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Apr 2012 16:43:03 -0000
Received: by lboi15 with SMTP id i15so785500lbo.32
	for <xen-devel@lists.xen.org>; Fri, 27 Apr 2012 09:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type; bh=g1wYXtFZATd5lsANtMm0l5WFPUQQhlALlGg83f1dQDQ=;
	b=NAkCWYzoLWcJ6xqxw+Yj5kp3ne436+hBTtX90+Zk2y2EQr0LS1lGgROCwOsgJPHeM7
	WiPxlZWQDXntgnC2cUD3WIGxdiIrMAj52vIcSauefKUKF901gM4ZUtwceLsdKVXLt265
	7M4/PFYnZf/PjIH8NuY6uAv3Gv6qWpFpdzJu/+4rT18eTiigwNKGFvj+Yx6QnFUxROpC
	yUZ1UdiAXkpaSrDOjN9T07yvgwVPnxAQCoQ18Rj+AxPF+tWzKx4L4YkEC0DiejG/Nn4f
	oZANSSZ/0x4gBoZKoIpE4fBB4hYXspZUtBxkaXsUk+mrGb5MZOf9jJB4KdqOT7K3XJhZ
	5edw==
MIME-Version: 1.0
Received: by 10.112.48.6 with SMTP id h6mr5581229lbn.94.1335544982988; Fri, 27
	Apr 2012 09:43:02 -0700 (PDT)
Received: by 10.152.3.167 with HTTP; Fri, 27 Apr 2012 09:43:02 -0700 (PDT)
In-Reply-To: <CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
References: <CAMVU=Qi2yNqA3X9HqMgsm8NUUnNm7qgctm_t4Jtgawa0dudBnQ@mail.gmail.com>
	<1335529430.28015.194.camel@zakaz.uk.xensource.com>
	<CAMVU=QiHFJLmwCTU_d1avwfORvjfJrMahJrY+kXS2S5jgzgfyw@mail.gmail.com>
	<1335543062.28015.234.camel@zakaz.uk.xensource.com>
	<CAMVU=Qg3+fConXymt3OiwprrC0uJkz+Y0=thfykVsWratSYRfw@mail.gmail.com>
Date: Fri, 27 Apr 2012 12:43:02 -0400
Message-ID: <CAMVU=Qhf+Rc17_KzYLfOf-=gMhwLQZnoPFQ-M-3wMyJUeRX4Bw@mail.gmail.com>
From: misiu godfrey <misiu.godfrey@gmail.com>
Cc: xen-devel <xen-devel@lists.xen.org>
X-Mailman-Approved-At: Mon, 30 Apr 2012 08:19:40 +0000
Subject: [Xen-devel] Fwd:  Xen-4.1-testing fails to "make tools"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: misiu godfrey <misiu.godfrey@gmail.com>
Date: Fri, 27 Apr 2012 12:41:28 -0400
Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools"
To: Ian Campbell <Ian.Campbell@citrix.com>

On 4/27/12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> If you cd into the ioemu-remote dir then what do:
> 	git show a2d2123a7dfc4d116011d51f48df786a3b853537
> 	git show origin/master
> say?

For the following results I assume "ioemu-remote dir" refers to
"ioemu-remote.tmp, as there is no such directory "ioemu-remote"
present.  My file listing is as shown:

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools# ls
blktap	       debugger  include	   libxen    ocaml     security
vtpm_manager  xenpaging  xm-test
blktap2        examples  ioemu-remote.tmp  libxl     pygrub    sv	
xcutils       xenpmd
check	       firmware  libaio		   Makefile  python    tests	
xenbackendd   xenstat
console        flask	 libfsimage	   memshr    remus     vnet	
xenballoon    xenstore
cross-install  hotplug	 libxc		   misc      Rules.mk  vtpm	 xenmon
   xentrace

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools# cd ioemu-remote.tmp/

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#
git show a2d2123a7dfc4d116011d51f48df786a3b853537
fatal: bad object a2d2123a7dfc4d116011d51f48df786a3b853537

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#
git show origin/master
commit 06d2e688405932841e9a1c27e2eaaef315298a66
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Thu Mar 1 18:58:27 2012 +0000

    qemu-xen: ignore console disconnect events for console/0

    The first console has a different location compared to other PV devices
    (console, rather than device/console/0) and doesn't obey the xenstore
    state protocol. We already special case the first console in con_init
    and con_initialise, we should also do it in con_disconnect.

    This patch should be applied to 4.1 too.

    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    (cherry picked from commit 2503d4d5a29e7af8dffd1e11229e11c1917d2ccf)

diff --git a/hw/xen_console.c b/hw/xen_console.c
index 0a2374c..f036b8d 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -253,6 +253,8 @@ static void con_disconnect(struct XenDevice *xendev)
 {
     struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);

+    if (!xendev->dev)
+        return;
     if (con->chr)
         qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
     xen_be_unbind_evtchn(&con->xendev);
(END)


> What happens if you then run "git fetch origin" in that dir?

"git fetch origin" seems to complete without any feedback, as shown:
root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#
git fetch origin
root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#


> From the top-level what does "make tools/ioemu-dir-force-update" do?

root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg# make
tools/ioemu-dir-force-update
make -C tools ioemu-dir-force-update
make[1]: Entering directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'
set -ex; \
	if [ "a2d2123a7dfc4d116011d51f48df786a3b853537" ]; then \
		cd ioemu-remote; \
		git fetch origin; \
		git reset --hard a2d2123a7dfc4d116011d51f48df786a3b853537; \
	fi
+ [ a2d2123a7dfc4d116011d51f48df786a3b853537 ]
+ cd ioemu-remote
cd: 1: can't cd to ioemu-remote
make[1]: *** [ioemu-dir-force-update] Error 2
make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'
make: *** [tools/ioemu-dir-force-update] Error 2
root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg#


> Last resort you could try nuking the ioemu-remote dir and rebuilding.

I removed the ioemu-remote.tmp dir and remade to the same result.

Misiu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:23:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlsl-0001to-BI; Mon, 30 Apr 2012 08:22:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOlsj-0001ta-FS
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:22:53 +0000
Received: from [85.158.139.83:4944] by server-2.bemta-5.messagelabs.com id
	02/FB-17016-BDB4E9F4; Mon, 30 Apr 2012 08:22:51 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335774170!26055980!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9666 invoked from network); 30 Apr 2012 08:22:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	30 Apr 2012 08:22:50 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U8MfkE032449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 04:22:42 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3U8MZhS011265; Mon, 30 Apr 2012 04:22:36 -0400
Message-ID: <4F9E4BCA.5030604@redhat.com>
Date: Mon, 30 Apr 2012 11:22:34 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com> <4F9D417D.1050105@redhat.com>
	<20120429135227.GC15413@redhat.com>
In-Reply-To: <20120429135227.GC15413@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/29/2012 04:52 PM, Gleb Natapov wrote:
> On Sun, Apr 29, 2012 at 04:26:21PM +0300, Avi Kivity wrote:
> > On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > > > can use one of reserved delivery modes as PV delivery mode. We will
> > > > > disallow guest to trigger it through apic interface, so this will not be
> > > > > part of ABI and can be changed at will.
> > > > >
> > > > 
> > > > I'm not thrilled about this.  Those delivery modes will eventually
> > > > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > > > among implementations.
> > > > 
> > > This is only internal implementation. If they become unreserved we will
> > > use something else.
> > >
> > 
> > Yeah, I'm thinking of that time.  Why do something temporary and fragile?
> > 
> Why is it fragile? Just by unreserving the value Intel will not break
> KVM. Only when KVM will implement apic feature that unreserves the value
> we will have to change internal implementation and use another value,
> but this will be done by the same patch that does unreserving. The
> unreserving may even never happen. 

Some remains of that may leak somewhere.  Why not add an extra
parameter?  Or do something like

kvm_for_each_apic_dest(vcpu, apic_destination) {
      ...
}

That can be reused in both the apic code and pv kick.

> Meanwhile kvm_irq_delivery_to_apic()
> will likely be optimized to use hash for unicast delivery and unhalt
> hypercall will benefit from it immediately.

Overloading delivery mode is not the only way to achieve sharing.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:23:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOlsl-0001to-BI; Mon, 30 Apr 2012 08:22:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1SOlsj-0001ta-FS
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:22:53 +0000
Received: from [85.158.139.83:4944] by server-2.bemta-5.messagelabs.com id
	02/FB-17016-BDB4E9F4; Mon, 30 Apr 2012 08:22:51 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1335774170!26055980!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9666 invoked from network); 30 Apr 2012 08:22:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	30 Apr 2012 08:22:50 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U8MfkE032449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 04:22:42 -0400
Received: from balrog.usersys.redhat.com (dhcp-4-117.tlv.redhat.com
	[10.35.4.117])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3U8MZhS011265; Mon, 30 Apr 2012 04:22:36 -0400
Message-ID: <4F9E4BCA.5030604@redhat.com>
Date: Mon, 30 Apr 2012 11:22:34 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com> <4F9D417D.1050105@redhat.com>
	<20120429135227.GC15413@redhat.com>
In-Reply-To: <20120429135227.GC15413@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/29/2012 04:52 PM, Gleb Natapov wrote:
> On Sun, Apr 29, 2012 at 04:26:21PM +0300, Avi Kivity wrote:
> > On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > > > can use one of reserved delivery modes as PV delivery mode. We will
> > > > > disallow guest to trigger it through apic interface, so this will not be
> > > > > part of ABI and can be changed at will.
> > > > >
> > > > 
> > > > I'm not thrilled about this.  Those delivery modes will eventually
> > > > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > > > among implementations.
> > > > 
> > > This is only internal implementation. If they become unreserved we will
> > > use something else.
> > >
> > 
> > Yeah, I'm thinking of that time.  Why do something temporary and fragile?
> > 
> Why is it fragile? Just by unreserving the value Intel will not break
> KVM. Only when KVM will implement apic feature that unreserves the value
> we will have to change internal implementation and use another value,
> but this will be done by the same patch that does unreserving. The
> unreserving may even never happen. 

Some remains of that may leak somewhere.  Why not add an extra
parameter?  Or do something like

kvm_for_each_apic_dest(vcpu, apic_destination) {
      ...
}

That can be reused in both the apic code and pv kick.

> Meanwhile kvm_irq_delivery_to_apic()
> will likely be optimized to use hash for unicast delivery and unhalt
> hypercall will benefit from it immediately.

Overloading delivery mode is not the only way to achieve sharing.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:38:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOm7H-0002Oh-0R; Mon, 30 Apr 2012 08:37:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOm7G-0002Oc-8E
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:37:54 +0000
Received: from [193.109.254.147:39350] by server-5.bemta-14.messagelabs.com id
	EF/75-30733-16F4E9F4; Mon, 30 Apr 2012 08:37:53 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335775071!6884073!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7973 invoked from network); 30 Apr 2012 08:37:52 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Apr 2012 08:37:52 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOm7C-0001eX-W2
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 01:37:50 -0700
Date: Mon, 30 Apr 2012 01:37:50 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335775070971-5675394.post@n5.nabble.com>
In-Reply-To: <1335537402.28015.227.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
	<1335536869945-5670447.post@n5.nabble.com>
	<1335537402.28015.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
> On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
>> Lucid disk1 is ext4 partition, on old xen-unstable test build was
>> working,
> 
> Do you know what changeset that was?
> 
>> also without change of python prefix, monday I retry with full clean
>> build
>> and also to latest changeset
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same
error.
Last working changeset was 25070, after that I do mainly qemu upstream test.

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675394.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:38:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOm7H-0002Oh-0R; Mon, 30 Apr 2012 08:37:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOm7G-0002Oc-8E
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:37:54 +0000
Received: from [193.109.254.147:39350] by server-5.bemta-14.messagelabs.com id
	EF/75-30733-16F4E9F4; Mon, 30 Apr 2012 08:37:53 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335775071!6884073!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7973 invoked from network); 30 Apr 2012 08:37:52 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Apr 2012 08:37:52 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOm7C-0001eX-W2
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 01:37:50 -0700
Date: Mon, 30 Apr 2012 01:37:50 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335775070971-5675394.post@n5.nabble.com>
In-Reply-To: <1335537402.28015.227.camel@zakaz.uk.xensource.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
	<1335536869945-5670447.post@n5.nabble.com>
	<1335537402.28015.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ian Campbell-10 wrote
> 
> On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
>> Lucid disk1 is ext4 partition, on old xen-unstable test build was
>> working,
> 
> Do you know what changeset that was?
> 
>> also without change of python prefix, monday I retry with full clean
>> build
>> and also to latest changeset
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same
error.
Last working changeset was 25070, after that I do mainly qemu upstream test.

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675394.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOm81-0002RH-Dr; Mon, 30 Apr 2012 08:38:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOm7z-0002R5-TD
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:38:40 +0000
Received: from [85.158.143.99:11523] by server-1.bemta-4.messagelabs.com id
	AD/BA-20925-F8F4E9F4; Mon, 30 Apr 2012 08:38:39 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335775117!25801316!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9595 invoked from network); 30 Apr 2012 08:38:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	30 Apr 2012 08:38:37 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U8cRGl008882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 04:38:28 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3U8cQoP008339; Mon, 30 Apr 2012 04:38:27 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 8D2B018D495; Mon, 30 Apr 2012 11:38:25 +0300 (IDT)
Date: Mon, 30 Apr 2012 11:38:25 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120430083825.GD15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com> <4F9D417D.1050105@redhat.com>
	<20120429135227.GC15413@redhat.com> <4F9E4BCA.5030604@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9E4BCA.5030604@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 11:22:34AM +0300, Avi Kivity wrote:
> On 04/29/2012 04:52 PM, Gleb Natapov wrote:
> > On Sun, Apr 29, 2012 at 04:26:21PM +0300, Avi Kivity wrote:
> > > On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > > > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > > > > can use one of reserved delivery modes as PV delivery mode. We will
> > > > > > disallow guest to trigger it through apic interface, so this will not be
> > > > > > part of ABI and can be changed at will.
> > > > > >
> > > > > 
> > > > > I'm not thrilled about this.  Those delivery modes will eventually
> > > > > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > > > > among implementations.
> > > > > 
> > > > This is only internal implementation. If they become unreserved we will
> > > > use something else.
> > > >
> > > 
> > > Yeah, I'm thinking of that time.  Why do something temporary and fragile?
> > > 
> > Why is it fragile? Just by unreserving the value Intel will not break
> > KVM. Only when KVM will implement apic feature that unreserves the value
> > we will have to change internal implementation and use another value,
> > but this will be done by the same patch that does unreserving. The
> > unreserving may even never happen. 
> 
> Some remains of that may leak somewhere.
I do not see where. APIC code should #GP if a guest attempts to set
reserved values through APIC interface, or at least ignore them.

>                                           Why not add an extra
> parameter?
Yes, we can add extra parameter to "struct kvm_lapic_irq" and propagate it to
__apic_accept_irq(). We can do that now, or when Intel unreserve all
reserved values. I prefer the later since I do not believe it will
happen in observable feature.

>              Or do something like
> 
> kvm_for_each_apic_dest(vcpu, apic_destination) {
>       ...
> }
> 
> That can be reused in both the apic code and pv kick.
> 
That's exactly what kvm_irq_delivery_to_apic() is.

> > Meanwhile kvm_irq_delivery_to_apic()
> > will likely be optimized to use hash for unicast delivery and unhalt
> > hypercall will benefit from it immediately.
> 
> Overloading delivery mode is not the only way to achieve sharing.
> 
It is simplest and most straightforward with no demonstratable drawbacks :)
Adding parameter to "struct kvm_lapic_irq" is next best thing.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 08:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 08:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOm81-0002RH-Dr; Mon, 30 Apr 2012 08:38:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOm7z-0002R5-TD
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 08:38:40 +0000
Received: from [85.158.143.99:11523] by server-1.bemta-4.messagelabs.com id
	AD/BA-20925-F8F4E9F4; Mon, 30 Apr 2012 08:38:39 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1335775117!25801316!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9595 invoked from network); 30 Apr 2012 08:38:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	30 Apr 2012 08:38:37 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U8cRGl008882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 04:38:28 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q3U8cQoP008339; Mon, 30 Apr 2012 04:38:27 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 8D2B018D495; Mon, 30 Apr 2012 11:38:25 +0300 (IDT)
Date: Mon, 30 Apr 2012 11:38:25 +0300
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120430083825.GD15413@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com> <4F9D3F8B.9010805@redhat.com>
	<20120429132030.GB15413@redhat.com> <4F9D417D.1050105@redhat.com>
	<20120429135227.GC15413@redhat.com> <4F9E4BCA.5030604@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F9E4BCA.5030604@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 11:22:34AM +0300, Avi Kivity wrote:
> On 04/29/2012 04:52 PM, Gleb Natapov wrote:
> > On Sun, Apr 29, 2012 at 04:26:21PM +0300, Avi Kivity wrote:
> > > On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > > > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > > > > can use one of reserved delivery modes as PV delivery mode. We will
> > > > > > disallow guest to trigger it through apic interface, so this will not be
> > > > > > part of ABI and can be changed at will.
> > > > > >
> > > > > 
> > > > > I'm not thrilled about this.  Those delivery modes will eventually
> > > > > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > > > > among implementations.
> > > > > 
> > > > This is only internal implementation. If they become unreserved we will
> > > > use something else.
> > > >
> > > 
> > > Yeah, I'm thinking of that time.  Why do something temporary and fragile?
> > > 
> > Why is it fragile? Just by unreserving the value Intel will not break
> > KVM. Only when KVM will implement apic feature that unreserves the value
> > we will have to change internal implementation and use another value,
> > but this will be done by the same patch that does unreserving. The
> > unreserving may even never happen. 
> 
> Some remains of that may leak somewhere.
I do not see where. APIC code should #GP if a guest attempts to set
reserved values through APIC interface, or at least ignore them.

>                                           Why not add an extra
> parameter?
Yes, we can add extra parameter to "struct kvm_lapic_irq" and propagate it to
__apic_accept_irq(). We can do that now, or when Intel unreserve all
reserved values. I prefer the later since I do not believe it will
happen in observable feature.

>              Or do something like
> 
> kvm_for_each_apic_dest(vcpu, apic_destination) {
>       ...
> }
> 
> That can be reused in both the apic code and pv kick.
> 
That's exactly what kvm_irq_delivery_to_apic() is.

> > Meanwhile kvm_irq_delivery_to_apic()
> > will likely be optimized to use hash for unicast delivery and unhalt
> > hypercall will benefit from it immediately.
> 
> Overloading delivery mode is not the only way to achieve sharing.
> 
It is simplest and most straightforward with no demonstratable drawbacks :)
Adding parameter to "struct kvm_lapic_irq" is next best thing.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:11:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOmdb-0003Sp-Ab; Mon, 30 Apr 2012 09:11:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOmda-0003Se-CQ
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 09:11:18 +0000
Received: from [193.109.254.147:24427] by server-11.bemta-14.messagelabs.com
	id 6F/9D-05858-5375E9F4; Mon, 30 Apr 2012 09:11:17 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335777060!6976867!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22805 invoked from network); 30 Apr 2012 09:11:02 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Apr 2012 09:11:02 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOmdH-0005dS-Qs
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 02:10:59 -0700
Date: Mon, 30 Apr 2012 02:10:59 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335777059816-5675450.post@n5.nabble.com>
In-Reply-To: <1335775070971-5675394.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
	<1335536869945-5670447.post@n5.nabble.com>
	<1335537402.28015.227.camel@zakaz.uk.xensource.com>
	<1335775070971-5675394.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Ian Campbell-10 wrote
>> 
>> On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
>>> Lucid disk1 is ext4 partition, on old xen-unstable test build was
>>> working,
>> 
>> Do you know what changeset that was?
>> 
>>> also without change of python prefix, monday I retry with full clean
>>> build
>>> and also to latest changeset
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
>> 
> I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same
> error.
> Last working changeset was 25070, after that I do mainly qemu upstream
> test.
> 
I tried also pv-grub but it doesn't working.
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
kernel is not a bzImage: Invalid kernel
Daemon running with PID 2683

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675450.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:11:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOmdb-0003Sp-Ab; Mon, 30 Apr 2012 09:11:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOmda-0003Se-CQ
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 09:11:18 +0000
Received: from [193.109.254.147:24427] by server-11.bemta-14.messagelabs.com
	id 6F/9D-05858-5375E9F4; Mon, 30 Apr 2012 09:11:17 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1335777060!6976867!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22805 invoked from network); 30 Apr 2012 09:11:02 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Apr 2012 09:11:02 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1SOmdH-0005dS-Qs
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 02:10:59 -0700
Date: Mon, 30 Apr 2012 02:10:59 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1335777059816-5675450.post@n5.nabble.com>
In-Reply-To: <1335775070971-5675394.post@n5.nabble.com>
References: <1335435995180-5667212.post@n5.nabble.com>
	<1335441317.28015.127.camel@zakaz.uk.xensource.com>
	<20120427082114.GA28258@bloms.de> <4F9A5C79.2090604@eu.citrix.com>
	<1335517688.28015.180.camel@zakaz.uk.xensource.com>
	<1335528921825-5670111.post@n5.nabble.com>
	<1335532771.28015.209.camel@zakaz.uk.xensource.com>
	<1335536869945-5670447.post@n5.nabble.com>
	<1335537402.28015.227.camel@zakaz.uk.xensource.com>
	<1335775070971-5675394.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Fantu wrote
> 
> 
> Ian Campbell-10 wrote
>> 
>> On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
>>> Lucid disk1 is ext4 partition, on old xen-unstable test build was
>>> working,
>> 
>> Do you know what changeset that was?
>> 
>>> also without change of python prefix, monday I retry with full clean
>>> build
>>> and also to latest changeset
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
>> 
> I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same
> error.
> Last working changeset was 25070, after that I do mainly qemu upstream
> test.
> 
I tried also pv-grub but it doesn't working.
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
kernel is not a bzImage: Invalid kernel
Daemon running with PID 2683

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675450.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:16:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOmiX-0003kQ-4s; Mon, 30 Apr 2012 09:16:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SOmiW-0003kJ-1q
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 09:16:24 +0000
Received: from [85.158.143.99:53874] by server-2.bemta-4.messagelabs.com id
	35/BA-17550-7685E9F4; Mon, 30 Apr 2012 09:16:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335777381!24920510!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1842 invoked from network); 30 Apr 2012 09:16:22 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 09:16:22 -0000
Received: by qaeb19 with SMTP id b19so703774qae.11
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 02:16:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fsY+J+EaB5URKzt40XLneRddKTEtThgyEFm+ruLd5PU=;
	b=k4+sPhL64XgzODXDO6e79tYZk3aK9BQ3nh759y5z/JxsOtXmmkE3HPfVW91lecdbK7
	oukf2l3Tm6hdYYrmsVY3LLxQyOoCV7dpxHjSPi2RuBQu1IbFOp/6aD+WlDXxrae+tsE8
	zlP/rCapY97uBnOCZk6u0lrKbPSoSRldOW2o4RZ/ixX4bJQZFeRnIPzpB4b9OE9XFyGm
	sxDwy+ixREwpUHkYNAbMlcQ84z9ucB4fyM/LLdRjblUtUuUXNnctLHAZa+CxQGEvXuoc
	vE+KgZgjBpkfygu0jiBtinSqfYW2DAix/l3eEJxplVTQ5MyVjVYa3nuTYg9sLie9+K+4
	sozg==
MIME-Version: 1.0
Received: by 10.224.185.204 with SMTP id cp12mr11862592qab.42.1335777381324;
	Mon, 30 Apr 2012 02:16:21 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Mon, 30 Apr 2012 02:16:21 -0700 (PDT)
In-Reply-To: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
Date: Mon, 30 Apr 2012 10:16:21 +0100
X-Google-Sender-Auth: GS0R_ws8PfHVxJZF_4AQo1Ppxjk
Message-ID: <CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: wang zhihao <accept.acm@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 29, 2012 at 4:21 PM, wang zhihao <accept.acm@gmail.com> wrote:
> Hi , All
>
> I 'm a green hand and interested in open source development. I have a gen=
eral question =93How to test my patch before I post it to public?=94 Hope y=
ou guys give me some suggestions. : )
>
> Firstly, I can re-compile the code, to assure no syntax error. However,I =
don't know how to test my patch's function is right or not. Some software r=
equires unit test for each function. Is there anything similar in xen proje=
ct?

There is no unit testing for Xen.  What you need to test really
depends on what your patch is doing.  The main goal is to exercise the
code you've just added or changed: try to put it in different
combinations to make sure that it works as you expect.  Try to break
it, really. :-)

If you're just tweaking a simple option in the xl config file, then
you need to test a few different combinations to make sure that all
the reasonable combinations work.  If you're changing the locks in the
memory management code in the hypervisor, then you need to run a bunch
of benchmarks that exercise that code, probably for several hours.

If you post your patch to the list (with an appropriate description)
we may be able to give you some suggestions.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:16:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOmiX-0003kQ-4s; Mon, 30 Apr 2012 09:16:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SOmiW-0003kJ-1q
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 09:16:24 +0000
Received: from [85.158.143.99:53874] by server-2.bemta-4.messagelabs.com id
	35/BA-17550-7685E9F4; Mon, 30 Apr 2012 09:16:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1335777381!24920510!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1842 invoked from network); 30 Apr 2012 09:16:22 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 09:16:22 -0000
Received: by qaeb19 with SMTP id b19so703774qae.11
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 02:16:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fsY+J+EaB5URKzt40XLneRddKTEtThgyEFm+ruLd5PU=;
	b=k4+sPhL64XgzODXDO6e79tYZk3aK9BQ3nh759y5z/JxsOtXmmkE3HPfVW91lecdbK7
	oukf2l3Tm6hdYYrmsVY3LLxQyOoCV7dpxHjSPi2RuBQu1IbFOp/6aD+WlDXxrae+tsE8
	zlP/rCapY97uBnOCZk6u0lrKbPSoSRldOW2o4RZ/ixX4bJQZFeRnIPzpB4b9OE9XFyGm
	sxDwy+ixREwpUHkYNAbMlcQ84z9ucB4fyM/LLdRjblUtUuUXNnctLHAZa+CxQGEvXuoc
	vE+KgZgjBpkfygu0jiBtinSqfYW2DAix/l3eEJxplVTQ5MyVjVYa3nuTYg9sLie9+K+4
	sozg==
MIME-Version: 1.0
Received: by 10.224.185.204 with SMTP id cp12mr11862592qab.42.1335777381324;
	Mon, 30 Apr 2012 02:16:21 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Mon, 30 Apr 2012 02:16:21 -0700 (PDT)
In-Reply-To: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
Date: Mon, 30 Apr 2012 10:16:21 +0100
X-Google-Sender-Auth: GS0R_ws8PfHVxJZF_4AQo1Ppxjk
Message-ID: <CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: wang zhihao <accept.acm@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Apr 29, 2012 at 4:21 PM, wang zhihao <accept.acm@gmail.com> wrote:
> Hi , All
>
> I 'm a green hand and interested in open source development. I have a gen=
eral question =93How to test my patch before I post it to public?=94 Hope y=
ou guys give me some suggestions. : )
>
> Firstly, I can re-compile the code, to assure no syntax error. However,I =
don't know how to test my patch's function is right or not. Some software r=
equires unit test for each function. Is there anything similar in xen proje=
ct?

There is no unit testing for Xen.  What you need to test really
depends on what your patch is doing.  The main goal is to exercise the
code you've just added or changed: try to put it in different
combinations to make sure that it works as you expect.  Try to break
it, really. :-)

If you're just tweaking a simple option in the xl config file, then
you need to test a few different combinations to make sure that all
the reasonable combinations work.  If you're changing the locks in the
memory management code in the hypervisor, then you need to run a bunch
of benchmarks that exercise that code, probably for several hours.

If you post your patch to the list (with an appropriate description)
we may be able to give you some suggestions.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOn3k-0004I2-SF; Mon, 30 Apr 2012 09:38:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SOn3k-0004Hx-3M
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 09:38:20 +0000
Received: from [85.158.139.83:48004] by server-8.bemta-5.messagelabs.com id
	20/18-26964-B8D5E9F4; Mon, 30 Apr 2012 09:38:19 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335778696!25996492!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17867 invoked from network); 30 Apr 2012 09:38:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	30 Apr 2012 09:38:17 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U9cBOF015474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 05:38:11 -0400
Received: from redhat.com (vpn-202-127.tlv.redhat.com [10.35.202.127])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q3U9c3aZ005052; Mon, 30 Apr 2012 05:38:05 -0400
Date: Mon, 30 Apr 2012 12:38:13 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120430093811.GC5414@redhat.com>
References: <20120429101019.GA21165@redhat.com>
	<20120430084319.GE15413@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430084319.GE15413@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org,
	devel@linuxdriverproject.org, davej@redhat.com
Subject: Re: [Xen-devel] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote:
> On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote:
> > The following makes 'x86info -r' dump kvm cpu ids
> > (signature+features) when running in a vm.
> > 
> > On the guest we see the signature and the features:
> > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> > 
> > On the host it just adds a couple of zero lines:
> > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > 
> This is too KVM specific.

That's what I have. I scratch my own itch.

> Other hypervisors may use more cpuid leafs.

But not less so no harm's done.

> As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid
> leaf available. Haven't checked Xen or VMWare.

I don't think guessing at the CPU behaviour from linux source
is the right thing to do.

I Cc'd some addresses found in MAINTAINERS in the linux
kernel. This will give more people the opportunity
to ask for their stuff to be added, if they care.

> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > 
> > ---
> > 
> > Dave - not sure whether there's a mailing list for x86info.
> > The patch is on top of the master branch in
> > git://git.codemonkey.org.uk/x86info.git
> > 
> > Thanks!
> > 
> > diff --git a/x86info.c b/x86info.c
> > index 22c4734..dee5ed1 100644
> > --- a/x86info.c
> > +++ b/x86info.c
> > @@ -44,6 +44,7 @@ static void display_detailed_info(struct cpudata *cpu)
> >  
> >  		if (cpu->maxei2 >=0xC0000000)
> >  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> > +		dump_raw_cpuid(cpu->number, 0x40000000, 0x40000001);
> >  	}
> >  
> >  	if (show_cacheinfo) {
> 
> --
> 			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOn3k-0004I2-SF; Mon, 30 Apr 2012 09:38:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SOn3k-0004Hx-3M
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 09:38:20 +0000
Received: from [85.158.139.83:48004] by server-8.bemta-5.messagelabs.com id
	20/18-26964-B8D5E9F4; Mon, 30 Apr 2012 09:38:19 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1335778696!25996492!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExMzY=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17867 invoked from network); 30 Apr 2012 09:38:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	30 Apr 2012 09:38:17 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U9cBOF015474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 05:38:11 -0400
Received: from redhat.com (vpn-202-127.tlv.redhat.com [10.35.202.127])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q3U9c3aZ005052; Mon, 30 Apr 2012 05:38:05 -0400
Date: Mon, 30 Apr 2012 12:38:13 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120430093811.GC5414@redhat.com>
References: <20120429101019.GA21165@redhat.com>
	<20120430084319.GE15413@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430084319.GE15413@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org,
	devel@linuxdriverproject.org, davej@redhat.com
Subject: Re: [Xen-devel] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote:
> On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote:
> > The following makes 'x86info -r' dump kvm cpu ids
> > (signature+features) when running in a vm.
> > 
> > On the guest we see the signature and the features:
> > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> > 
> > On the host it just adds a couple of zero lines:
> > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > 
> This is too KVM specific.

That's what I have. I scratch my own itch.

> Other hypervisors may use more cpuid leafs.

But not less so no harm's done.

> As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid
> leaf available. Haven't checked Xen or VMWare.

I don't think guessing at the CPU behaviour from linux source
is the right thing to do.

I Cc'd some addresses found in MAINTAINERS in the linux
kernel. This will give more people the opportunity
to ask for their stuff to be added, if they care.

> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > 
> > ---
> > 
> > Dave - not sure whether there's a mailing list for x86info.
> > The patch is on top of the master branch in
> > git://git.codemonkey.org.uk/x86info.git
> > 
> > Thanks!
> > 
> > diff --git a/x86info.c b/x86info.c
> > index 22c4734..dee5ed1 100644
> > --- a/x86info.c
> > +++ b/x86info.c
> > @@ -44,6 +44,7 @@ static void display_detailed_info(struct cpudata *cpu)
> >  
> >  		if (cpu->maxei2 >=0xC0000000)
> >  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> > +		dump_raw_cpuid(cpu->number, 0x40000000, 0x40000001);
> >  	}
> >  
> >  	if (show_cacheinfo) {
> 
> --
> 			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOn6m-0004QF-EJ; Mon, 30 Apr 2012 09:41:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOn6k-0004Q5-Uj
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 09:41:27 +0000
Received: from [193.109.254.147:21012] by server-6.bemta-14.messagelabs.com id
	F4/EB-02047-64E5E9F4; Mon, 30 Apr 2012 09:41:26 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335778884!6951903!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31828 invoked from network); 30 Apr 2012 09:41:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	30 Apr 2012 09:41:25 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U9fM1q015726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 05:41:22 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3U9fK3m024613; Mon, 30 Apr 2012 05:41:21 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 03A6318D495; Mon, 30 Apr 2012 12:41:20 +0300 (IDT)
Date: Mon, 30 Apr 2012 12:41:19 +0300
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20120430094119.GI15413@redhat.com>
References: <20120429101019.GA21165@redhat.com>
	<20120430084319.GE15413@redhat.com>
	<20120430093811.GC5414@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430093811.GC5414@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org,
	devel@linuxdriverproject.org, davej@redhat.com
Subject: Re: [Xen-devel] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 12:38:13PM +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote:
> > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote:
> > > The following makes 'x86info -r' dump kvm cpu ids
> > > (signature+features) when running in a vm.
> > > 
> > > On the guest we see the signature and the features:
> > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> > > 
> > > On the host it just adds a couple of zero lines:
> > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > > 
> > This is too KVM specific.
> 
> That's what I have. I scratch my own itch.
> 
> > Other hypervisors may use more cpuid leafs.
> 
> But not less so no harm's done.
> 
> > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid
> > leaf available. Haven't checked Xen or VMWare.
> 
> I don't think guessing at the CPU behaviour from linux source
> is the right thing to do.
> 
That is guessing from Hyper-V specification. The best kind of guess.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff542700%28v=vs.85%29.aspx

> I Cc'd some addresses found in MAINTAINERS in the linux
> kernel. This will give more people the opportunity
> to ask for their stuff to be added, if they care.
> 
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > 
> > > ---
> > > 
> > > Dave - not sure whether there's a mailing list for x86info.
> > > The patch is on top of the master branch in
> > > git://git.codemonkey.org.uk/x86info.git
> > > 
> > > Thanks!
> > > 
> > > diff --git a/x86info.c b/x86info.c
> > > index 22c4734..dee5ed1 100644
> > > --- a/x86info.c
> > > +++ b/x86info.c
> > > @@ -44,6 +44,7 @@ static void display_detailed_info(struct cpudata *cpu)
> > >  
> > >  		if (cpu->maxei2 >=0xC0000000)
> > >  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> > > +		dump_raw_cpuid(cpu->number, 0x40000000, 0x40000001);
> > >  	}
> > >  
> > >  	if (show_cacheinfo) {
> > 
> > --
> > 			Gleb.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 09:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 09:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOn6m-0004QF-EJ; Mon, 30 Apr 2012 09:41:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOn6k-0004Q5-Uj
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 09:41:27 +0000
Received: from [193.109.254.147:21012] by server-6.bemta-14.messagelabs.com id
	F4/EB-02047-64E5E9F4; Mon, 30 Apr 2012 09:41:26 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1335778884!6951903!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31828 invoked from network); 30 Apr 2012 09:41:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	30 Apr 2012 09:41:25 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3U9fM1q015726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 05:41:22 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3U9fK3m024613; Mon, 30 Apr 2012 05:41:21 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 03A6318D495; Mon, 30 Apr 2012 12:41:20 +0300 (IDT)
Date: Mon, 30 Apr 2012 12:41:19 +0300
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20120430094119.GI15413@redhat.com>
References: <20120429101019.GA21165@redhat.com>
	<20120430084319.GE15413@redhat.com>
	<20120430093811.GC5414@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430093811.GC5414@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org,
	devel@linuxdriverproject.org, davej@redhat.com
Subject: Re: [Xen-devel] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 12:38:13PM +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote:
> > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote:
> > > The following makes 'x86info -r' dump kvm cpu ids
> > > (signature+features) when running in a vm.
> > > 
> > > On the guest we see the signature and the features:
> > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> > > 
> > > On the host it just adds a couple of zero lines:
> > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
> > > 
> > This is too KVM specific.
> 
> That's what I have. I scratch my own itch.
> 
> > Other hypervisors may use more cpuid leafs.
> 
> But not less so no harm's done.
> 
> > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid
> > leaf available. Haven't checked Xen or VMWare.
> 
> I don't think guessing at the CPU behaviour from linux source
> is the right thing to do.
> 
That is guessing from Hyper-V specification. The best kind of guess.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff542700%28v=vs.85%29.aspx

> I Cc'd some addresses found in MAINTAINERS in the linux
> kernel. This will give more people the opportunity
> to ask for their stuff to be added, if they care.
> 
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > 
> > > ---
> > > 
> > > Dave - not sure whether there's a mailing list for x86info.
> > > The patch is on top of the master branch in
> > > git://git.codemonkey.org.uk/x86info.git
> > > 
> > > Thanks!
> > > 
> > > diff --git a/x86info.c b/x86info.c
> > > index 22c4734..dee5ed1 100644
> > > --- a/x86info.c
> > > +++ b/x86info.c
> > > @@ -44,6 +44,7 @@ static void display_detailed_info(struct cpudata *cpu)
> > >  
> > >  		if (cpu->maxei2 >=0xC0000000)
> > >  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> > > +		dump_raw_cpuid(cpu->number, 0x40000000, 0x40000001);
> > >  	}
> > >  
> > >  	if (show_cacheinfo) {
> > 
> > --
> > 			Gleb.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 12:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 12:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOpGp-00063v-VR; Mon, 30 Apr 2012 11:59:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SOpGp-00063q-2K
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 11:59:59 +0000
Received: from [85.158.143.99:17728] by server-3.bemta-4.messagelabs.com id
	C3/C0-05853-EBE7E9F4; Mon, 30 Apr 2012 11:59:58 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335787195!25875317!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzEwOTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22200 invoked from network); 30 Apr 2012 11:59:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Apr 2012 11:59:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 838732AEB
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 14:59:54 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5B9B02005D; Mon, 30 Apr 2012 14:59:54 +0300 (EEST)
Date: Mon, 30 Apr 2012 14:59:54 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120430115954.GL2058@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] Virtualization overhead benchmark/comparison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Interesting virtualization overhead benchmark comparison between
Native/baremetal, Xen4.1 on Ubuntu 11.10, XenServer 6.0, RHEV3 (KVM), Vsphere5, Hyper-V:

http://blog.exceliance.fr/2012/04/24/hypervisors-virtual-network-performance-comparison-from-a-virtualized-load-balancer-point-of-view/

Focusing on haproxy loadbalancer workload.. so a lot of network IO.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 12:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 12:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOpGp-00063v-VR; Mon, 30 Apr 2012 11:59:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SOpGp-00063q-2K
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 11:59:59 +0000
Received: from [85.158.143.99:17728] by server-3.bemta-4.messagelabs.com id
	C3/C0-05853-EBE7E9F4; Mon, 30 Apr 2012 11:59:58 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-216.messagelabs.com!1335787195!25875317!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzEwOTE=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22200 invoked from network); 30 Apr 2012 11:59:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Apr 2012 11:59:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 838732AEB
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 14:59:54 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5B9B02005D; Mon, 30 Apr 2012 14:59:54 +0300 (EEST)
Date: Mon, 30 Apr 2012 14:59:54 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120430115954.GL2058@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] Virtualization overhead benchmark/comparison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Interesting virtualization overhead benchmark comparison between
Native/baremetal, Xen4.1 on Ubuntu 11.10, XenServer 6.0, RHEV3 (KVM), Vsphere5, Hyper-V:

http://blog.exceliance.fr/2012/04/24/hypervisors-virtual-network-performance-comparison-from-a-virtualized-load-balancer-point-of-view/

Focusing on haproxy loadbalancer workload.. so a lot of network IO.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:08:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrG6-0007aG-4N; Mon, 30 Apr 2012 14:07:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SOrG4-0007Zg-JJ
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:07:20 +0000
Received: from [85.158.143.35:5953] by server-3.bemta-4.messagelabs.com id
	74/A8-05853-79C9E9F4; Mon, 30 Apr 2012 14:07:19 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335794837!12147447!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18936 invoked from network); 30 Apr 2012 14:07:18 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:07:18 -0000
Received: by bkty15 with SMTP id y15so2383907bkt.32
	for <multiple recipients>; Mon, 30 Apr 2012 07:07:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=u88rlYbvqAmT/KH1+3YrAFV0pVnmnf/DinTh0/GwT30=;
	b=vbTjVOfMYHWs0AhQsEMnJtSY7HTLnXOASGrUYRKc9g6ZWp6WY7GzwlckznBnDYh7Ki
	9hzEDmHrX8/q3ObrqxzvffHjiCVUyJ0+E0/Kjbe3d6Sloj7ubKGMtY26th6nyJIU5hY3
	Ooae45n7iYqAqL1Fks/wF1p5T/wSpHCUWpWsds8Jn/6jWIgTXFKaiIQ4NUzBYrDpNQmf
	D3X51nwDqzv7vmKAp8UqPofnV9FfCOfMqpjaGF1jEPjDWKUiWxyP5DSr0WYxlLR8dJKv
	cRy9djQ9W6NmzvVRnSvhLck7M4Qv7UTusKmkglRNtR4y4gj0As0tDtjo1velGep3tFqs
	fN0g==
Received: by 10.205.133.210 with SMTP id hz18mr7016487bkc.117.1335794837078;
	Mon, 30 Apr 2012 07:07:17 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id h18sm27243851bkh.8.2012.04.30.07.07.15
	(version=SSLv3 cipher=OTHER); Mon, 30 Apr 2012 07:07:15 -0700 (PDT)
Message-ID: <4F9E9C91.50403@xen.org>
Date: Mon, 30 Apr 2012 15:07:13 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-api@lists.xen.org, xen-arm@lists.xen.org, 
 xen-devel@lists.xen.org
Subject: [Xen-devel] Regarding a XenDev Day at XenSummit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,
we had an overwhelming vote for a 1/2 day invite only DevDay on the 
Sunday before XenSummit. I will look at logistics and then get back to you.
Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:08:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrG6-0007aG-4N; Mon, 30 Apr 2012 14:07:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SOrG4-0007Zg-JJ
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:07:20 +0000
Received: from [85.158.143.35:5953] by server-3.bemta-4.messagelabs.com id
	74/A8-05853-79C9E9F4; Mon, 30 Apr 2012 14:07:19 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1335794837!12147447!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18936 invoked from network); 30 Apr 2012 14:07:18 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:07:18 -0000
Received: by bkty15 with SMTP id y15so2383907bkt.32
	for <multiple recipients>; Mon, 30 Apr 2012 07:07:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=u88rlYbvqAmT/KH1+3YrAFV0pVnmnf/DinTh0/GwT30=;
	b=vbTjVOfMYHWs0AhQsEMnJtSY7HTLnXOASGrUYRKc9g6ZWp6WY7GzwlckznBnDYh7Ki
	9hzEDmHrX8/q3ObrqxzvffHjiCVUyJ0+E0/Kjbe3d6Sloj7ubKGMtY26th6nyJIU5hY3
	Ooae45n7iYqAqL1Fks/wF1p5T/wSpHCUWpWsds8Jn/6jWIgTXFKaiIQ4NUzBYrDpNQmf
	D3X51nwDqzv7vmKAp8UqPofnV9FfCOfMqpjaGF1jEPjDWKUiWxyP5DSr0WYxlLR8dJKv
	cRy9djQ9W6NmzvVRnSvhLck7M4Qv7UTusKmkglRNtR4y4gj0As0tDtjo1velGep3tFqs
	fN0g==
Received: by 10.205.133.210 with SMTP id hz18mr7016487bkc.117.1335794837078;
	Mon, 30 Apr 2012 07:07:17 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id h18sm27243851bkh.8.2012.04.30.07.07.15
	(version=SSLv3 cipher=OTHER); Mon, 30 Apr 2012 07:07:15 -0700 (PDT)
Message-ID: <4F9E9C91.50403@xen.org>
Date: Mon, 30 Apr 2012 15:07:13 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-api@lists.xen.org, xen-arm@lists.xen.org, 
 xen-devel@lists.xen.org
Subject: [Xen-devel] Regarding a XenDev Day at XenSummit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,
we had an overwhelming vote for a 1/2 day invite only DevDay on the 
Sunday before XenSummit. I will look at logistics and then get back to you.
Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrKy-0007xG-Jc; Mon, 30 Apr 2012 14:12:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOrKx-0007x3-Oz
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:12:23 +0000
Received: from [193.109.254.147:20087] by server-6.bemta-14.messagelabs.com id
	E7/6A-02047-7CD9E9F4; Mon, 30 Apr 2012 14:12:23 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335795140!6973560!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17584 invoked from network); 30 Apr 2012 14:12:22 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:12:22 -0000
Received: by pbbro12 with SMTP id ro12so2978134pbb.32
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 07:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to:x-mailer;
	bh=GNBeHWtDoaA/gIvXvKRoyUijKw/eAwtdAzUf4uE/HsY=;
	b=uKVrUy7InYrZW81Z2qK/BeMQZ0M6TqNeF23GRBWcL1sYodlzI6mQzcUCKmnQsNd2/V
	fMK7N3oaVBsR42hDbwA1ziO3SdH6hLD5HQmKRuAFzr1g1tvt1cmUKtXIYaO6Ddca4deR
	Pc26kbTbd1+mxTXs86TDBiQwYmBHvJDfbInUlCXlQaViSk3zUqcWB4zJlrCQ6T7sQjEl
	I7y4kvLgvEZPjnyIsnAkIeO1JKvitKUyqREAQN5GXUV11puwXl1uq6ygdDD+FfufH4Bb
	mI90hhmow+kNz/WR6+JsroyVe7xGp0mQFdV9NMERWKM0PZZgMrUbCuP2XnTLQu3SGa2E
	l4bg==
Received: by 10.68.204.234 with SMTP id lb10mr4083962pbc.164.1335795140259;
	Mon, 30 Apr 2012 07:12:20 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id pt8sm16141128pbc.64.2012.04.30.07.12.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Apr 2012 07:12:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: wang zhihao <accept.acm@gmail.com>
In-Reply-To: <CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
Date: Mon, 30 Apr 2012 22:12:14 +0800
Message-Id: <068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Mailer: Apple Mail (2.1084)
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1232431981702452208=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1232431981702452208==
Content-Type: multipart/alternative; boundary=Apple-Mail-7-1005649548


--Apple-Mail-7-1005649548
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

Hi George:
=20
  Thanks for your guides, But I don't know what "combination" means.  =
Could you tell me more about it?
 =20
Best Regards
Wang Zhihao

=D4=DA 2012-4-30=A3=AC=CF=C2=CE=E75:16=A3=AC George Dunlap =D0=B4=B5=C0=A3=
=BA

> On Sun, Apr 29, 2012 at 4:21 PM, wang zhihao <accept.acm@gmail.com> =
wrote:
>> Hi , All
>>=20
>> I 'm a green hand and interested in open source development. I have a =
general question =A1=B0How to test my patch before I post it to =
public?=A1=B1 Hope you guys give me some suggestions. : )
>>=20
>> Firstly, I can re-compile the code, to assure no syntax error. =
However,I don't know how to test my patch's function is right or not. =
Some software requires unit test for each function. Is there anything =
similar in xen project?
>=20
> There is no unit testing for Xen.  What you need to test really
> depends on what your patch is doing.  The main goal is to exercise the
> code you've just added or changed: try to put it in different
> combinations to make sure that it works as you expect.  Try to break
> it, really. :-)
>=20
> If you're just tweaking a simple option in the xl config file, then
> you need to test a few different combinations to make sure that all
> the reasonable combinations work.  If you're changing the locks in the
> memory management code in the hypervisor, then you need to run a bunch
> of benchmarks that exercise that code, probably for several hours.
>=20
> If you post your patch to the list (with an appropriate description)
> we may be able to give you some suggestions.
>=20
> -George


--Apple-Mail-7-1005649548
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=GB2312

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi =
George:<div>&nbsp;</div><div>&nbsp; Thanks for your guides, But I don't =
know what "<b>combination</b>" means. &nbsp;Could you tell me more about =
it?</div><div>&nbsp;&nbsp;</div><div>Best Regards</div><div>Wang =
Zhihao</div><div><br></div><div><div>=D4=DA 2012-4-30=A3=AC=CF=C2=CE=E75:1=
6=A3=AC George Dunlap =D0=B4=B5=C0=A3=BA</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On =
Sun, Apr 29, 2012 at 4:21 PM, wang zhihao &lt;<a =
href=3D"mailto:accept.acm@gmail.com">accept.acm@gmail.com</a>&gt; =
wrote:<br><blockquote type=3D"cite">Hi , All<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I 'm a green =
hand and interested in open source development. I have a general =
question =A1=B0How to test my patch before I post it to public?=A1=B1 =
Hope you guys give me some suggestions. : )<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Firstly, I can =
re-compile the code, to assure no syntax error. However,I don't know how =
to test my patch's function is right or not. Some software requires unit =
test for each function. Is there anything similar in xen =
project?<br></blockquote><br>There is no unit testing for Xen. =
&nbsp;What you need to test really<br>depends on what your patch is =
doing. &nbsp;The main goal is to exercise the<br>code you've just added =
or changed: try to put it in different<br>combinations to make sure that =
it works as you expect. &nbsp;Try to break<br>it, really. :-)<br><br>If =
you're just tweaking a simple option in the xl config file, then<br>you =
need to test a few different combinations to make sure that all<br>the =
reasonable combinations work. &nbsp;If you're changing the locks in =
the<br>memory management code in the hypervisor, then you need to run a =
bunch<br>of benchmarks that exercise that code, probably for several =
hours.<br><br>If you post your patch to the list (with an appropriate =
description)<br>we may be able to give you some suggestions.<br><br> =
-George<br></div></blockquote></div><br></body></html>=

--Apple-Mail-7-1005649548--


--===============1232431981702452208==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1232431981702452208==--


From xen-devel-bounces@lists.xen.org Mon Apr 30 14:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrKy-0007xG-Jc; Mon, 30 Apr 2012 14:12:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOrKx-0007x3-Oz
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:12:23 +0000
Received: from [193.109.254.147:20087] by server-6.bemta-14.messagelabs.com id
	E7/6A-02047-7CD9E9F4; Mon, 30 Apr 2012 14:12:23 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1335795140!6973560!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17584 invoked from network); 30 Apr 2012 14:12:22 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:12:22 -0000
Received: by pbbro12 with SMTP id ro12so2978134pbb.32
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 07:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to:x-mailer;
	bh=GNBeHWtDoaA/gIvXvKRoyUijKw/eAwtdAzUf4uE/HsY=;
	b=uKVrUy7InYrZW81Z2qK/BeMQZ0M6TqNeF23GRBWcL1sYodlzI6mQzcUCKmnQsNd2/V
	fMK7N3oaVBsR42hDbwA1ziO3SdH6hLD5HQmKRuAFzr1g1tvt1cmUKtXIYaO6Ddca4deR
	Pc26kbTbd1+mxTXs86TDBiQwYmBHvJDfbInUlCXlQaViSk3zUqcWB4zJlrCQ6T7sQjEl
	I7y4kvLgvEZPjnyIsnAkIeO1JKvitKUyqREAQN5GXUV11puwXl1uq6ygdDD+FfufH4Bb
	mI90hhmow+kNz/WR6+JsroyVe7xGp0mQFdV9NMERWKM0PZZgMrUbCuP2XnTLQu3SGa2E
	l4bg==
Received: by 10.68.204.234 with SMTP id lb10mr4083962pbc.164.1335795140259;
	Mon, 30 Apr 2012 07:12:20 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id pt8sm16141128pbc.64.2012.04.30.07.12.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Apr 2012 07:12:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: wang zhihao <accept.acm@gmail.com>
In-Reply-To: <CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
Date: Mon, 30 Apr 2012 22:12:14 +0800
Message-Id: <068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Mailer: Apple Mail (2.1084)
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: multipart/mixed; boundary="===============1232431981702452208=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1232431981702452208==
Content-Type: multipart/alternative; boundary=Apple-Mail-7-1005649548


--Apple-Mail-7-1005649548
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

Hi George:
=20
  Thanks for your guides, But I don't know what "combination" means.  =
Could you tell me more about it?
 =20
Best Regards
Wang Zhihao

=D4=DA 2012-4-30=A3=AC=CF=C2=CE=E75:16=A3=AC George Dunlap =D0=B4=B5=C0=A3=
=BA

> On Sun, Apr 29, 2012 at 4:21 PM, wang zhihao <accept.acm@gmail.com> =
wrote:
>> Hi , All
>>=20
>> I 'm a green hand and interested in open source development. I have a =
general question =A1=B0How to test my patch before I post it to =
public?=A1=B1 Hope you guys give me some suggestions. : )
>>=20
>> Firstly, I can re-compile the code, to assure no syntax error. =
However,I don't know how to test my patch's function is right or not. =
Some software requires unit test for each function. Is there anything =
similar in xen project?
>=20
> There is no unit testing for Xen.  What you need to test really
> depends on what your patch is doing.  The main goal is to exercise the
> code you've just added or changed: try to put it in different
> combinations to make sure that it works as you expect.  Try to break
> it, really. :-)
>=20
> If you're just tweaking a simple option in the xl config file, then
> you need to test a few different combinations to make sure that all
> the reasonable combinations work.  If you're changing the locks in the
> memory management code in the hypervisor, then you need to run a bunch
> of benchmarks that exercise that code, probably for several hours.
>=20
> If you post your patch to the list (with an appropriate description)
> we may be able to give you some suggestions.
>=20
> -George


--Apple-Mail-7-1005649548
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=GB2312

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi =
George:<div>&nbsp;</div><div>&nbsp; Thanks for your guides, But I don't =
know what "<b>combination</b>" means. &nbsp;Could you tell me more about =
it?</div><div>&nbsp;&nbsp;</div><div>Best Regards</div><div>Wang =
Zhihao</div><div><br></div><div><div>=D4=DA 2012-4-30=A3=AC=CF=C2=CE=E75:1=
6=A3=AC George Dunlap =D0=B4=B5=C0=A3=BA</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On =
Sun, Apr 29, 2012 at 4:21 PM, wang zhihao &lt;<a =
href=3D"mailto:accept.acm@gmail.com">accept.acm@gmail.com</a>&gt; =
wrote:<br><blockquote type=3D"cite">Hi , All<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I 'm a green =
hand and interested in open source development. I have a general =
question =A1=B0How to test my patch before I post it to public?=A1=B1 =
Hope you guys give me some suggestions. : )<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Firstly, I can =
re-compile the code, to assure no syntax error. However,I don't know how =
to test my patch's function is right or not. Some software requires unit =
test for each function. Is there anything similar in xen =
project?<br></blockquote><br>There is no unit testing for Xen. =
&nbsp;What you need to test really<br>depends on what your patch is =
doing. &nbsp;The main goal is to exercise the<br>code you've just added =
or changed: try to put it in different<br>combinations to make sure that =
it works as you expect. &nbsp;Try to break<br>it, really. :-)<br><br>If =
you're just tweaking a simple option in the xl config file, then<br>you =
need to test a few different combinations to make sure that all<br>the =
reasonable combinations work. &nbsp;If you're changing the locks in =
the<br>memory management code in the hypervisor, then you need to run a =
bunch<br>of benchmarks that exercise that code, probably for several =
hours.<br><br>If you post your patch to the list (with an appropriate =
description)<br>we may be able to give you some suggestions.<br><br> =
-George<br></div></blockquote></div><br></body></html>=

--Apple-Mail-7-1005649548--


--===============1232431981702452208==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1232431981702452208==--


From xen-devel-bounces@lists.xen.org Mon Apr 30 14:19:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrRe-0008Ll-Er; Mon, 30 Apr 2012 14:19:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SOrRd-0008Le-M8
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:19:17 +0000
Received: from [85.158.139.83:64574] by server-7.bemta-5.messagelabs.com id
	11/DE-16195-56F9E9F4; Mon, 30 Apr 2012 14:19:17 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335795554!18893683!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13898 invoked from network); 30 Apr 2012 14:19:15 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:19:15 -0000
Received: by eaaf11 with SMTP id f11so704925eaa.32
	for <multiple recipients>; Mon, 30 Apr 2012 07:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=74Zk9kKRa07ixsLcVK6fnwfu0kvVzMxOoNq6tUYEeoA=;
	b=dNE8CntnvObBdNmo6rhnEjCIqXMh5SrP8I7s8VHT1BG2ngHQHXdVa+Ll16+JkrbjXq
	XjOwA5GveYczctQEWSlv1WUk5OTH4xCxdq6YsIZAZXbThmCJ84nn5fFyjNjeN+Tm1p+1
	d5J/D21QxSOLxJB/tbdAdE3QWCzoQLhAmcvD5ltmDrFbOTJg/3LxiAXDwKb4dwhcZaHb
	QJUZlWA/0+zxgY7sG7+aDIhJdVcvgRlH8OdwsaIh2o1p1yMwrysXPgNH6F2jT2neaiGp
	11Ucpl5a8hSwzQjbhozqS+g7al2QO6zxrhiD81yC+rcgLmcXbTzcXLcKmZUU2NX2f08X
	esTw==
Received: by 10.14.96.198 with SMTP id r46mr4443158eef.80.1335795554034;
	Mon, 30 Apr 2012 07:19:14 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id n56sm75823366eeb.4.2012.04.30.07.19.12
	(version=SSLv3 cipher=OTHER); Mon, 30 Apr 2012 07:19:13 -0700 (PDT)
Message-ID: <4F9E9F5F.3000503@xen.org>
Date: Mon, 30 Apr 2012 15:19:11 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-xci@lists.xen.org
Subject: [Xen-devel] XCI archivation review
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
nobody really has stepped up with respect of reviving XCI, so my 
proposal is to hold an archivation review the week of May 21st. Anybody 
who wants to participate or has a view please
a) let me know that you want to participate
b) Provide me with a couple of time-slots
Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:19:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrRe-0008Ll-Er; Mon, 30 Apr 2012 14:19:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SOrRd-0008Le-M8
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:19:17 +0000
Received: from [85.158.139.83:64574] by server-7.bemta-5.messagelabs.com id
	11/DE-16195-56F9E9F4; Mon, 30 Apr 2012 14:19:17 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1335795554!18893683!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13898 invoked from network); 30 Apr 2012 14:19:15 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:19:15 -0000
Received: by eaaf11 with SMTP id f11so704925eaa.32
	for <multiple recipients>; Mon, 30 Apr 2012 07:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=74Zk9kKRa07ixsLcVK6fnwfu0kvVzMxOoNq6tUYEeoA=;
	b=dNE8CntnvObBdNmo6rhnEjCIqXMh5SrP8I7s8VHT1BG2ngHQHXdVa+Ll16+JkrbjXq
	XjOwA5GveYczctQEWSlv1WUk5OTH4xCxdq6YsIZAZXbThmCJ84nn5fFyjNjeN+Tm1p+1
	d5J/D21QxSOLxJB/tbdAdE3QWCzoQLhAmcvD5ltmDrFbOTJg/3LxiAXDwKb4dwhcZaHb
	QJUZlWA/0+zxgY7sG7+aDIhJdVcvgRlH8OdwsaIh2o1p1yMwrysXPgNH6F2jT2neaiGp
	11Ucpl5a8hSwzQjbhozqS+g7al2QO6zxrhiD81yC+rcgLmcXbTzcXLcKmZUU2NX2f08X
	esTw==
Received: by 10.14.96.198 with SMTP id r46mr4443158eef.80.1335795554034;
	Mon, 30 Apr 2012 07:19:14 -0700 (PDT)
Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55])
	by mx.google.com with ESMTPS id n56sm75823366eeb.4.2012.04.30.07.19.12
	(version=SSLv3 cipher=OTHER); Mon, 30 Apr 2012 07:19:13 -0700 (PDT)
Message-ID: <4F9E9F5F.3000503@xen.org>
Date: Mon, 30 Apr 2012 15:19:11 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-xci@lists.xen.org
Subject: [Xen-devel] XCI archivation review
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
nobody really has stepped up with respect of reviving XCI, so my 
proposal is to hold an archivation review the week of May 21st. Anybody 
who wants to participate or has a view please
a) let me know that you want to participate
b) Provide me with a couple of time-slots
Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrSG-0008Ot-Iw; Mon, 30 Apr 2012 14:19:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SOrSF-0008Oc-5g
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:19:55 +0000
Received: from [193.109.254.147:38358] by server-1.bemta-14.messagelabs.com id
	94/6B-29372-A8F9E9F4; Mon, 30 Apr 2012 14:19:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335795592!6944739!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3937 invoked from network); 30 Apr 2012 14:19:53 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:19:53 -0000
Received: by qcsc20 with SMTP id c20so1824590qcs.32
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 07:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=m+4AJsNCBdHAczcj+q7r/L64UzgIbUrB+0ViG1RxLm0=;
	b=A9+/l23ameIdh7KZNxWGrxF85NuwXF7H72rnXEvZPUpUhl+P3sph/U2GBWvEMROvlQ
	anpCR45y3VzwpyATdNwHDONKIN25+Yk5W/yXOZvfnmtSbmwxYFGjVBAy6GzZMQMosbzx
	4GjT/OYQ3lu2rvs7dav6hM2gwCUNwY1gkjwnAeiTfAir9e9vObXt+8ibPVCkUNZWtnh+
	Ofy3Y48+JOvyhTHxeZ1O7015+6pCZyQU6SDnD8SpNhnL4106jdt7cOAS0zpctIDReBgM
	8LbAXCG/aRM4huYVMyov5VwCDXer545PaGRqxYuB8ow0qKKsJC/t/zApW9P2IUMKe6/H
	qJdQ==
MIME-Version: 1.0
Received: by 10.229.135.143 with SMTP id n15mr5523821qct.70.1335795592196;
	Mon, 30 Apr 2012 07:19:52 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Mon, 30 Apr 2012 07:19:52 -0700 (PDT)
In-Reply-To: <068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
Date: Mon, 30 Apr 2012 15:19:52 +0100
X-Google-Sender-Auth: vgAX3WPcw5SwLfn5e_Lb-YY_NJc
Message-ID: <CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: wang zhihao <accept.acm@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBBcHIgMzAsIDIwMTIgYXQgMzoxMiBQTSwgd2FuZyB6aGloYW8gPGFjY2VwdC5hY21A
Z21haWwuY29tPiB3cm90ZToKPiBIaSBHZW9yZ2U6Cj4KPiAgIFRoYW5rcyBmb3IgeW91ciBndWlk
ZXMsIEJ1dCBJIGRvbid0IGtub3cgd2hhdCAiY29tYmluYXRpb24iIG1lYW5zLiAgQ291bGQKPiB5
b3UgdGVsbCBtZSBtb3JlIGFib3V0IGl0PwoKSSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhh
bXBsZSB3aXRob3V0IGFuIGV4YW1wbGUgdG8gd29yayB3aXRoLgo6LSkgIFdoYXQgZG9lcyB5b3Vy
IHBhdGNoIGRvPwoKIC1HZW9yZ2UKCj4KPiBCZXN0IFJlZ2FyZHMKPiBXYW5nIFpoaWhhbwo+Cj4g
1NogMjAxMi00LTMwo6zPws7nNToxNqOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6Cj4KPiBPbiBTdW4s
IEFwciAyOSwgMjAxMiBhdCA0OjIxIFBNLCB3YW5nIHpoaWhhbyA8YWNjZXB0LmFjbUBnbWFpbC5j
b20+IHdyb3RlOgo+Cj4gSGkgLCBBbGwKPgo+Cj4gSSAnbSBhIGdyZWVuIGhhbmQgYW5kIGludGVy
ZXN0ZWQgaW4gb3BlbiBzb3VyY2UgZGV2ZWxvcG1lbnQuIEkgaGF2ZSBhCj4gZ2VuZXJhbCBxdWVz
dGlvbiAiSG93IHRvIHRlc3QgbXkgcGF0Y2ggYmVmb3JlIEkgcG9zdCBpdCB0byBwdWJsaWM/IiBI
b3BlIHlvdQo+IGd1eXMgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zLiA6ICkKPgo+Cj4gRmlyc3Rs
eSwgSSBjYW4gcmUtY29tcGlsZSB0aGUgY29kZSwgdG8gYXNzdXJlIG5vIHN5bnRheCBlcnJvci4g
SG93ZXZlcixJCj4gZG9uJ3Qga25vdyBob3cgdG8gdGVzdCBteSBwYXRjaCdzIGZ1bmN0aW9uIGlz
IHJpZ2h0IG9yIG5vdC4gU29tZSBzb2Z0d2FyZQo+IHJlcXVpcmVzIHVuaXQgdGVzdCBmb3IgZWFj
aCBmdW5jdGlvbi4gSXMgdGhlcmUgYW55dGhpbmcgc2ltaWxhciBpbiB4ZW4KPiBwcm9qZWN0Pwo+
Cj4KPiBUaGVyZSBpcyBubyB1bml0IHRlc3RpbmcgZm9yIFhlbi4gIFdoYXQgeW91IG5lZWQgdG8g
dGVzdCByZWFsbHkKPiBkZXBlbmRzIG9uIHdoYXQgeW91ciBwYXRjaCBpcyBkb2luZy4gIFRoZSBt
YWluIGdvYWwgaXMgdG8gZXhlcmNpc2UgdGhlCj4gY29kZSB5b3UndmUganVzdCBhZGRlZCBvciBj
aGFuZ2VkOiB0cnkgdG8gcHV0IGl0IGluIGRpZmZlcmVudAo+IGNvbWJpbmF0aW9ucyB0byBtYWtl
IHN1cmUgdGhhdCBpdCB3b3JrcyBhcyB5b3UgZXhwZWN0LiAgVHJ5IHRvIGJyZWFrCj4gaXQsIHJl
YWxseS4gOi0pCj4KPiBJZiB5b3UncmUganVzdCB0d2Vha2luZyBhIHNpbXBsZSBvcHRpb24gaW4g
dGhlIHhsIGNvbmZpZyBmaWxlLCB0aGVuCj4geW91IG5lZWQgdG8gdGVzdCBhIGZldyBkaWZmZXJl
bnQgY29tYmluYXRpb25zIHRvIG1ha2Ugc3VyZSB0aGF0IGFsbAo+IHRoZSByZWFzb25hYmxlIGNv
bWJpbmF0aW9ucyB3b3JrLiAgSWYgeW91J3JlIGNoYW5naW5nIHRoZSBsb2NrcyBpbiB0aGUKPiBt
ZW1vcnkgbWFuYWdlbWVudCBjb2RlIGluIHRoZSBoeXBlcnZpc29yLCB0aGVuIHlvdSBuZWVkIHRv
IHJ1biBhIGJ1bmNoCj4gb2YgYmVuY2htYXJrcyB0aGF0IGV4ZXJjaXNlIHRoYXQgY29kZSwgcHJv
YmFibHkgZm9yIHNldmVyYWwgaG91cnMuCj4KPiBJZiB5b3UgcG9zdCB5b3VyIHBhdGNoIHRvIHRo
ZSBsaXN0ICh3aXRoIGFuIGFwcHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+IHdlIG1heSBiZSBhYmxl
IHRvIGdpdmUgeW91IHNvbWUgc3VnZ2VzdGlvbnMuCj4KPiAtR2VvcmdlCj4KPgo+Cj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwKPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrSG-0008Ot-Iw; Mon, 30 Apr 2012 14:19:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SOrSF-0008Oc-5g
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:19:55 +0000
Received: from [193.109.254.147:38358] by server-1.bemta-14.messagelabs.com id
	94/6B-29372-A8F9E9F4; Mon, 30 Apr 2012 14:19:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335795592!6944739!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3937 invoked from network); 30 Apr 2012 14:19:53 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:19:53 -0000
Received: by qcsc20 with SMTP id c20so1824590qcs.32
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 07:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=m+4AJsNCBdHAczcj+q7r/L64UzgIbUrB+0ViG1RxLm0=;
	b=A9+/l23ameIdh7KZNxWGrxF85NuwXF7H72rnXEvZPUpUhl+P3sph/U2GBWvEMROvlQ
	anpCR45y3VzwpyATdNwHDONKIN25+Yk5W/yXOZvfnmtSbmwxYFGjVBAy6GzZMQMosbzx
	4GjT/OYQ3lu2rvs7dav6hM2gwCUNwY1gkjwnAeiTfAir9e9vObXt+8ibPVCkUNZWtnh+
	Ofy3Y48+JOvyhTHxeZ1O7015+6pCZyQU6SDnD8SpNhnL4106jdt7cOAS0zpctIDReBgM
	8LbAXCG/aRM4huYVMyov5VwCDXer545PaGRqxYuB8ow0qKKsJC/t/zApW9P2IUMKe6/H
	qJdQ==
MIME-Version: 1.0
Received: by 10.229.135.143 with SMTP id n15mr5523821qct.70.1335795592196;
	Mon, 30 Apr 2012 07:19:52 -0700 (PDT)
Received: by 10.229.44.145 with HTTP; Mon, 30 Apr 2012 07:19:52 -0700 (PDT)
In-Reply-To: <068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
Date: Mon, 30 Apr 2012 15:19:52 +0100
X-Google-Sender-Auth: vgAX3WPcw5SwLfn5e_Lb-YY_NJc
Message-ID: <CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: wang zhihao <accept.acm@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBBcHIgMzAsIDIwMTIgYXQgMzoxMiBQTSwgd2FuZyB6aGloYW8gPGFjY2VwdC5hY21A
Z21haWwuY29tPiB3cm90ZToKPiBIaSBHZW9yZ2U6Cj4KPiAgIFRoYW5rcyBmb3IgeW91ciBndWlk
ZXMsIEJ1dCBJIGRvbid0IGtub3cgd2hhdCAiY29tYmluYXRpb24iIG1lYW5zLiAgQ291bGQKPiB5
b3UgdGVsbCBtZSBtb3JlIGFib3V0IGl0PwoKSSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhh
bXBsZSB3aXRob3V0IGFuIGV4YW1wbGUgdG8gd29yayB3aXRoLgo6LSkgIFdoYXQgZG9lcyB5b3Vy
IHBhdGNoIGRvPwoKIC1HZW9yZ2UKCj4KPiBCZXN0IFJlZ2FyZHMKPiBXYW5nIFpoaWhhbwo+Cj4g
1NogMjAxMi00LTMwo6zPws7nNToxNqOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6Cj4KPiBPbiBTdW4s
IEFwciAyOSwgMjAxMiBhdCA0OjIxIFBNLCB3YW5nIHpoaWhhbyA8YWNjZXB0LmFjbUBnbWFpbC5j
b20+IHdyb3RlOgo+Cj4gSGkgLCBBbGwKPgo+Cj4gSSAnbSBhIGdyZWVuIGhhbmQgYW5kIGludGVy
ZXN0ZWQgaW4gb3BlbiBzb3VyY2UgZGV2ZWxvcG1lbnQuIEkgaGF2ZSBhCj4gZ2VuZXJhbCBxdWVz
dGlvbiAiSG93IHRvIHRlc3QgbXkgcGF0Y2ggYmVmb3JlIEkgcG9zdCBpdCB0byBwdWJsaWM/IiBI
b3BlIHlvdQo+IGd1eXMgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zLiA6ICkKPgo+Cj4gRmlyc3Rs
eSwgSSBjYW4gcmUtY29tcGlsZSB0aGUgY29kZSwgdG8gYXNzdXJlIG5vIHN5bnRheCBlcnJvci4g
SG93ZXZlcixJCj4gZG9uJ3Qga25vdyBob3cgdG8gdGVzdCBteSBwYXRjaCdzIGZ1bmN0aW9uIGlz
IHJpZ2h0IG9yIG5vdC4gU29tZSBzb2Z0d2FyZQo+IHJlcXVpcmVzIHVuaXQgdGVzdCBmb3IgZWFj
aCBmdW5jdGlvbi4gSXMgdGhlcmUgYW55dGhpbmcgc2ltaWxhciBpbiB4ZW4KPiBwcm9qZWN0Pwo+
Cj4KPiBUaGVyZSBpcyBubyB1bml0IHRlc3RpbmcgZm9yIFhlbi4gIFdoYXQgeW91IG5lZWQgdG8g
dGVzdCByZWFsbHkKPiBkZXBlbmRzIG9uIHdoYXQgeW91ciBwYXRjaCBpcyBkb2luZy4gIFRoZSBt
YWluIGdvYWwgaXMgdG8gZXhlcmNpc2UgdGhlCj4gY29kZSB5b3UndmUganVzdCBhZGRlZCBvciBj
aGFuZ2VkOiB0cnkgdG8gcHV0IGl0IGluIGRpZmZlcmVudAo+IGNvbWJpbmF0aW9ucyB0byBtYWtl
IHN1cmUgdGhhdCBpdCB3b3JrcyBhcyB5b3UgZXhwZWN0LiAgVHJ5IHRvIGJyZWFrCj4gaXQsIHJl
YWxseS4gOi0pCj4KPiBJZiB5b3UncmUganVzdCB0d2Vha2luZyBhIHNpbXBsZSBvcHRpb24gaW4g
dGhlIHhsIGNvbmZpZyBmaWxlLCB0aGVuCj4geW91IG5lZWQgdG8gdGVzdCBhIGZldyBkaWZmZXJl
bnQgY29tYmluYXRpb25zIHRvIG1ha2Ugc3VyZSB0aGF0IGFsbAo+IHRoZSByZWFzb25hYmxlIGNv
bWJpbmF0aW9ucyB3b3JrLiAgSWYgeW91J3JlIGNoYW5naW5nIHRoZSBsb2NrcyBpbiB0aGUKPiBt
ZW1vcnkgbWFuYWdlbWVudCBjb2RlIGluIHRoZSBoeXBlcnZpc29yLCB0aGVuIHlvdSBuZWVkIHRv
IHJ1biBhIGJ1bmNoCj4gb2YgYmVuY2htYXJrcyB0aGF0IGV4ZXJjaXNlIHRoYXQgY29kZSwgcHJv
YmFibHkgZm9yIHNldmVyYWwgaG91cnMuCj4KPiBJZiB5b3UgcG9zdCB5b3VyIHBhdGNoIHRvIHRo
ZSBsaXN0ICh3aXRoIGFuIGFwcHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+IHdlIG1heSBiZSBhYmxl
IHRvIGdpdmUgeW91IHNvbWUgc3VnZ2VzdGlvbnMuCj4KPiAtR2VvcmdlCj4KPgo+Cj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwKPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:25:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrXi-0000Un-Iv; Mon, 30 Apr 2012 14:25:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOrXh-0000Ub-AC
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:25:33 +0000
Received: from [85.158.139.83:27664] by server-12.bemta-5.messagelabs.com id
	8A/26-01344-AD0AE9F4; Mon, 30 Apr 2012 14:25:30 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335795925!25441849!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23798 invoked from network); 30 Apr 2012 14:25:27 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:25:27 -0000
Received: by dajx4 with SMTP id x4so4398307daj.28
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 07:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=pOE6jJh0z7aewPUR7lOVVGUjefCBaQ1m8zClOMiUj7g=;
	b=RrHzsz0s74x9qmKX3yalpWRp8CpqFnuujR2uJH0xo+cyq7Ok2H1x3MedhbeSnVpdyz
	0+sAerErSaFSbJDa2twAOxCtUfDWYU6kAzEsf73u1JKKl1tb9hgGnIJidxCzg9BbxVFq
	mFuVsDxkC9hdxNJbVjsUvkja3d6KA/s7CdajancOfDTXHhYcNGoIgV/7RyZsmbVzjm7w
	0BQUQrR23kXHtXPjnB//AP1LGbeeLnHJJaAT1GkZDPC9eNXuzoG5YAE2Or6imacTLLvk
	SnZhIpEO7rlAvcAXxVA++ZSMu1SKZcNj7YYUkPSsrqz4o9ibkAgO0xTSbzOmsrHu5hbZ
	gNJQ==
Received: by 10.68.136.137 with SMTP id qa9mr4252019pbb.78.1335795925017;
	Mon, 30 Apr 2012 07:25:25 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id 2sm16188608pbw.57.2012.04.30.07.25.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Apr 2012 07:25:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: wang zhihao <accept.acm@gmail.com>
In-Reply-To: <CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
Date: Mon, 30 Apr 2012 22:25:19 +0800
Message-Id: <7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
	<CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Mailer: Apple Mail (2.1084)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgR2VvcmdlOgoKSSBkb24ndCBoYXZlIGEgcGF0Y2ggbm93LCBidXQgbWF5IGhhdmUgb25lIGlu
IGZ1dHVyZS4gOiBQCgpPaywgSSB3aWxsIHRyeSB0byBtYWtlIGEgcGF0Y2ggYW5kIHRoZW4gYXNr
IHRoaXMgcXVlc3Rpb24gOiApCgpSZWdhcmRzCldhbmcgemhpaGFvCgrU2iAyMDEyLTQtMzCjrM/C
zucxMDoxOaOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6Cgo+IE9uIE1vbiwgQXByIDMwLCAyMDEyIGF0
IDM6MTIgUE0sIHdhbmcgemhpaGFvIDxhY2NlcHQuYWNtQGdtYWlsLmNvbT4gd3JvdGU6Cj4+IEhp
IEdlb3JnZToKPj4gCj4+ICBUaGFua3MgZm9yIHlvdXIgZ3VpZGVzLCBCdXQgSSBkb24ndCBrbm93
IHdoYXQgImNvbWJpbmF0aW9uIiBtZWFucy4gIENvdWxkCj4+IHlvdSB0ZWxsIG1lIG1vcmUgYWJv
dXQgaXQ/Cj4gCj4gSSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhhbXBsZSB3aXRob3V0IGFu
IGV4YW1wbGUgdG8gd29yayB3aXRoLgo+IDotKSAgV2hhdCBkb2VzIHlvdXIgcGF0Y2ggZG8/Cj4g
Cj4gLUdlb3JnZQo+IAo+PiAKPj4gQmVzdCBSZWdhcmRzCj4+IFdhbmcgWmhpaGFvCj4+IAo+PiDU
2iAyMDEyLTQtMzCjrM/Czuc1OjE2o6wgR2VvcmdlIER1bmxhcCDQtLXAo7oKPj4gCj4+IE9uIFN1
biwgQXByIDI5LCAyMDEyIGF0IDQ6MjEgUE0sIHdhbmcgemhpaGFvIDxhY2NlcHQuYWNtQGdtYWls
LmNvbT4gd3JvdGU6Cj4+IAo+PiBIaSAsIEFsbAo+PiAKPj4gCj4+IEkgJ20gYSBncmVlbiBoYW5k
IGFuZCBpbnRlcmVzdGVkIGluIG9wZW4gc291cmNlIGRldmVsb3BtZW50LiBJIGhhdmUgYQo+PiBn
ZW5lcmFsIHF1ZXN0aW9uICJIb3cgdG8gdGVzdCBteSBwYXRjaCBiZWZvcmUgSSBwb3N0IGl0IHRv
IHB1YmxpYz8iIEhvcGUgeW91Cj4+IGd1eXMgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zLiA6ICkK
Pj4gCj4+IAo+PiBGaXJzdGx5LCBJIGNhbiByZS1jb21waWxlIHRoZSBjb2RlLCB0byBhc3N1cmUg
bm8gc3ludGF4IGVycm9yLiBIb3dldmVyLEkKPj4gZG9uJ3Qga25vdyBob3cgdG8gdGVzdCBteSBw
YXRjaCdzIGZ1bmN0aW9uIGlzIHJpZ2h0IG9yIG5vdC4gU29tZSBzb2Z0d2FyZQo+PiByZXF1aXJl
cyB1bml0IHRlc3QgZm9yIGVhY2ggZnVuY3Rpb24uIElzIHRoZXJlIGFueXRoaW5nIHNpbWlsYXIg
aW4geGVuCj4+IHByb2plY3Q/Cj4+IAo+PiAKPj4gVGhlcmUgaXMgbm8gdW5pdCB0ZXN0aW5nIGZv
ciBYZW4uICBXaGF0IHlvdSBuZWVkIHRvIHRlc3QgcmVhbGx5Cj4+IGRlcGVuZHMgb24gd2hhdCB5
b3VyIHBhdGNoIGlzIGRvaW5nLiAgVGhlIG1haW4gZ29hbCBpcyB0byBleGVyY2lzZSB0aGUKPj4g
Y29kZSB5b3UndmUganVzdCBhZGRlZCBvciBjaGFuZ2VkOiB0cnkgdG8gcHV0IGl0IGluIGRpZmZl
cmVudAo+PiBjb21iaW5hdGlvbnMgdG8gbWFrZSBzdXJlIHRoYXQgaXQgd29ya3MgYXMgeW91IGV4
cGVjdC4gIFRyeSB0byBicmVhawo+PiBpdCwgcmVhbGx5LiA6LSkKPj4gCj4+IElmIHlvdSdyZSBq
dXN0IHR3ZWFraW5nIGEgc2ltcGxlIG9wdGlvbiBpbiB0aGUgeGwgY29uZmlnIGZpbGUsIHRoZW4K
Pj4geW91IG5lZWQgdG8gdGVzdCBhIGZldyBkaWZmZXJlbnQgY29tYmluYXRpb25zIHRvIG1ha2Ug
c3VyZSB0aGF0IGFsbAo+PiB0aGUgcmVhc29uYWJsZSBjb21iaW5hdGlvbnMgd29yay4gIElmIHlv
dSdyZSBjaGFuZ2luZyB0aGUgbG9ja3MgaW4gdGhlCj4+IG1lbW9yeSBtYW5hZ2VtZW50IGNvZGUg
aW4gdGhlIGh5cGVydmlzb3IsIHRoZW4geW91IG5lZWQgdG8gcnVuIGEgYnVuY2gKPj4gb2YgYmVu
Y2htYXJrcyB0aGF0IGV4ZXJjaXNlIHRoYXQgY29kZSwgcHJvYmFibHkgZm9yIHNldmVyYWwgaG91
cnMuCj4+IAo+PiBJZiB5b3UgcG9zdCB5b3VyIHBhdGNoIHRvIHRoZSBsaXN0ICh3aXRoIGFuIGFw
cHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+PiB3ZSBtYXkgYmUgYWJsZSB0byBnaXZlIHlvdSBzb21l
IHN1Z2dlc3Rpb25zLgo+PiAKPj4gLUdlb3JnZQo+PiAKPj4gCj4+IAo+PiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Cj4+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo+PiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:25:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrXi-0000Un-Iv; Mon, 30 Apr 2012 14:25:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOrXh-0000Ub-AC
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:25:33 +0000
Received: from [85.158.139.83:27664] by server-12.bemta-5.messagelabs.com id
	8A/26-01344-AD0AE9F4; Mon, 30 Apr 2012 14:25:30 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1335795925!25441849!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23798 invoked from network); 30 Apr 2012 14:25:27 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:25:27 -0000
Received: by dajx4 with SMTP id x4so4398307daj.28
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 07:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=pOE6jJh0z7aewPUR7lOVVGUjefCBaQ1m8zClOMiUj7g=;
	b=RrHzsz0s74x9qmKX3yalpWRp8CpqFnuujR2uJH0xo+cyq7Ok2H1x3MedhbeSnVpdyz
	0+sAerErSaFSbJDa2twAOxCtUfDWYU6kAzEsf73u1JKKl1tb9hgGnIJidxCzg9BbxVFq
	mFuVsDxkC9hdxNJbVjsUvkja3d6KA/s7CdajancOfDTXHhYcNGoIgV/7RyZsmbVzjm7w
	0BQUQrR23kXHtXPjnB//AP1LGbeeLnHJJaAT1GkZDPC9eNXuzoG5YAE2Or6imacTLLvk
	SnZhIpEO7rlAvcAXxVA++ZSMu1SKZcNj7YYUkPSsrqz4o9ibkAgO0xTSbzOmsrHu5hbZ
	gNJQ==
Received: by 10.68.136.137 with SMTP id qa9mr4252019pbb.78.1335795925017;
	Mon, 30 Apr 2012 07:25:25 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id 2sm16188608pbw.57.2012.04.30.07.25.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Apr 2012 07:25:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: wang zhihao <accept.acm@gmail.com>
In-Reply-To: <CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
Date: Mon, 30 Apr 2012 22:25:19 +0800
Message-Id: <7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
	<CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Mailer: Apple Mail (2.1084)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgR2VvcmdlOgoKSSBkb24ndCBoYXZlIGEgcGF0Y2ggbm93LCBidXQgbWF5IGhhdmUgb25lIGlu
IGZ1dHVyZS4gOiBQCgpPaywgSSB3aWxsIHRyeSB0byBtYWtlIGEgcGF0Y2ggYW5kIHRoZW4gYXNr
IHRoaXMgcXVlc3Rpb24gOiApCgpSZWdhcmRzCldhbmcgemhpaGFvCgrU2iAyMDEyLTQtMzCjrM/C
zucxMDoxOaOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6Cgo+IE9uIE1vbiwgQXByIDMwLCAyMDEyIGF0
IDM6MTIgUE0sIHdhbmcgemhpaGFvIDxhY2NlcHQuYWNtQGdtYWlsLmNvbT4gd3JvdGU6Cj4+IEhp
IEdlb3JnZToKPj4gCj4+ICBUaGFua3MgZm9yIHlvdXIgZ3VpZGVzLCBCdXQgSSBkb24ndCBrbm93
IHdoYXQgImNvbWJpbmF0aW9uIiBtZWFucy4gIENvdWxkCj4+IHlvdSB0ZWxsIG1lIG1vcmUgYWJv
dXQgaXQ/Cj4gCj4gSSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhhbXBsZSB3aXRob3V0IGFu
IGV4YW1wbGUgdG8gd29yayB3aXRoLgo+IDotKSAgV2hhdCBkb2VzIHlvdXIgcGF0Y2ggZG8/Cj4g
Cj4gLUdlb3JnZQo+IAo+PiAKPj4gQmVzdCBSZWdhcmRzCj4+IFdhbmcgWmhpaGFvCj4+IAo+PiDU
2iAyMDEyLTQtMzCjrM/Czuc1OjE2o6wgR2VvcmdlIER1bmxhcCDQtLXAo7oKPj4gCj4+IE9uIFN1
biwgQXByIDI5LCAyMDEyIGF0IDQ6MjEgUE0sIHdhbmcgemhpaGFvIDxhY2NlcHQuYWNtQGdtYWls
LmNvbT4gd3JvdGU6Cj4+IAo+PiBIaSAsIEFsbAo+PiAKPj4gCj4+IEkgJ20gYSBncmVlbiBoYW5k
IGFuZCBpbnRlcmVzdGVkIGluIG9wZW4gc291cmNlIGRldmVsb3BtZW50LiBJIGhhdmUgYQo+PiBn
ZW5lcmFsIHF1ZXN0aW9uICJIb3cgdG8gdGVzdCBteSBwYXRjaCBiZWZvcmUgSSBwb3N0IGl0IHRv
IHB1YmxpYz8iIEhvcGUgeW91Cj4+IGd1eXMgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zLiA6ICkK
Pj4gCj4+IAo+PiBGaXJzdGx5LCBJIGNhbiByZS1jb21waWxlIHRoZSBjb2RlLCB0byBhc3N1cmUg
bm8gc3ludGF4IGVycm9yLiBIb3dldmVyLEkKPj4gZG9uJ3Qga25vdyBob3cgdG8gdGVzdCBteSBw
YXRjaCdzIGZ1bmN0aW9uIGlzIHJpZ2h0IG9yIG5vdC4gU29tZSBzb2Z0d2FyZQo+PiByZXF1aXJl
cyB1bml0IHRlc3QgZm9yIGVhY2ggZnVuY3Rpb24uIElzIHRoZXJlIGFueXRoaW5nIHNpbWlsYXIg
aW4geGVuCj4+IHByb2plY3Q/Cj4+IAo+PiAKPj4gVGhlcmUgaXMgbm8gdW5pdCB0ZXN0aW5nIGZv
ciBYZW4uICBXaGF0IHlvdSBuZWVkIHRvIHRlc3QgcmVhbGx5Cj4+IGRlcGVuZHMgb24gd2hhdCB5
b3VyIHBhdGNoIGlzIGRvaW5nLiAgVGhlIG1haW4gZ29hbCBpcyB0byBleGVyY2lzZSB0aGUKPj4g
Y29kZSB5b3UndmUganVzdCBhZGRlZCBvciBjaGFuZ2VkOiB0cnkgdG8gcHV0IGl0IGluIGRpZmZl
cmVudAo+PiBjb21iaW5hdGlvbnMgdG8gbWFrZSBzdXJlIHRoYXQgaXQgd29ya3MgYXMgeW91IGV4
cGVjdC4gIFRyeSB0byBicmVhawo+PiBpdCwgcmVhbGx5LiA6LSkKPj4gCj4+IElmIHlvdSdyZSBq
dXN0IHR3ZWFraW5nIGEgc2ltcGxlIG9wdGlvbiBpbiB0aGUgeGwgY29uZmlnIGZpbGUsIHRoZW4K
Pj4geW91IG5lZWQgdG8gdGVzdCBhIGZldyBkaWZmZXJlbnQgY29tYmluYXRpb25zIHRvIG1ha2Ug
c3VyZSB0aGF0IGFsbAo+PiB0aGUgcmVhc29uYWJsZSBjb21iaW5hdGlvbnMgd29yay4gIElmIHlv
dSdyZSBjaGFuZ2luZyB0aGUgbG9ja3MgaW4gdGhlCj4+IG1lbW9yeSBtYW5hZ2VtZW50IGNvZGUg
aW4gdGhlIGh5cGVydmlzb3IsIHRoZW4geW91IG5lZWQgdG8gcnVuIGEgYnVuY2gKPj4gb2YgYmVu
Y2htYXJrcyB0aGF0IGV4ZXJjaXNlIHRoYXQgY29kZSwgcHJvYmFibHkgZm9yIHNldmVyYWwgaG91
cnMuCj4+IAo+PiBJZiB5b3UgcG9zdCB5b3VyIHBhdGNoIHRvIHRoZSBsaXN0ICh3aXRoIGFuIGFw
cHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+PiB3ZSBtYXkgYmUgYWJsZSB0byBnaXZlIHlvdSBzb21l
IHN1Z2dlc3Rpb25zLgo+PiAKPj4gLUdlb3JnZQo+PiAKPj4gCj4+IAo+PiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Cj4+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo+PiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:48:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrth-000159-75; Mon, 30 Apr 2012 14:48:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SOrtf-000152-CC
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:48:15 +0000
Received: from [85.158.143.99:7625] by server-3.bemta-4.messagelabs.com id
	42/7B-05853-E26AE9F4; Mon, 30 Apr 2012 14:48:14 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335797291!14684877!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDgxMjk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17032 invoked from network); 30 Apr 2012 14:48:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:48:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,504,1330923600"; d="scan'208";a="192671033"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Apr 2012 10:47:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Apr 2012 10:47:55 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SOrtK-0008S4-SN;
	Mon, 30 Apr 2012 15:47:54 +0100
Message-ID: <4F9EA5DA.40100@eu.citrix.com>
Date: Mon, 30 Apr 2012 15:46:50 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: wang zhihao <accept.acm@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
	<CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
	<7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
In-Reply-To: <7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMzAvMDQvMTIgMTU6MjUsIHdhbmcgemhpaGFvIHdyb3RlOgo+IEhpIEdlb3JnZToKPgo+IEkg
ZG9uJ3QgaGF2ZSBhIHBhdGNoIG5vdywgYnV0IG1heSBoYXZlIG9uZSBpbiBmdXR1cmUuIDogUAo+
Cj4gT2ssIEkgd2lsbCB0cnkgdG8gbWFrZSBhIHBhdGNoIGFuZCB0aGVuIGFzayB0aGlzIHF1ZXN0
aW9uIDogKQpXZWxsLCBhcyBJIHNhaWQsIHRoZSBnZW5lcmFsIGlkZWEgaXMsICJ0cnkgdG8gYnJl
YWsgaXQiLiBJZiB5b3UgYWRkIGEKbmV3IG9wdGlvbiwgZm9yIGluc3RhbmNlLCBjaGVjayB0byBt
YWtlIHN1cmUgdGhhdCBpdCB3b3JrcyByaWdodDoKKiBJZiB5b3UgcHV0IGluIGEgcmVhc29uYWJs
ZSB2YWx1ZQoqIElmIHlvdSBwdXQgaW4gYW4gdW5yZWFzb25hYmx5IGhpZ2ggdmFsdWUKKiBJZiB5
b3UgcHV0IGluIGEgbmVnYXRpdmUgbnVtYmVyCiogSWYgeW91IGRvbid0IHNwZWNpZnkgdGhlIG9w
dGlvbiBhdCBhbGwKKiBJZiB5b3UgcHV0IGEgc3RyaW5nIGluc3RlYWQgb2YgYSBudW1iZXIKCk1h
a2Ugc2Vuc2U/CgotR2VvcmdlCgo+Cj4gUmVnYXJkcwo+IFdhbmcgemhpaGFvCj4KPiDU2iAyMDEy
LTQtMzCjrM/CzucxMDoxOaOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6Cj4KPj4gT24gTW9uLCBBcHIg
MzAsIDIwMTIgYXQgMzoxMiBQTSwgd2FuZyB6aGloYW8gPGFjY2VwdC5hY21AZ21haWwuY29tPiB3
cm90ZToKPj4+IEhpIEdlb3JnZToKPj4+Cj4+PiAgVGhhbmtzIGZvciB5b3VyIGd1aWRlcywgQnV0
IEkgZG9uJ3Qga25vdyB3aGF0ICJjb21iaW5hdGlvbiIgbWVhbnMuICBDb3VsZAo+Pj4geW91IHRl
bGwgbWUgbW9yZSBhYm91dCBpdD8KPj4gSSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhhbXBs
ZSB3aXRob3V0IGFuIGV4YW1wbGUgdG8gd29yayB3aXRoLgo+PiA6LSkgIFdoYXQgZG9lcyB5b3Vy
IHBhdGNoIGRvPwo+Pgo+PiAtR2VvcmdlCj4+Cj4+PiBCZXN0IFJlZ2FyZHMKPj4+IFdhbmcgWmhp
aGFvCj4+Pgo+Pj4g1NogMjAxMi00LTMwo6zPws7nNToxNqOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6
Cj4+Pgo+Pj4gT24gU3VuLCBBcHIgMjksIDIwMTIgYXQgNDoyMSBQTSwgd2FuZyB6aGloYW8gPGFj
Y2VwdC5hY21AZ21haWwuY29tPiB3cm90ZToKPj4+Cj4+PiBIaSAsIEFsbAo+Pj4KPj4+Cj4+PiBJ
ICdtIGEgZ3JlZW4gaGFuZCBhbmQgaW50ZXJlc3RlZCBpbiBvcGVuIHNvdXJjZSBkZXZlbG9wbWVu
dC4gSSBoYXZlIGEKPj4+IGdlbmVyYWwgcXVlc3Rpb24gIkhvdyB0byB0ZXN0IG15IHBhdGNoIGJl
Zm9yZSBJIHBvc3QgaXQgdG8gcHVibGljPyIgSG9wZSB5b3UKPj4+IGd1eXMgZ2l2ZSBtZSBzb21l
IHN1Z2dlc3Rpb25zLiA6ICkKPj4+Cj4+Pgo+Pj4gRmlyc3RseSwgSSBjYW4gcmUtY29tcGlsZSB0
aGUgY29kZSwgdG8gYXNzdXJlIG5vIHN5bnRheCBlcnJvci4gSG93ZXZlcixJCj4+PiBkb24ndCBr
bm93IGhvdyB0byB0ZXN0IG15IHBhdGNoJ3MgZnVuY3Rpb24gaXMgcmlnaHQgb3Igbm90LiBTb21l
IHNvZnR3YXJlCj4+PiByZXF1aXJlcyB1bml0IHRlc3QgZm9yIGVhY2ggZnVuY3Rpb24uIElzIHRo
ZXJlIGFueXRoaW5nIHNpbWlsYXIgaW4geGVuCj4+PiBwcm9qZWN0Pwo+Pj4KPj4+Cj4+PiBUaGVy
ZSBpcyBubyB1bml0IHRlc3RpbmcgZm9yIFhlbi4gIFdoYXQgeW91IG5lZWQgdG8gdGVzdCByZWFs
bHkKPj4+IGRlcGVuZHMgb24gd2hhdCB5b3VyIHBhdGNoIGlzIGRvaW5nLiAgVGhlIG1haW4gZ29h
bCBpcyB0byBleGVyY2lzZSB0aGUKPj4+IGNvZGUgeW91J3ZlIGp1c3QgYWRkZWQgb3IgY2hhbmdl
ZDogdHJ5IHRvIHB1dCBpdCBpbiBkaWZmZXJlbnQKPj4+IGNvbWJpbmF0aW9ucyB0byBtYWtlIHN1
cmUgdGhhdCBpdCB3b3JrcyBhcyB5b3UgZXhwZWN0LiAgVHJ5IHRvIGJyZWFrCj4+PiBpdCwgcmVh
bGx5LiA6LSkKPj4+Cj4+PiBJZiB5b3UncmUganVzdCB0d2Vha2luZyBhIHNpbXBsZSBvcHRpb24g
aW4gdGhlIHhsIGNvbmZpZyBmaWxlLCB0aGVuCj4+PiB5b3UgbmVlZCB0byB0ZXN0IGEgZmV3IGRp
ZmZlcmVudCBjb21iaW5hdGlvbnMgdG8gbWFrZSBzdXJlIHRoYXQgYWxsCj4+PiB0aGUgcmVhc29u
YWJsZSBjb21iaW5hdGlvbnMgd29yay4gIElmIHlvdSdyZSBjaGFuZ2luZyB0aGUgbG9ja3MgaW4g
dGhlCj4+PiBtZW1vcnkgbWFuYWdlbWVudCBjb2RlIGluIHRoZSBoeXBlcnZpc29yLCB0aGVuIHlv
dSBuZWVkIHRvIHJ1biBhIGJ1bmNoCj4+PiBvZiBiZW5jaG1hcmtzIHRoYXQgZXhlcmNpc2UgdGhh
dCBjb2RlLCBwcm9iYWJseSBmb3Igc2V2ZXJhbCBob3Vycy4KPj4+Cj4+PiBJZiB5b3UgcG9zdCB5
b3VyIHBhdGNoIHRvIHRoZSBsaXN0ICh3aXRoIGFuIGFwcHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+
Pj4gd2UgbWF5IGJlIGFibGUgdG8gZ2l2ZSB5b3Ugc29tZSBzdWdnZXN0aW9ucy4KPj4+Cj4+PiAt
R2VvcmdlCj4+Pgo+Pj4KPj4+Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwo+Pj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+Pj4gWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKPj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+Pj4KCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Apr 30 14:48:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 14:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOrth-000159-75; Mon, 30 Apr 2012 14:48:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SOrtf-000152-CC
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 14:48:15 +0000
Received: from [85.158.143.99:7625] by server-3.bemta-4.messagelabs.com id
	42/7B-05853-E26AE9F4; Mon, 30 Apr 2012 14:48:14 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1335797291!14684877!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDgxMjk=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17032 invoked from network); 30 Apr 2012 14:48:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 14:48:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,504,1330923600"; d="scan'208";a="192671033"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Apr 2012 10:47:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Apr 2012 10:47:55 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SOrtK-0008S4-SN;
	Mon, 30 Apr 2012 15:47:54 +0100
Message-ID: <4F9EA5DA.40100@eu.citrix.com>
Date: Mon, 30 Apr 2012 15:46:50 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: wang zhihao <accept.acm@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
	<CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
	<7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
In-Reply-To: <7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMzAvMDQvMTIgMTU6MjUsIHdhbmcgemhpaGFvIHdyb3RlOgo+IEhpIEdlb3JnZToKPgo+IEkg
ZG9uJ3QgaGF2ZSBhIHBhdGNoIG5vdywgYnV0IG1heSBoYXZlIG9uZSBpbiBmdXR1cmUuIDogUAo+
Cj4gT2ssIEkgd2lsbCB0cnkgdG8gbWFrZSBhIHBhdGNoIGFuZCB0aGVuIGFzayB0aGlzIHF1ZXN0
aW9uIDogKQpXZWxsLCBhcyBJIHNhaWQsIHRoZSBnZW5lcmFsIGlkZWEgaXMsICJ0cnkgdG8gYnJl
YWsgaXQiLiBJZiB5b3UgYWRkIGEKbmV3IG9wdGlvbiwgZm9yIGluc3RhbmNlLCBjaGVjayB0byBt
YWtlIHN1cmUgdGhhdCBpdCB3b3JrcyByaWdodDoKKiBJZiB5b3UgcHV0IGluIGEgcmVhc29uYWJs
ZSB2YWx1ZQoqIElmIHlvdSBwdXQgaW4gYW4gdW5yZWFzb25hYmx5IGhpZ2ggdmFsdWUKKiBJZiB5
b3UgcHV0IGluIGEgbmVnYXRpdmUgbnVtYmVyCiogSWYgeW91IGRvbid0IHNwZWNpZnkgdGhlIG9w
dGlvbiBhdCBhbGwKKiBJZiB5b3UgcHV0IGEgc3RyaW5nIGluc3RlYWQgb2YgYSBudW1iZXIKCk1h
a2Ugc2Vuc2U/CgotR2VvcmdlCgo+Cj4gUmVnYXJkcwo+IFdhbmcgemhpaGFvCj4KPiDU2iAyMDEy
LTQtMzCjrM/CzucxMDoxOaOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6Cj4KPj4gT24gTW9uLCBBcHIg
MzAsIDIwMTIgYXQgMzoxMiBQTSwgd2FuZyB6aGloYW8gPGFjY2VwdC5hY21AZ21haWwuY29tPiB3
cm90ZToKPj4+IEhpIEdlb3JnZToKPj4+Cj4+PiAgVGhhbmtzIGZvciB5b3VyIGd1aWRlcywgQnV0
IEkgZG9uJ3Qga25vdyB3aGF0ICJjb21iaW5hdGlvbiIgbWVhbnMuICBDb3VsZAo+Pj4geW91IHRl
bGwgbWUgbW9yZSBhYm91dCBpdD8KPj4gSSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhhbXBs
ZSB3aXRob3V0IGFuIGV4YW1wbGUgdG8gd29yayB3aXRoLgo+PiA6LSkgIFdoYXQgZG9lcyB5b3Vy
IHBhdGNoIGRvPwo+Pgo+PiAtR2VvcmdlCj4+Cj4+PiBCZXN0IFJlZ2FyZHMKPj4+IFdhbmcgWmhp
aGFvCj4+Pgo+Pj4g1NogMjAxMi00LTMwo6zPws7nNToxNqOsIEdlb3JnZSBEdW5sYXAg0LS1wKO6
Cj4+Pgo+Pj4gT24gU3VuLCBBcHIgMjksIDIwMTIgYXQgNDoyMSBQTSwgd2FuZyB6aGloYW8gPGFj
Y2VwdC5hY21AZ21haWwuY29tPiB3cm90ZToKPj4+Cj4+PiBIaSAsIEFsbAo+Pj4KPj4+Cj4+PiBJ
ICdtIGEgZ3JlZW4gaGFuZCBhbmQgaW50ZXJlc3RlZCBpbiBvcGVuIHNvdXJjZSBkZXZlbG9wbWVu
dC4gSSBoYXZlIGEKPj4+IGdlbmVyYWwgcXVlc3Rpb24gIkhvdyB0byB0ZXN0IG15IHBhdGNoIGJl
Zm9yZSBJIHBvc3QgaXQgdG8gcHVibGljPyIgSG9wZSB5b3UKPj4+IGd1eXMgZ2l2ZSBtZSBzb21l
IHN1Z2dlc3Rpb25zLiA6ICkKPj4+Cj4+Pgo+Pj4gRmlyc3RseSwgSSBjYW4gcmUtY29tcGlsZSB0
aGUgY29kZSwgdG8gYXNzdXJlIG5vIHN5bnRheCBlcnJvci4gSG93ZXZlcixJCj4+PiBkb24ndCBr
bm93IGhvdyB0byB0ZXN0IG15IHBhdGNoJ3MgZnVuY3Rpb24gaXMgcmlnaHQgb3Igbm90LiBTb21l
IHNvZnR3YXJlCj4+PiByZXF1aXJlcyB1bml0IHRlc3QgZm9yIGVhY2ggZnVuY3Rpb24uIElzIHRo
ZXJlIGFueXRoaW5nIHNpbWlsYXIgaW4geGVuCj4+PiBwcm9qZWN0Pwo+Pj4KPj4+Cj4+PiBUaGVy
ZSBpcyBubyB1bml0IHRlc3RpbmcgZm9yIFhlbi4gIFdoYXQgeW91IG5lZWQgdG8gdGVzdCByZWFs
bHkKPj4+IGRlcGVuZHMgb24gd2hhdCB5b3VyIHBhdGNoIGlzIGRvaW5nLiAgVGhlIG1haW4gZ29h
bCBpcyB0byBleGVyY2lzZSB0aGUKPj4+IGNvZGUgeW91J3ZlIGp1c3QgYWRkZWQgb3IgY2hhbmdl
ZDogdHJ5IHRvIHB1dCBpdCBpbiBkaWZmZXJlbnQKPj4+IGNvbWJpbmF0aW9ucyB0byBtYWtlIHN1
cmUgdGhhdCBpdCB3b3JrcyBhcyB5b3UgZXhwZWN0LiAgVHJ5IHRvIGJyZWFrCj4+PiBpdCwgcmVh
bGx5LiA6LSkKPj4+Cj4+PiBJZiB5b3UncmUganVzdCB0d2Vha2luZyBhIHNpbXBsZSBvcHRpb24g
aW4gdGhlIHhsIGNvbmZpZyBmaWxlLCB0aGVuCj4+PiB5b3UgbmVlZCB0byB0ZXN0IGEgZmV3IGRp
ZmZlcmVudCBjb21iaW5hdGlvbnMgdG8gbWFrZSBzdXJlIHRoYXQgYWxsCj4+PiB0aGUgcmVhc29u
YWJsZSBjb21iaW5hdGlvbnMgd29yay4gIElmIHlvdSdyZSBjaGFuZ2luZyB0aGUgbG9ja3MgaW4g
dGhlCj4+PiBtZW1vcnkgbWFuYWdlbWVudCBjb2RlIGluIHRoZSBoeXBlcnZpc29yLCB0aGVuIHlv
dSBuZWVkIHRvIHJ1biBhIGJ1bmNoCj4+PiBvZiBiZW5jaG1hcmtzIHRoYXQgZXhlcmNpc2UgdGhh
dCBjb2RlLCBwcm9iYWJseSBmb3Igc2V2ZXJhbCBob3Vycy4KPj4+Cj4+PiBJZiB5b3UgcG9zdCB5
b3VyIHBhdGNoIHRvIHRoZSBsaXN0ICh3aXRoIGFuIGFwcHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+
Pj4gd2UgbWF5IGJlIGFibGUgdG8gZ2l2ZSB5b3Ugc29tZSBzdWdnZXN0aW9ucy4KPj4+Cj4+PiAt
R2VvcmdlCj4+Pgo+Pj4KPj4+Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwo+Pj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+Pj4gWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKPj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+Pj4KCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Apr 30 15:03:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 15:03:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOs8P-0001No-Po; Mon, 30 Apr 2012 15:03:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOs8N-0001Nj-R5
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 15:03:28 +0000
Received: from [193.109.254.147:31579] by server-12.bemta-14.messagelabs.com
	id 6A/D3-05898-FB9AE9F4; Mon, 30 Apr 2012 15:03:27 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335798205!6951456!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10139 invoked from network); 30 Apr 2012 15:03:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	30 Apr 2012 15:03:26 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3UF3MsD012187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 11:03:22 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3UF3LnS027575; Mon, 30 Apr 2012 11:03:21 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id DF50518D495; Mon, 30 Apr 2012 18:03:20 +0300 (IDT)
Date: Mon, 30 Apr 2012 18:03:20 +0300
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20120430150320.GA16592@redhat.com>
References: <20120430143835.GA10190@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430143835.GA10190@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org,
	devel@linuxdriverproject.org, davej@redhat.com
Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 05:38:35PM +0300, Michael S. Tsirkin wrote:
> The following makes 'x86info -r' dump hypervisor leaf cpu ids
> (for kvm this is signature+features) when running in a vm.
> 
> On the guest we see the signature and the features:
> eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> 
> Hypervisor flag is checked to avoid output changes when not
> running on a VM.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
Looks good to me.

> Changes from v1:
> 	Make work on non KVM hypervisors (only KVM was tested).
> 	Avi Kivity said kvm will in the future report
> 	max HV leaf in eax. For now it reports eax = 0
>         so add a work around for that.
> 
> ---
> 
> diff --git a/identify.c b/identify.c
> index 33f35de..a4a3763 100644
> --- a/identify.c
> +++ b/identify.c
> @@ -9,8 +9,8 @@
>  
>  void get_cpu_info_basics(struct cpudata *cpu)
>  {
> -	unsigned int maxi, maxei, vendor, address_bits;
> -	unsigned int eax;
> +	unsigned int maxi, maxei, maxhv, vendor, address_bits;
> +	unsigned int eax, ebx, ecx;
>  
>  	cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL);
>  	maxi &= 0xffff;		/* The high-order word is non-zero on some Cyrix CPUs */
> @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  		return;
>  
>  	/* Everything that supports cpuid supports these. */
> -	cpuid(cpu->number, 1, &eax, NULL, NULL, NULL);
> +	cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL);
>  	cpu->stepping = eax & 0xf;
>  	cpu->model = (eax >> 4) & 0xf;
>  	cpu->family = (eax >> 8) & 0xf;
> @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  
>  	cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
>  	cpu->maxei2 = maxei;
> +	if (ecx & 0x80000000) {
> +		cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL);
> +		/*
> +		 * KVM up to linux 3.4 reports 0 as the max hypervisor leaf,
> +		 * where it really means 0x40000001.
> +		 * Most (all?) hypervisors have at least one CPUID besides
> +		 * the vendor ID so assume that.
> +		 */
> +		cpu->maxhv = maxhv ? maxhv : 0x40000001;
> +	} else {
> +		/* Suppress hypervisor cpuid unless running on a hypervisor */
> +		cpu->maxhv = 0;
> +	}
>  
>  	cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL);
>  	cpu->phyaddr_bits = address_bits & 0xFF;
> diff --git a/x86info.c b/x86info.c
> index 22c4734..80cae36 100644
> --- a/x86info.c
> +++ b/x86info.c
> @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu)
>  
>  		if (cpu->maxei2 >=0xC0000000)
>  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> +
> +		if (cpu->maxhv >= 0x40000000)
> +			dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv);
> +
>  	}
>  
>  	if (show_cacheinfo) {
> diff --git a/x86info.h b/x86info.h
> index 7d2a455..c4f5d81 100644
> --- a/x86info.h
> +++ b/x86info.h
> @@ -84,7 +84,7 @@ struct cpudata {
>  	unsigned int cachesize_trace;
>  	unsigned int phyaddr_bits;
>  	unsigned int viraddr_bits;
> -	unsigned int cpuid_level, maxei, maxei2;
> +	unsigned int cpuid_level, maxei, maxei2, maxhv;
>  	char name[CPU_NAME_LEN];
>  	enum connector connector;
>  	unsigned int flags_ecx;

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 15:03:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 15:03:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOs8P-0001No-Po; Mon, 30 Apr 2012 15:03:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1SOs8N-0001Nj-R5
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 15:03:28 +0000
Received: from [193.109.254.147:31579] by server-12.bemta-14.messagelabs.com
	id 6A/D3-05898-FB9AE9F4; Mon, 30 Apr 2012 15:03:27 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1335798205!6951456!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10139 invoked from network); 30 Apr 2012 15:03:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	30 Apr 2012 15:03:26 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3UF3MsD012187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 11:03:22 -0400
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q3UF3LnS027575; Mon, 30 Apr 2012 11:03:21 -0400
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id DF50518D495; Mon, 30 Apr 2012 18:03:20 +0300 (IDT)
Date: Mon, 30 Apr 2012 18:03:20 +0300
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20120430150320.GA16592@redhat.com>
References: <20120430143835.GA10190@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430143835.GA10190@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org,
	devel@linuxdriverproject.org, davej@redhat.com
Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 05:38:35PM +0300, Michael S. Tsirkin wrote:
> The following makes 'x86info -r' dump hypervisor leaf cpu ids
> (for kvm this is signature+features) when running in a vm.
> 
> On the guest we see the signature and the features:
> eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> 
> Hypervisor flag is checked to avoid output changes when not
> running on a VM.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
Looks good to me.

> Changes from v1:
> 	Make work on non KVM hypervisors (only KVM was tested).
> 	Avi Kivity said kvm will in the future report
> 	max HV leaf in eax. For now it reports eax = 0
>         so add a work around for that.
> 
> ---
> 
> diff --git a/identify.c b/identify.c
> index 33f35de..a4a3763 100644
> --- a/identify.c
> +++ b/identify.c
> @@ -9,8 +9,8 @@
>  
>  void get_cpu_info_basics(struct cpudata *cpu)
>  {
> -	unsigned int maxi, maxei, vendor, address_bits;
> -	unsigned int eax;
> +	unsigned int maxi, maxei, maxhv, vendor, address_bits;
> +	unsigned int eax, ebx, ecx;
>  
>  	cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL);
>  	maxi &= 0xffff;		/* The high-order word is non-zero on some Cyrix CPUs */
> @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  		return;
>  
>  	/* Everything that supports cpuid supports these. */
> -	cpuid(cpu->number, 1, &eax, NULL, NULL, NULL);
> +	cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL);
>  	cpu->stepping = eax & 0xf;
>  	cpu->model = (eax >> 4) & 0xf;
>  	cpu->family = (eax >> 8) & 0xf;
> @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  
>  	cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
>  	cpu->maxei2 = maxei;
> +	if (ecx & 0x80000000) {
> +		cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL);
> +		/*
> +		 * KVM up to linux 3.4 reports 0 as the max hypervisor leaf,
> +		 * where it really means 0x40000001.
> +		 * Most (all?) hypervisors have at least one CPUID besides
> +		 * the vendor ID so assume that.
> +		 */
> +		cpu->maxhv = maxhv ? maxhv : 0x40000001;
> +	} else {
> +		/* Suppress hypervisor cpuid unless running on a hypervisor */
> +		cpu->maxhv = 0;
> +	}
>  
>  	cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL);
>  	cpu->phyaddr_bits = address_bits & 0xFF;
> diff --git a/x86info.c b/x86info.c
> index 22c4734..80cae36 100644
> --- a/x86info.c
> +++ b/x86info.c
> @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu)
>  
>  		if (cpu->maxei2 >=0xC0000000)
>  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> +
> +		if (cpu->maxhv >= 0x40000000)
> +			dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv);
> +
>  	}
>  
>  	if (show_cacheinfo) {
> diff --git a/x86info.h b/x86info.h
> index 7d2a455..c4f5d81 100644
> --- a/x86info.h
> +++ b/x86info.h
> @@ -84,7 +84,7 @@ struct cpudata {
>  	unsigned int cachesize_trace;
>  	unsigned int phyaddr_bits;
>  	unsigned int viraddr_bits;
> -	unsigned int cpuid_level, maxei, maxei2;
> +	unsigned int cpuid_level, maxei, maxei2, maxhv;
>  	char name[CPU_NAME_LEN];
>  	enum connector connector;
>  	unsigned int flags_ecx;

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 15:08:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 15:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOsCj-0001YW-Ll; Mon, 30 Apr 2012 15:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SOsCi-0001YO-DE
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 15:07:56 +0000
Received: from [85.158.143.99:47629] by server-3.bemta-4.messagelabs.com id
	44/C2-05853-BCAAE9F4; Mon, 30 Apr 2012 15:07:55 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335798474!25554889!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14128 invoked from network); 30 Apr 2012 15:07:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	30 Apr 2012 15:07:54 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3UF7p4x007532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 11:07:52 -0400
Received: from redhat.com (vpn-202-127.tlv.redhat.com [10.35.202.127])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q3UEcQLK030281; Mon, 30 Apr 2012 10:38:27 -0400
Date: Mon, 30 Apr 2012 17:38:35 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: davej@redhat.com
Message-ID: <20120430143835.GA10190@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org,
	Gleb Natapov <gleb@redhat.com>, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org
Subject: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following makes 'x86info -r' dump hypervisor leaf cpu ids
(for kvm this is signature+features) when running in a vm.

On the guest we see the signature and the features:
eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000

Hypervisor flag is checked to avoid output changes when not
running on a VM.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Changes from v1:
	Make work on non KVM hypervisors (only KVM was tested).
	Avi Kivity said kvm will in the future report
	max HV leaf in eax. For now it reports eax = 0
        so add a work around for that.

---

diff --git a/identify.c b/identify.c
index 33f35de..a4a3763 100644
--- a/identify.c
+++ b/identify.c
@@ -9,8 +9,8 @@
 
 void get_cpu_info_basics(struct cpudata *cpu)
 {
-	unsigned int maxi, maxei, vendor, address_bits;
-	unsigned int eax;
+	unsigned int maxi, maxei, maxhv, vendor, address_bits;
+	unsigned int eax, ebx, ecx;
 
 	cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL);
 	maxi &= 0xffff;		/* The high-order word is non-zero on some Cyrix CPUs */
@@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu)
 		return;
 
 	/* Everything that supports cpuid supports these. */
-	cpuid(cpu->number, 1, &eax, NULL, NULL, NULL);
+	cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL);
 	cpu->stepping = eax & 0xf;
 	cpu->model = (eax >> 4) & 0xf;
 	cpu->family = (eax >> 8) & 0xf;
@@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu)
 
 	cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
 	cpu->maxei2 = maxei;
+	if (ecx & 0x80000000) {
+		cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL);
+		/*
+		 * KVM up to linux 3.4 reports 0 as the max hypervisor leaf,
+		 * where it really means 0x40000001.
+		 * Most (all?) hypervisors have at least one CPUID besides
+		 * the vendor ID so assume that.
+		 */
+		cpu->maxhv = maxhv ? maxhv : 0x40000001;
+	} else {
+		/* Suppress hypervisor cpuid unless running on a hypervisor */
+		cpu->maxhv = 0;
+	}
 
 	cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL);
 	cpu->phyaddr_bits = address_bits & 0xFF;
diff --git a/x86info.c b/x86info.c
index 22c4734..80cae36 100644
--- a/x86info.c
+++ b/x86info.c
@@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu)
 
 		if (cpu->maxei2 >=0xC0000000)
 			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
+
+		if (cpu->maxhv >= 0x40000000)
+			dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv);
+
 	}
 
 	if (show_cacheinfo) {
diff --git a/x86info.h b/x86info.h
index 7d2a455..c4f5d81 100644
--- a/x86info.h
+++ b/x86info.h
@@ -84,7 +84,7 @@ struct cpudata {
 	unsigned int cachesize_trace;
 	unsigned int phyaddr_bits;
 	unsigned int viraddr_bits;
-	unsigned int cpuid_level, maxei, maxei2;
+	unsigned int cpuid_level, maxei, maxei2, maxhv;
 	char name[CPU_NAME_LEN];
 	enum connector connector;
 	unsigned int flags_ecx;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 15:08:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 15:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOsCj-0001YW-Ll; Mon, 30 Apr 2012 15:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SOsCi-0001YO-DE
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 15:07:56 +0000
Received: from [85.158.143.99:47629] by server-3.bemta-4.messagelabs.com id
	44/C2-05853-BCAAE9F4; Mon, 30 Apr 2012 15:07:55 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335798474!25554889!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTExNTg=\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14128 invoked from network); 30 Apr 2012 15:07:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	30 Apr 2012 15:07:54 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3UF7p4x007532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 11:07:52 -0400
Received: from redhat.com (vpn-202-127.tlv.redhat.com [10.35.202.127])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q3UEcQLK030281; Mon, 30 Apr 2012 10:38:27 -0400
Date: Mon, 30 Apr 2012 17:38:35 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: davej@redhat.com
Message-ID: <20120430143835.GA10190@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org,
	Gleb Natapov <gleb@redhat.com>, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org
Subject: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following makes 'x86info -r' dump hypervisor leaf cpu ids
(for kvm this is signature+features) when running in a vm.

On the guest we see the signature and the features:
eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000

Hypervisor flag is checked to avoid output changes when not
running on a VM.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Changes from v1:
	Make work on non KVM hypervisors (only KVM was tested).
	Avi Kivity said kvm will in the future report
	max HV leaf in eax. For now it reports eax = 0
        so add a work around for that.

---

diff --git a/identify.c b/identify.c
index 33f35de..a4a3763 100644
--- a/identify.c
+++ b/identify.c
@@ -9,8 +9,8 @@
 
 void get_cpu_info_basics(struct cpudata *cpu)
 {
-	unsigned int maxi, maxei, vendor, address_bits;
-	unsigned int eax;
+	unsigned int maxi, maxei, maxhv, vendor, address_bits;
+	unsigned int eax, ebx, ecx;
 
 	cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL);
 	maxi &= 0xffff;		/* The high-order word is non-zero on some Cyrix CPUs */
@@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu)
 		return;
 
 	/* Everything that supports cpuid supports these. */
-	cpuid(cpu->number, 1, &eax, NULL, NULL, NULL);
+	cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL);
 	cpu->stepping = eax & 0xf;
 	cpu->model = (eax >> 4) & 0xf;
 	cpu->family = (eax >> 8) & 0xf;
@@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu)
 
 	cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
 	cpu->maxei2 = maxei;
+	if (ecx & 0x80000000) {
+		cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL);
+		/*
+		 * KVM up to linux 3.4 reports 0 as the max hypervisor leaf,
+		 * where it really means 0x40000001.
+		 * Most (all?) hypervisors have at least one CPUID besides
+		 * the vendor ID so assume that.
+		 */
+		cpu->maxhv = maxhv ? maxhv : 0x40000001;
+	} else {
+		/* Suppress hypervisor cpuid unless running on a hypervisor */
+		cpu->maxhv = 0;
+	}
 
 	cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL);
 	cpu->phyaddr_bits = address_bits & 0xFF;
diff --git a/x86info.c b/x86info.c
index 22c4734..80cae36 100644
--- a/x86info.c
+++ b/x86info.c
@@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu)
 
 		if (cpu->maxei2 >=0xC0000000)
 			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
+
+		if (cpu->maxhv >= 0x40000000)
+			dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv);
+
 	}
 
 	if (show_cacheinfo) {
diff --git a/x86info.h b/x86info.h
index 7d2a455..c4f5d81 100644
--- a/x86info.h
+++ b/x86info.h
@@ -84,7 +84,7 @@ struct cpudata {
 	unsigned int cachesize_trace;
 	unsigned int phyaddr_bits;
 	unsigned int viraddr_bits;
-	unsigned int cpuid_level, maxei, maxei2;
+	unsigned int cpuid_level, maxei, maxei2, maxhv;
 	char name[CPU_NAME_LEN];
 	enum connector connector;
 	unsigned int flags_ecx;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 15:10:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 15:10:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOsFE-0001fQ-81; Mon, 30 Apr 2012 15:10:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOsFD-0001fJ-4s
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 15:10:31 +0000
Received: from [193.109.254.147:53107] by server-1.bemta-14.messagelabs.com id
	34/46-29372-66BAE9F4; Mon, 30 Apr 2012 15:10:30 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335798616!153851!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5866 invoked from network); 30 Apr 2012 15:10:17 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 15:10:17 -0000
Received: by dajx4 with SMTP id x4so4455268daj.28
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 08:10:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=uOgMjR/NjnBmJWz+D/zKMdutCQ1lQZ9LjBeUXJh6XQA=;
	b=R9um4SR2Ok4L+bYDQBc02axO6L/EOsJVUZ+mLLE+jxaof8MNeiy2I442iVEiGRtyW0
	9a4mpzCm1gJmQsLtAI0l0grbdO/AtEPX08CVRmVIBzqZymjcfBeG7Ztg9R8bqU8dAw35
	jPC3Os+ZuVzctvQ2tqEOO68whyaufuGCk/OrwbEXtraiMmf1r0HoTlsh8pEkwzwkXx1d
	DnTczEOoIoc9hXFg2cih6xXyRpQsAXUemX6ZWNau1Zi10U7Iti9OkdebdT8FhYfhdMSS
	3dHHMEVXz1NfbNYF6IDdIxEtQSQrnvideyNR1RoafSwx5uNREXI7GkjZF/6yOHSg7zMq
	LpUA==
Received: by 10.68.201.9 with SMTP id jw9mr48586433pbc.88.1335798615702;
	Mon, 30 Apr 2012 08:10:15 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id pb4sm16276935pbc.55.2012.04.30.08.10.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Apr 2012 08:10:15 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: wang zhihao <accept.acm@gmail.com>
In-Reply-To: <4F9EA5DA.40100@eu.citrix.com>
Date: Mon, 30 Apr 2012 23:10:10 +0800
Message-Id: <3EB7454D-B8B6-4D62-88E2-0B46FA71B20C@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
	<CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
	<7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
	<4F9EA5DA.40100@eu.citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Mailer: Apple Mail (2.1084)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgR2VvcmdlOgoKSSBnb3QgaXQuICBUcnkgc29tZSBleHRyZW1lIHZhbHVlIG9yIGludmFsaWQg
aW5wdXQgdG8gdGhlIHJ1bm5pbmcgY29kZSB3aXRoIG15IG5ldyBmZWF0dXJlLCBJZiB0aGUgcGF0
Y2ggaXMgYSBzaW1wbGUgb3B0aW9uIG9yIHNvbWV0aGluZy1saWtlIHdoaWNoIGNhbiBiZSBlYXN5
IHRlc3RlZCBpbiB0aGlzIHdheSwgUmlnaHQ/CgpSZWdhcmRzCldhbmcgWmhpaGFvCgoK1NogMjAx
Mi00LTMwo6zPws7nMTA6NDajrCBHZW9yZ2UgRHVubGFwINC0tcCjugoKPiBPbiAzMC8wNC8xMiAx
NToyNSwgd2FuZyB6aGloYW8gd3JvdGU6Cj4+IEhpIEdlb3JnZToKPj4gCj4+IEkgZG9uJ3QgaGF2
ZSBhIHBhdGNoIG5vdywgYnV0IG1heSBoYXZlIG9uZSBpbiBmdXR1cmUuIDogUAo+PiAKPj4gT2ss
IEkgd2lsbCB0cnkgdG8gbWFrZSBhIHBhdGNoIGFuZCB0aGVuIGFzayB0aGlzIHF1ZXN0aW9uIDog
KQo+IFdlbGwsIGFzIEkgc2FpZCwgdGhlIGdlbmVyYWwgaWRlYSBpcywgInRyeSB0byBicmVhayBp
dCIuIElmIHlvdSBhZGQgYQo+IG5ldyBvcHRpb24sIGZvciBpbnN0YW5jZSwgY2hlY2sgdG8gbWFr
ZSBzdXJlIHRoYXQgaXQgd29ya3MgcmlnaHQ6Cj4gKiBJZiB5b3UgcHV0IGluIGEgcmVhc29uYWJs
ZSB2YWx1ZQo+ICogSWYgeW91IHB1dCBpbiBhbiB1bnJlYXNvbmFibHkgaGlnaCB2YWx1ZQo+ICog
SWYgeW91IHB1dCBpbiBhIG5lZ2F0aXZlIG51bWJlcgo+ICogSWYgeW91IGRvbid0IHNwZWNpZnkg
dGhlIG9wdGlvbiBhdCBhbGwKPiAqIElmIHlvdSBwdXQgYSBzdHJpbmcgaW5zdGVhZCBvZiBhIG51
bWJlcgo+IAo+IE1ha2Ugc2Vuc2U/Cj4gCj4gLUdlb3JnZQo+IAo+PiAKPj4gUmVnYXJkcwo+PiBX
YW5nIHpoaWhhbwo+PiAKPj4g1NogMjAxMi00LTMwo6zPws7nMTA6MTmjrCBHZW9yZ2UgRHVubGFw
INC0tcCjugo+PiAKPj4+IE9uIE1vbiwgQXByIDMwLCAyMDEyIGF0IDM6MTIgUE0sIHdhbmcgemhp
aGFvIDxhY2NlcHQuYWNtQGdtYWlsLmNvbT4gd3JvdGU6Cj4+Pj4gSGkgR2VvcmdlOgo+Pj4+IAo+
Pj4+IFRoYW5rcyBmb3IgeW91ciBndWlkZXMsIEJ1dCBJIGRvbid0IGtub3cgd2hhdCAiY29tYmlu
YXRpb24iIG1lYW5zLiAgQ291bGQKPj4+PiB5b3UgdGVsbCBtZSBtb3JlIGFib3V0IGl0Pwo+Pj4g
SSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhhbXBsZSB3aXRob3V0IGFuIGV4YW1wbGUgdG8g
d29yayB3aXRoLgo+Pj4gOi0pICBXaGF0IGRvZXMgeW91ciBwYXRjaCBkbz8KPj4+IAo+Pj4gLUdl
b3JnZQo+Pj4gCj4+Pj4gQmVzdCBSZWdhcmRzCj4+Pj4gV2FuZyBaaGloYW8KPj4+PiAKPj4+PiDU
2iAyMDEyLTQtMzCjrM/Czuc1OjE2o6wgR2VvcmdlIER1bmxhcCDQtLXAo7oKPj4+PiAKPj4+PiBP
biBTdW4sIEFwciAyOSwgMjAxMiBhdCA0OjIxIFBNLCB3YW5nIHpoaWhhbyA8YWNjZXB0LmFjbUBn
bWFpbC5jb20+IHdyb3RlOgo+Pj4+IAo+Pj4+IEhpICwgQWxsCj4+Pj4gCj4+Pj4gCj4+Pj4gSSAn
bSBhIGdyZWVuIGhhbmQgYW5kIGludGVyZXN0ZWQgaW4gb3BlbiBzb3VyY2UgZGV2ZWxvcG1lbnQu
IEkgaGF2ZSBhCj4+Pj4gZ2VuZXJhbCBxdWVzdGlvbiAiSG93IHRvIHRlc3QgbXkgcGF0Y2ggYmVm
b3JlIEkgcG9zdCBpdCB0byBwdWJsaWM/IiBIb3BlIHlvdQo+Pj4+IGd1eXMgZ2l2ZSBtZSBzb21l
IHN1Z2dlc3Rpb25zLiA6ICkKPj4+PiAKPj4+PiAKPj4+PiBGaXJzdGx5LCBJIGNhbiByZS1jb21w
aWxlIHRoZSBjb2RlLCB0byBhc3N1cmUgbm8gc3ludGF4IGVycm9yLiBIb3dldmVyLEkKPj4+PiBk
b24ndCBrbm93IGhvdyB0byB0ZXN0IG15IHBhdGNoJ3MgZnVuY3Rpb24gaXMgcmlnaHQgb3Igbm90
LiBTb21lIHNvZnR3YXJlCj4+Pj4gcmVxdWlyZXMgdW5pdCB0ZXN0IGZvciBlYWNoIGZ1bmN0aW9u
LiBJcyB0aGVyZSBhbnl0aGluZyBzaW1pbGFyIGluIHhlbgo+Pj4+IHByb2plY3Q/Cj4+Pj4gCj4+
Pj4gCj4+Pj4gVGhlcmUgaXMgbm8gdW5pdCB0ZXN0aW5nIGZvciBYZW4uICBXaGF0IHlvdSBuZWVk
IHRvIHRlc3QgcmVhbGx5Cj4+Pj4gZGVwZW5kcyBvbiB3aGF0IHlvdXIgcGF0Y2ggaXMgZG9pbmcu
ICBUaGUgbWFpbiBnb2FsIGlzIHRvIGV4ZXJjaXNlIHRoZQo+Pj4+IGNvZGUgeW91J3ZlIGp1c3Qg
YWRkZWQgb3IgY2hhbmdlZDogdHJ5IHRvIHB1dCBpdCBpbiBkaWZmZXJlbnQKPj4+PiBjb21iaW5h
dGlvbnMgdG8gbWFrZSBzdXJlIHRoYXQgaXQgd29ya3MgYXMgeW91IGV4cGVjdC4gIFRyeSB0byBi
cmVhawo+Pj4+IGl0LCByZWFsbHkuIDotKQo+Pj4+IAo+Pj4+IElmIHlvdSdyZSBqdXN0IHR3ZWFr
aW5nIGEgc2ltcGxlIG9wdGlvbiBpbiB0aGUgeGwgY29uZmlnIGZpbGUsIHRoZW4KPj4+PiB5b3Ug
bmVlZCB0byB0ZXN0IGEgZmV3IGRpZmZlcmVudCBjb21iaW5hdGlvbnMgdG8gbWFrZSBzdXJlIHRo
YXQgYWxsCj4+Pj4gdGhlIHJlYXNvbmFibGUgY29tYmluYXRpb25zIHdvcmsuICBJZiB5b3UncmUg
Y2hhbmdpbmcgdGhlIGxvY2tzIGluIHRoZQo+Pj4+IG1lbW9yeSBtYW5hZ2VtZW50IGNvZGUgaW4g
dGhlIGh5cGVydmlzb3IsIHRoZW4geW91IG5lZWQgdG8gcnVuIGEgYnVuY2gKPj4+PiBvZiBiZW5j
aG1hcmtzIHRoYXQgZXhlcmNpc2UgdGhhdCBjb2RlLCBwcm9iYWJseSBmb3Igc2V2ZXJhbCBob3Vy
cy4KPj4+PiAKPj4+PiBJZiB5b3UgcG9zdCB5b3VyIHBhdGNoIHRvIHRoZSBsaXN0ICh3aXRoIGFu
IGFwcHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+Pj4+IHdlIG1heSBiZSBhYmxlIHRvIGdpdmUgeW91
IHNvbWUgc3VnZ2VzdGlvbnMuCj4+Pj4gCj4+Pj4gLUdlb3JnZQo+Pj4+IAo+Pj4+IAo+Pj4+IAo+
Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4g
WGVuLWRldmVsIG1haWxpbmcgbGlzdAo+Pj4+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4+Pj4g
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4+Pj4gCj4gCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 30 15:10:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 15:10:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOsFE-0001fQ-81; Mon, 30 Apr 2012 15:10:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <accept.acm@gmail.com>) id 1SOsFD-0001fJ-4s
	for xen-devel@lists.xen.org; Mon, 30 Apr 2012 15:10:31 +0000
Received: from [193.109.254.147:53107] by server-1.bemta-14.messagelabs.com id
	34/46-29372-66BAE9F4; Mon, 30 Apr 2012 15:10:30 +0000
X-Env-Sender: accept.acm@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1335798616!153851!1
X-Originating-IP: [209.85.210.41]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5866 invoked from network); 30 Apr 2012 15:10:17 -0000
Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com)
	(209.85.210.41)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 15:10:17 -0000
Received: by dajx4 with SMTP id x4so4455268daj.28
	for <xen-devel@lists.xen.org>; Mon, 30 Apr 2012 08:10:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=uOgMjR/NjnBmJWz+D/zKMdutCQ1lQZ9LjBeUXJh6XQA=;
	b=R9um4SR2Ok4L+bYDQBc02axO6L/EOsJVUZ+mLLE+jxaof8MNeiy2I442iVEiGRtyW0
	9a4mpzCm1gJmQsLtAI0l0grbdO/AtEPX08CVRmVIBzqZymjcfBeG7Ztg9R8bqU8dAw35
	jPC3Os+ZuVzctvQ2tqEOO68whyaufuGCk/OrwbEXtraiMmf1r0HoTlsh8pEkwzwkXx1d
	DnTczEOoIoc9hXFg2cih6xXyRpQsAXUemX6ZWNau1Zi10U7Iti9OkdebdT8FhYfhdMSS
	3dHHMEVXz1NfbNYF6IDdIxEtQSQrnvideyNR1RoafSwx5uNREXI7GkjZF/6yOHSg7zMq
	LpUA==
Received: by 10.68.201.9 with SMTP id jw9mr48586433pbc.88.1335798615702;
	Mon, 30 Apr 2012 08:10:15 -0700 (PDT)
Received: from ?IPv6:2001:cc0:2020:2021:e2f8:47ff:fe20:9134?
	([2001:cc0:2020:2021:e2f8:47ff:fe20:9134])
	by mx.google.com with ESMTPS id pb4sm16276935pbc.55.2012.04.30.08.10.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Apr 2012 08:10:15 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
From: wang zhihao <accept.acm@gmail.com>
In-Reply-To: <4F9EA5DA.40100@eu.citrix.com>
Date: Mon, 30 Apr 2012 23:10:10 +0800
Message-Id: <3EB7454D-B8B6-4D62-88E2-0B46FA71B20C@gmail.com>
References: <BCAD5D6E-1C3F-4EE0-8980-2E134E007B8A@gmail.com>
	<CAFLBxZY2ZmRssD3LBSTUW7d=MXgQ4qnH+zu1pUygR5T0JWEEwA@mail.gmail.com>
	<068F8B66-CCED-47D3-962E-649293E0EC5C@gmail.com>
	<CAFLBxZYt7FqZNzvaDx-Y0=gA4GryxAT_TdT=0mCMk37KsDuw9A@mail.gmail.com>
	<7EAB5881-3224-4AE0-B31D-637FEDB07A27@gmail.com>
	<4F9EA5DA.40100@eu.citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Mailer: Apple Mail (2.1084)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] How to test my patch before I post it to public?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgR2VvcmdlOgoKSSBnb3QgaXQuICBUcnkgc29tZSBleHRyZW1lIHZhbHVlIG9yIGludmFsaWQg
aW5wdXQgdG8gdGhlIHJ1bm5pbmcgY29kZSB3aXRoIG15IG5ldyBmZWF0dXJlLCBJZiB0aGUgcGF0
Y2ggaXMgYSBzaW1wbGUgb3B0aW9uIG9yIHNvbWV0aGluZy1saWtlIHdoaWNoIGNhbiBiZSBlYXN5
IHRlc3RlZCBpbiB0aGlzIHdheSwgUmlnaHQ/CgpSZWdhcmRzCldhbmcgWmhpaGFvCgoK1NogMjAx
Mi00LTMwo6zPws7nMTA6NDajrCBHZW9yZ2UgRHVubGFwINC0tcCjugoKPiBPbiAzMC8wNC8xMiAx
NToyNSwgd2FuZyB6aGloYW8gd3JvdGU6Cj4+IEhpIEdlb3JnZToKPj4gCj4+IEkgZG9uJ3QgaGF2
ZSBhIHBhdGNoIG5vdywgYnV0IG1heSBoYXZlIG9uZSBpbiBmdXR1cmUuIDogUAo+PiAKPj4gT2ss
IEkgd2lsbCB0cnkgdG8gbWFrZSBhIHBhdGNoIGFuZCB0aGVuIGFzayB0aGlzIHF1ZXN0aW9uIDog
KQo+IFdlbGwsIGFzIEkgc2FpZCwgdGhlIGdlbmVyYWwgaWRlYSBpcywgInRyeSB0byBicmVhayBp
dCIuIElmIHlvdSBhZGQgYQo+IG5ldyBvcHRpb24sIGZvciBpbnN0YW5jZSwgY2hlY2sgdG8gbWFr
ZSBzdXJlIHRoYXQgaXQgd29ya3MgcmlnaHQ6Cj4gKiBJZiB5b3UgcHV0IGluIGEgcmVhc29uYWJs
ZSB2YWx1ZQo+ICogSWYgeW91IHB1dCBpbiBhbiB1bnJlYXNvbmFibHkgaGlnaCB2YWx1ZQo+ICog
SWYgeW91IHB1dCBpbiBhIG5lZ2F0aXZlIG51bWJlcgo+ICogSWYgeW91IGRvbid0IHNwZWNpZnkg
dGhlIG9wdGlvbiBhdCBhbGwKPiAqIElmIHlvdSBwdXQgYSBzdHJpbmcgaW5zdGVhZCBvZiBhIG51
bWJlcgo+IAo+IE1ha2Ugc2Vuc2U/Cj4gCj4gLUdlb3JnZQo+IAo+PiAKPj4gUmVnYXJkcwo+PiBX
YW5nIHpoaWhhbwo+PiAKPj4g1NogMjAxMi00LTMwo6zPws7nMTA6MTmjrCBHZW9yZ2UgRHVubGFw
INC0tcCjugo+PiAKPj4+IE9uIE1vbiwgQXByIDMwLCAyMDEyIGF0IDM6MTIgUE0sIHdhbmcgemhp
aGFvIDxhY2NlcHQuYWNtQGdtYWlsLmNvbT4gd3JvdGU6Cj4+Pj4gSGkgR2VvcmdlOgo+Pj4+IAo+
Pj4+IFRoYW5rcyBmb3IgeW91ciBndWlkZXMsIEJ1dCBJIGRvbid0IGtub3cgd2hhdCAiY29tYmlu
YXRpb24iIG1lYW5zLiAgQ291bGQKPj4+PiB5b3UgdGVsbCBtZSBtb3JlIGFib3V0IGl0Pwo+Pj4g
SSBjYW4ndCByZWFsbHkgZ2l2ZSB5b3UgYW4gZXhhbXBsZSB3aXRob3V0IGFuIGV4YW1wbGUgdG8g
d29yayB3aXRoLgo+Pj4gOi0pICBXaGF0IGRvZXMgeW91ciBwYXRjaCBkbz8KPj4+IAo+Pj4gLUdl
b3JnZQo+Pj4gCj4+Pj4gQmVzdCBSZWdhcmRzCj4+Pj4gV2FuZyBaaGloYW8KPj4+PiAKPj4+PiDU
2iAyMDEyLTQtMzCjrM/Czuc1OjE2o6wgR2VvcmdlIER1bmxhcCDQtLXAo7oKPj4+PiAKPj4+PiBP
biBTdW4sIEFwciAyOSwgMjAxMiBhdCA0OjIxIFBNLCB3YW5nIHpoaWhhbyA8YWNjZXB0LmFjbUBn
bWFpbC5jb20+IHdyb3RlOgo+Pj4+IAo+Pj4+IEhpICwgQWxsCj4+Pj4gCj4+Pj4gCj4+Pj4gSSAn
bSBhIGdyZWVuIGhhbmQgYW5kIGludGVyZXN0ZWQgaW4gb3BlbiBzb3VyY2UgZGV2ZWxvcG1lbnQu
IEkgaGF2ZSBhCj4+Pj4gZ2VuZXJhbCBxdWVzdGlvbiAiSG93IHRvIHRlc3QgbXkgcGF0Y2ggYmVm
b3JlIEkgcG9zdCBpdCB0byBwdWJsaWM/IiBIb3BlIHlvdQo+Pj4+IGd1eXMgZ2l2ZSBtZSBzb21l
IHN1Z2dlc3Rpb25zLiA6ICkKPj4+PiAKPj4+PiAKPj4+PiBGaXJzdGx5LCBJIGNhbiByZS1jb21w
aWxlIHRoZSBjb2RlLCB0byBhc3N1cmUgbm8gc3ludGF4IGVycm9yLiBIb3dldmVyLEkKPj4+PiBk
b24ndCBrbm93IGhvdyB0byB0ZXN0IG15IHBhdGNoJ3MgZnVuY3Rpb24gaXMgcmlnaHQgb3Igbm90
LiBTb21lIHNvZnR3YXJlCj4+Pj4gcmVxdWlyZXMgdW5pdCB0ZXN0IGZvciBlYWNoIGZ1bmN0aW9u
LiBJcyB0aGVyZSBhbnl0aGluZyBzaW1pbGFyIGluIHhlbgo+Pj4+IHByb2plY3Q/Cj4+Pj4gCj4+
Pj4gCj4+Pj4gVGhlcmUgaXMgbm8gdW5pdCB0ZXN0aW5nIGZvciBYZW4uICBXaGF0IHlvdSBuZWVk
IHRvIHRlc3QgcmVhbGx5Cj4+Pj4gZGVwZW5kcyBvbiB3aGF0IHlvdXIgcGF0Y2ggaXMgZG9pbmcu
ICBUaGUgbWFpbiBnb2FsIGlzIHRvIGV4ZXJjaXNlIHRoZQo+Pj4+IGNvZGUgeW91J3ZlIGp1c3Qg
YWRkZWQgb3IgY2hhbmdlZDogdHJ5IHRvIHB1dCBpdCBpbiBkaWZmZXJlbnQKPj4+PiBjb21iaW5h
dGlvbnMgdG8gbWFrZSBzdXJlIHRoYXQgaXQgd29ya3MgYXMgeW91IGV4cGVjdC4gIFRyeSB0byBi
cmVhawo+Pj4+IGl0LCByZWFsbHkuIDotKQo+Pj4+IAo+Pj4+IElmIHlvdSdyZSBqdXN0IHR3ZWFr
aW5nIGEgc2ltcGxlIG9wdGlvbiBpbiB0aGUgeGwgY29uZmlnIGZpbGUsIHRoZW4KPj4+PiB5b3Ug
bmVlZCB0byB0ZXN0IGEgZmV3IGRpZmZlcmVudCBjb21iaW5hdGlvbnMgdG8gbWFrZSBzdXJlIHRo
YXQgYWxsCj4+Pj4gdGhlIHJlYXNvbmFibGUgY29tYmluYXRpb25zIHdvcmsuICBJZiB5b3UncmUg
Y2hhbmdpbmcgdGhlIGxvY2tzIGluIHRoZQo+Pj4+IG1lbW9yeSBtYW5hZ2VtZW50IGNvZGUgaW4g
dGhlIGh5cGVydmlzb3IsIHRoZW4geW91IG5lZWQgdG8gcnVuIGEgYnVuY2gKPj4+PiBvZiBiZW5j
aG1hcmtzIHRoYXQgZXhlcmNpc2UgdGhhdCBjb2RlLCBwcm9iYWJseSBmb3Igc2V2ZXJhbCBob3Vy
cy4KPj4+PiAKPj4+PiBJZiB5b3UgcG9zdCB5b3VyIHBhdGNoIHRvIHRoZSBsaXN0ICh3aXRoIGFu
IGFwcHJvcHJpYXRlIGRlc2NyaXB0aW9uKQo+Pj4+IHdlIG1heSBiZSBhYmxlIHRvIGdpdmUgeW91
IHNvbWUgc3VnZ2VzdGlvbnMuCj4+Pj4gCj4+Pj4gLUdlb3JnZQo+Pj4+IAo+Pj4+IAo+Pj4+IAo+
Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4g
WGVuLWRldmVsIG1haWxpbmcgbGlzdAo+Pj4+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4+Pj4g
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4+Pj4gCj4gCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Apr 30 16:17:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 16:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOtHV-0002UT-JG; Mon, 30 Apr 2012 16:16:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SOtHU-0002UO-3P
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 16:16:56 +0000
Received: from [85.158.143.99:13521] by server-3.bemta-4.messagelabs.com id
	1F/4E-05853-7FABE9F4; Mon, 30 Apr 2012 16:16:55 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335802613!25565011!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12122 invoked from network); 30 Apr 2012 16:16:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-216.messagelabs.com with SMTP;
	30 Apr 2012 16:16:53 -0000
Received: from [192.168.1.103] (unknown [180.159.255.59])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 80726DBC70;
	Tue,  1 May 2012 00:16:38 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 01 May 2012 00:16:27 +0800
Message-ID: <1335802587.4746.2.camel@chief-river-32>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH v2] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implements xen_io_apic_read with hypercall, so it returns proper
IO-APIC information instead of fabricated one.

Fallback to return an emulated IO_APIC values if hypercall fails.

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---

v2: fallback to return an emulated IO_APIC values if hypercall fails

 arch/x86/xen/apic.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index aee16ab..1913bf2 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -1,14 +1,27 @@
 #include <linux/init.h>
 #include <asm/x86_init.h>
+#include <asm/apic.h>
+#include <xen/interface/physdev.h>
+#include <asm/xen/hypercall.h>
 
 unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
 {
+	struct physdev_apic apic_op;
+	int ret;
+
+	apic_op.apic_physbase = mpc_ioapic_addr(apic);
+	apic_op.reg = reg;
+	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
+	if (!ret)
+		return apic_op.value;
+
+	/* fallback to return an emulated IO_APIC values */
 	if (reg == 0x1)
 		return 0x00170020;
 	else if (reg == 0x0)
 		return apic << 24;
 
-	return 0xff;
+	return 0xfd;
 }
 
 void __init xen_init_apic(void)
-- 
1.7.9




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 16:17:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 16:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOtHV-0002UT-JG; Mon, 30 Apr 2012 16:16:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlin@ss.pku.edu.cn>) id 1SOtHU-0002UO-3P
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 16:16:56 +0000
Received: from [85.158.143.99:13521] by server-3.bemta-4.messagelabs.com id
	1F/4E-05853-7FABE9F4; Mon, 30 Apr 2012 16:16:55 +0000
X-Env-Sender: mlin@ss.pku.edu.cn
X-Msg-Ref: server-5.tower-216.messagelabs.com!1335802613!25565011!1
X-Originating-IP: [124.207.24.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12122 invoked from network); 30 Apr 2012 16:16:53 -0000
Received: from unknown (HELO mail.ss.pku.edu.cn) (124.207.24.138)
	by server-5.tower-216.messagelabs.com with SMTP;
	30 Apr 2012 16:16:53 -0000
Received: from [192.168.1.103] (unknown [180.159.255.59])
	(Authenticated sender: mlin@ss.pku.edu.cn)
	by mail.ss.pku.edu.cn (Postfix) with ESMTPA id 80726DBC70;
	Tue,  1 May 2012 00:16:38 +0800 (CST)
From: Lin Ming <mlin@ss.pku.edu.cn>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 01 May 2012 00:16:27 +0800
Message-ID: <1335802587.4746.2.camel@chief-river-32>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH v2] xen/apic: implement io apic read with
	hypercall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implements xen_io_apic_read with hypercall, so it returns proper
IO-APIC information instead of fabricated one.

Fallback to return an emulated IO_APIC values if hypercall fails.

Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---

v2: fallback to return an emulated IO_APIC values if hypercall fails

 arch/x86/xen/apic.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index aee16ab..1913bf2 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -1,14 +1,27 @@
 #include <linux/init.h>
 #include <asm/x86_init.h>
+#include <asm/apic.h>
+#include <xen/interface/physdev.h>
+#include <asm/xen/hypercall.h>
 
 unsigned int xen_io_apic_read(unsigned apic, unsigned reg)
 {
+	struct physdev_apic apic_op;
+	int ret;
+
+	apic_op.apic_physbase = mpc_ioapic_addr(apic);
+	apic_op.reg = reg;
+	ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op);
+	if (!ret)
+		return apic_op.value;
+
+	/* fallback to return an emulated IO_APIC values */
 	if (reg == 0x1)
 		return 0x00170020;
 	else if (reg == 0x0)
 		return apic << 24;
 
-	return 0xff;
+	return 0xfd;
 }
 
 void __init xen_init_apic(void)
-- 
1.7.9




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 17:10:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 17:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOu74-0002z1-Ka; Mon, 30 Apr 2012 17:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOu72-0002yp-7S
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 17:10:12 +0000
Received: from [85.158.143.99:34108] by server-3.bemta-4.messagelabs.com id
	EC/B5-05853-377CE9F4; Mon, 30 Apr 2012 17:10:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335805810!18371037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjkwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19290 invoked from network); 30 Apr 2012 17:10:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 17:10:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208";a="12210452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Apr 2012 17:10:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Apr 2012 18:10:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOu6z-0001kg-VQ;
	Mon, 30 Apr 2012 17:10:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOu6z-0001lC-UV;
	Mon, 30 Apr 2012 18:10:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12766-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Apr 2012 18:10:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12766: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12766 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12766/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot         fail in 12764 REGR. vs. 12694
 test-amd64-i386-pv            5 xen-boot         fail in 12764 REGR. vs. 12694
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 12764 REGR. vs. 12694
 test-amd64-i386-rhel6hvm-amd  5 xen-boot         fail in 12764 REGR. vs. 12694
 test-i386-i386-pv             5 xen-boot         fail in 12762 REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl             3 host-install(3)           broken pass in 12764
 test-i386-i386-pv             3 host-install(3)           broken pass in 12762
 test-amd64-i386-xl            3 host-install(3)           broken pass in 12764
 test-amd64-i386-pv            3 host-install(3)           broken pass in 12764
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 12764
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 12764
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 12764 pass in 12766
 test-amd64-amd64-xl-sedf    12 guest-saverestore.2 fail in 12762 pass in 12766

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                f1c84a5cb52ee2915457b481c756fcc1dfe6a471
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 17:10:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 17:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOu74-0002z1-Ka; Mon, 30 Apr 2012 17:10:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SOu72-0002yp-7S
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 17:10:12 +0000
Received: from [85.158.143.99:34108] by server-3.bemta-4.messagelabs.com id
	EC/B5-05853-377CE9F4; Mon, 30 Apr 2012 17:10:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1335805810!18371037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjkwNw==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19290 invoked from network); 30 Apr 2012 17:10:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Apr 2012 17:10:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208";a="12210452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Apr 2012 17:10:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Apr 2012 18:10:10 +0100
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1SOu6z-0001kg-VQ;
	Mon, 30 Apr 2012 17:10:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SOu6z-0001lC-UV;
	Mon, 30 Apr 2012 18:10:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12766-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Apr 2012 18:10:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 12766: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12766 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12766/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             5 xen-boot         fail in 12764 REGR. vs. 12694
 test-amd64-i386-pv            5 xen-boot         fail in 12764 REGR. vs. 12694
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 12764 REGR. vs. 12694
 test-amd64-i386-rhel6hvm-amd  5 xen-boot         fail in 12764 REGR. vs. 12694
 test-i386-i386-pv             5 xen-boot         fail in 12762 REGR. vs. 12694

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl             3 host-install(3)           broken pass in 12764
 test-i386-i386-pv             3 host-install(3)           broken pass in 12762
 test-amd64-i386-xl            3 host-install(3)           broken pass in 12764
 test-amd64-i386-pv            3 host-install(3)           broken pass in 12764
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 12764
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 12764
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 12764 pass in 12766
 test-amd64-amd64-xl-sedf    12 guest-saverestore.2 fail in 12762 pass in 12766

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  8 guest-saverestore          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore        fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                f1c84a5cb52ee2915457b481c756fcc1dfe6a471
baseline version:
 linux                0527fde0639955203ad48a9fd83bd6fc35e82e07

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 19:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 19:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOwV3-0004iQ-Q0; Mon, 30 Apr 2012 19:43:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SOwV1-0004iG-VO
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 19:43:08 +0000
Received: from [85.158.143.99:14380] by server-2.bemta-4.messagelabs.com id
	8E/A7-17550-B4BEE9F4; Mon, 30 Apr 2012 19:43:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335814980!18872529!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMjcyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15772 invoked from network); 30 Apr 2012 19:43:06 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Apr 2012 19:43:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3UJguw6012526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 19:42:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3UJgt47017143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Apr 2012 19:42:55 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3UJgtRa014589; Mon, 30 Apr 2012 14:42:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Apr 2012 12:42:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4FEDD40357; Mon, 30 Apr 2012 15:37:13 -0400 (EDT)
Date: Mon, 30 Apr 2012 15:37:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: weidong.han@intel.com, xen-devel@lists.xensource.com, JBeulich@novell.com, 
	Tim.Deegan@citrix.com
Message-ID: <20120430193713.GA12817@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1
 or Xen-unstable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I somehow thought that this has been fixed but I've been
getting reports that people are running into this.

What kind of fix do I need the in the kernel? I see this:
 255         xen_cpuid(&ax, &bx, &cx, &dx);
 256 
 257         xsave_mask =
 258                 (1 << (X86_FEATURE_XSAVE % 32)) |
 259                 (1 << (X86_FEATURE_OSXSAVE % 32));
 260 
 261         /* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 262         if ((cx & xsave_mask) != xsave_mask)
 263                 cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
 264 }

But do I need some other one?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Apr 30 19:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Apr 2012 19:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SOwV3-0004iQ-Q0; Mon, 30 Apr 2012 19:43:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SOwV1-0004iG-VO
	for xen-devel@lists.xensource.com; Mon, 30 Apr 2012 19:43:08 +0000
Received: from [85.158.143.99:14380] by server-2.bemta-4.messagelabs.com id
	8E/A7-17550-B4BEE9F4; Mon, 30 Apr 2012 19:43:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1335814980!18872529!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMjcyMQ==\n
X-StarScan-Version: 6.5.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15772 invoked from network); 30 Apr 2012 19:43:06 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Apr 2012 19:43:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q3UJguw6012526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Apr 2012 19:42:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q3UJgt47017143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Apr 2012 19:42:55 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q3UJgtRa014589; Mon, 30 Apr 2012 14:42:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Apr 2012 12:42:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4FEDD40357; Mon, 30 Apr 2012 15:37:13 -0400 (EDT)
Date: Mon, 30 Apr 2012 15:37:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: weidong.han@intel.com, xen-devel@lists.xensource.com, JBeulich@novell.com, 
	Tim.Deegan@citrix.com
Message-ID: <20120430193713.GA12817@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1
 or Xen-unstable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I somehow thought that this has been fixed but I've been
getting reports that people are running into this.

What kind of fix do I need the in the kernel? I see this:
 255         xen_cpuid(&ax, &bx, &cx, &dx);
 256 
 257         xsave_mask =
 258                 (1 << (X86_FEATURE_XSAVE % 32)) |
 259                 (1 << (X86_FEATURE_OSXSAVE % 32));
 260 
 261         /* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 262         if ((cx & xsave_mask) != xsave_mask)
 263                 cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
 264 }

But do I need some other one?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel